文档介绍：软件需求规格说明书的评审检查单
软件需求评审，作为一种软件产品验证的活动之一，通过及早地从软件产品中识别并消除缺陷，从而减少后期的返工，加快开发进度，提高产品的质量。
在需求阶段，发现一个需求缺陷的价值是多大呢？业内有个缺陷修复成本比例,
　　需求阶段：设计阶段：测试阶段：上市阶段＝N:10N：100N：1000N；
方案一
一、注意对需求规格说明的正确性进行评审
需求规格说明的正确性通常可以从如下方面得以体现：
1 是否有需求与其他需求相互冲突或者重复？
2 是否清晰、简洁、无二义地表达了每个需求？
“清晰”是让人能够读懂;“简洁”是让人愿意去读；“无二义”决定”读”的效果，是让大家对需求描述的理解能够达成一致。
3 是否每个需求都通过了演示、测试、评审，分析是否得到了验证?
4 是否每个需求都在项目的范围内?
5 是否每个需求都没有内容和语法上的错误?
6 在现有的资源内, 是否能实现所有的需求？
7 每一条特定的错误信息，是否都是唯一的和具有含义的？
二、注意对需求规格说明的实践性进行评审
所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。
三、注意对需求规格说明的完整性进行评审
我们经常由下面的问题清单来评审需求说明书是否”完整” 。
1 编写的所有需求,其详细程度是否一致和合适？
2 需求是否能为设计提供足够的基础？
3 所有对其他需求的内部引用是否正确?
4 是否包含了每个需求的实现优先级?
5 是否定义了功能说明的内在算法？
6 是否包含了所有已知的客户需求或系统需求？
7 是否遗漏了必要的信息？如果有遗漏的话，把他们标记为待确定的问题（TBD） ?
8 是否对所有预期的错误条件所产生的系统行为都编制了文档？
需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢？我认为需求需要精化,而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应,等等。
四、注意对需求方案的可行性和成本预算进行评审
五、注意对需求的质量属性进行评审
我们需要评审需求规格说明是否合理地确定了所有的性能目标，是否合理地确定了安全性方面要考虑到的问题。
六、注意对需求的可实施性进行评审
是否对每个需求都设置了惟一性并且可以正确地识别它？是否每个功能需求都可以跟踪到高层需求（比如系统需求或用例）？
需求必须可以测试,,需求应当层次分明，需要把单个需求下面的相关需求综合在一起形成一组需求功能。
需求的可实施性除了可跟踪性还包括可测试性。事实上, 分析人员和测试人员在编写代码以前把需求模型，分析模型和测试用例综合起来通盘考虑，检查出遗漏的、错误的和不必要的需求。软件需求在概念上的测试是一种很必要的技术，它可以在项目早期阶段发现需求的歧义和错误。
七、注意对需求包含的用例文档进行评审
用例是参与者对系统和参与者的交互过程所达成的一种