典型情境是指軟體開發的常見情境，本文選擇如下來進行分析：
1. 傳統瀑布模型開發下的需求評審
2. 使用IEEE Std. 1028的需求評審
3. 敏捷開發下的需求評審

傳統瀑布模型下的需求評審

對傳統瀑布模型現有需求評審的分析

傳統瀑布模型在需求階段末期安排有關鍵的需求里程碑評審，其特徵參見2.8節情況1。在業界實際操作中，往往出現如下情況：
1，召集包括領導在內的各方代表，歷經1～2小時會議，評審30頁以上需求規格說明書，走過場式各方簽字通過評審；
2，各方對需求規格書有各種各樣意見，歷經3～n次評審會，眼看工期已經有明顯拖延，後續開發已經跟進，甚至開發快完成了，總算獲得通過；
3，經過多方運籌協調，前後費時4周多，召集各方到某度假村，歷經三天討論修改評審，總算通過評審。
以上情況就體現了前文所言的“官僚繁瑣、繁文縟節”，其弊端明顯。在[26]文同樣也識別到：需求評審往往流於形式。
受CMM/CMMI要求和啟發，為了讓需求階段最後的里程碑評審能夠順利通過，需求同級評審得到了使用[12][13]。常見有如下情況：
1，在需求完稿時，計劃一次同級評審會議，關注於技術方面，形成同級評審發現和記錄。這對勝利通過里程碑評審有很大幫助，但往往是更為了應付CMM/CMMI的評估；
2，分階段安排多次會議或非即時的需求同級評審，關注技術方面，記錄評審發現並解決。這是CMM/CMMI比較推薦的做法，能大大緩解瀑布型需求階段里程碑評審的弊端。

綜合以上分析，為便於整體理解，得下表。
表8 瀑布模型下需求評審情況

新需求評審框架對傳統瀑布模型的啟示

啟示1：值得開展定期的雙人即時評審，每次時間約15～30分鐘，適合位置坐在一起的團隊同伴。好處：儘早交流，彼此學習。
啟示2：值得把技術方面評審與管理方面評審分開，先進行各種型別的技術方面評審，然後召開里程碑管理方面評審。好處：技術方面評審問題解決後，需求階段里程碑評審著重於管理方面，比如需求規模、進度、工作量等等，更加關注專案整體成功，也能大大節約會議時間。

使用IEEE Std. 1028的需求評審

對照到需求評審，IEEE Std. 1028中的管理評審、技術評審、審查和走查可以適用於需求評審，而其中的審計不屬於本文所討論的需求評審範疇。

管理評審

IEEE Std. 1028說明管理評審（Management Reviews)用於監測進展情況，判斷計劃和進度表的狀態，或評估為了達成合適目標的管理方法的有效性；管理評審支援關於糾正措施、資源分配變更或者專案範圍變更的決策；管理評審識別與計劃的一致性和差異，或者識別管理流程的完善度和不足度。在需求管理評審的實踐中，最焦點問題是需求範圍和規模是否與計劃相匹配。有些組織在需求之前制定了計劃，那麼需求實際的結果是否需要重新計劃；有些組織把專案整體計劃的制定安排在需求之後，那麼需要判斷前期進展如何，對後面制定計劃有什麼影響。
管理評審有詳盡的規範，從角色、會前、會中、會後、到輸入和輸出等等。它成為IEEE Std.1028首先闡述的評審型別絕非徒有虛名，雖然它有沉重繁瑣的嫌疑，但對於謹慎多幹系人場合，仍然是關鍵里程碑評審的首選甚至是必須的評審型別。在本五維需求評審框架中，管理評審在絕大多數情況下屬於有預審的會議形式里程碑性質的管理方面非同級需求文件評審，它提供了管理方面評審的最系統性的“極點”。

技術評審

技術評審的目的是由合格人員組成的團隊來評價一個軟體產物，以判斷是否適合其預期用途，並識別對比於規範和標準的差異。它為管理層提供證實該專案技術狀態的證據，也可能提供替代方案建議，可能需要一個以上的會議。
同管理評審一樣，技術評審有詳盡的規範。技術評審是最廣為人知的一個評審型別，早在1996年出版的《實用軟體工程》（第2版）[9]對此也有詳細的闡述。在實踐中技術評審常常擔當里程碑評審的重任，而至於管理評審，其關注內容成為技術評審的一小部分，而不再有專門的管理評審。在本五維需求評審框架中，技術評審在絕大多數情況下屬於有預審的會議形式里程碑性質的技術方面非同級需求文件評審，它提供了技術方面評審的最系統性的“極點”。
啟示3：理解管理評審和技術評審在五維需求評審框架中的位置，在實際工作中靈活應用這兩項評審，更加有把握的對其進行適應性的剪裁，使其發揮更高效率，儘量規避為人詬病的沉重繁瑣的弊端。

審查

審查對應的英文是Inspection，其目的是檢測和識別軟體產品的異常情況。審查是一個系統性的同級檢查。審查定義了5個角色，分別是審查領導者、記錄員、閱讀者、作者、審查員。任何審查組成員（包括以上5個角色）的上級都不能參加審查活動。審查應當得到計劃並記錄在恰當的專案計劃文件中，審查開始前需要確認被審查產物是完整的並且符合格式要求，審查後需要記錄評審產物的規模、會中會前時間、返工時間等等。
點評：審查在IEEE Std. 1028得到了嚴格定義，給出了詳盡的規範指導。在本五維需求評審框架中，審查屬於有預審的會議形式完稿技術方面同級評審，同樣是同級評審最系統性的“極點”。 審查要求完整產物，並不能儘早發現問題。
啟示4：值得探索和使用更輕量更高效更及時的需求同級評審。

走查

系統性的走查目的是為了評估一個軟體產品。走查可能也會有讓培訓軟體產品受眾的目的。走查的作用還有交流技術、交流不同風格變化。 走查不僅可以發現異常，也可以指出不足之處（例如，軟體產品的效率和可讀性問題，設計或程式碼的模組化問題，或無法驗證的規格）。參與走查有4個角色，分別是走查組長、記錄者、作者、走查成員，走查至少需要2人。任何走查組成員的行政上級都不能參加走查。走查的最主要活動是作者或走查組長詳細的展現所評審產物的每個部分，走查組識別並提出發現的異常和問題。走查的標準最少輸出物總計有9項。走查不要求產物已經全部完成，可以按需高頻開展。
在本五維需求評審框架中，走查屬於有預審的雙人即時或者會議形式、技術方面的定期或高頻的同級需求文件評審。雙人走查是標準允許的最少人數。雙人走查與會議形式走查其實存在較大的差異：雙人走查可以使用一臺普通顯示器，利用普通能夠坐下兩人的工作位置即可，這樣就能夠高頻按需開展，會議形式往往需要會議室，而會議室在多陣列織是稀缺資源，如果所有專案團隊都開展需求和程式碼會議走查，那麼每二週一次的會議室預訂都未必能夠保證，所以難以按需開展。程式碼走查是常聽到的詞彙，但是需求走查在中文世界很少提到，而在敏捷軟體開發中已經顯示了其有效性。
啟示5：值得探索和使用雙人高頻按需的需求走查或者簡化的需求走查。

IEEE評審小計

綜合以上分析，為便於整體理解，得下表。
表9 IEEE標準需求評審情況

敏捷開發下的需求評審

首先要說明，在敏捷開發語境中，幾乎不使用“評審”這詞，常用“驗證”、“驗收”、“反饋”等。本文將基於文件閱讀或者觀察軟體執行的時效性人工檢查工作定義為評審，符合此定義的敏捷實踐也被視為評審。下文將選取敏捷中典型的需求評審對應實踐來分析。由於Scrum是目前採納最多的敏捷流派，選擇了多個來自於Scrum的實踐來分析，也兼顧了其它敏捷流派。

產品待辦列表的優化

Scrum中，產品負責人（英文：Product Owner，縮寫PO)是管理產品待辦列表的唯一責任人[28]。雖然理論上產品負責人可以一個人單獨建立維護產品待辦列表的全部內容，但多數情況下產品負責人是吸收他人貢獻的，產品負責人然後進行整理排序調整優化等等[21]。Scrum中的產品待辦列表優化（Scrum Guide 2011版中其英文名是Grooming，Scrum Guide2013版中其英文名是refinement）指的是為列表項補充細節、估算和排序。這是一個持續不斷的過程，產品負責人和開發團隊協作討論產品待辦列表項的細節，並對列表項進行評審和修改。對照到本五維需求評審框架，這是定期會議的、技術方面的同級需求文件評審。因為這個過程中就算產品負責人是團隊的行政上級，也是評審物件的主要作者，而不是評審者。
一般的，產品待辦列表細化的結果用於未來的迭代（Scrum中稱為衝刺），其起到的作用相當於瀑布模型中需求階段的技術方面評審，但耐人尋味的是Scrum Guide說“細化的工作通常佔用開發團隊不超過10%的時間。然而，產品負責人可以根據自己的判斷隨時更新產品待辦列表。”，而對於只有1～2次需求評審的傳統瀑布模型而言，需求討論評審會議所佔比例恐怕不超過5%。

Scrum計劃會議第一部分

Scrum中的計劃會議第一部分的問題是：接下來的衝刺（等同於迭代）交付的增量中要包含什麼內容?開發團隊預計這個衝刺中要開發的功能。產品負責人講解衝刺的目標以及達成該目標所需要完成的產品待辦列表項。整個Scrum 團隊為了更好地瞭解衝刺的工作進行討論。對照到新需求評審框架，這是定期會議側重於管理方面的同級需求文件評審，與上述產品待辦列表細化同樣是同級評審。
負責需求的產品負責人與團隊一起交流，聽取處理各種各樣意見建議，在管理評審中反而是被評審的物件，這確實是對傳統做法的大突破，而Scrum的流行也說明了這新做法的有效性。對比到瀑布模型，Scrum中的計劃會議第一部分起到的作用相當於瀑布模型中需求階段的里程碑管理方面評審。值得注意的是，Scrum建議1個月的迭代情況下，計劃會議第一部分約需要4小時，佔比約2.3%，整個計劃會議需要8小時。

Scrum每日站會和燃盡圖繪製

每日 Scrum 站會是以 15 分鐘為限的事件，開發團隊成員在這裡分享各自的工作情況，併為接下來的 24小時制定計劃。這需要檢視上個每日站會以來的工作和預測下個每日站會之前所能完成的工作[28]。一般的，Scrum團隊每天繪製衝刺燃盡圖，在衝刺中每日繪製本衝刺未來剩餘的工作量，而此工作量是根據使用者故事或者用例來預測估計的，使用者故事和用例都是需求表達的形式。所以這也相當於需求管理評審，具體對應到新五維需求評審框架，這是會議形式高頻管理方面同級需求文件評審。

敏捷開發過程中需求的澄清和確認

在敏捷開發環境下，由於不要求在開始時就有一份完整詳細的需求說明，所以在開發過程中就需要諸如現場客戶或客戶代表來澄清和確認需求。這是各敏捷流派共有的實踐。敏捷方法鼓勵面對面的交流，所以開發過程中對需求的澄清和確認往往採用桌查，這其實也是一種需求評審的形態，對照到新需求評審框架，這是雙人結對即時高頻技術方面同級評審，而且不再僅僅基於需求文件，還可以基於軟體執行來判斷需求是否得到滿足，雖然也許不能完全執行，但能夠部分執行，能夠展現介面或介面。在Scrum中，產品負責人承擔響應此類評審（澄清解釋並按需要修改補充）的責任，這個過程中，就算產品負責人是團隊成員的行政上級，也是按同級的身份參與。
這同樣是最高效率的需求評審型別之一，最高效特徵有交流反饋快，顆粒度小，針對性強，甚至可結合半成品或者成品來核對。
啟示6：需求分析人員和開發人員值得在開發過程中，結合半成品或者成品進行需求桌查，能夠更早更快的避免需求理解偏差帶來的缺陷。

迭代展示

迭代展示是各敏捷流派共有的實踐，常見的做法是在迭代末期向各方干係人展示迭代的成果，甚至直接交付給使用者試用或使用。Scrum對此環節有清晰的定義，即是其衝刺（等同於迭代）評審會議：衝刺評審會議在衝刺結束時舉行，用以檢視所交付的產品增量並按需調整產品待辦列表；在衝刺評審會議中，Scrum 團隊和相關干係人討論衝刺中完成的工作；然後，根據完成情況和衝刺期間產品待辦列表的變化，與參會人員討論接下來可能要做的事情來優化價值[28]。值得說明的是對於典型一個月的衝刺，其衝刺評審會議的時間箱是4小時。衝刺評審會議可以算作為需求評審和給客戶展示演化的原型[21]。對照到新五維需求評審框架，這是無預審的會議形式、定期的、側重於管理方面也兼顧技術方面、基於軟體執行的非同級評審。
這樣的評審也是最高效率的需求評審型別之一，其高效特徵有需求以直觀執行方式展現，客戶或者客戶代表參加，當場收集反饋，當場根據反饋來計劃未來。
啟示7：讓客戶或者客戶代表定期結合軟體執行來進行評審，更加直觀更能發現改進，可以讓客戶更加滿意。

敏捷需求評審小結

綜合以上分析，為便於整體理解，得下表。
表10 敏捷開發下常見需求評審相關實踐情況

可以看到，敏捷軟體開發常見的需求評審竟然沒有采納任何一種標準評審，頂多可以說對審查和走查有所借鑑。
啟示8：為了更高效且更高質量的開發軟體，敢於突破原有需求評審標準和權威指南，敢於尋求更高效率的需求評審方式方法。
啟示9：根據啟示8，結合此新五維需求評審框架，結對定期需求文件或軟體執行管理評審是值得推薦的新評審方式。具體是指管理者每幾天或每週或每雙週與開發人員結對來評審需求相應的狀態、進度、困難和風險，具體形式可以採用師徒制、主程式設計師制[29]、一對一會議等等。
啟示10：根據啟示8，結合此新五維需求評審框架，非即時按需高頻需求文件技術方面同級評審也是值得推薦的新評審方式。結合需求條目化管理工具，可以實現逐個需求的同級評審。下文第4章有更詳盡分析。
啟示11：根據啟示8，突破此五維需求評審框架，值得尋求其它更高效更人性化的需求評審方式，比如將遊戲做法、積分升級等等引入到評審中。

新需求評審框架對敏捷方法的啟示

啟示12：Scrum對於管理評審的應用是關注於當前和下個迭代，缺失對整體更長過程的關注。雖然已經有在Scrum中補充了釋出計劃和釋出燃盡圖，但並沒有明確定義如何評審或校驗，因此值得開展關注整體產品更長時間範圍發展的定期管理評審會議。