需求说明书评审检查单

1、软件需求说明书评审检查单 归口部门： 编号： 项目名称项目编码 检查方式检查人 检查对象检查日期 指标名称需求数检查项不合格数合格率 需求说明书 需求说明书1450100.0 全部单条需 求说明 功能需求(use case)26 性能需求14 质量属性需求13 外部接口需求13 其它需求14 说明 序号软件需求说明书（作为一个整体）检查项y/n备注 标准化 1 是否描述了运行环境？ 2 是否描述了需求追踪？ 3 是否描述了验收准则？ 4 语法、句法、词法、标点是否正确？ 5 模板编写指导及示例是否都已经删除或正确沿用了？ 6 是否描述了本文涉及的术语、定义及缩略语？ 7 是否按要求对版本修改情

2、况进行了说明？ 8 图、表、列项等是否规范？ 9 引用标准/文件是否现行有效？标准/文件编号、名称是否正确？ 10 引用标准/文件的具体内容时是否写明具体章条号？ 11 在正文中引用的标准、文件是否在执行标准一章中列出？ 12 修改记录内容、封面、页眉内容是否完整、一致？ 完整性 13 在“3.1 背景”中，是否已明确描述了“被描述系统”（实践中，“被描述系统”经常 在变动：有时是整个软件，有时又是内部的一个小模块）？ 14 对于满足软件的目标来说，功能需求是否足够？ 15 对于满足软件的目标来说，性能需求是否足够？ 16 对于满足软件的目标来说，质量属性需求是否足够？ 17 对于满足软件的目

3、标来说，外部接口需求（外部接口需求可能单独成文。下同。评审时 应一道评审）是否足够？ 18 对于满足软件的目标来说，标准化要求是否足够？ 19 对于满足软件的目标来说，设计和实现上的限制是否足够？ 20 对于满足软件的目标来说，执行标准是否足够？ 21 对于满足软件的目标来说，国际化需求是否足够？ 22 模板编写指导中列出的内容是否都有所体现？（如果文档中基本没有编写指导中列出需 要考虑的内容，则该需求说明书可能是不完整的） 一致性 23 各功能需求在内容上是否一致？ 24 各性能需求在内容上是否一致？ 25 各质量属性需求在内容上是否一致？ 26 各外部接口需求在内容上是否一致？ 27 各其

4、它需求在内容上是否一致？ 28 各功能需求在内容上是否与性能需求、质量属性需求、外部接口需求、其它需求一致？ 29 各性能需求在内容上是否与功能需求、质量属性需求、外部接口需求、其它需求一致？ 30 各质量属性需求在内容上是否与功能需求、性能需求、外部接口需求、其它需求一致？ 31 各外部接口需求在内容上是否与功能需求、性能需求、质量属性需求、其它需求一致？ 32 各其它需求在内容上是否与功能需求、性能需求、质量属性需求、外部接口需求一致？ 33 对于软硬件大系统来说，软件需求是否与系统方案（或各个子系统方案）中软件部 分的内容一致？可从功能、性能、质量属性、接口等方面进行检查。 对于纯软件项

5、目来说，软件需求是否与软件系统需求论证说明？ 34 所有需求的编写在详细程度上是否都一致或合适？ 可修改性 35 变更一个需求是否不会对其它若干需求有重大影响？ 36 功能需求、性能需求、质量属性需求、外部接口需求、其它需求各自及相互间是否不存 在冗余？ 37 内部交叉引用是否正确、明确（读者应能在1分钟之内定位被引用的内容）？ 38 外部引用是否正确、明确（具有权限的读者应能在10分钟之内定位被引用的内容）？ 可追踪性 39 使用的图片是否是“嵌入型”的而不是其它如“浮于文字上方”？ 40 与需求相关的表格的使用是否符合要求（即不可以使用n (2 = n 全部) 个单元格描述 一个需求）？

6、其它 41 已经描述的、本文涉及的术语、定义及缩略语正确、完整？ 42 是否已可基于需求进行设计？ 43 是否已可基于需求进行系统测试方案及系统测试用例的编写？ 44 是否已可基于需求编写用户类文档（初稿）？ 45 是否考虑了初始状态和特殊状态（例如：冷启动、异常终止）？ 序号单条需求说明评审检查项y/n不合格需求数 功能需求、性能需求、质量属性需求、外部接口需求、其它需求都要满足的公共检查项 1 每个叶节点需求是否都有优先级？ 2 每个叶节点需求是否都有项目内唯一的标识？ 3 需求标识是否满足模板要求？ 4 每个叶节点需求是否可验证（应注意验证的代价。如果验证的代价太大，也认为是不可 验证的

7、）？ 5 需求描述是否正确？ 6 需求描述是否完整（至少应“可验证”，且描述了模板要求的所有“字段”。另外，对 所有可能出现的输入/激励都应予以定义；应对合法和非合法的输入值的响应做出规定 ；未遗漏插图、表、图示标记和参照，并且定义了使用到的术语和度量单位、取值范围 等） 7 从成本、进度、技术角度来看，需求是否可行？ 8 从市场角度来看，需求是否必要？ 9 需求描述是否清楚明确、没有歧义？ 10 需求是否注重于描述“做什么”而不是“如何做”？ 11 需求描述中是否未包含“为什么要做”的内容？（应放在“需求论证说明”中描述） 12 多条需求是否未放在一个段落中进行描述？ 功能需求需要满足的公共

8、检查项 1 需求描述中是否未遗漏“业务规则”？（业务规则（或逻辑）是指操作规则，如“操作 的先后次序”、“什么人在特定环境下可以进行何种操作”、合法性/一致性定义等） 2 功能需求中是否描述了必须的特殊需求？ 3 功能需求的所有输入是否都是必需的，而且足够满足执行要求操作的需要？ 4 是否详细罗列了功能需求的输出内容（如顺序、排序、结果对应的条件等）？这些结果 是否都是必然的（即是否多或少了输出）？ 5 是否描述了所有可能的过程（包括正常过程、可选过程及异常过程。对于ipo方式，体 现在“处理”中，可以不必显式出现“正常过程”、“可选过程”及“异常过程”这样 的字眼）？ 6 是否将需求涉及的输

9、入、输出数据的含义、类型、数据大小、格式、度量单位、精度以 及允许取值的范围的信息定义在“数据字典”（对于纯软件，含后台网管项目）或“接 口说明书”（对于前台软件）中了？ 7 需求涉及的输入、输出数据是否直接引用了“数据字典”（对于纯软件，含后台网管项 目）或“接口说明书”（对于前台软件）中的相关数据项而不是重新定义？ 使用use case描述功能需求 1 use case描述是否包含了需求标识、需求名称、需求描述、执行者、优先级、使用频度 、前置条件、后置条件、正常过程、可选过程、异常过程、特殊需求？ 2 use case描述中，前置条件、后置条件、正常过程、可选过程、异常过程、特殊需求是

10、否都进行了编号？ 3 use case描述中，前置条件、后置条件、正常过程、可选过程、异常过程、特殊需求的 编号是否满足模板要求？ 4 use case描述中，是否不存在将属于“异常过程”的内容放在了“前置条件”中了？ 5 use case描述中，异常过程中是否已经明确发生异常的位置？ 6 use case描述中，是否至少存在一个“执行者”？ 7 use case描述中，是否有“执行者”与“被描述系统”的交互（如只有“执行者”或“ 被描述系统”的活动，则该use case的描述存在问题）？ 性能需求检查项 1 性能需求描述中，是否描述“性能”对应的具体的、可验证的条件？ 2 出现在“性能需求”

11、中的功能，是否都已在“功能需求”中进行了描述？ 质量属性需求检查项 1 出现在“质量属性需求”中的功能，是否在“功能需求”中描述了？（如“安全性需求 ”要求“使用系统前必须登录”，这就涉及到登录、用户及其权限管理等功能，这些功 能应该在功能需求中已有描述。注：“可扩展性”例外：只有那些可以描述清楚的扩展 功能才放在“功能需求”中） 外部接口需求检查项 1 出现在“外部接口需求”中的功能，是否都已在“功能需求”中进行了描述？ 其它需求检查项 1 国际化需求中是否包括了语种及特定国家的特定协议的描述？ 2 出现在“其它需求”中的功能，是否都已在“功能需求”中进行了描述？ 序号审查技巧（主要为用语检查，可作为审查活动的参考） 1 鼓励采用如“总是”、“每一种”、“所有”、“没有”、“从不”等绝对或肯定的词语。 2 警惕如“当然”、“因此”、“明显”、“显然”、“必然”等词语。看到这些词语，审查员应仔细审查推断或假 定是否成立。 3 一般可将需求正文中出现的“某些”、“有时”、“常常”、“通常”、“贯常”、“经常”、“大多”、“几乎 ”、“用户友好”、“容易”、“简单”、“许多”、“最新技术”、“可接受的”、“健壮的”等视为缺陷，因 为这些词太过模糊，所描述的需求无法测试。 4 与“等”、“等等”、“诸如此类”、“依此类推”等词语相关的需求无法测试，一般应视为