[精选]需求管理流程设计研讨v03

《[精选]需求管理流程设计研讨v03》由会员分享，可在线阅读，更多相关《[精选]需求管理流程设计研讨v03（43页珍藏版）》请在金锄头文库上搜索。

1、需求管理流程研討目的,瞭解需求管理流程的基本概念、實際案例； 討論並確定需求管理流程的主要活動及其之間的關聯； 確定需求管理流程的典型角色及其與主要活動之間的匹配情況； 討論並確認需求管理流程執行策略並收集相關建議。,Copyright 2004-2014上海翰緯,1,主要關注點,需要確定的關注點： 支保部的定位？ 需求管理流程的管理對象和範圍？ 需求管理的生命週期長度？開發前還是上線投產？ 流程的角色設置和職責 流程各角色的工作界面和溝通接口,目標： 需求管理恰如裁縫的量體裁衣，它直接關係到最終產品的成型。僅從字面出發，如果一個產品滿足了客戶需求，那它無疑就是成功的。需求管理的過程，從需求分

2、析開始貫穿整個項目始終，力圖實現最終產品同需求性的最佳結合。 需求管理能夠確證： 我們確知客戶的需求是什麼（質量）； 滿足客戶需求的最佳解決辦法（統一性）；,Copyright 2004-2014上海翰緯,2,議程/ Agenda,Copyright 2004-2014上海翰緯,3,概念準備 實際案例 XX銀行需求管理流程現狀 流程活動和流程角色設計 管理策略研討 總結與課後作業安排 附錄：理論依據,需求管理-基礎,目的： 確保服務資源的生產能力和需求預測及模式保持一致； 確保資源能力可以在需要時有效使用，在不使用時及時釋放 關鍵字： 業務分析 服務組合 資源容量 如何滿足“適”： 前提條件：

3、已受理需求申請 考慮要素：需求分析、需求評審、需求驗證、需求確認,過程目的,減小需求的不確定性 提供充分需求估計和規劃，保證產品和需求的一致性 減少因過度冗餘而導致閒置容量的額外成本無法得到有效的回收 鞏固與提升客戶與使用者滿意度 便於需求支持資源的合理配備與使用,過程價值,定義 是指理解並影響客戶對服務的需求以及提供相應容量以滿足這些需求的活動； 術語 信息技術服務需求：指業務部門以及最終用戶對信息技術服務的需求。 新增服務：按照業務部門或公司統一規劃（或備案）確定的、滿足用戶和業務需求的新增信息技術服務，這些服務未列入已發佈的服務目錄。 服務功能的變更：該服務已經上線運行，並且已列入部已發

4、佈的服務目錄，現階段主要以功能完善、修復Bug為主，通過立項續建來實現大版本升級。 說明 觸發條件：業務需求； 過程模式：主動式的管理過程； 過程特點：適，統一，一致,過程概述,Copyright 2004-2014上海翰緯,4,適,需求管理流程的主要活動概述（一）,需求開發 需求調研： 問卷 訪談 場景模擬 需求建模和分析，可利用以下工具進行： UML Rational Rose(Rational Software Architect) PowerDesigner VISIO 輸出需求定義（需求規格說明書）或需求定義說明書 需求定義的確認： 確認有兩層含義： 首先是需求調查與分析人員與客戶間

5、通過溝通，剔除或修訂對需求理解不一致的部分； 另外一個層面的意思是指，雙方對於已達成共同理解或獲得客戶/用戶認可的部分進行承諾。,Copyright 2004-2014 上海翰纬,5,需求管理流程的主要活動概述（二）,建立並識別需求狀態和跟蹤機制 需求狀態是指用戶需求的一種狀態變換過程 進行需求調研時，客戶對需求的描述可能有多種： 客戶可以明確且清楚的提出的需求； 客戶知道需要做些什麼，但又不能確定的需求； 客戶本身可以得出這類需求，但需求的業務不明確，還需要等待外部信息 客戶本身也說不清楚 對於這些需求，在需求開發的過程中，存在著以下幾種情況: 有可能要取消的 因為不明確而可以後延的，同時可

6、能轉化為被取消的需求 與客戶經過溝通或確認的，此處有兩種情況，一類是確認雙方達成共識，另一種情況是還需要再進一步溝通的。 建立狀態追蹤機制：如狀態追蹤矩陣 狀態示例： 待確認：客戶提出需求，但雙方沒有經過溝通或確認； 已確認：經過確認，雙方認可並達成共識； 未能確認: 雙方經過確認，但沒有達成共識的需求；,Copyright 2004-2014 上海翰纬,6,需求管理流程的主要活動概述（三）,技術解決方案設計 技術需求分析和建模 根據業務需求規格說明書或業務需求定義說明書和建模分析結果編制技術需求規格說明書 評審確認技術需求 開發技術解決方案： 定義產品或服務組件以滿足需求 定義組件的關係和接

7、口 明確組件的開發或獲取方式：內部完成還是採購 有條件時，可能有多套方案供評審決策 需求評審和確認 預審核：在進行正式評審前，需要有人員對其要進行評審的對象進行把關，確認其是否具備進入評審的初步條件。 正式評審中評判需求優劣的主要指標有：正確性、清晰性、無二義性、一致性、必要性、完整性、可實現性、可驗證性、可測性。 如果有可能，應制定預審核的送審材料清單和正式審核的檢查項清單。,Copyright 2004-2014 上海翰纬,7,需求管理流程的主要活動概述（四）,產品開發與集成 不在需求管理中討論 需求跟蹤 進行需求跟蹤的目的是為了建立和維護從用戶需求開始到測試之間的一致性與完整性。確保所有

8、的實現是以用戶需求為基礎。對於需求實現是否全部的覆蓋。同時確保所有的輸出與用戶需求的符合性。 正向跟蹤：以用戶需求為切入點，檢查用戶需求說明書或需求規格說明書中的每個需求是否都能在後繼工作產品中找到對應點。 逆向跟蹤：檢查設計文檔、代碼、測試用例等工作產品是否都能在需求規格說明書中找到出處。,Copyright 2004-2014 上海翰纬,8,需求管理流程的主要活動概述（五）,需求變更控制 需求變更通常會對產品開發和集成的進度、投入人力資源產生很大的影響，這是必須面臨與需要處理的問題。 需求發生變更的起因主要有： 隨著項目生命週期的不斷往前推進，人們（包括開發方和客戶方）對需求的瞭解越來越深

9、入，發現原先的提出的需求可能存在著一定的缺陷，因此要變更需求。 市場業務需求發生了變化，原先的需求可能跟不上當前的市場業務發展，因此要變更需求。 需求的變更則意味著要需要重新進行估計，調整資源、重新分配任務、修改前期工作產品等，而作為開發者，需要增加預算與投資，開發組要為此付出較重的代價。 需求變更控制的動機是： 如果需求變更帶來的好處大於壞處，那麼允許變更，但必須按照已定義的變更規程執行，以免變更失去控制。 如果需求變更帶來的壞處大於好處，那麼拒絕變更。 由於需求文檔是重要的配置項，需求的變更應當遵循相關的變更管理程序。,Copyright 2004-2014 上海翰纬,9,議程/ Agen

10、da,Copyright 2004-2014上海翰緯,10,概念準備 實際案例 XX銀行需求管理流程現狀 流程活動和流程角色設計 管理策略研討 總結與課後作業安排 附錄：理論依據,案例1：某電力局信息系統需求管理流程,Copyright 2004-2014 上海翰纬,11,案例1：,Copyright 2004-2014 上海翰纬,12,案例2：某軟件開發商需求管理流程,Copyright 2004-2014 上海翰纬,13,案例2：某軟件開發商需求管理流程,Copyright 2004-2014 上海翰纬,14,議程/ Agenda,Copyright 2004-2014上海翰緯,15,概念

11、準備 實際案例 XX銀行需求管理流程現狀 流程活動和流程角色設計 管理策略研討 總結與課後作業安排 附錄：理論依據,需求管理（差距分析&現狀）,現狀： 優勢： 不足：,Copyright 2004-2014上海翰緯,16,議程/ Agenda,Copyright 2004-2014上海翰緯,17,概念準備 實際案例 XX銀行需求管理流程現狀 流程活動和流程角色設計 管理策略研討 總結與課後作業安排 附錄：理論依據,對需求的處理將遵循以下執行途徑,提交需求： （1）需求來源：業務部門 關閉事件： （1）一般有手動關閉和自動關閉兩種方式； （2）採用首問負責制，一般應集中由服務台（一線）工作人員關

12、閉，如有特殊需求可由需求經理關閉。,Copyright 2004-2014上海翰緯,18,需求管理流程活動,根據實際業務需求提出需求申請交至服務台； 記錄需求申請，並創建和分派需求申請單；,受理技術需求； 判定需求信息是否充足； 技術需求分析和建模，並編寫業務需求說明書； 創建變更申請；,業務需求內部評審和提交,技術需求受理分析和評審確認,變更管理 評審,分析評審變更申請進，並反饋變更相關情況； 記錄更新需求評審結果，並反饋結果；,需求 關閉,與用戶驗證結果，徵求用戶同意關閉事件 根據知識管理流程決定是否需要進行更新知識庫 關閉事件，設定適當的關閉代碼,受理業務需求； 判定需求信息是否充分；

13、業務需求分析和建模，並編寫業務需求說明書； 業務需求可行性評審； 記錄需求評審結果；,業務需求受理分析和評審確認,Copyright 2004-2014上海翰緯,19,需求管理與其他流程的關係,Copyright 2004-2014上海翰緯,20,需求管理流程角色,Copyright 2004-2014上海翰緯,21,需求管理流程角色匹配,Copyright 2004-2014上海翰緯,22,議程/ Agenda,Copyright 2004-2014上海翰緯,23,概念準備 實際案例 XX銀行需求管理流程現狀 流程活動和流程角色設計 管理策略研討 總結與課後作業安排 附錄：理論依據,需求管理

14、流程的流程原則,業務部門與信息科技部、支持保障部應本著團結、協作的原則在信息技術服務需求的全生命週期內保持充分溝通。 需求的生命週期包括：需求提交、需求分析、需求審核、需求開發、需求測試、需求驗證和需求上線。流程執行應遵循以下原則： 需求的提交與分析遵循需求管理流程。 需求審核分為以下兩種情況： 如需立項審批應遵循公司立項和招投標相關規定； 其他情況遵循變更管理流程的變更策略。 需求開發、測試、驗證和上線在發佈和部署管理流程中實現，並遵循流程中發佈和部署的相關策略。,Copyright 2004-2014上海翰緯,24,需求單的責任人策略,責任人策略用來確保每個需求在任何時段都有適當的人員來負

15、責，從而保證需求處理的及時性和有效性，確保需求的處理能夠得到及時跟蹤和協調。 事件單的責任人策略 當一個需求被創建後，事件需求受理員負責這個需求單，其負責跟蹤需求處理的進展直至最終的解決； 當需求單被分派後，需求經理員負責此需求單，但是分派方（需求受理員）有責任通知被分派的需求經理，需求經理協調需求分析員完成需求分析和建模工作； 需求單被需求經理接受之後，需求經理對該單負責；,Copyright 2004-2014上海翰緯,25,議程/ Agenda,Copyright 2004-2014上海翰緯,26,概念準備 實際案例 XX銀行需求管理流程現狀 流程活動和流程角色設計 管理策略研討 總結與

16、課後作業安排 附錄：理論依據,需求管理流程總結,Copyright 2004-2014上海翰緯,27,需求管理是服務管理非常重要的一個方面。如果對客戶的服務需求缺乏充分的需求管理，則需求的不確定性就會成為服務提供者的一個主要風險來源。 需求管理的流程核心是需求來源於業務部門，需求提交後由服務台開單，經過需求和技術需求分析建模和評審，交由變更管理評審，最終由服務台關單。,需求管理流程課後作業,對今天現場討論未達成一致的管理流程、角色匹配、管理策略等，翰緯會根據需要提供作業範本和其他實例參考，XX銀行各團隊需參考翰緯給出的範例和範本，制定自己的管理策略。,Copyright 2004-2014上海翰緯,28,議程/ Agenda,Copyright 2004-2014上海翰緯,29,概念準備 實際案例 XX銀行需求管理流程現狀 流程活動和流程角色設計 管理策略研討 總結與課後作業安排 附錄：理論依據,ITIL V3 Strategy Service：Demand Management業務活動模式,Copyright 2004-2014上海翰緯,30,業務活動影響服務需求模式（來源：OGC）