Die Inspektion der Spezifikation

„Überprüfe bitte kurz mal die Spezifikation, vielleicht fällt Dir etwas auf.“ – Kennen Sie solche Aufgaben? Bestimmt finden Sie diverse Widersprüche, Lücken oder Fehler in der Spezifikation, wenn Sie nur lange genug suchen. Wie hilfreich eine solche Vorgehensweise ist, hängt jedoch vom Zufall ab. 15% aller Softwarefehler werden ausgeliefert und ein Großteil dieser Fehler steckt bereits in der Spezifikation. Anforderungen von Kunden werden falsch verstanden, Anwendungsfälle unvollständig beschrieben, verschiedene Begriffe für dasselbe verwendet und Begriffe unterschiedlich interpretiert. Diese Probleme wirken sich natürlich nicht nur auf Spezifikationen aus, sondern auch auf Architekturentwürfe, Testfälle, sämtliche schriftlichen Zwischenergebnisse der Softwareentwicklung und den Quellcode.

Best Practices für erfolgreiche Inspektionen

Die Qualität der Ergebnisse einer Inspektion ist von der Qualität der gestellten Fragen abhängig. Eine einfache Sichtprüfung im Sinne von „Überprüfe bitte kurz mal die Spezifkation, vielleicht fällt Dir etwas auf.“ muss subjektiv ausfallen. Wissenschaftliche Untersuchungen haben gezeigt, dass die Ergebnisse einer Inspektion nie ganz vollständig sind. Niemand findet alle Fehler. Stets werden verschiedene Ungenauigkeiten, Widersprüche oder Fehler identifiziert. Und sogar derselbe Leser wird bei verschiedenen Durchgängen durch dieselbe Spezifkation nicht dieselben Punkte entdecken. Daraus erfolgt natürlich nicht, dass die Inspektion einer Spezifikation nutzlos wäre. Im Gegenteil: sie deckt frühzeitig Fehler auf, die sonst durchs Projekt transportiert würden, anstatt diese frühzeitig zu beheben. Damit eine Inspektion der Spezifikation bestmögliche Ergebnisse liefert, empfehle ich sechs Best Practices:

1. Eine eindeutige Zieldefinition:

Definieren Sie zu Beginn ein klares Ziel. Steht in einer ersten Prüfung die Vollständigkeit des Projektumfangs im Vordergrund und die Details werden anschließend schrittweise erarbeitet? Oder soll die Inspektion eine letzte Qualitätssicherung vor der Implementierung sein und möglichst alle abnahmerelevanten Fehler aufdecken?

2. Die Verwendung von Checklisten

Bei der Fehlersuche in Inspektionen haben sich Checklisten mit Ja-Nein-Fragen bewährt. Beispiele:

• Ist ein Use-Case-Diagramm enthalten?
• Sind die Namen der Stakeholder in Kapitel 3 konsistent mit den Namen der Aktoren in Kapitel 4?
• Sind alle Fehlerfälle abgedeckt?

Lautet die Antwort auf eine Frage „Ja“, dann ist alles in Ordnung, lautet sie „Nein“ 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

Genau genommen ist eine Checkliste eine eindimensionale Darstellung eines zweidimensionalen Vorgangs: Mehrere Kapitel oder Inhalte des Dokuments werden gegen eine Liste von Qualitätskriterien geprüft. Ich empfehle gerne, kapitelweise vorzugehen und für jedes Kapitel nacheinander die Kriterien zu prüfen. Meist sind Kapitel oder Diagramme so komplex, dass Sie sich erst hineindenken müssen, bevor eine qualifizierte Beurteilung möglich ist.

In der Fachliteratur wird häufig oft empfohlen, dass Checklisten nur ein bis zwei Seiten umfassen sollten, doch meine Erfahrungen sind andere. Meine Checklisten für Lastenheft-Vorlagen mit zehn Kapiteln umfassen fünf bis zehn Seiten. Eine Liste abstrakter Qualitätskriterien wie „vollständig“ oder „konsistent“ ist an sich gut, aber das Ergebnis der Inspektion fällt in der Praxis dennoch subjektiv und willkürlich aus. Besser ist es, diese Kriterien passend für die Vorlage zu konkretisieren. Dabei vermehren sich die Kriterien üblicherweise. Werfen wir einen beispielhaften Blick auf „Konsistenz“: Die Inhalte eines Kapitels sollen untereinander und gleichzeitig mit mehreren anderen Kapiteln konsistent sein. Für Experten ist das Herunterbrechen relativ 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 Konsistenzbeziehungen zwischen ihnen aussehen. Ich meiner Checkliste habe ich dieses Wissen konsolidiert und kann es bei jeder Inspektion einfach wiederverwenden. Ist das Kriterium konkret genug formuliert, kann es schnell abgearbeitet werden. Ich würde mir erhoffen, dass auch die Ergebnisse wiederholbarer sind und weniger vom Inspektor abhängen, doch das hat sich bisher so nicht bestätigt. Die klaren Kriterien sind manchmal doch subjektiv. Wie wollen Sie zum Beispiel eine Frage nach der Verständlichkeit wie: „Sind die Namen aller Use Cases selbsterklärend?“ objektiv beantworten?

3. Keine Hoffnung auf Vollständigkeit der Fehlerliste

Geht es darum, zunächst nur die gröbsten Widersprüche, Lücken oder Fehler in einer Spezifikation zu finden, genügt eine schnelle Inspektion durch einen einzelnen Experten. Benötigen Sie aber eine detaillierte Inspektion, werden auch ein halbes Dutzend unabhängiger Gutachten nicht alle Widersprüche, Lücken oder Fehler aufdecken. Eine Spezifikation ist ein derart komplexes Dokument mit unzähligen Abhängigkeiten zwischen den Inhalten, dass es menschenunmöglich ist, alle Fehler zu finden. Leider kann ich Ihnen keine Hoffnung auf die Vollständigkeit einer Fehlerliste machen. Deswegen ist auch nach der Inspektion eine weitere Qualitätssicherung nötig.

4. Das Arbeiten mit mehreren Inspektoren

Es gibt semantische und syntaktische Inspektionskriterien: Die Syntax bezieht sich auf die verwendeten Elemente wie Wörter oder Modellsymbole, sowie erlaubte Kombinationen, also die Grammatik von Text und grafischen Notationen. Diese Syntax kann ein externer Spezifikationsexperte sehr gut bewerten, häufig sogar ohne den Inhalt der Spezifikation vollständig zu verstehen. Mit den semantischen Kriterien prüfen Sie die inhaltliche Qualität, beispielsweise die Vollständigkeit der Anforderungen. Diese lassen sich am besten durch Stakeholder oder Branchenkenner beurteilen. Da Spezifikations- und Branchenexpertise oft auf verschiedene Personen verteilt sind, sollten mehrere Inspektoren die Spezikation beurteilen. So decken Sie Kriterien kompetent ab und erreichen eine bessere Vollständigkeit der Ergebnisse.

5. Die Wiederholung der Inspektion

Eine Spezifikation sollte mehrmals qualitätsgesichert werden. In der Praxis ändern sich Anforderungen relativ häufig. So positiv diese Änderungen auch sind, im Sinne der Spezifikation gefährden sie die Qualität und Konsistenz. Zusätzlich entstehen zu verschiedenen Zeitpunkten unterschiedliche Fragen. Durch die Wiederholung der Inspektion erhalten Sie eine neue Chance, Widersprüche, Lücken oder Fehler zu entdecken. Denken Sie daran: 15% aller Software-Fehler werden ausgeliefert und ein Großteil dieser Fehler steckt bereits in der Spezifikation.

6. Eine Automatisierung ist schwierig

Wäre es nicht toll, wenn Sie auf Knopfdruck und nach wenigen Sekunden eine Fehlerliste zu Ihrer Spezifikation erhalten könnten? Eine Unterstützung durch automatisierte Werkzeuge klingt wirklich verlockend. Leider haben mich die von mir bis heute getesteten Werkzeuge nicht überzeugt. Nicht alle Qualitätskriterien lassen sich maschinell überprüfen. Lediglich syntaktische Kriterien, für die Sie einfache Regeln definieren können, lassen sich so identifizieren. Und selbst dann erhalten Sie noch zu viele „falsche Fehler“, also Fehlermeldungen bezüglich Stellen, die zwar die Kriterien eines Fehlers erfüllen, aber trotzdem korrekt sind. Dies führt zu hohem manuellen Aufwand, denn Sie müssen entscheiden, ob die angezeigten Fehler tatsächlich behoben werden müssen oder ob es sich doch nur um Falschmeldungen handelt? Nur einfache Prüfungen sind relativ treffsicher, beispielsweise die Suche nach Sätzen mit zu vielen Wörtern oder nach verbotenen Begriffen wie „jederzeit“. Listen mit solchen verbotenen Begriffe finden Sie unter anderem im Standard ISO/IEC/IEEE 29148:2011 oder im CPRE Foundation Level¹. Meine Empfehlung: Definieren Sie zuerst Ihre Checkliste und prüfen Sie anschließend, ob Sie einzelne Kriterien mit einem Werkzeug überprüfen können. Es verursacht mehr Kosten als Nutzen, wenn Sie alle Prüfmöglichkeiten eines Werkzeugs durchspielen und dann versuchen herauszufinden, ob Ihnen die Fehlerliste wirklich nutzt.

Fazit

Die Inspektion einer Spezifikation macht Aufwand. Ein Aufwand, der sich lohnt, gerade wenn Sie ihn mit den Kosten für die Beseitigung von ausgelieferten Softwarefehlern vergleichen. Fehlerhafte Software reduziert die Kundenzufriedenheit und die Kundenloyalität, gefährdet das Produkt- oder gar Unternehmensimage. Das wollen Sie sicherlich vermeiden. Und zuletzt ein persönlicher, nicht ganz uneigennütziger Tipp: Wenn Sie eine Spezifikation prüfen wollen, nutzen Sie einen externen Profi. Mit den genannten Best Practices kann er Sie sehr individuell unterstützen. Passend zu Ihrer Situation entwickelt er eine passende Checkliste mit zahlreichen konkreten Verbesserungsvorschlägen. Natürlich wird auch der Experte nicht alle Fehler aufdecken, jedoch ist eine solche Inspektion immer günstiger als Fehler erst nach der Auslieferung zu beseitigen.

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

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

Im t2informatik Blog hat Dr. Andrea Herrmann weitere Beiträge veröffentlicht, u. a.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.