Masterarbeit/Versuche/Versuch_01/01_Prompt.md

Versuch 01 - Baseline (Prompt-only) - Iteration 01

Metadaten

• Versuch: V1 Baseline (Prompt-only)
• Iteration: 01 (Initial-Prompt, zu Versuchsbeginn neu formuliert)
• Codebasis: c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
• Zeitstempel: 2026-08-25
• Änderungsgrund: Initial-Prompt für V1 Baseline (kein Vorgänger). Vor Erstlauf überarbeitet: Abgleich mit Kap. 4 (RRE-Methodenkette, Evaluationsrahmen) und Kap. 2 (Prozesskontrollen); mit der Vorfassung fand kein Lauf statt. Am 2026-08-26 werkzeugneutral gefasst: Aussagen zu Werkzeugkonfiguration, Modell und Ausgabeverzeichnis entfernt (sie werden vom Versuchsaufbau zur Laufzeit beigestellt und im Messprotokoll dokumentiert); Feld Übernahmewürdigkeit aus dem Evaluationsrahmen (Kap. 4.3) ergänzt.

Dieser Prompt enthält ausschließlich die Analyseanweisung und ist damit unabhängig von einem bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.

---

Prompt

Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach ISO/IEC/IEEE 29148:2018. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.

Auftrag

Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:

1. StRS - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. SyRS - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. SwRS - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)

Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.

Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)

Der Untersuchungsgegenstand ist die gesamte Codebasis im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen. Priorisiere die Analysetiefe selbstständig, dokumentiere aber im Analysebericht.md, welche Bereiche wie tief analysiert wurden.

Vorgehen (statische Analyse, keine Ausführung)

Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten):

2. Artefakterhebung: Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
3. Technische Analyse: Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
4. Semantische Interpretation: Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
5. Formalisierung: Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
6. Traceability-Anreicherung: Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.

Pflicht-Eigenschaften jeder Anforderung

• Belegpflicht: Jede Anforderung muss mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Anforderungen ohne Beleg sind unzulässig. Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt.
• Trennung von Fakt und Interpretation: Die belegte technische Beobachtung (Feld Fakt) wird getrennt von der fachlichen Interpretation (Feld Aussage) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
• Risikobasierte Priorisierung: Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen PRIMÄR-Beleg, andernfalls sind sie zwingend als [HYPOTHESE] zu kennzeichnen.
• Belegklassifikation: Kennzeichne jeden Beleg als
  • PRIMÄR (durchgesetzte Regel im Code oder DB-Constraint),
  • SEKUNDÄR (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
  • KONTEXT (Kommentar, Commit-Message, Ticketreferenz).
• Hypothesenmarkierung: Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit [HYPOTHESE] und einer kurzen Begründung, welche Information zur Bestätigung fehlt.
• Verifizierbarkeit: Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
• Eindeutigkeit: Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
• Übernahmewürdigkeit: Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide übernehmen (fachlich weiterhin erforderlich), Workaround (historisch gewachsene Behelfslösung), Sonderfall (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und veraltet (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
• Redundanzfreiheit: Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.

Formatvorgabe pro Anforderung

ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
Titel:         <kurzer Titel>
Ebene:         <StRS | SyRS | SwRS>
Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
Akteur:        <Rolle / System / Komponente>
Vorbedingung:  <Zustand vor Auslösen>
Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
Belege:
  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
  - [SEKUNDÄR] <...> - Begründung: <...>
  - [KONTEXT]  <...> - Begründung: <...>
Prüfidee:      <Akzeptanzkriterium oder Testidee>
Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
Status:        <belegt | HYPOTHESE>

Traceability

Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:

• Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
• Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
• Erzeuge zusätzlich eine konsolidierte Traceability-Tabelle (Markdown oder CSV): StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg.

Nicht-funktionale Anforderungen

• Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der ISO/IEC 25010 zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit).
• Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.

Konsolidierungsbedarf

Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld Konsolidierung als Kandidat für eine Zusammenführung im Zielsystem.

Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)

Ergebnisse/
  StRS.md
  SyRS.md
  SwRS.md
  Traceability.md   (oder Traceability.csv)
  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
  Analysebericht.md (Modul-/Komponentenübersicht, abgedeckte Bereiche, bekannte Lücken)

Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.

Randbedingungen

• Keine Halluzinationen. Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
• Keine Generierung von Code. Es sollen ausschließlich Spezifikationsartefakte entstehen.
• Keine Annahme über nicht beigestellte Hilfsmittel. Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als [HYPOTHESE] zu kennzeichnen.
• Migrationsperspektive berücksichtigen. Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld Übernahmewürdigkeit, nicht in das Feld Status. Status beschreibt ausschließlich die Belegsituation (belegt oder HYPOTHESE), Übernahmewürdigkeit die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
• Sprache: Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.

Abschluss

Führe vor Abgabe einen Konsistenzcheck über das gesamte Anforderungs-Set durch und dokumentiere das Ergebnis im Analysebericht.md:

• Doppelte oder mehrfach vergebene IDs
• Anforderungen ohne Beleg
• Anforderungen ohne Angabe zur Übernahmewürdigkeit
• Tracelinks auf nicht existierende IDs
• Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind

Beende den Lauf mit einer kurzen Selbstbewertung im Analysebericht.md:

• Welche Module wurden vollständig analysiert, welche nur stichprobenhaft, welche gar nicht?
• An welchen Stellen war der Beleg dünn (hoher Anteil SEKUNDÄR/KONTEXT oder [HYPOTHESE])?
• Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?