这个世界唯一不变的就是变化了。月有阴晴圆缺，潮涨潮落，千年前的沧海是现在的良田，这是自然界的变化;人有悲欢离合，生老病死，这是人情世故。变化是并不一定总是给我们带来惊喜，更多的是带来意外，使得我们被迫去作一些改变来适应这种变化。所以，变化也是我们人类得以从简单生物进化到今天的推动力。

　　回到我们软件需求这个论题上来，无疑，变化也是需求的一个基本特性。没有一成不变的需求，无论我们在正是构建之前对需求进行了多么深入的开发，和客户进行了多少回合的反复验证，而最终却不得不接受这样的现实：系统正式上线之后，在客户提交的试运行报告中，客户的需求发生了变化，或者客户又提出了新的需求等等。我们的软件开发人员陷入了这样的一个困境：需求总是在变化，客户总会有新的想法，项目好像没有终结，即使验收通过，那也是草草完事，而不是想象中的完美。

　　这是一个残酷的现实。所以Fred Brooks敢于1987的《没有银弹》这篇论文中强调不存在银弹，能使得软件工程的生产力能在十年之内提高十倍，这也是基于软件需求的这样一种复杂性的原因。我们只能被动接受这样的现实吗?不，我们还是有很多应对措施的。就好比我们在实际的生活中遇到变化时的策略一样，只是在应对软件需求变化时，我们拥有更多的准备。

　　在本篇文章中，我们将从项目管理的角度来讨论对变化的需求的策略：首先是讨论在构建前需求的质量，然后说明了如何在构建过程中对需求进行跟踪，最后讲述了当真正发生需求变更的时候，我们应该如何去面对。

　　我们先来看软件需求的生命周期，正如软件项目具有一般的过程，软件需求也有着一个普遍的生命周期，如下图所示：

　　上图中的项目阶段反映的是一般的项目过程，不管采用瀑布模型还是迭代开发或者是其他的软件开发生命周期模型，这样的一个基本过程是需要遵循的。而需求的生命周期和项目的阶段也是一一对应的。在项目的启动阶段，我们需要对项目进行可行性分析，完成立项报告，在这个阶段，也就种下了需求的“种子”，这个“种子”也决定了下面所有阶段的努力是否有成果，如果项目根本就是不可行的，那么就别提最后的“结果”了，“种子”是否能“萌芽”也都是个未知之数;如果通过了可行性分析，完成了项目的启动过程。接下来我们就要把需求这颗“种子”种下去，通过需求调研和需求分析阶段的努力，需求的“种子”开始“萌芽”，并且一直“成长”，直到“成熟”，需求“成熟”之后，我们就可以构建需求基线，进入项目构建阶段。如果对还没有“成熟”的需求就开始构建，那么后果就是在构建阶段需求的反复变化，开发人员疲于奔命。对“成熟”的需求进行构建，我们所交付的才是优质的“果实”，当然，项目后期也不可避免有需求变更，这时，只要我们按照规定的流程进行需求变更，将变更控制在一个可以接受的范围，这是不会影响到我们最终的交付的“果实”。

　　做好需求变更的管理，最终的目的是为了有优质的交付品。从上面的图中，我们可以得知，首先必须要有良好的“种子”和健康的“果树”，最后才有可能结出优质的“果实”。所以，做好需求开发是有效需求变更管理的基础。

　　1. 重视需求开发

　　需求开发是在问题及其最终解决方案之间架设桥梁的第一步，是软件需求过程的主体。一个项目的目的就是致力于开发正确的系统，要做到这一点就要足够详细地描述需求，也就是系统必须达到的条件或能力，使用户和开发人员在系统应该做什么，不应该做什么方面达成共识。我们都知道开发软件系统最为困难的部分就是准确说明开发什么，最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。

　　需求开发就是为了解决这些问题，它必不可少的成果就是对项目中描述的用户需求的普遍理解，一旦理解了需求，分析者、开发者和用户就能探索出描述这些需求的多种解决方案。这一阶段的工作一旦做错，将最终会给系统带来极大损害的部分，由于需求获取事物造成的对需求定义的任何改动，都将导致设计、实现和测试上的大量返工，而这时花费的资源和时间将大大超过仔细精确获取需求的时间和资源。而且通常会暴露出两方面问题：

　　第一，软件需求不能如实反映用户的真正需要。比较常见的一种误解是需求的简单和复杂程度决定了用户是否能够真正理解相应的内容：误认为客户只能看懂简单的需求，但是对开发没有直接帮助;只有复杂的需求才有用，但是大多用户又不可能看得懂。事实上，造成这类问题的主要原因是捕获的需求不能反映用户的视角，因而，用户站在自己的立场上很难判断需求是否完备和正确，特别是在开发活动的早期。

　　第二，软件需求不能被开发团队的不同工种直接共用。理论上，开发团队所有成员的工作内容都受软件需求制约;现实中，如果不采用理想的需求捕获方式，只有分析人员的工作看起来和软件需求的内容直接关联，其它人的工作内容和软件需求的关联并不直观，形式上的差异或转述往往不易察觉地造成了诸多歧义、冗余或者缺失。

　　本文并不会就此开始探讨需求开发的问题，只是强调需求开发过程的重要，以及需求开发过程对需求变更的影响。就拿笔者亲身参与的一个项目来说：我们遵循一般的软件开发过程，通过前期一段时间的调研，做需求分析，客户基本确认之后，开发人员就投入到紧张的开发工作中，由于项目时间要求紧迫，在经过测试人员的简单确认之后，进入到试运行阶段。结果是，在客户的试运行报告中，提出了很多问题，其中就有一条，关于一个数据查询条件的设置，客户要求的是模糊匹配查询，而实现的却是精确匹配查询。在相关的需求文档中，却找不到任何相关的需求说明。这就是一个很典型的需求工作没有做好，而导致的需求变更。

　　关于需求开发的质量问题，在《代码大全》一书中列出了一张关于需求的核对表[1]，如果能在需求开发完成之后，根据这张核对表来进行对照，相信一定能找到不少的需求质量问题。在此也不一一列出这张核对表的内容，核对表从四个方面来对需求进行检查：针对功能需求，针对非功能需求，需求的质量和需求的完备性。

　　需求开发完成之后，进入系统构建阶段，下面我们来谈构建过程中如何做好需求跟踪，以便于后期需求变更的管理。

　　2. 构建过程中的需求跟踪

　　跟踪需求是高质量软件开发过程中必需的一个特性。用以保证开发过程中每一个步骤的正确性，以及该步骤与上一步的一致性。经验表明，在需求规格、架构、设计、开发和测试阶段，对需求的跟踪能力是确保实现高质量软件的重要因素，同时也为需求变更管理提供有力的支持。跟踪这些需求在每个阶段的变化，并且分析变更带来的影响，是现代软件过程的一个主线，尤其是在一些事关重大的软件工程项目中，需求跟踪的影响更加突出。

　　历史数据表明，如果需求没有被完整的跟踪，那么总会有遗失的需求或者是没有解决的需求，或者是需求的变更没有彻底进行，导致部分影响被忽略了，而往往是这样的失误导致很严重的安全问题和可靠性问题，给客户带来不可估量的损失。这样的教训往往是非常惨痛而且印象深刻，笔者至今尤对这样的一次“事故”记忆犹新。那是参加的一个预算项目，在我们开发即将结束的时候，客户由于业务情况发生变化，提出了一条业务数据修改规则的变更。对于这个这个业务数据的写规则，虽然我们在需求文档中有记录，但是没有将其与设计、开发构件一一对应，建立它们之间的关联，导致在处理这条变更的时候，开发人员遗漏了一种情况的处理。而这样的问题直到在客户的应用系统运行半年之后才由客户发现，虽然事情最后通过升级软件、人工加工数据处理了这次意外，但是，事故给企业带来的不仅是金钱上的损失，也给企业的声誉带来非常不利的影响。

　　对需求的跟踪过程可以分为：

　　l 系统定义领域的需求跟踪

　　l 需求到实现的跟踪

　　l 需求到测试的跟踪

　　下图描述了这样的一种需求跟踪模型：

　　在上述模型中，箭头代表的是跟踪的方向，模型表明，不仅在需求定义的领域跟踪需求，而且我们也在实现领域和测试领域跟踪需求。在系统定义领域，包括有三个方向的跟踪：从业务需求到产品特性的跟踪;从用例到产品特性的跟踪;从变更的需求到产品新特性的跟踪。对于每一种跟踪，我们都可以使用类似于如下的一个表格来管理(以产品特性和用例的跟踪来举例，其他类似于这个表格)：

　　用例1用例2…用例n

　　产品特性1X X

　　产品特性2 X

　　…

　　产品特性n X

　　在实际项目中，要做好需求的跟踪管理并非易事，也许我们可以使用电子表格，办公软件来协助处理，确实，它们对于项目的管理非常有用。但是，表格的问题在于难于维护，特别是当项目较大，存在复杂的关联关系的情况，改变一个链接可能涉及到很多相关的链接，在这种情况下，维护就成了一场噩梦。在这种情况下，我们要么简化需求跟踪处理，对大的模块进行跟踪;要么使用专门的需求管理工具。如果是大型项目，最好使用工具来进行管理。这样，在我们面临需求变更的时候，才能有备无患。

　　3. 因时而变，做好需求变更控制

　　就如前文所述，变化总是避免不了的。变更天生就是软件过程的一部分。在这种情况下，我们需要建立一个管理变更的过程，使得变更的工作得到控制，并能高效的发现变更，进行影响分析，将变更有效的集成到现有系统中。一般说来，我们可以采用以下过程来管理变更：

　　首先，产生需求变更的因素包括内部因素和外部因素，不管需求变更来自哪里，都需要遵循一个既定的流程来提出变更请求。这样的渠道根据实际的企业情况有各自的方案。一般说来，如果是来自客户的变更，都需要遵照一个固定流程，通过一种正式的方式提交。即使客户口头的提出，那么也需要通过会议记录、文件交由客户签字确认后才正式进入变更流程。否则，如果在没有正式依据下就进行需求变更，这样的项目将进入无休止的修改和维护状态。

　　对于提出的变更请求，首先可以通过项目小组指派专人负责进行分析，包括该变更的可行性分析，对其他需求的影响分析，对项目进度的影响分析等。在这个过程中，就需要利用前文中所述的各种需求跟踪表格。通过需求跟踪表格，列举出该变更所涉及需要修改的其他需求，影响的其他用例、测试用例、用例实现等。然后才可以对工作量进行估算，评估该变更的可行性以及对项目进度影响等。

　　在变更管理中，有一个重要的角色：变更控制委员会(Change Control Board，简称CCB)。CCB的成员一般是项目经理、技术负责人、相关领导等。当对需求变更分析完毕之后，提交给CCB进行变更评审，一般说来，只有评审通过的变更才可以进行变更处理。

　　对变更评审结束之后，如果评审通过了变更，那么就开始进行变更处理，首先是要制定变更的开发计划。经验表明，如果涉及的人时超过50人时，都需要制定该变更的计划。如果变更处理人时较少，可以没有正式的变更计划。制定了变更计划之后，根据计划对变更的需求进行开发，这个阶段涉及到原有代码的修改。也是需要遵循一般软件过程，从设计到开发、测试。

　　变更开发结束之后，也需要组织相关人员对变更进行评审，这样的评审往往能发现不少潜在的问题，比如有遗漏的需求没有修改等。只有评审通过后，才能进入下一阶段，对变更相关的文档、产品进行维护，使得需求文档、设计文档、产品保持一致性。至此，整个需求变更过程结束。

　　需求变更管理是需求管理中的一个重要部分，只有有效的需求变更管理提才能高产品的可能性，并使最终产品更接近于解决需求，提高了用户对产品的满意度，从而使产品成为真正优质合格的产品。从这层意义上说，需求变更管理是产品质量的基础。本文从需求开发、需求跟踪和需求变更过程三个方面来讨论了需求的变更管理。一方面希望能引起业界对需求管理的关注，另外也希望能借此抛砖引玉，引发各位方家对需求管理方面的讨论。

　　[1] Steve McConnell，《代码大全》，英文名《Code Complete》，电子工业出版社，P42。