写好需求评审报告需要包括:1、项目背景介绍;2、启动汇报问题总结;3、需求阶段汇总总结;4、非功能需求分析总结。需求评审是产品经理与开发、测试、设计沟通产品实现的过程,是由产品经理组织相关的人员一起参与业务评审的会议,包括评审原型设计交互和需求文档的内容。
如何写好需求评审报告
写好需求评审报告需要包括:1、项目背景介绍;2、启动汇报问题总结;3、需求阶段汇总总结;4、非功能需求分析总结。
1、项目背景介绍
项目立项依据,项目立项金额,项目投标介绍、项目合同介绍,项目来源,使用单位,项目投资金额,项目建设工期,参与方,建设方,监理等一些基本信息。
2、启动汇报问题总结
需求评审会议之前,项目一般都会有启动会流程,相关的专家或者客户也会提出一些问题,所以项目经理应该把相关问题进行总结并提出解决方案。
3、需求阶段汇总总结
- 介绍项目调研的计划、方法、历程并提供对应的文档截图
- 现场调研的照片或者相关材料
- 调研报告或者调研记录经过用户确认签字的文件的介绍
- 用户的组织结构和涉及范围的介绍,总结系统的角色和相关权限
- 客户的业务目标的确认,通过目标的确认,挖掘客户实际业务的痛点,为进一步给用户提供精准化的服务
- 根据调研结果,按业务模块进行流程图的梳理,一般通过VISO软件画就可,复杂业务流程一定要拆分成多个模块,需求尽量要细化
- 根据用户实际网络情况,梳理出用户的网络拓扑图
- 业务痛点问题分析,项目实施后未来的业务远景,项目亮点
- 功能需求:业务处理过程的输入输出表单,处理的业务规则,讲解重点功能子系统,核心业务场景
- 数据迁移需求:如果有遗留系统数据,需要做数据迁移需求分析
4、非功能需求分析总结
- 是否可测试验证,是否具体,安全性需求是否考虑费用支持,特别强调三级等保备案、评审,性能需求是否过高、过低
- 如果有条件,原型系统演示,介绍UI布局设计,代表型模块演示
- 需求编号建立需求跟踪矩阵
- 大型项目可以按照,总体需求—子系统需求的模式组织PPT,可以让子系统需求负责人分别讲,也可分几次会议汇报需求
- 子系统/子模块的关系:说明各子系统之间如何配合完成整体业务
- 需求与合同要求吻合度分析
- 验收标准
- 系统上线使用的依赖条件及成熟度,如外部条件不成熟如何保障系统上线
- 进度分析,里程碑计划,具体列出团队成员、预算
- 是否有不明确的需求,主要风险识别,需求变更风险,各方意见分歧,如出现职责调整、新法规发布、调整工作程序等情况将如何应对
拓展阅读
需求评审的参与人员
1、UI设计、UE设计人员
作为设计来说,他们关注的更多是原型方面的内容,提的问题大概率也是关于视觉效果和图标模块的意见。在评审会上简单说明,确认下整体结构就好,产品经理不需要细抠什么按钮颜色字体大小,放手让设计做他们专业内的工作。
2、开发人员
研发的人是非常多的了,他们也是最关注需求业务功能和流程的。通常会对流程的逻辑进行提问,这也是对产品经理逻辑严谨性的一次考验。较好在开需求评审前仔细将业务功能和逻辑梳理清楚形成闭环,这样才能最大程度的减少研发对你专业性的质疑,在之后的需求跟进工作中也会更加的顺利。
3、测试人员
说起测试同学真的是又爱又恨的存在啊,在产品需求评审中,测试同学堪称意见担当了,正常流程的逻辑,异常流程的处理,用户的提示和反馈,事无巨细的进行提问,产品经理面对这样的场面也难免会觉得无法招架。较好的方法就是对需求的每一个流程都进行深度思考,避免主观判断,尽可能回答测试同学的疑问,也要适时把控会议时间和进度,结合需求场景进行整理和修改。
4、运营人员
运营在需求评审的过程中一般不会有太多意见,甚至充当旁听的角色,那为什么还需要运营参与呢。因为我们实现的产品后期是需要运营来推广和参与的,提前让他们参与需求评审了解业务和流程,做好心理预设,结合产品业务做运营推广计划。
5、需求提出方(老板或甲方)
既然是需求评审那么需求的提出方毫无疑问是需要参与的,看看是否满足他们对于需求本身的预想。
文章标题:如何写好需求评审报告,发布者:小编,转载请注明出处:https://worktile.com/kb/p/32171