一、 注意對需求規格說明的正確性進行評審
需求規格說明的正確性通常可以從如下方面得以體現：
1、是否有需求與其他需求相互衝突或者重複？
2、是否清晰、簡潔、無二義地表達了每個需求?
「清晰」是讓人能夠讀懂；「簡潔」是讓人願意去讀；「無二義」決定」讀」的效果,是讓大家對需求描述的理解能夠達成一致 。
3、是否每個需求都通過了演示、測試、評審，分析是否得到了驗證?
4、是否每個需求都在專案的範圍內?
5、是否每個需求都沒有內容和語法上的錯誤?
6、在現有的資源內, 是否能實現所有的需求?
7、每一條特定的錯誤資訊，是否都是唯一的和具有含義的?
二、 注意對需求規格說明的實踐性進行評審
本文出自51testing軟體測試網，感謝會員archonwang在每週一問（08-11-10）中的精彩回答。
三、 注意對需求規格說明的完整性進行評審
我們經常由下面的問題清單來評審需求說明書是否」完整」 。
1、編寫的所有需求，其詳細程度是否一致和合適?
2、需求是否能為設計提供足夠的基礎?
3、所有對其他需求的內部引用是否正確?
4、是否包含了每個需求的實現優先順序?
5、是否定義了功能說明的內在演算法?
6、是否包含了所有已知的客戶需求或系統需求?
7、是否遺漏了必要的資訊?如果有遺漏的話,把他們標記為待確定的問題(tbd) ?
8、是否對所有預期的錯誤條件所產生的系統行為都編制了文件?
需求說明的完整性主要體現在需求說明的詳細程度上，我們怎樣判斷該需求的描述是否詳細呢?我認為需求需要精化，而不是僅僅提出精化功能、物件要考慮涉眾參與者、做些什麼、需要什麼資料資訊、受什麼業務規則和條件限制、系統會有什麼響應，等等。
四、 注意對需求方案的可行性和成本預算進行評審
五、 注意對需求的質量屬性進行評審
我們需要評審需求規格說明是否合理地確定了所有的效能目標，是否合理地確定了安全性方面要考慮到的問題。
本文出自51testing軟體測試網，感謝會員archonwang在每週一問（08-11-10）中的精彩回答。
六、 注意對需求的可實施性進行評審
是否對每個需求都設定了惟一性並且可以正確地識別它？是否每個功能需求都可以跟蹤到高層需求（比如系統需求或用例）?
需求必須可以測試,每個需求在特定的輸入條件下應當能給出已知的輸出結果。同時,需求應當層次分明,需要把單個需求下面的相關需求綜合在一起形成一組需求功能。
需求的可實施性除了可跟蹤性還包括可測試性。事實上, 分析人員和測試人員在編寫**以前把需求模型,分析模型和測試用例綜合起來通盤考慮，檢查出遺漏的、錯誤的和不必要的需求。軟體需求在概念上的測試是一種很必要的技術，它可以在專案早期階段發現需求的歧義和錯誤。
七、 注意對需求包含的用例文件進行評審
用例是參與者對系統和參與者的互動過程所達成的一種契約。需求說明書基於用例的分析方法是也是當前較為流行的需求開發方式。用例文件作為需求重要的成果性文件也是需求評審主體之所在。需求評審確認的重點是對關鍵使用者的最常用和最重要的用例進行深入和細緻的評審,首先要通過測試用例的主幹過程。而我們是否撰寫有效的用例則要從以下方面著手評審。
1、用例的目標或價值度量是否明確?
2、用例是否是獨立的分散任務?
3、是否明確說明可用用例會給哪些參與者帶來用處?
4、編寫用例的詳細程度是否恰當?是否有不必要的設計和實現細節?
5、所有預期的分支過程是否都編寫了文件說明?
6、所有預估的異常過程是否都編寫了文件說明?
7、是否存在一些普通的動作序列可以分解成獨立的用例?
8、每個路徑的步驟是否都清晰明了,無歧義而且完整?
9、用例中的每個參與者和步驟是否都與所執行的任務有關?
10、用例中定義的每個可選路徑是否都可行和可驗證?
11、用例的前置條件和後置條件是否合理?
分析師必須確認用例的前置條件和後置條件準確界定了用例的邊界範圍,區分了用例和用例之間的界限。
本文出自51testing軟體測試網，感謝會員archonwang在每週一問（08-11-10）中的精彩回答。
八、 注意需求評審會的過程和結束標準
需求評審會的結果是對需求規格書完成了評審過程,那我們又如何判斷審查的結束標準呢?請看如下幾條建議:
1、審查期間評審員們提出的所有問題都已經解決。
2、相關文件中的所有更改都已經正確完成。
3、修訂過的文件進行了拼寫檢查。
4、所有標識為tbd(待確定)的問題已經全部解決, 或者已經對每個tbd的問題的解決過程、計畫解決的目標日期和責任解決人等編制了文件。
5 需求文件正式進入了配置庫。
以上來自51testing
需求評審是我們專案立項之前的一條必經之路，是專案經理，開發，測試，架構師等等的同學針對自己將要開展的工作內容，進行檢查並提出問題；只有評審通過的需求才能立項，但是我們的評審總帶有一定的盲目性；
在公司裡面，需求評審的時候，我們常可以看到這樣的乙個情況，一堆人，在一間會議室裡面，吵得臉紅脖子粗；大家都在強調：「你沒有明白我的意思，我的意思是。。。」上午吵不完，下午繼續吵，今天吵不完，明天再吵。。。最後，乙個旁觀的人突然說：「你們爭論的根本不是同乙個東西。」
在此同時，至少有五個與這個功能完全沒有關係的人在看著別人臉紅脖子粗。。。哀哉。我們需要改進現有的評審方式。
1、評審要有目的
在需求評審的時候，與會的同學關注的需求功能點都是分散的，我們很難將偏離使用者需求的功能點找出。
我的意見是在評審之前，發出會議邀請的時候，分清必須參與評審的人員和選擇參與評審的人員。必須參與評審的人員必須在需求評審之前發出自己認為需求中存在的問題；選擇與會人員，可以自主選擇是否發出評審意見；
2、評審要控制時限
我們也常見到這樣一種情況，pm和pd兩個人就乙個問題爭執不下，其餘的同學都在下面看著兩個人爭執不下。可能還有這樣一種情況，我說服不了你，但是我就默默唧唧的不答應，你也別想說服得了我。或者我們也在評審的時候發現：我們從a問題引申到b問題，再到c問題，直到大家一起偏離主題討論n久，原定的計畫還沒有完成，還浪費大家的時間。
所以，對於每次評審中的提出的問題，pd或者pm設定乙個討論的最大時長，比如十五分鐘。如果對乙個問題討論的時間太長，那麼，在一定的程度上，這個功能點的實際存在著問題，考慮還不周全、不完善，有必要大家回去再思考。
3、及時作出評審的界定
在pd輪崗期間，在制定搜的需求評審期間，和專案的ued同學對專案的流程爭執不下，連帶著各自的一幫人都在爭論不休；我們當時有叫來需求方，各自對需求方講訴我們各自的出發點，結果需求方被我們講得頭暈腦脹，不知所言。
即使是辯論賽，我們也會有乙個主持人進行中間調停。此時，我們當需要公推乙個能拍板的人來，為此時做個不偏不倚的公斷！
拍板的結果，雙方必須當場無條件信服。如果爭執的一方還認定自己的觀點，本次會議中不可以再次提出，但是可以在蒐集證據之後，再次召集有關人員討論這個問題。
4、跟蹤評審中問題的結果
在需求評審的時候，肯定還存在一些，例如呼叫儲存訪問等留待溝通之後再議的問題，但是評審之後是煙雲繚繞，不知下文。如果沒有乙個發起人催一下問題解決的結果，甚至可能專案上線了，都沒有讓所有相關的人員知道問題是否得到解決，以及問題具體的解決方法。
在我們專案中的一些主要角色中，需求方太遙遠，pd太忙太沒有時間，開發太飄忽太隨意，當然，我們的測試可能因為影響力等原因，太沒有力度。要建立自己的威信和對專案的責任感，我們需要從跟蹤評審問題的結果開始，讓大家都看到你對專案的關注程度，你對專案的責任感。
5、設定需求變更聯絡人
在**，擁抱變化的思想深入人心；我遇到過這樣一件事情，後台crm需要跟流程平台打通，呼叫流程平台的審批系統；我們當時跟流程平台的同學一起討論可行性，討論介面的內容等。突然，有一天我詢問專案進度的時候，開發同學說，我們決定不用流程平台的審批系統了。
我們也常聽到測試的同學怒吼一聲，你們需求又變了，我為什麼不知道。這些是什麼原因導致的呢？
一直以來，大家都很隨意，沒有一種明確的需求變更的機制；如果需求變化了，應該告訴誰，對誰可能有影響，這些我們都沒有想；我們只想到，我們實現這個功能更加簡單了。這種片面性的想法導致了以上的種種問題。
故而，上到乙個專案，下到乙個小日常，我們需要確定專案需求變更的通知人。一旦遇到變更情況，需要馬上通知到相關的變更聯絡人。
6、評審的結果——基線
基線是專案儲存庫中每個工件版本在特定時期的乙個「快照」。它提供乙個正式標準，隨後的工作基於此標準，並且只有經過授權後才能變更這個標準。建立乙個初始基線後，以後每次對其進行的變更都將記錄為乙個差值，直到建成下乙個基線。
而我們現在評審完畢之後，頂多發出乙個會議的紀要出來，上面寫明，今天的評審中提出了哪些問題，哪些問題是需要進一步跟蹤的會議紀要，再也沒用進一步的東東。所以，這個不是基線，至少不是完整的基線，不是正式的基線。
我覺得，基線還應該包含以下幾個方面的內容：
1） 需求變更的聯絡人
2） 公開評審中問題的結果
3） 修改後，大家達成共識的prd。現在我們評審的結果只有輸入值，乙個初始版本的prd,但是沒有基線版本的prd。
評審是我們專案和日常的第一步，熟話說，好的開始是成功的一半。乙個良好的，有序的評審方法，有利於我們發現更多的問題。
如何進行需求評審
作為產品經理，一般都經歷過需求評審，或者是自己主持的需求評審，或者是參加別人的需求評審。大部分需求評審會陷入兩種極端情況，一種是產品經理在上面對著產品需求文件照本宣科，下面與會人員無動於衷 另一種是產品經理剛講幾個需求，大家已開始了激烈的討論，都在證明自己是對的，會議被無限延長，效果甚微。所以說需求...
軟體需求評審 過程階段評審
過程階段評審，無評審，不過關！還記得在我們還是學生的年代，每次考試交卷前都會檢查好幾遍，生怕錯漏了什麼，實際上就是開展了一次評審活動，評審的人是你，評審的物件是那份卷子，評審的目的是為了發現問題並修改。在軟體生產過程中，涉及到一道道環節，軟體生命週期從專案啟動到需求，緊跟著設計，然後開發，之後測試，...
需求評審與需求測試
在軟體開發過程中，需求分析是最開始的工作，需求分析如果做得不夠詳細或者是偏離使用者需求的話，往往會給專案帶來滅絕性的災難。因此如何保證需求分析的正確性，不偏離使用者的需求就成了決定軟體專案成敗的關鍵。需求工程師取得使用者的顯性需求後，要仔細的分析使用者到底要求軟體實現什麼功能，使用者的表達和需求工程...