Managing requirements across Analysis and Design phases using System Architect & DOORS

of 20 “Rational Support Whitepaper”
Managing requirements across
Analysis and Design phases using
IBM Rational System Architect & IBM Rational
DOORS
Rajesh Avanthi and Praveen Sreenivasan
November 15, 2010

PREFACE .................................................................................................................................................3
INTRODUCTION .................................................................................................................................4
BASIC CONCEPTS OF SYSTEM ARCHITECT-DOORS INTEGRATION...................5
PRE-REQUISITES FOR SETTING UP SYSTEM ARCHITECT-DOORS
INTEGRATION .....................................................................................................................................6
INSTALLATIONS.......................................................................................................................................6
VERIFYING THE INTEGRATION SETUP...................................................................................................6
SYSTEM ARCHITECT-DOORS VERSION COMPATIBILITY CHART .....................................................6
TRANSFERRING ARTIFACTS FROM SYSTEM ARCHITECT TO DOORS................7
SYSTEM ARCHITECT DOORS INTEGRATION WITH DOORS AS THE START
POINT.....................................................................................................................................................14
CONCLUSION .....................................................................................................................................19
REFERENCES.......................................................................................................................................20

Preface
Requirement Analysts and Architecture Analysts tend to work separately from
each other, while the work performed by each role directly impacts the other. In
other words, traceability across the work groups is typically minimal, if existent at
all.
Management of the architecture development process is very difficult if the
organizations can not trace back to the requirement(s) that explain the “why” of
their implementation efforts, regardless of whether it is enterprise architecture,
application architecture, or technology architecture.
Requirements Management becomes difficult when focus is lost on what the
original drivers were for their implementation decisions, like business objectives
and goals
Business requirements are the organization drivers for the project. They include
business rules, standards, regulatory requirements, legal constraints, etcetera.
User requirements capture the information that the end users wants from the
defined system.
System requirements move from the outside-in perspective of the business and
the user requirements move from the inside-out perspective of what a system
would need to do to meet the business and user requirements.
In a general scenario, you would gather some requirements and manage them in
DOORS. Once done, these requirements would be passed on to the modeling
phase. In the modeling phase, you would then check and validate these
requirements with reference to the intended model and see if the business needs
are fulfilled with the requirements provided.
Also, it’s not a surprising scenario that the requirements change during the
project development.
To retain the focus and to handle the changing requirements efficiently, the
requirements management and design tools/products must be integrated well.
Rational offers DOORS to manage requirements and System Architect for
subsequent design. Thus, having a two way integration between System
Architect and DOORS serves to be a very effective aid.

Introduction
This document will be useful for users who would like to manage their
requirements in Rational DOORS and build the model in Rational System
Architect. It also covers the step by step procedure of bringing in the
requirements and building a model with these requirements.
This document describes both starting points of the integration:
• System Architect as the starting point
The document describes how you can transfer the artifacts from Rational
System Architect to DOORS, link these artifacts to some requirements
within DOORS and send it back to Rational System Architect.
• DOORS as the starting point
The current System Architect DOORS integration available with the
product does not allow integration from DOORS as a starting point. This
document describes how this can be overcome using CSV import/export
facility.
The document also outlines how to take all the requirements from an existing
DOORS module into one Rational System Architect definition and vice-versa.
You can be selective and take a section of the existing requirements to various
definitions that the user creates in Rational System Architect. As this would be
very specific to modeling strategy and depends on the scenario, it’s beyond the
scope of the attached document.
If you are not familiar with System Architect-DOORS integration concepts, this
document is the pick for you. It starts with the basic concepts involved in the
integration then moves on to describe the actual integrations. If you are looking
at setting up the integration, the prerequisites are also covered here.

Basic Concepts of the System Architect-DOORS
Integration
System Architect encyclopedia objects that are sent, or to be sent, to DOORS are
associated with one or more DOORS Transfer Unit definition in System Architect.
A DOORS Transfer Unit can be thought of as an envelop holding System Architect
Encyclopedia Objects. The DOORS Transfer Unit is a definition type in System
Architect created by the users.
System Architect encyclopedia objects are sent to one or more Formal Modules
(surrogate modules) in DOORS, where they can be linked with requirements.
All linking is done in DOORS! System Architect reflects the links, but no links can
be done in System Architect.
When you send System Architect artifacts to DOORS, you will need to specify
what DOORS Formal module is to be created to hold this information. As this
module is updated by System Architect, it is also referred to as a the DOORS
surrogate module
There is a one-to-one relationship between a DOORS Transfer Unit definition and
a DOORS surrogate module.

Pre-requisites for setting up System Architect-
DOORS integration
Installations
1. Install Rational System Architect, Rational DOORS client and Server.
2. Install the System Architect-DOORS interface
Verifying the Integration Setup
The DOORS menu options seen in Rational System Architect and System Architect
menu options in DOORS will appear after installing the System Architect-DOORS
interface.
System Architect-DOORS Version Compatibility Chart
Please refer to the compatibility chart below before setting up the System
Architect-DOORS integration.
System
Architect
DOORS Version Compatibility
10.3-10.4.23 7.0, 7.1, 8.0 System Architect version 10.3 and
10.4.23 were tested with DOORS 7.0, 7.1
and 8.0
10.6.11 HF1
and HF2
7.0, 7.1,8.0,8.1 System Architect10.6.11 is even
compatible DOORS 8.1, however it threw
errors when tested with DOORS 8.2
10.7.16 7.0, 7.1, 8.0, 8.1, 8.2 System Architect10.7 was tested to be
compatible with DOORS 8.2 but has
reported issues with 8.3
10.8.4 8.0,8.1,8.2,8.3 System Architect10.8 is compatible only
with DOORS 8.0 and above
11.0.37 8.0,8.1,8.2,8.3 System Architect11.0.37 is compatible
only with DOORS 8.0 and above.
11.1 8.0,8.1,8.2,8.3 and 9.0 System Architect11.1 is compatible only
with DOORS 8.0 and above.
11.2.25 9.0 and above System Architect11.2.25 is compatible
11.3 9.0,9.1 System Architect11.3 is compatible only
11.3.1 9.0, 9.1 and 9.2 System Architect v11.3.1 is compatible
11.4 9.0,9.1,9.2 and 9.3 System Architect11.3 is compatible only

Transferring artifacts from System Architect to
DOORS
The following screenshots describe the general steps that need to be followed in
order to send the existing artifacts from Rational System Architect to the
requirement management tool “DOORS”
1. Create a new encyclopedia (example: DOORS capture)
2. Configure the encyclopedia accordingly.
3. In the new encyclopedia create a definition. In this example the “Use
Case” definition was used
4. Give the definition an appropriate name and associate an existing package
or define a new package (example: define a new “SRS” package)

5. Leave the defaults and Click OK in the Dictionary Object dialog
6. Launch DOORS and open the project where you existing requirements
module exists.
7. Now right-click on the new definition that you created and select DOORS -
> Stage for DOORS…

8. Create a new Transfer Unit in the project where your existing DOORS
requirements are located. By default System Architect will populate the
project that is currently open, shown in Step 6.
9. Select the newly create Transfer Unit and click OK
10. You will now see that the definition in System Architect has a “door” icon
beside it. This represents that it is ready to be sent to DOORS.

11. Highlight the definition in the System Architect explorer and then navigate
to the Tools -> DOORS menu and select the “Send to DOORS…” menu
option.
12. Select the Transfer Unit again and click OK
13. You will notice some activity and dialog box indicator appear. Once
completed you will notice a status log window towards the right hand side
of System Architect letting you know the transfer information.
14. At the same time a “Surrogate” module will have been created in your
project with the same name as the Transfer Unit that you created. In
addition you will see in the Description column “System Architect
Integration Proxy - do not edit” which is also an indicator that this is a
surrogate module.

15. Open the surrogate module in DOORS and you should see an object
created that is associated with System Architect.
16. Right-click on the object that was created (in this example it is called
“SRS.SRSreqs”) and select Link –> Start Link
17. You will notice that the object/requirement in DOORS now changes color
to a darker shade of pink, indicating that it’s been selected as a source
object to be linked.
18. Now open your existing requirements module that you want to transfer
over to System Architect. In this example project, there is a module that
the requirements engineers created called “System requirements”. You will
want to now take these over to System Architect so that you have visibility
of these requirements in System Architect as definitions.

19. In the existing module, highlight the first requirement and with the “shift”
button depressed scroll to the bottom to locate the last requirement and
then click the last requirement with the “shift” key still depressed. This will
select all the requirements in the module and change the color to a shade
of pink
20. Either go to the Link menu option or right-click on one of the selected
“pink” requirements and select “Make Link from Start”
21. In the dialog that appears click the “Selected objects” button
22. In DOORS you should now see that all your system requirements from
your existing DOORS module have been linked to a particular requirement
in the System Architect surrogate module (or Transfer Unit). This is
depicted by “see link” indicators:

23. In System Architect, navigate to the use case definition that we created in
Step 4. Highlight it and go to Tools -> DOORS -> Update from DOORS…
24. Depending on the size of your existing requirements module the
integration will create dictionary objects under the definition that you
selected. Once the update has completed you will see the following:
25. System Architect has now been populated with the requirements
information from your existing requirements module.

System Architect DOORS integration with DOORS as
the start point
Now, lets assume that the we already have the requirements defined in our
requirement management tool (for example: DOORS) and would like to bring this
into System Architect. In order to achieve this, the following describes a way by
which users can have the requirements in DOORS exported to a CSV file and then
have this CSV file imported into System Architect.
NOTE: Currently, System Architect-DOORS integration does not allow a user to
do this in a straight forward way. The method described below may be very
cumbersome if there are many objects/requirements defined in the DOORS
module/CSV files which need to be brought into System Architect. The steps
explained below have been described as an example to demonstrate how a
requirement written in DOORS can be mapped to System Architect via a CSV file.
1. Start by writing a requirement in the DOORS module. In this case, you have
this requirement created in the DOORS module with the name “Object
Definition”. Your objective would be to have this “Object Definition” created in
DOORS and then have this mapped to System Architect and vice-versa.
2. You will now export this requirement out to a CSV file from DOORS.

3. The CSV file exported from DOORS
4. In order for System Architect to understand this requirement on import, you
would need to create this requirement as a definition such that on doing a
CSV import, System Architect would be able to understand in which object the
columns in the CSV file need to be placed. Hence, write a USRPROPS file as
below:
NOTE: In the above screenshot, “Object Definition” would be a user defined
definition type in System Architect. Hence, to be able for System Architect to
create this user defined definition, you need to declare it in the syntax as shown
in the code above. Also, there are 150 user defined definitions that can be
created in System Architect which is denoted by “User 1”, “User 2”, ….. , “User
150”.
If there exists multiple requirements (say 3 requirements) which need to be
imported into System Architect, then the above code would be written as:
For more information on how to write the usrprops.txt code, please refer to the
System Architect online help section.

5. Have this USRPROPS file imported into the System Architect encyclopedia so
that the meta-model understands the new object. In this case, the new object
is the “Object Definition” which in turn is a requirement in the DOORS module.
6. Once the USRPROPS file has been imported, reopen the encyclopedia in
System Architect. Now go to the menu Dictionary -> Import Definitions.
NOTE: In the Path below, specify the path to the CSV file which was exported
from DOORS. In the definitions list, select the definition which was newly
created which will in turn be mapped as a requirement in DOORS.

Click on “Ok” to Import the CSV file into System Architect.
Notice that a new entry was added into System Architect.
7. Expand the definition node to find the newly created “Object Definition”.
8. Now, map this definition to a new DOORS module.
9. Create a new Transfer Unit

10. Select the New Transfer Unit name to complete the staging.
11. Notice that icon is seen in System Architect which shows the object to be
staged to DOORS.
12. Now send this Object to the DOORS module.
13. Select the new transfer unit name created above to complete the Send to
DOORS operation.
13. Observe that this object was successfully transferred to the DOORS module.

Conclusion
The System Architect DOORS integration helps users create abstract views in
System Architect based on the user requirements in DOORS. Having this
integration will enable users to synchronize the model with the ever changing
requirements. This document can be used as a reference for users who would like
to map their requirements captured in DOORS to a modeling tool Rational System
Architect. Also, there would be an information flow between DOORS to System
Architect and vice-versa.
Managing changes to the requirements and mapping it to the equivalent model
sometimes becomes very challenging if there are too many objects or artifacts
present within the requirements module. As a result, for effective results and to
manage dynamic requirements, System Architect DOORS integration would be
the effective solution.
Using the document provided, users can have the requirements in DOORS
mapped to the System Architect project encyclopedia and vice versa. As a
summary, this document can prove effective as a start point for new users who
are in the process of exploring this wonderful integration and its benefits.

References
The following were used in references or as other sources of information:
• http://publib.boulder.ibm.com/infocenter/rsdp/v1r0m0/index.jsp?topic=/com.ibm.help.downl
oad.sa.doc/helpindex_sa.html
• http://publib.boulder.ibm.com/infocenter/rsdp/v1r0m0/index.jsp?topic=/com.ibm.help.downl
oad.sa.doc/helpindex_sa.html

Managing requirements across Analysis and Design phases using System Architect & DOORS

More Related Content

Similar to Managing requirements across Analysis and Design phases using System Architect & DOORS (20)

More from Bill Duncan (20)

Recently uploaded (20)

Managing requirements across Analysis and Design phases using System Architect & DOORS