辛辛苦苦的熬了几个月，软件开发终于快要告一段落了。系统功能已经基本完成了，在准备按部班的完成后的测试时，客户突然提出要改变某些非功能性需求。这对于软件开发团队来说，不亚于晴天惊雷，这也是让所有软件开发人员感到恐怖的事情之一。因为在多数情况下，对非功能性需求的变更都会演变成一个对系统无休止的修改过程，终会把客户和开发团队都拖进泥潭而难以自拔。

　　需求变更本应是客户的权力，如果确是需要变更，当然要满足客户需要。但问题是不能让变更权力滥用，把一些无关痛痒的非功能性需求变更宠惯养成堂而皇之的变更。对于非功能性需求客户总会有新的想法，项目好像总没有办法终结。以前当出现这种情况时，我总觉得很沮丧，觉得自己非常不幸，怎样会碰上这样的客户。可在读了《设计模式精解（Design Patterns Explained）》一书的一段话后，我恍然大悟，这不是我的错，世界原来是这样子的啊，永远不变的是变化。

　　令人烦恼的非功能性需求变更

　　在软件开发中，大家都会遇到过这样的问题：客户的一个新想法，推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些，毕竟功能性需求不实现的话，是会大大影响到软件产品的质量。但现在我所负责的这个开发项目中遇到的都是一些非功能性的变更，而且许多是看起来无关痛痒的、鸡毛蒜皮的变更。

　　（1）什么是非功能性需求？

　　在IEEE中，软件需求的定义是：用户解决问题或达到目标所需的条件或功能。一般包含业务需求、用户需求、功能需求、行业隐含需求和一些非功能性需求。业务需求反映了客户对系统、产品高层次的目标要求；功能需求定义了开发人员必须实现的软件功能。所谓非功能性需求，是指为满足用户业务需求而必须具有除功能需求以外的特性。包括系统性能、可靠性、可维护性、易用性和对技术和对业务适应性等。其中常见的是软件界面、操作方便等一系列要求。

　　（2）非功能性需求变更的特点

　　让我们从客户角度和开发人员角度去看看非功能性需求的特点。首先，有些非功能性小需求从客户角度看起来工作量不大，但是实际上开发人员要耗费比较长的时间去完成这些小功能。其次，许多非功能性需求，如界面美观、操作方便等都是客户头脑一热、或领导一拍脑袋部署下去的需求，往往是原来在需求分析阶段所没有注意的内容。

　　其实，非功能性需求是常常被轻视，甚至被忽视的。原因是非功能性需求描述很困难，它很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚。在描述这类需求时候，我们经常采用软件性能要好、操作要方便、软件界面要美观大方等较模糊的描述词语。例如，易用性同时涉及到美工和UI界面、人机工程、交互式设计、心理学、用户行为模式等内容。这类描述词语都是脱离了软件的执行环境，是对人和相关的场景的描述，因此很难体现到软件架构设计和具体的实现中。

　　为什么非功能性需求变更会频繁发生？

　　为什么非功能性需求不能固定下来呢？或定下来后不许变了呢？通常有许多人会问这样的问题。实际上，当他变成了客户时，他可能不会问这个问题了。

　　（1）非功能性需求容易产生理解分歧

　　在软件需求分析阶段，客户和开发人员对非功能性需求的理解呈现"大体上共识多，细节上差异多"的特点。一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关。即使通过反复沟通，但是以实践经验来看非功能性需求的描述还是永远不够清晰、不够明确的，主要是因为在这个阶段所谓的产品还只存在于大家的大脑构思中。

　　作为一个客户，大多数情况下是不懂技术的，但他所需要的软件在他的心里还是有一个印象的。他会想象出软件的样子和功能，然后通过口头或者笔头的方式告诉需求分析人员。简单的说，是在这个阶段用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，或者是他们想象出来的东西。结果是当客户向需求分析人员提出需求的时候，往往是通过自己的想法用自然语言来表达的，这样的表达结果对于真实的需求来说只是一种描述，甚至只是某个角度的描述，但远远不能保证这样的描述可以得到百分之百的正确理解。

　　当客户提出要求之后，在双方认为理解大概没有分歧的时候，开发人员开始工作了。但随着开发工作的不断进展，系统开始展现雏形，客户对系统的了解也逐步深入。这个时候，客户会对系统的界面、操作、功能、性能等有一些了解，有可能提出需求变更要求，而且这些要求很多是基于主观的、人为的因素。总之，他们了解得越多，新的要求也会越多。

　　（2）没有明确的需求变更管理流程

　　在软件开发中的常识是，一旦发生需求变更不要一味的抱怨，也不要一味地去迎合客户的新需求，而是要管理和控制需求变更。但令人不解的是我们常常看到变更的提出、讨论和执行常常只停留在口头上。这样做有两个弊端：首先是时间一长，无论是当事人还是开发团队都说不清楚变更是因何发生以及结果怎么样了。显然，这对于提高项目质量、改进开发过程是很不利的。其次是由于缺乏形式上的约束和对变更代价的定量分析，变更会被非常随意地提出、或被草率地执行，也会大大影响项目的进展和开发质量。

　　因此，没有明确的需求变更管理流程，会使需求变更变得泛滥。因为并不是所有的变更都要修改，也不是所有变更都要立刻修改，需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。比如界面风格问题，可以先不修改，或者规划一下修改的时间待到以后进行优化。