【IT168 技术文章】

    在市场竞争激烈的今天，软件开发组织的项目管理者应充分认识到软件需求变更的事实，仔细分析软件需求变更的原因，并根据实际情况采取相应的对策，这是十分必要的。

    做过项目的人可能都会有这样的经历:一个项目做了很久，感觉总是做不完，就像一个“无底洞”。用户总是有新的需求要项目开发方来做，系统开发以后，用户不断提出新需求，每天迫着开发人员解决问题，没完没了地往下做。这种现象的本质问题就是需求变更所引发的。

    1997年l2月，Computer Industry Daily报道了Sequent Computer Systems公司的一项研究。该公司对美国和英国500名IT经理做调查后发现，76％的受访者在他们的事业中经历过完全的项目失败。其中提到最多的导致项目失败的原因就是“变更用户需求”。

    因此，必须接受软件项目中的需求会变动这个事实，在进行需求分析和需求管理时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统统计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。

    其实，需求变更也是软件开发过程中开发人员和管理者们最为头疼的一件事情，而且有的项目由于需求的频繁变更，又没有很好的变更管理，最后导致项目的失败。因此，需求变更管理是项目管理中非常重要的一项工作。

    需求变更产生的原因

    需求阶段的最后一关是需求评审，这是质量保证的一个关键环节，目前许多企业已经认识到这一点，但实际中的需求评审往往流于形式，没有达到预期的效果。

    需求评审流于形式

    彻底审查一份几百页的软件需求规格说明会令人望而生畏。我们可能会忍不住想要完全跳过这一步而直接开始构造软件，但这实在不是明智之举。即使对一份中等篇幅的软件需求规格说明，可能所有审查员都会认真地审查开头部分，而只有少数意志坚定的人才可能检查到中间部分，但可能没有一个人能坚持审查到最后一部分。

    另外，在需求评审中还经常存在如下一些问题:对于需求规格说明书，用户听不懂、看不明白，参加需求评审的相关人员能力达不到相关要求，参加需求评审的人员不愿负起应有的责任，在需求评审时针对不重要的问题争论不休导致评审无法顺利进行，或评审失败;对需求评审出来的问题不进行有效地跟踪管理，致使评审工作前功尽弃等等。这些问题的存在，很容易使评审工作成为一种浪费人力、物力、财力的形式。

    与需求分析人员本身的业务素质有关

    需求分析员称职与否可以影响项目的成败。有资料表明，检查有经验的分析员写的需求说明所花的时间只是检查新手写的需求说明所花时间的一半，因为前者缺陷更少。在广泛使用的CocomoII项目估算模型中，需求分析员的经验和能力对项目所需的工作量和成本有很大影响。相比缺乏经验的需求分析员，使用经验丰富的需求分析员能使项目所需的工作量减少三分之一 如果使用最出色的分析员，则项目所需的工作量只是使用最差的分析员时的一半，同时需求缺陷也将大大减少。

    需求分析阶段用户参与不足

    在需求分析阶段，客户常常不能理解为什么必须下这么大力气去收集需求和保证需求质量。

    开发人员往往也不重视用户的参与，原因是他们认为用户也说不清楚自己的需求，和用户很难有共同语言，或者自以为已经知道了用户想要什么 有些时候，与产品实际的使用者直接联系很困难，而用户方需求代表又不能完全理解用户的真正需求。

    有许多用户安排本单位的系统管理员作为自己的需求代言人，认为自己不懂计算机，无法与软件公司的人员进行交谈 而软件公司的人员认为用户会提出很多不合理的需求，因为用户不懂计算机而无法和用户进行解释，沟通。这种方式，在需求阶段，表面上看是节省了时间，但随之而来的是大量的无用劳动及频繁的需求变更，以及开发方和用户方的相互埋怨。

    项目的实施周期过长

    一个大中型系统的建设一般都需要一定的时间，当用户提出需求之后，用户当时并不能看到系统的运行情况，当双方认为理解大概没有分歧的时候，开发方就开始工作了。当客户拿到差不多可以试用的产品时他可以实际操作，这时候他就会对系统的界面、操作、功能、性能等有一些切身的体会，有可能会提出新的需求。