# RE4AI - Requirements Engineering für AI *Geschrieben am: 29.08.2025* Durch die schnelle Entwicklung im Gebiet von AI (Artificial Intelligence) und ML (Machine Learning) in den letzten paar Jahren wurde ein Paradigmenwechsel in der Software Entwicklung angeregt, durch welchen neue Möglichkeiten aber auch Schwierigkeiten erschaffen wurden. Ein grosser Teil von AI Projekten, geschätzt auf etwa 87%, erreichen nie die Produktion. Ein grosser Teil davon kann auf eine fundamentale Krise im Requirements Engineering (RE) zurückgeführt werden.[^1] Traditionelles RE wurde für deterministische, Regel-basierte Systeme entworfen, und ist so nicht für die probabilistische, Daten-getriebene und oft unverständliche Natur von moderner AI ausgelegt. In diesem Beitrag wollen wir uns also die aufsteigende Disziplin des *Requirements Engineering for Artificial Intelligence* genauer ansehen. Wir gehen in diesem Beitrag jedoch nicht auf explizite Praktiken ein, sondern wollen uns eher mit der Problemstellung auseinandersetzen. ## Das RE4AI Imperativ Durch die Verfügbarkeit von massiven Datenmengen und dem exponentiellen Wachstum von Rechenleistung wird Künstliche Intelligenz heute oft als die bevorzugte Lösung für Automationsprobleme angesehen. Durch diesen schnellen Wachstum fehlen jetzt jedoch die nötigen Methodiken, um das ganze zu Verwalten. Ein Grossteil von AI Systemen werden mit dem primären Fokus auf die Wahl und Kombination von Algorithmen begonnen, wobei oft ein abstrakteres, fundamentales Verständnis über das effektive Endprodukt fehlt. Wie erwähnt, schaffen es aus diesem Grund viele Projekte nie aus der Entwicklungsphase. Ein weiteres Risiko ist aber auch, dass sogenannte "rogue" Systeme, also schädliche und fehlerhafte Systeme, veröffentlicht werden. Requirements Engineering wird schon lange als eine sehr wichtige Phase im Software Lifecycle angesehen, da es einen primären Kommunikationskanal zwischen Entwicklern und Stakeholdern darstellt. In der konventionellen Form versucht es, jegliche Wünsche und Anforderungen durch ein Produkt oder eine Dienstleistung zu erfüllen. Die einzigartige Natur von AI verlangt jedoch nach einer erweiterten Definition. RE4AI ist die Disziplin der Anwendung und Anpassung von RE Methoden, Techniken und Tools, um die Entwicklung von AI Systemen, welche gesetzlich, ethisch und robust sind, zu unterstützen. Diese Definition reflektiert einen wichtigen Wandel. Das Ziel ist nicht mehr, ein funktionales System gemäss Spezifikationen, sondern viel mehr, eine "vertrauenswürdige AI" zu bauen. Durch diese Erweiterung des Umfangs muss auch die Definition von Requirements (Anforderungen) erweitert werden. Es müssen neu auch gesellschaftliche Erwartungen und mögliche Schäden, wie algorithmische Diskriminierung und fehlende Transparenz, beides Probleme welche nicht einfach mit Code gelöst werden können, enthalten. Dadurch verschiebt sich das Gebiet des RE4AI von einer rein technischen zu einer sozio-technischen Disziplin. ## Der Paradigmenwechsel Der Übergang von traditioneller Software Entwicklung zur Entwicklung von AI-basierten Systemen repräsentiert einen fundamentalen Wechsel in Paradigma. Verwurzelt ist dieser Wechsel in den Unterschieden von konventioneller, deterministischer Logik und der probabilistischen, gelernten Natur von AI. Diesen Unterschied zu verstehen ist der erste Schritt, um zu realisieren, warum traditionelle RE Praktiken nicht mehr ausreichen und weshalb RE4AI nötig ist. ### Die deterministische Welt von traditionellem RE Konventionelle Software baut auf einem Fundament von deterministischer, Regel-basierter Logik. Das Verhalten ist hierbei explizit programmiert und ein bestimmter Input sollte vorhersehbar und kontinuierlich das gleiche Resultat ergeben. Der Entwicklungsprozess ist entsprechend Spezifikationsgetrieben (Specification-driven). Der Prozess folgt hierbei einem etablierten, grösstenteils linearen Ablauf mit Phasen wie Erhebung, Analyse, Spezifikation und Dokumentation, Validierung und Verwaltung. Das Ziel dieses Ablaufs ist, einen präzisen und umfangreichen Blueprint des Systems und dessen Verhalten abzubilden. Formal wird dies in einer "Software Requirements Specification (SRS)" festgehalten. Dieses Dokument gilt als die einzige "Quelle der Wahrheit" gegen welche das finale System auch gebaut, getestet und validiert wird.[^2] ### Die probabilistische Welt von RE4AI In starkem Kontrast hierzu stehen AI-basierte Systeme, besonders jene die ML einsetzen, welche induktiv entwickelt werden. Das Verhalten ist hierbei nicht explizit programmiert sondern durch Muster und Verbindungen erlernt. Dieser induktive Prozess resultiert in Systemen welche von Grund auf probabilistisch und nicht deterministisch sind. Das Verhalten kann zwar geleitet und beschränkt, aber nie ganz vorhergesagt oder spezifiziert werden. Dazu kommt noch, dass der Code für die ML Komponenten oft einen eher kleinen Teil des Systems ausmachen. Stattdessen liegt ein grosser Teil der Entwicklungsarbeiten in Aktivitäten welche mit Daten zu tun haben, wie die Datensammlung, Säuberung, Analyse und System Konfiguration. Dieser fundamentale Unterschied schafft eine neue Realität für Requirement Engineers. Während traditionelles RE definiert "was ein System machen sollte", muss RE4AI viel mehr mit dem Fakt zurecht kommen, dass es oft gar nicht möglich ist, alle Verhalten eines ML Modells im voraus zu definieren. Der Fokus sollte hier auf das Definieren von gewünschten Performance-Charakteristiken in einem gewissen Kontext wechseln.[^3] ## Fazit Im Rahmen dieses Beitrags haben wir uns die Unterschiede zwischen traditionellem RE und RE4AI auf einer abstrakten Ebene angeschaut. Die wichtigsten Punkte möchte ich in der folgenden Tabelle noch ein Mal zusammenfassen: | Merkmal | Traditionelles RE | RE4AI | | -------------------------------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | Kernlogik | Deterministisch, Regel-basiert und explizit programmiert | Probabilistisch, Muster-basiert und gelernt von Daten | | Entwicklungs-Paradigma | Spezifikations-getrieben: Das Verhalten wird zuvor in einem SRS definiert | Daten-getrieben und experimentell: Das Verhalten ergibt sich aus Daten und Training | | Natur des Verhaltens | Vorhersehbar und Reproduzierbar | Adaptiv und möglicherweise nicht deterministisch | | Schlüssschwierigkeiten | Alle funktionalen Anforderungen sammeln und "Scope Creep" vermeiden | Datenqualität verwalten, nicht-funktionale Anforderungen definieren und Unerwartetes behandeln | | Validierungsmethode | Verifikation gegen eine strikte und detaillierte Spezifikation | Empirische Auswertung von Leistungs-Metriken gegen definierte Akzeptanzkriterien | | Dominante NFRs (Non Functional Requirements) | Leistung, Nutzbarkeit, Verlässlichkeit und Sicherheit | Erklärbarkeit, Fairness, Transparenz, Vertrauen und Ethik | Das Feld ist zurzeit noch ziemlich neu und entsprechend auch sehr Offen. Es ist jedoch wichtig, dass sich Praktiken etablieren können, um die Erfolgschancen von AI-Projekten zu verbessern. [^1]: vgl. Habiba, Umm-e: How mature is requirements engineering for AI-based systems? A systematic mapping study on practices, challenges, and future research directions, in: Requirements Engineering, 29.08.2025, [doi:10.1007/s00766-024-00432-3](http://dx.doi.org/10.1007/s00766-024-00432-3) [^2]: vgl. Liu, Kaihua: Artificial Intelligence in Software Requirements Engineering: State-of-the-Art, in: IEEE IRI, 29.08.2025, [doi:0.1109/IRI54793.2022.00034](https://web.ntpu.edu.tw/~myday/doc/IRI2022/IEEE_IRI2022_Proceedings/pdfs/IRI2022-2biJIxjybiQ3DOmA6IkB2x/660300a106/660300a106.pdf) [^3]: vgl. Ahmad, Khlood: What’s up with Requirements Engineering for Artificial Intelligence Systems?, in: IEEE IREC, 29.08.2025, https://raw.githubusercontent.com/nzjohng/publications/master/papers/re2021_1.pdf