需求剖析可以说是每个从事需求剖析事情的人，不管其级别是初中高等亦或是产品总督工作中的重中之重。把需求进行剖析进而分解成核心组件是一种必须节制的强剖析技能，每个产品经理该当形成这种意识，乃至是碰着需求后条件反射的本能。本日，我们就来说说需求剖析的核心组件，希望能帮助大家的事情和运用到实践中。
一、需求的核心组件的定义，需求的核心组件是什么，为什么须要节制核心组件！
需求核心组件即：构成需求的核心要素，其在产品经理和需求剖析师对需求剖析过程并转化为功能需求至关主要，也是一种强大的剖析手段。
需求的核心组件构成：工具（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）当业务规则不清晰或者多变时，我们须要一套业务规则的管理系统进行管理规则。这时候，只要根据我们的数据需求进行规则地表达。
现在的软件系统越做越大，个中的关系也是纷繁繁芜。通过业务规则的提炼和相同相似规则的合并，可以组成强有力的规则引擎。在公司对对应领域高度把握，和基于业务需求和规则的理解的根本上，这样建立出的规则引擎将具有强大的生命周期和中台能力，毕竟业务中台和能复用的底层构造的生命线远远比项目的软件系统本身来得长，以是深度挖掘规则也是对全体业态和系统灵巧性和扩展性的深度把握。
四、总结
每个产品经理的层次有高低，但每个产品经理都要节制自己的剖析技能，四大需求组件剖析方法，能更好地让我们节制构造化剖析方法，帮助产品经理从不同的工具、不同视角去阐发业务需求和问题。
需求剖析作为产品和需求剖析师的核心事情内容，须要以科学的方法、精确的思考办法、完全的逻辑来进行，切勿眉毛胡子一把抓，而应把持着懂分解需求、擅分解需求的意识进行需求剖析事情。
本文紧张帮助小伙伴们思考构造化自己的需求，并进行剖析，希望对大家有所帮助。
本文由 @止 原创发布于大家都是产品经理。未经容许，禁止转载
题图来自Unsplash，基于CC0协议
