The Importance of Being Traceable

Knowing 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?”

Questions and Answers

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 that are traceable from their source through to all of the artifacts of the solution that the requirement impacts.

The two major automated methods to trace requirements 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 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 Traceability

But, (are you sitting down?) even this is not enough. “What more?” you ask. Traceability 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 traceability.



Copyright MKS Software Inc. © 2006. In Canada copyright owned by MKS Inc. © 2006. All rights reserved.

A lack of requirements traceability 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 (see article A Primer on Software Litigation), traceability 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.

Editors’ Notes: Website Upgrade and a Request for Topics (RFT)

NEWSFLASH! For anyone who hasn't noticed it yet, the Requirements Solutions Group website has undergone a major facelift this month. We have added several new pages (go ahead, see if you can find them). Also new is a link to the Noiseletter archives so in case you missed a previous edition (or found it so exciting you just have to reread it!), it is only a click away. In addition, we’ve added a link for visitors to voluntarily subscribe to this pillar of know-how and know-not to make it easier than ever to stay in-the-know-now.

In that vein, we are also soliciting topics you would like to read about in future Noiseletters. Until now, we have been overbearingly undemocratic regarding what we wanted to write about, but we really are interested in whatever interests you. If you have a tough question, a wild idea, a stray thought, or a good story, share it with us and we will research it, ponder it, opine about it and otherwise do our best to generate an interesting and informative response which we will publish (pending editorial review, obviously; we do have standards — if we could only figure out where we put them). If publication is not desirable from your interests or ours, we will, at the very least, respond to you personally — assuming you provide a valid email address..

Meanwhile, back at the ranch, hope you're enjoying our edutainment efforts and we look forward to seeing you at a future training event.

Tom Hathaway and Dan Myers
Managing Partners

Future Feature: "The Goldilock’s Theory of Business Analysis"