系统架构设计师考试培训需求变更

4.2.4需求变更

一个大型软件系统的需求总是有变化的，原因是该系统通常是要解决一些复杂和难 度大的问题，而一些问题不可能一次就被完全定义：此外，开发者对问题的理解可能在 变化，这些变化也反映到需求中。

对许多项目来说，系统软件总需要不断完善，一些需求的改进是合理的而且不可避 免，要使得软件需求完全不变更，也许是不可能的，但毫无控制的变更是项目陷入混乱、 不能按进度完成，或者软件质量无法保证的主要原因之_.事实上，迟到的需求变更会 对已进行的工作产生非常大的影响。如果不控制范围的扩展，将使我们持续不断地采纳 新功能，而且要不断地调整资源、进度或者质量标准，是极为有害的。如果每一个建议 的需求变更都采用，该项目将有可能永远不能完成。

软件需求文档应该精确描述要交付的产品，这是一个基本的原则。为了使开发组织 能够严格控制软件项目，应该确保以下事项：

仔细评估已建议的变更

挑选合适的人选对变更做出决定。

变更应及时通知所有涉及的人员。

项目要按一定的程序来采纳需求变更。

1.变更控制过程

一个好的变更控制过程，给项目风险承担者提供了正式的建议需求变更机制。通过 这些处理过程，项目负责人可以在信息充分的条件下做出决策。我们可以通过变更控制 过程来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽。一旦确定了需求 基线，应该使所有已建议的变更都遒循变更控制过程。

需求变更管理过程如图4-8所示。

（1）问题分析和变更描述。这是识别和分析需求问题或者一份明确的变更提议，以 检查它的有效性，从而产生一个更明确的需求变更提议。

（2）变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更 提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计 和实现的成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。

（3）变更实现。这要求需求文档和系统设计以及实现都要同时修改。如果先对系统 的程序做变更，然后再修改需求文档，这几乎不可避免地会出现需求文档和程序的不 一致。

变更控制过程并不是给变更设置障碍。相反地，它是一个渠道和过滤器，通过它可 以确保采纳最合适的变更，使变更产生的负面影响降到最低。变更过程应该做成文档， 而且要简单、有效。

控制需求变更与项目的其他配置管理决策也有着密切的联系。项目管理应该达成一 个策略，用来描述如何处理需求变更，而且策略具有现实可行性。

我们可以参考以下的需求变更策略：

（1）所有需求变更必须遵循变更控制过程。

（2）对于未获得批准的变更，不应该做设计和实现工作。

（3）变更应该由项目变更控制委员会决定实现哪些变更。

（4）项目风险承担者应该能够了解变更数据库的内容。

（5）决不能从数据库中删除或者修改变更请求的原始文档。

（6）每一个集成的需求变更必须能跟踪到一个经核准的变更请求。

在实际中，人们总是希望使用自动工具来执行变更控制过程。、有许多人使用商业问 题跟踪工具来收集、存储、管理需求变更。可以使用工具对一系列最近提交的变更建议 产生一个列表给变更控制委员会开会时做议程用。问题跟踪工具也可以随时按变更状态 分类报告变更请求的数目。

挑选工具时可以考虑以下几个方面：

（1）可以定义变更请求的数据项。

（2）可以定义变更请求生存期的状态转换图。

（3）可以加强状态转换图使经授权的用户仅能做出所允许的状态变更。

（4）记录每一种状态变更的数据，确认做出变更的人员。

（5）可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。

（6）可以根据需要生成标准的或定制的报告和图表。

2.变更控制委员会

变更控制委员会可以帮助我们很好地管理项目，哪怕是一个小项目。一个有效率的 变更控制委员会定期地考虑每个变更请求，并且基于由此带来的影响和获益做出及时地 决策。

变更控制委员会只要能决定合适的人做正确的事就足够了，不必追求大而全。变更 控制委员会负责决定哪些已建议需求变更或者新产品特性付诸应用，决定在哪些版本中 纠正哪些错误。广义上，变更控制委员会对项目中任何基线工作产品的变更都可以做出 决定，需求变更文档仅是其中之一。

变更控制委员会可以由一个小组担任，也可以由多个不同的组担任。变更控制委员 会的成员应能代表变更涉及的团体。变更控制委员会可能包括如下方面的代表：

产品或计划管理部门。

项目管理部门。

开发部门。

测试或质量保证部门。

市场部或客户代表。

制作用户文档的部门。

技术支持部门。

帮助桌面或用户支持热线部门。

配置管理部门。

对于小项目只需几个人充当其中的一些角色就可以，并不一定要面面俱到。组建包 含软、硬件两方面的项目的变更控制委员会时，也要包括来自硬件工程、系统工程、制 造部门或者硬件质量保证和配置管理的代表。建立变更控制委员会在保证性的前提 下应尽可能精简人员。

变更控制委员会应该有一个总则，用于描述变更控制委员会的目的、授权范围、成 员构成、做出决策的过程及操作步骤。总则也应该说明举行会议的频度和事由。管理范 围描述该委员会能做什么样的决策，以及有哪一类决策应上报到髙一级的委员会。过程 及操作步骤如下。

1）制定决策

制定决策过程的描述应确认：

变更控制委员会必须到会的人数或做出有效决定必须出席的人数。

决策的方法（例如投票，一致通过或其他机制）。

变更控制委员会主席是否可以否决该集体的决定。

变更控制委员会应该对每个变更权衡利弊后做出决定。"利"包括节省的资金或额外 的收入、增强的客户满意度、竞争优势、减少上市时间；"弊"是指接受变更后产生的负 面影响，包括增加的开发费用、推迟的交付日期、产品质量的下降、减少的功能、用户 不满意。如果估计的费用超过了本级变更控制委员会的管理范围，应上报到高一级的委 员会，否则用制订的决策过程来对变更做出决定。

1）交流情况

一旦变更控制委员会做出决策，指派的人员应及时更新数据库中请求的状态。有的 工具可以自动通过电子邮件来通却相关人员。若没有这样的工具，就应该人工通知，以 保证他们能充分处理变更。

3）重新协商约定

变更总是有代价的。即使拒绝的变更也因为决策行为（提交、评估、决策）而耗费 了资源。变更对新的产品特性会有很大的影响。如果对一个工程项目增加很多新功能。 又要求在原先确定的进度计划、人员安排、资金预算和质量要求限制内完成整个项目是 不现实的。

当工程项目接受了重要的需求变更时，为了适应变更情况要与管理部门和客户重新 协商约定。协商的内容可能包括推迟交货时间、要求增加人手、推迟实现尚未实现的较 低优先级的需求，或者质量上进行折中。要是不能获得一些约定的调整，应该把面临的 风险写进风险管理计划中。