CMM
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）也并不提倡制作過多的文檔�？刂坪媚愕挠媱�，使之適合你的項目。需求分析人員應該專注于需求的獲取和分析，而不是寫出漂亮的文檔。當然，如果用戶有這方面的要求的話，你是應當重視的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
