中維持需求約定集成性和精確性的所有活動，如圖所示。需求管理強調(diào)：
1、控制對需求基線的變動。
2、保持項目計劃與需求一致。
3、控制單個需求和需求文檔的版本情況。
4、管理需求和聯(lián)系鏈之間的聯(lián)系或管理單個需求和其它項目可交付品之間的依賴關(guān)系。
5、跟蹤基線中需求的狀態(tài)。
和任何的管理活動一樣，需求管理的目的也是為了確保需求分析活動按照既定方針執(zhí)行。
CMM
CMM（capability Maturity Model）過程成熟度模型，這個概念是由位于賓夕法尼亞洲匹茲堡市的卡內(nèi)基梅隆大學(xué)所屬的軟件工程研究所提出的。CMM是在軟件開發(fā)機構(gòu)中被廣泛地用來指導(dǎo)過程改進(jìn)工作的模型。該方法描述了軟件處理能力的五個成熟級別。處于一級的組織典型地以非正式的方式管理項目進(jìn)度，要獲得成功，主要依靠天才從業(yè)者和管理者的英雄史詩般的奮斗。處于更高成熟度級別的組織把具有創(chuàng)造性、訓(xùn)練有素的員工同軟件工程和項目管理過程結(jié)合起來，將持續(xù)不斷地獲得成功。 過程能力成熟度模型對需求管理是一個有用的指導(dǎo)。為達(dá)到軟件過程能力成熟度模型的第二級，組織必須具有在軟件開發(fā)與管理的六個關(guān)鍵過程域（key process areas，KPA）以展示達(dá)到目標(biāo)的能力。需求管理是其中之一，它的目標(biāo)如下：
1) 把軟件需求建立一個基線供軟件工程和管理使用。
2) 軟件計劃，產(chǎn)品和活動同軟件需求保持一致。
需求管理的關(guān)鍵過程領(lǐng)域不涉及收集和分析項目需求。而是假定已收集了軟件需求或已由更高一級的系統(tǒng)給定了需求。一旦需求到手且文檔化了，軟件開發(fā)團隊和有關(guān)的團隊（例如質(zhì)量保證和測試）需要評審文檔。發(fā)現(xiàn)問題應(yīng)與客戶或其它需求源協(xié)商解決，軟件開發(fā)計劃是基于已確認(rèn)的需求。 開發(fā)團隊在向客戶、市場部或經(jīng)理們作出承諾（commitment）之前，應(yīng)該確認(rèn)需求和確認(rèn)約束條件、風(fēng)險、偶然因素、假定條件。也許不得不面對由于技術(shù)因素或進(jìn)度原因而不現(xiàn)實的需求作出承諾。但是，決不要承諾任何無法實現(xiàn)的事。
關(guān)鍵處理領(lǐng)域同樣建議通過版本控制和變更控制來管理需求文檔。版本控制確保隨時能知道在開發(fā)和計劃中正在使用的需求的版本情況。變更控制提供了支配下的規(guī)范的方式來統(tǒng)一需求變更，并且基于業(yè)務(wù)和技術(shù)的因素來同意或反對建議的變更。當(dāng)在開發(fā)中修改、增加、減少需求時，軟件開發(fā)計劃應(yīng)該隨時更新以與新的需求保持一致。不反映現(xiàn)實的計劃于事無補。 必需要強調(diào)的一點是，CMM只是推薦方法，并沒有說你一定要采用這種方法。仔細(xì)的分析自身的特點，總結(jié)適合自身的方法。但是CMM提到的兩個目標(biāo)卻是任何需求活動都應(yīng)該追尋的目標(biāo)。事實上，不但各個企業(yè)采用的方法不同，即便是企業(yè)內(nèi)部，對于不同的項目，也不存在一個標(biāo)準(zhǔn)的模式。每個項目都有自身的特點，不能強制性的要求他們采用同樣的模板。所以在項目開始的時候，一般在項目可行性論證的時候，管理小組就會根據(jù)本個項目的特性制定項目計劃和需求計劃。 需求管理步驟
開發(fā)組織應(yīng)該定義項目組執(zhí)行管理他們需求的步驟。文檔化編寫這些步驟能使組織成員持續(xù)有效地進(jìn)行必要的項目活動。請考慮選擇以下主題：
1、用于控制各種需求文檔和單個需求版本的工具、技術(shù)和習(xí)慣做法。
2、建議、處理、協(xié)商、通告新的需求和變更給有關(guān)的功能域的方法。
3、如何制定需求基線。
4、將使用的需求狀態(tài)，并且是誰允許作出的變更。
5、需求狀態(tài)跟蹤和報告過程。
6、分析已建議變動的影響應(yīng)遵循的步驟。
7、在何種情況下需求變更將會怎樣影響項目計劃和約定。
你可以在一個文檔中包含上面所有的信息?；蛘?，你可能喜歡專題分述，例如分成變更控制過程，影響分析過程，狀態(tài)跟蹤過程。這