簡 介

[網盤分流]
如電驢無法下載，請大家從網盤下載後將文件移至電驢文件夾用eMule做種，讓更多人下載
網盤下載 ：
http://www.666pan.cc/file-171129.html|http://fsl.to/d0ae1p|https://lanyang.ctfile.com/fs/92356-205844713
內容簡介

本書著眼於系統設計之前的需求過程，它是整個開發過程（如何設計人們想要的產品和系統）中最有挑戰性的那部分。通過對一些需求分析中的常見誤區和問題的分析和討論，從和客戶溝通開始，深入研究一些可能的需求，澄清用戶和開發者期望值，最終給出了能夠大幅度提高項目成功幾率的一些建議方法。
　　 本書由該領域內公認的兩位作者合著，搜集了他們在大大小小的公司裡加起來超過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 CC下載站 精品源碼 | 68資源網