成功的軟體產品是建立在成功的需求基礎之上的，而高質量的需求來源於使用者與開發人員之間有效的溝通與合作。當用戶有一個問題可以用計算機系統來解決，而開發人員開始幫助使用者解決這個問題，溝通就開始了，溝通技巧就顯得尤為重要了。

　　需求獲取可能是軟體開發中最困難、最關鍵、最易出錯及最需要溝通交流的活動。對需求的獲取往往有錯誤的認識：使用者知道需求是什麼，我們所要做的就是和他們交談從他們那裡得到需求，只要問使用者系統的目標特徵，什麼是要完成的，什麼樣的系統能適合商業需要就可以了，但是實際上需求獲取並不是想象的這樣簡單，這條溝通之路佈滿了荊棘。首先需求獲取要定義問題範圍，系統的邊界往往是很難明確的，使用者不瞭解技術實現的細節，這樣造成了系統目標的混淆。

　　其次是對問題的理解，使用者對計算機系統的能力和限制缺乏瞭解，任何一個系統都會有很多的使用者或者不同型別的使用者，每個使用者只知道自己需要的系統，而不知道系統的整體情況，他們不知道系統作為一個整體怎麼樣工作效率更好，也不太清楚那些工作可以交給軟體完成，他們不清楚需求是什麼，或者說如何以一種精確的方式來描述需求，他們需要開發人員的協助和指導，但是使用者與開發人員之間的交流很容易出現障礙，忽略了那些被認為是"很明確的資訊。最後是需求的確認，因為需求的不穩定性往往隨著時間的推移產生變動，使之難以確認。為了克服以上的問題，必須有組織的執行需求的獲取活動。

　　需求獲取活動建議要完成的11個任務或者說步驟分別是確定需求過程、編寫專案檢視和範圍文件、使用者群分類、選擇使用者代表、選擇使用者代表、建立核心隊伍、確定使用例項、召開聯合會議、分析使用者工作流程、確定質量屬性、檢查問題報告和需求重用。當然應該根據組織和專案的具體情況進行適當的裁減，比如根據專案和使用者情況把需求獲取會議改成問卷調查或者座談等等。

　　1、編寫專案檢視和範圍文件

　　系統的需求包括四個不同的層次：業務需求、使用者需求和功能需求、非功能性需求。業務需求說明了提供給使用者新系統的最初利益,反映了組織機構或使用者對系統、產品高層次的目標要求，它們在專案檢視與範圍文件中予以說明。使用者需求文件描述了使用者使用產品必須要完成的任務，這在使用例項文件或方案指令碼說明中予以說明。功能需求定義了開發人員必須實現的軟體功能，使得使用者能完成他們的任務，從而滿足了業務需求。

　　非功能性需求是使用者對系統良好運作提出的期望，包括了易用性、反應速度、容錯性、健壯性等等質量屬性。需求獲取就是根據系統業務需求去獲得系統使用者需求，然後通過需求分析得到系統的功能需求和非功能需求。專案檢視和範圍文件就是從高層次上描述系統的業務需求，應該包括高層的產品業務目標，評估問題解決方案的商業和技術可行性,所有的使用例項和功能需求都必須遵從的標準。而範圍文件定義了專案產品所包括的所有工作及產生產品所用的過程。專案相關人員對專案的目標和範圍能達成共識,整個專案組都應該把注意力集中在專案目標和範圍上。

　　2、使用者群分類

　　系統使用者在很多方面存在著差異，例如：使用系統的頻度和程度、應用領域和計算機系統知識、所使用的系統特性、所進行的業務過程、訪問許可權、地理上的佈局以及個人的素質和喜好等等。根據這些差異，你可以把這些不同的使用者分成不同的使用者類。與UML中Usecase的Actor概念一樣，使用者類不一定都指人，也可以包括其他應用系統、介面或者硬體，這樣做使得與系統邊界外的介面也成為系統需求。將使用者群分類並歸納各自特點，並詳細描述出它們的個性特點及任務狀況，將有助於需求的獲取和系統設計。

　　3、選擇使用者代表

　　不可能對所有的使用者都進行需求獲取，這樣做時間不允許效果也不一定好，所以要識別出能夠確定需求和了解業務流程的使用者作為每類使用者的代表。每類使用者至少選擇一位能真正代表他們需求的人作為代表並且能夠作出決策，使用者代表往往是本類使用者中三類人：對專案有決定權的領導、熟悉業務流程的專家、系統終端使用者。

　　每一個使用者代表者代表了一個特定的使用者類，並在那個使用者類和開發者之間充當主要的介面，使用者代表從他們所代表的使用者類中收集需求資訊，同時每個使用者代表又負責協調他們所代表的使用者在需求表達上的不一致性和不相容性。

　　4、建立核心隊伍

　　通常使用者和開發人員不自覺的都有一種"我們和他們"的想法，產生一種對立關係，把彼此放在對立面，每一方都定義自己的"邊界"，只想自己的利益而忽略對方的想法。他們通過文件、記錄和對話來溝通，而不是作為一個合作的整體去識別和確定需求完成任務。實踐證明這樣的方法是不正確的，不會給雙方帶來一點益處,良好的溝通關係沒有建立導致了誤解和忽略重要的資訊。只有當雙方參與者都明白要成功自己需要什麼，同時也知道要成功對方需要什麼時，才能建立起一種合作關係。

　　為了建立合作關係通常採取一種組隊的方式來獲取需求，建立一個由使用者代表和開發人員組成的聯合小組作為需求獲取的核心隊伍。聯合小組將負責識別需求、分析解決方案和協商分歧，小組成員可以採用會議、電子郵件、綜合辦公系統等方式進行交流，但交流時應注意以下原則：小組會議應該由中立方來組織和主持，使用者和開發人員都要參加;交流預先要確定準備和參與的規則;議題要明確並覆蓋所有關鍵點，但資訊來源應該自由;交流目標要明確，並告知所有的成員。

　　5、確定使用例項

　　從使用者代表處收集他們將使用系統完成所需任務的描述，討論使用者與系統間的互動方式和對話要求，這就是使用例項，一個單一的使用例項可能包括完成某項任務的許多邏輯相關任務和互動順序。使用例項方法給需求獲取帶來的好處來自於該方法是用以任務為中心和以使用者為中心的觀點，比起使用以功能為中心和以開發者為中心的方法，使用例項方法可以使使用者更清楚地理解和認識到新系統允許他們做什麼和怎麼做。描寫使用例項的時候要注意使用簡潔直白的表述，儘量使用主動語態，"系統"或者"使用者"作為主語，比如"使用者提交使用者密碼，系統驗證使用者密碼是否正確"，還有一點在描述中不要設計介面細節，比如"使用者從下拉框中選擇產品型別"。使用例項為以後寫用例場景描述中的基本路徑和擴充套件路徑提供了素材。

　　6、召開聯合會議

　　最常見的需求獲取方法是召開會議或者面談，聯合會議是範圍廣的、簡便的討論會，也是核心隊伍成員之間一種很好的溝通方法，該會議通過緊密而集中的討論得以將使用者代表與開發人員間的合作伙伴關係付諸於實踐並能由此擬出需求文件的底稿。聯合會議的第一個議題就是系統的必要性和合理性，必須所有成員都同意系統是必要的而且合理的。接下來就可以討論使用例項清單，清單可以列印成大紙掛在牆上、寫在黑板上或做成演示材料。對每個清單合併去掉重複項，加上補充內容就可以得到一份總的清單，注意避免採用負面的"太差""不可行"去否定使用者的想法，這些想法都應該保留下來作為被評議的清單項，這樣保護了小組成員開放的思維。最後對清單進行討論，會議成員必須檢查每一個使用例項，在把它們納入需求之前決定其是否在專案所定義的範圍內，形成最終的需求報告。

　　在進行討論時，也應該避免受不成熟的細節的影響，在對系統需求取得共識之前，使用者能很容易地在一個報表或對話方塊中列出某些精確設計，如果這些細節都作為需求記錄下來，他們會給隨後的設計過程帶來不必要的限制，應確保使用者參與者將注意力集中在與所討論的話題適合的抽象層上，重點就是討論做什麼而不是怎麼做。這裡有一點很重要就是要讓使用者理解對於某些功能的討論並不意味著即將在系統中實現它，更不要做暗示或者承諾什麼時候完成需求。在討論之後，記下所討論的條目，並請參與討論的使用者評論並更正，因為只有提供需求的人才能確定是否真正獲取需求。當最後拿到了一份詳細準確的需求報告書的時候，會議就算成功完成了。但是要清楚需求過程本身就是一個迭代的過程，在以後的過程活動中不可避免的將要修改和完善這份報告。

　　7、分析使用者工作流程

　　分析使用者工作流程觀察使用者執行業務任務的過程，通過分析使用例項得到系統的用例圖。編制用例圖文件將有助於明確系統的使用例項和功能需求，統一建模語言的使用有助於與使用者進一步交流。每個用例的描述應包括：編號,為每個用例分配一個唯一的編號，為需求的追溯提供了方便;參與者，與這個用例互動的actor;前置條件，開始用例前所必須具備的系統狀態;後置條件，用例完成後系統達到的狀態;基本路徑，用例完成的關鍵路徑，也是使用者期望的路徑;擴充套件點，基本路徑的分枝，表示意外情況;欄位說明，路徑中名稱的進一步分解說明，對以後類屬性的定義和資料庫欄位設計起作用;設計約束，實現用例的非功能約束。寫基本路徑時應該使用主動語句;句子以actor或者系統作為主語;一句表示一個actor動作，一句表示系統動作，交叉表現互動;不要涉及介面細節，比如"使用者在文字框輸入名稱，下拉框選擇型別"。

　　用例：使用者註冊，使用者註冊成為系統會員

　　編號

　　UC1

　　參與者使用者

　　前置條件

　　使用者訪問系統，系統執行正常

　　後置條件

　　系統記錄使用者註冊資訊

　　基本路徑

　　1.使用者請求註冊。

　　2.系統顯示註冊介面。

　　3.使用者提交註冊資訊。

　　4.系統驗證註冊資訊是否正確。

　　5.系統生成使用者名稱和密碼，儲存註冊資訊。

　　6.系統顯示"註冊成功"資訊，進入會員頁面。

　　擴充套件點

　　4a.使用者提供的資訊不正確：

　　4a1.系統提示輸入正確資訊

　　4a2.返回3

　　補充說明

　　註冊資訊包括=使用者實名+電話+傳真+Email+聯絡地址聯絡地址=省份+城市+街道+郵編

　　設計約束

　　註冊反應時間不能超過3秒

　　8、確定質量屬性

　　在功能需求之外再考慮一下非功能的質量特點，以及確定由於特殊的商業應用環境對系統提出的功能或效能上的約束，這會使你的產品達到並超過客戶的期望。對系統如何能很好地執行某些行為或讓使用者採取某一措施的陳述就是質量屬性，這是一種非功能需求。聽取那些描述合理特性的意見：快捷、簡易、直覺性、使用者友好、健壯性、可靠性、安全性和高效性。你將要和使用者一起商討精確定義他們模糊的和主觀言辭的真正含義，並且要將質量屬性分配到每個用例的設計約束中去。

　　9、檢查問題報告

　　通過檢查當前已經執行系統的問題報告來進一步完善需求客戶的問題報告及補充需求為新系統或新版本提供了大量豐富的改進及增加特性的想法，負責提供使用者支援及幫助的人能為收集需求過程提供極有價值的資訊。

　　10、需求重用

　　如果客戶要求的功能與已有的系統很相似，則可檢視需求是否有足夠的靈活性以允許重用一些已有的軟體元件。業務建模和領域建模式需求重用的最好方法，像分析模式和設計模式一樣，需求也有自己的模式。