Requirements traceability in analysis models in Rational Software Architect Version 7.5

Trace requirements from use cases in an analysis modeling process

Learn how to create a platform-independent analysis model and realize use cases with IBM® Rational® Software Architect Version 7.5. Using the process outlined in this article can help you create Model-Driven Architecture and maintain traceability of requirements from the use case model to the Rational Unified Process (RUP) analysis model.


Rajeev Shrivastava (, Certified Senior IT Architect, EMC

author photoRajeev Shrivastava is a Certified Senior IT Architect working in IBM Global Business Services.

03 August 2010

Also available in Chinese

Often, software architects face a challenge in realizing use case and creating logical structure of the system. The IBM Rational Unified Process-based (RUP-based) analysis model will not only help in understanding the requirements but also jumpstart your design for an overall solution. This article covers the following topics:

  • The RUP-based analysis process to model the dynamic and static behavior of the system through IBM® Rational® Software Architect 7.5 (realization through a sequence diagram and analysis classes and their relationships, respectively).
  • The significance of the Analysis model and how it fits into Model-Driven Architecture.
  • The technique of how to tracing requirements from a Use Case model to an Analysis model by using Rational Software Architect 7.5.

Model-Driven Architecture

The Model-Driven Architecture (MDA) approach defines system functionality by using a Platform-Independent Model with an appropriate domain-specific language. In this approach, models drive the design and construction of components in an application.

Then, given a Platform Definition Model that corresponds to Java™ Enterprise Edition (JEE) or Microsoft®.NET, and so forth, the Platform-Independent Model is translated to one or more Platform-Specific Models that computers can run. The platform-specific models can use different domain-specific languages (DSLs) or a general purpose language, such as Java, C#, PHP, or Python.

Classification of models in MDA

Models can be classified into following categories (also described in Figure 1), which range from more abstract (1) to more specific (3):

  1. Computation-Independent Model (CIM)
  2. Platform-Independent Model (PIM)
  3. Platform-Specific Model (PSM)
Figure 1. Models in MDA
Illustration from more abstract to more specific

Computation-Independent Model (CIM)
Also referred to as a domain or business model, the CIM presents the system at the highest level of abstraction. The goal of the CIM is to model the problem entirely in business terms and without getting into the solution or how it might be implemented. It helps domain experts share business requirements with software development experts.

Platform-Independent Model (PIM)
A PIM is used by software architects and designers to describe the software solution at a high level, independent of the solution's deployment platform. This high-level definition of the solution can then be translated into multiple Platform-Specific Models.

Platform-Specific Model (PSM)
A PSM specifies a combination between the details found in the PIM with the details representing how a solution can be implemented on a platform. As the name implies, this includes details about a specific platform in the model.

About the analysis model

The analysis model describes the structure of the system or application that you are modeling. It consists of class diagrams and sequence diagrams that describe the logical implementation or realization of the functional requirements that you identified in the use case model.

The analysis model identifies the main classes in the system and contains a set of use case realizations that describe how the system will be built. Class diagrams describe the static structure of the system by using stereotypes to model the functional parts of the system. Sequence diagrams realize the use cases by describing the flow of events in the use cases when they are executed. These use case realizations model how the parts of the system interact within the context of a specific use case.

You can think of the analysis model as the foundation of the design model, because it describes the logical structure of the system but not how it will be implemented.

The analysis model is usually platform-independent (a PIM), which means that these models are technology agnostic. You can use an analysis model for any technology (Java™ Enterprise Edition [JEE], Microsoft® .NET, and so forth).

Types of classes in the analysis diagram

There are three kinds of classes in the analysis model (also see Figure 2):

  • Boundary class
  • Control class
  • Entity class
Figure 2. Analysis model classes
Simple illustration of the 3 classes

Boundary class
Mediates between the system and something outside of the system. Actors interact with the system through the boundary class (for example, JavaServer Pages, or JSPs, in JEE or ASP in a .NET application).

Control class
Coordinates between the boundary class and an entity class or other components. It contains the logic to invoke appropriate components to complete the path.

Entity class
It represents the business entity in the system. These classes often contain persistent characteristics (for example: Driver, Ticket and so on in the Driver Ticket System).

How to create an analysis model

The analysis model consists of a domain model that describes the static structure of the Driver Ticket System and a set of use case realizations that model the temporal details of the use cases as sequence diagrams.

By following these steps, you will create an analysis model for the Driver Ticket System described in the use case se model (see attached project Interchange file in resource section):

  1. Download the file from the Downloads section to a temporary folder.
  2. Now open the Rational Software Architect workspace and import the .zip file as a Project Interchange option by selecting File > Import, and then select Project Interchange and Next as Figure 3 shows.
Figure 3. Import the Project Interchange file
Import screen, Select view
  1. Select your .zip file and then click Finish as Figure 4 shows.
Figure 4. Select the file
Import Projects screen
  1. Now Open you My Article modeling project and review the Use Case model for Driver Ticket System. There are five use case in this package:
Figure 5. Review the use case
Project Explorer view of Use Case model
  1. Now it's time to create the analysis model. Create an analysis model by selecting File > New > Model. Keep all of the default values, and select Next.
Figure 6. Create a new analysis model
Create Model screen
  1. Now, from Categories, select Analysis and Design and from Templates, select RUP Analysis Package, Select My Article Modeling as a destination folder and then click Finish (see Figure 7).
Figure 7. Select a template
Create Model view

You can see the RUP Analysis model in the Project Explorer view (select My Article Modeling >Models > RUP Analysis Model), as Figure 8 shows.

Figure 8. RUP analysis model
Project Explorer view
  1. Next, the goal is to create domain model of the system. All of the classes should be identified in this process. To identify the classes, you must first analyze the use case documentation (see the use case model) and list all of the nouns that occur. This list provides the basis for the entity, controller, and boundary elements that comprise the domain diagram. The following list contains all of the nouns in the Driver Payment System use case documentation:
    • Driver
    • Ticket
    • Catalog
    • Payment

After analyzing the use case model or document carefully, the following classes are stereotyped as Boundary, Control, and Entity, respectively, as the following table shows.

Ticket Entry
Payment Entry
Ticket Processing Controller
Payment Processing Controller

Now it is time to complete the analysis model building blocks.

First, highlight the ${functional.area} template, copy it by pressing Ctrl+C, and then paste it by pressing Ctrl+V in the analysis building block (also see Figure 9).

Figure 9. Copy and paste the template
To modelLibrary Analysis Building Blocks folder
  1. Rename Copy_1_${functional.area} to Driver Payment System (see Figure 10).
Figure 10. Rename the functional area folder
Shows new folder name
  1. Copy, paste, and rename (Boundary, Control, Entity (according to the preceding table) to ${functional.area} Analysis Elements and Use Case Template, ${}, to Driver Payment System package, as Figure 11 shows.
Figure 11. Placement of classes
Placement of classes
  1. Now copy ${} template, paste it in the same folder, and rename it with appropriate use case realization (see Figure 12).
Figure 12. Placement of realization
Placement of realization
  1. Now it's time to drag analysis classes and use case realizations to the default diagrams. See Figure 13 and 14, respectively.
    • Payment processing for charges in the ticket. See Figure 16 for Ticket Payment Processing, under the Ticket Payment use case.
Figure 13. Analysis class diagram view in the Project Explorer
Driver Payment System analysis elements

Larger view of Figure 13.

Figure 14. Use case realization overview
Driver Payment System use case realization

Larger view of Figure 14.

  1. Create use case realizations for all of the sequences described in the use case specification. (For this exercise, you can see it in Step 13) . Use all of the analysis classes to create a use case realization or sequence diagram. This is the generic sequence for each sequence diagram:
    Actor > Boundary Class > Control Class > Entity Class > Data Source
  2. To create a use case realization for the main use case, Ticket Payment, you need to realize following sequences:
    • Retrieve Ticket Information. This includes retrieving driver information, the nature of the offense, and the amount of the charge (financial penalty) for that ticket. See Figure 15 for the basic Retrieve Ticket Info Flow under the Ticket Payment use case.
    • Payment processing for charges in the ticket. See Figure 16. Ticket Payment Processing, under Use Case Ticket Payment.
Figure 15. Retrieve Ticket Information process flow
Flow diagram

Larger view of Figure 15.

Figure 16. Ticket Payment processing flow
Flow diagram

Larger view of Figure 16.

The following additional use cases in the functionalities are either subordinate or optional.

  • Ticket Payment by Internet. See Figure 17. Reuse the sequence from main use case, Ticket Payment.
Figure 17. Ticket Payment by Internet sub use case
Flow diagram

Larger view of Figure 17.

  • Ticket Payment by Phone. See Figure 18. Reuse the sequence from main use case, Ticket Payment.
Figure 18. Ticket Payment by Phone sub use case
Flow diagram

Larger view of Figure 18.

  • Capture Driver Information. This subordinate use case is accessed by the Ticket Entity use case (see Figure 19).
Figure 19. Capture driver information sub use case
Flow diagram

Larger view of Figure 19.

  • Access Point Catalog. This is an optional use case that is accessed by the Driver as actor (see Figure 20).
Figure 20. Access Point Catalog optional use case
Access Point catalog

Larger view of Figure 20.

How to make perspective diagrams

Now, after completing the building blocks, analysis elements (classes) and use case realizations, for the Driver Ticket Payment System, it is time to complete the perspective overview diagrams.

  1. Expand package «perspective» Overviews and complete the diagrams. For Driver Ticket System UI, Key Controllers, Key Abstraction, and Domain model, click the corresponding diagrams and drag the significant analysis classes from the Analysis Elements package as the following figures show:
    • Figure 21 shows PaymentEntry, PointCatalog, and TicketEntry as boundry classes.
    • Figure 22 shows CatalogPointProcessing, TicketProcessing, and PaymentProcessing as control classes.
    • Figure 23 shows Payment, Catalog, Driver, Ticket as entity classes.
    • Figure 24 shows key abstraction of the Driver Ticket System.
Figure 21. Driver Ticket System UI view
3 analysis classes stereotyped as Boundary

Larger view of Figure 21.

Figure 22. Driver Ticket System Key Controllers view
3 analysis classes stereotyped as Control

Larger view of Figure 22.

Figure 23. Driver Ticket System Domain Model view
4 analysis classes stereotyped as Entity

Larger view of Figure 23.

Figure 24. Driver Ticket System Key Abstractions view
Diagram of 9 significant analysis classes

Larger view of Figure 24.

  1. Now create a final Driver Ticket System Analysis overview diagram: Click the Driver Ticket System Analysis Overview diagram from the root, and drag the functional area package, Driver Ticket Payment System, from the analysis building blocks and the «perspective» Overviews package (see Figure 25).
Figure 25. Driver Ticket System Analysis Model Overview view
perspective Overviews under use case

Larger view of Figure 25.

How to make requirements traceable

Two major work products have been created in the analysis model: analysis classes and use case realizations. Follow these steps to establish traceability from requirements as use cases to their realizations and from realizations to analysis classes:

  1. Traceability from a use case to a use case realization: Highlight one of the main Ticket Payment use cases from the Use Case model and right-click to select Query > Traceability > Specification from the drop-down menu.
  2. Save the result in a .dnx file (see Figure 26).
Figure 26. Traceability from the use case
Traceability.dnx tab view

Larger view of Figure 26.

You can also establish traceability from use case realizations:

  1. Highlight the Ticket Payment use case realization, and right-click to select Query > Traceability > Implementations. You can trace all of the artifacts, as Figure 27 shows.
Figure 27. Traceability from a use case realization
Implementation of” tab view

Larger view of Figure 27.


After completing the analysis model for the problem that is mentioned in the article, you may know how to realize the use case and create a logical structure of the system. The analysis model not only gives you a full understanding of the system, but helps you trace the related requirements, too. As a platform-independent model, the analysis model provides basic building blocks for full enterprise design for any specific platform.

You can find the and the Project Interchange File (PIF) files for this exercise in the Downloads section.


Project Interchange FileRSA-ReqPro-PIF.zip12KB
Project filesAnalysisModel.zip62KB



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Requirements traceability in analysis models in Rational Software Architect Version 7.5