作为软件开发者或者软件系统客户，相信我们都遭遇过由于需求变更而须要改动系统的情况。一般说来客户会要求改变界面，改变操作方式，甚至改变业务。说，当时我是那样要求的，只是如今我们的业务调整了…这时须要中断正在进行的工作，须要查证以往的资料。须要修正计划，须要… 需求包含业务需求、用户需求和功能需求。业务需求（BusinessRequirement）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（UserRequirement）描写叙述了用户使用产品必须完毕的任务。功能需求（FunctionalRequirement）定义了开发者必须实现的软件功能。在软件系统开发过程中，有非常多问题都是由于在需求分析阶段没有正确地收集、编写、协商、改动产品真实需求而产生的，造成这样的状况有几方面的原因: 对需求的理解分歧
当客户向需求分析人员提出需求的时候往往是通过自然语言来表达的，这种表达对于真实的需求来说是一种描写叙述（甚至仅仅是某个角度的描写叙述），远远不能保证这种描写叙述能够得到百分之百的正确理解，也许在同客户交流的第一时刻就埋下了理解分歧的种子。打一个例如说客户说我要的是大象，身子象一堵墙。耳朵象扇子。四条腿象四根柱子。尾巴象绳子，分析人员想，哦。墙、扇子、柱子、绳子这些我都知道。可是真的画出来的时候客户当然会跳起来了！这是理解分歧的问题，一般跟分析员的知识、背景，还有客户表述的标准程度、两方的交流情况有关；
系统实施时间过长
一个大中型系统的建设可能要延续一段时间。当客户提出要求之后，他当时并不能看到系统的执行情况，当两方觉得理解大概没有分歧的时候（其实还会有个Deadline），开发方就開始工作了。当客户拿到差点儿相同能够试用的产品时他能够实际操作，这时候他就会对系统的界面、操作、功能、性能等有一些切身的体会，有可能提出需求变更要求。
客户详细情况不一
当前客户的情况不一，有可能客户行业的竞争度高。须要随时作出调整和反应，那么他们自然会常常提出需求变更的要求。也有可能客户所在的行业操作不规范，本身存在非常多人为因素。这时候开发方更是须要随时准备应变。
开发本身要求
有可能是来自开发方自身版本号升级或性能改进、设计修正的要求出现需求变更。这时更是无法绕开这个问题的了！
所以说就算分析人员和客户之间不存在理解分歧。客户对于实际的系统还是会提出一些个人意见。就算没有个人意见，他们自己的业务会变化或环境发生变化。这些都是无法避免的，所以不要梦想那么理想的需求分析。当你開始一个项目的时候就应该意识到，客户需求变更一定会有的。那么对于这种现状。我们该怎么办呢？客户是上帝。难道我们就象曾经一样，跟着客户的需求不停地改动软件，到最后工期延长，员工疲惫，成本成倍增长，客户惬意度降低。原来的设计也会改变得支离破碎，系统难以维护？
客观面对需求变更
假设需求一定会变化，假设我们不得不面对，假设我们已经痛定思痛，想要变革，那么还有什么办法能够改善我们的现状
答案是有的。
加强人员培训
从客观方面能够採取的措施来说，首先。我想不容置疑的是加强对需求分析人员的培训。尽可能增强软件系统、行业的背景知识，提高与客户的沟通能力，增强服务意识和责任感。由于将要开发的系统直接建立在需求分析的基础上；同一时候规范需求分析人员和客户沟通的方式。以及规范需求说明的格式，假设可能的话，尽量採取象XP的UserStory，或者用户能够理解的用例图来对需求进行标准、规范的描写叙述。保证两方在工具的协助下对需求达到共同的认识，这一点是老生常谈，就不多说。
确定文档的有效性（Validity）
顺便要提的一句是关于文档，需求文档是相当重要的，可是眼下存在一种奇怪的现象。本来说必须要有文档，并且是依照某种特定的格式，当然这没有错，但接下来，却没有人关心文档的真正内容是否正确。格式是否真的合理。是否实用（并且非常多情况下是在几天时间里赶出来或补上去的），例如我遇到一个样例，须要在原来的需求基础上进行兴许开发。文档找到了。全然符合格式的要求。可是我在里面找到的线索是有限的，结果是自己花几天的时间查找数据表结构、甚至查看数据表的内容，询问当时的开发者。才分析到所要的关系，这种情况在设计文档里也存在。所以同一时候提一提，希望我们的开发者、PM以及各级领导能够注意文档的有效性和实用性问题，甚至对文档的格式进行一下合理性检查。
建立代价估算（CostEstimate）概念
这一点对开发方和客户相同重要，由于假设出现需求变更。不可避免将带来成本的添加、开发时间延长等不良后果，这种影响是两方的。
这时候须要区分需求变更的原因。是客户方必要/不必要的要求，还是由于开发方的工作失误，还是两方都有原因，然后对现实情况进行分析。得出两方实现变更需求的须要的成本，包含时间，人力。资源等等方面，再与客户商讨是否必要进行变更和如何在最小代价下实现变更。
当客户看到实际的代价估算。他们也会再一次谨慎地考虑需求变更问题，也会更easy理解系统建设中的进行状况，自然开发方也不用负担全部的需求变更成本。所以进行成本分摊还是有其积极意义的。
当然还有建立需求变更版本号控制等等专业的需求管理。在这里不做专门论述。 从软件分析和设计着手
前面说了面对需求变更的几种策略。那么从软件系统分析和设计的角度来看，通过採用合理的分析设计方法，进行可扩展性设计能够有效地降低需求变更引起的风险和维护代价。
採用OO技术
採用OO技术能够建立易于改变和加强可重用性的软件系统。
对于OO技术。我想如今已经不是什么陌生的概念：
1、封装（Encapsulation）能够把问题影响的范围缩小，外部的变化要求对系统的影响可以限定到某个类层次或某些类层次中，从而改变系统的一部分相对简单；
2、继承（Inheritance）能够使改变基于原有技术基础，非常大程度上降低反复开发工作； 3、多态（Polymorphism）的应用能够使开发和设计人员在相对统一的接口下更改系统的实现细节，从而改变系统的行为。
4、并且由于对OO的类体系结构业界有非常清楚明晰的描写叙述方式，就是眼下规范的描写叙述语言-UML，非常易于被开发组的理解并达成共识。促进开发组成员之间的合作以及加强软件开发工作的可延续性；
可见本身即是一种增强软件可维护性、健壮性以及保持设计稳定性的一种分析和设计方法，本身能够在一定程度上高速对需求变更进行反应，并可相对降低需求变更须要的成本。
（OO的意义在于分析和设计软件系统的思考方式，以及建立对象库以后的软件重用将给软件系统的开发带来质的改变。可是在建立OO开发体系之前的过程。一定会是一段荆棘遍布的路，须要付出加倍的努力以及达成思想的转变。这里另一个误区须要澄清的是非常多人以为用了C++，PB。VB。DELPHI就是面向对象的开发了，其实仅仅是用了一些面向对象的工具，骨子里仍然是结构化的分析和设计方法。套上一层OOP的外壳而已。）
可扩展性设计（Extensible-Design）
其次，从我们能够控制的软件设计来说，如何进行合适的设计才干最大程度降低需求变更带来的代价？
或许有人说。我的设计极为灵活。我已经估计了客户可能提出的要求，并设计几种应对的方式，到时候客户提出来，呵呵。我已经攻克了。这种想法不错。至少比僵硬的设计强。可是谁能够保证设计者能够预知以后的需求变化？而同一时候为了达到这种灵活（万能/多能？）的设计，设计将变得复杂，并且可能那些多余的设计从来不会被用到？复杂的设计将添加实现的难度和提高成本，并有可能带来潜在的Bug，使得系统难以维护。 设计的思想应该有一些小小的转变，那就是。设计确实要灵活。可是要体如今可扩展性上面。也就是说，设计能够简单，可是一定要易于转变，须要给出便于改变的接口。这一点非常重要。
结论
可见。在面对需求变更时，除了客观上能够通过人员培训、代价分析等管理方式进行有效的需求管理外，从分析和设计的角度能够通过採用合理的分析和设计方法，还有改变我们设计的意识。能够做到对需求变更的灵活应对，至少能够在一定程度上降低维护代价和提高用户惬意度。
