Requirements Traceability to Know Why You Did What
At the beginning of any IT project, you are extremely busy trying to figure out what you can (should) and cannot (should not) do. This is the phase of quantum uncertainty and the only way to reduce it is to define requirements. Once you have defined requirements, design decisions and their consequences move the project into the nether regions of specification and code. Assuming that you had perfect requirements to start with (a highly improbable state) and that nothing changes until you deliver the solution (probability probably less than 0), development is relatively easy (this is our interpretation of Einstein’s Theory of Relativity). The challenging question in development is, ” What happens when something changes?”
Requirements Traceability Facilitates Change
The two most pressing questions that you need to ask are, ” Who has the authority to change the requirements?” and ” What is the impact of the change?” To answer both of these questions, you need Requirements Traceability. A key for your change management efforts is to have requirements that are traceable from their source through to all of the artifacts of the solution that the requirement impacts.
The two major automated methods for Requirements Traceability can be thought of as document-centric and data-centric. Document-centric uses word processing or spreadsheets and is by far the most common. It works fine for simple projects that meet most of the following criteria:
- Small: Less than 1,500 work hours with less than 4 FTE team members
- Short: Less than 6 months total duration or less than 2 months per incremental release
- Independent: Little or no relationship to other projects
How Many Projects Fit?
The first two of these criteria are not that uncommon. Unfortunately, the third one is a killer. Based on our experience, only about 50% of projects meet all criteria. As systems or enhancements get larger and/or more complex, keeping track of each requirement and its relation to other system artifacts becomes increasingly challenging. Every user requirement needs to be traceable back to its source (owner) and to all delivered objects, modules, code segments, test cases, help facilities, and other system artifacts.
This is often the only way to evaluate the real impact of a change. This level of documentation exceeds the capabilities of word processors and spreadsheet. It is virtually impossible without the significant linking capability of a database system.
Centralized Requirements Trace-ability
But, (are you sitting down?) even this is not enough. “What more?” you ask. Requirements Trace-ability at its most powerful not only tracks requirements and their impact on specific artifacts, but also the workflows that create, relate, and change the requirements and the artifacts. Having all this information in a single repository allows for maximum flexibility, user access, and trace-ability.
A lack of requirements trace-ability results in not being able to prove that a given requirement has been met as expected. It also often leads to unspecified (perhaps unused, unwanted and even surprising) system behaviors. Considering that the next killer app in IT technology may (will) be litigation. A Primer on Software Litigation), trace-ability may be a necessary constraint for not only the normal high-risk or highly regulated systems, but probably includes virtually any system developed through outsourcing.
