軟件需求是軟件開發(fā)的最重要的一個輸入，需求風險也常常是軟件開發(fā)過程中最大的一個風險，降低需求風險的一個重要手段就是需求評審，但是需求評審是所有的評審活動中最難的一個，也是最容易被忽視的一個評審。筆者曾經(jīng)歷過以下的幾種失敗的需求評審：
　　案例一
　　某領域?qū)＜褹先生就某企業(yè)的成本管理系統(tǒng)做用戶需求報告的評審工作，在評審會開始時間不長，就被在場的某企業(yè)的一位副總B先生打斷，認為A先生提出的方案不適合本企業(yè)，A先生提出的管理改進方案在企業(yè)中無法實施。該副總提完意見后，與會的用戶方人員紛紛跟隨B先生的提出了他們的反對意見，致使評審會無法再進行下去，最終該報告被用戶否決。
　　案例二
　　某軟件公司內(nèi)部舉行產(chǎn)品的需求評審會，主要是公司內(nèi)部的相關領域的專家參加，在評審會開始后不久，某領域?qū)＜揖蛯π枨髨蟾嬷械哪硞€具體問題提出了自己的不同意見，于是，與會人員紛紛就該問題發(fā)表自己的意見，大家爭執(zhí)不下，結果，致使會議出現(xiàn)了混亂狀況，主持人無法控制局面，會議大大超出了計劃評審時間。
　　案例三
　　某軟件公司為某公司A做業(yè)務流程管理系統(tǒng)的需求評審會，當項目組人員在會議上宣讀多達上百頁的需求報告時，用戶明確提出聽不懂，致使會議不得不改日進行。
　　案例四
　　某軟件公司在用戶處開完物資管理系統(tǒng)的需求評審會后，與會人員在離開會議室時紛紛搖頭，認為本次會議沒有多少實際效果，完全是在走過場。
　　案例五
　　某軟件公司在公司內(nèi)部舉行產(chǎn)品的需求評審會時，需求報告的執(zhí)筆人與產(chǎn)品策劃的主要策劃人員的想法差別很大，致使需求評審會沒有必要繼續(xù)進行下去。
　　以上的現(xiàn)象可以在很多項目中都可以看到。概括起來，在需求評審中常見的問題是：
　　◇ 需求報告很長，短時間內(nèi)評審者根本就不能把需求報告讀懂、想清楚；
　　◇ 沒有作好前期準備工作，需求評審的效率很低；
　　◇ 需求評審的節(jié)奏無法控制；
　　◇ 找不到合格的評審員，與會的評審員無法提出深入的問題；
　　……
　　那么究竟如何做好需求評審呢？
建議一：分層次評審
　　我們知道用戶的需求是可以分層次的，一般而言可以分成如下的層次：
　　目標性需求：定義了整個系統(tǒng)需要達到的目標；
　　功能性需求：定義了整個系統(tǒng)必須完成的任務；
　　操作性需求：定義了完成每個任務的具體的人機交互；
　　目標性需求是企業(yè)的高層管理人員所關注的，功能性需求是企業(yè)的中層管理人員所關注的，操作性需求是企業(yè)的具體操作人員所關注的。對不同層次的需求，其描述形式是有區(qū)別的，參與評審的人員也是不同的。如果讓具體的操作人員去評審目標性需求，可能會很容易地導致“撿了芝麻，丟了西瓜”的現(xiàn)象，如果讓高層的管理人員也去評審那些操作性需求，無疑是一種資源的浪費或者就會出現(xiàn)案例三的情形。
　　建議二：正式評審與非正式評審結合
　　正式評審是指通過開評審會的形式，組織多個專家，將需求涉及到的人員集合在一起，并定義好參與評審人員的角色和職責，對需求進行正規(guī)的會議評審。而非正式的評審并沒有這種嚴格的組織形式，一般也不需要將人員集合在一起評審，而是通過電子郵件、文件匯簽甚至是網(wǎng)絡聊天等多種形式對需求進行評審。兩種形式各有利弊，但往往非正式的評審比正式的評審效率更高，更容易發(fā)現(xiàn)問題。因此在評審時，應該更靈活地利用這兩種方式。
　　建議三：分階段評審
　　應該在需求形成的過程中進行分階段的評審，而不是在需求最終形成后再進行評審。分階段評審可以將原本需要進行的大規(guī)模評審拆分成各個小規(guī)模的評審，降低了需求返工的風險，提高了評審的質(zhì)量。比如可以在形成目標性需求后進行一次評審，在形成系統(tǒng)的初次概要需求后

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html