需求可视化：22个需求模型及其应用场景

需求文档的模糊性和歧义性是导致很多软件项目无法满足用户需求的主要原因。针对这一现状，《需求可视化：22个需求模型及其应用场景》主要侧重于以视觉化方式来表达软件需求，介绍了4大类22个可视化需求模型，旨在指导读者通过软件需求的视觉化模型来进一步明确需求，促进开发人员对需求的理解，从而进一步推动软件项目的成功。

《需求可视化：22个需求模型及其应用场景》取自需求领域两位专家十多年的实践经验，具有重要的指导和参考意义，可以帮助读者准确理解需求，开发出满足用户需求和可以帮助用户达成任务目标的软件产品。

《需求可视化：22个需求模型及其应用场景》介绍了4大类22个可视化需求模型及其应用场景，阐述了如何通过可视化的方式来建立需求模型、模型的使用技巧和适用场景等。讲解了整个软件需求阶段所涉及的收集、萃取、分析和优化，并通过可视化的方式来建立需求模型，从头源头上精准定位需求及其价值，从而帮助读者学会通过有价值的需求来实现商业成果。《需求可视化：22个需求模型及其应用场景》由需求领域两位具有实战经验的资深专家所写，适合业务分析师、商业分析师以及产品负责人和敏捷团队成员阅读和参考。

乔伊·比蒂（Joy Beatty）

主要负责新的软件需求方法论及其最佳实践，从需求征询与建模到创建和实现。参与过《财富》500强公司卓越业务分析中心的筹建。有数千名商业分析师参加过她的培训。

乔伊积极参与需求社区的领导工作，是多个行业组织的董事会成员。她是国际商业分析协会（IIBA）的核心团队成员，主导更新了《商业分析知识体系指南》。她经常以发言人的身份活跃于需求相关会议和演讲活动中。此外，她还在专业期刊、白皮书和博客文章中撰写关于需求方法论的文章。乔伊毕业于普渡大学，获得了计算机科学和数学双学士学位。

安东尼·陈（Anthony Chen）

与《财富》500强公司有广泛的合作。他负责公司战略发展以及软件需求技术创新，包括目标链、业务目标模型、OPSD（目标、人员、系统和数据分类）以及可视化需求建模语言（RML）。

除了领导业务和创新，安东尼还写了大量关于软件需求技术、体验和理念的文章。他在伊利诺伊大学获得了电子工程和微生物学学士学位，在德州农工大学获得了医学微生物学和免疫学硕士学位。

方达

爱下厨房的全栈工程师，写过代码，做过测试，研究过需求，从需求领域的学习者成为实践者，具有丰富的产品（菜品，尤其是川菜，其次是鲁菜和粤菜）实操经验与项目管理经验。

第Ⅰ部分 模型导论

第1章 RML简介 3

1.1 定义RML 4

1.1.1 传统需求实践的挑战 4

1.1.2 脑力有限 6

1.1.3 图容易理解，文字很难 6

1.2 需求模型 7

1.2.1 为什么不用UML 8

1.2.2 需求与设计 9

1.2.3 需求模型不是尾声 11

1.3 在项目中使用RML 12

第2章 模型分类 13

2.1 目标、人员、系统和数据模型 14

2.1.1 界定模型 15

2.1.2 全部四个类别都需要 15

2.2 目标模型 16

2.3 人员模型 17

2.4 系统模型 18

2.5 数据模型 19

第Ⅱ部分 目标模型

第3章 业务目标模型 23

3.1 业务目标模型模板 24

3.2 示例 26

3.3 创建业务目标模型 29

3.3.1 确定业务问题 29

3.3.2确定业务目标 31

3.3.3 定义额外的问题和目标 32

3.3.4 定义产品概念 32

3.3.5 描述成功指标 33

3.3.6 为完成业务目标模型需要提出的问题 34

3.4 使用业务目标模型 34

3.4.1 提供对项目价值的共同理解 35

3.4.2 界定解决方案空间 35

3.4.3 理解正在进行的项目 35

3.4.4 推导需求 38

3.4.5 何时适用 38

3.4.6 何时不适用 38

3.5 常见错误 38

3.5.1 没有理解业务问题 38

3.5.2 定义了不可度量的业务目标 38

3.5.3 在业务目标中阐述了错误的信息类型 39

3.6 相关模型 39

第4章 目标链 41

4.1 目标链模板 42

4.2 示例 43

4.3 创建目标链 47

4.3.1 确定业务目标和特性 47

4.3.2 选择要在目标链中分析的特性 47

4.3.3 确定目标因素 48

4.3.4 创建目标链层次结构 51

4.3.5 定义目标方程 53

4.4 使用目标链 55

4.4.1 确定映射到多个业务目标的一个特性的价值 55

4.4.2 确定映射到同一目标链的多个特性的价值 56

4.4.3 确定附属于情感目标的特性价值 57

4.4.4 确定项目是否成功 58

4.4.5 推导需求 58

4.4.6 何时适用 58

4.4.7 何时不适用 58

4.5 常见错误 59

4.5.1 因为数据不存在就不创建目标链 59

4.5.2 在层次结构中跳级 58

4.6 相关模型 59

第5章 关键绩效指标模型 61

5.1 KPIM模板 62

5.2 示例 63

5.3 创建KPIM 65

5.3.1 确定业务过程 66

5.3.2 确定KPI 67

5.3.3 创建KPIM 67

5.3.4 使用KPIM 68

5.3.5 当业务目标不好用时排定KPIM的优先级 68

5.3.6 替换现有特性时排定优先级 68

5.3.7 比较需求的相对价值以缩小范围 69

5.3.8 推导需求 69

5.3.9 何时适用 69

5.3.10 何时不适用 70

5.4 常见错误 70

5.4.1 因为没有KPI就不使用KPIM 70

5.4.2 由于担心被追责而不使用KPIM 70

5.4.3 缺少持续监测 70

5.5 相关模型 70

第6章 特性树 73

6.1 特性树模板 74

6.2 示例 76

6.3 创建特性树 78

6.3.1 确定特性 78

6.3.2 组织特性 78

6.3.3 创建特性树 79

6.3.4 寻找缺失特性 79

6.3.5 使用特性树 81

6.3.6 何时适用 83

6.3.7 何时不适用 83

6.4 常见错误 83

6.4.1 每一级的特性数量不对 83

6.4.2 糟糕的特性名称 83

6.5 相关模型 83

第7章 需求映射矩阵 87

7.1 RMM模板 88

7.2 示例 90

7.3 创建RMM 92

7.3.1 列出“过程流程”步骤 93

7.3.2 将需求映射到“过程流程”步骤 93

7.3.3 发现缺失的映射 96

7.4 使用RMM 97

7.4.1 以容易阅读的结构进行审查 98

7.4.2 发现缺失的需求 98

7.4.3 发现无关的需求或缺失的步骤 98

7.4.4 确定范围的优先级 99

7.4.5 使用需求管理工具的优势 99

7.4.6 推导需求 99

7.4.7 何时适用 99

7.4.8 何时不适用 100

7.5 常见错误 100

7.5.1 没有映射到过程流程 100

7.5.2 不使用或更新RMM 100

7.6 相关模型 100

第Ⅲ部分 人员模型

可视化需求模型（visual requirement model）是分析软件需求最有效的方法之一。它们可以帮助分析师确保所有利益相关方——包括主题专家、业务利益相关方、高管和技术团队——了解解决方案。可视化，可以使利益相关方始终有兴趣参与需求过程（这是对需求进行查漏补缺的关键）。最重要的是，可视化这种方式为解决方案创建了一个全景，可以帮助利益相关方了解解决方案要提供什么和不会提供什么。虽然可视化有这么多优点，但仍然有许多业务分析师和产品经理沿用其中列有成千上万条需求陈述的电子表格或者文档来创建非可视化的需求。这样的文件非常繁琐，云山雾罩，令人不知所措，不仅审查起来很枯燥，甚至更难分析是否有被遗漏的需求。这种实践反映出需求培训的“软肋”（通常将重点放在如何写好需求上），而不是侧重于如何对整个解决方案进行分析。

本书旨在帮助业务分析师、产品经理及其组织中的其他人使用可视化模型来征询（elicit，也称“引出”或“萃取出”）、建模（model）和理解（understand）软件需求。本书描述了一种简单而全面的软件需求可视化建模语言，称为RML（requirement modeling language，需求建模语言），业内通中常以一种“特别”或“即兴”的方式使用。

本书面向的读者

虽然本书主要面向业务分析师（business analyst，BA，也称“商业分析师”）和产品经理（product manager，PO），但我们认为，项目经理、开发人员、架构师和测试人员也能从本书中收获不小的价值，因为本书可以帮助他们理解所接收的信息的标准，使其工作变得更容易。在整本书中，我们一般将从事这项工作的人称为“分析师”，但该角色在不同组织中有许多不同的头衔。当书中提到“你”或者“我们”时，指的也是“分析师”。

事先声明，我们的经验主要来自于运行在现有基础设施上的软件项目，例如为内部开发的信息技术（IT）系统、面向消费者的大规模“软件即服务”（Software as a Service，SaaS）系统以及云系统。虽然我们在独立软件（通用软件或packaged software）以及嵌入式系统上使用过RML，但这些类型的项目并不是我们主要的关注点。不过，基于我们对这些系统的有限经验，我们仍然认为，使用这些系统的读者会从RML中发现令人难以置信的价值，而且我们期待着能从他们那里得到反馈，以便进行改进。

假设

本书不包含需求的基本信息，因此会假设你已经具备编写软件需求的基础知识。另外，本书假设你对软件开发过程（例如迭代方法、瀑布方法和敏捷方法）已经有一个基本的了解，并理解需求如何与这些方法相适应。

本书不面向的读者

如果是刚开始做业务分析师，那么可能应该在阅读本书之前阅读卡尔·魏格斯和乔伊·比蒂的《高质量软件需求》（清华大学出版社，2023年全新译本），了解需求实践的概况。如果你是一名产品经理，专注于软件产品的战略或营销，而不是软件构建，那么本书可能也不太适合你，因为它非常强调如何设计特性以获得更高的最终用户接受度和满意度。

本书的组织

本书经过高效的组织，可以作为参考指南来使用。

第Ⅰ部分从常规意义上介绍模型，然后继续讨论RML和模型的四个分类：目标模型、人员模型、系统模型和数据模型（OPSD）。

第Ⅱ部分~第Ⅴ部分中，每一章都包含一个RML模型并采用一致的布局，具体说明如下：

一个将模型和现实世界关联起来的开篇故事

模型的定义

模型模板

关于使用何种工具来创建模型的建议（工具提示）

一个虚构的示例

对如何创建和使用模型的解释

一个练习，供大家练习模型的使用

每一章的练习都基于同一个样板项目，该项目贯穿全书所有章节。

第Ⅵ部分解释如何选择模型以及如何综合使用多种模型来推导需求。

附录 A 包含两个模型速查表，供大家选择模型时参考。附录B列举创建模型的一般准则，其中包括所有模型的元数据和关于模板的提示。附录C包含书中所有练习的参考答案。书的最后还提供了一个词汇表，定义了本书使用的术语。

找到理想的起点

可以直接从头阅读本书，但对某些人来说，在深入了解每个模型的细节之前，可以先阅读第Ⅵ部分体会一下上下文。下表提供了进一步的指导。

读者画像 可遵循的步骤

初次接触需求建模或更广义的可视化建模 从头开始，一直读到本书最后，了解需求模型的常规知识，了解各种具体的模型，最后学会综合运用

熟悉可视化需求建模而且已在使用类似模型的业务分析师 建议所有章都读完，了解RML处理可视化模型的方式与其他建模语言有何不同。然而，也可能发现第Ⅵ部分更有用，可以先了解如何选择模型并在项目中综合运用。之后，在做具体的项目时，可以根据需要随时参考具体的章

模型快速入门

本书包含大量关于模型的信息。信息量有些大，可能会让大家不知所措。为此，我们开发了一种方法来方便大家快速上手，虽然尽量少用模型，但仍然可以为项目创造巨大的价值。这种快速入门的方法适合大多数基于 IT 的项目。以下过程流程图对这种方法进行了概述。

如图所示，首先创建一个过程流程。接着，根据过程流程中的步骤来创建一个需求映射矩阵（RMM）。然后，为每个屏幕都创建一个显示-操作-响应（DAR）模型，建立它们与业务过程的映射。最后创建数据字典，以确保所有字段都被覆盖，而且校验规则是已知的。

虽然其他许多模型的价值还没有被发挥出来，但采用这一系列步骤无伤大雅。其结果是，需求将按过程流程步骤组织起来，屏幕也映射到过程步骤，以确保UI可以反映关键的过程。

本书约定和特色

本书采用了一些使信息具有可读性并易于理解的约定。

每章开篇都有一个来自现实生活的故事，用楷体显示，旨在帮助读者建立应用场景。

所有RML模型名称简称都大写。采用其他建模语言做的模型则全部小写。

RML模型的基本构建单元称为“元素”，这些模型元素没有采用首字母大写，因而不会与模型名称混淆。

本书末尾的术语表包含我们认为对RML很重要的术语。

每个模型模板小节的最后，有一个“工具提示”，建议了哪些工具可以用来创建当前模型。

配套资源

欢迎下载RML模型模板。如果想在自己的项目中创建本书描述的模型，可以直接使用这些模板。通过以下网址获得一套完整的RML模型：

http://go.microsoft.com/FWLink/?Linkid=253518

在下载后的压缩包中，我们解释了如何使用这些模板。这里简要重复一下：将压缩包解压到一个方便的位置。每个模型都有一个模板。Microsoft Visio文件模型包括一个.vst文件和一个.vss文件，这两个文件是使模板正确工作的必要前提。其余模板采用Microsoft Excel或Microsoft Word格式。模型速查表也包含在压缩包中。