建模知识在需求分析、梳理中的应用（中）

2017-10-17 09:53:00

文接上篇《数据库建模知识：在需求获取与分析中的应用（上）》，本文详述如何将建模知识应用到需求梳理和需求设计中。

1. 模型建立后如何呈现

想要将脑海中的实体-联系表达、呈现出来，能让开发、测试、客户看的明白，我一般会使用实体-联系图和角色权限矩阵来表达。

（1）业余画法

专业性要求不高的情况下，一般的画图软件都可以实现，比如Axure、Visio、word、ppt，就连系统自带的画图软件都可以。虽然这种画法比较随意，也会忽略在数据库阶段建模要考虑的其他属性，但对于产品来说，这个业余画法也够用了。

以下是方法：

如下图，以word示例：

注：建议每个实体-联系都加上解释，避免查看的人因为不懂而出现二次解释场景。

（2）专业绘制

专业绘制，是指技术/开发人员在进行数据库设计之前会根据系统业务需求而进行的建模工作，一般会使用专业的数据库建模工具，这样的话，后面的表结构是可以直接由这个模型进行转化的。

注：对于产品来说，可以稍作了解，无需太深入研究。感兴趣而且有时间那另算。答主本人是学软件工程出身，所以这块还是略有接触，但由于实习+工作都是关于需求方面的工作，所以专业程度仅限于大学老师讲的基础（摊手）。

角色权限矩阵，顾名思义，就是看系统中有哪些角色，这些角色有哪些权限。这个是一定要去思考并表达出来的，一个系统在被提出来时，就应该考虑系统的若干 “干系人”，就是将来使用这个系统的人员角色定义。

在与用户详细沟通需求后，这个系统是以什么方式去做，我们大概是清楚的，即使不清楚，在整理需求时，我们也会去思考适合的方式。

问题围绕：

一个系统对应抽离出角色实体、物实体后，这个基本就可以归纳出来。

以下内容由Excel绘制，X轴（横轴）代表角色实体，Y轴（纵轴）代表物实体，其中1级为功能模块，2级为功能，3级为对该功能的操作，有差异请以实际情况为准。

下图为例：

角色权限矩阵不像UML中的用例图那样，一千个人眼中有一千个哈姆雷特，粒度随心。角色权限矩阵建议尽量细化，有时候甚至可以细化到具体的某个字段，这样做的好处是，在设计阶段，我们可以不用再文字累述哪些人员可见哪些人员不可见。

主要介绍系统主流程及实体状态图转化的画法。

角色权限矩阵确定后，基本上系统的主流程是可以确定下来；

我一般使用Axure或者Visio来绘制流程图，如只是业务较简单的图，我会用Axure直接画；如查看的人对美观度要求比较高且业务较复杂的，建议用Visio的跨职能流程，方便阅览系统-人员，人员-人员的流程扭转和关键步骤的衔接。

跨职能流程图，绘制要点如下，后续会持续追加；

下图为例，主流程中的一小部分：

系统中涉及到的实体，包括物实体、角色实体都可以有状态的，只是有时候可能系统用不到，就不会设置状态；我一般在业务较复杂，或者主流程梳理出现卡壳、断掉的情况下，会来重新设计下这块业务涉及到的实体的状态转化图；

状态图3要素介绍：

实体状态图，绘制要点如下，后续会持续追加；

列出该状图涉及到的实体以及实体的初始状态；如涉及到的实体超过1个，应标明状态是属于哪个实体，如下面的示例图，橘色是报备的状态，蓝色是价格申请的状态，绿色是合同的状态；
归纳出刺激实体状态转化的事件，分类归纳，即有可能这两类事件对状态的转化是一致的，那他们就是属于一类事件，但记得要将两类事件都标注出来；
检查当前实体的状态是否满足业务流程，如状态缺失满足不了，增加状态或限制条件；说的过于笼统，但只要只要有实际案例的经验，应该都能了解我说的是个啥，摊手；
当状态图梳理完成，贴合业务后，再去适当的调整系统流程图；