1、中 國 聯(lián) 通 需 求 管 理 實 施方法和工具王 穎二零零七年四月二十八日背景 需求管理是IT部門一直在做的工作，大家在一線工作中積累了豐富的經驗。當前在信息系統(tǒng)越來越成為企業(yè)的神經中樞的時候，無論IT部門還是業(yè)務部門都對需求管理的價值有了新的認識?？偛繌娜ツ觊_始，在需求管理方面進行了新的嘗試，并逐漸摸索出一套適合于電信企業(yè)支撐系統(tǒng)的需求管理的工作方法。 2007年初，為了提升需求管理的水平、促進需求管理的標準化、提高需求管理效率，購置了一套成熟的管理工具。在實施過程中，引入了專業(yè)的需求管理專家，系統(tǒng)的梳理了聯(lián)通的需求管理的整個文檔體系，并進行了完善和標準化。 本次課程內容即建立在上述工作的

2、根底上。 課程目的理解和掌握聯(lián)通需求管理的文檔體系及其相互關系明確省分需要編制的文檔和要求理解和掌握需求規(guī)格書的內容和編制方法熟悉主要文檔之間的追蹤關系了解如何使用工具來支持需求管理工作課程大綱中國聯(lián)通需求管理文檔體系用戶需求書的主要內容和編制方法系統(tǒng)需求規(guī)格書的主要內容和編制方法需求文檔與設計、測試文檔之間的追蹤關系需求管理系統(tǒng)介紹和演示系統(tǒng)需求用戶需求書滿足工程管理滿足廠商設計(n個)測試計劃集成商測試結果(n個)驗證產品測試用例安排執(zhí)行初驗文檔終驗文檔上線文檔驗證中國聯(lián)通需求管理文檔體系31省分補充需求規(guī)格說明書全國統(tǒng)一需求規(guī)格說明書補充標準規(guī)范指標體系指導和約束各項文檔的管理主體文檔類

3、型責任方參與方評審/審核方用戶需求書總部市場部總部、省分業(yè)務部門信息化部總部、省分業(yè)務部門信息化部全國統(tǒng)一需求規(guī)格說明書總部信息化部省分信息化部總部、省分業(yè)務部門總部、省分信息化部總部業(yè)務部門省分補充需求規(guī)格說明書省分信息化部省分業(yè)務部門總部信息化部產品測試相關文檔總部信息化部省分信息化部總部信息化部工程相關文檔省分信息化部集成商總部信息化部標準規(guī)范總部信息化部省分信息化部集成商總部信息化部指標體系總部信息化部總部業(yè)務部門總部信息化部總部業(yè)務部門設計文檔集成商省分信息化部總部、省分信息化部軟件需求層次 業(yè)務需求 用戶需求軟件需求分不同的層次和階段：業(yè)務需求、用戶需求和系統(tǒng)需求 需求分析人員進行

4、需求開發(fā)用戶語言轉換成技術語言功能性需求非功能性需求環(huán)境和約束文檔體系和軟件需求層次的對應關系用戶需求書 系統(tǒng)功能需求系統(tǒng)需求規(guī)格說明書課程大綱中國聯(lián)通需求管理文檔體系用戶需求書的主要內容和編制方法系統(tǒng)需求規(guī)格書的主要內容和編制方法需求文檔與設計、測試文檔之間的追蹤關系需求管理系統(tǒng)介紹和演示現(xiàn)有用戶需求書情況總部市場部組織編制了新一代BSS系統(tǒng)用戶需求書20冊現(xiàn)有用戶需求書的內容要素：名稱及屬性 目標及作用 內容/功能描述 收費結算 業(yè)務受理要求 權限及范圍 界面要求 數(shù)據(jù)要素風險控制 用戶需求書內容要素用戶需求書功能性需求非功能性需求性能要求易用性要求安全性要求其他業(yè)務描述業(yè)務目標和作用業(yè)務

5、流程及描述業(yè)務權限及范圍用戶界面要求內控要求業(yè)務數(shù)據(jù)定義對業(yè)務本身的介紹和描述該項需求支持哪些業(yè)務上的目標需求需要支持的詳細業(yè)務流程及描述該項業(yè)務向哪些角色/人員開放權限與該項業(yè)務相關的內控要求是什么？對于用戶界面有何具體要求？（可選）業(yè)務數(shù)據(jù)定義、業(yè)務數(shù)據(jù)與流程的關系4 業(yè)務數(shù)據(jù)匯總用戶需求書模板樣例流程描述要求：圖形與文字相結合 圖形描述：使用泳道圖 文字描述：逐個描述流程步驟 步驟任務 步驟中涉及的業(yè)務角色 步驟中涉及的業(yè)務規(guī)則 步驟中涉及的業(yè)務數(shù)據(jù)新的用戶需求書模板對于現(xiàn)有用戶需求書的完善專注于問題域：在用戶需求書中以業(yè)務為主進行描述，專注于把業(yè)務講清楚使業(yè)務人員將精力放到研究業(yè)務本身

6、，而不是研究解決方案，降低業(yè)務人員的理解和編寫難度不限制系統(tǒng)實現(xiàn)，使設計人員可以采用更加適合的方法來解決業(yè)務問題對于編寫的標準化程度提出更高的要求：對于流程的詳細程度和編寫標準提出了具體要求，作為編寫人員共同遵守的標準，有利于文檔質量的管理，防止不同組并行時文檔質量、風格參差不齊增加業(yè)務數(shù)據(jù)匯總表業(yè)務數(shù)據(jù)字典:將用戶需求書中的所有業(yè)務數(shù)據(jù)都匯總到統(tǒng)一的表格中進行管理，并與業(yè)務流程進行關聯(lián)有利于保持業(yè)務數(shù)據(jù)的一致性，防止互相的沖突與重復定義用戶需求書的標準化屬性名稱取值需求編號用DOORS系統(tǒng)定義的ID（可自動維護） 是否需求點是,否需求狀態(tài)新創(chuàng)建、已變更、已接受、需澄清、已拒絕、重復、已規(guī)劃、

7、已開發(fā)、已取消、已上線 反饋意見分類枚舉類型取值：需求定義重復，需求功能點定義模糊，需求功能點無法測試，等多值反饋意見描述取值：文字描述 需求來源總部或省份實施階段一期，二期，。需求優(yōu)先級 高、中、低 統(tǒng)一程度功能，流程，數(shù)據(jù)，規(guī)則需求聯(lián)系人上線省分總部+31省，多選屬性 管理粒度：最細一級業(yè)務需求 屬性定義：針對每個需求點定義詳細的屬性，具體見右側表格。 權限定義：總部市場部人員：文檔正文的所有權限總部信息化部人員：文檔正文的讀取權限、屬性的修改權限分公司、廠商人員：讀取權限課程大綱中國聯(lián)通需求管理文檔體系用戶需求書的主要內容和編制方法系統(tǒng)需求規(guī)格書的主要內容和編制方法系統(tǒng)需求規(guī)格書的構成用

8、例方法介紹系統(tǒng)需求規(guī)格書模板樣例需求文檔與設計、測試文檔之間的追蹤關系需求管理系統(tǒng)介紹和演示系統(tǒng)需求規(guī)格書的構成和描述方法省分BSS系統(tǒng)需求規(guī)格書全國統(tǒng)一需求規(guī)格書省分補充需求規(guī)格書統(tǒng)一功能性需求統(tǒng)計查詢除外統(tǒng)一非功能性需求補充功能性需求統(tǒng)計查詢局部、統(tǒng)一需求擴展局部補充非功能性需求環(huán)境和約束接口、替代系統(tǒng)統(tǒng)一接口需求用例方法用例方法條目化語言描述條目化語言描述條目化語言描述條目化語言描述 以BSS系統(tǒng)為例，省分BSS系統(tǒng)的需求規(guī)格說明書由兩局部組成。其中對于核心的功能要求，全部在全國的統(tǒng)一需求規(guī)格書中定義，對于允許省分擴展的局部，在省分補充需求規(guī)格書中定義。 無論是全國統(tǒng)一需求還是省分補充需

9、求，都要遵循相同的需求編制方法。全國統(tǒng)一需求與省分補充需求之間的關系例如 擴展擴展全國統(tǒng)一需求規(guī)格說明書31個省份省分A省分 B第n用例A省對該用例進行了擴展B省沒有對該用例進行擴展 根據(jù)總部統(tǒng)一需求規(guī)格書中統(tǒng)一管理程度的要求，省分對于一些需求可以進行擴展、細化和補充。這些省分的細化和補充需求統(tǒng)一納入到總部的管理范圍，與總部統(tǒng)一需求建立關聯(lián)關系，作為統(tǒng)一版本由總部進行發(fā)布。用例方法主要建模元素用例Use Case:用例用于表示系統(tǒng)所提供的效勞，它定義了系統(tǒng)是如何被參與者所使用的，它描述的是參與者為了使用系統(tǒng)所提供的某一完整功能而與系統(tǒng)之間發(fā)生的一段對話。參與者Actor:參與者是指存在于被定義

10、系統(tǒng)外部并與該系統(tǒng)發(fā)生交互的人或其他系統(tǒng)，他們代表的是系統(tǒng)的使用者或使用環(huán)境。事件流Event flow：對用例的具體描述是通過事件流來詳細進行說明的。事件流反映了系統(tǒng)的使用者期望與系統(tǒng)交互的流程，事件流又分為根本流系統(tǒng)正常使用下的流程和備選流系統(tǒng)在特定情況下的分支流，根本流和備選流的組合反映了系統(tǒng)在使用過程中的真實場景。前置條件：執(zhí)行用例前，系統(tǒng)所處的狀態(tài)。后置條件：執(zhí)行用例之后，系統(tǒng)所處的狀態(tài)。用例描述樣例參與者事件流用例方法的特點和優(yōu)勢用例具有以下的特點優(yōu)點：給出了需求的上下文：誰使用，在什么條件下使用，如何使用。容易理解：盡量采用用戶理解的語言。易于重用：是設計、測試及系統(tǒng)相關文檔的根

11、底。編寫用例的步驟第一步：發(fā)現(xiàn)用例，通過對業(yè)務進行分析，提取系統(tǒng)所要完成的“事務性的功能，并形成用例。第二步：簡要描述，對該用例所要完成的功能進行簡要描述。第三步：編寫用例大綱，概括出系統(tǒng)處理的主要步驟根本流，并進行編號。第四步：細化用例。針對根本流中的主要步驟，采用參與者與系統(tǒng)交互的語言進行詳細描述，并增加備選流、前后置條件、特殊需求等。用例方法介紹-發(fā)現(xiàn)參與者系統(tǒng)的參與者定義了系統(tǒng)的邊界，可從以下幾方面發(fā)現(xiàn)系統(tǒng)的參與者：誰使用系統(tǒng)？誰從系統(tǒng)獲取信息？誰向系統(tǒng)提供信息？系統(tǒng)在什么地方使用？誰支持或維護系統(tǒng)？有沒有其它的系統(tǒng)使用該系統(tǒng)？用例方法介紹-識別用例從參與者的角度出發(fā)發(fā)現(xiàn)用例，以下問題

12、有助于發(fā)現(xiàn)用例：參與者希望怎樣使用該系統(tǒng)？參與者希望創(chuàng)立、存儲、修改、刪除系統(tǒng)的數(shù)據(jù)嗎？當外部事件發(fā)生變化時，參與者需要通知系統(tǒng)嗎？參與者希望被告知系統(tǒng)內部發(fā)生的變化嗎？識別參與者和用例舉例定義用例根本流和備選流根本流與備選流：根本流是該用例的一個主要的使用場景，一個用例只有一個根本流。備選流是在根本流之上的有條件的分支，備選流結束后，要么該回到根本流，要么導致該用例結束。定義用例根本流和備選流編寫用例綱要步驟編寫用例流程步驟要點：列出根本流的主要處理步驟。對根本流的處理步驟進行編號。列出可能的備選流。定義用例場景Scenario 場景是指從流程的起點開始，直到某個終點的一串流程。細化用例細化

13、根本流細化根本流要點：采用參與者與系統(tǒng)交互的語言進行描述。參與者與系統(tǒng)交互的行為要明確，包括交互的信息數(shù)據(jù)，系統(tǒng)處理所要遵守的業(yè)務規(guī)那么，系統(tǒng)處理過程中與其它系統(tǒng)的接口，當然，數(shù)據(jù)、規(guī)那么、接口如果有地方統(tǒng)一描述的話，引用即可。細化用例細化備選流細化備選流要點：起始位置：寫明備選流在根本流中的起始位置條件：寫明分支的條件。動作：通過交互式語言寫明備選流處理的動作?；謴停簜溥x流結束后要么回到根本流的某一步，要么導致用例終止。注：異常流也可視為一種特殊的備選流細化用例-前置/后置條件前置條件是執(zhí)行用例之間系統(tǒng)必須存在的一組狀態(tài)，注意：前置條件不是觸發(fā)該用例的事件。前置條件有助于減少事件流描述中的一

14、些校驗。前置條件不描述系統(tǒng)之外的事情，如“客戶有一個有效的SIM卡。前置是可選的。僅在需要時描述。后置條件是用例一執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài) ：后置條件也是可選的，僅在需要時描述。根本流、備選流描述樣例根本流、備選流描述樣例用例描述樣例9. 后置條件訂單生成，待訂單處理生成定單。 細化用例要點總結描述對參與者可見的事件參與者做什么，系統(tǒng)做什么。用例必須提供參與者可見的結果。用例有不同的精細程度，細化到所有涉眾對需求有共同的理解為止。采用公用的術語和詞匯。使用明確的語言?；诼?lián)通需求 豐富用例方法豐富事件流的描述方法，細化區(qū)分：系統(tǒng)功能需求系統(tǒng)的數(shù)據(jù)處理需求：展現(xiàn)數(shù)據(jù)、存儲數(shù)據(jù)系統(tǒng)要處理的

15、業(yè)務規(guī)那么將后臺處理需求統(tǒng)一到用例描述中使用與事件流相似的方式描述后臺處理流程對于每個處理步驟，細化區(qū)分：功能輸入數(shù)據(jù)輸出數(shù)據(jù)業(yè)務規(guī)那么用例描述樣例結構化用例描述用例之間的關系：包含關系include:根底用例會用到被包含的用例；也就是被包含的用例的事件流一定會插入到根底用例的事件流中。擴展關系extend:根底用例(Base)中定義有一至多個已命名的擴展點，擴展關系是指將擴展用例(Extension)的事件流在一定的條件下按照相應的擴展點插入到根底用例(Base)中 ，擴展用例的事件流會被有條件地引用。參與者之間的關系：參與者的繼承總部/省分統(tǒng)一需求規(guī)格書文檔結構業(yè)務資源管理用例1用例n客戶

16、問題管理用例1用例n全國統(tǒng)一需求規(guī)格說明書主文檔樣例總部統(tǒng)一需求規(guī)格書的標準化 管理粒度：作為跟蹤、管理的最小單位 功能性需求：需求用例說明； 非功能性需求：描述條目 屬性定義：針對每個需求點定義詳細的屬性，具體見右側表格。 權限定義： 總部市場部人員：文檔正文的讀取權限 總部信息化部需求分析人員：文檔所有權限 分公司、廠商人員：讀取權限屬性取值需求狀態(tài)新創(chuàng)建、已變更、審核通過、已發(fā)布、已取消、已上線 審核意見分類通過、不通過審核意見描述取值：文字描述實施階段一期、二期需求類型枚舉類型取值：功能性需求、非功能性需求、非需求需求負責人 需求編寫人 統(tǒng)一管理程度統(tǒng)一需求、推薦需求、補充需求功能統(tǒng)一

17、程度統(tǒng)一要求、不統(tǒng)一要求流程統(tǒng)一程度所有流程、僅正常流程、不統(tǒng)一要求規(guī)則統(tǒng)一程度配置、僅列舉、不統(tǒng)一要求數(shù)據(jù)統(tǒng)一程度統(tǒng)一要求、不統(tǒng)一要求省分需求規(guī)格書主文檔樣例省分需求規(guī)格書的標準化 管理粒度：需求用例說明； 屬性定義：針對每個需求點定義詳細的屬性，具體見右側表格。 權限定義：總部信息化部需求分析人員：文檔讀取權限、局部屬性修改權限所屬分公司：讀、寫、修改權限所屬分公司實施廠商：讀取權限屬性取值需求狀態(tài)新創(chuàng)建、已變更、審核通過、已發(fā)布、已取消、已上線 總部審核結果通過、未通過審核意見描述取值：文字描述統(tǒng)一管理類型全國統(tǒng)一需求、總部推薦需求、省分新增需求、省分補充需求流程是否擴展是/否流程擴展說

18、明 文字描述規(guī)則是否擴展是/否規(guī)則擴展說明 文字描述數(shù)據(jù)是否擴展是/否數(shù)據(jù)擴展說明 文字描述需求編寫人需求負責人課程大綱中國聯(lián)通需求管理文檔體系用戶需求書的主要內容和編制方法系統(tǒng)需求規(guī)格書的主要內容和編制方法需求文檔與設計、測試文檔之間的追蹤關系需求管理系統(tǒng)介紹和演示擴展總部統(tǒng)一需求實施省1補充需求既要滿足總部統(tǒng)一需求，也要滿足實施省分的補充需求 滿足滿足某廠商的設計文檔需求規(guī)格書與設計文檔的關系 每個廠商提交統(tǒng)一的設計文檔，既要滿足總部統(tǒng)一需求，也要滿足所實施省分的補充需求。但是要作為一個統(tǒng)一的版本進行維護。實施省2補充需求擴展總部統(tǒng)一需求用例需求規(guī)格書與產品測試文檔的管理 產品功能測試用例

19、以總部統(tǒng)一需求規(guī)格書作為依據(jù)，對于每項需求，對應到測試用例文檔。根據(jù)每次測試的實際情況，可以對測試用例文檔進行篩選，形成每輪測試的測試方案，針對每家廠商執(zhí)行測試后，形成測試報告。由于測試可以進行多輪，因此測試方案和測試報可以有多套存在。安排測試用例母板驗證執(zhí)行測試方案1測試報告廠家1測試報告廠家2執(zhí)行執(zhí)行測試方案2執(zhí)行測試報告廠家1測試報告廠家2安排第一輪測試第二輪測試課程大綱中國聯(lián)通需求管理文檔體系用戶需求書的主要內容和編制方法系統(tǒng)需求規(guī)格書的主要內容和編制方法需求文檔與設計、測試文檔之間的追蹤關系需求管理系統(tǒng)介紹和演示總體架構主要功能實施方案系統(tǒng)演示需求管理系統(tǒng)總體架構需求決策需求分析需求開發(fā)系統(tǒng)驗收系統(tǒng)維護需求啟動測試用戶需求需求規(guī)格設計測試用例文檔模板文檔模板文檔模板DOORS軟件文檔管理測試計劃原始需求Synergy/CM代碼/