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