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

合集下载

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

功能项（系统控制退票只能退回原提出行，税票只能向指定交换行提出）未在需求说明书中体现，需要补
7充
功能项（能够统计各地区、行别的资金流量流向）有
8 遗漏
功能项（根据机构代码、行别、清算行、地区代码等条件查询收费信息；根据机构代码、行别、清算行、地区代码等条件查询提出提入业务量）未在需求说明
9 书中体现，需要补充；
3306951832.xls 第2页共2页
评审准备表
项目经理角色评审检查者
QA工程师评审日期
序号
1 跨区代理问题
2020/9/23 缺陷记录
作者
记录人
缺陷总数缺陷级别提出人
一般
14 备注
多表实现。其中控制类型只允许条件是否可略去需和
2 用户确认
3
4 进行修改
补充市区操作员和各县区操作员可查询的账户信息范
5围 6 大额交易查询检测功能：用户界面项遗漏行别等字段
12 有遗漏
功能项（已存在的银行类别可以修改，如将农信社改
13 为农合行或农商行）不需要实现批量改
批量导入、导出功能。提供按机构代码、清算行行号、账号位数批量删除账户信息功能。提供账户批量迁移功能）原系统中导入Excel、批量删除功能还未实
14 现，需要补充 15
一般一般严重严重
建议
上海畅星智能系统有限公司
提供账户批量迁移功能原系统中导入excel批量删除功能还未实现需要补充功能项一台前置机支持多个清算账户未在需求说明书中体现需要补充功能项交易明细查询可以设置查询金额的范围有遗漏上海畅星智能系统有限公司第2页共5页a1299073341编号项目是否不适用说明1需求划分是否合理是2业务规则是否均有说明

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

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

在需求阶段，发现一种需求缺陷旳价值是多大呢？业内有个缺陷修复成本比例，需求阶段：设计阶段：测试阶段：上市阶段＝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 21 22 23 24 25 结果统计

需求评审检查表

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．是否文档的所有内容都跟要解决的问题相关？无关的内容都要去掉。

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

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

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

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

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

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

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

软件设计评审表模板

XXXXXXXXXXXX 单位名称软件设计评审表项目名称型号规格软件产品设计人评审人员部门职务或职称评审人员部门职务或职称评审项目概要设计说明书评审日期评审结果标记合格x 不合格TBD 待完成NA 不适用评审情况检查项：项；有效检查项：项；通过项：项；通过率：% 序号主要检查项检查结果说明标准化1 有规定的文档标识2 引用的文档现行有效3 文档编写的内容、格式符合相关标准、规定的要求4 文档签署完整完整性5 文档有独立的版本说明部分6 有文档的文字目录页7 有总体设计部分8 有功能设计9 有接口设计10 有性能设计追溯性11 设计是否可以追踪到需求12 需求是否可追溯到设计符合性13 是否每个设计都是可测试的或以别的方式可以确定的设计范围、边界是否清晰，文档中是否清晰阐明了系统14的各项特性及预期的结果15 逻辑性、算法和处理过程是否正确16 文档是否符合客户的需要17 设计是否考虑到未来的扩充性18 设计的系统是否易于维护评审项目详细设计说明书评审日期评审结果标记合格x 不合格TBD 待完成NA 不适用评审情况检查项：项；有效检查项：项；通过项：项；通过率：% 序号主要检查项检查结果说明标准化1 有规定的文档标识2 引用的文档现行有效3 文档编写的内容、格式符合相关标准、规定的要求4 文档签署完整5 设计陈述中的命名、属于和缩写是否上下文一致完整性5 文档有独立的版本说明部分6 每个设计是否都有相应的标识7 每个设计的输入/输出是否进行了描述8 关键的用户接口是否进行了描述9 用户接口是否模块化，并且修改时不影响其他程序10 是否提供了一致的错误处理机制11 各子系统、模块之间的关系是否描述得清楚12 系统的设计是否考虑了系统的可扩展性13 设计是否考虑了重用性14 重用构件是否进行了标识15 是否说明了重用模块的获得方式和相关的文档16 系统的设计是否考虑了系统的易移植性设计是否使用标准的技术，避免使用怪异的、不易理解17的方式和方法设计的调用宽度、调用深度、耦合度、内聚度和结构化18程序是否进行了描述追溯性19 设计是否可以追踪到需求20 需求是否可追溯到设计编制：日期：审核：日期：批准：日期：。

需求评审检查表

7.
《需求说明书》中，本系统与其它软件/硬件产品的接口是否都列出了？
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 是否对所有预期的错误条件所产生的系统行为都编制了文档?需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。

软件评审检查表

在体系结构设计中，是否清晰描述了数据流、控制流与接口？在体系结构设计中，是否清晰描述了数据流、控制流与接口？在设计说明书中是否描述了所有的假设、约束、决定与依赖？在设计说明书中是否描述了所有的假设、约束、决定与依赖？是否定义了目标？是否定义了目标？在合适时，是否有设计是多样的、一致的？在合适时，是否有设计是多样的、一致的？功能性对每个子模块是否都做了简要描述并概略描述了采用的算法？对每个子模块是否都做了简要描述并概略描述了采用的算法？选择的设计或算法是否满足需求？选择的设计或算法是否满足需求？接口所有接口的描述是否与需求文档一致？所有接口的描述是否与需求文档一致？在软件各个功能模块之间的数据流是否得到了明确描述？在软件各个功能模块之间的数据流是否得到了明确描述？是否对所有的元件之间的接口都进行了定义？是否对所有的元件之间的接口都进行了定义？是否接口的定义正确、合理？是否接口的定义正确、合理？是否所有的外部接口定义可以追索到需求？是否所有的外部接口定义可以追索到需求？细节 KLOC，FPA）是否每个子模块的规模都得到估计（ KLOC ， FPA ）并且是合理 1 的？是否考虑了所有可能的状态和用例？ 2 是否考虑了所有可能的状态和用例？是否描述足够详细以至于可以开始详细设计阶段？ 3 是否描述足够详细以至于可以开始详细设计阶段？九可维护性设计是否高内聚、低耦合的？ 1 设计是否高内聚、低耦合的？ 2 设计是模块化的吗？设计是模块化的吗？设计是否采用了继承，是否描述了选择的工具？ 3 设计是否采用了继承，是否描述了选择的工具？
是[1]否[ ]免[ ] 是[ ]否[1]免[ ] 是[1]否[ ]免[ ] 是[1]否[ ]免[ ] 是[ ]否[ ]免[ ] 是[ ]否[1]免[ ] 是[ ]否[ ]免[1] 是[ ]否[ ]免[ ] 是[ ]否[ ]免[1] 是[ ]否[1]免[ ] 是[ ]否[1]免[ ] 是[ ]否[1]免[ ] 是[ ]否[1]免[ ] 是[ ]否[ ]免[ ] 是[ ]否[1]免[ 是[ ]否[1]免[ 是[ ]否[1]免[ 是[ ]否[ ]免[ 是[ ]否[1]免[ 是[1]否[ ]免[ 是[ ]否[1]免[ ] ] ] ] ] ] ]

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

产品线：项目名称：版本：
技术评审
主要评审内容
类型
优先级
检查结果
是否已
上传svn
是否已基线
软件需求规格说明书
1．是否覆盖了用户提出的所有需求项，以及用户的使用场景；
完整性
高
2．是否描述了软件使用的目标环境，包括软硬件环境；
完整性、可验证性
高
3．是否清晰描述了软件系统的性能要求；
完整性、可验证性
高
4．是否明确了对用户的验收场景，验收方法；
可验证性
高
5．是否描述了各种约束条件；
可验证性
高
6．是否清楚地描述了软件系统需要做什么及不做什么；
必要性
高
7．是否前后一致，彼此不冲突；
一致性
高
8．是否用词清晰，语义是否存在有歧义的地方；
明确性
高
9．是否利于后期设计、实现、兼容、升级等；
实现性、维护性
高
10．ห้องสมุดไป่ตู้否合理分配需求优先级；
优先级
中
11．是否可以根据可以需求每个场景输出测试用例；
可验证性
中
12．是否对项目实现的可容忍缺陷针对性评估分析；
必要性
中
13．是否进行需求特性差异性分析；
可验证性
低
14．是否清楚说明了系统的每个输入、输出的格式，以及输入输出之间的对应关系。
可验证性
低
注
“检查结果”栏填写检查者给出的结果是“有”或“无”
在评审检查清单模板中，“备注”栏是对该检查项的注解

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

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

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

37 内部交叉引用是否正确、明确（读者应能在1分钟之内定位被引用的内容）？ 38 外部引用是否正确、明确（具有权限的读者应能在10分钟之内定位被引用的内容）？可追踪性 39 使用的图片是否是“嵌入型”的而不是其它如“浮于文字上方”？ 40 与需求相关的表格的使用是否符合要求（即不可以使用n (2 =< n < 全部) 个单元格描述一个需求）？其它 41 已经描述的、本文涉及的术语、定义及缩略语正确、完整？ 42 是否已可基于需求进行设计？ 43 是否已可基于需求进行系统测试方案及系统测试用例的编写？ 44 是否已可基于需求编写用户类文档（初稿）？ 45 是否考虑了初始状态和特殊状态（例如：冷启动、异常终止）？
功能需求需要满足的公共检查项 1 需求描述中是否未遗漏“业务规则”？（业务规则（或逻辑）是指操作规则，如“操作的先后次序”、“什么人在特定环境下可以进行何种操作”、合法性/一致性定义等）
2 功能需求中是否描述了必须的特殊需求？ 3 功能需求的所有输入是否都是必需的，而且足够满足执行要求操作的需要？ 4 是否详细罗列了功能需求的输出内容（如顺序、排序、结果对应的条件等）？这些结果是否都是必然的（即是否多或少了输出）？
14 对于满足软件的目标来说，功能需求是否足够？ 15 对于满足软件的目标来说，性能需求是否足够？ 16 对于满足软件的目标来说，质量属性需求是否足够？ 17 对于满足软件的目标来说，外部接口需求（外部接口需求可能单独成文。下同。评审时应一道评审）是否足够？
18 对于满足软件的目标来说，标准化要求是否足够？ 19 对于满足软件的目标来说，设计和实现于满足软件的目标来说，国际化需求是否足够？ 22 模板编写指导中列出的内容是否都有所体现？（如果文档中基本没有编写指导中列出需要考虑的内容，则该需求说明书可能是不完整的）

软件设计评审检查表

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

需求规格说明书评审确认表

□是/□否
□是/□否
是否对关键术语和缩略语进行定义和描述
□是/□否
□是/□否
所使用的术语是否和用户使用一致
□是/□否
□是/□否
需求的描述是否清晰,不含糊
□是/□否
□是/□否
是否有对整套系统进行功能概述
□是/□否
□是/□否
是否已详细说明说明了软件环境（共存的软件）和硬件环境（特定的配置）
□是/□否
□是/□否
如果有会影响实施的假设情况,是否已说明
□是/□否
□是/□否
是否已对每个业务逻辑进行输入、输出以及过程的项目说明
□是/□否
□是/□否
2.完整性
是否列出了系统所必须的依赖、假设和约束
□是/□否
□是/□否
是否对每个提交物或阶段实施都进行了需求说明
□是/□否
□是/□否
需求说明书是否已包含了主要的质量属性,例如：有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性等
□是/□否
16
文档中的描述是香完整,清晰.准确地反映用户的要求
□是/□否
□是/□否
17
所使用的数据流.数据结构等软件需求分析方法是否充分
□是/□否
□是/□否
18
图表是否清楚,在不补充说明时易于理解
□是/□否
□是/□否
19
软件需求说明中规定的约束条件或限制条件是否符合实际
□是/□否
□是/□否
20
是否有遗漏,重复或不一致的地方
需求规格说明书评审确认表
文件编号: XXX-XQPS-001
工程名称
合同编号
系统名称
业主单位

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

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

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

《软件需求规格说明书》检查单
文档组织与完整性
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. 是否确定了对时间要求高的功能并定义了它们的时限标准？。

需求规格说明评审表

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

需求评审检查单

■通过□免查□不通过
系统功能边界与分类是否正确、清晰，是否存在重复，是否符合用户需求
■通过□免查□不通过
系统功能的重要性和优先级设定是否合理
■通过□免查□不通过
系统环境定义是否完整(硬件平台与配置、操作系统、数据库系统、中间件)，是否符合用户需求
■通过□免查□不通过
设计与实现上的限制是否符合用户需求
需求评审检查单
项目名称
U型臂数字化医用X射线摄影系统
文档名称
嵌入式软件需求说明书
检查内容
检查结果
1、总体检查
是否符合公司制定的模板
■通过□免查□不通过
术语定义是否完整、清晰、符合行业规范和惯例
■通过□免查□不通过
参考资料是否完整，是否符合时效性的要求
■通过□免查□不通过
系统用户分类是否符合用户需求(用户需求包括行业标准、合同约定、目标用户群的普遍共识、目标用户的个性化需求等，下同)
系统连续运行时间假设是否符合用户需求，是否与环境相匹配
■通过□免查□不通过
系统安全方案是否完整，是否符合用户需求
■通过□免查□不通过
系统灾备方案是否符合用户需求，是否与环境相匹配
■通过□免查□不通过
系统日志功能是否符合用户需求和工程维护的需要
■通过□免查□不通过
评审组结论：（以下内容在评审会议后填写）
■通过□免查□不通过
2、功能需求的逐个检查
相关描述是否准确、易理解、无歧义（描述与描述之间是否一致）
■通过□免查□不通过
相关描述是否符合用户需求
■通过□免查□不通过
输入、输出的描述是否完整
■通过□免查□不通过
正常业务处理流程是否合理
■通过□免查□不通过

软件需求检查单

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
每一个功能用例场景描述是否全面完整？