需求管理之擷取使用者需求的十大溝通技巧

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

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

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

　　需求擷取活動建議要完成的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、需求重用

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