在软件开发中，需求工作致力于解决提升销售的问题，设计工作致力于解决降低成本的问题，二者不能相互取代。能低成本生产某个系统，不一定能保证它好卖。系统好卖，如果生产成本太高，*终还是赚不了多少钱。
如果需求和设计不分，利润就会缩水。从需求直接映射设计，会得到大量重复代码；如果从设计出发来定义需求，会得到一堆假的需求。
《软件方法（上）：业务建模和需求（第2版）》在主要思想不变的前提下，结合*近几年的发展，从文字到图形进行更新，每一章的内容更加细致，道理讲得更加严谨，例子和练习也更加丰富，希望能给读者提供帮助。
截至2013年7月，潘加宇老师已经上门为超过190家软件组织提供需求和设计技能的训练和咨询服务（2017年10月的数字已超过260家）。为了更好的理解软件方法和软件组织，潘加宇老师推荐大家阅读的需求和设计书籍和资料：见书XVI-XIX页。《软件方法（上）：业务建模和需求（第2版）》不提供练习题答案，请扫码（二维码见书中习题）完成在线测试，做到全对，自然就知道答案了。
每当变幻时，便知时光去。
《每当变幻时》；词：卢国沾，曲：古贺政男，唱：薰妮；1985
前 言
2013年写的第一版前言，现在看来依然可以用，所以除了修改一些随年份变化的数字之外，我把第一版前言附在后面，本次版本的前言就尽量写得简短一些。
在主要思想不变的前提下，我结合最近几年的进展，几乎把整《软件方法（上）：业务建模和需求（第2版）》重新写了一遍，从文字到图形基本上都换了。每一章的内容更细致，道理讲得更严谨，例子和练习也更丰富。总之，希望能给读者带来一本更有用的书。《软件方法（上）：业务建模和需求（第2版）》出版之后，将继续投入未写完的《软件方法（下）：分析和设计》。
18年过去，弹指一挥间。我已经在这一个狭窄的领域泡了十八年了，也许累计的时间已经超过了一些前辈。希望还能再研究十八年，和大家分享更多有价值的东西。
潘加宇
2017年10月
光阴匆匆似流水，它一去不再回。
《浪子归》；词：黄小茂，曲：崔健，唱：崔健；1985
前言（2013版）
1999年还是一名程序员时，我创建了UMLChina，从那时开始关注软件工程各方面的进展。2001年12月，阿里巴巴的吴泳铭来email询问是否有UML方面的训练，我开始准备训练材料。2002年3月，我去杭州给阿里巴巴做了这个训练。虽然与后来我给阿里集团各公司做的许多次训练相比，这第一次讲课从内容到形式都算是糟透了，但是我现在还记得当时的心情迈出自己事业第一步的心情。
截至2013年7月，我已经上门为超过190家软件组织提供需求和设计技能的训练和咨询服务（2017年注：2017年10月的数字为超过260家）。训练结束后，学员们常会问：潘老师，上完课后我们应该看什么书？我总是回答：先不用看杂七杂八的书，还是要复习我们留下的资料，那些幻灯片、练习题、模型就已经是最好的书了，按照改进指南先用一点点在具体项目上，带着出现的具体困惑和我讨论。虽然一再这样强调，有的学员还是情不自禁地拿着一本《***UML***》之类的书来问我问题，不管书上说得对不对。看来写在正式出版物上的效果就是不一样。
其实现在出书也不难，UMLChina一直在和出版社合作推介国外优秀的软件工程书籍，目前UMLChina的标记已经出现在三十多本软件工程书籍上。不过我一直没有自己写一《软件方法（上）：业务建模和需求（第2版）》，主要原因还是觉得积累不够，思考的深度也不够，对软件开发的认识还在不断变化。如果没有自己成形的东西，不能站在别人的肩膀上看得更远，只是摘抄别人的观点，这样的书有什么意义呢？
另外一个原因是，UMLChina后来采取了隐形、关门的策略，秉持内外有别的原则。我关闭了已经有4万多人的Smiling电子小组（也是为了降低某些风险），网站不再有公开的社区，在网站上也找不到客户名单，所有更细致的服务以非公开的方式对会员提供。在这种情况下，出一《软件方法（上）：业务建模和需求（第2版）》也不是那么迫切。
现在距离第一次提供服务已经超过10年（2017年注：已经超过15年了），也有了一些积累，所以硬着头皮也要开始写书了。在这些年的服务过程中，和开发团队谈到改进时，我发现一个有趣的现象：很多开发团队（不是每个团队）或多或少都会有人（不是每个人）或明或暗地表达出这样的观点自己团队的难处与众不同，奇特的困难降临在他们身上，偏偏别人得以幸免。
尽管UMLChina一直强调自己的服务是聚焦最后一公里，坚信每一个开发团队都会在细节上和其他团队有所不同，而且也应该有所不同，但很多时候，我还是感觉到，开发团队高估了自己的个性，低估了共性。《软件方法（上）：业务建模和需求（第2版）》就是归纳这样一些共性，作为我的一家之言，供大家参考。感谢曾经选择我的服务的伙伴们。他们一次次地给我机会来实践、发展和锤炼技艺，才有了这《软件方法（上）：业务建模和需求（第2版）》。
《软件方法（上）：业务建模和需求（第2版）》中所讲述的技能集合也是我本人身体力行的。例如，您可能已经注意到，为《软件方法（上）：业务建模和需求（第2版）》写推荐序的正是《软件方法（上）：业务建模和需求（第2版）》的老大，他不是什么大师专家名人，而是一名经历了入职、升职和创业，不断成长的软件开发人员。
一些书籍作者喜欢在书中每一章的开头放上和该章内容相关的一幅画或一句名人名言，我也效仿一下，不过没那么高雅每章的开头放上和该章内容相关的一句歌词。
书中的模型图，如果是我为了讲解知识而画的，用的建模工具是Enterprise Architect 9（2017年注：改为Enterprise
Architect 13）；如果是截取真实模型的图片，可能会涉及各种工具。我不像Robert C. Martin那样，女儿已经长大到可以帮画插图，所以书中的手绘插图，我都自己用Wacom 笔来画，可能丑了一些，请见谅。
潘加宇
2013年10月
潘加宇UMLChina首席专家从1999年起潜心研究需求和设计技能。2002年开始对外提供UML需求和设计的技术指导和训练服务。到2017年为止，已经上门为超过260家的组织提供服务，覆盖国内各个领域的领袖企业，包括通信、企业管理、电子商务、房地产、网络游戏、地理信息、物流、数码设备、医疗设备、工业控制等。潘加宇联系方式：见书第XIV页。
目 录
第1章 建模和UML 1
1.1 粗放经营的时代已经远去 1
1.2 利润＝需求－设计 2
1.3 建模工作流 4
1.4 UML简史 11
1.5 UML应用于建模工作流 14
1.6 基本共识上的沟通 16
1.7 建模和敏捷（Agile） 19
1.8 什么样的系统不需要建模 21
1.8.1 市场没有小系统 21
1.8.2 你的系统不特别 23
1.9 案例介绍 24
1.10 模型的组织 25
1.11 工具操作 28
第2章 业务建模之愿景 33
2.1 什么是愿景（Vision） 33
2.2 【步骤】定位目标组织和老大 35
2.2.1 目标组织和老大的含义 35
2.2.2 定位情况1：定位目标人群和老大 37
2.2.3 定位情况2：定位机构范围和老大 42
2.2.4 定位情况3：定位目标机构 46
2.2.5 其他一些要点 47
2.3 【步骤】提炼改进目标 53
2.3.1 改进目标不是系统功能需求 53
2.3.2 改进目标不是系统的质量需求 56
2.3.3 改进是系统带来的 57
2.3.4 改进目标应来自老大的视角 58
2.3.5 多个目标之间的权衡 59
2.4 【案例和工具操作】愿景 61
第3章业务建模之业务用例图 65
3.1 软件是组织的零件 65
3.2 【步骤】识别业务执行者 68
3.2.1 业务执行者（Business Actor） 68
3.2.2 业务工人和业务实体 68
3.2.3 识别业务执行者 71
3.3 【步骤】识别业务用例 75
3.3.1 正确理解价值 77
3.3.2 识别业务用例的思路和常犯错误 80
3.4 【案例和工具操作】业务用例图 88
第4章业务建模之业务序列图 95
4.1 描述业务流程的手段 95
4.1.1 文本 95
4.1.2 活动图 96
4.1.3 序列图 97
4.1.4 序列图和活动图比较 98
4.2 业务序列图要点 101
4.2.1 消息代表责任分配而不是数据流动 101
4.2.2 抽象级别是系统之间的协作 102
4.2.3 只画核心域相关的系统 106
4.2.4 把时间看作特殊的业务实体 107
4.2.5 为业务对象分配合适的责任 107
4.3 【步骤】现状业务序列图 109
4.3.1 错误：把想象中的改进当成现状 110
4.3.2 错误：把现状误解为纯手工 110
4.3.3 错误：把现状误解为本开发团队未参与之前
111
4.3.4 错误：把现状误解为规范 112
4.3.5 错误：我是创新，没有现状 112
4.3.6 错误：我做产品，没有现状 112
4.4 【案例和工具操作】现状业务序列图 115
4.5 【步骤】改进业务序列图 124
4.5.1 改进模式一：物流变成信息流 125
4.5.2 改进模式二：改善信息流转 126
4.5.3 改进模式三：封装领域逻辑 129
4.5.4 阿布思考法 131
4.6 【案例和工具操作】改进业务序列图 137
第5章需求之系统用例图 145
5.1 系统执行者要点 145
5.1.1 系统是能独立对外提供服务的整体 146
5.1.2 系统边界是责任的边界 147
5.1.3 系统执行者和系统有交互 149
5.1.4 交互是功能性交互 151
5.1.5 系统执行者可以是人或非人系统 152
5.2 【步骤】识别系统执行者 154
5.3 系统用例要点 158
5.3.1 价值是买卖的平衡点 158
5.3.2 价值不等于可以这样做 160
5.3.3 增删改查用例的根源是从设计映射需求 163
5.3.4 从设计映射需求错误二：复用用例 165
5.3.5 系统用例不存在层次问题 170
5.3.6 用例的命名是动宾结构 173
5.4 【步骤】识别系统用例 178
5.5 【案例和工具操作】系统用例图 181
第6章需求之系统用例规约 187
6.1 用例规约的内容 187
6.1.1 前置条件和后置条件 188
6.1.2 涉众利益 193
6.1.3 基本路径 200
6.1.4 扩展路径 211
6.1.5 补充约束 217
6.2 【案例和工具操作】系统用例规约 227
第7章需求启发 245
7.1 需求启发要点 245
7.2 需求启发手段 249
7.2.1 研究资料 249
7.2.2 问卷调查 250
7.2.3 访谈 251
7.2.4 观察 253
7.2.5 研究竞争对手 254
7.3 需求人员的素质培养 255
7.3.1 好奇心 256
7.3.2 探索力 257
7.3.3 沟通力 257
7.3.4 表达力 258
7.3.5 热情 258
书评 263
书单推荐
