1、第 6 章 軟件項目需求管理 第1頁，共34頁。6.1 軟件項目需求管理概述影響軟件項目成敗的因素第2頁，共34頁。軟件開發的目標按時按預算開發出滿足用戶真實需要的軟件。需求 一個軟件項目的開始階段。在軟件工程中，需求分析階段是 包括客戶、用戶、業務或需求分析員、開發人員、測試人員、用戶文檔編寫者、項目管理者和客戶管理者在內的所有的風險承擔者都需要參與的階段。軟件項目需求管理概述第3頁，共34頁。 需求定義 IEEE軟件工程標準詞匯表(1997年)中將需求定義為：用戶解決問題或達到目標所需的條件或權能(Capability)；系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件

2、或權能；一種反映上面(1)或(2)所描述的條件或權能的文檔說明。 軟件需求包括以下幾個層次：業務需求（business requirement）用戶需求（user requirement）功能需求（functional requirement）同時也包括非功能需求、軟件需求規格說明（software requirements specification，SRS）等。軟件項目需求管理概述第4頁，共34頁。軟件項目需求管理概述軟件需求各組成部分關系第5頁，共34頁。 需求類型 在UP（統一過程）中，軟件需求是根據FURPS+模型來分類的，其中FURPS的含義如下：Functional（功能性）Us

3、ability（可用性）Reliability（可靠性）Performance（性能）Supportability（可支持性）“+”是指一些輔助性的和次要的因素： Implementation（實現）Interface（接口）Operations（操作）Packaging(包裝)Legal（授權）軟件項目需求管理概述第6頁，共34頁。需求過程所涉及的工作6.2 需求開發和管理過程第7頁，共34頁。需求工程也叫做需求過程或需求階段，包括需求開發和需 求管理。需求開發包括需求獲取、需求分析、編寫需求規格說明、驗證需求四個階段，在這四個階段執行以下活動：確定產品所期望的用戶類；獲取每個用戶類的需求；

4、了解實際用戶任務和目標以及這些任務所支持的業務需求；分析源于用戶的信息以區別業務需求、功能需求、質量屬性、業務規則，建議解決的方法和附加的信息； 分解需求，并將需求中的一部分分配給軟件組件；了解相關屬性的重要性；劃分實施優先級；編寫需求規格說明和模型；評審需求規格，驗證對用戶需求的正確理解和認識。需求開發和管理過程第8頁，共34頁。需求管理是一種用于查找、記錄、組織和跟蹤系統需求變更的系統化方法，可用于獲取、組織和記錄系統需求并使客戶和項目團隊在系統需求變更上保持一致。有效的需求管理在于維護清晰明確的需求闡述、每種需求類型所適用的屬性，以及與其它需求和其它項目工件之間的可追蹤性。需求管理活動包

5、括定義需求基線評審需求變更并評估每項需求變更對軟件產品的影響從而決定是否實施它。以一種可控制的方式將需求變更融入當前的軟件項目。讓當前的項目計劃和需求保持一致。估計變更所產生的影響并在此基礎上協商新的約定實現通過需求可跟蹤對應的設計、源代碼和測試用例。在整個項目過程中跟蹤需求狀態及其變更情況。需求開發和管理過程第9頁，共34頁。 需求獲取 需求獲取的主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現有的組織架構、業務流程、系統環境等，對任務進行分析、從而開發、捕獲和修訂用戶的需求，以建立良好的溝通渠道和方式。 需求獲取需要執行以下活動： 確定需求開發過程 編寫項目視圖和范圍文檔 獲取涉眾請

6、求 選擇每類用戶的產品代表 建立典型的以用戶為核心的隊伍 讓用戶代表確定用例 召開應用程序開發聯系會議 分析用戶工作流程 確定質量屬性和其它非功能需求需求開發和管理過程第10頁，共34頁。 需求分析 需求分析包括提煉、分析和仔細審查已收集到的需求，為最終用戶所看到的系統建立一個概念模型以確保所有的風險承擔者都明白其含義并找出其中的錯誤、遺漏或其它不足的地方。分析用戶需求應該執行以下活動：繪制系統關聯圖創建用戶接口原型分析需求可行性確定需求的優先級別為需求建立模型建立數據字典使用質量功能調配需求開發和管理過程第11頁，共34頁。 需求規格說明軟件需求規格說明闡述一個軟件系統必須提供的功能和性能以

7、及它所要考慮的限制條件,它不僅是系統測試和用戶文檔的基礎，也是所有子系列項目規劃、設計和編碼的基礎。需求分析完成的標志是提交一份完整的軟件需求規格說明書（SRS）。軟件需求規格說明作為產品需求的最終成果必須包括所有的需求。在開發人員的組織中要為編寫軟件需求文檔定義一種標準模板。需求開發和管理過程第12頁，共34頁。需求規格說明模板123456a.引言目的文檔約定預期的讀者和閱讀建議產品的范圍參考文獻b.綜合描述產品的前景產品的功能用戶類和特征運行環境設計和實現上的限制假設和依賴附錄c.外部接口需求 附錄用戶界面附錄硬件接口軟件接口通信接口d.系統特性說明和優先級激勵/響應序列功能需求e.其它非

8、功能需求性能需求安全設施需求安全性需求軟件質量屬性業務規則用戶文檔f.其它需求g.附件詞匯表分析模型待確定問題的列表需求開發和管理過程第13頁，共34頁。 需求驗證驗證是為了確保需求說明準確、無二義性并完整地表達系 統功能以及必要的質量特性。需求驗證要求客戶代表和開發人員共同參與，對提交后的需求規格說明進行驗證，分析需求的正確性，完整性以及可行性等等。需求驗證中的活動一般包括：審查需求文檔以需求為依據編寫測試用例編寫用戶手冊確定合格的標準最后的簽字需求開發和管理過程第14頁，共34頁。 需求變更管理 需求變更管理是項目管理中非常重要的一項工作。有效的需求變更管理能對變更帶來的潛在影響及可能的成

9、本費用進行評估。需求變更管理中活動一般包括：確定需求變更控制過程建立需求變更控制委員會進行需求變更影響分析建立需求基準版本和需求控制版本文檔維護需求變更的歷史記錄跟蹤每項需求的狀態跟蹤所有受需求變更影響的工作產品衡量需求穩定性需求開發和管理過程第15頁，共34頁。 訪談和調研和用戶進行訪談和調研通常是適用于任何環境下的最重要最直接的方法之一。訪談的一個主要目標是確保訪談者的偏見或主觀意識不會干擾自由的交流。“環境無關問題”就是不涉及任何背景的問題。通過幾次這樣的訪談，開發人員和系統分析員能獲得一些問題域中的知識，對要解決的問題有進一步的理解。6.3 需求獲取方法第16頁，共34頁。 專題討論會

10、專題討論會是一種可用于任何情況下的軟件需求調研方法。專題討論會的目的是鼓勵軟件需求調研并且在很短的時間內 對討論的問題達成一致。專題討論會一般由開發團隊的成員主持，主要討論系統應具備的特征或者評審系統特性。專題討論會前的準備工作是能否成功的舉行會議的關鍵。需求獲取方法第17頁，共34頁。 腦力風暴 腦力風暴是一種對于獲取新觀點或創造性的解決方案而言非常有用的方法。 通常，專題討論會的一部分時間是用于進行腦力風暴，找出關于軟件系統的新想法和新特征。 腦力風暴包括兩個階段：想法產生階段和想法精化階段。應用程序腦力風暴中確定的特征系統特征定義家用自動照明系統自動照明設置用戶可以制定每天自動照明的時間

11、計劃，系統將按時間計劃觸發照明事件任務管理系統代理任務通知當用戶將自己的任務代理給其他人時，系統自動發送Email通知將接手該任務的人腦力風暴中為確定的問題定義系統特征需求獲取方法第18頁，共34頁。 場景串聯 場景串聯的目的是為了盡早的從用戶那里得到用戶對建議的系統功能的意見。 場景串聯提供了用戶界面以說明系統操作流程，它容易創建和修改，能讓用戶知道系統的操作方式和流程。 根據與用戶交互的方式，場景串聯被分成三種模式：靜態的場景串聯、動態的場景串聯以及交互的場景串聯。 選擇提供哪種場景串聯是根據系統的復雜性和需求缺陷的風險來確定的。需求獲取方法第19頁，共34頁。 用例分析方法 簡介軟件需求

12、分析者利用場景或經歷來描述用戶和軟件系統的交互方式，并以此來獲取軟件需求。使用用例的分析方法來源于面向對象的思想。用例分析方法最大的特點在于面向用例，在對用例的描述中引入了外部角色的概念。 相關技術用例需求分析常常采用UML（Unified Modeling Language，統一建模語言）技術，UML是一種面向對象的建模語言。6.4 需求分析建模方法第20頁，共34頁。 原型分析方法原型法是為了快速開發系統而推出的一種開發模式，旨在改進傳統的結構化生命周期法的不足，縮短開發周期，減少開發風險。原型法的理念對原型的基本要求原型法進行軟件需求分析的過程原型法的適用范圍需求分析建模方法第21頁，共

13、34頁。 結構化分析方法結構化分析方法(Structured Method，結構化方法)是強調開發方法的結構合理性以及所開發軟件的結構合理性的軟件開發方法。結構化的分析方法的基本步驟為： 需求分析業務流程分析數據流程分析編制數據字典結構化分析方法的優點與局限性。需求分析建模方法第22頁，共34頁。Rational RequisiteProBorland CaliberRational RoseRational XDERational ClearCase 6.5 需求管理工具第23頁，共34頁。本節以HRMS（Human Resource Manage System）的系統為例，介紹需求的開發和

14、管理過程。需求開發需求獲取6.6 案例分析第24頁，共34頁。需求分類編號系統典型需求功能需求（Functional）1招聘人員：用戶可以通過招聘人員2申請職位：Web用戶可以填寫信息申請職位3查看職位申請信息：Web用戶可以查看職位申請信息4處理職位申請：管理員可以處理職位申請5修改申請人信息：管理員可以修改申請人的信息可用性（Usability）1對于熟悉公司原系統的用戶新系統應易于操作2系統應支持Internet環境3系統應給用戶提供在線指南可靠性（Reliability）1系統應該在任何時間都能工作，若是出現故障，必須要在一個小時之內修復2系統應能支持用戶在指定的時間備份資料 HRMS

15、系統中的需求分類案例分析第25頁，共34頁。性能需求（Performance）1管理系統必須支持公司內部員工和web用戶同時訪問，并且支持同時在線人數不低于100人2系統的響應時間不超過4秒安全性需求（Security）1支持多用戶訪問系統2一般用戶只能查看和修改自己的信息不能看到其他人的信息3公司的下級員工不能查看上級員工的信息4公司的上級員工可以查看下級員工的信息而不能修改可支持性（Supportability）1系統采用B/S結構，用戶可以通過Internet訪問系統2培訓系統可以在所有流行的瀏覽器（如Navigation,IE）上正常顯示 HRMS系統中的需求分類案例分析第26頁，共3

16、4頁。需求分析本項目采用原型分析方法和用例分析方法相結合來進行需求分析，以用例分析方法為主，對于每個Use Case，創建用戶接口說明文檔和Use case報告，同時建立這個用例的原型。此系統的角色定義如圖所示。HMS中的角色案例分析第27頁，共34頁。其中各個角色描述如下：角色1: 員工（Employee）角色2: 雇用經理（Hiring Manager）角色3: 部門經理（Department Manager）角色4: 上級（Superior）角色5: 分區經理（Division Manager）角色6: 運行官（Operation Head）角色7: 申請人（Applicant） 角色8

17、: 人力資源經理（HR Manager）角色9: 培訓經理（Training Administrator） 角色10: 培訓中心經理（Training Center Administrator） 案例分析第28頁，共34頁。用例分析 HRMS中的用例圖案例分析第29頁，共34頁。用例1：招聘員工（Recruit Employee）用例2：候選人分類（Categorize Candidate）用例3：更新面試信息（Update Interview）用例4：確認候選人（Confirm Candidate）用例5：管理申請（Manage Requisition） 用例6：記錄申請者信息（Register Applicant Data）用例7：修改申請者信息（Modify Applicant Data）用例8：確認申請信息（Validate Application）案例分析第30頁，共34頁。編寫Use Case報告為系統中的每個用例編寫Use Case報告，則系統分析與設計人員可以更加清晰的掌握系統架構。格式如下：Use Case Report: 創建員工記錄【簡短描述】【事件流】【特殊需求】【執行前條件】【執行后結果】【Use case圖】【場景】案例分析第31頁，共34頁。下表描述了該用例和主角與其他use case的關系。 HRMS中的用例圖案例分析第32頁，共34頁。 需求變更