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