一个需求经过大脑，大脑判断它，整个过程不过是一瞬间。 笔者将这个过程具象化为书面形式，并加以总结，借文中的方法评估需求，希望对产品的人有一定的启发和帮助。

需求分析是产品设计的前置过程。

由于产品经理是沟通的中心，我们需要在短时间内评估需求的价值并提出解决方案。

一个需求在产品经理的脑海里经历怎样的过程？ 本文从需求分析、分解、优先级评价三个维度分享一些方法，希望对大家有所启发。

一、需求分析的方法

1. 基础元素分析法

。

图1-要求的基本要素

第一种方法是从需求的完整性出发，以挖掘真正的需求为目标。

完整的要求至少必须包括图1中的四个元素。 分别如下所示。

1.1需求背景

需求背景是指动机，该项目实质上是一种换位思考，有助于从业务端的角度，从使用场景、用户心理理解需求。

在实际工作中，我们收到的“需求”常常表现得不清晰、不完整，也有欺骗性。

一个问题解决很多问题，找到真正的需求是我们的责任。

1.2有需求的参加者

有需求的客户需要注意的问题有两个。

谁是真正的参加者？ 参加者的集团是否具有代表性。 需求的来源很多，可能是用户、业务方面等。 我们有必要弄清楚谁是真正的参加者。

在一个需求中角色的认知和诉求不同，信息如果有主观判断就会被污染。

其次，是复盖度的问题。 如果频率不够高，或者人们没有代表性的需求，投入产出比就会成为一个大问号。 在评估需求优先级和制定解决方案时，识别受众会大大降低混乱性。

1.3需求的目的

需求就是需要做什么，很多时候，我们收到的“需求”其实就是业务方过滤的“解决方案”。

以“口渴”为例，此时业务方提出的需求是做饮水机，但是饮水机不能解决问题。 如果背后的动机是“口渴”，可以从减少水分补给和水分流失中提供解决方案。

1.4需求目标

中文词典中的解释，目的是期待，目标是成果。

目标更具体，可以用数据指标来衡量，之后也可以指导需求的改善。

需求的本质是为了创造价值，创造价值最坦率的是开源和节流。 特别是具体到目标上，可以在创造的收益、提高的效率、节约的资源等方面进行量化。

2. 因果关系分析法

如果需求具有上述4个要素，下一步是分析逻辑是否足够严密，可以在这里使用因果关系分析法。

图2-推导需求目的

用图2因果关系来表示的话，“希望某用户出于某种理由做点什么”

通过穷举法，如图3所示，可以得到更多的因果关系类型

图3-因果类型

网罗结束后，我们开始了关于因果关系的辩证法：

原因是真的吗？ 这个原因一定会引起这个结果吗？ 这个结果还有其他原因吗？ ……前几天有一个典型的“需求”。

“APP注册页面改版后，注册数据下降，因此优化APP注册页面。 ”

将此示例代入上述三个问题：

APP注册页面改版了吗？ 答：改版了。 APP的注册页面改版后，注册数据一定会下降吗？ 答：未必如此。 只能回答有可能。 注册数据下降，优化APP的注册页面一定有用吗？ 答：未必如此。 只能回答有可能。 注册数据下降有其他原因吗？ a )渠道普及减少，投放的渠道匹配度不高，平台老乐队的新活动减少等。 经过这样的分析，可以看出这个需求的逻辑有问题，业务方将相关关系转换为因果关系，将相关原因直接转换为原因。

对于诸多原因造成的结果，数学中使用多元回归分析来发现问题。 只着眼于一点的话，这样的需求是非常经不起推敲的。

弄清

3. 公式法

因果关系后，我们开始进一步细分。

假设上述注册人数的减少只受到APP改版的影响，则如图4所示，可以绘制用户在下载后注册和登录的访问路径。

图4-用户路径

方法也非常简单，只要按时间顺序描绘用户各步骤的操作即可。 研究表明，绘制完成后，影响注册数据的原因可能是下载前流量下降或后续链路的流失率增加。

这里将抽象的需求转换为具象的公式，根据公式优化各个环节的数据指标。

根据图4，我们可以列出如下的公式：

APP注册人数=手机号注册人数+微信注册人数微信注册人数=进入注册页面人数-进入注册页面人数*跳失率-登录人数-点击手机号登录注册人数手机号注册人数=进入注册页面人数-进入注册页面人数*跳失率-登录人数-点击微信登录注册人数-进入手机号登录页面人数*跳失率-选择切换登录方式人数-输入手机号未获取验证码人数-输入验证码未登录人数

罗列公式并代入近期的数据进行对比，就能够发现是哪个环节的数据指标下降了，优化那个数据指标也正是我们的需求。

二、需求的拆解

当明确了我们的需求知道要做什么，下一步则是对需求的拆解，从而建立产品设计的框架，这个环节我推荐的是UML拆解法。

UML（Unified Modeling Language）其中文的翻译是统一建模语言，这种方法主要运用于系统设计。这是一种非常好的解构方法，能够帮助我们在产品设计时逻辑更为清晰、全面（对这种方法有兴趣的朋友可以阅读相关的书籍，在这里仅做进行简单介绍）。

1. 用例图

图5-用例图

用例图（Use Case Diagram）是显示一组用例、参与者及它们之间关系的一种图。

在这里，左边的参与者（Actor）不仅是真实的用户，还有关联系统，这个图例能够帮助我们梳理关联的业务方，明晰系统的边界以及应当提供的功能。

目前在网络上有一些倒推某产品PRD的文章或者体验报告，其拆解方式是从页面出发倒推功能。这种方式个人认为会有些取舍不当，我们更应该从用户和系统的层面进行去设计功能。

2. 时序图

图6-时序图例图

时序图在百度百科的解释为：“通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。它可以表示用例的行为顺序，当执行一个用例行为时，其中的每条消息对应一个类操作或状态机中引起转换的触发事件。”

简而言之，时序图是功能与内外部系统之间的交互，表示其每一步的请求以及返回数据的过程。

时序图和产品工作中所使用的泳道图非常相近，理解时序图，能够帮助我们理解系统的边界及耦合程度。

如果在产品设计中常常撰写相同的功能逻辑，可以考虑将其抽象成为一个单独的中台系统供业务方使用，节省资源也使设计的系统延展性更强。

3. 状态机

图7-状态机例图

用例用于枚举功能，时序用于理解系统的交互，在产品设计中还有很常见一类设计是状态的转换，这是用例图和时序图所覆盖不了的。如权限的控制、用户交互的切换、状态的转移等。更具体的例子可以参考秒杀活动的前中后前端的交互、电商平台中订单状态的切换。

这些场景我们会使用状态机来描述。

状态机泛指有限状态机，表示有限个状态以及在这些状态之间的转移和动作。对于复杂的状态，文字描写会相对无力，这个时候状态机就能够派上用场了。

以上的三种图像是产品经理需要去理解的，这也是技术评审中所会接触到知识点。在这里并不是建议使用这种方式撰写需求文档，而是学习UML对需求的解构方法。

在系统设计中产品经理还需要关心的，是数据库的表结构设计，它会影响到后续数据是否能够提取。

三、需求优先级的评定

最后一个环节是需求优先级的评定，我常用的方法是选取影响优先级的因素并设定比例，经过加权计算出优先级，分数越高优先级越高。

其公式如下：

优先级=因素1比例*因素1分值+因素2比例*因素2分值+….

表1-需求评估加权表

这张表，影响的因素主要有两项：投入产出比以及重要程度。

投入产出比个人认为是必选的，而重要程度中的维度可以根据实际情况去增加、减少。同理，加权中比例的设置也是如此。

经过了这3个环节，需求分析也大致结束了。在需求分析中，我们不必要拘泥于具体的某个方法，适合才是最好的。

没想到脑海里迅速完结的过程写了这么多，感谢你看到这里，谢谢。

本文由 @WISE 原创发布于人人都是产品经理 ，未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议