用CMMI指導需求管理

能力成熟度模型集成（CMMI，Capability Maturity Model Integration）已逐步成為IT業的標準。CMMI定義了5個組織成熟度級別，包含25個過程域（PA,Process Area），這些過程域全面涵蓋了軟件生命周期的各個領域。特別是在業界普遍感到難以控制的需求方面，它定義了兩個過程域：需求管理和需求開發。

需求管理（REQM,Requirements Management）屬于成熟度2級（受管理級）的過程域，是其他許多過程域實施的前提。對于暫未實施CMMI的企業，同樣也可以借鑒CMMI的原則，實施和優化需求管理。本文從實際工作的角度，闡述如何用CMMI指導需求管理工作。

一、需求管理概述

許多IT企業都有過需求失控的痛苦經歷，我們不難體會，沒有好的需求管理會給我們帶來什么：

    需求以失控的狀態進入軟件過程，從源頭上失去了項目的質量保證；

    需求范圍界定不清，使項目缺乏計劃性，導致成本、研制周期失控；

    需求變更失控，使組織處于被動反應式的環境中，項目組成為救火隊；

    需求管理不當，導致項目延期、士氣低落，增加了項目的失敗風險；

    ……

為了避免上述情況的出現，CMMI對需求管理提出了明確的目的：一是管理項目的產品和產品構件的需求；二是標識哪些需求與項目計劃及工作產品之間不一致。通過適當的步驟，確保需求在項目的各個層面上動態地保持一致，一旦出現不一致，則啟動相關的處理過程域，使其調整到一致。

需求管理包含5個特定實踐（SP,Specific Practice），這5個特定實踐的關系如圖1所示。

獲得對需求的理解。需求接收者與需求提供者就需求達成共識。 獲取項目參與者對需求的承諾。通過書面承諾，建立各方、各項工作的基準。 管理需求變更。維護變更歷史，為調整與控制提供數據。 維護對需求的雙向可追溯性。這是從軟件的可維護性角度提出的管理要求。 標識項目計劃和工作產品與需求的不一致性。旨在發現不一致性，并且啟動糾正措施。

二、需求管理計劃

在組織級建立需求管理計劃模板，具體項目則是在此模板的基礎上結合項目的特點和具體情況，制定項目的需求管理計劃。

需求管理計劃（模板）應包括如下內容：

需求管理的方針與政策； 需求管理需使用的資源（管理人員、計算機資源、使用工具等）； 角色與責任； 培訓計劃； 需求管理的干系人及介入事件的關聯矩陣； 配合項目節奏或里程碑的事項（如：在哪些階段點應做“識別項目工作與需求之間的不一致的工作”）； 判斷項目工作與需求不一致的準則和糾正流程； 需求溯源性矩陣模板（最好使用工具）； 需求變更流程； 需求管理計劃的審批與變更流程； 其他流程。

具體項目的需求管理計劃一般應在如下幾個方面加以具體化：①項目的需求管理角色應分派到具體的人；②可根據項目需求管理人員的實際情況，安排有針對性的培訓內容，如應用領域的業務培訓、需求管理工具的培訓等；③需求管理的干系人及介入事件更加明確。如與需求管理相關的人員（干系人）主要有業務代表（代表業務需求提出部門）、設計人員、開發人員、測試人員等，當需求具有跨系統或接口性質時，相關受影響的部門應列入干系人清單中。介入的事件是評估需求變更的影響、通報雙向溯源性情況、識別項目工作與需求之間的不一致。

三、需求管理流程

各企業可根據自己的組織結構制定需求管理流程，但流程必須涵蓋上述5個特定實踐，對于具體項目一般應用組織級的需求管理流程，項目的特殊事項可以放在需求管理計劃中進行描述。

需求管理流程可以由幾個子流程組成，有些子流程可以并行工作，有些子流程還與其他過程域的流程有關。

首先，“獲得對需求的理解”和“獲取項目參與者對需求的承諾”兩個特定實踐可以放到一個流程中實施。將實際流程圖進行簡化（見圖2），可以看出：
①通過一個綜合流程可將多個特定實踐包含其中。同時，還可以看出需求管理過程域與其他過程域（配置管理、技術開發、項目策劃）相關聯。
②“獲得對需求的理解”要求明確需求的正式來源（總行業務部門）。
③“獲得對需求的理解”實際上是進行需求分析、確認需求的過程，它的結果是形成“達成一致”的需求（《軟件需求說明書》）。
④“獲取項目參與者對需求的承諾”主要包括兩個承諾。一是需求方對達成一致的需求（《軟件需求說明書》）的正式確認二是開發方以項目目標定義書的方式，對開發計劃和成本等作出承諾。

其次，“管理需求變更”中應先進行評估與審批，審批之后應執行“維護對需求的雙向可追溯性”和“標識項目計劃和工作產品與需求的不一致性”。這兩個看上去好象是附加上去的特定實踐，其實很重要（不好的需求管理流程中常缺這兩個特定實踐），其目的是通過流程維護需求變更的歷史和理由、評價需求變更的影響，發現不一致并啟動相關的處理過程域（進入其他流程）。例如，當變更對項目產生風險時，需要使用其他流程進行風險防范或進行項目計劃變更，這些都可以包含在流程中?！肮芾硇枨笞兏绷鞒绦枰渲霉芾磉^程域的支持（通常是通過配置管理的控制變更來實現對需求變更的控制）。

再次，兩個關系密切的特定實踐“維護對需求的雙向可追溯性”和“標識項目計劃和工作產品與需求的不一致性”，一般分散在其他相關流程中，并貫穿于整個軟件生命周期中。例如，定期或以事件觸發方式啟動“標識項目計劃和工作產品與需求的不一致性”，檢查是否一致，從而進行相應處理。

流程的具體編制依賴于組織結構（同時它也影響著組織結構），因此，不同的組織需要制定自己的流程。組織流程一般是跨過程域的綜合流程，在制定流程前，應充分了解過程域之間的依賴關系，只有這樣，才能將這些關系有機地融合到流程中。這些相關的過程域可能分屬于不同的成熟度級別，因此，可能在現有條件下沒有實施較高級別的過程域，這時我們可以“弱化”這些不能實現的過程域，即只取其必要的功能放到流程中去。如圖2中，我們將“需求開發”過程域弱化成“需求分析”（“需求管理”要求“需求開發”提供必要的功能）放到流程中。

總之，掌握過程域之間的關系，對編制流程很有幫助。這里我們總結出需求管理與其他過程域的主要關系。

（1）需求管理依賴的過程域
①需求開發：通過需求開發建立和維護客戶產品、產品部件和接口需求。
②配置管理：通過配置管理控制需求的變更。
③項目監督和控制：通過監督和控制識別需求與項目計劃、工作產品的矛盾。

（2）依賴于需求管理的過程域
①需求開發：通過需求管理來管理客戶和產品需求，獲得需求供應者的同意和需求實現者的承諾，并使需求的維護可追溯。
②技術解決方案：通過需求管理為產品和產品部件管理需求。
③產品集成：通過需求管理來管理接口需求的變更。
④項目計劃：根據需求管理來制定計劃和更改計劃。
⑤驗證和確認：根據需求管理維護需求。
⑥供應商合同管理：根據需求管理確定能被外部滿足的需求并管理可追溯的需求，這些需求來源于供應商已經完成的產品。

四、需求管理工具化

需求管理的工具包括：①需求及相關文檔管理的工具；②流程審批的流轉電子化；③溯源性矩陣的維護工具。其中最大的難點是需求溯源性矩陣的維護工具，對此我們作重點分析。

需求溯源包括的三個方面，可看作是三個子矩陣，每個子矩陣對某個方面都具有雙向溯源性。

1．需求向低層分解的雙向溯源矩陣

需求向低層分解的雙向溯源矩陣，如表1所示。

2．需求沿生命周期縱向產品溯源矩陣

需求沿生命周期縱向產品溯源矩陣，用表2、表3予以說明。
表2中的編號均表示文檔的版本號，例如，對于軟件需求說明書ＲＳ．1．2，對應有兩個系統設計規格書（DM．1．2．1、DM．1．2．2），后一個版本號代表新版本，應作為當前使用版本。該表反映了文檔變更歷史。

3．需求的水平溯源矩陣（跨系統功能間）

當需求影響到多個系統時，就應建立關聯功能間的水平溯源關系（見表4）。
綜上所述，需求管理要求建立和維護需求雙向溯源表，而雙向溯源表的關聯關系非常復雜，因此：

（1）必須借助工具進行管理。對小的項目，可以用Excel等簡單工具進行管理，但對大型項目或組織級的需求管理，則應購買或自行開發專門的需求管理工具。

（2）必須建立一套編碼體系，以便進行標識和檢索。

（3）需求管理工具可以與配置管理工具同時考慮，即綜合設計成一個管理系統。

五、需求管理實施建議

需求管理是基礎性的管理，企業必須投入精力，認真實施，并以此作為實施CMMI的起點。在實施中要注意如下幾點：

1．培訓工作。從以上分析可以看出，需求管理是一項技術含量高、參與人員多、持續時間長（從項目前期到項目結束）的管理活動。因此，必須作好相關的培訓，通過培訓使高層管理人員了解需求管理的意義，取得他們的支持；使需求管理人員學會使用工具；使一般員工有需求管理意識，維護好溯源矩陣中與自己相關的部分，并提高識別項目工作與需求的不一致的能力。

2．試點工作。應先選幾個項目作為試點，取得經驗后再全面實施。

3．從制度方面進行實施體系的建立，使之制度化。

4．監督與控制。質量保證（QA,Quality Assurance）人員應根據需求管理計劃為基準進行監督與控制，例如，根據需求管理的干系人及介入事件的關聯矩陣，審查“通報雙向溯源性情況”是否到位（是否按時通報，是否有人員遺漏）等。

5．評價與審查。一方面對過程的活動、狀態及結果進行審查，解決相關問題；另一方面對照要求進行評價與檢查，總結經驗并處理不符合項。

6．度量。逐步建立度量的指標體系，開始時可只度量完成各項工作的工作量，之后可以作進一步的度量，積累組織的歷史數據，供以后進行需求管理的分析、決策等。例如，需求變更比率、因變更造成的延期、需求變更累計數等。

 

原文轉自：http://www.anti-gravitydesign.com