Performing traceability of delivered functionality to requirements without tying them back to Business Objectives is in my opinion an exercise in futility. To anyone engaged in this exercise, I ask “So What?”

At first blush this might seem like an extreme position to take. The benefits of requirements traceability seem readily obvious whether or not they are tied back to Business Objectives. You can determine what requirements were implemented, when they were implemented, what still needs to be done and so on. All of these are good things in and of themselves.

Do You Need Business Objectives For Software Requirements Traceability?

By way of answer, imagine that you are writing requirements for an Experiment Management system. Consider the following scenario.

The first set deals with setting up the experiment. The other set deals with analyzing the results of the experiment.

One of them is responsible for the team that defines and sets up the experiments. The other manager leads the team that analyzes the results of the experiments.

Each set had a total of 10 requirements each. The users prioritized their requirements and each team came back with 4 “critical” and 6 “nice to have requirements”. Assume that all the “Critical” requirements are equally important and deliver approximately the same amount of functionality each to the final delivered product.

They satisfied all of the “nice to have” requirements of both sets. All 4 critical requirements of the experiment analysis requirements were satisfied, but only one of the critical requirements of the experiment set up requirements.

Business Objectives Are Your Yardstick For Success

Simple traceability that did not tie back to Business Objectives would show something along the following lines:

By any yardstick it looks like a spectacularly successful release.

But consider for a moment if the Business Objective for the release has been defined as “reduce the amount of time taken to perform experiment set up by 90% so that the company can increase the probability of successful new product creation by increasing the number of experiments that can be set up by our team of scientists.” The company came up with this objective because it is far easier for them to hire analysts than find skilled scientists who can dream up new experiments that will result in new products.

If we were to apply this knowledge to traceability and coverage of requirements, a very different picture of the success of the release emerges.

All else remaining the same, from a Business Objective stand point, we have about 25% coverage of what is really important to the company for this release. So, this was a pretty dismal release though the raw statistics that do not tie back to Business Objectives seem to indicate otherwise.

At the end of the day, companies build software that advance their prospects and help them achieve specific business goals. As requirements professionals, we need to tie back the outcomes to the Business Objectives. So, if we are not tracing requirements back to the Business Objectives, we are generating data that may or may not be useful or relevant in the grander scheme of things.

There is definitely some virtue in generating data for its own sake. This would be the case in doing all the hard work to trace requirements to specific functionality that has been delivered. But not taking the final step and tracing it back to Business Objectives misses the whole point of the exercise. We are guilty of generating data without giving it the proper context that Business Objectives provide.

So the next time, someone tells you they are tracing delivered functionality back to the requirements, ask them if they are tying them back to Business Objectives. If the answer is no, ask them “So What?” I would.