IT管理

详解需求分析的评审工作

2017-01-19 15:24:30 | 来源:中培企业IT培训网

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

需求评审前:

完整的需求说明:

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

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

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

提前发出文档:

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

需求评审中:

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

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

step2:需求简要说明(告诉大家项目范围在哪里)

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

step3:需求详细说明(配合demo图进行讲解)

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

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

需求评审后:

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

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

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

后续工作

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

标签: 需求分析