Channels ▼

Eric Bruno

Dr. Dobb's Bloggers

Requirements Traceability Matrix (RTM)

July 22, 2008

When embarking on a new software project, there are many development methodologies that you can follow. Of course, there's the classic waterfall model, where you define all of the requirements, then you design the entire system, then you code the entire system, then you test the entire system, and you don't release it until all of the features are complete. This makes sense on paper, but in practice it's inflexible, and impractical as there's no room for change along the way.


Iterative Development


An alternative is to use an iterative approach, where you break the overall project into sub-projects (possibly by requirement) and you create a pipeline for each. For instance, while one requirement is nailed down and being coded, others might still be in the works, others might already be in testing, and others might loop back around to requirements definition even though coding already started for them. It's truly iterative, in that you go through the "define / code / test" cycle multiple times, even for the same requirement(s).


From this concept,  Model-driven Engineering (MDE) was born, with its variants such as Rational's Unified Process based on UML, and the OMG's Model-driven Architecture (MDA).  I particularly like UML as it helps me visualize the components in a large software system, and it goes a long way to communicating a system's design with others. In my opinion, a handful of good UML diagrams tell me more about a system then dozens of written pages. 




The Capability Maturity Model (CMM), defined by the Software Engineering Institute (SEI), defines a five-level process to software development. It describes the  steps that a software development team should follow to attain a repeatable, successful, software development process. It also defines five possible levels that a development organization might be in, level 1 being the base level. After being assessed on certain points, such as how well documented requirements, design, and testing are, as well as how well progress is measured, an organization is deemed to be at one of the five levels. 


Some developers balk at all of the formality involved with CMM, and the process-heavy approach they're often required to follow. Others like the structure and repeatability it fosters. However, most developers will agree that some process and documentation are small prices to pay to avoid the problems and possible project cancelations that might result without them. Perhaps the biggest strength of CMM is that it's flexible enough to work with any software methodology.


Agile Development and XP


Agile Software Development is a methodology that encompasses other software development methodologies. More importantly, it combines software development process with an iterative approach, group collaboration, adaptability, and software life-cycle issues. After all, a software system's life doesn't end after it exits testing. The need to deal with full life-cycle issues (i.e. customer support, patch deployment, and capturing customer feedback) is often underestimated.


Extreme Programming (XP), made popular by Kent Beck from his work at Chrysler, is form of Agile Programming. Its goals are to consider the humanity in software development just as much as the process. It focuses equally on the social side of programming, setting it out to make it as enjoyable as it is successful. The idea is that happy developers are productive developers. As a result, the methodology combines process with style, discipline, communication, feedback, and basic teamwork. 




Unfortunately, all too often, most development teams use the SOYP methodology; otherwise known as the Seat Of Your Pants process (or lack thereof). I've found that it's best to follow some sort of process. Even if you don't choose to follow one strictly, you'll find more success if you follow portions of the methodologies defined above. 


For instance, I've combined the use of UML diagrams, with the small group communication techniques found in XP, and the need to document and execute unit tests, without adopting all of the related details of the Unified Process, or XP, or CMM. On many projects and with most development teams, this can lead to more success than going too far in either direction (SOYP versus strict process). However, I've found one component critical to success in all of these projects; the RTM.


Requirements Traceability Matrix (RTM) Defined


Regardless of the process followed on the projects I've been involved in, I've always introduced the concept of the requirements traceability matrix (RTM). This is implemented as a simple spreadsheet, with each row of the spreadsheet dedicated to a requirement to be implemented. Included are spreadsheet columns for the following:


-A unique requirements identifier  (i.e. a number)

-A description of the requirement

-A pointer to a design document for the requirement

-A pointer to the unit test document for the requirement

-A pointer to the test results after testing the requirement

-A color-coded (i.e. red, yellow, or green) status column for the requirement

-A column for sign-off for the requirement's inclusion in the next release


Each associated document, and all communication about the project (email, and so on) refer back to the requirements by requirement ID. This provides good two-way reconciliation between the RTM, and the set of design, test, and test-result documents. Meetings to measure project status and development progress always revolve around the RTM, and the requirements IDs contained within. 


I've found that this simple form of project accounting helps to keep the project organized, and helps to focus all of the stakeholders. It also helps to ensure that nothing falls through the cracks. For instance, if a design document is missing for a particular requirement/feature, it will be obvious when you look at the spreadsheet. If the implementation of a particular requirement is not going well, the status column will show this (and you can sort them by status if needed).


What process do you follow? How do you trace requirements/features from definition through deployment on your projects? Write back in the comments section and share with your fellow DobbsCodeTalk readers.


Happy Coding!


Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

