# 1. Einleitung

## 1.1 Ausgangssituation und Motivation

Die c-entron GmbH betreibt seit über zwei Jahrzehnten eine Windows-basierte ERP-Suite für IT-Systemhäuser. Die Lösung ist funktional breit aufgestellt (u. a. Auftragsabwicklung, Lager, Fakturierung, Projektabrechnung), wächst aber auf einer klassischen Client/Server-Architektur weiter. Mit dem Wunsch nach webbasierten Oberflächen, Self-Service-Funktionen und flexibleren Betriebsmodellen stößt dieses Setup an Grenzen: Skalierung, Deployment und Nutzerführung lassen sich nur mit hohem Aufwand weiterentwickeln.

Gleichzeitig liegt ein großer Teil des Systemwissens implizit im Quellcode oder bei langjährigen Mitarbeitenden. Architekturentscheidungen sind selten dokumentiert, und viele Spezialfälle sind nur über Code-Historien nachvollziehbar. Damit erschwert sich die Vorbereitung einer Migration auf eine webbasierte Plattform erheblich.

Aktuelle Large Language Models (LLMs) wie GPT-4, Claude oder Code Llama können Code analysieren und beschreiben. Sie eröffnen die Möglichkeit, aus einer Legacy-Codebasis zumindest einen Teil der Requirements zu rekonstruieren. Wie tragfähig diese Unterstützung in einem mittelständischen Umfeld tatsächlich ist, ist bislang kaum erprobt. Genau hier setzt die Arbeit an.

## 1.2 Problemstellung

Für die bestehende ERP-Lösung fehlen strukturierte Requirements. Die Codebasis ist groß, historisch gewachsen und nur teilweise dokumentiert. Die Analyse bindet erfahrene Entwickler, ist fehleranfällig und lässt sich kaum skalieren. Daraus ergeben sich wesentliche Risiken für die Migration:

- Funktionen oder Edge Cases gehen bei der Neuimplementierung verloren, weil sie nur im Code sichtbar sind.
- Zeit fließt in das Entziffern alter Strukturen, statt in die neue Plattform; technische Schulden werden mitgeschleppt.
- Domänenwissen konzentriert sich auf wenige Personen, wodurch Personalwechsel zu Wissensverlust führen.
- Ohne eindeutige Traceability fehlt die Grundlage für Priorisierung, Tests und spätere Wartung.

Eine rein manuelle Rekonstruktion aller Anforderungen ist wirtschaftlich schwer darstellbar. Es soll daher geprüft werden, ob KI-gestützte Verfahren einen belastbaren Anteil dieser Arbeit übernehmen können.

## 1.3 Zielsetzung

Die Arbeit entwickelt und bewertet ein Vorgehen für KI-gestütztes Reverse Requirements Engineering in einem mittelständischen ERP-Kontext. Kernergebnisse sollen sein:

- ein praxistaugliches Prozessmodell mit klaren Phasen für Vorbereitung, Analyse, Validierung und Übergabe,
- eine evaluierte Auswahl geeigneter LLMs (u. a. Kontextfenster, Codeverständnis, Kosten, Datenschutz),
- ein Prototyp, der Code analysiert, Requirements formuliert und Traceability-Informationen erfasst,
- eine Ergänzung der KI-Ergebnisse durch Stakeholder-Interviews, wo Code allein nicht reicht,
- ein Evaluationsrahmen (quantitativ und qualitativ) sowie Governance-Empfehlungen für den Umgang mit sensiblen Daten,
- Handlungsempfehlungen für die c-entron GmbH und Hinweise zur Übertragbarkeit auf ähnliche Unternehmen.

## 1.4 Forschungsleitfragen

Die Arbeit beantwortet vier Leitfragen:

- **F1:** Welche Prozessschritte, Steuerungsmechanismen und Kontrollpunkte braucht es, um LLMs reproduzierbar für Reverse Requirements Engineering einzusetzen?
- **F2:** Welche funktionalen und nicht-funktionalen Anforderungen lassen sich direkt aus Code ableiten, und wo müssen Interviews und vorhandene Dokumentation ergänzen?
- **F3:** Wie bewerten Fachexperten Vollständigkeit, Verständlichkeit und Nutzen der KI-Ergebnisse im Vergleich zu manuellen Ansätzen?
- **F4:** Welche Chancen (Effizienz, Systematisierung) und Grenzen (Halluzinationen, Datenschutz, Kontextgröße) sind beim KI-gestützten Requirements Engineering in Legacy-Umgebungen zu erwarten?

## 1.5 Aufbau der Arbeit

Die acht Kapitel folgen einer durchgängigen Linie: Einleitung (Kap. 1), theoretische Grundlagen zu Requirements Engineering, Reverse Engineering und LLMs (Kap. 2), Fallstudie c-entron GmbH (Kap. 3), Konzept und methodisches Vorgehen (Kap. 4), prototypische Umsetzung des LLM-Agenten (Kap. 5), Evaluation (Kap. 6), Diskussion der Ergebnisse (Kap. 7) sowie Fazit und Ausblick (Kap. 8). Damit entsteht ein klarer Bogen von der Ausgangslage bis zur Validierung des Ansatzes.
