為什么要管理軟件需求
簡單講，軟件開發團隊的成功就是滿足軟件項目的需求。當今世界對軟件的依賴程度急劇增長，面對質量和交付周期的固有矛盾以及各種動態因素的綜合作用，軟件需求日益復雜，軟件開發成為一項跨越技能、職責范圍和時間階段的綜合團隊活動，協調統一是成功的必要條件。軟件需求是統一的核心線索，需求管理正是協調的必由之路。
嚴格意義上，需求是系統或軟件必須達到的目標和能力;需求管理是一種系統方法，用來獲取、組織和記錄需求，建立并維護客戶、用戶和開發機構之間針對需求變化的協議。
眾多的實踐證明，良好的需求管理對于降低開發成本和保障項目成功至關重要。根據權威機構的統計，在全世界范圍，僅有1/4的軟件開發項目能在規定的時間和預算內達到客戶的目標�？v觀這些項目各自總結出的十項首要成功經驗，我們總能找到三個要素: 有效的用戶參與，明確的業務目標和穩定的基本需求。這三個要素的核心內容是軟件需求，其核心活動是需求管理。
CMM2對軟件需求管理的指導
針對如何提高軟件質量和開發效率，CMM為我們提供了一套的綜合見解和完整的框架，CMM對軟件開發機構投入產出比(ROI)的卓著貢獻已經得到業界的廣泛認可。
需求管理是CMM2級的首要關鍵過程領域(KPA)，是軟件開發活動中不可或缺的組成部分。需求管理的目的是在客戶和開發機構之間建立一個共識，形成軟件工程所必須的管理基線，從而對需求實施有效的控制。在軟件開發活動中，所有的活動計劃，日程安排，交付工件都要直接或間接地和需求保持一致，這是貫穿于CMM體系中的一個重要理念和準則。只有基于這種準則，軟件開發組織才有可能進入渾然一體的境界：軟件的技術需求，項目計劃以及各項相關活動協調一致，井井有序。為了實現這一目標，開發組織需要付出的努力是多方面的。
最基本地，經過相關涉眾(涉眾：會受到作為結果的目標軟件系統實質性影響的個人。)審閱的軟件需求必須形成"文檔"。對"文檔"的理解不應僅局限于平面化的文字文檔，文檔的存在形式可以是多種多樣的，關鍵是文檔所記錄的內容能夠為不同工種提供可用的信息依據。軟件需求規約(SRS)作為項目的核心文檔，用以全面詳實地定義軟件需求的要素。另外，面向客戶和最終用戶的通用詞匯，描述軟件產?quot;做什么和為什么做"的高層次規約也很重要。
為了達到有效管理軟件需求的目標，開發機構必須投入必要的人力、資金和管理層支持。軟件工程團隊的成員和不同工種的團隊成員應當接受必要的培訓，以便完成與角色相應的需求管理任務。培訓的內容要覆蓋過程方法，標準以及針對應用領域的一些特殊問題。
軟件需求的變更應當作為項目計劃的有機組成部分被審閱。需求變更所牽涉的人員能夠通過有效的機制來磋商和評估由于變更導致的影響。針對磋商和評估活動中的權衡和分析工作，CMM建議我們至少要掌握三個方面信息: 軟件需求的狀態，軟件需求的變更內容和累計變更次數，待決定的、被建議的、被批準的以及被融入基線的軟件需求變更的個數統計信息。
CMM3對軟件需求管理的指導
根據CMM的建議，不應將需求管理當作瀑布式的簡單文檔化流程。CMM的一個顯著的特征是將軟件需求作為一個活躍的實體貫穿于整個開發過程之中，實施有效的需求管理事實上滲透在CMM的不同層次(Level)和眾多關鍵過程領域之中。
對于那些準備通過CMM3級評測的開發機構而言，基于一種被定義和文檔化的標準實踐流程從事軟件開發活動是工作的重點，該級別涉及到七個關鍵過程領域。其?quot;軟件產品工程"一項旨在有機整合各項活動，目標是快速有效地生產高質量的軟件產品。該關鍵過程領域中明確指出: "軟件需求的獲取、維護、歸檔和校驗有賴于系統化的分析，這種分析要以項目所定義的軟件開發流程為根據。"該分析過程的目的是保證軟件需求自身的有效性。
關鍵過程領域"軟件產品工程"中還明確指出: "一致性的維護要貫穿軟件開發過程中的各種類型的工件(工件：由軟件開發流程所生成或使用的一組信息。)，包括軟件開發計劃，過程描述，需求信息，軟件設計，編碼，測試計劃，以及測試流程。"根據CMM的指導，各種有價值的軟件工件都需要歸檔和維護以確保其可用。
根據CMM的建議，軟件需求的變更被接受為軟件開發活動中的一個必然組成部分�！皟鼋Y需求規約"的做法顯然已經不能適應當今的商業環境和技術環境。取而代之的做法是建立相對穩定的軟件需求基線，并將其融合到系統化的開發活動當中，以確保對需求變更的控制能夠跨越不同工種和覆蓋整個生命周期。
CMM給出了幾點針對性的指導建議: 變更需要經過提請，分析并且在合適的條件下被整合;需求的變更得到批準并加以整和之后，相應的工件和活動才能變更;在變更發生之前確定該變更所帶來的影響，團隊之間要針對變更進行必要的溝通和協商;所有的變更從始至終被跟蹤。在以需求為核心線索的開發過程中，確保所有的需求變更從始至終被跟蹤是掌握開發活動來龍去脈的基本保證。需求的修訂要被一組具有代表性和權威性的涉眾代表審閱并認可后方可得到批準，這樣能夠確保在修訂的需求中體現出不同背景和立場的影響力。涉眾包括客戶，最終用戶，項目管理人員以及軟件測試人員等。
根據CMM的要求，所有被批準的變更都要被從始至終地記錄在案，用作記錄相關信息的文檔也要接受控制和管理。此外，我們還需要掌握用以確定軟件產品功能、質量及開發活動狀態的信息。 總 結
作為一種廣泛的和具有影響力的軟件過程控制和評估框架，CMM只有映射到一個具體的系統化軟件流程中才能體現出其真正的價值。換言之，準備通過CMM評估的開發機構應該以現有的流程和方法作為改進和優化其流程的基本出發點。
在軟件需求管理方面，對于準備通過CMM2級評測的開發機構，團隊應將注意力放在以下幾個方面:
* 軟件需求必須形成文檔;
* 軟件需求必須能被控制，進而建立工程和管理的基線;
* 成員必須接受需求管理培訓;
* 建立衡量需求狀態的信息。
對于準備通過CMM3級評測的開發機構，應將注意力放在以下幾個方面:
* 對需求進行系統化分析，確保軟件需求完整性，一致性和可測試性;
* 軟件需求、設計、編碼和測試用例都能夠回溯到相應的源頭，在需求發生實質變更之前能夠判別該變更所帶來的潛在影響;
* 需求的修訂應遵從統一的流程，需求的變更應從始至終被跟蹤，軟件需求文檔應當通過配置和變更管理工具進行管理。
最后要強調的是，過程成熟度水平是衡量機構開發流程成熟度的標準，不應該被當作開發流程改進的奮斗目標。開發機構切忌本末倒置，應該以現有流程為基礎，實事求是地改進、優化各項具體工作，參照過程成熟度模型全面提升開發機構的需求管理能力。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
