需求包括业务需求、用户需求和功能需求。业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement ）描述了用户使用产品必须完成的任务，功能需求（Functional Requirement ）定义了开发人员必须实现的软件功能。

会导致需求变更的原因会有很多，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。在软件系统开发过程中，有很多问题都是由于在需求分析阶段没有正确地收集、编写、协商、修改产品真实需求而产生的，造成这样的状况有以下几方面的基本原因:

当客户向需求分析人员提出需求的时候往往是通过自己的想法用自然语言来表达的，这样的表达结果对于真实的需求来说是一种描述（甚至只是某个角度的描述），远远不能保证这样的描述可以得到百分之百的正确理解，也许在同客户交流的第一时刻就埋下了理解分歧的种子，打一个比方说客户说我要的是大象，身子象一堵墙，耳朵象扇子，四条腿象四根柱子，尾巴象绳子，分析人员想，哦，墙、扇子、柱子、绳子这些我都知道，但是真的画出来的时候客户当然会跳起来了！这是理解分歧的问题，一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关。

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

当前客户的运营情况不确定，有可能客户行业的竞争度高，需要随时作出调整和反应，那么他们自然会经常提出需求变更的要求；也有可能客户所在的行业操作不规范，本身存在很多人为因素，这时候开发方更是需要随时准备应变。

有可能是来自开发方自身版本升级或性能改进、设计修正的要求出现需求变更，这时更是无法绕开这个问题的了！

所以说就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的，所以不要梦想那么理想的需求分析，当你开始一个项目的时候就应该意识到，客户需求变更一定会有的，那么对于这样的现状，我们该怎么办呢？客户是上帝，难道我们就象以前一样，跟着客户的需求不停地修改软件，到最后工期延长，员工疲惫，成本成倍增长，客户满意度降低，原来的设计也会改变得支离破碎，系统难以维护？

正如前文所说，需求变更往往是不可避免的。通常是项目负责人员花费了大量的气力避免需求变更，可最后需求变更总是会出现。但是这并不意味着项目开发人员不应该做这方面的工作，项目开发人员对于需求变更的正确态度应该和软件测试的态度一样，在需求变更发生之前尽量减少需求变更，以将需求变更带来的风险降低到最低。项目开发人员切忌在项目设计之前试图消除需求变更，这样做往往费力不讨好。

相比于需求开发人员而言，客户可能对需求变更认识不足，认为他们出钱，程序员或软件开发公司就要为它服务，因此客户对需求变更往往更加肆无忌弹，将需求变更视为儿戏，随个人喜好随意变更需求。因此，在需求人员同用户代表或用户部门主管人员接触时，就应该向他们挑明态度，和他们协商好，特别是应该让他们清楚软件的定价应该与软件的功能相关，以及需求随意变更所带来的风险的承担者应该由客户和项目开发者共同承担。通过这样做，让客户在需求分析之前就尽量对他们所需要的功能有个整体的了解和确定的思路，而不是等到程序员开始编码了，才提出以前原本在需求分析时就可以提出的需求。

让客户明白减少需求变更的重要性后，需求分析人员应该采取合适的方法同客户交流，帮助他们明确他们的需求。需求分析人员和客户的关系不应该仅仅是记录人员和需求提供者，他们的关系应该更多的是战略合作伙伴关系。虽然需求分析人员和客户存在着服务商和顾客的关系，但是他们有着一个共同的目标：开发出适合客户需求的软件，因此需求分析人员除了记录客户提出的需求以外，还应和用户讨论，提出一些建议，使用合适的工具帮助客户提出需求。在需求分析时，尽量多的召集需求研讨会，邀请开发人员和客户共同协商探讨，在研讨会上允许任意的提出需求，并将这些需求整理成档后由客户代表和需求分析人员共同商议可选的功能，这样能够尽量使得需求完备。在需求开发时，开发人员采用原型的方法启发客户思考功能需求也不失为一个好办法。


　虽然需求不可能是完备的、变更不可能没有的，但是在项目开始设计时使得需求尽可能完备还是应该的，也是值得的，完备需求的过程也就相应的减少了因为需求不清楚而产生变更的几率。

需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。

需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。

这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目进度拖延、成本不足、人力紧缺，甚至导致整个项目失败。当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。

（1）建立需求基线，需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（用户参与评审），可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。

（2）制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。

（3）成立项目变更控制委员会（CCB）或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。

（4）需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。

（5）需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。

（6）妥善保存变更产生的相关文档。

需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。针对变更控制流程，在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策：

优先排序 分批实现　每个需求的重要性是不同的。由于资源或技术条件的限制，会显得“僧多粥少”，因此不可能把所有的需求一次完成。怎么办？把每个需求按照对效益的贡献打个分，排出个优先级来，优先级高的需求先实现，低的到一下版式本实现。由于不断有新的需求进来，有的需求可能永远没有机会被子实现，但不紧，还是要记录下来，并一起参加排序，保证在每个版本发布时重要的需求先得到满足。每个需求的实现是需要花时间的，没人有百分百的把握预估得很清楚，但借鉴过去的经验可以大概估算出人力成本，然后根据开发人员和开发周期得出可用人力投入作为上限。从优先级高的需求中挑，直到挑中的人力成本总和刚刚低于可用投入上限，这样得出的就是需求的录取榜。今后的软件开发规划也会以此为依据，分期分批地在不同的回合中实现。最合理的不一定是优先级最高的，也就是说不一不定是最先考虑的，“经济为本”是指导优先排序的最终原则。

相互协作　很难想像遭到用户抵制的项目能够成功。在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。

充分交流　需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。

安排专职人员负责需求变更管理　有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。

合同约束　需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。

区别对待　随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况，开发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求（虽然用户认为是细化需求，但实际上是增加了工作量的新需求），会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。

选用适当的开发模型　采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。

用户参与需求评审　作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。

变更控制流程如图所示。