經過這學期軟體工程實驗的學習，深深感到用戶需求對軟體的重要性。成功的軟體產品是建立在成功的需求基礎之上的，而高質量的需求來源於用戶與開發人員之間有效的溝通與合作。當用戶有一個問題可以用計算機系統來解決，而開發人員開始幫助用戶解決這個問題，溝通就開始了。
需求獲取可能是最困難、最關鍵、最易出錯及最需要溝通交流的活動。對需求的獲取往往有錯誤的認識：用戶知道需求是什麼，我們所要做的就是和他們交談從他們那裡得到需求，只要問用戶系統的目標特徵，什麼是要完成的，什麼樣的系統能適合商業需要就可以了，但是實際上需求獲取並不是想像的這樣簡單，這條溝通之路布滿了荊棘。首先需求獲取要定義問題範圍，系統的邊界往往是很難明確的，用戶不了解技術實現的細節，這樣造成了系統目標的混淆。
其次是對問題的理解，用戶對計算機系統的能力和限制缺乏了解，任何一個系統都會有很多的用戶或者不同類型的用戶，每個用戶只知道自己需要的系統，而不知道系統的整體情況，他們不知道系統作為一個整體怎么樣工作效率更好，也不太清楚那些工作可以交給軟體完成，他們不清楚需求是什麼，或者說如何以一種精確的方式來描述需求，他們需要開發人員的協助和指導，但是用戶與開發人員之間的交流很容易出現障礙，忽略了那些被認為是"很明顯"的信息。最後是需求的確認，因為需求的不穩定性往往隨著時間的推移產生變動，使之難以確認。為了克服以上的問題，必須有組織的執行需求的獲取活動。
需求獲取活動要完成的任務或者步驟的過程如下：
1、編寫項目視圖和範圍文檔
系統的需求包括四個不同的層次：業務需求、用戶需求和功能需求、非功能性需求。業務需求說明了提供給用戶新系統的最初利益,反映了組織機構或用戶對系統、產品高層次的目標要求，它們在項目視圖與範圍文檔中予以說明。用戶需求文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明。功能需求定義了開發人員必須實現的軟體功能，使得用戶能完成他們的任務，從而滿足了業務需求。
非功能性需求是用戶對系統良好運作提出的期望，包括了易用性、反應速度、容錯性、健壯性等等質量屬性。需求獲取就是根據系統業務需求去獲得系統用戶需求，然後通過需求分析得到系統的功能需求和非功能需求。項目視圖和範圍文檔就是從高層次上描述系統的業務需求，應該包括高層的產品業務目標，評估問題解決方案的商業和技術可行性,所有的使用實例和功能需求都必須遵從的標準。而範圍文檔定義了項目產品所包括的所有工作及產生產品所用的過程。項目相關人員對項目的目標和範圍能達成共識,整個項目組都應該把注意力集中在項目目標和範圍上。
2、用戶群分類
系統用戶在很多方面存在著差異，例如：使用系統的頻度和程度、套用領域和計算機系統知識、所使用的系統特性、所進行的業務過程、訪問許可權、地理上的布局以及個人的素質和喜好等等。根據這些差異，你可以把這些不同的用戶分成不同的用戶類。與ulm中usecase的actor概念一樣，用戶類不一定都指人，也可以包括其他套用系統、接口或者硬體，這樣做使得與系統邊界外的接口也成為系統需求。將用戶群分類並歸納各自特點，並詳細描述出它們的個性特點及任務狀況，將有助於需求的獲取和系統設計。