【项目流程】需求评审

一.需求评审的定义

对需求分析进行的各利益方参加的评审

二.需求评审的目的

序号	参会人员	评审目的	产品作用	开发作用	测试作用
第一次	产品、领导层（产品组领导、项目经理）	判断需求的可行性，是否实施需求内容	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.开发根据已确定的需求进行开发工作。

六.需求评审结束标准

• 需求内容无异议。
• 评审结束后，产品出需求评审报告给到相关人员。
• 评审结果经项目经理同意确认。

说明：具体根据公司要求，部分公司并不要求完成评审报告，那么可以进行自我总结复盘。