需求评审的案例分析

案例一:客户需求文档评审

参与人员:1位主持人,1位作者,1位记录员,4位专家,1位咨询顾问旁观
开始时间:15:40     结束时间:17:15   会议工时 :6.3人时
会前准备累计工时:9人时   总工时:15.3人时
会议前发现的问题:25个   会中发现的问题:2个   合计问题:27个
会前评审效率:2.8个/人时   会中评审效率:0.3个/人时
评审文档的规模:13页   缺陷密度: 2.1个/页

在会议开始,主持人首先检查了各位专家的准备情况:
甲 花费了3个小时准备,发现18个问题;
乙 花费了2个小时准备,发现了18个问题
丙 花费了3个小时准备,发现了18个问题
丁 花费了1个小时准备,发现了10个问题

咨询顾问作为旁观者经历了评审会议的全过程,对该评审过程进行了如下点评:
1 在评审专家的分工中没有识别需求专家,只定义了2个设计、1个测试、1个用户。
2 专家在个人评审阶段描述发现时,注意:
(1)位置准确 (2)问题准确
3 在开评审会时,主持人需要注意控制会议的节奏:
(1)在同一个时间只有1个人发言  
(2)不要讨论个人描述风格的偏好问题
(3)不在同一个问题上花费太多的时间
4 好现象:大家都能心平气和的讨论问题
5 注意客户需求的模板中存在的问题也要记录下来,并优化模板
6 有的专家很适合作为主持人
7 在本次评审中也存在“虫子窝”现象,即某个章节中缺陷比较多

案例二: 需求评审流程定义与推广
场景:
公司存在2个主要的研发部门,部门领导是业务专家,其中一个部门的研发的系统比较庞大,可能会有10多个子系统,每个子系统都有一个需求人员,可能每个子系统的需求人员并不熟悉其他子系统的需求。每次评审的文档量比较大,专家通常就是部门领导与公司领导,开发人员比较年轻,缺乏业务经验。
EPG成员及咨询顾问一起针对公司的实际讨论如何推广需求评审实践。

结论:
需求评审流程定义与推广的要点:
1 在组织级建立领域专家库,针对不同产品、不同类型的评审,识别出来自不同部门的专家。
2 在项目立项时确定参与项目评审的专家
3 在公司例会上,确定各部门本月需要配合参与的评审会,要承诺按时提供专家,确保专家的准备时间与出席时间
4 由质量部经理出任每次评审的主持人,如果有其他部门的领导或公司的老板参加,则仅以专家的身份参与
5 如果系统规模比较大,则首先评审系统的总体需求,此时,领导们可以参与。在评审每个子系统的需求时,领导不再参与。
6 每次评审确定参与的角色:设计、测试、QA、主持人等。
7 先开概况会议,由作者介绍被评审的材料,然后个人评审,记录每位专家发现的缺陷个数,并纳入考核,确保每位专家都真正做了个人评审,最后开记录会议,汇总缺陷。
8 主持人要制定评审计划,明确人员、角色、时间、流程的定义或裁剪、退出的准则等。
9 定义评审过程的度量元:规模、缺陷个数、效率、速率等。
10 流程建立后,在整个公司宣讲,尤其是领导们要熟悉评审的各项规定与要求

案例三:需求评审度量数据分析
某公司6次需求评审度量数据如下:
评审序号   缺陷密度(个数/页)   评审效率(个数/小时)
P1   0.56   0.75
P5   1.47   2.44
P8   1.23   1.79
P10   1.64   1.33
P11   0.33   0.59
P12   0.40   0.85

对缺陷密度进行分析,得到:
•   均值:0.936
•   标准差:0.522
•   离散系数:0.557692
•   离散系数太大,超过15%了,因此以均值的15%作为标准差计算基线:
–   均值:0.936
–   上控制限:1.357
–   下控制限:0.515
–   计量单位:个/页

对评审效率进行分析,得到:
•   均值:1.293
•   标准差:0.675
•   离散系数:0.522
•   离散系数太大,超过15%了,因此以均值的15%作为标准差计算基线:
–   均值:1.293
–   上控制限:1.875
–   下控制限:0.712
–   计量单位:个/人时

展开阅读全文
©️2020 CSDN 皮肤主题: 深蓝海洋 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值