不为有趣之事,何遣有涯之生
不失其所者久,死而不亡者寿

需求分析之路专题(7) 详细需求分析之数据篇

领域建模

数据主线的重点在于范围和关系,弄清楚哪些数据要纳入系统,他们之间的关系是什么,领域建模就是解决这两个问题的关键。

下面是领域建模任务指引图:

https://hzqiuxm-doc-image.oss-cn-hangzhou.aliyuncs.com/blogimgblogimg20230417145720.png

注意:前4个步骤会循环很多次

数据与类图

正确理清数据与数据之间的关系,才能正确进行功能设计,否则不仅会限制功能,还会限制业务。

下面是一个银行业务的真实案例,很好的说明了数据关系梳理的重要性。

银行都会推出VIP业务,A银行VIP是以个人为单位的,某位先生因为一开始以他太太名义办理的业务,所以他太太成为了VIP,但是每次办业务其实是先生自己去办,为了享受一些VIP业务,经常需要带上太太的身份证和VIP卡,十分不便。实际上他的定期存款都早就超过VIP要求了,他希望把一部分钱存在自己名下来解决,但和老婆协商未果,正苦闷之际,得知B银行的VIP是以家庭为单位,一人是VIP全家都是VIP,这位先生就把所有银行资产都转移到了B银行。

这个故事中很好说明了,数据关系没厘清,客户是怎么被你劝退的。

在软件项目中一般会使用类图来表示数据关系,类图偏向工程师使用,需求/产品人员只需要掌握简单类图的表示方式就可以了,需要画出的内容包含:类名,主要属性,类与类之间关系即可。

类之间的常用关系有4种:关联(泛指二者有关系)、组合(关系紧密的整体部分关系,生命周期一致)、聚合(关系一般整体部分关系,生命周期不一致)、继承(类别,比如人分为男人和女人)。

https://hzqiuxm-doc-image.oss-cn-hangzhou.aliyuncs.com/blogimg20230417150408.png

这里比较难理解的是中间二种关系组合和聚合,这里举几个例子:部门和员工的关系,部门没了,员工还在,所以生命周求不一致,属于聚合;订单和订单项,当订单没了,订单项也不存在了,生命周期一直,所以是组合。

但是!具体的关系还是要根据业务特定问题域而言的,不能脱离业务的上下文。

比如我问你,你是爸爸还是儿子?这个答案得看你是相对谁而言了。在你和你爸爸的上下文里,你是儿子;在你和你儿子的上下文里,你是爸爸。

留一个思考题:人和眼睛是聚合还是组合?(答案在本小结最后面)

如果你还不能有效的分析出后3种关系,都使用关联过渡下也是可以,但和研发沟通时一定要表达清楚。还是建议大家把常用的4种都熟悉掌握。

当你学会画类图了,工作才完成了一半,你还要学会读类图(别以为读类图就很简单,很多人都没法正确读)。

请看下面的类图:

https://hzqiuxm-doc-image.oss-cn-hangzhou.aliyuncs.com/blogimg20230417150652.png

请你认真尝试的读一下上面这个类图,真的需要尝试一次。

请看参考答案:客户和订单的关系是1对多的关系,订单和收货人是1对1的关系,订单和订单项之间是组合关系.......

如果你的解读和上面的参考答案差不多,那么恭喜你,你读错了。

为什么?因为很多没有产品技术背景客户听完你的解读一定一脸懵,不知道你说的是啥。所以切记给客户都类图要掌握二个原则:1 使用客户的母语(客户习惯或行业中一些叫法);2 用业务语言去解读(以介绍业务的方式来介绍)

下面是正确解读示例:一个客户可以下多个订单;每个订单上有且只有一个收货人;订单是可以由多个订单项组成的;由于订单中涉及多个供应商,因此需要将订单分拆为多个送货单;每个送货单由相应的供应商执行;每个供应商可以为我们提供多种产品;每个订单项相同的产品只能有一个。

领域建模要点

  • 识别过程数据:可以采用四色建模法、事件风暴法(这些技能不属于本课程内容,不了解的希望大家自行搜索)。

  • 识别自然数据:将过程中参与者(人、公司)、地点、东西(物品、服务)识别出来,引入系统中的角色替换。

  • 识别描述类数据:将说明/概述类,规则类识别出来。

  • 整理拆分合并数领域模型:将不同名实际相同的类进行合并;将同名实际不同的类进行拆分;优化关系和补充字段,标出依赖关系等。

建模的技巧有很多,大家可以选择适合自己的,简单的直接可以使用面向对象的建模方式,复杂业务推荐以DDD(领域驱动设计)为指导思想进行。

业务数据分析

通过领域建模或其它方法标识出系统所涉及的业务数据之后,还需要细化业务数据的构成细节,也就是进行业务数据分析的工作。

下面是业务数据分析任务指引图:

https://hzqiuxm-doc-image.oss-cn-hangzhou.aliyuncs.com/blogimg20230417151517.png

业务数据分析要点如下:

  • 数据应用分析:哪些流程需要这些数据?流程中的CURD都涉及了吗?具体流程中需要数据有哪些?

  • 数据构成分析:包含了哪些字段,数据字段的类型、规格、长度、范围、约束分别是什么?字段枚举值,增长规则、业务规则有哪些?

  • 数据特点分析:主要包含结构特点(主要字段、次要字段、稳定字段、不稳定字段)和使用特点(即时数据、历史数据、关键检索字段、增长规律)两个部分。

小结

本小结主要介绍了数据范围与关系的梳理,主要工作就是领域建模。领域建模非常重要,它在很大程度上影响着后续研发工程师对业务系统核心领域的架构设计。所以是否能够画出一个清晰准确的类图就显的非常重要了。

当系统十分复杂时,要注意类图的边界。你不可能为整个系统画一张类图,你也不需要为所有的子系统都要画类图。我的建议是你最好遵循主业务场景来进行此项工作。

获得数据类图后,我们需要进行数据分析,数据分析主要是要弄清楚数据需要在哪些流程中使用,数据的构成细节,数据的结构特点。

一个好的数据分析会对系统的可扩展性有着显著的影响,区分出稳定和不稳定,实时和历史,增长规律等特点,对工程师架构设计有着重要的指导作用。

附录

当我们完成领域建模后,需要输出领域模型描述文档,模板如下图所示:

https://hzqiuxm-doc-image.oss-cn-hangzhou.aliyuncs.com/blogimg20230417151247.png

当我们完成业务数据分析后,需要输出业务数据描述文档,模板如下图所示:

https://hzqiuxm-doc-image.oss-cn-hangzhou.aliyuncs.com/blogimg20230417151736.png

思考题答案:通常情况下人和眼睛是组合关系,但是如果你开发的是器官捐赠管理系统呢?那显然是聚合了!所以脑子里一定时刻装着上下文这个词。

未经允许不得转载:菡萏如佳人 » 需求分析之路专题(7)

欢迎加入极客江湖

进入江湖关于作者