前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、全局分析的 5W 模型

要清晰的描述一件事情，可以遵循 5w 要素的情景叙述法，谁 who 基于什么原因why，在什么地方where，是什么时候wnen，做了什么事情what，怎么做到的 how。5 要素中的前五个与问题空间需要探索的内容存在对应关系

5w	说明
who	利益相关者
why	系统元愿景
where	系统范围
when	业务流程
what	业务服务，描述到底做了什么

价值需求需要从系统价值的角度进行分析获取，没有价值，系统就没有开发的必要，价值一定是人为提供的，不同角色的人对于该系统的期望并不相同，牵扯到的利益也不同。这就是系统的利益相关者。 我们需要对利益相关者提出的各种价值进行提炼概括，进而明确愿景。通过分析目前系统的当前状态和未来状态，确定目前系统的范围。利益相关者（who），系统愿景why，系统范围where共同组成了目标系统的价值需求。

业务需求由动态的业务流程和静态的业务场景和业务服务构成，每个业务路程都体现了一个业务价值，多个角色在不同阶段参与到业务流程中。整个流程由处于不同时间点的执行步揍构成，具有时间属性，属于 5w 中的 when，每个角色在该时空背景下与目标系统的一次完整服功能交互都是为了获得服务价值，这就是业务场景喜爱的一个服务服务。业务服务是全局分析阶段下获得的基本业务单元，业务服务描述了目标系统到底做了什么，即目标系统提供的业务功能，属于 5w 中的 what

二、高效沟通

全局分析的 5w 模型撑起了精准获得问题的空间的整个骨架，但这离不开业务分析师和利益相关者的高效沟通。

1、达成共识

达成共识的目的是确定目标系统的统一语言，获得统一语言就是在全局分析的过程中不断达成共识的过程。使用统一语言可以帮我们参与讨论的利益相关者，领域专家，开发团队拉到同一个维度空间进行讨论，没有达成共识，就是鸡同鸭讲。毫无沟通效率。

2、统一语言

一单确定了统一语言，最终都可以通过相同的术语清晰准确地定义和表达领域知识

形成统一的领域术语，尤其是基于模型的语言概念，是让沟通达成一致的前提。业务人员，开发人员等存在知识差异，开发人员更熟悉代码细节，业务人员更熟悉业务。两种角色直接的交流就好像两种不同语音的人直接交流。必然磕磕绊绊。从需求中提炼统一语言，就是在两种语言直接进行正确翻译的过程

三、高效协作

一个只靠文字组成的文档进行纸面交流，如能成为一个高效协作的团队。一图胜千言。

1、商业模式画布

商业画布共有9个方格组成，每一个方格里面都涵盖着成千上万种的可能性和替代方案，以画布的可视化方式引导大家一起梳理目标系统的价值需求

方格	理解	说明
客户细分	你想帮助谁？	找出你的目标用户用来描述一个企业想要接触和服务的不同人群或组织
价值主张	你提供的价值是什么？	你所提供的产品或服务。用来描绘为特定客户细分创造价值的系列产品和服务；
用户获取渠道	你怎么触达客户？	分销路径及商铺，用来描绘公司是如何沟通接触其客户细分而传递其价值主张；
客户关系	你与客户怎么样互动？	你想同目标用户建立怎样的关系，用来描绘公司与特定客户细分群体建立的关系类型；
收入来源	你能创造哪些收益？	用来描绘公司从每个客户群体中获取的现金收入，是企业的盈利模式
核心资源	你需要什么？	资金、人才，用来描绘让商业模式有效运转所必需的最重要的因素；
关键业务	你的核心业务是什么？	执行一些关键业务活动，运转企业的商业模式
重要伙伴	谁能帮助你	让商业模式有效运作所需的供应商与合作伙伴的网络。
成本结构	你的成本有哪些	运营一个商业模式所引发的所有成本。

2、业务流程图

业务流程图善于表现业务流程，在绘制流程图的时候，尽量使用标准的可视化符号。如此就可以形成交流的统一语言。如泳道图，任务流程图

想要画好流程图，需要遵循一些的设计规范，掌握一些绘图技巧。例如符号规范、逻辑规范、结构规范、路径规范等等设计规范，比如流程图的绘制顺序：一般遵循，应从上至下，从左到到右的顺序，这样更便于阅读和理解。

1）流程图结构

a、顺序结构

b、分支结构

c、循环结构

2）流程图组件

a、开始、结束

开始组件：作为整个流程的入口，只允许引出连线，不允许引入连线。

结束组件：作为整个流程的，只允许引出连线，不允许引入连线。

b、分支判断

c、调用外部数据，引用外部数据

d、存储数据，输出存储数据

e、流程图中涉及的文档

f、手动输入处理

表示手动输入处理。如手动输入用户名和密码。或者手动录入数据等等。

g、子流程

预先定义的子流程。引用某一预先定义的流程进行处理。如示例，汽车空调加工子流程。

3、服务蓝图

服务蓝图不是记录用户体验。而是以用户的体验作为起点，揭露组织如何支持该旅程 。服务蓝图能够全方位展现具有完整业务价值，如果将一个业务流程是对客户提供的服务，那么一个服务蓝图就成对应了一个业务流程，服务蓝图是真实世界业务流程的真实实现，

服务行为由三条分界线构成：互动分割线、可视边界线和内部支持线；分别描述前台服务面对消费者，后台服务支持前台，公司系统支持前后台的服务逻辑。它不仅包括横向的消费者服务过程，还包括纵向的内部协作，是描绘整个服务前、中、后台构成的全景图。

1）外卖平台服务蓝图

用户行为是通过某外卖平台订购外卖、配送、收到外卖、用餐后完成整个订单流程，服务的后台交互包括了订单处理、优惠活动、时间地点等。

2）快递服务蓝图

3）用户手机选择餐厅

4、用例图

用例图是编写需求说明时经常用到的需求表达方式，用于向开发、测试同事说明需求中用户与系统功能单元之间的关系。它主要由三部分组成：参与者、用例、参与者与用例之间的关系。

组成部分	说明
参与者	不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等
用例	是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
关系	参与者与用例之间的关系主要包括关联、归纳（泛化）、包含、拓展

1）关联关系

关系说明：表示参与者与用例之间的关系

表示方法：带箭头的实线，箭头指向用例。

举例说明：用户登录系统

2）归纳（泛化）关系

关系说明：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关。

表示方法：带空心箭头的实线，箭头指向被泛化（被继承）的用例，即基础用例/父用例。（注意：泛化关系的箭头不是指向被泛化，而是指向被继承。泛化和继承是不同的方向。泛化是从下到上的抽象过程，继承是从上到下，从一般到特殊的过程。）

举例说明：业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

3）包含关系

关系说明：表示用例与用例之间的关系，其中一个用例（基础用例）的行为包含了另一个用例（包含用例）的行为。

表示方法：虚线箭头+«include»字样，箭头指向被包含的用

举例说明：用户在账号登录过程中，包括输入账号、输入密码、确认登录等操作

4）拓展关系

关系说明：表示用例与用例之间的关系；用于拓展用例对基础用例的增强；拓展用例是在特定条件出现时，才会被执行的用例。

表示方法：虚线箭头+«extend»字样，箭头指向被扩展的用例（即基础用例）

举例说明：系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述

5、事件风暴

事件风暴是一场发现事件模型的头脑风暴会议，通过领域专家、产品经理和技术人员共同头碰头的群策群力，以事件模型为主要线索，发现业务系统中发生的代表重要事实的重要事件。 事件风暴是Alberto Brandolini的心血结晶，它是Gamestorming和领域驱动设计（DDD）原则的综合学习实践。

1、以事件为核心驱动力对业务开展探索

2、强调可视化的互动，更好的调动所有参与者共同对业务展开探索

主持人必须是 DDD 从业者才能指导小组走向完整的模型。包括非技术产品所有者在内的每个人都可以参与对领域的理解和建模。整个团队了解域越好，软件实施越有可能反映域，这是 DDD 的主要目的。以下是事件风暴如何运作

1、开一场事件风暴会议，每个人都参与其中，协调人必须使团队保持专注和参与，指导进展到完整的域模型。

2、从领域事件开始，向前和向后遍历模型，以确保涵盖所有内容。

3、添加导致事件的命令或触发器，并考虑所有命令溯源（ES:EventSoucring），包括用户，外部系统甚至时间。

4、识别聚合接受命令和完成事件，并将聚合组在一起成为有界上下文。

5、识别关键测试场景、用户和目标并将其合并到模型中。

6、添加有界上下文之间的关系以创建上下文映射。

7、最后用代码对所得模型进行挑战，以验证组学习并验证模型。

1）事件风暴能解决的问题

1、当软件系统需要进行跨部门的协作与对齐时，能帮助所有 stakeholder 看到整个系统的全貌、让技术和业务在同一个问题上进行讨论、发现有价值的问题、定义与明确各 stakeholder 的职责、发现逻辑漏洞、划分系统上下文、统一语言。

2、当软件系统开始研发之前，能帮助研发团队所有人看到系统的全貌或者一个上下文的全貌、协助进行业务建模，统一语言、非常适合项目研发的 kickoff 。

3、当有新人入职时，能帮助新人快速的学习系统的全貌、边界以及统一的语言。

2）事件风暴不能解决所有问题

1、不能解决所有的沟通协作问题

2、不能解决 Why 的问题，更适合解决 How 的问题

3、不适合用做底层技术的讨论