－－－－－－－－－－－－－－－－－－－－－－
本文歡迎轉載，歡迎大家與我交流討論。
聯系方式：高�。ňW名DrCMM）， w-gao@263.net
轉載請保留本聲明，謝謝！
－－－－－－－－－－－－－－－－－－－－－－－
需求管理是CMM二級中列出的第一個關鍵域，這是因為它實際上是二級引入到開發過程中的所有管理原則的先決條件。只有在開發的目標被清楚明白地表述和理解的情況下，軟件開發才能以一種有計劃的有序的方式進行。實際上，沒有文檔化的需求，在開發工作完成前后都很有可能發生產品與要求的偏離。計劃、追蹤、配置管理以及軟件質量保證這些在二級的其他關鍵過程域中涉及的原則，都是從一個穩定的基礎開始的，那就是文檔化的需求基線。
什么需求？誰的需求？
CMM已經說得很清楚：本關鍵過程與中所說的需求是指“分配給軟件的系統需求“，或者更簡潔地說，“分配需求”。這些需求有可能是技術方面的（比如：功能和性能需求），也有可能是非技術方面的（比如：發布日期，開支限度）。這里假設被開發的軟件是更大的系統中的一部分，這個更大的系統包括了正在開發著的軟件和所有其它組件。更進一步的假設是那個更大的系統就是一位客戶，這個客戶是所有系統需求的來源。他不需要負責區分軟件所要實現的系統需求和其他的需求。確切地說，負責選擇哪些系統需求必須分配給軟件的人是系統工程組。但是，在執行這個角色的時候，系統工程組并不是獨自行事的。這個觀點在本關鍵過程域的行為1中有明顯的證據，原文如下：
“軟件工程組在分配需求合并入軟件項目中之前對其進行復審。
一般的混亂點存在于沒有高一級的系統或者正被開發的軟件就是整個產品的情況下。盡管這種情況下沒有分配給軟件的需求，但為了保持CMM的一致性，仍然使用“分配需求”的概念。毫無疑問，這個概念在這里是不能直接應用的，但是可以通過所有的產品需求都是分配需求來解釋。
區分開需求管理（CMM中的概念）和軟件需求分析（軟件工程文獻中的概念）是很重要的。一旦分配需求被文檔化，并且被所有受影響部門（客戶，系統工程，軟件工程）通過，需求管理的基本工作就完成了，所剩下的就是管理變更而已。沒有證據證明分配需求本身就可以十分清楚完整的作為軟件開發的全部基礎。事實上，通常它們不是。優化和精確描述需求，填補漏洞，將含義表達得更清楚是軟件需求分析要做的，分析的結果在CMM中被稱為“軟件需求“。這樣，作為需求管理的輸出的分配需求實際上就成了軟件需求分析的輸入。需求管理遠遠先于軟件開發的技術行動，而軟件需求分析則是關鍵開發技術行為的第一步。
客戶的主張也必須闡明。CMM詞匯表中對“客戶”的定義是：
“負責接收產品并且付給開發組織報酬的個人或組織�！�
當一個組織為外部客戶在合同約定下做軟件開發時，這個概念很清楚并且可以直接的應用。甚至當一個大公司的軟件開發部門為公司的其他部門開發系統的時候，也即當存在一個“內部用戶”的時候，這個詞的使用也是可以憑直覺的。但是在商業產品開發的情況下可能會有混亂產生，在這種情況下，軟件開發的努力作為開發組織的一種投資，真正的用戶是決定買不買最終的產品。這種客戶在軟件開發中不扮演任何角色，當然也不會與軟件組織“關于需求達成協議”。但是，即便是在這種商業產品的情況下，在公司的內部也存在著這樣的組織負責決定那些特征為預期的用戶所需要，這些用戶愿意為什么掏錢。這個組可能在客戶群中做市場調查，也可能與一些典型用戶展開討論會，還有可能他們使用企業現有的客戶庫中的反饋信息。無論他們怎樣收集信息，CMM都把這個組看作是客戶的代理，并且期望在開發啟動之前，代理客戶與軟開發組之間在需求方面達成協議。
需求變更
因為現實世界的軟件系統可能有不同的嚴格程度和復雜性，事先預言所有的相關需求是不可能的。系統原計劃的操作環境會改變，用戶的需求會改變，甚至系統的角色也有可能改變。實際上，實現和測試系統的行為可能導致對正解決的問題的新的理解和洞察，這種新的認識就有可能導致需求變更。
CMM承認這一事實。實際上，本關鍵過程域的行為3是如此表述這個問題的：
“分配需求的變更被復審，并加入到軟件項目中來�！�
文章來源于領測軟件測試網 http://www.kjueaiud.com/
