working with ibm rational doors 9 requirements -凯发k8网页登录

setup for ibm rational doors

configure the requirements management interface for interaction with ibm rational doors by following the instructions in .

overview of workflow with 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 requirements toolbox™ while maintaining traceability. additionally:

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 .

import a doors module

you can import a doors requirements module or a subset of requirements from a module by using a filter. for more information, see .

to navigate between the imported requirements references and doors:

if your doors module has links between doors items, you 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 .

before you import your doors module, be sure that you've added all desired requirements attributes. you cannot import additional attributes to requirements toolbox after the original import.

link to your model

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 and select a requirement, links are displayed in the property inspector under links. you can:

you can link imported requirements to entities such as test cases, matlab code, data dictionaries, and other requirements. for more information, see link test cases to requirements and working with ibm rational doors 9 requirements.

update requirements to reflect doors changes

if the source requirements in doors change, you can update the imported references in requirements toolbox.

follow the steps in .

if you have added attributes to your doors module since the original import to requirements toolbox, the new attributes are not imported. if you want to import attributes from your doors module, be sure to add them before importing to a new requirement set in requirements toolbox.

synchronizing links and navigation from doors

you can bring traceability data into doors for easier navigation from original requirements to design and tests. to synchronize your requirements toolbox links into doors:

requirements toolbox analyzes outgoing links in the link set and checks for incoming links from applications that support backlinks insertion, including doors.

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 for general information about managing links from external documents.

embedded http connector

navigation from external applications to matlab/simulink relies on the built-in http server in matlab. requirements toolbox 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:

use the 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:

tracing to doors module baseline

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 requirements toolbox 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, requirements toolbox 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.

repair links to previously imported references after module prefix changed in doors

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 the requirements toolbox ™ requirement set. also, when updates received from doors do not include some custom ids that are present in the requirement set, the corresponding items are assumed to be deleted in doors, and will be cleaned-up from the requirement set. with this comes the following danger: if doors user has modified the module prefix in doors before performing the update for the requirement set, none of the existing custom ids will match, because doors module prefix is a part of id, and all ids known on requirements toolbox 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:

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 link.description values).

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: