1、定義產品願景和項目範圍
願景和範圍文檔包含產品的業務需求。願景描述可以是所有干係人對產品的產出有一致的理解。範圍界定了發佈或者迭代中哪些功能應該或不應該出現。願景與範圍提供了一種參考，方便對大家所提議的需求進行評估。願景在整個項目過程中時相對穩定的，每個計劃的發佈或迭代都有自己的範圍。
2、識別用戶類型及其特徵
爲了避免遺漏任何用戶團體的需求，我們要爲產品識別出不同的用戶組。在使用頻率、所用特性、權限級別以及經驗方面，這些組別可能不同。記下他們的工作任務、態度、位置或個性，這些都可能影響產品設計。建立用戶角色---也就是一種虛擬人物---來代表特定用戶類型。
3、爲每類用戶選出用戶代表
爲每類用戶找出一個能精確傳達用戶心聲的個人---產品用戶代表。他提出用戶組的需求，並代表用戶組做決策。在內部信息系統的開發中，這是最容易做到的，因爲你的用戶就是你的同事。對於商業產品的開發，則要按照你與大客戶的現有關係或是beta測試網站來鎖定合適的產品用戶代表。
4、安排由典型用戶組成的焦點小組
將以前產品或類似產品的用戶代表組成小組。收集他們期望有的產品功能及質量。焦點小組對商業產品尤其重要，因爲你可能要面對數量巨大切形形色色的客戶。與產品用戶代表不同，焦點小組通常沒有決策權。
5、與用戶代表協同發現用戶需求
要與用戶代表共同探討他們需要軟件完成什麼任務以及他們希望獲得哪些價值。用戶需求的表達方式包括用例、用戶故事或場景。討論內容還包括用戶與能使其完成各項任務的系統之間的互動關係。
6、識別系統事件和反應
列出系統可能經歷的外部事件及其對每個事件可能做出的反應。外部事件可以分爲三類。信號事件是指控制信號或從外部硬件接收到的數據。時間或時間相關事件會觸發一個響應，例如系統每天晚上導出外部數據。業務事件在業務應用中觸發用例。
7、舉辦獲取訪談
訪談可以是一對一的，也可以是和一個小組干係人。這是一個獲取需求 的高效方式，可以避免佔用干係人過多時間。因爲你只跟每個人討論對他們很重要的需求。面談十分有用，它可以分別啓發出每個人的需求並且爲討論會做準備。在討論會上大家聚在一起解決衝突。
8、舉辦並引導需求獲取討論會
通過需求獲取討論會，分析師和客戶能夠精誠合作，高效的探索用戶需求和起草需求文檔。這樣的討論會有時稱作“聯合應用設計”會議。
9、觀察用戶如何工作
觀察用戶如何完成其任務目標，能夠了解到一個新應用在這些用戶中的潛在用途。簡易的流程圖可以描述出每個步驟以及所涉及的決策，並且展示不同用戶組如何交互的。如果能將業務流程圖記錄成文檔，你就能識別出解決方案是否能夠支持此流程的需求。
10、分發調查問卷
調查問卷這種方式就是調查大量用戶羣並判斷他們有哪些需要。如果用戶羣體比較大，就適合使用調查問卷，特別是用戶羣比較分散是，效果更好。如果問題設計得好，調查問卷可以幫助你快速獲得關於需求的分析結果。這樣一來，獲取需求的其他工作量就可以按照調查問卷結果來確定。
11、分析文檔
現有的文檔可以解釋系統目前如何運行或人們期望它如何運行。文檔中的書面信息涉及現有系統、業務流程、需求規範說明、對競爭對手的研究以及產品上架發行時的用戶手冊。檢查並分析這些文檔可以幫助你發現什麼樣的功能需要保留，什麼功能是沒有被用到，人們現在如何完成他們的工作，競爭對手提供什麼功能，軟件供應商如何描述產品功能。
12、檢查現有系統在需求方面的問題報告
從用戶那裏獲取問題報告和改進請求爲我們提供了豐富的候選項，我們可以將這些新增需求或改進建議納入到下一個發佈或新產品中。客戶支持或售後服務可以爲未來開發工作挺很多有價值的需求。
13、重用現有需求
如果客戶所要的功能跟現有系統已經提供的功能類似，就要看需求及客戶是否能夠通過變通，允許重用或者改寫已有組件。例如符合組織業務規則的安全需求或者符合政府法規的可訪問性需求，就經常可以重用。另一些可以重用的東西包括詞彙表、數據模型、定義、干係人信息、用戶類型描述以及用戶角色等。