4.5.2　需求评审

软件的缺陷并不是在编程时才出现的，需求和设计阶段都会产生问题，缺陷发现得越早，修正得越早，所用的成本就越低；缺陷发现得越迟，成本就越高。通过产品需求的评审，更好地理解产品的功能性和非功能性需求，为制订测试计划、测试范围等提供参考。

1.评审的层次

用户的需求是可以分层次的，主要有：

（1）目标性需求：定义了整个系统需要达到的目标。

（2）功能性需求：定义了整个系统必须完成的任务。

（3）操作性需求：定义了完成每个任务的具体的人机交互。

目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的，对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。

2.正式评审与非正式评审相结合

（1）正式技术评审，也称同行评审。

（2）非正式技术评审。

正式评审是指通过开评审会的形式，组织多个专家，将需求涉及的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。非正式评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至网络聊天等多种形式对需求进行评审。两种方式各有利弊，应该更灵活运用。

3.分阶段评审

在需求形成的过程中进行分阶段评审，不是在需求最终形成后再进行评审，分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审质量。

4.评审人员

需求评审可能涉及的人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点和系统的目标有关系，有些和系统的目标关系不大，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心挑选评审员，首先要保证使不同类型的人员都要参与进来，否则很可能会漏掉很重要的需求；其次，在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际修改了系统范围。

5.建立标准的评审流程

对正规的需求评审需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程，比如，在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等。

6.做好评审后的跟踪工作

在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，并给出充分的客观理由与证据。当确定需要纠正的问题后，要形成书面的需求变更申请，进入需求变更的管理流程，并确保变更的执行。在变更完成后，要进行复审，切忌评审完毕后，没有对问题进行跟踪，否则无法保证评审结果的落实，使前期的评审努力付之东流。