能力成熟度模型整合（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．度量。逐步建立度量的指標體系，開始時可只度量完成各項工作的工作量，之後可以作進一步的度量，積累組織的歷史資料，供以後進行需求管理的分析、決策等。例如，需求變更比率、因變更造成的延期、需求變更累計數等。
CMMI管理 需求部分
一.cmmi簡要介紹 cmmi是美國為了對軟體企業所做的軟體工程進行管理和改進而出台的詳細整合化框架，對軟體開發的各個崗位，各個工作流程制定了相應的規範。cmmi 的全稱是 capability maturity model integration 即軟體能力成熟度整合模型。cmmi主要關注點 成本...
CMMI 需求管理 REQM 2級
sg 1 管理需求 sp1.1 理解需求 sp1.2 獲得對需求的承諾 sp1.3 管理需求變更 sp1.4 維護需求的雙向可追溯性 sp1.5 確保專案工作與需求間的協調一致 一 管理需求 1 理解需求 通過需求調研計畫，了解客戶需求，通過 的形式將一些固定需求向客戶調查 2 獲得對需求的承諾 專...
CMMI過程 風險管理
申明 如果你要是感覺本文對你有用，http www.zgxingai.com 1簡介1.1目的 本過程的目的是定義組織內部的專案風險的識別 分析 跟蹤和處理活動的流程以及所使用的技術。1.2適用範圍 本文件適用於組織內的各軟體專案的風險管理活動。2過程總體描述 2.1過程概述 為了管理專案可能存在的...