Requirement mapping options page (Integration for IBM Rational DOORS)

This page of Integration for IBM Rational DOORS allows you to specify how Requirements are synchronized. You can synchronize Requirements only when the SysML Profile (Full Profile or Requirements Only) is present in the Modeler Model.

In addition to the common navigation buttons, the following controls appear on this page of Integration for IBM Rational DOORS.

◦ Integration for IBM Rational DOORS updates the requirements in DOORS from the SysML Requirements relationships in Modeler.

◦ Integration for IBM Rational DOORS updates the SysML Requirements in Modeler from the Requirements in DOORS.

Use this option when you want to be able to change Requirements in either the Modeler model or the DOORS surrogate module, and then have those Requirements synchronized so that they match in Modeler and DOORS.

• DOORS ->Modeler option - specifies that the synchronization process creates or updates Requirements in the Modeler model from the Requirements in a DOORS module.

Use this option when you are maintaining your Requirements only in the DOORS surrogate module, or when you want to import your DOORS Requirements to a Modeler model the first time.

• Modeler -> DOORS option - specifies that the synchronization process updates Requirements in DOORS from the SysML Requirements in Modeler.

Use this option when you are maintaining your SysML Requirements only in the Modeler model, or when you want to export your Modeler Requirements to a DOORS surrogate module the first time.

• Keep Unsynchronized Items check box - for a DOORS -> Modeler synchronization, specifies that items in Modeler that have not been synchronized will not be deleted by the synchronization. For a Modeler -> DOORS synchronization, specifies that objects in DOORS that have not been synchronized will not be deleted by the synchronization. This check box is not available for Modeler <-> DOORS synchronizations.

• Modeler <-> DOORS option - specifies that traceability relationships created or changed in Modeler are exported to DOORS, and traceability links created or changed in DOORS are imported to Modeler.

Use this option when you want to be able to change traceability relationships in either the Modeler model or the DOORS module, and then have those traceability relationships synchronized so that they match in Modeler and DOORS.

• DOORS ->Modeler option - specifies that traceability links created or changed in DOORS are imported to Modeler.

Use this option when you are maintaining your traceability relationships only in the DOORS surrogate module, or when you want to import your DOORS traceability relationships to a Modeler model the first time.

• Modeler -> DOORS option - specifies that traceability relationships created or changed in Modeler are exported to DOORS.

Use this option when you are maintaining your traceability relationships only in the Modeler model, or when you want to export your traceability relationships to a DOORS surrogate module the first time.

A heading object is an object that has a Heading value, or an object that does not have a Heading value or Object Text value.

• As Packages option - specifies that when importing a heading object from DOORS the first time, Integration for IBM Rational DOORS creates the heading object as a Package in the Modeler model.

• When an object does not have a Heading value, but does have an Object Text value, that object is imported as a Requirement.

• Requirement owned heading objects are always imported as Requirements in the Modeler model, even when this option is selected.

• As Requirements option - specifies that when importing a heading object from DOORS the first time, Integration for IBM Rational DOORS creates the heading object as a Requirement in the Modeler model.

• Delete Target Object option - specifies that when importing a Requirement that has been deleted from the DOORS surrogate module, Integration for IBM Rational DOORS deletes the associated Requirement from the Modeler model. Likewise, when exporting a Requirement that has been deleted from the Modeler model, Integration for IBM Rational DOORS deletes the associated Requirement from the DOORS surrogate module.

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.

Undeleting a surrogate object may result in more than one surrogate object being mapped to the same Modeler item. If Integration for IBM Rational DOORS detects this problem it abandons the synchronization and records which surrogate objects are causing the problem in the log. To resolve the problem you must change the module so that only one surrogate object is mapped to the Modeler item.

• Mark Target Object as Deleted From Source option - specifies that when importing a Requirement that has been deleted from the DOORS surrogate module, Integration for IBM Rational DOORS marks the associated Requirement in the Modeler model as deleted. Likewise, when exporting a Requirement that has been deleted from the Modeler model, Integration for IBM Rational DOORS marks the associated Requirement in the DOORS surrogate module as deleted.

◦ In a DOORS surrogate module, Integration for IBM Rational DOORS marks a Requirement as deleted by setting the value of its ART Model Element Deleted attribute to True.

◦ In a Modeler model, Integration for IBM Rational DOORS marks a Requirement as deleted by setting the value of its isDeletedInRequirementTool tag definition (applied by the «requirement» stereotype) to True.