需求评审的目的

• 加强对业务/用户需求的理解，为做好需求分析、测试计划和测试设计打下基础。
• 澄清需求，保证各角色在需求认知上达成一致。
• 发现需求问题。
• 确定测试目标和测试范围。

评审之前

需求评审之前应该会拿到产品规格说明书，作为评审员，应该提前对产品规格说明书进行通读、研究，提前发现问题，带着问题参加评审会议，而不是到会议上再临时发现问题。

测试可以挖掘的问题

• 正确性：需求是否合理？逻辑是否正确？是否有无意义的需求？是否有重叠需求？是否有冗余信息？
• 完备性：功能、性能、安全、输入/输出、条件限制、应用范围是否说明完备？是否有漏掉的功能、输入/输出、条件？是否定义各种故障模式和错误类型的处理方式？输入/输出的类型、取值范围、精度、单位、格式是否定义完整？是否考虑性能、安全需求目标？
• 易理解性：描述是否清晰和明确，没有二义性？
• 一致性：需求之间是否有冲突和矛盾？是否考虑不同设备、系统、浏览器等兼容性？是否考虑向前/向后兼容？是否考虑对其他模块的影响？
• 可行性：技术可否实现？
• 可测试性：是否明确各个功能的验收标准？输入/输出的数据是否清楚定义从而容易验证？

评审过程

• 认真倾听产品讲解需求，在讨论环节提出自己的问题。
• 提问时对事不对人。

常用技术和工具

• 可以建立评审 checklist，checklist 需要持续完善，发现一个典型错误就加进去。通读产品规格说明书时，按 checklist 挖掘问题。
• 善用场景分析法，从用户的角度去质疑需求。
• 最好是有项目管理工具，可以在需求评审计划上关联记录发现的问题（这一步可以在评审之前完成，也可以在评审过程中录入，鉴于评审过程录入有点影响大家的时间，最好是评审之前完成，评审过程直接打开问题讨论即可），用于记录评审过程以及后续的研发数据分析。

希望大家补充。