前 言
大话软件工程——需求分析与软件设计
计意图，不但沟通效率低，而且经常发生严重的需求失真、遗漏、设计偏差等问题，是造成系
统质量问题的主要原因之一。
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. 树立和强化“设计”意识，明确设计带来客户价值
本书不但可以让读者掌握设计的理论和方法，而且可以确认是设计决定了产品的价值，同
时，理解提升产品的复用率也必须要依赖于设计（特别是“应用设计”）。
软件行业的从业人员普遍对“设计”的意识不强，软件实现过程的重心都在编码上，甚至
没有意识到产品的价值是设计出来的（他们认为是开发出来的）。不但刚毕业入职的大学毕业
生没有设计意识，就是从事了多年软件行业的工程师中也不乏不知设计为何物者。
软件开发，如同拍电影
培训会上学员提出了软件行业的常见问题：软件不做出来不知道什么样、不知道怎么使
用、更不知道效果如何。当软件一旦开发出来，大家看到了软件的样子后，马上就进入了软
件的修改阶段，有时修改所花的时间甚至比开发用的时间还要长。针对这个问题大家进行了
讨论，但是讨论的结论是：这是常态，没有办法，因为不做出来就无法确认、验证。
老师也向学员们提出反问：为什么比软件构成更复杂的建筑却能在设计完成时就知道
了它的样子、用法和效果，且完成后没有大规模的修改呢？同理，再设想一下，电影导演能
够说电影不拍出来就不知道效果，拍完后效果不理想再做修改吗？大家的回答是：不行。那
么，为什么单单软件开发做不到？问题出在哪里呢？
大家给出的原因五花八门，但有一点是共同的，那就是：缺乏设计。
通过学习，学员们亲身感受到了经过体系化的、标准化的设计之后，不需要等到开发完
成就可以知道开发完成后的效果和价值了，而且还能用设计成果验证完成的产品是否符合设
计的要求。
缺乏设计造成了在软件生产过程中没有“共同语言和指导原则”，特别是缺乏了“业务设
计/应用设计”的内容带来的影响更大，因为这个部分是所有干系人都必须要理解的（技术设计
的内容不需要所有干系人都理解），这个设计完成后，不但知道了软件完成后的样子、使用方
法、效果和价值，而且它还是软件生产过程中的核心指导原则（因为它是所有相关人都必须知
道和遵守的）。
笔者认为，要做到提升设计意识，需要从大学和软件企业两个方面同时着手。
1）对大学和大学生
在软件企业内，软件是由“业务人员”和“技术人员”两方面的共同工作完成的，但是大
学和培训机构只培养“从事技术开发的人才”，而缺乏专门培养“从事分析与设计人才”的课
程，这是其他行业所没有的现象。
大学应该增加“分析与设计”相关的学科，在大学生毕业前就要给学生树立基本的设计意
分享
大话软件工程——需求分析与软件设计
识，特别是计算机专业的学生，他们不但要学习编程技术，还要加强业务设计/应用设计的学
习，因为前者主要解决的是“实现”的方法，后者主要解决的是“创新”的能力。如果在大学
阶段就给学生植入了设计意识，学生进入企业后从“程序员”成长为“工程师”的时间和路途
就会大大地缩短。
2）对软件企业和软件工程师
对于软件企业来说，解决的产品的3低（低质量、低价值、低复用）问题，除了提升设计水
平和能力外别无他途。因此，应该以制造业、建筑业等为参考，明确设计的作用和设计师的定
位与价值，要能够肯定地表明：在软件生产过程中，从事业务设计/应用设计的工程师是核心，
并且理解：
●
业务设计/应用设计决定产品的最高价值
最高价值指的是系统为客户的业务提升了效率和效益，这是客户投资信息系统的目的。
●
技术设计/开发保证了产品的最低价值
最低价值指的是系统可用（没有bug、性能优秀），但这不是客户投资信息系统的目的。
2. 利用“图形”表达设计，是提升质量、效率和工程化的基础
生产“产品”，不论是哪个行业都是用图的方法表达设计结果，“用图说话”是设计的常
识。利用图形进行表达和交流，不但可以提升质量和效率，它还是设计工程化的基础。
由于企业管理类软件实现的对象是抽象的（建筑、机械因为内容是具象的，所以比较容易
理解），这就需要从逻辑上理解对象和传递意图。软件行业从业人员（特别是业务人员）有一
个共同的弱点就是缺乏逻辑概念和表达方法。而在用图形进行设计时，由于“逻辑”的表达是
标准的、可见的，因此掌握了图形化的设计方法就能大大地提升相关人员的逻辑表达能力，从
而直接地提升了设计的质量和意图传递效率。
用图形做设计，是质量、效率，也是效益
参加培训的学员中，需求/设计团队与开发团队不在同一个地方工作的现象非常多，而且
现在利用交易平台进行外包设计/外包开发的应用场景也越来越多，这就带来了沟通的效率和
质量问题，原来在同一个地方可以面对面沟通时这个问题还不是那么突出，但是不见面进行
沟通就变得很困难，软件开发不像建筑和制造，后者的图纸是标准的，只要有图纸不论何地
的承包商都可以按图制造。但是软件行业不行，由于缺乏标准的设计方法（特别是业务设计/
应用设计部分），以文字和表格为主的传递效率很低，质量很差，很难做到一看资料就明白
十之八九，这里的一个主要问题就是由于表达的没有图形化造成的（虽然也可使用UML，但
只能在懂得UML的人之间进行传递）。
在培训的前后，老师都要出题让学员用图做设计，然后让大家互相解读对方设计图的意
图，通过这样的训练可以明显地感受到学员们表达和认知能力的提升，由于大家掌握了同一
标准的设计方法，所以在分开进行设计和开发的情况下，不但可以提升工作效率，同时也能
大大地减少原来由于缺乏逻辑表达方式而带来的高沟通成本（时间、人力、经费等）。
案例中的问题说明：因为用图形表达逻辑的方式是标准的，所以双方在读取逻辑时都非常
准确，没有歧义，因此，可以看出图形化的表达方式不但可以大幅度地提升工作效率和效益，
分享
最终还可以促进产品质量的有效提升。
3. 建立“工程”化的设计体系，让软件工程从一门知识转化为一套可操作的“技术”
设计工程化，是提升软件开发的效率、质量、复用率以及强化过程管理的重要手段。
在软件行业中（特别是针对业务设计/应用设计部分），很难确定它们的工作内容、工作
量、所需资源的能力、交付物、交付质量、交付时间等内容，软件的生产过程虽然是一个“工
程”，但由于很多的内容不能定性、定量，所以很难用工程化的方式进行管理。
程序员与工程师，程序与工程
在一次以技术开发者为主的培训会上，老师向学员们提了这样的问题：
●
问大家：认为工程师的能力比程序员高一级的请举手，大家都举了手。
●
问大家：“认为自己是程序员的举左手，认为自己是工程师的举右手”，结果大多数
人举了左手，只有3个人举了右手。
●
问这3人：如果你们认为自己是工程师的话，请说明什么是工程、什么是工程师。
结果这3个人马上就改举左手了（全场大笑）。
“工程”是一个过程，这个过程你不去实践一遍是没有感性认知的，大学毕业进了企业
后直接做了开发工作（程序员），由于不知道分析与设计的过程，因此对自己所开发的功能
是“知其然而不知其所以然”，所以程序员长期都是做“小工”的。
因此老师给新学员提了一个建议：大学毕业进入软件公司后做的第一件事不是做程序
员，而是去做“学徒”，体验一次从需求调研到设计的全过程，这个过程可以帮助你理解什
么是“工程”。这个过程可能要花费2～3个月或更多一些的时间，但这将会大大缩短你从
“程序员→工程师”的距离和时间。如果开始没有花费这个时间，很有可能过了5年甚至是
10年之后，你会发现自己还站在“程序员”的原处，没有走向“工程师”的位置。
从事建筑设计、制造设计的大学毕业生是一样的，他们进入公司后的第一步是先下到工地
/车间去实习，实习一段时间后再进入到设计岗位工作，这使得他们懂得了什么是工程，这个
过程的体验成果使他们受益终身。
学习过软件工程的人很多，但是深知软件工程具体有什么作用的人不多，软件工程的知识
不能落地，不但造成设计水平低、产品价值低，而且对软件过程进行的项目管理也不容易。
本书参照传统工程的设计分类与标准制定的方法，让软件工程从一门“知识”成为一门可
以按部就班学习，并且可以实操的“技术”，同时工程化的做法也可以有效地改变现实中存在
的“业务设计/应用设计”部分的资料“只可字会、不能图传”的现象。
0.3 结尾与致谢
本书讲述的“业务设计与应用设计”内容是对传统软件工程中关于分析和设计部分的探
索、补充和完善，采用的理论、方法、工具和标准等是根据作者从事不同的行业经历、跨界知
识，以及结合业内常见、常用的模型进行整理、设计而成的。书中很多的理念、观点、方法是
根据本人在实践过程中的经验抽提以及对未来的预想而做出的，书中的内容在软件企业的实际
分享
大话软件工程——需求分析与软件设计
工作中进行了多年的应用验证。
本书每一篇内容都有相应的微课视频讲解，扫描篇首页上方的二维码即可观看，816940768（QQ群）为本书技术交流社群，欢迎读者进群交流，相互促进，共同提高。
由于作者本身所具有知识和经历的局限性，所以在书中难免会出现一些理论、方法方面的
谬误之处，欢迎读者朋友提出批评指正。
在此特别感谢同望科技股份有限公司刘洪舟董事长，您推行的银弹谷工程和两阶段软件开
发模式为书中理论和方法的确认提供了非常宝贵的实践平台。
李鸿君
2020年2月于北京
