0°

共读DAY008《软件需求最佳实践》08

2016-10-09《软件需求最佳实践》徐锋著

第8章 需求验证最佳实践


需求验证是需求开发的最后一个环节,它是一个质量关。也就是说,其目标是发现尽可能多的错误,减少因为需求的错误而带来的工作量浪费。而需求验证的主要手段就是Review(复查,也常译为评审)。

小婧:作者这里可能是为了让大家更好理解,后续的需求验证可以等同的视为需求评审。


1 需求验证的主要手段


A不同正式化程度的评审

共读DAY008《软件需求最佳实践》08


a3种相对正式的评审

在这6种不同正式化程度的评审方法中,前3种是相对正式的。它们之间的主要区别可以体现在以下几个方面

共读DAY008《软件需求最佳实践》08

小婧:我们目前采取的形式可以是偏向于走查的方式。但是在项目的需求调研结束后的评审,会采取审查的方式。通常在审查正式进行前先进行走查和小组评审。


b3种相对不正式的评审

(1)结对编程

(2)同级桌查/轮查

需求人员之间私下进行交叉的复查:

● 桌查:两位需求人员之间交换文档产物,互相提出意见;

● 轮查:多位需求人员之间交叉交换文档产物,互相提出意见。

(3)临时评审

● 用户访谈:在和用户访谈时,一定要对每次访谈的内容进行概述,让用户对你理解、记录的信息进行即时的验证。

● 和技术团队的交流:当向开发团队介绍与需求相关的信息时,应该建议开发人员对自己听到的、理解的内容进行简单的复述,你再对其阐述的信息进行验证。

小婧:目前我们开始尝试使用轮查的方式,这样也方便大家互为backup。


B审查过程概述

准备阶段的目标是发现问题,而召开审查会议的目标则是暴露问题、讨论问题,大家对预先找到的问题,逐一讨论,给出结论。

评审活动的直接目标当然是找出软件需求规格说明书中的问题,但更有价值、更有意义的是解决问题,并且避免它。

共读DAY008《软件需求最佳实践》08

● 解决问题:我们必须对提出的问题是否解决进行跟踪、督促;

● 避免问题出现:对所有的问题都应该进行分类、因果分析,找到出现这些问题的深层次原因。


2 需求验证的主要误区与解决方案


A需求验证的5大要点


要做好需求验证,必须在思想、方法、语言、人员、内容5个要点上做好相应的工作,否则就会产生很多负面的影响。

a思想

需求验证的目标是尽可能暴露问题,而不是证明无错。

b方法

在企业中推行即时评审、同级桌查等正式化程度不高的评审手段,是创建企业评审文化的有效手段。

c语言

共读DAY008《软件需求最佳实践》08

在评审会中,不要用“评价者”的口气谈论你的观点。

d人员

参加需求评审的人不是越多越好,一定要保证同级、适合。

e内容

评审时要确保评审内容、缺陷检查表的规模适合,内容应该按每小时30~40页的速度来准备,缺陷检查表尽量在9条之内。


B需求验证常见的5大问题


a评审会上是上面开大会、下面开小会

按照评审者关注的内容拆分分场,与其大家聚在一起讨论,还不如分主题、分场次、分人员进行周期更短的评审会。

b评审会成了审判会

让参与评审会的评审者转换为“建议者”、“协作者”的角度,改进语气、语句。这既可以通过培训评审者的方式来实现,也可以通过主持人以身作则的方法示范。

c评审会成了吵架会

和前一种情况一样,要通过让参与评审会的评审者转换为“建议者”、“协作者”的角度,改进语气、语句。

d评审会成了语法纠错大会

“好人主义”的问题,需要我们通过避免管理者参加、创建企业评审文化两个方面的努力来缓解;而准备不足的问题则需要一些策略来解决。

e评审会成了翻书会

可以采用的方法应该与前面的方法结合起来,当所有评审者返回了问题之后,先按页码序进行排列,然后在会议上按顺序逐一解决;每翻过一页之前,还可以停一下,让大家现场再补充一些意见和建议。

小婧:其实任何的会议我们都应该注意在会前多准备多沟通,定好议程以及目标。在会议中注意把握节奏,特别是有些具体的技术实现问题或者5分钟尚未讨论出结果的问题,就可以先记录为action,会后再组织小范围讨论和确认,或者组织另外一个会议进行专题讨论。会议结束后,一定要有结论。如果有action一定要形成跟踪机制,确认这些条目落实情况。


小婧是一名行走在产品路上的资深业务分析师(BA),如果想与我同行,就请关注我吧!

共读DAY008《软件需求最佳实践》08







「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论