Calculating ROI on your Investment in Requirements Management Tools

a factor of 5 from phase to phase, well within the industry averages that are cited in the literature.

Now let's look at the model. We start by estimating the number of requirements-related defects. Unless we are willing to acknowledge the possibility of a perfect requirement, it's safe to assume that all of the defects have at least one defect. If you are not comfortable with that assumption, adjust the percent as needed.

Next, we estimate the number of requirements related defects removed prior to commitment to code, and the associated cost. A removal effectiveness of 50% means that of the total population of defects, 50% were caught and fixed. We'll assume that on average a defect at this stage can be found and fixed in 1 staff day. Changes that don't involve code are simply cheaper to make.

Next, we estimate the number of requirements related defects removed from the code itself (e.g. unit, integration and system test) and the associated cost. The calculation starts with the number of defects that remain undetected and unfixed from the previous stage. Because we are now dealing with code, the cost of finding and fixing a defect rises from 1 staff day per defect to 5.

At this point let's review the total removal effectiveness of the first two stages.

Finally, the cost of defects shipped with the product to the customer. At this stage "finding" the bug is not so much a factor in the cost; the customer does that for you! Here, the cost of defects is determined by factors such as customer support calls, loss of sales from unhappy customers, and, of course the increased cost to patch software in the field. The cost of defects at this point will vary greatly depending on the industry, safety-critical products being an example where the cost can be very high.

Our baseline cost for finding, supporting, and fixing requirements-based defects is $2,608,696. Then we rerun the baseline, but with a 10% increase in defect detection and removal at each of the first two stages. This is the added review and rigor we paid for previously (see above under costs).

Our new cost is $2,024,348; a cost savings of $584,348.

Bottom Line
All that is left is to tally the Benefit to Cost Ratio, and, as they say, "Your mileage may vary."

Estimated savings: $1,884,565
Estimated cost: $427,657
Benefit to Cost Ratio: 4.4 to 1

Recall that cost at this point includes one-time expenses such as initial software purchase, and initial on-site consulting and training. The ratio should get even better once those one-time expenses are out of the way.

Summary
As noted previously, cells that are gray filled are ones where the values entered are highly subjective, and vary depending on your company and industry. I found that a useful approach to using this model in talking with people is to have them provide values for these cells, kind of a Wideband Delphi approach. In that way they can see if the values they are willing to buy into result in a good benefit to cost ratio. After you've talked with a number of people, use their responses to build a minimum and maximum version of the model. If you want to get a bit more sophisticated, you can even run the model with a Monte Carlo simulation tool. This would provide a probability distribution function of the Benefit to Cost Ratio.

And while this model was developed to demonstrate ROI after the fact, the ideal use of such a model is to help in selling the process change in the