本文試圖歸納分析近年來出現的需求評審方式方法，全面涵蓋系統性評審和非系統性評審，提出五維需求評審框架。

---

首先確定對于需求評審的定義，結合傳統需求階段評審和敏捷迭代開發中相關需求實踐，得如下定義。
定義1(需求評審). 需求評審是指基于需求文檔閱讀或者觀察軟件運行并且對當期工作有時效性的人工檢查。

根據以上定義，需求評審的范疇不包括機器自動檢查，不包括需求審計；包括了需求上線后的校對，包括了系統性需求評審和非系統性需求評審。觀察軟件運行與測試有部分重疊，但并不是測試，比如說有些觀察時，鼠標和鍵盤在演示者手中，而有些觀察是在試用。
本章分析識別需求評審的5大關鍵方面，分別是：1，組織形式； 2，時機； 3，側重； 4，評審者；5，評審對象。下文進行一一說明。

需求評審的組織形式分類

表1 需求評審組織形式分類表

組織形式分類說明

非即時評審	將需求發送給1位或多位評審者，評審者獨立的進行評審，返回評審發現，不安排會議。其優點：成本最低，評審者時間安排靈活，缺點：響應慢，交流不充分，容易馬虎。
結對評審	雙人在可全程實時口頭交流的情況下，包括面對面、遠程語音或視頻，進行需求評審[22]。結對是來自于英文Pair, 僅指雙人即時交流，并沒有固定結對的暗示。優點：面對面交流反饋快，互相啟發，可深入交流，缺點：需要協調兩個人的時間，可能激化潛在的人際沖突。
有預審的會議評審	會議形式，參會人數多于2人，評審者在會前預審，作者和評審者在會議中交流探討。優點：業界已經積累了許多評審流程[10]，會前會中會后都有相當成熟的指導，各方交流較充分，能得到正式結論，缺點：協調多人時間，總工作量比較大。
無預審的會議評審	會議形式，參會人數多于2人，作者和評審者在會議中交流探討。優點：較之有預審的會議，省去了預審，節約工作量，會議上各方交流較充分，也能得到正式結論，缺點：協調多人時間，總工作量較大，由于沒有預審，不排除會上需要更多時間來說明情況，甚至出現存在明顯理解差異，導致會議失敗。

說明：非即時評審加上無預審的會議評審將組合得到有預審的會議評審。

需求評審的時機分類

需求評審時機分類是區分何時進行需求評審。
表2 需求評審時機分類表

時機說明

里程碑評審	需求完稿后，關鍵各方參加評審，一旦通過，就進入下一階段工作。順利的話，只需一次需求里程碑評審。
非里程碑	完稿評審 需求完稿后，為確保里程碑評審通過，先進行的評審，可以分部分進行。為方便計，以下簡稱完稿評審。
分段評審	按時間分段進行，提前發現并解決問題。
定期評審	定期進行評審，其頻度要高于分段評審，一般高于等于每月一次，低于等于每周一次，比如每周、每雙周、每月。
高頻按需評審	按照需要，頻繁的開展，比如針對指定功能的桌查，每天或每幾天發生，頻率高于每周一次。以下簡稱高頻。

需求評審的側重分類

需求評審側重分類是區分是從技術還是從管理角度來評審產物。
表3 需求評審側重分類表

側重說明

技術方面	從需求技術角度來評審，發現需求技術方面問題，比如錯漏、模糊、前后矛盾等等。
管理方面	關注于需求開發與管理的過程規范、進度、規模、工作量、成本、前期評審情況等等

需求評審的評審者分類

需求評審的評審者分類是區分上級是否參與評審。
需求評審者分類表

評審者說明

嚴格同級	也稱同行，這樣的評審不直接影響作者和評審者績效考核，可以讓作者和評審者更自如的表達，讓評審者更客觀的評審，作者、評審者之間沒有任何上下級關系，即是作者不是任何評審者的上級或下級，評審者之間也沒有上下級關系。
無作者上級或稱同級	評審者中沒有作者的上級，評審者之間可能存在上下級，最新CMMI for DEV V1.3中沒有采用嚴格同級來實施同級評審，只說明了由作者的同級人員來實施同級評審[23]，而在實踐中不少的同級評審包括有作者的下級，這不違背“使用同級評審數據來評價人員的績效”的禁令[23]。這是最常見的同級評審形態，下文的同級評審是指無作者上級的評審。
含作者上級	評審者中包括作者的上級。評審表現可能被上級用于評價人員績效。下文有稱為非同級。

需求評審的對象

需求評審的對象分類是區分不同的評審對象
表5 需求對象分類表

對象說明

需求文檔	各類需求文檔，比如需求規格說明書，用例分析，用戶故事等等，在CMMI的過程域分類下，屬于驗證，處理的是工作產品是否適當地體現了規定的需求，確保“正確地做了事”。優點：能夠較早的開展，提前發現問題，大大降低后續修復缺陷的成本；缺點：不夠直觀，尤其難以判斷交互易用性。
軟件運行	軟件運行提供直觀的操作場景，包括原型、敏捷迭代可交付物，值得說明的是界面原型也屬于軟件運行范疇，雖然界面原因可能無法真正運行，但其能演示操作場景。在CMMI過程域分類下，屬于確認，證實產品在被提供時（或者在其將被提供時）能滿足其預期的用途，確保“做了正確的事”。優點：直觀展現實現的需求，可以更好的判斷需求，尤其是交互易用性（usability）[24][25]；缺點：得到可運行軟件需要等待較長的時間。

關于正式和非正式評審

不少文獻使用正式評審和非正式評審對評審分類[26]，這有部分是對于IEEE Std. 1028中systematic review和non-systematic review的翻譯，也有對CMMI DEV V1.3中“formal and informal reviews”的翻譯[27]。但是部分組織在實際命名本組織的評審方式時，直接采用“非正式評審”和“半正式評審”作為評審名稱，這樣的名稱在實踐中帶有強烈的馬虎、不作數的暗示，導致“非正式評審”“半正式評審”不能發現有價值的問題，往往是為了走評審流程而形式主義開展這些評審。作為嚴謹、專業的做法，在中文環境下不應當將評審命名為“非正式評審”和“半正式評審”。應當采用專門能描述評審特征的名稱來命名，比如本文提到的各類稱呼。本文所識別框架沒有采用正式、非正式作為分類，本文認為所有的評審都應當是正式的，哪怕比如說是雙人隨時發起的沒有任何記錄的桌查，或者團隊15分鐘需求狀態一覽會議，這些只是采用了不同的評審方式方法。

需求評審框架組成

以上識別的5個最關鍵維度組成了需求評審的如下表的五維需求評審框架。
表6 五維需求評審框架

維度說明常見情況

組織形式	如何來組織評審	非即時，結對，有預審的會議，無預審的會議
時機	何時舉行評審	高頻次按需，定期，分段，完稿，里程碑
側重	評審主要關注的方面	技術方面，管理方面
評審者	評審中可以提出意見的人員	嚴格同級、同級（評審者不含上級），評審者含上級
對象	評審的目標對象	需求文檔，軟件運行

可以看到各種各樣的需求評審都可以按此框架來進行分析解釋，也可以從此框架中尋找發現適合不同情境的有效需求評審方式方法。按以上框架中5個方面的分類，其組合總共有4×5×2×3×2=240種。可能有讀者看到這里會認為，有些組合在現實中是不會出現的，比如高頻結對管理方面評審，但是套用一句廣告語“沒有不可能”，下面將分析已經存在各類需求評審。下文也將繼續探討在不同情境下如何靈活應用，如何搭配得到高效組合，識別新的評審方式方法。

常見的需求評審舉例

為了便于理解以上各方面分類，請看如下常見的需求評審。
表7 常見需求評審情況

典型情況情況1情況2情況3情況4情況5

常見稱呼	需求里程碑評審會	需求分別同行評審	需求結對評審	需求分段同級互查	需求管理評審
組織形式	有預審的會議	非即時	結對即時	非即時	有預審的會議
時機	里程碑	完稿	定期	分段	里程碑
側重	技術為主+管理為次	技術	技術	技術	管理
評審者	含上級	同級	同級	同級	含上級
對象	需求文檔	需求文檔	需求文檔	需求文檔	需求文檔

上表中情況1的需求里程碑評審會就是傳統瀑布模型中的需求評審會。

總結

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

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