需求质量验证一需求评审

通常，总是由一些非软件开发人员进行产品检查以发现产品所存在的问题，这就是技术评审。需求文档的评审是一项精益求精的技术，它可以发现那些二义性的或不确定的需求、那些由于定义不清而不能作为设计基础的需求，还有那些实际上是设计规格说明的所谓的“需求”。
需求评审也为风险承担者们提供了在特定问题上达成共识的方法。我的同事B a r r y曾经主持了一个包括来自四个用户代表的软件需求规格说明的评审工作。一个用户提出了一个灾难性的问题：它将使需求做重大更改。会后，需求分析员和项目经理很恼火，因为在前两个月的定义需求会议上，该用户也在场，但她却没有提出这一问题。经过一些调查之后才发现该用户已经反复提出了这个问题，但都被忽略了。在评审过程中，当许多用户一致认为这是一个严重的问题时，分析员和项目经理意识到，他们再也不能忽略这一问题了。
不同种类的技术评审具有不同的称谓。非正式评审的方法包括把工作产品分发给许多其它的开发人员粗略看一看和走过场似地检查一遍( w a l k t h r o u g h )。同时执行者描述产品，且征求意见。非正式评审对于培养其他人对产品的认识并获得非结构化的反馈是有利的，但非正式评审是非系统化的，不彻底的，或者在实施过程中具有不一致性。非正式评审不需要记录备案。
非正式评审可以根据个人爱好的方式进行评审，而正式评审则遵循预先定义好的一系列步骤过程。正式评审内容需要记录在案，它包括确定材料、评审员、评审小组对产品是否完整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题的总结。正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责（ F r e e d m a nand We i n b e rg 1990）
正式技术评审的最好类型叫作审查（ i n s p e c t i o n）（Ebenau and Strauss 1994; Gilb and
Graham 1993）。对需求文档的审查是可利用的最高级软件质量技术。一些公司已经认识到：在审查需求文档或其它软件产品上花费一个小时，可节省十个小时的工作时间（ G r a d y 1 9 9 4）。
我尚不知道有哪些其它的软件开发或质量评估可以产生十倍的回收投资比。如果你对提高软件的质量持有认真的态度，那么就审查所编写需求文档的每一行。虽然对大型的需求文档进行详细审查很无聊并且也很费时，但是我所知道的采用需求审查的人都一致认为他们所花的每一分钟都是值得的。如果你认为没有时间详细审查每个方面，那么就使用简单的风险分析模型来区分需求文档哪些部分是需要详细审查的和那些不重要部分只要用非正式评审就能满足质量要求。
在“化学制品跟踪系统”中，在每次获取需求的专题讨论会之后代表不同用户类的小组对渐增性软件需求规格说明进行非正式评审，立刻就发现了许多错误。在需求获取完成以后，由一个系统分析员把来自不同用户类的软件需求规格说明归纳在一起组成一份大约有5 0页的文档，并加上许多附录。两个分析员、一个开发人员、三个产品代表者、项目经理以及一个测试人员一起在三次长达两个小时的审查会上对软件需求规格说明进行审查。审查小组发现了2 2 3个错误，其中包括几十个重大缺陷。所有的审查员一致认为在审查会上，他们在软件需求规格说明上所花的时间（一次一个需求），从长远目标来看，节省了项目开发小组大量的时间。