Alles rund um die Qualitätssicherung von Lastenheften

Prozess-Reviews

In diesem Beitrag möchte ich Prozess-Reviews beschreiben. Dieser Review-Typ bzw. das Audit ist für das gesamte Entwicklungsprojekt entscheidend.

Das Prozess- oder Reifegrad-Review weist die Entwicklungsreife eines Projekts nach. Dabei geht es nicht mehr um den Inhalt der Ergebnisse, sondern um den Nachweis der zu erbringenden Arbeitsergebnisse, also zum Beispiel Spezifikationen, Planungsdokumente, Testdurchführungen etc. Als Basis dienen hier meist Prozessreifegradmodelle wie z.B. SPICE oder CMI. Weiterlesen

Freigabe-Reviews für Lastenhefte – Ergebnisse im Team freigeben

Für ein gelungenes Lastenheft sind Reviews meiner Erfahrung nach unerlässlich. Ich habe bereits über die allgemeinen Vorteile von Reviews und die spezielle Form der Peer Reviews berichtet. Kommen wir nun zu den Freigabe-Reviews.

Im Gegensatz zu Peer Reviews ist dieser Typ Geheimwaffe deutlich formaler. Ein Freigabe-Review wird oft in einer Gruppe von Entwicklungsingenieuren durchgeführt. Das bedeutet, sie müssen geplant, vor- und nachbereitet werden. Welche Schritte genau das beinhaltet, möchte ich im Folgenden erläutern. Weiterlesen

Peer Reviews – strukturiertes Feedback von Kollegen

Ich habe bereits in anderen Beiträgen über Reviews und ihre Funktionen berichtet: Zwischenergebnisse und Prozesse absichern, Feedback erhalten, Ergebnisse freigeben – ich bezeichne Reviews nicht umsonst als Geheimwaffe.

Im Folgenden möchte ich ein bisschen tiefer in das Thema Peer Reviews einsteigen. Der Begriff kommt eigentlich aus dem wissenschaftlichen Umfeld und geht bis ins 17. Jahrhundert zurück. Das Konzept fokussiert seitdem die Begutachtung von Ergebnissen durch einen gleichwertigen Kollegen – und lässt sich bei Lastenheften natürlich ebenso gut anwenden. Weiterlesen

Geheimwaffe Reviews

Ich nutze diese Bezeichnung ganz bewusst, denn Reviews sind bei unserer Arbeit enorm wirkungsvoll. Warum das so ist und wie sie effektiv eingesetzt werden können, möchte ich im Folgenden näher beschreiben.

Feedback von Profis

Zunächst einmal sind wir „Geistesleister“: Viele unserer Ergebnisse als Ingenieure sind Kopfleistungen. Diese dokumentieren wir in Spezifikationen und erstellen Modelle, entwerfen Planungen, definieren Baugruppen, schreiben Quellcodes oder konstruieren Komponenten. Weiterlesen

Drei Kriterien, um die Qualität eines Lastenheftes sicherzustellen

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.