懂一点「建模知识」，对需求获取和分析很重要

获取需求是一个项目的始点，是我们和用户对系统/功能最开始、最直接的沟通。

写在前面

产品经理的日常工作中，获取需求是一个项目的始点，这是我们和用户对系统/功能最开始、最直接的沟通。

如果说，我们在获取需求的时候，没有理清实体之间的关系，没有对系统有个系统认识，那这个项目的主线其实到后期多半是推翻重做。

之后就是梳理、分析需求，这其实和获取需求是可以同步的。在一些比较有经验的产品中，他们在获取需求的时候，脑海中就已经梳理、分析的差不多了，包括这个功能怎么做、对其他功能带来的影响、涉及到的改动点等。

实体、实体之间的联系，这其实是在数据库建模时候，也就是数据库设计的阶段才用到的，但是我会在需求分析、梳理、设计需求都参考，特别是在获取需求时，这个能帮我们很快从用户嘴里抠出我们想要的东西。

一、 实体

实体是一个抽象名词，是指一个独立的事物个体，自然界的一切具体存在的事物都可以看做一个实体。一个人是一个实体，一个组织也可以看做一个实体。实体不是某一个具体事物，而是自然界所有事物的统称。实体可以是有形的，也可以是无形的，实体也可以是抽象的事物或联系。

理解点：

1、 客观存在的人（机构，下同）、物，

2、有形的、无形的；

3、 独立的个体。

世界由人、物、联系组成，人、物可以定义为实体，将人与物的关联即为联系；我个人更倾向于把人与物，人与人，物与物之间的联系单独拿出来分析，所以实体和联系是分开来写的。

先来看看实体，实体区分人与物，分为角色实体和物实体 ；

角色实体：

人在系统中可以定义为角色实体，如后台的系统管理员、负责审批的审批员，还是前端的促销员，普通的用户，又或者是某个渠道经销商；

他是独立的个体，且在系统中是可以模拟、抽象出来的；

在需求获取阶段，角色的定义、抽离、权限是我们首先需要通盘考虑的问题；

一般情况下，客户会根据他们的实际情况来定义几个不同的角色，分配他们不同的职责权限。

具体的提问点可以围绕：

在现实中，是否有对应的这类人是否与其他已经定义的角色有重合他们可以干什么事情他们不可以干什么事情

物实体：实体中，除去人，剩下的就是物；“他们可以干什么事情”“他们不可以干什么事情”，这其中的“事情”就是物实体。日常区分角色实体与物实体，大概为下面4类；

人-物，比如项目销售可以报备项目，这时候基本就可以断定项目销售-角色实体，项目-物实体，报备是把人和物关联起来的联系；区域经理管理多个区域，区域经理-角色实体，区域-系统枚举定义，管理多个即为区域经理与区域的联系；

人-人，店长管理门店店员，店长、店员-角色实体，门店-机构，也可以认为为物；

物-物，一个项目下可以有多个报备，项目、报备-物实体；

物-人，一个项目允许多个经销商报备，项目-实体，经销商-角色实体。

角色实体很好区分，其实就是人、机构，那剩下的那个名词基本上就是一个实体；确认实体可以围绕以下几点。

是否存在，包括客观的，抽象的；是否可以作为主语使用。

二、 联系

联系，即人与人，人与物，物与物之间的联系；分为3种关系，即：1-1，1-N，N-N。

判断关系应从正、反两方面去看，正向即从A-B，反向即B-A；其中A-B时，默认A为某一个固定实体，看他对应几个B；同理B-A。

1-1，关系比较简单，确定一个，另一个也随之确定；比如部门经理与部门的关系（暂不考虑特殊情况，纯举例）。

正向：一个部门经理管理一个部门；反向：一个部门只有一个部门经理；如张三是产品部的部门经理，张三管理那个部门？产品部的部门经理是谁？问题围绕：

正向提问，答案是否是唯一；反向提问，答案是否唯一。

1-N，即一对多；比较常见的如部门与员工的关系。

正向：一个部门有多个员工，确定员工是N；反向：一个员工只隶属于一个部门，确定部门是1，所以部门-员工为1：N；注意区分哪边是1哪边是N，这个搞混了基本就狗带了；问题围绕：

正向提问，确定1：N中的N对应哪个实体；反向提问，确认1：N中的1对应哪个实体；

N：N，即多对多；同上，正向、反向提问，问题，均为多个；问题围绕，同上。

三、 写在后面

根据以上方法确定实体以及实体之间的联系后，基本上什么人能干什么事情，以及实体之间的联系基本可以确定。这对整个流程的梳理、信息架构的组织和设计可是起到至关重要的作用；关于梳理流程以及如何设计、布局信息架构，把整个产品清晰而有条理的串起来，这个后面再开章节继续写。

注1：我们这里所说的实体、实体之间的联系，只是从产品的角度去度量、思考、表达系统/功能，帮助我们更好的了解、梳理系统/功能，不要求专业性的产物，一般通过Axure、visio，甚至系统自带的画图都可以完成。

注2：文中内容是笔者在日常工作中获取、分析、设计需求时需考虑的必不可少的一个环节，也是有了这些关系之后才会产生后面的流程梳理、原型线框图；对于业务复杂的B端产品更为试用，发表此文仅限交流，不喜勿喷。