在軟件開發中，需求工作致力于解決提升銷售的問題，設計工作致力于解決降低成本的問題，二者不能相互取代。能低成本生產某個系統，不一定能保證它好賣。系統好賣，如果生產成本太高，*終還是賺不了多少錢。
如果需求和設計不分，利潤就會縮水。從需求直接映射設計，會得到大量重復代碼；如果從設計出發來定義需求，會得到一堆假的需求。
《軟件方法（上）：業務建模和需求（第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
新書資訊