獲取資訊的第一步就是定義功能，在這個階段描述產品是為了做什麼的動作。假設是決策樹的根源，那麼客戶說想要什麼東西存在就是問題宣告的提出。而客戶說產品能夠實現什麼功能就是指他的測試功能。在描述功能方面，需要記錄所有使用者想要的功能，然後進行理解，不能記錄記錄使用者不想要的功能。做到這些也需要一些技巧，首先要記錄所有潛在功能，；理解明顯的隱藏的以及裝飾性的功能，識別未注意到的功能。實用功能啟發的方式來進行識別功能，創造歸功能的一直處理方法。
屬性是客戶希望的特徵，要將屬性和功能加以區分，屬性不同的產品有可能功能會十分相似或相同。同乙個屬性可能會限定不止一種屬性，此外在分析的時候將屬性分類為必須、需要和忽略，這樣可以有效地判斷使用者的期望。乙個約束就是置於乙個m型別屬性之上的強制性條件，為了讓最終的設計方案能夠被別人接受必須滿足每乙個約束條件。每乙個系統會存在他的邊界，而我們在考慮約束條件時也要把它考慮在內。
偏好是附加在屬性上的一種願望，但卻是可選擇的條件。在需求中，偏好這個因素就會讓開發者從備選方案中選出最好的最符合條件的方案，是我們的方案更好。往往在設計者把產品交付給使用者的時候，使用者才會發現自己的偏好的存在。但是偏好不應該被過度使用。在確定這個因素的時候要清楚地將每個偏好區分開來，否則就會將兩個或者多偏好混在一起，難以分辨。為了使編號變得可量化，可以採用多感官的資訊展示，將能夠收到所有資訊的人的比例作為量化標準。有約束的偏好往往會變成價值，價值圖可以幫助設計者分析每一種偏好的作用力來使自己的工作變得更有方向性。
失望和滿意的差別不在於交電費的成果，而在於交付的成果與期望的匹配程度有多大。由於人不是完美的，人並不都是有邏輯的，人們對事物的理解程度不同等一系列因素，需要額外的一步來限制期望。為了計算認為因素的影響，可以使用希望限制的方法：產生專門的期望列表、產生期望列表、限制期望、讓可能性保持公開。
然後專案需求階段就進入了尾聲，經過將含混性進行度量、進行技術複審、衡量滿意度、測試用例、學習已存在的產品、達成協議幾個階段之後就可以結束了。首先，可以使用投票的方法進行含混性的測量，可以針對不同的問題對參與者進行調查，將三種含混性問題描述含混性、設計過程含混性和最終產品含混性加以明確並進行處理。複審階段，技術附身為專案複審提供資訊，專案複審還要考慮非技術主題的資訊；附身的結果可以對需求調整以匹配資源，或是對資源調整以匹配需求。複查報告也要寫的完整準確、為相關工作作為可靠的基礎，為跟蹤程序的目的而可度量，因為有了複審才能對於工作進度有乙個可靠的衡量方法。
接下來可以進行使用者滿意度測試，為了避免使用者不滿意，需要從設計開始就一直測量使用者滿意度。另外，測試本身也可以作為我們尋找屬性的工具，和設計者與使用者交流的工具，它可以作為乙個貫穿始終的內容來幫助設計者開展工作。接下來可以進行黑箱測試，用來獲取專案可以做到的、實現的有哪些，黑箱測試的結果能夠作為隨後系統和產品測試的基礎，所以這一步工作是必須的，為了測試開發到現在的任何需求的完備性、準確性、以及簡明性也需要進行黑箱測試。
幾乎沒有「新」的產品完全都是新的，因為設計的所有產品幾乎都會被拿來與已經有的東西作比較。要將自己的產品與現存產品做比較，看在產品中缺少了哪些功能，在自己的產品中是否有相應部分的實現。比較產品提出乙份在新需求中可能遺漏的功能列表；然後訪談一些舊產品的使用者，提出乙份當前系統中不見了的功能，再對自己的產品需求進行更正。在決策的時候，需要進行選擇，假設和強迫接受，在避免錯誤假設的前提下將決策轉化為協議。需求過程開始於含混行，最終卻一定要結束於協議。
《探索需求 設計前的質量》閱讀筆記三
1 在探索需求過程中，任何對於想法的評價不管是積極的還是消極的，都應該放到以後進行。當想法產生時，記錄者應僅僅記錄下每乙個想法，就像一台自動機器一樣。因為這樣可以保證不丟失想法，人們不會自我檢查是否合適，也不會使會議突然跑題，變成參與者討論乙個想法究竟是好還是壞。世界上大多數偉大的想法在剛剛被提出來...
《探索需求 設計前的質量》閱讀筆記三
第五篇 極大提高成功的可能性 19含混性度量 被通知投票人的最大到最小估計值的比率就可以用作含混性度量，乙個我們可以過得精確值的可度量實體。度量三類含混性是指問題描述含混性，設計過程含混性，最終產品的含混性。一些估計值的變化就可能簡單地來自於估計中發生了錯誤，所以一定要對最大和最小的估計值追根溯源。...
《探索需求 設計前的質量》閱讀筆記一
需求，是人們的期望 探索需求是尋找人們的期望的過程。而我們所做出來的軟體產品就是試圖滿足復合的一系列期望。發現什麼都不是，而發現過程即探索過程就是一切 只有當自己知道需要時，才有可能會獲得它，這也是需求分析的必要性。經過前輩們無數次的實踐 分析總結出很多很多經驗，可以說已經形成一套有效的軟體開發方法...