

Using a traceability matrix to map requirements to test cases

Expert Robin Goldsmith explains the use of a traceability matrix and the importance of level of detail in cross-referencing requirements to test cases. Goldsmith recommends higher level of detail in both requirements and tests in order to attain the most meaningful traceability.

What are the current challenges in software traceability area? Are there any open source requirements gathering tools that can be integrated with IDEs and a traceability environment can be set?

Traceability is an important, relatively simple, and unfortunately, often over-stated testing and development concept. Basically, tracing requirements to where they are implemented and then to where they are tested helps assure all requirements have been met and can identify extra "gold plating" work without corresponding requirements. A traceability matrix shows these relationships. The matrix traces forward to identify things that may be affected when a requirement changes and traces backward from changed downstream artifacts (such as code or tests) to identify affected requirements. Traceability matrices can be created manually or with a spreadsheet or simple database. However, these methods tend to turn tedious and unwieldy. Consequently, creating, maintaining, and reporting traceability matrices is a major feature of requirements management tools that many people rely on. Open source versions undoubtedly exist, but I'm not personally familiar with them. 

Tools handle traceability matrix mechanics, but not content. Human beings must indicate each cross-reference to the tool, e.g., each module where the requirement is implemented and each test of the module's implementation of the requirement. This is where traceability matrix issues arise and capabilities are over-stated. 

Even traceability matrix advocates recognize it's easy to miss cross-references. They generally fail to recognize importance of starting point and impact of level of detail. Most traceability starts with product/system requirements but should start with real business requirements. It's usually only practical to do a traceability matrix at relatively high-level, but that reduces the value below what proponents claim. 

Meaningfulness usually demands considerably greater detail of both requirements and tests. Consider the example in my tip, What is a test case? What is a requirement? in which I describe how requirements and test cases may be documented with varying levels of detail. Running only one low-level test might satisfy a traceability matrix indication that a high-level requirement had been tested; but such minimal testing provides illusory inadequate confidence the requirement has been met. 

However, adding even one or two needed levels of requirements and testing detail almost immediately geometrically expands the number of cross-references. That swells matrix entry costs while reducing value by increasing likelihood of errors. 

To the best of my knowledge, the simplicity of traceability as a concept means it's not likely to have a lot of research. I'd guess that most of what could be called research is actually done by vendors designing new or improved tools that do traceability matrices. A quick Google search revealed a place I'm not familiar with called the Center of Excellence for Software Traceability (COEST).

This was last published in October 2010

Dig Deeper on Software Requirements Gathering Techniques

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.