需求分析是軟件開發過程中必不可少的工作環節，而在需求分析過程中又有一個非常重要的環節，那就是需求評審。那么在需求評審過程中到底要做哪些工作呢，中培偉業《需求分析與管理最佳實踐》培訓專家王老師在這里就需求評審工作的相關環節進行了詳細介紹。

需求評審前：

完整的需求說明：

demo圖并注釋文字的做法會比較好，此外將所有相關的內容（包括流程圖、表格、版本管理等）全部整理在一個Axure文件中，并寫明需求場景與前置后置需求），會更方便與設計、技術、測試的溝通，避免不必要的反復溝通。

盡可能想清楚所有的細節、準備盡可能完善的文檔，（當然了，完美幾乎是不可能的，盡力而為吧！不要出大的紕漏）并提前與相關人員溝通（研發、需求放等相關人員），達成一致。減少二次評審、扯皮的概率，避免不必要的背鍋。

需求說明文檔說到底是給設計、開發／測試人員看的，不管使用什么樣的工具、格式，最重要的是看文檔的人能夠看明白能夠接受，方便他們工作，不妨在交付物交付后詢問一下他們的意見與建議（對于需求文檔而言，這些相關工作人員才是用戶啊，以用戶為中心，產品經理時刻牢記！）

提前發出文檔：

可能有些時候文檔來不及提前完成，但是沒關系。合理安排時間，盡量提前完成文檔，完不成就先把初稿（需要完成大部分內容，少數細節未完成影響不大）完成發給大家看，目的并不是過細節，而是希望在需求評審前大家對接下來的項目要做什么內容，為什么做達成一致（目的認知上的不一致，根本就不可能聊到一起去。）

需求評審中：

step1：說明此次迭代／產品的主要目的是什么

讓大家對項目有一定的了解。

step2：需求簡要說明（告訴大家項目范圍在哪里）

常用xmindmindmanager等工具（前面有說整合到阿axure中，憑審批還是可以用原文件，方便修改）。

step3：需求詳細說明（配合demo圖進行講解）

step4：最好用自己的筆記本電腦做展示 ，有問題的地方做標注，幫助會后的修改調整工作。

這部分最好能自己做，雖然會影響會議進程，但是只有自己最了解所有內容，別人幫忙記錄可能會抓不住重點。

需求評審后：

評審完成后，修改相關問題后，連同修改內容清單郵件給參會人員，取得最后的溝通協調。如果修改功能過多，且比較重要的，就只能開二次評審會了。

敲定設計時間、測試時間、上線時間。

配合設計是完成產品設計的工作，當中可能會遇到需求的調整問題。

后續工作

到此為止，圍繞需求評審的相關事宜就告一段落了，當然在后續的工作中，根據項目的具體情況，可能還需要召開設計評審、測試用例評審、功能評審（一般由開發召開），雖然這些評審會，產品并不是第一負責人，但是按照目前的通行情況，產品經理通常會兼任項目管理方面的工作，因此我們需要幫助設計、測試、開發完成后面的評審工作，特別是在設計與用例評審中，有時會遇到對需求提出異議的情況，此時已定要做好協調工作，保證項目的順利進展。