需求开发同级评审检查单
合集下载
需求评审检查表
7.
《需求说明书》中，本系统与其它软件/硬件产品的接口是否都列出了？
8.
每个需求都是可测试和可验证的吗？
9.
是否清晰地描述了限制条件？
10.
需求中有没有描述对异常情况的处理方法？
11.
需求中是否详细描述了性能需求？是否可测量？对每一个性能标准，是否定义了偏差范围（如果需要的话）？
12.
是否详细说明了用户界面（如果有的话）设计要考虑的因素？
需求评审检查表
评审对象
作者
序号
《需求说明书》检查项
评审意见
1.
《需求说明书》包括了合同中提到的需求吗？
2.
在需求中有无不一致或冲突的地方？
3.
有模糊不清的地方吗？
4.有不适当的ຫໍສະໝຸດ 设条件吗？5.还有没有描述的假设条件吗？
6.
《需求说明书》是否包括其他相关内容（如：与性能、安全性、可靠性、保密性、法律法规、标准等相关的需求）？如果是，描述的这些需求是否是可度量的，这样在产品交付给客户时是可验证的。
13.
是否详细说明了在系统输出一致性上的考虑事项？
14.
是否明确了硬件/软件的运行环境？
15.
是否描述了系统可靠性（期望的正常运行时间）方面的要求？
16.
需求中是否说明了系统的可维护性方面的要求（如：纠错需要的平均时间）？
17.
需求中是否描述了系统安全性方面的要求？
提示：以上检查项列表是个通用列表，某些问题可能不能应用到项目当前的软件工程中，请忽略那些不适用的检查项。
《需求说明书》中，本系统与其它软件/硬件产品的接口是否都列出了？
8.
每个需求都是可测试和可验证的吗？
9.
是否清晰地描述了限制条件？
10.
需求中有没有描述对异常情况的处理方法？
11.
需求中是否详细描述了性能需求？是否可测量？对每一个性能标准，是否定义了偏差范围（如果需要的话）？
12.
是否详细说明了用户界面（如果有的话）设计要考虑的因素？
需求评审检查表
评审对象
作者
序号
《需求说明书》检查项
评审意见
1.
《需求说明书》包括了合同中提到的需求吗？
2.
在需求中有无不一致或冲突的地方？
3.
有模糊不清的地方吗？
4.有不适当的ຫໍສະໝຸດ 设条件吗？5.还有没有描述的假设条件吗？
6.
《需求说明书》是否包括其他相关内容（如：与性能、安全性、可靠性、保密性、法律法规、标准等相关的需求）？如果是，描述的这些需求是否是可度量的，这样在产品交付给客户时是可验证的。
13.
是否详细说明了在系统输出一致性上的考虑事项？
14.
是否明确了硬件/软件的运行环境？
15.
是否描述了系统可靠性（期望的正常运行时间）方面的要求？
16.
需求中是否说明了系统的可维护性方面的要求（如：纠错需要的平均时间）？
17.
需求中是否描述了系统安全性方面的要求？
提示：以上检查项列表是个通用列表，某些问题可能不能应用到项目当前的软件工程中，请忽略那些不适用的检查项。
软件需求规格说明书的评审检查单
软件需求规格说明书的评审检查单软件需求评审，作为一种软件产品验证的活动之一，通过及早地从软件产品中识别并消除缺陷，从而减少后期的返工，加快开发进度，提高产品的质量。
在需求阶段，发现一个需求缺陷的价值是多大呢？业内有个缺陷修复成本比例，需求阶段：设计阶段：测试阶段：上市阶段＝N:10N:100N:1000N；方案一一、注意对需求规格说明的正确性进行评审需求规格说明的正确性通常可以从如下方面得以体现：1 是否有需求与其他需求相互冲突或者重复？2 是否清晰、简洁、无二义地表达了每个需求?“清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果,是让大家对需求描述的理解能够达成一致。
3 是否每个需求都通过了演示、测试、评审，分析是否得到了验证?4 是否每个需求都在项目的范围内?5 是否每个需求都没有内容和语法上的错误?6 在现有的资源内, 是否能实现所有的需求?7 每一条特定的错误信息，是否都是唯一的和具有含义的?二、注意对需求规格说明的实践性进行评审所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。
实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。
三、注意对需求规格说明的完整性进行评审我们经常由下面的问题清单来评审需求说明书是否”完整” 。
1 编写的所有需求，其详细程度是否一致和合适?2 需求是否能为设计提供足够的基础?3 所有对其他需求的内部引用是否正确?4 是否包含了每个需求的实现优先级?5 是否定义了功能说明的内在算法?6 是否包含了所有已知的客户需求或系统需求?7 是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ?8 是否对所有预期的错误条件所产生的系统行为都编制了文档?需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。
软件需求规格说明书评审检查清单
产品线：项目名称：版本：
技术评审
主要评审内容
类型
优先级
检查结果
是否已
上传svn
是否已基线
软件需求规格说明书
1．是否覆盖了用户提出的所有需求项，以及用户的使用场景；
完整性
高
2．是否描述了软件使用的目标环境，包括软硬件环境；
完整性、可验证性
高
3．是否清晰描述了软件系统的性能要求；
完整性、可验证性
高
4．是否明确了对用户的验收场景，验收方法；
可验证性
高
5．是否描述了各种约束条件；
可验证性
高
6．是否清楚地描述了软件系统需要做什么及不做什么；
必要性
高
7．是否前后一致，彼此不冲突；
一致性
高
8．是否用词清晰，语义是否存在有歧义的地方；
明确性
高
9．是否利于后期设计、实现、兼容、升级等；
实现性、维护性
高
10．ห้องสมุดไป่ตู้否合理分配需求优先级；
优先级
中
11．是否可以根据可以需求每个场景输出测试用例；
可验证性
中
12．是否对项目实现的可容忍缺陷针对性评估分析；
必要性
中
13．是否进行需求特性差异性分析；
可验证性
低
14．是否清楚说明了系统的每个输入、输出的格式，以及输入输出之间的对应关系。
可验证性
低
注
“检查结果”栏填写检查者给出的结果是“有”或“无”
在评审检查清单模板中，“备注”栏是对该检查项的注解
技术评审
主要评审内容
类型
优先级
检查结果
是否已
上传svn
是否已基线
软件需求规格说明书
1．是否覆盖了用户提出的所有需求项，以及用户的使用场景；
完整性
高
2．是否描述了软件使用的目标环境，包括软硬件环境；
完整性、可验证性
高
3．是否清晰描述了软件系统的性能要求；
完整性、可验证性
高
4．是否明确了对用户的验收场景，验收方法；
可验证性
高
5．是否描述了各种约束条件；
可验证性
高
6．是否清楚地描述了软件系统需要做什么及不做什么；
必要性
高
7．是否前后一致，彼此不冲突；
一致性
高
8．是否用词清晰，语义是否存在有歧义的地方；
明确性
高
9．是否利于后期设计、实现、兼容、升级等；
实现性、维护性
高
10．ห้องสมุดไป่ตู้否合理分配需求优先级；
优先级
中
11．是否可以根据可以需求每个场景输出测试用例；
可验证性
中
12．是否对项目实现的可容忍缺陷针对性评估分析；
必要性
中
13．是否进行需求特性差异性分析；
可验证性
低
14．是否清楚说明了系统的每个输入、输出的格式，以及输入输出之间的对应关系。
可验证性
低
注
“检查结果”栏填写检查者给出的结果是“有”或“无”
在评审检查清单模板中，“备注”栏是对该检查项的注解
评审检查单
评审意见/建议 1 2 3 4 5 6 7 8
2.完整性、正确性 1 所有的图表都定义标签了吗？ 2 所有的图表都前后对应吗？ 3 有被遗漏的信息吗？ 4 是否每个需求都在项目的范围内？ 5 是否有的需求应该描述的更详细些？ 6 是否有的需求应该描述得更简略些？ 7 是否包含了所有的功能需求？ 8 是否合理地确定了所有性能需求？ 9 是否定义了主要的数据？ 10 需求是否能为设计提供足够的基础？ 11 是否识别了设计约束？ 12 是否对假设条件进行了说明？ 3 是否定义了可维护行需求？ 4 是否定义了安全保密性需求？ 5 是否定义了安装需求？ 6 是否定义了局限性？ 4. 一致性 1 对同一对象的术语定义存在矛盾吗？ 2 对同一对象的特征描述存在矛盾吗？ 3 是否多个需求相互冲突？ 5.可追踪性、可验证 1 是否所有的需求都可追溯到一条特定的客户需求？ 2 是否所有的需求都可向前追踪到一个特定的设计文档？ 3 是否所有的需求都可向前追踪到一个特定的软件模块？ 4 是否所有的需求都能实现？ 5 是否每个需求都是可测试的？
软件需求 检查单 评审人 文档编号 文档版本 结 论 检查日期 检查工时 统 计
通过 未通过 0 0 检查条目
不适用 0 28
1. 清晰性 1 2 3 4 对需求的描述是否易于理解？ 是否存在有二义性的需求？ 是否定义了术语表，对特定含义的术语给予了定义？ 最终产品的每个特征是用唯一的术语描述的吗？
6. 接口 1 2 3 4 5 6 7 是否对用户界面进行了说明? 是否对硬件接口进行了说明？ 是否对软件接口进行了说明？ 是否对通讯接口进行了说明？ 是否对接口的设计约束进行了说明？ 是否对接口的安全性需求进行了说明？ 是否对接口的可维护性需求进行6 7 是否指明了内存需求？ 是否指明了硬盘需求? 是否对要求的软件环境/操作系统进行了说明？ 是否说明了需要购买的软件？ 是否给出了要求的或估计的网络吞吐率？ 是否定义了预期的处理时间？ 是否定义了数据传输速度？
软件需求开发-需求评审检查单模版
2)系统连续运行时间假设是否符合用户需求，是否与环境相匹配？
3)系统安全方案是否完整，是否符合用户需求？
4)系统灾备方案是否符合用户需求，是否与环境相匹配？
5)系统日志功能是否符合用户需求和工程维护的需要？
评审组成员会后意见：（以下内容在评审会议后填写）
评审组对本次评审结果的建议为：□通过□有条件通过□不通过
3)输入、输出的描述是否完整？
4)正常业务处理流程是否合理？
5)异常状况是否列举充分，相应的容错处理是否合理？
6பைடு நூலகம்约束条件的设定是否合理？
7)兼容性和扩展性是否得到了必要的考虑？
8)易验证性：定义的需求是否是能够得到验证的？
3.非功能需求检查
3.
1)是否对负载和环境的不同组合进行了必要的枚举，组合条件的假设是否合理，相应的系统执行效率描述是否准确、合理？
需求评审检查单
项目名称
被评审人
文档名称
版本号
评审时间
检查内容
检查结果
1.总体检查
1)是否符合公司制定的模板？
2)术语定义是否完整、清晰、符合行业规范和惯例？
3)参考资料是否完整，是否符合时效性的要求？
4)系统用户分类是否符合用户需求(用户需求包括行业标准、合同约定、目标用户群的普遍共识、目标用户的个性化需求等，下同)？
具体意见如下（如评审结果建议为“有条件通过”或“不通过”，请务必填写遗留的问题与建议）：
评审组长签名：
10)需求设计的完整性（需求定义是否包含了有关功能、性能、安全性、限制、目标、质量等方面的所有需求）？
11)是否识别并定义了在将来可能会变化的需求？
12)需求定义是否使软件的设计、实现、操作和维护都可行？
3)系统安全方案是否完整，是否符合用户需求？
4)系统灾备方案是否符合用户需求，是否与环境相匹配？
5)系统日志功能是否符合用户需求和工程维护的需要？
评审组成员会后意见：（以下内容在评审会议后填写）
评审组对本次评审结果的建议为：□通过□有条件通过□不通过
3)输入、输出的描述是否完整？
4)正常业务处理流程是否合理？
5)异常状况是否列举充分，相应的容错处理是否合理？
6பைடு நூலகம்约束条件的设定是否合理？
7)兼容性和扩展性是否得到了必要的考虑？
8)易验证性：定义的需求是否是能够得到验证的？
3.非功能需求检查
3.
1)是否对负载和环境的不同组合进行了必要的枚举，组合条件的假设是否合理，相应的系统执行效率描述是否准确、合理？
需求评审检查单
项目名称
被评审人
文档名称
版本号
评审时间
检查内容
检查结果
1.总体检查
1)是否符合公司制定的模板？
2)术语定义是否完整、清晰、符合行业规范和惯例？
3)参考资料是否完整，是否符合时效性的要求？
4)系统用户分类是否符合用户需求(用户需求包括行业标准、合同约定、目标用户群的普遍共识、目标用户的个性化需求等，下同)？
具体意见如下（如评审结果建议为“有条件通过”或“不通过”，请务必填写遗留的问题与建议）：
评审组长签名：
10)需求设计的完整性（需求定义是否包含了有关功能、性能、安全性、限制、目标、质量等方面的所有需求）？
11)是否识别并定义了在将来可能会变化的需求？
12)需求定义是否使软件的设计、实现、操作和维护都可行？
软件设计与开发评审检查表
软件概要设计
无
完成软件集成测试计划
开始设计确认测试用例、编写确认测试说明
开始设计系统测试用例、编写系统测试说明
软件详细设计
完成软件单元测试计划
开始设计集成测试用例、编写集成测试说明
软件编码
编写软件单元测试说明、执行软件单元测试、编写软件单元测试报告
软件测试
无
完成集成测试说明、执行集成测试、进行测试分析、编写软件集成测试报告
所选择的设计和算法能否满足所有的需求
接口
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
是否已描述界面的功能特性
界面将有利于问题解决吗
是否所有界面都互相一致，与其它模块一致，以及和更高级别文档中的需求一致
是否所有的界面都提供了所要求的信息
是否已说明内部各界面之间的关系
界面的数量和复杂程度是否已减少到最小
测试案例集是否考虑到了足够数量的程序错误路径
易测性/可行性
测试方法是否可行
是否所有被认为不可测的需求都被详细说明并说明原因
是否对获得测试软件、方法和工具分配了足够的时间并形成了进度计划
测试所要求的资源是否已经详细说明和估计
对于多次的构建（builds），是否已在前一构建的基础上确定所有的需求
测试所包含的所有人员的角色和职责是否都已详细说明
该设计是否反映了实际操作环境（硬件、软件、支持软件）
可行性
从进度、预算和技术角度上看该设计是否可行
是否存在错误的、缺少的或不完整的逻辑
数据使用
所有复合数据元素、参数以及对象的概念是否都已文档化
是否还有任何需要的但还没有定义的数据结构，反之亦然
是否已描述最低级别数据元素是否已详细说明取值范围
无
完成软件集成测试计划
开始设计确认测试用例、编写确认测试说明
开始设计系统测试用例、编写系统测试说明
软件详细设计
完成软件单元测试计划
开始设计集成测试用例、编写集成测试说明
软件编码
编写软件单元测试说明、执行软件单元测试、编写软件单元测试报告
软件测试
无
完成集成测试说明、执行集成测试、进行测试分析、编写软件集成测试报告
所选择的设计和算法能否满足所有的需求
接口
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
是否已描述界面的功能特性
界面将有利于问题解决吗
是否所有界面都互相一致，与其它模块一致，以及和更高级别文档中的需求一致
是否所有的界面都提供了所要求的信息
是否已说明内部各界面之间的关系
界面的数量和复杂程度是否已减少到最小
测试案例集是否考虑到了足够数量的程序错误路径
易测性/可行性
测试方法是否可行
是否所有被认为不可测的需求都被详细说明并说明原因
是否对获得测试软件、方法和工具分配了足够的时间并形成了进度计划
测试所要求的资源是否已经详细说明和估计
对于多次的构建（builds），是否已在前一构建的基础上确定所有的需求
测试所包含的所有人员的角色和职责是否都已详细说明
该设计是否反映了实际操作环境（硬件、软件、支持软件）
可行性
从进度、预算和技术角度上看该设计是否可行
是否存在错误的、缺少的或不完整的逻辑
数据使用
所有复合数据元素、参数以及对象的概念是否都已文档化
是否还有任何需要的但还没有定义的数据结构，反之亦然
是否已描述最低级别数据元素是否已详细说明取值范围
《需求开发与管理检查单》
说明： 1、本检查单在需求开发结束/项目结束之后由QA进行检查。 2、工作产品中空白的sheet必须删除。 3、 不需填写 需要填写 自动计算出的结果 4、检查“结果”栏的内容有三种：“是”、“否”，“免”。“是”表示符合，“否”表示不符合，“免”表示 不适用或不需检查。
单
0 0
备注
”表示符合，“否”表示不符合，“免”表示
需求开发与管理检查单
项目名称 项目编号 项目级别 项目经理 检 查人 检查日期 说 明 序号 1 2 3 4 5 6 8 9 10 11 12 13 14 15 16 17 18 24 25 检查大类 检查项 总项数 符合项数 不符合项数 NA项数 符合度
结果
Байду номын сангаас
是否已制订需求开发阶段计划？ 通过沟通了解项目组是否明确了需求获取的信息 内容、来源与渠道？ 需求获取 项目组是否采用了至少一种需求获取技术获取相 关的需求？是否形成了相关的资料与记录？ 是否根据需求获取的结果编制了《用户需求说明 书》？ 项目经理是否组织进行了软件需求分析工作？ 需求分析是否采取了相关的分析方法？ 需求分析与 需求分析师是否为每一个软件需求分配了一个需 定义 求编号？且该编号是唯一的。 是否根据规定的标准确定了需求的优先级？ 是否编制形成了《软件需求规格说明书》？ 是否提出了需求技术评审会议申请 评审通过后，是否采用了适当的方式获得了客户 与关联项目组的需求确认？ 需求确认 是否在需求评审通过后建立了需求跟踪矩阵？ 项目经理是否指定人员对需求跟踪矩阵进行了个 人复查？ 需求的变更是否提出了申请？ 发生需求变更后，是否同步更新了需求文档？ 需求变更与 每次需求变更完成后，是否对需求跟踪矩阵进行 跟踪 了修改？ 在项目的每个阶段产品完成后，是否由项目的相 关人员补充填写了需求跟踪矩阵的相应内容？ 完整性、规 是否遵循标准的软件需求规格说明书模板 范性 是否遵循需求开发与管理的其他模板
需求管理过程检查单
项目名称
需求管理过程检查单
检查项
检查要素
1）是否已接到《研发任务书》、《用户需求规格书》、UI资料等立项输出文件 需求确认
2）项目经理应组织项目组成员与产品经理针对用户的需求进行确认；确认的方式可以 是评审、电话沟通、会议形式等。 3）是否组织小组成员对需求进行分析，建立系统的逻辑模型，明确产品的需求及对产 品组件的要求；
相关文档、《需求跟踪矩阵》 14）需求的变更若引起基线的重新发布，是否根据基线发布的要求进行
15）在项目的每个阶段产品完成后，相关人员维护了《需求跟踪矩阵》
检查结果统计
意见与建议
检查单
参考文件
责任人 是/否/不适用
项目经理 项目经理 项目小组 项目经理 项目小组 项目经理 项目小组/业
务组长 项目经理
项目经理
项目经理
配置管理员
项目经理
项目经理 业务组长
项目经理 项目小组
项目经理 研发管理员
项目经理 业务组长
符合项
0
不符合项
0
不适用
0
《需求管理控制程序》
检查说明
裁剪说明
9）《产品需求规格说明书》是否依据评审报告进行改，评审通过后是否进行签批
10）是否在产品需求评审通过后建立了正确的需求基线，《产品需求规格说明书》是否 纳入配置库管理 11）是否在产品需求评审通过后建立了《需求跟踪矩阵》，并纳入配置管理
12）需求的变更是否遵循《变更控制程序》 需求管理 13）若接受需求变更，是否更新《项目进度计划》、概要设计、详细设计、接口设计等
4）是否依据需求分析，编制《产品需求规格说明书》
5）是否编制分系统的需求规格说明书如《软件需求规格说明书》、《硬件需求规格说 明书》《结构需求规格说明书》 需求分析 6）《产品需求规格说明书》内容是否完整，是否与《用户需求规格说明书》一致或有 所扩展,能够涵盖客户所需的要求
需求管理过程检查单
检查项
检查要素
1）是否已接到《研发任务书》、《用户需求规格书》、UI资料等立项输出文件 需求确认
2）项目经理应组织项目组成员与产品经理针对用户的需求进行确认；确认的方式可以 是评审、电话沟通、会议形式等。 3）是否组织小组成员对需求进行分析，建立系统的逻辑模型，明确产品的需求及对产 品组件的要求；
相关文档、《需求跟踪矩阵》 14）需求的变更若引起基线的重新发布，是否根据基线发布的要求进行
15）在项目的每个阶段产品完成后，相关人员维护了《需求跟踪矩阵》
检查结果统计
意见与建议
检查单
参考文件
责任人 是/否/不适用
项目经理 项目经理 项目小组 项目经理 项目小组 项目经理 项目小组/业
务组长 项目经理
项目经理
项目经理
配置管理员
项目经理
项目经理 业务组长
项目经理 项目小组
项目经理 研发管理员
项目经理 业务组长
符合项
0
不符合项
0
不适用
0
《需求管理控制程序》
检查说明
裁剪说明
9）《产品需求规格说明书》是否依据评审报告进行改，评审通过后是否进行签批
10）是否在产品需求评审通过后建立了正确的需求基线，《产品需求规格说明书》是否 纳入配置库管理 11）是否在产品需求评审通过后建立了《需求跟踪矩阵》，并纳入配置管理
12）需求的变更是否遵循《变更控制程序》 需求管理 13）若接受需求变更，是否更新《项目进度计划》、概要设计、详细设计、接口设计等
4）是否依据需求分析，编制《产品需求规格说明书》
5）是否编制分系统的需求规格说明书如《软件需求规格说明书》、《硬件需求规格说 明书》《结构需求规格说明书》 需求分析 6）《产品需求规格说明书》内容是否完整，是否与《用户需求规格说明书》一致或有 所扩展,能够涵盖客户所需的要求
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
完备
需求规格说明书中是否遗漏一些必要的需求？是否忽视了其它一些不起眼的但却是必需的功能？
可实现
需求规格说明书中的各项需求对开发方而言是否都是可实现的（Attainable）？“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。
可验证
需求规格说明书中的各项需求对用户方而言是否都是可验证的（Verifiable）？如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。
确定优先级
需求规格说明书是否对需求进行“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。
阐述“做什么”而不是“怎么做”
需求规格说明书的重点是否在阐述“做什么”，而不是阐述“怎么做”？“怎么做”是系统设计和实现阶段的事情。
需求开发同级评审检查单
项目名称
检查日期
检查人员
检查项状态标记
O合格、X不合格、明
是否检查
规范性
需求规格说明书是否按照CMMI模板文档进行编写？
正确
需求规格说明书应当正确地反映用户的真实意图，需求文档是否明确写明“要什么”和“不要什么”。需求规格说明书的每一部分都已与客户进行需求确认。
清楚
文档的结构、段落是否清晰？上下文是否连贯？
文档的语句是否含糊其词、简洁、明了？
文档描述的需求是否需要较难读懂？
无二
义性
每个需求只有唯一的含义。对于不同的人是否可能有不同的理解？以避免人们误解需求而开发出偏离需求的产品。
一致
各个需求之间是否发生矛盾？矛盾常常潜伏在需求文档的上下文中。
必要
需求规格说明书中的各项需求对用户而言应当都是必要的？是必须要实现的，而不是“画蛇添足”或“锦上添花”。
需求规格说明书中是否遗漏一些必要的需求？是否忽视了其它一些不起眼的但却是必需的功能？
可实现
需求规格说明书中的各项需求对开发方而言是否都是可实现的（Attainable）？“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。
可验证
需求规格说明书中的各项需求对用户方而言是否都是可验证的（Verifiable）？如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。
确定优先级
需求规格说明书是否对需求进行“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。
阐述“做什么”而不是“怎么做”
需求规格说明书的重点是否在阐述“做什么”，而不是阐述“怎么做”？“怎么做”是系统设计和实现阶段的事情。
需求开发同级评审检查单
项目名称
检查日期
检查人员
检查项状态标记
O合格、X不合格、明
是否检查
规范性
需求规格说明书是否按照CMMI模板文档进行编写？
正确
需求规格说明书应当正确地反映用户的真实意图，需求文档是否明确写明“要什么”和“不要什么”。需求规格说明书的每一部分都已与客户进行需求确认。
清楚
文档的结构、段落是否清晰？上下文是否连贯？
文档的语句是否含糊其词、简洁、明了？
文档描述的需求是否需要较难读懂？
无二
义性
每个需求只有唯一的含义。对于不同的人是否可能有不同的理解？以避免人们误解需求而开发出偏离需求的产品。
一致
各个需求之间是否发生矛盾？矛盾常常潜伏在需求文档的上下文中。
必要
需求规格说明书中的各项需求对用户而言应当都是必要的？是必须要实现的，而不是“画蛇添足”或“锦上添花”。