1 分析对象

如果问题能够在需求阶段予以解决，后续的整个项目的进度和质量将会好很多。

1.1 需求分析的对象

• 产品需求说明书
• 交互原型
• UE图
  一般在进入需求评审之前，要求PM将这些文档提前发出来，提前了解该需求，带着问题参加需求评审无疑是最高效的

2 如何梳理需求

2.1 需求来源

• 市场调研
• 数据埋点
• 用户吐槽
  我们为什么要做这个需求，这是一个why的过程。这也是需要一些数据来支撑这个需求的必要性。我们可以通过目标用户的市场调研，通过已有客户的使用的数据埋点统计，以及用户的吐槽来搜集这些需求，然后根据这些数据的频度和产品的规划结合，确定该需求的优先级

2.2 需求注入的使用场景

往往PM在设计一个需求的时候，可能存在对需求理解的偏差，或者在设计的过程中设计的模型与用户的实际场景会有一定的差距。我们就需要去还原这个真实的业务场景，看这个设计是否是用户这个场景的功能模型。

2.3 需求边界

• 正常业务流程
• 异常业务流程
  往往PM设计的需求只会去描述正常的业务逻辑，而在实际使用过程中，各种分支和场景是多条路径的，我们要想到各种异常的操作可能，要么在产品设计上加以规避，要么在程序设计上予以处理

2.4 抠字眼

需求的描述往往是文字话的表述，而中国的语言是多样话的。我们就需要一个个的字去扣，比如说我要老公去买个苹果。那去哪里买，买什么样的苹果，这些就要我们在分析时进行拷问

2.5 NLP，按照程序性思维分解

我们在梳理需求的时候，要将语言文字转化为程序逻辑的过程思考，这样你会发现一些判断、边界的问题

2.6 交叉逻辑，影响点

往往产品不断的迭代，相互之间的交叉会越来越多，这时候就要关注是否对其他部分存在影响
针对移动端，还需要考虑对老的版本是否会有兼容

2.7 UI风格是否一致 风格、交互

这个往往是我们不太注重的地方，产品也是品牌树立的一部分，整个系统的样式是否统一、交互是否一致

2.8 结合当前的技术框架的可行性

当然了，需求设计的很好，但是也得结合目前的产品技术架构和产品架构进行思考，是否与目前的产品架构是一致的。还是整个底层都要重新来过，这是需要考虑时间成本的

3 工具

3.1 流程线框图

我们在梳理需求的时候，业务流程比较长，涉及到的职能角色比较多，数据链长，我们需要借助工具来帮我们进行梳理，如采用visio等建模工具

3.2 思维导图

当然，业务点比较多，在梳理的时候通过思维导图扩散的模式来梳理也是很有必要的

4 沉淀

4.1 评审前的问题搜集

需求的梳理过程中，会发现有很多的疑问，一定要立即记录下来，反复2-3次这样的梳理，然后与PM进行沟通，并记录沟通完成的结论

4.2 会议纪要

而在评审过程中，其他同学都会有他们自己角度的一些问题，这时候要认真的去记录，然后回顾，也是对自己的需求梳理方法的一个完善的过程