PMP6(二)：范围确认之需求评审

在项目管理中，需求评审属于项目确认范围的内容。目的是判断工作和可交付成果是否符合需求和产品验收标准。

在软件项目中，需求评审非常重要。项目计划，软件设计，编码，测试等需要以需求评审为基准。

但需求评审通常做的是比较粗的，不够严谨，不够详细，落到实际开发时各种需求考虑不周，有基本流，但扩展流不全不详细，业务逻辑不闭环等。基于以上原因，现整理如何做需求评审。

需求评审过程

1、参会者

• 产品经理
• 项目经理
• 开发团队
• 测试团队
• UI设计师
• UE设计师

2、发放资料

• 原型图
• 《产品需求规格说明书》（PRD）
• 需求功能清单

需求评审纬度

对需求内容评审的纬度：

• 逻辑合理性
• 实现可行性
• 业务流程是否清晰
• 前置条件是否明确
• 是否包含隐含逻辑
• 描述文字是否清晰
• 数据源、数据流向、数据范围是否清晰
• 是否有多场景，多人，多角色是否有交叉操作

评审功能

• 逻辑上是否合理，需要关注业务功能是否闭环，包括异常逻辑的处理。

• 开发需思考实现方案的及可行性，初步评估时间和人力成本。

  不仅仅是看原型图和需求文字描述，必须确认方案可行。

• 评审需要关注到具本的业务点，业务细节，业务深度。

• 评审，尽可能各自独立，使用穷举的思维方式去遍历，分层，不断深入。

  第一层：人，第二层：流程，第三层：流程的不同分支，场景

• 业务逻辑是否有多场景情况，需求描述是否都有完整详细覆盖。

  需要对每一种场景，业务分支进行详情描述，不能一句话概括。

• 涉及到状态的需求，状态尽可能避免回环

• 是否有前置条件，前置条件是否明确。

• 需求是否有隐含逻辑，若有则需要补充完整。

  例如：父子机构科室，隐含联动关系，隐含可能没有父级机构的情况。

• 思考数据源，数据流向。

  需要考虑单人写读，多人写读。例如，状态改变了，其它角色或人是怎么呈现的。

评审UI&交互

• 要关注提示语，提示图标，展示符号等确认。
• 要关注交互细节，跳转，弹窗，刷新，回退等。
• 原型，UI页面文字描述是否有岐意，不易理解，需要明确含义。
• 页面字段约束 ，操作逻辑约束，相关提醒是否明确。

checklist

序号	检查项	是/否
功能评审
1	业务逻辑是否合理？是否包含异常逻辑？
2	业务流程是否清晰？业务功能量闭环？
3	涉及状态的，状态是否避免回环？
4	数据来源量是否明确？
5	数据流向是否明确？
6	前置条件是否明确？
7	是否包含隐含逻辑？
8	文字描述是否清晰？
9	一个功能是否有多场景，多分支，多角色，多用户交叉操作？ 需求描述量完全增覆盖，且足够详细无岐义
10	实现方案是否可行？时间和人力是否满足？
UI&UE评审
1	正确提示语，错误提示语，提示图标或符号，展示位置是否明确？
2	交互细的的跳转，弹窗，刷新，回退是否明确？
3	UI与原型是否存在文字描述，布局不一致？
4	页面字段是否有约束，约束是否明确？