Managing Changing Requirements

It is inevitable that requirements will change during the specification and solution phases of a project, and most requirements management processes have some type of mechanisms for embracing these changes. Typically, a set of requirements will have been specified and groomed for the solution teams to implement; any subsequent changes are specified as Change Requests. Regardless of the rigor of the process being used, inadvertent changes will occur that need to be managed along with the Change Requests. Enterprise Architect is a sophisticated requirements management platform, with a range of tools to assist the requirements manager. Change Requests can be managed in the Element Maintenance window, which allows the requested change to be recorded and described, along with when and who requested it and who completed the change and when it was done. Inadvertent changes can be discovered and analyzed using a number of tool features, including Auditing, Baselines and Version Control; these tools have some overlapping features and can be used in isolation or together. The built-in Security system will also assist in preventing inadvertent changes to models, by allowing modelers to intentionally lock Packages and elements in the model.

Mechanisms for managing changing requirements

Mechanism	Description
Element change task and effort items	Changes to requirements can happen inadvertently but it is more common for there to be an intentional change in response to a wide variety of factors such as Stakeholders revising their needs, the business changing or a problem being poorly understood. Inadvertent changes can be picked up using a number of tools but deliberate changes can be assigned using the Change item, which can be recorded against each element. Once the impact of the change has been analyzed Tasks can be created to specify what needs to be done to implement the change and Effort can be assigned using the Requirements Effort item.
Auditing	Auditing is a built-in tool that, when enabled, automatically records changes to the repository. It has a number of different modes and views, and can be configured to assist in the management of Requirements. It can track what was changed in the model, who made the change and when it was made, showing the before and after views. So if the text of a Requirement was updated or its status was changed, this would be recorded. Auditing functionality overlaps with the Baseline tool but unlike the Baseline tool the changes are being recorded automatically and every discreet change is recorded. In contrast, the Baseline tool will only compare the current model to a Baseline regardless of how many intervening changes had been made. Auditing will not assist with the impact of the changes but just what changes have occurred. Once the changes have been established, tools such as the Relationship Matrix can be used to determine the impact.
Version Control	Version Control can be implemented in Enterprise Architect to manage changes and revisions to any Package including Requirements Packages. Once implemented changes to Requirements will be recorded and a requirements analyst will be able to view previous version and roll back to these versions if required. There is some overlap between this tool feature and Auditing and Baselines. The difference between this facility and Auditing is that Auditing simply records the changes but does not allow you to revert to a previous version. The difference between Version Control and Baselines is that a modeler must intentionally create a baseline whereas with Version Control the changes are being recorded automatically in the background. Also with Baselines the intervening changes are not recorded, just the difference between the current requirement and the one captured in the Baseline.
Baselines	Baselines provide a powerful mechanism for managing changes to Requirements. Any number of baselines can be created and when requirement are changed these requirements can be compared to one of the baselines. Baselines are typically created at important milestones in a project such as after a stakeholder meeting or before a development iteration is commenced. When differences are found and these changes were not intended or contravene project management practice the requirements from the baseline can be restored to the current model. Baselines will not help with assessing the impact of a change but once a change has been identified tools such as the Relationship Matrix and element traces can be used to determine the impact of a change.