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