
| 评审角色 | 评审关注重点 |
| 项目经理 | 所有。 |
| 业务需求专家/方案结构设计师/技术经理/开发工程师代表 | 实现要求、基本要求、接口要求 |
| 测试经理/测试工程师代表 | 实现要求、基本要求、接口要求 |
| 用户代表 | 基本要求 |
| QA工程师 | 规范要求 |
| 检查号 | 检查项分类 | 检查项 |
| 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 | 实现要求 | 需求是否可设计、可实现? |
| 26 | 需求是否充分考虑现有产品和构架? | |
| 27 | 需求是否可测试? | |
| 28 | 规定的所有需求是否都是软件应该满足的? | |
| 29 | 每个需求是否都有一种且只有一种解释? | |
| 30 | 是否已使用客户的特有语言? | |
| 31 | 响应是否已同时包括在有效输入值和无效输入值中? | |
| 32 | 所有的图、表和图表是否都包括所有评测术语和评测单元的完整标注、引用和定义? | |
| 33 | 是否已解决或处理所有的未确定因素? | |
| 34 | 有高复杂系数的需求吗?高复杂系数的需求分解成几个小需求吗? | |
| 35 | 接口要求 | 接口需求是否描述清楚? |
| 36 | 接口需求是否是合理的、必要的? | |
| 37 | 接口需求实现是否可行? | |
| 38 | 规范要求 | 使用的模板格式是否符合规程? |
| 39 | 评审过程是否符合规程? | |
| 40 | 缺陷纠正过程是否符合规程? | |
| 41 | 需求是否可追溯? | |
| 42 | 是否已使用图来补充自然语言说明? |
1、以下基本问题应得到解决:
功能:本软件有什么用途?
外部接口:此软件如何与人员、系统硬件、其他硬件及其他软件进行交互?
性能:不同软件功能都有什么样的速度、可用性、响应时间、恢复时间等?
属性:在正确性、可维护性、安全性等方面都有哪些事项要考虑?
2、是否指定了在需求规格说明书 范围之外的任何需求?这里表明需求规格说明书
应正确定义所有的软件需求,
不应说明任何设计或实施细节,
不应该对软件附加更多约束。
需求规格说明书是否合理地了有效设计的范围而不指定任何特定的设计?
3、需求规格说明书 是否显示以下特征?
正确性:
需求规格说明书 规定的所有需求是否都是软件应该满足的?
明确性
每个需求是否都有一种且只有一种解释?
是否已使用客户的语言?
是否已使用图来补充自然语言说明?
完全性
需求规格说明书 是否包括所有的重要需求(无论其与功能、性能设计约束、属性有关还是与外部接口有关)?
是否已确定并指出所有可能情况的输入值的预期范围?
响应是否已同时包括在有效输入值和无效输入值中?
所有的图、表和图表是否都包括所有评测术语和评测单元的完整标注、引用和定义?
是否已解决或处理所有的未确定因素?
一致性
此需求规格说明书 是否与前景文档、用例模型和补充规约相一致?
它是否与更高层的规约相一致?
它是否保持内部一致,其中说明的个别需求的任何部分都不发生冲突?
排列需求的能力
每个需求是否都已通过标识符来标注,以表明该特定需求的重要性或稳定性?
是否已标识出正确确定优先级的其他重要属性?
可核实性
在需求规格说明书 中说明的所有需求是否可被核实?
是否存在一定数量可节省成本的流程可供人员或机器用来检查软件产品是否满足需求?
可修改性
需求规格说明书 的结构和样式是否允许在保留结构和样式不变的情况下方便地对需求进行全面而统一的更改?
是否确定和最大限度地减少了冗余,并对其进行交叉引用?
可追踪性
每个需求是否都有明确的标识符?
每个需求的来源是否确定?
是否通过显式引用早期的工件来维护向后可追踪性?
需求规格说明书 产生的工件是否具有相当大的向前可追踪性?
