Requirements Engineering aus Stakeholder-Input

Die meisten Projektfehlschläge beginnen bei Anforderungen, die vage, widersprüchlich, lückenhaft oder nie aufgeschrieben sind. LLMs können Workshops und Interviews zuhören, E-Mail-Verläufe und Tickets lesen und wohlgeformte Anforderungen und User Stories mit Quellenrückverfolgung entwerfen, während sie Mehrdeutigkeiten und Konflikte markieren. Analysten verwenden ihre Zeit dann für Verhandlung und Validierung statt für Abtippen und Formatieren.

Problem & Nutzen

• Heute: Business-Analysten und Product Owner besuchen Besprechungen, machen Notizen, schreiben sie zu User Stories oder „Das System muss …“-Aussagen um, gleichen Widersprüche zwischen Abteilungen ab und halten ein Backlog oder Anforderungswerkzeug aktuell. Zwischen Gespräch und Ticket geht Kontext verloren; Stakeholder entdecken Lücken erst beim Testen oder bei der Abnahme.
• KI-Nutzen: schnellere erste Entwürfe aus Rohmaterial, einheitliche Struktur (Vorlagen wie EARS, User-Story-Format, Gherkin), automatische Erkennung mehrdeutiger Wörter („schnell“, „benutzerfreundlich“), von Duplikaten und Konflikten sowie Erzeugung von Rückfragen. Rückverfolgbarkeit jeder Anforderung bis zum Zitat, aus dem sie entstand.
• Belege: Ein systematischer Review von 74 Studien (2023-2024) zu LLMs im Requirements Engineering stellt fest, dass Erhebung sowie Verifikation/Validierung die am häufigsten behandelten Tätigkeiten sind und die Zahl der Studien schnell wächst, die meisten Auswertungen aber kleinen Umfangs und nur wenige industriell sind [1]. Ein Review zu Prompting-Strategien für die Erhebung umfasst 58 Studien [2]. Behandeln Sie Produktivitätsversprechen von Anbietern mit Vorsicht; belastbare Felddaten zu Qualitätsgewinnen sind noch dünn.

Varianten

• Von der Besprechung ins Backlog: Transkript eines Refinement- oder Discovery-Workshops → Story-Entwürfe in Jira / Azure DevOps.
• Vom Dokument zu Anforderungen: Ausschreibung, Vertrag oder Vorschrift → Anforderungsliste (siehe DOC-015, CODE-025).
• Feedback-Auswertung: Support-Tickets, Bewertungen und Umfrageantworten, gebündelt zu Funktionswünschen und Bedarfen.
• Qualitätssicherung von Anforderungen: vorhandene Spezifikationen anhand der Kriterien von ISO/IEC/IEEE 29148 prüfen (eindeutig, testbar, konsistent).
• Simulierte Stakeholder / Personas: LLM-Agenten spielen Nutzer, um übersehene Bedarfe vor echten Interviews aufzudecken (Forschungsstadium, z. B. das Elicitron-Framework).
• Regulierte Bereiche: Spezifikationen für Medizin, Automobil und öffentlichen Sektor mit verpflichtender Rückverfolgbarkeit (siehe CODE-020).
• Private / Hobby-Nutzung: eine persönliche App-Idee in eine Funktionsliste gliedern, bevor CODE-007 genutzt wird.

So funktioniert es

1. sources (recordings, mail, tickets, docs)
2. transcription + speaker separation (ASR, diarization)
3. cleaning + PII minimisation (names, health data)
4. extraction (needs, constraints, decisions, open questions)
5. structuring (requirement IDs, EARS / user story / Gherkin)
6. quality + consistency checks (ambiguity, duplicates, conflicts vs. repository via retrieval)
7. analyst review (accept / edit / reject, with source quote shown)
8. export to Jira / Azure DevOps / Confluence / requirements tool + traceability links
9. stakeholder validation round (generated summary and clarifying questions)

• Extraktion und Entwurf: ein allgemeines oder Reasoning-LLM mit striktem Ausgabeschema und Few-Shot-Beispielen im Anforderungsstil des Teams.
• Konsistenzprüfung: Embeddings plus Reranking rufen verwandte vorhandene Anforderungen ab; das LLM vergleicht Paare und kennzeichnet sie als Duplikat / Konflikt / Verfeinerung.
• Mensch-in-der-Schleife (Human-in-the-Loop): Der Analyst besitzt die Anforderungsbasis. Jedes erzeugte Element trägt ein Quellzitat und eine Konfidenz; nichts gelangt ohne Prüfung in die Basis, und Stakeholder bestätigen die endgültige Formulierung.

Datenaufbereitung

Eingaben sind Interviewaufzeichnungen und -notizen, Workshop-Protokolle, E-Mails, vorhandene Spezifikationen, Tickets und Prozessbeschreibungen. In einem KMU verteilen sich diese auf Postfächer, Laufwerke, Whiteboard-Fotos, Papiernotizen und Besprechungswerkzeuge, oft ohne einheitliches Benennungsschema.

Typische Lücken: unstrukturiertes Audio ohne Transkripte, eingescannte oder fotografierte Notizen, Duplikate und veraltete Fassungen von Spezifikationen, kein Glossar (derselbe Begriff bedeutet Unterschiedliches), unklare Quellen einer Anforderung und personenbezogene Daten von Stakeholdern im Material.

Schritte der Aufbereitung: - Aufzeichnungen lokal mit Whisper transkribieren und die Einwilligung klären (PREP-007 für Formatkonvertierung, PREP-006 für eingescannte Notizen). - Die aktuellen Fassungen der Spezifikation in einem Ordner oder Repository sammeln und kennzeichnen, welche maßgeblich ist (PREP-009). - Ein Projektglossar und eine Abkürzungsliste aufbauen (PREP-015, PREP-012). - Zwei oder drei gute Beispielanforderungen und eine Vorlage als Goldstandard bereitstellen (PREP-016). - Namen pseudonymisieren, wo sie nicht gebraucht werden (PREP-022), und die Rechtsgrundlage prüfen (PREP-025).

Aufwandsanteil: mittel, etwa 30 %, überwiegend für das Zusammenführen des Materials und das Glossar. Siehe GUIDE-003 für den Reifegrad-Check.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg B, weil Anforderungsarbeit auf die Werkzeuge und Vorlagen des Unternehmens zugeschnitten ist und eine schlanke, API-basierte Pipeline (transkribieren, strukturieren, mit Tickets verknüpfen) besser passt als ein Produkt.
• Großunternehmen: Weg C, weil Stakeholder-Interviews und Anforderungen oft vertraulich sind und personenbezogene Daten enthalten und eine gemeinsame interne Plattform mit Whisper und einem Modell mit offenen Gewichten Kosten je Arbeitsplatz vermeidet.
• Entwickler: Weg C, weil lokale Transkription und ein lokales Modell das Interviewmaterial kostengünstig privat halten.
• Öffentlicher Sektor: Weg C in einer souveränen EU- oder deutschen Cloud, wegen Vergaberegeln, Souveränität und der personenbezogenen Daten von Bürgern und Beschäftigten.

Weg A — Kaufen (Standardsoftware)

• Backlog-Werkzeuge mit integrierter KI: Atlassian Rovo (Jira / Confluence, mit einem Agenten für Produktanforderungen und Story-Entwürfen) [3]; Azure DevOps mit GitHub Copilot; Productboard, Linear, ClickUp, Notion AI, Miro AI.
• Speziell für Anforderungen: Jama Connect (Advisor, Anforderungsqualität), IBM DOORS Next mit watsonx, Visure (mit Sitz in Brüssel/Spanien, EU), codeBeamer (PTC), Modern Requirements4DevOps.
• Besprechungserfassung: Microsoft Teams Copilot, Zoom AI Companion, Fireflies, Otter, Granola; EU-Optionen wie in der EU gehostete Alternativen zu Fathom, tl;dv, Sembly. Datenresidenz in der EU und Einwilligungsfunktionen prüfen.
• A wählen, wenn: das Team bereits in Jira oder Azure DevOps arbeitet und Entwürfe im Werkzeug wünscht.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: Claude, GPT, Gemini oder Mistral (EU-Anbieter) mit strukturierten Ausgaben; Reasoning-Modelle für die Konfliktanalyse. EU-Regionen nutzen (Azure OpenAI EU Data Zones, Vertex AI EU, AWS Bedrock Frankfurt, Mistral La Plateforme).
• Sprache: ASR der Whisper-Klasse oder vom Anbieter mit Diarization (z. B. Azure Speech EU, Deepgram EU, Speechmatics - UK/EU).
• Integration: REST-APIs oder MCP-Server von Jira / Azure DevOps, n8n oder Power Automate zur Orchestrierung, ein Vektorspeicher (pgvector, Qdrant - EU) für das Anforderungs-Repository.
• B wählen, wenn: Sie eine eigene Anforderungsvorlage, Repository-Integration und einen Prüf-Workflow brauchen.

Weg C — Selbst betreiben (Open Source)

• ASR / Diarization: Whisper-large-v3-Varianten (faster-whisper), pyannote.audio, WhisperX.
• LLMs: Modelle mit offenen Gewichten wie Qwen3, Llama, die Familien Mistral / Mixtral, gpt-oss, bereitgestellt mit vLLM oder Ollama; Embeddings mit bge-m3 oder Qwen-Embedding-Modellen.
• Stack: Qdrant oder pgvector, n8n, Langfuse fürs Tracing.
• Hardware: HW3 für ein Modell der 70B-Klasse bei guter Entwurfsqualität; HW2 funktioniert mit Modellen um 30B, wenn die Ausgaben genau geprüft werden. Lohnt sich, wenn Interviews vertrauliche oder personenbezogene Daten enthalten.

Weg D — Eigenes Training

Selten gerechtfertigt. Feintuning auf den freigegebenen Anforderungen einer Organisation (einige Hundert bis wenige Tausend Elemente mit Quelltexten) kann Hausstil und Fachvokabular durchsetzen, doch Prompting plus Abruf von Beispielen erreicht meist das Meiste davon.

Stand der Technik (2026)

• LLMs schreiben aus klaren Eingaben flüssige, gut strukturierte Stories und Akzeptanzkriterien; die Qualität sinkt bei verrauschten Transkripten, implizitem Fachwissen und Konflikten zwischen mehreren Beteiligten [1].
• Typische Fehlerbilder: erfundene Anforderungen, die niemand wollte, stilles Auflösen von Konflikten statt sie aufzuzeigen, zu allgemeine Stories, fehlende nichtfunktionale Anforderungen und eine Verzerrung zugunsten des lautesten Sprechers im Transkript.
• Hilfreiche Techniken: schemabeschränkte Ausgaben, verpflichtende Quellzitate, getrennte Durchgänge für „Extrahieren“ und „Kritisieren“, Abruf vorhandener Anforderungen, EARS-Vorlagen und das Erzeugen von Rückfragen, statt zu raten.
• Agenten-Setups verknüpfen Anforderungen mit Code und Tests: Werkzeuge für spezifikationsgetriebene Entwicklung (z. B. GitHub Spec Kit, Kiro) lassen Spezifikationen Coding-Agenten steuern (CODE-002), sodass die Anforderungsqualität die Codequalität nun unmittelbar bestimmt.
• Multi-Agenten-Persona-Simulation für die Erhebung bleibt im Forschungsstadium [2].

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack wie Besprechungszusammenfassung und DOC-015 (Ausschreibungsanalyse): ASR + LLM + Retrieval; ein selbst betriebener LLM-Server bedient alle.
• Nachgelagert: CODE-004 (Tests aus Akzeptanzkriterien), CODE-002 (Coding-Agenten, die Spezifikationen verarbeiten), CODE-006 (Dokumentation), CODE-007 (Prototyp aus Beschreibung), CODE-014 (Rückkopplung aus der Fehler-Triage).
• Regulatorische Regeln als Anforderungen: CODE-025 macht aus Gesetzgebung ausführbare Logik.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen, Preise je Arbeitsplatz für die Werkzeuge.
• Weg B: 1-3 Monate für Pipeline, Vorlagen und Jira-Integration; die Kosten entstehen vor allem durch Transkription und LLM-Tokens (klein gegenüber der Arbeitszeit der Analysten).
• Weg C: 2-4 Monate; GPU-Server plus Betrieb.
• Kennzahlen: Bearbeitungsquote des Analysten je erzeugtem Element, Anteil unverändert akzeptierter Anforderungen, Nacharbeit/Änderungswünsche nach Sprintbeginn, auf Anforderungsfehler zurückgeführte Defekte, Zeit vom Workshop bis zum verfeinerten Backlog, Durchlaufzeit der Stakeholder-Validierung.

Menschen & Veränderung

Einbinden: die Geschäftsleitung als Sponsor, die Abteilungsleitung als Verantwortliche für den Anforderungsprozess, die Endanwender (Business-Analysten, Product Owner, Entwickler), die Stakeholder, deren Aussagen verarbeitet werden, die IT, die bzw. den Datenschutzbeauftragten sowie Recht/Compliance. Kunden und externe Stakeholder sollten informiert werden, wenn ihre Aussagen aufgezeichnet und transkribiert werden.

Betriebsrat: kommt darauf an, in der Regel ja, wenn Interviews mit Beschäftigten aufgezeichnet oder ausgewertet werden, weil Transkription und Verschlagwortung von Aussagen technisch zur Verhaltensüberwachung geeignet sind (§ 87 Abs. 1 Nr. 6 BetrVG, BAG: Eignung genügt). Unterrichten nach § 90 Abs. 1 Nr. 3 und vereinbaren, dass die Ergebnisse nicht zur Leistungsbewertung verwendet werden. Öffentlicher Dienst: Personalrat.

Datenschutz: Interviews enthalten personenbezogene Daten, daher sind ein AVV (Art. 28 DSGVO), eine dokumentierte Rechtsgrundlage, Information oder Einwilligung der Teilnehmenden und die Einbindung der bzw. des Datenschutzbeauftragten nötig; eine DSFA ist wahrscheinlich nur bei umfangreichen oder sensiblen Interviews erforderlich (GUIDE-005).

KI-Kompetenz: Analysten mit Schulungen unterstützen, wie KI-erzeugte Anforderungen auf Lücken und erfundene Bedarfe geprüft werden (GUIDE-006).

Pilot und Kommunikation: ein Projekt ausprobieren, in dem Analysten jede erzeugte Anforderung prüfen. Bedenken: „Die KI übersieht Nuancen“ und Überwachung. Beiden begegnen Sie, indem der Analyst Autor bleibt und mit transparenter Einwilligung (GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko; Pflicht zur KI-Kompetenz (Art. 4). Kein Hochrisiko, es sei denn, sie ist in ein Produkt eingebettet, das selbst reguliert ist. Das Aufzeichnen von Teilnehmenden mit Emotions- oder Stimmungserkennung am Arbeitsplatz ist eine nach Art. 5 verbotene Praktik; ergänzen Sie daher keine Emotionsanalyse in der Besprechungsauswertung.
• DSGVO: Aufzeichnungen und Transkripte enthalten personenbezogene Daten von Beschäftigten, Kunden und Nutzern; Rechtsgrundlage, Information der Teilnehmenden, Aufbewahrungsfristen, AVV mit Anbietern, EU-Hosting. Mitbestimmung des Betriebsrats in Deutschland (BetrVG) bei Aufzeichnungswerkzeugen. Personenbezogene Daten in erzeugten Anforderungen minimieren.
• Vertraulichkeit: Transkripte können Geschäftsgeheimnisse enthalten; Enterprise-Tarife ohne Training auf Eingaben oder Weg C bevorzugen.
• Qualität und Haftung: Bei sicherheitskritischen oder regulierten Produkten bleiben Anforderungen menschlich freigegeben (Rückverfolgbarkeit nach ISO 26262, IEC 62304). KI-Vorschläge im Vergleich zum akzeptierten Text protokollieren.
• Gegenmaßnahmen: Einwilligungshinweis, Schwärzungsschritt, Quellzitate, verpflichtende Prüfung, regelmäßige Stichprobenaudits.

Erste Schritte

1. Eine wiederkehrende Besprechungsart (Refinement oder Discovery) auswählen und mit Einwilligung aufzeichnen.
2. Das Zielformat festlegen (User Story + Gherkin oder EARS) und 10 gute Beispiele geben.
3. Eine Entwurfs-Pipeline bauen oder aktivieren; Quellzitate und eine Liste offener Fragen verlangen.
4. 3-4 Sprints im Schattenbetrieb laufen lassen; Bearbeitungsquote und später gefundene Lücken messen.
5. Konsistenzprüfungen gegen das bestehende Backlog ergänzen, dann in das Backlog-Werkzeug exportieren.

Quellen

1. Zadenoori et al. — Large Language Models (LLMs) for Requirements Engineering: A Systematic Literature Review — https://arxiv.org/abs/2509.11446
2. Prompting Strategies for Large Language Models in Requirements Elicitation: A Systematic Literature Review — https://trepo.tuni.fi/handle/10024/232320
3. Atlassian — Rovo product requirements agent — https://www.atlassian.com/software/rovo/use-cases/agent-product-requirements-expert
4. GitHub Docs — Integrating Copilot cloud agent with Azure Boards — https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/integrate-cloud-agent-with-azure-boards
5. pyannote.audio — https://github.com/pyannote/pyannote-audio
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj