03_fertig

Kapitel/03_fallstudie.typ

@@ -57,34 +57,29 @@ Ziel der Modernisierung ist eine webbasierte SaaS-Plattform, die sowohl Cloud- a
 - *Datenbanksystem-Unabhängigkeit:* Geschäftslogik und Abfragen werden möglichst vollständig im Code abgebildet und nicht im DBMS. Damit sinken Migrationsaufwände, und im Multi-Tenant-Betrieb lassen sich günstige oder kostenlose Datenbanksysteme einsetzen.
 - *Skalierbarkeit:* Das Backend ist über Microservices und Load-Balancing horizontal skalierbar, um auch bei größeren Kunden performant zu bleiben.
 - *KI-Fähigkeit:* Schnittstellen zu KI-Systemen (z. B. MCP-Server, RAG-Embeddings) sind von Beginn an in der Architektur vorgesehen.
-- *Web-Frontend:* Eine responsive Web-Oberfläche ermöglicht die geräteübergreifende Nutzung.
-- *Zentrale Stammdatenverwaltung:* Das Basissystem stellt eine eigenständige Oberfläche zur Benutzer- und Kundenverwaltung bereit und dient auch ohne ERP-Funktionalität als Anker für weitere Produkte der Firma.
+- *Web-Frontend:* Eine responsive Web-Oberfläche ermöglicht die geräteherstellerunabhängige Nutzung.
+- *Zentrale Datenverwaltung:* Das Basissystem stellt eine eigenständige Oberfläche zur Benutzer- und Kundenverwaltung bereit und dient auch ohne ERP-Funktionalität als Basis für weitere Produkte der Firma.
 
-Als Performance-Ziel wird ein Sweetspot von 5 bis 100 gleichzeitigen Nutzern pro Mandant festgelegt (Priorität 1). Kleinere Installationen mit 1 bis 5 Nutzern (Priorität 2) sowie größere Installationen oberhalb von 100 Nutzern (Priorität 3) werden ebenfalls unterstützt.
+Als Performance-Ziel wird ein Bereich von 5 bis 100 gleichzeitigen Nutzern pro Mandant festgelegt. Kleinere Installationen mit 1 bis 5 Nutzern sowie größere Installationen oberhalb von 100 Nutzern werden ebenfalls unterstützt, bleiben aber opportunistische Ziele.
 
 #heading(level: 3)[Strategische Optionen und Abgrenzung]
 
-Migrationsstrategien für Legacy-Software reichen von leichtgewichtigen Ansätzen wie Rehosting bis zur schrittweisen Neuimplementierung zentraler Funktionen. Gegenstand dieser Arbeit ist nicht die vollständige Migrationsplanung, sondern die Frage, wie eine belastbare Requirementsbasis für die Umsetzung erzeugt wird.
+Migrationsstrategien für Legacy-Software reichen von leichtgewichtigen Ansätzen wie Refactoring bis zur schrittweisen Neuimplementierung zentraler Funktionen. Gegenstand dieser Arbeit ist nicht die vollständige Migrationsplanung, sondern die Frage, wie eine belastbare Requirementsbasis für die Umsetzung erzeugt wird.
 
-Schwerpunkt ist die *Rückgewinnung und Strukturierung* von Requirements aus bestehenden Artefakten. Architektur- und Implementierungsentscheidungen der Zielplattform werden nur insoweit diskutiert, als sie Requirements beeinflussen, etwa bei Sicherheits- und Betriebsanforderungen. Die technische Migration selbst — Datenmigration, Refactoring im Detail oder Release-Planung — wird als Rahmenbedingung verstanden und in späteren Kapiteln methodisch adressiert.
+Schwerpunkt ist die *Rückgewinnung und Strukturierung* von Requirements aus bestehenden Artefakten. Architektur- und Implementierungsentscheidungen der Zielplattform werden nur insoweit diskutiert, als sie Requirements beeinflussen, etwa bei Sicherheits- und Betriebsanforderungen. Die technische Migration selbst, also Datenmigration, Refactoring im Detail, Reimplementierung oder Release-Planung, wird lediglich als Randbedingung mit betrachtet.
 
 #heading(level: 3)[Spezifische Herausforderungen im Fallunternehmen]
 
 Aus dem Ist-Zustand ergeben sich mehrere Herausforderungen, die das Vorgehen des Reverse Requirements Engineering unmittelbar prägen:
 
-- *Funktionsäquivalenz mit Randfällen:* Ein erheblicher Teil des Systemwertes steckt in implementierten Ausnahmen und Prozessvarianten. Diese sind im Code zwar nachvollziehbar, aber selten dokumentiert; Traceability und Validierung haben damit hohe Priorität.
-- *Implizite Geschäftsregeln:* Geschäftslogik ist häufig als Prüf- und Statuslogik realisiert. Ohne strukturierte Extraktion droht, dass Regeln in der Neuimplementierung vereinfacht oder falsch interpretiert werden.
-- *Datenzentrierte Domäne:* ERP-Funktionalität ist eng mit Datenobjekten und historisierten Zuständen verbunden. Anforderungen müssen daher auch als Daten- und Integritätsanforderungen formuliert werden, nicht nur UI-nah.
-- *Nicht-funktionale Anforderungen:* Mit der webbasierten Zielplattform steigen die Anforderungen an Sicherheit, Verfügbarkeit und Observability. Insbesondere Identitätsmanagement und Datenflusskontrolle sind in Legacy-to-Cloud-Migrationen wiederkehrende Problemfelder.
-- *Organisatorische Randbedingungen:* Ressourcen für manuelle Analyse sind begrenzt und an erfahrene Mitarbeiter gebunden. Die Analysearbeit muss skalierbar und ihre Ergebnisse müssen reproduzierbar sein.
+- *Randfäll und Varianten:* Ein erheblicher Teil des Systemumfangs steckt in implementierten Sonderfällen und Varianten. Diese sind im Code zwar nachvollziehbar, aber selten dokumentiert und zur Laufzeit auch jeweils nur einzeln zu analysieren da sie sich oft gegenseitig ausschließen.
+- *Daten und Logische Redundanz:* Historisch wurden zusätzliche Funktionen oft inmplementiert indem Code oder Masken hinzugefügt wurden ohne alten code zu verändern. Daher kommt es vor, dass die die gleiche Anforderung auf Unterschiedlichen Masken oder Berechnungspfaden mehrfach unterschiedliche implementiert wurde.
+- *Implizite Geschäftsregeln:* Geschäftslogik ist häufig als Prüf- und Statuslogik oder über Randbediungungen in Eingabefeldern realisiert. Eine zuordung zu anderen zusammenghörigen Regeln fällt hier schwer.
+- *Kontextbasierte Logik:* Funktionalitäten und Logik sind oft nur lose über  historische Zuständen verbunden. Eine Regel kann daher nur bei Betrachtung eines vollständigen historischen Datensatzes im Kontext abgeleitet werden.
+- *Nicht-funktionale Anforderungen:* Mit dem Wechsel auf einen neuen Tech-Stack ist zu prüfen, welche der bisherigen nicht-funktionalen Anforderungen weiterhin Gültigkeit haben und welche neu definiert werden müssen. Annahmen zu Performance, Sicherheit oder Verfügbarkeit gelten unter veränderten Architektur- und Betriebsbedingungen nicht automatisch weiter.
+
 
 #heading(level: 3)[Konsequenzen für das Vorgehen in dieser Arbeit]
 
-Aus den Herausforderungen ergeben sich konkrete Anforderungen an das in Kapitel 4 entwickelte Vorgehen:
+Aus den Herausforderungen ergeben sich vier konkrete Anforderungen an das Vorgehen. Zunächst gilt eine *Belegpflicht*. Jede extrahierte Anforderung muss auf ein Artefakt wie eine Datei, ein Modul, ein Datenobjekt oder einen UI-Text zurückgeführt werden können. Aussagen, die nicht eindeutig aus Artefakten ableitbar sind, werden *explizit als Hypothesen markiert* und priorisiert validiert. Da Artefakte verteilt sind, ist eine *Segmentierung und Kontextsteuerung* notwendig, um Überinterpretation zu reduzieren. Schließlich ist eine fachliche Validierung durch einen *Human-in-the-loop* zwingend, da „plausible" Textausgaben kein hinreichender Beweis für fachliche Korrektheit sind.
 
-1. *Belegpflicht und Nachvollziehbarkeit:* Jede extrahierte Anforderung muss auf Artefakte zurückgeführt werden können (Datei, Modul, Datenobjekt, UI-Text).
-2. *Explizite Unsicherheitskennzeichnung:* Aussagen, die nicht eindeutig aus Artefakten ableitbar sind, werden als Hypothesen markiert und priorisiert validiert.
-3. *Segmentierung und Kontextsteuerung:* Da Artefakte verteilt sind, ist eine systematische Auswahl relevanter Kontexte notwendig, um Überinterpretation zu reduzieren.
-4. *Human-in-the-loop:* Fachliche Validierung ist zwingend, da „plausible" Textausgaben kein hinreichender Beweis für fachliche Korrektheit sind.
-
-Im nächsten Kapitel werden das methodische Vorgehen und die Claude-Code-basierte Durchführung beschrieben. Kapitel 5 dokumentiert die Ergebnisse der Versuche, Kapitel 6 evaluiert die Eignung im Fallkontext der c-entron GmbH.