3、建立核心隊
通常用戶和開發人員不自覺的都有一種"我們和他們"的想法，產生一種對立關係，把彼此放在對立面，每一方都定義自己的"邊界"，只想自己的利益而忽略對方的想法。他們通過文檔、記錄和對話來溝通，而不是作為一個合作的整體去識別和確定需求完成任務。實踐證明這樣的方法是不正確的，不會給雙方帶來一點益處,良好的溝通關係沒有建立導致了誤解和忽略重要的信息。只有當雙方參與者都明白要成功自己需要什麼，同時也知道要成功對方需要什麼時，才能建立起一種合作關係。
為了建立合作關係通常採取一種組隊的方式來獲取需求，建立一個由用戶代表和開發人員組成的聯合小組作為需求獲取的核心隊伍。聯合小組將負責識別需求、分析解決方案和協商分歧，小組成員可以採用會議、電子郵件、綜合辦公系統等方式進行交流，但交流時應注意以下原則：小組會議應該由中立方來組織和主持，用戶和開發人員都要參加;交流預先要確定準備和參與的規則;議題要明確並覆蓋所有關鍵點，但信息來源應該自由;交流目標要明確，並告知所有的成員。
4、確定使用實例
從用戶代表處收集他們將使用系統完成所需任務的描述，討論用戶與系統間的互動方式和對話要求，這就是使用實例，一個單一的使用實例可能包括完成某項任務的許多邏輯相關任務和互動順序。使用實例方法給需求獲取帶來的好處來自於該方法是用以任務為中心和以用戶為中心的觀點，比起使用以功能為中心和以開發者為中心的方法，使用實例方法可以使用戶更清楚地理解和認識到新系統允許他們做什麼和怎么做。描寫使用實例的時候要注意使用簡潔直白的表述，儘量使用主動語態，用"系統"或者"用戶"作為主語，比如"用戶提交用戶密碼，系統驗證用戶密碼是否正確"，還有一點在描述中不要設計界面細節，比如"用戶從下拉框中選擇產品類型"。使用實例為以後寫用例場景描述中的基本路徑和擴展路徑提供了素材。
5、分析用戶工作流程
分析用戶工作流程觀察用戶執行業務任務的過程，通過分析使用實例得到系統的用例圖。編制用例圖文檔將有助於明確係統的使用實例和功能需求，統一建模語言的使用有助於與用戶進一步交流。每個用例的描述應包括：編號,為每個用例分配一個唯一的編號，為需求的追溯提供了方便;參與者，與這個用例互動的 actor;前置條件，開始用例前所必須具備的系統狀態;後置條件，用例完成後系統達到的狀態;基本路徑，用例完成的關鍵路徑，也是用戶期望的路徑;擴展點，基本路徑的分枝，表示意外情況;欄位說明，路徑中名稱的進一步分解說明，對以後類屬性的定義和資料庫欄位設計起作用;設計約束，實現用例的非功能約束。
6、檢查問題報告
通過檢查當前已經運行系統的問題報告來進一步完善需求客戶的問題報告及補充需求為新系統或新版本提供了大量豐富的改進及增加特性的想法，負責提供用戶支持及幫助的人能為收集需求過程提供極有價值的信息。
7、需求重用
如果客戶要求的功能與已有的系統很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟體組件。業務建模和領域建模式需求重用的最好方法，像分析模式和設計模式一樣，需求也有自己的模式。
總結 ：經過一學期的軟工實驗，深刻感到其重要性的同時也學到了不少的東西 ，將對我在今後的軟體開發過程中起極大的作用。