{"id":28402,"date":"2026-02-20T14:38:06","date_gmt":"2026-02-20T13:38:06","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=28402"},"modified":"2026-02-20T14:38:08","modified_gmt":"2026-02-20T13:38:08","slug":"ai-aided-requirements-engineering-methodische-integration-von-llms-und-agenten-frameworks-in-den-anforderungsprozess","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/20\/ai-aided-requirements-engineering-methodische-integration-von-llms-und-agenten-frameworks-in-den-anforderungsprozess\/","title":{"rendered":"AI-Aided Requirements Engineering: Methodische Integration von LLMs und Agenten-Frameworks in den Anforderungsprozess"},"content":{"rendered":"\n

Abstract<\/h2>\n

Unklare und unvollst\u00e4ndige Anforderungen gelten als einer der Hauptgr\u00fcnde f\u00fcr das Scheitern von Softwareprojekten. Das vorliegende Paper untersucht den \u00dcbergang von klassischem Requirements Engineering (RE) hin zu einem KI-gest\u00fctzten Anforderungsprozess (AI-Aided RE<\/em>). Zun\u00e4chst wird der Status Quo der Human-AI Collaboration (HAIC) im RE analysiert, wobei die Dominanz explorativer Proof-of-Concept-Ans\u00e4tze gegen\u00fcber produktiven Eins\u00e4tzen herausgestellt wird. Anschlie\u00dfend werden die vier Kernrollen der KI in den RE-Phasen Elicitation, Analysis, Specification und Validation systematisch untersucht. Ein weiterer Schwerpunkt liegt auf strukturierten Prompting-Strategien wie CRAFT und CLEAR die f\u00fcr Denk- und Pr\u00e4zisierungsprozesse fungieren, der KI als Sparringspartner unter Ber\u00fccksichtigung verschiedener Prompting-Strategien, sowie auf dem Paradigmenwechsel hin zu agentischen Frameworks und (semi-)automatisierten Workflows, insbesondere der BMAD-Methode (Breakthrough Method for Agile AI-Driven Development<\/em>). Die Ergebnisse zeigen, dass der Einsatz von Large Language Models (LLMs) im RE erhebliches Potenzial zur Effizienzsteigerung bietet, jedoch der Mensch als Orchestrator und Dom\u00e4nenexperte unverzichtbar bleibt.<\/p>\n

Abstract (English):<\/strong>\nAmbiguous and incomplete requirements remain a leading cause of software project failure. This paper examines the transition from traditional requirements engineering (RE) toward AI-aided RE. It analyses the current state of human-AI collaboration, identifies four core AI roles across the RE lifecycle (elicitation, analysis, specification, validation), and focuses on structured prompting strategies such as CRAFT and CLEAR, which support reasoning and refinement processes with AI as a sparring partner, as well as the paradigm shift toward agentic frameworks and (semi-)automated workflows, particularly the BMAD method. Results indicate that LLMs offer significant efficiency gains in RE, yet human oversight as orchestrator and domain expert remains essential.<\/p>\n

Keywords:<\/strong> Requirements Engineering, Large Language Models, Human-AI Collaboration, BMAD-Methode, Prompt Engineering, Agentische Systeme<\/p>\n

I. Einleitung<\/h2>\n

A. Ziel der Arbeit<\/h3>\n

Das vorliegende Paper untersucht die Integration von Large Language Models (LLMs) in den RE-Prozess. Es evaluiert sowohl methodische Ans\u00e4tze auf der Ebene des Prompt Engineerings als auch architekturelle Konzepte auf der Ebene agentischer Systeme und der BMAD-Methode. Ziel ist es, aufzuzeigen, wie KI-gest\u00fctzte Werkzeuge den RE-Prozess in seinen verschiedenen Phasen unterst\u00fctzen k\u00f6nnen, wo ihre Grenzen liegen und welche Entwicklungen f\u00fcr die Zukunft zu erwarten sind. Die Arbeit richtet sich an Softwareingenieure, Projektmanager und Studierende, die den aktuellen Stand der Forschung und Praxis im Bereich AI-Aided RE verstehen m\u00f6chten.<\/p>\n

II. Grundlagen und Status Quo<\/h2>\n

Das Requirements Engineering l\u00e4sst sich als eine systematische Vorgehensweise zur Erhebung, Dokumentation, Pr\u00fcfung und Verwaltung von Anforderungen definieren [2]. F\u00fcr Projekte ist ein gutes Requirements Engineering unerl\u00e4sslich. Es f\u00fchrt unter anderem dazu, dass die Erwartungen der Stakeholder klar sind und alle Beteiligten auf dem aktuellen Stand sind sowie dasselbe Verst\u00e4ndnis f\u00fcr die Anforderungen haben. Diese gro\u00dfe Bedeutung des Requirements Engineering und die Fortschritte im Bereich der K\u00fcnstlichen Intelligenz machen es notwendig, sich damit zu befassen, wie K\u00fcnstliche Intelligenz im Requirements Engineering produktiv eingesetzt werden kann. [1] [2]<\/p>\n

In diesem Kapitel werden zun\u00e4chst die zentralen Aufgaben des Requirements Engineering beschrieben. Darauffolgend wird der momentane Status Quo bei der Nutzung von K\u00fcnstlicher Intelligenz im Requirements Engineering besprochen.<\/p>\n

A. Klassische Aufgaben des Requirements Engineering<\/h3>\n

Das Requirements Engineering kennt vier Hauptaufgaben. Die erste der vier Hauptaufgaben ist die Erhebung von Anforderungen. Dabei geht es nicht nur darum, die Anforderungen selbst zu ermitteln, sondern auch zun\u00e4chst die Stakeholder des Projektes zu identifizieren. Zur Ermittlung der Anforderungen k\u00f6nnen verschiedene Methoden angewandt werden. Zu diesen geh\u00f6ren das Durchf\u00fchren von Interviews oder Workshops und die Analyse von bereits bestehenden Dokumenten. [1] [2] [3] [4]<\/p>\n

Die zweite Aufgabe ist die Dokumentation der erhobenen Anforderungen. Dabei muss entschieden werden, in welcher Form diese dokumentiert werden sollen. F\u00fcr die Art der Dokumentation gibt es verschiedene M\u00f6glichkeiten. Im Fall des klassischen Projektmanagements ist das in der Regel ein Pflichten- und\/oder Lastenheft. Bei agilem Projektmanagement werden stattdessen Epics und User-Stories verwendet. Auch k\u00f6nnen UML-Diagramme zur Dokumentation erstellt werden. Die Anforderungen m\u00fcssen bei der Dokumentation in funktionale sowie nicht-funktionale gruppiert werden. Au\u00dferdem sollte den Anforderungen in der Dokumentation eine Priorit\u00e4t zugeordnet werden. Weiterhin m\u00fcssen alle Projektbeteiligten immer auf die f\u00fcr sie relevanten Teile der Dokumentation zugreifen k\u00f6nnen. [1] [2] [3] [4] [5]<\/p>\n

Bei der dritten Aufgabe handelt es sich um die Pr\u00fcfung und Abstimmung der Anforderungen. Durch die Pr\u00fcfung der Anforderungen, soll sichergestellt werden, dass die Anforderungen vollst\u00e4ndig, sowie in sich konsistent und fehlerfrei sind. Um dies zu erreichen, m\u00fcssen alle Anforderungen immer mit allen Stakeholdern abgestimmt werden. [1] [2] [3] [4]<\/p>\n

Die letzte der vier Aufgaben ist das Management von Anforderungen. Streng genommen geh\u00f6rt dies zu einem eigenen Feld des Requirement Managements. Beide sind allerdings eng miteinander verbunden und oft wird das Requirement Engineering als \u00dcberbegriff genutzt [3]. Das Anforderungsmanagement beinhaltet die Versionierung der Dokumentation der Anforderungen, die Priorisierung der Anforderungen und einen Prozess f\u00fcr das Management von \u00c4nderungen an den Anforderungen. Ein \u00c4nderungsmanagement wird ben\u00f6tigt, um sicherzustellen, dass mit Anforderungs\u00e4nderungen umgegangen werden kann. [1] [2] [3] [4]<\/p>\n

Wichtig ist auch, dass diese Aufgaben nicht einmalig in der Anfangsphase eines Projektes zu erledigen sind. Es handelt sich hierbei um einen st\u00e4ndigen Prozess, dessen Aufgaben \u00fcber die gesamte Dauer eines Projektes immer wieder erledigt werden m\u00fcssen. [1] [3]<\/p>\n

B. KI im Requirements Engineering: Der Status Quo<\/h3>\n

Die systematische Analyse des aktuellen Forschungsstands zeigt, dass der Einsatz generativer KI im Requirements Engineering sich noch \u00fcberwiegend in einer explorativen Phase befindet. Die umfassende Systematic Literature Review von Cheng et al., die 238 Prim\u00e4rstudien analysiert, belegt, dass \u00fcber 90 % der untersuchten Ans\u00e4tze dem Stadium fr\u00fcher Entwicklung (early-stage development<\/em>) zuzuordnen sind, w\u00e4hrend lediglich 1,3 % der L\u00f6sungen einen produktiven Einsatz in industriellen Kontexten erreichen [6]. Diese Diskrepanz verdeutlicht, dass trotz der rasanten Fortschritte im Bereich generativer KI die praktische Reife der Werkzeuge f\u00fcr den unternehmensweiten Einsatz noch nicht gegeben ist.<\/p>\n

Die Praxisperspektive wird durch die Umfrage von Rani et al. unter 55 Industriepraktikern erg\u00e4nzt. Ihre Ergebnisse zeigen, dass bereits 58,2 % der befragten Praktiker KI-Werkzeuge in ihrem RE-Prozess einsetzen [7]. Im Hinblick auf den Grad der Automatisierung dominiert dabei das Paradigma der Human-AI Collaboration<\/em> (HAIC): Je nach RE-Phase setzen zwischen 49,2 % und 60,5 % der Befragten auf eine kollaborative Interaktion zwischen menschlichen Analysten und KI-Systemen [7]. Vollst\u00e4ndig automatisierte Ans\u00e4tze, bei denen die KI den RE-Prozess autonom durchf\u00fchrt, bilden hingegen mit 3,8 % bis 7,6 % eine deutliche Nische. Bemerkenswert ist zudem die \u00fcberwiegend positive Wahrnehmung: 69,1 % der Befragten bewerten den KI-Einsatz im RE als positiv oder sehr positiv [7].<\/p>\n

Die Rolle des Menschen im KI-gest\u00fctzten RE-Prozess bleibt dennoch von zentraler Bedeutung. Abbasi et al. formalisieren diese Notwendigkeit im HARE-SM-Framework, das vier S\u00e4ulen definiert: Human-in-the-Loop Validation<\/em>, Explainability & Transparency<\/em>, Bias Mitigation<\/em> und Stakeholder Trust Calibration<\/em> [8]. Dieses Framework unterstreicht, dass der Mensch nicht nur als letzter Entscheider fungiert, sondern aktiv in die Gestaltung und \u00dcberwachung des KI-gest\u00fctzten Prozesses eingebunden sein muss. Der kollaborative Ansatz erm\u00f6glicht es, die St\u00e4rken beider Seiten zu nutzen: die Verarbeitungskapazit\u00e4t und Konsistenz der KI auf der einen Seite und das kontextuelle Verst\u00e4ndnis sowie die kreative Urteilskraft des Menschen auf der anderen Seite.<\/p>\n

III. KI-Rollen im RE-Prozesslebenszyklus<\/h2>\n

Dieses Kapitel analysiert die spezifischen Einsatzszenarien von Large Language Models in den vier etablierten Phasen des Requirements Engineering. Dabei wird f\u00fcr jede Phase eine charakteristische Rolle der KI identifiziert, die das Zusammenspiel zwischen menschlichem Analysten und KI-System beschreibt. Die Systematik orientiert sich an der von Cheng et al. identifizierten Verteilung der Forschungsaktivit\u00e4ten: Anforderungsanalyse bildet mit 30 % den am h\u00e4ufigsten untersuchten Bereich, gefolgt von Elicitation mit 22,1 % und Management mit 6,8 % [6].<\/p>\n

A. Elicitation: Die KI als Assistent<\/h3>\n

Die Anforderungserhebung (Elicitation<\/em>) stellt den initialen und h\u00e4ufig aufwendigsten Schritt im RE-Prozess dar. Traditionell erfolgt sie \u00fcber Interviews, Workshops und Dokumentenanalysen, die einen erheblichen manuellen Aufwand erfordern. LLMs k\u00f6nnen in dieser Phase als Assistenten eingesetzt werden, indem sie gro\u00dfe Datenmengen aus verschiedenen Quellen \u2013 wie Meeting-Transkripten, E-Mail-Korrespondenzen und bestehenden Dokumentationen \u2013 verarbeiten und erste Anforderungsentw\u00fcrfe extrahieren [6].<\/p>\n

Ein konkreter Anwendungsfall ist die automatisierte Extraktion von Anforderungen aus unstrukturiertem Input. Beispielsweise kann ein LLM eine aufgezeichnete Stakeholder-Besprechung transkribieren und daraus initiale funktionale sowie nicht-funktionale Anforderungen ableiten. Cheng et al. identifizieren in ihrer SLR die Anforderungsextraktion als eine der zentralen GenAI-F\u00e4higkeiten, bei der das Modell relevante Informationsfragmente erkennt und in eine vorl\u00e4ufige Anforderungsliste \u00fcberf\u00fchrt [6]. Die Umfrage von Rani et al. best\u00e4tigt die praktische Relevanz: In der Elicitation-Phase setzen 49,2 % der befragten Praktiker auf Human-AI Collaboration, w\u00e4hrend lediglich 5,4 % eine vollautomatisierte Erhebung praktizieren [7]. Die Qualit\u00e4t dieser Erstergebnisse h\u00e4ngt dabei ma\u00dfgeblich von der Promptgestaltung und dem bereitgestellten Kontext ab, was die Bedeutung strukturierter Prompting-Strategien unterstreicht (vgl. Kapitel IV).<\/p>\n

B. Analysis: Die KI als Pr\u00fcfer<\/h3>\n

In der Analysephase \u00fcbernimmt die KI die Rolle eines systematischen Pr\u00fcfers. Zentrale Aufgaben umfassen die Klassifizierung von Anforderungen in funktionale (FA) und nicht-funktionale Anforderungen (NFA) sowie die Erkennung von Konflikten, Redundanzen und Inkonsistenzen innerhalb der Anforderungsliste. Cheng et al. identifizieren die Anforderungsanalyse mit 30 % als den am intensivsten erforschten RE-Teilbereich im Kontext generativer KI [6].<\/p>\n

LLMs haben gezeigt, dass sie bei der Klassifizierung von Anforderungen in FA und NFA eine hohe Genauigkeit erreichen k\u00f6nnen. Dar\u00fcber hinaus sind sie in der Lage, semantische \u00dcberlappungen zu identifizieren \u2013 etwa wenn zwei Stakeholder funktional identische Anforderungen unterschiedlich formulieren (z. B. \u201eUser Authentication" vs. \u201eSichere Registrierung"). Insbesondere Transformer-basierte Modelle liefern dabei vielversprechende Ergebnisse bei der automatisierten Klassifikation [6].<\/p>\n

Gleichzeitig ist zu beachten, dass die Analyse dom\u00e4nenspezifischer Anforderungen \u2013 insbesondere in regulierten Umgebungen wie dem Gesundheitswesen oder der Finanzbranche \u2013 weiterhin menschliche Expertise erfordert. Cheng et al. identifizieren die mangelnde Reproduzierbarkeit mit 66,8 % als die h\u00e4ufigste technische Limitation. Das Halluzinationsrisiko folgt als zweith\u00e4ufigste Limitation, wobei 63,4 % der untersuchten Studien von Problemen mit fehlerhaft generierten Inhalten berichten [6]. Abbasi et al. adressieren dieses Risiko durch die S\u00e4ule Explainability & Transparency<\/em> im HARE-SM-Framework, die eine nachvollziehbare Begr\u00fcndung aller KI-Ergebnisse fordert [8].<\/p>\n

C. Specification: Die KI als Co-Autor<\/h3>\n

Die Spezifikationsphase transformiert analysierte Anforderungen in strukturierte, standardisierte Formate. In dieser Rolle agiert die KI als Co-Autor, der den menschlichen Analysten bei der Erstellung formalisierter Dokumente unterst\u00fctzt.<\/p>\n

Typische Einsatzszenarien umfassen die Transformation von Rohanforderungen in strukturierte User Stories nach dem Schema Als [Rolle] m\u00f6chte ich [Funktion], damit [Nutzen]<\/em>, die Erstellung von Product Requirement Documents (PRD) sowie die Generierung von Akzeptanzkriterien [6]. Dabei kann das LLM templatespezifische Dokumentenstrukturen einhalten und konsistente Formatierungen sicherstellen. Rani et al. berichten, dass in der Spezifikationsphase der Anteil von Human-AI Collaboration mit 54,1 % besonders hoch ist, was die Bedeutung dieser Phase f\u00fcr den kollaborativen KI-Einsatz unterstreicht [7].<\/p>\n

Ein wesentlicher Vorteil besteht in der Skalierbarkeit: W\u00e4hrend ein menschlicher Analyst f\u00fcr die Ausformulierung einer umfangreichen Anforderungsliste Stunden ben\u00f6tigt, kann ein LLM innerhalb von Sekunden erste Entw\u00fcrfe generieren, die anschlie\u00dfend vom Fachexperten validiert und verfeinert werden. Allerdings identifizieren Cheng et al. die mangelnde Reproduzierbarkeit als kritische Limitation: 66,8 % der Studien berichten von Herausforderungen bei der Konsistenz wiederholter Generierungsl\u00e4ufe [6].<\/p>\n

D. Validation: Die KI als Qualit\u00e4tssicherer<\/h3>\n

In der abschlie\u00dfenden Validierungsphase fungiert die KI als Qualit\u00e4tssicherer, der die erstellten Anforderungen auf formale und inhaltliche Korrektheit pr\u00fcft. Ein zentrales Konzept ist hierbei die Erkennung sogenannter Requirement Smells<\/em> \u2013 also Muster, die auf potenzielle Qualit\u00e4tsprobleme hinweisen [6].<\/p>\n

Zu den h\u00e4ufigsten Requirement Smells z\u00e4hlen Mehrdeutigkeit, etwa durch Verwendung vager Begriffe wie \u201eschnell" oder \u201ebenutzerfreundlich", Unvollst\u00e4ndigkeit sowie mangelnde Testbarkeit. LLMs k\u00f6nnen solche Muster systematisch identifizieren und Verbesserungsvorschl\u00e4ge generieren. Abbasi et al. betonen in ihrem Framework die Notwendigkeit einer Human-in-the-Loop Validation<\/em> gerade in dieser Phase, da die endg\u00fcltige Bewertung der Anforderungsqualit\u00e4t dom\u00e4nenspezifisches Expertenwissen voraussetzt [8].<\/p>\n

Dar\u00fcber hinaus k\u00f6nnen LLMs Testf\u00e4lle aus bestehenden Anforderungen ableiten, um die Testbarkeit sicherzustellen. Cheng et al. berichten, dass die automatisierte Generierung von Testf\u00e4llen aus Anforderungsdokumenten ein wachsendes Forschungsfeld darstellt, wobei allerdings die Interpretierbarkeit der Ergebnisse mit 57,1 % als dritth\u00e4ufigste Limitation identifiziert wird [6]. Die Kombination von Chain-of-Thought Prompting<\/em> und dom\u00e4nenspezifischem Kontext liefert hierbei vielversprechende Resultate zur Verbesserung der Nachvollziehbarkeit.<\/p>\n

IV. Methodik und Prompting-Strategien<\/h2>\n

Dieses Kapitel untersucht die methodischen Grundlagen des Prompt Engineerings im AI-gest\u00fctzten Requirements Engineering. Es werden sowohl die Grenzen einfacher, naiver Ans\u00e4tze als auch die Vorteile strukturierter Frameworks und Strategien vorgestellt. Ziel ist es, den \u00dcbergang von explorativen zu reproduzierbaren und qualitativ hochwertigen Interaktionen mit Sprachmodellen nachzuvollziehen.<\/p>\n

A. Grenzen naiver Ans\u00e4tze<\/h3>\n

Ein h\u00e4ufiger Einstieg in AI-gest\u00fctztes Requirements Engineering besteht in der Verwendung einfacher, wenig spezifizierter Prompts. Dieser Ansatz zeichnet sich durch minimale Vorbereitung, geringe Kontextbereitstellung und fehlende strukturelle Vorgaben aus. Obwohl solche Interaktionen eine schnelle Generierung von Antworten erm\u00f6glichen, zeigen sich in der Praxis signifikante Qualit\u00e4tsprobleme.<\/p>\n

Insbesondere f\u00fchren unstrukturierte Eingaben h\u00e4ufig zu unvollst\u00e4ndigen, inkonsistenten oder falsch interpretierten Anforderungen. Zudem kann das erzeugte Ausgabeformat stark variieren, was eine direkte Weiterverarbeitung erschwert. Diese Problematik l\u00e4sst sich darauf zur\u00fcckf\u00fchren, dass gro\u00dfe Sprachmodelle probabilistisch arbeiten und daher stark von der Qualit\u00e4t der Eingabeinstruktionen abh\u00e4ngen [9] [10]. Fehlen klare Vorgaben zu Kontext, Ziel oder Struktur, entstehen Ergebnisse, die eher explorativ als reproduzierbar sind [11].<\/p>\n

Ein weiterer Nachteil naiver Ans\u00e4tze ist die mangelnde Nachvollziehbarkeit der Generierungsschritte sowie potenzielle Halluzinationen [11] [12]. Ohne explizite Strukturierung oder Validierungsmechanismen bleibt unklar, auf welcher Grundlage bestimmte Anforderungen formuliert wurden. Dies erschwert insbesondere in sicherheitskritischen oder regulierten Projekten die notwendige Dokumentation und \u00dcberpr\u00fcfbarkeit.<\/p>\n

Der naive Prompting-Ansatz kann daher als exploratives Werkzeug f\u00fcr fr\u00fche Ideationsphasen betrachtet werden, ist jedoch f\u00fcr systematische Requirements-Engineering-Prozesse nur eingeschr\u00e4nkt geeignet. F\u00fcr produktive Einsatzszenarien sind strukturierte und methodisch fundierte Prompting-Strategien erforderlich.<\/p>\n

B. Strukturierte Prompting-Frameworks<\/h3>\n

Um die genannten Einschr\u00e4nkungen zu adressieren, wurden strukturierte Prompting-Frameworks entwickelt, die als methodische Leitlinien f\u00fcr die Interaktion mit Sprachmodellen dienen. Zu den verbreiteten Ans\u00e4tzen z\u00e4hlen unter anderem die Frameworks CRAFT und CLEAR, welche standardisierte Prompt-Bausteine definieren [13] [14] [15].<\/p>\n

Diese Frameworks legen fest, dass effektive Prompts typischerweise mehrere Elemente enthalten sollten, darunter Kontextinformationen, Rollenbeschreibungen, konkrete Aufgabenstellungen, gew\u00fcnschte Ausgabeformate sowie stilistische Vorgaben [13] [14]. Beispiele k\u00f6nnen ebenfalls als Prompt-Baustein herangezogen werden [14]. Durch diese explizite Strukturierung wird die Interpretation des Modells gelenkt und die Varianz der Antworten reduziert.<\/p>\n

Des Weiteren existieren allgemeine Gestaltungsprinzipien f\u00fcr die Entwicklung effektiver Prompts, die nicht prim\u00e4r als Strukturrahmen, sondern als Leitlinien f\u00fcr Formulierung und Iteration dienen. Auch hierf\u00fcr wird teilweise das Akronym CLEAR [16] verwendet, allerdings mit einer anderen semantischen Auslegung als in den zuvor beschriebenen Frameworks.<\/p>\n

Die Komponenten dieses alternativen CLEAR-Modells [16] werden im Folgenden er\u00f6rtert:<\/p>\n

    \n
  • \n

    Concise<\/strong> beschreibt die Notwendigkeit pr\u00e4ziser, verst\u00e4ndlicher und m\u00f6glichst knapper Formulierungen. Unn\u00f6tige Details, redundante Informationen oder sprachliche H\u00f6flichkeitsfloskeln sollten vermieden werden, da sie die semantische Interpretation durch das Modell erschweren k\u00f6nnen. Besonders relevant ist hierbei die Priorisierung zentraler Informationen, die m\u00f6glichst fr\u00fch im Prompt positioniert werden sollten. [16]<\/p>\n<\/li>\n

  • \n

    Logical<\/strong> betont die Bedeutung einer koh\u00e4renten und strukturierten Darstellung der Anfrage. Anforderungen oder Instruktionen sollten in logisch nachvollziehbarer Reihenfolge formuliert sein, sodass das Modell den intendierten Ablauf der Aufgabe eindeutig rekonstruieren kann. [16]<\/p>\n<\/li>\n

  • \n

    Explicit<\/strong> wird die explizite Spezifikation von Erwartungen verstanden. Dazu z\u00e4hlen klare Angaben zu Ausgabeformat, Detailgrad, Umfang sowie gew\u00fcnschtem Stil oder Perspektive. Je eindeutiger diese Parameter definiert sind, desto geringer ist die Varianz der generierten Ergebnisse.<\/p>\n<\/li>\n

  • \n

    Adaptive<\/strong> verweist darauf, dass Prompt Engineering als iterativer Prozess betrachtet werden sollte. Effektive Prompts entstehen selten im ersten Versuch, sondern durch schrittweises Testen, Anpassen und Kombinieren unterschiedlicher Strategien. Dieser iterative Charakter \u00e4hnelt klassischen Optimierungsprozessen in der Softwareentwicklung. [16]<\/p>\n<\/li>\n

  • \n

    Reflective<\/strong> beschreibt die Notwendigkeit systematischer Ergebnisbewertung. Generierte Antworten sollten kritisch \u00fcberpr\u00fcft, validiert und mit den urspr\u00fcnglichen Anforderungen abgeglichen werden. Erkenntnisse aus solchen Evaluationsschritten k\u00f6nnen genutzt werden, um zuk\u00fcnftige Prompts gezielt zu verbessern und die Modellinteraktion langfristig zu optimieren. [16]<\/p>\n<\/li>\n<\/ul>\n

    Zusammenfassend stellt dieses CLEAR-Modell keinen strukturellen Promptaufbau dar, sondern ein heuristisches Regelwerk zur Qualit\u00e4tssicherung von Promptformulierungen. W\u00e4hrend Frameworks wie CRAFT oder formale Promptstrategien die Architektur einer Anfrage definieren [13] [14], liefert dieser Ansatz praktische Richtlinien f\u00fcr deren sprachliche und methodische Ausgestaltung [16].<\/p>\n<\/div>\n\n\n\n

    \"\"
    Abbildung 1. \u2018CLEAR\u2019-Akronym im Bereich Prompt-Gestaltung<\/em><\/figcaption><\/figure>\n\n\n\n

    Neben solchen Frameworks existieren spezifische Prompting-Strategien, die f\u00fcr komplexe reasoning-intensive Aufgaben entwickelt wurden [11]. Eine der bekanntesten Methoden ist Chain-of-Thought Prompting, bei dem das Modell aufgefordert wird, seine Zwischenschritte explizit darzustellen [11]. Studien zeigen, dass dieser und weitere Ans\u00e4tze die logische Konsistenz und Genauigkeit von Modellantworten signifikant verbessern k\u00f6nnen [11].<\/p>\n

    Weitere Strategien umfassen unter anderem:<\/p>\n

      \n
    • Chain-of-Verification<\/strong>: interne Pr\u00fcfung von Modellantworten vor der finalen Ausgabe zur Fehlerreduktion [11]<\/li>\n
    • Thread-of-Thought<\/strong>: Segmentierung gro\u00dfer Kontexte in analysierbare Teilabschnitte [11]<\/li>\n
    • Logic-of-Thought<\/strong>: Integration formaler Logikstrukturen in Promptinstruktionen [11]<\/li>\n
    • Explicit Schema Enforcement<\/strong>: Erzwingen strukturierter Ausgabeformate (z. B. JSON)<\/li>\n<\/ul>\n

      Diese Strategien verfolgen ein gemeinsames Ziel: die Transformation eines generativen Sprachmodells von einem explorativen Textgenerator zu einem reproduzierbaren Analysewerkzeug [9]. Empirische Untersuchungen zeigen, dass strukturierte Prompts insbesondere bei komplexen Aufgabenstellungen deutliche Qualit\u00e4tsgewinne gegen\u00fcber unstrukturierten Eingaben erzielen [11].<\/p>\n

      Daraus l\u00e4sst sich ableiten, dass Prompt Engineering eine zentrale methodische Kompetenz im AI-Aided Requirements Engineering darstellt und vergleichbar mit Modellierungstechniken klassischer Softwaretechnik betrachtet werden kann.<\/p>\n

      C. KI-Sparring Partner<\/h3>\n

      Neben der Optimierung einzelner Prompts hat sich ein dialogbasierter Ansatz etabliert, bei dem das Sprachmodell nicht als passiver Antwortgenerator, sondern als aktiver Interaktionspartner eingesetzt wird. Dieses Konzept wird h\u00e4ufig als KI-Sparring Partner bezeichnet [12].<\/p>\n

      In diesem Modus wird das Modell gezielt angewiesen, R\u00fcckfragen zu stellen, Unklarheiten zu identifizieren und Vorschl\u00e4ge kritisch zu hinterfragen [12]. Dadurch entsteht ein iterativer Dialog, der dem klassischen Requirements-Engineering-Interview \u00e4hnelt. Der Fokus verschiebt sich von einmaliger Anforderungsgenerierung hin zu kollaborativer Anforderungsentwicklung.<\/p>\n

      Der Einsatz eines solchen Sparring-Partners erweist sich insbesondere in Situationen als hilfreich, in denen Stakeholder nur eingeschr\u00e4nkt verf\u00fcgbar sind oder Anforderungen zun\u00e4chst vage formuliert wurden. Durch strukturierte R\u00fcckfragen kann die KI dabei helfen, implizite Annahmen sichtbar zu machen [12] und Anforderungen zu pr\u00e4zisieren.<\/p>\n

      Gleichzeitig bestehen klare Grenzen dieses Ansatzes. Ein Sprachmodell besitzt kein echtes Dom\u00e4nenverst\u00e4ndnis [12] [17] und kann reale Stakeholder nicht ersetzen. Der KI-Sparring Partner sollte daher als unterst\u00fctzendes Werkzeug verstanden werden, das menschliche Analyseprozesse erg\u00e4nzt, jedoch nicht substituiert.<\/p>\n

      Zusammenfassend l\u00e4sst sich feststellen, dass dialogbasierte KI-Nutzung eine vielversprechende Erweiterung klassischer Requirements-Engineering-Methoden darstellt, insbesondere wenn sie mit strukturierten Prompting-Strategien kombiniert wird.<\/p>\n

      V. Agentische Systeme und BMAD-Methode<\/h2>\n

      In diesem Kapitel steht der \u00dcbergang von ad-hoc Prompting zu systematischem KI-Engineering im Mittelpunkt. Es werden agentische Architekturen und die BMAD-Methode vorgestellt, die eine modulare, transparente und evaluierbare Nutzung von KI im Requirements Engineering erm\u00f6glichen. Damit wird gezeigt, wie komplexe Aufgaben in definierte Verarbeitungsschritte \u00fcberf\u00fchrt werden k\u00f6nnen, um Zuverl\u00e4ssigkeit und Nachvollziehbarkeit zu erh\u00f6hen.<\/p>\n

      A. Paradigmenwechsel: Von Prompting zu Engineering<\/h3>\n

      Fr\u00fche Anwendungen generativer KI basierten prim\u00e4r auf experimentellen Promptformulierungen und wurden h\u00e4ufig als Black-Box-Systeme wahrgenommen [10]. Diese Herangehensweise erschwerte die Nachvollziehbarkeit von Ergebnissen und stand im Widerspruch zu den Anforderungen systematischer Softwareentwicklung, die Reproduzierbarkeit, Dokumentation und Validierbarkeit erfordern.<\/p>\n

      Mit zunehmender Integration von KI in Entwicklungsprozesse vollzieht sich daher ein Paradigmenwechsel: Der Fokus verschiebt sich von spontaner Promptgestaltung hin zu strukturierten, ingenieursm\u00e4\u00dfigen Vorgehensweisen. Prompting wird nicht l\u00e4nger als ad-hoc Interaktion verstanden, sondern als konfigurierbarer Bestandteil eines definierten Systems.<\/p>\n

      Dieser Wandel zeigt sich insbesondere in der Entwicklung agentischer Architekturen, in denen mehrere spezialisierte KI-Komponenten definierte Rollen \u00fcbernehmen [17] [10]. Durch die Aufteilung komplexer Aufgaben in klar abgegrenzte Verarbeitungsschritte wird die Transparenz erh\u00f6ht und die Wartbarkeit verbessert [17]. Gleichzeitig lassen sich einzelne Komponenten gezielt evaluieren und optimieren [10].<\/p>\n

      Der \u00dcbergang von experimentellem Prompting zu systematischem KI-Engineering stellt somit einen zentralen Schritt dar, um generative Modelle zuverl\u00e4ssig in professionelle Requirements-Engineering-Prozesse zu integrieren.<\/p>\n

      B. Die BMAD-Architektur<\/h3>\n

      Die Breakthrough Method for Agile AI-Driven Development<\/em> (BMAD) stellt einen strukturierten Ansatz dar, der den \u00dcbergang von ad-hoc-Prompting zu einem systematischen, ingenieursm\u00e4\u00dfigen Einsatz von KI-Agenten im Softwareentwicklungsprozess formalisiert [18]. Im Gegensatz zu isolierten LLM-Interaktionen verfolgt BMAD das Ziel, spezialisierte KI-Agenten als virtuelle Teammitglieder zu orchestrieren, die gemeinsam an der Erstellung und Verfeinerung von Projektartefakten arbeiten.<\/p>\n

      Philosophie und Kernprinzipien<\/h4>\n

      Die BMAD-Philosophie basiert auf vier Grundpfeilern: Collaboration<\/em>, Optimization<\/em>, Reflection<\/em> und Engine<\/em> (CORE) [18]. Collaboration<\/em> beschreibt die strukturierte Zusammenarbeit spezialisierter Agenten \u2013 darunter Analyst, Product Manager, Architekt und Scrum Master \u2013 die jeweils dom\u00e4nenspezifische Expertise einbringen. Optimization<\/em> zielt auf die iterative Verbesserung der generierten Artefakte durch Feedback-Schleifen zwischen den Agenten. Reflection<\/em> fordert von jedem Agenten eine kritische Selbstbewertung seiner Ergebnisse, bevor diese an den n\u00e4chsten Agenten weitergegeben werden. Die Engine<\/em> bildet die technische Infrastruktur, die den Agenten-Workflow orchestriert und die Konsistenz der Artefakte sicherstellt.<\/p>\n

      Paradigmen: Agentic Planning, Agent-as-Code, Context-Engineering<\/h4>\n

      BMAD basiert auf drei zentralen Paradigmen [18]:<\/p>\n

      Agentic Planning<\/em> beschreibt den \u00dcbergang von konventioneller, rein menschengetriebener Anforderungserhebung hin zu einem kollaborativen \u00d6kosystem, in dem spezialisierte KI-Agenten als virtuelle Teammitglieder fungieren. Der Analyst-Agent identifiziert Projektanforderungen, der Product-Manager-Agent erstellt das PRD, und der Architekt-Agent leitet daraus die technische Architektur ab.<\/p>\n

      Das Agent-as-Code<\/em>-Paradigma definiert Agenten nicht als monolithische Modellinstanzen, sondern als konfigurierbare Codeeinheiten mit expliziten Rollen, Werkzeugen und Einschr\u00e4nkungen. Dies erm\u00f6glicht eine versionierbare, reproduzierbare und auditierbare KI-Nutzung \u2013 ein wesentlicher Vorteil gegen\u00fcber der \u201eBlack Box"-Problematik unkontrollierter LLM-Interaktionen.<\/p>\n

      Context-Engineering<\/em> adressiert das Problem des Context Collapse<\/em> \u2013 den schleichenden Verlust von Projektverst\u00e4ndnis bei zunehmender Komplexit\u00e4t [18]. Durch einen sogenannten Epic-Sharding-Prozess<\/em> wird das umfassende PRD systematisch in fokussierte, in sich geschlossene Entwicklungseinheiten zerlegt, die jedem Agenten den vollst\u00e4ndigen Kontext seiner Aufgabe bereitstellen.<\/p>\n

      Die drei Planning Tracks<\/h4>\n

      BMAD definiert drei skalierbare Planungspfade, die sich nach Projektgr\u00f6\u00dfe und Regulierungsanforderungen richten [18]:<\/p>\n

        \n
      1. Quick Flow:<\/strong> Ein schlanker Ansatz f\u00fcr kleine Projekte, bei dem ausschlie\u00dflich eine technische Spezifikation (Tech-Spec<\/em>) erstellt wird. Geeignet f\u00fcr Prototypen und explorative Vorhaben.<\/li>\n
      2. BMAD Method:<\/strong> Der Standardpfad, der ein vollst\u00e4ndiges PRD, eine Architekturspezifikation und UX-Richtlinien umfasst. Dieser Track eignet sich f\u00fcr mittelgro\u00dfe bis gro\u00dfe Projekte mit mehreren Stakeholdern.<\/li>\n
      3. Enterprise Method:<\/strong> Der umfassendste Planungspfad, der zus\u00e4tzlich zum vollst\u00e4ndigen PRD auch Sicherheits-, Compliance- und Governance-Anforderungen einschlie\u00dft. Dieser Track adressiert die Anforderungen regulierter Industrien.<\/li>\n<\/ol>\n

        Die 4-Phasen-Methodik<\/h4>\n

        Der BMAD-Workflow gliedert sich in vier aufeinanderfolgende Phasen [18]:<\/p>\n

        In der Analysis-Phase<\/strong> analysiert der Analyst-Agent den Projektkontext, identifiziert Stakeholder-Bed\u00fcrfnisse und erstellt eine initiale Anforderungs\u00fcbersicht. Die Planning-Phase<\/strong> \u00fcberf\u00fchrt diese Analyse in ein strukturiertes PRD durch den Product-Manager-Agenten. In der Solutioning-Phase<\/strong> leitet der Architekt-Agent aus dem PRD die technische Architektur, Datenmodelle und Schnittstellenspezifikationen ab. Die abschlie\u00dfende Implementation-Phase<\/strong> \u00fcbergibt die generierten Artefakte an Entwicklungs-Agenten, die den Code auf Basis der vollst\u00e4ndig spezifizierten Anforderungen implementieren.<\/p>\n

        Diese Docs-as-Code-Philosophie \u2013 bei der die Dokumentation und nicht der Code die prim\u00e4re Wahrheitsquelle darstellt \u2013 gew\u00e4hrleistet eine durchg\u00e4ngige Traceability von der Anforderung bis zur Implementierung [18].<\/p>\n

        C. Workflow-Automatisierung<\/h3>\n

        Wie sich bei der BMAD Method auch schon gezeigt hat, liegt ein wesentlicher Vorteil agentischer Systeme in ihrer F\u00e4higkeit, Requirements-Engineering-Aufgaben in automatisierten oder teilautomatisierten Workflows zu organisieren. Hierbei werden spezialisierte KI-Komponenten so orchestriert, dass sie unterschiedliche Prozessschritte \u00fcbernehmen, etwa Anforderungsextraktion, Klassifikation, Priorisierung oder Konsistenzpr\u00fcfung [17].<\/p>\n

        Solche Systeme basieren typischerweise auf modularen Architekturen, in denen einzelne Agenten definierte Rollen erf\u00fcllen und \u00fcber Schnittstellen miteinander kommunizieren [17]. Die Interaktion erfolgt h\u00e4ufig \u00fcber Prompts, strukturierte Datenformate oder Programmierschnittstellen, wodurch komplexe Verarbeitungsketten realisiert werden k\u00f6nnen [17].<\/p>\n

        In praktischen Implementierungen werden hierf\u00fcr h\u00e4ufig Workflow-Plattformen eingesetzt, die externe Tools, Datenquellen und KI-Modelle miteinander verbinden [17]. Diese erm\u00f6glichen es, Requirements-Engineering-Prozesse als orchestrierte Pipelines abzubilden und wiederholt auszuf\u00fchren. Dadurch entstehen reproduzierbare Abl\u00e4ufe, die gegen\u00fcber rein manuellen Vorgehensweisen eine h\u00f6here Konsistenz und Skalierbarkeit aufweisen [10].<\/p>\n

        Ein weiterer Vorteil liegt in der Parallelisierbarkeit. W\u00e4hrend menschliche Analysten nur begrenzt gleichzeitig arbeiten k\u00f6nnen, lassen sich agentische Systeme auf mehrere Projekte oder Datens\u00e4tze gleichzeitig anwenden [17]. Dies kann insbesondere bei gro\u00dfen Projekten zu erheblichen Effizienzgewinnen f\u00fchren.<\/p>\n

        Insgesamt zeigt sich, dass Workflow-Automatisierung einen zentralen Baustein zuk\u00fcnftiger Requirements-Engineering-Prozesse darstellt und eine Br\u00fccke zwischen generativer KI und klassischer Softwaretechnik bildet.<\/p>\n

        VI. Fallstudie: Lernplattform-Projekt<\/h2>\n

        Die zuvor beschriebenen Konzepte agentischer Systeme und automatisierter Workflows bilden die methodische Grundlage f\u00fcr die praktische Umsetzung von AI-Aided Requirements Engineering. W\u00e4hrend Abschnitt V.C die architektonischen Prinzipien solcher Systeme theoretisch erl\u00e4utert hat, demonstriert die folgende Fallstudie deren konkrete Anwendung in einem realit\u00e4tsnahen Szenario.<\/p>\n

        A. Szenario und Datengrundlage<\/h3>\n

        Das Ausgangsszenario f\u00fcr die Fallstudie ist ein studentisches Projekt zur Entwicklung einer Lernplattform. Die grundlegende Idee der Plattform ist die Bereitstellung von Kursen, die von Studierenden belegt werden k\u00f6nnen. Dozenten sollen dabei die Kurse bereitstellen k\u00f6nnen. Zur Idee geh\u00f6rt au\u00dferdem die Verwendung von Gamification-Elementen, um eine weitere Motivation zu bieten. Um die Anforderungen der Projektbeteiligten an das Projekt zu ermitteln, wurde ein Workshop mit allen Beteiligten durchgef\u00fchrt. In diesem Workshop wurden zun\u00e4chst mehrere Arbeitsgruppen gebildet. Jede der Gruppen hatte die Aufgabe, Anforderungen an die Lernplattform zu erarbeiten. Bei diesem Prozess sind insgesamt f\u00fcnf heterogene Dokumente erstellt worden. Diese unterscheiden sich im Dateityp, in der Struktur, im Inhalt und in der Art, wie sie erstellt wurden.<\/p>\n

        In einer zweiten Phase des Workshops sollten diese Dokumente in ein einheitliches Anforderungsdokument \u00fcberf\u00fchrt werden. Dabei sollte auch bereits eine Unterteilung in funktionale und nicht-funktionale Anforderungen stattfinden. Auch sollten weitere nicht-funktionale Anforderungen, die sich aus funktionalen ergeben, abgeleitet werden. F\u00fcr diese Aufgaben wurde im Workshop ein LLM-Chatbot mit den naiven Ans\u00e4tzen aus Abschnitt IV.A eingesetzt. Die Ergebnisse waren dabei zum einen sehr unterschiedlich und wiesen auch keine hohe Qualit\u00e4t auf. Dies f\u00fchrte zun\u00e4chst dazu, dass die Anforderungen aus den f\u00fcnf Dokumenten mit manuellem Aufwand gesammelt werden mussten. F\u00fcr die Fallstudie wurden die f\u00fcnf einzelnen Anforderungsdokumente als Datenbasis verwendet. Ziel der Studie war es zu untersuchen, inwieweit K\u00fcnstliche Intelligenz den Requirements-Engineering-Prozess unterst\u00fctzen kann und insbesondere, ob sich eine unstrukturierte Menge von Anforderungen aus verschiedenen Quellen konsolidieren und systematisch zusammenf\u00fchren l\u00e4sst.<\/p>\n

        B. Herausforderungen und L\u00f6sung<\/h3>\n

        Herausforderungen.<\/strong> Aus dem beschriebenen Szenario ergeben sich einige Herausforderungen f\u00fcr eine von KI unterst\u00fctzte L\u00f6sung. Eine der gr\u00f6\u00dften Herausforderungen ist dabei die Konsolidierung mehrerer Dokumente in ein einziges Anforderungsdokument. Die L\u00f6sung muss hier zun\u00e4chst mit den verschiedenen Dateitypen, Strukturen und Layouts umgehen k\u00f6nnen. Auch muss es in einem n\u00e4chsten Schritt m\u00f6glich sein, die Anforderungen zu extrahieren und mit den bestehenden Anforderungen zusammenzuf\u00fchren. Ein konkretes Problem ist hierbei, dass Anforderungen auf verschiedene Weisen formuliert werden k\u00f6nnen, aber die gleiche Bedeutung haben oder einander erg\u00e4nzen. Zus\u00e4tzlich ist au\u00dferdem eine Gruppierung der Anforderungen in funktionale und nicht-funktionale Anforderungen notwendig. Dabei d\u00fcrfen keine Anforderungen verloren gehen. Es darf zum Beispiel nicht vorkommen, dass eine nicht-funktionale Anforderung \u00fcbersehen wird, wenn diese innerhalb einer funktionalen Anforderung genannt ist oder aus dieser hervorgeht. Zus\u00e4tzlich bringen KI-Systeme, die auf LLMs basieren, selbst Herausforderungen mit sich. Zu diesen geh\u00f6ren unter anderem Halluzinationen und ein begrenztes Kontextfenster. Diese k\u00f6nnen zu falschen Anforderungen oder Schwierigkeiten bei der Verarbeitung von besonders vielen Anforderungen f\u00fchren.<\/p>\n

        L\u00f6sung.<\/strong> Basierend auf den genannten Herausforderungen und dem Ziel der Erstellung eines einheitlichen Anforderungsdokuments auf Basis von mehreren Quellen, wurde eine L\u00f6sung konzipiert und mit dem Workflowautomatisierungstool n8n umgesetzt. Die implementierte Workflow-Architektur folgt einem semi-automatisierten Pipeline-Ansatz, bei dem mehrere spezialisierte Agenten sequenziell zusammenarbeiten. Der Prozess wird initial durch einen oder mehrere Trigger ausgel\u00f6st, beispielsweise durch das Hochladen eines Dokuments oder das Eintreffen neuer Daten. Anschlie\u00dfend startet ein Vorverarbeitungsschritt, der die Eingabe vorbereitet und an einen KI-Agenten \u00fcbergibt. Die Vorbereitung der Daten besteht in dem hier implementierten Workflow darin, die verschiedenen Dateitypen zu erkennen und den in ihnen enthaltenen Text zu extrahieren. In diesem Fall werden von dem Workflow reine Textdateien, PDFs und auch Audioaufnahmen unterst\u00fctzt.<\/p>\n<\/div>\n\n\n\n

        \"\"
        Abbildung 2. Schematische Darstellung des konzipierten (semi-)automatischen Workflows mit Agenten<\/figcaption><\/figure>\n\n\n\n

        Jeder Agent besteht konzeptionell aus drei Kernkomponenten: einem Sprachmodell, einem strukturierten Prompt sowie einem Output-Parser. Das Sprachmodell \u00fcbernimmt die eigentliche Analyse- oder Generierungsaufgabe, w\u00e4hrend der Prompt die Instruktionen und Kontextinformationen definiert. Der Output-Parser stellt sicher, dass die erzeugten Ergebnisse in ein konsistentes und maschinenverarbeitbares Format \u00fcberf\u00fchrt werden. Auf diese Weise k\u00f6nnen die Resultate eines Agenten direkt an nachgelagerte Agenten weitergereicht werden, wodurch mehrstufige Verarbeitungsketten entstehen. Optional k\u00f6nnen Agenten zus\u00e4tzlich mit externem Wissen oder Werkzeugen ausgestattet werden, um spezialisierte Aufgaben effizienter zu l\u00f6sen.<\/p>\n

        In dem in dieser Fallstudie implementierten Workflow gibt es insgesamt drei solcher Agenten. Zwei dieser Agenten bilden dabei den Kern des Workflows. Der erste Agent, der direkt auf die Vorverarbeitung folgt, hat die Aufgabe, die Anforderungen aus dem ihm gegebenen Text in einem strukturierten Format (JSON) zu extrahieren. Der zweite Agent arbeitet direkt mit diesen strukturierten Daten weiter. Er konsolidiert dabei die extrahierten Anforderungen mit einem einheitlichen Anforderungsdokument. Dazu vergleicht der Agent die extrahierten Anforderungen mit dem einheitlichen Anforderungsdokument, f\u00fcgt neue Anforderungen hinzu oder ver\u00e4ndert bestehende bei Bedarf. Die neue konsolidierte Version gibt dieser Agent ebenfalls in einem strukturierten Format (JSON) aus. Ein dritter und letzter Agent hat lediglich die Aufgabe, die Daten des zweiten Agenten in ein menschenlesbares Format zu bringen.<\/p>\n

        Der Workflow umfasst zus\u00e4tzlich eine Human-in-the-Loop-Komponente, in der Zwischenergebnisse \u00fcberpr\u00fcft, validiert und gegebenenfalls korrigiert werden. Diese Integration menschlicher Kontrolle dient der Qualit\u00e4tssicherung und reduziert das Risiko fehlerhafter oder halluzinierter Anforderungen. Gleichzeitig bleibt der Gesamtprozess weitgehend automatisiert, sodass Effizienzgewinne gegen\u00fcber rein manuellen Vorgehensweisen erzielt werden k\u00f6nnen. \u00dcber eine solche Human-in-the-Loop-Komponente wird in dem implementierten Workflow die Arbeit des zweiten Agenten kontrolliert und so sichergestellt, dass die neuen Anforderungen und \u00c4nderungen im Anforderungsdokument eine hohe Qualit\u00e4t haben.<\/p>\n

        Mit dem gew\u00e4hlten Konzept und der Umsetzung konnte eine deutliche Verbesserung der Ergebnisse im Vergleich zu den im Workshop gew\u00e4hlten Methoden beobachtet werden. Der umgesetzte Workflow konnte die einzelnen Dateien analysieren und ein einheitliches Anforderungsdokument aufbauen. Zudem ist der Workflow in der Lage, Anforderungen aus neuen Dokumenten, die hochgeladen werden, in das Anforderungsdokument zu \u00fcbernehmen.<\/p>\n

        VII. Diskussion und Grenzen<\/h2>\n

        Der Einsatz von KI-Agenten im Requirements Engineering birgt ein gro\u00dfes Potenzial. Es gibt allerdings auch Limitationen beim Einsatz von KI. In diesem Kapitel werden zun\u00e4chst die Limitationen von KI-Agenten betrachtet. Daraufhin werden zuk\u00fcnftige Entwicklungen diskutiert, die f\u00fcr eine breitere industrielle Adaption adressiert werden m\u00fcssen.<\/p>\n

        A. Limitationen des KI-Einsatzes<\/h3>\n

        Bei dem Einsatz von KI im Requirements-Engineering-Prozess gibt es auch einige Limitationen. Vorweg muss festgestellt werden, dass KI einen Requirements Engineer zum jetzigen Zeitpunkt nicht vollst\u00e4ndig ersetzen kann. KI-Agenten k\u00f6nnen hier eher eingesetzt werden, um den Engineer bei seiner Arbeit zu unterst\u00fctzen. Dabei werden von KI-Agenten konkrete einzelne Aufgaben \u00fcbernommen, um dem Engineer zuzuarbeiten. Zudem gibt es auch Aufgaben, die ein KI-Agent nicht ohne Weiteres \u00fcbernehmen kann. Die Kommunikation und pers\u00f6nliche Gespr\u00e4che mit den Stakeholdern m\u00fcssen weiterhin vom Requirements Engineer \u00fcbernommen werden, da hierf\u00fcr Soft Skills ben\u00f6tigt werden.<\/p>\n

        Eine weitere Limitation liegt in der Qualit\u00e4t der Ergebnisse vom KI-Agenten. Um qualitativ hochwertige Ergebnisse mit KI-Agenten zu erzielen, werden genaue Erkl\u00e4rungen in Bezug auf die Aufgabe und das Ergebnis ben\u00f6tigt. Auch ist es hier wichtig, dass eine Kontrolle der Qualit\u00e4t eines Experten durch einen Human-in-the-Loop-Mechanismus stattfindet. Nur so k\u00f6nnen Fehler erkannt und korrigiert werden. Au\u00dferdem gibt es auch bei der Nachvollziehbarkeit von Entscheidungen und Ergebnissen der KI starke Limitationen. Es ist zwar m\u00f6glich, von einem LLM eine schriftliche Begr\u00fcndung f\u00fcr seine Entscheidung zu verlangen, was zusammen mit einem Prompt eventuell R\u00fcckschl\u00fcsse erlaubt. Die Modelle selbst sind aber eine Black-Box. Eine Limitation, die ebenfalls beachtet werden muss, ist das Kontextfenster von LLMs. Besonders bei gro\u00dfen Projekten kann es hier leicht zum Verlust von Kontext und Informationen kommen. [19] [20] [21] [22] [23]<\/p>\n

        B. Zuk\u00fcnftige Entwicklungen<\/h3>\n

        Der zuk\u00fcnftige Fortschritt und die praktische Reife von AI-Aided RE lassen sich anhand vier zentralen Dimensionen bewerten. Diese dienen als Indikatoren, um zu messen, wie weit der \u00dcbergang von explorativer Forschung zur produktiven Praxis fortgeschritten ist:<\/p>\n

        Evaluation und Benchmarking.<\/strong> Ein wesentliches Defizit des aktuellen Forschungsstands ist das Fehlen standardisierter Benchmarks f\u00fcr die objektive Bewertung von KI-Werkzeugen im RE. Cheng et al. identifizieren die Entwicklung einheitlicher Evaluationsmetriken als eine der dringendsten Forschungsl\u00fccken, da ohne solche Benchmarks ein systematischer Vergleich verschiedener Ans\u00e4tze nicht m\u00f6glich ist [6]. Zuk\u00fcnftige Arbeiten sollten dom\u00e4nenspezifische Datens\u00e4tze und Bewertungskriterien etablieren, die sowohl die Qualit\u00e4t der generierten Anforderungen als auch die Effizienz des Gesamtprozesses messen.<\/p>\n

        Governance, Ethik und Bias-Kontrolle.<\/strong> Mit der zunehmenden Integration von KI in kritische Entscheidungsprozesse gewinnen Fragen der Governance an Bedeutung. LLMs k\u00f6nnen systemische Verzerrungen (Bias<\/em>) in ihre Ergebnisse einbringen, die sich in der Priorisierung oder Formulierung von Anforderungen manifestieren. Transparenz \u00fcber die verwendeten Trainingsdaten und Modellentscheidungen sowie die Etablierung klarer Verantwortlichkeiten zwischen KI-generiertem Output und menschlicher Entscheidung sind essenziell f\u00fcr einen verantwortungsvollen Einsatz [6] [8].<\/p>\n

        Skalierbarkeit durch Retrieval Augmented Generation.<\/strong> Eine vielversprechende technologische Entwicklung ist der Einsatz von Retrieval Augmented Generation<\/em> (RAG), bei dem LLMs zur Laufzeit auf externe Wissensbasen zugreifen, anstatt sich ausschlie\u00dflich auf ihre Trainingsdaten zu st\u00fctzen [24]. Im RE-Kontext erm\u00f6glicht RAG die Einbindung unternehmensinterner Dokumentationen, bestehender Anforderungskataloge und dom\u00e4nenspezifischer Standards, was die Relevanz und Genauigkeit der KI-Ergebnisse signifikant verbessern und das Risiko von Halluzinationen reduzieren kann.<\/p>\n

        Industrielle Reife und Produktionseinsatz.<\/strong> Der \u00dcbergang von explorativen Proof-of-Concept-Ans\u00e4tzen hin zu standardisierten, rechtssicheren Produktionsl\u00f6sungen erfordert erhebliche Fortschritte in mehreren Bereichen: Zuverl\u00e4ssigkeit und Reproduzierbarkeit der Ergebnisse, Integration in bestehende Werkzeugketten (ALM-Tools, Versionsverwaltung) sowie die Erf\u00fcllung regulatorischer Anforderungen. Die BMAD-Methode (vgl. Abschnitt V.B) stellt einen ersten Schritt in diese Richtung dar, indem sie einen strukturierten, auditierbaren Rahmen f\u00fcr den KI-Einsatz bereitstellt [18].<\/p>\n

        Eine fl\u00e4chendeckende industrielle Adaption von AI-Aided RE setzt somit voraus, dass in diesen vier Dimensionen belastbare und standardisierte L\u00f6sungen entwickelt werden.<\/p>\n

        VIII. Fazit<\/h2>\n

        Der Einsatz von KI im Requirements Engineering entwickelt sich von einfachem, explorativen Prompt Engineering hin zu einem systematischen AI-driven Software Development<\/em>. W\u00e4hrend isolierte LLM-Interaktionen an Bedeutung verlieren, gewinnen strukturierte Methoden wie die in Kapitel IV beschriebenen Prompting-Frameworks und insbesondere agentische Architekturen wie die BMAD-Methode an Relevanz. Die vier identifizierten KI-Rollen \u2013 Assistent (Elicitation), Pr\u00fcfer (Analysis), Co-Autor (Specification) und Qualit\u00e4tssicherer (Validation) \u2013 bieten einen analytischen Rahmen f\u00fcr die gezielte Integration von LLMs in den RE-Prozess.<\/p>\n

        Gleichzeitig zeigt die Analyse, dass der Mensch als Orchestrator und Dom\u00e4nenexperte unverzichtbar bleibt. Die \u00fcberw\u00e4ltigende Dominanz von Human-AI Collaboration gegen\u00fcber Vollautomatisierung best\u00e4tigt, dass der effektivste Ansatz nicht in der Abl\u00f6sung des Menschen liegt, sondern in der Augmentation seiner F\u00e4higkeiten durch KI-Werkzeuge. Die Zukunft des RE liegt somit in der intelligenten Orchestrierung von menschlicher Expertise und maschineller Verarbeitungskapazit\u00e4t \u2013 ein Paradigma, das durch agentische Frameworks wie BMAD zunehmend operationalisiert wird.<\/p>\n

        Referenzen<\/h2>\n

        [1] A. Herrmann, Grundlagen der Anforderungsanalyse: Standardkonformes Requirements Engineering<\/em>. Springer Vieweg Wiesbaden, 2022. doi: 10.1007\/978-3-658-35460-2<\/p>\n

        [2] t2informatik GmbH, \u201eRequirements Engineering." [Online]. Verf\u00fcgbar: https:\/\/t2informatik.de\/wissen-kompakt\/requirements-engineering\/<\/p>\n

        [3] Technikum Wien GmbH, \u201eWas ist Requirement Engineering und Requirement Management?" [Online]. Verf\u00fcgbar: https:\/\/academy.technikum-wien.at\/ratgeber\/was-ist-requirements-engineering\/<\/p>\n

        [4] B. Bauer, \u201eWas macht ein Requirements Engineer?" get in GmbH. [Online]. Verf\u00fcgbar: https:\/\/www.get-in-it.de\/magazin\/arbeitswelt\/it-berufe\/was-macht-ein-requirements-engineer<\/p>\n

        [5] P. Schifino, \u201eMethoden der Anforderungserhebung: Grundlagen, Techniken & Einsatzgebiete." easyfeedback GmbH. [Online]. Verf\u00fcgbar: https:\/\/easy-feedback.de\/blog\/anforderungserhebung\/anforderungserhebung-methoden\/<\/p>\n

        [6] H. Cheng, J. H. Husen, Y. Lu, T. Racharak, N. Yoshioka, N. Ubayashi und H. Washizaki, \u201eGenerative AI for Requirements Engineering: A Systematic Literature Review," Software: Practice and Experience<\/em>, Bd. 56, Nr. 2, S. 141\u2013170, 2025. doi: 10.1002\/spe.70029<\/p>\n

        [7] L. M. Rani, R. Berntsson Svensson und R. Feldt, \u201eAI for Requirements Engineering: Industry adoption and Practitioner perspectives," arXiv:2511.01324, 2025. [Online]. Verf\u00fcgbar: https:\/\/arxiv.org\/abs\/2511.01324<\/p>\n

        [8] M. A. Abbasi, P. Ihantola, T. Mikkonen und N. M\u00e4kitalo, \u201eTowards Human-AI Synergy in Requirements Engineering: A Framework and Preliminary Study," in 2025 Sixth International Conference on Intelligent Data Science Technologies and Applications (IDSTA)<\/em>, IEEE, 2025, S. 81\u201388. doi: 10.1109\/idsta66210.2025.11202850<\/p>\n

        [9] J. Polomski, \u201e8 Prompting Techniken im \u00dcberblick," Blogpost, Mai 2024. [Online]. Verf\u00fcgbar: https:\/\/jens.marketing\/acht-prompting-techniken-im-uberblick\/<\/p>\n

        [10] OpenAI, \u201ePrompt engineering," OpenAI API Documentation, 2025. [Online]. Verf\u00fcgbar: https:\/\/platform.openai.com\/docs\/guides\/prompt-engineering<\/p>\n

        [11] P. Sahoo, A. K. Singh, S. Saha, V. Jain, S. Mondal und A. Chadha, \u201eA Systematic Survey of Prompt Engineering in Large Language Models: Techniques and Applications," arXiv:2402.07927, 2025. [Online]. Verf\u00fcgbar: https:\/\/arxiv.org\/abs\/2402.07927<\/p>\n

        [12] M. Kentz, \u201eFrom Thinking Partner to Sparring Partner: A Better Way to Use AI," Juli 2025. [Online]. Verf\u00fcgbar: https:\/\/mikekentz.substack.com\/p\/from-thinking-partner-to-sparring<\/p>\n

        [13] AI Prompting Clinic, \u201ePrompt Engineering Frameworks," 2025. [Online]. Verf\u00fcgbar: https:\/\/aipromptingclinic.com\/craft<\/p>\n

        [14] S. Srinivasan, \u201eThe CLEAR Framework: Mastering Prompt Clarity for Better AI Results," LinkedIn Article, Juli 2025. [Online]. Verf\u00fcgbar: https:\/\/www.linkedin.com\/pulse\/clear-framework-mastering-prompt-clarity-better-ai-sriram-srinivasan-jdmwc<\/p>\n

        [15] DAIR.AI, \u201eElemente eines Prompts," 2025. [Online]. Verf\u00fcgbar: https:\/\/www.promptingguide.ai\/de\/introduction\/elements<\/p>\n

        [16] Texas A&M University-Corpus Christi, \u201eThe CLEAR Framework \u2013 Prompt Engineering," Research Guides, September 2025. [Online]. Verf\u00fcgbar: https:\/\/guides.library.tamucc.edu\/prompt-engineering\/clear<\/p>\n

        [17] C. Vogt, \u201eKI-Agenten im E-Commerce," AMALYTIX Blog, Oktober 2025. [Online]. Verf\u00fcgbar: https:\/\/www.amalytix.com\/wissen\/ai\/ki-agenten\/<\/p>\n

        [18] BMad Code, \u201eBMAD-METHOD: Breakthrough method for agile AI-driven development," GitHub Repository, 2025. [Online]. Verf\u00fcgbar: https:\/\/github.com\/bmad-code-org\/BMAD-METHOD<\/p>\n

        [19] I. Belcic und C. Stryker, \u201eKI-Agenten im Jahr 2025: Erwartungen vs. Realit\u00e4t," IBM. [Online]. Verf\u00fcgbar: https:\/\/www.ibm.com\/de-de\/think\/insights\/ai-agents-2025-expectations-vs-reality<\/p>\n

        [20] J. Siebert, \u201eAgentic AI \u2013 Multi-Agenten-Systeme im Zeitalter generativer KI," Fraunhofer IESE, Juni 2025. [Online]. Verf\u00fcgbar: https:\/\/www.iese.fraunhofer.de\/blog\/agentic-ai-multi-agenten-systeme\/<\/p>\n

        [21] Deutsche Telekom MMS GmbH, \u201eKI-Agenten realistisch bewertet: \u00dcber Trends, Use Cases und Grenzen," Oktober 2025. [Online]. Verf\u00fcgbar: https:\/\/www.telekom-mms.com\/blog\/artikel\/detail\/ki-agenten-realistisch-bewertet-ueber-trends-use-cases-und-grenzen<\/p>\n

        [22] Deutsche Telekom MMS GmbH, \u201eWas sind KI-Agenten? \u2013 Intelligente Assistenten im Zeitalter von Agentic AI." [Online]. Verf\u00fcgbar: https:\/\/www.telekom-mms.com\/spotlight\/was-sind-ki-agenten<\/p>\n

        [23] WTSH GmbH, \u201eKI-Agenten: \u00dcbertriebener Hype oder echte Revolution?" [Online]. Verf\u00fcgbar: https:\/\/kuenstliche-intelligenz.sh\/de\/ki-agenten-uebertriebener-hype-oder-echte-revolution<\/p>\n

        [24] P. Lewis, E. Perez, A. Piktus, F. Petroni, V. Karpukhin, N. Goyal, H. K\u00fcttler, M. Lewis, W. Yih, T. Rockt\u00e4schel, S. Riedel und D. Kiela, \u201eRetrieval-Augmented Generation for Knowledge-Intensive NLP Tasks," arXiv:2005.11401, 2021. [Online]. Verf\u00fcgbar: https:\/\/arxiv.org\/abs\/2005.11401<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":1247,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"ppma_author":[1083,1186,1187],"class_list":["post-28402","post","type-post","status-publish","format-standard","hentry","category-allgemein"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":28248,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/01\/ki-sicherheit-nutzung-von-ki-fur-die-sicherheitsautomatisierung\/","url_meta":{"origin":28402,"position":0},"title":"KI-Sicherheit \u2013 Nutzung von KI f\u00fcr die Sicherheitsautomatisierung","author":"Samet Alkan","date":"1. February 2026","format":false,"excerpt":"Dieser Blogpost wurde f\u00fcr das Modul Enterprise IT (113601a) verfasst. Einleitung: Das Ende der manuellen Abwehr Wer heute in einem Security Operations Center (SOC) arbeitet, steht oft vor einer schier unbezwingbaren Wand aus Daten. Es ist l\u00e4ngst kein Geheimnis mehr: Die schiere Masse, das Tempo und vor allem die Raffinesse\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/unnamed.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/unnamed.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/unnamed.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/unnamed.jpg?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":28173,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/01\/14\/autonome-ki-agenten-in-der-softwareentwicklung-architektur-patterns-theoretische-frameworks-und-design-entscheidungen\/","url_meta":{"origin":28402,"position":1},"title":"Autonome KI-Agenten in der Softwareentwicklung: Architektur-Patterns, theoretische Frameworks und Design-Entscheidungen","author":"Kay Kn\u00f6pfle","date":"14. January 2026","format":false,"excerpt":"Abstract This paper provides a systematic introduction to AI agents, covering core definitions and foundational architectural concepts. It examines tool integration, including operational principles, capabilities, and evaluation of AI coding agents, as well as the Model Context Protocol. The paper further analyzes memory systems as a key component for context\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"Schematische Darstellung des Groupchat Patterns","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/01\/groupchat.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/01\/groupchat.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/01\/groupchat.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/01\/groupchat.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":28501,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/20\/integration-von-ki-in-devops-ein-uberblick-uber-aiops-prinzipien-und-praktiken\/","url_meta":{"origin":28402,"position":2},"title":"Integration von KI in DevOps: Ein \u00dcberblick \u00fcber AIOps-Prinzipien und -Praktiken","author":"Leonard Lais\u00e9","date":"20. February 2026","format":false,"excerpt":"Abstract \u2014 Die zunehmende Komplexit\u00e4t cloud-nativer Architekturen und die exponentielle Zunahme von Telemetriedaten \u00fcbersteigen die Kapazit\u00e4t manueller Betriebsprozesse und erfordern eine intelligente Automatisierung des IT-Betriebs. Die vorliegende Arbeit bietet einen umfassenden \u00dcberblick \u00fcber AIOps (Artificial Intelligence for IT Operations) und analysiert systematisch den aktuellen Forschungsstand entlang des Incident-Lifecycles. Ausgehend von\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":28492,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/20\/auswirkung-der-integration-von-ki-auf-den-software-development-lifecycle-mit-fokus-auf-frontend-entwicklung\/","url_meta":{"origin":28402,"position":3},"title":"Auswirkung der Integration von KI auf den Software Development Lifecycle mit Fokus auf Frontend-Entwicklung","author":"Tom Bestvater","date":"20. February 2026","format":false,"excerpt":"Abstract - Die Integration K\u00fcnstlicher Intelligenz (KI) in den Software Development Lifecycle (SDLC) f\u00fchrt zu einer Transformation der Frontend-Entwicklung und verschiebt den Fokus von der manuellen Implementierung hin zur KI-gest\u00fctzten Orchestrierung. Das vorliegende Paper untersucht den Einfluss generativer KI-Modelle und multimodaler Sprachmodelle (MLLMs) auf die Frontend-Engineering-Prozesse, wobei ein besonderer Schwerpunkt\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/sdlc_phases.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/sdlc_phases.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/sdlc_phases.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/sdlc_phases.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":28372,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/18\/safeguards-in-der-ki-unterstutzten-softwareentwicklung\/","url_meta":{"origin":28402,"position":4},"title":"Safeguards in der KI-unterst\u00fctzten Softwareentwicklung","author":"Christoph Merck","date":"18. February 2026","format":false,"excerpt":"KI gest\u00fctzte Werkzeuge und autonome Agenten machen Softwareentwicklung schneller, schaffen aber neue Sicherheitsrisiken, weil sie eigenst\u00e4ndig Entscheidungen treffen und externe Tools nutzen k\u00f6nnen. Der Artikel zeigt, warum deshalb ein mehrschichtiges Safeguard Konzept n\u00f6tig ist, das klassische Ma\u00dfnahmen wie Code Reviews, Tests und statische sowie dynamische Analysen mit KI spezifischen Schutzmechanismen\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":28461,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/20\/das-alltagliche-automatisieren-das-menschliche-perfektionieren-die-transformation-des-scrum-masters-und-der-team-kommunikation-im-ki-gestutzten-agilen-umfeld\/","url_meta":{"origin":28402,"position":5},"title":"Das Allt\u00e4gliche automatisieren, das Menschliche perfektionieren: Die Transformation des Scrum-Masters und der Team-Kommunikation im KI-gest\u00fctzten agilen Umfeld","author":"Alice Ginnen","date":"20. February 2026","format":false,"excerpt":"Abstract Die zunehmende Nutzung von KI in der Softwareentwicklung ver\u00e4ndert grundlegend die bew\u00e4hrten agilen Methoden. In der vorliegenden Arbeit wird untersucht, inwiefern sich die Rolle des Scrum Masters und die Teamkommunikation durch den Einsatz von Large Language Models (LLMs) und autonomen Agenten ver\u00e4ndern. Die Analyse ergibt, dass ein zunehmender Anteil\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":1083,"user_id":1247,"is_guest":0,"slug":"cedric_gottschalk","display_name":"Cedric Gottschalk","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/472d26ded7606fb8380c1f434241072814d874082d94097668be7def3acbce3b?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""},{"term_id":1186,"user_id":1307,"is_guest":0,"slug":"tobias_heim-galindo","display_name":"Tobias Heim Galindo","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/5e78a67821b633c33f93d49def703f702047710ace011d131276d4bc7dab8c1e?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""},{"term_id":1187,"user_id":1308,"is_guest":0,"slug":"tom_gtz","display_name":"Tom G\u00f6tz","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/9b2de7a01247cfa9a2a2e9a14326dc30df46b04f9547c2fd30e7395288862dea?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/28402","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/1247"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=28402"}],"version-history":[{"count":11,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/28402\/revisions"}],"predecessor-version":[{"id":28482,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/28402\/revisions\/28482"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=28402"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=28402"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=28402"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=28402"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}