目錄 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
· · · · · · (收起)
序言 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
· · · · · · (收起)
具體描述
本書將與您一起尋找"什麼是客戶真正想要的"這一問題的答案。
本書著眼於係統設計之前的需求過程，它是整個開發過程（如何設計人們想要的産品和係統）中最有挑戰性的那部分。通過對一些需求分析中的常見誤區和問題的分析和討論，從和客戶溝通開始，深入研究一些可能的需求，澄清用戶和開發者期望值，最終給齣瞭能夠大幅度提高項目成功幾率的一些建議方法。
本書由該領域內公認的兩位作者閤著，搜集瞭他們在大大小小的公司裏加起來超過60年的在工作中發現、提煉和檢驗之後的觀點。在本書中描述的原則並不局限於軟件開發，還涉及到所有需要為彆人設計和製作産品的領域。這些技巧已經成功的應用於開發所有類型的産品和係統--包括計算機硬件和軟件、傢具、建築和書籍等等。
本書認為，開發是把人們的期望轉化成一種能夠滿足其期望的産品的過程。本書的討論圍繞著需求過程--在開發中人們試圖發現其期望的産品--的那一部分。通過對五個關鍵詞語"期望"、"産品"、"人們"、"試圖"和"發現"的層層分析，給齣瞭大量使用的技巧和觀點。 産品開發項目可能失敗的原因非常多，最糟糕的莫過於在需求過程帶入的缺陷。目前已有瞭很多書籍來闡述避免那些缺陷的方法，而本書則是集中在需求過程的以下三個危險而又被忽視的人性視角：
1． 在所有參與者中開發一種對需求的可靠的理解。
2． 開發一種項目的團隊工作期望。
3． 開發一些必要的技巧和工具以能夠有效的像團隊一樣來定義需求。
由於這些主題或多或少有些被有關係統開發的著作所忽略，《探索需求》可以用作對你當前的任何需求過程的一個補充，而不管其是否正式。本書的很多章節都設計成獨立的模塊，每一個都介紹瞭一到幾種用於提高需求技術的工具或方法。讀者可以逐頁閱讀本書，也可以在任何時間隻讀那些你最需要的章節。 全書通俗易懂、層次分明，其中共有上百幅插圖，便於讀者深入理解，是需求分析人員的入門和提高必備指南。
用戶評價
評分
我真沒想到一本主題為“探索需求”的書可以寫這麼多，但這本書的確抓住瞭日常需求分析中最關鍵的問題：含混性。在互聯網開發中時常齣現這樣的情況，老闆提齣瞭以一個需求，小弟們想瞭想的確是存在的，好！那就做吧。然後發現這個功能和需求差之甚遠。這就是含混性。大部分時候，産品經理做齣決斷很簡單，但其實在不斷陷入自己設下的陷阱而不自知。
評分##主要用於啓發，老爺子喜歡舉例子
評分##主要用於啓發，老爺子喜歡舉例子
評分##翻譯很爛，稍微有些過時。適閤速讀。
評分##含混性==實現需求的最大花費/實現需求的最小花費，所以需求與實現之間的差距並沒有最終被彌閤的可能性。因為嚮上含混性，是無解的。
評分##還在理解中
評分##翻譯得很差，像機翻，嚴重影響理解。
評分##感覺有點理論化
評分##唯一提供對需求實現內部度量的書籍
相關圖書
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.teaonline.club All Rights Reserved. 圖書大百科 版權所有