需求评审规范

elmoyan

已于 2022-09-09 08:39:34 修改

阅读量3.9k

点赞数 6

分类专栏：测试理论文章标签：功能测试

于 2022-09-07 17:53:13 首次发布

本文链接：https://blog.csdn.net/elmoyan/article/details/126745572

版权

测试理论专栏收录该内容

5 篇文章 5 订阅

订阅专栏

需求评审，就是产品经理将收集、整理的需求，通过向团队成员（项目经理、研发、测试）进行阐述、说明或者演示，使团队成员对需求的理解保持一致，从而使产品达到预期效果。

一、需求评审的重要性

实际项目中，我们常见的几类与需求有关的问题：

需求开发的过程中发现有逻辑不通、逻辑遗漏，研发不知道该如何继续实现
开发前评估工作量2周，实际开发却发现越做越多，工作量远超计划
测试的过程中提交的bug有争议，测试认为是bug，开发认为需求设计如此
开发测试都很顺利，但交付后，运营不满意、客户不满意，认为没有满足自己的需求

需求评审的好处：

评审过程本身也是一个知识传递过程，评审人员与需求分析人员一起讨论用户需求，这有助与评审人员获得用户需求的前期认识，确保对需求理解的一致性
评审过程中，沟通细节，可能发现不明确的或者遗漏的需求
各方思考的角度不同，可能可以产出更合理或更有建设性的解决方案

二、如何进行需求评审

需求评审流程

需求评审流程
1、范围评审

评审目标：明确需求范围，要做什么，不做什么
文档准备：需求场景、需求清单、客户调研报告、竞品调研报告等
参会人员：产品、需求方（业务、销售、售后、老板等）
评审产出：达成一致的需求范围清单

2、低保真评审

评审目标：初步明确大致的样式交互及业务逻辑方案
文档准备：低保真稿（包含核心业务逻辑说明及核心页面交互）
参会人员：产品、需求方、研发（前端、后端）、UI/UE
评审产出：就核心业务逻辑及核心页面交互达成一致

这个流程可视团队情况、需求复杂度、需求量决定是否进行。

3、方案评审（高保真）

评审目标：关注粒度更细的方案细节，需求、逻辑需覆盖全面
文档准备：包含全部业务逻辑说明、页面样式交互说明，是可以直接开始研发的终稿
参会人员：产品、研发（前端、测试）、UI/UE
评审产出：理想状态下，就全部业务逻辑和页面交互达成一致

会议管理

会议前
明确本次会议的目的、提前确定与会人员、与会时间、会议时长、会议室预约、会议材料准备。
在评审前，需先把需求文档、原型图、流程图等材料提前邮件给会议相关方，各方查看后标注评审意见，方便会议上提出讨论，提高评审的效率。

目的：让团队所有人员对需求达成一致
与会人：项目经理、产品、研发、测试、UI设计、运营、需求方，尽可能召集与项目有关的所有人员，各个领域的负责人必须到场
与会时间：提前协调各方合适的时间
会议时长：最好控制在1个小时以内，时间太短无法把需求说清楚，时间太长容易疲劳、注意力不集中
会议室预约：根据参会人数、以及演示方式预订符合自己需要的会议室
会议材料：提前准备好项目概要、需求文档、原型图、流程图、项目排期计划并提前发送给相关与会人

会议中

评审流程：

需求背景–>需求价值–>需求带来的收益–>用户场景与需求–>功能模块及操作–>流程讲解–>原型演示–>迭代计划及项目排期–>与各方确认是否有疑义

澄清需求时要注意以下几点：

> 在进行需求澄清前不要忙着讲解用户操作流程，演示原型图，首先我们应该对需求的价值进行澄清，然后澄清需求的背景以及需求想要实现什么目标、解决什么问题，这样的话大家对需求的理解才能更深刻，才不会在后期质疑是否需求的必要性。
> 尽量用举例子、讲故事的方式来澄清需求。在讲解用户操作时可以结合具体的业务场景。
> 节奏把控，避免在一个问题上讨论太久，一时半会儿没有结论的问题需要记录下来，后续再专门安排时间讨论；避免讨论溢出范围的问题
> 记录会上提出的所有问题
> 与每一块的负责人确认排期时间是否有疑义
> 防止突发事件，预留一定时间

会议后
输出会议纪要，一般分为3部分：待讨论、待完善、已确认。