Mit KI mehr Qualität bei Anforderungen

KI-gestütztes Requirements Engineering bezeichnet den gezielten Einsatz von KI-Systemen entlang des gesamten Anforderungsprozesses: von der Ermittlung über die Dokumentation bis zur Qualitätssicherung. Wirksame Prompts definieren Kontext, Scope und Anforderungsebene präzise und führen die KI schrittweise mit Feedback-Zyklen. Schwammige Formulierungen liefern schwache Ergebnisse, konkrete Vorgaben messbare, testbare Anforderungen.

Das Wichtigste in Kürze

• Gute Prompts für Requirements Engineering sind vier Seiten lang: Scope, Kontext, Rollenangabe, Schablonen und messbare Akzeptanzkriterien müssen explizit vorgegeben werden, sonst produziert die KI Quantität statt Qualität.
• KI-Systeme behaupten, bekannte Anforderungsschablonen zu kennen, liefern aber falsche Ergebnisse: wer die Schablone nicht als konkreten Input mitgibt, bekommt eine erfundene Variante zurück.
• Diagramme wie Aktivitäts- und Zustandsdiagramme sind beim agilen Arbeiten weggefallen, fehlen aber als Überbau für geschäftsprozessorientiertes Testen und sollten als Teil der Requirements wieder aufgebaut werden.
• Anforderungsqualität für Tests erfordert messbare Nicht-Funktionale Anforderungen mit konkreten Werten statt schwammiger Formulierungen wie “übersichtlich” oder “performant”.

Gute Anforderungen sind die Voraussetzung fürs Testen

Ohne Anforderungen lässt sich kaum testen, jedenfalls kein anforderungsbasiertes Testen. Wer keine saubere Testbasis hat, leitet Testfälle aus dem Bauchgefühl ab und hofft, das Richtige zu prüfen. Genau hier liegt der Knackpunkt: Testqualität hängt direkt an der Qualität der Anforderungen.

Andreas Guenther von den Sophisten beschreibt das Ziel klar. Es geht darum, KI einzusetzen, um eine bestmögliche Testbasis herzustellen, statt aus Testsicht in eine inhaltliche Leere zu blicken. Eine messbare, testbare Anforderung erspart später viel Rätselraten.

Requirements Engineering deckt dabei mehr ab als das Niederschreiben von User Stories. Ermitteln, Dokumentieren, Validieren und Verwalten gehören dazu. Der zeitintensivste Teil ist oft nicht die Dokumentation, sondern das Ermitteln und Validieren: an die verstreuten Informationen in Köpfen, Dokumenten und Bauchgefühlen überhaupt erst heranzukommen.

Warum Diagramme zurück in die Anforderungen gehören

Mit der Agilisierung sind viele hart erarbeitete Diagramme verschwunden. An ihre Stelle traten Epic, Feature, User Story, Akzeptanzkriterien: Text, Text und noch mehr Text. Andreas hält das für eine schlechte Idee, denn ein Bild sagt mehr als tausend Worte.

Der Überbau eines Systems lässt sich mit Sprache allein schlecht abbilden. Use-Case-Gerüste, Aktivitätsdiagramme und Zustandsdiagramme zeigen, welche Prozesse zusammenhängen. Diese Struktur ist die Grundlage, um nicht nur einzelne Testschritte abzuleiten, sondern ganze Testszenarien und Testprozeduren.

In der Praxis sind etwa 70 bis 80 Prozent der Anforderungen sprachlich formuliert, klassisch oder agil. Der tragende Rest ist Struktur, abgebildet in Diagrammen. Ob UML oder bei technischen Systemen SysML, spielt dabei eine untergeordnete Rolle. Wichtig ist, dass überhaupt Struktur entsteht.

Was KI im Requirements Engineering wirklich leistet

KI liefert auf jede Frage zunächst viel Output, und das macht Eindruck. Ob dieser Output Qualität hat, ist eine andere Frage. Wer ein bisschen genauer analysiert, stellt fest: Das meiste ist erst einmal Quatsch, und die KI halluziniert.

Der Wert entsteht erst, wenn nicht Quantität, sondern Qualität das Ziel ist. KI ist stark darin, Dinge zu verknüpfen, an die man selbst nicht gedacht hat, und so Features sinnvoll zu schneiden oder Innovationen einzubringen. Aus einem ersten Interview oder einer Product Vision lässt sich mit einem guten Prompt ein strukturiertes Backlog füllen.

Die Sophisten haben dafür eine zweistellige Zahl konkreter Einsatzszenarien ausgearbeitet, aus einer noch deutlich größeren Sammlung von rund 60 bis 70 definierten Szenarien. Abgedeckt wird der gesamte Prozess: Ermitteln, Dokumentieren, Validieren, Verwalten. KI eignet sich auch fürs Brainstorming und für die Ermittlung neuer Anforderungen.

Wie ein guter Prompt fürs Requirements Engineering aussieht

Ein guter Prompt arbeitet vom Groben ins Feine, genau wie ein klassisches Requirements-Training. Erst kommt der Scope, dann der Kontext, dann die einzelnen Anforderungsebenen.

Das beginnt mit der Frage nach dem Testobjekt und dem Kontext. Reden wir über die App allein oder inklusive Server? Über eine Komponente oder das Gesamtsystem? Über funktionale oder nicht funktionale Anforderungen? Diese Einordnung muss man der KI Schritt für Schritt beibringen.

Präzise Begriffe sind dabei der Hebel. “Generiere mal Anforderungen” ist zu unscharf. Erst die Festlegung auf fachliche, System- oder Komponentenebene, auf funktional oder nicht funktional, macht den Output brauchbar. Bei nicht funktionalen Anforderungen heißt das: keine schwammigen Wünsche wie “übersichtlich” oder “performant”, sondern konkrete, messbare Werte.

Genau hier liegt der Unterschied zwischen viel Text und echter Requirements-Qualität. Der Prompt, den die Sophisten im Workshop schrittweise aufbauen, umfasst rund vier Seiten. Das Ergebnis sind User Stories nach Schablone, Akzeptanzkriterien und testbare nicht funktionale Anforderungen.

Da muss man mit einem Prompt die KI etwas trietzen. Aber es wirkt. Andreas Guenther

Arbeite mit der KI wie mit einem neuen Mitarbeiter

Die KI lässt sich behandeln wie ein neuer Mitarbeiter, der Wissen mitbringt, aber Anleitung braucht, wo er es abruft. Statt alles auf einmal zu generieren, lässt man die KI in Feedback-Zyklen arbeiten: erst fragen, ob das Zwischenergebnis passt, dann den nächsten Schritt gehen.

Breno Pinheiro empfiehlt, die KI gezielt in eine Rolle zu setzen, etwa als Product Owner oder Tester. Damit greift sie auf den passenden Teil ihrer Trainingsdaten zu und liefert Output aus der gewünschten Perspektive. Das spart Schleifen, auch wenn ein paar gezielte Schleifen sinnvoll bleiben.

Ein Glossar mit fest definierten Domänenbegriffen reduziert schwammige Formulierungen. Mitgelieferte Vorgaben, etwa eine Requirements Guideline als Upload, geben der KI den Rahmen, in dem sie arbeiten soll.

Vorsicht bei Quellen: KI lügt eiskalt

KI generiert immer eine Antwort, aber nicht immer eine ehrliche. Auf die Frage nach einer konkreten Schablone behauptet das System, sie zu kennen, und die Lüge fliegt erst auf, wenn man nach dem genauen Aufbau fragt.

Deshalb gehört die Quelle in den Prompt. “Generiere eine Anforderung nach Schablone” reicht nicht, denn nach welcher Schablone? Wer eine bestimmte Vorlage will, muss sie mitliefern oder hochladen, statt sich auf das vermeintliche Wissen der KI zu verlassen.

Wenn der erste Output nicht passt, hilft Hartnäckigkeit: die Schablone erneut vorgeben, präzise nachjustieren, die Schleife drehen. Mit genug konkreten Vorgaben entsteht am Ende belastbare Requirements-Qualität.

Diagramme aus Text: der Umweg über PlantUML

Textbasierte KI-Systeme verweigern oft die direkte Grafikausgabe und erklären, sie seien nur textbasiert. Der Ausweg: PlantUML-Code anfordern, denn der ist ebenfalls Text.

Den generierten PlantUML-Code lässt man anschließend durch einen Compiler laufen und erhält daraus ein Diagramm. So entstehen Ablaufdiagramme und andere Darstellungen über einen Zwischenschritt, auch wenn die KI keine Grafik direkt liefert. Bei vielen Elementen lohnt ein kurzer Blick, ob wirklich alles gebraucht wird.

Welches KI-Tool eignet sich am besten?

Ein klarer Spitzenreiter fürs Requirements Engineering lässt sich nicht ausmachen. Über die Zeit haben sich die Tools mit Updates eher zum Positiven entwickelt, aber kein System sticht grundsätzlich heraus.

Die gängigen Allrounder lassen sich für fast alles nutzen, wenn man den Prompt gezielt anpasst. Manche Systeme sind für Bilder, Präsentationen oder Story Maps besser geeignet, doch die Auswahl ist eher Präferenz. Entscheidender als das Tool ist die Frage der Vertraulichkeit.

Der wichtigste Hebel sitzt nicht im Tool, sondern in den Daten. Je mehr gute Anforderungen als Trainingsbasis vorliegen, desto besser versteht die KI, was das Unternehmen macht und was typische Anforderungen auf den jeweiligen Ebenen sind. Interne Projekte bleiben oft grob, externe Projekte mit Festpreis gehen tiefer. Ohne diese Information rät die KI am Ziel vorbei.

Wie du in das Thema einsteigst

Ein einfacher Startpunkt ist ein Prompting-Leitfaden mit Schritt-für-Schritt-Hinführung. Ein solcher Two-Pager zeigt, worauf es beim Prompten ankommt: Scope definieren, Kontext setzen, Rollen vergeben, präzise Begriffe verwenden.

Wer tiefer einsteigen will, findet in einem Buch der Sophisten zum Einsatz von KI im Requirements Engineering eine Sammlung erprobter Einsatzszenarien. Es bündelt nicht alle der über 70 getesteten Szenarien, sondern die mit dem besten praktischen Nutzen, jeweils mit Beispielen und der Diskussion, was gut oder schlecht ist und wie man es verbessert. Das Buch erscheint im dpunkt.verlag.