Genau das ist der Kern, wenn du Anforderungen mit KI erheben willst: nicht schneller tippen, sondern besser denken. Die KI schreibt die Story nicht für mich – sie führt mich durch ein Gespräch, an dessen Ende ich selbst klarer bin als vorher.

Das klingt banal. Ist aber das genaue Gegenteil von dem, was die meisten mit KI machen.

Der Fragebogen-Reflex

Der erste Reflex – bei Menschen wie bei KI – ist: alles auf einmal. Ein großes Template, zwanzig Felder, „bitte vollständig ausfüllen“. Oder du kippst der KI in einem Absatz deine halbe Idee hin und sie spuckt eine fertig aussehende Story aus.

Das Problem: So entsteht eine Scheinvollständigkeit. Du füllst Felder, weil sie da sind, nicht weil du die Antwort wirklich durchdacht hast. Und die KI ergänzt den Rest mit plausiblen Annahmen. Am Ende steht ein Dokument, das fertig aussieht – und auf Vermutungen gebaut ist.

Anforderungsarbeit ist aber kein Formular. Sie ist Denkarbeit. Und Denken erzwingt man nicht mit mehr Feldern, sondern mit den richtigen Fragen zur richtigen Zeit.

Anforderungen mit KI erheben heißt: eine Frage nach der anderen

Deshalb läuft es bei mir als echtes Gespräch. Eine Frage. Ich antworte. Die KI hört zu, hakt nach, stellt die nächste. Kein Fragebogen, ein Dialog.

Die Reihenfolge ist bewusst gewählt: Erst was genau, dann warum (der eigentliche Wert), dann für wen, dann – die unbequeme – was explizit nicht, und zum Schluss der Kern der Akzeptanzkriterien.

Der Unterschied zum Fragebogen ist der gleiche wie zwischen einem guten Interviewer und einem Formular: Der Interviewer merkt, wenn eine Antwort schwammig ist, und bohrt nach. Das Formular nimmt jede Antwort, auch die faule. Genau dieses Nachbohren – „für wen genau?“, „was passiert, wenn nicht?“ – ist die Arbeit, die eine Story trägt oder scheitern lässt. (Über den Interview-Ansatz selbst habe ich hier schon ausführlicher geschrieben.)

Während wir reden, prüft die KI schon

Und jetzt kommt der Teil, der mir das Gespräch erst richtig wertvoll macht: Während ich rede, arbeitet die KI im Hintergrund.

Sie gleicht meine Idee live gegen die bestehenden Tickets ab – gibt es das schon, unter anderem Titel, in einem anderen Epic? Sie schaut in die Wissensbasis aus Teil 2: Widerspricht die Idee einer Architekturentscheidung? Steht sie im Konflikt mit etwas, das wir bewusst verworfen haben? Gibt es Abhängigkeiten zu anderen Stories?

Das ist der Moment aus Teil 1, nur von innen betrachtet: „Das gibt es schon. Zweimal.“ Ich muss dafür nicht 200 Tickets im Kopf haben – die KI hat sie parat, während ich mich aufs Denken konzentriere. Vor einem Live-Abgleich fragt sie mich übrigens kurz, ob sie loslegen soll. Auch hier bleibe ich der, der entscheidet.

Am Ende steht ein Draft – nicht das Ticket

Wichtig: Was aus dem Interview herausfällt, ist ein Draft. Ein strukturierter Entwurf mit Titel, dem eigentlichen „als wer will ich was und warum“, ersten Akzeptanzkriterien, einer klaren Abgrenzung und den gefundenen Abhängigkeiten. Dazu ein schneller INVEST-Check – und wenn die Sache zu groß ist, ein Vorschlag, sie zu splitten.

Es ist ausdrücklich nicht das fertige Ticket. Es ist mein Rohmaterial – sauber vorbereitet, aber noch nicht entschieden. Und es ist eine simple Markdown-Datei, die ich lesen und ändern kann, ganz gleich, ob die KI gerade mitspielt oder nicht.

Der Draft geht als Nächstes durch die Mangel. Und zwar nicht durch eine Perspektive, sondern durch ein ganzes Gremium.

Was das im Alltag verändert

Die größte Wirkung hat nicht die Zeitersparnis – die gibt es, ist aber nicht der Punkt. Die größte Wirkung ist, dass ich gezwungen werde, meine eigene Idee zu Ende zu denken, bevor sie irgendwer anders sieht. Die unbequemen Fragen kommen jetzt von der KI, an meinem Schreibtisch, und nicht später im Refinement vom halben Team.

Die Exportfunktion von neulich? Die sieht heute anders aus als die Idee, mit der ich reingegangen bin. Besser. Weil mir jemand die eine unbequeme Frage gestellt hat, bevor ich losgelaufen bin.

Das ist Teil 3 der Serie „Requirements Engineering mit KI-Agenten“. Im nächsten Teil geht der Draft durch die Mangel: sechs Perspektiven schauen gleichzeitig drauf – Security, UX, Architektur, Compliance, Story-Qualität – und ein Advocatus Diaboli, der mich vor mir selbst schützt.

Alle Teile der Serie: Zur Themenseite „Requirements Engineering Pipeline“

Der Beitrag Anforderungen mit KI erheben: ein Interview statt eines Fragebogens erschien zuerst auf Das ist die Welt von Thomas.