令人烦恼的需求变更

　　在软件开发中，大家都会遇到过这样的问题：客户的一个新想法，推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些，毕竟功能性需求不实现的话，是会大大影响到软件产品的质量。但是一些非功能性的变更会让人很头疼，许多是看起来无关痛痒的、鸡毛蒜皮的变更，却是极为令人无语和无奈，甚至是烦恼和厌恶的。

　　（1）什么是软件需求？

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

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

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

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

　　国内的很多软件公司，对于这种情况趋之若鹜，认为是负担，影响软件公司的工作安排，工作量以及工作进度，直接导致了软件公司的效益，几乎是很多软件公司的大隐患，因此我们如何认识、对待这个普遍存在的问题成了软件公司以及员工需要解决的问题；

　　1）首先，要从心理上彻底根除对需求变更的恐惧，从认识上明确需求变更是软件开发过程中不可缺少的部分，从方针上明确需求变更的存在性和必然性；

　　　　a）从软件公司角度，认清自身存在的不足， 客观面对需求的变更

　　　　b）从职员角度，提高本身的业务和技术能力

　　2）从技术角度上使需求变更的处理简单化，明确化，增加可维护性；

　　　　a）使用更好的技术手段，设计更灵活以用来适应更多变的需求；

　　　　b）使用更完善的软件工程的理念，让软件各个步骤细化，更易维护和修改；

　　　　c）使用完善的测试流程，大的降低需求变更带来的软件风险；

　　3）对需求变更进行有效的管理，让需求变更可以规范化管理，做到有效的处理需求的变更，用有限的资源获得大的效益；

　　　　a）软件的初期，要考虑大限度的减少将来可能存在的需求变更

　　　　b）需求的控制，减少需求的来源，过滤不合理的需求

　　　　c）文档化管理，有备可查，有据可依；

　　　　d）合适的公司体制和运作，找到一条适合自己公司发展的运作体制和管理模式；

　　可能大家觉得上面说的话有些空，那么我从技术角度上再具体的谈谈。

　　像刚才说过的，需求变更是必然存在的。从技术的角度来降低或避免需求变更给我们带来的影响显得极为重要。

　　1、设计之初，充分理解需求，更好对需求进行整理和规划，预测可能变更的需求。

　　需求难做，业务难做，非功能性的需求变更更是难做。所以当我们在收集了用户需求后，不仅仅是简单的分类，然后按部班的开发，而是要深入挖掘需求，一些看似固定业务的需求，可能由于业务的变更而使得你的系统不能使用。我们要做的是拆分需求，把一些可能会发生变化的需求拆开，改成工作流程可配置的。像面向过程转向面向对象的那样，面向过程是死的，而面向对象重新组合后，特别简单。