Quality costs money! Many can probably agree with this statement. Anyway, it is difficult to refute the statement, as it is very generic.
At the same time very often the simplistic conclusion is drawn, that any quality measure within the software development process is just expensive.
I want to take a closer look with the following blog. As an example for quality measures I will take the requirement review. These reviews are required by all the functional safety standards.

Time is money:

“Time is money” is here first of all, the topic. That means in the first step we need to consider how long last on average the review of requirements. I assume that each blog reader has made different experiences on this topic. Despite of that, I will try to derive a value.

The following constraints are defined:

• The Review Checklist includes 5 points.
• The reviewers are very experienced.
• Individual Requirements include no more than 3 sentences and 3 lines.

Let’s say, under these circumstances the review of one requirement takes 5 minutes. For each of the 5 review checklist remains 1 minute. This is certainly not much. On the other hand it’s plausible. Experience tells that 80% of problems in a requirement with max. 3 sentences and 3 lines are found in 5 minutes. It is not effective to review such a requirement e.g. 20minutes. It is very likely that not even one more problem would be found within the 20 minutes review.
So far we did not consider the number of found problems which have to be documented. So let us now assume that in 50% of the average requirements an error is found. Writing down a fault typically takes 2 minutes. Next, we assume that our system contains 500 requirements. Therefore we must add 2 additional minutes to half (i.e. 250) of all requirements. This results in a total processing time of 6 minutes per Requirement.
Furthermore we assume now that 20% of the errors found have a significant impact on the system behavior. This results in the following calculation:

Number Requirements: 500
Errors discovered: 250 (500 * 0.5)
significant errors 50 (250 * 0.2)

To find these 50 mistakes you need for 500 Requirements á 6 minutes Review effort. This then gives a total review effort of 50 hours.

This also means that one significant error is found per hour in this example!

Even if you now double the effort of the review, and halve the number of errors found, one significant error is found with an effort of 4 hours.
Another measure to find errors is testing. Even without further detailed calculation it is already plausible that the effort to detect errors will be significantly higher.
For proper testing it is necessary to write test specifications. For the review, we have applied five minutes per requirement. In the test you have to read not only the requirement and understand it (as in the review), but you also have to actively write test cases. Let’s assume this lasts twice as long, so 10 minutes are needed per requirement. The next step is to write test procedure. Here you have to consider a lot of details, which need an overall detailed system understanding. Therefore the test procedure will take significantly more time compared to the test case. Suppose 30 minutes are required per test procedure. For manual tests, also the execution time would need to be considered. In the example we ignore this effort. In next step we must consider that, sometimes for several requirements one test case is sufficient. On the other hand for many requirements usually more than just one test case is required. To keep the example simple, let assume that these effects are cancel out each other. Thus the creation of a test for one requirement takes 40 minutes. This is almost 7 times as much as it takes to review one requirement (6 minutes).
In the last step we assume that the same number (50) of errors will found with testing, compared to the requirement review. So to test the 500 requirements you need 333 hours (500*40minutes).
333hours divided by 50 significant errors results in 6.6hours.

So one significant error is found per 6.6 hours in this test example!

Conclusion:

1 hour review effort to find one significant error compared to almost 7 hours to find such a test failure. Despite of several uncertainty factors included in the calculated figures, the result is still a strong argument to perform requirement reviews.

Are you ready for a status workshop, to analyse improvement potentials in your requirement engineering, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.