摘要 近年來隨著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]，但卻沒有歸納整理傳統需求評審和新出現的需求評審（需求驗證確認類的實踐）之間的框架或者結構。