管理不断变化的需求

不可避免的是，需求将在项目的规格说明和解决方案阶段发生变化，并且大多数需求管理流程都具有某种类型的机制来适应这些变化。通常，将为解决方案团队指定并整理一组需求。任何后续更改都指定为“更改请求”。不管所使用过程的严格性如何，都会发生无意的更改，需要将其与更改请求一起进行管理。 Enterprise Architect是一个复杂的需求管理平台，具有一系列辅助需求管理器的工具。可以在“维护”窗口中管理变更请求，该窗口允许记录和描述所请求的变更，以及请求者，完成时间和完成者。可以使用许多工具功能（包括审核，基准和版本控制）来发现和分析无意的更改；这些工具具有一些重叠的功能，可以单独使用或一起使用。内置的安全系统还将允许建模人员有意锁定模型中的包和元素，从而有助于防止意外更改模型。

管理变更需求的机制

机制	描述
元素变更任务和工作量项目	需求的更改可能会无意间发生，但更常见的是，有针对性的更改是对多种因素的响应，例如利益相关者修改需求，业务变化或对问题的了解不多。可以使用许多工具来获取无意的更改，但是可以使用“更改”项来分配有意的更改，该更改项可以记录在每个元素上。一旦分析了变更的影响，就可以创建任务以指定需要执行哪些操作来实施变更，并且可以使用“需求工作量”项来分配工作量。
稽核	审核是一个内置工具，启用后会自动将更改记录到存储库中。它具有许多不同的模式和视图，并且可以配置为帮助管理需求。它可以跟踪模型中发生了什么更改，进行了更改的人员以及更改的时间，并显示了之前和之后的视图。因此，如果更新了需求文本或更改了其状态，则会记录下来。审核功能与“基线”工具重叠，但是与“基线”工具不同，该更改会自动记录，并且会记录所有谨慎的更改。相比之下，“基线”工具将仅将当前模型与“基线”进行比较，而不管进行了多少中间更改。审核将无助于更改的影响，而只会影响已发生的更改。一旦建立了更改，就可以使用诸如关系矩阵之类的工具来确定影响。
版本控制	可以在Enterprise Architect实施版本控制，以管理对任何软件包（包括需求软件包）的更改和修订。实施需求后，将记录对需求的更改，需求分析人员将能够查看以前的版本，并在需要时回滚到这些版本。此工具功能与“审核和基准”之间存在一些重叠。此功能与审核之间的区别在于审核仅记录更改，但不允许您还原到以前的版本。版本控制和基线之间的区别在于，建模者必须有意创建基线，而使用版本控制，更改将自动记录在后台。同样，使用基准线时，不会记录中间的更改，而仅记录当前需求和基准线中捕获的需求之间的差异。
基准线	基准提供了一种强大的机制来管理对需求的更改。可以创建任意数量的基准，并且在更改需求时，可以将这些已更改的需求与基准之一进行比较。通常在项目的重要里程碑上创建基线，例如在利益相关者会议之后或开始开发迭代之前。当发现差异并且这些更改不是故意的或违反项目管理实践时，可以将基线的要求恢复到当前模型。基准不会帮助评估更改的影响，但是一旦确定了更改，就可以使用诸如关系矩阵和元素跟踪之类的工具来确定更改的影响。