當用戶有一個問題能夠用計算機系統來解決，而開發者開始幫助用戶解決問題，溝通就開始了。
需求獲取可能是軟件開發中最困難、最關鍵、最易出錯及最須要溝通交流的活動。對需求的獲取往往有錯誤的認識：用戶知道需求是什么，我們所要做的就是和他們交談從他們那里得到需求。僅僅要問用戶系統的目標特征，什么是要完畢的，什么樣的系統能適合商業須要就能夠了，可是實際上需求獲取並非想象的這樣簡單。這條溝通之路布滿了荊棘。首先需求獲取要定義問題范圍，系統的邊界往往是非常難明白的，用戶不了解技術實現的細節，這樣造成了系統目標的混淆。
其次是對問題的理解，用戶對計算機系統的能力和限制缺乏了解。不論什么一個系統都會有非常多的用戶或者不同類型的用戶。每一個用戶僅僅知道自己須要的系統。而不知道系統的總體情況，他們不知道系統作為一個總體怎么樣工作效率更好。也不太清楚那些工作能夠交給軟件完畢，他們不清楚需求是什么。或者說怎樣以一種精確的方式來描寫敘述需求。他們須要開發者的協助和指導，可是用戶與開發者之間的交流非常easy出現障礙，忽略了那些被覺得是"非常明顯"的信息。最后是需求的確認，由於需求的不穩定性往往隨着時間的推移產生變動，使之難以確認。
為了克服以上的問題，必須有組織的運行需求的獲取活動。
需求獲取活動建議要完畢的11個任務或者說步驟各自是確定需求過程、編寫項目視圖和范圍文檔、用戶群分類、選擇用戶代表、選擇用戶代表、建立核心隊伍、確定使用實例、召開聯合會議、分析用戶工作流程、確定質量屬性、檢查問題報告和需求重用。
當然應該依據組織和項目的具體情況進行適當的裁減。比方依據項目和用戶情況把需求獲取會議改成問卷調查或者座談等等。
1、編寫項目視圖和范圍文檔
系統的需求包含四個不同的層次：業務需求、用戶需求和功能需求、非功能性需求。
業務需求說明了提供給用戶新系統的最初利益,反映了組織機構或用戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。用戶需求文檔描寫敘述了用戶使用產品必須要完畢的任務。這在使用實例文檔或方案腳本說明中予以說明。功能需求定義了開發者必須實現的軟件功能，使得用戶能完畢他們的任務，從而滿足了業務需求。
非功能性需求是用戶對系統良好運作提出的期望。包含了易用性、反應速度、容錯性、健壯性等等質量屬性。需求獲取就是依據系統業務需求去獲得系統用戶需求，然后通過需求分析得到系統的功能需求和非功能需求。項目視圖和范圍文檔就是從高層次上描寫敘述系統的業務需求，應該包含高層的產品業務目標。評估問題解決方式的商業和技術可行性,全部的使用實例和功能需求都必須遵從的標准。
而范圍文檔定義了項目產品所包含的全部工作及產生產品所用的過程。
項目相關人員對項目的目標和范圍能達成共識,整個項目組都應該把注意力集中在項目目標和范圍上。
2、用戶群分類
系統用戶在非常多方面存在着差異。比如：使用系統的頻度和程度、應用領域和計算機系統知識、所使用的系統特性、所進行的業務過程、訪問權限、地理上的布局以及個人的素養和喜好等等。依據這些差異，你能夠把這些不同的用戶分成不同的用戶類。與UML中Usecase的Actor概念一樣，用戶類不一定都指人，也能夠包含其它應用系統、接口或者硬件，這樣做使得與系統邊界外的接口也成為系統需求。將用戶群分類並歸納各自特點。並具體描寫敘述出它們的個性特點及任務狀況，將有助於需求的獲取和系統設計。
3、選擇用戶代表
不可能對全部的用戶都進行需求獲取。這樣做時間不同意效果也不一定好，所以要識別出能夠確定需求和了解業務流程的用戶作為每類用戶的代表。每類用戶至少選擇一位能真正代表他們需求的人作為代表而且能夠作出決策，用戶代表往往是本類用戶中三類人：對項目有決定權的領導、熟悉業務流程的專家、系統終於用戶。
每一個用戶代表者代表了一個特定的用戶類。並在那個用戶類和開發者之間充當基本的接口，用戶代表從他們所代表的用戶類中收集需求信息。同一時候每一個用戶代表又負責協調他們所代表的用戶在需求表達上的不一致性和不兼容性。
4、建立核心隊伍
通經常使用戶和開發者不自覺的都有一種"我們和他們"的想法，產生一種對立關系。把彼此放在對立面，每一方都定義自己的"邊界"。僅僅想自己的利益而忽略對方的想法。他們通過文檔、記錄和對話來溝通，而不是作為一個合作的總體去識別和確定需求完畢任務。實踐證明這個方案是不對的，不會給兩方帶來一點益處,良好的溝通關系沒有建立導致了誤解和忽略重要的信息。僅僅有當兩方參與者都明白要成功自己須要什么，同一時候也知道要成功對方須要什么時。才干建立起一種合作關系。
為了建立合作關系通常採取一種組隊的方式來獲取需求，建立一個由用戶代表和開發者組成的聯合小組作為需求獲取的核心隊伍。聯合小組將負責識別需求、分析解決方式和協商分歧，小組成員能夠採用會議、電子郵件、綜合辦公系統等方式進行交流，但交流時應注意下面原則：小組會議應該由中立方來組織和主持。用戶和開發者都要參加；交流預先要確定准備和參與的規則。議題要明白並覆蓋全部關鍵點，但信息來源應該自由；交流目標要明白。並告知全部的成員。
5、確定使用實例
從用戶代表處收集他們將使用系統完畢所需任務的描寫敘述。討論用戶與系統間的交互方式和對話要求，這就是使用實例。一個單一的使用實例可能包含完畢某項任務的很多邏輯相關任務和交互順序。
使用實例方法給需求獲取帶來的優點來自於該方法是用以任務為中心和以用戶為中心的觀點，比起使用以功能為中心和以開發者為中心的方法，使用實例方法能夠使用戶更清楚地理解和認識到新系統同意他們做什么和怎么做。描寫使用實例的時候要注意使用簡潔直白的表述，盡量使用主動語態，用"系統"或者"用戶"作為主語，比方"用戶提交用戶password，系統驗證用戶password是否正確"，另一點在描寫敘述中不要設計界面細節，比方"用戶從下拉框中選擇產品類型"。
使用實例為以后寫用例場景描寫敘述中的基本路徑和擴展路徑提供了素材。
6、召開聯合會議
最常見的需求獲取方法是召開會議或者面談。聯合會議是范圍廣的、簡便的討論會，也是核心隊伍成員之間一種非常好的溝通方法。該會議通過緊密而集中的討論得以將用戶代表與開發者間的合作伙伴關系付諸於實踐並能由此擬出需求文檔的底稿。
聯合會議的第一個議題就是系統的必要性和合理性。必須全部成員都同意系統是必要的而且合理的。
接下來就能夠討論使用實例清單，清單能夠打印成大紙掛在牆上、寫在黑板上或做成演示材料。
對每一個清單合並去掉反復項，加上補充內容就能夠得到一份總的清單，注意避免採用負面的"太差""不可行"去否定用戶的想法，這些想法都應該保留下來作為被評議的清單項，這樣保護了小組成員開放的思維。最后對清單進行討論，會議成員必須檢查每一個使用實例，在把它們納入需求之前決定其是否在項目所定義的范圍內。形成終於的需求報告。
在進行討論時，也應該避免受不成熟的細節的影響。在對系統需求取得共識之前，用戶能非常easy地在一個報表或對話框中列出某些精確設計，假設這些細節都作為需求記錄下來，他們會給隨后的設計過程帶來不必要的限制，應確保用戶參與者將注意力集中在與所討論的話題適合的抽象層上，重點就是討論做什么而不是怎么做。這里有一點非常重要就是要讓用戶理解對於某些功能的討論並不意味着即將在系統中實現它，更不要做暗示或者承諾什么時候完畢需求。
在討論之后，記下所討論的條目，並請參與討論的用戶評論並更正，由於僅僅有提供需求的人才干確定是否真正獲取需求。當最后拿到了一份具體准確的需求報告書的時候。會議就算成功完畢了。可是要清楚需求過程本身就是一個迭代的過程。在以后的過程活動中不可避免的將要改動和完好這份報告。
7、分析用戶工作流程
分析用戶工作流程觀察用戶運行業務任務的過程，通過分析使用實例得到系統的用例圖。
編制用例圖文檔將有助於明白系統的使用實例和功能需求，統一建模語言的使用有助於與用戶進一步交流。每一個用例的描寫敘述應包含：編號,為每一個用例分配一個唯一的編號，為需求的追溯提供了方便；參與者，與這個用例交互的actor；前置條件。開始用例前所必須具備的系統狀態；后置條件，用例完畢后系統達到的狀態。基本路徑，用例完畢的關鍵路徑，也是用戶期望的路徑；擴展點，基本路徑的分枝，表示意外情況；字段說明。路徑中名稱的進一步分講解明。對以后類屬性的定義和數據庫字段設計起作用。設計約束，實現用例的非功能約束。寫基本路徑時應該使用主動語句；句子以actor或者系統作為主語；一句表示一個actor動作，一句表示系統動作。交叉表現交互；不要涉及界面細節，比方"用戶在文本框輸入名稱，下拉框選擇類型"。
| 用例：用戶注冊。用戶注冊成為系統會員 | |
| 編號 | UC1 |
| 參與者 | 用戶 |
| 前置條件 | 用戶訪問系統。系統運行正常 |
| 后置條件 | 系統記錄用戶注冊信息 |
| 基本路徑 | 1. 用戶請求注冊。
|
| 擴展點 | 4a. 用戶提供的信息不對： 4a1. 系統提示輸入正確信息 4a2. 返回3 |
| 補充說明 | 注冊信息包含＝用戶實名＋電話＋傳真＋Email＋聯系地址聯系地址＝省份＋城市＋街道＋郵編 |
| 設計約束 | 注冊反應時間不能超過3秒 |
8、確定質量屬性
在功能需求之外再考慮一下非功能的質量特點，以及確定由於特殊的商業應用環境對系統提出的功能或性能上的約束，這會使你的產品達到並超過客戶的期望。對系統怎樣能非常好地運行某些行為或讓用戶採取某一措施的陳述就是質量屬性，這是一種非功能需求。
聽取那些描寫敘述合理特性的意見：快捷、簡易、直覺性、用戶友好、健壯性、可靠性、安全性和高效性。
你將要和用戶一起商討精確定義他們模糊的和主觀言辭的真正含義，而且要將質量屬性分配到每一個用例的設計約束中去。
9、檢查問題報告
通過檢查當前已經運行系統的問題報告來進一步完好需求客戶的問題報告及補充需求為新系統或新版本號提供了大量豐富的改進及添加特性的想法，負責提供用戶支持及幫助的人能為收集需求過程提供極有價值的信息。
10、需求重用
假設客戶要求的功能與已有的系統非常類似。則可查看需求是否有足夠的靈活性以同意重用一些已有的軟件組件。業務建模和領域建模式需求重用的最好方法。像分析模式和設計模式一樣。需求也有自己的模式。