摘要 近年來隨著CMMI、敏捷軟件開發的推進，出現了多種多樣的需求評審類型，這些類型超出了標準評審類型的范圍。根據這些情況進行分析，得到了一個新的軟件需求評審框架，這個新框架由5個維度組成：
1，組織形式；2，時機；3，側重；4，評審者；5，對象
分析了分別在傳統開發和敏捷開發下的典型需求評審情境，顯示新框架能夠適用于所有系統性的和非系統性的評審類型上。從分析中得到了15個有價值的啟示。新需求評審類型的設計和對需求評審類型的選擇可以從這個新五維需求評審框架中受益。根據啟示，得到了一個多級小瀑布生命周期模型，這個新模型可以大幅度的優化傳統瀑布生命周期模型，具備靈活的自調整自適應能力。
關鍵詞: 需求變更; 需求評審; 需求條目化; 多級小瀑布; 需求工程

在軟件開發中，需求變更被視為導致軟件開發失敗的主要原因。早在1988年BILL CURTIS等人的研究表明：需求的沖突和變化對于生產效率和質量存在巨大影響，識別到學習、技術交流、需求協商和客戶交流是非常關鍵的過程[1]。這些過程在當時的軟件過程模型中描述得非常糟糕，而當時的軟件過程模型把重點放在了如何通過一系列的產物（比如需求功能規格說明，代碼，等等）來得到軟件產品。當時的軟件過程模型對實際的軟件開發沒有提供足夠的用于指導軟件開發技術研究的洞察力，這些模型只是描述了一系列開發任務，而對以下事情沒有幫助：項目團隊成員必須要學習哪些新信息；如何協商不一致的需求；設計團隊如何解決架構的沖突；這些因素及其它類似因素是如何影響項目本身的不確定性和風險。雖然時光過去了整整27年多，但是這一段文字在今天讀來都仍然讓人感覺汗顏。
在1988年以前，瀑布型生命周期模型（下文簡稱稱為瀑布模型）是占主導地位的生命周期模型，從時間上可以合理的推斷[1]文中所說的當時軟件過程模型就是以瀑布模型為主。而在[1]文中提到了螺旋模型-“Boehm的螺旋模型是一種很有前途的從宏觀層面來管理這些問題的嘗試”。螺旋模型的特征是快速原型迭代增量進化并結合風險分析[2]。
復雜軟件系統中分析和處理可能存在不一致的需求描述,這解決得好壞直接影響到需求規格說明的質量,進而影響到最終軟件產品的質量[3]。為了在需求方面克服不一致和變更問題，需求評審成為試圖解決此類問題的第一道關口：在需求階段或需求活動時就馬上識別到需求不一致，這樣修復成本是最低的。人們對此開展了大量的研究[4][5]。但是直到最近幾年的研究，需求變更導致軟件開發延期甚至失敗仍然是困擾軟件行業多年的老大難問題[6][7][8]。
源于瀑布模型的傳統軟件需求評審發展得很全面規范[9]，其中最突出的代表是IEEE軟件評審和審計標準Std.1028[10]，最早版本是1028-1988，歷經1028-1997，當前最新版是1028-2008，最新版IEEE Std. 1028-2008對比1997版沒有本質性差異[10]。在最新版中，仍然是定義了5類評審審計，分別是管理評審（Management reviews)、技術評審（Technical reviews)、檢查（Inspections）、走查（Walk-throughs）、審計（Audits）。這些類別都是系統性的（英文原文是“systematic types of reviews and audits”），不符合此標準的其它評審類型都是非系統性的。顯然的，還有許多非系統性的評審類型，IEEE Std 1028-2008說明：“本標準無意阻止或禁止使用的非系統性評審”,“判斷一個評審或審計必要性的流程沒有定義，并且沒有說明評審或審計結果的處置”，“本標準沒有建立對于實施具體評審的需要，這些需要定義在其它軟件工程標準或本地流程中”，“本標準的使用者應說明何時何地使用本標準與及任何的故意差異”[10]。所以，IEEE Std. 1028并沒有完全解決上述問題，留出了大量的空白需要填補。而確實在實際的軟件開發中，就算是需求文檔得到了正式批準，遭遇需求變更仍然是經常性的[11]。
自1991年起，軟件能力成熟度模型(Capability Maturity Model，簡稱CMM)在全世界范圍內廣泛傳播，2002年能力成熟度模型集成(Capability maturity model integration，簡稱CMMI）發布，2006年，CMMI全面替代了CMM，至今CMMI得到全世界大范圍的使用。在CMM3/CMMI3中，同級評審（也稱同行評審或者同級互查）是其要求[12][13]，隨著CMM/CMMI的推廣，同級評審也被應用到包括需求文檔在內的各類工作產物中，對傳統的需求評審帶來了變化[14]。
傳統的基于文檔和文檔評審的方法在2001年起的敏捷運動中被視為官僚繁瑣、繁文縟節[15]，而在敏捷首先著力的需求領域，IEEE Std. 1028簡直就是“罪魁禍首”。而最近十多年來，敏捷軟件開發帶來了新的變化，提出擁抱變化，不再假設軟件需求可以被凍結[16]，傳統的需求評審方法在敏捷環境下已經不再奏效[17]，而敏捷軟件開發確實帶來了很好的效果。敏捷軟件開發的特征有迭代增量開發、軟件盡快可運行、短距溝通、業務方參與和快速反饋[18]，簡直是針對了1988年BILL CURTIS等人所識別的問題[1]。另外也明顯可以看出敏捷軟件開發與螺旋模型存在淵源關系[19]，讓人不得不感嘆BILL CURTIS等人早在25年前的先見之明。
但是敏捷軟件開發各個流派對需求管理方法各異，實際效果并不完全盡如人意，仍然存在不少爭議和模糊的地方。而以瀑布模型為核心的傳統開發方式，對于有些組織而言是雖然難以（也許也不必）轉換成敏捷短迭代開發，但也從近年來的敏捷發展中獲得了啟示，出現了新變化，就需求評審領域出現了更加高效的評審方式方法，將在下文進行說明分析。
1995年Kim, Lesley Pek Wee等人發表了《一個軟件開發技術評審的框架》[20]，對當時出現的各類技術評審、審查和走查進行了分析，歸納了其框架，但顯然的此框架不可能覆蓋后續出現的新情況。而自敏捷開發在全球的推進傳播，已經有許多研究表明敏捷開發其實同樣是符合需求工程的宗旨[21]，但卻沒有歸納整理傳統需求評審和新出現的需求評審（需求驗證確認類的實踐）之間的框架或者結構。

總結

以上是生活随笔為你收集整理的需求评审五个维度框架分析及其带来的启示-总起的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。