软件项目中如何开展有效需求评审.docVIP

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