软件需求规格说明书评审检查表
软件项目需求评审检查表-模板
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 结果统计
需求评审检查表
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 需求是否可追溯到设计编制：日期：审核：日期：批准：日期：。
需求评审检查表
《需求说明书》中，本系统与其它软件/硬件产品的接口是否都列出了？
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 是否对所有预期的错误条件所产生的系统行为都编制了文档?需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
检查表
编制人员： 项目名称： 检查依据：《 软件需求规格说明书模板》、《需求开发过程》
编制日期： 项目经理： 花费工作量：
序 号
问题
组织和完整性
1 所有对其它需求的内部交叉引用是否正确？
2 所有需求的编写在细节上是否都一致或者合适？
3 需求是否能为设计提供足够的基础？
4 是否包括了每个需求的实现优先级？
5 是否定义了所有外部硬件、软件和通信接口？
6 是否定义了功能需求内在的算法？
7 软件需求规格说明中是否包括了所有客户代表或系统的需求？
8 是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题。
9 是否记录了所有可能的错误条件所产生的系统行为？
正确性
10 是否有需求与其它需求相冲突或重复？
规格说明书评审
组织和完整性
检查表
编号： 编制日期： 项目经理： 花费工作量：
备注
正确性
质量属性 可跟踪性 特殊的问题
23 是否确定了对时间要求很高的功能并且定义了它们的时间标准？
24 是否已经明确地阐述了国际化问题？
25
21
22
23
24
25
结果统计
是：
0个
否：
0个
不适用：
0个
未检查：
0个
说明
检查结果
使 用 说 明 ： 本 检 查 表 在 项 目 中 各 种 评 审 、 审 计 工 作 实 施 前 编 制 ， 用 于 列 出 问 题目标？
18 是否合理地确定了安全与保密方面的考虑？
19 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？
可跟踪性
20 是否每个需求都具有唯一性并且可以正确地识别它？
21 是否可以根据高层需求（如系统需求或使用安例（用例））跟踪到软件功能需求？
特殊的问题
22 是否所有的需求都是名副其实的需求而不是设计或实现方案？
11 是否简明、简洁、无二义性地表达了每个需求？
12 是否每个需求都能通过测试、演示、审查得以验证或分析？
13 是否每个需求都在项目的范围内？
14 是否每个需求都没有内容上和语法上的错误？
15 在现有的资源限制内，是否能实现所有的需求？
16 是否任一个特定的错误信息都具有唯一性和明确的意义？
质量属性