需求评审实践

对团队来说，其价值主要体现在对外的交付产出。对一个职能完整的软件研发团队，其价值产出体现在其对外交付的需求上。需求作为团队对外价值衡量，同时也贯穿了团队的整个研发周期。因此交付质量高低，不仅仅是对外体现团队价值，反过来也会影响团队内的协作方向，好的交付会提升团队凝聚力，增强交付信心。其中需求的评审过程是需求从设计到实现的关键节点。一个设计良好，澄清充分的需求内容，能保证实现阶段不会出现偏差，能够做到快速高质量的交付。同时也提升团队内部协作效率。

1、评审准备

1、开始需求评审前，参与人员都已阅读过文档，并针对需求文档的疑问给到产品人员。

--提前熟悉文档，能发现文档中绝大部分的明显问题。

2、产品人员根据所有反馈的问题，做出适当的文档补充或调整，并在整理完备后发起需求评审会议。

--文档更加完整，遗漏或者错误更少。

3、涉及到与其他团队有业务对接或者其他团队提出的业务需求，已经了解充分，不需要再次确认。

--涉及到对外业务需要由产品和技术负责人共同参与讨论。

2、评审会议

需求评审会议是澄清的关键事项，要在迭代开始前进行。

2.1 需求文档要求

1、需求文档独立、完整。

需求在一份文档中完整说明，新的功能实现，不依赖其他文档说明体现；

2、需求文档针对前期参与人员提出的问题给与了解答说明，或者有了解释。

问题在需求讲解中说明；

3、需求文档内容包括背景、目的、说明、名词定义、功能需求、风险点等模块内容，对需求有完整的描述；

4、需求文档中功能描述需要有实例化内容，包括业务正常及异常逻辑，交叉业务场景，错误提示信息等完备的需求描述；

--需求检查清单

4.1、功能描述完整，有整体业务流程展示；

功能描述完整，是指对一个实现功能有完整的思考，对其描述无遗漏。例如，页面注册功能，需要以文字、图片等方式完整说明注册功能，包含注册支持邮箱还是手机号还是两者皆可，注册已经存在的账号如何提示，注册中对密码长度要求，密码可输入字符类型要求等等。对此功能的所有细节都思考，异常场景有对应处理方式。

整体业务流程展示，是指较为复杂的需求内容，以清晰的流程图或者思维导图。如下

4.2、业务异常流程清晰且全面，提示信息完整；

以图片或者文字方式展示所有异常的流程，异常流程发生时有相应提示信息展示。

4.3、业务分支路径罗列完全；

对一种场景下多种可能发生的情况完全罗列，并后续发生的情况做出具体说明。

4.4、交叉业务场景考虑全面；

如下面的场景，多种筛选条件组合，决定不同的结果，在类似场景中也需要考虑交叉的场景验证。

4.5、涉及到前端业务流程，有界面交互；

涉及到具体场景，在页面上的展示结果需要由图形展示出来。如下图所示：

4.6、业务耦合度低，可扩展性好；

这里是指，不在一种功能实现上捆绑过多内容，例如一个页面支持注册功能，不在其中做登录功能，保持不同场景的功能独立。

4.7、技术实现合理，技术方案可行；

技术实现是否可行优先考察，这里是指需求中涉及到新的或者产品人员不了解的技术方案需要事先和技术研发人员沟通，确定技术上的可行性。

4.8、向下兼容，同样业务实现与老功能保持一致性；

5、需求讲解时，从业务功能起始点开始逐一讲解。

保证所有功能都涉及，会议人员能更好的进行需求理解、场景联想，更容易从细节中发现场景遗漏或者逻辑错误；

6、各司其职，需求业务逻辑由产品决定，技术方案实现由研发人员决定。

需求文档描述及讲解时关注业务逻辑、功能实现、结果展示能给用户带来更好的体验。

2.2 其他参与人员（测试、开发等）

1、遇到疑问或者发现问题，及时讨论，确定修改建议或解决方案；

2、需求细节问题不做过多展开，只在本需求涉及范围内讨论；

3、对技术方案，逻辑流程可以提出自己的意见、方案。

3 、准出要求

1、满足需求检查清单要求（至少应满足需求检查清单前5条）；

2、可遗留部分细节问题，但不影响需求内容评估；

3、技术可行性分析后是可行的。