软件项目需求评审检查表-模板

软件需求分析检查单

项目名称 XXX项目

填表人 填表日期 2023-8-12

问题检查清单 检查说明 是 否

检查需求是否完整? 需求阶段要分子阶段进行管理，在进行业务总貌梳理的时候，不要深入细节；深入细节会导致全局观念淡薄，需求总体框架出现问题。 √

检查需求的描述是否正确 正确的需求是成功的根本，对于不成熟的业务流程，在进行需求确认之前，往往需要独立的流程建造或者再造过程。这个过程是应用开发的前置工程。简单地说：就是人要首先知道人工怎么处理，才能通过设计师和程序员告诉计算机它该如何处理。 √

检查需求是否清晰 软件生命周期中，需求是整个周期的源头。良好的开端，是成功√ 的一半。需求的重要性自然不言而喻。我们知道，在软件开发过程中，只有得知了需求的精确定义，才能开展工作。比如功能方面，编辑框能支持多少位字符。性能方面，时间和容量规定等。当然还包含其他非功能，性能方面的定义。所以需求一定要清晰。

需求前后是否有矛盾 技术和需要产生矛盾往往是因为两种情况。一是需求不清晰（如细节未考虑）、或者提出的方案不合理。这种情况下，技术会对需求方的方案做补充和修缮；如果从技术角度想到更好的解决方案，也会提出来。在不影响商业价值或用户的体验的前提下，需求方大都会认同，从而解决矛盾。 √

系统的安全性如何 登陆身份验证。系统的每个功能都必须经过身份验证后才能访√ 问，没有认证的请求会被过滤掉，这是最基本的安全要求。

界面是否符合用户需求 首先要明确到底谁是使用者，要站在用户的观点和立场上来考虑设计软件。要作到这一点，必须要和用户来沟通，了解他们的需求、目标、期望和偏好等。设计者要清楚，用户之间差别很大，他们的能力各有不同。 √

1《需求规格说明书》是否评审并建立了基线?

2 是否按照测试计划时间完成用例编写?

3 需求新增和变更是否进行了对应的调整?

4 用例是否按照公司定义的模板进行编写?

5 测试用例是否覆盖了《需求规格说明书》?

6 用例编号是否和需求进行对应?

7 非功能测试需求或不可测试需求是否在用例中列出并说明?

8 用例设计是否包含了正面、反面的用例?

9 每个测试用例是否清楚的填写了测试特性、步骤、预期结果?

10 步骤/输入数据部分是否清晰，是否具备可操作性?

11 测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述?

12 测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法?是否针对需求不同部分设计使用不同设计方法?

13 重点需求用例设计至少要有三种设计方法?

14 每个测试用例是否都阐述预期结果和评估该结果的方法? 软件测试

15 需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置;表格和数据格式是否有说明或附件?

16 用例覆盖率是否达到相应质量指标?

17 用例预期缺陷率是否达到相应质量指标?

软件系统评审记录表

项目名称

项目名称 项目编号

项目经理 评审计划日期

评审组织者

评审内容 评审内容:

1.检测项目是否在本公司检测范围之内 是□ 否□

2.检测项目及其相应的要求是否口头约定后与客户确认 是□ 否□

3.检测项目及其相应的要求是否进行文字合同/协议签订 是□ 否□

4.为客户进行的检测项目是否配备正确的仪器设备 是□ 否□

5.专业技术检测人员在数量与技能方面能否满足客户要求 是□ 否□

6.实验室在现有检测工作量前提下能否按时提供检测报告 是□ 否□

7.现有的检测方法及其能否进行本项目的检测 是□ 否□

8.进行的本项检测是否符合现行的法律法规 是□ 否□

9.为客户进行的检测是否须分包检测完成 是□ 否□

10.实验室能否采用适当的方法,完成客户要求的全部检测项目 是□ 否□

11.人员技能、专业技术、检测设备、环境条件等能否满足客户的要求

是□ 否□

12.在合同期间,能否保证按时提供检测报告 是□ 否□

13.其他：请说明

评审结论 满足□ 不满足□ 部分满足□

评审人员会签

批准意见

批准人： 日期：

.WORD 完美格式编辑

技术资料 .专业整理

需求规格说明书检查表

Y: 是 TBD: 不确定 N: 不是 NA: 不适用

检查项 Y/TBD/N/NA

清晰性

系统的目标是否已定义？

是否对关键术语和缩略语进行定义和描述？

所使用的术语是否和用户 / 客户使用的一致？

需求的描述是否清晰，不含糊？

是否有对整套系统进行功能概述？

是否已详细说明了软件环境 （ 共存的软件 ） 和硬件环境 （ 特定的配置 ） ？

如果有会影响实施的假设情况，是否已经声明？

是否已经对每个业务逻辑进行输入、输出以及过程的详细说明？

完整性

是否列出了系统所必须的依赖、假设以及约束？

是否对每个提交物或阶段实施都进行了需求说明？

需求说明书是否已包括了主要的质量属性，例如有效性、高效性、灵活性、完

整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性

和可测试性。

依从性

该文档是否遵守了该项目的文档编写标准？

一致性

需求说明是否存在直接相互矛盾的条目？

本需求说明书是否与相关需求素材一致？

可行性

所描述的所有功能是否必要并充分地满足了客户 / 系统目标？

需求说明书的描述的详细程度是否足以进行详细的设计？

已知的限制（局限）是否已经详细说明？

是否已确定每个需求的优先级别？

可管理性

是否将需求分别陈述，因此它们是独立的并且是可检查的？

是否所有需求都可以回溯到相应的需求素材，反之亦然？

是否已详细说明需求变更的过程？

.WORD 完美格式编辑

技术资料 .专业整理

概要设计检查表

Y: 是 TBD: 不确定 N: 不是 NA: 不适用

检查项 Y/TBD/N/NA

清晰性

是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了？

是否所有的假设、约束、策略及依赖都被记录在本文档了？

是否定义了总体设计目标？

完整性