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:
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).
The following sites provide more detailed information on capturing requirements: