文/秋之川
这是《落叶》文集里第 323 片落叶，希望你能喜欢，不为别的，只为这份坚持。
第九章 理解了什么是需求之后该如何做好需求评审呢？
在真正理解了什么是软件需求之后，我通过学习和回顾，对如何做好需求评审做了一些补充理解。
需求评审的形式：
- 邮件评审：多用于产品经理、研发团队等相关干系人不在同一个办公地点，或者是需求刚刚出了框架，或比较粗的规划，可通过邮件发给相关干系人初评，收集反馈意见。
- 会议评审：相对邮件评审，比较系统化、严密的一种集体评审方法，过程一般包括制定评审计划准备和组织会议、跟踪和分析结果等，是最正式，也是最常见的一种评审形式。
评审会议基本流程
需求评审的层级
-
High-Level 评审，也就是我们常说的初评。
（1）通常是产品经理在有了基本的需求框架之后，召集相关干系人，主要是项目里各个角色的负责人展开的评审；
（2）他们需要一起明确用户是谁，站在用户的角度去看问题，去挖掘用户的真实期望，理解用户的业务流程或应用场景，检查需求是否全面、合理和可行； -
Middle-Level 评审，也就是我们常见的正式需求评审。
（1）这时候需求文档和原型应该都已基本完备，需要项目里的相关干系人一起从用户的业务流程和逻辑关系出发分析需求；
（2）检查是否遗漏了某个业务节点；
（3）检查是否遗漏了某个用户角色；
（4）检查是否有完整的业务规则、业务数据的输入和输出规范；
（5）检查最终的功能需求是否能满足用户的需求，且合理，并已划分了优先级；
（6）从用户场景出发，检查功能模块之间是否有冲突；
（7）检查非功能性需求的描述是否清晰合理； -
Low-Level 评审，一些跟业务逻辑无关的微小细节的检查。
（1）需求文档和原型中的术语或图例是否一致；
（2）需求文档中的提示语文案是的语气是否合适，语法是否正确，是否有错别字；
（3）需求文档中是否存在二义性描述，或含糊不清的定义；
需求评审检查表
为了保证不论是同一个人，还是不同的人，每次参与需求评审都能高质量和高效率地完成评审工作，作为测试项目管理者，有一个不错的工具可以利用，那就是将需求文档，包括原型的质量标准和检查点，制作成一个检查表（Check-list），供评审人使用。
参考样例：
| 序号 | 质量标准 | 检查点 | 检查结果 |
|---|---|---|---|
| 1 | 正确性 | 所有的功能逻辑描述是否都正确？ | |
| 1 | 完整性 | 是否有业务节点被遗漏？ | |
| 1 | 是否有功能的业务规则描述不完整？ | ||
| 1 | 是否有遗漏业务数据的输入和输出规范？ | ||
| 1 | 一致性 | 是否有使用图例不一致？ | |
| 1 | 是否有使用术语不一致？ | ||
| 1 | 易测性 | 每个功能需求是否可以被测试或如何测试？ | |
| 1 | 对于性能上的需求，应该如何测试？是否有标准可参考？ | ||
| 1 | 可行性 | 每个功能是否都具有可行性或可操作性？ | |
| 1 | 可靠性 | 当系统报错时，是否有相应的、正确的提示信息？ |
扩展知识补充：
在敏捷里，其实需求已经被用户故事（User Story）所取代，所以在评审敏捷里的 User Story 时，除了本文中提到的需求质量标准之外，还要关注 User Story 所应该符合的 INVEST 标准。
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable
- 每个 User Story 都是独立的，彼此没有依赖的；
- 每个 User Story 的内容都是可以协商的；
- 每个 User Story 都是有价值的；
- 每个 User Story 都是可以估算的；
- 每个 User Story 都是足够小的；
- 每个 User Story 都是可测试的；
《告诉你如何从执行测试到管理测试》带你迈出第（9）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
