Many application development frameworks (Extreme, Iterative, RAD) establish the guidelines for a successful application development process. With the popularity of the Rational Unified Process (RUP) and Unified Modeling Language (UML), application development tools have prospered.

But what if your application does not conform to what is considered e-development? Do you need to abandon the tools and techniques outlined by RUP and UML?

Not at all. However, you may need to mold and stretch the existing RUP and UML techniques to fit your particular requirements. In fact, both processes are designed for this ad hoc type of approach.

In this article, I will discuss the use of what is typically termed a Requirements Traceability Matrix, or RTM. This method of capturing user requirements can be used in any application development process and attempts to “whitebox” the development approach.

The whitebox approach
“Whiteboxing” refers to the development of system requirements without considering the technical implementation of those requirements. In UML, this type of approach is typically termed a “Perspective.” Within the UML, there are three perspectives:

  • Conceptual
  • Specification
  • Implementation

Whiteboxing refers only to the Conceptual and Specification Perspectives. The Conceptual Perspective deals with “concepts in the domain,” while Specification deals with interfaces. The approach also helps you deal with your subject matter experts’ domain concepts and interfaces without having to discuss technical aspects of the application. For example, if you were working with an automobile manufacturer, the domain concepts would center around how the car is manufactured or specific details about the automotive manufacturing industry. Interfaces deal with how the proposed system elements—such as user authentication or placing an order—interact.

Developing a baseline RTM
The primary purpose of the RTM is to capture end-user requirements. While there are many variations on the elements that make up the RTM, I have included those that have worked well for me. The main elements that make up my ad hoc RTM are as follows:

  • RTM Number—Choose a specific and easily identifiable number to refer to the specific requirement.
  • Requirements—This is a structure sentence describing the requirement in a “shall” format; i.e., the “user shall…,” the “system shall…,” or “clicking the Enter button shall….”
  • Notes—These are any notes relative to the requirement.
  • Requestor and date—This is when and who requested the requirement.

Within the RTM, you will typically have subdivisions capturing different functions of the application. Specifically, the RTM should be broken into sub-RTMs that capture the following information:

  • GUI requirements
  • System requirements
  • Data requirements

While the above four RTM elements comprise the core of the RTM, you can customize the matrix to tie the requirements back to other documents. This is really where the RTM starts to show its power.

As an example, let’s look at some additional RTM elements that can be used to further enhance your ability to “trace” the requirements.

Additional RTM elements

  • Relative to RTM #—This number details whether the requirements are directly or indirectly related to other requirements.
  • Statement of Work (SOW) paragraph—This description relates the requirements directly back into a specific paragraph within the Statement of Work. This is one of the more powerful features. (Note: An SOW details the specific nature of your engagement with your clients and lists and defines deliverables and other boilerplate information. The SOW stops short of being a contract but does outline your approach to the project and sets expectations.)
  • Use Case #—This number relates the RTM number forward into a use case for even more traceability.

So we can see now where the traceability idea comes in. Any feature within the application should be directly traceable to a user requirement. Objects should trace to object and interaction diagrams, object and interaction diagrams should trace to class diagrams, class diagrams should trace to use-case diagrams and individual use cases, and use cases should trace directly back into the baseline requirements of the user that are captured within the RTM (see Figure A).
Figure A



User case #

Rel. to RTM #

Requested by

SOW paragraph
Login screen
User will be presented with a login username field.
End user 1 – 1/2/01
User will be presented with a password name field.
DBA -101
End user 1 – 1/2/01
The username will be a maximum of eight alphanumeric case-insensitive characters.
DBA – 101
End user 1 – 1/2/01
The password will be a maximum of eight alphanumeric case-insensitive characters.
DBA – 101
End user 1 – 1/2/01
The password will be a minimum of six alphanumeric case-insensitive characters.
DBA – 101
End user 1 – 1/2/01
The password will be encrypted and stored on the database.
DBA 101, 106
End user 1 – 1/2/01
The username will also be stored on the database.
End user 1- 1/2/01
The login screen will have a Clear Fields button.
End user 1 – 1/2/01
The login screen will have an Enter button.
End user 1 – 1/2/01
The login screen will have a mechanism for setting up an account.
Note: Need to define this mechanism
in more detail for users
End user 1 – 1/2/01

This example of an RTM shows how application requirements are tracked, who made the request, and how each is tied to the Statement of Work.

Helpful links
The following sites provide more detailed information on capturing requirements: