3. CMMI級別三的需求管理
在CMMI級別三中，組織需要建立、歸檔所有項目中所使用的公共的和一致的流程。
過程域：需求開發(fā)
需求開發(fā)過程將解釋如何抽取責任人的需要、導出用戶的需求聲明，并把這些用戶需求進一步分析/總結成為相應的系統(tǒng)需求。
CMMI對需求開發(fā)定義了以下幾個目標：
組織必須能夠將收集來的責任人的需求轉換成用戶需求
CMMI中建議：
“將收集來的責任人的需要，期望值，約束條件和接口定義轉換成用戶需求。”
在一般情況下，責任人的需要并沒有被很好地定義和理解，這些需要甚至可能是不一致或相互矛盾的。一個責任人的典型代表必須參與產(chǎn)品開發(fā)的整個生命周期。在這個生命周期中，必須反復地定義，闡述和明確這些需求，最后總結出一組清晰的，被正確理解的用戶需求。
以上過程非常類似于邀請客戶代表進入項目隊伍參與全周期的開發(fā)工作。此外，對需求采集和闡釋的技巧也是極其重要 的，目前較流行的是Use Cases方法。Use Cases方法是一套在不同的使用場景下，從用戶的角度出發(fā)，構造和記錄功能性需求的方法。單個的UseCase只能記錄簡單的文本，最好的方式是使用 UML中的Use Case視圖對一組UseCases進行描述，并表示它們之間的相關關系。
因此，需求管理工具必須能夠支持在文本說明的需求聲明中插入相關的UML視圖，并可將文本和視圖同時顯示在一個文檔中。
組織必須可從用戶需求分析出系統(tǒng)需求
CMMI中建議：
“對用戶需求進行推敲和細化以開發(fā)出對系統(tǒng)需求。”
對用戶需求進行徹底的分析，識別出所有已暗示但沒有被清晰表述的需求，再結合所開發(fā) 目標產(chǎn)品的技術架構細節(jié)，可得出該產(chǎn)品的系統(tǒng)需求。系統(tǒng)需求根據(jù)產(chǎn)品的規(guī)模和復雜度，可細化成系統(tǒng)需求、子系統(tǒng)需求、模塊需求等。在這個過程中，必須同時 建立起不同需求之間的可追蹤性，為后續(xù)的決策指定提供參考，并支持需求變更影響度分析。
根據(jù)CMMI要求，在技術架構的基礎上，通過對用戶需求的分析可推導出系統(tǒng)需求。因此，需求管理工具需要支持實 現(xiàn)這種推導，這種推導的支持不僅包括在不同層次的需求之間創(chuàng)建可追蹤性，還包括提供可分析上層需求的技術和相關方法。在UML建模方法中，可通過 UseCase視圖,Activity視圖和Sequence視圖等有效的方法來幫助分析和導出新的需求，上層的技術架構通過Architecture視 圖（也稱為復合結構）進行描述。這些方法都要求在需求文檔中建立模型，用來記錄分析和決策過程，從而為下一步提出開發(fā)技術方案提供指導。
組織必須能夠驗證需求
CMMI中建議：:
“需求必須可以被分析和驗證，同時必須開發(fā)出對“必需的功能性”的定義。”
當那些非正式的需要轉化為正式的需求時，需求的分析和驗證對于確定責任人需要、用戶需求、系統(tǒng)需求等是否可行，是否可以在預算范圍內達到，是否跟當前系統(tǒng)運行環(huán)境相匹配都是非常必要的。
用于需求分析和驗證的技術包括按時間順序的使用場景驗證需求，并提推導新的需求。場景方法是一種有效的采集，闡述和推導需求的方法，在這個方法中我們常用UML中的Activity視圖或Sequence視圖來表示場景。
“必需的功能性”的定義是通過功能性分析建立起一整套功能性的架構。功能性分析描述了系統(tǒng)的行為，時序活動，輸 入輸出以及其他所有對該系統(tǒng)應用的描述。功能性架構則從邏輯上描述了一組功能（或服務）和需求是怎樣相互滿足的。UML的Activity視圖能夠從工作 流的角度描述系統(tǒng)的活動行為，并且可以識別負責這些工作流的相應組件，這些視圖在描述功能性分析，以及將需求進一步分配到子系統(tǒng)級別時非常