分析階段：“準備需求采集和分析”
管理要求：
�、� 閱讀有關行業/技術概念上的背景資料或相關標準、公文、規則等等
�、� 熟悉客戶的操作流程
�、� 確定信息采集和分析的方法
�、� 確定用戶組和評審組，及評審方式
�、� 項目風險的評估
大部分的需求調研中，以上的準備工作常常被忽略，在這次的操作中，雖然注意了該方面的運作，但還是出現了一些問題，影響了需求調研的工期。首先，確定信息采集和分析的方法，由于該系統是客戶方的一個類似商務操作流的控制系統，在收集信息過程中，我們過于相信客戶方最初提供的資料，在熟悉客戶的流程后，依照客戶方提供的資料進行項目的初步成本、工期、資源的核算。但是，在后面的調研時，客戶業務流程發生較大的變動，細化點眾多，功能點較原先估計的繁雜。出現這樣的問題原因在于：1、客戶原先手工操作無任何限制，而系統約束性較高。2、在需求調研中客戶方發現其流程存在不合理的地方即產生變動，變動性大(該點我們無法控制)。3、與我們進行溝通的客戶方人員無決策權。雙方在討論一個流程的實現過程中，對方無權對流程的簡、繁進行決策，往往討論半天實現該功能后，其部門經理一句話就推翻原先擬定的流程，在這點上浪費了許多時間，這也是我們準備過程中的一個失誤，當初應該事先申明，溝通人員必須有一定的決策權(這是在確定用戶組上的失策)。
當在熟悉、確定客戶操作流程上，我們浪費了很多時間，至后來雙方在溝通及決策上達成一定的協議后，后期的調研工作順利很多，但最終產生的系統需求與原先客戶提供的需求已經是截然不同的了，最終需求得出的成本、工期、使用資源都已翻了好幾番。
分析階段：“收集和分辨需求”
管理要求：
�、� 分辨技術(功能點)與非技術(交貨日期、里程碑、協議條件等)需求
�、� 建立系統目標和范圍
�、� 收集相關技術需求(功能點、約束、處理等)
�、� 收集用戶特殊需求
�、� 分析用戶工作流程
�、� 準備原型
該階段工作較順利，基本上按要求完成，其實該階段與第一階段―――“準備需求采集和分析”基本上可融合，故在雙方按一定要求達成溝通協議后，在業務流程及功能點收集上進展較順利，準確性也較高。
分析階段：“分析—編寫文檔—評審”
根據收集到的功能需求，接下來，項目組各人分工進行模塊功能需求的分析工作，按模塊的操作角色、模塊功能、輸入、處理流程、輸出等進行技術需求的細分析，該部分與編寫文檔同步進行。在進行分析及編寫文檔時，為了確定較準的最終功能需求，分析做得比較細，可以避免后期與客戶的糾纏不清。分析時用UML畫的業務流圖在與客戶溝通時發生一點問題，客戶無法看懂其圖內容，故建議以后項目內部溝通分析時采用UML用例圖及流程圖，與客戶進行溝通時使用通用的流程圖較方便。當各模塊的分析文檔完成時，單單模塊功能就寫了160多頁，其中還不包括近五十張報表的分析數據。此時的功能需求與原先客戶給的9頁的需求已經大相徑庭了。最終整合的需求依照“CMM系統需求規格說明書模板”進行編寫，由于在每個模塊分析時均注上標號，便于其后需求變更的跟蹤及修改。
評審時準備采用CMM軟件質量保證過程要求的“系統需求分析過程評審檢查列表”，實際評審中與列表要求的還是會有一定的距離，標準度及執行度暫無法做到CMM完全要求的，只能盡量往其中的要求點靠攏了。其中“系統需求分析過程評審檢查列表”的基本內容要求如下：
____軟件需求分析被記錄在軟件需求說明書或者其他經核準的正式文檔中
____軟件來源的明確性
____對于用戶給定的需求，文檔記錄是否完整及有遺漏項
____軟件需求在配置管理下維持(配置標識)
____文字說明清晰、適當
____前后一致，變更依據是否充分，是否有正常的記錄
____功能的可測試性
____評估需求的可行性，是否適用于軟件實現
____軟件開發計劃、工作產品，以及活動的變更與軟件需求的變更相一致
____驗收被制定，并且使用來確定需求管理的狀態
在評審中，以上的要求可以起到一定的引導作用。
分析階段：“交付驗收”
在交付給用戶驗收時，所需附上的產品有：各模塊的功能分析文檔、整合的需求規格說明書、需求驗收文檔。
管理要求：
�、� 客戶對確定的需求無疑異，在驗收文檔上簽字
�、� 若客戶提出相應的變更，則為變更做好記錄，修改后的變更依然應通過評審才能交付用戶。
�、� 客戶簽收的需求作為系統的需求基線確立下來，
分析階段：“需求變更過程”
該過程主要針對確立需求基線后的變更。目前該項目還未涉及(待續!)
管理要求：
�、� 提出變更請求(變更項、變更原因)
�、� 變更可行性評估
�、� 變更評審
�、� 更新基線
CMM過程中有一個詳細的“日常工作變更請求過程樣例”，日后有機會再細談該變更的管理過程及實現方式。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
