| Prev | Next |
Requirements as First Class Citizens
Enterprise Architect provides a wide range of facilities that can be used for the development, visualization, management and documentation of Requirements as first class elements. People reading general SysML textbooks will often come away with the idea that Requirements are expressed on diagrams, but Enterprise Architect provides a wide range of other ways to visualize Requirements that will assist the engineer when working with them as text based elements, including being able to visualize them in a hierarchy in the Browser window.
Requirements can be created as part of a specification or tender, or form part of a contractual document, in which case they can be easily imported into Enterprise Architect. However, it is more common for them to be developed as part of an elicitation effort typically conducted with workshops and reviews. Enterprise Architect has a number of features that can be used to record the proceeds of these meetings, such as Mind Map diagrams. Once the workshops have been completed, the ideas recorded in these meetings can be converted to Requirements or mapped to the meeting elements in a way that allows them to be developed collaboratively.
The Requirements often form part of a contractual relationship between organizations, or an agreement between different sections of the same organization, and as such need to be maintained and managed with rigor. Enterprise Architect provides a wide range of facilities to assist with this rigor, including Baselines, Audit tools, Version Control and more.
Requirements Auditing
Auditing can be turned on in a model and can track the details of a requirement change, including when it was changed, who changed it and the delta - before and after the change. Auditing can be used to track what was changed in a model, who changed it and when. There are a number of modes and a repository administrator can use the settings to specify what is recorded in the audit. While a Baseline can be used to show the difference between a model and a snapshot at a point in time, the Auditing tool records each individual change; it cannot, however, be used to revert to a previous state (the Baseline tool would be used if that was required).
This is a particularly useful feature in Systems Engineering, where there are regulatory or compliance aspects to a process or when faults have to be traced back to their design or requirement specification. Auditing would typically be set up and administered by a librarian or administration function within the team. Auditing can be enabled, set up and viewed using the ribbon option 'Settings > Model > Auditing'.
Auditing is by default disabled and must be enabled (turned on) before the system will start to keep an audit log. This, along with a range of other options, is available from the Audit Settings window.
For more information see the Auditing Help topic.
Requirements Baselines
Baselines are user initiated snapshots of a Package in a model. The Baseline effectively makes a copy of a branch of the Package hierarchy and its contents. At a subsequent point in time, the model can be compared with the Baseline and, if the model has changed, these changes will be presented in a visualization tool, allowing a user to view each part of the model that has changed, including the content that exists in the Baseline and the model. It is then possible to inject the contents from the Baseline into the model at the level of a discrete change.
Baselines provide a convenient way for Systems Engineering teams to ensure that models are evolving the right way, and when a model direction needs to be reverted to a previous version they can be used to reinstate atomic parts of the model. Baselines can be set up and viewed by pressing or from the ribbon location:
Ribbon: Design > Package > Manage > Manage Baselines
As discussed previously, Baselines are user initiated and are stored inside the repository, so if the repository is copied the Baselines would be copied as well. It is quite common for most users to be given permission to create Baselines, but the ability to restore from a Baseline is typically reserved for a librarian or administration role. For more information see the Baseline Tool Help topic.
Version Control
Version Control allows Packages within a model to be versioned. To commence work on a part of the model, a user is required to check out a Package (including its sub-Packages) and then to work on a local copy. When the work is complete or at any point a user can check in the Package allowing the changes to be seen by other model users.
Version Control provides a sophisticated and robust way of working with models, and in contrast to Baselines does not require a user to initiate a version other than to check-out the Package. The system is automatically creating a version in the background as the work is done and changes are being made. Version Control can be set up and viewed from these ribbon options.
Settings > Version Control > Project-VC, Package-VC
Version Control provides an effective mechanism for managing model content and allows a user or a team to keep fine-grained control over the way a Package and its content change over time. For more information see the Version Control of Model Data Help topic.