需求管理流程设计研讨 课件

需求管理流程研討目的瞭解需求管理流程的基本概念、實際案例；討論並確定需求管理流程的主要活動及其之間的關聯；確定需求管理流程的典型角色及其與主要活動之間的匹配情況；討論並確認需求管理流程執行策略並收集相關建議。Copyright@2004-2014上海翰緯1需求管理流程研討目的瞭解需求管理流程的基本概念、實際案例；C主要關注點需要確定的關注點：支保部的定位？需求管理流程的管理對象和範圍？需求管理的生命週期長度？開發前還是上線投產？流程的角色設置和職責流程各角色的工作界面和溝通接口

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

等待需求处理完毕、评价需求处理结果。除局领导和RA本身外的所有系统使用者（包括不担任RA的部门领导）提出的需求都必须先通过部门内审核然后进入需求评审委员会评审流程。信息需求评审委员会为保证需求管理的有效运作，特成立信息需求评审委员会，下设业务专家组和信息专家组。业务专家组负责业务评审，信息专家组负责信息技术评审。

普通使用部门基层人员及一般管理人员系统使用者，可以使用系统、对信息系统提出需求、

等待需求处理完毕、评价需求处理结果。部门领导RARA是部门内需求审核人，RA由人事部发文指定，每个部门可以有一个或多

个RA。业务归口管理部门基层人员及一般管理人员系统使用者，可以使用系统、对信息系统提出需求、

等待需求处理完毕、评价需求处理结果。部门领导RARA是部门内需求审核人，RA由人事部发文指定，每个部门可以有一个或多

个RA。业务专家组信息需求评审委员会中指定的业务专家组负责对需求进行业务评审。业务专家

组按照业务条线分为若干小组，按照需求评审委

员会的规划，每个信息系统都有其对应的业务专家组，在相应信息系统出现需求

变更和问题反馈时执行需求业务评审工作。信息部基层人员及一般管理人员系统使用者，可以使用系统、对信息系统提出需求、

等待需求处理完毕、评价需求处理结果。部门领导RARA是部门内需求审核人，RA由人事部发文指定，每个部门可以有一个或多

个RA。业务专家组信息需求评审委员会中指定的业务专家组负责对需求进行业务评审。部分业务的归口管理部门是信息部。信息专家组需求评审委员会中指定的信息专家组负责对需求进行信息技术评审。信息

专家组分为信息系统组、SOA集成组、信息安全组、厂商组等。

信息专家组中的信息系统组由多个下属小组组成，每个下属小组对应一个

信息系统。所有针对信息系统提出的需求都会先由信息系统组下属小组接收处

理，由下属小组决定是否发起与其他几个信息专家组的会签。信息系统负责人信息部为每个信息系统指定一个信息系统负责人，信息系统负责人

保证系统正常运行、处理跟进系统改造。Copyright@2004-2014上海翰纬11案例1：某電力局信息系統需求管理流程部门业务参与者职责说明备案例1：Copyright@2004-2014上海翰纬12案例1：Copyright@2004-2014上海翰纬案例2：某軟件開發商需求管理流程角色职责能力要求备注客户/最终用户被邀请参与《软件需求规格说明书》的评审；参与并确认客户需求的定义。

项目经理

参与《软件需求规格说明书》的评审；建立并维护本项目的需求跟踪矩阵，跟踪需求负责接收《需求变更申请表》，组织需求变更活动的开展；定义需求状态类型；分析需求跟踪状态结果；接受需求变更、需求状态类别确定的培训

高级经理参与《软件需求规格说明书》的评审批准软件需求规格说明书评审报告

项目组成员协助项目经理定义客户原始需求或需求协助项目经理编写软件需求规格说明书负责不同阶段的需求跟踪矩阵内容（素材）的更新、分析、再利用负责变更的需求的修改；

测试人员参与《软件需求规格说明书》的评审；负责不同阶段的跟踪矩阵内容（素材）的更新、分析、再利用

配置管理人员

参与《软件需求规格说明书》的评审；负责将需求基线纳入配置管理；并在需求基线的变更过程中，记录变更状态；发布变更和基线；更新需求基线；统计需求变更总数；接受需求变更、需求状态表填写、需求状态图绘制的培训

质量保证人员参与《软件需求规格说明书》的评审；检查《需求跟踪矩阵》的填写，协助项目经理分析需求跟踪状态结果

Copyright@2004-2014上海翰纬13案例2：某軟件開發商需求管理流程角色职责能力要求备注客户/最案例2：某軟件開發商需求管理流程Copyright@2004-2014上海翰纬14案例2：某軟件開發商需求管理流程Copyright@20議程/AgendaCopyright@2004-2014上海翰緯15概念準備實際案例XX銀行需求管理流程現狀流程活動和流程角色設計管理策略研討總結與課後作業安排附錄：理論依據議程/AgendaCopyright@2004-201需求管理（差距分析&現狀）現狀：優勢：不足：Copyright@2004-2014上海翰緯16需求管理（差距分析&現狀）現狀：Copyright@20議程/AgendaCopyright@2004-2014上海翰緯17概念準備實際案例XX銀行需求管理流程現狀流程活動和流程角色設計管理策略研討總結與課後作業安排附錄：理論依據議程/AgendaCopyright@2004-201對需求的處理將遵循以下執行途徑提交需求： （1）需求來源：業務部門關閉事件： （1）一般有手動關閉和自動關閉兩種方式； （2）採用首問負責制，一般應集中由服務台（一線）工作人員關閉，如有特殊需求可由需求經理關閉。Copyright@2004-2014上海翰緯18對需求的處理將遵循以下執行途徑提交需求：Copyright需求管理流程活動根據實際業務需求提出需求申請交至服務台；記錄需求申請，並創建和分派需求申請單；受理技術需求；判定需求信息是否充足；技術需求分析和建模，並編寫業務需求說明書；創建變更申請；業務需求內部評審和提交技術需求受理分析和評審確認變更管理評審分析評審變更申請進，並反饋變更相關情況；記錄更新需求評審結果，並反饋結果；需求關閉與用戶驗證結果，徵求用戶同意關閉事件根據知識管理流程決定是否需要進行更新知識庫關閉事件，設定適當的關閉代碼

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

業務活動模式Copyright@2004-2014上海翰緯30業務活動影響服務需求模式（來源：OGC）ITILV3StrategyService：DemanITILV3StrategyService：DemandManagement

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

業務活動模式和用戶概述業務活動推動了服務的需求。用戶概述（如人員、流程和應用）產生了業務活動模式（PBA）。用戶概述（UserProfile）是用於描述用戶對各種IT服務的需求的一種需求分析性文檔。每份用戶概述文件與一份或者多分PBA文件相關聯，如下圖：對於有些業務流程或系統，我們也可以將其視為一個用戶，可根據實際情況進行判斷。Copyright@2004-2014上海翰纬32ITILV3StrategyService：DemanCMMI開發模型V1.3：Part1

4.過程域之間的關係:項目管理類（項目管理類）Copyright@2004-2014上海翰緯33基本項目管理過程域CMMI-DEV中的七個項目管理類過程域：•集成項目管理（IPM）•項目監督與控制（PMC）•項目計畫（PP）•量化項目管理（QPM）•需求管理（REQM）•風險管理（RSKM）•供方協議管理（SAM）CMMI開發模型V1.3：Part1

4.過程域之間的關CMMI開發模型V1.3：Part1

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

4.過程域之間的關CMMI開發模型V1.3：Part1

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

適用于開發領域中任何產品或服務的開發（如，軟體產品、硬體產品、服務、過程等）。CMMI-DEV中的五個工程類過程域是：產品集成（ProductIntegration，PI）需求開發（RequirementsDevelopment，RD）技術解決方案（TechnicalSolution，TS）確認（Validation，VAL）驗證（Verification，VER）

CMMI開發模型V1.3：Part1

4.過程域之間的關CMMI：Part1應用於發展的CMMI

4.過程域之間的關係:工程類Copyright@2004-2014上海翰纬36工程類過程域CMMI：Part1應用於發展的CMMI

4.過程域之CMMI開發模型V1.3：Part1

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

4.過程域之間的關CMMI開發模型V1.3：Part1

4.過程域之間的關係:工程類驗證（VER)確保選定的工作產品滿足規定的需求。選擇工作產品與驗證方法，用於對照規定的需求對工作產品進行驗證。驗證也應對了同級評審。確認（VAL)對照客戶需要，增量式地對產品進行確認。確認可以在操作環境或模擬的操作環境下執行。在確認的需求方面與客戶進行協調是該過程域的重要元素。範圍包括對產品、產品元件、選定的中間工作產品與過程的確認。產品集成（PI）包含的特定實踐與建立集成策略、進行產品元件集成、以及向客戶交付產品等相關聯。在實施產品集成過程時使用了“確認”過程域與“驗證”過程域中的特定實踐。介面驗證是集成過程中的必要事件。在操作環境中進行產品集成時，就要使用到“確認”過程域中的特定實踐。Copyright@2004-2014上海翰緯38CMMI開發模型V1.3：Part1

4.過程域之間的關CMMI:Part2通用目標與通用實踐以及過程域

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

SG1準備產品集成SP1.1建立集成策略SP1.2建立產品集成環境SP1.3建立產品集成規程與準則SG2確保介面相容性SP2.1評審介面描述的完整性SP2.2管理介面SG3裝配產品元件並交付產品SP3.1確定需集成的產品元件準備就緒SP3.2裝配產品元件SP3.3評價裝配後的產品元件SP3.4打包並交付產品或產品元件Copyright@2004-2014上海翰緯39CMMI:Part2通用目標與通用實踐以及過程域

產品集CMMI:Part2通用目標與通用實踐以及過程域

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

特定目標與特定實踐：SG1開發客戶需求SP1.1挖掘需要SP1.2將干係人的需要轉換為客戶需求SG2開發產品需求SP2.1建立產品與產品元件需求SP2.2分配產品元件需求SP2.3識別介面需求SG3分析並確認需求SP3.1建立操作概念與場景SP3.2建立必需的功能與品質屬性的定義SP3.3分析需求SP3.4分析需求以達到平衡SP3.5確認需求Copyright@2004-2014上海翰緯40CMMI:Part2通用目標與通用實踐以及過程域

需求開CMMI:Part2通用目標與通用實踐以及過程域

需求管理（REQM)目的：管理項目的產品與產品元件需求，並確保那些需求與項目計畫和工作產品間的協調一致。注意點：管理所有由項目收到或產生的需求，包括技術與非技術需求，以及由組織賦予項目的需求。由該過程域中的各過程產生的產品與產品元件需求也將由需求管理過程來進行管理。項目應採取適當的步驟來確保已批准的需求集得到管理，以支援項目計畫與執行的需要。特定目標與特定實踐:SG1管理需求SP1.1理解需求SP1.2獲得對需求的承諾SP1.3管理需求變更SP1.4維護需求的雙向可追溯性SP1.5確保項目工作與需求間的協調一致Copyright@2004-2014上海翰緯41CMMI:Part2通用目標與通用實踐以及過程域

需求管CMMI:Part2通用目標與通用實踐以及過程域

技術解決方案（TS)目的：選擇、設計並實現對需求的解決方案。解決方案、設計與實現包括單獨的或以適當形式組合的產品、產品元件以及與產品相關的生命週期過程。注意點：適用于產品架構的任一層級和每一個產品、產品元件以及與產品相關的生命週期過程。項目應採取適當的步驟來確保已批准的需求集得到管理，以支援項目計畫與執行的需要。特定目標與特定實踐:SG1選擇產品元件解決方案SP1.1開發備選解決方案與選擇準則SP1.2選擇產品元件解決方案SG2開發設計SP2.1設計產品或產品元件SP2.2建立技術資料包SP2.3使用準則設計介面SP2.4執行自製、購買或複用分析SG3實現產品設計SP3.1實現設計SP3.2開發產品支援文檔Copyright@2004-2014上海翰緯42CMMI:Part2通用目標與通用實踐以及過程域

技術解需求管理流程研討目的瞭解需求管理流程的基本概念、實際案例；討論並確定需求管理流程的主要活動及其之間的關聯；確定需求管理流程的典型角色及其與主要活動之間的匹配情況；討論並確認需求管理流程執行策略並收集相關建議。Copyright@2004-2014上海翰緯43需求管理流程研討目的瞭解需求管理流程的基本概念、實際案例；C主要關注點需要確定的關注點：支保部的定位？需求管理流程的管理對象和範圍？需求管理的生命週期長度？開發前還是上線投產？流程的角色設置和職責流程各角色的工作界面和溝通接口

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

等待需求处理完毕、评价需求处理结果。除局领导和RA本身外的所有系统使用者（包括不担任RA的部门领导）提出的需求都必须先通过部门内审核然后进入需求评审委员会评审流程。信息需求评审委员会为保证需求管理的有效运作，特成立信息需求评审委员会，下设业务专家组和信息专家组。业务专家组负责业务评审，信息专家组负责信息技术评审。

普通使用部门基层人员及一般管理人员系统使用者，可以使用系统、对信息系统提出需求、

等待需求处理完毕、评价需求处理结果。部门领导RARA是部门内需求审核人，RA由人事部发文指定，每个部门可以有一个或多

个RA。业务归口管理部门基层人员及一般管理人员系统使用者，可以使用系统、对信息系统提出需求、

等待需求处理完毕、评价需求处理结果。部门领导RARA是部门内需求审核人，RA由人事部发文指定，每个部门可以有一个或多

个RA。业务专家组信息需求评审委员会中指定的业务专家组负责对需求进行业务评审。业务专家

组按照业务条线分为若干小组，按照需求评审委

员会的规划，每个信息系统都有其对应的业务专家组，在相应信息系统出现需求

变更和问题反馈时执行需求业务评审工作。信息部基层人员及一般管理人员系统使用者，可以使用系统、对信息系统提出需求、

等待需求处理完毕、评价需求处理结果。部门领导RARA是部门内需求审核人，RA由人事部发文指定，每个部门可以有一个或多

个RA。业务专家组信息需求评审委员会中指定的业务专家组负责对需求进行业务评审。部分业务的归口管理部门是信息部。信息专家组需求评审委员会中指定的信息专家组负责对需求进行信息技术评审。信息

专家组分为信息系统组、SOA集成组、信息安全组、厂商组等。

信息专家组中的信息系统组由多个下属小组组成，每个下属小组对应一个

信息系统。所有针对信息系统提出的需求都会先由信息系统组下属小组接收处

理，由下属小组决定是否发起与其他几个信息专家组的会签。信息系统负责人信息部为每个信息系统指定一个信息系统负责人，信息系统负责人

保证系统正常运行、处理跟进系统改造。Copyright@2004-2014上海翰纬53案例1：某電力局信息系統需求管理流程部门业务参与者职责说明备案例1：Copyright@2004-2014上海翰纬54案例1：Copyright@2004-2014上海翰纬案例2：某軟件開發商需求管理流程角色职责能力要求备注客户/最终用户被邀请参与《软件需求规格说明书》的评审；参与并确认客户需求的定义。

项目经理

参与《软件需求规格说明书》的评审；建立并维护本项目的需求跟踪矩阵，跟踪需求负责接收《需求变更申请表》，组织需求变更活动的开展；定义需求状态类型；分析需求跟踪状态结果；接受需求变更、需求状态类别确定的培训

高级经理参与《软件需求规格说明书》的评审批准软件需求规格说明书评审报告

项目组成员协助项目经理定义客户原始需求或需求协助项目经理编写软件需求规格说明书负责不同阶段的需求跟踪矩阵内容（素材）的更新、分析、再利用负责变更的需求的修改；

测试人员参与《软件需求规格说明书》的评审；负责不同阶段的跟踪矩阵内容（素材）的更新、分析、再利用

配置管理人员

参与《软件需求规格说明书》的评审；负责将需求基线纳入配置管理；并在需求基线的变更过程中，记录变更状态；发布变更和基线；更新需求基线；统计需求变更总数；接受需求变更、需求状态表填写、需求状态图绘制的培训

质量保证人员参与《软件需求规格说明书》的评审；检查《需求跟踪矩阵》的填写，协助项目经理分析需求跟踪状态结果

Copyright@2004-2014上海翰纬55案例2：某軟件開發商需求管理流程角色职责能力要求备注客户/最案例2：某軟件開發商需求管理流程Copyright@2004-2014上海翰纬56案例2：某軟件開發商需求管理流程Copyright@20議程/AgendaCopyright@2004-2014上海翰緯57概念準備實際案例XX銀行需求管理流程現狀流程活動和流程角色設計管理策略研討總結與課後作業安排附錄：理論依據議程/AgendaCopyright@2004-201需求管理（差距分析&現狀）現狀：優勢：不足：Copyright@2004-2014上海翰緯58需求管理（差距分析&現狀）現狀：Copyright@20議程/AgendaCopyright@2004-2014上海翰緯59概念準備實際案例XX銀行需求管理流程現狀流程活動和流程角色設計管理策略研討總結與課後作業安排附錄：理論依據議程/AgendaCopyright@2004-201對需求的處理將遵循以下執行途徑提交需求： （1）需求來源：業務部門關閉事件： （1）一般有手動關閉和自動關閉兩種方式； （2）採用首問負責制，一般應集中由服務台（一線）工作人員關閉，如有特殊需求可由需求經理關閉。Copyright@2004-2014上海翰緯60對需求的處理將遵循以下執行途徑提交需求：Copyright需求管理流程活動根據實際業務需求提出需求申請交至服務台；記錄需求申請，並創建和分派需求申請單；受理技術需求；判定需求信息是否充足；技術需求分析和建模，並編寫業務需求說明書；創建變更申請；業務需求內部評審和提交技術需求受理分析和評審確認變更管理評審分析評審變更申請進，並反饋變更相關情況；記錄更新需求評審結果，並反饋結果；需求關閉與用戶驗證結果，徵求用戶同意關閉事件根據知識管理流程決定是否需要進行更新知識庫關閉事件，設定適當的關閉代碼

受理業務需求；判定需求信息是否充分；業務需求分析和建模，並編寫業務需求說明書；業務需求可行性評審；記錄需求評審結果；業務需求受理分析和評審確認Copyright@2004-2014上海翰緯61需求管理流程活動根據實際業務需求提出需求申請交至服務台；受理需求管理與其他流程的關係Copyright@2004-2014上海翰緯62需求管理與其他流程的關係Copyright@2004-2需求管理流程角色Copyright@2004-2014上海翰緯63需求管理流程角色主要職責需求提出人業務部門提交需求。服務台分派需求單。更新需求記錄。跟蹤整個需求管理流程。業務需求經理支持保障部內業務需求負責人。協調相關資源進行業務需求分析建模、業務需求評審，保障需求管理按照預定流程順利運作。負責需求管理與其他流程的交互管理工作。業務需求分析員信息科技部內技術需求負責人協調相關資源進行技術需求分析建模，技術需求評審工作。技術需求經理信息科技部內技術需求負責人。協調相關資源進行技術需求分析建模，技術需求評審工作。技術需求分析員技術需求分析建模和定義描述，並編寫技術需求規格說明書。需求管理流程角色Copyright@2004-2014上需求管理流程角色匹配Copyright@2004-2014上海翰緯64需求管理流程角色對應XX銀行相關崗位/人員需求提出人服務台業務需求經理業務需求分析員技術需求經理技術需求分析員需求管理流程角色匹配Copyright@2004-201議程/AgendaCopyright@2004-2014上海翰緯65概念準備實際案例XX銀行需求管理流程現狀流程活動和流程角色設計管理策略研討總結與課後作業安排附錄：理論依據議程/AgendaCopyright@2004-201需求管理流程的流程原則業務部門與信息科技部、支持保障部應本著團結、協作的原則在信息技術服務需求的全生命週期內保持充分溝通。需求的生命週期包括：需求提交、需求分析、需求審核、需求開發、需求測試、需求驗證和需求上線。流程執行應遵循以下原則：需求的提交與分析遵循需求管理流程。需求審核分為以下兩種情況：如需立項審批應遵循公司立項和招投標相關規定；其他情況遵循變更管理流程的變更策略。需求開發、測試、驗證和上線在發佈和部署管理流程中實現，並遵循流程中發佈和部署的相關策略。Copyright@2004-2014上海翰緯66需求管理流程的流程原則業務部門與信息科技部、支持保障部應本著需求單的責任人策略責任人策略用來確保每個需求在任何時段都有適當的人員來負責，從而保證需求處理的及時性和有效性，確保需求的處理能夠得到及時跟蹤和協調。事件單的責任人策略當一個需求被創建後，事件需求受理員負責這個需求單，其負責跟蹤需求處理的進展直至最終的解決；當需求單被分派後，需求經理員負責此需求單，但是分派方（需求受理員）有責任通知被分派的需求經理，需求經理協調需求分析員完成需求分析和建模工作；需求單被需求經理接受之後，需求經理對該單負責；Copyright@2004-2014上海翰緯67需求單的責任人策略責任人策略用來確保每個需求在任何時段都有適議程/AgendaCopyright@2004-2014上海翰緯68概念準備實際案例XX銀行需求管理流程現狀流程活動和流程角色設計管理策略研討總結與課後作業安排附錄：理論依據議程/AgendaCopyright@2004-201需求管理流程總結Copyright@2004-2014上海翰緯69需求管理是服務管理非常重要的一個方面。如果對客戶的服務需求缺乏充分的需求管理，則需求的不確定性就會成為服務提供者的一個主要風險來源。需求管理的流程核心是需求來源於業務部門，需求提交後由服務台開單，經過需求和技術需求分析建模和評審，交由變更管理評審，最終由服務台關單。需求管理流程總結Copyright@2004-2014上需求管理流程課後作業對今天現場討論未達成一致的管理流程、角色匹配、管理策略等，翰緯會根據需要提供作業範本和其他實例參考，XX銀行各團隊需參考翰緯給出的範例和範本，制定自己的管理策略。Copyright@2004-2014上海翰緯70需求管理流程課後作業對今天現場討論未達成一致的管理流程、角色議程/AgendaCopyright@2004-2014上海翰緯71概念準備實際案例XX銀行需求管理流程現狀流程活動和流程角色設計管理策略研討總結與課後作業安排附錄：理論依據議程/AgendaCopyright@2004-201ITILV3StrategyService：DemandManagement

業務活動模式Copyright@2004-2014上海翰緯72業務活動影響服務需求模式（來源：OGC）ITILV3StrategyService：DemanITILV3StrategyService：DemandManagement

業務活動模式業務（流程）是服務需求的主要來源。業務活動模式（PBA）影響著服務提供者提供的需求方式。必須研究客戶的業務以便確定、分析和設計這些模式，從而為容量管理提供充分的基礎。業務活動模式（PBA）PBA是用於描述一項或多項業務（流程）活動的負載（workload）情況的需求分析文檔。業務活動隨時間而變化的“走勢圖”有助於幫助IT服務提供者深入瞭解並規劃不同級別的業務活動。定義一項業務的一些動態變化的關鍵參數，包括與客戶、供應商、合作夥伴以及其他利益相關者的關係。PBA需納入變更管理的控制。PBA中需要描述業務流程的一些重要參數，如頻率、數量、位置和持續時間等。分析PBA是為如下的服務管理職能和流程提供輸入：服務設計後可以優化設計，以適應需求的方式；服務目錄可以將需求方式與適當的服務對應；服務組合管理可以批准在增加容量、新的服務或變更服務上進行的投資；服務運營可以調整資源的分配和安排；服務運營可以識別機會，通過對緊密匹配的需求方式進行分組而合併需求；財務管理可以批准合適的激勵措施，從而影響需求。Copyright@2004-2014上海翰緯73ITILV3StrategyService：DemanITILV3StrategyService：DemandManagement

業務活動模式和用戶概述業務活動推動了服務的需求。用戶概述（如人員、流程和應用）產生了業務活動模式（PBA）。用戶概述（UserProfile）是用於描述用戶對各種IT服務的需求的一種需求分析性文檔。每份用戶概述文件與一份或者多分PBA文件相關聯，如下圖：對於有些業務流程或系統，我們也可以將其視為一個用戶，可根據實際情況進行判斷。Copyright@2004-2014上海翰纬74ITILV3StrategyService：DemanCMMI開發模型V1.3：Part1

4.過程域之間的關係:項目管理類（項目管理類）Copyright@2004-2014上海翰緯75基本項目管理過程域CMMI-DEV中的七個項目管理類過程域：•集成項目管理（IPM）•項目監督與控制（PMC）•項目計畫（PP）•量化項目管理（QPM）•需求管理（REQM）•風險管理（RSKM）•供方協議管理（SAM）CMMI開發模型V1.3：Part1

4.過程域之間的關CMMI開發模型V1.3：Part1

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

4.過程域之間的關CMMI開發模型V1.3：Part1

4.過程域之間的關係:工程類Copyright@2004-2014上海翰緯77工程類過程域：

適用于開發領域中任何產品或服務的開發（如，軟體產品、硬體產品、服務、過程等）。CMMI-DEV中的五個工程類過程域是：產品集成（ProductIntegration，PI）需求開發（RequirementsDevelopment，RD）技術解決方案（TechnicalSolution，TS）確認（Validation，VAL）驗證（Verification，VER）

CMMI開發模型V1.3：Part1

4.過程域之間的關CMMI：Part1應用於發展的CMMI

4.過程域之間的關係:工程類Copyright@2004-2014上海翰纬78工程類過程域CMMI：Part1應用於發展的CMMI

4.過程域之CMMI開發模型V1.3：Part1

4.過程域之間的關係:工程類需求開發（RD）識別客戶需要並將這些需要轉化為產品需求。產品需求的集合被加以分析，生成高層次的概念解決方案。該需求集合隨後被分配，以建立最初的產品元件需求集合。該產品與產品元件的需求集合清晰地描述了產品的性能、品質屬性、設計功能、驗證需求等等，並通過開發人員能夠理解並使用的術語進行描述。提供