面对不断变化的需求，可能很难抽象出一套通用的方法论。我们来看看需求分析过程中常见的套路，或许可以借鉴和思考其中的一些。

当我们收到一个新的需求点，在需求分析中应该遵循哪些步骤？ 首先，根据需求设计功能，需要了解需求的来龙去脉。为此，有必要澄清以下问题:

1、需求的原因 当需求方向说明某个需求时，问她:这个需求的目的是什么？也就是为什么会出现这种需求？这个问题会帮助你充分了解自己的需求，帮助你辨别需求的真实性。

2.需求使用场景 也就是搞清楚在什么情况下谁会使用这个功能。只有了解这一点，我们才能知道如何更好地设计功能来满足需求。

在需求场景模拟的过程中，为了避免设计功能缺乏可扩展性，需要通过不断的推演，在一开始就尽可能全面的考虑。通过需求方场景，拓展思路，是否有衍生场景。思考的过程也是帮助你把握和理解需求本质的过程。

3.辨别真假需求 不听任何人的需求。每个人都有自己的想法和需求。没有一款产品能满足所有用户。在系统分析需求之前，你首先要搞清楚需求提出者的身份。是目标用户吗？是产品的重度使用者吗？是功能服务对象吗？不是说来源不可靠的需求根本不会分析，但这也是你分析的时候要考虑的。

在我们收到需求并充分了解后，我们会花时间与团队合作伙伴进行讨论，听取他们的意见和建议。通过这个过程，基本上就需求点和实现方法达成一致，这将减少后期正式开发中的很多障碍

4.需求解决方案 当我们理解了用户的需求，就需要提供一个产品解决方案来解决用户的需求。在提供解决方案时，我们不仅要考虑用户的需求，还要考虑战略需求、老板的需求、产品运营的需求、业务人员的需求、竞争的需求、产品经理的价值需求。基于这些需求，我们将构建一个产品。这个产品解决方案中会有很多产品功能。这个功能就是我们常说的。

5.打开版本迭代并细化需求 提交需求是为了告知需要全面、清晰合作的小伙伴，让他们能够清晰地了解产品需求，一般通过以下三个交付件告知:

产品流程图

产品流程图是描述产品操作和相应过程的文件，一般有两种类型:

一个是业务流程图，基于业务逻辑设计，一般包含主要流程和功能模块来说明产品架构；

另一种是功能流程图，一般是根据用户任务设计的，包括人物角色、操作过程中的关键节点、状态、判断、结果等

产品原型

以上流程图主要是对产品后端和逻辑的描述，而产品原型的功能只是对流程图的补充，重点是对产品界面信息架构、跳转逻辑、交互功能的展示和说明。通过产品原型，抽象产品可以具体化，使产品更容易理解。产品原型一般由线框组成，业内大多数人用axure制作。有的公司有交互设计师，原型制作工作由交互设计师承担。大多数互联网公司没有交互设计师。

产品需求文件

产品需求文档，简称prd，主要以文字的形式阐述产品的详细需求，并结合流程图和产品原型来说明产品需求。核心内容是对要实现的每个产品功能以及用户角色、前置条件、后置条件、接口、流程、数据统计等的描述。它主要是为R&D人员编写的，并且是逐字逐句地编写和阅读的。

这三个交付件是产品经理协作过程中常见的交付件，尤其是在大公司中。但是，这不是强制性标准。很多中小公司没有产品文档的那部分，有的直接用产品原型标注文字描述做文档，有的用excell写文档。所以根据自己公司的实际需求，这些可交付物的目的是辅助沟通，不管是什么样的可交付物，只要能实现简单、快速、高效的沟通。

6.审查要求 提交产品需求后，需要组织研究、运行、设计和测试人员对产品需求进行评审。在评审过程中，介绍了产品的目标、背景、问题、思路和解决方案。评审的一个目的是使产品更加完善和可行，另一个目的是使所有参与者都认识到产品的要求并达成一致。只有经过所有参与者批准和审查的产品。

结论:需求分析是基于用户沟通、背景认知和人的理解，是一个层层还原一个需求源的过程。恢复一个需求的程度越高，就越准确，我们在后续的产品设计中就越有机会给出合理的方案。