关键词：需求、需求变更、需求分析、代价估算、面向对象技术、封装、继承、多态、UML 、软件设计、软件可维护性、可扩展性、软件可重用性、接口

摘要：作者针对当前软件系统建设中普遍存在的需求变更问题提出了自己的见解，并提出除了从客观上采取加强培训和代价分析等方法外，更重要的是通过采用合理的分析设计方法，进行可扩展性设计可以有效地降低需求变更引起的风险和维护代价，并给出了可扩展性设计的一个具体例子。

软件系统开发过程中的需求变更问题

作为软件开发人员或者软件系统客户，相信我们都遭遇过因为需求变更而需要修改系统的情况，一般说来客户会要求改变界面，改变操作方式，甚至改变业务，说，当时我是那样要求的，不过现在我们的业务调整了…这时需要中断正在进行的工作，需要查证以往的资料，需要修正计划，需要…

需求包括业务需求、用户需求和功能需求。业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement ）描述了用户使用产品必须完成的任务，功能需求（Functional Requirement ）定义了开发人员必须实现的软件功能。在软件系统开发过程中，有很多问题都是由于在需求分析阶段没有正确地收集、编写、协商、修改产品真实需求而产生的，造成这样的状况有几方面的原因:

对需求的理解分歧

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

系统实施时间过长

一个大中型系统的建设可能要延续一段时间，当客户提出要求之后，他当时并不能看到系统的运行情况，当双方认为理解大概没有分歧的时候（事实上还会有个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 ，使得系统难以维护。

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

例如，现在有一个类叫做TCPConnection ，来代表计算机网络通信中典型的TCP 连接，对于这个连接而言，它可能处于以下几种状态：Established （连接已建立），Listening （正在侦听），Closed （连接关闭）。一个连接对象需要从其他的对象接受请求，至于它的反应则决定于连接对象所处的状态，对于（打开连接的请求），如果是在连接关闭状态，则进行Open （），处于其他状态则不做反应；同样，如果在连接建立和侦听状态，可以进行Close （），在连接建立状态可以进行Acknowledge （），即接收数据。

对于这样的状况，最不可取的设计应该是用一系列的Switch 语句（甚至If/else 语句）进行Hard 设计，对于以后每一次需求改变，都需要改变源代码，接踵而来的系统一致性、文档更新等工作将使开发人员不可避免地陷入一场灾难，这样的后果将导致原来就不合理的设计变得更加支离破碎，系统维护的代价将越来越大；就算没有需求变更发生，这些设计的可重用性也会极差。稍好一些的设计是预先估计并设置TCPConnection 类所有可能的状态，并预先加入设计，这种需要付出更多的设计、开发、维护的代价，而且也很难达到完美的效果，所以不多说了。

下面介绍一种经典的设计思路，这种设计可以充分体现“为（系统）将来改变预留接口”的可扩展性（Extensible-Design ）思想，并且很好的实现了这一思想。在这里，我们引入一个抽象类TCPState 来代表TCPConnection 类的状态，给出具体各种状态的通用操作接口，并派生出不同的子类（实现具体的操作）

去实现TCPConnection 类的不同状态，例如派生出TCPEstablished 类来实现TCPConnection 类的连接建立状态。结构图示如下：

只需要在TCPConnection 类中包含一个TCPState 的状态引用，并在TCPConnection 的状态改变时更新为当前的状态引用，例如在连接关闭时进行Open （），状态引用就应该从TCPClosed 变成TCPEstablished ，这样就实现了原来的要求。

但这个设计思路的意义远不止于此。我们可以看到，抽象类TCPState 已经为TCPConnection 类将来可能的状态留出接口，只需要不断派生具体的不同状态子类就可以实现将来的状态变更，并且无须影响原有的设计，也无须加入多余的代码来实现现在还不需要的功能，所以这是一个优美的、可扩展的设计思路，非常清晰，易于维护，相信可以给我们在做软件设计时带来一些启发。

结论

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

参考文献：