需求评审的目标
- 了解需求的动机、目标、方案、排期等，为开发设计、测试设计做准备；
- 降低需求设计本身的不完整、不一致、不准确等出现的可能性
- 通过评审尽可能降低团队成员理解的不一致性
- 提早考虑排期风险、实现风险
需求评审可能存在的问题
- 产品的频繁变更，前后实现不一致。这里是说，需求本身的不合理导致产品方面的频繁修改上线。 举一个实际的项目例子：当时新来了一个PM，决定读首页的筛选进行改版，结果上线之后发现不符合用户需求，下次需求就立马改回来了。
- 产品实现方案不合理。这里主要是说，需求评审中直接详细对接了技术实现方案，与第三方对接方案等，结果技术人员评审后，发现与现有的实现冲突、违背，或者如此实现技术方面的改动太大了。
- 需求的预期目标不明确。这类问题是需求评审时常见的一类问题，特别是对效益不太容易评估的产品。 例如，曾经做过一个给公司内部运营人员使用的一款web产品，经过了两年多的迭代后，每次在需求评审时，仍然没有清晰的产品迭代目标。
- 需求过大，而评审文档本身脉络不是十分清晰。举一个这种需求产生的问题： 当时要做一个大型的消息平台，但产品人员与技术人员分隔两地，于是产品人员采用视频/语言的方式来进行需求评审，结果评审后，大家一脸茫然，不知所以。后来产品人员不得已又进行了2次的面对面需求评审，才最终把评审做完
需求的开发视角
- 需求是否技术上可实现、实现成本是多大、目前人力资源是否可支持？
- 需求本身可以带来多大的业务价值，与技术投入成本是否匹配?(避免投入过大，产出过小)
- 需求实现方案是否可验证，有无更轻便的实现方案？
- 实现方案上对用户、技术架构等会带来哪些不利影响？
- 需求是否粒度过小，使得产品琐碎功能累积，过多占用人力？
- 需求是否粒度过大，从而导致开发风险、进度难以预估？
需求的测试视角
测试视角除了上述的开发视角需要考虑的方面外，通常还会考虑以下方面：
- 整个产品方案在可测性方案有哪些阻碍，目前是否可100%支撑？
- 是否需要和第三方人员大交道，中间不可知时间成本有多大，留多少时间buffer？
- 需求粒度大小，复杂程度，使用的技术方案，测试需要提前做哪些准备？
- 需求实现的目标用户、用户习惯是怎么样？
- 需求对应的访问量是多大，是否需要压测评估？