需求评审的案例分析

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

参与人员：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
– 计量单位：个/人时