CMM（capability Maturity Model）過程成熟度模型，這個概念是由位于賓夕法尼亞洲匹茲堡市的卡內基梅隆大學所屬的軟件工程研究所提出的。CMM是在軟件開發機構中被廣泛地用來指導過程改進工作的模型。該方法描述了軟件處理能力的五個成熟級別。處于一級的組織典型地以非正式的方式管理項目進度，要獲得成功，主要依靠天才從業者和管理者的英雄史詩般的奮斗。處于更高成熟度級別的組織把具有創造性、訓練有素的員工同軟件工程和項目管理過程結合起來，將持續不斷地獲得成功。
過程能力成熟度模型對需求管理是一個有用的指導。為達到軟件過程能力成熟度模型的第二級，組織必須具有在軟件開發與管理的六個關鍵過程域（key process areas，KPA）以展示達到目標的能力。需求管理是其中之一，它的目標如下：
1) 把軟件需求建立一個基線供軟件工程和管理使用。
2) 軟件計劃，產品和活動同軟件需求保持一致。
需求管理的關鍵過程領域不涉及收集和分析項目需求。而是假定已收集了軟件需求或已由更高一級的系統給定了需求。一旦需求到手且文檔化了，軟件開發團隊和有關的團隊（例如質量保證和測試）需要評審文檔。發現問題應與客戶或其它需求源協商解決，軟件開發計劃是基于已確認的需求。
開發團隊在向客戶、市場部或經理們作出承諾（commitment）之前，應該確認需求和確認約束條件、風險、偶然因素、假定條件。也許不得不面對由于技術因素或進度原因而不現實的需求作出承諾。但是，決不要承諾任何無法實現的事。
關鍵處理領域同樣建議通過版本控制和變更控制來管理需求文檔。版本控制確保隨時能知道在開發和計劃中正在使用的需求的版本情況。變更控制提供了支配下的規范的方式來統一需求變更，并且基于業務和技術的因素來同意或反對建議的變更。當在開發中修改、增加、減少需求時，軟件開發計劃應該隨時更新以與新的需求保持一致。不反映現實的計劃于事無補。
必需要強調的一點是，CMM只是推薦方法，并沒有說你一定要采用這種方法。仔細的分析自身的特點，總結適合自身的方法。但是CMM提到的兩個目標卻是任何需求活動都應該追尋的目標。事實上，不但各個企業采用的方法不同，即便是企業內部，對于不同的項目，也不存在一個標準的模式。每個項目都有自身的特點，不能強制性的要求他們采用同樣的模板。所以在項目開始的時候，一般在項目可行性論證的時候，管理小組就會根據本個項目的特性制定項目計劃和需求計劃。
需求管理步驟
開發組織應該定義項目組執行管理他們需求的步驟。文檔化編寫這些步驟能使組織成員持續有效地進行必要的項目活動。請考慮選擇以下主題：
1、用于控制各種需求文檔和單個需求版本的工具、技術和習慣做法。
2、建議、處理、協商、通告新的需求和變更給有關的功能域的方法。
3、如何制定需求基線。
4、將使用的需求狀態，并且是誰允許作出的變更。
5、需求狀態跟蹤和報告過程。
6、分析已建議變動的影響應遵循的步驟。
7、在何種情況下需求變更將會怎樣影響項目計劃和約定。
你可以在一個文檔中包含上面所有的信息�；蛘�，你可能喜歡專題分述，例如分成變更控制過程，影響分析過程，狀態跟蹤過程。這些過程可能在多個項目中都有用，因為他們反映每個項目所應遵循的公共功能。
需求控制的工具有很多，你可以使用專業的Rational公司的RequisistPro，也可以使用一些可視化的數據庫管理工具，甚至你可以只是使用目錄結構。用什么樣的工具并不是特別重要，關鍵還是在于人。上面已經說過，需求的管理最重要的（關鍵過程域）就是版本控制和變更管理。這兩個方面是密切相關的。需要版本控制的一個重要因素就是需求在不斷的變化。
文檔的海洋
雖然到現在還沒有提到任何的具體文檔，但是需求過程的產品中大都是文檔。文檔的產生目的是為了項目能夠被控制。如果為了實現控制項目的目的，而文檔卻陷入了不可控制的境地，那就是一條歧途了。想象起來是很可笑，但是這個錯誤是確實存在的。往往有一些狂熱的技術分子，為了追求完美的實施項目管理，實施了過多的文檔，可是這個項目本身并沒有想象的那么龐大。到了最后，是由于文檔的失控導致了項目的失控。即便是以完善著稱的RUP（Rational Unifined Process）也并不提倡制作過多的文檔�？刂坪媚愕挠媱�，使之適合你的項目。需求分析人員應該專注于需求的獲取和分析，而不是寫出漂亮的文檔。當然，如果用戶有這方面的要求的話，你是應當重視的。
需求管理活動的積累材料
變更控制過程變更控制過程能夠減少因無休止、失控的需求變更引起的混亂。它明確了一種方法來提出、協商、評估一個新的需求或在已有需求上的一項變更。變更控制通常需要問題跟蹤工具的支持，但請銘記工具并不能替代過程。
變更控制委員會過程變更控制委員會(CCB)是由風險承擔者的主要成員組成的，對提出的需求變更決定執行哪一項，拒絕哪一項，以及在各產品發行版本中包括哪些變更。CCB過程描述了變更控制委員會的組成及操作過程。CCB的主要活動是對提出的變更進行影響分析，為每項變更作出決定，并且告知那些將受到影響的人。
需求變更影響分析清單和模板估計提出的需求變更的成本費用和影響是決定是否執行變更的重要步驟。影響分析能幫助CCB作出正確的決定。影響分析清單包括許多自問自答型的問題，如：要考慮到可能的任務、邊界影響、實施所確定的變更引起的相關的潛在風險。一張參與人員工作表可以作為估計任務工作量的簡單方法，從這里就能明白確認變更的復雜性。
需求狀態跟蹤過程需求管理包括監控和報告每項功能需求的狀態和狀態改變的條件。你需要一個數據庫或一種商業需求管理工具來跟蹤一個復雜系統中大量的需求狀態。此過程也描述了當你隨時查看收集到的需求狀態時輸出的報告格式。
需求跟蹤能力矩陣模板需求跟蹤能力矩陣列出了SRS中的所有功能需求及相應的設計模塊，源文件和實施需求的過程，還有驗證需求實施正確性的測試用例。跟蹤能力矩陣應該也可以指出對應的上一層用戶需求或系統需求。
需求分析
需求分析可分為：問題獲�。╡licitation）、分析(analysis)、編寫規格說明（specification）和驗證（verification）四個階段（Thayer and Dorfman 1997）。這些子項包括軟件類產品中需求收集、評價、編寫文檔等所有活動。需求開發活動包括以下幾個方面：
1、確定產品所期望的用戶類。
2、獲取每個用戶類的需求。
3、了解實際用戶任務和目標以及這些任務所支持的業務需求。
4、分析源于用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息。
5、將系統級的需求分為幾個子系統，并將需求中的一部份分配給軟件組件。
6、了解相關質量屬性的重要性。
7、商討實施優先級的劃分。
8、將所收集的用戶需求編寫成規格說明和模型。
9、評審需求規格說明，確保對用戶需求達到共同的理解與認識，并在整個開發小組接受說明之前將問題都弄清楚。
需求開發過程的積累材料
1) 項目視圖與范圍模板項目的視圖與范圍文檔明確了項目的概念性功能，并提供了確定需求優先級和變更的參考。需求視圖與范圍文檔是簡明扼要的、高度概括的新項目業務需求說明。用統一的方式編寫項目視圖與范圍文檔能確保在項目進行過程中作決定時能考慮到所有應考慮的情況。
2) 需求開發過程該過程介紹了怎樣確定客戶及從客戶那里獲取需求的技術。也描述了項目。需要創建的各種需求文檔和分析模型。這個過程還指明了每項需求包含的信息種類，比如：優先級、預計的穩定性或計劃發行版本號。同時還應指明需求分析及需求文檔檢驗需要執行的步驟以及確認軟件需求規格說明和建立需求基線的步驟。
3) 需求分配過程把高層的產品需求分成若干特定子系統是非常重要的，尤其是當開發的系統既含有軟件又含有硬件或是包括多個子系統的軟件產品時尤為重要（Nelsen 1990）。需求分配是在系統級需求完成和系統體系結構確定后才進行的，這個過程包含的信息是怎樣執行分配以確保功能分配到合適的系統組件中，同時也說明分配的需求怎樣才能追溯回它們的上兩級系統需求以及在其它子系統中的相關需求。
4) 使用實例模板使用實例模板提供了一種把每項用戶希望使用軟件系統完成的任務編寫成文檔的標準方法。使用實例定義包括一個簡要的任務介紹，必須處理的異常情況的說明和描述用戶任務特點的附加信息。使用實例可作為軟件需求規格說明中一條獨立的功能需求。另外，你也可將使用實例與SRS模板合并為一個文檔，既包括產品的使用實例，又包括軟件功能需求。
5) 軟件需求規格說明模板軟件需求規格說明模板提供了一種組織功能需求和非功能需求的結構化方法。采用標準的SRS模板將有助于創建統一且高質量的需求文檔�？赡芤捎枚鄠�模板以適應組織承擔的不同類型和規模的項目。這樣可減少因一種“萬能”模板并不適合你的項目所帶來的障礙。
6) 需求優先級確定過程，此時為滿足進度時限要求，計劃的功能不得不放棄掉。我們需要知道哪些性能、使用實例或功能需求的優先級最低，以便在任何階段，我們都可適當縮減范圍。
7) SRS和使用實例審查清單對需求文檔的正式審查是保證軟件質量的一項重要措施。審查清單指出在需求文檔中發現的一些錯誤。在審查會議的準備中運用清單將使你的注意力集中到通常存在問題的地方。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
