1 需求评审的重要性
在软件项目中,需求分析是最开始的工作,同时也是最重要的工作。需求分析如果做得不够详细或者是偏离用户需求或者是存在缺陷的话,往往会给项目带来灭绝性的灾难,不重视需求过程的项目团队将自食其果。因此,如何保证需求分析的正确、准确性,成了决定软件项目成败的关键因素。在实际的项目过程中,需求阶段往往是由一两位需求分析人员与用户沟通用户需求,然后根据自己的理解输出软件需求说明书及软件原型。
接下来的项目计划、软件设计、编码、测试等各个环节都以此为基准。俗话说,当局者迷,旁观者清,经验再丰富的需求分析人员也可能犯错,所谓智者千虑,必有一失,这是永远不变的客观规律。另外,受需求分析人员的理解及用户的表达等因素的影响,需求在传递过程中往往存在很大偏差。
需求分析人员输出的需求分析说明书,到设计人员、编码人员、测试人员那里往往又会有不同的理解。因此,软件需求分析说明书的正确性必须得到彻底的验证,利益相关方必须彻底理解需求,并达成一致。要达成这一目标、降低需求风险,需求评审是一个行之有效的方法。
目前,很多小型软件企业在需求阶段,往往是需求人员写完需求后再跟用户沟通一下,就直接进入设计开发阶段了,设计、编码、测试人员前期没有参与进来,根本没有进行需求评审。也有不少企业的需求评审存在“走过场”的情况,其他人员根本不关心软件需求,认为软件需求就是需求分析人员的事情,他们怎么写大家怎么做就可以了,在提需求异常时简单几个错别字提一下应付了事,没有提出有效的需求异常。也有的时候,在需求评审会议中,大家的关注点常常会不知不觉的转向设计,结果需求评审会议成了设计讨论会议,大家想得最多的是需求如何实现,而不是需求文档本身有无问题。
或者是因为没有做好前期准备工作,导致评审时间长、效率低,结果很多问题不了了之。这样的评审,最终效果可想而知。
2 需求评审的关键
下文根据笔者多年参与软件项目管理的切身体会及经验,从不同角度对需求评审方法进行论述。
2·1 充分准备评审
好的软件需求说明书,是进行有效需求评审的前提。
首先,需求人员在与用户确认需求的过程中,一定不要放过任何一个细节,仔细体会用户的每一个要求。对于用户的要求,需求人员需要对其加以梳理:哪些是合理的需求,哪些是不合理的需求,还有一些可能是必要的但是用户没想到的需求。
软件需求说明书不应该只是用户意愿的表达,而应该是从软件层面上对用户需求的总结。
怎样磨刀 软件需求说明书对需求用例的描述一般分为基本流和扩展流,基本流是大家很容易想到的主要业务流程,而实际设计开发及测试过程中,最耗费时间的是实现扩展流的过程。因此不能只注重基本流,好的软件需求说明书,扩展流一定远远多于基本流,扩展流写得越完善,说明需求人员考虑得越周全。
而实质上,如果扩展流写得不完善,后期的设计、开发及测试人员往往在相应的细节处理上无所适从。
2·2分层次评审
用户的需求是可以分层次的,一般而言分成以下层次:
①目标性需求,定义整个系统需要达到的目标;
②功能性需求,定义了整个系统必须完成的任务;
③操作性需求,定义了完成每个任务的具体的人机交互;目标性需求是企业的高层管理人员所关注的,功能性需求是企业的中层管理人员所关注的,操作性需求是企业的具体操作人员所关注的。
对不同层次的需求,其描述形式是有区别的,参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求,可能会很容易地导致“捡了芝麻,丢了西瓜”的现象,如果让高层的管理人员也去评审那些操作性需求,无疑是一种资源的浪费。
分层次评审,可以让不同类型的参与人分别评审他们关注的内容,从不同的角度到需求的异常,提高评审效率。
2·3 正式评审与非正式评审结合
正式评审时指通过开评审会的方式,将需求涉及到的人员集合在一起,并定义好参与评审人员
的角和职责,对需求进行正规的会议评审。很多时候,因为需求内容太多,正式的评审会议中不可能将每一个细节都涉及到,评审员也有一个理解需求的过程,在短短的会议中不可能发现太多问题。因此,需要与非正式评审相结合,在评审会之前可以先开会对大家进行需求讲解,然后把需求通过邮件等方式发送给相关人员,留几天时间,以便相关人员仔细研究,记录异常,在正 式的评审会上讨论。
2·4 分阶段评审
需求评审应该在需求形成的过程中进行分阶段的评审,而不是在需求最终形成后再进行评审。可以根据需求人员进行需求分析的进度,将一个整体的软件需求分为不同的阶段,组织小规模的评审。在形成目标性需求后进行一次评审,在形成系统的初次概要需求后进行一次评审,对概要需求细分成几个部分,对每个部分进行各个评审,最终再对整体的需求进行评审。这样降低了需求返工的风险,提高了评审的质量。
2·5 评审人员选择
需求评审涉及到各层次人员,在进行评审员选择时,一定要将各层次人员都囊括进来,他们可能
有用户、需求分析人员、产品经理、项目经理、架构师、概要设计人员、详细设计人员、编码人员、测试人员、质量保证人员等等。
用户在进行需求评审时,关注点更多在于他们所要求的功能是否在软件需求说明书中都囊括进来了;架构师及概要设计人员更多关注的是在现有的技术条件下,是否能够实现需求中的要求,如果无法实现需求或者代价太大,可能就要需求人员与用户沟通更改需求;编码人员可能更多关注于某些细节,例如界面元素等;测试人员主要关注是否所有的需求都是可测试的;质量保证人员关注点在于输出物是否符合规范。各层次人员充分参与,便于他们理解需求,通过需求评审,达成一致意见,不至于需求在不同环节因理解不同而出现偏差。
因为各层次人员的立场不同,对同一个问题的看法是不相同的,有些观点是和系统的目标有关系的,有些是关系不大的,不同的观点可能形成互补的关系。如果漏掉某一层次的人员,可能会漏掉很重要的需求。
2·6 对评审人员进行培训
常常见到有的项目的需求评审会议在主持人进行需求讲解时,与会人员似懂非懂,没有提出有
价值的问题,致使会议没有取得预期的效果,不得不改日重新进行。有的项目的需求评审会议针对某一个细节问题与会人纷纷提出自己的意见,大家争执不下,结果,会议出现了混乱状况,主持人无法控制局面,致使会议大大超出了计划评审时间。因为各层次评审人员关注点不同,评审也需要技巧、把握关键点,因此,应该对各层次评审人员进行有针对性的培训。以便于参与评审的人员能够紧紧围绕评审的目标来进行,能够控制评审活动的节奏,提高评审效率。
发布评论