1、概要设计检查表
2、需求规格说明书检查表
概要（结构）设计检查表
| 工程名称 | |||||
| 业主单位 | |||||
| 承建单位 | |||||
| 检查依据 | 1、设计方案、投标文件；2、合同；3、信息系统相关技术标准及安全规范； | ||||
| 检查类目 | 检查内容 | 检查结果 | 备注 | ||
| 清晰性 | 是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了 | ||||
| 是否所有的假设、约束、策略及依赖都被记录在本文档了 | |||||
| 是否定义了总体设计目标 | |||||
| 完整性 | 是否所有的以前的TBD（待确定条目）都已经被确定了 | ||||
| 是否设计已经可以支持本文档中遗留的TBD有可能带来的变更 | |||||
| 是否所有的TBD的影响都已经被评估了 | |||||
| 是否仍存在可能不可行的设计部分 | |||||
| 是否已记录设计时的权衡考虑？该文档是否包括了权衡选择的标准和不选择其他方案的原因 | |||||
| 依从性 | 是否遵守了项目的文档编写标准 | ||||
| 一致性 | 数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致 | ||||
| 该设计是否反映了实际操作环境（硬件、软件、支持软件） | |||||
| 可行性 | 从功能、成果、进度、预算和技术角度上看该设计是否可行 | ||||
| 是否存在错误的、缺少的或不完整的逻辑 | |||||
| 数据使用 | 所有复合数据元素、参数以及对象的概念是否都已文档化 | ||||
| 是否还有任何需要的但还没有定义的数据结构，反之亦然 | |||||
| 是否已描述最低级别数据元素？是否已详细说明取值范围 | |||||
| 功能性 | 是否对每一下级模块进行了概要算法说明 | ||||
| 所选择的设计和算法能否满足所有的需求 | |||||
| 接口 | 操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易） | ||||
| 是否已描述界面的功能特性 | |||||
| 界面是否有利于问题解决 | |||||
| 是否所有界面都互相一致，与其他模块一致，以及和更高级别文档中的需求一致 | |||||
| 是否所有界面都提供了所要求的信息 | |||||
| 是否已说明内部各界面直接的关系 | |||||
| 界面的数据和复杂程度是否已减少到最小 | |||||
| 可维护性 | 该设计是否是模块化的 | ||||
| 这些模块是否具有高内聚度和低耦合度 | |||||
| 是否已经对继承设计、代码或先前选择工具的使用进行了详细说明 | |||||
| 性能 | 主要性能参数是否已被详细说明 | ||||
| 可靠性 | 该设计是否能够提供错误检测和恢复 | ||||
| 是否已考虑非正常情况 | |||||
| 是否考虑了网络、数据安全 | |||||
| 该设计是否满足系统进行集成时所遵守的约定 | |||||
| 是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的 | |||||
| 该套系统是否能用增量型的方法来集成和测试 | |||||
| 是否各部分的设计都能追溯到需求说明书的要求 | |||||
| 是否所有的设计决策都能追溯到原来确定的权衡因素 | |||||
| 所继承设计的已知风险是否已确定和分析 | |||||
| 专家意见： | |||||
| 业主单位 代表签字： 20XX年 XX月 XX日 | 承建单位 代表签字： 20XX年 12 月 20 日 | 监理机构 代表签字： 20XX年 XX月 XX 日 | |||
需求规格说明书检查表
| 工程名称 | |||||
| 业主单位 | |||||
| 承建单位 | |||||
| 监理单位 | |||||
| 检查依据 | 1、设计方案、投标文件；2、合同；3、信息系统相关技术标准及安全规范； | ||||
| 检查项目 | 检查内容 | 检查结果 | 备注 | ||
| 清晰性 | 系统的目标是否已定义 | ||||
| 是否对关键术语缩略语进行定义和描述 | |||||
| 所使用的术语是否和用户使用的一致 | |||||
| 需求的描述是否清晰，不含糊 | |||||
| 是否对整套系统进行功能概述 | |||||
| 是否已详细说明了软件环境（共存的软件）和硬件环境（特定的配置） | |||||
| 如果有会影响实施的假设情况，是否已申明 | |||||
| 是否已经对每个业务逻辑进行输入、输出以及过程的详细说明 | |||||
| 完整性 | 是否列出了系统所必须的依赖、假设以及约束 | ||||
| 是否对每个提交物或阶段实施都进行了需求说明 | |||||
| 需求说明书是否已包括了主要的质量属性，例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性等 | |||||
| 是否有业务流程图和数据流程图 | |||||
| 是否包含接口需求 | |||||
| 依从性 | 该文档是否遵守了该项目的文档编写标准 | ||||
| 一致性 | 需求说明是否存在直接相互矛盾的条目 | ||||
| 需求说明书是否与相关需求素材一致 | |||||
| 可行性 | 所描述的功能是否必要并充分满足了用户/系统目标 | ||||
| 需求说明书的描述是否满足下一阶段设计所需 | |||||
| 已知的限制（局限）是否已经详细说明 | |||||
| 是否已确定每个需求的优先级别 | |||||
| 可管理性 | 是否将需求分别陈述，因此他们是独立的并且是可检查的 | ||||
| 是否所有需求都可以回溯到相应的需求素材，反之亦然 | |||||
| 是否已详细说明需求变更的过程 | |||||
| 专家签字： | |||||
| 承建单位 代表签字： 20XX年 XX月 XX日 | 监理机构 代表签字： 20XX年 XX 月 XX 日 | 业主单位 代表盖章： 20XX年 XX月 XX 日 | |||
