軟件需求管理：統(tǒng)一方法

第一部分   引      言
第1章   需求問題 3
1.1   目標 3
1.2   有關數(shù)據(jù) 3
1.3   項目成功和失敗的根本原因 4
1.3.1   需求錯誤的頻率 5
1.3.2   需求錯誤的高昂代價 6
1.3.3   結論 7
第2章   需求管理簡介 9
2.1   定義 9
2.1.1   什么是需求 9
2.1.2   什么是需求管理 9
2.2   需求管理技術的應用 10
2.2.1   軟件應用程序的類型 10
2.2.2   系統(tǒng)應用程序 10
2.3   路線圖 11
2.3.1   問題領域 11
2.3.2   風險承擔人的需要 11
2.3.3   向解決方案領域前進 12
2.3.4   系統(tǒng)的特征 12
2.3.5   軟件需求 12
2.3.6   用例介紹 12
2.4   小結 13
第3章   軟件團隊 14
3.1   把軟件開發(fā)作為一種團隊活動 14
3.1.1   有效需求管理所需要的團隊技能 15
3.1.2   團隊成員具有不同的技能 15
3.1.3   軟件團隊的組織 16
3.2   個例研究 16
3.2.1   個例研究的背景 16
3.2.2   HOLIS軟件開發(fā)團隊 17
3.3   小結 17
第二部分   團隊技能之一—分析問題
第4章   問題分析的五個步驟 21
4.1   第一步：在問題定義上達成共識 22
4.2   第二步：理解根本理由—
問題背后的問題 23
4.3   第三步：確定風險承擔人和用戶 25
4.4   第四步：定義解決方案系統(tǒng)的界限 26
4.5   第五步：確定加在解決方案上的約束 27
4.6   小結 29
4.7   展望 29
第5章   商業(yè)建模 31
5.1   商業(yè)建模的目的 31
5.2   利用軟件工程技術進行商業(yè)建模 32
5.2.1   選擇正確的技術 32
5.2.2   統(tǒng)一建模語言UML 32
5.2.3   利用UML的概念進行商業(yè)建模 33
5.3   從商業(yè)模型到系統(tǒng)模型 34
5.4   何時使用商業(yè)建模 35
5.5   小結 35
5.6   展望 35
第6章   軟件密集型系統(tǒng)的系統(tǒng)工程 36
6.1   什么是系統(tǒng)工程 36
6.1.1   系統(tǒng)工程的實用準則 37
6.1.2   復雜系統(tǒng)的組合和分解 37
6.2   系統(tǒng)工程中的需求分配 38
6.2.1   關于派生的需求 39
6.2.2   無聲的演化 39
6.2.3   沖突何時產生：資深系統(tǒng)工程師碰上年輕程序員 40
6.2.4   避免“煙囪”系統(tǒng)問題 41
6.2.5   當子系統(tǒng)是轉包合同時 41
6.2.6   使系統(tǒng)正確實現(xiàn) 41
6.3   個例研究 42
6.3.1   基本用戶需要 42
6.3.2   問題分析 43
6.3.3   HOLIS：系統(tǒng). 參與者和
風險承擔人 44
6.3.4   HOLIS系統(tǒng)工程 45
6.3.5   HOLIS子系統(tǒng) 46
團隊技能之一小結 47
第三部分   團隊技能之二
—理解用戶的需要
第7章   需求啟發(fā)的挑戰(zhàn) 51
7.1   啟發(fā)的障礙 51
7.1.1  “是的, 但是”綜合癥 51
7.1.2  “尚未發(fā)現(xiàn)的遺址”綜合癥 52
7.1.3  “用戶和開發(fā)人員”綜合癥 52
7.2   需求啟發(fā)的技術 53
第8章   產品或系統(tǒng)的特征 54
8.1   風險承擔人和用戶的需要 54
8.2   特征 54
8.2.1   通過對抽象級別的選擇來管理復雜度 56
8.2.2   產品特征的屬性 56
第9章   面談 58
9.1   面談的背景 58
9.2   增值背景 59
9.3   真實的時刻：面談 61
9.4   編輯需要數(shù)據(jù) 62
9.4.1   分析人員的總結：10＋10＋10≠30 62
9.4.2   個例研究 62
9.5   對問卷調查的注解 63
第10章   需求專題討論會 65
10.1   加速決策過程 65
10.2   專題討論會的準備 65
10.2.1   推銷概念 66
10.2.2   確保真正的風險承擔人的參與 66
10.2.3   后勤保障 66
10.2.4   “熱身材料” 66
10.3   聯(lián)絡員的作用 68
10.4   安排日程 68
10.5   舉行專題討論會 69
10.5.1   折衷的問題與技巧 69
10.5.2   自由討論和意見精簡 70
10.5.3   成果和監(jiān)督執(zhí)行 71
第11章   自由討論和意見精簡 72
11.1   現(xiàn)場自由討論 72
11.2   意見精簡 74
11.2.1   修剪 74
11.2.2   把意見歸類 74
11.2.3   特征定義 75
11.2.4   確定優(yōu)先次序 75
11.3   基于萬維網(wǎng)的自由討論 76
11.4   個例研究：HOLIS 2000需求
專題討論會 77
11.4.1   參加人員 77
11.4.2   專題討論會 77
11.4.3   會議 77
11.5   結果分析 79
第12章   情節(jié)串聯(lián)板制作 80
12.1   情節(jié)串聯(lián)板的類型 80
12.2   情節(jié)串聯(lián)板做什么 81
12.3   情節(jié)串聯(lián)板制作的工具和技術 82
12.4   情節(jié)串聯(lián)板制作的幾點提示 82
12.5   小結 83
第13章   應用用例 86
13.1   構建用例模型 86
13.2   應用用例啟發(fā)需求 87
13.3   個例研究：HOLIS的用例 88
13.4   小結 89
第14章   角色扮演 90
14.1   如何扮演角色 90
14.2   與角色扮演類似的技術 91
14.2.1   腳本預演 91
14.2.2   CRC卡 91
14.3   小結 92
第15章   原型開發(fā) 93
15.1   原型的類型 93
15.2   需求原型 93
15.3   原型的對象 95
15.4   構建原型 95
15.5   評估結果 95
15.6   小結 96
團隊技能之二小結 96
第四部分   團隊技能之三—定義系統(tǒng)
第16章   組織需求信息 99
16.1   組織復雜硬件系統(tǒng)和軟件系統(tǒng)的需求 100
16.2   組織產品系列的需求 102
16.3   關于“未來”需求 102
16.4   商業(yè)和市場需求與產品需求的比較 103
16.5   個例研究 103
16.6   小結 104
第17章   前景文檔 105
17.1   前景文檔的組件 105
17.2  “d前景”文檔 107
17.2.1   1.0版本的前景文檔 108
17.2.2   2.0版本的前景文檔 108
17.3   遺留系統(tǒng)環(huán)境中的d前景文檔 110
第18章   負責人 111
18.1   產品負責人的作用 111
18.2   軟件產品環(huán)境中的產品負責人 112
18.3   IS/IT商店里的產品負責人 113
團隊技能之三小結 114
第五部分   團隊技能之四—管理廣度
第19章   項目廣度問題 117
19.1   項目廣度的組件 117
19.2   難題 119
第20章   建立項目廣度 120
20.1   需求基線 120
20.2   設定優(yōu)先級 121
20.3   評估工作量 121
20.4   加入風險因素 122
20.5   縮小廣度 123
20.6   個例研究 125
第21章   管理客戶 128
21.1   促使客戶管理他們的項目廣度 128
21.2   交流結果 128
21.3   與客戶協(xié)商 128
21.4   管理基線 129
21.4.1   正式變更 130
21.4.2   非正式變更 130
第22章   廣度管理和軟件開發(fā)過程模型 131
22.1   瀑布模型 131
22.2   螺旋模型 133
22.3   迭代方法 134
22.3.1   生命周期階段 135
22.3.2   迭代 135
22.3.3   工作流程 136
22.4   做什么, 做什么…… 137
團隊技能之四小結 137
第六部分   團隊技能之五—細化系統(tǒng)定義
第23章   軟件需求 141
23.1   軟件需求的定義 142
23.2   特征和軟件需求之間的關系 143
23.3   需求的兩難問題：做什么與如何做 143
23.3.1   排除項目信息 144
23.3.2   排除設計信息 144
23.4   更多有關需求與設計的討論 145
23.5   需求的其他特性 146
23.5.1   功能性軟件需求 147
23.5.2   非功能性軟件需求 147
23.5.3   設計約束 150
23.5.4   設計約束是真正的需求嗎 151
23.6   采用父-子需求提高確切性 152
23.7   展望 153
第24章   細化用例 154
24.1   要問的問題 154
24.1.1   什么時候應該采用用例方法 154
24.1.2   什么時候用例不是最佳選擇 154
24.1.3   冗余問題 155
24.2   細化用例的規(guī)格說明 155
24.2.1   用例是如何演變的 156
24.2.2   用例的廣度 157
24.3   個例研究：一個簡單用例的解剖 157
24.3.1   定義參與者 157
24.3.2   通過命名用例來定義用例 157
24.3.3   寫一個簡明的描述 158
24.3.4   定義事件流程 158
24.3.5   確定前置條件和后置條件 159
24.4   展望  160
第25章   現(xiàn)代軟件需求規(guī)格說明 161
25.1   現(xiàn)代SRS包 161
25.1.1   現(xiàn)代SRS包歸誰所有 163
25.1.2   組織現(xiàn)代SRS包 163
25.2   為功能性需求建檔 165
25.3   展望 166
第26章   歧義性和確切性 167
26.1   找到“最佳擊球點” 167
26.2   瑪麗有只小羊羔 169
26.3   消除歧義的技術 170
26.4   做什么 171
第27章   軟件需求的質量度量 172
27.1   九個質量度量 172
27.1.1   正確的需求 172
27.1.2   無歧義的需求 173
27.1.3   需求集的完備性 173
27.1.4   需求集的一致性 175
27.1.5   根據(jù)重要性和穩(wěn)定性給需求分級 175
27.1.6   可驗證的需求 176
27.1.7   可修改的需求集 177
27.1.8   可跟蹤的需求 177
27.1.9   可理解的需求 178
27.2   用例模型的質量度量 178
27.2.1   用例規(guī)格說明 178
27.2.2   用例的參與者 179
27.3   現(xiàn)代SRS包的質量度量 180
27.3.1   好的目錄 180
27.3.2   好的索引 180
27.3.3   修正記錄 181
27.3.4   詞匯表 181
第28章   說明需求的技術性方法 182
28.1   說明需求的技術性方法 182
28.1.1   偽代碼 182
28.1.2   有限狀態(tài)機 183
28.1.3   決策樹和決策表 184
28.1.4   圖形決策樹 185
28.1.5   活動圖 185
28.1.6   實體聯(lián)系模型 186
28.1.7   面向對象建模 187
28.1.8   數(shù)據(jù)流圖 188
28.2   規(guī)格說明的維護 189
28.3   個例研究 189
團隊技能之五小結 189
第七部分   團隊技能之六—構建正確系統(tǒng)
第29章   正確地構建正確系統(tǒng)：概述 193
29.1   不斷證實開發(fā)沿著正確的方向 193
29.1.1   軟件驗證的原則 193
29.1.2   驗證的耗費 194
29.1.3   在所有層次上進行驗證 194
29.1.4   驗證的原因 195
29.2   證實開發(fā)結果是正確的 195
29.3   學習處理開發(fā)過程中出現(xiàn)的變更 196
29.4   展望 196
第30章   從需求到實現(xiàn) 197
30.1   把需求映射到設計和代碼 197
30.1.1   不相關問題 197
30.1.2   面向對象 198
30.1.3   把用例作為需求 199
30.1.4   管理過渡 199
30.1.5   軟件系統(tǒng)建模 199
30.1.6   用例模型在體系結構中的作用 201
30.2   在設計模型中實現(xiàn)用例 201
30.2.1   協(xié)作的結構方面和行為方面 202
30.2.2   利用協(xié)作實現(xiàn)個體需求集 203
30.3   從設計到實現(xiàn) 203
30.4   小結 204
30.5   展望 204
第31章   利用可跟蹤性支持驗證 205
31.1   需求驗證中可跟蹤性的作用 205
31.1.1   隱式跟蹤與顯式跟蹤 206
31.1.2   其他要考慮的可跟蹤選項 207
31.2   使用跟蹤工具 207
31.3   在沒有跟蹤工具條件下進行 210
31.3.1   被忽略的驗證關系 211
31.3.2   過度的驗證關系 211
31.4   有關驗證和可跟蹤性的思考 213
31.5   展望 213
第32章   確認系統(tǒng) 214
32.1   確認 214
32.1.1   驗收測試 214
32.1.2   確認測試 215
32.1.3   確認跟蹤 215
32.1.4   基于需求的測試 216
32.2   個例研究：測試用例 216
32.2.1   測試實例1描述 216
32.2.2   跟蹤測試實例 217
32.3   測試離散需求 217
32.3.1   被忽略的確認關系 218
32.3.2   過度的確認關系 219
32.4   測試設計約束 220
32.5   展望 220
第33章   利用投資收益決定V&V工作量 221
33.1   深度與覆蓋 221
33.1.1   V&V深度 221
33.1.2   V&V覆蓋 222
33.2   驗證和確認什么 222
33.2.1   第1種選擇：驗證和確認一切 222
33.2.2   第2種選擇：利用冒險分析來
決定V&V的必要性 223
33.2.3   把冒險分析作為投資收益 224
33.3   展望 224
第34章   管理變更 225
34.1   為什么需求會變更 225
34.2   外部因素 225
34.3   內部因素 226
34.4   “我們已經(jīng)遇到了敵人, 而且敵人
就是我們自己” 226
34.5   管理變更的過程 227
34.5.1   第1步：認識到變更是不可避免的并為
變更制定計劃 227
34.5.2   第2步：確定需求的基線 228
34.5.3   第3步：建立控制變更的惟一渠道 228
34.5.4   第4步：使用變更控制系統(tǒng)來
捕獲變更 229
34.5.5   第5步：分層次地管理變更 231
34.6   需求配置管理 231
34.6.1   基于工具的變更管理 233
34.6.2   變更所影響的元素 234
34.6.3   變更記錄的審計追蹤 235
34.6.4   配置管理和變更管理 235
34.7   小結 235
團隊技能之六小結 236
第八部分   開      始
第35章   開始 240
35.1   致詞 240
35.2   已經(jīng)學到的主要內容 240
35.2.1   引言 240
35.2.2   團隊技能之一：分析問題 241
35.2.3   團隊技能之二：理解用戶的需要 241
35.2.4   團隊技能之三：定義系統(tǒng) 242
35.2.5   團隊技能之四：管理廣度 242
35.2.6   團隊技能之五：細化系統(tǒng)定義 243
35.2.7   團隊技能之六：構建正確系統(tǒng) 243
35.3   需求管理的方案 244
35.3.1   簡化的假設 244
35.3.2   方案 244
35.4   現(xiàn)在開始下一個版本 246
附      錄
附錄A   HOLIS制品 248
附錄B   前景文檔模板 272
附錄C   現(xiàn)代SRS包模板 279
附錄D   SEI-CMM和ISO 9000
中的需求管理 285
附錄E   Rational統(tǒng)一過程中的需求管理 290
參考文獻 299
索引