菡萏如佳人文章目录
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，机场并不会对液体进行测量，一般是根据瓶子大小和人为预估的，这也是处于可执行考虑
约束分析
约束实际属于非功能需求，非功能需求包括了质量和约束两类，质量是我们的要求，约束是对我们的限制。约束可以分为两类：项目约束和设计约束。
下面是约束分析粪污指引图：
约束分析要点
虽然指引图中列出了约束的六个小步骤，其实可以归纳成两个：
- 明确项目约束：从进度、资源、预算三个角度进行整理
- 明确实现约束：从技术选型、部署环境、开发角度进行整理
输出物
约束描述模板
