信息系統(tǒng)項(xiàng)目管理師需求管理培訓(xùn)教材課件

信息系統(tǒng)項(xiàng)目管理師

需求管理閆波信息系統(tǒng)項(xiàng)目管理師

需求管理閆波1需求管理用戶需求是軟件項(xiàng)目成敗的關(guān)鍵需求問題：需求的隱含錯(cuò)誤需求不明確、含糊用戶刁難、用戶不斷增加需求需求變更需求管理用戶需求是軟件項(xiàng)目成敗的關(guān)鍵2本章要點(diǎn)17.1需求管理概述17.2制定需求管理計(jì)劃17.3需求管理規(guī)格說明的版本控制17.4需求變更管理17.5需求跟蹤本章要點(diǎn)17.1需求管理概述3需求管理需求：指的是由項(xiàng)目接受的或項(xiàng)目產(chǎn)生的產(chǎn)品和產(chǎn)品構(gòu)件需求。包括由組織征集的對(duì)項(xiàng)目的需求。RequirementManagement需求管理確保各方對(duì)需求的一致理解，管理和控制需求的變更，從需求到最終產(chǎn)品的雙向跟蹤。需求管理需求：指的是由項(xiàng)目接受的或項(xiàng)目產(chǎn)生的產(chǎn)品和產(chǎn)品構(gòu)件需4軟件需求定義需求是指用戶對(duì)軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達(dá)到什么性能。軟件需求定義需求是指用戶對(duì)軟件的功能和性能的要求，就是用戶希5軟件需求特征：模糊性不確定性變化性主觀性軟件需求特征：6軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格非功能性需求質(zhì)量特性約束和假設(shè)系統(tǒng)需求軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格非功能性需7軟件需求的類型功能需求性能需求環(huán)境需求用戶界面需求資源使用需求成本消耗需求開發(fā)進(jìn)度需求預(yù)先估計(jì)以后系統(tǒng)可能達(dá)到的目標(biāo)軟件需求的類型功能需求8軟件需求的重要性軟件需求的重要性9需求管理與項(xiàng)目管理的關(guān)系項(xiàng)目需求是制定項(xiàng)目計(jì)劃，開發(fā)項(xiàng)目產(chǎn)品和從事項(xiàng)目活動(dòng)的依據(jù)。項(xiàng)目的計(jì)劃、項(xiàng)目的開發(fā)活動(dòng)及開發(fā)的產(chǎn)品應(yīng)與項(xiàng)目需求保持一致，隨需求的變化而調(diào)整。需求管理與項(xiàng)目管理的關(guān)系項(xiàng)目需求是制定項(xiàng)目計(jì)劃，開發(fā)項(xiàng)目產(chǎn)品10需求工程（RE）需求工程是指應(yīng)用已證實(shí)有效的技術(shù)、方法進(jìn)行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標(biāo)系統(tǒng)的所有外部特征一門學(xué)科。需求開發(fā)需求管理需求工程（RE）需求工程是指應(yīng)用已證實(shí)有效的技術(shù)、方法進(jìn)行需11軟件需求工程管理的過程需求分析需求定義需求驗(yàn)證需求獲取需求管理需求開發(fā)需求管理軟件需求工程管理的過程需求分析需求定義需求驗(yàn)證需求獲取需求管12需求獲取需求獲取13

擴(kuò)展需求需求獲取用戶要求基線需求軟件需求通過與用戶的交流，對(duì)現(xiàn)有系統(tǒng)的觀察及對(duì)任務(wù)進(jìn)行分析，從而開發(fā)、捕獲和修訂用戶的需求。需求獲取用戶要求軟件需求通過與用戶的交流，對(duì)現(xiàn)有系統(tǒng)的觀察及14獲取需求的活動(dòng)了解用戶類型及潛在類型訪談和調(diào)研（要有記錄）對(duì)用戶需求進(jìn)一步整理和提取將用戶需求反饋用戶獲取需求的活動(dòng)了解用戶類型及潛在類型15注意事項(xiàng)識(shí)別真正的客戶.正確理解客戶的需求具備較強(qiáng)的忍耐力和清晰的思維說服和教育客戶注意事項(xiàng)識(shí)別真正的客戶.16需求分析定義：需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型，是對(duì)需求的抽象描述。

需求分析也稱為需求建模需求分析定義：需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模17需求分析模型需求分析模型18需求分析的時(shí)間設(shè)計(jì)方案的時(shí)候項(xiàng)目開始的時(shí)候接管一個(gè)項(xiàng)目的時(shí)候需求變更的時(shí)候需求分析的時(shí)間設(shè)計(jì)方案的時(shí)候19需求分析基本策略頭腦風(fēng)暴專家評(píng)審焦點(diǎn)會(huì)議組目的：進(jìn)行具體的流程細(xì)化、數(shù)據(jù)項(xiàng)確認(rèn)，必要時(shí)可以提供原型系統(tǒng)和明確的業(yè)務(wù)流程報(bào)告、數(shù)據(jù)項(xiàng)表，并能清晰的向用戶描述系統(tǒng)的業(yè)務(wù)流設(shè)計(jì)目標(biāo)。需求分析基本策略頭腦風(fēng)暴20需求分析的難點(diǎn)問題的復(fù)雜性（不了解業(yè)務(wù)）交流的障礙不完備性和不一致性需求的易變性需求分析的難點(diǎn)問題的復(fù)雜性（不了解業(yè)務(wù)）21需求定義需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)范的需求規(guī)格說明書（SRS）需求規(guī)格說明書的編制是為了使用戶和軟件開發(fā)者雙方對(duì)該軟件的初始規(guī)定有一個(gè)共同的理解，使之成為整個(gè)開發(fā)工作的基礎(chǔ)。需求定義需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)22軟件需求規(guī)格說明的原則從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”要求使用面向處理的規(guī)格說明語言（或稱系統(tǒng)定義語言）如果被開發(fā)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說明的描述之中規(guī)格說明必須包括系統(tǒng)運(yùn)行環(huán)境規(guī)格說明必須是一個(gè)認(rèn)識(shí)模型規(guī)格說明必須是可操作的規(guī)格說明必須容許不完備性并允許擴(kuò)充軟件需求規(guī)格說明的原則從現(xiàn)實(shí)中分離功能，即描述要“做什么”而23需求規(guī)格說明書文檔參考引言系統(tǒng)定義應(yīng)用環(huán)境功能規(guī)格性能需求產(chǎn)品提交實(shí)現(xiàn)約束質(zhì)量描述其它簽字認(rèn)證需求規(guī)格說明書文檔參考引言24需求驗(yàn)證開發(fā)方和用戶方共同對(duì)需求文檔進(jìn)行評(píng)審，經(jīng)雙方對(duì)需求達(dá)成共識(shí)后做出書面承諾，使需求文檔具有商業(yè)合同效果。需求驗(yàn)證開發(fā)方和用戶方共同對(duì)需求文檔進(jìn)行評(píng)審，經(jīng)雙方對(duì)需求達(dá)25需求驗(yàn)證需求是正確的嗎？需求是一致的嗎？需求是完全的嗎？需求是實(shí)際可行的嗎？需求是客戶需要的嗎？需求是可檢驗(yàn)的嗎？需求是可跟蹤的嗎？最后的簽字需求驗(yàn)證需求是正確的嗎？26需求驗(yàn)證快速原型法需求驗(yàn)證快速原型法27需求管理需求管理中要收集需求的變更和變更的理由，維持對(duì)原有需求和所有產(chǎn)品及產(chǎn)品構(gòu)件需求的雙向跟蹤。需求管理需求管理中要收集需求的變更和變更的理由，維持對(duì)原有需28需求變更項(xiàng)目失敗主要的原因在于需求變更!需求變更項(xiàng)目失敗主要的原因在于需求變更!29信息系統(tǒng)項(xiàng)目管理師需求管理培訓(xùn)教材課件30需求建模的方法創(chuàng)建體系結(jié)構(gòu)的表示形式以捕獲需求、就解決方案方法進(jìn)行交流、以及分析所提出的系統(tǒng)設(shè)計(jì)。其目的是使用模型來表現(xiàn)系統(tǒng)中的關(guān)鍵方面。需求建模的方法創(chuàng)建體系結(jié)構(gòu)的表示形式以捕獲需求、就解決方案方31原型分析法定義：按照用戶的需要，快速形成一個(gè)操作流程界面可能只是一個(gè)框架，具體的功能沒有實(shí)現(xiàn)，只是結(jié)果靜態(tài)的操作流程，以便與用戶快速就需求達(dá)成一致主要考慮系統(tǒng)的功能需求，很少考慮非功能需求原型分析法定義：32原型方法需求分析原型開發(fā)原型評(píng)價(jià)原型方法需求分析原型開發(fā)原型評(píng)價(jià)33原型方法的類型進(jìn)化型開發(fā)出來用于了解問題，并形成被交付軟件的部分或全部的基礎(chǔ)拋棄型開發(fā)出來獲以便更多地了解問題或探究可能的方案的靈活性或者合理性，是嘗試性軟件，不用于被交付軟件的實(shí)際部分原型方法的類型進(jìn)化型34結(jié)構(gòu)化分析法定義（SA,StructuredAnalysis）20世紀(jì)70年發(fā)展起來的面向數(shù)據(jù)流的方法是一種自頂向下逐步求精的分析方法根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系進(jìn)行分析的結(jié)構(gòu)化分析法定義（SA,StructuredAnalysi35結(jié)構(gòu)化分析方法－技術(shù)數(shù)據(jù)流圖(DFD)數(shù)據(jù)字典(DD)系統(tǒng)流程圖結(jié)構(gòu)化分析方法－技術(shù)數(shù)據(jù)流圖(DFD)36數(shù)據(jù)流圖是一種描述軟件系統(tǒng)邏輯模型的圖形符號(hào)表示數(shù)據(jù)的起始點(diǎn)和終點(diǎn)表示對(duì)數(shù)據(jù)的加工處理表示數(shù)據(jù)流,箭頭表示數(shù)據(jù)的流動(dòng)方向表示對(duì)數(shù)據(jù)的存儲(chǔ)數(shù)據(jù)流圖是一種描述軟件系統(tǒng)邏輯模型的圖形符號(hào)表示數(shù)據(jù)的起始點(diǎn)37銀行取款過程數(shù)據(jù)流圖銀行取款過程數(shù)據(jù)流圖38數(shù)據(jù)流圖的層次結(jié)構(gòu)為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采用層次結(jié)構(gòu)的數(shù)據(jù)流圖。按照系統(tǒng)的層次結(jié)構(gòu)進(jìn)行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關(guān)系，能清楚地表達(dá)和容易理解整個(gè)系統(tǒng)數(shù)據(jù)流圖的層次結(jié)構(gòu)為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采39分層數(shù)據(jù)流圖分層數(shù)據(jù)流圖40分層數(shù)據(jù)流圖頂層流圖僅包含一個(gè)加工，它代表被開發(fā)系統(tǒng)。它的輸入流是該系統(tǒng)的輸入數(shù)據(jù)，輸出流是系統(tǒng)所輸出數(shù)據(jù)底層流圖是指其加工不需再做分解的數(shù)據(jù)流圖，它處在最底層中間層流圖則表示對(duì)其上層父圖的細(xì)化。它的每一加工可能繼續(xù)細(xì)化，形成子圖。分層數(shù)據(jù)流圖頂層流圖僅包含一個(gè)加工，它代表被開發(fā)系統(tǒng)。它的輸41數(shù)據(jù)字典描述系統(tǒng)中涉及的每個(gè)數(shù)據(jù),是數(shù)據(jù)描述的集合,通常配合數(shù)據(jù)流圖使用,用來描述數(shù)據(jù)流圖中出現(xiàn)的各種數(shù)據(jù)和加工.組成：數(shù)據(jù)項(xiàng):數(shù)據(jù)元素?cái)?shù)據(jù)流:由數(shù)據(jù)項(xiàng)組成的數(shù)據(jù)流數(shù)據(jù)文件:表示對(duì)數(shù)據(jù)文件的存儲(chǔ)數(shù)據(jù)字典描述系統(tǒng)中涉及的每個(gè)數(shù)據(jù),是數(shù)據(jù)描述的集合,通常配合42數(shù)據(jù)字典關(guān)系符號(hào)符號(hào)含義=等于,定義為+加[]選擇符,表示對(duì)[]列舉的值可以任取其一{}重復(fù)符,表示對(duì){}中的內(nèi)容可視需要重復(fù)使用()可選符,表示對(duì)()中的內(nèi)容可由設(shè)計(jì)員決定取舍*……*注釋符,表示兩個(gè)*之間的內(nèi)容為對(duì)條目的注釋數(shù)據(jù)字典關(guān)系符號(hào)符號(hào)含義=等于,定義為+加[]選擇符,表43數(shù)據(jù)流圖需求分析實(shí)例建立學(xué)生管理系統(tǒng)學(xué)管科體檢科學(xué)籍科學(xué)生處數(shù)據(jù)流圖需求分析實(shí)例建立學(xué)生管理系統(tǒng)44頂層數(shù)據(jù)流圖學(xué)管科體檢科學(xué)籍科學(xué)生管理信息系統(tǒng)學(xué)生處領(lǐng)導(dǎo)學(xué)生基本信息學(xué)生健康信息學(xué)生成績學(xué)生健康情況表學(xué)生成績單查詢要求不及格人數(shù)人數(shù)統(tǒng)計(jì)表頂層數(shù)據(jù)流圖學(xué)管科體檢科學(xué)籍科學(xué)生管理學(xué)生處領(lǐng)導(dǎo)學(xué)生基本信息45第0層數(shù)據(jù)流圖第0層數(shù)據(jù)流圖46第1層數(shù)據(jù)流圖第1層數(shù)據(jù)流圖47系統(tǒng)流程圖系統(tǒng)包含的部分以及各個(gè)部分之間的關(guān)系是描述物理系統(tǒng)的工具用圖形符號(hào)表示系統(tǒng)中的元素表達(dá)了系統(tǒng)中各個(gè)元素之間的信息流動(dòng)情況系統(tǒng)流程圖系統(tǒng)包含的部分以及各個(gè)部分之間的關(guān)系48系統(tǒng)流程圖符號(hào)系統(tǒng)流程圖符號(hào)49信息系統(tǒng)項(xiàng)目管理師需求管理培訓(xùn)教材課件50用例分析法面向?qū)ο蟮能浖こ蹋∣OSE）OOAOODOOP(objectorientedprogramming

)OOT…….用例分析法面向?qū)ο蟮能浖こ蹋∣OSE）51用例（UserCase）表示一個(gè)動(dòng)作序列的定義，包括執(zhí)行的變量和外界交互的過程。提款機(jī)取款用例用例（UserCase）表示一個(gè)動(dòng)作序列的定義，包括執(zhí)行的52OOA是OO軟件工程的第一項(xiàng)技術(shù)活動(dòng)將現(xiàn)實(shí)世界的“視圖”轉(zhuǎn)化為用對(duì)象來描述的模型描述對(duì)象之間的各種關(guān)系，以滿足軟件系統(tǒng)的要求。OOA是OO軟件工程的第一項(xiàng)技術(shù)活動(dòng)53用例需求分析用例需求分析方法采用一種面向?qū)ο蟮那榫胺治龇椒ㄓ美窍到y(tǒng)向用戶提供一個(gè)有價(jià)值的結(jié)果的某項(xiàng)功能所有的用例結(jié)合起來就構(gòu)成了用例模型從用戶角度出發(fā)考慮的功能需求用例需求分析用例需求分析方法采用一種面向?qū)ο蟮那榫胺治龇椒?4用例需求分析從前：問用戶希望系統(tǒng)為他做什么？現(xiàn)在：問用戶利用系統(tǒng)做什么？用例需求分析從前：問用戶希望系統(tǒng)為他做什么？55UMLUnifiedModelingLanguage統(tǒng)一建模語言，是一種通用的模擬語言。Booch,Rumbaugh和Jocobson基礎(chǔ)上發(fā)展起來的。1997年11月國際對(duì)象管理組織OMG批準(zhǔn)將UML作為基于面向?qū)ο蠹夹g(shù)的標(biāo)準(zhǔn)建模語言。UML制定了一整套完整的面向?qū)ο蟮臉?biāo)記和處理方法。UMLUnifiedModelingLanguage統(tǒng)一56UML需求視圖用例視圖（UsecaseDiagram）順序圖（SequenceDiagram）狀態(tài)圖（StateDiagram）活動(dòng)圖（ActivityDiagram）UML需求視圖用例視圖（UsecaseDiagram）57USECASE視圖用例視圖主要是展示了外部行為者所觀察到的系統(tǒng)將提交的功能.即:各類外部行為者與系統(tǒng)所提供的用例的連接－－－－用例（Usecase）：系統(tǒng)所提供的功能描述角色（Actor）：可能使用用例的人或者外部系統(tǒng)USECASE視圖用例視圖主要是展示了外部行為者所觀察到的58UML圖符UML圖符59USERCASE實(shí)例USERCASE實(shí)例60序列（Sequence）圖順序圖展示了幾個(gè)對(duì)象之間的動(dòng)態(tài)協(xié)作關(guān)系，主要用來顯示對(duì)象之間發(fā)送消息的順序，還顯示對(duì)象之間的交互，即系統(tǒng)執(zhí)行某一特定時(shí)間點(diǎn)所發(fā)生的事。序列（Sequence）圖順序圖展示了幾個(gè)對(duì)象之間的動(dòng)態(tài)協(xié)作61Sequence實(shí)例Sequence實(shí)例62狀態(tài)視圖狀態(tài)圖是對(duì)類描述的補(bǔ)充，它說明該類的對(duì)象所有可能的狀態(tài)以及那些事件將導(dǎo)致狀態(tài)的改變。它是一個(gè)類對(duì)象所可能經(jīng)歷的所有歷程的模型圖。狀態(tài)視圖狀態(tài)圖是對(duì)類描述的補(bǔ)充，它說明該類的對(duì)象所有可能的狀63活動(dòng)（Activity）視圖活動(dòng)圖用來描述執(zhí)行工作流程中涉及的活動(dòng)，展示了連續(xù)的活動(dòng)流活動(dòng)（Activity）視圖活動(dòng)圖用來描述執(zhí)行工作流程中涉及64活動(dòng)圖例活動(dòng)圖例65UseCase需求分析方法綜述識(shí)別出系統(tǒng)的Actor描述主要的Usecase實(shí)現(xiàn)用例視圖實(shí)現(xiàn)順序視圖，活動(dòng)視圖,狀態(tài)視圖等UseCase需求分析方法綜述識(shí)別出系統(tǒng)的Actor66功能列表法對(duì)項(xiàng)目的功能需求進(jìn)行詳細(xì)說明，既可以單獨(dú)使用，也可以作為用例分析方法的附加說明來詳細(xì)說明用例的具體功能。功能列表法對(duì)項(xiàng)目的功能需求進(jìn)行詳細(xì)說明，既可以單獨(dú)使用，也可67為什么會(huì)有需求變更？與用戶交互不夠，對(duì)問題理解有差異模糊的需求用戶需求增加開發(fā)方需求人員重視程度不夠開發(fā)人員理解偏差為什么會(huì)有需求變更？與用戶交互不夠，對(duì)問題理解有差異68有效控制變更合理的方法需求階段盡可能采用原型或用例法明確用戶需求。采用嚴(yán)格的需求管理變更流程。采用良好的體系結(jié)構(gòu)采用面向?qū)ο笏枷胗行Э刂谱兏侠淼姆椒ㄐ枨箅A段盡可能采用原型或用例法明確用戶69變更申請(qǐng)忽略選擇變更方式SCCB評(píng)估項(xiàng)目經(jīng)理自行決定根據(jù)評(píng)估結(jié)果拒絕接受本次修改下個(gè)版本再修改修改合同相關(guān)信息修改相關(guān)需求修改相應(yīng)的項(xiàng)目計(jì)劃變更申請(qǐng)忽略選擇變更方式SCCB評(píng)估項(xiàng)目經(jīng)理自行決定根據(jù)評(píng)估70需求變更處理軟件基線產(chǎn)品修改提交單申請(qǐng)人韓萬江申請(qǐng)日期2002。10．11項(xiàng)目名稱項(xiàng)目管理系統(tǒng)階段名稱系統(tǒng)設(shè)計(jì)文件名稱RCR-PM-01.doc,RCR-PM-02.doc,變更簡述如下修改內(nèi)容1）修改測試流程控制：將2個(gè)角色，3個(gè)渠道流，改為3個(gè)角色，4個(gè)渠道流，詳見RCR-PM-01.doc2）增加開發(fā)人員技能信息庫管理，詳見RCR-PM-02.doc

驗(yàn)證意見同意RCR-PM-01.doc變更。RCR-PM-02.doc的變更可以推遲到下一個(gè)版本實(shí)施驗(yàn)證人楊炎泰驗(yàn)證日期2002．10．11SCCB韓萬江，姜岳尊，孫泉

填表人韓萬江需求變更處理軟件基線產(chǎn)品修改提交單申請(qǐng)人韓萬江申請(qǐng)日期20071CMMI中的需求管理流程1制定需求管理計(jì)劃2求得對(duì)需求的理解3求得對(duì)需求的承諾4管理需求變更5維護(hù)對(duì)需求的雙向跟蹤性6識(shí)別項(xiàng)目工作與需求之間的不一致CMMI中的需求管理流程1制定需求管理計(jì)劃72CMMI中的需求管理流程1制定需求管理計(jì)劃確定需求管理的軟硬件資源、需求跟蹤矩陣、需求變更請(qǐng)求表。CMMI中的需求管理流程1制定需求管理計(jì)劃73CMMI中的需求管理流程2求得對(duì)需求的理解 需求確認(rèn)。避免需求蔓延和遺漏CMMI中的需求管理流程2求得對(duì)需求的理解 74CMMI中的需求管理流程3求得對(duì)需求的承諾為實(shí)現(xiàn)需求活動(dòng)所需的活動(dòng)人員之間達(dá)成一致和建立承諾。CMMI中的需求管理流程3求得對(duì)需求的承諾75CMMI中的需求管理流程4管理需求變更5維護(hù)對(duì)需求的雙向跟蹤性6識(shí)別項(xiàng)目工作與需求之間的不一致CMMI中的需求管理流程4管理需求變更76需求的屬性創(chuàng)建需求的時(shí)間需求的版本號(hào)需求創(chuàng)建的作者負(fù)責(zé)認(rèn)可需求的人員需求狀態(tài)已建議；已批準(zhǔn)；已實(shí)現(xiàn)；需求涉及到的子系統(tǒng)需求的穩(wěn)定性……需求的屬性創(chuàng)建需求的時(shí)間77本章要點(diǎn)17.1需求管理概述17.2制定需求管理計(jì)劃17.3需求管理規(guī)格說明的版本控制17.4需求變更管理17.5需求跟蹤本章要點(diǎn)17.1需求管理概述781建立并維護(hù)需求管理的組織方針對(duì)需求進(jìn)行管理，確定項(xiàng)目計(jì)劃與工作產(chǎn)品之間需求不一致之處。1建立并維護(hù)需求管理的組織方針對(duì)需求進(jìn)行管理，確定項(xiàng)目計(jì)劃792確定需求管理需使用的資源人力、財(cái)力、物力2確定需求管理需使用的資源人力、財(cái)力、物力803分配責(zé)任確定需求管理負(fù)責(zé)人及其責(zé)任確認(rèn)需求管理員的權(quán)限責(zé)任3分配責(zé)任確定需求管理負(fù)責(zé)人及其責(zé)任814培訓(xùn)計(jì)劃對(duì)需求人員的培訓(xùn)應(yīng)用領(lǐng)域、需求分析、分析、審查和管理、需求管理工具、配置管理4培訓(xùn)計(jì)劃對(duì)需求人員的培訓(xùn)825確定需求管理的項(xiàng)目干系人解決對(duì)需求的共識(shí)問題，評(píng)估需求變更的影響，通報(bào)雙向跟蹤情況，識(shí)別項(xiàng)目工作與需求不一致的情況。5確定需求管理的項(xiàng)目干系人解決對(duì)需求的共識(shí)問題，評(píng)估需求變836制定判斷項(xiàng)目工作與需求不一致的準(zhǔn)則和糾正規(guī)程依據(jù)此判斷項(xiàng)目工作與需求不一致；不一致時(shí)啟動(dòng)糾正規(guī)程。6制定判斷項(xiàng)目工作與需求不一致的準(zhǔn)則和糾正規(guī)程依據(jù)此判斷項(xiàng)847制定需求跟蹤性矩陣正向跟蹤、逆向跟蹤該矩陣保存了需求與后續(xù)工作成果的對(duì)應(yīng)關(guān)系7制定需求跟蹤性矩陣正向跟蹤、逆向跟蹤858制定需求變更審批程序?yàn)楸ＷC項(xiàng)目順利進(jìn)行和產(chǎn)品質(zhì)量，必須嚴(yán)格控制需求的變更。8制定需求變更審批程序?yàn)楸ＷC項(xiàng)目順利進(jìn)行和產(chǎn)品質(zhì)量，必須嚴(yán)869制定審批規(guī)程需求管理計(jì)劃的審批規(guī)程9制定審批規(guī)程需求管理計(jì)劃的審批規(guī)程87本章要點(diǎn)17.1需求管理概述17.2制定需求管理計(jì)劃17.3需求管理規(guī)格說明的版本控制17.4需求變更管理17.5需求跟蹤本章要點(diǎn)17.1需求管理概述88版本管理版本Checkout–Checkin版本管理版本89本章要點(diǎn)17.1需求管理概述17.2制定需求管理計(jì)劃17.3需求管理規(guī)格說明的版本控制17.4需求變更管理17.5需求跟蹤本章要點(diǎn)17.1需求管理概述90需求變更仔細(xì)評(píng)估已建議的變更挑選合適的人選對(duì)變更做出決定變更應(yīng)及時(shí)通知所有涉及的人員項(xiàng)目按一定的程序來采納需求變更需求變更仔細(xì)評(píng)估已建議的變更91控制項(xiàng)目范圍的擴(kuò)展擴(kuò)展需求是指在軟件需求基線已經(jīng)確定后又要增添新的功能或進(jìn)行較大的改動(dòng)。需求變更不可避免，但必須控制?？刂祈?xiàng)目范圍的擴(kuò)展擴(kuò)展需求是指在軟件需求基線已經(jīng)確定后又要增92變更控制過程1變更控制策略達(dá)成一個(gè)策略，如何控制需求所有需求變更必須遵循的過程；未獲批準(zhǔn)的變更，不做過多工作；CCB決定實(shí)現(xiàn)哪些變更項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者應(yīng)了解變更數(shù)據(jù)庫的內(nèi)容；不能從數(shù)據(jù)庫中刪除或修改變更請(qǐng)求的原始文檔；變更控制過程1變更控制策略93變更控制過程2變更控制步驟開始條件EntryCriteria通過合適渠道接受一個(gè)合法的變更請(qǐng)求；過程和步驟驗(yàn)證任務(wù)正確完成的步驟Verify結(jié)束條件ExitCriteria變更控制過程2變更控制步驟94信息系統(tǒng)項(xiàng)目管理師需求管理培訓(xùn)教材課件95變更控制過程3變更控制狀態(tài)報(bào)告用報(bào)告、圖表方式來總結(jié)變更控制數(shù)據(jù)庫的內(nèi)容和按狀態(tài)分類的變更請(qǐng)求數(shù)量。變更控制過程3變更控制狀態(tài)報(bào)告96變更控制過程4變更控制工具自動(dòng)工具幫助有效的執(zhí)行變更控制過程。變更控制過程4變更控制工具97InfoSys公司對(duì)需求變更的處理處理步驟：1.記錄變更2.分析變更對(duì)工作產(chǎn)品的影響3.估計(jì)變更申請(qǐng)所需的工作量4.重新估計(jì)交付時(shí)間表5.執(zhí)行累積的成本影響分析6.如果影響超出一定的限度，則與高級(jí)主管一起評(píng)審影響7.客戶不再提出變更申請(qǐng)8.修改工作產(chǎn)品InfoSys公司對(duì)需求變更的處理處理步驟：98示例申請(qǐng)?zhí)?33日期2000-01-02變更說明：本變更申請(qǐng)是使客戶機(jī)屏幕根據(jù)顯示器自動(dòng)調(diào)整分辨率。影響分析：變更分類：主要變更，因?yàn)樗绊懰衅聊弧＝鉀Q方案：布局管理器和組件的約束設(shè)置加以修改……工作量影響：總屏幕數(shù)為40……，估計(jì)實(shí)現(xiàn)總工作量為480人時(shí)進(jìn)度影響：實(shí)現(xiàn)變更對(duì)總進(jìn)度影響大概為10天狀態(tài)：得到客戶認(rèn)可，已加入到需求規(guī)格文檔中。項(xiàng)目進(jìn)度和里程碑將發(fā)生變化。經(jīng)手人評(píng)審人示例申請(qǐng)?zhí)?33日期2000-01-02變更說明：本變更申請(qǐng)99變更日志跟蹤累積變更影響變更申請(qǐng)?zhí)栕兏暾?qǐng)日期變更說明工作量影響(人日)狀態(tài)12月18日規(guī)定使用情況統(tǒng)計(jì)3已解決2演示期間強(qiáng)制用戶退出2未解決3演示期間支持用戶存檔3已解決42月18日復(fù)制窗口7已解決5演示期間刪除時(shí)列出所有節(jié)點(diǎn)5已解決6演示期間從一個(gè)特定節(jié)點(diǎn)啟動(dòng)4已解決總計(jì)24變更日志跟蹤累積變更影響變更申請(qǐng)?zhí)栕兏暾?qǐng)日期變更說明工作量100變更度量活動(dòng)接收、未作決定、結(jié)束處理的變更請(qǐng)求的數(shù)量；已實(shí)現(xiàn)的變更需求的合計(jì)數(shù)量；每個(gè)方面發(fā)出的變更請(qǐng)求數(shù)量；每個(gè)已應(yīng)用的需求建議變更和實(shí)現(xiàn)變更的數(shù)量；投入處理變更的人力、物力；變更度量活動(dòng)接收、未作決定、結(jié)束處理的變更請(qǐng)求的數(shù)量；101本章要點(diǎn)17.1需求管理概述17.2制定需求管理計(jì)劃17.3需求管理規(guī)格說明的版本控制17.4需求變更管理17.5需求跟蹤本章要點(diǎn)17.1需求管理概述102需求跟蹤編制每個(gè)需求同系統(tǒng)元素之間的聯(lián)系文檔。如需求、體系結(jié)構(gòu)、源代碼、測試用例、幫助文檔等。跟蹤能力鏈TraceabilityLink記錄了單個(gè)需求之間的父層、互連、依賴的關(guān)系；需求跟蹤編制每個(gè)需求同系統(tǒng)元素之間的聯(lián)系文檔。如需求、體系結(jié)103需求跟蹤的內(nèi)容跟蹤需求使用期限的全過程。從需求源到實(shí)現(xiàn)的前后生存期。需求跟蹤的內(nèi)容跟蹤需求使用期限的全過程。從需求源到實(shí)現(xiàn)的前后104需求跟蹤的目的提供一個(gè)表明與合同或說明一致的方法。可以改善產(chǎn)品質(zhì)量，降低維護(hù)成本，容易實(shí)現(xiàn)重用。需求跟蹤的目的提供一個(gè)表明與合同或說明一致的方法?？梢愿纳飘a(chǎn)105需求跟蹤能力矩陣表示需求和別的系統(tǒng)之間的聯(lián)系。一對(duì)一、一對(duì)多、多對(duì)多需求跟蹤能力矩陣表示需求和別的系統(tǒng)之間的聯(lián)系。106需求建模常用方法原型分析法結(jié)構(gòu)化分析法用例分析法功能列表方法其他方法根據(jù)需要選擇最適合項(xiàng)目的方法！需求建模常用方法原型分析法107需求變更的代價(jià)：影響分析“變更是免費(fèi)的”影響分析可以提供對(duì)建議變更的準(zhǔn)確理解，有助于做出信息量充分的變更批準(zhǔn)決策。需求變更的代價(jià)：影響分析“變更是免費(fèi)的”108信息系統(tǒng)項(xiàng)目管理師

需求管理閆波信息系統(tǒng)項(xiàng)目管理師

需求管理閆波109需求管理用戶需求是軟件項(xiàng)目成敗的關(guān)鍵需求問題：需求的隱含錯(cuò)誤需求不明確、含糊用戶刁難、用戶不斷增加需求需求變更需求管理用戶需求是軟件項(xiàng)目成敗的關(guān)鍵110本章要點(diǎn)17.1需求管理概述17.2制定需求管理計(jì)劃17.3需求管理規(guī)格說明的版本控制17.4需求變更管理17.5需求跟蹤本章要點(diǎn)17.1需求管理概述111需求管理需求：指的是由項(xiàng)目接受的或項(xiàng)目產(chǎn)生的產(chǎn)品和產(chǎn)品構(gòu)件需求。包括由組織征集的對(duì)項(xiàng)目的需求。RequirementManagement需求管理確保各方對(duì)需求的一致理解，管理和控制需求的變更，從需求到最終產(chǎn)品的雙向跟蹤。需求管理需求：指的是由項(xiàng)目接受的或項(xiàng)目產(chǎn)生的產(chǎn)品和產(chǎn)品構(gòu)件需112軟件需求定義需求是指用戶對(duì)軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達(dá)到什么性能。軟件需求定義需求是指用戶對(duì)軟件的功能和性能的要求，就是用戶希113軟件需求特征：模糊性不確定性變化性主觀性軟件需求特征：114軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格非功能性需求質(zhì)量特性約束和假設(shè)系統(tǒng)需求軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格非功能性需115軟件需求的類型功能需求性能需求環(huán)境需求用戶界面需求資源使用需求成本消耗需求開發(fā)進(jìn)度需求預(yù)先估計(jì)以后系統(tǒng)可能達(dá)到的目標(biāo)軟件需求的類型功能需求116軟件需求的重要性軟件需求的重要性117需求管理與項(xiàng)目管理的關(guān)系項(xiàng)目需求是制定項(xiàng)目計(jì)劃，開發(fā)項(xiàng)目產(chǎn)品和從事項(xiàng)目活動(dòng)的依據(jù)。項(xiàng)目的計(jì)劃、項(xiàng)目的開發(fā)活動(dòng)及開發(fā)的產(chǎn)品應(yīng)與項(xiàng)目需求保持一致，隨需求的變化而調(diào)整。需求管理與項(xiàng)目管理的關(guān)系項(xiàng)目需求是制定項(xiàng)目計(jì)劃，開發(fā)項(xiàng)目產(chǎn)品118需求工程（RE）需求工程是指應(yīng)用已證實(shí)有效的技術(shù)、方法進(jìn)行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標(biāo)系統(tǒng)的所有外部特征一門學(xué)科。需求開發(fā)需求管理需求工程（RE）需求工程是指應(yīng)用已證實(shí)有效的技術(shù)、方法進(jìn)行需119軟件需求工程管理的過程需求分析需求定義需求驗(yàn)證需求獲取需求管理需求開發(fā)需求管理軟件需求工程管理的過程需求分析需求定義需求驗(yàn)證需求獲取需求管120需求獲取需求獲取121

擴(kuò)展需求需求獲取用戶要求基線需求軟件需求通過與用戶的交流，對(duì)現(xiàn)有系統(tǒng)的觀察及對(duì)任務(wù)進(jìn)行分析，從而開發(fā)、捕獲和修訂用戶的需求。需求獲取用戶要求軟件需求通過與用戶的交流，對(duì)現(xiàn)有系統(tǒng)的觀察及122獲取需求的活動(dòng)了解用戶類型及潛在類型訪談和調(diào)研（要有記錄）對(duì)用戶需求進(jìn)一步整理和提取將用戶需求反饋用戶獲取需求的活動(dòng)了解用戶類型及潛在類型123注意事項(xiàng)識(shí)別真正的客戶.正確理解客戶的需求具備較強(qiáng)的忍耐力和清晰的思維說服和教育客戶注意事項(xiàng)識(shí)別真正的客戶.124需求分析定義：需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型，是對(duì)需求的抽象描述。

需求分析也稱為需求建模需求分析定義：需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模125需求分析模型需求分析模型126需求分析的時(shí)間設(shè)計(jì)方案的時(shí)候項(xiàng)目開始的時(shí)候接管一個(gè)項(xiàng)目的時(shí)候需求變更的時(shí)候需求分析的時(shí)間設(shè)計(jì)方案的時(shí)候127需求分析基本策略頭腦風(fēng)暴專家評(píng)審焦點(diǎn)會(huì)議組目的：進(jìn)行具體的流程細(xì)化、數(shù)據(jù)項(xiàng)確認(rèn)，必要時(shí)可以提供原型系統(tǒng)和明確的業(yè)務(wù)流程報(bào)告、數(shù)據(jù)項(xiàng)表，并能清晰的向用戶描述系統(tǒng)的業(yè)務(wù)流設(shè)計(jì)目標(biāo)。需求分析基本策略頭腦風(fēng)暴128需求分析的難點(diǎn)問題的復(fù)雜性（不了解業(yè)務(wù)）交流的障礙不完備性和不一致性需求的易變性需求分析的難點(diǎn)問題的復(fù)雜性（不了解業(yè)務(wù)）129需求定義需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)范的需求規(guī)格說明書（SRS）需求規(guī)格說明書的編制是為了使用戶和軟件開發(fā)者雙方對(duì)該軟件的初始規(guī)定有一個(gè)共同的理解，使之成為整個(gè)開發(fā)工作的基礎(chǔ)。需求定義需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)130軟件需求規(guī)格說明的原則從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”要求使用面向處理的規(guī)格說明語言（或稱系統(tǒng)定義語言）如果被開發(fā)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說明的描述之中規(guī)格說明必須包括系統(tǒng)運(yùn)行環(huán)境規(guī)格說明必須是一個(gè)認(rèn)識(shí)模型規(guī)格說明必須是可操作的規(guī)格說明必須容許不完備性并允許擴(kuò)充軟件需求規(guī)格說明的原則從現(xiàn)實(shí)中分離功能，即描述要“做什么”而131需求規(guī)格說明書文檔參考引言系統(tǒng)定義應(yīng)用環(huán)境功能規(guī)格性能需求產(chǎn)品提交實(shí)現(xiàn)約束質(zhì)量描述其它簽字認(rèn)證需求規(guī)格說明書文檔參考引言132需求驗(yàn)證開發(fā)方和用戶方共同對(duì)需求文檔進(jìn)行評(píng)審，經(jīng)雙方對(duì)需求達(dá)成共識(shí)后做出書面承諾，使需求文檔具有商業(yè)合同效果。需求驗(yàn)證開發(fā)方和用戶方共同對(duì)需求文檔進(jìn)行評(píng)審，經(jīng)雙方對(duì)需求達(dá)133需求驗(yàn)證需求是正確的嗎？需求是一致的嗎？需求是完全的嗎？需求是實(shí)際可行的嗎？需求是客戶需要的嗎？需求是可檢驗(yàn)的嗎？需求是可跟蹤的嗎？最后的簽字需求驗(yàn)證需求是正確的嗎？134需求驗(yàn)證快速原型法需求驗(yàn)證快速原型法135需求管理需求管理中要收集需求的變更和變更的理由，維持對(duì)原有需求和所有產(chǎn)品及產(chǎn)品構(gòu)件需求的雙向跟蹤。需求管理需求管理中要收集需求的變更和變更的理由，維持對(duì)原有需136需求變更項(xiàng)目失敗主要的原因在于需求變更!需求變更項(xiàng)目失敗主要的原因在于需求變更!137信息系統(tǒng)項(xiàng)目管理師需求管理培訓(xùn)教材課件138需求建模的方法創(chuàng)建體系結(jié)構(gòu)的表示形式以捕獲需求、就解決方案方法進(jìn)行交流、以及分析所提出的系統(tǒng)設(shè)計(jì)。其目的是使用模型來表現(xiàn)系統(tǒng)中的關(guān)鍵方面。需求建模的方法創(chuàng)建體系結(jié)構(gòu)的表示形式以捕獲需求、就解決方案方139原型分析法定義：按照用戶的需要，快速形成一個(gè)操作流程界面可能只是一個(gè)框架，具體的功能沒有實(shí)現(xiàn)，只是結(jié)果靜態(tài)的操作流程，以便與用戶快速就需求達(dá)成一致主要考慮系統(tǒng)的功能需求，很少考慮非功能需求原型分析法定義：140原型方法需求分析原型開發(fā)原型評(píng)價(jià)原型方法需求分析原型開發(fā)原型評(píng)價(jià)141原型方法的類型進(jìn)化型開發(fā)出來用于了解問題，并形成被交付軟件的部分或全部的基礎(chǔ)拋棄型開發(fā)出來獲以便更多地了解問題或探究可能的方案的靈活性或者合理性，是嘗試性軟件，不用于被交付軟件的實(shí)際部分原型方法的類型進(jìn)化型142結(jié)構(gòu)化分析法定義（SA,StructuredAnalysis）20世紀(jì)70年發(fā)展起來的面向數(shù)據(jù)流的方法是一種自頂向下逐步求精的分析方法根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系進(jìn)行分析的結(jié)構(gòu)化分析法定義（SA,StructuredAnalysi143結(jié)構(gòu)化分析方法－技術(shù)數(shù)據(jù)流圖(DFD)數(shù)據(jù)字典(DD)系統(tǒng)流程圖結(jié)構(gòu)化分析方法－技術(shù)數(shù)據(jù)流圖(DFD)144數(shù)據(jù)流圖是一種描述軟件系統(tǒng)邏輯模型的圖形符號(hào)表示數(shù)據(jù)的起始點(diǎn)和終點(diǎn)表示對(duì)數(shù)據(jù)的加工處理表示數(shù)據(jù)流,箭頭表示數(shù)據(jù)的流動(dòng)方向表示對(duì)數(shù)據(jù)的存儲(chǔ)數(shù)據(jù)流圖是一種描述軟件系統(tǒng)邏輯模型的圖形符號(hào)表示數(shù)據(jù)的起始點(diǎn)145銀行取款過程數(shù)據(jù)流圖銀行取款過程數(shù)據(jù)流圖146數(shù)據(jù)流圖的層次結(jié)構(gòu)為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采用層次結(jié)構(gòu)的數(shù)據(jù)流圖。按照系統(tǒng)的層次結(jié)構(gòu)進(jìn)行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關(guān)系，能清楚地表達(dá)和容易理解整個(gè)系統(tǒng)數(shù)據(jù)流圖的層次結(jié)構(gòu)為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采147分層數(shù)據(jù)流圖分層數(shù)據(jù)流圖148分層數(shù)據(jù)流圖頂層流圖僅包含一個(gè)加工，它代表被開發(fā)系統(tǒng)。它的輸入流是該系統(tǒng)的輸入數(shù)據(jù)，輸出流是系統(tǒng)所輸出數(shù)據(jù)底層流圖是指其加工不需再做分解的數(shù)據(jù)流圖，它處在最底層中間層流圖則表示對(duì)其上層父圖的細(xì)化。它的每一加工可能繼續(xù)細(xì)化，形成子圖。分層數(shù)據(jù)流圖頂層流圖僅包含一個(gè)加工，它代表被開發(fā)系統(tǒng)。它的輸149數(shù)據(jù)字典描述系統(tǒng)中涉及的每個(gè)數(shù)據(jù),是數(shù)據(jù)描述的集合,通常配合數(shù)據(jù)流圖使用,用來描述數(shù)據(jù)流圖中出現(xiàn)的各種數(shù)據(jù)和加工.組成：數(shù)據(jù)項(xiàng):數(shù)據(jù)元素?cái)?shù)據(jù)流:由數(shù)據(jù)項(xiàng)組成的數(shù)據(jù)流數(shù)據(jù)文件:表示對(duì)數(shù)據(jù)文件的存儲(chǔ)數(shù)據(jù)字典描述系統(tǒng)中涉及的每個(gè)數(shù)據(jù),是數(shù)據(jù)描述的集合,通常配合150數(shù)據(jù)字典關(guān)系符號(hào)符號(hào)含義=等于,定義為+加[]選擇符,表示對(duì)[]列舉的值可以任取其一{}重復(fù)符,表示對(duì){}中的內(nèi)容可視需要重復(fù)使用()可選符,表示對(duì)()中的內(nèi)容可由設(shè)計(jì)員決定取舍*……*注釋符,表示兩個(gè)*之間的內(nèi)容為對(duì)條目的注釋數(shù)據(jù)字典關(guān)系符號(hào)符號(hào)含義=等于,定義為+加[]選擇符,表151數(shù)據(jù)流圖需求分析實(shí)例建立學(xué)生管理系統(tǒng)學(xué)管科體檢科學(xué)籍科學(xué)生處數(shù)據(jù)流圖需求分析實(shí)例建立學(xué)生管理系統(tǒng)152頂層數(shù)據(jù)流圖學(xué)管科體檢科學(xué)籍科學(xué)生管理信息系統(tǒng)學(xué)生處領(lǐng)導(dǎo)學(xué)生基本信息學(xué)生健康信息學(xué)生成績學(xué)生健康情況表學(xué)生成績單查詢要求不及格人數(shù)人數(shù)統(tǒng)計(jì)表頂層數(shù)據(jù)流圖學(xué)管科體檢科學(xué)籍科學(xué)生管理學(xué)生處領(lǐng)導(dǎo)學(xué)生基本信息153第0層數(shù)據(jù)流圖第0層數(shù)據(jù)流圖154第1層數(shù)據(jù)流圖第1層數(shù)據(jù)流圖155系統(tǒng)流程圖系統(tǒng)包含的部分以及各個(gè)部分之間的關(guān)系是描述物理系統(tǒng)的工具用圖形符號(hào)表示系統(tǒng)中的元素表達(dá)了系統(tǒng)中各個(gè)元素之間的信息流動(dòng)情況系統(tǒng)流程圖系統(tǒng)包含的部分以及各個(gè)部分之間的關(guān)系156系統(tǒng)流程圖符號(hào)系統(tǒng)流程圖符號(hào)157信息系統(tǒng)項(xiàng)目管理師需求管理培訓(xùn)教材課件158用例分析法面向?qū)ο蟮能浖こ蹋∣OSE）OOAOODOOP(objectorientedprogramming

)OOT…….用例分析法面向?qū)ο蟮能浖こ蹋∣OSE）159用例（UserCase）表示一個(gè)動(dòng)作序列的定義，包括執(zhí)行的變量和外界交互的過程。提款機(jī)取款用例用例（UserCase）表示一個(gè)動(dòng)作序列的定義，包括執(zhí)行的160OOA是OO軟件工程的第一項(xiàng)技術(shù)活動(dòng)將現(xiàn)實(shí)世界的“視圖”轉(zhuǎn)化為用對(duì)象來描述的模型描述對(duì)象之間的各種關(guān)系，以滿足軟件系統(tǒng)的要求。OOA是OO軟件工程的第一項(xiàng)技術(shù)活動(dòng)161用例需求分析用例需求分析方法采用一種面向?qū)ο蟮那榫胺治龇椒ㄓ美窍到y(tǒng)向用戶提供一個(gè)有價(jià)值的結(jié)果的某項(xiàng)功能所有的用例結(jié)合起來就構(gòu)成了用例模型從用戶角度出發(fā)考慮的功能需求用例需求分析用例需求分析方法采用一種面向?qū)ο蟮那榫胺治龇椒?62用例需求分析從前：問用戶希望系統(tǒng)為他做什么？現(xiàn)在：問用戶利用系統(tǒng)做什么？用例需求分析從前：問用戶希望系統(tǒng)為他做什么？163UMLUnifiedModelingLanguage統(tǒng)一建模語言，是一種通用的模擬語言。Booch,Rumbaugh和Jocobson基礎(chǔ)上發(fā)展起來的。1997年11月國際對(duì)象管理組織OMG批準(zhǔn)將UML作為基于面向?qū)ο蠹夹g(shù)的標(biāo)準(zhǔn)建模語言。UML制定了一整套完整的面向?qū)ο蟮臉?biāo)記和處理方法。UMLUnifiedModelingLanguage統(tǒng)一164UML需求視圖用例視圖（UsecaseDiagram）順序圖（SequenceDiagram）狀態(tài)圖（StateDiagram）活動(dòng)圖（ActivityDiagram）UML需求視圖用例視圖（UsecaseDiagram）165USECASE視圖用例視圖主要是展示了外部行為者所觀察到的系統(tǒng)將提交的功能.即:各類外部行為者與系統(tǒng)所提供的用例的連接－－－－用例（Usecase）：系統(tǒng)所提供的功能描述角色（Actor）：可能使用用例的人或者外部系統(tǒng)USECASE視圖用例視圖主要是展示了外部行為者所觀察到的166UML圖符UML圖符167USERCASE實(shí)例USERCASE實(shí)例168序列（Sequence）圖順序圖展示了幾個(gè)對(duì)象之間的動(dòng)態(tài)協(xié)作關(guān)系，主要用來顯示對(duì)象之間發(fā)送消息的順序，還顯示對(duì)象之間的交互，即系統(tǒng)執(zhí)行某一特定時(shí)間點(diǎn)所發(fā)生的事。序列（Sequence）圖順序圖展示了幾個(gè)對(duì)象之間的動(dòng)態(tài)協(xié)作169Sequence實(shí)例Sequence實(shí)例170狀態(tài)視圖狀態(tài)圖是對(duì)類描述的補(bǔ)充，它說明該類的對(duì)象所有可能的狀態(tài)以及那些事件將導(dǎo)致狀態(tài)的改變。它是一個(gè)類對(duì)象所可能經(jīng)歷的所有歷程的模型圖。狀態(tài)視圖狀態(tài)圖是對(duì)類描述的補(bǔ)充，它說明該類的對(duì)象所有可能的狀171活動(dòng)（Activity）視圖活動(dòng)圖用來描述執(zhí)行工作流程中涉及的活動(dòng)，展示了連續(xù)的活動(dòng)流活動(dòng)（Activity）視圖活動(dòng)圖用來描述執(zhí)行工作流程中涉及172活動(dòng)圖例活動(dòng)圖例173UseCase需求分析方法綜述識(shí)別出系統(tǒng)的Actor描述主要的Usecase實(shí)現(xiàn)用例視圖實(shí)現(xiàn)順序視圖，活動(dòng)視圖,狀態(tài)視圖等UseCase需求分析方法綜述識(shí)別出系統(tǒng)的Actor174功能列表法對(duì)項(xiàng)目的功能需求進(jìn)行詳細(xì)說明，既可以單獨(dú)使用，也可以作為用例分析方法的附加說明來詳細(xì)說明用例的具體功能。功能列表法對(duì)項(xiàng)目的功能需求進(jìn)行詳細(xì)說明，既可以單獨(dú)使用，也可175為什么會(huì)有需求變更？與用戶交互不夠，對(duì)問題理解有差異模糊的需求用戶需求增加開發(fā)方需求人員重視程度不夠開發(fā)人員理解偏差為什么會(huì)有需求變更？與用戶交互不夠，對(duì)問題理解有差異176有效控制變更合理的方法需求階段盡可能采用原型或用例法明確用戶需求。采用嚴(yán)格的需求管理變更流程。采用良好的體系結(jié)構(gòu)采用面向?qū)ο笏枷胗行Э刂谱兏侠淼姆椒ㄐ枨箅A段盡可能采用原型或用例法明確用戶177變更申請(qǐng)忽略選擇變更方式SCCB評(píng)估項(xiàng)目經(jīng)理自行決定根據(jù)評(píng)估結(jié)果拒絕接受本次修改下個(gè)版本再修改修改合同相關(guān)信息修改相關(guān)需求修改相應(yīng)的項(xiàng)目計(jì)劃變更申請(qǐng)忽略選擇變更方式SCCB評(píng)估項(xiàng)目經(jīng)理自行決定根據(jù)評(píng)估178需求變更處理軟件基線產(chǎn)品修改提交單申請(qǐng)人韓萬江申請(qǐng)日期2002。10．11項(xiàng)目名稱項(xiàng)目管理系統(tǒng)階段名稱系統(tǒng)設(shè)計(jì)文件名稱RCR-PM-01.doc,RCR-PM-02.doc,變更簡述如下修改內(nèi)容1）修改測試流程控制：將2個(gè)角色，3個(gè)渠道流，改為3個(gè)角色，4個(gè)渠道流，詳見RCR-PM-01.doc2）增加開發(fā)人員技能信息庫管理，詳見RCR-PM-02.doc

驗(yàn)證意見同意RCR-PM-01.doc變更。RCR-PM-02.doc的變更可以推遲到下一個(gè)版本實(shí)施驗(yàn)證人楊炎泰驗(yàn)證日期2002．10．11SCCB韓萬江，姜岳尊，孫泉

填表人韓萬江需求變更處理軟件基線產(chǎn)品修改提交單申請(qǐng)人韓萬江申請(qǐng)日期200179CMMI中的需求管理流程1制定需求管理計(jì)劃2求得對(duì)需求的理解3求得對(duì)需求的承諾4管理需求變更5維護(hù)對(duì)需求的雙向跟蹤性6識(shí)別項(xiàng)目工作與需求之間的不一致CMMI中的需求管理流程1制定需求管理計(jì)劃180CMMI中的需求管理流程1制定需求管理計(jì)劃確定需求管理的軟硬件資源、需求跟蹤矩陣、需求變更請(qǐng)求表。CMMI中的需求管理流程1制定需求管理計(jì)劃181CMMI中的需求管理流程2求得對(duì)需求的理解 需求確認(rèn)。避免需求蔓延和遺漏CMMI中的需求管理流程2求得對(duì)需求的理解 182CMMI中的需求管理流程3求得對(duì)需求的承諾為實(shí)現(xiàn)需求活動(dòng)所需的活動(dòng)人員之間達(dá)成一致和建立承諾。CMMI中的需求管理流程3求得對(duì)需求的承諾183CMMI中的需求管理流程4管理需求變更5維護(hù)對(duì)需求的雙向跟蹤性6識(shí)別項(xiàng)目工作與需求之間的不一致CMMI中的需求管理流程4管理需求變更184需求的屬性創(chuàng)建需求的時(shí)間需求的版本號(hào)需求創(chuàng)建的作者負(fù)責(zé)認(rèn)可需求的人員需求狀態(tài)已建議；已批準(zhǔn)；已實(shí)現(xiàn)；需求涉及到的子系統(tǒng)需求的穩(wěn)定性……需求的屬性創(chuàng)建需求的時(shí)間185本章要點(diǎn)17.1需求管理概述17.2制定需求管理計(jì)劃17.3需求管理規(guī)格說明的版本控制17.4需求變更管理17.5需求跟蹤本章要點(diǎn)17.1需求管理概述1861建立并維護(hù)需求管理的組織方針對(duì)需求進(jìn)行管理，確定項(xiàng)目計(jì)劃與工作產(chǎn)品之間需求不一致之處。1建立并維護(hù)需求管理的組織方針對(duì)需求進(jìn)行管理，確定項(xiàng)目計(jì)劃1872確定需求管理需使用的資源人力、財(cái)力、物力2確定需求管理需使用的資源人力、財(cái)力、物力1883分配責(zé)任確定需求管理負(fù)責(zé)人及其責(zé)任確認(rèn)需求管理員的權(quán)限責(zé)任3分配責(zé)任確定需求管理負(fù)責(zé)人及其責(zé)任1894培訓(xùn)計(jì)劃對(duì)需求人員的培訓(xùn)應(yīng)用領(lǐng)域、需求分析、分析、審查和管理、需求管理工具、配置管理4培訓(xùn)計(jì)劃對(duì)需求人員的培訓(xùn)1905確定需求管理的項(xiàng)目干系人解決對(duì)需求的共識(shí)問題，評(píng)估需求變更的影響，通報(bào)雙向跟蹤情況，識(shí)別項(xiàng)目工作與需求不一致的情況。5確定需求管理的項(xiàng)目干系人解決對(duì)需求的共識(shí)問題，評(píng)估需求變1916制定判斷項(xiàng)目工作與需求不一致的準(zhǔn)則和糾正規(guī)程依據(jù)此判斷項(xiàng)目工作與需求不一致；不一致時(shí)啟動(dòng)糾正規(guī)程。6制定判斷項(xiàng)目工作與需求不一致的準(zhǔn)則和糾正規(guī)程依據(jù)此判斷項(xiàng)1927制定需求跟蹤性矩陣正向跟蹤、逆向跟蹤該矩陣保存了需求與后續(xù)工作成果的對(duì)應(yīng)關(guān)系7制定需求跟蹤性矩陣正向跟蹤、逆向跟蹤1938制定需求變更審批程序?yàn)楸ＷC項(xiàng)目順利進(jìn)行和產(chǎn)品質(zhì)量，必須嚴(yán)格控制需求的變更。8制定需求變更審批程序?yàn)楸ＷC項(xiàng)目順利進(jìn)行和產(chǎn)品質(zhì)量，必須嚴(yán)1949制定審批規(guī)程需求管理計(jì)劃的審批規(guī)程9制定審批規(guī)程需求管理計(jì)劃的審批規(guī)程195本章要點(diǎn)17.1需求管理概述17.2制定需求管理計(jì)劃17.3需求管理規(guī)格說明的版本控制17.4需求變更管理17.5需求跟蹤本章要點(diǎn)17.1需求管理概述196版本管理版本Checkout–Checkin版本管理版本197本章要點(diǎn)17.1需求管理概述17.2制定需求管理計(jì)劃17.3需求管理規(guī)格說明的版本控制17.4需求變更管理17.5需求跟蹤本章要點(diǎn)17.1需求管理概述198需求變更仔細(xì)評(píng)估已建議的變更挑選合適的人選對(duì)變更做出