需求分析：每个产品经理都应掌握的需求核心组件分析

人人都是产品经理 • 3年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

编辑导语：不管是To B还是To C，做好需求分析，对产品经理乃至整个产品团队都十分重要，因为了解用户需求有助于产品针对市场、针对用户体验进行后期的迭代优化升级。本篇文章里，作者总结了掌握需求核心组件、做好需求分析的方法，一起来看一下。

需求分析可以说是每个从事需求分析工作的人，不管其级别是初中高级亦或是产品总监工作中的重中之重。把需求进行分析进而分解成核心组件是一种必须掌握的强分析技术，每个产品经理应该形成这种意识，甚至是遇到需求后条件反射的本能。今天，我们就来说说需求分析的核心组件，希望能帮助大家的工作和应用到实践中。

一、需求的核心组件的定义，需求的核心组件是什么，为什么需要掌握核心组件！

需求核心组件即：构成需求的核心要素，其在产品经理和需求分析师对需求分析过程并转化为功能需求至关重要，也是一种强大的分析手段。

需求的核心组件构成：对象（Object）、数据（Data）、过程（Process）、规则（Rule），四大组成部分。

应用需求核心组件我们来举一个例子：系统发送消息。那么应用需求核心组件如何进行分解。

对象（需求涉及实体）：系统；
过程（完成的动作或活动）：发送消息；
数据（信息）：消息内容；
规则（业务规则）：什么时候发，满足什么条件才能发。

这么简单的需求分解出来，其实就转化为了具体问题，没有解决的问题或者不清晰的元素，我们就需要去弄明白，这样才不会疏漏任何细节。

需求是复杂的，产品经理在进行需求分析中，如果没有合适的方法去分析和分解需求，那么会造成关系对象的疏漏、信息的缺失、架构的不完整亦或是系统支撑性不足等问题。理解和掌握需求中的核心组件，能让产品经理在需求分析时准确把握核心要素，让业务需求转化成功能需求时的逻辑分析和思路更加清晰，思维更加缜密。

二、需求分析组件的概念和简述

1. 对象（Object）

对象是与业务过程有交互、有关系的人、事物，或者其他软件系统、模块。

没有哪个业务过程是不涉及多个对象进行运转的，当我们进行需求分析时一定要分析出其中涉及的对象，这些对象具象化有可能是你的软件系统、你的用户、你的用户的客户、上下游的软件系统。对象分得越清晰，越能站在不同的对象角度去思考和分析需求的使用场景和衍生场景。

2. 过程（Process）

过程是业务完成的动作或者活动。它是构成需求核心组件的第二大组件，也可以描述为流程。

有些人认为流程都是工作流，审批流等复杂性流程，其实简单的一个动作也叫流程，这里统一称过程吧。过程或流程是一个对象到另一个对象之间涉及的动作或者活动，其通常是由动词加名词进行构成描述，我们常常说的，行为、任务、流程和用例皆可代表过程。

3. 数据（Data）

数据是业务过程中所涉及到的所有信息，我们常说的信息系统和信息技术、信息通信，都无时无刻不在提醒我们软件系统中信息的重要性。

无论你做成的软件功能是自动化完成的活动还是需要收工进行录入完成的活动，尽管活动的形式可以千变万化千姿百态，技术可以千变万化，遗漏了数据需求将造成严重的需求疏漏，对于信息化时代，这种遗漏无疑是致命的。再好的软件，再精美的界面，再牛逼的技术架构，如果客户无法管理、呈现、使用他们需要的业务信息，开发完成也是一场徒劳。所以，数据需求更需要我们详细分析和挖掘。

4. 规则（Rule）

规则定义了业务过程的约束和规则，它代表系统、模块、功能在满足什么样的约束下做出什么样的反应，从而使整个业务过程按照逻辑和我们事先定义的准则进行流转和做出响应。

常常听到几个词：“验证”、“确认”、“检查”、“决定”或者“评估”，这几个动词常常都需要涉及到规则和约束，来判断后续过程的走向和处理过程，因此规则可以说代表了系统的决策点，也是整个需求的关系链逻辑。

三、四大组件深度理解和掌握

清晰了四大组件的基本概念和含义，我们需要掌握每一个组件要素，它们为我们分析需求提供了专业的角度，有助于你分析复杂业务领域。因为每个需求都是由它们进行构成，你拆解分析得越深入，无疑你对需求的把控更加准确。

1. 掌握和理解需求核心组件——对象（Object）

对象是业务涉及到的实质性对象和抽象性对象，其可以是一个人、系统、组织、模块、接口，清晰地分清楚需求涉及的对象非常重要，它是决定产品经理需求范围意识的核心。

对象涉及到内部对象和外部对象，内部对象常常是自己的公司架构、软件系统本身涉及的对象，外部对象主要有其他系统或者接口，主要来自于公司的外部。

这些干系对象都能成为需求分析中的重要角色，都可以包含重要的功能需求。产品经理需要在项目初期进行充分地识别，并分析哪些是主要对象，哪些是次要对象，分清其中的对象从属关系。

通常对象越多，产品经理分析的工作难度也越大，项目的范围和关系也就越复杂，因为这些对象可能都与你的软件最终成果息息相关。比如当考虑到外部对象时，我们就要考虑我们解决方案的数据的公开性和安全性，尽可能地识别出对象与对象之间的关系，能让后续的软件功能更加符合用户的期望。

需求分析时划分外部和内部对象，这也是必要的。开发一个软件，自己的公司和流程很可能可以进行变化，但是外部的对象、政府、客户、其他公司，它们不会受到软件开发项目的影响，因此对象的分析能让我们的软件符合它们的技术环境和架构。

2. 掌握和理解需求核心组件——过程（Process）

过程，比较专业化的描述，指的是，把一个输入的数据转化为输出数据的活动。从大多数的需求分析来看，过程是最重要的的需求要素，非业内人士常常不明白业内人士描述的过程，这就是专业和行业的差异造成的对过程的理解偏差。

过程比数据更难定义。数据是具体的，过程是需要更多的描述性信息来描述其准确含义的活动。

举例：“接收数据”，“记录数据”，接收是被动，记录是主动，那么在系统中采用哪种活动更符合客户需要呢？这就要我们产品经理结合实际场景和更多的需求调研来确认。

过程描述对于产品经理的需求分析非常重要，因此常常需要一些图来详细分析过程的实现形式。我们可以常常使用流程图、数据流图，或者用例来分析系统的需求实现过程，这样我们才能知道什么样的呈现形式、技术架构、搭载终端才是最符合用户场景需求的实现手段。

3. 掌握和理解需求核心组件——数据（Data）

数据在整个需求分析分解过程中占据主要的地位，其不仅作为输入，也作为输出参与到整个业务过程的生命周期中，甚至被其他外部对象继续利用产生外部系统的输入。但是数据又是最复杂的，可以说整个软件系统无处不在的就是数据，软件的成果的核心就在于被准确定义和可使用的数据输入输出。

那么产品经理在分析数据需求时，一般会涉及到什么数据的属性呢？

关联对象的数据；
数据的唯一性；
数据的可控性；
数据的重复性。

1）关联对象的数据

数据是关联对象而存在的描述和属性定义。对象也是我们分析和获取数据的源头，对象的数据可以描述其特征和属性，比如身份证，是一个对象，其包含的数据：18位的数字、姓名、地址、国徽图案、人物头像、防伪标志、以及签发公安局等。

对象的数据可以让使用者清晰识别和认知对象，相反如果对象的数据定义不足或者不清晰，同样会对产品的使用者造成困扰和混淆。

只有通过数据，才能进一步地描述对象的存在价值和特点，对象也通过数据形式，表现出它的独特性和唯一性或者是重要性。当你在发现一个用户和系统的关联越紧密时，这个用户涉及的数据属性也同样至关重要。比如这个用户在系统上的数据：“姓名”、“身份证”、“手机号”、“邮箱”、“地址”等信息，这些数据元素准确的描述了对象（用户）的重要特征。

当然在产品经理的工作中，有时候用户并不会清晰地描述自己的数据，在具象化之前，它们通常被描述为：“报告”、“表格”、“表单”等。对于这些不清晰的数据需求，我们一定要询问和调研，将文档中的数据元素进行确认，并确保其符合客户的工作特征及需要，关联对象的数据获取不仅可以通过访谈、询问，也可以结合个人业务的常识进行补充和扩展，但最重要的是不要遗漏重要的数据。

对象的数据最好使用业务术语描述，而不是采用专业的技术术语，更能让人理解业务需求。我们出一个老师对象的数据模板举个例子，对不对暂且不说，毕竟对教育行业不熟悉，只做举例：

需求分析：每个产品经理都应掌握的需求核心组件分析

这只是简单举例，优秀的产品经理和需求分析师能更准确地定义其需要的数据。如果你所需要的数据已经存入系统，那么你此时更应该思考，数据的查询规则、如何让用户快速找到定位自己想要的数据、数据又以何种方式呈现。这也是数据需求，详细的数据元素和查询规则记录，往往能增加对数据需求的思考层次，同时也避免遗漏需求。

2）数据的唯一性

数据的唯一性常常用来作为搜索、查询特定数据集合的条件。

比如说如果教师工号是唯一性识别的身份标志，那么通过工号定义业务查询规则就能准确找出对应的教师信息；如果老师的学校不是唯一的，那么通过学校的数据取值，就会出现多个结果。

数据需求很重要的一点在于如何查询和访问存储的数据，如果教师工号是具有唯一性的访问识别特征，当该教师的账号被别人登录进行访问时，那么就会产生数据真实性问题。所以手机验证、令牌、其他设备的辅助身份认证这时候就凸显出数据安全保障的作用。数据需求也可以加深我们对客户需求的理解和挖掘。

3）数据的可控性

数据的可控性指的是数据是否是强制还是非强制，即必填和选填，除此之外，还有数据权限，即对应的业务场景下，数据的编辑、删除。

可见权限的定义规则也是属于数据需求，数据的可控性应结合具体场景进行分析。不同业务领域和流程，在于对数据的可控性上定义是不同的。如我们经常碰到购物软件，注册时，我们的收货地址是选填项，因为这时候，收货地址数据为空，你也能正常进行其他动作并不对系统造成任何的影响。

但是业务过程到了提交订单，点击付款时，这时候系统需要用户进行地址数据的录入，并且不允许为空，这是因为系统的流程的下一步必须知道用户的地址数据，才能进行订单的发货。该数据的需要性在业务流程中属于重要节点，这时候原先的数据的可控性便发生了变化。所以数据的可控性应结合到业务过程进行分析。

4）数据的重复性

数据的重复性，常见的比如我们的用户的某个数据是否允许多个取值，如多个电话号码、多个电子邮箱、多个收货地址。

随着信息化时代，每个用户在相同数据定义下都可能具有多个取值需求，产品经理在分析数据的重复性时，切莫去想当然，而是应该站在用户的实际的场景架构和基础上进行思考是否有必要保留数据的重复性，这些场景架构包括用户的画像、用户所处的物理环境。

数据的重复性问题，可以用假设的方法来分析。

比如收货地址，如果用户地址只有一个，用户会频分需要修改吗？如果用户收货地址不是自己的怎么办？这样结合具体的假设和场景分析，看下能不能闭环，闭环时有什么痛点，你就知道是否需要多个电话、多个地址、多个邮箱，来验证自己对数据重复性的思考。

4. 掌握和理解需求核心组件——规则（Rule）

规则，即业务活动能够完成、业务过程能够运转满足的条件要素。

规则有时候是简略就能表示，有时候需要涉及复杂算法的计算并最终校验，才能够决策活动是否完成或者流程是否流转。

准确来说，规则是一个需求中的关系组件，它常常会也关联到其他需求和对象，需求与需求之间也通过规则进行联结在一起，共同进行协作。

举个例子：“某某地区凡是有超过15m的水位线的湖泊都记录到风险点管理”。

我们提炼一下，对象（某地区的湖泊）、数据（水位线）、其他对象（风险点）、规则（水位线超过15m），这样通过规则的定义，就把一个整个需求和不同对象进行关联起来。

有些产品经理可能会把规则误认为是需求，其实这样不能完全说是错的，只是大家在结合分析的时候要分清主次关系，重要的是在需求分析中提炼系统需要的规则，使需求和对象进行逻辑性的联结、沟通、通信。

描述规则时，我们在同一个项目中，相同的规则一定要采用相同的术语，避免测试和研发人员的误解和概念的混淆。这一点在开发过程中会造成很大的歧义，甚至影响后台整个的规则架构，引发不必要的开发工程量。所以在定义和描述规则时，动词的使用和名词的使用，最好保持一致性的原则。

如何从需求中找出我们的规则呢？

1）通过业务需求的干系人获取规则和定义规则。

需求讨论会中，不同的需求的干系人，也有可能对同一规则的描述产生用词差异。产品经理一定要询问并确认其是否指的是同一过程的同一规则、规则使用的场景是什么，这样才能对规则的把控和后续的功能描述更加到位。

2）通过数据需求的分析来暴露规则。

通常我们需要的规则往往是从对象之间数据需求的分析中暴露出来的，规则还可称为“数据传递相关规则”。

软件开发中也转化为表达式和校验判断的规则来约束数据在对象之间的传递，记录在数据的模型中，大多数的规则至少依赖于两个对象之间的数据。当然自己和自己进行内部的处理也是可以的，但我们作为分析，应该以对象之间的数据传递为中心去挖掘规则。

3）当业务规则不清晰或者多变时，我们需要一套业务规则的管理系统进行管理规则。这时候，只要根据我们的数据需求进行规则地表达。

现在的软件系统越做越大，其中的关系也是纷繁复杂。通过业务规则的提炼和相同相似规则的合并，可以组成强有力的规则引擎。在公司对对应领域高度把握，和基于业务需求和规则的理解的基础上，这样建立出的规则引擎将具有强大的生命周期和中台能力，毕竟业务中台和能复用的底层结构的生命线远远比项目的软件系统本身来得长，所以深度挖掘规则也是对整个业态和系统灵活性和扩展性的深度把握。