Mit Inspektion zur guten Spezifikation

by | 07.11.2018 | Requirements Engineering

„Guck mal kurz über die Spezifikation drüber, ob dir was auffällt“, sagt der Kollege und verschwindet wieder zur Tür hinaus.

Mit so einer Vorgabe kann man kurz oder lange auf das Dokument starren und darüber meditieren, ob einem etwas auffällt. Bestimmt springt irgendetwas ins Auge. Wie viel und ob es hilfreich ist, das hängt leider vom Zufall ab. 15% aller Software-Fehler werden ausgeliefert, und der Großteil dieser Fehler steckte schon in der Spezifikation. Da waren Anforderungen des Kunden missverstanden worden, Sonderfälle nicht vollständig beschrieben, verschiedene Begriffe für dasselbe verwendet und dergleichen. Inspizieren kann man natürlich außer Anforderungsdokumenten auch Architekturentwürfe, Quellcode, Testfälle und alle anderen schriftlichen Zwischenergebnisse der Software-Entwicklung.

Die Qualität der Inspektion

Bei der Inspektion hängt die Qualität der Ergebnisse – wie so oft – von der Qualität der gestellten Fragen ab. Eine spontane Sichtprüfung im Stil von „grob drüber gucken, ob was auffällt“ fällt selbstverständlich subjektiv und situationsabhängig aus, sozusagen „nach Laune des Gutachters“. Wissenschaftliche Selbstversuche haben gezeigt, dass das Ergebnis einer Inspektion nie ganz vollständig ist – niemand findet alle Fehler -, jeder stolpert über andere Defekte und sogar derselbe Leser wird bei verschiedenen Durchgängen durch denselben Text nicht wiederholbar exakt dieselben Stellen anstreichen.

Natürlich folgt daraus auf gar keinen Fall, dass man Inspektionen gleich bleiben lassen könnte. Sie decken frühzeitig Fehler auf, die man sonst noch eine Weile durchs Projekt verschleppt hätte, statt sie zu beheben. Damit die Inspektion die bestmöglichen Ergebnisse einbringt, empfehle ich Folgendes:

Sechs Best Practices für eine erfolgreiche Inspektion

  1. Zieldefinition: Zuerst muss das Ziel klar sein. Soll die Inspektion als letzte Qualitätssicherung vor der Implementierung möglichst alle abnahmerelevanten Fehler aufdecken? Oder soll in einer ersten Prüfung die Vollständigkeit des Projektumfangs sichergestellt werden, ohne zu sehr auf die Details zu achten?
  2. Checkliste: Klare Kriterien unterstützen die Fehlersuche. Bewährt haben sich Checklisten, bei denen die zu prüfenden Kriterien als Ja-Nein-Fragen formuliert sind wie zum Beispiel: „Ist ein Use-Case-Diagramm enthalten?“ oder „Sind die Namen der Stakeholder in Kap. 2 konsistent mit den Namen der Aktoren in Kap. 3?“ oder „Sind alle Fehlerfälle abgedeckt?“ Lautet die Antwort „Ja“, dann ist alles in Ordnung. Andernfalls besteht Verbesserungsbedarf. Die Qualitätskriterien können Sie aus relevanten Standards entnehmen. Ich verwende für Anforderungen den Standard ISO/IEC/IEEE 29148:2011 “Systems and software engineering — Life cycle processes — Requirements engineering”. Dieser nennt die folgenden Qualitätskriterien an Anforderungen: nötig, implementierungsunabhängig, eindeutig, konsistent, vollständig, atomar, realisierbar, verfolgbar, verifizierbar.Eine solche Checkliste ist genau genommen eine eindimensionale Darstellung eines zweidimensionalen Vorgangs: Mehrere Kapitel oder Inhalte (z.B. Text und Bild) des Dokuments sollen gegen eine Liste von Qualitätskriterien geprüft werden. Ich empfehle, jeweils kapitelweise zu arbeiten und für jedes Kapitel nacheinander die Kriterien zu prüfen. Erst dann das nächste Kapitel. Die Kapitel oder Diagramme sind ja meist etwas komplexer, so dass man sich erst hineindenken muss, bevor man sie beurteilen kann. In der Fachliteratur wird oft empfohlen, dass eine Checkliste nur ein bis zwei Seiten umfassen solle. Das sehe ich anders! Meine Checklisten für Lastenheft-Vorlagen mit zehn Kapiteln umfassen fünf bis zehn Seiten. Warum? Eine Liste abstrakter Qualitätskriterien wie z.B. „vollständig“ oder „konsistent“ ist zwar besser als gar nichts. Aber das Inspektionsergebnis gerät dann leider willkürlich und subjektiv. Besser ist es, diese Kriterien passend für die Vorlage zu konkretisieren. Dabei vermehren sie sich üblicherweise. Beispielsweise für die Konsistenz: Die Inhalte eines Kapitels sollen untereinander konsistent sein, gleichzeitig aber auch mit mehreren anderen Kapiteln. Das Herunterbrechen ist für den Experten einfach, denn es ist aus Standards und Fachliteratur bekannt, was zu einer vollständigen textuellen Anforderung oder einem vollständigen Use-Case-Diagramm gehört oder wie die Konsistenzbeziehungen zwischen ihnen sein sollen. Ich habe dieses Wissen in meine Checkliste konsolidiert und kann es bei jeder Inspektion effizient wiederverwenden. Ist das Kriterium konkret genug formuliert, kann es schnell abgearbeitet werden. Man würde sich erhoffen, dass dann die Ergebnisse auch wiederholbarer sind und weniger vom Inspektor abhängen. Dies hat sich bisher aber so nicht bestätigt. Die klaren Kriterien sind manchmal doch subjektiv, z.B. eine Frage nach der Verständlichkeit wie: „Sind die Namen aller Use Cases selbsterklärend?“.
  3. Keine Hoffnung auf Vollständigkeit der Fehlerliste: Geht es darum, zunächst nur die gröbsten Fehler zu finden, genügt eine schnelle Inspektion durch einen einzelnen Experten. Soll es vollständig werden, können aber auch ein halbes Dutzend unabhängiger Gutachten nicht alle Fehler abdecken. Kein Grund, jemanden zu feuern! Eine Spezifikation ist ein derart komplexes Dokument mit vielfältigen Querabhängigkeiten zwischen den Inhalten, dass es menschenunmöglich ist, alle Fehler zu finden. Darum ist auch nach der Inspektion noch weitere Qualitätssicherung nötig.
  4. Mehrere Inspektoren: Es gibt semantische und syntaktische Inspektionskriterien: Die Syntax bezieht sich auf die verwendeten Elemente (z.B. Wörter, Modellsymbole) und deren erlaubte Kombinationen, also die Grammatik von Text und grafischen Notationen. Diese kann ein externer Spezifikationsexperte sehr gut bewerten, oft sogar, ohne den Inhalt komplett zu verstehen. Die semantischen Kriterien prüfen die inhaltliche Qualität, beispielsweise die Vollständigkeit der Anforderungen. Diese kann nur ein Stakeholder oder ein Branchenkenner beurteilen. Da oft Spezifikations- und Branchen-Expertise auf verschiedene Personen verteilt sind, legt allein dies schon die Beteiligung mehrerer Inspektoren nahe, um alle Kriterien kompetent abzudecken. Ein weiteres Argument ist eine bessere Vollständigkeit der Ergebnisse.
  5. Wiederholung: Ein Dokument sollte mehr als einmalig qualitätsgesichert werden. Nicht nur darum, weil wiederholte Änderungen die Qualität und Konsistenz gefährden, sondern auch weil zu verschiedenen Zeitpunkten unterschiedliche Fragen anstehen und man bei der vorherigen Runde höchstwahrscheinlich Fehler übersehen hat. Bei der Wiederholung erhält man eine neue Chance.
  6. Automatisierung: Eine Unterstützung durch automatisierte Werkzeuge klingt verlockend: ein Knopfdruck und nach wenigen Sekunden erhalten wir eine Fehlerliste. Bisher haben mich die von mir getesteten Werkzeuge leider nicht überzeugt. Nicht alle Qualitätskriterien kann man maschinell prüfen, sondern nur diejenigen syntaktischen Kriterien, für die sich eine Regel definieren lässt. Und selbst dann erhält man noch zu viele „falsche Fehler“, also Fehlermeldungen bezüglich Stellen, die zwar die Kriterien eines Fehlers erfüllen, aber trotzdem korrekt sind. Auch wenn man automatisch in Sekunden eine Liste von hundert Fehlern erhält, muss man dann doch von Hand prüfen, ob diese auch tatsächlich behoben werden müssen oder Falschmeldungen sind. Nur recht schlichte Prüfungen sind treffsicher genug, um effizienter als eine händische auszufallen, z.B. die Suche nach Sätzen mit zu vielen Wörtern oder nach verbotenen Begriffen wie „jederzeit“. Solche Listen mit verbotenen Wörtern finden Sie in der Requirements Engineering Fachliteratur, beispielsweise im Standard ISO/IEC/IEEE 29148:2011 und im CPRE Foundation Level [1]. Meine Empfehlung: Definieren Sie zuerst Ihre Checkliste und prüfen Sie anschließend, ob Sie einzelne Kriterien an ein Werkzeug delegieren können. Es verursacht mehr Kosten als Nutzen, wenn Sie einfach so alle Prüfmöglichkeiten eines Werkzeugs durchspielen und dann versuchen herauszufinden, ob der Datenwust Ihnen nutzt.

Und zuletzt ein nicht ganz uneigennütziger Tipp: Lassen Sie doch einen externen Profi drüber schauen, ob ihm etwas auffällt. Passend zu Ihrer Arbeitsfrage entwickelt er / sie für Sie die passende Checkliste und befüllt sie gleich mit zahlreichen konkreten Verbesserungsvorschlägen. Natürlich wird auch der Expert nicht alle Fehler aufdecken, jedoch ist eine solche Inspektion immer ihren Aufwand wert.

 

Hinweise:

[1] Informationen zum CPRE Foundation Level finden Sie unter http://www.ireb.org.