《大话软件工程——需求分析与软件设计》[94M]百度网盘|pdf下载|亲测有效

《大话软件工程——需求分析与软件设计》面向从事软件分析与设计相关工作的读者。《大话软件工程——需求分析与软件设计》的重点是在软件工程中增加了业务设计和应用设计的部分，提出了软件设计工程化的模式，支持进行定性、定量的软件项目管理，是一本实操型的软件工程工具书。全书共分为6篇22章，分别介绍了业务分析与设计的理论、需求工程的调研与分析方法、业务的分析与设计方法、应用设计方法、业务用例和应用用例的编写方法、需求和设计的配套模板、规格书标准等。

《大话软件工程——需求分析与软件设计》可作为软件工程师（包括需求、设计、开发、实施）、产品/项目经理、管理咨询师的实用工具书、培训机构的设计资格培训教材，以及普通高等院校管理信息专业、计算机专业学生学习软件设计方法的参考书。

资深需求咨询顾问，具有10年工程管理经验和20多年企业管理信息化咨询、需求分析、系统规划、架构设计的工作经历。

多年专注于研究软件工程实用化的理论、方法、标准等，研究的重点有两个方向：一是探索建立软件“工程化设计”的方法体系，让软件工程从一门 “高深的知识”转化为一套可以 “实操的技术”；二是研究以客户价值为导向的软件设计方法，提出在软件工程中加入“业务设计”和“应用设计”的环节及相关的设计方法。

在进行企业管理信息化咨询工作的同时，致力于软件工程化设计方法的完善、验证和推广。

目录


第1篇　基础概念
第1章　知识体系概述 2
1.1　基础部分 2
1.1.1　三个知识体系 2
1.1.2　三个基础原理 6
1.2　软件工程 7
1.2.1　定义与框架 7
1.2.2　工程分解（横轴） 9
1.2.3　工作分解（纵轴） 10
1.2.4　工程与工作的分解区别 10
1.3　知识框架的构成 11
1.3.1　篇章的构成 11
1.3.2　软件工程知识体系框架 12
1.4　本书的思路与方法 15
1.4.1　本书采用的方法 15
1.4.2　面向过程与面向对象 17
第2章　分离原理 20
2.1　基本概念 20
2.1.1　定义与作用 20
2.1.2　分离原理模型 21
2.1.3　思路与理解 24
2.2　业务与管理的概念 25
2.2.1　业务的概念 25
2.2.2　管理的概念 26
2.2.3　业务与管理的区别 27
2.2.4　业务与管理的相对性 29
2.2.5　业务与管理的特性 30
2.3　分离1——业务与管理 32
2.3.1　要素的分离 32
2.3.2　架构的分离 33
2.3.3　业务流程与审批流程的分离 34
2.4　分离2——组织 35
2.4.1　组织的概念 35
2.4.2　组织、业务与管理的关系 36
2.4.3　组织与业务流程的关系 37
2.5　分离3——物品 38
2.5.1　物品的概念 38
2.5.2　物品要素的作用 38
第3章　组合原理 41
3.1　基本概念 41
3.1.1　定义与作用 41
3.1.2　组合原理模型 42
3.1.3　思路与理解 43
3.2　组合三元素1——要素 44
3.2.1　对象的概念 44
3.2.2　要素的概念 46
3.2.3　要素属性1——粒度与分层 47
3.2.4　要素属性2——黑盒与白盒 49
3.2.5　要素属性3——系统与模块 52
3.2.6　要素属性4——解耦与内聚 54
3.3　组合三元素2——逻辑 57
3.3.1　逻辑的概念 57
3.3.2　逻辑的作用 58
3.3.3　逻辑的分类 60
3.3.4　逻辑的表达1——架构 61
3.3.5　逻辑的表达2——功能 62
3.3.6　逻辑的表达3——数据 63
3.3.7　逻辑的表达4——管理 63
3.4　组合三元素3——模型 64
3.4.1　分析模型 64
3.4.2　架构模型 66
3.4.3　两种模型的区别 68
第4章　分析模型与架构模型 72
4.1　基本用语约定 72
4.2　图形符号说明 73
4.2.1　图形符号的构成 73
4.2.2　图形符号的用法 75
4.2.3　背景框的用法 76
4.3　分析模型1——关联图 77
4.3.1　概念与解读 77
4.3.2　画法与场景 78
4.4　分析模型2——鱼骨图 80
4.4.1　概念与解读 80
4.4.2　画法与场景 80
4.5　分析模型3——思维导图 81
4.5.1　概念与解读 81
4.5.2　画法与场景 82
4.6　分析模型4——排比图（一维） 83
4.6.1　概念与解读 83
4.6.2　画法与场景 85
4.7　分析模型5——排比图（二维） 86
4.7.1　概念与解读 86
4.7.2　画法与场景 87
4.8　架构模型1——拓扑图 88
4.8.1　概念与解读 88
4.8.2　画法与场景 89
4.9　架构模型2——分层图 90
4.9.1　概念与解读 90
4.9.2　画法与场景 92
4.10　架构模型3——框架图 93
4.10.1　概念与解读 93
4.10.2　画法与场景 94
4.11　架构模型4——分解图 96
4.11.1　概念与解读 96
4.11.2　画法与场景 97
4.12　架构模型5——流程图 98
4.12.1　概念与解读 98
4.12.2　画法与场景 99
4.13　其他模型——交互图 100
4.13.1　概念与解读 101
4.13.2　画法与场景 102
第2篇　需求工程
第5章　需求工程概述 106
5.1　基本概念 106
5.1.1　定义与作用 106
5.1.2　内容与能力 107
5.1.3　思路与理解 108
5.2　需求分类 110
5.2.1　功能性需求 110
5.2.2　非功能性需求 110
5.2.3　关于售前咨询 111
5.3　工程分解 112
5.3.1　工程分解1——需求调研 113
5.3.2　工程分解2——需求分析 113
5.3.3　需求调研与需求分析 113
5.3.4　需求工程资料的应用 114
5.4　工作分解 114
5.4.1　需求调研的工作分解 115
5.4.2　需求分析的工作分解 115
5.5　需求体系的建立 115
5.5.1　需求体系的内容 115
5.5.2　需求体系的价值 116
第6章　需求调研 118
6.1　基本概念 118
6.1.1　定义与作用 118
6.1.2　内容与能力 119
6.1.3　思路与理解 120
6.2　需求调研方法 121
6.2.1　需求调研的准备 121
6.2.2　调研对象的区别 125
6.2.3　需求调研的顺序 126
6.2.4　需求真实性的识别 127
6.2.5　需求背景的记录 129
6.2.6　需求的记录形式 129
6.3　记录方式1——现状构成（图） 131
6.3.1　定义与作用 131
6.3.2　构成图1——静态构成 132
6.3.3　构成图2——动态构成 133
6.3.4　构成图3——管控构成 135
6.4　记录方式2——访谈记录（文） 136
6.4.1　定义与作用 136
6.4.2　访谈记录表 137
6.4.3　需求与要求 137
6.5　记录方式3——既存表单（表） 138
6.5.1　定义与作用 138
6.5.2　表单的梳理与记录 139
6.5.3　梳理与记录的流程 141
6.6　需求调研汇总 143
6.6.1　需求记录的原则 143
6.6.2　需求记录的形式 143
第7章　需求分析 146
7.1　基本概念 146
7.1.1　定义与作用 146
7.1.2　内容与能力 147
7.1.3　思路与理解 148
7.2　需求的分析 149
7.2.1　需求的分层 149
7.2.2　需求的转换 150
7.2.3　三种需求分析法 152
7.3　需求分析1——现状构成图 153
7.3.1　资料梳理 153
7.3.2　分析与转换 155
7.4　需求分析2——访谈记录 155
7.4.1　资料梳理 155
7.4.2　分析与转换1——目标需求 156
7.4.3　分析与转换2——业务需求 158
7.4.4　分析与转换3——功能需求 160
7.4.5　分析与转换4——待定需求 162
7.5　需求分析3——既存表单 164
7.5.1　资料梳理 164
7.5.2　分析与转换 165
7.6　需求分析汇总 165
7.6.1　需求规格说明书 165
7.6.2　功能需求一览 166
7.6.3　功能需求规格书（需求4件套） 167
第3篇　设计工程——概要设计
第8章　设计工程概述 174
8.1　基本概念 174
8.1.1　定义与作用 174
8.1.2　内容与能力 176
8.1.3　思路与理解 178
8.2　工程分解 181
8.2.1　工程分解1——概要设计 182
8.2.2　工程分解2——详细设计 182
8.2.3　工程分解3——应用设计 183
8.2.4　工程分解4——三个阶段的关系 183
8.2.5　业务设计与技术设计的关系 184
8.2.6　工程分解与资料引用 185
8.3　工作分解 186
8.3.1　工作分解1——架构层 186
8.3.2　工作分解2——功能层 186
8.3.3　工作分解3——数据层 186
8.3.4　工作分解4——三分层的关系 187
8.3.5　工作分解5——业务与技术的分层关系 188
8.4　管理设计 189
8.5　组织设计 190
8.6　物品设计 191
8.7　价值设计 191
8.8　验证用例与规格书 192
8.8.1　验证用例 192
8.8.2　设计规格书 193
第9章　架构的概要设计 198
9.1　基本概念 199
9.1.1　定义与作用 199
9.1.2　内容与能力 200
9.1.3　思路与理解 201
9.2　设计基础——设计规范 205
9.2.1　设计理念 205
9.2.2　设计主线 206
9.2.3　规范的其他内容 207
9.3　设计基础——基础手法 207
9.3.1　架构设计的基础 207
9.3.2　设计标准 209
9.4　架构的整体规划——拓扑图 211
9.4.1　使用场景 211
9.4.2　使用案例 212
9.5　架构的分层规划——分层图 213
9.5.1　使用场景 213
9.5.2　使用案例 214
9.6　架构的区域规划——框架图 216
9.6.1　使用场景 216
9.6.2　使用案例 216
9.7　架构的结构规划——分解图 218
9.7.1　使用场景 218
9.7.2　使用案例 219
9.8　架构的流程规划——流程图 220
9.8.1　使用场景 220
9.8.2　使用案例 222
9.8.3　流程划分 224
9.9　综合应用案例 226
9.9.1　各类图形的变化 226
9.9.2　模型的组合使用 228
第10章　功能的概要设计 234
10.1　基本概念 235
10.1.1　定义与作用 235
10.1.2　内容与能力 235
10.1.3　思路与理解 236
10.2　业务功能1——分类 237
10.2.1　业务功能的分类 237
10.2.2　业务功能的分类视图 241
10.3　业务功能2——规划 243
10.3.1　功能关联图 243
10.3.2　功能关联图的设计 245
10.3.3　架构与规划的区别 248
10.4　业务功能3——汇总 250
10.4.1　业务功能的最终确定 250
10.4.2　业务功能一览 250

第3章

组合原理

分离原理，提供了如何分离研究对象的原理。本章的组合原理要解决的是如何用模型表达

研究成果的原理。用图形表达分析与设计的成果，可以多维度、精准、完整地传递信息。

本章介绍逻辑图形的构成原理、规律，详细说明了图形中各元素的属性等，组合原理是建

立用图形表达分析与设计成果的基础，见图3-1。

业务

物品

组织

管理

要素

逻辑

模型

分离原理

（4分类）

组合原理

（3元素）企业管理信息系统

1.业务

2.管理

3.组织

4.物品

企业构成的分类

业务架构的元素

图3-1 分离原理与组合原理关系

3.1 基本概念

3.1.1 定义与作用

1.

定义

组合原理，给出了用要素、逻辑和模型三元素形成图形的原理和设计方法，利用组合三元

素可以表达出任意的逻辑图。

在分析与设计过程中，不论使用什么样的逻辑图形（分析用、架构用、管理用等），图形

的构成都包括这三个元素，三元素既可以用来绘图，也可以用来检查图形是否正确。

2.

作用

在企业管理咨询行业和软件行业中，针对企业管理对象的描述，不同的业务领域、不同的

描述人、不同的关注点等使得表达方式有无数种，这就带来了传递意图、解读意图都很困难的

现象。这些图形是否存在着相似的规律呢？是否可以找到一套与业务领域、描述人和关注点无

关的、具有普遍性的图形表达方法呢？

通常寻找具有普遍性的表达方法时，最常用的做法就是“穷尽”所有应用场景，然后通过

抽提共性整合成为一套方法。由于“应用场景”与具体业务相关联，所以这种方式的最大短处

就是随着遇到的场景越多，相应的约束规则、附加条件也会增多。例如，基于100次不同应用场

景抽提出的方法，在用到第101次时如果存在着新的不同点，就要将新场景中的不同之处再加入

大话软件工程——需求分析与软件设计

到既有约束规则中，这种积累方式难以收敛为一个具有共性的模型。

理想的方式是，不论什么业务应用场景仅通过有限的“元素”组合就可以表达，“组合原

理”的提出就是为了满足这一要求。

3.1.2 组合原理模型

1.图形的基本构成

由于研究对象的形态有万千种，所以表达分析、设计意图的图形也就有非常多的形式，如

果要想找到一套通用的方法来替代，需要先研究一下各种图形的构成内容是什么、规律性有哪

些等，从而找到一个通用的建模方法。

下面通过对比几个完全没有任何业务背景，也无任何关联的图形，研究一下它们之间有哪

些共同之处。如图3-2（a）所示，其中有4个图形a1～a4，它们从外形上看似乎没有什么共同

点，如果对a1～a4的图形进行拆分，将拆分后获得的图形元素进行分类，可以获得三组不同的

元素，分别详见图3-2（b）～图3-2（d），这三组不同元素的含义如下。

（1）图3-2（b）：表达的是图的“要素”。

将a1～a4各图中都具有的共同内容3个方块A、B、C提出来，这3个方块是用来表达构成图

形主体内容的“构件”，它们被称为图形的“要素”。

（2）图3-2（c）：表达的是要素间的“逻辑”。

在去掉a1～a4各个图形中的构件要素后，剩下了“线条、位置、背景框”等内容，它们是

用来表达各个构件要素之间的关系，它们被称为“逻辑”。

（3）图3-2（d）：表达的是图的“模型”。

在去除了a1～a4 各个图形中表达要素和逻辑的内容之后，只剩下了要素方块和逻辑的“投

影”，这些投影表达的是要素与逻辑构成的不同“形状”，它们被称为“模型”。

原图三元素

A

B C

BA C

A B C

A

B C

A

B C

BA C

BA C

BA C

箭头

位置

背景框

线条①关联

　关系

②位置

　关系

③包含

　关系

a1

a2

a3

a4

A

B

C

A

B

C

(d) 图的形状(b)图的要素(c)要素的关联(a) 常用图形

A B C

A

B C

图3-2 组合原理三元素的抽提

大话软件工程 四校　正文1-4.indd 42 2020-3-22 15:19:46

前 言



大话软件工程——需求分析与软件设计

计意图，不但沟通效率低，而且经常发生严重的需求失真、遗漏、设计偏差等问题，是造成系
统质量问题的主要原因之一。

3）产品复用的问题

产品的复用率低，或者说几乎没有复用能力，这使得每开发一个新系统都要重复地做着初
级劳动，造成高成本、低效率，其结果还带来了对客户需求变化响应速度慢的问题。复用问题
不解决，即影响客户的满意度，也阻碍开发企业降低成本的能力。

3. 产生问题的背景分析

基于笔者常年的观察与实践经验来看，造成上述诸问题的重要原因可以从软件工程的构成
上看到。在传统软件工程中有需求工程和设计工程，但是在设计工程中没有如图0-1中②所示的
环节，在①的工作完成后，就进入③的工作（或是直接就进入了系统的开发工作）。

□业务设计
(优化,完善,价值)
□应用设计
(机制,复用,共享)
1.需求工程3.开发工程
□ 系统结构
□ 接口设计
□ 数据库设计
□ 界面
3
□ 需求调研
□ 需求分析
□ 功能识别
□ 功能确认
□ ……□ ……
212.设计工程
业务设计/应用设计部分软件设计部分

图0-1 既存软件工程（局部）

图0-1的①和③框中显示的是一般常见软件工程的主要工作内容，这些内容基本上都是围绕
着功能实现进行的，它们各自的重点如下。

①需求工程的重点是获取功能需求，以收集、分析及确定客户对系统的功能需求为主。

②设计工程——业务设计/应用设计部分的工作内容，先设计出理想的客户业务形态，然后
以实现这个理想的业务形态为目标再来判断和设计需要的功能，将这些功能置于“为支持实现
理想的业务状态而存在”的位置。②的设计是以需求实现后要为客户带来最大价值（效率、效
益）为目标的。

③设计工程——软件设计部分，重点是如何实现功能，以系统结构、数据接口、数据库、
界面等内容的设计为主。这些工作都是偏软件实现方面的内容。

打个比方，②的作用就相当于建筑行业的“建筑设计”、汽车行业的“汽车设计”环节，
这些环节的核心目标不是“如何实现产品”，而是“如何实现客户价值”。没有②对应的角
色，就如同在建筑设计院中有结构设计师、设备设计师，但没有“建筑设计师”，在汽车制造
厂有发动机设计师、电器设计师，但没有“汽车设计师”。这个“业务设计/应用设计”环节就
相当于“建筑设计”和“汽车设计”的环节。

0.1.2 本书的观点与目的

1. 本书的观点

作者认为造成客户和软件开发者存在问题的主要原因有三个（不限于此）。



VII

.
前
言

（1）软件工程：缺乏从“业务”视角的分析和设计方法体系。

传统的设计工程重点是针对“功能需求”的获取和设计。而完美的系统设计应该是先建立
优化的业务体系，然后将“功能”看作为优化后的业务运行提供支持服务的信息化手段。

（2）软件企业：缺乏以“设计”为驱动的理念。

软件企业通常用“架构”的概念代替“设计”，但是“架构≠设计”，“架构”只是“设
计”这个大概念的一部分，架构是“粗粒度的设计”，而完美的设计需要包括大到一个系统的
整体架构，小到一个控件的精细描绘。

（3）软件工程师：缺乏以“客户价值”为导向的设计思想。

重“功能”轻“业务”的现象比较多，这样做会忽视客户信息化价值。完美的设计应以
“客户价值”为引导，理解客户购买的是“价值”，功能是为实现价值而存在的。

2. 本书的对策

因为传统的“软件设计”中缺乏“业务设计/应用设计”的内容，所以软件设计的成果是
不完整的，因此，笔者将图0-1的“③软件设计”中有关“界面设计”的部分移到了图0-1的
“②业务设计/应用设计”中，将原软件设计的其他部分称为“技术设计”，将“设计工程”的
内容扩展成为三个阶段：业务设计、应用设计和技术设计，见图0-2，完整的软件设计应该包括
“业务设计、应用设计和技术设计”三个阶段的内容。

1.需求工程3.开发工程
①业务设计
2.设计工程
②应用设计③技术设计
本书涉及的内容
软件设计
的内容

图0-2 软件工程—设计工程（部分）的构成

由于客户价值获取的重点在需求工程阶段，为了保持分析与设计的完整性，本书的内容包
括需求工程和设计工程，其中设计工程包括前两个阶段：业务设计、应用设计。

本书虽然不包含技术设计阶段的内容（此阶段的内容比较成熟，参考书籍丰富），但是给
出了三个阶段设计成果的传递与继承内容、标准、协同关系。

3. 本书的目的

本书的目的是探索并提供一套方法体系来支持上述的设计工程。为了达到这个目的，笔者
为本书的编写制定了四个目标。

目标一：明确“设计”在软件工程中的定位。

传统的软件工程—设计工程中虽然在分类上使用了“设计”一词，但在实际的软件开发
过程中采用更多的是“架构”一词。在“设计”这个大概念中，“业务设计/应用设计”是非常
重要的部分，这个部分决定了系统的客户价值大小。明确“设计”（特别是业务设计/应用设计
部分）在软件工程中的定位，可以提升整个行业对“设计”重要性的认知，同时也可明确从事
“非技术类工程师”在软件过程中的作用、价值和地位。

目标二：构建“业务设计/应用设计”的方法体系。

构建“业务设计/应用设计”的方法体系，它是需求工程与技术设计之间的桥梁，这套方法



大话软件工程——需求分析与软件设计

体系以客户的价值设计为核心，同时它可以作为与管理信息系统干系人之间进行沟通、决策的
“共同语言”。

注：关于干系人

干系人包括：客户方、软件企业的业务方、技术方及其他相关人（如监理等）。

（3）目标三：确定“业务设计/应用设计”方法体系的应用模式。

参照传统行业的分析和设计方法，让“业务设计/应用设计”的体系符合“工程化设计”的
原则、标准、流程，使得从需求调研到设计完成之间的所有成果都是标准的、规范的，并且都
是可传递、可继承的，让这些成果与后续的技术设计形成精确的无缝衔接。

（4）目标四：提升软件企业和软件工程师的设计能力。

设计，不论在任何一个行业都是龙头，提升了企业和员工的设计能力，不但可以提升产品
价值、产品质量和产品复用的能力，而且还可以助力“业务人员”成为“业务设计师”，让开
发“程序员”成为开发“工程师”。

0.1.3 本书的特点

为了实现本书的目的，在构建“业务设计/应用设计”体系时，为这个体系设定了“三化一
线”的要求，其中，三化为图形化、标准化、工程化；一线为逻辑线。

1. 图形化

软件行业缺乏用“图”来表达分析与设计的现象由来已久（UML可表达的场景有限，同时
也不能为所有干系人理解和使用），因此本书为软件工程划分了不同的阶段和层次（参见后续
的软件工程框架），在所有的设计阶段和层次中都提供了对应的参考标准图形。采用图形表达
为主的方式可以大幅度地减少需求与设计的失真，图形化的表达方式可以明显地提升工作效率
和产品质量。图形化表达是工程化设计的基础。

注：关于自然图形

本书采用的图形是“自然图形”表达方式，读者不需要经过特别的培训就可以理解。

2. 标准化

软件行业不能用“标准”的方式进行设计、传递、检验也是一个普遍问题。为了解决这个
问题，本书制定了从图形表达到文字描述的标准化方式。用这样的表达方式可以实现“需求调
研→需求分析→业务设计/应用设计→技术设计”之间的无缝传递、继承。

3. 工程化

有了前述的图形化、标准化作为基础，将软件实现的各个环节按照工程化的模式串联起
来，使软件行业的设计过程和设计资料如同建筑业、制造业可以按照流程进行操作。

本书采用了不同于传统软件工程的知识体系表达方式，如图0-3所示。



(a)按照思维导图方式归集知识(b)按照工程化方式归集知识
技术
设计
①架构层
②功能层
③数据层
2.业务设计
-详细设计
1.业务设计
-概要设计
3.应用设计
第9章：
架构的概要设计
第10章：
功能的概要设计
第12章：
架构的详细设计
第16章：
架构的应用设计
第11章：
数据的概要设计
第14章：
数据的详细设计
第18章：
数据的应用设计
第13章：
功能的详细设计
第17章：
功能的应用设计
设计工程（本书内容）

图0-3 知识的归集方式

1）思维导图方式

如图0-3（a）所示，传统的软件工程知识体系多采用的是“思维导图”式的归集方式，它
将知识进行了归集和分类，但从知识体系的整体上不严格地强调各环节之间的输入与输出、成
果的传递与继承标准、流程等关系。

2）工程化方式

如图0-3（b）所示，将知识体系按照实操的过程进行归集、分类，设计工程中的每个阶
段、环节的成果都是相互衔接的，明确了前后环节之间的输入、输出关系，这种方式有助于软
件企业建立可以定性、定量的开发流程管理、计划管理、资源管理、配置管理，建立可以规范
化地检验各环节作业完成情况以及建立相应的检查标准。

4. 逻辑线

本书从需求调研开始直至应用设计为止，全书始终以“逻辑”为分析和设计的指导主线，
让读者按照逻辑思路去理解知识、同时按照合乎逻辑的结构形式去表达设计结果。在软件工程
的使用过程中，始终以逻辑为流转、传递、承接的依据，“逻辑”的通顺，可以确保分析与设
计结果经得起推敲。同时符合逻辑的设计结果确保了“业务人员”和“技术人员”对接、交流
的正确无误。逻辑是分析与设计过程的灵魂。

0.2 本书的使用

0.2.1 适用的课题

本书中提出的理论、方法、工具和标准，以及相应的软件管理流程、规则等，均以企业
管理信息系统的构建过程为主要目标对象，书中重点在分析和设计的方法。企业管理信息类系
统的范围覆盖了构成企业的主要要素（人、物资、能源、资金、信息等），常见的名称有：
MIS、ERP、PM、CRM、HR、OA等。

选用企业管理信息系统作为研究分析和设计方法的对象，主要是考虑这个对象相对于
其他类型的对象（图书管理系统、售票管理系统等）来说更加复杂、特别是关于项目管理



大话软件工程——需求分析与软件设计

（PM）部分的内容更是所有管理类系统中比较复杂的，如果通过阅读本书的案例读者可以基
本上理解所讲述的理论、方法等内容，那么在进行其他类型系统的分析和设计时就会感到比
较容易了。

本书虽然采用了企业管理信息系统的案例，但书中提供的理论和方法是具有普遍意义的。

本书以构建虚拟的“蓝岛工程建设集团”企业管理信息系统为案例的主线。

0.2.2 适用的对象

本书推荐的读者对象可以是下述各领域的从业者（因企业不同定义不同，仅作为参考）。

1. 软件开发

（1）业务人员：需求调研/需求分析师、业务架构师、实施工程师。

掌握从需求调研、分析、业务设计（架构、功能、数据）、应用设计（界面、复用等）的
方法、标准，可以与客户、技术两个方面进行全方位的沟通、表达。

（2）技术人员：技术架构师、开发工程师（程序员）、测试工程师。

掌握业务人员是如何将客户需求转换为支持开发的设计资料，快速、准确地理解业务设计
资料。同时帮助提升由编码程序员向开发工程师、架构设计师转换的能力。

（3）管理人员：项目经理、产品经理、配置管理员等。

本书的内容可以支持软件项目进行定性、定量的过程管理，包括：开发流程的设计、分析
与设计方法、工作量的计算、投入资源的判断、确定交付物以及交付标准等。

2. 教育培训

（1）大学和培训机构中，从事相关教育和培训的老师。

一般软件开发企业和企业信息中心大都缺乏有经验、知识和能力的业务分析与设计人才
（特别是高端人才），由于缺乏体系化的方法，这些人才的养成通常是靠自己的经验积累，难
以速成，采用了本书提供的知识体系就可以大幅度地缩短教育培训周期。

（2）大学信息管理专业的学生：学习分析与设计方法，在进入社会前就掌握一门实战
技能。

（3）大学软件工程专业的学生：理解软件工程的实用性，特别是设计在软件工程中的
作用。

（4）大学计算机专业的学生：理解、掌握设计的理念、基本方法，拓展思路，开阔眼界。

3. 专业咨询

对于从事企业管理类的专业咨询师来说，利用本书提供的方法可以将企业管理咨询的成
果用逻辑图形来表达，减少由于大量使用文字和表格表达带来的不确定性，使得咨询师向客户
提出的主张更加具有说服力。同时也使得专业咨询的成果可以成为构建企业管理信息系统的依
据，提升专业咨询成果在信息化建设过程中的价值。

注：关于专业咨询

专业咨询包括从事各类企业管理咨询、各类业务领域咨询（如财务、物流等）。



0.2.3 使用的效果

笔者通过常年的培训和验证确定了本书的实用效果，本书的知识为软件企业和读者带来的
收获可以用三个词来归纳：设计、图形、工程。这三个词所代表的知识和能力就是解开在背景
中所谈到软件开发者的“3低”问题（产品价值低、产品质量低和产品复用率低）的钥匙，如果
这三个问题获得解决，那么用户存在的问题也就会随之得到解决。

1. 树立和强化“设计”意识，明确设计带来客户价值

本书不但可以让读者掌握设计的理论和方法，而且可以确认是设计决定了产品的价值，同
时，理解提升产品的复用率也必须要依赖于设计（特别是“应用设计”）。

软件行业的从业人员普遍对“设计”的意识不强，软件实现过程的重心都在编码上，甚至
没有意识到产品的价值是设计出来的（他们认为是开发出来的）。不但刚毕业入职的大学毕业
生没有设计意识，就是从事了多年软件行业的工程师中也不乏不知设计为何物者。

软件开发，如同拍电影

培训会上学员提出了软件行业的常见问题：软件不做出来不知道什么样、不知道怎么使
用、更不知道效果如何。当软件一旦开发出来，大家看到了软件的样子后，马上就进入了软
件的修改阶段，有时修改所花的时间甚至比开发用的时间还要长。针对这个问题大家进行了
讨论，但是讨论的结论是：这是常态，没有办法，因为不做出来就无法确认、验证。

老师也向学员们提出反问：为什么比软件构成更复杂的建筑却能在设计完成时就知道
了它的样子、用法和效果，且完成后没有大规模的修改呢？同理，再设想一下，电影导演能
够说电影不拍出来就不知道效果，拍完后效果不理想再做修改吗？大家的回答是：不行。那
么，为什么单单软件开发做不到？问题出在哪里呢？

大家给出的原因五花八门，但有一点是共同的，那就是：缺乏设计。

通过学习，学员们亲身感受到了经过体系化的、标准化的设计之后，不需要等到开发完
成就可以知道开发完成后的效果和价值了，而且还能用设计成果验证完成的产品是否符合设
计的要求。

缺乏设计造成了在软件生产过程中没有“共同语言和指导原则”，特别是缺乏了“业务设
计/应用设计”的内容带来的影响更大，因为这个部分是所有干系人都必须要理解的（技术设计
的内容不需要所有干系人都理解），这个设计完成后，不但知道了软件完成后的样子、使用方
法、效果和价值，而且它还是软件生产过程中的核心指导原则（因为它是所有相关人都必须知
道和遵守的）。