前言：面对千变万化的需求，也许很难抽象出一套普适的方法论，不妨一起来看看需求分析过程中的那些常见套路，或许能有一些值得借鉴和思考。
首先，要根据需求设计功能，就要做到理解需求的来龙去脉。为此，需要搞清楚以下问题：
当需求方向你阐述完某个需求后，向她询问：提这个需求的目的是什么？即为什么会产生这个需求？这个问题帮你完全理解需求，帮你辨别需求的真伪。
即搞清楚什么人在什么情况下会用到此功能。只有明白了这个，才知道如何更好地设计功能来满足需要。
在需求场景模拟的过程中，为了避免设计的功能因扩展性不足，通过不断的推导，在一开始，就应该做尽可能全面的考虑。通过需求方的场景，扩展思考，是否存在衍生的场景。思考的过程，也是帮助你抓住和理解需求本质的过程。
不要谁的需求都听，每个人都有自己的想法，也有自己的需求，没有哪个产品能满足所有用户，系统分析需求之前应该先搞清楚需求提出人身份，是目标用户吗？是产品重度使用者吗？是功能服务对象吗？不是说来源不可靠的需求就完全不做分析，但这一点也需要考虑在你的分析范畴内。
我们接到需求后，充分理解了需求后，跟团队伙伴一起花个时间讨论一下，听听他们的意见和建议对需求的考虑。通过此过程，基本上对需求点及实现方式达成一致，在后期正式开发时，会减小很多阻碍
当我们弄清楚了用户需求后，就需要提供一个产品解决方案来解决用户的需求，在提供解决方案的时候，我们不能只考虑用户需求，还需要考虑战略的需求，老板的需求，产品运营的需求，业务人员的需求，竞争的需求，作为产品经理自己本身的价值观需求等，基于这些需求，我们来构建产品，在这个产品方案里面会有很多产品的功能，这个功能就是我们常说的产品需求。
提交需求就是把产品需求完整清晰的告知给需要协作的小伙伴，让他们清楚的了解产品的需求， 一般通过以下三个交付物来告知：
产品流程图是说明产品操作和相应过程的文档，一般有两类：
一类是业务流程图，基于业务逻辑来设计，一般包含主要流程和功能模块，用来说明产品的架构；
另一类是功能流程图，一般基于用户任务来设计，包含人物角色，操作过程的关键节点，状态，判断，结果等
上面的流程图主要偏重于对产品后端和逻辑的描述，而产品原型的作用正好与流程图互补，偏重于对产品界面信息架构，跳转逻辑和交互功能的展示说明，通过产品原型，可以将抽象的产品具体化，让产品更容易被理解，产品原型一般由线框图构成，在业界大部分人使用axure来制作，有的公司有交互设计师，原型制作工作由交互设计师来承担，大部分互联网公司是没有交互设计师的，所以产品原型一般由产品经理来完成，一般长下面这样:
产品需求文档，简称prd, 主要以文字形式来阐述产品的详细需求，与流程图，产品原型配合使用来说明产品需求，核心内容是对要实现的每个产品功能及里面用户角色、前置条件、后置条件、界面、流程，数据统计等内容的描述，主要面向研发人员，使用word来撰写和阅读。
以上这三种交付物是产品经理协作过程中比较常见的交付物，尤其是在大公司中这些是必备的。但这不是强制的标准，很多中小公司都没有产品文档这个部分，有的直接用产品原型标注文字说明来做文档，有的是用excell来写文档，所以具体的交付物根据自己所处公司的实际要求来看，这些交付物的目的是为了辅助沟通，不管什么样的交付物，只要能达到简单，快速，高效沟通的目的就可以。
在提交了产品需求后，需要组织研、运营、设计、测试等人员对产品需求评审，在评审过程中，对产品的目标、背景、问题、思路、解决方案等进行介绍，评审的目的一个是为了让产品更完善，更具有可行性，另一个目的，也是让所有参与实施的人员对产品需求认可，目标达成一致，只有被所有参与人员认可并评审通过的产品需求才能被开发，评审是产品工作中非常重要的环节，如果这部分工作做不好，开发过程中的摩擦和修改需求的概率非常大。
结语：需求分析是基于用户沟通、背景认知、人性理解，层层还原一个需求本源的过程。我们对一个需求的还原程度越高越准，越有机会在后续产品设计给出合理的方案。
关注微信