V01 Erste Runs

Versuche/Versuch_01/01_Prompt.md

@@ -6,8 +6,8 @@
 - **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).
+- **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.
 
 ---
 
@@ -25,19 +25,25 @@ Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
 
 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 (Scope und Validierung sind manuell vorgegeben):
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten):
 
-1. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen.
-2. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
-3. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
-4. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen.
-5. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+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.
+- **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),
@@ -55,14 +61,16 @@ 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)
+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>
-  - [SEKUNDÄR] <...>
-  - [KONTEXT]  <...>
+  - [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>>
 Status:        <belegt | HYPOTHESE>
 ```
 
@@ -73,7 +81,16 @@ Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
 - 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)
+### 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/
@@ -86,6 +103,8 @@ Ergebnisse/
   Analysebericht.md (Modul-/Komponentenübersicht, abgedeckte Bereiche, bekannte Lücken)
 ```
 
+Das Ausgabeverzeichnis wird beim Start des Laufs benannt. 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.
@@ -96,6 +115,11 @@ Ergebnisse/
 
 ### 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
+- Tracelinks auf nicht existierende IDs
+
 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]`)?