软件需求规格说明书评审检查表

软件需求规格说明书的评审检查单

软件需求规格阐明书旳评审检查单软件需求评审，作为一种软件产品验证旳活动之一，通过及早地从软件产品中辨认并消除缺陷，从而减少后期旳返工，加快开发进度，提高产品旳质量。

在需求阶段，发现一种需求缺陷旳价值是多大呢？业内有个缺陷修复成本比例，需求阶段：设计阶段：测试阶段：上市阶段＝N:10N:100N:1000N；方案一一、注意对需求规格阐明旳对旳性进行评审需求规格阐明旳对旳性一般可以从如下方面得以体现：1 与否有需求与其他需求互相冲突或者反复？2 与否清晰、简洁、无二义地体现了每个需求?“清晰”是让人可以读懂；“简洁”是让人乐意去读；“无二义”决定”读”旳效果,是让大家对需求描述旳理解可以达到一致。

3 与否每个需求都通过了演示、测试、评审，分析与否得到了验证?4 与否每个需求都在项目旳范畴内?5 与否每个需求都没有内容和语法上旳错误?6 在既有旳资源内, 与否能实现所有旳需求?7 每一条特定旳错误信息，与否都是唯一旳和具有含义旳?二、注意对需求规格阐明旳实践性进行评审所谓实践性是指需求自身与否来源于目前公司旳有关业务规则和文献制度,而非源于分析师们经验主义旳臆测。

实践性是判断需求规格阐明是不是理论联系实践、密切和顾客联系旳一种核心性指标。

三、注意对需求规格阐明旳完整性进行评审我们常常由下面旳问题清单来评审需求阐明书与否”完整” 。

1 编写旳所有需求，其具体限度与否一致和合适?2 需求与否能为设计提供足够旳基础?3 所有对其他需求旳内部引用与否对旳?4 与否涉及了每个需求旳实现优先级?5 与否认义了功能阐明旳内在算法?6 与否涉及了所有已知旳客户需求或系统需求?7 与否漏掉了必要旳信息?如果有漏掉旳话,把他们标记为待拟定旳问题(TBD) ?8 与否对所有预期旳错误条件所产生旳系统行为都编制了文档?需求阐明旳完整性重要体目前需求阐明旳具体限度上，我们如何判断该需求旳描述与否具体呢?我觉得需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。

软件需求检查单

3
是否合理地确定了安全与保密方面（防护性）的需求？
4
对其它相关的质量属性目标是否明确地文档化和量化，且进行了可接受的权衡也被详细说明了？
可靠性
1
是否描述了所有软件故障的原因和结果？
2
是否记录了所有可能的错误条件所产生的系统行为？
3
是否定义了防止故障或错误探查策略？
4
是否定义了修正策略？
软硬件
1
是否指明了硬件需求如内存、硬盘空间等？
4
是否有冗余的信息？
接口
1
是否对用户界面进行了说明?
2
是否对硬件接口进行了说明？
3
是否对软件接口进行了说明？
5
是否对接口的设计约束进行了说明？
6
是否对接口的安全性需求进行了说明？
7
是否对接口的可维护性需求进行了说明？
质量、性能属性
1
是否合理地定义了性能目标？
2
是否合理地确定了所有性能需求？如预期处理时间，数据传输速度等。
7
是否需求中必需的信息都没有遗漏？如果有的话，是否标记为“待决定”了？
8
在已知的约束条件下，是一个特定的错误信息都具有唯一性和明确的意义？
一致性
1
所有需求的编写在细节上是否都一致？
2
对同一对象的术语定义存在矛盾吗？
3
对同一对象的特征描述存在矛盾吗？
4
是否多个需求相互冲突？
是否所有业务属性字段都描述了约束规则？
3
非功能性需求是否有非客观的描述？
4
软件运行的环境属性是否有全面的描述？
5
每一个功能用例是否有参考UI原型？
6
每一个功能用例场景描述是否全面完整？

需求评审检查表

1．所描述的软件需求与客户需求和系统需求是否一致？
2．所规定的处理及其数据是否与必须完成的功能要求一致？
3．是否有超出范围的功能？
4．文档内部是否存在前后不一致的描述？
正确性
1．是否正确理解和描述了客户对软件的需求？所有错误是否已经排除？
明确性
1．是否存在含混、不清楚和含有二义的描述？
2．图表是否清楚？
可管理性
1．是否所有需求是以一种可管理的方式表达的？一个需求项的改变会不会影响其它很多功能？
问题
编号
问题说明和建议
（如果是针对文档中具体的内容，请标识位置）
1
2
……
n
评审检查结论
（邮件评审时填写此项）
□通过□有条件通过□不通过
说明：
需求评审检查表
项目名称
评委姓名
评审检查日期
评审检查用时（小时）
主要检查内容
意见
完整性
1．是否完整地定义了软件需求规格？
2.是否考虑了数据量和处理量？
3．是否定义了关键的接口和界面？
4．范围内的功能是否都有适当的描述？
5．在定义功能时是否考虑了异常处理ቤተ መጻሕፍቲ ባይዱ例外处理？
6．是否考虑过其它可选的软件需求？
一致性
3．某些信息是否被忽略了或有冗余？
可实施性
1．是否每一项软件需求都存在实现的可能？
2．软件设计是否可行？
3．约束条件是否现实？
4．是否考虑了实现需求的技术风险？
可追溯性
1．是否能够在后续过程中对每一项软件需求进行追溯？
2．是否需求中的每一项都能到用户问题域中找到对应？
相关性
1．是否文档的所有内容都跟要解决的问题相关？无关的内容都要去掉。

精选项目管理-需求规格说明书评审意见表

需求规格说明书评审意见表
工程名称
X市智慧城市设施建设项目
系统名称
X市城市管理部智慧化管理系统
业主单位
X市局
承建单位
山水大数据公司
监理单位
山卓检测公司
序号
评审内容
评审意见
备注
1
是否规定了用户要求的功能
是/否
2
是否在处理每个功能时，规定了时间约束、存储约束的需求
是/否
3
输入信息是否给出格式、接收方法、数量、范围、精度、时间和优先顺序要求
是/否
4
输出信息是否给出传送方法、格式、数量、范围、精度、时间和优先顺序要求，是否符合用户要求
是/否
5
是否对合法和非法输入数据的处理给出了规定
是/否
6
与硬件和其他软件的接口是否都已经描述
是/否
7
是否列举了必须的安装操作
是/否
8
是否存在技术上和经济上可行的手段对每项需求进行验证和确认
是/否
9
提供的文档资料是否齐全
是/否
10
文档中的描述是否完整、清晰、准确地反映、数据结构等软件需求分析方法是否充分
是/否
12
图表是否清楚，在不补充说明时易于理解
是/否
13
软件需求说明中规定的约束条件或限制条件是否符合实际
是/否
14
是否有遗漏、重复或不一致的地方
是/否
15
是否考虑过软件需求的其他方案
是/否
16
软件需求说明等各配置项是否按配置管理程序标识入库
是/否
承建单位：
代表签字：
年月日
监理单位：
代表签字：
年月日
建设单位：
代表签字：
年月日

软件需求规格说明书的评审检查单

软件需求规格说明书的评审检查单软件需求评审，作为一种软件产品验证的活动之一，通过及早地从软件产品中识别并消除缺陷，从而减少后期的返工，加快开发进度，提高产品的质量。

在需求阶段，发现一个需求缺陷的价值是多大呢？业内有个缺陷修复成本比例，需求阶段：设计阶段：测试阶段：上市阶段＝N：10N：100N：1000N；方案一一、注意对需求规格说明的正确性进行评审需求规格说明的正确性通常可以从如下方面得以体现：1是否有需求与其他需求相互冲突或者重复？2是否清晰、简洁、无二义地表达了每个需求?“清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果,是让大家对需求描述的理解能够达成一致。

3是否每个需求都通过了演示、测试、评审，分析是否得到了验证?4是否每个需求都在项目的范围内?5是否每个需求都没有内容和语法上的错误?6在现有的资源内,是否能实现所有的需求?7每一条特定的错误信息，是否都是唯一的和具有含义的?二、注意对需求规格说明的实践性进行评审所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。

实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。

三、注意对需求规格说明的完整性进行评审我们经常由下面的问题清单来评审需求说明书是否”完整”。

1编写的所有需求，其详细程度是否一致和合适?2需求是否能为设计提供足够的基础?3所有对其他需求的内部引用是否正确?4是否包含了每个需求的实现优先级?5是否定义了功能说明的内在算法?6是否包含了所有已知的客户需求或系统需求?7是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ?8是否对所有预期的错误条件所产生的系统行为都编制了文档?需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。

软件需求规格说明书检查单

《软件需求规格说明书》检查单
文档组织与完整性
1.所有对其它需求的内部交叉引用是否正确？
2.需求为设计提供了充足的基础么？
3. 是否所有需求的书写详细程度都是一致的、合适的？
4.是否包括了每个需求的实现优先级？
5.是否定义了所有与外部硬件、软件和通讯的接口？
6.是否定义了功能性需求内在的算法？
7.软件规格说明书是否包含了所有已知的业务需求？
8.是否记录了所有可能的错误条件所产生的系统行为？
9. 对所有内部和外部接口的描述，是否都符合模板的要求，即包括来源、目的、输入、输出和激发条件？
正确性
10. 是否没有需求间的冲突或重复的需求？
11. 是否每个需求都是无二义性的？
12. 是否每个需求的描述都是简洁、清晰的？
13. 是否每个需求都可以用测试或同级评审来进行验证？
14. 是否每个需求都在项目的范围内？
15. 是否每个需求都没有内容或语法上的错误？
16. 是否需求中必需的信息都没有遗漏？如果有的话，是否标记为“待决定”了？
17. 在已知的约束条件下，是否可以实现所有的需求？
18. 是否任一个特定的错误信息都具有唯一性和明确的意义？
质量属性
19. 对所有性能目标都作了适当的说明么？
20. 对所有安全和防护性的考虑作了适当的说明么？
21. 对其它相关的质量属性目标是否明确地文档化和量化，且进行了可接受的权衡也被详细说明了？
可追溯性
22. 每个需求的标识都是唯一和正确的么？
23. 每个软件功能需求都可追溯到客户需求么？
特殊问题
24. 是否所有需求都是名副其实的需求，而不是设计或实现方案？
25. 是否确定了对时间要求高的功能并定义了它们的时限标准？。

软件需求规格说明书的评审检查单

软件需求规格说明书的评审检查单软件需求评审，作为一种软件产品验证的活动之一，通过及早地从软件产品中识别并消除缺陷，从而减少后期的返工，加快开发进度，提高产品的质量。

在需求阶段，发现一个需求缺陷的价值是多大呢？业内有个缺陷修复成本比例，需求阶段：设计阶段：测试阶段：上市阶段＝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．是否清楚说明了系统的每个输入、输出的格式，以及输入输出之间的对应关系。
可验证性
低
注
“检查结果”栏填写检查者给出的结果是“有”或“无”
在评审检查清单模板中，“备注”栏是对该检查项的注解

软件需求开发-需求评审检查单模版

2)系统连续运行时间假设是否符合用户需求，是否与环境相匹配？
3)系统安全方案是否完整，是否符合用户需求？
4)系统灾备方案是否符合用户需求，是否与环境相匹配？
5)系统日志功能是否符合用户需求和工程维护的需要？
评审组成员会后意见：（以下内容在评审会议后填写）
评审组对本次评审结果的建议为：□通过□有条件通过□不通过
3)输入、输出的描述是否完整？
4)正常业务处理流程是否合理？
5)异常状况是否列举充分，相应的容错处理是否合理？
6பைடு நூலகம்约束条件的设定是否合理？
7)兼容性和扩展性是否得到了必要的考虑？
8)易验证性：定义的需求是否是能够得到验证的？
3.非功能需求检查
3.
1)是否对负载和环境的不同组合进行了必要的枚举，组合条件的假设是否合理，相应的系统执行效率描述是否准确、合理？
需求评审检查单
项目名称
被评审人
文档名称
版本号
评审时间
检查内容
检查结果
1.总体检查
1)是否符合公司制定的模板？
2)术语定义是否完整、清晰、符合行业规范和惯例？
3)参考资料是否完整，是否符合时效性的要求？
4)系统用户分类是否符合用户需求(用户需求包括行业标准、合同约定、目标用户群的普遍共识、目标用户的个性化需求等，下同)？
具体意见如下（如评审结果建议为“有条件通过”或“不通过”，请务必填写遗留的问题与建议）：
评审组长签名：
10)需求设计的完整性（需求定义是否包含了有关功能、性能、安全性、限制、目标、质量等方面的所有需求）？
11)是否识别并定义了在将来可能会变化的需求？
12)需求定义是否使软件的设计、实现、操作和维护都可行？

需求规格说明评审表

对设计和实现的限制是否都有了论证
是否每一个需求都只有一种解释
功能性需求是否以模块方式描述的，是否明确地标识了其功能
评审意见：通过修改后复审（问题附后）未通过
参加评审人员签年月日
研发部经理审批意见：
研发部经理（签字）：＿＿＿＿＿＿＿年月日
需求规格评审表
项目名称
评审时间
评审内容
评审结论是否通过（请以√表示）
硬件
软件
网管
软件，硬件，网管规格是否覆盖总休规格需求
软件，硬件，网管规格是否做到细化说明
硬件设计是否满足软件需求
在功能实现过程、方法和技术要求的描述上，是否背离了功能的实际要求
是否有不能理解或造成误解的描述
是否所有与需求相关的设计约束都包含了
是否所有与需求相关的硬件都被包含了
是否所有与需求相关的软件都被包含了
是否所有与需求相关的输入输出都被包含了
是否所有与需求相关的安全特性都被包含了
是否对各种操作模式（如正常、非正常、有干扰等）下的环境条件都做了规定
需求定义是否满足标准的要求
是否定义了对在错误、危险分析中所标识的各种故障模式和错误类型所需的反应

软件需求规格说明书评审检查表

软件需求规格说明书评审
编制人员：项目名称：检查依据：《软件需求规格说明书模板》、《需求开发过程》序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 问题组织和完整性所有对其它需求的内部交叉引用是否正确？所有需求的编写在细节上是否都一致或者合适？需求是否能为设计提供足够的基础？是否包括了每个需求的实现优先级？是否定义了所有外部硬件、软件和通信接口？是否定义了功能需求内在的算法？软件需求规格说明中是否包括了所有客户代表或系统的需求？是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题。是否记录了所有可能的错误条件所产生的系统行为？正确性是否有需求与其它需求相冲突或重复？是否简明、简洁、无二义性地表达了每个需求？是否每个需求都能通过测试、演示、审查得以验证或分析？是否每个需求都在项目的范围内？是否每个需求都没有内容上和语法上的错误？在现有的资源限制内，是否能实现所有的需求？是否任一个特定的错误信息都具有唯一性和明确的意义？质量属性是否合理地确定了性能目标？是否合理地确定了安全与保密方面的考虑？在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？可跟踪性是否每个需求都具有唯一性并且可以正确地识别它？是否可以根据高层需求（如系统需求或使用安例（用例））跟踪到软件功能需求？特殊的问题是否所有的需求都是名副其实的需求而不是设计或实现方案？是否确定了对时间要求很高的功能并且定义了它们的时间标准？是否已经明确地阐述了国际化问题？
检查表
编制日期：项目经理：花费工作量：检查结果
22 23 24 25 21 22 23 24 25 结果统计
是：否：不适用：未检查：说明

软件需求规格说明书评审检查单模板

是否清楚描述了系统中与其它子系统、模块或硬件设备的相关接口？
是[ ] 否[ ] NA[ ]
11
一致性
每一个需求是否切实可行、可测试、前后一致、彼此不冲突
是[ ] 否[ ] NA[ ]
12
效率
是否描述了性能需求
所描述的性能需求是否能通过测试来进行验证
是[ ] 否[ ] NA[
13
可测试性
是否每个需求都有输入和输出及相关的数据和流程及准备条件？
软件需求规格说明书评审检查单模板
项目编号
检查人
检查日期
序号
检查项
检查子项
检查结果
说明
1
布局
是否遵循了需求模板？
图片、表格等是否都有标签并正确引用？
需求是否都有分级？
是[ ] 否[ ] NA[ ]
2
跟踪性
是否所有需求都来源于用户？
是否每一个具体需求都有唯一的编号？
是[ ] 否[ ] NA[ ]
3
完整性
是否包含了所有用户需求？
是否描述了所有用户类型及其特征？
是否描述了非功能性需求？
是否包含多余的需求？
术语是否都有完整的定义？
是否说明了对每个输入的处理？
是否说明了所有对系统可能的约束？
是否有用户手册及相关培训？
是否考虑了整个生命周期的维护？
是[ ] 否[ ] NA[ ]
4
可读性
是否从设计人员、普通客户等角度都很易懂？
是[ ] 否[ ] NA[ ]
9
准确性
用语是否清晰无歧义（查找诸如也许、可能、大概、大约等关键字
是否说明了对每个输入的验证措施，并描述了每个输入的属性，如：度量单位、边界值、时序要求等

软件设计评审检查表

是否所有的界面都提供了所要求的信息
~
是否已说明内部各界面之间的关系
界面的数量和复杂程度是否已减少到最小
可维护性
该设计是否是模块化的
}
这些模块具有高内聚度和低耦合度
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明
性能
主要性能参数是否已被详细说明（例如：实时、速度要求、磁盘输入/输出接口等）
）
；
Y: 是 TBD: 不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义
、
是否对关键术语和缩略语进行定义和描述
所使用的术语是否和用户/客户使用的一致
需求的描述是否清晰，不含糊
是否有对整套系统进行功能概述
：
是否已详细说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)
完成软件确认测试说明、执行软件确认测试、进行测试分析、编写确认测试报告
完成系统测试说明、执行系统测试、进行测试分析、编写系统测试报告
正确性
是否处理所有条件（大于、等于、小于零、switch/case）是否存在处理“case not found”的条件
￥
是否正确地规定了分支（逻辑没有颠倒）
数据使用
是否所有声明的数据都被实际使用到
是否所有该单元的数据结构都被详细说明
￥
是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限
该测试计划是否充分地描述了测试基线
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用
该测试计划是否定义了足够和正确的衰退测试
^
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档

需求规格评审检查表

是
否
必要
出现在“其它需求”中的功能，是否都已在“功能需求”中进行了描述？
是
否
必要
238058842.xls
5/5
项目名称：
产品需求说明书评审检查单(V1.0)
要素代号细分要素软件需求说明书（作为一个整体）检查项 1.1 1.2 1.3 1.4 1.5 1. 标 1.6 准化 1.7 1.8 1.9 1.1 1.11 2.1 2.2 2.3 2.4 2. 完整性 2.5 2.6 是否描述了运行环境？是否描述了验收准则？语法、句法、词法、标点是否正确？是否描述了本文涉及的术语、定义及缩略语？是否按要求对版本修改情况进行了说明？图、表、列项等是否规范？引用标准/文件是否现行有效？标准/文件编号、名称是否正确？在正文中引用的标准、文件是否在执行标准一章中列出？文档格式是否满足该工程标准化模板要求？文档内容是否基本覆盖GJB438A-97的要求？修改记录内容、封面、页眉内容是否完整、一致？在“背景”中，是否已明确描述了“被描述系统”（实践中，“被描述系统”经常在变动：有时是整个软件，有时又是内部的一个小模块）？对于满足软件的目标来说，功能需求是否足够？对于满足软件的目标来说，性能需求是否足够？对于满足软件的目标来说，质量属性需求是否足够？对于满足软件的目标来说，外部接口需求（外部接口需求可能单独成文。下同。评审时应一道评审）是否足够？对于满足软件的目标来说，数据需求是否足够？
3/5
、性能、质量属性、外部接代号要素口、 7.8 其 7.9 它需 7.1 求都 7.11 要 8. 8.1 功能 8.2 需求 8.3 需要 8.4 满足 8.5 的 8.6 公共检 8.7 查 9. 性 9.1 能需 9.2 求 10. 质 10.1 量属

软件设计评审检查表

测试计划检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略？
该测试计划是否详细说明所有测试活动的顺序？
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形？
该测试计划是否为所有测试定义了成功标准？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？

软件需求规格说明书的评审检查单

软件需求规格说明书的评审检查单软件需求评审，作为一种软件产品验证的活动之一，通过及早地从软件产品中识别并消除缺陷，从而减少后期的返工，加快开发进度，提高产品的质量。

在需求阶段，发现一个需求缺陷的价值是多大呢？业内有个缺陷修复成本比例，需求阶段：设计阶段：测试阶段：上市阶段＝N：10N：100N：1000N；方案一一、注意对需求规格说明的正确性进行评审需求规格说明的正确性通常可以从如下方面得以体现：1是否有需求与其他需求相互冲突或者重复？2是否清晰、简洁、无二义地表达了每个需求?“清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果,是让大家对需求描述的理解能够达成一致。

3是否每个需求都通过了演示、测试、评审，分析是否得到了验证?4是否每个需求都在项目的范围内?5是否每个需求都没有内容和语法上的错误?6在现有的资源内,是否能实现所有的需求?7每一条特定的错误信息，是否都是唯一的和具有含义的?二、注意对需求规格说明的实践性进行评审所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。

实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。

三、注意对需求规格说明的完整性进行评审我们经常由下面的问题清单来评审需求说明书是否”完整”。

1编写的所有需求，其详细程度是否一致和合适?2需求是否能为设计提供足够的基础?3所有对其他需求的内部引用是否正确?4是否包含了每个需求的实现优先级?5是否定义了功能说明的内在算法?6是否包含了所有已知的客户需求或系统需求?7是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ?8是否对所有预期的错误条件所产生的系统行为都编制了文档?需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。

软件设计评审检查表

测试所包含的所有人员的角色和职责是否都已详细说明？
在已计划的测试人员之间是否存在进度冲突？
可追溯性
测试是否有执行/演示在适当级别的文档所说明的需求？
测试验收标准是否可追溯到更高级别的文档？
测试计划进程表
开发阶段/测试阶段
单元测试/承建方
开发组
集成测试/承建方
开发组、测试组
确认测试/承建方
测试组
系统测试/业主
该测试计划是否和更高级别的测试计划文档一致？
正确性
该测试计划的进入和退出条件是否实现？
是否所有必须的驱动程序和桩（stubs）都已被定义且可利用来测试指定的功能？
详细级别/程度
测试案例是否完整覆盖了所有功能，是否覆盖了被测试功能的正常执行情况？
测试案例集是否覆盖了足够的非法和冲突的输入？
测试案例集是否包括了足够的默认输入值的使用？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置？
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出有意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？