由于软件系统的复杂性，在需求分析阶段可能存在着开发方对委托方的业务需求理解不全面、不准确的情况。在这种情况下，如果不通过需求评审进行相关的质量控制，往往造成开发结果与用户需求不一致的情况。需求评审的目的在于描述评价目标。需求评审可以保证软件大可能地满足有关评价结果的所有需求，降低额外风险和未预料的成本。

　　建议依据GB/T 16260中定义的“质量特性”的一系列质量需求以及其中的一些子特性，结合实际系统，编写需求评审规范。

　　需求评审建议采用测试方依据需求评审规范对需求说明书进行审查并协调业主方完成需求说明书的评审确认，开发方的分析人员和设计人员参会协助评审工作的工作方式。

　　需求分析审查针对《**系统需求规格说明书》，主要评审其表述的清晰性、完整性、依从性、一致性、可行性、可管理性等。评审的主要内容有：

　　● 系统定义的目标是否与用户的要求一致；

　　● 系统需求分析阶段提供的文档资料是否齐全；

　　● 文档中的所有描述是否完整、清晰，准确地反映用户要求；

　　● 与所有其他系统成份的重要接口是否都已经描述；

　　● 被开发项目的数据流与数据结构是否足够、确定；

　　● 所有图表是否清楚，在不补充说明时能否理解；

　　● 主要功能是否已包括在规定的软件范围之内，是否都已充分说明；

　　● 软件的行为和它必须处理的信息、必须完成的功能是否一致；

　　● 设计的约束条件或限制条件是否符合实际；

　　● 是否考虑了开发的技术风险；

　　● 是否考虑过软件需求的其他方案；

　　● 是否考虑过将来可能会提出的软件需求；

　　● 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；

　　● 有没有遗漏、重复或不一致的地方；

　　● 用户是否审查了初步的用户手册或原型；

　　● 项目开发计划中的估算是否受到了影响。

　　为保证软件需求定义的质量，评审应由专门指定的人员负责，并按规程严格进行。评审结束，应有评审负责人的结论意见及签字。除开发方分析人员之外，业主方和测试方都应当参加评审工作。

　　需求说明书要经过严格评测，一般，评测的结果都包括了一些修改意见，待修改完成后再经评测，才可进入设计阶段。

　　在需求说明书评测结束后，测试方应将评测意见以专题报告的形式提交业主方。