文档介绍：软件开发如何应对非功能性需求变更?     需求变更本应是客户的权力,如果确是需要变更,当然要满足客户需要。但问题是不能让变更权力滥用,把一些无关痛痒的非功能性需求变更宠惯养成堂而皇之的变更。对于非功能性需求客户总会有新的想法,项目好像总没有办法终结。以前当出现这种情况时,我总觉得很沮丧,觉得自己非常不幸,怎样会碰上这样的客户。可在读了《设计模式精解(DesignPatternsExplained)》一书的一段话后,我恍然大悟,这不是我的错,世界原来就是这样子的啊,永远不变的就是变化。令人烦恼的非功能性需求变更     在软件开发中,大家都会遇到过这样的问题:客户的一个新想法,就推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些,毕竟功能性需求不实现的话,是会大大影响到软件产品的质量。但现在我所负责的这个开发项目中遇到的都是一些非功能性的变更,而且许多是看起来无关痛痒的、鸡毛蒜皮的变更。(1)什么是非功能性需求?     在IEEE中,软件需求的定义是:用户解决问题或达到目标所需的条件或功能。一般包含业务需求、用户需求、功能需求、行业隐含需求和一些非功能性需求。业务需求反映了客户对系统、产品高层次的目标要求;功能需求定义了开发人员必须实现的软件功能。所谓非功能性需求,是指为满足用户业务需求而必须具有除功能需求以外的特性。包括系统性能、可靠性、可维护性、易用性和对技术和对业务适应性等。其中最常见的是软件界面、操作方便等一系列要求。(2)非功能性需求变更的特点     让我们从客户角度和开发人员角度去看看非功能性需求的特点。首先,有些非功能性小需求从客户角度看起来工作量不大,但是实际上开发人员要耗费比较长的时间去完成这些小功能。其次,许多非功能性需求,如界面美观、操作方便等都是客户头脑一热、或领导一拍脑袋就部署下去的需求,往往是原来在需求分析阶段所没有注意的内容。     其实,非功能性需求是常常被轻视,甚至被忽视的。原因是非功能性需求描述很困难,它很难像功能性需求那样,可以通过结构化和量化的词语来描述清楚。在描述这类需求时候,我们经常采用软件性能要好、操作要方便、软件界面要美观大方等较模糊的描述词语。例如,易用性就同时涉及到美工和UI界面、人机工程、交互式设计、心理学、用户行为模式等内容。这类描述词语都是脱离了软件的执行环境,是对人和相关的场景的描述,因此很难体现到软件架构设计和具体的实现中。为什么非功能性需求变更会频繁发生?     为什么非功能性需求不能固定下来呢?或定下来后就不许变了呢?通常有许多人会问这样的问题。实际上,当他变成了客户时,他可能就不会问这个问题了。(1)非功能性需求容易产生理解分歧     在软件需求分析阶段,客户和开发人员对非功能性需求的理解呈现"大体上共识多,细节上差异多"的特点。一般跟分析员的知识、背景,还有客户表述的标准程度、双方的交流情况有关。即使通过反复沟通,但是以实践经验来看非功能性需求的描述还是永远不够清晰、不够明确的,主要是因为在这个阶段所谓的产品还只存在于大家的大脑构思中。     作为一个客户,大多数情况下是不懂技术的,但他所需要的软件在他的心里还是有一个印象的。他会想象出软件的样子和功能,然后通过口头或者笔头的方式告诉需求分析人员。简单的说,就是在这个阶段用户往往不能