需求评审会议分析

第一部分：失败案例

案例一

某领域专家A先生就某企业的成本管理系统作用户需求报告的评审工做，在评审会开始时间不长，就被在场的企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中没法实施。该副厂长提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，导致评审会没法再进行下去，最终该报告被用户否决。

案例二

某软件公司内部举行产品的需求评审会，主要是公司内部的领域专家参加，在评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了本身的不一样意见，因而，与会人员纷纷就该问题发表本身的意见，你们争执不下，结果，导致会议出现了混乱情况，主持人没法控制局面，会议大大超出了计划评审时间。

案例三

某软件公司为某公司A作业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，导致会议不得不改日进行。

案例四

某软件公司在用户处开完物资管理系统的需求评审会后，与会人员离开会议室时，纷纷摇头，认为本次会议没有多少实际效 果，彻底是在走过场。

案例五

某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划主要策划人员的想法差异很大，导致需求评审会没有必要继续进行下去。

---

第二部分：需求评审中常见的问题

◇ 需求报告很长，短期内评审者根本就不能把需求报告读懂，想清楚；

◇ 没有做好前期准备工做，需求评审的效率很低；

◇ 需求评审的节奏没法控制；

◇ 找不到合格的评审员，与会的评审员没法提出深刻的问题；

 

---

第三部分：如何作好需求评审

建议一：分层次评审

目标性需求：定义了整个系统须要达到的目标；

功能性需求：定义了整个系统必须完成的任务；

操做性需求：定义了完成每一个任务的具体的人机交互；

 

目标性需求是企业的高层管理人员所关注的，

功能性需求是企业的中层管理人员所关注的，

操做性需求是企业的具体操做人员所关注的。

 

建议二：正式评审与非正式评审结合

建议三：分阶段评审

分阶段评审能够将本来须要进行的大规模评审拆分红各个小规模的评审，下降了需求返工的风险，提升了评审的质量。

建议四：精心挑选评审员

需求评审可能涉及的人员包括：需方的高层管理人员、中层管理人员、具体操做人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家

首先要保证使不一样类型的人员的都要参与进来，不然极可能会漏掉了很重要的需求。

其次在不一样类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来

建议五：对评审员进行培训

对于主持评审的管理者也须要进行培训，以便于参与评审的人员可以牢牢围绕评审的目标来进行，可以控制评审活动的节奏，提升评审效率

建议六：充分利用需求评审检查单

需求形式的检查单和需求内容的检查单。需求形式的检查能够由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点

建议七：创建标准的评审流程

建议八：作好评审后的跟踪工做

在需求评审后，须要根据评审人员提出的问题进行评价，要造成书面的需求变动的申请，进入需求变动的管理流程，并确保变动的执行，在变动完成后，要进行复审。

建议九：充分准备评审

评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并无提早下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。

 

---

摩兜公司-IT赋能中心-需求评审标准

前提：主持者明确本次评审内容及评审的级别、参会者名单确立、文件无低级错误（文字、页面）

目标：会议中对下一阶段作的内容中功能性、操做性需求进行讨论

1：评审内容须要有清单（思惟导图）

2：评审清单内要求对评审内容作文字性或流程图或思惟导图或原型图的描述（建议用流程图、原型图）

3：评审前至少半个小时将评审内容分发给参会人员（将准备好的文件打包）

4：会议内容：介绍需求，头脑风暴对内容进行补充（作好记录），主持者进行引导，将全部的建议进行断定并做出决定（记录）。

5：会后整理文档，绘制成project、思惟导图、禅道需求记录等进行管理，并整理会议纪要，经过邮件进行确认。