目录
一.需求评审的定义
对需求分析进行的各利益方参加的评审
二.需求评审的目的
| 序号 | 参会人员 | 评审目的 | 产品作用 | 开发作用 | 测试作用 |
|---|---|---|---|---|---|
| 第一次 | 产品、领导层（产品组领导、项目经理） | 判断需求的可行性，是否实施需求内容 | 1.讲叙需求调研内容 ； 2.需求的商用价值； 3.实施周期，预价等 |
||
| 第二次 | 产品、UI、开发组、测试组 | 1.了解需求的动机、目标、方案、排期等，为开发设计、测试设计做准备； 2.降低需求设计本身的不完整、不一致、不准确等出现的可能性； 3.通过评审尽可能降低团队成员理解的不一致性； 4.提早考虑排期风险、实现风险规避 |
1.讲解需求 2.记录需求问题 3.改进需求内容 |
评估产品需求是否明确、清晰、合理，时间和技术的可实施性 | 评估产品需求的可测试性，测试用例的内容是否明确 |
三.需求评审各角度
3.1开发角度
- 需求是否技术上可实现、实现成本是多大、目前人力资源是否可支持？
- 需求本身可以带来多大的业务价值，与技术投入成本是否匹配?(避免投入过大，产出过小）
- 需求实现方案是否可验证，有无更轻便的实现方案？
- 实现方案上对用户、技术架构等会带来哪些不利影响？
- 需求是否粒度过小，使得产品琐碎功能累积，过多占用人力？
- 需求是否粒度过大，从而导致开发风险、进度难以预估？
3.2测试角度
- 测试视角除了上述的开发视角需要考虑的方面外，通常还会考虑以下方面：
- 整个产品方案在可测性方案有哪些阻碍，目前是否可100%支撑？
- 是否需要和第三方人员大交道，中间不可知时间成本有多大，留多少时间buffer？
- 需求粒度大小，复杂程度，使用的技术方案，测试需要提前做哪些准备？
- 需求实现的目标用户、用户习惯是怎么样？
- 需求对应的访问量是多大，是否需要压测评估？
四.需求评审问题
4.1产品的频繁变更，前后实现不一致。
需求本身的不合理导致产品方面的频繁修改上线。
举例：PM对项目内容的优化不符合用户需求
4.2.产品实现方案不合理。
需求评审中直接详细对接了技术实现方案，与第三方对接方案等，结果技术人员评审后，发现与现有的实现冲突、违背，或者如此实现技术方面的改动太大了。
4.3需求的预期目标不明确。
这类问题是需求评审时常见的一类问题，特别是对效益不太容易评估的产品。
举例：需求对产品的预期目标在评审时没有明确的态度，对产品迭代内容也不清晰。
4.4需求过大，而评审文档本身脉络不是十分清晰。
需求内容多，但文档逻辑条理不清晰，相关人员看不懂。
举例：一个业务逻辑或者业务场景，产品可能需要借助流程图或者原型图来讲解清楚。
五.需求评审会议流程
5.1会前准备
5.1.1产品
1.产品确认需求、原型、文档都完成
2.提前找核心人员小范围沟通、消灭掉大问题
3.与参会者确定可出席的时间
4.提前发出会议邀请,定好会议室
5.提前将需求文档和原型交互设计稿等发送给相关人员
6.提前到会议室、提前演练一遍评审会现场
5.2 开发/测试
1.提前阅读需求文档，查看原型图等
2.记录问题，统一在会议时提出
5.2会中流程
1.产品讲述需求内容
2.开发/测试提出问题，产品解答
5.3会后总结
1.产品整理会议问题，及时整改，完成后组织下次会议。
2.测试根据已确定的需求开始编写测试用例
3.开发根据已确定的需求进行开发工作。
六.需求评审结束标准
- 需求内容无异议。
- 评审结束后，产品出需求评审报告给到相关人员。
- 评审结果经项目经理同意确认。
说明：具体根据公司要求，部分公司并不要求完成评审报告，那么可以进行自我总结复盘。