DEFOSPAM ist ein Akronym zur strukturierten Überprüfung von Anforderungen, das sieben Prüfdimensionen bündelt: Definitionen, Features, Outcomes, Szenarien, Vorhersagen, Ambiguität und fehlende Elemente. Ziel ist es, Lücken, Widersprüche und Mehrdeutigkeiten in Anforderungsdokumenten frühzeitig aufzudecken. KI kann dabei als Ideengenerator dienen, ersetzt aber nicht die menschliche Überprüfung.
Das Wichtigste in Kürze
- Das Akronym DEFOSPAM steht für Definitionen, Funktionen, Ergebnisse, Szenarien, Vorhersagen, Ambiguität und fehlende Teile, und dient dazu, Anforderungen systematisch zu hinterfragen.
- Ungeklärte Definitionen wie “Kunde” oder “Bestellung” führen dazu, dass Entwickler und Tester dasselbe Dokument unterschiedlich verstehen, was Fehler erst spät im Projekt sichtbar macht.
- Anforderungen fungieren als Orakel: Wer aus einer Anforderung keine Vorhersage ableiten kann, was das System bei einer bestimmten Eingabe tun soll, kann weder testen noch entwickeln.
- KI eignet sich als Ideengenerator für Szenario-Ergebnis-Paare, die im Team übersehen werden, ist aber kein verlässlicher Ersatz für menschliche Überprüfung, weil sie halluziniert und Fragen falsch interpretiert.
- KI als Coach statt als Mentor einzusetzen bedeutet: nicht auf vollständige Antworten zu vertrauen, sondern ihre Fragen und Vorschläge als Denkanstoß zu nutzen, den man anschließend selbst bewertet.
Anforderungen prüfen heißt: die richtigen Fragen stellen
Anforderungen lassen sich systematisch hinterfragen, wenn man sie nicht nur liest, sondern gegen einen festen Fragenkatalog hält. Genau das ist die Idee hinter DEFOSPAM, einem Akronym, das Paul Gerrard vor über zehn Jahren entwickelt und in einem schmalen Buch zusammen mit Susan Windsor festgehalten hat.
Der Name entstand aus Zufall. Paul skizzierte die Methode in einer Stunde, schaute sich die Anfangsbuchstaben an und blieb bei einem Wort hängen, das niemand vergisst. Verkauft hat sich das Buch nie, eingesetzt hat es kaum jemand. Trotzdem trägt der Ansatz eine Logik, die für jeden Tester und jeden Entwickler brauchbar ist.
Der Hintergrund ist klassisch: Anforderungen lesen sich oft flüssig und wirken vollständig, sind es aber nicht. Beispiele beschreiben Software immer nur teilweise. Man bräuchte unendlich viele Beispiele, um ein System vollständig zu spezifizieren, und unendlich viele Tests, um es vollständig zu bewerten. Spezifikation anhand von Beispielen ist deshalb nur eine Teillösung.
Was bedeuten die Buchstaben in DEFOSPAM?
DEFOSPAM steht für eine Reihe von Prüffragen, mit denen sich Anforderungen aus verschiedenen Blickwinkeln durchleuchten lassen. Jeder Buchstabe markiert eine eigene Suchrichtung.
- D wie Definitionen: Begriffe wie Kunde, Produkt, Bestellung oder Fehler klären, bevor man weiterarbeitet.
- F wie Funktionen und Merkmale: Was kann das System, und wie lässt es sich in Funktionen bündeln?
- O wie Ergebnisse (Outcomes): Was tut das System tatsächlich, wenn man es füttert?
- S wie Szenarien: Welche Situationen führen zu welchen Ergebnissen?
- P wie Vorhersage (Prediction): Welches Verhalten lässt sich aus der Anforderung ableiten?
- A wie Ambiguität: Wo ist die Sprache oder die Logik mehrdeutig?
- M wie Missing: Was fehlt, an Szenarien, Daten oder Regeln?
Die Buchstaben S und O gehören eng zusammen. Ein Ergebnis ohne zugehöriges Szenario ergibt kaum Sinn, ein Szenario ohne Ergebnis ebenso wenig. Sinnvoll sind Szenario-Ergebnis-Paare nach dem Muster: wenn dies, dann das.
Warum Definitionen am Anfang stehen
Definitionen sind der Ausgangspunkt, weil die meisten Missverständnisse an unklaren Begriffen hängen. Leute lesen ein Anforderungsdokument, greifen sich Ideen heraus und hinterfragen die Wörter nie.
Über Jahre hat sich gezeigt: Die Gespräche, die entstehen, wenn man einer Definition wirklich auf den Grund geht, sind oft die wertvollsten. Was genau ist ein Kunde? Was ist eine Bestellung? Was ist ein Fehler? Dieselbe Unschärfe kennt das Testen selbst. Jeder trägt seine Lieblingsdefinition mit sich, die in der Branche nicht geteilt wird.
Sich auf einen Satz gemeinsamer Definitionen zu einigen, klingt langweilig und zeitaufwendig. Das ist es auch. Aber danach kommt deine Botschaft an, und du verstehst die Botschaft des anderen.
Die Anforderung ist dein Orakel
Die Vorhersage ist der Punkt, an dem eine Anforderung ihren eigentlichen Zweck erfüllt: Sie dient als Orakel. Wenn du A, B und C eingibst, soll das System D, E und F tun. Triffst du diese Vorhersage und liest sie aus dem Dokument, funktioniert die Anforderung als Wissensquelle.
Dasselbe Orakel nutzen beide Seiten. Der Tester leitet daraus erwartete Ergebnisse ab. Der Entwickler leitet daraus ab, was er bauen muss.
Ein perfektes Orakel existiert nicht. Es müsste ein riesiges, in mathematischer Logik formuliertes Dokument sein. In der Praxis arbeitet man deshalb mit Kompromissen und Abstrichen.
Genau hier wird die Tester-Haltung produktiv. Man kann sich ein vernünftiges Ergebnis vorstellen, findet es aber in der Anforderung nicht. Ein Dokument beschreibt etwa die Bestellverarbeitung mit allen Regeln, sagt aber nichts über ungültige Werte. Die Anforderung kennt nur “abgelehnt”. Abgelehnt zu werden ist eine Sache, aber unter bestimmten Umständen könnte ein Wert akzeptabel sein und unter anderen nicht. Stehen diese Regeln nicht im Dokument, weiß weder der Tester, was er prüfen soll, noch der Entwickler, was er bauen soll.
Indem du dich wie ein Tester verhältst und die Anforderungen kritisch betrachtest, hilfst du allen: den Entwicklern, den Nutzern und dir selbst. Paul Gerrard
Mehrdeutigkeit versteckt sich zwischen den Seiten
Mehrdeutigkeit tritt auf mehreren Ebenen auf, und die gefährlichste liegt nicht im einzelnen Wort. Auf der Sprachebene ist der Fall noch offensichtlich. Das Wort “Kunde” kann Neukunde oder Stammkunde meinen, Privat- oder Firmenkunde, hochwertig oder geringwertig. Ohne Einschränkung bleibt der Begriff unscharf.
Schwieriger sind die strukturellen Widersprüche über das Dokument verteilt. Zwei sehr unterschiedliche Szenarien führen zum selben Ergebnis, das eine auf Seite 23, das andere auf Seite 38. Niemand hat den Zusammenhang gesehen, weil die Stellen weit auseinander liegen.
Der umgekehrte Fall ist genauso heikel. Dasselbe Szenario erzeugt je nach Stelle im Dokument unterschiedliche Ergebnisse. Auf Seite 23 verhält sich das System so, auf Seite 43 anders. Es kann nicht beides stimmen. Solche Widersprüche zu finden verlangt, das ganze Dokument gleichzeitig im Kopf zu behalten, eine echte Anstrengung. Der Zeitaufwand kann sich lohnen.
Das Fehlende ist am schwersten zu sehen
Fehlende Teile sind die schwierigste Kategorie, weil man sich schwer vorstellt, was nicht da ist. Eine bestimmte Kombination von Eingaben taucht nirgends auf. Ein Datenfeld fehlt, etwa das Alter des Nutzers, das in einer Situation eigentlich relevant wäre.
Anforderungen können nie jede Eventualität abdecken. Das Dokument würde sonst ins Unermessliche wachsen. Deshalb geht es nicht um Vollständigkeit, sondern um Priorisierung: Die wichtigsten fehlenden Dinge bleiben die wichtigsten, und genau auf die musst du dich konzentrieren.
Hier liegt der Wert eines externen Anstoßes. Aus Erfahrung weiß man, dass eine bestimmte Situation behandelt gehört. Aber keine Erfahrung ist umfassend, vollständig und allwissend. Eine breitere Auswahl an Beispielen deckt mehr ab als das Gedächtnis eines einzelnen Teams.
KI als Coach für bessere Anforderungen
KI kann beim Durcharbeiten dieses Fragenkatalogs ein nützlicher Assistent sein, ohne die Arbeit zu ersetzen. Paul testet das gerade in Experimenten und baut einen Prototyp, um auszuloten, was geht.
Erste Beobachtungen sind konkret. Gibt man der KI einen Text, identifiziert sie benannte Entitäten, also Substantive, Handlungen und Aktivitäten, recht zuverlässig. Sie schlägt brauchbare Definitionen vor, vielleicht nicht perfekt, aber genug für den Einstieg. Sie erzeugt Szenario-Ergebnis-Paare und ordnet sie einander zu.
Eine gut wirkende Anforderung liefert dabei erstaunlich wenig Material. Sie setzt viel Implizites voraus, das ein Mensch ergänzen würde, das die KI aber nicht kennt. Aus einer Handvoll Paare wird auf Nachfrage schnell mehr. Bei einer E-Commerce-Anwendung weiß das Modell, dass es Bestandsgrenzen, Preisberechnungen und Rabatte gibt, und schlägt passende Szenarien vor. Aus fünf Beispielen werden ohne große Mühe acht weitere, und die meisten ergeben Sinn.
Das System lässt sich auch direkt befragen: nach sprachlichen Mehrdeutigkeiten, nach inkonsistenten Szenario-Paaren, nach fehlenden Situationen oder Daten. Es liefert eine Liste dessen, was es erkennt.
Vertrauenswürdig nein, hilfreich ja
KI ist beim Prüfen von Anforderungen ein nicht ganz perfekter Assistent, dem man nicht blind vertrauen darf. Die Ideen sind nicht garantiert fundiert. Du musst sie überprüfen, im Auge behalten, was das Modell tut, und jede gute Eingabe nutzen.
Die Stärke liegt im Gedächtnis, nicht im Denken. Das Modell merkt sich alles, rechnet zuverlässig und kennt, gemessen am Trainingsmaterial, mehr Fälle als jedes einzelne Teammitglied. Es ist nicht das beste Mitglied des Teams, es hat nur das bessere Gedächtnis. Denken, debattieren, echtes Infragestellen kann es kaum.
Seine Fehler ähneln menschlichen. Es übertreibt, halluziniert, missversteht eine Frage und beantwortet eine andere. Das verlangt Aufsicht.
Die produktivere Rolle ist die des Coaches, nicht des Mentors. Ein Mentor müsste alles über alles wissen und dich aus dem Schlamassel ziehen. Ein Coach stellt gute Fragen, macht Vorschläge und bringt dich dazu, tiefer nachzudenken. In dieser Funktion erreicht das Werkzeug vielleicht 80 Prozent dessen, was ein Team mit mehr Aufwand selbst schaffen würde. Das bringt dich weiter, löst aber nicht das ganze Problem.
Dasselbe gilt für generierten Code. Vertrauen die wenigsten ihm blind, doch er kann einen Großteil liefern. Wenn er deiner Anweisung entspricht und du weißt, was er tut, sparst du Zeit. Testen oder zumindest überprüfen musst du ihn trotzdem.
