需求管理是cmm二級中列出的第乙個關鍵域，這是因為它實際上是二級引入到開發過程中的所有管理原則的先決條件。只有在開發的目標被清楚明白地表述和理解的情況下，軟體開發才能以一種有計畫的有序的方式進行。實際上，沒有文件化的需求，在開發工作完成前後都很有可能發生產品與要求的偏離。
計畫、追蹤、配置管理以及軟體質量保證這些在二級的其他關鍵過程域中涉及的原則，都是從乙個穩定的基礎開始的，那就是文件化的需求基線。
什麼需求？誰的需求？
cmm已經說得很清楚：本關鍵過程與中所說的需求是指「分配給軟體的系統需求「，或者更簡潔地說，「分配需求」。這些需求有可能是技術方面的（比如：
功能和效能需求），也有可能是非技術方面的（比如：發布日期，開支限度）。這裡假設被開發的軟體是更大的系統中的一部分，這個更大的系統包括了正在開發著的軟體和所有其它元件。
更進一步的假設是那個更大的系統就是一位客戶，這個客戶是所有系統需求的**。他不需要負責區分軟體所要實現的系統需求和其他的需求。確切地說，負責選擇哪些系統需求必須分配給軟體的人是系統工程組。
但是，在執行這個角色的時候，系統工程組並不是獨自行事的。這個觀點在本關鍵過程域的行為1中有明顯的證據，原文如下：
「軟體工程組在分配需求合併入軟體專案中之前對其進行複審。「（cmu/sei-93-tr-25,
一般的混亂點存在於沒有高一級的系統或者正被開發的軟體就是整個產品的情況下。儘管這種情況下沒有分配給軟體的需求，但為了保持cmm的一致性，仍然使用「分配需求」的概念。毫無疑問，這個概念在這裡是不能直接應用的，但是可以通過所有的產品需求都是分配需求來解釋。
區分開需求管理（cmm中的概念）和軟體需求分析（軟體工程文獻中的概念）是很重要的。一旦分配需求被文件化，並且被所有受影響部門（客戶，系統工程，軟體工程）通過，需求管理的基本工作就完成了，所剩下的就是管理變更而已。沒有證據證明分配需求本身就可以十分清楚完整的作為軟體開發的全部基礎。
事實上，通常它們不是。優化和精確描述需求，填補漏洞，將含義表達得更清楚是軟體需求分析要做的，分析的結果在cmm中被稱為「軟體需求「。這樣，作為需求管理的輸出的分配需求實際上就成了軟體需求分析的輸入。
需求管理遠遠先於軟體開發的技術行動，而軟體需求分析則是關鍵開發技術行為的第一步。
客戶的主張也必須闡明。cmm詞彙表中對「客戶」的定義是：
「負責接收產品並且付給開發組織報酬的個人或組織。」
當乙個組織為外部客戶在合同約定下做軟體開發時，這個概念很清楚並且可以直接的應用。甚至當乙個大公司的軟體開發部門為公司的其他部門開發系統的時候，也即當存在乙個「內部使用者」的時候，這個詞的使用也是可以憑直覺的。但是在商業產品開發的情況下可能會有混亂產生，在這種情況下，軟體開發的努力作為開發組織的一種投資，真正的使用者是決定買不買最終的產品。
這種客戶在軟體開發中不扮演任何角色，當然也不會與軟體組織「關於需求達成協議」。但是，即便是在這種商業產品的情況下，在公司的內部也存在著這樣的組織負責決定那些特徵為預期的使用者所需要，這些使用者願意為什麼掏錢。這個組可能在客戶群中做市場調查，也可能與一些典型使用者展開討論會，還有可能他們使用企業現有的客戶庫中的反饋資訊。
無論他們怎樣收集資訊，cmm都把這個組看作是客戶的**，並且期望在開發啟動之前，**客戶與軟開發組之間在需求方面達成協議。
需求變更
因為現實世界的軟體系統可能有不同的嚴格程度和複雜性，事先預言所有的相關需求是不可能的。系統原計畫的操作環境會改變，使用者的需求會改變，甚至系統的角色也有可能改變。實際上，實現和測試系統的行為可能導致對正解決的問題的新的理解和洞察，這種新的認識就有可能導致需求變更。
cmm承認這一事實。實際上，本關鍵過程域的行為3是如此表述這個問題的：
「分配需求的變更被複審，並加入到軟體專案中來。」（cmu/sei-93-tr-25,
此處的關鍵是在需求發生變更時，沒有必要馬上把這些變更付諸軟體開發工作。實際上，堅持把需求變更付諸開發努力，企業就會形成一種混亂且不穩定的氛圍，浙江嚴重破壞專案的控制和管理。需求管理關鍵過程域試圖通過把分配需求的變更囤積到可管理的組中，等到開發工作允許的時候在引入的方法，避免產生這種混亂的氛圍。
結果，需求管理建立了乙個隔絕開發工作與所有的真實的、潛在無序的、來自於客戶的變更。這個緩衝器允許真實的變更被注意、記錄、追蹤，同時開發工作又不會因此而被擾亂。開發專案應該週期性的暫停來吸收最新的需求變更積累，此時，所有的計畫，設計，行為都根據剛剛吸收的需求變更的影響進行更新。
維護的需求管理
需求管理只能應用於新的開發專案中麼？維護工作呢？需求管理怎樣應用於維護工作?
cmm同樣使軟體維護工作從改進的過程成熟度中受益。在典型的維護情景中，有一系列的變更請求和/或問題報告必須滿足。這些變更請求和問題報告可能單個的提出，也有可能為了分析實現之便綜合成相聯絡的一組。
無論哪種情況下，這些定義詳細維護工作的目標的文件都作為「分配需求」的角色。而cmm要求的是把它們文件化，控制好，保證它們被所有的受影響組通過，保證軟體維護計畫和活動與它們保持一致，並且對它們來說是是可追蹤的。變更請求和問題報告可以是維護組織選定的任意形式和內容，只要它們可以為軟體維護人員提供充足的指導，幫助他們知道客戶需要它們來做什麼。
與開發需求的情況相同，可能在技術工作之前可能會有技術診斷和分析，但這些診斷和分析的工作是技術維護活動的一部分，而不是需求管理的一部分。
需求管理的困難
從這裡的描述看來，需求管理的活動簡直太簡單，太基礎了，顯然沒有哪個軟體開發組織會不有效的進行著這種活動。但是，我們看見許多處於一級水平的軟體公司在為把該原則付諸實施奮力拼搏著。
問題經常處在企業對透明度的懼怕。客戶覺得保持需求含糊不清，鬆散或者無正式檔案能夠給他們更多的機會去說：「那並不是我所要的，那並不是我認為的需求的含義。
」文件化清晰的需求可能迫使使用者在系統滿足了文件化的需求但沒有滿足實際需要的情況下，為開始變更負責。相似地，開發人員覺得含糊不清，鬆散或者無正式檔案的需求能給他們更大的餘地，允許他們與預算和進度盡可能地接近，然後說：「這就是我們所認為的需求的含義，如果你需要其他的什麼東西，你必須另外付出代價。
」文件化清晰的需求會迫使開發者承擔滿足這些需求的義務，並使他們暴露於開支、進度評估不準確的風險之下。
這樣一來，儘管客戶與開發人員的利益動機相對，但他們卻走到了一起，偷偷摸摸地共謀抵抗cmm的實施。每一方都認為他們在保護自己的利益，鞏固自己討價還價的地位，但是事實上每一方都在走向將來的失望和爭吵。
完美主義在這裡也會成為障礙之一。人們通常承認，至少向自己承認，他們不清楚將來所有的系統需求。不幸的是，他們就這樣想：
因為需求不會完美，那麼他們也就無法對需求文件化了。事實上，就像軟體設計能在反覆優化的每個階段精確地用文件描述出來一樣，軟體需求也可以隨著變化進行文件化，在進化的每個階段，對系統需求的理解只在該階段有效。對需求或者設計的連續影像的記錄允許對該過程所學到的有個清楚的檔案，允許所有的專案參與者對任何給定的關於正被開發的系統的問題，包括他們知道和不知道的都能夠理解。
有效的文件化和需求管理可以標誌著乙個軟體企業的文化改變，通常幾個主要文化改變中的第一次源自於長期的軟體過程改進規劃。但是，擁有清楚，寫出來的需求顯然是制訂清晰的、寫出來的、正式的承諾的必要前提。打破模糊的、曖昧的、沒有文件化的需求是一種偉大的挑戰。
但是制訂堅持遵守的承諾，並實踐它，是個更加巨大的挑戰。
CMM3正式評估全過程
2005 06 28 09 08 csdn 評估時間 5月30日 6月8日 1 atm assessment team member 培訓 也就是對正式評估的評估小組成員進行相關培訓，但我和幾個將要被訪談的同事也參加了培訓。培訓時間 5.30 5.319 00 17 00培訓地點 公司會議室 培訓老...
特殊過程關鍵過程如何識別
提要 1 當前，對特殊過程確認的實施和控制存在兩個誤區 一是識別不準確，二是確認不充分。2 特殊過程的識別是特殊過程確認的關鍵環節，根據朱蘭博士對質量特性的劃分和9000標準的有關概念提出了特殊過程識別的三原則。3 對特殊過程的區域應進行適當的界定，目的是方便確認。4 應對特殊過程實現所策劃的結果的...
CMMI 關鍵過程CPI
cmmi軟體過程管理的cki模型分析 2009 04 10作者 chenji chenji的blog 容變 知識 互動 cki 理論框架模型為敏捷軟體過程管理提供了乙個整體的概念框架，從而引導敏捷軟體過程管理的研究得出更加全面的觀點。敏捷軟體過程管理有三個基本的特徵屬性 容變管理 人 過程的互動管理...