管理不断变化需求

在项目的规范和解决方案阶段，需求不可避免地会发生变化，并且大多数需求管理过程都有某种类型的机制来接受这些变化。通常，会为解决方案团队指定和整理一组要求来实施；任何后续更改都指定为更改请求。无论使用的流程有多严格，都会发生需要与更改请求一起管理的无意更改。 Enterprise Architect是一个复杂的需求管理平台，具有一系列工具来协助需求经理。更改请求可以在维护窗口中进行管理，它允许记录和描述所请求的更改，以及请求的人以及请求的时间done 以及完成更改的人。可以使用许多特征发现和分析意外更改，包括审计、基线版本和版本控制；这些工具有一些重叠的特征，可以单独使用，也可以一起使用。内置的安全系统还将通过允许建模者有意锁定模型中的包和元素来帮助防止对模型的无意更改。

管理不断变化的需求的机制

机制	描述
元素改变任务和努力项	对需求的修改可能会在不经意间发生，但更常见的是有意更改以响应各种因素，例如利益相关者修改他们的需求、业务变化或对问题了解甚少。可以使用许多工具来获取无意的更改，但是可以使用更改项来分配故意的更改，这可以针对每个元素进行记录。一旦分析了变更的影响，就可以创建任务来指定实施变更需要做什么，工作量可以使用需求工作量项来分配工作量。
审计	审计是一个内置工具，启用后会自动记录对存储库的更改。它有许多不同的模式和视图，并且可以配置以协助管理需求。它可以跟踪模型中的更改、更改的人员和更改的时间，显示之前和之后的视图。因此，如果它的状态将被记录为与审计功能重叠的基线需求，但与基线更新或记录工具不同的是，每次更改都被记录在谨慎的变化中。相比之下，没有基线审计将不会对当前模型的基线进行比较，只是比较已发生的变化。一旦确定了更改，就可以使用关系矩阵等工具来确定影响。
版本控制	版本控制可以在Enterprise Architect中实施，以管理对任何包的更改和修订，包括需求包。一旦实施对需求的更改将被记录下来，需求分析师将能够查看以前的版本并在需要时回滚到这些版本。这个工具特征和审计和使用之间有一些基线。该功能与审计的区别在于，审计只记录变更，而不允许您恢复到以前的版本。版本控制和基线之间的区别是建模者必须有意创建基线，而版本控制在后台自动记录更改基线是当前记录的间隔变化与记录的要求之间的基线。
基线	用于管理需求基线的多功能机制。任何数量的利益相关者基线都可以被更改为项目的一个重要更改的要求，而这些基线的基线通常可以在一个开发迭代之后或在开始之前在一个开发迭代中创建。当发现差异并且不符合预期或违反从当前项目基线到当前项目的要求时，这些变更一旦恢复，这些基线将模型于评估变更的影响。关系矩阵和元素跟踪可用于确定更改的影响。