文档介绍：软件需求规格说明书的评审检查单
软件需求评审，作为一种软件产品验证的活动之一，通过及早地从软件产品中识别并消除缺陷，从而 减少后期的返工，加快开发进度，提高产品的质量。
在需求阶段，发现一个需求缺陷的价值是多大呢？业内有个缺陷修复成本比 到的问题。
六、 注意对需求的可实施性进行评审
是否对每个需求都设置了惟一性并且可以正确地识别它？是否每个功能需求都可以跟踪到高层需求
（比如系统需求或用例）?
需求必须可以测试,每个需求在特定的输入条件下应当能给出已知的输出结果。同时,需求应当层次分明, 需要把单个需求下面的相关需求综合在一起形成一组需求功能。
需求的可实施性除了可跟踪性还包括可测试性。事实上, 分析人员和测试人员在编写代码以前把需求 模型,分析模型和测试用例综合起来通盘考虑，检查出遗漏的、错误的和不必要的需求。软件需求在概 念上的测试是一种很必要的技术，它可以在项目早期阶段发现需求的歧义和错误。
七、 注意对需求包含的用例文档进行评审
用例是参与者对系统和参与者的交互过程所达成的一种契约。需求说明书基于用例的分析方法是也是 当前较为流行的需求开发方式。用例文档作为需求重要的成果性文档也是需求评审主体之所在。需求 评审确认的重点是对关键用户的最常用和最重要的用例进行深入和细致的评审,首先要通过测试用例 的主干过程。而我们是否撰写有效的用例则要从以下方面着手评审。
用例的目标或价值度量是否明确?
用例是否是独立的分散任务 ?
是否明确说明可用用例会给哪些参与者带来用处?
编写用例的详细程度是否恰当? 是否有不必要的设计和实现细节?
所有预期的分支过程是否都编写了文档说明 ?
所有预估的异常过程是否都编写了文档说明 ?
是否存在一些普通的动作序列可以分解成独立的用例 ?
每个路径的步骤是否都清晰明了, 无歧义而且完整 ?
用例中的每个参与者和步骤是否都与所执行的任务有关 ?
用例中定义的每个可选路径是否都可行和可验证?
用例的前置条件和后置条件是否合理?
分析师必须确认用例的前置条件和后置条件准确界定了用例的边界范围,区分了用例和用例之间的界 限。
八、 注意需求评审会的过程和结束标准
需求评审会的结果是对需求规格书完成了评审过程,那我们又如何判断审查的结束标准呢?请看如下几 条建议:
审查期间评审员们提出的所有问题都已经解决。
相关文档中的所有更改都已经正确完成。
修订过的文档进行了拼写检查。
所有标识为 TBD（ 待确定 ） 的问题已经全部解决 , 或者已经对每个 TBD 的问题的解决过程、计划解决 的目标日期和责任解决人等编制了文档。
需求文档正式进入了配置库。
方案二
组织和完整性
* 所有需求的编写在细节上是否都一致或者合适？
* 是否包括了每个需求的实现优先级？
* 软件需求规格说明中是否包括了所有客户代表或系统的需求？
* 是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题
* 是否记录了所有可能的错误条件所产生的系统行为？
正确性
* 是否有需求与其它需求相冲突或重复？
* 是否简明、简洁、无二义性地表达每个需求的？
* 是否每个需求都能通过测试、演示、审查得以验证或分析？
* 是否任一个特定的错误信息都具有唯一性和明确的意义？
质量属性