围之内，是否都已充分说明；
软件的行为和它必须处理的信息、必须完成的功能是否一致；
设计的约束条件或限制条件是否符合实际；
是否考虑了开发的技术风险；
是否考虑过软件需求的其它方案；
是否考虑过将来可能会提出的软件需求；
是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
有没有遗漏，重复或不一致的地方；
用户是否审查了初步的用户手册或原型；
项目开发计划中的估算是否受到了影响。
四、需求说明书评审检查
|
＃ |
检查项 |
Y/TBD/N/NA |
|
|
清晰性 |
|
|
|
系统的目标是否已定义？ |
|
|
|
是否对关键术语和缩略语进行定义和描述？ |
|
|
|
所使用的术语是否和用户/客户使用的一致？ |
|
|
|
需求的描述是否清晰，不含糊？ |
|
|
|
是否有对整套系统进行功能概述？ |
|
|
|
是否已详细说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？ |
|
|
|
如果有会影响实施的假设情况，是否已经声明？ |
|
|
|
是否已经对每个业务逻辑进行输入、输出以及过程的详细说明？ |
|
|
|
完整性 |
|
|
|
是否列出了系统所必须的依赖、假设以及约束？ |
|
|
|
是否对每个提交物或阶段实施都进行了需求说明？ |
|
|
|
需求说明书是否已包括了主要的质量属性，例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性。 |
|
|
|
依从性 |
|
|
|
该文档是否遵守了该项目的文档编写标准？ |
|
|
|
一致性 |
|
|
|
需求说明是否存在直接相互矛盾的条目？ |
|
|
|
本需求说明书是否与相关需求素材一致？ |
|
|
|
可行性 |
|
|
|
所描述的所有功能是否必要并充分地满足了客户/系统目标？ |
|
|
|
需求说明书的描述的详细程度是否足以进行详细的设计？ |
|
|
|
已知的限制（局限）是否已经详细说明？ |
|
|
|
是否已确定每个需求的优先级别？ |
|
|
|
可管理性 |
|
|
|
是否将需求分别陈述，因此它们是独立的并且是可检查的？ |
|
|
|
是否所有需求都可以回溯到相应的需求素材，反之亦然？ |
|
|
|
是否已详细说明需求变更的过程？ |
|
在需求说明书评审结束后，监理单位应将评审意见以专题监理报告形式提交业主单位。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
