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

Metadaten

Versuch: V1 Baseline (Prompt-only)
Iteration: 01 (Initial-Prompt, zu Versuchsbeginn neu formuliert)
Werkzeugkonfiguration: Claude Code, keine Agentendateien, keine MCP-Server
Codebasis: c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
Modell: Claude (Claude Code)
Zeitstempel: 2026-06-04
Änderungsgrund: Initial-Prompt für V1 Baseline (kein Vorgänger).

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). Es stehen weder spezialisierte Agenten noch MCP-Server zur Verfügung; nutze nur, was als Datei lesbar ist.

Auftrag

Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:

StRS - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
SyRS - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
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.

Vorgehen (statische Analyse, keine Ausführung)

Bearbeite die Schritte 2-6 der RRE-Methodenkette (Scope und Validierung sind manuell vorgegeben):

Artefakterhebung: Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen.
Technische Analyse: Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
Semantische Interpretation: Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
Formalisierung: Überführe die Aussagen in klare, testbare Anforderungen.
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.
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.

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>
Aussage:       Das System soll <...>. (klare Soll-Aussage)
Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
Belege:
  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String>
  - [SEKUNDÄR] <...>
  - [KONTEXT]  <...>
Prüfidee:      <Akzeptanzkriterium oder Testidee>
Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
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.

Ergebnisstruktur (im aktuellen Arbeitsverzeichnis)

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)

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 nicht vorhandener Tools. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist die Aussage als [HYPOTHESE] zu kennzeichnen.
Migrationsperspektive berücksichtigen. Wenn eine Implementierung erkennbar ein historischer Workaround oder Sonderfall ist, vermerke das im Feld Status (belegt; Workaround), damit es in der späteren Validierung priorisiert geprüft werden kann.
Sprache: Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.

Abschluss

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?

5.7 KiB Raw Blame History