《探索需求》是2004年清華大學出版社出版的圖書，作者是傑拉爾德・溫伯格，唐納德・高斯，譯者是章柏幸 ，王媛媛 ，謝攀。
基本介紹
- 作者：傑拉爾德・溫伯格，唐納德・高斯
- 譯者：章柏幸、王媛媛、謝攀
- ISBN：9787302088646
- 頁數：362
- 定價：39.00
- 出版社：清華大學出版社
- 出版時間：2004-7-1
- 裝幀：平裝(無盤)
內容簡介,作者簡介,目錄,
內容簡介
本書將與您一起尋找“什麼是客戶真正想要的”這一問題的答案。本書著眼於系統設計前的需求分析，它是整個開發過程（如何設計人們想到的產品和系統）中最有挑戰性的一部分。通過對一些需求分析中的常見誤區和問題的分析和討論，從和客戶溝通開始，深入研究一些可能的需求，澄清用戶和開發者的期望值，最終給出了能夠大幅度提高項目成功幾率的一些建議方法。
本書由該領域內公認的兩位作者合著，蒐集了他們在大大小小的公司里加起來超過60年的、在工作中發現、提煉和檢驗之後的觀點。在本書中描述的原則並不局限於軟體開發，還涉及到所有需要為他人設計和製作產品的領域。這些技巧已經成功的套用於開發所有類型的產品和系統——包括計算機硬體和軟體、家具、建築和書籍等等。
本書認為，開發是把人們的期望轉比成一種能夠滿足其期望的產品的過程。本書的討論圍繞著需求過程——在開發中人們試圖發現其期望的產品——這一部分展開。通過對五個關鍵字語——“期望”、“產品”、“人們”、“試圖”和“發現”的層層分析，給出了大量實用的技巧和觀點。可能導致產品開發項目失敗的原因非常多，其中最糟糕的莫過於在需求階段產生的重大缺陷。針對開發過程中的缺陷管理方法，已有很多專著對其進行了闡述，而本書的主題則集中在以下三個在需求過程中危險的而又被忽視的人性方面：如何在所有參與者中達成一種需求的共識。如何建立開發團隊的工作期望（需求目標）。有哪些技巧和工具能夠幫助我們有效地探索需求。由於上述主題的高度含混性和人性化，一直以來被那些關於系統開發的著作（有意或無意地）忽視，而《探索需求》則可以用作對你當前任何需求過程的一個有力補充。本書的很多章節都可以獨立閱讀，每一章都介紹了若干用於提高需求技術的工具或方法。讀者可以逐頁閱讀本書，也可以在任何時間唯讀那些你最需要的章節。全書通俗易懂、層次分明，書中共有107幅插圖，便於讀者深入理解，是需求分析人員入門和提高的必備指南。
作者簡介
GeraldM.WeinbergGeraldM.Weinberg，美國傑出的專業作家和思想家，著有30多本書籍和數以百計的論文，其主題主要集中在兩個方面：人與技術的結合；人的思維模式、思維習慣以及解決問題的方法。溫伯格（GeraldM.Weinberg）首要的貢獻集中於軟體領域，他是從個體心理、組織行為和企業文化角度研究軟體管理和軟體工程的權威和代表人物。在超過40年的軟體職業生涯中，溫伯格從事過軟體開發，軟體項目管理、軟體管理教學和諮詢，他更是一位傑出的軟體專業作家和思想家。1997年，溫伯格因其在軟體領域的傑出貢獻，被美國計算機博物館的計算機名人堂選為首批5位成員之一。這個名人堂至今只有20名成員。為中國讀者所熟悉的比爾·蓋茨和麥可·戴爾也是在溫伯格之後方才獲得這一計算機界至高無上的殊榮。溫伯格精力旺盛、思想活躍，從20世紀70年代開始，他總共撰寫了30多本書籍和數以百計的論文。在西方國家，溫伯格擁有大量忠實的讀者群，這些"追星族"閱讀了溫伯格的每本重要著作，他們甚至建設有專門的組織和網站，討論和交流大師的重要思想。可以說，溫伯格近年來的每本新書都是在萬眾矚目中推出的。
目錄
目錄 6
序言 13
第一部分為共識而談判 17
1方法論是不夠的 18
1.1CASE,CAD和滅蟑儀 18
1.2方法作用於問題 19
1.3映射及其符號系統 20
1.4確保每個人都能讀懂映射圖 21
1.5需求的映射圖並不是需求 21
1.6提示和變化 22
1.7小結 24
2在陳述需求中的含混性 24
2.1含混性的例子 24
2.1.1缺少的需求 25
2.1.2含混的詞語 25
2.1.3無意中引入的假設 25
2.2含混性的成本 26
2.3為消除含混性而探索 27
2.3.1需求的圖片 27
2.3.2需求的模型 28
2.4提示和變化 28
2.5小結 28
3含混性的來源 29
3.1實例：收斂設計過程演講 29
3.2注意力的測試 30
3.3聚類啟發 31
3.3.1觀察和回憶錯誤 31
3.3.2解釋錯誤 32
3.3.3錯誤來源的混合 32
3.3.4人們互動的作用 32
3.4問題陳述的含混性 33
3.5提示和變化 35
3.6小結 35
4可靠但不真實的直接問題的用法 36
4.1決策樹 36
4.1.1問題的次序 37
4.1.2穿越決策樹：一個實例 37
4.2含混性投票的結果 38
4.3可能會是什麼錯了？ 39
4.4現實生活比我們想像的要現實 40
4.5提示和變化 40
4.6小結 41
第二部分開始之路 42
5切入點 43
5.1一個通用的切入點 43
5.2不同切入點的通用化 43
5.2.1來自解決方案的想法 43
5.2.2來自技術的想法 44
5.2.3比喻 45
5.2.4標準 45
5.2.5實體模型 46
5.2.6名稱 46
5.3存在性假設 46
5.4一個升降機的例子 47
5.4.1命名我們的項目 47
5.5提示和變化 48
5.6小結 48
6自由問題 49
6.1過程的自由問題 49
6.2自由提問的潛在影響 50
6.3產品的自由問題 50
6.4連環問題 51
6.5自由提問的好處 52
6.6提示和變化 53
6.7小結 54
7找到正確的相關人員 55
7.1辨別正確的人員 55
7.1.1客戶和使用者 55
7.1.2為什麼要包括使用者？ 56
7.1.3鐵路的矛盾 56
7.1.4產品能夠創造用戶群 56
7.1.5失敗者是使用者嗎？ 57
7.2啟發式包含使用者 57
7.2.1列出可能的用戶群 57
7.2.2修葺使用者清單 59
7.3參與者 59
7.3.1誰參與？ 60
7.3.2他們什麼時候參與？ 61
7.3.3我們如何得到他們的判斷？ 61
7.4為抓獲使用者而計畫 61
7.5提示和變化 62
7.6小結 62
8為每個人準備會議工作 63
8.1會議：離不開又無法忍受的工具 63
8.1.1一個可怕而典型的會議 63
8.1.2為度量而開會 65
8.2參與和安全 65
8.2.1建立一個打斷機制 66
8.2.2設定時間限制 66
8.2.3反對人身攻擊和貶低 66
8.2.4緩解壓力 66
8.2.5承認結束時間,並且按時結束 66
8.2.6處理相關問題 67
8.2.7改進規則 67
8.3不出席會議也感到安全 67
8.3.1公布一個議程並且堅持它 68
8.3.2不插手突發模式 68
8.3.3處理好不相關的人員 68
8.3.4包含正確的人員 68
8.4設計你需要的會議 69
8.5提示和變化 69
8.6小結 70
9自始至終降低含混性 70
9.1利用記憶啟發 70
9.2延伸含混性投票 71
9.3"瑪麗從前有一隻小羔羊"啟發 71
9.4詳述"瑪麗欺騙商人"啟發 73
9.5在星星問題上套用啟發 75
9.6提示和變化 78
9.7小結 78
第三部分探索機會 79
10產生想法的會議 81
10.1典型的頭腦暴風雪 81
10.2頭腦風暴的第一部分 82
10.2.1不允許批評和責備 82
10.2.2讓你的想像自由飛翔 83
10.2.3為數量而努力 83
10.2.4改變和合成想法 83
10.3頭腦風暴的第二部分 83
10.3.1門限投票法 83
10.3.2競選演講投票法 84
10.3.3合成想法 84
10.3.4套用判據 85
10.3.5打分或者排名系統 85
10.4有益的提示和變化 85
10.5總結 85
11右腦方法 87
11.1地圖工具 87
11.1.1草圖 87
11.1.2畫曲線圖 87
11.2頭腦作圖 88
11.3右腦運動 88
11.4有益的提示和變化 89
11.5總結 89
12項目的名稱 91
12.1工作名稱,綽號和正式名稱 91
12.2名稱的影響 91
12.2.1一個命名的證明 92
12.2.2命名完成了什麼？ 92
12.3啟發式命名方法 93
12.4有益的提示和變化 94
12.5總結 94
13面臨衝突時推動進程 95
13.1處理無關緊要的衝突 95
13.1.1錯誤的時間,錯誤的項目 95
13.1.2個性衝突 96
13.1.3必不可少的人 96
13.1.4組內的偏見 96
13.1.5級別不一樣 97
13.2注意力完全集中的技巧 97
13.3處理本質的衝突 98
13.3.1重塑個性差異 98
13.3.2協商 99
13.3.3處理政治衝突 99
13.4有益的提示和變化 100
13.5總結 100
第四部分明確期望 102
14功能 103
14.1定義功能 103
14.1.1存在功能 103
14.1.2測試功能 103
14.2記錄所有且唯一的功能 104
14.2.1記錄所有潛在的功能 104
14.2.2理解明顯的.隱藏的以及裝飾性的功能 105
14.2.3識別未注意到的功能 106
14.2.4避免隱含的解決方案 107
14.2.5"如果你能夠就實現它"列表 107
14.3有益的提示和變化 108
14.4總結 108
15屬性 110
15.1屬性的願望列表 110
15.2改變願望列表 111
15.2.1區分屬性和屬性細節 111
15.2.2揭示屬性的含混性 111
15.2.3組織列表 112
15.2.4從改變後的列表揭示內幕 112
15.3為功能分配屬性 113
15.3.1屬性如何修改功能 113
15.3.2從新格式中獲取內幕 113
15.4去掉屬性 113
15.4.1將屬性分類為必須,需要和忽略 113
15.4.2隱式和顯式地排除屬性 114
15.5有益的提示和變化 114
15.6總結 115
16約束條件 116
16.1定義約束 116
16.2考慮作為邊界的約束 116
16.3測試約束 118
16.3.1過於嚴格？ 118
16.3.2不夠嚴格？ 118
16.3.3不清楚嗎？ 119
16.3.4產生新的想法 119
16.4相互關聯的約束 119
16.5過度約束 120
16.6心理約束 120
16.6.1傾斜觀念 121
16.6.2打破約束 121
16.6.3自負與糟糕設計的循環 122
16.7約束產生自由 122
16.7.1標準 122
16.7.2語言和其他工具 122
16.8有益的提示和改變 123
16.9總結 124
17優先權 125
17.1定義優先權 125
17.1.1一個例子 126
17.1.2優先權的來源 126
17.2讓優先權可量化 126
17.2.1針對度量的合理方法 126
17.2.2讓優先權可量化 127
17.3區別約束和優先權 127
17.3.1滿足進度是約束嗎？ 127
17.4受到約束的優先權 128
17.4.1它值什麼圖（what's-it-worth?graphs） 129
17.4.2什麼時候你需要它圖（when-do-you-need-it?graph） 129
17.5重新將約束定製為優先權 130
17.5.1在優先權之間交易 130
17.5.2產品開發的決定律 131
17.6有益的提示和變化 132
17.7總結 132
18期望 134
18.1限制期望的原因 134
18.1.1人們不是完美的 134
18.1.2人們並不都是有邏輯的 134
18.1.3人們對事情的感受不一樣 135
18.1.4設計者也是人 135
18.2採用期望限制過程 136
18.2.1產生專門的期望列表 136
18.2.2電梯的例子 136
18.2.3產生期望列表 137
18.2.4限制期望 138
18.3限制條件不必被限制 138
18.3.1輪椅的例子 138
18.3.2讓可能性保持公開 139
18.3.3包括限制的來源 139
18.4有益的提示和變化 139
18.5總結 140
第四部分極大地增加成功的可能 141
19含混性度量 142
19.1測量含混性 142
19.1.1使用含混性投票 142
19.1.2使用投票方法 143
19.1.3在不同的基礎上投票 143
19.2將度量作為測試 143
19.2.1度量三類含混性 143
19.2.2解釋結果 144
19.2.3通過聚類得來信息 144
19.2.4選擇被投票的人群 144
19.3有益的提示和變化 145
19.4總結 145
20技術評論 146
20.1一個走過場的例子 146
20.2技術評論的角色 148
20.2.1正式和非正式的評論 148
20.2.2技術評論與項目評論 148
20.3評論報告 149
20.3.1評論報告所需的東西 149
20.3.2創造問題列表 150
20.3.3技術評論總結報告 150
20.4評論的主要類型 151
20.4.1香草評論 151
20.4.2檢查 152
20.4.3預演 152
20.4.4聯名聲明評論 152
20.5真實與理想的評論 152
20.6有益的變化和提示 153
20.7總結 153
21衡量滿意度 154
21.1創建用戶滿意度測試 154
21.1.1測試屬性 154
21.1.2為每個項目採取的客戶測試 154
21.2使用測試 155
21.2.1好處 155
21.2.2繪製改變和趨勢 156
21.2.3解釋評論 156
21.2.4感覺就是事實 156
21.3測試的其他用處 157
21.3.1交流工具 157
21.3.2貫穿項目的持續作用 158
21.3.3對設計者的用處 158
21.4其他測試 158
21.4.1原型作為滿意度測試 158
21.5有益的提示和變化 159
21.6總結 160
22測試用例 160
22.1黑箱測試 160
22.1.1外部與內部的知識 160
22.1.2構建黑箱測試用例 161
22.1.3測試這些測試用例 162
22.2套用測試用例 162
22.2.1示例 162
22.2.2反覆測試和回答 163
22.2.3清晰地指明含混性 164
22.3以測試用例為證 164
22.4有益的提示和變化 165
22.5總結 166
23學習已存在的產品 166
23.1把現存產品當作標準來使用 166
23.2訪談 167
23.2.1新產品中有什麼不見了？ 167
23.2.2為什麼不見了？ 167
23.2.3在舊產品中遺漏了什麼？ 168
23.2.4在舊需求中遺漏了什麼？ 168
23.3用特徵代替功能 169
23.4有用的提示和變化 170
23.5小結 170
24達成協定 171
24.1決策從哪裡來 171
24.1.1選擇,假設和強迫接受 171
24.1.2電梯設計決策的例子 171
24.1.3撰寫可追溯的需求 172
24.2錯誤假設從哪裡來 173
24.2.1有效信息的缺乏 173
24.2.2逾時失效 173
24.2.3收費公路效應 173
24.2.4需求滲漏 174
24.3把決策轉化為協定 174
24.4有用的提示和變化 174
24.5小結 175
25結束 175
25.1對結束的害怕 176
25.2結束一切的勇氣 176
25.2.1自動化設計和開發 176
25.2.2堆土窯方式 176
25.2.3凍結需求 177
25.2.4重新談判過程 177
25.2.5對做出清晰假設的害怕 177
25.3不夠格的勇氣 178
25.4有用的提示和變化 178
25.5小結 179
參考文獻 179
索引表 179
序言 13
第一部分為共識而談判 17
1方法論是不夠的 18
1.1CASE,CAD和滅蟑儀 18
1.2方法作用於問題 19
1.3映射及其符號系統 20
1.4確保每個人都能讀懂映射圖 21
1.5需求的映射圖並不是需求 21
1.6提示和變化 22
1.7小結 24
2在陳述需求中的含混性 24
2.1含混性的例子 24
2.1.1缺少的需求 25
2.1.2含混的詞語 25
2.1.3無意中引入的假設 25
2.2含混性的成本 26
2.3為消除含混性而探索 27
2.3.1需求的圖片 27
2.3.2需求的模型 28
2.4提示和變化 28
2.5小結 28
3含混性的來源 29
3.1實例：收斂設計過程演講 29
3.2注意力的測試 30
3.3聚類啟發 31
3.3.1觀察和回憶錯誤 31
3.3.2解釋錯誤 32
3.3.3錯誤來源的混合 32
3.3.4人們互動的作用 32
3.4問題陳述的含混性 33
3.5提示和變化 35
3.6小結 35
4可靠但不真實的直接問題的用法 36
4.1決策樹 36
4.1.1問題的次序 37
4.1.2穿越決策樹：一個實例 37
4.2含混性投票的結果 38
4.3可能會是什麼錯了？ 39
4.4現實生活比我們想像的要現實 40
4.5提示和變化 40
4.6小結 41
第二部分開始之路 42
5切入點 43
5.1一個通用的切入點 43
5.2不同切入點的通用化 43
5.2.1來自解決方案的想法 43
5.2.2來自技術的想法 44
5.2.3比喻 45
5.2.4標準 45
5.2.5實體模型 46
5.2.6名稱 46
5.3存在性假設 46
5.4一個升降機的例子 47
5.4.1命名我們的項目 47
5.5提示和變化 48
5.6小結 48
6自由問題 49
6.1過程的自由問題 49
6.2自由提問的潛在影響 50
6.3產品的自由問題 50
6.4連環問題 51
6.5自由提問的好處 52
6.6提示和變化 53
6.7小結 54
7找到正確的相關人員 55
7.1辨別正確的人員 55
7.1.1客戶和使用者 55
7.1.2為什麼要包括使用者？ 56
7.1.3鐵路的矛盾 56
7.1.4產品能夠創造用戶群 56
7.1.5失敗者是使用者嗎？ 57
7.2啟發式包含使用者 57
7.2.1列出可能的用戶群 57
7.2.2修葺使用者清單 59
7.3參與者 59
7.3.1誰參與？ 60
7.3.2他們什麼時候參與？ 61
7.3.3我們如何得到他們的判斷？ 61
7.4為抓獲使用者而計畫 61
7.5提示和變化 62
7.6小結 62
8為每個人準備會議工作 63
8.1會議：離不開又無法忍受的工具 63
8.1.1一個可怕而典型的會議 63
8.1.2為度量而開會 65
8.2參與和安全 65
8.2.1建立一個打斷機制 66
8.2.2設定時間限制 66
8.2.3反對人身攻擊和貶低 66
8.2.4緩解壓力 66
8.2.5承認結束時間,並且按時結束 66
8.2.6處理相關問題 67
8.2.7改進規則 67
8.3不出席會議也感到安全 67
8.3.1公布一個議程並且堅持它 68
8.3.2不插手突發模式 68
8.3.3處理好不相關的人員 68
8.3.4包含正確的人員 68
8.4設計你需要的會議 69
8.5提示和變化 69
8.6小結 70
9自始至終降低含混性 70
9.1利用記憶啟發 70
9.2延伸含混性投票 71
9.3"瑪麗從前有一隻小羔羊"啟發 71
9.4詳述"瑪麗欺騙商人"啟發 73
9.5在星星問題上套用啟發 75
9.6提示和變化 78
9.7小結 78
第三部分探索機會 79
10產生想法的會議 81
10.1典型的頭腦暴風雪 81
10.2頭腦風暴的第一部分 82
10.2.1不允許批評和責備 82
10.2.2讓你的想像自由飛翔 83
10.2.3為數量而努力 83
10.2.4改變和合成想法 83
10.3頭腦風暴的第二部分 83
10.3.1門限投票法 83
10.3.2競選演講投票法 84
10.3.3合成想法 84
10.3.4套用判據 85
10.3.5打分或者排名系統 85
10.4有益的提示和變化 85
10.5總結 85
11右腦方法 87
11.1地圖工具 87
11.1.1草圖 87
11.1.2畫曲線圖 87
11.2頭腦作圖 88
11.3右腦運動 88
11.4有益的提示和變化 89
11.5總結 89
12項目的名稱 91
12.1工作名稱,綽號和正式名稱 91
12.2名稱的影響 91
12.2.1一個命名的證明 92
12.2.2命名完成了什麼？ 92
12.3啟發式命名方法 93
12.4有益的提示和變化 94
12.5總結 94
13面臨衝突時推動進程 95
13.1處理無關緊要的衝突 95
13.1.1錯誤的時間,錯誤的項目 95
13.1.2個性衝突 96
13.1.3必不可少的人 96
13.1.4組內的偏見 96
13.1.5級別不一樣 97
13.2注意力完全集中的技巧 97
13.3處理本質的衝突 98
13.3.1重塑個性差異 98
13.3.2協商 99
13.3.3處理政治衝突 99
13.4有益的提示和變化 100
13.5總結 100
第四部分明確期望 102
14功能 103
14.1定義功能 103
14.1.1存在功能 103
14.1.2測試功能 103
14.2記錄所有且唯一的功能 104
14.2.1記錄所有潛在的功能 104
14.2.2理解明顯的.隱藏的以及裝飾性的功能 105
14.2.3識別未注意到的功能 106
14.2.4避免隱含的解決方案 107
14.2.5"如果你能夠就實現它"列表 107
14.3有益的提示和變化 108
14.4總結 108
15屬性 110
15.1屬性的願望列表 110
15.2改變願望列表 111
15.2.1區分屬性和屬性細節 111
15.2.2揭示屬性的含混性 111
15.2.3組織列表 112
15.2.4從改變後的列表揭示內幕 112
15.3為功能分配屬性 113
15.3.1屬性如何修改功能 113
15.3.2從新格式中獲取內幕 113
15.4去掉屬性 113
15.4.1將屬性分類為必須,需要和忽略 113
15.4.2隱式和顯式地排除屬性 114
15.5有益的提示和變化 114
15.6總結 115
16約束條件 116
16.1定義約束 116
16.2考慮作為邊界的約束 116
16.3測試約束 118
16.3.1過於嚴格？ 118
16.3.2不夠嚴格？ 118
16.3.3不清楚嗎？ 119
16.3.4產生新的想法 119
16.4相互關聯的約束 119
16.5過度約束 120
16.6心理約束 120
16.6.1傾斜觀念 121
16.6.2打破約束 121
16.6.3自負與糟糕設計的循環 122
16.7約束產生自由 122
16.7.1標準 122
16.7.2語言和其他工具 122
16.8有益的提示和改變 123
16.9總結 124
17優先權 125
17.1定義優先權 125
17.1.1一個例子 126
17.1.2優先權的來源 126
17.2讓優先權可量化 126
17.2.1針對度量的合理方法 126
17.2.2讓優先權可量化 127
17.3區別約束和優先權 127
17.3.1滿足進度是約束嗎？ 127
17.4受到約束的優先權 128
17.4.1它值什麼圖（what's-it-worth?graphs） 129
17.4.2什麼時候你需要它圖（when-do-you-need-it?graph） 129
17.5重新將約束定製為優先權 130
17.5.1在優先權之間交易 130
17.5.2產品開發的決定律 131
17.6有益的提示和變化 132
17.7總結 132
18期望 134
18.1限制期望的原因 134
18.1.1人們不是完美的 134
18.1.2人們並不都是有邏輯的 134
18.1.3人們對事情的感受不一樣 135
18.1.4設計者也是人 135
18.2採用期望限制過程 136
18.2.1產生專門的期望列表 136
18.2.2電梯的例子 136
18.2.3產生期望列表 137
18.2.4限制期望 138
18.3限制條件不必被限制 138
18.3.1輪椅的例子 138
18.3.2讓可能性保持公開 139
18.3.3包括限制的來源 139
18.4有益的提示和變化 139
18.5總結 140
第四部分極大地增加成功的可能 141
19含混性度量 142
19.1測量含混性 142
19.1.1使用含混性投票 142
19.1.2使用投票方法 143
19.1.3在不同的基礎上投票 143
19.2將度量作為測試 143
19.2.1度量三類含混性 143
19.2.2解釋結果 144
19.2.3通過聚類得來信息 144
19.2.4選擇被投票的人群 144
19.3有益的提示和變化 145
19.4總結 145
20技術評論 146
20.1一個走過場的例子 146
20.2技術評論的角色 148
20.2.1正式和非正式的評論 148
20.2.2技術評論與項目評論 148
20.3評論報告 149
20.3.1評論報告所需的東西 149
20.3.2創造問題列表 150
20.3.3技術評論總結報告 150
20.4評論的主要類型 151
20.4.1香草評論 151
20.4.2檢查 152
20.4.3預演 152
20.4.4聯名聲明評論 152
20.5真實與理想的評論 152
20.6有益的變化和提示 153
20.7總結 153
21衡量滿意度 154
21.1創建用戶滿意度測試 154
21.1.1測試屬性 154
21.1.2為每個項目採取的客戶測試 154
21.2使用測試 155
21.2.1好處 155
21.2.2繪製改變和趨勢 156
21.2.3解釋評論 156
21.2.4感覺就是事實 156
21.3測試的其他用處 157
21.3.1交流工具 157
21.3.2貫穿項目的持續作用 158
21.3.3對設計者的用處 158
21.4其他測試 158
21.4.1原型作為滿意度測試 158
21.5有益的提示和變化 159
21.6總結 160
22測試用例 160
22.1黑箱測試 160
22.1.1外部與內部的知識 160
22.1.2構建黑箱測試用例 161
22.1.3測試這些測試用例 162
22.2套用測試用例 162
22.2.1示例 162
22.2.2反覆測試和回答 163
22.2.3清晰地指明含混性 164
22.3以測試用例為證 164
22.4有益的提示和變化 165
22.5總結 166
23學習已存在的產品 166
23.1把現存產品當作標準來使用 166
23.2訪談 167
23.2.1新產品中有什麼不見了？ 167
23.2.2為什麼不見了？ 167
23.2.3在舊產品中遺漏了什麼？ 168
23.2.4在舊需求中遺漏了什麼？ 168
23.3用特徵代替功能 169
23.4有用的提示和變化 170
23.5小結 170
24達成協定 171
24.1決策從哪裡來 171
24.1.1選擇,假設和強迫接受 171
24.1.2電梯設計決策的例子 171
24.1.3撰寫可追溯的需求 172
24.2錯誤假設從哪裡來 173
24.2.1有效信息的缺乏 173
24.2.2逾時失效 173
24.2.3收費公路效應 173
24.2.4需求滲漏 174
24.3把決策轉化為協定 174
24.4有用的提示和變化 174
24.5小結 175
25結束 175
25.1對結束的害怕 176
25.2結束一切的勇氣 176
25.2.1自動化設計和開發 176
25.2.2堆土窯方式 176
25.2.3凍結需求 177
25.2.4重新談判過程 177
25.2.5對做出清晰假設的害怕 177
25.3不夠格的勇氣 178
25.4有用的提示和變化 178
25.5小結 179
參考文獻 179
索引表 179
