需求分析是软件开发过程中必不可少的工作环节，而在需求分析过程中又有一个非常重要的环节，那就是需求评审。那么在需求评审过程中到底要做哪些工作呢，中培伟业《需求分析与管理最佳实践》培训专家王老师在这里就需求评审工作的相关环节进行了详细介绍。

需求评审前：

完整的需求说明：

demo图并注释文字的做法会比较好，此外将所有相关的内容（包括流程图、表格、版本管理等）全部整理在一个Axure文件中，并写明需求场景与前置后置需求），会更方便与设计、技术、测试的沟通，避免不必要的反复沟通。

尽可能想清楚所有的细节、准备尽可能完善的文档，（当然了，完美几乎是不可能的，尽力而为吧！不要出大的纰漏）并提前与相关人员沟通（研发、需求放等相关人员），达成一致。减少二次评审、扯皮的概率，避免不必要的背锅。

需求说明文档说到底是给设计、开发／测试人员看的，不管使用什么样的工具、格式，最重要的是看文档的人能够看明白能够接受，方便他们工作，不妨在交付物交付后询问一下他们的意见与建议（对于需求文档而言，这些相关工作人员才是用户啊，以用户为中心，产品经理时刻牢记！）

提前发出文档：

可能有些时候文档来不及提前完成，但是没关系。合理安排时间，尽量提前完成文档，完不成就先把初稿（需要完成大部分内容，少数细节未完成影响不大）完成发给大家看，目的并不是过细节，而是希望在需求评审前大家对接下来的项目要做什么内容，为什么做达成一致（目的认知上的不一致，根本就不可能聊到一起去。）

需求评审中：

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

让大家对项目有一定的了解。

step2：需求简要说明（告诉大家项目范围在哪里）

常用xmindmindmanager等工具（前面有说整合到阿axure中，凭审批还是可以用原文件，方便修改）。

step3：需求详细说明（配合demo图进行讲解）

step4：最好用自己的笔记本电脑做展示 ，有问题的地方做标注，帮助会后的修改调整工作。

这部分最好能自己做，虽然会影响会议进程，但是只有自己最了解所有内容，别人帮忙记录可能会抓不住重点。

需求评审后：

评审完成后，修改相关问题后，连同修改内容清单邮件给参会人员，取得最后的沟通协调。如果修改功能过多，且比较重要的，就只能开二次评审会了。

敲定设计时间、测试时间、上线时间。

配合设计是完成产品设计的工作，当中可能会遇到需求的调整问题。

后续工作

到此为止，围绕需求评审的相关事宜就告一段落了，当然在后续的工作中，根据项目的具体情况，可能还需要召开设计评审、测试用例评审、功能评审（一般由开发召开），虽然这些评审会，产品并不是第一负责人，但是按照目前的通行情况，产品经理通常会兼任项目管理方面的工作，因此我们需要帮助设计、测试、开发完成后面的评审工作，特别是在设计与用例评审中，有时会遇到对需求提出异议的情况，此时已定要做好协调工作，保证项目的顺利进展。