軟件方法：業(yè)務建模和需求（上冊）

第1章.建模和UML 1
1.1 粗放經營的時代已經遠去 1
1.2 利潤＝需求－設計  2
1.3 核心工作流  4
1.4 UML 簡史  9
1.5 各工作流中的UML  12
1.6 基本共識上的溝通 14
1.7 溝通僅限于開發(fā)團隊內部  16
1.8 方法和過程  18
1.9 案例介紹  20
1.10 模型的組織 21
1.11 工具操作  25
第2章 愿景27
2.1 最不可缺的工件  27
2.2 愿景的定義  28
2.3 老大 29
2.4 把產品當項目——定位具體的組織（人群） 31
2.5 尋找老大：要點和典型錯誤  34
2.6 可度量的目標 36
2.7 揣摩目標度量 38
2.8 涉眾利益 40
2.9 可以積累的財富 42
2.10 案例  45
2.11 工具操作 46
第3章.業(yè)務建模之業(yè)務用例圖 47
3.1 軟件是組織的零件 47
3.2 業(yè)務建模步驟1-1 ：選定要改進的組織 49
3.3 業(yè)務建模步驟1-2 ：組織的業(yè)務用例圖 54
3.3.1 業(yè)務執(zhí)行者 54
3.3.2 業(yè)務工人和業(yè)務實體 55
3.3.3 尋找業(yè)務執(zhí)行者 57
3.3.4 業(yè)務用例 58
3.4 案例  65
3.5 工具操作67
3.6 總結   75
第4章.業(yè)務建模之業(yè)務序列圖77
4.1 描述業(yè)務流程的手段 77
4.2 業(yè)務序列圖要點 87
4.2.1 消息代表責任分配而不是數據流動 87
4.2.2 聚焦于系統(tǒng)之間的協(xié)作 88
4.2.3 只畫核心域相關的系統(tǒng) 91
4.2.4 把時間看作特殊的業(yè)務實體 92
4.3 業(yè)務建模步驟1-3 ：現(xiàn)狀業(yè)務序列圖 92
4.3.1 錯誤：把“現(xiàn)狀”誤解為“純手工”93
4.3.2 錯誤：把“現(xiàn)狀”誤解為“規(guī)范” 93
4.3.3 錯誤：以待開發(fā)系統(tǒng)為中心拼湊流程 94
4.4 案例  96
4.5 工具操作 100
4.6 業(yè)務建模步驟1-4 ：改進業(yè)務序列圖117
4.6.1 改進一：物流變成信息流 118
4.6.2 改進二：改善信息流轉 120
4.6.3 改進三：封裝領域邏輯 121
4.6.4 阿布思考法123
4.7 案例 129
4.8 工具操作 131
第5章.需求之系統(tǒng)用例圖139
5.1 系統(tǒng)執(zhí)行者要點 139
5.2 需求步驟2-1 ：識別系統(tǒng)執(zhí)行者 143
5.3 系統(tǒng)用例要點 146
5.4 需求步驟2-2 ：識別系統(tǒng)用例 154
5.5 用例的進一步講解 157
5.5.1 錯誤：玩弄“復用” 157
5.5.2 錯誤：玩弄“層次”163
5.5.3 錯誤：玩弄“子系統(tǒng)” 163
5.5.4 錯誤：模糊的價值164
5.5.5 提示：大用例無妨小用例 167
5.5.6 提示：用例的命名167
5.6 案例  169
5.7 工具操作 170
5.8 總結 176
第6章.需求之系統(tǒng)用例規(guī)約177
6.1 需求步驟2-3 ：書寫系統(tǒng)用例規(guī)約 177
6.1.1 前置條件和后置條件178
6.1.2 涉眾利益183
6.1.3 基本路徑 189
6.1.4 擴展路徑196
6.1.5 補充約束  199
6.2 案例 206
6.3 工具操作 209
第7章.需求之需求啟發(fā) 227
7.1 啟發(fā)障礙 227
7.2 需求啟發(fā)手段 229
7.2.1 研究資料229
7.2.2 問卷調查 230
7.2.3 訪談  230
7.2.4 觀察  233
7.2.5 研究競爭對手234
7.3 需求工程師236
7.3.1 好奇心  236
7.3.2 探索力  237
7.3.3 溝通力  238
7.3.4 表達力  239
7.3.5 熱情  240