軟件項(xiàng)目需求管理課件

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

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

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

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

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

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

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

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

9、本費(fèi)用進(jìn)行評估。需求變更管理中活動一般包括：確定需求變更控制過程建立需求變更控制委員會進(jìn)行需求變更影響分析建立需求基準(zhǔn)版本和需求控制版本文檔維護(hù)需求變更的歷史記錄跟蹤每項(xiàng)需求的狀態(tài)跟蹤所有受需求變更影響的工作產(chǎn)品衡量需求穩(wěn)定性需求開發(fā)和管理過程第15頁，共34頁。 訪談和調(diào)研和用戶進(jìn)行訪談和調(diào)研通常是適用于任何環(huán)境下的最重要最直接的方法之一。訪談的一個主要目標(biāo)是確保訪談?wù)叩钠娀蛑饔^意識不會干擾自由的交流?！碍h(huán)境無關(guān)問題”就是不涉及任何背景的問題。通過幾次這樣的訪談，開發(fā)人員和系統(tǒng)分析員能獲得一些問題域中的知識，對要解決的問題有進(jìn)一步的理解。6.3 需求獲取方法第16頁，共34頁。 專題討論會

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

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

12、分析者利用場景或經(jīng)歷來描述用戶和軟件系統(tǒng)的交互方式，并以此來獲取軟件需求。使用用例的分析方法來源于面向?qū)ο蟮乃枷?。用例分析方法最大的特點(diǎn)在于面向用例，在對用例的描述中引入了外部角色的概念。 相關(guān)技術(shù)用例需求分析常常采用UML（Unified Modeling Language，統(tǒng)一建模語言）技術(shù)，UML是一種面向?qū)ο蟮慕ＵZ言。6.4 需求分析建模方法第20頁，共34頁。 原型分析方法原型法是為了快速開發(fā)系統(tǒng)而推出的一種開發(fā)模式，旨在改進(jìn)傳統(tǒng)的結(jié)構(gòu)化生命周期法的不足，縮短開發(fā)周期，減少開發(fā)風(fēng)險。原型法的理念對原型的基本要求原型法進(jìn)行軟件需求分析的過程原型法的適用范圍需求分析建模方法第21頁，共

13、34頁。 結(jié)構(gòu)化分析方法結(jié)構(gòu)化分析方法(Structured Method，結(jié)構(gòu)化方法)是強(qiáng)調(diào)開發(fā)方法的結(jié)構(gòu)合理性以及所開發(fā)軟件的結(jié)構(gòu)合理性的軟件開發(fā)方法。結(jié)構(gòu)化的分析方法的基本步驟為： 需求分析業(yè)務(wù)流程分析數(shù)據(jù)流程分析編制數(shù)據(jù)字典結(jié)構(gòu)化分析方法的優(yōu)點(diǎn)與局限性。需求分析建模方法第22頁，共34頁。Rational RequisiteProBorland CaliberRational RoseRational XDERational ClearCase 6.5 需求管理工具第23頁，共34頁。本節(jié)以HRMS（Human Resource Manage System）的系統(tǒng)為例，介紹需求的開發(fā)和

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

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

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

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