需求評審的重要性 軟件測試
1.軟件需求是軟件開發最重要的一個輸入 ，好的開始是成功的一半! 所以，需求的質量很大程度上決定了項目質量或產品質量。
2.需求風險常常是軟件開發過程中最大的一個風險 ，要降低需求階段帶來的風險，就要把需求評審做好。
3.需求評審做不好的后果：
需求變更
需求不明確
需求不可測
需求不可實現
導致后續工作難于開展或經常出現變更。
4、產品經理：不識廬山真面目，只緣身在此山中，需求是自己寫的，容易受到固定思維的限制，所以，需要一雙沒有看過這個需求的眼睛來檢查一下，有什么問題。
先大概說一下需求的不同類型：
需求的不同層次：
目標性需求：定義了整個系統需要達到的目標;
-高層關注
功能性需求：定義了整個系統必須完成的任務;
-中層關注
操作性需求：定義了完成每個任務的具體的人機交互;
-執行人員關注
在做需求評審的時候，應該根據不同的需求層次，進行不同的評審。
因為經常參加需求評審會議，所以對需求評審中常見的問題有所了解，現在舉一些例子：
1、某產品經理在主持需求評審會，評審開始時間不長，就被一位主管打斷，明確指出此方案與企業業務發展方向不符，不能實施。緊接著其他與會人員紛紛發言表示同意，結果評審會無法繼續進行，需求最終被否決。
問題所在：
缺乏初步溝通，目標性需求尚未明確，功能性需求和操作性需求無從談起。
2、某次需求評審會，主要是公司內部相關領域的專家參加，在評審會開始后不久，某專家就對需求中的某個具體問題提出了自己的不同意見，于是，與會人員紛紛就該問題發表自己的意見，大家爭執不下，結果，致使會議出現了混亂狀況，主持人無法控制局面，會議大大超出了計劃評審時間。
問題所在：
前期溝通和準備不夠，缺乏應對不同意見的準備，難以化解爭執。
主持者不能有效把握會議目標，會議討論過于關注細節，導致評審失控。
3、某產品經理主持需求評審會，在講解需求說明書時，與會人員似懂非懂，沒有提出任何有價值的問題，致使會議沒有得到預期效果，不得不改日重新進行。
問題所在：
前期準備和溝通不夠，評審變成了培訓。
沒有選擇合適的評審人員，無法獲得有價值的信息。
4、某需求評審會，與會人員各抒己見，氣氛熱烈，產品經理忙于收集意見，結果散會時發現對需求有價值的并不多，并且遺漏了許多要評審的問題，評審效果不佳。與會人員在離開會議室后，私下也認為評審沒有多少實際效果，完全是在走過場。
問題所在：
評審缺乏有效依據和規范，不能保證評審的覆蓋率和有效性。
產品經理沒有把握好會議主題，評審變成了頭腦風暴。
需求評審常見問題匯總
目標性需求沒有溝通好，后面的需求變成空中樓閣。
缺乏評審的可操作依據，遺漏評審內容。
沒有作好前期準備工作，導致評審時間長，效率低。
沒有選擇合適的評審人員，無法獲得有價值的反饋。
參加人員過多，容易陷入細枝末節的討論，會議演變成一場人人自由的混戰。
針對以上問題，提出一些建議：
建議一、做好評審前的溝通和準備
需求編寫人員應將評審所需的資料準備齊全，數據、圖表、其他相關資料等，并仔細檢查以保證文檔質量。
需求文檔在評審會議前應提前下發給參與評審會議的人員，并留出時間讓參與評審的人員閱讀需求文檔。
參加評審的人，應該是帶著問題而來，而不是來參加培訓的。
建議二、先溝通好目標，再進行細節的落實。
應該在需求形成的過程中進行分階段的評審，而不是在需求最終形成后再進行評審。
分階段評審保證了需求在形成的過程中不偏離方向，不出現大的錯誤，降低了需求返工的風險，提高了最終評審的質量
建議三、正式評審與非正式評審相結合
正式評審
是指通過開評審會的形式，組織多個專家，將需求涉及到的人員集合在一起，并定義好參與評審人員的角色和職責，對需求進行正規的會議評審。
非正式的評審
通過電子郵件、文件匯簽甚至是網絡聊天等多種形式對需求進行評審。 兩種形式各有利弊，因此在評審時，根據項目復雜程度，緊急程度不同，應該靈活地利用這兩種方式。
建議四、精心挑選評審員
為了保證評審的質量和效率，需要精心挑選評審員。
首先要保證使不同類型的人員的都要參與進來，否則很可能會漏掉了很重要的需求。(測試經常被遺忘哦!)
在不同類型的人員中要選擇那些真正和系統相關的，對系統有足夠了解的人員參與進來，選擇有經驗的，而不是有時間的人。(teamleader選擇參加，主要執行人員必須參加!針對評審目標選擇參與者，避免高、中、低層一起評審。)
建議五、充分利用需求檢查單
使評審有可操作依據，提高評審有效性，避免遺漏。
便于收集評審數據，記錄評審結果
建議六、做好評審后的跟蹤工作
切忌評審完畢后，沒有對問題進行跟蹤，而無法保證評審結果的落實，使前期的評審努力付之東流
發送項目狀態通知，讓相關人員周知需求評審已完成。
說明需求經評審后改動的部分，如實現優先級、加入和裁減了哪些。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
