需求评审的案例分析

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

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