搜索
需求管理流程研討目的瞭解需求管理流程的基本概念、實際案例；討論並確定需求管理流程的主要活動及其之間的關聯；確定需求管理流程的典型角色及其與主要活動之間的匹配情況；討論並確認需求管理流程執行策略並收集相關建議。Copyright@2004-2014上海翰緯1主要關注點需要確定的關注點：•支保部的定位？•需求管理流程的管理對象和範圍？•需求管理的生命週期長度？開發前還是上線投產？•流程的角色設置和職責•流程各角色的工作界面和溝通接口目標：需求管理恰如裁縫的量體裁衣，它直接關係到最終產品的成型。僅從字面出發，如果一個產品滿足了客戶需求，那它無疑就是成功的。需求管理的過程，從需求分析開始貫穿整個項目始終，力圖實現最終產品同需求性的最佳結合。需求管理能夠確證：•我們確知客戶的需求是什麼（質量）；•滿足客戶需求的最佳解決辦法（統一性）；Copyright@2004-2014上海翰緯2議程/AgendaCopyright@2004-2014上海翰緯3概念準備實際案例XX銀行需求管理流程現狀流程活動和流程角色設計管理策略研討總結與課後作業安排附錄：理論依據需求管理-基礎目的：確保服務資源的生產能力和需求預測及模式保持一致；確保資源能力可以在需要時有效使用，在不使用時及時釋放關鍵字：業務分析服務組合資源容量如何滿足“適”：前提條件：已受理需求申請考慮要素：需求分析、需求評審、需求驗證、需求確認過程目的減小需求的不確定性提供充分需求估計和規劃，保證產品和需求的一致性減少因過度冗餘而導致閒置容量的額外成本無法得到有效的回收鞏固與提升客戶與使用者滿意度便於需求支持資源的合理配備與使用過程價值定義是指理解並影響客戶對服務的需求以及提供相應容量以滿足這些需求的活動；術語信息技術服務需求：指業務部門以及最終用戶對信息技術服務的需求。新增服務：按照業務部門或公司統一規劃（或備案）確定的、滿足用戶和業務需求的新增信息技術服務，這些服務未列入已發佈的服務目錄。服務功能的變更：該服務已經上線運行，並且已列入部已發佈的服務目錄，現階段主要以功能完善、修復Bug為主，通過立項續建來實現大版本升級。說明觸發條件：業務需求；過程模式：主動式的管理過程；過程特點：適，統一，一致過程概述Copyright@2004-2014上海翰緯4適需求管理流程的主要活動概述（一）•需求開發–需求調研：•問卷•訪談•場景模擬–需求建模和分析，可利用以下工具進行：•UML•RationalRose(RationalSoftwareArchitect)•PowerDesigner•VISIO–輸出需求定義（需求規格說明書）或需求定義說明書•需求定義的確認：–確認有兩層含義：•首先是需求調查與分析人員與客戶間通過溝通，剔除或修訂對需求理解不一致的部分；•另外一個層面的意思是指，雙方對於已達成共同理解或獲得客戶/用戶認可的部分進行承諾。Copyright@2004-2014上海翰纬5需求管理流程的主要活動概述（二）•建立並識別需求狀態和跟蹤機制–需求狀態是指用戶需求的一種狀態變換過程–進行需求調研時，客戶對需求的描述可能有多種：•客戶可以明確且清楚的提出的需求；•客戶知道需要做些什麼，但又不能確定的需求；•客戶本身可以得出這類需求，但需求的業務不明確，還需要等待外部信息•客戶本身也說不清楚–對於這些需求，在需求開發的過程中，存在著以下幾種情況:•有可能要取消的•因為不明確而可以後延的，同時可能轉化為被取消的需求•與客戶經過溝通或確認的，此處有兩種情況，一類是確認雙方達成共識，另一種情況是還需要再進一步溝通的。–建立狀態追蹤機制：如狀態追蹤矩陣–狀態示例：•待確認：客戶提出需求，但雙方沒有經過溝通或確認；•已確認：經過確認，雙方認可並達成共識；•未能確認:雙方經過確認，但沒有達成共識的需求；Copyright@2004-2014上海翰纬6需求管理流程的主要活動概述（三）•技術解決方案設計–技術需求分析和建模–根據業務需求規格說明書或業務需求定義說明書和建模分析結果編制技術需求規格說明書–評審確認技術需求–開發技術解決方案：•定義產品或服務組件以滿足需求•定義組件的關係和接口•明確組件的開發或獲取方式：內部完成還是採購•有條件時，可能有多套方案供評審決策•需求評審和確認–預審核：在進行正式評審前，需要有人員對其要進行評審的對象進行把關，確認其是否具備進入評審的初步條件。–正式評審中評判需求優劣的主要指標有：正確性、清晰性、無二義性、一致性、必要性、完整性、可實現性、可驗證性、可測性。–如果有可能，應制定預審核的送審材料清單和正式審核的檢查項清單。Copyright@2004-2014上海翰纬7需求管理流程的主要活動概述（四）•產品開發與集成–不在需求管理中討論•需求跟蹤–進行需求跟蹤的目的是為了建立和維護從用戶需求開始到測試之間的一致性與完整性。確保所有的實現是以用戶需求為基礎。對於需求實現是否全部的覆蓋。同時確保所有的輸出與用戶需求的符合性。–正向跟蹤：以用戶需求為切入點，檢查《用戶需求說明書》或《需求規格說明書》中的每個需求是否都能在後繼工作產品中找到對應點。–逆向跟蹤：檢查設計文檔、代碼、測試用例等工作產品是否都能在《需求規格說明書》中找到出處。Copyright@2004-2014上海翰纬8需求管理流程的主要活動概述（五）•需求變更控制–需求變更通常會對產品開發和集成的進度、投入人力資源產生很大的影響，這是必須面臨與需要處理的問題。–需求發生變更的起因主要有：•隨著項目生命週期的不斷往前推進，人們（包括開發方和客戶方）對需求的瞭解越來越深入，發現原先的提出的需求可能存在著一定的缺陷，因此要變更需求。•市場業務需求發生了變化，原先的需求可能跟不上當前的市場業務發展，因此要變更需求。–需求的變更則意味著要需要重新進行估計，調整資源、重新分配任務、修改前期工作產品等，而作為開發者，需要增加預算與投資，開發組要為此付出較重的代價。–需求變更控制的動機是：•如果需求變更帶來的好處大於壞處，那麼允許變更，但必須按照已定義的變更規程執行，以免變更失去控制。•如果需求變更帶來的壞處大於好處，那麼拒絕變更。•由於需求文檔是重要的配置項，需求的變更應當遵循相關的變更管理程序。Copyright@2004-2014上海翰纬9議程/AgendaCopyright@2004-2014上海翰緯10概念準備實際案例XX銀行需求管理流程現狀流程活動和流程角色設計管理策略研討總結與課後作業安排附錄：理論依據案例1：某電力局信息系統需求管理流程部门业务参与者职责说明备注最高管理层局领导系统使用者，可以使用系统、对信息系统提出需求、等待需求处理完毕、评价需求处理结果。除局领导和RA本身外的所有系统使用者（包括不担任RA的部门领导）提出的需求都必须先通过部门内审核然后进入需求评审委员会评审流程。信息需求评审委员会为保证需求管理的有效运作，特成立信息需求评审委员会，下设业务专家组和信息专家组。业务专家组负责业务评审，信息专家组负责信息技术评审。普通使用部门基层人员及一般管理人员系统使用者，可以使用系统、对信息系统提出需求、等待需求处理完毕、评价需求处理结果。部门领导RARA是部门内需求审核人，RA由人事部发文指定，每个部门可以有一个或多个RA。业务归口管理部门基层人员及一般管理人员系统使用者，可以使用系统、对信息系统提出需求、等待需求处理完毕、评价需求处理结果。部门领导RARA是部门内需求审核人，RA由人事部发文指定，每个部门可以有一个或多个RA。业务专家组信息需求评审委员会中指定的业务专家组负责对需求进行业务评审。业务专家组按照业务条线分为若干小组，按照需求评审委员会的规划，每个信息系统都有其对应的业务专家组，在相应信息系统出现需求变更和问题反馈时执行需求业务评审工作。信息部基层人员及一般管理人员系统使用者，可以使用系统、对信息系统提出需求、等待需求处理完毕、评价需求处理结果。部门领导RARA是部门内需求审核人，RA由人事部发文指定，每个部门可以有一个或多个RA。业务专家组信息需求评审委员会中指定的业务专家组负责对需求进行业务评审。部分业务的归口管理部门是信息部。信息专家组需求评审委员会中指定的信息专家组负责对需求进行信息技术评审。信息专家组分为信息系统组、SOA集成组、信息安全组、厂商组等。信息专家组中的信息系统组由多个下属小组组成，每个下属小组对应一个信息系统。所有针对信息系统提出的需求都会先由信息系统组下属小组接收处理，由下属小组决定是否发起与其他几个信息专家组的会签。信息系统负责人信息部为每个信息系统指定一个信息系统负责人，信息系统负责人保证系统正常运行、处理跟进系统改造。Copyright@2004-2014上海翰纬11案例1：Copyright@2004-2014上海翰纬12需求管理全过程闭环机制系统使用者开始提出需求需求提出信息模型是否RARARA审核流程RA审核单RA审核需求信息RA审核信息模型是否需求评审委员会业务评审流程信息系统负责人基础配置数据业务评审需求信息业务评审单业务评审信息模型备选库是是否通过否是否通过是否跟进处理需求处理完毕跟进处理需求信息跟进处理需求信息是填写问题类型跟进处理单、跟进处理工作日志指定辅助评价人需求管理系统处理结果评价备选需求信息需求提出信息需求采集单渠道包括1600、电话、短信、OA、门户论坛、各系统需求提交模块、局内QQ等。无论通过什么渠道采集到的需求，都必须进入需求管理中心系统备审。备审的需求先由信息系统负责人筛选判别是否在需求管理中心进行管理从基础配置获取数据驱动需求评审信息评审信息模型信息技术评审流程信息技术评审需求信息是否通过是否信息技术评审单除局领导和RA本身外的所有系统使用者（包括不担任RA的部门领导）提出的需求都必须先通过RA审核从基础配置获取数据驱动需求跟进处理评审工作由业务组和信息组进行，业务组和信息组根据信息系统从基础配置获取，基础配置中的评审期限可用于督促及时评审否结果评价需求信息待处理需求信息辅助评价人在需求跟进处理完毕后由信息系统负责人从人力资源组织机构人员中选定一般选择与需求提出者的同级或上级进行评价结束短信通知需求提出者和辅助评价人评价需求处理结果跟进处理工作由信息系统负责人执行，信息系统负责人从基础配置获取短信通知需求提出者需求在哪个环节未被采纳是否省公司统筹需求待实现需求库省公司统筹需求库否是案例2：某軟件開發商需求管理流程角色职责能力要求备注客户/最终用户被邀请参与《软件需求规格说明书》的评审；参与并确认客户需求的定义。项目经理参与《软件需求规格说明书》的评审；建立并维护本项目的需求跟踪矩阵，跟踪需求负责接收《需求变更申请表》，组织需求变更活动的开展；定义需求状态类型；分析需求跟踪状态结果；接受需求变更、需求状态类别确定的培训高级经理参与《软件需求规格说明书》的评审批准软件需求规格说明书评审报告项目组成员协助项目经理定义客户原始需求或需求协助项目经理编写软件需求规格说明书负责不同阶段的需求跟踪矩阵内容（素材）的更新、分析、再利用负责变更的需求的修改；测试人员参与《软件需求规格说明书》的评审；负责不同阶段的跟踪矩阵内容（素材）的更新、分析、再利用配置管理人员参与《软件需求规格说明书》的评审；负责将需求基线纳入配置管理；并在需求基线的变更过程中，记录变更状态；发布变更和基线；更新需求基线；统计需求变更总数；接受需求变更、需求状态表填写、需求状态图绘制的培训质量保证人员参与《软件需求规格说明书》的评审；检查《需求跟踪矩阵》的填写，协助项目经理分析需求跟踪状态结果Copyright@2004-2014上海翰纬13案例2：某軟件開發商需求管理流程Copyright@2004-2014上海翰纬14需求管理（REQM）需求定义需求跟踪需求状态跟踪需求变更需求分析人员项目经理质量保证人员输出输入用户需求说明书（或用户原始需求）分析细化用户需求编写软件需求规格说