Wie ich KI als Sparringspartner im Requirements Engineering nutze

Dieser Artikel richtet sich an Product Owner, Business Analysten und alle, die Anforderungen zwischen fachlichen und technischen Perspektiven strukturieren.

Viele glauben, KI hilft beim Schreiben von User Stories.
Das stimmt nur teilweise.

Im Alltag scheitern Anforderungen selten am Schreiben.
Sie scheitern an fehlender Klarheit.

Stakeholder beschreiben Lösungen statt Probleme.
Anforderungen werden zu groß formuliert.
Stories wirken korrekt, sind aber fachlich unklar.
Offene Punkte fallen erst spät auf.

Ein typisches Beispiel:

Stakeholder: „Wir brauchen ein Dashboard für Kunden.“
Entwicklung: „Welche Daten?“
Fachbereich: „Alle wichtigen.“

Genau hier nutze ich die Prompts.
Nicht um Text zu erzeugen, sondern um Denken zu strukturieren.

Die folgenden Prompts sind kein Ablaufplan.
Es sind Werkzeuge für verschiedene Zustände einer Anforderung.

Manchmal gibt es nur Gesprächsnotizen.
Manchmal existiert bereits eine User Story, aber Kontext oder Verständnis fehlen.

Die KI dient dabei als Sparringspartner zum Strukturieren und Hinterfragen.

Einsatz je nach Reifegrad der Anforderung

Nicht jede Anforderung beginnt bei null.
Die Werkzeuge helfen beim Erstellen und beim Weiterentwickeln.

Vorgehensweise

Ich bringe jede Anforderung zuerst mit P1 in ein einheitliches Format.
Erst danach nutze ich weitere Prompts.

P1 ist damit die gemeinsame Grundlage für alles Weitere.

Wenn nur Notizen existieren → P1

Ziel: Aus Fragmenten wird eine verständliche Anforderung.

P1 – Rohbeschreibung → User Story

Rolle: Du bist ein erfahrener Product Owner.

Anweisung:
Warte auf meine Beschreibung eines konkreten Features, Problems oder Anwendungsfalls.

Wenn ich dir eine Beschreibung gebe:
- stelle bei Unklarheiten gezielte Rückfragen
- hilf mir anschließend, eine prägnante User Story zu formulieren

Die User Story soll enthalten:
- Titel
- Story/Ziel (Als … möchte ich …, um …)
- Problem & Kontext
- Business Value
- Out-Of-Scope
- Akzeptanzkriterien

Formuliere kompakt und in aktiver Sprache.

Diese Struktur macht spätere Diskussionen vergleichbar.

Wenn fachliche Einordnung fehlt → P2

Kontext ist optional.
Bei explorativen Themen nutze ich ihn oft nicht.
Bei fachlichen Details hilft er sehr.

P2 – Kontext gezielt einbeziehen

Systemkontext (optional zur Einordnung):

[Domänen- oder Systembeschreibung]

Nutze den Kontext nur, um fachliche Annahmen einzuordnen.
Kennzeichne explizit, wo du Annahmen triffst.

Der Prompt verhindert falsche Ableitungen, ohne Ideen einzuengen.

Wenn Umsetzung unklar bleibt → P3

Die Story ist verständlich, aber nicht planbar.

P3 – Story zerlegen

Bitte mach einen Vorschlag für eine mögliche fachliche Zerlegung der User Story.
Liste zuerst die Titel und Story/Ziel der jeweiligen User Stories auf.

So entstehen umsetzbare Einheiten.

---

Wenn Diskussionen sich im Detail verlieren → P4

Hier hilft Abstand statt weiterer Details.

P4 – High-Level Ziel ableiten

Bitte erstelle aus der User Story ein High-Level Epic.

Beschränke dich auf:
- Ziel
- Problem & Kontext
- Business Value
- High-Level Akzeptanzkriterien

Das Gespräch kehrt zurück zum Zweck der Anforderung.

Wenn jeder etwas anderes versteht → P5

Text wird interpretiert.
Abläufe werden beobachtet.

P5 – Visualisierung erzeugen

Erzeuge zur User Story eine Visualisierung in Mermaid:

- UML Sequenzdiagramm
oder
- ER Diagramm
oder
- Aktivitätsdiagramm
oder
- User Journey

Jetzt sprechen alle über denselben Ablauf.

Was sich dadurch verändert

Die Zusammenarbeit wird ruhiger.
Rückfragen entstehen früher.
Annahmen werden sichtbar.
Refinements werden klarer.
Verantwortlichkeiten werden verständlicher.

Die Kommunikation wird nicht weniger.
Sie wird besser vorbereitet.

Fazit

Die Prompts sind kein Prozess.
Sie sind Denkwerkzeuge.

Mit P1 strukturiere ich Anforderungen.
Mit P2 bis P5 entwickle ich sie weiter.

Templates ordnen Text.
Fragen ordnen Verständnis.
Diese Prompts ordnen Gespräche.

Die KI erweitert die Perspektive und macht Annahmen sichtbar.
So werden Anforderungen gemeinsam klarer.