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