盡量理解用戶用于表述他們需求的思維過程。充分研究用戶執行任務時作出決策的過程，并提取出潛在的邏輯關系。流程圖和決策樹是描述這些邏輯決策途徑的好方法。
在需求獲取的過程中，你可能會發現對項目范圍的定義存在誤差，不是太大就是太小。如果范圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業務和客戶的值，此時獲取過程將會拖延。如果項目范圍太小，那么客戶將會提出很重要的但又在當前產品范圍之外的需求。當前的范圍太小，以致不能提供一個令人滿意的產品。需求的獲取將導致修改項目的范圍和任務，但作出這樣具有深遠影響的改變，一定要小心謹慎。 正如經常所說的，需求主要是關于系統做什么，而解決方案如何實現是屬于設計的范圍。這樣說雖然很簡潔，但似乎過于簡單化。需求的獲取應該把重點放在“做什么”上，但在分析和設計之間還是存在一定的距離。你可以使用假設“怎么做”來分類并改善你對用戶需求的理解。在需求的獲取過程中，分析模型、屏幕圖形和原型可以使概念表達得更加清楚，然后提供一個尋找錯誤和遺漏的辦法。把你在需求開發階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議，而不應該看成是對設計者選擇的一種限制。 需求獲取討論會中如果參與者過多，就會減慢進度。人數大致控制在5到7人是最好的。這些人包括客戶、系統設計者、開發者和可視化設計者等主要工程角色。相反地，從極少的代表那里收集信息或者只聽到呼聲最高、最有輿論影響的用戶的聲音，也會造成問題。這將導致忽視特定用戶類的重要的需求，或者其需求不能代表絕大多數用戶的需要。最?好的權衡在于選擇一些授權為他們的用戶類發言的產品代表者，他們也被同組用戶類的其它代表所支持。 沒有一個簡單、清楚的信號暗示你什么時候已完成需求獲取。當客戶和開發者與他們的同事聊天、閱讀工業和商業上的文獻及在早上沐浴時思考時，他們都將對潛在產品產生新的構思。你不可能全面收集需求，但是下列的提示將會暗示你在需求獲取的過程中的返回點。
1. 如果用戶不能想出更多的使用實例，也許你就完成了收集需求的工作。用戶總是按其重要性的順序來確定使用實例的。
2. 如果用戶提出新的使用實例，但你可以從其它使用實例的相關功能需求中獲得這些新的使用實例，這時也許你就完成了收集需求的工作。這些新的使用實例可能是你已獲取的其它使用實例的可選過程。 3. 如果用戶開始重復原先討論過的問題，此時，也許你就完成了收集需求的工作。
4. 如果所提出的新需求比你已確定的需求的優先級都低時，也許你就完成了收集需求的工作。
5. 如果用戶提出對將來產品的要求，而不是現在我們討論的特定產品，也許你就完成了收集需求的工作。
以上知識大致上討論需求分析應該如何做，實際上對于需求分析的方法有很多很多，已經形成了一定的理論，當然這種理論比較偏向與方法學，而方法學的應用主要還是要靠個人。所以，大家在實際應用的時候，不妨結合自己的實際，有選擇性的采用一些方法，那你就是成功的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
