1.軟件需求是軟件開發(fā)最重要的一個輸入 ，好的開始是成功的一半! 所以，需求的質(zhì)量很大程度上決定了項目質(zhì)量或產(chǎn)品質(zhì)量。
2.需求風(fēng)險常常是軟件開發(fā)過程中最大的一個風(fēng)險 ，要降低需求階段帶來的風(fēng)險，就要把需求評審做好。
3.需求評審做不好的后果：
需求變更
需求不明確
需求不可測
需求不可實現(xiàn)
導(dǎo)致后續(xù)工作難于開展或經(jīng)常出現(xiàn)變更。
4、產(chǎn)品經(jīng)理：不識廬山真面目，只緣身在此山中，需求是自己寫的，容易受到固定思維的限制，所以，需要一雙沒有看過這個需求的眼睛來檢查一下，有什么問題。
先大概說一下需求的不同類型：
需求的不同層次：
目標(biāo)性需求：定義了整個系統(tǒng)需要達(dá)到的目標(biāo);
-高層關(guān)注
功能性需求：定義了整個系統(tǒng)必須完成的任務(wù);
-中層關(guān)注
操作性需求：定義了完成每個任務(wù)的具體的人機交互;
-執(zhí)行人員關(guān)注
在做需求評審的時候，應(yīng)該根據(jù)不同的需求層次，進(jìn)行不同的評審。
因為經(jīng)常參加需求評審會議，所以對需求評審中常見的問題有所了解，現(xiàn)在舉一些例子：
1、某產(chǎn)品經(jīng)理在主持需求評審會，評審開始時間不長，就被一位主管打斷，明確指出此方案與企業(yè)業(yè)務(wù)發(fā)展方向不符，不能實施。緊接著其他與會人員紛紛發(fā)言表示同意，結(jié)果評審會無法繼續(xù)進(jìn)行，需求最終被否決。
問題所在：
缺乏初步溝通，目標(biāo)性需求尚未明確，功能性需求和操作性需求無從談起。
2、某次需求評審會，主要是公司內(nèi)部相關(guān)領(lǐng)域的專家參加，在評審會開始后不久，某專家就對需求中的某個具體問題提出了自己的不同意見，于是，與會人員紛紛就該問題發(fā)表自己的意見，大家爭執(zhí)不下，結(jié)果，致使會議出現(xiàn)了混亂狀況，主持人無法控制局面，會議大大超出了計劃評審時間。
問題所在：
前期溝通和準(zhǔn)備不夠，缺乏應(yīng)對不同意見的準(zhǔn)備，難以化解爭執(zhí)。
主持者不能有效把握會議目標(biāo)，會議討論過于關(guān)注細(xì)節(jié)，導(dǎo)致評審失控。
3、某產(chǎn)品經(jīng)理主持需求評審會，在講解需求說明書時，與會人員似懂非懂，沒有提出任何有價值的問題，致使會議沒有得到預(yù)期效果，不得不改日重新進(jìn)行。
問題所在：
前期準(zhǔn)備和溝通不夠，評審變成了培訓(xùn)。
沒有選擇合適的評審人員，無法獲得有價值的信息。
4、某需求評審會，與會人員各抒己見，氣氛熱烈，產(chǎn)品經(jīng)理忙于收集意見，結(jié)果散會時發(fā)現(xiàn)對需求有價值的并不多，并且遺漏了許多要評審的問題，評審效果不佳。與會人員在離開會議室后，私下也認(rèn)為評審沒有多少實際效果，完全是在走過場。
問題所在：
評審缺乏有效依據(jù)和規(guī)范，不能保證評審的覆蓋率和有效性。
產(chǎn)品經(jīng)理沒有把握好會議主題，評審變成了頭腦風(fēng)暴。
需求評審常見問題匯總
目標(biāo)性需求沒有溝通好，后面的需求變成空中樓閣。
缺乏評審的可操作依據(jù)，遺漏評審內(nèi)容。
沒有作好前期準(zhǔn)備工作，導(dǎo)致評審時間長，效率低。
沒有選擇合適的評審人員，無法獲得有價值的反饋。
參加人員過多，容易陷入細(xì)枝末節(jié)的討論，會議演變成一場人人自由的混戰(zhàn)。
針對以上問題，提出一些建議：
建議一、做好評審前的溝通和準(zhǔn)備
需求編寫人員應(yīng)將評審所需的資料準(zhǔn)備齊全，數(shù)據(jù)、圖表、其他相關(guān)資料等，并仔細(xì)檢查以保證文檔質(zhì)量。
需求文檔在評審會議前應(yīng)提前下發(fā)給參與評審會議的人員，并留出時間讓參與評審的人員閱讀需求文檔。
參加評審的人，應(yīng)該是帶著問題而來，而不是來參加培訓(xùn)的。
建議二、先溝通好目標(biāo)，再進(jìn)行細(xì)節(jié)的落實。
應(yīng)該在需求形成的過程中進(jìn)行分階段的評審，而不是在需求最終形成后再進(jìn)行評審。
分階段評審保證了需求在形成的過程中不偏離方向，不出現(xiàn)大的錯誤，降低了需求返工的風(fēng)險，提高了最終評審的質(zhì)量
&