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

产品之路系列(8) 详细需求分析之数据主线

8 详细需求分析之数据主线

领域建模

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


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

数据与类图

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

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

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

一般会使用类图来表示数据关系,相对研发人员使用的类图,产品人员只需要掌握简单类图的表示方式就可以了,需要画出的内容包含:类名,主要属性,类与类之间关系即可

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

这里比较难理解的是中间二种关系组合和聚合,这里举几个例子:部门和员工的关系,部门没了,员工还在,所以生命周求不一致,属于聚合;订单和订单项,当订单没了,订单项也不存在了,生命周期一直,所以是组合。但是!具体的关系还是要根据业务特定问题域而言的,不能脱离业务的上下文。比如我问你,你是爸爸还是儿子?这个答案得看你是相对谁而言了,对不对?在你爸爸的上下文里,你是儿子;在你儿子的上下文里,你是爸爸。

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

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

学会画类图,工作才完成了一半,你还要学会读类图。请看下面的类图:

错误示例:客户和订单的关系是1对多的关系,订单和收货人是1对1的关系,订单和订单项之间是组合关系

如果你也是按照这种方式来给客户解读类图,那么你就犯了大错误,很多没有产品技术背景客户一定一脸懵,不知道你说的是啥。

切记给客户都类图要掌握二个原则:1 使用客户的母语(客户习惯或行业中一些叫法);2 用业务语言去解读(以介绍业务的方式来介绍)

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

领域建模要点

  • 识别过程数据:可以采用四色/彩色建模法、事件风暴法(这些技能不属于本课程内容,不了解的希望大家自行搜索)
  • 识别自然数据:将过程中参与者(人、公司)、地点、东西(物品、服务)识别出来,引入系统中的角色替换-
  • 识别描述类数据:将说明/概述类,规则类识别出来
  • 整理拆分合并数领域模型:将不同名实际相同的类进行合并;将同名实际不同的类进行拆分;优化关系和补充字段,标出依赖关系等

建模的技巧有很多,大家可以选择适合自己的,推荐以DDD(领域驱动设计)为指导思想进行

输出物

领域模型描述模板

PS:思考题答案,通常情况下人和眼睛是组合关系,但是如果你开发的是器官捐赠管理系统呢?那显然是聚合了!

业务数据分析

通过领域建模或其它方法标识出系统所涉及的业务数据之后,还需要细化业务数据的构成细节,也就是业务数据分析。
下面是业务数据分析任务指引图:

业务数据分析要点

  • 数据应用分析:哪些流程需要这些数据?流程中的CURD都涉及了吗?具体流程中需要数据有哪些?
  • 数据构成分析:包含了哪些字段,数据字段的类型、规格、长度、范围、约束分别是什么?字段枚举值,增长规则、业务规则有哪些?
  • 数据特点分析:主要包含结构特点(主要字段、次要字段、稳定字段、不稳定字段)和使用特点(即时数据、历史数据、关键检索字段、增长规律)两个部分

输出物

业务数据描述模板

标识关键质量和场景分析

关键质量识别

属于非功能性需求分析,标识出最关键的质量需求,以便通过有效的技术手段来保证系统能够达到要求,为业务提供稳定、可靠的支持。
下面是标识关键质量任务指引图:

识别质关键质量要点

识别之前需要通过逆向思考和场景化思考方式进行

  • 识别重要质量属性:包含了安全性、可靠性、易用性、性能、可维护性、可移植性
  • 对重要的质量属性进行排序:通过威胁的影响度和频率综合考虑,可根据指引图中的权重进行,打分的时候两个维度分别交给不同的人/团队进行,曲奇乘积进行排序

质量场景分析

标识出关键质量需求之后,还需要进一步细化,找出具体的质量场景,然后与研发团队一起讨论,采取合适的手段来实现。‘
下面是质量场景分析任务指引图:

大部分的PRD中关于非功能性需求,往往都是乱写一气,充斥着大量的定性描述,还存在盲目的定量、全局化描述等典型问题。
比如:系统要求高扩展性,高弹性.....,研发人员看到后绝对是一脸懵逼,系统到底想往哪里扩展,哪里弹?项目成本是固定的,不可能不计时间和资源成本,无限扩展。
所以这种所谓的质量描述毫无意义也毫无营养。产品人员应该具体指明哪个业务流程会发生变化,可能会怎么变,希望要哪些扩展和配置化?

除了定性的问题外,定量也会存在问题。比如:平均用户学习时间要求1.25小时,平均无故障时间2127小时......如果你去问写的人:这些量化指标你是如何计算的?

答案无非是:COPY来的,我自己脑补的.......

如果是为了量化而量化,最后结果反而会适得其反,最好是能够积累历史数据,在有效理解的基础上,给出科学、严谨的量化描述。
另外还要警惕那种:所有查询都应在多少秒内响应的描述,那种数据量超大的年报之类,很可能就无法做到;而有的查询如果超过3秒用户可能就等不住了。如果你无法预估出质量指标,你应该写出功能的使用频率等有效信息。

质量分析要点

  • 识别质量场景:运用逆向思维(站在对立面),场景化思维(给出具体场景)
  • 制订对策:针对质量场景的影响、威胁采用什么手段来避免或降低风险,注意每种措施都会带来新问题和影响,同时还要来了项目的成本
  • 验证矛盾并解决:验证对策的影响,确定对策;比如防止客户乱发短信,一般需要增加一个验证码,通过验证再触发短信发送,牺牲了易用性带来了安全性

输出物

质量描述模板

业务规则与约束分析

业务规则

大多数系统规则,我们可以在流程分析时一并给出,但是针对规则特别多,系统特别复杂的情况,建议单独对业务规则进行整理。
业务规则的整理要点如下:

  • 按作用域规则:如果系统中有大量的规则,研发在工作中可能会经常顾此失彼,为了不遗漏最好对规则进行分类,一种是按照作用域归类

    影响整个问题域,整理成专门的章节;只影响某个业务流程的,在流程分析中描述即可;只影响某个业务场景的,在业务场景中描述即可

  • 按类型二次归类规则:业务规则非常细的时候,还需要再进一步归类

    行为类:影响业务流程,场景执行的规则;数据类:用于控制数据格式与内容;权限类:用于控制用户执行和数据查看

  • 分析规则后的动机:最后也是最重要的一点,理解规则背后的动机,包含业务动机和可执行性;业务动机帮助发现改规则是否存在欠考虑的地方,可执行性帮助更好优化规则

    电商平台通过复杂的优惠券规则,使得分开多单下其实更加优惠,结果范围增加了系统的负担,增加了物流成本,浪费了用户时间,更好的方案难道不是根据订单总额来限制优惠券的使用吗?还有机场规定随身携带的液体不能超过100ml,机场并不会对液体进行测量,一般是根据瓶子大小和人为预估的,这也是处于可执行考虑

约束分析

约束实际属于非功能需求,非功能需求包括了质量和约束两类,质量是我们的要求,约束是对我们的限制。约束可以分为两类:项目约束和设计约束。
下面是约束分析粪污指引图:

约束分析要点

虽然指引图中列出了约束的六个小步骤,其实可以归纳成两个:

  • 明确项目约束:从进度、资源、预算三个角度进行整理
  • 明确实现约束:从技术选型、部署环境、开发角度进行整理

输出物

约束描述模板

未经允许不得转载:菡萏如佳人 » 产品之路系列(8)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

欢迎加入极客江湖

进入江湖关于作者