什么需求？誰的需求？
CMM已經說得很清楚：本關鍵過程與中所說的需求是指“分配給軟件的系統需求“，或者更簡潔地說，“分配需求”。這些需求有可能是技術方面的（比如：功能和性能需求），也有可能是非技術方面的（比如：發布日期，開支限度）。這里假設被開發的軟件是更大的系統中的一部分，這個更大的系統包括了正在開發著的軟件和所有其它組件。更進一步的假設是那個更大的系統就是一位客戶，這個客戶是所有系統需求的來源。他不需要負責區分軟件所要實現的系統需求和其他的需求。確切地說，負責選擇哪些系統需求必須分配給軟件的人是系統工程組。但是，在執行這個角色的時候，系統工程組并不是獨自行事的。這個觀點在本關鍵過程域的行為1中有明顯的證據，原文如下：
“軟件工程組在分配需求合并入軟件項目中之前對其進行復審�！埃–MU/SEI-93-TR-25,RM.AC.1）
一般的混亂點存在于沒有高一級的系統或者正被開發的軟件就是整個產品的情況下。盡管這種情況下沒有分配給軟件的需求，但為了保持CMM的一致性，仍然使用“分配需求”的概念。毫無疑問，這個概念在這里是不能直接應用的，但是可以通過所有的產品需求都是分配需求來解釋。
區分開需求管理（CMM中的概念）和軟件需求分析（軟件工程文獻中的概念）是很重要的。一旦分配需求被文檔化，并且被所有受影響部門（客戶，系統工程，軟件工程）通過，需求管理的基本工作就完成了，所剩下的就是管理變更而已。沒有證據證明分配需求本身就可以十分清楚完整的作為軟件開發的全部基礎。事實上，通常它們不是。優化和精確描述需求，填補漏洞，將含義表達得更清楚是軟件需求分析要做的，分析的結果在CMM中被稱為“軟件需求“。這樣，作為需求管理的輸出的分配需求實際上就成了軟件需求分析的輸入。需求管理遠遠先于軟件開發的技術行動，而軟件需求分析則是關鍵開發技術行為的第一步。
客戶的主張也必須闡明。CMM詞匯表中對“客戶”的定義是：
“負責接收產品并且付給開發組織報酬的個人或組織�！�
當一個組織為外部客戶在合同約定下做軟件開發時，這個概念很清楚并且可以直接的應用。甚至當一個大公司的軟件開發部門為公司的其他部門開發系統的時候，也即當存在一個“內部用戶”的時候，這個詞的使用也是可以憑直覺的。但是在商業產品開發的情況下可能會有混亂產生，在這種情況下，軟件開發的努力作為開發組織的一種投資，真正的用戶是決定買不買最終的產品。這種客戶在軟件開發中不扮演任何角色，當然也不會與軟件組織“關于需求達成協議”。但是，即便是在這種商業產品的情況下，在公司的內部也存在著這樣的組織負責決定那些特征為預期的用戶所需要，這些用戶愿意為什么掏錢。這個組可能在客戶群中做市場調查，也可能與一些典型用戶展開討論會，還有可能他們使用企業現有的客戶庫中的反饋信息。無論他們怎樣收集信息，CMM都把這個組看作是客戶的代理，并且期望在開發啟動之前，代理客戶與軟開發組之間在需求方面達成協議。
需求變更
因為現實世界的軟件系統可能有不同的嚴格程度和復雜性，事先預言所有的相關需求是不可能的。系統原計劃的操作環境會改變，用戶的需求會改變，甚至系統的角色也有可能改變。實際上，實現和測試系統的行為可能導致對正解決的問題的新的理解和洞察，這種新的認識就有可能導致需求變更。
CMM承認這一事實。實際上，本關鍵過程域的行為3是如此表述這個問題的：
“分配需求的變更被復審，并加入到軟件項目中來�！保–MU/SEI-93-TR-25,RM.AC.1）
此處的關鍵是在需求發生變更時，沒有必要馬上把這些變更付諸軟件開發工作。實際上，堅持把需求變更付諸開發努力，企業就會形成一種混亂且不穩定的氛圍，浙江嚴重破壞項目的控制和管理。需求管理關鍵過程域試圖通過把分配需求的變更囤積到可管理的組中，等到開發工作允許的時候在引入的方法，避免產生這種混亂的氛圍。結果，需求管理創建了一個隔絕開發工作與所有的真實的、潛在無序的、來自于客戶的變更。這個緩沖器允許真實的變更被注意、記錄、追蹤，同時開發工作又不會因此而被擾亂。開發項目應該周期性的暫停來吸收最新的需求變更積累，此時，所有的計劃，設計，行為都根據剛剛吸收的需求變更的影響進行更新。
維護的需求管理
需求管理只能應用于新的開發項目中么？維護工作呢？需求管理怎樣應用于維護工作?
CMM同樣使軟件維護工作從改進的過程成熟度中受益。在典型的維護情景中，有一系列的變更請求和/或問題報告必須滿足。這些變更請求和問題報告可能單個的提出，也有可能為了分析實現之便綜合成相聯系的一組。無論哪種情況下，這些定義詳細維護工作的目標的文檔都作為“分配需求”的角色。而CMM要求的是把它們文檔化，控制好，保證它們被所有的受影響組通過，保證軟件維護計劃和活動與它們保持一致，并且對它們來說是是可追蹤的。變更請求和問題報告可以是維護組織選定的任意形式和內容，只要它們可以為軟件維護人員提供充足的指導，幫助他們知道客戶需要它們來做什么。與開發需求的情況相同，可能在技術工作之前可能會有技術診斷和分析，但這些診斷和分析的工作是技術維護活動的一部分，而不是需求管理的一部分。
需求管理的困難
從這里的描述看來，需求管理的活動簡直太簡單，太基礎了，顯然沒有哪個軟件開發組織會不有效的進行著這種活動。但是，我們看見許多處于一級水平的軟件公司在為把該原則付諸實施奮力拼搏著。
問題經常處在企業對透明度的懼怕�？蛻粲X得保持需求含糊不清，松散或者無正式文件能夠給他們更多的機會去說：“那并不是我所要的，那并不是我認為的需求的含義�！蔽臋n化清晰的需求可能迫使用戶在系統滿足了文檔化的需求但沒有滿足實際需要的情況下，為開始變更負責。相似地，開發人員覺得含糊不清，松散或者無正式文件的需求能給他們更大的余地，允許他們與預算和進度盡可能地接近，然后說：“這就是我們所認為的需求的含義，如果你需要其他的什么東西，你必須另外付出代價�！蔽臋n化清晰的需求會迫使開發者承擔滿足這些需求的義務，并使他們暴露于開支、進度評估不準確的風險之下。
這樣一來，盡管客戶與開發人員的利益動機相對，但他們卻走到了一起，偷偷摸摸地共謀抵抗CMM的實施。每一方都認為他們在保護自己的利益，鞏固自己討價還價的地位，但是事實上每一方都在走向將來的失望和爭吵。
完美主義在這里也會成為障礙之一。人們通常承認，至少向自己承認，他們不清楚將來所有的系統需求。不幸的是，他們就這樣想：因為需求不會完美，那么他們也就無法對需求文檔化了。事實上，就像軟件設計能在反復優化的每個階段精確地用文檔描述出來一樣，軟件需求也可以隨著變化進行文檔化，在進化的每個階段，對系統需求的理解只在該階段有效。對需求或者設計的連續影像的記錄允許對該過程所學到的有個清楚的檔案，允許所有的項目參與者對任何給定的關于正被開發的系統的問題，包括他們知道和不知道的都能夠理解。
有效的文檔化和需求管理可以標志著一個軟件企業的文化改變，通常幾個主要文化改變中的第一次源自于長期的軟件過程改進規劃。但是，擁有清楚，寫出來的需求顯然是制訂清晰的、寫出來的、正式的承諾的必要前提。打破模糊的、曖昧的、沒有文檔化的需求是一種偉大的挑戰。但是制訂堅持遵守的承諾，并實踐它，是個更加巨大的挑戰。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
