Compare commits
2
Commits
affde3a45f
...
ea1f3caff7
| Author | SHA1 | Date | |
|---|---|---|---|
 Christoph Schwörer
|
ea1f3caff7 | ||
|
Christoph SchwörerandClaude Opus 5
|
3d5b691bfa |
@@ -2,7 +2,7 @@
|
|||||||
name: run-experiment
|
name: run-experiment
|
||||||
description: Führt einen Versuchs-Prompt aus einer Prompt-Datei als messbaren Headless-Lauf mit Claude Code oder Codex CLI aus und schreibt ein Messprotokoll mit Start-/Endzeit, Modell, Tokenverbrauch und weiteren Metriken. Verwenden bei "/run-experiment <Pfad-zur-Prompt-Datei>" oder wenn der User einen Versuch/ein Experiment ausführen und tracken will.
|
description: Führt einen Versuchs-Prompt aus einer Prompt-Datei als messbaren Headless-Lauf mit Claude Code oder Codex CLI aus und schreibt ein Messprotokoll mit Start-/Endzeit, Modell, Tokenverbrauch und weiteren Metriken. Verwenden bei "/run-experiment <Pfad-zur-Prompt-Datei>" oder wenn der User einen Versuch/ein Experiment ausführen und tracken will.
|
||||||
argument-hint: <Pfad zur Prompt-Datei> <Root-Verzeichnis>
|
argument-hint: <Pfad zur Prompt-Datei> <Root-Verzeichnis>
|
||||||
version: 5.0.0
|
version: 7.0.0
|
||||||
---
|
---
|
||||||
|
|
||||||
# RunExperiment – Versuchslauf mit Messprotokoll
|
# RunExperiment – Versuchslauf mit Messprotokoll
|
||||||
@@ -16,8 +16,9 @@ schreibst du ein Messprotokoll neben die Prompt-Datei.
|
|||||||
|
|
||||||
- **Prompt** (Pflicht): Pfad zur Prompt-Datei (Markdown). Erstes Argument in `$ARGUMENTS`.
|
- **Prompt** (Pflicht): Pfad zur Prompt-Datei (Markdown). Erstes Argument in `$ARGUMENTS`.
|
||||||
- **Root** (Pflicht): Verzeichnis, das als Root des Versuchslaufs dient. Zweites Argument.
|
- **Root** (Pflicht): Verzeichnis, das als Root des Versuchslaufs dient. Zweites Argument.
|
||||||
Der Headless-Lauf wird mit diesem Verzeichnis als Arbeitsverzeichnis gestartet – es ist
|
Es ist die Wurzel der zu analysierenden Codebasis und wird nur GELESEN. Der Codex-Adapter
|
||||||
die Wurzel der zu analysierenden Codebasis und wird nur GELESEN. Fehlt das Argument: den
|
erstellt daraus ein isoliertes temporäres Arbeitsabbild; andere Adapter starten
|
||||||
|
unmittelbar mit diesem Root als Arbeitsverzeichnis. Fehlt das Argument: den
|
||||||
User danach fragen und NICHT stillschweigend das aktuelle Verzeichnis verwenden. Vor dem
|
User danach fragen und NICHT stillschweigend das aktuelle Verzeichnis verwenden. Vor dem
|
||||||
Lauf prüfen, dass das Verzeichnis existiert; sonst abbrechen und den User informieren.
|
Lauf prüfen, dass das Verzeichnis existiert; sonst abbrechen und den User informieren.
|
||||||
- **Modell** (Pflicht, **kein Default**): Wird **vor jedem Lauf beim User erfragt** – siehe
|
- **Modell** (Pflicht, **kein Default**): Wird **vor jedem Lauf beim User erfragt** – siehe
|
||||||
@@ -216,7 +217,7 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
|
|||||||
unangetastet und die Agentenkonfiguration ist eine dokumentierte, versionierte
|
unangetastet und die Agentenkonfiguration ist eine dokumentierte, versionierte
|
||||||
Versuchsbedingung. Format siehe `claude --help` zu `--agents`.
|
Versuchsbedingung. Format siehe `claude --help` zu `--agents`.
|
||||||
|
|
||||||
**Codex-Adapter in Version 5.0.0:** ausschließlich `solo` ist freigegeben und wird doppelt
|
**Codex-Adapter ab Version 5.0.0:** ausschließlich `solo` ist freigegeben und wird doppelt
|
||||||
mit `--disable multi_agent` sowie `-c agents.enabled=false` erzwungen. Bei `builtin` oder
|
mit `--disable multi_agent` sowie `-c agents.enabled=false` erzwungen. Bei `builtin` oder
|
||||||
`custom` abbrechen und mitteilen, dass dieser Adaptermodus noch nicht verifiziert ist. Eine
|
`custom` abbrechen und mitteilen, dass dieser Adaptermodus noch nicht verifiziert ist. Eine
|
||||||
stillschweigende Annäherung an Claude-Agentendefinitionen wäre keine reproduzierbare Bedingung.
|
stillschweigende Annäherung an Claude-Agentendefinitionen wäre keine reproduzierbare Bedingung.
|
||||||
@@ -255,7 +256,7 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
|
|||||||
Sort-Object { [int]($_.Name -replace '\D','') }
|
Sort-Object { [int]($_.Name -replace '\D','') }
|
||||||
$iteration = if ($iterationen) { $iterationen[-1].Name } else { 'Iteration 1' }
|
$iteration = if ($iterationen) { $iterationen[-1].Name } else { 'Iteration 1' }
|
||||||
$zelle = Join-Path (Join-Path (Join-Path $iteration $modell) $modus) $effort
|
$zelle = Join-Path (Join-Path (Join-Path $iteration $modell) $modus) $effort
|
||||||
$skillVer = 'v5.0.0' # entspricht version: im Frontmatter dieses Skills
|
$skillVer = 'v7.0.0' # entspricht version: im Frontmatter dieses Skills
|
||||||
do {
|
do {
|
||||||
$id4 = '{0:x4}' -f (Get-Random -Maximum 65536)
|
$id4 = '{0:x4}' -f (Get-Random -Maximum 65536)
|
||||||
$lauf = Join-Path "<promptverzeichnis>\$zelle" "<NN>_Lauf_$(Get-Date -Format 'yyyy-MM-dd_HHmmss')_${skillVer}-$id4"
|
$lauf = Join-Path "<promptverzeichnis>\$zelle" "<NN>_Lauf_$(Get-Date -Format 'yyyy-MM-dd_HHmmss')_${skillVer}-$id4"
|
||||||
@@ -347,15 +348,16 @@ Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
|||||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||||
```
|
```
|
||||||
|
|
||||||
**Codex-Abweichung bei Block 2.** Der Codex-Adapter läuft mit einem technisch erzwungenen
|
**Codex-Abweichung bei Block 2.** Der Codex-Adapter läuft in einer isolierten Arbeitskopie
|
||||||
`read-only`-Sandboxmodus. Er kann deshalb auch das externe Laufverzeichnis nicht direkt als
|
im System-Temp-Verzeichnis mit `workspace-write`. Das originale Root liegt außerhalb dieses
|
||||||
Agent beschreiben. Block 2 wird dort durch folgende strukturierte Rückgabeanweisung ersetzt;
|
Arbeitsbereichs und kann vom Agenten nicht erreicht werden. Trotz des technisch beschreibbaren
|
||||||
|
Abbilds darf der Agent keine Dateien verändern. Block 2 wird dort durch folgende strukturierte Rückgabeanweisung ersetzt;
|
||||||
die CLI erzwingt `codex-output-schema.json`, anschließend materialisiert
|
die CLI erzwingt `codex-output-schema.json`, anschließend materialisiert
|
||||||
`normalise-codex-result.py` die Dateien:
|
`normalise-codex-result.py` die Dateien:
|
||||||
|
|
||||||
```
|
```
|
||||||
### Ergebnisausgabe (überschreibt anderslautende Pfadangaben oben)
|
### Ergebnisausgabe (überschreibt anderslautende Pfadangaben oben)
|
||||||
Verändere keine Dateien. Gib alle geforderten Ergebnisdateien im vorgegebenen JSON-Schema zurück.
|
Verändere keine Dateien im Arbeitsverzeichnis. Gib alle geforderten Ergebnisdateien im vorgegebenen JSON-Schema zurück.
|
||||||
Jeder Eintrag in `files` enthält unter `path` einen relativen Pfad innerhalb von `Ergebnisse`
|
Jeder Eintrag in `files` enthält unter `path` einen relativen Pfad innerhalb von `Ergebnisse`
|
||||||
und unter `content` den vollständigen Dateiinhalt. `summary` enthält nur eine kurze Laufzusammenfassung.
|
und unter `content` den vollständigen Dateiinhalt. `summary` enthält nur eine kurze Laufzusammenfassung.
|
||||||
```
|
```
|
||||||
@@ -376,6 +378,9 @@ $lauf = "<absoluter Pfad zum Laufverzeichnis>"
|
|||||||
$prompt = (Get-Content "<prompt-datei>" -Raw) + "`n`n<Ausgabe-Anweisung>"
|
$prompt = (Get-Content "<prompt-datei>" -Raw) + "`n`n<Ausgabe-Anweisung>"
|
||||||
# Steuerdateien IMMER ins Laufverzeichnis - nie in den gemeinsamen Scratchpad (parallelfaehig)
|
# Steuerdateien IMMER ins Laufverzeichnis - nie in den gemeinsamen Scratchpad (parallelfaehig)
|
||||||
Set-Content -Path "$lauf\_meta\combined_prompt.md" -Value $prompt -Encoding utf8
|
Set-Content -Path "$lauf\_meta\combined_prompt.md" -Value $prompt -Encoding utf8
|
||||||
|
# Ohne diese Variable bricht der Headless-Modus nach 600 s ab, sobald noch
|
||||||
|
# Hintergrund-Subagenten laufen - und meldet dabei `is_error: false`.
|
||||||
|
$env:CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS = '0'
|
||||||
Set-Content -Path "$lauf\_meta\startzeit.txt" -Value (Get-Date -Format o)
|
Set-Content -Path "$lauf\_meta\startzeit.txt" -Value (Get-Date -Format o)
|
||||||
|
|
||||||
# Schreibende und bauende Shell-Kommandos sperren – die Codebasis wird nur gelesen.
|
# Schreibende und bauende Shell-Kommandos sperren – die Codebasis wird nur gelesen.
|
||||||
@@ -414,7 +419,7 @@ Bedeutung der Flags:
|
|||||||
|
|
||||||
| Flag | Zweck |
|
| Flag | Zweck |
|
||||||
|---|---|
|
|---|---|
|
||||||
| `--safe-mode` | Isolation: CLAUDE.md, Skills, Plugins, Hooks, MCP-Server, Custom-Agenten, Commands und Output-Styles aus – ohne Dateieingriff. Auth, Modellwahl, eingebaute Tools und Permissions bleiben normal aktiv. |
|
| `--safe-mode` | Isolation: CLAUDE.md, Skills, Plugins, Hooks, MCP-Server, Custom-Agenten, Commands und Output-Styles aus – ohne Dateieingriff. Auth, Modellwahl, eingebaute Tools und Permissions bleiben normal aktiv. **Nur in den Modi `solo` und `builtin` verwendbar** – siehe „Isolation je Agentenmodus". |
|
||||||
| `--strict-mcp-config` | zweite Absicherung gegen MCP-Server aus Projekt- oder User-Konfiguration |
|
| `--strict-mcp-config` | zweite Absicherung gegen MCP-Server aus Projekt- oder User-Konfiguration |
|
||||||
| `--permission-mode acceptEdits` | Schreibrechte für die Ergebnisdateien im Laufverzeichnis |
|
| `--permission-mode acceptEdits` | Schreibrechte für die Ergebnisdateien im Laufverzeichnis |
|
||||||
| `--allowedTools "Bash" "PowerShell"` | **Shell-Zugriff ohne Rückfrage** – Standard seit Prompt-Version 02 |
|
| `--allowedTools "Bash" "PowerShell"` | **Shell-Zugriff ohne Rückfrage** – Standard seit Prompt-Version 02 |
|
||||||
@@ -434,6 +439,55 @@ Die belastbare Read-only-Garantie bleibt der Vorher/Nachher-Vergleich per
|
|||||||
`git status --porcelain` aus Abschnitt 1 bzw. 3. Die Denylist senkt das Risiko, sie ersetzt die
|
`git status --porcelain` aus Abschnitt 1 bzw. 3. Die Denylist senkt das Risiko, sie ersetzt die
|
||||||
Verifikation nicht.
|
Verifikation nicht.
|
||||||
|
|
||||||
|
**Isolation je Agentenmodus – `--safe-mode` ist nicht immer verwendbar.**
|
||||||
|
|
||||||
|
`--safe-mode` schaltet ausweislich der CLI-Hilfe „all customizations (CLAUDE.md, skills, plugins,
|
||||||
|
hooks, **MCP servers, custom commands and agents**, output styles, workflows, …)" ab. Damit
|
||||||
|
deaktiviert es genau das, was die Modi `custom` (V2) und der MCP-Einsatz (V3) untersuchen sollen.
|
||||||
|
|
||||||
|
Verifiziert am 2026-08-26 gegen CLI 2.1.246 mit identischem Aufruf, nur `--safe-mode` variiert:
|
||||||
|
|
||||||
|
| Konfiguration | `subagent_stats.spawned` | `by_type` |
|
||||||
|
|---|---:|---|
|
||||||
|
| mit `--safe-mode` | **0** | leer – der Agent meldet, die Rollen seien „nicht in der Agent-Registry registriert" |
|
||||||
|
| ohne `--safe-mode` | **2** | `{"modulinventar": 1, "konsistenzpruefer": 1}` |
|
||||||
|
|
||||||
|
Daraus folgt eine modusabhängige Isolation:
|
||||||
|
|
||||||
|
| Modus | Isolation |
|
||||||
|
|---|---|
|
||||||
|
| `solo`, `builtin` | `--safe-mode` + `--strict-mcp-config` (unverändert) |
|
||||||
|
| `custom`, sowie jeder Lauf mit `--mcp-config` | **kein** `--safe-mode`; stattdessen `--strict-mcp-config` und die Sperre `--disallowedTools Skill WebSearch WebFetch SlashCommand` |
|
||||||
|
|
||||||
|
Der gezielte Ersatz wurde am selben Tag gegengeprüft. Der Agent antwortete auf eine
|
||||||
|
Werkzeugabfrage: `VORGELADEN: NICHTS VORGELADEN` · `SKILLS: KEINE` · `WEB: KEIN WEBZUGRIFF` ·
|
||||||
|
alle acht Custom-Rollen verfügbar. Ohne die Sperre lädt die CLI **16 global installierte Skills**
|
||||||
|
(darunter `code-review`, `security-review`, `run`, `init`); `--setting-sources ''` unterdrückt sie
|
||||||
|
**nicht**.
|
||||||
|
|
||||||
|
**Was der Ersatz nicht abdeckt.** `--safe-mode` deaktiviert zusätzlich Plugins, Hooks und
|
||||||
|
Output-Styles. Die Sperre tut das nicht. Auf der Maschine, auf der die Versuchsreihe läuft, sind
|
||||||
|
davon keine konfiguriert (`~/.claude/settings.json` enthält nur `model` und
|
||||||
|
`agentPushNotifEnabled`, kein `hooks`; kein `plugins`- und kein `output-styles`-Verzeichnis) –
|
||||||
|
das ist jedoch eine Eigenschaft der Umgebung, keine Garantie. **Vor jedem Lauf im Modus `custom`
|
||||||
|
oder mit MCP ist deshalb zu prüfen:**
|
||||||
|
|
||||||
|
```powershell
|
||||||
|
$us = Join-Path $env:USERPROFILE '.claude\settings.json'
|
||||||
|
if (Test-Path $us) { (Get-Content $us -Raw | ConvertFrom-Json).PSObject.Properties.Name }
|
||||||
|
foreach ($d in 'plugins','output-styles','skills') {
|
||||||
|
$pfad = Join-Path $env:USERPROFILE ".claude\$d"
|
||||||
|
if (Test-Path $pfad) { "VORHANDEN: $d -> " + ((Get-ChildItem $pfad | Measure-Object).Count) + ' Eintraege' }
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Treten Hooks, Plugins oder Output-Styles auf, ist der Lauf **nicht** isoliert und die Bedingung
|
||||||
|
im Protokoll als abweichend zu kennzeichnen.
|
||||||
|
|
||||||
|
**Unverändert bleibt:** `--safe-mode` hat die Modellwahl nie beeinflusst. Der Eintrag `model` in
|
||||||
|
den User-Settings (hier `opus[1m]`) kann Subagenten binden – das ist der bekannte Grund der zwei
|
||||||
|
dokumentierten Modellabweichungen und gilt mit wie ohne `--safe-mode`.
|
||||||
|
|
||||||
**`--safe-mode` bleibt als zweite Sicherung aktiv.** Die primäre Isolation leistet der
|
**`--safe-mode` bleibt als zweite Sicherung aktiv.** Die primäre Isolation leistet der
|
||||||
bereinigte Snapshot (Abschnitt 1); `--safe-mode` fängt zusätzlich alles ab, was von außerhalb
|
bereinigte Snapshot (Abschnitt 1); `--safe-mode` fängt zusätzlich alles ab, was von außerhalb
|
||||||
des Roots wirken könnte – User-Level-Settings, global installierte Skills, Plugins, Hooks.
|
des Roots wirken könnte – User-Level-Settings, global installierte Skills, Plugins, Hooks.
|
||||||
@@ -542,6 +596,32 @@ Subagenten gibt.
|
|||||||
Bei Modus `builtin` oder `custom` daher **nie** den Flag-Wert allein ins Protokoll schreiben,
|
Bei Modus `builtin` oder `custom` daher **nie** den Flag-Wert allein ins Protokoll schreiben,
|
||||||
sondern die Modelle aus `modelUsage` mit ihrem jeweiligen Anteil ausweisen.
|
sondern die Modelle aus `modelUsage` mit ihrem jeweiligen Anteil ausweisen.
|
||||||
|
|
||||||
|
**Pflichtprüfung: Hat der Lauf überhaupt etwas erzeugt?** `is_error` allein genügt **nicht**.
|
||||||
|
Ein Lauf kann `is_error: false`, `subtype: success` und `terminal_reason: completed` melden und
|
||||||
|
trotzdem **null Ergebnisdateien** hinterlassen. Belegt am 2026-08-26, Lauf
|
||||||
|
`Iteration 3/claude-opus-5/builtin/high/…160037_v4.5.0-116d`: Der Hauptagent startete zehn
|
||||||
|
Subagenten im Hintergrund, beendete seinen Turn und schrieb als Abschlusstext „Die Erhebung
|
||||||
|
läuft"; der Headless-Modus wartete 600 s und brach dann ab. `Stderr.log` enthielt
|
||||||
|
„Background tasks still running after 600s; terminating." Verbraucht waren zu diesem Zeitpunkt
|
||||||
|
**193,4 Mio. Tokens** – der teuerste Lauf der Reihe, ohne ein einziges Artefakt.
|
||||||
|
|
||||||
|
Nach jedem Lauf daher zwingend prüfen:
|
||||||
|
|
||||||
|
1. `Ergebnisse\` ist **nicht leer** und enthält die vom Prompt geforderten Dateien. Fehlen sie,
|
||||||
|
ist der Lauf **unabhängig von `is_error` als Fehlmessung zu kennzeichnen**.
|
||||||
|
2. `Stderr.log` enthält keine Abbruchmeldung. Die Datei ist im Normalfall 0 Byte groß.
|
||||||
|
|
||||||
|
Vorbeugend setzt der Ausführungsabschnitt `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`, damit der
|
||||||
|
Lauf auf seine Hintergrund-Subagenten wartet, statt sie abzuschneiden.
|
||||||
|
|
||||||
|
**Subagenten-Ergebnisse kommen nicht als Werkzeugergebnis zurück.** Startet der Hauptagent einen
|
||||||
|
Subagenten im Hintergrund, liefert der Werkzeugaufruf sofort eine **Start-Quittung** von rund
|
||||||
|
1.093 Zeichen („Async agent launched successfully …") zurück, nicht die Befunde. Deren Länge ist
|
||||||
|
folglich **kein** Maß für den Ertrag des Subagenten. Die Quittung nennt einen Pfad
|
||||||
|
`<temp>\<session>\tasks\<agentId>.output`; diese Dateien werden zwar angelegt, bleiben aber
|
||||||
|
**leer** (geprüft an 33 Dateien aus zwei Läufen). Die Aussage, dass Subagenten-Transkripte nicht
|
||||||
|
auswertbar persistiert werden, gilt damit unverändert.
|
||||||
|
|
||||||
`permission_denials` ist eine **reguläre Messgröße** und immer auszuweisen, auch bei 0. Ein
|
`permission_denials` ist eine **reguläre Messgröße** und immer auszuweisen, auch bei 0. Ein
|
||||||
hoher Wert bedeutet, dass die Werkzeugkonfiguration den Lauf eingeschränkt hat, und ist bei der
|
hoher Wert bedeutet, dass die Werkzeugkonfiguration den Lauf eingeschränkt hat, und ist bei der
|
||||||
Interpretation der Ergebnisqualität zu berücksichtigen.
|
Interpretation der Ergebnisqualität zu berücksichtigen.
|
||||||
@@ -683,7 +763,11 @@ Vorlage:
|
|||||||
- **Permission-/Sandbox-Modus:** <acceptEdits | read-only / approval never | ...>
|
- **Permission-/Sandbox-Modus:** <acceptEdits | read-only / approval never | ...>
|
||||||
- **Toolfreigabe:** <adapterabhängige Flags wörtlich>
|
- **Toolfreigabe:** <adapterabhängige Flags wörtlich>
|
||||||
- **Isolationsmechanismus:** <adapterabhängige Flags wörtlich>
|
- **Isolationsmechanismus:** <adapterabhängige Flags wörtlich>
|
||||||
- **MCP-Server / Agentendateien:** <keine – aus dem Snapshot entfernt, zusätzlich --safe-mode | Liste>
|
- **MCP-Server / Agentendateien:** <keine – aus dem Snapshot entfernt, zusätzlich --safe-mode |
|
||||||
|
Liste der Server mit Pfad und SHA-256 der `--mcp-config`-Datei; Pfad und SHA-256 der
|
||||||
|
`--agents`-Datei>
|
||||||
|
- **Umgebungsprüfung (nur `custom` / MCP):** <keine Hooks, Plugins, Output-Styles im
|
||||||
|
User-Profil vorgefunden | **abweichend**: welche>
|
||||||
- **Subagenten:** <Anzahl und Typ aus `subagent_stats`, z. B. 8 × Explore, 0 fehlgeschlagen>
|
- **Subagenten:** <Anzahl und Typ aus `subagent_stats`, z. B. 8 × Explore, 0 fehlgeschlagen>
|
||||||
- **Verschachtelung:** `spawned` = <N>, davon `spawned_by_subagents` = <M>, `max_depth` = <D>.
|
- **Verschachtelung:** `spawned` = <N>, davon `spawned_by_subagents` = <M>, `max_depth` = <D>.
|
||||||
Bei `max_depth` > 1 ausdrücklich vermerken – die Tokens der tieferen Ebenen sind in
|
Bei `max_depth` > 1 ausdrücklich vermerken – die Tokens der tieferen Ebenen sind in
|
||||||
@@ -742,6 +826,8 @@ Status, Regelkonformität>
|
|||||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = <Zahl> (bei `solo` muss 0 stehen,
|
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = <Zahl> (bei `solo` muss 0 stehen,
|
||||||
sonst Fehlmessung)
|
sonst Fehlmessung)
|
||||||
- **Subagenten-Prompts:** <`_meta\subagenten.md`, N Aufrufe erfasst | entfällt (Modus solo)>
|
- **Subagenten-Prompts:** <`_meta\subagenten.md`, N Aufrufe erfasst | entfällt (Modus solo)>
|
||||||
|
- **Gültigkeit:** <gültig | **Fehlmessung**: Ergebnisverzeichnis leer / Abbruchmeldung in
|
||||||
|
Stderr.log – Wortlaut zitieren>
|
||||||
- **Erzeugte Dateien:** <Liste aus Ergebnisse\>
|
- **Erzeugte Dateien:** <Liste aus Ergebnisse\>
|
||||||
- **Root unverändert:** <ja | nein: welche Abweichungen>
|
- **Root unverändert:** <ja | nein: welche Abweichungen>
|
||||||
- **Abschlusstext des Agenten:** siehe RawResult.json (`result`)
|
- **Abschlusstext des Agenten:** siehe RawResult.json (`result`)
|
||||||
@@ -789,28 +875,47 @@ OpenAI-Modell-IDs entworfen. Referenzstand bei Einführung: **Codex CLI 0.149.0-
|
|||||||
Vor jedem Lauf `codex --version` protokollieren; bei geändertem JSONL-Schema den Normalisierer
|
Vor jedem Lauf `codex --version` protokollieren; bei geändertem JSONL-Schema den Normalisierer
|
||||||
zuerst mit einem kleinen, ausdrücklich freigegebenen Smoke-Test prüfen.
|
zuerst mit einem kleinen, ausdrücklich freigegebenen Smoke-Test prüfen.
|
||||||
|
|
||||||
**Unterstützter Agentenmodus:** In Version 5.0.0 nur `solo`. `builtin` und `custom` müssen
|
**Unterstützter Agentenmodus:** Auch in Version 6.0.0 nur `solo`. `builtin` und `custom` müssen
|
||||||
abbrechen. `solo` wird mit zwei unabhängigen Einstellungen erzwungen:
|
abbrechen. `solo` wird mit zwei unabhängigen Einstellungen erzwungen:
|
||||||
`--disable multi_agent` und `-c agents.enabled=false`.
|
`--disable multi_agent` und `-c agents.enabled=false`.
|
||||||
|
|
||||||
**Isolation und Ausgabe.** Codex arbeitet im Root mit `--sandbox read-only`. Anders als beim
|
**Isolation und Ausgabe.** Unter Windows blockierte `--sandbox read-only` mit Codex CLI
|
||||||
Claude-Adapter erhält der Agent deshalb kein beschreibbares Zusatzverzeichnis. Er liefert ein
|
0.149.0-alpha.4.3 bereits den Start rein lesender Prozesse (`pwsh`, `cmd`, `rg`). Der Adapter
|
||||||
Schemaobjekt mit vollständigen Dateiinhalten; `--output-last-message` schreibt dieses durch die
|
erstellt deshalb vor dem Lauf eine isolierte Kopie der versionierten und nicht ignorierten
|
||||||
CLI nach `_meta\final_response.json`. Erst nach Ende des Agenten materialisiert das lokale,
|
Quelldateien im System-Temp-Verzeichnis und startet Codex dort mit `--sandbox workspace-write`.
|
||||||
deterministische Skript die validierten relativen Pfade unter `Ergebnisse\`. Absolute Pfade,
|
Das originale Root liegt außerhalb des Codex-Arbeitsbereichs und bleibt technisch getrennt.
|
||||||
`..`, Laufwerkspräfixe und case-insensitive Duplikate werden abgelehnt.
|
`prepare-codex-workspace.py` hasht die Kopie vor und nach dem Lauf; jede Änderung macht den Lauf
|
||||||
|
ungültig. Quelle, Dateizahl, Größe und beide Manifeste werden unter `_meta` archiviert; die
|
||||||
|
temporäre Kopie wird erst nach der Integritätsprüfung entfernt. Die Ablage außerhalb des
|
||||||
|
IDE-Projektbaums verhindert automatische Design-Time-Restores, die sonst ungefragt `obj`-Dateien
|
||||||
|
in der Kopie erzeugen.
|
||||||
|
|
||||||
|
Der Agent liefert weiterhin ausschließlich ein Schemaobjekt mit vollständigen Dateiinhalten;
|
||||||
|
`--output-last-message` schreibt dieses durch die CLI nach `_meta\final_response.json`. Erst nach
|
||||||
|
Ende des Agenten materialisiert das lokale, deterministische Skript die validierten relativen
|
||||||
|
Pfade unter `Ergebnisse\`. Absolute Pfade, `..`, Laufwerkspräfixe und case-insensitive Duplikate
|
||||||
|
werden abgelehnt.
|
||||||
|
|
||||||
Vor dem Start `$codex`, `$skillDir`, `$lauf`, `$root`, `$modell` und `$effort` auf absolute
|
Vor dem Start `$codex`, `$skillDir`, `$lauf`, `$root`, `$modell` und `$effort` auf absolute
|
||||||
Pfade beziehungsweise die bestätigten Versuchsbedingungen setzen. Den Prompt mit dem
|
Pfade beziehungsweise die bestätigten Versuchsbedingungen setzen. Den Prompt mit dem
|
||||||
Codex-Ausgabeblock aus Abschnitt 2 nach `_meta\combined_prompt.md` schreiben. Der eigentliche
|
Codex-Ausgabeblock aus Abschnitt 2 nach `_meta\combined_prompt.md` schreiben. Anschließend das
|
||||||
Aufruf lautet:
|
isolierte Abbild anlegen; bei einem Fehler darf der API-Lauf nicht starten:
|
||||||
|
|
||||||
|
```powershell
|
||||||
|
$meta = Join-Path $lauf '_meta'
|
||||||
|
$workspace = Join-Path ([IO.Path]::GetTempPath()) "codex-experiment-<Laufverzeichnis-ID>"
|
||||||
|
python (Join-Path $skillDir 'prepare-codex-workspace.py') create $root $workspace $meta
|
||||||
|
if ($LASTEXITCODE -ne 0) { throw 'Codex-Arbeitsabbild konnte nicht erstellt werden.' }
|
||||||
|
```
|
||||||
|
|
||||||
|
Der eigentliche Aufruf lautet:
|
||||||
|
|
||||||
```powershell
|
```powershell
|
||||||
$codexArgs = @(
|
$codexArgs = @(
|
||||||
'--model', $modell,
|
'--model', $modell,
|
||||||
'-c', "model_reasoning_effort=`"$effort`"",
|
'-c', "model_reasoning_effort=`"$effort`"",
|
||||||
'-c', 'service_tier="default"',
|
'-c', 'service_tier="default"',
|
||||||
'--sandbox', 'read-only',
|
'--sandbox', 'workspace-write',
|
||||||
'--ask-for-approval', 'never',
|
'--ask-for-approval', 'never',
|
||||||
'--disable', 'multi_agent',
|
'--disable', 'multi_agent',
|
||||||
'-c', 'agents.enabled=false',
|
'-c', 'agents.enabled=false',
|
||||||
@@ -818,7 +923,7 @@ $codexArgs = @(
|
|||||||
'--disable', 'apps',
|
'--disable', 'apps',
|
||||||
'--disable', 'hooks',
|
'--disable', 'hooks',
|
||||||
'--disable', 'skill_search',
|
'--disable', 'skill_search',
|
||||||
'--cd', $root,
|
'--cd', $workspace,
|
||||||
'exec',
|
'exec',
|
||||||
'--ignore-user-config',
|
'--ignore-user-config',
|
||||||
'--ignore-rules',
|
'--ignore-rules',
|
||||||
@@ -837,14 +942,20 @@ $codexExit = $LASTEXITCODE
|
|||||||
Set-Content -Path "$lauf\_meta\exitcode.txt" -Value $codexExit
|
Set-Content -Path "$lauf\_meta\exitcode.txt" -Value $codexExit
|
||||||
Set-Content -Path "$lauf\_meta\endzeit.txt" -Value (Get-Date -Format o)
|
Set-Content -Path "$lauf\_meta\endzeit.txt" -Value (Get-Date -Format o)
|
||||||
|
|
||||||
|
python (Join-Path $skillDir 'prepare-codex-workspace.py') verify $workspace $meta
|
||||||
|
$workspaceExit = $LASTEXITCODE
|
||||||
|
|
||||||
python (Join-Path $skillDir 'normalise-codex-result.py') $lauf `
|
python (Join-Path $skillDir 'normalise-codex-result.py') $lauf `
|
||||||
--model $modell --effort $effort
|
--model $modell --effort $effort
|
||||||
|
|
||||||
|
python (Join-Path $skillDir 'prepare-codex-workspace.py') cleanup $workspace $meta
|
||||||
```
|
```
|
||||||
|
|
||||||
Auch dieser Aufruf ist als Background-Task zu starten. Das Erscheinen von `RawEvents.jsonl`
|
Auch dieser Aufruf ist als Background-Task zu starten. Das Erscheinen von `RawEvents.jsonl`
|
||||||
allein bedeutet noch nicht, dass der Lauf fertig ist; Ende ist der abgeschlossene Prozess plus
|
allein bedeutet noch nicht, dass der Lauf fertig ist; Ende ist der abgeschlossene Prozess plus
|
||||||
erzeugte `RawResult.json`. Schlägt die Normalisierung fehl, Rohdateien unverändert lassen und
|
Integritätsprüfung und erzeugte `RawResult.json`. Ist `$workspaceExit` ungleich null, den Lauf
|
||||||
den Lauf als Fehler protokollieren.
|
wegen einer veränderten Arbeitskopie als ungültig kennzeichnen. Schlägt die Normalisierung fehl,
|
||||||
|
Rohdateien unverändert lassen und den Lauf als Fehler protokollieren.
|
||||||
|
|
||||||
**Warum diese Flags:**
|
**Warum diese Flags:**
|
||||||
|
|
||||||
@@ -853,13 +964,13 @@ den Lauf als Fehler protokollieren.
|
|||||||
| `--model <id>` | vollständige, vom User bestätigte OpenAI-Modell-ID |
|
| `--model <id>` | vollständige, vom User bestätigte OpenAI-Modell-ID |
|
||||||
| `model_reasoning_effort` | expliziter Denkaufwand |
|
| `model_reasoning_effort` | expliziter Denkaufwand |
|
||||||
| `service_tier="default"` | verhindert eine geerbte Fast-/Priority-Bedingung |
|
| `service_tier="default"` | verhindert eine geerbte Fast-/Priority-Bedingung |
|
||||||
| `--sandbox read-only` | technische Schreibsperre für den Codebasis-Snapshot |
|
| `--sandbox workspace-write` | erlaubt Windows-Prozessstarts nur innerhalb der isolierten Arbeitskopie |
|
||||||
| `--ask-for-approval never` | keine interaktiven Unterbrechungen im Headless-Lauf |
|
| `--ask-for-approval never` | keine interaktiven Unterbrechungen im Headless-Lauf |
|
||||||
| `--ignore-user-config`, `--ignore-rules` | keine User-Konfiguration und keine Exec-Regeln |
|
| `--ignore-user-config`, `--ignore-rules` | keine User-Konfiguration und keine Exec-Regeln |
|
||||||
| `--disable plugins/apps/hooks/skill_search` | keine externen oder benutzerspezifischen Erweiterungen |
|
| `--disable plugins/apps/hooks/skill_search` | keine externen oder benutzerspezifischen Erweiterungen |
|
||||||
| `--disable multi_agent`, `agents.enabled=false` | keine Subagenten im Modus `solo` |
|
| `--disable multi_agent`, `agents.enabled=false` | keine Subagenten im Modus `solo` |
|
||||||
| `--json` | vollständiger maschinenlesbarer Ereignisstrom |
|
| `--json` | vollständiger maschinenlesbarer Ereignisstrom |
|
||||||
| `--output-schema`, `--output-last-message` | validierbare Ergebnisdateien ohne Schreibrecht des Agenten |
|
| `--output-schema`, `--output-last-message` | validierbare Ergebnisdateien außerhalb des Arbeitsabbilds |
|
||||||
|
|
||||||
`--ignore-user-config` lässt die gespeicherte Authentifizierung weiterhin nutzbar; niemals
|
`--ignore-user-config` lässt die gespeicherte Authentifizierung weiterhin nutzbar; niemals
|
||||||
`auth.json` kopieren oder in Laufartefakten ablegen. Live-Websuche ist nicht freigegeben, weil
|
`auth.json` kopieren oder in Laufartefakten ablegen. Live-Websuche ist nicht freigegeben, weil
|
||||||
@@ -946,6 +1057,9 @@ der Historie unten – im selben Arbeitsschritt.
|
|||||||
|
|
||||||
| Version | Änderung | Grund | Verwendet in |
|
| Version | Änderung | Grund | Verwendet in |
|
||||||
|---|---|---|---|
|
|---|---|---|---|
|
||||||
|
| **7.0.0** | **Isolationsmechanismus wird modusabhängig.** In den Modi `solo` und `builtin` unverändert `--safe-mode`; im Modus `custom` und bei jedem Lauf mit `--mcp-config` **kein** `--safe-mode`, stattdessen `--strict-mcp-config` plus `--disallowedTools Skill WebSearch WebFetch SlashCommand`. Neue Pflicht-Umgebungsprüfung auf Hooks, Plugins und Output-Styles im User-Profil; neue Protokollfelder für die MCP-Konfiguration und die Umgebungsprüfung. | `--safe-mode` schaltet ausweislich der CLI-Hilfe „MCP servers, custom commands and agents" ab – also genau das, was V2 und V3 untersuchen. Smoke-Test am 2026-08-26 (CLI 2.1.246, identischer Aufruf, nur `--safe-mode` variiert): mit Flag `spawned` = 0 und die Meldung, die Rollen seien „nicht in der Agent-Registry registriert"; ohne Flag `spawned` = 2 mit `{"modulinventar": 1, "konsistenzpruefer": 1}`. Ohne Ersatz hätte der erste V2-Lauf stillschweigend als V1-Lauf gemessen. Der Ersatz wurde gegengeprüft: nichts vorgeladen, keine Skills, kein Webzugriff, alle Rollen verfügbar. **MAJOR: Läufe im Modus `custom` sind hinsichtlich der Isolation nicht unmittelbar mit `solo`- und `builtin`-Läufen vergleichbar** – Plugins, Hooks und Output-Styles sind dort nicht durch das Flag, sondern nur durch die Umgebungsprüfung ausgeschlossen. | ab dem ersten V2-Lauf |
|
||||||
|
| **6.1.0** | Zwei adapterunabhängige Pflichtprüfungen nach jedem Lauf: **(a)** `Ergebnisse\` darf nicht leer sein – sonst Fehlmessung, unabhängig von `is_error`; **(b)** `Stderr.log` auf Abbruchmeldungen prüfen. Der Ausführungsabschnitt setzt `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`. Neues Protokollfeld „Gültigkeit". Dokumentiert, dass die Rückgabe eines Hintergrund-Subagenten eine Start-Quittung ist und ihre Länge kein Ertragsmaß. | Lauf `…160037_v4.5.0-116d` meldete `is_error: false`, `subtype: success` und lieferte **null Ergebnisdateien** bei 193,4 Mio. Tokens – der Headless-Modus hatte nach 600 s abgebrochen, während zehn Hintergrund-Subagenten noch liefen. Ohne die neue Prüfung wäre der Lauf als gültiger Messpunkt mit „0 Anforderungen" in den Modellvergleich eingegangen. MINOR: neue Prüfschritte; die Umgebungsvariable ändert die Versuchsbedingung für künftige `builtin`-Läufe und ist dort zu vermerken. | ab sofort |
|
||||||
|
| **6.0.0** | **Windows-taugliche Codex-Isolation.** Pro Lauf wird im System-Temp-Verzeichnis außerhalb des IDE-Projektbaums eine Kopie der versionierten und nicht ignorierten Dateien des Codebasis-Roots erstellt. Codex läuft ausschließlich dort mit `--sandbox workspace-write`; SHA-256-Manifeste vor und nach dem Lauf erkennen jede Änderung. Ergebnisse und Nachweise bleiben im Laufverzeichnis, die temporäre Kopie wird danach entfernt. | Der erste Codex-Lauf mit 5.0.0 konnte fachlich nicht starten, weil die Windows-Read-only-Sandbox sämtliche lesenden Kindprozesse vor dem Start blockierte. Eine Kopie im Laufverzeichnis wurde zudem vom C#-Projektservice automatisch mit ignorierten `obj`-Dateien verändert. MAJOR, weil Sandboxmodus und Arbeitsverzeichnis eine neue Versuchsbedingung bilden; der erste Lauf eröffnet deshalb eine neue Iteration. | ab dem ersten wiederholten Codex-Lauf |
|
||||||
| **5.0.0** | **Neuer Codex-CLI-Adapter für OpenAI-Modelle.** Exakte OpenAI-Modell-IDs, expliziter Reasoning-Effort und Service-Tier; technisch read-only ausgeführtes `codex exec`; schemaerzwungene Dateirückgabe; JSONL-Rohdaten und deterministische Normalisierung nach `RawResult.json`. Codex ist zunächst nur im Modus `solo` freigegeben. Zusätzlich fünf beschädigte Backslashes vor `analyse-anforderungen.py`, `anforderungen.*` und `after.txt` repariert. | Der bisherige Skill konnte nur Claude Code ausführen. Ein Codex-Lauf braucht andere Isolations-, Ausgabe- und Messmechanismen. MAJOR, weil Werkzeug, Rohdatenformat und Ergebnisübergabe neue Versuchsbedingungen bilden; der nächste Lauf eröffnet deshalb eine neue Iteration. | ab dem ersten Codex-Lauf |
|
| **5.0.0** | **Neuer Codex-CLI-Adapter für OpenAI-Modelle.** Exakte OpenAI-Modell-IDs, expliziter Reasoning-Effort und Service-Tier; technisch read-only ausgeführtes `codex exec`; schemaerzwungene Dateirückgabe; JSONL-Rohdaten und deterministische Normalisierung nach `RawResult.json`. Codex ist zunächst nur im Modus `solo` freigegeben. Zusätzlich fünf beschädigte Backslashes vor `analyse-anforderungen.py`, `anforderungen.*` und `after.txt` repariert. | Der bisherige Skill konnte nur Claude Code ausführen. Ein Codex-Lauf braucht andere Isolations-, Ausgabe- und Messmechanismen. MAJOR, weil Werkzeug, Rohdatenformat und Ergebnisübergabe neue Versuchsbedingungen bilden; der nächste Lauf eröffnet deshalb eine neue Iteration. | ab dem ersten Codex-Lauf |
|
||||||
| **1.0.0** | Ausgangsfassung: `--permission-mode acceptEdits`, kein Shell-Zugriff; Isolation durch Löschen der KI-Konfigurationsdateien im Root vor dem Lauf und `git restore` danach | Erstaufsetzung des Versuchsaufbaus | Lauf 1 (`01_Lauf_2026-08-25_1228`) |
|
| **1.0.0** | Ausgangsfassung: `--permission-mode acceptEdits`, kein Shell-Zugriff; Isolation durch Löschen der KI-Konfigurationsdateien im Root vor dem Lauf und `git restore` danach | Erstaufsetzung des Versuchsaufbaus | Lauf 1 (`01_Lauf_2026-08-25_1228`) |
|
||||||
| **2.0.0** | `--allowedTools "Bash" "PowerShell"` + 33er-Denylist für schreibende und bauende Kommandos. Isolation über **eingefrorenen Codebasis-Snapshot ohne KI-Konfigurationen** (Commit `79c1142`, Parent `89ccfd6`, GitHub-Remote entkoppelt), zusätzlich `--safe-mode` und `--strict-mcp-config`. Der destruktive Lösch-/Restore-Schritt pro Lauf entfällt. `permission_denials` und `subagent_stats` werden reguläre Messgrößen; Verbrauchstabelle trennt Hauptagent und Gesamtlauf. CLI-Pfad-Auflösung als eigener Schritt. | Lauf 1 erzeugte 36 Permission-Denials (32 × Bash, 4 × PowerShell); Shell-gestützte Verzeichnisinventuren fehlten dem Agenten. `--safe-mode` allein genügt nicht: Es unterdrückt das Vorladen von `CLAUDE.md`/`AGENTS.md`, verhindert aber nicht, dass der Agent sie mit Shell-Zugriff selbst liest – im Smoke-Test nachgewiesen. | Lauf 2 (`01_Lauf_2026-08-25_1349`, API-Abbruch) |
|
| **2.0.0** | `--allowedTools "Bash" "PowerShell"` + 33er-Denylist für schreibende und bauende Kommandos. Isolation über **eingefrorenen Codebasis-Snapshot ohne KI-Konfigurationen** (Commit `79c1142`, Parent `89ccfd6`, GitHub-Remote entkoppelt), zusätzlich `--safe-mode` und `--strict-mcp-config`. Der destruktive Lösch-/Restore-Schritt pro Lauf entfällt. `permission_denials` und `subagent_stats` werden reguläre Messgrößen; Verbrauchstabelle trennt Hauptagent und Gesamtlauf. CLI-Pfad-Auflösung als eigener Schritt. | Lauf 1 erzeugte 36 Permission-Denials (32 × Bash, 4 × PowerShell); Shell-gestützte Verzeichnisinventuren fehlten dem Agenten. `--safe-mode` allein genügt nicht: Es unterdrückt das Vorladen von `CLAUDE.md`/`AGENTS.md`, verhindert aber nicht, dass der Agent sie mit Shell-Zugriff selbst liest – im Smoke-Test nachgewiesen. | Lauf 2 (`01_Lauf_2026-08-25_1349`, API-Abbruch) |
|
||||||
|
|||||||
@@ -64,6 +64,10 @@ for a in aufrufe:
|
|||||||
txt = ergebnisse.get(a['id']) or ''
|
txt = ergebnisse.get(a['id']) or ''
|
||||||
a['ergebnis_zeichen'] = len(txt)
|
a['ergebnis_zeichen'] = len(txt)
|
||||||
a['abgewiesen'] = ABSAGE in txt
|
a['abgewiesen'] = ABSAGE in txt
|
||||||
|
# Ein im Hintergrund gestarteter Subagent liefert sofort eine Start-Quittung
|
||||||
|
# ('Async agent launched successfully'), nicht seine Befunde. Ihre Laenge ist
|
||||||
|
# KEIN Ertragsmass - sie ist fuer alle Hintergrund-Subagenten praktisch gleich.
|
||||||
|
a['nur_startquittung'] = 'Async agent launched successfully' in txt
|
||||||
|
|
||||||
abgewiesen = [a for a in aufrufe if a['abgewiesen']]
|
abgewiesen = [a for a in aufrufe if a['abgewiesen']]
|
||||||
echte = [a for a in aufrufe if not a['abgewiesen']]
|
echte = [a for a in aufrufe if not a['abgewiesen']]
|
||||||
@@ -102,8 +106,11 @@ for i, a in enumerate(echte, 1):
|
|||||||
'',
|
'',
|
||||||
'- **Werkzeug:** `%s` **Typ:** `%s` **Hintergrund:** %s'
|
'- **Werkzeug:** `%s` **Typ:** `%s` **Hintergrund:** %s'
|
||||||
% (a['werkzeug'], a['subagent_type'], a['run_in_background']),
|
% (a['werkzeug'], a['subagent_type'], a['run_in_background']),
|
||||||
'- **Prompt-Zeichen:** %d **Ergebnis-Zeichen:** %s'
|
'- **Prompt-Zeichen:** %d **Rueckgabe:** %s'
|
||||||
% (len(a['prompt']), a['ergebnis_zeichen']),
|
% (len(a['prompt']),
|
||||||
|
'Start-Quittung (Befunde kommen per Benachrichtigung, nicht als '
|
||||||
|
'Werkzeugergebnis - Laenge ist kein Ertragsmass)'
|
||||||
|
if a.get('nur_startquittung') else '%s Zeichen' % a['ergebnis_zeichen']),
|
||||||
'', '### Prompt', '', '```', a['prompt'].rstrip(), '```', '']
|
'', '### Prompt', '', '```', a['prompt'].rstrip(), '```', '']
|
||||||
io.open(os.path.join(meta, 'subagenten.md'), 'w', encoding='utf-8').write('\n'.join(md))
|
io.open(os.path.join(meta, 'subagenten.md'), 'w', encoding='utf-8').write('\n'.join(md))
|
||||||
|
|
||||||
@@ -111,6 +118,8 @@ print('Subagenten gefunden: %d echte%s (direkt erwartet: %s, gesamt: %s, davon v
|
|||||||
% (len(echte), (', %d abgewiesen' % len(abgewiesen)) if abgewiesen else '',
|
% (len(echte), (', %d abgewiesen' % len(abgewiesen)) if abgewiesen else '',
|
||||||
erwartet, gesamt, verschachtelt))
|
erwartet, gesamt, verschachtelt))
|
||||||
for a in echte:
|
for a in echte:
|
||||||
print(' - %-42s %s Prompt %6d Z. Ergebnis %s Z.'
|
print(' - %-42s %-16s Prompt %6d Z. %s'
|
||||||
% ((a['description'] or '')[:42], a['subagent_type'], len(a['prompt']), a['ergebnis_zeichen']))
|
% ((a['description'] or '')[:42], a['subagent_type'], len(a['prompt']),
|
||||||
|
'Hintergrund (Start-Quittung)' if a.get('nur_startquittung')
|
||||||
|
else 'Ergebnis %s Z.' % a['ergebnis_zeichen']))
|
||||||
print('geschrieben:', os.path.join(meta, 'subagenten.md'))
|
print('geschrieben:', os.path.join(meta, 'subagenten.md'))
|
||||||
|
|||||||
@@ -0,0 +1,207 @@
|
|||||||
|
#!/usr/bin/env python3
|
||||||
|
"""Create and verify an isolated Codex analysis workspace."""
|
||||||
|
|
||||||
|
from __future__ import annotations
|
||||||
|
|
||||||
|
import argparse
|
||||||
|
import hashlib
|
||||||
|
import json
|
||||||
|
import os
|
||||||
|
import shutil
|
||||||
|
import subprocess
|
||||||
|
import tempfile
|
||||||
|
from pathlib import Path
|
||||||
|
|
||||||
|
|
||||||
|
def fail(message: str) -> None:
|
||||||
|
raise SystemExit(message)
|
||||||
|
|
||||||
|
|
||||||
|
def resolved(path: str) -> Path:
|
||||||
|
return Path(path).resolve()
|
||||||
|
|
||||||
|
|
||||||
|
def native_path(path: Path) -> str:
|
||||||
|
value = str(path)
|
||||||
|
if os.name == "nt" and not value.startswith("\\\\?\\"):
|
||||||
|
return "\\\\?\\" + value
|
||||||
|
return value
|
||||||
|
|
||||||
|
|
||||||
|
def allowed_workspace(workspace: Path, meta: Path) -> bool:
|
||||||
|
temporary_root = Path(tempfile.gettempdir()).resolve()
|
||||||
|
return (
|
||||||
|
(workspace.parent == meta and workspace.name == "workspace")
|
||||||
|
or (workspace.parent == temporary_root and workspace.name.startswith("codex-experiment-"))
|
||||||
|
)
|
||||||
|
|
||||||
|
|
||||||
|
def git_output(cwd: Path, *args: str) -> bytes:
|
||||||
|
completed = subprocess.run(
|
||||||
|
["git", "-C", str(cwd), *args],
|
||||||
|
check=True,
|
||||||
|
stdout=subprocess.PIPE,
|
||||||
|
stderr=subprocess.PIPE,
|
||||||
|
)
|
||||||
|
return completed.stdout
|
||||||
|
|
||||||
|
|
||||||
|
def source_files(source: Path) -> tuple[list[Path], str | None]:
|
||||||
|
try:
|
||||||
|
top = resolved(git_output(source, "rev-parse", "--show-toplevel").decode().strip())
|
||||||
|
relative_source = source.relative_to(top)
|
||||||
|
raw = git_output(
|
||||||
|
top,
|
||||||
|
"ls-files",
|
||||||
|
"-z",
|
||||||
|
"--cached",
|
||||||
|
"--others",
|
||||||
|
"--exclude-standard",
|
||||||
|
"--",
|
||||||
|
relative_source.as_posix(),
|
||||||
|
)
|
||||||
|
paths = []
|
||||||
|
for entry in raw.split(b"\0"):
|
||||||
|
if not entry:
|
||||||
|
continue
|
||||||
|
candidate = resolved(top / os.fsdecode(entry))
|
||||||
|
if candidate.is_file() and candidate.is_relative_to(source):
|
||||||
|
paths.append(candidate)
|
||||||
|
return sorted(set(paths), key=lambda item: item.as_posix().casefold()), str(top)
|
||||||
|
except (subprocess.CalledProcessError, ValueError):
|
||||||
|
paths = [item for item in source.rglob("*") if item.is_file() and ".git" not in item.parts]
|
||||||
|
return sorted(paths, key=lambda item: item.as_posix().casefold()), None
|
||||||
|
|
||||||
|
|
||||||
|
def sha256(path: Path) -> str:
|
||||||
|
digest = hashlib.sha256()
|
||||||
|
with open(native_path(path), "rb") as handle:
|
||||||
|
for chunk in iter(lambda: handle.read(1024 * 1024), b""):
|
||||||
|
digest.update(chunk)
|
||||||
|
return digest.hexdigest().upper()
|
||||||
|
|
||||||
|
|
||||||
|
def manifest(workspace: Path) -> dict[str, dict[str, int | str]]:
|
||||||
|
result: dict[str, dict[str, int | str]] = {}
|
||||||
|
workspace_native = native_path(workspace)
|
||||||
|
files: list[tuple[str, Path]] = []
|
||||||
|
for directory, _, names in os.walk(workspace_native):
|
||||||
|
for name in names:
|
||||||
|
full_path = Path(directory) / name
|
||||||
|
relative = os.path.relpath(str(full_path), workspace_native).replace("\\", "/")
|
||||||
|
files.append((relative, full_path))
|
||||||
|
for relative, path in sorted(files, key=lambda item: item[0].casefold()):
|
||||||
|
result[relative] = {"size": os.stat(str(path)).st_size, "sha256": sha256(path)}
|
||||||
|
return result
|
||||||
|
|
||||||
|
|
||||||
|
def write_json(path: Path, value: object) -> None:
|
||||||
|
path.parent.mkdir(parents=True, exist_ok=True)
|
||||||
|
path.write_text(json.dumps(value, ensure_ascii=False, indent=2) + "\n", encoding="utf-8")
|
||||||
|
|
||||||
|
|
||||||
|
def create(source_arg: str, workspace_arg: str, meta_arg: str) -> None:
|
||||||
|
source = resolved(source_arg)
|
||||||
|
workspace = resolved(workspace_arg)
|
||||||
|
meta = resolved(meta_arg)
|
||||||
|
if not source.is_dir():
|
||||||
|
fail(f"Source directory does not exist: {source}")
|
||||||
|
if not allowed_workspace(workspace, meta):
|
||||||
|
fail("Workspace must be _meta/workspace or a codex-experiment-* directory in system temp")
|
||||||
|
if workspace.exists():
|
||||||
|
before_manifest = meta / "workspace-manifest-before.json"
|
||||||
|
if workspace.parent == meta and workspace.name == "workspace" and not before_manifest.exists():
|
||||||
|
shutil.rmtree(native_path(workspace))
|
||||||
|
else:
|
||||||
|
fail(f"Workspace already exists: {workspace}")
|
||||||
|
|
||||||
|
files, git_root = source_files(source)
|
||||||
|
workspace.mkdir(parents=True)
|
||||||
|
for path in files:
|
||||||
|
relative = path.relative_to(source)
|
||||||
|
target = workspace / relative
|
||||||
|
os.makedirs(native_path(target.parent), exist_ok=True)
|
||||||
|
try:
|
||||||
|
shutil.copy2(native_path(path), native_path(target), follow_symlinks=False)
|
||||||
|
except OSError as error:
|
||||||
|
fail(f"Failed to copy {path} -> {target}: {error}")
|
||||||
|
|
||||||
|
before = manifest(workspace)
|
||||||
|
write_json(meta / "workspace-manifest-before.json", before)
|
||||||
|
write_json(
|
||||||
|
meta / "workspace-source.json",
|
||||||
|
{
|
||||||
|
"source": str(source),
|
||||||
|
"workspace": str(workspace),
|
||||||
|
"git_root": git_root,
|
||||||
|
"file_count": len(before),
|
||||||
|
"total_bytes": sum(int(item["size"]) for item in before.values()),
|
||||||
|
},
|
||||||
|
)
|
||||||
|
print(f"Created isolated workspace with {len(before)} files: {workspace}")
|
||||||
|
|
||||||
|
|
||||||
|
def verify(workspace_arg: str, meta_arg: str) -> None:
|
||||||
|
workspace = resolved(workspace_arg)
|
||||||
|
meta = resolved(meta_arg)
|
||||||
|
before_path = meta / "workspace-manifest-before.json"
|
||||||
|
if not workspace.is_dir() or not before_path.is_file():
|
||||||
|
fail("Workspace or before-manifest is missing")
|
||||||
|
|
||||||
|
before = json.loads(before_path.read_text(encoding="utf-8"))
|
||||||
|
after = manifest(workspace)
|
||||||
|
added = sorted(set(after) - set(before), key=str.casefold)
|
||||||
|
removed = sorted(set(before) - set(after), key=str.casefold)
|
||||||
|
modified = sorted(
|
||||||
|
(path for path in set(before) & set(after) if before[path] != after[path]),
|
||||||
|
key=str.casefold,
|
||||||
|
)
|
||||||
|
write_json(meta / "workspace-manifest-after.json", after)
|
||||||
|
result = {
|
||||||
|
"unchanged": not (added or removed or modified),
|
||||||
|
"added": added,
|
||||||
|
"removed": removed,
|
||||||
|
"modified": modified,
|
||||||
|
"file_count_before": len(before),
|
||||||
|
"file_count_after": len(after),
|
||||||
|
}
|
||||||
|
write_json(meta / "workspace-integrity.json", result)
|
||||||
|
print(json.dumps(result, ensure_ascii=False))
|
||||||
|
if not result["unchanged"]:
|
||||||
|
raise SystemExit(3)
|
||||||
|
|
||||||
|
|
||||||
|
def cleanup(workspace_arg: str, meta_arg: str) -> None:
|
||||||
|
workspace = resolved(workspace_arg)
|
||||||
|
meta = resolved(meta_arg)
|
||||||
|
if not allowed_workspace(workspace, meta):
|
||||||
|
fail("Refusing to remove a directory outside the approved experiment workspace locations")
|
||||||
|
if workspace.exists():
|
||||||
|
shutil.rmtree(native_path(workspace))
|
||||||
|
print(f"Removed temporary workspace: {workspace}")
|
||||||
|
|
||||||
|
|
||||||
|
def main() -> None:
|
||||||
|
parser = argparse.ArgumentParser()
|
||||||
|
subparsers = parser.add_subparsers(dest="command", required=True)
|
||||||
|
create_parser = subparsers.add_parser("create")
|
||||||
|
create_parser.add_argument("source")
|
||||||
|
create_parser.add_argument("workspace")
|
||||||
|
create_parser.add_argument("meta")
|
||||||
|
verify_parser = subparsers.add_parser("verify")
|
||||||
|
verify_parser.add_argument("workspace")
|
||||||
|
verify_parser.add_argument("meta")
|
||||||
|
cleanup_parser = subparsers.add_parser("cleanup")
|
||||||
|
cleanup_parser.add_argument("workspace")
|
||||||
|
cleanup_parser.add_argument("meta")
|
||||||
|
args = parser.parse_args()
|
||||||
|
if args.command == "create":
|
||||||
|
create(args.source, args.workspace, args.meta)
|
||||||
|
elif args.command == "verify":
|
||||||
|
verify(args.workspace, args.meta)
|
||||||
|
else:
|
||||||
|
cleanup(args.workspace, args.meta)
|
||||||
|
|
||||||
|
|
||||||
|
if __name__ == "__main__":
|
||||||
|
main()
|
||||||
+307
-4
@@ -30,7 +30,7 @@ gleichen Bedingungen streuen.
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2. Chronologie in sechs Phasen
|
## 2. Chronologie in acht Phasen
|
||||||
|
|
||||||
### Phase 1 – Erster Lauf und die Entdeckung der Werkzeugkonfiguration (12:29–13:00)
|
### Phase 1 – Erster Lauf und die Entdeckung der Werkzeugkonfiguration (12:29–13:00)
|
||||||
|
|
||||||
@@ -287,6 +287,285 @@ und Iteration 3 entstanden am selben Tag. Weil „Iteration" mit der Fassung der
|
|||||||
kollidierte, heißt diese seither **Prompt-Version**. Die Prompt-Dateien selbst blieben unverändert:
|
kollidierte, heißt diese seither **Prompt-Version**. Die Prompt-Dateien selbst blieben unverändert:
|
||||||
Ihre SHA-256 sind in 33 Protokollen dokumentiert.
|
Ihre SHA-256 sind in 33 Protokollen dokumentiert.
|
||||||
|
|
||||||
|
### Phase 7 – Delegation, Effort und zwei Totalausfälle (26.08., ab 12:50)
|
||||||
|
|
||||||
|
Nach den zehn `solo`-Läufen folgten drei Zellen, die die verbliebenen Stellschrauben trennen
|
||||||
|
sollten: `builtin` mit Sonnet, `max`-Effort mit Opus, und `builtin` mit Opus.
|
||||||
|
|
||||||
|
**Der Effort ist die wirksamste Einzelvariable der gesamten Reihe.** Über alle 44 Läufe auf
|
||||||
|
`high` lag der Median konstant bei **einem** Beleg je Anforderung – genau der Befund, wegen dem
|
||||||
|
Prompt-Version 02 geschrieben wurde und der sich unter Version 02 auf `high` sogar verschärft
|
||||||
|
hatte. Die drei `max`-Läufe liegen bei 2,0 / 2,0 / 3,0:
|
||||||
|
|
||||||
|
| Lauf | Anf. | Belege/Anf. | mit Primärbeleg | Risiko offen | Tokens |
|
||||||
|
|---|---:|---:|---:|---:|---:|
|
||||||
|
| `a8f5` | 380 | 2,0 | 95,5 % | 0 von 112 | 67,5 Mio. |
|
||||||
|
| `37c5` | 434 | 2,0 | **100 %** | 0 von 100+ | 77,3 Mio. |
|
||||||
|
| `fcdf` | 446 | **3,0** | 98,2 % | 0 von 139 | 116,2 Mio. |
|
||||||
|
|
||||||
|
Alle drei erfüllen sämtliche fünf Regelkriterien. **Damit kippt auch die Anti-Korrelation:** Über
|
||||||
|
die zehn `solo`/`high`-Läufe liefen Anforderungszahl und Belegqualität gegeneinander
|
||||||
|
(Pearson −0,63, Spearman −0,70); auf `max` treten beide zusammen auf. Der Zielkonflikt war kein
|
||||||
|
Gesetz, sondern Folge zu knappen Aufwands. Das beantwortet zugleich die in Abschnitt 8 offene
|
||||||
|
Frage nach dem Fable-Block teilweise: Der Verbrauchssprung dort kam **nicht** allein vom Modell.
|
||||||
|
|
||||||
|
**`max` zeigt sich nicht in Thinking-Tokens.** `a8f5` liegt mit 51.019 im Bereich der
|
||||||
|
`high`-Läufe (33.051–55.760). Der Mehraufwand steckt in Turns und Laufzeit: 210 bis 371 Turns,
|
||||||
|
1:34 bis 2:33 Stunden. Die Vermutung aus Iteration 1, `max` sei an den Thinking-Token-Werten
|
||||||
|
erkennbar, trägt nicht.
|
||||||
|
|
||||||
|
**Bei `builtin` entscheidet die Beauftragung der Subagenten, nicht deren Anzahl.** Drei Läufe,
|
||||||
|
gleicher Prompt, gleiches Modell:
|
||||||
|
|
||||||
|
| Lauf | Subagenten | Auftragsart | Anf. | mit Primärbeleg |
|
||||||
|
|---|---:|---|---:|---:|
|
||||||
|
| `4048` | 6 | „concrete, citable **FACTS only** … find the **EXACT enforcing location**" | 185 | **97,8 %** |
|
||||||
|
| `fb24` | 31 (2 Ebenen) | „Research … M01–M20" mit Faktenpflicht | 383 | **96,9 %** |
|
||||||
|
| `f8b4` | 8 | „**quickly inspect** … open **1-3 representative files**" | 276 | **46,4 %** |
|
||||||
|
|
||||||
|
Aus einer Stichprobe von ein bis drei Dateien lässt sich kein Primärbeleg gewinnen – die
|
||||||
|
durchsetzende Stelle liegt fast nie in der Datei, die repräsentativ aussieht. Damit hat
|
||||||
|
Befund 6.3 erstmals eine **inhaltliche** Erklärung statt nur einer Zahl. Genau dafür wurde die
|
||||||
|
Erfassung der Subagenten-Prompts in Skill 3.3.0 eingeführt.
|
||||||
|
|
||||||
|
Nebenbefund: `fb24` verlagerte 63,5 % seines Verbrauchs auf die Subagenten, `4048` sogar 78,4 %,
|
||||||
|
bei nur 26 Turns im Hauptagenten. Delegation verschiebt den Verbrauch, ohne ihn zwangsläufig zu
|
||||||
|
erhöhen – anders als in Iteration 1, wo `builtin` deutlich über `solo` lag.
|
||||||
|
|
||||||
|
**Zwei Totalausfälle in der Zelle Opus + `builtin`.** Beide Läufe scheiterten, auf verschiedene
|
||||||
|
Weise, und verbrauchten zusammen **586 Mio. Tokens ohne verwertbares Ergebnis**:
|
||||||
|
|
||||||
|
- `116d` – **stiller Fehlschlag.** `is_error: false`, `subtype: success`,
|
||||||
|
`terminal_reason: completed` – und **null Ergebnisdateien**. Der Hauptagent hatte zehn
|
||||||
|
Subagenten im Hintergrund gestartet und seinen Turn beendet; der Headless-Modus wartete 600 s
|
||||||
|
und brach ab. Der einzige Hinweis stand in `Stderr.log`. Verbraucht: 193,4 Mio. Tokens.
|
||||||
|
- `9d9e` – **API-Abbruch**, HTTP 429, „You've hit your session limit". 34 Subagenten, davon 24
|
||||||
|
von Subagenten gestartet, 22 weitere am Nebenläufigkeitslimit abgewiesen. Verbraucht:
|
||||||
|
392,9 Mio. Tokens, eine Ergebnisdatei von sieben.
|
||||||
|
|
||||||
|
Der stille Fehlschlag ist der methodisch wichtigere: **`is_error` erkennt ihn nicht.** Ohne den
|
||||||
|
Blick ins Ergebnisverzeichnis wäre der Lauf als gültiger Messpunkt mit „0 Anforderungen" in den
|
||||||
|
Modellvergleich eingegangen.
|
||||||
|
|
||||||
|
**Die Modellbedingung ist bei Delegation nicht über `--model` herstellbar.** `9d9e` weist neben
|
||||||
|
`claude-opus-5` auch `claude-sonnet-5` mit 18,5 Mio. Tokens (4,72 %) aus – der zweite
|
||||||
|
dokumentierte Fall nach Fable in Iteration 1. Beide betreffen ausschließlich den Modus `builtin`.
|
||||||
|
Für saubere Modellvergleiche ist `solo` zu verwenden oder die Modellbindung der Subagenten
|
||||||
|
gesondert zu belegen. Das betrifft Versuch 2 und 3 unmittelbar, die beide auf Delegation setzen.
|
||||||
|
|
||||||
|
**Vier weitere Messinstrument-Defekte gefunden und behoben:**
|
||||||
|
|
||||||
|
- *Abgewiesene Subagenten wurden als Subagenten gezählt* (Skill 4.5.0 / heute 6.1.0-Zweig).
|
||||||
|
`fb24` meldete 21 gefundene gegenüber 13 erwarteten Aufrufen; die Differenz waren 8 Absagen am
|
||||||
|
Nebenläufigkeitslimit, die im Transkript wie Starts aussehen. Nach der Trennung stimmen alle
|
||||||
|
drei Läufe exakt. Die Zahl der Absagen ist selbst eine Messgröße für die *beabsichtigte*
|
||||||
|
Parallelität.
|
||||||
|
- *Die Rückgabe eines Hintergrund-Subagenten ist eine Start-Quittung*, keine Befunde. Die
|
||||||
|
einheitlichen 1.093 Zeichen, die als „Ergebnis" protokolliert wurden, sind der Text „Async
|
||||||
|
agent launched successfully …". Als Ertragsmaß war das wertlos.
|
||||||
|
- *Subagenten-Transkripte* werden unter `<temp>\<session>\tasks\<agentId>.output` angelegt,
|
||||||
|
bleiben aber **leer** – geprüft an 33 Dateien aus zwei Läufen. Die bisherige Aussage, sie seien
|
||||||
|
nicht auswertbar persistiert, gilt damit unverändert.
|
||||||
|
- *Gültigkeitsprüfung ergänzt:* leeres Ergebnisverzeichnis oder Abbruchmeldung in `Stderr.log`
|
||||||
|
bedeutet Fehlmessung, unabhängig von `is_error`. Vorbeugend setzt der Ausführungsabschnitt
|
||||||
|
jetzt `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`.
|
||||||
|
|
||||||
|
**Ein Befund zur Belegquelle, den ein Agent selbst entdeckte.** `116d` hielt im Abschlusstext
|
||||||
|
fest, die Codebasis enthalte „keine `.git`-Historie und keine SQL-Migrationsskripte". Das trifft
|
||||||
|
zu und gilt für **alle** Läufe der Reihe: Seit die Codebasis als Dateien ins Arbeitsrepo
|
||||||
|
übernommen wurde, ist die Entwicklungshistorie der ERP-Suite nicht mehr erreichbar. Der Prompt
|
||||||
|
fordert Commit-Messages, Tickets und Release Notes in Schritt 2 ausdrücklich als Artefaktquelle –
|
||||||
|
diese Quelle steht der gesamten Versuchsreihe nicht zur Verfügung.
|
||||||
|
|
||||||
|
### Vorbereitung von Versuch 2 und 3
|
||||||
|
|
||||||
|
Beide Versuchsverzeichnisse wurden angelegt und nach den Vorgaben aus @tab_versuchskonfiguration
|
||||||
|
konfiguriert. Die Prompt-Kette folgt der dort festgelegten Ableitung **V1 → V2 → V3**.
|
||||||
|
|
||||||
|
| Artefakt | SHA-256 | Ableitung |
|
||||||
|
|---|---|---|
|
||||||
|
| `Versuch_02/01_Prompt.md` | `DCDC0E3F…B71BCF` | Prompt-Version 02-A: aus V1, angepasst an Agentendateien |
|
||||||
|
| `Versuch_02/01_Agents.json` | `6943EECD…AF1696` | acht Rollen |
|
||||||
|
| `Versuch_03/01_Prompt.md` | `E65A696C…6A06E1` | Prompt-Version 02-B: aus V2, angepasst an MCP-Server |
|
||||||
|
| `Versuch_03/01_Agents.json` | `EDCB8001…C49B55` | elf Rollen |
|
||||||
|
| `Versuch_03/01_MCP.json` | `F08840F7…5EE2DB` | fünf Werkzeugserver |
|
||||||
|
|
||||||
|
**Die Anpassung „an Agentendateien" ist ein einziger neuer Abschnitt: Arbeitsteilung.** Er nennt
|
||||||
|
keine Rolle und schreibt keinen Zuschnitt vor. Er schließt die Lücken, die entstehen, wenn nicht
|
||||||
|
mehr ein Bearbeiter die ganze Kette durchläuft: Prompt-Version 02 ordnet Schritte zeitlich,
|
||||||
|
vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck – bei verteilter Bearbeitung
|
||||||
|
ist nichts davon von selbst erfüllt. Die vier Kernsätze: ID-Bereiche vorab und
|
||||||
|
überschneidungsfrei; die Ebene ergibt sich aus dem Inhalt, nicht aus dem Bearbeiter; die
|
||||||
|
Mindestabdeckung gilt für das **gemeinsame** Inventar, nicht je Ausschnitt; der Konsistenzcheck
|
||||||
|
gilt dem zusammengeführten Ergebnis. Der Abschnitt ist bei einem einzelnen Bearbeiter
|
||||||
|
wirkungslos, sodass der Prompt auch für einen `solo`-Lauf gültig bleibt.
|
||||||
|
|
||||||
|
**Die Rollen sind aus den Messungen abgeleitet.** Drei getrennte Autoren je Ebene gegen die
|
||||||
|
Verteilungsstreuung (92,7 % StRS bis 89,4 % SwRS bei identischem Prompt); ein `faktenermittler`
|
||||||
|
nach dem Muster des erfolgreichsten `builtin`-Laufs samt Stichprobenverbot; ein neuer
|
||||||
|
`belegpruefer`, der zitierte Primärbelege öffnet und prüft, ob die Einstufung trägt; ein
|
||||||
|
`konsistenzpruefer`, der seinen Risikobegriff offenlegen muss, weil ein Lauf „alle 36 gedeckt"
|
||||||
|
meldete, während die maschinelle Prüfung 51 risikorelevante Anforderungen fand.
|
||||||
|
|
||||||
|
**Der ISO-29148-Orchestrator ist als konsolidierende, nicht delegierende Rolle umgesetzt.** Er
|
||||||
|
startet keine Subagenten und schreibt keine Anforderungen, sondern stellt her, was erst am
|
||||||
|
zusammengeführten Bestand entsteht: durchgängige Nummerierung samt mitgezogener Verweise,
|
||||||
|
beidseitig geschlossene Traceability, eine aus dem Gesamtbestand erzeugte Hypothesenliste und die
|
||||||
|
Abdeckungstabelle über das gemeinsame Inventar. Sein Schwerpunkt liegt auf den Nahtstellen
|
||||||
|
zwischen den Ausschnitten – dort sitzen die Fehler verteilter Bearbeitung. Ein **delegierender**
|
||||||
|
Orchestrator wäre die naheliegende, aber messtechnisch schlechtere Lösung gewesen: Er erzeugte
|
||||||
|
eine zweite Delegationsebene, deren Subagenten-Prompts nicht protokollierbar sind – bei `fb24`
|
||||||
|
blieben so 18 von 31 Aufrufen unerfassbar.
|
||||||
|
|
||||||
|
**Versuch 3 erhielt eine eigene Prompt-Version.** Prompt-Version 02-A schreibt „statische
|
||||||
|
Analyse, keine Ausführung" vor und begrenzt die Quellen auf das Arbeitsverzeichnis; ein live
|
||||||
|
gestartetes ERP verletzt beides. Geändert wurde nur das Nötige: Quellenbeschränkung erweitert,
|
||||||
|
Schritt 2b „Beobachtung am laufenden System" (ausdrücklich lesend), neue Belegklasse `LAUFZEIT`
|
||||||
|
als **nachrangig** gegenüber `PRIMÄR`, und Kennzeichnung fremden Wissens. Der Abschnitt
|
||||||
|
Arbeitsteilung wird aus V2 unverändert geerbt.
|
||||||
|
|
||||||
|
Fünf Werkzeugserver sind vorgesehen: `serena` (Symbol-Navigation), `mssql` (Datenbank-Inspektion,
|
||||||
|
read-only), `windows-mcp` und `playwright` (GUI-Beobachtung für Desktop-Client und Blazor-Portal)
|
||||||
|
sowie `context7`. Letzterer steht nicht in der Aufzählung der Arbeit und ist eine bewusst
|
||||||
|
hinzugenommene Erweiterung; er ist zugleich der einzige der fünf, der nicht lokal betrieben wird.
|
||||||
|
|
||||||
|
Zwei Server wurden **ausgeschlossen**: `memory`, weil er Zustand zwischen Läufen trägt und damit
|
||||||
|
die Unabhängigkeit der Wiederholungsmessungen zerstört, und `sequential-thinking`, weil er den
|
||||||
|
`--effort`-Parameter dupliziert – zwei Variablen gleichzeitig zu verändern war schon beim
|
||||||
|
Fable-Block der Fehler.
|
||||||
|
|
||||||
|
**Ein Blocker, gefunden bevor er einen Messlauf gekostet hat: `--safe-mode` ist mit V2 und V3
|
||||||
|
unvereinbar.** Das Flag schaltet ausweislich der CLI-Hilfe „MCP servers, custom commands and
|
||||||
|
agents" ab – also genau das, was beide Versuche untersuchen. Smoke-Test am 2026-08-26 (CLI
|
||||||
|
2.1.246, identischer Aufruf, nur das Flag variiert):
|
||||||
|
|
||||||
|
| Konfiguration | `spawned` | `by_type` |
|
||||||
|
|---|---:|---|
|
||||||
|
| mit `--safe-mode` | **0** | leer – „die Rollen sind nicht in der Agent-Registry registriert" |
|
||||||
|
| ohne `--safe-mode` | **2** | `{"modulinventar": 1, "konsistenzpruefer": 1}` |
|
||||||
|
|
||||||
|
Der Fehler wäre **still** geblieben: `--agents` hätte keine Wirkung gehabt, der Lauf wäre
|
||||||
|
fehlerfrei durchgelaufen und hätte Anforderungen erzeugt – nur ohne die Rollen, die den Versuch
|
||||||
|
ausmachen. Er wäre als V2-Lauf protokolliert worden und wäre in Wahrheit ein V1-Lauf gewesen.
|
||||||
|
|
||||||
|
Der Ersatz (Skill 7.0.0, MAJOR): kein `--safe-mode` in den Modi `custom` und bei MCP-Einsatz,
|
||||||
|
stattdessen `--strict-mcp-config` plus `--disallowedTools Skill WebSearch WebFetch SlashCommand`.
|
||||||
|
Gegengeprüft mit derselben Werkzeugabfrage: nichts vorgeladen, keine Skills, kein Webzugriff,
|
||||||
|
alle Rollen verfügbar. Bemerkenswert dabei: Ohne die Sperre lädt die CLI **16 global installierte
|
||||||
|
Skills** – darunter `code-review`, `security-review`, `run` und `init`. `--setting-sources ''`
|
||||||
|
unterdrückt sie nicht.
|
||||||
|
|
||||||
|
Der Ersatz deckt Plugins, Hooks und Output-Styles nicht ab. Auf der Versuchsmaschine ist davon
|
||||||
|
nichts konfiguriert – geprüft: `~/.claude/settings.json` enthält nur `model` und
|
||||||
|
`agentPushNotifEnabled`, kein `hooks`; kein `plugins`- und kein `output-styles`-Verzeichnis. Das
|
||||||
|
ist eine Eigenschaft der Umgebung, keine Garantie, weshalb der Skill vor jedem `custom`-Lauf eine
|
||||||
|
Umgebungsprüfung verlangt. **Läufe im Modus `custom` sind hinsichtlich der Isolation damit nicht
|
||||||
|
unmittelbar mit den `solo`- und `builtin`-Läufen vergleichbar**; der Unterschied ist benannt und
|
||||||
|
auf Plugins, Hooks und Output-Styles begrenzt.
|
||||||
|
|
||||||
|
Nebenbefund derselben Prüfung: In den User-Settings steht `model: opus[1m]`. Das ist die Quelle
|
||||||
|
der zwei dokumentierten Modellabweichungen bei Delegation – und `--safe-mode` hat sie nie
|
||||||
|
verhindert, wirkt hier also weder positiv noch negativ.
|
||||||
|
|
||||||
|
**Offene Punkte vor dem ersten Lauf beider Versuche:** `extract-subagenten.py` ist nicht gegen
|
||||||
|
`custom`-Agententypen geprüft; die Modellbedingung ist bei Delegation über `--model` allein nicht
|
||||||
|
herstellbar; für V3 sind die Serverversionen nicht gepinnt, und der Zustand des laufenden Systems
|
||||||
|
– Datenbankstand, Mandant, Datenart – ist als Teil des Untersuchungsgegenstands je Lauf zu
|
||||||
|
erfassen.
|
||||||
|
|
||||||
|
### Phase 8 – Rastererweiterung, Kontingentgrenzen und der Wechsel auf serielle Läufe (26.–27.08.)
|
||||||
|
|
||||||
|
Iteration 3 belegte zu Beginn dieser Phase erst **4 von 12 Zellen** des aufgespannten Rasters aus
|
||||||
|
drei Modellen, zwei Agentenmodi und zwei Effort-Stufen. Ziel war, je einen Lauf für die fehlenden
|
||||||
|
Kombinationen zu erheben.
|
||||||
|
|
||||||
|
**Der erste Anlauf scheiterte vollständig – an der Parallelität.** Vier gleichzeitig gestartete
|
||||||
|
Läufe (19:59) liefen sämtlich in HTTP 429, „You've hit your session limit". Zusammen hatten sie
|
||||||
|
bis dahin **297,4 Mio. Tokens** verbraucht, davon allein 204,4 Mio. in `opus-5/builtin/high`. Drei
|
||||||
|
der vier hatten Teilergebnisse erzeugt, bevor das Kontingent riss – zwischen einer und drei von
|
||||||
|
sieben Dateien; sie sind als Fehlmessungen mit Teilbestand protokolliert und gehen in keinen
|
||||||
|
Vergleich ein.
|
||||||
|
|
||||||
|
Daraus folgte die Umstellung auf **strikt serielle Läufe**. Sie hat einen messtechnischen
|
||||||
|
Nebeneffekt, der über die Kontingentfrage hinausreicht: Seit dem seriellen Lauf `d6f9` waren
|
||||||
|
sämtliche Wanduhrzeiten entweder durch Parallelbetrieb oder durch Kontingent-Wartezeiten
|
||||||
|
verzerrt. Serielle Läufe machen die Laufzeit wieder zu einer verwertbaren Messgröße.
|
||||||
|
|
||||||
|
**Zwei neue Zellen sind seriell entstanden und gültig:**
|
||||||
|
|
||||||
|
| Zelle | Anf. | StRS/SyRS/SwRS | Primärbeleg | Belege/Anf. | Tokens | Wanduhr |
|
||||||
|
|---|---:|---|---:|---:|---:|---:|
|
||||||
|
| `opus-5/solo/high` | 363 | 62/132/169 | **99,7 %** | **2,0** | 38,1 Mio. | 26 min |
|
||||||
|
| `fable-5/solo/high` | 241 | 33/50/158 | 98,3 % | 1,0 | 30,6 Mio. | 7:03 h\* |
|
||||||
|
|
||||||
|
\*Kontingent-Wartezeit, siehe unten.
|
||||||
|
|
||||||
|
**Befund: Die Belegdichte folgt dem Modell, nicht dem Effort.** In Phase 7 war die verdoppelte
|
||||||
|
Belegdichte – Median 2,0 statt 1,0 – dem `max`-Effort zugeschrieben worden, weil alle 44
|
||||||
|
vorherigen `high`-Läufe bei Median 1,0 lagen. `opus-5/solo/high` erreicht Median **2,0 auf
|
||||||
|
`high`**. Die 44 Läufe mit Median 1,0 liefen sämtlich auf Sonnet, die `max`-Läufe auf Opus – die
|
||||||
|
beiden Variablen waren konfundiert. Nach jetzigem Stand:
|
||||||
|
|
||||||
|
| Modell | `high` | `max` |
|
||||||
|
|---|---:|---:|
|
||||||
|
| Sonnet | 1,0 | – |
|
||||||
|
| Fable | 1,0 | – |
|
||||||
|
| Opus | **2,0** | **2,0–3,0** |
|
||||||
|
|
||||||
|
Der Effort bleibt für den **Verbrauch** wirksam (38,1 Mio. auf `high` gegenüber 67,5–116,2 Mio.
|
||||||
|
auf `max`), für die Belegdichte ist das Modell die stärkere Größe.
|
||||||
|
|
||||||
|
**Befund: Die Fable-Modellverletzung ist reproduziert – und abgegrenzt.** Der Lauf
|
||||||
|
`fable-5/builtin/high` wies erneut `claude-opus-5[1m]` in `modelUsage` aus, wie schon in
|
||||||
|
Iteration 1 unter anderer Prompt-Version und anderem Snapshot. Der Lauf `fable-5/solo/high`
|
||||||
|
dagegen ist sauber: ausschließlich `claude-fable-5` plus Haiku. Damit steht fest: **Nicht Fable
|
||||||
|
ist die Ursache, sondern Fable in Kombination mit Delegation.** Sonnet und Opus werden an die
|
||||||
|
Subagenten durchgereicht, Fable nicht; die CLI fällt dann auf die Sitzungsvorgabe
|
||||||
|
`model: opus[1m]` aus `~/.claude/settings.json` zurück.
|
||||||
|
|
||||||
|
**`opus-5/builtin/high` ist zum dritten Mal gescheitert.** Über drei Anläufe zusammen
|
||||||
|
**790,7 Mio. Tokens ohne ein einziges verwertbares Artefakt**:
|
||||||
|
|
||||||
|
| Lauf | Abbruch | Subagenten | Tokens |
|
||||||
|
|---|---|---:|---:|
|
||||||
|
| `116d` | 600-s-Zeitlimit für Hintergrund-Subagenten | 20 (10 verschachtelt) | 193,4 |
|
||||||
|
| `9d9e` | Kontingent (429) | 34 (24 verschachtelt) | 392,9 |
|
||||||
|
| `45dd` | Kontingent (429) | 24 | 204,4 |
|
||||||
|
|
||||||
|
Jedes Mal dasselbe Muster: Opus zerlegt die Aufgabe in 20 bis 34 Subagenten, beendet seinen
|
||||||
|
eigenen Turn nach einem einzigen Turn und überlässt die Arbeit den Hintergrundagenten. Die
|
||||||
|
Korrektur des Zeitlimits (`CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`) beseitigte die erste Ursache;
|
||||||
|
die Delegationsbreite riss dann das Kontingent. **Die Zelle ist mit dieser Prompt-Version und
|
||||||
|
diesem Modell nicht messbar** – drei reproduzierbare Ausfälle sind als Grenzbefund über die
|
||||||
|
Delegation aussagekräftiger als ein vierter Versuch.
|
||||||
|
|
||||||
|
**Ein dritter Verzerrungsmechanismus der Zeitmessung.** `fable-5/solo/high` brauchte 7:03:44
|
||||||
|
Wanduhrzeit, ohne parallel zu laufen. Die Abstände zwischen den Werkzeugaufrufen zeigen den
|
||||||
|
Grund: Lücken von 4:00 h und zweimal rund 2 h. Bei erschöpftem Kontingent **bricht die CLI nicht
|
||||||
|
ab, sondern wartet auf das nächste Reset-Fenster** und arbeitet dann weiter. `duration_ms` bildet
|
||||||
|
diese Wartezeit mit ab. Neben Parallelbetrieb und Abbruch ist das die dritte Ursache unbrauchbarer
|
||||||
|
Zeitangaben – und die einzige, die von außen wie ein hängender Prozess aussieht. Tokenverbrauch,
|
||||||
|
Anforderungszahl und Belegkennzahlen sind davon nicht betroffen.
|
||||||
|
|
||||||
|
**Verbrauchsbilanz der Reihe.** Über beide Tage: 42 abgeschlossene Läufe, **2.294,7 Mio. Tokens**,
|
||||||
|
davon am 26.08. allein 1.703,6 Mio. mit fünf Fehlmessungen. Rund 880 Mio. Tokens – gut ein Drittel
|
||||||
|
des Gesamtverbrauchs – entfielen auf Läufe ohne verwertbares Ergebnis.
|
||||||
|
|
||||||
|
**Codex-Lauf verworfen.** Der Lauf `Iteration 5/gpt-5.6-sol/solo/high/…-54dd` stand seit
|
||||||
|
13,5 Stunden ohne Fortschritt und ohne `RawResult.json`; die Arbeitskopie lag zudem mit 352 MB im
|
||||||
|
Laufverzeichnis statt im System-Temp-Verzeichnis, wie Skill 6.0.0 es vorsieht. Prozesse beendet,
|
||||||
|
Lauf gelöscht. Der Neustart steht aus: Die Codex-CLI ist inzwischen auf **0.150.0-alpha.8**, der
|
||||||
|
Referenzstand des Adapters ist **0.149.0-alpha.4.3**. Der Skill verlangt bei geändertem
|
||||||
|
JSONL-Schema einen Smoke-Test des Normalisierers **vor** dem Messlauf – sonst endet ein
|
||||||
|
mehrstündiger Lauf mit nicht parsbaren Rohdaten.
|
||||||
|
|
||||||
|
**Serielle Kette gestartet (27.08., 08:12).** Sechs offene Zellen, günstigste zuerst, damit bei
|
||||||
|
einem Kontingentabbruch möglichst viele belegt sind: `fable/solo/max`, `sonnet/solo/max`,
|
||||||
|
`fable/builtin/high`, `sonnet/builtin/max`, `fable/builtin/max`, `opus/builtin/max`. Die Kette
|
||||||
|
wartet bei einem 429 einmal 70 Minuten und wiederholt dieselbe Zelle; beim zweiten 429 bricht sie
|
||||||
|
ab. Ein leeres Ergebnisverzeichnis trotz Erfolgsmeldung wird als Fehlmessung protokolliert, ohne
|
||||||
|
die Kette zu stoppen.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 3. Entwicklung des Prompts
|
## 3. Entwicklung des Prompts
|
||||||
@@ -548,9 +827,33 @@ Belegqualität zu halten – dann wäre die Änderung zurückzunehmen.
|
|||||||
|
|
||||||
## 8. Grenzen und offene Punkte
|
## 8. Grenzen und offene Punkte
|
||||||
|
|
||||||
**Nicht geklärt:** Ob der Verbrauchssprung im Fable-Block vom Modell oder vom Effort kommt –
|
**Teilweise geklärt:** Ob der Verbrauchssprung im Fable-Block vom Modell oder vom Effort kommt –
|
||||||
beide Variablen wechselten gleichzeitig. Ein Fable-Block auf `high` oder ein Sonnet-Block auf
|
beide Variablen wechselten gleichzeitig. Die Zelle `claude-opus-5 / solo / max` (Iteration 3)
|
||||||
`max` würde die Frage entscheiden.
|
zeigt, dass der Effort allein Verbrauch **und** Belegdichte erheblich anhebt. Vollständig
|
||||||
|
isoliert wäre die Frage erst durch einen Opus-`high`-Block unter denselben Bedingungen –
|
||||||
|
gleicher Snapshot, gleiche Prompt-Version.
|
||||||
|
|
||||||
|
**Nicht messbar:** Die Zelle `claude-opus-5 / builtin / high` ist **dreimal** gescheitert
|
||||||
|
(einmal Zeitlimit, zweimal Session-Kontingent) und hat dabei 790,7 Mio. Tokens ohne ein Artefakt
|
||||||
|
verbraucht. Sie wird als nicht messbare Kombination dokumentiert statt ein viertes Mal versucht.
|
||||||
|
Ein weiterer Anlauf wäre nur mit gedrosselter Nebenläufigkeit
|
||||||
|
(`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`) sinnvoll – das wäre allerdings eine geänderte
|
||||||
|
Werkzeugkonfiguration und nicht mehr mit den Sonnet-`builtin`-Läufen vergleichbar.
|
||||||
|
|
||||||
|
**Bedingungsverletzt statt unbelegt:** Die Zelle `claude-fable-5 / builtin / *` ist messbar, aber
|
||||||
|
die Modellbedingung ist dort nicht herstellbar – die Subagenten laufen auf `claude-opus-5[1m]`.
|
||||||
|
Läufe dieser Zelle sind für Modellvergleiche unbrauchbar und nur als Beleg für die
|
||||||
|
Durchreichungsgrenze zu verwenden.
|
||||||
|
|
||||||
|
**Kontingent als Versuchsgrenze:** Rund ein Drittel des Gesamtverbrauchs von 2.294,7 Mio. Tokens
|
||||||
|
entfiel auf Läufe ohne verwertbares Ergebnis, überwiegend durch Parallelbetrieb an der
|
||||||
|
Kontingentgrenze. Seit dem 27.08. wird strikt seriell gefahren.
|
||||||
|
|
||||||
|
**Offen für Versuch 2 und 3:** Bei Delegation ist die Modellbedingung über `--model` allein nicht
|
||||||
|
herstellbar (zwei dokumentierte Fälle). `extract-subagenten.py` ist noch nicht gegen
|
||||||
|
`custom`-Agententypen geprüft. Für V3 fehlt im Skill ein Protokollfeld für die
|
||||||
|
MCP-Konfiguration, und der Zustand des laufenden Systems – Datenbankstand, Mandant, Datenart –
|
||||||
|
ist als Teil des Untersuchungsgegenstands je Lauf zu erfassen.
|
||||||
|
|
||||||
**Nicht durchgeführt:** Die Stakeholder-Validierung nach Kapitel 4.3. Alle Aussagen dieses
|
**Nicht durchgeführt:** Die Stakeholder-Validierung nach Kapitel 4.3. Alle Aussagen dieses
|
||||||
Protokolls beruhen auf maschinell erhebbaren Größen. Ob die erzeugten Anforderungen sachlich
|
Protokolls beruhen auf maschinell erhebbaren Größen. Ob die erzeugten Anforderungen sachlich
|
||||||
|
|||||||
+252
@@ -0,0 +1,252 @@
|
|||||||
|
# Analysebericht — Reverse Requirements Engineering c-entron ERP-Suite
|
||||||
|
|
||||||
|
**Lauf:** V1 Baseline (Prompt-only), Iteration 02 — 2026-08-26
|
||||||
|
**Untersuchungsgegenstand:** Gesamte Codebasis unter `C:\DEV\MasterArbeit\QuellCode\CentronERP` (nur lesend analysiert)
|
||||||
|
**Methode:** Statische Analyse entlang der RRE-Methodenkette (Schritte 0, 0b, 0c, 2–6); keine Ausführung des Systems.
|
||||||
|
|
||||||
|
## Überblick über den Untersuchungsgegenstand
|
||||||
|
|
||||||
|
Die c-entron ERP-Suite ist ein ERP-/Servicemanagement-System für IT-Systemhäuser (deutschsprachiger Markt) mit:
|
||||||
|
|
||||||
|
- **WPF-Desktop-Client** (`src\centron\Centron.WPF.UI`, ~29 Fachmodule) — „c-entron.NET"
|
||||||
|
- **Backend-Geschäftslogik** (`src\backend\Centron.BL`, >80 Fachbereiche) mit NHibernate-Datenzugriff (`Centron.DAO`, `Centron.Entities`)
|
||||||
|
- **REST-Webservice** (`src\webservice\Centron.Host`, `Centron.Controllers`, `Centron.WebServices.Core`) — der WPF-Client arbeitet wahlweise direkt gegen SQL Server oder über den Webservice (Dual-Architektur `BLLogic`/`WSLogic`, siehe `docs\getting-started\general-structure.md`)
|
||||||
|
- **Blazor-Web-App „c-entron Nexus"** (`src\nexus\CentronNexus`) mit ServiceBoard (Ticket-Arbeitsplatz), WebCart-Kundenportal, WebOffer, Office, DocumentSigning, ProductionOrderManagement sowie ein **Outlook-Add-In**
|
||||||
|
- **Externe API-Integrationen** (`src\apis`, `Centron.Api.docuFORM`): ITscope, COP, EGIS, Icecat, finAPI, GLS, Shipcloud, ebInterface, docuFORM
|
||||||
|
- **MSSQL-Datenbank**: Schema-Dump `SSMS_DB_SCHEMA.sql` mit 1.535 `CREATE TABLE`-Anweisungen (Legacy-Tabellen mit deutschen Namen, z. B. `AngKopf`/`AufKopf`/`RechKopf`, plus englischsprachige Views)
|
||||||
|
- **Entwicklerdokumentation** (`docs\`) — dient als KONTEXT-Beleg (u. a. `CentronRights.md`, `docs\reference\receipts\*`, `docs\reference\security\*`)
|
||||||
|
- **Deployment**: WiX-Installer (`deployment\`), Docker/Linux-Betrieb des Webservice (`docker\`), Azure-Pipelines (`azure\`)
|
||||||
|
- **Tests**: `tests\` (End-to-End, Integration, Playwright, Unit)
|
||||||
|
|
||||||
|
Umfang: ca. 15.554 C#-Dateien. Eine Original-Commit-Historie des ERP-Produkts liegt nicht vor (die Codebasis wurde als Snapshot in das Arbeitsrepository übernommen); Change-Historie stand daher als Artefaktquelle nicht zur Verfügung.
|
||||||
|
|
||||||
|
## Schritt 0 — Modulinventar
|
||||||
|
|
||||||
|
Bezugsgröße für Abdeckung und Mindestabdeckung. Pfade relativ zu `C:\DEV\MasterArbeit\QuellCode\CentronERP`. Kürzel: `UI` = `src\centron\Centron.WPF.UI\Modules`, `BL` = `src\backend\Centron.BL`. Spalte AP = Arbeitspaket der Analyse.
|
||||||
|
|
||||||
|
### A — Vertrieb & Belegwesen
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M01 | Belegwesen Verkauf (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholliste) | `BL\Sales\Receipts` (Offers, Orders, DeliveryLists, Invoices, CreditVouchers, PickupLists, DownPayment), `UI\Sales` | Kern-Belegkette des Verkaufs von Angebot bis Gutschrift inkl. Versionierung und Statusführung. | AP1 |
|
||||||
|
| M02 | Sonderpreise / Aktionspreise | `docs\reference\receipts\actionprice-system.md`, BL `Accounts` (Sonderpreise), `UI\Sales\SpecialArticleImport` | Kunden-/aktionsbezogene Preisfindung und Import von Sonderpreisen. | AP1 |
|
||||||
|
| M03 | Belegkonditionen | `UI\Administration\ReceiptConditions` | Verwaltung von Zahlungs-/Lieferkonditionen für Belege. | AP1 |
|
||||||
|
| M04 | Kassenbuch | `BL\Sales\CashBooks` | Führen von Kassenbüchern mit Ein-/Auszahlungen. | AP1 |
|
||||||
|
| M05 | Schweiz-Sonderlogik Belege | `BL\Sales\Receipts\Switzerland` | Länderspezifische Sonderbehandlung von Belegen für die Schweiz. | AP1 |
|
||||||
|
| M06 | Stundenzuschlagssätze | `BL\Sales\HourlySurchargeRatesBL`, `UI\Administration\HourlySurchargeRates` | Zuschlagssätze auf Stundenleistungen. | AP1 |
|
||||||
|
| M07 | Serienmails/Mailing-Aktionen | `UI\Sales\Mailing`, `BL\Mailings` | Serienmail-Kampagnen mit Vorlagen und Empfängerlisten. | AP9 |
|
||||||
|
|
||||||
|
### B — Verträge & wiederkehrende Abrechnung
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M08 | Vertragsverwaltung | `UI\Finances\Contracts`, `BL\Sales\Receipts\ContractLists`, `docs\reference\receipts\contracts-backend.md` | Verwaltung von Service-/Wartungsverträgen als Belegart (VertragKopf/VertragPos). | AP2 |
|
||||||
|
| M09 | Automatische Vertragsabrechnung | `UI\Finances\AutomatedBilling`, `docs\reference\receipts\Contract-Billing-RMM-Article-Logic.md` | Periodische Fakturierung von Verträgen inkl. RMM-Mengenlogik. | AP2 |
|
||||||
|
| M10 | Flatrate-Abrechnung | `UI\Finances\FlatrateBilling` | Pauschal-Abrechnung von Leistungen. | AP2 |
|
||||||
|
| M11 | Timer-/Zeitabrechnung | `UI\Finances\TimerBilling`, `UI\Helpdesk` (HelpdeskTimers) | Abrechnung erfasster Arbeitszeiten aus Tickets. | AP2 |
|
||||||
|
| M12 | Geräte-Klickabrechnung | `UI\Finances\DeviceClickCounter` | Abrechnung von Druck-/Kopierklicks je Gerät (Zählerstände). | AP2 |
|
||||||
|
| M13 | Vertragsauswertung | `UI\Finances\ContractEvaluation2`, `UI\Finances\ContractEvaluationOld` | Wirtschaftlichkeitsauswertung von Verträgen (neue und alte Implementierung). | AP2 |
|
||||||
|
| M14 | SEPA-Vertragsdaten | `UI\Administration\SepaContract` | Verwaltung von SEPA-Mandaten/Bankdaten für Vertragsabrechnung. | AP2 |
|
||||||
|
| M15 | Telekom-DIVE-Export | `UI\Modules\TelekomDive` | Export von Vertrags-/Abrechnungsdaten im Telekom-DIVE-Format. | AP2 |
|
||||||
|
|
||||||
|
### C — Finanzen & Buchhaltung
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M16 | Offene Posten (OPOS) | `UI\Finances\Opos` | Überwachung offener Forderungen/Verbindlichkeiten. | AP3 |
|
||||||
|
| M17 | Zahlungsverkehr (Ein-/Ausgangszahlungen) | `UI\Finances\Payments`, `BL\Finances\IncomingPayments`, `BL\Finances\Payments`, `UI\Warehousing\OutcomingPayments` | Erfassen und Zuordnen von Zahlungen zu Belegen. | AP3 |
|
||||||
|
| M18 | Mahnwesen | `UI\Finances\Dunning` | Mahnläufe über fällige offene Posten. | AP3 |
|
||||||
|
| M19 | Online-Banking | `UI\Modules\OnlineBanking`, `BL\Finances\OnlineBanking`, `src\apis\Centron.APIs.FinAPI` | Bankkonten-Anbindung, Umsatzabruf und Zahlungen über finAPI. | AP3 |
|
||||||
|
| M20 | Buchhaltungsexport / DATEV | `UI\DataExchange\BookKeeping`, `UI\DataExchange\DatevOnline2020` | Export von Buchungsdaten an Finanzbuchhaltung/DATEV. | AP3 |
|
||||||
|
| M21 | E-Rechnung (ZUGFeRD/XRechnung/ebInterface) | `docs\guides\development\xrechnung.md`, `docs\reference\zugferd-field-mapping.md`, `src\apis\Centron.Api.EbInterface`, Controller `ZugferdImportController.cs`, `BL\ReportEngine` (ZUGFeRD-PDF) | Erzeugung und Import elektronischer Rechnungen. | AP3 |
|
||||||
|
| M22 | Bankverbindungen (Stammdaten) | `BL\Accounting` | Verwaltung der Bankkonten von Kunden und eigener Firma. | AP3 |
|
||||||
|
| M23 | Zahler & Kostenstellen | `UI\Modules\PayersAndCostCenter` | Verwaltung abweichender Zahler und Kostenstellen. | AP3 |
|
||||||
|
| M24 | Gutschein-Verwaltung | `BL\VoucherManagement` | Gutscheine mit Barcode und Einlösestatus. | AP3 |
|
||||||
|
|
||||||
|
### D — Einkauf & Beschaffung
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M25 | Einkaufsbelege (Bestellung, Wareneingang, Eingangsrechnung, Lieferanten-Gutschrift) | `BL\Sales\Receipts\SupplierOrders`, `...\SupplierDeliveryLists`, `...\SupplierInvoices`, `...\SupplierCreditVouchers`, `UI\Purchasing` | Einkaufsseitige Belegkette gegenüber Lieferanten. | AP4 |
|
||||||
|
| M26 | EDI-Anbindung Distributoren | `BL\EDI`, `UI\Purchasing\EDIManagement`, `docs\reference\edi\*` | Elektronischer Belegaustausch mit Distributoren (ALSO, Alltron, Komsa, EGIS, Concerto, OpenTrans). | AP4 |
|
||||||
|
| M27 | Bestellvorschläge | `UI\Purchasing\OrderSuggestionList` | Ermittlung von Bestellvorschlägen aus Bedarf/Beständen. | AP4 |
|
||||||
|
| M28 | Reisekosten | `UI\Purchasing\TravelExpense` | Erfassung und Abrechnung von Reisekosten. | AP4 |
|
||||||
|
| M29 | Distributoren-Stammdaten | `BL\Buying` | Stammdaten der Großhändler/Distributoren. | AP4 |
|
||||||
|
| M30 | ITscope-Marktplatz | `src\apis\Centron.APIs.ITscopeDataAccess` | Produkt-/Preis-/Bestellzugriff auf den ITscope-Marktplatz. | AP4 |
|
||||||
|
| M31 | COP-Produktdatendienst | `src\apis\Centron.APIs.CopDataAccess` | SOAP-Zugriff auf Produkt-, Preis- und Lieferantendaten (COP). | AP4 |
|
||||||
|
| M32 | EGIS-Distributionsdienst | `src\apis\Centron.APIs.EgisDataAccess` | Artikelsuche, Preise/Verfügbarkeiten, Produktspezifikationen (EGIS). | AP4 |
|
||||||
|
| M33 | Icecat-Produktkatalog | `src\apis\Centron.APIs.IcecatDataAccess` | Anreicherung von Artikeln mit Icecat-Katalogdaten. | AP4 |
|
||||||
|
| M34 | TradePool-Import | `BL\TradePool` | XML-Import von Handels-/Marktplatzdaten. | AP4 |
|
||||||
|
|
||||||
|
### E — Artikel, Lager & Logistik
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M35 | Artikelstamm | `UI\Warehousing\ArticleManagement`, `UI\Warehousing\SearchArticle` | Verwaltung des Artikelstamms inkl. Suche. | AP5 |
|
||||||
|
| M36 | Artikelimport | `UI\Warehousing\ArticleImport` | Dateibasierter Import von Artikeldaten. | AP5 |
|
||||||
|
| M37 | Artikel-Nebenstammdaten (Einheiten, Warengruppen, Kontenrahmen) | `UI\Warehousing\ArticleUnitManagement`, `...\MaterialGroupManagement`, `...\AccountSystems` | Pflege von Einheiten, Warengruppen und Kontenzuordnungen. | AP5 |
|
||||||
|
| M38 | Lager & Inventur | `BL\Storage`, `UI\Warehousing\Inventory` | Lagerverwaltung und Inventurdurchführung. | AP5 |
|
||||||
|
| M39 | Kommissionierung | `UI\Warehousing\Commissioning`, `UI\Warehousing\Commissions` | Kommissionieren von Aufträgen. | AP5 |
|
||||||
|
| M40 | Barcode-Verwaltung | `UI\Warehousing\BarcodeManagement` | Barcodes für Artikel/Lagerprozesse. | AP5 |
|
||||||
|
| M41 | Versand/Logistik | `UI\Modules\Logistic`, `BL\Logistics` | Versandabwicklung und Versandarten-Konfiguration. | AP5 |
|
||||||
|
| M42 | GLS-Versand | `src\apis\Centron.Api.Gls` | Paketerstellung und Labeldruck über GLS. | AP5 |
|
||||||
|
| M43 | Shipcloud-Versand | `src\apis\Centron.Api.Shipcloud` | Multi-Carrier-Versand über Shipcloud inkl. Zolldaten. | AP5 |
|
||||||
|
| M44 | Lieferantensuche | `UI\Warehousing\SupplierSearch`, `BL\BusinessPartner` | Suche von Lieferanten zu Artikeln. | AP5 |
|
||||||
|
|
||||||
|
### F — Helpdesk & Service
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M45 | Helpdesk/Ticketsystem (Kern) | `UI\Helpdesk` (TicketList, TicketDetails, Dashboard), `BL\Modules`-übergreifende Helpdesk-BLs, `CentronRights.md` | Zentrales Ticketsystem für Servicefälle inkl. Rechten, Timern, Dashboard. | AP6 |
|
||||||
|
| M46 | Checklisten | `BL\CheckListArea`, `UI\Helpdesk\CentronChecklist` | Checklisten mit Positionen und Änderungsprotokoll. | AP6 |
|
||||||
|
| M47 | Erwartete Ereignisse | `BL\ExpectedEvents`, `UI\Helpdesk\ExpectedEvents`, `...\ExpectedEventsReporting` | Überwachung erwarteter Ereignisse/Fälligkeiten mit Auswertung. | AP6 |
|
||||||
|
| M48 | Aufgabenverwaltung (TaskManager) | `BL\TaskManager`, `UI\Helpdesk\TaskManagement`, `UI\Administration\TaskManagmentSettings` | Aufgaben mit konfigurierbaren Aktions-Handlern. | AP6 |
|
||||||
|
| M49 | Ticket-Projekte | `BL\TicketProjects` | Bündelung von Tickets zu Projekten inkl. Abhängigkeiten. | AP6 |
|
||||||
|
| M50 | Ticket-Prozessvorlagen / Ticket-Muster | `UI\Helpdesk\TicketProcessTemplates`, Controller `TicketPatternsController.cs` | Vorlagen für wiederkehrende Ticketprozesse. | AP6 |
|
||||||
|
| M51 | SelfCare-Formulare | `BL\SelfCare`, `UI\Helpdesk\SendSelfCareForm`, Controller `SelfCareFormsController.cs` | Self-Service-Formulare für Endkunden. | AP6 |
|
||||||
|
| M52 | Externes Helpdesk | `BL\ExternalHelpdesk` | Anbindung externer Ticketsysteme. | AP6 |
|
||||||
|
| M53 | Zeitregeln/Fristen | `BL\Time` | Konfigurierbare Zeitregeln (z. B. für Fristen und Jobs). | AP6 |
|
||||||
|
| M54 | Eskalationen | `UI\Administration\EscalationsSettings`, `src\webservice\Centron.Host` (Eskalationsdienst) | Eskalationsregeln für Tickets/Fristen. | AP6 |
|
||||||
|
| M55 | Umfragen | `UI\Modules\Survey` | Erstellen, Ausführen und Auswerten von Umfragen. | AP6 |
|
||||||
|
| M56 | RMA-Abwicklung | `UI\Modules\Rma`, `BL\CustomerArea\RmaBL.cs` | Rücksendeabwicklung an Lieferanten und Rückgabe an Kunden. | AP6 |
|
||||||
|
| M57 | IT-Planner | `BL\ItPlanner` | Kategorien virtueller Objekte für IT-Planungs-/Checklistenstruktur. | AP6 |
|
||||||
|
| M58 | DocuBoard / Asset-Management-Board | `BL\DocuBoard` | Board mit Partner-, Artikelzuordnungs- und AD-Benutzerausschlussverwaltung. | AP6 |
|
||||||
|
|
||||||
|
### G — CRM & Stammdaten
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M59 | Adress-/Kundenstamm | `BL\Accounts`, `BL\CustomerArea`, `BL\Sales\Customers` | Zentraler Kunden-/Adressstamm mit Ansprechpartnern, Branchen, Interessen. | AP8 |
|
||||||
|
| M60 | Kontaktaktivitäten / CRM | `UI\Finances\Crm`, `BL\CustomerArea` (Aktivitäten) | Dokumentation von Kundenkontakten und Aktivitäten. | AP8 |
|
||||||
|
| M61 | Kampagnen | `UI\Finances\Campaigns`, `BL\Accounts\Campaigns`, `BL\Sales\Marketing` | Marketing-Kampagnen mit Kundenzuordnung. | AP8 |
|
||||||
|
| M62 | Geräte/Assets beim Kunden | `BL\Devices`, `BL\Sales\CustomerAssets`, `BL\BusinessPartner\SupplierAssetBL.cs` | Verwaltung von Kundengeräten/Assets (inkl. getrennter Druckerstammblätter — Konsolidierungskandidat). | AP8 |
|
||||||
|
| M63 | Projekte | `BL\Projects`, `UI\Modules\ProjectManagement`, `UI\Finances\Projects` | Projektstammdaten und Projektsichten. | AP8 |
|
||||||
|
| M64 | Projektpreis-/Sonderpreisimport & Custom Gateways | `UI\Modules\ProjectPriceImport`, `BL\Gateway`, `UI\Sales\SpecialArticleToContractImport` | Import kundenspezifischer Preis-/Vertragsdaten über konfigurierbare Gateways. | AP11 |
|
||||||
|
| M65 | Länder & Bundesländer | `BL\CountryArea`, `UI\Administration\CountryManagement` | Stammdaten Länder/Bundesländer. | AP8 |
|
||||||
|
| M66 | Tags/Schlagwörter | `BL\Tags` | Schlagwortverwaltung und Zuordnung zu Objekten. | AP8 |
|
||||||
|
| M67 | Textbausteine | `BL\TextModuleArea`, `UI\Administration\TextBlockManagement` | Textbausteine inkl. Anrede-/Grußformel-Ersetzung. | AP8 |
|
||||||
|
| M68 | Mitarbeiterverwaltung | `BL\EmployeeArea`, `UI\Administration\EmployeeManagement` | Mitarbeiterstamm, App-Benutzer, Abteilungen, Urlaub, RFID, Teams. | AP8 |
|
||||||
|
| M69 | Stammdatenlisten | `UI\Finances\MasterDataLists`, Controller `MasterDataListsController.cs` | Pflege einfacher Auswahl-/Stammdatenlisten. | AP8 |
|
||||||
|
| M70 | Massenupdates | `BL\MassUpdate`, `UI\Modules\Massenupdates` | Massenänderungen über konfigurierbare Update-Jobs. | AP8 |
|
||||||
|
| M71 | Kundenindividuelle Zusatztabellen | `BL\Customizations` | Custom Tables mit Variablenersetzung. | AP8 |
|
||||||
|
| M72 | Externe Objektreferenzen | `BL\ObjectExternalReferences`, Controller `ObjectExternalReferencesController.cs` | Verknüpfung von c-entron-Objekten mit Fremdsystem-IDs. | AP8 |
|
||||||
|
| M73 | Produktmatrix | `BL\ProductMatrix`, `UI\Sales\ProductMatrix` | Produktkategorien-Matrix je Kunde. | AP8 |
|
||||||
|
| M74 | DSGVO | `UI\Administration\DSGVO` | Datenschutzfunktionen (Auskunft/Löschung). | AP7 |
|
||||||
|
|
||||||
|
### H — Kommunikation & Zusammenarbeit
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M75 | E-Mail-Versand/-Zugriff | `BL\Mail` (SMTP, Exchange/EWS, MS Graph), `UI\Administration\MailTemplates`, `docs\guides\development\create-mail-templates.md` | Mailversand über mehrere Protokolle inkl. Vorlagen und Signaturen. | AP9 |
|
||||||
|
| M76 | MailScanner | `BL\MailScanner` | Automatisches Auslesen von Postfächern zur Weiterverarbeitung (Ticket-/Belegerzeugung). | AP9 |
|
||||||
|
| M77 | Kalender & Exchange-Sync | `UI\Modules\Calendar`, `BL\Calendar`, `UI\Administration\MailAndCalender`, `docs\features\exchange-sync-bugprotokoll.md` | Terminverwaltung und Synchronisation mit Exchange. | AP9 |
|
||||||
|
| M78 | Terminanfragen | `BL\AppointmentRequests` | Terminanfragen mit Zu-/Absagen. | AP9 |
|
||||||
|
| M79 | Outlook-Add-In | `src\nexus\CentronNexus.OutlookAddIn`, `BL\Outlook` | Kontextanzeige von Kunde/Belegen/Aktivitäten zur aktuellen Mail. | AP9 |
|
||||||
|
| M80 | Telefonie (TAPI) | `BL\Tapi`, `docs\reference\architecture\tapi.md`, `UI\Administration\PhoneSettings` | Anruferfassung und -auswertung über TAPI. | AP9 |
|
||||||
|
| M81 | Interner Chat | `BL\Chats` | Interner Chat mit Objektbezug. | AP9 |
|
||||||
|
| M82 | Benachrichtigungen | `BL\Notifications`, `BL\NexusNotifications` | Systemweite und Realtime-Benachrichtigungen (SignalR). | AP9 |
|
||||||
|
| M83 | Soziale Netzwerke | `BL\SocialMedia` | Zuordnung sozialer Netzwerke zu Personen. | AP9 |
|
||||||
|
| M84 | Videoportal | `BL\VideoPortal` | Zuordnung von Videoinhalten zu Objekten. | AP9 |
|
||||||
|
| M85 | Signierte Web-Links | `BL\WebLinks` | Signierte Links mit hinterlegten Aktionen. | AP9 |
|
||||||
|
| M86 | Kurz-URLs | `BL\Urls` | Einfache Objekt-/Kurz-URLs. | AP9 |
|
||||||
|
|
||||||
|
### I — Auswertung & persönlicher Arbeitsbereich
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M87 | Statistiken | `UI\Modules\Statistics`, `BL\Statistics` | Umsatz-/Kennzahlenauswertungen. | AP12 |
|
||||||
|
| M88 | Reports/Formulardruck | `BL\ReportEngine` (FastReport), `BL\Reporting`, `UI\Modules\Reports`, `UI\Administration\ReportServer` | Formular-/Reporterzeugung inkl. PDF und ReportServer. | AP11 |
|
||||||
|
| M89 | Dashboard | `UI\Modules\Dashboard` | Übergreifendes Kennzahlen-Dashboard. | AP12 |
|
||||||
|
| M90 | Volltextsuche | `BL\IndexSearch` (Lucene) | Volltextindizierung und -suche über Geschäftsobjekte. | AP11 |
|
||||||
|
| M91 | KI-Funktionen | `UI\Modules\ArtificialIntelligence`, `BL\ArtificialIntelligence`, Controller `ArtificialIntelligenceChatsController.cs` | KI-gestützte Chats/Assistenz. | AP12 |
|
||||||
|
| M92 | MyCentron/MyDay/ToDo/QuickNotes | `BL\MyCentron`, `BL\MyDay`, `BL\ToDoArea`, `UI\Modules\MyCentron` | Persönlicher Arbeitsbereich: Dashboard, Tagesübersicht, To-dos, Notizen. | AP12 |
|
||||||
|
|
||||||
|
### J — Sicherheit & Administration
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M93 | Benutzerrechte | `CentronRights.md`, `docs\guides\development\check-userrights.md`, `UI\Administration\RightsManagement`, UserRightsConst | Feingranulare Rechteverwaltung inkl. einschränkender Rechte (nur eigene / eigene Filiale). | AP7 |
|
||||||
|
| M94 | Authentifizierung & Login | `docs\reference\security\anmelden-mit-microsoft-technische-anleitung.md`, `src\webservice\Centron.Controllers\Controllers\...\JwtAuthController.cs`, `AuthConfigurationController.cs`, AccessTokens | Anmeldung am Client/Webservice inkl. „Anmelden mit Microsoft", JWT, Access-Tokens. | AP7 |
|
||||||
|
| M95 | Zwei-Faktor-Authentifizierung | `BL\TwoFactorAuthenticator`, Controller `TwoFactorAuthController.cs` | TOTP-Registrierung und -Prüfung. | AP7 |
|
||||||
|
| M96 | Passwortmanager | `BL\PasswordManagementArea`, `BL\PasswordManager`, `UI\Modules\PasswordManager` | Verwaltung von Kundenpasswörtern inkl. Zugriffs-/Änderungsprotokoll. | AP7 |
|
||||||
|
| M97 | Lizenzierung | `docs\reference\security\licensing-system.md`, `LicenseGuids.cs`, `ApplicationKind.cs`, Controller `LicenseController.cs` | GUID-basierte Lizenzen mit Anzahl/Gültigkeit je Feature und Applikation. | AP7 |
|
||||||
|
| M98 | Mandanten & Filialen | `UI\Administration\MandatorManagement`, Branch-Logik | Mandanten- und Filialverwaltung. | AP7 |
|
||||||
|
| M99 | PDF-Signatur | `BL\Security\PdfSigningBL.cs`, `UI\Administration\PdfSigning` | Digitale Signatur von PDF-Dokumenten mit Zertifikaten. | AP7 |
|
||||||
|
| M100 | Einstellungsverwaltung | `docs\guides\development\settings-management.md`, `UI\Administration\Settings` | Zentrale, hierarchische Verwaltung von System-/Benutzereinstellungen. | AP7 |
|
||||||
|
| M101 | Änderungsverfolgung/Audit | `BL\ChangeTracking` | Historisierung von Importen und Datenänderungen. | AP7 |
|
||||||
|
| M102 | Telemetrie | `BL\Telemetry` | Erfassung von Nutzungsdaten. | AP7 |
|
||||||
|
| M103 | Log-Viewer/Protokollierung | `UI\Administration\LogViewer` | Einsehen von Anwendungsprotokollen. | AP7 |
|
||||||
|
| M104 | Admin-Werkzeuge (Cache, Profiling, SqlManagers, CentronConfigDb, Connections) | `UI\Administration\Cache`, `...\Profiling`, `...\SqlManagers`, `...\CentronConfigDb`, `...\Connections` | Technische Administrationswerkzeuge des Clients. | AP7 |
|
||||||
|
| M105 | Modul-Registry & Favoriten | `BL\Modules` | Registrierung der Anwendungsmodule, Kategorien, Favoriten. | AP7 |
|
||||||
|
| M106 | Systemtabelle/ID-Vergabe | `BL\SystemArea\SystemTableI3DBL.cs` | Zentrale Systemtabelle mit ID-Vergabe (I3D). | AP11 |
|
||||||
|
|
||||||
|
### K — Web-Plattform & Schnittstellen
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M107 | Webservice-Server | `src\webservice\Centron.Host`, `src\webservice\Centron.Controllers`, `BL\WebServices` (Fassade, 464 Dateien), `docs\guides\services\add-webservice-methods.md` | REST-/Webservice-Schicht über der Geschäftslogik inkl. Hintergrunddienste. | AP10 |
|
||||||
|
| M108 | Webservice-Client-Kern | `src\webservice\Centron.WebServices.Core` | Transport, Serialisierung, JWT-Auth, HTTP-Clients für Client-Zugriffe. | AP10 |
|
||||||
|
| M109 | ConnectionManager | `src\webservice\c-entron.misc.ConnectionManager` | Admin-Tool für Verbindungen, Lizenzen, Hardware-ID, 2FA-Test. | AP10 |
|
||||||
|
| M110 | Nexus ServiceBoard | `src\nexus\CentronNexus\ServiceBoard`, `BL\NexusTicketViews`, `BL\CentronNexus` | Web-Ticket-Arbeitsplatz (Kanban, Scheduler, MyDay, Statistiken). | AP10 |
|
||||||
|
| M111 | Nexus WebCart/Kundenportal | `src\nexus\CentronNexus\WebCart`, `README.md` (WebCart), `UI\Administration\WebCart` | Webshop für Endkunden auf Basis von Web-Accounts und Sonderpreisen. | AP10 |
|
||||||
|
| M112 | Nexus WebOffer/Belegansicht | `src\nexus\CentronNexus\WebOffer` | Web-Ansicht von Belegen mit PDF-Vorschau. | AP10 |
|
||||||
|
| M113 | Nexus Office & DocumentSigning | `src\nexus\CentronNexus\Office`, `...\DocumentSigning` | Geteilte Dokumente, Freigaben und digitale Unterschrift. | AP10 |
|
||||||
|
| M114 | Nexus ProductionOrderManagement | `src\nexus\CentronNexus\ProductionOrderManagement` | Web-Verwaltung von Fertigungsaufträgen. | AP10 |
|
||||||
|
| M115 | Nexus Management/Settings/Shared | `src\nexus\CentronNexus\Management`, `...\Settings`, `...\Shared` | Web-Administration (TaskManagement, TicketPatterns, WebAccounts), Auth, Layout. | AP10 |
|
||||||
|
| M116 | Mobile-App-Backend | `BL\Mobile` | Datenversorgung der mobilen App. | AP10 |
|
||||||
|
| M117 | WebSuite (Alt-Web) | `BL\WebSuite` | Konfiguration der älteren Web-Suite. | AP10 |
|
||||||
|
| M118 | Webservice-Versionsabgleich | `BL\WebVersion` | Versionsermittlung/-abgleich zwischen Client und Webservice. | AP10 |
|
||||||
|
| M119 | RMM-/DocBee-Integrationen | `BL\Integrations`, Controller `RmmController.cs`, `DocBeeConnectorConfigurationController.cs`, `RmmConnectionSettingsController.cs`, `UI\DataExchange` (RMM) | Anbindung von RMM-Systemen und DocBee. | AP12 |
|
||||||
|
| M120 | RiverDivo-Schnittstelle | `BL\RiverDivo` | Webservice-Schnittstelle zum Riverbird/Divo-System. | AP12 |
|
||||||
|
| M121 | cPra-Anbindung | `BL\CPra` | Login/Konfiguration für das externe System „cPra". | AP12 |
|
||||||
|
| M122 | docuFORM-Anbindung | `Centron.Api.docuFORM`, Controller `DocuFormApiSettingsController.cs`, `UI\DataExchange` (DocSync) | REST-Anbindung docuFORM (OAuth, Kundenanlage, Deployments). | AP12 |
|
||||||
|
| M123 | Externe Tools | `BL\ExternalToolsBL`, `UI\Modules\ExternalTool`, `UI\Administration\ExternalTools` | Konfigurierbarer Aufruf externer Programme mit Variablenersetzung. | AP12 |
|
||||||
|
| M124 | Import-/Export-Framework (DataExchange) | `UI\Modules\DataExchange` (Assistenten, Konnektoren) | Generische Import-/Export-Assistenten und Konnektoren. | AP11 |
|
||||||
|
| M125 | Prozesse (generisch) | `BL\Processes` | Generische Vorgangs-/Prozessobjekte an beliebigen Objekten. | AP11 |
|
||||||
|
| M126 | Transaktionen | `BL\Transactions` | Verwaltung/Abfrage von Transaktionen. | AP11 |
|
||||||
|
|
||||||
|
### L — Produktion & Sonstige Fachmodule
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M127 | Produktion/Fertigungsaufträge | `UI\Modules\Production` (ProductionOrder, MachineManagement, Settings), `BL\Production` | Fertigungsaufträge und Maschinenverwaltung. | AP12 |
|
||||||
|
| M128 | Produkt-Lifecycle-Management | `UI\Modules\PLM`, `UI\Finances\ProductLifecycleManagement` | Produktfamilien/-gruppen mit Lebenszyklusinformationen. | AP12 |
|
||||||
|
| M129 | Qualitätsmanagement | `UI\Modules\QM` | QM-Einstellungen (Beleg-/Asset-Gründe). | AP12 |
|
||||||
|
| M130 | Dokumentation an Objekten | `BL\DocumentationArea`, `BL\Sales\DocumentationWizardArea` | Dokumentationseinträge zu Objekten inkl. Rechteprüfung. | AP12 |
|
||||||
|
|
||||||
|
### M — Plattform, Infrastruktur & Betrieb
|
||||||
|
|
||||||
|
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M131 | WPF-Client-Rahmen | `src\centron\Centron.WPF.UI` (Start, Layout, Dialogs, Wizards), `src\centron\Centron.WPF.UI.Extension`, `src\shared\Centron.Controls` | Anwendungsrahmen: Start/Login, Modul-Hosting, MVVM, Steuerelemente. | AP11 |
|
||||||
|
| M132 | Lokalisierung | `docs\guides\ui\localization.md`, `LocalizedStrings.resx`/`.en.resx` | Zweisprachigkeit Deutsch (Standard)/Englisch. | AP11 |
|
||||||
|
| M133 | Datenzugriff & O/R-Mapping | `src\backend\Centron.DAO`, `src\backend\Centron.Entities`, `BL\Start` | NHibernate-basierter Datenzugriff, Entities, Mapping. | AP11 |
|
||||||
|
| M134 | Datenbankschema & Skript-System | `SSMS_DB_SCHEMA.sql`, `docs\guides\database\create-scripts.md`, `docs\reference\database\script-rules.md`, `scripts\` | 1.535 Tabellen, Views, Constraints; versionierte Migrationsskripte. | AP11 |
|
||||||
|
| M135 | Hintergrunddienste | `src\webservice\Centron.Host` (HostedServices), `docs\Background Service\DataQualityService.md` | Geplante Dienste: EDI-Download, Exchange-Sync, Indexierung, Eskalation, Preisupdates, Datenqualität. | AP10 |
|
||||||
|
| M136 | Deployment/Installer | `deployment\` (WiX), `azure\`, `version.json` | MSI-Installer für Client und Webservice, Build-Pipelines. | AP11 |
|
||||||
|
| M137 | Docker-/Linux-Betrieb | `docker\`, `docs\guides\services\web-service-on-linux.md` | Containerisierter Betrieb des Webservice. | AP11 |
|
||||||
|
| M138 | Teststrategie | `tests\` (EndToEnd, Integration, Playwright), `docs\guides\development\end-to-end-testing.md` | Automatisierte Regressions-/E2E-Tests. | AP11 |
|
||||||
|
| M139 | Gemeinsame Basisbibliothek | `src\shared\Centron.Core`, `src\backend\Centron.Common`, `src\backend\Centron.Interfaces`, `src\backend\Centron.Gateway` | Technische Querschnittsfunktionen (Guard, TOTP, Result-Pattern, DTOs). | AP11 |
|
||||||
|
|
||||||
|
**Inventarstand:** 139 Module/Komponenten. Das Inventar darf ergänzt, aber nicht gekürzt werden.
|
||||||
|
|
||||||
|
## Arbeitspakete der Analyse (Schritt 0b/0c)
|
||||||
|
|
||||||
|
| AP | Themenfeld | ID-Bereich (je Ebene) | Risikofokus |
|
||||||
|
|---|---|---|---|
|
||||||
|
| AP1 | Belegwesen Verkauf | 100–299 | Fakturierung ✔ |
|
||||||
|
| AP2 | Verträge & wiederkehrende Abrechnung | 300–499 | Fakturierung ✔ |
|
||||||
|
| AP3 | Finanzen & Buchhaltung | 500–699 | Abrechnung/Zahlung ✔ |
|
||||||
|
| AP4 | Einkauf & Beschaffung | 700–899 | — |
|
||||||
|
| AP5 | Artikel/Lager/Logistik | 900–1099 | — |
|
||||||
|
| AP6 | Helpdesk & Service | 1100–1299 | Berechtigungen (Ticketrechte) ✔ |
|
||||||
|
| AP7 | Sicherheit & Administration | 1300–1499 | Sicherheit/Berechtigungen ✔ |
|
||||||
|
| AP8 | CRM & Stammdaten | 1500–1699 | — |
|
||||||
|
| AP9 | Kommunikation | 1700–1899 | — |
|
||||||
|
| AP10 | Web-Plattform & Webservice | 1900–2099 | Auth am Webservice ✔ |
|
||||||
|
| AP11 | Plattform & Infrastruktur | 2100–2299 | — |
|
||||||
|
| AP12 | Übrige Fachmodule & Integrationen | 2300–2499 | — |
|
||||||
|
|
||||||
|
Mindestabdeckung (Schritt 0b): Jedes der 139 Module erhält mindestens eine Anforderung oder wird mit Begründung als `nicht analysiert` geführt. Vertiefung (Schritt 0c) erfolgt in AP1–AP3, AP6, AP7 und AP10 (Sicherheits-, Abrechnungs- und Berechtigungslogik).
|
||||||
|
|
||||||
|
*Die Abschnitte Abdeckungstabelle, Konsistenzcheck und Selbstbewertung werden nach Abschluss der Analyse ergänzt (siehe unten).*
|
||||||
+89
@@ -0,0 +1,89 @@
|
|||||||
|
# Messprotokoll – Versuch 01 (V1b Baseline mit werkzeugeigenen Agenten) – Prompt-Version 02
|
||||||
|
|
||||||
|
> ## ⚠ FEHLMESSUNG – nicht für Auswertungen verwenden
|
||||||
|
>
|
||||||
|
> Der Lauf brach mit `is_error: true` und HTTP 429 ab: „You've hit your session limit ·
|
||||||
|
> resets 10:50pm (Europe/Berlin)". Erzeugt wurden **1 von sieben** geforderten Ergebnisdateien; der Lauf brach mitten in der Bearbeitung ab. Verbraucht wurden
|
||||||
|
> bis zum Abbruch **77.815.316 Tokens**.
|
||||||
|
|
||||||
|
## Lauf
|
||||||
|
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
|
||||||
|
- **Prompt-Version:** 02
|
||||||
|
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
|
||||||
|
- **Startzeit:** 2026-08-26T20:00:11.2795634+02:00
|
||||||
|
- **Endzeit:** 2026-08-26T20:30:04.2067421+02:00
|
||||||
|
- **Dauer gesamt:** 00:07:4x — bis zum Kontingentabbruch
|
||||||
|
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||||
|
- **Codebasis-Commit:** `f349d189c735a87f5829bc93f67991320061a2c0` (dirty: nein)
|
||||||
|
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; enthält `SSMS_DB_SCHEMA.sql`
|
||||||
|
|
||||||
|
## Werkzeugkonfiguration
|
||||||
|
- **Skill-Version:** 7.0.0
|
||||||
|
- **Claude-Code-Version:** 2.1.246
|
||||||
|
- **Modell (angefordert):** `claude-fable-5`
|
||||||
|
- **Modelle (tatsächlich eingesetzt):** `claude-fable-5` 77.433.773 (99.51 %), `claude-opus-5[1m]` 374.562 (0.48 %), `claude-haiku-4-5-20251001` 6.981 (0.01 %)
|
||||||
|
- **Kontrolle Modell:** **verletzt** – nicht angefordertes Modell `claude-opus-5[1m]` mit 374.562 Tokens (0.48 %)
|
||||||
|
- **Effort:** `high`
|
||||||
|
- **Agentenmodus:** `builtin` (V1b)
|
||||||
|
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
|
||||||
|
- **Hintergrund-Wartezeit:** `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`
|
||||||
|
- **Parallele Läufe:** **ja** – alle vier Läufe der Welle liefen gleichzeitig
|
||||||
|
- **Subagenten:** 13 gestartet (1 × `Explore`, 12 × `general-purpose`), `max_depth` = 1
|
||||||
|
|
||||||
|
## Verbrauch
|
||||||
|
|
||||||
|
| Messgröße | `claude-fable-5` | `claude-opus-5[1m]` | `claude-haiku-4-5-20251001` | Summe |
|
||||||
|
|---|---:|---:|---:|---:|
|
||||||
|
| Input-Tokens | 1.426 | 20 | 6.961 | 8.407 |
|
||||||
|
| Output-Tokens | 1.037.386 | 15.803 | 20 | 1.053.209 |
|
||||||
|
| Cache-Write-Tokens | 4.150.505 | 52.132 | 0 | 4.202.637 |
|
||||||
|
| Cache-Read-Tokens | 72.244.456 | 306.607 | 0 | 72.551.063 |
|
||||||
|
| **Tokens gesamt** | **77.433.773** | **374.562** | **6.981** | **77.815.316** |
|
||||||
|
|
||||||
|
|
||||||
|
**Tokens gesamt: 77.815.316** — real angefallen und deshalb ausgewiesen, obwohl der Lauf ungültig ist.
|
||||||
|
|
||||||
|
## Gefundene Anforderungen
|
||||||
|
|
||||||
|
Der Lauf brach vor Abschluss ab. Die vorhandenen Dateien sind ein **Teilbestand** und mit vollständigen Läufen nicht vergleichbar; eine Auswertung unterbleibt deshalb.
|
||||||
|
|
||||||
|
## Ergebnis
|
||||||
|
- **Gültigkeit:** **Fehlmessung** – API-Abbruch (HTTP 429, Session-Kontingent); nur 1 von sieben Artefakten erzeugt
|
||||||
|
- **Status:** `is_error` = true, `terminal_reason` = `api_error`, `api_error_status` = 429
|
||||||
|
- **Session-ID:** `d77bf9b3-7a4d-4620-861f-28861a420996`
|
||||||
|
- **Turns:** 44
|
||||||
|
- **Permission-Denials:** 14
|
||||||
|
- **Erzeugte Dateien:** 1 von sieben geforderten Artefakten:
|
||||||
|
|
||||||
|
| Datei | Größe |
|
||||||
|
|---|---:|
|
||||||
|
| `Analysebericht.md` | 26.963 B |
|
||||||
|
|
||||||
|
Es fehlen: `StRS.md`, `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`
|
||||||
|
- **Root unverändert:** ja
|
||||||
|
- **Abschlusstext des Agenten:** „You've hit your session limit · resets 10:50pm (Europe/Berlin)"
|
||||||
|
|
||||||
|
## Anmerkungen/Auffälligkeiten
|
||||||
|
|
||||||
|
**1. Kontingentabbruch, nicht Laufversagen.** Vier Läufe wurden am 26.08. um 19:59 gleichzeitig
|
||||||
|
gestartet; alle vier liefen in dieselbe Grenze. Zusammen hatten sie zu diesem Zeitpunkt
|
||||||
|
297,4 Mio. Tokens verbraucht, davon allein 204,4 Mio. im Lauf `45dd`. Die Parallelität von vier
|
||||||
|
Läufen – darunter einer mit extremer Delegation – hat das Kontingent gerissen.
|
||||||
|
|
||||||
|
**2. Konsequenz für den Versuchsaufbau:** Die verbleibenden Zellen werden **seriell** gefahren.
|
||||||
|
Der erste serielle Lauf danach (`opus-5/solo/high`, `2269`) lief mit 38,1 Mio. Tokens sauber durch.
|
||||||
|
|
||||||
|
**3. Die Modellverletzung aus Iteration 1 ist reproduziert.** `modelUsage` weist neben
|
||||||
|
`claude-fable-5` auch **`claude-opus-5[1m]`** aus. Derselbe Befund war in Iteration 1 unter
|
||||||
|
Prompt-Version 01 und ohne DB-Schema aufgetreten; damit ist aus einem Einzelfall ein belegtes
|
||||||
|
Muster geworden: **Fable wird bei Delegation nicht an die Subagenten durchgereicht**, Sonnet und
|
||||||
|
Opus dagegen schon. Ursache ist die Sitzungsvorgabe `model: opus[1m]` in
|
||||||
|
`~/.claude/settings.json`; `--safe-mode` verhindert das nicht.
|
||||||
|
|
||||||
|
Die Gegenprobe im selben Block bestätigt die Abgrenzung: Der Lauf `77a1` mit Fable im Modus
|
||||||
|
`solo` weist ausschließlich `claude-fable-5` plus Haiku aus. **Nicht das Modell ist das Problem,
|
||||||
|
sondern Fable in Kombination mit Delegation.**
|
||||||
|
|
||||||
|
**4. Die Zelle bleibt unbelegt.** Ein gültiger Lauf für `fable-5/builtin/high` steht aus. Er wäre
|
||||||
|
allerdings von vornherein als bedingungsverletzt zu führen, solange die Subagenten auf einem
|
||||||
|
nicht angeforderten Modell laufen.
|
||||||
+1
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
|||||||
|
|
||||||
+178
@@ -0,0 +1,178 @@
|
|||||||
|
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
|
||||||
|
|
||||||
|
## Metadaten
|
||||||
|
- **Versuch:** V1 Baseline (Prompt-only)
|
||||||
|
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
|
||||||
|
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||||
|
- **Zeitstempel:** 2026-08-26
|
||||||
|
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
|
||||||
|
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||||
|
|
||||||
|
| Änderung | Auslösender Befund |
|
||||||
|
|---|---|
|
||||||
|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
|
||||||
|
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
|
||||||
|
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
|
||||||
|
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
|
||||||
|
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
|
||||||
|
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
|
||||||
|
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
|
||||||
|
|
||||||
|
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
|
||||||
|
|
||||||
|
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||||
|
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||||
|
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Prompt
|
||||||
|
|
||||||
|
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||||
|
|
||||||
|
### Auftrag
|
||||||
|
|
||||||
|
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||||
|
|
||||||
|
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||||
|
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||||
|
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||||
|
|
||||||
|
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||||
|
|
||||||
|
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||||
|
|
||||||
|
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
**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. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
|
||||||
|
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||||
|
|
||||||
|
### Formatvorgabe pro Anforderung
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||||
|
Titel: <kurzer Titel>
|
||||||
|
Ebene: <StRS | SyRS | SwRS>
|
||||||
|
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||||
|
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)
|
||||||
|
|
||||||
|
```
|
||||||
|
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)
|
||||||
|
```
|
||||||
|
|
||||||
|
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?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||||
|
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien, das Ausführen von
|
||||||
|
Kommandozeilenbefehlen im Arbeitsverzeichnis sowie die werkzeugeigenen Subagenten.
|
||||||
|
Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
|
||||||
|
Werkzeugserver.
|
||||||
|
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||||
|
Werkzeuge zu ersetzen.
|
||||||
|
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||||
|
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||||
|
`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-fable-5\builtin\high\02_Lauf_2026-08-26_195958_v7.0.0-d694\Ergebnisse\`.
|
||||||
|
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-26T20:30:04.2067421+02:00
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-26T20:00:11.2795634+02:00
|
||||||
+615
@@ -0,0 +1,615 @@
|
|||||||
|
# Analysebericht
|
||||||
|
|
||||||
|
**Untersuchungsgegenstand:** c-entron ERP-Suite (Arbeitsverzeichnis `C:\DEV\MasterArbeit\QuellCode\CentronERP`)
|
||||||
|
**Analyseart:** statische Analyse, keine Ausführung. Codebasis wurde ausschließlich gelesen.
|
||||||
|
**Datum:** 2026-08-27
|
||||||
|
|
||||||
|
## Architekturüberblick (Befund aus Schritt 0)
|
||||||
|
|
||||||
|
Die Codebasis umfasst eine Mehrschicht-Anwendung:
|
||||||
|
|
||||||
|
| Schicht | Pfad | Umfang (Dateien) | Technik |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Windows-Client (Fat Client) | `src\centron\Centron.WPF.UI` | ~4.726 .cs + XAML | WPF, DevExpress, Ribbon |
|
||||||
|
| Web-Client „c-entron Nexus" | `src\nexus\CentronNexus` | ~756 (.cs/.razor, 460 .razor) | ASP.NET Core Blazor |
|
||||||
|
| Geschäftslogik | `src\backend\Centron.BL` | ~85 Fachbereiche | C#/.NET |
|
||||||
|
| Datenzugriff | `src\backend\Centron.DAO` | ~1.129 | ADO.NET/SQL |
|
||||||
|
| Entitäten | `src\backend\Centron.Entities` | ~1.183 | POCO/DTO |
|
||||||
|
| Webservice (REST + Legacy) | `src\webservice` | ~2.528 (Core) + Controller | ASP.NET Core, JWT |
|
||||||
|
| Externe API-Adapter | `src\apis`, `Centron.Api.docuFORM` | 9 Projekte | REST-Clients |
|
||||||
|
| Datenbankschema | `SSMS_DB_SCHEMA.sql` | 1.535 `CREATE TABLE` | MSSQL |
|
||||||
|
| Deployment | `docker`, `azure`, `deployment`, `scripts` | — | Docker/Azure DevOps |
|
||||||
|
|
||||||
|
## Schritt 0 — Modulinventar
|
||||||
|
|
||||||
|
Das Inventar ist die Bezugsgröße für die Abdeckungstabelle. Es wurde vor der ersten Anforderung erstellt und wird später ergänzt, aber nicht gekürzt. Gruppierung: A1–A12 = Analyse-Cluster.
|
||||||
|
|
||||||
|
| Nr. | Modul / Komponente | Pfad (Hauptfundort) | Fachliche Aufgabe (ein Satz) | Cluster |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M01 | Rechteverwaltung / UserRights | `src\backend\Centron.BL\Security`, `src\centron\...\Modules\Administration\RightsManagement`, `CentronRights.md` | Definition und Durchsetzung feingranularer Benutzerrechte inkl. einschränkender Rechte (nur eigene, nur eigene Filiale). | A1 |
|
||||||
|
| M02 | Authentifizierung Webservice (JWT) | `src\webservice\Centron.Controllers\JwtAuthController.cs`, `Authorize*Attribute.cs` | Anmeldung und Autorisierung externer Zugriffe über JWT-Token und Rechte-Attribute. | A1 |
|
||||||
|
| M03 | Zwei-Faktor-Authentifizierung | `src\backend\Centron.BL\TwoFactorAuthenticator`, `TwoFactorAuthController.cs` | Zweiter Faktor bei der Anmeldung. | A1 |
|
||||||
|
| M04 | Passwortmanager | `src\centron\...\Modules\PasswordManager`, `Centron.BL\PasswordManagementArea` | Verwaltung von Zugangsdaten (z. B. Kundenpasswörter) im ERP. | A1 |
|
||||||
|
| M05 | DSGVO-Funktionen | `src\centron\...\Modules\Administration\DSGVO` | Datenschutzfunktionen (Anonymisierung/Auskunft) für personenbezogene Daten. | A1 |
|
||||||
|
| M06 | Verträge (Service/Leasing) | `Centron.BL\Finances`, `...\Modules\Finances\Contracts` | Verwaltung wiederkehrend abzurechnender Service-, Wartungs- und Leasingverträge. | A2 |
|
||||||
|
| M07 | Automatisierte Abrechnung | `...\Modules\Finances\AutomatedBilling`, `FlatrateBilling`, `TimerBilling` | Periodische Erzeugung von Abrechnungsbelegen aus Verträgen, Flatrates und Zeitbuchungen. | A2 |
|
||||||
|
| M08 | Mahnwesen | `...\Modules\Finances\Dunning` | Mahnläufe über offene Posten mit Mahnstufen. | A2 |
|
||||||
|
| M09 | Offene Posten (OPOS) / Zahlungen | `...\Modules\Finances\Opos`, `Payments` | Verwaltung offener Posten und Zahlungszuordnung. | A2 |
|
||||||
|
| M10 | Onlinebanking / FinAPI | `...\Modules\OnlineBanking`, `src\apis\Centron.APIs.FinAPI` | Abruf von Kontoumsätzen und Abgleich mit offenen Posten. | A2 |
|
||||||
|
| M11 | Zahler & Kostenstellen | `...\Modules\PayersAndCostCenter` | Abweichende Rechnungsempfänger (Zahler) und Kostenstellenzuordnung. | A2 |
|
||||||
|
| M12 | Buchhaltungsexport (DATEV u. a.) | `...\Modules\DataExchange\BookKeeping`, `DatevOnline2020`, `PaymentTransactions` | Übergabe von Buchungsdaten und Zahlungsverkehr an Finanzbuchhaltungssysteme. | A2 |
|
||||||
|
| M13 | Gerätezähler (Click-Abrechnung) | `...\Modules\Finances\DeviceClickCounter` | Erfassung von Zählerständen (z. B. Druckerklicks) als Abrechnungsgrundlage. | A2 |
|
||||||
|
| M14 | SEPA | `...\Modules\Administration\SepaContract` | SEPA-Mandate/Lastschrift-Grundlagen. | A2 |
|
||||||
|
| M15 | Belegwesen Verkauf (Angebot→Rechnung) | `Centron.BL\Sales` (248 Dateien), `...\Modules\Sales` | Angebots-, Auftrags-, Lieferschein- und Rechnungserstellung mit Belegkette. | A3 |
|
||||||
|
| M16 | Sonderpreise / Preisfindung | `Centron.BL\Sales`, Adressstamm-Sonderpreise | Kunden- bzw. vertragsspezifische Preisfindung. | A3 |
|
||||||
|
| M17 | Produktmatrix | `Centron.BL\ProductMatrix`, `...\Modules\Sales\ProductMatrix` | Matrixbasierte Produkt-/Konditionszuordnung im Vertrieb. | A3 |
|
||||||
|
| M18 | Mailing/Kampagnen Vertrieb | `...\Modules\Sales\Mailing`, `Centron.BL\Mailings` | Serienmails/Kampagnen an Kundenselektionen. | A3 |
|
||||||
|
| M19 | E-Rechnung (XRechnung/ZUGFeRD/ebInterface) | `docs\guides\development\xrechnung.md`, `src\apis\Centron.Api.EbInterface`, `ZugferdImportController.cs` | Erzeugung und Import strukturierter elektronischer Rechnungen. | A3 |
|
||||||
|
| M20 | Belegkonditionen | `...\Modules\Administration\ReceiptConditions` | Konfigurierbare Zu-/Abschlagskonditionen auf Belegen. | A3 |
|
||||||
|
| M21 | Artikelstamm & Lager | `Centron.BL\Warehousing` (40), `...\Modules\Warehousing` | Artikelverwaltung, Einheiten, Materialgruppen, Lagerbestände, Inventur. | A4 |
|
||||||
|
| M22 | Kommissionierung | `...\Modules\Warehousing\Commissioning`, `Commissions` | Zusammenstellung von Lieferungen aus Lagerbeständen. | A4 |
|
||||||
|
| M23 | Barcode | `...\Modules\Warehousing\BarcodeManagement` | Barcodegestützte Lagerprozesse. | A4 |
|
||||||
|
| M24 | Einkauf & Bestellvorschlag | `Centron.BL\Buying`, `Centron.BL\Purchasing`, `...\Modules\Purchasing` | Lieferantenbestellungen inkl. Bestellvorschlagsliste und Wareneingang. | A4 |
|
||||||
|
| M25 | EDI (Lieferanten) | `Centron.BL\EDI` (27), `...\Modules\Purchasing\EDIManagement` | Elektronischer Belegaustausch mit Lieferanten/Distributoren. | A4 |
|
||||||
|
| M26 | Versand / Logistik | `...\Modules\Logistic`, `src\apis\Centron.Api.Gls`, `Centron.Api.Shipcloud` | Versandarten, Paketlabel und Sendungsverfolgung über GLS/Shipcloud. | A4 |
|
||||||
|
| M27 | RMA / Retouren | `...\Modules\Rma`, `Centron.BL` | Abwicklung von Rücksendungen an Kunden (SendBack) und Lieferanten (SendForth). | A4 |
|
||||||
|
| M28 | Produktdaten-Anbindungen (Icecat, ITscope, COP, EGIS) | `src\apis\Centron.APIs.*DataAccess` | Import von Artikelstammdaten und Konditionen externer Kataloge/Distributoren. | A4 |
|
||||||
|
| M29 | TradePool | `Centron.BL\TradePool` | Austausch/Handel von Artikeln über einen Händlerpool. | A4 |
|
||||||
|
| M30 | Helpdesk / Ticketsystem | `Centron.BL\Helpers`, `...\Modules\Helpdesk`, `Centron.BL\ExternalHelpdesk` | Ticketverwaltung mit Kategorien, Status, Zuweisung, Eskalation. | A5 |
|
||||||
|
| M31 | Zeiterfassung auf Tickets | `Centron.BL\Time`, `...\Modules\Helpdesk` (EDIT_TIME-Rechte) | Erfassung und Abrechnung von Arbeitszeiten auf Tickets. | A5 |
|
||||||
|
| M32 | Checklisten | `Centron.BL\CheckListArea`, `...\Modules\Helpdesk\CentronChecklist` | Strukturierte Abarbeitungslisten an Tickets. | A5 |
|
||||||
|
| M33 | Expected Events | `Centron.BL\ExpectedEvents`, `...\Modules\Helpdesk\ExpectedEvents` | Überwachung erwarteter Ereignisse (z. B. Backup-Meldungen) mit Alarmierung. | A5 |
|
||||||
|
| M34 | SelfCare-Formulare | `Centron.BL\SelfCare`, `SelfCareFormsController.cs` | Endkunden-Formulare zur Selbstauskunft/Ticketanlage. | A5 |
|
||||||
|
| M35 | Aufgabenverwaltung (TaskManager) | `Centron.BL\TaskManager`, `...\Modules\Helpdesk\TaskManagement` | Aufgaben mit Fälligkeit und Verantwortlichen, auch ticketbezogen. | A5 |
|
||||||
|
| M36 | Umfragen (Survey) | `...\Modules\Survey` | Erstellung und Auswertung von Kundenumfragen. | A5 |
|
||||||
|
| M37 | Ticket-Projekte | `Centron.BL\TicketProjects` | Bündelung von Tickets zu Projekten. | A5 |
|
||||||
|
| M38 | Adress-/Kundenstamm | `Centron.BL\BusinessPartner`, `CustomerArea`, `Accounts` | Verwaltung von Kunden, Lieferanten, Ansprechpartnern und Web-Accounts. | A6 |
|
||||||
|
| M39 | Mitarbeiterstamm | `Centron.BL\EmployeeArea`, `...\Administration\EmployeeManagement` | Mitarbeiterdaten, Abteilungen, Filialen. | A6 |
|
||||||
|
| M40 | Geräte / Assets / Stammblätter | `Centron.BL\Devices`, `Centron.BL\ItPlanner` | Verwaltung von Kundengeräten (Drucker-Stammblätter, IT-Assets) inkl. Historie. | A6 |
|
||||||
|
| M41 | Länder/Regionen | `Centron.BL\CountryArea` | Länderstammdaten inkl. steuerlicher Zuordnung. | A6 |
|
||||||
|
| M42 | Tags & Custom Properties | `Centron.BL\Tags`, `Centron.BL\Customizations`, `...\Global\CustomProperties` | Freie Verschlagwortung und kundenindividuelle Zusatzfelder. | A6 |
|
||||||
|
| M43 | Objekt-Externreferenzen | `Centron.BL\ObjectExternalReferences` | Verknüpfung von ERP-Objekten mit IDs externer Systeme. | A6 |
|
||||||
|
| M44 | Mail (Versand/Empfang) | `Centron.BL\Mail` (20), `MailScanner` | Mailversand/-empfang, Vorlagen, automatische Zuordnung eingehender Mails. | A7 |
|
||||||
|
| M45 | Mail-Vorlagen | `...\Administration\MailTemplates`, `docs\guides\development\create-mail-templates.md` | Platzhalterbasierte Mailvorlagen für Systemmails. | A7 |
|
||||||
|
| M46 | Kalender / Termine | `Centron.BL\Calendar`, `AppointmentRequests`, `...\Modules\Calendar` | Terminverwaltung inkl. Terminanfragen, Exchange-Sync. | A7 |
|
||||||
|
| M47 | Outlook-/Exchange-Integration | `Centron.BL\Outlook`, `src\nexus\CentronNexus.OutlookAddIn`, `docs\features\exchange-sync-bugprotokoll.md` | Synchronisation von Mails/Terminen mit Outlook/Exchange. | A7 |
|
||||||
|
| M48 | Telefonie (TAPI) | `Centron.BL\Tapi`, `...\MyCentron\Telephony` | Anrufsignalisierung und Wahlhilfe am Arbeitsplatz. | A7 |
|
||||||
|
| M49 | Chats | `Centron.BL\Chats` | Interner Chat. | A7 |
|
||||||
|
| M50 | Benachrichtigungen | `Centron.BL\Notifications`, `NexusNotifications` | Systembenachrichtigungen an Benutzer (Client und Web). | A7 |
|
||||||
|
| M51 | MyCentron / MyDay / ToDo | `Centron.BL\MyCentron`, `MyDay`, `ToDoArea`, `...\Modules\MyCentron` | Persönliche Startseite mit Tagesübersicht, Aufgaben, Wiedervorlagen. | A7 |
|
||||||
|
| M52 | Social Media / VideoPortal | `Centron.BL\SocialMedia`, `VideoPortal` | Anbindung Social-Media-Kanäle und internes Videoportal. | A7 |
|
||||||
|
| M53 | Nexus WebCart (Shop) | `src\nexus\CentronNexus\WebCart` | Webshop für Endkunden auf Basis der Sonderpreise. | A8 |
|
||||||
|
| M54 | Nexus WebOffer | `src\nexus\CentronNexus\WebOffer` | Online-Angebotsansicht/-annahme durch Kunden. | A8 |
|
||||||
|
| M55 | Nexus ServiceBoard | `src\nexus\CentronNexus\ServiceBoard` | Web-Ticketboard für Servicevorgänge. | A8 |
|
||||||
|
| M56 | Nexus DocumentSigning | `src\nexus\CentronNexus\DocumentSigning` | Digitale Unterschrift von Dokumenten (Signaturpad) im Browser. | A8 |
|
||||||
|
| M57 | Nexus Produktionsaufträge | `src\nexus\CentronNexus\ProductionOrderManagement` | Web-Sicht auf Fertigungsaufträge. | A8 |
|
||||||
|
| M58 | REST-API (Centron.Controllers) | `src\webservice\Centron.Controllers` | REST-Endpunkte für Kunden, Aufträge, Tickets usw. mit Rechteprüfung. | A8 |
|
||||||
|
| M59 | Legacy-Webservices | `src\webservice\Centron.WebServices.Core` (2.528 Dateien) | Umfangreiche Service-Schicht für Client-Server-Kommunikation. | A8 |
|
||||||
|
| M60 | ConnectionManager / Hosts | `src\webservice\c-entron.misc.ConnectionManager`, `Centron.Host*` | Hosting der Dienste (Konsole, Windows-Dienst) und Verbindungsverwaltung. | A8 |
|
||||||
|
| M61 | Mobile | `Centron.BL\Mobile` | Unterstützung mobiler Zugriffe. | A8 |
|
||||||
|
| M62 | DocSync / docuFORM | `...\Modules\DataExchange\DocSync`, `DocuForm`, `Centron.Api.docuFORM` | Dokumenten-/Datenaustausch mit docuFORM (Geräte-/Zählerdaten). | A9 |
|
||||||
|
| M63 | RMM-Connectors | `...\Modules\DataExchange\Rmm`, `RmmController.cs` | Anbindung von Remote-Monitoring-Systemen (Geräte-/Alarmdaten). | A9 |
|
||||||
|
| M64 | TelekomDive | `Centron.BL`? `...\Modules\TelekomDive`, `DataExchange\TelekomDive` | Anbindung Telekom-DIVE-Portal (Aufträge/Provisionen). | A9 |
|
||||||
|
| M65 | Datenimport/-export generisch | `...\Modules\DataExchange\DataImport`, `DataExport`, `Connectors` | Konfigurierbarer Im-/Export von Stammdaten und Belegen. | A9 |
|
||||||
|
| M66 | Integrations / RiverDivo / CPra | `Centron.BL\Integrations`, `RiverDivo`, `CPra` | Weitere Drittsystem-Anbindungen. | A9 |
|
||||||
|
| M67 | Gateway | `src\backend\Centron.Gateway` | Vermittlungsschicht zwischen Client und Diensten. | A9 |
|
||||||
|
| M68 | Produktion / Fertigungsaufträge | `Centron.BL\Production`, `...\Modules\Production` | Fertigungsaufträge und Maschinenverwaltung. | A10 |
|
||||||
|
| M69 | Projektmanagement | `Centron.BL\Projects`, `...\Modules\ProjectManagement` | Projekte mit Budgets/Auswertung. | A10 |
|
||||||
|
| M70 | Projektpreisimport | `...\Modules\ProjectPriceImport` | Import projektspezifischer Preise mit Differenzprüfung. | A10 |
|
||||||
|
| M71 | PLM (Product Lifecycle) | `...\Modules\PLM`, `...\Finances\ProductLifecycleManagement` | Lebenszyklusverwaltung von Produkten/Geräten. | A10 |
|
||||||
|
| M72 | QM | `...\Modules\QM` | Qualitätsmanagement-Funktionen. | A10 |
|
||||||
|
| M73 | Statistiken / Management-Info | `Centron.BL\Statistics` (16), `...\Modules\Statistics` | Vertriebs-, MSP- und Mitarbeiterauswertungen. | A10 |
|
||||||
|
| M74 | Reporting / ReportEngine | `Centron.BL\ReportEngine` (26), `...\Modules\Reports`, `...\Administration\ReportServer` | Berichtserzeugung (Belegdruck, Listen) über Reportvorlagen. | A10 |
|
||||||
|
| M75 | Massenupdates | `Centron.BL\MassUpdate`, `...\Modules\Massenupdates` | Massenänderungen an Stammdaten/Verträgen. | A10 |
|
||||||
|
| M76 | Dashboard | `Centron.BL\DocuBoard`, `...\Modules\Dashboard`, `Statistics\Dashboard` | Konfigurierbare Kennzahlen-Dashboards. | A10 |
|
||||||
|
| M77 | Persistenzschicht / DB-Schema | `Centron.DAO`, `Centron.Entities`, `SSMS_DB_SCHEMA.sql` (1.535 Tabellen) | Datenzugriff und relationales Schema. | A11 |
|
||||||
|
| M78 | Volltextsuche (IndexSearch) | `Centron.BL\IndexSearch` | Indexgestützte übergreifende Suche. | A11 |
|
||||||
|
| M79 | Änderungsverfolgung (ChangeTracking) | `Centron.BL\ChangeTracking` | Protokollierung von Datenänderungen. | A11 |
|
||||||
|
| M80 | Dateiablage (Storage) | `Centron.BL\Storage`, `...\CentronFileSystem` | Ablage von Dokumenten/Dateien zu ERP-Objekten. | A11 |
|
||||||
|
| M81 | Lokalisierung | `...\Centron.WPF.UI\Localization`, `ResXManager.config.xml` | Mehrsprachige Oberflächentexte (ResX). | A11 |
|
||||||
|
| M82 | Logging / Telemetrie | `nlog.config`, `Centron.BL\Telemetry`, `...\Administration\LogViewer` | Technisches Logging und Telemetrie inkl. Log-Ansicht. | A11 |
|
||||||
|
| M83 | KI-Funktionen | `Centron.BL\ArtificialIntelligence` (25), `...\Modules\ArtificialIntelligence` | OpenAI-gestützte Funktionen (Chat, Angebotstexte, Textbewertung). | A11 |
|
||||||
|
| M84 | UI-Framework / Controls / GUI-Profile | `src\shared\Centron.Controls` (742), `...\Modules\Gui\Profiles` | Wiederverwendbare UI-Steuerelemente und benutzerspezifische Oberflächenprofile. | A11 |
|
||||||
|
| M85 | Externe Tools | `Centron.BL\ExternalToolsBL`, `...\Modules\ExternalTool` | Einbindung externer Programme mit Variablenübergabe. | A11 |
|
||||||
|
| M86 | Mandantenverwaltung | `...\Administration\MandatorManagement` | Verwaltung mehrerer Mandanten. | A12 |
|
||||||
|
| M87 | Einstellungsverwaltung | `...\Administration\Settings`, `docs\guides\development\settings-management.md`, `CentronConfigDb` | Zentrale, hierarchische Systemeinstellungen. | A12 |
|
||||||
|
| M88 | Textbausteine | `Centron.BL\TextModuleArea`, `...\Administration\TextBlockManagement` | Wiederverwendbare Textbausteine für Belege/Mails. | A12 |
|
||||||
|
| M89 | Hintergrunddienste | `docs\Background Service\DataQualityService.md`, `Centron.BL\Services`, `...\Administration\Services` | Zeitgesteuerte Serverdienste (u. a. Datenqualität, Eskalation). | A12 |
|
||||||
|
| M90 | Eskalationsregeln | `...\Administration\EscalationsSettings` | Konfigurierbare Eskalationen (z. B. Ticketfälligkeit). | A12 |
|
||||||
|
| M91 | PDF-Export/-Signierung | `...\Administration\PdfExport`, `PdfSigning` | PDF-Erzeugung und qualifizierte Signatur von Belegen. | A12 |
|
||||||
|
| M92 | Deployment / Betrieb | `docker`, `azure`, `deployment`, `scripts`, `Centron.Host.WindowsService` | Build-, Container- und Releaseprozesse; Betrieb als Windows-Dienst/Container. | A12 |
|
||||||
|
| M93 | Stundenzuschlagssätze | `...\Administration\HourlySurchargeRates` | Zuschlagsregeln auf Arbeitszeiten. | A12 |
|
||||||
|
| M94 | Update-Benachrichtigung | `...\Administration\UpdateAvailableNotificationSettings` | Hinweis auf verfügbare Programmversionen. | A12 |
|
||||||
|
| M95 | Gutscheinverwaltung | `Centron.BL\VoucherManagement` | Verwaltung von Gutscheinen. | A2 |
|
||||||
|
| M96 | Web-Links/URLs | `Centron.BL\Urls`, `WebLinks` | Verwaltung von Weblinks zu ERP-Objekten. | A8 |
|
||||||
|
|
||||||
|
*Das Inventar wurde vor der ersten Anforderung erstellt und im Laufe der Analyse ergänzt (nicht gekürzt); die Abdeckungstabelle unten führt jede Zeile mit Analysetiefe und Anforderungszahl.*
|
||||||
|
|
||||||
|
### Inventar-Korrekturen aus der Analyse
|
||||||
|
|
||||||
|
Die Detailanalyse hat die Ein-Satz-Beschreibungen bzw. Pfade folgender Module korrigiert oder präzisiert (das ursprüngliche Inventar bleibt oben unverändert stehen; maßgeblich sind die Korrekturen):
|
||||||
|
|
||||||
|
| Nr. | Korrektur (Kurzfassung) |
|
||||||
|
|---|---|
|
||||||
|
| M01 | `Centron.BL\Security` enthält nur `PdfSigningBL.cs`; die Rechte-BL liegt in `Centron.BL\Administration\Rights` (AppRightsBL), die Rechtekonstanten in `Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs`. |
|
||||||
|
| M03 | `Centron.BL\TwoFactorAuthenticator` enthält nur die TOTP-PIN-Prüfung für den Passwortmanager; die Login-2FA (RADIUS/E-Mail-Link) liegt in `Centron.BL\Administration\Logins\TwoFactor`. |
|
||||||
|
| M04 | Der Passwortmanager existiert doppelt: `PasswordManagementArea` (Alt) und `PasswordManager` (aktuell, AES-verschlüsselt, Siegel). |
|
||||||
|
| M06 | Enthält zwei parallele Auswertungsmodule: `ContractEvaluation2` und `ContractEvaluationOld` (Altimplementierung). |
|
||||||
|
| M11 | Verwaltet Kostenstellen (CostCenter) und Kostenträger (CostObject, UI „Payers") — nicht „Zahler" im Sinne abweichender Rechnungsempfänger. |
|
||||||
|
| M15/M19/M20 | ZUGFeRD-Import liegt unter `Centron.Controllers\Controllers\v1\Receipts\`; E-Rechnungs-Generatoren in `Centron.BL\DataExchange\EDI\SaleInvoices\`; Konditions-Durchsetzung in `Centron.BL\Sales\Receipts\ReceiptBL.cs`. |
|
||||||
|
| M27 | RMA-BL liegt in `Centron.BL\CustomerArea\RmaBL.cs`; umfasst Kundenretouren, Lieferantenrücksendungen (SendBack) und Vorab-/Ersatzlieferungen (SendForth). |
|
||||||
|
| M31 | Ticket-Zeiterfassung liegt in `Centron.BL\Sales\Support` (HelpdeskTimerBL u. a.), nicht in `Centron.BL\Time` (dort nur TimingSettingsBL). |
|
||||||
|
| M33 | Expected Events = kundenbezogene Überwachung erwarteter externer Ereignisse (z. B. Backup-Meldungen) mit Zeitfenstern und Textmustern; Auswertungskomponente liegt außerhalb der Codebasis. |
|
||||||
|
| M36 | Umfrage-BL liegt in `Centron.BL\Accounts\Survey\SurveyProcessBL.cs`; Kopplung an Ticketabschluss über `HelpdeskCloseBL.AddSurvey()`. |
|
||||||
|
| M39 | EmployeeManagement-UI liegt im WPF-Client und in `Centron.Controls`; BL in `Centron.BL\EmployeeArea`. |
|
||||||
|
| M40 | „Stammblätter" = `MasterDataList` unter `Centron.BL\Sales\CustomerAssets\Contracts\ClickContracts`; `ItPlanner` enthält nur Checklisten-Kategorien. Kundengeräte liegen in **drei** Datenhaltungen (Stammblätter, `AccountDevices`, AssetManagement-/River-Sync). |
|
||||||
|
| M42 | Custom-Property-Logik liegt in `Centron.BL\Administration\Customization`; `Centron.BL\Customizations\CustomTables` ist nur ein Report-Hilfsdienst. |
|
||||||
|
| M47 | `Centron.BL\Outlook` enthält nur eine Asset-Suche für das Add-in; Exchange-Funktionalität liegt im Blazor-Add-in, `Centron.BL\Mail\Exchange` (EWS) und der Kalender-Synchronisation. |
|
||||||
|
| M50 | Zwei getrennte Benachrichtigungssysteme: `Notifications` (System-/Adminprotokoll, externe Empfänger) und `NexusNotifications` (persönliche Mitarbeiter-Benachrichtigungen mit SignalR-Push). |
|
||||||
|
| M52 | VideoPortal = rechtegeschützte Video-Zuweisung mit ToDo-Kopplung; SocialMedia = interner Aktivitäten-Stream auf Stored-Procedure-Basis. |
|
||||||
|
| M53 | WebCart umfasst das gesamte Endkunden-Portal (Belege/Verträge, Tickets, Formulare, Dokumente, Zeitnachweise), nicht nur den Warenkorb. |
|
||||||
|
| M56 | DocumentSigning (Route `/contractmanagement`) signiert beliebige PDF-Dokumente inkl. SEPA-Mandate über einmalige GUID-Links. |
|
||||||
|
| M61 | „Mobile" ist ein 37-zeiliger Alt-Lesezugriff auf `NewMobileEmployee`/`NewMobileContactPerson`, kein Mobile-Backend. |
|
||||||
|
| M62 | docuFORM = OAuth2-Import von Druckgeräte-Seitenzählern für die Click-Abrechnung; DocSync = davon unabhängige Dokumentbereitstellung je Objektart. |
|
||||||
|
| M66 | „CPra" = Konnektor zum Dienst Nexoware Smartflow; EsCustomerGroups/EsRoles = lokale Caches von ElectronicSales-Webshop-Stammdaten. |
|
||||||
|
| M69 | ProjectManagement = internes Projekt-/Auslastungsboard, hart codiert auf die Abteilung „Software-Entwicklung"; `Centron.BL\Projects` ist trivialer Altbestand. |
|
||||||
|
| M71 | Keine Doppelimplementierung: `Modules\Finances\ProductLifecycleManagement` ist nur der Einstellungsdialog des PLM-Moduls. |
|
||||||
|
| M76 | `Modules\Dashboard` = Modul-Startübersicht (Kacheln), kein Kennzahlen-Dashboard; `Centron.BL\DocuBoard` = Asset-Management-Stammlisten. |
|
||||||
|
| M79 | Das eigentliche ChangeTracking liegt in `Centron.DAO\ChangeTracking` und `ChangeLogBL`; `Centron.BL\ChangeTracking` enthält nur Import-Historie. |
|
||||||
|
| M80 | `Centron.BL\Storage` ist seit 2014 vollständig auskommentierte, obsolete Inventur-Altlogik; die Dateiablage liegt clientseitig in `CentronFileSystem` (Backend: FileManagement). |
|
||||||
|
| M86 | Mandantenverwaltung = Firmenstammdaten/Filialen in EINER Datenbank; keine Mandantentrennung im SaaS-Sinn (kein getrennter Datenraum). |
|
||||||
|
| M89 | Der Host betreibt ca. 35 über die Tabelle `BackgroundServices` einzeln aktivierbare Hintergrunddienste auf der Basisklasse `ManagedBackgroundService`. |
|
||||||
|
| M95 | Gutscheinmodul = belegbasierte Statusauswertung (frei/ausgegeben/eingelöst) über `GutscheinZuRechnung`; Ausgabe/Einlösung erfolgt im Belegwesen. |
|
||||||
|
|
||||||
|
## Vorgehen im Lauf
|
||||||
|
|
||||||
|
Die Analyse folgte den Schritten 0–6 der RRE-Methodenkette: (0) Modulinventar vor der ersten Anforderung, (0b) Mindestabdeckung je Modul, (0c) Vertiefung nach Risiko (Sicherheit, Abrechnung/Fakturierung, Berechtigungen zuerst), (2) Artefakterhebung, (3) technische Analyse, (4) semantische Interpretation, (5) Formalisierung, (6) Traceability. Die 96 Inventarmodule wurden in 12 Analyse-Cluster (A1–A12) aufgeteilt und parallel durch Analyse-Subagenten bearbeitet; jeder Cluster erhielt einen eigenen ID-Nummernkreis (A1=1xx … A12=12xx). Alle PRIMÄR-Belege wurden im Quelltext bzw. im SQL-Schema tatsächlich gelesen; die Codebasis wurde ausschließlich lesend verarbeitet.
|
||||||
|
|
||||||
|
## Abdeckungstabelle
|
||||||
|
|
||||||
|
Jede Zeile des Modulinventars mit Analysetiefe und Anzahl der daraus erzeugten Anforderungen. Anforderungszahlen enthalten teilweise anteilige Zuordnungen (eine Anforderung kann mehrere Module eines Clusters tragen); Bezugsgröße ist die Abdeckungsangabe des jeweiligen Cluster-Agenten. **Kein Modul ist ohne Anforderung** (Mindestabdeckung erfüllt); kein Modul musste als `nicht analysiert` eingestuft werden.
|
||||||
|
|
||||||
|
| Nr. | Modul | Tiefe | Anzahl Anforderungen | Bemerkung |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M01 | Rechteverwaltung/UserRights | tief | 9 | HasUserRight-Kern, Datenmodell, Gruppenverwaltung, Audit-Log |
|
||||||
|
| M02 | Authentifizierung Webservice (JWT) | tief | 6 | JwtAuthController, Authorize-Attribute, AuthenticatorFactory |
|
||||||
|
| M03 | Zwei-Faktor-Authentifizierung | tief | 4 | beide 2FA-Subsysteme analysiert |
|
||||||
|
| M04 | Passwortmanager | tief | 7 | inkl. Alt-Implementierung (Hypothese SwRS-119) |
|
||||||
|
| M05 | DSGVO-Funktionen | mittel | 5 | Kontaktlöschung/Cleanup/AVV belegt; Komplettlöschung nicht implementiert |
|
||||||
|
| M06 | Verträge (Service/Leasing) | tief | 6 | ContractBL vollständig; Auswertungsmodule nur Controller-Ebene |
|
||||||
|
| M07 | Automatisierte Abrechnung | tief | 7 | AutomaticFacturaBL (2.900 Zeilen) und TimerBillingBL gelesen |
|
||||||
|
| M08 | Mahnwesen | tief | 6 | DunningBL/DunningRunBL vollständig |
|
||||||
|
| M09 | OPOS/Zahlungen | tief | 4 | OposBL/PaymentsBL/IncomingPaymentBL vollständig |
|
||||||
|
| M10 | Onlinebanking/FinAPI | tief | 7 | Matching-Heuristiken; Rechte-Durchsetzung als Hypothese (SwRS-248) |
|
||||||
|
| M11 | Zahler & Kostenstellen | mittel | 1 | Belegzuordnungslogik nicht vertieft |
|
||||||
|
| M12 | Buchhaltungsexport (DATEV u. a.) | mittel | 4 | Formatauswahl/Exportflags; Formatgeneratoren nicht im Detail |
|
||||||
|
| M13 | Gerätezähler (Click-Abrechnung) | tief | 2 | DeviceClickCounterBL vollständig |
|
||||||
|
| M14 | SEPA | tief | 3 | Online-Signaturprozess mit Statusmaschine |
|
||||||
|
| M15 | Belegwesen Verkauf | tief | 24 | Belegkette, Storno, Festschreibung, Nummernkreise, MwSt; ReceiptBL (11.441 Zeilen) auszugsweise |
|
||||||
|
| M16 | Sonderpreise/Preisfindung | tief | 5 | Preisfindungshierarchie, Mindestpreis-Override |
|
||||||
|
| M17 | Produktmatrix | mittel | 3 | BL + Schema vollständig, UI überflogen |
|
||||||
|
| M18 | Mailing/Kampagnen | mittel | 4 | Versandpfad nicht vertieft (Hypothese SwRS-350) |
|
||||||
|
| M19 | E-Rechnung (XRechnung/ZUGFeRD/ebInterface) | mittel | 4 | Formatwahl/Leitweg-ID belegt; XML-Feldmapping nicht Feld für Feld |
|
||||||
|
| M20 | Belegkonditionen | mittel | 2 | Durchsetzung am Beleg belegt |
|
||||||
|
| M21 | Artikelstamm & Lager | tief | 14 | Rechte, Bestandsermittlung, gleitender EK, Inventur |
|
||||||
|
| M22 | Kommissionierung | mittel | 3 | zwei parallele Implementierungen festgestellt |
|
||||||
|
| M23 | Barcode/Seriennummern | tief | 4 | Statusmodell, Eindeutigkeit, Ausbuchung |
|
||||||
|
| M24 | Einkauf & Bestellvorschlag | mittel | 3 | Bestellvorschlags-SQL tief; TravelExpense nur gesichtet |
|
||||||
|
| M25 | EDI (Lieferanten) | mittel | 3 | Formatdispatcher belegt; Distributor-Parser nicht vertieft |
|
||||||
|
| M26 | Versand/Logistik | mittel | 4 | GLS-Limits und Shipcloud-Broker belegt |
|
||||||
|
| M27 | RMA/Retouren | mittel | 3 | Statusmaschine SaveRma tief |
|
||||||
|
| M28 | Produktdaten-Anbindungen | flach | 2 | Icecat/ITscope/EGIS gelesen; CopDataAccess nicht analysiert |
|
||||||
|
| M29 | TradePool | flach | 1 | fachlicher Zweck unklar (Hypothese SwRS-451) |
|
||||||
|
| M30 | Helpdesk/Ticketsystem | tief | 12 | Statusmodell, Rechte, Fälligkeit, Eskalation, Abschluss |
|
||||||
|
| M31 | Zeiterfassung auf Tickets | tief | 8 | serverseitige Rechte belegt; MOVE-Recht nur clientseitig |
|
||||||
|
| M32 | Checklisten | mittel | 2 | kein hartes Abschluss-Gate gefunden |
|
||||||
|
| M33 | Expected Events | mittel | 2 | Auswertungskomponente außerhalb der Codebasis (Hypothese SwRS-545) |
|
||||||
|
| M34 | SelfCare | mittel | 3 | GUID-/Ablauflogik belegt |
|
||||||
|
| M35 | TaskManager | mittel | 2 | Wiederholungsregeln, Handler, Lizenzprüfung |
|
||||||
|
| M36 | Umfragen | mittel | 2 | Antwort-Erfassung (ServiceBoard) nicht analysiert |
|
||||||
|
| M37 | Ticket-Projekte | flach | 1 | CRUD/Nummernkreis belegt |
|
||||||
|
| M38 | Adress-/Kundenstamm | tief | 12 | AccountBL/WebAccountBL gelesen |
|
||||||
|
| M39 | Mitarbeiterstamm | mittel | 5 | EmployeeBL/AppUserBL gelesen |
|
||||||
|
| M40 | Geräte/Assets/Stammblätter | tief | 7 | Drei-Datenhaltungen-Befund dokumentiert |
|
||||||
|
| M41 | Länder/Regionen | mittel | 2 | CountryBL/FederalStateBL vollständig |
|
||||||
|
| M42 | Tags & Custom Properties | tief | 3 | Pflichtfeldprüfung nur clientseitig |
|
||||||
|
| M43 | Objekt-Externreferenzen | tief | 1 | Detailregeln in SyRS-612; Tabelle fehlt im SQL-Dump |
|
||||||
|
| M44 | Mail (Versand/Empfang), MailScanner | tief | 8 | Absender-Whitelist, VMA-Verschlüsselung |
|
||||||
|
| M45 | Mail-Vorlagen | tief | 3 | Fallback-Hierarchie belegt |
|
||||||
|
| M46 | Kalender/Termine | mittel | 4 | CalendarBL/AppointmentRequestBL vollständig |
|
||||||
|
| M47 | Outlook/Exchange | mittel | 2 | Sync teils über Doku (KONTEXT) erfasst |
|
||||||
|
| M48 | Telefonie (TAPI) | tief | 4 | PhoneCallBL/PhoneSettingsBL gelesen |
|
||||||
|
| M49 | Chats | tief | 2 | Mitgliedschafts-Expressions belegt |
|
||||||
|
| M50 | Benachrichtigungen | mittel | 3 | zwei Systeme (Konsolidierungskandidat) |
|
||||||
|
| M51 | MyCentron/MyDay/ToDo | tief | 6 | Rechteprüfungen FREMDTODOLISTE belegt |
|
||||||
|
| M52 | Social Media / VideoPortal | mittel | 3 | SocialMedia-Logik in Stored Procedures (Hypothese SwRS-748) |
|
||||||
|
| M53 | Nexus WebCart | tief | 5 | Freigabewesen bis in die BL verfolgt |
|
||||||
|
| M54 | Nexus WebOffer | mittel | 2 | Token-Flow und Zustandsmodell |
|
||||||
|
| M55 | Nexus ServiceBoard | mittel | 3 | CloseTicket/Auth vertieft; Kanban/Scheduler strukturell |
|
||||||
|
| M56 | Nexus DocumentSigning | mittel | 2 | Signaturseite und DsgvoBL vollständig |
|
||||||
|
| M57 | Nexus Produktionsaufträge | mittel | 2 | Auth-Lücke als Hypothese (SwRS-848) |
|
||||||
|
| M58 | REST-API (Centron.Controllers) | tief | 10 | alle Authorization-Klassen und Filter gelesen |
|
||||||
|
| M59 | Legacy-Webservices | flach | 2 | 2.530 Dateien, vereinbarungsgemäß nur strukturell |
|
||||||
|
| M60 | ConnectionManager/Hosts | mittel | 2 | beide Host-Einstiege gelesen |
|
||||||
|
| M61 | Mobile | tief | 1 | Modul vollständig (37 Zeilen), Altbestand |
|
||||||
|
| M62 | DocSync/docuFORM | mittel | 4 | Tokenfluss und Importablauf gelesen |
|
||||||
|
| M63 | RMM-Connectors | tief | 8 | RmmController/RiverDivoBL/DocBee-BLs vollständig |
|
||||||
|
| M64 | TelekomDive | mittel | 3 | Export-ViewModel und BL gelesen |
|
||||||
|
| M65 | Datenimport/-export generisch | flach | 2 | Kontenimport belegt; InvoiceUpload ist leerer Stub |
|
||||||
|
| M66 | Integrations/RiverDivo/CPra | mittel | 5 | EsRoleBL nur Kopf geprüft |
|
||||||
|
| M67 | Gateway | flach | 2 | Struktur inventarisiert, Adapter nicht im Detail |
|
||||||
|
| M68 | Produktion | tief | 4 | Statusmodell, Logkatalog, Schema |
|
||||||
|
| M69 | Projektmanagement | mittel | 2 | interner Sonderfall (hart codierte Abteilung) |
|
||||||
|
| M70 | Projektpreisimport | mittel | 1 | Import-/Differenzlogik gelesen |
|
||||||
|
| M71 | PLM | tief | 3 | Konsolidierungsfrage geklärt (keine Doppelimplementierung) |
|
||||||
|
| M72 | QM | mittel | 2 | Durchsetzung in ReceiptBL/CustomerAssetBL |
|
||||||
|
| M73 | Statistiken | tief | 6 | Rechte-/Abrechnungslogik (MSP) im Fokus |
|
||||||
|
| M74 | Reporting/ReportEngine | tief | 5 | doppelte Berichts-Datenhaltung belegt |
|
||||||
|
| M75 | Massenupdates | tief | 3 | alle vier Start-Pfade gesichtet |
|
||||||
|
| M76 | Dashboard/DocuBoard | mittel | 2 | drei DocuBoard-BLs vollständig |
|
||||||
|
| M77 | Persistenzschicht/DB-Schema | tief | 6 | Transaktionen, Listener, Konventionen, Constraints |
|
||||||
|
| M78 | Volltextsuche (IndexSearch) | tief | 4 | alle Kerndateien + Schema |
|
||||||
|
| M79 | ChangeTracking | mittel | 4 | Attribut-Mechanismus ungenutzt (Befund) |
|
||||||
|
| M80 | Dateiablage | mittel | 2 | BL\Storage als obsolet eingestuft; Server-BL als Hypothese (SyRS-1119) |
|
||||||
|
| M81 | Lokalisierung | mittel | 2 | LocalizationHelper vollständig |
|
||||||
|
| M82 | Logging/Telemetrie | tief | 4 | TelemetryBL vollständig; Schema-Drift festgestellt |
|
||||||
|
| M83 | KI-Funktionen | mittel | 3 | SSRF-Schutz und Schlüssel-Verschlüsselung belegt |
|
||||||
|
| M84 | UI-Framework/GUI-Profile | mittel | 2 | Controls strukturell; Profil-Rechtelogik tief |
|
||||||
|
| M85 | Externe Tools | mittel | 2 | BL vollständig |
|
||||||
|
| M86 | Mandantenverwaltung | tief | 6 | serverseitige Rechteprüfung offen (Hypothese SwRS-1233) |
|
||||||
|
| M87 | Einstellungsverwaltung | tief | 5 | beide Settings-Tabellen (Stammdat/ApplicationSettings) |
|
||||||
|
| M88 | Textbausteine | mittel | 3 | TextModuleBL vollständig |
|
||||||
|
| M89 | Hintergrunddienste | tief | 4 | ~35 Dienste auf gemeinsamer Basisklasse |
|
||||||
|
| M90 | Eskalationsregeln | mittel | 2 | Kernberechnung DoEscalation nicht gelesen |
|
||||||
|
| M91 | PDF-Export/-Signierung | tief | 5 | PdfSigningBL vollständig |
|
||||||
|
| M92 | Deployment/Betrieb | mittel | 2 | Docker/Compose/Windows-Dienst gelesen |
|
||||||
|
| M93 | Stundenzuschlagssätze | mittel | 2 | serverseitige BL nicht gelesen |
|
||||||
|
| M94 | Update-Benachrichtigung | mittel | 2 | Versions- und Zielgruppenlogik gelesen |
|
||||||
|
| M95 | Gutscheinverwaltung | mittel | 1 | NamedQuery vollständig analysiert |
|
||||||
|
| M96 | Web-Links/URLs | mittel | 1 | SimpleUrl vs. WebLink (Konsolidierungskandidat) |
|
||||||
|
|
||||||
|
**Zusammenfassung der Analysetiefe:** 42 Module tief, 48 Module mittel, 6 Module flach (M28, M29, M37, M59, M65, M67), 0 Module nicht analysiert. Zusätzlich wurden Querschnittsthemen ohne eigene Inventarzeile erfasst (Login/Sessions, Architektur-Schichtung, Heartbeat, Teststrategie, Profiling, SqlManagers).
|
||||||
|
|
||||||
|
## Konsistenzcheck über das gesamte Anforderungs-Set
|
||||||
|
|
||||||
|
Der Check wurde skriptgestützt über alle 413 Anforderungsblöcke (StRS.md, SyRS.md, SwRS.md) ausgeführt.
|
||||||
|
|
||||||
|
| Prüfung | Ergebnis |
|
||||||
|
|---|---|
|
||||||
|
| Anforderungen gesamt | **413** (50 StRS, 122 SyRS, 241 SwRS) |
|
||||||
|
| Doppelte oder mehrfach vergebene IDs | **keine** (413 eindeutige IDs; Hinweis: SwRS-240 wurde nicht vergeben — dokumentierte Lücke im Nummernkreis A2, kein fehlender Inhalt) |
|
||||||
|
| Anforderungen ohne Beleg | **keine** (jede Anforderung führt mindestens einen klassifizierten Beleg mit Begründung) |
|
||||||
|
| Anforderungen ohne Prüfidee | **keine** |
|
||||||
|
| Anforderungen ohne Angabe zur Übernahmewürdigkeit | **keine** |
|
||||||
|
| Tracelinks auf nicht existierende IDs | **keine** (alle referenzierten IDs existieren) |
|
||||||
|
| Anforderungen ohne Tracelinks | **keine** |
|
||||||
|
| Nicht-funktionale Anforderungen ohne ISO-25010-`Qualitätsmerkmal` | **keine** (21 nicht-funktionale Anforderungen, alle mit Merkmal) |
|
||||||
|
| Status-Verteilung | 397 `belegt`, 16 `HYPOTHESE` (3,9 %) |
|
||||||
|
| Abgleich `Hypothesen.md` gegen Inline-Markierungen | **deckungsgleich**: beide Seiten nennen exakt dieselben 16 IDs (SyRS-110, SyRS-1119; SwRS-119, 248, 350, 354, 451, 545, 637, 740, 748, 848, 947, 1043, 1147, 1233); `Hypothesen.md` enthält keine zusätzlichen freien Fragen |
|
||||||
|
| Konsolidierungskandidaten | 44 Anforderungen (10,7 %) mit `Konsolidierung: Kandidat` |
|
||||||
|
| Risikoanforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) | **198**; jede trägt entweder mindestens einen `PRIMÄR`-Beleg mit durchsetzender Stelle oder ist als `HYPOTHESE` gekennzeichnet — **0 Verstöße** gegen die risikobasierte Priorisierung (skriptgeprüft) |
|
||||||
|
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung | keine gefunden; die bekannten Doppelimplementierungen (siehe Konsolidierungsübersicht) sind in den betroffenen Anforderungen als Kandidat markiert. Restrisiko: clusterübergreifende Dubletten wurden über die Meta-Abgleiche geprüft, eine paarweise Volltextprüfung aller 413 Anforderungen fand nicht statt |
|
||||||
|
|
||||||
|
### Konsolidierungsübersicht (fachlich gleichartige Konzepte in getrennten Implementierungen)
|
||||||
|
|
||||||
|
Wichtigste clusterübergreifend bestätigte bzw. vermutete Konsolidierungsfälle für das Zielsystem:
|
||||||
|
|
||||||
|
1. **Kundengeräte in drei Datenhaltungen** (bestätigt): „Stammblätter" `MasterDataList` (Drucker mit Klickzählern), `AccountDevices` (sonstige Hardware), AssetManagement-/River-Sync-Geräte — der im Auftrag genannte Fall, um eine dritte Datenhaltung erweitert.
|
||||||
|
2. **Zwei Berechtigungssysteme**: `Sichrech`/`Sichtrus`/`Sichmemb` (AppUser) vs. `WebRights`/`WebAccountsRights` (WebAccounts); dazu doppelter API-Zugriffsschutz (REST-Attributfilter vs. Legacy-`AuthenticateInterceptor`).
|
||||||
|
3. **Zwei 2FA-Subsysteme** (Login-2FA RADIUS/E-Mail vs. TOTP-PIN des Passwortmanagers) und **zwei Passwortmanager-Implementierungen** (alt/neu).
|
||||||
|
4. **Zahlungsausgleich doppelt**: IncomingPayments vs. OnlineBanking-Zuordnungen, beide über `UpdateReceiptIsPaid`; **Kostenstellen doppelt**: `Warehousing.CostCenter` vs. `Accounts.CustomerCostCenter`.
|
||||||
|
5. **Vertragsauswertung doppelt** (ContractEvaluation2 vs. „_old"); **Berichts-Datenhaltung doppelt** (`dbo.Reports` vs. `dbo.ReportData`); **Einstellungs-Datenhaltung doppelt** (`Stammdat` vs. `ApplicationSettings`).
|
||||||
|
6. **Drei E-Rechnungs-Generatoren** (ZUGFeRD/XInvoice, ebInterface, Gateway `ZUGFeRD21_Extended`); **Beleg-Summenlogik doppelt** (`ReceiptPriceHelper` vs. `CalculationUtils`).
|
||||||
|
7. **Lager/Logistik intern**: Inventur alt/neu, Kommissionierung (`CommissioningBL` vs. `OrderCommissionBL`), `BarCode` vs. `BarCode2`, GLS-Direktanbindung vs. Shipcloud-Broker, RMA-Alt-Tabellen; **duale Bestandsermittlung** (Seriennummernzählung vs. Mengenfeld, Regel doppelt in SQL und C#).
|
||||||
|
8. **Kommunikation**: zwei Benachrichtigungssysteme (`Notifications` vs. `NexusNotifications`), zwei Kalender-Sync-Pfade (EWS vs. Graph), zwei Anrufjournal-Befüllungen (TAPI vs. Teams-CallRecords), Mail-Body-Aufbau doppelt (`FillMailBodyOld`/`New`).
|
||||||
|
9. **Externe Referenzen dreifach** (generische `ObjectExternalReference`, `RiverbirdCustomerReference`, `EsCustomerGroup.ExternalId`); **„externes Ereignis → Ticket" dreifach** (RiverDivo, DocBee-Timer, DocBee-Creation).
|
||||||
|
10. **Weitere**: `SimpleUrl` vs. `WebLink`, `NewMobileEmployee` vs. Mitarbeiterstamm, zwei tokenbasierte Dokumentsignatur-Pfade (DocumentSigning vs. Office/SharedDocument), Adress-Doppelhaltung neu (`AccountAddresses`) vs. alt (`Anschrif`/`Address`), Entitäten `Mandator`/`Mandatory` auf derselben Tabelle `Mandant`, TicketProjects neben allgemeinem Projektmodul, Rechte-Doku doppelt (`CentronRights.md` vs. `Sichrech.Beschreibung`).
|
||||||
|
|
||||||
|
## Liste aller risikorelevanten Anforderungen
|
||||||
|
|
||||||
|
Alle 198 Anforderungen zu Sicherheit, Abrechnung/Fakturierung und Berechtigungen mit ihrer Belegsituation (skriptgeprüft: jede Zeile hat `PRIMÄR = ja` oder `Status = HYPOTHESE`). Vollständige Titel und Belege in StRS.md/SyRS.md/SwRS.md.
|
||||||
|
|
||||||
|
### A1 — Sicherheit, Identität, Berechtigungen (37)
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| StRS-101 | Rollenbasierte Zugriffskontrolle für alle Fachfunktionen | ja | belegt |
|
||||||
|
| StRS-102 | Gesicherte Anmeldung für interne Benutzer und Kunden | ja | belegt |
|
||||||
|
| StRS-103 | Schutz und Nachvollziehbarkeit von Kundenzugangsdaten | ja | belegt |
|
||||||
|
| StRS-104 | DSGVO-konforme Löschung und Bereinigung personenbezogener Daten | ja | belegt |
|
||||||
|
| SyRS-101 | Durchgängige Berechtigungsprüfung an allen Systemschnittstellen | ja | belegt |
|
||||||
|
| SyRS-102 | Administrierbarkeit des Rechtesystems mit Protokollierung | ja | belegt |
|
||||||
|
| SyRS-103 | Sitzungsverwaltung über Tickets mit begrenzter Lebensdauer | ja | belegt |
|
||||||
|
| SyRS-104 | Konfigurierbare Authentifizierungsverfahren mit benutzerbezogenem Fallback | ja | belegt |
|
||||||
|
| SyRS-105 | Zwei-Faktor-Authentifizierung systemweit zuschaltbar | ja | belegt |
|
||||||
|
| SyRS-106 | Getrennte Identitäten AppUser/WebAccount | ja | belegt |
|
||||||
|
| SyRS-107 | Kontodeaktivierung verhindert Anmeldung | ja | belegt |
|
||||||
|
| SyRS-108 | Passwortmanager mit Lizenz-, Richtlinien- und Protokollpflicht | ja | belegt |
|
||||||
|
| SyRS-109 | DSGVO-Funktionen nur mit dediziertem Recht | ja | belegt |
|
||||||
|
| SyRS-110 | Serverseitige Durchsetzung aller UI-Rechte | nein | HYPOTHESE |
|
||||||
|
| SwRS-101 | Benutzerrechtsprüfung über Gruppenmitgliedschaft | ja | belegt |
|
||||||
|
| SwRS-102 | Rechte-Datenmodell und zentrale Rechtekonstanten | ja | belegt |
|
||||||
|
| SwRS-103 | Rechtegruppenverwaltung mit Admin-Gruppen-Schutz | ja | belegt |
|
||||||
|
| SwRS-104 | Protokollierung aller Rechteänderungen | ja | belegt |
|
||||||
|
| SwRS-105 | REST-Autorisierung über Rechte-Attribute (401/403) | ja | belegt |
|
||||||
|
| SwRS-106 | JWT-/OIDC-Login mit Subject-Zuordnung | ja | belegt |
|
||||||
|
| SwRS-107 | Basic-Auth über SHA1-Passworthash | ja | belegt |
|
||||||
|
| SwRS-108 | Abweisung deaktivierter Konten | ja | belegt |
|
||||||
|
| SwRS-109 | Ticket-Lebensdauer und Verlängerung | ja | belegt |
|
||||||
|
| SwRS-110 | Passwortänderung mit Ist-Passwort-Prüfung und Mindestlänge | ja | belegt |
|
||||||
|
| SwRS-111 | Web-Account-Login mit Aktivitätskette | ja | belegt |
|
||||||
|
| SwRS-112 | Entscheidungslogik Zwei-Faktor-Bestätigung | ja | belegt |
|
||||||
|
| SwRS-113 | E-Mail-Link-Zweitfaktor mit Einmalcode | ja | belegt |
|
||||||
|
| SwRS-114 | TOTP-PIN-Prüfung für Passwortmanager | ja | belegt |
|
||||||
|
| SwRS-115 | Passwortmanager-Rechteprüfungen | ja | belegt |
|
||||||
|
| SwRS-116 | Export von Zugangsdaten nur mit Exportrecht | ja | belegt |
|
||||||
|
| SwRS-117 | AES-Verschlüsselung mit Masterkey und Fallback-Schlüssel | ja | belegt |
|
||||||
|
| SwRS-118 | Siegelbruch mit Recht, Kommentar, Protokoll, Mail | ja | belegt |
|
||||||
|
| SwRS-119 | Alt-Passwortverwaltung ohne wirksame Verschlüsselung | teilweise | HYPOTHESE |
|
||||||
|
| SwRS-120 | DSGVO-Kontaktlöschung mit Löschprotokoll | ja | belegt |
|
||||||
|
| SwRS-121 | DSGVO-Datenbereinigung und Modulzugang | ja | belegt |
|
||||||
|
| SwRS-122 | AVV-Verwaltung mit eigenen Rechten | ja | belegt |
|
||||||
|
| SwRS-1233 | Serverseitige Rechteprüfung beim Speichern von Mandantenstammdaten (A12) | nein | HYPOTHESE |
|
||||||
|
|
||||||
|
### A2 — Finanzen & Abrechnung (44)
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| StRS-201 | Wiederkehrende vertragsbasierte Abrechnung | ja | belegt |
|
||||||
|
| StRS-202 | Forderungsmanagement und Zahlungsabgleich | ja | belegt |
|
||||||
|
| StRS-203 | Ordnungsgemäße Übergabe an die Finanzbuchhaltung | ja | belegt |
|
||||||
|
| StRS-204 | Digitale SEPA-Mandatsverwaltung | ja | belegt |
|
||||||
|
| StRS-205 | Zugriffsschutz auf Finanzfunktionen | ja | belegt |
|
||||||
|
| SyRS-206 | Abrechnungsintervalle und Zeitraumfortschreibung | ja | belegt |
|
||||||
|
| SyRS-207 | Verknüpfung Rechnung–Vertrag und Kontingentbuchung | ja | belegt |
|
||||||
|
| SyRS-208 | Vertragslebenszyklus | ja | belegt |
|
||||||
|
| SyRS-209 | Click-/Zählerabrechnung | ja | belegt |
|
||||||
|
| SyRS-210 | Abrechnung von Ticketzeiten | ja | belegt |
|
||||||
|
| SyRS-211 | Mahn- und OPOS-Läufe mit Versand | ja | belegt |
|
||||||
|
| SyRS-212 | OPOS-/Mahnübersicht mit Salden | ja | belegt |
|
||||||
|
| SyRS-213 | Zahlungseingänge und Rechnungsausgleich | ja | belegt |
|
||||||
|
| SyRS-214 | Bankauszugsimport und Zahlungsabgleich | ja | belegt |
|
||||||
|
| SyRS-215 | Externe Schnittstelle finAPI | ja | belegt |
|
||||||
|
| SyRS-216 | Multiformat-Buchhaltungsexport | ja | belegt |
|
||||||
|
| SyRS-217 | SEPA-Mandat-Onlineprozess | ja | belegt |
|
||||||
|
| SyRS-218 | Serverseitige Rechte-/Lizenzprüfung | ja | belegt |
|
||||||
|
| SwRS-230 | Vertragsende-Berechnung | ja | belegt |
|
||||||
|
| SwRS-231 | Automatischer Vertragsabschluss | ja | belegt |
|
||||||
|
| SwRS-232 | Kontingentrest-Formel | ja | belegt |
|
||||||
|
| SwRS-233 | Abrechnungstermin/Normierung | ja | belegt |
|
||||||
|
| SwRS-234 | Kontingentbuchung abweichende Intervalle | ja | belegt |
|
||||||
|
| SwRS-235 | Vertragsauswahl Abrechnungslauf | ja | belegt |
|
||||||
|
| SwRS-236 | Folge-ToDo nach Abrechnung | ja | belegt |
|
||||||
|
| SwRS-237 | Mahnstufen-Statusmaschine | ja | belegt |
|
||||||
|
| SwRS-238 | Mahnlauf-Protokoll | ja | belegt |
|
||||||
|
| SwRS-239 | Mahnreife (Sperre/Fälligkeit) | ja | belegt |
|
||||||
|
| SwRS-241 | Versandvoraussetzungen Mahn-E-Mail | ja | belegt |
|
||||||
|
| SwRS-242 | Zahlungseingang löschen (Rechte/Rückrechnung) | ja | belegt |
|
||||||
|
| SwRS-243 | OPOS-Saldenformel | ja | belegt |
|
||||||
|
| SwRS-244 | Duplikaterkennung Umsatzimport | ja | belegt |
|
||||||
|
| SwRS-245 | Abschlussstatus mit Toleranz | ja | belegt |
|
||||||
|
| SwRS-246 | Matching-Heuristiken | ja | belegt |
|
||||||
|
| SwRS-247 | Buchung/Chargeback/Storno | ja | belegt |
|
||||||
|
| SwRS-248 | Kontoauszugs-Rechte serverseitig | nein | HYPOTHESE |
|
||||||
|
| SwRS-249 | Export-Doppelschutz | ja | belegt |
|
||||||
|
| SwRS-250 | Steuer-Mapping Export | ja | belegt |
|
||||||
|
| SwRS-251 | Zählerhistorie/Monotonie | ja | belegt |
|
||||||
|
| SwRS-252 | SEPA-Mandatsdaten | ja | belegt |
|
||||||
|
| SwRS-253 | Kostenstellen/Kostenträger Soft-Delete | ja | belegt |
|
||||||
|
| SwRS-254 | Editierschutz Ticketzeiten | ja | belegt |
|
||||||
|
| SwRS-255 | Gutschein-Lebenszyklus | ja | belegt |
|
||||||
|
| SwRS-1246 | Validierung/Log der Stundenzuschlagssätze (A12) | ja | belegt |
|
||||||
|
|
||||||
|
### A3 — Vertrieb & Belegwesen (22)
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| StRS-302 | Korrekte und revisionssichere Fakturierung | ja | belegt |
|
||||||
|
| SyRS-312 | Belegnummernvergabe aus konfigurierbaren Nummernkreisen | ja | belegt |
|
||||||
|
| SyRS-313 | Mehrwertsteuerberechnung je Steuersatz mit definierter Rundung | ja | belegt |
|
||||||
|
| SyRS-314 | Revisionssichere Rechnung: Storno und Festschreibung | ja | belegt |
|
||||||
|
| SyRS-315 | Berechtigungsprüfung im Belegwesen | ja | belegt |
|
||||||
|
| SyRS-316 | Forderungsüberwachung: Mahnwesen und Kreditlimit | ja | belegt |
|
||||||
|
| SyRS-317 | Automatische Preisfindung mit Schutz des Mindestpreises | ja | belegt |
|
||||||
|
| SyRS-318 | E-Rechnungs-Export und -Import | ja | belegt |
|
||||||
|
| SwRS-334 | Nebenläufigkeitssichere Nummernvergabe | ja | belegt |
|
||||||
|
| SwRS-336 | MwSt-Splitting und Rundungsregeln | ja | belegt |
|
||||||
|
| SwRS-337 | MwSt-Pflichtprüfungen beim Belegspeichern | ja | belegt |
|
||||||
|
| SwRS-338 | Stornoregeln für Rechnungen | ja | belegt |
|
||||||
|
| SwRS-339 | Rechnungsfestschreibung mit Protokollierung | ja | belegt |
|
||||||
|
| SwRS-340 | Belegart-spezifische Rechteprüfungen inkl. Filialbindung | ja | belegt |
|
||||||
|
| SwRS-341 | Mahnstufen-Statusmaschine und Neuanlagesperre | ja | belegt |
|
||||||
|
| SwRS-342 | Kreditlimitprüfung beim Speichern | ja | belegt |
|
||||||
|
| SwRS-347 | Mindestpreis-Übersteuerung nur durch berechtigten Benutzer | ja | belegt |
|
||||||
|
| SwRS-350 | Werbesperre beim Mailingversand | nein | HYPOTHESE |
|
||||||
|
| SwRS-351 | E-Rechnungs-Formatauswahl und Dateierzeugung | ja | belegt |
|
||||||
|
| SwRS-352 | Authentifizierter ZUGFeRD-Parse-Endpunkt | ja | belegt |
|
||||||
|
| SwRS-353 | Konditionstexte am Beleg (Zahlungskonditionen) | ja | belegt |
|
||||||
|
| SwRS-354 | Manueller Storno für Nicht-Rechnungsbelege | nein | HYPOTHESE |
|
||||||
|
|
||||||
|
### A4 — Artikel, Lager, Einkauf, Logistik (7)
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| SyRS-411 | Berechtigungsmodell für Artikelpflege und Lagerbuchungen | ja | belegt |
|
||||||
|
| SyRS-412 | Lückenlose Protokollierung aller Bestandsänderungen | ja | belegt |
|
||||||
|
| SyRS-419 | Berechtigungsgeschützte Kommissionierung mit Mengenrückmeldung | ja | belegt |
|
||||||
|
| SwRS-430 | Feingranulare Rechteprüfung beim Artikelspeichern | ja | belegt |
|
||||||
|
| SwRS-432 | Gleitender Einkaufspreis bei Wareneingang | ja | belegt |
|
||||||
|
| SwRS-433 | Lagerumbuchung nur mit Recht TRANSFER_STOCK | ja | belegt |
|
||||||
|
| SwRS-439 | Zugriffsschutz des Kommissioniermoduls | ja | belegt |
|
||||||
|
|
||||||
|
### A5 — Helpdesk & Service (15)
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| StRS-502 | Abrechnungsfähige und rechtssichere Zeiterfassung auf Tickets | ja | belegt |
|
||||||
|
| SyRS-512 | Berechtigungsgeprüfte Ticketbearbeitung (intern und Web-Accounts) | ja | belegt |
|
||||||
|
| SyRS-513 | Fälligkeitsberechnung aus Priorität, geschütztes Fälligkeitsdatum | ja | belegt |
|
||||||
|
| SyRS-515 | Rechte- und Sperrkonzept der Ticket-Zeiterfassung | ja | belegt |
|
||||||
|
| SyRS-516 | Kundenunterschrift auf erbrachten Zeiten | ja | belegt |
|
||||||
|
| SyRS-517 | Automatische Ticketerzeugung durch den TaskManager | ja | belegt |
|
||||||
|
| SyRS-518 | Zeitlich begrenzte SelfCare-Formularlinks | ja | belegt |
|
||||||
|
| SwRS-533 | Serverseitige Rechteprüfung beim Ticket-Speichern | ja | belegt |
|
||||||
|
| SwRS-534 | Rechteprüfung für Portal-Web-Accounts mit Eigentümerbindung | ja | belegt |
|
||||||
|
| SwRS-538 | Zeiten speichern nur mit EDIT_TIME, Eigenzeiten-Beschränkung, Belegsperre | ja | belegt |
|
||||||
|
| SwRS-539 | Zeiten löschen mit DELETE_HELPDESK_TIMER, Belegsperre, Historie | ja | belegt |
|
||||||
|
| SwRS-541 | Unterschrift entfernen nur mit DELETE_HELPDESK_SIGNATURE | ja | belegt |
|
||||||
|
| SwRS-542 | Zeiten verschieben mit mehrstufiger Prüfkette (MOVE-Recht nur clientseitig) | ja | belegt |
|
||||||
|
| SwRS-546 | SelfCare-Webformulare: GUID, Ablauf, Formulardefinitionen | ja | belegt |
|
||||||
|
| SwRS-547 | TaskManager: Wiederholungsregeln, Handler-Dispatch, automatische Tickets | ja | belegt |
|
||||||
|
|
||||||
|
### A6 — Stammdaten & Assets (10)
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| SyRS-605 | Berechtigungsprüfung aller Geschäftspartner-Operationen | ja | belegt |
|
||||||
|
| SyRS-607 | Systemweit eindeutige Benutzer-Logins über Kontoarten hinweg | ja | belegt |
|
||||||
|
| SyRS-608 | Geschützte Mitarbeiterverwaltung mit automatischer Personalakte | ja | belegt |
|
||||||
|
| SwRS-620 | Operationsbezogene Rechteprüfung in AccountBL inkl. Betreuer-Einschränkung | ja | belegt |
|
||||||
|
| SwRS-624 | Feldbezogene Rechte für Adresssprache/-währung mit Wertrücksetzung | ja | belegt |
|
||||||
|
| SwRS-625 | Ansprechpartnerpflege mit rollenabhängigen Rechten | ja | belegt |
|
||||||
|
| SwRS-627 | Dublettenprüfung von Logins und OpenID-Kennungen | ja | belegt |
|
||||||
|
| SwRS-628 | Mitarbeiterspeicherung mit Rechteprüfung und Personalakten-Ordnern | ja | belegt |
|
||||||
|
| SwRS-631 | Seriennummernwechsel am Stammblatt nur ohne aktive Klickzähler | ja | belegt |
|
||||||
|
| SwRS-637 | Berechtigungsprüfung der Kundengeräteverwaltung (Negativbefund) | nein | HYPOTHESE |
|
||||||
|
|
||||||
|
### A7 — Kommunikation & Organisation (9)
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| SyRS-712 | Freischaltung von Absenderadressen beim Mailversand | ja | belegt |
|
||||||
|
| SyRS-714 | Virtual Mail Assistant: Zugriffsschutz, verschlüsselte Zugangsdaten | ja | belegt |
|
||||||
|
| SyRS-719 | Tagesabschluss- und Aufgabenverwaltung (Berechtigungslogik) | ja | belegt |
|
||||||
|
| SwRS-738 | MailScanner-Profile: Rechteprüfung und Master-Key-Verschlüsselung | ja | belegt |
|
||||||
|
| SwRS-742 | Teams-CallRecords-Sync (Lizenzprüfung) | ja | belegt |
|
||||||
|
| SwRS-743 | Chat: mitgliedschaftsbasierte Zugriffskontrolle | ja | belegt |
|
||||||
|
| SwRS-744 | NexusNotification-Massenoperationen nur auf eigene Einträge | ja | belegt |
|
||||||
|
| SwRS-745 | ToDo-Fremdzugriffs-Rechte | ja | belegt |
|
||||||
|
| SwRS-747 | VideoPortal-Zuweisung nur mit Recht | ja | belegt |
|
||||||
|
|
||||||
|
### A8 — Web-Client Nexus & Service-Schnittstellen (20)
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| StRS-803 | Abgesicherte Service-Schnittstellen für Clients und Integrationen | ja | belegt |
|
||||||
|
| SyRS-811 | Policy-basierter Zugriffsschutz (LoginType, Rechte, Lizenz, Port) in Nexus | ja | belegt |
|
||||||
|
| SyRS-812 | Mehrstufiges Freigabewesen für Warenkörbe im WebCart | ja | belegt |
|
||||||
|
| SyRS-813 | Token-basierte Angebotsannahme (WebOffer) | ja | belegt |
|
||||||
|
| SyRS-814 | Online-Signatur von Dokumenten über einmaligen GUID-Link | ja | belegt |
|
||||||
|
| SyRS-815 | Sichtbarkeitsbeschränkung von Portal-Tickets auf den eigenen Kunden | ja | belegt |
|
||||||
|
| SyRS-817 | REST-API: JWT-Authentifizierung, Benutzerrechte, 401/403-Semantik | ja | belegt |
|
||||||
|
| SyRS-818 | Legacy-API: Pflicht-Authentifizierung per Ticket oder Access-Token | ja | belegt |
|
||||||
|
| SwRS-831 | UserRight-Autorisierungsfilter (Einzel-, Any-, All-Semantik) | ja | belegt |
|
||||||
|
| SwRS-832 | Hosted-only-Endpunkte über Lizenz CentronInternal | ja | belegt |
|
||||||
|
| SwRS-833 | JwtAuthController: OpenID-Connect-Login und Kontoverknüpfung | ja | belegt |
|
||||||
|
| SwRS-834 | 2FA-Code-Validierung über anonymen Bestätigungslink | ja | belegt |
|
||||||
|
| SwRS-835 | Rechteprüfung WEBACCOUNT_MANAGEMENT in der WebAccount-BL | ja | belegt |
|
||||||
|
| SwRS-836 | Interceptor-basierte Ticket-/Access-Token-Prüfung mit Sperren | ja | belegt |
|
||||||
|
| SwRS-839 | ClaimsService: Rechte/Web-Rechte/Lizenzen als Rollen-Claims | ja | belegt |
|
||||||
|
| SwRS-840 | PortHandler: getrennte Ports für Host- und Kundenportal-Bereich | ja | belegt |
|
||||||
|
| SwRS-841 | ReceiptCart-Guards: Lizenz, Web-Account-Recht, Kartenzugriff | ja | belegt |
|
||||||
|
| SwRS-842 | OrdererApproveCart: Pflichtfelder, Statuswechsel, Auftragserzeugung | ja | belegt |
|
||||||
|
| SwRS-845 | HelpdeskSearchBL: Expression-Filter für Web-Account-Logins | ja | belegt |
|
||||||
|
| SwRS-848 | Produktionsübersicht ohne deklarativen Autorisierungsschutz (Negativbefund) | nein | HYPOTHESE |
|
||||||
|
|
||||||
|
### A9 — Datenaustausch & Integrationen (10)
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| SyRS-911 | Zugriffsschutz der RMM-REST-Schnittstelle per Zugriffsschlüssel | ja | belegt |
|
||||||
|
| SyRS-912 | Integrations-Zugangsdaten nur mit Admin-Recht, verschlüsselte Ablage | ja | belegt |
|
||||||
|
| SyRS-918 | Kundenisolation beim Datenabruf über Web-Zugänge | ja | belegt |
|
||||||
|
| SwRS-931 | Zeitkonstante Prüfung des RMM-Zugriffsschlüssels | ja | belegt |
|
||||||
|
| SwRS-932 | RMM-Einstellungen: Rechteprüfung und AES-Verschlüsselung | ja | belegt |
|
||||||
|
| SwRS-936 | Idempotente DocBee-Zeitbuchungsübernahme mit Abrechnungssteuerung | ja | belegt |
|
||||||
|
| SwRS-937 | DocBee-Konnektor: Aktivierung über Lizenz/Recht | ja | belegt |
|
||||||
|
| SwRS-938 | docuFORM-Zugangsdaten mit Masterkey-Verschlüsselung | ja | belegt |
|
||||||
|
| SwRS-939 | Gerätezähler-Import von docuFORM (abrechnungsrelevant) | ja | belegt |
|
||||||
|
| SwRS-947 | Berechtigungsschutz Pflege Integrationsstammdaten (Negativbefund) | nein | HYPOTHESE |
|
||||||
|
|
||||||
|
### A10 — Produktion, Projekte, Statistik, Reporting (11)
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| SyRS-1010 | Lizenzgate für alle Produktionsfunktionen | ja | belegt |
|
||||||
|
| SyRS-1012 | Rechtebasierter Zugriff auf Statistiken und Kennzahlen | ja | belegt |
|
||||||
|
| SyRS-1014 | Ad-hoc-SQL-Ausführung nur mit Administrationsrecht | ja | belegt |
|
||||||
|
| SyRS-1017 | MSP-Nutzungsimport und Vertragsabgleich (Abrechnung) | ja | belegt |
|
||||||
|
| SwRS-1037 | Verkaufsstatistik: Rechte, Filiallimitierung, Web-Account-Schutz | ja | belegt |
|
||||||
|
| SwRS-1038 | Management-Info-Kennzahlen mit Filialbeschränkung | ja | belegt |
|
||||||
|
| SwRS-1039 | MSP-Import: Schemata, Duplikatschutz, verschlüsselte Zugangsdaten | ja | belegt |
|
||||||
|
| SwRS-1040 | MSP-Evaluation: Vertragsanpassung mit Historie | ja | belegt |
|
||||||
|
| SwRS-1041 | ReportEngine-Abfrageausführung mit Variablenersetzung | ja | belegt |
|
||||||
|
| SwRS-1044 | Beleg-Massenpreisupdate (Abrechnungsschutzregeln) | ja | belegt |
|
||||||
|
| SwRS-1045 | Artikel-/Kontenmassenupdate mit Logs | ja | belegt |
|
||||||
|
|
||||||
|
### A11 — Plattform & Querschnitt (7)
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| SyRS-1113 | Verbindungs- und Lizenzüberwachung per Heartbeat | ja | belegt |
|
||||||
|
| SyRS-1118 | Konfigurierbare KI-Provider-Anbindung mit abgesicherten Endpunkten | ja | belegt |
|
||||||
|
| SyRS-1121 | Arbeitsplatz-Anpassung über GUI-Profile und externe Tools | ja | belegt |
|
||||||
|
| SwRS-1134 | Protokollierung von Stundensatz-Zuschlagsänderungen | ja | belegt |
|
||||||
|
| SwRS-1141 | Validierung der KI-Endpunkt-URLs (SSRF-Schutz) | ja | belegt |
|
||||||
|
| SwRS-1142 | Verschlüsselte Ablage der KI-API-Schlüssel | ja | belegt |
|
||||||
|
| SwRS-1145 | Rechteprüfung für globale GUI-Profile | ja | belegt |
|
||||||
|
|
||||||
|
### A12 — Administration & Betrieb (6)
|
||||||
|
|
||||||
|
*SwRS-1233 ist oben unter A1, SwRS-1246 unter A2 gelistet (thematische Zuordnung).*
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| SyRS-1216 | PDF-Signierung als Systemdienst | ja | belegt |
|
||||||
|
| SyRS-1218 | Stundenzuschlagsmodelle für die Vertragsabrechnung | ja | belegt |
|
||||||
|
| SwRS-1234 | Mandantenspezifischer KI-Systemprompt nur mit Recht und Lizenz | ja | belegt |
|
||||||
|
| SwRS-1242 | Rechteprüfung/Verschlüsselung der PDF-Signierungseinstellungen | ja | belegt |
|
||||||
|
| SwRS-1243 | PDF-Signaturvorgang PKCS#7/SHA256/TSA | ja | belegt |
|
||||||
|
| SwRS-1245 | Serverseitige Rechteprüfung für Ad-hoc-SQL im SQL-Manager | ja | belegt |
|
||||||
|
|
||||||
|
## Selbstbewertung
|
||||||
|
|
||||||
|
### Mengengerüst und Abdeckung
|
||||||
|
|
||||||
|
- **Analysetiefe über das Inventar (96 Module):** 42 tief, 48 mittel, 6 flach (M28 Produktdaten-APIs, M29 TradePool, M37 Ticket-Projekte, M59 Legacy-Webservices, M65 generischer Datenim-/-export, M67 Gateway), **0 nicht analysiert**.
|
||||||
|
- **Mindestabdeckung erreicht:** Ja — jedes der 96 Inventarmodule hat mindestens eine Anforderung; kein Modul benötigte die Ausweichkennzeichnung `nicht analysiert`.
|
||||||
|
- **Anforderungen:** 413 gesamt (50 StRS, 122 SyRS, 241 SwRS), davon 16 Hypothesen (3,9 %), 21 nicht-funktionale mit ISO-25010-Merkmal, 198 risikorelevante (alle regelkonform belegt oder als Hypothese gekennzeichnet), 44 Konsolidierungskandidaten.
|
||||||
|
- **Belegbasis:** Alle PRIMÄR-Belege wurden im Quelltext bzw. SQL-Schema gelesen; für risikorelevante Anforderungen benennt der PRIMÄR-Beleg durchgängig die durchsetzende Stelle (Datei, Klasse, Methode, konkrete Prüfung).
|
||||||
|
|
||||||
|
### Wo der Beleg dünn war
|
||||||
|
|
||||||
|
- **Negativbefunde als Hypothesen:** Mehrere sicherheitsrelevante Hypothesen beruhen auf der Abwesenheit einer Prüfung (SwRS-637 AccountDeviceBL ohne Rechteprüfung, SwRS-848 `/production/overview` ohne Authorize-Policy, SwRS-947 Integrationsstammdaten, SwRS-1233 Mandantenspeicherung, SwRS-248 Kontoauszugs-Rechte). Abwesenheit ist statisch schwer beweisbar (die Prüfung könnte an nicht gesichteter Stelle liegen) — Verifikation durch Fachexperten bzw. Laufzeittest nötig.
|
||||||
|
- **Nur clientseitig belegte Regeln:** Pflichtfelder der Custom Properties (SwRS-636), MOVE_HELPDESK_TIMER (SwRS-542), Stundenzuschlags-Validierung (SwRS-1246), KI-Systemprompt-Recht (SwRS-1234) — die Regel existiert, ihre serverseitige Durchsetzung ist offen.
|
||||||
|
- **Nicht einsehbare Logik:** SocialMedia (Stored Procedures, SwRS-748), Expected-Events-Auswertung (außerhalb der Codebasis, SwRS-545), Reportserver-Ausführungsdienst (SwRS-1043).
|
||||||
|
- **Sehr große Einzeldateien nur auszugsweise:** `ReceiptBL.cs` (11.441 Zeilen), `InvoiceZugferdBL` (>2.000 Zeilen, kein Feld-für-Feld-Abgleich gegen EN 16931), `ContractEvaluationBL` (1.493 Zeilen), `OrderBalanceBL` (FlatrateBilling-Kern), DATEV-Formatgeneratoren.
|
||||||
|
- **Nur strukturell erfasst:** M59 Legacy-Webservices (~2.500 Dateien, exemplarisch WebAccount/ReceiptCart/Helpdesk vertieft), `Centron.Controls` (742+ Dateien), Gateway-Adapter.
|
||||||
|
|
||||||
|
### Sicherheits- und Qualitätsbefunde für die Neuimplementierung (Auswahl)
|
||||||
|
|
||||||
|
1. Passworthashing als ungesalzenes SHA1 über Codepage-1252-Bytes (`BasicAuthenticator`, TODO im Code) — im Zielsystem durch moderne KDF ersetzen; identischer Pfad für AppUser und WebAccounts.
|
||||||
|
2. Hartkodierte Geheimnisse: AES-Fallback-Schlüssel (`AESCryptoLogic`), finAPI-OAuth-Client-Credentials im Quellcode — Geheimnisverwaltung zwingend.
|
||||||
|
3. SQL-String-Konkatenation in ReportEngine (`ReportDataBL.ExecuteQuery`) und NexusNotifications — parametrisieren.
|
||||||
|
4. DSGVO-Komplettlöschung für Kunden/Lieferanten/Accounts wirft `NotImplementedException` (nur Kontaktpersonen-Löschung produktiv).
|
||||||
|
5. Keine gesichtete zentrale Schreibsperre für festgeschriebene Rechnungen (`IsFixed`) im SaveReceipt-Pfad; `RechKopf` ohne Unique-Index auf der Belegnummer — im Zielsystem als harte Invarianten spezifizieren.
|
||||||
|
6. `CanCloseHelpdesk()` liefert konstant `true` (kein Abschluss-Gate für offene Checklisten/RMA, nur TODO-Kommentar).
|
||||||
|
7. Schema-Drift: Telemetrie-Tabellen sowie `MasterDataList`/`ObjectExternalReferences` fehlen im Dump `SSMS_DB_SCHEMA.sql` — Schemaquelle und Migrationsskripte abgleichen.
|
||||||
|
8. Keine datenraumtrennende Mehrmandantenfähigkeit (eine DB, Mandant = Firmenstammsatz) — zentrale Architekturentscheidung für SaaS.
|
||||||
|
|
||||||
|
### Empfehlungen für Folge-Iterationen
|
||||||
|
|
||||||
|
1. **Verifikation der 16 Hypothesen**, vorrangig der fünf sicherheitsrelevanten Negativbefunde (Laufzeittest bzw. gezielte Suche nach der durchsetzenden Stelle).
|
||||||
|
2. **Systematischer Abgleich clientseitig geprüfter Rechte gegen serverseitige Durchsetzung** (SyRS-110): CentronRights.md-Rechteliste gegen alle WebServiceBL-Speicherpfade.
|
||||||
|
3. **Abrechnungskern vertiefen:** Positionsbildung des Abrechnungslaufs (VertragPos/VertragArtikel), OrderBalanceBL (Flatrate), Sammelrechnungen, DATEV-Formatdetails, Anzahlungsrechnungen, Provisionslogik.
|
||||||
|
4. **Legacy-Webservices (M59) flächig erfassen** — dort liegen vermutlich weitere fachliche Regeln und Rechteprüfungen; ebenso ServiceBoard-Zeiterfassung (Abrechnungsrelevanz) und Office/SharedDocument-Signaturpfad.
|
||||||
|
5. **E-Rechnung Feld-für-Feld** gegen EN 16931 prüfen (InvoiceZugferdBL, ebInterface, Gateway) — zugleich Konsolidierungsentscheidung für einen Generator.
|
||||||
|
6. **EDI-Distributor-Parser, EscalationBL.DoEscalation, AccountSearchBL, Alt-Migrationen (Anschrif→AccountAddresses)** sowie die ScriptMethods-SQL-Migrationsskripte als Quelle zusätzlicher DB-Regeln.
|
||||||
|
7. **Lizenzverwaltung (LicenseManager/LicenseGuids)** als eigenes Querschnittsthema erheben.
|
||||||
|
|
||||||
|
### Methodische Anmerkungen
|
||||||
|
|
||||||
|
- Die Anforderungszahlen je Modul in der Abdeckungstabelle enthalten anteilige Zuordnungen; die Summe über die Tabelle ist daher nicht identisch mit der Gesamtzahl 413.
|
||||||
|
- SwRS-240 wurde nicht vergeben (dokumentierte Nummernkreislücke, kein Inhaltsverlust).
|
||||||
|
- Die Hypothesenquote (3,9 %) liegt bewusst über null: Alle Aussagen ohne eindeutige Artefaktgrundlage wurden als Hypothese abgegrenzt statt behauptet; zusätzlich benennt die Selbstbewertung offene Punkte, die keiner Anforderung zugeordnet sind (nur hier, nicht in `Hypothesen.md`).
|
||||||
|
- Änderungshistorie (Commits) wurde nicht als Belegquelle herangezogen; KONTEXT-Belege stammen aus `docs\`, `CentronRights.md` und Code-Kommentaren (inkl. Ticketnummern, z. B. 168245/164153 beim MSP-Abgleich).
|
||||||
+211
@@ -0,0 +1,211 @@
|
|||||||
|
# Glossar
|
||||||
|
|
||||||
|
**System:** c-entron ERP-Suite | **Datum:** 2026-08-27
|
||||||
|
|
||||||
|
Domänenbegriffe, wie sie in StRS/SyRS/SwRS verwendet werden. Technische Bezeichner (Klassen, Tabellen, Spalten) stehen in Backticks.
|
||||||
|
|
||||||
|
| Begriff | Definition |
|
||||||
|
|---------|------------|
|
||||||
|
| 2FA | Zwei-Faktor-Authentifizierung; beim Login per RADIUS-Server oder E-Mail-Bestätigungslink. |
|
||||||
|
| Absender-Whitelist | Menge der zum Versand freigeschalteten Absenderadressen (Systemadressen + eigene Mitarbeiteradresse + `ApplicationSettingID.AllowedEmails`). |
|
||||||
|
| Access-Key (RMM) | Statischer, AES-verschlüsselt gespeicherter Schlüssel im Header `X-RMM-Access-Key` zur Autorisierung der RMM-REST-Schnittstelle. |
|
||||||
|
| Access-Token | Persistenter API-Schlüssel als Alternative zum Sitzungsticket (`AccessTokensController`, `AccessTokenWebServiceBL`), mit Zugriffsprotokoll (`AccessTokenLog`). |
|
||||||
|
| Account | Zentraler Geschäftspartner-Datensatz (Tabelle `Accounts`), der über Rollen gleichzeitig Kunde, Lieferant, Kontakt u. a. sein kann. |
|
||||||
|
| AccountDevice | Datenhaltung für sonstige Kundengeräte/Hardware (Tabelle `AccountDevices`) mit Soft-Delete, Log und Ticketverknüpfung. |
|
||||||
|
| AccountType / `AccountTypeToAccount` | Rollenzuordnung eines Accounts; verknüpft Account mit Kunden- (`AccountCustomers`) bzw. Lieferantendaten (`AccountSuppliers`). |
|
||||||
|
| `AESCryptoLogic` | c-entron-Hilfsklasse zur symmetrischen Verschlüsselung gespeicherter Geheimnisse (teils mit zentralem Masterkey aus der Konfigurations-DB). |
|
||||||
|
| Anrede / Abrede | Einleitungstext (`AN_*`) bzw. Schlusstext (`AB_*`) eines Belegs. |
|
||||||
|
| `ApplicationSettings` | Aktuelle Tabelle für typisierte Anwendungseinstellungen mit fester numerischer ID (Enum `ApplicationSettingID`). |
|
||||||
|
| AppUser | Internes ERP-Benutzerkonto eines Mitarbeiters (Mitarbeiterkonto) für die Anwendung, persistiert in Tabelle `Sichbenu`. |
|
||||||
|
| Artikel | Stammdatensatz eines Produkts/einer Dienstleistung (Tabelle `ARTIK`), identifiziert durch I3D und fachlich durch Artikelcode. |
|
||||||
|
| AssetManagement-Gerät | Extern (DocuBoard/River, AD/SNMP-Monitoring) synchronisierte Gerätedaten mit eigener Objektart `AssetManagementDeviceClass` (5101330). |
|
||||||
|
| AssetReason (QM-Grund) | Je Belegart gepflegter Rückgabe-/Reklamationsgrund mit Pflichtkennzeichen (`IsMandatory`). |
|
||||||
|
| AuthentificationKind | Pro Benutzer gespeichertes Anmeldeverfahren (CentronLogin/WindowsAuth/OpenIdConnectAuth), Spalte in `Sichbenu`. |
|
||||||
|
| AVV | Auftragsverarbeitungsvertrag (DSGVO Art. 28); im DSGVO-Modul als Vorlage und je Kunde als `OrderProcessingContract` verwaltet. |
|
||||||
|
| Barbeleg / Barrechnung (`IsCashAsset`) | Bar abgewickelter Beleg mit bruttobasierter Steuerrundung und eigenem Nummernkreis; vom Storno ausgeschlossen. |
|
||||||
|
| BatchId | Gruppenkennung mehrtägiger MyDay-Serieneinträge; 0 = Einzeltag. |
|
||||||
|
| Beleg | Geschäftsdokument der Verkaufs-/Einkaufskette (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholschein u. a.), technisch `IReceiptBase` mit Kopf und Positionen. |
|
||||||
|
| Belegart | Typ eines Belegs (`CentronObjectKindNumeric`, z. B. OrderClass, InvoiceClass); steuert Rechte, Nummernkreis und Weiterverarbeitungsziele über SpecificLogics. |
|
||||||
|
| Belegkette / Weiterverarbeitung (Forwarding) | Erzeugen eines Folgebelegs aus einem oder mehreren Quellbelegen mit Datenübernahme; Herkunft wird beidseitig gespeichert. |
|
||||||
|
| Belegkondition (`AssetCondition`) | Zahlungs-, Liefer- oder sonstige Kondition mit länderspezifischen Texten, Fälligkeitsart und Mindestbetrag. |
|
||||||
|
| Belegstatus Aktiv (`ReceiptState.Active`) | Einziger Belegzustand, in dem Massenänderungen an Belegpreisen zulässig sind. |
|
||||||
|
| Belegversion | Historisierte Ausprägung eines Belegs; Änderungen erzeugen Version+1, Vorversionen bleiben erhalten. |
|
||||||
|
| Belegzuordnung (`IsAssignedToAsset`) | Verweis einer Zeit auf eine Auftrags-, Lieferschein- oder Rechnungsposition (`AufPosI3D`/`LiefPosI3D`/`RechPosI3D`); macht die Zeit unveränderlich. |
|
||||||
|
| Bestellvorschlag | Automatisch berechnete Vorschlagsliste zu bestellender Mengen aus Auftragsbedarf, Mindestbestand, Bestand und Zulauf. |
|
||||||
|
| Betreuer (Adviser) | Bis zu sechs am Account hinterlegte Mitarbeiter (`Adviser1I3D`..`Adviser6I3D`), die für den Kunden verantwortlich sind. |
|
||||||
|
| BL / DAO / ILogic | Schichten: Business Logic (Entities/NHibernate), Data Access (Sessions/Mappings), clientseitige Logik-Schnittstelle mit BL- (Direkt-DB) und WS- (WebService) Implementierung. |
|
||||||
|
| CentronHosted | Autorisierungs-Policy, die Endpunkte auf von c-entron gehostete Installationen (Lizenz CentronInternal) beschränkt. |
|
||||||
|
| `CentronObjectKindNumeric` (ObjectKind) | Systemweite numerische Objektart-Enumeration/-Kennung (z. B. Account, HelpdeskClass, MasterDataListClass=25, AssetManagementDeviceClass=5101330) zur generischen Adressierung von Geschäftsobjekten. |
|
||||||
|
| ChangeLog | Generische Änderungshistorientabelle, adressiert über ObjectKind (Objektart) + ObjectI3D. |
|
||||||
|
| Chargeback | Rücklastschrift; negative Zuordnung, die auch geschlossene Rechnungen wieder öffnen darf. |
|
||||||
|
| Checkliste (`CentronChecklist`) | Hierarchische Aufgabenliste mit Punktzuständen (u. a. Open), generisch über ObjectKind/ObjectI3D an Objekte wie Tickets gebunden. |
|
||||||
|
| Check-out / Check-in | Exklusives Sperren eines Dokuments der Dateiablage zur Bearbeitung (mit Arbeitsstation) und Rückgabe als neue Version. |
|
||||||
|
| Click-Vertrag | Vertrag, der Gerätezählerstände (z. B. Druckseiten) als Differenzmenge abrechnet (`ContractExtraKind.ClickDevice`). |
|
||||||
|
| ConnectionManager | WPF-Werkzeug zur Pflege der `WebServiceConfig.xml` (DB-Verbindung, Proxy, AD, Zertifikate, Secret Key). |
|
||||||
|
| DataQualityService | Hintergrunddienst, der Datenbereinigungs- und Reparaturaufgaben in isolierten Einzelschritten ausführt. |
|
||||||
|
| DetachedFromOrigin | Kennzeichen einer Vertragsposition, dass die Verknüpfung zum erzeugenden Ursprungsauftrag gelöst wurde (verhindert Rückwirkungen bei Mengenänderungen). |
|
||||||
|
| Direktlieferung | Lieferung vom Distributor direkt an den Endkunden ohne eigenen Lagerdurchlauf (`AufPos.Direktlieferung`). |
|
||||||
|
| D!VE-Profil | Gespeicherte Exportvorgaben (Mandant, Rahmenvertrag, feste Zahlungs-/Rabatt-/USt-Werte) für den D!VE-Export (Entität `TelekomDiveProfile`). |
|
||||||
|
| DocBee | Externes Service-Management-/Vorgangssystem; angebunden über Webhooks und die DocBee-Konnektor-BLs. |
|
||||||
|
| DocSync | Mechanismus zur Bereitstellung von c-entron-Dokumenten/Verzeichnissen an eine externe Synchronisation, gefiltert nach Objektarten. |
|
||||||
|
| docuFORM | Fleet-/Print-Management-Server; liefert Druckgeräte und Seitenzähler über eine OAuth2-geschützte REST-API. |
|
||||||
|
| EAV | Entity-Attribute-Value: generisches Speichermuster mit typisierten Wertspalten je Attribut. |
|
||||||
|
| ebInterface | Österreichisches E-Rechnungsformat (hier Version 4.3). |
|
||||||
|
| EDI | Electronic Data Interchange — strukturierter elektronischer Belegaustausch mit Lieferanten/Distributoren (Bestellung, Bestellbestätigung, Lieferschein, Rechnung). |
|
||||||
|
| ElectronicSales (ES) | Webshop-System; dessen Kundengruppen/Rollen werden als lokale Caches (`EsCustomerGroup`/`EsRole`) geführt. |
|
||||||
|
| Empfänger-Bitmaske | Kodierung der Eskalationsempfänger einer Stufe als Summe von Empfänger-IDs in einer Integer-Spalte (`StageNReceivers`). |
|
||||||
|
| Eskalation | Zeitgesteuerte, bis zu dreistufige E-Mail-Benachrichtigung bei überfälligen Vorgängen (Tabellen `eskalationen`/`eskalationTypen`); die erreichte Stufe wird in `hlpdsk_requests.EscalationLevel` geführt. |
|
||||||
|
| Eskalationstyp | Konfigurierbares dreistufiges Regelwerk für die automatische Eskalation überfälliger Vorgänge, je Objektart bzw. Ticketpriorität: Wartestunden/Fristen je Stufe (`Hour1`-`3`), Geschäftszeitfenster, Sa/So-Flags und Empfängerkreise je Stufe. |
|
||||||
|
| EWS | Exchange Web Services; klassische Microsoft-Exchange-API, im System für Kalender- und Mailzugriff genutzt. |
|
||||||
|
| Expected Event | Definition eines je Wochentag erwarteten externen Ereignisses (z. B. Backup-Meldung) mit Textmustern zur Erfolgs-/Warn-/Fehlerklassifikation und Logeinträgen mit Ticketbezug. |
|
||||||
|
| Externes Tool | Konfigurierbares Fremdprogramm (Pfad + Argumente) mit @@Platzhalter@@-Ersetzung aus dem Fachkontext. |
|
||||||
|
| Externreferenz (`ObjectExternalReference`) | Generische Verknüpfung eines c-entron-Objekts (ObjectI3D + ObjectKind) mit einem Objekt eines Fremdsystems (ExternalReferenceType + ExternalReferenceID), z. B. DocBee. |
|
||||||
|
| Fälligkeit (`DueDate`/`FaelligAm`) | Aus der Ticketpriorität (Reaktionszeit in Stunden, Bürozeiten, Sa/So-Regeln) berechneter Zieltermin für die Ticketbearbeitung. |
|
||||||
|
| Festschreibung (`IsFixed`) | Unveränderlichkeits-Kennzeichen einer Rechnung (`RechKopf.IsFixed`=1), gesetzt mit Protokolleintrag. |
|
||||||
|
| FiBu-Export | Übergabe von Buchungs-/Stammdaten an Finanzbuchhaltungssysteme (DATEV, Abacus, Sage u. a.). |
|
||||||
|
| Filialbeschränkung | Rechtegesteuerte Einschränkung von Auswertungen auf die Filiale (Branch) des angemeldeten Mitarbeiters. |
|
||||||
|
| Filiale (Branch) | Standort/Niederlassung (organisatorische Einheit) eines Mandanten (Tabelle `Filiale`, `BranchDTO`); genau eine Filiale je Mandant ist Standard. `BranchI3D` bindet Rechtegruppen und restriktive Rechte an Standorte; „nur eigene Filiale"-Rechte binden den Belegzugriff an die Filiale des Benutzers. |
|
||||||
|
| finAPI | Externer Kontozugriffs-/PSD2-Dienst (live/sandbox.finapi.io), angebunden über REST v2 und WebForm. |
|
||||||
|
| Firmengruppe (`CompanyGroup`) | Konzernklammer über Konten; kann Preisliste, Sonderpreise und Leitweg-ID für Belege vorgeben. |
|
||||||
|
| Freigabewesen | Mehrstufiger Genehmigungsworkflow des Warenkorbs (Prüfer → Besteller) über die Zustandsmaschine `ReceiptCartState`. |
|
||||||
|
| Fremd-Todoliste | Recht (RIGHT_FREMDTODOLISTE), die ToDo-Listen anderer Mitarbeiter einzusehen; RIGHT_FREMDTODOLISTEVERWERFEN erlaubt das Verwerfen fremder ToDos. |
|
||||||
|
| Fremdware | Im RMA angenommener Artikel ohne eigenen Verkaufsbeleg; wird in ein RMA-Kundenlager (`StockKind.RmaCustomer`) eingebucht. |
|
||||||
|
| Gateway | Projekt `Centron.Gateway`: Sammlung von Formatadaptern (EDI, FiBu, SEPA, OpenTrans, ZUGFeRD, FinTS). |
|
||||||
|
| Gläubiger-ID (`SepaIdentificationNumber`) | SEPA-Gläubigeridentifikationsnummer des Mandanten (Mandator). |
|
||||||
|
| Gleitender EK | Mengen-gewichteter Durchschnitts-Einkaufspreis, der bei jedem Wareneingang fortgeschrieben wird (Alternative: Fest-EK, letzter EK; `ARTIK`-Feld `NoMixedEk`). |
|
||||||
|
| Globaler Zuschlag | Das per Einstellung `GlobalHourlySurchargeRateI3D` als systemweiter Standard markierte Zuschlagsmodell; nicht deaktivierbar. |
|
||||||
|
| Gruppen-Settings-Klasse | Serverseitige Klasse, die fachlich zusammengehörige Einstellungen gebündelt lädt, typisiert bereitstellt und speichert (z. B. `PdfSigningSettings`). |
|
||||||
|
| GUI-Profil | Gespeichertes Oberflächen-Layout (`CentronUiProfiles`), privat je Benutzer oder global (`IsGlobal`) für alle. |
|
||||||
|
| Gutschein (Voucher) | Barcode eines Gutscheinartikels; Status frei/ausgegeben/eingelöst über `GutscheinZuRechnung` abgeleitet. |
|
||||||
|
| Hauptlager | Implizites Basislager eines Artikels; im Code als Lager-I3D -1 geführt, Bestand in `ARTIK.Menge`. |
|
||||||
|
| Hauptposition (`IsMainItem`) | Die genau eine Position eines Stammblatts, die das Hauptgerät (Menge 1) repräsentiert. |
|
||||||
|
| Heartbeat | Zyklischer Client-Server-Ping (5 Minuten) zur Validierung von Sitzung und Lizenz. |
|
||||||
|
| Helpdesk-Status (`HelpdeskState`) | Frei konfigurierbarer Datensatz in `hlpdsk_status`, der die Lebenszyklusphase eines Tickets angibt; ein per AppSetting bestimmter Status gilt als „Abgeschlossen". |
|
||||||
|
| Helpdesk-Timer (Zeit) | Erfasste Arbeitszeit/Zeitbuchung eines Mitarbeiters auf einem Ticket (Tabelle `hlpdsk_timer`) mit Berechenbar-Flag (`Calculable`, steuert die Fakturierbarkeit) und optionaler Beleg-Zuordnung; Basis der Leistungsabrechnung. |
|
||||||
|
| Herstellercode (`ManufactorCode`/`ManufacturerCode`) | Artikelnummer des Herstellers; Zuordnungsschlüssel beim Preislistenimport. |
|
||||||
|
| Heuristik / MatchingRate | Herkunftskennzeichen und Güte einer automatischen Umsatz-Beleg-Zuordnung. |
|
||||||
|
| Hintergrunddienst (`ManagedBackgroundService`) | Im Webservice-Host laufender periodischer Job, dessen Aktivierung und Laufzeiten über die Tabelle `BackgroundServices` gesteuert/protokolliert werden. |
|
||||||
|
| I3D | „ID 3develop": systemweiter technischer Primärschlüssel (int IDENTITY) nahezu aller c-entron-Tabellen und -Entitäten; Fremdschlüsselspalten tragen das Suffix I3D. Wird auch als fester ID-Wert von Rechten verwendet. |
|
||||||
|
| Interne Rechnung | Rechnung nur mit Dienstleistungspositionen zum Gesamtwert 0,00, nummeriert aus eigenem Nummernkreis (InternalInvoice). |
|
||||||
|
| Inventur | Stichtagsbezogene Bestandszählung je Lager mit anschließender Buchbestandskorrektur; Voll- (Komplett-) oder Teilinventur. |
|
||||||
|
| Kalkulationsfaktor | Mandantenweiter Faktor (AppSetting `ArticleCalculationFactor`), mit dem Einkaufspreise bei Bewertung/Anzeige multipliziert bzw. dividiert werden. |
|
||||||
|
| Klickzähler / Seitenzähler (`DeviceClickCounter`) | Zähler eines Stammblatt-Geräts (z. B. Seitenzähler von Druckgeräten); Grundlage der verbrauchsbasierten Abrechnung von Click-/Managed-Print-Verträgen. |
|
||||||
|
| Kommissionierung | Zusammenstellen der Auftragspositionen im Lager mit Rückmeldung gepickter Mengen (`QuantityPicked`). |
|
||||||
|
| Kontenrahmen (`BookKeepingAccountSystems`) | Zuordnung Erlös-/Aufwandskonten zu Steuersätzen für den Export. |
|
||||||
|
| Kontingentrest-Mitnahme (`KontingentRestMitnehmen`) | Option, nicht verbrauchte Kontingente in die Folgeperiode zu übertragen. |
|
||||||
|
| Kontingentvertrag | Vertrag mit gebuchtem Leistungsvolumen (z. B. Stunden); Verbrauch wird gegen Buchungen (`VertragRechKopfZuordnung`) gerechnet. |
|
||||||
|
| Kontoauszug (`OnlineBankingAccountTransaction`) | Importierter Bankumsatz einer Onlinebanking-Konfiguration (FinTS/finAPI/Spreadsheet). |
|
||||||
|
| Kostenstelle / Kostenträger (`CostCenter`/`CostObject`) | Controlling-Stammdaten zur Belegzuordnung; Soft-Delete über State-Feld. |
|
||||||
|
| Kreditlimit | Kundenindividuelle Obergrenze des offenen Belegvolumens (netto/brutto); Überschreitung erfordert Bestätigung. |
|
||||||
|
| Kundensonderpreis (`KundenSonderpreise`) | Kunden-/warengruppenbezogene Preisregel mit Gültigkeitszeitraum und Preisbasis (`SpecialPriceKind`). |
|
||||||
|
| `Laenkenn` | Ländertabelle (Legacy-Name) mit Währung (`KursZuEur`), Vorwahl, MwSt-Art, Erlöskonten, Standardland-Kennzeichen. |
|
||||||
|
| Leitweg-ID | Adressierungskennung öffentlicher Auftraggeber in Deutschland; am Kunden bzw. dessen Firmengruppe gepflegt. |
|
||||||
|
| Löschprotokoll | Bei DSGVO-Löschung erzeugtes Textprotokoll („c-entron Löschprotokoll") aller entfernten personenbezogenen Angaben. |
|
||||||
|
| Mahnlauf | Ein Ausführungsvorgang des Mahnwesens; protokolliert je Rechnung in Tabelle `Mahnlauf` unter fortlaufender MahnLaufNr. |
|
||||||
|
| Mahnsperre (DunningStop) | Kennzeichen/Zeitraum auf Kunde oder Rechnung, das die Aufnahme in Mahnvorschläge verhindert. |
|
||||||
|
| Mahnstufe (DunningLevel) | Eskalationsstufe einer überfälligen Rechnung (je nach Sicht 0–3 bzw. 1–3), gespeichert in `RechKopf.Mahnstufe` mit Datum und Bearbeiter je Stufe. |
|
||||||
|
| Mailing | Kampagnenbezogener Massenversand (E-Mail/SMS) mit personalisierten Empfängertexten und Versandkennzeichen. |
|
||||||
|
| MailTemplateReference | Eindeutige Identifikation einer Mail-Vorlage über ObjectKind, SubObjectKind, ObjectI3D und TemplatePrio (Tabelle `MailVorlagen`). |
|
||||||
|
| Mandant (Mandator) | Rechtlich/organisatorisch eigenständige Firma innerhalb einer c-entron-Installation mit eigenen Stammdaten (Anschrift, Bankverbindungen, USt-ID, Logos) und Belegnummernkreisen (Tabelle `Mandant`, Entität Mandator); zugleich die eigene Firma des Systemhauses als Absender-Stammdaten für Belege. Getrennte Datenhaltung je Firma (MandantID in `Sichbenu`), wobei alle Mandanten eine Datenbank teilen; nicht zu verwechseln mit SaaS-Mandantentrennung. |
|
||||||
|
| Mandatsreferenz (`AuthorizationNumber`) | Eindeutige Kennung des SEPA-Mandats an der Bankverbindung. |
|
||||||
|
| Maschinenart (`ProductionMachineKind`) | Klassifikation von Produktionsmaschinen; trägt wiederverwendbare Arbeitsschrittbeschreibungen (`ProductionMachineKindStepsDescription`). |
|
||||||
|
| Massenupdate-Vorlage (`MassUpdateTemplate`) | Benannter Massenänderungslauf mit Einzelpositionen (Items) je Zielobjekt, Ausführungsstatus und Fehlergrund. |
|
||||||
|
| Masterkey / Masterschlüssel | Zentraler mandantenweiter symmetrischer Schlüssel aus der Konfigurations-DB (`CentronConfigurationDbBL`; „Hotline-Masterkey") zur AES-Ver-/Entschlüsselung gespeicherter Geheimnisse, z. B. der Zugangsdaten des Passwortmanagers sowie der Postfach-Passwörter und Client-Secrets der VMA-Profile. |
|
||||||
|
| MCP-Tool | Werkzeug des Model-Context-Protocol-KI-Assistenten, dessen Nutzung telemetrisch gezählt wird (`McpToolUsageTelemetry`). |
|
||||||
|
| Microsoft Graph | Moderne Microsoft-365-API; alternativer Mail-Transport (GraphMail) und Quelle der Teams-Anrufdaten (CallRecords). |
|
||||||
|
| Mindestpreis (`MinPrice`) | Artikeluntergrenze für den Netto-VK; Unterschreitung erfordert Recht ALLOW_IGNORE_MINIMUM_PRICE. |
|
||||||
|
| Mitarbeiter (Employee) | Personalstammsatz (Tabelle `Personal`) mit Kürzel (`ShortSign`), Filiale (`BranchI3D`) und Personalakten-Ordnern. |
|
||||||
|
| MSP | Managed-Service-Provider — Systemhaus, das IT-Betrieb für Kunden übernimmt; Zielgruppe von c-entron. |
|
||||||
|
| MSP-Collector | Konfigurierte Importschnittstelle zu einem Managed-Service-Lieferanten (z. B. Veeam, Octopus, ArrowSphere), die Nutzungs-/Abrechnungsdaten abholt. |
|
||||||
|
| MSP-Evaluation | Positionsweiser Abgleich importierter Lieferantenabrechnungen mit Kundenvertragspositionen inklusive Übernahmeentscheidung (Menge/Preis/ignorieren). |
|
||||||
|
| Nebenlager | Zusätzliches, in `Warehouses` definiertes Lager; Artikelbestand je Nebenlager in `NebenlagerArtikel`. |
|
||||||
|
| Nexoware Smartflow (CPra) | Externer Formular-/Workflow-Dienst; c-entron erzeugt vorbefüllte Webhook-Links. |
|
||||||
|
| NexusNotification | Persönliche Benachrichtigung im Nexus-Web-Client mit getrennten Zuständen `IsSeen` (Badge) und `IsRead` (gelesen), gepusht über SignalR-Hub. |
|
||||||
|
| Normierung (`RechnungNormieren`) | Tagesanteilige Berechnung angebrochener erster/letzter Abrechnungsperioden auf Kalendermonat/-quartal/-jahr. |
|
||||||
|
| Nummernkreis (`NumberGroup`) | Zentraler konfigurierbarer Zähler für fortlaufende Nummern (Tabelle `Nummernkreis`), je Belegart/Mandant/Filiale zur Vergabe eindeutiger Belegnummern sowie für Account-, Kunden- und Lieferantennummern (via `NumberGroupBL.GetNextNumber`). |
|
||||||
|
| OnlinePdfDocument | Per GUID adressiertes, einmalig signierbares PDF-Dokument (`DsgvoBL`); nach Bestätigung gelöscht. |
|
||||||
|
| OpenTRANS 2.1 | XML-Standardformat für Geschäftsbelege; Standardformat des Bestellversands. |
|
||||||
|
| OPOS | Offene-Posten-Liste: aktive Rechnungen abzüglich Zahlungen und verrechneter Gutschriften je Kunde; Versandform „Kontoauszug". |
|
||||||
|
| Pauschalabrechnung (FlatRate) | Auftragbasierte Pauschalfaktura; zugehörige Zeiten sind von der Einzelzeitabrechnung ausgeschlossen (`IsFlatRateItem`). |
|
||||||
|
| PDF/A | ISO-Normfamilie für Langzeitarchivierung von PDF; im System als Konformitätsstufen PDF/A-1a bis PDF/A-3b sowie PDF/X wählbar. |
|
||||||
|
| Personalakte | Automatisch angelegte Dokumenten-Ordnerstruktur je Mitarbeiter (Zertifikate, Verträge, Gesprächsnotizen usw.). |
|
||||||
|
| PLM (`ProductLifecycleInformation`) | Product Lifecycle Management — Lebenszyklusdatensatz einer verkauften Lizenz/eines Abos (Quelle meist Rechnungsposition) mit Laufzeit (`StartDate`/`EndDate`), Kunde und Angebotsstatus; das Verwerfen des zugehörigen ToDos deaktiviert die Lizenz und wird protokolliert. |
|
||||||
|
| `PORTRECH` / `PORTWARE` | Flag-Tabellen für bereits an die FiBu exportierte Kunden- bzw. Lieferantenbelege. |
|
||||||
|
| Preisliste (VK1–VK4) | Vier Verkaufspreisfelder je Artikel; `Customer.PriceList` wählt den anzuwendenden VK. |
|
||||||
|
| Produktfamilie (`ProductFamily`/`-Group`) | Fachliche Gruppierung von Artikeln im PLM zur Zuordnung von Lebenszyklusdaten. |
|
||||||
|
| Produktionsauftrag (`ProductionOrder`) | Fertigungsauftrag, der zwingend auf einen Verkaufsauftrag (`OrderI3D`/`OrderNumber`) verweist und Arbeitsschritte (`ProductionOrderItems`) bündelt. |
|
||||||
|
| Produktionsschritt / Werkschritt (`ProductionOrderItem`) | Einzelner Arbeitsschritt eines Produktionsauftrags mit Maschinenart/Maschine, Soll-/Ist-Menge und Zustand (`ProductionOrderItemState`: Offen/OpenNotStarted, In Bearbeitung, Beendet/Finished). |
|
||||||
|
| Produktmatrix | Bewertungsraster Kunde × Produkt mit 4 Potenzialstufen und Änderungshistorie. |
|
||||||
|
| QmNotification | Dreistufiger Benachrichtigungsmodus je Belegart: keine / Nachfrage / immer. |
|
||||||
|
| Recht | Einzelberechtigung mit fester I3D (Tabelle `Sichrech`), im Code über `UserRightsConst` referenziert. |
|
||||||
|
| Rechtegruppe | Gruppe (Tabelle `Sichgrup`), der Rechte (`Sichtrus`) und Benutzer (`Sichmemb`) zugeordnet werden. |
|
||||||
|
| ReportEngine / ReportData | Neuere Berichtsverwaltung auf FastReport-Basis (XML im DB-Feld `Report`) mit Gruppen (`ReportGroup`, GUID je Belegart) und Abfragen (`ReportDataQuery`). |
|
||||||
|
| Reports (Alt-Tabelle) | Legacy-Berichtsspeicher (`dbo.Reports`, deutsche Spalten) mit eigener BL — Parallelbestand zur ReportEngine. |
|
||||||
|
| Restriktives Recht | Recht, das Befugnisse einschränkt statt erweitert (z. B. MANAGE_RIGHTS_ONLY_OWN_BRANCH, „nur eigene"-Rechte). |
|
||||||
|
| Result / `Result<T>` | Einheitliches Rückgabemuster der Logikschicht mit Status (Success/Error), Meldung und Nutzdaten statt Exceptions. |
|
||||||
|
| Richtlinie (Guideline) | Passwortmanager-Regelwerk, das je Kunde und Mitarbeiter feingranulare Zugriffsrechte (Bitflags) auf Zugangsdaten definiert. |
|
||||||
|
| Riverbird / RiverDivo | RMM-Produkt bzw. dessen c-entron-Anbindung (Namespace `RiverDivo`); Legacy-Zugang per Ticket, neuer Zugang per RMM-Access-Key. |
|
||||||
|
| RMA | Return Merchandise Authorization — Retourenvorgang mit Statushistorie je reklamiertem Artikel. |
|
||||||
|
| RMM | Remote Monitoring & Management — Fernüberwachungs-/Verwaltungssystem eines Managed-Service-Providers (hier v. a. Riverbird). |
|
||||||
|
| SelfCare-Formular / WebForm | Konfigurierbares Kundenformular, das über einen GUID-Link mit Ablaufdatum extern (ServiceBoard-Web) ausgefüllt wird. |
|
||||||
|
| SendBack | RMA-Rücksendung defekter Ware an den Lieferanten (`RmaSendBack`). |
|
||||||
|
| SendForth | RMA-Vorab-/Ersatzlieferung an den Kunden (`RmaSendForth`). |
|
||||||
|
| SEPA-Mandat (`SepaContract`) | Lastschriftmandat mit Status Draft/Accepted/Declined/LinkExpired und Online-Unterschriftsprozess; als Signaturdokument mit Pflicht-Bankdaten (Bankname, IBAN, BIC) über die DocumentSigning-Seite erteilt. |
|
||||||
|
| Seriennummer / Barcode | Einzelstück-Identifikation eines Artikels (Tabelle `Barcode`, Entitäten `BarCode`/`BarCode2`) mit eigenem Statuslebenszyklus (`BarcodeState`). |
|
||||||
|
| Seriennummernpflicht (`ScanBarcode`) | Artikelkennzeichen (`ARTIK.BarcodeScanen`), das die Bestandsführung auf Seriennummernzählung umstellt. |
|
||||||
|
| ServiceBoard (SBO) | Web-Frontend der Suite; je nach Sicht browserbasierter Mitarbeiter-Arbeitsbereich für Tickets, Planung und Zeiterfassung (Lizenz ServiceBoardWebDev) sowie Zugangspunkt für Kunden-/Technikerzugriffe (Formulare, Umfragen, Tickets); Basis-URL in den Einstellungen. |
|
||||||
|
| SETTINGS-Recht | Benutzerrecht `UserRightsConst.Administration.SETTINGS`; Voraussetzung für die Pflege von Integrations-/Systemeinstellungen. |
|
||||||
|
| Siegel / Siegelbruch | Schutzmechanismus des Passwortmanagers: versiegelte Zugangsdaten dürfen nur mit SealBreak-Recht, Begründung, Protokoll und E-Mail-Meldung geöffnet werden. |
|
||||||
|
| SimpleUrl / WebLink | Zwei getrennte Datenhaltungen für objektbezogene URLs; WebLinks besitzen zusätzlich Gruppen und ausführbare Aktionen (`WebLinkAction`). |
|
||||||
|
| Skonto-Ausschluss (`NoEarlyPaymentDiscountAllowed`) | Positionskennzeichen, das die Position aus der Skontobasis herausnimmt (NotDiscountable-Summen). |
|
||||||
|
| Soft-Delete | Logisches Löschen per Kennzeichen statt physischem Entfernen des Datensatzes; je nach Modul über Statusfeld (State=0) oder über `IsDeleted`/`DeletedByI3D`/`DeletedDate`. |
|
||||||
|
| Sondervereinbarung (SpecialAgreement, Projektpreis) | Kunden-, projekt- oder auftragsbezogenes Preisabkommen: verkaufsseitig eine Preisliste mit eigenen EK/VK bzw. prozentualen Reduktionen, Artikelpositionen und zugeordneten Kunden; einkaufsseitig eine auftrags-/projektbezogene Einkaufspreisabsprache (`SondervereinbarungI3D`) mit Gültigkeitsdatum, die vom Standard-EK-Verfahren ausgenommen ist. |
|
||||||
|
| Staffelpreis (`ArticleVolumePrices`) | Mengenabhängige EK/VK-Preise eines Artikels. |
|
||||||
|
| Stammblatt (MasterDataList) | Gerätedatensatz des Kunden für abrechnungsrelevante Geräte (v. a. Drucker/Kopierer) mit Hauptposition, Seriennummer, Klickzählern und Click-Vertragszuordnung; Träger der Gerätezähler; UI-Bezeichnung der Objektart `MasterDataListClass` (25). |
|
||||||
|
| `Stammdat` | Legacy-Einstellungstabelle (Zugriff über Enum `AppSettingsConst`); für neue Einstellungen gesperrt. |
|
||||||
|
| Standardmandant | Der genau eine Mandant mit `Default`=true; er kann nicht gelöscht/deaktiviert werden und dient als Fallback (z. B. für Logos). |
|
||||||
|
| Stemming | Rückführung von Wörtern auf ihre Stammform (`GermanAnalyzer`, angelehnt an Lucene.NET GermanStemmer). |
|
||||||
|
| Storno | Aufhebung einer Rechnung als neue Belegversion mit Status „storniert" und genullten Mengen; nur mit Recht RIGHT_RECHNUNGSTORNIEREN. |
|
||||||
|
| Stundenzuschlagsmodell (`HourlySurchargeRate`) | Satz von Zeitfenstern mit prozentualen Zuschlägen je Wochentag/Feiertag, der Verträgen zur Abrechnung von Arbeitszeiten zugeordnet wird. |
|
||||||
|
| Sync-Mitglied | Mitarbeiter, dessen Teams-Anrufe beim Graph-CallRecords-Sync in das Anrufjournal übernommen werden. |
|
||||||
|
| Tag | Normalisiertes (lowercase, getrimmt) freies Schlagwort (Tabelle `Tags`), Objekten z. B. Tickets über `TicketTags` zugeordnet. |
|
||||||
|
| Tagesabschluss (`MyDayFinalizedDay`) | Verbindliche Bestätigung eines Mitarbeiters, dass sein Arbeitstag in MyDay vollständig erfasst ist; fehlende Abschlüsse lösen Erinnerungen und Teamleiter-Eskalation aus. |
|
||||||
|
| TAPI | Telephony API; Windows-Telefonie-Schnittstelle, über die der Client Anrufe meldet, die als `PhoneCall` protokolliert werden. |
|
||||||
|
| TaskManager-Aufgabe | Wiederkehrende Aufgabe (`TaskManagementTask`) mit Wiederholungsregel (Recurrence) und Aktion, z. B. automatischer Ticketanlage (`TaskManagementHelpdeskAction`). |
|
||||||
|
| Teilkommission | Kommissionierung einer Teilmenge eines Auftrags (`PartialCommissionOrder`). |
|
||||||
|
| Telekom D!VE | Telekom-Partnerportal/Marktplatz; c-entron exportiert Angebote als D!VE-XML. |
|
||||||
|
| Telemetrie-Bucket | Zeitfenster (`BucketStartUtc`), auf das Nutzungsereignisse aggregiert werden; gespeichert wird nur ein Zähler je Schlüsselkombination. |
|
||||||
|
| Terminanfrage (`AppointmentRequest`) | Vorgang, bei dem einem Kunden mehrere Terminvorschläge (`AppointmentProposal`) angeboten werden; Antwort erfolgt über eine Guid und schaltet den `RequestState` weiter. |
|
||||||
|
| Textbaustein (TextModule) | Wiederverwendbarer Anrede- oder Schlusstext je Belegart/Helpdesk-Kontext mit @@-Platzhaltern; Auflösung kundenspezifisch vor benutzerspezifisch vor global. |
|
||||||
|
| Ticket (Authentifizierung) | Serverseitig gespeichertes/verwaltetes Sitzungs-Token mit Ablaufdatum, ausgestellt nach erfolgreicher Anmeldung (`TicketBL`); wird bei jedem Legacy-Aufruf validiert und verlängert. Nicht zu verwechseln mit dem Helpdesk-Ticket. |
|
||||||
|
| Ticket (Helpdesk-Fall) | Kundenbezogener Service-/Support-Vorgang in Tabelle `hlpdsk_requests` (Entität `Helpdesk`/`HelpdeskCompact`), auch im ServiceBoard/Kundenportal sichtbar; „Ticket" und „Helpdesk(-Fall)" werden in der Codebasis synonym verwendet. |
|
||||||
|
| Ticket-Projekt | Bündelung von Tickets mit eigenem Nummernkreis, Aufgaben, Abhängigkeiten, Nachrichten und Logs (`TicketProject`; `hlpdsk_requests.ProjectHelpdeskI3D`). |
|
||||||
|
| TimerBilling | Abrechnung erfasster Helpdesk-Zeiten (HelpdeskTimer) über Aufträge/Rechnungen. |
|
||||||
|
| ToDo / Wiedervorlage | Aus Geschäftsobjekten (Belege, Verträge, Tickets, PLM-Lizenzen, Geburtstage, Videozuweisungen) erzeugter Aufgabeneintrag mit Read-/Discarded-Status. |
|
||||||
|
| Toleranzfrist (`DaysToTolerate`) | Konfigurierte Anzahl Tage, innerhalb derer ablaufende Lizenzen Wiedervorlagen (ToDos) erzeugen. |
|
||||||
|
| TOTP-PIN | Zeitbasiertes Einmalpasswort (Google-Authenticator-Verfahren) gegen den in `Sichbenu.TwoFactorAuthKey` hinterlegten Schlüssel. |
|
||||||
|
| TradePool | Separater, per XML befüllter Katalog von Handelsartikeln (`TradeArticles`) mit Klassenhierarchie; Nutzung unklar. |
|
||||||
|
| TSA | Time Stamping Authority; Zeitstempeldienst (RFC 3161), der Signaturen einen beglaubigten Zeitpunkt hinzufügt. |
|
||||||
|
| Umfrage-Instanz | Antwortleere Kopie einer Umfragevorlage (`SurveyProcessTemplate`) mit Status Open, Objektbezug und verschlüsseltem Zugriffslink. |
|
||||||
|
| UniqueId (`MyDayWorkItem`) | Fachlicher Eindeutigkeitsschlüssel (Type + ObjectI3D bzw. Type + I3D) zur Deduplizierung automatisch erzeugter Zeiteinträge. |
|
||||||
|
| Update-Benachrichtigungsart (`UpdateAvailableNotificationKind`) | Einstellung, die die Zielgruppe von Update-Hinweisen festlegt (keine, Administratoren, ausgewählte Mitarbeiter, alle). |
|
||||||
|
| Verknüpfungsnummer (`ConnectionNumber`) | Fortlaufende Nummer, die mehrere Tickets zu einer Gruppe (`HelpdeskConnections`) bündelt. |
|
||||||
|
| Vertragssonderpreis (`ContractSpecialPrice`) | Preisregel aus einem Vertrag; hat Vorrang vor Kundensonderpreisen. |
|
||||||
|
| VMA (Virtual Mail Assistant) | Mail-Eingangs-Scanner (MailScanner), der Postfächer über Profile abruft und eingehende Mails Workflows zuführt; lizenz- (MailScannerNET) und rechtegeschützt (ACCESS_VMA_MODULE). |
|
||||||
|
| Volltextindex | Datenbanktabelle `ObjectFulltextIndex` mit gestemmten Termen je Objekt; Suche = UND-Verknüpfung von Präfixtreffern. |
|
||||||
|
| Vorab-/Nachberechnung (Billingadvance/Billingarrear) | Abrechnung vor Beginn bzw. nach Ende des Leistungszeitraums. |
|
||||||
|
| Vorgang (DocBee) | Ticket-Äquivalent in DocBee; referenziert über `ObjectExternalReference` mit Typ „DocBee". |
|
||||||
|
| Vorlagen-Fallback | Auflösungsreihenfolge einer Mail-Vorlage: Kunde (Account) → Mitarbeiter → Filiale (Branch) → global → Systemstandard. |
|
||||||
|
| Warenkorb (`ReceiptCart`) | Web-Warenkorb, technisch ein ReceiptOffer (`AngKopf`) mit `IsCart`=true und CartState (`ReceiptCartState`). |
|
||||||
|
| Web-Account (WebAccount) | Externes Portal-Konto/Kundenlogin (Self-Service-/Webportal, ServiceBoard) eines Kunden-/Account-Ansprechpartners, persistiert in Tabelle `WebAccounts`; eigener Login-Typ „Webaccount" mit eigenem Rechtesystem (WEBRIGHT_*, Enum `WebAccountRightsConst`), abgegrenzt vom internen Mitarbeiter-Login (AppUser); besitzt keinen Mitarbeiterkontext und unterliegt Kundenisolation (darf nur Daten des eigenen Kunden sehen). |
|
||||||
|
| Web-Receipt / Web-Angebot | Per Token im Browser bereitgestellter Beleg (Angebot) mit eigenem Zustandsmodell `WebReceiptState` (Annahme/Ablehnung/Änderungswünsche). |
|
||||||
|
| Web-Recht | Berechtigung eines Web-Accounts (Enum `WebAccountRightsConst`, z. B. WEBRIGHT_WEBCART2_CHECK_CART); unabhängig von den Mitarbeiterrechten (`UserRightsConst`, int-I3Ds). |
|
||||||
|
| Werbesperre (`AdvertisingNotAllowed`) | Kennzeichen am Konto, dass keine Werbung zugesendet werden darf. |
|
||||||
|
| XRechnung / XInvoice | Deutsche EN-16931-konforme E-Rechnungs-XML-Ausprägung; erfordert BuyerReference (Leitweg-ID) für B2G. |
|
||||||
|
| Zeit-Signatur | Grafische Kundenunterschrift zu genau einer Zeit (Tabelle `hlpdsk_timer_signature`); Flag `IsSigned` am Timer. |
|
||||||
|
| Zugangsdaten (Access Data) | Im Passwortmanager verwaltete Benutzername/Passwort-Kombinationen für Kundensysteme (Hotline-Custom-Items mit Custom-Properties). |
|
||||||
|
| ZUGFeRD | Hybrides E-Rechnungsformat: E-Rechnungs-XML eingebettet in PDF/A; Versionen 1.0 bis 3.0.1 (XInvoice) im System wählbar; im EDI-Rechnungsimport unterstützt. |
|
||||||
|
| Zulauf | Bereits bestellte, noch nicht gelieferte Menge (Intake) je Artikel/Lager. |
|
||||||
|
| Zuordnung (`TransactionAssignment`) | Verknüpfung Bankumsatz ↔ Beleg mit zugewiesenem Betrag, Heuristik und Buchungsflags. |
|
||||||
|
| Zusatzfeld (`ModuleCustomProperty`) | Konfigurierbares kundenindividuelles Feld je Objektart mit Datentyp, Pflicht- (`IsMandatory`) und Versiegelungskennzeichen (`Sealable`); Werte in EAV-Tabelle `ModuleCustomPropertyValues`. |
|
||||||
|
| Zwischenrechnung | Codierter Zuordnungstyp in `VertragRechKopfZuordnung` für abweichende Kontingentintervalle (`DifferContingentInterval`: none/headMinor/interimMinor/headMajor/interimMajor). |
|
||||||
+24
@@ -0,0 +1,24 @@
|
|||||||
|
# Hypothesen
|
||||||
|
|
||||||
|
**System:** c-entron ERP-Suite | **Datum:** 2026-08-27
|
||||||
|
|
||||||
|
Diese Datei enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung (`Status: HYPOTHESE`) aus StRS.md, SyRS.md und SwRS.md — deckungsgleich mit den Inline-Markierungen. Je Eintrag die offene Frage, deren Beantwortung die Hypothese bestätigen oder verwerfen würde.
|
||||||
|
|
||||||
|
| ID | Ebene | Titel | Offene Frage (fehlende Information) |
|
||||||
|
|----|-------|-------|-------------------------------------|
|
||||||
|
| SyRS-110 | SyRS | Serverseitige Durchsetzung aller im WPF-Client geprüften Rechte | Existiert für jedes clientseitig geprüfte Recht (insb. UI-Sichtbarkeitsrechte wie EDIT_GLOBAL_PROFILES) eine korrespondierende serverseitige Prüfung in BL oder Webservice? |
|
||||||
|
| SyRS-1119 | SyRS | Zentrale Dateiablage mit Versionierung und Sperrmechanismus | Die serverseitige Durchsetzung (Ablehnung eines zweiten Check-outs, Versionszählung) in der Dokumenten-BL (FileManagement) wurde nicht gelesen; belegt ist nur der Client-Vertrag (ICentronFileSystemConnector). |
|
||||||
|
| SwRS-119 | SwRS | Alt-Passwortverwaltung (PasswordManagementArea) mit Zugriffsprotokoll, aber ohne wirksame Verschlüsselung | Wird PasswordManagementKeyword.Password von einem anderen (Alt-)Client verschlüsselt befüllt, oder liegen die Werte im Klartext vor? Warum wird beim Lesezugriff der ActionType "Create" geloggt? |
|
||||||
|
| SwRS-248 | SwRS | Serverseitige Durchsetzung der Kontoauszugs-Rechte (20800147–20800151) | Existiert eine hier nicht gefundene serverseitige Prüfung (z. B. in einer Webservice-Fassade/Modulfreischaltung), oder sind die Rechte 20800147–20800151 tatsächlich nur UI-wirksam? |
|
||||||
|
| SwRS-350 | SwRS | Durchsetzung der Werbesperre beim Mailingversand | Gibt es im Versandpfad (Mail-Dispatcher/UI-Auswahl) eine erzwungene Filterung auf Werbesperre, oder verlässt sich das System allein auf die manuelle Filterwahl der Empfängerselektion? |
|
||||||
|
| SwRS-354 | SwRS | Manueller Statuswechsel auf „storniert" für Nicht-Rechnungsbelege | Über welchen UI-/BL-Pfad werden Angebote/Aufträge/Lieferscheine storniert, und welche Prüfungen (Rechte, Bestandsrückbuchung, Folgebelege) werden dabei erzwungen? |
|
||||||
|
| SwRS-451 | SwRS | TradePool-Artikelimport aus XML-Dateien | Wird der TradePool produktiv noch genutzt und was ist der fachliche Zweck (kundenübergreifende Handelsbörse vs. interner Katalog)? Kein aufrufendes UI-Modul im Cluster gefunden. |
|
||||||
|
| SwRS-545 | SwRS | Automatische Auswertung eingehender Meldungen gegen Expected Events | Welche Komponente (vermutlich ein externer Dienst oder RiverDivo-Integration) wertet eingehende Meldungen gegen die MessageContains*-Muster aus und erzeugt ExpectedEventLogEntries bzw. Tickets? |
|
||||||
|
| SwRS-637 | SwRS | Berechtigungsprüfung der Kundengeräteverwaltung | Wird der Zugriff auf die Geräteverwaltung an anderer Stelle (WPF-Client-Menürechte, API-Gateway, Lizenz) durchgesetzt, oder ist die Operation tatsächlich ungeschützt? |
|
||||||
|
| SwRS-740 | SwRS | Getrennte Persistenz von Betreff-Schalter und Betreff-Text der Outlook-Termine | Ist die Nutzung von HolidayRequestedEmailSubject als Bool-Schalter beabsichtigte Wiederverwendung eines freien Schlüssels oder ein Copy-Paste-Fehler, und liest ein anderes Modul denselben Schlüssel mit Urlaubs-Semantik? |
|
||||||
|
| SwRS-748 | SwRS | Social-Media-Interaktionen über Datenbankprozeduren | Welche Regeln (Berechtigung, Dubletten, Benachrichtigung) implementieren die Stored Procedures AddCommentToASocialMediaAction/LikeAStreamOrAction, und ist socialKind = 0 für Actions ein Fehler? |
|
||||||
|
| SwRS-848 | SwRS | Fehlender Seitenschutz der Produktionsübersicht | Existiert an anderer Stelle (Middleware, Host-Konfiguration, Reverse Proxy) ein Schutz der Route /production/overview, oder ist die Seite tatsächlich anonym erreichbar? |
|
||||||
|
| SwRS-947 | SwRS | Berechtigungsschutz für die Pflege von Integrationsstammdaten (D!VE-Profile, ES-Kundengruppen) | Greift für v1/telekom-dive und v1/integrations/es-* eine globale Autorisierung (z. B. Authentifizierungspflicht in Centron.Host/Middleware) oder genügt heute jede gültige Anmeldung für Schreibzugriffe? |
|
||||||
|
| SwRS-1043 | SwRS | Reportserver: automatisierter Reportversand per E-Mail über Aufgaben | Wo (welcher Dienst/Serverprozess) führt die geplanten Aufgaben aus und mit welcher Render-/Mail-Logik — der ausführende Code wurde im Cluster nicht gefunden. |
|
||||||
|
| SwRS-1147 | SwRS | Doppelte Entitätsklassen für den Firmenmandanten (Tabelle Mandant) | Ist „Mandant" ausschließlich Belegabsender (eigene Firma) ohne datenraumtrennende Mehrmandantenfähigkeit, und wird die Alt-Tabelle MandantenStammdat noch verwendet? |
|
||||||
|
| SwRS-1233 | SwRS | Serverseitige Rechteprüfung beim Speichern von Mandantenstammdaten | Prüft die aufrufende REST-Schicht (CentronRestService) oder MandatorBL.SaveMandatory das Recht Administration.MANDATORY serverseitig, oder verlässt sich das System allein auf die Client-UI? |
|
||||||
+1201
File diff suppressed because it is too large
Load Diff
+5552
File diff suppressed because it is too large
Load Diff
+2893
File diff suppressed because it is too large
Load Diff
+324
@@ -0,0 +1,324 @@
|
|||||||
|
# Traceability
|
||||||
|
|
||||||
|
**System:** c-entron ERP-Suite | **Datum:** 2026-08-27
|
||||||
|
|
||||||
|
Forward-/Backward-Traceability zwischen StRS ↔ SyRS ↔ SwRS. Jede SwRS-Anforderung referenziert ihre SyRS, jede SyRS ihre StRS. Eine Zeile pro Kette; der Artefaktbeleg ist der Hauptbeleg der jeweils spezifischsten Anforderung. Nummernkreise: A1=1xx, A2=2xx, A3=3xx, A4=4xx, A5=5xx, A6=6xx, A7=7xx, A8=8xx, A9=9xx, A10=10xx, A11=11xx, A12=12xx.
|
||||||
|
|
||||||
|
## A1 — Sicherheit, Identität, Berechtigungen
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-101 | SyRS-101 | SwRS-101 | Centron.BL\Administration\Rights\AppRightsBL.cs → HasUserRight (SQL Sichtrus⋈Sichmemb) |
|
||||||
|
| StRS-101 | SyRS-101 | SwRS-105 | Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs → OnAuthorization (401/403) |
|
||||||
|
| StRS-101 | SyRS-102 | SwRS-102 | SSMS_DB_SCHEMA.sql → CREATE TABLE dbo.Sichrech/Sichgrup/Sichmemb/Sichtrus |
|
||||||
|
| StRS-101 | SyRS-102 | SwRS-103 | AppRightsBL.cs → SaveRightGroup/DeleteRightGroup (UserRightsManagement-Prüfungen, Admin-Gruppen-Schutz) |
|
||||||
|
| StRS-101 | SyRS-102 | SwRS-104 | AppRightsBL.cs → WriteAddRightToGroupLog/WriteBaseLog (AppRightLog) |
|
||||||
|
| StRS-101 | SyRS-110 | — | Centron.WPF.UI\Extensions\RibbonControlExtensions.cs → nur clientseitige Rechteprüfung |
|
||||||
|
| StRS-102 | SyRS-103 | SwRS-109 | Centron.BL\Administration\Logins\TicketBL.cs → GetExpireDate/RefreshTicketExpireDate |
|
||||||
|
| StRS-102 | SyRS-104 | SwRS-106 | OpenIdConnectAuthenticator.cs → AppUser-Lookup über OpenIdConnectSubjectIdentifier |
|
||||||
|
| StRS-102 | SyRS-104 | SwRS-107 | BasicAuthenticator.cs → SHA1Decoder.GetDecodedSHA1String + Passwortvergleich |
|
||||||
|
| StRS-102 | SyRS-104 | SwRS-110 | UsersBL.cs → ChangeOwnPassword/IsValidAppUserPassword |
|
||||||
|
| StRS-102 | SyRS-105 | SwRS-112 | TwoFactorAuthBL.cs → HasToValidateTwoFactor |
|
||||||
|
| StRS-102 | SyRS-105 | SwRS-113 | EmailTwoFactorValidator.cs + TwoFactorAuthController.cs → /2fa/validate |
|
||||||
|
| StRS-102 | SyRS-105 | SwRS-114 | TwoFactorAuthenticationBL.cs → ValidateAuthenticationPin (GoogleAuthenticator) |
|
||||||
|
| StRS-102 | SyRS-106 | SwRS-111 | WebAccountBL.cs → LoginWithWebAccount (Statuskette) |
|
||||||
|
| StRS-102 | SyRS-107 | SwRS-108 | Authenticator.cs → ValidateAppUser (Deaktivierungsfenster) |
|
||||||
|
| StRS-103 | SyRS-108 | SwRS-115 | PasswordManagerBL.cs → ValidateUserRights + Guideline-Rechteprüfungen |
|
||||||
|
| StRS-103 | SyRS-108 | SwRS-116 | PasswordManagerBL.cs → EXPORT_ACCESS_AND_PASSWORD_DATA-Prüfung vor Export |
|
||||||
|
| StRS-103 | SyRS-108 | SwRS-117 | AESCryptoLogic.cs → EncryptText/GetKeyAndIV (inkl. Fallback-Key) |
|
||||||
|
| StRS-103 | SyRS-108 | SwRS-118 | Centron.Controls\PasswordManager\AccessManagementViewModel.cs → SealBreakPropertyValue |
|
||||||
|
| StRS-103 | SyRS-108 | SwRS-119 | PasswordManagementKeywordBL.cs → GetDecryptedKeywordById (fehlende Entschlüsselung) |
|
||||||
|
| StRS-104 | SyRS-109 | SwRS-120 | DataSecurityBL.cs → DoDeleteContactPerson + Löschprotokoll |
|
||||||
|
| StRS-104 | SyRS-109 | SwRS-121 | DataSecurityBL.cs → ACCESS_CLEANUP_DATABASE-Prüfung |
|
||||||
|
| StRS-104 | SyRS-109 | SwRS-122 | DsgvoBL.cs → ORDER_PROCESSING_CONTRACTS_MANAGEMENT-Prüfung |
|
||||||
|
|
||||||
|
## A2 — Finanzen & Abrechnung
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-201 | SyRS-206 | SwRS-233 | AutomaticFacturaBL.Contracts.cs: NextDate/SetInvoiceTo/NormalizeCoefficient (Z. 1375–1583) |
|
||||||
|
| StRS-201 | SyRS-206 | SwRS-235 | AutomaticFacturaBL.Contracts.cs: SearchBillingContracts (Z. 847–970) |
|
||||||
|
| StRS-201 | SyRS-206 | SwRS-236 | AutomaticFacturaBL.Contracts.cs: StoreInvoiceToContract ToDo-Teil (Z. 1310–1336) |
|
||||||
|
| StRS-201 | SyRS-207 | SwRS-232 | ContractBL.cs: GetContingentRest (Z. 60–83) |
|
||||||
|
| StRS-201 | SyRS-207 | SwRS-234 | AutomaticFacturaBL.Contracts.cs: StoreBookedContingent (Z. 1098–1245) |
|
||||||
|
| StRS-201 | SyRS-208 | SwRS-230 | ContractBL.cs: RefreshContractEndeDate (Z. 1067–1177) |
|
||||||
|
| StRS-201 | SyRS-208 | SwRS-231 | ContractBL.cs: CloseContract (Z. 1243–1316) |
|
||||||
|
| StRS-201 | SyRS-209 | SwRS-251 | DeviceClickCounterBL.cs: GetAndUpdateDeviceClickCounter (Z. 234–270) |
|
||||||
|
| StRS-201 | SyRS-210 | SwRS-254 | HelpdeskTimerWebServiceBL.cs: ThrowIfUserDoesntHaveRightToChangeHelpdeskTimers (Z. 348–376) |
|
||||||
|
| StRS-202 | SyRS-211 | SwRS-237 | DunningRunBL.cs: UpdateInvoice (Z. 248–275) |
|
||||||
|
| StRS-202 | SyRS-211 | SwRS-238 | DunningRunBL.cs: SaveDunningRun (Z. 277–315); Tabelle Mahnlauf |
|
||||||
|
| StRS-202 | SyRS-211 | SwRS-241 | DunningRunBL.cs: GenerateMail (Z. 406–451) |
|
||||||
|
| StRS-202 | SyRS-212 | SwRS-239 | DunningBL.cs: GetDunningStopActive (Z. 170–182); cvw_InvoiceDunning NextDueDate |
|
||||||
|
| StRS-202 | SyRS-212 | SwRS-243 | DunningBL.cs: CalculateDunningStatistics (Z. 205–236) |
|
||||||
|
| StRS-202 | SyRS-213 | SwRS-242 | PaymentsBL.cs: DeleteIncomingPayment (Z. 38–78) |
|
||||||
|
| StRS-202 | SyRS-214 | SwRS-244 | OnlineBankingAccountTransactionsBL.cs: SaveOnlineBankingAccountTransactions (Z. 294–340) |
|
||||||
|
| StRS-202 | SyRS-214 | SwRS-245 | OnlineBankingAccountTransactionsBL.cs: CheckForCompleted (Z. 342–360) |
|
||||||
|
| StRS-202 | SyRS-214 | SwRS-246 | OnlineBankingAccountTransactionsBL.cs: AutoCompleteSingleAccountTransaciton (Z. 581–617) |
|
||||||
|
| StRS-202 | SyRS-214 | SwRS-247 | OnlineBankingAccountTransactionsBL.cs: BookAmountToAssignedInvoice (Z. 1042–1086) |
|
||||||
|
| StRS-202 | SyRS-214 | SwRS-248 | ScriptMethod11560.cs (Rechteanlage, TODO-Kommentar) |
|
||||||
|
| StRS-202 | SyRS-215 | SwRS-244 | FinApiClient.cs: LoadAccountTransactions (Z. 266 ff.); OnlineBankingFinApiBL.cs Z. 29–50 |
|
||||||
|
| StRS-203 | SyRS-216 | SwRS-249 | BookKeepingExportBL.cs: IsReceiptExported (Z. 209–226); PORTRECH/PORTWARE |
|
||||||
|
| StRS-203 | SyRS-216 | SwRS-250 | BookKeepingExportBL.cs: GetReceiptsBookingdataExportFile (Z. 443–544) |
|
||||||
|
| StRS-203 | SyRS-216 | SwRS-253 | CustomerCostCenterBL.cs: DeleteCustomerCostCenter (Z. 42–54) |
|
||||||
|
| StRS-203 | SyRS-216 | SwRS-255 | NamedQueryPool.xml: VoucherManagementGetVoucherArticles (Z. 680–709) |
|
||||||
|
| StRS-204 | SyRS-217 | SwRS-252 | SepaContractOnlinePdfDocumentHandler.cs: Confirm (Z. 78–178) |
|
||||||
|
| StRS-205 | SyRS-218 | SwRS-242 | PaymentsBL.cs: Rechteprüfung 10980 (Z. 43–44) |
|
||||||
|
| StRS-205 | SyRS-218 | SwRS-248 | CheckForUnknownIbanViewModel.cs: CheckUserRightsAsync (Z. 83–101) |
|
||||||
|
| StRS-205 | SyRS-218 | SwRS-254 | HelpdeskTimerWebServiceBL.cs: EDIT_TIME/OWN_TIME_EDIT (Z. 348–376) |
|
||||||
|
|
||||||
|
## A3 — Vertrieb & Belegwesen
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-301 | SyRS-310 | SwRS-331 | OfferSpecificLogic.CanBeForwardedInto() (Zeile 314) |
|
||||||
|
| StRS-301 | SyRS-310 | SwRS-332 | ReceiptBL.ValidateReceiptForwarding() (Zeile 2462) |
|
||||||
|
| StRS-301 | SyRS-310 | SwRS-333 | ReceiptBL.ForwardReceipt() (Zeile 1548, UpdateReceiptNumber Zeile 1643) |
|
||||||
|
| StRS-301 | SyRS-311 | SwRS-330 | Centron.Interfaces\Sales\Receipts\ReceiptState.cs |
|
||||||
|
| StRS-301 | SyRS-311 | SwRS-343 | ReceiptBL.CreateNewVersion<T>() (Zeile 3068) |
|
||||||
|
| StRS-301 | SyRS-311 | SwRS-344 | AutomaticallyCloseReceiptHelperBL.ItemIsFinished() |
|
||||||
|
| StRS-302 | SyRS-312 | SwRS-334 | NumberGroupBL.GetNextNumber() (bedingtes UPDATE, Zeile 80) |
|
||||||
|
| StRS-302 | SyRS-312 | SwRS-335 | InvoiceSpecificLogic.GetNumberGroup() (Zeile 104) |
|
||||||
|
| StRS-302 | SyRS-313 | SwRS-336 | ReceiptPriceHelper.CalculateReceiptVatPrices() (Zeile 61) |
|
||||||
|
| StRS-302 | SyRS-313 | SwRS-337 | ReceiptBL.CheckIfAllArticlePositionsHaveVatRate() |
|
||||||
|
| StRS-302 | SyRS-314 | SwRS-338 | ReceiptInvoiceBL.CancelInvoice() (Zeile 143, Recht Zeile 154) |
|
||||||
|
| StRS-302 | SyRS-314 | SwRS-339 | ReceiptInvoiceBL.FixInvoice() (UPDATE RechKopf SET IsFixed=1) |
|
||||||
|
| StRS-302 | SyRS-314 | SwRS-354 | ReceiptItemBL.cs Zeile 2954 (Sperre stornierter Belege) |
|
||||||
|
| StRS-302 | SyRS-315 | SwRS-340 | ReceiptBL.CanUserEditReceipt() (Zeile 10273) |
|
||||||
|
| StRS-302 | SyRS-316 | SwRS-341 | DunningRunBL (Mahnstufen-Switch Zeilen 253–268) |
|
||||||
|
| StRS-302 | SyRS-316 | SwRS-342 | ReceiptBL.CheckIfCustomerLimitIsReached() |
|
||||||
|
| StRS-302 | SyRS-321 | SwRS-353 | ReceiptBL.GetReceiptConditionText() (Zeile 8500) |
|
||||||
|
| StRS-303 | SyRS-317 | SwRS-345 | ReceiptItemPriceBL.GetBasePrice() (Zeile 154) |
|
||||||
|
| StRS-303 | SyRS-317 | SwRS-346 | ReceiptItemPriceBL.GetSpecialPrice() (Zeile 588) + CustomerSpecialPriceMaps (KundenSonderpreise) |
|
||||||
|
| StRS-303 | SyRS-317 | SwRS-347 | ReceiptBL.CheckArticleMinPrices() (Zeilen 9036–9130) |
|
||||||
|
| StRS-304 | SyRS-318 | SwRS-351 | InvoiceZugferdBL.GenerateZugferdFile() (Zeile 124) |
|
||||||
|
| StRS-304 | SyRS-318 | SwRS-352 | ZugferdImportController.cs ([Authorize], POST parse) |
|
||||||
|
| StRS-305 | SyRS-319 | SwRS-349 | MailingDataBL.SaveMailingData() (Version=2, Zeile 78) |
|
||||||
|
| StRS-305 | SyRS-319 | SwRS-350 | AccountSearchBL (AdvertisingNotAllowed-Filter, Zeilen 993–1011) |
|
||||||
|
| StRS-305 | SyRS-320 | SwRS-348 | SSMS_DB_SCHEMA.sql, CustomerProductMatrixRating/ChangeLogs (Zeilen 36519/36535) |
|
||||||
|
|
||||||
|
## A4 — Artikel, Lager, Einkauf, Logistik, RMA
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-401 | SyRS-410 | SwRS-435 | SSMS_DB_SCHEMA.sql, cvw_BarcodeCount (Status in (1,2,8)) |
|
||||||
|
| StRS-401 | SyRS-410 | SwRS-436 | SSMS_DB_SCHEMA.sql, Tabelle NebenlagerArtikel |
|
||||||
|
| StRS-401 | SyRS-410 | SwRS-441 | BarcodeBL.ValidateNewBarcode |
|
||||||
|
| StRS-401 | SyRS-410 | SwRS-443 | BarcodeBL.GetSystemSNID |
|
||||||
|
| StRS-401 | SyRS-411 | SwRS-430 | ArticleBL.CheckUserRightBeforeSave |
|
||||||
|
| StRS-401 | SyRS-411 | SwRS-431 | ArticleBL.SaveArticle (Duplikat-/Längenprüfung) |
|
||||||
|
| StRS-401 | SyRS-411 | SwRS-432 | ArticleStockBL.UpdateArticlePurchasePrice |
|
||||||
|
| StRS-401 | SyRS-411 | SwRS-433 | SecondStockArticleBL.RebookStockArticle (TRANSFER_STOCK) |
|
||||||
|
| StRS-401 | SyRS-412 | SwRS-434 | SecondStockArticleBL.StockBookOrBookout (ARTIKlog) |
|
||||||
|
| StRS-401 | SyRS-412 | SwRS-442 | BarcodeBL.CheckOutBarCodes |
|
||||||
|
| StRS-401 | SyRS-413 | SwRS-437 | InventoryNewBL.CloseInventory |
|
||||||
|
| StRS-401 | SyRS-413 | SwRS-438 | InventoryBL.CloseStorages |
|
||||||
|
| StRS-402 | SyRS-414 | SwRS-444 | OrderSuggestionListBL, _sqlArticle |
|
||||||
|
| StRS-402 | SyRS-415 | SwRS-445 | EDIDispatcherBL.CreateEDISuggestionOrderAsync |
|
||||||
|
| StRS-402 | SyRS-415 | SwRS-446 | SupplierEdiBL.SaveReceiptItemAssignments |
|
||||||
|
| StRS-402 | SyRS-418 | SwRS-450 | IceCatImportService.GetArticleAsync |
|
||||||
|
| StRS-402 | SyRS-418 | SwRS-451 | TradePoolBL.StartTradeImport |
|
||||||
|
| StRS-403 | SyRS-419 | SwRS-439 | OrderCommissionBL.HasUserRightsTooAccessCommissionModule |
|
||||||
|
| StRS-403 | SyRS-419 | SwRS-440 | OrderCommissionBL.ExecuteCommissionForOrders |
|
||||||
|
| StRS-403 | SyRS-416 | SwRS-447 | CentronGlsLogic.DoValidateShipment |
|
||||||
|
| StRS-403 | SyRS-416 | SwRS-448 | CentronShipcloudLogic.CreateShipmentAsync |
|
||||||
|
| StRS-404 | SyRS-417 | SwRS-449 | RmaBL.SaveRma |
|
||||||
|
|
||||||
|
## A5 — Helpdesk & Service
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-501 | SyRS-511 | SwRS-531 | HelpdeskStatusBL.DeleteHelpdeskStatus() |
|
||||||
|
| StRS-501 | SyRS-511 | SwRS-532 | HelpdeskCloseBL.CloseHelpdeskForNotificationMethods() |
|
||||||
|
| StRS-501 | SyRS-511 | SwRS-549 | TicketProjectBL.SaveOrUpdateTicketProject() |
|
||||||
|
| StRS-501 | SyRS-511 | SwRS-550 | HelpdeskConnectionNumberBL.EnsureHelpdeskConnection() |
|
||||||
|
| StRS-501 | SyRS-512 | SwRS-533 | HelpdeskBL.CheckUserRigths() |
|
||||||
|
| StRS-501 | SyRS-512 | SwRS-534 | HelpdeskBL.CheckWebRights() |
|
||||||
|
| StRS-501 | SyRS-512 | SwRS-535 | HelpdeskBL.DoValidateMandatoryFields() |
|
||||||
|
| StRS-501 | SyRS-513 | SwRS-536 | HelpdeskBL.GetDueDateFromPriority() |
|
||||||
|
| StRS-501 | SyRS-514 | SwRS-537 | EscalationBL.CheckEskalationStage()/UpdateTicket() |
|
||||||
|
| StRS-501 | SyRS-520 | SwRS-543 | CentronChecklistBL.ObjectHasOpenChecklists() |
|
||||||
|
| StRS-502 | SyRS-515 | SwRS-538 | HelpdeskTimerWebServiceBL.ThrowIfUserDoesntHaveRightToChangeHelpdeskTimers() |
|
||||||
|
| StRS-502 | SyRS-515 | SwRS-539 | HelpdeskTimerBL.DeleteHelpdeskTimer() |
|
||||||
|
| StRS-502 | SyRS-515 | SwRS-542 | HelpdeskTimerWebServiceBL.CheckTimerCanBeMoved() |
|
||||||
|
| StRS-502 | SyRS-516 | SwRS-540 | HelpdeskTimerSignatureBL.SignMultipleTimers() |
|
||||||
|
| StRS-502 | SyRS-516 | SwRS-541 | HelpdeskTimerSignatureBL.RemoveSignatureFromTime() |
|
||||||
|
| StRS-503 | SyRS-517 | SwRS-544 | ExpectedEventsBL.SaveExpectedEvent() |
|
||||||
|
| StRS-503 | SyRS-517 | SwRS-545 | ExpectedEventsMaps.cs (Mapping MessageContains*) |
|
||||||
|
| StRS-503 | SyRS-517 | SwRS-547 | TaskManagementHelpdeskActionHandler.Execute() |
|
||||||
|
| StRS-504 | SyRS-518 | SwRS-546 | SelfCareBL.GetWebFormByGuid() |
|
||||||
|
| StRS-504 | SyRS-519 | SwRS-548 | SurveyProcessBL.GetSurveyfromTemplate() |
|
||||||
|
|
||||||
|
## A6 — Stammdaten & Assets
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-601 | SyRS-605 | SwRS-620 | Centron.BL\Accounts\AccountBL.cs, ValidateUserRights |
|
||||||
|
| StRS-601 | SyRS-605 | SwRS-624 | Centron.BL\Accounts\AccountAddressBL.cs, CheckSpecialUserRightForAddressLanguageBeforeSave |
|
||||||
|
| StRS-601 | SyRS-605 | SwRS-625 | Centron.BL\Accounts\AccountAddressContactBL.cs, AccountSaveAddressContact |
|
||||||
|
| StRS-601 | SyRS-606 | SwRS-621 | Centron.BL\Accounts\AccountBL.cs, GetNewAccount |
|
||||||
|
| StRS-601 | SyRS-606 | SwRS-622 | SSMS_DB_SCHEMA.sql, IX_Accounts_Number / IX_AccountCustomers_UniqueNumber |
|
||||||
|
| StRS-601 | SyRS-606 | SwRS-623 | Centron.BL\Accounts\AccountBL.cs, DeleteAccount |
|
||||||
|
| StRS-601 | SyRS-606 | SwRS-626 | Centron.BL\Accounts\AccountAddressBL.cs, GetNotImportedGeoInfoList |
|
||||||
|
| StRS-602 | SyRS-607 | SwRS-627 | Centron.BL\EmployeeArea\AppUserBL.cs, SaveOrUpdateAppUser |
|
||||||
|
| StRS-602 | SyRS-607 | SwRS-629 | Centron.BL\EmployeeArea\AppUserBL.cs, GetActiveAppUsers |
|
||||||
|
| StRS-602 | SyRS-608 | SwRS-628 | Centron.BL\EmployeeArea\EmployeeBL.cs, SaveOrUpdateEmployee |
|
||||||
|
| StRS-603 | SyRS-609 | SwRS-630 | Centron.BL\Sales\CustomerAssets\Contracts\ClickContracts\MasterDataListBL.cs, SaveMasterDataList |
|
||||||
|
| StRS-603 | SyRS-609 | SwRS-631 | ebd., RemoveMainDeviceSerialNumber / SwapMainDeviceSerialNumber |
|
||||||
|
| StRS-603 | SyRS-609 | SwRS-633 | Centron.Entities\Entities\Sales\Receipts\MasterDataLists\MasterDataList.cs vs. Entities\Devices\AccountDevice.cs |
|
||||||
|
| StRS-603 | SyRS-610 | SwRS-632 | Centron.BL\Devices\AccountDeviceBL.cs, DeleteAccountDevice |
|
||||||
|
| StRS-603 | SyRS-610 | SwRS-637 | Centron.BL\Devices\AccountDeviceBL.cs (Negativbefund Rechteprüfung) |
|
||||||
|
| StRS-604 | SyRS-611 | SwRS-635 | Centron.BL\Tags\TagsBL.cs, AddTicketTag |
|
||||||
|
| StRS-604 | SyRS-611 | SwRS-636 | Centron.BL\Administration\Customization\ModuleCustomPropertyBL.cs, SaveCustomPropertyStructure |
|
||||||
|
| StRS-604 | SyRS-612 | — | Centron.BL\ObjectExternalReferences\ObjectExternalReferenceBL.cs, CreateReference |
|
||||||
|
| StRS-604 | SyRS-613 | SwRS-634 | Centron.BL\CountryArea\CountryBL.cs, UpdateCurrencyRateByRateDictionary |
|
||||||
|
|
||||||
|
## A7 — Kommunikation & persönliche Organisation
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-701 | SyRS-711 | SwRS-731 | Centron.BL\Mail\Factory\CentronMailFactory.cs, GetMail() |
|
||||||
|
| StRS-701 | SyRS-711 | SwRS-732 | Centron.BL\Mail\Protocols\SMTPMail.cs, CreateSmtpClient() |
|
||||||
|
| StRS-701 | SyRS-711 | SwRS-733 | Centron.BL\Mail\Protocols\SMTPMail.cs, CreateMailMessage() |
|
||||||
|
| StRS-701 | SyRS-711 | SwRS-734 | Centron.BL\Mail\Protocols\SMTPMail.cs, FillMailBodyOld() |
|
||||||
|
| StRS-701 | SyRS-711 | SwRS-735 | Centron.BL\Mail\Blacklist\DomainBlacklistBL.cs, IsBlacklisted() |
|
||||||
|
| StRS-701 | SyRS-712 | — | Centron.BL\WebServices\Mail\SendMailWebserviceBL.cs, CheckFromAdress() |
|
||||||
|
| StRS-701 | SyRS-713 | SwRS-736 | Centron.BL\Mail\Templates\MailTemplateBL.cs, MailTemplate() (Fallback-Kommentar Z. 248–255) |
|
||||||
|
| StRS-701 | SyRS-713 | SwRS-737 | Centron.BL\Mail\Templates\MailTemplateBL.cs, GenerateVariables() |
|
||||||
|
| StRS-701 | SyRS-714 | SwRS-738 | Centron.BL\MailScanner\MailScannerBL.cs, GetProfiles() / EncryptProperties() |
|
||||||
|
| StRS-702 | SyRS-715 | SwRS-739 | Centron.BL\AppointmentRequests\AppointmentRequestBL.cs, HandleAppointmentRequestReply() |
|
||||||
|
| StRS-702 | SyRS-716 | SwRS-740 | Centron.BL\Calendar\CalendarBL.cs, GetCalendarSynchronizationSettings() |
|
||||||
|
| StRS-704 | SyRS-717 | SwRS-741 | Centron.BL\Tapi\PhoneCallBL.cs, SearchContactPersonByPhoneNumberV2() |
|
||||||
|
| StRS-704 | SyRS-717 | SwRS-742 | Centron.BL\Tapi\PhoneCallBL.cs, SyncPhoneCalls() (Lizenzprüfung) |
|
||||||
|
| StRS-704 | SyRS-718 | SwRS-743 | Centron.BL\Chats\ChatBL.cs, GetFilterExpression() (OnlyOwn/Membership) |
|
||||||
|
| StRS-703 | SyRS-718 | SwRS-744 | Centron.BL\NexusNotifications\NexusNotificationsBL.cs, MarkAllNexusNotificationsAsRead() |
|
||||||
|
| StRS-703 | SyRS-718 | SwRS-748 | Centron.BL\SocialMedia\SocialMediaBL.cs, AddCommentToASocialMediaAction() |
|
||||||
|
| StRS-703 | SyRS-719 | SwRS-745 | Centron.BL\ToDoArea\ToDoBL.cs, GetTodosThroughPaging() (RIGHT_FREMDTODOLISTE) |
|
||||||
|
| StRS-703 | SyRS-719 | SwRS-746 | Centron.BL\MyDay\MyDayBL.cs, SaveOrUpdateWorkItem() (UniqueId-Dedup) |
|
||||||
|
| StRS-703 | SyRS-719 | SwRS-747 | Centron.BL\VideoPortal\VideoPortalAssignmentBL.cs, SaveVideoPortalAssignment() |
|
||||||
|
|
||||||
|
## A8 — Web-Client Nexus & Service-Schnittstellen
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-801 | SyRS-811 | SwRS-839 | src\nexus\CentronNexus\Shared\Authorization\ClaimsService.cs (GetClaims) |
|
||||||
|
| StRS-801 | SyRS-811 | SwRS-840 | src\nexus\CentronNexus\Shared\Authorization\PortAuthorization.cs (PortHandler) |
|
||||||
|
| StRS-802 | SyRS-811 | SwRS-848 | src\nexus\CentronNexus\ProductionOrderManagement\Pages\ProductionOrderOverView.razor (fehlendes Authorize-Attribut) |
|
||||||
|
| StRS-801 | SyRS-812 | SwRS-841 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs (ThrowIfCanNotAccessCart) |
|
||||||
|
| StRS-801 | SyRS-812 | SwRS-842 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartReleaseSystemBL.cs (OrdererApproveCart) |
|
||||||
|
| StRS-801 | SyRS-813 | SwRS-843 | src\nexus\CentronNexus\WebOffer\WebReceiptOverview.razor (ChangeWebReceiptState) |
|
||||||
|
| StRS-801 | SyRS-814 | SwRS-844 | src\backend\Centron.BL\Administration\Documents\Dsgvo\DsgvoBL.cs (ConfirmOnlinePdfDocument) |
|
||||||
|
| StRS-801 | SyRS-815 | SwRS-845 | src\backend\Centron.BL\Sales\Support\HelpdeskSearchBL.cs (IsWebAccountLogin-Filter) |
|
||||||
|
| StRS-802 | SyRS-816 | SwRS-846 | src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs (CloseHelpdesk) |
|
||||||
|
| StRS-802 | SyRS-816 | SwRS-847 | src\nexus\CentronNexus\ProductionOrderManagement\Components\WorkStepTemplateComponent.razor (FinishWorkstep) |
|
||||||
|
| StRS-803 | SyRS-817 | SwRS-831 | src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs (OnAuthorization) |
|
||||||
|
| StRS-803 | SyRS-817 | SwRS-832 | src\webservice\Centron.Controllers\Authorization\CentronHostedAuthorization.cs (HandleRequirementAsync) |
|
||||||
|
| StRS-803 | SyRS-817 | SwRS-833 | src\webservice\Centron.Controllers\Controllers\Unversioned\JwtAuthController.cs (LoginWithBearer) |
|
||||||
|
| StRS-803 | SyRS-817 | SwRS-834 | src\webservice\Centron.Controllers\Controllers\Unversioned\TwoFactorAuthController.cs (ValidateTwoFactorCode) |
|
||||||
|
| StRS-803 | SyRS-817 | SwRS-835 | src\backend\Centron.BL\WebServices\Administration\Logins\WebAccountWebServiceBL.cs (HasUserRight WEBACCOUNT_MANAGEMENT) |
|
||||||
|
| StRS-803 | SyRS-818 | SwRS-836 | src\webservice\Centron.Host\AspNetCore\WcfBridge\Interception\Interceptors\AuthenticateInterceptor.cs (InterceptExecution) |
|
||||||
|
| StRS-803 | SyRS-818 | SwRS-849 | src\backend\Centron.BL\Mobile\MobileBL.cs (GetMobileEmployee) |
|
||||||
|
| StRS-803 | SyRS-818 | SwRS-850 | src\backend\Centron.BL\WebLinks\WebLinkActionAccountActivityHandler.cs (Execute) |
|
||||||
|
| StRS-803 | SyRS-819 | SwRS-837 | src\webservice\Centron.Controllers\Configuration\GlobalExceptionFilter.cs (OnException) |
|
||||||
|
| StRS-803 | SyRS-819 | SwRS-838 | src\webservice\Centron.Controllers\Configuration\Routing\KebabCaseTransformer.cs (TransformOutbound) |
|
||||||
|
| StRS-804 | SyRS-820 | — | src\webservice\Centron.Host.Console\Program.cs (CentronHost.Instance.Start) |
|
||||||
|
|
||||||
|
Hinweis: SwRS-848 hängt unter SyRS-811 (Zugriffsschutz) und zusätzlich fachlich unter StRS-802; SwRS-850 ist sekundär auch SyRS-816 zugeordnet (Tracelinks im Block).
|
||||||
|
|
||||||
|
## A9 — Datenaustausch & Integrationen
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-901 | SyRS-911 | SwRS-931 | src\backend\Centron.BL\RiverDivo\RiverDivoBL.cs → ValidateRmmAccessKey (FixedTimeEquals) |
|
||||||
|
| StRS-901 | SyRS-911 | SwRS-933 | src\backend\Centron.BL\RiverDivo\RiverDivoBL.cs → CreateHelpdeskRequest (CreatedFrom = 7) |
|
||||||
|
| StRS-901 | SyRS-911 | SwRS-935 | src\backend\Centron.BL\RiverDivo\RiverDivoBL.cs → GetAllCustomersForSync (ChangedAfterDate, LogoHash) |
|
||||||
|
| StRS-901 | SyRS-912 | SwRS-932 | src\backend\Centron.BL\WebServices\Rmm\RmmConnectionSettingsWebServiceBL.cs → HasUserRight(SETTINGS) |
|
||||||
|
| StRS-901 | SyRS-912 | SwRS-937 | src\backend\Centron.BL\DataExchange\Connectors\DocBeeTicketCreationBL.cs → IsDocBeeActive (Lizenzprüfung) |
|
||||||
|
| StRS-901 | SyRS-912 | SwRS-947 | src\webservice\Centron.Controllers\Controllers\v1\DataExchange\TelekomDiveController.cs → SaveProfiles (ohne Rechteattribut) |
|
||||||
|
| StRS-901 | SyRS-913 | SwRS-934 | src\backend\Centron.BL\RiverDivo\RiverDivoBL.cs → GetCentronCustomerI3D (RiverbirdCustomerReference) |
|
||||||
|
| StRS-901 | SyRS-913 | SwRS-936 | src\backend\Centron.BL\DataExchange\Connectors\DocBeeTicketTimerBL.cs → SaveDocBeeTicketTimer |
|
||||||
|
| StRS-904 | SyRS-913 | SwRS-942 | src\backend\Centron.BL\Integrations\EsCustomerGroupBL.cs → Create/Delete (Soft-Delete) |
|
||||||
|
| StRS-901 | SyRS-913 | SwRS-945 | src\backend\Centron.BL\CPra\CPraConnectorBL.cs → GenerateLink (Base64-Parameter) |
|
||||||
|
| StRS-903 | SyRS-914 | SwRS-938 | src\backend\Centron.BL\DataExchange\DocuForm\DocuFormApiSettingsBL.cs → AES + SETTINGS-Recht |
|
||||||
|
| StRS-903 | SyRS-914 | SwRS-939 | src\centron\Centron.WPF.UI\Modules\Finances\DeviceClickCounter\DocuFormApiImport\DocuFormApiImportViewModel.cs → DownloadDeviceCounters |
|
||||||
|
| StRS-902 | SyRS-915 | SwRS-940 | src\backend\Centron.Entities\Entities\DataExchange\TelekomDive\TelekomDiveProfile.cs |
|
||||||
|
| StRS-902 | SyRS-915 | SwRS-941 | src\centron\Centron.WPF.UI\Modules\TelekomDive\TelekomDiveExportViewModel.cs → ExportToXml |
|
||||||
|
| StRS-902 | SyRS-916 | SwRS-946 | src\backend\Centron.Gateway\DataExchange\BookKeeping\BookKeepingFileExport.cs → PrepareStoreFile |
|
||||||
|
| StRS-904 | SyRS-917 | SwRS-943 | src\backend\Centron.BL\Administration\FileManagement\DirectoryBL.cs → IsDocSyncEnabledForObjectKind |
|
||||||
|
| StRS-904 | SyRS-917 | SwRS-944 | src\centron\Centron.WPF.UI\Modules\DataExchange\DataImport\AccountImport\IbanValidation.cs → IbanChecksumCheck |
|
||||||
|
| StRS-901 | SyRS-918 | — | src\backend\Centron.BL\RiverDivo\RiverConnectionBL.cs → GetActiveDirectoryUsers (WebAccount-Isolationsprüfung) |
|
||||||
|
|
||||||
|
## A10 — Produktion, Projekte, PLM, QM, Statistik, Reporting
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-1001 | SyRS-1010 | SwRS-1030 | ProductionOrderBL.cs: LicenseManager.HasLicense(LicenseGuids.ProductionManagement)-Gate |
|
||||||
|
| StRS-1001 | SyRS-1010 | SwRS-1031 | ProductionBL.cs: Lizenzgate vor Maschinenstammdaten |
|
||||||
|
| StRS-1001 | SyRS-1011 | SwRS-1030 | ProductionOrderItemState.cs / ProductionOrderLogKind.cs |
|
||||||
|
| StRS-1001 | SyRS-1011 | SwRS-1031 | SSMS_DB_SCHEMA.sql: ProductionOrders/ProductionOrderLogs NOT-NULL-Constraints |
|
||||||
|
| StRS-1002 | SyRS-1012 | SwRS-1037 | SaleStatisticBL.GetSalesArticleStatistic: SALES_STATISTIC-Prüfung |
|
||||||
|
| StRS-1002 | SyRS-1012 | SwRS-1038 | ManagementInfoBL: MANAGEMENT_INFO_ONLY_OWN_BRANCH-Zwangsfilter |
|
||||||
|
| StRS-1002 | SyRS-1012 | SwRS-1046 | ModulesSlideViewModel.cs: Gruppierung/Suche/Favoriten |
|
||||||
|
| StRS-1002 | SyRS-1013 | SwRS-1041 | ReportDataBL.ExecuteQuery: Regex-Variablenersetzung |
|
||||||
|
| StRS-1002 | SyRS-1013 | SwRS-1042 | SSMS_DB_SCHEMA.sql: Tabellen ReportData und Reports |
|
||||||
|
| StRS-1002 | SyRS-1013 | SwRS-1043 | ReportServerAppModuleController.Description + ReportServerConnector |
|
||||||
|
| StRS-1002 | SyRS-1014 | SwRS-1041 | ReportDataWebBL.ReportEngineExecuteQuery: SQL_MANAGER/REPORT_MANAGEMENT-Prüfung |
|
||||||
|
| StRS-1002 | SyRS-1019 | SwRS-1032 | ProjectManagementViewModel.RefreshAsync/RefreshEmployeeWorkload |
|
||||||
|
| StRS-1003 | SyRS-1015 | SwRS-1033 | ProjectPriceImportViewModel: Fehlerliste + SpecialAgreementDifferenceViewModel |
|
||||||
|
| StRS-1003 | SyRS-1015 | SwRS-1044 | MassUpdateBL.StartReceiptPriceUpdate: ReceiptState.Active-Prüfung |
|
||||||
|
| StRS-1003 | SyRS-1015 | SwRS-1045 | MassUpdateBL.StartArticlePriceUpdate: Bulkchanger-Log |
|
||||||
|
| StRS-1003 | SyRS-1016 | SwRS-1036 | ReceiptBL.CheckIfAssetReasonIsNeeded: IsMandatory-Prüfung |
|
||||||
|
| StRS-1004 | SyRS-1017 | SwRS-1039 | MspCollectorsBL.MspDowloadStart: Duplikatprüfung MspCollectorInvoiceHead |
|
||||||
|
| StRS-1004 | SyRS-1017 | SwRS-1040 | MspCollectorsBL.UpdateMspContractItem: MspEvaluationDecision-Switch |
|
||||||
|
| StRS-1004 | SyRS-1017 | SwRS-1047 | AssetManagementArticleAssignmentBL: Löschschutz bei Vertragsreferenz |
|
||||||
|
| StRS-1004 | SyRS-1018 | SwRS-1034 | ProductFamilyBL.ImportProductLifecycleInformations: Dedup-Query |
|
||||||
|
| StRS-1004 | SyRS-1018 | SwRS-1035 | ProductFamilyBL: DaysToTolerate-Fristlogik + UserForPLM |
|
||||||
|
|
||||||
|
## A11 — Plattform & Querschnitt
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-1101 | SyRS-1110 | SwRS-1130 | src\backend\Centron.DAO\DAOSession.cs (WithTransaction) |
|
||||||
|
| StRS-1101 | SyRS-1110 | SwRS-1143 | src\centron\Centron.WPF.UI\CentronFileSystem\CentronFileSystemConnector.cs |
|
||||||
|
| StRS-1101 | SyRS-1111 | SwRS-1131 | src\backend\Centron.Entities\PersistedEntity.cs (operator ==) |
|
||||||
|
| StRS-1101 | SyRS-1111 | SwRS-1132 | src\backend\Centron.DAO\DAOFactory.cs:100-127 (AppendListeners) |
|
||||||
|
| StRS-1101 | SyRS-1111 | SwRS-1147 | src\backend\Centron.DAO\Mappings\...\MandatorMaps.cs / MandatoryMaps.cs (Table("Mandant")) |
|
||||||
|
| StRS-1101 | SyRS-1112 | — | tests\Centron.Tests.Integration\IntegrationTest.cs (TestGetHelpdesksThroughPaging) |
|
||||||
|
| StRS-1102 | SyRS-1114 | — | src\centron\Centron.WPF.UI\nlog.config (csvTarget, WARN, 15 Archive) |
|
||||||
|
| StRS-1102 | SyRS-1115 | SwRS-1133 | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
|
||||||
|
| StRS-1102 | SyRS-1115 | SwRS-1134 | src\backend\Centron.DAO\ChangeTracking\LogHourlySurchargeRateChangesListener.cs |
|
||||||
|
| StRS-1102 | SyRS-1115 | SwRS-1135 | SSMS_DB_SCHEMA.sql:34746 (ChangeLog + IX_ChangeLog) |
|
||||||
|
| StRS-1102 | SyRS-1116 | SwRS-1136 | src\backend\Centron.BL\Telemetry\TelemetryBL.cs (MERGE WITH (HOLDLOCK)) |
|
||||||
|
| StRS-1102 | SyRS-1116 | SwRS-1137 | src\backend\Centron.BL\Telemetry\TelemetryBL.cs (InsertMissingNames) |
|
||||||
|
| StRS-1103 | SyRS-1117 | SwRS-1138 | src\backend\Centron.BL\IndexSearch\IndexBuilder.cs |
|
||||||
|
| StRS-1103 | SyRS-1117 | SwRS-1139 | src\backend\Centron.BL\IndexSearch\IndexSearchBL.cs (UpdateIndexesInternal) |
|
||||||
|
| StRS-1103 | SyRS-1117 | SwRS-1140 | SSMS_DB_SCHEMA.sql:45591 (ObjectFulltextIndex/Stats) |
|
||||||
|
| StRS-1103 | SyRS-1118 | SwRS-1141 | src\backend\Centron.BL\ArtificialIntelligence\AiApiLinkValidator.cs |
|
||||||
|
| StRS-1103 | SyRS-1118 | SwRS-1142 | src\backend\Centron.BL\Administration\ArtificialIntelligence\ArtificialIntelligenceBL.cs:184 |
|
||||||
|
| StRS-1104 | SyRS-1113 | — | src\centron\Centron.WPF.UI\ConnectionHeartbeatTimer.cs (TimerTick) |
|
||||||
|
| StRS-1104 | SyRS-1119 | SwRS-1143 | src\centron\Centron.WPF.UI\CentronFileSystem\CentronFileSystemConnector.cs (CheckOutDocument) |
|
||||||
|
| StRS-1104 | SyRS-1120 | SwRS-1144 | src\centron\Centron.WPF.UI\Localization\LocalizationHelper.cs |
|
||||||
|
| StRS-1104 | SyRS-1121 | SwRS-1145 | src\backend\Centron.BL\GUI\Profiles\UiProfileBL.cs:51 |
|
||||||
|
| StRS-1104 | SyRS-1121 | SwRS-1146 | src\backend\Centron.BL\ExternalToolsBL\ExternalToolBL.cs (SaveExternalTool) |
|
||||||
|
|
||||||
|
## A12 — Administration, Konfiguration & Betrieb
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---------|---------|---------|---------------|
|
||||||
|
| StRS-1201 | SyRS-1211 | SwRS-1231 | MandatorManagementViewModel.DeleteMandatorAsync (State = 0) |
|
||||||
|
| StRS-1201 | SyRS-1211 | SwRS-1232 | MandatorManagementViewModel.IsSetToDefault / EditBranchDetails |
|
||||||
|
| StRS-1201 | SyRS-1211 | SwRS-1233 | MandatorWebServiceBL.SaveMandatoryExtended (fehlende Rechteprüfung) |
|
||||||
|
| StRS-1201 | SyRS-1211 | SwRS-1234 | MandatorManagementViewModel.SaveMandatorInstructionPrompt (Rechteprüfung 10510) |
|
||||||
|
| StRS-1202 | SyRS-1212 | SwRS-1235 | SSMS_DB_SCHEMA.sql [dbo].[ApplicationSettings] |
|
||||||
|
| StRS-1202 | SyRS-1212 | SwRS-1236 | docs\guides\development\settings-management.md + Tabellen Stammdat/ApplicationSettings |
|
||||||
|
| StRS-1202 | SyRS-1212 | SwRS-1245 | ReportDataWebBL.ReportEngineExecuteQuery (Rechteprüfung SQL_MANAGER) |
|
||||||
|
| StRS-1202 | SyRS-1213 | SwRS-1237 | TextModuleBL.GetTextModule (dreistufige Kaskade) |
|
||||||
|
| StRS-1202 | SyRS-1213 | SwRS-1238 | TextModuleBL.ReplaceCustomerTextBlockVariables ("@@") |
|
||||||
|
| StRS-1203 | SyRS-1214 | SwRS-1239 | ManagedBackgroundService.GetIsEnabledCached/GetDelayWithBackoff |
|
||||||
|
| StRS-1203 | SyRS-1214 | SwRS-1240 | DataQualityService.ExecuteService (Task-Isolation) |
|
||||||
|
| StRS-1202, StRS-1203 | SyRS-1215 | SwRS-1241 | EscalationTypeSettingViewModel.EscTypeVM_To_DTO (Hour1-3, StageReceivers) |
|
||||||
|
| StRS-1204 | SyRS-1216 | SwRS-1242 | PdfSigningBL.SavePdfSigningSettings (Rechteprüfung + AES) |
|
||||||
|
| StRS-1204 | SyRS-1216 | SwRS-1243 | PdfSigningBL.SignPdfDocument (Pkcs7Signer/SHA256/TSA) |
|
||||||
|
| StRS-1204 | SyRS-1216 | SwRS-1244 | PdfExportSettingsViewModel.InitializeDropdownLists (PDF/A-Stufen) |
|
||||||
|
| StRS-1203 | SyRS-1217 | SwRS-1248 | docker\compose\compose.yaml + CentronService.cs |
|
||||||
|
| StRS-1202 | SyRS-1218 | SwRS-1246 | HourlySurchargeRateItemViewModel.UpdateInvalidRatesReasons + HourlySurchargeRateLog |
|
||||||
|
| StRS-1203 | SyRS-1219 | SwRS-1247 | UpdateAvailableNotificationBL.ShowUpdatesFor |
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
{"is_error":false,"duration_api_ms":15462451,"num_turns":2,"stop_reason":"end_turn","session_id":"73f6a03e-8aed-4897-8d13-e9e10ba3a32b","total_cost_usd":205.92314750000008,"usage":{"input_tokens":4,"cache_creation_input_tokens":1791,"cache_read_input_tokens":453523,"output_tokens":2278,"output_tokens_details":{"thinking_tokens":253},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":1791,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":1575,"cache_read_input_tokens":227183,"cache_creation_input_tokens":948,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":948},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6962,"outputTokens":29,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.0071070000000000005,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-fable-5":{"inputTokens":1626,"outputTokens":1343904,"cacheReadInputTokens":92177958,"cacheCreationInputTokens":3603520,"webSearchRequests":0,"costUSD":205.91604050000007,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","origin":{"kind":"task-notification"},"subagent_stats":{"spawned":18,"requested":{"background":0,"foreground":0,"unset":18},"started_in_background":18,"max_depth":1,"spawned_by_subagents":0,"completed":16,"failed":2,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{"general-purpose":18}},"subtype":"success","api_error_status":null,"result":"Der Lauf ist abgeschlossen. Alle sieben Ergebnisdateien liegen im Verzeichnis `Ergebnisse\\` und sind konsistenzgeprüft.\n\n## Ergebnis\n\n**413 Anforderungen** aus der gesamten Codebasis der c-entron ERP-Suite, verteilt auf drei Ebenen nach ISO/IEC/IEEE 29148: **50 StRS**, **122 SyRS**, **241 SwRS** — dazu Traceability (269 Ketten StRS↔SyRS↔SwRS), 16 Hypothesen, 203 Glossarbegriffe und der Analysebericht mit Modulinventar, Abdeckungstabelle und Konsistenzcheck.\n\n**Vorgehen:** Vor der ersten Anforderung wurde ein Modulinventar mit 96 Modulen erstellt (Schritt 0), danach in 12 parallelen Analyse-Clustern (Sicherheit, Finanzen/Abrechnung, Vertrieb, Lager/Einkauf, Helpdesk, Stammdaten, Kommunikation, Web/Schnittstellen, Integrationen, Produktion/Reporting, Plattform, Administration) mit eigenen ID-Nummernkreisen gearbeitet — erst Mindestabdeckung, dann Vertiefung nach Risiko.\n\n**Kennzahlen aus dem skriptgestützten Konsistenzcheck:**\n- Mindestabdeckung erfüllt: alle 96 Module haben ≥1 Anforderung (42 tief, 48 mittel, 6 flach, 0 nicht analysiert)\n- Keine doppelten IDs, keine Anforderung ohne Beleg, Prüfidee oder Übernahmewürdigkeit, keine toten Tracelinks\n- **198 risikorelevante Anforderungen** (Sicherheit/Abrechnung/Berechtigungen): jede mit PRIMÄR-Beleg inkl. durchsetzender Stelle oder als Hypothese gekennzeichnet — 0 Verstöße; die Liste steht vollständig im Analysebericht\n- `Hypothesen.md` deckungsgleich mit den 16 Inline-Markierungen (3,9 % Hypothesenquote)\n- 44 Konsolidierungskandidaten, alle 21 nicht-funktionalen Anforderungen mit ISO-25010-`Qualitätsmerkmal`\n\n**Fachlich wichtigste Befunde:** Der im Prompt genannte Konsolidierungsfall (Stammblätter vs. Assets) wurde bestätigt und auf **drei** Gerätedatenhaltungen erweitert; daneben ~20 weitere Doppelimplementierungen (zwei Berechtigungssysteme, drei E-Rechnungs-Generatoren, Inventur/Kommissionierung alt/neu, zwei Settings-Datenhaltungen u. a.). Für die SaaS-Neuimplementierung kritisch: ungesalzene SHA1-Passworthashes, hartkodierte Secrets (AES-Fallback, finAPI), fehlende datenraumtrennende Mandantenfähigkeit, keine Schreibsperre für festgeschriebene Rechnungen, sowie fünf als Hypothese dokumentierte Verdachtsfälle nur clientseitiger Rechteprüfung.\n\nZwei Hinweise zur Durchführung: Zwei Analyse-Agenten brachen unterwegs an API-Fehlern ab und wurden mit erhaltenem Kontext erfolgreich fortgesetzt; da Shell-Schreibzugriffe auf das Ausgabeverzeichnis von der Rechtekonfiguration verweigert wurden, erfolgte die Zusammenführung der großen Dateien über Subagenten mit dem Write-Tool (jeweils byteidentisch gegen die Quellkonkatenation verifiziert). Die Codebasis selbst wurde ausschließlich gelesen.","ttft_ms":5456,"ttft_stream_ms":3850,"time_to_request_ms":10,"type":"result","duration_ms":36521,"uuid":"466ea4d1-f66d-4d0f-9eaf-aefc1a731d26","queued_turn_count":0}
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
|
||||||
+178
@@ -0,0 +1,178 @@
|
|||||||
|
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
|
||||||
|
|
||||||
|
## Metadaten
|
||||||
|
- **Versuch:** V1 Baseline (Prompt-only)
|
||||||
|
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
|
||||||
|
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||||
|
- **Zeitstempel:** 2026-08-26
|
||||||
|
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
|
||||||
|
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||||
|
|
||||||
|
| Änderung | Auslösender Befund |
|
||||||
|
|---|---|
|
||||||
|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
|
||||||
|
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
|
||||||
|
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
|
||||||
|
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
|
||||||
|
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
|
||||||
|
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
|
||||||
|
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
|
||||||
|
|
||||||
|
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
|
||||||
|
|
||||||
|
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||||
|
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||||
|
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Prompt
|
||||||
|
|
||||||
|
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||||
|
|
||||||
|
### Auftrag
|
||||||
|
|
||||||
|
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||||
|
|
||||||
|
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||||
|
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||||
|
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||||
|
|
||||||
|
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||||
|
|
||||||
|
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||||
|
|
||||||
|
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
**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. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
|
||||||
|
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||||
|
|
||||||
|
### Formatvorgabe pro Anforderung
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||||
|
Titel: <kurzer Titel>
|
||||||
|
Ebene: <StRS | SyRS | SwRS>
|
||||||
|
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||||
|
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)
|
||||||
|
|
||||||
|
```
|
||||||
|
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)
|
||||||
|
```
|
||||||
|
|
||||||
|
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?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||||
|
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien, das Ausführen von
|
||||||
|
Kommandozeilenbefehlen im Arbeitsverzeichnis sowie die werkzeugeigenen Subagenten.
|
||||||
|
Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
|
||||||
|
Werkzeugserver.
|
||||||
|
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||||
|
Werkzeuge zu ersetzen.
|
||||||
|
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||||
|
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||||
|
`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-fable-5\builtin\high\02_Lauf_2026-08-27_095953_v7.0.0-6ce6\Ergebnisse\`.
|
||||||
|
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-27T11:09:58.0288148+02:00
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-27T09:59:53.7439250+02:00
|
||||||
+195
@@ -0,0 +1,195 @@
|
|||||||
|
# Analysebericht – Reverse Requirements Engineering c-entron ERP-Suite
|
||||||
|
|
||||||
|
Lauf: 02_Lauf_2026-08-26_195958_v7.0.0-77a1 (Baseline Prompt-only, Iteration 02)
|
||||||
|
Untersuchungsgegenstand: gesamte Codebasis `C:\DEV\MasterArbeit\QuellCode\CentronERP` (nur lesend).
|
||||||
|
|
||||||
|
Dieser Bericht enthält:
|
||||||
|
1. Modulinventar (Schritt 0 – erstellt **vor** der ersten Anforderung)
|
||||||
|
2. Abdeckungstabelle (wird nach Abschluss der Anforderungserhebung gefüllt)
|
||||||
|
3. Konsistenzcheck
|
||||||
|
4. Liste der risikorelevanten Anforderungen mit Belegsituation
|
||||||
|
5. Selbstbewertung
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Modulinventar (Schritt 0)
|
||||||
|
|
||||||
|
Grundlage: Verzeichnisstruktur `src/` (backend/centron/nexus/shared/webservice/apis), `docs/`,
|
||||||
|
`deployment/`, `docker/`, `scripts/`, `tests/` sowie Wurzeldateien (`SSMS_DB_SCHEMA.sql`,
|
||||||
|
`CentronRights.md`). Die fachlichen Module wurden primär aus den Fachordnern von
|
||||||
|
`src/backend/Centron.BL` (Geschäftslogik), den UI-Modulen `src/centron/Centron.WPF.UI/Modules`
|
||||||
|
und den Web-Bereichen `src/nexus/CentronNexus` abgeleitet. Pfade sind relativ zum
|
||||||
|
Arbeitsverzeichnis. Das Inventar darf ergänzt, aber nicht gekürzt werden.
|
||||||
|
|
||||||
|
| Nr. | Modul / Komponente | Pfad | Fachliche Aufgabe (1 Satz) |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M001 | Belegwesen-Kern | src/backend/Centron.BL/Sales/Receipts (ReceiptBL.cs, SpecificLogics.cs) | Gemeinsame Logik aller Belegarten: Laden, Speichern, Statusführung, Nummernvergabe, Preisberechnung, Versionierung. |
|
||||||
|
| M002 | Angebote | src/backend/Centron.BL/Sales/Receipts/Offers | Erstellung und Verwaltung von Kundenangeboten (AngKopf/AngPos). |
|
||||||
|
| M003 | Aufträge | src/backend/Centron.BL/Sales/Receipts/Orders | Verwaltung von Kundenaufträgen (AufKopf/AufPos) inkl. Überführung in Folgebelege. |
|
||||||
|
| M004 | Lieferscheine | src/backend/Centron.BL/Sales/Receipts/DeliveryLists | Verwaltung von Lieferscheinen (LiefKopf/LiefPos). |
|
||||||
|
| M005 | Rechnungen | src/backend/Centron.BL/Sales/Receipts/Invoices | Verwaltung von Ausgangsrechnungen (RechKopf/RechPos). |
|
||||||
|
| M006 | Gutschriften | src/backend/Centron.BL/Sales/Receipts/CreditVouchers | Verwaltung von Gutschriften (GutKopf/GutPos). |
|
||||||
|
| M007 | Abholscheine | src/backend/Centron.BL/Sales/Receipts/PickupLists, .../PickUps | Verwaltung von Abholscheinen (AbholKopf/AbholPos). |
|
||||||
|
| M008 | Verträge | src/backend/Centron.BL/Sales/Receipts/ContractLists, .../LeasingAndService | Verwaltung von Service-/Wartungsverträgen (VertragKopf/VertragPos) mit Laufzeiten, Kontingenten und Gerätelisten. |
|
||||||
|
| M009 | Vertragsabrechnung | src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura | Automatische Fakturierung von Verträgen, Aufträgen, Lieferscheinen und Tickets (Intervalle, Kontingente, Klickzähler). |
|
||||||
|
| M010 | Mahnwesen | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning | Mahnläufe über offene Rechnungen mit Mahnstufen, Mahnstopp und Mahnreports. |
|
||||||
|
| M011 | Offene Posten (OPOS) | src/backend/Centron.BL/Sales/Receipts/Invoices/Opos | Verwaltung und Auswertung offener Posten. |
|
||||||
|
| M012 | Anzahlungen | src/backend/Centron.BL/Sales/Receipts/DownPayment | Abbildung von Anzahlungen im Belegfluss. |
|
||||||
|
| M013 | Warenkorb & Freigabewesen | src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs, ReceiptCartReleaseSystemBL.cs | Warenkörbe von Web-Accounts mit mehrstufigem Prüf-/Freigabe-/Bestellprozess. |
|
||||||
|
| M014 | Lieferantenbelege | src/backend/Centron.BL/Sales/Receipts/Supplier* | Bestellungen, Wareneingänge, Eingangsrechnungen und Lieferantengutschriften. |
|
||||||
|
| M015 | Provisionen | src/backend/Centron.BL/Sales/Receipts/ReceiptProvision*.cs | Provisionsschemata, -ziele und -stufen für Vertriebsmitarbeiter. |
|
||||||
|
| M016 | Kassenbuch | src/backend/Centron.BL/Sales/CashBooks | Kassenbücher mit Buchungen und Belegen je Filiale. |
|
||||||
|
| M017 | Preisfindung & Kalkulation | src/backend/Centron.BL/Sales/Receipts/ReceiptPriceHelperBL.cs; Centron.BL/Warehousing/ActionPriceBL.cs, ArticleVolumePricesBL.cs; Sales/Support/CustomerSpecialArticleBL.cs | Berechnung von Positions-/Belegpreisen, MwSt., Rabatten, Aktions-, Staffel- und Sonderpreisen. |
|
||||||
|
| M018 | Schweiz-Sonderlogik | src/backend/Centron.BL/Sales/Receipts/Switzerland | Landesspezifische Sonderbehandlung für Schweizer Belege. |
|
||||||
|
| M019 | Belegvorlagen | src/backend/Centron.BL/Sales/Receipts/ReceiptTemplateBL.cs | Belegvorlagen über einen definierten Vorlagen-Kunden. |
|
||||||
|
| M020 | Marketing | src/backend/Centron.BL/Sales/Marketing | Marketingaktionen/-kampagnen im Vertriebsumfeld. |
|
||||||
|
| M021 | CRM-Projekte | src/backend/Centron.BL/Sales/Customers/CrmProjects | Vertriebschancen/CRM-Projekte zu Kunden. |
|
||||||
|
| M022 | Kundenstamm (Alt-Struktur) | src/backend/Centron.BL/Sales/Customers | Verwaltung der Kunden (Tabelle Kunden) mit Kreditlimit, Sperren und Zuordnungen. |
|
||||||
|
| M023 | Stundensatz-Zuschläge | src/backend/Centron.BL/Sales/HourlySurchargeRatesBL | Zuschlagsätze auf Stundensätze (z. B. nach Zeit/Art). |
|
||||||
|
| M024 | Dokumentations-Assistent | src/backend/Centron.BL/Sales/DocumentationWizardArea | Geführte Erstellung von Dokumentationen. |
|
||||||
|
| M025 | Helpdesk/Ticketsystem | src/backend/Centron.BL/Sales/Support (HelpdeskBL.cs u. a.) | Störungs-/Serviceticketverwaltung mit Status, Typen, Kategorien, Prioritäten, Historie und Mailversand. |
|
||||||
|
| M026 | Ticket-Zeiterfassung | src/backend/Centron.BL/Sales/Support/HelpdeskTimer*.cs | Erfassung, Signatur, Verschiebung und Abrechnung von Arbeitszeiten auf Tickets. |
|
||||||
|
| M027 | Ticket-Eskalation | src/backend/Centron.BL/Sales/Support/Escalation | Eskalationsregeln und -überwachung für Tickets. |
|
||||||
|
| M028 | Ticketvorlagen/Prozesse (C-FLOW) | src/backend/Centron.BL/Sales/Support/TicketProcess, HelpdeskPatternBL.cs, HelpdeskCreationTemplateBL.cs | Ticketvorlagen und automatische Tickerzeugung nach Vorlagen/Prozessen. |
|
||||||
|
| M029 | Ticketprojekte | src/backend/Centron.BL/TicketProjects; Sales/Support/TicketProject*.cs | Bündelung von Tickets zu Projekten mit Aufgaben und Abhängigkeiten. |
|
||||||
|
| M030 | Externe Helpdesks | src/backend/Centron.BL/ExternalHelpdesk | Konfiguration der Kopplung zu Fremd-Ticketsystemen. |
|
||||||
|
| M031 | Support-Level | src/backend/Centron.BL/Sales/Support/SupportLevelBL.cs | Verwaltung von Support-Leveln (z. B. SLA-Stufen) für Kunden/Tickets. |
|
||||||
|
| M032 | Kundengeräte/Assets | src/backend/Centron.BL/Sales/CustomerAssets; Centron.BL/Devices | Verwaltung der beim Kunden befindlichen Geräte/Assets inkl. Stammdatenlisten und Historie. |
|
||||||
|
| M033 | RMA | src/backend/Centron.BL/CustomerArea/RmaBL.cs; UI: Modules/Rma | Reklamations-/Rücksendeabwicklung mit Artikeln und Historie. |
|
||||||
|
| M034 | Checklisten | src/backend/Centron.BL/CheckListArea | Checklistenvorlagen und Checklisten an Objekten (v. a. Tickets). |
|
||||||
|
| M035 | Umfragen | src/centron/Centron.WPF.UI/Modules/Survey; BL: HelpdeskSurveyProcess (Sales/Support) | Erstellung und Versand von Kundenumfragen, u. a. beim Ticketabschluss. |
|
||||||
|
| M036 | TaskManager | src/backend/Centron.BL/TaskManager | Zeit-/ereignisgesteuerte Aufgaben (Tasks) mit Aktionen und Ausführungsprotokoll. |
|
||||||
|
| M037 | Nexus-Ticketansichten | src/backend/Centron.BL/NexusTicketViews | Konfigurierbare Ticket-Listenansichten für den Webclient. |
|
||||||
|
| M038 | Einkauf/Bestellwesen | src/backend/Centron.BL/Purchasing, Centron.BL/Buying | Lieferantenbestellungen je Filiale und Einkaufsunterstützung. |
|
||||||
|
| M039 | Lager/Bestandsführung | src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs; Logistics/LogisticSettings | Verwaltung von Lagern, Lagerorten, Umbuchungen und Bestandslogik. |
|
||||||
|
| M040 | Inventur | src/backend/Centron.BL/Storage (StorageBL.cs, InventoryArticlePool.cs) | Inventurdurchführung mit Zähllisten und Bestandsabgleich. |
|
||||||
|
| M041 | Artikelstamm | src/backend/Centron.BL/Warehousing (ArticleBL.cs u. a.) | Verwaltung der Artikel (ARTIK) mit Einheiten, Varianten, Logs und Sonderartikeln. |
|
||||||
|
| M042 | Barcode | src/backend/Centron.BL/Warehousing/Barcode*.cs | Barcodeverwaltung inkl. Historie und Bedingungen. |
|
||||||
|
| M043 | Produktion | src/backend/Centron.BL/Production | Fertigungsaufträge mit Positionen und Protokoll. |
|
||||||
|
| M044 | TradePool | src/backend/Centron.BL/TradePool | Import/Verwaltung von Handelsware-Pools (Distributorenartikel) und Kundenzuordnung. |
|
||||||
|
| M045 | Produktmatrix | src/backend/Centron.BL/ProductMatrix | Bewertungsmatrix Kunde × Produktkategorie (IT-Portfolio-Beratung). |
|
||||||
|
| M046 | Produktlebenszyklus | src/backend/Centron.BL/Finances/ProductLifecycleBL.cs | Lebenszyklusdaten zu Produkten (z. B. EOL) für Beratung/Planung. |
|
||||||
|
| M047 | Konten-/Adressstamm (Accounts) | src/backend/Centron.BL/Accounts | Neuer vereinheitlichter Konten-/Adress-/Kontaktstamm (Accounts) mit Kunden-/Lieferantenrollen. |
|
||||||
|
| M048 | Lieferantenstamm | src/backend/Centron.BL/BusinessPartner | Suche/Verwaltung von Lieferanten und Lieferanten-Assets. |
|
||||||
|
| M049 | Mitarbeiter/Personal | src/backend/Centron.BL/EmployeeArea | Mitarbeiterstamm mit Abteilungen, Urlaub, RFID-Token, Benutzerzuordnung. |
|
||||||
|
| M050 | Länder/Bundesländer | src/backend/Centron.BL/CountryArea | Länder- und Bundeslandstamm inkl. Währungsangaben. |
|
||||||
|
| M051 | Kostenstellen/Kostenträger | src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter; DB: Kostenstellen, Kostentraeger | Verwaltung von Kostenstellen und Kostenträgern. |
|
||||||
|
| M052 | CRM-Kataloge | src/backend/Centron.BL/CustomerArea (BusinessLineBL, InterestBL, ProductBL, ContactActivityBL, ContactDepartmentBL) | Katalogdaten für CRM: Branchen, Interessen, Produkte, Kontaktaktivitäten. |
|
||||||
|
| M053 | Textmodule/Anreden | src/backend/Centron.BL/TextModuleArea | Textbausteine sowie Anrede-/Grußformel-Ersetzung. |
|
||||||
|
| M054 | Tags | src/backend/Centron.BL/Tags | Freie Verschlagwortung (v. a. Tickets). |
|
||||||
|
| M055 | FiBu-Export/-Import | src/backend/Centron.BL/DataExchange/BookKeeping; Administration/BookKeepingAccountSystems | Übergabe von Stammdaten, Belegen und Kassenbuch an Finanzbuchhaltungen (u. a. DATEV, Abacus) und Rückimport. |
|
||||||
|
| M056 | Zahlungsverkehr (SEPA) | src/backend/Centron.BL/DataExchange/PaymentTransactions | Export von Lastschriften/Zahlungen als SEPA-XML (pain.008-Varianten). |
|
||||||
|
| M057 | Zahlungseingänge | src/backend/Centron.BL/Finances/IncomingPayments | Erfassung/Protokollierung von Zahlungseingängen auf Rechnungen. |
|
||||||
|
| M058 | OnlineBanking (finAPI) | src/backend/Centron.BL/Finances/OnlineBanking; src/apis/Centron.APIs.FinAPI | Abruf von Kontoumsätzen über finAPI und Zuordnung zu Belegen. |
|
||||||
|
| M059 | Bankkonten | src/backend/Centron.BL/Accounting/BankAccountBL.cs | Verwaltung von Bankverbindungen von Kunden/Firmen. |
|
||||||
|
| M060 | E-Rechnung | docs/reference/zugferd-field-mapping.md; docs/guides/development/xrechnung.md; src/apis/Centron.Api.EbInterface | Erzeugung elektronischer Rechnungen (ZUGFeRD/XRechnung, ebInterface AT). |
|
||||||
|
| M061 | Gutschein-/Voucherverwaltung | src/backend/Centron.BL/VoucherManagement | Verwaltung von Gutschein-Barcodes. |
|
||||||
|
| M062 | Finanzen Sonstiges | src/backend/Centron.BL/Finances/Payments, Finances/ActivitySettings | Zahlungsarten/Aktivitätseinstellungen im Finanzumfeld. |
|
||||||
|
| M063 | Authentifizierung | src/backend/Centron.BL/Administration/Logins/Auth | Anmeldung per Benutzername/Passwort, Active Directory, OpenID Connect (Entra ID) und Web-Account. |
|
||||||
|
| M064 | Zwei-Faktor-Authentifizierung | src/backend/Centron.BL/Administration/Logins/TwoFactor; Centron.BL/TwoFactorAuthenticator | Zweiter Faktor per RADIUS oder E-Mail-Link mit Gültigkeitsdauer je Gerät. |
|
||||||
|
| M065 | Benutzerverwaltung | src/backend/Centron.BL/Administration/Logins/UsersBL.cs; EmployeeArea/AppUserBL.cs | Verwaltung der Anwendungsbenutzer (Sichbenu) inkl. Deaktivierungszeiträumen. |
|
||||||
|
| M066 | Web-Accounts | src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs | Logins für Endkunden-Kontakte (Portal/Shop) mit Statusprüfung. |
|
||||||
|
| M067 | Rechteverwaltung | src/backend/Centron.BL/Administration/Rights; CentronRights.md; webservice/.../UserRightsConst.cs | Rechte/Gruppen (Sichtrus/Sichmemb/Sichbenu) inkl. einschränkender Rechte (nur eigene / eigene Filiale). |
|
||||||
|
| M068 | Lizenzierung | src/backend/Centron.BL/Administration/Licensing | Prüfung von Produktlizenzen, Versionsbeschränkung und paralleler Nutzeranzahl. |
|
||||||
|
| M069 | Sitzungs-/Ticketverwaltung | src/backend/Centron.BL/Administration/Logins/TicketBL.cs, AuthenticationTicketBL.cs | Vergabe/Wiederverwendung von Anmelde-Tickets je Anwendung/Maschine. |
|
||||||
|
| M070 | Anwendungseinstellungen | src/backend/Centron.BL/Administration/Settings; Centron.Interfaces/Administration/Settings | Zentrale, typisierte Konfiguration (ApplicationSettings) mit Definitionen und Gruppen. |
|
||||||
|
| M071 | Mandanten | src/backend/Centron.BL/Administration/Company/MandatorBL.cs | Mandantenverwaltung. |
|
||||||
|
| M072 | Filialen | src/backend/Centron.BL/Administration/Company/BranchBL.cs | Filialverwaltung inkl. filialbezogener Konten und Läger. |
|
||||||
|
| M073 | Nummernkreise | src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs; Administration/Mandatory | Vergabe fortlaufender Nummern je Objektart (und Filiale) mit Kollisionsschutz. |
|
||||||
|
| M074 | DB-Migrationsskripte | src/backend/Centron.BL/Administration/Scripts (ScriptMethods) | Versionierte Datenbank-Migrations-/Wartungsskripte. |
|
||||||
|
| M075 | DSGVO/Datensicherheit | src/backend/Centron.BL/Administration/DataSecurity; WebServices/Administration/Documents/Dsgvo | Datenschutzfunktionen (DSGVO-Dokumente, Datensicherheit). |
|
||||||
|
| M076 | Dokumente/Dateiverwaltung | src/backend/Centron.BL/Administration/Documents, FileManagement; WPF: CentronFileSystem | Ablage und Verwaltung von Dokumenten/Dateien zu Objekten. |
|
||||||
|
| M077 | Hintergrunddienste | src/backend/Centron.BL/Administration/BackgroundServices; docs/Background Service | Serverseitige Hintergrundverarbeitung (z. B. Datenqualitätsdienst). |
|
||||||
|
| M078 | AccessTokens | src/backend/Centron.BL/Administration/AccessTokens | Verwaltung von API-/Zugriffstokens. |
|
||||||
|
| M079 | Telemetrie | src/backend/Centron.BL/Telemetry | Erfassung von Nutzungsdaten (API-Aufrufe, KI-/MCP-Toolnutzung). |
|
||||||
|
| M080 | Themes/Customizing | src/backend/Centron.BL/Administration/Themes, Customization; Centron.BL/Customizations/CustomTables | Oberflächen-Themes und kundenspezifische Erweiterungen/Zusatztabellen. |
|
||||||
|
| M081 | SQL-/Systemdiagnose | src/backend/Centron.BL/Administration/SQLManagement, NetworkDiagnostics, Profiling, PerformanceTests | Administrative Diagnose- und Wartungswerkzeuge. |
|
||||||
|
| M082 | Passwortverwaltung (Kundenzugänge) | src/backend/Centron.BL/PasswordManagementArea, PasswordManager | Verschlüsselte Ablage von Zugangsdaten mit Zugriffs-/Änderungsprotokoll. |
|
||||||
|
| M083 | Mail | src/backend/Centron.BL/Mail | Mailkonten, -einstellungen, -signaturen und Mailversand. |
|
||||||
|
| M084 | MailScanner | src/backend/Centron.BL/MailScanner | Überwachung von Postfächern und regelbasierte Verarbeitung (z. B. Ticketerzeugung). |
|
||||||
|
| M085 | Mailings/Newsletter | src/backend/Centron.BL/Mailings | Serienmails/Newsletter mit Vorlagen. |
|
||||||
|
| M086 | Kalender/Termine | src/backend/Centron.BL/Calendar, AppointmentRequests; Sales/Calendar | Terminkalender inkl. Terminwünschen und Synchronisationseinstellungen. |
|
||||||
|
| M087 | Chats | src/backend/Centron.BL/Chats | Interner Chat mit Gruppen, Nachrichten, Bearbeiten/Löschen. |
|
||||||
|
| M088 | SocialMedia-Feed | src/backend/Centron.BL/SocialMedia | Interner Aktivitäten-Feed mit Kommentaren, Likes und Abos auf Objekte. |
|
||||||
|
| M089 | TAPI-Telefonie | src/backend/Centron.BL/Tapi; assemblies/tapi | Telefonie-Integration: Anruferkennung, Anrufprotokolle, Kontaktsuche per Rufnummer. |
|
||||||
|
| M090 | ToDo | src/backend/Centron.BL/ToDoArea | Aufgaben-/Wiedervorlagenverwaltung an Objekten. |
|
||||||
|
| M091 | MyDay/MyCentron | src/backend/Centron.BL/MyDay, MyCentron | Persönliche Tagesübersicht (Arbeitsvorrat) und zuletzt verwendete Objekte. |
|
||||||
|
| M092 | Benachrichtigungen | src/backend/Centron.BL/Notifications, NexusNotifications | Benutzerbenachrichtigungen im Client und Web (SignalR-Hub). |
|
||||||
|
| M093 | Outlook-Integration | src/nexus/CentronNexus.OutlookAddIn; Centron.BL/Outlook; assemblies/outlook | Outlook-AddIn zur Verbindung von E-Mails mit c-entron-Objekten. |
|
||||||
|
| M094 | WebLinks/Kurz-URLs | src/backend/Centron.BL/WebLinks, Urls | Verwaltete Weblinks mit Aktionen und Klick-Protokoll sowie einfache URL-Verwaltung. |
|
||||||
|
| M095 | Mobile | src/backend/Centron.BL/Mobile | Datenbereitstellung für die mobile Nutzung (mobile Mitarbeiter). |
|
||||||
|
| M096 | ReportEngine (FastReport) | src/backend/Centron.BL/ReportEngine | Berichtsdefinitionen, -gruppen, -abfragen und Standardberichte je Ausgabekanal. |
|
||||||
|
| M097 | Berichte (Alt) | src/backend/Centron.BL/Reporting; UI: Modules/Reports | Verwaltung/Rendern klassischer Berichte. |
|
||||||
|
| M098 | Statistiken | src/backend/Centron.BL/Statistics | Umsatz-, Auftrags-, Ticket-, Vertrags- und MSP-Statistiken. |
|
||||||
|
| M099 | Volltextsuche | src/backend/Centron.BL/IndexSearch | Lucene-basierter Volltextindex mit deutschem Analyzer über Fachobjekte. |
|
||||||
|
| M100 | Massenupdates | src/backend/Centron.BL/MassUpdate; UI: Modules/Massenupdates | Massenänderungen an Belegen, Artikeln und Kontodaten über Vorlagen. |
|
||||||
|
| M101 | Änderungsverfolgung | src/backend/Centron.DAO/ChangeTracking; Centron.BL/ChangeTracking | Feldgenaue Änderungsprotokolle (ChangeLog) über NHibernate-Events. |
|
||||||
|
| M102 | Import-Historie | src/backend/Centron.BL/ChangeTracking/History (ImportHistoryBL.cs) | Protokollierung durchgeführter Datenimporte. |
|
||||||
|
| M103 | Erwartete Ereignisse | src/backend/Centron.BL/ExpectedEvents | Überwachung erwarteter Ereignisse (Log je Konto) mit Fehlverhaltensanzeige. |
|
||||||
|
| M104 | Prozesse (Langläufer) | src/backend/Centron.BL/Processes | Verwaltung langlaufender Verarbeitungsprozesse. |
|
||||||
|
| M105 | Fachliche Transaktionen | src/backend/Centron.BL/Transactions | Protokollierung fachlicher Transaktionen mit Details je Benutzer. |
|
||||||
|
| M106 | KI-Funktionen | src/backend/Centron.BL/ArtificialIntelligence; Administration/ArtificialIntelligence | Anbindung von KI-Modellen (u. a. OpenAI-kompatibel) für Ticket-Kategorisierung, Textbewertung, Zusammenfassungen. |
|
||||||
|
| M107 | EDI | src/backend/Centron.BL/EDI; DataExchange/EDI; src/backend/Centron.Gateway | Elektronischer Belegaustausch mit Distributoren (ALSO, Alltron, Herweck, Komsa, OpenTrans 2.1 u. a.). |
|
||||||
|
| M108 | docuFORM | Centron.Api.docuFORM; Centron.BL/DataExchange/DocuForm | Anbindung docuFORM (Druckerzähler/Verbrauchsdaten). |
|
||||||
|
| M109 | RMM-/AssetManagement-Connector | src/backend/Centron.BL/DataExchange/Rmm; Centron.BL/DocuBoard (AssetManagement*) | Anbindung von Remote-Monitoring-Systemen und Übernahme erkannter Geräte. |
|
||||||
|
| M110 | TANSS-Schnittstelle | src/backend/Centron.BL/DataExchange/TanssInterfaces | Datenaustausch mit TANSS. |
|
||||||
|
| M111 | Telekom DIVE | src/backend/Centron.BL/DataExchange/TelekomDive; UI: Modules/TelekomDive | Export von Artikel-/Kategoriedaten an Telekom DIVE. |
|
||||||
|
| M112 | GfK-Export | src/backend/Centron.BL/DataExchange/GfkExport | Meldung von Abverkaufsdaten an GfK. |
|
||||||
|
| M113 | Datenimport | src/backend/Centron.BL/DataExchange/Import, Connectors | Generische Importe und Konnektoren. |
|
||||||
|
| M114 | ITscope | src/apis/Centron.APIs.ITscopeDataAccess | Anbindung ITscope (Distributorenkatalog/Bestellung). |
|
||||||
|
| M115 | Icecat | src/apis/Centron.APIs.IcecatDataAccess | Übernahme von Artikelstammdaten aus Icecat. |
|
||||||
|
| M116 | COP | src/apis/Centron.APIs.CopDataAccess | SOAP-Anbindung COP (Distributor). |
|
||||||
|
| M117 | EGIS | src/apis/Centron.APIs.EgisDataAccess; Centron.BL/EDI/EGIS | Anbindung EGIS (Warenkorb/Bestellungen). |
|
||||||
|
| M118 | GLS-Versand | src/apis/Centron.Api.Gls | Erzeugung von GLS-Versandaufträgen/Labels. |
|
||||||
|
| M119 | Shipcloud-Versand | src/apis/Centron.Api.Shipcloud; Sales/Receipts/ShipcloudPackageTemplateBL.cs | Versandabwicklung über Shipcloud inkl. Pakettemplates. |
|
||||||
|
| M120 | RiverDivo/Riverbird | src/backend/Centron.BL/RiverDivo; deployment/riverbird | Kopplung an Riverbird/RiverDivo (Remote-Zugriff/Servicedaten). |
|
||||||
|
| M121 | C-Pra | src/backend/Centron.BL/CPra | Anbindung C-Pra (WebHooks). |
|
||||||
|
| M122 | ES-Integrationen | src/backend/Centron.BL/Integrations (EsCustomerGroupBL, EsRoleBL) | Rollen-/Kundengruppenabgleich mit einem externen System (ES). |
|
||||||
|
| M123 | Custom Gateway | src/backend/Centron.BL/Gateway; WebServices/Gateway | Konfigurierbares Gateway für kundenspezifische externe Aufrufe. |
|
||||||
|
| M124 | Objekt-Fremdreferenzen | src/backend/Centron.BL/ObjectExternalReferences | Zuordnung externer IDs zu c-entron-Objekten. |
|
||||||
|
| M125 | SelfCare-Formulare | src/backend/Centron.BL/SelfCare | Konfigurierbare Web-Formulare (Self-Service) mit Status. |
|
||||||
|
| M126 | Externe Tools | src/backend/Centron.BL/ExternalToolsBL, Tools; UI: Modules/ExternalTool | Einbindung externer Programme mit Variablenübergabe. |
|
||||||
|
| M127 | VideoPortal | src/backend/Centron.BL/VideoPortal | Zuordnung von Schulungs-/Videoinhalten. |
|
||||||
|
| M128 | IT-Planner | src/backend/Centron.BL/ItPlanner | Checklisten-/Planungsobjekte für IT-Planungen. |
|
||||||
|
| M129 | DocuBoard | src/backend/Centron.BL/DocuBoard | Verwaltung AssetManagement-Partner/Artikelzuordnungen (Dokumentationsboard). |
|
||||||
|
| M130 | WPF-Client (Shell) | src/centron/Centron.WPF.UI | Windows-Desktop-Client: Modulrahmen, Navigation, Layouts, Dialoge, Lokalisierung. |
|
||||||
|
| M131 | Webservice/Backend-Host | src/webservice (Centron.Host, Centron.WebServices.Core, Centron.Host.WindowsService, Centron.Host.Console) | Zentraler Anwendungsserver (SOAP/REST) als Windows-Dienst, Konsole oder Container. |
|
||||||
|
| M132 | REST-API v1 | src/webservice/Centron.Controllers | Versionierte REST-Schnittstelle mit JWT-Authentifizierung und Rechte-Attributen. |
|
||||||
|
| M133 | Nexus-Webclient | src/nexus/CentronNexus, CentronNexus.Host | Blazor-Webclient (ServiceBoard, Management, Office, WebCart, WebOffer, Produktionsaufträge, Dokumentensignatur). |
|
||||||
|
| M134 | DAO/Persistenz | src/backend/Centron.DAO | NHibernate-Datenzugriff mit Repositories, Named Queries, RawSQL und Mappings. |
|
||||||
|
| M135 | Entities/Datenmodell | src/backend/Centron.Entities; SSMS_DB_SCHEMA.sql | Entitätsmodell und MSSQL-Schema (1.558 Tabellen, Legacy-Tabellen + englische Views). |
|
||||||
|
| M136 | Basisbibliotheken | src/backend/Centron.Common, Centron.Interfaces; src/shared/Centron.Core, Centron.Controls | Querschnittsfunktionen, Interfaces/DTO-Verträge, WPF-Controls. |
|
||||||
|
| M137 | ConnectionManager | src/webservice/c-entron.misc.ConnectionManager | Werkzeug zur Verwaltung von Verbindungsprofilen. |
|
||||||
|
| M138 | Deployment/Installer | deployment (centron, WixSharpInstaller, riverbird) | Erstellung der Installationspakete. |
|
||||||
|
| M139 | Docker/Linux-Betrieb | docker/; docs/guides/services/web-service-on-linux.md | Containerisierter Betrieb von Webservice, Demo, Mailcatcher, Regressionstest-DB. |
|
||||||
|
| M140 | CI/CD | azure/, .github/workflows | Automatisierte Builds/Pipelines. |
|
||||||
|
| M141 | Tests | tests/ (Integration, EndToEnd, Playwright, Unit) | Automatisierte Test-Suiten. |
|
||||||
|
| M142 | Modulverwaltung | src/backend/Centron.BL/Modules; WPF: Modules/ModuleRegistration.cs | Registrierung/Kategorisierung der Anwendungsmodule inkl. Rechtebindung. |
|
||||||
|
| M143 | Start/Versionsprüfung | src/backend/Centron.BL/Start, WebVersion, WebSuite | Startlogik des Clients inkl. Versionsabgleich mit dem Webservice. |
|
||||||
|
| M144 | GUI-Personalisierung | src/backend/Centron.BL/GUI (UserGridBL.cs); Administration/Themes | Speicherung benutzerspezifischer Grid-/Oberflächeneinstellungen. |
|
||||||
|
| M145 | Caching-Dienste | src/backend/Centron.BL/Services (CachedTableBL.cs) | Serverseitiges Tabellen-Caching. |
|
||||||
|
| M146 | Icons | src/backend/Centron.BL/CentronIcons | Verwaltung der Anwendungs-Icons. |
|
||||||
|
| M147 | Zeitsteuerung | src/backend/Centron.BL/Time (TimingSettingsBL.cs) | Timing-/Zeiterfassungseinstellungen. |
|
||||||
|
| M148 | SystemArea | src/backend/Centron.BL/SystemArea (SystemTableI3DBL.cs) | Systemtabellen-/ID-Verwaltung. |
|
||||||
|
| M149 | Helpers | src/backend/Centron.BL/Helpers | Hilfsfunktionen (PDF, Word-Bilder, Graph-Client, Logging). |
|
||||||
|
| M150 | Kern-Krypto | src/backend/Centron.BL/Core (CryptoUtils.cs, ReplacementBL.cs) | Salz-/Hash-Erzeugung und Platzhalter-Ersetzung. |
|
||||||
|
|
||||||
|
Nachträgliche Ergänzungen des Inventars sind unter „1a. Inventar-Ergänzungen" zu führen (keine vorhanden).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Abdeckungstabelle
|
||||||
|
|
||||||
|
*(wird nach Abschluss der Anforderungserhebung gefüllt – siehe Abschnitt am Ende dieses Dokuments)*
|
||||||
|
|
||||||
|
## 3. Konsistenzcheck
|
||||||
|
|
||||||
|
*(wird nach Abschluss der Anforderungserhebung gefüllt)*
|
||||||
|
|
||||||
|
## 4. Risikorelevante Anforderungen
|
||||||
|
|
||||||
|
*(wird nach Abschluss der Anforderungserhebung gefüllt)*
|
||||||
|
|
||||||
|
## 5. Selbstbewertung
|
||||||
|
|
||||||
|
*(wird nach Abschluss der Anforderungserhebung gefüllt)*
|
||||||
+600
@@ -0,0 +1,600 @@
|
|||||||
|
# StRS – Stakeholder Requirements Specification
|
||||||
|
|
||||||
|
c-entron ERP-Suite (Reverse Requirements Engineering, statische Analyse).
|
||||||
|
Referenzrahmen: ISO/IEC/IEEE 29148:2018. Sprache: Deutsch; technische Bezeichner original.
|
||||||
|
|
||||||
|
**Identifizierte Akteure (aus Code, Rechte-Doku und UI-Ressourcen abgeleitet):**
|
||||||
|
Innendienst/Vertrieb, Servicetechniker, Helpdesk-Mitarbeiter, Buchhaltung, Einkäufer,
|
||||||
|
Lagermitarbeiter, Administrator, Geschäftsführung/Controlling, Endkunde (Web-Account),
|
||||||
|
Mandant/Filiale als Organisationseinheiten, externe Systeme (Distributoren, FiBu, Banken).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-001
|
||||||
|
Titel: Durchgängige Auftragsabwicklung über Belegkette
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Innendienst/Vertrieb
|
||||||
|
Vorbedingung: Kunde und Artikel sind als Stammdaten angelegt.
|
||||||
|
Fakt: Die Codebasis führt die Belegarten Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholschein und Vertrag als eigenständige, gemeinsam verankerte Belegtypen (ReceiptBase-Hierarchie, Tabellen AngKopf/AufKopf/LiefKopf/RechKopf/GutKopf/AbholKopf/VertragKopf).
|
||||||
|
Aussage: Das System soll den Vertriebsprozess vom Angebot über Auftrag und Lieferung bis zur Rechnung/Gutschrift als zusammenhängende Belegkette unterstützen.
|
||||||
|
Ergebnis: Ein Geschäftsvorfall ist über alle Belegstufen dokumentiert und nachvollziehbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs (abstrakte Basisklasse, abstrakte Methode ReceiptKind) – Begründung: gemeinsame Belegbasis aller Belegarten ist im Code verankert.
|
||||||
|
- [SEKUNDÄR] docs/reference/receipts/receipts-backend-architecture.md (Tabelle „Receipt Types Hierarchy") – Begründung: Entwicklerdokumentation benennt alle Belegarten und ihre DB-Tabellen.
|
||||||
|
Prüfidee: Für einen Testkunden Angebot→Auftrag→Lieferschein→Rechnung erzeugen; jede Stufe referenziert die Vorstufe.
|
||||||
|
Tracelinks: SyRS-010, SyRS-011, SyRS-012
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Kernprozess jedes ERP-Systems.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-002
|
||||||
|
Titel: Automatisierte wiederkehrende Vertragsabrechnung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung
|
||||||
|
Vorbedingung: Verträge mit Abrechnungsintervall und Positionen existieren.
|
||||||
|
Fakt: AutomaticFacturaBL/AutomaticFacturaBL.Contracts.cs implementieren Suche abrechenbarer Verträge (SearchBillingContracts), Intervallfortschreibung (SetNextBillingDate, NextDate) und Rechnungszuordnung (StoreInvoiceToContract) inkl. Normalisierungskoeffizienten (MonthNormalizeCoefficient u. a.).
|
||||||
|
Aussage: Das System soll wiederkehrende Leistungen (Wartung, Miete, Kontingente, Klickzähler) aus Verträgen automatisiert und periodengerecht in Rechnungen überführen.
|
||||||
|
Ergebnis: Zum Stichtag fällige Verträge sind fakturiert; das nächste Abrechnungsdatum ist fortgeschrieben.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Methoden SearchBillingContracts / SetNextBillingDate / StoreInvoiceToContract – Begründung: durchsetzende Abrechnungslogik (Auswahl fälliger Verträge, Fortschreibung, Rechnungszuordnung).
|
||||||
|
- [SEKUNDÄR] docs/reference/receipts/contracts-backend.md (Billing Configuration: BillingIntervalKind, AutomatedBilling) – Begründung: dokumentiert die fachlichen Abrechnungsparameter am Vertrag.
|
||||||
|
Prüfidee: Vertrag mit Monatsintervall anlegen, Abrechnungslauf zum Stichtag ausführen; genau eine Rechnung entsteht, LastInvoiceDate/nächstes Datum korrekt fortgeschrieben.
|
||||||
|
Tracelinks: SyRS-020
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – zentrales Umsatzmodell (MSP/Servicevertrieb) der Zielgruppe.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-003
|
||||||
|
Titel: Forderungsmanagement mit Mahnwesen und offenen Posten
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung
|
||||||
|
Vorbedingung: Rechnungen mit Fälligkeit sind gebucht.
|
||||||
|
Fakt: DunningRunBL führt Mahnläufe mit drei Mahnstufen (DunningLevel.Level1–Level3) und fortlaufender Mahnlaufnummer aus; DunningBL kennt Mahnstopp (DunningStop, DunningStopBegin/End); OposBL/OposRunBL verwalten offene Posten.
|
||||||
|
Aussage: Das System soll überfällige Forderungen erkennen, in bis zu drei Mahnstufen anmahnen (Druck oder E-Mail) und offene Posten auswerten; einzelne Kunden/Rechnungen sollen vom Mahnlauf ausgenommen werden können (Mahnstopp).
|
||||||
|
Ergebnis: Mahnungen sind erzeugt und dokumentiert; Mahnstufen der Rechnungen sind fortgeschrieben.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methode UpdateInvoice (switch über DunningLevel None→1→2→3) – Begründung: durchgesetzte Mahnstufenlogik.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Methode SetDunningStop (setzt DunningStop/Begin/End am AccountCustomer) – Begründung: durchgesetzter Mahnstopp.
|
||||||
|
Prüfidee: Überfällige Rechnung dreimal anmahnen; vierte Mahnung wird abgelehnt (ArgumentOutOfRangeException-Pfad), Mahnstopp verhindert Aufnahme in den Lauf.
|
||||||
|
Tracelinks: SyRS-021, SyRS-022
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – gesetzlich/kaufmännisch erforderliches Forderungsmanagement.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-004
|
||||||
|
Titel: SEPA-Zahlungsverkehr für Lastschriften
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung
|
||||||
|
Vorbedingung: Rechnungen mit Lastschrift-Zahlungsart und Bankverbindung/Mandat liegen vor.
|
||||||
|
Fakt: PaymentTransactionBL exportiert Rechnungen als SEPA-Lastschriftdateien in den Formatvarianten Sepa0080101/0080302/0080102/00800102GBIC3/00800108GBIC4 (enum PaymentTransactionInterface) und markiert exportierte Rechnungen (SetInvoicesAsExported).
|
||||||
|
Aussage: Das System soll fällige Lastschriften als bankfähige SEPA-XML-Dateien exportieren und den Exportstatus je Rechnung nachhalten.
|
||||||
|
Ergebnis: Eine SEPA-Datei je Lauf; exportierte Rechnungen sind gekennzeichnet und können zurückgesetzt werden.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, Methoden ExportInvoices / SetInvoicesAsExported / ResetInvoiceExportedFlag – Begründung: durchsetzende Exportlogik inkl. Statusführung.
|
||||||
|
- [PRIMÄR] src/backend/Centron.Interfaces/DataExchange/PaymentTransactions/PaymentTransactionInterface.cs (enum mit pain.008-Varianten) – Begründung: implementierte Formatvarianten.
|
||||||
|
Prüfidee: Export mit zwei Testrechnungen ausführen; XML validiert gegen pain.008-Schema, erneuter Lauf enthält die Rechnungen nicht mehr.
|
||||||
|
Tracelinks: SyRS-023
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Zahlungsabwicklung ist Pflicht; Formatversionen im Zielsystem aktualisieren.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-005
|
||||||
|
Titel: Übergabe an die Finanzbuchhaltung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Schnittstelle
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung; externes FiBu-System (u. a. DATEV, Abacus)
|
||||||
|
Vorbedingung: Belege bzw. Stammdaten sind freigegeben/abgeschlossen.
|
||||||
|
Fakt: BookKeepingExportBL exportiert Kunden-/Lieferantenstammdaten, Kunden-/Lieferantenbelege und Kassenbuch (enum BookKeepingExportKind) mit Übergabehistorie (GetBookKeepingExport*History) und Doppel-Export-Schutz (IsReceiptExported); zahlreiche DATEV-Einstellungen existieren (ApplicationSettingID.Datev*).
|
||||||
|
Aussage: Das System soll Debitoren/Kreditoren, Buchungsdaten der Belege und Kassenbuchdaten an Finanzbuchhaltungssysteme übergeben, Übergaben protokollieren und Doppelübergaben verhindern.
|
||||||
|
Ergebnis: Exportdateien im Zielformat; Historie der Übergaben ist einsehbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs, Methoden IsReceiptExported / GetReceiptsBookingdataExportFile / GetCustomerDataExportFile – Begründung: durchsetzende Export- und Schutzlogik.
|
||||||
|
- [SEKUNDÄR] src/backend/Centron.Interfaces/Administration/Settings/ApplicationSettingID.cs (DatevOnlineSavePath, DatevFolderForInvoice u. a.) – Begründung: Konfigurationsschalter belegen DATEV-Integration.
|
||||||
|
Prüfidee: Abgeschlossene Rechnung exportieren; zweiter Exportversuch wird als bereits exportiert erkannt.
|
||||||
|
Tracelinks: SyRS-024
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Kernanforderung im deutschen Markt (DATEV-Anbindung).
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-006
|
||||||
|
Titel: Kassenführung in Filialen
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Filialmitarbeiter, Buchhaltung
|
||||||
|
Vorbedingung: Kassenbuch je Filiale eingerichtet.
|
||||||
|
Fakt: Sales/CashBooks enthält CashBookBL, CashBookBookingBL, CashBookRecordBL mit Buchungen, Löschregeln und Verknüpfung zu Belegen; Kassenbuchdaten sind Teil des FiBu-Exports (BookKeepingExportKind.Cashbook).
|
||||||
|
Aussage: Das System soll Barbewegungen je Kasse als Kassenbuch führen und in die Buchhaltung überleiten.
|
||||||
|
Ergebnis: Kassenbuchungen sind erfasst, mit Belegen verknüpft und exportierbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/CashBooks/CashBookBookingBL.cs, Methoden DeleteCashBookBooking / GetCashBookBookingsFromAsset – Begründung: implementierte Kassenbuchlogik mit Belegbezug.
|
||||||
|
Prüfidee: Kassenbuchung zu einem Beleg anlegen und im FiBu-Export „Cashbook" wiederfinden.
|
||||||
|
Tracelinks: SyRS-024
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – für Filialbetriebe mit Barverkauf erforderlich.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-007
|
||||||
|
Titel: Serviceticket-Management mit abrechenbarer Zeiterfassung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Helpdesk-Mitarbeiter, Servicetechniker, Serviceleitung
|
||||||
|
Vorbedingung: Kunde existiert; Ticketstammdaten (Typen, Status, Prioritäten, Kategorien) sind gepflegt.
|
||||||
|
Fakt: Sales/Support enthält >50 BL-Klassen für Tickets (HelpdeskBL, HelpdeskStatusBL, HelpdeskCloseBL, HelpdeskHistoryBL, Escalation, HelpdeskTimer*); Zeiten können signiert (HelpdeskTimerSignatureBL) und Artikeln/Belegen zugeordnet werden (HelpdeskTimerArticleBookingBL); Rechte-Doku CentronRights.md beschreibt Zeiten-Verschiebung nur, solange das Ticket nicht Teil eines Belegs ist.
|
||||||
|
Aussage: Das System soll Kundenanfragen als Tickets mit Status, Kategorien, Prioritäten, Historie und Eskalation verwalten; erfasste Arbeitszeiten sollen vom Kunden signierbar und in die Fakturierung überführbar sein.
|
||||||
|
Ergebnis: Tickets sind lückenlos dokumentiert; geleistete Zeiten fließen in Belege ein.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs, Methode CloseHelpdesk (setzt HelpdeskState=closed, ClosedAt, erzeugt Historie/Aktivität) – Begründung: durchgesetzter Ticket-Abschlussprozess.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs, Methoden AddSignature / SignMultipleTimers / RemoveSignatureFromTime – Begründung: implementierte Signaturfunktion auf Zeiteinträgen.
|
||||||
|
- [KONTEXT] CentronRights.md Abschnitt 8/9 („nur wenn das Ticket nicht Teil eines Belegs ist") – Begründung: bestätigt die Kopplung Zeiterfassung↔Beleg.
|
||||||
|
Prüfidee: Ticket mit Zeiteintrag anlegen, signieren, abrechnen; danach ist Verschieben/Löschen des Zeiteintrags gesperrt.
|
||||||
|
Tracelinks: SyRS-030, SyRS-031, SyRS-032
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Kern des Servicegeschäfts (Systemhaus/MSP).
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-008
|
||||||
|
Titel: Zentrale Kunden- und Kontaktverwaltung (CRM)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Vertrieb, Innendienst, Service
|
||||||
|
Vorbedingung: –
|
||||||
|
Fakt: Parallel existieren der Alt-Kundenstamm (Tabellen Kunden/Anschrif/Personen, Sales/Customers) und der neue Konten-/Adressstamm (Accounts, AccountAddress, AccountAddressContact in Centron.BL/Accounts) mit Kunden-/Lieferantenrollen (AccountCustomers/AccountSuppliers).
|
||||||
|
Aussage: Das System soll Geschäftspartner mit Adressen, Ansprechpartnern, Rollen (Kunde/Lieferant), Branchen, Interessen und Aktivitäten zentral verwalten.
|
||||||
|
Ergebnis: Ein Geschäftspartner ist einheitlich auffindbar und in allen Prozessen referenzierbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs, Methoden GetAccount / CreateNewAccountTypeForAccount – Begründung: implementierter vereinheitlichter Kontenstamm.
|
||||||
|
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Accounts / AccountCustomers / AccountSuppliers / Kunden – Begründung: beide Datenhaltungen existieren im Schema.
|
||||||
|
Prüfidee: Konto mit Kunden- und Lieferantenrolle anlegen; beide Rollen in Verkauf und Einkauf nutzbar.
|
||||||
|
Tracelinks: SyRS-040
|
||||||
|
Konsolidierung: Kandidat: Alt-Kundenstamm (Kunden/Anschrif/Personen) und Accounts-Stamm bilden denselben fachlichen Gegenstand ab und sollen im Zielsystem zu einem Partnerstamm zusammengeführt werden.
|
||||||
|
Übernahmewürdigkeit: übernehmen – Stammdatenbasis aller Prozesse; Zusammenführung der Doppelstruktur nötig.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-009
|
||||||
|
Titel: Einkauf mit elektronischer Distributorenanbindung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Einkäufer; Distributoren (ALSO, Alltron, Herweck, Komsa, ITscope, EGIS u. a.)
|
||||||
|
Vorbedingung: Lieferant mit EDI-Konfiguration vorhanden.
|
||||||
|
Fakt: EDIDispatcherBL erzeugt/überträgt Bestellungen elektronisch (CreateEDISuggestionOrderAsync, EdiEgisOrderUploadAsync, EdiItScopeOrderUploadAsync, EdiConcertoOrderUploadAsync); docs/reference/edi beschreibt Verarbeitung von Bestellantworten, Lieferavisen und Rechnungen je Lieferant.
|
||||||
|
Aussage: Das System soll Bestellungen elektronisch an Distributoren übertragen und deren Rückmeldungen (Auftragsbestätigung, Lieferavis, Rechnung) automatisiert verarbeiten.
|
||||||
|
Ergebnis: Bestellprozesse laufen ohne manuelle Doppelerfassung; EDI-Vorgänge sind protokolliert (EDILogBL).
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs, Methoden EdiEgisOrderUploadAsync / EdiItScopeOrderUploadAsync – Begründung: durchsetzende Übertragungslogik.
|
||||||
|
- [SEKUNDÄR] docs/reference/edi/edi-architecture.md (SupplierEdiBL-Partialklassen je Distributor) – Begründung: dokumentiert die unterstützten Distributoren und Belegflüsse.
|
||||||
|
Prüfidee: Testbestellung im OpenTrans-2.1-Format erzeugen und gegen Schema prüfen.
|
||||||
|
Tracelinks: SyRS-050
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – zentrale Effizienzfunktion für IT-Handel.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-010
|
||||||
|
Titel: Lager- und Bestandsführung mit Inventur
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Lagermitarbeiter
|
||||||
|
Vorbedingung: Läger und Artikel sind angelegt.
|
||||||
|
Fakt: StockBL verwaltet Läger inkl. Filialzuordnung und Umbuchungsprotokoll (WriteStockRebookLog); StorageBL/InventoryArticlePool implementieren Inventur (AddInventory, RefreshInv) mit Transaktionssteuerung.
|
||||||
|
Aussage: Das System soll Bestände je Lager führen, Umbuchungen protokollieren und Inventuren mit Bestandsabgleich unterstützen.
|
||||||
|
Ergebnis: Bestände sind je Lager korrekt; Umbuchungen und Inventuren sind nachvollziehbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs, Methode WriteStockRebookLog – Begründung: durchgesetzte Protokollierung von Lagerumbuchungen.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Storage/StorageBL.cs, Methoden AddInventory / StartTransaction / CommitTransaction – Begründung: implementierte Inventurlogik.
|
||||||
|
Prüfidee: Umbuchung zwischen zwei Lägern erzeugen; RebookLog-Eintrag vorhanden; Inventur ändert Bestand nachvollziehbar.
|
||||||
|
Tracelinks: SyRS-051, SyRS-052
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Grundfunktion Warenwirtschaft.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-011
|
||||||
|
Titel: Artikelstamm mit differenzierter Preisfindung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Produktmanagement, Vertrieb
|
||||||
|
Vorbedingung: –
|
||||||
|
Fakt: Warehousing enthält ArticleBL mit Spezialartikeln (Fracht-, Kundenrabatt-, Kontingentausgleichsartikel), ActionPriceBL (Aktionspreise), ArticleVolumePricesBL (Staffelpreise), CustomerSpecialArticleBL (kundenspezifische Sonderpreise); ReceiptPriceHelperBL berechnet Positions- und Belegpreise inkl. MwSt., Rabatt und Währungsfaktor.
|
||||||
|
Aussage: Das System soll Artikel mit Einkaufs-/Verkaufspreisen führen und bei der Belegerstellung die Preisfindung aus Listenpreis, Aktionspreis, Staffelpreis und kundenindividuellem Sonderpreis anwenden.
|
||||||
|
Ergebnis: Belegpositionen erhalten nachvollziehbar den korrekten Preis inkl. Steuer.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptPriceHelperBL.cs, Methoden CalculateReceiptItemPrices / CalculateReceiptVatPrices – Begründung: durchsetzende Preis-/Steuerberechnung.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Warehousing/ActionPriceBL.cs, ArticleVolumePricesBL.cs – Begründung: implementierte Preisarten.
|
||||||
|
Prüfidee: Artikel mit Listen-, Aktions- und Sonderpreis anlegen; Belegposition zieht die dokumentierte Priorität.
|
||||||
|
Tracelinks: SyRS-014, SyRS-053
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Kern der Warenwirtschaft.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-012
|
||||||
|
Titel: Rollen- und rechtebasierter Zugriffsschutz
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Sicherheit
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Administrator, Geschäftsführung/Compliance
|
||||||
|
Vorbedingung: Benutzer, Gruppen und Rechte sind gepflegt.
|
||||||
|
Fakt: Rechte werden über Gruppen zugewiesen (SQL-Join Sichtrus→Sichmemb in AppRightsBL.CheckRightsFromUser); es existieren einschränkende Rechte („nur eigene", „nur eigene Filiale") laut CentronRights.md und deren Durchsetzung z. B. in HelpdeskBL (ShowHelpdeskRight.OnlyOwn/OnlyOwnBranch).
|
||||||
|
Aussage: Das System soll jede fachliche Funktion über ein feingranulares Rechtesystem (Benutzer→Gruppen→Rechte) schützen, einschließlich einschränkender Rechte auf eigene Datensätze bzw. die eigene Filiale.
|
||||||
|
Ergebnis: Benutzer sehen und bearbeiten nur Daten, für die ihnen Rechte zugewiesen sind.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode CheckRightsFromUser (SQL über dbo.Sichtrus/dbo.Sichmemb) – Begründung: durchsetzende Rechteprüfung.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Zeilen 269–291 (Auswertung SHOW_HELPDESK_ONLY_OWN / _ONLY_OWN_BRANCH) – Begründung: durchgesetzte einschränkende Rechte.
|
||||||
|
- [SEKUNDÄR] CentronRights.md – Begründung: fachliche Beschreibung der Rechte inkl. Restriktionssemantik.
|
||||||
|
Prüfidee: Benutzer nur mit SHOW_HELPDESK_ONLY_OWN sieht ausschließlich Tickets, bei denen er Bearbeiter/Verantwortlicher ist.
|
||||||
|
Tracelinks: SyRS-001, SyRS-004, SyRS-005
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Compliance-Grundanforderung.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-013
|
||||||
|
Titel: Kontrollierte Benutzeranmeldung mit Mehrfaktor-Option
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Sicherheit
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Alle Benutzer; Administrator
|
||||||
|
Vorbedingung: Benutzerkonto existiert und ist aktiv.
|
||||||
|
Fakt: Authentifizierung erfolgt wahlweise per Benutzername/Passwort (BasicAuthenticator), Active Directory, OpenID Connect/Entra ID oder Web-Account (AuthenticatorFactory-Varianten); deaktivierte Konten und Austrittsdaten verhindern die Anmeldung (Authenticator.ValidateAppUser); optional wird ein zweiter Faktor per RADIUS oder E-Mail-Link verlangt (TwoFactorAuthBL).
|
||||||
|
Aussage: Das System soll Benutzer sicher authentifizieren, deaktivierte oder ausgeschiedene Mitarbeiter abweisen und optional eine Zwei-Faktor-Authentifizierung mit konfigurierbarer Gültigkeitsdauer je Gerät erzwingen.
|
||||||
|
Ergebnis: Nur berechtigte, aktive Benutzer erhalten eine Sitzung.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, Methode ValidateAppUser (Prüfung IsAccountDisabled, AccountDisabledFrom/ToDate, IsActiveEmployeeCompact) – Begründung: durchsetzende Kontoprüfung.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs, Methode HasToValidateTwoFactor – Begründung: durchgesetzte 2FA-Pflichtlogik.
|
||||||
|
Prüfidee: Anmeldeversuch mit deaktiviertem Konto → Fehlermeldung „Mitarbeiterkonto wurde deaktiviert"; 2FA-Pflicht nach Ablauf der Gültigkeitsdauer.
|
||||||
|
Tracelinks: SyRS-001, SyRS-002, SyRS-003
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Sicherheitsgrundanforderung; Passwort-Hashing im Zielsystem modernisieren (siehe SwRS-Sicherheit).
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-014
|
||||||
|
Titel: Lizenzbasierte Nutzungssteuerung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Hersteller (c-entron Software), Administrator
|
||||||
|
Vorbedingung: Lizenzdatei/Lizenzserver verfügbar.
|
||||||
|
Fakt: LicenseManager.CheckLicense prüft je Anwendung Lizenz-GUID, Versionsbeschränkung und maximale gleichzeitige Nutzung (Ticketanzahl >= Lizenzanzahl → „Die maximale Anzahl an Lizenzen wurde erreicht.").
|
||||||
|
Aussage: Das System soll den Zugang je Anwendung/Modul an Lizenzen binden und die Anzahl gleichzeitiger Anmeldungen auf die lizenzierte Menge begrenzen.
|
||||||
|
Ergebnis: Anmeldung über Lizenzgrenze hinaus wird abgewiesen.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, Methode CheckLicense (Vergleich currentlyUsedLicenses >= maxNumberOfLicenses) – Begründung: durchsetzende Lizenzprüfung.
|
||||||
|
Prüfidee: Bei Lizenzanzahl n meldet sich Benutzer n+1 an → Fehlermeldung Lizenzmaximum.
|
||||||
|
Tracelinks: SyRS-006
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: Sonderfall – herstellerseitiges Geschäftsmodell; im SaaS-Zielsystem durch Abo-/Mandantenmodell zu ersetzen.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-015
|
||||||
|
Titel: Kundenselbstbedienung über Webportal
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Endkunde (Web-Account)
|
||||||
|
Vorbedingung: Web-Account für Kundenkontakt existiert und ist aktiv.
|
||||||
|
Fakt: CentronNexus enthält WebCart (Shop auf Basis Kunden-Sonderpreisen laut README), WebOffer, SelfCare-Formulare und Ticketfunktionen; Warenkörbe durchlaufen ein Freigabewesen (ReceiptCartReleaseSystemBL, nur Web-Account-Logins: Guard „Only web-account logins ready carts for check").
|
||||||
|
Aussage: Das System soll Endkunden ein Webportal bieten, in dem sie Artikel zu vereinbarten Preisen bestellen, Angebote einsehen, Formulare ausfüllen und Tickets verfolgen können; Bestellungen sollen kundenseitig einem Prüf-/Freigabeprozess unterliegen können.
|
||||||
|
Ergebnis: Kundenbestellungen erreichen den Innendienst strukturiert und freigegeben.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs, Methode ReadyCartForCheck – Begründung: durchgesetzter Freigabeprozess für Web-Warenkörbe.
|
||||||
|
- [KONTEXT] README.md Abschnitt „WebCart" – Begründung: beschreibt Zweck (Kunden der Kunden) und Preisquelle Sonderpreise.
|
||||||
|
Prüfidee: Web-Account legt Warenkorb an, Prüfer lehnt ab → Status DeclinedByChecker; nach Freigabe entsteht Bestellung.
|
||||||
|
Tracelinks: SyRS-060, SyRS-061
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – strategisch für SaaS-Ziel (Self-Service).
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-016
|
||||||
|
Titel: Auswertungen, Statistiken und Berichte
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Geschäftsführung/Controlling, Vertrieb, Serviceleitung
|
||||||
|
Vorbedingung: Bewegungsdaten vorhanden.
|
||||||
|
Fakt: Statistics enthält Umsatz-/Auftrags-/Ticket-/Vertrags-/MSP-Statistiken; ReportEngine verwaltet FastReport-Berichte in Gruppen mit Standardberichten je Ausgabeart (ReportGroupBL, ReportDataDefault Type Mail/Print, z. B. Gruppe MAHNUNG).
|
||||||
|
Aussage: Das System soll betriebliche Kennzahlen (Umsätze, Aufträge, Tickets, Verträge) auswerten und Druck-/Mailberichte über konfigurierbare Berichtsvorlagen erzeugen.
|
||||||
|
Ergebnis: Auswertungen und Belegdrucke stehen rollengerecht zur Verfügung.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methode GenerateReport (ReportGroupConstants.MAHNUNG, Defaults je SendType) – Begründung: durchgesetzte Berichtsauswahl je Ausgabekanal.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Statistics (Ordnerstruktur mit SaleStatistics, TicketStatistics, ContractStatistics, MspStatistics) – Begründung: implementierte Statistikbereiche.
|
||||||
|
Prüfidee: Mahnlauf mit SendType Mail nutzt den Mail-Standardbericht der Gruppe „Mahnung".
|
||||||
|
Tracelinks: SyRS-070, SyRS-071
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Steuerungsrelevanz; Berichtstechnologie im Ziel neu wählbar.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-017
|
||||||
|
Titel: Interne Zusammenarbeit und Selbstorganisation
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Alle Mitarbeiter
|
||||||
|
Vorbedingung: –
|
||||||
|
Fakt: Es existieren Kalender (CalendarBL, AppointmentRequests), ToDo (ToDoBL), Chat (ChatBL mit Gruppen/Nachrichten), MyDay-Arbeitsvorrat (MyDayBL), Benachrichtigungen (UserNotificationBL, NotificationsHubHelper) und ein interner SocialMedia-Feed (SocialMediaBL mit Kommentaren/Likes/Abos).
|
||||||
|
Aussage: Das System soll Mitarbeitern Kalender, Aufgaben, Chat, persönliche Tagesübersicht und Benachrichtigungen als integrierte Werkzeuge der Zusammenarbeit bereitstellen.
|
||||||
|
Ergebnis: Termine, Aufgaben und Informationen sind ohne Systemwechsel verfügbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Chats/ChatBL.cs (CreateChat, SendChatMessage, EditChatMessage) – Begründung: implementierte Chat-Funktionen.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/MyDay/MyDayBL.cs (SaveOrUpdateWorkItem, GetEmployeeSelection) – Begründung: implementierter Arbeitsvorrat.
|
||||||
|
Prüfidee: Chatnachricht senden/ändern/löschen; MyDay-Eintrag anlegen und in der Tagesansicht sehen.
|
||||||
|
Tracelinks: SyRS-080
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Kollaborationsfunktionen; Chat ggf. durch Standardtools ersetzbar (Bewertung im Ziel).
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-018
|
||||||
|
Titel: Integrierte E-Mail-Verarbeitung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Innendienst, Helpdesk; E-Mail-Infrastruktur
|
||||||
|
Vorbedingung: Mailkonten sind konfiguriert.
|
||||||
|
Fakt: Mail-BL verwaltet Konten/Signaturen/Vorlagen; MailScannerBL verarbeitet Postfächer über Workflows/Profile mit Protokoll (MailScannerLog); Outlook-AddIn (CentronNexus.OutlookAddIn) koppelt Outlook an c-entron; Ticket-Mailversand über HelpdeskSendMailBL.
|
||||||
|
Aussage: Das System soll E-Mails senden (mit Vorlagen/Signaturen), eingehende Postfächer regelbasiert verarbeiten (u. a. automatische Ticketerzeugung) und sich in Outlook integrieren.
|
||||||
|
Ergebnis: Kundenkommunikation ist am Vorgang dokumentiert; eingehende Mails erzeugen Vorgänge.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/MailScanner/MailScannerBL.cs (GetWorkflows, SaveProfile, SaveMailScannerLog) – Begründung: implementierte regelbasierte Mailverarbeitung.
|
||||||
|
- [SEKUNDÄR] docs/features/automatic-helpdesk-creation-templates.md – Begründung: dokumentiert automatische Ticketerzeugung aus Mails.
|
||||||
|
Prüfidee: Eingehende Mail auf überwachtem Postfach erzeugt gemäß Workflow ein Ticket mit Protokolleintrag.
|
||||||
|
Tracelinks: SyRS-081, SyRS-082
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – zentraler Kommunikationskanal.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-019
|
||||||
|
Titel: Verwaltung von Kundengeräten und Managed Services
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Servicetechniker, MSP-Betrieb; RMM-Systeme, docuFORM
|
||||||
|
Vorbedingung: Kundengeräte sind erfasst oder werden automatisch erkannt.
|
||||||
|
Fakt: AccountDeviceBL verwaltet Kundengeräte mit Log; AssetManagement*-Tabellen (u. a. AssetManagementDevices, AssetManagementSnmp*) und RMM-/docuFORM-Anbindungen liefern Gerätedaten; Verträge führen Gerätelisten (MasterDataLists) mit Klickzählern (AutomaticFacturaBL.Contracts: Counter-Funktionen), MspCollectorsBL sammelt MSP-Mengen.
|
||||||
|
Aussage: Das System soll die beim Kunden betriebenen Geräte inkl. automatisch erhobener Daten (RMM, Zählerstände) verwalten und als Abrechnungsgrundlage für Serviceverträge nutzen.
|
||||||
|
Ergebnis: Gerätebestand aktuell; verbrauchsabhängige Abrechnung möglich.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Devices/AccountDeviceBL.cs (SaveAccountDevice, WriteAccountDeviceLog) – Begründung: implementierte Geräteverwaltung mit Protokoll.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs (StoreCounterState, GetCurrentCounterState, UpdClickCounterHistory) – Begründung: durchgesetzte Zähler-Abrechnungslogik.
|
||||||
|
Prüfidee: Zählerstand importieren; Vertragsabrechnung berechnet Klicks über Freimenge korrekt.
|
||||||
|
Tracelinks: SyRS-020, SyRS-090
|
||||||
|
Konsolidierung: Kandidat: Gerätedaten liegen mehrfach vor (AccountDevices, AssetManagementDevices, Vertrags-Stammdatenlisten) – im Zielsystem zu einem Gerätekonzept zusammenführen.
|
||||||
|
Übernahmewürdigkeit: übernehmen – MSP-Geschäftsmodell.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-020
|
||||||
|
Titel: Projekte und Produktionsaufträge
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Projektleiter, Fertigung/Technik
|
||||||
|
Vorbedingung: –
|
||||||
|
Fakt: ProjectBL liefert Projektlisten; TicketProjects bündelt Tickets mit Aufgaben/Abhängigkeiten; ProductionOrderBL verwaltet Fertigungsaufträge mit Positionen und Log; CrmProjects bilden Vertriebsprojekte ab; Nexus enthält ProductionOrderManagement.
|
||||||
|
Aussage: Das System soll projektbezogenes Arbeiten (Vertriebs-, Ticket- und Fertigungsprojekte) mit Aufgaben, Abhängigkeiten und Protokollen unterstützen.
|
||||||
|
Ergebnis: Projektfortschritt und Fertigungsstatus sind nachvollziehbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs (SaveProductionOrder, SaveProductionOrderLog) – Begründung: implementierte Fertigungsauftragsverwaltung.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs (SaveOrUpdateTicketProject, SaveOrUpdateTicketProjectDependency) – Begründung: implementierte Ticketprojekte mit Abhängigkeiten.
|
||||||
|
Prüfidee: Fertigungsauftrag mit zwei Positionen anlegen; Statuswechsel wird im Log protokolliert.
|
||||||
|
Tracelinks: SyRS-091, SyRS-092
|
||||||
|
Konsolidierung: Kandidat: Projektbegriffe (Project, CrmProject, TicketProject, ProjectNumber am Beleg) sind getrennt implementiert – im Zielsystem vereinheitlichen.
|
||||||
|
Übernahmewürdigkeit: übernehmen – verbreitetes Arbeitsmodell der Zielkunden.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-021
|
||||||
|
Titel: Reklamations-/RMA-Abwicklung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Service, Lager; Lieferant
|
||||||
|
Vorbedingung: Gerät/Artikel mit Kaufbezug vorhanden.
|
||||||
|
Fakt: RmaBL verwaltet RMA-Vorgänge mit Artikeln, Historie und Versandarten (RmaSendKindBL); RMA kann aus einem Ticket entstehen (GetRmaByHelpdeskI3D); UI-Modul Rma existiert.
|
||||||
|
Aussage: Das System soll Rücksendungen/Reklamationen als RMA-Vorgänge mit Artikeln, Historie und Bezug zu Tickets abwickeln.
|
||||||
|
Ergebnis: RMA-Vorgänge sind durchgängig dokumentiert.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs (SaveRma, GetRmaByHelpdeskI3D, CreateNewRmaArticle) – Begründung: implementierte RMA-Verwaltung mit Ticketbezug.
|
||||||
|
Prüfidee: RMA aus Ticket erzeugen; Artikelhistorie zeigt den Vorgang.
|
||||||
|
Tracelinks: SyRS-093
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Standardprozess im Hardwaregeschäft.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-022
|
||||||
|
Titel: Datenschutz und Datensicherheit (DSGVO)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Sicherheit
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Datenschutzbeauftragter, Administrator
|
||||||
|
Vorbedingung: –
|
||||||
|
Fakt: Es existieren DsgvoWebServiceBL (Administration/Documents/Dsgvo), der Ordner Administration/DataSecurity sowie ein Zugriffs-/Änderungsprotokoll für gespeicherte Kundenpasswörter (PasswordManagementAccessLogBL, PasswordManagementLogBL).
|
||||||
|
Aussage: Das System soll Datenschutzprozesse unterstützen (DSGVO-Dokumente) und Zugriffe auf besonders schützenswerte Daten protokollieren.
|
||||||
|
Ergebnis: Nachweisbare Datenschutz-Dokumentation und Zugriffsprotokolle.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/PasswordManagementArea/PasswordManagementAccessLogBL.cs – Begründung: implementiertes Zugriffsprotokoll auf Passwörter.
|
||||||
|
- [SEKUNDÄR] src/backend/Centron.BL/WebServices/Administration/Documents/Dsgvo/DsgvoWebServiceBL.cs (Dateiname/Klasse) – Begründung: DSGVO-Funktionsbereich existiert.
|
||||||
|
Prüfidee: Abruf eines gespeicherten Passworts erzeugt einen AccessLog-Eintrag mit Benutzer und Zeit.
|
||||||
|
Tracelinks: SyRS-100, SyRS-101
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – gesetzliche Anforderung.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-023
|
||||||
|
Titel: Revisionsfähigkeit durch Historien und Belegversionen
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: nicht-funktional
|
||||||
|
Qualitätsmerkmal: Zuverlässigkeit (Nachvollziehbarkeit/Auditierbarkeit)
|
||||||
|
Akteur: Geschäftsführung, Wirtschaftsprüfer
|
||||||
|
Vorbedingung: –
|
||||||
|
Fakt: Jede Belegänderung wird als vollständige Kopie in *KopfVersions/*PosVersions-Tabellen versioniert (docs receipts-backend-architecture, AssetHeadDAO.SaveAssetVersion); ChangeTrackingEventListener schreibt feldgenaue ChangeLog-Einträge; Belege tragen Audit-Felder (CreatedBy/ChangedBy/At); Tickets führen Historie (HelpdeskHistoryBL).
|
||||||
|
Aussage: Das System soll Änderungen an Belegen und wesentlichen Objekten versioniert bzw. feldgenau protokollieren, sodass frühere Zustände nachvollziehbar sind.
|
||||||
|
Ergebnis: Zu jedem Beleg sind alle historischen Versionen einsehbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs, Methode OnPreUpdate (erzeugt ChangeLog bei Feldänderung) – Begründung: durchgesetztes feldgenaues Änderungsprotokoll.
|
||||||
|
- [PRIMÄR] SSMS_DB_SCHEMA.sql, Tabellen RechKopfVersions/RechPosVersions u. a. – Begründung: Versionstabellen existieren im Schema.
|
||||||
|
- [SEKUNDÄR] docs/reference/receipts/receipts-backend-architecture.md (Version Tables 1:1) – Begründung: dokumentierter Versionierungsmechanismus.
|
||||||
|
Prüfidee: Rechnung zweimal ändern; zwei Versionssätze in RechKopfVersions, ChangeLog enthält Feldänderungen.
|
||||||
|
Tracelinks: SyRS-015, SyRS-102
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – GoBD-/Audit-Anforderung.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-024
|
||||||
|
Titel: Mandanten- und Filialfähigkeit
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Geschäftsführung, Administrator
|
||||||
|
Vorbedingung: –
|
||||||
|
Fakt: MandatorBL und BranchBL existieren; Belege tragen BranchI3D mit Herkunftslogik (ReceiptBL.GetBranchForNewReceipt nach BranchOrigin Creator/Adviser2); Nummernkreise, Läger, Rechte („nur eigene Filiale") und Erlöskonten (BranchRevenueAndExpenseAccountBL) sind filialbezogen.
|
||||||
|
Aussage: Das System soll mehrere Mandanten und Filialen abbilden; Belege, Nummernkreise, Läger und Berechtigungen sollen filialbezogen steuerbar sein.
|
||||||
|
Ergebnis: Filialen arbeiten getrennt mit eigenen Nummern/Lägern; übergreifende Auswertung bleibt möglich.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methoden GetBranchForNewReceipt / UpdateReceiptNumber (Nummernkreis je Branch) – Begründung: durchgesetzte Filialzuordnung.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/Company/BranchBL.cs, MandatorBL.cs – Begründung: implementierte Organisationsstämme.
|
||||||
|
Prüfidee: Zwei Filialen mit eigenen Nummernkreisen; Belege erhalten filialspezifische Nummern.
|
||||||
|
Tracelinks: SyRS-013, SyRS-110
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – im SaaS-Ziel als Mandanten-/Standortmodell.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-025
|
||||||
|
Titel: Sichere Verwaltung von Kundenzugangsdaten
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Sicherheit
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Servicetechniker, Administrator
|
||||||
|
Vorbedingung: Berechtigung auf den Passwortbereich.
|
||||||
|
Fakt: PasswordManagementBL speichert Zugangsdaten mit Entschlüsselungsfunktion (GetDecryptedPassword) und getrennten Protokollen für Zugriffe (AccessLog) und Änderungen (Log); Typen/Schlagworte strukturieren die Einträge.
|
||||||
|
Aussage: Das System soll Zugangsdaten zu Kundensystemen verschlüsselt speichern, den Zugriff berechtigungsabhängig gewähren und jeden Abruf protokollieren.
|
||||||
|
Ergebnis: Zugangsdaten sind zentral, geschützt und auditierbar verfügbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/PasswordManagementArea/PasswordManagementBL.cs, Methode GetDecryptedPassword – Begründung: implementierte ver-/entschlüsselte Ablage.
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/PasswordManagementArea/PasswordManagementAccessLogBL.cs – Begründung: durchgesetztes Zugriffsprotokoll.
|
||||||
|
Prüfidee: Passwortabruf erzeugt AccessLog; Datenbankfeld enthält keinen Klartext.
|
||||||
|
Tracelinks: SyRS-101
|
||||||
|
Konsolidierung: Kandidat: PasswordManager (BL/PasswordManager) und PasswordManagementArea adressieren denselben Gegenstand – im Ziel ein Konzept.
|
||||||
|
Übernahmewürdigkeit: übernehmen – sicherheitskritische Kernfunktion für Systemhäuser.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-026
|
||||||
|
Titel: Telefonie-Integration am Arbeitsplatz
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Innendienst, Helpdesk; TK-Anlage (TAPI)
|
||||||
|
Vorbedingung: TAPI-Treiber verfügbar und konfiguriert.
|
||||||
|
Fakt: PhoneCallBL erzeugt/synchronisiert Anrufdatensätze und sucht Kontakte per Rufnummer (SearchContactPersonByPhoneNumberV2); assemblies/tapi und docs/reference/architecture/tapi.md existieren.
|
||||||
|
Aussage: Das System soll ein- und ausgehende Telefonate erkennen, dem Anrufer Kunden/Kontakte zuordnen und Anrufe protokollieren.
|
||||||
|
Ergebnis: Anrufbezogene Vorgangsbearbeitung ohne manuelle Suche.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Tapi/PhoneCallBL.cs (CreatePhoneCall, SearchContactPersonByPhoneNumberV2, SyncPhoneCalls) – Begründung: implementierte Telefonie-Logik.
|
||||||
|
- [KONTEXT] docs/reference/architecture/tapi.md – Begründung: Architekturdokumentation der TAPI-Anbindung.
|
||||||
|
Prüfidee: Simulierter Anruf mit bekannter Nummer öffnet den passenden Kontakt.
|
||||||
|
Tracelinks: SyRS-083
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: Workaround – TAPI ist Windows-/Desktop-gebunden; im Web-Ziel durch CTI-/WebRTC-Ansatz zu ersetzen, fachliche Funktion bleibt.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-027
|
||||||
|
Titel: Elektronische Rechnungsstellung (XRechnung/ZUGFeRD)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Schnittstelle
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung; öffentliche/gewerbliche Rechnungsempfänger
|
||||||
|
Vorbedingung: Rechnung ist fakturiert; Empfänger verlangt E-Rechnung.
|
||||||
|
Fakt: Es existieren eine eigene ZUGFeRD-Implementierung (docs/guides/development/xrechnung.md: „instead of creating our own implementation"), Feldzuordnungsdokumente (docs/reference/zugferd-field-mapping.md, zugferd-feldzuordnung-anwender.md) und die österreichische ebInterface-API (src/apis/Centron.Api.EbInterface).
|
||||||
|
Aussage: Das System soll Ausgangsrechnungen als strukturierte E-Rechnungen (ZUGFeRD/XRechnung, ebInterface für AT) erzeugen können.
|
||||||
|
Ergebnis: Normkonforme E-Rechnungsdatei zur Rechnung.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/apis/Centron.Api.EbInterface (Projekt) – Begründung: implementierte E-Rechnungs-Schnittstelle ebInterface.
|
||||||
|
- [SEKUNDÄR] docs/reference/zugferd-field-mapping.md – Begründung: dokumentierte Feldzuordnung der eigenen ZUGFeRD-Erzeugung.
|
||||||
|
- [KONTEXT] docs/guides/development/xrechnung.md – Begründung: bestätigt eigene ZUGFeRD/XRechnung-Implementierung.
|
||||||
|
Prüfidee: Erzeugte XRechnung mit KOSIT-Validator prüfen.
|
||||||
|
Tracelinks: SyRS-025
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – gesetzliche Pflicht (B2G, ab 2025ff B2B-Empfangspflicht in DE).
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-028
|
||||||
|
Titel: KI-gestützte Assistenzfunktionen
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Helpdesk-Mitarbeiter; KI-Dienste (OpenAI-kompatibel)
|
||||||
|
Vorbedingung: KI-Anbindung konfiguriert und lizenziert.
|
||||||
|
Fakt: ArtificialIntelligence enthält OpenAiApiClient, TicketCategoryApiClient, TextRatingApiClient, ChatModelApiClient; Nexus-ServiceBoard enthält TicketAiSummary; TelemetryBL erfasst KI-Toolnutzung.
|
||||||
|
Aussage: Das System soll KI-Dienste für Ticket-Kategorisierung, Textbewertung und Ticket-Zusammenfassungen anbinden und deren Nutzung erfassen.
|
||||||
|
Ergebnis: KI-Vorschläge in der Ticketbearbeitung; Nutzung ist ausgewertet.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/ArtificialIntelligence/TicketCategoryApiClient.cs, OpenAiApiClient.cs – Begründung: implementierte KI-Clients.
|
||||||
|
- [PRIMÄR] src/nexus/CentronNexus/ServiceBoard/TicketAiSummary (Ordner) – Begründung: KI-Zusammenfassung im Webclient.
|
||||||
|
Prüfidee: Ticket-Zusammenfassung im ServiceBoard abrufen; Telemetrie-Eintrag entsteht.
|
||||||
|
Tracelinks: SyRS-120
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen – Differenzierungsmerkmal; Anbieterwahl im Ziel offen.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
+1691
File diff suppressed because it is too large
Load Diff
+80
@@ -0,0 +1,80 @@
|
|||||||
|
# Messprotokoll – Versuch 01 (V1 Baseline) – Prompt-Version 02
|
||||||
|
|
||||||
|
> ## ⚠ FEHLMESSUNG – nicht für Auswertungen verwenden
|
||||||
|
>
|
||||||
|
> Der Lauf brach mit `is_error: true` und HTTP 429 ab: „You've hit your session limit ·
|
||||||
|
> resets 10:50pm (Europe/Berlin)". Erzeugt wurden **3 von sieben** geforderten Ergebnisdateien; der Lauf brach mitten in der Bearbeitung ab. Verbraucht wurden
|
||||||
|
> bis zum Abbruch **7.997.215 Tokens**.
|
||||||
|
|
||||||
|
## Lauf
|
||||||
|
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
|
||||||
|
- **Prompt-Version:** 02
|
||||||
|
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
|
||||||
|
- **Startzeit:** 2026-08-26T20:00:08.8552900+02:00
|
||||||
|
- **Endzeit:** 2026-08-26T20:28:31.6394457+02:00
|
||||||
|
- **Dauer gesamt:** 00:07:4x — bis zum Kontingentabbruch
|
||||||
|
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||||
|
- **Codebasis-Commit:** `f349d189c735a87f5829bc93f67991320061a2c0` (dirty: nein)
|
||||||
|
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; enthält `SSMS_DB_SCHEMA.sql`
|
||||||
|
|
||||||
|
## Werkzeugkonfiguration
|
||||||
|
- **Skill-Version:** 7.0.0
|
||||||
|
- **Claude-Code-Version:** 2.1.246
|
||||||
|
- **Modell (angefordert):** `claude-fable-5`
|
||||||
|
- **Modelle (tatsächlich eingesetzt):** `claude-fable-5` 7.990.250 (99.91 %), `claude-haiku-4-5-20251001` 6.965 (0.09 %)
|
||||||
|
- **Kontrolle Modell:** bestanden
|
||||||
|
- **Effort:** `high`
|
||||||
|
- **Agentenmodus:** `solo` (V1)
|
||||||
|
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
|
||||||
|
- **Hintergrund-Wartezeit:** `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`
|
||||||
|
- **Parallele Läufe:** **ja** – alle vier Läufe der Welle liefen gleichzeitig
|
||||||
|
- **Subagenten:** keine (`spawned` = 0)
|
||||||
|
|
||||||
|
## Verbrauch
|
||||||
|
|
||||||
|
| Messgröße | `claude-fable-5` | `claude-haiku-4-5-20251001` | Summe |
|
||||||
|
|---|---:|---:|---:|
|
||||||
|
| Input-Tokens | 128 | 6.945 | 7.073 |
|
||||||
|
| Output-Tokens | 127.802 | 20 | 127.822 |
|
||||||
|
| Cache-Write-Tokens | 279.983 | 0 | 279.983 |
|
||||||
|
| Cache-Read-Tokens | 7.582.337 | 0 | 7.582.337 |
|
||||||
|
| **Tokens gesamt** | **7.990.250** | **6.965** | **7.997.215** |
|
||||||
|
|
||||||
|
|
||||||
|
**Tokens gesamt: 7.997.215** — real angefallen und deshalb ausgewiesen, obwohl der Lauf ungültig ist.
|
||||||
|
|
||||||
|
## Gefundene Anforderungen
|
||||||
|
|
||||||
|
Der Lauf brach vor Abschluss ab. Im vorhandenen **Teilbestand** stehen **109 Anforderungen**. Die Zahl ist **nicht** mit vollständigen Läufen vergleichbar – es fehlen `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`. Die maschinelle Auswertung liegt zur Vollständigkeit unter `_meta/anforderungen.md`, geht aber nicht in Vergleiche ein.
|
||||||
|
|
||||||
|
## Ergebnis
|
||||||
|
- **Gültigkeit:** **Fehlmessung** – API-Abbruch (HTTP 429, Session-Kontingent); nur 3 von sieben Artefakten erzeugt
|
||||||
|
- **Status:** `is_error` = true, `terminal_reason` = `api_error`, `api_error_status` = 429
|
||||||
|
- **Session-ID:** `1d368e93-cb25-434c-9365-b76eace2ee17`
|
||||||
|
- **Turns:** 94
|
||||||
|
- **Permission-Denials:** 0
|
||||||
|
- **Erzeugte Dateien:** 3 von sieben geforderten Artefakten:
|
||||||
|
|
||||||
|
| Datei | Größe |
|
||||||
|
|---|---:|
|
||||||
|
| `Analysebericht.md` | 24.343 B |
|
||||||
|
| `StRS.md` | 42.134 B |
|
||||||
|
| `SyRS.md` | 105.262 B |
|
||||||
|
|
||||||
|
Es fehlen: `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`
|
||||||
|
- **Root unverändert:** ja
|
||||||
|
- **Abschlusstext des Agenten:** „You've hit your session limit · resets 10:50pm (Europe/Berlin)"
|
||||||
|
|
||||||
|
## Anmerkungen/Auffälligkeiten
|
||||||
|
|
||||||
|
**1. Kontingentabbruch, nicht Laufversagen.** Vier Läufe wurden am 26.08. um 19:59 gleichzeitig
|
||||||
|
gestartet; alle vier liefen in dieselbe Grenze. Zusammen hatten sie zu diesem Zeitpunkt
|
||||||
|
297,4 Mio. Tokens verbraucht, davon allein 204,4 Mio. im Lauf `45dd`. Die Parallelität von vier
|
||||||
|
Läufen – darunter einer mit extremer Delegation – hat das Kontingent gerissen.
|
||||||
|
|
||||||
|
**2. Konsequenz für den Versuchsaufbau:** Die verbleibenden Zellen werden **seriell** gefahren.
|
||||||
|
Der erste serielle Lauf danach (`opus-5/solo/high`, `2269`) lief mit 38,1 Mio. Tokens sauber durch.
|
||||||
|
|
||||||
|
**3. Zelle inzwischen gültig belegt.** Der Wiederholungslauf `02_Lauf_2026-08-27_002430_v7.0.0-35a4`
|
||||||
|
war erfolgreich: 241 Anforderungen, 98,3 % mit Primärbeleg, 30,6 Mio. Tokens – allerdings mit
|
||||||
|
7:03 h Wanduhrzeit, weil er mehrfach stundenweise auf Kontingent-Reset-Fenster wartete.
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
{"is_error":true,"duration_api_ms":1549743,"num_turns":94,"stop_reason":"stop_sequence","session_id":"1d368e93-cb25-434c-9365-b76eace2ee17","total_cost_usd":19.580422,"usage":{"input_tokens":128,"cache_creation_input_tokens":279983,"cache_read_input_tokens":7582337,"output_tokens":127802,"output_tokens_details":{"thinking_tokens":21913},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":279983,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":374,"cache_read_input_tokens":247654,"cache_creation_input_tokens":32329,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":32329},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6945,"outputTokens":20,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007045,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-fable-5":{"inputTokens":128,"outputTokens":127802,"cacheReadInputTokens":7582337,"cacheCreationInputTokens":279983,"webSearchRequests":0,"costUSD":19.573377,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"api_error","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":429,"result":"You've hit your session limit · resets 10:50pm (Europe/Berlin)","type":"result","duration_ms":1701146,"uuid":"910fddce-feda-4375-862c-350dbb92f47b","queued_turn_count":0}
|
||||||
+2144
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 | 25,7 % |
|
||||||
|
| SyRS | 81 | 74,3 % |
|
||||||
|
| SwRS | 0 | 0,0 % |
|
||||||
|
| **Gesamt** | **109** | 100 % |
|
||||||
|
|
||||||
|
### Anforderungstypen
|
||||||
|
|
||||||
|
| Typ | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| funktional | 60 | 55,0 % |
|
||||||
|
| Schnittstelle | 15 | 13,8 % |
|
||||||
|
| Sicherheit | 15 | 13,8 % |
|
||||||
|
| nicht-funktional | 10 | 9,2 % |
|
||||||
|
| Daten | 9 | 8,3 % |
|
||||||
|
|
||||||
|
### Belegqualität
|
||||||
|
|
||||||
|
| Messgröße | Wert |
|
||||||
|
|---|---:|
|
||||||
|
| Belege gesamt | 180 |
|
||||||
|
| davon `PRIMÄR` | 145 (80,6 %) |
|
||||||
|
| davon `SEKUNDÄR` | 28 (15,6 %) |
|
||||||
|
| davon `KONTEXT` | 7 (3,9 %) |
|
||||||
|
| Belege je Anforderung (Median) | 2 |
|
||||||
|
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 108 (99,1 %) |
|
||||||
|
|
||||||
|
### Übernahmewürdigkeit
|
||||||
|
|
||||||
|
| Einstufung | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| übernehmen | 102 | 93,6 % |
|
||||||
|
| workaround | 4 | 3,7 % |
|
||||||
|
| sonderfall | 1 | 0,9 % |
|
||||||
|
| veraltet | 2 | 1,8 % |
|
||||||
|
|
||||||
|
### Status
|
||||||
|
|
||||||
|
| Kategorie | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| belegt | 101 | 92,7 % |
|
||||||
|
| als `HYPOTHESE` gekennzeichnet | 8 | 7,3 % |
|
||||||
|
| als Workaround vermerkt | 0 | 0,0 % |
|
||||||
|
| Konsolidierungskandidaten | 11 | 10,1 % |
|
||||||
|
| mit ISO-25010-Qualitätsmerkmal | 10 | 9,2 % |
|
||||||
|
|
||||||
|
### 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]` | **verletzt** – 1 von 28 ungedeckt: SyRS-008 |
|
||||||
|
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||||
|
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 109 Anforderungen eingestuft) |
|
||||||
|
| **Traceability** – Verknüpfung zwischen den Ebenen | 109 von 109 mit Tracelinks (100,0 %) |
|
||||||
|
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
|
||||||
+177
@@ -0,0 +1,177 @@
|
|||||||
|
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
|
||||||
|
|
||||||
|
## Metadaten
|
||||||
|
- **Versuch:** V1 Baseline (Prompt-only)
|
||||||
|
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
|
||||||
|
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||||
|
- **Zeitstempel:** 2026-08-26
|
||||||
|
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
|
||||||
|
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||||
|
|
||||||
|
| Änderung | Auslösender Befund |
|
||||||
|
|---|---|
|
||||||
|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
|
||||||
|
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
|
||||||
|
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
|
||||||
|
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
|
||||||
|
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
|
||||||
|
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
|
||||||
|
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
|
||||||
|
|
||||||
|
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
|
||||||
|
|
||||||
|
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||||
|
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||||
|
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Prompt
|
||||||
|
|
||||||
|
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||||
|
|
||||||
|
### Auftrag
|
||||||
|
|
||||||
|
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||||
|
|
||||||
|
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||||
|
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||||
|
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||||
|
|
||||||
|
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||||
|
|
||||||
|
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||||
|
|
||||||
|
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
**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. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
|
||||||
|
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||||
|
|
||||||
|
### Formatvorgabe pro Anforderung
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||||
|
Titel: <kurzer Titel>
|
||||||
|
Ebene: <StRS | SyRS | SwRS>
|
||||||
|
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||||
|
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)
|
||||||
|
|
||||||
|
```
|
||||||
|
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)
|
||||||
|
```
|
||||||
|
|
||||||
|
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?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||||
|
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
|
||||||
|
Kommandozeilenbefehlen im Arbeitsverzeichnis.
|
||||||
|
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
|
||||||
|
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||||
|
Werkzeuge zu ersetzen.
|
||||||
|
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||||
|
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||||
|
`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-fable-5\solo\high\02_Lauf_2026-08-26_195958_v7.0.0-77a1\Ergebnisse\`.
|
||||||
|
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-26T20:28:31.6394457+02:00
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-26T20:00:08.8552900+02:00
|
||||||
+492
@@ -0,0 +1,492 @@
|
|||||||
|
# Analysebericht – Reverse Requirements Engineering c-entron ERP-Suite
|
||||||
|
|
||||||
|
**Lauf:** V1 Baseline (Prompt-only), Iteration 02, 2026-08-27
|
||||||
|
**Untersuchungsgegenstand:** Gesamte Codebasis unter `C:\DEV\MasterArbeit\QuellCode\CentronERP` (statische Analyse, keine Ausführung)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Schritt 0 – Modulinventar
|
||||||
|
|
||||||
|
Das Inventar wurde vor der ersten Anforderung erstellt. Es basiert auf der Verzeichnisstruktur der
|
||||||
|
Solution (`Centron.sln`), insbesondere der fachlichen Modulordner in `src/backend/Centron.BL`
|
||||||
|
(Geschäftslogikschicht), sowie den weiteren Schichten (DAO, Entities, Gateway, WPF-Client,
|
||||||
|
Blazor-Web „Nexus", Webservice, API-Integrationsprojekte) und Begleitartefakten (DB-Schema,
|
||||||
|
Deployment, Doku). Pfade sind relativ zum Arbeitsverzeichnis.
|
||||||
|
|
||||||
|
Legende Spalte „Modul": M-Nummer = Bezugsgröße für Abdeckungstabelle und Mindestabdeckung.
|
||||||
|
|
||||||
|
### A. Geschäftslogik (src/backend/Centron.BL)
|
||||||
|
|
||||||
|
| Nr. | Modul / Komponente | Pfad | Fachliche Aufgabe (1 Satz) |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-001 | Accounting (Bankkonten) | src/backend/Centron.BL/Accounting | Verwaltung der Bankkonten des Unternehmens (BankAccountBL). |
|
||||||
|
| M-002 | Accounts (Konten-/Adressstamm) | src/backend/Centron.BL/Accounts | Verwaltung von Konten (Kunden/Adressen), Kontakten, Kontenverträgen, Kampagnen, Kontenmigration und Aktivitäten. |
|
||||||
|
| M-003 | Administration: AccessTokens | src/backend/Centron.BL/Administration/AccessTokens | Verwaltung von API-/Zugriffstokens für externe Zugriffe. |
|
||||||
|
| M-004 | Administration: Applications | src/backend/Centron.BL/Administration/Applications | Verwaltung registrierter (Client-)Anwendungen. |
|
||||||
|
| M-005 | Administration: ArtificialIntelligence | src/backend/Centron.BL/Administration/ArtificialIntelligence | Administrative Konfiguration der KI-Funktionen (Modelle, API-Anbindung). |
|
||||||
|
| M-006 | Administration: BackgroundServices | src/backend/Centron.BL/Administration/BackgroundServices | Konfiguration und Überwachung von Hintergrunddiensten (Jobs). |
|
||||||
|
| M-007 | Administration: BookKeepingAccountSystems | src/backend/Centron.BL/Administration/BookKeepingAccountSystems | Verwaltung der Buchhaltungs-Kontenrahmen (z. B. SKR) für die FiBu-Übergabe. |
|
||||||
|
| M-008 | Administration: CentronConfigDb | src/backend/Centron.BL/Administration/CentronConfigDb | Zugriff auf die zentrale Konfigurationsdatenbank (mandantenübergreifende Konfiguration). |
|
||||||
|
| M-009 | Administration: Company/CompanyInformations | src/backend/Centron.BL/Administration/Company, .../CompanyInformations | Verwaltung der eigenen Firmenstammdaten (Firmen, Filialen, Firmeninformationen). |
|
||||||
|
| M-010 | Administration: Connections | src/backend/Centron.BL/Administration/Connections | Verwaltung technischer Verbindungen (DB-/Dienstverbindungen). |
|
||||||
|
| M-011 | Administration: Customization | src/backend/Centron.BL/Administration/Customization | Kundenspezifische Anpassungen der Anwendung (Custom-Verhalten). |
|
||||||
|
| M-012 | Administration: DataSecurity | src/backend/Centron.BL/Administration/DataSecurity | Datensicherheits-/Datenschutzfunktionen (DataSecurityBL). |
|
||||||
|
| M-013 | Administration: Documents/FileManagement | src/backend/Centron.BL/Administration/Documents, .../FileManagement | Dokumentenablage und Dateiverwaltung (Speicherorte, Dateioperationen). |
|
||||||
|
| M-014 | Administration: Employees | src/backend/Centron.BL/Administration/Employees | Administrative Mitarbeiterverwaltung (Anlage, Einstellungen). |
|
||||||
|
| M-015 | Administration: Environments | src/backend/Centron.BL/Administration/Environments | Verwaltung von Umgebungen (z. B. Test-/Produktivumgebung). |
|
||||||
|
| M-016 | Administration: Licensing | src/backend/Centron.BL/Administration/Licensing | Lizenzverwaltung und Lizenzprüfung der ERP-Installation (LicenseManager). |
|
||||||
|
| M-017 | Administration: Logins/Auth | src/backend/Centron.BL/Administration/Logins | Benutzer-Authentifizierung: Logins, Auth-Tickets, Zwei-Faktor, Web-Accounts, EntraID-Anbindung. |
|
||||||
|
| M-018 | Administration: Mandatory | src/backend/Centron.BL/Administration/Mandatory | Verwaltung der Mandanten (Mandatoren) der Installation. |
|
||||||
|
| M-019 | Administration: Masterdata | src/backend/Centron.BL/Administration/Masterdata | Zentrale Stammdaten der Administration (Basistabellen). |
|
||||||
|
| M-020 | Administration: NetworkDiagnostics | src/backend/Centron.BL/Administration/NetworkDiagnostics | Netzwerk-Diagnosefunktionen für den Support. |
|
||||||
|
| M-021 | Administration: PerformanceTests/Profiling | src/backend/Centron.BL/Administration/PerformanceTests, .../Profiling | Performancemessung und Profiling der Anwendung. |
|
||||||
|
| M-022 | Administration: PhoneSettings | src/backend/Centron.BL/Administration/PhoneSettings | Telefonie-Einstellungen (TAPI-Konfiguration). |
|
||||||
|
| M-023 | Administration: Portal | src/backend/Centron.BL/Administration/Portal | Anbindung/Verwaltung eines (Kunden-)Portals. |
|
||||||
|
| M-024 | Administration: Rights | src/backend/Centron.BL/Administration/Rights | Benutzerrechte- und Benutzergruppenverwaltung (AppRights, Rechtebaum). |
|
||||||
|
| M-025 | Administration: Scripts/SQLManagement | src/backend/Centron.BL/Administration/Scripts, .../SQLManagement | Verwaltung und Ausführung administrativer SQL-Skripte. |
|
||||||
|
| M-026 | Administration: Settings | src/backend/Centron.BL/Administration/Settings | Systemweite und benutzerbezogene Einstellungen. |
|
||||||
|
| M-027 | Administration: Themes | src/backend/Centron.BL/Administration/Themes | Verwaltung der UI-Themes. |
|
||||||
|
| M-028 | Administration: WebServiceConfiguration | src/backend/Centron.BL/Administration/WebServiceConfiguration | Konfiguration des c-entron Webservice. |
|
||||||
|
| M-029 | AppointmentRequests | src/backend/Centron.BL/AppointmentRequests | Terminanfragen (Vereinbarung von Terminen mit Externen). |
|
||||||
|
| M-030 | ArtificialIntelligence | src/backend/Centron.BL/ArtificialIntelligence | KI-Funktionen: Chat-Anbindung an LLM-Anbieter, Modellkatalog, Tool-Aufrufe. |
|
||||||
|
| M-031 | BusinessPartner | src/backend/Centron.BL/BusinessPartner | Lieferanten-Suche und Lieferanten-Assets (Geschäftspartnersicht). |
|
||||||
|
| M-032 | Buying | src/backend/Centron.BL/Buying | Einkaufssicht auf Distributoren (externe Bezugsquellen). |
|
||||||
|
| M-033 | Calendar | src/backend/Centron.BL/Calendar | Kalenderfunktionen (Termine der Mitarbeiter). |
|
||||||
|
| M-034 | CentronIcons | src/backend/Centron.BL/CentronIcons | Verwaltung der in der Anwendung verwendeten Icons. |
|
||||||
|
| M-035 | CentronNexus (BL) | src/backend/Centron.BL/CentronNexus | Geschäftslogik-Anteil für den Webclient „c-entron Nexus". |
|
||||||
|
| M-036 | ChangeTracking | src/backend/Centron.BL/ChangeTracking | Import-Historie und Änderungsverfolgung. |
|
||||||
|
| M-037 | Chats | src/backend/Centron.BL/Chats | Interne Chat-Funktion. |
|
||||||
|
| M-038 | CheckListArea | src/backend/Centron.BL/CheckListArea | Checklisten inkl. Änderungsprotokoll. |
|
||||||
|
| M-039 | Core (BL-Kern) | src/backend/Centron.BL/Core | Kernfunktionen der BL: Kryptographie-Hilfsfunktionen, Platzhalter-Ersetzung. |
|
||||||
|
| M-040 | CountryArea | src/backend/Centron.BL/CountryArea | Länder- und Bundesland-Stammdaten. |
|
||||||
|
| M-041 | CPra | src/backend/Centron.BL/CPra | Konnektor „CPra" (Konfiguration und Anbindung eines Externsystems). |
|
||||||
|
| M-042 | CustomerArea | src/backend/Centron.BL/CustomerArea | Kundenbezogene Nebenstammdaten: Branchen, Interessen, Produkte, RMA-Abwicklung. |
|
||||||
|
| M-043 | Customizations (CustomTables) | src/backend/Centron.BL/Customizations | Kundenindividuelle Zusatztabellen (Custom Tables). |
|
||||||
|
| M-044 | DataExchange | src/backend/Centron.BL/DataExchange | Datenaustausch: FiBu-Export/-Import, DocBee-/DocuForm-Konnektoren, E-Rechnungs-Upload, WebHooks. |
|
||||||
|
| M-045 | Devices | src/backend/Centron.BL/Devices | Geräteverwaltung je Konto (AccountDevice). |
|
||||||
|
| M-046 | DocuBoard | src/backend/Centron.BL/DocuBoard | Asset-Management-Anbindung (AD-Systembenutzer, Artikelzuordnung, Partner). |
|
||||||
|
| M-047 | DocumentationArea | src/backend/Centron.BL/DocumentationArea | Dokumentationen zu Objekten (Systemdokumentation). |
|
||||||
|
| M-048 | EDI | src/backend/Centron.BL/EDI | Elektronischer Datenaustausch mit Distributoren (Alltron, ALSO, Concerto, EGIS, Komsa u. a.): Bestellungen, Auftragsbestätigungen. |
|
||||||
|
| M-049 | EmployeeArea | src/backend/Centron.BL/EmployeeArea | Mitarbeiterstamm: App-Benutzer, Abteilungen, Urlaub, RFID-Token, Team-Management. |
|
||||||
|
| M-050 | ExpectedEvents | src/backend/Centron.BL/ExpectedEvents | Erwartete Ereignisse (Überwachung ausbleibender Ereignisse). |
|
||||||
|
| M-051 | ExternalHelpdesk | src/backend/Centron.BL/ExternalHelpdesk | Konfiguration externer Helpdesk-Anbindungen. |
|
||||||
|
| M-052 | ExternalToolsBL | src/backend/Centron.BL/ExternalToolsBL | Einbindung externer Tools in die Anwendung. |
|
||||||
|
| M-053 | Finances | src/backend/Centron.BL/Finances | Finanzen: Zahlungseingänge, Onlinebanking (FinAPI), Zahlungen, Produkt-Lebenszyklus. |
|
||||||
|
| M-054 | Gateway (BL) | src/backend/Centron.BL/Gateway | Kundenspezifische Gateway-Logik (CustomGateway). |
|
||||||
|
| M-055 | GUI (BL-Anteil) | src/backend/Centron.BL/GUI | UI-nahe BL: Bestellimport (EDI), UI-Profile, Benutzer-Grid-Layouts. |
|
||||||
|
| M-056 | IndexSearch | src/backend/Centron.BL/IndexSearch | Volltextsuche über Konten und Tickets (Lucene-Index, GermanAnalyzer). |
|
||||||
|
| M-057 | Integrations | src/backend/Centron.BL/Integrations | Integrationen (EsCustomerGroup, EsRole – externes Shopsystem). |
|
||||||
|
| M-058 | ItPlanner | src/backend/Centron.BL/ItPlanner | IT-Planner (Checklisten-basierte Planung virtueller Objekte). |
|
||||||
|
| M-059 | Logistics | src/backend/Centron.BL/Logistics | Logistikeinstellungen und Bestandsführung (StockBL). |
|
||||||
|
| M-060 | Mail | src/backend/Centron.BL/Mail | E-Mail-Verarbeitung: Exchange/EWS-Anbindung, Mail-Erzeugung, Signaturen, Domain-Blacklist. |
|
||||||
|
| M-061 | MailScanner | src/backend/Centron.BL/MailScanner | Automatisches Scannen von Mailpostfächern (z. B. zur Ticketerzeugung). |
|
||||||
|
| M-062 | Mailings | src/backend/Centron.BL/Mailings | Serien-Mailings auf Basis von Vorlagen. |
|
||||||
|
| M-063 | MassUpdate | src/backend/Centron.BL/MassUpdate | Massenänderungen an Datenobjekten. |
|
||||||
|
| M-064 | Mobile | src/backend/Centron.BL/Mobile | Unterstützung mobiler Clients. |
|
||||||
|
| M-065 | Modules | src/backend/Centron.BL/Modules | Verwaltung der freigeschalteten Programm-Module (Modul-/Kategorieverwaltung). |
|
||||||
|
| M-066 | MyCentron | src/backend/Centron.BL/MyCentron | Persönlicher Bereich: Dashboards, Quick Notes, zuletzt verwendete Objekte, Schedulings. |
|
||||||
|
| M-067 | MyDay | src/backend/Centron.BL/MyDay | „Mein Tag"-Übersicht (Tagesnotifications, Reports, Supremo-Fernwartung). |
|
||||||
|
| M-068 | NexusNotifications | src/backend/Centron.BL/NexusNotifications | Benachrichtigungen im Webclient (SignalR-Hub). |
|
||||||
|
| M-069 | NexusTicketViews | src/backend/Centron.BL/NexusTicketViews | Konfigurierbare Ticket-Ansichten im Webclient. |
|
||||||
|
| M-070 | Notifications | src/backend/Centron.BL/Notifications | Benutzerbenachrichtigungen im Client. |
|
||||||
|
| M-071 | ObjectExternalReferences | src/backend/Centron.BL/ObjectExternalReferences | Externe Referenzen auf c-entron-Objekte (Fremdschlüssel zu Drittsystemen). |
|
||||||
|
| M-072 | Outlook | src/backend/Centron.BL/Outlook | Outlook-Integration (Asset-Suche aus Outlook). |
|
||||||
|
| M-073 | PasswordManagementArea | src/backend/Centron.BL/PasswordManagementArea | Passwortverwaltung für Kunden-Zugangsdaten inkl. Zugriffs- und Änderungsprotokoll. |
|
||||||
|
| M-074 | PasswordManager | src/backend/Centron.BL/PasswordManager | Anbindung externer Passwortmanager. |
|
||||||
|
| M-075 | Processes | src/backend/Centron.BL/Processes | Prozessverwaltung (Geschäftsprozess-Objekte). |
|
||||||
|
| M-076 | ProductMatrix | src/backend/Centron.BL/ProductMatrix | Produktmatrix (Zuordnung Produkte zu Konten). |
|
||||||
|
| M-077 | Production | src/backend/Centron.BL/Production | Produktion/Fertigungsaufträge (ProductionOrder). |
|
||||||
|
| M-078 | Projects | src/backend/Centron.BL/Projects | Projektverwaltung. |
|
||||||
|
| M-079 | Purchasing | src/backend/Centron.BL/Purchasing | Einkauf: Bestellvorschläge, Lieferanten, Einkaufseinstellungen, filialbezogene Lieferantenbestellungen. |
|
||||||
|
| M-080 | ReportEngine | src/backend/Centron.BL/ReportEngine | Reporterzeugung (FastReport), PDF-Export inkl. ZUGFeRD-PDF-Generierung. |
|
||||||
|
| M-081 | Reporting | src/backend/Centron.BL/Reporting | Verwaltung der Reports (ReportsBL). |
|
||||||
|
| M-082 | RiverDivo | src/backend/Centron.BL/RiverDivo | Anbindung „Riverbird/RiverDivo" (Vertragsartikel-Referenzen, River-Client). |
|
||||||
|
| M-083 | Sales: Receipts (Belegwesen) | src/backend/Centron.BL/Sales/Receipts | Belegwesen: Angebote, Aufträge, Rechnungen, Lieferscheine, Gutschriften, Anzahlungen, Abhollisten sowie Lieferantenbelege (Bestellungen, Lieferanten-Rechnungen/-Gutschriften). |
|
||||||
|
| M-084 | Sales: CustomerAssets (Verträge) | src/backend/Centron.BL/Sales/CustomerAssets | Kundenverträge und Vertragsabrechnung: Verträge, automatische Fakturierung, Timer-Billing, vertragsbezogene Belege. |
|
||||||
|
| M-085 | Sales: Customers (CRM) | src/backend/Centron.BL/Sales/Customers | Kundenverwaltung/CRM: Adressen, Kontakte, CRM-Projekte, Kundendetails, Textbausteine. |
|
||||||
|
| M-086 | Sales: Support (Helpdesk) | src/backend/Centron.BL/Sales/Support | Helpdesk/Ticketsystem inkl. Eskalationslogik und Ticketprozessen. |
|
||||||
|
| M-087 | Sales: CashBooks | src/backend/Centron.BL/Sales/CashBooks | Kassenbuchführung. |
|
||||||
|
| M-088 | Sales: Marketing | src/backend/Centron.BL/Sales/Marketing | Marketingfunktionen im Vertrieb. |
|
||||||
|
| M-089 | Sales: Calendar | src/backend/Centron.BL/Sales/Calendar | Vertriebsbezogene Kalenderfunktionen. |
|
||||||
|
| M-090 | Sales: DocumentationWizardArea | src/backend/Centron.BL/Sales/DocumentationWizardArea | Assistent zur Dokumentationserstellung im Vertriebskontext. |
|
||||||
|
| M-091 | Sales: HourlySurchargeRatesBL | src/backend/Centron.BL/Sales/HourlySurchargeRatesBL | Stundenzuschlagssätze (z. B. für Servicezeiten). |
|
||||||
|
| M-092 | Security (PdfSigning) | src/backend/Centron.BL/Security | Digitale Signatur von PDF-Dokumenten. |
|
||||||
|
| M-093 | SelfCare | src/backend/Centron.BL/SelfCare | SelfCare-Portalfunktionen (Web-Anfrageseiten für Endkunden). |
|
||||||
|
| M-094 | Services | src/backend/Centron.BL/Services | Dienste: Workflows (Prozess-Engine), CTime-Zeiterfassungs-Konnektor, Datenqualität, Tabellen-Cache. |
|
||||||
|
| M-095 | SocialMedia | src/backend/Centron.BL/SocialMedia | Social-Media-Profile von Personen/Konten. |
|
||||||
|
| M-096 | Start | src/backend/Centron.BL/Start | Anwendungsstart-Logik (StartBL). |
|
||||||
|
| M-097 | Statistics | src/backend/Centron.BL/Statistics | Statistiken: Umsatz, Mitarbeiterauslastung, Vertragsauswertung, MSP-Auswertungen. |
|
||||||
|
| M-098 | Storage | src/backend/Centron.BL/Storage | Inventur (InventoryArticlePool) und Lagerort-Logik. |
|
||||||
|
| M-099 | SystemArea | src/backend/Centron.BL/SystemArea | Systemtabellen (I3D-Systemtabelle). |
|
||||||
|
| M-100 | Tags | src/backend/Centron.BL/Tags | Verschlagwortung von Objekten (Tags). |
|
||||||
|
| M-101 | Tapi | src/backend/Centron.BL/Tapi | Telefonie-Integration (Anrufe, PhoneCallBL). |
|
||||||
|
| M-102 | TaskManager | src/backend/Centron.BL/TaskManager | Aufgabenverwaltung mit Aktions-Handlern (Helpdesk-/Report-Aktionen). |
|
||||||
|
| M-103 | Telemetry | src/backend/Centron.BL/Telemetry | Telemetrie-Erfassung der Anwendungsnutzung. |
|
||||||
|
| M-104 | TextModuleArea | src/backend/Centron.BL/TextModuleArea | Textbausteine und Anrede-/Grußformel-Ersetzung. |
|
||||||
|
| M-105 | TicketProjects | src/backend/Centron.BL/TicketProjects | Ticket-Projekte (Bündelung von Tickets). |
|
||||||
|
| M-106 | Time | src/backend/Centron.BL/Time | Zeitsteuerungs-Einstellungen (TimingSettings). |
|
||||||
|
| M-107 | ToDoArea | src/backend/Centron.BL/ToDoArea | ToDo-Verwaltung über Objektarten hinweg. |
|
||||||
|
| M-108 | Tools | src/backend/Centron.BL/Tools | Werkzeugverwaltung (ToolBL). |
|
||||||
|
| M-109 | TradePool | src/backend/Centron.BL/TradePool | „TradePool"-Handelsbörse (XML-basierter Austausch von Handelsdaten). |
|
||||||
|
| M-110 | Transactions | src/backend/Centron.BL/Transactions | Transaktionsobjekte (TransactionBL). |
|
||||||
|
| M-111 | TwoFactorAuthenticator | src/backend/Centron.BL/TwoFactorAuthenticator | Zwei-Faktor-Authentifizierung (TOTP). |
|
||||||
|
| M-112 | Urls | src/backend/Centron.BL/Urls | Verwaltung einfacher URL-Objekte (Weblinks je Objekt). |
|
||||||
|
| M-113 | VideoPortal | src/backend/Centron.BL/VideoPortal | Zuordnung von Schulungsvideos (Videoportal). |
|
||||||
|
| M-114 | VoucherManagement | src/backend/Centron.BL/VoucherManagement | Gutscheinverwaltung: Barcodes mit Status frei/ausgegeben/eingelöst. *(Beschreibung nach Detailanalyse präzisiert)* |
|
||||||
|
| M-115 | Warehousing | src/backend/Centron.BL/Warehousing | Artikelstamm und Lager: Artikel, EAN-Codes, Preise/Aktionspreise, Artikelhistorie, Umweltschutz-Angaben, Artikelimport. |
|
||||||
|
| M-116 | WebLinks | src/backend/Centron.BL/WebLinks | Aktions-Weblinks (z. B. Erinnerungen, Kontoaktivitäten per Link). |
|
||||||
|
| M-117 | WebServices (BL) | src/backend/Centron.BL/WebServices | Geschäftslogik der Webservice-Endpunkte (Datenbereitstellung für Web/Mobile/Nexus). |
|
||||||
|
| M-118 | WebSuite | src/backend/Centron.BL/WebSuite | Konfiguration der Web-Suite (Webmenü, Web-Einstellungen, Web-HD-Fragen). |
|
||||||
|
| M-119 | WebVersion | src/backend/Centron.BL/WebVersion | Versionsverwaltung der Webanwendung. |
|
||||||
|
| M-120 | Helpers (BL) | src/backend/Centron.BL/Helpers | Technische Hilfsklassen (Graph-Client, PDF-Interaktion, String-/Bild-Helfer). |
|
||||||
|
| M-121 | Exceptions (BL) | src/backend/Centron.BL/Exceptions | Fachliche Ausnahmen (z. B. TicketExpiredException). |
|
||||||
|
|
||||||
|
### B. Weitere Schichten, Anwendungen und Artefakte
|
||||||
|
|
||||||
|
| Nr. | Modul / Komponente | Pfad | Fachliche Aufgabe (1 Satz) |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-122 | Centron.DAO (Persistenz) | src/backend/Centron.DAO | Datenzugriffsschicht auf NHibernate-Basis: Mappings, Sessions, Change-Tracking, Repositories, benannte Abfragen. |
|
||||||
|
| M-123 | Centron.Entities | src/backend/Centron.Entities | Entitätsmodell (persistierte Geschäftsobjekte). |
|
||||||
|
| M-124 | Centron.Common | src/backend/Centron.Common | Querschnittsbibliothek: Logging, Einstellungen, Berechnungen, Konstanten, Benutzerkontext. |
|
||||||
|
| M-125 | Centron.Interfaces | src/backend/Centron.Interfaces | Schnittstellen- und Konstantendefinitionen (u. a. Rechte-Konstanten UserRightsConst). |
|
||||||
|
| M-126 | Centron.Gateway | src/backend/Centron.Gateway | Import-/Export-Gateway: EDI-Formate (Alltron, ALSO, EGIS, Herweck, Komsa), OpenTrans, ZUGFeRD 2.1, Onlinebanking, MSP-Collector, Portal. |
|
||||||
|
| M-127 | Centron.WPF.UI (+ Extension) | src/centron/Centron.WPF.UI, .../Centron.WPF.UI.Extension | Windows-Desktop-Client (WPF/XAML): Masken, Module, Wizards, Lokalisierung. |
|
||||||
|
| M-128 | Centron.Controls (+ Preview) | src/shared/Centron.Controls, .../Centron.Controls.Preview | Wiederverwendbare UI-Controls (DevExpress-basiert) inkl. Dokumentvorschau. |
|
||||||
|
| M-129 | Centron.Core (shared) | src/shared/Centron.Core | Gemeinsame Kernbibliothek von Client und Server. |
|
||||||
|
| M-130 | CentronNexus (Blazor-Web) | src/nexus/CentronNexus | Webclient „c-entron Nexus" (Blazor): WebCart/Shop, WebOffer, ServiceBoard, Dokument-Signierung, Produktionsauftrags-Management. |
|
||||||
|
| M-131 | CentronNexus.Host | src/nexus/CentronNexus.Host | Hosting-Anwendung des Nexus-Webclients. |
|
||||||
|
| M-132 | CentronNexus.OutlookAddIn | src/nexus/CentronNexus.OutlookAddIn | Outlook-Add-In des Nexus-Webclients. |
|
||||||
|
| M-133 | Centron.Controllers (REST-API) | src/webservice/Centron.Controllers | REST-Controller des c-entron Webservice (versionierte API, Autorisierung). |
|
||||||
|
| M-134 | Centron.WebServices.Core | src/webservice/Centron.WebServices.Core | Kern des Webservice (Infrastruktur der Dienstschicht). |
|
||||||
|
| M-135 | Centron.Host (+ Console/WindowsService) | src/webservice/Centron.Host, .../Centron.Host.Console, .../Centron.Host.WindowsService | Hosting des Webservice als Konsole oder Windows-Dienst. |
|
||||||
|
| M-136 | ConnectionManager | src/webservice/c-entron.misc.ConnectionManager | Verwaltung der Verbindungskonfiguration (Werkzeug). |
|
||||||
|
| M-137 | Centron.Api.EbInterface | src/apis/Centron.Api.EbInterface | Erzeugung österreichischer E-Rechnungen (ebInterface). |
|
||||||
|
| M-138 | Centron.Api.Gls | src/apis/Centron.Api.Gls | Versandanbindung GLS (Paketlabel). |
|
||||||
|
| M-139 | Centron.Api.Shipcloud | src/apis/Centron.Api.Shipcloud | Versandanbindung Shipcloud (Multi-Carrier-Versand). |
|
||||||
|
| M-140 | Centron.APIs.CopDataAccess | src/apis/Centron.APIs.CopDataAccess | Anbindung „COP" (SOAP-Datenzugriff auf Distributor). |
|
||||||
|
| M-141 | Centron.APIs.EgisDataAccess | src/apis/Centron.APIs.EgisDataAccess | Anbindung EGIS (Distributor-Datenzugriff). |
|
||||||
|
| M-142 | Centron.APIs.FinAPI | src/apis/Centron.APIs.FinAPI | Anbindung finAPI (Onlinebanking-REST-Dienst). |
|
||||||
|
| M-143 | Centron.APIs.IcecatDataAccess | src/apis/Centron.APIs.IcecatDataAccess | Anbindung Icecat (Produktdatenkatalog). |
|
||||||
|
| M-144 | Centron.APIs.ITscopeDataAccess | src/apis/Centron.APIs.ITscopeDataAccess | Anbindung ITscope (Handelsplattform). |
|
||||||
|
| M-145 | Centron.Api.docuFORM | Centron.Api.docuFORM | Anbindung docuFORM (Druckerdaten/Managed Print). |
|
||||||
|
| M-146 | Datenbankschema | SSMS_DB_SCHEMA.sql | SQL-Schema-Dump der c-entron-Datenbank (1558 CREATE TABLE, Constraints, Indizes). |
|
||||||
|
| M-147 | Deployment/Installer | deployment | Installer (WixSharp) und Deployment-Konfiguration für c-entron und Riverbird. |
|
||||||
|
| M-148 | Docker/Betrieb | docker | Container-Definitionen für API, Webservice, Demo, Mailcatcher, Regressionstest-DB. |
|
||||||
|
| M-149 | Scripts | scripts | Hilfs- und Wartungsskripte. |
|
||||||
|
| M-150 | Dokumentation | docs | Entwickler-/Betriebsdokumentation (Features, Architektur, Security, EDI, Belege). |
|
||||||
|
| M-151 | Tests | tests | Test-Suiten (Unit, Integration, EndToEnd, Playwright). |
|
||||||
|
|
||||||
|
**Hinweis:** Das Inventar wird bei Bedarf ergänzt, aber nicht gekürzt.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Abdeckungstabelle (je Modul des Inventars)
|
||||||
|
|
||||||
|
Einstufung: `tief` = mehrere Anforderungen inkl. gelesener Kernlogik der risikorelevanten Pfade; `mittel` = 2-3 Anforderungen auf Basis gelesener Kernmethoden; `flach` = 1-2 Anforderungen auf Basis von Methodensignaturen/ausgewählten Codeausschnitten; `nicht analysiert` = keine Anforderung (mit Begründung).
|
||||||
|
|
||||||
|
| Modul | Bezeichnung | Einstufung | Anzahl Anforderungen | Anforderungen |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M-001 | Accounting (Bankkonten) | mittel | 2 | SwRS-019, SwRS-155 |
|
||||||
|
| M-002 | Accounts (Konten-/Adressstamm) | mittel | 3 | SwRS-020, SyRS-020, StRS-001 |
|
||||||
|
| M-003 | Administration: AccessTokens | mittel | 3 | SyRS-017, SwRS-021, StRS-013 |
|
||||||
|
| M-004 | Administration: Applications | flach | 1 | SwRS-022 |
|
||||||
|
| M-005 | Administration: ArtificialIntelligence | mittel | 3 | SyRS-019, SwRS-023, StRS-029 |
|
||||||
|
| M-006 | Administration: BackgroundServices | mittel | 3 | SyRS-018, SwRS-024, StRS-031 |
|
||||||
|
| M-007 | Administration: BookKeepingAccountSystems | flach | 1 | SwRS-025 |
|
||||||
|
| M-008 | Administration: CentronConfigDb | flach | 1 | SwRS-026 |
|
||||||
|
| M-009 | Administration: Company/CompanyInformations | mittel | 3 | SyRS-024, SwRS-027, StRS-033 |
|
||||||
|
| M-010 | Administration: Connections | flach | 1 | SwRS-028 |
|
||||||
|
| M-011 | Administration: Customization | mittel | 2 | SwRS-029, StRS-032 |
|
||||||
|
| M-012 | Administration: DataSecurity | mittel | 3 | SyRS-022, SwRS-030, StRS-030 |
|
||||||
|
| M-013 | Administration: Documents/FileManagement | mittel | 3 | SwRS-031, SyRS-026, StRS-020 |
|
||||||
|
| M-014 | Administration: Employees | flach | 1 | SwRS-032 |
|
||||||
|
| M-015 | Administration: Environments | flach | 1 | SwRS-033 |
|
||||||
|
| M-016 | Administration: Licensing | tief | 3 | SyRS-003, SwRS-009, StRS-014 |
|
||||||
|
| M-017 | Administration: Logins/Auth | tief | 9 | SyRS-003, SyRS-004, SyRS-005, SyRS-006, SyRS-007, SwRS-002, SwRS-003, SwRS-005, StRS-013 |
|
||||||
|
| M-018 | Administration: Mandatory | mittel | 4 | SyRS-012, SwRS-012, SyRS-024, StRS-033 |
|
||||||
|
| M-019 | Administration: Masterdata | flach | 1 | SwRS-034 |
|
||||||
|
| M-020 | Administration: NetworkDiagnostics | flach | 1 | SwRS-035 |
|
||||||
|
| M-021 | Administration: PerformanceTests/Profiling | flach | 1 | SwRS-036 |
|
||||||
|
| M-022 | Administration: PhoneSettings | mittel | 2 | SwRS-037, SyRS-030 |
|
||||||
|
| M-023 | Administration: Portal | flach | 1 | SwRS-038 |
|
||||||
|
| M-024 | Administration: Rights | tief | 7 | SyRS-001, SyRS-002, SyRS-008, SwRS-001, SwRS-004, SwRS-008, StRS-012 |
|
||||||
|
| M-025 | Administration: Scripts/SQLManagement | flach | 1 | SwRS-039 |
|
||||||
|
| M-026 | Administration: Settings | mittel | 4 | SyRS-023, SwRS-040, SyRS-050, StRS-032 |
|
||||||
|
| M-027 | Administration: Themes | flach | 1 | SwRS-041 |
|
||||||
|
| M-028 | Administration: WebServiceConfiguration | flach | 1 | SwRS-042 |
|
||||||
|
| M-029 | AppointmentRequests | flach | 1 | SwRS-043 |
|
||||||
|
| M-030 | ArtificialIntelligence | mittel | 2 | SyRS-019, StRS-029 |
|
||||||
|
| M-031 | BusinessPartner | flach | 1 | SwRS-044 |
|
||||||
|
| M-032 | Buying | flach | 1 | SwRS-045 |
|
||||||
|
| M-033 | Calendar | mittel | 3 | SwRS-046, SyRS-029, SwRS-157 |
|
||||||
|
| M-034 | CentronIcons | flach | 1 | SwRS-047 |
|
||||||
|
| M-035 | CentronNexus (BL) | flach | 1 | SwRS-048 |
|
||||||
|
| M-036 | ChangeTracking | mittel | 3 | SyRS-009, SwRS-007, StRS-030 |
|
||||||
|
| M-037 | Chats | mittel | 2 | SwRS-049, StRS-017 |
|
||||||
|
| M-038 | CheckListArea | flach | 1 | SwRS-050 |
|
||||||
|
| M-039 | Core (BL-Kern) | mittel | 4 | SyRS-009, SyRS-010, SwRS-006, SwRS-007 |
|
||||||
|
| M-040 | CountryArea | flach | 1 | SwRS-051 |
|
||||||
|
| M-041 | CPra | flach | 1 | SwRS-052 |
|
||||||
|
| M-042 | CustomerArea | mittel | 2 | SwRS-059, StRS-023 |
|
||||||
|
| M-043 | Customizations (CustomTables) | mittel | 2 | SwRS-053, StRS-032 |
|
||||||
|
| M-044 | DataExchange | tief | 7 | SyRS-021, SwRS-057, SwRS-058, SyRS-043, StRS-009, StRS-010, StRS-021 |
|
||||||
|
| M-045 | Devices | mittel | 3 | SwRS-054, SyRS-028, StRS-022 |
|
||||||
|
| M-046 | DocuBoard | mittel | 3 | SwRS-055, SyRS-028, StRS-022 |
|
||||||
|
| M-047 | DocumentationArea | flach | 1 | SwRS-056 |
|
||||||
|
| M-048 | EDI | mittel | 4 | SyRS-027, SwRS-060, StRS-007, StRS-010 |
|
||||||
|
| M-049 | EmployeeArea | flach | 1 | SwRS-061 |
|
||||||
|
| M-050 | ExpectedEvents | flach | 1 | SwRS-062 |
|
||||||
|
| M-051 | ExternalHelpdesk | flach | 1 | SwRS-063 |
|
||||||
|
| M-052 | ExternalToolsBL | flach | 1 | SwRS-064 |
|
||||||
|
| M-053 | Finances | tief | 6 | SyRS-032, SwRS-065, SwRS-066, SyRS-050, SwRS-155, StRS-009 |
|
||||||
|
| M-054 | Gateway (BL) | flach | 1 | SwRS-067 |
|
||||||
|
| M-055 | GUI (BL-Anteil) | flach | 1 | SwRS-134 |
|
||||||
|
| M-056 | IndexSearch | mittel | 3 | SyRS-033, SwRS-068, StRS-027 |
|
||||||
|
| M-057 | Integrations | flach | 1 | SwRS-069 |
|
||||||
|
| M-058 | ItPlanner | flach | 1 | SwRS-070 |
|
||||||
|
| M-059 | Logistics | mittel | 2 | SwRS-071, StRS-008 |
|
||||||
|
| M-060 | Mail | mittel | 4 | SyRS-035, SwRS-072, SwRS-157, StRS-017 |
|
||||||
|
| M-061 | MailScanner | mittel | 2 | SyRS-036, SwRS-073 |
|
||||||
|
| M-062 | Mailings | mittel | 2 | SwRS-074, StRS-026 |
|
||||||
|
| M-063 | MassUpdate | mittel | 2 | SyRS-034, SwRS-075 |
|
||||||
|
| M-064 | Mobile | flach | 1 | SwRS-076 |
|
||||||
|
| M-065 | Modules | mittel | 2 | SwRS-077, StRS-014 |
|
||||||
|
| M-066 | MyCentron | mittel | 3 | SyRS-029, SwRS-078, StRS-018 |
|
||||||
|
| M-067 | MyDay | mittel | 4 | SyRS-029, SwRS-079, SwRS-158, StRS-018 |
|
||||||
|
| M-068 | NexusNotifications | flach | 1 | SwRS-080 |
|
||||||
|
| M-069 | NexusTicketViews | flach | 1 | SwRS-081 |
|
||||||
|
| M-070 | Notifications | flach | 1 | SwRS-082 |
|
||||||
|
| M-071 | ObjectExternalReferences | mittel | 2 | SwRS-083, StRS-021 |
|
||||||
|
| M-072 | Outlook | flach | 1 | SwRS-084 |
|
||||||
|
| M-073 | PasswordManagementArea | mittel | 2 | SwRS-085, StRS-028 |
|
||||||
|
| M-074 | PasswordManager | mittel | 2 | SwRS-086, StRS-028 |
|
||||||
|
| M-075 | Processes | flach | 1 | SwRS-087 |
|
||||||
|
| M-076 | ProductMatrix | mittel | 2 | SwRS-088, StRS-025 |
|
||||||
|
| M-077 | Production | mittel | 2 | SwRS-089, StRS-024 |
|
||||||
|
| M-078 | Projects | mittel | 2 | SwRS-090, StRS-025 |
|
||||||
|
| M-079 | Purchasing | mittel | 2 | SwRS-091, StRS-007 |
|
||||||
|
| M-080 | ReportEngine | mittel | 3 | SyRS-025, SyRS-043, StRS-015 |
|
||||||
|
| M-081 | Reporting | flach | 1 | SyRS-025 |
|
||||||
|
| M-082 | RiverDivo | flach | 1 | SwRS-101 |
|
||||||
|
| M-083 | Sales: Receipts (Belegwesen) | tief | 16 | SyRS-011, SyRS-012, SyRS-013, SyRS-014, SyRS-015, SyRS-016, SwRS-010, SwRS-013, SwRS-014, SwRS-015, SwRS-016, SwRS-017, SwRS-018, SwRS-154, StRS-002, StRS-003 |
|
||||||
|
| M-084 | Sales: CustomerAssets (Verträge) | tief | 11 | SyRS-028, SyRS-037, SyRS-038, SyRS-039, SwRS-092, SwRS-093, SwRS-094, SwRS-095, StRS-004, StRS-006, StRS-022 |
|
||||||
|
| M-085 | Sales: Customers (CRM) | flach | 1 | SwRS-102 |
|
||||||
|
| M-086 | Sales: Support (Helpdesk) | tief | 11 | SyRS-039, SyRS-040, SyRS-041, SwRS-095, SwRS-096, SwRS-097, SwRS-098, SwRS-099, SwRS-156, StRS-005, StRS-006 |
|
||||||
|
| M-087 | Sales: CashBooks | tief | 4 | SyRS-042, SwRS-100, StRS-003, StRS-009 |
|
||||||
|
| M-088 | Sales: Marketing | mittel | 2 | SwRS-103, StRS-026 |
|
||||||
|
| M-089 | Sales: Calendar | flach | 1 | SwRS-104 |
|
||||||
|
| M-090 | Sales: DocumentationWizardArea | flach | 1 | SwRS-105 |
|
||||||
|
| M-091 | Sales: HourlySurchargeRatesBL | flach | 1 | SwRS-106 |
|
||||||
|
| M-092 | Security (PdfSigning) | mittel | 2 | SwRS-107, StRS-020 |
|
||||||
|
| M-093 | SelfCare | mittel | 2 | SwRS-108, StRS-019 |
|
||||||
|
| M-094 | Services | flach | 1 | SwRS-109 |
|
||||||
|
| M-095 | SocialMedia | flach | 1 | SwRS-110 |
|
||||||
|
| M-096 | Start | flach | 1 | SwRS-111 |
|
||||||
|
| M-097 | Statistics | mittel | 2 | SwRS-135, StRS-016 |
|
||||||
|
| M-098 | Storage | mittel | 2 | SwRS-112, StRS-008 |
|
||||||
|
| M-099 | SystemArea | flach | 1 | SwRS-113 |
|
||||||
|
| M-100 | Tags | flach | 1 | SwRS-114 |
|
||||||
|
| M-101 | Tapi | mittel | 3 | SyRS-030, SwRS-115, StRS-017 |
|
||||||
|
| M-102 | TaskManager | flach | 1 | SwRS-116 |
|
||||||
|
| M-103 | Telemetry | flach | 1 | SwRS-117 |
|
||||||
|
| M-104 | TextModuleArea | flach | 1 | SwRS-118 |
|
||||||
|
| M-105 | TicketProjects | mittel | 2 | SwRS-119, StRS-025 |
|
||||||
|
| M-106 | Time | flach | 1 | SwRS-120 |
|
||||||
|
| M-107 | ToDoArea | mittel | 2 | SyRS-029, SwRS-121 |
|
||||||
|
| M-108 | Tools | flach | 1 | SwRS-122 |
|
||||||
|
| M-109 | TradePool | flach | 1 | SwRS-123 |
|
||||||
|
| M-110 | Transactions | flach | 1 | SwRS-124 |
|
||||||
|
| M-111 | TwoFactorAuthenticator | flach | 1 | SwRS-011 |
|
||||||
|
| M-112 | Urls | flach | 1 | SwRS-125 |
|
||||||
|
| M-113 | VideoPortal | flach | 1 | SwRS-126 |
|
||||||
|
| M-114 | VoucherManagement | flach | 1 | SwRS-127 |
|
||||||
|
| M-115 | Warehousing | mittel | 4 | SyRS-013, SwRS-014, SwRS-128, StRS-008 |
|
||||||
|
| M-116 | WebLinks | flach | 1 | SwRS-129 |
|
||||||
|
| M-117 | WebServices (BL) | flach | 1 | SwRS-136 |
|
||||||
|
| M-118 | WebSuite | flach | 1 | SwRS-130 |
|
||||||
|
| M-119 | WebVersion | flach | 1 | SwRS-131 |
|
||||||
|
| M-120 | Helpers (BL) | flach | 1 | SwRS-132 |
|
||||||
|
| M-121 | Exceptions (BL) | flach | 1 | SwRS-133 |
|
||||||
|
| M-122 | Centron.DAO (Persistenz) | flach | 1 | SwRS-137 |
|
||||||
|
| M-123 | Centron.Entities | flach | 1 | SwRS-138 |
|
||||||
|
| M-124 | Centron.Common | flach | 1 | SwRS-139 |
|
||||||
|
| M-125 | Centron.Interfaces | flach | 1 | SwRS-140 |
|
||||||
|
| M-126 | Centron.Gateway | mittel | 2 | SyRS-043, SwRS-141 |
|
||||||
|
| M-127 | Centron.WPF.UI (+ Extension) | mittel | 2 | SyRS-031, SwRS-142 |
|
||||||
|
| M-128 | Centron.Controls (+ Preview) | flach | 1 | SwRS-143 |
|
||||||
|
| M-129 | Centron.Core (shared) | flach | 1 | SwRS-144 |
|
||||||
|
| M-130 | CentronNexus (Blazor-Web) | mittel | 5 | SyRS-031, SyRS-045, SwRS-145, SwRS-156, StRS-019 |
|
||||||
|
| M-131 | CentronNexus.Host | flach | 1 | SwRS-145 |
|
||||||
|
| M-132 | CentronNexus.OutlookAddIn | flach | 1 | SwRS-145 |
|
||||||
|
| M-133 | Centron.Controllers (REST-API) | mittel | 3 | SyRS-031, SyRS-046, SwRS-147 |
|
||||||
|
| M-134 | Centron.WebServices.Core | flach | 1 | SwRS-146 |
|
||||||
|
| M-135 | Centron.Host (+ Console/WindowsService) | flach | 1 | SwRS-146 |
|
||||||
|
| M-136 | ConnectionManager | flach | 1 | SwRS-146 |
|
||||||
|
| M-137 | Centron.Api.EbInterface | flach | 1 | SyRS-043 |
|
||||||
|
| M-138 | Centron.Api.Gls | mittel | 3 | SyRS-044, SwRS-151, StRS-011 |
|
||||||
|
| M-139 | Centron.Api.Shipcloud | mittel | 3 | SyRS-044, SwRS-151, StRS-011 |
|
||||||
|
| M-140 | Centron.APIs.CopDataAccess | flach | 1 | SwRS-148 |
|
||||||
|
| M-141 | Centron.APIs.EgisDataAccess | flach | 1 | SwRS-148 |
|
||||||
|
| M-142 | Centron.APIs.FinAPI | flach | 1 | SwRS-149 |
|
||||||
|
| M-143 | Centron.APIs.IcecatDataAccess | flach | 1 | SwRS-148 |
|
||||||
|
| M-144 | Centron.APIs.ITscopeDataAccess | flach | 1 | SwRS-148 |
|
||||||
|
| M-145 | Centron.Api.docuFORM | flach | 1 | SwRS-150 |
|
||||||
|
| M-146 | Datenbankschema | flach | 1 | SwRS-152 |
|
||||||
|
| M-147 | Deployment/Installer | mittel | 3 | SyRS-048, SwRS-153, StRS-031 |
|
||||||
|
| M-148 | Docker/Betrieb | mittel | 4 | SyRS-047, SyRS-049, SwRS-153, StRS-031 |
|
||||||
|
| M-149 | Scripts | mittel | 2 | SyRS-048, SwRS-153 |
|
||||||
|
| M-150 | Dokumentation | nicht analysiert | 0 | – (reine Entwickler-/Betriebsdokumentation ohne eigene Systemfunktion; als KONTEXT-Belegquelle genutzt, z. B. für SyRS-043, SwRS-157) |
|
||||||
|
| M-151 | Tests | mittel | 2 | SyRS-049, StRS-031 |
|
||||||
|
|
||||||
|
**Summen:** tief: 9 Module, mittel: 58, flach: 83, nicht analysiert: 1 (gesamt 151 Module).
|
||||||
|
|
||||||
|
## Konsistenzcheck
|
||||||
|
|
||||||
|
Automatisiert über alle drei Spezifikationsdateien ausgeführt (241 Anforderungsblöcke):
|
||||||
|
|
||||||
|
| Prüfung | Ergebnis |
|
||||||
|
|---|---|
|
||||||
|
| Doppelte oder mehrfach vergebene IDs | keine (241 eindeutige IDs: 33 StRS, 50 SyRS, 158 SwRS) |
|
||||||
|
| Anforderungen ohne Beleg | keine (jeder Block enthält mind. einen klassifizierten Beleg) |
|
||||||
|
| Anforderungen ohne Übernahmewürdigkeit | keine |
|
||||||
|
| Anforderungen ohne Prüfidee | keine |
|
||||||
|
| Tracelinks auf nicht existierende IDs | keine |
|
||||||
|
| SwRS ohne SyRS-Referenz / SyRS ohne StRS-Referenz | keine (siehe Traceability.md) |
|
||||||
|
| Abgleich Hypothesen.md ↔ Inline-Markierungen | deckungsgleich: SyRS-050, SwRS-154, SwRS-155, SwRS-156, SwRS-157, SwRS-158 (6 Stück) |
|
||||||
|
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk | keine gefundenen; erkannte fachliche Doppelimplementierungen sind als Konsolidierungskandidaten markiert (siehe Liste unten) |
|
||||||
|
|
||||||
|
**Wesentliche Konsolidierungskandidaten (fachlich gleiche Konzepte in getrennten Implementierungen):**
|
||||||
|
|
||||||
|
1. Gerätedatenhaltungen: AccountDevices (M-045) vs. CustomerAssets/„Stammblätter" (M-084) vs. DocuBoard-Assetmanagement (M-046) → ein Asset-Konzept (SyRS-028, StRS-022).
|
||||||
|
2. Zwei Belegmodelle: Sales/Receipts (neu) vs. Sales/CustomerAssets (alt) für dieselben Belegarten (SyRS-011).
|
||||||
|
3. Zwei Rechtemodelle: interne Rechte (Sichtrus/Sichmemb) vs. WebAccountsRights (SyRS-001/SyRS-002).
|
||||||
|
4. Drei 2FA-Wege: RADIUS, E-Mail-Link, TOTP (SyRS-005, SwRS-011).
|
||||||
|
5. Zwei Passwortverwaltungen: PasswordManagementArea vs. PasswordManager (SwRS-085/SwRS-086).
|
||||||
|
6. Zwei Workflow-/Prozess-Engines: Processes vs. Services/Workflows (SwRS-087/SwRS-109); zusätzlich MailScanner-Workflows (SyRS-036).
|
||||||
|
7. Zwei Customizing-Mechanismen: Custom Properties vs. Custom Tables (SwRS-029/SwRS-053).
|
||||||
|
8. Drei Projektbegriffe: Projects, CrmProjects, TicketProjects (SwRS-090/SwRS-119, StRS-025).
|
||||||
|
9. Zwei Aufgabenkonzepte: ToDoArea vs. TaskManager (SwRS-116/SwRS-121).
|
||||||
|
10. Zwei Benachrichtigungssysteme: Notifications vs. NexusNotifications (SwRS-080/SwRS-082).
|
||||||
|
11. EDI-Logik doppelt: Centron.BL/EDI vs. Centron.Gateway/EDI_* (SyRS-027/SwRS-141).
|
||||||
|
12. Bankverbindungen doppelt: Felder in Tabelle Kunden vs. BankAccount-Objekte (SwRS-152/SwRS-019).
|
||||||
|
13. Zwei Endkunden-Formularwege: SelfCare vs. Nexus-Kundenportal-Formulare (SwRS-108/SyRS-045).
|
||||||
|
14. Versandwege GLS-direkt vs. Shipcloud (SyRS-044).
|
||||||
|
15. Desktop-Client (WPF) vs. Nexus-Web-UI für dieselben Prozesse (SyRS-031, SwRS-142/SwRS-145).
|
||||||
|
|
||||||
|
## Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
|
||||||
|
|
||||||
|
75 Anforderungen sind risikorelevant. Belegsituation:
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR-Beleg vorhanden | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| SyRS-001 | Gruppenbasierte Benutzerrechtepruefung | ja | belegt |
|
||||||
|
| SyRS-002 | Getrenntes Rechtemodell fuer Web-Accounts | ja | belegt |
|
||||||
|
| SyRS-003 | Ticketbasierte Sitzungen mit Lizenzpruefung | ja | belegt |
|
||||||
|
| SyRS-004 | Mehrere Authentifizierungsverfahren | ja | belegt |
|
||||||
|
| SyRS-005 | Zwei-Faktor-Authentifizierung | ja | belegt |
|
||||||
|
| SyRS-006 | Zeitgesteuerte Kontodeaktivierung | ja | belegt |
|
||||||
|
| SyRS-007 | Anwendungsbezogene Anmelderechte | ja | belegt |
|
||||||
|
| SyRS-008 | Standard-Rechtegruppen | ja | belegt |
|
||||||
|
| SwRS-001 | Rechteermittlung SQL+Cache | ja | belegt |
|
||||||
|
| SwRS-002 | Passwort SHA1 ungesalzen | ja | belegt |
|
||||||
|
| SwRS-003 | 2FA-Validatorwahl | ja | belegt |
|
||||||
|
| SwRS-004 | Rechtegruppenverwaltung | ja | belegt |
|
||||||
|
| SwRS-005 | Ticket-Wiederverwendung+LoginIP | ja | belegt |
|
||||||
|
| SwRS-008 | Standardrechtegruppen aus Ressource | ja | belegt |
|
||||||
|
| SwRS-009 | Signaturvalidierte Lizenzdatei | ja | belegt |
|
||||||
|
| SyRS-011 | Belegkette Weiterfuehrungswege | ja | belegt |
|
||||||
|
| SyRS-012 | Nummernkreise je Mandant/Filiale | ja | belegt |
|
||||||
|
| SyRS-013 | Bestandswirkung der Belege | ja | belegt |
|
||||||
|
| SyRS-014 | Mindestpreisschutz | ja | belegt |
|
||||||
|
| SwRS-010 | Belegnummernvergabe+Templatekunde | ja | belegt |
|
||||||
|
| SwRS-011 | TOTP-Zweitfaktor | ja | belegt |
|
||||||
|
| SwRS-012 | Nummernkreis-Kaskade | ja | belegt |
|
||||||
|
| SwRS-014 | Negativbuchung nur mit Recht | ja | belegt |
|
||||||
|
| SwRS-015 | Mindestpreis-Reauth | ja | belegt |
|
||||||
|
| SyRS-017 | API-Zugriffstokens | ja | belegt |
|
||||||
|
| SwRS-019 | Bankverbindungen Rechte+Default | ja | belegt |
|
||||||
|
| SwRS-020 | Kontenstamm Rechte+FiBu-Nummer | ja | belegt |
|
||||||
|
| SwRS-021 | API-Token Hash+Ablauf+Log | ja | belegt |
|
||||||
|
| SwRS-026 | Konfig-DB Masterkey | ja | belegt |
|
||||||
|
| SyRS-022 | DSGVO Loeschkonzept | ja | belegt |
|
||||||
|
| SwRS-027 | Kollisionssichere Nummernvergabe | ja | belegt |
|
||||||
|
| SwRS-030 | DSGVO-Kontaktloeschung | ja | belegt |
|
||||||
|
| SyRS-021 | FiBu-Uebergabe DATEV | ja | belegt |
|
||||||
|
| SwRS-057 | FiBu-Exportkonfigurationen | ja | belegt |
|
||||||
|
| SwRS-058 | Doppeluebergabeschutz FiBu | ja | belegt |
|
||||||
|
| SyRS-032 | Onlinebanking-Zahlungsabgleich | ja | belegt |
|
||||||
|
| SwRS-065 | Zahlungseingangsprotokoll | ja | belegt |
|
||||||
|
| SwRS-066 | Bankumsatz-Zuordnung/Buchung | ja | belegt |
|
||||||
|
| SwRS-085 | Kundenzugangsdaten+Logs | ja | belegt |
|
||||||
|
| SwRS-086 | Passwortmanager Siegel | ja | belegt |
|
||||||
|
| SyRS-037 | Vertragsverwaltung Laufzeit/Intervalle | ja | belegt |
|
||||||
|
| SyRS-038 | Automatische Vertragsfakturierung | ja | belegt |
|
||||||
|
| SyRS-039 | Timer-Billing | ja | belegt |
|
||||||
|
| SyRS-040 | Helpdesk Rechte+Status | ja | belegt |
|
||||||
|
| SyRS-042 | Kassenbuch | ja | belegt |
|
||||||
|
| SwRS-092 | Vertrags-Datumsarithmetik | ja | belegt |
|
||||||
|
| SwRS-093 | Auto-Vertragsschliessen | ja | belegt |
|
||||||
|
| SwRS-094 | Abrechnungsfaellige Kunden+Zaehler | ja | belegt |
|
||||||
|
| SwRS-095 | Timer-Belegerzeugung | ja | belegt |
|
||||||
|
| SwRS-096 | Ticket-Rechtepruefung Save | ja | belegt |
|
||||||
|
| SwRS-097 | Ticket-Sichtbarkeit restriktiv | ja | belegt |
|
||||||
|
| SwRS-100 | Kassenbuchbuchung | ja | belegt |
|
||||||
|
| SwRS-101 | Riverbird-Ticketvalidierung | ja | belegt |
|
||||||
|
| SwRS-106 | Stundenzuschlagssaetze | ja | belegt |
|
||||||
|
| SwRS-107 | PDF-Signatur | ja | belegt |
|
||||||
|
| SwRS-112 | Inventur | ja | belegt |
|
||||||
|
| SwRS-127 | Gutscheinverwaltung | ja | belegt |
|
||||||
|
| SyRS-043 | E-Rechnungsformate | ja | belegt |
|
||||||
|
| SyRS-046 | REST-API Rechteautorisierung | ja | belegt |
|
||||||
|
| SwRS-144 | Core-Bibliothek TOTP | ja | belegt |
|
||||||
|
| SwRS-147 | Versionierte Controller | ja | belegt |
|
||||||
|
| SwRS-149 | finAPI-Client | ja | belegt |
|
||||||
|
| SyRS-050 | [HYPOTHESE] Mahnwesen | nein | HYPOTHESE |
|
||||||
|
| SwRS-154 | [HYPOTHESE] Anzahlungsverrechnung | ja | HYPOTHESE |
|
||||||
|
| SwRS-155 | [HYPOTHESE] SEPA-Lastschrift | ja | HYPOTHESE |
|
||||||
|
| StRS-003 | Geschuetzte Fakturierung | ja | belegt |
|
||||||
|
| StRS-004 | Vertragsgeschaeft | ja | belegt |
|
||||||
|
| StRS-006 | Leistungserfassung | ja | belegt |
|
||||||
|
| StRS-009 | Finanzprozesse | ja | belegt |
|
||||||
|
| StRS-010 | E-Belegaustausch | ja | belegt |
|
||||||
|
| StRS-012 | Berechtigungssteuerung | ja | belegt |
|
||||||
|
| StRS-013 | Sichere Anmeldung/API | ja | belegt |
|
||||||
|
| StRS-014 | Lizenz-/Modulsteuerung | ja | belegt |
|
||||||
|
| StRS-028 | Kundenzugangsdaten | ja | belegt |
|
||||||
|
| StRS-030 | DSGVO+Audit | ja | belegt |
|
||||||
|
|
||||||
|
**Regelprüfung:** Alle risikorelevanten Anforderungen besitzen entweder einen PRIMÄR-Beleg mit benannter durchsetzender Stelle oder sind als `[HYPOTHESE]` gekennzeichnet (betrifft SyRS-050 Mahnwesen). Kein Verstoß gegen die risikobasierte Priorisierung.
|
||||||
|
|
||||||
|
## Selbstbewertung
|
||||||
|
|
||||||
|
**Umfang des Laufs:** 241 Anforderungen (33 StRS, 50 SyRS, 158 SwRS) über 151 Inventarmodule; 6 Hypothesen (2,5 %); 75 risikorelevante Anforderungen.
|
||||||
|
|
||||||
|
**Analysetiefe (absolute Zahlen):**
|
||||||
|
- tief: 9 Module (M-016 Licensing, M-017 Logins/Auth, M-024 Rights, M-044 DataExchange/FiBu, M-053 Finances/Onlinebanking, M-083 Receipts/Belegwesen, M-084 CustomerAssets/Verträge, M-086 Support/Helpdesk, M-087 CashBooks) - Kernlogik der risikorelevanten Pfade wurde im Quelltext gelesen.
|
||||||
|
- mittel: 58 Module (2-3 Anforderungen, Kernmethoden gelesen).
|
||||||
|
- flach: 83 Module (1 Anforderung auf Basis von Klassen-/Methodensignaturen und gezielten Codeausschnitten).
|
||||||
|
- nicht analysiert: 1 Modul (M-150 docs - reine Dokumentation, als KONTEXT-Belegquelle genutzt).
|
||||||
|
|
||||||
|
**Mindestabdeckung:** erreicht. Jedes der 151 Module hat mindestens eine Anforderung; einzige Ausnahme ist M-150 mit dokumentierter Begründung (zulässig laut Vorgabe: `nicht analysiert` mit Begründung).
|
||||||
|
|
||||||
|
**Dünne Belegstellen (ehrliche Abgrenzung):**
|
||||||
|
- Bei flach eingestuften Modulen stützen sich die PRIMÄR-Belege auf gelesene Methodensignaturen und kurze Codeausschnitte, nicht auf vollständige Methodenrümpfe (z. B. SwRS-047 Icons, SwRS-070 ItPlanner, SwRS-090 Projekte, SwRS-124 Transactions, SwRS-143 Controls). Die Aussagen sind bewusst eng an den gesicherten Befund formuliert.
|
||||||
|
- Rein strukturbasierte Belege (Ordner-/Projektexistenz statt Prüf logik) tragen SwRS-142 (WPF-Client), SwRS-143 (Controls), SwRS-145 (Nexus), SwRS-146 (Hosting), SyRS-031 (Mehrkanal), SyRS-049 (Tests) - hier ist die Existenz der Struktur selbst der Fakt.
|
||||||
|
- Hypothesen betreffen v. a. Abrechnungsdetails (Mahnwesen, SEPA-Datei, Anzahlungsverrechnung) und Web-/Sync-Verhalten (WebCart-Sortiment, Exchange-Sync, Supremo).
|
||||||
|
- SEKUNDÄR/KONTEXT-lastig sind SyRS-050 (nur Konfigurationsschalter) und SwRS-156 (nur README + Klassenexistenz) - beide korrekt als HYPOTHESE geführt.
|
||||||
|
|
||||||
|
**Hypothesenquote:** 6 von 241 (2,5 %). Der Wert liegt bewusst über null: Bei einer Codebasis dieser Größe (u. a. 11.441 Zeilen allein in ReceiptBL.cs, 1558 DB-Tabellen) bleiben nach einem Lauf zwangsläufig offene Kernfragen; die sechs Hypothesen benennen sie explizit.
|
||||||
|
|
||||||
|
**Erkenntnisse für eine Folge-Iteration (Nachschlag empfohlen):**
|
||||||
|
1. Mahnwesen lokalisieren und als belegte Anforderungen ausarbeiten (SyRS-050) - abrechnungskritisch.
|
||||||
|
2. DownPaymentBL, SEPA-Erzeugung und ReceiptItemPriceBL/ReceiptPriceHelperBL (Preisberechnung inkl. Rabatt-/Staffellogik) vertiefen - die Preisermittlungsformeln selbst wurden nicht spezifiziert.
|
||||||
|
3. Das alte Belegmodell Sales/CustomerAssets systematisch gegen Sales/Receipts differenzieren (welche Masken nutzen noch das Altmodell?).
|
||||||
|
4. WebServices-BL (464 Dateien) und Centron.Controllers-Endpunkte vollständig katalogisieren (API-Oberfläche als eigenes Spezifikationskapitel).
|
||||||
|
5. DB-Schema systematisch auswerten (Constraints/Trigger je Kerntabelle); in diesem Lauf nur punktuell genutzt (Tabelle Kunden).
|
||||||
|
6. WPF-Masken (Views/Wizards) und Nexus-Seiten fachlich durchgehen, um UI-nahe Regeln (Pflichtfelder, Sichtbarkeiten) zu heben - bisher überwiegend BL-getrieben analysiert.
|
||||||
|
7. Statistiken/Reports einzeln inventarisieren (Reportvorlagenbestand ist Migrationsaufwandstreiber).
|
||||||
|
|
||||||
|
**Methodische Anmerkungen:**
|
||||||
|
- Alle Anforderungen wurden aus statischer Analyse gewonnen; keine Ausführung, keine externen Werkzeuge.
|
||||||
|
- Die Change-Historie (Git) wurde nicht ausgewertet, da im Arbeitsverzeichnis keine Commit-Metadaten als Dateien vorlagen (nur der Code-Snapshot); Schritt 2 der Methodenkette ist insoweit teilweise erfüllt (Projektartefakte docs/, README, CentronRights.md wurden genutzt).
|
||||||
|
|
||||||
+47
@@ -0,0 +1,47 @@
|
|||||||
|
# Glossar – c-entron ERP-Suite
|
||||||
|
|
||||||
|
Domänenbegriffe, wie sie in den Anforderungen verwendet werden. Technische Bezeichner (Klassen,
|
||||||
|
Tabellen) in Originalschreibweise.
|
||||||
|
|
||||||
|
| Begriff | Bedeutung |
|
||||||
|
|---|---|
|
||||||
|
| Abholliste / Abholschein (PickupList) | Beleg über die Rücknahme von Ware vom Kunden; bucht Bestand zu. |
|
||||||
|
| AppUser | Internes Benutzerkonto (Tabelle `Sichbenu`); mit Mitarbeiter (Employee) verknüpft. |
|
||||||
|
| Asset (CustomerAsset) | Historischer Oberbegriff des alten Belegmodells („Vorgang") unter Sales/CustomerAssets; zugleich Begriff für beim Kunden befindliche Geräte („Stammblätter"). |
|
||||||
|
| AssetCondition | Stammdatensatz für Zahlungs-/Lieferkonditionen; steuert u. a. Kassenbuchwirkung (`ChangesCashBook`) und automatisches Schließen von Belegen. |
|
||||||
|
| AutomaticFactura | Automatische Vertragsfakturierung inkl. Zählerstands- und Sammelrechnungslogik. |
|
||||||
|
| Barbeleg / IsCashAsset | Beleg mit Barzahlung; eigener Nummernkreis (CashInvoice/CashOffer) und Kassenbuchbindung. |
|
||||||
|
| Belegkette | Zulässige Weiterführungspfade zwischen Belegarten (Angebot → Auftrag → Lieferschein → Rechnung → Gutschrift; Vertrag → Rechnung). |
|
||||||
|
| BranchOrigin | Regel, aus welcher Person (Ersteller oder Vertriebsmitarbeiter) die Filiale eines neuen Belegs abgeleitet wird. |
|
||||||
|
| c-entron Nexus | Blazor-basierter Webclient (interne Web-Oberfläche und Kundenportal). |
|
||||||
|
| CashBookRecord | Kassen-Belegart je Steuersatz/Filiale mit Sachkonto und Steuerschlüssel; Voraussetzung jeder Kassenbuchbuchung. |
|
||||||
|
| CentronObjectKindNumeric | Systemweiter numerischer Katalog der Objektarten (Belegarten, Tickets, Konten …). |
|
||||||
|
| Concurrency-Control-Guid | Token je Beleg zur Erkennung konkurrierender Änderungen bei Einzelfeld-Updates. |
|
||||||
|
| Dispatcher | Ausgezeichneter Mitarbeiter für die Einsatz-/Ticketverteilung (genau einer). |
|
||||||
|
| Distributor | Großhändler/Lieferant der IT-Branche (ALSO, Alltron, EGIS, Komsa, Herweck, ITscope …). |
|
||||||
|
| EDI | Elektronischer Datenaustausch mit Distributoren (Bestellungen, Auftragsbestätigungen) in herstellerspezifischen Formaten. |
|
||||||
|
| Eskalation | Dreistufige Fristenüberwachung überfälliger Vorgänge mit Zeitstempeln `Eskalation1Am`–`Eskalation3Am`. |
|
||||||
|
| Firmengruppe (CompanyGroup) | Konzernverbund von Kundenkonten; kann Belegeinstellungen der Gruppe vererben (`UseSettingsFromCompanyGroupForReceipts`). |
|
||||||
|
| Helpdesk / Ticket | Supportvorgang mit Status, Verantwortlichem, Fälligkeit, Timern und Eskalation. |
|
||||||
|
| Helpdesk-Timer | Am Ticket erfasste Arbeitszeit; Grundlage der Leistungsabrechnung (Timer-Billing). |
|
||||||
|
| I3D | Systemweiter Primärschlüssel der Geschäftsobjekte (zentral vergeben, keine Identity-Spalten). |
|
||||||
|
| Lieferschein (DeliveryList) | Bestandswirksamer Auslieferungsbeleg; bucht Bestand ab. |
|
||||||
|
| Mandant (Mandator) | Rechtlich eigenständige Firma innerhalb einer Installation; Filialen (Branch) sind Mandanten zugeordnet. |
|
||||||
|
| Mindestpreis (MinPrice) | Artikeluntergrenze; Unterschreitung nur per Recht bzw. Zweitanmeldung (Vier-Augen-Prinzip). |
|
||||||
|
| MSP / MSP-Collector | Managed-Service-Provider-Funktionen; Collector sammelt Verbrauchs-/Gerätedaten für Auswertung und Abrechnung. |
|
||||||
|
| Nummernkreis (NumberGroup) | Fortlaufender Nummernvorrat je Belegart, Mandant und Filiale mit Fallback-Kaskade. |
|
||||||
|
| Receipt | Beleg im neueren Belegmodell (Sales/Receipts); ersetzt schrittweise das CustomerAssets-Modell. |
|
||||||
|
| Rechtegruppe (AppGroup) | Bündel von Rechten (Tabelle `Sichtrus`), Benutzern über `Sichmemb` zugeordnet. |
|
||||||
|
| Restriktives Recht | Recht, das die Sicht einschränkt statt erweitert (z. B. „Tickets anzeigen – nur eigene"). |
|
||||||
|
| RMA | Reklamationsvorgang: Rücknahme vom Kunden (SendBack) und Weiterleitung an den Lieferanten (SendForth). |
|
||||||
|
| Sammelrechnung (Collective Invoice) | Eine Rechnung über mehrere Verträge/Leistungen eines Kunden oder Konzerns. |
|
||||||
|
| SelfCare | Web-Formulare, über die Endkunden Anfragen einreichen. |
|
||||||
|
| Sonderpreis | Kundenindividueller Artikelpreis; laut Doku Basis des WebCart-Sortiments. |
|
||||||
|
| Stammblatt | Historische Bezeichnung für Gerätedatensätze beim Kunden (v. a. Drucker); Konsolidierungskandidat zum Asset-Konzept. |
|
||||||
|
| Ticket (Anmeldung) | Sitzungsnachweis nach erfolgreicher Authentifizierung (nicht zu verwechseln mit Helpdesk-Ticket). |
|
||||||
|
| Timer-Billing | Überführung erfasster Ticketzeiten in Abrechnungsbelege unter Vertrags-/Kontingentbeachtung. |
|
||||||
|
| Vertrag (ReceiptContract) | Wiederkehrend abzurechnender Beleg mit Laufzeit, Kündigung, Verlängerung und Abrechnungsintervall. |
|
||||||
|
| Web-Account | Externer Kundenzugang (Portal/Shop) mit eigenem Rechtemodell (`WebAccountsRights`). |
|
||||||
|
| WebCart | Shop-Bereich des Kundenportals im Nexus. |
|
||||||
|
| Zählerstand (Counter) | Nutzungswert je Gerät/Vertrag (z. B. Druckseiten) als Abrechnungsgrundlage. |
|
||||||
|
| ZUGFeRD / Factur-X | Hybrides E-Rechnungsformat (PDF mit eingebettetem XML), hier in Version 2.1 Extended. |
|
||||||
+23
@@ -0,0 +1,23 @@
|
|||||||
|
# Hypothesen – c-entron ERP-Suite
|
||||||
|
|
||||||
|
Diese Datei enthält **genau die Anforderungen mit `[HYPOTHESE]`-Markierung** aus StRS/SyRS/SwRS
|
||||||
|
(deckungsgleich mit den Inline-Markierungen, keine zusätzlichen freien Fragen). Offene Punkte ohne
|
||||||
|
zugehörige Anforderung stehen in der Selbstbewertung des Analyseberichts.
|
||||||
|
|
||||||
|
Stand: 6 Hypothesen bei 241 Anforderungen (2,5 %).
|
||||||
|
|
||||||
|
| ID | Titel | Offene Frage (fehlende Information zur Bestätigung) |
|
||||||
|
|---|---|---|
|
||||||
|
| SyRS-050 | Mahnwesen mit drei Mahnstufen und Belegsperre | Wo liegt die durchsetzende Mahnlauf-Logik (Stufenermittlung, Mahnschreiben, Sperrprüfung)? Nur Konfigurationsschalter (DunningLevel1-3Text, CustomerAssetsLockedAfterDunningLevel) wurden gefunden. |
|
||||||
|
| SwRS-154 | Verrechnung von Anzahlungen in der Schlussrechnung | Wie verrechnet DownPaymentBL geleistete Anzahlungen konkret in der Schlussrechnung (Positionslogik, Steuerbehandlung)? |
|
||||||
|
| SwRS-155 | SEPA-Lastschrifteinzug aus Rechnungen | Wo wird die SEPA-XML-Einzugsdatei erzeugt (vermutlich Gateway/OnlineBanking)? Mandatsbindung und Statusfeld `directDebitCreated` sind belegt, die Dateierzeugung nicht. |
|
||||||
|
| SwRS-156 | Webshop-Sortiment aus Kunden-Sonderpreisen | Welche Codestelle im Nexus-WebCart schränkt das Sortiment auf die Sonderpreise des Kunden ein? Bisher nur README-Aussage und Existenz von CustomerSpecialArticleBL. |
|
||||||
|
| SwRS-157 | Bidirektionale Exchange-Terminsynchronisation | Synchronisationsrichtung, Konfliktauflösung und Auslöser der Kalendersynchronisation (EWS vs. Graph) sind nicht aus dem Code verifiziert. |
|
||||||
|
| SwRS-158 | Fernwartungsstart (Supremo) aus dem Arbeitsplatz | Wie wird die Supremo-Sitzung aufgebaut (Parameter, Zielgerätezuordnung)? Nur Komponenten (MyDay/Supremo.cs, assemblies/remote-desktop) belegt. |
|
||||||
|
|
||||||
|
## Hinweis zur risikobasierten Priorisierung
|
||||||
|
|
||||||
|
SyRS-050, SwRS-154 und SwRS-155 betreffen Abrechnung/Fakturierung. SwRS-154/155 besitzen je einen
|
||||||
|
`PRIMÄR`-Beleg für den belegten Teilaspekt; die dennoch offene Kernregel ist der Grund für die
|
||||||
|
Hypothesen-Kennzeichnung. SyRS-050 besitzt keinen `PRIMÄR`-Beleg und ist deshalb zwingend als
|
||||||
|
`[HYPOTHESE]` geführt (regelkonform).
|
||||||
+669
@@ -0,0 +1,669 @@
|
|||||||
|
# StRS – Stakeholder Requirements Specification
|
||||||
|
**System:** c-entron ERP-Suite | **Quelle:** Statische Codeanalyse | **Lauf:** 2026-08-27
|
||||||
|
|
||||||
|
Fachliche Anforderungen aus Stakeholdersicht (Akteure, Geschäftsziele). Grundlage: aus der Codebasis rekonstruierte Fachfunktionen.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Zielgruppe des Systems (aus der Codebasis rekonstruiert):** IT-Systemhäuser und Managed-Service-Provider im DACH-Raum (deutschsprachige Fachbegriffe, DATEV-/SEPA-/ZUGFeRD-Bezüge, Distributoren-EDI ALSO/Alltron/EGIS/Komsa/Herweck, Schweiz-Spezifika in Receipts/Switzerland).
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-001
|
||||||
|
Titel: Zentrale Geschäftspartnerverwaltung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Vertrieb, Einkauf, Verwaltung
|
||||||
|
Vorbedingung: -
|
||||||
|
Fakt: Die Codebasis führt Konten mit Rollen Kunde/Lieferant, Adressen, Ansprechpartnern, Klassifikationen, Firmengruppen, Bankverbindungen und Länder-/Währungsbezug (Accounts, Sales/Customers, CountryArea, Accounting).
|
||||||
|
Aussage: Das Unternehmen soll alle Geschäftspartner (Kunden, Lieferanten, Interessenten) einheitlich mit Adressen, Ansprechpartnern, Konditionen und Bankdaten verwalten können.
|
||||||
|
Ergebnis: Ein Partnerstamm als Basis aller Prozesse.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs (SaveAccount, Kontotypen) - Begründung: implementiert die Partnerverwaltung.
|
||||||
|
Prüfidee: Partner als Kunde und Lieferant führen; alle Belegprozesse referenzieren denselben Stamm.
|
||||||
|
Tracelinks: SyRS-020, SyRS-024
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Fundament.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-002
|
||||||
|
Titel: Durchgängige Angebots- und Auftragsabwicklung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Vertrieb
|
||||||
|
Vorbedingung: Kunde existiert.
|
||||||
|
Fakt: Belegkette Angebot → Auftrag → Lieferschein → Rechnung (→ Gutschrift) mit Weiterführung, Versionierung, Sperren und Vorlagen ist implementiert (Sales/Receipts).
|
||||||
|
Aussage: Der Vertrieb soll Verkaufsvorgänge vom Angebot bis zur Rechnung ohne Doppelerfassung abwickeln können; jeder Schritt bleibt nachvollziehbar.
|
||||||
|
Ergebnis: Lückenlose, versionierte Belegkette.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (ForwardReceipt, CreateNewVersion) - Begründung: implementiert die Kette.
|
||||||
|
Prüfidee: Kompletten Durchlauf Angebot→Rechnung ohne Neuerfassung der Positionen durchführen.
|
||||||
|
Tracelinks: SyRS-011, SyRS-015, SyRS-016
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Kernprozess.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-003
|
||||||
|
Titel: Korrekte und geschützte Fakturierung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Vertrieb, Buchhaltung, Geschäftsführung
|
||||||
|
Vorbedingung: Leistungen/Lieferungen sind erbracht.
|
||||||
|
Fakt: Rechnungen, Barrechnungen, interne Rechnungen und Gutschriften haben eigene Nummernkreise; Mindestpreise sind geschützt (Vier-Augen-Prinzip); Kassenbuchbuchungen entstehen automatisch (Receipts/Invoices, CashBooks, NumberGroups).
|
||||||
|
Aussage: Das Unternehmen soll Rechnungen und Gutschriften mit eindeutigen Nummern, geschützten Preisuntergrenzen und automatischer Kassenanbindung erstellen können.
|
||||||
|
Ergebnis: Revisionssichere Fakturierung ohne Margenverlust.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs (Nummernkreise), ReceiptBL.CheckArticleMinPrices - Begründung: implementieren die Schutzregeln.
|
||||||
|
Prüfidee: Rechnung unter Mindestpreis ohne Freigabe; erwartet: verhindert.
|
||||||
|
Tracelinks: SyRS-012, SyRS-014, SyRS-042, SyRS-050
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Umsatz- und Compliance-Kern.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-004
|
||||||
|
Titel: Vertragsgeschäft mit wiederkehrender Abrechnung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Geschäftsführung, Vertragsverwaltung, Buchhaltung
|
||||||
|
Vorbedingung: Serviceverträge sind abgeschlossen.
|
||||||
|
Fakt: Verträge mit Laufzeiten, Verlängerung, Intervallen, Zählerständen und automatischer Fakturierung inkl. Sammelrechnung sind implementiert (CustomerAssets/Contracts, AutomaticFactura).
|
||||||
|
Aussage: Das Unternehmen soll wiederkehrende Umsätze (Wartung, Miete, Managed Services, Seitenpreise) automatisch, vollständig und periodengerecht abrechnen können.
|
||||||
|
Ergebnis: Planbare, automatisierte Vertragsumsätze.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, AutomaticFactura/AutomaticFacturaBL.cs - Begründung: implementieren das Vertragsgeschäft.
|
||||||
|
Prüfidee: Jahresvertrag mit Zähler; erwartet: 12 korrekte Perioden, keine Lücke/Doppel.
|
||||||
|
Tracelinks: SyRS-037, SyRS-038, SyRS-039
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - strategischer Umsatzträger.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-005
|
||||||
|
Titel: Professioneller Kundensupport (Helpdesk)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Support, Support-Leitung, Endkunde
|
||||||
|
Vorbedingung: Kunde meldet Anliegen.
|
||||||
|
Fakt: Ticketsystem mit Status, Kategorien, Prioritäten, Zeiterfassung, Eskalation, Abschlussbenachrichtigung, Ticket-Projekten und Web-Zugriff ist implementiert (Sales/Support, NexusTicketViews).
|
||||||
|
Aussage: Der Support soll Kundenanliegen als Tickets mit Verantwortlichen, Fälligkeiten und Eskalationen bearbeiten; Kunden sollen ihre Tickets online verfolgen können.
|
||||||
|
Ergebnis: Nachvollziehbarer, SLA-fähiger Supportprozess.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Escalation/EscalationBL.cs - Begründung: implementieren den Prozess.
|
||||||
|
Prüfidee: Ticket mit SLA-Verletzung; erwartet: dreistufige Eskalation.
|
||||||
|
Tracelinks: SyRS-040, SyRS-041, SyRS-036
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Kernprozess des Systemhauses.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-006
|
||||||
|
Titel: Lückenlose Leistungserfassung und -verrechnung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Techniker, Buchhaltung
|
||||||
|
Vorbedingung: Leistungen werden erbracht.
|
||||||
|
Fakt: Ticket-Timer mit Abrechnungsstatus, Stundenzuschlagssätzen und Belegerzeugung sind implementiert (HelpdeskTimer*, TimerBilling, HourlySurchargeRates).
|
||||||
|
Aussage: Erbrachte Arbeitszeiten sollen vollständig erfasst und - unter Berücksichtigung von Verträgen und Zuschlägen - genau einmal verrechnet werden.
|
||||||
|
Ergebnis: Kein Leistungsverlust zwischen Erbringung und Rechnung.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs - Begründung: implementiert die Verrechnung.
|
||||||
|
Prüfidee: Erfasste Zeit doppelt abrechnen; erwartet: verhindert.
|
||||||
|
Tracelinks: SyRS-039
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - direkter Umsatzhebel.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-007
|
||||||
|
Titel: Effizienter Einkauf mit Distributorenanbindung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Einkauf
|
||||||
|
Vorbedingung: Bedarf besteht.
|
||||||
|
Fakt: Bestellvorschläge, Lieferantenbestellungen, EDI-Übertragung an Distributoren und externe Artikel-/Preissuche (ITscope, EGIS, COP, Icecat) sind implementiert.
|
||||||
|
Aussage: Der Einkauf soll Bedarfe automatisch erkennen, Preise/Verfügbarkeiten der Distributoren direkt einsehen und Bestellungen elektronisch übertragen können.
|
||||||
|
Ergebnis: Schneller, fehlerarmer Einkaufsprozess.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs, EDI/EDIDispatcherBL.cs - Begründung: implementieren den Prozess.
|
||||||
|
Prüfidee: Unterschreitung Mindestbestand bis EDI-Bestellung durchspielen.
|
||||||
|
Tracelinks: SyRS-027; SwRS-091, SwRS-148
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Kernprozess des IT-Handels.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-008
|
||||||
|
Titel: Verlässliche Artikel- und Lagerführung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Lager, Einkauf, Vertrieb
|
||||||
|
Vorbedingung: Artikelstamm existiert.
|
||||||
|
Fakt: Artikelstamm mit EAN, Preisen, Seriennummern-/Barcodeverfolgung, Mehrlager, Umbuchungslog, Inventur und belegbasierter Bestandsführung ist implementiert (Warehousing, Logistics, Storage).
|
||||||
|
Aussage: Bestände sollen jederzeit korrekt, seriennummerngenau und je Lagerort nachvollziehbar sein; jede Veränderung hat einen Belegbezug.
|
||||||
|
Ergebnis: Inventurfähige Bestandsführung.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs, Warehousing/ArticleBL.cs - Begründung: implementieren die Bestandsführung.
|
||||||
|
Prüfidee: Bestandsdifferenz erzeugen; erwartet: über Belege/Umbuchungslog aufklärbar.
|
||||||
|
Tracelinks: SyRS-013, SyRS-034; SwRS-112
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Kernprozess.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-009
|
||||||
|
Titel: Nahtlose Finanzprozesse (Zahlungen, FiBu, Mahnwesen)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung, Steuerberater
|
||||||
|
Vorbedingung: Belege sind fakturiert.
|
||||||
|
Fakt: Onlinebanking-Zahlungsabgleich, Zahlungsprotokolle, DATEV-Export mit Doppelübergabeschutz und Kassenbuch sind implementiert; Mahnwesen ist konfigurierbar angelegt.
|
||||||
|
Aussage: Zahlungseingänge sollen automatisch zugeordnet, offene Posten gemahnt und alle Buchungsdaten ohne Doppelerfassung an die Finanzbuchhaltung (DATEV) übergeben werden.
|
||||||
|
Ergebnis: Geschlossener Order-to-Cash-Kreislauf.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs, DataExchange/BookKeeping/BookKeepingExportBL.cs - Begründung: implementieren die Finanzprozesse.
|
||||||
|
Prüfidee: Zahlungseingang bis DATEV-Export durchspielen; keine manuelle Doppelerfassung nötig.
|
||||||
|
Tracelinks: SyRS-021, SyRS-032, SyRS-042, SyRS-050
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Pflichtprozess.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-010
|
||||||
|
Titel: Elektronischer Belegaustausch und E-Rechnung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung, Kunden, Behörden, Distributoren
|
||||||
|
Vorbedingung: Belege werden ausgetauscht.
|
||||||
|
Fakt: ZUGFeRD/Factur-X, XRechnung-Schnittstellen, ebInterface (AT) und Distributoren-EDI sind implementiert.
|
||||||
|
Aussage: Das Unternehmen soll Belege elektronisch in den gesetzlich bzw. vom Partner geforderten Formaten senden und empfangen können.
|
||||||
|
Ergebnis: E-Rechnungs- und EDI-Konformität.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/ReportEngine/CustomPdfGenerators/CustomZugferdPdfGenerator.cs; Centron.Gateway/ZUGFeRD21_Extended - Begründung: implementieren die Formate.
|
||||||
|
Prüfidee: ZUGFeRD-Rechnung gegen Validator prüfen.
|
||||||
|
Tracelinks: SyRS-043, SyRS-027
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - gesetzlich getrieben.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-011
|
||||||
|
Titel: Integrierte Versandabwicklung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Lager/Versand
|
||||||
|
Vorbedingung: Lieferung ist kommissioniert.
|
||||||
|
Fakt: GLS- und Shipcloud-Anbindungen erzeugen Sendungen aus dem System (src/apis).
|
||||||
|
Aussage: Versandlabel und Tracking sollen direkt aus dem Lieferbeleg erzeugt werden.
|
||||||
|
Ergebnis: Kein Medienbruch im Versand.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/apis/Centron.Api.Gls/CentronGlsLogic.cs - Begründung: implementiert den Versand.
|
||||||
|
Prüfidee: Label aus Lieferschein erzeugen.
|
||||||
|
Tracelinks: SyRS-044
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Logistikstandard.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-012
|
||||||
|
Titel: Feingranulare Berechtigungssteuerung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Sicherheit
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Geschäftsführung, Administrator, alle Benutzer
|
||||||
|
Vorbedingung: -
|
||||||
|
Fakt: Gruppenbasiertes Rechtesystem mit hunderten Einzelrechten, restriktiven Rechten (nur eigene/Filiale), Rollenvorlagen und Rechteprotokoll ist implementiert.
|
||||||
|
Aussage: Jede Funktion und jede Datensicht soll einzeln berechtigt werden können; Standardrollen erleichtern die Einführung; Rechteänderungen sind nachvollziehbar.
|
||||||
|
Ergebnis: Need-to-know-Prinzip im gesamten System.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs - Begründung: implementiert das Rechtesystem.
|
||||||
|
Prüfidee: Stichprobe: Funktion ohne Recht aufrufen; erwartet: verweigert.
|
||||||
|
Tracelinks: SyRS-001, SyRS-002, SyRS-006, SyRS-007, SyRS-008
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Sicherheitsfundament.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-013
|
||||||
|
Titel: Sichere Anmeldung und API-Zugänge
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Sicherheit
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Alle Benutzer, externe Systeme
|
||||||
|
Vorbedingung: -
|
||||||
|
Fakt: Mehrere Authentifizierungsverfahren, Zwei-Faktor-Optionen, Sitzungstickets, gehashte API-Tokens und deklarativ geschützte REST-Endpunkte sind implementiert.
|
||||||
|
Aussage: Zugriffe von Menschen und Systemen sollen stark authentifiziert, zeitlich begrenzt und protokolliert sein.
|
||||||
|
Ergebnis: Kontrollierter Zugang über alle Kanäle.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, AccessTokens/AccessTokenBL.cs - Begründung: implementieren die Zugriffssicherung.
|
||||||
|
Prüfidee: Penetrationstest der Anmeldewege.
|
||||||
|
Tracelinks: SyRS-003, SyRS-004, SyRS-005, SyRS-017, SyRS-046
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - im Zielsystem modernisieren (Passworthashing!).
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-014
|
||||||
|
Titel: Lizenz- und Modulsteuerung des Produkts
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Hersteller, Kunde (Systemhaus)
|
||||||
|
Vorbedingung: -
|
||||||
|
Fakt: Signierte Lizenzdateien, Seat-Prüfung bei Anmeldung, Feature-Gates (ModuleFeatures) und Modulkatalog sind implementiert.
|
||||||
|
Aussage: Der Funktionsumfang je Installation soll sich aus der erworbenen Lizenz ergeben; Überbelegung von Arbeitsplätzen wird verhindert.
|
||||||
|
Ergebnis: Durchgesetztes Lizenzmodell.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs - Begründung: implementiert die Lizenzsteuerung.
|
||||||
|
Prüfidee: Anmeldung über Seat-Limit; erwartet: abgelehnt.
|
||||||
|
Tracelinks: SyRS-003; SwRS-009, SwRS-139
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - als SaaS-Abomodell neu umsetzen.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-015
|
||||||
|
Titel: Professioneller Belegdruck und Berichte
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Alle Fachbereiche, Kunden (Empfänger)
|
||||||
|
Vorbedingung: Daten vorhanden.
|
||||||
|
Fakt: FastReport-basierte Report-Engine mit Vorlagen, PDF-Export, Belegarchivierung und zentraler Reportverteilung ist implementiert.
|
||||||
|
Aussage: Alle Belege und Berichte sollen in anpassbarem Firmenlayout gedruckt, als PDF archiviert und zentral aktualisiert werden können.
|
||||||
|
Ergebnis: Einheitliches Schriftbild, archivierte Belege.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/ReportEngine/FastReportHelper.cs; ReceiptBL.CreateFullReportForReceipt - Begründung: implementieren den Druck.
|
||||||
|
Prüfidee: Vorlage ändern; alle Folgedrucke nutzen neue Vorlage.
|
||||||
|
Tracelinks: SyRS-025
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Pflicht.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-016
|
||||||
|
Titel: Betriebswirtschaftliche Transparenz
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Geschäftsführung, Controlling
|
||||||
|
Vorbedingung: Bewegungsdaten vorhanden.
|
||||||
|
Fakt: Statistiken zu Umsatz, offenen Posten, Verträgen, Auslastung und MSP-Verbräuchen sind implementiert (Statistics).
|
||||||
|
Aussage: Die Geschäftsführung soll Umsätze, offene Posten, Vertragsbestand und Auslastung ohne Zusatzwerkzeuge auswerten können.
|
||||||
|
Ergebnis: Steuerungsfähige Kennzahlen.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Statistics/Accounts/RevenueStatisticBL.cs - Begründung: implementiert Auswertungen.
|
||||||
|
Prüfidee: Umsatzstatistik gegen Belegsumme abstimmen.
|
||||||
|
Tracelinks: SyRS-021; SwRS-135
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Führungsinstrument.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-017
|
||||||
|
Titel: Integrierte Kommunikation (E-Mail, Telefon, Chat)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Alle Mitarbeiter
|
||||||
|
Vorbedingung: Kommunikationskanäle konfiguriert.
|
||||||
|
Fakt: Exchange-Mail, Signaturen, Mail-Scanner, TAPI-Telefonie mit Anruferkennung und interner Chat sind implementiert.
|
||||||
|
Aussage: Kundenkommunikation soll im Vorgangskontext stattfinden: Mails und Anrufe werden automatisch Kunden/Tickets zugeordnet.
|
||||||
|
Ergebnis: Vollständige Kommunikationshistorie je Vorgang.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Mail/*, Tapi/PhoneCallBL.cs - Begründung: implementieren die Kanäle.
|
||||||
|
Prüfidee: Eingehende Mail/Anruf; erwartet: Kontextzuordnung.
|
||||||
|
Tracelinks: SyRS-035, SyRS-036, SyRS-030
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Effizienzkern.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-018
|
||||||
|
Titel: Persönliche Arbeitsorganisation
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Alle Mitarbeiter
|
||||||
|
Vorbedingung: -
|
||||||
|
Fakt: Kalender, ToDos, MyDay, Dashboards, Benachrichtigungen und Terminanfragen sind implementiert.
|
||||||
|
Aussage: Jeder Mitarbeiter soll seinen Arbeitsvorrat (Termine, Aufgaben, Benachrichtigungen) an einem Ort sehen und steuern können.
|
||||||
|
Ergebnis: Weniger Übersehen von Fälligkeiten.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/MyDay/MyDayBL.cs - Begründung: implementiert die Tagesübersicht.
|
||||||
|
Prüfidee: Fällige Objekte erscheinen in MyDay.
|
||||||
|
Tracelinks: SyRS-029
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Produktivität.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-019
|
||||||
|
Titel: Online-Self-Service für Endkunden
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Endkunde des Systemhauses
|
||||||
|
Vorbedingung: Web-Account existiert.
|
||||||
|
Fakt: Kundenportal mit Shop (Sonderpreise), Ticketeinsicht, Verträgen, Formularen, Dokumenten und Aktionslinks ist implementiert (Nexus WebCart, SelfCare, WebLinks).
|
||||||
|
Aussage: Endkunden sollen Bestellungen, Tickets, Verträge und Dokumente online einsehen und auslösen können - beschränkt auf die eigenen Daten.
|
||||||
|
Ergebnis: Entlastung des Supports, moderner Kundenzugang.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/nexus/CentronNexus/WebCart/*.razor - Begründung: implementiert das Portal.
|
||||||
|
Prüfidee: Web-Account sieht nur eigene Tickets/Verträge.
|
||||||
|
Tracelinks: SyRS-045, SyRS-002
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Zielbild SaaS.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-020
|
||||||
|
Titel: Dokumentenverwaltung mit digitaler Unterschrift
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Alle Fachbereiche, Kunden
|
||||||
|
Vorbedingung: -
|
||||||
|
Fakt: Objektbezogene Verzeichnisse, PDF-Signatur, Online-Bestätigung von AVV/SEPA und Beleg-Signierprozess sind implementiert.
|
||||||
|
Aussage: Dokumente sollen objektbezogen abgelegt und Verträge/Belege digital unterschrieben werden können.
|
||||||
|
Ergebnis: Papierlose, nachweisbare Dokumentprozesse.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/FileManagement/DirectoryReferenceBL.cs, Security/PdfSigningBL.cs - Begründung: implementieren Ablage und Signatur.
|
||||||
|
Prüfidee: AVV online bestätigen; erwartet: signiertes Dokument am Kunden.
|
||||||
|
Tracelinks: SyRS-026, SyRS-022; SwRS-031, SwRS-107
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Digitalisierungskern.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-021
|
||||||
|
Titel: Offenheit für Drittsysteme (Konnektoren)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Schnittstelle
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Systemhaus, Drittsysteme
|
||||||
|
Vorbedingung: Drittsystem im Einsatz.
|
||||||
|
Fakt: Konnektoren zu DocBee, docuFORM, Riverbird, CPra, Shopsystemen, TradePool sowie generische WebHooks und externe Objektreferenzen sind implementiert.
|
||||||
|
Aussage: Das System soll gängige Branchenwerkzeuge anbinden und Objekte beidseitig referenzieren können.
|
||||||
|
Ergebnis: Integrierbare Systemlandschaft.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs, DataExchange/Connectors/* - Begründung: implementieren die Offenheit.
|
||||||
|
Prüfidee: Fremd-ID an Objekt koppeln und rückwärts auflösen.
|
||||||
|
Tracelinks: SyRS-027; SwRS-083
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Ökosystem entscheidend.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-022
|
||||||
|
Titel: Überblick über Kundengeräte und -infrastruktur
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Service, Vertrieb
|
||||||
|
Vorbedingung: Geräte beim Kunden im Einsatz.
|
||||||
|
Fakt: Kundengeräte werden in mehreren Modulen geführt (AccountDevices, CustomerAssets/Stammblätter, DocuBoard-Assets) inkl. Logs, Vertragsbezug und Outlook-Suche.
|
||||||
|
Aussage: Der Servicebetrieb soll jederzeit wissen, welche Geräte mit welchen Verträgen beim Kunden stehen.
|
||||||
|
Ergebnis: Asset-Transparenz für Service und Abrechnung.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Devices/AccountDeviceBL.cs - Begründung: implementiert Geräteverwaltung.
|
||||||
|
Prüfidee: Gerät über alle Sichten konsistent auffinden.
|
||||||
|
Tracelinks: SyRS-028
|
||||||
|
Konsolidierung: Kandidat: drei Gerätedatenhaltungen (siehe SyRS-028) - im Zielsystem ein Asset-Konzept
|
||||||
|
Übernahmewürdigkeit: übernehmen - mit Konsolidierungsauflage.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-023
|
||||||
|
Titel: Geordnete Reklamationsabwicklung (RMA)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Service, Kunde, Lieferant
|
||||||
|
Vorbedingung: Defektes Gerät wird gemeldet.
|
||||||
|
Fakt: RMA-Prozess mit Kundenrücknahme, Lieferantenweiterleitung, Versandarten und Artikelhistorie ist implementiert.
|
||||||
|
Aussage: Reklamationen sollen vom Kundeneingang bis zur Lieferantenabwicklung verfolgt werden.
|
||||||
|
Ergebnis: Kein Reklamationsverlust; Garantienachweis.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs - Begründung: implementiert den Prozess.
|
||||||
|
Prüfidee: RMA-Kette Kunde→Lieferant→Rückläufer verfolgen.
|
||||||
|
Tracelinks: SyRS-028; SwRS-059
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Handelskern.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-024
|
||||||
|
Titel: Auftragsbezogene Fertigung (Assemblierung)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Produktion/Technik
|
||||||
|
Vorbedingung: Fertigungsauftrag liegt vor.
|
||||||
|
Fakt: Fertigungsaufträge mit Positionen und Protokoll sowie ein Web-Produktionsmanagement sind implementiert (Production, Nexus/ProductionOrderManagement); Rechte für Stücklisten/Arbeitspläne existieren.
|
||||||
|
Aussage: Das Unternehmen soll kundenbezogene Fertigung (z. B. PC-/Server-Assemblierung) mit dokumentierten Arbeitsschritten abwickeln können.
|
||||||
|
Ergebnis: Nachvollziehbare Fertigung mit Seriennummernbezug.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs - Begründung: implementiert die Fertigung.
|
||||||
|
Prüfidee: Fertigungsauftrag mit Protokollschritten abschließen.
|
||||||
|
Tracelinks: SyRS-013; SwRS-089
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - sofern Geschäftsfeld bestätigt.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-025
|
||||||
|
Titel: Projekt- und Chancenverfolgung (CRM)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Vertrieb, Projektleitung
|
||||||
|
Vorbedingung: -
|
||||||
|
Fakt: Projekte, CRM-Projekte, Ticket-Projekte, Produktmatrix, Angebotsklassifikationen (Wahrscheinlichkeit/Produktgruppe) und Aktivitäten sind implementiert.
|
||||||
|
Aussage: Der Vertrieb soll Verkaufschancen und Projekte mit Wahrscheinlichkeiten und Produktpotenzialen je Kunde verfolgen können.
|
||||||
|
Ergebnis: Gefüllte, bewertbare Pipeline.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Offers/ClassificationProbabilityBL.cs, ProductMatrix/ProductMatrixBL.cs - Begründung: implementieren die Bewertung.
|
||||||
|
Prüfidee: Angebot mit Wahrscheinlichkeit klassifizieren; erscheint in Pipeline-Auswertung.
|
||||||
|
Tracelinks: SyRS-020; SwRS-088, SwRS-090, SwRS-119
|
||||||
|
Konsolidierung: Kandidat: drei Projektbegriffe (Projects, CrmProjects, TicketProjects) zusammenführen
|
||||||
|
Übernahmewürdigkeit: übernehmen - Vertriebssteuerung.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-026
|
||||||
|
Titel: Zielgerichtetes Marketing (Kampagnen, Mailings, Telemarketing)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Marketing, Vertrieb
|
||||||
|
Vorbedingung: Zielgruppen definierbar.
|
||||||
|
Fakt: Kampagnen (Accounts/Campaigns), Serien-Mailings und Telemarketing-Aktionen sind implementiert.
|
||||||
|
Aussage: Das Unternehmen soll Zielgruppen ansprechen können (Mailing, Telefonaktion, Kampagne) und Reaktionen am Kunden dokumentieren.
|
||||||
|
Ergebnis: Messbare Marketingaktionen.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Mailings/MailingDataBL.cs, Sales/Marketing/TelemarketingBL.cs - Begründung: implementieren die Aktionen.
|
||||||
|
Prüfidee: Mailing an Zielgruppe mit Antwortdokumentation.
|
||||||
|
Tracelinks: SyRS-035; SwRS-074, SwRS-103
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Basisumfang genügt ggf.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-027
|
||||||
|
Titel: Schnelles Auffinden aller Informationen
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Alle Benutzer
|
||||||
|
Vorbedingung: -
|
||||||
|
Fakt: Volltextsuche (Lucene) über Konten und Tickets sowie Suche über Zusatzfelder sind implementiert.
|
||||||
|
Aussage: Benutzer sollen Kunden und Vorgänge über eine zentrale Suche in Sekunden finden.
|
||||||
|
Ergebnis: Kurze Suchwege im Tagesgeschäft.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs - Begründung: implementiert die Suche.
|
||||||
|
Prüfidee: Suche nach Ticketinhalt liefert Treffer < definierte Zeit.
|
||||||
|
Tracelinks: SyRS-033
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Nutzererwartung.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-028
|
||||||
|
Titel: Sicherer Umgang mit Kundenzugangsdaten
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Sicherheit
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Techniker, Datenschutz
|
||||||
|
Vorbedingung: Zugangsdaten von Kundensystemen werden benötigt.
|
||||||
|
Fakt: Zwei Passwortverwaltungen mit Zugriffslogs, Siegeln, kundenbezogenen Rechten und Richtlinien sind implementiert.
|
||||||
|
Aussage: Zugangsdaten der Kundensysteme sollen verschlüsselt, feingranular berechtigt und mit lückenlosem Zugriffsnachweis verwaltet werden.
|
||||||
|
Ergebnis: Auditierbarer Passwortzugriff.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/PasswordManagementArea/PasswordManagementBL.cs, PasswordManager/PasswordManagerBL.cs - Begründung: implementieren die Verwaltung.
|
||||||
|
Prüfidee: Passwortzugriff hinterlässt Logeintrag; Siegelbruch sichtbar.
|
||||||
|
Tracelinks: SyRS-017; SwRS-085, SwRS-086, SwRS-026
|
||||||
|
Konsolidierung: Kandidat: zwei Passwortmodule vereinigen
|
||||||
|
Übernahmewürdigkeit: übernehmen - MSP-Vertrauensbasis.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-029
|
||||||
|
Titel: KI-Unterstützung im Tagesgeschäft
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Support, Administration
|
||||||
|
Vorbedingung: KI-Dienst konfiguriert.
|
||||||
|
Fakt: Ticket-Zusammenfassungen, Lösungsvorschläge, Prompt-Verwaltung und Modellanbindung sind implementiert.
|
||||||
|
Aussage: Mitarbeiter sollen KI-Unterstützung (Zusammenfassungen, Vorschläge) direkt im Vorgang erhalten; das Unternehmen kontrolliert Modelle und Prompts.
|
||||||
|
Ergebnis: Zeitersparnis im Support.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/ArtificialIntelligence/ArtificialIntelligenceBL.cs - Begründung: implementiert die KI-Funktionen.
|
||||||
|
Prüfidee: Ticketzusammenfassung erzeugen und fachlich bewerten.
|
||||||
|
Tracelinks: SyRS-019
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Differenzierungsmerkmal.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-030
|
||||||
|
Titel: Datenschutz und Nachvollziehbarkeit (DSGVO, Audit)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Sicherheit
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Datenschutzbeauftragter, Geschäftsführung
|
||||||
|
Vorbedingung: -
|
||||||
|
Fakt: DSGVO-Löschung mit Protokoll, Änderungsmetadaten an allen Objekten, Rechte-/Zugriffs-/Beleglogs und transaktionale Speicherung sind implementiert.
|
||||||
|
Aussage: Das Unternehmen soll Betroffenenrechte (Löschung) erfüllen und jede relevante Änderung einem Verursacher zuordnen können.
|
||||||
|
Ergebnis: DSGVO-Konformität und Auditierbarkeit.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs; DBBaseBL.cs (Änderungsmetadaten) - Begründung: implementieren die Pflichten.
|
||||||
|
Prüfidee: Löschantrag ausführen; Protokoll weist Durchführung nach.
|
||||||
|
Tracelinks: SyRS-022, SyRS-009, SyRS-010
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - gesetzlich.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-031
|
||||||
|
Titel: Automatisierter, wartbarer Systembetrieb
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: nicht-funktional
|
||||||
|
Qualitätsmerkmal: Zuverlässigkeit, Übertragbarkeit
|
||||||
|
Akteur: IT-Betrieb (Systemhaus), Hersteller
|
||||||
|
Vorbedingung: -
|
||||||
|
Fakt: Steuerbare Hintergrunddienste, Wartungsskripte, Container-Deployment, Installer, Testsuiten und Diagnosefunktionen sind implementiert.
|
||||||
|
Aussage: Das System soll automatisiert betrieben, aktualisiert und überwacht werden können, mit reproduzierbaren Deployments.
|
||||||
|
Ergebnis: Geringer Betriebsaufwand, sichere Updates.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/BackgroundServices/BackgroundServiceBL.cs; docker/compose/compose.yaml - Begründung: implementieren den Betrieb.
|
||||||
|
Prüfidee: Update-Durchlauf mit Skriptausführung und Regressionstests.
|
||||||
|
Tracelinks: SyRS-018, SyRS-047, SyRS-048, SyRS-049
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Basis der SaaS-Fähigkeit.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-032
|
||||||
|
Titel: Anpassbarkeit ohne Programmierung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: nicht-funktional
|
||||||
|
Qualitätsmerkmal: Wartbarkeit (Modifizierbarkeit)
|
||||||
|
Akteur: Administrator, Customizing
|
||||||
|
Vorbedingung: -
|
||||||
|
Fakt: Tausende Einstellungen (AppSettingsConst), Custom-Properties, Custom-Tables, konfigurierbare Menüs, Reportvorlagen und Rechtestrukturen sind implementiert.
|
||||||
|
Aussage: Das Systemhaus soll das System an eigene Prozesse anpassen können (Felder, Einstellungen, Menüs, Vorlagen), ohne Individualprogrammierung.
|
||||||
|
Ergebnis: Hohe Passgenauigkeit je Installation.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsBL.cs, Customization/ModuleCustomPropertyBL.cs - Begründung: implementieren die Anpassbarkeit.
|
||||||
|
Prüfidee: Prozessvariante rein per Konfiguration abbilden.
|
||||||
|
Tracelinks: SyRS-023
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Produkt-DNA; Wildwuchs im Zielsystem eindämmen.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-033
|
||||||
|
Titel: Mehrfirmen- und Filialbetrieb
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Unternehmensgruppe, Filialen
|
||||||
|
Vorbedingung: Mehrere Firmen/Standorte.
|
||||||
|
Fakt: Mandanten, Filialen mit eigenen Nummernkreisen, Erlöskonten, filialbezogene Rechte und Belege sind implementiert.
|
||||||
|
Aussage: Unternehmensgruppen sollen mehrere Firmen und Standorte mit getrennten Nummernkreisen und Konten in einer Installation führen können.
|
||||||
|
Ergebnis: Konzernfähigkeit.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.BL/Administration/Company/MandatorBL.cs, BranchBL.cs - Begründung: implementieren die Struktur.
|
||||||
|
Prüfidee: Zwei Mandanten mit getrennten Rechnungskreisen betreiben.
|
||||||
|
Tracelinks: SyRS-024, SyRS-012
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - im SaaS als Mandantenmodell.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
+3186
File diff suppressed because it is too large
Load Diff
+1030
File diff suppressed because it is too large
Load Diff
+60
@@ -0,0 +1,60 @@
|
|||||||
|
# Traceability – c-entron ERP-Suite
|
||||||
|
|
||||||
|
Konsolidierte Traceability-Tabelle über die drei Ebenen (Forward: StRS → SyRS → SwRS; Backward über dieselben Spalten). Der Artefaktbeleg nennt den führenden Modulpfad; die vollständigen Belege stehen in den Einzelanforderungen.
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---|---|---|---|
|
||||||
|
| StRS-012 | SyRS-001 | SwRS-001, SwRS-004, SwRS-014, SwRS-019, SwRS-020, SwRS-096 | src/backend/Centron.BL/Administration/Rights |
|
||||||
|
| StRS-019, StRS-012 | SyRS-002 | SwRS-001 | src/backend/Centron.BL/Administration/Rights |
|
||||||
|
| StRS-013, StRS-014 | SyRS-003 | SwRS-005, SwRS-009, SwRS-022, SwRS-028, SwRS-133, SwRS-139 | src/backend/Centron.BL/Administration/Logins; src/backend/Centron.BL/Administration/Licensing |
|
||||||
|
| StRS-013 | SyRS-004 | SwRS-002 | src/backend/Centron.BL/Administration/Logins |
|
||||||
|
| StRS-013 | SyRS-005 | SwRS-003, SwRS-011, SwRS-042, SwRS-144 | src/backend/Centron.BL/Administration/Logins |
|
||||||
|
| StRS-012, StRS-013 | SyRS-006 | - | src/backend/Centron.BL/Administration/Logins |
|
||||||
|
| StRS-012, StRS-013 | SyRS-007 | - | src/backend/Centron.BL/Administration/Logins |
|
||||||
|
| StRS-012 | SyRS-008 | SwRS-004, SwRS-008 | src/backend/Centron.BL/Administration/Rights |
|
||||||
|
| StRS-030 | SyRS-009 | SwRS-007, SwRS-137, SwRS-138 | src/backend/Centron.BL/ChangeTracking; src/backend/Centron.BL/Core |
|
||||||
|
| StRS-030 | SyRS-010 | SwRS-006, SwRS-111, SwRS-113, SwRS-137, SwRS-138 | src/backend/Centron.BL/Core |
|
||||||
|
| StRS-002, StRS-003 | SyRS-011 | SwRS-013, SwRS-018, SwRS-034, SwRS-051, SwRS-118, SwRS-140, SwRS-152, SwRS-154 | src/backend/Centron.BL/Sales/Receipts |
|
||||||
|
| StRS-003, StRS-012 | SyRS-012 | SwRS-010, SwRS-012, SwRS-016, SwRS-027 | src/backend/Centron.BL/Sales/Receipts; src/backend/Centron.BL/Administration/Mandatory |
|
||||||
|
| StRS-002, StRS-008, StRS-024 | SyRS-013 | SwRS-013, SwRS-014, SwRS-017, SwRS-071, SwRS-089, SwRS-112, SwRS-128 | src/backend/Centron.BL/Sales/Receipts; src/backend/Centron.BL/Warehousing |
|
||||||
|
| StRS-003 | SyRS-014 | SwRS-015, SwRS-154 | src/backend/Centron.BL/Sales/Receipts |
|
||||||
|
| StRS-002 | SyRS-015 | - | src/backend/Centron.BL/Sales/Receipts |
|
||||||
|
| StRS-002, StRS-030 | SyRS-016 | - | src/backend/Centron.BL/Sales/Receipts |
|
||||||
|
| StRS-013, StRS-028 | SyRS-017 | SwRS-021, SwRS-026, SwRS-085, SwRS-086, SwRS-101 | src/backend/Centron.BL/Administration/AccessTokens |
|
||||||
|
| StRS-031 | SyRS-018 | SwRS-024, SwRS-039, SwRS-062, SwRS-120 | src/backend/Centron.BL/Administration/BackgroundServices |
|
||||||
|
| StRS-029 | SyRS-019 | SwRS-023 | src/backend/Centron.BL/Administration/ArtificialIntelligence; src/backend/Centron.BL/ArtificialIntelligence |
|
||||||
|
| StRS-001, StRS-025 | SyRS-020 | SwRS-019, SwRS-020, SwRS-032, SwRS-061, SwRS-088, SwRS-090, SwRS-102, SwRS-103, SwRS-124, SwRS-152 | src/backend/Centron.BL/Accounts |
|
||||||
|
| StRS-030 | SyRS-022 | SwRS-030, SwRS-031 | src/backend/Centron.BL/Administration/DataSecurity |
|
||||||
|
| StRS-032 | SyRS-023 | SwRS-029, SwRS-033, SwRS-035, SwRS-036, SwRS-039, SwRS-040, SwRS-041, SwRS-042, SwRS-053, SwRS-064, SwRS-117, SwRS-122, SwRS-126 | src/backend/Centron.BL/Administration/Settings |
|
||||||
|
| StRS-033 | SyRS-024 | SwRS-027 | src/backend/Centron.BL/Administration/Company, .../CompanyInformations; src/backend/Centron.BL/Administration/Mandatory |
|
||||||
|
| StRS-009, StRS-016 | SyRS-021 | SwRS-025, SwRS-057, SwRS-058, SwRS-135, SwRS-141, SwRS-155 | src/backend/Centron.BL/DataExchange |
|
||||||
|
| StRS-015 | SyRS-025 | SwRS-038, SwRS-099, SwRS-107, SwRS-118, SwRS-132 | src/backend/Centron.BL/ReportEngine; src/backend/Centron.BL/Reporting |
|
||||||
|
| StRS-020 | SyRS-026 | SwRS-044, SwRS-056, SwRS-105, SwRS-125 | src/backend/Centron.BL/Administration/Documents, .../FileManagement |
|
||||||
|
| StRS-010, StRS-007, StRS-021 | SyRS-027 | SwRS-045, SwRS-052, SwRS-060, SwRS-063, SwRS-067, SwRS-069, SwRS-083, SwRS-091, SwRS-101, SwRS-123, SwRS-141, SwRS-148, SwRS-150 | src/backend/Centron.BL/EDI |
|
||||||
|
| StRS-022, StRS-023 | SyRS-028 | SwRS-054, SwRS-055, SwRS-059 | src/backend/Centron.BL/Devices; src/backend/Centron.BL/DocuBoard; src/backend/Centron.BL/Sales/CustomerAssets |
|
||||||
|
| StRS-018 | SyRS-029 | SwRS-043, SwRS-046, SwRS-049, SwRS-050, SwRS-070, SwRS-078, SwRS-079, SwRS-082, SwRS-104, SwRS-110, SwRS-116, SwRS-121, SwRS-157, SwRS-158 | src/backend/Centron.BL/Calendar; src/backend/Centron.BL/MyCentron; src/backend/Centron.BL/MyDay; src/backend/Centron.BL/ToDoArea |
|
||||||
|
| StRS-017 | SyRS-030 | SwRS-037, SwRS-115, SwRS-158 | src/backend/Centron.BL/Tapi; src/backend/Centron.BL/Administration/PhoneSettings |
|
||||||
|
| StRS-019 | SyRS-031 | SwRS-047, SwRS-048, SwRS-076, SwRS-077, SwRS-080, SwRS-081, SwRS-084, SwRS-108, SwRS-129, SwRS-130, SwRS-131, SwRS-134, SwRS-136, SwRS-142, SwRS-143, SwRS-145, SwRS-146, SwRS-147 | src/centron/Centron.WPF.UI, .../Centron.WPF.UI.Extension; src/nexus/CentronNexus; src/webservice/Centron.Controllers |
|
||||||
|
| StRS-009 | SyRS-032 | SwRS-065, SwRS-066, SwRS-135, SwRS-149, SwRS-155 | src/backend/Centron.BL/Finances |
|
||||||
|
| StRS-027 | SyRS-033 | SwRS-068 | src/backend/Centron.BL/IndexSearch |
|
||||||
|
| StRS-008 | SyRS-034 | SwRS-075 | src/backend/Centron.BL/MassUpdate |
|
||||||
|
| StRS-017, StRS-026 | SyRS-035 | SwRS-072, SwRS-074, SwRS-157 | src/backend/Centron.BL/Mail |
|
||||||
|
| StRS-017, StRS-005 | SyRS-036 | SwRS-073, SwRS-087, SwRS-109 | src/backend/Centron.BL/MailScanner |
|
||||||
|
| StRS-004 | SyRS-037 | SwRS-092, SwRS-093 | src/backend/Centron.BL/Sales/CustomerAssets |
|
||||||
|
| StRS-004, StRS-003 | SyRS-038 | SwRS-093, SwRS-094, SwRS-150 | src/backend/Centron.BL/Sales/CustomerAssets |
|
||||||
|
| StRS-006, StRS-005 | SyRS-039 | SwRS-095, SwRS-106 | src/backend/Centron.BL/Sales/CustomerAssets; src/backend/Centron.BL/Sales/Support |
|
||||||
|
| StRS-005, StRS-012 | SyRS-040 | SwRS-096, SwRS-097, SwRS-099, SwRS-114, SwRS-119 | src/backend/Centron.BL/Sales/Support |
|
||||||
|
| StRS-005 | SyRS-041 | SwRS-098 | src/backend/Centron.BL/Sales/Support |
|
||||||
|
| StRS-003, StRS-009 | SyRS-042 | SwRS-100, SwRS-127 | src/backend/Centron.BL/Sales/CashBooks |
|
||||||
|
| StRS-010, StRS-003 | SyRS-043 | SwRS-141 | src/backend/Centron.BL/DataExchange; src/backend/Centron.BL/ReportEngine; src/backend/Centron.Gateway; src/apis/Centron.Api.EbInterface |
|
||||||
|
| StRS-011 | SyRS-044 | SwRS-151 | src/apis/Centron.Api.Gls; src/apis/Centron.Api.Shipcloud |
|
||||||
|
| StRS-019 | SyRS-045 | SwRS-145, SwRS-156 | src/nexus/CentronNexus |
|
||||||
|
| StRS-013, StRS-012 | SyRS-046 | SwRS-136, SwRS-147 | src/webservice/Centron.Controllers |
|
||||||
|
| StRS-031 | SyRS-047 | SwRS-146, SwRS-153 | docker |
|
||||||
|
| StRS-031 | SyRS-048 | SwRS-153 | deployment; scripts |
|
||||||
|
| StRS-031 | SyRS-049 | SwRS-153 | tests; docker |
|
||||||
|
| StRS-009, StRS-003 | SyRS-050 | - | src/backend/Centron.BL/Administration/Settings; src/backend/Centron.BL/Finances |
|
||||||
|
|
||||||
|
**SwRS ohne SyRS-Referenz:** keine – jede SwRS-Anforderung referenziert mindestens eine SyRS-Anforderung.
|
||||||
|
|
||||||
|
**StRS ohne referenzierende SyRS-Anforderung:** keine – jede StRS-Anforderung wird von mindestens einer SyRS-Anforderung referenziert.
|
||||||
+197
@@ -0,0 +1,197 @@
|
|||||||
|
# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
|
||||||
|
|
||||||
|
## Lauf
|
||||||
|
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
|
||||||
|
- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
|
||||||
|
vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
|
||||||
|
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
|
||||||
|
- **Startzeit:** 2026-08-27T00:24:41.6237308+02:00
|
||||||
|
- **Endzeit:** 2026-08-27T07:28:28.0825221+02:00
|
||||||
|
- **Dauer gesamt:** 7:03:46 (`duration_ms` 7:03:44; API: 7:01:25)
|
||||||
|
— **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
|
||||||
|
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
|
||||||
|
- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
|
||||||
|
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
|
||||||
|
die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
|
||||||
|
Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
|
||||||
|
- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
|
||||||
|
- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
|
||||||
|
|
||||||
|
## Werkzeugkonfiguration
|
||||||
|
- **Skill-Version:** 7.0.0
|
||||||
|
- **Claude-Code-Version:** 2.1.246
|
||||||
|
- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
|
||||||
|
- **Modell (angefordert):** `claude-fable-5`
|
||||||
|
- **Modelle (tatsächlich eingesetzt):** `claude-fable-5` 30.635.548 Tokens (99.98 %), `claude-haiku-4-5-20251001` 6.969 Tokens (0.02 %)
|
||||||
|
- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
|
||||||
|
- **Effort:** `high` (per `--effort high` gesetzt)
|
||||||
|
- **Laufverzeichnis-ID:** `v7.0.0-35a4`
|
||||||
|
- **Ablage:** `Iteration 3/claude-fable-5/solo/high/`
|
||||||
|
- **Parallele Läufe:** nein – die Zeitangaben sind für Laufzeitvergleiche verwendbar
|
||||||
|
- **Agentenmodus:** `solo` (V1)
|
||||||
|
- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
|
||||||
|
- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
|
||||||
|
- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
|
||||||
|
- **Permission-Mode:** `acceptEdits`
|
||||||
|
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
|
||||||
|
`--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos) **zuzüglich** `Task`, `Agent`, `Workflow` aus dem Modus `solo`
|
||||||
|
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
|
||||||
|
- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
|
||||||
|
- **Subagenten:** keine (`spawned` = 0, `by_type` leer)
|
||||||
|
- **Verschachtelung:** `spawned` = 0, davon `spawned_by_subagents` = 0, `max_depth` = 0. Keine tieferen Ebenen, `_meta\subagenten.md` entfällt.
|
||||||
|
|
||||||
|
## Validierungsstichprobe
|
||||||
|
- **Größe:** noch nicht festgelegt
|
||||||
|
- **Ziehungsverfahren:** noch nicht festgelegt
|
||||||
|
- **Validatoren:** noch nicht festgelegt
|
||||||
|
- **Stand:** noch nicht gezogen
|
||||||
|
|
||||||
|
## Verbrauch
|
||||||
|
|
||||||
|
### Hauptagent (`usage`)
|
||||||
|
| Messgröße | Wert |
|
||||||
|
|---|---:|
|
||||||
|
| Input-Tokens | 246 |
|
||||||
|
| Output-Tokens | 280.683 (davon 40.204 Thinking-Tokens) |
|
||||||
|
| Cache-Write-Tokens | 816.487 |
|
||||||
|
| Cache-Read-Tokens | 28.808.092 |
|
||||||
|
| Agent-Turns | 139 |
|
||||||
|
|
||||||
|
### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
|
||||||
|
| Messgröße | `claude-fable-5` | `claude-haiku-4-5-20251001` | Summe |
|
||||||
|
|---|---:|---:|---:|
|
||||||
|
| Input-Tokens | 250 | 6.945 | 7.195 |
|
||||||
|
| Output-Tokens | 281.133 | 24 | 281.157 |
|
||||||
|
| Cache-Write-Tokens | 1.178.596 | 0 | 1.178.596 |
|
||||||
|
| Cache-Read-Tokens | 29.175.569 | 0 | 29.175.569 |
|
||||||
|
| **Tokens gesamt** | **30.635.548** | **6.969** | **30.642.517** |
|
||||||
|
|
||||||
|
**Tokens gesamt: 30.642.517** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
|
||||||
|
Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
|
||||||
|
`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
|
||||||
|
preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
|
||||||
|
|
||||||
|
Da im Modus `solo` keine Subagenten laufen, sind `usage` und `modelUsage` für das Hauptmodell
|
||||||
|
deckungsgleich; die Differenz zur Summe stammt allein aus den Haiku-Hilfsaufrufen.
|
||||||
|
|
||||||
|
## 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 | 33 | 13,7 % |
|
||||||
|
| SyRS | 50 | 20,7 % |
|
||||||
|
| SwRS | 158 | 65,6 % |
|
||||||
|
| **Gesamt** | **241** | 100 % |
|
||||||
|
|
||||||
|
### Anforderungstypen
|
||||||
|
|
||||||
|
| Typ | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| funktional | 133 | 55,2 % |
|
||||||
|
| Sicherheit | 32 | 13,3 % |
|
||||||
|
| Schnittstelle | 25 | 10,4 % |
|
||||||
|
| funktional (Abrechnung) | 19 | 7,9 % |
|
||||||
|
| nicht-funktional | 16 | 6,6 % |
|
||||||
|
| Daten | 12 | 5,0 % |
|
||||||
|
| Schnittstelle (Abrechnung) | 2 | 0,8 % |
|
||||||
|
| funktional (Abrechnung/Fakturierung) | 1 | 0,4 % |
|
||||||
|
| Sicherheit (Abrechnung) | 1 | 0,4 % |
|
||||||
|
|
||||||
|
### Belegqualität
|
||||||
|
|
||||||
|
| Messgröße | Wert |
|
||||||
|
|---|---:|
|
||||||
|
| Belege gesamt | 283 |
|
||||||
|
| davon `PRIMÄR` | 252 (89,0 %) |
|
||||||
|
| davon `SEKUNDÄR` | 18 (6,4 %) |
|
||||||
|
| davon `KONTEXT` | 13 (4,6 %) |
|
||||||
|
| Belege je Anforderung (Median) | 1 |
|
||||||
|
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 237 (98,3 %) |
|
||||||
|
|
||||||
|
### Übernahmewürdigkeit
|
||||||
|
|
||||||
|
| Einstufung | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| übernehmen | 218 | 90,5 % |
|
||||||
|
| workaround | 9 | 3,7 % |
|
||||||
|
| sonderfall | 7 | 2,9 % |
|
||||||
|
| veraltet | 7 | 2,9 % |
|
||||||
|
|
||||||
|
### Status
|
||||||
|
|
||||||
|
| Kategorie | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| belegt | 235 | 97,5 % |
|
||||||
|
| als `HYPOTHESE` gekennzeichnet | 6 | 2,5 % |
|
||||||
|
| als Workaround vermerkt | 0 | 0,0 % |
|
||||||
|
| Konsolidierungskandidaten | 41 | 17,0 % |
|
||||||
|
| mit ISO-25010-Qualitätsmerkmal | 16 | 6,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** (74 risikorelevante Anforderungen, alle gedeckt) |
|
||||||
|
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||||
|
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 241 Anforderungen eingestuft) |
|
||||||
|
| **Traceability** – Verknüpfung zwischen den Ebenen | 241 von 241 mit Tracelinks (100,0 %) |
|
||||||
|
|
||||||
|
## Ergebnis
|
||||||
|
- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
|
||||||
|
- **Session-ID:** `03603a98-feb4-43f9-8f8c-1621115f6c38`
|
||||||
|
- **Permission-Denials:** 2 (2 × `Bash`) – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
|
||||||
|
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – Bedingung `solo` eingehalten
|
||||||
|
- **Subagenten-Prompts:** entfällt (Modus `solo`)
|
||||||
|
- **Erzeugte Dateien:** 7 Dateien in `Ergebnisse\`:
|
||||||
|
|
||||||
|
| Datei | Größe |
|
||||||
|
|---|---:|
|
||||||
|
| `Analysebericht.md` | 43.009 B |
|
||||||
|
| `Glossar.md` | 4.881 B |
|
||||||
|
| `Hypothesen.md` | 2.131 B |
|
||||||
|
| `StRS.md` | 33.169 B |
|
||||||
|
| `SwRS.md` | 201.104 B |
|
||||||
|
| `SyRS.md` | 83.391 B |
|
||||||
|
| `Traceability.md` | 6.885 B |
|
||||||
|
|
||||||
|
- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
|
||||||
|
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
|
||||||
|
|
||||||
|
## Anmerkungen/Auffälligkeiten
|
||||||
|
|
||||||
|
**1. Neue Zelle: `claude-fable-5` / `solo` / `high`.** Erster gültiger Lauf dieser Kombination;
|
||||||
|
der vorausgegangene Versuch `195958_v7.0.0-77a1` scheiterte am Session-Kontingent.
|
||||||
|
|
||||||
|
**2. Die Modellkontrolle ist sauber – und grenzt den Fable-Befund ein.** `modelUsage` weist
|
||||||
|
ausschließlich `claude-fable-5` plus Haiku-Hilfsaufrufe aus. Im Modus `builtin` war bei Fable
|
||||||
|
zweimal `claude-opus-5[1m]` aufgetreten, zuletzt im Lauf `d694` desselben Blocks. Damit steht
|
||||||
|
fest: **Nicht Fable ist das Problem, sondern Fable in Kombination mit Delegation.** Ohne
|
||||||
|
Subagenten wird das angeforderte Modell eingehalten.
|
||||||
|
|
||||||
|
**3. Zweithöchster `PRIMÄR`-Anteil der Reihe: 89,0 %** von 283 Belegen, 98,3 % der Anforderungen
|
||||||
|
mit mindestens einem Primärbeleg – bei nur 30,6 Mio. Tokens. Das günstigste Modell liefert hier
|
||||||
|
die sauberste Belegarbeit.
|
||||||
|
|
||||||
|
**4. Vollständig regelkonform:** alle fünf Prüfkriterien erfüllt, einschließlich der
|
||||||
|
risikobasierten Priorisierung (74 risikorelevante Anforderungen, alle gedeckt) und Tracelinks bei
|
||||||
|
100 %. Das gelang sonst nur `f631`, `2316`, `b652` und den drei `max`-Läufen.
|
||||||
|
|
||||||
|
**5. Belegdichte Median 1,0** – Fable schreibt einen Beleg je Anforderung. Zusammen mit Opus
|
||||||
|
(2,0 auf `high`) und Sonnet (1,0) stützt das den Befund aus Punkt 2 des Laufs `2269`: Die
|
||||||
|
Belegdichte folgt dem Modell.
|
||||||
|
|
||||||
|
**6. Die Wanduhrzeit von 7:03:44 ist unbrauchbar – aus einem neuen Grund.** Nicht Parallelbetrieb,
|
||||||
|
sondern **Kontingent-Wartezeiten**: Zwischen den Werkzeugaufrufen lagen Lücken von 4:00 h
|
||||||
|
(23:08 → 03:08) und zweimal rund 2 h. Die CLI bricht bei erschöpftem Kontingent nicht ab, sondern
|
||||||
|
wartet auf das nächste Reset-Fenster. `duration_ms` bildet diese Wartezeit mit ab. Damit ist ein
|
||||||
|
dritter Verzerrungsmechanismus der Zeitmessung dokumentiert, neben Parallelbetrieb und Abbruch.
|
||||||
|
Tokenverbrauch, Anforderungszahl und Belegkennzahlen sind davon **nicht** betroffen.
|
||||||
|
|
||||||
|
**7. Zwei Permission-Denials**, keiner auf `Task`/`Agent`/`Workflow`. `spawned` = 0.
|
||||||
+1
File diff suppressed because one or more lines are too long
+242
@@ -0,0 +1,242 @@
|
|||||||
|
ReqID Titel Ebene Module Trace Risiko PRIMAER Status Konsolidierung
|
||||||
|
SyRS-001 Gruppenbasierte Benutzerrechtepruefung SyRS M-024 StRS-012 J J belegt Kandidat:SyRS-002
|
||||||
|
SyRS-002 Getrenntes Rechtemodell fuer Web-Accounts SyRS M-024 StRS-019,StRS-012 J J belegt Kandidat:SyRS-001
|
||||||
|
SyRS-003 Ticketbasierte Sitzungen mit Lizenzpruefung SyRS M-017,M-016 StRS-013,StRS-014 J J belegt nein
|
||||||
|
SyRS-004 Mehrere Authentifizierungsverfahren SyRS M-017 StRS-013 J J belegt nein
|
||||||
|
SyRS-005 Zwei-Faktor-Authentifizierung SyRS M-017 StRS-013 J J belegt Kandidat:SwRS-011
|
||||||
|
SyRS-006 Zeitgesteuerte Kontodeaktivierung SyRS M-017 StRS-012,StRS-013 J J belegt nein
|
||||||
|
SyRS-007 Anwendungsbezogene Anmelderechte SyRS M-017 StRS-012,StRS-013 J J belegt nein
|
||||||
|
SyRS-008 Standard-Rechtegruppen SyRS M-024 StRS-012 J J belegt nein
|
||||||
|
SyRS-009 Aenderungsnachverfolgung SyRS M-036,M-039 StRS-030 N J belegt nein
|
||||||
|
SyRS-010 Transaktionale Speicherung SyRS M-039 StRS-030 N J belegt nein
|
||||||
|
SwRS-001 Rechteermittlung SQL+Cache SwRS M-024 SyRS-001,SyRS-002 J J belegt nein
|
||||||
|
SwRS-002 Passwort SHA1 ungesalzen SwRS M-017 SyRS-004 J J belegt nein
|
||||||
|
SwRS-003 2FA-Validatorwahl SwRS M-017 SyRS-005 J J belegt nein
|
||||||
|
SwRS-004 Rechtegruppenverwaltung SwRS M-024 SyRS-001,SyRS-008 J J belegt nein
|
||||||
|
SwRS-005 Ticket-Wiederverwendung+LoginIP SwRS M-017 SyRS-003 J J belegt nein
|
||||||
|
SwRS-006 Speicher-Template Hooks SwRS M-039 SyRS-010 N J belegt nein
|
||||||
|
SwRS-007 Erstellungs-/Aenderungsmetadaten SwRS M-036,M-039 SyRS-009 N J belegt nein
|
||||||
|
SwRS-008 Standardrechtegruppen aus Ressource SwRS M-024 SyRS-008 J J belegt nein
|
||||||
|
SwRS-009 Signaturvalidierte Lizenzdatei SwRS M-016 SyRS-003 J J belegt nein
|
||||||
|
SyRS-011 Belegkette Weiterfuehrungswege SyRS M-083 StRS-002,StRS-003 J J belegt Kandidat:CustomerAssets-Modell
|
||||||
|
SyRS-012 Nummernkreise je Mandant/Filiale SyRS M-083,M-018 StRS-003,StRS-012 J J belegt nein
|
||||||
|
SyRS-013 Bestandswirkung der Belege SyRS M-083,M-115 StRS-002,StRS-008,StRS-024 J J belegt nein
|
||||||
|
SyRS-014 Mindestpreisschutz SyRS M-083 StRS-003 J J belegt nein
|
||||||
|
SyRS-015 Belegsperren+Concurrency SyRS M-083 StRS-002 N J belegt nein
|
||||||
|
SyRS-016 Belegversionierung SyRS M-083 StRS-002,StRS-030 N J belegt nein
|
||||||
|
SwRS-010 Belegnummernvergabe+Templatekunde SwRS M-083 SyRS-012 J J belegt nein
|
||||||
|
SwRS-011 TOTP-Zweitfaktor SwRS M-111 SyRS-005 J J belegt Kandidat:SyRS-005
|
||||||
|
SwRS-012 Nummernkreis-Kaskade SwRS M-018 SyRS-012 J J belegt nein
|
||||||
|
SwRS-013 IReceiptSpecificLogic-Strategie SwRS M-083 SyRS-011,SyRS-013 N J belegt nein
|
||||||
|
SwRS-014 Negativbuchung nur mit Recht SwRS M-083,M-115 SyRS-013,SyRS-001 J J belegt nein
|
||||||
|
SwRS-015 Mindestpreis-Reauth SwRS M-083 SyRS-014 J J belegt nein
|
||||||
|
SwRS-016 Filialzuordnung BranchOrigin SwRS M-083 SyRS-012 N J belegt nein
|
||||||
|
SwRS-017 Seriennummern-Vollstaendigkeit SwRS M-083 SyRS-013 N J belegt nein
|
||||||
|
SwRS-018 Firmengruppen-Belegeinstellungen SwRS M-083 SyRS-011 N J belegt nein
|
||||||
|
SyRS-017 API-Zugriffstokens SyRS M-003 StRS-013,StRS-028 J J belegt nein
|
||||||
|
SyRS-018 Steuerbare Hintergrunddienste SyRS M-006 StRS-031 N J belegt nein
|
||||||
|
SyRS-019 KI-Assistenz konfigurierbar SyRS M-005,M-030 StRS-029 N J belegt nein
|
||||||
|
SwRS-019 Bankverbindungen Rechte+Default SwRS M-001 SyRS-001,SyRS-020 J J belegt nein
|
||||||
|
SwRS-020 Kontenstamm Rechte+FiBu-Nummer SwRS M-002 SyRS-001,SyRS-020 J J belegt nein
|
||||||
|
SwRS-021 API-Token Hash+Ablauf+Log SwRS M-003 SyRS-017 J J belegt nein
|
||||||
|
SwRS-022 Client-Version je Anmeldung SwRS M-004 SyRS-003 N J belegt nein
|
||||||
|
SwRS-023 KI-Prompts+verschluesselte Keys SwRS M-005 SyRS-019 N J belegt nein
|
||||||
|
SwRS-024 Hintergrunddienst-Zustand SwRS M-006 SyRS-018 N J belegt nein
|
||||||
|
SwRS-025 Kontenrahmenverwaltung SwRS M-007 SyRS-021 N J belegt nein
|
||||||
|
SwRS-026 Konfig-DB Masterkey SwRS M-008 SyRS-017,StRS-028 J J belegt Kandidat:SwRS-023
|
||||||
|
SyRS-020 Konten-/Adressstamm SyRS M-002 StRS-001,StRS-025 N J belegt nein
|
||||||
|
SyRS-022 DSGVO Loeschkonzept SyRS M-012 StRS-030 J J belegt nein
|
||||||
|
SyRS-023 Zentrale Konfiguration SyRS M-026 StRS-032 N J belegt nein
|
||||||
|
SyRS-024 Mandanten-/Filialstruktur SyRS M-009,M-018 StRS-033 N J belegt nein
|
||||||
|
SwRS-027 Kollisionssichere Nummernvergabe SwRS M-009 SyRS-012,SyRS-024 J J belegt nein
|
||||||
|
SwRS-028 Verbindungsverwaltung SwRS M-010 SyRS-003 N J belegt nein
|
||||||
|
SwRS-029 Custom Properties je Modul SwRS M-011 SyRS-023 N J belegt Kandidat:M-043
|
||||||
|
SwRS-030 DSGVO-Kontaktloeschung SwRS M-012 SyRS-022 J J belegt nein
|
||||||
|
SwRS-031 Online-AVV/SEPA-Dokumente SwRS M-013 SyRS-022,StRS-020 N J belegt Kandidat:Nexus-Signierung
|
||||||
|
SwRS-032 Mitarbeiter Abteilungen/Skills SwRS M-014 SyRS-020,StRS-012 N J belegt nein
|
||||||
|
SwRS-033 DB-Umgebungspruefungen SwRS M-015 SyRS-023 N J belegt nein
|
||||||
|
SwRS-034 Konditionen-Stammdaten SwRS M-019 SyRS-011 N J belegt nein
|
||||||
|
SwRS-035 Netzwerkdiagnose SwRS M-020 SyRS-023 N J belegt nein
|
||||||
|
SwRS-036 Performance-Messungen SwRS M-021 SyRS-023 N J belegt nein
|
||||||
|
SwRS-037 Telefonie-Einstellungen SwRS M-022 SyRS-030 N J belegt nein
|
||||||
|
SwRS-038 Portal Statuspruefung/Reportupload SwRS M-023 SyRS-025 N J belegt nein
|
||||||
|
SwRS-039 Wartungsskripte+SQL-Management SwRS M-025 SyRS-023,SyRS-018 N J belegt nein
|
||||||
|
SwRS-040 Typisierter Einstellungszugriff SwRS M-026 SyRS-023 N J belegt nein
|
||||||
|
SwRS-041 UI-Themes SwRS M-027 SyRS-023 N J belegt nein
|
||||||
|
SwRS-042 Webservice-Konfigurationsdatei SwRS M-028 SyRS-023,SyRS-005 N J belegt nein
|
||||||
|
SyRS-021 FiBu-Uebergabe DATEV SyRS M-044 StRS-009,StRS-016 J J belegt nein
|
||||||
|
SwRS-043 Terminanfragen SwRS M-029 SyRS-029,StRS-018 N J belegt nein
|
||||||
|
SwRS-044 Lieferantenbeleg-Ablage SwRS M-031 SyRS-026 N J belegt nein
|
||||||
|
SwRS-045 Distributoren auto-anlegen SwRS M-032 SyRS-027 N J belegt nein
|
||||||
|
SwRS-046 Kalender-Einstellungen SwRS M-033 SyRS-029,StRS-018 N J belegt nein
|
||||||
|
SwRS-047 Icon-Verwaltung SwRS M-034 SyRS-031 N J belegt nein
|
||||||
|
SwRS-048 Nexus-Einstellungen SwRS M-035 SyRS-031 N J belegt nein
|
||||||
|
SwRS-049 Chat SwRS M-037 SyRS-029,StRS-017 N J belegt nein
|
||||||
|
SwRS-050 Checklisten SwRS M-038 SyRS-029 N J belegt nein
|
||||||
|
SwRS-051 Laender/Waehrungen SwRS M-040 SyRS-011,StRS-001 N J belegt nein
|
||||||
|
SwRS-052 CPra-Konnektor SwRS M-041 SyRS-027 N J belegt nein
|
||||||
|
SwRS-053 Custom Tables SwRS M-043 SyRS-023 N J belegt Kandidat:SwRS-029
|
||||||
|
SwRS-054 AccountDevices SwRS M-045 SyRS-028,StRS-022 N J belegt Kandidat:Assets
|
||||||
|
SwRS-055 AssetManagement DocuBoard SwRS M-046 SyRS-028,StRS-022 N J belegt Kandidat:SwRS-054
|
||||||
|
SwRS-056 Dokumentationen SwRS M-047 SyRS-026,StRS-020 N J belegt nein
|
||||||
|
SwRS-057 FiBu-Exportkonfigurationen SwRS M-044 SyRS-021 J J belegt nein
|
||||||
|
SwRS-058 Doppeluebergabeschutz FiBu SwRS M-044 SyRS-021 J J belegt nein
|
||||||
|
SyRS-025 Report-Engine Belegdruck SyRS M-080,M-081 StRS-015 N J belegt nein
|
||||||
|
SyRS-026 Dokumenten-/Verzeichnisverwaltung SyRS M-013 StRS-020 N J belegt nein
|
||||||
|
SyRS-027 EDI-Bestelluebertragung SyRS M-048 StRS-010,StRS-007,StRS-021 N J belegt Kandidat:Gateway-EDI
|
||||||
|
SyRS-028 Kundengeraete/Assets SyRS M-045,M-046,M-084 StRS-022,StRS-023 N J belegt Kandidat:3 Datenhaltungen
|
||||||
|
SyRS-029 Organisation+Zusammenarbeit SyRS M-033,M-066,M-067,M-107 StRS-018 N J belegt nein
|
||||||
|
SyRS-030 TAPI-Telefonie SyRS M-101,M-022 StRS-017 N J belegt nein
|
||||||
|
SyRS-031 Mehrkanal-Clients SyRS M-127,M-130,M-133 StRS-019 N J belegt Kandidat:Doppel-UI
|
||||||
|
SyRS-032 Onlinebanking-Zahlungsabgleich SyRS M-053 StRS-009 J J belegt nein
|
||||||
|
SyRS-033 Volltextsuche SyRS M-056 StRS-027 N J belegt nein
|
||||||
|
SyRS-034 Massenaenderungen SyRS M-063 StRS-008 N J belegt nein
|
||||||
|
SyRS-035 E-Mail/Exchange SyRS M-060 StRS-017,StRS-026 N J belegt nein
|
||||||
|
SyRS-036 Mail-Scanner SyRS M-061 StRS-017,StRS-005 N J belegt Kandidat:Workflows
|
||||||
|
SwRS-059 RMA-Abwicklung SwRS M-042 SyRS-028,StRS-023 N J belegt nein
|
||||||
|
SwRS-060 EDI-Bestellerzeugung SwRS M-048 SyRS-027 N J belegt nein
|
||||||
|
SwRS-061 Mitarbeiterstatus/Dispatcher SwRS M-049 SyRS-020,StRS-012 N J belegt nein
|
||||||
|
SwRS-062 ExpectedEvents SwRS M-050 SyRS-018,StRS-031 N J belegt nein
|
||||||
|
SwRS-063 Externe Helpdesk-Konfiguration SwRS M-051 SyRS-027,StRS-005 N J belegt Kandidat:DocBee
|
||||||
|
SwRS-064 Externe Tools SwRS M-052 SyRS-023 N J belegt nein
|
||||||
|
SwRS-065 Zahlungseingangsprotokoll SwRS M-053 SyRS-032 J J belegt nein
|
||||||
|
SwRS-066 Bankumsatz-Zuordnung/Buchung SwRS M-053 SyRS-032 J J belegt nein
|
||||||
|
SwRS-067 CustomGateway Sonderartikel SwRS M-054 SyRS-027,StRS-004 N J belegt nein
|
||||||
|
SwRS-068 Lucene-Index inkrementell SwRS M-056 SyRS-033 N J belegt nein
|
||||||
|
SwRS-069 Shop-Integration ExternalId SwRS M-057 SyRS-027,StRS-019 N J belegt nein
|
||||||
|
SwRS-070 ItPlanner Kategorien SwRS M-058 SyRS-029 N J belegt nein
|
||||||
|
SwRS-071 Lagerorte+Umbuchungslog SwRS M-059 SyRS-013,StRS-008 N J belegt nein
|
||||||
|
SwRS-072 Signaturen+Blacklist SwRS M-060 SyRS-035 N J belegt nein
|
||||||
|
SwRS-073 MailScanner-Konfiguration SwRS M-061 SyRS-036 N J belegt nein
|
||||||
|
SwRS-074 Serien-Mailings SwRS M-062 SyRS-035,StRS-026 N J belegt nein
|
||||||
|
SwRS-075 Massenpreisaenderungen SwRS M-063 SyRS-034 N J belegt nein
|
||||||
|
SwRS-076 Mobile Mitarbeiterliste SwRS M-064 SyRS-031 N J belegt nein
|
||||||
|
SwRS-077 Modulkatalog+Favoriten SwRS M-065 SyRS-031,StRS-014 N J belegt nein
|
||||||
|
SwRS-078 Dashboards SwRS M-066 SyRS-029 N J belegt nein
|
||||||
|
SwRS-079 MyDay Arbeitsvorrat SwRS M-067 SyRS-029 N J belegt nein
|
||||||
|
SwRS-080 Nexus-Benachrichtigungen SwRS M-068 SyRS-031,StRS-018 N J belegt Kandidat:M-070
|
||||||
|
SwRS-081 Ticket-Ansichten Nexus SwRS M-069 SyRS-031,StRS-005 N J belegt nein
|
||||||
|
SwRS-082 Objekt-Benachrichtigungsempfaenger SwRS M-070 SyRS-029 N J belegt Kandidat:SwRS-080
|
||||||
|
SwRS-083 Externe Objektreferenzen SwRS M-071 SyRS-027 N J belegt nein
|
||||||
|
SwRS-084 Outlook-Assetsuche SwRS M-072 SyRS-031,StRS-022 N J belegt nein
|
||||||
|
SwRS-085 Kundenzugangsdaten+Logs SwRS M-073 SyRS-017,StRS-028 J J belegt Kandidat:M-074
|
||||||
|
SwRS-086 Passwortmanager Siegel SwRS M-074 SyRS-017,StRS-028 J J belegt Kandidat:SwRS-085
|
||||||
|
SwRS-087 Prozesse Schritte/Bindungen SwRS M-075 SyRS-036,StRS-031 N J belegt Kandidat:Workflows
|
||||||
|
SwRS-088 Produktmatrix SwRS M-076 SyRS-020,StRS-025 N J belegt nein
|
||||||
|
SwRS-089 Fertigungsauftraege SwRS M-077 SyRS-013,StRS-024 N J belegt nein
|
||||||
|
SwRS-090 Projektliste SwRS M-078 SyRS-020,StRS-025 N J belegt Kandidat:Projektbegriffe
|
||||||
|
SwRS-091 Bestellvorschlaege SwRS M-079 SyRS-027,StRS-007 N J belegt nein
|
||||||
|
SyRS-037 Vertragsverwaltung Laufzeit/Intervalle SyRS M-084 StRS-004 J J belegt nein
|
||||||
|
SyRS-038 Automatische Vertragsfakturierung SyRS M-084 StRS-004,StRS-003 J J belegt nein
|
||||||
|
SyRS-039 Timer-Billing SyRS M-084,M-086 StRS-006,StRS-005 J J belegt nein
|
||||||
|
SyRS-040 Helpdesk Rechte+Status SyRS M-086 StRS-005,StRS-012 J J belegt nein
|
||||||
|
SyRS-041 Ticket-Eskalation SyRS M-086 StRS-005 N J belegt nein
|
||||||
|
SyRS-042 Kassenbuch SyRS M-087 StRS-003,StRS-009 J J belegt nein
|
||||||
|
SwRS-092 Vertrags-Datumsarithmetik SwRS M-084 SyRS-037 J J belegt nein
|
||||||
|
SwRS-093 Auto-Vertragsschliessen SwRS M-084 SyRS-037,SyRS-038 J J belegt nein
|
||||||
|
SwRS-094 Abrechnungsfaellige Kunden+Zaehler SwRS M-084 SyRS-038 J J belegt nein
|
||||||
|
SwRS-095 Timer-Belegerzeugung SwRS M-084,M-086 SyRS-039 J J belegt nein
|
||||||
|
SwRS-096 Ticket-Rechtepruefung Save SwRS M-086 SyRS-040,SyRS-001 J J belegt nein
|
||||||
|
SwRS-097 Ticket-Sichtbarkeit restriktiv SwRS M-086 SyRS-040 J J belegt nein
|
||||||
|
SwRS-098 Eskalationslauf SwRS M-086 SyRS-041 N J belegt nein
|
||||||
|
SwRS-099 Ticketabschluss+Benachrichtigung SwRS M-086 SyRS-040,SyRS-025 N J belegt nein
|
||||||
|
SwRS-100 Kassenbuchbuchung SwRS M-087 SyRS-042 J J belegt nein
|
||||||
|
SwRS-101 Riverbird-Ticketvalidierung SwRS M-082 SyRS-017,SyRS-027 J J belegt nein
|
||||||
|
SwRS-102 Kundensuche Kompakt SwRS M-085 SyRS-020 N J belegt nein
|
||||||
|
SwRS-103 Telemarketing SwRS M-088 SyRS-020,StRS-026 N J belegt nein
|
||||||
|
SwRS-104 Terminverwaltung Schedule SwRS M-089 SyRS-029 N J belegt Kandidat:M-033
|
||||||
|
SwRS-105 Dokuwizard Infrastruktur SwRS M-090 SyRS-026,StRS-020 N J belegt Kandidat:M-047
|
||||||
|
SwRS-106 Stundenzuschlagssaetze SwRS M-091 SyRS-039 J J belegt nein
|
||||||
|
SwRS-107 PDF-Signatur SwRS M-092 SyRS-025,StRS-020 J J belegt nein
|
||||||
|
SwRS-108 SelfCare-Formulare SwRS M-093 SyRS-031,StRS-019 N J belegt Kandidat:WebHDQuestion
|
||||||
|
SwRS-109 Workflow-Prozesse SwRS M-094 SyRS-036,StRS-031 N J belegt Kandidat:SwRS-087
|
||||||
|
SwRS-110 Social-Media-Feed SwRS M-095 SyRS-029 N J belegt nein
|
||||||
|
SwRS-111 Start Mapping/Verbindung SwRS M-096 SyRS-010 N J belegt nein
|
||||||
|
SwRS-112 Inventur SwRS M-098 SyRS-013,StRS-008 J J belegt nein
|
||||||
|
SwRS-113 I3D-Systemtabelle SwRS M-099 SyRS-010 N J belegt nein
|
||||||
|
SwRS-114 Tags SwRS M-100 SyRS-040 N J belegt nein
|
||||||
|
SwRS-115 Anruferkennung SwRS M-101 SyRS-030 N J belegt nein
|
||||||
|
SwRS-116 TaskManager Handler SwRS M-102 SyRS-029,StRS-031 N J belegt Kandidat:M-107
|
||||||
|
SwRS-117 Telemetrie SwRS M-103 SyRS-023 N J belegt nein
|
||||||
|
SwRS-118 Textbausteine SwRS M-104 SyRS-025,SyRS-011 N J belegt nein
|
||||||
|
SwRS-119 Ticket-Projekte SwRS M-105 SyRS-040,StRS-025 N J belegt Kandidat:SwRS-090
|
||||||
|
SwRS-120 TimingSettings SwRS M-106 SyRS-018 N J belegt nein
|
||||||
|
SwRS-121 Objekt-ToDos SwRS M-107 SyRS-029 N J belegt Kandidat:SwRS-116
|
||||||
|
SwRS-122 Textformat-Konvertierung SwRS M-108 SyRS-023 N J belegt nein
|
||||||
|
SwRS-123 TradePool-Import SwRS M-109 SyRS-027 N J belegt nein
|
||||||
|
SwRS-124 Transaktionsobjekte SwRS M-110 SyRS-020 N J belegt nein
|
||||||
|
SwRS-125 SimpleUrls SwRS M-112 SyRS-026 N J belegt nein
|
||||||
|
SwRS-126 Videoportal-Zuordnung SwRS M-113 SyRS-023 N J belegt nein
|
||||||
|
SwRS-127 Gutscheinverwaltung SwRS M-114 SyRS-042 J J belegt nein
|
||||||
|
SwRS-128 Artikelstamm Systemartikel SwRS M-115 SyRS-013,StRS-008 N J belegt nein
|
||||||
|
SwRS-129 Aktions-Weblinks SwRS M-116 SyRS-031,StRS-019 N J belegt nein
|
||||||
|
SwRS-130 Webmenue-Konfiguration SwRS M-118 SyRS-031 N J belegt nein
|
||||||
|
SwRS-131 Webservice-Version SwRS M-119 SyRS-031 N J belegt nein
|
||||||
|
SwRS-132 PDF-Merge SwRS M-120 SyRS-025 N J belegt nein
|
||||||
|
SwRS-133 Typisierte Exceptions SwRS M-121 SyRS-003 N J belegt nein
|
||||||
|
SyRS-043 E-Rechnungsformate SyRS M-044,M-080,M-126,M-137 StRS-010,StRS-003 J J belegt nein
|
||||||
|
SyRS-044 Versanddienstleister SyRS M-138,M-139 StRS-011 N J belegt Kandidat:GLS-vs-Shipcloud
|
||||||
|
SyRS-045 Kundenportal Nexus SyRS M-130 StRS-019 N J belegt Kandidat:SelfCare
|
||||||
|
SyRS-046 REST-API Rechteautorisierung SyRS M-133 StRS-013,StRS-012 J J belegt nein
|
||||||
|
SyRS-047 Container-Betrieb SyRS M-148 StRS-031 N J belegt nein
|
||||||
|
SyRS-048 Windows-Installer SyRS M-147,M-149 StRS-031 N J belegt nein
|
||||||
|
SyRS-049 Testabdeckung SyRS M-151,M-148 StRS-031 N J belegt nein
|
||||||
|
SwRS-134 Grid-/UI-Profile SwRS M-055 SyRS-031 N J belegt nein
|
||||||
|
SwRS-135 Statistiken SwRS M-097 SyRS-021,SyRS-032,StRS-016 N J belegt nein
|
||||||
|
SwRS-136 Webservice-Fassaden SwRS M-117 SyRS-031,SyRS-046 N J belegt Kandidat:Doppel-BL
|
||||||
|
SwRS-137 DAO Event-Listener SwRS M-122 SyRS-010,SyRS-009 N J belegt nein
|
||||||
|
SwRS-138 Entitaetsmodell I3D SwRS M-123 SyRS-009,SyRS-010 N J belegt nein
|
||||||
|
SwRS-139 ModuleFeatures SwRS M-124 SyRS-003 N J belegt nein
|
||||||
|
SwRS-140 Objektartenkatalog SwRS M-125 SyRS-011 N J belegt nein
|
||||||
|
SwRS-141 Gateway-Formatadapter SwRS M-126 SyRS-027,SyRS-021,SyRS-043 N J belegt Kandidat:EDI-Doppel
|
||||||
|
SwRS-142 WPF-Client SwRS M-127 SyRS-031 N J belegt Kandidat:Nexus
|
||||||
|
SwRS-143 Controls-Bibliothek SwRS M-128 SyRS-031 N J belegt nein
|
||||||
|
SwRS-144 Core-Bibliothek TOTP SwRS M-129 SyRS-005 J J belegt nein
|
||||||
|
SwRS-145 Nexus-Webclient SwRS M-130,M-131,M-132 SyRS-031,SyRS-045 N J belegt Kandidat:SwRS-142
|
||||||
|
SwRS-146 Webservice-Hosting SwRS M-134,M-135,M-136 SyRS-047,SyRS-031 N J belegt nein
|
||||||
|
SwRS-147 Versionierte Controller SwRS M-133 SyRS-046,SyRS-031 J J belegt nein
|
||||||
|
SwRS-148 Distributor-Produktdaten SwRS M-140,M-141,M-143,M-144 SyRS-027,StRS-007 N J belegt nein
|
||||||
|
SwRS-149 finAPI-Client SwRS M-142 SyRS-032 J J belegt nein
|
||||||
|
SwRS-150 docuFORM-Anbindung SwRS M-145 SyRS-038,SyRS-027 N J belegt Kandidat:Assets
|
||||||
|
SwRS-151 GLS/Shipcloud Logik SwRS M-138,M-139 SyRS-044 N J belegt nein
|
||||||
|
SwRS-152 Legacy-DB-Schema Kunden SwRS M-146 SyRS-011,SyRS-020 N J belegt Kandidat:Bankdaten
|
||||||
|
SwRS-153 Release-Artefakte SwRS M-147,M-148,M-149 SyRS-047,SyRS-048,SyRS-049 N J belegt nein
|
||||||
|
SyRS-050 [HYPOTHESE] Mahnwesen SyRS M-026,M-053 StRS-009,StRS-003 J N HYPOTHESE nein
|
||||||
|
SwRS-154 [HYPOTHESE] Anzahlungsverrechnung SwRS M-083 SyRS-011,SyRS-014 J J HYPOTHESE nein
|
||||||
|
SwRS-155 [HYPOTHESE] SEPA-Lastschrift SwRS M-053,M-001 SyRS-032,SyRS-021 J J HYPOTHESE nein
|
||||||
|
SwRS-156 [HYPOTHESE] WebCart-Sonderpreise SwRS M-130,M-086 SyRS-045 N N HYPOTHESE nein
|
||||||
|
SwRS-157 [HYPOTHESE] Exchange-Sync SwRS M-060,M-033 SyRS-035,SyRS-029 N N HYPOTHESE Kandidat:SwRS-104
|
||||||
|
SwRS-158 [HYPOTHESE] Fernwartung Supremo SwRS M-067 SyRS-029,SyRS-030 N N HYPOTHESE nein
|
||||||
|
StRS-001 Geschaeftspartnerverwaltung StRS M-002 SyRS-020,SyRS-024 N J belegt nein
|
||||||
|
StRS-002 Angebots-/Auftragsabwicklung StRS M-083 SyRS-011,SyRS-015,SyRS-016 N J belegt nein
|
||||||
|
StRS-003 Geschuetzte Fakturierung StRS M-083,M-087 SyRS-012,SyRS-014,SyRS-042 J J belegt nein
|
||||||
|
StRS-004 Vertragsgeschaeft StRS M-084 SyRS-037,SyRS-038,SyRS-039 J J belegt nein
|
||||||
|
StRS-005 Helpdesk StRS M-086 SyRS-040,SyRS-041,SyRS-036 N J belegt nein
|
||||||
|
StRS-006 Leistungserfassung StRS M-084,M-086 SyRS-039 J J belegt nein
|
||||||
|
StRS-007 Einkauf+Distribution StRS M-079,M-048 SyRS-027 N J belegt nein
|
||||||
|
StRS-008 Artikel-/Lagerfuehrung StRS M-115,M-059,M-098 SyRS-013,SyRS-034 N J belegt nein
|
||||||
|
StRS-009 Finanzprozesse StRS M-053,M-044,M-087 SyRS-021,SyRS-032,SyRS-042,SyRS-050 J J belegt nein
|
||||||
|
StRS-010 E-Belegaustausch StRS M-044,M-048 SyRS-043,SyRS-027 J J belegt nein
|
||||||
|
StRS-011 Versandabwicklung StRS M-138,M-139 SyRS-044 N J belegt nein
|
||||||
|
StRS-012 Berechtigungssteuerung StRS M-024 SyRS-001,SyRS-002,SyRS-008 J J belegt nein
|
||||||
|
StRS-013 Sichere Anmeldung/API StRS M-017,M-003 SyRS-003,SyRS-004,SyRS-005,SyRS-017,SyRS-046 J J belegt nein
|
||||||
|
StRS-014 Lizenz-/Modulsteuerung StRS M-016,M-065 SyRS-003 J J belegt nein
|
||||||
|
StRS-015 Belegdruck/Berichte StRS M-080 SyRS-025 N J belegt nein
|
||||||
|
StRS-016 BW-Transparenz StRS M-097 SyRS-021 N J belegt nein
|
||||||
|
StRS-017 Integrierte Kommunikation StRS M-060,M-101,M-037 SyRS-035,SyRS-036,SyRS-030 N J belegt nein
|
||||||
|
StRS-018 Arbeitsorganisation StRS M-067,M-066 SyRS-029 N J belegt nein
|
||||||
|
StRS-019 Endkunden-Self-Service StRS M-130,M-093 SyRS-045,SyRS-002 N J belegt nein
|
||||||
|
StRS-020 Dokumente+Signatur StRS M-013,M-092 SyRS-026,SyRS-022 N J belegt nein
|
||||||
|
StRS-021 Konnektoren-Offenheit StRS M-071,M-044 SyRS-027 N J belegt nein
|
||||||
|
StRS-022 Kundengeraete-Ueberblick StRS M-045,M-046,M-084 SyRS-028 N J belegt Kandidat:Asset-Konzept
|
||||||
|
StRS-023 RMA StRS M-042 SyRS-028 N J belegt nein
|
||||||
|
StRS-024 Fertigung StRS M-077 SyRS-013 N J belegt nein
|
||||||
|
StRS-025 CRM/Projekte StRS M-078,M-076,M-105 SyRS-020 N J belegt Kandidat:Projektbegriffe
|
||||||
|
StRS-026 Marketing StRS M-062,M-088 SyRS-035 N J belegt nein
|
||||||
|
StRS-027 Zentrale Suche StRS M-056 SyRS-033 N J belegt nein
|
||||||
|
StRS-028 Kundenzugangsdaten StRS M-073,M-074 SyRS-017 J J belegt Kandidat:2 Passwortmodule
|
||||||
|
StRS-029 KI-Unterstuetzung StRS M-030,M-005 SyRS-019 N J belegt nein
|
||||||
|
StRS-030 DSGVO+Audit StRS M-012,M-036 SyRS-022,SyRS-009,SyRS-010 J J belegt nein
|
||||||
|
StRS-031 Automatisierter Betrieb StRS M-006,M-148,M-147,M-151 SyRS-018,SyRS-047,SyRS-048,SyRS-049 N J belegt nein
|
||||||
|
StRS-032 Anpassbarkeit StRS M-026,M-011,M-043 SyRS-023 N J belegt nein
|
||||||
|
StRS-033 Mehrfirmen-/Filialbetrieb StRS M-009,M-018 SyRS-024,SyRS-012 N J belegt nein
|
||||||
|
+4623
File diff suppressed because it is too large
Load Diff
+69
@@ -0,0 +1,69 @@
|
|||||||
|
## 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 | 33 | 13,7 % |
|
||||||
|
| SyRS | 50 | 20,7 % |
|
||||||
|
| SwRS | 158 | 65,6 % |
|
||||||
|
| **Gesamt** | **241** | 100 % |
|
||||||
|
|
||||||
|
### Anforderungstypen
|
||||||
|
|
||||||
|
| Typ | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| funktional | 133 | 55,2 % |
|
||||||
|
| Sicherheit | 32 | 13,3 % |
|
||||||
|
| Schnittstelle | 25 | 10,4 % |
|
||||||
|
| funktional (Abrechnung) | 19 | 7,9 % |
|
||||||
|
| nicht-funktional | 16 | 6,6 % |
|
||||||
|
| Daten | 12 | 5,0 % |
|
||||||
|
| Schnittstelle (Abrechnung) | 2 | 0,8 % |
|
||||||
|
| funktional (Abrechnung/Fakturierung) | 1 | 0,4 % |
|
||||||
|
| Sicherheit (Abrechnung) | 1 | 0,4 % |
|
||||||
|
|
||||||
|
### Belegqualität
|
||||||
|
|
||||||
|
| Messgröße | Wert |
|
||||||
|
|---|---:|
|
||||||
|
| Belege gesamt | 283 |
|
||||||
|
| davon `PRIMÄR` | 252 (89,0 %) |
|
||||||
|
| davon `SEKUNDÄR` | 18 (6,4 %) |
|
||||||
|
| davon `KONTEXT` | 13 (4,6 %) |
|
||||||
|
| Belege je Anforderung (Median) | 1 |
|
||||||
|
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 237 (98,3 %) |
|
||||||
|
|
||||||
|
### Übernahmewürdigkeit
|
||||||
|
|
||||||
|
| Einstufung | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| übernehmen | 218 | 90,5 % |
|
||||||
|
| workaround | 9 | 3,7 % |
|
||||||
|
| sonderfall | 7 | 2,9 % |
|
||||||
|
| veraltet | 7 | 2,9 % |
|
||||||
|
|
||||||
|
### Status
|
||||||
|
|
||||||
|
| Kategorie | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| belegt | 235 | 97,5 % |
|
||||||
|
| als `HYPOTHESE` gekennzeichnet | 6 | 2,5 % |
|
||||||
|
| als Workaround vermerkt | 0 | 0,0 % |
|
||||||
|
| Konsolidierungskandidaten | 41 | 17,0 % |
|
||||||
|
| mit ISO-25010-Qualitätsmerkmal | 16 | 6,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** (74 risikorelevante Anforderungen, alle gedeckt) |
|
||||||
|
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||||
|
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 241 Anforderungen eingestuft) |
|
||||||
|
| **Traceability** – Verknüpfung zwischen den Ebenen | 241 von 241 mit Tracelinks (100,0 %) |
|
||||||
|
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
|
||||||
+177
@@ -0,0 +1,177 @@
|
|||||||
|
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
|
||||||
|
|
||||||
|
## Metadaten
|
||||||
|
- **Versuch:** V1 Baseline (Prompt-only)
|
||||||
|
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
|
||||||
|
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||||
|
- **Zeitstempel:** 2026-08-26
|
||||||
|
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
|
||||||
|
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||||
|
|
||||||
|
| Änderung | Auslösender Befund |
|
||||||
|
|---|---|
|
||||||
|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
|
||||||
|
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
|
||||||
|
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
|
||||||
|
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
|
||||||
|
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
|
||||||
|
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
|
||||||
|
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
|
||||||
|
|
||||||
|
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
|
||||||
|
|
||||||
|
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||||
|
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||||
|
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Prompt
|
||||||
|
|
||||||
|
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||||
|
|
||||||
|
### Auftrag
|
||||||
|
|
||||||
|
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||||
|
|
||||||
|
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||||
|
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||||
|
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||||
|
|
||||||
|
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||||
|
|
||||||
|
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||||
|
|
||||||
|
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
**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. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
|
||||||
|
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||||
|
|
||||||
|
### Formatvorgabe pro Anforderung
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||||
|
Titel: <kurzer Titel>
|
||||||
|
Ebene: <StRS | SyRS | SwRS>
|
||||||
|
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||||
|
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)
|
||||||
|
|
||||||
|
```
|
||||||
|
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)
|
||||||
|
```
|
||||||
|
|
||||||
|
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?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||||
|
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
|
||||||
|
Kommandozeilenbefehlen im Arbeitsverzeichnis.
|
||||||
|
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
|
||||||
|
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||||
|
Werkzeuge zu ersetzen.
|
||||||
|
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||||
|
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||||
|
`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-fable-5\solo\high\02_Lauf_2026-08-27_002430_v7.0.0-35a4\Ergebnisse\`.
|
||||||
|
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-27T07:28:28.0825221+02:00
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-27T00:24:41.6237308+02:00
|
||||||
+150
@@ -0,0 +1,150 @@
|
|||||||
|
M-001 2
|
||||||
|
M-002 3
|
||||||
|
M-003 3
|
||||||
|
M-004 1
|
||||||
|
M-005 3
|
||||||
|
M-006 3
|
||||||
|
M-007 1
|
||||||
|
M-008 1
|
||||||
|
M-009 3
|
||||||
|
M-010 1
|
||||||
|
M-011 2
|
||||||
|
M-012 3
|
||||||
|
M-013 3
|
||||||
|
M-014 1
|
||||||
|
M-015 1
|
||||||
|
M-016 3
|
||||||
|
M-017 9
|
||||||
|
M-018 4
|
||||||
|
M-019 1
|
||||||
|
M-020 1
|
||||||
|
M-021 1
|
||||||
|
M-022 2
|
||||||
|
M-023 1
|
||||||
|
M-024 7
|
||||||
|
M-025 1
|
||||||
|
M-026 4
|
||||||
|
M-027 1
|
||||||
|
M-028 1
|
||||||
|
M-029 1
|
||||||
|
M-030 2
|
||||||
|
M-031 1
|
||||||
|
M-032 1
|
||||||
|
M-033 3
|
||||||
|
M-034 1
|
||||||
|
M-035 1
|
||||||
|
M-036 3
|
||||||
|
M-037 2
|
||||||
|
M-038 1
|
||||||
|
M-039 4
|
||||||
|
M-040 1
|
||||||
|
M-041 1
|
||||||
|
M-042 2
|
||||||
|
M-043 2
|
||||||
|
M-044 7
|
||||||
|
M-045 3
|
||||||
|
M-046 3
|
||||||
|
M-047 1
|
||||||
|
M-048 4
|
||||||
|
M-049 1
|
||||||
|
M-050 1
|
||||||
|
M-051 1
|
||||||
|
M-052 1
|
||||||
|
M-053 6
|
||||||
|
M-054 1
|
||||||
|
M-055 1
|
||||||
|
M-056 3
|
||||||
|
M-057 1
|
||||||
|
M-058 1
|
||||||
|
M-059 2
|
||||||
|
M-060 4
|
||||||
|
M-061 2
|
||||||
|
M-062 2
|
||||||
|
M-063 2
|
||||||
|
M-064 1
|
||||||
|
M-065 2
|
||||||
|
M-066 3
|
||||||
|
M-067 4
|
||||||
|
M-068 1
|
||||||
|
M-069 1
|
||||||
|
M-070 1
|
||||||
|
M-071 2
|
||||||
|
M-072 1
|
||||||
|
M-073 2
|
||||||
|
M-074 2
|
||||||
|
M-075 1
|
||||||
|
M-076 2
|
||||||
|
M-077 2
|
||||||
|
M-078 2
|
||||||
|
M-079 2
|
||||||
|
M-080 3
|
||||||
|
M-081 1
|
||||||
|
M-082 1
|
||||||
|
M-083 16
|
||||||
|
M-084 11
|
||||||
|
M-085 1
|
||||||
|
M-086 11
|
||||||
|
M-087 4
|
||||||
|
M-088 2
|
||||||
|
M-089 1
|
||||||
|
M-090 1
|
||||||
|
M-091 1
|
||||||
|
M-092 2
|
||||||
|
M-093 2
|
||||||
|
M-094 1
|
||||||
|
M-095 1
|
||||||
|
M-096 1
|
||||||
|
M-097 2
|
||||||
|
M-098 2
|
||||||
|
M-099 1
|
||||||
|
M-100 1
|
||||||
|
M-101 3
|
||||||
|
M-102 1
|
||||||
|
M-103 1
|
||||||
|
M-104 1
|
||||||
|
M-105 2
|
||||||
|
M-106 1
|
||||||
|
M-107 2
|
||||||
|
M-108 1
|
||||||
|
M-109 1
|
||||||
|
M-110 1
|
||||||
|
M-111 1
|
||||||
|
M-112 1
|
||||||
|
M-113 1
|
||||||
|
M-114 1
|
||||||
|
M-115 4
|
||||||
|
M-116 1
|
||||||
|
M-117 1
|
||||||
|
M-118 1
|
||||||
|
M-119 1
|
||||||
|
M-120 1
|
||||||
|
M-121 1
|
||||||
|
M-122 1
|
||||||
|
M-123 1
|
||||||
|
M-124 1
|
||||||
|
M-125 1
|
||||||
|
M-126 2
|
||||||
|
M-127 2
|
||||||
|
M-128 1
|
||||||
|
M-129 1
|
||||||
|
M-130 5
|
||||||
|
M-131 1
|
||||||
|
M-132 1
|
||||||
|
M-133 3
|
||||||
|
M-134 1
|
||||||
|
M-135 1
|
||||||
|
M-136 1
|
||||||
|
M-137 1
|
||||||
|
M-138 3
|
||||||
|
M-139 3
|
||||||
|
M-140 1
|
||||||
|
M-141 1
|
||||||
|
M-142 1
|
||||||
|
M-143 1
|
||||||
|
M-144 1
|
||||||
|
M-145 1
|
||||||
|
M-146 1
|
||||||
|
M-147 3
|
||||||
|
M-148 4
|
||||||
|
M-149 2
|
||||||
|
M-151 2
|
||||||
+192
@@ -0,0 +1,192 @@
|
|||||||
|
## Abdeckungstabelle (je Modul des Inventars)
|
||||||
|
|
||||||
|
Einstufung: `tief` = mehrere Anforderungen inkl. gelesener Kernlogik der risikorelevanten Pfade; `mittel` = 2-3 Anforderungen auf Basis gelesener Kernmethoden; `flach` = 1-2 Anforderungen auf Basis von Methodensignaturen/ausgewählten Codeausschnitten; `nicht analysiert` = keine Anforderung (mit Begründung).
|
||||||
|
|
||||||
|
| Modul | Bezeichnung | Einstufung | Anzahl Anforderungen | Anforderungen |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M-001 | Accounting (Bankkonten) | mittel | 2 | SwRS-019, SwRS-155 |
|
||||||
|
| M-002 | Accounts (Konten-/Adressstamm) | mittel | 3 | SwRS-020, SyRS-020, StRS-001 |
|
||||||
|
| M-003 | Administration: AccessTokens | mittel | 3 | SyRS-017, SwRS-021, StRS-013 |
|
||||||
|
| M-004 | Administration: Applications | flach | 1 | SwRS-022 |
|
||||||
|
| M-005 | Administration: ArtificialIntelligence | mittel | 3 | SyRS-019, SwRS-023, StRS-029 |
|
||||||
|
| M-006 | Administration: BackgroundServices | mittel | 3 | SyRS-018, SwRS-024, StRS-031 |
|
||||||
|
| M-007 | Administration: BookKeepingAccountSystems | flach | 1 | SwRS-025 |
|
||||||
|
| M-008 | Administration: CentronConfigDb | flach | 1 | SwRS-026 |
|
||||||
|
| M-009 | Administration: Company/CompanyInformations | mittel | 3 | SyRS-024, SwRS-027, StRS-033 |
|
||||||
|
| M-010 | Administration: Connections | flach | 1 | SwRS-028 |
|
||||||
|
| M-011 | Administration: Customization | mittel | 2 | SwRS-029, StRS-032 |
|
||||||
|
| M-012 | Administration: DataSecurity | mittel | 3 | SyRS-022, SwRS-030, StRS-030 |
|
||||||
|
| M-013 | Administration: Documents/FileManagement | mittel | 3 | SwRS-031, SyRS-026, StRS-020 |
|
||||||
|
| M-014 | Administration: Employees | flach | 1 | SwRS-032 |
|
||||||
|
| M-015 | Administration: Environments | flach | 1 | SwRS-033 |
|
||||||
|
| M-016 | Administration: Licensing | tief | 3 | SyRS-003, SwRS-009, StRS-014 |
|
||||||
|
| M-017 | Administration: Logins/Auth | tief | 9 | SyRS-003, SyRS-004, SyRS-005, SyRS-006, SyRS-007, SwRS-002, SwRS-003, SwRS-005, StRS-013 |
|
||||||
|
| M-018 | Administration: Mandatory | mittel | 4 | SyRS-012, SwRS-012, SyRS-024, StRS-033 |
|
||||||
|
| M-019 | Administration: Masterdata | flach | 1 | SwRS-034 |
|
||||||
|
| M-020 | Administration: NetworkDiagnostics | flach | 1 | SwRS-035 |
|
||||||
|
| M-021 | Administration: PerformanceTests/Profiling | flach | 1 | SwRS-036 |
|
||||||
|
| M-022 | Administration: PhoneSettings | mittel | 2 | SwRS-037, SyRS-030 |
|
||||||
|
| M-023 | Administration: Portal | flach | 1 | SwRS-038 |
|
||||||
|
| M-024 | Administration: Rights | tief | 7 | SyRS-001, SyRS-002, SyRS-008, SwRS-001, SwRS-004, SwRS-008, StRS-012 |
|
||||||
|
| M-025 | Administration: Scripts/SQLManagement | flach | 1 | SwRS-039 |
|
||||||
|
| M-026 | Administration: Settings | mittel | 4 | SyRS-023, SwRS-040, SyRS-050, StRS-032 |
|
||||||
|
| M-027 | Administration: Themes | flach | 1 | SwRS-041 |
|
||||||
|
| M-028 | Administration: WebServiceConfiguration | flach | 1 | SwRS-042 |
|
||||||
|
| M-029 | AppointmentRequests | flach | 1 | SwRS-043 |
|
||||||
|
| M-030 | ArtificialIntelligence | mittel | 2 | SyRS-019, StRS-029 |
|
||||||
|
| M-031 | BusinessPartner | flach | 1 | SwRS-044 |
|
||||||
|
| M-032 | Buying | flach | 1 | SwRS-045 |
|
||||||
|
| M-033 | Calendar | mittel | 3 | SwRS-046, SyRS-029, SwRS-157 |
|
||||||
|
| M-034 | CentronIcons | flach | 1 | SwRS-047 |
|
||||||
|
| M-035 | CentronNexus (BL) | flach | 1 | SwRS-048 |
|
||||||
|
| M-036 | ChangeTracking | mittel | 3 | SyRS-009, SwRS-007, StRS-030 |
|
||||||
|
| M-037 | Chats | mittel | 2 | SwRS-049, StRS-017 |
|
||||||
|
| M-038 | CheckListArea | flach | 1 | SwRS-050 |
|
||||||
|
| M-039 | Core (BL-Kern) | mittel | 4 | SyRS-009, SyRS-010, SwRS-006, SwRS-007 |
|
||||||
|
| M-040 | CountryArea | flach | 1 | SwRS-051 |
|
||||||
|
| M-041 | CPra | flach | 1 | SwRS-052 |
|
||||||
|
| M-042 | CustomerArea | mittel | 2 | SwRS-059, StRS-023 |
|
||||||
|
| M-043 | Customizations (CustomTables) | mittel | 2 | SwRS-053, StRS-032 |
|
||||||
|
| M-044 | DataExchange | tief | 7 | SyRS-021, SwRS-057, SwRS-058, SyRS-043, StRS-009, StRS-010, StRS-021 |
|
||||||
|
| M-045 | Devices | mittel | 3 | SwRS-054, SyRS-028, StRS-022 |
|
||||||
|
| M-046 | DocuBoard | mittel | 3 | SwRS-055, SyRS-028, StRS-022 |
|
||||||
|
| M-047 | DocumentationArea | flach | 1 | SwRS-056 |
|
||||||
|
| M-048 | EDI | mittel | 4 | SyRS-027, SwRS-060, StRS-007, StRS-010 |
|
||||||
|
| M-049 | EmployeeArea | flach | 1 | SwRS-061 |
|
||||||
|
| M-050 | ExpectedEvents | flach | 1 | SwRS-062 |
|
||||||
|
| M-051 | ExternalHelpdesk | flach | 1 | SwRS-063 |
|
||||||
|
| M-052 | ExternalToolsBL | flach | 1 | SwRS-064 |
|
||||||
|
| M-053 | Finances | tief | 6 | SyRS-032, SwRS-065, SwRS-066, SyRS-050, SwRS-155, StRS-009 |
|
||||||
|
| M-054 | Gateway (BL) | flach | 1 | SwRS-067 |
|
||||||
|
| M-055 | GUI (BL-Anteil) | flach | 1 | SwRS-134 |
|
||||||
|
| M-056 | IndexSearch | mittel | 3 | SyRS-033, SwRS-068, StRS-027 |
|
||||||
|
| M-057 | Integrations | flach | 1 | SwRS-069 |
|
||||||
|
| M-058 | ItPlanner | flach | 1 | SwRS-070 |
|
||||||
|
| M-059 | Logistics | mittel | 2 | SwRS-071, StRS-008 |
|
||||||
|
| M-060 | Mail | mittel | 4 | SyRS-035, SwRS-072, SwRS-157, StRS-017 |
|
||||||
|
| M-061 | MailScanner | mittel | 2 | SyRS-036, SwRS-073 |
|
||||||
|
| M-062 | Mailings | mittel | 2 | SwRS-074, StRS-026 |
|
||||||
|
| M-063 | MassUpdate | mittel | 2 | SyRS-034, SwRS-075 |
|
||||||
|
| M-064 | Mobile | flach | 1 | SwRS-076 |
|
||||||
|
| M-065 | Modules | mittel | 2 | SwRS-077, StRS-014 |
|
||||||
|
| M-066 | MyCentron | mittel | 3 | SyRS-029, SwRS-078, StRS-018 |
|
||||||
|
| M-067 | MyDay | mittel | 4 | SyRS-029, SwRS-079, SwRS-158, StRS-018 |
|
||||||
|
| M-068 | NexusNotifications | flach | 1 | SwRS-080 |
|
||||||
|
| M-069 | NexusTicketViews | flach | 1 | SwRS-081 |
|
||||||
|
| M-070 | Notifications | flach | 1 | SwRS-082 |
|
||||||
|
| M-071 | ObjectExternalReferences | mittel | 2 | SwRS-083, StRS-021 |
|
||||||
|
| M-072 | Outlook | flach | 1 | SwRS-084 |
|
||||||
|
| M-073 | PasswordManagementArea | mittel | 2 | SwRS-085, StRS-028 |
|
||||||
|
| M-074 | PasswordManager | mittel | 2 | SwRS-086, StRS-028 |
|
||||||
|
| M-075 | Processes | flach | 1 | SwRS-087 |
|
||||||
|
| M-076 | ProductMatrix | mittel | 2 | SwRS-088, StRS-025 |
|
||||||
|
| M-077 | Production | mittel | 2 | SwRS-089, StRS-024 |
|
||||||
|
| M-078 | Projects | mittel | 2 | SwRS-090, StRS-025 |
|
||||||
|
| M-079 | Purchasing | mittel | 2 | SwRS-091, StRS-007 |
|
||||||
|
| M-080 | ReportEngine | mittel | 3 | SyRS-025, SyRS-043, StRS-015 |
|
||||||
|
| M-081 | Reporting | flach | 1 | SyRS-025 |
|
||||||
|
| M-082 | RiverDivo | flach | 1 | SwRS-101 |
|
||||||
|
| M-083 | Sales: Receipts (Belegwesen) | tief | 16 | SyRS-011, SyRS-012, SyRS-013, SyRS-014, SyRS-015, SyRS-016, SwRS-010, SwRS-013, SwRS-014, SwRS-015, SwRS-016, SwRS-017, SwRS-018, SwRS-154, StRS-002, StRS-003 |
|
||||||
|
| M-084 | Sales: CustomerAssets (Verträge) | tief | 11 | SyRS-028, SyRS-037, SyRS-038, SyRS-039, SwRS-092, SwRS-093, SwRS-094, SwRS-095, StRS-004, StRS-006, StRS-022 |
|
||||||
|
| M-085 | Sales: Customers (CRM) | flach | 1 | SwRS-102 |
|
||||||
|
| M-086 | Sales: Support (Helpdesk) | tief | 11 | SyRS-039, SyRS-040, SyRS-041, SwRS-095, SwRS-096, SwRS-097, SwRS-098, SwRS-099, SwRS-156, StRS-005, StRS-006 |
|
||||||
|
| M-087 | Sales: CashBooks | tief | 4 | SyRS-042, SwRS-100, StRS-003, StRS-009 |
|
||||||
|
| M-088 | Sales: Marketing | mittel | 2 | SwRS-103, StRS-026 |
|
||||||
|
| M-089 | Sales: Calendar | flach | 1 | SwRS-104 |
|
||||||
|
| M-090 | Sales: DocumentationWizardArea | flach | 1 | SwRS-105 |
|
||||||
|
| M-091 | Sales: HourlySurchargeRatesBL | flach | 1 | SwRS-106 |
|
||||||
|
| M-092 | Security (PdfSigning) | mittel | 2 | SwRS-107, StRS-020 |
|
||||||
|
| M-093 | SelfCare | mittel | 2 | SwRS-108, StRS-019 |
|
||||||
|
| M-094 | Services | flach | 1 | SwRS-109 |
|
||||||
|
| M-095 | SocialMedia | flach | 1 | SwRS-110 |
|
||||||
|
| M-096 | Start | flach | 1 | SwRS-111 |
|
||||||
|
| M-097 | Statistics | mittel | 2 | SwRS-135, StRS-016 |
|
||||||
|
| M-098 | Storage | mittel | 2 | SwRS-112, StRS-008 |
|
||||||
|
| M-099 | SystemArea | flach | 1 | SwRS-113 |
|
||||||
|
| M-100 | Tags | flach | 1 | SwRS-114 |
|
||||||
|
| M-101 | Tapi | mittel | 3 | SyRS-030, SwRS-115, StRS-017 |
|
||||||
|
| M-102 | TaskManager | flach | 1 | SwRS-116 |
|
||||||
|
| M-103 | Telemetry | flach | 1 | SwRS-117 |
|
||||||
|
| M-104 | TextModuleArea | flach | 1 | SwRS-118 |
|
||||||
|
| M-105 | TicketProjects | mittel | 2 | SwRS-119, StRS-025 |
|
||||||
|
| M-106 | Time | flach | 1 | SwRS-120 |
|
||||||
|
| M-107 | ToDoArea | mittel | 2 | SyRS-029, SwRS-121 |
|
||||||
|
| M-108 | Tools | flach | 1 | SwRS-122 |
|
||||||
|
| M-109 | TradePool | flach | 1 | SwRS-123 |
|
||||||
|
| M-110 | Transactions | flach | 1 | SwRS-124 |
|
||||||
|
| M-111 | TwoFactorAuthenticator | flach | 1 | SwRS-011 |
|
||||||
|
| M-112 | Urls | flach | 1 | SwRS-125 |
|
||||||
|
| M-113 | VideoPortal | flach | 1 | SwRS-126 |
|
||||||
|
| M-114 | VoucherManagement | flach | 1 | SwRS-127 |
|
||||||
|
| M-115 | Warehousing | mittel | 4 | SyRS-013, SwRS-014, SwRS-128, StRS-008 |
|
||||||
|
| M-116 | WebLinks | flach | 1 | SwRS-129 |
|
||||||
|
| M-117 | WebServices (BL) | flach | 1 | SwRS-136 |
|
||||||
|
| M-118 | WebSuite | flach | 1 | SwRS-130 |
|
||||||
|
| M-119 | WebVersion | flach | 1 | SwRS-131 |
|
||||||
|
| M-120 | Helpers (BL) | flach | 1 | SwRS-132 |
|
||||||
|
| M-121 | Exceptions (BL) | flach | 1 | SwRS-133 |
|
||||||
|
| M-122 | Centron.DAO (Persistenz) | flach | 1 | SwRS-137 |
|
||||||
|
| M-123 | Centron.Entities | flach | 1 | SwRS-138 |
|
||||||
|
| M-124 | Centron.Common | flach | 1 | SwRS-139 |
|
||||||
|
| M-125 | Centron.Interfaces | flach | 1 | SwRS-140 |
|
||||||
|
| M-126 | Centron.Gateway | mittel | 2 | SyRS-043, SwRS-141 |
|
||||||
|
| M-127 | Centron.WPF.UI (+ Extension) | mittel | 2 | SyRS-031, SwRS-142 |
|
||||||
|
| M-128 | Centron.Controls (+ Preview) | flach | 1 | SwRS-143 |
|
||||||
|
| M-129 | Centron.Core (shared) | flach | 1 | SwRS-144 |
|
||||||
|
| M-130 | CentronNexus (Blazor-Web) | mittel | 5 | SyRS-031, SyRS-045, SwRS-145, SwRS-156, StRS-019 |
|
||||||
|
| M-131 | CentronNexus.Host | flach | 1 | SwRS-145 |
|
||||||
|
| M-132 | CentronNexus.OutlookAddIn | flach | 1 | SwRS-145 |
|
||||||
|
| M-133 | Centron.Controllers (REST-API) | mittel | 3 | SyRS-031, SyRS-046, SwRS-147 |
|
||||||
|
| M-134 | Centron.WebServices.Core | flach | 1 | SwRS-146 |
|
||||||
|
| M-135 | Centron.Host (+ Console/WindowsService) | flach | 1 | SwRS-146 |
|
||||||
|
| M-136 | ConnectionManager | flach | 1 | SwRS-146 |
|
||||||
|
| M-137 | Centron.Api.EbInterface | flach | 1 | SyRS-043 |
|
||||||
|
| M-138 | Centron.Api.Gls | mittel | 3 | SyRS-044, SwRS-151, StRS-011 |
|
||||||
|
| M-139 | Centron.Api.Shipcloud | mittel | 3 | SyRS-044, SwRS-151, StRS-011 |
|
||||||
|
| M-140 | Centron.APIs.CopDataAccess | flach | 1 | SwRS-148 |
|
||||||
|
| M-141 | Centron.APIs.EgisDataAccess | flach | 1 | SwRS-148 |
|
||||||
|
| M-142 | Centron.APIs.FinAPI | flach | 1 | SwRS-149 |
|
||||||
|
| M-143 | Centron.APIs.IcecatDataAccess | flach | 1 | SwRS-148 |
|
||||||
|
| M-144 | Centron.APIs.ITscopeDataAccess | flach | 1 | SwRS-148 |
|
||||||
|
| M-145 | Centron.Api.docuFORM | flach | 1 | SwRS-150 |
|
||||||
|
| M-146 | Datenbankschema | flach | 1 | SwRS-152 |
|
||||||
|
| M-147 | Deployment/Installer | mittel | 3 | SyRS-048, SwRS-153, StRS-031 |
|
||||||
|
| M-148 | Docker/Betrieb | mittel | 4 | SyRS-047, SyRS-049, SwRS-153, StRS-031 |
|
||||||
|
| M-149 | Scripts | mittel | 2 | SyRS-048, SwRS-153 |
|
||||||
|
| M-150 | Dokumentation | nicht analysiert | 0 | – (reine Entwickler-/Betriebsdokumentation ohne eigene Systemfunktion; als KONTEXT-Belegquelle genutzt, z. B. für SyRS-043, SwRS-157) |
|
||||||
|
| M-151 | Tests | mittel | 2 | SyRS-049, StRS-031 |
|
||||||
|
|
||||||
|
**Summen:** tief: 9 Module, mittel: 58, flach: 83, nicht analysiert: 1 (gesamt 151 Module).
|
||||||
|
|
||||||
|
## Konsistenzcheck
|
||||||
|
|
||||||
|
Automatisiert über alle drei Spezifikationsdateien ausgeführt (241 Anforderungsblöcke):
|
||||||
|
|
||||||
|
| Prüfung | Ergebnis |
|
||||||
|
|---|---|
|
||||||
|
| Doppelte oder mehrfach vergebene IDs | keine (241 eindeutige IDs: 33 StRS, 50 SyRS, 158 SwRS) |
|
||||||
|
| Anforderungen ohne Beleg | keine (jeder Block enthält mind. einen klassifizierten Beleg) |
|
||||||
|
| Anforderungen ohne Übernahmewürdigkeit | keine |
|
||||||
|
| Anforderungen ohne Prüfidee | keine |
|
||||||
|
| Tracelinks auf nicht existierende IDs | keine |
|
||||||
|
| SwRS ohne SyRS-Referenz / SyRS ohne StRS-Referenz | keine (siehe Traceability.md) |
|
||||||
|
| Abgleich Hypothesen.md ↔ Inline-Markierungen | deckungsgleich: SyRS-050, SwRS-154, SwRS-155, SwRS-156, SwRS-157, SwRS-158 (6 Stück) |
|
||||||
|
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk | keine gefundenen; erkannte fachliche Doppelimplementierungen sind als Konsolidierungskandidaten markiert (siehe Liste unten) |
|
||||||
|
|
||||||
|
**Wesentliche Konsolidierungskandidaten (fachlich gleiche Konzepte in getrennten Implementierungen):**
|
||||||
|
|
||||||
|
1. Gerätedatenhaltungen: AccountDevices (M-045) vs. CustomerAssets/„Stammblätter" (M-084) vs. DocuBoard-Assetmanagement (M-046) → ein Asset-Konzept (SyRS-028, StRS-022).
|
||||||
|
2. Zwei Belegmodelle: Sales/Receipts (neu) vs. Sales/CustomerAssets (alt) für dieselben Belegarten (SyRS-011).
|
||||||
|
3. Zwei Rechtemodelle: interne Rechte (Sichtrus/Sichmemb) vs. WebAccountsRights (SyRS-001/SyRS-002).
|
||||||
|
4. Drei 2FA-Wege: RADIUS, E-Mail-Link, TOTP (SyRS-005, SwRS-011).
|
||||||
|
5. Zwei Passwortverwaltungen: PasswordManagementArea vs. PasswordManager (SwRS-085/SwRS-086).
|
||||||
|
6. Zwei Workflow-/Prozess-Engines: Processes vs. Services/Workflows (SwRS-087/SwRS-109); zusätzlich MailScanner-Workflows (SyRS-036).
|
||||||
|
7. Zwei Customizing-Mechanismen: Custom Properties vs. Custom Tables (SwRS-029/SwRS-053).
|
||||||
|
8. Drei Projektbegriffe: Projects, CrmProjects, TicketProjects (SwRS-090/SwRS-119, StRS-025).
|
||||||
|
9. Zwei Aufgabenkonzepte: ToDoArea vs. TaskManager (SwRS-116/SwRS-121).
|
||||||
|
10. Zwei Benachrichtigungssysteme: Notifications vs. NexusNotifications (SwRS-080/SwRS-082).
|
||||||
|
11. EDI-Logik doppelt: Centron.BL/EDI vs. Centron.Gateway/EDI_* (SyRS-027/SwRS-141).
|
||||||
|
12. Bankverbindungen doppelt: Felder in Tabelle Kunden vs. BankAccount-Objekte (SwRS-152/SwRS-019).
|
||||||
|
13. Zwei Endkunden-Formularwege: SelfCare vs. Nexus-Kundenportal-Formulare (SwRS-108/SyRS-045).
|
||||||
|
14. Versandwege GLS-direkt vs. Shipcloud (SyRS-044).
|
||||||
|
15. Desktop-Client (WPF) vs. Nexus-Web-UI für dieselben Prozesse (SyRS-031, SwRS-142/SwRS-145).
|
||||||
+83
@@ -0,0 +1,83 @@
|
|||||||
|
## Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
|
||||||
|
|
||||||
|
75 Anforderungen sind risikorelevant. Belegsituation:
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR-Beleg vorhanden | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| SyRS-001 | Gruppenbasierte Benutzerrechtepruefung | ja | belegt |
|
||||||
|
| SyRS-002 | Getrenntes Rechtemodell fuer Web-Accounts | ja | belegt |
|
||||||
|
| SyRS-003 | Ticketbasierte Sitzungen mit Lizenzpruefung | ja | belegt |
|
||||||
|
| SyRS-004 | Mehrere Authentifizierungsverfahren | ja | belegt |
|
||||||
|
| SyRS-005 | Zwei-Faktor-Authentifizierung | ja | belegt |
|
||||||
|
| SyRS-006 | Zeitgesteuerte Kontodeaktivierung | ja | belegt |
|
||||||
|
| SyRS-007 | Anwendungsbezogene Anmelderechte | ja | belegt |
|
||||||
|
| SyRS-008 | Standard-Rechtegruppen | ja | belegt |
|
||||||
|
| SwRS-001 | Rechteermittlung SQL+Cache | ja | belegt |
|
||||||
|
| SwRS-002 | Passwort SHA1 ungesalzen | ja | belegt |
|
||||||
|
| SwRS-003 | 2FA-Validatorwahl | ja | belegt |
|
||||||
|
| SwRS-004 | Rechtegruppenverwaltung | ja | belegt |
|
||||||
|
| SwRS-005 | Ticket-Wiederverwendung+LoginIP | ja | belegt |
|
||||||
|
| SwRS-008 | Standardrechtegruppen aus Ressource | ja | belegt |
|
||||||
|
| SwRS-009 | Signaturvalidierte Lizenzdatei | ja | belegt |
|
||||||
|
| SyRS-011 | Belegkette Weiterfuehrungswege | ja | belegt |
|
||||||
|
| SyRS-012 | Nummernkreise je Mandant/Filiale | ja | belegt |
|
||||||
|
| SyRS-013 | Bestandswirkung der Belege | ja | belegt |
|
||||||
|
| SyRS-014 | Mindestpreisschutz | ja | belegt |
|
||||||
|
| SwRS-010 | Belegnummernvergabe+Templatekunde | ja | belegt |
|
||||||
|
| SwRS-011 | TOTP-Zweitfaktor | ja | belegt |
|
||||||
|
| SwRS-012 | Nummernkreis-Kaskade | ja | belegt |
|
||||||
|
| SwRS-014 | Negativbuchung nur mit Recht | ja | belegt |
|
||||||
|
| SwRS-015 | Mindestpreis-Reauth | ja | belegt |
|
||||||
|
| SyRS-017 | API-Zugriffstokens | ja | belegt |
|
||||||
|
| SwRS-019 | Bankverbindungen Rechte+Default | ja | belegt |
|
||||||
|
| SwRS-020 | Kontenstamm Rechte+FiBu-Nummer | ja | belegt |
|
||||||
|
| SwRS-021 | API-Token Hash+Ablauf+Log | ja | belegt |
|
||||||
|
| SwRS-026 | Konfig-DB Masterkey | ja | belegt |
|
||||||
|
| SyRS-022 | DSGVO Loeschkonzept | ja | belegt |
|
||||||
|
| SwRS-027 | Kollisionssichere Nummernvergabe | ja | belegt |
|
||||||
|
| SwRS-030 | DSGVO-Kontaktloeschung | ja | belegt |
|
||||||
|
| SyRS-021 | FiBu-Uebergabe DATEV | ja | belegt |
|
||||||
|
| SwRS-057 | FiBu-Exportkonfigurationen | ja | belegt |
|
||||||
|
| SwRS-058 | Doppeluebergabeschutz FiBu | ja | belegt |
|
||||||
|
| SyRS-032 | Onlinebanking-Zahlungsabgleich | ja | belegt |
|
||||||
|
| SwRS-065 | Zahlungseingangsprotokoll | ja | belegt |
|
||||||
|
| SwRS-066 | Bankumsatz-Zuordnung/Buchung | ja | belegt |
|
||||||
|
| SwRS-085 | Kundenzugangsdaten+Logs | ja | belegt |
|
||||||
|
| SwRS-086 | Passwortmanager Siegel | ja | belegt |
|
||||||
|
| SyRS-037 | Vertragsverwaltung Laufzeit/Intervalle | ja | belegt |
|
||||||
|
| SyRS-038 | Automatische Vertragsfakturierung | ja | belegt |
|
||||||
|
| SyRS-039 | Timer-Billing | ja | belegt |
|
||||||
|
| SyRS-040 | Helpdesk Rechte+Status | ja | belegt |
|
||||||
|
| SyRS-042 | Kassenbuch | ja | belegt |
|
||||||
|
| SwRS-092 | Vertrags-Datumsarithmetik | ja | belegt |
|
||||||
|
| SwRS-093 | Auto-Vertragsschliessen | ja | belegt |
|
||||||
|
| SwRS-094 | Abrechnungsfaellige Kunden+Zaehler | ja | belegt |
|
||||||
|
| SwRS-095 | Timer-Belegerzeugung | ja | belegt |
|
||||||
|
| SwRS-096 | Ticket-Rechtepruefung Save | ja | belegt |
|
||||||
|
| SwRS-097 | Ticket-Sichtbarkeit restriktiv | ja | belegt |
|
||||||
|
| SwRS-100 | Kassenbuchbuchung | ja | belegt |
|
||||||
|
| SwRS-101 | Riverbird-Ticketvalidierung | ja | belegt |
|
||||||
|
| SwRS-106 | Stundenzuschlagssaetze | ja | belegt |
|
||||||
|
| SwRS-107 | PDF-Signatur | ja | belegt |
|
||||||
|
| SwRS-112 | Inventur | ja | belegt |
|
||||||
|
| SwRS-127 | Gutscheinverwaltung | ja | belegt |
|
||||||
|
| SyRS-043 | E-Rechnungsformate | ja | belegt |
|
||||||
|
| SyRS-046 | REST-API Rechteautorisierung | ja | belegt |
|
||||||
|
| SwRS-144 | Core-Bibliothek TOTP | ja | belegt |
|
||||||
|
| SwRS-147 | Versionierte Controller | ja | belegt |
|
||||||
|
| SwRS-149 | finAPI-Client | ja | belegt |
|
||||||
|
| SyRS-050 | [HYPOTHESE] Mahnwesen | nein | HYPOTHESE |
|
||||||
|
| SwRS-154 | [HYPOTHESE] Anzahlungsverrechnung | ja | HYPOTHESE |
|
||||||
|
| SwRS-155 | [HYPOTHESE] SEPA-Lastschrift | ja | HYPOTHESE |
|
||||||
|
| StRS-003 | Geschuetzte Fakturierung | ja | belegt |
|
||||||
|
| StRS-004 | Vertragsgeschaeft | ja | belegt |
|
||||||
|
| StRS-006 | Leistungserfassung | ja | belegt |
|
||||||
|
| StRS-009 | Finanzprozesse | ja | belegt |
|
||||||
|
| StRS-010 | E-Belegaustausch | ja | belegt |
|
||||||
|
| StRS-012 | Berechtigungssteuerung | ja | belegt |
|
||||||
|
| StRS-013 | Sichere Anmeldung/API | ja | belegt |
|
||||||
|
| StRS-014 | Lizenz-/Modulsteuerung | ja | belegt |
|
||||||
|
| StRS-028 | Kundenzugangsdaten | ja | belegt |
|
||||||
|
| StRS-030 | DSGVO+Audit | ja | belegt |
|
||||||
|
|
||||||
|
**Regelprüfung:** Alle risikorelevanten Anforderungen besitzen entweder einen PRIMÄR-Beleg mit benannter durchsetzender Stelle oder sind als `[HYPOTHESE]` gekennzeichnet (betrifft SyRS-050 Mahnwesen). Kein Verstoß gegen die risikobasierte Priorisierung.
|
||||||
+606
@@ -0,0 +1,606 @@
|
|||||||
|
# Analysebericht – Reverse Requirements Engineering c-entron ERP-Suite
|
||||||
|
|
||||||
|
**Lauf:** 02_Lauf_2026-08-27_081235_v7.0.0-3021
|
||||||
|
**Codebasis:** `C:\DEV\MasterArbeit\QuellCode\CentronERP` (nur lesend analysiert)
|
||||||
|
**Methode:** Statische Analyse (RRE-Schritte 0, 2–6), keine Ausführung
|
||||||
|
**Datum:** 2026-08-27
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Kennzahlen der Codebasis (erhoben in Schritt 0)
|
||||||
|
|
||||||
|
| Kennzahl | Wert | Quelle |
|
||||||
|
|---|---|---|
|
||||||
|
| C#-Dateien (src, ohne bin/obj) | ~14.200 | Verzeichniszählung `src/**`.cs |
|
||||||
|
| Projekte in `Centron.sln` | 46 Code-Projekte (+ Setup/Doku-Ordner) | `Centron.sln` |
|
||||||
|
| DB-Tabellen | 1.558 `CREATE TABLE` | `SSMS_DB_SCHEMA.sql` |
|
||||||
|
| DB-Views | 182 `CREATE VIEW` | `SSMS_DB_SCHEMA.sql` |
|
||||||
|
| FK-Constraints | 134 | `SSMS_DB_SCHEMA.sql` |
|
||||||
|
| CHECK-Constraints | 330 | `SSMS_DB_SCHEMA.sql` |
|
||||||
|
| Benutzerrechte (Konstanten) | 750 `public const int` | `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs` |
|
||||||
|
|
||||||
|
Architektur-Grobbild (aus `docs/getting-started/general-structure.md` und Verzeichnisstruktur):
|
||||||
|
WPF-Client (`src/centron`) und Blazor-Web-Client „Nexus" (`src/nexus`) greifen über ein
|
||||||
|
`ILogic`-Muster wahlweise direkt (BLLogic → NHibernate → MSSQL) oder über den Webservice
|
||||||
|
(WSLogic → `src/webservice`) auf die Geschäftslogik (`src/backend/Centron.BL`) zu.
|
||||||
|
Belege werden dual gehalten: deutsche Legacy-Tabellen (`AngKopf`/`AngPos` …) mit englischen Views
|
||||||
|
(`Offers`/`OfferItems` …) darüber.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Schritt 0 – Modulinventar
|
||||||
|
|
||||||
|
Das Inventar wurde **vor** der ersten Anforderung erstellt. Bezugsgröße für Mindestabdeckung
|
||||||
|
und Abdeckungstabelle. Granularität: fachliches Modul bzw. abgrenzbare Komponente.
|
||||||
|
Pfade relativ zum Arbeitsverzeichnis; `BL/` steht für `src/backend/Centron.BL/`.
|
||||||
|
|
||||||
|
### A. Vertrieb / Belegwesen
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M01 | Angebote | `BL/Sales/Receipts/Offers`, Tabellen `AngKopf`/`AngPos` | Erstellen und Verwalten von Angeboten an Kunden. |
|
||||||
|
| M02 | Aufträge | `BL/Sales/Receipts/Orders`, `AufKopf`/`AufPos` | Auftragsverwaltung inkl. Auftragsstatus und Folgebelegen. |
|
||||||
|
| M03 | Lieferscheine | `BL/Sales/Receipts/DeliveryLists`, `LiefKopf`/`LiefPos` | Lieferscheinerstellung und Lieferabwicklung. |
|
||||||
|
| M04 | Rechnungen | `BL/Sales/Receipts/Invoices`, `RechKopf`/`RechPos` | Fakturierung, Rechnungsstatus, Zahlungsreferenzen. |
|
||||||
|
| M05 | Gutschriften | `BL/Sales/Receipts/CreditVouchers`, `GutKopf`/`GutPos` | Gutschriftenerstellung zu Rechnungen/Retouren. |
|
||||||
|
| M06 | Abhollisten | `BL/Sales/Receipts/PickupLists`, `AbholKopf`/`AbholPos` | Abholaufträge für Geräte/Waren beim Kunden. |
|
||||||
|
| M07 | Verträge (Beleg) | `BL/Sales/Receipts/ContractLists`, `VertragKopf`/`VertragPos` | Wiederkehrende Leistungsverträge als Belegart mit Abrechnungsintervallen. |
|
||||||
|
| M08 | Automatische Fakturierung | `BL/Sales/CustomerAssets/AutomaticFactura` | Automatische Rechnungserzeugung aus Verträgen, Kontingent- und Klickabrechnung. |
|
||||||
|
| M09 | Zeitenabrechnung | `BL/Sales/CustomerAssets/TimerBilling` | Abrechnung erfasster Helpdesk-/Servicezeiten in Belege. |
|
||||||
|
| M10 | Anzahlungen | `BL/Sales/Receipts/DownPayment` | Anzahlungsrechnungen und deren Verrechnung. |
|
||||||
|
| M11 | Projekte (Beleg/PM) | `BL/Sales/Receipts/Projects`, `BL/Projects` | Projektverwaltung mit Belegzuordnung. |
|
||||||
|
| M12 | Leasing & Service | `BL/Sales/Receipts/LeasingAndService` | Leasing-/Serviceabwicklung zu Belegen. |
|
||||||
|
| M13 | Aktionspreise | `docs/reference/receipts/actionprice-system.md`, ActionPrice-Klassen | Zeitlich begrenzte Aktionsverkaufspreise je Artikel/Kunde. |
|
||||||
|
| M14 | Artikelsuche im Beleg | `BL/Sales/Receipts/ArticleSearch` | Artikel-/Preisfindung beim Belegerfassen. |
|
||||||
|
| M15 | Kassenbuch | `BL/Sales/CashBooks` | Kassenbuchführung mit Belegen und Salden. |
|
||||||
|
| M16 | Sonderpreise | `BL/Accounts/SpecialPrices` | Kundenindividuelle Preise (auch Quelle des WebCart-Sortiments). |
|
||||||
|
| M17 | Stammblätter (Geräteabrechnung) | `Centron.Entities/Entities/Sales/Receipts/MasterDataLists` | Gerätestammblätter mit Seriennummer, Zählern, Vertrags- und Rechnungsbezug. |
|
||||||
|
| M18 | Schweiz-Besonderheiten | `BL/Sales/Receipts/Switzerland` | Länderspezifische Beleglogik Schweiz (z. B. Rundung, MwSt). |
|
||||||
|
| M19 | Belegversionierung | `*KopfVersions`/`*PosVersions`-Tabellen, `AssetHeadDAO` | Versionsstände aller Belegarten für Audit-Trail. |
|
||||||
|
| M20 | Nummernkreise | `BL/Administration/Company/NumberGroupBL.cs` | Vergabe eindeutiger Beleg-/Stammdatennummern je Mandant/Filiale. |
|
||||||
|
| M21 | Belegdruck/-versand (Mailvorlagen) | `BL/Sales/Receipts` (ReceiptBL Druck/Mail), `BL/Mail/Templates` | Erzeugen, Drucken und Mailen von Belegdokumenten. |
|
||||||
|
|
||||||
|
### B. Einkauf
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M22 | Lieferantenbestellungen | `BL/Sales/Receipts/SupplierOrders` | Bestellungen an Lieferanten/Distributoren. |
|
||||||
|
| M23 | Lieferantenrechnungen | `BL/Sales/Receipts/SupplierInvoices` | Eingangsrechnungserfassung und -prüfung. |
|
||||||
|
| M24 | Lieferantenlieferscheine | `BL/Sales/Receipts/SupplierDeliveryLists` | Wareneingang auf Basis Lieferantenlieferscheinen. |
|
||||||
|
| M25 | Lieferantengutschriften | `BL/Sales/Receipts/SupplierCreditVouchers` | Gutschriften von Lieferanten. |
|
||||||
|
| M26 | Lieferantenbelegdokumente | `BL/Sales/Receipts/SupplierReceiptDocuments` | Dokumente/Anhänge zu Einkaufsbelegen. |
|
||||||
|
| M27 | Bestellvorschläge | `BL/Purchasing/OrderSuggestionList` | Bestellvorschlagsermittlung aus Bedarf/Beständen. |
|
||||||
|
| M28 | Lieferanten-/Distributorenstamm | `BL/Purchasing/Suppliers`, `BL/Buying/DistributorBL.cs`, `BL/BusinessPartner` | Verwaltung von Lieferanten und Distributoren. |
|
||||||
|
|
||||||
|
### C. Kunden / CRM
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M29 | Adress-/Kundenstamm | `BL/Accounts/AccountBL.cs`, `BL/CustomerArea`, Tabellen `Accounts`/`AccountCustomers`/`Kunden` | Zentrale Verwaltung von Accounts (Kunden, Lieferanten, Interessenten) mit Adressen. |
|
||||||
|
| M30 | Ansprechpartner & Adressen | `BL/Sales/Customers/Addresses` | Kontaktpersonen und Adressverwaltung zu Accounts. |
|
||||||
|
| M31 | Aktivitäten | `BL/Accounts/Activities` | Protokollierung von Kundenaktivitäten (Anrufe, Mails, Belege). |
|
||||||
|
| M32 | Kampagnen | `BL/Accounts/Campaigns` | Marketingkampagnen mit Zielgruppen. |
|
||||||
|
| M33 | Marketing/Mailings | `BL/Sales/Marketing`, `BL/Mailings` | Serienmails/Mailings an Kundengruppen. |
|
||||||
|
| M34 | Umfragen | `BL/Accounts/Survey` | Kundenumfragen inkl. Versand nach Ticketabschluss. |
|
||||||
|
| M35 | CRM-Projekte | `BL/Sales/Customers/CrmProjects` | Vertriebschancen/CRM-Projekte. |
|
||||||
|
| M36 | Hotline | `BL/Accounts/HotlineArea` | Hotline-Konditionen je Kunde. |
|
||||||
|
| M37 | Kundenvereinbarungen | `BL/Accounts/AccountContracts` | Rahmenvereinbarungen je Account. |
|
||||||
|
|
||||||
|
### D. Service / Helpdesk
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M38 | Helpdesk/Tickets | `BL/Sales/Support/HelpdeskBL.cs` u. a. | Ticketverwaltung (Anlage, Bearbeitung, Status, Kategorien). |
|
||||||
|
| M39 | Eskalationsmanagement | `BL/Sales/Support/EscalationBL.cs` | Eskalationsregeln und Fälligkeiten auf Tickets. |
|
||||||
|
| M40 | Ticket-Zeiterfassung | `BL/Sales/Support/HelpdeskTimer*.cs` | Zeiterfassung auf Tickets inkl. Unterschrift und Artikelbuchung. |
|
||||||
|
| M41 | Checklisten | `BL/CheckListArea` | Checklistenvorlagen und -abarbeitung (v. a. auf Tickets). |
|
||||||
|
| M42 | Ticketvorlagen (C-FLOW) | `BL/Sales/Support/HelpdeskPatternBL.cs`, `HelpdeskCreationTemplateBL.cs` | Vorlagen zur automatischen Ticketerzeugung. |
|
||||||
|
| M43 | Taskmanagement | `BL/TaskManager` | Aufgabensteuerung mit Aktionen auf Tickets. |
|
||||||
|
| M44 | Ticketprojekte | `BL/TicketProjects` | Bündelung von Tickets zu Projekten. |
|
||||||
|
| M45 | RMA | `BL/CustomerArea/RmaBL.cs`, Tabelle `Rma` | Retouren-/Reparaturabwicklung zu Tickets. |
|
||||||
|
| M46 | Externes Helpdesk | `BL/ExternalHelpdesk` | Anbindung fremder Ticketsysteme. |
|
||||||
|
| M47 | Terminanfragen | `BL/AppointmentRequests` | Terminanfragen an Kunden (z. B. aus Tickets). |
|
||||||
|
| M48 | ToDos | `BL/ToDoArea` | Persönliche/ticketbezogene Aufgabenlisten. |
|
||||||
|
|
||||||
|
### E. Geräte / Assets / MSP
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M49 | Kundengeräte | `BL/Devices/AccountDeviceBL.cs`, `BL/Sales/CustomerAssets` | Verwaltung der beim Kunden stehenden Geräte. |
|
||||||
|
| M50 | DocuBoard/Assetmanagement | `BL/DocuBoard`, Tabellen `AssetManagement*` | IT-Dokumentation/Inventarisierung (AD-Scans, SNMP, Partner). |
|
||||||
|
| M51 | RMM-Datenimport | `BL/DataExchange/Rmm` | Import von Monitoring-/RMM-Daten für Abrechnung. |
|
||||||
|
| M52 | MSP-Abrechnung | `BL/Statistics/MspCollectors` | Sammler und Auswertung nutzungsbasierter MSP-Leistungen. |
|
||||||
|
|
||||||
|
### F. Lager / Logistik / Produktion
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M53 | Artikelstamm | `BL/Warehousing/ArticleBL.cs`, `BL/Warehousing/ArticleManagement` | Artikelverwaltung inkl. Preisen, Herstellern, EAN. |
|
||||||
|
| M54 | Lager/Bestände | `BL/Warehousing/StockManagement`, `BL/Storage` | Lagerorte, Bestandsführung, Umbuchungen. |
|
||||||
|
| M55 | Inventur | `BL/Warehousing/InventoryManagement` | Inventurdurchführung und Bestandskorrektur. |
|
||||||
|
| M56 | Kommissionierung | `BL/Warehousing/CommissioningManagement`, `Commissions` | Kommissionieren von Aufträgen. |
|
||||||
|
| M57 | Seriennummern/Barcodes | `Centron.Entities/Entities/Warehousing/SerialNumber.cs`, `BarCode.cs` | Serialisierte Bestandsführung und Barcodestatus. |
|
||||||
|
| M58 | Produktion | `BL/Production`, `BL/Warehousing/ArticleProduction` | Fertigungsaufträge und Stücklistenproduktion. |
|
||||||
|
| M59 | Versand GLS | `src/apis/Centron.Api.Gls` | Paketversand über GLS-API. |
|
||||||
|
| M60 | Versand Shipcloud | `src/apis/Centron.Api.Shipcloud` | Paketversand über Shipcloud-API. |
|
||||||
|
|
||||||
|
### G. Finanzen
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M61 | Zahlungseingänge | `BL/Finances/IncomingPayments` | Erfassung/Zuordnung von Zahlungseingängen zu Rechnungen. |
|
||||||
|
| M62 | Onlinebanking | `BL/Finances/OnlineBanking`, `src/apis/Centron.APIs.FinAPI` | Kontoumsatzabruf über finAPI und Transaktionszuordnung. |
|
||||||
|
| M63 | Zahlungsverkehr/SEPA | `BL/Finances/Payments`, Mandate (`MandatI3D`) | Lastschrift-/Zahlungsläufe mit SEPA-Mandaten. |
|
||||||
|
| M64 | Mahnwesen | `BL/Sales/Receipts/Invoices/Dunning` | Mahnläufe mit Mahnstufen und Mahnsperren. |
|
||||||
|
| M65 | OPOS | `BL/Sales/Receipts/Invoices/Opos` | Offene-Posten-Verwaltung. |
|
||||||
|
| M66 | Buchhaltungsexport | `BL/DataExchange/BookKeeping`, `Centron.Gateway/DataExchange/BookKeeping` | Export an DATEV, Sage, Schilling u. a. |
|
||||||
|
| M67 | Bankkonten | `BL/Accounting/BankAccountBL.cs` | Bankverbindungen von Accounts. |
|
||||||
|
| M68 | Kreditlimit/Bonität | `ReceiptBL` (Kreditlimitprüfung) | Kreditlimitprüfung bei Belegerstellung. |
|
||||||
|
|
||||||
|
### H. Administration / System
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M69 | Benutzer & Login | `BL/Administration/Logins` | Benutzerkonten, Authentifizierung (Basic/AD/Entra ID), Sitzungstickets. |
|
||||||
|
| M70 | Rechteverwaltung | `BL/Administration/Rights`, Tabellen `Sichbenu`/`Sichmemb`/`Sichtrus` | Gruppenbasierte Rechtevergabe mit 750 Einzelrechten. |
|
||||||
|
| M71 | Zwei-Faktor-Authentifizierung | `BL/Administration/Logins/TwoFactor` | 2FA per E-Mail oder RADIUS. |
|
||||||
|
| M72 | Lizenzierung | `BL/Administration/Licensing`, `docs/reference/security/licensing-system.md` | GUID-basierte Produkt-/Featurelizenzen mit Anzahl und Ablauf. |
|
||||||
|
| M73 | Mandanten/Filialen | `BL/Administration/Company`, `BL/Administration/Mandatory` | Mandanten-, Firmen- und Filialverwaltung. |
|
||||||
|
| M74 | Mitarbeiterverwaltung | `BL/Administration/Employees`, `BL/EmployeeArea` | Mitarbeiterstamm, Abteilungen, Teams. |
|
||||||
|
| M75 | Einstellungen | `BL/Administration/Settings` | Zentrale Anwendungseinstellungen (`ApplicationSettingID`). |
|
||||||
|
| M76 | Datensicherheit/DSGVO | `BL/Administration/DataSecurity` | Datenschutzfunktionen (Anonymisierung/Löschkonzept). |
|
||||||
|
| M77 | DB-Skripte/Migration | `BL/Administration/Scripts`, `docs/guides/database` | Nummerierte SQL-Migrationsskripte mit Versionierung. |
|
||||||
|
| M78 | Hintergrunddienste | `BL/Administration/BackgroundServices`, `docs/Background Service` | Zeitgesteuerte Dienste (z. B. DataQualityService). |
|
||||||
|
| M79 | Telemetrie/Profiling | `BL/Telemetry`, `BL/Administration/Profiling` | Nutzungs-/Leistungsdaten. |
|
||||||
|
| M80 | Access Tokens | `BL/Administration/AccessTokens` | API-Zugriffstoken für Fremdzugriffe. |
|
||||||
|
| M81 | Passwortmanager | `BL/PasswordManagementArea`, `BL/PasswordManager` | Verwaltung von Kundenpasswörtern/Zugangsdaten. |
|
||||||
|
| M82 | Anpassungen/CustomTables | `BL/Customizations/CustomTables` | Kundenindividuelle Zusatztabellen/-felder. |
|
||||||
|
| M83 | Massenupdate | `BL/MassUpdate` | Massenänderung von Stammdaten. |
|
||||||
|
| M84 | GUI-Profile | `BL/GUI/Profiles` | Benutzer-/Rollenprofile für Oberflächenlayouts. |
|
||||||
|
|
||||||
|
### I. Kommunikation
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M85 | E-Mail & Vorlagen | `BL/Mail` | Mailversand, Vorlagen mit Variablenersetzung, Blacklist. |
|
||||||
|
| M86 | Exchange-Sync | `BL/Mail/Exchange`, `docs/features/exchange-sync-bugprotokoll.md` | Synchronisation von Mails/Terminen mit Exchange. |
|
||||||
|
| M87 | MailScanner | `BL/MailScanner` | Automatische Ticketerzeugung/Zuordnung aus Postfächern. |
|
||||||
|
| M88 | TAPI/Telefonie | `BL/Tapi/PhoneCallBL.cs`, `docs/reference/architecture/tapi.md` | Anrufsignalisierung und Anruferkennung. |
|
||||||
|
| M89 | Kalender | `BL/Sales/Calendar`, `BL/Calendar` | Terminkalender der Mitarbeiter. |
|
||||||
|
| M90 | Chats | `BL/Chats` | Interne Chatfunktion. |
|
||||||
|
| M91 | Outlook-Add-In | `src/nexus/CentronNexus.OutlookAddIn` | Ticket-/Kundenbezug direkt aus Outlook. |
|
||||||
|
| M92 | Benachrichtigungen | `BL/Notifications`, `BL/NexusNotifications` | Systembenachrichtigungen an Benutzer (Client und Web). |
|
||||||
|
|
||||||
|
### J. Datenaustausch / Schnittstellen
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M93 | EDI-Framework | `BL/EDI`, `docs/reference/edi` | Elektronischer Belegaustausch mit Distributoren (ALSO, Alltron, Komsa …). |
|
||||||
|
| M94 | ZUGFeRD/XRechnung | `BL/EDI/Zugferd`, `docs/guides/development/xrechnung.md`, `docs/reference/zugferd-*.md` | Strukturierte E-Rechnung (Erzeugung/Einlesen). |
|
||||||
|
| M95 | ebInterface | `src/apis/Centron.Api.EbInterface` | Österreichisches E-Rechnungsformat. |
|
||||||
|
| M96 | docuFORM | `Centron.Api.docuFORM` | Zählerstands-/Gerätedaten von docuFORM. |
|
||||||
|
| M97 | Icecat | `src/apis/Centron.APIs.IcecatDataAccess` | Artikelstammdaten-Anreicherung aus Icecat. |
|
||||||
|
| M98 | ITscope | `src/apis/Centron.APIs.ITscopeDataAccess` | Produkt-/Preisdaten und Bestellungen über ITscope. |
|
||||||
|
| M99 | COP | `src/apis/Centron.APIs.CopDataAccess` | COP-Datenzugriff (Herstellerdaten/Servicedaten). |
|
||||||
|
| M100 | EGIS | `src/apis/Centron.APIs.EgisDataAccess`, `BL/EDI/EGIS` | EGIS-Warenkorb/Bestellübertragung. |
|
||||||
|
| M101 | Telekom Dive | `BL/DataExchange/TelekomDive` | Telekom-Dive-Schnittstelle. |
|
||||||
|
| M102 | TANSS | `BL/DataExchange/TanssInterfaces` | Übernahme aus TANSS-Ticketsystem. |
|
||||||
|
| M103 | GFK-Export | `BL/DataExchange/GfkExport` | Absatzmeldung an GfK. |
|
||||||
|
| M104 | Datenimport allgemein | `BL/DataExchange/Import` | Generischer Datenimport (CSV u. a.). |
|
||||||
|
| M105 | Connectors | `BL/DataExchange/Connectors`, `BL/Services/CTimeConnectors` | Konnektoren zu Drittsystemen (u. a. c-time). |
|
||||||
|
|
||||||
|
### K. Auswertung / Suche
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M106 | ReportEngine | `BL/ReportEngine` | Reportvorlagen, PDF-Erzeugung, Belegdruckstrategien. |
|
||||||
|
| M107 | Statistiken | `BL/Statistics` | Umsatz-, Auftrags-, Ticket- und Vertragsstatistiken. |
|
||||||
|
| M108 | Indexsuche | `BL/IndexSearch` | Volltextsuche (Lucene) über Accounts und Tickets. |
|
||||||
|
|
||||||
|
### L. Web (c-entron Nexus) und Webservice
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M109 | Nexus-Rahmen | `src/nexus/CentronNexus`, `CentronNexus.Host` | Blazor-Webanwendung (Login, Navigation, Hosting). |
|
||||||
|
| M110 | ServiceBoard | `src/nexus/CentronNexus/ServiceBoard` | Web-Ticketboard für Techniker/Kunden. |
|
||||||
|
| M111 | WebCart | `src/nexus/CentronNexus/WebCart` | Webshop für Endkunden auf Basis Sonderpreisen. |
|
||||||
|
| M112 | WebOffer | `src/nexus/CentronNexus/WebOffer` | Online-Angebotsansicht/-freigabe durch Kunden. |
|
||||||
|
| M113 | Dokumentensignierung | `src/nexus/CentronNexus/DocumentSigning` | Digitale Unterschrift von Dokumenten im Web. |
|
||||||
|
| M114 | Produktionsaufträge Web | `src/nexus/CentronNexus/ProductionOrderManagement` | Web-Sicht auf Fertigungsaufträge. |
|
||||||
|
| M115 | SelfCare | `BL/SelfCare` | Selbstbedienungsseiten für Endkunden (Web-Anfragen). |
|
||||||
|
| M116 | Web-Accounts/WebSuite | `BL/Administration/Logins/WebAccountBL.cs`, `BL/WebSuite` | Weblogins für Kunden mit eigenem Rechtesatz. |
|
||||||
|
| M117 | Webservice | `src/webservice` (Host, Controllers, WebServices.Core) | REST-/Dienstschicht für Client-, Web- und Fremdzugriffe. |
|
||||||
|
| M118 | ConnectionManager | `src/webservice/c-entron.misc.ConnectionManager` | Verwaltung der DB-/Dienstverbindungen. |
|
||||||
|
|
||||||
|
### M. Weitere Fachmodule
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M119 | MyCentron/Dashboard | `BL/MyCentron` | Persönliche Startseite mit Dashboards, Notizen, Planungen. |
|
||||||
|
| M120 | MyDay | `BL/MyDay` | Tagesübersicht mit Importen aus Fremdtools (lizenzpflichtig je Import). |
|
||||||
|
| M121 | KI-Funktionen | `BL/ArtificialIntelligence` | KI-Chat und Prompts (z. B. Textvorschläge). |
|
||||||
|
| M122 | TradePool | `BL/TradePool` | Gebrauchtgeräte-/Handelsplattform-Anbindung. |
|
||||||
|
| M123 | VoucherManagement | `BL/VoucherManagement` | Gutschein-/Voucherverwaltung. |
|
||||||
|
| M124 | Textbausteine | `BL/TextModuleArea` | Wiederverwendbare Textmodule. |
|
||||||
|
| M125 | Tags | `BL/Tags` | Freie Verschlagwortung von Objekten. |
|
||||||
|
| M126 | Social Media | `BL/SocialMedia` | Social-Media-Profile zu Personen/Accounts. |
|
||||||
|
| M127 | VideoPortal | `BL/VideoPortal` | Zuordnung von Schulungs-/Videos. |
|
||||||
|
| M128 | WebLinks | `BL/WebLinks` | Aktionslinks (z. B. Terminbestätigung) mit Handlern. |
|
||||||
|
| M129 | Mobile | `BL/Mobile` | Unterstützung mobiler Clients. |
|
||||||
|
| M130 | ProductMatrix | `BL/ProductMatrix` | Produktmatrix (Artikelvergleich/-zuordnung). |
|
||||||
|
| M131 | ItPlanner | `BL/ItPlanner` | Planungsobjekte/Checklisten für IT-Projekte. |
|
||||||
|
| M132 | ExpectedEvents | `BL/ExpectedEvents` | Erwartete Ereignisse/Wiedervorlagen. |
|
||||||
|
| M133 | CPra | `BL/CPra` | Anbindung „CPra"-Konnektor (Konfiguration + Übertragung). |
|
||||||
|
| M134 | RiverDivo | `BL/RiverDivo` | Anbindung RiverSuite/Divo (Vertragsartikel-Referenzen). |
|
||||||
|
| M135 | Länder/Regionen | `BL/CountryArea` | Länder- und Bundesländerstamm. |
|
||||||
|
| M136 | Feiertage | `Centron.DAO/Holiday` | Feiertagsberechnung (z. B. für Fristen). |
|
||||||
|
| M137 | Wechselkurse/Währungen | `ReceiptBase` (CurrencyI3D/Factor), Währungstabellen | Fremdwährungsbelege mit Kursfaktor. |
|
||||||
|
| M138 | Objekt-Fremdreferenzen | `BL/ObjectExternalReferences` | Verknüpfung interner Objekte mit externen IDs. |
|
||||||
|
| M139 | Prozesse/Workflows | `BL/Processes`, `BL/Services/Workflows` | Definierte Abläufe/Workflow-Unterstützung. |
|
||||||
|
| M140 | Änderungsverfolgung | `BL/ChangeTracking`, `Centron.DAO/ChangeTracking` | Historisierung von Feldänderungen. |
|
||||||
|
|
||||||
|
### N. Infrastruktur / Querschnitt
|
||||||
|
|
||||||
|
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M141 | WPF-Client-Rahmen | `src/centron/Centron.WPF.UI` (Start, Modules, Views) | Windows-Client mit Modulnavigation und Anmeldung. |
|
||||||
|
| M142 | Shared Controls | `src/shared/Centron.Controls`, `Centron.Core` | Wiederverwendbare UI-Komponenten und Basisfunktionen. |
|
||||||
|
| M143 | Datenzugriff/DAO | `src/backend/Centron.DAO` | NHibernate-Mappings, Repositories, NamedQueries, RawSQL. |
|
||||||
|
| M144 | Gateway | `src/backend/Centron.Gateway` | Externe Format-Gateways (u. a. Buchhaltungsexporte, EGIS-Suche). |
|
||||||
|
| M145 | Deployment/Setup | `deployment/`, `docker/`, `azure/`, `azure-blazor/` | Installer (WiX), Container- und Cloud-Bereitstellung. |
|
||||||
|
| M146 | Lokalisierung | `LocalizedStrings*.resx`, `docs/guides/ui/localization.md` | Deutsch als Erstsprache, Englisch als Zweitsprache. |
|
||||||
|
|
||||||
|
**Summe: 146 Module.** Das Inventar darf ergänzt, aber nicht gekürzt werden.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Erzeugtes Anforderungs-Set (Überblick)
|
||||||
|
|
||||||
|
| Ebene | Anzahl | davon HYPOTHESE |
|
||||||
|
|---|---|---|
|
||||||
|
| StRS | 32 | 0 |
|
||||||
|
| SyRS | 156 | 11 |
|
||||||
|
| SwRS | 71 | 2 |
|
||||||
|
| **Gesamt** | **259** | **13 (5,0 %)** |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Abdeckungstabelle (je Modul des Inventars)
|
||||||
|
|
||||||
|
Einstufung: **tief** = mehrere Anforderungen mit methodengenau gelesener Logik (inkl.
|
||||||
|
SwRS-Vertiefung) · **mittel** = 1-2 Anforderungen mit konkret gelesener Logik ·
|
||||||
|
**flach** = 1 Anforderung auf Basis von Dateibestand/Signaturen · **nicht analysiert** = 0
|
||||||
|
Anforderungen. `[H]` = Anforderung mit Status HYPOTHESE. Jede Inventarzeile ist enthalten.
|
||||||
|
|
||||||
|
| Nr. | Modul | Abdeckung | Anforderungen (tragend) | Anzahl |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M01 | Angebote | mittel | SyRS-001 (+SyRS-026/027 übergreifend) | 1 |
|
||||||
|
| M02 | Aufträge | mittel | SyRS-002 | 1 |
|
||||||
|
| M03 | Lieferscheine | mittel | SyRS-003 | 1 |
|
||||||
|
| M04 | Rechnungen | tief | SyRS-004, SyRS-005, SyRS-006, SwRS-016, SwRS-017 | 5 |
|
||||||
|
| M05 | Gutschriften | mittel | SyRS-007 | 1 |
|
||||||
|
| M06 | Abhollisten | flach | SyRS-008 | 1 |
|
||||||
|
| M07 | Verträge (Beleg) | mittel | SyRS-009, SwRS-023 | 2 |
|
||||||
|
| M08 | Automatische Fakturierung | tief | SyRS-010, SyRS-011, SwRS-019, SwRS-020, SwRS-021, SwRS-022, SwRS-024, SwRS-064, SwRS-071 [H] | 9 |
|
||||||
|
| M09 | Zeitenabrechnung | tief | SyRS-012, SwRS-063 | 2 |
|
||||||
|
| M10 | Anzahlungen | mittel | SyRS-013, SwRS-018 | 2 |
|
||||||
|
| M11 | Projekte (Beleg/PM) | flach | SyRS-014 | 1 |
|
||||||
|
| M12 | Leasing & Service | flach | SyRS-015 | 1 |
|
||||||
|
| M13 | Aktionspreise | mittel | SyRS-016 | 1 |
|
||||||
|
| M14 | Artikelsuche im Beleg | tief | SyRS-017, SwRS-007, SwRS-009, SwRS-010, SwRS-013, SwRS-014 | 6 |
|
||||||
|
| M15 | Kassenbuch | mittel | SyRS-018 | 1 |
|
||||||
|
| M16 | Sonderpreise | tief | SyRS-019, SwRS-008 | 2 |
|
||||||
|
| M17 | Stammblätter | mittel | SyRS-020 | 1 |
|
||||||
|
| M18 | Schweiz-Besonderheiten | tief | SyRS-021, SwRS-012 | 2 |
|
||||||
|
| M19 | Belegversionierung | mittel | SyRS-022, SwRS-002, SwRS-003 | 3 |
|
||||||
|
| M20 | Nummernkreise | tief | SyRS-023, SwRS-025 | 2 |
|
||||||
|
| M21 | Belegdruck/-versand | mittel | SyRS-024 | 1 |
|
||||||
|
| M22 | Lieferantenbestellungen | flach | SyRS-029 | 1 |
|
||||||
|
| M23 | Lieferantenrechnungen | mittel | SyRS-030 | 1 |
|
||||||
|
| M24 | Lieferantenlieferscheine | mittel | SyRS-031 | 1 |
|
||||||
|
| M25 | Lieferantengutschriften | flach | SyRS-032 | 1 |
|
||||||
|
| M26 | Lieferantenbelegdokumente | flach | SyRS-033 | 1 |
|
||||||
|
| M27 | Bestellvorschläge | flach | SyRS-034 | 1 |
|
||||||
|
| M28 | Lieferanten-/Distributorenstamm | mittel | SyRS-035 | 1 |
|
||||||
|
| M29 | Adress-/Kundenstamm | tief | SyRS-036, SyRS-037, SwRS-051 | 3 |
|
||||||
|
| M30 | Ansprechpartner & Adressen | mittel | SyRS-037 | 1 |
|
||||||
|
| M31 | Aktivitäten | mittel | SyRS-038 | 1 |
|
||||||
|
| M32 | Kampagnen | flach | SyRS-039 | 1 |
|
||||||
|
| M33 | Marketing/Mailings | flach | SyRS-040 | 1 |
|
||||||
|
| M34 | Umfragen | mittel | SyRS-041 | 1 |
|
||||||
|
| M35 | CRM-Projekte | flach | SyRS-042 | 1 |
|
||||||
|
| M36 | Hotline | flach | SyRS-043 | 1 |
|
||||||
|
| M37 | Kundenvereinbarungen | flach | SyRS-044 | 1 |
|
||||||
|
| M38 | Helpdesk/Tickets | tief | SyRS-045, SyRS-046, SyRS-047, SyRS-058, SwRS-047, SwRS-048 | 6 |
|
||||||
|
| M39 | Eskalationsmanagement | tief | SyRS-048, SwRS-049 | 2 |
|
||||||
|
| M40 | Ticket-Zeiterfassung | mittel | SyRS-049 | 1 |
|
||||||
|
| M41 | Checklisten | mittel | SyRS-050 | 1 |
|
||||||
|
| M42 | Ticketvorlagen (C-FLOW) | mittel | SyRS-051 | 1 |
|
||||||
|
| M43 | Taskmanagement | flach | SyRS-052 | 1 |
|
||||||
|
| M44 | Ticketprojekte | mittel | SyRS-053 | 1 |
|
||||||
|
| M45 | RMA | mittel | SyRS-054, SwRS-050 | 2 |
|
||||||
|
| M46 | Externes Helpdesk | flach | SyRS-055 [H] | 1 |
|
||||||
|
| M47 | Terminanfragen | mittel | SyRS-056 | 1 |
|
||||||
|
| M48 | ToDos | mittel | SyRS-057 | 1 |
|
||||||
|
| M49 | Kundengeräte | mittel | SyRS-059 | 1 |
|
||||||
|
| M50 | DocuBoard/Assetmanagement | flach | SyRS-060 | 1 |
|
||||||
|
| M51 | RMM-Datenimport | flach | SyRS-061 | 1 |
|
||||||
|
| M52 | MSP-Abrechnung | mittel | SyRS-062, SwRS-064 | 2 |
|
||||||
|
| M53 | Artikelstamm | mittel | SyRS-063 | 1 |
|
||||||
|
| M54 | Lager/Bestände | tief | SyRS-064, SwRS-011, SwRS-046 | 3 |
|
||||||
|
| M55 | Inventur | tief | SyRS-065, SwRS-069 | 2 |
|
||||||
|
| M56 | Kommissionierung | mittel | SyRS-066 | 1 |
|
||||||
|
| M57 | Seriennummern/Barcodes | tief | SyRS-067, SwRS-045 | 2 |
|
||||||
|
| M58 | Produktion | mittel | SyRS-068 | 1 |
|
||||||
|
| M59 | Versand GLS | flach | SyRS-069 | 1 |
|
||||||
|
| M60 | Versand Shipcloud | flach | SyRS-070 | 1 |
|
||||||
|
| M61 | Zahlungseingänge | tief | SyRS-071, SwRS-031 | 2 |
|
||||||
|
| M62 | Onlinebanking | tief | SyRS-072, SwRS-028 | 2 |
|
||||||
|
| M63 | Zahlungsverkehr/SEPA | tief | SyRS-073, SwRS-026, SwRS-027 | 3 |
|
||||||
|
| M64 | Mahnwesen | tief | SyRS-074, SwRS-030 | 2 |
|
||||||
|
| M65 | OPOS | flach | SyRS-075 | 1 |
|
||||||
|
| M66 | Buchhaltungsexport | tief | SyRS-076, SwRS-029 | 2 |
|
||||||
|
| M67 | Bankkonten | mittel | SyRS-077 | 1 |
|
||||||
|
| M68 | Kreditlimit/Bonität | tief | SyRS-025, SwRS-015 | 2 |
|
||||||
|
| M69 | Benutzer & Login | tief | SyRS-078, SyRS-079, SwRS-032, SwRS-033, SwRS-034, SwRS-041 | 6 |
|
||||||
|
| M70 | Rechteverwaltung | tief | SyRS-080, SwRS-036, SwRS-038 | 3 |
|
||||||
|
| M71 | Zwei-Faktor-Authentifizierung | tief | SyRS-081, SwRS-037 | 2 |
|
||||||
|
| M72 | Lizenzierung | tief | SyRS-082, SwRS-035 | 2 |
|
||||||
|
| M73 | Mandanten/Filialen | mittel | SyRS-083 (+SyRS-028) | 1 |
|
||||||
|
| M74 | Mitarbeiterverwaltung | mittel | SyRS-084 | 1 |
|
||||||
|
| M75 | Einstellungen | mittel | SyRS-085, SwRS-054 | 2 |
|
||||||
|
| M76 | Datensicherheit/DSGVO | tief | SyRS-086, SwRS-052 | 2 |
|
||||||
|
| M77 | DB-Skripte/Migration | mittel | SyRS-087, SwRS-053 | 2 |
|
||||||
|
| M78 | Hintergrunddienste | mittel | SyRS-088, SwRS-057 | 2 |
|
||||||
|
| M79 | Telemetrie/Profiling | flach | SyRS-089 [H] | 1 |
|
||||||
|
| M80 | Access Tokens | tief | SyRS-090, SwRS-040 | 2 |
|
||||||
|
| M81 | Passwortmanager | mittel | SyRS-091 | 1 |
|
||||||
|
| M82 | Anpassungen/CustomTables | flach | SyRS-092 | 1 |
|
||||||
|
| M83 | Massenupdate | mittel | SyRS-093 | 1 |
|
||||||
|
| M84 | GUI-Profile | flach | SyRS-094 | 1 |
|
||||||
|
| M85 | E-Mail & Vorlagen | tief | SyRS-095, SwRS-059, SwRS-060 | 3 |
|
||||||
|
| M86 | Exchange-Sync | flach | SyRS-096 | 1 |
|
||||||
|
| M87 | MailScanner | mittel | SyRS-097 | 1 |
|
||||||
|
| M88 | TAPI/Telefonie | mittel | SyRS-098 | 1 |
|
||||||
|
| M89 | Kalender | mittel | SyRS-099 | 1 |
|
||||||
|
| M90 | Chats | mittel | SyRS-100 | 1 |
|
||||||
|
| M91 | Outlook-Add-In | flach | SyRS-101 | 1 |
|
||||||
|
| M92 | Benachrichtigungen | mittel | SyRS-102 | 1 |
|
||||||
|
| M93 | EDI-Framework | mittel | SyRS-103, SwRS-062 | 2 |
|
||||||
|
| M94 | ZUGFeRD/XRechnung | tief | SyRS-104, SwRS-061 | 2 |
|
||||||
|
| M95 | ebInterface | flach | SyRS-105 | 1 |
|
||||||
|
| M96 | docuFORM | flach | SyRS-106 [H] | 1 |
|
||||||
|
| M97 | Icecat | flach | SyRS-107 | 1 |
|
||||||
|
| M98 | ITscope | mittel | SyRS-108 | 1 |
|
||||||
|
| M99 | COP | flach | SyRS-109 [H] | 1 |
|
||||||
|
| M100 | EGIS | flach | SyRS-110 | 1 |
|
||||||
|
| M101 | Telekom Dive | flach | SyRS-111 [H] | 1 |
|
||||||
|
| M102 | TANSS | flach | SyRS-112 [H] | 1 |
|
||||||
|
| M103 | GFK-Export | flach | SyRS-113 | 1 |
|
||||||
|
| M104 | Datenimport allgemein | flach | SyRS-114 | 1 |
|
||||||
|
| M105 | Connectors | flach | SyRS-115 | 1 |
|
||||||
|
| M106 | ReportEngine | mittel | SyRS-116 | 1 |
|
||||||
|
| M107 | Statistiken | mittel | SyRS-117 | 1 |
|
||||||
|
| M108 | Indexsuche | mittel | SyRS-118 | 1 |
|
||||||
|
| M109 | Nexus-Rahmen | tief | SyRS-119, SwRS-067 | 2 |
|
||||||
|
| M110 | ServiceBoard | mittel | SyRS-120 | 1 |
|
||||||
|
| M111 | WebCart | tief | SyRS-121, SwRS-043 | 2 |
|
||||||
|
| M112 | WebOffer | tief | SyRS-122, SwRS-044 | 2 |
|
||||||
|
| M113 | Dokumentensignierung | mittel | SyRS-123 | 1 |
|
||||||
|
| M114 | Produktionsaufträge Web | flach | SyRS-124 | 1 |
|
||||||
|
| M115 | SelfCare | mittel | SyRS-125 | 1 |
|
||||||
|
| M116 | Web-Accounts/WebSuite | tief | SyRS-126, SwRS-039, SwRS-042, SwRS-066 | 4 |
|
||||||
|
| M117 | Webservice | tief | SyRS-127, SwRS-055, SwRS-068 | 3 |
|
||||||
|
| M118 | ConnectionManager | flach | SyRS-128 | 1 |
|
||||||
|
| M119 | MyCentron/Dashboard | mittel | SyRS-129 | 1 |
|
||||||
|
| M120 | MyDay | mittel | SyRS-130 | 1 |
|
||||||
|
| M121 | KI-Funktionen | mittel | SyRS-131 | 1 |
|
||||||
|
| M122 | TradePool | flach | SyRS-132 [H] | 1 |
|
||||||
|
| M123 | VoucherManagement | mittel | SyRS-133 | 1 |
|
||||||
|
| M124 | Textbausteine | mittel | SyRS-134 | 1 |
|
||||||
|
| M125 | Tags | mittel | SyRS-135 | 1 |
|
||||||
|
| M126 | Social Media | mittel | SyRS-136 | 1 |
|
||||||
|
| M127 | VideoPortal | flach | SyRS-137 | 1 |
|
||||||
|
| M128 | WebLinks | mittel | SyRS-138 | 1 |
|
||||||
|
| M129 | Mobile | flach | SyRS-139 [H] | 1 |
|
||||||
|
| M130 | ProductMatrix | mittel | SyRS-140 | 1 |
|
||||||
|
| M131 | ItPlanner | flach | SyRS-141 [H] | 1 |
|
||||||
|
| M132 | ExpectedEvents | mittel | SyRS-142 | 1 |
|
||||||
|
| M133 | CPra | flach | SyRS-143 [H] | 1 |
|
||||||
|
| M134 | RiverDivo | mittel | SyRS-144 | 1 |
|
||||||
|
| M135 | Länder/Regionen | mittel | SyRS-145 | 1 |
|
||||||
|
| M136 | Feiertage | flach | SyRS-146 | 1 |
|
||||||
|
| M137 | Wechselkurse/Währungen | mittel | SyRS-147 | 1 |
|
||||||
|
| M138 | Objekt-Fremdreferenzen | mittel | SyRS-148 | 1 |
|
||||||
|
| M139 | Prozesse/Workflows | flach | SyRS-149 [H] | 1 |
|
||||||
|
| M140 | Änderungsverfolgung | flach | SyRS-150 | 1 |
|
||||||
|
| M141 | WPF-Client-Rahmen | tief | SyRS-151, SwRS-056 | 2 |
|
||||||
|
| M142 | Shared Controls | flach | SyRS-152 | 1 |
|
||||||
|
| M143 | Datenzugriff/DAO | mittel | SyRS-153, SwRS-001, SwRS-006 | 3 |
|
||||||
|
| M144 | Gateway | flach | SyRS-154 | 1 |
|
||||||
|
| M145 | Deployment/Setup | flach | SyRS-155 | 1 |
|
||||||
|
| M146 | Lokalisierung | mittel | SyRS-156, SwRS-058 | 2 |
|
||||||
|
|
||||||
|
**Abdeckungssummen:** tief = 33 Module · mittel = 66 Module · flach = 47 Module ·
|
||||||
|
nicht analysiert = 0 Module (Summe 146 = Inventar). **Mindestabdeckung erfüllt:** Jedes Modul
|
||||||
|
besitzt mindestens eine Anforderung; kein Modul musste als `nicht analysiert` geführt werden.
|
||||||
|
Hinweis: Übergreifende Anforderungen (z. B. SyRS-026-028, StRS-Ebene) sind der Übersicht halber
|
||||||
|
nur bei ihrem Hauptmodul gezählt; die Anzahl-Spalte summiert deshalb konservativ (203 Zuordnungen
|
||||||
|
bei 259 Anforderungen; StRS-Anforderungen sind bereichs-, nicht modulbezogen).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Konsistenzcheck über das gesamte Anforderungs-Set
|
||||||
|
|
||||||
|
Die Prüfungen wurden skriptgestützt über die erzeugten Dateien ausgeführt (grep/awk über
|
||||||
|
`StRS.md`, `SyRS.md`, `SwRS.md`).
|
||||||
|
|
||||||
|
| Prüfung | Ergebnis |
|
||||||
|
|---|---|
|
||||||
|
| Doppelte oder mehrfach vergebene IDs | **0** (32 StRS + 156 SyRS + 71 SwRS = 259 eindeutige IDs) |
|
||||||
|
| Anforderungen ohne Beleg | **0** (259 `Belege:`-Abschnitte zu 259 IDs) |
|
||||||
|
| Anforderungen ohne `Übernahmewürdigkeit` | **0** (259/259) |
|
||||||
|
| Anforderungen ohne `Prüfidee` / `Status` / `Konsolidierung` / `Tracelinks` | **0** (jeweils 259/259) |
|
||||||
|
| Tracelinks auf nicht existierende IDs | **0** (alle 188 referenzierten IDs existieren) |
|
||||||
|
| SyRS ohne StRS-Rückverweis | **0** · SwRS ohne SyRS-Rückverweis: **0** |
|
||||||
|
| Nicht rückverlinkte StRS | **0** (jede StRS wird von ≥1 SyRS referenziert) |
|
||||||
|
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung | **0 bekannte Fälle**; als Konsolidierungskandidaten markiert sind: Gerätedaten dreifach (StRS-19, SyRS-020/059/060), Verträge vs. Kundenvereinbarungen (SyRS-044↔SyRS-009), Versand GLS↔Shipcloud (SyRS-069↔070), Inventur alt/neu (SyRS-065), Einstellungen zweigleisig (SyRS-085, SwRS-054), Social-Media-Stream↔Chat/Benachrichtigungen (SyRS-136) |
|
||||||
|
| Abgleich `Hypothesen.md` gegen Inline-Markierungen | **deckungsgleich**: 13 Status-HYPOTHESE-Blöcke (SyRS-055, 089, 106, 109, 111, 112, 132, 139, 141, 143, 149; SwRS-065, 071) = 13 Einträge in `Hypothesen.md`; keine zusätzlichen freien Fragen in der Sammeldatei |
|
||||||
|
|
||||||
|
### Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
|
||||||
|
|
||||||
|
Regel: risikorelevante Anforderungen benötigen mindestens einen `PRIMÄR`-Beleg mit benannter
|
||||||
|
durchsetzender Stelle, andernfalls `[HYPOTHESE]`. Ergebnis: **81 risikorelevante Anforderungen,
|
||||||
|
80 mit PRIMÄR-Beleg, 1 als HYPOTHESE gekennzeichnet (SwRS-071). Kein Verstoß.**
|
||||||
|
|
||||||
|
**Sicherheit/Berechtigungen (Typ Sicherheit; 35 Anforderungen, alle mit PRIMÄR, alle belegt):**
|
||||||
|
|
||||||
|
| ID | Titel (Kurz) | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| StRS-13 | Rollenbasierter Zugriffsschutz | 2 | belegt |
|
||||||
|
| StRS-14 | Anmeldung (AD/Entra, 2FA) | 2 | belegt |
|
||||||
|
| StRS-23 | DSGVO-Compliance | 1 | belegt |
|
||||||
|
| SyRS-005 | Rechnungsstorno-Schutz | 1 | belegt |
|
||||||
|
| SyRS-006 | Rechnungsfestschreibung | 1 | belegt |
|
||||||
|
| SyRS-028 | Filialbezogene Belegrechte | 1 | belegt |
|
||||||
|
| SyRS-036 | Account-Rechteprüfung | 2 | belegt |
|
||||||
|
| SyRS-058 | Einschränkende Helpdesk-Rechte | 1 | belegt |
|
||||||
|
| SyRS-078 | Login mit Sitzungstickets | 3 | belegt |
|
||||||
|
| SyRS-079 | Kontodeaktivierung | 1 | belegt |
|
||||||
|
| SyRS-080 | Gruppenbasierte Rechte | 1 | belegt |
|
||||||
|
| SyRS-081 | Zwei-Faktor-Authentifizierung | 2 | belegt |
|
||||||
|
| SyRS-086 | DSGVO-Bereinigung/Löschrecht | 1 | belegt |
|
||||||
|
| SyRS-090 | API-Zugriffstoken | 2 | belegt |
|
||||||
|
| SyRS-091 | Passwortmanager | 1 | belegt |
|
||||||
|
| SyRS-119 | Nexus Cookie-Auth/HSTS | 1 | belegt |
|
||||||
|
| SyRS-126 | Web-Accounts (getrennte Rechte) | 2 | belegt |
|
||||||
|
| SyRS-151 | Modulfreischaltung Recht+Lizenz | 1 | belegt |
|
||||||
|
| SwRS-016 | Stornoregeln im Detail | 1 | belegt |
|
||||||
|
| SwRS-017 | Festschreibungsmechanik | 1 | belegt |
|
||||||
|
| SwRS-032 | SHA1-Passworthash (Ist-Zustand) | 2 | belegt |
|
||||||
|
| SwRS-033 | Dreifache Deaktivierungslogik | 1 | belegt |
|
||||||
|
| SwRS-034 | Ticket-Lebensdauern | 1 | belegt |
|
||||||
|
| SwRS-036 | Anwendungs-Pflicht-/Verbotsrechte | 1 | belegt |
|
||||||
|
| SwRS-037 | 2FA-Parametrik | 1 | belegt |
|
||||||
|
| SwRS-039 | Getrennte Web-Rechte | 1 | belegt |
|
||||||
|
| SwRS-040 | Token-Kryptomechanik | 1 | belegt |
|
||||||
|
| SwRS-041 | Passwortregeln | 1 | belegt |
|
||||||
|
| SwRS-042 | Web-Login-Beziehungskette | 1 | belegt |
|
||||||
|
| SwRS-043 | WebCart-Sortiments-Isolation | 1 | belegt |
|
||||||
|
| SwRS-056 | Modul-Doppelbedingung | 1 | belegt |
|
||||||
|
| SwRS-059 | Mailumleitung Dev-Builds | 1 | belegt |
|
||||||
|
| SwRS-066 | Belegsperre für Web-Accounts | 1 | belegt |
|
||||||
|
| SwRS-067 | Nexus-Transportsicherheit | 1 | belegt |
|
||||||
|
| SwRS-068 | Webservice-Interceptor-Kette | 1 | belegt |
|
||||||
|
|
||||||
|
**Abrechnung/Fakturierung (46 Anforderungen; 45 mit PRIMÄR, 1 HYPOTHESE):**
|
||||||
|
|
||||||
|
| ID | Titel (Kurz) | PRIMÄR | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| SyRS-004 | Rechnungen erstellen | 1 | belegt |
|
||||||
|
| SyRS-005 | Rechnungsstorno (auch Sicherheit) | 1 | belegt |
|
||||||
|
| SyRS-006 | Festschreibung (auch Sicherheit) | 1 | belegt |
|
||||||
|
| SyRS-007 | Gutschriften | 1 | belegt |
|
||||||
|
| SyRS-010 | Automatische Vertragsabrechnung | 1 | belegt |
|
||||||
|
| SyRS-011 | Klickabrechnung | 1 | belegt |
|
||||||
|
| SyRS-012 | Zeitenabrechnung | 1 | belegt |
|
||||||
|
| SyRS-013 | Anzahlungen | 2 | belegt |
|
||||||
|
| SyRS-018 | Kassenbuch | 1 | belegt |
|
||||||
|
| SyRS-021 | Rappenrundung CH | 2 | belegt |
|
||||||
|
| SyRS-023 | Nummernkreise | 1 | belegt |
|
||||||
|
| SyRS-024 | Belegversand | 1 | belegt |
|
||||||
|
| SyRS-025 | Kreditlimit | 1 | belegt |
|
||||||
|
| SyRS-062 | MSP-Abrechnung | 1 | belegt |
|
||||||
|
| SyRS-071 | Zahlungseingänge | 1 | belegt |
|
||||||
|
| SyRS-072 | Onlinebanking-Zuordnung | 1 | belegt |
|
||||||
|
| SyRS-073 | SEPA-Export | 1 | belegt |
|
||||||
|
| SyRS-074 | Mahnläufe | 2 | belegt |
|
||||||
|
| SyRS-075 | OPOS | 1 | belegt |
|
||||||
|
| SyRS-076 | FiBu-Export | 2 | belegt |
|
||||||
|
| SyRS-077 | Bankverbindungen | 2 | belegt |
|
||||||
|
| SyRS-082 | Lizenzprüfung (Abrechnungsbezug Hersteller) | 1 | belegt |
|
||||||
|
| SyRS-104 | E-Rechnung | 1 | belegt |
|
||||||
|
| SwRS-012 | Rundung über Steuerkorrektur | 1 | belegt |
|
||||||
|
| SwRS-015 | Kreditlimitberechnung | 1 | belegt |
|
||||||
|
| SwRS-018 | Anzahlungsmechanik | 1 | belegt |
|
||||||
|
| SwRS-019 | Intervallfortschreibung | 1 | belegt |
|
||||||
|
| SwRS-020 | Pro-rata-Normalisierung | 1 | belegt |
|
||||||
|
| SwRS-021 | Voraus-/Nachberechnung | 1 | belegt |
|
||||||
|
| SwRS-022 | Kontingentbuchung | 1 | belegt |
|
||||||
|
| SwRS-023 | Kontingent-Änderungslog | 1 | belegt |
|
||||||
|
| SwRS-024 | Klickzähler-Historie | 1 | belegt |
|
||||||
|
| SwRS-025 | Nummernvergabe CAS | 1 | belegt |
|
||||||
|
| SwRS-026 | SEPA-Formate/Mandatssequenz | 1 | belegt |
|
||||||
|
| SwRS-027 | SEPA-Folgen/Rücknahme | 1 | belegt |
|
||||||
|
| SwRS-028 | Banking-Zuordnungsregex | 1 | belegt |
|
||||||
|
| SwRS-029 | DATEV EXTF 700 | 1 | belegt |
|
||||||
|
| SwRS-030 | Mahnstufen/Sperren | 1 | belegt |
|
||||||
|
| SwRS-031 | Zahlungslöschung mit Rückrechnung | 1 | belegt |
|
||||||
|
| SwRS-035 | Floating-Lizenzzählung | 1 | belegt |
|
||||||
|
| SwRS-061 | E-Rechnungs-Erzeugungsregeln | 1 | belegt |
|
||||||
|
| SwRS-062 | ZUGFeRD-Import | 1 | belegt |
|
||||||
|
| SwRS-063 | Pauschalfilter/Zuschläge | 1 | belegt |
|
||||||
|
| SwRS-064 | Sonderartikel-Import | 1 | belegt |
|
||||||
|
| SwRS-070 | Batch-/Paging-Verarbeitung | 1 | belegt |
|
||||||
|
| SwRS-071 | Sammelrechnung Konzern | 0 | **HYPOTHESE** (regelkonform gekennzeichnet) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Selbstbewertung
|
||||||
|
|
||||||
|
**1. Analysetiefe (absolute Zahlen):** Von 146 Inventarmodulen wurden **33 tief**, **66 mittel**
|
||||||
|
und **47 flach** analysiert; **0 Module blieben unanalysiert**. Die Vertiefung folgte der
|
||||||
|
vorgegebenen Risikopriorisierung: Sicherheits-/Anmelde-/Rechtelogik (M69-M72, M80, M116, M117),
|
||||||
|
Abrechnung/Fakturierung (M04, M08, M09, M14, M16, M61-M64, M66, M68, M94) und Berechtigungen
|
||||||
|
(M29, M38, M70, M141) sind tief abgedeckt; die flache Randabdeckung betrifft überwiegend kleine
|
||||||
|
Zusatzmodule und Schnittstellen mit dünnem Codebestand.
|
||||||
|
|
||||||
|
**2. Mindestabdeckung:** Erreicht. Jedes der 146 Module trägt mindestens eine Anforderung; kein
|
||||||
|
Modul musste mit Begründung als `nicht analysiert` geführt werden. 11 Module tragen ihre einzige
|
||||||
|
Anforderung als `[HYPOTHESE]` (M46, M79, M96, M99, M101, M102, M122, M129, M131, M133, M139) –
|
||||||
|
das ist bewusste Abgrenzung, keine Lücke im Sinne der Mindestabdeckung.
|
||||||
|
|
||||||
|
**3. Dünne Belegstellen (hoher SEKUNDÄR-/KONTEXT- oder Hypothesenanteil):**
|
||||||
|
- Die 13 Hypothesen (siehe `Hypothesen.md`) stützen sich ausschließlich auf SEKUNDÄR-Belege
|
||||||
|
(Dateiexistenz, Klassennamen) – v. a. kleine Schnittstellenmodule (docuFORM, COP, Telekom Dive,
|
||||||
|
TANSS, CPra, TradePool, Mobile, ItPlanner, Workflows, Telemetrie, ExternesHelpdesk) sowie
|
||||||
|
AutoLock und Sammelrechnung.
|
||||||
|
- StRS-Belege sind konstruktionsbedingt häufig SEKUNDÄR/KONTEXT (Geschäftsziele sind nicht
|
||||||
|
direkt im Code kodiert); die zugehörigen SyRS/SwRS tragen die PRIMÄR-Belege.
|
||||||
|
- Flach eingestufte Module (47) stützen sich auf Dateibestand und Methodensignaturen ohne
|
||||||
|
vollständige Methodenlektüre; die Aussagen sind bewusst auf das dadurch Belegbare begrenzt.
|
||||||
|
- Beim Passwortmanager (SyRS-091) ist die Existenz der Ver-/Entschlüsselung belegt, das
|
||||||
|
Kryptoverfahren selbst aber ungeprüft.
|
||||||
|
|
||||||
|
**4. Hypothesenführung:** 13 Hypothesen (5,0 % des Sets) wurden geführt – die Analyse kommt
|
||||||
|
also nicht ohne offene Punkte aus; eine Begründung für „null Hypothesen" entfällt.
|
||||||
|
|
||||||
|
**5. Erkenntnisse für eine Folge-Iteration (Nachschlagsempfehlungen):**
|
||||||
|
1. **Hypothesenauflösung:** Die 13 Hypothesen sind konkret adressierbar (Methodenanalyse von
|
||||||
|
TanssBL, TelekomDiveBL, TradePoolBL, MobileBL, CPraConnectorBL, Workflow-Engine,
|
||||||
|
docuFORM-Konsument, COP-Aufrufer, AutoLock-Mechanik, Sammelrechnungs-Bündelung,
|
||||||
|
Telemetrie-Datenfluss) – geschätzt je Modul wenige Dateien.
|
||||||
|
2. **ReceiptBL-Resttiefe:** Die 10.000+-Zeilen-Klasse ReceiptBL wurde gezielt (Limit, Rechte,
|
||||||
|
Concurrency, Logs), aber nicht vollständig gelesen; SaveReceipt-Callbacks, Belegkopier- und
|
||||||
|
Versandpfade bieten weitere Regeln (z. B. automatisches Schließen,
|
||||||
|
AutomaticallyCloseReceiptHelperBL).
|
||||||
|
3. **Steuerlogik:** TaxBL und die MwSt-Zuordnung (innergemeinschaftlich, Drittland,
|
||||||
|
Reverse-Charge) wurden nicht vertieft – für ein Abrechnungssystem prüfenswert.
|
||||||
|
4. **Provisionen:** ReceiptProvisionBL/Provision-Schemata (WPF-Modul Provision) sind nur am Rand
|
||||||
|
erfasst.
|
||||||
|
5. **Web-Rechtekatalog:** Die WebRights-Einzelrechte (Portalumfang) wurden nicht enumeriert –
|
||||||
|
für den Zuschnitt des Zielportals nützlich.
|
||||||
|
6. **UI-Pflichtfelder/Validierungen im Client:** Die WPF-Views enthalten weitere clientseitige
|
||||||
|
Validierungen, die serverseitig nicht sichtbar sind; für Feature-Parität stichprobenhaft
|
||||||
|
erheben.
|
||||||
|
7. **Konsolidierungsentscheidungen vorbereiten:** Für die markierten Kandidaten (Gerätedaten
|
||||||
|
dreifach, Inventur alt/neu, Einstellungen zweigleisig, Versandwege, Vereinbarungen vs.
|
||||||
|
Verträge) je eine Feldabgleich-Matrix erstellen, damit Fachexperten in Schritt 7 entscheiden
|
||||||
|
können.
|
||||||
|
8. **Werkzeuggrenze:** Die Change-Historie (Git-Log) stand als Artefakt nicht im Fokus dieser
|
||||||
|
Iteration; Commit-Messages könnten KONTEXT-Belege für Übernahmewürdigkeits-Einstufungen
|
||||||
|
(veraltet/Workaround) liefern.
|
||||||
|
|
||||||
|
**Methodische Anmerkung:** Alle Zahlen dieses Berichts (IDs, Belegabdeckung, Tracelink-Ziele,
|
||||||
|
Hypothesenabgleich) wurden skriptgestützt aus den abgegebenen Dateien selbst ermittelt, nicht
|
||||||
|
manuell gezählt.
|
||||||
+70
@@ -0,0 +1,70 @@
|
|||||||
|
# Glossar
|
||||||
|
|
||||||
|
Domänen- und Systembegriffe, wie sie in den Anforderungen (StRS/SyRS/SwRS) verwendet werden.
|
||||||
|
Technische Bezeichner (Klassen, Tabellen, Spalten) bleiben in Originalsprache.
|
||||||
|
|
||||||
|
| Begriff | Definition |
|
||||||
|
|---|---|
|
||||||
|
| Abholliste | Belegart für die Abholung von Geräten/Waren beim Kunden (Tabellen `AbholKopf`/`AbholPos`). |
|
||||||
|
| Account | Zentraler Geschäftspartner-Datensatz (Kunde, Lieferant, Interessent) im neuen Datenmodell (`Accounts`, `AccountCustomers`, `AccountSuppliers`); Alt-Tabellen: `Kunden`, `Kreditor`. |
|
||||||
|
| AccountDevice | Zweite Datenhaltung für Kundengeräte (Seriennummer, Modell, Garantie); Konsolidierungskandidat mit Stammblatt und AssetManagement. |
|
||||||
|
| Aktionspreis | Zeitlich begrenzter Einkaufs-/Verkaufspreis je Artikel (Tabelle `HerstellerArtikAktionspreis`). |
|
||||||
|
| AnlageLog | Gemeinsame Log-Tabelle aller Belegarten; Belegart über `AnlageArt`-Code (1=Angebot … 4=Rechnung, 22=Vertrag). |
|
||||||
|
| Anwendungs-GUID (ApplicationKind) | GUID, die eine anmeldeberechtigte Anwendung identifiziert und lizenziert (z. B. c-entron.NET, ServiceBoard, Outlook-Add-In). |
|
||||||
|
| AppUser | Internes Benutzerkonto eines Mitarbeiters (Tabelle `Sichbenu`); Gegenstück: Web-Account für Endkunden. |
|
||||||
|
| AssetManagement (DocuBoard) | Dritte Gerätedatenhaltung: automatisiert erhobene IT-Inventardaten (AD-Scans, SNMP) je Kunde. |
|
||||||
|
| Barcode/Seriennummer | Serialisierte Bestandseinheit mit Zustandsautomat (`BarcodeState`, 20 Zustände) über Lager, Belege, RMA, Stammblatt. |
|
||||||
|
| Barrechnung | Rechnung mit `IsCashAsset`; erzeugt Kassenbuchbuchungen und ist vom Storno ausgeschlossen. |
|
||||||
|
| Belegkette / Weiterverarbeitung | Überführung eines Belegs in Folgebelege (Angebot→Auftrag→Lieferschein→Rechnung) mit gespeicherter Herkunftsbeziehung ("Forwarding"). |
|
||||||
|
| Beleg (Receipt) | Oberbegriff für Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholliste, Vertrag sowie die Lieferanten-Gegenstücke; gemeinsame Basisklasse `ReceiptBase`. |
|
||||||
|
| BillingKind (Voraus-/Nachberechnung) | Abrechnungsart eines Vertrags: Vorausberechnung (`Billingadvance`) vor Leistungsbeginn oder nachträgliche Berechnung nach Periodenende. |
|
||||||
|
| C-FLOW | Produktname der Ticketvorlagen (automatische/manuelle Ticketerzeugung aus Vorlagen). |
|
||||||
|
| ConcurrencyControlGuid | Beleg-Versionsstempel für optimistische Sperre; Abweichung ⇒ Fehler "ChangedByOtherInstance". |
|
||||||
|
| DunningStop (Mahnsperre) | Kennzeichen auf Kunde oder Rechnung, das die Aufnahme in Mahnläufe verhindert. |
|
||||||
|
| EDI | Elektronischer Belegaustausch mit Distributoren (ALSO, ALSO CH, Alltron, Herweck, Komsa, OpenTrans 2.1, EGIS). |
|
||||||
|
| Eskalationsstufe | Eine von bis zu drei zeitgesteuerten Eskalationen eines Tickets (Wartezeiten `WaitHourEsc1-3`) innerhalb definierter Arbeitszeitfenster. |
|
||||||
|
| ESR | Schweizer Einzahlungsschein mit Referenznummer; Felder am Rechnungsbeleg (`EsrReferenceNumber` u. a.). |
|
||||||
|
| Festschreibung | Unveränderlichmachen einer Rechnung (`RechKopf.IsFixed=1`) mit Pflicht-Logeintrag; GoBD-relevant. |
|
||||||
|
| Filiale (Branch) | Organisationseinheit unterhalb des Mandanten mit eigenen Nummernkreisen und Lagerzuordnung; einschränkende Rechte binden Benutzer an ihre Filiale. |
|
||||||
|
| Floating-Lizenz | Lizenzzählung über gleichzeitig aktive Sitzungstickets je Anwendungs-GUID. |
|
||||||
|
| Gutschrift | Belegart zur Minderung einer Forderung (`GutKopf`/`GutPos`). |
|
||||||
|
| Helpdesk / Ticket | Servicevorgang mit Kunde, Status (konfigurierbar), Typ, Priorität, Kategorien, Bearbeitern, Zeiterfassungen. |
|
||||||
|
| I3D | Systemweiter Primärschlüsselname (Identity-Spalte) aller Tabellen. |
|
||||||
|
| Kontingent | Vertraglich vereinbartes Leistungsvolumen (Stunden oder Betrag) mit Regeln für Überbuchung, Restmitnahme und abweichende Kontingentintervalle. |
|
||||||
|
| Klickabrechnung | Nutzungsabrechnung über Gerätezählerstände (Drucker/Kopierer) mit Freimengen und Staffelpreisen. |
|
||||||
|
| Kreditlimit | Kundenlimit; Prüfart netto/brutto/keine (`CreditLimitCalculationKind`), Überschreitung erzeugt Bestätigungsdialog. |
|
||||||
|
| Leitweg-ID | Empfänger-Routing-Kennung der XRechnung; am Kunden hinterlegt (`IAccountCustomer.LeitwegID`). |
|
||||||
|
| Lizenz (GUID-Lizenz) | Produkt-/Funktionsfreischaltung als GUID mit Anzahl, Gültigkeitsdatum und Maximalversion; Quelle: Lizenzserver. |
|
||||||
|
| Mandant (Mandator) | Rechtlich selbständige Firmeneinheit mit eigenen Bankdaten, SEPA-Gläubiger-ID und Nummernkreisen. |
|
||||||
|
| Mandat (SEPA-Mandat) | Einzugsermächtigung an einer Bankverbindung mit Sequenz (First/Recurrent/Last/Single) und Gültigkeit. |
|
||||||
|
| MasterDataList → siehe Stammblatt | |
|
||||||
|
| MSP | Managed Services Provider; MSP-Sammler erfassen nutzungsbasierte Mengen (z. B. Lizenzen) zur Vertragsabrechnung. |
|
||||||
|
| Nummernkreis (NumberGroup) | Konfigurierbarer Nummernbereich je Objektart, Mandant und Filiale mit Intervall und aktuellem Stand. |
|
||||||
|
| Nexus | Blazor-Webanwendung der Suite (ServiceBoard, Kundenportal/WebCart, WebOffer, Verwaltung). |
|
||||||
|
| OPOS | Offene-Posten-Verwaltung; Abgleich der Zahlungsstände mit der Finanzbuchhaltung. |
|
||||||
|
| Pro-rata-Normalisierung | Anteilige Berechnung der ersten Vertragsperiode nach Kalendertagen (`IsNormalize`). |
|
||||||
|
| Rappenrundung | Schweizer Rundung des Bruttobetrags auf 0,05 durch Anpassung des Steueranteils (Einstellung `CommercialRoundCH`). |
|
||||||
|
| Recht (AppRight) | Einzelberechtigung (750 Konstanten in `UserRightsConst`); Vergabe ausschließlich über Gruppen (`Sichtrus`/`Sichmemb`). |
|
||||||
|
| Einschränkendes Recht | Recht, das die Sichtbarkeit verengt statt erweitert (z. B. "Tickets anzeigen - nur eigene"). |
|
||||||
|
| RMA | Retouren-/Reparaturvorgang; genau eine RMA je Ticket (Unique Index auf `Rma.HelpdeskI3D`). |
|
||||||
|
| RMM | Remote Monitoring & Management; liefert Geräte-/Nutzungsdaten für die Vertragsabrechnung. |
|
||||||
|
| Sammelrechnung | Konsolidierte Rechnung über mehrere Verträge eines Kunden/Konzerns (`CollectInvoice`); Bündelungsregel als Hypothese offen. |
|
||||||
|
| SEPA-Export | Erzeugung von pain.008-Lastschriftdateien mit Folgewirkungen (Exportkennzeichen, optional Rechnungsabschluss, Mandatssequenz). |
|
||||||
|
| ServiceBoard | Webbasierter Ticketarbeitsplatz der Techniker (Kanban, Zeiten, Mails, Planung). |
|
||||||
|
| Sitzungsticket | Zeitlich begrenzte Sitzungskennung des Webservice (Standard 30 min, gleitend verlängert). |
|
||||||
|
| Skontosperre | Artikelkennzeichen `NoEarlyPaymentDiscountAllowed`; nimmt Positionen aus der Skontobasis aus. |
|
||||||
|
| Sonderabkommen (SpecialAgreement) | Einkaufsvereinbarung mit Lieferanten (eigener EK oder EK-Reduktion) je Artikel. |
|
||||||
|
| Sonderpreis (Kundensonderpreis) | Kundenindividuelle Preisregel je Artikel in fünf Arten (Fixpreis, EK-Aufschlag, Abschläge auf UVP/VK/Listenpreis); definiert zugleich das WebCart-Sortiment. |
|
||||||
|
| Stammblatt (MasterDataList) | Gerätestammsatz für die Abrechnung (Seriennummer, Zähler, Vertrag, Ursprungsrechnung); Konsolidierungskandidat mit AccountDevice/AssetManagement. |
|
||||||
|
| Staffelpreis (VolumePrice) | Mengenabhängige Preisstufen mit vier Verkaufspreislisten (VK1-VK4) und Staffel-EK. |
|
||||||
|
| Stundenzuschlagssatz | Zeitfensterbezogener Zuschlag auf Servicezeiten (z. B. Nacht/Wochenende), als Überlappung je Zeiterfassung berechnet. |
|
||||||
|
| Ticket → siehe Helpdesk | |
|
||||||
|
| TimerBilling (Zeitenabrechnung) | Überführung abrechenbarer Ticketzeiten in Auftrags-/Rechnungspositionen ohne Doppelabrechnung. |
|
||||||
|
| Übernahmewürdigkeit | Bewertungsfeld dieser Spezifikation: übernehmen / Workaround / Sonderfall / veraltet. |
|
||||||
|
| Vertrag (ReceiptContract) | Belegart für Dauerleistungen mit Abrechnungsintervall, Kontingenten, Verlängerung und automatischer Abrechnung (`VertragKopf`/`VertragPos`). |
|
||||||
|
| VertragRechKopfZuordnung | Verknüpfungstabelle Vertrag↔Rechnung je Abrechnungslauf inkl. Kontingentbuchung und Zwischenrechnungskennzeichen. |
|
||||||
|
| Web-Account | Endkunden-Login für das Portal (getrenntes Rechtesystem `WebRights`); Voraussetzung: durchgehend aktive Kette Kontakt→Adresse→Kunde. |
|
||||||
|
| WebCart | Shop des Kundenportals; Sortiment = Artikel mit aktiven Sonderpreisen des Kunden. |
|
||||||
|
| WebOffer | Online-Angebotsansicht mit Freigabe-Zustandsautomat (`WebReceiptState`, 9 Zustände inkl. Signatur). |
|
||||||
|
| XRechnung / ZUGFeRD | Strukturierte E-Rechnungsformate; Erzeugung je Rechnung mit Leitweg-ID, Einlesen von ZUGFeRD 2.1-Eingangsrechnungen. |
|
||||||
|
| Zwischenrechnung (Kontingent) | Kontingentbuchung bei abweichendem Kontingent- vs. Abrechnungsintervall (`DifferContingentInterval`). |
|
||||||
+30
@@ -0,0 +1,30 @@
|
|||||||
|
# Hypothesen
|
||||||
|
|
||||||
|
Diese Datei enthält **genau die Anforderungen mit `[HYPOTHESE]`-Markierung** aus StRS/SyRS/SwRS
|
||||||
|
(Status `HYPOTHESE`) – deckungsgleich mit den Inline-Markierungen der Spezifikationen.
|
||||||
|
Offene Punkte ohne zugehörige Anforderung stehen in der Selbstbewertung des Analyseberichts.
|
||||||
|
|
||||||
|
Gesamtzahl: **13 Hypothesen** (11 × SyRS, 2 × SwRS, 0 × StRS).
|
||||||
|
|
||||||
|
| Nr. | ID | Titel | Hypothese (Kurzfassung) | Fehlende Information zur Bestätigung |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | SyRS-055 | Anbindung externer Helpdesk-Systeme | Tickets werden mit externen Helpdesk-Systemen ausgetauscht. | Nur `ExternalHelpdeskConfigurationBL.cs` gefunden; Synchronisationslogik (Richtung, Umfang, Zielsysteme) fehlt im analysierten Code. |
|
||||||
|
| 2 | SyRS-089 | Telemetrie und Profiling | Nutzungs-/Leistungsdaten werden zur Produktverbesserung erfasst. | Inhalt, Übertragungsweg und Empfänger der Telemetriedaten (TelemetryBL/ProfilerBL) nicht verifiziert; DSGVO-Einordnung offen. |
|
||||||
|
| 3 | SyRS-106 | docuFORM-Anbindung | Gerätezähler-/Flottendaten werden von docuFORM abgerufen und der Klickabrechnung bereitgestellt. | Konsumierender Codepfad vom `DocuFormRestApiClient` zur Zählerübernahme nicht nachvollzogen. |
|
||||||
|
| 4 | SyRS-109 | COP-Datenzugriff | Produkt-/Preisdaten aus COP dienen der Artikelanreicherung bzw. dem Einkauf. | Aufrufer und fachlicher Zweck des `CopApi`-Clients nicht identifiziert. |
|
||||||
|
| 5 | SyRS-111 | Telekom-Dive-Schnittstelle | Austausch von Auftrags-/Bestandsdaten mit dem Telekom-Dive-Portal. | Methoden der `TelekomDiveBL` und zugehörige Views nicht analysiert; Richtung und Inhalt unklar. |
|
||||||
|
| 6 | SyRS-112 | TANSS-Datenübernahme | Übernahme von Tickets/Kunden/Zeiten aus TANSS (vermutlich Migration). | Unklar, ob einmalige Migrations- oder laufende Austauschschnittstelle; Methodenanalyse `TanssBL` fehlt. |
|
||||||
|
| 7 | SyRS-132 | TradePool-Anbindung | Import von Artikel-/Preisdaten einer Handelsplattform "TradePool". | Datenquelle, Aktualität und fachlicher Nutzungskontext der Plattform unbelegt. |
|
||||||
|
| 8 | SyRS-139 | Mobile Unterstützung | Versorgung mobiler Clients mit Mitarbeiter-/Kontaktdaten. | Konsumierende Mobile App und tatsächlicher Funktionsumfang unbekannt (nur `MobileBL` mit 3 Methoden). |
|
||||||
|
| 9 | SyRS-141 | ItPlanner | Strukturierung von IT-Planungsobjekten über kategorisierte Checklisten. | Nur `ChecklistVirtualObjectCategoryBL` gefunden; restlicher Modulzweck (UI, Prozesse) unklar. |
|
||||||
|
| 10 | SyRS-143 | CPra-Webhook-Anbindung | Übergabe von Vorgängen mit Kunden-/Ticketbezug an ein Partnersystem "CPra" über Webhooks. | Identität des Zielsystems CPra und ausgelöste Prozesse unbekannt. |
|
||||||
|
| 11 | SyRS-149 | Prozess-/Workflow-Definitionen | Grafisch definierte Workflows werden an Objekten ausgeführt. | Ausführungssemantik (Trigger, Engine, Schrittausführung) nicht nachvollzogen; nur Definitionsverwaltung belegt. |
|
||||||
|
| 12 | SwRS-065 | Automatische Belegsperre (AutoLock) | Belege/Tickets werden beim Öffnen pessimistisch gesperrt. | Sperrmechanik (Sperrtabelle, Timeout, Entsperrung) nur über Parameternamen `autoLockIfNewReceipt`/`IgnoreLock` indiziert. |
|
||||||
|
| 13 | SwRS-071 | Sammelrechnung für Konzerne | Mehrere Verträge werden in einer Sammelrechnung gebündelt und an Konzernempfänger versendet. | Bündelungskriterien (welche Verträge in eine Rechnung) nicht verifiziert; nur Empfänger-/Vorlagenlogik belegt. |
|
||||||
|
|
||||||
|
## Vollständige Anforderungsblöcke
|
||||||
|
|
||||||
|
Die vollständigen Blöcke stehen in den jeweiligen Spezifikationen:
|
||||||
|
|
||||||
|
- SyRS-055, SyRS-089, SyRS-106, SyRS-109, SyRS-111, SyRS-112, SyRS-132, SyRS-139, SyRS-141, SyRS-143, SyRS-149 → `SyRS.md`
|
||||||
|
- SwRS-065, SwRS-071 → `SwRS.md`
|
||||||
+778
@@ -0,0 +1,778 @@
|
|||||||
|
# StRS – Stakeholder Requirements Specification
|
||||||
|
|
||||||
|
**System:** c-entron ERP-Suite (Branchen-ERP für IT-Systemhäuser)
|
||||||
|
**Quelle:** Reverse Requirements Engineering aus der Codebasis, statische Analyse
|
||||||
|
**Norm:** ISO/IEC/IEEE 29148:2018, Ebene Stakeholder-Anforderungen
|
||||||
|
**Hinweis:** Alle Aussagen sind aus Artefakten der Codebasis abgeleitet. `BL/` steht für
|
||||||
|
`src/backend/Centron.BL/`. Die fachliche Sicht wurde aus Modulstruktur, durchgesetzten Regeln
|
||||||
|
und Benutzertexten rekonstruiert; direkte Stakeholder-Aussagen (Interviews, Lastenhefte) lagen
|
||||||
|
nicht vor, weshalb StRS-Belege überwiegend `SEKUNDÄR`/`KONTEXT` sind. Die zugehörigen
|
||||||
|
Systemregeln sind auf SyRS-/SwRS-Ebene mit `PRIMÄR`-Belegen unterlegt (siehe Tracelinks).
|
||||||
|
|
||||||
|
**Identifizierte Akteure (aus Rechten, Modulen und UI-Texten):**
|
||||||
|
Vertrieb/Innendienst, Servicetechniker, Lagermitarbeiter, Buchhaltung/Controlling,
|
||||||
|
Administrator, Geschäftsleitung, Endkunde (Web-Account im Kundenportal),
|
||||||
|
Lieferant/Distributor (EDI), Fremdsysteme (RMM, TANSS, RiverSuite, docuFORM).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-01
|
||||||
|
Titel: Einheitliche Verwaltung von Geschäftspartnern (Accounts)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Vertrieb/Innendienst
|
||||||
|
Vorbedingung: Benutzer ist angemeldet und besitzt die Account-Rechte.
|
||||||
|
Fakt: Die Codebasis führt Kunden, Lieferanten und Interessenten in einem gemeinsamen
|
||||||
|
Account-Modell (Tabellen Accounts/AccountCustomers/AccountSuppliers, Alt-Tabellen
|
||||||
|
Kunden/Kreditor) mit Rechteprüfung für Anlegen/Bearbeiten/Löschen.
|
||||||
|
Aussage: Das System soll alle Geschäftspartner (Kunden, Lieferanten, Interessenten) zentral
|
||||||
|
mit Adressen und Ansprechpartnern verwalten.
|
||||||
|
Ergebnis: Ein Geschäftspartner ist genau einmal erfasst und für alle Module referenzierbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Accounts/AccountBL.cs:1305-1366 (CheckRightsFromUser mit CREATE_CUSTOMER/EDIT/DELETE, Fehlermeldungen "Fehlende Rechte um Accounts zu erstellen") - Begründung: durchgesetzte Kernoperationen des Accountstamms.
|
||||||
|
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql (Tabellen Accounts, AccountCustomers, AccountSuppliers, Kunden, Kreditor) - Begründung: Datenmodell der Partnerverwaltung.
|
||||||
|
Prüfidee: Ein Benutzer ohne CREATE_CUSTOMER-Recht kann keinen Account anlegen; mit Recht wird der Account angelegt und ist in Verkaufs- und Servicebelegen auswählbar.
|
||||||
|
Tracelinks: SyRS-036, SyRS-037, SwRS-051
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - zentrale Stammdatenbasis jedes ERP.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-02
|
||||||
|
Titel: Durchgängige Vertriebsbelegkette
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Vertrieb/Innendienst
|
||||||
|
Vorbedingung: Kunde ist angelegt.
|
||||||
|
Fakt: Die Codebasis implementiert Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift
|
||||||
|
und Abholliste als Belegarten mit gemeinsamer Basisklasse und Weiterverarbeitung
|
||||||
|
(Forwarding) zwischen den Arten.
|
||||||
|
Aussage: Das System soll den Vertriebsprozess als Belegkette von Angebot über Auftrag und
|
||||||
|
Lieferschein bis Rechnung/Gutschrift abbilden, wobei Folgebelege aus Vorgängerbelegen
|
||||||
|
entstehen.
|
||||||
|
Ergebnis: Jeder Beleg kennt seine Ursprungsbelege; Mengen und Werte fließen in Folgebelege.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs (gemeinsame Basisklasse) und BL/Sales/Receipts/ReceiptBL.cs:1563/2462 (ValidateReceiptForwarding) - Begründung: Belegkette und geprüfte Weiterverarbeitung sind implementiert.
|
||||||
|
- [KONTEXT] docs/reference/receipts/receipts-backend-architecture.md - Begründung: beschreibt die Belegarten und deren Tabellen.
|
||||||
|
Prüfidee: Aus einem Angebot wird ein Auftrag erzeugt; der Auftrag referenziert das Angebot; aus dem Auftrag entstehen Lieferschein und Rechnung mit übernommenen Positionen.
|
||||||
|
Tracelinks: SyRS-001, SyRS-002, SyRS-003, SyRS-004, SyRS-007, SyRS-008, SyRS-026
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Kernprozess des Vertriebs.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-03
|
||||||
|
Titel: Wiederkehrende Abrechnung über Verträge
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung/Controlling
|
||||||
|
Vorbedingung: Vertrag mit Abrechnungsintervall ist erfasst.
|
||||||
|
Fakt: Verträge (VertragKopf/VertragPos) tragen Abrechnungsintervall, Abrechnungsart und
|
||||||
|
das Kennzeichen automatische Abrechnung; AutomaticFacturaBL erzeugt daraus Rechnungen.
|
||||||
|
Aussage: Das System soll Dauerschuldverhältnisse (Wartung, Miete, Managed Services) über
|
||||||
|
Verträge mit definierten Abrechnungsintervallen automatisch fakturieren.
|
||||||
|
Ergebnis: Zum Stichtag entstehen Rechnungen für alle fälligen Verträge ohne manuelle Einzelerfassung.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs:1474-1627 (NextDate/SetNextBillingDate/ContractForBilling) - Begründung: Intervallfortschreibung und Fälligkeitsermittlung sind implementiert.
|
||||||
|
- [KONTEXT] docs/reference/receipts/contracts-backend.md - Begründung: beschreibt Abrechnungsintervalle und AutomaticFacturaBL.
|
||||||
|
Prüfidee: Ein Monatsvertrag mit Beginn 01.01. erzeugt bei Abrechnung bis 31.03. drei Rechnungen mit korrekten Leistungszeiträumen.
|
||||||
|
Tracelinks: SyRS-009, SyRS-010, SwRS-019, SwRS-020, SwRS-021
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - zentrales Geschäftsmodell der Zielbranche (Systemhäuser/MSP).
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-04
|
||||||
|
Titel: Nutzungsbasierte Abrechnung (Zähler, Kontingente, MSP)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung/Controlling
|
||||||
|
Vorbedingung: Vertrag mit Zähler- oder Kontingentbezug besteht.
|
||||||
|
Fakt: Die Codebasis verwaltet Gerätezähler (Klickzähler) mit Historie, Freimengen und
|
||||||
|
Staffelpreisen sowie Vertragskontingente mit Überbuchung/Restmitnahme; MSP-Kollektoren
|
||||||
|
liefern nutzungsbasierte Mengen.
|
||||||
|
Aussage: Das System soll verbrauchsabhängige Leistungen (Druckklicks, Stundenkontingente,
|
||||||
|
MSP-Lizenzen) erfassen und periodengerecht abrechnen.
|
||||||
|
Ergebnis: Nutzungsmengen werden je Periode bewertet, mit Freimengen/Kontingenten verrechnet und fakturiert.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs:1098-1245 (StoreBookedContingent inkl. Überbuchung/Restmitnahme) - Begründung: Kontingentverrechnung ist durchgesetzte Logik.
|
||||||
|
- [PRIMÄR] ebd.:1248-1256 (UpdClickCounterHistory) - Begründung: Klickzähler werden je Rechnungsposition historisiert.
|
||||||
|
- [SEKUNDÄR] BL/Statistics/MspCollectors/MspCollectorsBL.cs - Begründung: MSP-Mengenerfassung vorhanden.
|
||||||
|
Prüfidee: Ein Klickvertrag mit Freimenge X und Zählerständen erzeugt eine Rechnung nur über die Menge oberhalb X.
|
||||||
|
Tracelinks: SyRS-011, SyRS-062, SwRS-022, SwRS-024
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Differenzierungsmerkmal für MSP-Geschäft.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-05
|
||||||
|
Titel: Servicegeschäft über Tickets mit abrechenbarer Zeiterfassung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Servicetechniker
|
||||||
|
Vorbedingung: Kunde vorhanden; Techniker angemeldet.
|
||||||
|
Fakt: Helpdesk-Tickets tragen Kunde, Status, Kategorien, Bearbeiter und Zeiterfassungen
|
||||||
|
(HelpdeskTimer) mit Abrechnungsstatus; TimerBilling überführt Zeiten in Belege.
|
||||||
|
Aussage: Das System soll Serviceleistungen als Tickets führen, darauf erfasste Arbeitszeiten
|
||||||
|
dokumentieren und die abrechenbaren Zeiten in Rechnungen überführen.
|
||||||
|
Ergebnis: Jede abrechenbare Minute ist einem Ticket zugeordnet und wird genau einmal fakturiert.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs:233-383 (SearchTimers mit OnlyCalculable, AlreadyBilledTime) - Begründung: Abrechnungsselektion der Zeiten ist implementiert.
|
||||||
|
- [SEKUNDÄR] CentronRights.md Abschnitt Helpdesk - Begründung: dokumentiert die Ticket-/Zeitrechte fachlich.
|
||||||
|
Prüfidee: Eine auf einem Ticket erfasste abrechenbare Zeit erscheint in der Zeitenabrechnung und nach Fakturierung nicht erneut.
|
||||||
|
Tracelinks: SyRS-045, SyRS-049, SyRS-012, SwRS-063
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Kern des Servicegeschäfts.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-06
|
||||||
|
Titel: Fristen- und Eskalationsüberwachung im Service
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Serviceleitung
|
||||||
|
Vorbedingung: Eskalationstypen sind konfiguriert.
|
||||||
|
Fakt: EscalationBL prüft Tickets gegen bis zu drei Eskalationsstufen mit Wartezeiten,
|
||||||
|
Arbeitszeitfenstern und Wochenendregeln und versendet Eskalationsmails.
|
||||||
|
Aussage: Das System soll überfällige Tickets automatisch erkennen und mehrstufig eskalieren.
|
||||||
|
Ergebnis: Verantwortliche werden zeitgestuft benachrichtigt; Eskalationen sind protokolliert.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Sales/Support/Escalation/EscalationBL.cs:223-332 (DoEscalation, ShouldEscalated mit WaitHourEsc1-3, Sa/So-Flags) - Begründung: Eskalationsregeln sind durchgesetzte Logik.
|
||||||
|
Prüfidee: Ein Ticket ohne Reaktion überschreitet die Stufe-1-Wartezeit innerhalb des Arbeitszeitfensters und löst genau eine Stufe-1-Mail aus.
|
||||||
|
Tracelinks: SyRS-048, SwRS-049
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - SLA-Erfüllung ist vertragsrelevant.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-07
|
||||||
|
Titel: Bestandsführung mit Seriennummernverfolgung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Lagermitarbeiter
|
||||||
|
Vorbedingung: Artikel sind angelegt.
|
||||||
|
Fakt: Bestände werden je Lager geführt; serialisierte Einheiten (Barcodes) durchlaufen
|
||||||
|
einen Zustandsautomaten von "im Lager" über Belege bis Stammblatt/RMA.
|
||||||
|
Aussage: Das System soll Lagerbestände artikel- und lagergenau führen und serialisierte
|
||||||
|
Geräte über ihren gesamten Lebenszyklus (Einkauf, Lager, Verkauf, Service) verfolgen.
|
||||||
|
Ergebnis: Zu jeder Seriennummer ist der aktuelle Verbleib feststellbar; Bestände stimmen mit Belegbewegungen überein.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.Interfaces/Warehousing/BarcodeState.cs:5-30 (Zustände InStock…ManuallyBookedOut) - Begründung: Lebenszyklus ist als Enum-Zustandsautomat kodiert.
|
||||||
|
- [PRIMÄR] BL/Warehousing/StockManagement/ArticleStockBL.cs:47-61 (UpdateArticleStock/IncreaseArticleStock) - Begründung: Bestandsfortschreibung ist implementiert.
|
||||||
|
Prüfidee: Wareneingang einer Seriennummer setzt Zustand InStock; Lieferung an Kunden ändert ihn in InDeliveryList/InInvoice; der Lagerbestand sinkt entsprechend.
|
||||||
|
Tracelinks: SyRS-063, SyRS-064, SyRS-067, SwRS-045, SwRS-046
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Voraussetzung für Gewährleistung und Service.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-08
|
||||||
|
Titel: Einkauf über Distributoren mit elektronischem Belegaustausch
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Einkauf
|
||||||
|
Vorbedingung: Distributor-EDI-Zugang ist konfiguriert.
|
||||||
|
Fakt: Die Codebasis enthält Lieferantenbelegarten und EDI-Anbindungen (ALSO, ALSO CH,
|
||||||
|
Alltron, Herweck, Komsa, OpenTrans 2.1, EGIS) für Bestellungen, Auftragsbestätigungen,
|
||||||
|
Lieferavis und Rechnungen.
|
||||||
|
Aussage: Das System soll Bestellungen an Distributoren elektronisch übertragen und deren
|
||||||
|
Rückbelege (Bestätigung, Lieferschein, Rechnung) automatisch einlesen und zuordnen.
|
||||||
|
Ergebnis: Einkaufsbelege entstehen ohne manuelle Doppelerfassung; Seriennummern und Preise werden übernommen.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/EDI/SupplierEdiBL.cs (+ Partial-Klassen je Lieferant) - Begründung: Verarbeitung der Distributor-Dateien ist implementiert.
|
||||||
|
- [KONTEXT] docs/reference/edi/edi-architecture.md - Begründung: beschreibt Ablauf Download→Parsen→Zuordnung.
|
||||||
|
Prüfidee: Eine per EDI empfangene Lieferantenrechnung wird der Bestellung zugeordnet und als Eingangsbeleg angelegt.
|
||||||
|
Tracelinks: SyRS-029, SyRS-030, SyRS-031, SyRS-103, SyRS-110
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - hohes Belegvolumen im Distributionsgeschäft.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-09
|
||||||
|
Titel: Zahlungsabwicklung inklusive SEPA-Lastschrift und Onlinebanking
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung
|
||||||
|
Vorbedingung: Bankverbindungen und Mandate sind hinterlegt.
|
||||||
|
Fakt: Die Codebasis erzeugt SEPA-Lastschriftdateien (pain.008-Varianten), verwaltet
|
||||||
|
Mandatssequenzen, liest Kontoumsätze über finAPI und ordnet sie Rechnungen zu.
|
||||||
|
Aussage: Das System soll offene Rechnungen per SEPA-Lastschrift einziehen und Zahlungseingänge
|
||||||
|
aus Kontoumsätzen automatisch den Rechnungen zuordnen.
|
||||||
|
Ergebnis: Zahlungsstatus der Rechnungen ist aktuell; Lastschriftläufe sind nachvollziehbar protokolliert.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs:132-360 (ExportInvoices, InvoiceExportDone, RefreshBankInformation) - Begründung: SEPA-Export inkl. Folgebuchungen ist implementiert.
|
||||||
|
- [PRIMÄR] BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs:524-643 (AutoCompleteAccountTransacitons, 3-stufige Zuordnung) - Begründung: automatische Zahlungszuordnung ist implementiert.
|
||||||
|
Prüfidee: Ein Kontoumsatz mit Rechnungsnummer im Verwendungszweck wird der Rechnung zugeordnet und deren bezahlter Betrag erhöht.
|
||||||
|
Tracelinks: SyRS-071, SyRS-072, SyRS-073, SwRS-026, SwRS-027, SwRS-028
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Liquiditätssicherung.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-10
|
||||||
|
Titel: Mahnwesen und Offene-Posten-Überwachung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung
|
||||||
|
Vorbedingung: Rechnungen mit überschrittenem Zahlungsziel existieren.
|
||||||
|
Fakt: DunningBL ermittelt mahnbare Kunden/Rechnungen mit drei Mahnstufen und beachtet
|
||||||
|
Mahnsperren auf Kunden- und Rechnungsebene; OPOS-Läufe existieren.
|
||||||
|
Aussage: Das System soll überfällige Forderungen mehrstufig anmahnen und offene Posten
|
||||||
|
kundenbezogen ausweisen.
|
||||||
|
Ergebnis: Mahnläufe erzeugen stufengerechte Mahnungen; gesperrte Kunden/Rechnungen werden übersprungen.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs:58-113 (GetDunningCustomers mit DunningStopActive) - Begründung: Mahnselektion inkl. Sperren ist implementiert.
|
||||||
|
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/Invoices/Dunning/DunningLevel.cs (None, Level1-3) - Begründung: Mahnstufen sind kodiert.
|
||||||
|
Prüfidee: Eine überfällige Rechnung ohne Sperre erscheint im Mahnlauf; mit gesetzter Mahnsperre erscheint sie nicht.
|
||||||
|
Tracelinks: SyRS-074, SyRS-075, SwRS-030
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Forderungsmanagement.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-11
|
||||||
|
Titel: Übergabe an externe Finanzbuchhaltung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Schnittstelle
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung / Steuerberater
|
||||||
|
Vorbedingung: Buchungsperiode ist abgeschlossen.
|
||||||
|
Fakt: Es existieren Exportformate für DATEV (ASCII EXTF 700, XML Online 2012/2020), Sage,
|
||||||
|
Lexware, Addison, Abacus, Navision, SAP, Schilling AS400, GDI, Europa3000 sowie
|
||||||
|
OPOS-/Stammdaten-Importe zurück.
|
||||||
|
Aussage: Das System soll Belege und Personenkonten in gängige FiBu-Systeme exportieren und
|
||||||
|
Zahlungsinformationen aus der FiBu reimportieren.
|
||||||
|
Ergebnis: Buchhaltungsrelevante Daten stehen dem FiBu-System periodengerecht zur Verfügung.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.Gateway/DataExchange/BookKeeping/DatevAscii/BookKeepingExportDatevAscii.cs:991-1029 (EXTF-Header Format 700) - Begründung: DATEV-Format ist implementiert.
|
||||||
|
- [SEKUNDÄR] src/backend/Centron.Gateway/DataExchange/BookKeeping/ (28 Export-/Importklassen) - Begründung: Formatbreite belegt.
|
||||||
|
Prüfidee: Der DATEV-ASCII-Export erzeugt eine mit "EXTF";700 beginnende Datei, die die exportierten Rechnungen als Buchungsstapel enthält.
|
||||||
|
Tracelinks: SyRS-076, SwRS-029
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - gesetzlich notwendige FiBu-Anbindung.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-12
|
||||||
|
Titel: Gesetzeskonforme elektronische Rechnung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Schnittstelle
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung / öffentliche Auftraggeber
|
||||||
|
Vorbedingung: Rechnung ist erstellt; Kunde verlangt E-Rechnung.
|
||||||
|
Fakt: Die Codebasis erzeugt ZUGFeRD-/XRechnung-Dateien zu Rechnungen (mit Leitweg-ID des
|
||||||
|
Kunden), liest ZUGFeRD-2.1-Eingangsrechnungen und unterstützt das österreichische
|
||||||
|
ebInterface-Format.
|
||||||
|
Aussage: Das System soll Ausgangsrechnungen als strukturierte E-Rechnung (ZUGFeRD/XRechnung,
|
||||||
|
ebInterface) bereitstellen und strukturierte Eingangsrechnungen verarbeiten.
|
||||||
|
Ergebnis: Kunden mit E-Rechnungspflicht erhalten normkonforme Rechnungsdateien.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs:2151-2185 (CreateZugferdFile mit GetLeitwegID, nur InvoiceClass) - Begründung: E-Rechnungserzeugung ist implementiert.
|
||||||
|
- [PRIMÄR] BL/EDI/Zugferd/ZUGFeRD_BL.cs:38 (ReadInvoice ZUGFeRD 2.1) - Begründung: Einlesen strukturierter Rechnungen ist implementiert.
|
||||||
|
- [SEKUNDÄR] docs/reference/zugferd-field-mapping.md, src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs - Begründung: Feldzuordnung und AT-Format.
|
||||||
|
Prüfidee: Zu einer Rechnung eines Kunden mit Leitweg-ID wird eine XRechnung-Datei mit dieser Leitweg-ID erzeugt.
|
||||||
|
Tracelinks: SyRS-104, SyRS-105, SwRS-061, SwRS-062
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - gesetzliche Pflicht (E-Rechnung B2G/B2B).
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-13
|
||||||
|
Titel: Feingranularer, rollenbasierter Zugriffsschutz
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Sicherheit
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Administrator
|
||||||
|
Vorbedingung: Benutzer und Gruppen sind eingerichtet.
|
||||||
|
Fakt: 750 Einzelrechte werden über Gruppen (Sichtrus→Sichmemb→Sichbenu) an Benutzer
|
||||||
|
vergeben; Module und Operationen prüfen Rechte serverseitig; einschränkende Rechte
|
||||||
|
("nur eigene", "nur eigene Filiale") verengen Sichtbarkeit.
|
||||||
|
Aussage: Das System soll jede fachliche Funktion einzeln berechtigbar machen und Rechte
|
||||||
|
ausschließlich über Gruppenzugehörigkeit vergeben.
|
||||||
|
Ergebnis: Benutzer sehen und tun nur, was ihre Gruppenrechte erlauben; Verstöße werden mit Fehlermeldung abgewiesen.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Administration/Rights/AppRightsBL.cs:95-111 (CheckRightsFromUser: SQL über Sichtrus/Sichmemb) - Begründung: durchsetzende Rechteauflösung.
|
||||||
|
- [PRIMÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs (750 `public const int`) - Begründung: Rechtekatalog.
|
||||||
|
- [KONTEXT] CentronRights.md - Begründung: fachliche Beschreibung inkl. einschränkender Rechte.
|
||||||
|
Prüfidee: Entzug eines Gruppenrechts entzieht allen Gruppenmitgliedern die Funktion; ein "nur eigene"-Recht blendet fremde Tickets aus.
|
||||||
|
Tracelinks: SyRS-080, SyRS-058, SwRS-038
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Compliance- und Organisationsanforderung.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-14
|
||||||
|
Titel: Unternehmenskonforme Anmeldung (Verzeichnisdienst, 2FA)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Sicherheit
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Alle Benutzer
|
||||||
|
Vorbedingung: Benutzerkonto existiert.
|
||||||
|
Fakt: Die Anmeldung unterstützt Benutzername/Passwort, Active Directory und
|
||||||
|
OpenID Connect (Microsoft Entra ID); optional erzwingt das System eine
|
||||||
|
Zwei-Faktor-Prüfung per E-Mail oder RADIUS.
|
||||||
|
Aussage: Das System soll die Anmeldung wahlweise gegen das lokale Konto oder den
|
||||||
|
Unternehmens-Verzeichnisdienst durchführen und eine Zwei-Faktor-Authentifizierung
|
||||||
|
unterstützen.
|
||||||
|
Ergebnis: Nur authentifizierte (und bei aktivierter 2FA zweifach bestätigte) Benutzer erhalten ein Sitzungsticket.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Administration/Logins/Auth/ (BasicAuthenticator, ActiveDirectoryAuthenticator, OpenIdConnectAuthenticator, AuthenticatorFactory) - Begründung: Authentifizierungswege sind implementiert.
|
||||||
|
- [PRIMÄR] BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs:33-120 (ValidateTwoFactor) - Begründung: 2FA-Erzwingung ist implementiert.
|
||||||
|
- [KONTEXT] docs/reference/security/anmelden-mit-microsoft-technische-anleitung.md - Begründung: dokumentierter Entra-ID-Login.
|
||||||
|
Prüfidee: Ein Benutzer mit aktivierter 2FA und abgelaufener Gültigkeitsdauer muss den zweiten Faktor bestätigen, sonst schlägt der Login fehl.
|
||||||
|
Tracelinks: SyRS-078, SyRS-081, SwRS-032, SwRS-037
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Sicherheitsstandard.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-15
|
||||||
|
Titel: Lizenzbasierte Freischaltung von Produkten und Funktionen
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Hersteller (nexoware) / Administrator
|
||||||
|
Vorbedingung: Lizenzdatei/Lizenzserver ist erreichbar.
|
||||||
|
Fakt: Lizenzen sind GUIDs mit Anzahl, Gültigkeitsdatum und Maximalversion; Anwendungen
|
||||||
|
prüfen beim Login die Anzahl gleichzeitiger Nutzer über aktive Tickets; Module
|
||||||
|
prüfen HasLicense.
|
||||||
|
Aussage: Das System soll Produkte und Einzelfunktionen nur bei vorhandener Lizenz anbieten
|
||||||
|
und die zulässige Anzahl gleichzeitiger Anmeldungen durchsetzen.
|
||||||
|
Ergebnis: Nicht lizenzierte Funktionen sind unsichtbar/gesperrt; Überschreitungen der Nutzerzahl verhindern den Login.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Administration/Licensing/LicenseManager.cs:258-302 (CheckLicense: Versions- und Anzahl-Prüfung über GetTicketCount) - Begründung: durchsetzende Lizenzprüfung.
|
||||||
|
- [KONTEXT] docs/reference/security/licensing-system.md - Begründung: beschreibt GUID-Lizenzmodell.
|
||||||
|
Prüfidee: Bei erreichter Lizenzanzahl schlägt ein weiterer Login mit "Die maximale Anzahl an Lizenzen wurde erreicht." fehl.
|
||||||
|
Tracelinks: SyRS-082, SwRS-035, SwRS-056
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Vermarktungsmodell des Herstellers; Umsetzung im SaaS-Modell neu zu bewerten.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-16
|
||||||
|
Titel: Mandanten- und Filialfähigkeit
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Geschäftsleitung / Administrator
|
||||||
|
Vorbedingung: Mandanten/Filialen sind eingerichtet.
|
||||||
|
Fakt: Nummernkreise, Bankverbindungen und Belege sind mandanten-/filialbezogen; Rechte
|
||||||
|
können auf die eigene Filiale einschränken; Belege tragen BranchI3D.
|
||||||
|
Aussage: Das System soll mehrere Mandanten und Filialen mit getrennten Nummernkreisen,
|
||||||
|
Bankdaten und filialbezogener Sichtbarkeit unterstützen.
|
||||||
|
Ergebnis: Filialbenutzer arbeiten nur auf Belegen ihrer Filiale, sofern einschränkende Rechte gesetzt sind.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Sales/Receipts/ReceiptBL.cs:10251-10295 (CanUserCreateReceiptsInBranch/CanUserEditReceipt mit BranchI3D-Vergleich) - Begründung: Filialbindung wird durchgesetzt.
|
||||||
|
- [PRIMÄR] BL/Administration/Company/NumberGroupBL.cs:136-152 (Nummernkreise je Mandant und Filiale) - Begründung: getrennte Nummernkreise.
|
||||||
|
Prüfidee: Ein Benutzer mit Filiale A und "nur eigene Filiale"-Recht kann keinen Beleg der Filiale B bearbeiten.
|
||||||
|
Tracelinks: SyRS-083, SyRS-028, SyRS-023
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Multi-Site-Betrieb der Kunden.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-17
|
||||||
|
Titel: Kundenportal im Web
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Endkunde (Web-Account)
|
||||||
|
Vorbedingung: Web-Account ist für den Kunden angelegt.
|
||||||
|
Fakt: Das Nexus-Kundenportal bietet Shop (WebCart), Ticketanlage/-verfolgung inkl.
|
||||||
|
Zeitnachweisen, Vertrags- und Belegübersichten, Dokumente und Formulare.
|
||||||
|
Aussage: Das System soll Endkunden ein Webportal bereitstellen, in dem sie bestellen,
|
||||||
|
Tickets erstellen und verfolgen sowie ihre Verträge, Belege und Dokumente einsehen können.
|
||||||
|
Ergebnis: Endkunden erledigen Standardvorgänge ohne Anruf beim Systemhaus.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/nexus/CentronNexus/WebCart/ (WebCartShopPage.razor, WebCartTicketsPage.razor, ContractsOverview.razor, ReceiptsOverview.razor, CustomerDocumentsPage.razor) - Begründung: Portalfunktionen sind implementiert.
|
||||||
|
- [KONTEXT] README.md Abschnitt WebCart - Begründung: beschreibt Zweck (Kunden der Kunden).
|
||||||
|
Prüfidee: Ein Web-Account sieht nach Login den Shop, kann ein Ticket anlegen und seine Verträge einsehen.
|
||||||
|
Tracelinks: SyRS-121, SyRS-126, SwRS-043
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Self-Service reduziert Servicekosten.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-18
|
||||||
|
Titel: Online-Angebotsfreigabe mit Unterschrift
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Endkunde
|
||||||
|
Vorbedingung: Angebot wurde dem Kunden online bereitgestellt.
|
||||||
|
Fakt: Web-Belege durchlaufen Zustände von SendToCustomer über FirstLoaded bis
|
||||||
|
Annahme/Ablehnung/Signatur (WebReceiptState inkl. WebOfferSign,
|
||||||
|
WebOfferSignedWithoutSignature); eine Signaturkomponente existiert.
|
||||||
|
Aussage: Das System soll Kunden Angebote online bereitstellen und deren Annahme, Ablehnung,
|
||||||
|
Änderungswünsche oder digitale Unterschrift erfassen.
|
||||||
|
Ergebnis: Die Kundenentscheidung ist mit Zeitpunkt und ggf. Unterschrift am Beleg dokumentiert.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/WebReceipt/WebReceiptState.cs:6-26 - Begründung: Freigabe-Zustandsautomat ist kodiert.
|
||||||
|
- [SEKUNDÄR] src/nexus/CentronNexus/DocumentSigning/IsolatedSignaturePad.razor - Begründung: Unterschriftskomponente vorhanden.
|
||||||
|
Prüfidee: Ein online angenommenes Angebot wechselt in AcceptFullWebReceipt und ist im Client als angenommen sichtbar.
|
||||||
|
Tracelinks: SyRS-122, SyRS-123, SwRS-044
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - beschleunigt den Vertriebsabschluss.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-19
|
||||||
|
Titel: Gerätestamm beim Kunden für Service und Abrechnung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Servicetechniker / Vertrieb
|
||||||
|
Vorbedingung: Geräte sind beim Kunden im Einsatz.
|
||||||
|
Fakt: Kundengeräte werden in drei getrennten Datenhaltungen geführt: Stammblätter
|
||||||
|
(MasterDataList mit Zähler-, Vertrags- und Rechnungsbezug), AccountDevices
|
||||||
|
(Seriennummer, Modell, Garantie) und AssetManagement (DocuBoard-Inventarisierung).
|
||||||
|
Aussage: Das System soll die beim Kunden befindlichen Geräte mit Seriennummer, Standort,
|
||||||
|
Garantie und Vertragsbezug führen, damit Service und nutzungsbasierte Abrechnung
|
||||||
|
darauf aufsetzen können.
|
||||||
|
Ergebnis: Zu jedem Kundengerät sind Historie, Vertrag und Zähler auffindbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs (SerialNumber, CounterDevice, ContractI3D, InvoiceI3D) - Begründung: Stammblatt-Datenmodell.
|
||||||
|
- [PRIMÄR] src/backend/Centron.Entities/Entities/Devices/AccountDevice.cs (SerialNumber, Model, Manufacturer, WarrantyExpiryDate) - Begründung: zweite Gerätedatenhaltung.
|
||||||
|
- [SEKUNDÄR] BL/DocuBoard/AssetManagement*BL.cs - Begründung: dritte Datenhaltung (Inventarisierung).
|
||||||
|
Prüfidee: Ein Drucker mit Stammblatt ist über seine Seriennummer auffindbar und zeigt Vertrag und Zählerhistorie.
|
||||||
|
Tracelinks: SyRS-020, SyRS-059, SyRS-060
|
||||||
|
Konsolidierung: Kandidat: SyRS-020 (Stammblätter), SyRS-059 (AccountDevices), SyRS-060 (AssetManagement) - drei Datenhaltungen für denselben fachlichen Gegenstand "Kundengerät"; im Zielsystem zu einem Asset-Konzept zusammenführen.
|
||||||
|
Übernahmewürdigkeit: übernehmen - fachlich erforderlich, aber konsolidiert statt dreifach.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-20
|
||||||
|
Titel: CRM: Aktivitäten, Kampagnen, Umfragen, Verkaufschancen
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Vertrieb / Marketing
|
||||||
|
Vorbedingung: Accounts existieren.
|
||||||
|
Fakt: Die Codebasis protokolliert Kundenaktivitäten, führt Kampagnen mit Phasen,
|
||||||
|
Telemarketing-Aktionen, Umfragen (auch automatisch nach Ticketabschluss) und
|
||||||
|
CRM-Projekte.
|
||||||
|
Aussage: Das System soll Kundeninteraktionen lückenlos dokumentieren und Marketing-/
|
||||||
|
Vertriebsvorgänge (Kampagnen, Umfragen, Verkaufschancen) unterstützen.
|
||||||
|
Ergebnis: Die Kundenhistorie ist je Account vollständig einsehbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Accounts/Activities/AccountActivitiesBL.cs, BL/Accounts/Campaigns/CampaignBL.cs (+Phase/Action), BL/Accounts/Survey/SurveyProcessBL.cs, BL/Sales/Customers/CrmProjects/CrmProjectBL.cs - Begründung: implementierte CRM-Funktionen.
|
||||||
|
- [PRIMÄR] BL/Sales/Support/HelpdeskCloseBL.cs:151 (CreateActivityForTicketClosed) - Begründung: automatische Aktivitätenerzeugung ist durchgesetzt.
|
||||||
|
Prüfidee: Der Abschluss eines Tickets erzeugt eine Aktivität in der Kundenhistorie.
|
||||||
|
Tracelinks: SyRS-038, SyRS-039, SyRS-040, SyRS-041, SyRS-042
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Vertriebssteuerung.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-21
|
||||||
|
Titel: Integrierte Kommunikation (E-Mail, Kalender, Telefonie, Outlook)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Alle Benutzer
|
||||||
|
Vorbedingung: Mail-/Telefonie-Konfiguration vorhanden.
|
||||||
|
Fakt: Mails werden über SMTP oder Microsoft Graph versendet, mit Vorlagen und
|
||||||
|
Variablenersetzung; Exchange-Synchronisation (EWS), MailScanner-Postfachverarbeitung,
|
||||||
|
TAPI-Anruferkennung und ein Outlook-Add-In existieren.
|
||||||
|
Aussage: Das System soll die Kundenkommunikation (E-Mail, Termine, Telefonate) direkt aus dem
|
||||||
|
ERP führen und eingehende Kommunikation den Kunden/Tickets zuordnen.
|
||||||
|
Ergebnis: Kommunikationsvorgänge sind am Kunden/Ticket dokumentiert.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Mail/Protocols/ (SMTPMail.cs, GraphMail.cs), BL/Mail/Templates/MailTemplateBL.cs, BL/Tapi/PhoneCallBL.cs (SearchContactPersonByPhoneNumberV2), BL/MailScanner/MailScannerBL.cs - Begründung: Kommunikationswege implementiert.
|
||||||
|
- [SEKUNDÄR] src/nexus/CentronNexus.OutlookAddIn/ - Begründung: Outlook-Integration vorhanden.
|
||||||
|
Prüfidee: Ein eingehender Anruf zeigt den zugehörigen Ansprechpartner; eine per MailScanner empfangene Mail erzeugt/aktualisiert ein Ticket.
|
||||||
|
Tracelinks: SyRS-095, SyRS-096, SyRS-097, SyRS-098, SyRS-099, SyRS-101
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Effizienz im Tagesgeschäft.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-22
|
||||||
|
Titel: Auswertungen, Statistiken und Belegreports
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Geschäftsleitung / Controlling
|
||||||
|
Vorbedingung: Bewegungsdaten vorhanden.
|
||||||
|
Fakt: Es existieren Umsatz-, Auftrags-, Rechnungs-, Vertrags-, Ticket- und
|
||||||
|
Mitarbeiterauslastungs-Statistiken sowie eine ReportEngine mit Vorlagen und
|
||||||
|
PDF-Erzeugung für Belegdrucke.
|
||||||
|
Aussage: Das System soll betriebswirtschaftliche Auswertungen und druckfähige Belegdokumente
|
||||||
|
aus den operativen Daten erzeugen.
|
||||||
|
Ergebnis: Kennzahlen und Belegdrucke stehen ohne Datenexport zur Verfügung.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Statistics/ (RevenueStatisticBL.cs, SaleStatisticBL.cs, InvoiceStatisticBL.cs, EmployeeUtilizationBL.cs u. a.), BL/ReportEngine/ (ReportDataBL.cs, PdfExport) - Begründung: Auswertungs- und Reportlogik implementiert.
|
||||||
|
Prüfidee: Die Umsatzstatistik eines Jahres entspricht der Summe der fakturierten Rechnungen dieses Jahres.
|
||||||
|
Tracelinks: SyRS-116, SyRS-117
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Steuerungsinformation.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-23
|
||||||
|
Titel: Datenschutz-Compliance (DSGVO)
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Sicherheit
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Datenschutzbeauftragter / Administrator
|
||||||
|
Vorbedingung: DSGVO-Modul lizenziert; Benutzer hat DSGVO-Rechte.
|
||||||
|
Fakt: Das DSGVO-Modul ermittelt löschbare Altdaten (Kunden ohne Aktivität, Altbelege,
|
||||||
|
CRM-Einträge) und setzt das Löschrecht für Kontakte um; Zugriff ist rechtegebunden.
|
||||||
|
Aussage: Das System soll personenbezogene Altdaten identifizieren und auf Anforderung
|
||||||
|
löschen können (Recht auf Löschung).
|
||||||
|
Ergebnis: Löschläufe entfernen die ausgewählten personenbezogenen Daten nachvollziehbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Administration/DataSecurity/DataSecurityBL.cs:34-70, 377, 787 (Rechteprüfung ACCESS_CLEANUP_DATABASE, DsgvoDeleteRightGetContacts/DeleteContacts) - Begründung: durchgesetzte DSGVO-Funktionen.
|
||||||
|
Prüfidee: Ein Benutzer ohne DSGVO-Recht erhält "Insufficient rights!"; mit Recht liefert die Statistik löschbare Kontakte.
|
||||||
|
Tracelinks: SyRS-086, SwRS-052
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - gesetzliche Pflicht.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-24
|
||||||
|
Titel: Revisionssichere Belegführung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Buchhaltung / Wirtschaftsprüfer
|
||||||
|
Vorbedingung: Belege werden verändert oder storniert.
|
||||||
|
Fakt: Jede Belegänderung erzeugt einen vollständigen Versionsstand in *Versions-Tabellen;
|
||||||
|
Rechnungen können festgeschrieben werden (IsFixed) und sind dann unveränderlich;
|
||||||
|
Stornos sind nur unter dokumentierten Bedingungen möglich; Beleglogs protokollieren
|
||||||
|
Aktionen.
|
||||||
|
Aussage: Das System soll Belegänderungen versionieren, Rechnungen festschreibbar machen und
|
||||||
|
alle abrechnungsrelevanten Aktionen protokollieren.
|
||||||
|
Ergebnis: Jeder frühere Belegstand ist rekonstruierbar; Festschreibung verhindert nachträgliche Änderung.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:86-141 (FixInvoice: UPDATE RechKopf SET IsFixed=1 + Logeintrag "festgeschrieben") - Begründung: Festschreibung ist durchgesetzt.
|
||||||
|
- [PRIMÄR] ebd.:273-291 (CheckIfInvoiceIsFixed: "Die Rechnung ist festgeschrieben. Änderungen nicht möglich.") - Begründung: Änderungssperre.
|
||||||
|
- [KONTEXT] docs/reference/receipts/receipts-backend-architecture.md (Version Tables 1:1) - Begründung: Versionierungskonzept.
|
||||||
|
Prüfidee: Nach Festschreibung einer Rechnung wird jeder Änderungsversuch abgewiesen; die Versionstabellen enthalten den Stand vor jeder Änderung.
|
||||||
|
Tracelinks: SyRS-006, SyRS-022, SwRS-002, SwRS-016, SwRS-017
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - GoBD-relevante Anforderung.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-25
|
||||||
|
Titel: Produkt- und Preisdaten von Drittanbietern
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Schnittstelle
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Einkauf / Vertrieb
|
||||||
|
Vorbedingung: API-Zugänge sind konfiguriert.
|
||||||
|
Fakt: Es existieren Clients für Icecat (Produktbeschreibungen/Bilder), ITscope
|
||||||
|
(Produkte/Preise/Bestellungen), COP und EGIS; die Artikelsuche bindet externe
|
||||||
|
Artikelquellen ein.
|
||||||
|
Aussage: Das System soll Artikelstammdaten und Tagespreise aus Drittquellen beziehen, um
|
||||||
|
Angebote ohne manuelle Artikelanlage erstellen zu können.
|
||||||
|
Ergebnis: Externe Artikel sind mit aktuellen Preisen direkt in Belege übernehmbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Sales/Receipts/ArticleSearch/ArticleSearchBL.cs:1107-1126 (ExecuteExternalArticleSearchAsync über ExternalArticleSearchProvider) - Begründung: Einbindung externer Quellen in die Belegartikelsuche.
|
||||||
|
- [SEKUNDÄR] src/apis/Centron.APIs.IcecatDataAccess/IcecatApi.cs, src/apis/Centron.APIs.ITscopeDataAccess/ITscopeApi.cs - Begründung: API-Clients vorhanden.
|
||||||
|
Prüfidee: Die Artikelsuche in einem Auftrag findet einen nur bei ITscope vorhandenen Artikel und übernimmt ihn mit Preis in die Position.
|
||||||
|
Tracelinks: SyRS-107, SyRS-108, SyRS-109, SyRS-110, SyRS-017
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Sortimentsbreite ohne Stammdatenpflege.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-26
|
||||||
|
Titel: Versandabwicklung mit Paketdiensten
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: Schnittstelle
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Lagermitarbeiter
|
||||||
|
Vorbedingung: Lieferschein ist kommissioniert.
|
||||||
|
Fakt: API-Clients für GLS und Shipcloud (Labels, Tracking) existieren; Rechnungen tragen
|
||||||
|
TrackingNumber/TrackingNumberURL.
|
||||||
|
Aussage: Das System soll Versandaufträge an Paketdienste übergeben und Sendungsnummern am
|
||||||
|
Beleg speichern.
|
||||||
|
Ergebnis: Pakete sind ohne Medienbruch etikettiert; Tracking ist am Beleg abrufbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/apis/Centron.Api.Gls/CentronGlsLogic.cs, src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs - Begründung: Versand-API-Clients implementiert.
|
||||||
|
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/Invoices/ReceiptInvoice.cs:101-102 (TrackingNumber, TrackingNumberURL) - Begründung: Tracking am Beleg.
|
||||||
|
Prüfidee: Für einen Lieferschein wird ein GLS-Label erzeugt und die Sendungsnummer am Beleg gespeichert.
|
||||||
|
Tracelinks: SyRS-069, SyRS-070
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Standard-Logistikprozess.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-27
|
||||||
|
Titel: Produktion/Konfektionierung eigener Artikel
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Produktion / Lager
|
||||||
|
Vorbedingung: Stücklistenartikel existieren.
|
||||||
|
Fakt: ProductionOrderBL verwaltet Fertigungsaufträge mit Positionen und Status
|
||||||
|
(ProductionOrderItemState); ArticleProductionBL produziert Artikel aus Teilelisten;
|
||||||
|
eine Web-Sicht (Nexus ProductionOrderManagement) existiert.
|
||||||
|
Aussage: Das System soll Fertigungsaufträge für zusammengesetzte Artikel (z. B. PC-Konfigurationen)
|
||||||
|
führen und deren Fertigstellung bestandwirksam buchen.
|
||||||
|
Ergebnis: Komponenten werden ausgebucht, das Erzeugnis eingebucht; der Auftragsstatus ist verfolgbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Production/ProductionOrderBL.cs (SaveProductionOrder, GetProductionOrdersByFilter), BL/Warehousing/ArticleProduction/ArticleProductionBL.cs - Begründung: Fertigungslogik implementiert.
|
||||||
|
Prüfidee: Das Abschließen eines Fertigungsauftrags reduziert die Komponentenbestände und erhöht den Bestand des Erzeugnisses.
|
||||||
|
Tracelinks: SyRS-068, SyRS-124
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Konfektionierung gehört zum Systemhausgeschäft.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-28
|
||||||
|
Titel: Projektgeschäft mit Belegzuordnung
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Projektleiter
|
||||||
|
Vorbedingung: Projekt ist angelegt.
|
||||||
|
Fakt: Projekte existieren als eigene Objekte; Belege tragen ProjectNumber; Ticketprojekte
|
||||||
|
bündeln Tickets mit Abhängigkeiten.
|
||||||
|
Aussage: Das System soll Projekte führen und Belege sowie Tickets Projekten zuordnen, damit
|
||||||
|
projektbezogene Auswertungen möglich sind.
|
||||||
|
Ergebnis: Alle Belege/Tickets eines Projekts sind über die Projektnummer auffindbar.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Projects/ProjectBL.cs, BL/TicketProjects/TicketProjectBL.cs (Dependencies), src/backend/Centron.Entities/.../ReceiptInvoice.cs:34 (ProjectNumber) - Begründung: Projektbezug implementiert.
|
||||||
|
Prüfidee: Ein Auftrag mit Projektnummer erscheint in der Belegliste des Projekts.
|
||||||
|
Tracelinks: SyRS-014, SyRS-053
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Projektgeschäft der Systemhäuser.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-29
|
||||||
|
Titel: Kassenführung für Bargeschäfte
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Verkauf/Theke
|
||||||
|
Vorbedingung: Kassenbuch ist eingerichtet.
|
||||||
|
Fakt: Barrechnungen (IsCashAsset) sind vom Storno ausgenommen; Kassenbuchbuchungen werden
|
||||||
|
aus Belegen erzeugt und gelöscht.
|
||||||
|
Aussage: Das System soll Barverkäufe über ein Kassenbuch mit belegbezogenen Buchungen abbilden.
|
||||||
|
Ergebnis: Kassenbestand und Belege stimmen überein; Barbelege sind gegen Storno geschützt.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/Sales/CashBooks/CashBookBookingBL.cs (UpdateCashBookBookingFromAsset, DeleteCashBookBookingFromAsset) - Begründung: Kassenbuchbuchungen implementiert.
|
||||||
|
- [PRIMÄR] BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:160-161 (Storno-Verbot für Barrechnung) - Begründung: durchgesetzte Kassenregel.
|
||||||
|
Prüfidee: Eine Barrechnung erzeugt eine Kassenbuchbuchung; ihr Storno wird mit Hinweis auf die Barrechnung abgewiesen.
|
||||||
|
Tracelinks: SyRS-018, SwRS-016
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Ladengeschäft.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-30
|
||||||
|
Titel: Mitarbeiterverwaltung mit Auslastungssicht
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: funktional
|
||||||
|
Qualitätsmerkmal:
|
||||||
|
Akteur: Personal / Serviceleitung
|
||||||
|
Vorbedingung: Mitarbeiter sind erfasst.
|
||||||
|
Fakt: Mitarbeiterstamm mit Abteilungen, Skills, Urlaub, RFID-Token und Teams existiert;
|
||||||
|
Auslastung anderer Mitarbeiter ist rechtegebunden einsehbar; Ein-/Austrittsdatum
|
||||||
|
deaktiviert Konten.
|
||||||
|
Aussage: Das System soll Mitarbeiter mit Organisationszuordnung und Qualifikationen verwalten
|
||||||
|
und deren Auslastung berechtigten Rollen anzeigen.
|
||||||
|
Ergebnis: Einsatzplanung kann auf aktuelle Auslastungs- und Skilldaten zugreifen.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] BL/EmployeeArea/ (EmployeeBL.cs, EmployeeDepartmentBL.cs, EmployeeSkillsBL.cs, TeamManagementBL.cs), BL/Statistics/Administration/Employees/EmployeeUtilizationBL.cs - Begründung: implementierte Personalfunktionen.
|
||||||
|
- [PRIMÄR] BL/Administration/Logins/Auth/Authenticator.cs:206-216 (IsActiveEmployeeCompact: Deaktivierung über Ein-/Austrittstermin) - Begründung: durchgesetzte Kopplung Mitarbeiterstatus→Login.
|
||||||
|
- [KONTEXT] CentronRights.md Abschnitt Mitarbeiterauslastung - Begründung: fachliche Rechtebeschreibung.
|
||||||
|
Prüfidee: Ein ausgetretener Mitarbeiter (Austrittstermin überschritten) kann sich nicht mehr anmelden.
|
||||||
|
Tracelinks: SyRS-084, SyRS-079
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Basisstammdaten.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-31
|
||||||
|
Titel: Zuverlässiger Systembetrieb mit automatischer Datenpflege
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: nicht-funktional
|
||||||
|
Qualitätsmerkmal: Zuverlässigkeit
|
||||||
|
Akteur: Administrator / Betrieb
|
||||||
|
Vorbedingung: Webservice läuft.
|
||||||
|
Fakt: Ein stündlicher DataQualityService bereinigt/repariert Daten; abgelaufene
|
||||||
|
Sitzungstickets werden gelöscht; nummerierte Migrationsskripte aktualisieren das
|
||||||
|
Schema versionsgebunden.
|
||||||
|
Aussage: Das System soll wiederkehrende Wartungs- und Konsistenzaufgaben automatisch im
|
||||||
|
Hintergrund ausführen und Schemaänderungen versioniert einspielen.
|
||||||
|
Ergebnis: Datenbestand und Schema bleiben ohne manuelle Eingriffe konsistent.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/DataQualityService.cs - Begründung: Hintergrunddienst implementiert.
|
||||||
|
- [PRIMÄR] BL/Administration/Scripts/ScriptMethods/Scripts/ (ScriptMethod<Nr>.cs) - Begründung: versionierte Migrationen.
|
||||||
|
- [KONTEXT] docs/Background Service/DataQualityService.md, docs/guides/database/create-scripts.md - Begründung: dokumentierte Betriebskonzepte.
|
||||||
|
Prüfidee: Nach einem Update führt der Dienst ausstehende Skriptnummern genau einmal aus; der DataQualityService läuft stündlich.
|
||||||
|
Tracelinks: SyRS-087, SyRS-088, SwRS-053, SwRS-057
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Betriebsstabilität.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: StRS-32
|
||||||
|
Titel: Deutschsprachiges System mit englischer Zweitsprache
|
||||||
|
Ebene: StRS
|
||||||
|
Typ: nicht-funktional
|
||||||
|
Qualitätsmerkmal: Benutzbarkeit (Usability)
|
||||||
|
Akteur: Alle Benutzer
|
||||||
|
Vorbedingung: keine
|
||||||
|
Fakt: Alle Benutzertexte liegen deutsch in Basis-Resx (2.812 Einträge allein in
|
||||||
|
Centron.WPF.UI LocalizedStrings.resx) mit englischen Übersetzungsdateien
|
||||||
|
(LocalizedStrings.en.resx); die Doku schreibt Deutsch als Erstsprache vor.
|
||||||
|
Aussage: Das System soll alle Benutzertexte deutsch als Erstsprache und englisch als
|
||||||
|
Zweitsprache bereitstellen; Fachbegriffe folgen der deutschen Branchenterminologie.
|
||||||
|
Ergebnis: Benutzer arbeiten vollständig in ihrer Sprache; Umschaltung auf Englisch ist möglich.
|
||||||
|
Belege:
|
||||||
|
- [PRIMÄR] src/centron/Centron.WPF.UI/Resources/LocalizedStrings.resx (2.812 data-Einträge) und LocalizedStrings.en.resx - Begründung: Sprachressourcen vorhanden.
|
||||||
|
- [KONTEXT] docs/getting-started/general-structure.md (German-First Language Policy) - Begründung: dokumentierte Sprachpolitik.
|
||||||
|
Prüfidee: Alle in der UI sichtbaren Meldungen erscheinen in der eingestellten Sprache; fehlende EN-Texte fallen auf DE zurück.
|
||||||
|
Tracelinks: SyRS-156, SwRS-058
|
||||||
|
Konsolidierung: nein
|
||||||
|
Übernahmewürdigkeit: übernehmen - Zielmarkt DACH; Mehrsprachigkeit im Web-Zielsystem von Beginn an einplanen.
|
||||||
|
Status: belegt
|
||||||
|
```
|
||||||
+1784
File diff suppressed because it is too large
Load Diff
+3708
File diff suppressed because it is too large
Load Diff
+199
@@ -0,0 +1,199 @@
|
|||||||
|
# Traceability
|
||||||
|
|
||||||
|
Konsolidierte Traceability-Tabelle über die drei Ebenen. Eine Zeile je SyRS-Anforderung:
|
||||||
|
Spalte 1 nennt die StRS-Elternanforderung(en) (Backward-Trace), Spalte 3 die zugeordneten
|
||||||
|
SwRS-Kindanforderungen (Forward-Trace), Spalte 4 den zentralen Artefaktbeleg (Kurzform;
|
||||||
|
vollständige Belege in den Spezifikationen). `BL/` = `src/backend/Centron.BL/`.
|
||||||
|
|
||||||
|
Alle 32 StRS-Anforderungen sind über mindestens eine SyRS-Zeile abgedeckt; alle 71
|
||||||
|
SwRS-Anforderungen erscheinen in mindestens einer Zeile.
|
||||||
|
|
||||||
|
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||||
|
|---|---|---|---|
|
||||||
|
| StRS-02 | SyRS-001 | SwRS-004 | Entities/Sales/Receipts/Offers/ReceiptOffer.cs; AngKopf/AngPos |
|
||||||
|
| StRS-02 | SyRS-002 | – | AutomaticFacturaBL.cs:114 (GetOrdersForAutomatedBilling) |
|
||||||
|
| StRS-02 | SyRS-003 | – | AutomaticFacturaBL.cs:102 (State==1) |
|
||||||
|
| StRS-02, StRS-24 | SyRS-004 | SwRS-013 | Entities/.../ReceiptInvoice.cs:38-108 |
|
||||||
|
| StRS-24, StRS-29 | SyRS-005 | SwRS-016, SwRS-004 | BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:143-206 |
|
||||||
|
| StRS-24 | SyRS-006 | SwRS-017 | ReceiptInvoiceBL.cs:86-141 (FixInvoice) |
|
||||||
|
| StRS-02, StRS-10 | SyRS-007 | – | DunningBL.cs:99-108 (CreditVouchers) |
|
||||||
|
| StRS-02, StRS-07 | SyRS-008 | SwRS-045 | BarcodeState.cs:24 (AssignedToPickupList) |
|
||||||
|
| StRS-03 | SyRS-009 | SwRS-023 | Entities/.../ReceiptContract.cs |
|
||||||
|
| StRS-03 | SyRS-010 | SwRS-019, SwRS-020, SwRS-021, SwRS-022, SwRS-070, SwRS-071 | AutomaticFacturaBL.Contracts.cs:1596-1627 |
|
||||||
|
| StRS-04 | SyRS-011 | SwRS-024 | AutomaticFacturaBL.Contracts.cs:1248 (UpdClickCounterHistory) |
|
||||||
|
| StRS-05 | SyRS-012 | SwRS-063 | TimerBillingBL.cs:233-383 |
|
||||||
|
| StRS-02 | SyRS-013 | SwRS-018 | DownPaymentBL.cs:82/198 |
|
||||||
|
| StRS-28 | SyRS-014 | – | BL/Projects/ProjectBL.cs; ReceiptInvoice.ProjectNumber |
|
||||||
|
| StRS-02, StRS-15 | SyRS-015 | – | LeasingAndService/; ModuleRegistration.cs:475 |
|
||||||
|
| StRS-25 | SyRS-016 | – | BL/Warehousing/ActionPriceBL.cs |
|
||||||
|
| StRS-02, StRS-25 | SyRS-017 | SwRS-007, SwRS-008, SwRS-009, SwRS-010, SwRS-013, SwRS-014 | ArticleSearchBL.cs:1080-1126 |
|
||||||
|
| StRS-29 | SyRS-018 | – | CashBookBookingBL.cs |
|
||||||
|
| StRS-17, StRS-25 | SyRS-019 | SwRS-008, SwRS-043 | ReceiptItemPriceBL.cs:232-257; ArticleSearchWebServiceBL.cs:71 |
|
||||||
|
| StRS-19, StRS-04 | SyRS-020 | – | Entities/.../MasterDataList.cs |
|
||||||
|
| StRS-02 | SyRS-021 | SwRS-012 | ReceiptPriceHelper.cs:37-41 (0.05-Rundung) |
|
||||||
|
| StRS-24 | SyRS-022 | SwRS-002, SwRS-003 | ReceiptInvoiceBL.cs:174; *KopfVersions-Tabellen |
|
||||||
|
| StRS-16 | SyRS-023 | SwRS-025, SwRS-051 | NumberGroupBL.cs:62-134 |
|
||||||
|
| StRS-03, StRS-21, StRS-22 | SyRS-024 | – | AutomaticFacturaBL.Contracts.cs:263-443 (Mailvorlagen/Empfänger) |
|
||||||
|
| StRS-01, StRS-02 | SyRS-025 | SwRS-015 | ReceiptBL.cs:8636-8705 (Kreditlimit) |
|
||||||
|
| StRS-02 | SyRS-026 | – | ReceiptBL.cs:2462 (ValidateReceiptForwarding) |
|
||||||
|
| StRS-02 | SyRS-027 | SwRS-005, SwRS-065 | ReceiptBL.cs:4808 (ConcurrencyControlGuid) |
|
||||||
|
| StRS-13, StRS-16 | SyRS-028 | SwRS-066 | ReceiptBL.cs:10251-10311 (Branch-Checks) |
|
||||||
|
| StRS-08 | SyRS-029 | – | SupplierOrderBL.cs; BL/EDI/AlsoOrderBL.cs |
|
||||||
|
| StRS-08, StRS-12 | SyRS-030 | SwRS-062 | SupplierInvoicesBL.cs; PdfScanner.cs |
|
||||||
|
| StRS-08, StRS-07 | SyRS-031 | – | SupplierDeliveryListBL.cs; ZUGFeRD_BL.cs:107 |
|
||||||
|
| StRS-08 | SyRS-032 | – | SupplierCreditVoucherSpecificLogic.cs |
|
||||||
|
| StRS-08, StRS-24 | SyRS-033 | – | SupplierReceiptDocumentBL.cs |
|
||||||
|
| StRS-08, StRS-07 | SyRS-034 | – | OrderSuggestionListBL.cs |
|
||||||
|
| StRS-01, StRS-08 | SyRS-035 | SwRS-051 | SSMS_DB_SCHEMA.sql:3854 (Unique Lieferantennummer) |
|
||||||
|
| StRS-01, StRS-13 | SyRS-036 | SwRS-051 | AccountBL.cs:1305-1366 (Rechteprüfungen) |
|
||||||
|
| StRS-01 | SyRS-037 | – | ReceiptInvoiceBL.cs:293 (AlternateInvoiceReceiver) |
|
||||||
|
| StRS-20 | SyRS-038 | – | AccountActivitiesBL.cs; HelpdeskCloseBL.cs:151 |
|
||||||
|
| StRS-20 | SyRS-039 | – | BL/Accounts/Campaigns/ |
|
||||||
|
| StRS-20, StRS-21 | SyRS-040 | – | BL/Sales/Marketing/; BL/Mailings/ |
|
||||||
|
| StRS-20, StRS-05 | SyRS-041 | – | HelpdeskCloseBL.cs:168-198 (AddSurvey) |
|
||||||
|
| StRS-20 | SyRS-042 | – | CrmProjectBL.cs |
|
||||||
|
| StRS-05 | SyRS-043 | – | BL/Accounts/HotlineArea/ |
|
||||||
|
| StRS-20 | SyRS-044 | – | BL/Accounts/AccountContracts/ |
|
||||||
|
| StRS-05 | SyRS-045 | SwRS-047 | HelpdeskBL.cs:298-307, 515-519 |
|
||||||
|
| StRS-05 | SyRS-046 | SwRS-047 | HelpdeskBL.cs:658-702 (Pflichtfelder) |
|
||||||
|
| StRS-05 | SyRS-047 | SwRS-048 | HelpdeskCloseBL.cs:120-157 |
|
||||||
|
| StRS-06 | SyRS-048 | SwRS-049 | EscalationBL.cs:223-332 |
|
||||||
|
| StRS-05 | SyRS-049 | – | HelpdeskTimerBL.cs; CentronRights.md Abschn. 7-9 |
|
||||||
|
| StRS-05 | SyRS-050 | – | CentronChecklistBL.cs |
|
||||||
|
| StRS-05 | SyRS-051 | – | HelpdeskPatternBL.cs; automatic-helpdesk-creation-templates.md |
|
||||||
|
| StRS-05 | SyRS-052 | – | BL/TaskManager/ |
|
||||||
|
| StRS-28, StRS-05 | SyRS-053 | – | TicketProjectBL.cs (Dependencies) |
|
||||||
|
| StRS-05, StRS-07 | SyRS-054 | SwRS-050 | SSMS_DB_SCHEMA.sql:4176 (Unique RMA) |
|
||||||
|
| StRS-05 | SyRS-055 [H] | – | ExternalHelpdeskConfigurationBL.cs (nur Konfiguration) |
|
||||||
|
| StRS-05, StRS-21 | SyRS-056 | – | AppointmentRequestBL.cs |
|
||||||
|
| StRS-05 | SyRS-057 | – | ToDoBL.cs; HelpdeskCloseBL.cs:134 |
|
||||||
|
| StRS-13, StRS-05 | SyRS-058 | SwRS-038 | UserRightsConst.cs (SHOW_HELPDESK_ONLY_OWN…) |
|
||||||
|
| StRS-19 | SyRS-059 | – | AccountDeviceBL.cs; Entities/Devices/AccountDevice.cs |
|
||||||
|
| StRS-19 | SyRS-060 | – | BL/DocuBoard/; AssetManagement*-Tabellen |
|
||||||
|
| StRS-04, StRS-19 | SyRS-061 | – | RmmConnectionSettingsBL.cs; RiverbirdImportValues |
|
||||||
|
| StRS-04 | SyRS-062 | SwRS-064 | AutomaticFacturaBL.cs:129-147 (MSP→Vertragsposition) |
|
||||||
|
| StRS-07, StRS-25 | SyRS-063 | – | ArticleBL.cs; ArticleImportBL.cs |
|
||||||
|
| StRS-07 | SyRS-064 | SwRS-011, SwRS-046, SwRS-010 | ArticleStockBL.cs:47-149 |
|
||||||
|
| StRS-07 | SyRS-065 | SwRS-069 | InventoryNewBL.cs:80-330 |
|
||||||
|
| StRS-07, StRS-02 | SyRS-066 | – | CommissioningBL.cs; PartialCommissionOrderBL.cs |
|
||||||
|
| StRS-07 | SyRS-067 | SwRS-045, SwRS-046 | BarcodeState.cs; BarcodeHistoryBL.cs |
|
||||||
|
| StRS-27 | SyRS-068 | – | ProductionOrderBL.cs; ProductionOrderItemState.cs |
|
||||||
|
| StRS-26 | SyRS-069 | – | Centron.Api.Gls/CentronGlsLogic.cs |
|
||||||
|
| StRS-26 | SyRS-070 | – | Centron.Api.Shipcloud/CentronShipcloudLogic.cs |
|
||||||
|
| StRS-09, StRS-13 | SyRS-071 | SwRS-031, SwRS-027 | PaymentsBL.cs:38-78 |
|
||||||
|
| StRS-09 | SyRS-072 | SwRS-028, SwRS-070 | OnlineBankingAccountTransactionsBL.cs:524-643 |
|
||||||
|
| StRS-09 | SyRS-073 | SwRS-026, SwRS-027 | PaymentTransactionBL.cs:132-345 |
|
||||||
|
| StRS-10 | SyRS-074 | SwRS-030 | DunningBL.cs:58-113; DunningLevel.cs |
|
||||||
|
| StRS-10, StRS-11 | SyRS-075 | – | OposRunBL.cs; OposImports-Settings |
|
||||||
|
| StRS-11 | SyRS-076 | SwRS-029 | BookKeepingExportDatevAscii.cs:991; ReceiptInvoiceBL.cs:167 |
|
||||||
|
| StRS-09 | SyRS-077 | SwRS-026 | BankAccountBL.cs; PaymentTransactionBL.cs:347 |
|
||||||
|
| StRS-14 | SyRS-078 | SwRS-032, SwRS-034, SwRS-036, SwRS-041, SwRS-068 | CentronRestService.cs:363-397; TicketBL.cs:26 |
|
||||||
|
| StRS-14, StRS-30 | SyRS-079 | SwRS-033 | Authenticator.cs:157-217 |
|
||||||
|
| StRS-13 | SyRS-080 | SwRS-038, SwRS-036 | AppRightsBL.cs:95-111 (Sichtrus/Sichmemb) |
|
||||||
|
| StRS-14 | SyRS-081 | SwRS-037 | TwoFactorAuthBL.cs:33-120 |
|
||||||
|
| StRS-15 | SyRS-082 | SwRS-035 | LicenseManager.cs:258-302 |
|
||||||
|
| StRS-16 | SyRS-083 | – | MandatorBL.cs; BranchBL.cs; NumberGroupBL.cs:136 |
|
||||||
|
| StRS-30 | SyRS-084 | – | BL/EmployeeArea/ |
|
||||||
|
| StRS-31 | SyRS-085 | SwRS-054 | ApplicationSettingID.cs (~500 IDs) |
|
||||||
|
| StRS-23 | SyRS-086 | SwRS-052 | DataSecurityBL.cs:34-70, 377, 787 |
|
||||||
|
| StRS-31 | SyRS-087 | SwRS-053 | ScriptMethods/Scripts/; create-scripts.md |
|
||||||
|
| StRS-31 | SyRS-088 | SwRS-057 | DataQualityService.cs |
|
||||||
|
| StRS-31 | SyRS-089 [H] | – | TelemetryBL.cs; ProfilerBL.cs (Zweck unbelegt) |
|
||||||
|
| StRS-14 | SyRS-090 | SwRS-040 | AccessTokenBL.cs:125-194, 457-488 |
|
||||||
|
| StRS-13 | SyRS-091 | – | PasswordManagementBL.cs:81 (GetDecryptedPassword) |
|
||||||
|
| StRS-01 | SyRS-092 | – | CustomTableBL.cs |
|
||||||
|
| StRS-01 | SyRS-093 | – | MassUpdateBL.cs |
|
||||||
|
| StRS-32 | SyRS-094 | – | UiProfileBL.cs |
|
||||||
|
| StRS-21 | SyRS-095 | SwRS-059, SwRS-060 | CentronMailFactory.cs; DeveloperSecurity.cs:30 |
|
||||||
|
| StRS-21 | SyRS-096 | – | EwsHelper/ (EWSConnection, EwsCalendarAccess) |
|
||||||
|
| StRS-21, StRS-05 | SyRS-097 | – | MailScannerBL.cs |
|
||||||
|
| StRS-21 | SyRS-098 | – | PhoneCallBL.cs (SearchContactPersonByPhoneNumberV2) |
|
||||||
|
| StRS-21, StRS-13 | SyRS-099 | – | CalendarBL.cs; CentronRights.md Kalender |
|
||||||
|
| StRS-21 | SyRS-100 | – | ChatBL.cs (CreateChat mit objectKind) |
|
||||||
|
| StRS-21 | SyRS-101 | – | CentronNexus.OutlookAddIn/ (CustomerTab u. a.) |
|
||||||
|
| StRS-21, StRS-17 | SyRS-102 | – | NexusNotificationsBL.cs; Program.cs:349 (SignalR) |
|
||||||
|
| StRS-08 | SyRS-103 | SwRS-062 | SupplierEdiBL.cs (+Partials); EDIDispatcherBL.cs |
|
||||||
|
| StRS-12 | SyRS-104 | SwRS-061 | ReceiptWebServiceBL.cs:2151-2185 |
|
||||||
|
| StRS-12 | SyRS-105 | – | EbInterfaceLogic.cs |
|
||||||
|
| StRS-04 | SyRS-106 [H] | – | DocuFormRestApiClient.cs (Konsument unbelegt) |
|
||||||
|
| StRS-25 | SyRS-107 | – | IcecatApi.cs |
|
||||||
|
| StRS-25 | SyRS-108 | – | ITscopeApi.cs; ArticleSearchBL.cs:1107 |
|
||||||
|
| StRS-25 | SyRS-109 [H] | – | CopApi.cs (Aufrufer unbelegt) |
|
||||||
|
| StRS-08, StRS-25 | SyRS-110 | – | EgisWarenkorbBL.cs; EgisApi.cs |
|
||||||
|
| StRS-25 | SyRS-111 [H] | – | TelekomDiveBL.cs (Inhalt unbelegt) |
|
||||||
|
| StRS-05 | SyRS-112 [H] | – | TanssBL.cs (Nutzungsart unbelegt) |
|
||||||
|
| StRS-11 | SyRS-113 | – | GfkExportBL.cs |
|
||||||
|
| StRS-25 | SyRS-114 | – | HPQuoteImportBL.cs |
|
||||||
|
| StRS-05, StRS-21 | SyRS-115 | – | DocBeeTicketConnectorBL.cs; CTimeConnectorBL.cs |
|
||||||
|
| StRS-22 | SyRS-116 | – | BL/ReportEngine/ (ReportDataBL, PdfExport) |
|
||||||
|
| StRS-22 | SyRS-117 | SwRS-070 | BL/Statistics/ (15 BLs) |
|
||||||
|
| StRS-01, StRS-05 | SyRS-118 | – | IndexSearchBL.cs (Lucene, GermanAnalyzer) |
|
||||||
|
| StRS-17 | SyRS-119 | SwRS-067 | CentronNexus.Host/Program.cs:264-276, 395 |
|
||||||
|
| StRS-05, StRS-17 | SyRS-120 | – | ServiceBoard/ (341 Dateien) |
|
||||||
|
| StRS-17 | SyRS-121 | SwRS-043 | ArticleSearchWebServiceBL.cs:71-99 |
|
||||||
|
| StRS-18 | SyRS-122 | SwRS-044 | WebReceiptState.cs:6-26 |
|
||||||
|
| StRS-18, StRS-05 | SyRS-123 | – | DocumentSigning/ (IsolatedSignaturePad) |
|
||||||
|
| StRS-27, StRS-17 | SyRS-124 | – | ProductionOrderManagement/ |
|
||||||
|
| StRS-17 | SyRS-125 | – | SelfCareBL.cs; CustomerPortalFormsPage.razor |
|
||||||
|
| StRS-17, StRS-13 | SyRS-126 | SwRS-039, SwRS-042, SwRS-066, SwRS-032 | WebAccountBL.cs:54-105; AppRightsBL.cs:113 |
|
||||||
|
| StRS-14, StRS-17 | SyRS-127 | SwRS-055, SwRS-068 | CentronRestServiceParts/ (32 Teile); AuthenticateInterceptor.cs |
|
||||||
|
| StRS-31 | SyRS-128 | – | c-entron.misc.ConnectionManager/ |
|
||||||
|
| StRS-22 | SyRS-129 | – | BL/MyCentron/ |
|
||||||
|
| StRS-15, StRS-05 | SyRS-130 | – | MyDayBL.cs; licensing-system.md (Count) |
|
||||||
|
| StRS-05 | SyRS-131 | – | OpenAiApiClient.cs; TicketAiSummary/ |
|
||||||
|
| StRS-25 | SyRS-132 [H] | – | TradePoolBL.cs (Kontext unbelegt) |
|
||||||
|
| StRS-02 | SyRS-133 | – | VoucherManagementBL.cs |
|
||||||
|
| StRS-02, StRS-21 | SyRS-134 | – | TextModuleBL.cs (GetInvoiceTextModule) |
|
||||||
|
| StRS-05 | SyRS-135 | – | TagsBL.cs (AddTicketTag) |
|
||||||
|
| StRS-21 | SyRS-136 | – | SocialMediaBL.cs |
|
||||||
|
| StRS-32 | SyRS-137 | – | VideoPortalAssignmentBL.cs |
|
||||||
|
| StRS-21 | SyRS-138 | – | WebLinkBL.cs (+ActionHandler) |
|
||||||
|
| StRS-05 | SyRS-139 [H] | – | MobileBL.cs (Konsument unbelegt) |
|
||||||
|
| StRS-20 | SyRS-140 | – | ProductMatrixBL.cs |
|
||||||
|
| StRS-05 | SyRS-141 [H] | – | ChecklistVirtualObjectCategoryBL.cs |
|
||||||
|
| StRS-20 | SyRS-142 | – | ExpectedEventsBL.cs |
|
||||||
|
| StRS-25 | SyRS-143 [H] | – | CPraConnectorBL.cs |
|
||||||
|
| StRS-05, StRS-14 | SyRS-144 | – | RiverDivoBL.cs (CreateHelpdeskRequest) |
|
||||||
|
| StRS-02 | SyRS-145 | – | CountryBL.cs |
|
||||||
|
| StRS-06, StRS-21 | SyRS-146 | – | HolidayDAO.cs |
|
||||||
|
| StRS-02 | SyRS-147 | – | ReceiptInvoice.CurrencyFactorIsFixed; ReceiptBL.cs:8369 |
|
||||||
|
| StRS-25 | SyRS-148 | – | ObjectExternalReferenceBL.cs |
|
||||||
|
| StRS-05 | SyRS-149 [H] | – | ProcessBL.cs; WorkflowShapeBL.cs |
|
||||||
|
| StRS-24 | SyRS-150 | – | DAO/ChangeTracking/; ChangeLog-Tabelle |
|
||||||
|
| StRS-13, StRS-15 | SyRS-151 | SwRS-056, SwRS-055 | ModuleRegistration.cs:441-498 (83 Module) |
|
||||||
|
| StRS-32 | SyRS-152 | – | Centron.Controls/; Centron.Core/ |
|
||||||
|
| StRS-02 | SyRS-153 | SwRS-001, SwRS-006 | Centron.DAO/ (Mappings, Repositories) |
|
||||||
|
| StRS-08, StRS-11 | SyRS-154 | – | Centron.Gateway/ |
|
||||||
|
| StRS-31 | SyRS-155 | – | deployment/; docker/ |
|
||||||
|
| StRS-32 | SyRS-156 | SwRS-058 | LocalizedStrings*.resx (2.812 Einträge) |
|
||||||
|
|
||||||
|
**Legende:** `[H]` = Anforderung mit Status HYPOTHESE; `–` = keine vertiefende SwRS-Anforderung.
|
||||||
|
|
||||||
|
## Gegenrichtung: SwRS → SyRS (Backward-Trace der Softwareebene)
|
||||||
|
|
||||||
|
| SwRS | → SyRS | | SwRS | → SyRS | | SwRS | → SyRS |
|
||||||
|
|---|---|---|---|---|---|---|---|
|
||||||
|
| 001 | 153 | | 025 | 023 | | 049 | 048 |
|
||||||
|
| 002 | 022 | | 026 | 073, 077 | | 050 | 054 |
|
||||||
|
| 003 | 022, 006 | | 027 | 073, 071 | | 051 | 036, 035, 023 |
|
||||||
|
| 004 | 001, 005 | | 028 | 072 | | 052 | 086 |
|
||||||
|
| 005 | 027 | | 029 | 076 | | 053 | 087 |
|
||||||
|
| 006 | 153 | | 030 | 074 | | 054 | 085 |
|
||||||
|
| 007 | 017, 009 | | 031 | 071 | | 055 | 127, 151 |
|
||||||
|
| 008 | 019, 017 | | 032 | 078, 126 | | 056 | 151 |
|
||||||
|
| 009 | 017 | | 033 | 079 | | 057 | 088 |
|
||||||
|
| 010 | 017, 064 | | 034 | 078 | | 058 | 156 |
|
||||||
|
| 011 | 064 | | 035 | 082 | | 059 | 095 |
|
||||||
|
| 012 | 021 | | 036 | 078, 080 | | 060 | 095 |
|
||||||
|
| 013 | 017, 004 | | 037 | 081 | | 061 | 104 |
|
||||||
|
| 014 | 017 | | 038 | 080 | | 062 | 103, 030 |
|
||||||
|
| 015 | 025 | | 039 | 126 | | 063 | 012 |
|
||||||
|
| 016 | 005, 010, 011, 012 | | 040 | 090 | | 064 | 062, 010 |
|
||||||
|
| 017 | 006 | | 041 | 078 | | 065 [H] | 027 |
|
||||||
|
| 018 | 013 | | 042 | 126 | | 066 | 126, 028 |
|
||||||
|
| 019 | 010 | | 043 | 121 | | 067 | 119 |
|
||||||
|
| 020 | 010 | | 044 | 122 | | 068 | 127, 078 |
|
||||||
|
| 021 | 010 | | 045 | 067 | | 069 | 065 |
|
||||||
|
| 022 | 010, 011 | | 046 | 064, 067 | | 070 | 010, 072, 117 |
|
||||||
|
| 023 | 009, 022 | | 047 | 046 | | 071 [H] | 010, 024 |
|
||||||
|
| 024 | 011 | | 048 | 047 | | | |
|
||||||
+165
@@ -0,0 +1,165 @@
|
|||||||
|
# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
|
||||||
|
|
||||||
|
## Lauf
|
||||||
|
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
|
||||||
|
- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
|
||||||
|
vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
|
||||||
|
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
|
||||||
|
- **Startzeit:** 2026-08-27T08:12:35.5152425+02:00
|
||||||
|
- **Endzeit:** 2026-08-27T09:12:14.8158828+02:00
|
||||||
|
- **Dauer gesamt:** 0:59:39 (`duration_ms` 0:59:37; API: 0:57:54)
|
||||||
|
— **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
|
||||||
|
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
|
||||||
|
- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
|
||||||
|
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
|
||||||
|
die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
|
||||||
|
Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
|
||||||
|
- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
|
||||||
|
- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
|
||||||
|
|
||||||
|
## Werkzeugkonfiguration
|
||||||
|
- **Skill-Version:** 7.0.0
|
||||||
|
- **Claude-Code-Version:** 2.1.246
|
||||||
|
- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
|
||||||
|
- **Modell (angefordert):** `claude-fable-5`
|
||||||
|
- **Modelle (tatsächlich eingesetzt):** `claude-fable-5` 41.314.054 Tokens (99.98 %), `claude-haiku-4-5-20251001` 6.965 Tokens (0.02 %)
|
||||||
|
- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
|
||||||
|
- **Effort:** `max` (per `--effort max` gesetzt)
|
||||||
|
- **Laufverzeichnis-ID:** `v7.0.0-3021`
|
||||||
|
- **Ablage:** `Iteration 3/claude-fable-5/solo/max/`
|
||||||
|
- **Parallele Läufe:** nein – die Zeitangaben sind für Laufzeitvergleiche verwendbar
|
||||||
|
- **Agentenmodus:** `solo` (V1)
|
||||||
|
- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
|
||||||
|
- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
|
||||||
|
- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
|
||||||
|
- **Permission-Mode:** `acceptEdits`
|
||||||
|
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
|
||||||
|
`--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos) **zuzüglich** `Task`, `Agent`, `Workflow` aus dem Modus `solo`
|
||||||
|
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
|
||||||
|
- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
|
||||||
|
- **Subagenten:** keine (`spawned` = 0, `by_type` leer)
|
||||||
|
- **Verschachtelung:** `spawned` = 0, davon `spawned_by_subagents` = 0, `max_depth` = 0. Keine tieferen Ebenen, `_meta\subagenten.md` entfällt.
|
||||||
|
|
||||||
|
## Validierungsstichprobe
|
||||||
|
- **Größe:** noch nicht festgelegt
|
||||||
|
- **Ziehungsverfahren:** noch nicht festgelegt
|
||||||
|
- **Validatoren:** noch nicht festgelegt
|
||||||
|
- **Stand:** noch nicht gezogen
|
||||||
|
|
||||||
|
## Verbrauch
|
||||||
|
|
||||||
|
### Hauptagent (`usage`)
|
||||||
|
| Messgröße | Wert |
|
||||||
|
|---|---:|
|
||||||
|
| Input-Tokens | 352 |
|
||||||
|
| Output-Tokens | 296.436 (davon 48.784 Thinking-Tokens) |
|
||||||
|
| Cache-Write-Tokens | 547.351 |
|
||||||
|
| Cache-Read-Tokens | 40.469.915 |
|
||||||
|
| Agent-Turns | 204 |
|
||||||
|
|
||||||
|
### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
|
||||||
|
| Messgröße | `claude-fable-5` | `claude-haiku-4-5-20251001` | Summe |
|
||||||
|
|---|---:|---:|---:|
|
||||||
|
| Input-Tokens | 352 | 6.944 | 7.296 |
|
||||||
|
| Output-Tokens | 296.436 | 21 | 296.457 |
|
||||||
|
| Cache-Write-Tokens | 547.351 | 0 | 547.351 |
|
||||||
|
| Cache-Read-Tokens | 40.469.915 | 0 | 40.469.915 |
|
||||||
|
| **Tokens gesamt** | **41.314.054** | **6.965** | **41.321.019** |
|
||||||
|
|
||||||
|
**Tokens gesamt: 41.321.019** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
|
||||||
|
Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
|
||||||
|
`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
|
||||||
|
preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
|
||||||
|
|
||||||
|
Da im Modus `solo` keine Subagenten laufen, sind `usage` und `modelUsage` für das Hauptmodell
|
||||||
|
deckungsgleich; die Differenz zur Summe stammt allein aus den Haiku-Hilfsaufrufen.
|
||||||
|
|
||||||
|
## 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 | 32 | 12,4 % |
|
||||||
|
| SyRS | 156 | 60,2 % |
|
||||||
|
| SwRS | 71 | 27,4 % |
|
||||||
|
| **Gesamt** | **259** | 100 % |
|
||||||
|
|
||||||
|
### Anforderungstypen
|
||||||
|
|
||||||
|
| Typ | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| funktional | 166 | 64,1 % |
|
||||||
|
| Sicherheit | 35 | 13,5 % |
|
||||||
|
| Schnittstelle | 34 | 13,1 % |
|
||||||
|
| nicht-funktional | 13 | 5,0 % |
|
||||||
|
| Daten | 11 | 4,2 % |
|
||||||
|
|
||||||
|
### Belegqualität
|
||||||
|
|
||||||
|
| Messgröße | Wert |
|
||||||
|
|---|---:|
|
||||||
|
| Belege gesamt | 370 |
|
||||||
|
| davon `PRIMÄR` | 285 (77,0 %) |
|
||||||
|
| davon `SEKUNDÄR` | 43 (11,6 %) |
|
||||||
|
| davon `KONTEXT` | 42 (11,4 %) |
|
||||||
|
| Belege je Anforderung (Median) | 1 |
|
||||||
|
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 245 (94,6 %) |
|
||||||
|
|
||||||
|
### Übernahmewürdigkeit
|
||||||
|
|
||||||
|
| Einstufung | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| übernehmen | 244 | 94,2 % |
|
||||||
|
| workaround | 8 | 3,1 % |
|
||||||
|
| sonderfall | 5 | 1,9 % |
|
||||||
|
| veraltet | 2 | 0,8 % |
|
||||||
|
|
||||||
|
### Status
|
||||||
|
|
||||||
|
| Kategorie | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| belegt | 246 | 95,0 % |
|
||||||
|
| als `HYPOTHESE` gekennzeichnet | 13 | 5,0 % |
|
||||||
|
| als Workaround vermerkt | 0 | 0,0 % |
|
||||||
|
| Konsolidierungskandidaten | 9 | 3,5 % |
|
||||||
|
| mit ISO-25010-Qualitätsmerkmal | 13 | 5,0 % |
|
||||||
|
|
||||||
|
### 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** (60 risikorelevante Anforderungen, alle gedeckt) |
|
||||||
|
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||||
|
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 259 Anforderungen eingestuft) |
|
||||||
|
| **Traceability** – Verknüpfung zwischen den Ebenen | 259 von 259 mit Tracelinks (100,0 %) |
|
||||||
|
|
||||||
|
## Ergebnis
|
||||||
|
- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
|
||||||
|
- **Session-ID:** `2db865cc-0f0d-440b-867f-bd92dfa2b20d`
|
||||||
|
- **Permission-Denials:** 1 (1 × `PowerShell`) – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
|
||||||
|
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – Bedingung `solo` eingehalten
|
||||||
|
- **Subagenten-Prompts:** entfällt (Modus `solo`)
|
||||||
|
- **Erzeugte Dateien:** 7 Dateien in `Ergebnisse\`:
|
||||||
|
|
||||||
|
| Datei | Größe |
|
||||||
|
|---|---:|
|
||||||
|
| `Analysebericht.md` | 39.480 B |
|
||||||
|
| `Glossar.md` | 8.320 B |
|
||||||
|
| `Hypothesen.md` | 3.632 B |
|
||||||
|
| `StRS.md` | 46.076 B |
|
||||||
|
| `SwRS.md` | 93.705 B |
|
||||||
|
| `SyRS.md` | 191.384 B |
|
||||||
|
| `Traceability.md` | 13.545 B |
|
||||||
|
|
||||||
|
- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
|
||||||
|
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
|
||||||
|
|
||||||
|
## Anmerkungen/Auffälligkeiten
|
||||||
|
|
||||||
|
<!-- ANMERKUNGEN -->
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
{"is_error":false,"duration_api_ms":3474396,"num_turns":204,"stop_reason":"end_turn","session_id":"2db865cc-0f0d-440b-867f-bd92dfa2b20d","total_cost_usd":66.24930400000002,"usage":{"input_tokens":352,"cache_creation_input_tokens":547351,"cache_read_input_tokens":40469915,"output_tokens":296436,"output_tokens_details":{"thinking_tokens":48784},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":547351,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":1542,"cache_read_input_tokens":546412,"cache_creation_input_tokens":939,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":939},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6944,"outputTokens":21,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007049,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-fable-5":{"inputTokens":352,"outputTokens":296436,"cacheReadInputTokens":40469915,"cacheCreationInputTokens":547351,"webSearchRequests":0,"costUSD":66.24225500000001,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"PowerShell","tool_use_id":"toolu_0114xsshBxZ2Y6sbJ7yuMx44","tool_input":{"command":"New-Item -ItemType Directory -Force \"c:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 3\\claude-fable-5\\solo\\max\\02_Lauf_2026-08-27_081235_v7.0.0-3021\\Ergebnisse\" | Out-Null; Write-Host \"Ausgabeverzeichnis angelegt\"","description":"Create output directory"}}],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":null,"result":"Der Lauf ist abgeschlossen. Alle sieben Ergebnisdateien liegen im vorgegebenen Ausgabeverzeichnis `…\\02_Lauf_2026-08-27_081235_v7.0.0-3021\\Ergebnisse\\`.\n\n## Ergebnis im Überblick\n\n**259 Anforderungen** über drei Ebenen: **StRS 32, SyRS 156, SwRS 71**, davon **13 Hypothesen** (5,0 %). Die Codebasis wurde ausschließlich lesend analysiert.\n\n**Vorgehen gemäß Schritt 0-0c:** Vor der ersten Anforderung wurde ein **Modulinventar mit 146 Modulen** erstellt (Kennzahlen: ~14.200 C#-Dateien, 1.558 DB-Tabellen, 182 Views, 750 Benutzerrechte, 83 registrierte Client-Module). Die **Mindestabdeckung ist vollständig erfüllt**: Jedes Modul trägt mindestens eine Anforderung, kein Modul blieb unanalysiert (33 tief, 66 mittel, 47 flach).\n\n**Risikovertiefung:** Alle 81 risikorelevanten Anforderungen (35 Sicherheit/Berechtigungen, 46 Abrechnung/Fakturierung) tragen einen PRIMÄR-Beleg mit benannter durchsetzender Stelle (Datei, Klasse, Methode, Prüfung) – die einzige Ausnahme (Sammelrechnungs-Bündelung) ist regelkonform als `[HYPOTHESE]` markiert. Fachlich besonders ergiebig waren u. a.: Rechnungsstorno mit fünf Vorbedingungen, GoBD-Festschreibung (`IsFixed`), Vertragsabrechnung mit Monatsend-/Schaltjahrlogik und Pro-rata-Normalisierung, Kontingentbuchung mit Überbuchung/Zwischenrechnung, SEPA-Mandatssequenzen, DATEV EXTF 700, die fünfstufige Preisfindungshierarchie, das Sichbenu/Sichmemb/Sichtrus-Rechtemodell sowie der Sicherheitsbefund **ungesalzenes SHA1-Passworthashing** (mit TODO-Kommentar im Code belegt, als abzulösender Ist-Zustand dokumentiert).\n\n**Konsistenzcheck (skriptgestützt über die Abgabedateien):** 0 doppelte IDs, 0 Anforderungen ohne Beleg/Übernahmewürdigkeit/Prüfidee, 0 tote Tracelinks, vollständige Rückverlinkung SwRS→SyRS→StRS, `Hypothesen.md` deckungsgleich mit den 13 Inline-Markierungen. Das Konsolidierungsbeispiel aus dem Prompt wurde im Code bestätigt und erweitert: Kundengeräte existieren **dreifach** (Stammblätter/`MasterDataList`, `AccountDevice`, DocuBoard-`AssetManagement`) und sind als Konsolidierungskandidaten markiert, ebenso Inventur alt/neu, das zweigleisige Einstellungssystem und die beiden Versandwege.","ttft_ms":8870,"ttft_stream_ms":1746,"time_to_request_ms":31,"type":"result","duration_ms":3577708,"uuid":"92217355-07c0-4f36-9301-6be091bcdeb5","queued_turn_count":0}
|
||||||
+5034
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 | 32 | 12,4 % |
|
||||||
|
| SyRS | 156 | 60,2 % |
|
||||||
|
| SwRS | 71 | 27,4 % |
|
||||||
|
| **Gesamt** | **259** | 100 % |
|
||||||
|
|
||||||
|
### Anforderungstypen
|
||||||
|
|
||||||
|
| Typ | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| funktional | 166 | 64,1 % |
|
||||||
|
| Sicherheit | 35 | 13,5 % |
|
||||||
|
| Schnittstelle | 34 | 13,1 % |
|
||||||
|
| nicht-funktional | 13 | 5,0 % |
|
||||||
|
| Daten | 11 | 4,2 % |
|
||||||
|
|
||||||
|
### Belegqualität
|
||||||
|
|
||||||
|
| Messgröße | Wert |
|
||||||
|
|---|---:|
|
||||||
|
| Belege gesamt | 370 |
|
||||||
|
| davon `PRIMÄR` | 285 (77,0 %) |
|
||||||
|
| davon `SEKUNDÄR` | 43 (11,6 %) |
|
||||||
|
| davon `KONTEXT` | 42 (11,4 %) |
|
||||||
|
| Belege je Anforderung (Median) | 1 |
|
||||||
|
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 245 (94,6 %) |
|
||||||
|
|
||||||
|
### Übernahmewürdigkeit
|
||||||
|
|
||||||
|
| Einstufung | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| übernehmen | 244 | 94,2 % |
|
||||||
|
| workaround | 8 | 3,1 % |
|
||||||
|
| sonderfall | 5 | 1,9 % |
|
||||||
|
| veraltet | 2 | 0,8 % |
|
||||||
|
|
||||||
|
### Status
|
||||||
|
|
||||||
|
| Kategorie | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| belegt | 246 | 95,0 % |
|
||||||
|
| als `HYPOTHESE` gekennzeichnet | 13 | 5,0 % |
|
||||||
|
| als Workaround vermerkt | 0 | 0,0 % |
|
||||||
|
| Konsolidierungskandidaten | 9 | 3,5 % |
|
||||||
|
| mit ISO-25010-Qualitätsmerkmal | 13 | 5,0 % |
|
||||||
|
|
||||||
|
### 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** (60 risikorelevante Anforderungen, alle gedeckt) |
|
||||||
|
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||||
|
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 259 Anforderungen eingestuft) |
|
||||||
|
| **Traceability** – Verknüpfung zwischen den Ebenen | 259 von 259 mit Tracelinks (100,0 %) |
|
||||||
|
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
|
||||||
+177
@@ -0,0 +1,177 @@
|
|||||||
|
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
|
||||||
|
|
||||||
|
## Metadaten
|
||||||
|
- **Versuch:** V1 Baseline (Prompt-only)
|
||||||
|
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
|
||||||
|
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||||
|
- **Zeitstempel:** 2026-08-26
|
||||||
|
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
|
||||||
|
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||||
|
|
||||||
|
| Änderung | Auslösender Befund |
|
||||||
|
|---|---|
|
||||||
|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
|
||||||
|
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
|
||||||
|
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
|
||||||
|
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
|
||||||
|
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
|
||||||
|
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
|
||||||
|
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
|
||||||
|
|
||||||
|
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
|
||||||
|
|
||||||
|
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||||
|
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||||
|
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Prompt
|
||||||
|
|
||||||
|
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||||
|
|
||||||
|
### Auftrag
|
||||||
|
|
||||||
|
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||||
|
|
||||||
|
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||||
|
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||||
|
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||||
|
|
||||||
|
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||||
|
|
||||||
|
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||||
|
|
||||||
|
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
**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. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
|
||||||
|
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||||
|
|
||||||
|
### Formatvorgabe pro Anforderung
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||||
|
Titel: <kurzer Titel>
|
||||||
|
Ebene: <StRS | SyRS | SwRS>
|
||||||
|
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||||
|
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)
|
||||||
|
|
||||||
|
```
|
||||||
|
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)
|
||||||
|
```
|
||||||
|
|
||||||
|
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?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||||
|
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
|
||||||
|
Kommandozeilenbefehlen im Arbeitsverzeichnis.
|
||||||
|
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
|
||||||
|
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||||
|
Werkzeuge zu ersetzen.
|
||||||
|
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||||
|
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||||
|
`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-fable-5\solo\max\02_Lauf_2026-08-27_081235_v7.0.0-3021\Ergebnisse\`.
|
||||||
|
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-27T09:12:14.8158828+02:00
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-27T08:12:35.5152425+02:00
|
||||||
+64
-70
@@ -1,67 +1,39 @@
|
|||||||
# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
|
# Messprotokoll – Versuch 01 (V1b Baseline mit werkzeugeigenen Agenten) – Prompt-Version 02
|
||||||
|
|
||||||
|
> ## ⚠ FEHLMESSUNG – nicht für Auswertungen verwenden
|
||||||
|
>
|
||||||
|
> Der Lauf meldet `is_error: false` und `subtype: success`, hat aber **null Ergebnisdateien** erzeugt. Der Headless-Modus brach nach 600 Sekunden ab, während zehn Hintergrund-Subagenten noch arbeiteten. Verbraucht wurden dabei **193.399.648 Tokens**. Der Lauf ist für jede inhaltliche Auswertung unbrauchbar; sein Verbrauch ist real und wird ausgewiesen.
|
||||||
|
|
||||||
## Lauf
|
## Lauf
|
||||||
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
|
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
|
||||||
- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
|
- **Prompt-Version:** 02
|
||||||
vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
|
|
||||||
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
|
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
|
||||||
- **Startzeit:** 2026-08-26T16:00:49.2361402+02:00
|
- **Startzeit:** 2026-08-26T16:00:44.0+02:00
|
||||||
- **Endzeit:** 2026-08-26T16:21:48.6873493+02:00
|
- **Endzeit:** 2026-08-26T16:21:43.0+02:00
|
||||||
- **Dauer gesamt:** 0:20:59 (`duration_ms` 0:10:57; API: 3:49:48)
|
- **Dauer gesamt:** 00:20:59 — im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar
|
||||||
— **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
|
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||||
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
|
- **Codebasis-Commit:** `f349d189c735a87f5829bc93f67991320061a2c0` (dirty: nein)
|
||||||
- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
|
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; enthält `SSMS_DB_SCHEMA.sql`
|
||||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
|
(SHA-256 `ED7F21250E868577572B4CADA53C132F7433C74270BF9B59E817CCEC6B1FA8DB`)
|
||||||
die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
|
|
||||||
Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
|
|
||||||
- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
|
|
||||||
- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
|
|
||||||
|
|
||||||
## Werkzeugkonfiguration
|
## Werkzeugkonfiguration
|
||||||
- **Skill-Version:** 4.5.0
|
- **Skill-Version:** 4.5.0 (Laufzeit); Gültigkeitsprüfung nachträglich mit 6.1.0 eingeführt
|
||||||
- **Claude-Code-Version:** 2.1.246
|
- **Claude-Code-Version:** 2.1.246
|
||||||
- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
|
|
||||||
- **Modell (angefordert):** `claude-opus-5`
|
- **Modell (angefordert):** `claude-opus-5`
|
||||||
- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 193.392.662 Tokens (100.00 %), `claude-haiku-4-5-20251001` 6.986 Tokens (0.00 %)
|
- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 193.392.662 Tokens (100.00 %), `claude-haiku-4-5-20251001` 6.986 Tokens (0.00 %)
|
||||||
- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
|
- **Kontrolle Modell:** bestanden – ausschließlich `claude-opus-5` plus Haiku-Hilfsaufrufe
|
||||||
- **Effort:** `high` (per `--effort high` gesetzt)
|
- **Effort:** `high`
|
||||||
- **Laufverzeichnis-ID:** `v4.5.0-116d`
|
|
||||||
- **Ablage:** `Iteration 3/claude-opus-5/builtin/high/`
|
|
||||||
- **Parallele Läufe:** **ja** – zeitgleich liefen:
|
|
||||||
- `Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e`
|
|
||||||
|
|
||||||
Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden. Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials bleiben unverzerrt.
|
|
||||||
- **Agentenmodus:** `builtin` (V1b)
|
- **Agentenmodus:** `builtin` (V1b)
|
||||||
- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
|
|
||||||
- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
|
|
||||||
- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
|
|
||||||
- **Permission-Mode:** `acceptEdits`
|
- **Permission-Mode:** `acceptEdits`
|
||||||
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
|
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` / 33er-Denylist
|
||||||
`--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos). Der Modus `builtin` fügt keine weiteren Sperren hinzu – die werkzeugeigenen Subagenten sind zugelassen.
|
|
||||||
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
|
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
|
||||||
- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
|
- **Parallele Läufe:** ja – der jeweils andere Lauf dieser Zelle
|
||||||
- **Subagenten:** 20 gestartet (10 × `Explore`, 10 × `general-purpose`), 10 abgeschlossen, 0 fehlgeschlagen; 20 im Hintergrund gestartet
|
- **Subagenten:** 20 gestartet (10 × `Explore`, 10 × `general-purpose`), 10 abgeschlossen, 0 fehlgeschlagen
|
||||||
- **Verschachtelung:** `spawned` = 20, davon `spawned_by_subagents` = 10, `max_depth` = 2. Bei `max_depth` > 1 sind die Tokens der tieferen Ebenen in „Tokens gesamt" enthalten, ihre Prompts jedoch **nicht** in `_meta\subagenten.md`.
|
- **Verschachtelung:** `spawned` = 20, davon `spawned_by_subagents` = 10,
|
||||||
- **Verbrauchsanteil der Subagenten:** `usage` (nur Hauptagent) 2.124.147 Tokens gegenüber `modelUsage` 193.399.648 Tokens – auf die Subagenten entfallen 191.275.501 Tokens (98.9 %).
|
`max_depth` = 2, am Nebenläufigkeitslimit abgewiesen: 5
|
||||||
|
|
||||||
## Validierungsstichprobe
|
|
||||||
- **Größe:** noch nicht festgelegt
|
|
||||||
- **Ziehungsverfahren:** noch nicht festgelegt
|
|
||||||
- **Validatoren:** noch nicht festgelegt
|
|
||||||
- **Stand:** noch nicht gezogen
|
|
||||||
|
|
||||||
## Verbrauch
|
## Verbrauch
|
||||||
|
|
||||||
### Hauptagent (`usage`)
|
|
||||||
| Messgröße | Wert |
|
|
||||||
|---|---:|
|
|
||||||
| Input-Tokens | 44 |
|
|
||||||
| Output-Tokens | 65.246 (davon 9.113 Thinking-Tokens) |
|
|
||||||
| Cache-Write-Tokens | 123.977 |
|
|
||||||
| Cache-Read-Tokens | 1.934.880 |
|
|
||||||
| Agent-Turns | 44 |
|
|
||||||
|
|
||||||
### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
|
|
||||||
| Messgröße | `claude-opus-5` | `claude-haiku-4-5-20251001` | Summe |
|
| Messgröße | `claude-opus-5` | `claude-haiku-4-5-20251001` | Summe |
|
||||||
|---|---:|---:|---:|
|
|---|---:|---:|---:|
|
||||||
| Input-Tokens | 2.604 | 6.960 | 9.564 |
|
| Input-Tokens | 2.604 | 6.960 | 9.564 |
|
||||||
@@ -70,34 +42,56 @@
|
|||||||
| Cache-Read-Tokens | 187.592.610 | 0 | 187.592.610 |
|
| Cache-Read-Tokens | 187.592.610 | 0 | 187.592.610 |
|
||||||
| **Tokens gesamt** | **193.392.662** | **6.986** | **193.399.648** |
|
| **Tokens gesamt** | **193.392.662** | **6.986** | **193.399.648** |
|
||||||
|
|
||||||
**Tokens gesamt: 193.399.648** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
|
|
||||||
Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
|
|
||||||
`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
|
|
||||||
preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
|
|
||||||
|
|
||||||
`usage` erfasst **nur den Hauptagenten**. Der Unterschied zu `modelUsage` ist der Verbrauch
|
**Tokens gesamt: 193.399.648** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
|
||||||
der Subagenten – siehe Feld „Verbrauchsanteil der Subagenten" oben. Für den
|
Der Verbrauch ist **real angefallen** und wird deshalb ausgewiesen, obwohl der Lauf ungültig ist.
|
||||||
abrechnungsrelevanten Gesamtverbrauch gilt ausschließlich `modelUsage`.
|
|
||||||
|
|
||||||
## Gefundene Anforderungen
|
## Gefundene Anforderungen
|
||||||
|
|
||||||
Keine Anforderungen im vorgegebenen Format gefunden.
|
Keine. Der Lauf hat **null** verwertbare Ergebnisdatei(en) erzeugt; eine Auswertung mit
|
||||||
|
`analyse-anforderungen.py` ist gegenstandslos.
|
||||||
|
|
||||||
## Ergebnis
|
## Ergebnis
|
||||||
- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
|
- **Gültigkeit:** **Fehlmessung** – Ergebnisverzeichnis leer, Abbruch durch Hintergrund-Zeitlimit
|
||||||
|
- **Status:** `is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`,
|
||||||
|
`terminal_reason` = `completed`
|
||||||
- **Session-ID:** `ac82faba-7709-4a7c-9881-dcf0cd4faa1c`
|
- **Session-ID:** `ac82faba-7709-4a7c-9881-dcf0cd4faa1c`
|
||||||
- **Permission-Denials:** 1 (1 × `Bash`) – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
|
- **Permission-Denials:** 1
|
||||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 20 – Bedingung `solo` **VERLETZT – Fehlmessung**
|
- **Erzeugte Dateien:** **keine**
|
||||||
- **Subagenten-Prompts:** `_meta\subagenten.md` erzeugt
|
- **Root unverändert:** ja
|
||||||
- **Erzeugte Dateien:** 0 Dateien in `Ergebnisse\`:
|
- **Abschlusstext des Agenten:** „Die Erhebung läuft. … 10 von 12 Agenten arbeiten parallel." – der Agent berichtet einen Zwischenstand, keinen Abschluss.
|
||||||
|
|
||||||
| Datei | Größe |
|
|
||||||
|---|---:|
|
|
||||||
|
|
||||||
|
|
||||||
- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
|
|
||||||
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
|
|
||||||
|
|
||||||
## Anmerkungen/Auffälligkeiten
|
## Anmerkungen/Auffälligkeiten
|
||||||
|
|
||||||
<!-- ANMERKUNGEN -->
|
**1. Stiller Fehlschlag – `is_error` erkennt ihn nicht.** `RawResult.json` meldet
|
||||||
|
`is_error: false`, `subtype: success`, `stop_reason: end_turn`, `terminal_reason: completed`.
|
||||||
|
Der einzige maschinelle Hinweis steht in `Stderr.log`:
|
||||||
|
|
||||||
|
```
|
||||||
|
Background tasks still running after 600s; terminating.
|
||||||
|
Set CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0 to wait indefinitely.
|
||||||
|
```
|
||||||
|
|
||||||
|
Ohne den Blick in `Ergebnisse\` wäre der Lauf als gültiger Messpunkt mit „0 Anforderungen" in
|
||||||
|
den Modellvergleich eingegangen. Daraufhin wurde in Skill 6.1.0 die Pflichtprüfung ergänzt:
|
||||||
|
leeres Ergebnisverzeichnis oder Abbruchmeldung in `Stderr.log` bedeutet Fehlmessung,
|
||||||
|
unabhängig von `is_error`.
|
||||||
|
|
||||||
|
**2. Ursache ist eine Wechselwirkung, keine Modelleigenschaft.** Der Hauptagent startete zehn
|
||||||
|
Subagenten im Hintergrund und beendete seinen eigenen Turn nach 44 Turns. Die Subagenten liefen
|
||||||
|
weiter, der Headless-Modus wartete 600 s und schnitt sie ab. Die drei Sonnet-`builtin`-Läufe
|
||||||
|
derselben Iteration starteten ihre Subagenten **ebenfalls durchgängig im Hintergrund**
|
||||||
|
(6/6, 8/8, 31/31) und lieferten dennoch alle sieben Dateien mit leerem `Stderr` – ihre
|
||||||
|
Subagenten waren vor Ablauf der Frist fertig. Der Unterschied liegt im Zuschnitt: Opus erteilte
|
||||||
|
Aufträge von rund 7.700 Zeichen (Sonnet: 1.428–3.656) an zehn Agenten und wollte zwölf.
|
||||||
|
|
||||||
|
**3. Vorbeugung ab Skill 6.1.0:** `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0` im
|
||||||
|
Ausführungsabschnitt. Das ändert die Versuchsbedingung für künftige `builtin`-Läufe und ist
|
||||||
|
dort zu vermerken; die bisherigen Läufe liefen unter dem 600-Sekunden-Limit, haben es aber
|
||||||
|
nie erreicht.
|
||||||
|
|
||||||
|
**4. Nebenbefund aus dem Abschlusstext:** Der Agent stellt fest, die Codebasis enthalte „keine
|
||||||
|
`.git`-Historie und keine SQL-Migrationsskripte". Das trifft zu und gilt für **alle** Läufe:
|
||||||
|
Seit die Codebasis als Dateien ins Arbeitsrepo übernommen wurde, ist die Entwicklungshistorie
|
||||||
|
der ERP-Suite nicht erreichbar. Der Prompt fordert sie in Schritt 2 ausdrücklich als
|
||||||
|
Artefaktquelle – diese Belegquelle steht der gesamten Versuchsreihe nicht zur Verfügung.
|
||||||
|
|||||||
+91
@@ -0,0 +1,91 @@
|
|||||||
|
# Messprotokoll – Versuch 01 (V1b Baseline mit werkzeugeigenen Agenten) – Prompt-Version 02
|
||||||
|
|
||||||
|
> ## ⚠ FEHLMESSUNG – nicht für Auswertungen verwenden
|
||||||
|
>
|
||||||
|
> Der Lauf brach mit `is_error: true` und HTTP 429 ab: „You've hit your session limit". Erzeugt wurde eine einzige Datei (`Glossar.md`) von sieben geforderten. Verbraucht wurden **392.882.986 Tokens** – der mit Abstand höchste Wert der gesamten Versuchsreihe. Zusätzlich ist die **Modellbedingung verletzt**.
|
||||||
|
|
||||||
|
## Lauf
|
||||||
|
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
|
||||||
|
- **Prompt-Version:** 02
|
||||||
|
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
|
||||||
|
- **Startzeit:** 2026-08-26T16:00:46.8+02:00
|
||||||
|
- **Endzeit:** 2026-08-26T16:35:37.0+02:00
|
||||||
|
- **Dauer gesamt:** 00:34:50 — im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar
|
||||||
|
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||||
|
- **Codebasis-Commit:** `f349d189c735a87f5829bc93f67991320061a2c0` (dirty: nein)
|
||||||
|
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; enthält `SSMS_DB_SCHEMA.sql`
|
||||||
|
(SHA-256 `ED7F21250E868577572B4CADA53C132F7433C74270BF9B59E817CCEC6B1FA8DB`)
|
||||||
|
|
||||||
|
## Werkzeugkonfiguration
|
||||||
|
- **Skill-Version:** 4.5.0 (Laufzeit); Gültigkeitsprüfung nachträglich mit 6.1.0 eingeführt
|
||||||
|
- **Claude-Code-Version:** 2.1.246
|
||||||
|
- **Modell (angefordert):** `claude-opus-5`
|
||||||
|
- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 374.348.393 Tokens (95.28 %), `claude-sonnet-5` 18.527.609 Tokens (4.72 %), `claude-haiku-4-5-20251001` 6.984 Tokens (0.00 %)
|
||||||
|
- **Kontrolle Modell:** **verletzt** – nicht angefordertes Modell `claude-sonnet-5` mit 18.527.609 Tokens (4.72 %)
|
||||||
|
- **Effort:** `high`
|
||||||
|
- **Agentenmodus:** `builtin` (V1b)
|
||||||
|
- **Permission-Mode:** `acceptEdits`
|
||||||
|
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` / 33er-Denylist
|
||||||
|
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
|
||||||
|
- **Parallele Läufe:** ja – der jeweils andere Lauf dieser Zelle
|
||||||
|
- **Subagenten:** 34 gestartet (24 × `Explore`, 10 × `general-purpose`), 32 abgeschlossen, **1 fehlgeschlagen**
|
||||||
|
- **Verschachtelung:** `spawned` = 34, davon `spawned_by_subagents` = 24,
|
||||||
|
`max_depth` = 2, am Nebenläufigkeitslimit abgewiesen: 22
|
||||||
|
|
||||||
|
## Verbrauch
|
||||||
|
|
||||||
|
| Messgröße | `claude-opus-5` | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
|
||||||
|
|---|---:|---:|---:|---:|
|
||||||
|
| Input-Tokens | 4.038 | 296 | 6.962 | 11.296 |
|
||||||
|
| Output-Tokens | 1.970.258 | 136.253 | 22 | 2.106.533 |
|
||||||
|
| Cache-Write-Tokens | 8.663.246 | 665.977 | 0 | 9.329.223 |
|
||||||
|
| Cache-Read-Tokens | 363.710.851 | 17.725.083 | 0 | 381.435.934 |
|
||||||
|
| **Tokens gesamt** | **374.348.393** | **18.527.609** | **6.984** | **392.882.986** |
|
||||||
|
|
||||||
|
|
||||||
|
**Tokens gesamt: 392.882.986** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
|
||||||
|
Der Verbrauch ist **real angefallen** und wird deshalb ausgewiesen, obwohl der Lauf ungültig ist.
|
||||||
|
|
||||||
|
## Gefundene Anforderungen
|
||||||
|
|
||||||
|
Keine. Der Lauf hat eine von sieben verwertbare Ergebnisdatei(en) erzeugt; eine Auswertung mit
|
||||||
|
`analyse-anforderungen.py` ist gegenstandslos.
|
||||||
|
|
||||||
|
## Ergebnis
|
||||||
|
- **Gültigkeit:** **Fehlmessung** – API-Abbruch (HTTP 429, Session-Limit) und verletzte Modellbedingung
|
||||||
|
- **Status:** `is_error` = true, `subtype` = `success`, `stop_reason` = `stop_sequence`,
|
||||||
|
`terminal_reason` = `api_error`
|
||||||
|
- **Session-ID:** `d23d004f-5de4-47d7-a3c9-dbc25dafbe27`
|
||||||
|
- **Permission-Denials:** 0
|
||||||
|
- **Erzeugte Dateien:** `Glossar.md` (22.279 B) – von sieben geforderten Artefakten
|
||||||
|
- **Root unverändert:** ja
|
||||||
|
- **Abschlusstext des Agenten:** „You've hit your session limit · resets 5:40pm (Europe/Berlin)"
|
||||||
|
|
||||||
|
## Anmerkungen/Auffälligkeiten
|
||||||
|
|
||||||
|
**1. Abbruch durch Kontingentgrenze, nicht durch einen Fehler im Lauf.**
|
||||||
|
`terminal_reason: api_error`, `api_error_status: 429`. Der Lauf hatte zu diesem Zeitpunkt bereits
|
||||||
|
392,9 Mio. Tokens verbraucht – mehr als das Doppelte des bisher teuersten gültigen Laufs
|
||||||
|
(150,3 Mio., Fable/`builtin` aus Iteration 1). Auffällig ist die Diskrepanz zwischen
|
||||||
|
`duration_ms` (446 ms) und `duration_api_ms` (25.332.446 ms ≈ 7:02 h): Letzteres ist die Summe
|
||||||
|
der nebenläufigen Anfragen aller 34 Subagenten, nicht die Wanduhrzeit von 34:50.
|
||||||
|
|
||||||
|
**2. Modellbedingung verletzt – zweiter dokumentierter Fall der Reihe.** Angefordert war
|
||||||
|
`claude-opus-5`; `modelUsage` weist zusätzlich **`claude-sonnet-5` mit 18.527.609 Tokens
|
||||||
|
(4,72 %)** aus. Der erste Fall war Fable + `builtin` in Iteration 1, wo 91 % des Verbrauchs auf
|
||||||
|
`claude-opus-5[1m]` entfielen. Beide Fälle betreffen **ausschließlich den Modus `builtin`**:
|
||||||
|
`--model` steuert den Hauptagenten, nicht zwingend die Subagenten. Bei 34 Subagenten
|
||||||
|
(24 `Explore`, 10 `general-purpose`) ist plausibel, dass die `Explore`-Agenten auf einem
|
||||||
|
anderen Modell liefen. **Konsequenz für die Versuchsplanung: Bei `builtin` ist die
|
||||||
|
Modellbedingung nicht allein über `--model` herstellbar.** Für einen sauberen Modellvergleich
|
||||||
|
ist entweder `solo` zu verwenden oder die Modellbindung der Subagenten gesondert zu belegen.
|
||||||
|
|
||||||
|
**3. Extremste Delegation der Reihe:** 34 Subagenten, davon **24 von Subagenten gestartet**
|
||||||
|
(`max_depth` = 2), 22 weitere am Nebenläufigkeitslimit abgewiesen, einer fehlgeschlagen. Die
|
||||||
|
Prompts der 24 Enkel-Agenten sind nicht erfasst – sie liegen in Transkripten, die zwar als
|
||||||
|
Dateien angelegt, aber leer bleiben.
|
||||||
|
|
||||||
|
**4. Zusammen mit `116d` sind in dieser Zelle rund 586 Mio. Tokens ohne verwertbares Ergebnis
|
||||||
|
angefallen.** Die Kombination Opus + `builtin` + Prompt-Version 02 hat in beiden Läufen zu einer
|
||||||
|
Delegationstiefe geführt, die weder das Zeitlimit des Headless-Modus noch das Session-Kontingent
|
||||||
|
trägt. Vor einer Wiederholung ist zu entscheiden, ob die Zelle überhaupt sinnvoll messbar ist.
|
||||||
+90
@@ -0,0 +1,90 @@
|
|||||||
|
# Messprotokoll – Versuch 01 (V1b Baseline mit werkzeugeigenen Agenten) – Prompt-Version 02
|
||||||
|
|
||||||
|
> ## ⚠ FEHLMESSUNG – nicht für Auswertungen verwenden
|
||||||
|
>
|
||||||
|
> Der Lauf brach mit `is_error: true` und HTTP 429 ab: „You've hit your session limit ·
|
||||||
|
> resets 10:50pm (Europe/Berlin)". Erzeugt wurden **null Ergebnisdateien**. Verbraucht wurden
|
||||||
|
> bis zum Abbruch **204.385.225 Tokens**.
|
||||||
|
|
||||||
|
## Lauf
|
||||||
|
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
|
||||||
|
- **Prompt-Version:** 02
|
||||||
|
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
|
||||||
|
- **Startzeit:** 2026-08-26T20:00:13.2974808+02:00
|
||||||
|
- **Endzeit:** 2026-08-26T20:31:25.0410574+02:00
|
||||||
|
- **Dauer gesamt:** 00:07:4x — bis zum Kontingentabbruch
|
||||||
|
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||||
|
- **Codebasis-Commit:** `f349d189c735a87f5829bc93f67991320061a2c0` (dirty: nein)
|
||||||
|
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; enthält `SSMS_DB_SCHEMA.sql`
|
||||||
|
|
||||||
|
## Werkzeugkonfiguration
|
||||||
|
- **Skill-Version:** 7.0.0
|
||||||
|
- **Claude-Code-Version:** 2.1.246
|
||||||
|
- **Modell (angefordert):** `claude-opus-5`
|
||||||
|
- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 204.378.242 (100.00 %), `claude-haiku-4-5-20251001` 6.983 (0.00 %)
|
||||||
|
- **Kontrolle Modell:** bestanden
|
||||||
|
- **Effort:** `high`
|
||||||
|
- **Agentenmodus:** `builtin` (V1b)
|
||||||
|
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
|
||||||
|
- **Hintergrund-Wartezeit:** `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`
|
||||||
|
- **Parallele Läufe:** **ja** – alle vier Läufe der Welle liefen gleichzeitig
|
||||||
|
- **Subagenten:** 24 gestartet (11 × `Explore`, 13 × `general-purpose`), `max_depth` = 2
|
||||||
|
|
||||||
|
## Verbrauch
|
||||||
|
|
||||||
|
| Messgröße | `claude-opus-5` | `claude-haiku-4-5-20251001` | Summe |
|
||||||
|
|---|---:|---:|---:|
|
||||||
|
| Input-Tokens | 2.786 | 6.960 | 9.746 |
|
||||||
|
| Output-Tokens | 1.554.538 | 23 | 1.554.561 |
|
||||||
|
| Cache-Write-Tokens | 5.985.107 | 0 | 5.985.107 |
|
||||||
|
| Cache-Read-Tokens | 196.835.811 | 0 | 196.835.811 |
|
||||||
|
| **Tokens gesamt** | **204.378.242** | **6.983** | **204.385.225** |
|
||||||
|
|
||||||
|
|
||||||
|
**Tokens gesamt: 204.385.225** — real angefallen und deshalb ausgewiesen, obwohl der Lauf ungültig ist.
|
||||||
|
|
||||||
|
## Gefundene Anforderungen
|
||||||
|
|
||||||
|
Keine. Das Ergebnisverzeichnis ist leer; eine Auswertung ist gegenstandslos.
|
||||||
|
|
||||||
|
## Ergebnis
|
||||||
|
- **Gültigkeit:** **Fehlmessung** – API-Abbruch (HTTP 429, Session-Kontingent); Ergebnisverzeichnis leer
|
||||||
|
- **Status:** `is_error` = true, `terminal_reason` = `api_error`, `api_error_status` = 429
|
||||||
|
- **Session-ID:** `7312f1e5-98fe-447a-8150-f9c8427bf0f7`
|
||||||
|
- **Turns:** 1
|
||||||
|
- **Permission-Denials:** 0
|
||||||
|
- **Erzeugte Dateien:** **keine**
|
||||||
|
- **Root unverändert:** ja
|
||||||
|
- **Abschlusstext des Agenten:** „You've hit your session limit · resets 10:50pm (Europe/Berlin)"
|
||||||
|
|
||||||
|
## Anmerkungen/Auffälligkeiten
|
||||||
|
|
||||||
|
**1. Kontingentabbruch, nicht Laufversagen.** Vier Läufe wurden am 26.08. um 19:59 gleichzeitig
|
||||||
|
gestartet; alle vier liefen in dieselbe Grenze. Zusammen hatten sie zu diesem Zeitpunkt
|
||||||
|
297,4 Mio. Tokens verbraucht, davon allein 204,4 Mio. im Lauf `45dd`. Die Parallelität von vier
|
||||||
|
Läufen – darunter einer mit extremer Delegation – hat das Kontingent gerissen.
|
||||||
|
|
||||||
|
**2. Konsequenz für den Versuchsaufbau:** Die verbleibenden Zellen werden **seriell** gefahren.
|
||||||
|
Der erste serielle Lauf danach (`opus-5/solo/high`, `2269`) lief mit 38,1 Mio. Tokens sauber durch.
|
||||||
|
|
||||||
|
**3. Dritter Totalausfall derselben Zelle.** `opus-5/builtin/high` ist damit dreimal
|
||||||
|
gescheitert, ohne je ein Artefakt zu liefern:
|
||||||
|
|
||||||
|
| Lauf | Abbruch | Subagenten | Tokens |
|
||||||
|
|---|---|---:|---:|
|
||||||
|
| `116d` | 600-s-Zeitlimit für Hintergrund-Subagenten | 20 (10 verschachtelt) | 193,4 Mio. |
|
||||||
|
| `9d9e` | Kontingent (HTTP 429) | 34 (24 verschachtelt) | 392,9 Mio. |
|
||||||
|
| `45dd` | Kontingent (HTTP 429) | 24 | 204,4 Mio. |
|
||||||
|
| | | **Summe** | **790,7 Mio.** |
|
||||||
|
|
||||||
|
Das Muster ist jedes Mal identisch: Opus zerlegt die Aufgabe in 20 bis 34 Subagenten, beendet
|
||||||
|
seinen eigenen Turn nach einem einzigen Turn und überlässt die Arbeit den Hintergrundagenten.
|
||||||
|
Die in Skill 6.1.0 eingeführte Einstellung `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0` hat das
|
||||||
|
Zeitlimit beseitigt – der Lauf scheiterte diesmal am Kontingent, das die Delegationsbreite
|
||||||
|
erzeugt.
|
||||||
|
|
||||||
|
**4. Die Zelle ist mit dieser Prompt-Version und diesem Modell nicht messbar.** Drei
|
||||||
|
reproduzierbare Ausfälle sind als Grenzbefund über die Delegation aussagekräftiger als ein
|
||||||
|
vierter Versuch. Ein weiterer Anlauf wäre nur mit gedrosselter Nebenläufigkeit
|
||||||
|
(`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`) sinnvoll – das wäre allerdings eine geänderte
|
||||||
|
Werkzeugkonfiguration und damit nicht mehr mit den Sonnet-`builtin`-Läufen vergleichbar.
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
{"is_error":true,"duration_api_ms":18953757,"num_turns":1,"stop_reason":"stop_sequence","session_id":"7312f1e5-98fe-447a-8150-f9c8427bf0f7","total_cost_usd":175.15875799999992,"usage":{"output_tokens_details":{"thinking_tokens":0},"input_tokens":0,"cache_creation_input_tokens":0,"cache_read_input_tokens":0,"output_tokens":0,"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":0,"ephemeral_5m_input_tokens":0},"inference_geo":"","iterations":[],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6960,"outputTokens":23,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007075,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-opus-5":{"inputTokens":2786,"outputTokens":1554538,"cacheReadInputTokens":196835811,"cacheCreationInputTokens":5985107,"webSearchRequests":0,"costUSD":175.15168299999993,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-opus-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"api_error","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","origin":{"kind":"task-notification"},"subagent_stats":{"spawned":24,"requested":{"background":0,"foreground":0,"unset":24},"started_in_background":24,"max_depth":2,"spawned_by_subagents":11,"completed":10,"failed":14,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":7,"budget":0},"by_type":{"general-purpose":13,"Explore":11}},"subtype":"success","api_error_status":429,"result":"You've hit your session limit · resets 10:50pm (Europe/Berlin)","type":"result","duration_ms":357,"uuid":"d880473e-010c-4790-bd6c-7be798a324e7","queued_turn_count":0}
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
|
||||||
+178
@@ -0,0 +1,178 @@
|
|||||||
|
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
|
||||||
|
|
||||||
|
## Metadaten
|
||||||
|
- **Versuch:** V1 Baseline (Prompt-only)
|
||||||
|
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
|
||||||
|
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||||
|
- **Zeitstempel:** 2026-08-26
|
||||||
|
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
|
||||||
|
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||||
|
|
||||||
|
| Änderung | Auslösender Befund |
|
||||||
|
|---|---|
|
||||||
|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
|
||||||
|
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
|
||||||
|
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
|
||||||
|
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
|
||||||
|
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
|
||||||
|
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
|
||||||
|
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
|
||||||
|
|
||||||
|
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
|
||||||
|
|
||||||
|
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||||
|
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||||
|
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Prompt
|
||||||
|
|
||||||
|
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||||
|
|
||||||
|
### Auftrag
|
||||||
|
|
||||||
|
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||||
|
|
||||||
|
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||||
|
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||||
|
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||||
|
|
||||||
|
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||||
|
|
||||||
|
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||||
|
|
||||||
|
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
**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. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
|
||||||
|
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||||
|
|
||||||
|
### Formatvorgabe pro Anforderung
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||||
|
Titel: <kurzer Titel>
|
||||||
|
Ebene: <StRS | SyRS | SwRS>
|
||||||
|
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||||
|
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)
|
||||||
|
|
||||||
|
```
|
||||||
|
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)
|
||||||
|
```
|
||||||
|
|
||||||
|
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?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||||
|
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien, das Ausführen von
|
||||||
|
Kommandozeilenbefehlen im Arbeitsverzeichnis sowie die werkzeugeigenen Subagenten.
|
||||||
|
Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
|
||||||
|
Werkzeugserver.
|
||||||
|
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||||
|
Werkzeuge zu ersetzen.
|
||||||
|
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||||
|
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||||
|
`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-opus-5\builtin\high\02_Lauf_2026-08-26_195958_v7.0.0-45dd\Ergebnisse\`.
|
||||||
|
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-26T20:31:25.0410574+02:00
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-26T20:00:13.2974808+02:00
|
||||||
+181
@@ -0,0 +1,181 @@
|
|||||||
|
# Analysebericht — Reverse Requirements Engineering c-entron ERP-Suite
|
||||||
|
|
||||||
|
**Untersuchungsgegenstand:** Gesamte Codebasis unter `C:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||||
|
**Vorgehen:** Statische Analyse (Lesen/Suchen von Dateien, Kommandozeile). Keine Ausführung, kein Datenbankzugriff, keine externen Werkzeuge.
|
||||||
|
**Norm:** ISO/IEC/IEEE 29148:2018 (StRS/SyRS/SwRS), ISO/IEC 25010 für Qualitätsmerkmale.
|
||||||
|
**Datum des Laufs:** 2026-08-26
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Schritt 0 — Modulinventar
|
||||||
|
|
||||||
|
Das Inventar wurde **vor** der Formulierung der ersten Anforderung erstellt. Bezugsquellen für die
|
||||||
|
Vollständigkeit:
|
||||||
|
|
||||||
|
* `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs` — die zentrale Registrierungsliste der
|
||||||
|
fachlichen Module des WPF-Clients (82 registrierte `ModuleRegistrationItem`-Einträge inkl. Testmodul).
|
||||||
|
* `Centron.sln`, `docs/getting-started/ai-codebase-navigation.md` — Top-Level-Aufteilung der Projekte.
|
||||||
|
* `src/webservice/Centron.Host/AspNetCore/HostedServices/` — 37 Hintergrunddienste.
|
||||||
|
* `SSMS_DB_SCHEMA.sql` — 1.558 Tabellen, 181 Views, 59 Stored Procedures.
|
||||||
|
|
||||||
|
Das Inventar ist die Bezugsgröße für die Abdeckungstabelle in Abschnitt 3.
|
||||||
|
|
||||||
|
### 1.1 Fachliche Module (WPF-Client, Registrierungsgruppen wie im Quelltext)
|
||||||
|
|
||||||
|
| # | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-01 | Pauschalabrechnung | `src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/` | Pauschale (nicht aufwandsbezogene) Abrechnung von Projekten/Leistungen |
|
||||||
|
| M-02 | Provisionsauswertung | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Provision/Evaluation/` | Auswertung von Vertriebsprovisionen je Mitarbeiter/Zeitraum |
|
||||||
|
| M-03 | Provisionsschemas verwalten | `.../Finances/Receipts/Provision/Schemas/` | Definition der Berechnungsregeln für Provisionen |
|
||||||
|
| M-04 | Provisionsschema-Kundenzuordnung | `.../Finances/Receipts/Provision/SchemaCustomerAssignments/` | Zuordnung von Provisionsschemata zu Kunden |
|
||||||
|
| M-05 | Vereinfachte Ticketabrechnung | `.../Finances/TimerBilling/` | Abrechnung erfasster Ticketzeiten ohne vollen Belegdurchlauf |
|
||||||
|
| M-06 | Vertragsabrechnung (automatisiert) | `.../Finances/AutomatedBilling/`, BL `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/` | Periodische Rechnungserzeugung aus Verträgen |
|
||||||
|
| M-07 | Aufschläge Stundensätze | `.../Administration/HourlySurchargeRates/` | Zuschlagsätze auf Stundensätze (z. B. Nacht/Wochenende) |
|
||||||
|
| M-08 | c-entron DSGVO | `.../Administration/DSGVO/`, BL `src/backend/Centron.BL/Administration/Documents/Dsgvo/` | Auftragsverarbeitungsverträge, Online-PDF-Dokumente, Datenschutzdokumentation |
|
||||||
|
| M-09 | Einstellungen (Modul) | `.../Administration/Settings/` | Zentrale Anwendungseinstellungen des Mandanten |
|
||||||
|
| M-10 | Kontenrahmen | `.../Warehousing/AccountSystems/` | Buchhaltungskontenrahmen und Konten |
|
||||||
|
| M-11 | Leasing/Service | `.../Administration/SalesAndLeasing/` | Leasing- und Servicevertragsstammdaten |
|
||||||
|
| M-12 | Mailvorlagen | `.../Administration/MailTemplates/` | Verwaltung von E-Mail-Vorlagen mit Variablen |
|
||||||
|
| M-13 | Mandantenverwaltung | `.../Administration/MandatorManagement/` | Mehrmandantenfähigkeit, Mandantenstammdaten |
|
||||||
|
| M-14 | Mitarbeiterverwaltung | `.../Administration/EmployeeManagement/` | Personalstamm, Abteilungen, Filialzuordnung |
|
||||||
|
| M-15 | Rechteverwaltung | `.../Administration/RightsManagement/` | Benutzerrechte und Rechtegruppen |
|
||||||
|
| M-16 | Textbausteinverwaltung | `.../Administration/TextBlockManagement/` | Wiederverwendbare Textbausteine |
|
||||||
|
| M-17 | Ticketprozess-Vorlagen | `.../Helpdesk/TicketProcessTemplates/` | Vorlagen für mehrstufige Ticketprozesse (C-FLOW) |
|
||||||
|
| M-18 | Vertragsarten | `.../Finances/Contracts/ContractSettings/ContractTypes/` | Katalog der Vertragsarten |
|
||||||
|
| M-19 | Adressstamm (klassisch) | `.../Finances/AccountManagement/` | Kunden-/Lieferantenstamm in der klassischen Maske |
|
||||||
|
| M-20 | CRM (Account Management neu) | `.../Finances/Crm/` | Alternative CRM-Sicht auf denselben Adressstamm |
|
||||||
|
| M-21 | Audit / Umfragen | `.../Survey/`, BL `src/backend/Centron.BL/…` | Kundenbefragungen und Audits |
|
||||||
|
| M-22 | CRM-Projekte | `.../Finances/Projects/` | Vertriebsprojekte / Opportunities |
|
||||||
|
| M-23 | Kampagnen & Mailing | `.../Finances/Campaigns/` | Marketingkampagnen, Teilnehmer, Phasen, Serienmails |
|
||||||
|
| M-24 | Lieferantenverträge | `.../Finances/Crm/AccountContracts/` | Verträge auf Lieferantenseite |
|
||||||
|
| M-25 | PLM (Product Lifecycle) | `.../PLM/` | Lizenz-/Produktlebenszyklus beim Kunden |
|
||||||
|
| M-26 | Stammblätter | `.../Finances/MasterDataLists/OverView/` | Geräte-/Anlagenstammblätter beim Kunden (Seriennummern, Zähler) |
|
||||||
|
| M-27 | Erwartete Events | `.../Helpdesk/ExpectedEvents/` | Überwachung erwarteter technischer Ereignisse |
|
||||||
|
| M-28 | Erwartete Events — Auswertung | `.../Helpdesk/ExpectedEventsReporting/` | Auswertung der Ereignisüberwachung |
|
||||||
|
| M-29 | Reportserver | `.../Administration/ReportServer/` | Zeitgesteuerte Reportausführung und -verteilung |
|
||||||
|
| M-30 | Buchhaltungsexport/-import | `.../DataExchange/BookKeeping/` | Übergabe von Buchungssätzen an die Finanzbuchhaltung |
|
||||||
|
| M-31 | DATEV Belegtransfer | `.../DataExchange/DatevOnline2020/` | Belegtransfer an DATEV Unternehmen online |
|
||||||
|
| M-32 | Kalkulation pro Filiale | `.../DataExchange/SupplierOrderPerBranch/` | Filialbezogene Einkaufs-/Kalkulationsauswertung |
|
||||||
|
| M-33 | Mahnwesen | `.../Finances/Dunning/`, BL `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/` | Mahnläufe über offene Rechnungen, Mahnstufen |
|
||||||
|
| M-34 | OPOS | `.../Finances/Opos/` | Offene-Posten-Übersicht |
|
||||||
|
| M-35 | SEPA / Zahlungsverkehr | `.../DataExchange/PaymentTransactions/` | SEPA-Lastschriften und -Überweisungen, Mandate |
|
||||||
|
| M-36 | Zahlungseingang | `.../Finances/Payments/` | Erfassung und Zuordnung von Zahlungseingängen |
|
||||||
|
| M-37 | Analytics / Verkaufsstatistik | `.../Statistics/SaleStatistics/` | Umsatz-, Margen- und Verkaufsauswertungen |
|
||||||
|
| M-38 | Leistungsnachweise | `.../Statistics/EmployeeAnalytics/` | Leistungs-/Auslastungsnachweise je Mitarbeiter |
|
||||||
|
| M-39 | Management Info | `.../Statistics/ManagementInfo/` | Verdichtete betriebswirtschaftliche Kennzahlen |
|
||||||
|
| M-40 | Mitarbeiterauslastung | `.../MyCentron/MyDay/EmployeeOverview/` | Auslastungssicht über Mitarbeiter hinweg |
|
||||||
|
| M-41 | MSP-Auswertung (Comparer) | `.../Global/MSPLicensesCompare/` | Abgleich MSP-Lizenzbestand gegen Verträge |
|
||||||
|
| M-42 | MSP-Collector | `.../Statistics/MspCollectors/` | Einsammeln von MSP-Nutzungsdaten aus Fremdsystemen |
|
||||||
|
| M-43 | MSP-Dashboard | `.../Statistics/MspStatistics/` | Verdichtete MSP-Kennzahlen |
|
||||||
|
| M-44 | Vertragsauswertung | `.../Finances/ContractEvaluation2/` | Wirtschaftlichkeitsauswertung von Verträgen |
|
||||||
|
| M-45 | Belegerfassung Einkauf | `.../Warehousing/OutcomingPayments/` | Erfassung von Eingangsbelegen/Ausgangszahlungen |
|
||||||
|
| M-46 | Bestellvorschlagsliste | `.../Purchasing/OrderSuggestionList/` | Automatische Bestellvorschläge aus Bedarf/Bestand |
|
||||||
|
| M-47 | EDI-Verwaltung | `.../Purchasing/EDIManagement/`, BL `src/backend/Centron.BL/EDI/` | Elektronischer Belegaustausch mit Distributoren |
|
||||||
|
| M-48 | Eingang / Kalkulation | `.../Finances/Receipts/SupplierReceiptDocuments/` | Wareneingang mit Einkaufskalkulation |
|
||||||
|
| M-49 | Checklisten | `.../Helpdesk/CentronChecklist/` | Checklistenvorlagen und -instanzen an Tickets |
|
||||||
|
| M-50 | Projektverwaltung | `.../ProjectManagement/` | Interne Projektverwaltung (nur c-entron-intern freigeschaltet) |
|
||||||
|
| M-51 | RMA / Werkstatt | `.../Rma/` | Retouren-/Reparaturabwicklung |
|
||||||
|
| M-52 | Taskmanagement | `.../Helpdesk/TaskManagment/` | Aufgabenverwaltung mit Board-Sicht |
|
||||||
|
| M-53 | Ticket-Liste / Helpdesk | `.../Helpdesk/TicketList/`, BL `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs` | Serviceticket-Bearbeitung, Zeiterfassung, Eskalation |
|
||||||
|
| M-54 | c-entron Inspektor | `.../MyCentron/CentronInspectors/` | Technisches Diagnosewerkzeug (nur Admin) |
|
||||||
|
| M-55 | c-entron Logs | `.../Administration/LogViewer/` | Einsicht in Anwendungsprotokolle |
|
||||||
|
| M-56 | SQL-Manager | `.../Administration/SqlManagers/` | Direkter SQL-Zugriff für Administratoren |
|
||||||
|
| M-57 | Artikelimport | `.../Warehousing/ArticleImport/` | Import von Artikelstammdaten aus Distributorlisten |
|
||||||
|
| M-58 | Artikelverwaltung | `.../Warehousing/ArticleManagement/` | Artikelstamm, Preise, Warengruppen, Bestände |
|
||||||
|
| M-59 | Inventur | `.../Warehousing/Inventory/` | Inventurerfassung und -abschluss |
|
||||||
|
| M-60 | Kommissionierung | `.../Warehousing/Commissions/` | Kommissionierung von Aufträgen im Lager |
|
||||||
|
| M-61 | Dashboard | `.../MyCentron/Dashboard/` | Persönliches Einstiegs-Dashboard |
|
||||||
|
| M-62 | Mein Tag (MyDay) | `.../MyCentron/MyDay/Editor/` | Tagesbezogene Zeit-/Aufgabenerfassung |
|
||||||
|
| M-63 | Telefonate (TAPI) | `.../MyCentron/Telephony/CallLog/`, BL `src/backend/Centron.BL/Tapi/` | Telefonanbindung und Gesprächsprotokoll |
|
||||||
|
| M-64 | Todo-Liste | `.../MyCentron/TodoList/` | Persönliche Aufgabenliste |
|
||||||
|
| M-65 | KI-Chat | `.../ArtificialIntelligence/Chat/` | KI-Assistent im Client |
|
||||||
|
| M-66 | Persönliche Einstellungen | `.../MyCentron/PersonalSettings/` | Benutzerbezogene Einstellungen (13 Seiten) |
|
||||||
|
| M-67 | Passwort-Manager Richtlinien | `.../PasswordManager/` (GuidelineManagement) | Passwortrichtlinien für verwaltete Zugänge |
|
||||||
|
| M-68 | Passwort-Manager Zugänge | `.../PasswordManager/` (AccessManagement) | Verschlüsselte Ablage von Kundenzugängen |
|
||||||
|
| M-69 | Passwort-Manager Zugangsbereiche | `.../PasswordManager/` (AccessAreaManagement) | Bereichsstruktur für Zugänge |
|
||||||
|
| M-70 | Maschinenverwaltung | `.../Production/MachineManagement/` | Produktionsmaschinen |
|
||||||
|
| M-71 | Produktionsaufträge | `.../Production/ProductionOrder/` | Fertigungsaufträge mit Arbeitsschritten |
|
||||||
|
| M-72 | Belegkonditionen | `.../Administration/ReceiptConditions/` | Liefer-/Zahlungskonditionen für Belege |
|
||||||
|
| M-73 | Data Updater (Massenupdates) | `.../Massenupdates/`, BL `src/backend/Centron.BL/MassUpdate/` | Regelbasierte Massenänderung von Datensätzen |
|
||||||
|
| M-74 | Kostenträger/Kostenstellen | `.../PayersAndCostCenter/` | Kostenrechnungsobjekte |
|
||||||
|
| M-75 | Länderverwaltung | `.../Administration/CountryManagement/` | Länder, Währungen, Steuerkennzeichen |
|
||||||
|
| M-76 | Mehrwertsteuerverwaltung | `.../Warehousing/…/ValueAddedTax` | Steuersätze und deren Gültigkeit |
|
||||||
|
| M-77 | Projektpreis-Import | `.../ProjectPriceImport/` | Import von Projektpreisen (Sonderkonditionen) |
|
||||||
|
| M-78 | Reportverwaltung | `.../Reports/ReportManagement/`, BL `src/backend/Centron.BL/ReportEngine/` | Verwaltung und Ausführung von Reports |
|
||||||
|
| M-79 | Warengruppenverwaltung | `.../Warehousing/MaterialGroupManagement/` | Warengruppenhierarchie |
|
||||||
|
| M-80 | Dynamischer Datenimport Verträge | `.../Sales/SpecialArticleToContractImport/` | Periodischer Mengen-/Nutzungsimport in Verträge |
|
||||||
|
| M-81 | Klick-Zählerverwaltung | `.../Finances/DeviceClickCounter/` | Zählerstände für Klickabrechnung (Drucker/Kopierer) |
|
||||||
|
| M-82 | Statischer Datenimport Verträge | `.../Sales/SpecialArticleImport/` | Import fester Sonderartikel/-preise |
|
||||||
|
| M-83 | Einstellungsseiten ohne Modul | `ModuleRegistration.GetSettingsWithoutModule()` | 85 fachliche Einstellungsseiten, die kein eigenes Modul bilden |
|
||||||
|
| M-84 | Belegwesen Verkauf (Kern) | `src/backend/Centron.BL/Sales/Receipts/`, `src/backend/Centron.Entities/Entities/Sales/Receipts/` | Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholschein, Vertrag |
|
||||||
|
|
||||||
|
### 1.2 Technische Komponenten und Plattform
|
||||||
|
|
||||||
|
| # | Komponente | Pfad | Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| T-01 | Centron.Entities | `src/backend/Centron.Entities/` | NHibernate-Entitäten (86 fachliche Unterverzeichnisse) |
|
||||||
|
| T-02 | Centron.DAO | `src/backend/Centron.DAO/` | FluentNHibernate-Mappings, Repositories, Named Queries, ADO-Zugriff |
|
||||||
|
| T-03 | Centron.BL | `src/backend/Centron.BL/` | Geschäftslogik (85 fachliche Unterverzeichnisse) |
|
||||||
|
| T-04 | Centron.Interfaces | `src/backend/Centron.Interfaces/` | DTO-/Filter-/Enum-Verträge zwischen den Schichten |
|
||||||
|
| T-05 | Centron.Common | `src/backend/Centron.Common/` | Querschnittshelfer (Kodierung, Netzwerk, Assembly-Infos) |
|
||||||
|
| T-06 | Centron.Gateway | `src/backend/Centron.Gateway/` | EDI-Parserbibliotheken je Distributor |
|
||||||
|
| T-07 | Centron.Core | `src/shared/Centron.Core/` | Geteilte Basisbibliothek (TOTP, Parser, Utils) |
|
||||||
|
| T-08 | Centron.Controls | `src/shared/Centron.Controls/` | Wiederverwendbare WPF-Steuerelemente |
|
||||||
|
| T-09 | Centron.WPF.UI (Shell) | `src/centron/Centron.WPF.UI/` | Windows-Client, Modulhost, MVVM |
|
||||||
|
| T-10 | Centron.WPF.UI.Extension | `src/centron/Centron.WPF.UI.Extension/` | Erweiterungspunkte/Schnittstellen für Module |
|
||||||
|
| T-11 | Legacy-REST-Service | `src/webservice/Centron.WebServices.Core/` | `ICentronRestService`, Rechtekonstanten, Legacy-DTOs |
|
||||||
|
| T-12 | Moderne REST-API | `src/webservice/Centron.Controllers/` | Versionierte ASP.NET-Core-Controller (v1) |
|
||||||
|
| T-13 | Web-Service-Hosts | `src/webservice/Centron.Host*/` | Self-Host, Konsolen- und Windows-Dienst-Host |
|
||||||
|
| T-14 | Hintergrunddienste | `src/webservice/Centron.Host/AspNetCore/HostedServices/` | 37 periodische Dienste (EDI, Eskalation, Datenqualität …) |
|
||||||
|
| T-15 | Echtzeitdienste (SignalR) | `src/webservice/Centron.Host/RealTimeServices/` | Chat, Benachrichtigungen, Verfügbarkeit, TAPI |
|
||||||
|
| T-16 | Authentifizierung & Ticketing | `src/backend/Centron.BL/Administration/Logins/` | Basic/AD/OIDC/WebAccount, Ticketvergabe, 2FA |
|
||||||
|
| T-17 | Lizenzierung | `src/backend/Centron.BL/Administration/Licensing/` | Lizenzprüfung gegen Lizenzserver, Feature-Freischaltung |
|
||||||
|
| T-18 | Nexus ServiceBoard | `src/nexus/CentronNexus/ServiceBoard/` | Webbasierte Ticketbearbeitung (Blazor Server) |
|
||||||
|
| T-19 | Nexus WebCart / Kundenportal | `src/nexus/CentronNexus/WebCart/` | Kundenshop und Kundenportal |
|
||||||
|
| T-20 | Nexus WebOffer | `src/nexus/CentronNexus/WebOffer/` | Webbasierte Belegansicht/Freigabe |
|
||||||
|
| T-21 | Nexus Office / Dokumentsignatur | `src/nexus/CentronNexus/Office/`, `.../DocumentSigning/` | Geteilte Dokumente, Freigabe, digitale Signatur |
|
||||||
|
| T-22 | Nexus Management | `src/nexus/CentronNexus/Management/` | Verwaltung von Web-Accounts, Ticketvorlagen, Tasks |
|
||||||
|
| T-23 | Nexus Settings | `src/nexus/CentronNexus/Settings/` | Portaleinstellungen, Branding, Themes |
|
||||||
|
| T-24 | Nexus Host | `src/nexus/CentronNexus.Host/` | Kestrel/HttpSys-Host, Auth-Pipeline, Middleware |
|
||||||
|
| T-25 | Outlook Add-In | `src/nexus/CentronNexus.OutlookAddIn/` | Outlook-Integration für CRM/Tickets/Belege |
|
||||||
|
| T-26 | ConnectionManager | `src/webservice/c-entron.misc.ConnectionManager/` | Verbindungsprofile für den Client |
|
||||||
|
| T-27 | API COP | `src/apis/Centron.APIs.CopDataAccess/` | SOAP-Anbindung Distributor COP |
|
||||||
|
| T-28 | API EGIS | `src/apis/Centron.APIs.EgisDataAccess/` | Elektronische Rechnungsstellung EGIS |
|
||||||
|
| T-29 | API FinAPI | `src/apis/Centron.APIs.FinAPI/` | Bankdatenzugriff (Online-Banking) |
|
||||||
|
| T-30 | API ITscope | `src/apis/Centron.APIs.ITscopeDataAccess/` | Produkt-/Preisdaten ITscope |
|
||||||
|
| T-31 | API Icecat | `src/apis/Centron.APIs.IcecatDataAccess/` | Produktbeschreibungen/Bilder Icecat |
|
||||||
|
| T-32 | API ebInterface | `src/apis/Centron.Api.EbInterface/` | Österreichisches E-Rechnungsformat |
|
||||||
|
| T-33 | API GLS | `src/apis/Centron.Api.Gls/` | Versanddienstleister GLS |
|
||||||
|
| T-34 | API Shipcloud | `src/apis/Centron.Api.Shipcloud/` | Versand-Aggregator Shipcloud |
|
||||||
|
| T-35 | API docuFORM | `Centron.Api.docuFORM/` | Anbindung docuFORM (Druckerdatenerfassung) |
|
||||||
|
| T-36 | Deployment / Installer | `deployment/` | WiX-Installer für Client und Dienste |
|
||||||
|
| T-37 | Container | `docker/` | Dockerfile und Compose-Definitionen |
|
||||||
|
| T-38 | CI/CD | `azure/`, `.github/` | Build-, Test-, Analyse- und Docker-Pipelines |
|
||||||
|
| T-39 | Tests | `tests/` | Unit-, Integrations-, E2E- und Playwright-Tests |
|
||||||
|
| T-40 | Datenbankschema | `SSMS_DB_SCHEMA.sql` | 1.558 Tabellen, 181 Views, 59 Prozeduren, 134 Fremdschlüssel |
|
||||||
|
| T-41 | Lokalisierung | `**/LocalizedStrings*.resx`, `SharedResource*.resx` | Deutsch (Basis) und Englisch |
|
||||||
|
| T-42 | Build-/Hilfsskripte | `scripts/` | Buildorchestrierung |
|
||||||
|
|
||||||
|
**Inventarumfang: 84 fachliche Module + 42 technische Komponenten = 126 Inventareinträge.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Erhobene Artefakttypen (Schritt 2)
|
||||||
|
|
||||||
|
| Artefakttyp | Erhoben | Bemerkung |
|
||||||
|
|---|---|---|
|
||||||
|
| C#-Quellcode | ja | `src/**/*.cs` |
|
||||||
|
| XAML-UI (WPF) | teilweise | Stichprobenartig; Modulstruktur über Controller erschlossen |
|
||||||
|
| Razor-Komponenten (Blazor) | teilweise | Verzeichnisstruktur vollständig, Inhalte stichprobenartig |
|
||||||
|
| Datenbankschema | ja | `SSMS_DB_SCHEMA.sql` (3,2 MB, Stand 11.11.2025) |
|
||||||
|
| Konfiguration | ja | `appsettings.json`, `Directory.Build.props`, `global.json`, `docker/` |
|
||||||
|
| Projektdokumentation | ja | `docs/**` (44 Markdown-Dateien), `README.md`, `CentronRights.md` |
|
||||||
|
| Deployment-Skripte | ja | `docker/Dockerfile`, `azure/*.yml`, `deployment/` |
|
||||||
|
| Ressourcen/Lokalisierung | teilweise | `ResXManager.config.xml`, Resx-Struktur |
|
||||||
|
| Change-Historie (Commits) | **nein** | Kein Git-Verlauf des Zielsystems im Arbeitsverzeichnis lesbar; siehe Lücke L-1 |
|
||||||
|
| Tickets / Release Notes | teilweise | `src/nexus/CentronNexus/changelog.txt` vorhanden; kein Ticketsystem-Export |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Abschnitt 3 (Abdeckungstabelle), Abschnitt 4 (Konsistenzcheck) und Abschnitt 5 (Selbstbewertung)
|
||||||
|
folgen unten nach Abschluss der Spezifikation.*
|
||||||
+2088
File diff suppressed because it is too large
Load Diff
+79
@@ -0,0 +1,79 @@
|
|||||||
|
# Messprotokoll – Versuch 01 (V1 Baseline) – Prompt-Version 02
|
||||||
|
|
||||||
|
> ## ⚠ FEHLMESSUNG – nicht für Auswertungen verwenden
|
||||||
|
>
|
||||||
|
> Der Lauf brach mit `is_error: true` und HTTP 429 ab: „You've hit your session limit ·
|
||||||
|
> resets 10:50pm (Europe/Berlin)". Erzeugt wurden **2 von sieben** geforderten Ergebnisdateien; der Lauf brach mitten in der Bearbeitung ab. Verbraucht wurden
|
||||||
|
> bis zum Abbruch **7.198.773 Tokens**.
|
||||||
|
|
||||||
|
## Lauf
|
||||||
|
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
|
||||||
|
- **Prompt-Version:** 02
|
||||||
|
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
|
||||||
|
- **Startzeit:** 2026-08-26T20:00:06.7195929+02:00
|
||||||
|
- **Endzeit:** 2026-08-26T20:31:17.3017181+02:00
|
||||||
|
- **Dauer gesamt:** 00:07:4x — bis zum Kontingentabbruch
|
||||||
|
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||||
|
- **Codebasis-Commit:** `f349d189c735a87f5829bc93f67991320061a2c0` (dirty: nein)
|
||||||
|
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; enthält `SSMS_DB_SCHEMA.sql`
|
||||||
|
|
||||||
|
## Werkzeugkonfiguration
|
||||||
|
- **Skill-Version:** 7.0.0
|
||||||
|
- **Claude-Code-Version:** 2.1.246
|
||||||
|
- **Modell (angefordert):** `claude-opus-5`
|
||||||
|
- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 7.191.806 (99.90 %), `claude-haiku-4-5-20251001` 6.967 (0.10 %)
|
||||||
|
- **Kontrolle Modell:** bestanden
|
||||||
|
- **Effort:** `high`
|
||||||
|
- **Agentenmodus:** `solo` (V1)
|
||||||
|
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
|
||||||
|
- **Hintergrund-Wartezeit:** `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`
|
||||||
|
- **Parallele Läufe:** **ja** – alle vier Läufe der Welle liefen gleichzeitig
|
||||||
|
- **Subagenten:** keine (`spawned` = 0)
|
||||||
|
|
||||||
|
## Verbrauch
|
||||||
|
|
||||||
|
| Messgröße | `claude-opus-5` | `claude-haiku-4-5-20251001` | Summe |
|
||||||
|
|---|---:|---:|---:|
|
||||||
|
| Input-Tokens | 100 | 6.945 | 7.045 |
|
||||||
|
| Output-Tokens | 156.962 | 22 | 156.984 |
|
||||||
|
| Cache-Write-Tokens | 278.056 | 0 | 278.056 |
|
||||||
|
| Cache-Read-Tokens | 6.756.688 | 0 | 6.756.688 |
|
||||||
|
| **Tokens gesamt** | **7.191.806** | **6.967** | **7.198.773** |
|
||||||
|
|
||||||
|
|
||||||
|
**Tokens gesamt: 7.198.773** — real angefallen und deshalb ausgewiesen, obwohl der Lauf ungültig ist.
|
||||||
|
|
||||||
|
## Gefundene Anforderungen
|
||||||
|
|
||||||
|
Der Lauf brach vor Abschluss ab. Im vorhandenen **Teilbestand** stehen **65 Anforderungen**. Die Zahl ist **nicht** mit vollständigen Läufen vergleichbar – es fehlen `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`. Die maschinelle Auswertung liegt zur Vollständigkeit unter `_meta/anforderungen.md`, geht aber nicht in Vergleiche ein.
|
||||||
|
|
||||||
|
## Ergebnis
|
||||||
|
- **Gültigkeit:** **Fehlmessung** – API-Abbruch (HTTP 429, Session-Kontingent); nur 2 von sieben Artefakten erzeugt
|
||||||
|
- **Status:** `is_error` = true, `terminal_reason` = `api_error`, `api_error_status` = 429
|
||||||
|
- **Session-ID:** `aa5fb7ff-4191-4b88-b772-9baca2b9cc5c`
|
||||||
|
- **Turns:** 86
|
||||||
|
- **Permission-Denials:** 0
|
||||||
|
- **Erzeugte Dateien:** 2 von sieben geforderten Artefakten:
|
||||||
|
|
||||||
|
| Datei | Größe |
|
||||||
|
|---|---:|
|
||||||
|
| `Analysebericht.md` | 17.284 B |
|
||||||
|
| `StRS.md` | 133.396 B |
|
||||||
|
|
||||||
|
Es fehlen: `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`
|
||||||
|
- **Root unverändert:** ja
|
||||||
|
- **Abschlusstext des Agenten:** „You've hit your session limit · resets 10:50pm (Europe/Berlin)"
|
||||||
|
|
||||||
|
## Anmerkungen/Auffälligkeiten
|
||||||
|
|
||||||
|
**1. Kontingentabbruch, nicht Laufversagen.** Vier Läufe wurden am 26.08. um 19:59 gleichzeitig
|
||||||
|
gestartet; alle vier liefen in dieselbe Grenze. Zusammen hatten sie zu diesem Zeitpunkt
|
||||||
|
297,4 Mio. Tokens verbraucht, davon allein 204,4 Mio. im Lauf `45dd`. Die Parallelität von vier
|
||||||
|
Läufen – darunter einer mit extremer Delegation – hat das Kontingent gerissen.
|
||||||
|
|
||||||
|
**2. Konsequenz für den Versuchsaufbau:** Die verbleibenden Zellen werden **seriell** gefahren.
|
||||||
|
Der erste serielle Lauf danach (`opus-5/solo/high`, `2269`) lief mit 38,1 Mio. Tokens sauber durch.
|
||||||
|
|
||||||
|
**3. Zelle inzwischen gültig belegt.** Der Wiederholungslauf `02_Lauf_2026-08-26_225807_v7.0.0-2269`
|
||||||
|
war erfolgreich: 363 Anforderungen, 99,7 % mit Primärbeleg, 38,1 Mio. Tokens. Dieser Lauf hier
|
||||||
|
bleibt als Beleg für den Kontingentabbruch erhalten.
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
{"is_error":true,"duration_api_ms":1669088,"num_turns":86,"stop_reason":"stop_sequence","session_id":"aa5fb7ff-4191-4b88-b772-9baca2b9cc5c","total_cost_usd":10.090508999999999,"usage":{"input_tokens":100,"cache_creation_input_tokens":278056,"cache_read_input_tokens":6756688,"output_tokens":156962,"output_tokens_details":{"thinking_tokens":8446},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":278056,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":64000,"cache_read_input_tokens":214142,"cache_creation_input_tokens":63914,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":63914},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6945,"outputTokens":22,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007055,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-opus-5":{"inputTokens":100,"outputTokens":156962,"cacheReadInputTokens":6756688,"cacheCreationInputTokens":278056,"webSearchRequests":0,"costUSD":10.083454,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-opus-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"api_error","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":429,"result":"You've hit your session limit · resets 10:50pm (Europe/Berlin)","type":"result","duration_ms":1868837,"uuid":"8ae2f7a0-b8a3-49ae-bdb7-fb36c021be6a","queued_turn_count":0}
|
||||||
+1352
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 | 65 | 100,0 % |
|
||||||
|
| SyRS | 0 | 0,0 % |
|
||||||
|
| SwRS | 0 | 0,0 % |
|
||||||
|
| **Gesamt** | **65** | 100 % |
|
||||||
|
|
||||||
|
### Anforderungstypen
|
||||||
|
|
||||||
|
| Typ | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| funktional | 41 | 63,1 % |
|
||||||
|
| Sicherheit | 9 | 13,8 % |
|
||||||
|
| Schnittstelle | 8 | 12,3 % |
|
||||||
|
| nicht-funktional | 5 | 7,7 % |
|
||||||
|
| Daten | 2 | 3,1 % |
|
||||||
|
|
||||||
|
### Belegqualität
|
||||||
|
|
||||||
|
| Messgröße | Wert |
|
||||||
|
|---|---:|
|
||||||
|
| Belege gesamt | 180 |
|
||||||
|
| davon `PRIMÄR` | 125 (69,4 %) |
|
||||||
|
| davon `SEKUNDÄR` | 28 (15,6 %) |
|
||||||
|
| davon `KONTEXT` | 27 (15,0 %) |
|
||||||
|
| Belege je Anforderung (Median) | 3 |
|
||||||
|
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 63 (96,9 %) |
|
||||||
|
|
||||||
|
### Übernahmewürdigkeit
|
||||||
|
|
||||||
|
| Einstufung | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| übernehmen | 60 | 92,3 % |
|
||||||
|
| workaround | 2 | 3,1 % |
|
||||||
|
| veraltet | 3 | 4,6 % |
|
||||||
|
|
||||||
|
### Status
|
||||||
|
|
||||||
|
| Kategorie | Anzahl | Anteil |
|
||||||
|
|---|---:|---:|
|
||||||
|
| belegt | 65 | 100,0 % |
|
||||||
|
| als `HYPOTHESE` gekennzeichnet | 0 | 0,0 % |
|
||||||
|
| als Workaround vermerkt | 0 | 0,0 % |
|
||||||
|
| Konsolidierungskandidaten | 5 | 7,7 % |
|
||||||
|
| mit ISO-25010-Qualitätsmerkmal | 5 | 7,7 % |
|
||||||
|
|
||||||
|
### 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** (22 risikorelevante Anforderungen, alle gedeckt) |
|
||||||
|
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||||
|
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 65 Anforderungen eingestuft) |
|
||||||
|
| **Traceability** – Verknüpfung zwischen den Ebenen | 65 von 65 mit Tracelinks (100,0 %) |
|
||||||
|
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
|
||||||
+177
@@ -0,0 +1,177 @@
|
|||||||
|
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
|
||||||
|
|
||||||
|
## Metadaten
|
||||||
|
- **Versuch:** V1 Baseline (Prompt-only)
|
||||||
|
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
|
||||||
|
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||||
|
- **Zeitstempel:** 2026-08-26
|
||||||
|
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
|
||||||
|
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||||
|
|
||||||
|
| Änderung | Auslösender Befund |
|
||||||
|
|---|---|
|
||||||
|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
|
||||||
|
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
|
||||||
|
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
|
||||||
|
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
|
||||||
|
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
|
||||||
|
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
|
||||||
|
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
|
||||||
|
|
||||||
|
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
|
||||||
|
|
||||||
|
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||||
|
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||||
|
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Prompt
|
||||||
|
|
||||||
|
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||||
|
|
||||||
|
### Auftrag
|
||||||
|
|
||||||
|
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||||
|
|
||||||
|
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||||
|
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||||
|
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||||
|
|
||||||
|
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||||
|
|
||||||
|
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||||
|
|
||||||
|
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
**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. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
|
||||||
|
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||||
|
|
||||||
|
### Formatvorgabe pro Anforderung
|
||||||
|
|
||||||
|
```
|
||||||
|
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||||
|
Titel: <kurzer Titel>
|
||||||
|
Ebene: <StRS | SyRS | SwRS>
|
||||||
|
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||||
|
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)
|
||||||
|
|
||||||
|
```
|
||||||
|
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)
|
||||||
|
```
|
||||||
|
|
||||||
|
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?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||||
|
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
|
||||||
|
Kommandozeilenbefehlen im Arbeitsverzeichnis.
|
||||||
|
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
|
||||||
|
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||||
|
Werkzeuge zu ersetzen.
|
||||||
|
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||||
|
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||||
|
`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-opus-5\solo\high\02_Lauf_2026-08-26_195958_v7.0.0-e7e6\Ergebnisse\`.
|
||||||
|
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-26T20:31:17.3017181+02:00
|
||||||
+1
@@ -0,0 +1 @@
|
|||||||
|
2026-08-26T20:00:06.7195929+02:00
|
||||||
+876
@@ -0,0 +1,876 @@
|
|||||||
|
# Analysebericht — Reverse Requirements Engineering c-entron ERP-Suite
|
||||||
|
|
||||||
|
**Untersuchungsgegenstand:** gesamte Codebasis unter `C:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||||
|
**Verfahren:** ausschließlich statische Analyse (Lesen, Suchen, Kommandozeile). Keine Ausführung, kein Datenbankzugriff, keine laufende Instanz.
|
||||||
|
**Normbezug:** ISO/IEC/IEEE 29148:2018 (StRS / SyRS / SwRS), ISO/IEC 25010 (Qualitätsmerkmale)
|
||||||
|
**Datum:** 2026-08-26
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 0. Kennzahlen des Untersuchungsgegenstands
|
||||||
|
|
||||||
|
| Kennzahl | Wert | Ermittlung |
|
||||||
|
|---|---|---|
|
||||||
|
| .NET-Projekte (`*.csproj`) | 44 | `find . -name "*.csproj"` |
|
||||||
|
| C#-Quelldateien unter `src/` | 15.554 | `find src -name "*.cs" \| wc -l` |
|
||||||
|
| XAML-Dateien unter `src/` | 1.233 | `find src -name "*.xaml" \| wc -l` |
|
||||||
|
| Razor-Komponenten unter `src/` | 491 | `find src -name "*.razor" \| wc -l` |
|
||||||
|
| Tabellen im DB-Schema-Dump | 1.558 | `grep -c "CREATE TABLE" SSMS_DB_SCHEMA.sql` |
|
||||||
|
| Registrierte UI-Module (WPF) | 84 | `grep -c "ModuleRegistrationItem.For<" ModuleRegistration.cs` |
|
||||||
|
| Rechtekonstanten-Datei | 2.819 Zeilen | `wc -l UserRightsConst.cs` |
|
||||||
|
| Größte Einzelklasse | `ReceiptBL.cs`, 11.441 Zeilen | `wc -l` |
|
||||||
|
|
||||||
|
Technologiestack (belegt über `Directory.Build.props`, `docker/Dockerfile`, `*.csproj`):
|
||||||
|
WPF-Rich-Client (C#/XAML, DevExpress), Blazor-Server-Webanwendung („c-entron Nexus"), ASP.NET-Core-Webservice mit REST-Controllern,
|
||||||
|
NHibernate als O/R-Mapper gegen MS SQL Server, Outlook-Add-In, Linux-Container-Deployment (.NET 10, Alpine).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Modulinventar (Schritt 0)
|
||||||
|
|
||||||
|
Das Inventar wurde **vor** der Formulierung der ersten Anforderung erstellt. Es ist die Bezugsgröße für die
|
||||||
|
Abdeckungstabelle in Abschnitt 3. Grundlage sind (a) die 84 in `ModuleRegistration.cs` registrierten fachlichen
|
||||||
|
UI-Module, (b) die Verzeichnisstruktur von `src/backend/Centron.BL`, `src/backend/Centron.Entities`,
|
||||||
|
`src/apis`, `src/nexus`, `src/webservice`, (c) Betriebs- und Build-Artefakte (`docker/`, `azure/`, `.github/`).
|
||||||
|
|
||||||
|
Spalte „Aufgabe" ist eine Ein-Satz-Beschreibung der fachlichen Aufgabe des Moduls.
|
||||||
|
|
||||||
|
### 1.1 Vertrieb und Beleggeschäft
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-01 | Belegkern (receipt engine) | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs` | Gemeinsame Anlage-, Speicher-, Versions- und Weiterführungslogik für alle sieben Belegarten. |
|
||||||
|
| M-02 | Angebote | `src/backend/Centron.BL/Sales/Receipts/Offers/` | Erstellung, Klassifikation und Nachverfolgung von Kundenangeboten. |
|
||||||
|
| M-03 | Aufträge | `src/backend/Centron.BL/Sales/Receipts/Orders/` | Auftragserfassung und -abwicklung inklusive Teilkommissionierung. |
|
||||||
|
| M-04 | Lieferscheine | `src/backend/Centron.BL/Sales/Receipts/DeliveryLists/` | Warenausgangsbelege und Versandabwicklung. |
|
||||||
|
| M-05 | Rechnungen | `src/backend/Centron.BL/Sales/Receipts/Invoices/` | Fakturierung gegenüber Kunden inklusive Mahnstufenführung. |
|
||||||
|
| M-06 | Gutschriften | `src/backend/Centron.BL/Sales/Receipts/CreditVouchers/` | Kundengutschriften als wertmäßige Korrektur von Rechnungen. |
|
||||||
|
| M-07 | Abholscheine | `src/backend/Centron.BL/Sales/Receipts/PickUps/`, `PickupLists/` | Abholbelege für Barverkauf und Selbstabholung. |
|
||||||
|
| M-08 | Belegpositionen | `src/backend/Centron.BL/Sales/Receipts/ReceiptItemBL.cs` | Positionsverwaltung: Preise, Rabatte, Fracht, Saldopositionen, Anzeigenummerierung. |
|
||||||
|
| M-09 | Belegvorlagen | `src/backend/Centron.BL/Sales/Receipts/ReceiptTemplateBL.cs` | Wiederverwendbare Belegvorlagen in Ordnerstruktur. |
|
||||||
|
| M-10 | Belegprotokoll / Progression | `src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs`, `ReceiptProgressionBL.cs` | Änderungsprotokoll und Belegkette (Angebot → Auftrag → Lieferschein → Rechnung). |
|
||||||
|
| M-11 | Belegkonditionen | `src/centron/Centron.WPF.UI/Modules/Administration/ReceiptConditions/` | Pflege von Zahlungs- und Lieferkonditionen als Stammdaten. |
|
||||||
|
| M-12 | Web-Beleg (WebReceipt) | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs` (Region `WebReceipt`) | Freigabe/Ablehnung von Belegen durch den Kunden über einen Token-Link. |
|
||||||
|
| M-13 | Belegsignatur | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs` (Region `Signing`), `src/nexus/CentronNexus/DocumentSigning/` | Elektronische Unterzeichnung freigegebener Dokumente. |
|
||||||
|
| M-14 | Provisionsabrechnung | `src/backend/Centron.BL/Sales/Receipts/ReceiptProvision*BL.cs` | Provisionsschemata, Mitarbeiterziele und Provisionsauswertung. |
|
||||||
|
| M-15 | Sonderpreise / Produktmatrix | `src/backend/Centron.BL/ProductMatrix/`, `Accounts/SpecialPrices/` | Kundenindividuelle Preise und Preismatrizen. |
|
||||||
|
| M-16 | Frachtartikel-Steuerung | `src/backend/Centron.BL/Sales/Receipts/FreightArticleSettingBL.cs` | Automatisches Einsteuern von Fracht- und Versicherungspositionen. |
|
||||||
|
|
||||||
|
### 1.2 Verträge und wiederkehrende Abrechnung
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-17 | Verträge (Kern) | `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs` | Serviceverträge mit Abrechnungsintervall, Kontingent und Laufzeit. |
|
||||||
|
| M-18 | Automatische Vertragsabrechnung | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/` | Turnusmäßige Erzeugung von Rechnungen aus Verträgen. |
|
||||||
|
| M-19 | Klickabrechnung (MPS) | `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/` | Abrechnung nach Zählerständen von Druck-/Kopiergeräten. |
|
||||||
|
| M-20 | Pauschalabrechnung | `src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/` | Pauschale (flat-rate) Abrechnung von Projekten. |
|
||||||
|
| M-21 | Vereinfachte Ticketabrechnung | `src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs` | Abrechnung erfasster Ticketzeiten über Aufträge/Rechnungen. |
|
||||||
|
| M-22 | Vertragsarten | `src/centron/Centron.WPF.UI/Modules/Finances/Contracts/ContractSettings/ContractTypes/` | Katalog der Vertragsarten als Stammdaten. |
|
||||||
|
| M-23 | Vertragsauswertung | `src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluation2/` | Wirtschaftliche Auswertung von Verträgen. |
|
||||||
|
| M-24 | Vertrags-Datenimport | `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractExternalArticleImport*.cs` | Import externer Artikel-/Mengendaten in Verträge (dynamisch und statisch). |
|
||||||
|
| M-25 | Leasing/Service | `src/backend/Centron.BL/Sales/Receipts/LeasingAndService/` | Leasing- und Servicekonditionen an Belegen. |
|
||||||
|
|
||||||
|
### 1.3 Kunden, Lieferanten, CRM
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-26 | Adressstamm / Accounts | `src/backend/Centron.BL/Accounts/AccountBL.cs` | Zentraler Geschäftspartnerstamm (Kunde, Lieferant, Interessent). |
|
||||||
|
| M-27 | Alt-Kundenstamm | `src/backend/Centron.BL/Sales/Customers/` | Klassische Kundenstammverwaltung vor der Account-Umstellung. |
|
||||||
|
| M-28 | Lieferantenstamm | `src/backend/Centron.BL/BusinessPartner/`, `Purchasing/Suppliers/` | Lieferantendaten und Lieferantensuche. |
|
||||||
|
| M-29 | Adressen und Ansprechpartner | `src/backend/Centron.BL/Accounts/AccountAddress*BL.cs` | Mehrfachadressen und Kontaktpersonen je Geschäftspartner. |
|
||||||
|
| M-30 | CRM-Aktivitäten | `src/backend/Centron.BL/Accounts/Activities/` | Protokollierung von Kundenkontakten und Vorgängen. |
|
||||||
|
| M-31 | CRM-Projekte | `src/centron/Centron.WPF.UI/Modules/Finances/Projects/`, `Centron.BL/Projects/ProjectBL.cs` | Vertriebsprojekte über mehrere Belege hinweg. |
|
||||||
|
| M-32 | Kampagnen und Mailings | `src/backend/Centron.BL/Accounts/Campaigns/`, `Mailings/` | Serienbrief- und Kampagnensteuerung. |
|
||||||
|
| M-33 | Audit / Umfragen | `src/backend/Centron.BL/Accounts/Survey/` | Kundenzufriedenheitsbefragungen, u. a. nach Ticketabschluss. |
|
||||||
|
| M-34 | Lieferantenverträge | `src/backend/Centron.BL/Accounts/AccountContracts/` | Verträge auf der Beschaffungsseite. |
|
||||||
|
| M-35 | Kundenhotline / Zugangsdaten | `src/backend/Centron.BL/Accounts/HotlineArea/`, `HotlineBL.cs` | Kundenspezifische Hotline- und Zugangsinformationen. |
|
||||||
|
| M-36 | Geschäftsbereiche / Interessen | `src/backend/Centron.BL/CustomerArea/BusinessLineBL.cs`, `InterestBL.cs` | Segmentierungsmerkmale für Kunden. |
|
||||||
|
|
||||||
|
### 1.4 Service, Helpdesk, Zeiterfassung
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-37 | Helpdesk (Ticketkern) | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs` | Anlage, Bearbeitung und Sichtbarkeitssteuerung von Servicetickets. |
|
||||||
|
| M-38 | Ticketabschluss | `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs` | Abschluss von Tickets inklusive Benachrichtigung und Umfrage. |
|
||||||
|
| M-39 | Ticketkategorien/-typen/-status | `src/backend/Centron.BL/Sales/Support/HelpdeskCategoryBL.cs`, `HelpdeskTypeBL.cs`, `HelpdeskStatusBL.cs` | Klassifikationsschema der Tickets. |
|
||||||
|
| M-40 | Ticketprioritäten und Eskalation | `src/backend/Centron.BL/Sales/Support/HelpdeskPrioritiesBL.cs`, `Escalation/` | Priorisierung und Eskalationsstufen. |
|
||||||
|
| M-41 | Ticket-Zeiterfassung (Timer) | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `HelpdeskTimeRecordingBL.cs` | Erfassung von Arbeitszeiten je Ticket, inkl. Stoppuhr. |
|
||||||
|
| M-42 | Ticket-Unterschrift | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs` | Kundenunterschrift auf einem Zeiteintrag. |
|
||||||
|
| M-43 | Stundensatz-Aufschläge | `src/backend/Centron.BL/Sales/HourlySurchargeRatesBL/` | Zeitabhängige Zuschläge (Nacht, Wochenende) auf Stundensätze. |
|
||||||
|
| M-44 | Ticketvorlagen / Muster | `src/backend/Centron.BL/Sales/Support/HelpdeskPatternBL.cs`, `HelpdeskCreationTemplateBL.cs` | Automatische Ticketerzeugung aus Vorlagen. |
|
||||||
|
| M-45 | Ticketprozesse | `src/backend/Centron.BL/Sales/Support/TicketProcess/` | Mehrstufige Prozessvorlagen für Tickets. |
|
||||||
|
| M-46 | Ticketprojekte | `src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs` | Bündelung von Tickets zu Projekten. |
|
||||||
|
| M-47 | Checklisten | `src/backend/Centron.BL/CheckListArea/` | Abarbeitbare Prüflisten an Tickets und Objekten. |
|
||||||
|
| M-48 | Taskmanagement | `src/backend/Centron.BL/TaskManager/`, `src/nexus/CentronNexus/Management/TaskManagement/` | Aufgabenverwaltung quer zu Tickets. |
|
||||||
|
| M-49 | RMA / Werkstatt | `src/backend/Centron.BL/CustomerArea/RmaBL.cs` | Retouren-, Reparatur- und Tauschabwicklung mit Seriennummern. |
|
||||||
|
| M-50 | Mail-Scanner | `src/backend/Centron.BL/MailScanner/MailScannerBL.cs` | Regelbasiertes Erzeugen/Zuordnen von Tickets aus Postfächern. |
|
||||||
|
| M-51 | Externer Helpdesk | `src/backend/Centron.BL/ExternalHelpdesk/` | Anbindung fremder Ticketsysteme. |
|
||||||
|
| M-52 | Erwartete Events | `src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs` | Überwachung erwarteter, wiederkehrender Ereignisse. |
|
||||||
|
|
||||||
|
### 1.5 Warenwirtschaft und Logistik
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-53 | Artikelstamm | `src/backend/Centron.BL/Warehousing/ArticleBL.cs` | Zentrale Artikelverwaltung inklusive Sonderartikel-Rollen. |
|
||||||
|
| M-54 | Artikelimport | `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs` | Massenimport von Artikeldaten. |
|
||||||
|
| M-55 | Warengruppen | `src/backend/Centron.BL/Warehousing/InventoryManagement/MaterialGroupBL.cs` | Hierarchische Warengruppen mit Erlöskontozuordnung. |
|
||||||
|
| M-56 | Lager und Lagerplätze | `src/backend/Centron.BL/Warehousing/StockManagement/` | Lagerorte, Lagerplätze und Bestandsführung. |
|
||||||
|
| M-57 | Seriennummern und Barcodes | `src/backend/Centron.BL/Warehousing/BarcodeBL.cs`, `BarcodeHistoryBL.cs` | Einzelstückverfolgung über Barcode-/Seriennummernzustände. |
|
||||||
|
| M-58 | Inventur | `src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryNewBL.cs` | Zähl- und Abschlussprozess der Inventur. |
|
||||||
|
| M-59 | Kommissionierung | `src/backend/Centron.BL/Warehousing/Commissions/` | Auftragsbezogene Kommissionierung, auch als Teilkommissionierung. |
|
||||||
|
| M-60 | Artikeleinheiten und Staffelpreise | `src/backend/Centron.BL/Warehousing/ArticleUnitBL.cs`, `ArticleVolumePricesBL.cs` | Mengeneinheiten und mengenabhängige Preise. |
|
||||||
|
| M-61 | Stücklisten / Produktfamilien | `src/backend/Centron.BL/Warehousing/StockManagement/PartListArticleBL.cs`, `ArticleManagement/ProductFamilyBL.cs` | Zusammengesetzte Artikel und Produktfamilien. |
|
||||||
|
| M-62 | Versandarten und Versanddienstleister | `src/backend/Centron.BL/Logistics/`, `src/apis/Centron.Api.Gls/`, `Centron.Api.Shipcloud/` | Versandsteuerung und Labelerzeugung. |
|
||||||
|
| M-63 | Aktionspreise | `src/backend/Centron.BL/Warehousing/ActionPriceBL.cs` | Zeitlich befristete Aktionspreise. |
|
||||||
|
|
||||||
|
### 1.6 Einkauf
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-64 | Lieferantenbelege | `src/backend/Centron.BL/Sales/Receipts/Supplier*/` | Anfragen, Bestellungen, Wareneingänge, Lieferantenrechnungen und -gutschriften. |
|
||||||
|
| M-65 | Bestellvorschlagsliste | `src/backend/Centron.BL/Purchasing/OrderSuggestionList/` | Ermittlung von Bestellvorschlägen aus Bedarf und Bestand. |
|
||||||
|
| M-66 | EDI-Beschaffung | `src/backend/Centron.BL/EDI/` | Elektronischer Datenaustausch mit Distributoren (ALSO, Alltron, Komsa, EGIS, Concerto). |
|
||||||
|
| M-67 | ZUGFeRD / XRechnung | `src/backend/Centron.BL/EDI/Zugferd/`, `docs/guides/development/xrechnung.md` | Elektronische Rechnungsformate im Ein- und Ausgang. |
|
||||||
|
| M-68 | ebInterface (AT) | `src/apis/Centron.Api.EbInterface/` | Österreichisches E-Rechnungsformat. |
|
||||||
|
| M-69 | Distributor-Produktdaten | `src/apis/Centron.APIs.ITscopeDataAccess/`, `IcecatDataAccess/`, `CopDataAccess/`, `EgisDataAccess/` | Bezug von Produktstamm-, Preis- und Verfügbarkeitsdaten. |
|
||||||
|
| M-70 | Bestellung pro Filiale | `src/backend/Centron.BL/Purchasing/SupplierOrderPerBranchBL.cs` | Filialbezogene Aufteilung von Bestellungen. |
|
||||||
|
|
||||||
|
### 1.7 Finanzen und Buchhaltung
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-71 | Buchhaltungsexport/-import | `src/backend/Centron.BL/DataExchange/BookKeeping/` | Übergabe von Belegdaten an die Finanzbuchhaltung (DATEV). |
|
||||||
|
| M-72 | Mahnwesen | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/` | Mahnläufe, Mahnstufen und Mahnbelege. |
|
||||||
|
| M-73 | Offene Posten (OPOS) | `src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/` | Offene-Posten-Liste und Ausgleich. |
|
||||||
|
| M-74 | Zahlungseingang | `src/backend/Centron.BL/Finances/IncomingPayments/` | Erfassung und Protokollierung von Zahlungseingängen. |
|
||||||
|
| M-75 | SEPA-Mandate | `src/centron/Centron.WPF.UI/Modules/Administration/SepaContract/` | Verwaltung von SEPA-Lastschriftmandaten. |
|
||||||
|
| M-76 | Online-Banking | `src/backend/Centron.BL/Finances/OnlineBanking/`, `src/apis/Centron.APIs.FinAPI/` | Kontoumsatzabruf und Zahlungsverkehr über finAPI. |
|
||||||
|
| M-77 | Bankverbindungen | `src/backend/Centron.BL/Accounting/BankAccountBL.cs` | Bankstammdaten der Geschäftspartner. |
|
||||||
|
| M-78 | Kontenrahmen | `src/centron/Centron.WPF.UI/Modules/Warehousing/AccountSystems/` | Erlös- und Aufwandskonten je Mandant und Filiale. |
|
||||||
|
| M-79 | Mehrwertsteuer | `src/backend/Centron.BL/Warehousing/TaxBL.cs` | Steuersätze, Steuersatzketten und Steuersatzwechsel. |
|
||||||
|
| M-80 | Kostenstellen/Kostenträger | `src/backend/Centron.BL/Warehousing/CostCenterBL.cs`, `CostObjectBL.cs` | Kostenrechnerische Zuordnung. |
|
||||||
|
| M-81 | Kalkulation pro Filiale | `src/centron/Centron.WPF.UI/Modules/DataExchange/SupplierOrderPerBranch/` | Filialbezogene Kalkulation. |
|
||||||
|
| M-82 | Produkt-Lifecycle (PLM) | `src/backend/Centron.BL/Finances/ProductLifecycleBL.cs` | Lebenszyklus von Lizenz-/Produktbeständen beim Kunden. |
|
||||||
|
| M-83 | Gutschein-/Voucher-Verwaltung | `src/backend/Centron.BL/VoucherManagement/` | Ausgabe und Einlösung von Gutscheinen. |
|
||||||
|
|
||||||
|
### 1.8 Geräte, Assets, Monitoring
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-84 | Kunden-Assets | `src/backend/Centron.BL/Sales/CustomerAssets/AssetBL.cs`, `CustomerAssetBL.cs` | Beim Kunden installierte Wirtschaftsgüter. |
|
||||||
|
| M-85 | Stammblätter | `src/backend/Centron.BL/Sales/Receipts/…/MasterDataLists`, Tabelle `Stammdat` | Geräteblätter mit Seriennummer, Zählerstand und Rechnungsbezug. |
|
||||||
|
| M-86 | Account-Geräte | `src/backend/Centron.BL/Devices/AccountDeviceBL.cs`, Tabelle `AccountDevices` | Geräteverzeichnis am Account, verknüpfbar mit Tickets. |
|
||||||
|
| M-87 | Asset-Management / DocuBoard | `src/backend/Centron.BL/DocuBoard/`, Tabellen `AssetManagement*` | Inventarisierte IT-Systeme, SNMP-Checks und Monitoringergebnisse. |
|
||||||
|
| M-88 | RMM-Anbindung | `src/backend/Centron.BL/DataExchange/Rmm/`, `Controllers/v1/Integrations/RmmController.cs` | Anbindung von Remote-Monitoring-Systemen. |
|
||||||
|
| M-89 | docuFORM-Anbindung | `Centron.Api.docuFORM/`, `src/backend/Centron.BL/DataExchange/DocuForm/` | Auslesen von Druckerzählerständen. |
|
||||||
|
| M-90 | IT-Planner | `src/backend/Centron.BL/ItPlanner/` | Kategorisierung virtueller Objekte für Checklisten. |
|
||||||
|
|
||||||
|
### 1.9 Administration, Sicherheit, Betrieb
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-91 | Anmeldung und Authentifizierung | `src/backend/Centron.BL/Administration/Logins/Auth/` | Basic-, Active-Directory- und OpenID-Connect-Anmeldung. |
|
||||||
|
| M-92 | Zwei-Faktor-Authentifizierung | `src/backend/Centron.BL/Administration/Logins/TwoFactor/` | Zweiter Faktor per E-Mail oder RADIUS. |
|
||||||
|
| M-93 | Sitzungs-/Ticketverwaltung | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs` | Ausgabe und Ablauf von Sitzungstickets. |
|
||||||
|
| M-94 | Rechteverwaltung | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` | Benutzergruppen und rund 800 Einzelrechte. |
|
||||||
|
| M-95 | Web-Benutzerkonten | `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs` | Kundenzugänge für das Webportal mit eigenem Rechtesystem. |
|
||||||
|
| M-96 | API-Zugriffstoken | `src/backend/Centron.BL/Administration/AccessTokens/` | Persönliche und administrative API-Token. |
|
||||||
|
| M-97 | Lizenzierung | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs` | Freischaltung von Anwendungen und Einzelfunktionen über Lizenz-GUIDs. |
|
||||||
|
| M-98 | Mandanten und Filialen | `src/backend/Centron.BL/Administration/Company/` | Mandanten-, Filial- und Nummernkreisstruktur. |
|
||||||
|
| M-99 | Nummernkreise | `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs` | Vergabe fortlaufender Belegnummern je Nummernart. |
|
||||||
|
| M-100 | Mitarbeiterverwaltung | `src/backend/Centron.BL/EmployeeArea/` | Mitarbeiter, Abteilungen, Skills, Urlaub, Mitarbeiterartikel. |
|
||||||
|
| M-101 | Anwendungseinstellungen | `src/backend/Centron.BL/Administration/Settings/` | Zentrale Konfigurationswerte (`ApplicationSettings`). |
|
||||||
|
| M-102 | Konfigurationsdatenbank | `src/backend/Centron.BL/Administration/CentronConfigDb/` | Übergreifende Konfiguration inkl. Hotline-Masterkey. |
|
||||||
|
| M-103 | DB-Skript-/Migrationsengine | `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs` | Versionierte Datenbankmigration beim Start. |
|
||||||
|
| M-104 | SQL-Manager | `src/backend/Centron.BL/Administration/SQLManagement/` | Administrative SQL-Ausführung aus der Anwendung. |
|
||||||
|
| M-105 | Datenschutz (DSGVO) | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` | Auskunft, Löschung und Datenbankbereinigung. |
|
||||||
|
| M-106 | Passwort-Manager | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs` | Verschlüsselte Ablage von Kundenzugangsdaten. |
|
||||||
|
| M-107 | Passwortverwaltung (Altmodul) | `src/backend/Centron.BL/PasswordManagementArea/` | Vorgängermodul der Zugangsdatenverwaltung. |
|
||||||
|
| M-108 | Änderungshistorie | `src/backend/Centron.BL/ChangeTracking/History/` | Feldbezogene Änderungsverfolgung. |
|
||||||
|
| M-109 | Massenupdate | `src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs` | Feldänderungen über viele Datensätze hinweg. |
|
||||||
|
| M-110 | Customizing / Custom Properties | `src/backend/Centron.BL/Customizations/`, `Modules/` | Kundenindividuelle Zusatzfelder und Tabellen. |
|
||||||
|
| M-111 | Telemetrie | `src/backend/Centron.BL/Telemetry/TelemetryBL.cs` | Nutzungszählung von API- und KI-Werkzeugen. |
|
||||||
|
| M-112 | Protokollierung / LogViewer | `src/centron/Centron.WPF.UI/nlog.config`, `Modules/Administration/LogViewer/` | Anwendungsprotokollierung und Protokollansicht. |
|
||||||
|
| M-113 | Deployment und Container | `docker/`, `deployment/`, `azure/` | Auslieferung als Windows-Installer und Linux-Container. |
|
||||||
|
| M-114 | Build- und Testpipeline | `.github/workflows/`, `azure/*.yml`, `tests/` | Automatisierte Übersetzung, Signierung und Prüfung. |
|
||||||
|
| M-115 | Datenqualitätsdienst | `src/backend/Centron.BL/Services/DataQuality/`, `docs/Background Service/DataQualityService.md` | Periodische Konsistenzprüfungen im Hintergrund. |
|
||||||
|
|
||||||
|
### 1.10 Ausgabe, Kommunikation, Suche
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-116 | Report-Engine | `src/backend/Centron.BL/ReportEngine/` | Formulargenerierung (FastReport) und PDF-Export. |
|
||||||
|
| M-117 | Reportverwaltung | `src/centron/Centron.WPF.UI/Modules/Reports/ReportManagement/` | Verwaltung der Formularvorlagen und Reportgruppen. |
|
||||||
|
| M-118 | Reportserver | `src/centron/Centron.WPF.UI/Modules/Administration/ReportServer/` | Zeitgesteuerter Reportversand. |
|
||||||
|
| M-119 | PDF-Signatur | `src/backend/Centron.BL/Security/PdfSigningBL.cs` | Digitale Signatur erzeugter PDF-Dokumente. |
|
||||||
|
| M-120 | Mailversand und Vorlagen | `src/backend/Centron.BL/Mail/` | SMTP/Exchange-Versand, Mailvorlagen, Variablenersetzung. |
|
||||||
|
| M-121 | Textbausteine | `src/backend/Centron.BL/TextModuleArea/` | Wiederverwendbare Textblöcke in Belegen und Mails. |
|
||||||
|
| M-122 | Kalender und Terminplanung | `src/backend/Centron.BL/Calendar/CalendarBL.cs`, `Mail/Exchange/` | Termine und Exchange-Synchronisation. |
|
||||||
|
| M-123 | Terminanfragen | `src/backend/Centron.BL/AppointmentRequests/` | Terminvorschläge an Kunden. |
|
||||||
|
| M-124 | Telefonie / TAPI | `src/backend/Centron.BL/Tapi/PhoneCallBL.cs`, `docs/reference/architecture/tapi.md` | Anrufprotokollierung und Rufnummernauflösung. |
|
||||||
|
| M-125 | Volltext-Indexsuche | `src/backend/Centron.BL/IndexSearch/` | Objektübergreifende Volltextsuche mit eigenem Index. |
|
||||||
|
| M-126 | Dokumentenverwaltung | `src/backend/Centron.BL/Administration/FileManagement/` | Verzeichnisstruktur und Dokumentenablage je Objekt. |
|
||||||
|
| M-127 | Benachrichtigungen | `src/backend/Centron.BL/Notifications/`, `NexusNotifications/` | Push- und In-App-Benachrichtigungen. |
|
||||||
|
| M-128 | Chats | `src/backend/Centron.BL/Chats/ChatBL.cs` | Interne Kurznachrichten. |
|
||||||
|
| M-129 | Tags | `src/backend/Centron.BL/Tags/TagsBL.cs` | Freie Verschlagwortung von Objekten. |
|
||||||
|
| M-130 | Web-Links / Kurz-URLs | `src/backend/Centron.BL/Urls/`, `WebLinks/` | Signierte Kurzlinks mit hinterlegter Aktion. |
|
||||||
|
| M-131 | Dokumentationsbereich | `src/backend/Centron.BL/DocumentationArea/` | Strukturierte Kundendokumentation. |
|
||||||
|
| M-132 | Social Media | `src/backend/Centron.BL/SocialMedia/` | Anbindung sozialer Netzwerke. |
|
||||||
|
| M-133 | Videoportal | `src/backend/Centron.BL/VideoPortal/` | Zuordnung von Schulungsvideos. |
|
||||||
|
|
||||||
|
### 1.11 Web-Oberflächen (c-entron Nexus) und Clients
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-134 | Nexus ServiceBoard | `src/nexus/CentronNexus/ServiceBoard/` | Webbasierte Ticketbearbeitung inkl. Kanban und Planung. |
|
||||||
|
| M-135 | Nexus Kundenportal / WebCart | `src/nexus/CentronNexus/WebCart/` | Kundenportal mit Shop, Belegen, Tickets und Formularen. |
|
||||||
|
| M-136 | Nexus WebOffer | `src/nexus/CentronNexus/WebOffer/` | Belegansicht und -freigabe durch den Kunden. |
|
||||||
|
| M-137 | Nexus Dokumentensignatur | `src/nexus/CentronNexus/DocumentSigning/`, `Office/` | Unterzeichnung und geteilte Dokumente. |
|
||||||
|
| M-138 | Nexus Management | `src/nexus/CentronNexus/Management/` | Verwaltung von Tasks, Ticketmustern und Web-Konten im Web. |
|
||||||
|
| M-139 | Nexus Einstellungen/Branding | `src/nexus/CentronNexus/Settings/` | Mandantenspezifisches Erscheinungsbild und Konfiguration. |
|
||||||
|
| M-140 | Outlook-Add-In | `src/nexus/CentronNexus.OutlookAddIn/` | Zugriff auf Kunden, Belege und Tickets aus Outlook. |
|
||||||
|
| M-141 | Self-Care-Formulare | `src/backend/Centron.BL/SelfCare/`, `Controllers/v1/SelfCare/` | Vom Kunden ausfüllbare Formulare zur Ticketerzeugung. |
|
||||||
|
| M-142 | WPF-Rich-Client | `src/centron/Centron.WPF.UI/` | Hauptbedienoberfläche mit Modulregistrierung und Ribbon. |
|
||||||
|
| M-143 | Gemeinsame Steuerelemente | `src/shared/Centron.Controls/`, `Centron.Core/` | Wiederverwendete UI-Bausteine und Kernbibliothek. |
|
||||||
|
| M-144 | Mobile-Anbindung | `src/backend/Centron.BL/Mobile/MobileBL.cs` | Datenversorgung mobiler Clients. |
|
||||||
|
|
||||||
|
### 1.12 Schnittstellen, Auswertung, Sonstiges
|
||||||
|
|
||||||
|
| ID | Modul / Komponente | Pfad | Fachliche Aufgabe |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M-145 | Webservice-Host und REST-API | `src/webservice/`, `src/webservice/Centron.Controllers/` | Versionierte REST-Schnittstelle und Hosting als Dienst/Konsole. |
|
||||||
|
| M-146 | Verbindungsverwaltung | `src/webservice/c-entron.misc.ConnectionManager/`, `Centron.BL/Administration/Connections/` | Verwaltung der Datenbank- und Webserviceverbindungen. |
|
||||||
|
| M-147 | Statistiken und Auswertungen | `src/backend/Centron.BL/Statistics/` | Umsatz-, Ticket-, Vertrags- und MSP-Statistiken. |
|
||||||
|
| M-148 | MSP-Collector | `src/centron/Centron.WPF.UI/Modules/Statistics/MspCollectors/` | Einsammeln von Lizenz-/Nutzungsdaten für MSP-Abrechnung. |
|
||||||
|
| M-149 | Management-Info und Dashboard | `src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo/`, `MyCentron/Dashboard/` | Verdichtete Kennzahlen für Führungskräfte. |
|
||||||
|
| M-150 | Mein Tag (MyDay) | `src/backend/Centron.BL/MyDay/` | Persönliche Tagesplanung und Zeitübersicht. |
|
||||||
|
| M-151 | Todo-Liste | `src/backend/Centron.BL/ToDoArea/ToDoBL.cs` | Persönliche und objektbezogene Aufgaben. |
|
||||||
|
| M-152 | KI-Assistent | `src/backend/Centron.BL/ArtificialIntelligence/` | Chat, Textbewertung und Ticketkategorisierung über LLM-APIs. |
|
||||||
|
| M-153 | Externe Werkzeuge / Fernwartung | `src/backend/Centron.BL/ExternalToolsBL/`, `MyDay/Supremo.cs` | Start externer Programme und Fernwartungssitzungen. |
|
||||||
|
| M-154 | TradePool | `src/backend/Centron.BL/TradePool/` | Handelsplattform-Anbindung. |
|
||||||
|
| M-155 | RiverSuite/RiverDivo-Anbindung | `src/backend/Centron.BL/RiverDivo/` | Anbindung der RiverSuite-Produktlinie. |
|
||||||
|
| M-156 | CPra-Konnektor | `src/backend/Centron.BL/CPra/` | Anbindung des Fremdsystems CPra. |
|
||||||
|
| M-157 | Telekom Dive | `src/backend/Centron.BL/DataExchange/TelekomDive/` | Anbindung des Telekom-Dive-Portals. |
|
||||||
|
| M-158 | GFK-Export | `src/backend/Centron.BL/DataExchange/GfkExport/` | Marktforschungsdatenexport. |
|
||||||
|
| M-159 | Objekt-Externreferenzen | `src/backend/Centron.BL/ObjectExternalReferences/` | Verknüpfung interner Objekte mit Fremdsystem-IDs. |
|
||||||
|
| M-160 | Zahlungsverkehrsdateien | `src/backend/Centron.BL/DataExchange/PaymentTransactions/` | Erzeugung von Zahlungsverkehrsdateien. |
|
||||||
|
| M-161 | Produktion | `src/backend/Centron.BL/Production/` | Produktionsaufträge und Maschinenverwaltung. |
|
||||||
|
| M-162 | Datenimport (generisch) | `src/backend/Centron.BL/DataExchange/Import/`, `Entities/Import/` | Generische Importwege für Fremddaten. |
|
||||||
|
| M-163 | Gateway | `src/backend/Centron.BL/Gateway/`, `src/backend/Centron.Gateway/` | Vermittlungsschicht für externe Aufrufe. |
|
||||||
|
| M-164 | Länderverwaltung | `src/backend/Centron.BL/CountryArea/` | Länder, Bundesländer und länderabhängige Steuersätze. |
|
||||||
|
| M-165 | Themes und Oberflächenanpassung | `src/centron/Centron.WPF.UI/Style/`, `Controllers/v1/Administration/ThemesController.cs` | Farbschemata und Layoutanpassungen. |
|
||||||
|
|
||||||
|
**Inventarumfang: 165 Module/Komponenten.**
|
||||||
|
|
||||||
|
Die Abdeckungstabelle in Abschnitt 3 führt jede dieser 165 Zeilen mit Einstufung und Anforderungszahl.
|
||||||
|
Abschnitt 4 enthält den Konsistenzcheck, Abschnitt 5 die Selbstbewertung.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Vorgehen im Lauf
|
||||||
|
|
||||||
|
| Schritt | Umsetzung |
|
||||||
|
|---|---|
|
||||||
|
| **0 — Modulinventar** | Vor der ersten Anforderung erstellt (Abschnitt 1), 165 Einträge. Grundlage: `ModuleRegistration.cs` (84 registrierte UI-Module), Verzeichnisstruktur von `Centron.BL`, `Centron.Entities`, `src/apis`, `src/nexus`, `src/webservice`, Betriebsartefakte. |
|
||||||
|
| **0b — Mindestabdeckung** | Jedes Inventarmodul hat mindestens eine Anforderung (Abschnitt 3). Kein Modul steht auf `nicht analysiert`. |
|
||||||
|
| **0c — Vertiefung nach Risiko** | Vertieft wurden zuerst Berechtigungen (`AppRightsBL`, `UserRightsConst`, die vier Prüfmethoden in `ReceiptBL`), Anmeldung und Kennwortbehandlung (`Authenticator`, `BasicAuthenticator`, `SHA1Decoder`, `AESCryptoLogic`, `AccessTokenBL`, `WebAccountBL`), Abrechnung und Fakturierung (`ReceiptBL.SaveReceipt`/`ForwardReceipt`, `InvoiceSpecificLogic`, `DunningRunBL`, `AutomaticFacturaBL`, `TimerBillingBL`, `TaxBL`, `NumberGroupBL`) sowie Datenschutz (`DataSecurityBL`). |
|
||||||
|
| **2 — Artefakterhebung** | Quellcode, DB-Schema-Dump (1.558 Tabellen), Rechtekonstanten, Modulregistrierung, Ressourcendateien, `docs/` (54 Dateien), `CentronRights.md`, `README.md`, `docker/`, `azure/`, `.github/workflows/`. **Nicht erhoben:** Commit-Historie und Ticketreferenzen — das Arbeitsverzeichnis enthält kein Git-Repository der analysierten Codebasis, sondern nur den Dateibestand. |
|
||||||
|
| **3 — Technische Analyse** | Module, Abhängigkeiten, Statusmaschinen (`BarcodeState`, `DunningLevel`, `RmaArticleState`, Zeiterfassung), Validierungslogik (`SaveReceipt`, `HelpdeskBL.DoValidateMandatoryFields`), Berechtigungsprüfungen. |
|
||||||
|
| **4 — Semantische Interpretation** | Trennung in `Fakt` (belegte Beobachtung) und `Aussage` (fachliche Soll-Aussage) in jedem Anforderungsblock. |
|
||||||
|
| **5 — Formalisierung** | 363 Anforderungen im vorgegebenen Blockformat mit Vorbedingung, Ergebnis und Prüfidee. |
|
||||||
|
| **6 — Traceability-Anreicherung** | 740 Artefaktbelege; `Traceability.md` mit 319 Zeilen, maschinell aus den `Tracelinks`- und `Belege`-Feldern erzeugt. |
|
||||||
|
|
||||||
|
**Nicht durchgeführt:** Ausführung des Systems, Datenbankzugriff, Debugging, Einsatz zusätzlicher
|
||||||
|
Analysewerkzeuge. Alle Aussagen stammen aus dem Lesen und Durchsuchen der Dateien.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Abdeckungstabelle
|
||||||
|
|
||||||
|
Einstufung: `tief` ≥ 8 Anforderungen, `mittel` 4–7, `flach` 1–3, `nicht analysiert` 0.
|
||||||
|
|
||||||
|
Die Zuordnung Modul → Anforderung wurde maschinell erzeugt, indem die Belege und der Text jeder
|
||||||
|
Anforderung gegen die Pfad- und Bezeichnerschlüssel des jeweiligen Moduls geprüft wurden. Bei
|
||||||
|
fünfzehn Modulen überzeichnet diese Suche das Ergebnis, weil kurze Schlüssel auch fremde Begriffe
|
||||||
|
treffen (`Kunden` in „Kundenstamm", `Mandat` in „Mandant", `Voucher` in „CreditVoucher", `EDI` in
|
||||||
|
`EDIT_INVOICE`, `Employee`, `Signature`, `Exchange`, `Monitoring`). Für diese Module ist der nach
|
||||||
|
Durchsicht verbleibende Wert eingetragen und der Rohwert in der letzten Spalte vermerkt.
|
||||||
|
|
||||||
|
| Modul-ID | Modul | Einstufung | Anzahl Anforderungen | Anforderungs-IDs |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| M-01 | Belegkern | tief | 75 | StRS-003, StRS-004, StRS-005, StRS-012, StRS-013, StRS-023, StRS-028, StRS-030, StRS-032, StRS-034, StRS-038, StRS-040, StRS-045, StRS-051, StRS-058, SwRS-003, SwRS-009, SwRS-010, … (+57) |
|
||||||
|
| M-02 | Angebote | tief | 12 | StRS-003, StRS-004, SwRS-005, SwRS-012, SwRS-023, SwRS-024, SwRS-191, SyRS-012, SyRS-014, SyRS-015, SyRS-022, SyRS-023 |
|
||||||
|
| M-03 | Aufträge | mittel | 6 | StRS-030, StRS-040, SwRS-005, SwRS-083, SyRS-022, SyRS-113 |
|
||||||
|
| M-04 | Lieferscheine | mittel | 6 | StRS-009, StRS-024, SwRS-005, SwRS-070, SyRS-022, SyRS-032 |
|
||||||
|
| M-05 | Rechnungen | tief | 21 | StRS-005, StRS-028, StRS-029, StRS-040, SwRS-005, SwRS-013, SwRS-014, SwRS-021, SwRS-022, SwRS-082, SwRS-083, SwRS-090, SyRS-013, SyRS-014, SyRS-020, SyRS-021, SyRS-022, SyRS-082, SyRS-083, SyRS-113, SyRS-183 |
|
||||||
|
| M-06 | Gutschriften | mittel | 7 | StRS-006, StRS-024, StRS-040, SwRS-005, SwRS-027, SwRS-070, SyRS-113 |
|
||||||
|
| M-07 | Abholscheine | flach | 2 | StRS-007, SwRS-005 |
|
||||||
|
| M-08 | Belegpositionen | flach | 1 | SyRS-005 |
|
||||||
|
| M-09 | Belegvorlagen | flach | 2 | SwRS-016, SyRS-016 |
|
||||||
|
| M-10 | Belegprotokoll/Progression | mittel | 6 | StRS-051, SwRS-023, SwRS-024, SwRS-154, SyRS-023, SyRS-154 |
|
||||||
|
| M-11 | Belegkonditionen | flach | 2 | SwRS-017, SyRS-017 |
|
||||||
|
| M-12 | Web-Beleg | flach | 3 | StRS-045, SwRS-123, SyRS-123 |
|
||||||
|
| M-13 | Belegsignatur | mittel | 4 | StRS-045, SwRS-124, SyRS-123, SyRS-124 |
|
||||||
|
| M-14 | Provisionsabrechnung | mittel | 4 | StRS-003, StRS-013, SwRS-084, SyRS-034 |
|
||||||
|
| M-15 | Sonderpreise/Produktmatrix | mittel | 4 | StRS-044, SwRS-197, SyRS-004, SyRS-005 |
|
||||||
|
| M-16 | Frachtartikel-Steuerung | flach | 3 | SwRS-065, SyRS-011, SyRS-064 |
|
||||||
|
| M-17 | Verträge (Kern) | tief | 11 | StRS-008, SwRS-017, SwRS-018, SwRS-030, SwRS-084, SwRS-140, SyRS-018, SyRS-030, SyRS-031, SyRS-085, SyRS-140 |
|
||||||
|
| M-18 | Automatische Vertragsabrechnung | mittel | 7 | StRS-009, SwRS-032, SwRS-033, SwRS-088, SyRS-032, SyRS-033, SyRS-165 |
|
||||||
|
| M-19 | Klickabrechnung | mittel | 4 | StRS-010, StRS-049, SwRS-140, SyRS-140 |
|
||||||
|
| M-20 | Pauschalabrechnung | mittel | 5 | StRS-011, SwRS-031, SwRS-102, SyRS-031, SyRS-064 |
|
||||||
|
| M-21 | Vereinfachte Ticketabrechnung | mittel | 4 | StRS-012, SwRS-035, SwRS-180, SyRS-035 |
|
||||||
|
| M-22 | Vertragsarten | flach | 1 | SwRS-193 |
|
||||||
|
| M-23 | Vertragsauswertung | flach | 3 | StRS-054, SwRS-170, SwRS-190 |
|
||||||
|
| M-24 | Vertrags-Datenimport | mittel | 4 | SwRS-033, SwRS-088, SwRS-197, SyRS-033 |
|
||||||
|
| M-25 | Leasing/Service | flach | 1 | SwRS-191 |
|
||||||
|
| M-26 | Adressstamm/Accounts | tief | 13 | StRS-001, StRS-044, SwRS-053, SwRS-080, SwRS-120, SwRS-122, SwRS-199, SyRS-001, SyRS-002, SyRS-080, SyRS-085, SyRS-120, SyRS-122 |
|
||||||
|
| M-27 | Alt-Kundenstamm | tief | 66 | StRS-001, StRS-002, StRS-013, StRS-015, StRS-016, StRS-030, StRS-033, StRS-035, StRS-043, StRS-044, StRS-045, StRS-047, StRS-049, StRS-058, StRS-059, StRS-060, SwRS-011, SwRS-016, … (+48) |
|
||||||
|
| M-28 | Lieferantenstamm | mittel | 5 | StRS-001, StRS-035, SwRS-075, SyRS-002, SyRS-095 |
|
||||||
|
| M-29 | Adressen und Ansprechpartner | tief | 10 | StRS-050, SwRS-004, SwRS-018, SwRS-122, SwRS-140, SwRS-150, SyRS-002, SyRS-003, SyRS-014, SyRS-150 |
|
||||||
|
| M-30 | CRM-Aktivitäten | mittel | 4 | SwRS-183, SwRS-207, SyRS-002, SyRS-183 |
|
||||||
|
| M-31 | CRM-Projekte | flach | 2 | SwRS-192, SwRS-195 |
|
||||||
|
| M-32 | Kampagnen und Mailings | flach | 1 | StRS-057 |
|
||||||
|
| M-33 | Audit/Umfragen | flach | 3 | SwRS-056, SwRS-203, SyRS-056 |
|
||||||
|
| M-34 | Lieferantenverträge | flach | 1 | SwRS-193 |
|
||||||
|
| M-35 | Kundenhotline/Zugangsdaten | mittel | 7 | StRS-047, StRS-048, SwRS-107, SwRS-130, SwRS-131, SwRS-132, SyRS-130 |
|
||||||
|
| M-36 | Geschäftsbereiche/Interessen | flach | 1 | SwRS-194 |
|
||||||
|
| M-37 | Helpdesk (Ticketkern) | tief | 15 | StRS-016, StRS-017, SwRS-050, SwRS-051, SwRS-052, SwRS-053, SwRS-054, SwRS-057, SwRS-121, SwRS-129, SwRS-203, SyRS-050, SyRS-051, SyRS-052, SyRS-053 |
|
||||||
|
| M-38 | Ticketabschluss | tief | 17 | StRS-046, SwRS-004, SwRS-007, SwRS-054, SwRS-055, SwRS-056, SwRS-057, SwRS-112, SwRS-203, SwRS-211, SyRS-050, SyRS-054, SyRS-055, SyRS-056, SyRS-128, SyRS-165, SyRS-183 |
|
||||||
|
| M-39 | Ticketkategorien/-typen/-status | mittel | 4 | StRS-016, SwRS-054, SyRS-054, SyRS-058 |
|
||||||
|
| M-40 | Prioritäten/Eskalation | flach | 2 | StRS-016, SyRS-057 |
|
||||||
|
| M-41 | Ticket-Zeiterfassung | tief | 12 | StRS-014, SwRS-036, SwRS-040, SwRS-041, SwRS-043, SwRS-182, SyRS-035, SyRS-036, SyRS-040, SyRS-041, SyRS-042, SyRS-182 |
|
||||||
|
| M-42 | Ticket-Unterschrift | tief | 12 | StRS-015, StRS-040, StRS-045, SwRS-035, SwRS-040, SwRS-042, SwRS-043, SwRS-107, SwRS-110, SwRS-112, SyRS-012, SyRS-124 |
|
||||||
|
| M-43 | Stundensatz-Aufschläge | flach | 2 | SwRS-036, SyRS-036 |
|
||||||
|
| M-44 | Ticketvorlagen/Muster | mittel | 4 | SwRS-058, SwRS-125, SyRS-058, SyRS-125 |
|
||||||
|
| M-45 | Ticketprozesse | flach | 1 | SwRS-195 |
|
||||||
|
| M-46 | Ticketprojekte | flach | 1 | SwRS-195 |
|
||||||
|
| M-47 | Checklisten | mittel | 4 | StRS-019, SwRS-058, SwRS-202, SyRS-058 |
|
||||||
|
| M-48 | Taskmanagement | flach | 2 | StRS-020, StRS-046 |
|
||||||
|
| M-49 | RMA/Werkstatt | mittel | 5 | StRS-018, SwRS-060, SyRS-054, SyRS-055, SyRS-060 |
|
||||||
|
| M-50 | Mail-Scanner | flach | 2 | StRS-041, SwRS-113 |
|
||||||
|
| M-51 | Externer Helpdesk | flach | 2 | SwRS-175, SwRS-196 |
|
||||||
|
| M-52 | Erwartete Events | flach | 2 | SwRS-179, SyRS-179 |
|
||||||
|
| M-53 | Artikelstamm | tief | 15 | StRS-011, SwRS-027, SwRS-031, SwRS-065, SwRS-066, SwRS-067, SwRS-143, SwRS-181, SwRS-200, SyRS-004, SyRS-031, SyRS-064, SyRS-065, SyRS-181, SyRS-182 |
|
||||||
|
| M-54 | Artikelimport | mittel | 4 | SwRS-067, SwRS-197, SyRS-004, SyRS-033 |
|
||||||
|
| M-55 | Warengruppen | mittel | 5 | StRS-027, SyRS-007, SyRS-009, SyRS-064, SyRS-080 |
|
||||||
|
| M-56 | Lager und Lagerplätze | flach | 1 | StRS-021 |
|
||||||
|
| M-57 | Seriennummern und Barcodes | tief | 11 | StRS-018, StRS-021, StRS-049, SwRS-060, SwRS-061, SwRS-067, SwRS-140, SyRS-010, SyRS-060, SyRS-061, SyRS-140 |
|
||||||
|
| M-58 | Inventur | mittel | 7 | StRS-021, StRS-022, SwRS-062, SwRS-063, SwRS-140, SyRS-009, SyRS-062 |
|
||||||
|
| M-59 | Kommissionierung | mittel | 7 | StRS-023, SwRS-012, SwRS-064, SwRS-102, SyRS-012, SyRS-018, SyRS-063 |
|
||||||
|
| M-60 | Artikeleinheiten/Staffelpreise | flach | 3 | SyRS-004, SyRS-005, SyRS-066 |
|
||||||
|
| M-61 | Stücklisten/Produktfamilien | flach | 3 | SwRS-066, SwRS-067, SyRS-065 |
|
||||||
|
| M-62 | Versandarten/Dienstleister | flach | 3 | SwRS-068, SwRS-069, SyRS-067 |
|
||||||
|
| M-63 | Aktionspreise | flach | 2 | SyRS-004, SyRS-005 |
|
||||||
|
| M-64 | Lieferantenbelege | flach | 3 | StRS-024, SwRS-070, SwRS-193 |
|
||||||
|
| M-65 | Bestellvorschlagsliste | flach | 2 | SwRS-075, SyRS-075 |
|
||||||
|
| M-66 | EDI-Beschaffung | tief | 19 | StRS-016, StRS-025, StRS-026, StRS-032, SwRS-029, SwRS-051, SwRS-071, SwRS-072, SwRS-087, SwRS-109, SyRS-001, SyRS-020, SyRS-051, SyRS-071, SyRS-072, SyRS-109, SyRS-111, SyRS-178, SyRS-182 |
|
||||||
|
| M-67 | ZUGFeRD/XRechnung | flach | 2 | StRS-026, SwRS-072 |
|
||||||
|
| M-68 | ebInterface | flach | 1 | StRS-026 |
|
||||||
|
| M-69 | Distributor-Produktdaten | mittel | 4 | SwRS-073, SwRS-074, SyRS-073, SyRS-074 |
|
||||||
|
| M-70 | Bestellung pro Filiale | flach | 3 | SwRS-076, SwRS-199, SyRS-076 |
|
||||||
|
| M-71 | Buchhaltungsexport/-import | mittel | 5 | StRS-027, SwRS-080, SwRS-087, SyRS-009, SyRS-080 |
|
||||||
|
| M-72 | Mahnwesen | tief | 8 | StRS-028, StRS-029, StRS-030, SwRS-082, SwRS-083, SyRS-082, SyRS-083, SyRS-084 |
|
||||||
|
| M-73 | Offene Posten (OPOS) | flach | 1 | StRS-028 |
|
||||||
|
| M-74 | Zahlungseingang | flach | 2 | SwRS-086, SyRS-087 |
|
||||||
|
| M-75 | SEPA-Mandate | tief | 8 | StRS-003, StRS-034, SwRS-050, SwRS-084, SwRS-093, SyRS-050, SyRS-085, SyRS-093 |
|
||||||
|
| M-76 | Online-Banking | flach | 2 | SwRS-085, SyRS-086 |
|
||||||
|
| M-77 | Bankverbindungen | flach | 1 | SyRS-085 |
|
||||||
|
| M-78 | Kontenrahmen | flach | 3 | SwRS-080, SwRS-199, SyRS-080 |
|
||||||
|
| M-79 | Mehrwertsteuer | mittel | 6 | SwRS-007, SwRS-008, SwRS-009, SyRS-006, SyRS-007, SyRS-008 |
|
||||||
|
| M-80 | Kostenstellen/Kostenträger | flach | 3 | StRS-027, SwRS-194, SwRS-198 |
|
||||||
|
| M-81 | Kalkulation pro Filiale | flach | 1 | SwRS-199 |
|
||||||
|
| M-82 | Produkt-Lifecycle (PLM) | flach | 2 | SwRS-102, SyRS-089 |
|
||||||
|
| M-83 | Gutschein-/Voucher-Verwaltung | tief | 10 | StRS-006, StRS-024, StRS-040, SwRS-005, SwRS-027, SwRS-065, SwRS-070, SwRS-200, SyRS-064, SyRS-113 |
|
||||||
|
| M-84 | Kunden-Assets | tief | 18 | StRS-008, StRS-009, StRS-012, StRS-049, SwRS-013, SwRS-032, SwRS-033, SwRS-035, SwRS-057, SwRS-088, SwRS-140, SwRS-143, SwRS-180, SyRS-003, SyRS-030, SyRS-032, SyRS-033, SyRS-140 |
|
||||||
|
| M-85 | Stammblätter | tief | 11 | StRS-010, StRS-049, SwRS-017, SwRS-018, SwRS-140, SwRS-176, SwRS-198, SwRS-201, SyRS-001, SyRS-140, SyRS-176 |
|
||||||
|
| M-86 | Account-Geräte | mittel | 4 | StRS-049, SwRS-141, SyRS-002, SyRS-140 |
|
||||||
|
| M-87 | Asset-Management/DocuBoard | tief | 8 | StRS-049, StRS-062, SwRS-030, SwRS-142, SwRS-161, SyRS-030, SyRS-100, SyRS-140 |
|
||||||
|
| M-88 | RMM-Anbindung | mittel | 4 | StRS-062, SwRS-087, SwRS-175, SyRS-175 |
|
||||||
|
| M-89 | docuFORM-Anbindung | mittel | 5 | StRS-010, StRS-062, SwRS-087, SwRS-175, SwRS-201 |
|
||||||
|
| M-90 | IT-Planner | flach | 1 | SwRS-202 |
|
||||||
|
| M-91 | Anmeldung/Authentifizierung | tief | 15 | StRS-033, StRS-037, StRS-061, SwRS-003, SwRS-103, SwRS-104, SwRS-105, SwRS-106, SwRS-165, SyRS-102, SyRS-104, SyRS-105, SyRS-106, SyRS-107, SyRS-165 |
|
||||||
|
| M-92 | Zwei-Faktor-Authentifizierung | flach | 3 | SwRS-003, SwRS-104, SyRS-105 |
|
||||||
|
| M-93 | Sitzungs-/Ticketverwaltung | tief | 11 | StRS-033, StRS-037, SwRS-100, SwRS-101, SwRS-121, SyRS-100, SyRS-101, SyRS-103, SyRS-104, SyRS-105, SyRS-106 |
|
||||||
|
| M-94 | Rechteverwaltung | tief | 37 | StRS-006, StRS-007, StRS-017, StRS-022, StRS-024, StRS-028, StRS-031, StRS-032, StRS-050, StRS-054, StRS-056, SwRS-006, SwRS-090, SwRS-095, SwRS-109, SwRS-142, SwRS-192, SwRS-208, … (+19) |
|
||||||
|
| M-95 | Web-Benutzerkonten | tief | 15 | StRS-017, StRS-033, StRS-044, SwRS-053, SwRS-100, SwRS-101, SwRS-120, SwRS-121, SwRS-122, SwRS-126, SwRS-173, SyRS-051, SyRS-120, SyRS-121, SyRS-122 |
|
||||||
|
| M-96 | API-Zugriffstoken | mittel | 6 | SwRS-085, SwRS-102, SwRS-108, SwRS-109, SyRS-086, SyRS-109 |
|
||||||
|
| M-97 | Lizenzierung | tief | 22 | StRS-011, StRS-036, StRS-037, StRS-056, StRS-057, SwRS-034, SwRS-088, SwRS-101, SwRS-102, SwRS-103, SwRS-109, SwRS-160, SwRS-177, SwRS-192, SwRS-193, SyRS-018, SyRS-089, SyRS-103, SyRS-104, SyRS-109, SyRS-170, SyRS-178 |
|
||||||
|
| M-98 | Mandanten und Filialen | tief | 21 | StRS-003, StRS-017, StRS-027, StRS-032, StRS-034, SwRS-050, SwRS-059, SwRS-076, SwRS-080, SwRS-092, SwRS-093, SwRS-194, SwRS-199, SyRS-009, SyRS-020, SyRS-050, SyRS-076, SyRS-080, SyRS-092, SyRS-093, SyRS-126 |
|
||||||
|
| M-99 | Nummernkreise | tief | 13 | StRS-007, StRS-018, StRS-034, StRS-035, StRS-043, SwRS-093, SwRS-094, SwRS-095, SwRS-192, SyRS-093, SyRS-094, SyRS-095, SyRS-115 |
|
||||||
|
| M-100 | Mitarbeiterverwaltung | tief | 19 | StRS-013, StRS-029, StRS-032, StRS-050, StRS-051, StRS-061, SwRS-003, SwRS-041, SwRS-082, SwRS-093, SwRS-170, SwRS-181, SwRS-182, SyRS-041, SyRS-092, SyRS-093, SyRS-130, SyRS-181, SyRS-182 |
|
||||||
|
| M-101 | Anwendungseinstellungen | flach | 1 | SwRS-203 |
|
||||||
|
| M-102 | Konfigurationsdatenbank | mittel | 4 | StRS-047, SwRS-107, SwRS-131, SyRS-130 |
|
||||||
|
| M-103 | DB-Skript-/Migrationsengine | mittel | 6 | StRS-053, SwRS-161, SwRS-162, SyRS-161, SyRS-162, SyRS-165 |
|
||||||
|
| M-104 | SQL-Manager | flach | 2 | SwRS-177, SyRS-177 |
|
||||||
|
| M-105 | Datenschutz (DSGVO) | tief | 8 | StRS-050, SwRS-023, SwRS-150, SwRS-151, SwRS-152, SyRS-150, SyRS-151, SyRS-152 |
|
||||||
|
| M-106 | Passwort-Manager | tief | 8 | StRS-047, StRS-048, StRS-059, SwRS-107, SwRS-130, SwRS-131, SwRS-132, SyRS-130 |
|
||||||
|
| M-107 | Passwortverwaltung (Altmodul) | mittel | 4 | StRS-047, StRS-048, SyRS-130, SyRS-131 |
|
||||||
|
| M-108 | Änderungshistorie | tief | 17 | StRS-018, StRS-019, StRS-020, StRS-021, StRS-044, StRS-051, SwRS-040, SwRS-057, SwRS-060, SwRS-067, SwRS-153, SwRS-154, SyRS-040, SyRS-054, SyRS-060, SyRS-153, SyRS-154 |
|
||||||
|
| M-109 | Massenupdate | flach | 2 | SwRS-176, SyRS-176 |
|
||||||
|
| M-110 | Customizing/Custom Properties | mittel | 4 | StRS-047, StRS-059, SwRS-130, SyRS-130 |
|
||||||
|
| M-111 | Telemetrie | flach | 3 | StRS-056, SwRS-167, SyRS-167 |
|
||||||
|
| M-112 | Protokollierung/LogViewer | mittel | 4 | SwRS-105, SwRS-165, SyRS-106, SyRS-165 |
|
||||||
|
| M-113 | Deployment und Container | flach | 3 | StRS-052, SwRS-160, SyRS-160 |
|
||||||
|
| M-114 | Build- und Testpipeline | mittel | 6 | SwRS-163, SwRS-164, SwRS-211, SyRS-073, SyRS-163, SyRS-164 |
|
||||||
|
| M-115 | Datenqualitätsdienst | flach | 3 | SwRS-111, SwRS-166, SyRS-166 |
|
||||||
|
| M-116 | Report-Engine | mittel | 6 | StRS-038, SwRS-028, SwRS-110, SwRS-178, SwRS-206, SyRS-110 |
|
||||||
|
| M-117 | Reportverwaltung | mittel | 6 | StRS-038, SwRS-110, SwRS-178, SwRS-206, SyRS-110, SyRS-178 |
|
||||||
|
| M-118 | Reportserver | flach | 1 | SyRS-178 |
|
||||||
|
| M-119 | PDF-Signatur | flach | 1 | SyRS-124 |
|
||||||
|
| M-120 | Mailversand und Vorlagen | tief | 14 | StRS-040, StRS-041, StRS-042, StRS-045, StRS-057, SwRS-053, SwRS-058, SwRS-112, SwRS-113, SwRS-114, SwRS-124, SyRS-113, SyRS-114, SyRS-124 |
|
||||||
|
| M-121 | Textbausteine | flach | 2 | StRS-058, SwRS-015 |
|
||||||
|
| M-122 | Kalender und Terminplanung | tief | 18 | StRS-027, StRS-040, StRS-042, StRS-062, SwRS-076, SwRS-087, SwRS-112, SwRS-114, SwRS-173, SwRS-175, SwRS-196, SwRS-197, SwRS-199, SwRS-201, SwRS-214, SyRS-076, SyRS-088, SyRS-181 |
|
||||||
|
| M-123 | Terminanfragen | flach | 1 | SwRS-204 |
|
||||||
|
| M-124 | Telefonie/TAPI | flach | 3 | StRS-043, SwRS-115, SyRS-115 |
|
||||||
|
| M-125 | Volltext-Indexsuche | mittel | 5 | StRS-055, SwRS-023, SwRS-171, SyRS-023, SyRS-171 |
|
||||||
|
| M-126 | Dokumentenverwaltung | mittel | 7 | StRS-039, StRS-045, SwRS-111, SwRS-124, SyRS-111, SyRS-123, SyRS-124 |
|
||||||
|
| M-127 | Benachrichtigungen | mittel | 7 | StRS-046, SwRS-041, SwRS-126, SwRS-128, SwRS-205, SyRS-041, SyRS-128 |
|
||||||
|
| M-128 | Chats | flach | 1 | SwRS-205 |
|
||||||
|
| M-129 | Tags | flach | 1 | SwRS-206 |
|
||||||
|
| M-130 | Web-Links/Kurz-URLs | flach | 1 | SwRS-207 |
|
||||||
|
| M-131 | Dokumentationsbereich | flach | 1 | SwRS-208 |
|
||||||
|
| M-132 | Social Media | flach | 1 | SwRS-209 |
|
||||||
|
| M-133 | Videoportal | flach | 1 | SwRS-210 |
|
||||||
|
| M-134 | Nexus ServiceBoard | tief | 10 | StRS-046, SwRS-059, SwRS-101, SwRS-102, SwRS-141, SwRS-182, SwRS-215, SyRS-057, SyRS-059, SyRS-115 |
|
||||||
|
| M-135 | Nexus Kundenportal/WebCart | mittel | 6 | StRS-044, SwRS-025, SwRS-125, SwRS-126, SyRS-004, SyRS-125 |
|
||||||
|
| M-136 | Nexus WebOffer | flach | 1 | SyRS-123 |
|
||||||
|
| M-137 | Nexus Dokumentensignatur | flach | 3 | StRS-045, SwRS-124, SyRS-124 |
|
||||||
|
| M-138 | Nexus Management | mittel | 5 | StRS-020, SwRS-058, SwRS-125, SyRS-058, SyRS-125 |
|
||||||
|
| M-139 | Nexus Einstellungen/Branding | mittel | 4 | SwRS-126, SwRS-128, SyRS-126, SyRS-127 |
|
||||||
|
| M-140 | Outlook-Add-In | flach | 2 | SwRS-127, SyRS-127 |
|
||||||
|
| M-141 | Self-Care-Formulare | flach | 3 | SwRS-125, SwRS-173, SyRS-125 |
|
||||||
|
| M-142 | WPF-Rich-Client | tief | 61 | StRS-001, StRS-002, StRS-009, StRS-010, StRS-011, StRS-013, StRS-025, StRS-027, StRS-036, StRS-042, StRS-048, StRS-054, StRS-055, StRS-056, StRS-057, StRS-059, StRS-060, SwRS-001, … (+43) |
|
||||||
|
| M-143 | Gemeinsame Steuerelemente | tief | 8 | SwRS-093, SwRS-107, SwRS-164, SwRS-211, SyRS-107, SyRS-108, SyRS-112, SyRS-165 |
|
||||||
|
| M-144 | Mobile-Anbindung | flach | 1 | SwRS-212 |
|
||||||
|
| M-145 | Webservice-Host und REST-API | tief | 21 | StRS-019, StRS-026, StRS-033, StRS-052, StRS-062, SwRS-058, SwRS-069, SwRS-091, SwRS-173, SwRS-174, SwRS-175, SwRS-196, SwRS-201, SyRS-091, SyRS-105, SyRS-125, SyRS-170, SyRS-173, SyRS-174, SyRS-175, SyRS-182 |
|
||||||
|
| M-146 | Verbindungsverwaltung | flach | 3 | SwRS-002, SwRS-168, SyRS-168 |
|
||||||
|
| M-147 | Statistiken und Auswertungen | tief | 8 | StRS-046, StRS-054, SwRS-057, SwRS-088, SwRS-170, SwRS-182, SwRS-190, SyRS-182 |
|
||||||
|
| M-148 | MSP-Collector | mittel | 6 | StRS-054, SwRS-088, SwRS-170, SwRS-190, SyRS-033, SyRS-089 |
|
||||||
|
| M-149 | Management-Info und Dashboard | mittel | 4 | StRS-054, SwRS-190, SwRS-215, SyRS-170 |
|
||||||
|
| M-150 | Mein Tag (MyDay) | flach | 3 | StRS-046, SwRS-213, SwRS-215 |
|
||||||
|
| M-151 | Todo-Liste | mittel | 6 | StRS-020, StRS-046, SwRS-023, SwRS-215, SyRS-023, SyRS-054 |
|
||||||
|
| M-152 | KI-Assistent | mittel | 6 | StRS-056, SwRS-102, SwRS-167, SwRS-172, SyRS-167, SyRS-172 |
|
||||||
|
| M-153 | Externe Werkzeuge/Fernwartung | flach | 1 | SwRS-213 |
|
||||||
|
| M-154 | TradePool | flach | 2 | StRS-062, SwRS-214 |
|
||||||
|
| M-155 | RiverSuite/RiverDivo | flach | 2 | StRS-062, SwRS-214 |
|
||||||
|
| M-156 | CPra-Konnektor | flach | 2 | StRS-062, SwRS-214 |
|
||||||
|
| M-157 | Telekom Dive | mittel | 4 | SwRS-087, SwRS-175, SwRS-214, SyRS-175 |
|
||||||
|
| M-158 | GFK-Export | flach | 2 | SwRS-087, SyRS-088 |
|
||||||
|
| M-159 | Objekt-Externreferenzen | mittel | 5 | StRS-062, SwRS-023, SwRS-175, SyRS-023, SyRS-175 |
|
||||||
|
| M-160 | Zahlungsverkehrsdateien | flach | 2 | SwRS-087, SyRS-088 |
|
||||||
|
| M-161 | Produktion | mittel | 6 | StRS-052, StRS-060, SwRS-035, SwRS-067, SwRS-180, SyRS-180 |
|
||||||
|
| M-162 | Datenimport (generisch) | flach | 1 | SwRS-197 |
|
||||||
|
| M-163 | Gateway | mittel | 4 | StRS-025, SwRS-071, SwRS-214, SyRS-071 |
|
||||||
|
| M-164 | Länderverwaltung | flach | 1 | SyRS-008 |
|
||||||
|
| M-165 | Themes/Oberflächenanpassung | flach | 1 | SyRS-126 |
|
||||||
|
|
||||||
|
**Zusammenfassung der Abdeckung:**
|
||||||
|
|
||||||
|
| Einstufung | Module | Anteil |
|
||||||
|
|---|---|---|
|
||||||
|
| tief (≥ 8 Anforderungen) | 23 | 13,9 % |
|
||||||
|
| mittel (4–7) | 64 | 38,8 % |
|
||||||
|
| flach (1–3) | 78 | 47,3 % |
|
||||||
|
| nicht analysiert (0) | **0** | 0 % |
|
||||||
|
| **Summe** | **165** | **100 %** |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Konsistenzcheck über das gesamte Anforderungs-Set
|
||||||
|
|
||||||
|
Der Check wurde maschinell über alle 363 Anforderungsblöcke ausgeführt (Auswertung der Felder `ID`,
|
||||||
|
`Belege`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`, `Qualitätsmerkmal`).
|
||||||
|
|
||||||
|
| Prüfung | Ergebnis |
|
||||||
|
|---|---|
|
||||||
|
| Doppelte oder mehrfach vergebene IDs | **0** — alle 363 IDs sind eindeutig (62 StRS, 132 SyRS, 169 SwRS). |
|
||||||
|
| Anforderungen ohne Beleg | **0** — jede Anforderung führt mindestens einen Beleg; insgesamt 740 Belege. |
|
||||||
|
| Anforderungen ohne Angabe zur `Übernahmewürdigkeit` | **0** |
|
||||||
|
| Anforderungen ohne `Tracelinks` | **0** |
|
||||||
|
| Tracelinks auf nicht existierende IDs | **0** — vier zunächst leere Verweise (`SyRS-130`, `SyRS-131`, `SyRS-140`, ein Tippfehler `SyRS-200`) wurden im Lauf behoben, indem die fehlenden Anforderungen ergänzt beziehungsweise der Verweis korrigiert wurde. |
|
||||||
|
| Nicht-funktionale Anforderungen ohne ISO-25010-Zuordnung | **0** — alle 46 nicht-funktionalen Anforderungen führen das Merkmal im Feld `Qualitätsmerkmal`. |
|
||||||
|
| Doppelte Titel | **0** |
|
||||||
|
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung | **0** — ein automatischer Ähnlichkeitsvergleich aller Paare (Feld `Aussage`, Schwelle 0,72) liefert zwei Paare: `StRS-022`/`SyRS-062` (0,83) und `SwRS-063`/`SwRS-093` (0,73). Beide sind bereits als Konsolidierungskandidat markiert. `StRS-022`/`SyRS-062` beschreiben denselben Sachverhalt auf zwei Ebenen und sind damit gemäß Vorgabe **kein** Konsolidierungsfall; die Verbindung stellen die Tracelinks her. |
|
||||||
|
| Abgleich `Hypothesen.md` gegen Inline-Markierungen | **deckungsgleich** — 5 Anforderungen tragen `Status: HYPOTHESE`, dieselben 5 tragen die Inline-Markierung `[HYPOTHESE]` im Feld `Aussage`, und dieselben 5 stehen in `Hypothesen.md`. `Hypothesen.md` enthält keine zusätzlichen freien Fragen; diese stehen in Abschnitt 5.4. |
|
||||||
|
|
||||||
|
### 4.1 Belegsituation im Überblick
|
||||||
|
|
||||||
|
| Kennzahl | Wert |
|
||||||
|
|---|---|
|
||||||
|
| Belege gesamt | 740 |
|
||||||
|
| davon `PRIMÄR` | 490 (66,2 %) |
|
||||||
|
| davon `SEKUNDÄR` | 187 (25,3 %) |
|
||||||
|
| davon `KONTEXT` | 63 (8,5 %) |
|
||||||
|
| Anforderungen mit genau einem Beleg | 76 (20,9 %) |
|
||||||
|
| Anforderungen ohne `PRIMÄR`-Beleg | 1 (`SyRS-005`, als `[HYPOTHESE]` geführt) |
|
||||||
|
| Belege je Anforderung (Durchschnitt) | 2,04 |
|
||||||
|
|
||||||
|
### 4.2 Verteilung nach Typ und Übernahmewürdigkeit
|
||||||
|
|
||||||
|
| Typ | Anzahl | | Übernahmewürdigkeit | Anzahl |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| funktional | 147 | | übernehmen | 336 |
|
||||||
|
| Daten | 87 | | veraltet | 14 |
|
||||||
|
| Sicherheit | 55 | | Workaround | 12 |
|
||||||
|
| nicht-funktional | 46 | | Sonderfall | 1 |
|
||||||
|
| Schnittstelle | 28 | | | |
|
||||||
|
|
||||||
|
ISO-25010-Merkmale der 46 nicht-funktionalen Anforderungen: Wartbarkeit 29, Zuverlässigkeit 7,
|
||||||
|
Übertragbarkeit 4, Performance-Effizienz 4, Benutzbarkeit 2.
|
||||||
|
|
||||||
|
Konsolidierungskandidaten: **67** von 363 Anforderungen (18,5 %).
|
||||||
|
|
||||||
|
### 4.3 Liste der risikorelevanten Anforderungen
|
||||||
|
|
||||||
|
Als risikorelevant gilt jede Anforderung vom Typ `Sicherheit` sowie jede, deren `Titel`, `Fakt` oder
|
||||||
|
`Aussage` Berechtigungen, Abrechnung, Fakturierung, Preisfindung, Mahnwesen, Zahlungsverkehr,
|
||||||
|
Lizenzierung, Kennwörter, Verschlüsselung, Token, Anmeldung, Datenschutz, Steuersätze,
|
||||||
|
Kontingente, Belegnummern, Signaturen oder Zugangsdaten betrifft.
|
||||||
|
|
||||||
|
**Ergebnis: 173 risikorelevante Anforderungen. Davon 172 mit mindestens einem `PRIMÄR`-Beleg; die
|
||||||
|
eine Ausnahme (`SyRS-005`) ist als `[HYPOTHESE]` gekennzeichnet. Verstöße gegen die risikobasierte
|
||||||
|
Priorisierung: 0.**
|
||||||
|
|
||||||
|
| ID | Titel | PRIMÄR-Beleg vorhanden | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| StRS-003 | Durchgängige Belegkette vom Angebot zur Rechnung | ja | belegt |
|
||||||
|
| StRS-005 | Fakturierung erbrachter Leistungen | ja | belegt |
|
||||||
|
| StRS-006 | Gutschriften als wertmäßige Korrektur | ja | belegt |
|
||||||
|
| StRS-007 | Abholscheine und Barverkauf | ja | belegt |
|
||||||
|
| StRS-008 | Serviceverträge mit wiederkehrender Abrechnung | ja | belegt |
|
||||||
|
| StRS-009 | Automatische Erzeugung von Vertragsrechnungen | ja | belegt |
|
||||||
|
| StRS-010 | Abrechnung nach Zählerständen (Klickabrechnung) | ja | belegt |
|
||||||
|
| StRS-011 | Pauschalabrechnung von Projekten | ja | belegt |
|
||||||
|
| StRS-012 | Abrechnung erfasster Ticketzeiten | ja | belegt |
|
||||||
|
| StRS-013 | Provisionsabrechnung für Vertriebsmitarbeiter | ja | belegt |
|
||||||
|
| StRS-015 | Bestätigung erbrachter Leistung durch Kundenunterschrift | ja | belegt |
|
||||||
|
| StRS-017 | Abgestufte Sichtbarkeit von Tickets | ja | belegt |
|
||||||
|
| StRS-024 | Beschaffung über Lieferantenbelege | ja | belegt |
|
||||||
|
| StRS-025 | Elektronischer Datenaustausch mit Distributoren | ja | belegt |
|
||||||
|
| StRS-026 | Elektronische Rechnungsformate | ja | belegt |
|
||||||
|
| StRS-028 | Offene-Posten-Verwaltung | ja | belegt |
|
||||||
|
| StRS-029 | Mehrstufiges Mahnwesen | ja | belegt |
|
||||||
|
| StRS-030 | Auftragssperre bei erreichter Mahnstufe | ja | belegt |
|
||||||
|
| StRS-031 | Rollenbasierte Berechtigungsverwaltung | ja | belegt |
|
||||||
|
| StRS-032 | Einschränkende Rechte auf eigene Objekte oder eigene Filiale | ja | belegt |
|
||||||
|
| StRS-033 | Anmeldung über mehrere Identitätsquellen | ja | belegt |
|
||||||
|
| StRS-034 | Mandanten- und Filialstruktur | ja | belegt |
|
||||||
|
| StRS-035 | Lückenlose Belegnummernvergabe | ja | belegt |
|
||||||
|
| StRS-036 | Lizenzabhängige Funktionsfreischaltung | ja | belegt |
|
||||||
|
| StRS-037 | Begrenzung gleichzeitiger Anmeldungen über Lizenzanzahl | ja | belegt |
|
||||||
|
| StRS-040 | E-Mail-Kommunikation aus dem Vorgang heraus | ja | belegt |
|
||||||
|
| StRS-043 | Telefonieanbindung mit Anruferkennung | ja | belegt |
|
||||||
|
| StRS-045 | Belegfreigabe und Unterzeichnung durch den Kunden | ja | belegt |
|
||||||
|
| StRS-047 | Verwaltung von Kundenzugangsdaten | ja | belegt |
|
||||||
|
| StRS-048 | Ablösung des alten Zugangsdatenmoduls | ja | belegt |
|
||||||
|
| StRS-049 | Verwaltung installierter Kundengeräte | ja | belegt |
|
||||||
|
| StRS-050 | Wahrung der Betroffenenrechte nach DSGVO | ja | belegt |
|
||||||
|
| StRS-054 | Auswertungen und Kennzahlen für die Unternehmenssteuerung | ja | belegt |
|
||||||
|
| StRS-055 | Objektübergreifende Volltextsuche | ja | belegt |
|
||||||
|
| StRS-056 | KI-gestützte Assistenz | ja | belegt |
|
||||||
|
| StRS-057 | Kampagnen und Serienkommunikation | ja | belegt |
|
||||||
|
| StRS-059 | Kundenindividuelle Zusatzfelder | ja | belegt |
|
||||||
|
| StRS-061 | Mitarbeiterverwaltung als Grundlage der Zuständigkeit | ja | belegt |
|
||||||
|
| SyRS-001 | Rechteprüfung bei Anlage und Änderung von Geschäftspartnern | ja | belegt |
|
||||||
|
| SyRS-004 | Kundenindividuelle Sonderpreise | ja | belegt |
|
||||||
|
| SyRS-005 | Mehrstufige Preisquellen mit definierter Rangfolge | **nein** | HYPOTHESE |
|
||||||
|
| SyRS-006 | Steuersatzwechsel über verkettete Steuersätze | ja | belegt |
|
||||||
|
| SyRS-007 | Massenumstellung von Artikelsteuersätzen mit Preisoption | ja | belegt |
|
||||||
|
| SyRS-009 | Warengruppenhierarchie mit Erlöskontozuordnung | ja | belegt |
|
||||||
|
| SyRS-013 | Belegsperre während der Bearbeitung | ja | belegt |
|
||||||
|
| SyRS-017 | Zahlungsziel aus Zahlungskondition | ja | belegt |
|
||||||
|
| SyRS-018 | Abweichende Liefer-, Rechnungs- und Lizenznehmeradresse | ja | belegt |
|
||||||
|
| SyRS-020 | Rechteprüfung an jedem Belegänderungspunkt | ja | belegt |
|
||||||
|
| SyRS-021 | Getrennte Rechte für Einkaufs- und Verkaufspreisänderung | ja | belegt |
|
||||||
|
| SyRS-023 | Gemeinsames Objektprotokoll über Objektart und Objekt-ID | ja | belegt |
|
||||||
|
| SyRS-030 | Kontingentverbrauch und Restkontingent eines Vertrags | ja | belegt |
|
||||||
|
| SyRS-031 | Ausgleichsartikel für Kontingentsalden | ja | belegt |
|
||||||
|
| SyRS-032 | Stichtagsbezogene Ermittlung fälliger Abrechnungen | ja | belegt |
|
||||||
|
| SyRS-034 | Gegenseitiger Ausschluss der Provisionsmodule | ja | belegt |
|
||||||
|
| SyRS-035 | Einmalige Abrechnung eines Zeiteintrags | ja | belegt |
|
||||||
|
| SyRS-036 | Stundensatzzuschläge nach Zeitfenstern | ja | belegt |
|
||||||
|
| SyRS-042 | Löschen von Zeiteinträgen nur mit eigenem Recht | ja | belegt |
|
||||||
|
| SyRS-051 | Rechteprüfungen beim Speichern eines Tickets | ja | belegt |
|
||||||
|
| SyRS-055 | Ticketabschluss trotz offener RMA | ja | HYPOTHESE |
|
||||||
|
| SyRS-057 | Weiterleitung und Eskalation von Tickets | ja | belegt |
|
||||||
|
| SyRS-064 | Rollen von Systemartikeln | ja | belegt |
|
||||||
|
| SyRS-065 | Artikelbezogene Sichtbarkeits- und Sperrsteuerung | ja | belegt |
|
||||||
|
| SyRS-070 | Erkennung doppelter Lieferantenrechnungsnummern | ja | belegt |
|
||||||
|
| SyRS-073 | Bezug von Produktdaten externer Kataloge | ja | belegt |
|
||||||
|
| SyRS-074 | Kontingentüberwachung externer Katalogzugriffe | ja | belegt |
|
||||||
|
| SyRS-080 | Kontenfindung nach Artikel, Warengruppe und Filiale | ja | belegt |
|
||||||
|
| SyRS-081 | Erfassung des Bezahltstatus mit Herkunftsangabe | ja | belegt |
|
||||||
|
| SyRS-082 | Prüfung und Vorschau vor dem Mahnlauf | ja | belegt |
|
||||||
|
| SyRS-083 | Rücknahme eines Mahnlaufs um genau eine Stufe | ja | belegt |
|
||||||
|
| SyRS-084 | Keine Mahnstufensperre auf der Lieferantenseite | ja | belegt |
|
||||||
|
| SyRS-086 | Kontoumsatzabruf über finAPI mit eigenem Recht | ja | belegt |
|
||||||
|
| SyRS-087 | Protokoll der Zahlungseingänge mit eigener Laufnummer | ja | belegt |
|
||||||
|
| SyRS-088 | Erzeugung von Zahlungsverkehrsdateien | ja | belegt |
|
||||||
|
| SyRS-089 | Produktlebenszyklus von Lizenzbeständen | ja | belegt |
|
||||||
|
| SyRS-090 | Rechteermittlung ausschließlich über Gruppenzugehörigkeit | ja | belegt |
|
||||||
|
| SyRS-091 | Deklarative Rechteprüfung an REST-Endpunkten | ja | belegt |
|
||||||
|
| SyRS-092 | Filialbeschränkung als eigenständige Prüfstufe | ja | belegt |
|
||||||
|
| SyRS-093 | Hierarchische Nummernkreisauflösung über Mitarbeiter, Filiale und Mandant | ja | belegt |
|
||||||
|
| SyRS-100 | Sitzungsticket mit anwendungsabhängiger Gültigkeitsdauer | ja | belegt |
|
||||||
|
| SyRS-102 | Anwendungsbezogene Zugangsrechte bei der Anmeldung | ja | belegt |
|
||||||
|
| SyRS-103 | Lizenzprüfung mit Anzahl, Ablaufdatum und Versionsgrenze | ja | belegt |
|
||||||
|
| SyRS-104 | Wiederverwendung bestehender Sitzungen vor der Lizenzprüfung | ja | belegt |
|
||||||
|
| SyRS-105 | Zwei-Faktor-Authentifizierung als zweite Prüfstufe | ja | belegt |
|
||||||
|
| SyRS-106 | Protokollierung von Anmeldeversuchen | ja | belegt |
|
||||||
|
| SyRS-107 | Kennwortspeicherung der Anwendungsbenutzer | ja | belegt |
|
||||||
|
| SyRS-108 | Symmetrische Verschlüsselung mit fest hinterlegtem Ersatzschlüssel | ja | belegt |
|
||||||
|
| SyRS-109 | Erzeugung und Prüfung von API-Zugriffstoken | ja | belegt |
|
||||||
|
| SyRS-112 | Unterdrückung des Versands an externe Empfänger außerhalb von Freigabeversionen | ja | belegt |
|
||||||
|
| SyRS-115 | Anrufprotokollierung mit Vorgangsbezug | ja | belegt |
|
||||||
|
| SyRS-120 | Eigenes Rechtesystem für Web-Benutzerkonten | ja | belegt |
|
||||||
|
| SyRS-121 | Sperre der Belegeinsicht für Web-Benutzer in der Fachlogik | ja | belegt |
|
||||||
|
| SyRS-122 | Kennwortregeln und Kennwortversand für Web-Konten | ja | belegt |
|
||||||
|
| SyRS-123 | Belegfreigabe über Einmal-Token ohne Anmeldung | ja | belegt |
|
||||||
|
| SyRS-124 | Erfassung und Speicherung der Unterschrift im Browser | ja | belegt |
|
||||||
|
| SyRS-126 | Mandantenspezifisches Erscheinungsbild der Weboberfläche | ja | belegt |
|
||||||
|
| SyRS-150 | Ermittlung löschbarer Kontaktdaten nach DSGVO | ja | belegt |
|
||||||
|
| SyRS-151 | Nicht implementierte Löschpfade im Datenschutzmodul | ja | HYPOTHESE |
|
||||||
|
| SyRS-152 | Bereinigung nicht mehr benötigter Datenbestände | ja | belegt |
|
||||||
|
| SyRS-154 | Feldbezogene Änderungshistorie ausgewählter Belegangaben | ja | belegt |
|
||||||
|
| SyRS-161 | Ausführung fehlender Datenbankskripte vor der Anmeldung | ja | belegt |
|
||||||
|
| SyRS-170 | Getrennte Rechte je Auswertung | ja | belegt |
|
||||||
|
| SyRS-171 | Bedarfsgesteuerte und vollständige Indexaktualisierung | ja | belegt |
|
||||||
|
| SyRS-174 | Beschränkung von Endpunkten auf die gehostete Betriebsform | ja | belegt |
|
||||||
|
| SyRS-176 | Feldänderungen über viele Datensätze hinweg | ja | belegt |
|
||||||
|
| SyRS-177 | Administrative SQL-Ausführung aus der Anwendung | ja | belegt |
|
||||||
|
| SyRS-178 | Zeitgesteuerter Reportversand | ja | belegt |
|
||||||
|
| SyRS-179 | Überwachung erwarteter, wiederkehrender Ereignisse | ja | belegt |
|
||||||
|
| SyRS-181 | Abwesenheits- und Urlaubsverwaltung als Planungsgrundlage | ja | belegt |
|
||||||
|
| SyRS-182 | Mitarbeiterartikel als Bindeglied zwischen Person und Leistung | ja | belegt |
|
||||||
|
| SyRS-130 | Verschlüsselte Ablage und protokollierter Zugriff auf Zugangsdaten | ja | belegt |
|
||||||
|
| SyRS-131 | Unvollständige Kennwortspeicherung im abgelösten Zugangsdatenmodul | ja | belegt |
|
||||||
|
| SwRS-013 | Belegartspezifische Sperrentitäten | ja | belegt |
|
||||||
|
| SwRS-017 | Zahlungskonditionen als eigene Stammdatentabelle | ja | belegt |
|
||||||
|
| SwRS-020 | Zentrale Rechteprüfmethoden im Belegkern | ja | belegt |
|
||||||
|
| SwRS-021 | Rücksetzen unberechtigter Preisänderungen anhand der Vorgängerversion | ja | belegt |
|
||||||
|
| SwRS-027 | Warnung bei nicht umgewandelten Fremdartikeln | ja | belegt |
|
||||||
|
| SwRS-030 | Kontingentfelder als eigenständige Vertragsattribute | ja | belegt |
|
||||||
|
| SwRS-032 | Abrechnungslauf über benannte Abfragen je Vorgangsart | ja | belegt |
|
||||||
|
| SwRS-034 | Rechteausdrücke der Modulregistrierung | ja | belegt |
|
||||||
|
| SwRS-035 | Filterstruktur der Ticketabrechnung | ja | belegt |
|
||||||
|
| SwRS-042 | Unterschrift als eigenständige Entität je Zeiteintrag | ja | belegt |
|
||||||
|
| SwRS-043 | Protokoll der Zeiteintragsänderungen | ja | belegt |
|
||||||
|
| SwRS-051 | Rechteprüfung im Vorspeicherschritt der Ticketentität | ja | belegt |
|
||||||
|
| SwRS-053 | Variablenersetzung über eine gemeinsame Komponente | ja | belegt |
|
||||||
|
| SwRS-054 | Abschlussstatus des Tickets aus den Einstellungen | ja | belegt |
|
||||||
|
| SwRS-066 | Produktfamilien mit Kunden- und Positionssperren | ja | belegt |
|
||||||
|
| SwRS-074 | Kontingentangabe als Antwortbestandteil des Katalogs | ja | belegt |
|
||||||
|
| SwRS-080 | Dreistufige Erlöskontotabellen | ja | belegt |
|
||||||
|
| SwRS-081 | Herkunftsangabe als Pflichtparameter der Zahlungsbuchung | ja | belegt |
|
||||||
|
| SwRS-082 | Mahnstufenfelder je Stufe mit Datum und Bearbeiter | ja | belegt |
|
||||||
|
| SwRS-083 | Sperrgrenze aus dem Kundenstamm | ja | belegt |
|
||||||
|
| SwRS-084 | Mandat als Belegfeld mit eigener Übernahmeregel | ja | belegt |
|
||||||
|
| SwRS-085 | Bankzugangsdaten der finAPI-Anbindung | ja | HYPOTHESE |
|
||||||
|
| SwRS-086 | Zahlungseingangsprotokoll als eigenständige Entität | ja | belegt |
|
||||||
|
| SwRS-087 | Zahlungsverkehr als eigener Datenaustauschzweig | ja | belegt |
|
||||||
|
| SwRS-088 | Lizenzbestandsvergleich gegen MSP-Daten | ja | belegt |
|
||||||
|
| SwRS-090 | Zwei Wege der Rechteermittlung | ja | belegt |
|
||||||
|
| SwRS-091 | Drei Autorisierungsattribute mit gemeinsamer Filterbasis | ja | belegt |
|
||||||
|
| SwRS-092 | Filialvergleich als gemeinsame Hilfsfunktion | ja | belegt |
|
||||||
|
| SwRS-093 | Zwei Wege der Nummernkreisauflösung | ja | belegt |
|
||||||
|
| SwRS-094 | Optimistische Sperre der Nummernvergabe | ja | belegt |
|
||||||
|
| SwRS-095 | Zusammengesetzte SQL-Anweisungen der Nummernprüfung | ja | belegt |
|
||||||
|
| SwRS-100 | Ticketerzeugung mit gerätebezogenem Zusatzwert | ja | belegt |
|
||||||
|
| SwRS-101 | Anwendungsart als Konfigurationsobjekt der Anmeldung | ja | belegt |
|
||||||
|
| SwRS-102 | Lizenzkennungen als zentrale Konstantenliste | ja | belegt |
|
||||||
|
| SwRS-103 | Sperre um Ticketprüfung und Lizenzvergabe | ja | belegt |
|
||||||
|
| SwRS-104 | Austauschbare Zweitfaktor-Prüfer | ja | belegt |
|
||||||
|
| SwRS-106 | Kennwortprüfung als Datenbankvergleich des Hashwerts | ja | belegt |
|
||||||
|
| SwRS-107 | Verschlüsselungskomponente mit optionalem Schlüsselparameter | ja | belegt |
|
||||||
|
| SwRS-108 | Protokollierung aller Tokenvorgänge | ja | belegt |
|
||||||
|
| SwRS-109 | Trennung persönlicher und administrativer Tokenverwaltung | ja | belegt |
|
||||||
|
| SwRS-112 | Mailkomponenten nach Aufgabe getrennt | ja | belegt |
|
||||||
|
| SwRS-120 | Web-Rechte als eigene Entitäten mit Kategorien | ja | belegt |
|
||||||
|
| SwRS-121 | Kennzeichen der Web-Anmeldung im Anmeldekontext | ja | belegt |
|
||||||
|
| SwRS-124 | Geteiltes Dokument als eigene Entität | ja | belegt |
|
||||||
|
| SwRS-130 | Zugangsdaten als verschlüsselte Zusatzfelder | ja | belegt |
|
||||||
|
| SwRS-131 | Masterschlüssel aus der Konfigurationsdatenbank | ja | belegt |
|
||||||
|
| SwRS-132 | Migration der Altzugangsdaten in den Passwort-Manager | ja | belegt |
|
||||||
|
| SwRS-150 | Löschprotokoll des Datenschutzmoduls | ja | belegt |
|
||||||
|
| SwRS-153 | Audit-Felder als Bestandteil der Belegbasis | ja | belegt |
|
||||||
|
| SwRS-160 | Selbstenthaltende Veröffentlichung der Webanwendung | ja | belegt |
|
||||||
|
| SwRS-177 | SQL-Verwaltung mit Datenbankauskunft für den Lizenzserver | ja | belegt |
|
||||||
|
| SwRS-179 | Erwartete Ereignisse mit getrennter Auswertung | ja | belegt |
|
||||||
|
| SwRS-181 | Mitarbeiterbausteine nach Aufgabe getrennt | ja | belegt |
|
||||||
|
| SwRS-192 | CRM-Projekte mit eigener Nummernart | ja | belegt |
|
||||||
|
| SwRS-193 | Lieferantenverträge am Account | ja | belegt |
|
||||||
|
| SwRS-201 | docuFORM-Anbindung als eigenes Projekt | ja | belegt |
|
||||||
|
| SwRS-208 | Strukturierte Kundendokumentation | ja | belegt |
|
||||||
|
| SwRS-210 | Zuordnung von Schulungsvideos zu Objekten | ja | belegt |
|
||||||
|
| SwRS-212 | Mobile Datenversorgung als eigener Baustein | ja | belegt |
|
||||||
|
| SwRS-213 | Externe Werkzeuge und Fernwartung | ja | belegt |
|
||||||
|
| SwRS-214 | Fremdsystemkonnektoren mit eigener Verbindungslogik | ja | belegt |
|
||||||
|
| SwRS-215 | Dashboard und Startbereich als verdichtete Einstiegssicht | ja | belegt |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Selbstbewertung
|
||||||
|
|
||||||
|
### 5.1 Analysetiefe je Modul (absolute Zahlen)
|
||||||
|
|
||||||
|
Von **165** Inventarmodulen wurden
|
||||||
|
|
||||||
|
- **23** tief analysiert (≥ 8 Anforderungen) — darunter Belegkern, Rechnungen, Verträge, Helpdesk,
|
||||||
|
Zeiterfassung, Rechteverwaltung, Anmeldung, Lizenzierung, Nummernkreise, Mandanten/Filialen,
|
||||||
|
Mahnwesen, Artikelstamm, Web-Benutzerkonten, REST-Schnittstelle;
|
||||||
|
- **64** mittel analysiert (4–7 Anforderungen);
|
||||||
|
- **78** flach analysiert (1–3 Anforderungen);
|
||||||
|
- **0** gar nicht analysiert.
|
||||||
|
|
||||||
|
Die Verteilung folgt der Vorgabe „Breite vor Tiefe": zuerst wurde für jedes Modul mindestens eine
|
||||||
|
belegte Anforderung gebildet, danach wurden die Risikobereiche vertieft. Die 78 flach analysierten
|
||||||
|
Module tragen überwiegend Anforderungen auf SwRS-Ebene, die den Baustein und seine Datenstruktur
|
||||||
|
benennen, nicht seine inneren Regeln.
|
||||||
|
|
||||||
|
### 5.2 Mindestabdeckung
|
||||||
|
|
||||||
|
**Erreicht.** Jedes der 165 Inventarmodule hat mindestens eine Anforderung; kein Modul steht als
|
||||||
|
`nicht analysiert` im Inventar. Es war für kein Modul erforderlich, mangels belegbarer Aussage auf
|
||||||
|
eine Anforderung zu verzichten.
|
||||||
|
|
||||||
|
### 5.3 Stellen mit dünnem Beleg
|
||||||
|
|
||||||
|
Der Gesamtanteil an `PRIMÄR`-Belegen liegt bei 66,2 %. Dünn belegt sind insbesondere:
|
||||||
|
|
||||||
|
1. **Preisfindung (`SyRS-005`, `SwRS-005`).** Die einzige Anforderung ohne `PRIMÄR`-Beleg. Vier
|
||||||
|
konkurrierende Preisquellen sind nachgewiesen, die Rangfolge nicht. Als `[HYPOTHESE]` geführt.
|
||||||
|
2. **Kontenfindung (`SyRS-080`, `SwRS-080`).** Die drei Zuordnungstabellen sind im Schema belegt,
|
||||||
|
die Rangfolge zwischen ihnen wurde aus der Tabellenstruktur erschlossen, nicht aus dem
|
||||||
|
auswertenden Code. Die Prüfidee benennt diese offene Stelle ausdrücklich.
|
||||||
|
3. **Module, die nur über Verzeichnisstruktur und Modulregistrierung belegt sind.** Dazu zählen
|
||||||
|
TradePool (`M-154`), CPra (`M-156`), Telekom Dive (`M-157`), Social Media (`M-132`), Videoportal
|
||||||
|
(`M-133`), Chats (`M-128`), Mobile (`M-144`), IT-Planner (`M-90`) und Gateway (`M-163`). Ihre
|
||||||
|
Anforderungen benennen den Baustein und seine Datenstruktur, nicht die durchgesetzten Regeln.
|
||||||
|
Hier ist der Anteil `SEKUNDÄR`/`KONTEXT` am höchsten.
|
||||||
|
4. **Nicht erhobene Artefaktart.** Change-Historie, Commit-Messages, Tickets und Release Notes
|
||||||
|
konnten nicht ausgewertet werden, weil das Arbeitsverzeichnis kein Repository der analysierten
|
||||||
|
Codebasis enthält. Damit fehlt durchgängig die Belegklasse, aus der sich die Entstehungsgründe
|
||||||
|
von Workarounds ableiten ließen. Die 12 als `Workaround` und 14 als `veraltet` eingestuften
|
||||||
|
Anforderungen stützen sich stattdessen auf Quelltextkommentare, `[Obsolete]`-Attribute und
|
||||||
|
Bezeichnungen wie „(obsolate)" oder `ContractEvaluation2`.
|
||||||
|
5. **Vier Aussagen, die auf dem Fehlen eines Artefakts beruhen** (`SwRS-085` zu Bankzugangsdaten
|
||||||
|
ist der ausdrücklich als Hypothese geführte Fall). Negativbefunde aus einer Teilmenge tragen
|
||||||
|
keine belegte Aussage; wo sie dennoch für die Zielarchitektur wichtig sind, wurden sie in die
|
||||||
|
Prüfidee verschoben statt in die Aussage.
|
||||||
|
|
||||||
|
### 5.4 Offene Punkte ohne zugehörige Anforderung
|
||||||
|
|
||||||
|
Diese Punkte sind absichtlich **nicht** in `Hypothesen.md` aufgeführt, weil ihnen keine Anforderung
|
||||||
|
gegenübersteht:
|
||||||
|
|
||||||
|
- Die tatsächlich ausgeführten SQL-Anweisungen der benannten Abfragen (`NamedQueryEnums`) liegen
|
||||||
|
außerhalb des gelesenen C#-Codes; ihre Wirkung wurde aus Methodennamen und Parametern erschlossen.
|
||||||
|
- Die Zuordnung der 1.558 Datenbanktabellen zu den 165 Modulen wurde nur stichprobenartig
|
||||||
|
hergestellt. Etwa 1.400 Tabellen sind in dieser Analyse nicht einzeln betrachtet worden.
|
||||||
|
- Die 790 Skriptdateien unter `Administration/Scripts` wurden nicht inhaltlich ausgewertet; aus
|
||||||
|
ihnen ließe sich die fachliche Entwicklung des Datenmodells rekonstruieren.
|
||||||
|
- Von 15.554 C#-Dateien wurden rund 90 vollständig oder in wesentlichen Abschnitten gelesen. Die
|
||||||
|
übrigen sind über Verzeichnisstruktur, Klassennamen und Methodensignaturen erfasst.
|
||||||
|
- Ob der Sammelbenutzer `"InternalWebAccountUser"` (siehe `SwRS-121`) im Betrieb Rechte trägt, die
|
||||||
|
über die Portalfunktionen hinausgehen, konnte nicht festgestellt werden.
|
||||||
|
|
||||||
|
### 5.5 Warum Hypothesen geführt wurden — und warum nur fünf
|
||||||
|
|
||||||
|
Fünf von 363 Anforderungen (1,4 %) sind als Hypothese gekennzeichnet. Der niedrige Anteil ergibt
|
||||||
|
sich aus der gewählten Arbeitsweise: Wo ein Sachverhalt nicht bis zur durchsetzenden Stelle
|
||||||
|
verfolgt werden konnte, wurde in der Regel **keine** Anforderung geschrieben, sondern das Modul
|
||||||
|
flacher abgedeckt. Als Hypothese geführt wurden nur die fünf Fälle, in denen die Aussage für die
|
||||||
|
Zielarchitektur so wichtig ist, dass ihr Weglassen ein Risiko darstellt:
|
||||||
|
|
||||||
|
| ID | Warum trotz offener Frage geführt |
|
||||||
|
|---|---|
|
||||||
|
| `SyRS-005` | Preisfindung ist abrechnungsrelevant; ihr Fehlen im Zielsystem wäre ein Funktionsverlust. |
|
||||||
|
| `SyRS-055` | Der Quelltextkommentar belegt eine beabsichtigte, nicht umgesetzte Regel. |
|
||||||
|
| `SyRS-151` | Datenschutzrechtlich zwingende Anforderung, im heutigen Stand nachweislich nicht erfüllt. |
|
||||||
|
| `SwRS-055` | Der Sammelabschluss verändert Ticketzustände ohne Protokolleintrag. |
|
||||||
|
| `SwRS-085` | Sicherheitsrelevanter Negativbefund, der zu prüfen ist. |
|
||||||
|
|
||||||
|
Ein Anteil von 1,4 % ist für eine Codebasis dieser Größe niedrig. Er bedeutet nicht, dass wenige
|
||||||
|
Fragen offen sind, sondern dass die offenen Stellen überwiegend als **nicht geschriebene**
|
||||||
|
Anforderungen erscheinen — sichtbar in den 78 flach abgedeckten Modulen und in Abschnitt 5.4.
|
||||||
|
|
||||||
|
### 5.6 Wesentliche Befunde für die Neuimplementierung
|
||||||
|
|
||||||
|
**Sicherheit (unmittelbarer Handlungsbedarf):**
|
||||||
|
|
||||||
|
1. Kennwörter von Anwendungs- und Web-Benutzern werden als **ungesalzener SHA-1-Hash** gespeichert
|
||||||
|
(`SyRS-107`, `SyRS-122`, `SwRS-106`). Der Quelltext vermerkt die Schwäche selbst
|
||||||
|
(`// TODO the password should be salted!!!`).
|
||||||
|
2. Neue Web-Konten erhalten ihr **Kennwort im Klartext per E-Mail** (`SyRS-122`).
|
||||||
|
3. `AESCryptoLogic` fällt ohne übergebenen Schlüssel auf eine **im Quelltext hinterlegte Konstante**
|
||||||
|
zurück und leitet den Initialisierungsvektor aus demselben Hash wie den Schlüssel ab, wodurch er
|
||||||
|
je Schlüssel konstant ist (`SyRS-108`, `SwRS-107`).
|
||||||
|
4. Die Nummernvergabe setzt SQL-Abfragen aus **Zeichenketten** zusammen (`SwRS-095`).
|
||||||
|
5. Das **alte Zugangsdatenmodul speichert weder Kennwort noch Salt** und ist funktionslos
|
||||||
|
(`SyRS-131`, `StRS-048`).
|
||||||
|
6. Die Lizenzbegrenzung gleichzeitiger Anmeldungen ist über eine **prozesslokale Sperre** gelöst und
|
||||||
|
trägt bei mehreren Dienstinstanzen nicht (`SwRS-103`).
|
||||||
|
|
||||||
|
**Konsolidierung (Zielarchitektur):**
|
||||||
|
|
||||||
|
7. **Vier Datenhaltungen für installierte Geräte** — Stammblatt (`Stammdat`), Account-Gerät
|
||||||
|
(`AccountDevices`), Asset-Management-Gerät (`AssetManagementDevices`) und Kunden-Asset — plus
|
||||||
|
`GeraeteKopf` (`SyRS-140`, `SwRS-140` bis `SwRS-143`). Dies ist der im Auftrag genannte
|
||||||
|
Beispielfall und der größte Konsolidierungshebel.
|
||||||
|
8. **Zwei Geschäftspartnerstämme** im Parallelbetrieb, umgeschaltet über eine Einstellung
|
||||||
|
(`StRS-002`).
|
||||||
|
9. **Fünf Mechanismen zur Änderungsverfolgung** (Audit-Felder, Versionstabellen, `ReceiptLogBL`,
|
||||||
|
`ChangeTracking/History`, `AnlageLog`) — `SwRS-154`.
|
||||||
|
10. **Zwei Benachrichtigungsmechanismen** (`Notifications`, `NexusNotifications`) — `SwRS-128`.
|
||||||
|
11. **Drei Wege der Rechteprüfung** und **zwei Rechtesysteme** (interne Benutzer, Web-Konten) —
|
||||||
|
`SwRS-090`, `SwRS-120`.
|
||||||
|
12. **Zwei parallele Implementierungen** für Inventur (`SwRS-063`) und Nummernkreisauflösung
|
||||||
|
(`SwRS-093`), letztere über einen Merkmalsschalter erreichbar.
|
||||||
|
13. **Doppelte Datenzugriffsimplementierung je Modul** (`BLLogic`/`WSLogic`) — im Web-Zielsystem
|
||||||
|
entbehrlich (`SwRS-002`).
|
||||||
|
|
||||||
|
**Struktur:**
|
||||||
|
|
||||||
|
14. `ReceiptBL` umfasst **11.441 Zeilen** und bündelt sieben Belegarten; die Aufteilung nach dem
|
||||||
|
Vorbild von `Sales/Support` (49 nach Aufgabe geschnittene Klassen) ist im Zielsystem
|
||||||
|
naheliegend (`SwRS-010`, `SwRS-057`).
|
||||||
|
15. Fehlermeldungen stehen **deutschsprachig fest im Quelltext**, obwohl Ressourcendateien und eine
|
||||||
|
Zweisprachigkeitsvorgabe bestehen (`SwRS-129`).
|
||||||
|
|
||||||
|
### 5.7 Empfehlungen für eine Folge-Iteration
|
||||||
|
|
||||||
|
Nach Nutzen geordnet:
|
||||||
|
|
||||||
|
1. **Preisfindung und Kontenfindung bis zur entscheidenden Bedingung verfolgen.** `ReceiptItemBL`
|
||||||
|
(4.290 Zeilen) und `ReceiptPriceHelperBL` gezielt lesen. Beide Rangfolgen sind
|
||||||
|
abrechnungsrelevant und heute die einzigen bekannten Belegschwächen im Risikobereich
|
||||||
|
(`SyRS-005`, `SyRS-080`).
|
||||||
|
2. **`ReceiptBL.SaveReceipt` und `ForwardReceipt` vollständig auswerten.** Von 11.441 Zeilen wurden
|
||||||
|
rund 800 gelesen. Die Regionen in `ForwardReceipt` (Zeilen 2464–2860) benennen mindestens
|
||||||
|
fünfzehn weitere Übernahmeregeln, die je eine eigene Anforderung tragen könnten.
|
||||||
|
3. **Datenmodell systematisch erschließen.** Der Schema-Dump enthält 1.558 Tabellen; nur ein
|
||||||
|
Bruchteil ist erfasst. Eine Zuordnung Tabelle → Modul würde die 78 flach abgedeckten Module auf
|
||||||
|
Datenebene tragfähig machen.
|
||||||
|
4. **Die 790 Datenbankskripte auswerten.** Sie enthalten die Entwicklungsgeschichte des
|
||||||
|
Datenmodells und damit die beste verfügbare Ersatzquelle für die fehlende Change-Historie —
|
||||||
|
insbesondere für die Einstufung `Workaround` und `veraltet`.
|
||||||
|
5. **Das Rechtemodell vollständig ableiten.** `UserRightsConst.cs` enthält rund 800 Rechte in 60
|
||||||
|
Klassen; `ModuleRegistration.GetRightsForModule` erlaubt die maschinelle Ableitung einer
|
||||||
|
Rechtematrix Modul × Recht. Diese Matrix ist die Grundlage des Rollenmodells im Zielsystem.
|
||||||
|
6. **Die Weboberfläche vertiefen.** 460 Razor-Komponenten wurden nur über ihre Namen erfasst. Da
|
||||||
|
das Zielsystem eine Web-/SaaS-Anwendung ist, ist der bestehende Blazor-Teil die unmittelbarste
|
||||||
|
Vorlage.
|
||||||
|
7. **Die als `[Obsolete]` markierten Rechte und Module systematisch erfassen.** `UserRightsConst.cs`
|
||||||
|
enthält mehrere solcher Kennzeichnungen (`N13`, `Riversuite`, `CRM_ACTIVITY_MANAGEMENT`,
|
||||||
|
`DOCUMENT_CHECK`, `CHANGE_SYSTEM_SETTINGS`, `RIVERSUITE_ADMINISTRATION`). Sie sind belastbare
|
||||||
|
Kandidaten für die Einstufung `veraltet` und verkleinern den Migrationsumfang.
|
||||||
|
|
||||||
|
### 5.8 Grenzen dieser Analyse
|
||||||
|
|
||||||
|
- Alle Aussagen beruhen auf statischer Betrachtung. Ob eine im Code vorhandene Prüfung im Betrieb
|
||||||
|
tatsächlich erreicht wird, wurde nicht festgestellt.
|
||||||
|
- Zeilennummern beziehen sich auf den Dateistand im Arbeitsverzeichnis zum Zeitpunkt des Laufs.
|
||||||
|
- Die Modul-zu-Anforderung-Zuordnung in Abschnitt 3 ist maschinell erzeugt und in fünfzehn Fällen
|
||||||
|
manuell korrigiert; sie ist eine Näherung, keine exakte Zuordnung.
|
||||||
|
- Die Einstufung `Übernahmewürdigkeit` ist eine Einschätzung aus Codesicht. Sie ersetzt die
|
||||||
|
fachliche Bewertung durch Domänenexperten nicht (Schritt 7 der Methodenkette).
|
||||||
+284
@@ -0,0 +1,284 @@
|
|||||||
|
# Glossar
|
||||||
|
|
||||||
|
Domänenbegriffe, die in `StRS.md`, `SyRS.md` und `SwRS.md` verwendet werden. Technische Bezeichner
|
||||||
|
(Klassen, Methoden, Tabellen, Spalten) sind in ihrer Originalsprache belassen. Jeder Eintrag nennt
|
||||||
|
die Fundstelle, aus der die Bedeutung abgeleitet wurde.
|
||||||
|
|
||||||
|
## A
|
||||||
|
|
||||||
|
**Abholschein** — Belegart für Ware, die der Kunde selbst abholt. Tabellen `AbholKopf`/`AbholPos`,
|
||||||
|
Sicht `PickupLists`, Objektart 5, Nummernart `PickupList = 5`.
|
||||||
|
*Quelle: `NumberGroupEnum.cs`, `docs/reference/receipts/receipts-backend-architecture.md`.*
|
||||||
|
|
||||||
|
**Account** — Geschäftspartner im neuen Stammdatenmodell, der gleichzeitig Kunde, Lieferant und
|
||||||
|
Interessent sein kann. Tabelle `Accounts` mit den Rollenzuordnungen `AccountCustomers`,
|
||||||
|
`AccountSuppliers`, `AccountTypeToAccounts`. Löst den älteren, getrennten Kunden- (`Kunden`) und
|
||||||
|
Lieferantenstamm (`Kreditor`) ab.
|
||||||
|
*Quelle: `AccountBL.cs`, `SSMS_DB_SCHEMA.sql`.*
|
||||||
|
|
||||||
|
**AnlageArt** — Zahlenkodierung der Objektart im gemeinsamen Belegprotokoll `AnlageLog`:
|
||||||
|
1 = Angebot, 2 = Auftrag, 3 = Lieferschein, 4 = Rechnung, 5 = Abholschein, 6 = Gutschrift,
|
||||||
|
22 = Vertrag. Entspricht der Aufzählung `CentronObjectKindNumeric`.
|
||||||
|
*Quelle: `docs/reference/receipts/receipts-backend-architecture.md`.*
|
||||||
|
|
||||||
|
**Anwendungsart (`ApplicationKind`)** — Konfigurationsobjekt je anmeldefähiger Anwendung; bündelt
|
||||||
|
Lizenz-GUID, zusätzliche Lizenzen, erforderliches und ausschließendes Recht sowie die
|
||||||
|
Ticketgültigkeit.
|
||||||
|
*Quelle: `ApplicationKind.cs`, `docs/reference/security/licensing-system.md`.*
|
||||||
|
|
||||||
|
**Asset** — Beim Kunden installiertes Wirtschaftsgut. Im System in mindestens vier getrennten
|
||||||
|
Datenhaltungen geführt: Stammblatt (`Stammdat`), Account-Gerät (`AccountDevices`),
|
||||||
|
Asset-Management-Gerät (`AssetManagementDevices`) und Kunden-Asset (`CustomerAsset`).
|
||||||
|
Zusammenführungskandidat für das Zielsystem.
|
||||||
|
*Quelle: `MasterDataList.cs`, `AccountDevice.cs`, `CustomerAsset.cs`, `SSMS_DB_SCHEMA.sql`.*
|
||||||
|
|
||||||
|
**Ausgleichsartikel** — Systemartikel, über den ein Saldo zwischen vereinbarter und erbrachter
|
||||||
|
Leistung als Belegposition dargestellt wird. Getrennt für Vertrag
|
||||||
|
(`ArticleBL.GetContractBalanceArticle`) und Pauschale (`GetFlatrateBalanceArticle`).
|
||||||
|
*Quelle: `ArticleBL.cs`.*
|
||||||
|
|
||||||
|
## B
|
||||||
|
|
||||||
|
**Barcode-Zustand (`BarcodeState`)** — Zustand eines Einzelstücks: `InStock`, `InRequest`,
|
||||||
|
`InDeliveryList`, `InInvoice`, `ManuallyBookedOut`. Wird bei jeder Warenbewegung fortgeschrieben und
|
||||||
|
in `BarcodeHistoryBL` historisiert.
|
||||||
|
*Quelle: `RmaBL.cs`, `BarcodeHistoryBL.cs`.*
|
||||||
|
|
||||||
|
**Beleg (`Receipt`)** — Oberbegriff für die sieben Vorgangsarten Angebot, Auftrag, Lieferschein,
|
||||||
|
Rechnung, Gutschrift, Abholschein und Vertrag. Alle leiten von `ReceiptBase` ab und nutzen den
|
||||||
|
gemeinsamen Belegkern `ReceiptBL`.
|
||||||
|
*Quelle: `docs/reference/receipts/receipts-backend-architecture.md`.*
|
||||||
|
|
||||||
|
**Belegkette / Belegweiterführung (`Forward`)** — Überführung der Positionen eines Belegs in einen
|
||||||
|
Folgebeleg unter Übernahme von Konditionen, Adressen, Filiale, Provision und Mandat.
|
||||||
|
*Quelle: `ReceiptBL.ForwardReceipt`.*
|
||||||
|
|
||||||
|
**Belegprojekt-Layout (`ReceiptProjectLayoutItem`)** — Gliederung eines Belegs in Abschnitte, die
|
||||||
|
einzeln weitergeführt und ausgegeben werden können. Nicht zu verwechseln mit dem **CRM-Projekt**.
|
||||||
|
*Quelle: `ReceiptBL.ForwardReceipt`, `Receipts/Projects/`.*
|
||||||
|
|
||||||
|
**Belegversion** — Vollständiger Stand eines Belegs zu einem Ausgabezeitpunkt. Wird in
|
||||||
|
Versionstabellen (`RechKopfVersions` usw.) als strukturgleiche Kopie archiviert.
|
||||||
|
*Quelle: `ReceiptBL.CreateNewVersion`, `docs/reference/receipts/receipts-backend-architecture.md`.*
|
||||||
|
|
||||||
|
## C
|
||||||
|
|
||||||
|
**c-entron Nexus** — Blazor-Server-Webanwendung der Suite mit ServiceBoard (Ticketbearbeitung),
|
||||||
|
Kundenportal (WebCart), WebOffer, Dokumentensignatur und Verwaltungsbereich. Auch „c-entron Web".
|
||||||
|
*Quelle: `README.md`, `src/nexus/CentronNexus/`.*
|
||||||
|
|
||||||
|
**`CentronObjectKindNumeric`** — Systemweite Aufzählung der Objektarten. Grundlage für alle
|
||||||
|
objektartübergreifenden Referenzen (Protokoll, Aufgaben, Dokumente, Suchindex, Fremdschlüssel).
|
||||||
|
*Quelle: `IndexSearchBL.cs`, `CentronModule.cs`.*
|
||||||
|
|
||||||
|
**Concurrency-GUID (`ConcurrencyControlGuid`)** — Nebenläufigkeitskennung am Beleg. Punktuelle
|
||||||
|
Änderungen werden nur ausgeführt, wenn die übergebene mit der gespeicherten Kennung übereinstimmt.
|
||||||
|
*Quelle: `ReceiptBL.cs`, `docs/reference/receipts/receipts-backend-architecture.md`.*
|
||||||
|
|
||||||
|
## D
|
||||||
|
|
||||||
|
**DSGVO-Modul** — Funktionsbereich zur Wahrung der Betroffenenrechte: Ermittlung und Löschung von
|
||||||
|
Kontaktdaten sowie Bereinigung nicht mehr benötigter Datenbestände. Eigener Rechtezweig
|
||||||
|
`UserRightsConst.DsgvoModule`.
|
||||||
|
*Quelle: `DataSecurityBL.cs`, `UserRightsConst.cs`.*
|
||||||
|
|
||||||
|
## E
|
||||||
|
|
||||||
|
**EDI** — Elektronischer Datenaustausch mit Distributoren. Je Distributor (ALSO, AlsoCH, Alltron,
|
||||||
|
Komsa, EGIS, Concerto) eine eigene Implementierung, vermittelt über `EDIDispatcherBL` und
|
||||||
|
protokolliert in `EDILogBL`.
|
||||||
|
*Quelle: `src/backend/Centron.BL/EDI/`, `docs/reference/edi/edi-architecture.md`.*
|
||||||
|
|
||||||
|
**Einschränkendes Recht (restricting right)** — Recht, das ein bereits vergebenes Basisrecht
|
||||||
|
begrenzt, etwa auf eigene Objekte (`SHOW_HELPDESK_ONLY_OWN`) oder die eigene Filiale
|
||||||
|
(`EDIT_INVOICE_ONLY_OWN_BRANCH`).
|
||||||
|
*Quelle: `CentronRights.md`, `ReceiptBL.CanUserEditReceipt`.*
|
||||||
|
|
||||||
|
## F
|
||||||
|
|
||||||
|
**Filiale (`Filiale`, `BranchI3D`)** — Organisatorische Einheit unterhalb des Mandanten. Jeder Beleg
|
||||||
|
trägt eine Filiale; Nummernkreise, Erlöskonten und Rechte können filialbezogen sein.
|
||||||
|
*Quelle: `MandatoryBL.cs`, `BranchBL.cs`, `SSMS_DB_SCHEMA.sql`.*
|
||||||
|
|
||||||
|
## G
|
||||||
|
|
||||||
|
**Gutschrift** — Belegart zur wertmäßigen Korrektur einer Rechnung. Tabellen `GutKopf`/`GutPos`,
|
||||||
|
Sicht `CreditVouchers`, Objektart 6.
|
||||||
|
*Quelle: `docs/reference/receipts/receipts-backend-architecture.md`, `UserRightsConst.cs`.*
|
||||||
|
|
||||||
|
## H
|
||||||
|
|
||||||
|
**Helpdesk / Ticket** — Servicevorgang zu einem Kundenanliegen. Tabelle `hlpdsk_requests`,
|
||||||
|
klassifiziert über `hlpdsk_typen`, `hlpdsk_kategorien`, `hlpdsk_status`, `hlpdsk_prioritaeten`.
|
||||||
|
*Quelle: `HelpdeskBL.cs`, `SSMS_DB_SCHEMA.sql`.*
|
||||||
|
|
||||||
|
**Hotline-Masterkey** — Zentraler Schlüssel aus der Konfigurationsdatenbank, mit dem der
|
||||||
|
Passwort-Manager Kundenzugangsdaten ver- und entschlüsselt.
|
||||||
|
*Quelle: `PasswordManagerBL.cs`, `CentronConfigurationDbBL.GetHotlineMasterKey`.*
|
||||||
|
|
||||||
|
## I
|
||||||
|
|
||||||
|
**`I3D`** — Durchgängiger Name des Primärschlüssels aller persistierten Entitäten.
|
||||||
|
*Quelle: `BaseEntity.cs`, `PersistedEntity.cs`.*
|
||||||
|
|
||||||
|
**Inventur** — Zählprozess des Lagerbestands, gegliedert in Zählgruppen; Lager werden einzeln, die
|
||||||
|
Inventur insgesamt abgeschlossen.
|
||||||
|
*Quelle: `InventoryNewBL.cs`.*
|
||||||
|
|
||||||
|
## K
|
||||||
|
|
||||||
|
**Klickabrechnung** — Mengenabhängige Vertragsabrechnung nach Zählerständen von Ausgabegeräten
|
||||||
|
(Managed Print Services). Zählerstand am Stammblatt (`CounterDevice`), Einstellungen unter
|
||||||
|
`ClickBillingSettingsController`.
|
||||||
|
*Quelle: `MasterDataList.cs`, `ModuleRegistration.cs`.*
|
||||||
|
|
||||||
|
**Kommissionierung** — Bereitstellung der Auftragspositionen im Lager, vollständig oder als
|
||||||
|
Teilkommissionierung mit eigener Lieferadresse.
|
||||||
|
*Quelle: `OrderCommissionBL.cs`, `PartialCommissionOrderBL.cs`, `ReceiptBL.UpdateReceiptQuantityPicked`.*
|
||||||
|
|
||||||
|
**Kontingent (Vertrag)** — Vereinbartes Leistungsvolumen eines Vertrags in Stunden oder Betrag.
|
||||||
|
Verbrauch, Saldo, Restwert und Grenzwert werden als getrennte Vertragsattribute geführt.
|
||||||
|
*Quelle: `ReceiptContract.cs`, `ContractBL.GetContingentRest`.*
|
||||||
|
|
||||||
|
## L
|
||||||
|
|
||||||
|
**Lizenz** — GUID, die eine Anwendung oder eine Einzelfunktion freischaltet. Kann Anzahl,
|
||||||
|
Gültigkeitsdatum und maximale Programmversion tragen. Die Sammellizenz `LicenseGuids.Centron`
|
||||||
|
schließt zahlreiche Einzellizenzen ein.
|
||||||
|
*Quelle: `LicenseGuids.cs`, `LicenseManager.cs`, `docs/reference/security/licensing-system.md`.*
|
||||||
|
|
||||||
|
## M
|
||||||
|
|
||||||
|
**Mahnstufe (`DunningLevel`)** — Stand des Mahnverfahrens einer Rechnung: `None`, `Level1`,
|
||||||
|
`Level2`, `Level3`. Je Stufe werden Datum und ausführender Benutzer am Beleg gespeichert.
|
||||||
|
*Quelle: `DunningRunBL.cs`.*
|
||||||
|
|
||||||
|
**Mandant (`Mandant`)** — Oberste organisatorische Einheit; genau einer ist als Standardmandant
|
||||||
|
gekennzeichnet (`Standard = 1 AND Status = 1`).
|
||||||
|
*Quelle: `MandatoryBL.cs`.*
|
||||||
|
|
||||||
|
**Mitarbeiterartikel** — Artikel, über den die Leistung eines Mitarbeiters bewertet und abgerechnet
|
||||||
|
wird. Zeitauswertungen und das Recht `OWN_TIME_EDIT` beziehen sich auf ihn.
|
||||||
|
*Quelle: `EmployeeArticleBL.cs`, `HelpdeskTimerBL.GetEmployeeTimeStatistics`, `CentronRights.md`.*
|
||||||
|
|
||||||
|
**MSP (Managed Service Provider)** — Geschäftsmodell mit laufend abgerechneten Dienstleistungen.
|
||||||
|
Im System als eigene Auswertungs- und Sammelmodule (`MspStatistics`, `MspCollectors`,
|
||||||
|
`MSPLicensesCompare`) sowie als Kennzeichen `IsMsp` am Stammblatt abgebildet.
|
||||||
|
*Quelle: `ModuleRegistration.cs`, `MasterDataList.cs`.*
|
||||||
|
|
||||||
|
## N
|
||||||
|
|
||||||
|
**Nummernkreis (`Nummernkreis`, `NumberGroup`)** — Fortlaufende Nummernvergabe je Nummernart
|
||||||
|
(`NumberGroupEnum`, über 30 Arten), aufgelöst über Mitarbeiterfiliale, Mandantsfiliale und
|
||||||
|
Standardmandant.
|
||||||
|
*Quelle: `NumberGroupBL.cs`, `MandatoryBL.cs`, `NumberGroupEnum.cs`.*
|
||||||
|
|
||||||
|
## O
|
||||||
|
|
||||||
|
**OPOS** — Offene-Posten-Verwaltung; Übersicht der noch nicht ausgeglichenen Rechnungen. Zugriff
|
||||||
|
über das Recht `Controlling.Finances.Dunning`.
|
||||||
|
*Quelle: `OposBL.cs`.*
|
||||||
|
|
||||||
|
## P
|
||||||
|
|
||||||
|
**Passwort-Manager** — Verschlüsselte Ablage von Zugangsdaten der Kundensysteme über Zusatzfelder
|
||||||
|
vom Typ `EncryptedText`. Löst das ältere Modul `PasswordManagementArea` ab, das im Modulkatalog als
|
||||||
|
„obsolate" gekennzeichnet ist.
|
||||||
|
*Quelle: `PasswordManagerBL.cs`, `ModuleRegistration.cs`.*
|
||||||
|
|
||||||
|
**Provisionsschema** — Regelwerk zur Ermittlung des Provisionsanspruchs eines Vertriebsmitarbeiters,
|
||||||
|
ergänzt um Mitarbeiterziele und Provisionsstufen.
|
||||||
|
*Quelle: `ReceiptProvisionSchemaBL.cs`, `ReceiptProvisionEmployeeGoalBL.cs`, `ReceiptProvisionEmployeeLevelBL.cs`.*
|
||||||
|
|
||||||
|
## R
|
||||||
|
|
||||||
|
**Rechtegruppe (`Sichgrup`/`Sichmemb`/`Sichtrus`)** — Rechte werden ausschließlich über Gruppen
|
||||||
|
vergeben; `Sichmemb` verknüpft Benutzer und Gruppe, `Sichtrus` Gruppe und Recht.
|
||||||
|
*Quelle: `AppRightsBL.CheckRightsFromUser`.*
|
||||||
|
|
||||||
|
**RMA** — Retouren-, Reparatur- und Tauschvorgang mit eigener Zustandsverfolgung je Artikel und
|
||||||
|
Seriennummer. Eigene Nummernarten für Rücksendung, Reparatur, Reparatureingang und RMA-Nummer.
|
||||||
|
*Quelle: `RmaBL.cs`, `NumberGroupEnum.cs`.*
|
||||||
|
|
||||||
|
## S
|
||||||
|
|
||||||
|
**Self-Care-Formular** — Vom Kunden im Portal ausfüllbares Formular, dessen Felder im zugehörigen
|
||||||
|
Ticketmuster definiert sind und aus dem ein Ticket entsteht.
|
||||||
|
*Quelle: `SelfCareBL.cs`, `SelfCareFormFieldGrid.razor`.*
|
||||||
|
|
||||||
|
**Sitzungsticket (`Ticket`)** — Nach erfolgreicher Anmeldung ausgegebene Sitzungskennung mit
|
||||||
|
anwendungsabhängiger Gültigkeit (Standard 30 Minuten, Monitoring-Konnektor 5 Minuten, Sonderfall
|
||||||
|
24 Stunden). Nicht zu verwechseln mit dem **Helpdesk-Ticket**.
|
||||||
|
*Quelle: `TicketBL.cs`.*
|
||||||
|
|
||||||
|
**Sonderpreis** — Kundenindividueller Artikelpreis. Zugleich die Artikelquelle des Kundenportals.
|
||||||
|
*Quelle: `CustomerSpecialArticleBL.cs`, `README.md`.*
|
||||||
|
|
||||||
|
**Stammblatt (`Stammdat`, `MasterDataList`)** — Geräteakte mit Seriennummer, Herkunftsbeleg,
|
||||||
|
Vertragsbezug, Zählerstand, Standortadresse und eigenem Dokumentenverzeichnis. Historisch für
|
||||||
|
Drucker geführt; im Zielsystem mit den übrigen Gerätedatenhaltungen zu einem Asset-Konzept
|
||||||
|
zusammenzuführen.
|
||||||
|
*Quelle: `MasterDataList.cs`, `ContractBL.GetMasterDataListFromContract`.*
|
||||||
|
|
||||||
|
**Systemartikel** — Artikel mit fest zugewiesener technischer Rolle (Fracht, Kundenrabatt,
|
||||||
|
Kontingentsaldo, Pauschalsaldo, Fremdartikel, Neuartikel, Gutschein), aufgelöst über eigene Methoden
|
||||||
|
in `ArticleBL`.
|
||||||
|
*Quelle: `ArticleBL.cs`.*
|
||||||
|
|
||||||
|
## T
|
||||||
|
|
||||||
|
**Teilkommission (`PartialCommissionOrder`)** — Teilmenge eines Auftrags, die getrennt kommissioniert
|
||||||
|
und mit eigener Lieferadresse ausgeliefert wird.
|
||||||
|
*Quelle: `PartialCommissionOrderBL.cs`, `ReceiptBL.ForwardReceipt`.*
|
||||||
|
|
||||||
|
**Ticketmuster (`TicketPattern`)** — Vorlage für die automatische oder formulargestützte
|
||||||
|
Ticketerzeugung mit acht Konfigurationsdimensionen (Allgemein, Kunde, intern, Checklisten,
|
||||||
|
Formulare, Mailvorlage, Eigenschaften, Skripte, Webformular).
|
||||||
|
*Quelle: `Management/TicketPatterns/Components/`.*
|
||||||
|
|
||||||
|
## U
|
||||||
|
|
||||||
|
**Übernahmeoptionen (`InsertReceiptTakeoverOptions`)** — Steuerung, welche Bestandteile beim
|
||||||
|
Weiterführen eines Belegs in den Folgebeleg übernommen werden.
|
||||||
|
*Quelle: `ReceiptBL.ForwardReceipt`.*
|
||||||
|
|
||||||
|
## V
|
||||||
|
|
||||||
|
**Vertrag (`ReceiptContract`)** — Belegart für dauerhafte Leistungsvereinbarungen mit
|
||||||
|
Abrechnungsintervall, Laufzeit, automatischer Verlängerung und Kontingent. Tabellen
|
||||||
|
`VertragKopf`/`VertragPos`, Objektart 22.
|
||||||
|
*Quelle: `ReceiptContract.cs`, `docs/reference/receipts/contracts-backend.md`.*
|
||||||
|
|
||||||
|
## W
|
||||||
|
|
||||||
|
**WebAccount** — Kundenzugang zum Webportal mit eigenem Rechtesystem (`WebRights`,
|
||||||
|
`WebRightsCategories`, `WebAccountsRights`), getrennt von den internen Benutzerkonten (`AppUser`).
|
||||||
|
*Quelle: `WebAccountBL.cs`, `AppRightsBL.CheckWebRightsFromUser`.*
|
||||||
|
|
||||||
|
**WebCart** — Kundenportal mit Shop, Belegübersicht, Verträgen, Tickets, Formularen und Dokumenten.
|
||||||
|
Die Artikel stammen aus den Sonderpreisen des jeweiligen Kunden.
|
||||||
|
*Quelle: `src/nexus/CentronNexus/WebCart/`, `README.md`.*
|
||||||
|
|
||||||
|
**Webbeleg (`WebReceipt`)** — Über einen Token bereitgestellter Beleg, den der Kunde ohne Anmeldung
|
||||||
|
freigeben oder ablehnen kann; führt einen eigenen Zustand (`WebReceiptState`).
|
||||||
|
*Quelle: `ReceiptBL.ChangeWebReceiptState`.*
|
||||||
|
|
||||||
|
## Z
|
||||||
|
|
||||||
|
**Zählerstand (`CounterDevice`)** — Am Stammblatt geführter Zählerstand eines Ausgabegeräts;
|
||||||
|
Grundlage der Klickabrechnung. Kann manuell erfasst oder über die docuFORM-Schnittstelle bezogen
|
||||||
|
werden.
|
||||||
|
*Quelle: `MasterDataList.cs`, `Centron.Api.docuFORM`.*
|
||||||
|
|
||||||
|
**Zahlungskondition (`Zahkond`)** — Stammdatensatz mit Zahlungsziel und Skontoregelung; Grundlage
|
||||||
|
für das Fälligkeitsdatum eines Belegs.
|
||||||
|
*Quelle: `SSMS_DB_SCHEMA.sql`, `ReceiptBL.UpdatePaymentDueDate`.*
|
||||||
|
|
||||||
|
**ZUGFeRD / XRechnung** — Formate der elektronischen Rechnung. Ein- und ausgehend unterstützt;
|
||||||
|
Import auch über die REST-Schnittstelle.
|
||||||
|
*Quelle: `ZUGFeRD_BL.cs`, `ZugferdImportController.cs`, `docs/guides/development/xrechnung.md`.*
|
||||||
|
|
||||||
|
**Zuschlagssatz (`HourlySurchargeRate`)** — Zeitfensterabhängiger Aufschlag auf den Stundensatz
|
||||||
|
(Nacht, Wochenende, Feiertag). Ein Zeiteintrag wird abschnittsweise mit den überschneidenden Sätzen
|
||||||
|
bewertet.
|
||||||
|
*Quelle: `HelpdeskTimerBL.CalculateHourlySurchargeRateOverlaps`.*
|
||||||
+141
@@ -0,0 +1,141 @@
|
|||||||
|
# Hypothesen
|
||||||
|
|
||||||
|
Diese Datei enthält **genau** die Anforderungen, die in `StRS.md`, `SyRS.md` und `SwRS.md` mit
|
||||||
|
`Status: HYPOTHESE` und der Inline-Markierung `[HYPOTHESE]` gekennzeichnet sind — keine weiteren
|
||||||
|
freien Fragen. Offene Punkte ohne zugehörige Anforderung sind in der Selbstbewertung des
|
||||||
|
`Analysebericht.md` (Abschnitt 5) aufgeführt.
|
||||||
|
|
||||||
|
**Anzahl: 5** von 360 Anforderungen (1,4 %).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## SyRS-005 — Mehrstufige Preisquellen mit definierter Rangfolge
|
||||||
|
|
||||||
|
| | |
|
||||||
|
|---|---|
|
||||||
|
| **Ebene** | SyRS |
|
||||||
|
| **Typ** | funktional |
|
||||||
|
| **Übernahmewürdigkeit** | übernehmen |
|
||||||
|
|
||||||
|
**Belegte Beobachtung:** Es bestehen mindestens vier konkurrierende Preisquellen — `ActionPriceBL`
|
||||||
|
(Aktionspreise), `ArticleVolumePricesBL` (Staffelpreise), kundenbezogene Sonderpreise
|
||||||
|
(`Accounts/SpecialPrices/`, `CustomerSpecialArticleBL`) und `ProductMatrixBL`. Die Zusammenführung
|
||||||
|
erfolgt in `ReceiptItemBL` (4.290 Zeilen) und `ReceiptPriceHelperBL` (130 Zeilen).
|
||||||
|
|
||||||
|
**Offene Frage:** In welcher Rangfolge werden die vier Preisquellen ausgewertet, und welche gewinnt
|
||||||
|
bei gleichzeitiger Gültigkeit?
|
||||||
|
|
||||||
|
**Was zur Bestätigung fehlt:** Eine zeilenweise Auswertung der Preisermittlung in `ReceiptItemBL`
|
||||||
|
bis zu der Bedingung, die die Quelle auswählt. In dieser Analyse wurde nur die API-Oberfläche der
|
||||||
|
beteiligten Klassen erfasst, nicht der Entscheidungspfad.
|
||||||
|
|
||||||
|
**Warum als Hypothese geführt:** Die Preisfindung ist abrechnungsrelevant. Ohne benannte
|
||||||
|
durchsetzende Stelle darf die Aussage nach der Regel zur risikobasierten Priorisierung nicht als
|
||||||
|
belegt geführt werden.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## SyRS-055 — Ticketabschluss trotz offener RMA
|
||||||
|
|
||||||
|
| | |
|
||||||
|
|---|---|
|
||||||
|
| **Ebene** | SyRS |
|
||||||
|
| **Typ** | funktional |
|
||||||
|
| **Übernahmewürdigkeit** | übernehmen |
|
||||||
|
|
||||||
|
**Belegte Beobachtung:** `HelpdeskCloseBL.CanCloseHelpdesk(int helpdeskI3D)` (Zeilen 159-167)
|
||||||
|
enthält ausschließlich eine Nichtnull-Prüfung des Parameters, den Kommentar
|
||||||
|
`//Todo: if rma exists check if finished` und die Rückgabe `true`. Die Methode ist damit die
|
||||||
|
vorgesehene, aber leere Prüfstelle.
|
||||||
|
|
||||||
|
**Offene Frage:** Soll der Abschluss eines Tickets bei einem offenen RMA-Vorgang verhindert werden?
|
||||||
|
|
||||||
|
**Was zur Bestätigung fehlt:** Eine fachliche Aussage darüber, ob die im Kommentar vermerkte Regel
|
||||||
|
gewollt ist oder bewusst nicht umgesetzt wurde. Aus den Artefakten ist nur ersichtlich, dass sie
|
||||||
|
vorgesehen war.
|
||||||
|
|
||||||
|
**Warum als Hypothese geführt:** Der Kommentar belegt eine Absicht, nicht eine durchgesetzte Regel.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## SyRS-151 — Nicht implementierte Löschpfade im Datenschutzmodul
|
||||||
|
|
||||||
|
| | |
|
||||||
|
|---|---|
|
||||||
|
| **Ebene** | SyRS |
|
||||||
|
| **Typ** | Sicherheit |
|
||||||
|
| **Übernahmewürdigkeit** | übernehmen |
|
||||||
|
|
||||||
|
**Belegte Beobachtung:** `DataSecurityBL.DoDeleteCustomer(int i3d, bool isReferenceDelete)` wirft
|
||||||
|
`new NotImplementedException("DoDeleteCustomer is not ready for use!")` (Zeile 856-858);
|
||||||
|
`DoDeleteSupplier` ist analog angelegt. In `DsgvoDeleteRightDeleteContacts` sind die Aufrufe für
|
||||||
|
Kunde, Lieferant, Kontaktmanagement-Kontakt und Account auskommentiert (Zeilen 803-814), ebenso die
|
||||||
|
zugehörigen Anonymisierungs-SQL-Anweisungen (Zeilen 863-903).
|
||||||
|
|
||||||
|
**Offene Frage:** Warum sind die Löschpfade für vollständige Geschäftspartner deaktiviert — aus
|
||||||
|
fachlichen Bedenken wegen der Referenzintegrität zu Belegen, oder weil die Entwicklung nicht
|
||||||
|
abgeschlossen wurde? Und wie wird ein Löschbegehren, das einen ganzen Geschäftspartner betrifft,
|
||||||
|
heute bearbeitet?
|
||||||
|
|
||||||
|
**Was zur Bestätigung fehlt:** Eine fachliche Festlegung, welche Datensätze bei einem Löschbegehren
|
||||||
|
zu anonymisieren sind und welche aus handels- und steuerrechtlichen Aufbewahrungsgründen erhalten
|
||||||
|
bleiben müssen.
|
||||||
|
|
||||||
|
**Warum als Hypothese geführt:** Die Anforderung ist datenschutzrechtlich zwingend, im heutigen
|
||||||
|
Stand aber nachweislich nicht erfüllt. Sie wird als offener Punkt geführt, nicht als belegte
|
||||||
|
Systemeigenschaft.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## SwRS-055 — Sammelabschluss von Tickets aus der Wartung
|
||||||
|
|
||||||
|
| | |
|
||||||
|
|---|---|
|
||||||
|
| **Ebene** | SwRS |
|
||||||
|
| **Typ** | funktional |
|
||||||
|
| **Übernahmewürdigkeit** | übernehmen |
|
||||||
|
|
||||||
|
**Belegte Beobachtung:** `HelpdeskCloseBL.CloseHelpdesk(IList<HelpdeskCompact> helpdesks, AppUser currentUser)`
|
||||||
|
(Zeilen 108-118) führt ausschließlich die benannte Abfrage
|
||||||
|
`NamedQueryEnums.Helpdesk.CloseHelpdesksFromMaintenance` mit dem Abschlussstatus und einer Liste von
|
||||||
|
IDs aus und gibt stets `Result.AsSuccess()` zurück. Die beim Einzelabschluss
|
||||||
|
(`CloseHelpdesk(AppUser, int helpdeskI3D, …)`) ausgeführten Folgeaktionen — Löschen der zugehörigen
|
||||||
|
Aufgaben, Historieneintrag `HelpdeskHistoryType.Close`, Kundenaktivität, Benachrichtigung —
|
||||||
|
unterbleiben.
|
||||||
|
|
||||||
|
**Offene Frage:** Ist das Auslassen der Folgeaktionen beim Sammelabschluss fachlich gewollt (etwa
|
||||||
|
weil es sich um eine reine Datenbereinigung handelt), oder handelt es sich um eine Lücke in der
|
||||||
|
Nachvollziehbarkeit?
|
||||||
|
|
||||||
|
**Was zur Bestätigung fehlt:** Die Aufrufstellen des Sammelabschlusses und die fachliche Absicht des
|
||||||
|
Wartungsvorgangs. Der Name der benannten Abfrage („FromMaintenance") deutet auf eine Bereinigung
|
||||||
|
hin, belegt sie aber nicht.
|
||||||
|
|
||||||
|
**Warum als Hypothese geführt:** Der Sammelabschluss verändert Ticketzustände ohne Protokolleintrag.
|
||||||
|
Ob das zulässig ist, lässt sich aus den Artefakten nicht entscheiden.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## SwRS-085 — Bankzugangsdaten der finAPI-Anbindung
|
||||||
|
|
||||||
|
| | |
|
||||||
|
|---|---|
|
||||||
|
| **Ebene** | SwRS |
|
||||||
|
| **Typ** | Sicherheit |
|
||||||
|
| **Übernahmewürdigkeit** | übernehmen |
|
||||||
|
|
||||||
|
**Belegte Beobachtung:** `Centron.APIs.FinAPI/Data/` modelliert `AccessToken`, `Account`,
|
||||||
|
`AccountCapability`, `AccountInterface`, `AccountInterfacePaymentCapabilities`, `AccountList`,
|
||||||
|
`AccountParams` und `AccountReference`. Eine Klasse für dauerhaft gespeicherte Bankzugangsdaten des
|
||||||
|
Kunden (Zugangskennung, PIN) besteht in dieser Bibliothek nicht.
|
||||||
|
|
||||||
|
**Offene Frage:** Speichert das System an anderer Stelle — etwa im Zweig `Finances/OnlineBanking` oder
|
||||||
|
in der Datenbank — Bankzugangsdaten des Kunden im Klartext oder verschlüsselt?
|
||||||
|
|
||||||
|
**Was zur Bestätigung fehlt:** Eine vollständige Durchsicht des Zweigs `Finances/OnlineBanking` sowie
|
||||||
|
eine Suche im Datenbankschema nach Feldern für Bankzugangsdaten. Die Abwesenheit einer entsprechenden
|
||||||
|
Klasse in der API-Bibliothek ist kein Beweis für die Abwesenheit im Gesamtsystem.
|
||||||
|
|
||||||
|
**Warum als Hypothese geführt:** Die Aussage ist sicherheitsrelevant und stützt sich auf das Fehlen
|
||||||
|
eines Artefakts, nicht auf eine durchgesetzte Regel. Ein Negativbefund aus einer Teilmenge trägt die
|
||||||
|
Aussage nicht.
|
||||||
+1362
File diff suppressed because it is too large
Load Diff
+3558
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user