需求管理流程設(shè)計(jì)研討課件

需求管理流程研討目的瞭解需求管理流程的基本概念、實(shí)際案例；討論並確定需求管理流程的主要活動(dòng)及其之間的關(guān)聯(lián)；確定需求管理流程的典型角色及其與主要活動(dòng)之間的匹配情況；討論並確認(rèn)需求管理流程執(zhí)行策略並收集相關(guān)建議。Copyright@2004-2014上海翰緯1第一頁，共四十三頁。主要關(guān)注點(diǎn)需要確定的關(guān)注點(diǎn)：支保部的定位？需求管理流程的管理對象和範(fàn)圍？需求管理的生命週期長度？開發(fā)前還是上線投產(chǎn)？流程的角色設(shè)置和職責(zé)流程各角色的工作界面和溝通接口

目標(biāo)：需求管理恰如裁縫的量體裁衣，它直接關(guān)係到最終產(chǎn)品的成型。僅從字面出發(fā)，如果一個(gè)產(chǎn)品滿足了客戶需求，那它無疑就是成功的。需求管理的過程，從需求分析開始貫穿整個(gè)項(xiàng)目始終，力圖實(shí)現(xiàn)最終產(chǎn)品同需求性的最佳結(jié)合。需求管理能夠確證：我們確知客戶的需求是什麼（質(zhì)量）；滿足客戶需求的最佳解決辦法（統(tǒng)一性）；Copyright@2004-2014上海翰緯2第二頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯3概念準(zhǔn)備實(shí)際案例XX銀行需求管理流程現(xiàn)狀流程活動(dòng)和流程角色設(shè)計(jì)管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第三頁，共四十三頁。需求管理-基礎(chǔ)目的：確保服務(wù)資源的生產(chǎn)能力和需求預(yù)測及模式保持一致；確保資源能力可以在需要時(shí)有效使用，在不使用時(shí)及時(shí)釋放關(guān)鍵字：業(yè)務(wù)分析服務(wù)組合資源容量如何滿足“適”：前提條件：已受理需求申請考慮要素：需求分析、需求評(píng)審、需求驗(yàn)證、需求確認(rèn)過程目的減小需求的不確定性提供充分需求估計(jì)和規(guī)劃，保證產(chǎn)品和需求的一致性減少因過度冗餘而導(dǎo)致閒置容量的額外成本無法得到有效的回收鞏固與提升客戶與使用者滿意度便於需求支持資源的合理配備與使用過程價(jià)值定義是指理解並影響客戶對服務(wù)的需求以及提供相應(yīng)容量以滿足這些需求的活動(dòng)；術(shù)語信息技術(shù)服務(wù)需求：指業(yè)務(wù)部門以及最終用戶對信息技術(shù)服務(wù)的需求。新增服務(wù)：按照業(yè)務(wù)部門或公司統(tǒng)一規(guī)劃（或備案）確定的、滿足用戶和業(yè)務(wù)需求的新增信息技術(shù)服務(wù)，這些服務(wù)未列入已發(fā)佈的服務(wù)目錄。服務(wù)功能的變更：該服務(wù)已經(jīng)上線運(yùn)行，並且已列入部已發(fā)佈的服務(wù)目錄，現(xiàn)階段主要以功能完善、修復(fù)Bug為主，通過立項(xiàng)續(xù)建來實(shí)現(xiàn)大版本升級(jí)。說明觸發(fā)條件：業(yè)務(wù)需求；過程模式：主動(dòng)式的管理過程；過程特點(diǎn)：適，統(tǒng)一，一致過程概述Copyright@2004-2014上海翰緯4適第四頁，共四十三頁。需求管理流程的主要活動(dòng)概述（一）需求開發(fā)需求調(diào)研：問卷訪談場景模擬需求建模和分析，可利用以下工具進(jìn)行：UMLRationalRose(RationalSoftwareArchitect)PowerDesignerVISIO輸出需求定義（需求規(guī)格說明書）或需求定義說明書需求定義的確認(rèn)：確認(rèn)有兩層含義：首先是需求調(diào)查與分析人員與客戶間通過溝通，剔除或修訂對需求理解不一致的部分；另外一個(gè)層面的意思是指，雙方對於已達(dá)成共同理解或獲得客戶/用戶認(rèn)可的部分進(jìn)行承諾。Copyright@2004-2014上海翰緯5第五頁，共四十三頁。需求管理流程的主要活動(dòng)概述（二）建立並識(shí)別需求狀態(tài)和跟蹤機(jī)制需求狀態(tài)是指用戶需求的一種狀態(tài)變換過程進(jìn)行需求調(diào)研時(shí)，客戶對需求的描述可能有多種：客戶可以明確且清楚的提出的需求；客戶知道需要做些什麼，但又不能確定的需求；客戶本身可以得出這類需求，但需求的業(yè)務(wù)不明確，還需要等待外部信息客戶本身也說不清楚對於這些需求，在需求開發(fā)的過程中，存在著以下幾種情況:有可能要取消的因?yàn)椴幻鞔_而可以後延的，同時(shí)可能轉(zhuǎn)化為被取消的需求與客戶經(jīng)過溝通或確認(rèn)的，此處有兩種情況，一類是確認(rèn)雙方達(dá)成共識(shí)，另一種情況是還需要再進(jìn)一步溝通的。建立狀態(tài)追蹤機(jī)制：如狀態(tài)追蹤矩陣狀態(tài)示例：待確認(rèn)：客戶提出需求，但雙方?jīng)]有經(jīng)過溝通或確認(rèn)；已確認(rèn)：經(jīng)過確認(rèn)，雙方認(rèn)可並達(dá)成共識(shí)；未能確認(rèn):雙方經(jīng)過確認(rèn)，但沒有達(dá)成共識(shí)的需求；Copyright@2004-2014上海翰緯6第六頁，共四十三頁。需求管理流程的主要活動(dòng)概述（三）技術(shù)解決方案設(shè)計(jì)技術(shù)需求分析和建模根據(jù)業(yè)務(wù)需求規(guī)格說明書或業(yè)務(wù)需求定義說明書和建模分析結(jié)果編制技術(shù)需求規(guī)格說明書評(píng)審確認(rèn)技術(shù)需求開發(fā)技術(shù)解決方案：定義產(chǎn)品或服務(wù)組件以滿足需求定義組件的關(guān)係和接口明確組件的開發(fā)或獲取方式：內(nèi)部完成還是採購有條件時(shí)，可能有多套方案供評(píng)審決策需求評(píng)審和確認(rèn)預(yù)審核：在進(jìn)行正式評(píng)審前，需要有人員對其要進(jìn)行評(píng)審的對象進(jìn)行把關(guān)，確認(rèn)其是否具備進(jìn)入評(píng)審的初步條件。正式評(píng)審中評(píng)判需求優(yōu)劣的主要指標(biāo)有：正確性、清晰性、無二義性、一致性、必要性、完整性、可實(shí)現(xiàn)性、可驗(yàn)證性、可測性。如果有可能，應(yīng)制定預(yù)審核的送審材料清單和正式審核的檢查項(xiàng)清單。Copyright@2004-2014上海翰緯7第七頁，共四十三頁。需求管理流程的主要活動(dòng)概述（四）產(chǎn)品開發(fā)與集成不在需求管理中討論需求跟蹤進(jìn)行需求跟蹤的目的是為了建立和維護(hù)從用戶需求開始到測試之間的一致性與完整性。確保所有的實(shí)現(xiàn)是以用戶需求為基礎(chǔ)。對於需求實(shí)現(xiàn)是否全部的覆蓋。同時(shí)確保所有的輸出與用戶需求的符合性。正向跟蹤：以用戶需求為切入點(diǎn)，檢查《用戶需求說明書》或《需求規(guī)格說明書》中的每個(gè)需求是否都能在後繼工作產(chǎn)品中找到對應(yīng)點(diǎn)。逆向跟蹤：檢查設(shè)計(jì)文檔、代碼、測試用例等工作產(chǎn)品是否都能在《需求規(guī)格說明書》中找到出處。Copyright@2004-2014上海翰緯8第八頁，共四十三頁。需求管理流程的主要活動(dòng)概述（五）需求變更控制需求變更通常會(huì)對產(chǎn)品開發(fā)和集成的進(jìn)度、投入人力資源產(chǎn)生很大的影響，這是必須面臨與需要處理的問題。需求發(fā)生變更的起因主要有：隨著項(xiàng)目生命週期的不斷往前推進(jìn)，人們（包括開發(fā)方和客戶方）對需求的瞭解越來越深入，發(fā)現(xiàn)原先的提出的需求可能存在著一定的缺陷，因此要變更需求。市場業(yè)務(wù)需求發(fā)生了變化，原先的需求可能跟不上當(dāng)前的市場業(yè)務(wù)發(fā)展，因此要變更需求。需求的變更則意味著要需要重新進(jìn)行估計(jì)，調(diào)整資源、重新分配任務(wù)、修改前期工作產(chǎn)品等，而作為開發(fā)者，需要增加預(yù)算與投資，開發(fā)組要為此付出較重的代價(jià)。需求變更控制的動(dòng)機(jī)是：如果需求變更帶來的好處大於壞處，那麼允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。如果需求變更帶來的壞處大於好處，那麼拒絕變更。由於需求文檔是重要的配置項(xiàng)，需求的變更應(yīng)當(dāng)遵循相關(guān)的變更管理程序。Copyright@2004-2014上海翰緯9第九頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯10概念準(zhǔn)備實(shí)際案例XX銀行需求管理流程現(xiàn)狀流程活動(dòng)和流程角色設(shè)計(jì)管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第十頁，共四十三頁。案例1：某電力局信息系統(tǒng)需求管理流程部門業(yè)務(wù)參與者職責(zé)說明備注最高管理層局領(lǐng)導(dǎo)系統(tǒng)使用者，可以使用系統(tǒng)、對信息系統(tǒng)提出需求、

等待需求處理完畢、評(píng)價(jià)需求處理結(jié)果。除局領(lǐng)導(dǎo)和RA本身外的所有系統(tǒng)使用者（包括不擔(dān)任RA的部門領(lǐng)導(dǎo)）提出的需求都必須先通過部門內(nèi)審核然后進(jìn)入需求評(píng)審委員會(huì)評(píng)審流程。信息需求評(píng)審委員會(huì)為保證需求管理的有效運(yùn)作，特成立信息需求評(píng)審委員會(huì)，下設(shè)業(yè)務(wù)專家組和信息專家組。業(yè)務(wù)專家組負(fù)責(zé)業(yè)務(wù)評(píng)審，信息專家組負(fù)責(zé)信息技術(shù)評(píng)審。

普通使用部門基層人員及一般管理人員系統(tǒng)使用者，可以使用系統(tǒng)、對信息系統(tǒng)提出需求、

等待需求處理完畢、評(píng)價(jià)需求處理結(jié)果。部門領(lǐng)導(dǎo)RARA是部門內(nèi)需求審核人，RA由人事部發(fā)文指定，每個(gè)部門可以有一個(gè)或多

個(gè)RA。業(yè)務(wù)歸口管理部門基層人員及一般管理人員系統(tǒng)使用者，可以使用系統(tǒng)、對信息系統(tǒng)提出需求、

等待需求處理完畢、評(píng)價(jià)需求處理結(jié)果。部門領(lǐng)導(dǎo)RARA是部門內(nèi)需求審核人，RA由人事部發(fā)文指定，每個(gè)部門可以有一個(gè)或多

個(gè)RA。業(yè)務(wù)專家組信息需求評(píng)審委員會(huì)中指定的業(yè)務(wù)專家組負(fù)責(zé)對需求進(jìn)行業(yè)務(wù)評(píng)審。業(yè)務(wù)專家

組按照業(yè)務(wù)條線分為若干小組，按照需求評(píng)審委

員會(huì)的規(guī)劃，每個(gè)信息系統(tǒng)都有其對應(yīng)的業(yè)務(wù)專家組，在相應(yīng)信息系統(tǒng)出現(xiàn)需求

變更和問題反饋時(shí)執(zhí)行需求業(yè)務(wù)評(píng)審工作。信息部基層人員及一般管理人員系統(tǒng)使用者，可以使用系統(tǒng)、對信息系統(tǒng)提出需求、

等待需求處理完畢、評(píng)價(jià)需求處理結(jié)果。部門領(lǐng)導(dǎo)RARA是部門內(nèi)需求審核人，RA由人事部發(fā)文指定，每個(gè)部門可以有一個(gè)或多

個(gè)RA。業(yè)務(wù)專家組信息需求評(píng)審委員會(huì)中指定的業(yè)務(wù)專家組負(fù)責(zé)對需求進(jìn)行業(yè)務(wù)評(píng)審。部分業(yè)務(wù)的歸口管理部門是信息部。信息專家組需求評(píng)審委員會(huì)中指定的信息專家組負(fù)責(zé)對需求進(jìn)行信息技術(shù)評(píng)審。信息

專家組分為信息系統(tǒng)組、SOA集成組、信息安全組、廠商組等。

信息專家組中的信息系統(tǒng)組由多個(gè)下屬小組組成，每個(gè)下屬小組對應(yīng)一個(gè)

信息系統(tǒng)。所有針對信息系統(tǒng)提出的需求都會(huì)先由信息系統(tǒng)組下屬小組接收處

理，由下屬小組決定是否發(fā)起與其他幾個(gè)信息專家組的會(huì)簽。信息系統(tǒng)負(fù)責(zé)人信息部為每個(gè)信息系統(tǒng)指定一個(gè)信息系統(tǒng)負(fù)責(zé)人，信息系統(tǒng)負(fù)責(zé)人

保證系統(tǒng)正常運(yùn)行、處理跟進(jìn)系統(tǒng)改造。Copyright@2004-2014上海翰緯11第十一頁，共四十三頁。案例1：Copyright@2004-2014上海翰緯12第十二頁，共四十三頁。案例2：某軟件開發(fā)商需求管理流程角色職責(zé)能力要求備注客戶/最終用戶被邀請參與《軟件需求規(guī)格說明書》的評(píng)審；參與并確認(rèn)客戶需求的定義。

項(xiàng)目經(jīng)理

參與《軟件需求規(guī)格說明書》的評(píng)審；建立并維護(hù)本項(xiàng)目的需求跟蹤矩陣，跟蹤需求負(fù)責(zé)接收《需求變更申請表》，組織需求變更活動(dòng)的開展；定義需求狀態(tài)類型；分析需求跟蹤狀態(tài)結(jié)果；接受需求變更、需求狀態(tài)類別確定的培訓(xùn)

高級(jí)經(jīng)理參與《軟件需求規(guī)格說明書》的評(píng)審批準(zhǔn)軟件需求規(guī)格說明書評(píng)審報(bào)告

項(xiàng)目組成員協(xié)助項(xiàng)目經(jīng)理定義客戶原始需求或需求協(xié)助項(xiàng)目經(jīng)理編寫軟件需求規(guī)格說明書負(fù)責(zé)不同階段的需求跟蹤矩陣內(nèi)容（素材）的更新、分析、再利用負(fù)責(zé)變更的需求的修改；

測試人員參與《軟件需求規(guī)格說明書》的評(píng)審；負(fù)責(zé)不同階段的跟蹤矩陣內(nèi)容（素材）的更新、分析、再利用

配置管理人員

參與《軟件需求規(guī)格說明書》的評(píng)審；負(fù)責(zé)將需求基線納入配置管理；并在需求基線的變更過程中，記錄變更狀態(tài)；發(fā)布變更和基線；更新需求基線；統(tǒng)計(jì)需求變更總數(shù)；接受需求變更、需求狀態(tài)表填寫、需求狀態(tài)圖繪制的培訓(xùn)

質(zhì)量保證人員參與《軟件需求規(guī)格說明書》的評(píng)審；檢查《需求跟蹤矩陣》的填寫，協(xié)助項(xiàng)目經(jīng)理分析需求跟蹤狀態(tài)結(jié)果

Copyright@2004-2014上海翰緯13第十三頁，共四十三頁。案例2：某軟件開發(fā)商需求管理流程Copyright@2004-2014上海翰緯14第十四頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯15概念準(zhǔn)備實(shí)際案例XX銀行需求管理流程現(xiàn)狀流程活動(dòng)和流程角色設(shè)計(jì)管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第十五頁，共四十三頁。需求管理（差距分析&現(xiàn)狀）現(xiàn)狀：優(yōu)勢：不足：Copyright@2004-2014上海翰緯16第十六頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯17概念準(zhǔn)備實(shí)際案例XX銀行需求管理流程現(xiàn)狀流程活動(dòng)和流程角色設(shè)計(jì)管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第十七頁，共四十三頁。對需求的處理將遵循以下執(zhí)行途徑提交需求： （1）需求來源：業(yè)務(wù)部門關(guān)閉事件： （1）一般有手動(dòng)關(guān)閉和自動(dòng)關(guān)閉兩種方式； （2）採用首問負(fù)責(zé)制，一般應(yīng)集中由服務(wù)臺(tái)（一線）工作人員關(guān)閉，如有特殊需求可由需求經(jīng)理關(guān)閉。Copyright@2004-2014上海翰緯18第十八頁，共四十三頁。需求管理流程活動(dòng)根據(jù)實(shí)際業(yè)務(wù)需求提出需求申請交至服務(wù)臺(tái)；記錄需求申請，並創(chuàng)建和分派需求申請單；受理技術(shù)需求；判定需求信息是否充足；技術(shù)需求分析和建模，並編寫業(yè)務(wù)需求說明書；創(chuàng)建變更申請；業(yè)務(wù)需求內(nèi)部評(píng)審和提交技術(shù)需求受理分析和評(píng)審確認(rèn)變更管理評(píng)審分析評(píng)審變更申請進(jìn)，並反饋?zhàn)兏嚓P(guān)情況；記錄更新需求評(píng)審結(jié)果，並反饋結(jié)果；需求關(guān)閉與用戶驗(yàn)證結(jié)果，徵求用戶同意關(guān)閉事件根據(jù)知識(shí)管理流程決定是否需要進(jìn)行更新知識(shí)庫關(guān)閉事件，設(shè)定適當(dāng)?shù)年P(guān)閉代碼

受理業(yè)務(wù)需求；判定需求信息是否充分；業(yè)務(wù)需求分析和建模，並編寫業(yè)務(wù)需求說明書；業(yè)務(wù)需求可行性評(píng)審；記錄需求評(píng)審結(jié)果；業(yè)務(wù)需求受理分析和評(píng)審確認(rèn)Copyright@2004-2014上海翰緯19第十九頁，共四十三頁。需求管理與其他流程的關(guān)係Copyright@2004-2014上海翰緯20第二十頁，共四十三頁。需求管理流程角色Copyright@2004-2014上海翰緯21需求管理流程角色主要職責(zé)需求提出人業(yè)務(wù)部門提交需求。服務(wù)臺(tái)分派需求單。更新需求記錄。跟蹤整個(gè)需求管理流程。業(yè)務(wù)需求經(jīng)理支持保障部內(nèi)業(yè)務(wù)需求負(fù)責(zé)人。協(xié)調(diào)相關(guān)資源進(jìn)行業(yè)務(wù)需求分析建模、業(yè)務(wù)需求評(píng)審，保障需求管理按照預(yù)定流程順利運(yùn)作。負(fù)責(zé)需求管理與其他流程的交互管理工作。業(yè)務(wù)需求分析員信息科技部內(nèi)技術(shù)需求負(fù)責(zé)人協(xié)調(diào)相關(guān)資源進(jìn)行技術(shù)需求分析建模，技術(shù)需求評(píng)審工作。技術(shù)需求經(jīng)理信息科技部內(nèi)技術(shù)需求負(fù)責(zé)人。協(xié)調(diào)相關(guān)資源進(jìn)行技術(shù)需求分析建模，技術(shù)需求評(píng)審工作。技術(shù)需求分析員技術(shù)需求分析建模和定義描述，並編寫技術(shù)需求規(guī)格說明書。第二十一頁，共四十三頁。需求管理流程角色匹配Copyright@2004-2014上海翰緯22需求管理流程角色對應(yīng)XX銀行相關(guān)崗位/人員需求提出人服務(wù)臺(tái)業(yè)務(wù)需求經(jīng)理業(yè)務(wù)需求分析員技術(shù)需求經(jīng)理技術(shù)需求分析員第二十二頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯23概念準(zhǔn)備實(shí)際案例XX銀行需求管理流程現(xiàn)狀流程活動(dòng)和流程角色設(shè)計(jì)管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第二十三頁，共四十三頁。需求管理流程的流程原則業(yè)務(wù)部門與信息科技部、支持保障部應(yīng)本著團(tuán)結(jié)、協(xié)作的原則在信息技術(shù)服務(wù)需求的全生命週期內(nèi)保持充分溝通。需求的生命週期包括：需求提交、需求分析、需求審核、需求開發(fā)、需求測試、需求驗(yàn)證和需求上線。流程執(zhí)行應(yīng)遵循以下原則：需求的提交與分析遵循需求管理流程。需求審核分為以下兩種情況：如需立項(xiàng)審批應(yīng)遵循公司立項(xiàng)和招投標(biāo)相關(guān)規(guī)定；其他情況遵循變更管理流程的變更策略。需求開發(fā)、測試、驗(yàn)證和上線在發(fā)佈和部署管理流程中實(shí)現(xiàn)，並遵循流程中發(fā)佈和部署的相關(guān)策略。Copyright@2004-2014上海翰緯24第二十四頁，共四十三頁。需求單的責(zé)任人策略責(zé)任人策略用來確保每個(gè)需求在任何時(shí)段都有適當(dāng)?shù)娜藛T來負(fù)責(zé)，從而保證需求處理的及時(shí)性和有效性，確保需求的處理能夠得到及時(shí)跟蹤和協(xié)調(diào)。事件單的責(zé)任人策略當(dāng)一個(gè)需求被創(chuàng)建後，事件需求受理員負(fù)責(zé)這個(gè)需求單，其負(fù)責(zé)跟蹤需求處理的進(jìn)展直至最終的解決；當(dāng)需求單被分派後，需求經(jīng)理員負(fù)責(zé)此需求單，但是分派方（需求受理員）有責(zé)任通知被分派的需求經(jīng)理，需求經(jīng)理協(xié)調(diào)需求分析員完成需求分析和建模工作；需求單被需求經(jīng)理接受之後，需求經(jīng)理對該單負(fù)責(zé)；Copyright@2004-2014上海翰緯25第二十五頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯26概念準(zhǔn)備實(shí)際案例XX銀行需求管理流程現(xiàn)狀流程活動(dòng)和流程角色設(shè)計(jì)管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第二十六頁，共四十三頁。需求管理流程總結(jié)Copyright@2004-2014上海翰緯27需求管理是服務(wù)管理非常重要的一個(gè)方面。如果對客戶的服務(wù)需求缺乏充分的需求管理，則需求的不確定性就會(huì)成為服務(wù)提供者的一個(gè)主要風(fēng)險(xiǎn)來源。需求管理的流程核心是需求來源於業(yè)務(wù)部門，需求提交後由服務(wù)臺(tái)開單，經(jīng)過需求和技術(shù)需求分析建模和評(píng)審，交由變更管理評(píng)審，最終由服務(wù)臺(tái)關(guān)單。第二十七頁，共四十三頁。需求管理流程課後作業(yè)對今天現(xiàn)場討論未達(dá)成一致的管理流程、角色匹配、管理策略等，翰緯會(huì)根據(jù)需要提供作業(yè)範(fàn)本和其他實(shí)例參考，XX銀行各團(tuán)隊(duì)需參考翰緯給出的範(fàn)例和範(fàn)本，制定自己的管理策略。Copyright@2004-2014上海翰緯28第二十八頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯29概念準(zhǔn)備實(shí)際案例XX銀行需求管理流程現(xiàn)狀流程活動(dòng)和流程角色設(shè)計(jì)管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第二十九頁，共四十三頁。ITILV3StrategyService：DemandManagement

業(yè)務(wù)活動(dòng)模式Copyright@2004-2014上海翰緯30業(yè)務(wù)活動(dòng)影響服務(wù)需求模式（來源：OGC）第三十頁，共四十三頁。ITILV3StrategyService：DemandManagement

業(yè)務(wù)活動(dòng)模式業(yè)務(wù)（流程）是服務(wù)需求的主要來源。業(yè)務(wù)活動(dòng)模式（PBA）影響著服務(wù)提供者提供的需求方式。必須研究客戶的業(yè)務(wù)以便確定、分析和設(shè)計(jì)這些模式，從而為容量管理提供充分的基礎(chǔ)。業(yè)務(wù)活動(dòng)模式（PBA）PBA是用於描述一項(xiàng)或多項(xiàng)業(yè)務(wù)（流程）活動(dòng)的負(fù)載（workload）情況的需求分析文檔。業(yè)務(wù)活動(dòng)隨時(shí)間而變化的“走勢圖”有助於幫助IT服務(wù)提供者深入瞭解並規(guī)劃不同級(jí)別的業(yè)務(wù)活動(dòng)。定義一項(xiàng)業(yè)務(wù)的一些動(dòng)態(tài)變化的關(guān)鍵參數(shù)，包括與客戶、供應(yīng)商、合作夥伴以及其他利益相關(guān)者的關(guān)係。PBA需納入變更管理的控制。PBA中需要描述業(yè)務(wù)流程的一些重要參數(shù)，如頻率、數(shù)量、位置和持續(xù)時(shí)間等。分析PBA是為如下的服務(wù)管理職能和流程提供輸入：服務(wù)設(shè)計(jì)後可以優(yōu)化設(shè)計(jì)，以適應(yīng)需求的方式；服務(wù)目錄可以將需求方式與適當(dāng)?shù)姆?wù)對應(yīng)；服務(wù)組合管理可以批準(zhǔn)在增加容量、新的服務(wù)或變更服務(wù)上進(jìn)行的投資；服務(wù)運(yùn)營可以調(diào)整資源的分配和安排；服務(wù)運(yùn)營可以識(shí)別機(jī)會(huì)，通過對緊密匹配的需求方式進(jìn)行分組而合併需求；財(cái)務(wù)管理可以批準(zhǔn)合適的激勵(lì)措施，從而影響需求。Copyright@2004-2014上海翰緯31第三十一頁，共四十三頁。ITILV3StrategyService：DemandManagement

業(yè)務(wù)活動(dòng)模式和用戶概述業(yè)務(wù)活動(dòng)推動(dòng)了服務(wù)的需求。用戶概述（如人員、流程和應(yīng)用）產(chǎn)生了業(yè)務(wù)活動(dòng)模式（PBA）。用戶概述（UserProfile）是用於描述用戶對各種IT服務(wù)的需求的一種需求分析性文檔。每份用戶概述文件與一份或者多分PBA文件相關(guān)聯(lián)，如下圖：對於有些業(yè)務(wù)流程或系統(tǒng)，我們也可以將其視為一個(gè)用戶，可根據(jù)實(shí)際情況進(jìn)行判斷。Copyright@2004-2014上海翰緯32第三十二頁，共四十三頁。CMMI開發(fā)模型V1.3：Part1

4.過程域之間的關(guān)係:項(xiàng)目管理類（項(xiàng)目管理類）Copyright@2004-2014上海翰緯33基本項(xiàng)目管理過程域CMMI-DEV中的七個(gè)項(xiàng)目管理類過程域：?集成項(xiàng)目管理（IPM）?項(xiàng)目監(jiān)督與控制（PMC）?項(xiàng)目計(jì)畫（PP）?量化項(xiàng)目管理（QPM）?需求管理（REQM）?風(fēng)險(xiǎn)管理（RSKM）?供方協(xié)議管理（SAM）第三十三頁，共四十三頁。CMMI開發(fā)模型V1.3：Part1

4.過程域之間的關(guān)係:項(xiàng)目管理類—需求管理（REQM）CMMI-DEV中的七個(gè)項(xiàng)目管理類過程域：集成項(xiàng)目管理（IntegratedProjectManagement，IPM）項(xiàng)目監(jiān)督與控制（ProjectMonitoringandControl，PMC）項(xiàng)目計(jì)畫（ProjectPlanning，PP）量化項(xiàng)目管理（QuantitativeProjectManagement，QPM）需求管理（RequirementsManagement，REQM）風(fēng)險(xiǎn)管理（RiskManagement，RSKM）供方協(xié)議管理（SupplierAgreementManagement，SAM）需求管理（RequirementsManagement，REQM）對需求進(jìn)行維護(hù)。描述了獲得並控制需求的變更，並確保其它相關(guān)計(jì)畫與資料保持最新狀態(tài)的活動(dòng)。提供了從客戶需求到產(chǎn)品需求到產(chǎn)品元件需求的需求可追溯性。確保需求的變更能夠體現(xiàn)在項(xiàng)目計(jì)畫、活動(dòng)與工作產(chǎn)品中。需求管理是動(dòng)態(tài)且經(jīng)常迴圈發(fā)生的事件序列。Copyright@2004-2014上海翰緯34第三十四頁，共四十三頁。CMMI開發(fā)模型V1.3：Part1

4.過程域之間的關(guān)係:工程類Copyright@2004-2014上海翰緯35工程類過程域：

適用于開發(fā)領(lǐng)域中任何產(chǎn)品或服務(wù)的開發(fā)（如，軟體產(chǎn)品、硬體產(chǎn)品、服務(wù)、過程等）。CMMI-DEV中的五個(gè)工程類過程域是：產(chǎn)品集成（ProductIntegration，PI）需求開發(fā)（RequirementsDevelopment，RD）技術(shù)解決方案（TechnicalSolution，TS）確認(rèn)（Validation，VAL）驗(yàn)證（Verification，VER）

第三十五頁，共四十三頁。CMMI：Part1應(yīng)用於發(fā)展的CMMI

4.過程域之間的關(guān)係:工程類Copyright@2004-2014上海翰緯36工程類過程域第三十六頁，共四十三頁。CMMI開發(fā)模型V1.3：Part1

4.過程域之間的關(guān)係:工程類需求開發(fā)（RD）識(shí)別客戶需要並將這些需要轉(zhuǎn)化為產(chǎn)品需求。產(chǎn)品需求的集合被加以分析，生成高層次的概念解決方案。該需求集合隨後被分配，以建立最初的產(chǎn)品元件需求集合。該產(chǎn)品與產(chǎn)品元件的需求集合清晰地描述了產(chǎn)品的性能、品質(zhì)屬性、設(shè)計(jì)功能、驗(yàn)證需求等等，並通過開發(fā)人員能夠理解並使用的術(shù)語進(jìn)行描述。提供需求至“技術(shù)解決方案”過程域，在此處需求被轉(zhuǎn)換為產(chǎn)品架構(gòu)、產(chǎn)品元件設(shè)計(jì)與產(chǎn)品元件（如通過編碼、製造等）。需求也被提供給“產(chǎn)品集成”過程域，在此處產(chǎn)品元件被組合起來，介面得到驗(yàn)證，以確保其符合“需求開發(fā)”過程域所提供的介面需求。技術(shù)解決方案（TS）開發(fā)產(chǎn)品元件的技術(shù)資料包，用於“產(chǎn)品集成”過程域或“供方協(xié)議管理”過程域。備選解決方案被考察，並基於已建立的準(zhǔn)則選擇最優(yōu)設(shè)計(jì)。這些準(zhǔn)則可以因產(chǎn)品不同而有顯著區(qū)別，這取決於產(chǎn)品類型、操作環(huán)境、性能需求、支援需求以及成本或交付進(jìn)度。依賴於“驗(yàn)證”過程域中的特定實(shí)踐，以在設(shè)計(jì)過程中並在最後的構(gòu)建之前，執(zhí)行設(shè)計(jì)驗(yàn)證與同級(jí)評(píng)審。Copyright@2004-2014上海翰緯37第三十七頁，共四十三頁。CMMI開發(fā)模型V1.3：Part1

4.過程域之間的關(guān)係:工程類驗(yàn)證（VER)確保選定的工作產(chǎn)品滿足規(guī)定的需求。選擇工作產(chǎn)品與驗(yàn)證方法，用於對照規(guī)定的需求對工作產(chǎn)品進(jìn)行驗(yàn)證。驗(yàn)證也應(yīng)對了同級(jí)評(píng)審。確認(rèn)（VAL)對照客戶需要，增量式地對產(chǎn)品進(jìn)行確認(rèn)。確認(rèn)可以在操作環(huán)境或模擬的操作環(huán)境下執(zhí)行。在確認(rèn)的需求方面與客戶進(jìn)行協(xié)調(diào)是該過程域的重要元素。範(fàn)圍包括對產(chǎn)品、產(chǎn)品元件、選定的中間工作產(chǎn)品與過程的確認(rèn)。產(chǎn)品集成（PI）包含的特定實(shí)踐與建立集成策略、進(jìn)行產(chǎn)品元件集成、以及向客戶交付產(chǎn)品等相關(guān)聯(lián)。在實(shí)施產(chǎn)品集成過程時(shí)使用了“確認(rèn)”過程域與“驗(yàn)證”過程域中的特定實(shí)踐。介面驗(yàn)證是集成過程中的必要事件。在操作環(huán)境中進(jìn)行產(chǎn)品集成時(shí)，就要使用到“確認(rèn)”過程域中的特定實(shí)踐。Copyright@2004-2014上海翰緯38第三十八頁，共四十三頁。CMMI:Part2通用目標(biāo)與通用實(shí)踐以及過程域

產(chǎn)品集成（PI)目的：將產(chǎn)品元件裝配成產(chǎn)品，確保產(chǎn)品作為一個(gè)整體正確地運(yùn)行（即具有所要求的功能與品質(zhì)屬性），並交付產(chǎn)品。簡介：本過程域涉及如何將產(chǎn)品元件集成為更複雜的產(chǎn)品元件或者完整的產(chǎn)品。本過程域的範(fàn)圍是按照已定義的集成策略與規(guī)程，在一個(gè)階段或者增量式的多個(gè)階段中進(jìn)行產(chǎn)品元件的漸進(jìn)裝配，以實(shí)現(xiàn)完整的產(chǎn)品集成。所有過程域中使用的術(shù)語“產(chǎn)品”與“產(chǎn)品元件”，其含義也包括服務(wù)、服務(wù)系統(tǒng)及其元件。產(chǎn)品集成的一個(gè)重要方面是管理產(chǎn)品與產(chǎn)品元件的內(nèi)部與外部介面，以確保介面間的相容性。特定目標(biāo)與特定實(shí)踐：

SG1準(zhǔn)備產(chǎn)品集成SP1.1建立集成策略SP1.2建立產(chǎn)品集成環(huán)境SP1.3建立產(chǎn)品集成規(guī)程與準(zhǔn)則SG2確保介面相容性SP2.1評(píng)審介面描述的完整性SP2.2管理介面SG3裝配產(chǎn)品元件並交付產(chǎn)品SP3.1確定需集成的產(chǎn)品元件準(zhǔn)備就緒SP3.2裝配產(chǎn)品元件SP3.3評(píng)價(jià)裝配後的產(chǎn)品元件SP3.4打包並交付產(chǎn)品或產(chǎn)品元件Copyright@2004-2014上海翰緯39第三十九頁，共四十三頁。CMMI:Part2通用目標(biāo)與通用實(shí)踐以及過程域

需求開發(fā)（RD)目的：挖掘、分析並建立客戶需求、產(chǎn)品需求與產(chǎn)品元件需求。簡介：過程域描述3類需求：客戶需求、產(chǎn)品需求與產(chǎn)品元件需求。需求涉及：相關(guān)干係人的需要，包括與不同的產(chǎn)品生命週期階段和產(chǎn)品屬性（回應(yīng)性、安全性、可靠性等）相關(guān)的需要。源於設(shè)計(jì)解決方案（如：商用現(xiàn)貨產(chǎn)品的集成、特定架構(gòu)模式的使用等）的選擇所帶來的約束。

特定目標(biāo)與特定實(shí)踐：SG1開發(fā)客戶需求SP1.1挖掘需要SP1.2將干係人的需要轉(zhuǎn)換為客戶需求SG2開發(fā)產(chǎn)品需求SP2.1建立產(chǎn)品與產(chǎn)品元件需求SP2.2分配產(chǎn)品元件需求