Models of the Enterprise Architecture are built to satisfy requirements, and at the same time, requirements may be elucidated while you model various parts of the Enterprise Architecture. The System Architect-DOORS interface enables you to use the market leading Enterprise Architecture tool, System Architect, and the market-leading requirements management tool, DOORS, together to build and maintain an enterprise architecture and requirements for your organization.
The SA-Doors link enables you to send System Architect model artifacts to one or more ‘surrogate’ modules in DOORS, where they can be linked with requirements.
Overview of the SA-DOORS interface functionality
You can port System Architect modeling artifacts into DOORS so that they are viewable and so that traceability links may be created between them and DOORS objects. All linking of System Architect model artifacts to DOORS objects is done in DOORS, not System Architect. You can port instances of a symbol, a definition, or a diagram into DOORS. This includes line symbols.
Once linked in DOORS, you may "update" System Architect and view the requirements that are linked with model artifacts in a System Architect encyclopedia – diagrams, symbols, and definitions in the System Architect Explorer and on the diagram workspace are annotated with DOORS triangular icons denoting that the model artifact has an outgoing or an incoming link to a requirement. You may also view a skeleton of the DOORS object in System Architect, and use its reporting system to view relationships between DOORS objects and model artifacts, using three reporting relationships – "links to", "is to be sent to" and "has been sent to".
Workflows
There are numerous workflows that can be enacted using the SA-DOORS Interface. Some representative examples are presented below.
Workflow #1
1 Requirements Engineers, in DOORS, may develop and manage requirements, and send a list of requirements to business analysts in System Architect, by, for example, exporting a CSV file from DOORS and importing that CSV file into System Architect’s repository. System Architect’s metamodel would need to be extended first to add definitions or properties that would contain this information.
2 Business Analysts in System Architect specify that model artifacts (imported into the repository from DOORS) meet a requirement or requirements (or, in general, any DOORS object imported).
3 Business Analysts, using the SA-DOORS link, send model artifacts (containing the information on what DOORS object the artifact satisfies) over to DOORS.
4 Requirements Engineers, in DOORS, create traceability links between System Architect model artifacts and DOORS objects.
5 At certain stages during the project, Business Analysts in System Architect use the SA-DOORS interface to update information in System Architect from DOORS. Model artifacts that have been linked to DOORS objects are annotated appropriately in System Architect, and a skeleton of the actual DOORS objects are brought into System Architect.
6 System Architect users may view the DOORS requirements (or objects) linked with model artifacts in System Architect, use its reporting system to publish reports detailing such information, use the Explorer diagram to investigate ‘what if’ relationships, and publish all information to websites using System Architect’s publishing capabilities.
Workflow Example #2
A corollary to Workflow #1 is as follows:
1 Business Analysts, working in System Architect, elucidate new requirements from the business models that they are building. In System Architect, users may create Requirements definitions, and, using its customizable repository, tailor its metamodel to introduce new definition types, such as Functional Requirement, System Requirement, Technology Requirement, and so forth. These new requirements can be ported to DOORS to a module separate from modules that model artifacts are sent to – the SA-DOORS interface enables you to send System Architect artifacts to multiple modules in DOORS.
2 In DOORS, Requirements Engineers link the new requirements to model artifacts.
3 System Architect users perform an update from DOORS, and view model artifacts linked to DOORS requirements (or objects). As with Workflow Example #1, users may use System Architect’s reporting system to publish reports detailing such information, use the Explorer diagram to investigate ‘what if’ relationships, and publish all information to websites using System Architect’s publishing capabilities.
Workflow Example #3
Workflow Example #3 is a corollary to Workflows #1 and #2.
1 In System Architect, Business Analysts and other users such as Enterprise Architects, Systems Engineers, Database Designers, and so forth build models to represent the systems, applications, and databases that support the business processes. These system, application, and data models are also sent to DOORS using the SA-DOORS interface.
2 Meanwhile, Requirements Engineers in DOORS derive Functional Requirements from high-level Business Requirements, and develop and maintain System Requirements, Technology Requirements, and so forth in DOORS. The Requirements Engineers link these requirements with applicable System Architect model artifacts ported in through the interface.
3 System Architect users perform an update from DOORS, and view and report on requirements linked with model artifacts, as described in the previous workflows.
