对需求的理解分歧当客户向需求分析人员提出需求的时候往往是通过自然语言来表达的，这样的表达对于真实的需求来说是一种描述(甚至只是某个角度的描述)，远远不能保证这样的描述可以得到百分之百的正确理解，也许在同客户交流的第一时刻就埋下了理解分歧的种子，打一个比方说客户说我要的是大象，身子象一堵墙，耳朵象扇子，四条腿象四根柱子，尾巴象绳子，分析人员想，哦，墙、扇子、柱子、绳子这些我都知道，但是真的画出来的时候客户当然会跳起来了!这是理解分歧的问题，一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关;系统实施时间过长一个大中型系统的建设可能要延续一段时间，当客户提出要求之后，他当时并不能看到系统的运行情况，当双方认为理解大概没有分歧的时候(事实上还会有个Deadline )，开发方就开始工作了。当客户拿到差不多可以试用的产品时他可以实际操作，这时候他就会对系统的界面、操作、功能、性能等有一些切身的体会，有可能提出需求变更要求;客户具体情况不一当前客户的情况不一，有可能客户行业的竞争度高，需要随时作出调整和反应，那么他们自然会经常提出需求变更的要求;也有可能客户所在的行业操作不规范，本身存在很多人为因素，这时候开发方更是需要随时准备应变;开发本身要求有可能是来自开发方自身版本升级或性能改进、设计修正的要求出现需求变更，这时更是无法绕开这个问题的了!所以说就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的，所以不要梦想那么理想的需求分析，当你开始一个项目的时候就应该意识到，客户需求变更一定会有的，那么对于这样的现状，我们该怎么办呢?客户是上帝，难道我们就象以前一样，跟着客户的需求不停地修改软件，到最后工期延长，员工疲惫，成本成倍增长，客户满意度降低，原来的设计也会改变得支离破碎，系统难以维护?客观面对需求变更如果需求一定会变化，如果我们不得不面对，如果我们已经痛定思痛，想要变革，那么还有什么办法可以改善我们的现状答案是有的。加强人员培训从客观方面可以采取的措施来说，首先，我想不容置疑的是加强对需求分析人员的培训，尽可能增强软件系统、行业的背景知识，提高与客户的沟通能力，增强服务意识和责任感，因为将要开发的系统直接建立在需求分析的基础上;同时规范需求分析人员和客户沟通的方式，以及规范需求说明的格式，如果可能的话，尽量采取象XP 的UserStory ，或者用户可以理解的用例图来对需求进行标准、规范的描述，保证双方在工具的协助下对需求达到共同的认识，这一点是老生常谈，就不多说。

　　确定文档的有效性(Validity )顺便要提的一句是关于文档，需求文档是相当重要的，可是目前存在一种奇怪的现象，本来说必须要有文档，而且是按照某种特定的格式，当然这没有错，但接下来，却没有人关心文档的真正内容是否正确，格式是否真的合理，是否实用(而且很多情况下是在几天时间里赶出来或补上去的)，例如我遇到一个例子，需要在原来的需求基础上进行后续开发，文档找到了，完全符合格式的要求，但是我在里面找到的线索是有限的，结果是自己花几天的时间查找数据表结构、甚至查看数据表的内容，询问当时的开发人员，才分析到所要的关系，这种情况在设计文档里也存在，所以同时提一提，希望我们的开发人员、PM 以及各级领导可以注意文档的有效性和有用性问题，甚至对文档的格式进行一下合理性检查。建立代价估算(Cost Estimate )概念这一点对开发方和客户同样重要，因为如果出现需求变更，不可避免将带来成本的增加、开发时间延长等不良后果，这样的影响是双方的。这时候需要区分需求变更的原因，是客户方必要/不必要的要求，还是由于开发方的工作失误，还是双方都有原因，然后对现实情况进行分析，得出双方实现变更需求的需要的成本，包括时间，人力，资源等等方面，再与客户商讨是否必要进行变更和如何在最小代价下实现变更。当客户看到实际的代价估算，他们也会再一次慎重地考虑需求变更问题，也会更容易理解系统建设中的进行状况，自然开发方也不用负担所有的需求变更成本，

　　所以进行成本分摊还是有其积极意义的。当然还有建立需求变更版本控制等等专业的需求管理，在这里不做专门论述。从软件分析和设计着手前面说了面对需求变更的几种策略，那么从软件系统分析和设计的角度来看，通过采用合理的分析设计方法，进行可扩展性设计可以有效地降低需求变更引起的风险和维护代价。

　　采用OO 技术

　　采用OO 技术可以建立易于改变和加强可重用性的软件系统。

　　对于OO 技术，我想现在已经不是什么陌生的概念：

　　1 封装(Encapsulation )可以把问题影响的范围缩小，外部的变化要求对系统的影响可以限定到某个类层次或某些类层次中，从而改变系统的一部分相对简单;

　　2 继承(Inheritance )可以使改变基于原有技术基础，很大程度上减少重复开发工作;

　　3 多态(Polymorphism )的应用可以使开发和设计人员在相对统一的接口下更改系统的实现细节，从而改变系统的行为;

　　4 而且由于对OO 的类体系结构业界有非常清楚明晰的描述方式，就是目前规范的描述语言-UML ，非常易于被开发组的理解并达成共识，促进开发组成员之间的合作以及加强软件开发工作的可延续性;可见本身即是一种增强软件可维护性、健壮性以及保持设计稳定性的一种分析和设计方法，本身可以在一定程度上快速对需求变更进行反应，并可相对减少需求变更需要的成本。(OO 的意义在于分析和设计软件系统的思考方式，以及建立对象库以后的软件重用将给软件系统的开发带来质的改变，但是在建立OO 开发体系之前的过程，一定会是一段荆棘遍布的路，需要付出加倍的努力以及达成思想的转变。这里还有一个误区需要澄清的是很多人以为用了C++，PB ，VB ，DELPHI 就是面向对象的开发了，其实只是用了一些面向对象的工具，骨子里仍然是结构化的分析和设计方法，套上一层OOP 的外壳而已。)可扩展性设计(Extensible-Design )

　　其次，从我们可以控制的软件设计来说，怎样进行合适的设计才能最大程度减少需求变更带来的代价?

　　许有人说，我的设计极为灵活，我已经预计了客户可能提出的要求，并设计几种应对的方式，到时候客户提出来，呵呵，我已经解决了。这样的想法不错，至少比僵硬的设计强，但是谁可以保证设计者可以预知以后的需求变化?而同时为了达到这种灵活(万能/多能?)的设计，设计将变得复杂，而且可能那些多余的设计从来不会被用到?复杂的设计将增加实现的难度和提高成本，并有可能带来潜在的Bug ，使得系统难以维护。

　　设计的思想应该有一些小小的转变，那就是，设计确实要灵活，但是要体现在可扩展性上面，也就是说，设计可以简单，但是一定要易于转变，需要给出便于改变的接口，这一点很重要。

　　结论

　　可见，在面对需求变更时，除了客观上可以通过人员培训、代价分析等管理方式进行有效的需求管理外，从分析和设计的角度可以通过采用合理的分析和设计方法，还有改变我们设计的意识，可以做到对需求变更的灵活应对，至少可以在一定程度上降低维护代价和提高用户满意度。软件需求的管理和控制是非常专业的学问，作者在这里结合自己的实践提出一些粗浅的认识，只是想起到一个抛砖引玉的作用，希望大家可以一起来面对和想办法解决我们在系统开发过程中的实际问题，我想那样才是我真正想达到的目的。