Prompt Engineering für Stakeholder: Wie du KI nutzt, um unfokussierte Kundenwünsche in harte Requirements zu übersetzen

Warum Business Analysten, Scrum Master und Product Owner die besten Prompt Engineers sind, ohne es zu wissen

Apr. 03, 2026

“Wir brauchen das System schneller.”
“Es soll benutzerfreundlicher sein.”
“Können wir das irgendwie automatisieren?”

Wenn du in der Softwareentwicklung arbeitest, erkennst du diese Sätze. Sie kommen in jedem Sprint Review, in jedem Stakeholder-Meeting, in jedem Workshop. Und sie haben etwas gemeinsam: Sie sagen alles und nichts zugleich.

Die Standish Group dokumentiert seit 1994 in ihrem CHAOS Report, warum IT-Projekte scheitern. Drei Faktoren tauchen in jeder Ausgabe auf: fehlende Nutzereinbindung, mangelnde Management-Unterstützung und unklare Anforderungen. In der Ausgabe von 2020 galten nur 31 Prozent aller IT-Projekte als erfolgreich. 50 Prozent wurden als “challenged” eingestuft, 19 Prozent scheiterten komplett. Unklare Requirements stehen dabei konstant unter den Top-3-Ursachen.

Das Problem ist nicht neu. Die Lösung schon.

Generative KI verändert die Art, wie wir Anforderungen erheben, strukturieren und validieren. Nicht als Ersatz für das Gespräch mit Stakeholdern, sondern als Verstärker. Prompt Engineering, richtig eingesetzt, wird zum Werkzeug der Requirements-Analyse. Und die gute Nachricht: Wer bereits Erfahrung in Business Analysis, Scrum oder Produktmanagement hat, bringt die entscheidenden Fähigkeiten mit.

Dieser Artikel zeigt dir, wie du KI gezielt einsetzt, um aus vagen Kundenwünschen testbare, priorisierte und umsetzbare Requirements zu machen. Mit konkreten Prompts, einem durchgängigen Workflow und Warnhinweisen, wo die Technik an ihre Grenzen stösst.

Lerne, wie du mit gezieltem Prompt Engineering vage Stakeholder-Wünsche in testbare Requirements übersetzt. Praxisbeispiele, Prompt-Templates und ein konkreter Workflow. — Lerne, wie du mit gezieltem Prompt Engineering vage Stakeholder-Wünsche in testbare Requirements übersetzt.

Warum Stakeholder nicht sagen, was sie meinen

Bevor wir über KI sprechen, lohnt sich ein Blick auf das eigentliche Problem. Stakeholder sind keine Requirements Engineers. Sie denken in Problemen, Wünschen und manchmal in Lösungen. Selten in spezifizierbaren Anforderungen.

Die Fachliteratur zu Requirements Elicitation beschreibt dieses Phänomen seit Jahrzehnten. Christel und Kang identifizierten bereits 1992 drei Kernprobleme: Der Scope wird schlecht definiert, Stakeholder äussern technische Details statt Bedürfnisse, und triviale Annahmen bleiben unausgesprochen, obwohl sie für das Team nicht offensichtlich sind.

Dazu kommt: Stakeholder verwechseln oft Lösungen mit Anforderungen. “Wir brauchen ein Dashboard” ist keine Anforderung. Es ist ein Lösungsvorschlag. Die Anforderung dahinter könnte lauten: “Ich muss den aktuellen Status aller offenen Aufträge innerhalb von 10 Sekunden einsehen können, ohne drei verschiedene Systeme öffnen zu müssen.”

Diesen Übersetzungsschritt leisten heute Business Analysten, Product Owner und Scrum Master. Sie führen Interviews, stellen Rückfragen, ordnen ein. Das kostet Zeit. Und die Qualität hängt stark von der Erfahrung der Person ab, die die Fragen stellt.

Genau hier setzt KI als Werkzeug an.

Der Missing Link: Prompt Engineering als Requirements-Methode

Die International Institute of Business Analysis (IIBA) hat den Zusammenhang zwischen Business Analysis und Prompt Engineering bereits erkannt. In einem Artikel auf der IIBA-Website beschreibt ein erfahrener Functional Analyst, wie ihm auf einer Konferenz klar wurde: Die Fähigkeiten, die er seit Jahren für Stakeholder-Interviews nutzt, sind exakt die Fähigkeiten, die gutes Prompt Engineering braucht.

Das ergibt Sinn, wenn du darüber nachdenkst. Ein guter Business Analyst:

stellt offene Fragen, um neue Informationen zu gewinnen
stellt Rückfragen, um Details zu vertiefen
klärt Mehrdeutigkeiten, um Genauigkeit sicherzustellen
iteriert über Ergebnisse, um sie zu verfeinern

Ein guter Prompt Engineer tut dasselbe. Nur dass der Gesprächspartner kein Stakeholder ist, sondern ein Sprachmodell. Und dass die Iteration in Minuten statt Wochen stattfindet.

Das Forschungsfeld “AI for Requirements Engineering” (AI4RE) wächst schnell. Eine aktuelle Studie aus dem Jahr 2025 (veröffentlicht auf arxiv.org) kategorisiert Prompt-Engineering-Techniken systematisch im Kontext von Requirements Engineering. Die Autoren zeigen, wie kreative Prompt-Strategien Requirements-Artefakte generieren, alternative Formulierungen vorschlagen und sogar innovative Feature-Ideen hervorbringen können. Ein konkretes Beispiel aus der Studie: Aus einer vagen Anforderung wie “Das Licht soll sich der Temperatur anpassen” generiert ein LLM mit dem richtigen Prompt eine messbare Spezifikation wie “Das System muss die LED-Streifenintensität innerhalb von 500 ms nach einer erkannten Temperaturänderung von ±0,5 °C aktualisieren.”

Das ist der Sprung: von “es soll sich anpassen” zu einer testbaren, quantifizierten Anforderung. In Sekunden statt Stunden.

Der Workflow: Vom Stakeholder-Wunsch zum harten Requirement

Theorie ist gut. Praxis ist besser. Hier ist ein konkreter Workflow, den du in deinem nächsten Sprint Refinement oder Requirements Workshop einsetzen kannst.

Schritt 1: Den Stakeholder-Input erfassen

Starte mit dem Rohmaterial. Das kann ein Satz aus einem Meeting sein, eine E-Mail, ein Post-it von einem Workshop oder ein Transkript. Beispiel:

“Die Kunden beschweren sich, dass die Bestellübersicht zu langsam ist. Wir brauchen das schneller.”

Schritt 2: KI als Interviewer einsetzen

Gib der KI die Rolle eines erfahrenen Business Analysten und lass sie die Rückfragen stellen, die ein guter Analyst stellen würde. Ein Prompt dafür:

Du bist ein erfahrener Business Analyst mit 15 Jahren Erfahrung
in Requirements Engineering. Ein Stakeholder sagt dir:

"Die Kunden beschweren sich, dass die Bestellübersicht zu langsam
ist. Wir brauchen das schneller."

Stelle mir die 7 wichtigsten klärenden Fragen, die du diesem
Stakeholder stellen würdest, um aus dieser vagen Aussage eine
spezifizierbare Anforderung zu machen. Ordne die Fragen nach
Priorität. Erkläre bei jeder Frage, warum sie wichtig ist.

Die KI generiert dann Fragen wie:

Was bedeutet “zu langsam” konkret? Wie lange dauert das Laden aktuell? Wie lange wäre akzeptabel?
Welche Kunden beschweren sich? Alle oder eine bestimmte Gruppe?
Welche Bestellübersicht genau? Die im Kundenportal? In der App? Im Backend?
Wie viele Bestellungen haben betroffene Kunden typischerweise?
Gibt es bestimmte Tageszeiten oder Situationen, in denen das Problem auftritt?
Welche Informationen in der Bestellübersicht sind für die Kunden am wichtigsten?
Wie wirkt sich die langsame Ladezeit auf das Geschäft aus? Gibt es messbare Auswirkungen (Abbrüche, Support-Tickets)?

Jede dieser Fragen zielt auf eine andere Dimension: Performance-Metrik, Nutzergruppe, Systemkontext, Datenvolumen, Randbedingungen, Priorität und Business Impact.

Schritt 3: Antworten einspeisen und Requirements generieren

Nachdem du die Antworten vom Stakeholder eingeholt hast (das Gespräch bleibt zentral), fütterst du die KI mit den Ergebnissen:

Hier sind die Antworten des Stakeholders auf die klärenden Fragen:

1. Aktuell dauert das Laden 8-12 Sekunden. Unter 3 Sekunden wäre gut.
2. Betrifft Grosskunden mit mehr als 500 Bestellungen pro Jahr.
3. Die Bestellübersicht im Kundenportal (Web).
4. Grosskunden haben zwischen 500 und 5000 Bestellungen.
5. Das Problem tritt v.a. montags morgens auf (hohe Last).
6. Bestellstatus und Liefertermin sind am wichtigsten.
7. 15% der Grosskunden haben deswegen beim Support angerufen.

Erstelle daraus:
a) 3-5 User Stories im Format "Als [Rolle] möchte ich [Funktion],
   damit [Nutzen]"
b) Zu jeder User Story 3-4 Akzeptanzkriterien
c) Identifiziere nicht-funktionale Anforderungen (Performance,
   Skalierbarkeit)
d) Kennzeichne offene Punkte, die noch geklärt werden müssen

Schritt 4: Qualitätsprüfung mit INVEST

Die INVEST-Kriterien (Independent, Negotiable, Valuable, Estimable, Small, Testable) sind der Goldstandard für die Qualitätsbewertung von User Stories. Forschungsarbeiten zeigen, dass viele agile Teams diese Kriterien in der Praxis nicht konsequent anwenden, obwohl sie nachweislich die Qualität der Anforderungen verbessern.

Du kannst die KI nutzen, um die generierten Stories gegen INVEST zu prüfen:

Prüfe die folgenden User Stories anhand der INVEST-Kriterien
(Independent, Negotiable, Valuable, Estimable, Small, Testable).
Bewerte jedes Kriterium mit Grün, Gelb oder Rot. Begründe jede
Bewertung. Schlage bei Gelb und Rot konkrete Verbesserungen vor.

[User Stories hier einfügen]

Dieser Schritt ist entscheidend. Die KI produziert nicht automatisch gute Requirements. Sie produziert Requirements schnell. Die Qualitätssicherung bleibt beim Menschen, wird aber durch die KI unterstützt.

Schritt 5: Lückenanalyse

Der letzte Schritt im Workflow deckt auf, was fehlt. Erfahrene Business Analysten wissen: Die gefährlichsten Anforderungen sind die, die niemand ausspricht. Die KI kann hier als Sparringspartner dienen:

Analysiere die folgenden Requirements im Kontext eines
E-Commerce-Kundenportals für B2B-Grosskunden. Identifiziere:

1. Fehlende nicht-funktionale Anforderungen (Security,
   Accessibility, Compliance)
2. Edge Cases, die nicht abgedeckt sind
3. Abhängigkeiten zu anderen Systemen oder Teams
4. Annahmen, die implizit gemacht werden, aber explizit
   dokumentiert werden sollten

[Requirements hier einfügen]

Forschungsergebnisse bestätigen diesen Ansatz. Eine Studie der Universität Melbourne (veröffentlicht 2023 auf arxiv.org) dokumentiert, wie ein LLM bei der Anforderungserhebung für eine Gesundheits-App Compliance-Anforderungen identifizierte, an die das Team nicht gedacht hatte, konkret die Konformität mit dem australischen Therapeutic Goods Act.

Prompt-Templates für die tägliche Arbeit

Die obigen Beispiele zeigen den Gesamtworkflow. In der täglichen Arbeit brauchst du oft schnelle, fokussierte Prompts für spezifische Situationen. Hier sind vier Templates, die du direkt einsetzen kannst.

Template 1: Der Mehrdeutigkeits-Detektor

Analysiere die folgende Anforderung auf Mehrdeutigkeiten,
unklare Begriffe und fehlende Spezifikationen:

"[Anforderung hier einfügen]"

Für jede gefundene Mehrdeutigkeit:
- Beschreibe das Problem
- Erkläre, warum es in der Umsetzung zu Problemen führen wird
- Formuliere 2-3 alternative, präzisere Versionen der Anforderung

Template 2: Der Akzeptanzkriterien-Generator

Erstelle Akzeptanzkriterien im Given-When-Then-Format für
die folgende User Story:

"[User Story hier einfügen]"

Erstelle mindestens 5 Szenarien, darunter:
- 2 Happy-Path-Szenarien
- 2 Edge-Case-Szenarien
- 1 Fehlerfall-Szenario

Achte darauf, dass jedes Kriterium messbar und testbar ist.

Template 3: Der Requirement-Übersetzer (Fachsprache zu Technik)

Übersetze die folgenden Business-Anforderungen in technische
Requirements. Verwende das Format:

REQ-[ID]: Das System MUSS/SOLL/KANN [Funktionalität],
[Bedingung], [Messkriterium].

Klassifiziere jedes Requirement als:
- Funktional / Nicht-funktional
- Must / Should / Could (MoSCoW)

Business-Anforderungen:
[Anforderungen hier einfügen]

Template 4: Der Stakeholder-Simulator

Simuliere die Perspektive eines [Rolle, z.B. "Endnutzer im
Aussendienst, der die App auf dem Smartphone nutzt"]. Stelle
dir vor, du nutzt das beschriebene System im Alltag.

System: [Kurze Beschreibung]

Beschreibe:
1. Drei Situationen, in denen du das System dringend brauchst
2. Drei Dinge, die dich frustrieren würden
3. Drei Features, die dir fehlen würden
4. Deine grösste Angst bei der Einführung des Systems

Sei spezifisch und realistisch. Vermeide generische Aussagen.

Dieser letzte Prompt ist besonders wertvoll. Die Forschung zeigt, dass LLMs Stakeholder-Perspektiven simulieren können, was bei der Identifikation von Anforderungen hilft, die in traditionellen Workshops untergehen. Natürlich ersetzt das kein echtes Nutzerfeedback. Aber es deckt blinde Flecken auf und bereitet Interviews besser vor.

Die Grenzen: Wo KI versagt und Menschen zählen

Nach all der Begeisterung braucht es einen Realitätscheck. KI im Requirements Engineering hat klare Grenzen, und wer sie ignoriert, riskiert genau die Probleme, die er lösen will.

Halluzinationen und falsche Sicherheit

LLMs erfinden Anforderungen, die plausibel klingen, aber keinen Bezug zur Realität haben. Ein Forscherteam dokumentierte, wie ein generisches KI-Tool eine falsche Compliance-Anforderung generierte: eine Session-Timeout-Dauer von 30 Minuten, die angeblich aus dem PCI-DSS-Standard stammt. Der tatsächliche Standard verlangt 15 Minuten. Solche Fehler sind gefährlich, weil sie professionell formuliert sind und dadurch weniger hinterfragt werden.

Kontextverlust bei langen Gesprächen

LLMs haben ein begrenztes Kontextfenster. Bei komplexen Systemen mit vielen Abhängigkeiten verliert die KI den Überblick. Teilnehmer einer Studie berichteten, dass die KI den Kontext ihres Gesundheits-App-Projekts über eine längere Session hinweg nicht konsistent aufrechterhalten konnte. Das bedeutet: Bei grösseren Projekten musst du den Kontext aktiv managen, etwa durch strukturierte Prompts mit Zusammenfassungen des bisherigen Stands.

Domänenwissen fehlt

KI kennt Muster, nicht dein Business. Sie weiss nicht, dass euer ERP-System jeden Donnerstagabend einen Batch-Job lauft, der die Datenbank blockiert. Sie kennt nicht die interne Politik zwischen Abteilungen. Sie versteht nicht, warum der Vertriebsleiter auf Feature X besteht, obwohl kein Kunde danach gefragt hat.

Der Mensch bleibt der Entscheider

Die KI generiert Optionen und Strukturen. Die Entscheidung, welche Anforderung Priorität hat, welcher Trade-off akzeptabel ist, welche Stakeholder-Perspektive schwerer wiegt, bleibt beim Menschen. Immer.

Ein Team von ArgonDigital, einer Firma mit über 22 Jahren Erfahrung im Requirements Engineering, bringt es auf den Punkt: Ihre Teams nutzen KI, um Transkripte in strukturierte Requirements zu übersetzen und den Dokumentationsaufwand zu reduzieren. Die Entscheidungs- und Denkarbeit, das eigentliche “Product Thought Work”, bleibt beim Menschen.

Ein Praxisbeispiel aus dem Alltag

Um das Ganze greifbar zu machen, hier ein durchgängiges Beispiel. Stell dir vor, du bist Scrum Master oder Product Owner in einem Team, das ein internes Ticketing-System für den IT-Support entwickelt.

Im Sprint Review sagt der Head of IT Support:

“Unsere Leute verbringen zu viel Zeit mit der Kategorisierung von Tickets. Das muss automatischer werden.”

Du öffnest dein KI-Tool und startest den Workflow.

Prompt 1 (Klärung):

Ein Stakeholder (Head of IT Support) sagt:
"Unsere Leute verbringen zu viel Zeit mit der Kategorisierung
von Tickets. Das muss automatischer werden."

Kontext: Internes IT-Ticketing-System, ca. 200 Tickets pro Tag,
15 Support-Mitarbeitende, aktuell manuelle Kategorisierung in
12 Kategorien.

Generiere 8 klärende Fragen in absteigender Priorität.

Die KI liefert Fragen zu: Zeitaufwand pro Ticket, Fehlerrate bei manueller Kategorisierung, häufigste Kategorien, Konsequenzen falscher Kategorisierung, gewünschter Automatisierungsgrad, bestehende Datengrundlage für Training, Integration in bestehende Workflows und Akzeptanzkriterien für eine automatische Lösung.

Du stellst die Fragen im nächsten Gespräch mit dem Stakeholder und erhältst Antworten.

Prompt 2 (Requirement-Generierung):

Basierend auf den folgenden Stakeholder-Antworten, erstelle
User Stories mit Akzeptanzkriterien:

- Kategorisierung dauert aktuell 2-3 Minuten pro Ticket
- Fehlerrate bei manueller Kategorisierung: ca. 20%
- 80% der Tickets fallen in 4 von 12 Kategorien
- Falsche Kategorisierung führt zu Routing an falsches Team,
  durchschnittlich 4 Stunden Verzögerung
- Automatisierung soll Vorschlag machen, Mensch bestätigt
- Historische Ticketdaten der letzten 2 Jahre vorhanden
- Muss in bestehendes ITSM-Tool integrierbar sein
- Akzeptabel: 90% korrekte Vorschläge bei den Top-4-Kategorien

Erstelle User Stories im INVEST-Format mit Akzeptanzkriterien.
Identifiziere nicht-funktionale Anforderungen und offene Punkte.

Die KI generiert nun mehrere User Stories, etwa:

“Als IT-Support-Mitarbeitender möchte ich bei jedem neuen Ticket automatisch einen Kategorisierungsvorschlag erhalten, damit ich das Ticket schneller dem richtigen Team zuweisen kann.”

Mit Akzeptanzkriterien wie:

Der Vorschlag erscheint innerhalb von 2 Sekunden nach Ticket-Erstellung
Die korrekte Kategorie wird in mindestens 90% der Fälle bei den Top-4-Kategorien vorgeschlagen
Der Mitarbeitende kann den Vorschlag mit einem Klick bestätigen oder manuell ändern
Bei Tickets, die keiner Top-4-Kategorie zugeordnet werden können, zeigt das System die drei wahrscheinlichsten Kategorien mit Konfidenzwert

Prompt 3 (INVEST-Check und Lückenanalyse):

Prüfe die generierten User Stories gegen die INVEST-Kriterien.
Identifiziere zusätzlich:
- Datenschutzanforderungen (Ticketdaten können persönliche
  Informationen enthalten)
- Anforderungen an das ML-Modell-Training und -Monitoring
- Fallback-Szenarien bei Systemausfall der Automatisierung
- Schulungsbedarf für die Support-Mitarbeitenden

Innerhalb von 15 Minuten hast du ein strukturiertes Set an Requirements, das du im nächsten Refinement mit dem Team besprechen kannst. Nicht als fertiges Ergebnis, sondern als solide Grundlage, die Stunden an Vorbereitungszeit spart.

Was das für deine Rolle bedeutet

Die Einführung von KI im Requirements Engineering verschiebt die Rolle von Business Analysten, Product Ownern und Scrum Mastern. Weg von der manuellen Dokumentation, hin zur Kuratierung und Qualitätssicherung.

Für Business Analysten

Deine Kernkompetenz, das Verstehen von Geschäftsprozessen und Stakeholder-Bedürfnissen, wird wertvoller, nicht weniger. Die KI übernimmt die Strukturierung und Formulierung. Du konzentrierst dich auf die richtigen Fragen, die politische Navigation und die Priorisierung. Die IIBA beschreibt es treffend: Business-Analyse-Profis sind einzigartig positioniert, um im Prompt Engineering zu glänzen, weil sie die Brücke zwischen Geschäftszielen und technischer Umsetzung seit Jahren bauen.

Für Product Owner

Du kannst schneller von einer vagen Product-Vision zu einem strukturierten Backlog gelangen. Die KI hilft dir, Feature-Ideen durchzuspielen, Edge Cases zu identifizieren und Stakeholder-Perspektiven zu simulieren. Aber die Priorisierung, das “Was bauen wir als Nächstes und warum?”, bleibt deine Entscheidung.

Für Scrum Master

Du kannst den Refinement-Prozess beschleunigen, indem du vorbereitete, KI-unterstützte Requirements ins Meeting bringst. Statt 90 Minuten mit der Formulierung von User Stories zu verbringen, diskutiert das Team über Architekturentscheidungen und Trade-offs. Die wertschöpfende Arbeit steht im Fokus.

Der Tech-Stack: Welche Tools taugen wofür?

Die Frage nach dem richtigen Tool ist weniger wichtig als die Frage nach dem richtigen Prompt. Trotzdem ein kurzer Überblick, welche Ansätze sich in der Praxis bewähren.

Generelle LLMs (Claude, ChatGPT, Gemini): Für den oben beschriebenen Workflow reicht ein allgemeines Sprachmodell. Die Qualität hängt primär vom Prompt ab, nicht vom Modell. Claude und ChatGPT liefern bei strukturierten Requirements-Prompts vergleichbare Ergebnisse. Der Vorteil: Keine zusätzlichen Kosten, keine Integration, sofort einsetzbar.

Meeting-Intelligence-Tools (Otter.ai, Fireflies): Diese Tools zeichnen Stakeholder-Meetings auf, transkribieren sie und generieren Zusammenfassungen. Sie lösen ein reales Problem: Niemand kann gleichzeitig ein Meeting moderieren und alles protokollieren. Die Transkripte kannst du anschliessend in ein LLM einspeisen, um Requirements zu extrahieren.

Spezialisierte Requirements-Plattformen (Jira mit KI-Plugins, ClickUp Brain, Azure DevOps Copilot): Diese Tools integrieren KI direkt in den Requirements-Management-Workflow. Der Vorteil: Traceability und Versionierung sind eingebaut. Der Nachteil: Sie kennen nur, was du eingetragen hast. Ein Team, das Claude nutzte, um über 1000 Seiten regulatorische Dokumentation zu verarbeiten und daraus über 300 umsetzbare Anforderungen zu extrahieren, hätte das mit einem integrierten Tool allein nicht geschafft.

Die beste Strategie kombiniert beide Welten: Spezialisierte Tools für Struktur und Nachverfolgbarkeit, allgemeine LLMs für die Analyse unstrukturierter Inputs.

Häufige Fehler und wie du sie vermeidest

Aus der Praxis und der Forschung kristallisieren sich wiederkehrende Fehler heraus, die du kennen und vermeiden solltest.

Fehler 1: Die KI als alleinige Quelle nutzen. Wer KI-generierte Requirements ohne Stakeholder-Validierung ins Backlog schiebt, wiederholt den klassischen Fehler des Wasserfall-Modells: Anforderungen am Schreibtisch erfinden statt mit Nutzern sprechen. Die KI ergänzt das Gespräch, sie ersetzt es nicht.

Fehler 2: Zu vage Prompts. “Schreib mir User Stories für ein CRM” liefert generische Ergebnisse. Der Kontext macht den Unterschied. Branche, Nutzergruppe, technische Rahmenbedingungen, bestehende Systeme, bekannte Einschränkungen: Je mehr Kontext du gibst, desto besser das Ergebnis.

Fehler 3: Die Ausgabe nicht prüfen. LLMs klingen überzeugend, auch wenn sie falsch liegen. Jede generierte Anforderung braucht eine menschliche Prüfung. Stimmt die Metrik? Ist die Annahme korrekt? Fehlt ein Edge Case? Die KI-Ausgabe ist ein Entwurf, kein Endprodukt.

Fehler 4: Vertrauliche Informationen ungeschützt einspeisen. Requirements enthalten oft sensible Geschäftsinformationen. Wer Stakeholder-Interviews inklusive Firmennamen, Finanzdaten und strategischen Plänen in ein öffentliches LLM einspeist, riskiert Datenschutzverletzungen. Prüfe die Datenschutzrichtlinien deines Unternehmens und nutze bei Bedarf lokale Modelle oder Enterprise-Versionen.

Fehler 5: Die Stakeholder-Beziehung vernachlässigen. Die Forschung betont: Die Kernaufgabe eines Business Analysten ist nicht die Transkription von Anforderungen, sondern das Verstehen von Geschäftsproblemen, die Moderation von Stakeholder-Alignment und das Treffen von Entscheidungen bei widersprüchlichen Prioritäten. KI-Tools befreien dich von der “archäologischen Arbeit” wie dem Durchsuchen von Legacy-Systemen und dem Übersetzen veralteter Dokumentation. Nutze die gewonnene Zeit für strategisches Denken und Beziehungsarbeit.

Abschliessende Gedanken

Ich beobachte seit Jahren, wie Teams an Requirements scheitern. Nicht weil die Leute inkompetent sind, sondern weil der Übersetzungsprozess zwischen Stakeholder-Sprache und Entwickler-Sprache zu verlustbehaftet ist. Jede Schicht im “Stille Post”-Spiel frisst Information.

KI löst dieses Problem nicht. Aber sie verändert die Spielregeln.

Ich nutze die oben beschriebenen Prompts in meiner täglichen Arbeit als Scrum Master. Nicht für jede User Story, aber für jedes komplexe Feature, bei dem der Stakeholder-Input diffus ist. Das spart mir pro Sprint mehrere Stunden Vorbereitungszeit. Und die Qualität der Diskussionen im Refinement hat sich messbar verbessert, weil das Team nicht mehr über Formulierungen streitet, sondern über Architektur und Trade-offs.

Was mich dabei stört: Zu viele Teams behandeln KI im Requirements Engineering als Zukunftsthema. Sie warten auf das perfekte Tool, die perfekte Integration, die perfekte Policy. Währenddessen sitzen sie in dreistündigen Refinements und formulieren User Stories von Hand.

Mein Vorschlag: Nimm dir 30 Minuten. Nimm die vage Anforderung aus deinem letzten Sprint Review. Lauf den Workflow aus diesem Artikel durch. Beurteile das Ergebnis selbst. Nicht die Technik entscheidet, ob das funktioniert, sondern die Qualität deiner Fragen. Und Fragen stellen, das kannst du bereits.

Die Fähigkeiten, die gute Business Analysten, Product Owner und Scrum Master seit Jahren aufbauen, Empathie, Fragetechniken, Kontextverständnis, Priorisierung, sind genau die Fähigkeiten, die KI nicht hat. Und genau die Fähigkeiten, die den Unterschied machen zwischen einem generierten Textblock und einem Requirement, das tatsächlich Wert liefert.

Das Werkzeug ist da. Die Kompetenz hast du. Die Frage ist nur: Wann fängst du an?

Michaels Gedanken.

Diskussion über diese Post

Sind Sie bereit für mehr?