Requirements synchronization (Integration for IBM Rational DOORS)
This topic documents the synchronization of SysML Requirements with a DOORS surrogate module through a requirements mapping, not model elements with a DOORS surrogate module through a surrogate mapping. For information about model element synchronization, see
Model elements synchronization (Integration for IBM Rational DOORS).
Requirements synchronization is a bidirectional synchronization that can synchronize the following Modeler item and relationship types with a DOORS surrogate module:
• SysML Requirement items and their extensions - map to DOORS requirements that have their 'SysML Model Element Type' attribute set to Requirement.
Extension specific tags will not be available for Property Mappings.
• Actor, Comment, Constraint, Package, Problem, Rationale and Use Case items - map to DOORS formal objects that have their 'SysML Model Element Type' attribute set to Actor, Comment, Constraint, Package, Problem, Rationale or Use Case as appropriate.
These Modeler items are exported only if their owning item is exported as well. For example, Class owned Use Cases are not exported.
• Requirement Diagrams and Use Case Diagrams - map to DOORS formal objects that have their 'SysML Model Element Type' attribute set to requirementDiagram or Use Case Diagram as appropriate.
These Modeler diagrams are exported only if their owning item is exported as well. For example, Class owned Use Case Diagrams are not exported.
• SysML Allocate, Derive, Refine, Satisfy, Trace and Verify traceability relationships - map to DOORS links that have their ART Link Type attribute set to allocatedTo, derivedFrom, refines, satisfies, tracesTo or verifies as appropriate.
To perform a requirements synchronization rather than a model elements synchronization, on the Common Mapping Options page of Integration for IBM Rational DOORS, ensure that you select the Requirement option.
The Requirement option is available only if the SysML Profile (Full Profile or Requirements Only) has been added to the Modeler model.
When you first synchronize a Modeler package (or the Model) with a surrogate module, Integration for IBM Rational DOORS prompts you for the following information.
• Which Modeler Package (or the Model) is the root item for the synchronization. All child Requirements, Actors, Comments, Constraints, Problems, Rationales, Requirement Diagrams, Use Cases and Use Case Diagrams of the root item (and its child Packages) are included in the synchronization.
Each Package in a Modeler model can be involved in only one Integration for IBM Rational DOORS Mapping.
• Whether to export images of Requirement Diagrams and Use Case Diagrams.
• Which DOORS surrogate module and root object to use for the synchronization, and whether the surrogate module is saved, not saved, or saved and closed after the synchronization is complete:
◦ Automatically saving surrogate modules ensures that the synchronization and saving processes are completed in one operation. This saves time when synchronizing large models over night.
◦ Manually saving surrogate modules allows you to review the change bars in the surrogate modules before saving any changes.
◦ You can select a baseline of the selected module for DOORS -> Modeler synchronizations, but restrictions apply.
Tell me more....
In addition, you can optionally select a Link module to use. If you do not specify a Link module to use, Integration for IBM Rational DOORS creates one if necessary named '<formal module name> Links'.
Note that Integration for IBM Rational DOORS checks that it can lock the DOORS module for exclusive edit before starting a synchronization.
• Whether to use specific baselines of modules for target links that are created during the synchronization.
• Whether the synchronization is from Modeler to DOORS only, DOORS to Modeler only, or bidirectional.
• Which DOORS attribute types are included in the synchronization and how those attribute types map to Modeler property types.
• Which SysML traceability relationships are included in the synchronization and whether they are imported, exported or both.
• How deleted Requirements are dealt with:
◦ If deleted from the Modeler model, Integration for IBM Rational DOORS can delete the associated requirements in the DOORS surrogate module, or mark the requirements as deleted (ART Model Element Deleted attribute set to True).
◦ Note that before deleting a Requirement in DOORS, Integration for IBM Rational DOORS deletes its incoming and outgoing links that are in the scope of the mappings that are being synchronized. If after deleting these links there are no incoming or outgoing links, Integration for IBM Rational DOORS deletes the Requirement form DOORS; if after deleting these links there are incoming or outgoing links, Integration for IBM Rational DOORS does not delete the Requirement in DOORS and instead marks it as deleted.
◦ If deleted from the DOORS surrogate modules, Integration for IBM Rational DOORS can delete the associated items in the Modeler model, or mark in the associated items in the Modeler model as deleted (isDeletedInRequirementTool tag definition set to True).
• An optionally referenced DXL file that defines additional filtering and access control for a synchronization.
You can save the settings you make to an Integration for IBM Rational DOORS Mapping, and then in future use that Mapping to repeat the synchronization using the same settings.
Integration for IBM Rational DOORS creates commands for you to navigate between Modeler SysML requirements and their associated DOORS requirements:
• From Modeler, you can right-click a SysML Requirement, point to Tools, point to DOORS, and then click View. When using the View command, the module is opened read-only.
• From DOORS, you can select a requirement, and then on the PTC Integrity Modeler menu, click the View in Modeler.
• If Integration for IBM Rational DOORS creates a Modeler item from a DOORS object that does not have a Heading value, the name of the item created in Modeler is derived as follows:
• After synchronizing with a surrogate module, do not change the name of that surrogate module.
• When synchronizing extensions of Requirements or EnterpriseGoals, the following applies:
◦ When synchronizing Requirements/EnterpriseGoals, any extensions of those types (heavy or light) are also synchronized automatically.
◦ Property Mappings for extensions of Requirements/EnterpriseGoals are the same as the type they extend (i.e. DesignConstraints uses the PropertyMappings from Requirement).
◦ When synchronizing new objects from DOORS into Modeler, they will always be created as Requirements or EnterpriseGoals only.
◦ When synchronizing previously synchronized objects from DOORS into Modeler, they will be created as the original extension of Requirement/EnterpriseGoal (i.e. if you synchronized a DesignConstraint into DOORS, deleted the DesignConstraint from Modeler and then synchronized the object back into Modeler, it will be created as a DesignConstraint).
◦ If the extension of Requirement/EnterpriseGoal is not available, an error is logged but the synchronization will continue.
◦ Non-lightweight extensions of Requirement/EnterpriseGoals are not supported (i.e. a subtype of Requirement that is not detected as a lightweight extension will be treated as a class and ignored).
