On Track?

Luc Richard - August 4, 2003

Managing larger software development projects requires a lot of discipline. No matter how many times you've read the specs, unless you have a stringent process for tracking requirements, some of them will fall through the cracks. You'll reach code freeze only to realize during your testing phase that features x, y and z were omitted. At that point, you have two options: Edit the specs and reschedule the overlooked requirements to the next release, or force your developers to work overtime in order to get the features in the build.

If this problem sounds familiar, don't worry. Many managers have made this mistake in the past, but once you implement a "Requirements Traceability Matrix," you can be confident the gaps will be identified early on, giving you lots of time to rectify the situation.

Requirements Traceability Matrix
A "Requirements Traceability Matrix" (RTM) organizes and tracks the software requirements throughout the product lifecycle. It guarantees requirements cover all of the use cases, the system design meets those requirements and test cases cover all the areas of the system. Furthermore, it ensures that developers are not spending valuable time on features that do not map to a requirement requested by product management--a classic mistake known as gold plating.

To develop an RTM, follow these four simple steps:

Step 1: Identify what you want to track
Tracking software requirements calls for a lot of time and discipline. While you would benefit from tracking business requirements, use cases, mock-ups, function points and test cases, your busy schedule may not allow you to do so. Realistically, you might only want to track two or three specific items.

Step 2: Determine who's responsible for what
Managing the RTM is a tedious task, so you might want to assign it to someone else, or even possibly distribute the responsibility between a small group of people. However, these people must have the authority to rectify identified problems. If someone discovers that use cases a, b and c are not covered in a functional spec, or that there are missing test cases, he/she must be able to get someone to fix the problem. Identifying a problem and not being able to resolve it in a timely manner is simply a waste of time.

Step 3: Draft the RTM
The people responsible for the RTM can build one or more matrices using a simple spreadsheet. While there are commercial applications that allow you to track requirements, there is no need to invest thousands of dollars in such an application unless you have hundreds of requirements to manage.

The RTM should be built when the requirements are 80 percent complete. Drafting it too early will be inefficient because of the frequent alterations, and waiting too long will not allow you to identify gaps in a timely manner.

Step 4: Keep it up-to-date
The RTM is a tool that needs to be updated throughout the product lifecycle. New requirements should be added, and obsolete requirements should be struck through and/or deleted.

A Practical Example
Rick is managing a team of three developers, and product management asks him to develop a working prototype for a customer. The high-level system requirements are almost complete, and Rick's team now needs to define the technical requirements for the system.

Rick decides in step 1 to only map functional requirements to technical requirements. Since this is strictly a prototype, he won't worry at this point about tracking test cases and other artifacts.

Since his team is building the system, Rick decides in step 2 to build and manage the RTM himself. He already received the functional requirements from product management, and plans to get his developers to write the technical requirements.

The functional specs only have 10 requirements, and each has a unique ID (used for tracking purposes). After reviewing the requirements, Rick decides to break the system in three components, and asks each developer to write a technical note for the component they're responsible for. Once again, for tracking purposes, each technical note is given a unique ID.

Once the technical notes are drafted, Rick builds the following RTM using a simple spreadsheet. Column A enumerates software requirements 1 to 10 (SR-01 to SR-10), and row 1 lists technical notes 1 to 3 (TN-01 to TN-03). An "x" indicates that the software requirement is covered in the technical note.

After analyzing the RTM, Rick realizes that SR-06 has been left out from the technical notes, and SR-10 is not complete. While it is specified in TN-03, part if it's implementation requires additional details in TN-01 as well. He therefore completes the first revision of the RTM by filling out column E, and row 12.

A "yes" in column E signifies that the software requirement is fully specified, and a "no" means that the requirement is not (or only partially) specified. Likewise, a "yes" in row 12 signifies that the technical note is complete, while a "no" indicates that it requires additional details.

Once the author of TN-01 updates his technical note, Rick updates the RTM, and ends up with this second revision of the matrix.

All software requirements are specified, and Rick is now confident that his team has designed a prototype that meets the customer's needs.

Conclusion
By following this simple four-step plan, you too can be confident that by code freeze, all the use cases and software requirements requested by product management will be implemented in the system, and that customers will receive a solution built according to specs.

Luc earned a Master's Degree in Business Administration with a focus in high-technology. He has more than 6 years of experience in e-business consulting, project management and web development.

Related Content

Nonfunctional Requirements

by Luc K. Richard October 13, 2003

---