內容簡介
本書著眼於系統設計之前的需求過程，它是整個開發過程（如何設計人們想要的產品和系統）中最有挑戰性的那部分。通過對一些需求分析中的常見誤區和問題的分析和討論，從和客戶溝通開始，深入研究一些可能的需求，澄清用戶和開發者期望值，最終給出了能夠大幅度提高項目成功幾率的一些建議方法。
本書由該領域內公認的兩位作者合著，蒐集了他們在大大小小的公司里加起來超過60年的在工作中發現、提煉和檢驗之後的觀點。在本書中描述的原則並不局限於軟體開發，還涉及到所有需要為別人設計和製作產品的領域。這些技巧已經成功的套用於開發所有類型的產品和系統--包括計算機硬體和軟體、家具、建築和書籍等等。
本書認為，開發是把人們的期望轉化成一種能夠滿足其期望的產品的過程。本書的討論圍繞著需求過程--在開發中人們試圖發現其期望的產品--的那一部分。通過對五個關鍵字語"期望"、"產品"、"人們"、"試圖"和"發現"的層層分析，給出了大量使用的技巧和觀點。 產品開發項目可能失敗的原因非常多，最糟糕的莫過於在需求過程帶入的缺陷。目前已有了很多書籍來闡述避免那些缺陷的方法，而本書則是集中在需求過程的以下三個危險而又被忽視的人性視角：
1． 在所有參與者中開發一種對需求的可靠的理解。
2． 開發一種項目的團隊工作期望。
3． 開發一些必要的技巧和工具以能夠有效的像團隊一樣來定義需求。
由於這些主題或多或少有些被有關係統開發的著作所忽略，《探索需求》可以用作對你當前的任何需求過程的一個補充，而不管其是否正式。本書的很多章節都設計成獨立的模組，每一個都介紹了一到幾種用於提高需求技術的工具或方法。讀者可以逐頁閱讀本書，也可以在任何時間唯讀那些你最需要的章節。 全書通俗易懂、層次分明，其中共有上百幅插圖，便於讀者深入理解，是需求分析人員的入門和提高必備指南。
目錄
目錄6
序言13
第一部分 為共識而談判17
1 方法論是不夠的18
1.1 case，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
