（1）在探索需求過程中，任何對於想法的評價不管是積極的還是消極的，都應該放到以後進行。當想法產生時，記錄者應僅僅記錄下每乙個想法，就像一台自動機器一樣。因為這樣可以保證不丟失想法，人們不會自我檢查是否合適，也不會使會議突然跑題，變成參與者討論乙個想法究竟是好還是壞。世界上大多數偉大的想法在剛剛被提出來時看起來都是「愚蠢」的。當然，大多數聽起來愚蠢的想法確實會被證實是愚蠢的，而且一些人會因為他們的」愚蠢「被記錄下來而感到不安。由於這個原因，沒有經過編輯整理的想法的列表是絕不應當在會議之外被人看見的。會議議程的安排中必須包含當頭腦風暴結束時用於編輯整理想法的時間。如果參加者理解了並且相信這樣的承諾，他們就會放鬆下來而且產生許多「愚蠢」的想法，這也就起到了會議所應有的作用。
（2）「不要浪費時間」是一種心理壓力的潛在形式。如果浪費時間的確是需要關心的問題，那麼可以設定乙個時間限制，並且刺激參與者在那個時間規定裡提出數量大得驚人的想法。即使事情陷入困境，也要利用好所有可用的時間。推動者可能想要得到更多的想法，但是，他們應該有足夠的保持沉默的耐心。通常來說長時間的沉默過後就會有突破性的想法產生。
（3）在正確的頭腦風暴的設計中，應當鼓勵參與者對已經列出來的想法進行變化，或者合成一些想法以創造出更多的想法。這些「改進」並不會被認為是對原始想法的批評，而僅僅是一種變化。因為所有變更過的想法都是新的想法，因此他們都應該被記錄下來。
（4）頭腦風暴的第一部分設計成增加想法的數量，而第二部分則將想法列表中的想法數量減少到乙個可操作的規模。有許多可能減少想法的方法，可以根據需要單獨或結合使用。有如下方法：門限投票法、競選演講投票法等等。平時我們在學習生活中也會用到所謂的頭腦風暴，但相比之下很不規範，所以日後的頭腦風暴可以選擇按照書上的方式進行，想必這樣會高效一些。
《探索需求 設計前的質量》閱讀筆記三
獲取資訊的第一步就是定義功能，在這個階段描述產品是為了做什麼的動作。假設是決策樹的根源，那麼客戶說想要什麼東西存在就是問題宣告的提出。而客戶說產品能夠實現什麼功能就是指他的測試功能。在描述功能方面，需要記錄所有使用者想要的功能，然後進行理解，不能記錄記錄使用者不想要的功能。做到這些也需要一些技巧，首...
《探索需求 設計前的質量》閱讀筆記三
第五篇 極大提高成功的可能性 19含混性度量 被通知投票人的最大到最小估計值的比率就可以用作含混性度量，乙個我們可以過得精確值的可度量實體。度量三類含混性是指問題描述含混性，設計過程含混性，最終產品的含混性。一些估計值的變化就可能簡單地來自於估計中發生了錯誤，所以一定要對最大和最小的估計值追根溯源。...
《探索需求 設計前的質量》閱讀筆記一
需求，是人們的期望 探索需求是尋找人們的期望的過程。而我們所做出來的軟體產品就是試圖滿足復合的一系列期望。發現什麼都不是，而發現過程即探索過程就是一切 只有當自己知道需要時，才有可能會獲得它，這也是需求分析的必要性。經過前輩們無數次的實踐 分析總結出很多很多經驗，可以說已經形成一套有效的軟體開發方法...