软件需求规格说明书评审检查表
软件需求规格说明书的评审检查单
软件需求规格阐明书旳评审检查单软件需求评审，作为一种软件产品验证旳活动之一，通过及早地从软件产品中辨认并消除缺陷，从而减少后期旳返工，加快开发进度，提高产品旳质量。
在需求阶段，发现一种需求缺陷旳价值是多大呢？业内有个缺陷修复成本比例，需求阶段：设计阶段：测试阶段：上市阶段＝N:10N:100N:1000N；方案一一、注意对需求规格阐明旳对旳性进行评审需求规格阐明旳对旳性一般可以从如下方面得以体现：1 与否有需求与其他需求互相冲突或者反复？2 与否清晰、简洁、无二义地体现了每个需求?“清晰”是让人可以读懂；“简洁”是让人乐意去读；“无二义”决定”读”旳效果,是让大家对需求描述旳理解可以达到一致。
3 与否每个需求都通过了演示、测试、评审，分析与否得到了验证?4 与否每个需求都在项目旳范畴内?5 与否每个需求都没有内容和语法上旳错误?6 在既有旳资源内, 与否能实现所有旳需求?7 每一条特定旳错误信息，与否都是唯一旳和具有含义旳?二、注意对需求规格阐明旳实践性进行评审所谓实践性是指需求自身与否来源于目前公司旳有关业务规则和文献制度,而非源于分析师们经验主义旳臆测。
实践性是判断需求规格阐明是不是理论联系实践、密切和顾客联系旳一种核心性指标。
三、注意对需求规格阐明旳完整性进行评审我们常常由下面旳问题清单来评审需求阐明书与否”完整” 。
1 编写旳所有需求，其具体限度与否一致和合适?2 需求与否能为设计提供足够旳基础?3 所有对其他需求旳内部引用与否对旳?4 与否涉及了每个需求旳实现优先级?5 与否认义了功能阐明旳内在算法?6 与否涉及了所有已知旳客户需求或系统需求?7 与否漏掉了必要旳信息?如果有漏掉旳话,把他们标记为待拟定旳问题(TBD) ?8 与否对所有预期旳错误条件所产生旳系统行为都编制了文档?需求阐明旳完整性重要体目前需求阐明旳具体限度上，我们如何判断该需求旳描述与否具体呢?我觉得需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。
软件需求检查单
是否合理地确定了安全与保密方面（防护性）的需求？
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
每一个功能用例场景描述是否全面完整？
需求评审检查表
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．是否清楚说明了系统的每个输入、输出的格式，以及输入输出之间的对应关系。
可验证性
低
注
“检查结果”栏填写检查者给出的结果是“有”或“无”
在评审检查清单模板中，“备注”栏是对该检查项的注解
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
编制人员： 项目名称： 检查依据：《 软件需求规格说明书模板》、《需求开发过程》 序号 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 结果统计
是： 否： 不适用： 未检查： 说明
0 0 0 0
个 个 个 个
使用说明： 本检查表在项目中各种评审、审计工作实施前编制，用于列出问题、记录结果。
规格说明书审
检查表
编号： 编制日期： 项目经理： 花费工作量： 备注