正确应对需求变更
开篇：润墨网以专业的文秘视角，为您筛选了一篇正确应对需求变更范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
在市场竞争激烈的今天，软件开发组织的项目管理者应充分认识到软件需求变更的事实，仔细分析软件需求变更的原因，并根据实际情况采取相应的对策，这是十分必要的。
做过项目的人可能都会有这样的经历:一个项目做了很久，感觉总是做不完，就像一个“无底洞”。用户总是有新的需求要项目开发方来做，系统开发以后，用户不断提出新需求，每天迫着开发人员解决问题，没完没了地往下做。这种现象的本质问题就是需求变更所引发的。
1997年l2月，Computer Industry Daily报道了Sequent Computer Systems公司的一项研究。该公司对美国和英国500名IT经理做调查后发现，76％的受访者在他们的事业中经历过完全的项目失败。其中提到最多的导致项目失败的原因就是“变更用户需求”。
因此，必须接受软件项目中的需求会变动这个事实，在进行需求分析和需求管理时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统统计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。
其实，需求变更也是软件开发过程中开发人员和管理者们最为头疼的一件事情，而且有的项目由于需求的频繁变更，又没有很好的变更管理，最后导致项目的失败。因此，需求变更管理是项目管理中非常重要的一项工作。
需求变更产生的原因
需求阶段的最后一关是需求评审，这是质量保证的一个关键环节，目前许多企业已经认识到这一点，但实际中的需求评审往往流于形式，没有达到预期的效果。
需求评审流于形式
彻底审查一份几百页的软件需求规格说明会令人望而生畏。我们可能会忍不住想要完全跳过这一步而直接开始构造软件，但这实在不是明智之举。即使对一份中等篇幅的软件需求规格说明，可能所有审查员都会认真地审查开头部分，而只有少数意志坚定的人才可能检查到中间部分，但可能没有一个人能坚持审查到最后一部分。
另外，在需求评审中还经常存在如下一些问题:对于需求规格说明书，用户听不懂、看不明白，参加需求评审的相关人员能力达不到相关要求，参加需求评审的人员不愿负起应有的责任，在需求评审时针对不重要的问题争论不休导致评审无法顺利进行，或评审失败;对需求评审出来的问题不进行有效地跟踪管理，致使评审工作前功尽弃等等。这些问题的存在，很容易使评审工作成为一种浪费人力、物力、财力的形式。
与需求分析人员本身的业务素质有关
需求分析员称职与否可以影响项目的成败。有资料表明，检查有经验的分析员写的需求说明所花的时间只是检查新手写的需求说明所花时间的一半，因为前者缺陷更少。在广泛使用的CocomoII项目估算模型中，需求分析员的经验和能力对项目所需的工作量和成本有很大影响。相比缺乏经验的需求分析员，使用经验丰富的需求分析员能使项目所需的工作量减少三分之一 如果使用最出色的分析员，则项目所需的工作量只是使用最差的分析员时的一半，同时需求缺陷也将大大减少。
需求分析阶段用户参与不足
在需求分析阶段，客户常常不能理解为什么必须下这么大力气去收集需求和保证需求质量。
开发人员往往也不重视用户的参与，原因是他们认为用户也说不清楚自己的需求，和用户很难有共同语言，或者自以为已经知道了用户想要什么 有些时候，与产品实际的使用者直接联系很困难，而用户方需求代表又不能完全理解用户的真正需求。
有许多用户安排本单位的系统管理员作为自己的需求代言人，认为自己不懂计算机，无法与软件公司的人员进行交谈 而软件公司的人员认为用户会提出很多不合理的需求，因为用户不懂计算机而无法和用户进行解释，沟通。这种方式，在需求阶段，表面上看是节省了时间，但随之而来的是大量的无用劳动及频繁的需求变更，以及开发方和用户方的相互埋怨。
项目的实施周期过长
一个大中型系统的建设一般都需要一定的时间，当用户提出需求之后，用户当时并不能看到系统的运行情况，当双方认为理解大概没有分歧的时候，开发方就开始工作了。当客户拿到差不多可以试用的产品时他可以实际操作，这时候他就会对系统的界面、操作、功能、性能等有一些切身的体会，有可能会提出新的需求。
软件需求本身的特点决定的
软件需求作为整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，也是软件开发过程中最复杂的一项工作。象以下这些问题很难有一个万全的解决方案。
需求如何做到没有遗漏?
如何准确划定系统的范围?
需求到底描述到多细，才算可以结束?
如何面对软件项目中的需求变更
在软件开发过程中如果只有一条真理的话，那一定是:需求不可能是完备的，需求的变化是永恒的。软件开发的过程实际上是同变化作斗争的过程，因此，需求的变化问题是每个开发人员，每个项目经理都会遇到的问题，并且也是最头痛的问题。
一旦发生了需求变化，你不得不来修改你的设计，重写你的代码、修改你的测试用例，调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常进展带来了不尽的麻烦。那么怎样来解决这个问题呢?下面是我在项目管理过程中积累的一些经验:
建立需求文档并进行版本控制
需求必须被记录成文档，这一点很重要。我曾在一个项目中经历过开发人员的角色轮换。每次轮换后，新任需求分析员都跑去对客户蜕:“我们来谈谈需求吧。”客户不胜其烦，回答也变得很不客气:“我早就把需求告诉某某某某了，你们找他们去吧。”实际情况是没有谁把需求明确详细的写下来，所以每位新任分析员都几乎只能是从头开始。
需求分析的最终成果是，在客户和开发人员对所要开发的产品达成共识后，所编写的具体的文档。只有把所有与项目有关的需求组织起来，编写成易于阅读的文档，并由项目的主要相关人员对这些需求进行评审后，人们才能确定这些需求并定义需求基线。
在定义需求基线之前，虽然仍然可以对需求进行任意变更，但是，只要创建了初步的需求文档草稿，就应该开始实施版本控制，即唯一的标识每一个需求文档的不同版本。
需求评审并设置需求基线
根据项目管理的经验，进行需求评审不仅是必要的，而且是必须的。应该让不同角色的人员从不同的角度对需求进行验证，验证需求的可行性、完整性、一致性、正确性等 那么怎样才能做好需求评审呢?
评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，在评审文档中存在大量的低级错误或者没有在评审前进行沟通，从而导致评审的效率很低，质量很差。
为了保证评审的质量和效率，首先要保证使不同角色的人员都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。
为了避免评审小组被冗长的软件需求规格说明所吓倒，在审查整个需求文档之前，可以在整个需求开发期间采用增量式评审和多种评审方式相结合的方法。找出风险高的地方，并进行仔细审查，而风险较小的部分则可以采用非正式评审。。
需求在通过正式的评审和批准之后。应该确定需求基线，进一步的需求变更将在此基线的基础上，依照项目定义的变更过程进行。设置需求基线可以将变更引起的麻烦减至最小。
对于需求变更控制，绝大多数用户并不喜欢它，其实，变更控制流程并不是一种人为设置的障碍，而是一个漏斗和过滤机制，可以确保项目将最合适的需求包含进来。
很难想像，一个面对全国上万名会计人员的财务管理信息．系统项目，如果对每个人提出的需求不加任何控制，那将是一种怎样的局面。
在软件项目的研发过程中，需求变更贯穿了软件项目的整个生命周期，通过建立规范的变更控制流程，改进软件分析与设计，把变化纳入计划之中，在应对需求变更时可以更加的从容和有信心。