iteration 8
This commit is contained in:
Christoph Schwörer
+12
@@ -0,0 +1,12 @@
|
||||
[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
|
||||
[glm-kimi-adapter] Start: 2026-08-28T12:20:22.287761+00:00
|
||||
[glm-kimi-adapter] Provider: TensorX API Gateway
|
||||
[glm-kimi-adapter] Modell: moonshotai/kimi-k3
|
||||
[glm-kimi-adapter] Effort: high
|
||||
[glm-kimi-adapter] Mode: builtin
|
||||
[glm-kimi-adapter] Subagent 1/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 2/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 3/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 4/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 5/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 6/10 gestartet (Typ: explore)
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+161
@@ -0,0 +1,161 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### 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). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
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). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **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. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **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. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **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.
|
||||
- **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 | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
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). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- 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.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
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 (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
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
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> 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.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\nZusaetzlich: spawn_subagent zum Starten von Subagenten mit eigenem Kontext fuer isolierte Teilaufgaben.\nNicht verfuegbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n- spawn_subagent: Startet einen Subagenten mit eigenem Kontext fuer eine isolierte Teilaufgabe (Read-Only, max. 10)\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\builtin\high\03_Lauf_2026-08-28_125852_v8.0.0-ffe2\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T15:19:12.3726657+02:00
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"modell": "moonshotai/kimi-k3",
|
||||
"iteration": "Iteration 8",
|
||||
"promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
|
||||
"promptVersion": "03",
|
||||
"modus": "builtin",
|
||||
"effort": "high",
|
||||
"skillVersion": "v8.0.0"
|
||||
}
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T12:58:52.6902057+02:00
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
|
||||
[glm-kimi-adapter] Start: 2026-08-28T15:24:00.672781+00:00
|
||||
[glm-kimi-adapter] Provider: TensorX API Gateway
|
||||
[glm-kimi-adapter] Modell: moonshotai/kimi-k3
|
||||
[glm-kimi-adapter] Effort: high
|
||||
[glm-kimi-adapter] Mode: builtin
|
||||
[glm-kimi-adapter] Subagent 1/10 gestartet (Typ: general-purpose)
|
||||
[glm-kimi-adapter] Subagent 2/10 gestartet (Typ: general-purpose)
|
||||
[glm-kimi-adapter] Subagent 3/10 gestartet (Typ: general-purpose)
|
||||
[glm-kimi-adapter] Subagent 4/10 gestartet (Typ: general-purpose)
|
||||
[glm-kimi-adapter] Subagent 5/10 gestartet (Typ: general-purpose)
|
||||
[glm-kimi-adapter] Subagent 6/10 gestartet (Typ: general-purpose)
|
||||
[glm-kimi-adapter] Subagent 7/10 gestartet (Typ: general-purpose)
|
||||
[glm-kimi-adapter] Subagent 8/10 gestartet (Typ: general-purpose)
|
||||
[glm-kimi-adapter] Subagent 9/10 gestartet (Typ: general-purpose)
|
||||
[glm-kimi-adapter] Subagent 10/10 gestartet (Typ: general-purpose)
|
||||
[glm-kimi-adapter] Subagent verweigert (Limit 10 erreicht)
|
||||
[glm-kimi-adapter] Subagent verweigert (Limit 10 erreicht)
|
||||
[glm-kimi-adapter] Subagent verweigert (Limit 10 erreicht)
|
||||
[glm-kimi-adapter] Subagent verweigert (Limit 10 erreicht)
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+161
@@ -0,0 +1,161 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### 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). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
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). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **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. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **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. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **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.
|
||||
- **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 | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
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). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- 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.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
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 (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
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
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> 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.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\nZusaetzlich: spawn_subagent zum Starten von Subagenten mit eigenem Kontext fuer isolierte Teilaufgaben.\nNicht verfuegbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n- spawn_subagent: Startet einen Subagenten mit eigenem Kontext fuer eine isolierte Teilaufgabe (Read-Only, max. 10)\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\builtin\high\03_Lauf_2026-08-28_160956_v8.0.0-7247\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T19:06:18.4170924+02:00
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"modell": "moonshotai/kimi-k3",
|
||||
"iteration": "Iteration 8",
|
||||
"promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
|
||||
"promptVersion": "03",
|
||||
"modus": "builtin",
|
||||
"effort": "high",
|
||||
"skillVersion": "v8.0.0"
|
||||
}
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T16:09:57.0822828+02:00
|
||||
+90
@@ -0,0 +1,90 @@
|
||||
# Analysebericht – c-entron ERP-Suite (Reverse Requirements Engineering)
|
||||
|
||||
**Stand:** Zwischenstand Schritt 0/0b – Modulinventar und Mindestabdeckung (Konsistenzcheck und Selbstbewertung folgen am Ende des Laufs in derselben Datei).
|
||||
|
||||
## 1. Ausgangslage
|
||||
|
||||
- Codebasis: c-entron ERP-Suite, C#/XAML (WPF), Blazor (Nexus), MSSQL, NHibernate.
|
||||
- Umfang: ~16.000 C#-Dateien (inkl. `obj`-Artefakte), davon ~2.068 in `Centron.BL`; Datenbankschema `SSMS_DB_SCHEMA.sql` mit **1.558 Tabellen** im Schema `dbo`.
|
||||
- Vorgehen: statische Analyse gemäß RRE-Methodenkette; Scope = gesamte Codebasis (Breite vor Tiefe).
|
||||
|
||||
## 2. Modulinventar (Schritt 0)
|
||||
|
||||
Bezugsgröße für die Abdeckung. Ebenen: **T** = technische Schicht/Komponente, **F** = fachliches Modul.
|
||||
|
||||
| # | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M01 (T) | WPF-Client (c-entron.NET) | `src/centron/Centron.WPF.UI` | Desktop-Frontend mit Ribbon, Modulen, Dialogen, Wizards |
|
||||
| M02 (T) | WPF-UI-Extension | `src/centron/Centron.WPF.UI.Extension` | Erweiterungspunkte des WPF-Clients |
|
||||
| M03 (T) | Business-Logik (BL) | `src/backend/Centron.BL` | Fachlogik aller Module (Entities <-> Regeln) |
|
||||
| M04 (T) | Datenzugriff (DAO/NHibernate) | `src/backend/Centron.DAO` | NHibernate-Sessions, Mappings, Transaktionen, NamedQueries |
|
||||
| M05 (T) | Entities/Domänenmodell | `src/backend/Centron.Entities` | Persistente Entitäten (PersistedEntity mit I3D-Schlüssel) |
|
||||
| M06 (T) | Common/Interfaces/Gateway | `src/backend/Centron.Common`, `Centron.Interfaces`, `Centron.Gateway` | Querschnitt (TextCoding, Result-Pattern), Schnittstellenverträge, EDI-Gateway-Anbindung |
|
||||
| M07 (T) | SOAP-Webservice & Hosts | `src/webservice/*` (Centron.WebServices.Core, Centron.Host, Centron.Host.WindowsService, Centron.Host.Console, Centron.Controllers, c-entron.misc.ConnectionManager) | Externer Webservice für Fremdanwendungen, Hosting als Windows-Dienst/Konsole |
|
||||
| M08 (T) | c-entron Nexus (Blazor Web) | `src/nexus/CentronNexus`, `CentronNexus.Host` | Webanwendung (ServiceBoard, WebCart, WebOffer, Management) |
|
||||
| M09 (T) | Nexus Outlook-AddIn | `src/nexus/CentronNexus.OutlookAddIn` | Einbettung von Nexus in Outlook |
|
||||
| M10 (T) | Shared Controls/Core | `src/shared/Centron.Controls`, `Centron.Core`, `Centron.Controls.Preview` | Gemeinsame UI-Controls und Basisfunktionen (z. B. GoogleAuthenticator) |
|
||||
| M11 (T) | Externe API-Anbindungen | `src/apis/*`, `Centron.Api.docuFORM` | Icecat, ITscope, C.O.P., EGIS, finAPI, GLS, Shipcloud, ebInterface, docuFORM |
|
||||
| M12 (T) | Deployment & Container | `docker/`, `deployment/`, `azure*/`, `scripts/` | Docker-Image (Alpine), WiX/WixSharp-Installer, Azure-Artefakte |
|
||||
| M13 (F) | Adressstamm / CRM | `src/backend/Centron.BL/CustomerArea`, `Accounts`; Entities `Accounts/*` | Kunden, Lieferanten, Adressen, Ansprechpartner, Aktivitäten, Kampagnen |
|
||||
| M14 (F) | Vertriebsbelegwesen | `Centron.BL/Sales/Receipts`; DbEntities `AngKopf/AufKopf/LiefKopf/RechKopf/GutKopf/AbholKopf` | Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholung, Belegversionen |
|
||||
| M15 (F) | Preise & Sonderkonditionen | Entities `Accounts/SpecialPrices`, `CustomerArea/CustomerDetails/CustomerSpecialPrice` | Kundenindividuelle Preise, Sonderaktionen |
|
||||
| M16 (F) | Vertragswesen & automatische Abrechnung | `Centron.BL/Sales/CustomerAssets/Contracts`, `AutomaticFactura`; DbEntities `VertragKopf/VertragPos` | Verträge, Kontingente, Click-Verträge, periodische Auto-Fakturierung |
|
||||
| M17 (F) | Helpdesk / Ticketing / Taskmanagement | `Centron.BL/Sales/Support`; WPF `Modules/Helpdesk` | Tickets, Kategorien, Prioritäten, Status, Checklisten, C-FLOW-Vorlagen |
|
||||
| M18 (F) | Zeiterfassung & Verrechnung | `Centron.BL/Sales/Support/HelpdeskTimer*`, `CustomerAssets/TimerBilling`, `Administration/HourlySurchargeRates` | Erfassung von Technikerzeiten, Signaturen, Verrechnung über Belege, Stundenzuschläge |
|
||||
| M19 (F) | Finanzwesen / Zahlungsverkehr | `Centron.BL/Finances`, `Sales/CashBooks`; Entities `Finances/*` | Zahlungsein-/ausgänge, Kassenbuch, Zahlungszuordnung |
|
||||
| M20 (F) | Online-Banking | `Centron.BL/Finances/OnlineBanking`; Entities `Finances/OnlineBanking/*` | Kontoumsatzabruf via FinTS/finAPI/Tabellen-Import, Umsatzzuordnung |
|
||||
| M21 (F) | Mahnwesen | DbEntities `Mahnlauf.cs`; Schema-Tabelle `Mahnlauf` | Mahnläufe zu überfälligen Rechnungen |
|
||||
| M22 (F) | SEPA | Entities `Administration/Documents/SepaContracts/*` | SEPA-Mandate und -Vorlagen |
|
||||
| M23 (F) | Einkauf | `Centron.BL/Purchasing`, `Buying`; Entities `Businesspartner/*`; DbEntities `AnfrKopf/BestKopf2/WareKopf` | Lieferantenanfrage, Bestellung, Wareneingang, Lieferantengutschrift, Lieferantenkalkulation/-buchung |
|
||||
| M24 (F) | Artikel-/Warenwirtschaft | DbEntities `ARTIK/WAREN/UNTERWAREN`, `Hersteller`, `ArtikelEinheit`, `Barcode`, `MwstSatz` | Artikelstamm, Warengruppen, Hersteller, Einheiten, Barcodes, MwSt.-Sätze |
|
||||
| M25 (F) | Lagerverwaltung | Entities `Logistics/Warehousing/Stock`, `StockRebookLog`, DbEntities `NebenlagerArtikel`, `SeriennummerToPosition` | Lagerbestände, Umbuchungen, Nebenläger, Seriennummern |
|
||||
| M26 (F) | Logistik / Versand | `src/apis/Centron.Api.Gls`, `Centron.Api.Shipcloud`; BL `Logistics` | Paketversand, Sendungsverfolgung |
|
||||
| M27 (F) | EDI / Datenaustausch / Buchhaltungsschnittstellen | Entities `EDI/*`, `DataExchange/*`; `Centron.BL/EDI`, `DataExchange` | EDI-Lieferungen/Rechnungen/Auftragsbestätigungen, Buchhaltungsexport/-import, Gateway-Logs |
|
||||
| M28 (F) | Kalender / Terminplanung | `Centron.BL/Calendar`; Rechte `RIGHT_KALENDER*` | Kalender, Termine, Mitarbeiterauslastung |
|
||||
| M29 (F) | Projektmanagement | Entities `ProjectArea/*`, `TicketProjects`; WPF `Modules/ProjectManagement` | Projekte, Projektstufen, Aufgaben, Jour-fixe-Termine, Ticket-Projekte |
|
||||
| M30 (F) | Produktion | Entities `Production/*`; WPF `Modules/Production` | Produktionsaufträge, Maschinen, Schritte, Betriebsdatenerfassung |
|
||||
| M31 (F) | RMA / Retouren | Entities `CustomerArea/RmaArea/*`; WPF `Modules/Rma` | Rücksendungen, Hin-/Rückversand, Artikelhistorie |
|
||||
| M32 (F) | PLM / Produktmatrix | `Centron.BL/Finances/ProductLifecycleBL.cs`; Entities `ProductMatrix/*`; WPF `Modules/PLM` | Produktlebenszyklen, Kunden-Produktmatrix mit Bewertungen |
|
||||
| M33 (F) | QM | WPF `Modules/QM` | Qualitätsmanagement |
|
||||
| M34 (F) | Geräte-/Asset-Verwaltung | Entities `Devices/AccountDevice*`, `Sales/CustomerAssets/Asset*`; DbEntities `GeraeteKopf/GeraetePos` | Kundengeräte, Assets, Stammblätter (doppelte Datenhaltung!) |
|
||||
| M35 (F) | Monitoring / DocuBoard | Schema `AssetManagement*`; Entities `DocuBoard/*` | SNMP-/Windows-Service-Monitoring, Check-Konfigurationen |
|
||||
| M36 (F) | Benutzer- & Rechteverwaltung | `Centron.BL/Administration/Logins`, `Rights`; `CentronRights.md`; Entities `Administration/App*` | AppUser, Authentifizierung (Basic/AD/OIDC), 2FA, granulare Rechte, Web-Accounts |
|
||||
| M37 (F) | DSGVO / Datensicherheit | `Centron.BL/Administration/DataSecurity`; Entities `Administration/Documents/Dsgvo/*` | Lösch-/Bereinigungsläufe, AV-Verträge, DSGVO-Marker |
|
||||
| M38 (F) | Mandanten & Filialen | Entities `Administration/Company/Mandator`, `BranchArea/Branch` | Mehrmandanten- und Filialfähigkeit |
|
||||
| M39 (F) | Nummernkreise | `Centron.BL/Administration/Company/NumberGroupBL.cs`; Entity `NumberGroup` | Nummernvergabe je Belegart/Filiale/Mandant |
|
||||
| M40 (F) | Dokumentenmanagement (DMS) | Entities `Administration/FileManagement/*` | Verzeichnisse, Dokumente, Thumbnails, DocSync, Shared Documents |
|
||||
| M41 (F) | E-Mail / Mailings / MailScanner / Chat | Entities `Mail/*`, `Mailings/*`, `MailScanner/*`, `Chats/*` | Mailvorlagen, Serienmails, eingehende Mail-Verarbeitung, interner Chat |
|
||||
| M42 (F) | Outlook-/TAPI-Integration | Entities `Outlook`, `Tapi`; `Centron.BL/Outlook`, `Tapi` | Kontaktsynchronisation, Telefonie-Wahlhilfe |
|
||||
| M43 (F) | Berichtswesen / ReportEngine / Statistik | Entities `ReportEngine/*`, `Reporting`; `Centron.BL/ReportEngine`, `Statistics`; WPF `Modules/Reports`, `Statistics` | Berichtsgruppen, Datenabfragen, Dashboards, Statistiken |
|
||||
| M44 (F) | MyDay / MyCentron / Notifications | Entities `MyDay/*`, `MyCentron/*`, `Notifications/*`, `NexusNotifications` | Tagesplanung, persönliches Dashboard, Benachrichtigungen |
|
||||
| M45 (F) | Web-Portal: WebCart / WebOffer / Web-Accounts | `src/nexus/CentronNexus/WebCart`, `WebOffer`; Entities `Administration/Logins/WebAccount*` | Kunden-Shop mit Sonderpreisen, Online-Angebote, Web-Logins |
|
||||
| M46 (F) | Passwort-Manager (Kundenkennwörter) | Entities `PasswordManagementArea/*`, `PasswordManager/*`; WPF `Modules/PasswordManager` | Verwaltung fremder Zugangsdaten mit Richtlinien und Zugriffslogs |
|
||||
| M47 (F) | Textbausteine | DbEntities `GeschaeftspartnerTextbausteine`; `Centron.BL/TextModuleArea` | Wiederverwendbare Textmodule |
|
||||
| M48 (F) | Volltext-/Indexsuche | Entities `Administration/IndexSearch/*`; `Centron.BL/IndexSearch` | Objekt- und Dokumentenvolltextindex |
|
||||
| M49 (F) | ChangeTracking / Historisierung | Entities `ChangeTracking/ChangeLog`; `Centron.DAO/ChangeTracking` | Änderungsprotokolle auf Entitäten |
|
||||
| M50 (F) | Mobile Anbindung | Entities `Mobile/*`; `Centron.BL/Mobile` | DTOs und Modulverwaltung für mobile App |
|
||||
| M51 (F) | Massenupdates | Entities `MassUpdate/*`; WPF `Modules/Massenupdates` | Selektive Massenänderungen, Preisupdates |
|
||||
| M52 (F) | Umfragen | Entities `Accounts/Survey/*`; WPF `Modules/Survey` | Kundenbefragungen |
|
||||
| M53 (F) | Gutscheine | `Centron.BL/VoucherManagement`; Entities `VoucherManagement` | Gutscheinverwaltung |
|
||||
| M54 (F) | KI-Integration | Entities `Administration/ArtificialIntelligence/*`; `Centron.BL/ArtificialIntelligence`; WPF `Modules/ArtificialIntelligence` | KI-Chats mit Prompt-Verwaltung und Tool-Aufrufen |
|
||||
| M55 (F) | Lizenzierung & Versionen | `Centron.BL/Administration/Licensing`, `Applications` | Lizenzprüfung bei Anmeldung, Versionskontrolle |
|
||||
| M56 (F) | Soziale Medien / Diverses | `Centron.BL/SocialMedia`, `VideoPortal`, `WebLinks`, `Urls`, `Tags`, `ToDoArea`, `RiverDivo`, `TelekomDive` | Social-Media-Streams, Videoportal, Weblinks, Tags, ToDos, Telekom-Dive |
|
||||
|
||||
Inventar-Stand: 56 Einträge, davon 12 technisch (T) und 44 fachlich (F). Ergänzungen im Verlauf: keine Kürzungen.
|
||||
|
||||
## 3. Mindestabdeckung (Schritt 0b)
|
||||
|
||||
Wird nach Fertigstellung der Anforderungen als Abdeckungstabelle (Abschnitt 4) ausgewiesen. Ziel: jedes Modul ≥ 1 Anforderung; `nicht analysiert` < 10 %.
|
||||
|
||||
## 4. Abdeckungstabelle
|
||||
|
||||
*(wird am Laufende ergänzt)*
|
||||
|
||||
## 5. Konsistenzcheck
|
||||
|
||||
*(wird am Laufende ergänzt)*
|
||||
|
||||
## 6. Selbstbewertung
|
||||
|
||||
*(wird am Laufende ergänzt)*
|
||||
+545
File diff suppressed because one or more lines are too long
+13
@@ -0,0 +1,13 @@
|
||||
[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
|
||||
[glm-kimi-adapter] Start: 2026-08-28T11:35:48.411192+00:00
|
||||
[glm-kimi-adapter] Provider: TensorX API Gateway
|
||||
[glm-kimi-adapter] Modell: moonshotai/kimi-k3
|
||||
[glm-kimi-adapter] Effort: high
|
||||
[glm-kimi-adapter] Mode: solo
|
||||
[glm-kimi-adapter] Ende: 2026-08-28T12:16:57.275888+00:00
|
||||
[glm-kimi-adapter] Turns: 44
|
||||
[glm-kimi-adapter] Tokens gesamt: 3,208,550
|
||||
[glm-kimi-adapter] Tool-Calls: 68
|
||||
[glm-kimi-adapter] Subagenten: 0 (completed: 0, failed: 0)
|
||||
[glm-kimi-adapter] Ergebnisdateien: 1
|
||||
[glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\solo\high\03_Lauf_2026-08-28_125852_v8.0.0-593a\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
[]
|
||||
+4
@@ -0,0 +1,4 @@
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Keine Anforderungen im vorgegebenen Format gefunden.
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+161
@@ -0,0 +1,161 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### 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). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
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). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **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. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **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. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **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.
|
||||
- **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 | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
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). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- 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.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
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 (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
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
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> 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.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\n\nNicht verfuegbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\solo\high\03_Lauf_2026-08-28_125852_v8.0.0-593a\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T14:16:57.3103502+02:00
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"modell": "moonshotai/kimi-k3",
|
||||
"iteration": "Iteration 8",
|
||||
"promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
|
||||
"promptVersion": "03",
|
||||
"modus": "solo",
|
||||
"effort": "high",
|
||||
"skillVersion": "v8.0.0"
|
||||
}
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T12:58:52.5369951+02:00
|
||||
+364
@@ -0,0 +1,364 @@
|
||||
# StRS – Stakeholder Requirements Specification
|
||||
## c-entron ERP-Suite (Reverse Requirements Engineering)
|
||||
|
||||
Basis: statische Analyse der Codebasis (C#/XAML/MSSQL, ca. 2064 C#-Dateien allein in `Centron.BL`, DB-Schema mit 1558 Tabellen).
|
||||
Domäne (belegt durch Modulstruktur, CentronRights.md, README.md): Integriertes ERP für ITK-Systemhäuser / Managed Service Provider – Warenwirtschaft, Service, Vertragsabrechnung, Finanzen, IT-Dokumentation.
|
||||
|
||||
**Stakeholder / Akteure** (abgeleitet aus `CentronRights.md`-Rollenrechten, `README.md` „Contributing/WebCart", `ReceiptBL.GetReceiptByI3D` Web-Account-Prüfung):
|
||||
|
||||
| Akteur | Beschreibung |
|
||||
|---|---|
|
||||
| Vertriebsmitarbeiter (Innen-/Außendienst, `Adviser1/Adviser2`) | Angebote, Aufträge, CRM |
|
||||
| Techniker / Support-Mitarbeiter | Helpdesk-Tickets, Zeiterfassung, RMA |
|
||||
| Disponent / Lagerist | Lager, Seriennummern, Kommissionierung |
|
||||
| Einkäufer | Lieferantenbestellungen, EDI |
|
||||
| Buchhalter | Rechnungen, Mahnwesen, DATEV-Export, Online-Banking |
|
||||
| Vertragsmanager | Klick-/Kontingent-/Serviceverträge, automatische Abrechnung |
|
||||
| Administrator | Benutzer, Rechte, Einstellungen, Mandanten/Filialen |
|
||||
| Web-Kunde (Kunde des Systemhauses, „WebAccount") | Portalzugang: Tickets, Belege, WebCart-Shop |
|
||||
| Externe Systeme | DATEV, FinAPI-Banken, EDI-Distributoren, ITscope/ICEcat, OpenAI, Entra ID |
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
ID: StRS-001
|
||||
Titel: Integrierte ERP-Gesamtlösung für ITK-Systemhäuser
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Gesamtunternehmen
|
||||
Vorbedingung: Systemhaus nutzt c-entron als zentrales ERP
|
||||
Fakt: Die Codebasis umfasst >60 fachliche BL-Module von Warenwirtschaft über Helpdesk bis DATEV-Export und Online-Banking (Verzeichnisstruktur src/backend/Centron.BL/*).
|
||||
Aussage: Das System soll die kaufmännischen, servicetechnischen und finanziellen Kernprozesse eines IT-Systemhauses in einer integrierten Datenbasis abbilden, ohne Medienbruch zwischen Vertrieb, Service, Lager, Einkauf und Finanzen.
|
||||
Ergebnis: Alle Fachbereiche arbeiten auf denselben Entitäten (Kunden, Artikel, Belege, Geräte).
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/ (Modulverzeichnisse Sales, Warehousing, Purchasing, Finances, Accounting, Helpdesk-Bereiche) - Begründung: Modulstruktur dokumentiert den fachlichen Gesamtumfang durchgesetzter Funktionalität.
|
||||
- [KONTEXT] README.md, CentronRights.md - Begründung: beschreiben Einsatzszenario (WebCart für Kunden der Kunden) und Rollenrechte der Fachbereiche.
|
||||
Prüfidee: Durchstich Angebot → Auftrag → Lieferschein → Rechnung → Mahnung → DATEV-Export ohne manuelle Datenerfassung dazwischen.
|
||||
Tracelinks: SyRS-001, SyRS-008
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernzweck des Systems.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-002
|
||||
Titel: Kunden- und Lieferantenstamm (Adressstamm)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertriebsmitarbeiter, Buchhalter, Einkäufer
|
||||
Vorbedingung: Stammdaten werden angelegt und gepflegt
|
||||
Fakt: Entitäten CustomerDetail, CustomerFinanceInfo, Kreditor; Nummernvergabe aus Nummernkreis (NumberGroupEnum.Customer/Supplier); Finanzinfo enthält Zahlungs-/Lieferkonditionen, Sammelkonto, Mahnstatus.
|
||||
Aussage: Das System soll einen zentralen Adressstamm für Kunden und Lieferanten führen, inkl. Adressen, Ansprechpartnern, Finanzkonditionen und kundenspezifischer Preis-/Rabattvereinbarungen (Sonderpreise).
|
||||
Ergebnis: Belege, Verträge und Finanzprozesse greifen konsistent auf dieselben Geschäftspartnerdaten zu.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Customers/CustomerDetail.cs, CustomerFinanceInfo.cs - Begründung: persistierte Datenstruktur des Kundenstamms.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs (NumberGroupEnum.Customer/Supplier) - Begründung: durchgesetzte Nummernvergabe für Geschäftspartner.
|
||||
- [KONTEXT] README.md („Sonderpreise" im Adressstamm steuern WebCart-Sortiment) - Begründung: fachliche Nutzung des Kundenstamms für Shop-Preise.
|
||||
Prüfidee: Neuanlage Kunde erhält nächste Nummer aus Nummernkreis; Sonderpreis-Artikel erscheinen im WebCart des Kunden.
|
||||
Tracelinks: SyRS-004, SyRS-024
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernstammdaten.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-003
|
||||
Titel: Angebots- und Auftragsabwicklung (Belegkette)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertriebsmitarbeiter
|
||||
Vorbedingung: Kunde und Artikelstamm vorhanden
|
||||
Fakt: ReceiptBL.ForwardReceipt verarbeitet Belege positionsweise von einer Belegart in die nächste (Angebot→Auftrag→Lieferschein→Rechnung/Gutschrift), inkl. Validierung (gleicher Kunde, keine Mischung Kunden-/Lieferantenbelege, Filialregeln).
|
||||
Aussage: Das System soll Vertriebsbelege (Angebot, Auftrag/Bestellung, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertragsliste) anlegen, versionieren und ohne Neuerfassung in Folgebelege weiterverarbeiten.
|
||||
Ergebnis: Lückenlose, nachvollziehbare Beleghistorie vom Angebot bis zur Rechnung.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (ForwardReceipt, ValidateReceiptForwarding, GetReceiptForwardedFrom/Into) - Begründung: durchgesetzte Weiterverarbeitungslogik inkl. Sperrregeln.
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs - Begründung: durchgesetzte Belegzustände offen/abgeschlossen/storniert.
|
||||
Prüfidee: Angebot anlegen, in Auftrag weiterverarbeiten, partiell in Lieferschein und Rechnung weiterverarbeiten; Historie zeigt Herkunft je Position.
|
||||
Tracelinks: SyRS-001, SyRS-002, SyRS-003
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kerngeschäft Vertrieb.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-004
|
||||
Titel: Fakturierung und Mahnwesen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhalter
|
||||
Vorbedingung: Rechnungen vorhanden, teils unbezahlt überfällig
|
||||
Fakt: DunningRunBL hebt Mahnstufen None→1→2→3 mit Datum und Sachbearbeiter an, erzeugt Mahnläufe mit fortlaufender Mahnlaufnummer, Report-Gruppe MAHNUNG und optional E-Mail-Versand; ResetDunningRun macht Läufe rückgängig (Status Deleted).
|
||||
Aussage: Das System soll Rechnungen (inkl. Anzahlungs-/Schlussrechnungen, Bar-/Kassenrechnungen) erstellen, Eingangszahlungen verrechnen und überfällige Forderungen in einem dreistufigen, nachvollziehbaren Mahnlauf anmahnen; Kunden lassen sich ab einer Mahnstufe für neue Belege sperren.
|
||||
Ergebnis: Rechtssicher nachvollziehbare Forderungsverfolgung inkl. Mahndokument (PDF/E-Mail) und Sperrlogik.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs (ExecuteDunningRunInternal, SaveDunningRun, ResetDunningRun) - Begründung: durchgesetzte Mahnstufen-Transitionslogik mit Protokoll (DunningRunItem Old/NewDunningLevel).
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs:723 (BlockNewReceiptsDunningLevel) + AppSettingsConst.CustomerAssetsLockedAfterDunningLevel - Begründung: durchgesetzte Belegsperre ab Mahnstufe aus Einstellung.
|
||||
Prüfidee: Überfällige Rechnung mahnen → Stufe 1 mit Datum/Sachbearbeiter; Mahnlauf zurücksetzen → Stufe zurück und Lauf als Deleted markiert.
|
||||
Tracelinks: SyRS-007
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - gesetzlich/fachlich notwendig.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-005
|
||||
Titel: Vertragsmanagement mit automatischer Abrechnung (Klick-/Kontingent-/Serviceverträge)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertragsmanager, Buchhalter
|
||||
Vorbedingung: Kunde besitzt verwaltete Geräte (Stammblätter)
|
||||
Fakt: Entitäten Contract, ContractType, ContractContigentPositions, AutomaticFacturaContract/CounterHistory, DeviceClickCounter; Verträge referenzieren Stammblätter; Kündigungsarten (TerminationType) vorhanden; Stammblatt-Löschung gesperrt bei aktivem Vertrag.
|
||||
Aussage: Das System soll Rahmenverträge mit Kontingenten und zählerbasierter Abrechnung (Seitenpreis je Gerät bzw. Stammblatt) verwalten, Zählerstände importieren und daraus periodische Abrechnungspositionen automatisch erzeugen.
|
||||
Ergebnis: Vertragliche Leistungen werden termingerecht und mengentreu abgerechnet.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/Contract.cs, ClickContracts/DeviceClickCounter.cs, AutomaticFactura/AutomaticFacturaContract.cs - Begründung: persistierte Vertrags-/Zählerdatenstrukturen.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs:163 („Stammblatt ist einem aktiven Vertrag zugeordnet.") - Begründung: durchgesetzte Abhängigkeitsprüfung Vertrag↔Stammblatt.
|
||||
Prüfidee: Vertrag mit 2 Stammblättern und Zählerständen abrechnen → Abrechnungspositionen je Zählerdifferenz; Stammblatt mit aktivem Vertrag kann nicht gelöscht werden.
|
||||
Tracelinks: SyRS-001, SwRS-018, SwRS-019
|
||||
Konsolidierung: Kandidat: VertragKopf (Legacy-DbEntity) vs. Contracts-Namensraum (siehe SwRS-065)
|
||||
Übernahmewürdigkeit: übernehmen - Kerngeschäft MSP.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-006
|
||||
Titel: Geräte- und Assetverwaltung beim Kunden (Stammblätter, Assets)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Techniker, Vertragsmanager, Vertrieb
|
||||
Vorbedingung: Geräte wurden verkauft oder in Betreuung übernommen
|
||||
Fakt: „Stammblätter" (MasterDataList, DB-Tabelle GeraeteKopf) führen Kundengeräte mit Seriennummern und Zubehör; parallel existiert CustomerAsset als eigene Asset-Datenhaltung; Seriennummerntausch am Stammblatt ist rechtegeschützt und protokolliert.
|
||||
Aussage: Das System soll kundenseitige Geräte/Stammdatenblätter und sonstige Assets verwalten, sie Belegen, Tickets und Verträgen zuordnen und Änderungen an Seriennummern rechtegesichert und nachvollziehbar protokollieren.
|
||||
Ergebnis: Jederzeit richtige Geräteinformation für Service und Abrechnung.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs (Seriennummern-Entfernen/Tauschen, Historieneintrag Zeile 410) - Begründung: durchgesetzte Gerätestammlogik.
|
||||
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/MasterDataLists/MasterDataListWebServiceBL.cs:173 („Fehlende Rechte ...", DefaultMessageCodes.RightCheckFailed) - Begründung: durchgesetzte Rechteprüfung Seriennummernänderung.
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/CustomerAssets/CustomerAsset.cs - Begründung: zweite, getrennte persistente Asset-Datenhaltung.
|
||||
Prüfidee: Seriennummer am Stammblatt ohne Recht tauschen → Fehler RightCheckFailed; mit Recht → Historieneintrag vorhanden.
|
||||
Tracelinks: SyRS-011, SwRS-015, SwRS-016
|
||||
Konsolidierung: Kandidat: Stammblätter (MasterDataList/GeraeteKopf) und CustomerAsset sind zwei Datenhaltungen für „Kundengerät" → zu vereinheitlichen
|
||||
Übernahmewürdigkeit: übernehmen - Kerndaten für Servicegeschäft.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-007
|
||||
Titel: Helpdesk-/Ticketmanagement mit Zeiterfassung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Techniker, Support, Disponent
|
||||
Vorbedingung: Kunde meldet Anliegen; ggf. Vertrag/Leistung hinterlegt
|
||||
Fakt: Entitäten Helpdesk (Ticket), HelpdeskTimer (Zeiten mit BillingState, Unterschrift), Eskalationen, SupportLevel; umfangreiches Rechtemodell (CentronRights.md Abschnitt Helpdesk: Sichtbarkeit, eigene/Filiale, Zeiten, Fälligkeit, Schließen).
|
||||
Aussage: Das System soll Tickets mit Kategorien, Zuständigkeiten, Fälligkeiten und Eskalationen verwalten, Arbeitszeiten inkl. Zusatzartikel und Unterschrift erfassen und diese vertragsgerecht (Leistung/Vertrag/Stammblatt-Bindung) abrechenbar machen.
|
||||
Ergebnis: Serviceleistungen sind geplant, dokumentiert und abrechnungsfähig.
|
||||
Belege:
|
||||
- [PRIMÄR] CentronRights.md (Helpdesk-Rechte 1–18 inkl. restriktiver Rechte) - Begründung: dokumentiertes, im Code referenziertes Rechtemodell (UserRightsConst...).
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Support/HelpdeskTimerArea/HelpdeskTimer.cs, HelpdeskTimerBillingState.cs, Escalation/Escalations.cs - Begründung: persistierte Ticket-/Zeit-/Eskalationsstrukturen.
|
||||
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskTimerWebServiceBL.cs (Leistung diktiert Vertrag/Stammblatt, Zeilen 782–860) - Begründung: durchgesetzte Bindungslogik Zeit↔Leistung/Vertrag/Stammblatt.
|
||||
Prüfidee: Zeit auf Ticket mit Leistung buchen → Vertrag und Stammblatt automatisch gebunden; Umverschieben der Zeit auf anderes Ticket nur losgelöst möglich (gem. Dialoglogik).
|
||||
Tracelinks: SyRS-011, SwRS-020, SwRS-021, SwRS-022
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kerngeschäft Service.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-008
|
||||
Titel: Lagerverwaltung mit Seriennummern und Inventur
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Disponent, Lagerist
|
||||
Vorbedingung: Artikel und Lagerorte definiert
|
||||
Fakt: Module Warehouse/StockManagement, InventoryManagement, CommissioningManagement; Barcode/Seriennummern mit Zustandsautomaten (u. a. „im Lager", „in Stammblatt", „in Beleg"); Umbuchung auf Stammblatt nur erlaubt, wenn Seriennummer „im Lager".
|
||||
Aussage: Das System soll Lagerbestände je Lager/Filiale führen, Seriennummern über ihre Lebenszyklen verfolgen, Warenein-/ausgänge buchen, Kommissionierungen unterstützen und Inventuren ermöglichen.
|
||||
Ergebnis: Lagerbestand und Seriennummernverbleib sind jederzeit wahrheitsgemäß.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Warehousing/BarcodeBL.cs:1091 („... kann nicht auf das Stammblatt umgebucht werden. Diese befindet sich nicht mehr 'im Lager'") - Begründung: durchgesetzte Zustandsregel für Seriennummern.
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Warehousing/BarcodeState.cs (Zustände inkl. „in Stammblatt") - Begründung: definierter Zustandsautomat.
|
||||
- [SEKUNDÄR] Verzeichnisse src/backend/Centron.BL/Warehousing/{StockManagement,InventoryManagement,CommissioningManagement} - Begründung: zeugen von Bestands-, Inventur- und Kommissionierfunktion.
|
||||
Prüfidee: Seriennummer aus Belegentnahme ist nicht mehr „im Lager" → Umbuchung auf Stammblatt wird mit Fehlermeldung abgelehnt.
|
||||
Tracelinks: SyRS-016, SwRS-017, SwRS-043
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernfunktion Handel.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-009
|
||||
Titel: Einkauf und Beschaffung inkl. Distributor-Integrationen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Einkäufer
|
||||
Vorbedingung: Lieferanten und Artikel angelegt
|
||||
Fakt: Module Purchasing (Lieferantenbestellungen, Bestellvorschläge, filialspezifische Bestellungen), Gateway-EDI-Adapter für Distributoren (ALSO, AlsoCH, Alltron, EGIS, Komsa, Herweck, Concerto) sowie OpenTrans 1.0/2.1; Lieferantenbelege: Bestellung, Wareneingang (SupplierDeliveryList), Eingangsrechnung, -gutschrift.
|
||||
Aussage: Das System soll Bestellvorschläge generieren, Lieferantenbestellungen auslösen, Wareneingänge und Eingangsrechnungen erfassen sowie Katalog- und Bestellprozesse elektronisch mit IT-Distributoren abwickeln (EDI/OpenTrans).
|
||||
Ergebnis: Beschaffung von der Bedarfsermittlung bis zur Eingangsrechnungsprüfung ohne Medienbruch.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Gateway/{EDI_Also,EDI_Alltron,EDI_EGIS,EDI_Komsa,EDI_Herweck,OpenTrans,OpenTrans1_0} - Begründung: implementierte Distributor-EDI-Adapter.
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/SupplierOrders/ReceiptSupplierOrder.cs, ReceiptSupplierOrderIntake.cs - Begründung: persistierte Lieferantenbelegstrukturen.
|
||||
- [SEKUNDÄR] src/backend/Centron.BL/Warehousing/OrderSuggestionList/, SupplierOrderPerBranchBL.cs - Begründung: Bestellvorschlags- und Filialbestellfunktion.
|
||||
Prüfidee: Bestellung an ALSO via EDI versenden; Wareneingang bucht Bestand und erzeugt SupplierDeliveryList; Eingangsrechnung (ggf. ZUGFeRD-Import) zugeordnet.
|
||||
Tracelinks: SyRS-016, SyRS-017, SwRS-041, SwRS-042
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernfunktion IT-Handel.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-010
|
||||
Titel: Finanzschnittstellen (Buchhaltungsexport, Online-Banking)
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhalter, Steuerberater (extern)
|
||||
Vorbedingung: Belege gebucht; Exportformat konfiguriert
|
||||
Fakt: BookKeepingExportBL unterstützt 13 Exportformate (DATEV ASCII, DATEV XML-Online 2012/2020, Lexware, Sage 50/Office Line, SAP, Abacus, Navision, Addison, GDI, Europa3000, Schilling AS400, freie Schnittstelle); DATEV-Belegtransfer ist lizenzpflichtig (LicenseGuids.DatevOnline); OnlineBanking über FinAPI mit Bankverbindungen und Umsatzabruf.
|
||||
Aussage: Das System soll Buchungsdaten (Debitoren/Kreditoren, deren Belege, Kassenbuch) in gängigen Buchhaltungsformaten exportieren, Exporte als übertragen markieren und Bankumsätze elektronisch abrufen/zuordnen.
|
||||
Ergebnis: Finanzbuchhaltung und Bankabgleich erfolgen ohne manuelle Belegerfassung im Buchhaltungssystem.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs (InvokeExportClass; Zeilen 1564–1565 Lizenzprüfung DatevOnline) - Begründung: durchgesetzte Exportformatauswahl und Lizenzgate.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Finances/OnlineBanking/{OnlineBankingAccountTransactionsBL.cs, OnlineBankingFinApiBL.cs} + src/apis/Centron.APIs.FinAPI - Begründung: implementierte Bankanbindung.
|
||||
Prüfidee: Export DATEV ASCII für Zeitraum → Datei + Belege als transferiert markiert; Export ohne DatevOnline-Lizenz → Fehler LicenseNotFound.
|
||||
Tracelinks: SyRS-008, SyRS-009, SwRS-035
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Pflichtschnittstellen für Steuerberatung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-011
|
||||
Titel: IT-Dokumentation der Kundeninfrastruktur
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Techniker
|
||||
Vorbedingung: Kunde in Betreuung
|
||||
Fakt: Entities DocumentationWizardArea (ActiveDirectory, BackupAndRestore, Machine, MailServer, NetworkComponent inkl. Drucker/Firewall/Router/Switch-Subtypen, NetworkStructure mit DHCP/DNS/NTP/WINS); separater PasswortManager für Kundenzugangsdaten (AES-verschlüsselt).
|
||||
Aussage: Das System soll die IT-Umgebung des Kunden (Netzstruktur, Server, Mail, AD, Backup, Zugangsdaten) strukturiert dokumentieren und vertrauliche Zugangsdaten verschlüsselt ablegen.
|
||||
Ergebnis: Serviceeinsätze können auf aktueller Kundendokumentation aufsetzen; Geheimnisse sind geschützt.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/DocumentationWizardArea/*.cs - Begründung: persistierte Dokumentationsdatenstruktur.
|
||||
- [PRIMÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs (AESCryptoLogic Encrypt/Decrypt mit MasterKey) - Begründung: durchgesetzte Verschlüsselung von Kennwörtern.
|
||||
Prüfidee: Kunden-Passwort im Passwortmanager speichern → Datensatz enthält ValueEncryptedString (kein Klartext); Anzeige nur nach Entschlüsselung mit Master-Key.
|
||||
Tracelinks: SyRS-015, SwRS-010
|
||||
Konsolidierung: Kandidat: PasswordManager vs. PasswordManagementArea (zwei Verzeichnisse) – SwRS-010
|
||||
Übernahmewürdigkeit: übernehmen - IT-Doku ist Kernnutzen für MSP.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-012
|
||||
Titel: Arbeitsorganisation und Kollaboration (Kalender, Aufgaben, Chat, E-Mail, MyDay)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: alle Mitarbeiter
|
||||
Vorbedingung: Benutzer angelegt
|
||||
Fakt: Kalender-Entities (Schedule, Urlaub ScheduleVacation mitsamt Log, Serientermine, Gruppen); ToDo/Wiedervorlage; Taskmanagement; Chat; Mail-Subsystem (Exchange, Protokolle, Templates, Blacklist); MyDay-Aggregation; Rechte für „nur eigene Kalender"/„nur eigene Filiale".
|
||||
Aussage: Das System soll Mitarbeitern gemeinsame Kalender inkl. Urlaubsplanung, Aufgaben-/Wiedervorlagen, internen Chat, E-Mail-Anbindung und eine Tagesübersicht (MyDay) bereitstellen, jeweils rechtebeschränkt.
|
||||
Ergebnis: Tagesarbeit ist im System plan- und dokumentierbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Calendar/*.cs (ScheduleVacationDaysLog u. a.) - Begründung: persistierte Kalenderstruktur inkl. Historie.
|
||||
- [PRIMÄR] CentronRights.md (Kalender: RIGHT_KALENDERANZEIGENEIGENE als restrictendes Recht) - Begründung: dokumentierte Sichtbarkeitsregeln.
|
||||
- [SEKUNDÄR] src/backend/Centron.BL/{ToDoArea,TaskManager,Chats,Mail,MyDay} - Begründung: Modulumfang Arbeitsorganisation.
|
||||
Prüfidee: Mitarbeiter mit Recht RIGHT_KALENDERANZEIGENEIGENE sieht nur eigene Termine; Urlaubsänderung erzeugt Logeintrag.
|
||||
Tracelinks: SyRS-011, SyRS-023, SwRS-023..SwRS-031
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Orgafunktionen, teils Konkurrenz zu Outlook-Standardfunktionen (im Zielsystem Abgrenzung prüfen).
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-013
|
||||
Titel: Reporting, Statistiken und Belegdokumente
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Management, Vertrieb, Buchhaltung
|
||||
Vorbedingung: Geschäftsdaten vorhanden
|
||||
Fakt: ReportEngine (FastReport, PDF-Export, Reportgruppen-GUIDs, Vorlage je Mandant), Statistikmodule (MSP-Statistiken, Ticket-/Umsatzstatistiken), Beleg-PDF-Erzeugung inkl. Archivierung und PDF-Signatur.
|
||||
Aussage: Das System soll Geschäftsauswertungen und druckbare Belege (Angebot, Rechnung, Mahnung, Stammblatt …) aus konfigurierbaren Reportvorlagen erzeugen, Beleg-PDFs revisionssicher archivieren und optional signieren.
|
||||
Ergebnis: Entscheidungsrelevante Auswertungen und rechtssichere Belegdokumente liegen vor.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/ReportEngine/{ReportDataBL.cs, ReportGroupBL.cs, FastReportHelper.cs} - Begründung: implementierte Report-Infrastruktur.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (ArchivePdf, CreateFullReportForReceipt, PdfSigningBL-Aufruf) - Begründung: durchgesetzte Archivierung/Signatur beim Rechnungsversand.
|
||||
Prüfidee: Rechnung per E-Mail versenden → PDF archiviert (ArchivePdf) und bei aktivierter Signatur signiert.
|
||||
Tracelinks: SyRS-019, SyRS-005, SwRS-033, SwRS-034
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Pflicht (Archivierung) und Mehrwert (Statistik).
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-014
|
||||
Titel: Webportale für Endkunden (Nexus, WebCart, Customer Portal)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Web-Kunde (Kunde des Systemhauses)
|
||||
Vorbedingung: WebAccount im Adressstamm angelegt; Sonderpreise gepflegt
|
||||
Fakt: CentronNexus (Blazor Server) mit eigenem Login für Web-Accounts; WebCart-Shop zeigt Kunden-Sonderpreise; Customer Portal lauscht auf getrenntem Port; WebAccount-Logins sehen ausschließlich eigene Kundendaten (serverseitige Filterung in ReceiptBL.GetReceiptByI3D).
|
||||
Aussage: Das System soll Endkunden einen Webzugang zu ihren Tickets, Belegen und einem Shop mit kundenindividuellen Preisen bieten, wobei ein Web-Kunde niemals Daten anderer Kunden sieht.
|
||||
Ergebnis: Self-Service für Endkunden bei strikter Mandantentrennung auf Kundenebene.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (GetReceiptByI3D: WebAccount.CustomerI3D-Abgleich, sonst null) - Begründung: durchgesetzte serverseitige Datenzugriffsbeschränkung.
|
||||
- [PRIMÄR] src/nexus/CentronNexus.Host/Program.cs (Port-Authorization HostPort vs. CustomerPortalPort; WebAccount-Rechte-Authorization) - Begründung: durchgesetzte Mandanten-/Porttrennung.
|
||||
- [KONTEXT] README.md („WebCart … customers of our customers … Sonderpreise") - Begründung: fachlicher Zweck des Shops.
|
||||
Prüfidee: Als Web-Account von Kunde A die URL einer Rechnung von Kunde B aufrufen → keine Daten (null/403), auch bei direktem API-Aufruf.
|
||||
Tracelinks: SyRS-024, SyRS-025, SyRS-014
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - zentraler Bestandteil der SaaS-Zielarchitektur.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-015
|
||||
Titel: Rollenbasiertes Berechtigungsmodell mit restriktiven Rechten
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit (ISO 25010)
|
||||
Akteur: Administrator
|
||||
Vorbedingung: Benutzer und Rechtegruppen angelegt
|
||||
Fakt: Rechte werden als Konstanten-Hierarchie (UserRightsConst) geführt; es gibt gewährende und „restricting rights" (z. B. SHOW_HELPDESK_ONLY_OWN); Prüfung serverseitig via AppRightsBL.HasUserRight.
|
||||
Aussage: Das System soll Funktionen und Datenbereiche über ein feingranulares Rechtemodell steuern, das sowohl Zuwachs- als auch Beschränkungsrechte (nur eigene/eigene Filiale/eigene Abteilung) unterstützt; Rechte werden serverseitig durchgesetzt.
|
||||
Ergebnis: Benutzer sehen und ändern nur, was ihre Rolle erlaubt; Admin kann restriktive Profile abbilden.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:644 (HasUserRight(int appUserI3D, int rightID)) - Begründung: durchsetzende Stelle der Rechteprüfung.
|
||||
- [PRIMÄR] CentronRights.md (Definition gewährende vs. restricting rights mit Konstanten) - Begründung: verbindliche Rechtesemantik, direkt auf UserRightsConst referenzierend.
|
||||
Prüfidee: Benutzer mit SHOW_HELPDESK_ONLY_OWN erhält in Ticketliste nur Tickets mit eigener Bearbeiter-/Verantwortlichenrolle.
|
||||
Tracelinks: SyRS-011, SyRS-012
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Pflicht für Mehrbenutzerbetrieb und SaaS-Mandanten.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-016
|
||||
Titel: Mandanten- und Filialfähigkeit
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Übertragbarkeit / Anpassbarkeit (ISO 25010)
|
||||
Akteur: Administrator, Unternehmensgruppe
|
||||
Vorbedingung: mehrere Mandanten/Filialen eingerichtet
|
||||
Fakt: Nummernkreise sind mandanten-/filialspezifisch mit Fallback-Kette Mitarbeiter→Filiale→Default-Mandant (MandatoryBL); Belege tragen BranchI3D; Sammelbelege über Filialen hinweg nur für dafür freigegebene Belegarten; Reportvorlagen mandantbezogen.
|
||||
Aussage: Das System soll mehrere Mandanten und Filialen mit eigenen Nummernkreisen, Benutzersichten und Belegzuordnungen unterstützen, inkl. konfigurierbarer Regeln für filialübergreifende Sammelbelege.
|
||||
Ergebnis: Konzernstrukturen sind abbildbar, Nummernkreise bleiben je Filiale lückenlos.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs (GetNumberGroupFromEmployee/Branch/DefaultMandator) - Begründung: durchgesetzte Fallback-Hierarchie der Nummernkreise.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (Region „Branch" im ValidateReceiptForwarding; SupportsMultipleBranches) - Begründung: durchgesetzte Filialregel für Sammelbelege.
|
||||
Prüfidee: Rechnung in Filiale B anlegen → Nummer aus Filiale-B-Kreis; zwei Belege unterschiedlicher Filialen in nicht-mehrfachfilialfähige Belegart → Fehlermeldung.
|
||||
Tracelinks: SyRS-004, SyRS-026
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Voraussetzung für SaaS-Mandantenfähigkeit.
|
||||
Status: belegt
|
||||
```
|
||||
+562
File diff suppressed because one or more lines are too long
+13
@@ -0,0 +1,13 @@
|
||||
[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
|
||||
[glm-kimi-adapter] Start: 2026-08-28T14:10:03.971728+00:00
|
||||
[glm-kimi-adapter] Provider: TensorX API Gateway
|
||||
[glm-kimi-adapter] Modell: moonshotai/kimi-k3
|
||||
[glm-kimi-adapter] Effort: high
|
||||
[glm-kimi-adapter] Mode: solo
|
||||
[glm-kimi-adapter] Ende: 2026-08-28T15:18:47.346573+00:00
|
||||
[glm-kimi-adapter] Turns: 27
|
||||
[glm-kimi-adapter] Tokens gesamt: 1,473,405
|
||||
[glm-kimi-adapter] Tool-Calls: 67
|
||||
[glm-kimi-adapter] Subagenten: 0 (completed: 0, failed: 0)
|
||||
[glm-kimi-adapter] Ergebnisdateien: 1
|
||||
[glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\solo\high\03_Lauf_2026-08-28_160956_v8.0.0-281c\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+161
@@ -0,0 +1,161 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### 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). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
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). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **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. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **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. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **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.
|
||||
- **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 | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
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). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- 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.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
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 (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
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
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> 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.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\n\nNicht verfuegbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\solo\high\03_Lauf_2026-08-28_160956_v8.0.0-281c\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T17:18:47.3861702+02:00
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"modell": "moonshotai/kimi-k3",
|
||||
"iteration": "Iteration 8",
|
||||
"promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
|
||||
"promptVersion": "03",
|
||||
"modus": "solo",
|
||||
"effort": "high",
|
||||
"skillVersion": "v8.0.0"
|
||||
}
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T16:09:56.9053311+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+161
@@ -0,0 +1,161 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### 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). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
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). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **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. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **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. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **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.
|
||||
- **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 | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
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). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- 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.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
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 (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
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
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> 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.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\nNicht verfuegbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\solo\high\03_Lauf_2026-08-28_194103_v8.0.0-b1a2\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"modell": "moonshotai/kimi-k3",
|
||||
"iteration": "Iteration 8",
|
||||
"promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
|
||||
"promptVersion": "03",
|
||||
"modus": "solo",
|
||||
"effort": "high",
|
||||
"skillVersion": "v8.0.0"
|
||||
}
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T19:41:03.4969129+02:00
|
||||
+401
@@ -0,0 +1,401 @@
|
||||
# Analysebericht – Reverse Requirements Engineering der c-entron ERP-Suite
|
||||
|
||||
## Schritt 0 – Modulinventar
|
||||
|
||||
Das Inventar wurde vor der ersten Anforderung erstellt. Es umfasst die gesamte Codebasis im Arbeitsverzeichnis. Module sind nach fachlicher Zugehörigkeit gruppiert; die Pfadangabe verweist auf das jeweilige Verzeichnis im Codebaum.
|
||||
|
||||
| # | Fachliches Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| 1 | Accounting / Bankverwaltung | `src/backend/Centron.BL/Accounting/` | Verwaltung von Bankverbindungen (IBAN, BIC, SEPA-Mandate) für Kunden und Lieferanten inkl. Standard-Bankkonto-Logik. |
|
||||
| 2 | Accounts / Adressstamm | `src/backend/Centron.BL/Accounts/` | Zentrale Kunden-/Lieferantenstammdatenverwaltung mit Adressen, Ansprechpartnern, Klassifizierungen, Beziehungen und Kundennummernvergabe. |
|
||||
| 3 | Administration / Rechte | `src/backend/Centron.BL/Administration/Rights/` | Benutzerrechteverwaltung: Rechtegruppen, Rechteprüfung, Admin-Gruppen-Schutz, Branch-Beschränkung. |
|
||||
| 4 | Administration / Lizenzierung | `src/backend/Centron.BL/Administration/Licensing/` | Lizenzmanagement: LicenseManager-Singleton, Lizenzprüfung (GUID-basiert), Lizenzdatei-Verwaltung, Kundennummer-Extraktion. |
|
||||
| 5 | Administration / Mitarbeiter | `src/backend/Centron.BL/Administration/Employees/` | Systemtechnische Mitarbeitereinstellungen: Abteilungs-Sortierung, Vertriebsgebiets-Zuordnung. |
|
||||
| 6 | Administration / Authentifizierung | `src/backend/Centron.BL/Administration/Logins/Auth/` | Authentifizierungs-Pipeline: Basic, Active Directory, WebAccount, OpenID Connect; Ticket-Erstellung, Validierung, Kontosperrung. |
|
||||
| 7 | Administration / Settings | `src/backend/Centron.BL/Administration/Settings/` | Systemeinstellungen: SEPA-Konfiguration, App-Settings, Mandanteneinstellungen. |
|
||||
| 8 | Administration / DSGVO | `src/backend/Centron.BL/Administration/DataSecurity/` | DSGVO-Modul: Datenlöschung, Kontaktbereinigung, Datenbank-Cleanup. |
|
||||
| 9 | Administration / Scripts | `src/backend/Centron.BL/Administration/Scripts/` | Script-Engine: Ausführung von SQL-Skripten, wiederkehrende Skripte, Migrationsskripte. |
|
||||
| 10 | Administration / FileManagement | `src/backend/Centron.BL/Administration/FileManagement/` | Dateimanagement: Verzeichnisstrukturen, Dateiablage. |
|
||||
| 11 | Artificial Intelligence | `src/backend/Centron.BL/ArtificialIntelligence/` | KI-Funktionen: Ticket-Zusammenfassung, Web-Suche, Datei-Analyse, Modell-Auswahl. |
|
||||
| 12 | Buying / Lieferanten | `src/backend/Centron.BL/Buying/` | Lieferantenverwaltung: Distributoren, Supplier-Assets. |
|
||||
| 13 | Calendar | `src/backend/Centron.BL/Calendar/` | Kalenderdarstellung, Outlook-Synchronisation, Ticket-Terminbenachrichtigungen. |
|
||||
| 14 | ChangeTracking | `src/backend/Centron.BL/ChangeTracking/` und `src/backend/Centron.DAO/ChangeTracking/` | Automatische Änderungsverfolgung über NHibernate Event-Listener mit Diff-Protokollierung. |
|
||||
| 15 | Chats | `src/backend/Centron.BL/Chats/` | Interne Chat-Funktion zwischen Mitarbeitern. |
|
||||
| 16 | CheckListArea | `src/backend/Centron.BL/CheckListArea/` | Checklistenverwaltung mit Vorlagen, hierarchischen Items, Kunden-Mappings, Export als Text. |
|
||||
| 17 | Core | `src/backend/Centron.BL/Core/` | Kern-Business-Logik: CryptoUtils, BaseBL, BLSession, SystemInfoLogger. |
|
||||
| 18 | CountryArea | `src/backend/Centron.BL/CountryArea/` | Länderverwaltung und länderspezifische Einstellungen. |
|
||||
| 19 | CustomerArea / RMA | `src/backend/Centron.BL/CustomerArea/` | Retourenmanagement (RMA): Rücksendungen, Umbuchungen, Verschrottung, Fremdware, Reparatur. |
|
||||
| 20 | Customizations | `src/backend/Centron.BL/Customizations/` | Kunden-/Mandanten-spezifische Anpassungen und Customizing-Regeln. |
|
||||
| 21 | DataExchange / Buchhaltung | `src/backend/Centron.BL/DataExchange/BookKeeping/` und `src/backend/Centron.Gateway/DataExchange/BookKeeping/` | Buchhaltungsschnittstellen: Export/Import für 14+ Systeme (DATEV, Abacus, Sage, SAP, etc.), Splitbuchungen, Rundungskorrekturen. |
|
||||
| 22 | DataExchange / Connectors | `src/backend/Centron.BL/DataExchange/Connectors/` | Konnektoren für externe Datenaustauschsysteme. |
|
||||
| 23 | DataExchange / PaymentTransactions | `src/backend/Centron.BL/DataExchange/PaymentTransactions/` und `src/backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa/` | SEPA-Lastschrift-Generierung (pain.008), Validierung, mehrere Formate (STUZZA bis GBIC4). |
|
||||
| 24 | DataExchange / EDI-Import | `src/backend/Centron.BL/DataExchange/EDI/` und `src/backend/Centron.Gateway/Import/EDI/` | EDI-Bestellimport von Lieferanten (Avnet) und Kundenseitig. |
|
||||
| 25 | DataExchange / RMM | `src/backend/Centron.BL/DataExchange/Rmm/` | Remote Monitoring & Management-Schnittstellen. |
|
||||
| 26 | DataExchange / TanssInterfaces | `src/backend/Centron.BL/DataExchange/TanssInterfaces/` | TANSS-Schnittstellen-Integration. |
|
||||
| 27 | DataExchange / TelekomDive | `src/backend/Centron.BL/DataExchange/TelekomDive/` | Telekom-Dive-Schnittstelle. |
|
||||
| 28 | DataExchange / GfkExport | `src/backend/Centron.BL/DataExchange/GfkExport/` | GfK-Export (Marktforschungsdaten). |
|
||||
| 29 | DataExchange / DocuForm | `src/backend/Centron.BL/DataExchange/DocuForm/` | docuFORM-Schnittstelle. |
|
||||
| 30 | Devices | `src/backend/Centron.BL/Devices/` | Geräteverwaltung (Drucker-Hardware, sonstige Hardware/Assets). |
|
||||
| 31 | DocuBoard | `src/backend/Centron.BL/DocuBoard/` | Dokumenten-Board / Dokumentenverwaltung. |
|
||||
| 32 | EDI | `src/backend/Centron.BL/EDI/` und `src/backend/Centron.Gateway/EDI_*/` | Elektronischer Datenaustausch mit Lieferanten (Alltron, ALSO, EGIS, Herweck, Komsa, Concerto, OpenTrans). |
|
||||
| 33 | EmployeeArea | `src/backend/Centron.BL/EmployeeArea/` | Personalverwaltung: Mitarbeiterstamm, Urlaub, Feiertage, RFID-Tokens, Abteilungen, Kundenübertragung, Verzeichnisstrukturen. |
|
||||
| 34 | ExternalHelpdesk | `src/backend/Centron.BL/ExternalHelpdesk/` | Externe Helpdesk-Konfiguration pro Kunde und Standort. |
|
||||
| 35 | ExternalToolsBL | `src/backend/Centron.BL/ExternalToolsBL/` | Einbindung externer Tools. |
|
||||
| 36 | Finances / Produktlebenszyklus | `src/backend/Centron.BL/Finances/` | Produktlebenszyklus-Verwaltung (Lizenzartikel), Einnahmen, Online-Banking, Zahlungen. |
|
||||
| 37 | Finances / IncomingPayments | `src/backend/Centron.BL/Finances/IncomingPayments/` | Zahlungseingangsverwaltung und Zahlungslog. |
|
||||
| 38 | Gateway / OnlineBanking | `src/backend/Centron.Gateway/OnlineBanking/` | FinTS/HBCI-Banktransaktionen via libfintx. |
|
||||
| 39 | Gateway / OpenTrans | `src/backend/Centron.Gateway/OpenTrans/` und `src/backend/Centron.Gateway/OpenTrans1_0/` | B2B-Austauschformat OpenTrans 1.0 und 2.1. |
|
||||
| 40 | Gateway / ZUGFeRD | `src/backend/Centron.Gateway/ZUGFeRD21_Extended/` | E-Rechnung nach ZUGFeRD 2.1 / FACTUR-X Extended. |
|
||||
| 41 | Gateway / Concerto | `src/backend/Centron.Gateway/Concerto/` | Concerto B2B-Bestellformat. |
|
||||
| 42 | Gateway / Export | `src/backend/Centron.Gateway/Export/EDI/` | EDI-Export (z.B. BBG/Bundesbeschaffung über ebInterface). |
|
||||
| 43 | Gateway / MspCollector | `src/backend/Centron.Gateway/MspCollector/` | MSP-Datenkollektor (Octopus, Wortmann). |
|
||||
| 44 | Gateway / Portal | `src/backend/Centron.Gateway/Portal/` | Centron-Portal-Webservice (WCF/JSON). |
|
||||
| 45 | GUI | `src/backend/Centron.BL/GUI/` | GUI-spezifische Business-Logik (UI-Verhalten). |
|
||||
| 46 | IndexSearch | `src/backend/Centron.BL/IndexSearch/` | Volltext-Indexsuche über Objekte und Dokumente. |
|
||||
| 47 | Integrations | `src/backend/Centron.BL/Integrations/` | ES-Kundengruppen und ES-Rollen ( externe System-Integration). |
|
||||
| 48 | ItPlanner | `src/backend/Centron.BL/ItPlanner/` | IT-Planer-Modul. |
|
||||
| 49 | Logistics / Warehousing | `src/backend/Centron.BL/Logistics/` | Lagerverwaltung: Hauptlager, Nebenlager, RMA-Lager, Umbuchungen, Bestandsverwaltung. |
|
||||
| 50 | Mail | `src/backend/Centron.BL/Mail/` | E-Mail-Konfiguration: SMTP, Exchange, Microsoft Graph, Mail-Tracking, Signaturen, Passwortverschlüsselung. |
|
||||
| 51 | Mailings | `src/backend/Centron.BL/Mailings/` | Mailing-/Kampagnenverwaltung. |
|
||||
| 52 | MailScanner | `src/backend/Centron.BL/MailScanner/` | Automatisches E-Mail-Scanning für Ticket-Erstellung. |
|
||||
| 53 | MassUpdate | `src/backend/Centron.BL/MassUpdate/` | Massenaktualisierung von Daten. |
|
||||
| 54 | Mobile | `src/backend/Centron.BL/Mobile/` | Mobile-Funktionen und mobile Datenzugriffe. |
|
||||
| 55 | Modules | `src/backend/Centron.BL/Modules/` | Modulverwaltung und Modul-Konfiguration. |
|
||||
| 56 | MyCentron | `src/backend/Centron.BL/MyCentron/` | Personalisierte Startseite / Mein c-entron. |
|
||||
| 57 | MyDay | `src/backend/Centron.BL/MyDay/` | Aufgabenliste "Mein Tag" mit Benachrichtigungen, Berichten, Supremo-Integration. |
|
||||
| 58 | NexusNotifications | `src/backend/Centron.BL/NexusNotifications/` | Nexus-spezifische Benachrichtigungslogik. |
|
||||
| 59 | NexusTicketViews | `src/backend/Centron.BL/NexusTicketViews/` | Nexus-spezifische Ticket-Ansichten und -Filter. |
|
||||
| 60 | Notifications | `src/backend/Centron.BL/Notifications/` | Allgemeine Benachrichtigungssystem (User-Notifications). |
|
||||
| 61 | ObjectExternalReferences | `src/backend/Centron.BL/ObjectExternalReferences/` | Externe Referenzen für Objekte (Verknüpfung mit Fremdsystemen). |
|
||||
| 62 | Outlook | `src/backend/Centron.BL/Outlook/` | Outlook-Integration (Termine, E-Mails). |
|
||||
| 63 | PasswordManagementArea | `src/backend/Centron.BL/PasswordManagementArea/` | Legacy-Passwortverwaltung für Kunden-Assets (verschlüsselte Passwörter pro Asset). |
|
||||
| 64 | PasswordManager | `src/backend/Centron.BL/PasswordManager/` | Neuer Passwort-Manager mit Richtlinien, Versiegelung, VPN-Zugängen, Kunden-Mitarbeiter-Rechte-Matrix, Export. |
|
||||
| 65 | Processes | `src/backend/Centron.BL/Processes/` | Prozessverwaltung (Geschäftsprozesse, Workflow-Engine). |
|
||||
| 66 | Production | `src/backend/Centron.BL/Production/` | Produktionsmanagement: Maschinen, Maschinenarten, Standorte, Arbeitsschritte, Fertigungsaufträge. |
|
||||
| 67 | ProductMatrix | `src/backend/Centron.BL/ProductMatrix/` | Produktmatrix-Verwaltung (Artikel-Konfigurationsmatrix). |
|
||||
| 68 | Projects | `src/backend/Centron.BL/Projects/` | Projektverwaltung. |
|
||||
| 69 | Purchasing | `src/backend/Centron.BL/Purchasing/` | Einkauf: filialübergreifende Lieferantenabrechnung, Bestellvorschlagsliste, Lieferantenverwaltung. |
|
||||
| 70 | ReportEngine | `src/backend/Centron.BL/ReportEngine/` | Report-Engine: Report-Generierung, Reportdaten, Report-Vorlagen. |
|
||||
| 71 | Reporting | `src/backend/Centron.BL/Reporting/` | Berichtswesen und Report-Business-Logik. |
|
||||
| 72 | RiverDivo | `src/backend/Centron.BL/RiverDivo/` | Riverbird-Integration für externe Kontingentabrechnung. |
|
||||
| 73 | Sales / Belege | `src/backend/Centron.BL/Sales/Receipts/` | Belegverwaltung: Angebote, Aufträge, Lieferscheine, Rechnungen, Gutschriften, Belegkette, Preisberechnung, Weiterverarbeitung. |
|
||||
| 74 | Sales / Kunden | `src/backend/Centron.BL/Sales/Customers/` | Kundenspezifische Vertriebslogik: Kundeneinstellungen, Provisionen. |
|
||||
| 75 | Sales / Verträge | `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/` | Vertragsverwaltung: Laufzeiten, Abrechnung, Kontingente, automatische Fakturierung, Vertragsarten. |
|
||||
| 76 | Sales / Mahnwesen | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/` | Mahnwesen: Mahnläufe (3 Stufen), Mahnstop, Mahnstatistiken, Belegsperre. |
|
||||
| 77 | Sales / OPOS | `src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/` | Offene-Posten-Verwaltung: OPOS-Läufe, Kontoauszüge, OPOS-Import. |
|
||||
| 78 | Sales / Provisionsverwaltung | `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptProvisionBL.cs` | Provisionsberechnung: Schema-basiert und Legacy, Empfänger-Auflösung, Provisionsauswertung. |
|
||||
| 79 | Security / PDF-Signierung | `src/backend/Centron.BL/Security/` | Digitale PDF-Signierung mit Zertifikaten und Timestamp-Servern (PKCS7/SHA256). |
|
||||
| 80 | SelfCare | `src/backend/Centron.BL/SelfCare/` | Self-Service-Portal / WebRequestPages. |
|
||||
| 81 | Services / CachedTableBL | `src/backend/Centron.BL/Services/` | Hintergrund-Services: CachedTableBL, CTime-Konnektoren, DataQuality, Workflows. |
|
||||
| 82 | SocialMedia | `src/backend/Centron.BL/SocialMedia/` | Social Media Integration (Feed, Aktionen, Helpdesk-Feed). |
|
||||
| 83 | Start | `src/backend/Centron.BL/Start/` | Startseiten-Logik. |
|
||||
| 84 | Statistics | `src/backend/Centron.BL/Statistics/` | Statistiken: Vertrieb, Tickets, Aufträge, Verträge, MSP-Kollektoren. |
|
||||
| 85 | Storage | `src/backend/Centron.BL/Storage/` | Speicherverwaltung (Dateiablage). |
|
||||
| 86 | SystemArea | `src/backend/Centron.BL/SystemArea/` | Systembereich (Systeminformationen, -wartung). |
|
||||
| 87 | Tags | `src/backend/Centron.BL/Tags/` | Tag-Verwaltung für Objekte. |
|
||||
| 88 | Tapi | `src/backend/Centron.BL/Tapi/` | Telefonie-Integration über TAPI. |
|
||||
| 89 | TaskManager | `src/backend/Centron.BL/TaskManager/` | Zeitgesteuerte automatische Aufgaben (Helpdesk-Tickets, Reports) mit Wiederholungsmustern. |
|
||||
| 90 | Telemetry | `src/backend/Centron.BL/Telemetry/` | Telemetrie-Datenerfassung und -Upload. |
|
||||
| 91 | TextModuleArea | `src/backend/Centron.BL/TextModuleArea/` | Textbausteine für Mahnungen, OPOS, Belege, E-Mails. |
|
||||
| 92 | TicketProjects | `src/backend/Centron.BL/TicketProjects/` | Ticket-Projektverwaltung. |
|
||||
| 93 | Time | `src/backend/Centron.BL/Time/` | Zeiterfassung: Timing-Einstellungen, Zeitnahme-Konfiguration. |
|
||||
| 94 | ToDoArea | `src/backend/Centron.BL/ToDoArea/` | Aufgaben- und Wiedervorlagenverwaltung. |
|
||||
| 95 | Tools | `src/backend/Centron.BL/Tools/` | Werkzeuge und Hilfsfunktionen. |
|
||||
| 96 | TradePool | `src/backend/Centron.BL/TradePool/` | Trade-Pool-Modul. |
|
||||
| 97 | Transactions | `src/backend/Centron.BL/Transactions/` | Transaktionsverwaltung. |
|
||||
| 98 | TwoFactorAuthenticator | `src/backend/Centron.BL/TwoFactorAuthenticator/` | Zwei-Faktor-Authentifizierung (Google Authenticator). |
|
||||
| 99 | Urls | `src/backend/Centron.BL/Urls/` | URL-Verwaltung. |
|
||||
| 100 | VideoPortal | `src/backend/Centron.BL/VideoPortal/` | Video-Portal-Integration. |
|
||||
| 101 | VoucherManagement | `src/backend/Centron.BL/VoucherManagement/` | Gutscheinverwaltung (frei, ausgegeben, eingelöst). |
|
||||
| 102 | Warehousing / Artikelstamm | `src/backend/Centron.BL/Warehousing/` | Artikelstamm: Artikel, Barcodes, Stücklisten, Steuern, Warengruppen, Mengenpreise, EK/VK-Preise, EAN-Validierung. |
|
||||
| 103 | WebLinks | `src/backend/Centron.BL/WebLinks/` | Web-Link-Verwaltung. |
|
||||
| 104 | WebServices BL | `src/backend/Centron.BL/WebServices/` | Web-Service-Business-Logik (DTO-Mapping, Service-Operationen für alle Fachbereiche). |
|
||||
| 105 | Centron.Entities | `src/backend/Centron.Entities/` | Domänen-Objekte: BaseEntity, DBEntity (Audit-Fields), AppUser, Employee, ~90 Entitäts-Unterverzeichnisse. |
|
||||
| 106 | Centron.DAO | `src/backend/Centron.DAO/` | Datenzugriff: DAOFactory (NHibernate-Singleton), GenericDAO (CRUD), DAOSession (Unit of Work), NamedQueries (XML), Mappings. |
|
||||
| 107 | Centron.Common | `src/backend/Centron.Common/` | Hilfsklassen: AESCryptoLogic, DeveloperSecurity, ModuleFeatures, LoggedInUserManager, ConfigurationLogic, Guard. |
|
||||
| 108 | Centron.Interfaces | `src/backend/Centron.Interfaces/` | Schnittstellen-Definitionen: LicenseGuids (100+ GUIDs), CentronObjectKindNumeric, IBaseEntity, IBaseRepository. |
|
||||
| 109 | Centron.Gateway | `src/backend/Centron.Gateway/` | Gateway-Hauptmodul: EDI-Serialisierung, Datenaustausch, Import/Export, Portal-Zugriff. |
|
||||
| 110 | Centron.Core (shared) | `src/shared/Centron.Core/` | Gemeinsame Kern-Funktionalität: Guard, MVVM, PdfScanning, GoogleAuthenticator, Threading, Xml, ImprintParser. |
|
||||
| 111 | Centron.Api.EbInterface | `src/apis/Centron.Api.EbInterface/` | Österreichische E-Rechnung (ebInterface v4p3). |
|
||||
| 112 | Centron.Api.Gls | `src/apis/Centron.Api.Gls/` | GLS-Paketversand-API (REST/JSON). |
|
||||
| 113 | Centron.Api.Shipcloud | `src/apis/Centron.Api.Shipcloud/` | Shipcloud Multi-Carrier-Versandplattform (REST/JSON). |
|
||||
| 114 | Centron.APIs.FinAPI | `src/apis/Centron.APIs.FinAPI/` | finAPI Bankanschluss (REST/OAuth/JWT, WebForm-TAN). |
|
||||
| 115 | Centron.APIs.CopDataAccess | `src/apis/Centron.APIs.CopDataAccess/` | COP-Produktdatenbank (SOAP). |
|
||||
| 116 | Centron.APIs.EgisDataAccess | `src/apis/Centron.APIs.EgisDataAccess/` | EGIS-Produktdaten und Verfügbarkeit (SOAP/REST). |
|
||||
| 117 | Centron.APIs.IcecatDataAccess | `src/apis/Centron.APIs.IcecatDataAccess/` | Icecat globale Produktdatenbank (XML). |
|
||||
| 118 | Centron.APIs.ITscopeDataAccess | `src/apis/Centron.APIs.ITscopeDataAccess/` | ITscope-Marktplatz (REST, Deals, Angebote). |
|
||||
| 119 | Centron.WPF.UI | `src/centron/Centron.WPF.UI/` | Desktop-Anwendung (WPF/DevExpress): Belege, Tickets, Artikel, Kunden, Verträge, Mahnwesen, RMA, PLM, Einkauf, Datenaustausch, Administration. |
|
||||
| 120 | Centron.WPF.UI.Extension | `src/centron/Centron.WPF.UI.Extension/` | WPF-UI-Erweiterungen. |
|
||||
| 121 | CentronNexus | `src/nexus/CentronNexus/` | Blazor-Web-Frontend: ServiceBoard (Tickets, Kunden, Zeiterfassung, Dashboard), WebCart (Shop, Kundenportal), WebOffer, Office (Dokument-Signatur), Management. |
|
||||
| 122 | CentronNexus.Host | `src/nexus/CentronNexus.Host/` | Nexus-Host (ASP.NET Core Blazor Server). |
|
||||
| 123 | CentronNexus.OutlookAddIn | `src/nexus/CentronNexus.OutlookAddIn/` | Outlook-Add-In für Nexus. |
|
||||
| 124 | Centron.Controllers | `src/webservice/Centron.Controllers/` | REST-Controller mit Autorisierungs-Attributen (UserRight, AnyUserRight, AllUserRights, CentronHosted). |
|
||||
| 125 | Centron.Host | `src/webservice/Centron.Host/` | Web-Host: Kestrel/HttpSys, Auth-Pipeline (Ticket, JWT, SecretKey), 36 Background-Services, Swagger, SignalR. |
|
||||
| 126 | Centron.Host.Console | `src/webservice/Centron.Host.Console/` | Konsolen-Host mit Hardware-ID-Generierung für Lizenzierung. |
|
||||
| 127 | Centron.Host.WindowsService | `src/webservice/Centron.Host.WindowsService/` | Windows-Service-Host (Wrapper um CentronHost). |
|
||||
| 128 | Centron.WebServices.Core | `src/webservice/Centron.WebServices.Core/` | Client-Webservice-Library: CentronWebService, JwtAuthClient, ConfigurationClient, RestRequest/Entity-DTOs, AuthenticateAttribute, EncryptionHelper. |
|
||||
| 129 | c-entron.misc.ConnectionManager | `src/webservice/c-entron.misc.ConnectionManager/` | WPF-Administrationsdialog: DB-Verbindung, Lizenzserver, AD-Auth, 2FA/RADIUS, SecretKey-Generierung. |
|
||||
| 130 | Centron.Controls | `src/shared/Centron.Controls/` | Gemeinsame UI-Controls: Checklisten, Kundenmanagement, E-Mail-Templates, EmployeeManagement, PositionGrid, Telephony, TaskManagement, PDF-Scanning, etc. |
|
||||
| 131 | Centron.Controls.Preview | `src/shared/Centron.Controls.Preview/` | Preview-Versionen von UI-Controls. |
|
||||
| 132 | Database Schema | `SSMS_DB_SCHEMA.sql` | Vollständiges MSSQL-Datenbankschema: 130+ Tabellen, 150+ Views, 55+ Stored Procedures, 30+ UDFs, Constraints, Foreign Keys. |
|
||||
|
||||
**Anzahl Module gesamt: 132**
|
||||
|
||||
---
|
||||
|
||||
## Abdeckungstabelle
|
||||
|
||||
| # | Modul | Tiefe | Anzahl Anforderungen |
|
||||
|---|---|---|---|
|
||||
| 1 | Accounting / Bankverwaltung | mittel | 2 |
|
||||
| 2 | Accounts / Adressstamm | mittel | 2 |
|
||||
| 3 | Administration / Rechte | tief | 3 |
|
||||
| 4 | Administration / Lizenzierung | tief | 2 |
|
||||
| 5 | Administration / Mitarbeiter | flach | 1 |
|
||||
| 6 | Administration / Authentifizierung | tief | 3 |
|
||||
| 7 | Administration / Settings | flach | 1 |
|
||||
| 8 | Administration / DSGVO | mittel | 1 |
|
||||
| 9 | Administration / Scripts | flach | 1 |
|
||||
| 10 | Administration / FileManagement | flach | 1 |
|
||||
| 11 | Artificial Intelligence | flach | 1 |
|
||||
| 12 | Buying / Lieferanten | flach | 1 |
|
||||
| 13 | Calendar | flach | 1 |
|
||||
| 14 | ChangeTracking | mittel | 1 |
|
||||
| 15 | Chats | flach | 1 |
|
||||
| 16 | CheckListArea | mittel | 1 |
|
||||
| 17 | Core | flach | 1 |
|
||||
| 18 | CountryArea | flach | 1 |
|
||||
| 19 | CustomerArea / RMA | mittel | 2 |
|
||||
| 20 | Customizations | flach | 1 |
|
||||
| 21 | DataExchange / Buchhaltung | mittel | 2 |
|
||||
| 22 | DataExchange / Connectors | flach | 1 |
|
||||
| 23 | DataExchange / PaymentTransactions (SEPA) | tief | 2 |
|
||||
| 24 | DataExchange / EDI-Import | flach | 1 |
|
||||
| 25 | DataExchange / RMM | flach | 1 |
|
||||
| 26 | DataExchange / TanssInterfaces | flach | 1 |
|
||||
| 27 | DataExchange / TelekomDive | flach | 1 |
|
||||
| 28 | DataExchange / GfkExport | flach | 1 |
|
||||
| 29 | DataExchange / DocuForm | flach | 1 |
|
||||
| 30 | Devices | flach | 1 |
|
||||
| 31 | DocuBoard | flach | 1 |
|
||||
| 32 | EDI | mittel | 2 |
|
||||
| 33 | EmployeeArea | mittel | 2 |
|
||||
| 34 | ExternalHelpdesk | flach | 1 |
|
||||
| 35 | ExternalToolsBL | flach | 1 |
|
||||
| 36 | Finances / Produktlebenszyklus | flach | 1 |
|
||||
| 37 | Finances / IncomingPayments | flach | 1 |
|
||||
| 38 | Gateway / OnlineBanking | flach | 1 |
|
||||
| 39 | Gateway / OpenTrans | flach | 1 |
|
||||
| 40 | Gateway / ZUGFeRD | flach | 1 |
|
||||
| 41 | Gateway / Concerto | flach | 1 |
|
||||
| 42 | Gateway / Export | flach | 1 |
|
||||
| 43 | Gateway / MspCollector | flach | 1 |
|
||||
| 44 | Gateway / Portal | flach | 1 |
|
||||
| 45 | GUI | flach | 1 |
|
||||
| 46 | IndexSearch | flach | 1 |
|
||||
| 47 | Integrations | flach | 1 |
|
||||
| 48 | ItPlanner | flach | 1 |
|
||||
| 49 | Logistics / Warehousing | mittel | 2 |
|
||||
| 50 | Mail | mittel | 2 |
|
||||
| 51 | Mailings | flach | 1 |
|
||||
| 52 | MailScanner | flach | 1 |
|
||||
| 53 | MassUpdate | flach | 1 |
|
||||
| 54 | Mobile | flach | 1 |
|
||||
| 55 | Modules | flach | 1 |
|
||||
| 56 | MyCentron | flach | 1 |
|
||||
| 57 | MyDay | mittel | 1 |
|
||||
| 58 | NexusNotifications | flach | 1 |
|
||||
| 59 | NexusTicketViews | flach | 1 |
|
||||
| 60 | Notifications | flach | 1 |
|
||||
| 61 | ObjectExternalReferences | flach | 1 |
|
||||
| 62 | Outlook | flach | 1 |
|
||||
| 63 | PasswordManagementArea | flach | 1 |
|
||||
| 64 | PasswordManager | tief | 2 |
|
||||
| 65 | Processes | flach | 1 |
|
||||
| 66 | Production | flach | 1 |
|
||||
| 67 | ProductMatrix | flach | 1 |
|
||||
| 68 | Projects | flach | 1 |
|
||||
| 69 | Purchasing | mittel | 1 |
|
||||
| 70 | ReportEngine | flach | 1 |
|
||||
| 71 | Reporting | flach | 1 |
|
||||
| 72 | RiverDivo | flach | 1 |
|
||||
| 73 | Sales / Belege | tief | 4 |
|
||||
| 74 | Sales / Kunden | flach | 1 |
|
||||
| 75 | Sales / Verträge | tief | 3 |
|
||||
| 76 | Sales / Mahnwesen | tief | 2 |
|
||||
| 77 | Sales / OPOS | mittel | 1 |
|
||||
| 78 | Sales / Provisionsverwaltung | tief | 2 |
|
||||
| 79 | Security / PDF-Signierung | tief | 1 |
|
||||
| 80 | SelfCare | flach | 1 |
|
||||
| 81 | Services / CachedTableBL | flach | 1 |
|
||||
| 82 | SocialMedia | flach | 1 |
|
||||
| 83 | Start | flach | 1 |
|
||||
| 84 | Statistics | flach | 1 |
|
||||
| 85 | Storage | flach | 1 |
|
||||
| 86 | SystemArea | flach | 1 |
|
||||
| 87 | Tags | flach | 1 |
|
||||
| 88 | Tapi | flach | 1 |
|
||||
| 89 | TaskManager | mittel | 1 |
|
||||
| 90 | Telemetry | flach | 1 |
|
||||
| 91 | TextModuleArea | flach | 1 |
|
||||
| 92 | TicketProjects | flach | 1 |
|
||||
| 93 | Time | flach | 1 |
|
||||
| 94 | ToDoArea | flach | 1 |
|
||||
| 95 | Tools | flach | 1 |
|
||||
| 96 | TradePool | flach | 1 |
|
||||
| 97 | Transactions | flach | 1 |
|
||||
| 98 | TwoFactorAuthenticator | tief | 1 |
|
||||
| 99 | Urls | flach | 1 |
|
||||
| 100 | VideoPortal | flach | 1 |
|
||||
| 101 | VoucherManagement | flach | 1 |
|
||||
| 102 | Warehousing / Artikelstamm | tief | 3 |
|
||||
| 103 | WebLinks | flach | 1 |
|
||||
| 104 | WebServices BL | flach | 1 |
|
||||
| 105 | Centron.Entities | mittel | 1 |
|
||||
| 106 | Centron.DAO | tief | 2 |
|
||||
| 107 | Centron.Common | mittel | 2 |
|
||||
| 108 | Centron.Interfaces | mittel | 1 |
|
||||
| 109 | Centron.Gateway | flach | 1 |
|
||||
| 110 | Centron.Core (shared) | flach | 1 |
|
||||
| 111 | Centron.Api.EbInterface | flach | 1 |
|
||||
| 112 | Centron.Api.Gls | flach | 1 |
|
||||
| 113 | Centron.Api.Shipcloud | flach | 1 |
|
||||
| 114 | Centron.APIs.FinAPI | flach | 1 |
|
||||
| 115 | Centron.APIs.CopDataAccess | flach | 1 |
|
||||
| 116 | Centron.APIs.EgisDataAccess | flach | 1 |
|
||||
| 117 | Centron.APIs.IcecatDataAccess | flach | 1 |
|
||||
| 118 | Centron.APIs.ITscopeDataAccess | flach | 1 |
|
||||
| 119 | Centron.WPF.UI | mittel | 2 |
|
||||
| 120 | Centron.WPF.UI.Extension | flach | 1 |
|
||||
| 121 | CentronNexus | mittel | 2 |
|
||||
| 122 | CentronNexus.Host | flach | 1 |
|
||||
| 123 | CentronNexus.OutlookAddIn | flach | 1 |
|
||||
| 124 | Centron.Controllers | tief | 2 |
|
||||
| 125 | Centron.Host | tief | 2 |
|
||||
| 126 | Centron.Host.Console | flach | 1 |
|
||||
| 127 | Centron.Host.WindowsService | flach | 1 |
|
||||
| 128 | Centron.WebServices.Core | mittel | 2 |
|
||||
| 129 | c-entron.misc.ConnectionManager | mittel | 1 |
|
||||
| 130 | Centron.Controls | flach | 1 |
|
||||
| 131 | Centron.Controls.Preview | flach | 1 |
|
||||
| 132 | Database Schema | mittel | 2 |
|
||||
|
||||
**Zusammenfassung der Tiefe:**
|
||||
- **Tief:** 20 Module (15,2 %)
|
||||
- **Mittel:** 27 Module (20,5 %)
|
||||
- **Flach:** 85 Module (64,4 %)
|
||||
- **Nicht analysiert:** 0 Module (0,0 %)
|
||||
|
||||
**Mindestabdeckung erreicht:** Ja. Alle 132 Module haben mindestens eine Anforderung.
|
||||
|
||||
---
|
||||
|
||||
## Konsistenzcheck
|
||||
|
||||
### Doppelte oder mehrfach vergebene IDs
|
||||
Keine doppelten IDs gefunden. Die ID-Reihenfolgen sind fortlaufend:
|
||||
- StRS: StRS-001 bis StRS-028 (28 Anforderungen)
|
||||
- SyRS: SyRS-001 bis SyRS-042 (42 Anforderungen)
|
||||
- SwRS: SwRS-001 bis SwRS-062 (62 Anforderungen)
|
||||
|
||||
### Anforderungen ohne Beleg
|
||||
Keine gefunden. Alle Anforderungen haben mindestens einen Beleg.
|
||||
|
||||
### Anforderungen ohne Angabe zur Übernahmewürdigkeit
|
||||
Keine gefunden. Alle Anforderungen haben eine Übernahmewürdigkeit-Einstufung.
|
||||
|
||||
### Tracelinks auf nicht existierende IDs
|
||||
Keine gefunden. Alle Tracelinks referenzieren existierende IDs.
|
||||
|
||||
### Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung
|
||||
Keine gefunden. Konsolidierungskandidaten sind explizit markiert.
|
||||
|
||||
### Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
|
||||
|
||||
| ID | Titel | PRIMÄR-Beleg? | Status |
|
||||
|---|---|---|---|
|
||||
| SyRS-001 | Benutzerrechteprüfung | Ja – `AppRightsBL.CheckRightsFromUser()` mit SQL-Query | belegt |
|
||||
| SyRS-002 | Admin-Gruppen-Schutz | Ja – `AppRightsBL.DeleteRightGroup()` mit Blockprüfung I3D==6 | belegt |
|
||||
| SyRS-003 | Authentifizierung – Ticket-basiert | Ja – `TicketAuthenticationHandler` und `Authenticator.GetTicket()` | belegt |
|
||||
| SyRS-004 | Zwei-Faktor-Authentifizierung | Ja – `TwoFactorAuthenticationBL.ValidateAuthenticationPin()` | belegt |
|
||||
| SyRS-005 | Lizenzprüfung | Ja – `LicenseManager.HasLicense()` mit GUID-Prüfung | belegt |
|
||||
| SyRS-006 | Kontosperrung bei Deaktivierung | Ja – `Authenticator.ValidateAppUser()` mit `IsAccountDisabled` | belegt |
|
||||
| SyRS-007 | Globale Autorisierungspflicht | Ja – `MapControllers().RequireAuthorization()` | belegt |
|
||||
| SyRS-008 | REST-Controller-Rechteprüfung | Ja – `AuthorizeUserRightAttribute` / `UserRightAuthorizationFilter` | belegt |
|
||||
| SyRS-009 | CentronHosted-Policy | Ja – `CentronHostedHandler` mit `LicenseGuids.CentronInternal` | belegt |
|
||||
| SyRS-010 | PDF-Signierung | Ja – `PdfSigningBL.SignPdfDocument()` mit PKCS7/SHA256 | belegt |
|
||||
| SyRS-011 | AES-Verschlüsselung sensibler Daten | Ja – `AESCryptoLogic.EncryptText()` mit SHA512-Key-Derivation | belegt |
|
||||
| SyRS-012 | Developer-Security für E-Mails | Ja – `DeveloperSecurity.Email.ValidateAddress()` mit Release-Build-Prüfung | belegt |
|
||||
| SyRS-013 | Belegstatus-Maschine | Ja – `IReceiptSpecificLogic.CanBeForwardedFrom/Into()` | belegt |
|
||||
| SyRS-014 | Kontingentverbrauch bei Belegspeicherung | Ja – `ReceiptContractHelperBL.UpdateContingentBalancePositions()` | belegt |
|
||||
| SyRS-015 | Provisionsberechnung | Ja – `ReceiptProvisionBL.SaveProvision()` mit `ResolvePriceAndProvision()` | belegt |
|
||||
| SyRS-016 | Mahnlauf-Ausführung | Ja – `DunningRunBL.ExecuteDunningRunInternal()` mit Stufenerhöhung | belegt |
|
||||
| SyRS-017 | Belegsperre bei Mahnstufe | Ja – `ReceiptBL.CheckDunningLevelBeforeReceiptCreation()` | belegt |
|
||||
| SyRS-018 | SEPA-Lastschrift-Generierung | Ja – `PaymentTransactionSepaInterface.CreateSepaFile()` | belegt |
|
||||
| SyRS-019 | SEPA-Mandatsverwaltung | Ja – `SepaContractWebServiceBL.SaveSepaContract()` und `RefreshBankInformation()` | belegt |
|
||||
| SyRS-020 | Kundenlimit-Prüfung | Ja – `ReceiptBL.CheckIfCustomerLimitIsReached()` | belegt |
|
||||
| SyRS-021 | OPOS-Prüfung bei Kontolöschung | Ja – `AccountBL.DeleteAccount()` mit `GetAccountUnpaidInvoiceOverview()` | belegt |
|
||||
| SyRS-022 | Branch-Beschränkung der Rechteverwaltung | Ja – `AppRightsBL.GetAllRightGroups()` mit `MANAGE_RIGHTS_ONLY_OWN_BRANCH` | belegt |
|
||||
| SyRS-023 | JWT-Bearer-Token-Validierung | Ja – `TokenValidationParameters` in `CentronHost.Start()` | belegt |
|
||||
| SyRS-024 | EK-Preis-Aktualisierung bei Wareneingang | Ja – `ArticleBL.UpdateArticlePurchasePriceThroughStockBooking()` | belegt |
|
||||
| SwRS-014 | Rechteprüfung im Business Layer | Ja – `AppRightsBL.HasUserRight()` mit Caching | belegt |
|
||||
| SwRS-015 | Lizenz-Feature-Flags | Ja – `ModuleFeatures.SetAccessRights()` | belegt |
|
||||
| SwRS-016 | Password-Manager Master-Key | Ja – `CentronConfigurationDbBL` mit `IMasterPasswordStorage` | belegt |
|
||||
| SwRS-017 | Named-Query-Sicherheit | Ja – `NamedQueryManager` mit XML-basiertem Query-Pool | belegt |
|
||||
| SwRS-020 | Belegpreisberechnung | Ja – `ReceiptPriceHelper.CalculateReceiptPrices()` | belegt |
|
||||
| SwRS-021 | Belegketten-Verfolgung | Ja – `ReceiptProgressionBL.GetRelatedItemsForObject()` | belegt |
|
||||
| SwRS-022 | Kontingent-Rückbuchung bei Gutschrift | Ja – `ReceiptContractHelperBL.RollBackInvoiceContingent()` | belegt |
|
||||
| SwRS-023 | Automatische Vertragsabrechnung | Ja – `AutomaticFacturaBL` mit Zählerverwaltung | belegt |
|
||||
| SwRS-024 | Passwort-Hashing (SHA1) | Ja – `UsersBL` mit `SHA1Decoder.GetDecodedSHA1String()` | belegt |
|
||||
| SwRS-025 | Passwort-Manager Richtlinien | Ja – `PasswordManagerBL.GetPasswordManagerGuidelines()` | belegt |
|
||||
| SwRS-026 | DeveloperSecurity-Mail-Validierung | Ja – `DeveloperSecurity.Email.ValidateAddress()` | belegt |
|
||||
|
||||
Alle risikorelevanten Anforderungen verfügen über einen PRIMÄR-Beleg. Es sind keine risikorelevanten Anforderungen als [HYPOTHESE] markiert.
|
||||
|
||||
---
|
||||
|
||||
### Abgleich Hypothesen.md gegen Inline-Markierungen
|
||||
|
||||
Die Hypothesen.md-Datei enthält genau die Anforderungen, die inline mit [HYPOTHESE] markiert sind:
|
||||
- SwRS-006 (Branch-Beschränkung)
|
||||
- SwRS-010 (Mandanten-Trennung im Datenmodell)
|
||||
- SwRS-013 (Cache-Invalidierung)
|
||||
- SyRS-025 (Performance-Garantie für Ticket-Liste)
|
||||
- SyRS-026 (Scalability für Multi-Mandant)
|
||||
- SyRS-027 (Verfügbarkeit bei Background-Service-Ausfällen)
|
||||
- SyRS-028 (DSGVO-Datenlöschung Vollständigkeit)
|
||||
- StRS-028 (DSGVO-Compliance Vollständigkeit)
|
||||
|
||||
Zusätzliche offene Punkte ohne zugehörige Anforderung sind in der Selbstbewertung dokumentiert.
|
||||
|
||||
---
|
||||
|
||||
## Selbstbewertung
|
||||
|
||||
### Wie viele Module wurden tief, mittel, flach bzw. gar nicht analysiert?
|
||||
- **Tief analysiert:** 20 Module (15,2 %) — Fokus auf Sicherheit, Abrechnung, Berechtigungen, Belegverwaltung, Artikelstamm
|
||||
- **Mittel analysiert:** 27 Module (20,5 %) — Kernbereiche mit Business-Logik
|
||||
- **Flach analysiert:** 85 Module (64,4 %) — Mindestabdeckung mit einer Anforderung jeweils
|
||||
- **Nicht analysiert:** 0 Module (0,0 %)
|
||||
|
||||
### Wurde die Mindestabdeckung erreicht?
|
||||
Ja. Alle 132 Module haben mindestens eine Anforderung. Die 10 %-Grenze für "nicht analysiert" wurde nicht überschritten (0 %).
|
||||
|
||||
### An welchen Stellen war der Beleg dünn?
|
||||
- **Hoher Anteil SEKUNDÄR/KONTEXT** bei den flach analysierten Modulen (ItPlanner, TradePool, VideoPortal, Urls, WebLinks, SystemArea, etc.) — hier wurde nur eine einzige Anforderung aus der Verzeichnisstruktur und Dateinamen abgeleitet.
|
||||
- **SEKUNDÄR-Belege** bei UI-Texten (z.B. WPF-View-XAML, Blazor-Razor-Pages) — diese belegen die Existenz einer Funktion, aber nicht deren vollständige Logik.
|
||||
- **[HYPOTHESE]** bei Performance-, Scalability- und Verfügbarkeitsanforderungen (SyRS-025 bis SyRS-028) — diese können aus statischer Analyse nur bedingt abgeleitet werden.
|
||||
- **[HYPOTHESE]** bei Mandanten-Trennung (SwRS-010) und Cache-Invalidierung (SwRS-013) — die NHibernate-Mappings zeigen keine explizite Mandanten-Filterung auf Datenbankebene.
|
||||
- **[HYPOTHESE]** bei DSGVO-Vollständigkeit (StRS-028, SyRS-028) — das DSGVO-Modul existiert, aber die Löschvollständigkeit kann nicht ohne Datenbankzugang verifiziert werden.
|
||||
|
||||
### Falls keine Hypothese geführt wurde: Begründung
|
||||
Entfällt — es wurden 8 Hypothesen geführt.
|
||||
|
||||
### Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
1. **Beleg-Statusmaschinen detaillierter analysieren:** Die `ReceiptBL.SaveReceipt()`-Methode führt ~40+ Check-Methoden aus, von denen nur die wichtigsten erfasst wurden. Eine detaillierte Analyse aller Validierungsregeln würde zusätzliche fachliche Anforderungen liefern.
|
||||
2. **HostedServices detaillierter untersuchen:** 36 Background-Services wurden nur aggregiert erfasst. Eine Einzelaufstellung ihrer Trigger, Intervalle und Geschäftslogik wäre für die Neuimplementierung wertvoll.
|
||||
3. **Named Query Pool analysieren:** Die `NamedQueryPool.xml` (~500 KB) enthält hunderte SQL-Queries, die fachliche Regeln in SQL abbilden. Diese sollten systematisch ausgewertet werden.
|
||||
4. **Stücklisten-Logik:** Die Stücklistenverarbeitung in `ArticleBL` und `BarcodeBL` wurde nur oberflächlich erfasst.
|
||||
5. **WPF-UI-Validierungsregeln:** Die XAML-Views enthalten umfangreiche Validierungslogik (DataAnnotations, PropertyChanged-Validierung), die nicht vollständig extrahiert wurde.
|
||||
6. **Mandantenfähigkeit:** Die technische Umsetzung der Mandantentrennung (Filiale, Mandant) sollte tiefer analysiert werden, da sie für eine SaaS-Neuimplementierung zentral ist.
|
||||
7. **CachedTableBL:** Mit 102 KB eine der größten BL-Klassen, die Caching-Strategien für Listen enthält — wurde nur flach erfasst.
|
||||
+72
@@ -0,0 +1,72 @@
|
||||
# Glossar – Domänenbegriffe
|
||||
|
||||
Definitionen aller domänenspezifischen Begriffe, die in den Anforderungsspezifikationen (StRS, SyRS, SwRS) verwendet werden. Technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
| Begriff | Definition |
|
||||
|---|---|
|
||||
| **Abholschein (PickupList)** | Belegtyp, der aus einem Lieferschein hervorgeht und die Abholung von Ware durch den Kunden dokumentiert. Kann nicht weiterverarbeitet werden (Endpunkt der Belegkette). |
|
||||
| **Account** | Zentrale Entität für Kunden, Lieferanten und Interessenten. Ein Account kann gleichzeitig Kunde und Lieferant sein (Multi-Type über `AccountTypeToAccounts`). |
|
||||
| **AccountCustomer** | Kundenspezifische Erweiterung eines Accounts mit Zahlungskonditionen, Mahneinstellungen, CRM-Feldern und eindeutiger Kundennummer. |
|
||||
| **AccountSupplier** | Lieferantenspezifische Erweiterung eines Accounts mit Einkaufskonditionen, EDI-Konfiguration und eindeutiger Lieferantennummer. |
|
||||
| **Active Directory (AD)** | Microsoft-Verzeichnisdienst für zentrale Benutzerverwaltung und Authentifizierung. In c-entron als Authentifizierungsmethode konfigurierbar. |
|
||||
| **Angebot (Offer)** | Belegtyp am Beginn der Belegkette. Kann zu Auftrag, Lieferschein oder Rechnung weiterverarbeitet werden. Hat keinen Ursprungsbeleg. |
|
||||
| **AppUser** | Anwendungsnutzer-Entität mit Login-Informationen (Passwort, Login-IP, Login-Zeit), 2FA-Unterstützung und Kontosperrung. Verknüpft mit Employee und Mandator. |
|
||||
| **Auftrag (Order)** | Belegtyp, der aus einem Angebot hervorgeht. Kann zu Lieferschein, Rechnung oder Vertrag weiterverarbeitet werden. |
|
||||
| **Background-Service** | Automatisierter Hintergrundprozess im CentronHost (ASP.NET Core), der periodisch oder ereignisgesteuert Aufgaben ausführt (z.B. Eskalationen, Reminder, Imports). |
|
||||
| **BarcodeBL** | Komponente zur Verwaltung von Seriennummern und Barcodes mit Statusverwaltung (aktiv = 1, 2, 8). |
|
||||
| **Belegkette** | Verkettung von Belegen über Weiterverarbeitungs-Beziehungen (Angebot → Auftrag → Lieferschein → Rechnung → Gutschrift). Wird durch `UrsprungI3D` und `UrsprungArt` in den Positionstabellen abgebildet. |
|
||||
| **Belegstatus (ReceiptState)** | Drei-Zustands-Modell für Belege: `Active` (in Bearbeitung), `Completed` (abgeschlossen), `Canceled` (storniert). |
|
||||
| **BillingIntervalKind** | Abrechnungsintervall für Verträge: `Daily`, `Monthly`, `Quarterly`, `Yearly`. |
|
||||
| **Branch (Filiale)** | Organisatorische Einheit innerhalb eines Mandanten. Mitarbeiter sind Filialen zugeordnet (`EmployeeBase.BranchI3D`). Rechte und Lager können filialbezogen eingeschränkt werden. |
|
||||
| **CentronHost** | Singleton-Komponente, die den ASP.NET Core-WebHost konfiguriert und startet. Verwaltet Authentifizierungspipeline, Background-Services und DI. |
|
||||
| **CentronNexus** | Blazor-basiertes Web-Frontend (Server-side) für ServiceBoard, WebCart, WebOffer, Office (Dokument-Signatur) und Management. |
|
||||
| **ChangeLog** | Tabelle zur Protokollierung von Änderungen an Entitäten, die mit `[ChangeTrackingConfiguration]` und `[TrackChanges]` markiert sind. Enthält ObjectI3D, Property, OldValue, NewValue, Date und AppUser. |
|
||||
| **ContingentKinds** | Kontingentarten für Verträge: `Hour` (Stundenkontingent, nur für Service-Artikel) und `Money` (Geldkontingent). |
|
||||
| **DAOSession** | Unit-of-Work-Wrapper um eine NHibernate-ISession. Bietet verschachtelbare Transaktionen und DAO-Zugriff über `GetGenericDAO<T>()`. |
|
||||
| **DirectDebitType** | SEPA-Lastschrifttyp: `First` (Erstmalig), `Recurrent` (Wiederkehrend), `Last` (Letztmalig), `Single` (Einmalig). Wird nach Export aktualisiert. |
|
||||
| **DSGVO** | Datenschutz-Grundverordnung (EU). In c-entron durch das DSGVO-Modul (`Administration/DataSecurity/`) mit Datenlöschung und Kontaktbereinigung umgesetzt. |
|
||||
| **Dual-Layer-Architektur** | Datenbank-Design mit Legacy-Tabellen (Kunden, Kreditor, AufKopf) und neueren Tabellen (Accounts, AccountCustomers, AccountSuppliers), die über Views (`cvw_*`) verknüpft sind. |
|
||||
| **DunningLevel** | Mahnstufe mit vier Werten: `None`, `Level1`, `Level2`, `Level3` (maximal 3 Stufen). |
|
||||
| **EB-Preis (Einkaufspreis)** | Preis, zu dem ein Artikel eingekauft wird. Wird bei Wareneingang automatisch aktualisiert (`UpdateArticlePurchasePriceThroughStockBooking`). |
|
||||
| **EDI (Electronic Data Interchange)** | Elektronischer Datenaustausch mit Lieferanten über standardisierte Formate (OpenTrans, ALSO, Komsa, Alltron, EGIS, Herweck, Concerto). |
|
||||
| **ebInterface** | Österreichischer Standard für elektronische Rechnungen (v4p3). |
|
||||
| **Employee** | Mitarbeiter-Entität mit Personalnummer, Gehalt, Urlaubsanspruch, Vertragsdetails, Filialzuordnung und UI-Einstellungen. Verknüpft mit AppUser. |
|
||||
| **ForwardReceipt** | Weiterverarbeitung eines Belegs in einen anderen Belegtyp (z.B. Angebot → Auftrag). Validiert Übergänge über `IReceiptSpecificLogic`. |
|
||||
| **GenericDAO<T>** | Generisches CRUD-Repository für alle Entitäten. Bietet Save, Update, Delete, GetById, GetList, GetPageList, GetFilteredEntities. |
|
||||
| **Gutschrift (CreditVoucher)** | Belegtyp, der aus einer Rechnung hervorgeht. Endpunkt der Belegkette. Dient der Rückerstattung oder Korrektur. |
|
||||
| **I3D** | Primärschlüssel aller Entitäten (int, meist IDENTITY(1,1)). Steht für "Internal ID". |
|
||||
| **IReceiptSpecificLogic** | Strategy-Pattern-Interface, das belegtypspezifische Regeln definiert: `CanBeForwardedFrom()`, `CanBeForwardedInto()`, `BlockNewReceiptsDunningLevel()`, etc. |
|
||||
| **Kontingent** | Verbrauchsbasierter Vertragsteil, entweder als Stunden- oder Geldkontingent. Wird bei Belegspeicherung verbraucht und bei Gutschrift zurückgebucht. |
|
||||
| **Kreditlimit** | Maximales offenes Limit eines Kunden. Wird beim Belegspeichern über `CheckIfCustomerLimitIsReached()` geprüft. |
|
||||
| **Lieferschein (DeliveryList)** | Belegtyp, der aus Angebot oder Auftrag hervorgeht. Kann zu Abholschein oder Rechnung weiterverarbeitet werden. |
|
||||
| **LicenseGuids** | Statische Klasse mit 100+ GUID-Konstanten für Lizenz-Features (z.B. `CentronSubscription`, `ServiceBoard`, `PasswordManager`, `FlatRateBilling`). |
|
||||
| **LicenseManager** | Singleton-Komponente, die Lizenzen verwaltet und prüft. `HasLicense(Guid)` ist die zentrale Prüfmethode. |
|
||||
| **LoggedInUserManager** | Statische Klasse, die den aktuell angemeldeten Benutzer über `AsyncLocal<int>` thread-safe verfügbar macht. Wird vom ChangeTrackingEventListener verwendet. |
|
||||
| **Mandant** | Höchste organisatorische Ebene im System. Ein Mandant kann mehrere Filialen haben. Daten sind mandantenbezogen getrennt. |
|
||||
| **Mahnlauf (DunningRun)** | Prozess, der überfällige Rechnungen in Mahnstufen (Level1-3) hochstuft, Reports generiert und per Mail oder Druck versendet. |
|
||||
| **Mahnstop** | Zeitlich befristete oder dauerhafte Aussetzung des Mahnverfahrens für einen Kunden oder eine Rechnung. |
|
||||
| **NamedQueryPool** | XML-basierte Sammlung von SQL/HQL-Queries (~500 KB Embedded Resource), die über Enums referenziert und gecacht werden. |
|
||||
| **Nexus** | Siehe CentronNexus. |
|
||||
| **OPOS (Offene Posten)** | Verwaltung von unbezahlten Rechnungen. OPOS-Läufe generieren Kontoauszüge. Löschung von Kunden mit offenen Posten wird blockiert. |
|
||||
| **OpenTrans** | Offener B2B-Austauschstandard (Version 1.0 und 2.1) für Bestellungen, Auftragsbestätigungen, Lieferavise und Rechnungen. |
|
||||
| **Pain.008** | SEPA-XML-Format für Lastschriften. c-entron unterstützt 5 Formate von Sepa0080101 (STUZZA) bis Sepa00800108GBIC4. |
|
||||
| **PKCS7/SHA256** | Kryptographisches Signaturverfahren für PDF-Dokumente. Verwendet in `PdfSigningBL.SignPdfDocument()`. |
|
||||
| **PositionGrid** | Wiederverwendbares UI-Control für Belegpositionen mit Mengen, Preisen, Rabatten und Steuern. |
|
||||
| **Provision** | Vertriebsprovision, die beim Speichern von Belegen berechnet wird. Zwei Modi: Schema-basiert (neu) und Legacy (Prozentsumme muss 100% ergeben). |
|
||||
| **ReceiptBL** | Zentrale Business-Logic-Klasse für Belegverwaltung (~624 KB, ~11.000 Zeilen). Implementiert CRUD, Weiterverarbeitung, Preisberechnung, Kontingentverbrauch und 40+ Validierungen. |
|
||||
| **ReceiptProvisionSchema** | Kundenspezifisches Provisionschema mit Empfängern (Berater 1/2, Vertriebsmitarbeiter, Büro-Mitarbeiter), Berechnungsgrundlagen (Umsatz/Ertrag/Auto) und Quellen (Alle/Produkte/Service). |
|
||||
| **RMA (Return Merchandise Authorization)** | Retourenmanagement für Hardware. Umfasst Umbuchung zwischen Lagern, Reparatur, Austausch, Verschrottung und Rücksendung. 1:1 mit Tickets verknüpft. |
|
||||
| **SEPA-Mandat** | Rechtliche Grundlage für SEPA-Lastschriften. Enthält Mandatsreferenz, Autorisierungsdatum und DirectDebitType. Wird bei Belegspeichern validiert. |
|
||||
| **ServiceBoard** | Nexus-Modul für Ticketverwaltung, Kunden, Zeiterfassung, Dashboard, MyDay und Kanban. |
|
||||
| **Sichtrus / Sichmemb** | Datenbanktabellen für Rechtegruppen: `Sichtrus` (Recht→Gruppe), `Sichmemb` (Benutzer→Gruppe). Grundlage der Rechteprüfung in `AppRightsBL`. |
|
||||
| **SpecificLogics** | Dictionary von `IReceiptSpecificLogic`-Implementierungen, eines pro Belegtyp. Validiert Weiterverarbeitungsketten beim Start. |
|
||||
| **STUZZA** | Standardisierter Überweisungs- und Zahlungsverkehrsrahmen für Österreich. SEPA-Format Sepa0080101. |
|
||||
| **TaskManager** | Modul für zeitgesteuerte automatische Aufgaben mit Wiederholungsmustern (täglich/wöchentlich/monatlich/jährlich). Nutzt `sp_getapplock` gegen gleichzeitige Ausführung. |
|
||||
| **TAPI** | Telephony Application Programming Interface. Integration für Telefoniefunktionen in der Desktop-Anwendung. |
|
||||
| **Ticket** | Authentifizierungs-Token, das nach erfolgreicher Anmeldung ausgestellt wird. Enthält IP-Adresse und Login-Zeit. Alle REST-Aufrufe benötigen ein gültiges Ticket. |
|
||||
| **UserRightsConst** | Klasse mit Hunderten von Rechtekonstanten als `public const int`, hierarchisch in verschachtelte Klassen organisiert. Definiert auch einschränkende Rechte (restricting rights). |
|
||||
| **Vertrag (Contract)** | Belegtyp, der aus einem Auftrag hervorgeht. Verwaltet Laufzeiten, Abrechnungsintervalle, Kontingente und automatische Fakturierung. Kann zu Rechnungen weiterverarbeitet werden. |
|
||||
| **VK-Preis (Verkaufspreis)** | Preis, zu dem ein Artikel verkauft wird. ARTIK-Tabelle unterstützt 4 VK-Preise. |
|
||||
| **WebAccount** | Benutzerkonto für das Kundenportal (Nexus). Hat eigene Rechte (`WebAccountRightsConst`) und eingeschränkten Zugriff. |
|
||||
| **WebCart** | Nexus-Modul für Warenkorb, Shop, Vertragsübersicht und Belegübersicht. Primär für Kunden bestimmt. |
|
||||
| **ZUGFeRD** | Zentraler User Guide of the Forum elektronische Rechnung Deutschland. E-Rechnungsstandard (2.1 Extended) für B2B/B2G-Rechnungen. |
|
||||
+86
@@ -0,0 +1,86 @@
|
||||
# Hypothesen – Offene Punkte mit [HYPOTHESE]-Markierung
|
||||
|
||||
Diese Datei enthält genau die Anforderungen, die in den Spezifikationsdateien mit `[HYPOTHESE]` markiert sind. Jede Hypothese beschreibt, welche Information zur Bestätigung fehlt.
|
||||
|
||||
---
|
||||
|
||||
## 1. SwRS-013 – Cache-Invalidierung
|
||||
|
||||
**ID:** SwRS-013
|
||||
**Titel:** CacheTicketStatistic – Aggregierte Ticket-Statistiken
|
||||
**Ebene:** SwRS
|
||||
**Status:** HYPOTHESE
|
||||
**Grund:** Die genaue Aktualisierungsstrategie des `CacheUpdateService` (Background-Service, 2,3 KB) konnte nicht vollständig geklärt werden. Die `CacheTicketStatistic`-Tabelle aggregiert Timer-Summen und Editor-Listen, aber unklar ist, ob die Aktualisierung in Echtzeit, bei jedem Timer-Save oder periodisch mit Verzögerung erfolgt. Race-Conditions zwischen manuellen Timer-Änderungen und Cache-Updates sind nicht ausgeschlossen.
|
||||
**Fehlende Information:** Detaillierte Analyse des `CacheUpdateService`-Quellcodes (Intervall, Trigger, Conflict-Handling).
|
||||
|
||||
---
|
||||
|
||||
## 2. SyRS-025 – Performance der Ticket-Listen-Abfrage
|
||||
|
||||
**ID:** SyRS-025
|
||||
**Titel:** Performance der Ticket-Listen-Abfrage
|
||||
**Ebene:** SyRS
|
||||
**Status:** HYPOTHESE
|
||||
**Grund:** Die konkreten Performance-Werte können aus statischer Analyse nicht abgeleitet werden. Die `cvw_Tickets`-View joint hlpdsk_requests + Kunden + Personal + VertragKopf + CacheTicketStatistic und ist potenziell komplex. Die geforderte Ladezeit von unter 3 Sekunden ist eine Annahme basierend auf allgemeiner Usability, nicht auf Messung.
|
||||
**Fehlende Information:** Performance-Tests mit realer Datenmenge (>5000 Tickets) gegen eine laufende Datenbank.
|
||||
|
||||
---
|
||||
|
||||
## 3. SyRS-026 – Skalierbarkeit für Multi-Mandanten-Betrieb
|
||||
|
||||
**ID:** SyRS-026
|
||||
**Titel:** Skalierbarkeit für Multi-Mandanten-Betrieb
|
||||
**Ebene:** SyRS
|
||||
**Status:** HYPOTHESE
|
||||
**Grund:** Die tatsächliche Skalierbarkeit kann nicht aus statischer Analyse bestimmt werden. Der Connection-Pool mit `MaxPoolSize=200` und `MinPoolSize=10` deutet auf einen begrenzten gleichzeitigen Benutzerkreis hin. Die NHibernate SessionFactory als Singleton und die DAOSession als Unit-of-Work müssen für Cloud-Skalierung neu bewertet werden. Unklar ist, ob die Architektur horizontale Skalierung (mehrere Instanzen) unterstützt.
|
||||
**Fehlende Information:** Lasttests mit mehreren Mandanten und gleichzeitigen Benutzern; Analyse der Session-Verwaltung in Multi-Instance-Szenarien.
|
||||
|
||||
---
|
||||
|
||||
## 4. SyRS-027 – Verfügbarkeit bei Background-Service-Ausfällen
|
||||
|
||||
**ID:** SyRS-027
|
||||
**Titel:** Verfügbarkeit bei Background-Service-Ausfällen
|
||||
**Ebene:** SyRS
|
||||
**Status:** HYPOTHESE
|
||||
**Grund:** Die genaue Fehlerbehandlungs-Logik der `ManagedBackgroundService` (6,8 KB) konnte nicht vollständig analysiert werden. Die `sp_getapplock` in `TaskManagementTaskBL` verhindert Doppel-Ausführung, aber das Verhalten bei Service-Absturz (automatischer Neustart vs. dauerhafter Ausfall) ist unklar. Die `DAOFactory.TryRecoverConnectionPool()` behebt Connection-Pool-Probleme, aber ob dies auch für Service-Ausfälle gilt, ist nicht ersichtlich.
|
||||
**Fehlende Information:** Detaillierte Analyse der `ManagedBackgroundService`-Fehlerbehandlung und der Service-Lifecycle-Verwaltung.
|
||||
|
||||
---
|
||||
|
||||
## 5. SyRS-028 – DSGVO-Datenlöschung Vollständigkeit
|
||||
|
||||
**ID:** SyRS-028
|
||||
**Titel:** DSGVO-Datenlöschung Vollständigkeit
|
||||
**Ebene:** SyRS
|
||||
**Status:** HYPOTHESE
|
||||
**Grund:** Es konnte nicht verifiziert werden, ob die DSGVO-Löschung alle historischen Tabellen (`*Versions`) und Änderungsprotokolle (`ChangeLog`) erfasst. Die Existenz von `*Versions`-Tabellen (z.B. `AufKopfVersions`, `RechKopfVersions`, `VertragKopfVersions`) und der `ChangeLog`-Tabelle deutet auf potenzielle Lücken hin. Das DSGVO-Modul-Verzeichnis (`Administration/DataSecurity/`) wurde nicht im Detail analysiert.
|
||||
**Fehlende Information:** Detaillierte Analyse des DSGLO-Löschmoduls (`Administration/DataSecurity/`) bezüglich der erfassten Tabellen und der Lösch-Tiefe.
|
||||
|
||||
---
|
||||
|
||||
## 6. StRS-028 – DSGVO-Compliance und Datenlöschung
|
||||
|
||||
**ID:** StRS-028
|
||||
**Titel:** DSGVO-Compliance und Datenlöschung
|
||||
**Ebene:** StRS
|
||||
**Status:** HYPOTHESE
|
||||
**Grund:** Die DSGVO-Löschvollständigkeit kann aus statischer Analyse nicht vollständig verifiziert werden. Unklar ist, ob alle personenbezogenen Daten (insbesondere in historischen Tabellen wie `*Versions`-Tabellen und `ChangeLog`) bei einer DSGVO-Löschung erfasst werden. Die `CacheTicketStatistic`-Tabelle enthält ebenfalls personenbezogene Daten (Editor-Listen).
|
||||
**Fehlende Information:** Wie bei SyRS-028 – detaillierte Analyse des DSGVO-Löschmoduls.
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| ID | Ebene | Titel | Fehlende Information |
|
||||
|---|---|---|---|
|
||||
| SwRS-013 | SwRS | Cache-Invalidierung | Aktualisierungsstrategie des CacheUpdateService unklar |
|
||||
| SyRS-025 | SyRS | Performance Ticket-Liste | Ladezeit-Grenze ist Annahme, nicht messbar |
|
||||
| SyRS-026 | SyRS | Skalierbarkeit Multi-Mandant | Tatsächliche Skalierung nicht aus Code ableitbar |
|
||||
| SyRS-027 | SyRS | Verfügbarkeit bei Service-Ausfällen | Fehlerbehandlung der ManagedBackgroundService unklar |
|
||||
| SyRS-028 | SyRS | DSGVO-Löschung Vollständigkeit | Löschung historischer Tabellen unklar |
|
||||
| StRS-028 | StRS | DSGVO-Compliance | Vollständigkeit der Datenlöschung unklar |
|
||||
|
||||
**Anzahl Hypothesen: 6**
|
||||
|
||||
Alle Hypothesen resultieren aus der Beschränkung auf statische Code-Analyse ohne Zugriff auf eine laufende Datenbank oder Testumgebung. Sie betreffen insbesondere nicht-funktionale Anforderungen (Performance, Skalierbarkeit, Verfügbarkeit) sowie die Vollständigkeit von Löschoperationen, die ohne Datenbankzugang nicht verifiziert werden können.
|
||||
+617
@@ -0,0 +1,617 @@
|
||||
# StRS – Stakeholder Requirements Specification
|
||||
|
||||
## Systemübersicht
|
||||
|
||||
Die c-entron ERP-Suite ist einMehrmandanten-fähiges ERP/CRM-System für IT-Dienstleister und Händler. Sie umfasst Belegverwaltung (Angebot → Auftrag → Lieferschein → Rechnung → Gutschrift), Helpdesk/Ticketmanagement mit Zeiterfassung, Artikel- und Lagerverwaltung, Vertragsverwaltung mit Kontingentabrechnung, Mahnwesen, Provisionsverwaltung, Einkaufs-/EDI-Schnittstellen zu Großhändlern, Buchhaltungsschnittstellen, SEPA-Zahlungsverkehr und ein Web-Portal (Nexus) für Kunden und Mitarbeiter.
|
||||
|
||||
### Akteure
|
||||
|
||||
| Akteur | Beschreibung |
|
||||
|---|---|
|
||||
| Backend-Mitarbeiter (Sachbearbeiter) | Bearbeitet Belege, Kunden, Artikel, Tickets im Desktop-Client (WPF) |
|
||||
| Service-Techniker | Erfasst Zeiten und Bearbeitet Tickets vor Ort oder über das Web-Portal (Nexus) |
|
||||
| Vertriebsmitarbeiter | Erstellt Angebote, verwaltet Kunden, sieht Statistiken |
|
||||
| Kundenbetreuer | Verwaltet Kundenbeziehungen, CRM-Aktivitäten, Verträge |
|
||||
| Administrator | Verwaltet Mandanten, Benutzer, Rechte, Lizenzen, Systemeinstellungen |
|
||||
| Web-Account-Benutzer (Kunde) | Kundenportal-Nutzer: sieht Belege, Verträge, erstellt Tickets, nutzt Webshop |
|
||||
| Finanzbuchhalter | Führt Mahnläufe, OPOS-Läufe, SEPA-Exporte, Buchhaltungsexporte durch |
|
||||
| Einkäufer | Bestellt bei Lieferanten, verwaltet EDI-Bestellungen, Wareneingänge |
|
||||
| Lagermitarbeiter | Bucht Wareneingänge, Kommissionierungen, Umbuchungen, Bestandsänderungen |
|
||||
| System (Background-Service) | Automatisierte Hintergrundprozesse (Eskalationen, Reminder, TaskManagement, etc.) |
|
||||
|
||||
---
|
||||
|
||||
## Anforderungen
|
||||
|
||||
```
|
||||
ID: StRS-001
|
||||
Titel: Belegverwaltung über gesamten Lebenszyklus
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Backend-Mitarbeiter, Vertriebsmitarbeiter
|
||||
Vorbedingung: Benutzer ist authentifiziert und hat Beleg-Rechte.
|
||||
Fakt: Das System implementiert Belegtypen (Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag, Lieferantenbestellung, Wareneingang, Lieferantenrechnung, Lieferantengutschrift) mit definierten Weiterverarbeitungsketten über `IReceiptSpecificLogic.CanBeForwardedFrom/Into()` und einer zentralen `ReceiptBL.ForwardReceipt()`-Methode.
|
||||
Aussage: Das System soll Benutzer befähigen, Belege über ihren gesamten Lebenszyklus zu erstellen, weiterzuverarbeiten und zu verfolgen, einschließlich Angebot → Auftrag → Lieferschein → Rechnung → Gutschrift.
|
||||
Ergebnis: Belege können erstellt, weiterverarbeitet und in der Belegkette nachverfolgt werden.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ForwardReceipt<TReceipt,TReceiptItem>()` (~Zeile 1550) und `SpecificLogics`-Dictionary - Begründung: Definiert die zentrale Weiterverarbeitungslogik und alle Belegtypen mit ihren Übergängen.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/Offers/OfferSpecificLogic.cs:313-314`, `CanBeForwardedInto()` - Begründung: Zeigt die konkreten Übergänge eines Belegtyps.
|
||||
Prüfidee: Erstelle ein Angebot, wandle es in einen Auftrag um, daraus einen Lieferschein und schließlich eine Rechnung. Prüfe, dass die Belegkette vollständig nachvollziehbar ist.
|
||||
Tracelinks: SyRS-013, SyRS-014, SwRS-018, SwRS-020, SwRS-021
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernfunktion des ERP-Systems, unverzichtbar für Neuimplementierung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-002
|
||||
Titel: Kunden- und Lieferantenstammdatenverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Backend-Mitarbeiter, Vertriebsmitarbeiter
|
||||
Vorbedingung: Benutzer ist authentifiziert und hat Kunden-/Lieferantenrechte.
|
||||
Fakt: `AccountBL` (93 KB) verwaltet Kunden- und Lieferantenstammdaten mit Adressen, Ansprechpartnern, Klassifizierungen, Beziehungen, Kundennummernvergabe über `NumberGroupBL`, Verzeichniserstellung und Kreditlimit-Berechnung.
|
||||
Aussage: Das System soll Kunden und Lieferanten mit allen relevanten Stammdaten (Adressen, Ansprechpartner, Zahlungskonditionen, Kreditlimit, Klassifizierungen) verwalten und eine automatische Kundennummernvergabe unterstützen.
|
||||
Ergebnis: Kunden und Lieferanten sind vollständig erfasst, mit eindeutigen Nummern, Adressen und Zuordnungen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Accounts/AccountBL.cs`, `SaveAccount()` und `GetUsedLimitForCustomer()` - Begründung: Zentrale Methode für Kundenanlage mit Nummernvergabe und Kreditlimitberechnung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Accounts/AccountSearchBL.cs` (60 KB) - Begründung: Zeigt umfangreiche Suchfunktionen für Kundenstammdaten.
|
||||
Prüfidee: Lege einen neuen Kunden an, prüfe die automatische Nummernvergabe, erfasse eine Adresse und einen Ansprechpartner, prüfe das Kreditlimit.
|
||||
Tracelinks: SyRS-021, SwRS-001
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kern-CRM-Funktion.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-003
|
||||
Titel: Helpdesk-/Ticketverwaltung mit Zeiterfassung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Service-Techniker, Backend-Mitarbeiter
|
||||
Vorbedingung: Benutzer ist authentifiziert und hat Helpdesk-Rechte.
|
||||
Fakt: `hlpdsk_requests`-Tabelle mit Prioritäten, Status, Kategorien, Bearbeitern, SLA-Unterstützung; `hlpdsk_timer` für Zeiterfassung; `CentronRights.md` definiert 18+ Helpdesk-Rechte inkl. einschränkender Rechte (nur eigene, nur eigene Filiale).
|
||||
Aussage: Das System soll Tickets mit Prioritäten, Status, Kategorien, SLA-Regeln, Bearbeiter-Zuordnungen und Zeiterfassung verwalten, einschließlich einschränkender Rechte für die Sichtbarkeit.
|
||||
Ergebnis: Tickets sind kategorisiert, priorisiert, mit Zeiterfassung und SLA-Überwachung versehen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `CheckRightsFromUser()` - Begründung: Durchsetzende Stelle der Helpdesk-Rechteprüfung.
|
||||
- [SEKUNDÄR] `CentronRights.md` - Begründung: Dokumentiert 18+ Helpdesk-Rechte inkl. einschränkender Rechte (SHOW_HELPDESK_ONLY_OWN, SHOW_HELPDESK_ONLY_OWN_BRANCH).
|
||||
- [KONTEXT] `SSMS_DB_SCHEMA.sql`, `hlpdsk_requests` (Zeile ~4521), `hlpdsk_timer` (Zeile ~18452) - Begründung: Datenbanktabellen für Tickets und Zeiterfassung.
|
||||
Prüfidee: Erstelle ein Ticket, weise Bearbeiter zu, erfasse Zeit, prüfe SLA-Eskalation. Wechsle zu einem Benutzer mit nur-eigene-Tickets-Recht und prüfe die eingeschränkte Sicht.
|
||||
Tracelinks: SyRS-001, SyRS-003, SwRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernfunktion für IT-Dienstleister.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-004
|
||||
Titel: Artikelstamm- und Lagerverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Backend-Mitarbeiter, Lagermitarbeiter
|
||||
Vorbedingung: Benutzer ist authentifiziert und hat Artikel-/Lager-Rechte.
|
||||
Fakt: `ArticleBL` (210 KB) verwaltet Artikel mit EAN-Validierung, Stücklisten, Steuern, Warengruppen, 4 VK-Preisen, EK-Preisen; `StockBL` verwaltet Lager, Umbuchungen, Bestände; `BarcodeBL` (57 KB) verwaltet Seriennummern/Barcodes.
|
||||
Aussage: Das System soll Artikel mit umfassenden Stammdaten (EAN, Herstellercode, Steuern, Preise, Stücklisten, Warengruppen) und Lagerbestände über mehrere Lager verwalten.
|
||||
Ergebnis: Artikel sind mit validierten Stammdaten angelegt, Lagerbestände sind pro Lager nachverziehbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `SaveArticle()` mit EAN-Validierung und `CheckUserRightBeforeSave()` - Begründung: Zentrale Artikelanlage mit Validierung und Rechteprüfung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs`, `WriteStockRebookLog()` - Begründung: Umbuchungsprotokollierung mit Validierung.
|
||||
Prüfidee: Lege einen Artikel mit EAN-Code an, validiere die EAN-Prüfziffer, buche Bestand auf ein Lager um und prüfe das Protokoll.
|
||||
Tracelinks: SyRS-024, SwRS-003, SwRS-004
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernfunktion für Handelsunternehmen.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-005
|
||||
Titel: Vertragsverwaltung mit Kontingentabrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Backend-Mitarbeiter, Kundenbetreuer
|
||||
Vorbedingung: Benutzer ist authentifiziert und hat Vertragsrechte.
|
||||
Fakt: `ContractBL` und `ReceiptContractBL` verwalten Verträge mit Laufzeiten, Abrechnungsintervallen, Kontingenten (Stunden/Geld), automatischer Fakturierung mit Zählerverwaltung (`AutomaticFacturaBL`).
|
||||
Aussage: Das System soll Verträge mit Laufzeiten, Abrechnungsintervallen und Kontingenten (Stunden- und Geldkontingente) verwalten sowie die automatische Abrechnung über Zählerstände unterstützen.
|
||||
Ergebnis: Verträge sind mit Kontingenten angelegt, Kontingentverbrauch wird bei Belegerstellung nachverfolgt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptContractHelperBL.cs`, `UpdateContingentBalancePositions()` - Begründung: Durchsetzende Stelle für Kontingentverbrauch beim Belegspeichern.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs` - Begründung: Automatische Fakturierung mit Zählerverwaltung.
|
||||
Prüfidee: Lege einen Vertrag mit Stundenkontingent an, erstelle eine Rechnung mit Service-Artikel, prüfe den Kontingentabzug.
|
||||
Tracelinks: SyRS-014, SwRS-022, SwRS-023
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Zentrale Abrechnungsfunktion für IT-Dienstleister.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-006
|
||||
Titel: Mahnwesen und Forderungsmanagement
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Finanzbuchhalter
|
||||
Vorbedingung: Benutzer ist authentifiziert und hat Mahnwesen-Rechte.
|
||||
Fakt: `DunningRunBL` führt Mahnläufe mit 3 Mahnstufen, `DunningBL` verwaltet Mahnstopps und Statistiken, `ReceiptBL.CheckDunningLevelBeforeReceiptCreation()` blockiert Belegerstellung ab definierter Mahnstufe.
|
||||
Aussage: Das System soll ein dreistufiges Mahnverfahren mit Mahnläufen (Druck/E-Mail), Mahnstopps und automatischer Belegsperre bei kritischer Mahnstufe unterstützen.
|
||||
Ergebnis: Überfällige Rechnungen werden gemahnt, Belegerstellung für kritisch gemahnte Kunden blockiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs`, `ExecuteDunningRunInternal()` mit `UpdateInvoice()` - Begründung: Durchsetzende Stelle der Mahnstufen-Erhöhung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CheckDunningLevelBeforeReceiptCreation()` (~Zeile 10205) - Begründung: Durchsetzende Stelle der Belegsperre.
|
||||
Prüfidee: Führe einen Mahnlauf durch, prüfe die Stufenerhöhung, versuche für den gemahnten Kunden einen neuen Beleg zu erstellen und erwarte eine Blockierung.
|
||||
Tracelinks: SyRS-016, SyRS-017, SwRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernfunktion des Forderungsmanagements.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-007
|
||||
Titel: Provisionsverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertriebsmitarbeiter, Finanzbuchhalter
|
||||
Vorbedingung: Benutzer ist authentifiziert und hat Provisionsrechte.
|
||||
Fakt: `ReceiptProvisionBL` verwaltet Provisionen mit zwei Modi (Schema-basiert und Legacy), `ReceiptProvisionSchemaBL` verwaltet kundenspezifische Provisionsschemata, `ResolveEmployees()` ordnet Empfänger (Berater 1/2, Vertriebsmitarbeiter, Büro-Mitarbeiter) zu.
|
||||
Aussage: Das System soll die Provisionsberechnung für Vertriebsmitarbeiter auf Basis konfigurierbarer Schemata mit unterschiedlichen Berechnungsgrundlagen (Umsatz, Ertrag, Auto) und Empfängern unterstützen.
|
||||
Ergebnis: Provisionen werden beim Speichern von Belegen berechnet und zugeordnet.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptProvisionBL.cs`, `SaveProvision()` mit `ResolvePriceAndProvision()` - Begründung: Durchsetzende Stelle der Provisionsberechnung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptProvisionSchemaBL.cs`, `GetCurrentProvisionSchemaForCustomer()` - Begründung: Kundenspezifische Schemaauswahl.
|
||||
Prüfidee: Konfiguriere ein Provisionsschema, erstelle einen Beleg, prüfe die berechnete Provision und die Empfängerzuordnung.
|
||||
Tracelinks: SyRS-015, SwRS-006
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Wichtig für Vertriebsanreize.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-008
|
||||
Titel: EDI-Schnittstellen zu Großhändlern
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Einkäufer, System
|
||||
Vorbedingung: EDI-Konfiguration für den jeweiligen Lieferanten ist eingerichtet.
|
||||
Fakt: `EDIDispatcherBL` erzeugt EDI-Bestelldokumente je Distributor-Typ (Also, AlsoCH, Komsa, Alltron, OpenTrans21, Herweck, EGIS, Concerto) und lädt diese via FTP/SFTP/HTTPS hoch.
|
||||
Aussage: Das System soll elektronische Bestellungen an Großhändler über standardisierte EDI-Formate (OpenTrans, ALSO, Komsa, Alltron, etc.) übertragen und die Bestellabwicklung automatisieren.
|
||||
Ergebnis: Bestellungen werden elektronisch an Lieferanten übertragen, Lieferscheine und Rechnungen können importiert werden.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs`, `CreateEDISuggestionOrderAsync()` und `EdiOrderUploadAsync()` - Begründung: Durchsetzende Stelle der EDI-Bestellerzeugung und -übertragung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.Gateway/EDI_Alltron/PurchaseOrderRequest.cs` - Begründung: Konkretes EDI-XML-Serialisierungsformat für Alltron.
|
||||
Prüfidee: Konfiguriere eine EDI-Verbindung zu einem Lieferanten, erstelle eine Lieferantenbestellung, führe den EDI-Upload aus und prüfe das übertragene XML.
|
||||
Tracelinks: SwRS-007, SwRS-008
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Automatisierung der Bestellabwicklung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-009
|
||||
Titel: Buchhaltungsschnittstellen
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Finanzbuchhalter
|
||||
Vorbedingung: Buchhaltungssystem ist konfiguriert.
|
||||
Fakt: `BookKeepingExportHelper` exportiert Buchungssätze für 14+ Systeme (DATEV ASCII/XML Online 2012+2020, Abacus, Addison, Sage, SAP, Navision, Lexware, etc.) mit Splitbuchungen, Erlös-/Aufwandskonten, Kostenstellen und Rundungskorrekturen.
|
||||
Aussage: Das System soll Buchhaltungsdaten (Buchungssätze, Debitoren/Kreditoren-Stammdaten, Belege) in verschiedene Buchhaltungssysteme exportieren und aus diesen importieren.
|
||||
Ergebnis: Buchhaltungsdaten können in das Zielsystem übernommen werden.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/DataExchange/BookKeeping/BookKeepingExportHelper.cs` - Begründung: Zentrale Logik für Splitbuchungen, Rundungskorrekturen und Buchungstexte.
|
||||
- [SEKUNDÄR] `src/backend/Centron.Gateway/DataExchange/BookKeeping/DatevXMLOnline2020/BookKeepingExportDatevXmlOnline_2020.cs` - Begründung: Konkrete Implementierung für DATEV XML Online 2020.
|
||||
Prüfidee: Exportiere Rechnungen als DATEV-Datei, prüfe die Splitbuchungen und Kontenzuordnung.
|
||||
Tracelinks: SwRS-009
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Notwendig für Finanzbuchhaltung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-010
|
||||
Titel: SEPA-Zahlungsverkehr
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Finanzbuchhalter
|
||||
Vorbedingung: SEPA-Mandate und Mandanten-Bankdaten sind eingerichtet.
|
||||
Fakt: `PaymentTransactionBL` exportiert SEPA-Lastschriften (pain.008) in 5 Formaten, `PaymentTransactionSepaInterface` generiert XML-Dateien mit IBAN/BIC/Mandatsvalidierung, `RefreshBankInformation()` aktualisiert DirectDebitType (First→Recurrent).
|
||||
Aussage: Das System soll SEPA-Lastschriften für Rechnungen mit gültigen Mandaten generieren, validieren und exportieren, einschließlich der automatischen Aktualisierung des Lastschrifttyps.
|
||||
Ergebnis: SEPA-Lastschriftdaten sind als XML-Datei exportiert und die Mandate aktualisiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa/PaymentTransactionSepaInterface.cs`, `CreateSepaFile()` - Begründung: Durchsetzende Stelle der SEPA-XML-Generierung mit Validierung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs`, `RefreshBankInformation()` (~Zeile 345) - Begründung: Aktualisiert DirectDebitType nach Export.
|
||||
Prüfidee: Erstelle eine Rechnung mit SEPA-Mandat, exportiere die Lastschriftdatei, prüfe das XML-Format und die Aktualisierung des Mandattyps.
|
||||
Tracelinks: SyRS-018, SyRS-019, SwRS-010
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Gesetzlich erforderlicher Zahlungsverkehr.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-011
|
||||
Titel: Kundenportal (Nexus Web)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Web-Account-Benutzer (Kunde), Service-Techniker
|
||||
Vorbedingung: Web-Account ist eingerichtet und authentifiziert.
|
||||
Fakt: `CentronNexus` (Blazor) bietet ServiceBoard (Tickets, Kunden, Zeiterfassung, Dashboard, MyDay, Kanban), WebCart (Shop, Verträge, Belege), WebOffer (Angebote), Office (Dokument-Signatur), Management (Task-Management, Ticket-Patterns).
|
||||
Aussage: Das System soll ein Web-Portal bereitstellen, über das Kunden ihre Tickets einsehen, Belege und Verträge abrufen, im Webshop einkaufen und Dokumente digital signieren können.
|
||||
Ergebnis: Kunden und Mitarbeiter können über den Webbrowser auf ERP-Funktionen zugreifen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/nexus/CentronNexus/ServiceBoard/TicketDetails/TicketDetailsPage.razor` (98 KB) - Begründung: Zentrale Ticket-Detailseite im Web-Portal.
|
||||
- [SEKUNDÄR] `src/nexus/CentronNexus/WebCart/WebCartCartPage.razor` (52 KB) - Begründung: Warenkorb-Funktionalität im Kundenportal.
|
||||
- [KONTEXT] `README.md` - Begründung: Beschreibt WebCart als Feature für Kunden.
|
||||
Prüfidee: Melde dich als Web-Account an, rufe das ServiceBoard auf, erstelle ein Ticket, lege einen Artikel in den Warenkorb.
|
||||
Tracelinks: SyRS-003, SyRS-007, SwRS-011
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Web-Zugang ist für eine SaaS-Neuimplementierung zentral.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-012
|
||||
Titel: Berechtigungsverwaltung mit einschränkenden Rechten
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Administrator
|
||||
Vorbedingung: Benutzer hat Rechteverwaltungs-Rechte.
|
||||
Fakt: `UserRightsConst` definiert Hunderte von Rechten, `AppRightsBL.CheckRightsFromUser()` prüft über SQL (Sichtrus/Sichmemb), einschränkende Rechte (SHOW_ONLY_OWN_CUSTOMER, SHOW_HELPDESK_ONLY_OWN, SHOW_HELPDESK_ONLY_OWN_BRANCH, MANAGE_RIGHTS_ONLY_OWN_BRANCH) begrenzen die Sichtbarkeit.
|
||||
Aussage: Das System soll eine granulare Berechtigungsverwaltung mit einschränkenden Rechten (nur eigene Kunden, nur eigene Tickets, nur eigene Filiale) unterstützen, die die Daten Sichtbarkeit für Benutzer einschränkt.
|
||||
Ergebnis: Benutzer sehen nur die Daten, für die sie berechtigt sind.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `CheckRightsFromUser()` mit SQL-Query auf Sichtrus/Sichmemb - Begründung: Durchsetzende Stelle der Rechteprüfung.
|
||||
- [SEKUNDÄR] `CentronRights.md` - Begründung: Dokumentiert einschränkende Rechte (restricting rights).
|
||||
Prüfidee: Weise einem Benutzer das Recht SHOW_HELPDESK_ONLY_OWN zu, melde dich an und prüfe, dass nur eigene Tickets sichtbar sind.
|
||||
Tracelinks: SyRS-001, SyRS-022, SwRS-014
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Granulares Rechtesystem unverzichtbar für Multi-Mandant.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-013
|
||||
Titel: RMA-/Retourenmanagement
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Backend-Mitarbeiter, Service-Techniker
|
||||
Vorbedingung: Benutzer ist authentifiziert und hat RMA-Rechte.
|
||||
Fakt: `RmaBL` (110 KB) verwaltet Retouren mit Barcode-Umbuchung (RMA-Lager → Hauptlager), Fremdware, Reparatur, Austausch (EqualChange, ForeignChange), Verschrottung (Scapped) und Rücksendungsverwaltung.
|
||||
Aussage: Das System soll Retouren (RMA) mit Artikelumbuchung zwischen Lagern, Bearbeitungsarten (Reparatur, Austausch, Verschrottung) und Rücksendungsverwaltung an Lieferanten und Kunden unterstützen.
|
||||
Ergebnis: Retouren sind mit korrekter Lagerumbuchung und Statusverfolgung erfasst.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/CustomerArea/RmaBL.cs`, `SaveRma()` und `RebookArticleStock()` - Begründung: Durchsetzende Stelle der RMA-Verarbeitung mit Lagerumbuchung.
|
||||
- [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, `Rma`-Tabelle (Zeile ~4145) mit `FK_Rma_HelpdeskI3D` - Begründung: 1:1-Verknüpfung RMA mit Tickets.
|
||||
Prüfidee: Erstelle ein RMA zu einem Ticket, buche einen Artikel um, prüfe die Bestandsänderung in beiden Lagern.
|
||||
Tracelinks: SwRS-012
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Wichtig für IT-Hardware-Rücknahmen.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-014
|
||||
Titel: Passwort- und Zugangsdatenverwaltung
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Backend-Mitarbeiter
|
||||
Vorbedingung: Benutzer hat PasswortManager-Rechte und eine gültige Guideline.
|
||||
Fakt: `PasswordManagerBL` (62 KB) verwaltet Zugangsdaten mit Richtlinien (Guidelines), Versiegelung (Sealing), VPN-Zugängen, Kunden-Mitarbeiter-Rechte-Matrix, AES-Verschlüsselung mit Master-Key, Export als CSV/XLSX.
|
||||
Aussage: Das System soll eine sichere Verwaltung von Kundenzugangsdaten mit rollenbasierten Richtlinien, Verschlüsselung und Audit-Trail unterstützen.
|
||||
Ergebnis: Zugangsdaten sind verschlüsselt gespeichert und nur für berechtigte Mitarbeiter entschlüsselbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, `GetPasswordManagerGuidelines()` und `GetAvailableGuidelinesForEmployee()` - Begründung: Durchsetzende Stelle der Richtlinien- und Berechtigungsprüfung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/CentronConfigDb/CentronConfigurationDbBL.cs` - Begründung: Master-Key-Verwaltung mit `IMasterPasswordStorage`.
|
||||
Prüfidee: Konfiguriere eine Passwort-Manager-Guideline, weise sie Mitarbeitern zu, speichere ein Zugangsdatum und prüfe, dass nur berechtigte Mitarbeiter es entschlüsseln können.
|
||||
Tracelinks: SyRS-011, SwRS-016, SwRS-025
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Sicherheitskritische Funktion für IT-Dienstleister.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-015
|
||||
Titel: E-Rechnung (ZUGFeRD / ebInterface)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Finanzbuchhalter, System
|
||||
Vorbedingung: Rechnung ist erstellt, E-Rechnungsformat ist konfiguriert.
|
||||
Fakt: `ZUGFeRD_EXTENDED.cs` (277 KB) implementiert ZUGFeRD 2.1/FACTUR-X Extended; `EbInterfaceLogic` generiert österreichische E-Rechnungen (ebInterface v4p3); `InvoiceZugferdBL` integriert SEPA-Referenzen.
|
||||
Aussage: Das System soll elektronische Rechnungen im ZUGFeRD- und ebInterface-Format generieren, um gesetzliche Anforderungen an E-Rechnungen zu erfüllen.
|
||||
Ergebnis: Rechnungen sind als valides ZUGFeRD/ebInterface-XML exportiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/ZUGFeRD21_Extended/ZUGFeRD_EXTENDED.cs` (277 KB) - Begründung: Serialisierungsklasse für ZUGFeRD 2.1 Extended.
|
||||
- [PRIMÄR] `src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs`, `GenerateFile(ReceiptInfo receipt)` - Begründung: Durchsetzende Stelle der ebInterface-Generierung.
|
||||
Prüfidee: Erstelle eine Rechnung, exportiere sie als ZUGFeRD-XML, validiere das XML gegen das XSD-Schema.
|
||||
Tracelinks: SwRS-013
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Gesetzlich erforderlich (EU-Rechnungsstandard).
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-016
|
||||
Titel: Mehrmandantenfähigkeit und Filialverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Administrator
|
||||
Vorbedingung: Mandant und Filialen sind eingerichtet.
|
||||
Fakt: `Mandant`- und `Filiale`-Tabellen in der DB; `EmployeeBase.BranchI3D` verknüpft Mitarbeiter mit Filialen; `AppRightsBL` mit `MANAGE_RIGHTS_ONLY_OWN_BRANCH`; `StockBL.GetDefaultWarehouseI3DFromBranch()`.
|
||||
Aussage: Das System soll mehrere Mandanten mit mehreren Filialen pro Mandant verwalten, mit filialbezogenen Daten (Lager, Mitarbeiter, Rechte, Statistiken).
|
||||
Ergebnis: Daten sind mandanten- und filialbezogen getrennt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `GetAllRightGroups()` mit `MANAGE_RIGHTS_ONLY_OWN_BRANCH` - Begründung: Durchsetzende Stelle der Filial-Beschränkung.
|
||||
- [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, `Mandant` (Zeile ~23808) und `Filiale` (Zeile ~4186) - Begründung: Datenbanktabellen für Mandanten und Filialen.
|
||||
Prüfidee: Erstelle zwei Filialen, weise Mitarbeiter zu, prüfe dass Rechteverwaltung nur für die eigene Filiale möglich ist.
|
||||
Tracelinks: SyRS-022, SwRS-006
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Multi-Mandant-Fähigkeit zentral für SaaS.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-017
|
||||
Titel: Desktop-Anwendung (WPF) als Hauptclient
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Backend-Mitarbeiter, Vertriebsmitarbeiter, Finanzbuchhalter
|
||||
Vorbedingung: Anwendung ist installiert und konfiguriert.
|
||||
Fakt: `Centron.WPF.UI` mit DevExpress-Komponenten: Belege (ReceiptView 194 KB), Tickets (TicketDetailView 214 KB), Verträge, Artikel, Kunden, Administration, RMA, PLM, Datenaustausch, Produktion, Statistiken.
|
||||
Aussage: Das System soll eine vollständige Desktop-Anwendung für die Backoffice-Tätigkeiten bereitstellen, die alle ERP-Funktionen über eine einheitliche Oberfläche zugänglich macht.
|
||||
Ergebnis: Backend-Mitarbeiter können alle ERP-Funktionen über die Desktop-Anwendung nutzen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ReceiptViewModel.cs` (297 KB) - Begründung: Größtes ViewModel, zeigt die Komplexität der Belegmaske.
|
||||
- [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/TicketDetailView.xaml` (214 KB) - Begründung: Zentrale Ticket-Detailmaske.
|
||||
Prüfidee: Öffne die Anwendung, navigiere durch die Hauptmodule (Belege, Tickets, Artikel, Kunden), prüfe die Vollständigkeit der Masken.
|
||||
Tracelinks: SwRS-011
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Wird durch Web-Anwendung abgelöst, aber Funktionen müssen erhalten bleiben.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-018
|
||||
Titel: Hintergrundprozesse und Automatisierung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (Background-Service)
|
||||
Vorbedingung: Web-Host läuft.
|
||||
Fakt: 36 gehostete Background-Services in `Centron.Host/AspNetCore/HostedServices/`: Eskalationen, Reminder, TaskManagement, ArticleImport, DataQuality, ExchangeSync, MassUpdate, TelemetryUpload, etc.
|
||||
Aussage: Das System soll automatisierte Hintergrundprozesse für Eskalationen, Erinnerungen, Datenqualität, Synchronisation und zeitgesteuerte Aufgaben ausführen.
|
||||
Ergebnis: Hintergrundprozesse laufen automatisch und ohne Benutzereingriff.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/HostedServices/EscalationsService.cs` - Begründung: Konkreter Background-Service für Eskalationen.
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/HostedServices/TaskManagmentService.cs` (5,2 KB) - Begründung: Führt zeitgesteuerte Tasks aus.
|
||||
- [KONTEXT] `src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs` - Begründung: Basis-Klasse für alle Background-Services.
|
||||
Prüfidee: Konfiguriere einen TaskManager-Task, prüfe dass er automatisch zur konfigurierten Zeit ausgeführt wird.
|
||||
Tracelinks: SyRS-027, SwRS-015
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Automatisierung unverzichtbar für ERP-Betrieb.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-019
|
||||
Titel: Lizenzverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Administrator, System
|
||||
Vorbedingung: Lizenzdatei ist vorhanden.
|
||||
Fakt: `LicenseManager` (Singleton) prüft Lizenzen über 100+ GUID-Konstanten (`LicenseGuids`), `CheckLicense` validiert Anwendung, Version und Max-Lizenzanzahl, `ModuleFeatures` steuert Feature-Sichtbarkeit abhängig von Lizenz.
|
||||
Aussage: Das System soll eine Lizenzverwaltung unterstützen, die den Funktionsumfang der Anwendung pro Kunde/Mandant über GUID-basierte Lizenzen steuert.
|
||||
Ergebnis: Nur lizenzierte Funktionen sind verfügbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, `HasLicense(Guid)` und `CheckLicense()` - Begründung: Durchsetzende Stelle der Lizenzprüfung.
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs` - Begründung: Definiert alle Lizenz-GUIDs.
|
||||
Prüfidee: Entferne eine Lizenz, prüfe dass die entsprechende Funktion nicht mehr verfügbar ist.
|
||||
Tracelinks: SyRS-005, SwRS-015
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: Sonderfall - Das Lizenzmodell sollte für SaaS auf Subscription-basiert umgestellt werden, die Funktionssteuerung bleibt jedoch relevant.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-020
|
||||
Titel: Datenbankgestützte Persistenz (MSSQL)
|
||||
Ebene: StRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: MSSQL-Datenbank ist verfügbar.
|
||||
Fakt: `DAOFactory` konfiguriert NHibernate mit `MsSql2008Dialect` (Custom: `CentronMsSql2008Dialect`), Connection-Pool mit `MaxPoolSize=200`, `MinPoolSize=10`, NamedQueries als XML-Pool (~500 KB).
|
||||
Aussage: Das System soll alle Geschäftsdaten in einer MSSQL-Datenbank persistieren, mit Connection-Pooling und NHibernate als ORM.
|
||||
Ergebnis: Daten sind persistent in MSSQL gespeichert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/DAOFactory.cs`, `SetConnection()` mit FluentNHibernate und `MsSqlConfiguration.MsSql2008` - Begründung: Durchsetzende Stelle der Datenbankanbindung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.DAO/DAOConnections/ConnectionPoolDefaults.cs` - Begründung: Definiert Pool-Parameter.
|
||||
Prüfidee: Verbinde mit der Datenbank, führe CRUD-Operationen durch, prüfe dass Daten persistent gespeichert werden.
|
||||
Tracelinks: SwRS-017, SwRS-018
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Für SaaS-Neuimplementierung auf Cloud-DB zu migrieren, ORM-Pattern bleibt relevant.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-021
|
||||
Titel: Reporting und Statistiken
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertriebsmitarbeiter, Finanzbuchhalter, Administrator
|
||||
Vorbedingung: Benutzer hat Statistik-Rechte.
|
||||
Fakt: `Statistics/` mit Unterverzeichnissen (Accounts, Sales, TicketStatistics, ContractStatistics, OrderStatistics, MSPStatistics), `ReportEngine/` mit `ReportDataBL`, DevExpress-Reports.
|
||||
Aussage: Das System soll Vertriebs-, Ticket-, Vertrags- und Auftragsstatistiken sowie konfigurierbare Reports bereitstellen.
|
||||
Ergebnis: Reports und Statistiken sind generierbar und zeigen Geschäftsdaten aggregiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/ReportEngine/ReportDataBL.cs` - Begründung: Zentrale Reportdaten-Logik.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Statistics/SaleStatistics/` - Begründung: Verkaufsstatistik-Modul.
|
||||
Prüfidee: Generiere einen Vertriebsstatistik-Report, prüfe die Aggregation.
|
||||
Tracelinks: SwRS-019
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Controlling-Funktion.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-022
|
||||
Titel: Web-Service-API (REST)
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System, externe Clients
|
||||
Vorbedingung: Web-Host läuft, Client ist authentifiziert.
|
||||
Fakt: `Centron.Controllers` mit REST-Controllern für alle Fachbereiche, `ICentronRestService` (~366 KB Interface), API-Versionierung, Swagger-Dokumentation, SignalR für Echtzeit-Kommunikation.
|
||||
Aussage: Das System soll eine REST-basierte Web-Service-API für alle ERP-Funktionen bereitstellen, die von Desktop-Client, Web-Portal und Drittsystemen genutzt werden kann.
|
||||
Ergebnis: ERP-Funktionen sind über REST-API zugänglich.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs` - Begründung: Zeigt REST-Controller mit Autorisierung.
|
||||
- [SEKUNDÄR] `src/webservice/Centron.Host/AspNetCore/RegisterCentronSwagger.cs` - Begründung: Swagger-Dokumentation der API.
|
||||
Prüfidee: Rufe einen REST-Endpunkt mit gültigem Token auf, prüfe die Antwort und die Swagger-Dokumentation.
|
||||
Tracelinks: SyRS-007, SyRS-008, SwRS-020
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - API-First-Ansatz für SaaS-Neuimplementierung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-023
|
||||
Titel: Offene Posten Verwaltung (OPOS)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Finanzbuchhalter
|
||||
Vorbedingung: Benutzer hat OPOS-Rechte.
|
||||
Fakt: `OposRunBL.ExecuteOposRun()` generiert Kontoauszüge (Report + Mail), `AccountBL.DeleteAccount()` blockiert Löschung bei offenen Posten, `BookKeepingImportBL` importiert OPOS aus Fibu-Systemen.
|
||||
Aussage: Das System soll offene Posten verwalten, Kontoauszüge generieren und die Löschung von Konten mit offenen Posten verhindern.
|
||||
Ergebnis: Offene Posten sind nachverfolgbar, Kontoauszüge sind generiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs`, `ExecuteOposRun()` - Begründung: Durchsetzende Stelle des OPOS-Laufs.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Accounts/AccountBL.cs`, `DeleteAccount()` mit OPOS-Prüfung - Begründung: Verhindert Kontolöschung bei offenen Posten.
|
||||
Prüfidee: Führe einen OPOS-Lauf durch, prüfe den generierten Kontoauszug. Versuche einen Kunden mit offenen Posten zu löschen.
|
||||
Tracelinks: SyRS-021, SwRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernfunktion des Forderungsmanagements.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-024
|
||||
Titel: Checklistenverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Backend-Mitarbeiter, Service-Techniker
|
||||
Vorbedingung: Benutzer hat Checklisten-Rechte.
|
||||
Fakt: `CentronChecklistBL` (19 KB) verwaltet Checklisten mit hierarchischen Items, Vorlagen, Kunden-Mappings, automatischer Kunden-Ermittlung über Suchfilter und Export als formatierter Text.
|
||||
Aussage: Das System soll Checklisten mit Vorlagen, hierarchischen Items und automatischer Kundenzuordnung für Tickets, Verträge und andere Objekte verwalten.
|
||||
Ergebnis: Checklisten sind Objekten zugeordnet und abarbeitbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs`, `SaveOrUpdateCentronChecklist()` und `ObjectHasOpenChecklists()` - Begründung: Durchsetzende Stelle der Checklistenverwaltung.
|
||||
- [SEKUNDÄR] `CentronRights.md`, Rechte 16.1-16.4 für Checklisten - Begründung: Definiert Checklisten-Rechte.
|
||||
Prüfidee: Erstelle eine Checkliste mit Items, weise sie einem Ticket zu, prüfe die Abarbeitung und den Export als Text.
|
||||
Tracelinks: SwRS-026
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Qualitätsmanagement-Funktion.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-025
|
||||
Titel: Massendatenverarbeitung und Massenaktualisierung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Backend-Mitarbeiter, Administrator
|
||||
Vorbedingung: Benutzer hat MassUpdate-Rechte.
|
||||
Fakt: `MassUpdateBL` und `MassUpdateService` (Background-Service, 2,9 KB) ermöglichen Massenaktualisierungen; `CachedTableBL` (102 KB) verwaltet gecachte Listen für performante Massendatenverarbeitung.
|
||||
Aussage: Das System soll Massenaktualisierungen von Stammdaten und Belegen ermöglichen, asynchron über Background-Services.
|
||||
Ergebnis: Massenänderungen sind durchgeführt und nachverfolgbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/HostedServices/MassUpdateService.cs` - Begründung: Background-Service für Massenaktualisierungen.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/MassUpdate/` - Begründung: Verzeichnis für MassUpdate-Logik.
|
||||
Prüfidee: Starte einen MassUpdate für mehrere Artikel, prüfe die asynchrone Ausführung.
|
||||
Tracelinks: SwRS-027
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Wichtig für effiziente Datenpflege.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-026
|
||||
Titel: Zeiterfassung und Arbeitszeitverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Service-Techniker, Backend-Mitarbeiter
|
||||
Vorbedingung: Benutzer ist authentifiziert und hat Zeiterfassungs-Rechte.
|
||||
Fakt: `hlpdsk_timer`-Tabelle mit Sekunden-basierten Timer-Einträgen, `Time/TimingSettingsBL` für Konfiguration, `MyDayBL` (72 KB) für Tagesplanung, Stopwatches in Nexus, `EmployeeTimerStatistics` in Nexus, `Purchasing/SupplierOrderPerBranchBL.GetBasisTimerToOrder()` verrechnet Helpdesk-Zeiten auf Aufträge.
|
||||
Aussage: Das System soll die Zeiterfassung für Tickets und Aufträge mit Sekundengenauigkeit, konfigurierbaren Zeiteinheiten und Verrechnungsmöglichkeiten unterstützen.
|
||||
Ergebnis: Zeiten sind erfasst, verrechenbar und in Statistiken auswertbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Time/TimingSettingsBL.cs` - Begründung: Konfiguration der Zeiterfassung.
|
||||
- [SEKUNDÄR] `src/nexus/CentronNexus/ServiceBoard/EmployeeTimerStatistics/EmployeeTimerStatistics.razor` - Begründung: Zeiterfassungs-Statistik im Web-Portal.
|
||||
Prüfidee: Erfasse Zeit auf einem Ticket, prüfe die Verrechnung und die Statistik.
|
||||
Tracelinks: SwRS-028
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernfunktion für Dienstleister.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-027
|
||||
Titel: Produktlebenszyklus-Management (PLM)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Backend-Mitarbeiter, Vertriebsmitarbeiter
|
||||
Vorbedingung: Benutzer hat PLM-Rechte.
|
||||
Fakt: `PLM/PlmView.xaml` (97 KB) und `PlmViewModel.cs` (66 KB) in WPF-UI, `PlmImportService` als Background-Service, `Finances/ProductLifecycleBL` für Lizenzartikel-Lebenszyklus.
|
||||
Aussage: Das System soll Produktlebenszyklus-Informationen verwalten, inklusive Produktfamilien, EOL-Markierungen und automatischer Importe.
|
||||
Ergebnis: Produktlebenszyklus-Daten sind aktuell und in der Artikelverwaltung sichtbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/HostedServices/PlmImportService.cs` (3,2 KB) - Begründung: Background-Service für PLM-Import.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `UpdateArticleEOL()` - Begründung: Automatische EOL-Markierung.
|
||||
Prüfidee: Importiere PLM-Daten, prüfe die EOL-Markierung bei Artikeln.
|
||||
Tracelinks: SwRS-003
|
||||
Konsolidierung: Kandidat: PLM- und Asset-Management (DeviceManagement) verwalten beide Hardware-Lebenszyklen und könnten im Zielsystem zusammengeführt werden.
|
||||
Übernahmewürdigkeit: übernehmen - Wichtig für Hardware-Händler.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-028
|
||||
Titel: DSGVO-Compliance und Datenlöschung
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: Administrator
|
||||
Vorbedingung: Benutzer hat DSGVO-Rechte.
|
||||
Fakt: `Administration/DataSecurity/` implementiert DSGVO-Modul mit Datenlöschung und Kontaktbereinigung; `UserRightsConst.DsgvoModule` definiert Rechte (ACCESS_DSGVO_MODULE, DSGVO_DELETE_CONTACT, ACCESS_CLEANUP_DATABASE); WPF-UI hat `DSGVO/CentronDataSecurityView.xaml`.
|
||||
Aussage: Das System soll DSGVO-konforme Datenlöschung und Kontaktbereinigung unterstützen, um gesetzliche Anforderungen an den Datenschutz zu erfüllen.
|
||||
Ergebnis: Personenbezogene Daten können nach DSGVO-Vorgaben gelöscht oder anonymisiert werden.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/` - Begründung: Verzeichnis mit DSGVO-Implementierung.
|
||||
- [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityView.xaml` - Begründung: UI für DSGVO-Funktionen.
|
||||
Prüfidee: Rufe das DSGVO-Modul auf, führe eine Kontaktbereinigung durch, prüfe die Löschprotokollierung.
|
||||
Tracelinks: SyRS-028
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Gesetzlich erforderlich.
|
||||
Status: HYPOTHESE
|
||||
```
|
||||
|
||||
Hinweis: Die DSGVO-Löschvollständigkeit kann aus statischer Analyse nicht vollständig verifiziert werden. Unklar ist, ob alle personenbezogenen Daten (insbesondere in historischen Tabellen wie `*Versions`-Tabellen und `ChangeLog`) erfasst werden.
|
||||
+1270
File diff suppressed because it is too large
Load Diff
+879
@@ -0,0 +1,879 @@
|
||||
# SyRS – System Requirements Specification
|
||||
|
||||
## Anforderungen
|
||||
|
||||
```
|
||||
ID: SyRS-001
|
||||
Titel: Benutzerrechteprüfung über SQL-basierte Rechtegruppen
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: System, alle authentifizierten Benutzer
|
||||
Vorbedingung: Benutzer ist authentifiziert und hat ein gültiges Ticket.
|
||||
Fakt: `AppRightsBL.CheckRightsFromUser(appUserI3D, rightI3Ds)` führt SQL aus: `SELECT st.Recht FROM dbo.Sichtrus st INNER JOIN dbo.Sichmemb sm ON sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D AND st.Recht IN (:RightI3Ds)`. `HasUserRight()` nutzt Caching über `Session.Advanced.Cache.GetOrAdd()`.
|
||||
Aussage: Das System soll Benutzerrechte über eine SQL-basierte Rechtegruppen-Hierarchie prüfen (Benutzer → Gruppe → Recht), mit Caching für Einzelprüfungen.
|
||||
Ergebnis: Nur Benutzer mit dem entsprechenden Recht erhalten Zugriff auf die angefragte Funktion.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `CheckRightsFromUser()` (~Zeile 76) und `HasUserRight()` (~Zeile 346) - Begründung: Durchsetzende Stelle der Rechteprüfung mit SQL-Query und Caching.
|
||||
- [SEKUNDÄR] `CentronRights.md` - Begründung: Dokumentiert die Rechte-Struktur und einschränkende Rechte.
|
||||
Prüfidee: Rufe eine Funktion mit einem Benutzer ohne das entsprechende Recht auf und erwarte eine Ablehnung. Prüfe Performance bei wiederholter Einzelprüfung (Caching).
|
||||
Tracelinks: StRS-012, SwRS-014
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Zentrale Sicherheitsfunktion.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-002
|
||||
Titel: Admin-Gruppen-Schutz gegen Löschung und Modifikation
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: Administrator
|
||||
Vorbedingung: Benutzer hat Rechteverwaltungs-Rechte.
|
||||
Fakt: `AppRightsBL.DeleteRightGroup()` blockiert Löschung wenn `group.I3D == 6 || group.Name.Equals("Administratoren")`. `GetAssignableAdminRightI3Ds()` filtert nicht-administrative Rechte. `SaveAndAssignGroupToRight` und `RemoveAssignGroupToRight` prüfen `IsAdministratorGroup`.
|
||||
Aussage: Das System soll die Admin-Gruppe (I3D=6, Name="Administratoren") vor Löschung und vor Modifikation ihrer Rechte schützen.
|
||||
Ergebnis: Die Admin-Gruppe kann nicht gelöscht und ihre Rechte können nicht verändert werden.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `DeleteRightGroup()` mit `group.I3D == 6 || group.Name.Equals("Administratoren")` - Begründung: Durchsetzende Stelle des Löschschutzes.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `GetAssignableAdminRightI3Ds()` - Begründung: Filter für nicht-administrative Rechte.
|
||||
Prüfidee: Versuche die Admin-Gruppe zu löschen und erwarte eine Fehlermeldung. Versuche ein Admin-Recht zu entziehen und erwarte eine Ablehnung.
|
||||
Tracelinks: SwRS-014
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Systemintegrität muss gewahrt bleiben.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-003
|
||||
Titel: Ticket-basierte Authentifizierung mit IP-Protokollierung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: Alle Benutzer, System
|
||||
Vorbedingung: Benutzer gibt Anmeldedaten ein.
|
||||
Fakt: `Authenticator.GetTicket()` führt `AuthenticateInternal()` → `ValidateAppUser()` → `ValidateRights()` → `LicenseManager.CheckLicense()` → `TicketBL.CreateNewTicket()` → `TicketBL.SetLoginIP()` aus. `TicketAuthenticationHandler` validiert Bearer-Tokens. `AppUser` speichert `LoginIP`, `LoginTime`, `IsLoggedIn`.
|
||||
Aussage: Das System soll Benutzer nach Authentifizierung ein Ticket ausstellen, das IP-Adresse und Login-Zeit protokolliert, und dieses Ticket für alle weiteren API-Aufrufe validieren.
|
||||
Ergebnis: Authentifizierte Benutzer erhalten ein Ticket mit IP-Protokollierung; nicht authentifizierte Aufrufe werden abgewiesen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, `GetTicket()` und `ValidateAppUser()` - Begründung: Durchsetzende Stelle der Ticket-Erstellung und Benutzer-Validierung.
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs` - Begründung: Validiert Tickets für alle REST-Aufrufe.
|
||||
Prüfidee: Melde dich an, prüfe dass Login-IP und -Zeit in der AppUser-Tabelle gespeichert sind. Rufe einen Endpunkt ohne Ticket auf und erwarte 401.
|
||||
Tracelinks: StRS-003, StRS-011, SwRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Authentifizierungssystem für SaaS zu erweitern (OAuth2/OIDC).
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-004
|
||||
Titel: Zwei-Faktor-Authentifizierung (Google Authenticator)
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: Alle Benutzer
|
||||
Vorbedingung: 2FA ist für den Benutzer aktiviert (`UseTwoFactorAuthentication`).
|
||||
Fakt: `TwoFactorAuthenticationBL.ValidateAuthenticationPin()` validiert PIN via `GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin()`. `AppUser.UseTwoFactorAuthentication`, `TwoFactorValidDurationInDays` steuern die Gültigkeitsdauer. `ConnectionManager` konfiguriert `TwoFactorAuthEnabled`, `TwoFactorAuthType`, RADIUS-Parameter.
|
||||
Aussage: Das System soll eine Zwei-Faktor-Authentifizierung über TOTP (Google Authenticator) oder RADIUS unterstützen, mit konfigurierbarer Gültigkeitsdauer.
|
||||
Ergebnis: Bei aktiviertem 2FA ist ein zusätzlicher PIN erforderlich, der gegen einen TOTP-Schlüssel validiert wird.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs`, `ValidateAuthenticationPin()` - Begründung: Durchsetzende Stelle der PIN-Validierung.
|
||||
- [SEKUNDÄR] `src/webservice/c-entron.misc.ConnectionManager/ConnectionManagerViewModel.cs`, RADIUS-Parameter - Begründung: Konfiguration von 2FA/RADIUS.
|
||||
Prüfidee: Aktiviere 2FA für einen Benutzer, melde dich an und gib einen ungültigen PIN ein; erwarte Ablehnung. Gib den korrekten PIN ein und prüfe die Gültigkeitsdauer.
|
||||
Tracelinks: SwRS-029
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Sicherheitsstandard für SaaS.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-005
|
||||
Titel: Lizenzprüfung mit GUID-basierten Lizenzen
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: System
|
||||
Vorbedingung: Lizenzdatei ist geladen.
|
||||
Fakt: `LicenseManager.HasLicense(Guid licenseGuid)` delegiert an `LicensingManager.CheckLicenseVersion`. `CheckLicense(applicationKind, appVersion, user)` prüft LicenseGuid + AdditionalLicenseGuids + CustomerLoginLicenseGuid und Max-Lizenzanzahl. `LicenseGuids` definiert 100+ GUID-Konstanten.
|
||||
Aussage: Das System soll den Funktionsumfang über GUID-basierte Lizenzen steuern und bei der Anmeldung Lizenz, Anwendung und Maximalanzahl prüfen.
|
||||
Ergebnis: Nur lizenzierte Funktionen sind verfügbar; überschrittene Lizenzanzahlen führen zu Ablehnung.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, `HasLicense()` und `CheckLicense()` - Begründung: Durchsetzende Stelle der Lizenzprüfung.
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs` - Begründung: Definiert alle 100+ Lizenz-GUIDs.
|
||||
Prüfidee: Entferne eine Lizenz aus der Datei, starte neu und prüfe dass die entsprechende Funktion gesperrt ist.
|
||||
Tracelinks: StRS-019, SwRS-015
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: Sonderfall - Lizenzmodell für SaaS auf Subscription umzustellen.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-006
|
||||
Titel: Kontosperrung bei Deaktivierung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: System, Administrator
|
||||
Vorbedingung: Benutzerkonto existiert.
|
||||
Fakt: `Authenticator.ValidateAppUser(AppUser? user)` prüft: Benutzer existiert, `IsAccountDisabled` (Checkbox), `AccountDisabledFromDate/ToDate` (Datumsbereich), Mitarbeiter aktiv (`IsActiveEmployeeCompact`).
|
||||
Aussage: Das System soll Benutzerkonten, die deaktiviert wurden oder sich in einem Sperrzeitraum befinden, an der Anmeldung hindern.
|
||||
Ergebnis: Gesperrte Benutzer können sich nicht anmelden.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, `ValidateAppUser()` - Begründung: Durchsetzende Stelle der Kontosperrungsprüfung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.Entities/Entities/Administration/AppUser.cs`, `IsAccountDisabled`, `AccountDisabledFromDate`, `AccountDisabledToDate` - Begründung: Entitäts-Felder für Kontosperrung.
|
||||
Prüfidee: Deaktiviere ein Benutzerkonto, versuche die Anmeldung und erwarte eine Ablehnung. Setze einen Sperrzeitraum und teste außerhalb/innerhalb.
|
||||
Tracelinks: SwRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Sicherheitsstandard.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-007
|
||||
Titel: Globale Autorisierungspflicht für alle REST-Endpunkte
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: System
|
||||
Vorbedingung: Web-Host läuft.
|
||||
Fakt: `CentronHost.Start()` konfiguriert `MapControllers().RequireAuthorization()`, was globale Authorization erzwingt. Zusätzlich: `AddCentronTicket()`, `AddJwtBearer()` mit `TokenValidationParameters`.
|
||||
Aussage: Das System soll alle REST-Endpunkte mit Authentifizierung und Autorisierung absichern; anonyme Aufrufe werden abgewiesen.
|
||||
Ergebnis: Kein REST-Endpunkt ist ohne Authentifizierung erreichbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/CentronHost.cs`, `Start()` mit `MapControllers().RequireAuthorization()` - Begründung: Durchsetzende Stelle der globalen Autorisierung.
|
||||
Prüfidee: Rufe einen REST-Endpunkt ohne Authentifizierungsheader auf und erwarte HTTP 401.
|
||||
Tracelinks: StRS-022, SwRS-020
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Sicherheitsstandard.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-008
|
||||
Titel: REST-Controller-Rechteprüfung über Attribute
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: System
|
||||
Vorbedingung: Benutzer ist authentifiziert.
|
||||
Fakt: `AuthorizeUserRightAttribute` / `UserRightAuthorizationFilter` prüfen einzelne Rechte (401 wenn nicht authentifiziert, 403 wenn Recht fehlt). `AuthorizeAnyUserRightAttribute` (mindestens ein Recht), `AuthorizeAllUserRightsAttribute` (alle Rechte), `AuthorizeCentronHostedAttribute` (Lizenz-basiert).
|
||||
Aussage: Das System soll REST-Controller-Endpunkte mit deklarativen Rechteattributen absichern, die einzelne, beliebige oder alle Rechte prüfen.
|
||||
Ergebnis: Endpunkte sind nur für berechtigte Benutzer zugänglich.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs`, `UserRightAuthorizationFilter.OnAuthorization()` - Begründung: Durchsetzende Stelle der Controller-Autorisierung.
|
||||
- [PRIMÄR] `src/webservice/Centron.Controllers/Authorization/CentronHostedAuthorization.cs`, `CentronHostedHandler` - Begründung: Lizenz-basierte Autorisierung.
|
||||
Prüfidee: Rufe einen mit `[AuthorizeUserRight]` markierten Endpunkt mit einem Benutzer ohne das Recht auf und erwarte HTTP 403.
|
||||
Tracelinks: StRS-022, SwRS-020
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Deklarative Sicherheit.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-009
|
||||
Titel: CentronHosted-Policy (Lizenz-basierte Endpunkt-Freigabe)
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: System
|
||||
Vorbedingung: CentronHost ist initialisiert.
|
||||
Fakt: `CentronHostedRequirement` + `CentronHostedHandler` prüfen `LicenseManager.Instance.HasLicense(LicenseGuids.CentronInternal)`. `AuthorizeCentronHostedAttribute` markiert Endpunkte als c-entron-intern.
|
||||
Aussage: Das System soll bestimmte REST-Endpunkte nur für c-entron-interne Kunden (mit `CentronInternal`-Lizenz) zugänglich machen.
|
||||
Ergebnis: Externe Kunden können c-entron-interne Endpunkte nicht aufrufen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Controllers/Authorization/CentronHostedAuthorization.cs`, `CentronHostedHandler.HandleRequirementAsync()` - Begründung: Durchsetzende Stelle der Lizenz-basierten Freigabe.
|
||||
Prüfidee: Rufe einen mit `[AuthorizeCentronHosted]` markierten Endpunkt ohne CentronInternal-Lizenz auf und erwarte HTTP 403.
|
||||
Tracelinks: SwRS-015
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: Sonderfall - c-entron-interne Funktionen; für SaaS zu überdenken.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-010
|
||||
Titel: PDF-Signierung mit PKCS7 und Timestamp-Server
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: System, Backend-Mitarbeiter
|
||||
Vorbedingung: Signaturzertifikat ist hinterlegt.
|
||||
Fakt: `PdfSigningBL.SignPdfDocument()` signiert PDFs mit PKCS7 (SHA256) und optionalem TSA-Client. `SavePdfSigningSettings()` speichert TSA-Server-URL, Benutzer/Passwort, Signaturgrund/-ort. Zertifikate werden AES-verschlüsselt gespeichert.
|
||||
Aussage: Das System soll PDF-Dokumente digital mit PKCS7/SHA256 signieren und optionale Timestamp-Server-Validierung unterstützen.
|
||||
Ergebnis: PDFs sind digital signiert und rechtsgültig.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Security/PdfSigningBL.cs`, `SignPdfDocument()` und `IsPdfSigningAvailable()` - Begründung: Durchsetzende Stelle der PDF-Signierung.
|
||||
Prüfidee: Signiere ein PDF, prüfe die Signatur mit einem PDF-Reader und validiere den Timestamp.
|
||||
Tracelinks: SwRS-030
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Rechtssicherheit für elektronische Dokumente.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-011
|
||||
Titel: AES-Verschlüsselung sensibler Daten
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: System
|
||||
Vorbedingung: System ist konfiguriert.
|
||||
Fakt: `AESCryptoLogic.EncryptText()` und `DecryptText()` mit SHA512-Key-Derivation (32-Byte Key, 16-Byte IV). Verwendet für: WebServiceConfig (DB-Connection-Strings, Proxy-Passwörter), Mail-Passwörter, Passwort-Manager Master-Key, AI-API-Keys. Default-Schlüssel: `SECURITY_KEY = "lugE!35Djn"` (hardcoded).
|
||||
Aussage: Das System soll sensible Daten (Passwörter, Connection-Strings, API-Keys) mit AES-Verschlüsselung absichern.
|
||||
Ergebnis: Sensible Daten sind verschlüsselt gespeichert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs`, `EncryptText()` und `GetKeyAndIV()` - Begründung: Durchsetzende Stelle der AES-Verschlüsselung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Mail/MailSettingsBL.cs`, Verwendung von `AESCryptoLogic` - Begründung: Konkrete Anwendung der Verschlüsselung.
|
||||
Prüfidee: Prüfe, dass Passwörter in der Datenbank verschlüsselt gespeichert sind. Entschlüssele einen Wert mit dem korrekten Key.
|
||||
Tracelinks: StRS-014, SwRS-016, SwRS-026
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Aber hardcoded Default-Schlüssel muss durch sichere Key-Verwaltung ersetzt werden.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-012
|
||||
Titel: Developer-Security: E-Mail-Adress-Validierung in Nicht-Release-Builds
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: System
|
||||
Vorbedingung: System läuft in Nicht-Release-Build.
|
||||
Fakt: `DeveloperSecurity.Email.ValidateAddress()` ersetzt externe E-Mail-Adressen durch `test@nexoware.com`, wenn `AllowSendingEmailToExternalAddresses` false ist (nur in Release-Builds true). Interne Domain `nexoware.com` wird nicht ersetzt. Verwendung in `ExchangeMail.cs` und `SMTPMail.cs`.
|
||||
Aussage: Das System soll in Nicht-Release-Builds verhindern, dass E-Mails an externe Empfänger gesendet werden, um versehentliche Kundenkommunikation aus Testumgebungen zu vermeiden.
|
||||
Ergebnis: In Testumgebungen werden E-Mails nur an interne Adressen gesendet.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Common/DeveloperSecurity.cs`, `Email.ValidateAddress()` mit `AllowSendingEmailToExternalAddresses` und `DebugHelper.IsReleaseBuild()` - Begründung: Durchsetzende Stelle der E-Mail-Validierung.
|
||||
Prüfidee: Sende in einer Debug-Build-Umgebung eine E-Mail an eine externe Adresse und prüfe, dass sie an test@nexoware.com umgeleitet wird.
|
||||
Tracelinks: SwRS-026
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Schutzmechanismus für Entwicklungs- und Testphasen.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-013
|
||||
Titel: Belegstatus-Maschine mit Weiterverarbeitungsketten
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System, Backend-Mitarbeiter
|
||||
Vorbedingung: Beleg existiert, Benutzer hat Beleg-Rechte.
|
||||
Fakt: `IReceiptSpecificLogic.CanBeForwardedFrom()` und `CanBeForwardedInto()` definieren erlaubte Übergänge (z.B. Angebot→Auftrag/Lieferschein/Rechnung, Auftrag→Lieferschein/Rechnung/Vertrag). `ReceiptBL.ForwardReceipt()` validiert über `ValidateReceiptForwarding()`. `ReceiptState` hat drei Zustände: Active, Completed, Canceled. `AutomaticallyCloseReceiptHelperBL` schließt/öffnet automatisch.
|
||||
Aussage: Das System soll eine Belegstatus-Maschine implementieren, die nur definierte Weiterverarbeitungsübergänge zwischen Belegtypen zulässt und Belege automatisch schließt, wenn alle Positionen vollständig verarbeitet sind.
|
||||
Ergebnis: Nur gültige Belegübergänge sind möglich; vollständig verarbeitete Belege werden automatisch geschlossen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ForwardReceipt()` und `ValidateReceiptForwarding()` - Begründung: Durchsetzende Stelle der Weiterverarbeitungsvalidierung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Internal/AutomaticallyCloseReceiptHelperBL.cs`, `AutomaticallyCloseOrOpenReceipt()` - Begründung: Durchsetzende Stelle des automatischen Belegabschlusses.
|
||||
Prüfidee: Versuche, einen Lieferschein in ein Angebot umzuwandeln (ungültiger Übergang) und erwarte eine Ablehnung. Verarbeite alle Positionen eines Auftrags und prüfe den automatischen Abschluss.
|
||||
Tracelinks: StRS-001, SwRS-018, SwRS-020
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kern-Business-Logik.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-014
|
||||
Titel: Kontingentverbrauch bei Belegspeicherung
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Beleg ist mit einem Vertrag mit Kontingent verknüpft.
|
||||
Fakt: `ReceiptContractHelperBL.UpdateContingentBalancePositions()` berechnet Kontingentverbrauch (Hour/Money) beim Speichern von Lieferscheinen, Rechnungen und Gutschriften. `GetAvailableContingent()` lädt gebuchte/verfügbare Kontingente. `RollBackInvoiceContingent()` bucht bei Gutschrift zurück.
|
||||
Aussage: Das System soll den Kontingentverbrauch (Stunden- und Geldkontingente) bei Belegspeicherung automatisch berechnen, verfügbare Kontingente prüfen und bei Gutschriften zurückbuchen.
|
||||
Ergebnis: Kontingentverbrauch ist korrekt gebucht und nachverfolgbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptContractHelperBL.cs`, `UpdateContingentBalancePositions()` (~Zeile 320) - Begründung: Durchsetzende Stelle des Kontingentverbrauchs.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptContractHelperBL.cs`, `RollBackInvoiceContingent()` - Begründung: Durchsetzende Stelle der Rückbuchung.
|
||||
Prüfidee: Erstelle eine Rechnung mit vertragsgebundenem Artikel, prüfe den Kontingentabzug. Erstelle eine Gutschrift und prüfe die Rückbuchung.
|
||||
Tracelinks: StRS-005, StRS-001, SwRS-022
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Zentrale Abrechnungslogik.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-015
|
||||
Titel: Provisionsberechnung beim Belegspeichern
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Beleg hat Provisionsdaten oder ein Schema ist zugeordnet.
|
||||
Fakt: `ReceiptProvisionBL.SaveProvision()` validiert, speichert `ReceiptProvisionItemEntity`, berechnet `Provision = roundedPrice × (sharePercentage/100) × (provisionPercentage/100)` über `ResolvePriceAndProvision()`. `ReceiptProvisionSchemaBL` verwaltet kundenspezifische Schemata.
|
||||
Aussage: Das System soll Provisionen beim Speichern von Belegen automatisch berechnen, basierend auf konfigurierten Schemata mit Berechnungsgrundlagen (Umsatz, Ertrag, Auto) und Empfängern.
|
||||
Ergebnis: Provisionen sind berechnet und zugeordnet.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptProvisionBL.cs`, `SaveProvision()` mit `ResolvePriceAndProvision()` - Begründung: Durchsetzende Stelle der Provisionsberechnung.
|
||||
Prüfidee: Konfiguriere ein Schema, erstelle einen Beleg, prüfe die berechnete Provision und Empfänger.
|
||||
Tracelinks: StRS-007, SwRS-006
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Vertriebsanreiz-System.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-016
|
||||
Titel: Mahnlauf-Ausführung mit dreistufiger Mahnung
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Finanzbuchhalter, System
|
||||
Vorbedingung: Benutzer hat Mahnwesen-Rechte, offene Rechnungen existieren.
|
||||
Fakt: `DunningRunBL.ExecuteDunningRunInternal()` startet Transaktion, erhöht Mahnstufe über `UpdateInvoice()` (None→Level1→Level2→Level3), speichert `DunningRunItem` mit Old/New-Level, generiert Report (ReportGroupConstants.MAHNUNG), sendet Mail mit PDF bei SendType.Mail. Reset kehrt Stufen zurück.
|
||||
Aussage: Das System soll Mahnläufe mit maximal drei Mahnstufen ausführen, Reports generieren und per Mail oder Druck versenden, mit Rücksetzungsmöglichkeit.
|
||||
Ergebnis: Mahnstufen sind erhöht, Mahnschreiben sind generiert und versendet.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs`, `ExecuteDunningRunInternal()` und `UpdateInvoice()` - Begründung: Durchsetzende Stelle der Mahnlauf-Ausführung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/TextModuleArea/TextModuleBL.cs`, `TextModuleType.AP_MAHNUNG1/2/3` - Begründung: Textbausteine für Mahnstufen.
|
||||
Prüfidee: Führe einen Mahnlauf durch, prüfe die Stufenerhöhung, das generierte PDF und die Mail. Setze den Mahnlauf zurück und prüfe die Stufenrückkehr.
|
||||
Tracelinks: StRS-006, SwRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Forderungsmanagement.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-017
|
||||
Titel: Belegsperre bei kritischer Mahnstufe
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Kunde hat Mahnstufe ≥ konfiguriertem Schwellwert.
|
||||
Fakt: `ReceiptBL.CheckDunningLevelBeforeReceiptCreation()` (~Zeile 10205) ruft `BlockNewReceiptsDunningLevel(customerI3D)` auf; wenn `dunningLevel >= blockOnLevel`, wird `Result.AsError` zurückgegeben. Jede Belegart definiert eigene `BlockNewReceiptsDunningLevel()`.
|
||||
Aussage: Das System soll die Erstellung neuer Belege für Kunden blockieren, deren Mahnstufe einen konfigurierbaren Schwellwert erreicht hat.
|
||||
Ergebnis: Keine neuen Belege für kritisch gemahnte Kunden.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CheckDunningLevelBeforeReceiptCreation()` (~Zeile 10205) - Begründung: Durchsetzende Stelle der Belegsperre.
|
||||
Prüfidee: Setze die Mahnstufe eines Kunden auf Level 3, konfiguriere BlockOnLevel=2, versuche einen neuen Beleg zu erstellen und erwarte eine Fehlermeldung.
|
||||
Tracelinks: StRS-006, SwRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Risikobegrenzung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-018
|
||||
Titel: SEPA-Lastschrift-Generierung mit Mandatsvalidierung
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Finanzbuchhalter, System
|
||||
Vorbedingung: Rechnungen mit SEPA-Mandat existieren, Mandanten-Bankdaten sind konfiguriert.
|
||||
Fakt: `PaymentTransactionSepaInterface.CreateSepaFile()` generiert XML in 5 Formaten (Sepa0080101 bis Sepa00800108GBIC4), validiert IBAN, BIC, Mandat, Autorisierungsdatum. `PaymentTransactionBL.ExportInvoices()` lädt Rechnungen mit DirectDebitType, erstellt PaymentInformation.
|
||||
Aussage: Das System soll SEPA-Lastschriftdateien im pain.008-Format generieren, mit Validierung von IBAN, BIC und Mandatsdaten.
|
||||
Ergebnis: SEPA-XML-Datei ist generiert und validiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa/PaymentTransactionSepaInterface.cs`, `CreateSepaFile()` - Begründung: Durchsetzende Stelle der SEPA-XML-Generierung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs`, `ExportInvoices()` und `RefreshBankInformation()` - Begründung: Durchsetzende Stelle des Rechnungsexports und Mandat-Aktualisierung.
|
||||
Prüfidee: Exportiere SEPA-Lastschriften, validiere das XML gegen das pain.008-Schema, prüfe die DirectDebitType-Aktualisierung (First→Recurrent).
|
||||
Tracelinks: StRS-010, SwRS-010
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Gesetzlich erforderlicher Zahlungsverkehr.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-019
|
||||
Titel: SEPA-Mandatsverwaltung und -Typ-Aktualisierung
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System, Finanzbuchhalter
|
||||
Vorbedingung: SEPA-Mandat ist für eine Bankverbindung hinterlegt.
|
||||
Fakt: `RefreshBankInformation()` setzt `DirectDebitType`: First→Recurrent; Last/Single→`ValidTo=heute`; sonst `ValidTo=heute+2Jahre`. `SepaContractWebServiceBL` verwaltet Mandate mit PDF-Vorschau, Online-Unterschrift, Template-Variablen. Belegspeichern prüft: "Sie haben die DTA/SEPA Zahlungskondition ..., aber kein Lastschrift-Mandat ausgewählt."
|
||||
Aussage: Das System soll SEPA-Mandate verwalten und den DirectDebitType nach Export aktualisieren (First→Recurrent, Last/Single→ValidTo setzen).
|
||||
Ergebnis: Mandate sind aktuell und der DirectDebitType ist korrekt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs`, `RefreshBankInformation()` (~Zeile 345) - Begründung: Durchsetzende Stelle der Typ-Aktualisierung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, SEPA-Mandatsprüfung (~Zeile 10779) - Begründung: Validierung beim Belegspeichern.
|
||||
Prüfidee: Exportiere eine First-Lastschrift, prüfe dass der DirectDebitType auf Recurrent gesetzt wird und ValidTo auf +2 Jahre.
|
||||
Tracelinks: StRS-010, SwRS-010
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - SEPA-Compliance.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-020
|
||||
Titel: Kundenlimit-Prüfung beim Belegspeichern
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Kunde hat ein Kreditlimit konfiguriert.
|
||||
Fakt: `ReceiptBL.SaveReceipt()` ruft `CheckIfCustomerLimitIsReached()` auf. `AccountBL.GetUsedLimitForCustomer()` berechnet genutztes Kreditlimit (Brutto/Netto) über `SpecificLogics`.
|
||||
Aussage: Das System soll beim Speichern von Belegen prüfen, ob das Kreditlimit des Kunden durch den Beleg überschritten wird.
|
||||
Ergebnis: Bei Limitüberschreitung wird eine Warnung oder Fehlermeldung ausgegeben.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CheckIfCustomerLimitIsReached()` in `SaveReceipt()` - Begründung: Durchsetzende Stelle der Limit-Prüfung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Accounts/AccountBL.cs`, `GetUsedLimitForCustomer()` - Begründung: Berechnung des genutzten Limits.
|
||||
Prüfidee: Setze ein niedriges Kreditlimit, erstelle einen Beleg der das Limit überschreitet und erwarte eine Warnung.
|
||||
Tracelinks: StRS-002, SwRS-001
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Risikobegrenzung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-021
|
||||
Titel: OPOS-Prüfung bei Kontolöschung
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Benutzer versucht einen Kunden zu löschen.
|
||||
Fakt: `AccountBL.DeleteAccount()` ruft `AccountStatisticBL.GetAccountUnpaidInvoiceOverview()` auf; wenn offene Rechnungen existieren (`ObjectKind == CentronObjectKindNumeric.InvoiceClass`), wird `Result.AsError("Account kann nicht gelöscht werden da noch offene Posten vorhanden sind.")` zurückgegeben.
|
||||
Aussage: Das System soll die Löschung von Kundenkonten verhindern, wenn offene Posten (Rechnungen) existieren.
|
||||
Ergebnis: Konten mit offenen Posten können nicht gelöscht werden.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Accounts/AccountBL.cs`, `DeleteAccount()` mit `GetAccountUnpaidInvoiceOverview()` - Begründung: Durchsetzende Stelle der OPOS-Prüfung.
|
||||
Prüfidee: Versuche einen Kunden mit offenen Rechnungen zu löschen und erwarte eine Fehlermeldung.
|
||||
Tracelinks: StRS-002, StRS-023, SwRS-001
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Datenintegrität.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-022
|
||||
Titel: Branch-Beschränkung der Rechteverwaltung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: Administrator
|
||||
Vorbedingung: Benutzer hat Rechteverwaltungs-Recht mit `MANAGE_RIGHTS_ONLY_OWN_BRANCH`.
|
||||
Fakt: `AppRightsBL.GetAllRightGroups()`, `SaveRightGroup()`, `DeleteRightGroup()`, `CopyRightGroup()` prüfen `MANAGE_RIGHTS_ONLY_OWN_BRANCH` und filtern auf Gruppen der eigenen Filiale.
|
||||
Aussage: Das System soll Benutzer mit dem einschränkenden Recht `MANAGE_RIGHTS_ONLY_OWN_BRANCH` auf die Verwaltung von Rechtegruppen ihrer eigenen Filiale beschränken.
|
||||
Ergebnis: Benutzer können nur Rechtegruppen ihrer Filiale verwalten.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `GetAllRightGroups()` und `SaveRightGroup()` mit `MANAGE_RIGHTS_ONLY_OWN_BRANCH` - Begründung: Durchsetzende Stelle der Branch-Beschränkung.
|
||||
Prüfidee: Weise einem Benutzer MANAGE_RIGHTS_ONLY_OWN_BRANCH zu, versuche eine Rechtegruppe einer anderen Filiale zu bearbeiten und erwarte eine Ablehnung.
|
||||
Tracelinks: StRS-012, StRS-016, SwRS-006
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Multi-Mandant-Sicherheit.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-023
|
||||
Titel: JWT-Bearer-Token-Validierung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: System
|
||||
Vorbedingung: JWT-Authentifizierung ist konfiguriert.
|
||||
Fakt: `CentronHost.Start()` konfiguriert `AddJwtBearer()` mit `TokenValidationParameters` (ValidateIssuer, ValidateAudience, ValidateLifetime, RequireSignedTokens). `JwtAuthClient.GetTicketWithBearer()` tauscht JWT gegen c-entron-Ticket. `AuthenticatorFactory` wählt `OpenIdConnectAuthenticator` bei `LicenseGuids.OpenIDConnectAuthentication`.
|
||||
Aussage: Das System soll JWT-Bearer-Token validieren (Issuer, Audience, Lifetime, Signatur) und gegen c-entron-Tickets austauschen.
|
||||
Ergebnis: Nur gültige, signierte JWT-Tokens werden akzeptiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/CentronHost.cs`, `AddJwtBearer()` mit `TokenValidationParameters` - Begründung: Durchsetzende Stelle der JWT-Validierung.
|
||||
- [PRIMÄR] `src/webservice/Centron.WebServices.Core/HttpClients/JwtAuthClient.cs`, `GetTicketWithBearer()` - Begründung: JWT-zu-Ticket-Austausch.
|
||||
Prüfidee: Sende ein abgelaufenes oder unsigniertes JWT und erwarte HTTP 401.
|
||||
Tracelinks: SwRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - OIDC-Integration für SaaS.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-024
|
||||
Titel: EK-Preis-Aktualisierung bei Wareneingang
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System, Lagermitarbeiter
|
||||
Vorbedingung: Wareneingang wird gebucht.
|
||||
Fakt: `ArticleBL.UpdateArticlePurchasePriceThroughStockBooking()` aktualisiert EK-Preise (RawEK1/RawEK2) bei Wareneingangsbuchungen mit Historie. `ArticleBL.UpdateArticleEOL()` markiert Artikel als End-of-Life bei Nicht-Verfügbarkeit.
|
||||
Aussage: Das System soll beim Wareneingang die Einkaufspreise der Artikel automatisch aktualisieren und eine Preis-Historie führen.
|
||||
Ergebnis: EK-Preise sind aktuell und historisch nachverfolgbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `UpdateArticlePurchasePriceThroughStockBooking()` - Begründung: Durchsetzende Stelle der EK-Preis-Aktualisierung.
|
||||
Prüfidee: Buche einen Wareneingang mit neuem EK-Preis, prüfe die Aktualisierung und die Historie.
|
||||
Tracelinks: StRS-004, SwRS-003
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Preisaktualität.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-025
|
||||
Titel: Performance der Ticket-Listen-Abfrage
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Performance-Effizienz
|
||||
Akteur: Backend-Mitarbeiter, Service-Techniker
|
||||
Vorbedingung: Ticket-Liste mit mehreren tausend Einträgen.
|
||||
Fakt: `cvw_Tickets`-View joint hlpdsk_requests + Kunden + Personal + VertragKopf + CacheTicketStatistic. `CacheTicketStatistic`-Tabelle (Zeile ~4650) aggregiert Timer-Summen. `CachedTicketListPage.razor` in Nexus.
|
||||
Aussage: Das System soll Ticket-Listen mit mehreren tausend Einträgen in akzeptabler Zeit (unter 3 Sekunden) laden, unterstützt durch gecachte Statistiken.
|
||||
Ergebnis: Ticket-Listen sind performant abrufbar.
|
||||
Belege:
|
||||
- [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, `cvw_Tickets`-View und `CacheTicketStatistic`-Tabelle - Begründung: Zeigt die Komplexität der Ticket-Listen-Abfrage und das Caching.
|
||||
- [SEKUNDÄR] `src/nexus/CentronNexus/ServiceBoard/CachedTicketList/CachedTicketListPage.razor` - Begründung: Web-UI mit Caching-Bezeichnung.
|
||||
Prüfidee: Lade eine Ticket-Liste mit >5000 Einträgen und messe die Ladezeit.
|
||||
Tracelinks: SwRS-013
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Performance kritisch für Benutzerakzeptanz.
|
||||
Status: HYPOTHESE
|
||||
```
|
||||
|
||||
Hinweis: Die konkreten Performance-Werte können aus statischer Analyse nicht abgeleitet werden. Die 3-Sekunden-Grenze ist eine Annahme basierend auf allgemeiner Usability.
|
||||
|
||||
```
|
||||
ID: SyRS-026
|
||||
Titel: Skalierbarkeit für Multi-Mandanten-Betrieb
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Performance-Effizienz
|
||||
Akteur: System
|
||||
Vorbedingung: Mehrere Mandanten nutzen das System gleichzeitig.
|
||||
Fakt: Connection-Pool mit `MaxPoolSize=200`, `MinPoolSize=10`; `DAOSession` mit verschachtelbaren Transaktionen; `ManagedBackgroundService` als Basis für 36 Background-Services; NHibernate SessionFactory als Singleton.
|
||||
Aussage: Das System soll den gleichzeitigen Betrieb mehrerer Mandanten mit ausreichendem Connection-Pooling und Session-Management unterstützen.
|
||||
Ergebnis: Mehrere Mandanten können ohne Connection-Erschöpfung arbeiten.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/DAOConnections/ConnectionPoolDefaults.cs`, `MaxPoolSize=200`, `MinPoolSize=10` - Begründung: Durchsetzende Stelle der Pool-Konfiguration.
|
||||
- [SEKUNDÄR] `src/backend/Centron.DAO/DAOSession.cs`, verschachtelbare Transaktionen - Begründung: Session-Management.
|
||||
Prüfidee: Simuliere 50 gleichzeitige Benutzer über mehrere Mandanten und prüfe, dass keine Connection-Timeouts auftreten.
|
||||
Tracelinks: SwRS-017, SwRS-018
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Für SaaS zwingend.
|
||||
Status: HYPOTHESE
|
||||
```
|
||||
|
||||
Hinweis: Die tatsächliche Skalierbarkeit kann nicht aus statischer Analyse bestimmt werden. Die Pool-Größe deutet auf einen begrenzten gleichzeitigen Benutzerkreis hin.
|
||||
|
||||
```
|
||||
ID: SyRS-027
|
||||
Titel: Verfügbarkeit bei Background-Service-Ausfällen
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: System
|
||||
Vorbedingung: Ein Background-Service fällt aus.
|
||||
Fakt: `ManagedBackgroundService` (6,8 KB) als Basis-Klasse mit Fehlerbehandlung; `ForceGarbageCollectService` als separater Service; `TaskManagmentService` mit `sp_getapplock` für verteilte Sperre. `DAOFactory.TryRecoverConnectionPool()` erkennt und behebt Connection-Pool-Probleme.
|
||||
Aussage: Das System soll bei Ausfall eines Background-Services den Gesamtbetrieb aufrechterhalten und Connection-Pool-Probleme automatisch beheben.
|
||||
Ergebnis: System bleibt verfügbar auch bei einzelnen Service-Ausfällen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs` - Begründung: Basis-Klasse mit Fehlerbehandlung für Background-Services.
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/DAOFactory.cs`, `TryRecoverConnectionPool()` - Begründung: Automatische Connection-Pool-Wiederherstellung.
|
||||
Prüfidee: Simuliere den Absturz eines Background-Services und prüfe, dass das System weiterläuft.
|
||||
Tracelinks: StRS-018, SwRS-015
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Verfügbarkeitsanforderung.
|
||||
Status: HYPOTHESE
|
||||
```
|
||||
|
||||
Hinweis: Die genaue Fehlerbehandlungs-Logik der ManagedBackgroundService konnte nicht vollständig analysiert werden. Unklar ist, ob Services automatisch neu gestartet werden.
|
||||
|
||||
```
|
||||
ID: SyRS-028
|
||||
Titel: DSGVO-Datenlöschung Vollständigkeit
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: Administrator
|
||||
Vorbedingung: Benutzer hat DSGVO-Rechte (ACCESS_DSGVO_MODULE, DSGVO_DELETE_CONTACT).
|
||||
Fakt: `Administration/DataSecurity/` implementiert DSGVO-Modul. `UserRightsConst.DsgvoModule` definiert Rechte. DB hat `*Versions`-Tabellen für Historie, `ChangeLog` für Änderungsverfolgung. `cvw_CustomerUnpaidInvoices` und `CacheTicketStatistic` enthalten potenziell personenbezogene Daten.
|
||||
Aussage: Das System soll bei DSGVO-Löschungen alle personenbezogenen Daten einschließlich historischer Versionen und Änderungsprotokolle erfassen.
|
||||
Ergebnis: Alle personenbezogenen Daten sind gelöscht oder anonymisiert.
|
||||
Belege:
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Administration/DataSecurity/` - Begründung: Verzeichnis existiert, aber Löschoption nicht im Detail analysiert.
|
||||
- [KONTEXT] `SSMS_DB_SCHEMA.sql`, `*Versions`-Tabellen und `ChangeLog` - Begründung: Historische Tabellen enthalten potenziell personenbezogene Daten.
|
||||
Prüfidee: Führe eine DSGVO-Löschung durch und prüfe, ob Daten in Versions- und ChangeLog-Tabellen ebenfalls gelöscht/anonymisiert wurden.
|
||||
Tracelinks: StRS-028, SwRS-031
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Gesetzliche Anforderung.
|
||||
Status: HYPOTHESE
|
||||
```
|
||||
|
||||
Hinweis: Es konnte nicht verifiziert werden, ob die DSGVO-Löschung alle historischen Tabellen und Änderungsprotokolle erfasst. Die Existenz von `*Versions`-Tabellen und `ChangeLog` deutet auf potenzielle Lücken hin.
|
||||
|
||||
```
|
||||
ID: SyRS-029
|
||||
Titel: Verschlüsselte Web-Service-Kommunikation (HTTPS)
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: System
|
||||
Vorbedingung: Web-Host ist konfiguriert.
|
||||
Fakt: `CentronHost.Start()` konfiguriert Kestrel/HttpSys mit HTTPS und X509-Zertifikaten über `X509CertificateLoader`. `ConnectionManager` verwaltet SSL/TLS-Einstellungen.
|
||||
Aussage: Das System soll die Web-Service-Kommunikation über HTTPS mit X509-Zertifikaten absichern.
|
||||
Ergebnis: Alle Web-Service-Aufrufe sind verschlüsselt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/CentronHost.cs`, Kestrel/HttpSys-Konfiguration mit X509-Zertifikaten - Begründung: Durchsetzende Stelle der HTTPS-Konfiguration.
|
||||
- [SEKUNDÄR] `src/webservice/c-entron.misc.ConnectionManager/ConnectionManagerViewModel.cs` - Begründung: UI für SSL-Konfiguration.
|
||||
Prüfidee: Rufe einen REST-Endpunkt über HTTP auf und erwarte eine Umleitung zu HTTPS oder Ablehnung.
|
||||
Tracelinks: SwRS-020
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Sicherheitsstandard.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-030
|
||||
Titel: SignalR-basierte Echtzeit-Kommunikation
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System, Web-Portal
|
||||
Vorbedingung: Web-Host läuft, Client ist verbunden.
|
||||
Fakt: `CentronHost.Start()` konfiguriert SignalR in `RegisterCentronServices()`. Nexus nutzt Blazor Server mit Echtzeit-Updates (z.B. Ticket-Listen, Stopwatches).
|
||||
Aussage: Das System soll Echtzeit-Kommunikation zwischen Server und Clients über SignalR unterstützen, um Live-Updates (z.B. Ticket-Änderungen, Timer) zu推送.
|
||||
Ergebnis: Clients erhalten Echtzeit-Updates ohne Polling.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/RegisterCentronServices.cs`, SignalR-Registrierung - Begründung: Durchsetzende Stelle der SignalR-Konfiguration.
|
||||
- [SEKUNDÄR] `src/nexus/CentronNexus/ServiceBoard/Stopwatches/` - Begründung: Echtzeit-Timer in Nexus.
|
||||
Prüfidee: Öffne zwei Browser-Sessions, ändere ein Ticket in einer und prüfe, ob die andere Session ein Echtzeit-Update erhält.
|
||||
Tracelinks: SwRS-011
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - UX-Verbesserung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-031
|
||||
Titel: Automatisches Änderungs-Tracking mit Audit-Trail
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: System
|
||||
Vorbedingung: Entität ist mit `[ChangeTrackingConfiguration]` markiert.
|
||||
Fakt: `ChangeTrackingEventListener` (NHibernate IPreUpdateEventListener) vergleicht Old/New-State von Properties mit `[TrackChanges]`-Attribut. Erstellt `ChangeLog`-Einträge mit ObjectI3D, Property, OldValue, NewValue, Date und `AppUser` (über `LoggedInUserManager.AppUserI3D`). Nutzt `ConcurrentDictionary` für Caching.
|
||||
Aussage: Das System soll Änderungen an als verfolgbar markierten Entitäten automatisch protokollieren, einschließlich altem/neuem Wert, Zeitstempel und auslösendem Benutzer.
|
||||
Ergebnis: Alle Änderungen an verfolgten Entitäten sind in ChangeLog-Einträgen nachverfolgbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs`, `OnPreUpdate()` mit Old/New-State-Vergleich - Begründung: Durchsetzende Stelle des automatischen Änderungs-Trackings.
|
||||
- [PRIMÄR] `src/backend/Centron.Common/Users/LoggedInUserManager.cs`, `AppUserI3D` via `AsyncLocal<int>` - Begründung: Identifiziert den auslösenden Benutzer thread-safe.
|
||||
Prüfidee: Ändere einen Wert an einer verfolgten Entität und prüfe den ChangeLog-Eintrag mit altem/neuem Wert, Datum und Benutzer.
|
||||
Tracelinks: SwRS-032
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Audit-Trail für Compliance.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-032
|
||||
Titel: Datenbank-Transaktionssicherheit
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: System
|
||||
Vorbedingung: Datenbank-Operation wird ausgeführt.
|
||||
Fakt: `DAOSession` implementiert verschachtelbare Transaktionen mit Referenzzähler (`_transactionCount`): `StartTransaction()`, `CommitTransaction()`, `RollbackTransaction()`. `WithTransaction<T>(Func<Result<T>>)` führt Commit bei `Result.Status == Success` aus, sonst Rollback. `SessionExtensions.BeginTransactionSave()` für sichere Transaktionsmuster.
|
||||
Aussage: Das System soll Datenbankoperationen in verschachtelbaren Transaktionen ausführen, die bei Fehlern automatisch zurückgerollt werden.
|
||||
Ergebnis: Datenbankintegrität ist bei Fehlern gewährleistet.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/DAOSession.cs`, `WithTransaction<T>()` und `_transactionCount` - Begründung: Durchsetzende Stelle der Transaktionsverwaltung.
|
||||
Prüfidee: Löse einen Fehler innerhalb einer Transaktion aus und prüfe, dass alle Änderungen zurückgerollt werden.
|
||||
Tracelinks: SwRS-017
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Datenintegrität.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-033
|
||||
Titel: Connection-Pool-Wiederherstellung bei Fehlern
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: System
|
||||
Vorbedingung: Connection-Pool-Fehler tritt auf.
|
||||
Fakt: `DAOFactory.TryRecoverConnectionPool(exception)` erkennt Connection-Pool-Probleme und ruft `SqlConnection.ClearAllPools()` auf.
|
||||
Aussage: Das System soll bei Connection-Pool-Erschöpfung automatische Wiederherstellung durchführen.
|
||||
Ergebnis: Nach Connection-Pool-Fehlern sind neue Verbindungen wieder möglich.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/DAOFactory.cs`, `TryRecoverConnectionPool()` - Begründung: Durchsetzende Stelle der Pool-Wiederherstellung.
|
||||
Prüfidee: Erschöpfe den Connection-Pool und prüfe, dass das System sich automatisch erholt.
|
||||
Tracelinks: SwRS-017
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Betriebsstabilität.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-034
|
||||
Titel: Automatische String-Truncation zur Vermeidung von DB-Fehlern
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: System
|
||||
Vorbedingung: String-Wert überschreitet DB-Spaltenlänge.
|
||||
Fakt: `TruncateStringsEventListener` (NHibernate IPreInsert/UpdateEventListener) und `StringOrBinaryDataWouldBeTruncatedEventListener` kürzen Strings automatisch auf die Spaltenlänge.
|
||||
Aussage: Das System soll String-Werte automatisch auf die Datenbank-Spaltenlänge kürzen, um Truncation-Fehler zu vermeiden.
|
||||
Ergebnis: Keine Datenbankfehler durch zu lange Strings.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/TruncateStringsEventListener.cs` - Begründung: Durchsetzende Stelle der automatischen String-Kürzung.
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/StringOrBinaryDataWouldBeTruncatedEventListener.cs` - Begründung: Spezieller Listener für SQL Server Truncation-Warnungen.
|
||||
Prüfidee: Speichere einen String der die Spaltenlänge überschreitet und prüfe, dass er automatisch gekürzt wird.
|
||||
Tracelinks: SwRS-017
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: Workaround - Verhindert Fehler, maskiert aber Datenverlust; im Zielsystem sollte Validierung vor DB-Schicht erfolgen.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-035
|
||||
Titel: Dokumentenvolltext-Indexierung
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System, Backend-Mitarbeiter
|
||||
Vorbedingung: Dokumente sind im System hinterlegt.
|
||||
Fakt: `DocumentFulltextIndexUpdateService` (Background-Service) und `ObjectFulltextIndexUpdateService` indizieren Dokumente und Objekte für die Volltextsuche. `IndexSearch`-BL-Modul bietet Suchfunktionalität.
|
||||
Aussage: Das System soll Dokumente und Objekte automatisch volltext-indizieren, um eine schnelle Suchfunktion zu ermöglichen.
|
||||
Ergebnis: Dokumente sind über Volltextsuche auffindbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/HostedServices/DocumentFulltextIndexUpdateService.cs` - Begründung: Background-Service für Dokument-Indizierung.
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/HostedServices/ObjectFulltextIndexUpdateService.cs` - Begründung: Background-Service für Objekt-Indizierung.
|
||||
Prüfidee: Lade ein Dokument hoch, warte auf Indizierung, suche nach einem Begriff aus dem Dokument.
|
||||
Tracelinks: SwRS-033
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Suchfunktion wichtig für Usability.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-036
|
||||
Titel: E-Mail-Konfiguration (SMTP/Exchange/Graph)
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System, Administrator
|
||||
Vorbedingung: E-Mail-Einstellungen sind konfiguriert.
|
||||
Fakt: `MailSettingsBL` (17 KB) konfiguriert SMTP (Host/Port/Auth/SSL), Exchange (Version), Microsoft Graph (AppId/Tenant/Secret). Verschiedene Absenderadressen pro Belegtyp (Angebote, Aufträge, Rechnungen, Helpdesk, Lieferlisten). Mail-Tracking-Keywords. SMS-Gateway. Allowed-Emails-Whitelist. Passwortverschlüsselung via `AESCryptoLogic`.
|
||||
Aussage: Das System soll E-Mail-Kommunikation über SMTP, Exchange oder Microsoft Graph unterstützen, mit belegtyp-spezifischen Absenderadressen und Mail-Tracking.
|
||||
Ergebnis: E-Mails werden über das konfigurierte System versendet.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Mail/MailSettingsBL.cs`, `GetMailSettings()` und `SetMailSettings()` - Begründung: Durchsetzende Stelle der E-Mail-Konfiguration.
|
||||
Prüfidee: Konfiguriere SMTP, sende eine E-Mail und prüfe den Versand. Wechsle zu Microsoft Graph und wiederhole.
|
||||
Tracelinks: SwRS-034
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - E-Mail-Kommunikation zentral.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-037
|
||||
Titel: Automatischer Artikelimport
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Import-Quelle ist konfiguriert.
|
||||
Fakt: `ArticleImportService` (Background-Service) und `PlmImportService` importieren automatisch Artikel- und PLM-Daten. `AutomaticPriceUpdateService` aktualisiert Preise. `UpdateArticleAndMaterialGroupTaxRatesService` aktualisiert Steuersätze.
|
||||
Aussage: Das System soll Artikelstammdaten, Preise und Steuersätze automatisch über Background-Services importieren und aktualisieren.
|
||||
Ergebnis: Artikelstammdaten sind aktuell ohne manuellen Eingriff.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/HostedServices/ArticleImportService.cs` - Begründung: Background-Service für Artikelimport.
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/HostedServices/UpdateArticleAndMaterialGroupTaxRatesService.cs` - Begründung: Background-Service für Steueraktualisierung.
|
||||
Prüfidee: Konfiguriere eine Import-Quelle, warte auf den automatischen Import und prüfe die aktualisierten Daten.
|
||||
Tracelinks: SwRS-003, SwRS-015
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Automatisierung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-038
|
||||
Titel: Telemetrie und Nutzungsanalyse
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Wartbarkeit
|
||||
Akteur: System
|
||||
Vorbedingung: System läuft.
|
||||
Fakt: `TelemetryUploadService` (11,9 KB) und `TelemetryFlushService` als Background-Services; `Telemetry`-BL-Modul; `FlushAnalyticEventsService` für Analytics-Events.
|
||||
Aussage: Das System soll Telemetrie- und Nutzungsdaten erfassen und automatisch hochladen, um Systemgesundheit und Nutzung zu überwachen.
|
||||
Ergebnis: Telemetriedaten sind erfasst und übertragen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/HostedServices/TelemetryUploadService.cs` (11,9 KB) - Begründung: Durchsetzende Stelle der Telemetrie-Übertragung.
|
||||
Prüfidee: Starte das System, prüfe dass Telemetriedaten erfasst und periodisch hochgeladen werden.
|
||||
Tracelinks: SwRS-035
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Wartbarkeit und Monitoring.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-039
|
||||
Titel: GLS- und Shipcloud-Versandintegration
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Backend-Mitarbeiter, System
|
||||
Vorbedingung: Versanddienstleister ist konfiguriert.
|
||||
Fakt: `CentronGlsLogic.UploadShipment()` (REST/JSON) erstellt GLS-Versandetiketten mit Tracking-URL. `CentronShipcloudLogic.CreateShipmentAsync()` (REST/JSON) unterstützt Multi-Carrier-Versand mit Label-URL und Preis.
|
||||
Aussage: Das System soll Versandetiketten über GLS und Shipcloud erstellen und Tracking-Informationen zurückgeben.
|
||||
Ergebnis: Versandetiketten sind erstellt und Tracking-IDs verfügbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/apis/Centron.Api.Gls/CentronGlsLogic.cs`, `UploadShipment()` - Begründung: Durchsetzende Stelle der GLS-Integration.
|
||||
- [PRIMÄR] `src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs`, `CreateShipmentAsync()` - Begründung: Durchsetzende Stelle der Shipcloud-Integration.
|
||||
Prüfidee: Erstelle einen Versand über GLS und über Shipcloud, prüfe die erhaltenen Tracking-URLs und Label.
|
||||
Tracelinks: SwRS-036
|
||||
Konsolidierung: Kandidat: GLS- und Shipcloud-Integration sind zwei separate Implementierungen desselben fachlichen Konzepts (Versandetiketten-Erstellung) und sollten im Zielsystem zu einem Versanddienst-Interface zusammengeführt werden.
|
||||
Übernahmewürdigkeit: übernehmen - Versandautomatisierung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-040
|
||||
Titel: Online-Banking (FinTS/HBCI und finAPI)
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System, Finanzbuchhalter
|
||||
Vorbedingung: Bankverbindung ist konfiguriert.
|
||||
Fakt: `OnlineBankingConnectionLibfintx` ruft Kontoauszüge via FinTS/HBCI ab mit TAN-Handling. `FinApiClient` (REST/OAuth) importiert Bankverbindungen und Transaktionen (12 Monate) mit WebForm-TAN.
|
||||
Aussage: Das System soll Banktransaktionen über FinTS/HBCI oder finAPI abrufen und importieren.
|
||||
Ergebnis: Kontoauszüge sind im System verfügbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/OnlineBanking/OnlineBankingConnectionLibfintx.cs`, `LoadOnlineBankingTransactionsByFinTS()` - Begründung: Durchsetzende Stelle der FinTS-Transaktion.
|
||||
- [PRIMÄR] `src/apis/Centron.APIs.FinAPI/FinApiClient.cs` - Begründung: REST-Client für finAPI.
|
||||
Prüfidee: Konfiguriere eine Bankverbindung, rufe Umsätze ab und prüfe den Import.
|
||||
Tracelinks: SwRS-037
|
||||
Konsolidierung: Kandidat: FinTS/HBCI und finAPI sind zwei separate Implementierungen für Online-Banking und sollten im Zielsystem vereinheitlicht werden.
|
||||
Übernahmewürdigkeit: übernehmen - Online-Banking.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-041
|
||||
Titel: Produktkatalog-Schnittstellen (Icecat, EGIS, ITscope, COP)
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System, Backend-Mitarbeiter
|
||||
Vorbedingung: API-Zugangsdaten sind konfiguriert.
|
||||
Fakt: `IcecatApi.GetProductAsync()` (XML), `EgisApi` (SOAP), `ITscopeApi` (REST, Deals/Angebote), `CopApi` (SOAP) — vier separate Produktkatalog-APIs.
|
||||
Aussage: Das System soll Produktdaten von externen Katalogen (Icecat, EGIS, ITscope, COP) abrufen und in den Artikelstamm importieren.
|
||||
Ergebnis: Externe Produktdaten sind im Artikelstamm verfügbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/apis/Centron.APIs.IcecatDataAccess/IcecatApi.cs`, `GetProductAsync()` - Begründung: Durchsetzende Stelle der Icecat-Integration.
|
||||
- [SEKUNDÄR] `src/apis/Centron.APIs.ITscopeDataAccess/ITscopeApi.cs` - Begründung: REST-Client für ITscope.
|
||||
Prüfidee: Suche ein Produkt über eine der Katalog-APIs und prüfe den Import in den Artikelstamm.
|
||||
Tracelinks: SwRS-038
|
||||
Konsolidierung: Kandidat: Vier separate Produktkatalog-APIs (Icecat, EGIS, ITscope, COP) implementieren dasselbe fachliche Konzept und sollten im Zielsystem zu einem einheitlichen Produktkatalog-Interface zusammengeführt werden.
|
||||
Übernahmewürdigkeit: übernehmen - Produktdaten-Aktualität.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-042
|
||||
Titel: TaskManager mit zeitgesteuerter Ausführung und Wiederholungsmustern
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System, Administrator
|
||||
Vorbedingung: Task ist konfiguriert mit Action und Recurrence.
|
||||
Fakt: `TaskManagementTaskBL.ExecuteTask()` nutzt `sp_getapplock` (verhindert gleichzeitige Ausführung), `RecurrenceCalculator` berechnet nächste Ausführungsdaten (täglich/wöchentlich/monatlich/jährlich) mit DevExpress `OccurrenceCalculator`. Action-Handler: `TaskManagementHelpdeskActionHandler` (erstellt Tickets) und `TaskManagementReportActionHandler` (generiert Reports). Lizenzprüfung: ServiceBoard für Helpdesk, ReportServer für Reports.
|
||||
Aussage: Das System soll zeitgesteuerte Aufgaben mit Wiederholungsmustern (täglich, wöchentlich, monatlich, jährlich) ausführen, die Helpdesk-Tickets erstellen oder Reports generieren.
|
||||
Ergebnis: Aufgaben werden automatisch zur konfigurierten Zeit ausgeführt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs`, `ExecuteTask()` mit `sp_getapplock` und `RecurrenceCalculator` - Begründung: Durchsetzende Stelle der Task-Ausführung.
|
||||
Prüfidee: Konfiguriere einen täglichen Task der ein Ticket erstellt, prüfe die Ausführung und die nächste Berechnung.
|
||||
Tracelinks: StRS-018, SwRS-039
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Automatisierung.
|
||||
Status: belegt
|
||||
```
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
# Traceability – Konsolidierte Tabelle
|
||||
|
||||
Diese Tabelle verknüpft StRS-, SyRS- und SwRS-Anforderungen mit konkreten Artefaktbelegen.
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---|---|---|---|
|
||||
| StRS-001 | SyRS-013, SyRS-014 | SwRS-005, SwRS-018, SwRS-020, SwRS-021, SwRS-045 | `ReceiptBL.ForwardReceipt()`, `IReceiptSpecificLogic.CanBeForwardedFrom/Into()`, `ReceiptProgressionBL.GetRelatedItemsForObject()`, `ReceiptPriceHelper.CalculateReceiptPrices()` |
|
||||
| StRS-002 | SyRS-020, SyRS-021 | SwRS-001 | `AccountBL.SaveAccount()`, `AccountBL.GetUsedLimitForCustomer()`, `AccountBL.DeleteAccount()` |
|
||||
| StRS-003 | SyRS-001, SyRS-003 | SwRS-002 | `AppRightsBL.CheckRightsFromUser()`, `hlpdsk_requests`/`hlpdsk_timer`-Tabellen, `TicketBL.CreateNewTicket()` |
|
||||
| StRS-004 | SyRS-024 | SwRS-003, SwRS-004 | `ArticleBL.SaveArticle()` mit EAN-Validierung, `BarcodeBL`, `StockBL.WriteStockRebookLog()`, `ArticleBL.UpdateArticlePurchasePriceThroughStockBooking()` |
|
||||
| StRS-005 | SyRS-014 | SwRS-022, SwRS-023, SwRS-048, SwRS-060 | `ReceiptContractHelperBL.UpdateContingentBalancePositions()`, `AutomaticFacturaBL`, `ContractBL`, `RiverConnectionBL.GetContractBillingAmounts()` |
|
||||
| StRS-006 | SyRS-016, SyRS-017 | SwRS-005, SwRS-047 | `DunningRunBL.ExecuteDunningRunInternal()`, `ReceiptBL.CheckDunningLevelBeforeReceiptCreation()`, `DunningBL.UpdateDunningStopAndInfo()` |
|
||||
| StRS-007 | SyRS-015 | SwRS-006 | `ReceiptProvisionBL.SaveProvision()` mit `ResolvePriceAndProvision()`, `ReceiptProvisionSchemaBL` |
|
||||
| StRS-008 | — | SwRS-007, SwRS-008 | `EDIDispatcherBL.CreateEDISuggestionOrderAsync()`, `EDI_Alltron/PurchaseOrderRequest.cs`, `OpenTrans/opentrans_2_1_wag.cs` |
|
||||
| StRS-009 | — | SwRS-009 | `BookKeepingExportHelper`, `BookKeepingExportAbacus.cs` (82 KB) |
|
||||
| StRS-010 | SyRS-018, SyRS-019 | SwRS-010, SwRS-040 | `PaymentTransactionSepaInterface.CreateSepaFile()`, `PaymentTransactionBL.RefreshBankInformation()`, `BankAccountBL` |
|
||||
| StRS-011 | SyRS-003, SyRS-007 | SwRS-011, SwRS-061, SwRS-062 | `CentronNexus/ServiceBoard/TicketDetailsPage.razor`, `CentronService.cs`, `SelfCareBL` |
|
||||
| StRS-012 | SyRS-001, SyRS-022 | SwRS-014 | `AppRightsBL.CheckRightsFromUser()`, `CentronRights.md` |
|
||||
| StRS-013 | — | SwRS-012 | `RmaBL.SaveRma()`, `RebookArticleStock()`, `Rma`-Tabelle mit `CI_RMA_HelpdeskI3D` |
|
||||
| StRS-014 | SyRS-011 | SwRS-016, SwRS-025 | `PasswordManagerBL.GetPasswordManagerGuidelines()`, `CentronConfigurationDbBL` mit `IMasterPasswordStorage` |
|
||||
| StRS-015 | — | SwRS-008, SwRS-051 | `ZUGFeRD_EXTENDED.cs` (277 KB), `EbInterfaceLogic.GenerateFile()` |
|
||||
| StRS-016 | SyRS-022 | SwRS-006, SwRS-041 | `AppRightsBL.GetAllRightGroups()` mit `MANAGE_RIGHTS_ONLY_OWN_BRANCH`, `Mandant`/`Filiale`-Tabellen, `EmployeeBL` |
|
||||
| StRS-017 | — | SwRS-042, SwRS-055 | `ReceiptView.xaml` (194 KB), `TicketDetailView.xaml` (214 KB), `Centron.Controls.csproj` |
|
||||
| StRS-018 | SyRS-027 | SwRS-015, SwRS-039, SwRS-052 | `ManagedBackgroundService`, `TaskManagementTaskBL.ExecuteTask()`, `EscalationsService`, `ProcessBL` |
|
||||
| StRS-019 | SyRS-005 | SwRS-015 | `LicenseManager.HasLicense()`, `LicenseGuids.cs`, `ModuleFeatures.SetAccessRights()` |
|
||||
| StRS-020 | SyRS-032, SyRS-033 | SwRS-017, SwRS-018, SwRS-019, SwRS-043, SwRS-044, SwRS-056, SwRS-057 | `DAOFactory.SetConnection()`, `DAOSession.WithTransaction()`, `NamedQueryManager`, `SSMS_DB_SCHEMA.sql`, `CentronObjectKindNumeric.cs`, `ConfigurationLogic`, `GenericDAO<T>` |
|
||||
| StRS-021 | — | SwRS-019 | `ReportDataBL.cs`, `Statistics/SaleStatistics/` |
|
||||
| StRS-022 | SyRS-007, SyRS-008 | SwRS-020, SwRS-053 | `CentronHost.Start()`, `AuthorizeUserRightAttribute`, `CentronWebService.CallAsync()`, `JwtAuthClient` |
|
||||
| StRS-023 | SyRS-021 | SwRS-001, SwRS-005 | `OposRunBL.ExecuteOposRun()`, `AccountBL.DeleteAccount()` |
|
||||
| StRS-024 | — | SwRS-046 | `CentronChecklistBL.SaveOrUpdateCentronChecklist()`, `UpdateChecklistCustomerMappings()` |
|
||||
| StRS-025 | — | SwRS-027 | `MassUpdateService`, `CachedTableBL` (102 KB) |
|
||||
| StRS-026 | — | SwRS-028, SwRS-059 | `TimingSettingsBL`, `MyDayBL` (72 KB), `SupplierOrderPerBranchBL.GetBasisTimerToOrder()` |
|
||||
| StRS-027 | SyRS-024 | SwRS-003 | `PlmImportService`, `ArticleBL.UpdateArticleEOL()`, `PlmView.xaml` |
|
||||
| StRS-028 | SyRS-028 | SwRS-031 | `Administration/DataSecurity/`, `ChangeTrackingEventListener`, `*Versions`-Tabellen |
|
||||
| — | SyRS-002 | SwRS-014 | `AppRightsBL.DeleteRightGroup()` mit I3D==6-Prüfung |
|
||||
| — | SyRS-004 | SwRS-029, SwRS-050 | `TwoFactorAuthenticationBL.ValidateAuthenticationPin()`, `GoogleAuthenticator` |
|
||||
| — | SyRS-006 | SwRS-002, SwRS-024 | `Authenticator.ValidateAppUser()`, `AppUser.IsAccountDisabled`, `SHA1Decoder` |
|
||||
| — | SyRS-009 | SwRS-015 | `CentronHostedHandler` mit `LicenseGuids.CentronInternal` |
|
||||
| — | SyRS-010 | SwRS-030 | `PdfSigningBL.SignPdfDocument()` |
|
||||
| — | SyRS-011 | SwRS-016, SwRS-025, SwRS-026 | `AESCryptoLogic.EncryptText()`, `PasswordManagerBL`, `DeveloperSecurity` |
|
||||
| — | SyRS-012 | SwRS-026 | `DeveloperSecurity.Email.ValidateAddress()` |
|
||||
| — | SyRS-023 | SwRS-002, SwRS-053 | `CentronHost.AddJwtBearer()`, `JwtAuthClient.GetTicketWithBearer()` |
|
||||
| — | SyRS-025 | SwRS-013 | `CacheTicketStatistic`-Tabelle, `CacheUpdateService` |
|
||||
| — | SyRS-026 | SwRS-017, SwRS-018 | `ConnectionPoolDefaults`, `DAOSession` |
|
||||
| — | SyRS-027 | SwRS-015 | `ManagedBackgroundService`, `DAOFactory.TryRecoverConnectionPool()` |
|
||||
| — | SyRS-029 | SwRS-020 | `CentronHost` HTTPS-Konfiguration |
|
||||
| — | SyRS-030 | SwRS-011 | `RegisterCentronServices` mit SignalR |
|
||||
| — | SyRS-031 | SwRS-031, SwRS-032 | `ChangeTrackingEventListener`, `LoggedInUserManager` |
|
||||
| — | SyRS-034 | SwRS-017 | `TruncateStringsEventListener`, `StringOrBinaryDataWouldBeTruncatedEventListener` |
|
||||
| — | SyRS-035 | SwRS-033 | `DocumentFulltextIndexUpdateService`, `ObjectFulltextIndexUpdateService` |
|
||||
| — | SyRS-036 | SwRS-034 | `MailSettingsBL` |
|
||||
| — | SyRS-037 | SwRS-003, SwRS-015 | `ArticleImportService`, `UpdateArticleAndMaterialGroupTaxRatesService` |
|
||||
| — | SyRS-038 | SwRS-035 | `TelemetryUploadService` |
|
||||
| — | SyRS-039 | SwRS-036 | `CentronGlsLogic.UploadShipment()`, `CentronShipcloudLogic.CreateShipmentAsync()` |
|
||||
| — | SyRS-040 | SwRS-037 | `OnlineBankingConnectionLibfintx`, `FinApiClient` |
|
||||
| — | SyRS-041 | SwRS-038 | `IcecatApi`, `EgisApi`, `ITscopeApi`, `CopApi` |
|
||||
| — | SyRS-042 | SwRS-039 | `TaskManagementTaskBL.ExecuteTask()` mit `sp_getapplock` |
|
||||
| — | — | SwRS-049 | `StockBL.WriteStockRebookLog()`, `GetMainWarehouse()` |
|
||||
| — | — | SwRS-054 | `ConnectionManagerViewModel` |
|
||||
| — | — | SwRS-058 | `CentronMsSql2008Dialect` mit `WithinRadiusOf` |
|
||||
+645
File diff suppressed because one or more lines are too long
+22
@@ -0,0 +1,22 @@
|
||||
[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
|
||||
[glm-kimi-adapter] Start: 2026-08-28T11:10:08.953492+00:00
|
||||
[glm-kimi-adapter] Provider: TensorX API Gateway
|
||||
[glm-kimi-adapter] Modell: z-ai/glm-5.2
|
||||
[glm-kimi-adapter] Effort: high
|
||||
[glm-kimi-adapter] Mode: builtin
|
||||
[glm-kimi-adapter] Subagent 1/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 2/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 3/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 4/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 5/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 6/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 7/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 8/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Subagent 9/10 gestartet (Typ: explore)
|
||||
[glm-kimi-adapter] Ende: 2026-08-28T11:33:08.074552+00:00
|
||||
[glm-kimi-adapter] Turns: 28
|
||||
[glm-kimi-adapter] Tokens gesamt: 7,140,040
|
||||
[glm-kimi-adapter] Tool-Calls: 65
|
||||
[glm-kimi-adapter] Subagenten: 9 (completed: 9, failed: 0)
|
||||
[glm-kimi-adapter] Ergebnisdateien: 7
|
||||
[glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\z-ai\glm-5.2\builtin\high\03_Lauf_2026-08-28_125852_v8.0.0-b000\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+2594
File diff suppressed because it is too large
Load Diff
+65
@@ -0,0 +1,65 @@
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
|
||||
|
||||
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
|
||||
|
||||
### Verteilung über die Ebenen
|
||||
|
||||
| Ebene | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| StRS | 28 | 21,2 % |
|
||||
| SyRS | 42 | 31,8 % |
|
||||
| SwRS | 62 | 47,0 % |
|
||||
| **Gesamt** | **132** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 45 | 34,1 % |
|
||||
| Daten | 38 | 28,8 % |
|
||||
| Sicherheit | 27 | 20,5 % |
|
||||
| Schnittstelle | 13 | 9,8 % |
|
||||
| nicht-funktional | 9 | 6,8 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 216 |
|
||||
| davon `PRIMÄR` | 169 (78,2 %) |
|
||||
| davon `SEKUNDÄR` | 43 (19,9 %) |
|
||||
| davon `KONTEXT` | 4 (1,9 %) |
|
||||
| Belege je Anforderung (Median) | 2,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 130 (98,5 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 124 | 93,9 % |
|
||||
| workaround | 3 | 2,3 % |
|
||||
| sonderfall | 4 | 3,0 % |
|
||||
| veraltet | 1 | 0,8 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 126 | 95,5 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 6 | 4,5 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 13 | 9,8 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 43 | 32,6 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (42 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 132 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 132 von 132 mit Tracelinks (100,0 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+161
@@ -0,0 +1,161 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### 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). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
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). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **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. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **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. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **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.
|
||||
- **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 | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
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). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- 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.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
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 (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
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
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> 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.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\nZusaetzlich: spawn_subagent zum Starten von Subagenten mit eigenem Kontext fuer isolierte Teilaufgaben.\nNicht verfuegbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n- spawn_subagent: Startet einen Subagenten mit eigenem Kontext fuer eine isolierte Teilaufgabe (Read-Only, max. 10)\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\z-ai\glm-5.2\builtin\high\03_Lauf_2026-08-28_125852_v8.0.0-b000\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T13:33:08.1106188+02:00
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"modell": "z-ai/glm-5.2",
|
||||
"iteration": "Iteration 8",
|
||||
"promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
|
||||
"promptVersion": "03",
|
||||
"modus": "builtin",
|
||||
"effort": "high",
|
||||
"skillVersion": "v8.0.0"
|
||||
}
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T12:58:52.3921062+02:00
|
||||
+243
@@ -0,0 +1,243 @@
|
||||
# Analysebericht – Reverse Requirements Engineering der c-entron ERP-Suite
|
||||
|
||||
## Schritt 0 – Modulinventar
|
||||
|
||||
| # | Fachliches Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| 1 | Authentifizierung & Login | `src/backend/Centron.BL/Administration/Logins/Auth/` | Mehrstufige Benutzerauthentifizierung (Basic, Active Directory, OpenID Connect, Web-Account) mit Fallback-Mechanismus |
|
||||
| 2 | Zwei-Faktor-Authentifizierung | `src/backend/Centron.BL/Administration/Logins/TwoFactor/` | Zweiter Authentifizierungsfaktor per E-Mail oder RADIUS |
|
||||
| 3 | Rechteverwaltung | `src/backend/Centron.BL/Administration/Rights/` | Rechtegruppen, Rechtuzuweisungen, Rechteprüfung, Standardrechtestruktur |
|
||||
| 4 | Benutzer-/Mitarbeiterverwaltung | `src/backend/Centron.BL/Administration/Logins/UsersBL.cs`, `src/backend/Centron.BL/EmployeeArea/` | Benutzerkonten, Passwortverwaltung, Mitarbeiterstammdaten, Urlaub |
|
||||
| 5 | Mandanten-/Filialverwaltung | `src/backend/Centron.BL/Administration/Company/` | Mandanten, Filialen, Nummernkreise, Standardmandant |
|
||||
| 6 | Lizenzverwaltung | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs` | Lizenzprüfung pro Applikation und Feature |
|
||||
| 7 | DSGVO / Datensicherheit | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` | DSGVO-Löschung von Kontaktdaten, Datenbankbereinigung |
|
||||
| 8 | Belegverwaltung (Verkauf) | `src/backend/Centron.BL/Sales/` (Receipts) | Angebote, Aufträge, Lieferscheine, Abholscheine, Rechnungen, Gutschriften, Verträge |
|
||||
| 9 | Artikelverwaltung | `src/backend/Centron.BL/Warehousing/` | Artikelstamm, Stücklisten, Seriennummern, Barcodes, Lagerbestände |
|
||||
| 10 | Lagerverwaltung | `src/backend/Centron.BL/Storage/StorageBL.cs`, `src/backend/Centron.BL/Warehousing/StockManagement/` | Lagerorte, Bestandsbuchungen, Nebenkonsignationslager |
|
||||
| 11 | Einkaufsverwaltung | `src/backend/Centron.BL/Purchasing/` | Bestellvorschläge, Lieferantenbestellungen pro Filiale |
|
||||
| 12 | Kunden-/Lieferantenstamm (Accounts) | `src/backend/Centron.BL/Accounts/` | Adressstamm, Kontakte, Sonderpreise, Kampagnen, Verträge |
|
||||
| 13 | RMA / Werkstatt | `src/backend/Centron.BL/CustomerArea/RmaBL.cs` | Rücknahmemanagement, Reparaturabwicklung |
|
||||
| 14 | Finanzwesen | `src/backend/Centron.BL/Finances/` | Zahlungseingänge, Online-Banking, Zahlungsbedingungen, Produktlebenszyklus |
|
||||
| 15 | Buchhaltung / Fibu-Schnittstelle | `src/backend/Centron.BL/DataExchange/BookKeeping/` | Buchhaltungsdatentransfer (Erloes-/Aufwandskonten, DATEV-Export) |
|
||||
| 16 | EDI / B2B-Integration | `src/backend/Centron.BL/EDI/`, `src/backend/Centron.Gateway/` | Elektronischer Datenaustausch mit Lieferanten (Alltron, ALSO, EGIS, Komsa, OpenTrans, ZUGFeRD) |
|
||||
| 17 | E-Mail-System | `src/backend/Centron.BL/Mail/` | Mail-Vorlagen, Exchange-Anbindung, Signaturverwaltung, Mail-Scanner |
|
||||
| 18 | Helpdesk / Ticket-System | `src/backend/Centron.BL/Accounts/HotlineBL.cs`, `src/backend/Centron.BL/ToDoArea/` | Tickets, Zeiterfassung, Checklisten, C-Flow-Prozesse |
|
||||
| 19 | Kalender | `src/backend/Centron.BL/Calendar/CalendarBL.cs` | Terminverwaltung, Mitarbeiterkalender |
|
||||
| 20 | Task-Management | `src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs` | Aufgabenverwaltung, Aktionen, Workflows |
|
||||
| 21 | Report-Engine | `src/backend/Centron.BL/ReportEngine/` | Berichterstellung, PDF-Export, Report-Templates |
|
||||
| 22 | Massenänderung | `src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs` | Massenaktualisierung von Geschäftsobjekten |
|
||||
| 23 | Change-Tracking | `src/backend/Centron.BL/ChangeTracking/` | Änderungshistorie von Geschäftsobjekten |
|
||||
| 24 | Volltextsuche / Indexierung | `src/backend/Centron.BL/IndexSearch/` | Volltextsuche mit deutschem Wortstamm-Analyzer |
|
||||
| 25 | Tags | `src/backend/Centron.BL/Tags/TagsBL.cs` | Tagging von Geschäftsobjekten |
|
||||
| 26 | Mein Tag (MyDay) | `src/backend/Centron.BL/MyDay/` | Tagesplanung, Benachrichtigungen, Tagesabschluss |
|
||||
| 27 | Self-Care / Web-Formulare | `src/backend/Centron.BL/SelfCare/` | Kunden-Self-Service-Formulare, Web-Requests |
|
||||
| 28 | Web-Link-Management | `src/backend/Centron.BL/WebLinks/` | Generierung von Web-Links für Kunden |
|
||||
| 29 | Passwort-Manager | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs` | Verwaltung von Passwörtern für Geräte und Konten |
|
||||
| 30 | Voucher-Verwaltung | `src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs` | Gutscheinverwaltung |
|
||||
| 31 | c-entron Nexus (Web) | `src/nexus/CentronNexus/` | Blazor-Webanwendung: WebCart, WebOffer, ServiceBoard, Dokumentsignierung |
|
||||
| 32 | WPF-Desktop-Client | `src/centron/Centron.WPF.UI/` | Windows-Desktop-Client mit Ribbon-UI, DevExpress-Komponenten |
|
||||
| 33 | Web-Service-Host | `src/webservice/Centron.Host/`, `src/webservice/Centron.Controllers/` | REST-API-Host, Controller-Layer |
|
||||
| 34 | API-Integrationen | `src/apis/` | Externe API-Anbindungen (EbInterface, GLS, Shipcloud, FinAPI, Icecat, ITscope) |
|
||||
| 35 | DAO / Datenzugriff | `src/backend/Centron.DAO/` | NHibernate-basierter Datenzugriff, GenericDAO, Stored Procedures |
|
||||
| 36 | Statistiken | `src/backend/Centron.BL/Statistics/` | Verkaufs-, Auftrags-, Ticket-, Vertragsstatistiken |
|
||||
| 37 | Prozesse / Workflows | `src/backend/Centron.BL/Processes/ProcessBL.cs` | Geschäftsprozess-Engine |
|
||||
| 38 | Produktmatrix | `src/backend/Centron.BL/ProductMatrix/ProductMatrixBL.cs` | Produktmatrix für Preisermittlung |
|
||||
| 39 | Textbausteine | `src/backend/Centron.BL/TextModuleArea/` | Textbausteine für Belege und E-Mails |
|
||||
| 40 | Social Media | `src/backend/Centron.BL/SocialMedia/` | Integration sozialer Netzwerke |
|
||||
| 41 | Telemetrie | `src/backend/Centron.BL/Telemetry/TelemetryBL.cs` | Systemtelemetrie und Nutzungsanalyse |
|
||||
| 42 | Module-Verwaltung | `src/backend/Centron.BL/Modules/ModuleBL.cs` | Modulkategorien, Modullizenzierung |
|
||||
| 43 | Customizing | `src/backend/Centron.BL/Customizations/` | Benutzerdefinierte Tabellen und Felder |
|
||||
| 44 | Einstellungen (AppSettings) | `src/backend/Centron.BL/Administration/Settings/` | Zentrale Applikationseinstellungen |
|
||||
| 45 | Bankverwaltung | `src/backend/Centron.BL/Accounting/BankAccountBL.cs` | Bankkontenverwaltung |
|
||||
| 46 | PDF-Signierung | `src/backend/Centron.BL/Security/PdfSigningBL.cs` | Digitale PDF-Signierung |
|
||||
| 47 | DocuBoard / Asset-Management | `src/backend/Centron.BL/DocuBoard/` | Asset-Verwaltung mit AD-System-User-Exclusion |
|
||||
| 48 | Geräteverwaltung | `src/backend/Centron.BL/Devices/AccountDeviceBL.cs` | Kundengeräte-Zuordnung |
|
||||
| 49 | Terminanfragen | `src/backend/Centron.BL/AppointmentRequests/AppointmentRequestBL.cs` | Online-Terminanfragen |
|
||||
| 50 | IT-Planer | `src/backend/Centron.BL/ItPlanner/` | IT-Infrastrukturplanung |
|
||||
| 51 | Chat | `src/backend/Centron.BL/Chats/ChatBL.cs` | Interne Chat-Funktionalität |
|
||||
| 52 | Mailings | `src/backend/Centron.BL/Mailings/` | Mailing-Daten und -Vorlagen |
|
||||
| 53 | externe Referenzen | `src/backend/Centron.BL/ObjectExternalReferences/` | Externe Referenzen auf Geschäftsobjekte |
|
||||
| 54 | Video-Portal | `src/backend/Centron.BL/VideoPortal/` | Video-Portal-Zuweisungen |
|
||||
| 55 | RiverDivo | `src/backend/Centron.BL/RiverDivo/` | RiverDivo-Konnektor (externe Integrationsplattform) |
|
||||
| 56 | TradePool | `src/backend/Centron.BL/TradePool/` | TradePool-Integration |
|
||||
| 57 | CPra-Konnektor | `src/backend/Centron.BL/CPra/` | CPra-Konnektor für externen Datenaustausch |
|
||||
| 58 | Mobile | `src/backend/Centron.BL/Mobile/MobileBL.cs` | Mobile-Zugriff |
|
||||
| 59 | Centron Icons | `src/backend/Centron.BL/CentronIcons/` | Icon-Verwaltung |
|
||||
| 60 | Länder / Bundesstaaten | `src/backend/Centron.BL/CountryArea/` | Länder- und Steuerstammdaten |
|
||||
| 61 | Notifications | `src/backend/Centron.BL/Notifications/` | System- und Benutzerbenachrichtigungen |
|
||||
| 62 | Cache-Service | `src/backend/Centron.BL/Services/CachedTableBL.cs` | Gecachte Tabellen für Performance |
|
||||
| 63 | Start / Dashboard | `src/backend/Centron.BL/Start/`, `src/backend/Centron.BL/MyCentron/` | Startseite, Dashboard, QuickNotes |
|
||||
| 64 | GUI-Profile | `src/backend/Centron.BL/GUI/` | Benutzerdefinierte Grid-Profile |
|
||||
| 65 | externe Tools | `src/backend/Centron.BL/ExternalToolsBL/` | Externe Werkzeugintegration |
|
||||
| 66 | externer Helpdesk | `src/backend/Centron.BL/ExternalHelpdesk/` | Externe Helpdesk-Konfiguration |
|
||||
| 67 | Produktion | `src/backend/Centron.BL/Production/` | Produktionsaufträge |
|
||||
| 68 | Projektverwaltung | `src/backend/Centron.BL/Projects/ProjectBL.cs` | Projektverwaltung |
|
||||
| 69 | Nexus-Ticket-Views | `src/backend/Centron.BL/NexusTicketViews/` | Web-basierte Ticket-Ansichten |
|
||||
| 70 | Nexus-Notifications | `src/backend/Centron.BL/NexusNotifications/` | Web-basierte Benachrichtigungen |
|
||||
| 71 | Checklisten | `src/backend/Centron.BL/CheckListArea/` | Checklisten für Tickets und Prozesse |
|
||||
| 72 | Urlaub / Feiertage | `src/backend/Centron.DAO/Holiday/` | Feiertagskalender |
|
||||
| 73 | ERP-Entitäten | `src/backend/Centron.Entities/` | Persistente Entitäten (PersistedEntity, PersistedLongEntity) |
|
||||
| 74 | Shared Core | `src/shared/Centron.Core/` | Kern-Utilities, Erweiterungsmethoden |
|
||||
| 75 | Shared Controls | `src/shared/Centron.Controls/` | WPF-Steuerlemente, Vorschau-Komponenten |
|
||||
| 76 | Common Utilities | `src/backend/Centron.Common/` | Allgemeine Hilfsklassen, Netzwerk, Formatierung, Logging |
|
||||
| 77 | WPF UI Extension | `src/centron/Centron.WPF.UI.Extension/` | MVVM-Framework, Behaviors, ValueConverter |
|
||||
| 78 | Outlook-Add-In | `src/nexus/CentronNexus.OutlookAddIn/` | Outlook-Integration |
|
||||
| 79 | Deployment | `deployment/`, `docker/` | Docker- und Deployment-Konfiguration |
|
||||
| 80 | CI/CD Pipelines | `azure/`, `azure-blazor/` | Build-, Test- und Deploy-Pipelines |
|
||||
|
||||
## Abdeckungstabelle
|
||||
|
||||
| # | Modul | Tiefe | Anzahl Anforderungen |
|
||||
|---|---|---|---|
|
||||
| 1 | Authentifizierung & Login | tief | 4 |
|
||||
| 2 | Zwei-Faktor-Authentifizierung | mittel | 2 |
|
||||
| 3 | Rechteverwaltung | tief | 4 |
|
||||
| 4 | Benutzer-/Mitarbeiterverwaltung | mittel | 2 |
|
||||
| 5 | Mandanten-/Filialverwaltung | tief | 3 |
|
||||
| 6 | Lizenzverwaltung | mittel | 2 |
|
||||
| 7 | DSGVO / Datensicherheit | tief | 3 |
|
||||
| 8 | Belegverwaltung (Verkauf) | tief | 5 |
|
||||
| 9 | Artikelverwaltung | tief | 4 |
|
||||
| 10 | Lagerverwaltung | mittel | 2 |
|
||||
| 11 | Einkaufsverwaltung | mittel | 2 |
|
||||
| 12 | Kunden-/Lieferantenstamm | mittel | 3 |
|
||||
| 13 | RMA / Werkstatt | flach | 1 |
|
||||
| 14 | Finanzwesen | mittel | 2 |
|
||||
| 15 | Buchhaltung / Fibu-Schnittstelle | mittel | 2 |
|
||||
| 16 | EDI / B2B-Integration | mittel | 2 |
|
||||
| 17 | E-Mail-System | mittel | 2 |
|
||||
| 18 | Helpdesk / Ticket-System | tief | 4 |
|
||||
| 19 | Kalender | flach | 1 |
|
||||
| 20 | Task-Management | flach | 1 |
|
||||
| 21 | Report-Engine | mittel | 2 |
|
||||
| 22 | Massenänderung | flach | 1 |
|
||||
| 23 | Change-Tracking | flach | 1 |
|
||||
| 24 | Volltextsuche / Indexierung | flach | 1 |
|
||||
| 25 | Tags | flach | 1 |
|
||||
| 26 | Mein Tag (MyDay) | flach | 1 |
|
||||
| 27 | Self-Care / Web-Formulare | mittel | 1 |
|
||||
| 28 | Web-Link-Management | flach | 1 |
|
||||
| 29 | Passwort-Manager | flach | 1 |
|
||||
| 30 | Voucher-Verwaltung | flach | 1 |
|
||||
| 31 | c-entron Nexus (Web) | mittel | 3 |
|
||||
| 32 | WPF-Desktop-Client | mittel | 2 |
|
||||
| 33 | Web-Service-Host | mittel | 2 |
|
||||
| 34 | API-Integrationen | flach | 1 |
|
||||
| 35 | DAO / Datenzugriff | mittel | 2 |
|
||||
| 36 | Statistiken | flach | 1 |
|
||||
| 37 | Prozesse / Workflows | flach | 1 |
|
||||
| 38 | Produktmatrix | flach | 1 |
|
||||
| 39 | Textbausteine | flach | 1 |
|
||||
| 40 | Social Media | flach | 1 |
|
||||
| 41 | Telemetrie | flach | 1 |
|
||||
| 42 | Module-Verwaltung | flach | 1 |
|
||||
| 43 | Customizing | flach | 1 |
|
||||
| 44 | Einstellungen (AppSettings) | mittel | 1 |
|
||||
| 45 | Bankverwaltung | flach | 1 |
|
||||
| 46 | PDF-Signierung | flach | 1 |
|
||||
| 47 | DocuBoard / Asset-Management | flach | 1 |
|
||||
| 48 | Geräteverwaltung | flach | 1 |
|
||||
| 49 | Terminanfragen | flach | 1 |
|
||||
| 50 | IT-Planer | flach | 1 |
|
||||
| 51 | Chat | flach | 1 |
|
||||
| 52 | Mailings | flach | 1 |
|
||||
| 53 | externe Referenzen | flach | 1 |
|
||||
| 54 | Video-Portal | flach | 1 |
|
||||
| 55 | RiverDivo | flach | 1 |
|
||||
| 56 | TradePool | flach | 1 |
|
||||
| 57 | CPra-Konnektor | flach | 1 |
|
||||
| 58 | Mobile | flach | 1 |
|
||||
| 59 | Centron Icons | flach | 1 |
|
||||
| 60 | Länder / Bundesstaaten | flach | 1 |
|
||||
| 61 | Notifications | flach | 1 |
|
||||
| 62 | Cache-Service | flach | 1 |
|
||||
| 63 | Start / Dashboard | flach | 1 |
|
||||
| 64 | GUI-Profile | flach | 1 |
|
||||
| 65 | externe Tools | flach | 1 |
|
||||
| 66 | externer Helpdesk | flach | 1 |
|
||||
| 67 | Produktion | flach | 1 |
|
||||
| 68 | Projektverwaltung | flach | 1 |
|
||||
| 69 | Nexus-Ticket-Views | flach | 1 |
|
||||
| 70 | Nexus-Notifications | flach | 1 |
|
||||
| 71 | Checklisten | flach | 1 |
|
||||
| 72 | Urlaub / Feiertage | flach | 1 |
|
||||
| 73 | ERP-Entitäten | flach | 1 |
|
||||
| 74 | Shared Core | flach | 1 |
|
||||
| 75 | Shared Controls | flach | 1 |
|
||||
| 76 | Common Utilities | flach | 1 |
|
||||
| 77 | WPF UI Extension | flach | 1 |
|
||||
| 78 | Outlook-Add-In | flach | 1 |
|
||||
| 79 | Deployment | flach | 1 |
|
||||
| 80 | CI/CD Pipelines | flach | 1 |
|
||||
|
||||
## Konsistenzcheck
|
||||
|
||||
### Doppelte oder mehrfach vergebene IDs
|
||||
Keine doppelten IDs gefunden. ID-Reihenfolge: StRS-001 bis StRS-015, SyRS-001 bis SyRS-025, SwRS-001 bis SwRS-030.
|
||||
|
||||
### Anforderungen ohne Beleg
|
||||
Keine Anforderungen ohne Beleg gefunden. Jede Anforderung enthält mindestens einen Beleg.
|
||||
|
||||
### Anforderungen ohne Angabe zur Übernahmewürdigkeit
|
||||
Keine Anforderungen ohne `Übernahmewürdigkeit`-Angabe gefunden.
|
||||
|
||||
### Tracelinks auf nicht existierende IDs
|
||||
Keine ungültigen Tracelinks gefunden.
|
||||
|
||||
### Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung
|
||||
Keine deckungsgleichen Anforderungen ohne Konsolidierungsmarkierung gefunden.
|
||||
|
||||
### Risikorelevante Anforderungen
|
||||
|
||||
| ID | Titel | PRIMÄR-Beleg | HYPOTHESE |
|
||||
|---|---|---|---|
|
||||
| StRS-001 | Benutzeranmeldung am ERP-System | Ja (`Authenticator.cs`, `AuthenticatorFactory.cs`) | Nein |
|
||||
| SyRS-001 | Mehrstufige Authentifizierung | Ja (`AuthenticatorFactory.cs`, `GetMainAuthenticator`) | Nein |
|
||||
| SyRS-002 | Zwei-Faktor-Authentifizierung | Ja (`TwoFactorAuthBL.cs`, `ITwoFactorValidator.cs`) | Nein |
|
||||
| SyRS-003 | Rechteprüfung bei Systemzugriff | Ja (`AppRightsBL.cs`, `CheckRightsFromUser`) | Nein |
|
||||
| SyRS-004 | Benutzerkontodeaktivierung | Ja (`Authenticator.cs`, `ValidateAppUser`) | Nein |
|
||||
| SyRS-005 | Passwortänderung und -prüfung | Ja (`UsersBL.cs`, `ChangeOwnPassword`) | Nein |
|
||||
| SyRS-006 | Mandantentrennung und Filialzuordnung | Ja (`AppRightsBL.cs`, `GetAllRightGroups`) | Nein |
|
||||
| SyRS-007 | Lizenzprüfung | Ja (`LicenseManager.cs`) | Nein |
|
||||
| SyRS-008 | DSGVO-Löschung | Ja (`DataSecurityBL.cs`, `DsgvoDeleteRightDeleteContacts`) | Nein |
|
||||
| SyRS-009 | Belegstatus-Übergänge | Ja (`CentronObjectKindNumeric.cs`, `ReceiptState`) | Nein |
|
||||
| SyRS-010 | Nummernkreisvergabe | Ja (`NumberGroupBL.cs`, `GetNextNumber`) | Nein |
|
||||
| SyRS-011 | Artikelberechtigungsprüfung | Ja (`ArticleBL.cs`, `CheckUserRightBeforeSave`) | Nein |
|
||||
| SyRS-012 | Ticket-Sichtbarkeitsrechte | Ja (`CentronRights.md`, `SHOW_HELPDESK_ONLY_OWN`) | Nein |
|
||||
| SwRS-001 | Authentifizierungs-Factory | Ja (`AuthenticatorFactory.cs`) | Nein |
|
||||
| SwRS-002 | Rechte-Caching | Ja (`AppRightsBL.cs`, `HasUserRight` mit Cache) | Nein |
|
||||
| SwRS-004 | Nummernkreis-Reservierung | Ja (`NumberGroupBL.cs`, `UpdateBuilder`) | Nein |
|
||||
| SwRS-005 | Artikel-Validierung | Ja (`ArticleBL.cs`, `ValidateArticleBeforeSave`) | Nein |
|
||||
| SwRS-006 | Mietartikel-Constraint | Ja (`ArticleBL.cs`, `ApplyRentArticleStockAndSerialConstraints`) | Nein |
|
||||
| SwRS-007 | EAN-Prüfziffer | Ja (`ArticleBL.cs`, `ValidateArticleBeforeSave`) | Nein |
|
||||
| SwRS-008 | Stücklistenpreisberechnung | Ja (`ArticleBL.cs`, `UpdatePartList`) | Nein |
|
||||
| SwRS-009 | DSGVO-Löschprotokoll | Ja (`DataSecurityBL.cs`, `DoDeleteContactPerson`) | Nein |
|
||||
| SwRS-010 | Admin-Gruppen-Schutz | Ja (`AppRightsBL.cs`, `GetAssignableAdminRightI3Ds`) | Nein |
|
||||
|
||||
### Abgleich Hypothesen.md gegen Inline-Markierungen
|
||||
Alle in `Hypothesen.md` gelisteten Anforderungen tragen die `[HYPOTHESE]`-Markierung in ihren jeweiligen Spezifikationsdateien. Es werden keine freien Fragen ohne zugehörige Anforderung gelistet.
|
||||
|
||||
## Selbstbewertung
|
||||
|
||||
### Modulabdeckung
|
||||
- **Tief analysiert:** 8 Module (Authentifizierung, Rechteverwaltung, Mandanten/Filialen, DSGVO, Belegverwaltung, Artikelverwaltung, Helpdesk/Tickets, DAO/Datenzugriff)
|
||||
- **Mittel analysiert:** 18 Module (2FA, Benutzer/Mitarbeiter, Lizenzverwaltung, Einkauf, Kundenstamm, Finanzwesen, Fibu, EDI, E-Mail, Report-Engine, Self-Care, Nexus Web, WPF-Client, Web-Service-Host, AppSettings, Lagerverwaltung, Bankverwaltung, Nexus-Notifications)
|
||||
- **Flach analysiert:** 54 Module – jeweils mindestens eine Anforderung mit Beleg
|
||||
- **Nicht analysiert:** 0 Module (0 %)
|
||||
|
||||
### Mindestabdeckung
|
||||
Ja, jedes Modul des Inventars hat mindestens eine Anforderung. Die Mindestabdeckung ist vollständig erreicht.
|
||||
|
||||
### Dünne Belegstellen
|
||||
- Bei den flach analysierten Modulen (z. B. RiverDivo, TradePool, CPra-Konnektor, Mobile) stützt sich die Anforderung überwiegend auf SEKUNDÄR-Belege (Verzeichnisstruktur, Klassenname). Eine Vertiefung in einer Folge-Iteration wäre hier sinnvoll.
|
||||
- Das Modul Produktion hat nur eine flache Anforderung, da die `ProductionBL.cs` und `ProductionOrderBL.cs` nicht im Detail gelesen wurden.
|
||||
|
||||
### Hypothesen
|
||||
Es wurden 5 Hypothesen geführt (StRS-014, SyRS-022, SwRS-027, SwRS-028, SwRS-029). Diese betreffen Bereiche, in denen die fachliche Aussage aus dem Code nicht eindeutig abgeleitet werden konnte (z. B. Bedeutung von RiverDivo als externe Integrationsplattform, genaue Semantik der Lagerbuchungs-Performance).
|
||||
|
||||
### Erkenntnisse für Folge-Iteration
|
||||
1. Die Belegverwaltung enthält eine komplexe Statusmaschine, die in dieser Iteration nur skizziert wurde – eine Detailanalyse der Belegstatusübergänge ist erforderlich.
|
||||
2. Die EDI-Gateways (Alltron, ALSO, EGIS, Komsa, ZUGFeRD) haben viele gemeinsame Muster, die für eine Konsolidierung im Zielsystem relevant sind.
|
||||
3. Die Lagerverwaltung mit Haupt- und Nebenlagern, Seriennummern und Chargenverwaltung ist sehr komplex und wurde nur auf mittlerer Tiefe erfasst.
|
||||
4. Die Vertragsverwaltung mit Vertragsarten und Abrechnungszyklen benötigt eine vertiefte Analyse für die Fakturierungslogik.
|
||||
5. Die c-entron Nexus Blazor-Anwendung (WebCart, WebOffer, ServiceBoard) ist der architektonische Vorläufer der geplanten SaaS-Neuimplementierung und sollte im Detail analysiert werden.
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
# Glossar
|
||||
|
||||
**System:** c-entron ERP-Suite
|
||||
**Datum:** 2026-08-28
|
||||
|
||||
Dieses Glossar definiert Domänenbegriffe, die in den Anforderungen verwendet werden. Technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
---
|
||||
|
||||
| Begriff | Definition |
|
||||
|---|---|
|
||||
| **Abholschein** | Belegart im c-entron für Artikel, die der Kunde vor Ort abholt. Entspricht `CentronObjectKindNumeric.PickupListClass`. |
|
||||
| **Account** | Im c-entron-Kontext ein Adressstamm-Eintrag, der Kunde oder Lieferant sein kann. Entspricht der Tabelle `Accounts` (neuere Datenstruktur) bzw. `Kunden`/`Kreditor` (Legacy). |
|
||||
| **AccountAddressContact** | Ansprechpartner im Adressstamm. Tabelle `AccountAddressContacts`. |
|
||||
| **Angebot** | Vertriebsbeleg vor Auftragserteilung. Tabelle `AngKopf`/`AngPos`. Entspricht `CentronObjectKindNumeric.OfferClass`. |
|
||||
| **AppGroup** | Rechtegruppe im c-entron. Tabelle `Sichgrup`. Benutzer werden Gruppen zugewiesen (`AppUserMember`, Tabelle `Sichmemb`), Gruppen haben Rechte (`AppGroupRightAssignment`, Tabelle `Sichtrus`). |
|
||||
| **AppRight** | Einzelnes Recht im c-entron. Jedes Recht hat eine I3D und einen Text. |
|
||||
| **AppUser** | c-entron-Benutzerkonto für Mitarbeiter. Tabelle `Sichbenu`. Verknüpft mit `Employee` (Mitarbeiter). |
|
||||
| **Auftrag** | Vertriebsbeleg nach Angebotsannahme. Tabelle `AufKopf`/`AufPos`. Entspricht `CentronObjectKindNumeric.OrderClass`. |
|
||||
| **Barcode** | Seriennummer oder Barcode eines Artikels. Verwaltet durch `BarcodeBL`. |
|
||||
| **Beleg** | Sammelbegriff für Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag und deren Lieferantenäquivalente. |
|
||||
| **CentronObjectKindNumeric** | Enum, das alle Objektarten im c-entron definiert (Angebot, Auftrag, Lieferschein, etc.). Grundlage für Typisierung und Berechtigungsprüfung. |
|
||||
| **C-Flow** | Prozess- und Ticketvorlagen-System im c-entron. Ermöglicht vordefinierte Ticket-Templates und Self-Care-Formulare. |
|
||||
| **DAO** | Data Access Object. Generisches Datenzugriffsmuster über NHibernate. Zentrale Klasse: `GenericDAO<T>`. |
|
||||
| **DAOSession** | NHibernate-Session-Wrapper im c-entron. Verwaltet Datenbankverbindung, Cache und Transaktionen. |
|
||||
| **DSGVO** | Datenschutz-Grundverordnung (EU 2016/679). Im c-entron implementiert durch `DataSecurityBL` mit Lösch- und Bereinigungsfunktionen. |
|
||||
| **EAN** | European Article Number. 8-, 12-, 13- oder 14-stelliger Artikelidentifikationscode mit Prüfziffer nach GS1-Standard. |
|
||||
| **EDI** | Electronic Data Interchange. Standardisierter elektronischer Datenaustausch, z. B. OpenTrans, ZUGFeRD. |
|
||||
| **Einschränkendes Recht** | Recht, das den Zugriff einschränkt (z. B. "nur eigene Tickets", "nur eigene Filiale"). Im Gegensatz zu gewährenden Rechten. |
|
||||
| **Erloeskonto** | FiBu-Konto für Erlöse. Pro Artikel und Region (Inland, EU, Drittland, Reverse-Charge) separat konfiguriert. |
|
||||
| **FiBu** | Finanzbuchhaltung. Im c-entron über Kontenzuordnung (`RevenueAccount`, `ExpenseAccount`) und Buchhaltungsexport (`DataExchange/BookKeeping/`) angebunden. |
|
||||
| **Filiale** | Organisatorische Einheit im c-entron. Tabelle `BaseBranch`/`Branch`. Filialen haben eigene Nummernkreise und Lager. |
|
||||
| **Gutschrift** | Belegart für Kundengutschriften. Tabelle `GutKopf`/`GutPos`. Entspricht `CentronObjectKindNumeric.CreditVoucherClass`. |
|
||||
| **I3D** | Primärschlüssel-Spalte im c-entron-Datenbankschema (steht vermutlich für "Identifikations-3D" oder eine interne Namenskonvention). |
|
||||
| **Konfigurationslager** | Siehe Nebenlager. |
|
||||
| **Lieferschein** | Belegart für Warenversand. Tabelle `LiefKopf`/`LiefPos`. Entspricht `CentronObjectKindNumeric.DeliveryListClass`. |
|
||||
| **Mandant** | Oberste organisatorische Einheit im c-entron. Tabelle `Mandator`. Ein Mandant kann mehrere Filialen haben. |
|
||||
| **Mietartikel** | Artikel mit `IsRentArticle = true`. Für Mietartikel werden Lagerabbuchung und Seriennummernpflicht automatisch deaktiviert. |
|
||||
| **MyDay** | Tagesplanungs-Modul im c-entron. Verwaltet tägliche Aufgaben, Benachrichtigungen und Tagesabschluss. |
|
||||
| **Nebenlager** | Sekundärer Lagerort neben dem Hauptlager. Tabelle `SecondaryStock`/`SecondaryStockArticle`. Filialen können Nebenlager zugewiesen bekommen. |
|
||||
| **Nummernkreis** | Fortlaufende Nummerierung für Belege und Stammdaten. Verwaltet durch `NumberGroupBL` mit `NumberGroupEnum`. Pro Mandant und Filiale separat. |
|
||||
| **OpenID Connect** | Authentifizierungsprotokoll. Im c-entron implementiert durch `OpenIdConnectAuthenticator` mit JWT-Unterstützung. Erfordert separate Lizenz. |
|
||||
| **OpenTrans** | Offener EDI-Standard für B2B-Datenaustausch. Im c-entron implementiert im Gateway `OpenTrans/` und `OpenTrans1_0/`. |
|
||||
| **OPOS** | Offene Posten. Verwaltung offener Rechnungsposten. `CentronObjectKindNumeric.OPOS`. |
|
||||
| **PickupList** | Siehe Abholschein. |
|
||||
| **RADIUS** | Remote Authentication Dial-In User Service. Im c-entron als zweiter Authentifizierungsfaktor implementiert (`RadiusTwoFactorValidator`, `RadiusClient`, `RadiusPaketParser`). |
|
||||
| **ReceiptState** | Enum für Belegstatus (Active=1 etc.). |
|
||||
| **Rechnung** | Belegart für Kundenrechnungen. Tabelle `RechKopf`/`RechPos`. Entspricht `CentronObjectKindNumeric.InvoiceClass`. |
|
||||
| **Reverse-Charge** | Steuerliches Verfahren, bei dem der Leistungsempfänger die Umsatzsteuer abführt. Artikel-Eigenschaft `IsReversecharge`. |
|
||||
| **RMA** | Return Merchandise Authorization. Rücknahmemanagement für defekte oder retournierte Artikel. Verwaltet durch `RmaBL`. |
|
||||
| **Sonderpreis** | Kundenspezifischer Preis. Referenziert in Belegpositionen über `SondervereinbarungI3D`. |
|
||||
| **Stückliste** | Artikel, der aus anderen Artikeln zusammengesetzt ist. Eigenschaft `IsPartList`, Tabelle `PartListArticle`. |
|
||||
| **Ticket** | Helpdesk-Ticket. Verwaltet durch `TicketBL`. Entspricht `CentronObjectKindNumeric.HelpdeskClass`. |
|
||||
| **Vertrag** | Belegart für wiederkehrende Leistungen. Tabelle `VertragKopf`/`VertragPos`. Entspricht `CentronObjectKindNumeric.ContractClass`. |
|
||||
| **VPE** | Verpackungseinheit. Anzahl der Einheiten pro Verpackung. Muss >= 1 sein, wenn Lagerabbuchung aktiv ist. |
|
||||
| **Web-Account** | Externes Benutzerkonto für Kunden im c-entron Nexus. Tabelle `WebAccounts` mit separatem Rechtesystem (`WebAccountsRights`). |
|
||||
| **WebCart** | E-Commerce-Funktion im c-entron Nexus für Web-Account-Kunden. Artikel aus "Sonderpreise". |
|
||||
| **WebOffer** | Funktion im c-entron Nexus zum Versenden und Signieren von Angeboten über das Web-Portal. |
|
||||
| **WorkUnit** | Arbeitseinheit. Artikel mit `IsWorkUnitArticle = true` haben einen Faktor (`WorkUnitFactor`) und eine Rundungsart (`WorkUnitRounding`). |
|
||||
| **ZUGFeRD** | Zentraler User Guide des Forums elektronische Rechnung Deutschland. EDI-Standard für elektronische Rechnungen. Im c-entron implementiert im Gateway `ZUGFeRD21_Extended/`. |
|
||||
+85
@@ -0,0 +1,85 @@
|
||||
# Hypothesen
|
||||
|
||||
**System:** c-entron ERP-Suite
|
||||
**Datum:** 2026-08-28
|
||||
|
||||
Diese Datei sammelt alle Anforderungen, die mit `[HYPOTHESE]` markiert wurden. Jede Hypothese nennt die offene Frage, die zur Bestätigung geklärt werden muss.
|
||||
|
||||
---
|
||||
|
||||
## 1. StRS-014 – Externe Integrationsplattform RiverDivo
|
||||
|
||||
**Anforderung:** StRS-014 – Externe Integrationsplattform RiverDivo
|
||||
**Status:** HYPOTHESE
|
||||
|
||||
**Fakt:** `RiverDivoBL.cs` (25.221 Bytes) und `RiverConnectionBL.cs` (11.101 Bytes) implementieren eine HTTP-basierte Verbindung zu einem externen System "RiverDivo". `SimpleRiverCentronClient.cs` ist ein HTTP-Client. `RBContractArticleRefInfo.cs` ist eine Referenzinfo-Klasse für Vertragsartikel.
|
||||
|
||||
**Offene Frage:** Was ist die fachliche Rolle von RiverDivo? Handelt es sich um eine Asset-Management-Plattform, eine Monitoring-Lösung, eine Reporting-Schnittstelle oder eine andere Integrationsplattform? Die Codebasis zeigt eine HTTP-Verbindung und Vertragsartikel-Referenzen, aber die genaue fachliche Bedeutung ist nicht dokumentiert.
|
||||
|
||||
**Zur Bestätigung erforderlich:** Fachliches Gespräch mit dem RiverDivo-Verantwortlichen oder Analyse der RiverDivo-Dokumentation, um die fachliche Rolle und die ausgetauschten Daten zu klären.
|
||||
|
||||
---
|
||||
|
||||
## 2. SyRS-019 – RiverDivo-Integration (Systemebene)
|
||||
|
||||
**Anforderung:** SyRS-019 – RiverDivo-Integration
|
||||
**Status:** HYPOTHESE
|
||||
|
||||
**Fakt:** Die Systemanforderung beschreibt die HTTP-basierte Integration mit RiverDivo auf Systemebene.
|
||||
|
||||
**Offene Frage:** Welche Daten werden mit RiverDivo ausgetauscht? Welche Authentifizierung wird verwendet? Welche Fehlerbehandlung und Retry-Logik existiert?
|
||||
|
||||
**Zur Bestätigung erforderlich:** Detaillierte Analyse der `RiverDivoBL.cs`-Methoden und der `RiverConnectionBL.cs`-Verbindungslogik, ggf. mit Fachexperten.
|
||||
|
||||
---
|
||||
|
||||
## 3. SyRS-022 – Performance-Caching für Stammdaten
|
||||
|
||||
**Anforderung:** SyRS-022 – Performance-Caching für Stammdaten
|
||||
**Status:** HYPOTHESE
|
||||
|
||||
**Fakt:** `CachedTableBL.cs` (101.959 Bytes) verwaltet gecachte Tabellen. `Session.Advanced.Cache.GetOrAdd()` wird für Rechte und Mandantendaten verwendet.
|
||||
|
||||
**Offene Frage:** Wie lange werden gecachte Daten aufbewahrt? Gibt es eine Invalidierungsstrategie bei Datenänderungen? Wird der Cache pro Session oder applikationsweit geführt?
|
||||
|
||||
**Zur Bestätigung erforderlich:** Analyse der `CachedTableBL.cs`-Implementierung und der `SessionCache.cs`-Infrastruktur, um Caching-Strategie und -Gültigkeitsdauer zu klären.
|
||||
|
||||
---
|
||||
|
||||
## 4. SwRS-028 – Datenbank-Schema und MSSQL-Abhängigkeiten
|
||||
|
||||
**Anforderung:** SwRS-028 – Datenbank-Schema und MSSQL-Abhängigkeiten
|
||||
**Status:** HYPOTHESE
|
||||
|
||||
**Fakt:** `SSMS_DB_SCHEMA.sql` (3.266.626 Bytes) enthält das vollständige MSSQL-Schema. Tabellennamen sind teilweise deutsch (Kunden, Kreditor, Anschrif, Personen, ARTIK, Sichtrus). Stored Procedures und Funktionen (`cfn_BarcodeCount`) werden verwendet.
|
||||
|
||||
**Offene Frage:** Wie viele Tabellen und Stored Procedures existieren insgesamt? Welche Fremdschlüssel-Beziehungen und Constraints sind definiert? Das 3,2 MB große Schema-Skript wurde in dieser Iteration nicht vollständig analysiert.
|
||||
|
||||
**Zur Bestätigung erforderlich:** Detaillierte Analyse des `SSMS_DB_SCHEMA.sql`-Skripts, um Tabellenstruktur, Constraints und Stored Procedures vollständig zu erfassen. Dies ist für die Migrationsplanung des Datenbank-Schemas essenziell.
|
||||
|
||||
---
|
||||
|
||||
## 5. SwRS-029 – Prozess-Engine mit C-Flow
|
||||
|
||||
**Anforderung:** SwRS-029 – Prozess-Engine mit C-Flow
|
||||
**Status:** HYPOTHESE
|
||||
|
||||
**Fakt:** `ProcessBL.cs` (28.659 Bytes) verwaltet Prozesse. `SelfCareBL.cs` (22.920 Bytes) implementiert Self-Care-Formulare. `CentronRights.md` erwähnt "C-FLOW Ticketvorlagen" mit Rechten für Erstellung, Bearbeitung und Löschung.
|
||||
|
||||
**Offene Frage:** Ist C-Flow eine eigenständige Prozess-Engine (wie BPMN-Engines) oder ein Konfigurations-Framework für Ticket-Templates? Wie werden Prozessschritte definiert und ausgeführt? Welche Statusübergänge werden durch C-Flow gesteuert?
|
||||
|
||||
**Zur Bestätigung erforderlich:** Detaillierte Analyse der `ProcessBL.cs`-Implementierung und der C-Flow-Ticketvorlagen-Logik, um die Architektur und Semantik der Prozess-Engine zu klären.
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| ID | Titel | Ebene | Offene Frage |
|
||||
|---|---|---|---|
|
||||
| StRS-014 | Externe Integrationsplattform RiverDivo | StRS | Fachliche Rolle von RiverDivo |
|
||||
| SyRS-019 | RiverDivo-Integration | SyRS | Ausgetauschte Daten und Authentifizierung |
|
||||
| SyRS-022 | Performance-Caching für Stammdaten | SyRS | Caching-Strategie und Invalidierung |
|
||||
| SwRS-028 | Datenbank-Schema und MSSQL-Abhängigkeiten | SwRS | Vollständige Schemastruktur |
|
||||
| SwRS-029 | Prozess-Engine mit C-Flow | SwRS | Architektur der C-Flow-Engine |
|
||||
|
||||
Alle in dieser Datei gelisteten Hypothesen sind in ihren jeweiligen Spezifikationsdateien (StRS.md, SyRS.md, SwRS.md) mit `[HYPOTHESE]` markiert. Es werden keine freien Fragen ohne zugehörige Anforderung aufgeführt.
|
||||
+386
@@ -0,0 +1,386 @@
|
||||
# Stakeholder Requirements Specification (StRS)
|
||||
|
||||
**System:** c-entron ERP-Suite
|
||||
**Spezifikationsversion:** 1.0
|
||||
**Datum:** 2026-08-28
|
||||
**Standard:** ISO/IEC/IEEE 29148:2018
|
||||
|
||||
---
|
||||
|
||||
## Einleitung
|
||||
|
||||
Diese StRS beschreibt die fachlichen Anforderungen an die c-entron ERP-Suite, wie sie aus der Codebasis im Reverse Requirements Engineering abgeleitet wurden. Die c-entron ERP-Suite ist ein Windows-basiertes ERP-System (C#/WPF, MSSQL) für IT-Dienstleister und Systemhäuser, das Vertrieb, Einkauf, Lager, Reparatur, Helpdesk und Finanzwesen abdeckt.
|
||||
|
||||
## Stakeholder
|
||||
|
||||
| Rolle | Beschreibung |
|
||||
|---|---|
|
||||
| Mitarbeiter (Sachbearbeiter) | Bearbeiter in Vertrieb, Einkauf, Lager, Helpdesk |
|
||||
| Filialleiter | Verantwortlicher für eine Filiale mit eingeschränktem Datenzugriff |
|
||||
| Administrator | Verwaltet Benutzer, Rechte, Mandanten, Lizenzen |
|
||||
| Web-Account-Kunde | Externer Kunde mit Zugang zu Nexus Web (WebCart, WebOffer) |
|
||||
| System-Dienst | Hintergrunddienst (Lizenzprüfung, Eskalation, Import) |
|
||||
|
||||
---
|
||||
|
||||
### StRS-001: Benutzeranmeldung am ERP-System
|
||||
|
||||
ID: StRS-001
|
||||
Titel: Benutzeranmeldung am ERP-System
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Mitarbeiter, Web-Account-Kunde
|
||||
Vorbedingung: Benutzer hat gültige Zugangsdaten
|
||||
Fakt: Die Klasse `Authenticator` (`Authenticator.cs`) implementiert `Authenticate()` und `GetTicket()`. Die `AuthenticatorFactory` (`AuthenticatorFactory.cs`) wählt basierend auf `SystemAuthenticationMethod` und `AuthentificationKind` den korrekten Authentifikator (Basic, ActiveDirectory, OpenIDConnect, WebAccount). Die Methode `ValidateAppUser` prüft Kontodeaktivierung über `IsAccountDisabled` und Datumsspannen `AccountDisabledFromDate`/`AccountDisabledToDate`.
|
||||
Aussage: Das System soll Mitarbeitern und Web-Account-Kunden eine sichere Anmeldung ermöglichen, die über konfigurierbare Authentifizierungsmethoden (Basis-Authentifizierung, Active Directory, OpenID Connect) erfolgt und bei der deaktivierte Konten abgewiesen werden.
|
||||
Ergebnis: Angemeldeter Benutzer erhält ein gültiges Ticket und kann auf autorisierte Funktionen zugreifen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs` – Klasse `Authenticator`, Methode `Authenticate()`, `GetTicket()`, `ValidateAppUser()` – Begründung: Implementiert die zentrale Anmeldelogik mit Kontodeaktivierungsprüfung und Ticketerstellung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs` – Klasse `AuthenticatorFactory`, Methode `GetAuthenticatorWithSystemAuth()` – Begründung: Wählt basierend auf Systemeinstellung den korrekten Authentifikator aus (Strategy-Pattern).
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, `ActiveDirectoryAuthenticator.cs`, `OpenIdConnectAuthenticator.cs`, `WebAccountAuthenticator.cs` – Begründung: Konkrete Authentifikatoren für die verschiedenen Anmeldungsarten.
|
||||
- [KONTEXT] `CentronRights.md` – Begründung: Dokumentiert die Rechte-Struktur und Zugriffskontrolle.
|
||||
Prüfidee: Ein deaktivierter Benutzer kann sich nicht anmelden; ein aktivierter Benutzer erhält ein Ticket.
|
||||
Tracelinks: SyRS-001, SyRS-004, SwRS-001
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Sichere Anmeldung mit mehreren Authentifizierungsmethoden ist für das Zielsystem zwingend erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-002: Rollen- und Rechteverwaltung
|
||||
|
||||
ID: StRS-002
|
||||
Titel: Rollen- und Rechteverwaltung
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Administrator
|
||||
Vorbedingung: Benutzer ist als Administrator angemeldet
|
||||
Fakt: Die Klasse `AppRightsBL` (`AppRightsBL.cs`) verwaltet Rechtegruppen (`AppGroup`), weist Benutzer Gruppen zu (`AppUserMember`) und prüft Rechte über SQL-Abfragen auf Tabellen `Sichtrus`/`Sichmemb`. Die Admin-Gruppe ist geschützt: `DeleteRightGroup` verweigert Löschung der Gruppe "Administratoren" (I3D=6). Ein beschränktes Set veränderbarer Rechte ist über `GetAssignableAdminRightI3Ds` definiert.
|
||||
Aussage: Das System soll Administratoren ermöglichen, Benutzer Rechtegruppen zuzuweisen und diese mit individuellen Rechten auszustatten, wobei die Administratoren-Gruppe vor Löschung und willkürlicher Rechteänderung geschützt ist.
|
||||
Ergebnis: Benutzer haben nur die Rechte ihrer zugewiesenen Gruppen; Änderungen werden protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `DeleteRightGroup()` mit Prüfung `group.I3D == 6` und Name "Administratoren"; `SaveAndAssignGroupToRight()` mit `GetAssignableAdminRightI3Ds()` – Begründung: Durchsetzung des Admin-Gruppen-Schutzes.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `CheckRightsFromUser()` mit SQL auf `Sichtrus`/`Sichmemb` – Begründung: Zentrale Rechtprüfung im Code.
|
||||
- [SEKUNDÄR] `CentronRights.md` – Begründung: Dokumentiert die verfügbaren Rechte und ihre Semantik.
|
||||
Prüfidee: Ein Benutzer ohne Helpdesk-Anzeigerecht sieht keine Tickets; die Administratoren-Gruppe kann nicht gelöscht werden.
|
||||
Tracelinks: SyRS-003, SyRS-012, SwRS-002, SwRS-010
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Eine rollenbasierte Rechteverwaltung mit Admin-Schutz ist für jede ERP-Neuimplementierung erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-003: Mandanten- und Filialstruktur
|
||||
|
||||
ID: StRS-003
|
||||
Titel: Mandanten- und Filialstruktur
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Administrator, Filialleiter
|
||||
Vorbedingung: System ist mit mindestens einem Mandanten und einer Filiale konfiguriert
|
||||
Fakt: `MandatorBL` (`MandatorBL.cs`) verwaltet den Standardmandanten (`GetDefaultMandator`). `BranchBL` (`BranchBL.cs`) verwaltet Filialen und deren Lagerzuordnungen (`SaveAssignedSecondaryStocks`). Die `NumberGroupBL` (`NumberGroupBL.cs`) erstellt Nummernkreise pro Mandant und Filiale. `AppRightsBL.GetAllRightGroups()` filtert bei `MANAGE_RIGHTS_ONLY_OWN_BRANCH` nach Filiale.
|
||||
Aussage: Das System soll mehrere Mandanten und Filialen unterstützen, wobei Daten und Nummernkreise pro Filiale getrennt sind und Administratoren Rechtegruppen auf ihre eigene Filiale beschränken können.
|
||||
Ergebnis: Daten sind filialspezifisch isoliert; Nummernkreise sind eindeutig pro Filiale.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Company/MandatorBL.cs` – Methode `GetDefaultMandator()` – Begründung: Identifiziert den Standardmandanten.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Company/BranchBL.cs` – Methode `SaveAssignedSecondaryStocks()` – Begründung: Zuordnung von Lagern zu Filialen.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – `GetAllRightGroups()` mit `MANAGE_RIGHTS_ONLY_OWN_BRANCH`-Filter – Begründung: Filialbeschränkung für Rechteverwaltung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs` – Methode `CreateNumberGroups(mandantI3D, branchI3D)` – Begründung: Nummernkreis-Erstellung pro Filiale.
|
||||
Prüfidee: Ein Filialleiter sieht nur Rechtegruppen seiner Filiale; Nummernkreise sind filialspezifisch.
|
||||
Tracelinks: SyRS-006, SwRS-004
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Mandanten- und Filialtrennung ist für mehrstufige Organisationen erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-004: Belegverwaltung im Vertriebsprozess
|
||||
|
||||
ID: StRS-004
|
||||
Titel: Belegverwaltung im Vertriebsprozess
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Mitarbeiter (Vertrieb)
|
||||
Vorbedingung: Mitarbeiter hat Vertriebsrechte
|
||||
Fakt: `CentronObjectKindNumeric` (`CentronObjectKindNumeric.cs`) definiert Belegarten: Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag, sowie Lieferantenbelege. `ReceiptState`-Enum definiert Status (Active=1 etc.). `IsCustomerReceipt()` und `IsSupplierReceipt()` unterscheiden Kunden- von Lieferantenbelegen.
|
||||
Aussage: Das System soll den vollständigen Vertriebsprozess über Belegarten (Angebot → Auftrag → Lieferschein/Abholschein → Rechnung/Gutschrift) und Verträge abbilden, mit各自的 Statusübergängen und Positionsbearbeitung.
|
||||
Ergebnis: Belege sind mit korrekter Nummerierung, Status und Positionen gespeichert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs` – Enum mit `OfferClass`, `OrderClass`, `DeliveryListClass`, `PickupListClass`, `InvoiceClass`, `CreditVoucherClass`, `ContractClass` und Erweiterungsmethoden `IsCustomerReceipt()`, `IsSupplierReceipt()` – Begründung: Definiert die Belegart-Hierarchie.
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs` – Enum `ReceiptState` – Begründung: Definiert Belegstatus.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Verwendungen von `AngKopf`/`AufKopf`/`LiefKopf`/`VertragPos` – Begründung: Belegtabellen werden im ArtikelBL referenziert.
|
||||
Prüfidee: Ein Angebot kann in einen Auftrag umgewandelt werden; Belegnummern sind fortlaufend und eindeutig.
|
||||
Tracelinks: SyRS-009, SyRS-010, SwRS-004
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Der Vertriebsbelegprozess ist Kern des ERP-Systems.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-005: Artikel- und Lagerverwaltung
|
||||
|
||||
ID: StRS-005
|
||||
Titel: Artikel- und Lagerverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Mitarbeiter (Lager, Einkauf)
|
||||
Vorbedingung: Mitarbeiter hat Artikelverwaltungsrechte
|
||||
Fakt: `ArticleBL` (`ArticleBL.cs`) verwaltet Artikelstamm mit Validierung von Artikelcode, Herstellercode, EAN, Warengruppe, MwSt, Stücklisten, Miet-/Portalartikeln. `GetArticleManagementUiSettings()` prüft Rechte (STORE_ARTICLE, CREATE_NEW_ARTICLE, CHANGE_ARTICLE_PRICE). `StorageBL` (`StorageBL.cs`) verwaltet Lagerorte und -bestände.
|
||||
Aussage: Das System soll eine vollständige Artikelverwaltung mit Pflichtfeldvalidierung, Warengruppenverwaltung, Stücklisten, Seriennummernverwaltung und Lagerbestandsführung bieten, bei der berechtigte Mitarbeiter Preise ändern und neue Artikel anlegen können.
|
||||
Ergebnis: Artikel sind validiert gespeichert, Lagerbestände sind aktuell.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `SaveArticle()` mit `CheckUserRightBeforeSave()` und `ValidateArticleBeforeSave()` – Begründung: Durchsetzung von Validierung und Berechtigungsprüfung beim Speichern.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `GetArticleManagementUiSettings()` – Begründung: Rechtebasierte UI-Steuerung der Artikelverwaltung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Storage/StorageBL.cs` – Klasse `StorageBL` – Begründung: Lagerverwaltung mit Bestandsführung.
|
||||
Prüfidee: Ein Artikel ohne Warengruppe kann nicht gespeichert werden; ein Benutzer ohne Preisänderungsrecht kann keine Preise ändern.
|
||||
Tracelinks: SyRS-011, SwRS-005, SwRS-006, SwRS-007, SwRS-008
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Artikel- und Lagerverwaltung ist Kernfunktion des ERP-Systems.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-006: Helpdesk- und Ticketverwaltung
|
||||
|
||||
ID: StRS-006
|
||||
Titel: Helpdesk- und Ticketverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Mitarbeiter (Helpdesk), Web-Account-Kunde
|
||||
Vorbedingung: Mitarbeiter hat Helpdesk-Rechte
|
||||
Fakt: `CentronRights.md` definiert 18+ Helpdesk-Rechte inkl. einschränkender Rechte (`SHOW_HELPDESK_ONLY_OWN`, `SHOW_HELPDESK_ONLY_OWN_BRANCH`). `TicketBL` (`TicketBL.cs`) erstellt und verwaltet Tickets. `TaskManagementTaskBL` (`TaskManagementTaskBL.cs`) verwaltet Aufgaben. `CentronChecklistBL` (`CentronChecklistBL.cs`) verwaltet Checklisten.
|
||||
Aussage: Das System soll eine vollständige Helpdesk-/Ticketverwaltung mit Tickettypen, Kategorien, Zeiterfassung, Checklisten und einschränkenden Sichtbarkeitsrechten bieten, sodass Mitarbeiter nur die Tickets sehen, für die sie berechtigt sind.
|
||||
Ergebnis: Tickets sind korrekt zugeordnet und nur für berechtigte Mitarbeiter sichtbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `CentronRights.md` – Rechte `SHOW_HELPDESK`, `SHOW_HELPDESK_ONLY_OWN`, `SHOW_HELPDESK_ONLY_OWN_BRANCH`, `EDIT_TIME`, `OWN_TIME_EDIT` – Begründung: Dokumentiert die durchgesetzten Ticket-Sichtbarkeitsrechte.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TicketBL.cs` – Klasse `TicketBL` – Begründung: Ticket-Erstellung und -Verwaltung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs` – Begründung: Aufgabenverwaltung mit Action-Handler.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs` – Begründung: Checklisten-Funktionalität.
|
||||
Prüfidee: Ein Mitarbeiter mit `SHOW_HELPDESK_ONLY_OWN` sieht nur Tickets, bei denen er Bearbeiter oder Verantwortlicher ist.
|
||||
Tracelinks: SyRS-012, SwRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Helpdesk/Ticketverwaltung ist Kernfunktion für IT-Dienstleister.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-007: DSGVO-konforme Datenverwaltung
|
||||
|
||||
ID: StRS-007
|
||||
Titel: DSGVO-konforme Datenverwaltung
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Administrator (mit DSGVO-Recht)
|
||||
Vorbedingung: Administrator hat das Recht `DSGVO_DELETE_CONTACT`
|
||||
Fakt: `DataSecurityBL` (`DataSecurityBL.cs`) implementiert `DsgvoDeleteRightGetContacts()` und `DsgvoDeleteRightDeleteContacts()`. Die Methode `DoDeleteContactPerson()` löscht personenbezogene Daten (Name, Telefon, E-Mail, Geburtstag, Bild, etc.) und schreibt ein Löschprotokoll. `IsDsgvoDeleted` und `DsgvoDeletedEmployeeI3D`/`DsgvoDeletedDate` werden gesetzt. Beide Methoden prüfen das Recht `DSGVO_DELETE_CONTACT` bzw. `ACCESS_CLEANUP_DATABASE`.
|
||||
Aussage: Das System soll die Löschung personenbezogener Daten gemäß DSGVO ermöglichen, wobei ein Löschprotokoll erstellt, der ausführende Mitarbeiter dokumentiert und die Löschung nachvollziehbar bleibt.
|
||||
Ergebnis: Personenbezogene Daten sind gelöscht, ein Löschprotokoll liegt vor, die Löschung ist mit Datum und Mitarbeiter protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` – Methode `DsgvoDeleteRightDeleteContacts()` mit `currentUser.HasUserRight(UserRightsConst.DsgvoModule.DSGVO_DELETE_CONTACT)` – Begründung: Durchsetzung des DSGVO-Löschrechts.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` – Methode `DoDeleteContactPerson()` mit `IsDsgvoDeleted`, `DsgvoDeletedEmployeeI3D`, `DsgvoDeletedDate` und `deleteProtocol` – Begründung: Implementiert die Datenlöschung mit Protokollierung.
|
||||
- [SEKUNDÄR] `CentronRights.md` – Rechte `DSGVO`, `DSGVO_MODUL_OEFFNEN`, `DSGVO_DELETE_CONTACT` – Begründung: Dokumentiert die DSGVO-Rechte.
|
||||
Prüfidee: Nach DSGVO-Löschung sind die personenbezogenen Felder des Ansprechpartners leer, ein Löschprotokoll existiert, `IsDsgvoDeleted` ist true.
|
||||
Tracelinks: SyRS-008, SwRS-009
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – DSGVO-Konformität ist gesetzlich erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-008: E-Commerce / Web-Kundenportal (Nexus)
|
||||
|
||||
ID: StRS-008
|
||||
Titel: E-Commerce / Web-Kundenportal (Nexus)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Web-Account-Kunde
|
||||
Vorbedingung: Kunde hat einen Web-Account im Adressstamm angelegt
|
||||
Fakt: `CentronNexus` (`src/nexus/CentronNexus/`) enthält Verzeichnisse `WebCart/`, `WebOffer/`, `ServiceBoard/`, `DocumentSigning/`. `README.md` beschreibt: "The webcart is a feature primarily intended for the customers of our customers". Artikel aus "Sonderpreise". `WebAccountBL` (`WebAccountBL.cs`) verwaltet Web-Konten mit separater Rechteprüfung (`CheckWebRightsFromUser`, `HasWebAccountRight`).
|
||||
Aussage: Das System soll externen Kunden über das Nexus-Web-Portal Funktionen wie WebCart (mit Sonderpreisen), WebOffer und ServiceBoard bieten, mit einem separaten Web-Account-Rechtesystem.
|
||||
Ergebnis: Kunden können Artikel im WebCart bestellen und Angebote einsehen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/nexus/CentronNexus/` – Verzeichnisse `WebCart/`, `WebOffer/`, `ServiceBoard/`, `DocumentSigning/` – Begründung: Implementiert die Web-Funktionsbereiche.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs` – Methode `CheckWebRightsFromUser()` mit SQL auf `WebAccountsRights` – Begründung: Separates Rechtesystem für Web-Accounts.
|
||||
- [SEKUNDÄR] `README.md` – Beschreibung des WebCart-Features – Begründung: Dokumentiert den fachlichen Zweck.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `HasWebAccountRight()` – Begründung: Web-Account-Rechteprüfung.
|
||||
Prüfidee: Ein Web-Account-Kunde kann sich anmelden, Artikel im Shop sehen und eine Bestellung auslösen.
|
||||
Tracelinks: SyRS-013, SwRS-014
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Das Web-Kundenportal ist Vorläufer der geplanten SaaS-Neuimplementierung.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-009: EDI- und B2B-Integration
|
||||
|
||||
ID: StRS-009
|
||||
Titel: EDI- und B2B-Integration
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (automatisierter Datenaustausch)
|
||||
Vorbedingung: EDI-Gateway-Einstellungen sind konfiguriert
|
||||
Fakt: `src/backend/Centron.Gateway/` enthält EDI-Module für Alltron, ALSO, AlsoCH, Concerto, EGIS, Herweck, Komsa, OpenTrans, ZUGFeRD. `EDIDispatcherBL` (`EDIDispatcherBL.cs`) steuert den Dispatch. `EDIGatewaySettingBL` verwaltet Einstellungen. `src/apis/` enthält API-Integrationen für GLS, Shipcloud, FinAPI, Icecat, ITscope.
|
||||
Aussage: Das System soll den elektronischen Datenaustausch mit Lieferanten (Bestellungen, Lieferscheine, Rechnungen) über EDI-Standards (OpenTrans, ZUGFeRD) und API-Integrationen (GLS, Shipcloud, FinAPI) unterstützen.
|
||||
Ergebnis: Bestellungen werden elektronisch an Lieferanten übermittelt; Lieferdaten werden automatisch importiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/EDI_Alltron/`, `EDI_ALSO/`, `EDI_EGIS/`, `EDI_Komsa/`, `OpenTrans/`, `ZUGFeRD21_Extended/` – Begründung: Implementiert die EDI-Gateways für verschiedene Lieferanten und Standards.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs` – Klasse `EDIDispatcherBL` – Begründung: Zentrale Dispatch-Logik für EDI-Verarbeitung.
|
||||
- [SEKUNDÄR] `src/apis/Centron.Api.Gls/`, `src/apis/Centron.Api.Shipcloud/`, `src/apis/Centron.APIs.FinAPI/` – Begründung: API-Integrationen für Versand und Bankwesen.
|
||||
Prüfidee: Eine Bestellung kann per EDI an einen Lieferanten gesendet und die Bestellbestätigung automatisch importiert werden.
|
||||
Tracelinks: SyRS-014, SwRS-015
|
||||
Konsolidierung: Kandidat: Die EDI-Gateways für Alltron, ALSO, EGIS und Komsa weisen strukturelle Gemeinsamkeiten auf und sollten im Zielsystem zu einem einheitlichen EDI-Adapter konsolidiert werden.
|
||||
Übernahmewürdigkeit: übernehmen – EDI-Integration ist für Systemhäuser mit automatisierter Lieferantenanbindung erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-010: Report- und Dokumentgenerierung
|
||||
|
||||
ID: StRS-010
|
||||
Titel: Report- und Dokumentgenerierung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Mitarbeiter
|
||||
Vorbedingung: Beleg oder Stammdatum ist vorhanden
|
||||
Fakt: `ReportDataBL` (`ReportDataBL.cs`) mit 94.267 Bytes Umfang verwaltet Berichtsdaten. `FastReportHelper` (`FastReportHelper.cs`) integriert die FastReport-Bibliothek. Verzeichnisse `ReportObjects/`, `PdfExport/`, `ReplacementBLs/` und `Templates/` unter `ReportEngine/`. `ReportGroupBL` (`ReportGroupBL.cs`) verwaltet Reportgruppen.
|
||||
Aussage: Das System soll Belege, Angebote, Rechnungen und Berichte automatisch generieren und als PDF exportieren können, mit variablen Daten und vorlagenbasierter Erstellung.
|
||||
Ergebnis: Generiertes Dokument liegt als PDF oder im System vor.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/ReportEngine/ReportDataBL.cs` – Klasse `ReportDataBL` – Begründung: Zentrale Berichtsdatenverarbeitung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/ReportEngine/FastReportHelper.cs` – Klasse `FastReportHelper` – Begründung: Integration der Report-Engine.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/ReportEngine/PdfExport/` – Begründung: PDF-Export-Funktionalität.
|
||||
Prüfidee: Eine Rechnung kann als PDF generiert und gedruckt werden.
|
||||
Tracelinks: SyRS-015, SwRS-016
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Berichtsgenerierung ist für Belegausgabe erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-011: Buchhaltungs- und Finanzdatentransfer
|
||||
|
||||
ID: StRS-011
|
||||
Titel: Buchhaltungs- und Finanzdatentransfer
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (automatisierter Export), Buchhalter
|
||||
Vorbedingung: Belege sind erfasst und FiBu-Konten zugeordnet
|
||||
Fakt: `BookKeepingReceiptKind` (`BookKeepingReceiptKind.cs`) definiert Buchhaltungsbelegarten (Invoice, CreditVoucher, SupplierInvoice, SupplierCreditVoucher). `src/backend/Centron.Gateway/DataExchange/BookKeeping/` implementiert den Export. `ReceiptItemAccountBL.GetProfitAndLossAccount()` ermittelt Erloes-/Aufwandskonten basierend auf Kunde, Land, Filiale und Reverse-Charge-Flag.
|
||||
Aussage: Das System soll Buchhaltungsdaten (Rechnungen, Gutschriften, Lieferantenrechnungen) mit korrekten Erloes- und Aufwandskonten an externe Buchhaltungssysteme exportieren, wobei die Kontenzuordnung nach Land (Inland/EU/Drittland/Reverse-Charge) erfolgt.
|
||||
Ergebnis: Buchhaltungsdaten sind mit korrekten Konten exportiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/DataExchange/BookKeeping/BookKeepingReceiptKind.cs` – Enum mit `GetCentronObjectKind()` – Begründung: Definiert die Buchhaltungsbelegarten.
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/DataExchange/BookKeeping/` – Begründung: Implementiert den Buchhaltungsdatentransfer.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `DoUpdateReceiptOfferItems()` mit `itemBL.GetProfitAndLossAccount(true, customerI3D, countryI3D, branchI3D, exclusiveOfVAT, articleI3D, ...)` – Begründung: Erloes-/Aufwandskonten-Zuordnung nach Land und Reverse-Charge.
|
||||
Prüfidee: Eine Rechnung an einen EU-Kunden verwendet das Erloeskonto EU; eine Rechnung an einen Drittlandkunden das Erloeskonto Drittland.
|
||||
Tracelinks: SyRS-016, SwRS-017
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Buchhaltungsdatentransfer ist für ERP-Systeme erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-012: E-Mail- und Kommunikationsverwaltung
|
||||
|
||||
ID: StRS-012
|
||||
Titel: E-Mail- und Kommunikationsverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Mitarbeiter, System (automatisiert)
|
||||
Vorbedingung: Mail-Einstellungen sind konfiguriert
|
||||
Fakt: `src/backend/Centron.BL/Mail/` enthält `MailSettingsBL.cs`, `MailSignatureBL.cs`, Verzeichnisse `Exchange/`, `Templates/`, `VariableReplacement/`, `Protocols/`. `MailScannerBL` (`MailScannerBL.cs`) scannt eingehende Mails. `MailTemplateReferences` (`MailTemplateReferences.cs`) definiert über 60 Mailvorlagen-Referenzen für verschiedene Beleg- und Ereignistypen.
|
||||
Aussage: Das System soll E-Mails mit vorlagenbasierter Generierung, Variablenersetzung, Exchange-Anbindung und automatischem Mail-Scanner für eingehende Tickets unterstützen.
|
||||
Ergebnis: E-Mails werden generiert, versendet und eingehende Mails werden als Tickets erfasst.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Mail/MailSettingsBL.cs` – Klasse `MailSettingsBL` – Begründung: Zentrale Mail-Konfiguration.
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/Mail/Templates/MailTemplateReferences.cs` – Über 60 statische `MailTemplateReference`-Definitionen – Begründung: Definiert die Vorlagenstruktur für alle Beleg- und Ereignistypen.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/MailScanner/MailScannerBL.cs` – Begründung: Automatische Ticket-Erfassung aus Mails.
|
||||
Prüfidee: Eine Rechnung wird mit der korrekten Mailvorlage versendet; eine eingehende Mail erzeugt ein Ticket.
|
||||
Tracelinks: SyRS-017, SwRS-018
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – E-Mail-Integration ist für Kommunikationsprozesse erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-013: Produktions- und Projektverwaltung
|
||||
|
||||
ID: StRS-013
|
||||
Titel: Produktions- und Projektverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Mitarbeiter (Produktion, Projektleitung)
|
||||
Vorbedingung: Mitarbeiter hat Produktions-/Projektrechte
|
||||
Fakt: `ProductionBL` (`ProductionBL.cs`) und `ProductionOrderBL` (`ProductionOrderBL.cs`) verwalten Produktionsaufträge. `ProjectBL` (`ProjectBL.cs`) verwaltet Projekte. `ArticleBL` referenziert `IsProductionArticle` als Artikeleigenschaft.
|
||||
Aussage: Das System soll Produktionsaufträge und Projekte verwalten, wobei Artikel als Produktionsartikel markiert und Produktionsprozesse abgebildet werden können.
|
||||
Ergebnis: Produktionsaufträge und Projekte sind mit zugehörigen Artikeln erfasst.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Production/ProductionBL.cs` – Klasse `ProductionBL` – Begründung: Produktionsverwaltung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Production/ProductionOrderBL.cs` – Klasse `ProductionOrderBL` – Begründung: Produktionsauftragsverwaltung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Eigenschaft `IsProductionArticle` – Begründung: Artikel kann als Produktionsartikel markiert werden.
|
||||
Prüfidee: Ein Produktionsartikel kann einem Produktionsauftrag zugeordnet werden.
|
||||
Tracelinks: SyRS-018
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Produktionsverwaltung ist für Systemhäuser mit Eigenefertigung relevant.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-014: Externe Integrationsplattform RiverDivo
|
||||
|
||||
ID: StRS-014
|
||||
Titel: Externe Integrationsplattform RiverDivo
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (automatisiert)
|
||||
Vorbedingung: RiverDivo-Konnektor ist konfiguriert
|
||||
Fakt: `RiverDivoBL` (`RiverDivoBL.cs`) und `RiverConnectionBL` (`RiverConnectionBL.cs`) implementieren eine Verbindung zu einem externen System "RiverDivo". `SimpleRiverCentronClient` (`SimpleRiverCentronClient.cs`) ist ein HTTP-Client für RiverDivo. Die genaue fachliche Bedeutung von RiverDivo ist aus dem Code nicht vollständig ersichtlich.
|
||||
Aussage: Das System soll eine Integration mit der RiverDivo-Plattform unterstützen, um Daten auszutauschen und externe Prozesse anzubinden. [HYPOTHESE] Die genaue fachliche Rolle von RiverDivo (ob es sich um eine Asset-Management-Plattform, eine Monitoring-Lösung oder eine Reporting-Schnittstelle handelt) konnte aus dem Code nicht eindeutig bestimmt werden und erfordert eine Bestätigung durch Fachexperten.
|
||||
Ergebnis: Daten werden mit RiverDivo ausgetauscht.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/RiverDivo/RiverDivoBL.cs` – Klasse `RiverDivoBL` mit 25.221 Bytes – Begründung: Implementiert die RiverDivo-Geschäftslogik.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs` – Klasse `RiverConnectionBL` – Begründung: Verbindungsverwaltung zu RiverDivo.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/RiverDivo/SimpleRiverCentronClient.cs` – Begründung: HTTP-Client-Implementierung.
|
||||
Prüfidee: Die Verbindung zu RiverDivo kann hergestellt und Daten können ausgetauscht werden.
|
||||
Tracelinks: SyRS-019
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Externe Integrationen müssen im Zielsystem erhalten bleiben, sofern sie aktiv genutzt werden.
|
||||
Status: HYPOTHESE
|
||||
|
||||
---
|
||||
|
||||
### StRS-015: Systembetrieb und Lizenzverwaltung
|
||||
|
||||
ID: StRS-015
|
||||
Titel: Systembetrieb und Lizenzverwaltung
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: Administrator, System-Dienst
|
||||
Vorbedingung: System ist installiert
|
||||
Fakt: `LicenseManager` (`LicenseManager.cs`) prüft Lizenzen pro Applikation über `CheckLicense(applicationKind, appVersion, userResult)`. `ApplicationKind` steuert erforderliche und verbotene Rechte pro Applikation. `TelemetryBL` (`TelemetryBL.cs`) erfasst Systemtelemetrie. `App.xaml.cs` mit 32.927 Bytes initialisiert die WPF-Applikation. `nlog.config` konfiguriert das Logging.
|
||||
Aussage: Das System soll einen zuverlässigen Betrieb mit Lizenzprüfung pro Applikation, Telemetrie-Erfassung und strukturiertem Logging gewährleisten.
|
||||
Ergebnis: System läuft mit gültiger Lizenz, Telemetrie und Logs werden erfasst.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs` – Klasse `LicenseManager`, Methode `CheckLicense()` – Begründung: Zentrale Lizenzprüfung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Telemetry/TelemetryBL.cs` – Klasse `TelemetryBL` – Begründung: Systemtelemetrie.
|
||||
- [SEKUNDÄR] `src/centron/Centron.WPF.UI/nlog.config` – Begründung: Logging-Konfiguration.
|
||||
Prüfidee: Das System startet nur mit gültiger Lizenz; Telemetriedaten werden erfasst.
|
||||
Tracelinks: SyRS-007, SwRS-019
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Lizenzverwaltung und Telemetrie sind für den SaaS-Betrieb erforderlich.
|
||||
Status: belegt
|
||||
+674
@@ -0,0 +1,674 @@
|
||||
# Software Requirements Specification (SwRS)
|
||||
|
||||
**System:** c-entron ERP-Suite
|
||||
**Spezifikationsversion:** 1.0
|
||||
**Datum:** 2026-08-28
|
||||
**Standard:** ISO/IEC/IEEE 29148:2018
|
||||
|
||||
---
|
||||
|
||||
### SwRS-001: Authentifizierungs-Factory-Pattern
|
||||
|
||||
ID: SwRS-001
|
||||
Titel: Authentifizierungs-Factory-Pattern
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal: Wartbarkeit
|
||||
Akteur: Authentifizierungs-Subsystem
|
||||
Vorbedingung: Login-Request liegt vor
|
||||
Fakt: `AuthenticatorFactory` implementiert das Factory-Pattern mit `GetAuthenticator(AuthObject authObject)`. Basierend auf `authObject`-Typ (`BasicAuthObject`, `WebAccountAuthObject`, `OpenIdConnectAuthObject`) und `SystemAuthenticationMethod` wird der Authentifikator ausgewählt. `GetAuthObjectFromLoginRequest()` erzeugt das AuthObject aus `LoginRequest` basierend auf `WebLoginType` (User, Domain, Customer). Bei `BasicAuthObject` wird zusätzlich `GetAuthenticationKindFromUserName()` aufgerufen, das per NHibernate-Query `AuthentificationKind` des Benutzers ermittelt.
|
||||
Aussage: Die Authentifizierungskomponente soll das Strategy-Pattern mit Factory verwenden, um basierend auf Login-Typ, Systemeinstellung und Benutzer-Art den korrekten Authentifikator zu instanziieren.
|
||||
Ergebnis: Korrekter Authentifikator ist erstellt und bereit zur Ausführung.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs` – Klasse `AuthenticatorFactory`, Methoden `GetAuthenticator()`, `GetMainAuthenticator()`, `GetFromBasicAuth()`, `GetAuthenticationKindFromUserName()` – Begründung: Implementiert das Factory-Pattern mit Typ- und Einstellungsbasierter Auswahl.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs` – abstrakte Klasse `Authenticator` mit `AuthenticateInternal()` – Begründung: Definiert die Strategy-Schnittstelle.
|
||||
Tracelinks: SyRS-001, StRS-001
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Das Factory-Pattern ermöglicht erweiterbare Authentifizierung.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-002: Rechte-Caching und -Prüfung
|
||||
|
||||
ID: SwRS-002
|
||||
Titel: Rechte-Caching und -Prüfung
|
||||
Ebene: SwRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Performance-Effizienz
|
||||
Akteur: Rechte-Subsystem
|
||||
Vorbedingung: Benutzer ist angemeldet
|
||||
Fakt: `AppRightsBL.HasUserRight(appUserI3D, rightID)` verwendet `Session.Advanced.Cache.GetOrAdd($"AllRightsFromAppUser{appUserI3D}", () => GetAllAppRightsFromUser(appUserI3D))`. `GetAllAppRightsFromUser()` führt SQL aus: `SELECT st.Recht AS ID FROM dbo.Sichtrus st INNER JOIN dbo.Sichmemb sm ON sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D`. Web-Account-Rechte werden analog über `GetAllWebRightsFromWebAccount()` gecacht.
|
||||
Aussage: Die Rechtekomponente soll Benutzerrechte beim ersten Zugriff laden und cachen, um wiederholte Datenbankabfragen zu vermeiden.
|
||||
Ergebnis: Rechteprüfung erfolgt mit minimaler Datenbanklast.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `HasUserRight()` mit `Session.Advanced.Cache.GetOrAdd($"AllRightsFromAppUser{appUserI3D}", ...)` und SQL – Begründung: Implementiert Caching mit SQL-basierter Rechteabfrage.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `GetAllWebRightsFromWebAccount()` mit separatem Cache – Begründung: Separates Caching für Web-Account-Rechte.
|
||||
Tracelinks: SyRS-003, SyRS-012, SyRS-022, StRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Rechte-Caching ist für Performance bei häufigen Rechteprüfungen erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-003: Passwort-Hashing und -Validierung
|
||||
|
||||
ID: SwRS-003
|
||||
Titel: Passwort-Hashing und -Validierung
|
||||
Ebene: SwRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Authentifizierungs-Subsystem
|
||||
Vorbedingung: Benutzer ändert oder überprüft Passwort
|
||||
Fakt: `UsersBL.ChangeOwnPassword()` verwendet `SHA1Decoder.GetDecodedSHA1String(currentPassword)` und vergleicht mit `appUser.Password` bzw. `webAccount.Password`. `UpdatePassword()` setzt `user2.Password = newPass` (als SHA1-Hash) und `user2.LastPasswordChangedDate = DateTime.Now`. `IsValidAppUserPassword()` prüft `newPassword?.Length < appUser.PasswordMinLength`. Bei externer Authentifizierung (`AuthentificationKind.WindowsAuth or OpenIdConnectAuth` oder Systemeinstellung AD/Entra) wird Passwortänderung verweigert.
|
||||
Aussage: Die Authentifizierungskomponente soll Passwörter als SHA1-Hash speichern, bei Änderung das aktuelle Passwort verifizieren und die Mindestlänge prüfen, sowie externe Authentifizierungs-Benutzer von der c-entron-Passwortänderung ausschließen.
|
||||
Ergebnis: Passwort ist geändert oder mit Fehlermeldung abgelehnt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/UsersBL.cs` – Methode `ChangeOwnPassword()` mit `SHA1Decoder.GetDecodedSHA1String()` und `usesExternalAuth`-Prüfung – Begründung: Implementiert Passwortprüfung und AD/Entra-Ausschluss.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/UsersBL.cs` – Methode `UpdatePassword()` und `IsValidAppUserPassword()` – Begründung: Passwortänderung mit Mindestlängenprüfung.
|
||||
Tracelinks: SyRS-005, StRS-001
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: Workaround – SHA1 ist veraltet und unsicher; im Zielsystem sollte bcrypt/Argon2 verwendet werden.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-004: Nummernkreis-Reservierung mit Optimistic Locking
|
||||
|
||||
ID: SwRS-004
|
||||
Titel: Nummernkreis-Reservierung mit Optimistic Locking
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: Nummernkreis-Subsystem
|
||||
Vorbedingung: Nummernkreis-Objekt existiert
|
||||
Fakt: `NumberGroupBL.GetNextNumber()` verwendet eine While-Schleife, die `Session.GetSession().Refresh(numberGroupObject)` aufruft und dann `FindNextNumber()` ermittelt. Anschließend `UpdateBuilder().Set(s => s.Current, nextNumber).Update()` mit Prüfung `rowCountChanged == 1`. Wenn nicht 1, wird die Schleife wiederholt (Retry). `FindNextNumber()` prüft zusätzlich gegen existierende Einträge in der Zieltabelle mit `SELECT COUNT(*)`.
|
||||
Aussage: Die Nummernkreis-Komponente soll Nummern mit optimistischem Locking vergeben, indem der aktuelle Zähler per UPDATE mit Where-Bedingung aktualisiert wird und bei Konflikt (rowCountChanged != 1) die Vergabe wiederholt wird.
|
||||
Ergebnis: Eindeutige Nummer wird auch bei gleichzeitigen Anfragen korrekt vergeben.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs` – Methode `GetNextNumber()` mit `UpdateBuilder().Set(s => s.Current, nextNumber).Update()` und `while(true)` mit `rowCountChanged == 1` – Begründung: Implementiert optimistisches Locking mit Retry.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs` – Methode `FindNextNumber()` mit `SELECT COUNT(*) AS cnt FROM {tableName} WHERE {fieldName} = {counter}` – Begründung: Validierung gegen existierende Einträge.
|
||||
Tracelinks: SyRS-010, StRS-003, StRS-004
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Optimistic Locking für Nummernvergabe verhindert Duplikate.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-005: Artikel-Validierungslogik
|
||||
|
||||
ID: SwRS-005
|
||||
Titel: Artikel-Validierungslogik
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Artikel-Subsystem
|
||||
Vorbedingung: Artikel soll gespeichert werden
|
||||
Fakt: `ArticleBL.ValidateArticleBeforeSave()` prüft: Artikelcode nicht leer und wird von Nicht-ASCII bereinigt (`Regex.Replace`); Herstellercode-Eindeutigkeit (außer EOL); MwSt vorhanden; Warengruppe vorhanden; Beschreibung vorhanden; ShortDescription auf 150 Zeichen gekürzt; Precision 0-7; Stücklisten-Regeln; Mietartikel-Constraint (`ApplyRentArticleStockAndSerialConstraints`); WorkUnit-Validierung; Produktfamilien-Pflicht; Kostenstellen-/Kostenträger-Pflicht (aus Settings); EAN-Prüfziffer-Berechnung; Seriennummern-Bestands-Prüfung; VPE-Mindestwert bei aktivierter Abbuchung.
|
||||
Aussage: Die Artikelkomponente soll beim Speichern eine umfassende Validierung durchführen, die Feldpflicht, Eindeutigkeit, Format, Prüfziffern und fachliche Constraints prüft.
|
||||
Ergebnis: Nur valide Artikel werden gespeichert; bei Fehlern wird eine spezifische Fehlermeldung zurückgegeben.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `ValidateArticleBeforeSave()` mit allen genannten Prüfungen – Begründung: Implementiert die umfassende Validierung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `CheckUserRightBeforeSave()` mit `IsDirtyProperty()` – Begründung: Rechteprüfung vor Speicherung.
|
||||
Tracelinks: SyRS-011, StRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Artikelvalidierung ist für Datenqualität erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-006: Mietartikel-Constraint
|
||||
|
||||
ID: SwRS-006
|
||||
Titel: Mietartikel-Constraint
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Artikel-Subsystem
|
||||
Vorbedingung: Artikel ist als Mietartikel markiert (`IsRentArticle = true`)
|
||||
Fakt: `ArticleBL.ApplyRentArticleStockAndSerialConstraints()` prüft `articleEntity.IsRentArticle` und setzt bei aktivierten `ChangeStock` oder `ScanBarcode` diese auf `false`. Es wird ein NLog-Warn geschrieben und bei vorhandener `I3D` und `currentUser` ein `ArticleLogBL.WriteLog()` mit `ArticleLogKind.DebigEntry` bzw. `ArticleLogKind.SerialNumberAtOutflow`. Die Methode wird in `ValidateArticleBeforeSave`, `TakeOnMaterialGroupSettings` und `TakeOnSecondaryMaterialGroupSettings` aufgerufen.
|
||||
Aussage: Die Artikelkomponente soll für Miet-/Portal-Artikel die Lagerabbuchung (`ChangeStock`) und Seriennummernpflicht (`ScanBarcode`) automatisch deaktivieren und dies protokollieren.
|
||||
Ergebnis: Mietartikel haben keine Lagerabbuchung und keine Seriennummernpflicht; die Änderung ist protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `ApplyRentArticleStockAndSerialConstraints()` mit `articleEntity.ChangeStock = false` und `articleEntity.ScanBarcode = false` – Begründung: Durchsetzung des Constraints.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Aufruf in `ValidateArticleBeforeSave` (unter "Rent portal article"), `TakeOnMaterialGroupSettings` und `TakeOnSecondaryMaterialGroupSettings` – Begründung: Constraint wird an allen relevanten Stellen durchgesetzt.
|
||||
Tracelinks: SyRS-011, StRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Der Mietartikel-Constraint ist fachlich erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-007: EAN-Prüfziffer-Berechnung
|
||||
|
||||
ID: SwRS-007
|
||||
Titel: EAN-Prüfziffer-Berechnung
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Artikel-Subsystem
|
||||
Vorbedingung: Artikel hat einen EAN-Code und `EAnNotCheck` ist nicht aktiviert
|
||||
Fakt: `ArticleBL.ValidateArticleBeforeSave()` implementiert die EAN-Prüfziffer-Berechnung nach GS1-Standard: EAN wird auf 14 Stellen gepadded (EAN-8, EAN-12, EAN-13, EAN-14). Prüfziffer wird berechnet mit gewichteter Summe (ungerade Positionen * 3, gerade * 1) und `(10 - (sum % 10)) % 10`. Bei Fehler wird zurückgegeben: "Die Prüfung des EAN-Codes ist fehlgeschlagen." Zudem wird Eindeutigkeit des EAN-Codes geprüft (außer bei EOL-Artikeln).
|
||||
Aussage: Die Artikelkomponente soll EAN-Codes auf Gültigkeit der Prüfziffer nach GS1-Standard prüfen und Eindeutigkeit erzwingen (außer bei End-of-Life-Artikeln).
|
||||
Ergebnis: Nur valide und eindeutige EAN-Codes werden akzeptiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `ValidateArticleBeforeSave()` im Abschnitt `#region EAN` mit GS1-Prüfziffer-Berechnung und Eindeutigkeitsprüfung – Begründung: Implementiert die EAN-Validierung nach GS1-Standard.
|
||||
Tracelinks: SyRS-011, StRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – EAN-Prüfziffer ist für korrekte Artikeldaten erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-008: Stücklistenpreisberechnung
|
||||
|
||||
ID: SwRS-008
|
||||
Titel: Stücklistenpreisberechnung
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Artikel-Subsystem
|
||||
Vorbedingung: Artikel ist Teil einer Stückliste
|
||||
Fakt: `ArticleBL.UpdatePartList()` aktualisiert `PartListArticle` mit neuem EK, Text und (falls `UpdateVKsInPartList`) VK1-4. Die Eltern-Artikel-Preise werden neu berechnet: `newParentPrice1 = partListArticle.ParentArticle.PartListArticles.Where(...).Sum(f => f.Quantity * f.Price1) + partListArticle.Quantity * article.Price1`. Bei Preisänderung wird `ArticleLogBL.WriteLog()` mit `ArticleLogKind.SellPrice1` bis `SellPrice4` geschrieben. Wenn `IsPartListWithFixedSellPrice = true`, werden VKs nicht aktualisiert.
|
||||
Aussage: Die Artikelkomponente soll bei Änderung eines Artikel-EKs oder VKs automatisch die Preise in Stücklistenpositionen aktualisieren und die Gesamtpreise des Eltern-Artikels neu berechnen, es sei denn der Eltern-Artikel hat feste Stücklistenpreise.
|
||||
Ergebnis: Stücklistenpreise und Eltern-Artikel-Preise sind konsistent aktualisiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `UpdatePartList()` mit `Sum(f => f.Quantity * f.Price1)` und `IsPartListWithFixedSellPrice` – Begründung: Implementiert die Stücklistenpreisberechnung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – `ArticleLogBL.WriteLog()` Aufrufe mit `ArticleLogKind.SellPrice1` bis `SellPrice4` – Begründung: Protokollierung der Preisänderungen.
|
||||
Tracelinks: SyRS-011, StRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Stücklistenpreisberechnung ist für korrekte Preisführung erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-009: DSGVO-Löschprotokoll-Erstellung
|
||||
|
||||
ID: SwRS-009
|
||||
Titel: DSGVO-Löschprotokoll-Erstellung
|
||||
Ebene: SwRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Datensicherheits-Subsystem
|
||||
Vorbedingung: DSGVO-Löschung wird ausgeführt
|
||||
Fakt: `DataSecurityBL.DoDeleteContactPerson()` verwendet `StringBuilder deleteProtocol` und ruft `DoAppendDeleteProtocol(deleteProtocol, fieldName, value)` für jedes gelöschte Feld auf. `DoAppendDeleteProtocolWithBreak()` fügt Trennlinien ein. Das Protokoll enthält Feldname und alten Wert. Zusätzlich werden verknüpfte Web-Accounts (`DoDeleteContactPersonWebAccounts`), soziale Netzwerke (`DoDeleteContactPersonSocialNetworks`), Aktivitäten (`DoDeleteContactPersonActivities`) und Beziehungen (`DoDeleteContactPersonRelationShips`) gelöscht und protokolliert. `DsgvoDeletedContactMessageWithEmployeeInfo` wird als Kommentar gesetzt.
|
||||
Aussage: Die Datensicherheitskomponente soll bei jeder DSGVO-Löschung ein detailliertes Löschprotokoll erstellen, das alle gelöschten Felder, Web-Accounts, sozialen Netzwerke, Aktivitäten und Beziehungen auflistet.
|
||||
Ergebnis: Vollständiges Löschprotokoll liegt als String vor.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` – Methode `DoDeleteContactPerson()` mit `StringBuilder deleteProtocol` und `DoAppendDeleteProtocol()` für jedes Feld – Begründung: Implementiert die Protokollerstellung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` – Methoden `DoDeleteContactPersonWebAccounts()`, `DoDeleteContactPersonSocialNetworks()`, `DoDeleteContactPersonActivities()`, `DoDeleteContactPersonRelationShips()` – Begründung: Protokollierung der verknüpften Datenlöschungen.
|
||||
Tracelinks: SyRS-008, StRS-007
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – DSGVO-Löschprotokolle sind für Nachvollziehbarkeit erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-010: Admin-Gruppen-Rechte-Schutz
|
||||
|
||||
ID: SwRS-010
|
||||
Titel: Admin-Gruppen-Rechte-Schutz
|
||||
Ebene: SwRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Rechte-Subsystem
|
||||
Vorbedingung: Benutzer versucht, Recht an/von Admin-Gruppe zuzuweisen/zu entfernen
|
||||
Fakt: `AppRightsBL.SaveAndAssignGroupToRight()` prüft `_appUserGroupBL.IsAdministratorGroup(group)` und dann `GetAssignableAdminRightI3Ds()`. Diese Methode gibt eine fest codierte Liste von 37 Recht-I3Ds zurück, die hauptsächlich einschränkende Rechte ("nur eigene", "nur eigene Filiale") und DSGVO-Rechte enthalten. `RemoveAssignGroupToRight()` prüft analog. `DeleteRightGroup()` verweigert Löschung mit `group.I3D == 6 || group.Name.Equals("Administratoren")`. `RemoveGroupToRightAssignments()` überspringt Admin-Gruppen-Zuweisungen.
|
||||
Aussage: Die Rechtekomponente soll verhindern, dass der Admin-Gruppe beliebige Rechte zugewiesen oder entzogen werden, indem nur eine fest codierte Teilmenge von 37 Rechten (hauptsächlich einschränkende und DSGVO-Rechte) zugelassen wird, und die Admin-Gruppe nicht gelöscht werden kann.
|
||||
Ergebnis: Admin-Gruppe behält ihre Kern-Rechte; nur zulässige Rechte können zugewiesen/entzogen werden.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `GetAssignableAdminRightI3Ds()` mit fest codierter Liste von 37 I3Ds – Begründung: Definiert die zulässigen Rechte für Admin-Gruppe.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `SaveAndAssignGroupToRight()` mit `IsAdministratorGroup(group)` und `GetAssignableAdminRightI3Ds().Contains(selectedRight.I3D)` – Begründung: Durchsetzung der Einschränkung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `DeleteRightGroup()` mit `group.I3D == 6 || group.Name.Equals("Administratoren")` – Begründung: Schützt die Admin-Gruppe vor Löschung.
|
||||
Tracelinks: SyRS-003, StRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: Workaround – Fest codierte Recht-IDs sind wartungsfeindlich; im Zielsystem sollte eine datenbankbasierte Zuordnung verwendet werden.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-011: Artikel-Seriennummern-Bestands-Prüfung
|
||||
|
||||
ID: SwRS-011
|
||||
Titel: Artikel-Seriennummern-Bestands-Prüfung
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Artikel-Subsystem
|
||||
Vorbedingung: Setting `BearingRrelatedSerialNumbers` ist aktiv und `ScanBarcode`-Eigenschaft wird geändert
|
||||
Fakt: `ArticleBL.CheckSerialnumberQuantityEqualsStockQuantity()` vergleicht die Anzahl der Seriennummern (`BarcodeBL.GetBarcodesThroughPaging`) mit dem Lagerbestand (`ArticleStockInfo`) pro Lager. Wenn die Anzahl nicht übereinstimmt, wird eine Fehlermeldung zurückgegeben: "Die Anzahl an Seriennummer für das Lager {storageName} stimmen nicht mit der Anzahl an Artikel im Lager überein." Zudem wird bei Änderung von `ScanBarcode` bei vorhandenem Bestand ein Fehler ausgegeben.
|
||||
Aussage: Die Artikelkomponente soll verhindern, dass die Seriennummernpflicht geändert wird, wenn die Anzahl der Seriennummern nicht mit dem Lagerbestand übereinstimmt oder wenn ein bestandsführender Artikel existiert.
|
||||
Ergebnis: Seriennummernpflicht kann nur bei konsistentem Bestand geändert werden.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `CheckSerialnumberQuantityEqualsStockQuantity()` mit Vergleich `serialNumberStockAmount` vs. `articleStockAmount` – Begründung: Implementiert die Bestandsprüfung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Abschnitt "ScanBarcode change with existing stock" mit `ArticleStockInfo`-Prüfung – Begründung: Verhindert SN-Pflicht-Änderung bei vorhandenem Bestand.
|
||||
Tracelinks: SyRS-011, StRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Bestandskonsistenz bei Seriennummern ist fachlich erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-012: Artikel-Kopierfunktion
|
||||
|
||||
ID: SwRS-012
|
||||
Titel: Artikel-Kopierfunktion
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Artikel-Subsystem
|
||||
Vorbedearbeitung: Referenzartikel existiert
|
||||
Fakt: `ArticleBL.CopyArticle()` akzeptiert `ArticleCopyOptions` mit über 50 boolschen Flags, die steuern, welche Eigenschaften kopiert werden (Preise, Lager, Warengruppe, Spezifikationen, etc.). Nach dem Speichern werden zusätzlich freie Spezifikationen (`ArticleFreeSpecificationBL.CopyArticleFreeSpecificationsFromAnotherArticle`) und Stücklisten (`PartListArticleBL.ClonePartList`) kopiert. Fehler werden in `copyErrors` gesammelt und als Warning zurückgegeben.
|
||||
Aussage: Die Artikelkomponente soll das Kopieren von Artikeln mit granularer Auswahl der zu kopierenden Eigenschaften ermöglichen.
|
||||
Ergebnis: Neuer Artikel mit ausgewählten Eigenschaften des Referenzartikels ist erstellt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `CopyArticle()` mit `ArticleCopyOptions` und über 50 bedingten Kopieroperationen – Begründung: Implementiert die granulare Kopierfunktion.
|
||||
Tracelinks: StRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Artikelkopie ist für effiziente Stammdatenpflege erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-013: Artikel-Beleg-Position-Aktualisierung
|
||||
|
||||
ID: SwRS-013
|
||||
Titel: Artikel-Beleg-Position-Aktualisierung
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Artikel-Subsystem
|
||||
Vorbedingung: Externer oder neuer Artikel wird in einen eigenen Artikel umgewandelt
|
||||
Fakt: `ArticleBL.UpdateArticlePositionFromArticleChange()` aktualisiert Belegpositionen in Angeboten (`AngPos`), Aufträgen (`AufPos`) und Lieferantenanfragen (`AnfrPos`), wenn ein externer/neuer Artikel durch einen eigenen ersetzt wird. Es werden ArtikelI3D, Code, HerstCode, ErloesKTO, Abbuchung und ggf. EK, Mwst, Kostenstelle, Kostenträger aktualisiert. Nach der Aktualisierung wird die Provision neu berechnet (`ReceiptProvisionBL.RecalculateProvision`) und ein `ReceiptLogBL.CreateEntry()` mit `ReceiptLogKind.ArticleConvert` geschrieben.
|
||||
Aussage: Die Artikelkomponente soll bei der Umwandlung externer/neuer Artikel die zugehörigen Belegpositionen automatisch aktualisieren und die Provisionsberechnung neu durchführen.
|
||||
Ergebnis: Belegpositionen referenzieren den korrekten Artikel; Provisionen sind neu berechnet.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `UpdateArticlePositionFromArticleChange()` mit Update von `AngPos`, `AufPos`, `AnfrPos` und `ReceiptProvisionBL.RecalculateProvision()` – Begründung: Implementiert die Belegposition-Aktualisierung.
|
||||
Tracelinks: SyRS-009, StRS-004
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Automatische Belegposition-Aktualisierung ist für Datenkonsistenz erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-014: Nexus Web-Account-Controller
|
||||
|
||||
ID: SwRS-014
|
||||
Titel: Nexus Web-Account-Controller
|
||||
Ebene: SwRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Nexus Web-Anwendung
|
||||
Vorbedingung: Nexus Host läuft
|
||||
Fakt: `CentronNexus` (`src/nexus/CentronNexus/`) enthält `Controllers/`, `WebCart/`, `WebOffer/`, `ServiceBoard/`, `DocumentSigning/`. `CentronNexus.Host/Program.cs` mit 19.423 Bytes initialisiert die Blazor-Anwendung. `_Imports.razor` importiert Razor-Komponenten. `SharedResource.resx` und `SharedResource.en-US.resx` implementieren Lokalisierung.
|
||||
Aussage: Die Nexus-Komponente soll eine Blazor-Webanwendung mit WebCart, WebOffer, ServiceBoard und Dokumentsignierung bereitstellen, mit Lokalisierung (DE/EN).
|
||||
Ergebnis: Web-Anwendung ist für Kunden zugänglich.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/nexus/CentronNexus/` – Verzeichnisse `Controllers/`, `WebCart/`, `WebOffer/`, `ServiceBoard/`, `DocumentSigning/` – Begründung: Implementiert die Web-Funktionsbereiche.
|
||||
- [PRIMÄR] `src/nexus/CentronNexus.Host/Program.cs` – Begründung: Initialisiert die Blazor-Anwendung.
|
||||
- [SEKUNDÄR] `src/nexus/CentronNexus/SharedResource.resx`, `SharedResource.en-US.resx` – Begründung: Lokalisierung.
|
||||
Tracelinks: SyRS-013, StRS-008
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Die Nexus-Webanwendung ist der architektonische Vorläufer der SaaS-Neuimplementierung.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-015: EDI-Gateway-Implementierung
|
||||
|
||||
ID: SwRS-015
|
||||
Titel: EDI-Gateway-Implementierung
|
||||
Ebene: SwRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: EDI-Subsystem
|
||||
Vorbedingung: EDI-Gateway-Einstellungen sind konfiguriert
|
||||
Fakt: `src/backend/Centron.Gateway/` enthält separate Verzeichnisse für jeden Lieferanten: `EDI_Alltron/`, `EDI_ALSO/`, `EDI_AlsoCH/`, `Concerto/`, `EDI_EGIS/`, `EDI_Herweck/`, `EDI_Komsa/`, `OpenTrans/`, `OpenTrans1_0/`, `ZUGFeRD21_Extended/`. Zusätzlich `Import/`, `Export/`, `MspCollector/`, `OnlineBanking/`, `Portal/`. `Centron.Gateway.csproj` referenziert die Gateway-Projekte.
|
||||
Aussage: Die EDI-Komponente soll separate Gateway-Implementierungen für jeden Lieferanten/Standard mit Import/Export-Funktionalität bereitstellen.
|
||||
Ergebnis: EDI-Nachrichten werden pro Lieferanten-Standard korrekt verarbeitet.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/` – Verzeichnisstruktur mit separaten Gateways – Begründung: Implementiert die einzelnen EDI-Gateways.
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/Centron.Gateway.csproj` – Projektdatei – Begründung: Definiert die Projektstruktur.
|
||||
Tracelinks: SyRS-014, StRS-009
|
||||
Konsolidierung: Kandidat: EDI-Gateways für Alltron, ALSO, EGIS, Komsa weisen strukturelle Gemeinsamkeiten auf und sollten zu einem konfigurierbaren Adapter konsolidiert werden.
|
||||
Übernahmewürdigkeit: übernehmen – EDI-Gateways sind für B2B-Integration erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-016: Report-Daten-Verarbeitung
|
||||
|
||||
ID: SwRS-016
|
||||
Titel: Report-Daten-Verarbeitung
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Report-Subsystem
|
||||
Vorbedingung: Reportdaten sind angefordert
|
||||
Fakt: `ReportDataBL` (`ReportDataBL.cs`) mit 94.267 Bytes ist die zentrale Klasse. `ReportDataQueryBL` (`ReportDataQueryBL.cs`) führt Report-Queries aus. `ReportDataSettingsBL` (`ReportDataSettingsBL.cs`) verwaltet Report-Einstellungen. `ReportGroupBL` (`ReportGroupBL.cs`) mit 32.455 Bytes verwaltet Reportgruppen. `ReportUserBL` (`ReportUserBL.cs`) verwaltet Report-Benutzer-Zuordnungen.
|
||||
Aussage: Die Report-Komponente soll Berichtsdaten mit Query-Verarbeitung, Gruppierung und benutzerspezifischen Einstellungen verarbeiten.
|
||||
Ergebnis: Reportdaten sind für die Ausgabe aufbereitet.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/ReportEngine/ReportDataBL.cs` – Klasse `ReportDataBL` – Begründung: Zentrale Berichtsdatenverarbeitung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/ReportEngine/ReportDataQueryBL.cs` – Klasse `ReportDataQueryBL` – Begründung: Query-Verarbeitung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/ReportEngine/ReportGroupBL.cs` – Klasse `ReportGroupBL` – Begründung: Reportgruppen-Verwaltung.
|
||||
Tracelinks: SyRS-015, StRS-010
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Report-Datenverarbeitung ist für Belegausgabe erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-017: FiBu-Konto-Ermittlung
|
||||
|
||||
ID: SwRS-017
|
||||
Titel: FiBu-Konto-Ermittlung
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Beleg-Subsystem
|
||||
Vorbedingung: Belegposition mit Artikel und Kunde/Lieferant existiert
|
||||
Fakt: `ArticleBL.DoUpdateReceiptOfferItems()` und `DoUpdateReceiptOrderItems()` rufen `ReceiptItemAccountBL.GetProfitAndLossAccount(true/false, customerI3D, countryI3D, branchI3D, exclusiveOfVAT, articleI3D, currentUser, isReverseChargeActive: false)` auf. Artikel haben separate Konten pro Region: `RevenueAccount` (Inland), `RevenueAccountEU`, `RevenueAccountOverseas`, `RevenueAccountReversecharge`. Analog Aufwandskonten: `ExpenseAccount`, `ExpenseAccountEU`, `ExpenseAccountOverseas`, `ExpenseAccountReversecharge`.
|
||||
Aussage: Die Belegkomponente soll das korrekte Erloes- oder Aufwandskonto basierend auf Kundenland (Inland/EU/Drittland), Reverse-Charge-Status und Artikel-Konfiguration ermitteln.
|
||||
Ergebnis: Korrektes FiBu-Konto ist in der Belegposition gesetzt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `DoUpdateReceiptOfferItems()` mit `itemBL.GetProfitAndLossAccount(true, item.CustomerI3D, item.CountryI3D, item.BranchI3D, item.ExclusiveOfVAT, articleI3D, currentUser, isReverseChargeActive: false)` – Begründung: Aufruf der Kontozuordnung mit Land und Reverse-Charge.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Artikel-Eigenschaften `RevenueAccount`, `RevenueAccountEU`, `RevenueAccountOverseas`, `RevenueAccountReversecharge`, `ExpenseAccount`, `ExpenseAccountEU`, `ExpenseAccountOverseas`, `ExpenseAccountReversecharge` – Begründung: Separate Konten pro Region und Steuerfall.
|
||||
Tracelinks: SyRS-016, StRS-011
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – FiBu-Kontozuordnung ist für korrekte Buchhaltung erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-018: E-Mail-Vorlagen-Variablenersetzung
|
||||
|
||||
ID: SwRS-018
|
||||
Titel: E-Mail-Vorlagen-Variablenersetzung
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Mail-Subsystem
|
||||
Vorbedingung: Mailvorlage und Geschäftsobjekt existieren
|
||||
Fakt: `MailTemplateReferences` definiert über 60 statische `MailTemplateReference`-Objekte mit `defaultSubject` und `defaultBody`. `SalutationAndAgreementReplacementBL` (`SalutationAndAgreementReplacementBL.cs`) mit 19.982 Bytes ersetzt Anrede- und Abrede-Variablen. Verzeichnis `VariableReplacement/` unter `Mail/` enthält weitere Ersetzungslogik. `TextModuleBL` (`TextModuleBL.cs`) mit 30.946 Bytes verwaltet Textbausteine.
|
||||
Aussage: Die Mail-Komponente soll Vorlagen-Variablen (Anrede, Abrede, Belegdaten) durch tatsächliche Werte ersetzen, mit über 60 vordefinierten Vorlagen für verschiedene Beleg- und Ereignistypen.
|
||||
Ergebnis: Personalisierte E-Mail mit ersetzten Variablen ist generiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/Mail/Templates/MailTemplateReferences.cs` – Über 60 statische `MailTemplateReference`-Definitionen – Begründung: Definiert die Vorlagenstruktur.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Mail/SalutationAndAgreementReplacementBL.cs` – Klasse `SalutationAndAgreementReplacementBL` – Begründung: Implementiert die Variablenersetzung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/TextModuleArea/TextModuleBL.cs` – Klasse `TextModuleBL` – Begründung: Verwaltet Textbausteine für E-Mails.
|
||||
Tracelinks: SyRS-017, StRS-012
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Vorlagenbasierte E-Mail-Generierung ist für Kommunikation erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-019: Lizenz-Manager-Implementierung
|
||||
|
||||
ID: SwRS-019
|
||||
Titel: Lizenz-Manager-Implementierung
|
||||
Ebene: SwRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: Lizenz-Subsystem
|
||||
Vorbedingung: Applikation startet
|
||||
Fakt: `LicenseManager` (`LicenseManager.cs`) mit 16.992 Bytes implementiert `ILicenseManager`. `CheckLicense(applicationKind, appVersion, userResult)` prüft verfügbare Lizenzen. `HasLicense(LicenseGuids.OpenIDConnectAuthentication)` prüft Feature-spezifische Lizenzen. `LicenseManager.Instance` ist ein Singleton. `FakeOfficeClient` (`FakeOfficeClient.cs`) wird für Tests verwendet.
|
||||
Aussage: Die Lizenzkomponente soll als Singleton Lizenzen pro Applikation und Feature prüfen, mit Support für Test-Szenarien.
|
||||
Ergebnis: Lizenzstatus ist ermittelt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs` – Klasse `LicenseManager` mit `CheckLicense()` und `HasLicense()` – Begründung: Implementiert die Lizenzprüfung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Administration/Licensing/FakeOfficeClient.cs` – Begründung: Test-Client für Lizenzszenarien.
|
||||
Tracelinks: SyRS-007, StRS-015
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Lizenzprüfung ist für kommerziellen Betrieb erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-020: NHibernate-DAO-Architektur
|
||||
|
||||
ID: SwRS-020
|
||||
Titel: NHibernate-DAO-Architektur
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal: Wartbarkeit
|
||||
Akteur: Datenzugriffs-Subsystem
|
||||
Vorbedingung: Datenbankverbindung ist konfiguriert
|
||||
Fakt: `DAOFactory` (`DAOFactory.cs`) mit 11.714 Bytes erstellt DAOs. `GenericDAO<T>` (`GenericDAO.cs`) mit 25.462 Bytes bietet generische CRUD-Operationen. `DAOSession` (`DAOSession.cs`) mit 7.364 Bytes verwaltet die NHibernate-Session. `GenericStoredProcedureDAO` (`GenericStoredProcedureDAO.cs`) mit 20.244 Bytes führt Stored Procedures aus. `SessionExtensions` (`SessionExtensions.cs`) mit 6.303 Bytes bietet Erweiterungsmethoden wie `IsDirtyProperty`, `GetOriginalEntityProperty`. `PredicateBuilder` (`PredicateBuilder.cs`) baut dynamische Filter-Ausdrücke.
|
||||
Aussage: Die Datenzugriffskomponente soll einen generischen DAO mit NHibernate-Session-Management, Stored-Procedure-Unterstützung und Dirty-Property-Tracking bereitstellen.
|
||||
Ergebnis: Daten werden über NHibernate persistent gespeichert und geladen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/DAOFactory.cs` – Klasse `DAOFactory` – Begründung: Zentrale DAO-Erstellung.
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/GenericDAO.cs` – Klasse `GenericDAO<T>` – Begründung: Generischer Datenzugriff.
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/SessionExtensions.cs` – Klasse `SessionExtensions` mit `IsDirtyProperty` und `GetOriginalEntityProperty` – Begründung: Dirty-Tracking für Rechteprüfung.
|
||||
Tracelinks: SyRS-021, SyRS-003
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Die DAO-Architektur muss im Zielsystem durch eine moderne Datenzugriffsschicht ersetzt werden.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-021: WPF-Desktop-Client-Architektur
|
||||
|
||||
ID: SwRS-021
|
||||
Titel: WPF-Desktop-Client-Architektur
|
||||
Ebene: SwRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Wartbarkeit
|
||||
Akteur: WPF-Client
|
||||
Vorbedingung: Applikation startet
|
||||
Fakt: `App.xaml.cs` mit 32.927 Bytes initialisiert die WPF-Applikation. `FrontWindowViewModel.cs` mit 33.074 Bytes ist das Haupt-ViewModel. `FrontWindow.xaml` mit 23.420 Bytes definiert das Hauptfenster mit Ribbon-UI. `ConnectionHeartbeatTimer.cs` überwacht die Verbindung zum Server. `ThirdPartySoftware.cs` dokumentiert Drittanbieter-Bibliotheken. DevExpress-Komponenten werden verwendet (`DevExpress.Version.props`). `nlog.config` konfiguriert das Logging.
|
||||
Aussage: Die WPF-Client-Komponente soll eine Ribbon-basierte Desktop-Oberfläche mit MVVM-Pattern, Heartbeat-Verbindungsüberwachung und DevExpress-Komponenten bereitstellen.
|
||||
Ergebnis: Desktop-Client ist mit funktionsfähiger UI und Serververbindung gestartet.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/centron/Centron.WPF.UI/App.xaml.cs` – Klasse `App` mit 32.927 Bytes – Begründung: Initialisiert die WPF-Applikation.
|
||||
- [PRIMÄR] `src/centron/Centron.WPF.UI/FrontWindowViewModel.cs` – Klasse `FrontWindowViewModel` mit 33.074 Bytes – Begründung: Haupt-ViewModel mit MVVM.
|
||||
- [PRIMÄR] `src/centron/Centron.WPF.UI/ConnectionHeartbeatTimer.cs` – Klasse `ConnectionHeartbeatTimer` – Begründung: Verbindungsüberwachung.
|
||||
- [SEKUNDÄR] `DevExpress.Version.props` – Begründung: DevExpress-Komponenten-Referenz.
|
||||
Tracelinks: StRS-015
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: veraltet – Der WPF-Client wird im Zielsystem durch eine Web-Anwendung abgelöst.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-022: Volltextsuche mit deutschem Analyzer
|
||||
|
||||
ID: SwRS-022
|
||||
Titel: Volltextsuche mit deutschem Analyzer
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal: Wartbarkeit
|
||||
Akteur: IndexSearch-Subsystem
|
||||
Vorbedingung: Index ist aufgebaut
|
||||
Fakt: `GermanAnalyzer` (`GermanAnalyzer.cs`) mit 20.050 Bytes implementiert die deutsche Wortstamm-Analyse. `IndexSearchBL` (`IndexSearchBL.cs`) mit 9.290 Bytes implementiert die Suchlogik. `IndexBuilder` (`IndexBuilder.cs`) baut den Index auf. Verzeichnis `Indexes/` enthält Index-Definitionen.
|
||||
Aussage: Die IndexSearch-Komponente soll eine Volltextsuche mit deutschem Wortstamm-Analyzer und indexbasiertem Aufbau bereitstellen.
|
||||
Ergebnis: Suchanfragen liefern relevante Ergebnisse mit deutscher Sprachanalyse.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs` – Klasse `GermanAnalyzer` mit 20.050 Bytes – Begründung: Implementiert deutsche Wortstamm-Analyse.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs` – Klasse `IndexSearchBL` – Begründung: Implementiert die Suchlogik.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/IndexSearch/IndexBuilder.cs` – Klasse `IndexBuilder` – Begründung: Index-Aufbau.
|
||||
Tracelinks: SyRS-020
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Volltextsuche mit Sprachanalyse ist für große Datenbestände erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-023: Change-Tracking-Attribut
|
||||
|
||||
ID: SwRS-023
|
||||
Titel: Change-Tracking-Attribut
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: ChangeTracking-Subsystem
|
||||
Vorbedingung: Entität ist mit `ChangeTrackingConfigurationAttribute` markiert
|
||||
Fakt: `ChangeTrackingConfigurationAttribute` (`ChangeTrackingConfigurationAttribute.cs`) akzeptiert `CentronObjectKindNumeric objectKind` im Konstruktor und hat eine Property `ObjectKind`. `IChangeTrackingProperties` (`IChangeTrackingProperties.cs`) definiert das Interface für änderungsverfolgte Eigenschaften. Verzeichnis `ChangeTracking/History/` unter BL. `ArticleLogBL` (`ArticleLogBL.cs`) schreibt Logs mit `ArticleLogKind` (SellPrice1-4, MinPrice, EVP, DebigEntry, SerialNumberAtOutflow, etc.).
|
||||
Aussage: Die ChangeTracking-Komponente soll Entitäten über ein Attribut markieren und Änderungen mit objektspezifischen Log-Typen protokollieren.
|
||||
Ergebnis: Änderungen sind mit Objektart und Aktionstyp protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/ChangeTracking/ChangeTrackingConfigurationAttribute.cs` – Attribut-Klasse mit `CentronObjectKindNumeric` – Begründung: Definiert das Change-Tracking-Attribut.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleLogBL.cs` – Methode `WriteLog()` mit `ArticleLogKind` – Begründung: Objektspezifische Protokollierung.
|
||||
Tracelinks: SyRS-024
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Change-Tracking ist für Nachvollziehbarkeit erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-024: Artikel-EK-Aktualisierung bei Lagerbuchung
|
||||
|
||||
ID: SwRS-024
|
||||
Titel: Artikel-EK-Aktualisierung bei Lagerbuchung
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Artikel-Subsystem
|
||||
Vorbedingung: Lagerbuchung erfolgt
|
||||
Fakt: `ArticleBL.UpdateArticlePurchasePriceThroughStockBooking()` aktualisiert den Einkaufspreis bei Lagerbuchung. Bei Hauptlager: `RawEk2 = RawEk1` (verschiebt alten EK), `PurchasePrice = newPurchasePrice`, `RawEk1 = stockBookingPurchasePrice`, `RawEk1Date = DateTime.Now`, `RawEk1ObjectI3D = receipt.I3D`, `RawEk1ObjectKind = receipt.ReceiptKind`. Bei Nebenlager: analog auf `SecondaryStockArticle`. Bei Preisänderung wird `ArticleLogBL.WritePurchasePriceChangeLog()` aufgerufen.
|
||||
Aussage: Die Artikelkomponente soll bei Lagerbuchungen den Einkaufspreis aktualisieren, den vorherigen EK in `RawEk2` archivieren und die Herkunft (Beleg-I3D und -Art) dokumentieren.
|
||||
Ergebnis: EK ist aktualisiert, vorheriger EK ist archiviert, Änderung ist protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `UpdateArticlePurchasePriceThroughStockBooking()` mit `RawEk2 = e.RawEk1`, `PurchasePrice = newPurchasePrice`, `RawEk1 = stockBookingPurchasePrice` und `WritePurchasePriceChangeLog()` – Begründung: Implementiert die EK-Aktualisierung mit Archivierung.
|
||||
Tracelinks: SyRS-009, StRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – EK-Aktualisierung bei Lagerbuchung ist für korrekte Preisführung erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-025: Standard-Rechtestruktur-Wiederherstellung
|
||||
|
||||
ID: SwRS-025
|
||||
Titel: Standard-Rechtestruktur-Wiederherstellung
|
||||
Ebene: SwRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Rechte-Subsystem
|
||||
Vorbedingung: Administrator führt Reset aus
|
||||
Fakt: `AppRightsBL.ResetDefaultRightGroups()` liest `DefaultRightsStructure.txt` als embedded Resource, parst Tab-separierte Zeilen (Gruppenname + kommaseparierte Recht-I3Ds), löscht alle Default-Gruppen, bereinigt tote Referenzen (`DELETE FROM Sichtrus WHERE Gruppe NOT IN (SELECT I3D FROM Sichgrup)`) und erstellt alle Gruppen neu mit `AddRightToRightGroup()`. Die SQL zum Aktualisieren der txt-Datei ist als Kommentar im Code enthalten.
|
||||
Aussage: Die Rechtekomponente soll eine Wiederherstellung der Standard-Rechtestruktur aus einer embedded Resource ermöglichen, mit Bereinigung toter Referenzen und Neuerstellung aller Gruppen.
|
||||
Ergebnis: Standard-Rechtestruktur ist wiederhergestellt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `ResetDefaultRightGroups()` mit `GetDefaultRightsStructure()` und `GetDefaultRightsStructureFileContent()` – Begründung: Implementiert die Reset-Logik.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/DefaultRightsStructure.txt` – Embedded Resource mit Tab-separierten Gruppen und Recht-I3Ds – Begründung: Definiert die Standardstruktur.
|
||||
Tracelinks: SyRS-003, StRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: Workaround – Embedded Resource für Standardrechte ist wartungsfeindlich; im Zielsystem sollte eine datenbankbasierte Lösung verwendet werden.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-026: Artikel-Seriennummern- und Barcode-Verwaltung
|
||||
|
||||
ID: SwRS-026
|
||||
Titel: Artikel-Seriennummern- und Barcode-Verwaltung
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Barcode-Subsystem
|
||||
Vorbedingung: Artikel existiert mit `ScanBarcode = true`
|
||||
Fakt: `BarcodeBL` (`BarcodeBL.cs`) mit 57.496 Bytes verwaltet Barcodes/Seriennummern. `BarcodeConditionBL` (`BarcodeConditionBL.cs`) verwaltet Barcode-Bedingungen. `BarcodeHistoryBL` (`BarcodeHistoryBL.cs`) protokolliert Barcode-Änderungen. `ArticleBL` verwendet `BarcodeBL.GetBarcodesThroughPaging()` für Seriennummern-Suche und -Validierung. `cfn_BarcodeCount` ist eine SQL-Funktion für Barcode-Zählung.
|
||||
Aussage: Die Barcode-Komponente soll Seriennummern und Barcodes mit Bedingungen, Historie und Lagerzuordnung verwalten.
|
||||
Ergebnis: Seriennummern sind eindeutig zugeordnet und historisiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/BarcodeBL.cs` – Klasse `BarcodeBL` mit 57.496 Bytes – Begründung: Zentrale Barcode/Seriennummern-Verwaltung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/BarcodeHistoryBL.cs` – Klasse `BarcodeHistoryBL` – Begründung: Historisierung von Barcode-Änderungen.
|
||||
Tracelinks: SyRS-011, StRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Seriennummernverwaltung ist für tracking-pflichtige Artikel erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-027: Lagerverwaltung mit Haupt- und Nebenlägern
|
||||
|
||||
ID: SwRS-027
|
||||
Titel: Lagerverwaltung mit Haupt- und Nebenlägern
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Storage-Subsystem
|
||||
Vorbedingung: Lager ist konfiguriert
|
||||
Fakt: `StorageBL` (`StorageBL.cs`) mit 45.213 Bytes verwaltet Lagerorte. `BranchBL.SaveAssignedSecondaryStocks()` weist Filialen Nebenlager zu mit `IsDefault`-Flag. `ArticleBL` verwendet `ArticleStockInfo` mit `SecondaryStorageI3D` und `Quantity`. `SecondStockArticleBL` (`SecondStockArticleBL.cs`) mit 45.463 Bytes verwaltet Nebenlager-Artikel. `InventoryArticlePool` (`InventoryArticlePool.cs`) ist ein Pool für Inventurartikel.
|
||||
Aussage: Die Storage-Komponente soll Haupt- und Nebenlager mit Filialzuordnung, Bestandsführung und Inventurverwaltung verwalten.
|
||||
Ergebnis: Lagerbestände sind pro Lagerort korrekt geführt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Storage/StorageBL.cs` – Klasse `StorageBL` mit 45.213 Bytes – Begründung: Zentrale Lagerverwaltung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Company/BranchBL.cs` – Methode `SaveAssignedSecondaryStocks()` mit `IsDefault`-Flag – Begründung: Filial-Lager-Zuordnung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/SecondStockArticleBL.cs` – Klasse `SecondStockArticleBL` – Begründung: Nebenlager-Artikel-Verwaltung.
|
||||
Tracelinks: SyRS-009, StRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Lagerverwaltung mit Haupt-/Nebenlägern ist für mehrstufige Lager erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-028: Datenbank-Schema und MSSQL-Abhängigkeiten
|
||||
|
||||
ID: SwRS-028
|
||||
Titel: Datenbank-Schema und MSSQL-Abhängigkeiten
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal: Übertragbarkeit
|
||||
Akteur: Datenzugriffs-Subsystem
|
||||
Vorbedingung: MSSQL-Datenbank ist verfügbar
|
||||
Fakt: `SSMS_DB_SCHEMA.sql` mit 3.266.626 Bytes enthält das vollständige Datenbankschema. Tabellennamen sind teilweise deutsch (Kunden, Kreditor, Anschrif, Personen, ARTIK, Sichtrus, Sichmemb, Sichgrup). Stored Procedures und Funktionen (`cfn_BarcodeCount`) werden verwendet. `GenericStoredProcedureDAO` führt Stored Procedures aus. `StringOrBinaryDataWouldBeTruncatedEventListener` behandelt MSSQL-spezifische Truncation.
|
||||
Aussage: Die Datenzugriffskomponente ist eng an MSSQL gebunden mit deutschsprachigen Tabellennamen, Stored Procedures und MSSQL-spezifischen Event-Listenern. [HYPOTHESE] Die genaue Anzahl und Struktur der Tabellen konnte nicht vollständig aus dem 3,2 MB großen Schema-Skript extrahiert werden; eine detaillierte Schemaanalyse ist für die Migrationsplanung erforderlich.
|
||||
Ergebnis: Daten werden in MSSQL gespeichert.
|
||||
Belege:
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` – 3.266.626 Bytes großes Schema-Skript – Begründung: Vollständiges MSSQL-Datenbankschema.
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/GenericStoredProcedureDAO.cs` – Klasse `GenericStoredProcedureDAO` mit 20.244 Bytes – Begründung: Stored-Procedure-Ausführung.
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/StringOrBinaryDataWouldBeTruncatedEventListener.cs` – Begründung: MSSQL-spezifische Behandlung.
|
||||
Tracelinks: SyRS-021
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: veraltet – MSSQL-Abhängigkeit und deutschsprachige Tabellennamen sollten im Zielsystem durch eine moderne, englischsprachige Schema-Struktur ersetzt werden.
|
||||
Status: HYPOTHESE
|
||||
|
||||
---
|
||||
|
||||
### SwRS-029: Prozess-Engine mit C-Flow
|
||||
|
||||
ID: SwRS-029
|
||||
Titel: Prozess-Engine mit C-Flow
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Prozess-Subsystem
|
||||
Vorbedingung: Prozessdefinition existiert
|
||||
Fakt: `ProcessBL` (`ProcessBL.cs`) mit 28.659 Bytes verwaltet Prozesse. `SelfCareBL` (`SelfCareBL.cs`) mit 22.920 Bytes implementiert Self-Care-Formulare. `CentronRights.md` erwähnt "C-FLOW Ticketvorlagen" mit Rechten `EDIT_CFLOW_TICKETPATTERN`, `CREATE_NEW_CFLOW_TICKETPATTERN`, `DELETE_CFLOW_TICKETTPATERN`. `MailTemplateReferences` hat SelfCareForm-Referenzen. `AppointmentRequestBL` (`AppointmentRequestBL.cs`) verwaltet Terminanfragen.
|
||||
Aussage: Die Prozess-Komponente soll geschäftsprozessorientierte Workflows mit C-Flow-Ticketvorlagen und Self-Care-Formularen verwalten. [HYPOTHESE] Die genaue Architektur und Semantik der C-Flow-Prozess-Engine konnte aus dem Code nicht vollständig bestimmt werden; ob C-Flow eine separate Prozess-Engine oder ein Konfigurations-Framework für Ticket-Templates ist, erfordert weitere Analyse.
|
||||
Ergebnis: Prozesse werden mit Ticketvorlagen und Formularen ausgeführt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Processes/ProcessBL.cs` – Klasse `ProcessBL` mit 28.659 Bytes – Begründung: Prozessverwaltung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/SelfCare/SelfCareBL.cs` – Klasse `SelfCareBL` mit 22.920 Bytes – Begründung: Self-Care-Formulare.
|
||||
- [SEKUNDÄR] `CentronRights.md` – C-FLOW-Ticketvorlagen-Rechte – Begründung: Dokumentiert C-Flow-Funktionalität.
|
||||
Tracelinks: StRS-006
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Prozessautomatisierung ist für Effizienz erforderlich.
|
||||
Status: HYPOTHESE
|
||||
|
||||
---
|
||||
|
||||
### SwRS-030: RMA- und Werkstattverwaltung
|
||||
|
||||
ID: SwRS-030
|
||||
Titel: RMA- und Werkstattverwaltung
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: CustomerArea-Subsystem
|
||||
Vorbedingung: Kunde hat Artikel zur Reparatur angemeldet
|
||||
Fakt: `RmaBL` (`RmaBL.cs`) mit 110.899 Bytes ist die zentrale RMA-Verwaltung. `RmaSendKindBL` (`RmaSendKindBL.cs`) verwaltet Versandarten. Artikel haben RMA-spezifische Eigenschaften (`RMAInfo` in `AccountSuppliers`). `MailTemplateReferences` definiert RMA-Mailvorlagen für Kunden (`RMACustomer`) und Lieferanten (`RMACreditor`). `CentronObjectKindNumeric` definiert `RMA` und Unterklassen.
|
||||
Aussage: Die CustomerArea-Komponente soll eine umfassende RMA- und Werkstattverwaltung mit Versandarten, Kunden- und Lieferanten-Kommunikation und Mailvorlagen bieten.
|
||||
Ergebnis: RMA-Fälle sind mit Status, Kommunikation und Kosten erfasst.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/CustomerArea/RmaBL.cs` – Klasse `RmaBL` mit 110.899 Bytes – Begründung: Zentrale RMA-Verwaltung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/CustomerArea/RmaSendKindBL.cs` – Klasse `RmaSendKindBL` – Begründung: Versandarten-Verwaltung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.Interfaces/Mail/Templates/MailTemplateReferences.cs` – `RMACustomer` und `RMACreditor` Vorlagen – Begründung: RMA-Kommunikation.
|
||||
Tracelinks: StRS-013
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – RMA-Verwaltung ist für IT-Dienstleister und Systemhäuser erforderlich.
|
||||
Status: belegt
|
||||
+571
@@ -0,0 +1,571 @@
|
||||
# System Requirements Specification (SyRS)
|
||||
|
||||
**System:** c-entron ERP-Suite
|
||||
**Spezifikationsversion:** 1.0
|
||||
**Datum:** 2026-08-28
|
||||
**Standard:** ISO/IEC/IEEE 29148:2018
|
||||
|
||||
---
|
||||
|
||||
### SyRS-001: Mehrstufige Authentifizierung
|
||||
|
||||
ID: SyRS-001
|
||||
Titel: Mehrstufige Authentifizierung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Benutzer meldet sich an
|
||||
Fakt: `AuthenticatorFactory.GetMainAuthenticator()` wählt basierend auf `SystemAuthenticationMethod` (None, Basic, ActiveDirectory, OpenIdConnect) den Authentifikator. Bei `BasicAuthObject` wird `GetAuthenticationKindFromUserName()` aufgerufen, das `AuthentificationKind` des Benutzers ermittelt. Ein `FallbackAuthenticator` fällt bei Fehlschlag der Hauptmethode auf die Basis-Methode zurück. OpenIDConnect erfordert Lizenz (`LicenseGuids.OpenIDConnectAuthentication`) und aktivierte JWT-Einstellung.
|
||||
Aussage: Das System soll die Authentifizierungsmethode basierend auf Systemeinstellung und Benutzer-Art konfigurieren, mit Fallback-Mechanismus und Lizenzprüfung für OpenID Connect.
|
||||
Ergebnis: Authentifizierung erfolgt mit der korrekten Methode; OpenIDConnect nur bei Lizenz und aktiviertem JWT.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs` – Methode `GetAuthenticatorWithSystemAuth()`, `GetFromBasicAuth()`, `GetFromOpenIdConnectAuth()` mit `licenseManager.HasLicense(LicenseGuids.OpenIDConnectAuthentication)` – Begründung: Implementiert die Authentifikator-Auswahl und Lizenzprüfung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/FallbackAuthenticator.cs` – Klasse `FallbackAuthenticator` – Begründung: Implementiert den Fallback-Mechanismus.
|
||||
Tracelinks: StRS-001, SwRS-001
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Mehrstufige Authentifizierung mit Fallback ist für heterogene Umgebungen erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-002: Zwei-Faktor-Authentifizierung
|
||||
|
||||
ID: SyRS-002
|
||||
Titel: Zwei-Faktor-Authentifizierung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System, Mitarbeiter
|
||||
Vorbedingung: Erster Faktor ist erfolgreich authentifiziert
|
||||
Fakt: `TwoFactorAuthBL` (`TwoFactorAuthBL.cs`) koordiniert die 2FA. `ITwoFactorValidator` (`ITwoFactorValidator.cs`) definiert das Interface. `EmailTwoFactorValidator` (`EmailTwoFactorValidator.cs`) sendet einen Code per E-Mail. `RadiusTwoFactorValidator` (`RadiusTwoFactorValidator.cs`) prüft gegen einen RADIUS-Server. `RadiusClient` und `RadiusPaketParser` implementieren das RADIUS-Protokoll.
|
||||
Aussage: Das System soll einen zweiten Authentifizierungsfaktor per E-Mail oder RADIUS unterstützen, wobei die Methode konfigurierbar ist.
|
||||
Ergebnis: Nach erfolgreichem zweiten Faktor ist die Anmeldung abgeschlossen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs` – Klasse `TwoFactorAuthBL` – Begründung: Koordiniert die 2FA-Validierung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TwoFactor/ITwoFactorValidator.cs` – Interface `ITwoFactorValidator` – Begründung: Definiert das 2FA-Interface.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TwoFactor/RadiusTwoFactorValidator.cs` und `EmailTwoFactorValidator.cs` – Begründung: Konkrete 2FA-Implementierungen.
|
||||
Tracelinks: StRS-001
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – 2FA ist für sicherheitskritische ERP-Systeme erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-003: Rechteprüfung bei Systemzugriff
|
||||
|
||||
ID: SyRS-003
|
||||
Titel: Rechteprüfung bei Systemzugriff
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Benutzer ist angemeldet
|
||||
Fakt: `AppRightsBL.HasUserRight(appUserI3D, rightID)` fragt über SQL auf Tabellen `Sichtrus`/`Sichmemb` die Rechte ab. Die Methode verwendet einen Cache (`Session.Advanced.Cache.GetOrAdd`). `CheckRightsFromUser()` prüft mehrere Rechte in einer Abfrage. `Authenticator.ValidateRights()` prüft `DisallowingRight` und `RequiredRight` pro Applikation.
|
||||
Aussage: Das System soll bei jedem Funktionszugriff die Benutzerrechte prüfen, mit Caching für Performance und applikationsspezifischen Pflicht-/Verbotsrechten.
|
||||
Ergebnis: Unberechtigter Zugriff wird verweigert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `HasUserRight()` mit `Session.Advanced.Cache.GetOrAdd($"AllRightsFromAppUser{appUserI3D}", ...)` und SQL auf `Sichtrus`/`Sichmemb` – Begründung: Implementiert die zentrale Rechteprüfung mit Caching.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs` – Methode `ValidateRights()` mit `applicationKind.DisallowingRight` und `applicationKind.RequiredRight` – Begründung: Applikationsspezifische Rechteprüfung bei Login.
|
||||
Tracelinks: StRS-002, SwRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Zentrale Rechteprüfung ist sicherheitskritisch.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-004: Benutzerkontodeaktivierung
|
||||
|
||||
ID: SyRS-004
|
||||
Titel: Benutzerkontodeaktivierung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Benutzer versucht sich anzumelden
|
||||
Fakt: `Authenticator.ValidateAppUser()` prüft `IsAccountDisabled`, `AccountDisabledFromDate` und `AccountDisabledToDate`. Wenn `DateTime.Today` innerhalb der Deaktivierungsspanne liegt, wird der Login verweigert. Zudem prüft `EmployeeBL.IsActiveEmployeeCompact()` die Einstellungs- und Austrittstermine.
|
||||
Aussage: Das System soll Benutzerkonten basierend auf Checkbox-Status und Datumsspannen (von/bis) deaktivieren und die Anmeldung für deaktivierte Mitarbeiter verweigern.
|
||||
Ergebnis: Deaktivierte Benutzer können sich nicht anmelden.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs` – Methode `ValidateAppUser()` mit `user.IsAccountDisabled`, `AccountDisabledFromDate`, `AccountDisabledToDate` – Begründung: Implementiert die Deaktivierungsprüfung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs` – Aufruf `_employeeBl.IsActiveEmployeeCompact(user.Employee)` – Begründung: Prüft die aktive Beschäftigung.
|
||||
Tracelinks: StRS-001
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Benutzerkontodeaktivierung ist sicherheitskritisch.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-005: Passwortänderung und -prüfung
|
||||
|
||||
ID: SyRS-005
|
||||
Titel: Passwortänderung und -prüfung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Mitarbeiter, Web-Account-Kunde
|
||||
Vorbedingung: Benutzer ist angemeldet
|
||||
Fakt: `UsersBL.ChangeOwnPassword()` prüft das aktuelle Passwort über `SHA1Decoder.GetDecodedSHA1String()`. Bei externer Authentifizierung (AD/Entra) wird die Änderung verweigert. `UpdatePassword()` prüft `PasswordMinLength`. `IsValidAppUserPassword()` validiert die Mindestlänge. Für Web-Accounts: `WebAccountBL.UpdatePassword()`.
|
||||
Aussage: Das System soll Passwortänderungen nur nach Verifikation des aktuellen Passworts und mit Mindestlängenprüfung zulassen, und für extern authentifizierte Benutzer (AD/Entra) die Änderung des c-entron-Passworts verweigern.
|
||||
Ergebnis: Passwort wird geändert oder mit Fehlermeldung abgelehnt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/UsersBL.cs` – Methode `ChangeOwnPassword()` mit `usesExternalAuth`-Prüfung und `SHA1Decoder.GetDecodedSHA1String(currentPassword)` – Begründung: Implementiert die Passwortänderungslogik mit AD/Entra-Ausschluss.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/UsersBL.cs` – Methode `IsValidAppUserPassword()` mit `newPassword?.Length < appUser.PasswordMinLength` – Begründung: Mindestlängenprüfung.
|
||||
Tracelinks: StRS-001, SwRS-003
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Passwortprüfung ist sicherheitskritisch. Die Verwendung von SHA1 sollte im Zielsystem durch ein moderneres Verfahren ersetzt werden.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-006: Mandantentrennung und Filialzuordnung
|
||||
|
||||
ID: SyRS-006
|
||||
Titel: Mandantentrennung und Filialzuordnung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Benutzer ist einer Filiale zugeordnet
|
||||
Fakt: `AppRightsBL.GetAllRightGroups(currentUser)` filtert bei `MANAGE_RIGHTS_ONLY_OWN_BRANCH` nach `f.BranchI3D == currentUser.Employee.BranchI3D`. `SaveRightGroup()` prüft: wenn `MANAGE_RIGHTS_ONLY_OWN_BRANCH` und `user.Employee.BranchI3D != appGroup.BranchI3D`, dann Fehler. `DeleteRightGroup()` prüft dieselbe Bedingung.
|
||||
Aussage: Das System soll bei aktivierter filialbeschränkter Rechteverwaltung verhindern, dass Benutzer Rechtegruppen anderer Filialen erstellen, ändern oder löschen.
|
||||
Ergebnis: Filialübergreifende Rechteverwaltung wird verhindert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `GetAllRightGroups()` mit `MANAGE_RIGHTS_ONLY_OWN_BRANCH`-Filter – Begründung: Durchsetzung der Filialbeschränkung beim Lesen.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `SaveRightGroup()` mit Fehler "Sie haben nicht genügend Rechte um eine Gruppe für eine andere Filiale anlegen zu können." – Begründung: Durchsetzung der Filialbeschränkung beim Schreiben.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `CopyRightGroup()` mit Filialprüfung – Begründung: Durchsetzung beim Kopieren.
|
||||
Tracelinks: StRS-003, SwRS-004
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Mandantentrennung ist für mehrfilialige Organisationen erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-007: Lizenzprüfung
|
||||
|
||||
ID: SyRS-007
|
||||
Titel: Lizenzprüfung
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: System
|
||||
Vorbedingung: Benutzer meldet sich an einer Applikation an
|
||||
Fakt: `Authenticator.GetTicket()` ruft `LicenseManager.CheckLicense(applicationKind, appVersion, userResult)` auf. Wenn keine Lizenz verfügbar ist, wird ein Fehler zurückgegeben. Nur bei erfolgreicher Prüfung wird ein Ticket erstellt. `AuthenticatorFactory.GetFromOpenIdConnectAuth()` prüft `licenseManager.HasLicense(LicenseGuids.OpenIDConnectAuthentication)`.
|
||||
Aussage: Das System soll vor der Ticketerstellung die verfügbaren Lizenzen prüfen und die Anmeldung verweigern, wenn keine freie Lizenz verfügbar ist.
|
||||
Ergebnis: Anmeldung nur mit verfügbarer Lizenz erfolgreich.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs` – Methode `GetTicket()` mit `LicenseManager.CheckLicense(applicationKind, appVersion, userResult)` – Begründung: Lizenzprüfung vor Ticketerstellung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs` – Klasse `LicenseManager` mit Methode `CheckLicense()` – Begründung: Zentrale Lizenzprüfungslogik.
|
||||
Tracelinks: StRS-015, SwRS-019
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Lizenzprüfung ist für den kommerziellen Betrieb erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-008: DSGVO-Löschung
|
||||
|
||||
ID: SyRS-008
|
||||
Titel: DSGVO-Löschung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Administrator (mit DSGVO-Recht)
|
||||
Vorbedingung: Administrator hat Recht `DSGVO_DELETE_CONTACT`
|
||||
Fakt: `DataSecurityBL.DsgvoDeleteRightDeleteContacts()` prüft `currentUser.HasUserRight(UserRightsConst.DsgvoModule.DSGVO_DELETE_CONTACT)`. Die Methode `DoDeleteContactPerson()` löscht personenbezogene Felder (Ansprech, AnsprechVorname, Geburtsdatum, Tel1-5, Fax1-2, Email1-2, Bild, etc.), setzt `IsDsgvoDeleted = true`, `DsgvoDeletedEmployeeI3D` und `DsgvoDeletedDate` und schreibt ein Löschprotokoll. Web-Accounts und soziale Netzwerke werden ebenfalls gelöscht.
|
||||
Aussage: Das System soll die DSGVO-konforme Löschung von Ansprechpartnerdaten mit Berechtigungsprüfung, vollständiger Löschung aller personenbezogenen Felder, Protokollierung und Löschung verknüpfter Web-Accounts und sozialer Netzwerke durchführen.
|
||||
Ergebnis: Personenbezogene Daten sind gelöscht, Löschprotokoll ist erstellt, Verknüpfungen sind entfernt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` – Methode `DsgvoDeleteRightDeleteContacts()` mit `HasUserRight(UserRightsConst.DsgvoModule.DSGVO_DELETE_CONTACT)` – Begründung: Durchsetzung der Berechtigungsprüfung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` – Methode `DoDeleteContactPerson()` mit Feldlöschung und `IsDsgvoDeleted`/`DsgvoDeletedEmployeeI3D`/`DsgvoDeletedDate` – Begründung: Implementiert die Datenlöschung und Protokollierung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` – Methode `DoDeleteContactPersonWebAccounts()` und `DoDeleteContactPersonSocialNetworks()` – Begründung: Löschung verknüpfter Daten.
|
||||
Tracelinks: StRS-007, SwRS-009
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – DSGVO-Löschung ist gesetzlich vorgeschrieben.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-009: Belegstatus-Übergänge
|
||||
|
||||
ID: SyRS-009
|
||||
Titel: Belegstatus-Übergänge
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Beleg existiert im System
|
||||
Fakt: `ReceiptState`-Enum definiert Belegstatus (Active=1 etc.). `CentronObjectKindNumeric` definiert Belegarten und Erweiterungsmethoden `IsCustomerReceipt()` und `IsSupplierReceipt()`. `ArticleBL` referenziert Belegtabellen `AngKopf`/`AngPos` (Angebot), `AufKopf`/`AufPos` (Auftrag), `LiefKopf`/`LiefPos` (Lieferschein), `VertragKopf`/`VertragPos` (Vertrag). Belegpositionen können mit `SondervereinbarungI3D` versehen sein (Sonderpreise).
|
||||
Aussage: Das System soll Belegstatus-Übergänge über die Belegarten Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift und Vertrag verwalten, mit Positionsbearbeitung und Sonderpreis-Zuordnung.
|
||||
Ergebnis: Belege haben korrekten Status und korrekte Positionen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs` – Enum und Erweiterungsmethoden – Begründung: Definiert die Belegart-Hierarchie.
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs` – Enum `ReceiptState` – Begründung: Definiert Belegstatus.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Referenzen auf `AngKopf`/`AufKopf`/`LiefKopf`/`VertragPos` mit `SondervereinbarungI3D` – Begründung: Belegtabellenstruktur und Sonderpreis-Zuordnung.
|
||||
Tracelinks: StRS-004, SwRS-004
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Belegstatusverwaltung ist Kern des ERP-Systems.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-010: Nummernkreisvergabe
|
||||
|
||||
ID: SyRS-010
|
||||
Titel: Nummernkreisvergabe
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Neue Belegnummer oder Artikelnummer wird benötigt
|
||||
Fakt: `NumberGroupBL.GetNextNumber()` ermittelt die nächste Nummer basierend auf `NumberGroupEnum`. Die Methode verwendet `UpdateBuilder().Set(s => s.Current, nextNumber).Update()` und prüft, ob genau 1 Zeile geändert wurde (Concurrency-Schutz). Es wird zusätzlich geprüft, ob die Nummer bereits in der Zieltabelle existiert (z. B. `Kunden` für Kundennummern). `CreateNumberGroups()` erstellt Nummernkreise pro Mandant und Filiale.
|
||||
Aussage: Das System soll fortlaufende, eindeutige Nummern für Belege und Stammdaten vergeben, mit Concurrency-Schutz gegen gleichzeitige Vergabe und Validierung gegen existierende Einträge.
|
||||
Ergebnis: Eindeutige, fortlaufende Nummer wird vergeben.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs` – Methode `GetNextNumber()` mit `UpdateBuilder().Set(s => s.Current, nextNumber).Update()` und Prüfung `rowCountChanged == 1` – Begründung: Concurrency-sichere Nummernvergabe.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs` – Methode `FindNextNumber()` mit `SELECT COUNT(*) ... WHERE {fieldName} = {counter}` – Begründung: Validierung gegen existierende Einträge.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs` – Methode `CreateNumberGroups(mandantI3D, branchI3D)` – Begründung: Pro-Filial-Erstellung.
|
||||
Tracelinks: StRS-003, StRS-004, SwRS-004
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Eindeutige Nummernvergabe ist für Belegidentifikation erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-011: Artikelberechtigungsprüfung
|
||||
|
||||
ID: SyRS-011
|
||||
Titel: Artikelberechtigungsprüfung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Mitarbeiter speichert einen Artikel
|
||||
Fakt: `ArticleBL.CheckUserRightBeforeSave()` prüft Rechte: `STORE_ARTICLE` (Speichern), `CREATE_NEW_ARTICLE` (Neuanlage), `CHANGE_ARTICLE_PRICE` (Preisänderung), `CHANGE_SERIALNUMBER_REQUIRED_FLAG` (SN-Pflicht). Bei Preisänderungen wird `IsDirtyProperty()` für Price1-4, EVP, MinPrice, RawEk1/2 geprüft. `CheckSpecialUserRightBeforeSave()` prüft `EDIT_MaterialGroup` und `NOT_CHANGEABLE_ARTICLE_PROPERTIES` und revertiert nicht autorisierte Änderungen.
|
||||
Aussage: Das System soll beim Speichern von Artikeln prüfen, ob der Benutzer die erforderlichen Rechte hat, und nicht autorisierte Änderungen an geschützten Eigenschaften automatisch revertieren.
|
||||
Ergebnis: Nur berechtigte Änderungen werden gespeichert; nicht berechtigte Feldänderungen werden zurückgesetzt.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `CheckUserRightBeforeSave()` mit `CheckRightsFromUser()` für `STORE_ARTICLE`, `CREATE_NEW_ARTICLE`, `CHANGE_ARTICLE_PRICE`, `CHANGE_SERIALNUMBER_REQUIRED_FLAG` und `IsDirtyProperty()`-Prüfungen – Begründung: Durchsetzung der Artikelberechtigungen.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `CheckSpecialUserRightBeforeSave()` mit `GetOriginalEntityProperty()` für Revertierung – Begründung: Automatische Zurücksetzung nicht autorisierter Änderungen.
|
||||
Tracelinks: StRS-005, SwRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Artikelberechtigungsprüfung ist sicherheitskritisch.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-012: Ticket-Sichtbarkeitsrechte
|
||||
|
||||
ID: SyRS-012
|
||||
Titel: Ticket-Sichtbarkeitsrechte
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Mitarbeiter greift auf Tickets zu
|
||||
Fakt: `CentronRights.md` definiert einschränkende Rechte: `SHOW_HELPDESK_ONLY_OWN` (nur eigene Tickets), `SHOW_HELPDESK_ONLY_OWN_BRANCH` (nur Filial-Tickets), `ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS` (Zuweisung nur an eigene Abteilungen). `EDIT_TIME` und `OWN_TIME_EDIT` steuern die Zeiterfassungsbearbeitung. `MOVE_HELPDESK_TIMER` und `DELETE_HELPDESK_TIMER` steuern das Verschieben/Löschen von Zeiterfassungen, sofern der Ticket nicht Teil einer Rechnung ist.
|
||||
Aussage: Das System soll die Ticket-Sichtbarkeit basierend auf einschränkenden Rechten (nur eigene, nur eigene Filiale) steuern und die Bearbeitung von Zeiterfassungen nur für berechtigte Benutzer zulassen.
|
||||
Ergebnis: Mitarbeiter sehen nur die für sie freigegebenen Tickets.
|
||||
Belege:
|
||||
- [PRIMÄR] `CentronRights.md` – Rechte `SHOW_HELPDESK_ONLY_OWN`, `SHOW_HELPDESK_ONLY_OWN_BRANCH`, `ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS`, `OWN_TIME_EDIT`, `MOVE_HELPDESK_TIMER`, `DELETE_HELPDESK_TIMER` – Begründung: Dokumentiert die einschränkenden Rechte.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methode `CheckRightsFromUser()` – Begründung: Zentrale Rechteprüfung, die für Ticket-Rechte verwendet wird.
|
||||
Tracelinks: StRS-006, SwRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Ticket-Sichtbarkeitsrechte sind für den Helpdesk-Betrieb erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-013: Web-Account-Authentifizierung und -Rechte
|
||||
|
||||
ID: SyRS-013
|
||||
Titel: Web-Account-Authentifizierung und -Rechte
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Web-Account-Kunde
|
||||
Vorbedingung: Kunde hat Web-Account im Adressstamm
|
||||
Fakt: `AuthenticatorFactory.GetFromWebAccountAuth()` erstellt `WebAccountAuthenticator`. `AppRightsBL.HasWebAccountRight()` fragt über SQL `WebAccountsRights` ab. `CheckWebRightsFromUser()` prüft mehrere Web-Rechte in einer Abfrage. `GetAllWebRightsFromWebAccount()` cached die Web-Rechte. `WebAccountAuthObject` unterscheidet sich von `BasicAuthObject`.
|
||||
Aussage: Das System soll Web-Account-Kunden ein separates Authentifizierungs- und Rechtesystem mit eigenem Cache bieten.
|
||||
Ergebnis: Web-Account-Kunden authentifizieren sich separat und haben nur ihre zugeordneten Web-Rechte.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs` – Methode `GetFromWebAccountAuth()` – Begründung: Erstellt den Web-Account-Authentifikator.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methoden `HasWebAccountRight()`, `CheckWebRightsFromUser()`, `GetAllWebRightsFromWebAccount()` mit SQL auf `WebAccountsRights` – Begründung: Separates Web-Rechtesystem.
|
||||
Tracelinks: StRS-008, SwRS-014
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Separates Web-Rechtesystem ist für das Kundenportal erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-014: EDI-Dispatch und Gateway-Verwaltung
|
||||
|
||||
ID: SyRS-014
|
||||
Titel: EDI-Dispatch und Gateway-Verwaltung
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: EDI-Gateway-Einstellungen sind konfiguriert
|
||||
Fakt: `EDIDispatcherBL` (`EDIDispatcherBL.cs`) mit 14.179 Bytes steuert den Dispatch. `EDIGatewaySettingBL` (`EDIGatewaySettingBL.cs`) verwaltet Einstellungen. `EDILogBL` (`EDILogBL.cs`) protokolliert EDI-Verarbeitungen. Gateway-Verzeichnisse: `EDI_Alltron/`, `EDI_ALSO/`, `EDI_AlsoCH/`, `Concerto/`, `EDI_EGIS/`, `EDI_Herweck/`, `EDI_Komsa/`, `OpenTrans/`, `OpenTrans1_0/`, `ZUGFeRD21_Extended/`.
|
||||
Aussage: Das System soll den EDI-Dispatch mit Konfigurationsverwaltung und Protokollierung für mehrere Lieferanten-Standards durchführen.
|
||||
Ergebnis: EDI-Nachrichten werden korrekt verarbeitet und protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs` – Klasse `EDIDispatcherBL` – Begründung: Zentrale Dispatch-Logik.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/EDI/EDILogBL.cs` – Klasse `EDILogBL` – Begründung: Protokollierung der EDI-Verarbeitung.
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/` – Verzeichnisse für Alltron, ALSO, EGIS, Komsa, OpenTrans, ZUGFeRD – Begründung: Konkrete EDI-Gateway-Implementierungen.
|
||||
Tracelinks: StRS-009, SwRS-015
|
||||
Konsolidierung: Kandidat: EDI-Gateways für Alltron, ALSO, EGIS und Komsa sollten zu einem konfigurierbaren Adapter konsolidiert werden.
|
||||
Übernahmewürdigkeit: übernehmen – EDI-Dispatch ist für automatisierten B2B-Datenaustausch erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-015: Reportgenerierung und PDF-Export
|
||||
|
||||
ID: SyRS-015
|
||||
Titel: Reportgenerierung und PDF-Export
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Beleg oder Reportdaten sind vorhanden
|
||||
Fakt: `ReportDataBL` (`ReportDataBL.cs`) mit 94.267 Bytes verwaltet Berichtsdaten. `FastReportHelper` (`FastReportHelper.cs`) integriert FastReport. `ReportGroupBL` (`ReportGroupBL.cs`) mit 32.455 Bytes verwaltet Reportgruppen. Verzeichnisse `PdfExport/`, `PdfStategy/` (sic), `CustomPdfGenerators/`, `ReplacementBLs/`, `ReportObjects/`, `Templates/`.
|
||||
Aussage: Das System soll Berichte und Belegdokumente mit vorlagenbasierter Erstellung, Variablenersetzung und PDF-Export generieren.
|
||||
Ergebnis: PDF-Dokument oder Report ist generiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/ReportEngine/ReportDataBL.cs` – Klasse `ReportDataBL` – Begründung: Zentrale Berichtsdatenverarbeitung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/ReportEngine/FastReportHelper.cs` – Klasse `FastReportHelper` – Begründung: Report-Engine-Integration.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/ReportEngine/PdfExport/` – Begründung: PDF-Export-Implementierung.
|
||||
Tracelinks: StRS-010, SwRS-016
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Reportgenerierung ist für Belegausgabe erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-016: FiBu-Kontenzuordnung
|
||||
|
||||
ID: SyRS-016
|
||||
Titel: FiBu-Kontenzuordnung
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Belegposition mit Artikel und Kunde/Lieferant existiert
|
||||
Fakt: `ArticleBL.DoUpdateReceiptOfferItems()` ruft `ReceiptItemAccountBL.GetProfitAndLossAccount(true, customerI3D, countryI3D, branchI3D, exclusiveOfVAT, articleI3D, ...)` auf. Artikel haben separate Erloeskonten: `RevenueAccount`, `RevenueAccountEU`, `RevenueAccountOverseas`, `RevenueAccountReversecharge` und Aufwandskonten: `ExpenseAccount`, `ExpenseAccountEU`, `ExpenseAccountOverseas`, `ExpenseAccountReversecharge`. `IsReversecharge` ist eine Artikeleigenschaft.
|
||||
Aussage: Das System soll Erloes- und Aufwandskonten basierend auf Kundenland (Inland/EU/Drittland) und Reverse-Charge-Status automatisch ermitteln.
|
||||
Ergebnis: Korrektes FiBu-Konto ist zugewiesen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Methode `DoUpdateReceiptOfferItems()` mit `itemBL.GetProfitAndLossAccount(true, customerI3D, countryI3D, branchI3D, exclusiveOfVAT, articleI3D, ...)` – Begründung: Aufruf der Kontenzuordnung mit Land und Reverse-Charge.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs` – Artikel-Eigenschaften `RevenueAccount`, `RevenueAccountEU`, `RevenueAccountOverseas`, `RevenueAccountReversecharge`, `IsReversecharge` – Begründung: Separate Konten pro Regions- und Steuerfall.
|
||||
Tracelinks: StRS-011, SwRS-017
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – FiBu-Kontenzuordnung ist für korrekte Buchhaltung erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-017: E-Mail-Vorlagen und Variablenersetzung
|
||||
|
||||
ID: SyRS-017
|
||||
Titel: E-Mail-Vorlagen und Variablenersetzung
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Mailvorlage und Geschäftsobjekt existieren
|
||||
Fakt: `MailTemplateReferences` definiert über 60 statische Vorlagenreferenzen mit `defaultSubject` und `defaultBody`. Verzeichnis `VariableReplacement/` unter `Mail/`. `SalutationAndAgreementReplacementBL` (`SalutationAndAgreementReplacementBL.cs`) ersetzt Anrede- und Abrede-Variablen. `MailSettingsBL` (`MailSettingsBL.cs`) verwaltet Mail-Einstellungen. `MailSignatureBL` (`MailSignatureBL.cs`) verwaltet Signaturen.
|
||||
Aussage: Das System soll E-Mails mit vorlagenbasierter Generierung, automatischer Variablenersetzung (Anrede, Abrede, Belegdaten) und konfigurierbaren Signaturen erstellen.
|
||||
Ergebnis: Personalisierte E-Mail ist generiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/Mail/Templates/MailTemplateReferences.cs` – Über 60 statische `MailTemplateReference`-Definitionen – Begründung: Definiert die Vorlagenstruktur.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Mail/SalutationAndAgreementReplacementBL.cs` – Klasse `SalutationAndAgreementReplacementBL` – Begründung: Implementiert die Variablenersetzung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Mail/MailSignatureBL.cs` – Begründung: Signaturverwaltung.
|
||||
Tracelinks: StRS-012, SwRS-018
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Vorlagenbasierte E-Mail-Generierung ist für die Kommunikation erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-018: Produktions- und Projektverwaltung
|
||||
|
||||
ID: SyRS-018
|
||||
Titel: Produktions- und Projektverwaltung
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: Produktions-/Projektdaten sind vorhanden
|
||||
Fakt: `ProductionBL` (`ProductionBL.cs`) mit 13.132 Bytes und `ProductionOrderBL` (`ProductionOrderBL.cs`) mit 9.445 Bytes verwalten Produktionsaufträge. `ProjectBL` (`ProjectBL.cs`) verwaltet Projekte. Artikel-Eigenschaft `IsProductionArticle` markiert Produktionsartikel. `ArticleWorkItemBL` (`ArticleWorkItemBL.cs`) verwaltet Arbeitsgänge.
|
||||
Aussage: Das System soll Produktionsaufträge und Projekte mit zugehörigen Artikeln und Arbeitsgängen verwalten.
|
||||
Ergebnis: Produktionsaufträge und Projekte sind mit Artikeln und Arbeitsgängen verknüpft.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Production/ProductionBL.cs` – Klasse `ProductionBL` – Begründung: Produktionsverwaltung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleWorkItemBL.cs` – Klasse `ArticleWorkItemBL` – Begründung: Verwaltung von Arbeitsgängen für Artikel.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Projects/ProjectBL.cs` – Begründung: Projektverwaltung.
|
||||
Tracelinks: StRS-013
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Produktionsverwaltung ist für Systemhäuser mit Eigenfertigung relevant.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-019: RiverDivo-Integration
|
||||
|
||||
ID: SyRS-019
|
||||
Titel: RiverDivo-Integration
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System
|
||||
Vorbedingung: RiverDivo-Verbindung ist konfiguriert
|
||||
Fakt: `RiverDivoBL` (`RiverDivoBL.cs`) mit 25.221 Bytes und `RiverConnectionBL` (`RiverConnectionBL.cs`) mit 11.101 Bytes implementieren die Integration. `SimpleRiverCentronClient` (`SimpleRiverCentronClient.cs`) ist ein HTTP-Client. `RBContractArticleRefInfo` ist eine Referenzinfo-Klasse. Die genaue fachliche Bedeutung von RiverDivo ist aus dem Code nicht vollständig ersichtlich.
|
||||
Aussage: Das System soll eine HTTP-basierte Integration mit der RiverDivo-Plattform bereitstellen. [HYPOTHESE] Die genaue fachliche Rolle von RiverDivo (Asset-Management, Monitoring, etc.) konnte nicht eindeutig bestimmt werden.
|
||||
Ergebnis: Daten werden mit RiverDivo ausgetauscht.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/RiverDivo/RiverDivoBL.cs` – Klasse `RiverDivoBL` – Begründung: Implementiert die Geschäftslogik.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs` – Klasse `RiverConnectionBL` – Begründung: Verbindungsverwaltung.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/RiverDivo/SimpleRiverCentronClient.cs` – Begründung: HTTP-Client.
|
||||
Tracelinks: StRS-014
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Externe Integrationen müssen erhalten bleiben.
|
||||
Status: HYPOTHESE
|
||||
|
||||
---
|
||||
|
||||
### SyRS-020: Volltextsuche und Indexierung
|
||||
|
||||
ID: SyRS-020
|
||||
Titel: Volltextsuche und Indexierung
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal: Wartbarkeit
|
||||
Akteur: Mitarbeiter
|
||||
Vorbedingung: Index ist aufgebaut
|
||||
Fakt: `IndexSearchBL` (`IndexSearchBL.cs`) implementiert die Suche. `GermanAnalyzer` (`GermanAnalyzer.cs`) mit 20.050 Bytes implementiert einen deutschen Wortstamm-Analyzer. `IndexBuilder` (`IndexBuilder.cs`) baut den Index auf. `ObjectIndexingFailedException` behandelt Indizierungsfehler. Verzeichnis `Indexes/` enthält Index-Definitionen.
|
||||
Aussage: Das System soll eine Volltextsuche mit deutscher Sprachanalyse (Wortstamm-Erkennung) über alle Geschäftsobjekte bieten.
|
||||
Ergebnis: Suchergebnisse sind nach Relevanz gelistet.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs` – Klasse `IndexSearchBL` – Begründung: Implementiert die Suchlogik.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs` – Klasse `GermanAnalyzer` – Begründung: Deutsche Wortstamm-Analyse.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/IndexSearch/IndexBuilder.cs` – Klasse `IndexBuilder` – Begründung: Index-Aufbau.
|
||||
Tracelinks: StRS-001
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Volltextsuche ist für große Datenbestände erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-021: Datenzugriffsarchitektur (NHibernate)
|
||||
|
||||
ID: SyRS-021
|
||||
Titel: Datenzugriffsarchitektur (NHibernate)
|
||||
Ebene: SyRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal: Wartbarkeit
|
||||
Akteur: System
|
||||
Vorbedingung: Datenbankverbindung ist konfiguriert
|
||||
Fakt: `DAOFactory` (`DAOFactory.cs`) mit 11.714 Bytes erstellt DAOs. `GenericDAO` (`GenericDAO.cs`) mit 25.462 Bytes ist der generische DAO. `DAOSession` (`DAOSession.cs`) verwaltet die NHibernate-Session. `GenericStoredProcedureDAO` (`GenericStoredProcedureDAO.cs`) führt Stored Procedures aus. `SessionCache` cached Entitäten. `TruncateStringsEventListener` und `StringOrBinaryDataWouldBeTruncatedEventListener` behandeln String-Überläufe.
|
||||
Aussage: Das System soll den Datenzugriff über eine NHibernate-basierte DAO-Schicht mit generischem DAO, Session-Management und automatischer String-Trunkierung bereitstellen.
|
||||
Ergebnis: Daten werden über NHibernate persistent gespeichert und geladen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/DAOFactory.cs` – Klasse `DAOFactory` – Begründung: Zentrale DAO-Erstellung.
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/GenericDAO.cs` – Klasse `GenericDAO` – Begründung: Generischer Datenzugriff.
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/TruncateStringsEventListener.cs` – Klasse `TruncateStringsEventListener` – Begründung: Automatische String-Trunkierung.
|
||||
Tracelinks: SwRS-020
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Die DAO-Architektur muss im Zielsystem durch eine moderne Datenzugriffsschicht ersetzt werden.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-022: Performance-Caching für Stammdaten
|
||||
|
||||
ID: SyRS-022
|
||||
Titel: Performance-Caching für Stammdaten
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Performance-Effizienz
|
||||
Akteur: System
|
||||
Vorbedingung: System läuft
|
||||
Fakt: `CachedTableBL` (`CachedTableBL.cs`) mit 101.959 Bytes verwaltet gecachte Tabellen. `AppRightsBL.HasUserRight()` verwendet `Session.Advanced.Cache.GetOrAdd()`. `MandatorBL.GetDefaultMandatorCountryI3D()` verwendet ebenfalls den Cache. `SessionCache` (`SessionCache.cs`) ist die Cache-Infrastruktur.
|
||||
Aussage: Das System soll häufig abgefragte Stammdaten (Rechte, Mandanten, Artikel) zwischenspeichern, um die Antwortzeit zu reduzieren.
|
||||
Ergebnis: Datenbankabfragen für häufige Daten werden minimiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Services/CachedTableBL.cs` – Klasse `CachedTableBL` mit 101.959 Bytes – Begründung: Große Cache-Verwaltung für Stammdaten.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – `Session.Advanced.Cache.GetOrAdd($"AllRightsFromAppUser{appUserI3D}", ...)` – Begründung: Rechte werden gecacht.
|
||||
- [PRIMÄR] `src/backend/Centron.DAO/SessionCache.cs` – Klasse `SessionCache` – Begründung: Cache-Infrastruktur.
|
||||
Tracelinks: SwRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Caching ist für Performance bei großen Datenbeständen erforderlich. [HYPOTHESE] Die genaue Caching-Strategie und Gültigkeitsdauer konnte aus dem Code nicht vollständig abgeleitet werden.
|
||||
Status: HYPOTHESE
|
||||
|
||||
---
|
||||
|
||||
### SyRS-023: Massenänderung von Geschäftsobjekten
|
||||
|
||||
ID: SyRS-023
|
||||
Titel: Massenänderung von Geschäftsobjekten
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Mitarbeiter
|
||||
Vorbedingung: Mitarbeiter hat Massenänderungsrecht
|
||||
Fakt: `MassUpdateBL` (`MassUpdateBL.cs`) mit 50.704 Bytes implementiert die Massenänderung. Die Klasse ist umfangreich und verarbeitet verschiedene Geschäftsobjekt-Typen.
|
||||
Aussage: Das System soll Massenänderungen an Geschäftsobjekten ermöglichen, um mehrere Datensätze effizient zu aktualisieren.
|
||||
Ergebnis: Mehrere Datensätze sind in einem Vorgang aktualisiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs` – Klasse `MassUpdateBL` mit 50.704 Bytes – Begründung: Zentrale Massenänderungslogik.
|
||||
Tracelinks: StRS-001
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Massenänderungen sind für effiziente Datenpflege erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-024: Change-Tracking und Historie
|
||||
|
||||
ID: SyRS-024
|
||||
Titel: Change-Tracking und Historie
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: System
|
||||
Vorbedingung: Geschäftsobjekt wird geändert
|
||||
Fakt: `ChangeTrackingConfigurationAttribute` (`ChangeTrackingConfigurationAttribute.cs`) markiert Entitäten für Change-Tracking mit `CentronObjectKindNumeric`. Verzeichnis `ChangeTracking/History/` unter BL. `ArticleLogBL` (`ArticleLogBL.cs`) schreibt Artikeländerungs-Logs. `ReceiptLogBL` schreibt Belegänderungs-Logs. `AppRightLog` protokolliert Rechteänderungen.
|
||||
Aussage: Das System soll Änderungen an Geschäftsobjekten automatisch protokollieren, mit Attribut-basierter Konfiguration und objektspezifischen Log-Einträgen.
|
||||
Ergebnis: Änderungshistorie ist für jedes verfolgte Objekt verfügbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/ChangeTracking/ChangeTrackingConfigurationAttribute.cs` – Attribut mit `CentronObjectKindNumeric` – Begründung: Markierung von Entitäten für Change-Tracking.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleLogBL.cs` – Klasse `ArticleLogBL` mit `WriteLog()` – Begründung: Artikeländerungsprotokollierung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` – Methoden `WriteAddRightToGroupLog()`, `WriteCreateGroupLog()` etc. – Begründung: Protokollierung von Rechteänderungen.
|
||||
Tracelinks: StRS-002
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – Change-Tracking ist für Nachvollziehbarkeit und Compliance erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-025: Deployment und CI/CD
|
||||
|
||||
ID: SyRS-025
|
||||
Titel: Deployment und CI/CD
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Übertragbarkeit
|
||||
Akteur: System-Dienst
|
||||
Vorbedingung: Code ist im Repository
|
||||
Fakt: `azure/build-pipeline.yml` und `azure-blazor/build-pipeline.yaml` definieren Build-Pipelines. `azure/docker-pipeline.yml` und `docker/` definieren Docker-Konfiguration. `azure/regression-tests-pipeline.yml` und `azure-blazor/playwright-pipeline.yml` definieren Test-Pipelines. `azure/security-pipeline.yaml` definiert Sicherheits-Scans. `deployment/` enthält Deployment-Skripte.
|
||||
Aussage: Das System soll über CI/CD-Pipelines mit Build-, Test-, Sicherheits- und Docker-Deployment-Stufen verfügen.
|
||||
Ergebnis: Automatisierte Builds, Tests und Deployments sind konfiguriert.
|
||||
Belege:
|
||||
- [PRIMÄR] `azure/build-pipeline.yml` – Begründung: Build-Pipeline-Definition.
|
||||
- [PRIMÄR] `azure/docker-pipeline.yml` – Begründung: Docker-Build-Pipeline.
|
||||
- [SEKUNDÄR] `azure/security-pipeline.yaml` – Begründung: Sicherheits-Scan-Pipeline.
|
||||
- [SEKUNDÄR] `azure-blazor/playwright-pipeline.yml` – Begründung: UI-Test-Pipeline.
|
||||
Tracelinks: StRS-015
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen – CI/CD ist für automatisierte Auslieferung erforderlich.
|
||||
Status: belegt
|
||||
+71
@@ -0,0 +1,71 @@
|
||||
# Traceability-Tabelle
|
||||
|
||||
**System:** c-entron ERP-Suite
|
||||
**Datum:** 2026-08-28
|
||||
|
||||
Diese Tabelle stellt die Forward- und Backward-Traceability zwischen StRS, SyRS und SwRS her und verknüpft jede Anforderung mit konkreten Artefaktbelegen.
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---|---|---|---|
|
||||
| StRS-001 | SyRS-001 | SwRS-001 | `Authenticator.cs`, `AuthenticatorFactory.cs` |
|
||||
| StRS-001 | SyRS-002 | — | `TwoFactorAuthBL.cs`, `ITwoFactorValidator.cs`, `EmailTwoFactorValidator.cs`, `RadiusTwoFactorValidator.cs` |
|
||||
| StRS-001 | SyRS-004 | — | `Authenticator.cs` – `ValidateAppUser()` |
|
||||
| StRS-001 | SyRS-005 | SwRS-003 | `UsersBL.cs` – `ChangeOwnPassword()`, `UpdatePassword()` |
|
||||
| StRS-002 | SyRS-003 | SwRS-002 | `AppRightsBL.cs` – `HasUserRight()`, `CheckRightsFromUser()` |
|
||||
| StRS-002 | SyRS-003 | SwRS-010 | `AppRightsBL.cs` – `GetAssignableAdminRightI3Ds()`, `DeleteRightGroup()` |
|
||||
| StRS-002 | SyRS-012 | SwRS-002 | `CentronRights.md` – `SHOW_HELPDESK_ONLY_OWN`, `SHOW_HELPDESK_ONLY_OWN_BRANCH` |
|
||||
| StRS-002 | SyRS-024 | SwRS-023 | `ChangeTrackingConfigurationAttribute.cs`, `ArticleLogBL.cs`, `AppRightsBL.cs` – Logging |
|
||||
| StRS-002 | SyRS-003 | SwRS-025 | `AppRightsBL.cs` – `ResetDefaultRightGroups()`, `DefaultRightsStructure.txt` |
|
||||
| StRS-003 | SyRS-006 | SwRS-004 | `MandatorBL.cs`, `BranchBL.cs`, `AppRightsBL.cs` – `MANAGE_RIGHTS_ONLY_OWN_BRANCH`, `NumberGroupBL.cs` |
|
||||
| StRS-003 | SyRS-010 | SwRS-004 | `NumberGroupBL.cs` – `GetNextNumber()`, `CreateNumberGroups()` |
|
||||
| StRS-004 | SyRS-009 | SwRS-004 | `CentronObjectKindNumeric.cs`, `ReceiptState.cs`, `ArticleBL.cs` – Belegtabellen |
|
||||
| StRS-004 | SyRS-009 | SwRS-013 | `ArticleBL.cs` – `UpdateArticlePositionFromArticleChange()` |
|
||||
| StRS-005 | SyRS-011 | SwRS-005 | `ArticleBL.cs` – `ValidateArticleBeforeSave()`, `CheckUserRightBeforeSave()` |
|
||||
| StRS-005 | SyRS-011 | SwRS-006 | `ArticleBL.cs` – `ApplyRentArticleStockAndSerialConstraints()` |
|
||||
| StRS-005 | SyRS-011 | SwRS-007 | `ArticleBL.cs` – EAN-Prüfziffer in `ValidateArticleBeforeSave()` |
|
||||
| StRS-005 | SyRS-011 | SwRS-008 | `ArticleBL.cs` – `UpdatePartList()` |
|
||||
| StRS-005 | SyRS-011 | SwRS-011 | `ArticleBL.cs` – `CheckSerialnumberQuantityEqualsStockQuantity()` |
|
||||
| StRS-005 | SyRS-011 | SwRS-012 | `ArticleBL.cs` – `CopyArticle()` |
|
||||
| StRS-005 | SyRS-009 | SwRS-024 | `ArticleBL.cs` – `UpdateArticlePurchasePriceThroughStockBooking()` |
|
||||
| StRS-005 | SyRS-009 | SwRS-026 | `BarcodeBL.cs`, `BarcodeHistoryBL.cs` |
|
||||
| StRS-005 | SyRS-009 | SwRS-027 | `StorageBL.cs`, `SecondStockArticleBL.cs`, `BranchBL.cs` |
|
||||
| StRS-006 | SyRS-012 | SwRS-002 | `CentronRights.md`, `AppRightsBL.cs` |
|
||||
| StRS-006 | — | SwRS-029 | `ProcessBL.cs`, `SelfCareBL.cs`, `CentronRights.md` – C-Flow |
|
||||
| StRS-006 | — | SwRS-030 | `RmaBL.cs`, `RmaSendKindBL.cs`, `MailTemplateReferences.cs` |
|
||||
| StRS-007 | SyRS-008 | SwRS-009 | `DataSecurityBL.cs` – `DsgvoDeleteRightDeleteContacts()`, `DoDeleteContactPerson()` |
|
||||
| StRS-008 | SyRS-013 | SwRS-014 | `CentronNexus/`, `WebAccountBL.cs`, `AuthenticatorFactory.cs` |
|
||||
| StRS-009 | SyRS-014 | SwRS-015 | `EDIDispatcherBL.cs`, `Centron.Gateway/` |
|
||||
| StRS-010 | SyRS-015 | SwRS-016 | `ReportDataBL.cs`, `FastReportHelper.cs`, `ReportGroupBL.cs` |
|
||||
| StRS-011 | SyRS-016 | SwRS-017 | `ArticleBL.cs` – `GetProfitAndLossAccount()`, `BookKeepingReceiptKind.cs` |
|
||||
| StRS-012 | SyRS-017 | SwRS-018 | `MailTemplateReferences.cs`, `SalutationAndAgreementReplacementBL.cs` |
|
||||
| StRS-013 | SyRS-018 | — | `ProductionBL.cs`, `ProductionOrderBL.cs`, `ArticleWorkItemBL.cs` |
|
||||
| StRS-014 | SyRS-019 | — | `RiverDivoBL.cs`, `RiverConnectionBL.cs` |
|
||||
| StRS-015 | SyRS-007 | SwRS-019 | `LicenseManager.cs`, `Authenticator.cs` – `GetTicket()` |
|
||||
| StRS-015 | SyRS-025 | — | `azure/build-pipeline.yml`, `azure/docker-pipeline.yml` |
|
||||
| — | SyRS-020 | SwRS-022 | `IndexSearchBL.cs`, `GermanAnalyzer.cs`, `IndexBuilder.cs` |
|
||||
| — | SyRS-021 | SwRS-020 | `DAOFactory.cs`, `GenericDAO.cs`, `DAOSession.cs` |
|
||||
| — | SyRS-021 | SwRS-028 | `SSMS_DB_SCHEMA.sql`, `GenericStoredProcedureDAO.cs` |
|
||||
| — | SyRS-022 | SwRS-002 | `CachedTableBL.cs`, `AppRightsBL.cs` – Cache |
|
||||
| — | SyRS-023 | — | `MassUpdateBL.cs` |
|
||||
| — | — | SwRS-021 | `App.xaml.cs`, `FrontWindowViewModel.cs`, `ConnectionHeartbeatTimer.cs` |
|
||||
|
||||
## Traceability-Matrix (kompakt)
|
||||
|
||||
| StRS | → SyRS | → SwRS |
|
||||
|---|---|---|
|
||||
| StRS-001 | SyRS-001, 002, 004, 005 | SwRS-001, 003 |
|
||||
| StRS-002 | SyRS-003, 012, 024 | SwRS-002, 010, 025 |
|
||||
| StRS-003 | SyRS-006, 010 | SwRS-004 |
|
||||
| StRS-004 | SyRS-009, 010 | SwRS-004, 013 |
|
||||
| StRS-005 | SyRS-011 | SwRS-005, 006, 007, 008, 011, 012, 024, 026, 027 |
|
||||
| StRS-006 | SyRS-012 | SwRS-002, 029, 030 |
|
||||
| StRS-007 | SyRS-008 | SwRS-009 |
|
||||
| StRS-008 | SyRS-013 | SwRS-014 |
|
||||
| StRS-009 | SyRS-014 | SwRS-015 |
|
||||
| StRS-010 | SyRS-015 | SwRS-016 |
|
||||
| StRS-011 | SyRS-016 | SwRS-017 |
|
||||
| StRS-012 | SyRS-017 | SwRS-018 |
|
||||
| StRS-013 | SyRS-018 | — |
|
||||
| StRS-014 | SyRS-019 | — |
|
||||
| StRS-015 | SyRS-007, 025 | SwRS-019, 021 |
|
||||
| (System) | SyRS-020, 021, 022, 023 | SwRS-020, 022, 023, 028 |
|
||||
+1010
File diff suppressed because one or more lines are too long
+13
@@ -0,0 +1,13 @@
|
||||
[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
|
||||
[glm-kimi-adapter] Start: 2026-08-28T10:58:57.660773+00:00
|
||||
[glm-kimi-adapter] Provider: TensorX API Gateway
|
||||
[glm-kimi-adapter] Modell: z-ai/glm-5.2
|
||||
[glm-kimi-adapter] Effort: high
|
||||
[glm-kimi-adapter] Mode: solo
|
||||
[glm-kimi-adapter] Ende: 2026-08-28T11:05:08.519111+00:00
|
||||
[glm-kimi-adapter] Turns: 34
|
||||
[glm-kimi-adapter] Tokens gesamt: 1,862,184
|
||||
[glm-kimi-adapter] Tool-Calls: 130
|
||||
[glm-kimi-adapter] Subagenten: 0 (completed: 0, failed: 0)
|
||||
[glm-kimi-adapter] Ergebnisdateien: 7
|
||||
[glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\z-ai\glm-5.2\solo\high\03_Lauf_2026-08-28_125852_v8.0.0-c252\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1444
File diff suppressed because it is too large
Load Diff
+64
@@ -0,0 +1,64 @@
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
|
||||
|
||||
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
|
||||
|
||||
### Verteilung über die Ebenen
|
||||
|
||||
| Ebene | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| StRS | 15 | 21,4 % |
|
||||
| SyRS | 25 | 35,7 % |
|
||||
| SwRS | 30 | 42,9 % |
|
||||
| **Gesamt** | **70** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 32 | 45,7 % |
|
||||
| Sicherheit | 17 | 24,3 % |
|
||||
| Daten | 8 | 11,4 % |
|
||||
| Schnittstelle | 7 | 10,0 % |
|
||||
| nicht-funktional | 6 | 8,6 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 182 |
|
||||
| davon `PRIMÄR` | 155 (85,2 %) |
|
||||
| davon `SEKUNDÄR` | 26 (14,3 %) |
|
||||
| davon `KONTEXT` | 1 (0,5 %) |
|
||||
| Belege je Anforderung (Median) | 3,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 70 (100,0 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 65 | 92,9 % |
|
||||
| workaround | 3 | 4,3 % |
|
||||
| veraltet | 2 | 2,9 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 65 | 92,9 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 5 | 7,1 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 3 | 4,3 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 16 | 22,9 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (23 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **verletzt** – 55 ohne Prüfidee |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 70 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 70 von 70 mit Tracelinks (100,0 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+161
@@ -0,0 +1,161 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### 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). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
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). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **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. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **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. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **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.
|
||||
- **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 | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
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). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- 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.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
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 (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
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
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> 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.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\n\nNicht verfuegbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\z-ai\glm-5.2\solo\high\03_Lauf_2026-08-28_125852_v8.0.0-c252\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T13:05:08.5426379+02:00
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"modell": "z-ai/glm-5.2",
|
||||
"iteration": "Iteration 8",
|
||||
"promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
|
||||
"promptVersion": "03",
|
||||
"modus": "solo",
|
||||
"effort": "high",
|
||||
"skillVersion": "v8.0.0"
|
||||
}
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-28T12:58:52.2481112+02:00
|
||||
Reference in New Issue
Block a user