以下关于需求变更策略的叙述中，（）是错误的A、所有需求变更必须遵循变更控制过程B、对于未获得核准的变更，不应该做变更实现工作C、完成了对某个需求的变更后，就可以删除或者修改变更请求的原始文档D、每一个需求变更必须能追溯到一个经核准的变更请求

变更完成之后，变更的原始文档资料必须保存。

一个大型软件系统的需求总是有变化的。为了降低项目开发的风险，需要一个好的变更控制过程。合理的变更控制为识别问题、问题分析与变更描述、变更分析与成本计算、变更实现、得到修改后的需求。自动化工具能够帮助变更控制过程更有效地运作，能有效收集、存储、管理变更，工具应该具备的特征如下：（1）可定义变更请求中的数据项；（2）可定义变更请求生命周期的状态转换模型；（3）可强制实施状态转换模型，确保只有授权用户才能进行所允许的状态变更；（4）可记录每一个状态变更的日期和做出这一变更的人；（5）可定义当提交了新请求或者请求状态出现更新时，哪些人可以接收到电子邮件通知；（6）可生成标准的和定制的报告和图表。

一个大型的软件系统的需求总是有变化的。对许多项目来说，系统软件总需要不断完善，一些需求的改进是合理的而且不可避免，要使得软件需求完全不变更，也许是不可能的，但毫无控制的变更是项目陷入混乱、不能按进度完成，或者软件质量无法保证的主要原因之一。一个好的变更控制过程，给项目风险承担者提供了正式的建议需求变更机制，可以通过变更控制过程来跟踪已建议变更的状态，使己建议的变更确保不会丢失或疏忽。需求变更管理过程如下图所示：

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

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

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

自动化工具能够帮助变更控制过程更有效地运作。许多团队使用商业问题跟踪工具来收集、存储和管理需求变更。用这样的工具创建的最近提交的变更建议清单，可以用作CCB会议的议程。问题跟踪工具也可以随时按变更状态分类报告出变更请求的数目。

因为可用的工具、厂商和特性总在频繁地变化，所以这里无法给出有关工具的具体建议。但工具应该具有以下几个特性，以支持需求变更过程:

①可以定义变更请求中的数据项；

②可以定义变更请求生命周期的状态转换模型；

③可以强制实施状态转换模型，以便只有授权用户可以做出允许的状态变更；

④可以记录每一个状态变更的日期和做出这一变更的人；

⑤可以定义当提议者提交新请求或请求状态被更新时，!哪些人可以自动接收电子邮件通知；

⑥可以生成标准的和定制的报告和图表。

有些商业需求管理工具内置有简单的变更建议系统。这些系统可以将提议的变更与某一特定的需求联系起来，这样无论什么时候，只要有人提交了一个相关的变更请求，负责需求的每个人都会收到电子邮件通知。

每项记录在案的变更请求都必须由一位责任人批准或否决，这个责任人通常是项目发起人或项目经理。应该在项目管理计划或组织流程中指定这位责任人。必要时，应该由变更控制委员会（CCB）来决策是否实施整体变更控制过程。

在需求管理过程中需求的变更是受严格管控的，其流程为:（1）问题分析和变更描述：识别和分析需求问题，检查有效性，从而产生一个更明确的需求变更提议。（2）变更分析和成本计算：利用可追溯的信息和系统需求的知识，对需求变更提议进行影响分析和评估。变更成本计算包括需求文档修改成本、系统修改的设计和实现成本。分析并确认变更后，则决策是否执行变更。（3）变更实现：要求需求文档和系统设计、实现都要同时修改。如果先对系统程序做变更，然后再修改需求文档，则会出现需求文档和程序的不一致。

一个大型软件系统的需求通常是会发生变化的。在进行需求变更时，可以参考以下的需求变更策略：
（1）所有需求变更必须遵循变更控制过程
（2）对于未获得批准的变更，不应该做设计和实现工作
（3）变更应该由项目变更控制委员会决定实现哪些变更
（4）项目风险承担者应该能够了解变更数据库的内容
（5）决不能从数据库中删除或者修改变更请求的原始文档
（6）每一个集成的需求变更必须能跟踪到一个经核准的变更请求