Wenn ich Projekte begleite, kommt früher oder später folgende Frage auf: „Woran erkenne ich, ob ich mit meinen Requirements fertig bin?“

Es ist immer schwierig, geistige Leistung – und Requirements sind die Ergebnisse geistiger Arbeit – zu bewerten, und gerade bei den eigenen Arbeiten tun wir uns oft schwer.

Die meisten unter uns haben diese Erfahrungen mit selbstgeschriebenen Texten gemacht: Irgendwann sehen wir unsere Fehler einfach nicht mehr. Und leider schleichen sich aus diesem Grund auch schnell Fehler in die Requirements-Dokumente ein.

Damit das nicht passiert, nutze ich in der Praxis drei einfache Checks, die mir enorm weiterhelfen:

1) Testebene

Wenn ich Requirements beschreibe, ist es meine Aufgabe als Systemingenieur, bei jedem Requirement auch für die Testebene eine Empfehlung abzugeben. Fällt es mir schwer, nur eine Ebene anzugeben, und habe ich stattdessen mehrere Möglichkeiten, die ich auswählen kann, ist das Requirement sehr wahrscheinlich nicht gut beschrieben.

Als Konsequenz ändere ich also das Requirement, formuliere es detaillierter, teile es auf, schreibe es um – bis ich sicher nur eine Testebene empfehlen kann. Das hilft gleichzeitig auch dem Testkollegen, denn so kann er seine Tests frühzeitig entwerfen und die Abdeckung nachweisen.

2) Linkabdeckung

Im zweiten Schritt nutze ich den Filter meines Requirements-Management-Werkzeuges und schaue, ob es in meinem Dokument irgendwelche Requirements gibt, die keinen Link zu übergeordneten Anforderungen besitzen. Wenn mir der Filter Einträge dieser Art anzeigt, ziehe ich diese Links nach.

Anschließend prüfe ich mit einem weiteren Filter, ob es übergeordnete Anforderungen gibt, die keinen Link zu meinem Dokument haben. Wenn mir der Filter Einträge dieser Art anzeigt, prüfe ich, ob ich noch etwas in meinem Dokument vergessen habe, und erstelle entsprechende Anforderungen auf meiner Ebene (und verlinke diese natürlich!).

3) Reviews

Ich gebe meine Arbeitsergebnisse regelmäßig anderen Kollegen mit der Bitte, mir mit einem Peer-Review ein kurzes Feedback zu geben. Anschließend arbeite ich die Ergebnisse ein und lade zu einem formalen Review.

In dieser Review-Session übernehme ich alle Auffälligkeiten in ein Review-Protokoll und gewichte gemeinsam mit den Teilnehmern die Schwere der Auffälligkeiten. Wenn ich keine „Major“-Punkte und nicht mehr als zehn „Minor“-Punkte habe, ist die Reife der Requirements nach dem aktuellen Wissensstand gut genug. Ansonsten muss ich die Auffälligkeiten entsprechend korrigieren, bis ich unter meinem Grenzwert liege.

Wo genau Eure Grenzen sind, müsst Ihr in Euren Projekten selbst ausloten – die Requirements zu beschreiben, ist für mich eine sehr gute und ausreichende Hilfe.

Das Ergebnis

Mit dieser Vorgehensweise in drei Schritten habe ich die Möglichkeit, schnell zu erkennen, ob ich mit meinen Ergebnissen wirklich eine hohe Qualität erreiche.

Um diese für ein Lastenheft sicherzustellen und eine klare Aussage dazu treffen zu können, sind also die folgenden Aspekte hilfreich:

1. Habe ich Schwierigkeiten, mich für eine Testebene zu entscheiden, befinden sich meine Aussagen wahrscheinlich nicht auf der richtigen Testebene und ich muss sie verbessern.
2. Wenn ich ein Requirements-Management-Werkzeug nutze, kann ich überprüfen, ob alle Anforderungen verlinkt sind.
3. Indem ich Reviews mit Kollegen durchführe, kann ich sicherstellen, dass ich nichts vergessen habe.