《探索需求》——閱讀筆記三

屬性

按照下列步驟細化屬性集合：

經過頭腦風暴獲得可能的屬性列表。

從屬性細節中分類挑選屬性。將全部的細節填到屬性列表中，以及由全部的屬性按時的其餘細節也填到列表中。

將每一個屬性分配到適合的功能或功能組。

將全部的屬性分類到必須（M），須要（W）和忽略（I）。

爲下一步處理證實M和W屬性。

約束條件

在制定約束列表的時候，遵守下列過程：

1.生成基於M類型屬性的約束列表。

2.檢測約束的正確性和完備性。

3.尋找可能會生成更小或更大的潛在解決方案控件的相互關聯的約束。

4.在約束邊界的內部和外部邊緣的地方仔細地檢測過緊約束。

5.儘量地爲了獲得較大的解決方案控件而進行協調工做，單是不要試圖讓它過度大。

偏好

按照下述週期性步驟進行：

1.制定一個偏好的範圍很廣的列表。

2.女裏將每條偏好都轉變爲可量化的偏好，一遍設計者確切地知道如何衡量如何他們作得更好，和時作得更差。然而，要小心，不要在度量的問題上陷入困境。

3.從新考慮你的約束列表，看看他們是不是真的偏好。只要可能的話，都試圖將約束縮減爲偏好，多是受約束的偏好，以便爲設計者提供更加廣闊的解決方案控件用於搜索。

4.爲了幫助清晰地設定偏好，開發價值圖，用於幫助解決語句含混性問題，尤爲是約束和偏好之間的混淆問題。

指望

爲了提出並記錄指望和限制，遵循下列循環步驟：

1.從有表明性的用戶處得到專門的指望列表。

2.處理該列表，理解併產生每條指望，

3.經過協商將指望限制到一個合理的水平，微系統未來的修改留下公開的機會，可是堅定地去掉任何不能合理地指望獲得的東西。

4.設置一條設置時，確信幾下限制的來源，由於今天的權限就多是明天的機會。

第五篇——極大提升成功的可能

含混性度量

按照下述步驟進行投票：

1.召集一組人，讓其回到關於要測量含混性的文檔的問題。

2.卻行不存在壓力要求答案一致，或者不存在一個或其餘參與者的任何類型的影響。

3.提出一組問題，每個問題都鞥夠用數字進行回答。

4.經過比較熟知最高和最低的答案估計含混性。

5.訪問給出最高和最低值的估計者，幫助肯定含混性的來源。

技術複審

1.有不少能夠挑選的複審規則。都試一下，而後讓他們知足你特別的需求。

2.容許學習的時間，對你本身的笨拙要有耐心。

3.開發反饋系統，以便於你在早期複審中學到的東西可以用於改進未來的複審。這樣作得最簡單的方法就是發展一個通過培訓的複審領導團隊。

衡量滿意度

1.位你本身的項目監理一個用戶滿意度測試。使用咱們的表格或者他們合適你的組織機構文化的形式。在此基礎上，必定要讓用戶包含在此過程當中。

2.如允諾的那樣，週期性地管理測試。

3.吧每類或整體的滿意度評價製成表格，而後看看變化。追蹤這些變化，找出他們後面隱藏的東西。

4.對任何評論都要基於特別的表格，尤爲當它們表達了強烈的願望時。毫不要忘記感受就是事實，是關於你首先建立系統的對象的重要的事實。

5.不管你是否使用用戶滿意度測試，不要忘記使用全部來自其餘來源的全部用戶滿意度的信息。

測試用例

需求的黑箱測試過程遵循下述循環步驟：

1.經過想象產品已經制造出來，構造一系列的測試用例，而且爲「假設」問題。

2.回答這些測試用例，而且與全部感興趣的團體討論這些答案，爭取取得一致意見。

3.試圖獲得對答案的認同一般會致使其餘「假設」問題。將它們加入到列表中而且回答，重複這個過程知道列表穩定下來。

4.一旦列表或多或少穩定下來，一一個包括設計者和專業記錄員的小組仔細檢查它。這個小組專門蒐集過度約束的答覆，而後修改它們以給出最大可能的設計——可是不要再添加問題。

5.當完成了修改，將用例記錄下來，做爲開始構建系統和接受測試的其實的基礎。

學習已存在的產品

1.比較產品，提出一份在新需求中可能遺漏的功能列表。

2.訪談一些舊產品的使用者，提出一份當前系統中不見了的功能列表。

3.比較舊產品和其原始的需求，準備一份新產品開發中的潛在問題的列表。尤爲要注意那些沒有別實現的或是實現了以後又被丟棄的需求。

4.避免由於每一箇舊產品而把產品作成一把瑞士軍刀的誘惑。不要讓那些不隸屬這個需求系統的特徵悄悄混進來。

達成協議

1.記錄下每一個假設；

2.跟蹤每一個假設的源頭：是選擇、強迫接受仍是協議。

3.是假設加上其來源信息。

4.請參與者在每一個書面文檔上簽名。

5.尋找能夠下降由假設所帶來風險的行爲的時機。