| 序号 | 检查项 | Y/TBD/N/NA |
| 清晰性 | ||
| 1 | 系统的目标是否已定义？ | |
| 2 | 是否对关键术语和缩略语进行定义和描述？ | |
| 3 | 所使用的术语是否和用户/客户使用的一致？ | |
| 4 | 需求的描述是否清晰，不含糊？ | |
| 5 | 是否有对整套系统进行功能概述？ | |
| 6 | 是否已详细说明了软件环境（共存的软件）和硬件环境（特定的配置）？ | |
| 7 | 如果有会影响实施的假设情况，是否已经声明？ | |
| 8 | 是否已经对每个业务逻辑进行输入、输出以及过程的详细说明？ | |
| 完整性 | ||
| 9 | 是否列出了系统所必须的依赖、假设以及约束？ | |
| 10 | 是否对每个提交物或阶段实施都进行了需求说明？ | |
| 11 | 需求说明书是否已包括了主要的质量属性，如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性 | |
| 依从性 | ||
| 12 | 该文档是否遵守了该项目的文档编写标准？ | |
| 一致性 | ||
| 13 | 需求说明是否存在直接相互矛盾的条目？ | |
| 14 | 本需求说明书是否与相关需求素材一致？ | |
| 可行性 | ||
| 15 | 所描述的所有功能是否必要并充分地满足了客户/系统目标？ | |
| 16 | 需求说明书的描述的详细程度是否足以进行详细的设计？ | |
| 17 | 已知的（局限）是否已经详细说明？ | |
| 18 | 是否已确定每个需求的有限级别？ | |
| 可管理性 | ||
| 19 | 是否将需求分别陈述，因此它们是的并且是可检查的？ | |
| 20 | 是否所有需求都可以回溯到相应的需求素材，反之亦然？ | |
| 21 | 是否已详细说明需求变更的过程？ | |
监理工程师： 日期：下载本文
