典型情境是指軟件開發的常見情境，本文選擇如下來進行分析：
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 敏捷開發下常見需求評審相關實踐情況

敏捷中需求評審相關實踐需求評審框架分析說明

Scrum中產品待辦列表細化	無預審的會議，定期，技術方面，同級需求文檔評審
Scrum中計劃會議第一部分	無預審的會議，定期的里程碑，管理方面，同級需求文檔評審
Scrum每日站會和燃盡圖繪制	無預審的會議，每日高頻，管理方面，同級需求文檔評審
敏捷開發中需求澄清和細化	雙人，按需高頻，技術，同級評審，基于軟件運行
迭代展示	無預審的會議，定期，技術方面和管理方面兩者都有，非同級評審，基于軟件運行

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

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

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

總結

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

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