How to import, link, and update requirements from IBM Rational DOORS 9. Working with DOORS 9 is supported on Microsoft Windows®.
Configure the requirements management interface for interaction with IBM Rational DOORS by following the instructions in Configure RMI for Interaction with Microsoft Office and IBM Rational DOORS.
You can import requirements from DOORS into the Simulink environment, then establish traceability from your model to DOORS requirements through the imported references. Traceability is bi-directional. If DOORS requirements change, you can update the references in Simulink Requirements while maintaining traceability. Additionally:
You can establish traceability from MATLAB and Simulink to DOORS without modifying DOORS Formal or Link modules.
You can link between design, tests, and requirements without leaving the Simulink Editor.
You can establish traceability from low-level requirements in Simulink to high-level requirements in DOORS.
You can identify gaps in implementation and verification using metrics in Simulink Requirements.
Change detection and cross-domain traceability can be used to conduct change impact analysis.
If you have existing Simulink artifacts that are linked to DOORS with previous versions of the Requirements Management Interface, update your existing links. See the Update Model Link Destinations section in Migrating Requirements Management Interface Data to Simulink® Requirements™.
To import a DOORS module into Simulink Requirements:
Log in to DOORS and open the module to import.
In the Requirements Editor, select File > Import.
Select a DOORS module as the source document.
If your DOORS module includes pictures or tables, enable the Include graphics and layout option.
Click Import to complete the import process.
Check the results in Requirements Editor. The references should preserve the DOORS IDs and the requirements hierarchy.
To navigate between the imported requirements references and DOORS:
Select an imported requirements reference and click Show in document to navigate to DOORS.
Select MATLAB > Select Item in DOORS to navigate to the imported requirements reference.
If your DOORS module has links between DOORS items, to may use additional commands to bring links into the requirements set. Also, if your DOORS module has links to Simulink models, use link synchronization to bring the links into the requirements set. See the section Copying Link Information from DOORS to Simulink in Managing Requirements for Fault-Tolerant Fuel Control System (IBM Rational DOORS).
You can link imported requirements to Simulink blocks by dragging items from the Requirements Browser to items in your model. Open the Requirements Perspective in the model window by clicking the icon at the lower right of the window and selecting the Requirements tile.
When you open the Requirements Perspective, the Links panel in the bottom right displays related links. You can:
Navigate to linked artifacts outside the current model.
Delete links by pointing to the link and clicking the red cross.
Check and modify link properties by switching to the Links View.
You can link imported requirements to entities such as test cases, MATLAB code, data dictionaries, and other requirements. For more information, see Link to Test Cases from Requirements and Working with IBM Rational DOORS 9 Requirements.
If the source requirements in DOORS change, you can update the imported references in Simulink Requirements.
Select the top-level node that corresponds to updated DOORS module.
Click the Update button.
Follow the steps in Update Imported Requirements.
You can bring traceability data into DOORS for easier navigation from original requirements to design and tests. To synchronize your Simulink Requirements links into DOORS:
Switch into the Links View.
Locate and right-click the Link Set that has new links.
Select Update Backlinks shortcut at the bottom of context menu.
Simulink Requirements analyzes outgoing links in the Link Set and checks for incoming links from applications that support backlinks insertion, including DOORS.
Missing links are added to the external document. In DOORS, links appear as outgoing External Links and correspond to Simulink entities, such as a blocks or test cases in Simulink Test.
Linked documents are checked for stale links, where there is no matching link from Simulink to this external requirement.
You can delete unmatched links from the DOORS module by confirming the prompt.
A short report dialog is displayed on successful completion of Update Backlinks action:
After performing Update Backlinks step, review your linked requirements in DOORS module - you should see links to MATLAB or Simulink. You may see multiple links if same requirement is linked to multiple elements. Click the link in DOORS to navigate:
See Manage Navigation Backlinks in External Requirements Documents for general information about managing links from external documents.
Navigation from external applications to MATLAB/Simulink relies on the built-in HTTP server in MATLAB. Simulink Requirements will fail to insert a link in external application unless the MATLAB's built-in HTTP server is active on the correct port number.
If you see the following error popup when performing Update Backlinks action, this indicates that HTTP server is not in the correct state:
connector.port command-line API to check the status of HTTP server, and use
rmi('httpLink') API to activate the server if
connector.port command returns 0.
Update Backlinks feature requires that HTTP server is activated for port 31415. If
connector.port command returns a higher number, this indicates that port number 31415 was taken by some other process when this instance of MATLAB was started. You will need to:
Save your work and quit all instances of MATLAB.
Restart only one instance of MATLAB.
Check HTTP server status by running
If you get 0, rerun
connector.port command - you should now see 31415 port activated.
Re-open your MBD artifacts and retry Update Backlinks procedure.
At some point after linking MBD artifacts with requirements in DOORS, you may have created Baselines for linked modules. By default, your links stored in Simulink Requirements will still navigate to the current version of the linked modules. If you want to lock your design version to a baseline version of requirements, Simulink Requirements allows you to specify a Baseline number for each DOORS module you are linking with. You can choose to configure the preferred DOORS baseline numbers for all linked artifacts in your current MATLAB session, or you can specify a different DOORS baseline number, for specified MBD artifacts.
slreq.cmConfigureVersion is the command-line API that you use to specify your preferred DOORS baseline numbers.
slreq.cmGetVersion command to check the configured DOORS baseline number for a given DOORS module.
If you later created next version baselines for linked modules, and if you want navigation of previously stored links to target the later baseline, you rerun
slreq.cmConfigureVersion command to specify the updated baseline number.
Per-artifact values are stored with the corresponding Link Sets and will affect navigation for all users of same Link Set files.
Global (session-scope) assignments are stored in user preferences. Your next MATLAB session on the same installation remembers your previously configured baseline numbers. If you shared your work with other users, each user will need to re-enter the same preferred baseline numbers. If needed, you can include the required configuration commands in your MATLAB startup script or in your Simulink Project startup script.
When requirements change in DOORS, you perform the Update action to bring updated DOORS contents into previously imported Requirements Set. The process relies on matching DOORS object IDs with Custom IDs of previously imported items to determine which existing references need update, and which DOORS objects are new and require creation of new references in Simulink Requirements Set. Also, when updates received from DOORS do not include some Custom IDs that are present in Simulink Requirement Set, the corresponding items are assumed to be deleted in DOORS, and will be cleaned-up from Simulink Requirements Set. With this comes the following danger: if DOORS user has modified the module prefix in DOORS before performing the Update for Simulink Requirements Set, none of the existing Custom IDs will match, because DOORS module prefix is a part of ID, and all IDs known on Simulink Requirements side are based on the old prefix. Update process will remove all existing references and will then create new ones with Custom IDs that correspond to updated prefix in DOORS. If previously imported references where linked with design artifacts on Simulink side, all the links will be broken, because the originally linked references no longer exist. For example, if the original module prefix in DOORS was "KKK" and this was changed to "QQQ", you will see QQQ-based IDs in the Requirements Browser after performing Update,
... but the links will still point to KKK-based items as destinations. You will see orange warning triangles on all the links that got broken:
You can repair broken links by performing the following steps:
identify the original DOORS IDs in LinkSet data,
construct the expected updated DOORS IDs based on your knowledge of the original and current module prefix,
rely on reconstructed IDs to locate the matching Requirement Set entry for each broken link destination,
update each broken link to connect with the updated reference in Requirement set.
If an older copy of Requirement Set file is still available, you can collect the SID->CustomID mapping from it. But if you only have the updated version of the Requirement Set, and the links are already broken, you may be able to pull old DOORS IDs from the stored link labels (from
The following script demonstrates accomplishing this task for the case when all stored
link.Description labels start with the DOORS ID. In our example the labels look like "KKK123: DOORS Object Text or Heading", and we assume that DOORS item with old ID "KKK123" now has DOORS ID "QQQ123".
Run this script with four input arguments: LinkSet name, ReqSet name, old prefix, new prefix:
Now all the links are resolved and labels are updated correctly: