KI im Requirements Engineering braucht präzise Prompts

KI-gestütztes Requirements Engineering, auch KI-basierte Anforderungsanalyse genannt, 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 können rund vier Seiten umfassen: 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-basierte Anforderungsanalyse 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 rund 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.

Häufig gestellte Fragen

Was passiert beim Testen, wenn keine sauberen Anforderungen vorliegen?

Ohne Anforderungen gibt es kein anforderungsbasiertes Testen. Wer keine saubere Testbasis hat, leitet Testfälle aus dem Bauchgefühl ab und hofft, das Richtige zu prüfen. Die Testqualität hängt damit direkt an der Qualität der Anforderungen. Eine messbare, testbare Anforderung erspart später viel Rätselraten, etwa bei nicht funktionalen Anforderungen mit konkreten Werten statt Wünschen wie “übersichtlich”.

Reichen User Stories und Akzeptanzkriterien aus, um ein System vollständig zu beschreiben?

Nein. Etwa 70 bis 80 Prozent der Anforderungen sind sprachlich formuliert, klassisch oder agil. Der tragende Rest ist Struktur: Use-Case-Gerüste, Aktivitätsdiagramme, Zustandsdiagramme. Sie zeigen, welche Prozesse zusammenhängen, und bilden die Grundlage für ganze Testszenarien und Testprozeduren statt nur einzelner Testschritte. Ob UML oder SysML genutzt wird, ist zweitrangig.

Warum wirkt der Output von KI-Systemen bei Anforderungen oft besser, als er ist?

KI liefert auf jede Frage zunächst viel Text, und Menge macht Eindruck. Bei genauerer Analyse zeigt sich, dass vieles davon Quatsch ist und das System halluziniert. Nutzen entsteht erst, wenn Qualität das Ziel ist: KI verknüpft Dinge, an die man selbst nicht gedacht hat, schneidet Features sinnvoll oder füllt aus einer Product Vision ein strukturiertes Backlog.

Wie ausführlich muss ein Prompt sein, damit brauchbare Anforderungen herauskommen?

Deutlich ausführlicher als ein Einzeiler. Der Prompt, den die Sophisten im Workshop schrittweise aufbauen, umfasst rund vier Seiten. Er arbeitet vom Groben ins Feine: erst Scope und Testobjekt, dann Kontext, dann die Anforderungsebene, also fachlich, System oder Komponente, funktional oder nicht funktional. Das Ergebnis sind User Stories nach Schablone, Akzeptanzkriterien und testbare nicht funktionale Anforderungen.

Bringt es etwas, der KI eine bestimmte Rolle zuzuweisen?

Ja. Breno Pinheiro empfiehlt, die KI gezielt als Product Owner oder Tester agieren zu lassen. Sie greift dann auf den passenden Teil ihrer Trainingsdaten zu und antwortet aus der gewünschten Perspektive, was Schleifen spart. Ergänzend helfen ein Glossar mit fest definierten Domänenbegriffen und mitgelieferte Vorgaben wie eine Requirements Guideline als Upload.

Kennt eine KI die gängigen Anforderungsschablonen zuverlässig?

Nein. Auf die Frage nach einer konkreten Schablone behauptet das System, sie zu kennen, und liefert eine erfundene Variante. Auffällig wird das erst, wenn man nach dem genauen Aufbau fragt. Wer eine bestimmte Vorlage will, muss sie als Input mitgeben oder hochladen. Passt der erste Output nicht, hilft nur, die Schablone erneut vorzugeben und nachzujustieren.

Wie kommt man an Diagramme, wenn das KI-System nur Text ausgibt?

Über den Umweg PlantUML. Textbasierte Systeme verweigern oft die direkte Grafikausgabe, erzeugen aber PlantUML-Code, weil auch der Text ist. Dieser Code läuft anschließend durch einen Compiler, der das Diagramm rendert. So entstehen Ablaufdiagramme über einen Zwischenschritt. Bei vielen Elementen lohnt ein Blick, ob wirklich alles gebraucht wird.

Worauf kommt es bei der Auswahl eines KI-Systems fürs Requirements Engineering an?

Ein klarer Spitzenreiter lässt sich nicht ausmachen. Die gängigen Allrounder decken fast alles ab, wenn der Prompt gezielt angepasst wird; einzelne Systeme spielen ihre Stärken bei Bildern, Präsentationen oder Story Maps aus. Entscheidender als das Tool ist die Vertraulichkeit, also offenes oder geschlossenes System, und die Datenbasis: Je mehr gute Anforderungen als Input vorliegen, desto treffsicherer die Ausgabe.