需求评审与需求测试

在软件开发过程中，需求分析是最开始的工作，需求分析如果做得不够详细或者是偏离用户需求的话，往往会给项目带来灭绝性的灾难。因此如何保证需求分析的正确性，不偏离用户的需求就成了决定软件项目成败的关键。

需求工程师取得用户的显性需求后，要仔细的分析用户到底要求软件实现什么功能，用户的表达和需求工程师的理解有时间并不会一致，这样会导致用户所想的和需 求说明书上所描述的有偏差。并且需求工程师取得用户的需求后必须做仔细透彻的分析，有时候用户的需求并不一定正确，可能是用户忽然的想法，并不可行。如果 需求工程师不能对用户提出的需求进行判断的话，可能辛辛苦苦的实现了用户需求，结果被用户自己否决掉。用户绝对不会将责任揽到自己身上，他们只会说“你们 是专家，怎么能怪我呢？”。http://www.mscto.com

网上有一幅漫画形象地描述了信息在传递过程中产生的误差。http://www.mscto.com

http://www.mscto.com

需求分析师是项目中直接与客户接触的人，需求做的好不好决定项目成败，因此对于需求规格说明书的正确性必须进行彻底的验证，将错误在开工前就消灭。

通常有两种手段来检查需求的正确性，分别是需求评审和需求测试。

1、 需求评审

需 求评审可以分为正式评审与非正式评审，在需求规格说明书完成后，需求组必须自己对需求做评审。如果需求组递交的需求规格说明书在指导后面的工作的时候出现 很明显的错误，我想拿高工资的需求分析人员是无法向老板交差的。为了需求分析人员的名誉，他们自己会对自己提交的内容进行审核，直到他们认为自己的工作成 果足够好，才会将需求规格说明书提交给正式评审组。

正式评审组的成员一般由公司内经验最丰富，技术最牛的人（技术总监）来担任，当然参加评审的人中间还应该有项目经理、QA人员、测试人员、架构师，他们仔细阅读需求规格说明书，并针对自己将要开展的工作内容进行检查，并提出问题。

正式评审是最后一关，如果正式评审通过了，将进入系统设计阶段，如果在系统设计阶段再跨里程碑来修改需求的话，所花费的代价将大大增加。因此正式评审将是一个“鸡蛋里挑骨头”的过程，只有所有的人都认为需求已经没有什么可挑剔评审才能通过。

2、 需求测试http://www.mscto.com

可 以认为需求评审也属于需求测试范围，但是这里提的需求测试和评审不同，它是测部门来测试需求是否符合用户的要求。显然这是有难度的，传统的测试工作都是从 单元测试开始，编码之前全部做得都是计划性工作。测试人员对需求分析进行测试？那么前提条件是测试人员必须熟悉需求分析，这对测试人员的要求提高了。将需 求测试人员作为测试人员中的特殊种类来培养，能够对需求是否正确进行检查，这样就能够在需求阶段就引入测试。当然需求测试人员可以是经过培训的需求分析人 员，但是他必须脱离需求组，加入测试部门，这样才能保证测试不是自己人测自己，以保证测试的效果。

需 求测试不等同于后面阶段集成测试或者系统测试，后面的测试都是软件已经编写完成的条件下，判断软件是否会出错。而需求测试，只是验证需求是否真的是用户 的。对于需求的功能测试，可以用RAD工具建立界面原型，用户通过原型的操作来确定是否需求跟他的期望相同。对于那些用户不合理的需求，测试人员要能够分 辨出来，并跟用户进行核对，确定用户的真实需求。可以说需求测试是需求测试人员和用户共同来执行的。

之所以将需求测试和需求评审并行进行，是因为需求评审是项目的各方干系人共同进行的检查工作，评审工作关注的焦点是分散的，很难将偏离用户的需求检查出 来，并且涉及的人很多，因此不可能耗费太长时间。而需求测试执行的时间可以比评审时间长，有专门的关注方面，能够检查出不合理的需求分析，在项目前期进行 错误纠正，往往比实现后纠正要节约几百甚至几千倍的成本。