Qualität kostet Geld! Viele können vermutlich diesem Statement zustimmen. Das Statement wird sich auch kaum widerlegen lassen – schon deswegen nicht, weil es sehr allgemein formuliert ist.
Bezogen auf den Software Entwicklungsprozess wird aber oft der sehr vereinfachte Schluss gezogen, dass jede Maßnahme der Qualitätssicherung einfach nur teuer ist.
Ich möchte im nachfolgenden Blog einmal etwas genauer hinschauen und das Review von Requirements aus wirtschaftlicher Sicht betrachten. Lohnen sich Requirements Reviews, so wie sie in allen Standards der Funktionalen Sicherheit gefordert werden, aus wirtschaftlicher Sicht?
„Zeit ist Geld“ ist hier zunächst einmal das Motto, d.h. im ersten Schritt müssen wir überlegen, wie lange das Review eines Requirements im Durchschnitt dauert. Nun, ich gehe davon aus, dass Sie lieber Leser, hier durchaus sehr unterschiedliche Erfahrungen gemacht haben. Ich werde nachfolgend versuchen, trotzdem einen Wert herzuleiten.

Review:

Lassen Sie uns dann einige Randbedingungen festlegen:

• Die Review Checkliste umfasst 5 Punkte.
• Die Reviewer sind sehr erfahren.
• Einzelne Requirements umfassen nicht mehr als 3 Sätze und 3 Zeilen.

Nehmen wir mal an, unter diesen Voraussetzungen dauert das Review eines Requirements 5 Minuten. Für jeden der 5 Review Checklistenpunkte bleibt also 1 Minute. Das ist zunächst einmal sicher nicht viel, andererseits ist es doch plausibel ein Requirement mit max. 3 Sätzen und 3 Zeilen nicht länger als 5 Minuten anzuschauen. Wenn man in dieser Zeit keine Probleme identifiziert, dann ist es auch unwahrscheinlich, dass dies beim längeren Reviewen der Fall ist.
Die Anzahl der zu dokumentierenden, gefundenen Probleme haben wir bisher nicht betrachtet. Gehen wir also nun davon aus, dass in 50% der Requirements durchschnittlich ein Fehler gefunden wird. Das Aufschreiben eines Fehlers dauert in der Regel 2 Minuten. Weiter nehmen wir an, dass unser System 500 Requirements enthält. Damit müssen wir also noch 2 zusätzliche Minuten zur Hälfte (also 250) aller Requirements hinzu addieren und kommen somit auf eine durchschnittliche Gesamtbearbeitungszeit von 6 Minuten pro Requirement.
Nun gehen wir davon aus, dass 20% der gefundenen Fehler eine signifikante Auswirkung auf das Systemverhalten haben. Dies ergibt folgende Rechnung:

Anzahl Requirements:        500
gefundene Fehler insg.:     250 (500 * 0,5)
signifikante Fehler:               50 (250 * 0,2)

Um diese 50 Fehler zu finden benötigt man: für 500 Requirements á 6 Minuten Review Aufwand. Dies ergibt dann insgesamt 50 Stunden.

Das bedeutet, dass bei diesem Review-Beispiel pro Stunde ein signifikanter Fehler gefunden wird!

Test:

Selbst wenn Sie jetzt den Aufwand des Reviews verdoppeln und die Anzahl der gefundenen Fehler halbieren, wird mit 4 Stunden Aufwand ein signifikanter Fehler gefunden.
Wenn man nun das Testen als weitere essentielle Möglichkeit zum Finden von Fehlern entgegensetzt, dann ist schon ohne genauere rechnerische Analyse plausibel, dass der Aufwand pro gefundenem Fehler deutlich höher sein wird.
Beim Testen ist es zunächst einmal notwendig, Test Spezifikationen zu schreiben. Für das Review haben wir 5 Minuten pro Requirement angesetzt. Beim Test muss man aber nicht nur das Requirement lesen und verstehen (wie beim Review), sondern man muss aktiv Test Cases niederschreiben. Nehmen wir mal an, das dauert doppelt so lange, also 10 Minuten pro Requirement. Nachdem Test Case kommt dann noch die Testprozedur hinzu. Da man hier sehr viele Details beachten muss, welche meist über das einzelne Requirement weit hinausgehen, dauert das sicher noch einmal deutlich länger als die Formulierung des Test Cases. Nehmen wir an, es sind 30 Minuten. Bei manuellen Tests, kommt jetzt auch noch die Ausführungszeit hinzu. Diese ignorieren wir hier aber einfach. Zusätzlich müssen wir noch betrachten, dass zwar manchmal für mehrere Requirements ein Test Case ausreicht, andererseits benötigt man für viele Requirements in der Regel mehr als nur einen Test Case. Wir nehmen an, dieser Effekt hebt sich gegenseitig auf, sodass also die Erstellung von Tests pro Requirement 40 Minuten dauert. Gegenüber den 6 Minuten Aufwand für ein Review haben wir hier mit dem ca. 7 fachen Aufwand zu rechnen.
Wenn man von der gleichen Anzahl von gefunden Fehlern ausgeht, benötigt man um die 50 signifikanten Fehler zu finden: für 500 Requirements á 40 Minuten Aufwand beim Testen = insgesamt 333 Stunden Arbeitsaufwand.

Das bedeutet, dass bei diesem Test-Beispiel pro 6,6 Stunden ein signifikanter Fehler gefunden wird!

Fazit:

1 Stunde Review-Aufwand um einen signifikanten Fehler zu finden gegenüber fast 7 Stunden, um einen solchen Fehler beim Testen zu finden. Bei aller Relativierung, die man sicher bezüglich der Zahlen noch vornehmen kann, ist das doch ein aus wirtschaftlicher Sicht beindruckendes Plädoyer für die Durchführung von Reviews, oder nicht?

Ihre individuellen Fragen zum Requirements Engineering beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).