From 3d5b691bfaf257d6d8f0faca989692396002a073 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christoph=20Schw=C3=B6rer?= Date: Thu, 27 Aug 2026 08:03:00 +0200 Subject: [PATCH] Iteration 3: Modell- und Modusraster erweitert, Skill 7.0.0, V2/V3 vorbereitet Neue gueltige Zellen in Iteration 3 - claude-opus-5/solo/high: 363 Anforderungen, 99,7 % mit Primaerbeleg, Belege je Anforderung Median 2,0, 38,1 Mio. Tokens - claude-fable-5/solo/high: 241 Anforderungen, 98,3 % mit Primaerbeleg, 89,0 % PRIMAER-Anteil, vollstaendig regelkonform, 30,6 Mio. Tokens Damit sind 6 von 12 Zellen des Rasters belegt. Zwei Befunde daraus: Die Belegdichte folgt dem Modell, nicht dem Effort. Opus erreicht Median 2,0 auch auf high; alle 44 Sonnet-Laeufe lagen bei 1,0. max hebt Opus auf 3,0. Die frueher dem Effort zugeschriebene Verdopplung ist damit eingegrenzt. Die Fable-Modellverletzung ist reproduziert und abgegrenzt. Bei builtin laufen die Subagenten auf claude-opus-5[1m] statt Fable (zweiter Fall nach Iteration 1), bei solo dagegen sauber. Nicht das Modell ist die Ursache, sondern Fable in Kombination mit Delegation. Fehlmessungen, vollstaendig protokolliert - vier 429-Abbrueche (Session-Kontingent) aus dem Parallelblock 19:59; drei davon mit Teilbestand, einer ohne Ergebnis - opus-5/builtin/high zum dritten Mal gescheitert: 790,7 Mio. Tokens ueber drei Anlaeufe ohne Artefakt. Zelle mit dieser Prompt-Version nicht messbar. Skill 7.0.0 (MAJOR) - Isolationsmechanismus modusabhaengig: --safe-mode schaltet MCP-Server und Custom-Agenten ab und ist mit V2/V3 unvereinbar. Smoke-Test verifiziert: mit Flag spawned=0, ohne Flag spawned=2. Ersatz fuer custom/MCP: --strict-mcp-config plus --disallowedTools Skill WebSearch WebFetch SlashCommand. - 6.1.0: Pflichtpruefung leeres Ergebnisverzeichnis = Fehlmessung unabhaengig von is_error; CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0; Protokollfeld Gueltigkeit - extract-subagenten.py: Start-Quittung wird nicht mehr als Ertragsmass ausgewiesen Versuch 2 und 3 vorbereitet - Prompt-Kette V1 -> V2 (02-A, angepasst an Agentendateien) -> V3 (02-B, MCP) - V2: acht Rollen inkl. nicht delegierendem ISO-29148-Orchestrator - V3: elf Rollen, fuenf Werkzeugserver, neue Belegklasse LAUFZEIT Ablaufprotokoll um Phase 6 und 7 sowie die Vorbereitung von V2/V3 ergaenzt. Co-Authored-By: Claude Opus 5 (1M context) --- .claude/skills/run-experiment/SKILL.md | 166 +- .../run-experiment/extract-subagenten.py | 17 +- .../run-experiment/prepare-codex-workspace.py | 207 + Versuche/AblaufProtokoll.md | 207 +- .../Ergebnisse/Analysebericht.md | 252 + .../Protokoll.md | 89 + .../RawResult.json | 1 + .../Stderr.log | 0 .../_meta/before.txt | 1 + .../_meta/combined_prompt.md | 178 + .../_meta/endzeit.txt | 1 + .../_meta/startzeit.txt | 1 + .../Ergebnisse/Analysebericht.md | 195 + .../Ergebnisse/StRS.md | 600 ++ .../Ergebnisse/SyRS.md | 1691 ++++ .../Protokoll.md | 80 + .../RawResult.json | 1 + .../Stderr.log | 0 .../_meta/anforderungen.json | 2144 +++++ .../_meta/anforderungen.md | 65 + .../_meta/before.txt | 1 + .../_meta/combined_prompt.md | 177 + .../_meta/endzeit.txt | 1 + .../_meta/startzeit.txt | 1 + .../Ergebnisse/Analysebericht.md | 492 ++ .../Ergebnisse/Glossar.md | 47 + .../Ergebnisse/Hypothesen.md | 23 + .../Ergebnisse/StRS.md | 669 ++ .../Ergebnisse/SwRS.md | 3186 ++++++++ .../Ergebnisse/SyRS.md | 1030 +++ .../Ergebnisse/Traceability.md | 60 + .../Protokoll.md | 197 + .../RawResult.json | 1 + .../Stderr.log | 0 .../_ledger.tsv | 242 + .../_meta/after.txt | 0 .../_meta/anforderungen.json | 4623 +++++++++++ .../_meta/anforderungen.md | 69 + .../_meta/before.txt | 1 + .../_meta/combined_prompt.md | 177 + .../_meta/endzeit.txt | 1 + .../_meta/startzeit.txt | 1 + .../_modcounts.txt | 150 + .../_report_part2.md | 192 + .../_report_part3.md | 83 + .../Protokoll.md | 134 +- .../Protokoll.md | 91 + .../Protokoll.md | 90 + .../RawResult.json | 1 + .../Stderr.log | 0 .../_meta/before.txt | 1 + .../_meta/combined_prompt.md | 178 + .../_meta/endzeit.txt | 1 + .../_meta/startzeit.txt | 1 + .../Ergebnisse/Analysebericht.md | 181 + .../Ergebnisse/StRS.md | 2088 +++++ .../Protokoll.md | 79 + .../RawResult.json | 1 + .../Stderr.log | 0 .../_meta/anforderungen.json | 1352 +++ .../_meta/anforderungen.md | 64 + .../_meta/before.txt | 1 + .../_meta/combined_prompt.md | 177 + .../_meta/endzeit.txt | 1 + .../_meta/startzeit.txt | 1 + .../Ergebnisse/Analysebericht.md | 876 ++ .../Ergebnisse/Glossar.md | 284 + .../Ergebnisse/Hypothesen.md | 141 + .../Ergebnisse/StRS.md | 1362 +++ .../Ergebnisse/SwRS.md | 3558 ++++++++ .../Ergebnisse/SyRS.md | 2807 +++++++ .../Ergebnisse/Traceability.md | 330 + .../Protokoll.md | 184 + .../RawResult.json | 1 + .../Stderr.log | 0 .../_meta/after.txt | 0 .../_meta/anforderungen.json | 7276 +++++++++++++++++ .../_meta/anforderungen.md | 65 + .../_meta/before.txt | 1 + .../_meta/combined_prompt.md | 177 + .../_meta/endzeit.txt | 1 + .../_meta/startzeit.txt | 1 + Versuche/Versuch_02/01_Agents.json | 34 + Versuche/Versuch_02/01_Prompt.md | 172 + Versuche/Versuch_02/README.md | 147 + Versuche/Versuch_03/01_Agents.json | 46 + Versuche/Versuch_03/01_MCP.json | 40 + Versuche/Versuch_03/01_Prompt.md | 184 + Versuche/Versuch_03/README.md | 153 + 89 files changed, 39498 insertions(+), 104 deletions(-) create mode 100644 .claude/skills/run-experiment/prepare-codex-workspace.py create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/Ergebnisse/Analysebericht.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/Protokoll.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/RawResult.json create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/Stderr.log create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/before.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/combined_prompt.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/endzeit.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/startzeit.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/Analysebericht.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/StRS.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/SyRS.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Protokoll.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/RawResult.json create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Stderr.log create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/anforderungen.json create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/anforderungen.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/before.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/combined_prompt.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/endzeit.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/startzeit.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Analysebericht.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Glossar.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Hypothesen.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/StRS.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/SwRS.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/SyRS.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Traceability.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Protokoll.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/RawResult.json create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Stderr.log create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_ledger.tsv create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/after.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/anforderungen.json create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/anforderungen.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/before.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/combined_prompt.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/endzeit.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/startzeit.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_modcounts.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_report_part2.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_report_part3.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e/Protokoll.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/Protokoll.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/RawResult.json create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/Stderr.log create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/before.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/combined_prompt.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/endzeit.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/startzeit.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Ergebnisse/Analysebericht.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Ergebnisse/StRS.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Protokoll.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/RawResult.json create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Stderr.log create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/anforderungen.json create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/anforderungen.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/before.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/combined_prompt.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/endzeit.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/startzeit.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Analysebericht.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Glossar.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Hypothesen.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/StRS.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/SwRS.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/SyRS.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Traceability.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Protokoll.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/RawResult.json create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Stderr.log create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/after.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/anforderungen.json create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/anforderungen.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/before.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/combined_prompt.md create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/endzeit.txt create mode 100644 Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/startzeit.txt create mode 100644 Versuche/Versuch_02/01_Agents.json create mode 100644 Versuche/Versuch_02/01_Prompt.md create mode 100644 Versuche/Versuch_02/README.md create mode 100644 Versuche/Versuch_03/01_Agents.json create mode 100644 Versuche/Versuch_03/01_MCP.json create mode 100644 Versuche/Versuch_03/01_Prompt.md create mode 100644 Versuche/Versuch_03/README.md diff --git a/.claude/skills/run-experiment/SKILL.md b/.claude/skills/run-experiment/SKILL.md index 2afeb0b7..aa54ef97 100644 --- a/.claude/skills/run-experiment/SKILL.md +++ b/.claude/skills/run-experiment/SKILL.md @@ -2,7 +2,7 @@ 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 " oder wenn der User einen Versuch/ein Experiment ausführen und tracken will. argument-hint: -version: 5.0.0 +version: 7.0.0 --- # 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`. - **Root** (Pflicht): Verzeichnis, das als Root des Versuchslaufs dient. Zweites Argument. - Der Headless-Lauf wird mit diesem Verzeichnis als Arbeitsverzeichnis gestartet – es ist - die Wurzel der zu analysierenden Codebasis und wird nur GELESEN. Fehlt das Argument: den + Es ist die Wurzel der zu analysierenden Codebasis und wird nur GELESEN. Der Codex-Adapter + 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 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 @@ -216,7 +217,7 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen" unangetastet und die Agentenkonfiguration ist eine dokumentierte, versionierte 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 `custom` abbrechen und mitteilen, dass dieser Adaptermodus noch nicht verifiziert ist. Eine 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','') } $iteration = if ($iterationen) { $iterationen[-1].Name } else { 'Iteration 1' } $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 { $id4 = '{0:x4}' -f (Get-Random -Maximum 65536) $lauf = Join-Path "\$zelle" "_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). ``` -**Codex-Abweichung bei Block 2.** Der Codex-Adapter läuft mit einem technisch erzwungenen -`read-only`-Sandboxmodus. Er kann deshalb auch das externe Laufverzeichnis nicht direkt als -Agent beschreiben. Block 2 wird dort durch folgende strukturierte Rückgabeanweisung ersetzt; +**Codex-Abweichung bei Block 2.** Der Codex-Adapter läuft in einer isolierten Arbeitskopie +im System-Temp-Verzeichnis mit `workspace-write`. Das originale Root liegt außerhalb dieses +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 `normalise-codex-result.py` die Dateien: ``` ### 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` und unter `content` den vollständigen Dateiinhalt. `summary` enthält nur eine kurze Laufzusammenfassung. ``` @@ -376,6 +378,9 @@ $lauf = "" $prompt = (Get-Content "" -Raw) + "`n`n" # Steuerdateien IMMER ins Laufverzeichnis - nie in den gemeinsamen Scratchpad (parallelfaehig) 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) # Schreibende und bauende Shell-Kommandos sperren – die Codebasis wird nur gelesen. @@ -414,7 +419,7 @@ Bedeutung der Flags: | 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 | | `--permission-mode acceptEdits` | Schreibrechte für die Ergebnisdateien im Laufverzeichnis | | `--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 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 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. @@ -542,6 +596,32 @@ Subagenten gibt. Bei Modus `builtin` oder `custom` daher **nie** den Flag-Wert allein ins Protokoll schreiben, 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 +`\\tasks\.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 hoher Wert bedeutet, dass die Werkzeugkonfiguration den Lauf eingeschränkt hat, und ist bei der Interpretation der Ergebnisqualität zu berücksichtigen. @@ -683,7 +763,11 @@ Vorlage: - **Permission-/Sandbox-Modus:** - **Toolfreigabe:** - **Isolationsmechanismus:** -- **MCP-Server / Agentendateien:** +- **MCP-Server / Agentendateien:** +- **Umgebungsprüfung (nur `custom` / MCP):** - **Subagenten:** - **Verschachtelung:** `spawned` = , davon `spawned_by_subagents` = , `max_depth` = . 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` = (bei `solo` muss 0 stehen, sonst Fehlmessung) - **Subagenten-Prompts:** <`_meta\subagenten.md`, N Aufrufe erfasst | entfällt (Modus solo)> +- **Gültigkeit:** - **Erzeugte Dateien:** - **Root unverändert:** - **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 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: `--disable multi_agent` und `-c agents.enabled=false`. -**Isolation und Ausgabe.** Codex arbeitet im Root mit `--sandbox read-only`. Anders als beim -Claude-Adapter erhält der Agent deshalb kein beschreibbares Zusatzverzeichnis. Er liefert 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. +**Isolation und Ausgabe.** Unter Windows blockierte `--sandbox read-only` mit Codex CLI +0.149.0-alpha.4.3 bereits den Start rein lesender Prozesse (`pwsh`, `cmd`, `rg`). Der Adapter +erstellt deshalb vor dem Lauf eine isolierte Kopie der versionierten und nicht ignorierten +Quelldateien im System-Temp-Verzeichnis und startet Codex dort mit `--sandbox workspace-write`. +Das originale Root liegt außerhalb des Codex-Arbeitsbereichs und bleibt technisch getrennt. +`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 Pfade beziehungsweise die bestätigten Versuchsbedingungen setzen. Den Prompt mit dem -Codex-Ausgabeblock aus Abschnitt 2 nach `_meta\combined_prompt.md` schreiben. Der eigentliche -Aufruf lautet: +Codex-Ausgabeblock aus Abschnitt 2 nach `_meta\combined_prompt.md` schreiben. Anschließend das +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-" +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 $codexArgs = @( '--model', $modell, '-c', "model_reasoning_effort=`"$effort`"", '-c', 'service_tier="default"', - '--sandbox', 'read-only', + '--sandbox', 'workspace-write', '--ask-for-approval', 'never', '--disable', 'multi_agent', '-c', 'agents.enabled=false', @@ -818,7 +923,7 @@ $codexArgs = @( '--disable', 'apps', '--disable', 'hooks', '--disable', 'skill_search', - '--cd', $root, + '--cd', $workspace, 'exec', '--ignore-user-config', '--ignore-rules', @@ -837,14 +942,20 @@ $codexExit = $LASTEXITCODE Set-Content -Path "$lauf\_meta\exitcode.txt" -Value $codexExit 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 ` --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` 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 -den Lauf als Fehler protokollieren. +Integritätsprüfung und erzeugte `RawResult.json`. Ist `$workspaceExit` ungleich null, den Lauf +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:** @@ -853,13 +964,13 @@ den Lauf als Fehler protokollieren. | `--model ` | vollständige, vom User bestätigte OpenAI-Modell-ID | | `model_reasoning_effort` | expliziter Denkaufwand | | `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 | | `--ignore-user-config`, `--ignore-rules` | keine User-Konfiguration und keine Exec-Regeln | | `--disable plugins/apps/hooks/skill_search` | keine externen oder benutzerspezifischen Erweiterungen | | `--disable multi_agent`, `agents.enabled=false` | keine Subagenten im Modus `solo` | | `--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 `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 | |---|---|---|---| +| **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 | | **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) | diff --git a/.claude/skills/run-experiment/extract-subagenten.py b/.claude/skills/run-experiment/extract-subagenten.py index 2f32d10f..ace545d3 100644 --- a/.claude/skills/run-experiment/extract-subagenten.py +++ b/.claude/skills/run-experiment/extract-subagenten.py @@ -64,6 +64,10 @@ for a in aufrufe: txt = ergebnisse.get(a['id']) or '' a['ergebnis_zeichen'] = len(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']] 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' % (a['werkzeug'], a['subagent_type'], a['run_in_background']), - '- **Prompt-Zeichen:** %d **Ergebnis-Zeichen:** %s' - % (len(a['prompt']), a['ergebnis_zeichen']), + '- **Prompt-Zeichen:** %d **Rueckgabe:** %s' + % (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(), '```', ''] 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 '', erwartet, gesamt, verschachtelt)) for a in echte: - print(' - %-42s %s Prompt %6d Z. Ergebnis %s Z.' - % ((a['description'] or '')[:42], a['subagent_type'], len(a['prompt']), a['ergebnis_zeichen'])) + print(' - %-42s %-16s Prompt %6d Z. %s' + % ((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')) diff --git a/.claude/skills/run-experiment/prepare-codex-workspace.py b/.claude/skills/run-experiment/prepare-codex-workspace.py new file mode 100644 index 00000000..39b465d8 --- /dev/null +++ b/.claude/skills/run-experiment/prepare-codex-workspace.py @@ -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() diff --git a/Versuche/AblaufProtokoll.md b/Versuche/AblaufProtokoll.md index 09378e39..c4ef0695 100644 --- a/Versuche/AblaufProtokoll.md +++ b/Versuche/AblaufProtokoll.md @@ -30,7 +30,7 @@ gleichen Bedingungen streuen. --- -## 2. Chronologie in sechs Phasen +## 2. Chronologie in sieben Phasen ### Phase 1 – Erster Lauf und die Entdeckung der Werkzeugkonfiguration (12:29–13:00) @@ -287,6 +287,192 @@ 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: 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 `\\tasks\.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. + --- ## 3. Entwicklung des Prompts @@ -548,9 +734,22 @@ Belegqualität zu halten – dann wäre die Änderung zurückzunehmen. ## 8. Grenzen und offene Punkte -**Nicht 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 -`max` würde die Frage entscheiden. +**Teilweise geklärt:** Ob der Verbrauchssprung im Fable-Block vom Modell oder vom Effort kommt – +beide Variablen wechselten gleichzeitig. Die Zelle `claude-opus-5 / solo / max` (Iteration 3) +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 in der bisherigen Anlage:** Die Zelle `claude-opus-5 / builtin / high` ist +zweimal gescheitert (Zeitlimit, Session-Kontingent) und hat dabei 586 Mio. Tokens ohne Ergebnis +verbraucht. Vor einer Wiederholung ist zu entscheiden, ob die Kombination Opus + Delegation + +Prompt-Version 02 überhaupt sinnvoll messbar ist. + +**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 Protokolls beruhen auf maschinell erhebbaren Größen. Ob die erzeugten Anforderungen sachlich diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/Ergebnisse/Analysebericht.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/Ergebnisse/Analysebericht.md new file mode 100644 index 00000000..4bb4f3db --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/Ergebnisse/Analysebericht.md @@ -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).* diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/Protokoll.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/Protokoll.md new file mode 100644 index 00000000..b22edb0d --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/Protokoll.md @@ -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. diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/RawResult.json b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/RawResult.json new file mode 100644 index 00000000..5cc42e57 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/RawResult.json @@ -0,0 +1 @@ +{"is_error":true,"duration_api_ms":12390715,"num_turns":44,"stop_reason":"stop_sequence","session_id":"d77bf9b3-7a4d-4620-861f-28861a420996","total_cost_usd":177.79331799999994,"usage":{"input_tokens":54,"cache_creation_input_tokens":120350,"cache_read_input_tokens":1915680,"output_tokens":58348,"output_tokens_details":{"thinking_tokens":15574},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":120350,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":333,"cache_read_input_tokens":144811,"cache_creation_input_tokens":5517,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":5517},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6961,"outputTokens":20,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.0070610000000000004,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-fable-5":{"inputTokens":1426,"outputTokens":1037386,"cacheReadInputTokens":72244456,"cacheCreationInputTokens":4150505,"webSearchRequests":0,"costUSD":176.91195349999995,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty","costBasis":"list"},"claude-opus-5[1m]":{"inputTokens":20,"outputTokens":15803,"cacheReadInputTokens":306607,"cacheCreationInputTokens":52132,"webSearchRequests":0,"costUSD":0.8743035,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-opus-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"PowerShell","tool_use_id":"toolu_0187Tx7c8CfHaA5vzDAq1JRc","tool_input":{"command":"Get-ChildItem \"C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\tests\" -Directory | Select-Object -ExpandProperty Name; New-Item -ItemType Directory -Force \"c:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 3\\claude-fable-5\\builtin\\high\\02_Lauf_2026-08-26_195958_v7.0.0-d694\\Ergebnisse\" | Select-Object FullName","description":"List tests and create output directory"}},{"tool_name":"PowerShell","tool_use_id":"toolu_01LtG4b7XZJwwU5Xoxes89Nu","tool_input":{"command":"New-Item -ItemType Directory -Force \"c:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 3\\claude-fable-5\\builtin\\high\\02_Lauf_2026-08-26_195958_v7.0.0-d694\\Ergebnisse\" | Select-Object -ExpandProperty FullName","description":"Create Ergebnisse output directory"}},{"tool_name":"Read","tool_use_id":"toolu_01EPBLgCQuShRMdNHkx5RGof","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}},{"tool_name":"Read","tool_use_id":"toolu_012ipFUjnYT8zNn8NWWRQfDR","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}},{"tool_name":"Read","tool_use_id":"toolu_01DDoBPp2Zvn9L7M22pn8HGt","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}},{"tool_name":"Read","tool_use_id":"toolu_01JPE1NtmegxSdcqn4SEqcj9","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}},{"tool_name":"Read","tool_use_id":"toolu_01Cs5tYPPLNu8KAkjNCMFTMR","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}},{"tool_name":"Read","tool_use_id":"toolu_014zkToGkpReWtyuCbjzKhu3","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}},{"tool_name":"Read","tool_use_id":"toolu_014ESsEEkE94VKTyvAMVtm7G","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}},{"tool_name":"Read","tool_use_id":"toolu_018rRwQZqamfCd1Jy5wCHJv3","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}},{"tool_name":"Read","tool_use_id":"toolu_01UXdgEFQ6twkySL2WX35MZg","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}},{"tool_name":"Read","tool_use_id":"toolu_0183bKEDMhWk3N6QJ8xX8ge4","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}},{"tool_name":"Read","tool_use_id":"toolu_018EuPemZWLdHqVKRrWEyu3M","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}},{"tool_name":"Read","tool_use_id":"toolu_013qYupGYcNdnyhc2iimAJaQ","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\d77bf9b3-7a4d-4620-861f-28861a420996\\scratchpad\\AP_Anleitung.md"}}],"terminal_reason":"api_error","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":13,"requested":{"background":0,"foreground":0,"unset":13},"started_in_background":13,"max_depth":1,"spawned_by_subagents":0,"completed":10,"failed":3,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{"Explore":1,"general-purpose":12}},"subtype":"success","api_error_status":429,"result":"You've hit your session limit · resets 10:50pm (Europe/Berlin)","type":"result","duration_ms":1791107,"uuid":"058cf218-7f8d-4e56-955d-5b859b9b05d1","queued_turn_count":0} diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/Stderr.log b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/Stderr.log new file mode 100644 index 00000000..e69de29b diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/before.txt b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/before.txt new file mode 100644 index 00000000..8b137891 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/before.txt @@ -0,0 +1 @@ + diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/combined_prompt.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/combined_prompt.md new file mode 100644 index 00000000..20985249 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/combined_prompt.md @@ -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: - +Titel: +Ebene: +Typ: +Qualitätsmerkmal: +Akteur: +Vorbedingung: +Fakt: +Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage) +Ergebnis: +Belege: + - [PRIMÄR] - Begründung: + - [SEKUNDÄR] <...> - Begründung: <...> + - [KONTEXT] <...> - Begründung: <...> +Prüfidee: +Tracelinks: +Konsolidierung: > +Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - +Status: +``` + +### 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). diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/endzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/endzeit.txt new file mode 100644 index 00000000..1b027e54 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/endzeit.txt @@ -0,0 +1 @@ +2026-08-26T20:30:04.2067421+02:00 diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/startzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/startzeit.txt new file mode 100644 index 00000000..596809be --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-d694/_meta/startzeit.txt @@ -0,0 +1 @@ +2026-08-26T20:00:11.2795634+02:00 diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/Analysebericht.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/Analysebericht.md new file mode 100644 index 00000000..dc7e766f --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/Analysebericht.md @@ -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)* diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/StRS.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/StRS.md new file mode 100644 index 00000000..eede9631 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/StRS.md @@ -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 +``` diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/SyRS.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/SyRS.md new file mode 100644 index 00000000..e16bdc92 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Ergebnisse/SyRS.md @@ -0,0 +1,1691 @@ +# SyRS – System Requirements Specification + +c-entron ERP-Suite. Systemverhalten, Schnittstellen, Performance- und Sicherheitsanforderungen. +Jede SyRS-Anforderung referenziert in den Tracelinks die zugehörige(n) StRS-Anforderung(en); +zugehörige SwRS-Anforderungen verweisen ihrerseits auf die SyRS-ID (Backward-Links siehe Traceability.md). + +## 1. Sicherheit und Zugang + +``` +ID: SyRS-001 +Titel: Zentrale Rechteprüfung über Benutzer, Gruppen und Rechte +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System (Rechteprüfung); alle Clients +Vorbedingung: Benutzer ist angemeldet. +Fakt: AppRightsBL.CheckRightsFromUser ermittelt Rechte per SQL-Join dbo.Sichtrus (Gruppe→Recht) und dbo.Sichmemb (Benutzer→Gruppe); Web-Accounts werden separat über WebAccountsRights geprüft (CheckWebRightsFromUser); AppUser.HasUserRight wird flächig in BL-Klassen aufgerufen. +Aussage: Das System soll jede geschützte Operation gegen die dem Benutzer über Gruppen zugewiesenen Rechte prüfen; für Web-Accounts gilt ein eigener Rechtebestand. +Ergebnis: Operationen ohne zugewiesenes Recht werden verweigert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methoden CheckRightsFromUser (SQL Sichtrus/Sichmemb) und CheckWebRightsFromUser (WebAccountsRights) – Begründung: durchsetzende Prüfstellen beider Rechtebestände. +Prüfidee: Recht aus Gruppe entfernen → zugehörige Operation liefert Rechtefehler. +Tracelinks: StRS-012 +Konsolidierung: Kandidat: zwei getrennte Rechtebestände (AppUser-Rechte, WebAccount-Rechte) für denselben Zweck – im Zielsystem ein Berechtigungsmodell. +Übernahmewürdigkeit: übernehmen – Grundschutz; Modell im Ziel vereinheitlichen. +Status: belegt +``` + +``` +ID: SyRS-002 +Titel: Zwei-Faktor-Authentifizierung mit Gültigkeitsdauer je Gerät +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System (Anmeldung); RADIUS-Server bzw. Mailsystem +Vorbedingung: 2FA global aktiviert (WebServiceConfigHelper.TwoFactorAuthEnabled) und für den Benutzer eingeschaltet. +Fakt: TwoFactorAuthBL.ValidateTwoFactor prüft nach erfolgreicher Passwortprüfung einen zweiten Faktor über RadiusTwoFactorValidator oder EmailTwoFactorValidator; HasToValidateTwoFactor berücksichtigt eine Gültigkeitsdauer in Tagen (benutzer- oder systemweit), gespeichert je Anwendung/Maschine/IP (TwoFactorAuthLastLogin); Dauer 0 erzwingt 2FA bei jeder Anmeldung; Datumsvergleich ignoriert die Uhrzeit. +Aussage: Das System soll nach der Passwortprüfung optional einen zweiten Faktor (RADIUS oder E-Mail-Link) verlangen und eine erfolgreiche Validierung je Kombination aus Benutzer, Anwendung, Maschine und IP für n Tage anerkennen. +Ergebnis: Anmeldung ohne gültigen zweiten Faktor schlägt mit „Die Zwei-Faktor-Authentifizierung ist fehlgeschlagen." fehl. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs, Methoden ValidateTwoFactor / HasToValidateTwoFactor / RememberLogin – Begründung: vollständige durchsetzende 2FA-Logik. + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Zeilen 62–70 (Fehlerpfad TwoFactorAuthFailed) – Begründung: Abbruch der Anmeldung ohne 2FA. +Prüfidee: 2FA-Dauer 1 Tag: Anmeldung am Folgetag verlangt erneut den zweiten Faktor, am selben Tag nicht. +Tracelinks: StRS-013 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – zeitgemäße Verfahren (TOTP/Passkeys) im Ziel ergänzen. +Status: belegt +``` + +``` +ID: SyRS-003 +Titel: Authentifizierungsverfahren: Passwort, Active Directory, OpenID Connect, Web-Account +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System (Anmeldung); Verzeichnisdienste/IdP +Vorbedingung: Verfahren ist konfiguriert. +Fakt: Der Ordner Administration/Logins/Auth enthält BasicAuthenticator, ActiveDirectoryAuthenticator, OpenIdConnectAuthenticator (inkl. OpenIdConnectAccountConnector), WebAccountAuthenticator, FallbackAuthenticator, FailingAuthenticator sowie eine AuthenticatorFactory; für Entra ID existieren EntraIDUsersBL und die Anleitung docs/reference/security/anmelden-mit-microsoft-technische-anleitung.md; die REST-API bietet JwtAuthController mit „login" und „connect_accounts". +Aussage: Das System soll die Anmeldung wahlweise über internes Passwort, Active Directory, OpenID Connect (u. a. Microsoft Entra ID) oder Web-Account unterstützen und externe Identitäten mit internen Benutzerkonten verknüpfen. +Ergebnis: Benutzer melden sich über das konfigurierte Verfahren an; die Sitzung ist identisch nutzbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs und die genannten Authenticator-Klassen – Begründung: implementierte Verfahrensauswahl. + - [PRIMÄR] src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs, Endpunkte login / connect_accounts mit [Authorize(JwtBearer)] – Begründung: durchgesetzte tokenbasierte Anmeldung und Kontoverknüpfung. + - [SEKUNDÄR] docs/reference/security/anmelden-mit-microsoft-technische-anleitung.md – Begründung: dokumentiertes Entra-ID-Verfahren. +Prüfidee: Anmeldung mit Entra-ID-Token; connect_accounts verknüpft die Identität mit einem AppUser. +Tracelinks: StRS-013 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – SSO ist im SaaS-Ziel Pflicht. +Status: belegt +``` + +``` +ID: SyRS-004 +Titel: Anwendungszugang über erforderliche und verbietende Rechte +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System (Anmeldung) +Vorbedingung: Benutzer authentifiziert; Anwendungskennung (ApplicationKind) übergeben. +Fakt: Authenticator.ValidateRights verweigert die Ticketvergabe, wenn das DisallowingRight des ApplicationKind vorhanden ist oder das RequiredRight fehlt. +Aussage: Das System soll den Zugang je Client-Anwendung über ein erforderliches Recht gewähren und über ein verbietendes Recht entziehen können. +Ergebnis: Anmeldung an einer Anwendung ohne erforderliches Recht wird abgelehnt. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, Methode ValidateRights (DisallowingRight-/RequiredRight-Prüfung) – Begründung: durchsetzende Zugangsprüfung. +Prüfidee: Benutzer ohne RequiredRight der Anwendung → Fehlermeldung „RightsMissing". +Tracelinks: StRS-012, StRS-013 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-005 +Titel: Rechteprüfung an REST-Endpunkten per Autorisierungsattributen +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System (REST-API) +Vorbedingung: API-Aufruf mit gültiger Authentifizierung. +Fakt: Centron.Controllers/Authorization stellt AuthorizeUserRight-, AuthorizeAnyUserRight-, AuthorizeAllUserRights- und AuthorizeCentronHosted-Attribute bereit; das README zeigt die deklarative Verwendung mit UserRightsConst. +Aussage: Das System soll REST-Endpunkte deklarativ mit Benutzerrechten schützen (einzelnes Recht, beliebiges aus einer Menge, alle aus einer Menge). +Ergebnis: Aufrufe ohne passendes Recht erhalten eine Autorisierungsfehlermeldung. +Belege: + - [PRIMÄR] src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs, AuthorizeAnyUserRightAttribute.cs, AuthorizeAllUserRightsAttribute.cs – Begründung: durchsetzende Attribut-Implementierungen. + - [SEKUNDÄR] src/webservice/Centron.Controllers/Authorization/README.md – Begründung: dokumentierte Verwendung. +Prüfidee: Endpunkt mit AuthorizeUserRight ohne Recht aufrufen → 403/Fehler. +Tracelinks: StRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-006 +Titel: Sitzungstickets mit Lizenzbindung und Wiederverwendung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System (Anmeldung); Lizenzmanager +Vorbedingung: Authentifizierung und Rechteprüfung erfolgreich. +Fakt: Authenticator.AuthenticateUser vergibt unter Sperre (_getExistingOrCreateTicketLock) ein Sitzungsticket: vorhandenes Ticket je Anwendung/Benutzer/Maschine wird wiederverwendet, sonst Lizenzprüfung (LicenseManager.CheckLicense) und Neuanlage (TicketBL.CreateNewTicket); Login-IP/Maschine werden gespeichert (SetLoginIP), die Anwendungsversion protokolliert (SaveLogin). +Aussage: Das System soll je Benutzer, Anwendung und Maschine genau ein Sitzungsticket führen, vor Neuanlage die Lizenzverfügbarkeit prüfen und Anmeldekontext (IP, Maschine, Version) protokollieren. +Ergebnis: Wiederanmeldung derselben Maschine verbraucht keine zusätzliche Lizenz. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, Methode AuthenticateUser (GetExistingTicket → CheckLicense → CreateNewTicket, lock) – Begründung: vollständige durchsetzende Ticketlogik. +Prüfidee: Zweite Anmeldung derselben Maschine liefert dasselbe Ticket; Lizenzzähler unverändert. +Tracelinks: StRS-013, StRS-014 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – als Sessionmodell; Lizenzkopplung siehe StRS-014. +Status: belegt +``` + +``` +ID: SyRS-007 +Titel: Passwortspeicherung interner Benutzer (Ist-Zustand SHA-1 ohne Salt) +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System (Anmeldung) +Vorbedingung: – +Fakt: BasicAuthenticator vergleicht den SHA-1-Hash des Passworts direkt mit dem gespeicherten Wert (SHA1Decoder.GetDecodedSHA1String, Kommentar „TODO the password should be salted!!!"); WebAccountBL.LoginWithWebAccount nutzt dasselbe Verfahren; CryptoUtils bietet zwar CreateSalt/CreatePasswordHash (SHA-1 mit Salt), dies wird für die Anmeldung interner Benutzer nicht verwendet. +Aussage: Das System speichert Benutzer- und Web-Account-Passwörter als ungesalzene SHA-1-Hashes; das Zielsystem soll stattdessen ein modernes, gesalzenes Verfahren (z. B. Argon2/bcrypt) mit Migrationspfad verwenden. +Ergebnis: Ist: Anmeldung per SHA-1-Vergleich; Ziel: keine ungesalzenen Hashes mehr. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Zeilen 46–50 (SHA1-Vergleich, TODO-Kommentar) – Begründung: durchgesetztes Ist-Verfahren an der Anmeldestelle. + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs, Methode LoginWithWebAccount (SHA1-Vergleich) – Begründung: gleiches Verfahren für Web-Accounts. +Prüfidee: Passwortfeld in Sichbenu enthält 40-stelligen Hex-Hash; identische Passwörter ergeben identische Hashes (Beleg für fehlendes Salt). +Tracelinks: StRS-013 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet – kryptografisch überholtes Verfahren; fachliche Funktion (Passwortlogin) bleibt, Umsetzung ist zu ersetzen. +Status: belegt +``` + +``` +ID: SyRS-008 +Titel: Einheitliche Datenzugriffsschicht mit direktem und Webservice-Zugriff +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Flexibilität der Verbindungsarten) +Akteur: WPF-Client, Webservice +Vorbedingung: – +Fakt: docs/getting-started/general-structure.md beschreibt verbindlich das ILogic-Muster: je Modul ein ILogic-Interface mit BL-Implementierung (direkte DB) und WS-Implementierung (Webservice); Module deklarieren SupportsConnectionTypes (SqlServer, CentronWebServices); der Zugriff erfolgt über den ClassContainer mit Result-Fehlerbehandlung. +Aussage: Das System soll Client-Datenzugriffe über eine einheitliche Schnittstelle abwickeln, die wahlweise direkt auf die Datenbank oder über den Webservice arbeitet. +Ergebnis: Gleiches Modulverhalten in beiden Verbindungsarten. +Belege: + - [SEKUNDÄR] docs/getting-started/general-structure.md (Abschnitte ClassContainer/ILogic, Dual Implementation) – Begründung: verbindliche Architekturdoku mit Codebeispielen (BLAccountContractsLogic/WSAccountContractsLogic). +Prüfidee: Modul in beiden Verbindungsarten starten; identische Ergebnisse derselben Operation. +Tracelinks: StRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround – Doppelimplementierung je Modul ist dem Migrationsstand geschuldet; im Web-Ziel entfällt der Direkt-DB-Pfad. +Status: belegt +``` + +``` +ID: SyRS-009 +Titel: Web-Account-Anmeldung nur bei aktiven Kontakten und Kunden +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System (Portal-Anmeldung) +Vorbedingung: Web-Account existiert (Status aktiv). +Fakt: WebAccountBL.LoginWithWebAccount verlangt Status==1 und prüft die Aktivkette: Kontakt aktiv, Adresse aktiv, Kunde/Account aktiv und nicht gesperrt (IsCustomerActiveAndNotLocked / IsAccountActiveAndNotLocked); andernfalls null (Login verweigert). +Aussage: Das System soll Portal-Anmeldungen nur zulassen, wenn Web-Account, zugehöriger Kontakt, Adresse und Kunde aktiv und nicht gesperrt sind. +Ergebnis: Gesperrte/deaktivierte Kunden können sich nicht am Portal anmelden. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs, Methode LoginWithWebAccount (Aktiv-/Sperrprüfungen) – Begründung: durchsetzende Prüfkette. +Prüfidee: Kunden sperren → Portal-Login des zugehörigen Web-Accounts schlägt fehl. +Tracelinks: StRS-015, StRS-013 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 2. Belegwesen + +``` +ID: SyRS-010 +Titel: Einheitliches Belegstatusmodell +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System (Belegwesen) +Vorbedingung: Beleg existiert. +Fakt: enum ReceiptState definiert Active(1)=„offen", Completed(2)=„abgeschlossen", Canceled(3)=„storniert"; ReceiptBase führt State/Version/Editor. +Aussage: Das System soll jeden Beleg in genau einem der Zustände offen, abgeschlossen oder storniert führen. +Ergebnis: Statusabhängige Folgeaktionen (z. B. FiBu-Export, Abrechnung) greifen auf einen eindeutigen Zustand zu. +Belege: + - [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs (enum mit Description-Attributen) – Begründung: implementiertes Statusmodell. +Prüfidee: Statuswechsel offen→abgeschlossen→storniert; andere Werte werden abgelehnt (ArgumentOutOfRangeException in GetReceiptStateString). +Tracelinks: StRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-011 +Titel: Belegprotokoll über alle Belegarten (AnlageLog) +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System (Belegwesen) +Vorbedingung: Beleg wird angelegt/verändert. +Fakt: Die Tabelle AnlageLog protokolliert belegübergreifend über AnlageI3D+AnlageArt (1=Angebot … 6=Gutschrift, 22=Vertrag); das Muster ObjectI3D+ObjectKind wird systemweit für typübergreifende Referenzen genutzt; ReceiptLogBL existiert. +Aussage: Das System soll Belegereignisse typübergreifend in einem gemeinsamen Protokoll mit Objekt-ID und Objektart festhalten. +Ergebnis: Beleghistorie ist über alle Belegarten einheitlich auswertbar. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, Tabelle AnlageLog; src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs – Begründung: Datenstruktur und schreibende Logik existieren. + - [SEKUNDÄR] docs/reference/receipts/receipts-backend-architecture.md (AnlageArt-Werteliste) – Begründung: dokumentierte Typcodes. +Prüfidee: Angebot anlegen → AnlageLog-Eintrag mit AnlageArt=1. +Tracelinks: StRS-001, StRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-012 +Titel: Persistenz der Belege über Legacy-Tabellen mit englischen Views +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System (Persistenz) +Vorbedingung: – +Fakt: Belege werden aus englischen Views (Offers, Invoices, …) gelesen, aber über SaveReceipt*Repository-Klassen in die deutschen Legacy-Tabellen (AngKopf/AngPos, RechKopf/RechPos, …) geschrieben; neue Felder müssen in Tabelle, Versionstabelle, View, Entity, Mapping und Repository ergänzt werden. +Aussage: Das System soll Belege konsistent über den doppelschichtigen Persistenzweg (View lesen, Legacy-Tabelle schreiben) verarbeiten; das Zielsystem soll diese Doppelschicht durch ein einheitliches Schema ablösen. +Ergebnis: Gespeicherte Werte erscheinen beim erneuten Laden vollständig. +Belege: + - [PRIMÄR] src/backend/Centron.DAO/Repositories/Sales/Receipts/ContractList/SaveReceiptContractRepository.cs (u. a. Repositories) – Begründung: implementierter Schreibweg in Legacy-Tabellen. + - [SEKUNDÄR] docs/reference/receipts/receipts-backend-architecture.md („Critical Save Warning") – Begründung: dokumentiert den doppelten Persistenzweg und seine Risiken. +Prüfidee: End-to-End-Test: Beleg über ReceiptWebServiceBL.SaveReceipt speichern, Rohwerte der Legacy-Tabelle prüfen. +Tracelinks: StRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround – historisch gewachsene Doppelschicht; fachlich ist nur „Beleg speichern" zu übernehmen. +Status: belegt +``` + +``` +ID: SyRS-013 +Titel: Belegnummernvergabe aus Nummernkreisen mit Kollisionsschutz +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System (Belegwesen) +Vorbedingung: Nummernkreis (NumberGroup) je Belegart, optional je Filiale, ist konfiguriert. +Fakt: ReceiptBL.UpdateReceiptNumber bestimmt den Nummernkreis über die belegartspezifische Logik und die Filiale; NumberGroupBL.GetNextNumber erhöht den Zähler um das Intervall, prüft per SQL, dass die Nummer in der Zieltabelle noch nicht vorkommt, und schreibt den Zähler nur bei unverändertem Ausgangswert (UpdateBuilder mit Vergleich f.Current == alter Wert, Wiederholung in Schleife). +Aussage: Das System soll Belegnummern je Belegart und Filiale aus Nummernkreisen vergeben, Doppelvergaben auch bei parallelen Zugriffen ausschließen und bereits in der Zieltabelle vorhandene Nummern überspringen. +Ergebnis: Eindeutige Belegnummern ohne Kollision bei gleichzeitiger Vergabe. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs, Methoden GetNextNumber / FindNextNumber (optimistisches Update mit Rowcount-Prüfung, Existenzprüfung per SQL) – Begründung: durchsetzender Kollisionsschutz. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode UpdateReceiptNumber (branch-spezifischer Nummernkreis, Vorlagen-Sonderweg) – Begründung: Einbindung in die Belegerstellung. +Prüfidee: Zwei parallele Belegerstellungen erhalten unterschiedliche Nummern; manuell belegte Nummer wird übersprungen. +Tracelinks: StRS-001, StRS-024 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – Hinweis: Überspringen vorhandener Nummern kann Lücken erzeugen; GoBD-Bewertung im Ziel nötig. +Status: belegt +``` + +``` +ID: SyRS-014 +Titel: Preis-, Rabatt- und Umsatzsteuerberechnung je Position und Beleg +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System (Belegwesen) +Vorbedingung: Beleg mit Positionen (Preis, Rabatt, Steuersatz, Menge, Währungsfaktor). +Fakt: ReceiptPriceHelperBL berechnet Positionspreise (CalculateReceiptItemPrices mit basePrice, discount, taxRate, quantity, currencyFactor, precision) sowie Belegsummen und MwSt.-Aufteilung je Steuersatz (CalculateReceiptVatPrices); Belege kennen Brutto-/Netto-Führung (ExclusiveOfVAT) und Währungsangaben (CurrencyI3D/CurrencyFactor). +Aussage: Das System soll Positions- und Belegwerte aus Preis, Rabatt, Menge, Steuersatz und Währungsfaktor mit definierter Rundungspräzision berechnen und die Steuer je Steuersatz gruppiert ausweisen. +Ergebnis: Belegsummen und Steuerbeträge sind reproduzierbar korrekt. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptPriceHelperBL.cs, Methoden CalculateReceiptItemPrices / CalculateReceiptVatPrices / CalculateReceiptPrices – Begründung: durchsetzende Berechnungslogik. +Prüfidee: Beleg mit zwei Steuersätzen und Rabatt: Summen entsprechen manueller Kontrollrechnung; Steuerblöcke je Satz getrennt. +Tracelinks: StRS-011, StRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – abrechnungskritische Kernlogik. +Status: belegt +``` + +``` +ID: SyRS-015 +Titel: Vollständige Versionierung jeder Belegänderung +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System (Belegwesen) +Vorbedingung: Beleg wird gespeichert. +Fakt: Beim Speichern wird der vorherige Stand als vollständige Kopie in *KopfVersions/*PosVersions geschrieben (INSERT…SELECT mit OriginalI3D, KopfVersionsI3D; Mechanismus AssetHeadDAO.SaveAssetVersion); Versionstabellen sind 1:1-Kopien der Basistabellen. +Aussage: Das System soll bei jeder Belegänderung den vorherigen Stand vollständig (Kopf und Positionen) als Version archivieren. +Ergebnis: Jede historische Belegversion ist rekonstruierbar. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, Tabellen AngKopfVersions/AngPosVersions … VertragKopfVersions/VertragPosVersions – Begründung: Versionstabellen im Schema. + - [SEKUNDÄR] docs/reference/receipts/receipts-backend-architecture.md (Versioning Implementation Example, AssetHeadDAO.SaveAssetVersion) – Begründung: dokumentierter Kopiermechanismus. +Prüfidee: Beleg ändern → neuer Satz in *KopfVersions mit OriginalI3D des Belegs. +Tracelinks: StRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – Audit-Anforderung; technisch im Ziel z. B. als Event-/Temporal-Modell. +Status: belegt +``` + +``` +ID: SyRS-016 +Titel: Kreditlimitprüfung beim Belegspeichern +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System (Belegwesen); Innendienst +Vorbedingung: Kunde mit CreditLimit > 0 und Berechnungsart Netto/Brutto (CreditLimitCalculationKind ≠ 2). +Fakt: ReceiptBL.CheckIfCustomerLimitIsReached summiert das belegte Limit über alle limitrelevanten Belegarten (SpecificLogics.TakesPlaceInLimitCalculation, GetUsedLimitAmount), zieht die Vorversion ab und meldet bei Überschreitung einen Bestätigungsdialog („Das Limit von … wurde um … überschritten. … Möchten Sie den Speichervorgang fortsetzen?"); mit SaveAlthoughCustomerLimitExceeded kann fortgesetzt werden; CreditLimitAvailable wird am Kunden fortgeschrieben. +Aussage: Das System soll beim Speichern kundenbezogener Belege das Kreditlimit (netto oder brutto) gegen alle offenen limitrelevanten Belege prüfen, Überschreitungen dem Benutzer zur Bestätigung vorlegen und das verfügbare Limit am Kunden fortschreiben. +Ergebnis: Limitüberschreitungen erfolgen nur nach expliziter Bestätigung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode CheckIfCustomerLimitIsReached (Zeilen 8636–8690) – Begründung: vollständige durchsetzende Limitlogik. +Prüfidee: Kunde mit Limit 1.000: Beleg über 1.200 löst Dialog aus; Bestätigung speichert, Ablehnung nicht. +Tracelinks: StRS-001, StRS-008 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – kaufmännische Risikosteuerung. +Status: belegt +``` + +``` +ID: SyRS-017 +Titel: Belegvorlagen über definierten Vorlagenkunden +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Vorlagen-Kundennummer ist in den Einstellungen hinterlegt. +Fakt: ReceiptBL.UpdateReceiptNumber behandelt Belege des konfigurierten Vorlagenkunden (GetReceiptTemplateCustomerNumber) gesondert und vergibt Vorlagennummern über ReceiptTemplateBL.GetNextReceiptTemplateNumber. +Aussage: Das System soll Belegvorlagen als Belege eines speziellen Vorlagenkunden führen und mit eigenem Nummernkreis versehen. +Ergebnis: Vorlagen sind von Echtbelegen unterscheidbar und wiederverwendbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode UpdateReceiptNumber (isTemplate-Zweig); ReceiptTemplateBL.cs – Begründung: durchgesetzte Sonderbehandlung. +Prüfidee: Beleg auf Vorlagenkunden anlegen → Nummer aus Vorlagen-Nummernkreis. +Tracelinks: StRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround – Vorlagen als „Belege eines Pseudo-Kunden" sind eine Behelfskonstruktion; im Ziel eigenes Vorlagenkonzept. +Status: belegt +``` + +``` +ID: SyRS-018 +Titel: Optimistische Sperrung von Belegen +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Zuverlässigkeit (Datenintegrität bei Parallelzugriff) +Akteur: System (Belegwesen) +Vorbedingung: Zwei Benutzer bearbeiten denselben Beleg. +Fakt: ReceiptBase führt ConcurrencyControlGuid; die Architektursdoku nennt „Concurrency Control – GUID-based optimistic locking". +Aussage: Das System soll konkurrierende Belegänderungen über eine Versionskennung erkennen und verspätete Speichervorgänge zurückweisen. +Ergebnis: Kein stilles Überschreiben fremder Änderungen. +Belege: + - [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs, Property ConcurrencyControlGuid – Begründung: implementierte Versionskennung. + - [KONTEXT] docs/reference/receipts/receipts-backend-architecture.md (Security/Data Protection) – Begründung: dokumentierte Absicht des optimistischen Sperrens. +Prüfidee: Beleg parallel in zwei Sitzungen ändern; zweiter Speichervorgang wird abgewiesen. +Tracelinks: StRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: HYPOTHESE +``` + +``` +ID: SyRS-019 +Titel: Freigabewesen für Web-Warenkörbe als Statusmaschine +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Endkunde (Besteller, Prüfer, Freigeber), Innendienst +Vorbedingung: Warenkorb eines Web-Accounts existiert; Freigabewesen lizenziert (ThrowIfLicenseIsMissing). +Fakt: enum ReceiptCartState definiert Created → ReadyForCheck („In Prüfung") → Checked („In Bestellung") → Ordered mit Ablehnpfaden DeclinedByChecker/DeclinedByOrderer; ReceiptCartReleaseSystemBL.ReadyCartForCheck erlaubt das Einreichen nur Web-Account-Logins und versendet Mails über MailTemplateBL. +Aussage: Das System soll Web-Warenkörbe durch einen zweistufigen Prüf- und Freigabeprozess (Prüfer, Besteller) mit expliziten Ablehnzuständen und E-Mail-Benachrichtigungen führen. +Ergebnis: Nur geprüfte und freigegebene Warenkörbe werden zu Bestellungen. +Belege: + - [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/ReceiptCartState.cs (Statusmaschine) – Begründung: implementierte Zustände. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs, Methode ReadyCartForCheck (Guard „Only web-account logins…", Lizenzprüfung) – Begründung: durchgesetzter Prozessschritt. +Prüfidee: Warenkorb einreichen, ablehnen, erneut einreichen, freigeben → Statusfolge wie definiert. +Tracelinks: StRS-015 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 3. Abrechnung und Finanzen + +``` +ID: SyRS-020 +Titel: Vertragsabrechnung mit Intervallen, Normalisierung, Kontingenten und Zählern +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System (Abrechnungslauf); Buchhaltung +Vorbedingung: Vertrag ist aktiv, abrechenbar (ContractForBilling) und hat Abrechnungsintervall/Positionen. +Fakt: AutomaticFacturaBL.Contracts.cs enthält: Auswahl abrechenbarer Verträge (SearchBillingContracts, GetActiveContracts), Intervall-/Datumsfortschreibung (NextDate, SetNextBillingDate, SetInvoiceTo, GetContractLastDay), anteilige Normalisierung (MonthNormalizeCoefficient, QuarterNormalizeCoefficient, YearNormalizeCoefficient), Kontingentbuchung (AddInterimContingent, StoreBookedContingent, ContractContingentBalanceCalculation in ReceiptContractBL), Rest-/Überbuchung (UpdateTakeRestAndOverBooking) und Klickzähler (SetCounterActiv, SetCounterInterval, UpdClickCounterHistory); Rechnungen werden Verträgen über VertragRechKopfZuordnung zugeordnet (StoreInvoiceToContract) und können storniert/zurückgesetzt werden (DeactivateContractInvoice, ResetDeviceClickCounter, ChangeLastInvoiceDateForContract). +Aussage: Das System soll Verträge periodengerecht abrechnen: fällige Verträge selektieren, Beträge bei angebrochenen Perioden zeitanteilig normalisieren, Kontingente und Zählerstände (inkl. Freimengen und Staffelpreisen) verrechnen, die erzeugten Rechnungen dem Vertrag zuordnen und Abrechnungen kontrolliert zurücknehmen können. +Ergebnis: Je Abrechnungslauf entstehen korrekte Rechnungen; Vertragszustand (letzte/nächste Abrechnung, Kontingente, Zähler) ist fortgeschrieben und revidierbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Methoden SearchBillingContracts / SetNextBillingDate / MonthNormalizeCoefficient / StoreInvoiceToContract / SetCounterInterval – Begründung: durchsetzende Abrechnungslogik in allen Teilschritten. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ContractLists/ReceiptContractBL.cs, Methoden ContractContingentBalanceCalculation / DeactivateContractInvoice / ChangeLastInvoiceDateForContract – Begründung: durchgesetzte Kontingent- und Korrekturlogik. +Prüfidee: Vertrag mit Quartalsintervall, Start Mitte des Quartals: erste Rechnung anteilig (Koeffizient < 1); Kontingentverbrauch reduziert Folgeabrechnung; Storno setzt Zähler und LastInvoiceDate zurück. +Tracelinks: StRS-002, StRS-019 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – differenzierteste und umsatzkritischste Logik des Systems. +Status: belegt +``` + +``` +ID: SyRS-021 +Titel: Mahnlauf mit Rechteprüfung, Vorschau und Protokoll +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Benutzer besitzt das Mahnwesen-Recht; offene überfällige Rechnungen existieren. +Fakt: DunningRunBL.ExecuteDunningRunInternal prüft das Recht (DunningBL.ThrowIfUserHasInsufficentRights → UserRightsConst.Controlling.Finances.Dunning), erhöht je Rechnung die Mahnstufe mit Datum und Bearbeiter, vergibt eine fortlaufende Mahnlaufnummer, erzeugt Report (Gruppe MAHNUNG, Default je SendType Print/Mail) und optional Mail mit Beleganhängen; GetPreviewForDunningRun führt denselben Lauf in einer zurückgerollten Transaktion aus; ResetDunningRun nimmt einen Lauf zurück. +Aussage: Das System soll Mahnläufe nur für berechtigte Benutzer ausführen, je Rechnung Mahnstufe, Datum und Bearbeiter fortschreiben, jeden Lauf unter fortlaufender Nummer protokollieren, eine folgenlose Vorschau anbieten und Läufe rücksetzbar machen. +Ergebnis: Nachvollziehbare, autorisierte Mahnläufe mit Vorschau. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methoden ExecuteDunningRunInternal / UpdateInvoice / SaveDunningRun / GetPreviewForDunningRun / ResetDunningRun – Begründung: durchsetzende Ablauflogik. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Methode ThrowIfUserHasInsufficentRights (Recht UserRightsConst.Controlling.Finances.Dunning) – Begründung: durchsetzende Rechteprüfung. +Prüfidee: Benutzer ohne Mahnrecht startet Lauf → Exception; Vorschau verändert keine Mahnstufen. +Tracelinks: StRS-003, StRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-022 +Titel: Offene-Posten-Verwaltung +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Rechnungen/Gutschriften mit Zahlungsstatus existieren. +Fakt: Opos-Ordner enthält OposBL und OposRunBL; Mahnwesen lädt neben Rechnungen auch Gutschriften (DunningBL lädt DunningCustomer.Invoices und .CreditVouchers zur Saldierung). +Aussage: Das System soll offene Posten aus Rechnungen und Gutschriften je Kunde ermitteln und für Mahnung/Auswertung bereitstellen. +Ergebnis: Aktueller OP-Stand je Kunde. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs, OposRunBL.cs – Begründung: implementierte OP-Logik. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs (FetchMany Invoices/CreditVouchers) – Begründung: Gutschriften fließen in die Forderungsermittlung ein. +Prüfidee: Rechnung 100 € + Gutschrift 40 € → OP-Saldo 60 €. +Tracelinks: StRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-023 +Titel: SEPA-Lastschriftexport mit Statusführung +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Buchhaltung; Bank +Vorbedingung: Lastschriftfähige Rechnungen (Zahlungsart, Bankdaten, SEPA-Mandat MandatI3D) im Zeitraum. +Fakt: PaymentTransactionBL.GetInvoiceList filtert nach ExportDirectDebitType, Zeitraum und Filiale; ExportInvoices erzeugt die Datei im gewählten pain.008-Format, setzt Exportkennzeichen (SetInvoicesAsExported) und erlaubt Rücksetzung (ResetInvoiceExportedFlag); Verträge tragen SEPA-Mandatsbezug (MandatI3D laut contracts-backend.md). +Aussage: Das System soll lastschriftfähige Rechnungen zeitraum- und filialbezogen selektieren, als SEPA-Datei im konfigurierten Format exportieren und den Exportstatus je Rechnung führen. +Ergebnis: Bankfähige Datei; keine Doppel-Einzüge. +Belege: + - [PRIMÄR] src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, Methoden GetInvoiceList / ExportInvoices / SetInvoicesAsExported – Begründung: durchsetzende Export- und Statuslogik. +Prüfidee: Export zweimal ausführen → zweiter Lauf ohne bereits exportierte Rechnungen. +Tracelinks: StRS-004 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – Formatversionen aktualisieren. +Status: belegt +``` + +``` +ID: SyRS-024 +Titel: FiBu-Export mit Übergabehistorie und Doppelübergabeschutz +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Buchhaltung; FiBu-Systeme (DATEV, Abacus, kundenspezifische Formate) +Vorbedingung: Exportkonfiguration (BookKeepingExportConfiguration) vorhanden. +Fakt: BookKeepingExportBL exportiert fünf Datenarten (BookKeepingExportKind: Customer, Supplier, CustomerReceipts, SupplierReceipts, Cashbook), führt Historien je Datenart (GetBookKeepingExport*History), prüft Doppelte (IsReceiptExported) und unterstützt kundenspezifische Spaltenformate (CustomInterfaceSettings/Columns) sowie Abacus-Sammelkonten; DATEV-Parameter sind als ApplicationSettings hinterlegt; BookKeepingImportBL existiert für den Rückweg. +Aussage: Das System soll Stammdaten, Belege und Kassenbuch konfigurierbar an FiBu-Systeme exportieren, jede Übergabe historisieren, bereits übergebene Belege kennzeichnen und kundenspezifische Exportformate unterstützen. +Ergebnis: Vollständige, nicht doppelte Übergaben mit Nachweis. +Belege: + - [PRIMÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs, Methoden IsReceiptExported / GetReceiptsBookingdataExportFile / GetCustomInterfaceSettings – Begründung: durchsetzende Export-, Schutz- und Konfigurationslogik. +Prüfidee: Beleg exportieren, Historieneintrag prüfen; erneuter Export listet Beleg als bereits übergeben. +Tracelinks: StRS-005, StRS-006 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-025 +Titel: Erzeugung strukturierter E-Rechnungen +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: System (Rechnungsdruck/-versand); Rechnungsempfänger +Vorbedingung: Rechnung ist vollständig; Empfängerformat bekannt. +Fakt: Feldzuordnung ZUGFeRD ist dokumentiert (zugferd-field-mapping.md); eigene Implementierung laut xrechnung.md; ebInterface-API-Projekt für Österreich vorhanden. +Aussage: Das System soll Rechnungsdaten in die Formate ZUGFeRD/XRechnung (DE) und ebInterface (AT) abbilden und als Datei ausgeben. +Ergebnis: Validierbare E-Rechnung. +Belege: + - [SEKUNDÄR] docs/reference/zugferd-field-mapping.md – Begründung: vollständige dokumentierte Feldzuordnung. + - [PRIMÄR] src/apis/Centron.Api.EbInterface (Projektquellen) – Begründung: implementierte Formatabbildung ebInterface. +Prüfidee: Erzeugte Datei gegen XRechnung-/ebInterface-Schema validieren. +Tracelinks: StRS-027 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – im Ziel auf gepflegte Standardbibliothek wechseln (im Code selbst empfohlen). +Status: belegt +``` + +``` +ID: SyRS-026 +Titel: Zahlungseingänge und Bankumsatzabruf über finAPI +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Buchhaltung; finAPI (Bank-Aggregator) +Vorbedingung: finAPI-Zugangsdaten konfiguriert. +Fakt: IncomingPaymentBL protokolliert Zahlungseingänge mit fortlaufender Lognummer (GetNewIncomingPaymentLogNumber, GetIncomingPaymentLogOverview); OnlineBankingFinApiBL liefert finAPI-Client-Credentials; OnlineBankingAccountTransactionsBL verwaltet abgerufene Kontoumsätze; das UI-Modul OnlineBanking mit AccountTransactions existiert; src/apis/Centron.APIs.FinAPI kapselt die REST-Anbindung. +Aussage: Das System soll Bankumsätze über finAPI abrufen, Zahlungseingänge auf Rechnungen erfassen und jeden Verbuchungslauf protokollieren. +Ergebnis: Zahlungseingänge sind Rechnungen zugeordnet; OP-Bestand aktualisiert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentBL.cs (CreateIncomingPaymentLogItem, GetNewIncomingPaymentLogNumber) – Begründung: durchsetzende Verbuchungsprotokollierung. + - [PRIMÄR] src/apis/Centron.APIs.FinAPI (Projekt), src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs – Begründung: implementierte finAPI-Anbindung. +Prüfidee: Testumsatz abrufen und einer Rechnung zuordnen; Logeintrag mit Nummer entsteht. +Tracelinks: StRS-004, StRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-027 +Titel: Anzahlungsabwicklung im Belegfluss +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung, Innendienst +Vorbedingung: Auftrag mit vereinbarter Anzahlung. +Fakt: Der Ordner Sales/Receipts/DownPayment existiert als eigener Baustein des Belegwesens. +Aussage: Das System soll Anzahlungen als Teil des Belegflusses abbilden (Anzahlungsanforderung und Verrechnung in der Schlussrechnung). [HYPOTHESE] +Ergebnis: Anzahlungen werden ausgewiesen und in der Endabrechnung verrechnet. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/DownPayment (Ordner mit BL-Klassen) – Begründung: eigenständiger Anzahlungs-Baustein existiert. +Prüfidee: Anzahlung zu Auftrag erzeugen; Schlussrechnung weist Anzahlung ab. +Tracelinks: StRS-001, StRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – kaufmännischer Standard. +Status: HYPOTHESE – die konkrete Verrechnungslogik (Ausweis in Schlussrechnung) wurde nicht im Detail nachvollzogen; zu bestätigen durch Lesen der DownPayment-Klassen. +``` + +``` +ID: SyRS-028 +Titel: Provisionsermittlung für Vertrieb +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertrieb, Controlling +Vorbedingung: Provisionsschema und Mitarbeiterziele gepflegt. +Fakt: Es existieren ReceiptProvisionSchemaBL, ReceiptProvisionEmployeeGoalBL, ReceiptProvisionEmployeeLevelBL; Belege werden beim Laden mit Provisionen angereichert (ReceiptBL.FillReceiptWithAdditionalData → _receiptProvisionBL.FillReceiptWithProvision). +Aussage: Das System soll Vertriebsprovisionen über Schemata, Mitarbeiterziele und -stufen berechnen und an Belegen ausweisen. +Ergebnis: Provisionswerte je Beleg/Mitarbeiter sind auswertbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptProvisionSchemaBL.cs, ReceiptProvisionEmployeeGoalBL.cs, ReceiptProvisionEmployeeLevelBL.cs; Aufruf FillReceiptWithProvision in ReceiptBL.FillReceiptWithAdditionalData – Begründung: implementierte Provisionslogik und Einbindung. +Prüfidee: Beleg mit provisionsberechtigtem Verkäufer laden → Provisionsdaten gefüllt. +Tracelinks: StRS-016, StRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-029 +Titel: Kassenbuchführung mit Belegbezug +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Filialmitarbeiter, Buchhaltung +Vorbedingung: Kassenbuch eingerichtet. +Fakt: CashBookBookingBL verknüpft Kassenbuchungen mit Belegen (GetCashBookBookingsFromAsset über assetI3D+Kind) und regelt Löschungen (DeleteCashBookBooking, DeleteCashBookBookingFromAsset); Kassenbuchdaten sind FiBu-exportierbar (BookKeepingExportKind.Cashbook). +Aussage: Das System soll Kassenbuchungen mit auslösenden Belegen verknüpfen, kontrolliert löschen und für den FiBu-Export bereitstellen. +Ergebnis: Kassenbuch stimmt mit Belegwelt überein. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CashBooks/CashBookBookingBL.cs, Methoden GetCashBookBookingsFromAsset / DeleteCashBookBookingFromAsset – Begründung: durchgesetzter Belegbezug. +Prüfidee: Barrechnung erzeugt Kassenbuchung; Storno des Belegs entfernt/kompensiert die Buchung. +Tracelinks: StRS-006 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 4. Service und Support + +``` +ID: SyRS-030 +Titel: Ticketlebenszyklus mit Pflichtfeldern und Abschlussfolgen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Helpdesk-Mitarbeiter +Vorbedingung: Ticket existiert; Abschluss-Status ist in den Einstellungen definiert. +Fakt: HelpdeskBL.Save validiert Pflichtfelder (DoValidateMandatoryFields, umgehbar per ignoreMandatoryFields); HelpdeskCloseBL.CloseHelpdesk setzt den konfigurierten Abschlussstatus (GetClosedHelpdeskState) und ClosedAt, löscht offene Ticket-ToDos, erzeugt Historieneintrag (HelpdeskHistoryType.Close), Kontoaktivität und Benachrichtigungen; optional wird eine Umfrage-Mail angereichert (AddSurvey). +Aussage: Das System soll Tickets nur mit gefüllten Pflichtfeldern speichern und beim Abschluss automatisch Status, Abschlusszeitpunkt, Historie, Aktivität, Benachrichtigungen und optional eine Kundenumfrage erzeugen. +Ergebnis: Konsistent abgeschlossene Tickets mit dokumentierten Folgeaktionen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs, Methode CloseHelpdesk (Zeilen 120–157) – Begründung: durchgesetzte Abschlusskette. + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Methode Save (DoValidateMandatoryFields) – Begründung: durchgesetzte Pflichtfeldprüfung. +Prüfidee: Ticket ohne Pflichtfeld speichern → Fehler; Abschluss erzeugt Historie+ClosedAt. +Tracelinks: StRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-031 +Titel: Sichtbarkeits- und Bearbeitungsrestriktionen im Ticketsystem +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System (Ticketzugriff) +Vorbedingung: Benutzer angemeldet. +Fakt: HelpdeskBL wertet SHOW_HELPDESK, SHOW_HELPDESK_ONLY_OWN und SHOW_HELPDESK_ONLY_OWN_BRANCH zu ShowHelpdeskRight.All/OnlyOwn/OnlyOwnBranch/None aus; HelpdeskTimerWebServiceBL prüft OWN_TIME_EDIT für das Bearbeiten fremder Zeiten; CentronRights.md definiert weitere Restriktionen (Zuweisung nur eigene Abteilungen, Fälligkeit, Sichtbarkeit, Zeiten verschieben/löschen nur ohne Belegbezug). +Aussage: Das System soll Ticket-Sichtbarkeit und -Bearbeitung nach einschränkenden Rechten steuern: alle, nur eigene, nur eigene Filiale; Zeiteinträge dürfen ohne Sonderrecht nur vom Erfasser geändert werden. +Ergebnis: Benutzer sehen/bearbeiten ausschließlich rechtekonforme Tickets und Zeiten. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Zeilen 269–291 (Rechteauswertung) – Begründung: durchsetzende Sichtbarkeitslogik. + - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskTimerWebServiceBL.cs, Zeile 374 (HasUserRight OWN_TIME_EDIT) – Begründung: durchsetzende Zeitenrestriktion. + - [SEKUNDÄR] CentronRights.md, Abschnitte 1.1–15 – Begründung: fachliche Beschreibung aller Ticketrechte. +Prüfidee: Benutzer mit ONLY_OWN_BRANCH sieht keine Tickets fremder Filialen. +Tracelinks: StRS-007, StRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-032 +Titel: Ticket-Eskalation und Support-Level +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Eskalationsregeln/Support-Level konfiguriert. +Fakt: Der Ordner Sales/Support/Escalation und SupportLevelBL existieren; HelpdeskSchedulerBL und Prioritäten-/Statusstämme (hlpdsk_prioritaeten, hlpdsk_status) sind vorhanden. +Aussage: Das System soll Tickets anhand konfigurierter Regeln (Priorität, Support-Level, Fälligkeit) eskalieren und Verantwortliche informieren. [HYPOTHESE] +Ergebnis: Überfällige/kritische Tickets werden sichtbar gemacht. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/Escalation (Ordner), SupportLevelBL.cs – Begründung: implementierte Eskalations-/Levelbausteine. +Prüfidee: Ticket mit überschrittener Fälligkeit löst Eskalationsaktion aus. +Tracelinks: StRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: HYPOTHESE – konkrete Eskalationsauslöser/-aktionen nicht im Detail nachvollzogen; Bestätigung durch Lesen der Escalation-Klassen nötig. +``` + +``` +ID: SyRS-033 +Titel: Ticketvorlagen und automatisierte Ticketerzeugung (C-FLOW) +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Vorlagen sind gepflegt; Benutzer besitzt die C-FLOW-Rechte. +Fakt: HelpdeskPatternBL, HelpdeskCreationTemplateBL und der Ordner TicketProcess existieren; CentronRights.md definiert eigene Rechte für Ticketvorlagen (EDIT/CREATE/DELETE_CFLOW_TICKETPATTERN); docs/features/automatic-helpdesk-creation-templates.md beschreibt automatische Ticketerzeugung. +Aussage: Das System soll wiederkehrende Ticketabläufe als Vorlagen (C-FLOW) abbilden, deren Pflege eigenen Rechten unterliegt, und Tickets automatisiert aus Vorlagen erzeugen. +Ergebnis: Standardisierte Tickets ohne manuelle Neuanlage. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskPatternBL.cs, HelpdeskCreationTemplateBL.cs – Begründung: implementierte Vorlagenlogik. + - [SEKUNDÄR] CentronRights.md Abschnitt 17; docs/features/automatic-helpdesk-creation-templates.md – Begründung: Rechte und Automatik dokumentiert. +Prüfidee: Ticket aus Vorlage erzeugen; Benutzer ohne CFlow-Recht kann Vorlagen nicht ändern. +Tracelinks: StRS-007, StRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-034 +Titel: Regelbasierte Postfachverarbeitung mit Ticketbezug +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System (MailScanner); Helpdesk +Vorbedingung: MailScanner-Profil und Workflow konfiguriert. +Fakt: MailScannerBL verwaltet Profile und Workflow-Prozesse (MailScannerWorkflowProcessDTO) und protokolliert Verarbeitungen (MailScannerLog). +Aussage: Das System soll überwachte Postfächer nach konfigurierbaren Workflows verarbeiten (u. a. Tickets erzeugen/aktualisieren) und jede Verarbeitung protokollieren. +Ergebnis: Eingehende Mails werden ohne manuelle Triage zu Vorgängen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/MailScanner/MailScannerBL.cs (SaveWorkflow, SaveProfile, SaveMailScannerLog) – Begründung: implementierte Workflow- und Protokolllogik. +Prüfidee: Mail an überwachtes Postfach → Ticket gemäß Workflow, Logeintrag vorhanden. +Tracelinks: StRS-018, StRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-035 +Titel: Checklisten aus Vorlagen an Tickets +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Checklistenvorlage existiert; Benutzer besitzt Checklistenrechte. +Fakt: CentronChecklistBL verwaltet Checklisten und -punkte (SaveOrUpdateCentronChecklist, GetChecklistsByFilter); CentronRights.md definiert Rechte für Vorlagenpflege, Bearbeitung und Bearbeiterwechsel einzelner Punkte; Nexus enthält TicketChecklists. +Aussage: Das System soll Checklisten aus Vorlagen an Tickets führen; Pflege von Vorlagen, Listen und Punktbearbeitern unterliegt eigenen Rechten. +Ergebnis: Abarbeitungsstand je Ticket dokumentiert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs – Begründung: implementierte Checklistenlogik. + - [SEKUNDÄR] CentronRights.md Abschnitt 16 – Begründung: Rechtebindung dokumentiert. +Prüfidee: Checkliste aus Vorlage erzeugen, Punkt abhaken; ohne Recht EDIT_CHECKLISTS keine Änderung. +Tracelinks: StRS-007, StRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-036 +Titel: Kundenumfragen bei Ticketabschluss +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Endkunde; Serviceleitung +Vorbedingung: Umfragevorlage in den Survey-Einstellungen hinterlegt. +Fakt: HelpdeskCloseBL.AddSurvey hängt bei aktivierter Einstellung (ValueAttachmentForHelpdesk, ValueHelpdeskSurveyI3D) eine aus der Vorlage generierte Umfrage an die Abschlussmail an, sofern der Empfängerkontakt im Konto gefunden wird; UI-Modul Survey existiert. +Aussage: Das System soll beim Ticketabschluss optional eine Umfrage an den Kundenkontakt versenden, deren Vorlage konfigurierbar ist. +Ergebnis: Servicequalität wird systematisch beim Kunden abgefragt. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs, Methode AddSurvey (Zeilen 168–198) – Begründung: durchgesetzte Umfrageanreicherung. +Prüfidee: Ticket mit aktivierter Umfrageeinstellung schließen → Mailtext enthält Umfrage-Link/-Inhalt. +Tracelinks: StRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-037 +Titel: Kopplung an externe Helpdesk-Systeme +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: System; Fremd-Ticketsysteme +Vorbedingung: Konfiguration je Fremdsystem hinterlegt. +Fakt: ExternalHelpdeskConfigurationBL verwaltet Konfigurationen per Filter (Get/SaveOrUpdate/Delete). +Aussage: Das System soll Verbindungen zu externen Helpdesk-Systemen konfigurierbar verwalten und darüber Tickets austauschen. [HYPOTHESE] +Ergebnis: Ticketaustausch mit Fremdsystemen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs – Begründung: implementierte Konfigurationsverwaltung. +Prüfidee: Konfiguration anlegen; Austausch mit Testsystem prüfen. +Tracelinks: StRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: HYPOTHESE – nur die Konfigurationsverwaltung ist belegt; der eigentliche Austauschmechanismus wurde nicht gelesen. +``` + +``` +ID: SyRS-038 +Titel: Zeit-/ereignisgesteuerte Aufgabenautomatisierung (TaskManagement) +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Serviceleitung +Vorbedingung: Task mit Aktion und Auslöser definiert; Benutzer besitzt SHOW_TASKMANAGEMENT. +Fakt: TaskManagementTaskBL bietet SaveOrUpdateTask, ExecuteTask, ExecuteTaskTest und Ausführungsprotokoll (GetAllTaskExecutedAt); ActionHandler existieren (u. a. TaskManagementReportActionHandler); das Recht SHOW_TASKMANAGEMENT ist dokumentiert. +Aussage: Das System soll wiederkehrende Aufgaben (z. B. Berichtsversand) als konfigurierbare Tasks mit Aktionen ausführen, testweise ausführbar machen und Ausführungen protokollieren. +Ergebnis: Automatisierte, nachvollziehbare Routineaufgaben. +Belege: + - [PRIMÄR] src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs (ExecuteTask, GetAllTaskExecutedAt) – Begründung: durchsetzende Ausführungs- und Protokolllogik. +Prüfidee: Task mit Report-Aktion anlegen, testen (ExecuteTaskTest), Ausführungszeitpunkt im Protokoll. +Tracelinks: StRS-017, StRS-016 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 5. Stammdaten + +``` +ID: SyRS-040 +Titel: Vereinheitlichter Konten-/Adress-/Kontaktstamm mit Rollen +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Alle Fachbereiche +Vorbedingung: – +Fakt: Accounts-BL verwaltet Konten mit Adressen (AccountAddressBL), Kontakten (AccountAddressContactBL), Typen (AccountTypeBL) und Suche (AccountSearchBL, View cvw_AccountSearchAcc); Rollen liegen in AccountCustomers/AccountSuppliers; Konzernstrukturen existieren (CompanyGroupI3D, UseSettingsFromCompanyGroupForReceipts in ReceiptBL.GetCompanyGroupCustomerI3DForReceiptData). +Aussage: Das System soll Geschäftspartner als Konten mit beliebigen Adressen, Kontakten und Rollen (Kunde, Lieferant) führen und Konzernverbünde (Firmengruppe) für Belegeinstellungen berücksichtigen. +Ergebnis: Ein Partner, mehrere Rollen; Konzernregeln greifen bei Belegen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs, AccountAddressBL.cs, AccountAddressContactBL.cs – Begründung: implementierter Kontenstamm. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode GetCompanyGroupCustomerI3DForReceiptData (SQL über Accounts/CompanyGroup) – Begründung: durchgesetzte Konzernlogik. +Prüfidee: Konto in Firmengruppe: Beleg nutzt Einstellungen der Gruppe, wenn Flag gesetzt. +Tracelinks: StRS-008 +Konsolidierung: Kandidat: Parallelstruktur zum Alt-Kundenstamm (Kunden/Anschrif/Personen) – siehe StRS-008. +Übernahmewürdigkeit: übernehmen – als führendes Modell für das Zielsystem. +Status: belegt +``` + +``` +ID: SyRS-041 +Titel: Mitarbeiterverwaltung mit Beschäftigungszeitraum und Organisationszuordnung +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Personalverantwortliche, Administrator +Vorbedingung: – +Fakt: EmployeeArea enthält EmployeeBL (IsActiveEmployeeCompact prüft Ein-/Austrittstermin), EmployeeDepartmentBL, EmployeeHolidayBL, EmployeeRfidTokenBL, EmployeeArticleBL (Mitarbeiter als abrechenbarer Artikel), AppUserBL; Anmeldung ausgeschiedener Mitarbeiter wird abgewiesen (Authenticator.ValidateAppUser). +Aussage: Das System soll Mitarbeiter mit Beschäftigungszeitraum, Filiale, Abteilungen, Urlaub und RFID-Token führen; außerhalb des Beschäftigungszeitraums ist keine Anmeldung möglich; für die Leistungsabrechnung ist jedem Mitarbeiter ein Mitarbeiterartikel zuordenbar. +Ergebnis: Organisations- und Abrechnungsdaten der Mitarbeiter konsistent. +Belege: + - [PRIMÄR] src/backend/Centron.BL/EmployeeArea/EmployeeBL.cs (IsActiveEmployeeCompact) und Authenticator.ValidateAppUser (Aufruf) – Begründung: durchgesetzte Beschäftigungszeitraumprüfung. + - [PRIMÄR] src/backend/Centron.BL/EmployeeArea/EmployeeArticleBL.cs – Begründung: Mitarbeiterartikel-Konzept implementiert. +Prüfidee: Austrittstermin gestern setzen → Anmeldung schlägt fehl. +Tracelinks: StRS-013, StRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-042 +Titel: Bankverbindungen mit Löschschutz bei Belegbezug +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Bankverbindung existiert. +Fakt: BankAccountBL bietet ReceiptsForBankAccount (Belege je Bankkonto) und DeleteBankAccount als getrennte Operationen. +Aussage: Das System soll Bankverbindungen je Kunde verwalten und vor dem Löschen den Bezug zu Belegen prüfbar machen. +Ergebnis: Keine verwaisten Zahlungsreferenzen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Accounting/BankAccountBL.cs (ReceiptsForBankAccount, DeleteBankAccount) – Begründung: implementierte Prüf-/Löschoperationen. +Prüfidee: Bankkonto mit Belegbezug löschen → Warnung/Verweigerung gemäß Prüfliste. +Tracelinks: StRS-004, StRS-008 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-043 +Titel: Kostenstellen und Kostenträger +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Controlling +Vorbedingung: – +Fakt: Tabellen Kostenstellen/Kostentraeger existieren im Schema; UI-Modul PayersAndCostCenter (AddCostCenterOrPayersView, CostCentreDTOViewModel) verwaltet beide; CustomerCostCenterBL verknüpft Kunden mit Kostenstellen. +Aussage: Das System soll Kostenstellen und Kostenträger als Stammdaten führen und Kunden bzw. Belegen zuordenbar machen. +Ergebnis: Controlling-Dimensionen stehen in Auswertungen und FiBu-Export zur Verfügung. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, Tabellen Kostenstellen/Kostentraeger; src/backend/Centron.BL/Accounts/CustomerCostCenterBL.cs – Begründung: Datenmodell und Zuordnungslogik existieren. + - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter – Begründung: Pflege-UI existiert. +Prüfidee: Kostenstelle anlegen und Kunden zuordnen; Zuordnung in Auswertung sichtbar. +Tracelinks: StRS-005, StRS-016 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 6. Einkauf, Lager, Artikel + +``` +ID: SyRS-050 +Titel: EDI-Belegaustausch mit Distributoren +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Einkäufer; Distributoren (ALSO, ALSO CH, Alltron, Herweck, Komsa, ITscope, EGIS, Concerto, OpenTrans-Partner) +Vorbedingung: EDI-Zugang je Lieferant konfiguriert (EDIGatewaySettingBL). +Fakt: SupplierEdiBL mit Partialklassen je Distributor verarbeitet Bestellungen, Bestellantworten, Lieferavise und Rechnungen; EDIDispatcherBL erzeugt/lädt Bestellungen (OpenTrans 2.1, EGIS, ITscope, Concerto); EDILogBL protokolliert; Importregeln sind dokumentiert (edi-import-rules.md). +Aussage: Das System soll Einkaufsbelege mit Distributoren elektronisch austauschen (Bestellung hoch, Antwort/Avis/Rechnung herunter), lieferantenspezifische Formate abbilden und alle Vorgänge protokollieren. +Ergebnis: Automatischer Belegfluss mit dem Distributionskanal. +Belege: + - [PRIMÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs (EdiEgisOrderUploadAsync u. a.), EDILogBL.cs – Begründung: durchsetzende Übertragungs- und Protokolllogik. + - [SEKUNDÄR] docs/reference/edi/edi-architecture.md, edi-import-rules.md – Begründung: dokumentierte Formate und Verarbeitungsregeln. +Prüfidee: OpenTrans-Bestellung erzeugen und gegen Schema validieren; EDI-Log-Eintrag vorhanden. +Tracelinks: StRS-009 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-051 +Titel: Lagerstruktur mit Filialbezug und Umbuchungsprotokoll +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lagermitarbeiter +Vorbedingung: Läger angelegt. +Fakt: StockBL verwaltet Haupt-/Nebenläger (GetMainWarehouse, SecondaryStock), Filialzuordnung (GetDefaultWarehouseI3DFromBranch, GetWarehouseI3DToBranch) und schreibt Umbuchungsprotokolle (WriteStockRebookLog, StockRebookLogFilter). +Aussage: Das System soll Läger mit Haupt-/Nebenlagerstruktur und Filialzuordnung führen und jede Lagerumbuchung protokollieren. +Ergebnis: Bestandsbewegungen sind je Lager nachvollziehbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs (WriteStockRebookLog, GetDefaultWarehouseI3DFromBranch) – Begründung: durchsetzende Lager-/Protokolllogik. +Prüfidee: Umbuchung ausführen → RebookLog mit Quelle/Ziel/Menge. +Tracelinks: StRS-010, StRS-024 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-052 +Titel: Inventur mit Transaktionsklammer +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lagermitarbeiter +Vorbedingung: Inventur eröffnet. +Fakt: StorageBL kapselt Inventurvorgänge mit expliziter Transaktionssteuerung (StartTransaction/Commit/Rollback) und Bestandsfunktionen (AddInventory, DeleteInv, RefreshInv); InventoryArticlePool existiert. +Aussage: Das System soll Inventuren als transaktional geklammerte Zähl- und Korrekturvorgänge durchführen. +Ergebnis: Inventurbestände werden vollständig oder gar nicht wirksam. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Storage/StorageBL.cs (StartTransaction/AddInventory/RollbackTransaction) – Begründung: durchgesetzte Transaktionsklammer. +Prüfidee: Inventur abbrechen → keine Bestandsänderung. +Tracelinks: StRS-010 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-053 +Titel: Artikelstamm mit Sonderartikeln und Preisstrukturen +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Produktmanagement +Vorbedingung: – +Fakt: ArticleBL kennt funktionale Sonderartikel (Fracht-, Kundenrabatt-, Kontingentausgleichs-, Flatrate-Artikel) und Rechteprüfung (HasUserArticleRights); Preisstrukturen: ActionPriceBL (Aktionspreise), ArticleVolumePricesBL (Staffeln), CustomerSpecialArticleBL (kundenindividuell); ArticleUnitBL/ArticleVariableBL/BarcodeBL ergänzen Einheiten, Variablen, Barcodes; ArticleLogBL protokolliert. +Aussage: Das System soll Artikel mit Einheiten, Barcodes, Protokoll und mehreren Preisebenen führen sowie funktionale Sonderartikel (Fracht, Rabatt, Kontingentausgleich) über Einstellungen referenzieren. +Ergebnis: Preisfindung und Belegautomatiken greifen auf definierte Artikelrollen zu. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Warehousing/ArticleBL.cs (GetFreightArticle, GetCustomerDiscountArticle, GetContractBalanceArticle) – Begründung: implementierte Sonderartikelrollen. + - [PRIMÄR] src/backend/Centron.BL/Warehousing/ActionPriceBL.cs, ArticleVolumePricesBL.cs – Begründung: implementierte Preisebenen. +Prüfidee: Frachtartikel in Einstellungen setzen; Beleg zieht ihn bei Frachtberechnung. +Tracelinks: StRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-054 +Titel: Lieferantenbelegkette im Einkauf +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Lieferant existiert. +Fakt: Es existieren SupplierOrders, SupplierDeliveryLists, SupplierInvoices, SupplierCreditVouchers und SupplierReceiptDocuments als eigene Belegbereiche (BestKopf2/BestPos2, WareKopf/WarePos u. a. im Schema) mit SpecificLogic-Klassen inkl. Kreditlimit-Beteiligung; SupplierOrderPerBranchBL steuert Bestellungen je Filiale. +Aussage: Das System soll die Einkaufsseite als eigene Belegkette (Bestellung, Wareneingang, Eingangsrechnung, Lieferantengutschrift) mit denselben Kernmechanismen wie die Verkaufsseite führen. +Ergebnis: Einkaufsvorgänge sind durchgängig dokumentiert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/SupplierOrders/SupplierOrderSpecificLogic.cs u. a. Supplier*-Ordner – Begründung: implementierte Einkaufsbelegarten. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, Tabellen BestKopf2/BestPos2, WareKopf/WarePos – Begründung: Datenmodell der Einkaufsbelege. +Prüfidee: Bestellung→Wareneingang→Eingangsrechnung durchspielen. +Tracelinks: StRS-009 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-055 +Titel: Versandabwicklung über GLS und Shipcloud +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Lager/Versand; GLS, Shipcloud +Vorbedingung: Versanddienstleister-Zugang konfiguriert. +Fakt: Projekte Centron.Api.Gls und Centron.Api.Shipcloud existieren; ShipcloudPackageTemplateBL verwaltet Pakettemplates. +Aussage: Das System soll Versandaufträge/Labels über GLS und Shipcloud erzeugen und Paketvorlagen verwalten. [HYPOTHESE] +Ergebnis: Versandlabel aus dem Belegprozess heraus. +Belege: + - [PRIMÄR] src/apis/Centron.Api.Gls, src/apis/Centron.Api.Shipcloud (Projekte); src/backend/Centron.BL/Sales/Receipts/ShipcloudPackageTemplateBL.cs – Begründung: implementierte Anbindungen. +Prüfidee: Testlabel über Shipcloud-Sandbox erzeugen. +Tracelinks: StRS-001, StRS-010 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: HYPOTHESE – Ablauf (aus welchem Beleg, welche Daten) nicht im Detail verifiziert. +``` + +``` +ID: SyRS-056 +Titel: Katalog- und Stammdatenübernahme von Distributoren/Anbietern +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Produktmanagement; ITscope, Icecat, COP, EGIS, TradePool-Quellen +Vorbedingung: Zugänge konfiguriert. +Fakt: Eigene API-Projekte für ITscope, Icecat, COP, EGIS existieren (src/apis); TradePoolBL importiert Handelsartikel (StartTradeImport) mit Distributorenliste und Kundenzuordnung; ArticleImportBL existiert. +Aussage: Das System soll Artikel- und Preisdaten aus externen Katalogquellen übernehmen und aktualisieren. +Ergebnis: Aktueller Artikelstamm ohne manuelle Pflege. +Belege: + - [PRIMÄR] src/backend/Centron.BL/TradePool/TradePoolBL.cs (StartTradeImport) – Begründung: implementierter Katalogimport. + - [PRIMÄR] src/apis/Centron.APIs.ITscopeDataAccess, Centron.APIs.IcecatDataAccess, Centron.APIs.CopDataAccess, Centron.APIs.EgisDataAccess – Begründung: implementierte Quellanbindungen. +Prüfidee: Testimport eines Artikels aus einer Quelle; Felder im Artikelstamm gefüllt. +Tracelinks: StRS-009, StRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 7. Web und Portale + +``` +ID: SyRS-060 +Titel: Browserbasierter Serviceclient (Nexus) für Kernprozesse +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker, Innendienst, Management +Vorbedingung: Nexus-Host betrieben; Benutzer angemeldet. +Fakt: CentronNexus (Blazor) enthält ServiceBoard (Ticketlisten, Kanban, Details, Mails, Berichte, Stoppuhren, KI-Zusammenfassung, Scheduler), Management, Office, ProductionOrderManagement, DocumentSigning, WebCart, WebOffer und Settings; DevExpress-Blazor-Komponenten werden laut README bevorzugt. +Aussage: Das System soll zentrale Service- und Verwaltungsprozesse zusätzlich im Browser bereitstellen (Ticketbearbeitung inkl. Kanban und Zeiterfassung, Verwaltung, Produktionsaufträge, Dokumentensignatur). +Ergebnis: Ortsunabhängige Bearbeitung ohne Desktop-Client. +Belege: + - [PRIMÄR] src/nexus/CentronNexus/ServiceBoard (Ordnerstruktur mit TicketList, Kanban, Stopwatches, TicketAiSummary u. a.) – Begründung: implementierte Web-Funktionsbereiche. +Prüfidee: Ticket im ServiceBoard öffnen, Status ändern, Zeit stoppen. +Tracelinks: StRS-007, StRS-015 +Konsolidierung: Kandidat: Ticketbearbeitung existiert doppelt (WPF-Modul Helpdesk und Nexus ServiceBoard) – im Web-Ziel eine Implementierung. +Übernahmewürdigkeit: übernehmen – Ausgangspunkt der Web-Neuimplementierung. +Status: belegt +``` + +``` +ID: SyRS-061 +Titel: Webshop auf Basis kundenindividueller Preise +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Endkunde (Web-Account) +Vorbedingung: Web-Account mit Kundenkontakt; Sonderpreise gepflegt. +Fakt: WebCart-Bereich in CentronNexus; README beschreibt: Artikel des Shops stammen aus den „Sonderpreisen" des Kunden; Bestellungen laufen über Warenkörbe mit Freigabewesen (SyRS-019). +Aussage: Das System soll Endkunden einen Shop anbieten, dessen Sortiment und Preise aus den kundenindividuellen Sonderpreisvereinbarungen stammen. [HYPOTHESE] +Ergebnis: Kunden bestellen zu vereinbarten Konditionen. +Belege: + - [PRIMÄR] src/nexus/CentronNexus/WebCart (Ordner) – Begründung: implementierter Shopbereich. + - [KONTEXT] README.md „WebCart" – Begründung: benennt Sonderpreise als Sortimentsquelle. +Prüfidee: Sonderpreis anlegen → Artikel erscheint im Shop des Kunden mit diesem Preis. +Tracelinks: StRS-015 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: HYPOTHESE – Preisquelle nur per README belegt; Codepfad (Sonderpreise→Shop) nicht nachvollzogen. +``` + +``` +ID: SyRS-062 +Titel: Konfigurierbare Self-Service-Formulare +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Endkunde; Innendienst +Vorbedingung: Formular definiert. +Fakt: SelfCareBL verwaltet Formulare (SelfCareForm) und deren Status (SelfCareFormState); WebRequestPageBL existiert. +Aussage: Das System soll konfigurierbare Formulare für Kundenanliegen bereitstellen und eingereichte Formulare mit Status verwalten. +Ergebnis: Strukturierte Kundenanliegen ohne Medienbruch. +Belege: + - [PRIMÄR] src/backend/Centron.BL/SelfCare/SelfCareBL.cs (SaveOrUpdateSelfCareForm, SelfCareFormState) – Begründung: implementierte Formular- und Statusverwaltung. +Prüfidee: Formular definieren, als Kunde einreichen, Status intern fortschreiben. +Tracelinks: StRS-015 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 8. Auswertung und Datenqualität + +``` +ID: SyRS-070 +Titel: Berichtswesen mit Gruppen und Standardberichten je Ausgabekanal +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Fachbereiche +Vorbedingung: Berichtsgruppe mit Defaults konfiguriert. +Fakt: ReportEngine verwaltet Berichte (ReportDataBL), Gruppen (ReportGroupBL, per GUID adressiert, z. B. ReportGroupConstants.MAHNUNG), Standardberichte je Typ (ReportDataDefault, Type Mail/Print), Abfragen (ReportDataQueryBL) und Benutzerzuordnungen (ReportUserBL); Rendering über FastReport (FastReportHelper). +Aussage: Das System soll Berichte in fachlichen Gruppen mit je einem Standardbericht pro Ausgabekanal (Druck, Mail) verwalten und über eine Berichts-Engine rendern. +Ergebnis: Prozesse (z. B. Mahnlauf) finden ihren Bericht automatisch. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ReportEngine (ReportGroupBL.cs, ReportDataDefaultBL.cs, FastReportHelper.cs) – Begründung: implementierte Gruppen-/Default-Logik. + - [PRIMÄR] DunningRunBL.GenerateReport (Nutzung group.Defaults nach SendType) – Begründung: durchgesetzte Kanalauswahl. +Prüfidee: Standardbericht „Print" der Gruppe ändern → Mahnlauf-Druck nutzt neuen Bericht. +Tracelinks: StRS-016 +Konsolidierung: Kandidat: paralleles Altberichtswesen (Reporting/ReportsBL, UI Reports) – im Ziel ein Berichtssystem. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-071 +Titel: Fachstatistiken über alle Kernprozesse +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Controlling, Vertrieb, Serviceleitung +Vorbedingung: Bewegungsdaten vorhanden. +Fakt: Statistics gliedert sich in Accounts, SaleStatistics, OrderStatistics, TicketStatistics, ContractStatistics, MspStatistics/MspCollectors, Administration; CacheTicketStatistic-Tabelle existiert. +Aussage: Das System soll Statistiken zu Umsätzen, Aufträgen, Tickets, Verträgen und MSP-Mengen bereitstellen; aufwendige Kennzahlen sollen zwischengespeichert werden. +Ergebnis: Kennzahlen in vertretbarer Antwortzeit. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Statistics (Unterordnerstruktur) – Begründung: implementierte Statistikbereiche. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, Tabelle CacheTicketStatistic – Begründung: Cache-Struktur existiert. +Prüfidee: Ticketstatistik über Zeitraum abrufen; zweiter Abruf schneller (Cache). +Tracelinks: StRS-016 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-072 +Titel: Objektübergreifende Volltextsuche mit deutscher Sprachanalyse +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Benutzer +Vorbedingung: Index aufgebaut. +Fakt: IndexSearch enthält IndexBuilder, IndexSearchBL (UpdateAllIndexes, SearchIndex, RequestUpdateFor) und einen GermanAnalyzer (Lucene); Fehlerfall ObjectIndexingFailedException existiert. +Aussage: Das System soll Fachobjekte in einem Volltextindex mit deutscher Sprachanalyse indizieren, inkrementell aktualisieren und durchsuchbar machen. +Ergebnis: Treffer über Objektgrenzen hinweg in einer Suche. +Belege: + - [PRIMÄR] src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs, GermanAnalyzer.cs – Begründung: implementierte Such-/Analyse-Logik. +Prüfidee: Objekt ändern → RequestUpdateFor aktualisiert Index; Suche findet neuen Begriff. +Tracelinks: StRS-017, StRS-008 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-073 +Titel: Massenänderungen über gespeicherte Vorlagen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Produktmanagement +Vorbedingung: Massenupdate-Vorlage definiert. +Fakt: MassUpdateBL bietet Vorlagenverwaltung und Startmethoden für Beleg-, Artikelpreis- und Kontodaten-Updates (StartReceiptPriceUpdate, StartArticlePriceUpdate, StartAccountDataUpdate) inkl. Suche betroffener Positionen. +Aussage: Das System soll Massenänderungen an Belegpreisen, Artikelpreisen und Kontodaten über wiederverwendbare Vorlagen ausführen. +Ergebnis: Konsistente Massenpflege mit Vorschau der betroffenen Objekte. +Belege: + - [PRIMÄR] src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs (StartArticlePriceUpdate u. a.) – Begründung: durchsetzende Updatepfade. +Prüfidee: Preisupdate-Vorlage auf Testartikelmenge ausführen; Preise geändert. +Tracelinks: StRS-011, StRS-016 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 9. Kommunikation und Zusammenarbeit + +``` +ID: SyRS-080 +Titel: Integrierte Kollaborationswerkzeuge +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Mitarbeiter +Vorbedingung: – +Fakt: CalendarBL (Darstellung/Synchronisation/Termine zu Tickets), AppointmentRequestBL, ToDoBL (Objekterbezug), ChatBL (Gruppen, Nachrichten bearbeiten/löschen), MyDayBL (WorkItems, Mitarbeiterauswahl), SocialMediaBL (Kommentare, Likes, Abos auf CRM-Aktivitäten/Tickets), UserNotificationBL und NotificationsHubHelper (Push an Webclients). +Aussage: Das System soll Kalender (inkl. Terminen zu Tickets), Aufgaben mit Objektbezug, Gruppenchat, persönliche Arbeitsvorräte, Aktivitäten-Feed und Push-Benachrichtigungen bereitstellen. +Ergebnis: Zusammenarbeit ohne Systemwechsel; Ereignisse erreichen die richtigen Benutzer. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Chats/ChatBL.cs, MyDay/MyDayBL.cs, ToDoArea/ToDoBL.cs, Calendar/CalendarBL.cs, SocialMedia/SocialMediaBL.cs, NexusNotifications/NotificationsHubHelper.cs – Begründung: implementierte Kollaborationsbausteine. +Prüfidee: ToDo an Ticket anlegen; Benachrichtigung erscheint beim Verantwortlichen. +Tracelinks: StRS-017 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-081 +Titel: Mailversand mit Konten, Vorlagen, Signaturen und Platzhaltern +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Benutzer; Mailserver +Vorbedingung: Mailkonto konfiguriert. +Fakt: Mail-Ordner (20 Klassen) enthält MailSettingsBL, MailSignatureBL, MailTemplateBL; Platzhalterersetzung über ReplacementBL/HelpdeskReplacementBL; Mahn-/Beleg-/Vertragsprozesse erzeugen Mails (GenerateMail in DunningRunBL, GetContractMailTemplate in AutomaticFacturaBL.Contracts); Guides zum Erstellen von Mailvorlagen existieren. +Aussage: Das System soll E-Mails über konfigurierte Konten mit Vorlagen, Signaturen und kontextbezogenen Platzhaltern erzeugen und aus Fachprozessen heraus versenden. +Ergebnis: Einheitliche, personalisierte Ausgangskommunikation. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Mail (MailSettingsBL.cs, MailSignatureBL.cs) und AutomaticFacturaBL.Contracts.GetContractMailTemplate – Begründung: implementierter Vorlagen-/Versandweg. + - [SEKUNDÄR] docs/guides/development/create-mail-templates.md – Begründung: dokumentiertes Vorlagensystem. +Prüfidee: Rechnungsversand nutzt Vorlage mit ersetzten Platzhaltern (Kunde, Belegnummer). +Tracelinks: StRS-018 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-082 +Titel: Outlook-Anbindung +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Innendienst; Microsoft Outlook +Vorbedingung: AddIn installiert. +Fakt: Projekt CentronNexus.OutlookAddIn existiert; BL/Outlook (OutlookAssetKindSearchBL) und assemblies/outlook unterstützen die Kopplung; Exchange-Synchronisation ist dokumentiert (docs/features/exchange-sync-bugprotokoll.md); GraphServiceClientHelper existiert (Microsoft Graph). +Aussage: Das System soll E-Mails und Termine mit Outlook/Exchange koppeln (AddIn, Graph-Zugriff) und E-Mails c-entron-Objekten zuordnen. [HYPOTHESE] +Ergebnis: Mails aus Outlook sind am Vorgang dokumentiert. +Belege: + - [PRIMÄR] src/nexus/CentronNexus.OutlookAddIn (Projekt); src/backend/Centron.BL/Helpers/GraphServiceClientHelper.cs – Begründung: implementierte Anbindungsbausteine. + - [KONTEXT] docs/features/exchange-sync-bugprotokoll.md – Begründung: dokumentierte Exchange-Synchronisation. +Prüfidee: Mail im AddIn einem Ticket zuordnen; im Ticket sichtbar. +Tracelinks: StRS-018 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: HYPOTHESE – Funktionsumfang des AddIns nicht im Detail gelesen. +``` + +``` +ID: SyRS-083 +Titel: Telefonieereignisse mit Kontaktauflösung und Synchronisation +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Innendienst; TK-Anlage +Vorbedingung: TAPI eingerichtet. +Fakt: PhoneCallBL erzeugt Anrufdatensätze, löst Kontakte per Rufnummer auf (SearchContactPersonByPhoneNumberV2), synchronisiert Anrufe (SyncPhoneCalls) und kennt Synchronisationsteilnehmer (GetCallSyncMembers). +Aussage: Das System soll Telefonieereignisse erfassen, Anrufern Kontakte zuordnen und Anruflisten zwischen Arbeitsplätzen synchronisieren. +Ergebnis: Anrufe sind dokumentiert und teamweit sichtbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Tapi/PhoneCallBL.cs – Begründung: implementierte Telefonielogik. +Prüfidee: Anruf simulieren; Kontakt wird aufgelöst, Anrufliste synchronisiert. +Tracelinks: StRS-026 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround – TAPI desktopgebunden; fachliche Funktion übernehmen, Technik ersetzen. +Status: belegt +``` + +## 10. Geräte, Projekte, RMA + +``` +ID: SyRS-090 +Titel: Gerätebestand mit automatischer Datenübernahme (RMM/docuFORM/SNMP) +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: MSP-Betrieb; RMM-Systeme, docuFORM +Vorbedingung: Connector konfiguriert. +Fakt: AccountDeviceBL verwaltet Geräte mit Logs und Ticketbezug (AccountDevicesToTickets-Tabelle); AssetManagement-Tabellen (Devices, Patch, SnmpMib*, WindowsServices, DeviceDependencies, ServiceConnectorLogs) belegen automatische Erhebung; RmmConnectionSettingsBL und docuFORM-API existieren; DocuBoard-BL verwaltet Partner-/Artikelzuordnung und AD-Benutzer-Ausschlüsse. +Aussage: Das System soll Kundengeräte inkl. automatisch erhobener Detaildaten (Patches, SNMP-Werte, Windows-Dienste, Abhängigkeiten) führen, mit Tickets verknüpfen und Konnektorläufe protokollieren. +Ergebnis: Aktueller, ticketfähiger Gerätebestand je Kunde. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Devices/AccountDeviceBL.cs; SSMS_DB_SCHEMA.sql Tabellen AssetManagement* / AccountDevicesToTickets – Begründung: implementierte Verwaltung und Datenmodell der automatischen Erhebung. + - [PRIMÄR] src/backend/Centron.BL/DataExchange/Rmm/RmmConnectionSettingsBL.cs; Centron.Api.docuFORM – Begründung: implementierte Konnektoren. +Prüfidee: Konnektorlauf ausführen → ServiceConnectorLog-Eintrag, Gerätedaten aktualisiert. +Tracelinks: StRS-019 +Konsolidierung: Kandidat: Gerätedaten in AccountDevices und AssetManagementDevices – siehe StRS-019. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-091 +Titel: Projektverwaltung (Vertrieb und Service) +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Projektleiter, Vertrieb +Vorbedingung: – +Fakt: ProjectBL (Projektlisten), CrmProjects (Vertriebsprojekte), TicketProjectBL (Ticketprojekte mit Aufgaben/Abhängigkeiten und Einstellungen) existieren; Belege tragen ProjectNumber. +Aussage: Das System soll Projekte als Klammer über Belege und Tickets führen, mit Aufgaben und Abhängigkeiten im Serviceumfeld. +Ergebnis: Projektbezogene Sicht auf Vorgänge. +Belege: + - [PRIMÄR] src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs; Projects/ProjectBL.cs – Begründung: implementierte Projektverwaltungen. +Prüfidee: Ticketprojekt mit zwei abhängigen Aufgaben anlegen; Abhängigkeit wird gespeichert. +Tracelinks: StRS-020 +Konsolidierung: Kandidat: mehrere Projektkonzepte (Project, CrmProject, TicketProject) – siehe StRS-020. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-092 +Titel: Fertigungsaufträge mit Positionen und Protokoll +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Fertigung/Technik +Vorbedingung: Auftrag/Stückliste vorhanden. +Fakt: ProductionOrderBL verwaltet Fertigungsaufträge, Positionen und Logs; ProductionBL ergänzt; Nexus enthält ProductionOrderManagement; UI-Modul Production existiert. +Aussage: Das System soll Fertigungsaufträge mit Positionen führen, Statusänderungen protokollieren und die Bearbeitung auch im Web ermöglichen. +Ergebnis: Fertigungsfortschritt nachvollziehbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs (SaveProductionOrder, SaveProductionOrderLog) – Begründung: implementierte Fertigungslogik. +Prüfidee: Fertigungsauftrag anlegen, Status ändern → Logeintrag. +Tracelinks: StRS-020 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-093 +Titel: RMA-Vorgänge mit Artikelhistorie und Versandart +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Service, Lager +Vorbedingung: Reklamierter Artikel bekannt. +Fakt: RmaBL verwaltet RMA-Vorgänge (SaveRma) mit RMA-Artikeln (CreateNewRmaArticle), Artikelhistorie (ArticleRmaHistoryDTO, RmaArticleHistory) und Ticketbezug (GetRmaByHelpdeskI3D); RmaSendKindBL verwaltet Versandarten; Tabelle Rma existiert. +Aussage: Das System soll RMA-Vorgänge mit Artikeln, Historie, Versandart und optionalem Ticketbezug führen. +Ergebnis: Reklamationen sind vollständig dokumentiert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs – Begründung: implementierte RMA-Logik. +Prüfidee: RMA mit zwei Artikeln anlegen; Historie je Artikel abrufbar. +Tracelinks: StRS-021 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 11. Datenschutz, Audit, Betrieb + +``` +ID: SyRS-100 +Titel: DSGVO-Unterstützung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Datenschutzbeauftragter +Vorbedingung: – +Fakt: DsgvoWebServiceBL (Administration/Documents/Dsgvo) und der Bereich Administration/DataSecurity existieren. +Aussage: Das System soll DSGVO-bezogene Dokumente/Prozesse verwalten (z. B. Auskunft/Verarbeitungsnachweise). [HYPOTHESE] +Ergebnis: Datenschutzanforderungen sind im System abgebildet. +Belege: + - [PRIMÄR] src/backend/Centron.BL/WebServices/Administration/Documents/Dsgvo/DsgvoWebServiceBL.cs; Ordner Administration/DataSecurity – Begründung: DSGVO-Funktionsbereich existiert im Code. +Prüfidee: DSGVO-Dokument zu einem Kunden erzeugen/abrufen. +Tracelinks: StRS-022 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: HYPOTHESE – konkreter Funktionsumfang (Auskunft, Löschung, Anonymisierung?) nicht nachvollzogen. +``` + +``` +ID: SyRS-101 +Titel: Verschlüsselte Zugangsdatenablage mit Zugriffs- und Änderungsprotokoll +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Servicetechniker, Administrator +Vorbedingung: Berechtigung vorhanden. +Fakt: PasswordManagementBL speichert Passwörter mit Entschlüsselung beim Abruf (GetDecryptedPassword); getrennte Protokolle: PasswordManagementAccessLogBL (Zugriffe), PasswordManagementLogBL (Änderungen); Typen (PasswordManagementTypeBL) und Schlagworte (PasswordManagementKeywordBL) strukturieren; PasswordManagementUpdateBL für Massenpflege. +Aussage: Das System soll Kundenzugangsdaten verschlüsselt ablegen, jeden Abruf und jede Änderung getrennt protokollieren und Einträge über Typen/Schlagworte strukturieren. +Ergebnis: Auditierbarer, geschützter Zugangsdatenspeicher. +Belege: + - [PRIMÄR] src/backend/Centron.BL/PasswordManagementArea/PasswordManagementBL.cs (GetDecryptedPassword), PasswordManagementAccessLogBL.cs, PasswordManagementLogBL.cs – Begründung: durchsetzende Verschlüsselungs- und Protokolllogik. +Prüfidee: Passwort abrufen → AccessLog-Eintrag; ändern → Log-Eintrag. +Tracelinks: StRS-025, StRS-022 +Konsolidierung: Kandidat: BL/PasswordManager vs. PasswordManagementArea – siehe StRS-025. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-102 +Titel: Feldgenaue Änderungsprotokollierung markierter Entitäten +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System (Persistenz) +Vorbedingung: Entität ist für ChangeTracking markiert (Attribut). +Fakt: ChangeTrackingEventListener (NHibernate IPreUpdateEventListener) vergleicht bei jedem Update Alt-/Neuwerte attributierter Properties und schreibt ChangeLog-Einträge; ImportHistoryBL protokolliert Importe. +Aussage: Das System soll Änderungen an gekennzeichneten Entitäten feldgenau (alter Wert, neuer Wert, Benutzer, Zeitpunkt) protokollieren und Importe historisieren. +Ergebnis: Nachvollziehbare Datenänderungen ohne Zutun der Fachlogik. +Belege: + - [PRIMÄR] src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs, Methode OnPreUpdate – Begründung: durchsetzender Protokollmechanismus. + - [PRIMÄR] src/backend/Centron.BL/ChangeTracking/History/ImportHistoryBL.cs – Begründung: implementierte Importhistorie. +Prüfidee: Markiertes Feld ändern → ChangeLog-Eintrag mit Alt-/Neuwert. +Tracelinks: StRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 12. Plattform, Konfiguration, Betrieb + +``` +ID: SyRS-110 +Titel: Mandanten, Filialen und filialbezogene Ressourcen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: – +Fakt: MandatorBL, BranchBL, BranchRevenueAndExpenseAccountBL, Filiale-Tabelle; Filialbezug in Nummernkreisen (GetNumberGroup(branch)), Lägern (GetDefaultWarehouseI3DFromBranch), Rechten (MANAGE_RIGHTS_ONLY_OWN_BRANCH in AppRightsBL.GetAllRightGroups) und Belegen (BranchI3D). +Aussage: Das System soll Mandanten und Filialen führen und Nummernkreise, Läger, Erlöskonten, Rechtegruppen und Belege filialbezogen zuordnen. +Ergebnis: Filialgetrennte Abläufe bei zentraler Datenhaltung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode GetAllRightGroups (Branch-Filter) – Begründung: durchgesetzter Filialbezug im Rechtesystem. + - [PRIMÄR] src/backend/Centron.BL/Administration/Company/BranchBL.cs, BranchRevenueAndExpenseAccountBL.cs – Begründung: implementierte Filialressourcen. +Prüfidee: Rechteverwalter mit „nur eigene Filiale" sieht nur Gruppen seiner Filiale. +Tracelinks: StRS-024, StRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-111 +Titel: Zentrale typisierte Anwendungskonfiguration +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: – +Fakt: ApplicationSettingID (enum mit hunderten IDs) und ApplicationSettingDefinitions definieren Einstellungen typisiert mit Beschreibung; Tabelle ApplicationSettings existiert; AppSettingsBL/AppSettingsGroupBL lesen gruppierte Einstellungen; ein Settings-Management-Guide existiert. +Aussage: Das System soll Verhaltensparameter zentral, typisiert und dokumentiert in der Datenbank verwalten und Fachprozessen gruppiert bereitstellen. +Ergebnis: Konfigurierbares Systemverhalten ohne Codeänderung. +Belege: + - [PRIMÄR] src/backend/Centron.Interfaces/Administration/Settings/ApplicationSettingID.cs, ApplicationSettingDefinitions.cs; SSMS_DB_SCHEMA.sql Tabelle ApplicationSettings – Begründung: implementiertes Konfigurationsmodell. + - [SEKUNDÄR] docs/guides/development/settings-management.md – Begründung: dokumentiertes Verfahren. +Prüfidee: Einstellung ändern → abhängiger Prozess verhält sich entsprechend (z. B. DATEV-Pfad). +Tracelinks: StRS-024, StRS-005 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-112 +Titel: Versionierte Datenbankmigration über Skriptmethoden +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Änderbarkeit des Schemas) +Akteur: System (Update); Administrator +Vorbedingung: Neue Programmversion wird eingespielt. +Fakt: Administration/Scripts/ScriptMethods enthält tausende nummerierte ScriptMethodNNNNN-Klassen (z. B. ScriptMethod11799) für Schema-/Datenmigrationen; Regeln in docs/reference/database/script-rules.md und docs/guides/database/create-scripts.md. +Aussage: Das System soll Datenbankänderungen als nummerierte, versionierte Skriptmethoden ausliefern und beim Update in Reihenfolge ausführen. +Ergebnis: Reproduzierbare Schema-Migration je Version. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts (ScriptMethod*-Klassen) – Begründung: implementierter Migrationsmechanismus. + - [SEKUNDÄR] docs/reference/database/script-rules.md – Begründung: dokumentierte Skriptregeln. +Prüfidee: Update auf leerer Altdatenbank führt alle Skripte aus; Schema entspricht SSMS_DB_SCHEMA.sql. +Tracelinks: StRS-024 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround – Mechanismus ist migrationsspezifisch; im Ziel durch Standard-Migrationswerkzeug ersetzen. +Status: belegt +``` + +``` +ID: SyRS-113 +Titel: Serverseitige Hintergrundverarbeitung +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System (Background Service) +Vorbedingung: Dienst konfiguriert. +Fakt: BackgroundServiceBL existiert; docs/Background Service/DataQualityService.md beschreibt einen Datenqualitätsdienst; MailScanner, TaskManager und Konnektoren benötigen laufende Hintergrundverarbeitung. +Aussage: Das System soll wiederkehrende Verarbeitungen (Datenqualität, Postfachscan, Tasks, Konnektoren) als serverseitige Hintergrunddienste ausführen. +Ergebnis: Automatiken laufen ohne angemeldeten Client. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/BackgroundServices/BackgroundServiceBL.cs – Begründung: implementierter Dienstrahmen. + - [SEKUNDÄR] docs/Background Service/DataQualityService.md – Begründung: dokumentierter Dienst. +Prüfidee: Dienst starten; DataQualityService-Lauf protokolliert. +Tracelinks: StRS-018, StRS-002 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-114 +Titel: Nutzungstelemetrie +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Analysierbarkeit der Nutzung) +Akteur: Hersteller +Vorbedingung: – +Fakt: TelemetryBL erfasst API-Aufrufe, KI- und MCP-Toolnutzung batchweise (UpsertApiCallBatch, UpsertMcpToolUsageBatch) mit Abrufmethoden für „completed pending"-Daten. +Aussage: Das System soll Nutzungsdaten (API-/KI-/Toolaufrufe) sammeln und zur Übertragung bereitstellen. +Ergebnis: Auswertbare Nutzungsstatistik. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Telemetry/TelemetryBL.cs – Begründung: implementierte Telemetrieerfassung. +Prüfidee: KI-Aufruf ausführen → Telemetrie-Datensatz vorhanden. +Tracelinks: StRS-028 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – im Ziel mit Datenschutz-Review. +Status: belegt +``` + +``` +ID: SyRS-115 +Titel: Auslieferung als Windows-Installation und Windows-Dienst +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Installierbarkeit) +Akteur: Administrator +Vorbedingung: Windows-Umgebung, MSSQL-Server erreichbar. +Fakt: deployment/ enthält WixSharpInstaller und centron-Pakete; der Webservice existiert als Centron.Host.WindowsService und Centron.Host.Console; der Client ist eine WPF-Anwendung (Windows). +Aussage: Das System soll als installierbares Windows-Paket (Client) und als Windows-Dienst bzw. Konsolenprozess (Webservice) betreibbar sein. +Ergebnis: Standardisierte Installation beim Kunden. +Belege: + - [PRIMÄR] deployment/WixSharpInstaller; src/webservice/Centron.Host.WindowsService – Begründung: implementierte Installations-/Betriebsartefakte. +Prüfidee: Installer bauen und Dienst registrieren. +Tracelinks: StRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet – On-Premise-Windows-Verteilung entfällt im SaaS-Ziel; Übergangsbetrieb beachten. +Status: belegt +``` + +``` +ID: SyRS-116 +Titel: Containerisierter Linux-Betrieb des Webservice +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Plattformunabhängigkeit des Backends) +Akteur: Betrieb/DevOps +Vorbedingung: Container-Runtime vorhanden. +Fakt: docker/ enthält c-entron-api, c-entron-webservice, c-entron-demo, Mailcatcher, Regressionstest-DB und compose-Definitionen; docs/guides/services/web-service-on-linux.md beschreibt den Linux-Betrieb. +Aussage: Das System soll den Webservice auch als Linux-Container (inkl. Compose-Umgebungen für Demo/Test) betreiben können. +Ergebnis: Backend läuft plattformunabhängig; Testumgebungen reproduzierbar. +Belege: + - [PRIMÄR] docker/ (Dockerfiles, compose) – Begründung: implementierte Containerisierung. + - [SEKUNDÄR] docs/guides/services/web-service-on-linux.md – Begründung: dokumentierter Linux-Betrieb. +Prüfidee: compose-Umgebung starten; Webservice antwortet. +Tracelinks: StRS-015 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – Grundlage der SaaS-Migration. +Status: belegt +``` + +``` +ID: SyRS-117 +Titel: Deutschsprachige Oberfläche mit englischer Übersetzung +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Benutzbarkeit (Sprachangemessenheit) +Akteur: Alle Benutzer +Vorbedingung: – +Fakt: Lokalisierung über LocalizedStrings.resx (Deutsch als Basissprache) und LocalizedStrings.en.resx (Englisch); verbindliche „German-First"-Regeln in general-structure.md; ResXManager.config.xml im Repo. +Aussage: Das System soll alle Benutzertexte primär in Deutsch führen und Englisch als zweite Sprache über Ressourcendateien unterstützen. +Ergebnis: Konsistent deutsche Oberfläche, umschaltbar auf Englisch. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Resources/LocalizedStrings.Designer.cs (Ressourcensystem); Centron.WPF.UI/Localization – Begründung: implementiertes Lokalisierungssystem. + - [SEKUNDÄR] docs/getting-started/general-structure.md (German-First Language Policy) – Begründung: verbindliche Sprachregel. +Prüfidee: Sprachumschaltung auf Englisch übersetzt Standarddialoge. +Tracelinks: StRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – Mehrsprachigkeit im Ziel von Beginn an vorsehen. +Status: belegt +``` + +``` +ID: SyRS-118 +Titel: Strukturiertes Anwendungs- und Sicherheitslogging +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Diagnostizierbarkeit) +Akteur: Betrieb, Support +Vorbedingung: – +Fakt: NLog wird flächig genutzt (LogManager.GetCurrentClassLogger in BasicAuthenticator, TwoFactorAuthBL, ReceiptCartReleaseSystemBL u. v. a.); Anmeldevorgänge werden mit RequestId, Benutzer, IP und Maschine strukturiert protokolliert (AuthObject.ToString, Logger.Info/Warn in Authenticator-Klassen). +Aussage: Das System soll fachliche und sicherheitsrelevante Ereignisse (insbesondere An-/Abmeldung mit Kontext) strukturiert protokollieren. +Ergebnis: Sicherheitsvorfälle und Fehler sind rekonstruierbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs (Logger.Info/Warn mit RequestId/UserName/AuthObject) – Begründung: durchgesetztes Sicherheitslogging. +Prüfidee: Fehlanmeldung erzeugt Warn-Eintrag mit Kontext. +Tracelinks: StRS-013, StRS-022 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-119 +Titel: Mengen-/Lastverhalten: Paging, Caching, Batching +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Performance-Effizienz (Zeitverhalten bei großen Datenmengen) +Akteur: System +Vorbedingung: Große Datenbestände (1.558 Tabellen, Massendaten in Belegen/Tickets). +Fakt: PagingList wird in Abfragen genutzt (z. B. TaskManagementTaskBL.GetTasks); Session-Cache (Session.Advanced.Cache.GetOrAdd in ReceiptBL), CachedTableBL, Batch-Verarbeitung (Batch(2000) in AutomaticFacturaBL.SearchSpecialArticleToContractHead), ConditionalWeakTable gegen Mehrfachladen; Statistik-Cache-Tabellen. +Aussage: Das System soll große Ergebnismengen seitenweise liefern, teure Ermittlungen cachen und Massenzugriffe in Batches ausführen. +Ergebnis: Antwortzeiten bleiben bei Massendaten nutzbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs (Batch(2000)); ReceiptBL.GetCompanyGroupCustomerI3DForReceiptData (Cache.GetOrAdd) – Begründung: implementierte Mechanismen. +Prüfidee: Abfrage mit 10.000 Treffern liefert Seiten; zweiter Aufruf gecachter Ermittlung ohne SQL. +Tracelinks: StRS-001, StRS-016 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-120 +Titel: KI-Dienste-Anbindung mit Modellkatalog +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: System; KI-Anbieter (OpenAI-kompatibel) +Vorbedingung: API-Zugang konfiguriert; Link validiert. +Fakt: ArtificialIntelligence enthält ApiClientFactory, OpenAiApiClient, ChatModelApiClient, TextRatingApiClient, TicketCategoryApiClient, AiHttpModelCatalogClient und AiApiLinkValidator. +Aussage: Das System soll KI-Funktionen über austauschbare API-Clients (Chat, Textbewertung, Ticketkategorisierung) mit Modellkatalog und Endpunktvalidierung anbinden. +Ergebnis: KI-Funktionen konfigurierbar je Kunde. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ArtificialIntelligence (ApiClientFactory.cs, AiApiLinkValidator.cs u. a.) – Begründung: implementierte Anbindungsarchitektur. +Prüfidee: Ungültiger Endpunkt wird vom Validator abgewiesen; gültiger liefert Modellliste. +Tracelinks: StRS-028 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-121 +Titel: Versionierte REST-API +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Externe Anwendungen, Nexus +Vorbedingung: Authentifizierung vorhanden. +Fakt: Centron.Controllers/Controllers gliedert sich in Unversioned (Auth) und v1 (Accounts, Administration, Contracts, Customers, DataExchange, Helpdesks, Integrations, Offers, Orders, Receipts, SelfCare, Tickets, WebAccount, WebVersion, Nexoware); Dokument requests-and-responses.md beschreibt die Konventionen. +Aussage: Das System soll fachliche Operationen über eine versionierte REST-API (v1) mit stabilen Ressourcenbereichen anbieten. +Ergebnis: Integrationsfähige, versionsstabile Schnittstelle. +Belege: + - [PRIMÄR] src/webservice/Centron.Controllers/Controllers/v1 (Ressourcenordner) – Begründung: implementierte API-Struktur. + - [SEKUNDÄR] docs/reference/architecture/requests-and-responses.md – Begründung: dokumentierte Konventionen. +Prüfidee: v1-Endpunkt (z. B. Tickets) mit JWT aufrufen. +Tracelinks: StRS-015, StRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen – API-First im Ziel. +Status: belegt +``` + +``` +ID: SyRS-122 +Titel: Client-Versionsabgleich mit dem Webservice +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: WPF-Client, Webservice +Vorbedingung: Client verbindet sich mit Webservice. +Fakt: VersionBL (WebVersion), WebVersion-Controllerbereich und ApplicationVersionBL.SaveLogin (Speicherung der Anmeldeversion) existieren; LicenseManager berücksichtigt Versionsbeschränkungen der Lizenz (CheckLicenseVersion) inkl. Sonderbehandlung für c-entron-Delphi-Versionsnummern (TryFixCentronDelphiVersionNumber). +Aussage: Das System soll Client- und Serverversionen beim Anmelden abgleichen, protokollieren und lizenzseitige Versionsgrenzen durchsetzen; für das parallel betriebene Delphi-Altsystem gilt eine dokumentierte Ausnahme. +Ergebnis: Inkompatible/unlizenzierte Versionen werden abgewiesen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, Methode TryFixCentronDelphiVersionNumber (dokumentierte Ausnahme) – Begründung: durchgesetzter Versionsabgleich mit Sonderfall. +Prüfidee: Anmeldung mit zu hoher Versionsnummer bei versionsbeschränkter Lizenz wird abgelehnt. +Tracelinks: StRS-014 +Konsolidierung: nein +Übernahmewürdigkeit: Sonderfall – Delphi-Ausnahme ist Altbestandspflege; Grundfunktion übernehmen. +Status: belegt +``` + +``` +ID: SyRS-123 +Titel: Erwartete Ereignisse überwachen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Betrieb, Serviceleitung +Vorbedingung: Erwartetes Ereignis je Konto definiert. +Fakt: ExpectedEventsBL verwaltet erwartete Ereignisse und Logeinträge je Konto (SaveExpectedEventLogEntry, GetAllExpectedEventLogEntriesByAccount). +Aussage: Das System soll definierte erwartete Ereignisse (z. B. regelmäßige Datenlieferungen) je Konto überwachen und Einträge protokollieren. +Ergebnis: Ausbleibende Ereignisse werden erkennbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs – Begründung: implementierte Ereignisverwaltung. +Prüfidee: Ereignislog je Konto abrufen. +Tracelinks: StRS-019 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Protokoll.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Protokoll.md new file mode 100644 index 00000000..1f2e4308 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Protokoll.md @@ -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. diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/RawResult.json b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/RawResult.json new file mode 100644 index 00000000..d30cd1b9 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/RawResult.json @@ -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} diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Stderr.log b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/Stderr.log new file mode 100644 index 00000000..e69de29b diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/anforderungen.json b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/anforderungen.json new file mode 100644 index 00000000..99254f86 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/anforderungen.json @@ -0,0 +1,2144 @@ +[ + { + "id": "StRS-001", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Durchgängige Auftragsabwicklung über Belegkette", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, SyRS-011, SyRS-012", + "konsolidierung": "nein", + "pruefidee": "Für einen Testkunden Angebot→Auftrag→Lieferschein→Rechnung erzeugen; jede Stufe referenziert die Vorstufe.", + "qm": "", + "uebernahme": "übernehmen – Kernprozess jedes ERP-Systems." + }, + { + "id": "StRS-002", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Automatisierte wiederkehrende Vertragsabrechnung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020", + "konsolidierung": "nein", + "pruefidee": "Vertrag mit Monatsintervall anlegen, Abrechnungslauf zum Stichtag ausführen; genau eine Rechnung entsteht, LastInvoiceDate/nächstes Datum korrekt fortgeschrieben.", + "qm": "", + "uebernahme": "übernehmen – zentrales Umsatzmodell (MSP/Servicevertrieb) der Zielgruppe." + }, + { + "id": "StRS-003", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Forderungsmanagement mit Mahnwesen und offenen Posten", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-021, SyRS-022", + "konsolidierung": "nein", + "pruefidee": "Überfällige Rechnung dreimal anmahnen; vierte Mahnung wird abgelehnt (ArgumentOutOfRangeException-Pfad), Mahnstopp verhindert Aufnahme in den Lauf.", + "qm": "", + "uebernahme": "übernehmen – gesetzlich/kaufmännisch erforderliches Forderungsmanagement." + }, + { + "id": "StRS-004", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "SEPA-Zahlungsverkehr für Lastschriften", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "Export mit zwei Testrechnungen ausführen; XML validiert gegen pain.008-Schema, erneuter Lauf enthält die Rechnungen nicht mehr.", + "qm": "", + "uebernahme": "übernehmen – Zahlungsabwicklung ist Pflicht; Formatversionen im Zielsystem aktualisieren." + }, + { + "id": "StRS-005", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Übergabe an die Finanzbuchhaltung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-024", + "konsolidierung": "nein", + "pruefidee": "Abgeschlossene Rechnung exportieren; zweiter Exportversuch wird als bereits exportiert erkannt.", + "qm": "", + "uebernahme": "übernehmen – Kernanforderung im deutschen Markt (DATEV-Anbindung)." + }, + { + "id": "StRS-006", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kassenführung in Filialen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-024", + "konsolidierung": "nein", + "pruefidee": "Kassenbuchung zu einem Beleg anlegen und im FiBu-Export „Cashbook\" wiederfinden.", + "qm": "", + "uebernahme": "übernehmen – für Filialbetriebe mit Barverkauf erforderlich." + }, + { + "id": "StRS-007", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Serviceticket-Management mit abrechenbarer Zeiterfassung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-030, SyRS-031, SyRS-032", + "konsolidierung": "nein", + "pruefidee": "Ticket mit Zeiteintrag anlegen, signieren, abrechnen; danach ist Verschieben/Löschen des Zeiteintrags gesperrt.", + "qm": "", + "uebernahme": "übernehmen – Kern des Servicegeschäfts (Systemhaus/MSP)." + }, + { + "id": "StRS-008", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Zentrale Kunden- und Kontaktverwaltung (CRM)", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "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.", + "pruefidee": "Konto mit Kunden- und Lieferantenrolle anlegen; beide Rollen in Verkauf und Einkauf nutzbar.", + "qm": "", + "uebernahme": "übernehmen – Stammdatenbasis aller Prozesse; Zusammenführung der Doppelstruktur nötig." + }, + { + "id": "StRS-009", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Einkauf mit elektronischer Distributorenanbindung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-050", + "konsolidierung": "nein", + "pruefidee": "Testbestellung im OpenTrans-2.1-Format erzeugen und gegen Schema prüfen.", + "qm": "", + "uebernahme": "übernehmen – zentrale Effizienzfunktion für IT-Handel." + }, + { + "id": "StRS-010", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Lager- und Bestandsführung mit Inventur", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-051, SyRS-052", + "konsolidierung": "nein", + "pruefidee": "Umbuchung zwischen zwei Lägern erzeugen; RebookLog-Eintrag vorhanden; Inventur ändert Bestand nachvollziehbar.", + "qm": "", + "uebernahme": "übernehmen – Grundfunktion Warenwirtschaft." + }, + { + "id": "StRS-011", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Artikelstamm mit differenzierter Preisfindung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-014, SyRS-053", + "konsolidierung": "nein", + "pruefidee": "Artikel mit Listen-, Aktions- und Sonderpreis anlegen; Belegposition zieht die dokumentierte Priorität.", + "qm": "", + "uebernahme": "übernehmen – Kern der Warenwirtschaft." + }, + { + "id": "StRS-012", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Rollen- und rechtebasierter Zugriffsschutz", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-001, SyRS-004, SyRS-005", + "konsolidierung": "nein", + "pruefidee": "Benutzer nur mit SHOW_HELPDESK_ONLY_OWN sieht ausschließlich Tickets, bei denen er Bearbeiter/Verantwortlicher ist.", + "qm": "", + "uebernahme": "übernehmen – Compliance-Grundanforderung." + }, + { + "id": "StRS-013", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kontrollierte Benutzeranmeldung mit Mehrfaktor-Option", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-001, SyRS-002, SyRS-003", + "konsolidierung": "nein", + "pruefidee": "Anmeldeversuch mit deaktiviertem Konto → Fehlermeldung „Mitarbeiterkonto wurde deaktiviert\"; 2FA-Pflicht nach Ablauf der Gültigkeitsdauer.", + "qm": "", + "uebernahme": "übernehmen – Sicherheitsgrundanforderung; Passwort-Hashing im Zielsystem modernisieren (siehe SwRS-Sicherheit)." + }, + { + "id": "StRS-014", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Lizenzbasierte Nutzungssteuerung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-006", + "konsolidierung": "nein", + "pruefidee": "Bei Lizenzanzahl n meldet sich Benutzer n+1 an → Fehlermeldung Lizenzmaximum.", + "qm": "", + "uebernahme": "Sonderfall – herstellerseitiges Geschäftsmodell; im SaaS-Zielsystem durch Abo-/Mandantenmodell zu ersetzen." + }, + { + "id": "StRS-015", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kundenselbstbedienung über Webportal", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-060, SyRS-061", + "konsolidierung": "nein", + "pruefidee": "Web-Account legt Warenkorb an, Prüfer lehnt ab → Status DeclinedByChecker; nach Freigabe entsteht Bestellung.", + "qm": "", + "uebernahme": "übernehmen – strategisch für SaaS-Ziel (Self-Service)." + }, + { + "id": "StRS-016", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Auswertungen, Statistiken und Berichte", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-070, SyRS-071", + "konsolidierung": "nein", + "pruefidee": "Mahnlauf mit SendType Mail nutzt den Mail-Standardbericht der Gruppe „Mahnung\".", + "qm": "", + "uebernahme": "übernehmen – Steuerungsrelevanz; Berichtstechnologie im Ziel neu wählbar." + }, + { + "id": "StRS-017", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Interne Zusammenarbeit und Selbstorganisation", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-080", + "konsolidierung": "nein", + "pruefidee": "Chatnachricht senden/ändern/löschen; MyDay-Eintrag anlegen und in der Tagesansicht sehen.", + "qm": "", + "uebernahme": "übernehmen – Kollaborationsfunktionen; Chat ggf. durch Standardtools ersetzbar (Bewertung im Ziel)." + }, + { + "id": "StRS-018", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Integrierte E-Mail-Verarbeitung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-081, SyRS-082", + "konsolidierung": "nein", + "pruefidee": "Eingehende Mail auf überwachtem Postfach erzeugt gemäß Workflow ein Ticket mit Protokolleintrag.", + "qm": "", + "uebernahme": "übernehmen – zentraler Kommunikationskanal." + }, + { + "id": "StRS-019", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Verwaltung von Kundengeräten und Managed Services", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020, SyRS-090", + "konsolidierung": "Kandidat: Gerätedaten liegen mehrfach vor (AccountDevices, AssetManagementDevices, Vertrags-Stammdatenlisten) – im Zielsystem zu einem Gerätekonzept zusammenführen.", + "pruefidee": "Zählerstand importieren; Vertragsabrechnung berechnet Klicks über Freimenge korrekt.", + "qm": "", + "uebernahme": "übernehmen – MSP-Geschäftsmodell." + }, + { + "id": "StRS-020", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Projekte und Produktionsaufträge", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-091, SyRS-092", + "konsolidierung": "Kandidat: Projektbegriffe (Project, CrmProject, TicketProject, ProjectNumber am Beleg) sind getrennt implementiert – im Zielsystem vereinheitlichen.", + "pruefidee": "Fertigungsauftrag mit zwei Positionen anlegen; Statuswechsel wird im Log protokolliert.", + "qm": "", + "uebernahme": "übernehmen – verbreitetes Arbeitsmodell der Zielkunden." + }, + { + "id": "StRS-021", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Reklamations-/RMA-Abwicklung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-093", + "konsolidierung": "nein", + "pruefidee": "RMA aus Ticket erzeugen; Artikelhistorie zeigt den Vorgang.", + "qm": "", + "uebernahme": "übernehmen – Standardprozess im Hardwaregeschäft." + }, + { + "id": "StRS-022", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Datenschutz und Datensicherheit (DSGVO)", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-100, SyRS-101", + "konsolidierung": "nein", + "pruefidee": "Abruf eines gespeicherten Passworts erzeugt einen AccessLog-Eintrag mit Benutzer und Zeit.", + "qm": "", + "uebernahme": "übernehmen – gesetzliche Anforderung." + }, + { + "id": "StRS-023", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Revisionsfähigkeit durch Historien und Belegversionen", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-015, SyRS-102", + "konsolidierung": "nein", + "pruefidee": "Rechnung zweimal ändern; zwei Versionssätze in RechKopfVersions, ChangeLog enthält Feldänderungen.", + "qm": "Zuverlässigkeit (Nachvollziehbarkeit/Auditierbarkeit)", + "uebernahme": "übernehmen – GoBD-/Audit-Anforderung." + }, + { + "id": "StRS-024", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Mandanten- und Filialfähigkeit", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-013, SyRS-110", + "konsolidierung": "nein", + "pruefidee": "Zwei Filialen mit eigenen Nummernkreisen; Belege erhalten filialspezifische Nummern.", + "qm": "", + "uebernahme": "übernehmen – im SaaS-Ziel als Mandanten-/Standortmodell." + }, + { + "id": "StRS-025", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Sichere Verwaltung von Kundenzugangsdaten", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-101", + "konsolidierung": "Kandidat: PasswordManager (BL/PasswordManager) und PasswordManagementArea adressieren denselben Gegenstand – im Ziel ein Konzept.", + "pruefidee": "Passwortabruf erzeugt AccessLog; Datenbankfeld enthält keinen Klartext.", + "qm": "", + "uebernahme": "übernehmen – sicherheitskritische Kernfunktion für Systemhäuser." + }, + { + "id": "StRS-026", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Telefonie-Integration am Arbeitsplatz", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-083", + "konsolidierung": "nein", + "pruefidee": "Simulierter Anruf mit bekannter Nummer öffnet den passenden Kontakt.", + "qm": "", + "uebernahme": "Workaround – TAPI ist Windows-/Desktop-gebunden; im Web-Ziel durch CTI-/WebRTC-Ansatz zu ersetzen, fachliche Funktion bleibt." + }, + { + "id": "StRS-027", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Elektronische Rechnungsstellung (XRechnung/ZUGFeRD)", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-025", + "konsolidierung": "nein", + "pruefidee": "Erzeugte XRechnung mit KOSIT-Validator prüfen.", + "qm": "", + "uebernahme": "übernehmen – gesetzliche Pflicht (B2G, ab 2025ff B2B-Empfangspflicht in DE)." + }, + { + "id": "StRS-028", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "KI-gestützte Assistenzfunktionen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-120", + "konsolidierung": "nein", + "pruefidee": "Ticket-Zusammenfassung im ServiceBoard abrufen; Telemetrie-Eintrag entsteht.", + "qm": "", + "uebernahme": "übernehmen – Differenzierungsmerkmal; Anbieterwahl im Ziel offen." + }, + { + "id": "SyRS-001", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zentrale Rechteprüfung über Benutzer, Gruppen und Rechte", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012", + "konsolidierung": "Kandidat: zwei getrennte Rechtebestände (AppUser-Rechte, WebAccount-Rechte) für denselben Zweck – im Zielsystem ein Berechtigungsmodell.", + "pruefidee": "Recht aus Gruppe entfernen → zugehörige Operation liefert Rechtefehler.", + "qm": "", + "uebernahme": "übernehmen – Grundschutz; Modell im Ziel vereinheitlichen." + }, + { + "id": "SyRS-002", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zwei-Faktor-Authentifizierung mit Gültigkeitsdauer je Gerät", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013", + "konsolidierung": "nein", + "pruefidee": "2FA-Dauer 1 Tag: Anmeldung am Folgetag verlangt erneut den zweiten Faktor, am selben Tag nicht.", + "qm": "", + "uebernahme": "übernehmen – zeitgemäße Verfahren (TOTP/Passkeys) im Ziel ergänzen." + }, + { + "id": "SyRS-003", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Authentifizierungsverfahren: Passwort, Active Directory, OpenID Connect, Web-Account", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013", + "konsolidierung": "nein", + "pruefidee": "Anmeldung mit Entra-ID-Token; connect_accounts verknüpft die Identität mit einem AppUser.", + "qm": "", + "uebernahme": "übernehmen – SSO ist im SaaS-Ziel Pflicht." + }, + { + "id": "SyRS-004", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Anwendungszugang über erforderliche und verbietende Rechte", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012, StRS-013", + "konsolidierung": "nein", + "pruefidee": "Benutzer ohne RequiredRight der Anwendung → Fehlermeldung „RightsMissing\".", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-005", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Rechteprüfung an REST-Endpunkten per Autorisierungsattributen", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012", + "konsolidierung": "nein", + "pruefidee": "Endpunkt mit AuthorizeUserRight ohne Recht aufrufen → 403/Fehler.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-006", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Sitzungstickets mit Lizenzbindung und Wiederverwendung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013, StRS-014", + "konsolidierung": "nein", + "pruefidee": "Zweite Anmeldung derselben Maschine liefert dasselbe Ticket; Lizenzzähler unverändert.", + "qm": "", + "uebernahme": "übernehmen – als Sessionmodell; Lizenzkopplung siehe StRS-014." + }, + { + "id": "SyRS-007", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Passwortspeicherung interner Benutzer (Ist-Zustand SHA-1 ohne Salt)", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013", + "konsolidierung": "nein", + "pruefidee": "Passwortfeld in Sichbenu enthält 40-stelligen Hex-Hash; identische Passwörter ergeben identische Hashes (Beleg für fehlendes Salt).", + "qm": "", + "uebernahme": "veraltet – kryptografisch überholtes Verfahren; fachliche Funktion (Passwortlogin) bleibt, Umsetzung ist zu ersetzen." + }, + { + "id": "SyRS-008", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Einheitliche Datenzugriffsschicht mit direktem und Webservice-Zugriff", + "typ": "nicht-funktional", + "belege": [ + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001", + "konsolidierung": "nein", + "pruefidee": "Modul in beiden Verbindungsarten starten; identische Ergebnisse derselben Operation.", + "qm": "Übertragbarkeit (Flexibilität der Verbindungsarten)", + "uebernahme": "Workaround – Doppelimplementierung je Modul ist dem Migrationsstand geschuldet; im Web-Ziel entfällt der Direkt-DB-Pfad." + }, + { + "id": "SyRS-009", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Web-Account-Anmeldung nur bei aktiven Kontakten und Kunden", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-015, StRS-013", + "konsolidierung": "nein", + "pruefidee": "Kunden sperren → Portal-Login des zugehörigen Web-Accounts schlägt fehl.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-010", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Einheitliches Belegstatusmodell", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001", + "konsolidierung": "nein", + "pruefidee": "Statuswechsel offen→abgeschlossen→storniert; andere Werte werden abgelehnt (ArgumentOutOfRangeException in GetReceiptStateString).", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-011", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Belegprotokoll über alle Belegarten (AnlageLog)", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, StRS-023", + "konsolidierung": "nein", + "pruefidee": "Angebot anlegen → AnlageLog-Eintrag mit AnlageArt=1.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-012", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Persistenz der Belege über Legacy-Tabellen mit englischen Views", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001", + "konsolidierung": "nein", + "pruefidee": "End-to-End-Test: Beleg über ReceiptWebServiceBL.SaveReceipt speichern, Rohwerte der Legacy-Tabelle prüfen.", + "qm": "", + "uebernahme": "Workaround – historisch gewachsene Doppelschicht; fachlich ist nur „Beleg speichern\" zu übernehmen." + }, + { + "id": "SyRS-013", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Belegnummernvergabe aus Nummernkreisen mit Kollisionsschutz", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, StRS-024", + "konsolidierung": "nein", + "pruefidee": "Zwei parallele Belegerstellungen erhalten unterschiedliche Nummern; manuell belegte Nummer wird übersprungen.", + "qm": "", + "uebernahme": "übernehmen – Hinweis: Überspringen vorhandener Nummern kann Lücken erzeugen; GoBD-Bewertung im Ziel nötig." + }, + { + "id": "SyRS-014", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Preis-, Rabatt- und Umsatzsteuerberechnung je Position und Beleg", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-011, StRS-001", + "konsolidierung": "nein", + "pruefidee": "Beleg mit zwei Steuersätzen und Rabatt: Summen entsprechen manueller Kontrollrechnung; Steuerblöcke je Satz getrennt.", + "qm": "", + "uebernahme": "übernehmen – abrechnungskritische Kernlogik." + }, + { + "id": "SyRS-015", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Vollständige Versionierung jeder Belegänderung", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-023", + "konsolidierung": "nein", + "pruefidee": "Beleg ändern → neuer Satz in *KopfVersions mit OriginalI3D des Belegs.", + "qm": "", + "uebernahme": "übernehmen – Audit-Anforderung; technisch im Ziel z. B. als Event-/Temporal-Modell." + }, + { + "id": "SyRS-016", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kreditlimitprüfung beim Belegspeichern", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, StRS-008", + "konsolidierung": "nein", + "pruefidee": "Kunde mit Limit 1.000: Beleg über 1.200 löst Dialog aus; Bestätigung speichert, Ablehnung nicht.", + "qm": "", + "uebernahme": "übernehmen – kaufmännische Risikosteuerung." + }, + { + "id": "SyRS-017", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Belegvorlagen über definierten Vorlagenkunden", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001", + "konsolidierung": "nein", + "pruefidee": "Beleg auf Vorlagenkunden anlegen → Nummer aus Vorlagen-Nummernkreis.", + "qm": "", + "uebernahme": "Workaround – Vorlagen als „Belege eines Pseudo-Kunden\" sind eine Behelfskonstruktion; im Ziel eigenes Vorlagenkonzept." + }, + { + "id": "SyRS-018", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Optimistische Sperrung von Belegen", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "HYPOTHESE", + "hypothese": true, + "workaround": false, + "tracelinks": "StRS-001", + "konsolidierung": "nein", + "pruefidee": "Beleg parallel in zwei Sitzungen ändern; zweiter Speichervorgang wird abgewiesen.", + "qm": "Zuverlässigkeit (Datenintegrität bei Parallelzugriff)", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-019", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Freigabewesen für Web-Warenkörbe als Statusmaschine", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-015", + "konsolidierung": "nein", + "pruefidee": "Warenkorb einreichen, ablehnen, erneut einreichen, freigeben → Statusfolge wie definiert.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-020", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Vertragsabrechnung mit Intervallen, Normalisierung, Kontingenten und Zählern", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-002, StRS-019", + "konsolidierung": "nein", + "pruefidee": "Vertrag mit Quartalsintervall, Start Mitte des Quartals: erste Rechnung anteilig (Koeffizient < 1); Kontingentverbrauch reduziert Folgeabrechnung; Storno setzt Zähler und LastInvoiceDate zurück.", + "qm": "", + "uebernahme": "übernehmen – differenzierteste und umsatzkritischste Logik des Systems." + }, + { + "id": "SyRS-021", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mahnlauf mit Rechteprüfung, Vorschau und Protokoll", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-003, StRS-012", + "konsolidierung": "nein", + "pruefidee": "Benutzer ohne Mahnrecht startet Lauf → Exception; Vorschau verändert keine Mahnstufen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-022", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Offene-Posten-Verwaltung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-003", + "konsolidierung": "nein", + "pruefidee": "Rechnung 100 € + Gutschrift 40 € → OP-Saldo 60 €.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-023", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "SEPA-Lastschriftexport mit Statusführung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-004", + "konsolidierung": "nein", + "pruefidee": "Export zweimal ausführen → zweiter Lauf ohne bereits exportierte Rechnungen.", + "qm": "", + "uebernahme": "übernehmen – Formatversionen aktualisieren." + }, + { + "id": "SyRS-024", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "FiBu-Export mit Übergabehistorie und Doppelübergabeschutz", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-005, StRS-006", + "konsolidierung": "nein", + "pruefidee": "Beleg exportieren, Historieneintrag prüfen; erneuter Export listet Beleg als bereits übergeben.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-025", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Erzeugung strukturierter E-Rechnungen", + "typ": "Schnittstelle", + "belege": [ + "SEKUNDÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-027", + "konsolidierung": "nein", + "pruefidee": "Erzeugte Datei gegen XRechnung-/ebInterface-Schema validieren.", + "qm": "", + "uebernahme": "übernehmen – im Ziel auf gepflegte Standardbibliothek wechseln (im Code selbst empfohlen)." + }, + { + "id": "SyRS-026", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zahlungseingänge und Bankumsatzabruf über finAPI", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-004, StRS-003", + "konsolidierung": "nein", + "pruefidee": "Testumsatz abrufen und einer Rechnung zuordnen; Logeintrag mit Nummer entsteht.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-027", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Anzahlungsabwicklung im Belegfluss", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "HYPOTHESE – die konkrete Verrechnungslogik (Ausweis in Schlussrechnung) wurde nicht im Detail nachvollzogen; zu bestätigen durch Lesen der DownPayment-Klassen.", + "hypothese": true, + "workaround": false, + "tracelinks": "StRS-001, StRS-003", + "konsolidierung": "nein", + "pruefidee": "Anzahlung zu Auftrag erzeugen; Schlussrechnung weist Anzahlung ab.", + "qm": "", + "uebernahme": "übernehmen – kaufmännischer Standard." + }, + { + "id": "SyRS-028", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Provisionsermittlung für Vertrieb", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016, StRS-001", + "konsolidierung": "nein", + "pruefidee": "Beleg mit provisionsberechtigtem Verkäufer laden → Provisionsdaten gefüllt.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-029", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kassenbuchführung mit Belegbezug", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-006", + "konsolidierung": "nein", + "pruefidee": "Barrechnung erzeugt Kassenbuchung; Storno des Belegs entfernt/kompensiert die Buchung.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-030", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Ticketlebenszyklus mit Pflichtfeldern und Abschlussfolgen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-007", + "konsolidierung": "nein", + "pruefidee": "Ticket ohne Pflichtfeld speichern → Fehler; Abschluss erzeugt Historie+ClosedAt.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-031", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Sichtbarkeits- und Bearbeitungsrestriktionen im Ticketsystem", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-007, StRS-012", + "konsolidierung": "nein", + "pruefidee": "Benutzer mit ONLY_OWN_BRANCH sieht keine Tickets fremder Filialen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-032", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Ticket-Eskalation und Support-Level", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "HYPOTHESE – konkrete Eskalationsauslöser/-aktionen nicht im Detail nachvollzogen; Bestätigung durch Lesen der Escalation-Klassen nötig.", + "hypothese": true, + "workaround": false, + "tracelinks": "StRS-007", + "konsolidierung": "nein", + "pruefidee": "Ticket mit überschrittener Fälligkeit löst Eskalationsaktion aus.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-033", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Ticketvorlagen und automatisierte Ticketerzeugung (C-FLOW)", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-007, StRS-012", + "konsolidierung": "nein", + "pruefidee": "Ticket aus Vorlage erzeugen; Benutzer ohne CFlow-Recht kann Vorlagen nicht ändern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-034", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Regelbasierte Postfachverarbeitung mit Ticketbezug", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-018, StRS-007", + "konsolidierung": "nein", + "pruefidee": "Mail an überwachtes Postfach → Ticket gemäß Workflow, Logeintrag vorhanden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-035", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Checklisten aus Vorlagen an Tickets", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-007, StRS-012", + "konsolidierung": "nein", + "pruefidee": "Checkliste aus Vorlage erzeugen, Punkt abhaken; ohne Recht EDIT_CHECKLISTS keine Änderung.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-036", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kundenumfragen bei Ticketabschluss", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-007", + "konsolidierung": "nein", + "pruefidee": "Ticket mit aktivierter Umfrageeinstellung schließen → Mailtext enthält Umfrage-Link/-Inhalt.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-037", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kopplung an externe Helpdesk-Systeme", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "HYPOTHESE – nur die Konfigurationsverwaltung ist belegt; der eigentliche Austauschmechanismus wurde nicht gelesen.", + "hypothese": true, + "workaround": false, + "tracelinks": "StRS-007", + "konsolidierung": "nein", + "pruefidee": "Konfiguration anlegen; Austausch mit Testsystem prüfen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-038", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zeit-/ereignisgesteuerte Aufgabenautomatisierung (TaskManagement)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-017, StRS-016", + "konsolidierung": "nein", + "pruefidee": "Task mit Report-Aktion anlegen, testen (ExecuteTaskTest), Ausführungszeitpunkt im Protokoll.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-040", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Vereinheitlichter Konten-/Adress-/Kontaktstamm mit Rollen", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-008", + "konsolidierung": "Kandidat: Parallelstruktur zum Alt-Kundenstamm (Kunden/Anschrif/Personen) – siehe StRS-008.", + "pruefidee": "Konto in Firmengruppe: Beleg nutzt Einstellungen der Gruppe, wenn Flag gesetzt.", + "qm": "", + "uebernahme": "übernehmen – als führendes Modell für das Zielsystem." + }, + { + "id": "SyRS-041", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mitarbeiterverwaltung mit Beschäftigungszeitraum und Organisationszuordnung", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013, StRS-007", + "konsolidierung": "nein", + "pruefidee": "Austrittstermin gestern setzen → Anmeldung schlägt fehl.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-042", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Bankverbindungen mit Löschschutz bei Belegbezug", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-004, StRS-008", + "konsolidierung": "nein", + "pruefidee": "Bankkonto mit Belegbezug löschen → Warnung/Verweigerung gemäß Prüfliste.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-043", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kostenstellen und Kostenträger", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-005, StRS-016", + "konsolidierung": "nein", + "pruefidee": "Kostenstelle anlegen und Kunden zuordnen; Zuordnung in Auswertung sichtbar.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-050", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "EDI-Belegaustausch mit Distributoren", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-009", + "konsolidierung": "nein", + "pruefidee": "OpenTrans-Bestellung erzeugen und gegen Schema validieren; EDI-Log-Eintrag vorhanden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-051", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Lagerstruktur mit Filialbezug und Umbuchungsprotokoll", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-010, StRS-024", + "konsolidierung": "nein", + "pruefidee": "Umbuchung ausführen → RebookLog mit Quelle/Ziel/Menge.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-052", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Inventur mit Transaktionsklammer", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-010", + "konsolidierung": "nein", + "pruefidee": "Inventur abbrechen → keine Bestandsänderung.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-053", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Artikelstamm mit Sonderartikeln und Preisstrukturen", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-011", + "konsolidierung": "nein", + "pruefidee": "Frachtartikel in Einstellungen setzen; Beleg zieht ihn bei Frachtberechnung.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-054", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Lieferantenbelegkette im Einkauf", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-009", + "konsolidierung": "nein", + "pruefidee": "Bestellung→Wareneingang→Eingangsrechnung durchspielen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-055", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Versandabwicklung über GLS und Shipcloud", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "HYPOTHESE – Ablauf (aus welchem Beleg, welche Daten) nicht im Detail verifiziert.", + "hypothese": true, + "workaround": false, + "tracelinks": "StRS-001, StRS-010", + "konsolidierung": "nein", + "pruefidee": "Testlabel über Shipcloud-Sandbox erzeugen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-056", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Katalog- und Stammdatenübernahme von Distributoren/Anbietern", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-009, StRS-011", + "konsolidierung": "nein", + "pruefidee": "Testimport eines Artikels aus einer Quelle; Felder im Artikelstamm gefüllt.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-060", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Browserbasierter Serviceclient (Nexus) für Kernprozesse", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-007, StRS-015", + "konsolidierung": "Kandidat: Ticketbearbeitung existiert doppelt (WPF-Modul Helpdesk und Nexus ServiceBoard) – im Web-Ziel eine Implementierung.", + "pruefidee": "Ticket im ServiceBoard öffnen, Status ändern, Zeit stoppen.", + "qm": "", + "uebernahme": "übernehmen – Ausgangspunkt der Web-Neuimplementierung." + }, + { + "id": "SyRS-061", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Webshop auf Basis kundenindividueller Preise", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "HYPOTHESE – Preisquelle nur per README belegt; Codepfad (Sonderpreise→Shop) nicht nachvollzogen.", + "hypothese": true, + "workaround": false, + "tracelinks": "StRS-015", + "konsolidierung": "nein", + "pruefidee": "Sonderpreis anlegen → Artikel erscheint im Shop des Kunden mit diesem Preis.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-062", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Konfigurierbare Self-Service-Formulare", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-015", + "konsolidierung": "nein", + "pruefidee": "Formular definieren, als Kunde einreichen, Status intern fortschreiben.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-070", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Berichtswesen mit Gruppen und Standardberichten je Ausgabekanal", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016", + "konsolidierung": "Kandidat: paralleles Altberichtswesen (Reporting/ReportsBL, UI Reports) – im Ziel ein Berichtssystem.", + "pruefidee": "Standardbericht „Print\" der Gruppe ändern → Mahnlauf-Druck nutzt neuen Bericht.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-071", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Fachstatistiken über alle Kernprozesse", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016", + "konsolidierung": "nein", + "pruefidee": "Ticketstatistik über Zeitraum abrufen; zweiter Abruf schneller (Cache).", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-072", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Objektübergreifende Volltextsuche mit deutscher Sprachanalyse", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-017, StRS-008", + "konsolidierung": "nein", + "pruefidee": "Objekt ändern → RequestUpdateFor aktualisiert Index; Suche findet neuen Begriff.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-073", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Massenänderungen über gespeicherte Vorlagen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-011, StRS-016", + "konsolidierung": "nein", + "pruefidee": "Preisupdate-Vorlage auf Testartikelmenge ausführen; Preise geändert.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-080", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Integrierte Kollaborationswerkzeuge", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-017", + "konsolidierung": "nein", + "pruefidee": "ToDo an Ticket anlegen; Benachrichtigung erscheint beim Verantwortlichen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-081", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mailversand mit Konten, Vorlagen, Signaturen und Platzhaltern", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-018", + "konsolidierung": "nein", + "pruefidee": "Rechnungsversand nutzt Vorlage mit ersetzten Platzhaltern (Kunde, Belegnummer).", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-082", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Outlook-Anbindung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "HYPOTHESE – Funktionsumfang des AddIns nicht im Detail gelesen.", + "hypothese": true, + "workaround": false, + "tracelinks": "StRS-018", + "konsolidierung": "nein", + "pruefidee": "Mail im AddIn einem Ticket zuordnen; im Ticket sichtbar.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-083", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Telefonieereignisse mit Kontaktauflösung und Synchronisation", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-026", + "konsolidierung": "nein", + "pruefidee": "Anruf simulieren; Kontakt wird aufgelöst, Anrufliste synchronisiert.", + "qm": "", + "uebernahme": "Workaround – TAPI desktopgebunden; fachliche Funktion übernehmen, Technik ersetzen." + }, + { + "id": "SyRS-090", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Gerätebestand mit automatischer Datenübernahme (RMM/docuFORM/SNMP)", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-019", + "konsolidierung": "Kandidat: Gerätedaten in AccountDevices und AssetManagementDevices – siehe StRS-019.", + "pruefidee": "Konnektorlauf ausführen → ServiceConnectorLog-Eintrag, Gerätedaten aktualisiert.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-091", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Projektverwaltung (Vertrieb und Service)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-020", + "konsolidierung": "Kandidat: mehrere Projektkonzepte (Project, CrmProject, TicketProject) – siehe StRS-020.", + "pruefidee": "Ticketprojekt mit zwei abhängigen Aufgaben anlegen; Abhängigkeit wird gespeichert.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-092", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Fertigungsaufträge mit Positionen und Protokoll", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-020", + "konsolidierung": "nein", + "pruefidee": "Fertigungsauftrag anlegen, Status ändern → Logeintrag.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-093", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "RMA-Vorgänge mit Artikelhistorie und Versandart", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-021", + "konsolidierung": "nein", + "pruefidee": "RMA mit zwei Artikeln anlegen; Historie je Artikel abrufbar.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-100", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "DSGVO-Unterstützung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "HYPOTHESE – konkreter Funktionsumfang (Auskunft, Löschung, Anonymisierung?) nicht nachvollzogen.", + "hypothese": true, + "workaround": false, + "tracelinks": "StRS-022", + "konsolidierung": "nein", + "pruefidee": "DSGVO-Dokument zu einem Kunden erzeugen/abrufen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-101", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Verschlüsselte Zugangsdatenablage mit Zugriffs- und Änderungsprotokoll", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-025, StRS-022", + "konsolidierung": "Kandidat: BL/PasswordManager vs. PasswordManagementArea – siehe StRS-025.", + "pruefidee": "Passwort abrufen → AccessLog-Eintrag; ändern → Log-Eintrag.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-102", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Feldgenaue Änderungsprotokollierung markierter Entitäten", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-023", + "konsolidierung": "nein", + "pruefidee": "Markiertes Feld ändern → ChangeLog-Eintrag mit Alt-/Neuwert.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-110", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mandanten, Filialen und filialbezogene Ressourcen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-024, StRS-012", + "konsolidierung": "nein", + "pruefidee": "Rechteverwalter mit „nur eigene Filiale\" sieht nur Gruppen seiner Filiale.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-111", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zentrale typisierte Anwendungskonfiguration", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-024, StRS-005", + "konsolidierung": "nein", + "pruefidee": "Einstellung ändern → abhängiger Prozess verhält sich entsprechend (z. B. DATEV-Pfad).", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-112", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Versionierte Datenbankmigration über Skriptmethoden", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-024", + "konsolidierung": "nein", + "pruefidee": "Update auf leerer Altdatenbank führt alle Skripte aus; Schema entspricht SSMS_DB_SCHEMA.sql.", + "qm": "Wartbarkeit (Änderbarkeit des Schemas)", + "uebernahme": "Workaround – Mechanismus ist migrationsspezifisch; im Ziel durch Standard-Migrationswerkzeug ersetzen." + }, + { + "id": "SyRS-113", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Serverseitige Hintergrundverarbeitung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-018, StRS-002", + "konsolidierung": "nein", + "pruefidee": "Dienst starten; DataQualityService-Lauf protokolliert.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-114", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Nutzungstelemetrie", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-028", + "konsolidierung": "nein", + "pruefidee": "KI-Aufruf ausführen → Telemetrie-Datensatz vorhanden.", + "qm": "Wartbarkeit (Analysierbarkeit der Nutzung)", + "uebernahme": "übernehmen – im Ziel mit Datenschutz-Review." + }, + { + "id": "SyRS-115", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Auslieferung als Windows-Installation und Windows-Dienst", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001", + "konsolidierung": "nein", + "pruefidee": "Installer bauen und Dienst registrieren.", + "qm": "Übertragbarkeit (Installierbarkeit)", + "uebernahme": "veraltet – On-Premise-Windows-Verteilung entfällt im SaaS-Ziel; Übergangsbetrieb beachten." + }, + { + "id": "SyRS-116", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Containerisierter Linux-Betrieb des Webservice", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-015", + "konsolidierung": "nein", + "pruefidee": "compose-Umgebung starten; Webservice antwortet.", + "qm": "Übertragbarkeit (Plattformunabhängigkeit des Backends)", + "uebernahme": "übernehmen – Grundlage der SaaS-Migration." + }, + { + "id": "SyRS-117", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Deutschsprachige Oberfläche mit englischer Übersetzung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001", + "konsolidierung": "nein", + "pruefidee": "Sprachumschaltung auf Englisch übersetzt Standarddialoge.", + "qm": "Benutzbarkeit (Sprachangemessenheit)", + "uebernahme": "übernehmen – Mehrsprachigkeit im Ziel von Beginn an vorsehen." + }, + { + "id": "SyRS-118", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Strukturiertes Anwendungs- und Sicherheitslogging", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013, StRS-022", + "konsolidierung": "nein", + "pruefidee": "Fehlanmeldung erzeugt Warn-Eintrag mit Kontext.", + "qm": "Wartbarkeit (Diagnostizierbarkeit)", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-119", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mengen-/Lastverhalten: Paging, Caching, Batching", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, StRS-016", + "konsolidierung": "nein", + "pruefidee": "Abfrage mit 10.000 Treffern liefert Seiten; zweiter Aufruf gecachter Ermittlung ohne SQL.", + "qm": "Performance-Effizienz (Zeitverhalten bei großen Datenmengen)", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-120", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "KI-Dienste-Anbindung mit Modellkatalog", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-028", + "konsolidierung": "nein", + "pruefidee": "Ungültiger Endpunkt wird vom Validator abgewiesen; gültiger liefert Modellliste.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-121", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Versionierte REST-API", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-015, StRS-012", + "konsolidierung": "nein", + "pruefidee": "v1-Endpunkt (z. B. Tickets) mit JWT aufrufen.", + "qm": "", + "uebernahme": "übernehmen – API-First im Ziel." + }, + { + "id": "SyRS-122", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Client-Versionsabgleich mit dem Webservice", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-014", + "konsolidierung": "nein", + "pruefidee": "Anmeldung mit zu hoher Versionsnummer bei versionsbeschränkter Lizenz wird abgelehnt.", + "qm": "", + "uebernahme": "Sonderfall – Delphi-Ausnahme ist Altbestandspflege; Grundfunktion übernehmen." + }, + { + "id": "SyRS-123", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Erwartete Ereignisse überwachen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-019", + "konsolidierung": "nein", + "pruefidee": "Ereignislog je Konto abrufen.", + "qm": "", + "uebernahme": "übernehmen" + } +] \ No newline at end of file diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/anforderungen.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/anforderungen.md new file mode 100644 index 00000000..e1839831 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/anforderungen.md @@ -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 %) | + diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/before.txt b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/before.txt new file mode 100644 index 00000000..8b137891 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/before.txt @@ -0,0 +1 @@ + diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/combined_prompt.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/combined_prompt.md new file mode 100644 index 00000000..41713d18 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/combined_prompt.md @@ -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: - +Titel: +Ebene: +Typ: +Qualitätsmerkmal: +Akteur: +Vorbedingung: +Fakt: +Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage) +Ergebnis: +Belege: + - [PRIMÄR] - Begründung: + - [SEKUNDÄR] <...> - Begründung: <...> + - [KONTEXT] <...> - Begründung: <...> +Prüfidee: +Tracelinks: +Konsolidierung: > +Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - +Status: +``` + +### 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). diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/endzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/endzeit.txt new file mode 100644 index 00000000..f3f5abfc --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/endzeit.txt @@ -0,0 +1 @@ +2026-08-26T20:28:31.6394457+02:00 diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/startzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/startzeit.txt new file mode 100644 index 00000000..a97ddab9 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-77a1/_meta/startzeit.txt @@ -0,0 +1 @@ +2026-08-26T20:00:08.8552900+02:00 diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Analysebericht.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Analysebericht.md new file mode 100644 index 00000000..0277345f --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Analysebericht.md @@ -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). + diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Glossar.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Glossar.md new file mode 100644 index 00000000..fff88177 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Glossar.md @@ -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. | diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Hypothesen.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Hypothesen.md new file mode 100644 index 00000000..ca739cbd --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Hypothesen.md @@ -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). diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/StRS.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/StRS.md new file mode 100644 index 00000000..2a78126f --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/StRS.md @@ -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 +``` + diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/SwRS.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/SwRS.md new file mode 100644 index 00000000..7bbdce18 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/SwRS.md @@ -0,0 +1,3186 @@ +# SwRS – Software Requirements Specification +**System:** c-entron ERP-Suite | **Quelle:** Statische Codeanalyse | **Lauf:** 2026-08-27 + +Software-interne Anforderungen (Komponenten, Datenmodelle, durchgesetzte Regeln). Jede SwRS-Anforderung referenziert ihre SyRS-Anforderung. + +--- + +``` +ID: SwRS-001 +Titel: Rechteermittlung per SQL mit Sitzungscache +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Komponente Centron.BL (AppRightsBL) +Vorbedingung: Ein Aufrufer benötigt eine Rechteentscheidung für einen AppUser oder WebAccount. +Fakt: HasUserRight lädt die Rechteliste des Benutzers einmalig pro DAO-Session in den Cache (Schlüssel "AllRightsFromAppUser{I3D}") und entscheidet über Contains(rightID); für WebAccounts analog mit Schlüssel "AllRightsFromWebAccount{I3D}" gegen die Tabelle WebAccountsRights. +Aussage: Die Software soll Rechteentscheidungen aus einer pro Sitzung zwischengespeicherten Rechteliste treffen, die per SQL aus den Rechte-Tabellen geladen wird. +Ergebnis: Wiederholte Rechteprüfungen derselben Sitzung lösen keine weiteren Datenbankabfragen aus; Rechteänderungen wirken ab der nächsten Sitzung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, HasUserRight(int,int): Session.Advanced.Cache.GetOrAdd + rights.Contains(rightID); GetAllAppRightsFromUser(int) mit SQL über dbo.Sichtrus/dbo.Sichmemb - Begründung: durchsetzende Prüf- und Ladelogik. +Prüfidee: Recht während laufender Sitzung entziehen; erwartet: Entscheidung ändert sich erst nach neuer Sitzung (Cache-Verhalten dokumentieren/testen). +Tracelinks: SyRS-001, SyRS-002 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Caching-Strategie ist auch im Zielsystem nötig; Invalidierung bei Rechteänderung ergänzen. +Status: belegt +``` + +``` +ID: SwRS-002 +Titel: Passwortablage als ungesalzener SHA1-Hash +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Komponente Centron.BL (BasicAuthenticator), Tabelle Sichbenu (AppUser) +Vorbedingung: Benutzer meldet sich mit Benutzername/Passwort an. +Fakt: BasicAuthenticator vergleicht den SHA1-Hash des übergebenen Passworts (SHA1Decoder.GetDecodedSHA1String) direkt mit dem in AppUser.Password gespeicherten Wert; ein Code-Kommentar lautet "TODO the password should be salted!!!". +Aussage: Die Software prüft lokale Passwörter durch Vergleich ungesalzener SHA1-Hashes gegen die Benutzertabelle. +Ergebnis: Anmeldung gelingt genau dann, wenn Benutzername und SHA1-Hash übereinstimmen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, AuthenticateInternal(): GetEntity(where => where.Name == Auth.UserName && where.Password == decodedPassword) - Begründung: durchsetzende Passwortprüfung inkl. Hashverfahren. + - [KONTEXT] Ebd., Kommentar "// TODO the password should be salted!!!" - Begründung: Entwickler markieren das Verfahren selbst als unzureichend. +Prüfidee: Zwei Benutzer mit gleichem Passwort erzeugen identische Hashwerte in Sichbenu.Password (Nachweis fehlenden Salts). +Tracelinks: SyRS-004 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - ungesalzenes SHA1 ist kryptographisch überholt; im Zielsystem durch modernes Verfahren (z. B. Argon2/bcrypt) ersetzen, Funktion „lokales Passwort" bleibt. +Status: belegt +``` + +``` +ID: SwRS-003 +Titel: Konfigurationsgesteuerte Wahl des Zwei-Faktor-Validators +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Komponente Centron.BL (TwoFactorAuthBL) +Vorbedingung: 2FA-Typ ist in der Webservice-Konfiguration gesetzt. +Fakt: GetTwoFactorValidator wählt per switch über WebServiceConfigHelper.Current.TwoFactorAuthType den RadiusTwoFactorValidator oder EmailTwoFactorValidator; die RADIUS-Kommunikation ist mit RadiusClient/RadiusPaketParser implementiert. +Aussage: Die Software soll den zweiten Faktor über einen austauschbaren Validator prüfen, der zentral per Konfigurationsschalter bestimmt wird. +Ergebnis: Der konfigurierte Validator entscheidet über Erfolg/Misserfolg der 2FA. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs, GetTwoFactorValidator() (switch RadiusServer/EmailLink) - Begründung: durchsetzende Auswahllogik. + - [SEKUNDÄR] src/backend/Centron.BL/Administration/Logins/TwoFactor/RadiusClient.cs, EmailTwoFactorValidator.cs - Begründung: Implementierungen der beiden Verfahren. +Prüfidee: Konfiguration auf EmailLink stellen; erwartet: Anmeldung fordert E-Mail-Bestätigung an statt RADIUS-Abfrage. +Tracelinks: SyRS-005 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Austauschbarkeit der 2FA-Verfahren beibehalten. +Status: belegt +``` + +``` +ID: SwRS-004 +Titel: Verwaltung von Rechtegruppen und Zuordnungen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Komponente AppRightsBL +Vorbedingung: Administrator besitzt die Berechtigung zur Rechteverwaltung. +Fakt: AppRightsBL bietet Operationen zum Anlegen, Kopieren (auch je Filiale), Umbenennen und Löschen von Rechtegruppen, zum Zuordnen/Entfernen von Rechten und Benutzern sowie zum Kopieren aller Gruppenmitgliedschaften von einem Benutzer auf einen anderen; Änderungen werden als AppRightLog protokolliert. +Aussage: Das System soll Rechtegruppen vollständig verwalten können (anlegen, kopieren, löschen, Rechte- und Benutzerzuordnung) und jede Änderung protokollieren. +Ergebnis: Rechtestruktur ist administrierbar; Änderungen sind über AppRightLog nachvollziehbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methoden AddRightToRightGroup, RemoveRightFromRightGroup, AddUserToRightGroup, RemoveUserFromRightGroup, CopyRightGroup, CopyRightGroupsForUser, DeleteRightGroup, GetAllAppRightLogs - Begründung: implementierende und durchsetzende Stellen der Verwaltung. +Prüfidee: Gruppe kopieren und prüfen, dass Rechte- und Mitgliederliste identisch übernommen werden und ein Log-Eintrag entsteht. +Tracelinks: SyRS-001, SyRS-008 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - administrative Kernfunktion. +Status: belegt +``` + +``` +ID: SwRS-005 +Titel: Wiederverwendung bestehender Sitzungstickets und Login-Protokollierung +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Komponente Authenticator/TicketBL +Vorbedingung: Benutzer authentifiziert sich für eine Anwendung auf einer Maschine. +Fakt: AuthenticateUser prüft zuerst GetExistingTicket(applicationKind, user, webAccountI3D, machineName) und gibt ein vorhandenes Ticket zurück, bevor eine Lizenz verbraucht wird; bei Neuerstellung werden Login-IP (SetLoginIP) und die Client-Version (ApplicationVersionBL.SaveLogin) gespeichert; die Ticketvergabe ist durch ein Lock serialisiert. +Aussage: Die Software soll pro Benutzer/Anwendung/Maschine bestehende Sitzungen wiederverwenden, Neuanmeldungen serialisiert vergeben und dabei IP-Adresse und Client-Version protokollieren. +Ergebnis: Keine doppelten Lizenzverbräuche durch Mehrfachanmeldung; Anmeldungen sind mit IP/Version nachvollziehbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, AuthenticateUser(...): lock(_getExistingOrCreateTicketLock), GetExistingTicket, SetLoginIP, SaveLogin - Begründung: durchsetzende Ablauflogik. +Prüfidee: Zweite Anmeldung derselben Kombination liefert dasselbe Ticket; Lizenzzähler bleibt unverändert. +Tracelinks: SyRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Verhalten für Seat-basierte Lizenzierung erforderlich. +Status: belegt +``` + +``` +ID: SwRS-006 +Titel: Speicher-Template mit Vor- und Nachbedingungen (DoBefore/DoAfter) +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente Centron.BL (DBBaseBL) +Vorbedingung: Eine Fach-BL erbt von DBBaseBL und speichert eine Entität. +Fakt: Save unterscheidet Neuanlage (I3D <= 0 oder kein Datensatz vorhanden) von Änderung, ruft DoBeforeSave → DoBeforeStoreTrans → Save/SaveOrUpdate → DoAfterStoreTrans → Commit → DoAfterStore und rollt bei jedem Fehlschlag zurück. +Aussage: Die Software soll allen Fachmodulen ein einheitliches Speicher-Template mit definierten Validierungs- und Nachverarbeitungspunkten bereitstellen. +Ergebnis: Fachliche Prüfungen laufen vor der Persistierung, Nachverarbeitung nach erfolgreichem Commit; Verhalten ist modulübergreifend identisch. +Belege: + - [PRIMÄR] src/backend/Centron.BL/DBBaseBL.cs, Save(T,LoggedInUser,bool) mit den virtuellen Hooks DoBeforeSave/DoBeforeStoreTrans/DoAfterStoreTrans/DoAfterStore - Begründung: Template-Methode ist die durchsetzende Stelle. +Prüfidee: Fach-BL mit überschriebenem DoBeforeStoreTrans, das Fehler liefert; erwartet: kein Insert, Result mit Fehler. +Tracelinks: SyRS-010 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - als Muster (nicht 1:1-Code) ins Zielsystem. +Status: belegt +``` + +``` +ID: SwRS-007 +Titel: Erstellungs-/Änderungsmetadaten auf Entitätsebene +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Komponente Centron.BL/Centron.Entities +Vorbedingung: Entität implementiert IChangeTrackingProperties bzw. ist DBEntity. +Fakt: Bei I3D <= 0 werden CreatedByI3D/CreatedDate/CreatedVersion gesetzt, sonst nur ChangedByI3D/ChangedDate/ChangedVersion; als Verursacher dient der Employee des angemeldeten Benutzers; ein älterer, als obsolet kommentierter Pfad nutzt fälschlich die AppUser-I3D. +Aussage: Die Software soll Erstellungsmetadaten nur bei Neuanlage und Änderungsmetadaten bei jeder Speicherung setzen, jeweils bezogen auf den Mitarbeiter (nicht das Login). +Ergebnis: Konsistente Herkunftsdaten je Datensatz. +Belege: + - [PRIMÄR] src/backend/Centron.BL/BaseBL.cs, SetBaseProperties(AppUser,T) und SetBasePropertiesDBEntity(AppUser,DBEntity) - Begründung: durchsetzende Zuweisungslogik inkl. Neuanlage-Unterscheidung. + - [KONTEXT] Ebd., XML-Kommentar zur obsoleten Überladung ("It should use the Employee I3D") - Begründung: belegt die fachliche Regel „Mitarbeiter statt Login". +Prüfidee: Datensatz durch Benutzer A anlegen, durch B ändern; erwartet: CreatedBy=A.Employee, ChangedBy=B.Employee. +Tracelinks: SyRS-009 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Regel bleibt; obsolete AppUser-Variante nicht migrieren. +Status: belegt +``` + +``` +ID: SwRS-008 +Titel: Standard-Rechtegruppen aus eingebetteter Strukturdatei +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Komponente AppRightsBL +Vorbedingung: Zurücksetzen der Standardgruppen wird ausgelöst. +Fakt: Die Standardstruktur wird aus der Manifest-Ressource "Centron.BusinessLogic.Administration.Rights.DefaultRightsStructure.txt" gelesen (Tabulator-getrennt: Gruppenname → Rechte-IDs); zusätzlich existiert eine Liste admin-zuweisbarer Rechte (GetAssignableAdminRightI3Ds). +Aussage: Die Software soll die Standard-Rechtegruppen aus einer versionierten, mitausgelieferten Strukturdatei aufbauen. +Ergebnis: Reproduzierbare Standardrechte über alle Installationen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, GetDefaultRightsStructureFileContent() und ResetDefaultRightGroups(...) - Begründung: durchsetzende Lade- und Aufbaustelle. + - [SEKUNDÄR] src/backend/Centron.BL/Administration/Rights/DefaultRightsStructure.txt - Begründung: konkrete Rollen-/Rechtezuordnung. +Prüfidee: Strukturdatei um ein Recht erweitern, Reset ausführen; erwartet: Gruppe enthält das Recht. +Tracelinks: SyRS-008 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Mechanik „Rollenvorlagen als Daten" ist tragfähig. +Status: belegt +``` + +``` +ID: SwRS-009 +Titel: Signaturvalidierte Lizenzdatei mit Produkt- und Versionsbindung +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Komponente LicenseManager +Vorbedingung: Lizenzdatei ist installiert bzw. über den Webservice abrufbar. +Fakt: LicenseManager validiert die Lizenzdatei gegen einen öffentlichen Schlüssel, prüft je Anwendungs-GUID Lizenzanzahl und maximal erlaubte Programmversion (CheckLicenseVersion), liefert Kundennummer/Produkt-ID und meldet Lizenzwechsel über das Event LicensesChanged. +Aussage: Die Software soll Lizenzen aus einer kryptographisch signierten Lizenzdatei lesen und Anzahl- sowie Versionsbeschränkungen je Produkt durchsetzen. +Ergebnis: Manipulierte oder abgelaufene Lizenzen verhindern die Nutzung des jeweiligen Produkts. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, CheckLicense(...)/CheckLicenseVersion, Kommentar "Use the public key of the new key-pair to validate the license file", GetLicenseCount, GetCustomerNumber - Begründung: durchsetzende Prüf- und Ladelogik der Lizenzierung. +Prüfidee: Lizenzdatei mit zu niedriger Maximalversion einspielen; erwartet: CheckLicense liefert Fehler, Anmeldung der Anwendung wird abgelehnt. +Tracelinks: SyRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - dateibasierte Lizenzierung ist Client-Server-Erbe; im SaaS-Zielsystem durch Abonnementverwaltung ersetzen, fachliche Regel (Seat-/Produktbindung) bleibt. +Status: belegt +``` + +``` +ID: SwRS-010 +Titel: Belegnummernvergabe mit Sonderfall Vorlagenkunde +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente ReceiptBL +Vorbedingung: Neuer Beleg wird gespeichert; Nummernkreis ist auflösbar. +Fakt: UpdateReceiptNumber ermittelt den Nummernkreis über die Belegart-Logik und die Filiale des Belegs; gehört der Beleg zum konfigurierten „Template-Kunden" (AppSettingsBL.GetReceiptTemplateCustomerNumber), wird stattdessen eine Vorlagen-Nummer (GetNextReceiptTemplateNumber) vergeben. +Aussage: Die Software soll Belegnummern aus dem aufgelösten Nummernkreis vergeben und Belege des Vorlagenkunden mit separaten Vorlagennummern führen. +Ergebnis: Produktive Nummernkreise werden durch Belegvorlagen nicht verbraucht. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, UpdateReceiptNumber(...): isTemplate-Weiche mit _receiptTemplateBL.GetNextReceiptTemplateNumber vs. _numberGroupBL.GetNextNumber - Begründung: durchsetzende Vergabelogik inkl. Sonderfall. +Prüfidee: Beleg für den Template-Kunden speichern; erwartet: Vorlagen-Nummer, Nummernkreiszähler unverändert. +Tracelinks: SyRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: Sonderfall - Vorlagen über speziellen „Kunden" abzubilden ist ein historischer Behelf; im Zielsystem eigenes Vorlagenkonzept. +Status: belegt +``` + +``` +ID: SwRS-011 +Titel: TOTP-Zweitfaktor über hinterlegten Schlüssel (Google Authenticator) +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Benutzer, Komponente TwoFactorAuthenticationBL +Vorbedingung: In der Personalverwaltung ist für den Benutzer ein 2FA-Schlüssel hinterlegt. +Fakt: TwoFactorAuthenticationBL speichert je AppUser einen TwoFactorAuthKey (Named Query UpdateAppUserTwoFactorAuthKey) und validiert PINs über Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin; ohne hinterlegten Schlüssel wird mit der Meldung „Ihrem Benutzer ist kein Zwei-Faktor Schlüssel in der Personalverwaltung hinterlegt!" abgelehnt. +Aussage: Die Software soll zusätzlich einen TOTP-basierten Zweitfaktor (Authenticator-App) je Benutzer unterstützen, dessen Schlüssel in der Personalverwaltung gepflegt wird. +Ergebnis: Gültige TOTP-PIN → Erfolg; ungültige PIN oder fehlender Schlüssel → definierte Fehlermeldung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, ValidateAuthenticationPin(...): Aufruf GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin mit Fehlerpfaden - Begründung: durchsetzende PIN-Prüfung. +Prüfidee: PIN mit korrektem/inkorrektem TOTP-Code prüfen; erwartet: Success bzw. „Die eingegebene PIN ist ungültig!". +Tracelinks: SyRS-005 +Konsolidierung: Kandidat: SyRS-005 (zweiter, paralleler 2FA-Mechanismus neben RADIUS/E-Mail-Link; im Zielsystem auf ein 2FA-Framework konsolidieren) +Übernahmewürdigkeit: übernehmen - TOTP ist der zeitgemäße der vorhandenen 2FA-Wege. +Status: belegt +``` + +``` +ID: SwRS-012 +Titel: Auflösungskaskade der Nummernkreise +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente MandatoryBL +Vorbedingung: Nummernkreis wird für Mitarbeiter/Filiale/Mandant angefragt. +Fakt: GetNumberGroup sucht den Nummernkreis zuerst über den Mitarbeiter (dessen Filiale), dann über die Filiale (deren Mandant), dann über den Standardmandanten; GetNumberGroupsForBranch enthält dieselbe Fallback-Logik für die Verwaltungssicht. +Aussage: Die Software soll Nummernkreise in der festen Reihenfolge Mitarbeiter-Filiale → Filiale/Mandant → Standardmandant auflösen. +Ergebnis: Deterministische Kreiszuordnung auch bei unvollständiger Pflege. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs, GetNumberGroup(NumberGroupEnum, EmployeeCompact, Branch) (Zeile 55ff) und GetNumberGroupFromBranch/GetNumberGroupFromDefaultMandator - Begründung: implementierte Kaskade. +Prüfidee: Kreis nur am Standardmandanten pflegen; Anfrage mit Filiale ohne eigenen Kreis; erwartet: Kreis des Standardmandanten. +Tracelinks: SyRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Fallback-Kaskade vermeidet Pflegeaufwand. +Status: belegt +``` + +``` +ID: SwRS-013 +Titel: Belegartspezifische Strategieobjekte (IReceiptSpecificLogic) +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente Centron.BL (Belegwesen) +Vorbedingung: Eine belegartabhängige Entscheidung ist zu treffen. +Fakt: Jede Belegart implementiert IReceiptSpecificLogic mit u. a. GetNumberGroup, UpdatesStock/IncrementsStock, CanBeForwardedFrom/Into, Pflichtfeldern (IsDeliveryDateNeeded, IsCostCenterNeeded), automatischem Schließen (CanBeAutomaticallyClosed) und Sperrverhalten; ReceiptBL delegiert über _specificLogics.Execute. +Aussage: Die Software soll belegartspezifisches Verhalten zentral je Belegart als Strategie kapseln, sodass generische Belegfunktionen für alle Arten identisch ablaufen. +Ergebnis: Neue Belegarten sind durch eine weitere Strategie ergänzbar; generischer Code bleibt unverändert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs und Implementierungen (Invoices/InvoiceSpecificLogic.cs u. a.) - Begründung: Interface + Implementierungen sind die tragende Struktur. +Prüfidee: Für jede Belegart die Strategieantworten (Nummernkreis, Bestandswirkung, Weiterführung) tabellarisch gegen die Implementierung prüfen. +Tracelinks: SyRS-011, SyRS-013 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - als Architekturprinzip für das Zielsystem geeignet. +Status: belegt +``` + +``` +ID: SwRS-014 +Titel: Negativbuchungen nur mit gesondertem Recht und Warnung +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Lagerbuchung, Benutzer +Vorbedingung: Bestandswirksamer Beleg würde den Lagerbestand unter null senken. +Fakt: InvoiceSpecificLogic und DeliveryListSpecificLogic liefern UserNeedsRightToMakeNegativeArticleBooking()=true und WarnIfUserMakesNegativeArticleBooking()=true; der Rechtekatalog enthält hierfür eine eigene Konstante (RIGHT_NEGATIVBUCHUNG, in UserRightsConst referenziert). +Aussage: Die Software soll Lagerbuchungen ins Negative nur Benutzern mit dem entsprechenden Recht erlauben und zusätzlich eine Warnung ausgeben. +Ergebnis: Ohne Recht keine Negativbuchung; mit Recht Warnhinweis vor Ausführung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, UserNeedsRightToMakeNegativeArticleBooking()/WarnIfUserMakesNegativeArticleBooking() (Zeile 239f) - Begründung: belegartweise Aktivierung der Prüfung. + - [SEKUNDÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs (auskommentierte Konstante RIGHT_NEGATIVBUCHUNG=20400011 im Abschnitt 20400000) - Begründung: Rechtekonstante im Katalog. +Prüfidee: Rechnung über mehr als den verfügbaren Bestand ohne Recht; erwartet: Ablehnung; mit Recht: Warnung und Buchung. +Tracelinks: SyRS-013, SyRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Schutz der Bestandsführung. +Status: belegt +``` + +``` +ID: SwRS-015 +Titel: Mindestpreisprüfung: Ausnahme nur nach Re-Authentifizierung +Ebene: SwRS +Typ: Sicherheit (Abrechnung) +Qualitätsmerkmal: +Akteur: Komponente ReceiptBL, autorisierender Benutzer +Vorbedingung: Position unterschreitet den Artikel-Mindestpreis; Speichernder ohne Recht ALLOW_IGNORE_MINIMUM_PRICE. +Fakt: CheckArticleMinPrices authentifiziert die im Speichervorgang übergebenen Zweitanmeldedaten über die AuthenticatorFactory (ApplicationName "Artikel Mindestpreis") und akzeptiert die Unterschreitung nur, wenn der zweite Benutzer das Recht besitzt; sonst wird der Basispreis per ChangeBasePrice auf den Mindestpreis gesetzt oder das Speichern mit Meldung abgewiesen; Sonderartikelcodes sind ausgenommen; Lieferantenbelege werden nicht geprüft. +Aussage: Die Software soll Mindestpreis-Ausnahmen ausschließlich über eine vollständige Zweitanmeldung eines berechtigten Benutzers zulassen und alle Entscheidungen protokollieren. +Ergebnis: Nachvollziehbare Ausnahmen; automatische Preiskorrektur als Alternative. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CheckArticleMinPrices(...): Authenticate() der Zweitanmeldung, HasUserRight(ALLOW_IGNORE_MINIMUM_PRICE), _receiptItemPriceBL.ChangeBasePrice(item, minPrice), Logging der Entscheidungen - Begründung: vollständige durchsetzende Ausnahme- und Korrekturlogik. + - [KONTEXT] Ebd., Kommentar "TODO Das funktioniert dann mit der Azure Authentifikation nicht mehr" - Begründung: bekannte technische Schuld des Verfahrens. +Prüfidee: Zweitanmeldung mit Benutzer ohne Recht; erwartet: Meldung und keine Ausnahme; mit Recht: Preis bleibt unter Mindestpreis. +Tracelinks: SyRS-014 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - Vier-Augen-Freigabe fachlich übernehmen, technische Umsetzung (Passwort-Zweitanmeldung) ersetzen. +Status: belegt +``` + +``` +ID: SwRS-016 +Titel: Filialzuordnung neuer Kundenbelege nach konfigurierter Herkunft +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente ReceiptBL +Vorbedingung: Neuer Kundenbeleg wird angelegt. +Fakt: GetBranchForNewReceipt bestimmt die Filiale je nach BranchOrigin aus dem Ersteller (CreatedByI3D) oder dem Vertriebsmitarbeiter (SalesRepresentativeI3D); unbekannte Werte werfen ArgumentOutOfRangeException. +Aussage: Die Software soll die Filiale eines neuen Kundenbelegs regelbasiert aus Ersteller oder Betreuer ableiten. +Ergebnis: Belege sind stets einer Filiale zugeordnet; die Ableitungsregel ist konfigurierbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetBranchForNewReceipt(IReceiptBase): switch über customerReceipt.BranchOrigin (Creator/Adviser2) - Begründung: durchsetzende Ableitungslogik. +Prüfidee: BranchOrigin=Adviser2 setzen, Beleg durch Benutzer anderer Filiale anlegen; erwartet: Filiale des Vertriebsmitarbeiters. +Tracelinks: SyRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - filialgenaue Zuordnung ist Berichts- und Nummernkreisbasis. +Status: belegt +``` + +``` +ID: SwRS-017 +Titel: Konfigurierbare Seriennummern-Vollständigkeitsprüfung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente Belegwesen (Barcode-/Seriennummernprüfung) +Vorbedingung: Beleg mit seriennummernpflichtigen Artikeln wird gespeichert. +Fakt: InvoiceSpecificLogic.NeedsAllBarcodesForQuantity liefert true, außer der Konfigurationsschalter SaveWithoutAllSN ist gesetzt; d. h. standardmäßig müssen alle Positionsmengen mit erfassten Seriennummern/Barcodes hinterlegt sein. +Aussage: Die Software soll das Speichern bestandswirksamer Belege standardmäßig nur zulassen, wenn für die gesamte Menge Seriennummern erfasst sind; Abweichung nur per Konfiguration. +Ergebnis: Vollständige Seriennummernketten je Beleg; bewusste Ausnahme über Einstellung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, NeedsAllBarcodesForQuantity(...): Negation des Settings AppSettingsConst.SaveWithoutAllSN (Zeile 242) - Begründung: durchsetzende Bedingung. +Prüfidee: Rechnung mit fehlender Seriennummer speichern (Schalter aus); erwartet: Ablehnung; Schalter an: Speichern möglich. +Tracelinks: SyRS-013 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Seriennummernverfolgung ist für IT-Handel zentral. +Status: belegt +``` + +``` +ID: SwRS-018 +Titel: Beleg-Einstellungen der Firmengruppe (Konzernkunden) +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente ReceiptBL +Vorbedingung: Kunde gehört zu einer Firmengruppe; Konzern-Schalter am Konto ist gesetzt. +Fakt: GetCompanyGroupCustomerI3DForReceiptData ermittelt per SQL (IIF(A.UseSettingsFromCompanyGroupForReceipts = 1, ...)) die Kundennummer der Firmengruppe, deren Belegeinstellungen dann gelten; Ergebnis wird pro Session gecacht. +Aussage: Die Software soll für Konzernkunden optional die Belegeinstellungen der übergeordneten Firmengruppe anwenden. +Ergebnis: Einheitliche Konditionen/Einstellungen über Konzerntöchter hinweg, gesteuert per Konto-Flag. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetCompanyGroupCustomerI3DForReceiptData(int) mit SQL auf Accounts.UseSettingsFromCompanyGroupForReceipts/CompanyGroupI3D - Begründung: durchsetzende Ermittlungslogik. +Prüfidee: Konto mit gesetztem Flag und abweichenden Gruppeneinstellungen; erwartet: Beleg nutzt Gruppenwerte. +Tracelinks: SyRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Konzernstrukturen sind im B2B-Handel üblich. +Status: belegt +``` + +``` +ID: SwRS-019 +Titel: Bankverbindungen: Rechteprüfung, Gültigkeitszeitraum und eindeutige Standardverbindung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Benutzer, Komponente BankAccountBL +Vorbedingung: Bankverbindung eines Kontos wird angelegt/geändert. +Fakt: SaveBankAccount verlangt für Neuanlage das Recht CREATE_NEW_Bank_Account, für Änderung EDIT_Bank_Account; beim Setzen von IsDefault werden alle anderen Standard-Bankverbindungen desselben Objekts zurückgesetzt; GetBankAccountsFromCustomer filtert optional auf gültige Verbindungen (ValidFrom/ValidTo gegen Tagesdatum, Werte vor 1906 gelten als leer). +Aussage: Die Software soll Bankverbindungen nur mit passendem Recht ändern lassen, je Objekt genau eine Standardverbindung zulassen und Gültigkeitszeiträume beachten. +Ergebnis: Konsistente, berechtigungsgeschützte Bankdaten je Kunde. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Accounting/BankAccountBL.cs, SaveBankAccount(...): CheckRightsFromUser mit CREATE_NEW_Bank_Account/EDIT_Bank_Account und Rücksetzschleife über IsDefault; GetBankAccountsFromCustomer(...): Datumsfilter - Begründung: durchsetzende Prüf- und Konsistenzlogik. +Prüfidee: Zweite Bankverbindung als Standard markieren; erwartet: vorherige verliert IsDefault; Speichern ohne Recht: Fehlermeldung "Fehlendes Recht ...". +Tracelinks: SyRS-001; SyRS-020 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Zahlungsverkehrsgrundlage (SEPA-Mandate referenzieren Bankverbindungen). +Status: belegt +``` + +``` +ID: SwRS-020 +Titel: Kontenstamm: operationsbezogene Rechteprüfung und FiBu-Nummernkopplung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Benutzer, Komponente AccountBL +Vorbedingung: Konto (Kunde/Lieferant) wird angelegt, geändert, gelöscht oder reaktiviert. +Fakt: SaveAccount/DeleteAccount/ReactivateAccount validieren Benutzerrechte operationsspezifisch (ValidateUserRights mit newCustomer/newSupplier/editAccount/deleteAccount); bei aktivem Setting AccountsBookKeepingNumberEqualsCustomerNumber wird die Buchhaltungsnummer aus der Kundennummer übernommen (außer bei Datenimport mit vorhandener Nummer); ignoreRights existiert für Migrations-/Importpfade. +Aussage: Die Software soll Kontenoperationen nach Anlegen/Ändern/Löschen getrennt berechtigen und optional die Buchhaltungsnummer automatisch gleich der Kundennummer setzen. +Ergebnis: Berechtigungsgeschützte Kontenpflege; konsistente FiBu-Debitorennummern bei aktivem Schalter. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs, SaveAccount(...) (Zeile 473ff): ValidateUserRights-Aufrufe und Setting-Auswertung AccountsBookKeepingNumberEqualsCustomerNumber; DeleteAccount (Zeile 752ff), ReactivateAccount (Zeile 686ff) - Begründung: durchsetzende Rechteschranken und Nummernregel. +Prüfidee: Konto ohne Editierrecht speichern; erwartet: Ablehnung; Schalter aktiv, neues Konto: BookKeepingNumber == CustomerNumber. +Tracelinks: SyRS-001; SyRS-020 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kernstammdatenpflege. +Status: belegt +``` + +``` +ID: SwRS-021 +Titel: API-Token: Hash-Speicherung, Ablauf, Lizenzzählung, Aktionslog +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Komponente AccessTokenBL +Vorbedingung: Persönliches API-Token wird erzeugt oder verwendet. +Fakt: CreatePersonalToken erzeugt das Token per RandomNumberGenerator, persistiert ausschließlich den SHA-256-Hash (TokenHash) samt ExpiresAt und Ersteller; ValidateToken sucht per Hash, weist abgelaufene/inaktive Tokens ab und kann IP/API-Methode für das Log erhalten; aktive Tokens werden gegen die Lizenzanzahl gezählt; jede Aktion wird über AccessTokenLogBL protokolliert. +Aussage: Die Software soll API-Tokens niemals im Klartext speichern, Ablauf und Aktivität bei jeder Verwendung prüfen, die Anzahl aktiver Tokens lizenzieren und alle Tokenaktionen protokollieren. +Ergebnis: Sichere, nachvollziehbare, lizenzkonforme API-Zugänge. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, CreatePersonalToken(...), ValidateToken(...), SHA256.Create()-Hashing (Zeile ~478ff), Lizenzzählung aktiver Tokens (Zeile ~444) - Begründung: durchsetzende Sicherheitslogik. + - [PRIMÄR] src/backend/Centron.BL/Administration/AccessTokens/AccessTokenLogBL.cs - Begründung: Protokollierungskomponente. +Prüfidee: Erzeugtes Token in DB suchen; erwartet: nur Hash; Validierung nach Ablaufdatum; erwartet: Fehler. +Tracelinks: SyRS-017 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Stand der Technik. +Status: belegt +``` + +``` +ID: SwRS-022 +Titel: Protokollierung der Client-Version je Anmeldung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente ApplicationVersionBL +Vorbedingung: Benutzer meldet sich mit einer Client-Anwendung an. +Fakt: Authenticator.AuthenticateUser ruft nach Ticketerstellung ApplicationVersionBL.SaveLogin(applicationKind, version, machineName, currentUser) auf. +Aussage: Die Software soll je Anmeldung die eingesetzte Anwendungsart, Programmversion und Maschine persistieren. +Ergebnis: Verteilungsübersicht der Client-Versionen für Betrieb und Support. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Applications/ApplicationVersionBL.cs, SaveLogin(ApplicationKind,string,string,LoggedInUser) und Aufruf in Authenticator.AuthenticateUser - Begründung: implementierende und aufrufende Stelle. +Prüfidee: Anmeldung mit definierter Versionsnummer; erwartet: Datensatz mit Version/Maschine. +Tracelinks: SyRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - für Update-/Kompatibilitätssteuerung nützlich. +Status: belegt +``` + +``` +ID: SwRS-023 +Titel: Verwaltung von KI-Prompts und verschlüsselten API-Schlüsseln +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Komponente ArtificialIntelligenceBL +Vorbedingung: KI-Funktionen sollen konfiguriert werden. +Fakt: Prompt-Vorlagen und -Kategorien sind CRUD-verwaltbar (SavePromptSetting/SavePromptCategory, GetAllPromptsByActionId je AiActionId); Einstellungen umfassen AiApiKey, DefaultModel, WebSearchProvider; der WebSearch-API-Key wird mit AESCryptoLogic ver-/entschlüsselt; verfügbare Modelle werden über GetModels vom Anbieter geladen. +Aussage: Die Software soll KI-Prompts je Aktionstyp verwaltbar machen und API-Schlüssel der KI-Dienste verschlüsselt ablegen. +Ergebnis: Anpassbare KI-Aktionen; keine Klartextschlüssel in der Datenbank (für den WebSearch-Key belegt). +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/ArtificialIntelligence/ArtificialIntelligenceBL.cs, GetAISettings/UpdateAISettings mit AESCryptoLogic, SavePromptSetting/GetAllPromptsByActionId - Begründung: implementierende Verwaltungs- und Verschlüsselungslogik. + - [KONTEXT] Ebd., Kommentar "TODO: @Fabian, warum sollen standardmäßig überhaupt die Modelle von OpenAI geladen werden?" - Begründung: offener Punkt zum Default-Anbieter. +Prüfidee: WebSearch-Key speichern und DB prüfen (verschlüsselt); Prompt je Aktions-ID anlegen und in der Aktion abrufen. +Tracelinks: SyRS-019 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Konfigurierbarkeit der KI ist erforderlich; einheitliche Verschlüsselung aller Schlüssel prüfen. +Status: belegt +``` + +``` +ID: SwRS-024 +Titel: Persistenter Betriebszustand je Hintergrunddienst +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente BackgroundServiceBL +Vorbedingung: Hintergrunddienst startet oder beendet einen Lauf. +Fakt: Je Dienstname wird ein BackgroundService-Datensatz mit IsEnabled, StartTime und LastRunTime geführt; UpdateLastRunTime setzt den Zeitstempel nach einem Lauf; CreateOrUpdateBackgroundService legt fehlende Dienste an. +Aussage: Die Software soll für jeden Hintergrunddienst Aktivierungszustand und letzte Laufzeit persistent verwalten. +Ergebnis: Ausbleibende Läufe sind über LastRunTime erkennbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/BackgroundServices/BackgroundServiceBL.cs, UpdateLastRunTime/UpdateStartTime/CreateOrUpdateBackgroundService - Begründung: durchsetzende Zustandsführung. +Prüfidee: Dienstlauf simulieren; erwartet: LastRunTime aktualisiert. +Tracelinks: SyRS-018 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Monitoring-Grundlage. +Status: belegt +``` + +``` +ID: SwRS-025 +Titel: Verwaltung von Buchhaltungs-Kontenrahmen und Konten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Buchhalter, Komponente BookKeepingAccountSystemsBL +Vorbedingung: FiBu-Übergabe benötigt Kontenrahmen und Sachkonten. +Fakt: BookKeepingAccountSystemsBL verwaltet Kontenrahmen (BookKeepingAccountSystem) und deren Konten (BookKeepingAccount) inkl. Filterung und Default-System (GetBookKeepingAccounts(fromDefaultSystem)). +Aussage: Die Software soll mehrere Buchhaltungs-Kontenrahmen mit Sachkonten verwalten und einen Standardrahmen unterstützen. +Ergebnis: FiBu-Export kann Konten aus dem passenden Rahmen ziehen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/BookKeepingAccountSystems/BookKeepingAccountSystemBL.cs, GetBookKeepingAccountSystems/SaveBookKeepingAccountSystem/GetBookKeepingAccounts - Begründung: implementierende Verwaltungslogik. +Prüfidee: Zweiten Kontenrahmen anlegen; erwartet: getrennte Kontenlisten; Default-Abfrage liefert Standardrahmen. +Tracelinks: SyRS-021 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Voraussetzung der FiBu-Integration. +Status: belegt +``` + +``` +ID: SwRS-026 +Titel: Zentrale Konfigurationsdatenbank mit Master-Passwort-Verschlüsselung +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator, Komponente CentronConfigurationDbBL +Vorbedingung: Zentrale Konfigurations-DB ist eingerichtet oder wird angelegt. +Fakt: CentronConfigurationDbBL prüft/erstellt die Konfigurations-DB (CreateCentronConfigDb, wahlweise Integrated Security oder SQL-Login) und bietet Ver-/Entschlüsselung sensibler Texte mit einem Hotline-Master-Key (SetHotlineMasterKey, EncryptWithMasterKey/DecryptWithMasterKey); der Master-Key kann in der Konfigurations-DB oder einer geschützten Datei liegen (MasterPasswordConfigurationDatabaseStorage/MasterPasswordSecureFileStorage). +Aussage: Die Software soll sensible Zugangsdaten mit einem zentral verwalteten Master-Schlüssel verschlüsseln, dessen Ablageort (Datenbank oder gesicherte Datei) konfigurierbar ist. +Ergebnis: Sensible Konfigurationswerte sind nur mit Master-Key lesbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/CentronConfigDb/CentronConfigurationDbBL.cs, SetHotlineMasterKey/EncryptWithMasterKey/DecryptWithMasterKey; IMasterPasswordStorage-Implementierungen - Begründung: durchsetzende Verschlüsselungslogik und Ablagevarianten. +Prüfidee: Text ver- und entschlüsseln; ohne Master-Key: Entschlüsselung schlägt fehl. +Tracelinks: SyRS-017; StRS-028 +Konsolidierung: Kandidat: SwRS-023 (AESCryptoLogic) und Passwortmanagement (M-073) verwenden eigene Verschlüsselungswege für denselben Zweck „geheime Werte schützen" +Übernahmewürdigkeit: übernehmen - zentrales Secret-Handling; im Zielsystem durch Managed-Key-Dienst ersetzen. +Status: belegt +``` + +``` +ID: SwRS-027 +Titel: Kollisionssichere Vergabe fortlaufender Nummern +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente NumberGroupBL +Vorbedingung: Nächste Nummer eines Nummernkreises wird benötigt (updateDatabase=true). +Fakt: GetNextNumber aktualisiert den Zähler per bedingtem UPDATE (WHERE I3D=... AND Current=) und wiederholt die Vergabe in einer Schleife, bis genau eine Zeile geändert wurde; ein erklärender Kommentar dokumentiert dies als Schutz gegen parallele Reservierung. +Aussage: Die Software soll fortlaufende Nummern über einen Compare-and-Swap-Mechanismus vergeben, sodass auch bei parallelen Zugriffen keine Nummer doppelt vergeben wird. +Ergebnis: Eindeutige, lückenlos aufsteigende Nummern je Kreis unter Nebenläufigkeit. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs, GetNextNumber(NumberGroupEnum,NumberGroup,bool): while(true)-Schleife mit UpdateBuilder().Set(s => s.Current, nextNumber) und rowCountChanged==1-Prüfung - Begründung: durchsetzende Kollisionssicherung. +Prüfidee: Zwei parallele Nummernanforderungen; erwartet: zwei verschiedene Nummern, kein Duplikat. +Tracelinks: SyRS-012, SyRS-024 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - GoBD-relevante Eindeutigkeit. +Status: belegt +``` + +``` +ID: SwRS-028 +Titel: Verwaltung der Datenbank-/Webservice-Verbindungen +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Administrator, Komponente ConnectionBL +Vorbedingung: Client benötigt Verbindungskonfiguration. +Fakt: ConnectionBL lädt/speichert benannte CentronConnections (Datei-basiert) und unterscheidet, ob die Standardverbindung eine Webservice-Verbindung ist (IsDefaultConnectionAWebServiceConnection). +Aussage: Die Software soll mehrere benannte Verbindungen (Direkt-DB oder Webservice) verwalten und eine Standardverbindung kennzeichnen. +Ergebnis: Clients wählen zwischen Direkt- und Webservice-Zugriff. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Connections/ConnectionBL.cs, LoadConnections/SaveConnections/IsDefaultConnectionAWebServiceConnection - Begründung: implementierende Verwaltung. +Prüfidee: Standardverbindung auf Webservice stellen; erwartet: Client nutzt Webservice-Pfad. +Tracelinks: SyRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - Zwei-Wege-Zugriff (direkt/Webservice) entfällt im SaaS-Zielsystem; dort nur noch API-Zugriff. +Status: belegt +``` + +``` +ID: SwRS-029 +Titel: Kundenindividuelle Zusatzfelder je Modul mit Suche +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Endbenutzer +Vorbedingung: Für eine Objektart sind Custom-Properties definiert. +Fakt: ModuleCustomPropertyBL verwaltet Zusatzfeld-Strukturen je CentronObjectKindNumeric (auch objektbezogen), speichert Werte (ModuleCustomPropertyValueBL) und erlaubt objektübergreifende Suche über Zusatzfeldwerte (SearchObjectsThroughCustomProperties). +Aussage: Die Software soll je Objektart kundenindividuelle Zusatzfelder definieren, befüllen und durchsuchen können. +Ergebnis: Erweiterbarkeit ohne Schemaänderung; Suche über Zusatzfelder. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Customization/ModuleCustomPropertyBL.cs, GetCustomPropertyStructureForModule/SaveCustomPropertyStructure/SearchObjectsThroughCustomProperties - Begründung: implementierende Struktur-, Wert- und Suchlogik. +Prüfidee: Zusatzfeld am Kunden anlegen, Wert setzen, per Suche wiederfinden. +Tracelinks: SyRS-023 +Konsolidierung: Kandidat: M-043 CustomTables (zweiter Mechanismus für kundenindividuelle Datenstrukturen) +Übernahmewürdigkeit: übernehmen - Customizing-Fähigkeit ist Produktmerkmal. +Status: belegt +``` + +``` +ID: SwRS-030 +Titel: DSGVO-Kontaktlöschung mit Ersatztext und Löschprotokoll +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Komponente DataSecurityBL +Vorbedingung: Benutzer besitzt DSGVO_DELETE_CONTACT; Kontakte sind zur Löschung ausgewählt. +Fakt: DsgvoDeleteRightDeleteContacts löscht je nach Objektart über spezialisierte DoDelete*-Methoden, ersetzt Personendaten durch die Konstante "DSGVO: Auf Anfrage gelöscht." (optional mit Ausführendem/Zeitstempel) und führt ein deleteProtocol; die Bereinigungsfunktionen sind zusätzlich an das lizenzierte DSGVO-Modul gebunden. +Aussage: Die Software soll DSGVO-Löschungen objektartspezifisch durchführen, Personendaten durch einen standardisierten Ersatztext ersetzen und ein Protokoll erzeugen. +Ergebnis: Anonymisierte Datensätze mit nachweisbarer Durchführung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, DsgvoDeleteRightDeleteContacts(...) (Zeile 787ff) inkl. DoDeleteContactPerson/DoDeleteAccountAddressContact und Konstanten DsgvoDeletedContactMessage(WithEmployeeInfo) - Begründung: durchsetzende Lösch- und Ersetzungslogik. +Prüfidee: Ansprechpartner löschen; erwartet: Name/Kontaktdaten durch Ersatztext ersetzt, Protokolleintrag mit Benutzer und Zeit. +Tracelinks: SyRS-022 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - gesetzliche Pflicht. +Status: belegt +``` + +``` +ID: SwRS-031 +Titel: Online-Bestätigung von DSGVO-/SEPA-Dokumenten +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Kunde (extern), Komponente DsgvoBL +Vorbedingung: Ein Online-PDF-Dokument (AV-Vertrag oder SEPA-Mandat) wurde mit eindeutiger ID bereitgestellt. +Fakt: DsgvoBL verwaltet AV-Vertragsvorlagen (OrderProcessingContractTemplate) und Online-PDF-Dokumente; ShowOnlinePdfDocument liefert das Dokument per ID, ConfirmOnlinePdfDocument speichert Unterschrift, Ort, Datum und (bei SEPA) Bankname/BIC/IBAN, DeclineOnlinePdfDocument einen Ablehnungsgrund. +Aussage: Das System soll Auftragsverarbeitungsverträge und SEPA-Mandate online bereitstellen und deren Bestätigung mit Unterschrift bzw. Ablehnung mit Grund erfassen. +Ergebnis: Digital signierte AVV/SEPA-Dokumente inkl. Bankverbindung; Ablehnungen dokumentiert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Documents/Dsgvo/DsgvoBL.cs, ShowOnlinePdfDocument/ConfirmOnlinePdfDocument/DeclineOnlinePdfDocument, GetSepaContractPreviewPdf - Begründung: durchsetzende Bereitstellungs- und Bestätigungslogik. + - [SEKUNDÄR] .../Dsgvo/SepaContractOnlinePdfDocumentHandler.cs, OrderProcessingContractOnlinePdfDocumentHandler.cs - Begründung: Dokumentart-Handler. +Prüfidee: SEPA-Dokument bestätigen; erwartet: Unterschrift und IBAN gespeichert; Ablehnung erfasst Grund. +Tracelinks: SyRS-022; StRS-020 +Konsolidierung: Kandidat: Beleg-Signierprozess über Nexus (ReceiptBL SendSignDocument, SharedDocument) - zweiter Online-Signaturweg +Übernahmewürdigkeit: übernehmen - digitale Vertragsprozesse sind Zielbild. +Status: belegt +``` + +``` +ID: SwRS-032 +Titel: Mitarbeiterverwaltung mit Abteilungen, Skills und Einstellungsprofilen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Personalverwaltung +Vorbedingung: Mitarbeiterdatensätze existieren. +Fakt: Der Bereich Administration/Employees führt Abteilungen (EmployeeDepartmentBL, Zuordnung/Sortierung), Favoriten, Skills (EmployeeSkillsBL), persönliche Einstellungen und Einstellungsprofile (EmployeeSettingsProfileBL); ergänzend verwaltet EmployeeArea Urlaub, RFID-Token und Teams. +Aussage: Das System soll Mitarbeiter mit Abteilungszuordnung, Fähigkeiten (Skills), persönlichen Einstellungen und wiederverwendbaren Einstellungsprofilen verwalten. +Ergebnis: Organisationsstruktur und Qualifikationen sind abgebildet (u. a. für Ticket-Zuweisung). +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Employees/EmployeeDepartmentBL.cs, EmployeeSkillsBL.cs, EmployeeSettingsProfileBL.cs, EmployeeSettings/EmployeeSettingsBL.cs - Begründung: implementierende Verwaltungslogik. +Prüfidee: Mitarbeiter mit Skill anlegen und in abhängiger Funktion (z. B. Zuweisungsvorschlag) wiederfinden. +Tracelinks: SyRS-020; StRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - organisatorische Basisdaten. +Status: belegt +``` + +``` +ID: SwRS-033 +Titel: Datenbank-Umgebungsprüfungen beim Start +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Zuverlässigkeit (Reife) +Akteur: Komponente SqlServerBL +Vorbedingung: Anwendung/Webservice verbindet sich mit der Datenbank. +Fakt: SqlServerBL prüft die Sprache des DB-Benutzers (IsDatabaseUserLanguageOk), die Datenbankversion (CheckDatabaseVersion) und ob die Datenbank zum Webservice passt (CheckDatabaseMatchesWebService). +Aussage: Die Software soll beim Start prüfen, ob Datenbankversion, DB-Benutzereinstellungen und Webservice zueinander passen, und Abweichungen melden. +Ergebnis: Inkompatible Kombinationen werden früh erkannt statt zu Laufzeitfehlern zu führen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Environments/SqlServerBL.cs, CheckDatabaseVersion/CheckDatabaseMatchesWebService/IsDatabaseUserLanguageOk - Begründung: durchsetzende Prüfstellen. +Prüfidee: Webservice gegen fremde DB starten; erwartet: Fehlermeldung der Versions-/Zuordnungsprüfung. +Tracelinks: SyRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Startprüfungen erhöhen Betriebssicherheit. +Status: belegt +``` + +``` +ID: SwRS-034 +Titel: Zahlungs- und Belegkonditionen als Stammdaten (AssetCondition) +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Verwaltung, Belegwesen +Vorbedingung: Konditionen sind gepflegt. +Fakt: AssetConditionBL verwaltet Konditionen mit Textbausteinen (AssetConditionText) und liefert aktive Konditionen sowie Zahlungskonditionen getrennt nach Barbeleg (GetPaymentConditions(isCashAsset)); Belegarten leiten daraus u. a. automatisches Schließen ab (InvoiceSpecificLogic.ShouldCloseNewReceiptAutomatically(paymentCondition)). +Aussage: Das System soll Zahlungs-/Lieferkonditionen als zentrale Stammdaten mit Textbausteinen führen und barverkaufsspezifische Konditionen unterscheiden. +Ergebnis: Belege übernehmen Konditionen konsistent; Barbelege erhalten passende Konditionen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Masterdata/AssetConditionBL.cs, GetPaymentConditions(bool isCashAsset)/GetActiveAssetConditions/GetAssetConditionTexts - Begründung: implementierende Stammdatenlogik. +Prüfidee: Kondition als Bar-Kondition markieren; erwartet: nur in Barbelegen wählbar. +Tracelinks: SyRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Konditionsstammdaten bleiben erforderlich. +Status: belegt +``` + +``` +ID: SwRS-035 +Titel: Netzwerkdiagnose für Support-Zwecke +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Analysierbarkeit) +Akteur: Support, Komponente NetworkDiagnosticsBL +Vorbedingung: Verbindungsprobleme sollen analysiert werden. +Fakt: NetworkDiagnosticsBL implementiert Diagnosen bis auf TDS-Protokollebene (interner TdsPreLoginWrapperStream) und Musterprüfungen (NetworkDiagnosticsPatterns). +Aussage: Die Software soll Netzwerk-/Datenbankverbindungen diagnostizieren können, einschließlich SQL-Server-Handshake (TDS PreLogin). +Ergebnis: Supportfähige Diagnoseergebnisse bei Verbindungsproblemen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/NetworkDiagnostics/NetworkDiagnosticsBL.cs (inkl. TdsPreLoginWrapperStream) - Begründung: implementierende Diagnoselogik. +Prüfidee: Diagnose gegen erreichbaren/unerreichbaren SQL-Server; erwartet: differenzierte Befunde. +Tracelinks: SyRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - On-Premise-Diagnose entfällt weitgehend im SaaS-Betrieb. +Status: belegt +``` + +``` +ID: SwRS-036 +Titel: Persistente Performance- und Profiling-Messungen +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Performance-Effizienz (Zeitverhalten) +Akteur: Entwickler/Support +Vorbedingung: Messläufe werden ausgeführt. +Fakt: PerformanceTestBL und ProfilerBL persistieren Performancetests bzw. Profiling-Daten der Anwendung. +Aussage: Die Software soll Performancemessungen speichern, um Zeitverhalten über Versionen vergleichbar zu machen. +Ergebnis: Historisierte Messwerte. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/PerformanceTests/PerformanceTestBL.cs, .../Profiling/ProfilerBL.cs - Begründung: implementierende Messlogik. +Prüfidee: Messlauf ausführen; erwartet: persistierter Messdatensatz. +Tracelinks: SyRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - im Zielsystem durch APM-Werkzeuge ersetzen. +Status: belegt +``` + +``` +ID: SwRS-037 +Titel: Globale und persönliche Telefonie-Einstellungen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Benutzer +Vorbedingung: TAPI-Telefonie wird genutzt. +Fakt: PhoneSettingsBL trennt globale Einstellungen (UpdatePhoneSettings) von persönlichen je Benutzer (UpdatePersonalSettings/GetPersonalSettings mit LoggedInUser). +Aussage: Das System soll Telefonie-Einstellungen global vorgeben und je Benutzer individualisieren können. +Ergebnis: Persönliche Nebenstellen-/Wahlparameter überlagern globale Vorgaben. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/PhoneSettings/PhoneSettingsBL.cs, UpdatePhoneSettings/UpdatePersonalSettings - Begründung: implementierende Zweistufigkeit. +Prüfidee: Persönliche Einstellung setzen; erwartet: weicht von globaler ab und wirkt nur für den Benutzer. +Tracelinks: SyRS-030 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Telefonie-Integration bleibt gefragt (im Web über CTI-Dienste). +Status: belegt +``` + +``` +ID: SwRS-038 +Titel: Hersteller-Portal: Kundenstatusprüfung und Report-Upload +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Herstellerportal (c-entron), Installation beim Kunden +Vorbedingung: Kunden-Produkt-ID ist vorhanden. +Fakt: PortalWebServiceAccessBL.CheckCustomerStatusByProductId prüft den Kundenstatus gegen das Portal; ReportPortalWebServiceBL überträgt Reports; das Sonderrecht UPLOAD_PORTAL_REPORTS (99999458) beschränkt Uploads auf berechtigte Datenbanken. +Aussage: Das System soll den Lizenz-/Kundenstatus gegen das Herstellerportal prüfen und Report-Vorlagen dorthin hochladen können, letzteres nur mit Sonderrecht. +Ergebnis: Zentrale Reportverteilung; Statusabgleich mit Hersteller. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Portal/PortalWebServiceAccessBL.cs, CheckCustomerStatusByProductId; ReportPortalWebServiceBL.cs - Begründung: implementierende Portalzugriffe. + - [SEKUNDÄR] UserRightsConst.cs, UPLOAD_PORTAL_REPORTS = 99999458 mit Kommentar "Special Right: Only in c-entron databases where you are allowed to upload reports to the portal" - Begründung: Sonderrechtssteuerung. +Prüfidee: Upload ohne Sonderrecht; erwartet: Ablehnung. +Tracelinks: SyRS-025 +Konsolidierung: nein +Übernahmewürdigkeit: Sonderfall - herstellerinterner Vertriebskanal; im Zielsystem neu bewerten. +Status: belegt +``` + +``` +ID: SwRS-039 +Titel: Versionsgebundene Wartungsskripte und wiederkehrende Datenkorrekturen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente ScriptEngineBL, Administrator +Vorbedingung: Anwendungsstart bzw. geplanter Wartungslauf. +Fakt: ScriptEngineBL.ExecuteScripts führt Skriptmethoden aus (auch vor dem Login, versioniert über currentVersionOverride); wiederkehrende Korrektur-Skripte (z. B. FixAddressNoContact, FixArticleMainStockQuantityNull, FixCountriesWithIsEUMemberNull) laufen über DoExecuteRecurringScriptMethodSet; SQLManagementBL zeigt Backups, blockierte Prozesse und Wartungspläne. +Aussage: Das System soll versionsgebundene Migrations-/Wartungsskripte und wiederkehrende Datenkorrekturen automatisch ausführen sowie SQL-Betriebszustände (Backups, Blockaden) anzeigen. +Ergebnis: Datenbestand wird bei Updates und laufend automatisch konsistent gehalten. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs, ExecuteScripts/DoExecuteRecurringScriptMethodSet und ScriptMethods/RecurringScriptMethods/Fix*.cs - Begründung: durchsetzende Ausführungslogik samt konkreten Korrekturregeln. + - [PRIMÄR] src/backend/Centron.BL/Administration/SQLManagement/SQLManagementBL.cs, ShowBackupInformations/ShowBlockedSqlProcess - Begründung: Betriebsdiagnose. +Prüfidee: Land mit IsEUMember=NULL anlegen; nach Recurring-Lauf: Wert gesetzt. +Tracelinks: SyRS-023, SyRS-018 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Migrationsmechanik als Konzept; konkrete Fix-Skripte sind Workarounds für Altdatenqualität und einzeln zu bewerten. +Status: belegt +``` + +``` +ID: SwRS-040 +Titel: Typisierter Einstellungszugriff über SettingsCollection +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Module +Vorbedingung: Einstellungen werden gelesen/geschrieben. +Fakt: AppSettingsBL.GetSettings(params AppSettingsConst[]) lädt gebündelt; SettingsCollection bietet GetBool/GetString/GetEnum/GetLargeString; Schreibpfad über UpdateSettingsCollection. +Aussage: Die Software soll Einstellungen gebündelt laden und typisiert bereitstellen, um Fehlinterpretationen der generischen Wertfelder zu vermeiden. +Ergebnis: Einheitlicher, typsicherer Konfigurationszugriff. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsBL.cs, SettingsCollection.cs, UpdateSettingsCollection.cs - Begründung: implementierender Zugriffspfad (verwendet u. a. in InvoiceSpecificLogic, AccountBL, ArtificialIntelligenceBL). +Prüfidee: Bool-Setting über GetBool lesen; erwartet: korrekte Typkonvertierung aus dem generischen Feld. +Tracelinks: SyRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Muster für Zielsystem. +Status: belegt +``` + +``` +ID: SwRS-041 +Titel: Verwaltung von UI-Themes mit Standardtheme +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Benutzer +Vorbedingung: Themes sind hinterlegt. +Fakt: ThemeBL verwaltet Themes (aktiv/alle), liefert ein Standardtheme (GetDefaultTheme) und speichert Themes benutzerbezogen (Save mit currentUserI3D). +Aussage: Das System soll mehrere UI-Themes anbieten, ein Standardtheme definieren und Themes aktivierbar/deaktivierbar führen. +Ergebnis: Einheitliches, wählbares Erscheinungsbild. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Themes/ThemeBL.cs, GetActiveThemes/GetDefaultTheme/Save - Begründung: implementierende Themeverwaltung. +Prüfidee: Theme deaktivieren; erwartet: nicht mehr wählbar; Standardtheme greift ohne Benutzerwahl. +Tracelinks: SyRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Theming im Web über Designsystem. +Status: belegt +``` + +``` +ID: SwRS-042 +Titel: Zentrale Webservice-Konfigurationsdatei +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Administrator, Webservice +Vorbedingung: Webservice wird konfiguriert/gestartet. +Fakt: WebServiceConfig (serialisiert über WebServiceConfigSerializer, Zugriff über WebServiceConfigHelper.Current) enthält u. a. ActiveDirectoryAuthEnabled, TwoFactorAuthType, UseIncreasedThreadPool, ActivateHelpPage, ExecuteServices sowie DB-Verbindungsdaten (WebServiceConfigDAOConnection) und Zusatzdienste (AdditionalService). +Aussage: Das System soll den Webservice über eine zentrale Konfigurationsdatei steuern (Authentifizierungsverfahren, Dienste, Threading, Hilfeseite, Verbindungen). +Ergebnis: Betriebsverhalten des Webservice ist deklarativ konfigurierbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/WebServiceConfiguration/WebServiceConfig.cs, WebServiceConfigHelper.cs, WebServiceConfigSerializer.cs - Begründung: Konfigurationsmodell und Zugriff; TwoFactorAuthType wird in TwoFactorAuthBL ausgewertet. +Prüfidee: ExecuteServices=false setzen; erwartet: Hintergrunddienste starten nicht. +Tracelinks: SyRS-023, SyRS-005 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - als Umgebungs-/Deploymentkonfiguration im Zielsystem. +Status: belegt +``` + +``` +ID: SwRS-043 +Titel: Terminanfragen mit Vorschlagsliste und Antwortverarbeitung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Mitarbeiter, externer Empfänger +Vorbedingung: Terminanfrage mit Terminvorschlägen wurde versendet. +Fakt: AppointmentRequestBL verwaltet AppointmentRequests und AppointmentProposals und verarbeitet Empfängerantworten über HandleAppointmentRequestReply. +Aussage: Das System soll Terminanfragen mit mehreren Vorschlägen versenden und die Antwort des Empfängers automatisiert dem Vorgang zuordnen. +Ergebnis: Bestätigte Termine entstehen aus der gewählten Vorschlagsoption. +Belege: + - [PRIMÄR] src/backend/Centron.BL/AppointmentRequests/AppointmentRequestBL.cs, HandleAppointmentRequestReply/SaveOrUpdateAppointmentRequest/SaveOrUpdateAppointmentProposal - Begründung: implementierende Anfrage- und Antwortlogik. +Prüfidee: Antwort auf Vorschlag 2 senden; erwartet: Request auf bestätigt, Termin aus Vorschlag 2. +Tracelinks: SyRS-029; StRS-018 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - moderne Terminvereinbarung. +Status: belegt +``` + +``` +ID: SwRS-044 +Titel: Ablageverzeichnis für Lieferantenbestellungen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkauf, Komponente SupplierAssetBL +Vorbedingung: Lieferantenbeleg benötigt Dokumentenablage. +Fakt: SupplierAssetBL.GetSupplierPurchaseOrderDirectoryI3D liefert das Ablageverzeichnis zu einer Lieferantenbestellung. +Aussage: Die Software soll Lieferantenbelegen ein definiertes Dokumentenverzeichnis zuordnen. +Ergebnis: Belegdokumente liegen auffindbar je Bestellung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/BusinessPartner/SupplierAssetBL.cs, GetSupplierPurchaseOrderDirectoryI3D(int) - Begründung: implementierende Zuordnung. +Prüfidee: Verzeichnis-I3D für Bestellung abrufen; erwartet: konsistenter Verzeichnisknoten. +Tracelinks: SyRS-026 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Belegablage bleibt nötig. +Status: belegt +``` + +``` +ID: SwRS-045 +Titel: Automatisches Anlegen fehlender Distributoren +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente DistributorBL (Einkauf/EDI) +Vorbedingung: Externe Quelle (z. B. EDI/Preislisten) referenziert Distributorennamen. +Fakt: EnsureDistributorsExist legt zu einer Namensliste fehlende Distributor-Datensätze an und liefert die Gesamtmenge zurück. +Aussage: Die Software soll beim Import referenzierte Distributoren automatisch anlegen, statt Importe an fehlenden Stammdaten scheitern zu lassen. +Ergebnis: Importe laufen ohne manuelle Vorpflege der Distributoren. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Buying/External/DistributorBL.cs, EnsureDistributorsExist(IList) - Begründung: durchsetzende Anlagelogik. +Prüfidee: Import mit unbekanntem Distributornamen; erwartet: Datensatz entsteht automatisch. +Tracelinks: SyRS-027 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - robuste Importe. +Status: belegt +``` + +``` +ID: SwRS-046 +Titel: Kalender: Darstellungs-, Synchronisations- und Ticketterminate-Einstellungen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Benutzer, Administrator +Vorbedingung: Kalendermodul wird genutzt. +Fakt: CalendarBL persistiert Darstellungseinstellungen, Synchronisationseinstellungen (Exchange) und Einstellungen für automatische Termine zu Tickets (UpdateAppointmentsForTicketsSettings). +Aussage: Das System soll Kalenderdarstellung, Kalender-Synchronisation und automatische Ticket-Termine konfigurierbar machen. +Ergebnis: Ticketfälligkeiten erscheinen regelbasiert als Termine; Sync-Verhalten ist steuerbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Calendar/CalendarBL.cs, UpdateCalendarRepresentationSettings/UpdateCalendarSynchronizationSettings/UpdateAppointmentsForTicketsSettings - Begründung: implementierende Einstellungslogik. +Prüfidee: Ticket-Termine aktivieren; erwartet: Termin je Ticketfälligkeit im Kalender. +Tracelinks: SyRS-029; StRS-018 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kalender bleibt Kernorganisation. +Status: belegt +``` + +``` +ID: SwRS-047 +Titel: Zentrale Icon-Verwaltung inkl. Webservice-Bereitstellung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Clients +Vorbedingung: Icons werden für UI-Elemente benötigt. +Fakt: CentronIconsBL und CentronIconsWebserviceBL verwalten Icons und stellen sie Clients über den Webservice bereit. +Aussage: Das System soll Icons zentral verwalten und allen Clients (Desktop/Web) einheitlich bereitstellen. +Ergebnis: Konsistente Symbolik über alle Oberflächen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/CentronIcons/CentronIconsBL.cs, CentronIconsWebserviceBL.cs - Begründung: implementierende Verwaltung/Bereitstellung. +Prüfidee: Icon ändern; erwartet: Desktop und Web zeigen dasselbe Icon. +Tracelinks: SyRS-031 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - untergeordnet, aber nützlich. +Status: belegt +``` + +``` +ID: SwRS-048 +Titel: Zentrale Einstellungen für den Nexus-Webclient +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Nexus-Webclient ist im Einsatz. +Fakt: CentronNexusBL.UpdateCentronNexusSettings persistiert die Nexus-Einstellungen (CentronNexusSettingsDTO) serverseitig. +Aussage: Das System soll die Konfiguration des Webclients zentral serverseitig verwalten. +Ergebnis: Einheitliche Webclient-Konfiguration für alle Benutzer. +Belege: + - [PRIMÄR] src/backend/Centron.BL/CentronNexus/CentronNexusBL.cs, UpdateCentronNexusSettings(CentronNexusSettingsDTO) - Begründung: implementierende Einstellungsverwaltung. +Prüfidee: Einstellung ändern; erwartet: Wirkung für alle Webclient-Sitzungen. +Tracelinks: SyRS-031 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Basis des Web-Zielsystems. +Status: belegt +``` + +``` +ID: SwRS-049 +Titel: Interner Chat mit Mitgliedern, Notizen und Lesestatus +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Mitarbeiter +Vorbedingung: Chat existiert; Benutzer ist Mitglied. +Fakt: ChatBL liefert Chats gefiltert je Benutzer, paginierte Nachrichten, Notizen je Chat (SaveOrUpdateNotes), Lesestatus je Mitglied (LastViewedChat, ChatMemeberLastViewedHistoryLog) und Nachrichten-Zustellinfos (GetChatMessageInfo). +Aussage: Das System soll interne Chats mit Mitgliederverwaltung, Notizen, Lesebestätigungen und Nachrichtenhistorie bereitstellen. +Ergebnis: Nachvollziehbare Teamkommunikation mit Gelesen-Status. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Chats/ChatBL.cs, GetChats/GetChatMessages/LastViewedChat/GetChatMessageInfo - Begründung: implementierende Chatlogik. +Prüfidee: Nachricht senden, durch zweites Mitglied lesen; erwartet: Lesestatus aktualisiert. +Tracelinks: SyRS-029; StRS-017 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - interne Kommunikation; ggf. durch Standardtools ersetzbar (fachlich prüfen). +Status: belegt +``` + +``` +ID: SwRS-050 +Titel: Checklisten mit Kundenzuordnung und Änderungsprotokoll +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Techniker/Service +Vorbedingung: Checklistenvorlagen existieren. +Fakt: CentronChecklistBL verwaltet Checklisten samt Positionen, ordnet sie Kunden zu (UpdateChecklistCustomerMappings) und führt Änderungen über ChangeLogBL nach. +Aussage: Das System soll Checklisten (z. B. für Serviceeinsätze) mit Positionen verwalten, Kunden zuordnen und Änderungen protokollieren. +Ergebnis: Kundenbezogene Checklisten mit Änderungshistorie. +Belege: + - [PRIMÄR] src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs, SaveOrUpdateChecklists/UpdateChecklistCustomerMappings/DeleteCentronChecklistItem; CheckListArea/ChangeTracking/ChangeLogBL.cs - Begründung: implementierende Verwaltungs- und Protokolllogik. +Prüfidee: Checkliste ändern; erwartet: ChangeLog-Eintrag. +Tracelinks: SyRS-029 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Servicequalität. +Status: belegt +``` + +``` +ID: SwRS-051 +Titel: Länder- und Währungsverwaltung mit Kursaktualisierung +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Verwaltung +Vorbedingung: Länder mit Währung/MwSt.-Zuordnung sind gepflegt. +Fakt: CountryBL aktualisiert Währungskurse je Land (UpdateCurrencyRateByCountry, UpdateCurrencyRateByRateDictionary), pflegt EU-Mitgliedschaft (Recurring-Fix FixCountriesWithIsEUMemberNull) und setzt Länder-Defaults auf Artikel-Materialgruppen (UpdateArticleMaterialGroupsWithDefaultCountryValues mit VAT/Steuersatz/Kurs). +Aussage: Das System soll Länder mit Währungskursen und Steuerzuordnung verwalten und Kursänderungen auf abhängige Stammdaten anwenden. +Ergebnis: Fremdwährungsbelege rechnen mit aktuellen Kursen (CurrencyFactor der Belege). +Belege: + - [PRIMÄR] src/backend/Centron.BL/CountryArea/CountryBL.cs, UpdateCurrencyRateByCountry/UpdateArticleMaterialGroupsWithDefaultCountryValues/UpdateCurrencyRateByRateDictionary - Begründung: implementierende Kurs- und Defaultlogik. +Prüfidee: Kurs ändern; erwartet: neuer Beleg nutzt neuen CurrencyFactor. +Tracelinks: SyRS-011; StRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Auslandsgeschäft. +Status: belegt +``` + +``` +ID: SwRS-052 +Titel: CPra-Konnektor: tokenbasierte Anmeldung und Webhook-Links +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Externes System „CPra", Support +Vorbedingung: CPra-Zugangsdaten sind konfiguriert. +Fakt: CPraConnectorBL meldet sich mit Benutzer/Passwort an (ConnectToCPra, liefert Auth-Token), listet Webhooks und erzeugt parametrisierte Webhook-Links inkl. Ticketbezug (GetCPraWebHookLink mit Kundennummer, Ticketnummer, Zielmail). +Aussage: Das System soll das CPra-Drittsystem tokenbasiert anbinden und ticketbezogene Webhook-Links erzeugen. +Ergebnis: Ticketdaten können an CPra-Workflows übergeben werden. +Belege: + - [PRIMÄR] src/backend/Centron.BL/CPra/CPraConnectorBL.cs, ConnectToCPra/GetCPraWebHooks/GetCPraWebHookLink - Begründung: implementierende Anbindung. +Prüfidee: Webhook-Link zu Ticket erzeugen; erwartet: Link enthält Ticket-/Kundenparameter. +Tracelinks: SyRS-027 +Konsolidierung: nein +Übernahmewürdigkeit: Sonderfall - kundenspezifischer Konnektor, Bedarf im Zielsystem prüfen. +Status: belegt +``` + +``` +ID: SwRS-053 +Titel: Kundenindividuelle Zusatztabellen mit Variablenersetzung +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Customizing, Komponente CustomTableBL +Vorbedingung: Custom-Tabelle ist definiert. +Fakt: CustomTableBL fügt Datensätze in Custom-Tabellen ein (InsertCustomTableData) und ersetzt Spaltenwert-Variablen aus einem Datenobjekt (ReplaceColumnValueVariables). +Aussage: Die Software soll kundenindividuelle Tabellen befüllen können, wobei Spaltenwerte Variablen enthalten dürfen, die zur Laufzeit aus Kontextobjekten ersetzt werden. +Ergebnis: Erweiterbare Datenablage ohne Programmänderung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Customizations/CustomTables/CustomTableBL.cs, InsertCustomTableData/ReplaceColumnValueVariables - Begründung: implementierende Logik. +Prüfidee: Insert mit Variable; erwartet: ersetzter Wert in der Tabelle. +Tracelinks: SyRS-023 +Konsolidierung: Kandidat: SwRS-029 (Custom Properties) - zwei Customizing-Mechanismen für Zusatzdaten +Übernahmewürdigkeit: Workaround - generische Zusatztabellen im Zielsystem durch definierte Erweiterungspunkte ersetzen. +Status: belegt +``` + +``` +ID: SwRS-054 +Titel: Kundengeräte (AccountDevices) mit Gerätelog und Suche +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Service, Komponente AccountDeviceBL +Vorbedingung: Geräte sind Konten zugeordnet. +Fakt: AccountDeviceBL speichert Kundengeräte (SaveAccountDevice mit AppUser), löscht rechtegebunden, schreibt Gerätelogs (WriteAccountDeviceLog) und sucht über Filter (SearchAccountDevices); Geräte sind über I3Ds oder externe Geräte-IDs adressierbar. +Aussage: Das System soll Geräte je Kundenkonto mit externem Identifikator, Änderungslog und Suchfunktion verwalten. +Ergebnis: Gerätebestand je Kunde ist dokumentiert und durchsuchbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Devices/AccountDeviceBL.cs, SaveAccountDevice/WriteAccountDeviceLog/SearchAccountDevices/GetAccountDeviceLogs - Begründung: implementierende Geräteverwaltung. +Prüfidee: Gerät anlegen, Logeintrag schreiben, per externer ID suchen. +Tracelinks: SyRS-028; StRS-022 +Konsolidierung: Kandidat: Kundengeräte existieren zusätzlich als „CustomerAssets"-Stammblätter und im DocuBoard-Assetmanagement - drei Datenhaltungen für Geräte beim Kunden +Übernahmewürdigkeit: übernehmen - Gerätebestand ist Servicegrundlage; Konsolidierung nötig. +Status: belegt +``` + +``` +ID: SwRS-055 +Titel: Asset-Management-Partner und AD-Ausschlüsse (DocuBoard) +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Service (Managed Services) +Vorbedingung: Kunde nimmt am Asset-Management teil. +Fakt: DocuBoard verwaltet Asset-Management-Partner je Kunde (AssetManagementPartnerBL), Artikelzuordnungen (AssetManagementArticleAssignmentBL) und Ausschlüsse von AD-Systembenutzern (AssetManagementADSystemUserExclusionBL). +Aussage: Das System soll für das Asset-Management je Kunde Partner, Artikelzuordnungen und auszuschließende AD-Benutzer verwalten. +Ergebnis: Automatisiertes Asset-Management mit steuerbaren Ausnahmen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/DocuBoard/AssetManagementPartnerBL.cs, AssetManagementArticleAssignmentBL.cs, AssetManagementADSystemUserExclusionBL.cs - Begründung: implementierende Verwaltungslogik. +Prüfidee: AD-Benutzer ausschließen; erwartet: taucht in Asset-Erfassung nicht mehr auf. +Tracelinks: SyRS-028; StRS-022 +Konsolidierung: Kandidat: SwRS-054 (Gerätedatenhaltungen) +Übernahmewürdigkeit: übernehmen - MSP-Funktionalität. +Status: belegt +``` + +``` +ID: SwRS-056 +Titel: Systemdokumentationen mit Kategorien, Status und Rechteprüfung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Techniker, Komponente DocumentationBL +Vorbedingung: Benutzer besitzt das Dokumentationsrecht (checkRight=true als Standard). +Fakt: DocumentationBL (DBBaseBL) liefert Dokumentationen gefiltert, nach Status und je Kunde kategorisiert (GetCategories(customerI3D)); Zugriffe prüfen standardmäßig Benutzerrechte. +Aussage: Das System soll kundenbezogene Systemdokumentationen mit Kategorien und Status rechtegeschützt verwalten. +Ergebnis: Dokumentationen sind nur befugten Benutzern zugänglich. +Belege: + - [PRIMÄR] src/backend/Centron.BL/DocumentationArea/DocumentationBL.cs, GetDocumentation(..., bool checkRight = true)/GetDocumentationByStatus/GetCategories(int) - Begründung: implementierende, rechtegebundene Bereitstellung. +Prüfidee: Abruf ohne Recht; erwartet: leere/abgelehnte Antwort. +Tracelinks: SyRS-026; StRS-020 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kundendokumentation ist MSP-Kern. +Status: belegt +``` + +``` +ID: SwRS-057 +Titel: FiBu-Exportkonfigurationen mit Formatwahl und Standardkennzeichen +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Buchhaltung, Komponente BookKeepingExportBL +Vorbedingung: Exportkonfiguration wird gepflegt. +Fakt: SaveExportSettings speichert BookKeepingExportConfigurationen (u. a. BookKeepingType wie DatevXmlOnline, Versionsfelder Debitor/Kreditor) und erzwingt genau eine Default-Konfiguration (alle anderen DefaultExport=false); kundenspezifische Exportspalten sind über BookKeepingExportCustomInterfaceColumn definierbar. +Aussage: Die Software soll mehrere FiBu-Exportkonfigurationen mit Formattyp verwalten, genau eine als Standard führen und kundenspezifische Spaltenlayouts unterstützen. +Ergebnis: Reproduzierbare Exporte je Konfiguration; eindeutiger Standard. +Belege: + - [PRIMÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs, SaveExportSettings(...) (DefaultExport-Rücksetzschleife, Zeile 108ff), SaveCustomInterfaceColumn - Begründung: durchsetzende Konfigurationslogik. +Prüfidee: Zweite Konfiguration als Default speichern; erwartet: erste verliert Default. +Tracelinks: SyRS-021 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Export-Varianten bleiben nötig. +Status: belegt +``` + +``` +ID: SwRS-058 +Titel: Doppelübergabeschutz durch Übertragungsstatus je FiBu-Objekt +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Komponente BookKeepingExportBL +Vorbedingung: Belege/Stammdaten wurden bereits exportiert. +Fakt: IsAssetExported/IsReceiptExported prüfen den Exportstatus je Beleg; Abfragen der Exportkandidaten filtern über transferred-Parameter; getrennte Historien existieren für Kunden-/Lieferantenbelege, Stammdaten und Kassenbuch. +Aussage: Die Software soll bereits an die FiBu übergebene Objekte kennzeichnen und von Folgeexporten ausschließen, sofern nicht ausdrücklich erneut angefordert. +Ergebnis: Keine Doppelbuchungen durch wiederholte Exporte. +Belege: + - [PRIMÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs, IsReceiptExported(CentronObjectKindNumeric,int), GetExportAddresses(..., bool transferred, ...), GetBookKeepingExportCashBookData(..., bool alreadyExported, ...) - Begründung: durchsetzende Statusprüfungen. +Prüfidee: Beleg zweimal in Exportlauf aufnehmen; erwartet: zweiter Lauf ohne den Beleg. +Tracelinks: SyRS-021 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Schutz der Buchhaltungsintegrität. +Status: belegt +``` + +``` +ID: SwRS-059 +Titel: RMA-Abwicklung mit Rücksendung an Kunde und Lieferant +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Service, Komponente RmaBL +Vorbedingung: Reklamierter Artikel ist erfasst. +Fakt: RmaBL führt RMA-Vorgänge mit Rücksendungen vom Kunden (RmaSendBack) und Weitersendungen zum Lieferanten (RmaSendForth), bietet Übersichten je Filter/Benutzer (GetRmaOverview, GetRmaSendOverview) und eine RMA-Historie je Artikel (GetRmaArticles); Versandarten verwaltet RmaSendKindBL. +Aussage: Das System soll Reklamationen (RMA) als Vorgang mit Kunden-Rücknahme und Lieferanten-Weiterleitung inkl. Artikelhistorie und Versandarten abwickeln. +Ergebnis: Lückenlose RMA-Kette vom Kunden bis zum Lieferanten. +Belege: + - [PRIMÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs, SaveRmaSendForth/GetRmaSendBacksByFilter/GetRmaArticles/GetRmaOverview; RmaSendKindBL.cs - Begründung: implementierende RMA-Prozesslogik. +Prüfidee: RMA anlegen, an Lieferant weitersenden; erwartet: beide Teilvorgänge verknüpft, Artikelhistorie ergänzt. +Tracelinks: SyRS-028; StRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kernprozess im Hardwarehandel. +Status: belegt +``` + +``` +ID: SwRS-060 +Titel: Distributorspezifische EDI-Bestellerzeugung und -Upload +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Komponente EDIDispatcherBL +Vorbedingung: Lieferantenbestellung mit EDI-Konfiguration (Kundennummer beim Lieferanten) liegt vor. +Fakt: CreateEDISuggestionOrderAsync erzeugt aus ReceiptSupplierOrderDTO ein distributorspezifisches XML (EDIMultidistributors-Weiche); Upload-Methoden existieren je Distributor (EGIS, ITscope mit Benutzer-Mail, Concerto) und liefern EDI-Log-DTOs; ITscope-Warnungen sind abrufbar (GetItScopeWarnung). +Aussage: Die Software soll Bestellungen in das jeweilige Distributorformat transformieren, per Distributor-Upload übertragen und Rückmeldungen/Warnungen protokollieren. +Ergebnis: Formatkonforme, protokollierte Bestellübertragung je Distributor. +Belege: + - [PRIMÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs, CreateEDISuggestionOrderAsync(...), EdiEgisOrderUploadAsync/EdiItScopeOrderUploadAsync/EdiConcertoOrderUploadAsync - Begründung: durchsetzende Transformations- und Versandlogik. +Prüfidee: Bestellung je Distributor generieren; erwartet: distributorspezifisches XML-Schema. +Tracelinks: SyRS-027 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Formatvielfalt bleibt Realität. +Status: belegt +``` + +``` +ID: SwRS-061 +Titel: Mitarbeiterstatus: Verfügbarkeit, Dispatcher-Rolle, Aktivprüfung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente EmployeeBL +Vorbedingung: Mitarbeiterdatensatz existiert. +Fakt: EmployeeBL setzt genau einen Dispatcher (SetDispatcher), aktualisiert die Verfügbarkeit (UpdateEmployeeAvailability mit EmployeeAvailability-Enum), prüft aktive Mitarbeiter (IsActiveEmployeeCompact) und mappt AppUser↔Employee↔Mandant (GetEmployeeI3DFromAppUser, GetMandatorI3DFromEmployee). +Aussage: Die Software soll je Mitarbeiter Verfügbarkeitsstatus und Dispatcher-Rolle führen und Logins eindeutig Mitarbeitern und Mandanten zuordnen. +Ergebnis: Zuweisungslogik (z. B. Tickets) kann auf Verfügbarkeit und Dispatcher aufsetzen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/EmployeeArea/EmployeeBL.cs, SetDispatcher/UpdateEmployeeAvailability/IsActiveEmployeeCompact/GetEmployeeI3DFromAppUser - Begründung: implementierende Statuslogik. +Prüfidee: Zweiten Mitarbeiter als Dispatcher setzen; erwartet: Rolle wechselt eindeutig. +Tracelinks: SyRS-020; StRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Einsatzsteuerung. +Status: belegt +``` + +``` +ID: SwRS-062 +Titel: Überwachung erwarteter Ereignisse mit Protokoll +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Service (MSP), Komponente ExpectedEventsBL +Vorbedingung: Erwartetes Ereignis (z. B. Datensicherungsmeldung eines Kundensystems) ist je Konto definiert. +Fakt: ExpectedEventsBL verwaltet ExpectedEvents je Konto und schreibt Logeinträge (SaveExpectedEventLogEntry, GetAllExpectedEventLogEntries). +Aussage: Das System soll erwartete wiederkehrende Ereignisse je Kunde definieren und deren Eintreffen protokollieren, sodass ausbleibende Ereignisse erkennbar sind. +Ergebnis: Ausbleibende Meldungen werden sichtbar (Grundlage für Alarmierung). +Belege: + - [PRIMÄR] src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs, SaveExpectedEvent/SaveExpectedEventLogEntry/GetAllExpectedEventsByAccount - Begründung: implementierende Ereignisverwaltung. +Prüfidee: Ereignis definieren, Eintreffen loggen; erwartet: Log je Konto abrufbar. +Tracelinks: SyRS-018; StRS-031 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - MSP-Monitoring. +Status: belegt +``` + +``` +ID: SwRS-063 +Titel: Konfiguration externer Helpdesk-Anbindungen +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Externes Helpdesk-System soll angebunden werden. +Fakt: ExternalHelpdeskConfigurationBL verwaltet Konfigurationen gefiltert (GetExternalHelpdeskConfigurationByFilter, SaveOrUpdate als Liste, Delete per Filter). +Aussage: Das System soll Anbindungen an externe Helpdesk-Systeme konfigurierbar verwalten. +Ergebnis: Tickets können mit Fremdsystemen gekoppelt werden. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs, SaveOrUpdateExternalHelpdeskConfiguration - Begründung: implementierende Konfigurationsverwaltung. +Prüfidee: Konfiguration anlegen und per Filter wiederfinden. +Tracelinks: SyRS-027; StRS-005 +Konsolidierung: Kandidat: DataExchange/Connectors (DocBee-Ticketkonnektor) - zwei Wege zur Fremdticket-Kopplung +Übernahmewürdigkeit: übernehmen - Ökosystem-Anbindung. +Status: belegt +``` + +``` +ID: SwRS-064 +Titel: Einbindung externer Programme als Tools +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Benutzer +Vorbedingung: Externes Tool ist definiert. +Fakt: ExternalToolBL speichert externe Tools (SaveExternalTool mit LoggedInUser) und listet/löscht sie. +Aussage: Das System soll externe Programme/Verknüpfungen als aufrufbare Tools verwalten. +Ergebnis: Benutzer starten Drittprogramme aus der Oberfläche. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ExternalToolsBL/ExternalToolBL.cs, SaveExternalTool/GetAllExternalTools - Begründung: implementierende Verwaltung. +Prüfidee: Tool anlegen; erwartet: erscheint in der Toolliste. +Tracelinks: SyRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - Desktopgebundene Toolaufrufe im Web neu denken (Links/Integrationen). +Status: belegt +``` + +``` +ID: SwRS-065 +Titel: Nummerierte Zahlungseingangsprotokolle und Zahlungsübersichten +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Zahlungseingänge werden verarbeitet. +Fakt: IncomingPaymentBL erzeugt Zahlungseingangs-Logeinträge mit fortlaufender Nummer (GetNewIncomingPaymentLogNumber) und Übersichten inkl. Lastschriftstatus (directDebitCreated); PaymentsBL liefert Ein-/Ausgangszahlungen per Filter und löscht Zahlungseingänge rechtegebunden (LoggedInUser). +Aussage: Die Software soll Zahlungseingänge fortlaufend nummeriert protokollieren, nach Lastschrift-Erstellung filtern und Zahlungen (ein-/ausgehend) auswertbar machen. +Ergebnis: Nachvollziehbare Zahlungsverarbeitung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentBL.cs, CreateIncomingPaymentLogItem/GetNewIncomingPaymentLogNumber/GetIncomingPaymentLogOverview; Finances/Payments/PaymentsBL.cs, DeleteIncomingPayment/GetOutgoingPayments - Begründung: implementierende Protokoll- und Auswertelogik. +Prüfidee: Zwei Zahlungseingänge protokollieren; erwartet: fortlaufende Lognummern. +Tracelinks: SyRS-032 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Zahlungsnachweis. +Status: belegt +``` + +``` +ID: SwRS-066 +Titel: Automatische Zuordnungsvorschläge und Buchung von Bankumsätzen +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Komponente OnlineBankingAccountTransactionsBL +Vorbedingung: Importierte Bankumsätze sind offen. +Fakt: AutoCompleteAccountTransacitons erzeugt Zuordnungsvorschläge; UpdateOnlineBankingTransactionAssignment setzt Zuordnungen; BookAmountsForAccountTransacitons bucht Beträge auf Belege; UndoBookingForAccountTransaciton nimmt Buchungen zurück; ExecuteOnlineBankingInspectorCheck findet Inkonsistenzen, RepairOnlineBankingInspectorItems behebt sie; CheckForUnknownIbans meldet unbekannte Gegenkonten. +Aussage: Die Software soll Bankumsätze regelbasiert Belegen zuordnen, Buchung und Rücknahme unterstützen und Konsistenzprüfungen mit Reparaturfunktion bieten. +Ergebnis: Weitgehend automatisierter, korrigierbarer Zahlungsabgleich. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs, Methoden wie im Fakt (Zeilen 524, 883, 1003, 1093, 1345) - Begründung: durchsetzende Abgleichslogik. +Prüfidee: Buchung durchführen und zurücknehmen; erwartet: Beleg-Zahlstatus wechselt entsprechend; Inspector meldet keine Differenzen. +Tracelinks: SyRS-032 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kernfunktion. +Status: belegt +``` + +``` +ID: SwRS-067 +Titel: Import „Sonderartikel zu Vertrag" über kundenspezifisches Gateway +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Komponente CustomGatewayBL +Vorbedingung: Importdefinition existiert; Benutzer angemeldet. +Fakt: CustomGatewayBL verwaltet SpecialArticleToContractImports (CRUD mit LoggedInUser), ermittelt Vertragspreise zu Sonderartikeln (GetSpecialArticleToContractPrices) und mappt externe Artikelcodes (GetSpecialArticleToContractByExternalCodes). +Aussage: Die Software soll Sonderartikel externer Quellen über definierbare Importe Verträgen zuordnen und deren Preise auflösen. +Ergebnis: Vertragsbezogene Sonderpreise aus Fremddaten. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Gateway/CustomGatewayBL.cs, SaveSpecialArticleToContractImport/GetSpecialArticleToContractPrices/GetSpecialArticleToContractByExternalCodes - Begründung: implementierende Import- und Preislogik. +Prüfidee: Import mit externem Code; erwartet: Zuordnung zum Vertragsartikel und Preis. +Tracelinks: SyRS-027; StRS-004 +Konsolidierung: nein +Übernahmewürdigkeit: Sonderfall - kundenspezifische Gateway-Logik; Bedarf je Kunde prüfen. +Status: belegt +``` + +``` +ID: SwRS-068 +Titel: Lucene-Volltextindex mit gezielter Nachindizierung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente IndexSearchBL, Hintergrunddienst +Vorbedingung: Indexverzeichnis ist verfügbar. +Fakt: UpdateAllIndexes baut alle Indizes (abbrechbar per CancellationToken); RequestUpdateFor merkt einzelne Objekte zur Nachindizierung vor, UpdateRequestedIndexes arbeitet sie ab; SearchIndex filtert optional nach Objektart; Indizierungsfehler werfen ObjectIndexingFailedException. +Aussage: Die Software soll Volltextindizes inkrementell je geändertem Objekt aktualisieren und Vollaufbau abbrechbar gestalten. +Ergebnis: Aktuelle Suchtreffer ohne teuren Vollaufbau im Regelbetrieb. +Belege: + - [PRIMÄR] src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs, RequestUpdateFor/UpdateRequestedIndexes/UpdateAllIndexes/SearchIndex - Begründung: implementierende Indexlogik. +Prüfidee: Objekt ändern; erwartet: nach UpdateRequestedIndexes ist der neue Text auffindbar. +Tracelinks: SyRS-033 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Mechanik im Zielsystem z. B. mit Such-Service. +Status: belegt +``` + +``` +ID: SwRS-069 +Titel: Shop-Integrationsobjekte mit externer ID-Synchronisation +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Externes Shopsystem +Vorbedingung: Kundengruppen/Rollen werden vom Shop synchronisiert. +Fakt: EsCustomerGroupBL (und EsRoleBL) verwalten Integrationsobjekte mit ExternalId-Lookup (GetByExternalId) und Massen-Create/Update/Delete mit optionaler Benutzerangabe. +Aussage: Die Software soll Shop-Kundengruppen und -Rollen über externe IDs idempotent synchronisieren können. +Ergebnis: Wiederholte Synchronisation erzeugt keine Duplikate. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Integrations/EsCustomerGroupBL.cs, GetByExternalId/Create/Update/Delete - Begründung: implementierende Synchronisationslogik. +Prüfidee: Gruppe zweimal mit derselben ExternalId anlegen; erwartet: ein Datensatz. +Tracelinks: SyRS-027; StRS-019 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Shop-Anbindung bleibt relevant. +Status: belegt +``` + +``` +ID: SwRS-070 +Titel: IT-Planner: Kategorien für virtuelle Checklistenobjekte +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Service (IT-Planung) +Vorbedingung: IT-Planner wird genutzt. +Fakt: ChecklistVirtualObjectCategoryBL verwaltet Kategorien virtueller Objekte (RBChecklistVirtualObjectCategory) mit Filterabfrage und Löschung. +Aussage: Das System soll virtuelle Objekte der IT-Planung kategorisieren können. +Ergebnis: Strukturierte IT-Planungsobjekte. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs, GetChecklistVirtualObjectCategoriesByFilter/DeleteChecklistVirtualCategory - Begründung: implementierende Kategorienverwaltung. +Prüfidee: Kategorie anlegen/löschen; erwartet: Filterabfrage spiegelt Änderung. +Tracelinks: SyRS-029 +Konsolidierung: nein +Übernahmewürdigkeit: Sonderfall - Nutzungsgrad des IT-Planners vor Übernahme prüfen (RB-Präfix deutet auf Riverbird-Herkunft). +Status: belegt +``` + +``` +ID: SwRS-071 +Titel: Lagerortverwaltung mit Synchronisation und Umbuchungsprotokoll +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Logistik, Komponente StockBL +Vorbedingung: Lager (Stock) sind definiert. +Fakt: StockBL synchronisiert Lagerbestände (SynchronizeWarehouses), lädt offene Lager, speichert Lager und protokolliert Umbuchungen (WriteStockRebookLog, GetStockRebookLogs). +Aussage: Die Software soll Lagerorte verwalten, Bestände synchronisieren und jede Umbuchung protokollieren. +Ergebnis: Konsistente Lagerbestände mit Umbuchungshistorie. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs, SynchronizeWarehouses/WriteStockRebookLog/SaveWarehouse - Begründung: implementierende Lagerlogik. +Prüfidee: Umbuchung zwischen Lagern; erwartet: RebookLog-Eintrag, Bestände angepasst. +Tracelinks: SyRS-013; StRS-008 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Mehrlagerfähigkeit. +Status: belegt +``` + +``` +ID: SwRS-072 +Titel: E-Mail-Signaturen mit Platzhaltern und Domain-Blacklist +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente Mail +Vorbedingung: Signaturen/Blacklist sind gepflegt. +Fakt: MailSignatureBL verwaltet Signaturen, SignatureReplacementBL ersetzt Platzhalter (Benutzer-/Firmendaten), StringToHtmlConverter/RichEditMailMessageExporter formatieren Inhalte, DomainBlacklistBL führt gesperrte Domains; EWS-Klassen kapseln Exchange-Zugriff auf Mail und Kalender. +Aussage: Die Software soll ausgehende Mails mit personalisierten Signaturen versehen und Domains sperren können; Exchange-Postfächer und -Kalender sollen lesbar/beschreibbar angebunden sein. +Ergebnis: Einheitliche, richtlinienkonforme Mailkommunikation. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Mail/MailSignatureBL.cs, MailFormatting/SignatureReplacementBL.cs, Blacklist/DomainBlacklistBL.cs, Exchange/EwsHelper/EwsEmailAccess.cs - Begründung: implementierende Mail-Bausteine. +Prüfidee: Signatur mit Platzhalter versenden; erwartet: ersetzte Werte; Blacklist-Domain wird blockiert. +Tracelinks: SyRS-035 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Signatur-/Blacklistlogik bleibt. +Status: belegt +``` + +``` +ID: SwRS-073 +Titel: Mail-Scanner-Profile, -Workflows und -Aufgaben +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente MailScannerBL, Hintergrunddienst +Vorbedingung: Profil mit Postfachzugang existiert. +Fakt: MailScannerBL persistiert Profile (rechte-/benutzerbezogen via LoggedInUser), Workflows (SaveWorkflow mit AppUser) und Aufgabenlisten (SaveTasks); Profile sind löschbar. +Aussage: Die Software soll je Postfach Profile mit Workflows und Aufgaben konfigurieren, die eingehende Mails automatisiert verarbeiten. +Ergebnis: Konfigurierbare Posteingangsautomatisierung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/MailScanner/MailScannerBL.cs, SaveProfile/SaveWorkflow/SaveTasks - Begründung: implementierende Konfigurationslogik. +Prüfidee: Workflow ändern; erwartet: nächste Mailverarbeitung folgt neuer Regel. +Tracelinks: SyRS-036 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - siehe SyRS-036. +Status: belegt +``` + +``` +ID: SwRS-074 +Titel: Serien-Mailings mit Vorlagen, Anhängen und Übersicht +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Marketing +Vorbedingung: Mailing-Vorlage und Empfängerdaten existieren. +Fakt: MailingDataBL lädt vollständige Mailings (LoadFullMailing), speichert Mailingdaten und Anhänge (SaveAttachements) und liefert Übersichten per Filter; Vorlagen verwaltet MailingTemplateBL. +Aussage: Das System soll Serien-Mailings auf Vorlagenbasis mit Anhängen erstellen, speichern und auswerten können. +Ergebnis: Wiederholbare Marketing-Aussendungen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Mailings/MailingDataBL.cs, LoadFullMailing/SaveMailingData/SaveAttachements; MailingTemplateBL.cs - Begründung: implementierende Mailinglogik. +Prüfidee: Mailing mit Anhang speichern und vollständig laden. +Tracelinks: SyRS-035; StRS-026 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Basis-Marketing; ggf. durch Marketing-Tool ersetzbar. +Status: belegt +``` + +``` +ID: SwRS-075 +Titel: Massenpreisänderungen über Vorlagen für Artikel und Belege +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente MassUpdateBL +Vorbedingung: MassUpdate-Vorlage definiert Filter und Änderungsregel. +Fakt: StartArticlePriceUpdate und StartReceiptPriceUpdate wenden Vorlagen auf Artikel bzw. Belegpositionen an; SearchForReceiptUpdateItems ermittelt betroffene Positionen vorab; Vorlagen sind CRUD-verwaltet. +Aussage: Die Software soll Preisänderungen vorlagenbasiert massenhaft ausführen und betroffene Objekte vorab ermitteln können. +Ergebnis: Vorhersehbare Massenänderungen mit Vorschau. +Belege: + - [PRIMÄR] src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs, StartArticlePriceUpdate/StartReceiptPriceUpdate/SearchForReceiptUpdateItems - Begründung: durchsetzende Änderungslogik. +Prüfidee: Vorlage mit 5% Aufschlag auf Artikelgruppe; erwartet: Preise +5%, Vorschau zählt dieselben Artikel. +Tracelinks: SyRS-034 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Effizienzfunktion. +Status: belegt +``` + +``` +ID: SwRS-076 +Titel: Bereitstellung der Mitarbeiterliste für mobile Clients +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Mobile App +Vorbedingung: Mobile Anbindung ist lizenziert/aktiv. +Fakt: MobileBL.GetMobileEmployee liefert die Mitarbeiterliste im Mobile-Format (NewMobileEmployee). +Aussage: Das System soll mobilen Clients die erforderlichen Stammdaten (u. a. Mitarbeiter) in einem eigenen Übertragungsformat bereitstellen. +Ergebnis: Mobile Clients arbeiten mit aktuellen Mitarbeiterdaten. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Mobile/MobileBL.cs, GetMobileEmployee() - Begründung: implementierende Bereitstellung. +Prüfidee: Abruf der Mobile-Mitarbeiterliste; erwartet: aktive Mitarbeiter enthalten. +Tracelinks: SyRS-031 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - separates Mobile-Format im Zielsystem durch einheitliche API ersetzen. +Status: belegt +``` + +``` +ID: SwRS-077 +Titel: Modulkatalog mit automatischer Registrierung und Benutzerfavoriten +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System (Modulverwaltung), Benutzer +Vorbedingung: Anwendungsmodule sind im Code definiert. +Fakt: ModuleBL legt fehlende interne Module in der DB an (DoCreateMissingInternalModulesInDB), liefert den Modulkatalog und verwaltet Modul-Favoriten je Benutzer (SaveModuleFavorites, UpdateModuleFavorite per Modul-GUID). +Aussage: Die Software soll den Modulkatalog automatisch mit dem Code synchronisieren und Benutzern Favoritenmodule ermöglichen. +Ergebnis: Konsistente Modulliste; personalisierte Schnellzugriffe. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Modules/ModuleBL.cs, DoCreateMissingInternalModulesInDB/UpdateModuleFavorite - Begründung: implementierende Katalog- und Favoritenlogik. +Prüfidee: Neues Codemodul deployen; erwartet: DB-Eintrag entsteht automatisch. +Tracelinks: SyRS-031; StRS-014 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Navigationsgrundlage. +Status: belegt +``` + +``` +ID: SwRS-078 +Titel: Personalisierte Dashboards je Benutzer +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Benutzer +Vorbedingung: Dashboard-Container-Arten sind definiert. +Fakt: DashboardContainerBL registriert, lädt, aktualisiert und löscht Dashboard-Container je AppUser (moduleID/containerKindID). +Aussage: Das System soll Benutzern personalisierte Dashboards mit konfigurierbaren Containern bereitstellen. +Ergebnis: Individuelle Startseiten je Benutzer. +Belege: + - [PRIMÄR] src/backend/Centron.BL/MyCentron/Dashboard/DashboardContainerBL.cs, RegisterDashboardContainer/UpdateDashboardContainers - Begründung: implementierende Dashboardlogik. +Prüfidee: Container hinzufügen; erwartet: erscheint nur beim jeweiligen Benutzer. +Tracelinks: SyRS-029 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - personalisierte Übersichten. +Status: belegt +``` + +``` +ID: SwRS-079 +Titel: „Mein Tag": Arbeitsvorrat mit Mitarbeiterauswahl und Import +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Mitarbeiter, Teamleitung +Vorbedingung: Benutzer nutzt die MyDay-Übersicht. +Fakt: MyDayBL verwaltet WorkItems (einzeln und als Batch), benutzerbezogene Items, eine Mitarbeiterauswahl je Benutzer (GetEmployeeSelection) und einen Item-Import (ImportMyDayItems). +Aussage: Das System soll eine Tagesübersicht mit Arbeitsvorratspositionen bereitstellen, die auch Einträge anderer (ausgewählter) Mitarbeiter zeigt und Importe unterstützt. +Ergebnis: Konsolidierter Tagesarbeitsvorrat. +Belege: + - [PRIMÄR] src/backend/Centron.BL/MyDay/MyDayBL.cs, SaveWorkItemBatch/SaveOrUpdateWorkItem/GetEmployeeSelection/ImportMyDayItems - Begründung: implementierende MyDay-Logik. +Prüfidee: Mitarbeiterauswahl setzen; erwartet: deren Items erscheinen in der Übersicht. +Tracelinks: SyRS-029 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Produktivitätsfunktion. +Status: belegt +``` + +``` +ID: SwRS-080 +Titel: Web-Benachrichtigungen mit Gelesen-/Gesehen-Status +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Benutzer (Webclient) +Vorbedingung: Benachrichtigung wurde erzeugt. +Fakt: NexusNotificationsBL filtert Benachrichtigungen, markiert einzeln oder gesamt als gelesen/gesehen (MarkNexusNotificationsAsRead/AsSeen, MarkAll... je Mitarbeiter und Typ) und löscht sie; die Zustellung erfolgt über einen Hub (NotificationsHubHelper, SignalR). +Aussage: Das System soll Benutzern im Webclient Benachrichtigungen mit getrenntem Gesehen- und Gelesen-Status zustellen (Push über Hub) und Massenmarkierungen erlauben. +Ergebnis: Aktuelle, quittierbare Benachrichtigungen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/NexusNotifications/NexusNotificationsBL.cs, MarkNexusNotificationsAsRead/AsSeen, MarkAll...; NotificationsHubHelper.cs - Begründung: implementierende Zustell- und Statuslogik. +Prüfidee: Benachrichtigung erzeugen; erwartet: Push im Web, Statuswechsel bei Klick. +Tracelinks: SyRS-031; StRS-018 +Konsolidierung: Kandidat: M-070 Notifications (Client-Benachrichtigungen) - zwei Benachrichtigungssysteme +Übernahmewürdigkeit: übernehmen - Web-Benachrichtigungen sind Zielbild. +Status: belegt +``` + +``` +ID: SwRS-081 +Titel: Persönliche und globale Ticket-Ansichten im Webclient +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Support-Mitarbeiter +Vorbedingung: Ticketlisten werden im Webclient genutzt. +Fakt: NexusTicketViewBL verwaltet Ticket-Ansichten inkl. globaler Ansichten mit Namenskonfliktprüfung (GlobalViewWithSameNameExists), Nutzungsprüfung durch andere (IsGlobalViewUsedByOthers), getrennter Löschlogik und Sortierung (ReorderTicketViews). +Aussage: Das System soll persönliche und global geteilte Ticket-Ansichten mit eindeutigen Namen, geschütztem Löschen und benutzerdefinierter Reihenfolge unterstützen. +Ergebnis: Wiederverwendbare, konfliktfreie Ticketfilter. +Belege: + - [PRIMÄR] src/backend/Centron.BL/NexusTicketViews/NexusTicketViewBL.cs, GlobalViewWithSameNameExists/IsGlobalViewUsedByOthers/DeleteGlobalView/ReorderTicketViews - Begründung: durchsetzende Konsistenzregeln. +Prüfidee: Globale Ansicht mit vorhandenem Namen anlegen; erwartet: Ablehnung. +Tracelinks: SyRS-031; StRS-005 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Ansichtenverwaltung ist Web-Ziel. +Status: belegt +``` + +``` +ID: SwRS-082 +Titel: Objektbezogene Benachrichtigungsempfänger +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Benutzer +Vorbedingung: Objekt (z. B. Ticket/Beleg) existiert. +Fakt: UserNotificationBL verwaltet je Objekt (objectI3D+objectKind) die Liste zu benachrichtigender Benutzer (GetNotificationUsersFromObject, UpdateUsersFromObject). +Aussage: Das System soll je Geschäftsobjekt festlegen können, welche Benutzer über Änderungen benachrichtigt werden. +Ergebnis: Zielgerichtete Benachrichtigungen je Objekt. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Notifications/UserNotificationBL.cs, GetNotificationUsersFromObject/UpdateUsersFromObject - Begründung: implementierende Empfängerverwaltung. +Prüfidee: Benutzer als Empfänger eintragen; erwartet: erhält Benachrichtigung bei Objektänderung. +Tracelinks: SyRS-029 +Konsolidierung: Kandidat: SwRS-080 (Nexus-Benachrichtigungen) +Übernahmewürdigkeit: übernehmen - Abo-Prinzip je Objekt. +Status: belegt +``` + +``` +ID: SwRS-083 +Titel: Externe Referenzen je Geschäftsobjekt (Fremdsystem-IDs) +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Konnektoren, Komponente ObjectExternalReferenceBL +Vorbedingung: Objekt wird mit einem Fremdsystem gekoppelt. +Fakt: ObjectExternalReferenceBL speichert je Objekt beliebige externe Referenzen (Typ + ID), sucht objekt- wie referenzseitig (FindByExternalReference) und aktualisiert Referenzen. +Aussage: Die Software soll je Geschäftsobjekt mehrere typisierte Fremdsystem-Referenzen führen und Objekte über Fremd-IDs auffindbar machen. +Ergebnis: Bidirektionale Kopplung zu Drittsystemen ohne Schemaänderung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs, CreateReference/FindByExternalReference/GetReferencesForObjectByType - Begründung: implementierende Referenzverwaltung. +Prüfidee: Referenz (Typ "DocBee", ID X) anlegen; erwartet: Objekt über X auffindbar. +Tracelinks: SyRS-027 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Integrationsgrundlage. +Status: belegt +``` + +``` +ID: SwRS-084 +Titel: Asset-Suche aus Outlook (Kundenerkennung über Gerätenummer) +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Outlook-Add-In +Vorbedingung: Asset-/Gerätenummer liegt vor (z. B. aus Mailtext). +Fakt: OutlookAssetKindSearchBL.SearchCustomersWithAssetManagementEntrys findet Kunden anhand einer Asset-Nummer. +Aussage: Das System soll aus Outlook heraus Kunden über Asset-Nummern identifizieren können. +Ergebnis: Schnelle Kundenzuordnung im Mailkontext. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Outlook/OutlookAssetKindSearchBL.cs, SearchCustomersWithAssetManagementEntrys(int) - Begründung: implementierende Suche. +Prüfidee: Suche mit bekannter Assetnummer; erwartet: zugehöriger Kunde. +Tracelinks: SyRS-031; StRS-022 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Add-In-Nutzen. +Status: belegt +``` + +``` +ID: SwRS-085 +Titel: Kundenzugangsdaten-Verwaltung mit Zugriffs- und Änderungsprotokoll +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Techniker, Komponente PasswordManagementBL +Vorbedingung: Zugangsdaten eines Kundensystems werden verwaltet. +Fakt: PasswordManagementBL speichert Zugangsdaten je Kunde/Asset (AddNewPassword, ChangePassword mit AppUser), listet sie je Kunde/Asset; flankierend existieren Zugriffslog (PasswordManagementAccessLogBL), Änderungslog (PasswordManagementLogBL), Typen und Schlagworte. +Aussage: Das System soll Zugangsdaten von Kundensystemen strukturiert (je Kunde/Asset) verwalten und jeden Zugriff sowie jede Änderung protokollieren. +Ergebnis: Nachvollziehbarer Umgang mit Fremdzugangsdaten. +Belege: + - [PRIMÄR] src/backend/Centron.BL/PasswordManagementArea/PasswordManagementBL.cs, AddNewPassword/ChangePassword/GetPasswordList; PasswordManagementAccessLogBL.cs, PasswordManagementLogBL.cs - Begründung: implementierende Verwaltungs- und Protokollkomponenten. +Prüfidee: Passwort abrufen; erwartet: AccessLog-Eintrag mit Benutzer/Zeit. +Tracelinks: SyRS-017; StRS-028 +Konsolidierung: Kandidat: M-074 PasswordManager (zweites Passwortmodul mit Siegel/Guidelines) +Übernahmewürdigkeit: übernehmen - MSP-Kernfunktion mit Auditpflicht. +Status: belegt +``` + +``` +ID: SwRS-086 +Titel: Passwortmanager mit Kundenrechten, Siegeln und Richtlinien +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Techniker, Komponente PasswordManagerBL +Vorbedingung: Passwortmanager-Modul ist im Einsatz. +Fakt: PasswordManagerBL verwaltet Logs, kunden-/mitarbeiterbezogene Zugriffsrechte (GetPasswordManagerCustomersEmployeesRights), Versiegelungsinformationen je Wert (PropertyValueSealInformation) und Passwort-Richtlinien (Guidelines). +Aussage: Das System soll Passwortzugriffe kunden- und mitarbeitergenau berechtigen, Werte versiegeln (Öffnung nachweisbar) und Passwortrichtlinien verwalten. +Ergebnis: Feingranular geschützte, auditierbare Passwörter. +Belege: + - [PRIMÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, GetPasswordManagerCustomersEmployeesRights/GetPasswordManagerPropertyValueSealInformations/GetPasswordManagerGuidelines/SavePasswordManagerLog - Begründung: implementierende Schutz- und Auditlogik. +Prüfidee: Versiegelten Wert öffnen; erwartet: Siegelbruch protokolliert. +Tracelinks: SyRS-017; StRS-028 +Konsolidierung: Kandidat: SwRS-085 (zwei Passwortverwaltungen) - im Zielsystem ein Modul +Übernahmewürdigkeit: übernehmen - modernere der beiden Implementierungen als fachliche Basis. +Status: belegt +``` + +``` +ID: SwRS-087 +Titel: Objektbezogene Prozesse mit Schritten und Bindungen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente ProcessBL +Vorbedingung: Prozessdefinition existiert (ggf. objektbezogen). +Fakt: ProcessBL verwaltet Prozesse generisch (ProcessDTO) mit Schritten und Bindungen, objektbezogen (objectI3D/objectKind) sowie speziell für den MailScanner (GetProcessesForMailScanner). +Aussage: Die Software soll wiederverwendbare Prozessdefinitionen (Schritte, Bindungen) je Objektart verwalten, die u. a. der Mail-Scanner ausführt. +Ergebnis: Konfigurierbare Abläufe ohne Codeänderung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Processes/ProcessBL.cs, GetProcesses/SaveProcess/GetProcessesForMailScanner - Begründung: implementierende Prozessverwaltung. +Prüfidee: Prozess mit zwei Schritten speichern und vollständig laden. +Tracelinks: SyRS-036; StRS-031 +Konsolidierung: Kandidat: Services/Workflows (zweite Prozess-/Workflow-Engine) +Übernahmewürdigkeit: übernehmen - Prozesskonfiguration; Engines konsolidieren. +Status: belegt +``` + +``` +ID: SwRS-088 +Titel: Produktmatrix: Kategorien, Produkte und Kundenbewertungen mit Änderungslog +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: Produktmatrix-Kategorien und Produkte sind definiert. +Fakt: ProductMatrixBL verwaltet Kategorien, Produkte und kundenbezogene Ratings inkl. ChangeLog (CustomerProductMatrixRatingChangeLog). +Aussage: Das System soll je Kunde bewerten können, welche Produkte/Themen relevant sind (Produktmatrix), und Bewertungsänderungen protokollieren. +Ergebnis: Cross-Selling-Übersicht je Kunde mit Historie. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ProductMatrix/ProductMatrixBL.cs, SaveOrUpdateProductMatrixCategories/GetCustomerProductMatrixRatingChangeLogByI3D - Begründung: implementierende Matrix- und Loglogik. +Prüfidee: Rating ändern; erwartet: ChangeLog-Eintrag. +Tracelinks: SyRS-020; StRS-025 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Vertriebssteuerung. +Status: belegt +``` + +``` +ID: SwRS-089 +Titel: Fertigungsaufträge mit Positionen und Fertigungsprotokoll +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Produktion +Vorbedingung: Fertigungsauftrag existiert. +Fakt: ProductionOrderBL liefert Fertigungsaufträge, Positionen und Logs per Filter und speichert Fertigungsprotokolle (SaveProductionOrderLog). +Aussage: Das System soll Fertigungsaufträge (z. B. PC-Assemblierung) mit Positionen führen und Fertigungsschritte protokollieren. +Ergebnis: Nachvollziehbarer Fertigungsfortschritt. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs, GetProductionOrdersByFilter/GetProductionOrderItemsByFilter/SaveProductionOrderLog - Begründung: implementierende Fertigungslogik. +Prüfidee: Logeintrag zu Auftrag schreiben; erwartet: im Filterabruf enthalten. +Tracelinks: SyRS-013; StRS-024 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - sofern Fertigung im Zielmarkt bleibt (Nexus enthält eigenes ProductionOrderManagement). +Status: belegt +``` + +``` +ID: SwRS-090 +Titel: Projektliste mit Stichtagsfilter +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Projektleitung +Vorbedingung: Projekte sind angelegt. +Fakt: ProjectBL liefert die Projektliste, optional ab Stichtag (GetProjectList(DateTime?)). +Aussage: Das System soll Projekte als Stammobjekte führen und zeitlich gefiltert bereitstellen. +Ergebnis: Projektbezug für Belege/Tickets (ReceiptBL.UpdateReceiptProjectNumber existiert). +Belege: + - [PRIMÄR] src/backend/Centron.BL/Projects/ProjectBL.cs, GetProjectList(DateTime?) - Begründung: implementierende Bereitstellung. +Prüfidee: Projekt mit Startdatum nach Stichtag; erwartet: im gefilterten Abruf enthalten. +Tracelinks: SyRS-020; StRS-025 +Konsolidierung: Kandidat: Sales/Customers/CrmProjects und TicketProjects - drei Projektbegriffe abgrenzen/zusammenführen +Übernahmewürdigkeit: übernehmen - Projektbezug ist verbreitet. +Status: belegt +``` + +``` +ID: SwRS-091 +Titel: Bestellvorschlagsermittlung aus mehreren Quellen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkauf, Komponente OrderSuggestionListBL +Vorbedingung: Artikel-/Auftrags-/Lagerdaten vorhanden; Benutzer berechtigt. +Fakt: OrderSuggestionListBL ermittelt Bestellvorschläge artikelbasiert (GetOrderSuggestionArticle), auftragsbasiert (GetOrderSuggestionOrder), lagerbasiert (GetOrderSuggestionWH) sowie aus freien Vereinbarungen (GetFreeSpecAgreement, GetFreeArticlePerWH), jeweils mit AppUser-Kontext und Filtern. +Aussage: Das System soll Bestellvorschläge aus Mindestbeständen, offenen Aufträgen und Lagerbedarf ermitteln und dem Einkäufer zur Umsetzung anbieten. +Ergebnis: Bedarfsgerechte Lieferantenbestellungen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs, GetOrderSuggestionArticle/GetOrderSuggestionOrder/GetOrderSuggestionWH - Begründung: implementierende Vorschlagslogik. +Prüfidee: Artikel unter Mindestbestand; erwartet: erscheint im Vorschlag mit Bedarfsmenge. +Tracelinks: SyRS-027; StRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - dispositive Kernfunktion. +Status: belegt +``` + +``` +ID: SwRS-092 +Titel: Kaufmännische Datumsarithmetik der Vertragsintervalle +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Komponente ContractBL +Vorbedingung: Abrechnungs- oder Laufzeitfortschreibung eines Vertrags. +Fakt: GetNewMonthDate behandelt Monatsenden explizit: Startet ein Zeitraum am letzten Monatstag, endet der Folgezeitraum ebenfalls am Monatsende; Sondertage (29./30./31. sowie Februar-Endtage) werden per Offset auf den Monatsletzten gerechnet; GetMonthDuration übersetzt Intervallarten in Monate (Monthly=n, Quarterly=n*3, Yearly=n*12); Tagesintervalle rechnen AddDays(duration-1). +Aussage: Die Software soll Vertragszeiträume kaufmännisch korrekt fortschreiben, insbesondere bei Monatsenden und Schaltjahren, sodass keine Abrechnungslücken oder Überlappungen entstehen. +Ergebnis: 31.01. + 1 Monat = 28./29.02.; lückenlose Perioden. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, GetNewMonthDate/GetMonthDuration/GetNewDate (Zeile 1017-1062) - Begründung: durchsetzende Datumslogik. +Prüfidee: Vertrag mit Start 31.01. monatlich; erwartet: Folgeperioden 28./29.02., 31.03., 30.04. +Tracelinks: SyRS-037 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - fachlich zwingende Regel. +Status: belegt +``` + +``` +ID: SwRS-093 +Titel: Automatisches Schließen nur vollständig abgerechneter, abgelaufener Verträge +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Hintergrundprozess (CloseContract) +Vorbedingung: Einstellung AutomaticallyCloseExpiredContracts ist aktiv. +Fakt: CloseContract schließt aktive Auto-Verträge nur, wenn LastBookingTo das Vertragsende bzw. Kündigungsdatum erreicht hat UND das Referenzdatum danach liegt; bei automatischer Verlängerung gilt das Kündigungsdatum, sonst das Vertragsende; das Schließen läuft als Systembenutzer und speichert über SaveReceipt mit IgnoreCallbacks. +Aussage: Die Software soll abgelaufene Verträge erst dann automatisch abschließen, wenn sie bis zum Ende vollständig abgerechnet sind; nicht fertig abgerechnete Verträge bleiben offen. +Ergebnis: Kein Umsatzverlust durch vorzeitiges Schließen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, CloseContract(DateTime?) (Zeile 1243ff): Bedingungen LastBookingTo >= ContractTermination/ContractEnd und referenceDate-Vergleich - Begründung: durchsetzende Abschlussbedingungen. +Prüfidee: Abgelaufener Vertrag mit offener Restperiode; erwartet: bleibt aktiv; nach Abrechnung der Restperiode: wird geschlossen. +Tracelinks: SyRS-037, SyRS-038 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - schützt die Abrechnungsvollständigkeit. +Status: belegt +``` + +``` +ID: SwRS-094 +Titel: Ermittlung abrechnungsfälliger Kunden und Zählerstandsverwaltung +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Komponente AutomaticFacturaBL +Vorbedingung: Abrechnungslauf wird vorbereitet. +Fakt: SearchCustomers(BilledTo) liefert Kunden mit fälligen Verträgen; Zählerstände werden je Vertrag/Gerät gespeichert und deaktivierbar geführt (StoreCounterState/DeactivateCounterState), Geräte ohne Zähler sind identifizierbar (GetDeviceIDsWithoutCounter), Zähler sind über Barcodes auffindbar (GetCounterToBarcode); Sonderartikel-zu-Vertrag-Zuordnungen entstehen auch aus MSP-Auswertungen (CreateSpecialArticleToContractFromMspEvaluation). +Aussage: Die Software soll fällige Abrechnungskunden stichtagsbezogen ermitteln und nutzungsabhängige Abrechnungsgrundlagen (Zählerstände, MSP-Verbräuche) je Vertrag verwalten. +Ergebnis: Vollständige Datengrundlage je Abrechnungslauf. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs, SearchCustomers/CreateSpecialArticleToContractFromMspEvaluation; AutomaticFacturaBL.Contracts.cs, StoreCounterState/GetDeviceIDsWithoutCounter/GetCounterToBarcode - Begründung: implementierende Ermittlungslogik. +Prüfidee: Vertrag mit BilledTo vor Stichtag; erwartet: Kunde in Suchergebnis; Gerät ohne Zähler wird gemeldet. +Tracelinks: SyRS-038 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kernfunktion Managed Print/MSP. +Status: belegt +``` + +``` +ID: SwRS-095 +Titel: Timer-Abrechnung: Statusführung und Belegerzeugung aus Ticketzeiten +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Komponente TimerBillingBL/ReceiptBL +Vorbedingung: Abrechenbare Timer sind ausgewählt. +Fakt: TimerBillingBL pflegt Abrechnungsstatus (HelpdeskTimerBillingState CRUD), löst Artikel- und Vertragszuordnungen je Kunde auf (GetArticleWorkItems/GetContracts inkl. Pflichtverträgen) und filtert Timer (SearchTimers); ReceiptBL.CreateNewReceiptForHelpdekTimers erzeugt aus Timer-I3Ds den Abrechnungsbeleg gemäß TimerBillingSettingsDTO. +Aussage: Die Software soll Ticketzeiten über Statuswerte als abrechenbar/abgerechnet steuern und ausgewählte Zeiten in einen Beleg mit korrekten Artikeln/Verträgen überführen. +Ergebnis: Zeiten werden genau einmal, vertragskonform fakturiert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs, GetTimerBillingStates/SearchTimers/SaveTimer/UpdateOrderItems; src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateNewReceiptForHelpdekTimers (Zeile 5295) - Begründung: durchsetzende Abrechnungskette. +Prüfidee: Timer abrechnen, zweiten Lauf starten; erwartet: bereits abgerechneter Timer erscheint nicht erneut. +Tracelinks: SyRS-039 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Umsatzrelevanter Kern. +Status: belegt +``` + +``` +ID: SwRS-096 +Titel: Operationsgenaue Rechteprüfung beim Ticket-Speichern +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Komponente HelpdeskBL +Vorbedingung: Ticket wird angelegt oder geändert. +Fakt: CheckUserRigths verweigert: Neuanlage ohne ADD_NEW_HELPDESK, Bearbeitung ohne EDIT_HELPDESK, Setzen des Abschlussstatus ohne CLOSE_REQUEST, Fälligkeitsänderung ohne MATURITY_CHANGE (Dirty-Check IsDueDateChanged), Verantwortlichenwechsel außerhalb eigener Abteilungen bei ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS; Web-Accounts durchlaufen CheckWebRights; ohne Abschlussstatus wird ClosedAt genullt. +Aussage: Die Software soll jede Ticket-Änderung feldbezogen gegen die Helpdesk-Rechte prüfen und Verstöße mit spezifischen Fehlermeldungen ablehnen. +Ergebnis: Rechtekonforme Ticketpflege; deutsche Fehlermeldungen je Verstoß. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, CheckUserRigths(Helpdesk,AppUser,bool) (Zeile 418-466) - Begründung: durchsetzende Prüfkaskade. +Prüfidee: Fälligkeit ohne MATURITY_CHANGE ändern; erwartet: "Kein Recht für Fälligkeitsdatum ändern vorhanden." +Tracelinks: SyRS-040, SyRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - bewährtes Rechtemodell. +Status: belegt +``` + +``` +ID: SwRS-097 +Titel: Restriktive Ticket-Sichtbarkeit (nur eigene / eigene Filiale) +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Komponente HelpdeskBL +Vorbedingung: Benutzer besitzt ein restriktives Sichtbarkeitsrecht. +Fakt: Beim Laden von Tickets werden die Rechte SHOW_HELPDESK_ONLY_OWN und SHOW_HELPDESK_ONLY_OWN_BRANCH abgefragt und der Ticketfilter entsprechend eingeschränkt (Zeile 272-284). +Aussage: Die Software soll bei gesetztem restriktivem Recht nur Tickets zeigen, bei denen der Benutzer Bearbeiter/Verantwortlicher ist bzw. die zur eigenen Filiale gehören. +Ergebnis: Einschränkende Rechte wirken als Filter, nicht nur als UI-Ausblendung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Abfrage der Rechte SHOW_HELPDESK_ONLY_OWN/_ONLY_OWN_BRANCH mit Filteranwendung (Zeile 272-284) - Begründung: durchsetzende serverseitige Einschränkung. + - [KONTEXT] CentronRights.md, "restricting right"-Definitionen - Begründung: dokumentierte Semantik. +Prüfidee: Benutzer mit ONLY_OWN fragt fremdes Ticket per ID ab; erwartet: kein Zugriff. +Tracelinks: SyRS-040 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Datenschutz im Support. +Status: belegt +``` + +``` +ID: SwRS-098 +Titel: Eskalationslauf mit Stufenterminen und Testmodus +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente EscalationBL +Vorbedingung: Eskalationsregeln je Typ existieren. +Fakt: DoEscalation selektiert per SQL Vorgänge mit Terminen und den Stufenfeldern Eskalation1Am/2Am/3Am, filterbar nach Eskalations-ID/-Typ; TestEscalation führt den Lauf mit vorgegebenem Datum aus; Empfängerkreise sind als Enum definiert (EscalationReceiversEnum). +Aussage: Die Software soll Eskalationsläufe stufenweise ausführen, je Stufe den Ausführungszeitpunkt persistieren und Läufe mit simuliertem Datum testbar machen. +Ergebnis: Deterministische, prüfbare Eskalationen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs, DoEscalation/TestEscalation, SQL Zeile 68ff - Begründung: durchsetzende Lauf- und Stufenlogik. +Prüfidee: TestEscalation mit Datum+3 Stufenfristen; erwartet: alle drei Stufen nacheinander gesetzt. +Tracelinks: SyRS-041 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - SLA-Automatik. +Status: belegt +``` + +``` +ID: SwRS-099 +Titel: Ticketabschluss mit Kunden-/Teambenachrichtigung und Zeitbericht +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente HelpdeskCloseBL +Vorbedingung: Ticket ist abschlussberechtigt (CLOSE_REQUEST). +Fakt: CloseHelpdesk schließt Tickets (auch als Liste); CloseHelpdeskWithNotification/CloseTicketWithNotification versenden konfigurierbare interne/externe Mails inkl. Anhängen, Helpdesk-Report (GetHelpdeskReport über Reportgruppe HELPDESK_MAIL_EXTERN) und ausgewählten Timern; externe Signatur kommt aus den Einstellungen (HelpdeskExternalSignature). +Aussage: Die Software soll beim Ticketabschluss optional Kunde und Team benachrichtigen und dabei einen Abschlussbericht mit den erbrachten Zeiten beilegen. +Ergebnis: Dokumentierter Abschluss mit Kundeninformation. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs, CloseHelpdeskWithNotification/CloseTicketWithNotification (Zeile 200ff, 367ff) - Begründung: durchsetzende Abschluss- und Benachrichtigungslogik. +Prüfidee: Abschluss mit externer Benachrichtigung; erwartet: Mail mit Report-PDF und Timerliste. +Tracelinks: SyRS-040, SyRS-025 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kundenkommunikation im Support. +Status: belegt +``` + +``` +ID: SwRS-100 +Titel: Kassenbuchbuchung: MwSt-Split, Pflicht-Belegarten, Schreibschutz +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Komponente CashBookBookingBL +Vorbedingung: Barbeleg mit ChangesCashBook-Zahlungskondition wird gespeichert. +Fakt: UpdateCashBookBookingFromAsset splittet den Bruttobetrag je Mehrwertsteuersatz, verlangt je Satz einen konfigurierten CashBookRecord (sonst Fehlermeldung mit Steuersatz), erzeugt Buchungen mit ReadOnly=true, bucht Gutschriften als Credit und andere Belege als Debit, übernimmt Steuerschlüssel/Sachkonto aus dem CashBookRecord und wählt die Filiale gemäß Einstellung CreateCashBookBookingAtCurrentUserBranch. +Aussage: Die Software soll Kassenbuchungen automatisch je Steuersatz getrennt, unveränderlich und mit korrekter Konten-/Steuerschlüsselzuordnung erzeugen; fehlende Kassen-Belegarten müssen den Vorgang mit klarer Fehlermeldung stoppen. +Ergebnis: GoBD-taugliche Kassenbuchungen ohne manuelle Nacharbeit. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CashBooks/CashBookBookingBL.cs, UpdateCashBookBookingFromAsset (Zeile 33ff) - Begründung: vollständige durchsetzende Buchungslogik. +Prüfidee: Barrechnung mit zwei Steuersätzen, ein CashBookRecord fehlt; erwartet: Fehler "Kassenbuch Buchung kann nicht erstellt werden ...". +Tracelinks: SyRS-042 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Compliance-Kern. +Status: belegt +``` + +``` +ID: SwRS-101 +Titel: Validierung von Riverbird-Tickets und RMM-Zugriffsschlüsseln +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Riverbird-Webservice, Komponente RiverDivoBL +Vorbedingung: Riverbird ruft den c-entron-Webservice auf. +Fakt: RiverDivoBL validiert eingehende River-Tickets und RMM-Access-Keys (ValidateRiverTicket, ValidateRmmAccessKey, kombinierte Prüfung) bevor Daten bereitgestellt werden; die Klasse ist laut Kommentar die Gegenstelle der Riverbird-Webservice-Aufrufe. +Aussage: Die Software soll Aufrufe des Riverbird-Systems nur nach erfolgreicher Ticket- bzw. Zugriffsschlüsselprüfung beantworten. +Ergebnis: Kein unauthentifizierter Fremdzugriff über die Riverbird-Schnittstelle. +Belege: + - [PRIMÄR] src/backend/Centron.BL/RiverDivo/RiverDivoBL.cs, ValidateRiverTicket/ValidateRmmAccessKey/ValidateRiverTicketOrRmmAccessKey (Zeile 60-114) - Begründung: durchsetzende Zugriffsprüfungen. +Prüfidee: Aufruf mit ungültigem Ticket; erwartet: Ablehnung (false). +Tracelinks: SyRS-017, SyRS-027 +Konsolidierung: nein +Übernahmewürdigkeit: Sonderfall - produktspezifische Kopplung (Riverbird); im Zielsystem über Standard-API-Auth abbilden. +Status: belegt +``` + +``` +ID: SwRS-102 +Titel: Kundensuche und Kompakt-Kundendaten für alle Module +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Module, Komponente CustomerBL +Vorbedingung: Kundenstamm existiert. +Fakt: CustomerBL bietet Textsuche (auch eingeschränkt auf Kunden mit offenen Rahmenaufträgen), Kompaktdaten je ID-Liste, aktive Kunden je Benutzer und Kunden mit Webcart-Lizenz (GetCustomersWithWebcartLicense). +Aussage: Die Software soll eine performante Kundensuche mit Kompakt-Datensätzen bereitstellen, gefiltert u. a. nach offenen Rahmenaufträgen und Webshop-Berechtigung. +Ergebnis: Einheitliche Kundenauswahl in allen Masken. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Customers/CustomerBL.cs, SearchCustomerBySearchText/SearchCustomersWithBlanketOrdersBySearchText/GetCustomersWithWebcartLicense - Begründung: implementierende Suchlogik. +Prüfidee: Suche nach Namensfragment; erwartet: Kompakttreffer; Webcart-Filter liefert nur lizenzierte Kunden. +Tracelinks: SyRS-020 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Basisfunktion. +Status: belegt +``` + +``` +ID: SwRS-103 +Titel: Telemarketing-Aktionen mit Vorlagen und Referenzen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertrieb/Marketing +Vorbedingung: Telemarketing-Kampagne ist geplant. +Fakt: TelemarketingBL (DBBaseBL) speichert Telemarketing-Vorgänge rechte-/benutzerbezogen; Aktionen, Aktionsvorlagen und Referenzen haben eigene BLs (TelemarketingActionBL, TelemarketingActionTemplateBL, TelemarketingReferenceBL). +Aussage: Das System soll Telefonmarketing-Vorgänge mit Aktionen, wiederverwendbaren Aktionsvorlagen und Objektreferenzen verwalten. +Ergebnis: Strukturierte Anrufkampagnen mit Historie. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Marketing/TelemarketingBL.cs, SaveTelemarketing/GetTelemarketings; TelemarketingActionTemplateBL.cs - Begründung: implementierende Kampagnenlogik. +Prüfidee: Aktion aus Vorlage anlegen; erwartet: Vorgang mit Aktionshistorie. +Tracelinks: SyRS-020; StRS-026 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - CRM-Funktion. +Status: belegt +``` + +``` +ID: SwRS-104 +Titel: Terminverwaltung (Schedule) mit Personenzuordnung und Kalendersicht +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Mitarbeiter +Vorbedingung: Termine existieren. +Fakt: ScheduleBL (DBBaseBL, optional mit GraphServiceClient) liefert Termine je Mitarbeiter/Zeitraum/Objekt, verwaltet Terminpersonen (SchedulePerson) und stellt Kalender- und Übersichtsabfragen bereit (GetCalendar, GetScheduleOverview mit LoggedInUser). +Aussage: Das System soll Termine mit Objekt- und Personenbezug führen und als Kalender bzw. Übersicht bereitstellen; eine Microsoft-Graph-Anbindung ist vorgesehen. +Ergebnis: Objektbezogene Terminplanung (z. B. Ticket-/Kundentermine). +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Calendar/ScheduleBL.cs, GetSchedules/GetCalendar/GetScheduleOverview/SaveOrUpdateSchedulePerson - Begründung: implementierende Terminlogik. +Prüfidee: Termin mit Objektbezug anlegen; erwartet: erscheint in Kalenderfilter des Mitarbeiters. +Tracelinks: SyRS-029 +Konsolidierung: Kandidat: M-033 Calendar (Einstellungen) und Exchange-Kalenderzugriff (EwsCalendarAccess) - Terminwelt konsolidieren +Übernahmewürdigkeit: übernehmen - Kernorganisation. +Status: belegt +``` + +``` +ID: SwRS-105 +Titel: Dokumentationsassistent für Kundeninfrastruktur +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Techniker +Vorbedingung: Kundeninfrastruktur soll dokumentiert werden. +Fakt: Der DocumentationWizardArea-Bereich enthält BLs für Active Directory, Backup&Restore, Kundeninformationen und Maschinen (ActiveDirectoryBL, BackupAndRestoreBL, CustomerInformationBL, MachineBL). +Aussage: Das System soll die IT-Infrastruktur eines Kunden assistentengestützt in Kategorien (AD, Backup, Maschinen, Allgemeines) dokumentieren. +Ergebnis: Strukturierte Infrastrukturdokumentation je Kunde. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/DocumentationWizardArea/ActiveDirectoryBL.cs, BackupAndRestoreBL.cs, MachineBL.cs, CustomerInformationBL.cs - Begründung: implementierende Kategorien-BLs. +Prüfidee: Maschine dokumentieren; erwartet: Datensatz im Maschinenbereich des Kunden. +Tracelinks: SyRS-026; StRS-020 +Konsolidierung: Kandidat: M-047 DocumentationArea - zwei Dokumentationsmechanismen +Übernahmewürdigkeit: übernehmen - MSP-Dokupflicht. +Status: belegt +``` + +``` +ID: SwRS-106 +Titel: Stundenzuschlagssätze mit Einstellungen, Alternativtexten und Log +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Serviceabrechnung +Vorbedingung: Zuschlagssätze sind gepflegt. +Fakt: HourlySurchargeRatesBL verwaltet Zuschlagssätze inkl. Einstellungen, variablenbasierten Alternativ-Artikeltexten (TextVariableWithReplacementStrategy) und Änderungslog (HourlySurchargeRateLog); Belege referenzieren den Satz (ReceiptBL.UpdateReceiptHourlySurchargeRateI3D). +Aussage: Das System soll Stundenzuschlagssätze (z. B. Notdienst, Wochenende) mit protokollierten Änderungen verwalten und Belegen zuordnen. +Ergebnis: Zuschläge fließen nachvollziehbar in die Leistungsabrechnung ein. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/HourlySurchargeRatesBL/HourlySurchargeRatesBL.cs, SaveHourlySurchargeRateSettings/GetHourlySurchargeRateLogs; ReceiptBL.UpdateReceiptHourlySurchargeRateI3D (Zeile 5106) - Begründung: implementierende Satz- und Zuordnungslogik. +Prüfidee: Satz ändern; erwartet: Logeintrag; Beleg übernimmt neuen Satz. +Tracelinks: SyRS-039 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Abrechnungsrelevanz. +Status: belegt +``` + +``` +ID: SwRS-107 +Titel: Digitale PDF-Signatur mit zentral verwaltetem Zertifikat +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Komponente PdfSigningBL +Vorbedingung: Signaturzertifikat ist hinterlegt und Funktion verfügbar (IsPdfSigningAvailable). +Fakt: PdfSigningBL verwaltet Signatureinstellungen inkl. Zertifikat (SavePdfSigningSettings mit resetCertificate/certificate) und signiert PDF-Dokumente (SignPdfDocument(byte[])). +Aussage: Die Software soll PDF-Dokumente (z. B. Ausgangsrechnungen) mit einem zentral hinterlegten Zertifikat digital signieren können. +Ergebnis: Signierte, integritätsgesicherte PDFs. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs, SavePdfSigningSettings/SignPdfDocument/IsPdfSigningAvailable - Begründung: durchsetzende Signaturlogik. +Prüfidee: PDF signieren und Signatur mit Reader prüfen. +Tracelinks: SyRS-025; StRS-020 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Vertrauensanker für E-Dokumente. +Status: belegt +``` + +``` +ID: SwRS-108 +Titel: SelfCare-Formulare für Endkundenanfragen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Endkunde (Web), Administrator +Vorbedingung: SelfCare-Formulare sind definiert. +Fakt: SelfCareBL verwaltet SelfCareForms (CRUD, Filter); WebRequestPageBL bedient Web-Anfrageseiten. +Aussage: Das System soll konfigurierbare Web-Formulare bereitstellen, über die Endkunden Anfragen einreichen. +Ergebnis: Strukturierte Endkundenanfragen ohne Telefon/Mail. +Belege: + - [PRIMÄR] src/backend/Centron.BL/SelfCare/SelfCareBL.cs, SaveOrUpdateSelfCareForm/GetSelfCareFormsByFilter; WebRequestPageBL.cs - Begründung: implementierende Formularverwaltung. +Prüfidee: Formular anlegen und über Webseite abrufen. +Tracelinks: SyRS-031; StRS-019 +Konsolidierung: Kandidat: WebSuite WebHDQuestionBL (Webformular-Fragen) - Überschneidung prüfen +Übernahmewürdigkeit: übernehmen - Self-Service ist Zielbild. +Status: belegt +``` + +``` +ID: SwRS-109 +Titel: Grafische Workflow-Prozesse je Mitarbeiter +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Komponente WorkflowProcessBL +Vorbedingung: Workflow-Definitionen existieren. +Fakt: WorkflowProcessBL verwaltet WorkflowProcesses benutzerbezogen (GetWorkflowProcesses(EmployeeCompact, Filter)); Shapes und Bindungen haben eigene BLs (WorkflowShapeBL, WorkflowShapeBindingBL, WorkflowSettingBL). +Aussage: Das System soll grafisch modellierte Workflows (Formen, Verbindungen) speichern und je Mitarbeiter bereitstellen. +Ergebnis: Konfigurierbare Abläufe mit visueller Definition. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Services/Workflows/WorkflowProcessBL.cs, SaveWorkflowProcess/GetWorkflowProcesses; WorkflowShapeBL.cs, WorkflowShapeBindingBL.cs - Begründung: implementierende Workflowverwaltung. +Prüfidee: Workflow mit zwei Shapes speichern und vollständig laden. +Tracelinks: SyRS-036; StRS-031 +Konsolidierung: Kandidat: SwRS-087 (Processes) - zwei Prozess-Engines +Übernahmewürdigkeit: übernehmen - Automatisierung; Engines zusammenführen. +Status: belegt +``` + +``` +ID: SwRS-110 +Titel: Internes Social-Media-Modul (Kommentare, Likes, Feed) +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Mitarbeiter +Vorbedingung: Social-Media-Aktionen existieren. +Fakt: SocialMediaBL erlaubt Kommentare und Likes auf Aktionen/Streams und liefert einen Feed mit Mitarbeiterinteraktionen; PersonSocialNetworkBL/SocialNetworkBL verwalten Social-Media-Profile von Personen. +Aussage: Das System soll interne Feeds mit Kommentaren/Likes sowie Social-Media-Profile von Kontakten verwalten. +Ergebnis: Interaktion und Profildaten im CRM. +Belege: + - [PRIMÄR] src/backend/Centron.BL/SocialMedia/SocialMediaBL.cs, AddCommentToASocialMediaAction/LikeAStreamOrAction/GetSocialMediaFeedWithEmployeeInteraction - Begründung: implementierende Feedlogik. +Prüfidee: Kommentar und Like setzen; erwartet: im Feed sichtbar. +Tracelinks: SyRS-029 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - interner Social-Feed hat geringe Nutzung zu erwarten; fachlich prüfen und ggf. nicht migrieren. +Status: belegt +``` + +``` +ID: SwRS-111 +Titel: Anwendungsstart: Mapping-Vorladen und Verbindungswahl +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Performance-Effizienz (Zeitverhalten) +Akteur: Client-Start +Vorbedingung: Anwendung startet. +Fakt: StartBL.StartLoadMapping lädt die NHibernate-Mappings vor; SetConnectionString setzt die Zielverbindung. +Aussage: Die Software soll beim Start die ORM-Konfiguration vorladen, um erste Zugriffe zu beschleunigen, und die Datenbankverbindung dynamisch setzen können. +Ergebnis: Kürzere gefühlte Startzeit; wählbare Verbindung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Start/StartBL.cs, StartLoadMapping/SetConnectionString - Begründung: implementierende Startlogik. +Prüfidee: Start mit/ohne Vorladen vergleichen; erwartet: schnellerer Erstzugriff. +Tracelinks: SyRS-010 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - Client-seitiges ORM entfällt im Web-Zielsystem. +Status: belegt +``` + +``` +ID: SwRS-112 +Titel: Inventur mit Zuständen und transaktionaler Klammer +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lager, Komponente InventorysBL +Vorbedingung: Inventur wird durchgeführt. +Fakt: InventorysBL (Storage/StorageBL.cs) initialisiert Inventuren mit Zuständen und Typ (init(inventoryStates, inventoryType)) und steuert Transaktionen explizit (StartTransaction/Commit/Rollback); InventoryArticlePool hält die Zählmengen; Rechtekonstanten für Inventur existieren (RIGHT_INVABSCHLIESSEN, RIGHT_INVVERWERFEN u. a.). +Aussage: Das System soll Inventuren mit definierten Zuständen (z. B. erfasst, abgeschlossen, verworfen) transaktionssicher durchführen; Abschluss und Verwerfen sind eigene Rechte. +Ergebnis: Konsistente Bestandsaufnahme mit Berechtigungsschutz. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Storage/StorageBL.cs (InventorysBL), init/StartTransaction/CommitTransaction; Storage/InventoryArticlePool.cs - Begründung: implementierende Inventurlogik. + - [SEKUNDÄR] UserRightsConst.cs, RIGHT_INVABSCHLIESSEN=20400042, RIGHT_INVVERWERFEN=20400041 - Begründung: Rechtekonstanten der Inventur. +Prüfidee: Inventur abschließen ohne Recht; erwartet: Ablehnung. +Tracelinks: SyRS-013; StRS-008 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - gesetzlich erforderlich. +Status: belegt +``` + +``` +ID: SwRS-113 +Titel: Zentrale I3D-Systemtabelle +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Persistenzschicht +Vorbedingung: Schlüsselvergabe benötigt Systemtabelle. +Fakt: SystemTableI3DBL liefert den (einzigen) SystemTableI3D-Datensatz; das System vergibt Objektschlüssel (I3D) zentral (Kommentar in BaseBL: "Gets the next id from Entity, because in Database identityfields are missing"). +Aussage: Die Software soll Objektschlüssel zentral über eine Systemtabelle vergeben, da die Datenbank keine Identity-Spalten nutzt. +Ergebnis: Systemweit eindeutige I3D-Schlüssel. +Belege: + - [PRIMÄR] src/backend/Centron.BL/SystemArea/SystemTableI3DBL.cs, GetSystemTableI3D() - Begründung: implementierender Zugriff. + - [KONTEXT] src/backend/Centron.BL/BaseBL.cs, Kommentar zu fehlenden Identityfeldern - Begründung: erklärt die Architekturentscheidung. +Prüfidee: Parallele Objektanlagen; erwartet: keine I3D-Kollision. +Tracelinks: SyRS-010 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - im Zielsystem durch DB-native Schlüsselvergabe ersetzen. +Status: belegt +``` + +``` +ID: SwRS-114 +Titel: Verschlagwortung von Tickets mit aktiven Tags +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Support +Vorbedingung: Tags sind angelegt. +Fakt: TagsBL (DBBaseBL) liefert aktive Tags und entfernt Ticket-Tags gezielt (RemoveTicketTag(helpdeskI3D, caption, loggedInUser)). +Aussage: Das System soll Objekte (belegt: Tickets) mit aktiven Tags verschlagworten und Tags benutzerbezogen entfernen können. +Ergebnis: Filterbare Verschlagwortung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Tags/TagsBL.cs, GetActiveTags/RemoveTicketTag - Begründung: implementierende Taglogik. +Prüfidee: Tag an Ticket setzen/entfernen; erwartet: Zustand konsistent. +Tracelinks: SyRS-040 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - leichtgewichtige Klassifizierung. +Status: belegt +``` + +``` +ID: SwRS-115 +Titel: Anruferkennung und Anrufdokumentation (TAPI) +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente PhoneCallBL +Vorbedingung: Anruf wird signalisiert oder manuell erfasst. +Fakt: PhoneCallBL erzeugt und aktualisiert PhoneCall-Datensätze, sucht Anrufe per Filter und identifiziert Ansprechpartner zur Rufnummer (SearchContactPersonByPhoneNumberV2). +Aussage: Die Software soll Anrufe als Datensätze führen und Anrufer über die Rufnummer Kontakten/Kunden zuordnen. +Ergebnis: Anrufhistorie mit Kundenkontext. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Tapi/PhoneCallBL.cs, CreatePhoneCall/SearchContactPersonByPhoneNumberV2 - Begründung: implementierende Anruflogik. +Prüfidee: Bekannte Rufnummer suchen; erwartet: passender Ansprechpartner. +Tracelinks: SyRS-030 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Funktion bleibt, Technik wechselt (siehe SyRS-030). +Status: belegt +``` + +``` +ID: SwRS-116 +Titel: Aufgabenverwaltung mit typisierten Aktions-Handlern +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente TaskManagementTaskBL +Vorbedingung: Aufgabe wird angelegt/abgearbeitet. +Fakt: TaskManagementTaskBL verwaltet Aufgaben (CRUD, Paging, Filter); Aktionen je Aufgabentyp sind als Handler gekapselt (ITaskManagementActionHandler mit Helpdesk- und Report-Handler). +Aussage: Das System soll Aufgaben mit typspezifischen Aktionen (z. B. Ticket erzeugen, Report ausführen) über austauschbare Handler verwalten. +Ergebnis: Erweiterbare Aufgabenautomatisierung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs, SaveOrUpdateTask/GetTasks; ActionHandler/TaskManagementHelpdeskActionHandler.cs, TaskManagementReportActionHandler.cs - Begründung: implementierende Aufgaben- und Handlerlogik. +Prüfidee: Aufgabe mit Helpdesk-Aktion ausführen; erwartet: Ticket entsteht. +Tracelinks: SyRS-029; StRS-031 +Konsolidierung: Kandidat: ToDoArea (ToDoBL) - zwei Aufgabenkonzepte +Übernahmewürdigkeit: übernehmen - Automatisierung; mit ToDos konsolidieren. +Status: belegt +``` + +``` +ID: SwRS-117 +Titel: Telemetrie der Funktions-, KI- und API-Nutzung +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Analysierbarkeit) +Akteur: Hersteller, Komponente TelemetryBL +Vorbedingung: Telemetrie ist aktiv. +Fakt: TelemetryBL erfasst Nutzungsdaten in Buckets, u. a. für MCP-Tool-Nutzung, KI-Tool-Nutzung und API-Aufrufe (McpToolUsageBucketIncrement, ArtificialIntelligenceToolUsageBucketIncrement, ApiCallBucketIncrement). +Aussage: Das System soll die Nutzung von Funktionen, KI-Werkzeugen und API-Aufrufen aggregiert erfassen. +Ergebnis: Datenbasis für Produktentscheidungen und Kapazitätsplanung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Telemetry/TelemetryBL.cs, Bucket-Klassen (Zeile 518ff) - Begründung: implementierende Telemetrieerfassung. +Prüfidee: API-Aufruf ausführen; erwartet: Bucket-Zähler steigt. +Tracelinks: SyRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - mit Datenschutzprüfung. +Status: belegt +``` + +``` +ID: SwRS-118 +Titel: Textbausteine mit Filterung und Anrede-/Grußformel-Ersetzung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle textproduzierenden Module +Vorbedingung: Textbausteine sind gepflegt. +Fakt: TextModuleBL liefert aktive/gefilterte Textbausteine (auch je Benutzer) und löscht listenweise; SalutationAndAgreementReplacementBL ersetzt Anrede- und Grußformeln (verwendet in Belegen: GetSalutationTextModule/GetAgreementTextModule der SpecificLogics). +Aussage: Das System soll wiederverwendbare Textbausteine (u. a. Anreden, Grußformeln) verwalten und kontextbezogen in Belege und Mails einsetzen. +Ergebnis: Konsistente Textbausteine über alle Ausgaben. +Belege: + - [PRIMÄR] src/backend/Centron.BL/TextModuleArea/TextModuleBL.cs, GetActiveTextModuleList/GetFilteredTextModuleList; SalutationAndAgreementReplacementBL.cs - Begründung: implementierende Bausteinlogik. +Prüfidee: Anrede-Baustein ändern; erwartet: neuer Beleg nutzt neue Anrede. +Tracelinks: SyRS-025, SyRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Standardfunktion. +Status: belegt +``` + +``` +ID: SwRS-119 +Titel: Ticket-Projekte mit Abhängigkeiten +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Support/Projektleitung +Vorbedingung: Ticket-Projekt existiert. +Fakt: TicketProjectBL verwaltet Ticket-Projekte und deren Abhängigkeiten (TicketProjectDependency CRUD). +Aussage: Das System soll Tickets zu Projekten bündeln und Abhängigkeiten zwischen Projektelementen abbilden. +Ergebnis: Strukturierte Abarbeitung zusammengehöriger Tickets. +Belege: + - [PRIMÄR] src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs, GetTicketProjects/SaveOrUpdateTicketProjectDependency - Begründung: implementierende Projektlogik. +Prüfidee: Abhängigkeit anlegen; erwartet: in Abhängigkeitsliste enthalten. +Tracelinks: SyRS-040; StRS-025 +Konsolidierung: Kandidat: SwRS-090 (Projects) - Projektbegriffe +Übernahmewürdigkeit: übernehmen - Support-Projektgeschäft. +Status: belegt +``` + +``` +ID: SwRS-120 +Titel: Zeitsteuerungs-Einstellungen (TimingSettings) +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Zeitgesteuerte Funktionen sind konfiguriert. +Fakt: TimingSettingsBL verwaltet TimingSettings (Liste, Filter, Löschen). +Aussage: Das System soll Zeitsteuerungs-Einstellungen als eigenständige Datensätze verwalten. +Ergebnis: Konfigurierbare Zeitpläne für abhängige Funktionen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Time/TimingSettingsBL.cs, GetTimingSettingsByFilter/DeleteTimingSettings - Begründung: implementierende Verwaltung. +Prüfidee: Einstellung anlegen und per Filter finden. +Tracelinks: SyRS-018 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Terminierung von Automatiken. +Status: belegt +``` + +``` +ID: SwRS-121 +Titel: Objektbezogene ToDos über Objektarten hinweg +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Mitarbeiter +Vorbedingung: ToDo wird zu einem Objekt angelegt. +Fakt: ToDoBL (DBBaseBL) liefert ToDos je Kunde, Objektart und Objekt (GetTodoEntries-Überladungen, IToDoObjectKind); Belegarten definieren erzeugte ToDo-Typen (CreatesToDosWithTypes in den SpecificLogics). +Aussage: Das System soll Aufgaben (ToDos) an beliebige Objektarten knüpfen; Belege sollen definierte ToDo-Typen automatisch erzeugen können. +Ergebnis: Objektbezogener Arbeitsvorrat. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ToDoArea/ToDoBL.cs, GetTodoEntries(...); Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, CreatesToDosWithTypes() (Zeile 299) - Begründung: implementierende ToDo-Logik. +Prüfidee: ToDo zu Beleg anlegen; erwartet: über Objektfilter auffindbar. +Tracelinks: SyRS-029 +Konsolidierung: Kandidat: SwRS-116 (TaskManager) +Übernahmewürdigkeit: übernehmen - siehe Konsolidierung. +Status: belegt +``` + +``` +ID: SwRS-122 +Titel: Textformat-Konvertierung (ToolBL) +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: UI-Komponenten +Vorbedingung: Text liegt in einem Quellformat vor. +Fakt: ToolBL.ChangeTextFormat konvertiert Texte zwischen Formaten (TextFormat). +Aussage: Die Software soll Texte zwischen den intern verwendeten Formaten (z. B. RTF/HTML/Plain) konvertieren. +Ergebnis: Einheitliche Textdarstellung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Tools/ToolBL.cs, ChangeTextFormat(string, TextFormat) - Begründung: implementierende Konvertierung. +Prüfidee: RTF-Text konvertieren; erwartet: Zielformat. +Tracelinks: SyRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - formatspezifisch fürs Desktop-UI; im Web meist HTML-only. +Status: belegt +``` + +``` +ID: SwRS-123 +Titel: TradePool-Artikelimport mit gefilterter Sichtung +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Einkauf (Gebrauchtwaren-/Handelsbörse) +Vorbedingung: Importdateien liegen vor. +Fakt: TradePoolBL importiert Handelsartikel aus Dateien (StartTradeImport) und liefert paginierte, filterbare Artikellisten (GetTradeArticleList mit Herstellercode-/Beschreibungs-/Klassenfilter); TradePoolXmlLogic verarbeitet das XML-Format. +Aussage: Das System soll Handelsartikel-Listen (TradePool) aus XML-Dateien importieren und durchsuchbar bereitstellen. +Ergebnis: Externe Handelsangebote sind im System sichtbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/TradePool/TradePoolBL.cs, StartTradeImport/GetTradeArticleList; TradePool/Core/TradePoolXmlLogic.cs - Begründung: implementierende Import- und Abfragelogik. +Prüfidee: Importdatei einlesen; erwartet: Artikel per Filter auffindbar. +Tracelinks: SyRS-027 +Konsolidierung: nein +Übernahmewürdigkeit: Sonderfall - Nutzung der TradePool-Börse im Zielsystem prüfen. +Status: belegt +``` + +``` +ID: SwRS-124 +Titel: Transaktionsobjekte mit Detailpositionen +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Komponente TransactionBL +Vorbedingung: Transaktionen werden erfasst. +Fakt: TransactionBL verwaltet Transactions mit Details (GetTransactionDetailsByTransactionId), gefiltert und je Benutzer abfragbar. +Aussage: Das System soll Transaktionsobjekte mit Detailpositionen führen und je Benutzer auswertbar machen. +Ergebnis: Nachvollziehbare Transaktionshistorie. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Transactions/TransactionBL.cs, GetAllTransactions/GetTransactionDetailsByTransactionId/SaveTransaction - Begründung: implementierende Verwaltung. +Prüfidee: Transaktion mit Details speichern und laden. +Tracelinks: SyRS-020 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - vorbehaltlich fachlicher Klärung des Einsatzzwecks. +Status: belegt +``` + +``` +ID: SwRS-125 +Titel: Objektbezogene Weblinks (SimpleUrl) +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Benutzer +Vorbedingung: Objekt existiert. +Fakt: SimpleUrlBL verwaltet URL-Datensätze per Filter, speichert über DTO mit LoggedInUser und löscht listenweise; SimpleUrlWebServiceBL stellt sie dem Webservice bereit. +Aussage: Das System soll je Objekt beliebige Weblinks verwalten und über die API bereitstellen. +Ergebnis: Schnellzugriffe auf externe Ressourcen je Objekt. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Urls/SimpleUrlBL.cs, SaveOrUpdateSimpleUrl/GetSimpleUrlByFilter - Begründung: implementierende Linkverwaltung. +Prüfidee: Link an Kunde anlegen; erwartet: per Filter abrufbar. +Tracelinks: SyRS-026 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kleinfunktion. +Status: belegt +``` + +``` +ID: SwRS-126 +Titel: Zuordnung von Schulungsvideos (Videoportal) +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Videoportal-Inhalte existieren. +Fakt: VideoPortalAssignmentBL speichert, listet und löscht Videozuordnungen benutzerbezogen (LoggedInUser). +Aussage: Das System soll Schulungsvideos Modulen/Funktionen zuordnen können. +Ergebnis: Kontextbezogene Lerninhalte. +Belege: + - [PRIMÄR] src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs, SaveVideoPortalAssignment/GetAllVideoPortalAssignments - Begründung: implementierende Zuordnung. +Prüfidee: Zuordnung anlegen; erwartet: in Liste enthalten. +Tracelinks: SyRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Onboarding-Hilfe. +Status: belegt +``` + +``` +ID: SwRS-127 +Titel: Gutscheinverwaltung mit Barcode und Statusfilter +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Kasse/Vertrieb +Vorbedingung: Gutscheine sind erzeugt. +Fakt: VoucherManagementBL liefert aktive Gutschein-Barcodes gefiltert nach Status frei/ausgegeben/eingelöst (GetActivedVoucherBarcodes(FilterFreeVoucher, FilterVoucherIssued, FilterRedeemVoucher)). +Aussage: Das System soll Gutscheine mit Barcode über die Zustände frei → ausgegeben → eingelöst verwalten. +Ergebnis: Gutscheinbestand mit eindeutigem Status je Barcode. +Belege: + - [PRIMÄR] src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs, GetActivedVoucherBarcodes(bool,bool,bool) - Begründung: implementierende Statusfilterung. +Prüfidee: Gutschein einlösen; erwartet: erscheint nur noch im Eingelöst-Filter. +Tracelinks: SyRS-042 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kassennahe Funktion. +Status: belegt +``` + +``` +ID: SwRS-128 +Titel: Artikelstamm: Sonderartikel, Rechte und UI-Einstellungen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Komponente ArticleBL +Vorbedingung: Artikelstamm existiert. +Fakt: ArticleBL prüft Artikelrechte je Benutzer (HasUserArticleRights), liefert Systemartikel (Frachtartikel GetFreightArticle, Kundenrabattartikel GetCustomerDiscountArticle, Sammelartikel für externe Artikel GetArticleI3DForExternalArticles), erkennt Dienstleistungsartikel (IsArticleAServiceArticle über Materialgruppe) und verwaltet UI-Einstellungen der Artikelverwaltung. +Aussage: Die Software soll den Artikelstamm rechtegeschützt führen und definierte Systemartikel (Fracht, Rabatt, externe Artikel) sowie Dienstleistungskennzeichen bereitstellen. +Ergebnis: Belege greifen auf konsistente Artikel- und Sonderartikellogik zu. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Warehousing/ArticleBL.cs, HasUserArticleRights/GetFreightArticle/IsArticleAServiceArticle/GetArticleI3DForExternalArticles - Begründung: implementierende Artikellogik. +Prüfidee: Frachtposition erzeugen; erwartet: nutzt den konfigurierten Frachtartikel. +Tracelinks: SyRS-013; StRS-008 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Artikelstamm ist Kern. +Status: belegt +``` + +``` +ID: SwRS-129 +Titel: Aktions-Weblinks mit Klick-Protokoll +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Externe Empfänger, Komponente WebLinkBL +Vorbedingung: Weblink mit Aktion wurde versendet. +Fakt: WebLinkBL verwaltet Linkgruppen, Links, Aktionen und Klicks (GetWebLinkClicks); Aktions-Handler existieren für Kontoaktivitäten und Erinnerungen (WebLinkActionAccountActivityHandler, WebLinkActionReminderHandler). +Aussage: Das System soll versendbare Weblinks mit hinterlegten Aktionen (z. B. Erinnerung bestätigen) bereitstellen und Klicks protokollieren. +Ergebnis: Interaktive Links mit Nachweis der Nutzung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/WebLinks/WebLinkBL.cs, GetWebLinkActions/GetWebLinkClicks; WebLinkActionReminderHandler.cs - Begründung: implementierende Link- und Aktionslogik. +Prüfidee: Link klicken; erwartet: Klickdatensatz und ausgeführte Aktion. +Tracelinks: SyRS-031; StRS-019 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Self-Service-Baustein. +Status: belegt +``` + +``` +ID: SwRS-130 +Titel: Konfigurierbares Webmenü mit Sortierung und Sichtbarkeit +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator (Web-Suite) +Vorbedingung: Webmenü-Einträge existieren. +Fakt: WebMenuConfigBL verwaltet Menüeinträge je Gruppe mit Verschieben (MoveWebMenuConfigEntry), Sichtbarkeit je Gruppe (UpdateVisibilityOfWebMenuConfigGroup) und Sortierung (SortWebMenuConfigGroup); weitere Web-Einstellungen liegen in WebSettingBL/WebSettingGlobalBL, Webformular-Fragen in WebHDQuestionBL. +Aussage: Das System soll das Menü der Webanwendung je Gruppe konfigurierbar machen (Reihenfolge, Sichtbarkeit) und Web-Einstellungen global wie benutzerbezogen verwalten. +Ergebnis: Anpassbare Webnavigation ohne Deployment. +Belege: + - [PRIMÄR] src/backend/Centron.BL/WebSuite/Administration/Settings/WebMenuConfigBL.cs, MoveWebMenuConfigEntry/UpdateVisibilityOfWebMenuConfigGroup/SortWebMenuConfigGroup - Begründung: implementierende Menülogik. +Prüfidee: Eintrag verschieben; erwartet: neue Reihenfolge im Web. +Tracelinks: SyRS-031 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Web-Konfiguration. +Status: belegt +``` + +``` +ID: SwRS-131 +Titel: Versionsauskunft des Webservice +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Clients +Vorbedingung: Webservice läuft. +Fakt: VersionBL.GetWebserviceVersion liefert die Webservice-Version. +Aussage: Das System soll Clients die Webservice-Version zur Kompatibilitätsprüfung bereitstellen. +Ergebnis: Clients erkennen Versionsinkompatibilitäten. +Belege: + - [PRIMÄR] src/backend/Centron.BL/WebVersion/VersionBL.cs, GetWebserviceVersion() - Begründung: implementierende Auskunft. +Prüfidee: Versionsabruf; erwartet: Assembly-Version des Webservice. +Tracelinks: SyRS-031; SwRS-033 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - API-Versionsauskunft. +Status: belegt +``` + +``` +ID: SwRS-132 +Titel: PDF-Zusammenführung als wiederverwendbarer Helfer +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Druck-/Mailfunktionen +Vorbedingung: Mehrere PDFs sollen zu einem Dokument werden. +Fakt: PdfInteractionBL.MergePdfFiles fasst PDF-Byteströme oder Dateien zu einem PDF zusammen. +Aussage: Die Software soll mehrere PDF-Dokumente zu einem Gesamtdokument zusammenführen können (z. B. Beleg + Anhänge). +Ergebnis: Ein versandfertiges Gesamt-PDF. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Helpers/PdfInteractionBL.cs, MergePdfFiles(IList) - Begründung: implementierende Zusammenführung. +Prüfidee: Zwei PDFs mergen; erwartet: ein PDF mit allen Seiten. +Tracelinks: SyRS-025 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Standardhelfer. +Status: belegt +``` + +``` +ID: SwRS-133 +Titel: Fachliche Ausnahmen als typisierte Exceptions +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Fehlerbehandlung +Vorbedingung: Fachlicher Fehlerfall tritt ein. +Fakt: Das Exceptions-Modul definiert fachliche Ausnahmen wie TicketExpiredException (abgelaufene Sitzungs-Tickets). +Aussage: Die Software soll fachliche Fehlerzustände (z. B. abgelaufenes Sitzungsticket) als typisierte Ausnahmen signalisieren, damit Clients gezielt reagieren (z. B. Re-Login). +Ergebnis: Unterscheidbare Fehlerbehandlung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Exceptions/TicketExpiredException.cs - Begründung: typisierte fachliche Ausnahme. +Prüfidee: Aufruf mit abgelaufenem Ticket; erwartet: TicketExpiredException und Re-Login im Client. +Tracelinks: SyRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Muster beibehalten. +Status: belegt +``` + +``` +ID: SwRS-134 +Titel: Benutzerbezogene Grid- und UI-Profile +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Benutzer, Komponente GUI-BL +Vorbedingung: Benutzer passt Tabellen/Oberfläche an. +Fakt: UserGridBL speichert Grid-Einstellungen je Mitarbeiter und Grid (GetUserGridSettings(employeeId, gridId)); UiProfileBL verwaltet UI-Profile persönlich und global (LoadProfiles mit includeGlobal, Save/Delete mit LoggedInUser). +Aussage: Die Software soll Tabellen-Layouts und UI-Profile je Benutzer speichern und globale Profile teilen können. +Ergebnis: Persistente, teilbare Oberflächenanpassungen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/GUI/UserGridBL.cs, GetUserGridSettings; GUI/Profiles/UiProfileBL.cs, LoadProfiles/SaveProfile - Begründung: implementierende Profillogik. +Prüfidee: Grid-Layout ändern, neu anmelden; erwartet: Layout bleibt erhalten. +Tracelinks: SyRS-031 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - erwartete UI-Personalisierung. +Status: belegt +``` + +``` +ID: SwRS-135 +Titel: Auswertungen: offene Posten, Umsatz-, Vertrags- und MSP-Statistiken +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Controlling, Komponente Statistics +Vorbedingung: Bewegungsdaten liegen vor. +Fakt: Der Statistics-Bereich liefert offene Rechnungen je Konto (AccountStatisticBL.GetAccountUnpaidInvoiceOverview), Umsatzstatistiken (RevenueStatisticBL.GetNexowareRevenueStatistic mit Zeitraum), Vertragsauswertungen (ContractEvaluationBL/ContractStatisticBL), Mitarbeiterauslastung und -zeiten (EmployeeUtilizationBL, EmployeeTimeRecordsStatisticBL) sowie MSP-Statistiken (MspStatisticBL.GetMspArticleStatistic, MspCollectorsBL). +Aussage: Das System soll betriebswirtschaftliche Auswertungen bereitstellen: offene Posten je Kunde, Umsätze je Zeitraum, Vertrags- und Auslastungsstatistiken sowie MSP-Verbrauchsauswertungen. +Ergebnis: Steuerungsrelevante Kennzahlen ohne Externwerkzeug. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Statistics/Accounts/AccountStatisticBL.cs, GetAccountUnpaidInvoiceOverview; Statistics/Accounts/RevenueStatisticBL.cs, GetNexowareRevenueStatistic; Statistics/MspStatistics/MspStatisticBL.cs, GetMspArticleStatistic - Begründung: implementierende Auswertungslogik. +Prüfidee: Unbezahlte Rechnung anlegen; erwartet: erscheint in der Offene-Posten-Übersicht des Kontos. +Tracelinks: SyRS-021, SyRS-032; StRS-016 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kernauswertungen; Statistik-Recht (RIGHT_STATISTIK=20400015) beachten. +Status: belegt +``` + +``` +ID: SwRS-136 +Titel: Webservice-Fassaden-Schicht je Fachmodul (DTO-Bereitstellung) +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Webservice, Clients +Vorbedingung: Client fordert Fachdaten über die API an. +Fakt: Centron.BL/WebServices spiegelt die Fachmodule als eigene Webservice-BL-Schicht (464 Dateien in Unterordnern Accounts, Administration, Sales, CentronNexus, CentronReportEngine u. a., z. B. ReceiptWebServiceBL); mehrere Module führen parallele *WebServiceBL-Klassen (MyDayWebServiceBL, IncomingPaymentWebServiceBL, SimpleUrlWebServiceBL, CentronIconsWebserviceBL). +Aussage: Die Software soll Fachfunktionen über eine dedizierte Webservice-Fassadenschicht mit DTOs bereitstellen, getrennt von der internen Geschäftslogik. +Ergebnis: Stabile API-Verträge; interne Modelle bleiben gekapselt. +Belege: + - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs (verwendet u. a. von InvoiceUploadBL für Rechnungseinstellungen) und die Ordnerstruktur WebServices/* - Begründung: implementierende Fassadenschicht. +Prüfidee: API-Abruf eines Belegs; erwartet: DTO-Struktur statt interner Entität. +Tracelinks: SyRS-031, SyRS-046 +Konsolidierung: Kandidat: Doppelstrukturen BL vs. WebServices-BL je Modul - im Zielsystem eine Serviceschicht +Übernahmewürdigkeit: übernehmen - Muster ja, Doppelpflege nein. +Status: belegt +``` + +``` +ID: SwRS-137 +Titel: Persistenzschicht: NHibernate mit Ereignis-Listenern (Stringkürzung, Change-Tracking) +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Komponente Centron.DAO +Vorbedingung: Entität wird gespeichert. +Fakt: Die DAO-Schicht basiert auf NHibernate (Mappings je Modul, DAOSession/GenericDAO, NamedQueries, Repositories); Event-Listener greifen vor Insert/Update: TruncateStringsEventListener kürzt Strings stillschweigend auf die Mappinglänge (TruncatedStringUserType), StringOrBinaryDataWouldBeTruncatedEventListener behandelt Kürzungsfehler, ChangeTrackingEventListener und LogHourlySurchargeRateChangesListener protokollieren Änderungen, WhyIsMyEntityUpdatedEventListener unterstützt Diagnose. +Aussage: Die Software soll die Persistenz zentral über ein ORM mit Ereignis-Listenern abwickeln; überlange Strings werden vor dem Speichern automatisch auf Feldlänge gekürzt statt Fehler auszulösen. +Ergebnis: Keine Truncation-Ausnahmen; dafür stiller Datenverlust bei Überlänge (bewusste Altentscheidung). +Belege: + - [PRIMÄR] src/backend/Centron.DAO/TruncateStringsEventListener.cs, TruncateStringsIfNeeded(...) (Substring auf Mappinglänge); ChangeTracking/ChangeTrackingEventListener.cs; DAOSession.cs, GenericDAO.cs, Mappings/* - Begründung: durchsetzende Persistenzmechanik. +Prüfidee: String länger als Feldlänge speichern; erwartet: gekürzt gespeichert, kein Fehler. +Tracelinks: SyRS-010, SyRS-009 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - stille Kürzung im Zielsystem durch Validierung mit Benutzerfeedback ersetzen. +Status: belegt +``` + +``` +ID: SwRS-138 +Titel: Einheitliches Entitätsmodell mit I3D-Schlüssel +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Alle Schichten +Vorbedingung: Geschäftsobjekt wird modelliert. +Fakt: Centron.Entities definiert alle persistierten Geschäftsobjekte auf Basis von PersistedEntity/PersistedLongEntity (I3D-Schlüssel, BaseEntity/DBEntity mit Change-Tracking-Feldern) plus WebServices-DTO-Varianten. +Aussage: Die Software soll alle Geschäftsobjekte in einem einheitlichen Entitätsmodell mit gemeinsamem Schlüsselkonzept (I3D) und Change-Tracking-Basisfeldern führen. +Ergebnis: Durchgängige Objektidentität über alle Module. +Belege: + - [PRIMÄR] src/backend/Centron.Entities/PersistedEntity.cs, PersistedLongEntity.cs, Entities/* - Begründung: implementierendes Modell. +Prüfidee: Beliebige Entität prüfen; erwartet: I3D + Created/Changed-Felder vorhanden. +Tracelinks: SyRS-009, SyRS-010 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - als fachliches Objektmodell; technisch neu aufsetzen. +Status: belegt +``` + +``` +ID: SwRS-139 +Titel: Querschnittsbibliothek mit lizenzgesteuerten Modul-Features +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Module +Vorbedingung: Funktion ist lizenz-/featureabhängig. +Fakt: Centron.Common bündelt Querschnittsfunktionen (Logging, Settings, Calculations, Users, IO, Format) und definiert ModuleFeatures als zentrale Feature-Schalter (z. B. IsDsgvoDatabaseCleanupAvailable, geprüft in DataSecurityBL); DeveloperSecurity kapselt Entwicklerzugriffe. +Aussage: Die Software soll modulare Funktionsfreischaltungen zentral als Feature-Eigenschaften bereitstellen, die fachliche Module vor Ausführung prüfen. +Ergebnis: Lizenz-/editionabhängige Funktionssteuerung an einer Stelle. +Belege: + - [PRIMÄR] src/backend/Centron.Common/ModuleFeatures.cs; Verwendung in DataSecurityBL (ModuleFeatures.IsDsgvoDatabaseCleanupAvailable) - Begründung: durchsetzende Feature-Prüfung. +Prüfidee: Feature deaktivieren; erwartet: abhängige Funktion verweigert. +Tracelinks: SyRS-003; SwRS-009 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Feature-Gating bleibt (im SaaS als Plan-/Paketsteuerung). +Status: belegt +``` + +``` +ID: SwRS-140 +Titel: Zentrale Objektarten- und Konstantendefinition (CentronObjectKindNumeric) +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Alle Schichten +Vorbedingung: Objektartübergreifende Funktion (ToDos, Referenzen, Belege) wird genutzt. +Fakt: Centron.Interfaces definiert die numerische Objektartenliste CentronObjectKindNumeric (verwendet in Belegkette, ToDos, Custom Properties, externen Referenzen) sowie Schnittstellen und Konstanten je Fachbereich. +Aussage: Die Software soll alle Objektarten zentral und eindeutig nummeriert definieren, damit generische Funktionen (Verknüpfungen, Rechte, Suche) objektartsicher arbeiten. +Ergebnis: Einheitliche Objektart-Codes systemweit. +Belege: + - [PRIMÄR] src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs; Verwendungen in ReceiptBL/ToDoBL/ModuleCustomPropertyBL - Begründung: zentrale Definition + Nutzung. +Prüfidee: Neue generische Funktion nutzt dieselben Codes; erwartet: kompatible Verknüpfungen. +Tracelinks: SyRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - als kontrolliertes Enum/Katalog. +Status: belegt +``` + +``` +ID: SwRS-141 +Titel: Gateway-Formatadapter (EDI-Distributoren, OpenTrans, FiBu, Onlinebanking) +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Komponente Centron.Gateway +Vorbedingung: Externes Format muss gelesen/geschrieben werden. +Fakt: Centron.Gateway kapselt Formatadapter: EDI je Distributor (EDI_Alltron, EDI_Also/CH, EDI_EGIS, EDI_Herweck, EDI_Komsa), OpenTrans 1.0, Concerto, DATEV-Formate (DatevAscii/DatevXmlOnline/2020, genutzt von BookKeepingExportBL), ZUGFeRD 2.1, Onlinebanking, MspCollector, Portal sowie generischen Import/Export. +Aussage: Die Software soll externe Datenformate in einer eigenen Gateway-Schicht kapseln, sodass Fachlogik formatunabhängig bleibt. +Ergebnis: Neue Formate ohne Änderungen an der Fachlogik ergänzbar. +Belege: + - [PRIMÄR] src/backend/Centron.Gateway/EDI_*, OpenTrans1_0, ZUGFeRD21_Extended, OnlineBanking, Export/Import (Ordnerstruktur mit Adapterklassen) - Begründung: implementierende Adapter. +Prüfidee: Neues Distributorformat als weiterer Adapter; erwartet: keine Änderung in EDIDispatcher-Aufrufern nötig. +Tracelinks: SyRS-027, SyRS-021, SyRS-043 +Konsolidierung: Kandidat: EDI-Logik existiert in Centron.BL/EDI und Centron.Gateway (siehe SyRS-027) +Übernahmewürdigkeit: übernehmen - Adapter-Prinzip beibehalten. +Status: belegt +``` + +``` +ID: SwRS-142 +Titel: WPF-Desktop-Client mit Modul-Navigation, Wizards und Lokalisierung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Interner Benutzer +Vorbedingung: Desktop-Client ist installiert. +Fakt: Centron.WPF.UI strukturiert den Client in Module, Views/ViewModels (MVVM), Dialoge, Wizards, Layout- und Style-Ressourcen sowie Lokalisierung (Localization-Ordner, ResXManager.config.xml im Repo); StartupArgs und Prozesslogik steuern den Start; eine Extension-Assembly erweitert den Client. +Aussage: Das System soll den Desktop-Client modular (MVVM) mit lokalisierbaren Texten, geführten Assistenten und benutzerspezifischem Layout bereitstellen. +Ergebnis: Mehrsprachfähiger, modular erweiterbarer Desktop-Client. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules, Views, ViewModels, Wizards, Localization (Ordnerstruktur); ResXManager.config.xml - Begründung: implementierende Clientstruktur. +Prüfidee: Sprachumschaltung; erwartet: lokalisierte Masken. +Tracelinks: SyRS-031 +Konsolidierung: Kandidat: Nexus-Webclient (SyRS-031) - Doppel-UI +Übernahmewürdigkeit: veraltet - Desktop-Client wird durch Web-Zielsystem abgelöst; Fachinhalte der Masken sind Migrationsreferenz. +Status: belegt +``` + +``` +ID: SwRS-143 +Titel: Wiederverwendbare UI-Controls mit Dokumentvorschau +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Desktop-Client +Vorbedingung: Masken benötigen Standard-Controls. +Fakt: Centron.Controls (+ Centron.Controls.Preview) stellt gemeinsame Controls inkl. Dokumentvorschau bereit; Tests existieren (Centron.Tests.Controls). +Aussage: Das System soll wiederkehrende UI-Bausteine (inkl. Dateivorschau) zentral bereitstellen. +Ergebnis: Konsistente Bedienelemente. +Belege: + - [PRIMÄR] src/shared/Centron.Controls, src/shared/Centron.Controls.Preview (Projekte) - Begründung: implementierende Bibliothek. +Prüfidee: Vorschau einer PDF-Datei in verschiedenen Masken; erwartet: identisches Control. +Tracelinks: SyRS-031 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - WPF-spezifisch; Konzept (Komponentenbibliothek) übernehmen. +Status: belegt +``` + +``` +ID: SwRS-144 +Titel: Gemeinsame Kernbibliothek (TOTP, PDF-Scan, Guards, MVVM) +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Client und Server +Vorbedingung: Basisfunktionen werden benötigt. +Fakt: src/shared/Centron.Core enthält u. a. GoogleAuthenticator/TotpAuth (PIN-Validierung, genutzt von TwoFactorAuthenticationBL), PdfScanning, ImprintParser, Guard-Klasse, MVVM- und Threading-Helfer. +Aussage: Die Software soll sicherheits- und basisrelevante Kernfunktionen (TOTP-Validierung, PDF-Scan, Eingabewächter) in einer von Client und Server gemeinsam genutzten Bibliothek führen. +Ergebnis: Einheitliche Kernfunktionen ohne Duplikate. +Belege: + - [PRIMÄR] src/shared/Centron.Core/GoogleAuthenticator, TotpAuth, Guard.cs, PdfScanning - Begründung: implementierende Kernkomponenten. +Prüfidee: TOTP-Validierung aus BL ruft Centron.Core auf (TwoFactorAuthenticationBL.ValidateAuthenticationPin). +Tracelinks: SyRS-005 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kernlogik portieren. +Status: belegt +``` + +``` +ID: SwRS-145 +Titel: Nexus-Webclient: interne Web-Oberfläche und Kundenportal +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Mitarbeiter (Web), Endkunde (Portal) +Vorbedingung: Nexus ist gehostet (CentronNexus.Host). +Fakt: CentronNexus (Blazor) umfasst ServiceBoard, ProductionOrderManagement, Office-Integration, Management, Settings, WebCart/Kundenportal, WebOffer und DocumentSigning (IsolatedSignaturePad); Hosting erfolgt über CentronNexus.Host, Outlook-Integration über CentronNexus.OutlookAddIn; laut README werden DevExpress-Blazor-Komponenten und Bootstrap-Variablen verwendet. +Aussage: Das System soll eine Web-Oberfläche für interne Prozesse (Service-Board, Produktionsaufträge) und das Kundenportal bereitstellen, gehostet als eigenständige Webanwendung mit Outlook-Add-In. +Ergebnis: Browserbasierter Zugriff auf Kernprozesse. +Belege: + - [PRIMÄR] src/nexus/CentronNexus/ServiceBoard, ProductionOrderManagement, WebCart, DocumentSigning (Razor-Seiten); src/nexus/CentronNexus.Host; src/nexus/CentronNexus.OutlookAddIn - Begründung: implementierende Webanwendung. + - [KONTEXT] README.md (Komponenten-/CSS-Richtlinien für Nexus) - Begründung: Architekturvorgaben. +Prüfidee: ServiceBoard im Browser öffnen; erwartet: Ticketbearbeitung ohne Desktop-Client. +Tracelinks: SyRS-031, SyRS-045 +Konsolidierung: Kandidat: SwRS-142 (Desktop-Masken) - Funktionsdopplung bis zur Abloesung +Übernahmewürdigkeit: übernehmen - Ausgangspunkt des Web-Zielsystems. +Status: belegt +``` + +``` +ID: SwRS-146 +Titel: Webservice-Hosting als Windows-Dienst oder Konsole +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Anpassbarkeit) +Akteur: Betrieb +Vorbedingung: Webservice soll betrieben werden. +Fakt: Centron.Host kapselt den Webservice-Kern; Centron.Host.Console und Centron.Host.WindowsService hosten ihn wahlweise interaktiv oder als Windows-Dienst; Centron.WebServices.Core enthält die Dienstinfrastruktur; c-entron.misc.ConnectionManager verwaltet Verbindungskonfigurationen als Werkzeug. +Aussage: Das System soll den Webservice wahlweise als Windows-Dienst, Konsolenprozess oder Container betreiben können. +Ergebnis: Flexible Betriebsmodelle (On-Premise und Cloud). +Belege: + - [PRIMÄR] src/webservice/Centron.Host, Centron.Host.Console, Centron.Host.WindowsService, Centron.WebServices.Core; src/webservice/c-entron.misc.ConnectionManager - Begründung: implementierende Hosting-Varianten. +Prüfidee: Start als Konsole und als Dienst; erwartet: identisches API-Verhalten. +Tracelinks: SyRS-047, SyRS-031 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Container-Variante wird Standard. +Status: belegt +``` + +``` +ID: SwRS-147 +Titel: Versionierte REST-Controller mit Rechte-Attributen +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: API-Clients +Vorbedingung: API-Version v1 wird angesprochen. +Fakt: Centron.Controllers/Controllers/v1 enthält Ressourcen-Controller (Accounts, Contracts, Customers, DataExchange, Helpdesks, Integrations, Offers, Orders, Receipts, SelfCare, Tickets, WebAccount, WebVersion, Nexoware) neben unversionierten Controllern; Routing liegt in Configuration/Routing; Rechte werden per Authorize*-Attributen deklariert (SyRS-046). +Aussage: Die Software soll die API versioniert (v1) und ressourcenorientiert strukturieren, mit deklarativer Rechteprüfung je Aktion. +Ergebnis: Abwärtskompatible, geschützte API. +Belege: + - [PRIMÄR] src/webservice/Centron.Controllers/Controllers/v1/* (Ordnerliste), Configuration/Routing, Authorization/* - Begründung: implementierende API-Struktur. +Prüfidee: v1-Endpunkt aufrufen; erwartet: stabile Route auch nach Einführung v2. +Tracelinks: SyRS-046, SyRS-031 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - API-Basis des Zielsystems. +Status: belegt +``` + +``` +ID: SwRS-148 +Titel: Distributor-Produktdatenzugriffe (COP, EGIS, Icecat, ITscope) +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Einkauf/Artikelverwaltung +Vorbedingung: Zugangsdaten je Dienst sind konfiguriert. +Fakt: Eigene API-Projekte kapseln Produkt-/Bestandsdatenzugriffe: Centron.APIs.CopDataAccess (SOAP-Templates + Parser), Centron.APIs.EgisDataAccess (RequestTemplates + Parser), Centron.APIs.IcecatDataAccess (Produktdatenkatalog), Centron.APIs.ITscopeDataAccess (Handelsplattform); die Belegwesen-Artikelsuche nutzt sie als externe Suchprovider (CopApiBase-/Egis-/ITscopeExternalArticleSearchProvider). +Aussage: Das System soll Artikel- und Verfügbarkeitsdaten externer Anbieter direkt in der Artikelsuche der Belegerfassung anbieten. +Ergebnis: Externe Artikel inkl. Preis/Verfügbarkeit ohne Systemwechsel. +Belege: + - [PRIMÄR] src/apis/Centron.APIs.*DataAccess (Data/Parser/Templates); src/backend/Centron.BL/Sales/Receipts/ArticleSearch/ITscopeExternalArticleSearchProvider.cs, EgisExternalArticleSearchProvider.cs, CopApiBaseExternalArticleSearchProvider.cs - Begründung: implementierende Provider-Kette. +Prüfidee: Artikelsuche mit aktiviertem ITscope-Provider; erwartet: externe Treffer in der Belegposition übernehmbar (CanInsertNewAndExternalArticles der Belegart beachtend). +Tracelinks: SyRS-027; StRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Wettbewerbsrelevante Integrationen. +Status: belegt +``` + +``` +ID: SwRS-149 +Titel: finAPI-REST-Client für Onlinebanking +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Komponente Centron.APIs.FinAPI +Vorbedingung: finAPI-Zugangsdaten sind hinterlegt (OnlineBankingFinApiBL liefert Credentials). +Fakt: Centron.APIs.FinAPI kapselt den finAPI-Dienst mit RestClient, Requests/Responses und Datenklassen. +Aussage: Die Software soll Bankzugänge und Kontoumsätze über den finAPI-Dienst per REST abrufen. +Ergebnis: Umsatzimport für den Zahlungsabgleich (SyRS-032). +Belege: + - [PRIMÄR] src/apis/Centron.APIs.FinAPI/RestClient, Requests, Responses - Begründung: implementierender Client. +Prüfidee: Credentials abrufen und Testumsätze laden; erwartet: Transaktionen im Abgleichsmodul. +Tracelinks: SyRS-032 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Bankanbindung bleibt. +Status: belegt +``` + +``` +ID: SwRS-150 +Titel: docuFORM-Anbindung für Druckerdaten (Managed Print) +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: MSP-Prozesse +Vorbedingung: docuFORM-Dienst ist erreichbar. +Fakt: Centron.Api.docuFORM (eigenes Projekt mit Helper/Models) bindet docuFORM an; DocuFormApiSettingsBL verwaltet die Zugangskonfiguration; Zählerstände fließen in die Vertragsabrechnung (SyRS-038). +Aussage: Das System soll Druckerdaten (Zählerstände, Gerätestatus) aus docuFORM übernehmen und der Vertragsabrechnung bereitstellen. +Ergebnis: Automatisierte Seitenpreis-Abrechnung. +Belege: + - [PRIMÄR] Centron.Api.docuFORM/Helper, Models; src/backend/Centron.BL/DataExchange/DocuForm/DocuFormApiSettingsBL.cs - Begründung: implementierende Anbindung und Konfiguration. +Prüfidee: Zählerimport aus docuFORM; erwartet: Zählerstände am Vertrag. +Tracelinks: SyRS-038, SyRS-027 +Konsolidierung: Kandidat: Drucker als „Stammblätter" vs. Assets (SyRS-028) - Zielbild ein Gerätekonzept +Übernahmewürdigkeit: übernehmen - Managed-Print-Geschäft. +Status: belegt +``` + +``` +ID: SwRS-151 +Titel: GLS-/Shipcloud-Versandlogik mit Test- und Produktivumgebung +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Komponente Centron.Api.Gls / Centron.Api.Shipcloud +Vorbedingung: Versanddaten und Zugangsdaten liegen vor. +Fakt: CentronGlsLogic.UploadShipment sendet Sendungen mit Benutzer/Passwort wahlweise gegen Test- (api-qs.gls-group.eu) oder Produktiv-URL (api.gls-group.eu); Fehlercodes sind zentral definiert (CentronGlsErrors); Shipcloud analog über CentronShipcloudLogic. +Aussage: Die Software soll Versandübertragungen mit umschaltbarer Test-/Produktivumgebung und definierter Fehlerbehandlung ausführen. +Ergebnis: Gefahrloses Testen; klare Fehlerdiagnose. +Belege: + - [PRIMÄR] src/apis/Centron.Api.Gls/CentronGlsLogic.cs, UploadShipment(..., bool isTest, ...); CentronGlsConsts.cs; CentronGlsErrors.cs - Begründung: durchsetzende Versand- und Umgebungslogik. +Prüfidee: isTest=true; erwartet: Aufruf gegen QS-URL. +Tracelinks: SyRS-044 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Standard-Versandintegration. +Status: belegt +``` + +``` +ID: SwRS-152 +Titel: Legacy-Datenbankschema mit belegartspezifischen Kundenkonditionen +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Datenbank (MSSQL) +Vorbedingung: - +Fakt: Das Schema (SSMS_DB_SCHEMA.sql) umfasst 1558 Tabellen mit deutschsprachigen Legacy-Namen (Kunden, Kreditor, AufKopf, LiefKopf, Sichbenu/Sichtrus/Sichmemb) und 1654 Key-/Unique-Constraints; die Tabelle Kunden führt u. a. je Belegart eigene Zahlungskonditionsfelder (ZahlKondAng, ZahlKondAuf, ZahlKondSer, ZahlkondLief, ZahlkondAbhol, ZahlKondRech, ZahlKondGut), doppelte Bankverbindungsfelder (Bank/Bank02 inkl. IBAN/SWIFT) und Klassifizierungs-Flags (Haendler, Endkunde, Interessent). +Aussage: Das System soll je Kunde und Belegart eine eigene Standard-Zahlungskondition sowie mehrere Bankverbindungen und Kundenklassifizierungen persistieren. +Ergebnis: Belege ziehen die belegartspezifische Kondition des Kunden als Vorschlagswert. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[Kunden] (Zeile 2767ff, Spalten ZahlKond*/Bank*/Haendler/Endkunde) - Begründung: persistierte Datenstruktur als durchgesetzte Regel. +Prüfidee: Kunde mit abweichender Rechnungs-Kondition; erwartet: neue Rechnung schlägt diese vor, Angebot die Angebots-Kondition. +Tracelinks: SyRS-011, SyRS-020 +Konsolidierung: Kandidat: Bankfelder in Kunden vs. BankAccount-Tabelle (SwRS-019) - zwei Datenhaltungen für Bankverbindungen +Übernahmewürdigkeit: übernehmen - fachliche Regel ja; Schema-Altlasten (Feldpaare Bank/Bank02) bereinigen. +Status: belegt +``` + +``` +ID: SwRS-153 +Titel: Auslieferungs- und Betriebsartefakte (Installer, Container, CI) +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Installierbarkeit) +Akteur: Build/Release +Vorbedingung: Release wird erstellt. +Fakt: WixSharpInstaller erzeugt das Client-MSI; docker/* definiert Serverimages und compose-Betrieb; CI-Definitionen liegen in .github/workflows und azure/build-templates; Buildwerkzeuge (Signierung, WXS) in scripts/Centron.Scripts. +Aussage: Das System soll über automatisierte Build-Pipelines als signierter Client-Installer und als Server-Container ausgeliefert werden. +Ergebnis: Reproduzierbare Releases beider Kanäle. +Belege: + - [PRIMÄR] deployment/WixSharpInstaller/Program.cs; docker/compose/compose.yaml; scripts/Centron.Scripts/SignHelper.cs; .github/workflows - Begründung: implementierende Release-Artefakte. +Prüfidee: Pipeline-Lauf; erwartet: MSI + Container-Image als Artefakte. +Tracelinks: SyRS-047, SyRS-048, SyRS-049 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Containerpfad; MSI entfällt mit Desktop-Ablösung. +Status: belegt +``` + +``` +ID: SwRS-154 +Titel: [HYPOTHESE] Verrechnung von Anzahlungen in der Schlussrechnung +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Belegwesen (DownPayment) +Vorbedingung: Auftrag mit Anzahlungen wird weitergeführt. +Fakt: Es existiert eine Anzahlungskomponente (Receipts/DownPayment/DownPaymentBL.cs); ReceiptBL.ForwardReceipt validiert speziell, ob ein Lieferschein zu einem Auftrag mit Anzahlungen gehört (Region "Validate DeliveryList: Related to order with down payments?", Zeile 2483); die konkrete Verrechnungslogik der Anzahlung in der Schlussrechnung wurde nicht im Detail nachvollzogen. +Aussage: [HYPOTHESE] Die Software soll auf Aufträge geleistete Anzahlungen bei der Schlussrechnung automatisch verrechnen und die Weiterführung anzahlungsbehafteter Aufträge besonders prüfen. +Ergebnis: Schlussrechnung weist Anzahlung mindernd aus. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Region "Validate DeliveryList: Related to order with down payments?" (Zeile 2483) - Begründung: durchsetzende Sonderprüfung bei Weiterführung. + - [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/DownPayment/DownPaymentBL.cs (Existenz der Komponente) - Begründung: Anzahlungsmodul vorhanden, Verrechnungsdetail offen. +Prüfidee: Auftrag mit Anzahlung zur Rechnung weiterführen; erwartet: Anzahlungsposition wird verrechnet. +Tracelinks: SyRS-011, SyRS-014 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Anzahlungsprozesse sind im Projektgeschäft nötig. +Status: HYPOTHESE (fehlend: Detailanalyse von DownPaymentBL zur Verrechnungsregel) +``` + +``` +ID: SwRS-155 +Titel: [HYPOTHESE] SEPA-Lastschrifteinzug aus Rechnungen +Ebene: SwRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Buchhaltung, Bank +Vorbedingung: Rechnung mit aktivem SEPA-Kennzeichen und Mandat. +Fakt: Belege führen ein SEPA-Kennzeichen (IsSepaActive in InvoiceUploadBL-Datenabbild) und einen Mandatsbezug (IReceiptWithMandat, ReceiptsForBankAccount über MandatI3D in BankAccountBL); Zahlungseingangs-Übersichten filtern nach "directDebitCreated"; SEPA-Mandate werden online eingeholt (DsgvoBL.GetSepaContractPreviewPdf/ConfirmOnlinePdfDocument mit IBAN/BIC); die Erzeugung der SEPA-XML-Einzugsdatei wurde nicht lokalisiert. +Aussage: [HYPOTHESE] Die Software soll für rechnungsbezogene Lastschriften SEPA-Einzugsdateien auf Basis der hinterlegten Mandate erzeugen und den Erstellungsstatus je Zahlung führen. +Ergebnis: Bankfähige SEPA-Datei; Kennzeichnung eingezogener Zahlungen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Accounting/BankAccountBL.cs, ReceiptsForBankAccount (IReceiptWithMandat, MandatI3D) - Begründung: Mandatsbindung der Belege ist durchgesetzt. + - [SEKUNDÄR] src/backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentBL.cs, GetIncomingPaymentLogOverview(bool? directDebitCreated); Administration/Documents/Dsgvo/DsgvoBL.cs (SEPA-Mandatseinholung) - Begründung: Statusfelder und Mandatprozess belegen den Lastschriftprozess indirekt. +Prüfidee: Rechnung mit Mandat einziehen; erwartet: SEPA-XML mit Mandatsreferenz, Status directDebitCreated. +Tracelinks: SyRS-032, SyRS-021 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Lastschrift ist Standardzahlweg. +Status: HYPOTHESE (fehlend: durchsetzende SEPA-XML-Erzeugung; vermutlich im Gateway/OnlineBanking, nicht verifiziert) +``` + +``` +ID: SwRS-156 +Titel: [HYPOTHESE] Webshop-Sortiment aus Kunden-Sonderpreisen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Endkunde (WebCart) +Vorbedingung: Web-Account ist angemeldet; Sonderpreise sind gepflegt. +Fakt: Die Entwicklerdokumentation beschreibt, dass WebCart-Artikel aus den „Sonderpreisen" des Kunden stammen; eine Komponente für Kunden-Sonderartikel existiert (Support/CustomerSpecialArticleBL.cs); die durchsetzende Sortimentsabfrage des Shops wurde nicht im Code verifiziert. +Aussage: [HYPOTHESE] Das System soll im Kundenportal-Shop genau die Artikel anbieten, für die der Kunde Sonderpreise besitzt, zu diesen Preisen. +Ergebnis: Kundenindividuelles Shopsortiment. +Belege: + - [SEKUNDÄR] src/backend/Centron.BL/Sales/Support/CustomerSpecialArticleBL.cs (Existenz) - Begründung: Sonderartikelkomponente vorhanden. + - [KONTEXT] README.md, Abschnitt WebCart ("The available articles come from the customers 'Sonderpreise'") - Begründung: dokumentierte Sollregel. +Prüfidee: Web-Account ohne Sonderpreise; erwartet: leerer Shop; mit Sonderpreis: Artikel zum Sonderpreis. +Tracelinks: SyRS-045 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kernregel des B2B-Shops; in Folgeiteration im Nexus-Code verifizieren. +Status: HYPOTHESE (fehlend: durchsetzende Sortiments-/Preisabfrage im WebCart-Code) +``` + +``` +ID: SwRS-157 +Titel: [HYPOTHESE] Bidirektionale Exchange-Terminsynchronisation +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Exchange-Server, Kalender +Vorbedingung: Kalender-Synchronisation ist konfiguriert. +Fakt: EwsCalendarAccess kapselt Exchange-Kalenderzugriffe; CalendarBL persistiert Synchronisationseinstellungen; docs/features/exchange-sync-bugprotokoll.md dokumentiert Fehlerfälle einer Terminsynchronisation; Richtung und Konfliktverhalten der Synchronisation wurden nicht aus dem Code verifiziert. +Aussage: [HYPOTHESE] Das System soll Termine zwischen c-entron und Exchange in beide Richtungen synchronisieren und Konflikte deterministisch auflösen. +Ergebnis: Konsistente Termine in beiden Systemen. +Belege: + - [SEKUNDÄR] src/backend/Centron.BL/Mail/Exchange/EwsHelper/EwsCalendarAccess.cs; Calendar/CalendarBL.cs, UpdateCalendarSynchronizationSettings - Begründung: Zugriffs- und Konfigurationskomponenten vorhanden. + - [KONTEXT] docs/features/exchange-sync-bugprotokoll.md - Begründung: dokumentierte Sync-Praxis inkl. bekannter Fehler. +Prüfidee: Termin in Exchange ändern; erwartet: Änderung erscheint in c-entron (und umgekehrt). +Tracelinks: SyRS-035, SyRS-029 +Konsolidierung: Kandidat: SwRS-104 (Graph-Anbindung in ScheduleBL) - zwei Sync-Technologien (EWS vs. Graph) +Übernahmewürdigkeit: übernehmen - Kalendersync wird erwartet; Technologie auf Graph heben. +Status: HYPOTHESE (fehlend: durchsetzende Sync-Engine mit Richtungs-/Konfliktlogik) +``` + +``` +ID: SwRS-158 +Titel: [HYPOTHESE] Fernwartungsstart (Supremo/Remote-Desktop) aus dem Arbeitsplatz +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Support-Mitarbeiter +Vorbedingung: Fernwartungswerkzeug ist installiert. +Fakt: MyDay enthält eine Supremo-Komponente (MyDay/Supremo.cs); im Repo liegen Remote-Desktop-Assemblies (assemblies/remote-desktop); der konkrete Aufruf-/Sitzungsfluss wurde nicht analysiert. +Aussage: [HYPOTHESE] Das System soll Fernwartungssitzungen (z. B. Supremo) direkt aus der Arbeitsoberfläche zum ausgewählten Kunden starten. +Ergebnis: Fernwartung ohne Werkzeugwechsel. +Belege: + - [SEKUNDÄR] src/backend/Centron.BL/MyDay/Supremo.cs; assemblies/remote-desktop - Begründung: Komponenten vorhanden, Ablauf offen. +Prüfidee: Fernwartung aus MyDay starten; erwartet: Sitzung zum Kundengerät. +Tracelinks: SyRS-029, SyRS-030 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Supporteffizienz; Werkzeugwahl im Zielsystem prüfen. +Status: HYPOTHESE (fehlend: Analyse des Supremo-Aufrufs) +``` + diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/SyRS.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/SyRS.md new file mode 100644 index 00000000..fe98938d --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/SyRS.md @@ -0,0 +1,1030 @@ +# SyRS – System Requirements Specification +**System:** c-entron ERP-Suite | **Quelle:** Statische Codeanalyse | **Lauf:** 2026-08-27 + +Systemanforderungen (Systemverhalten, Schnittstellen, Performance, Sicherheit). Jede SyRS-Anforderung referenziert ihre StRS-Anforderung. + +--- + +``` +ID: SyRS-001 +Titel: Gruppenbasierte Benutzerrechteprüfung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System (Rechteprüfung), Benutzer +Vorbedingung: Benutzer ist angemeldet; Rechte sind Rechtegruppen zugeordnet, Benutzer sind Mitglieder von Rechtegruppen. +Fakt: Die effektiven Rechte eines Benutzers werden per SQL über die Tabellen dbo.Sichtrus (Gruppe→Recht) und dbo.Sichmemb (Gruppe→Benutzer) ermittelt; die Prüfung erfolgt über numerische Rechte-IDs und wird pro Benutzer im Session-Cache gehalten. +Aussage: Das System soll Funktionsberechtigungen ausschließlich über die Mitgliedschaft des Benutzers in Rechtegruppen ermitteln, denen einzelne, eindeutig nummerierte Rechte zugeordnet sind. +Ergebnis: Eine Funktion wird nur ausgeführt bzw. angezeigt, wenn mindestens eine Gruppe des Benutzers das zugehörige Recht enthält. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methoden HasUserRight(int,int) und GetAllAppRightsFromUser(int) mit SQL "SELECT st.Recht ... FROM dbo.Sichtrus st INNER JOIN dbo.Sichmemb sm ON sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D" - Begründung: durchsetzende Stelle der Rechteermittlung; die Prüfung rights.Contains(rightID) entscheidet über die Berechtigung. + - [SEKUNDÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs (2819 Zeilen Rechtekonstanten, z. B. RIGHT_RECHNUNG=40003) - Begründung: belegt den systemweiten Katalog numerischer Rechte. + - [KONTEXT] CentronRights.md - Begründung: dokumentiert die fachliche Bedeutung einzelner Rechte inkl. restriktiver Rechte. +Prüfidee: Benutzer ohne Gruppenzuordnung zu einem Recht ruft die geschützte Funktion auf; erwartet: Ablehnung mit Fehlermeldung "Benutzer hat nicht die passenden Rechte." (AppRightsBL.HasUserRightWithDefaultMessage). +Tracelinks: StRS-012; SwRS-001, SwRS-008 +Konsolidierung: Kandidat: SyRS-002 (getrenntes Rechtemodell für Web-Accounts bildet denselben fachlichen Gegenstand "Berechtigung" in zweiter Datenhaltung ab) +Übernahmewürdigkeit: übernehmen - gruppenbasierte Berechtigungsvergabe ist fachlicher Kern; numerische Alt-IDs können ersetzt werden. +Status: belegt +``` + +``` +ID: SyRS-002 +Titel: Getrenntes Rechtemodell für Web-Accounts +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Web-Account (Endkunden-Login), System +Vorbedingung: Ein Web-Account (Kundenzugang, z. B. für Shop/Portal) existiert. +Fakt: Rechte von Web-Accounts werden nicht über Sichtrus/Sichmemb, sondern direkt über die Tabelle WebAccountsRights (WebAccountsI3D→WebRightsI3D) geprüft. +Aussage: Das System soll für externe Web-Zugänge (Kunden-Accounts) ein eigenes, vom internen Mitarbeiter-Rechtemodell getrenntes Berechtigungsmodell führen. +Ergebnis: Web-Accounts erhalten nur explizit zugewiesene Web-Rechte; interne Rechte wirken für sie nicht. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methoden HasWebAccountRight(WebAccount,int) und GetAllWebRightsFromWebAccount(int) mit SQL auf WebAccountsRights - Begründung: durchsetzende Prüfstelle rights.Contains(rightI3D) für Web-Accounts. +Prüfidee: Web-Account ohne Eintrag in WebAccountsRights für ein Web-Recht ruft die Funktion auf; erwartet: Ablehnung. +Tracelinks: StRS-019, StRS-012; SwRS-001 +Konsolidierung: Kandidat: SyRS-001 (zwei getrennte Datenhaltungen für den fachlichen Gegenstand "Berechtigung"; im Zielsystem prüfen, ob ein einheitliches Rollenmodell mit Benutzerkreis-Trennung genügt) +Übernahmewürdigkeit: übernehmen - Trennung interner und externer Berechtigungen bleibt fachlich erforderlich, technische Vereinheitlichung möglich. +Status: belegt +``` + +``` +ID: SyRS-003 +Titel: Ticketbasierte Sitzungen mit Lizenzprüfung bei Anmeldung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Benutzer, Anmeldedienst, Lizenzmanager +Vorbedingung: Benutzer authentifiziert sich erfolgreich; die anfragende Anwendung ist über eine Application-GUID (ApplicationKind) identifiziert. +Fakt: Nach erfolgreicher Authentifizierung wird ein bestehendes Sitzungsticket wiederverwendet oder - nach LicenseManager.CheckLicense(applicationKind, appVersion, user) - ein neues Ticket erzeugt; bei erschöpften Lizenzen wird die Anmeldung abgelehnt; Login-IP/Maschinenname werden gespeichert. +Aussage: Das System soll Sitzungen über Tickets verwalten und vor der Ticketvergabe prüfen, ob für die anmeldende Anwendung eine freie Lizenz verfügbar ist. +Ergebnis: Pro Benutzer/Anwendung/Maschine existiert höchstens ein aktives Ticket; ohne freie Lizenz keine neue Sitzung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, Methode AuthenticateUser(...): Aufrufkette GetExistingTicket → LicenseManager.CheckLicense → CreateNewTicket → SetLoginIP, innerhalb lock(_getExistingOrCreateTicketLock) - Begründung: durchsetzende Stelle der Ticket- und Lizenzlogik inkl. Fehlerrückgabe bei Lizenzmangel. + - [PRIMÄR] src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, Methode CheckLicense(ApplicationKind, string, LoggedInUser) - Begründung: prüft Lizenz-GUID und Versionsbeschränkung der signaturvalidierten Lizenzdatei. +Prüfidee: Anmeldung mit ausgeschöpfter Lizenzanzahl für die Application-GUID; erwartet: Fehlerresultat statt Ticket; zweite Anmeldung desselben Benutzers/derselben Maschine liefert dasselbe Ticket. +Tracelinks: StRS-013, StRS-014; SwRS-005 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Sitzungs- und Lizenzsteuerung bleibt erforderlich; im SaaS-Zielsystem als Abonnement-/Seat-Prüfung. +Status: belegt +``` + +``` +ID: SyRS-004 +Titel: Mehrere Authentifizierungsverfahren +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Benutzer, Anmeldedienst +Vorbedingung: Anmeldedaten bzw. Identitätsnachweis liegen vor. +Fakt: Im Ordner Administration/Logins/Auth existieren Authenticator-Implementierungen: BasicAuthenticator (Benutzername/Passwort), ActiveDirectoryAuthenticator, OpenIdConnectAuthenticator (inkl. OpenIdConnectAccountConnector, EntraID), WebAccountAuthenticator, FallbackAuthenticator und eine AuthenticatorFactory. +Aussage: Das System soll die Anmeldung wahlweise über lokales Passwort, Active Directory, OpenID Connect (Entra ID) sowie über Web-Accounts unterstützen; das Verfahren wird zentral über eine Factory gewählt. +Ergebnis: Benutzer werden je nach Konfiguration über das passende Verfahren authentifiziert und erhalten denselben Sitzungs-/Ticketmechanismus. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs sowie BasicAuthenticator.cs, ActiveDirectoryAuthenticator.cs, OpenIdConnectAuthenticator.cs, WebAccountAuthenticator.cs (abstrakte Basis Authenticator.cs, Methode Authenticate()) - Begründung: die Klassenfamilie implementiert die Verfahren und ist die durchsetzende Stelle der Verfahrenswahl. +Prüfidee: Für jede konfigurierte Verfahrensart eine Anmeldung durchführen; erwartet: identisches Ticketformat und identische nachgelagerte Rechteprüfung. +Tracelinks: StRS-013; SwRS-002, SwRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Verfahrensvielfalt (lokal + IdP) ist für SaaS weiterhin nötig; AD-Variante ggf. durch reines OIDC ersetzen. +Status: belegt +``` + +``` +ID: SyRS-005 +Titel: Zwei-Faktor-Authentifizierung (RADIUS oder E-Mail-Link) +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Benutzer, Anmeldedienst, 2FA-Validator +Vorbedingung: Basisauthentifizierung erfolgreich; 2FA ist in der Webservice-Konfiguration aktiviert. +Fakt: Nach erfolgreicher Passwortprüfung ruft BasicAuthenticator TwoFactorAuthBL.ValidateTwoFactor auf; schlägt sie fehl, wird die Anmeldung mit Fehlercode TwoFactorAuthFailed abgelehnt. Der Validator wird per Konfiguration gewählt: RadiusServer → RadiusTwoFactorValidator, EmailLink → EmailTwoFactorValidator. +Aussage: Das System soll nach der Passwortprüfung optional einen zweiten Faktor erzwingen, wahlweise über einen RADIUS-Server oder einen per E-Mail zugestellten Bestätigungslink. +Ergebnis: Ohne bestandene Zwei-Faktor-Prüfung kommt keine Sitzung zustande. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, AuthenticateInternal(): Aufruf _twoFactorAuthBL.ValidateTwoFactor(...) mit Abbruch bei Status != Success - Begründung: durchsetzende Stelle, die den Login ohne zweiten Faktor verweigert. + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs, GetTwoFactorValidator(): switch über WebServiceConfigHelper.Current.TwoFactorAuthType (RadiusServer/EmailLink) - Begründung: belegt die beiden unterstützten Verfahren. +Prüfidee: Login mit korrektem Passwort, aber abgelehntem zweitem Faktor; erwartet: Fehler "Die Zwei-Faktor-Authentifizierung ist fehlgeschlagen." und kein Ticket. +Tracelinks: StRS-013; SwRS-002, SwRS-003 +Konsolidierung: Kandidat: SwRS-011 (separates TOTP-Modul TwoFactorAuthenticator bildet einen zweiten 2FA-Mechanismus ab) +Übernahmewürdigkeit: übernehmen - 2FA ist sicherheitlich erforderlich; Verfahren im Zielsystem auf Standard (TOTP/WebAuthn) heben. +Status: belegt +``` + +``` +ID: SyRS-006 +Titel: Zeitgesteuerte Deaktivierung von Benutzerkonten +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator, Anmeldedienst +Vorbedingung: Benutzerkonto existiert (Tabelle Sichbenu); Deaktivierungskennzeichen oder -zeitraum ist gesetzt. +Fakt: ValidateAppUser lehnt die Anmeldung ab, wenn IsAccountDisabled gesetzt ist oder das Tagesdatum im Intervall AccountDisabledFromDate/AccountDisabledToDate liegt (auch bei nur einseitig gesetzten Grenzen). +Aussage: Das System soll Benutzerkonten dauerhaft oder für einen definierten Zeitraum (von/bis) deaktivieren können; deaktivierte Konten dürfen sich nicht anmelden. +Ergebnis: Anmeldeversuche deaktivierter Konten werden mit Fehlermeldung abgewiesen und protokolliert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, Methode ValidateAppUser(AppUser): Prüfungen auf user.IsAccountDisabled sowie AccountDisabledFromDate/AccountDisabledToDate gegen DateTime.Today - Begründung: durchsetzende Bedingung, die den Login verweigert. +Prüfidee: Konto mit AccountDisabledFromDate = gestern, ohne ToDate: Anmeldung heute wird abgelehnt; Konto mit AccountDisabledToDate = gestern: Anmeldung heute wird angenommen. +Tracelinks: StRS-012, StRS-013 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - befristete Deaktivierung (z. B. Austritt, Sperrfristen) ist gängige Anforderung. +Status: belegt +``` + +``` +ID: SyRS-007 +Titel: Anwendungsbezogene Anmelderechte (erforderliche und ausschließende Rechte) +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Benutzer, Anmeldedienst +Vorbedingung: Anmeldende Anwendung ist als ApplicationKind mit optionalem RequiredRight/DisallowingRight definiert. +Fakt: ValidateRights verweigert die Anmeldung, wenn der Benutzer das DisallowingRight der Anwendung besitzt oder das RequiredRight nicht besitzt. +Aussage: Das System soll je Client-Anwendung (z. B. Desktop, Web, Mobile) steuern können, welche Benutzer sich dort anmelden dürfen - über ein erforderliches Recht und ein Verbotsrecht. +Ergebnis: Benutzer ohne erforderliches Recht bzw. mit Verbotsrecht erhalten für diese Anwendung kein Ticket. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, Methode ValidateRights(ApplicationKind, LoggedInUser): Prüfungen applicationKind.DisallowingRight/RequiredRight gegen AppRightsBL.HasUserRight - Begründung: durchsetzende Prüfstelle vor der Ticketvergabe. +Prüfidee: Benutzer mit DisallowingRight der Anwendung meldet sich an; erwartet: Fehlermeldung "Login nicht erlaubt" ohne Ticket. +Tracelinks: StRS-012, StRS-013; SyRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - kanalbezogene Zugangssteuerung bleibt sinnvoll. +Status: belegt +``` + +``` +ID: SyRS-008 +Titel: Ausliefern von Standard-Rechtegruppen (Rollenvorlagen) +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Installation bzw. Zurücksetzen der Rechtestruktur wird angestoßen. +Fakt: Eine eingebettete Ressource definiert Standardgruppen mit Rechtelisten (u. a. "Alle Benutzer", "Buchhaltung", "c-entron DSGVO Löschrecht", "Einkauf Leitung/Mitarbeiter", "Logistik Leitung/Mitarbeiter", "Service Leitung/Mitarbeiter", "Vertrieb Leitung/Mitarbeiter"); AppRightsBL.ResetDefaultRightGroups stellt diese Struktur her. +Aussage: Das System soll vordefinierte Rechtegruppen für typische Rollen (Buchhaltung, Einkauf, Logistik, Service, Vertrieb, jeweils Leitung/Mitarbeiter, sowie ein DSGVO-Löschrecht) bereitstellen und auf Anforderung zurücksetzen können. +Ergebnis: Nach dem Zurücksetzen entsprechen die Standardgruppen exakt der ausgelieferten Rechtezuordnung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode ResetDefaultRightGroups(AppUser) mit GetDefaultRightsStructureFileContent() (Manifest-Ressource) - Begründung: durchsetzende Stelle, die die Standardstruktur schreibt. + - [SEKUNDÄR] src/backend/Centron.BL/Administration/Rights/DefaultRightsStructure.txt - Begründung: enthält die konkreten Rollen und Rechtelisten. +Prüfidee: ResetDefaultRightGroups ausführen und Gruppenbestand mit DefaultRightsStructure.txt abgleichen. +Tracelinks: StRS-012; SwRS-008 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Rollenvorlagen erleichtern Einführung; Rechtelisten im Zielsystem neu schneiden. +Status: belegt +``` + +``` +ID: SyRS-009 +Titel: Änderungsnachverfolgung an allen Geschäftsobjekten +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Nachvollziehbarkeit/Accountability nach ISO 25010: Sicherheit – Verantwortlichkeit) +Akteur: System +Vorbedingung: Ein Geschäftsobjekt wird angelegt oder geändert. +Fakt: Beim Speichern setzt die Persistenzbasis auf jedem DBEntity die Felder CreatedBy/CreatedDate/CreatedVersion (nur bei Neuanlage) und ChangedBy/ChangedDate/ChangedVersion (bei jeder Änderung) auf den aktuellen Mitarbeiter, Zeitstempel und die Programmversion. +Aussage: Das System soll für jedes Geschäftsobjekt festhalten, wer es wann mit welcher Programmversion angelegt und zuletzt geändert hat. +Ergebnis: Jeder Datensatz trägt vollständige Erstellungs- und Änderungsmetadaten. +Belege: + - [PRIMÄR] src/backend/Centron.BL/DBBaseBL.cs, Methode DoBeforeSave(T,LoggedInUser,bool): Zuweisung CreatedBy/CreatedDate/CreatedVersion bzw. ChangedBy/ChangedDate/ChangedVersion - Begründung: zentrale durchsetzende Stelle für alle über DBBaseBL gespeicherten Entitäten. + - [PRIMÄR] src/backend/Centron.BL/BaseBL.cs, Methoden SetBaseProperties/SetBasePropertiesDBEntity - Begründung: gleiche Regel für den älteren Speicherpfad. +Prüfidee: Objekt anlegen und ändern; erwartet: CreatedBy bleibt stabil, ChangedBy/ChangedDate/ChangedVersion werden bei jeder Änderung aktualisiert. +Tracelinks: StRS-030; SwRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Änderungsmetadaten sind Compliance-Grundlage. +Status: belegt +``` + +``` +ID: SyRS-010 +Titel: Transaktionale Speicherung mit fachlichen Validierungshaken +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Zuverlässigkeit (Fehlertoleranz, Wiederherstellbarkeit) +Akteur: System (Persistenzschicht) +Vorbedingung: Ein Geschäftsobjekt wird über die Geschäftslogik gespeichert. +Fakt: DBBaseBL.Save kapselt jede Speicherung in eine Transaktion (StartTransaction/Commit/Rollback), bricht bei fehlgeschlagenen Validierungshaken (DoBeforeSave, DoBeforeStoreTrans, DoAfterStoreTrans) mit Rollback ab und protokolliert Ausnahmen über NLog. +Aussage: Das System soll Speicheroperationen atomar ausführen: Schlägt eine fachliche Prüfung oder die Persistierung fehl, werden alle Teiländerungen zurückgerollt und der Fehler als Ergebnisobjekt zurückgemeldet. +Ergebnis: Kein teilweise gespeicherter Zustand; Fehler werden geloggt und dem Aufrufer strukturiert (Result) gemeldet. +Belege: + - [PRIMÄR] src/backend/Centron.BL/DBBaseBL.cs, Methode Save(T,LoggedInUser,bool): Transaktionsklammer mit RollbackTransaction in allen Fehlerpfaden und Result.FromException(e) - Begründung: durchsetzende Stelle der Atomarität. +Prüfidee: Speichern mit absichtlich fehlschlagendem DoAfterStoreTrans; erwartet: Rollback, kein Datensatz in DB, Result mit Fehlerstatus. +Tracelinks: StRS-030; SwRS-006 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Grundprinzip der Datenintegrität. +Status: belegt +``` + +``` +ID: SyRS-011 +Titel: Durchgängige Belegkette mit definierten Weiterführungswegen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertriebsmitarbeiter, System (Belegwesen) +Vorbedingung: Ein Quellbeleg existiert und ist nicht gesperrt. +Fakt: Jede Belegart definiert per IReceiptSpecificLogic ihre zulässigen Weiterführungen: Angebot → Auftrag/Lieferschein/Rechnung; Auftrag → Lieferschein/Rechnung/Vertrag; Lieferschein → Abholliste/Rechnung; Rechnung → Gutschrift; Gutschrift und Abholliste sind Endpunkte; Rechnung kann aus Lieferschein, Auftrag, Angebot oder Vertrag entstehen. +Aussage: Das System soll Verkaufsbelege nur entlang der definierten Belegkette weiterführen (z. B. Angebot zu Auftrag, Lieferschein zu Rechnung, Rechnung zu Gutschrift) und dabei Positionen, Konditionen und Bezüge übernehmen. +Ergebnis: Weiterführungen außerhalb der Matrix sind nicht möglich; die Belegkette bleibt lückenlos nachvollziehbar (ReceiptProgression). +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/*/[Art]SpecificLogic.cs, Methoden CanBeForwardedFrom()/CanBeForwardedInto() (OfferSpecificLogic.cs:313f, OrderSpecificLogic.cs:256f, DeliveryListSpecificLogic.cs:257f, InvoiceSpecificLogic.cs:279f, CreditVoucherSpecificLogic.cs:267f, PickupListSpecificLogic.cs:262f, ContractSpecificLogic.cs:225ff) - Begründung: die Matrizen sind die durchsetzende Definition der zulässigen Übergänge. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, ForwardReceipt(...) mit Region "Validate Forwarding" (ab Zeile 2464) - Begründung: führt die Weiterführung aus und validiert sie. +Prüfidee: Versuch, eine Gutschrift in einen Auftrag weiterzuführen; erwartet: Ablehnung. Angebot→Auftrag→Lieferschein→Rechnung durchspielen; erwartet: Positionsübernahme und Fortschrittsanzeige. +Tracelinks: StRS-002, StRS-003; SwRS-013 +Konsolidierung: Kandidat: Das ältere Belegmodell unter src/backend/Centron.BL/Sales/CustomerAssets (OfferBL/OrderBL/InvoiceBL/DeliveryListBL) bildet dieselben Belegarten in zweiter Implementierung ab; im Zielsystem zu einem Belegmodell zusammenführen. +Übernahmewürdigkeit: übernehmen - Belegkette ist fachlicher Kern des Vertriebsprozesses. +Status: belegt +``` + +``` +ID: SyRS-012 +Titel: Nummernkreise je Belegart, Mandant und Filiale +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System (Belegwesen), Administrator +Vorbedingung: Nummernkreise (NumberGroup) sind je Mandant/Filiale gepflegt; ein Beleg wird erstmalig gespeichert. +Fakt: Die Belegart bestimmt den NumberGroupEnum (u. a. Offer/CashOffer, Order, DeliveryList, Invoice/CashInvoice/InternalInvoice, CreditVoucher, PickupList, Contract); MandatoryBL.GetNumberGroup löst den Nummernkreis in der Kaskade Mitarbeiter → Filiale → Mandant → Standardmandant auf; NumberGroupBL.GetNextNumber vergibt die nächste Nummer. +Aussage: Das System soll Belegnummern aus getrennten, je Mandant und Filiale konfigurierbaren Nummernkreisen pro Belegart vergeben; Barbelege und interne Rechnungen erhalten eigene Kreise. +Ergebnis: Eindeutige, kreisgebundene Belegnummern; filialspezifische Nummernvergabe, wo gepflegt, sonst Fallback auf den Mandanten. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, UpdateReceiptNumber(IReceiptBase,bool) (Zeile 7265ff) - Begründung: durchsetzende Vergabestelle inkl. Filialauflösung. + - [PRIMÄR] src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs, GetNumberGroup(NumberGroupEnum,...) (Zeile 55ff) mit Fallback-Kaskade - Begründung: definiert die Auflösungsreihenfolge. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, GetNumberGroup(IReceiptBase) (CashInvoice/InternalInvoice/Invoice) - Begründung: belegt die belegartspezifischen Kreise. +Prüfidee: Rechnung in Filiale mit eigenem Kreis speichern → Nummer aus Filialkreis; Filiale ohne Kreis → Nummer aus Mandantenkreis. +Tracelinks: StRS-003, StRS-012; SwRS-010, SwRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - GoBD-relevante Kernfunktion. +Status: belegt +``` + +``` +ID: SyRS-013 +Titel: Bestandswirkung der Belege +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System (Belegwesen, Lager) +Vorbedingung: Beleg mit Artikelpositionen wird gebucht. +Fakt: Ob ein Beleg Lagerbestand verändert, definiert die Belegart: Lieferschein und Rechnung buchen ab (UpdatesStock=true, IncrementsStock=false), Gutschrift und Abholliste buchen zu (beide true), Angebot/Auftrag/Vertrag sind bestandsneutral (UpdatesStock=false). +Aussage: Das System soll Lagerbestände ausschließlich durch bestandswirksame Belegarten verändern: Abbuchung durch Lieferschein/Rechnung, Zubuchung durch Gutschrift/Abholliste. +Ergebnis: Bestandsveränderungen sind stets einem Beleg zuzuordnen; bestandsneutrale Belege verändern keinen Bestand. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/*/[Art]SpecificLogic.cs, Methoden UpdatesStock()/IncrementsStock() (DeliveryListSpecificLogic.cs:185-188, InvoiceSpecificLogic.cs:224-227, CreditVoucherSpecificLogic.cs:199-202, PickupListSpecificLogic.cs:195-198, OfferSpecificLogic.cs:203ff, OrderSpecificLogic.cs:187-190) - Begründung: belegartweise Definition der Bestandswirkung. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptArticleBookingBL.cs - Begründung: ausführende Buchungskomponente. +Prüfidee: Auftrag speichern → Bestand unverändert; denselben Auftrag zu Lieferschein weiterführen und speichern → Bestand um Positionsmenge reduziert; Gutschrift aus Rechnung → Bestand erhöht. +Tracelinks: StRS-002, StRS-008, StRS-024; SwRS-014 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kernregel der Warenwirtschaft. +Status: belegt +``` + +``` +ID: SyRS-014 +Titel: Mindestpreisschutz mit autorisierter Überstimmung +Ebene: SyRS +Typ: funktional (Abrechnung/Fakturierung) +Qualitätsmerkmal: +Akteur: Vertriebsmitarbeiter, autorisierender Benutzer +Vorbedingung: Kundenbeleg mit Artikelpositionen wird gespeichert; für Artikel ist ein Mindestpreis (Article.MinPrice) gepflegt. +Fakt: Beim Speichern prüft CheckArticleMinPrices jede Artikelposition gegen den Mindestpreis; Unterschreitungen werden nur akzeptiert, wenn der Benutzer das Recht ALLOW_IGNORE_MINIMUM_PRICE besitzt oder sich ein zweiter Benutzer mit diesem Recht per Benutzername/Passwort re-authentifiziert; alternativ wird der Positionspreis auf den Mindestpreis angehoben. +Aussage: Das System soll den Verkauf unter Mindestpreis verhindern und Ausnahmen nur nach dem Vier-Augen-Prinzip (Recht ALLOW_IGNORE_MINIMUM_PRICE, ggf. durch Zweitanmeldung) zulassen. +Ergebnis: Belege mit Preisunterschreitung werden abgewiesen, korrigiert oder autorisiert gespeichert; Autorisierungen werden geloggt. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CheckArticleMinPrices(...) (ab Zeile 9037): Rechteprüfung UserRightsConst.Sales.Customer.CustomerCommon.Offer.ALLOW_IGNORE_MINIMUM_PRICE, Re-Authentifizierung über AuthenticatorFactory, Preisvergleich NetPrice >= MinPrice - Begründung: vollständige durchsetzende Prüf- und Ausnahmelogik. +Prüfidee: Beleg mit Position unter Mindestpreis ohne Recht speichern; erwartet: Dialog/Fehler; mit Zweitanmeldung eines berechtigten Benutzers; erwartet: Speicherung mit unverändertem Preis. +Tracelinks: StRS-003; SwRS-015 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Margenschutz ist fachlich gewollt; Re-Authentifizierung per Passwort im Zielsystem durch moderne Bestätigung ersetzen (Code-Kommentar: mit Azure-Authentifizierung nicht mehr funktionsfähig). +Status: belegt +``` + +``` +ID: SyRS-015 +Titel: Belegsperren und optimistische Nebenläufigkeitskontrolle +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Mehrere Benutzer, System (Belegwesen) +Vorbedingung: Mehrere Benutzer arbeiten an demselben Beleg. +Fakt: Belege werden über belegartspezifische Locks (z. B. AssetLockBL, TryLockReceipt/UnLockReceipt, CreateLock/RemoveLock mit onlyIfLockedByCurrentUser) exklusiv gesperrt; Feld-Updates (UpdateReceiptInformation, UpdateReceiptIsPaid u. a.) verlangen zusätzlich eine Guid concurrencyControlGuid zur Erkennung konkurrierender Änderungen. +Aussage: Das System soll Belege beim Bearbeiten für andere Benutzer sperren und Einzelfeld-Änderungen über ein Nebenläufigkeits-Token gegen zwischenzeitliche Fremdänderungen absichern. +Ergebnis: Kein gegenseitiges Überschreiben; fremdgesperrte Belege sind nur lesbar; veraltete Änderungen werden abgewiesen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateLock/RemoveLock (Zeile 3160ff) und Signaturen UpdateReceipt*(..., Guid? concurrencyControlGuid, ...) (z. B. Zeile 4790ff) - Begründung: durchsetzende Sperr- und Prüfparameter. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, TryLockReceipt/UnLockReceipt mit AssetLockBL - Begründung: belegartspezifische Sperrimplementierung. +Prüfidee: Beleg durch Benutzer A sperren, Änderungsversuch durch B; erwartet: Ablehnung; Feld-Update mit veralteter concurrencyControlGuid; erwartet: Konfliktfehler. +Tracelinks: StRS-002; SwRS-006 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Mehrbenutzerschutz bleibt nötig; Mechanik im Web ggf. anders (etags/Versionen). +Status: belegt +``` + +``` +ID: SyRS-016 +Titel: Belegversionierung +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertriebsmitarbeiter, System +Vorbedingung: Ein gespeicherter Beleg soll geändert werden, ohne den bisherigen Stand zu verlieren. +Fakt: ReceiptBL.CreateNewVersion erzeugt zu einem Beleg eine neue Versionsnummer; historische Stände werden als eigene Versionsentitäten (z. B. ReceiptInvoiceVersion mit OriginalI3D+Version) gehalten und über GetReceiptVersionByI3D abrufbar. +Aussage: Das System soll zu Belegen Versionen führen: Ältere Stände bleiben unverändert abrufbar, Änderungen erzeugen eine neue Version. +Ergebnis: Jede Belegversion ist eindeutig über Ursprungsbeleg und Versionsnummer adressierbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateNewVersion(CentronObjectKindNumeric,int,...) (Zeile 3063ff) - Begründung: durchsetzende Versionslogik. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, GetReceiptVersionByI3D: Query auf ReceiptInvoiceVersion (OriginalI3D == receiptI3D && Version == version) - Begründung: belegt das Versionsdatenmodell. +Prüfidee: Rechnung ändern mit neuer Version; erwartet: alte Version weiterhin abrufbar, Ausdruck referenziert die Version. +Tracelinks: StRS-002, StRS-030; SwRS-013 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Versionshistorie ist für Nachvollziehbarkeit und GoBD relevant. +Status: belegt +``` + +``` +ID: SyRS-017 +Titel: Persönliche API-Zugriffstokens mit Ablauf und Protokollierung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Mitarbeiter, externes System, Webservice +Vorbedingung: Mitarbeiter erhält ein persönliches Zugriffstoken für die API. +Fakt: AccessTokenBL erzeugt Tokens mit kryptographischem Zufall (RandomNumberGenerator), speichert nur den SHA-256-Hash (TokenHash), unterstützt Ablaufdatum (ExpiresAt), prüft bei ValidateToken Aktivität und Ablauf und protokolliert Aktionen über AccessTokenLogBL (u. a. Created); die Anzahl aktiver Tokens wird gegen die Lizenz gezählt. +Aussage: Das System soll API-Zugriffe über persönliche, ablaufende Tokens autorisieren, die nur als Hash gespeichert und deren Lebenszyklus protokolliert wird. +Ergebnis: Kompromittierte Datenbank gibt keine Klartext-Tokens preis; abgelaufene/inaktive Tokens werden abgewiesen; Nutzung ist nachvollziehbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, CreatePersonalToken(...) (SHA-256-Hash, RandomNumberGenerator, ExpiresAt), ValidateToken(string,...) (Prüfung IsExpired/IsActive), _logBL.LogAction(...) - Begründung: durchsetzende Erzeugungs- und Prüf logik inkl. Hashing. +Prüfidee: Token mit ExpiresAt in der Vergangenheit validieren; erwartet: Ablehnung; DB-Inhalt enthält nur Hash, nicht das Token. +Tracelinks: StRS-013, StRS-028; SwRS-021 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Standardmechanismus für API-Zugriff. +Status: belegt +``` + +``` +ID: SyRS-018 +Titel: Steuerbare Hintergrunddienste mit Laufzeitüberwachung +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Hintergrunddienst +Vorbedingung: Ein benannter Hintergrunddienst ist registriert. +Fakt: BackgroundServiceBL verwaltet je Dienstname einen Datensatz mit IsEnabled, LastRunTime und StartTime; Dienste können aktiviert/deaktiviert und ihr letzter Lauf abgefragt werden (IsServiceEnabled, UpdateLastRunTime). +Aussage: Das System soll Hintergrunddienste einzeln aktivierbar/deaktivierbar führen und deren letzte Laufzeit persistieren. +Ergebnis: Deaktivierte Dienste laufen nicht; Betriebszustand ist einsehbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/BackgroundServices/BackgroundServiceBL.cs, CreateOrUpdateBackgroundService/SetServiceEnabled/IsServiceEnabled/UpdateLastRunTime - Begründung: durchsetzende Steuer- und Statuslogik. +Prüfidee: Dienst deaktivieren; erwartet: IsServiceEnabled=false und kein weiterer Lauf; LastRunTime bleibt stehen. +Tracelinks: StRS-031; SwRS-024 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Betriebssteuerung der Automatisierung. +Status: belegt +``` + +``` +ID: SyRS-019 +Titel: KI-Assistenz mit konfigurierbarem Modellanbieter +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Benutzer (Support), KI-Dienst +Vorbedingung: KI-Einstellungen (API-Key, Standardmodell, optional Websuche) sind gepflegt. +Fakt: ArtificialIntelligenceBL verwaltet Prompt-Vorlagen und -Kategorien, liest/schreibt KI-Einstellungen (AiApiKey als LargeString, DefaultModel, WebSearchProvider, WebSearchApiKey AES-verschlüsselt) und erzeugt Ticket-Zusammenfassungen, Lösungsvorschläge und chronologische Ticketdetails (CreateTicketSummary, CreateSuggestedTicketSolutions u. a.). +Aussage: Das System soll KI-gestützte Zusammenfassungen und Lösungsvorschläge für Tickets bereitstellen, wobei Modellanbieter, Modell und Prompts konfigurierbar sind und API-Schlüssel verschlüsselt abgelegt werden. +Ergebnis: Support-Mitarbeiter erhalten generierte Zusammenfassungen; Schlüssel liegen nicht im Klartext. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/ArtificialIntelligence/ArtificialIntelligenceBL.cs, GetAISettings/UpdateAISettings (AESCryptoLogic().DecryptText für WebSearchApiKey), CreateTicketSummary/CreateSuggestedTicketSolutions/GetModels - Begründung: implementierende Stellen der KI-Funktionen und der Schlüsselablage. + - [SEKUNDÄR] src/backend/Centron.BL/ArtificialIntelligence/* (AiHttpModelCatalogClient, ClaudeCodeChatModelClient, AiModelRequest/Response, AiToolConstants) - Begründung: Anbindung der Modellanbieter. +Prüfidee: Ticket mit Verlauf zusammenfassen lassen; erwartet: generierter Text; DB-Inspektion: WebSearchApiKey nicht im Klartext. +Tracelinks: StRS-029; SwRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - KI-Unterstützung ist strategische Funktion. +Status: belegt +``` + +``` +ID: SyRS-020 +Titel: Verwaltung des Konten-/Adressstamms (Kunden und Lieferanten) +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertrieb, Einkauf, Verwaltung +Vorbedingung: Benutzer besitzt die jeweiligen Stammdatenrechte. +Fakt: AccountBL verwaltet Konten mit Kontotypen (Kunde/Lieferant, AccountTypeKind), Klassifikationen (CustomerClassification, SalesControlling, Branchen), Firmengruppen (AccountCompanyGroupDTO), Reaktivierung und Löschung; Adressen und Ansprechpartner werden über AccountAddressBL/AccountAddressContactBL geführt. +Aussage: Das System soll Geschäftspartner als Konten mit Typen (Kunde, Lieferant), Adressen, Ansprechpartnern, Klassifikationen und Firmengruppen-Zuordnung zentral verwalten. +Ergebnis: Ein Konto kann zugleich Kunde und Lieferant sein; alle Belege referenzieren denselben Stamm. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs, SaveAccount/GetAccount/DeleteAccount/ReactivateAccount/RemoveAccountTypeFromAccount - Begründung: implementierende Stammverwaltung inkl. Typenlogik. + - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountAddressBL.cs, AccountAddressContactBL.cs - Begründung: Adress- und Kontaktverwaltung. +Prüfidee: Konto als Kunde und Lieferant führen; erwartet: beide Rollen nutzbar, Entfernen einer Rolle über RemoveAccountTypeFromAccount. +Tracelinks: StRS-001, StRS-025; SwRS-020 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - zentraler Stammdatenkern. +Status: belegt +``` + +``` +ID: SyRS-022 +Titel: DSGVO-Funktionen: Löschkonzept und Datenbereinigung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Datenschutzbeauftragter, Administrator +Vorbedingung: Benutzer besitzt die DSGVO-Rechte; DSGVO-Modul ist lizenziert (ModuleFeatures.IsDsgvoDatabaseCleanupAvailable). +Fakt: DataSecurityBL bietet rechtegeschützte Bereinigungsstatistiken und -läufe (ACCESS_CLEANUP_DATABASE) sowie personenbezogene Löschung von Kontakten (DSGVO_DELETE_CONTACT); gelöschte Kontakte werden durch den Text "DSGVO: Auf Anfrage gelöscht." (optional mit Ausführendem und Zeitpunkt) ersetzt und in einem Löschprotokoll dokumentiert. +Aussage: Das System soll personenbezogene Daten auf Anfrage DSGVO-konform löschen bzw. anonymisieren, dies nur berechtigten Benutzern erlauben und jede Löschung protokollieren. +Ergebnis: Betroffene Kontakte sind anonymisiert; das Löschprotokoll weist Durchführenden und Zeitpunkt nach. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, DsgvoDeleteRightDeleteContacts (Rechteprüfung DSGVO_DELETE_CONTACT, DoDeleteContactPerson mit deleteProtocol), Konstanten DsgvoDeletedContactMessage* ; DataSecurityExecuteCleanUp (Rechteprüfung ACCESS_CLEANUP_DATABASE) - Begründung: durchsetzende Lösch-, Rechte- und Protokolllogik. + - [SEKUNDÄR] src/backend/Centron.BL/Administration/Rights/DefaultRightsStructure.txt, Gruppe "c-entron DSGVO Löschrecht" - Begründung: ausgelieferte Rollenvorlage. +Prüfidee: Kontakt DSGVO-löschen; erwartet: Ersatztext statt Personendaten, Protokolleintrag; ohne Recht: Ablehnung. +Tracelinks: StRS-030; SwRS-030 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - gesetzliche Pflicht. +Status: belegt +``` + +``` +ID: SyRS-023 +Titel: Zentrale typisierte Anwendungskonfiguration +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modifizierbarkeit) +Akteur: Administrator, alle Module +Vorbedingung: Einstellung ist im Einstellungskatalog definiert. +Fakt: AppSettingsConst ist ein zentraler Enum-Katalog (3044 Zeilen) aller Anwendungseinstellungen mit dokumentierten Feldern (Value/Text/ValueText/LargeValueText/ValueDecimal); AppSettingsBL/SettingsCollection liefern typisierte Zugriffe (GetBool/GetString/GetEnum); fachliche Regeln (z. B. Mahnstufen-Texte, Belegsperren nach Mahnstufe, Seriennummernpflicht) hängen an diesen Schaltern. +Aussage: Das System soll fachliches Verhalten über einen zentralen, typisierten Einstellungskatalog konfigurierbar machen, ohne Codeänderung je Installation. +Ergebnis: Installationen unterscheiden sich per Konfiguration; Einstellungen sind katalogisiert und dokumentiert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsBL.cs und SettingsCollection.cs - Begründung: zentrale Lese-/Schreiblogik. + - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs (u. a. DunningLevel1Text=100, CustomerAssetsLockedAfterDunningLevel=104, DBVersion=2) - Begründung: Katalog der Einstellungen mit fachlicher Bedeutung. +Prüfidee: Einstellung ändern (z. B. SaveWithoutAllSN) und Verhaltensänderung im abhängigen Modul nachweisen. +Tracelinks: StRS-032; SwRS-040 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Konfigurierbarkeit ist Produktkern; Katalog im Zielsystem bereinigen. +Status: belegt +``` + +``` +ID: SyRS-024 +Titel: Mehrmandanten- und Filialstruktur +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Verwaltung, alle Belegmodule +Vorbedingung: Mandanten (Mandator) und Filialen (Branch) sind gepflegt. +Fakt: MandatorBL/BranchBL verwalten Mandanten und Filialen; Filialen referenzieren ihren Mandanten (Branch.MandatorI3D); Nummernkreise, Belege und Mitarbeiter sind filial- bzw. mandantenbezogen; es existiert ein Standardmandant als Fallback; Filialen führen eigene Erlös-/Aufwandskonten (BranchRevenueAndExpenseAccountBL). +Aussage: Das System soll mehrere Mandanten mit untergeordneten Filialen abbilden; Belege, Nummernkreise und Kontenzuordnungen sollen je Filiale differenzierbar sein. +Ergebnis: Filialgenaue Beleg- und Kontensteuerung mit Mandanten-Fallback. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Company/MandatorBL.cs, BranchBL.cs, BranchRevenueAndExpenseAccountBL.cs; MandatoryBL.GetNumberGroupFromBranch (Branch.MandatorI3D-Kaskade) - Begründung: implementierende Struktur- und Fallback-Logik. +Prüfidee: Zwei Filialen mit eigenen Nummernkreisen und Erlöskonten anlegen; Belege je Filiale erhalten unterschiedliche Kreise/Konten. +Tracelinks: StRS-033; SwRS-012, SwRS-016, SwRS-027 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Mehrfirmenbetrieb ist für die Zielgruppe (Systemhäuser) üblich. +Status: belegt +``` + +``` +ID: SyRS-021 +Titel: FiBu-Übergabe (DATEV-Formate) mit Übertragungsnachweis +Ebene: SyRS +Typ: Schnittstelle (Abrechnung) +Qualitätsmerkmal: +Akteur: Buchhaltung, FiBu-System (DATEV), System +Vorbedingung: Exportkonfiguration ist gepflegt; zu übergebende Belege/Stammdaten liegen im Zeitraum. +Fakt: BookKeepingExportBL exportiert Debitoren-/Kreditorenstammdaten, Buchungsdaten aus Kunden- und Lieferantenbelegen sowie Kassenbuchdaten; unterstützte Zielformate umfassen DATEV ASCII und DATEV XML Online (Namespaces DatevAscii, DatevXmlOnline, DatevXMLOnline2020) sowie kundenspezifische Spaltenformate (BookKeepingExportCustomInterfaceColumn); je Objekt wird der Übertragungsstatus geführt (IsReceiptExported, transferred-Filter) und eine Exporthistorie gespeichert (GetBookKeepingExport*History). +Aussage: Das System soll Rechnungswesen-Daten (Stammdaten, Buchungssätze, Kassenbuch) in DATEV-kompatiblen Formaten exportieren, bereits übertragene Objekte kennzeichnen und jede Übergabe historisieren. +Ergebnis: FiBu erhält vollständige, nicht doppelte Übergaben; jeder Export ist rückverfolgbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs, GetReceiptsBookingdataExportFile/ExportCustomerBookingDataFile/GetSupplierBookingDataExportFile/GetBookKeepingExportCashBookData, IsReceiptExported(...), Historien-Methoden; Imports der Gateway-Namespaces DatevAscii/DatevXmlOnline/DatevXMLOnline2020 - Begründung: durchsetzende Export-, Format- und Statuslogik. +Prüfidee: Beleg exportieren, erneuten Export im Zeitraum anfordern; erwartet: Beleg als „übertragen" ausgefiltert; Exportdatei entspricht DATEV-Formatdefinition. +Tracelinks: StRS-009, StRS-016; SwRS-057, SwRS-058, SwRS-025 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - DATEV-Übergabe ist im DACH-Markt zwingend. +Status: belegt +``` + +``` +ID: SyRS-025 +Titel: Report-Engine für Belegdruck und PDF-Erzeugung +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Module mit Druckausgabe +Vorbedingung: Reportvorlage (FastReport) ist einer Belegart/Funktion zugeordnet. +Fakt: Der ReportEngine-Bereich kapselt FastReport (FastReportHelper), bietet austauschbare PDF-Strategien (IPdfStrategy: DefaultPdfStrategy/FastReportPdfStrategy), PDF-Exporteinstellungen, Report-Import/-Export (ReportDataImport/ExportBL) und einen speziellen ZUGFeRD-PDF-Generator (CustomZugferdPdfGenerator); ReceiptBL erzeugt Belegdrucke über CreateFullReportForReceipt und legt PDFs optional in den Belegdokumenten ab (AddReportToReceiptDocuments). +Aussage: Das System soll Belege und Auswertungen über eine zentrale Report-Engine mit austauschbaren Vorlagen drucken, als PDF exportieren und erzeugte PDFs dem Beleg zuordnen können. +Ergebnis: Einheitlicher Belegdruck; PDFs archiviert am Beleg; Vorlagen austauschbar ohne Codeänderung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ReportEngine/FastReportHelper.cs, PdfStategy/IPdfStrategy.cs (+Implementierungen), ImportExport/ReportDataImportBL.cs; src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateFullReportForReceipt/AddReportToReceiptDocuments (Zeile 3221ff, 3459ff) - Begründung: implementierende Druck- und Ablagelogik. +Prüfidee: Rechnung drucken mit "PDF zu Belegdokumenten"; erwartet: PDF-Datei am Beleg. +Tracelinks: StRS-015; SwRS-025, SwRS-038 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Belegdruck ist Pflicht; Engine im Web neu wählen. +Status: belegt +``` + +``` +ID: SyRS-026 +Titel: Zentrale Dokumenten- und Verzeichnisverwaltung je Objekt +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Module mit Dokumentbezug +Vorbedingung: Objekt (Konto, Beleg, Vertrag, Aktivität) benötigt Dokumentenablage. +Fakt: FileManagement stellt Verzeichnislogik (DirectoryBL, DirectoryReferenceBL) mit objektartspezifischen Providern bereit (u. a. AccountDirectoryProvider, AccountActivityDirectoryProvider, AccountContractsDirectoryProvider); eine Blacklist regelt Indexnamen (CreateIndexNameBlacklist); Belege erhalten Ablageverzeichnisse (GetParentDirectoryForReceipts in den SpecificLogics). +Aussage: Das System soll je Geschäftsobjekt automatisch strukturierte Dokumentverzeichnisse bereitstellen und referenzieren. +Ergebnis: Dokumente liegen einheitlich und objektbezogen auffindbar ab. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/FileManagement/DirectoryBL.cs, DirectoryReferenceBL.cs und DirectoryReferenceProviders/AccountFolders/*.cs - Begründung: implementierende Verzeichnislogik. +Prüfidee: Neues Konto anlegen; erwartet: Standardverzeichnisstruktur; Beleg-PDF landet im Belegverzeichnis. +Tracelinks: StRS-020; SwRS-031, SwRS-044, SwRS-056 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - DMS-Grundfunktion; im SaaS als Objektspeicher. +Status: belegt +``` + +``` +ID: SyRS-027 +Titel: Elektronische Bestellübertragung an Distributoren (EDI) +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Einkauf, Distributoren (ALSO, Alltron, EGIS, Concerto, ITscope u. a.) +Vorbedingung: Lieferantenbestellung ist erfasst; EDI-Konfiguration je Lieferant vorhanden. +Fakt: EDIDispatcherBL erzeugt distributorspezifische Bestell-XMLs (CreateEDISuggestionOrderAsync) und lädt sie je Distributor hoch (EdiEgisOrderUploadAsync, EdiItScopeOrderUploadAsync, EdiConcertoOrderUploadAsync); je Distributor existieren eigene Order-BLs (AlltronOrderBL, AlsoOrderBL, EgisOrderBL inkl. Auftragsbestätigung EgisOrderConfirmBL); Übertragungen werden geloggt (EDILogBL, EDIGatewayLogBL). +Aussage: Das System soll Lieferantenbestellungen elektronisch im Format des jeweiligen Distributors übertragen, Auftragsbestätigungen verarbeiten und alle Übertragungen protokollieren. +Ergebnis: Bestellungen erreichen Distributoren ohne Medienbruch; Status und Log je Übertragung. +Belege: + - [PRIMÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs, CreateEDISuggestionOrderAsync/Edi*OrderUploadAsync; EDI/EGIS/EgisOrderConfirmBL.cs; EDI/EDILogBL.cs - Begründung: durchsetzende Erzeugungs-, Versand- und Protokolllogik. +Prüfidee: Testbestellung an EGIS erzeugen; erwartet: valides XML, Logeintrag, Bestätigungsverarbeitung. +Tracelinks: StRS-010, StRS-007, StRS-021; SwRS-060, SwRS-045 +Konsolidierung: Kandidat: Centron.Gateway/EDI_* (zweite EDI-Schicht) - Zuordnung Gateway vs. BL im Zielsystem vereinheitlichen +Übernahmewürdigkeit: übernehmen - EDI mit Distributoren ist Kernprozess des IT-Handels. +Status: belegt +``` + +``` +ID: SyRS-028 +Titel: Verwaltung der beim Kunden befindlichen Geräte/Assets +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Service, Vertrieb +Vorbedingung: Geräte sind Kundenkonten zugeordnet. +Fakt: Kundengeräte werden mehrfach geführt: als AccountDevices (Geräte mit Log und externer ID), als „Stammblätter"/CustomerAssets (CustomerAssetBL, CustomerAssetExtendedBL) und im DocuBoard-Asset-Management (Partner, Artikelzuordnung, AD-Ausschlüsse). +Aussage: Das System soll die beim Kunden befindliche Hardware mit Historie, Vertragsbezug und Identifikatoren verwalten. +Ergebnis: Gerätebestand je Kunde für Service, Verträge und Abrechnung verfügbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Devices/AccountDeviceBL.cs; src/backend/Centron.BL/Sales/CustomerAssets/CustomerAssetBL.cs, CustomerAssetExtendedBL.cs; src/backend/Centron.BL/DocuBoard/*.cs - Begründung: drei implementierende Datenhaltungen desselben fachlichen Gegenstands. +Prüfidee: Gerät in allen drei Sichten anlegen/finden; erwartet: (heute) getrennte Datensätze - Konsolidierungsnachweis. +Tracelinks: StRS-022, StRS-023; SwRS-054, SwRS-055 +Konsolidierung: Kandidat: AccountDevices vs. CustomerAssets/Stammblätter vs. DocuBoard-Assets - im Zielsystem ein einheitliches Asset-Konzept +Übernahmewürdigkeit: übernehmen - fachlich zwingend, technisch zu konsolidieren. +Status: belegt +``` + +``` +ID: SyRS-029 +Titel: Persönliche Organisation und Zusammenarbeit +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Mitarbeiter +Vorbedingung: Benutzer ist angemeldet. +Fakt: Es existieren Kalender (CalendarBL), ToDos (ToDoBL über Objektarten), Terminanfragen (AppointmentRequestBL), Checklisten (CentronChecklistBL), Chats (ChatBL), Dashboards/QuickNotes/zuletzt verwendete Objekte (MyCentron) und eine „Mein Tag"-Übersicht (MyDayBL). +Aussage: Das System soll Mitarbeitern persönliche Organisationswerkzeuge (Kalender, Aufgaben, Notizen, Tagesübersicht, Dashboards) und Team-Zusammenarbeit (Chat, Checklisten, Terminanfragen) bereitstellen. +Ergebnis: Arbeitsvorrat und Kommunikation sind in der ERP-Oberfläche gebündelt. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Calendar/CalendarBL.cs, ToDoArea/ToDoBL.cs, MyCentron/Dashboard/DashboardContainerBL.cs, MyDay/MyDayBL.cs, Chats/ChatBL.cs - Begründung: implementierende Module. +Prüfidee: ToDo zu einem Beleg anlegen; erwartet: erscheint in MyDay/Benachrichtigungen des Zuständigen. +Tracelinks: StRS-018; SwRS-043, SwRS-046, SwRS-049, SwRS-050 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Produktivitätskern; Umfang im Zielsystem priorisieren. +Status: belegt +``` + +``` +ID: SyRS-030 +Titel: Telefonie-Integration (TAPI) mit Anrufdatenerfassung +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Mitarbeiter, Telefonanlage +Vorbedingung: TAPI-Treiber/Einstellungen sind konfiguriert; Benutzer hat das Recht TAPI_SUPPORT. +Fakt: PhoneCallBL verarbeitet Anrufe (Tapi-Modul); PhoneSettingsBL verwaltet globale und persönliche Telefonieeinstellungen; der Rechtekatalog enthält TAPI_SUPPORT (20400070); Assemblies für TAPI liegen unter assemblies/tapi. +Aussage: Das System soll Telefonanrufe über TAPI erkennen und mit Kontakten/Vorgängen verknüpfen; Telefonie ist je Benutzer konfigurierbar und rechtegebunden. +Ergebnis: Eingehende Anrufe öffnen den passenden Kunden-/Vorgangskontext. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Tapi/PhoneCallBL.cs; src/backend/Centron.BL/Administration/PhoneSettings/PhoneSettingsBL.cs - Begründung: implementierende Telefonielogik. + - [SEKUNDÄR] UserRightsConst.cs, TAPI_SUPPORT = 20400070; assemblies/tapi - Begründung: Rechtekonstante und Treiberbestand. +Prüfidee: Simulierter Anruf mit bekannter Nummer; erwartet: Kundenzuordnung. +Tracelinks: StRS-017; SwRS-037 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - TAPI ist Desktop-gebunden; im Web-Zielsystem durch CTI-/WebRTC-Dienst ersetzen, Funktion bleibt. +Status: belegt +``` + +``` +ID: SyRS-031 +Titel: Mehrkanal-Clients auf gemeinsamer Geschäftslogik +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Anpassbarkeit), Kompatibilität (Interoperabilität) +Akteur: Endbenutzer (Desktop, Web, Mobile, Outlook), Endkunden (Weblogin) +Vorbedingung: Webservice ist erreichbar. +Fakt: Die Solution enthält den WPF-Desktop-Client (src/centron/Centron.WPF.UI), den Blazor-Webclient „Nexus" (src/nexus/CentronNexus mit WebCart/WebOffer/ServiceBoard), ein Outlook-Add-In (CentronNexus.OutlookAddIn), Mobile-Unterstützung (Centron.BL/Mobile, WebServices) und einen zentralen Webservice (src/webservice) mit versionierten REST-Controllern; die BL-Schicht wird gemeinsam genutzt. +Aussage: Das System soll seine Funktionen über mehrere Clients (Windows-Desktop, Web, Outlook-Add-In, mobile Zugriffe) auf Basis derselben serverseitigen Geschäftslogik bereitstellen. +Ergebnis: Kanalübergreifend konsistente Geschäftsregeln. +Belege: + - [PRIMÄR] Verzeichnisstruktur src/centron, src/nexus, src/webservice mit Centron.Controllers (Controllers/v1, Authorization) und gemeinsamer Centron.BL - Begründung: Architekturaufbau belegt die Mehrkanalstruktur. +Prüfidee: Dieselbe Rechteprüfung (z. B. Ticketsicht) in Desktop und Web auslösen; erwartet: identisches Verhalten. +Tracelinks: StRS-019; SwRS-047, SwRS-048 +Konsolidierung: Kandidat: Desktop- und Webclient implementieren dieselben Masken doppelt; Zielsystem = ein Web-Frontend +Übernahmewürdigkeit: übernehmen - Zielarchitektur ist Web/SaaS mit derselben API. +Status: belegt +``` + +``` +ID: SyRS-032 +Titel: Onlinebanking-Zahlungsabgleich mit Buchung und Stornierung +Ebene: SyRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Buchhaltung, Bankdienst (finAPI) +Vorbedingung: Kontoumsätze wurden über finAPI importiert. +Fakt: OnlineBankingAccountTransactionsBL speichert Kontoumsätze, erkennt unbekannte IBANs (CheckForUnknownIbans), schlägt Zuordnungen vor (AutoCompleteAccountTransacitons), bucht Beträge auf Belege (BookAmountsForAccountTransacitons), kann Buchungen zurücknehmen (UndoBookingForAccountTransaciton) und prüft Konsistenz per Inspector (ExecuteOnlineBankingInspectorCheck/RepairOnlineBankingInspectorItems); Zugangsdaten liefert OnlineBankingFinApiBL. +Aussage: Das System soll Bankumsätze automatisch importieren, offenen Posten zuordnen (mit Vorschlagslogik), Zahlungen auf Belege buchen, Fehlbuchungen stornierbar machen und den Datenbestand per Konsistenzprüfung überwachen. +Ergebnis: Zahlungseingänge sind beleggenau ausgeziffert; Fehler korrigierbar und auffindbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs, AutoCompleteAccountTransacitons/BookAmountsForAccountTransacitons/UndoBookingForAccountTransaciton/ExecuteOnlineBankingInspectorCheck - Begründung: durchsetzende Abgleichs- und Buchungslogik. + - [PRIMÄR] src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs, GetFinApiClientCredentials - Begründung: Anbindung des Bankdienstes. +Prüfidee: Umsatz mit Rechnungsnummer im Verwendungszweck importieren; erwartet: Zuordnungsvorschlag zur Rechnung; Buchung setzt Beleg auf bezahlt; Undo stellt Zustand wieder her. +Tracelinks: StRS-009; SwRS-065, SwRS-066 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - zentrale Automatisierung der Debitorenbuchhaltung. +Status: belegt +``` + +``` +ID: SyRS-033 +Titel: Volltextsuche über zentrale Geschäftsobjekte +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Benutzer +Vorbedingung: Volltextindizes sind aufgebaut. +Fakt: IndexSearchBL baut Lucene-Indizes (IndexBuilder) mit deutschem Analyzer (GermanAnalyzer) für Konten (AccountFulltextIndex) und Tickets (TicketFulltextIndex), aktualisiert vollständig oder auf Anforderung (RequestUpdateFor je Objekt) und sucht optional artenspezifisch (SearchIndex mit CentronObjectKindNumeric). +Aussage: Das System soll eine sprachbewusste Volltextsuche über Konten und Tickets bereitstellen, deren Index bei Objektänderungen zeitnah aktualisiert wird. +Ergebnis: Treffer über Objektarten hinweg; Indexaktualisierung ohne Vollneuaufbau. +Belege: + - [PRIMÄR] src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs, UpdateAllIndexes/UpdateRequestedIndexes/SearchIndex/RequestUpdateFor; GermanAnalyzer.cs; Indexes/AccountFulltextIndex.cs, TicketFulltextIndex.cs - Begründung: implementierende Suchinfrastruktur. +Prüfidee: Ticket ändern, RequestUpdateFor auslösen; erwartet: Treffer mit neuem Text. +Tracelinks: StRS-027; SwRS-068 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - übergreifende Suche ist Erwartungsstandard. +Status: belegt +``` + +``` +ID: SyRS-034 +Titel: Regelbasierte Massenänderungen (Preise) +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Verwaltung/Vertriebsleitung +Vorbedingung: Massenänderungs-Vorlage ist definiert. +Fakt: MassUpdateBL verwaltet MassUpdateTemplates, sucht betroffene Belegpositionen (SearchForReceiptUpdateItems) und startet Preisänderungen auf Belege (StartReceiptPriceUpdate) und Artikel (StartArticlePriceUpdate). +Aussage: Das System soll Preisänderungen als wiederverwendbare Vorlagen massenhaft auf Artikel und offene Belege anwenden können. +Ergebnis: Konsistente Preisanpassungen ohne Einzelpflege. +Belege: + - [PRIMÄR] src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs, StartReceiptPriceUpdate/StartArticlePriceUpdate/SearchForReceiptUpdateItems - Begründung: durchsetzende Massenänderungslogik. +Prüfidee: Vorlage auf Artikelgruppe anwenden; erwartet: alle Artikelpreise gemäß Regel geändert. +Tracelinks: StRS-008; SwRS-075 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Effizienzfunktion. +Status: belegt +``` + +``` +ID: SyRS-035 +Titel: E-Mail-Versand und Exchange-Integration +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Mitarbeiter, Exchange-Server +Vorbedingung: Mailkonten/Exchange-Zugänge sind konfiguriert. +Fakt: Das Mail-Modul kapselt EWS-Zugriffe (EWSConnection, EwsEmailAccess, EwsCalendarAccess), erzeugt Mails über eine Factory (CentronMailFactory), formatiert Inhalte (RichEditMailMessageExporter, StringToHtmlConverter), verwaltet Signaturen (MailSignatureBL, SignatureReplacementBL mit Platzhaltern) und führt eine Domain-Blacklist (DomainBlacklistBL). +Aussage: Das System soll E-Mails mit personalisierten Signaturen versenden, Exchange-Postfächer und -Kalender anbinden und Versand an gesperrte Domains verhindern. +Ergebnis: Einheitlicher Mailversand aus allen Modulen; Exchange-Synchronisation. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Mail/Exchange/EwsHelper/EWSConnection.cs, EwsEmailAccess.cs; Mail/MailSignatureBL.cs; Mail/Blacklist/DomainBlacklistBL.cs - Begründung: implementierende Mail-Infrastruktur. +Prüfidee: Mail an geblacklistete Domain; erwartet: Ablehnung/Warnung; Signaturplatzhalter werden ersetzt. +Tracelinks: StRS-017, StRS-026; SwRS-072 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - E-Mail bleibt Hauptkanal; EWS durch Graph-API ablösen (GraphServiceClientHelper existiert bereits). +Status: belegt +``` + +``` +ID: SyRS-036 +Titel: Automatisierte Postfachverarbeitung (Mail-Scanner) +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Hintergrunddienst, Support +Vorbedingung: Scanner-Profile mit Postfachzugang und Workflows sind konfiguriert. +Fakt: MailScannerBL verwaltet Profile (Postfächer), Workflows (MailScannerWorkflowProcessDTO) und Aufgaben (SaveTasks); Workflows verarbeiten eingehende Mails regelbasiert (Modulname deutet auf Ticket-/Vorgangserzeugung; konkrete Zielaktionen liegen in den Workflow-Definitionen). +Aussage: Das System soll konfigurierte Postfächer automatisch überwachen und eingehende Mails regelbasiert weiterverarbeiten (z. B. zu Vorgängen zuordnen). +Ergebnis: Mails werden ohne manuelle Sichtung in Prozesse überführt. +Belege: + - [PRIMÄR] src/backend/Centron.BL/MailScanner/MailScannerBL.cs, GetWorkflows/SaveWorkflow/SaveProfile/SaveTasks - Begründung: implementierende Profil- und Workflowverwaltung. +Prüfidee: Testmail an überwachtes Postfach; erwartet: Workflow-Aktion (z. B. Ticket) wird ausgeführt. +Tracelinks: StRS-017, StRS-005; SwRS-073 +Konsolidierung: Kandidat: Services/Workflows (allgemeine Workflow-Engine) - zwei Workflow-Mechanismen +Übernahmewürdigkeit: übernehmen - Automatisierung des Posteingangs ist Kernnutzen. +Status: belegt +``` + +``` +ID: SyRS-037 +Titel: Vertragsverwaltung mit Laufzeit, Verlängerung und Abrechnungsintervallen +Ebene: SyRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Vertrieb, Vertragsverwaltung +Vorbedingung: Vertrag (ReceiptContract) ist aktiv. +Fakt: Verträge führen Laufzeit (ContractEnd), Kündigung (ContractTermination), automatische Verlängerung (AutomatedProlongation), Abrechnungsstand (LastBookingTo) und Abrechnungsintervalle (BillingIntervalKinds: Monthly/Quarterly/Yearly); Vertragsarten sind katalogisiert (GetContractKinds); Abrechnungszeiträume je Rechnungsposition sind rückverfolgbar (GetContractBillingPeriodForInvoiceItem). +Aussage: Das System soll Verträge mit Laufzeit, Kündigungsdatum, automatischer Verlängerung und monatlichen/quartalsweisen/jährlichen Abrechnungsintervallen verwalten und je Rechnungsposition den abgerechneten Zeitraum nachweisen. +Ergebnis: Verträge sind vollständig abrechenbar und auditierbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, GetMonthDuration (BillingIntervalKinds-Switch, Zeile 1017ff), GetContractBillingPeriodForInvoiceItem (Zeile 324ff), CloseContract (AutomatedProlongation-Zweige, Zeile 1243ff) - Begründung: durchsetzende Intervall-, Laufzeit- und Nachweislogik. +Prüfidee: Quartalsvertrag anlegen; erwartet: Abrechnungszeitraum je Rechnung = 3 Monate; Rechnungsposition liefert Periode. +Tracelinks: StRS-004; SwRS-092, SwRS-093 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kern des Servicegeschäfts. +Status: belegt +``` + +``` +ID: SyRS-038 +Titel: Automatische Vertragsfakturierung inkl. Zählerstände und Sammelrechnungen +Ebene: SyRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Hintergrundprozess/Buchhaltung +Vorbedingung: Verträge mit fälligen Abrechnungszeiträumen existieren. +Fakt: AutomaticFacturaBL ermittelt abrechnungsfällige Kunden (SearchCustomers(BilledTo)), zieht abzurechnende Lieferscheine heran (SearchBillingDeliveryLists), verarbeitet Zählerstände je Gerät/Vertrag (AutomaticFacturaCounterToContract, GetDeviceIDsWithoutCounter, Zähler-Importe) und unterstützt Sammelrechnungen mit eigener Mail-Empfängerlogik (GetContractMailTemplate mit isCollectiveInvoice, alternative Rechnungsempfänger, Konzernempfänger); Verträge sind in Rechnungen weiterführbar (ContractSpecificLogic → InvoiceClass). +Aussage: Das System soll fällige Verträge automatisch abrechnen, dabei nutzungsabhängige Positionen aus Zählerständen (z. B. Druckseiten) berücksichtigen, Sammelrechnungen je Kunde/Konzern erzeugen und den Rechnungsversand an konfigurierte Empfänger vorbereiten. +Ergebnis: Wiederkehrende Umsätze werden ohne manuelle Belegerstellung fakturiert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs, SearchCustomers(DateTime BilledTo)/SearchBillingDeliveryLists; AutomaticFacturaBL.Contracts.cs, StoreCounterState/GetCurrentCounterState/GetContractMailTemplate(isCollectiveInvoice) - Begründung: durchsetzende Ermittlungs-, Zähler- und Sammelrechnungslogik. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ContractLists/ContractSpecificLogic.cs, CanBeForwardedInto() (enthält InvoiceClass) - Begründung: Weg des Vertrags in die Rechnung. +Prüfidee: Vertrag mit Zählerartikel und Stichtag in der Vergangenheit; erwartet: Kunde erscheint in der Abrechnungssuche, Rechnung enthält Zählerdifferenz. +Tracelinks: StRS-004, StRS-003; SwRS-094 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - zentrales MSP-/Vertragsgeschäft. +Status: belegt +``` + +``` +ID: SyRS-039 +Titel: Leistungserfassung am Ticket und Abrechnung über Timer-Billing +Ebene: SyRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Support, Buchhaltung +Vorbedingung: Ticket-Zeiten (Timer) sind erfasst. +Fakt: HelpdeskTimerBL/HelpdeskTimeRecordingBL erfassen Zeiten je Ticket; TimerBillingBL verwaltet Abrechnungsstatus je Timer (HelpdeskTimerBillingState), ordnet Timern Artikel und Verträge zu (GetArticles/GetContracts), sucht abrechenbare Timer (SearchTimers) und aktualisiert Auftragsbezüge; ReceiptBL.CreateNewReceiptForHelpdekTimers erzeugt aus Timern einen Beleg gemäß TimerBillingSettings. +Aussage: Das System soll am Ticket erfasste Arbeitszeiten mit Abrechnungsstatus führen und daraus - unter Berücksichtigung von Verträgen/Kontingenten - Abrechnungsbelege erzeugen. +Ergebnis: Erfasste Leistungen werden vollständig und genau einmal fakturiert. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs, SearchTimers/SaveTimer/GetContracts/GetTimerBillingStates - Begründung: durchsetzende Abrechnungsvorbereitung. + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateNewReceiptForHelpdekTimers(IList timerI3Ds, TimerBillingSettingsDTO, AppUser) (Zeile 5295) - Begründung: durchsetzende Belegerzeugung aus Timern. +Prüfidee: Zwei Timer abrechnen; erwartet: Beleg mit zwei Leistungspositionen, Timer-Status wechselt auf abgerechnet. +Tracelinks: StRS-006, StRS-005; SwRS-095 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kern der Dienstleistungsabrechnung. +Status: belegt +``` + +``` +ID: SyRS-040 +Titel: Helpdesk-Ticketsystem mit rechtebasierter Sichtbarkeit und Statusfluss +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Support-Mitarbeiter, Endkunde (Web) +Vorbedingung: Benutzer besitzt Helpdesk-Rechte. +Fakt: HelpdeskBL prüft beim Speichern operationsgenau Rechte (ADD_NEW_HELPDESK, EDIT_HELPDESK, CLOSE_REQUEST beim Setzen des Abschlussstatus, MATURITY_CHANGE bei Fälligkeitsänderung, ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS bei Verantwortlichenwechsel) und trennt Web-Account-Prüfungen (CheckWebRights); restriktive Rechte (SHOW_HELPDESK_ONLY_OWN, SHOW_HELPDESK_ONLY_OWN_BRANCH) schränken Sichtbarkeit ein; Status werden über HelpdeskStatusBL/HelpdeskSettingsBL (Abschlussstatus) verwaltet. +Aussage: Das System soll Tickets mit konfigurierbaren Status führen, jede Operation (Anlegen, Bearbeiten, Abschließen, Fälligkeit ändern, Zuweisen) einzeln berechtigen und die Sichtbarkeit optional auf eigene Tickets bzw. die eigene Filiale beschränken. +Ergebnis: Feingranular geschützter Ticketprozess; identische Regeln für interne Benutzer und Web-Accounts. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, CheckUserRigths(...) (Zeile 418ff) mit allen genannten Rechteprüfungen und Abteilungsprüfung; Sichtbarkeitsrechte Zeile 272-284 - Begründung: durchsetzende Prüfstellen. + - [KONTEXT] CentronRights.md, Abschnitt Helpdesk - Begründung: dokumentierte Rechte-Semantik deckungsgleich zum Code. +Prüfidee: Benutzer mit SHOW_HELPDESK_ONLY_OWN sieht fremde Tickets nicht; Abschluss ohne CLOSE_REQUEST wird verweigert. +Tracelinks: StRS-005, StRS-012; SwRS-096, SwRS-097 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kernprozess mit ausgereiftem Rechtemodell. +Status: belegt +``` + +``` +ID: SyRS-041 +Titel: Mehrstufige Ticket-Eskalation +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Support-Leitung, Hintergrundprozess +Vorbedingung: Eskalationsdefinitionen sind gepflegt. +Fakt: EscalationBL führt je Objekt bis zu drei Eskalationsstufen mit Zeitstempeln (Eskalation1Am/2Am/3Am, Termin als Stufe 0), verarbeitet Eskalationen nach Typ/Filter (DoEscalation) und bietet einen Testlauf (TestEscalation mit EscalationDate). +Aussage: Das System soll überfällige Vorgänge in bis zu drei Stufen eskalieren, Eskalationszeitpunkte je Stufe dokumentieren und Eskalationsläufe testbar machen. +Ergebnis: Überfällige Tickets erreichen definierte Empfängerkreise stufenweise. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs, SQL mit Eskalation1Am/2Am/3Am (Zeile 68ff), DoEscalation/TestEscalation; EscalationReceiversEnum.cs - Begründung: durchsetzende Stufen- und Empfängerlogik. +Prüfidee: Ticket über Stufe-1-Frist altern lassen; erwartet: Eskalation1Am gesetzt, Empfänger benachrichtigt; Stufe 2 folgt fristgerecht. +Tracelinks: StRS-005; SwRS-098 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - SLA-Sicherung. +Status: belegt +``` + +``` +ID: SyRS-042 +Titel: Kassenbuch mit automatischen Buchungen aus Barbelegen +Ebene: SyRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Kasse/Filiale, Buchhaltung +Vorbedingung: Barbeleg mit kassenwirksamer Zahlungskondition (ChangesCashBook) wird gebucht. +Fakt: CashBookBookingBL erzeugt aus Barbelegen automatisch Kassenbuchbuchungen: Bruttobeträge werden je Mehrwertsteuersatz gesplittet, je Satz wird ein CashBookRecord (Konto/Steuerschlüssel) benötigt (sonst Fehler), Gutschriften buchen auf der Haben-Seite, Buchungen erhalten ReadOnly=true, Filialzuordnung folgt einer Einstellung (CreateCashBookBookingAtCurrentUserBranch); Kassenbuchdaten fließen in den FiBu-Export (GetBookKeepingExportCashBookData). +Aussage: Das System soll kassenwirksame Belege automatisch, unveränderlich und mehrwertsteuergerecht getrennt im Kassenbuch verbuchen und ins Rechnungswesen übergeben. +Ergebnis: Vollständiges, manipulationsgeschütztes Kassenbuch je Filiale. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CashBooks/CashBookBookingBL.cs, UpdateCashBookBookingFromAsset(...): VAT-Split, Fehlermeldung bei fehlendem CashBookRecord, ReadOnly=true, Credit/Debit-Zweig für Gutschriften - Begründung: durchsetzende Buchungslogik. +Prüfidee: Barrechnung mit 7%- und 19%-Positionen; erwartet: zwei Kassenbuchbuchungen mit passenden Steuerschlüsseln, ReadOnly. +Tracelinks: StRS-003, StRS-009; SwRS-100 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kassenführung ist gesetzlich relevant. +Status: belegt +``` + +``` +ID: SyRS-043 +Titel: Elektronische Rechnungsformate (ZUGFeRD, XRechnung, ebInterface) +Ebene: SyRS +Typ: Schnittstelle (Abrechnung) +Qualitätsmerkmal: +Akteur: Buchhaltung, Rechnungsempfänger, Plattformen +Vorbedingung: Ausgangsrechnung ist erstellt. +Fakt: Der ReportEngine-Bereich erzeugt ZUGFeRD-PDFs über CustomZugferdPdfGenerator (gebunden an Ziel-Reportgruppen); Centron.Gateway enthält das ZUGFeRD-2.1-Extended-Schema samt XSDs (Factur-X); DataExchange/EDI/SaleInvoices enthält XInvoice-Version-3-Schnittstellen und einen Rechnungs-Upload (InvoiceUploadBL mit Belegdaten inkl. SEPA-Kennzeichen und Leitweg-Feldern); für Österreich existiert Centron.Api.EbInterface (EbInterfaceLogic); Felddokumentation liegt in docs/reference/zugferd-field-mapping.md. +Aussage: Das System soll Ausgangsrechnungen in strukturierten E-Rechnungsformaten (ZUGFeRD/Factur-X, XRechnung, ebInterface) erzeugen und an Empfänger bzw. Plattformen übertragen können. +Ergebnis: Gesetzeskonforme E-Rechnungen je Zielland/Empfänger. +Belege: + - [PRIMÄR] src/backend/Centron.BL/ReportEngine/CustomPdfGenerators/CustomZugferdPdfGenerator.cs (ICustomPdfGenerator, TargetReportGroups); src/backend/Centron.Gateway/ZUGFeRD21_Extended/ZUGFeRD_EXTENDED.cs (+XSDs); src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceUploadBL.cs, GetInvoiceInfo(...); src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs - Begründung: implementierende Format- und Übertragungskomponenten. + - [KONTEXT] docs/reference/zugferd-field-mapping.md, docs/reference/zugferd-feldzuordnung-anwender.md - Begründung: dokumentierte Feldzuordnung. +Prüfidee: Rechnung mit ZUGFeRD-Reportgruppe drucken; erwartet: PDF mit eingebettetem Factur-X-XML, das gegen die XSD validiert. +Tracelinks: StRS-010, StRS-003; SwRS-150 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - E-Rechnungspflicht macht dies zwingend. +Status: belegt +``` + +``` +ID: SyRS-044 +Titel: Versanddienstleister-Anbindung (GLS, Shipcloud) +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Logistik, Versanddienstleister +Vorbedingung: Versandauftrag mit Empfängeradresse liegt vor. +Fakt: Centron.Api.Gls überträgt Sendungen an die GLS-API (CentronGlsLogic.UploadShipment mit Test-/Produktiv-URL und Zugangsdaten); Centron.Api.Shipcloud bindet den Multi-Carrier-Dienst Shipcloud an (CentronShipcloudLogic). +Aussage: Das System soll Versandaufträge elektronisch an Paketdienste übergeben (direkt an GLS oder über den Multi-Carrier-Dienst Shipcloud) und Ergebnisse (Label/Tracking) zurückerhalten. +Ergebnis: Paketlabel ohne Medienbruch aus dem Beleg. +Belege: + - [PRIMÄR] src/apis/Centron.Api.Gls/CentronGlsLogic.cs, UploadShipment(...); CentronGlsConsts.cs (BaseURL/TestBaseURL); src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs - Begründung: implementierende Übertragungslogik. +Prüfidee: Testsendung gegen GLS-QS-Umgebung; erwartet: UploadResult mit Labeldaten. +Tracelinks: StRS-011; SwRS-151 +Konsolidierung: Kandidat: GLS-Direktanbindung vs. Shipcloud (Multi-Carrier) - im Zielsystem ein Versandabstraktionsweg +Übernahmewürdigkeit: übernehmen - Versandprozess ist Kern der Logistik. +Status: belegt +``` + +``` +ID: SyRS-045 +Titel: Kundenportal mit Shop, Tickets, Formularen und Dokumenten +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Endkunde (Web-Account) +Vorbedingung: Kunde besitzt einen Web-Account mit Web-Rechten. +Fakt: Der Nexus-Webclient enthält ein Kundenportal: Shop/WebCart (Artikel aus Kunden-Sonderpreisen laut README), Vertragsübersicht (ContractsOverview.razor), Ticketdetails und -historie (CustomerTicketDetailsPage/CustomerTicketHistoryPage), ausfüllbare Formulare (CustomerPortalFormFillPage) und öffentliche Dokumente (CustomerPortalPublicDocumentsPage); zusätzlich WebOffer und DocumentSigning mit Unterschriften-Pad. +Aussage: Das System soll Endkunden ein Webportal bieten mit Artikelbestellung zu kundenspezifischen Preisen, Einsicht in eigene Tickets und Verträge, Formularen und bereitgestellten Dokumenten. +Ergebnis: Self-Service für Endkunden mit Web-Account-Rechtesteuerung (SyRS-002). +Belege: + - [PRIMÄR] src/nexus/CentronNexus/WebCart/*.razor (ContractsOverview, CustomerTicketDetailsPage, CustomerPortalFormFillPage, CustomerPortalPublicDocumentsPage), src/nexus/CentronNexus/WebOffer, src/nexus/CentronNexus/DocumentSigning/DocumentSigningPage.razor - Begründung: implementierende Portalseiten. + - [KONTEXT] README.md, Abschnitt WebCart ("available if you login as a web-account", Artikel aus "Sonderpreisen") - Begründung: dokumentiertes Sollverhalten. +Prüfidee: Web-Account meldet sich an, öffnet Shop; erwartet: nur Artikel der Kunden-Sonderpreise; Ticketliste zeigt nur eigene Tickets. +Tracelinks: StRS-019; SwRS-145, SwRS-129 +Konsolidierung: Kandidat: SelfCare-Formulare (SwRS-108) - zwei Formularwege für Endkunden +Übernahmewürdigkeit: übernehmen - zentrales Zielbild der Web-/SaaS-Version. +Status: belegt +``` + +``` +ID: SyRS-046 +Titel: REST-API mit deklarativer Rechte-Autorisierung je Endpunkt +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: API-Clients, Webservice +Vorbedingung: Aufruf eines geschützten API-Endpunkts. +Fakt: Centron.Controllers stellt versionierte Controller (Controllers/v1: Accounts, Contracts, Customers, Helpdesks, Invoices/Receipts, Orders, SelfCare, Tickets, WebAccount u. a.) bereit; Autorisierungsattribute erzwingen Benutzerrechte deklarativ: AuthorizeUserRightAttribute (ein Recht), AuthorizeAnyUserRightAttribute (eines von mehreren), AuthorizeAllUserRightsAttribute (alle), AuthorizeCentronHostedAttribute (nur gehostete Umgebung); die Filter prüfen im OnAuthorization gegen die Rechte des angemeldeten Benutzers. +Aussage: Das System soll jeden REST-Endpunkt deklarativ mit den erforderlichen Benutzerrechten schützen; unberechtigte Aufrufe werden vor Ausführung der Aktion abgewiesen. +Ergebnis: API-Sicherheit entspricht dem internen Rechtemodell; keine ungeprüften Endpunkte mit Attribut. +Belege: + - [PRIMÄR] src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs, AuthorizeAnyUserRightAttribute.cs, AuthorizeAllUserRightsAttribute.cs (jeweils IAuthorizationFilter.OnAuthorization), AuthorizeCentronHostedAttribute.cs/CentronHostedAuthorization.cs - Begründung: durchsetzende Autorisierungsfilter. +Prüfidee: Endpunkt mit AuthorizeUserRight ohne das Recht aufrufen; erwartet: 403 vor Ausführung. +Tracelinks: StRS-013, StRS-012; SwRS-147, SwRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Muster für Zielsystem-API. +Status: belegt +``` + +``` +ID: SyRS-047 +Titel: Containerisierter Serverbetrieb +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Installierbarkeit) +Akteur: Betrieb/DevOps +Vorbedingung: Server-Komponenten sollen bereitgestellt werden. +Fakt: Docker-Definitionen existieren für Webservice, API, Demo-Umgebung, Mailcatcher und Regressionstest-DB (docker/*); docker/compose enthält compose.yaml, WebServiceConfig.xml und appsettings.Production.json als Betriebskonfiguration. +Aussage: Das System soll serverseitig als Container mit ausgelagerter Konfiguration betreibbar sein. +Ergebnis: Reproduzierbare Deployments; Grundlage für SaaS-Betrieb. +Belege: + - [PRIMÄR] docker/c-entron-webservice/Dockerfile, docker/compose/compose.yaml + WebServiceConfig.xml - Begründung: implementierende Betriebsartefakte. +Prüfidee: compose-Stack starten; erwartet: erreichbarer Webservice mit Konfiguration aus WebServiceConfig.xml. +Tracelinks: StRS-031; SwRS-157 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - direkter Baustein der SaaS-Migration. +Status: belegt +``` + +``` +ID: SyRS-048 +Titel: Windows-Installer für Client-Verteilung +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Installierbarkeit) +Akteur: Administrator beim Kunden +Vorbedingung: Desktop-Client soll installiert/aktualisiert werden. +Fakt: deployment/WixSharpInstaller erzeugt einen MSI-Installer (WixSharp, Program.cs); scripts/Centron.Scripts enthält Sign- und WXS-Helfer (SignHelper, WXSHelper) für signierte Auslieferung. +Aussage: Das System soll den Desktop-Client als signiertes Windows-Installationspaket ausliefern. +Ergebnis: Standardisierte, signierte Client-Installation. +Belege: + - [PRIMÄR] deployment/WixSharpInstaller/Program.cs; scripts/Centron.Scripts/SignHelper.cs, WXSHelper.cs - Begründung: implementierende Build-/Installerartefakte. +Prüfidee: Installer bauen; erwartet: signiertes MSI. +Tracelinks: StRS-031; SwRS-156 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - entfällt bei reiner Web-Auslieferung; bis dahin nötig. +Status: belegt +``` + +``` +ID: SyRS-049 +Titel: Mehrstufige automatisierte Testabdeckung +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Testbarkeit) +Akteur: Entwicklung/CI +Vorbedingung: Codeänderungen werden integriert. +Fakt: Die Solution enthält Test-Suiten auf mehreren Ebenen: Unit-/BL-/DAO-Tests (tests/backend: Centron.Tests.BL, Centron.Tests.DAO), Shared-Tests (Centron.Tests.Core, Centron.Tests.Controls), Integrationstests (Centron.Tests.Integration), End-to-End-Tests (Centron.Tests.EndToEnd), UI-Tests (PlaywrightTests) und Nexus-Tests (CentronNexusTests); eine dedizierte Regressionstest-DB ist als Docker-Image definiert; CI-Workflows liegen unter .github/workflows und azure/build-templates. +Aussage: Das System soll durch automatisierte Tests auf Unit-, Integrations-, End-to-End- und UI-Ebene abgesichert sein, inklusive reproduzierbarer Testdatenbank. +Ergebnis: Regressionsschutz bei Weiterentwicklung; Referenz für die Neuimplementierung. +Belege: + - [PRIMÄR] tests/backend, tests/Centron.Tests.Integration, tests/Centron.Tests.EndToEnd, tests/PlaywrightTests, tests/CentronNexusTests; docker/c-entron-regression-tests-db - Begründung: vorhandene Testprojekte und -infrastruktur. +Prüfidee: Testläufe in CI ausführen; erwartet: alle Suiten laufen gegen die Regressions-DB. +Tracelinks: StRS-031; SwRS-157 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Testbestand als Verhaltensreferenz für die Migration nutzen. +Status: belegt +``` + +``` +ID: SyRS-050 +Titel: [HYPOTHESE] Mahnwesen mit drei Mahnstufen und Belegsperre +Ebene: SyRS +Typ: funktional (Abrechnung) +Qualitätsmerkmal: +Akteur: Buchhaltung, Kunde +Vorbedingung: Rechnungen sind überfällig. +Fakt: Der Einstellungskatalog definiert Mahnstufen-Texte (DunningLevel1Text=100, DunningLevel2Text=101, DunningLevel3Text=102), Nutzungsschalter je Mahnstufe und eine Sperre von Kundenbelegen ab einer Mahnstufe (CustomerAssetsLockedAfterDunningLevel=104); die durchsetzende Mahnlauf-Logik (Stufenermittlung, Mahnschreiben, Sperrprüfung) wurde in diesem Lauf nicht lokalisiert. +Aussage: [HYPOTHESE] Das System soll überfällige Rechnungen in bis zu drei Mahnstufen mit konfigurierbaren Texten mahnen und Kunden ab einer konfigurierten Mahnstufe für neue Belege sperren. +Ergebnis: Mahnschreiben je Stufe; Belegsperre ab Schwellstufe. +Belege: + - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, DunningLevel1Text/2/3, CustomerAssetsLockedAfterDunningLevel (Zeile ~100-110) - Begründung: Konfigurationsschalter belegen die Existenz des Mahnwesens, nicht dessen Durchsetzung. +Prüfidee: Überfällige Rechnung mahnen; erwartet: Stufentext gemäß Einstellung; Beleganlage nach Schwellstufe wird verweigert. +Tracelinks: StRS-009, StRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Mahnwesen ist Pflicht; Detailregeln in Folgeiteration am Code verifizieren. +Status: HYPOTHESE (fehlend: durchsetzende Mahnlauf-Klasse/Methode; vermutlich in Finances oder Statistics, in diesem Lauf nicht aufgefunden) +``` + diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Traceability.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Traceability.md new file mode 100644 index 00000000..d6ff7431 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse/Traceability.md @@ -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. diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Protokoll.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Protokoll.md new file mode 100644 index 00000000..57c55b65 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Protokoll.md @@ -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. diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/RawResult.json b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/RawResult.json new file mode 100644 index 00000000..f7620137 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/RawResult.json @@ -0,0 +1 @@ +{"is_error":false,"duration_api_ms":25285483,"num_turns":139,"stop_reason":"end_turn","session_id":"03603a98-feb4-43f9-8f8c-1621115f6c38","total_cost_usd":66.813704,"usage":{"input_tokens":246,"cache_creation_input_tokens":816487,"cache_read_input_tokens":28808092,"output_tokens":280683,"output_tokens_details":{"thinking_tokens":40204},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":816487,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":1463,"cache_read_input_tokens":451610,"cache_creation_input_tokens":901,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":901},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6945,"outputTokens":24,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007065,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-fable-5":{"inputTokens":250,"outputTokens":281133,"cacheReadInputTokens":29175569,"cacheCreationInputTokens":1178596,"webSearchRequests":0,"costUSD":66.806639,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"Bash","tool_use_id":"toolu_01A5Qd6nbrvCDxtYEHM88Guc","tool_input":{"command":"SCRATCH=\"C:/Users/CHRIST~1/AppData/Local/Temp/claude/C--DEV-MasterArbeit-QuellCode-CentronERP/03603a98-feb4-43f9-8f8c-1621115f6c38/scratchpad\"\nmkdir -p \"$SCRATCH\"\nmv \"c:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_ledger.tsv\" \"$SCRATCH/ledger.tsv\" && echo moved","description":"Move ledger to scratchpad"}},{"tool_name":"Bash","tool_use_id":"toolu_01H2D7cJMmQzBdVCEwdQ8EUz","tool_input":{"command":"OUT=\"c:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Ergebnisse\"\ncd \"$OUT\" && python - <<'PYEOF'\nimport re\nfor f in ['StRS.md','SyRS.md','SwRS.md']:\n s=open(f,encoding='utf-8').read()\n s=re.sub(r'\\n\\n?','\\n',s)\n open(f,'w',encoding='utf-8').write(s)\nprint('sentinels removed')\nPYEOF\nrm -f \"$OUT/../_report_part2.md\" \"$OUT/../_report_part3.md\"\ngrep -n \"Risikorelevante Anforderungen\" \"$OUT/Analysebericht.md\" | head -2\ntail -5 \"$OUT/SwRS.md\"","description":"Remove work markers and temp files"}}],"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 `Ergebnisse\\`-Verzeichnis.\n\n## Ergebnis\n\n**241 Anforderungen** (33 StRS, 50 SyRS, 158 SwRS) über ein Modulinventar von **151 Modulen**, davon 6 Hypothesen (2,5 %) und 75 risikorelevante Anforderungen.\n\n| Datei | Inhalt |\n|---|---|\n| `Analysebericht.md` | Modulinventar (151 Zeilen, vor der ersten Anforderung erstellt), Abdeckungstabelle (tief: 9 / mittel: 58 / flach: 83 / nicht analysiert: 1), Konsistenzcheck, Risikoliste, Selbstbewertung |\n| `StRS.md` / `SyRS.md` / `SwRS.md` | Anforderungen im vorgegebenen Blockformat, alle mit Fakt/Aussage-Trennung, klassifizierten Belegen, Prüfidee, Übernahmewürdigkeit |\n| `Traceability.md` | Generierte Tabelle StRS↔SyRS↔SwRS, beidseitig geschlossen (keine Waisen) |\n| `Hypothesen.md` | Exakt die 6 inline markierten Hypothesen mit offener Frage |\n| `Glossar.md` | 40 Domänenbegriffe |\n\n**Zentrale Befunde zur Codebasis:** Das System ist ein ERP für IT-Systemhäuser/MSPs mit Belegkette (Angebot→Auftrag→Lieferschein→Rechnung→Gutschrift als per Code durchgesetzte Weiterführungsmatrix), Vertragsgeschäft mit automatischer Fakturierung inkl. Zählerständen, Helpdesk mit dem in `CentronRights.md` dokumentierten und im Code deckungsgleich durchgesetzten Rechtemodell, DATEV-/SEPA-/ZUGFeRD-Anbindung und Distributoren-EDI. Als Migrationsrisiken markiert: ungesalzenes SHA1-Passworthashing (mit Entwickler-TODO belegt), stille String-Kürzung in der Persistenz und 15 dokumentierte Konsolidierungsfälle (u. a. drei Gerätedatenhaltungen, zwei Belegmodelle, zwei Passwortverwaltungen, Desktop/Web-Doppel-UI).\n\n**Regelkonformität des Laufs:** Mindestabdeckung erreicht (nur M-150 `docs` begründet ohne Anforderung); automatisierter Konsistenzcheck ohne Befund (keine ID-Duplikate, keine Anforderung ohne Beleg/Übernahmewürdigkeit/Prüfidee, keine toten Tracelinks); alle 75 Risikoanforderungen tragen einen PRIMÄR-Beleg mit durchsetzender Stelle — einzige Ausnahme SyRS-050 (Mahnwesen), die regelkonform als `[HYPOTHESE]` geführt ist. Die Vertiefung erfolgte nach der Breitenabdeckung gezielt in den Risikobereichen Authentifizierung/Rechte, Fakturierung/Nummernkreise, Vertragsabrechnung, Timer-Billing und Kassenbuch.","ttft_ms":5873,"ttft_stream_ms":3148,"time_to_request_ms":28,"type":"result","duration_ms":25424873,"uuid":"14177b4b-621d-4c20-a88f-ab9acca1f2c2","queued_turn_count":0} diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Stderr.log b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/Stderr.log new file mode 100644 index 00000000..e69de29b diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_ledger.tsv b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_ledger.tsv new file mode 100644 index 00000000..9d147389 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_ledger.tsv @@ -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 diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/after.txt b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/after.txt new file mode 100644 index 00000000..e69de29b diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/anforderungen.json b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/anforderungen.json new file mode 100644 index 00000000..82e199fd --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/anforderungen.json @@ -0,0 +1,4623 @@ +[ + { + "id": "StRS-001", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Zentrale Geschäftspartnerverwaltung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020, SyRS-024", + "konsolidierung": "nein", + "pruefidee": "Partner als Kunde und Lieferant führen; alle Belegprozesse referenzieren denselben Stamm.", + "qm": "", + "uebernahme": "übernehmen - Fundament." + }, + { + "id": "StRS-002", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Durchgängige Angebots- und Auftragsabwicklung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-011, SyRS-015, SyRS-016", + "konsolidierung": "nein", + "pruefidee": "Kompletten Durchlauf Angebot→Rechnung ohne Neuerfassung der Positionen durchführen.", + "qm": "", + "uebernahme": "übernehmen - Kernprozess." + }, + { + "id": "StRS-003", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Korrekte und geschützte Fakturierung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-012, SyRS-014, SyRS-042, SyRS-050", + "konsolidierung": "nein", + "pruefidee": "Rechnung unter Mindestpreis ohne Freigabe; erwartet: verhindert.", + "qm": "", + "uebernahme": "übernehmen - Umsatz- und Compliance-Kern." + }, + { + "id": "StRS-004", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Vertragsgeschäft mit wiederkehrender Abrechnung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-037, SyRS-038, SyRS-039", + "konsolidierung": "nein", + "pruefidee": "Jahresvertrag mit Zähler; erwartet: 12 korrekte Perioden, keine Lücke/Doppel.", + "qm": "", + "uebernahme": "übernehmen - strategischer Umsatzträger." + }, + { + "id": "StRS-005", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Professioneller Kundensupport (Helpdesk)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-040, SyRS-041, SyRS-036", + "konsolidierung": "nein", + "pruefidee": "Ticket mit SLA-Verletzung; erwartet: dreistufige Eskalation.", + "qm": "", + "uebernahme": "übernehmen - Kernprozess des Systemhauses." + }, + { + "id": "StRS-006", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Lückenlose Leistungserfassung und -verrechnung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-039", + "konsolidierung": "nein", + "pruefidee": "Erfasste Zeit doppelt abrechnen; erwartet: verhindert.", + "qm": "", + "uebernahme": "übernehmen - direkter Umsatzhebel." + }, + { + "id": "StRS-007", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Effizienter Einkauf mit Distributorenanbindung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027; SwRS-091, SwRS-148", + "konsolidierung": "nein", + "pruefidee": "Unterschreitung Mindestbestand bis EDI-Bestellung durchspielen.", + "qm": "", + "uebernahme": "übernehmen - Kernprozess des IT-Handels." + }, + { + "id": "StRS-008", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Verlässliche Artikel- und Lagerführung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-013, SyRS-034; SwRS-112", + "konsolidierung": "nein", + "pruefidee": "Bestandsdifferenz erzeugen; erwartet: über Belege/Umbuchungslog aufklärbar.", + "qm": "", + "uebernahme": "übernehmen - Kernprozess." + }, + { + "id": "StRS-009", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Nahtlose Finanzprozesse (Zahlungen, FiBu, Mahnwesen)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-021, SyRS-032, SyRS-042, SyRS-050", + "konsolidierung": "nein", + "pruefidee": "Zahlungseingang bis DATEV-Export durchspielen; keine manuelle Doppelerfassung nötig.", + "qm": "", + "uebernahme": "übernehmen - Pflichtprozess." + }, + { + "id": "StRS-010", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Elektronischer Belegaustausch und E-Rechnung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-043, SyRS-027", + "konsolidierung": "nein", + "pruefidee": "ZUGFeRD-Rechnung gegen Validator prüfen.", + "qm": "", + "uebernahme": "übernehmen - gesetzlich getrieben." + }, + { + "id": "StRS-011", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Integrierte Versandabwicklung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-044", + "konsolidierung": "nein", + "pruefidee": "Label aus Lieferschein erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Logistikstandard." + }, + { + "id": "StRS-012", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Feingranulare Berechtigungssteuerung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-001, SyRS-002, SyRS-006, SyRS-007, SyRS-008", + "konsolidierung": "nein", + "pruefidee": "Stichprobe: Funktion ohne Recht aufrufen; erwartet: verweigert.", + "qm": "", + "uebernahme": "übernehmen - Sicherheitsfundament." + }, + { + "id": "StRS-013", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Sichere Anmeldung und API-Zugänge", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-003, SyRS-004, SyRS-005, SyRS-017, SyRS-046", + "konsolidierung": "nein", + "pruefidee": "Penetrationstest der Anmeldewege.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem modernisieren (Passworthashing!)." + }, + { + "id": "StRS-014", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Lizenz- und Modulsteuerung des Produkts", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-003; SwRS-009, SwRS-139", + "konsolidierung": "nein", + "pruefidee": "Anmeldung über Seat-Limit; erwartet: abgelehnt.", + "qm": "", + "uebernahme": "übernehmen - als SaaS-Abomodell neu umsetzen." + }, + { + "id": "StRS-015", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Professioneller Belegdruck und Berichte", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-025", + "konsolidierung": "nein", + "pruefidee": "Vorlage ändern; alle Folgedrucke nutzen neue Vorlage.", + "qm": "", + "uebernahme": "übernehmen - Pflicht." + }, + { + "id": "StRS-016", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Betriebswirtschaftliche Transparenz", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-021; SwRS-135", + "konsolidierung": "nein", + "pruefidee": "Umsatzstatistik gegen Belegsumme abstimmen.", + "qm": "", + "uebernahme": "übernehmen - Führungsinstrument." + }, + { + "id": "StRS-017", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Integrierte Kommunikation (E-Mail, Telefon, Chat)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-035, SyRS-036, SyRS-030", + "konsolidierung": "nein", + "pruefidee": "Eingehende Mail/Anruf; erwartet: Kontextzuordnung.", + "qm": "", + "uebernahme": "übernehmen - Effizienzkern." + }, + { + "id": "StRS-018", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Persönliche Arbeitsorganisation", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029", + "konsolidierung": "nein", + "pruefidee": "Fällige Objekte erscheinen in MyDay.", + "qm": "", + "uebernahme": "übernehmen - Produktivität." + }, + { + "id": "StRS-019", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Online-Self-Service für Endkunden", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-045, SyRS-002", + "konsolidierung": "nein", + "pruefidee": "Web-Account sieht nur eigene Tickets/Verträge.", + "qm": "", + "uebernahme": "übernehmen - Zielbild SaaS." + }, + { + "id": "StRS-020", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Dokumentenverwaltung mit digitaler Unterschrift", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-026, SyRS-022; SwRS-031, SwRS-107", + "konsolidierung": "nein", + "pruefidee": "AVV online bestätigen; erwartet: signiertes Dokument am Kunden.", + "qm": "", + "uebernahme": "übernehmen - Digitalisierungskern." + }, + { + "id": "StRS-021", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Offenheit für Drittsysteme (Konnektoren)", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027; SwRS-083", + "konsolidierung": "nein", + "pruefidee": "Fremd-ID an Objekt koppeln und rückwärts auflösen.", + "qm": "", + "uebernahme": "übernehmen - Ökosystem entscheidend." + }, + { + "id": "StRS-022", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Überblick über Kundengeräte und -infrastruktur", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-028", + "konsolidierung": "Kandidat: drei Gerätedatenhaltungen (siehe SyRS-028) - im Zielsystem ein Asset-Konzept", + "pruefidee": "Gerät über alle Sichten konsistent auffinden.", + "qm": "", + "uebernahme": "übernehmen - mit Konsolidierungsauflage." + }, + { + "id": "StRS-023", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Geordnete Reklamationsabwicklung (RMA)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-028; SwRS-059", + "konsolidierung": "nein", + "pruefidee": "RMA-Kette Kunde→Lieferant→Rückläufer verfolgen.", + "qm": "", + "uebernahme": "übernehmen - Handelskern." + }, + { + "id": "StRS-024", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Auftragsbezogene Fertigung (Assemblierung)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-013; SwRS-089", + "konsolidierung": "nein", + "pruefidee": "Fertigungsauftrag mit Protokollschritten abschließen.", + "qm": "", + "uebernahme": "übernehmen - sofern Geschäftsfeld bestätigt." + }, + { + "id": "StRS-025", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Projekt- und Chancenverfolgung (CRM)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020; SwRS-088, SwRS-090, SwRS-119", + "konsolidierung": "Kandidat: drei Projektbegriffe (Projects, CrmProjects, TicketProjects) zusammenführen", + "pruefidee": "Angebot mit Wahrscheinlichkeit klassifizieren; erscheint in Pipeline-Auswertung.", + "qm": "", + "uebernahme": "übernehmen - Vertriebssteuerung." + }, + { + "id": "StRS-026", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Zielgerichtetes Marketing (Kampagnen, Mailings, Telemarketing)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-035; SwRS-074, SwRS-103", + "konsolidierung": "nein", + "pruefidee": "Mailing an Zielgruppe mit Antwortdokumentation.", + "qm": "", + "uebernahme": "übernehmen - Basisumfang genügt ggf." + }, + { + "id": "StRS-027", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Schnelles Auffinden aller Informationen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-033", + "konsolidierung": "nein", + "pruefidee": "Suche nach Ticketinhalt liefert Treffer < definierte Zeit.", + "qm": "", + "uebernahme": "übernehmen - Nutzererwartung." + }, + { + "id": "StRS-028", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Sicherer Umgang mit Kundenzugangsdaten", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-017; SwRS-085, SwRS-086, SwRS-026", + "konsolidierung": "Kandidat: zwei Passwortmodule vereinigen", + "pruefidee": "Passwortzugriff hinterlässt Logeintrag; Siegelbruch sichtbar.", + "qm": "", + "uebernahme": "übernehmen - MSP-Vertrauensbasis." + }, + { + "id": "StRS-029", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "KI-Unterstützung im Tagesgeschäft", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-019", + "konsolidierung": "nein", + "pruefidee": "Ticketzusammenfassung erzeugen und fachlich bewerten.", + "qm": "", + "uebernahme": "übernehmen - Differenzierungsmerkmal." + }, + { + "id": "StRS-030", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Datenschutz und Nachvollziehbarkeit (DSGVO, Audit)", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-022, SyRS-009, SyRS-010", + "konsolidierung": "nein", + "pruefidee": "Löschantrag ausführen; Protokoll weist Durchführung nach.", + "qm": "", + "uebernahme": "übernehmen - gesetzlich." + }, + { + "id": "StRS-031", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Automatisierter, wartbarer Systembetrieb", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-018, SyRS-047, SyRS-048, SyRS-049", + "konsolidierung": "nein", + "pruefidee": "Update-Durchlauf mit Skriptausführung und Regressionstests.", + "qm": "Zuverlässigkeit, Übertragbarkeit", + "uebernahme": "übernehmen - Basis der SaaS-Fähigkeit." + }, + { + "id": "StRS-032", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Anpassbarkeit ohne Programmierung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "Prozessvariante rein per Konfiguration abbilden.", + "qm": "Wartbarkeit (Modifizierbarkeit)", + "uebernahme": "übernehmen - Produkt-DNA; Wildwuchs im Zielsystem eindämmen." + }, + { + "id": "StRS-033", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Mehrfirmen- und Filialbetrieb", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-024, SyRS-012", + "konsolidierung": "nein", + "pruefidee": "Zwei Mandanten mit getrennten Rechnungskreisen betreiben.", + "qm": "", + "uebernahme": "übernehmen - im SaaS als Mandantenmodell." + }, + { + "id": "SyRS-001", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Gruppenbasierte Benutzerrechteprüfung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012; SwRS-001, SwRS-008", + "konsolidierung": "Kandidat: SyRS-002 (getrenntes Rechtemodell für Web-Accounts bildet denselben fachlichen Gegenstand \"Berechtigung\" in zweiter Datenhaltung ab)", + "pruefidee": "Benutzer ohne Gruppenzuordnung zu einem Recht ruft die geschützte Funktion auf; erwartet: Ablehnung mit Fehlermeldung \"Benutzer hat nicht die passenden Rechte.\" (AppRightsBL.HasUserRightWithDefaultMessage).", + "qm": "", + "uebernahme": "übernehmen - gruppenbasierte Berechtigungsvergabe ist fachlicher Kern; numerische Alt-IDs können ersetzt werden." + }, + { + "id": "SyRS-002", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Getrenntes Rechtemodell für Web-Accounts", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-019, StRS-012; SwRS-001", + "konsolidierung": "Kandidat: SyRS-001 (zwei getrennte Datenhaltungen für den fachlichen Gegenstand \"Berechtigung\"; im Zielsystem prüfen, ob ein einheitliches Rollenmodell mit Benutzerkreis-Trennung genügt)", + "pruefidee": "Web-Account ohne Eintrag in WebAccountsRights für ein Web-Recht ruft die Funktion auf; erwartet: Ablehnung.", + "qm": "", + "uebernahme": "übernehmen - Trennung interner und externer Berechtigungen bleibt fachlich erforderlich, technische Vereinheitlichung möglich." + }, + { + "id": "SyRS-003", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Ticketbasierte Sitzungen mit Lizenzprüfung bei Anmeldung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013, StRS-014; SwRS-005", + "konsolidierung": "nein", + "pruefidee": "Anmeldung mit ausgeschöpfter Lizenzanzahl für die Application-GUID; erwartet: Fehlerresultat statt Ticket; zweite Anmeldung desselben Benutzers/derselben Maschine liefert dasselbe Ticket.", + "qm": "", + "uebernahme": "übernehmen - Sitzungs- und Lizenzsteuerung bleibt erforderlich; im SaaS-Zielsystem als Abonnement-/Seat-Prüfung." + }, + { + "id": "SyRS-004", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mehrere Authentifizierungsverfahren", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013; SwRS-002, SwRS-003", + "konsolidierung": "nein", + "pruefidee": "Für jede konfigurierte Verfahrensart eine Anmeldung durchführen; erwartet: identisches Ticketformat und identische nachgelagerte Rechteprüfung.", + "qm": "", + "uebernahme": "übernehmen - Verfahrensvielfalt (lokal + IdP) ist für SaaS weiterhin nötig; AD-Variante ggf. durch reines OIDC ersetzen." + }, + { + "id": "SyRS-005", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zwei-Faktor-Authentifizierung (RADIUS oder E-Mail-Link)", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013; SwRS-002, SwRS-003", + "konsolidierung": "Kandidat: SwRS-011 (separates TOTP-Modul TwoFactorAuthenticator bildet einen zweiten 2FA-Mechanismus ab)", + "pruefidee": "Login mit korrektem Passwort, aber abgelehntem zweitem Faktor; erwartet: Fehler \"Die Zwei-Faktor-Authentifizierung ist fehlgeschlagen.\" und kein Ticket.", + "qm": "", + "uebernahme": "übernehmen - 2FA ist sicherheitlich erforderlich; Verfahren im Zielsystem auf Standard (TOTP/WebAuthn) heben." + }, + { + "id": "SyRS-006", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zeitgesteuerte Deaktivierung von Benutzerkonten", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012, StRS-013", + "konsolidierung": "nein", + "pruefidee": "Konto mit AccountDisabledFromDate = gestern, ohne ToDate: Anmeldung heute wird abgelehnt; Konto mit AccountDisabledToDate = gestern: Anmeldung heute wird angenommen.", + "qm": "", + "uebernahme": "übernehmen - befristete Deaktivierung (z. B. Austritt, Sperrfristen) ist gängige Anforderung." + }, + { + "id": "SyRS-007", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Anwendungsbezogene Anmelderechte (erforderliche und ausschließende Rechte)", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012, StRS-013; SyRS-003", + "konsolidierung": "nein", + "pruefidee": "Benutzer mit DisallowingRight der Anwendung meldet sich an; erwartet: Fehlermeldung \"Login nicht erlaubt\" ohne Ticket.", + "qm": "", + "uebernahme": "übernehmen - kanalbezogene Zugangssteuerung bleibt sinnvoll." + }, + { + "id": "SyRS-008", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Ausliefern von Standard-Rechtegruppen (Rollenvorlagen)", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012; SwRS-008", + "konsolidierung": "nein", + "pruefidee": "ResetDefaultRightGroups ausführen und Gruppenbestand mit DefaultRightsStructure.txt abgleichen.", + "qm": "", + "uebernahme": "übernehmen - Rollenvorlagen erleichtern Einführung; Rechtelisten im Zielsystem neu schneiden." + }, + { + "id": "SyRS-009", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Änderungsnachverfolgung an allen Geschäftsobjekten", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-030; SwRS-007", + "konsolidierung": "nein", + "pruefidee": "Objekt anlegen und ändern; erwartet: CreatedBy bleibt stabil, ChangedBy/ChangedDate/ChangedVersion werden bei jeder Änderung aktualisiert.", + "qm": "Wartbarkeit (Nachvollziehbarkeit/Accountability nach ISO 25010: Sicherheit – Verantwortlichkeit)", + "uebernahme": "übernehmen - Änderungsmetadaten sind Compliance-Grundlage." + }, + { + "id": "SyRS-010", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Transaktionale Speicherung mit fachlichen Validierungshaken", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-030; SwRS-006", + "konsolidierung": "nein", + "pruefidee": "Speichern mit absichtlich fehlschlagendem DoAfterStoreTrans; erwartet: Rollback, kein Datensatz in DB, Result mit Fehlerstatus.", + "qm": "Zuverlässigkeit (Fehlertoleranz, Wiederherstellbarkeit)", + "uebernahme": "übernehmen - Grundprinzip der Datenintegrität." + }, + { + "id": "SyRS-011", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Durchgängige Belegkette mit definierten Weiterführungswegen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-002, StRS-003; SwRS-013", + "konsolidierung": "Kandidat: Das ältere Belegmodell unter src/backend/Centron.BL/Sales/CustomerAssets (OfferBL/OrderBL/InvoiceBL/DeliveryListBL) bildet dieselben Belegarten in zweiter Implementierung ab; im Zielsystem zu einem Belegmodell zusammenführen.", + "pruefidee": "Versuch, eine Gutschrift in einen Auftrag weiterzuführen; erwartet: Ablehnung. Angebot→Auftrag→Lieferschein→Rechnung durchspielen; erwartet: Positionsübernahme und Fortschrittsanzeige.", + "qm": "", + "uebernahme": "übernehmen - Belegkette ist fachlicher Kern des Vertriebsprozesses." + }, + { + "id": "SyRS-012", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Nummernkreise je Belegart, Mandant und Filiale", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-003, StRS-012; SwRS-010, SwRS-012", + "konsolidierung": "nein", + "pruefidee": "Rechnung in Filiale mit eigenem Kreis speichern → Nummer aus Filialkreis; Filiale ohne Kreis → Nummer aus Mandantenkreis.", + "qm": "", + "uebernahme": "übernehmen - GoBD-relevante Kernfunktion." + }, + { + "id": "SyRS-013", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Bestandswirkung der Belege", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-002, StRS-008, StRS-024; SwRS-014", + "konsolidierung": "nein", + "pruefidee": "Auftrag speichern → Bestand unverändert; denselben Auftrag zu Lieferschein weiterführen und speichern → Bestand um Positionsmenge reduziert; Gutschrift aus Rechnung → Bestand erhöht.", + "qm": "", + "uebernahme": "übernehmen - Kernregel der Warenwirtschaft." + }, + { + "id": "SyRS-014", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mindestpreisschutz mit autorisierter Überstimmung", + "typ": "funktional (Abrechnung/Fakturierung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-003; SwRS-015", + "konsolidierung": "nein", + "pruefidee": "Beleg mit Position unter Mindestpreis ohne Recht speichern; erwartet: Dialog/Fehler; mit Zweitanmeldung eines berechtigten Benutzers; erwartet: Speicherung mit unverändertem Preis.", + "qm": "", + "uebernahme": "übernehmen - Margenschutz ist fachlich gewollt; Re-Authentifizierung per Passwort im Zielsystem durch moderne Bestätigung ersetzen (Code-Kommentar: mit Azure-Authentifizierung nicht mehr funktionsfähig)." + }, + { + "id": "SyRS-015", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Belegsperren und optimistische Nebenläufigkeitskontrolle", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-002; SwRS-006", + "konsolidierung": "nein", + "pruefidee": "Beleg durch Benutzer A sperren, Änderungsversuch durch B; erwartet: Ablehnung; Feld-Update mit veralteter concurrencyControlGuid; erwartet: Konfliktfehler.", + "qm": "", + "uebernahme": "übernehmen - Mehrbenutzerschutz bleibt nötig; Mechanik im Web ggf. anders (etags/Versionen)." + }, + { + "id": "SyRS-016", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Belegversionierung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-002, StRS-030; SwRS-013", + "konsolidierung": "nein", + "pruefidee": "Rechnung ändern mit neuer Version; erwartet: alte Version weiterhin abrufbar, Ausdruck referenziert die Version.", + "qm": "", + "uebernahme": "übernehmen - Versionshistorie ist für Nachvollziehbarkeit und GoBD relevant." + }, + { + "id": "SyRS-017", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Persönliche API-Zugriffstokens mit Ablauf und Protokollierung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013, StRS-028; SwRS-021", + "konsolidierung": "nein", + "pruefidee": "Token mit ExpiresAt in der Vergangenheit validieren; erwartet: Ablehnung; DB-Inhalt enthält nur Hash, nicht das Token.", + "qm": "", + "uebernahme": "übernehmen - Standardmechanismus für API-Zugriff." + }, + { + "id": "SyRS-018", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Steuerbare Hintergrunddienste mit Laufzeitüberwachung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031; SwRS-024", + "konsolidierung": "nein", + "pruefidee": "Dienst deaktivieren; erwartet: IsServiceEnabled=false und kein weiterer Lauf; LastRunTime bleibt stehen.", + "qm": "", + "uebernahme": "übernehmen - Betriebssteuerung der Automatisierung." + }, + { + "id": "SyRS-019", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "KI-Assistenz mit konfigurierbarem Modellanbieter", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-029; SwRS-023", + "konsolidierung": "nein", + "pruefidee": "Ticket mit Verlauf zusammenfassen lassen; erwartet: generierter Text; DB-Inspektion: WebSearchApiKey nicht im Klartext.", + "qm": "", + "uebernahme": "übernehmen - KI-Unterstützung ist strategische Funktion." + }, + { + "id": "SyRS-020", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Verwaltung des Konten-/Adressstamms (Kunden und Lieferanten)", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, StRS-025; SwRS-020", + "konsolidierung": "nein", + "pruefidee": "Konto als Kunde und Lieferant führen; erwartet: beide Rollen nutzbar, Entfernen einer Rolle über RemoveAccountTypeFromAccount.", + "qm": "", + "uebernahme": "übernehmen - zentraler Stammdatenkern." + }, + { + "id": "SyRS-022", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "DSGVO-Funktionen: Löschkonzept und Datenbereinigung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-030; SwRS-030", + "konsolidierung": "nein", + "pruefidee": "Kontakt DSGVO-löschen; erwartet: Ersatztext statt Personendaten, Protokolleintrag; ohne Recht: Ablehnung.", + "qm": "", + "uebernahme": "übernehmen - gesetzliche Pflicht." + }, + { + "id": "SyRS-023", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zentrale typisierte Anwendungskonfiguration", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-032; SwRS-040", + "konsolidierung": "nein", + "pruefidee": "Einstellung ändern (z. B. SaveWithoutAllSN) und Verhaltensänderung im abhängigen Modul nachweisen.", + "qm": "Wartbarkeit (Modifizierbarkeit)", + "uebernahme": "übernehmen - Konfigurierbarkeit ist Produktkern; Katalog im Zielsystem bereinigen." + }, + { + "id": "SyRS-024", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mehrmandanten- und Filialstruktur", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-033; SwRS-012, SwRS-016, SwRS-027", + "konsolidierung": "nein", + "pruefidee": "Zwei Filialen mit eigenen Nummernkreisen und Erlöskonten anlegen; Belege je Filiale erhalten unterschiedliche Kreise/Konten.", + "qm": "", + "uebernahme": "übernehmen - Mehrfirmenbetrieb ist für die Zielgruppe (Systemhäuser) üblich." + }, + { + "id": "SyRS-021", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "FiBu-Übergabe (DATEV-Formate) mit Übertragungsnachweis", + "typ": "Schnittstelle (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-009, StRS-016; SwRS-057, SwRS-058, SwRS-025", + "konsolidierung": "nein", + "pruefidee": "Beleg exportieren, erneuten Export im Zeitraum anfordern; erwartet: Beleg als „übertragen\" ausgefiltert; Exportdatei entspricht DATEV-Formatdefinition.", + "qm": "", + "uebernahme": "übernehmen - DATEV-Übergabe ist im DACH-Markt zwingend." + }, + { + "id": "SyRS-025", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Report-Engine für Belegdruck und PDF-Erzeugung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-015; SwRS-025, SwRS-038", + "konsolidierung": "nein", + "pruefidee": "Rechnung drucken mit \"PDF zu Belegdokumenten\"; erwartet: PDF-Datei am Beleg.", + "qm": "", + "uebernahme": "übernehmen - Belegdruck ist Pflicht; Engine im Web neu wählen." + }, + { + "id": "SyRS-026", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zentrale Dokumenten- und Verzeichnisverwaltung je Objekt", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-020; SwRS-031, SwRS-044, SwRS-056", + "konsolidierung": "nein", + "pruefidee": "Neues Konto anlegen; erwartet: Standardverzeichnisstruktur; Beleg-PDF landet im Belegverzeichnis.", + "qm": "", + "uebernahme": "übernehmen - DMS-Grundfunktion; im SaaS als Objektspeicher." + }, + { + "id": "SyRS-027", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Elektronische Bestellübertragung an Distributoren (EDI)", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-010, StRS-007, StRS-021; SwRS-060, SwRS-045", + "konsolidierung": "Kandidat: Centron.Gateway/EDI_* (zweite EDI-Schicht) - Zuordnung Gateway vs. BL im Zielsystem vereinheitlichen", + "pruefidee": "Testbestellung an EGIS erzeugen; erwartet: valides XML, Logeintrag, Bestätigungsverarbeitung.", + "qm": "", + "uebernahme": "übernehmen - EDI mit Distributoren ist Kernprozess des IT-Handels." + }, + { + "id": "SyRS-028", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Verwaltung der beim Kunden befindlichen Geräte/Assets", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-022, StRS-023; SwRS-054, SwRS-055", + "konsolidierung": "Kandidat: AccountDevices vs. CustomerAssets/Stammblätter vs. DocuBoard-Assets - im Zielsystem ein einheitliches Asset-Konzept", + "pruefidee": "Gerät in allen drei Sichten anlegen/finden; erwartet: (heute) getrennte Datensätze - Konsolidierungsnachweis.", + "qm": "", + "uebernahme": "übernehmen - fachlich zwingend, technisch zu konsolidieren." + }, + { + "id": "SyRS-029", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Persönliche Organisation und Zusammenarbeit", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-018; SwRS-043, SwRS-046, SwRS-049, SwRS-050", + "konsolidierung": "nein", + "pruefidee": "ToDo zu einem Beleg anlegen; erwartet: erscheint in MyDay/Benachrichtigungen des Zuständigen.", + "qm": "", + "uebernahme": "übernehmen - Produktivitätskern; Umfang im Zielsystem priorisieren." + }, + { + "id": "SyRS-030", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Telefonie-Integration (TAPI) mit Anrufdatenerfassung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-017; SwRS-037", + "konsolidierung": "nein", + "pruefidee": "Simulierter Anruf mit bekannter Nummer; erwartet: Kundenzuordnung.", + "qm": "", + "uebernahme": "Workaround - TAPI ist Desktop-gebunden; im Web-Zielsystem durch CTI-/WebRTC-Dienst ersetzen, Funktion bleibt." + }, + { + "id": "SyRS-031", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mehrkanal-Clients auf gemeinsamer Geschäftslogik", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-019; SwRS-047, SwRS-048", + "konsolidierung": "Kandidat: Desktop- und Webclient implementieren dieselben Masken doppelt; Zielsystem = ein Web-Frontend", + "pruefidee": "Dieselbe Rechteprüfung (z. B. Ticketsicht) in Desktop und Web auslösen; erwartet: identisches Verhalten.", + "qm": "Übertragbarkeit (Anpassbarkeit), Kompatibilität (Interoperabilität)", + "uebernahme": "übernehmen - Zielarchitektur ist Web/SaaS mit derselben API." + }, + { + "id": "SyRS-032", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Onlinebanking-Zahlungsabgleich mit Buchung und Stornierung", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-009; SwRS-065, SwRS-066", + "konsolidierung": "nein", + "pruefidee": "Umsatz mit Rechnungsnummer im Verwendungszweck importieren; erwartet: Zuordnungsvorschlag zur Rechnung; Buchung setzt Beleg auf bezahlt; Undo stellt Zustand wieder her.", + "qm": "", + "uebernahme": "übernehmen - zentrale Automatisierung der Debitorenbuchhaltung." + }, + { + "id": "SyRS-033", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Volltextsuche über zentrale Geschäftsobjekte", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-027; SwRS-068", + "konsolidierung": "nein", + "pruefidee": "Ticket ändern, RequestUpdateFor auslösen; erwartet: Treffer mit neuem Text.", + "qm": "", + "uebernahme": "übernehmen - übergreifende Suche ist Erwartungsstandard." + }, + { + "id": "SyRS-034", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Regelbasierte Massenänderungen (Preise)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-008; SwRS-075", + "konsolidierung": "nein", + "pruefidee": "Vorlage auf Artikelgruppe anwenden; erwartet: alle Artikelpreise gemäß Regel geändert.", + "qm": "", + "uebernahme": "übernehmen - Effizienzfunktion." + }, + { + "id": "SyRS-035", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "E-Mail-Versand und Exchange-Integration", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-017, StRS-026; SwRS-072", + "konsolidierung": "nein", + "pruefidee": "Mail an geblacklistete Domain; erwartet: Ablehnung/Warnung; Signaturplatzhalter werden ersetzt.", + "qm": "", + "uebernahme": "übernehmen - E-Mail bleibt Hauptkanal; EWS durch Graph-API ablösen (GraphServiceClientHelper existiert bereits)." + }, + { + "id": "SyRS-036", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Automatisierte Postfachverarbeitung (Mail-Scanner)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-017, StRS-005; SwRS-073", + "konsolidierung": "Kandidat: Services/Workflows (allgemeine Workflow-Engine) - zwei Workflow-Mechanismen", + "pruefidee": "Testmail an überwachtes Postfach; erwartet: Workflow-Aktion (z. B. Ticket) wird ausgeführt.", + "qm": "", + "uebernahme": "übernehmen - Automatisierung des Posteingangs ist Kernnutzen." + }, + { + "id": "SyRS-037", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Vertragsverwaltung mit Laufzeit, Verlängerung und Abrechnungsintervallen", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-004; SwRS-092, SwRS-093", + "konsolidierung": "nein", + "pruefidee": "Quartalsvertrag anlegen; erwartet: Abrechnungszeitraum je Rechnung = 3 Monate; Rechnungsposition liefert Periode.", + "qm": "", + "uebernahme": "übernehmen - Kern des Servicegeschäfts." + }, + { + "id": "SyRS-038", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Automatische Vertragsfakturierung inkl. Zählerstände und Sammelrechnungen", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-004, StRS-003; SwRS-094", + "konsolidierung": "nein", + "pruefidee": "Vertrag mit Zählerartikel und Stichtag in der Vergangenheit; erwartet: Kunde erscheint in der Abrechnungssuche, Rechnung enthält Zählerdifferenz.", + "qm": "", + "uebernahme": "übernehmen - zentrales MSP-/Vertragsgeschäft." + }, + { + "id": "SyRS-039", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Leistungserfassung am Ticket und Abrechnung über Timer-Billing", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-006, StRS-005; SwRS-095", + "konsolidierung": "nein", + "pruefidee": "Zwei Timer abrechnen; erwartet: Beleg mit zwei Leistungspositionen, Timer-Status wechselt auf abgerechnet.", + "qm": "", + "uebernahme": "übernehmen - Kern der Dienstleistungsabrechnung." + }, + { + "id": "SyRS-040", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Helpdesk-Ticketsystem mit rechtebasierter Sichtbarkeit und Statusfluss", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-005, StRS-012; SwRS-096, SwRS-097", + "konsolidierung": "nein", + "pruefidee": "Benutzer mit SHOW_HELPDESK_ONLY_OWN sieht fremde Tickets nicht; Abschluss ohne CLOSE_REQUEST wird verweigert.", + "qm": "", + "uebernahme": "übernehmen - Kernprozess mit ausgereiftem Rechtemodell." + }, + { + "id": "SyRS-041", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mehrstufige Ticket-Eskalation", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-005; SwRS-098", + "konsolidierung": "nein", + "pruefidee": "Ticket über Stufe-1-Frist altern lassen; erwartet: Eskalation1Am gesetzt, Empfänger benachrichtigt; Stufe 2 folgt fristgerecht.", + "qm": "", + "uebernahme": "übernehmen - SLA-Sicherung." + }, + { + "id": "SyRS-042", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kassenbuch mit automatischen Buchungen aus Barbelegen", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-003, StRS-009; SwRS-100", + "konsolidierung": "nein", + "pruefidee": "Barrechnung mit 7%- und 19%-Positionen; erwartet: zwei Kassenbuchbuchungen mit passenden Steuerschlüsseln, ReadOnly.", + "qm": "", + "uebernahme": "übernehmen - Kassenführung ist gesetzlich relevant." + }, + { + "id": "SyRS-043", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Elektronische Rechnungsformate (ZUGFeRD, XRechnung, ebInterface)", + "typ": "Schnittstelle (Abrechnung)", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-010, StRS-003; SwRS-150", + "konsolidierung": "nein", + "pruefidee": "Rechnung mit ZUGFeRD-Reportgruppe drucken; erwartet: PDF mit eingebettetem Factur-X-XML, das gegen die XSD validiert.", + "qm": "", + "uebernahme": "übernehmen - E-Rechnungspflicht macht dies zwingend." + }, + { + "id": "SyRS-044", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Versanddienstleister-Anbindung (GLS, Shipcloud)", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-011; SwRS-151", + "konsolidierung": "Kandidat: GLS-Direktanbindung vs. Shipcloud (Multi-Carrier) - im Zielsystem ein Versandabstraktionsweg", + "pruefidee": "Testsendung gegen GLS-QS-Umgebung; erwartet: UploadResult mit Labeldaten.", + "qm": "", + "uebernahme": "übernehmen - Versandprozess ist Kern der Logistik." + }, + { + "id": "SyRS-045", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kundenportal mit Shop, Tickets, Formularen und Dokumenten", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-019; SwRS-145, SwRS-129", + "konsolidierung": "Kandidat: SelfCare-Formulare (SwRS-108) - zwei Formularwege für Endkunden", + "pruefidee": "Web-Account meldet sich an, öffnet Shop; erwartet: nur Artikel der Kunden-Sonderpreise; Ticketliste zeigt nur eigene Tickets.", + "qm": "", + "uebernahme": "übernehmen - zentrales Zielbild der Web-/SaaS-Version." + }, + { + "id": "SyRS-046", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "REST-API mit deklarativer Rechte-Autorisierung je Endpunkt", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013, StRS-012; SwRS-147, SwRS-001", + "konsolidierung": "nein", + "pruefidee": "Endpunkt mit AuthorizeUserRight ohne das Recht aufrufen; erwartet: 403 vor Ausführung.", + "qm": "", + "uebernahme": "übernehmen - Muster für Zielsystem-API." + }, + { + "id": "SyRS-047", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Containerisierter Serverbetrieb", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031; SwRS-157", + "konsolidierung": "nein", + "pruefidee": "compose-Stack starten; erwartet: erreichbarer Webservice mit Konfiguration aus WebServiceConfig.xml.", + "qm": "Übertragbarkeit (Installierbarkeit)", + "uebernahme": "übernehmen - direkter Baustein der SaaS-Migration." + }, + { + "id": "SyRS-048", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Windows-Installer für Client-Verteilung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031; SwRS-156", + "konsolidierung": "nein", + "pruefidee": "Installer bauen; erwartet: signiertes MSI.", + "qm": "Übertragbarkeit (Installierbarkeit)", + "uebernahme": "veraltet - entfällt bei reiner Web-Auslieferung; bis dahin nötig." + }, + { + "id": "SyRS-049", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mehrstufige automatisierte Testabdeckung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031; SwRS-157", + "konsolidierung": "nein", + "pruefidee": "Testläufe in CI ausführen; erwartet: alle Suiten laufen gegen die Regressions-DB.", + "qm": "Wartbarkeit (Testbarkeit)", + "uebernahme": "übernehmen - Testbestand als Verhaltensreferenz für die Migration nutzen." + }, + { + "id": "SyRS-050", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "[HYPOTHESE] Mahnwesen mit drei Mahnstufen und Belegsperre", + "typ": "funktional (Abrechnung)", + "belege": [ + "SEKUNDÄR" + ], + "status": "HYPOTHESE (fehlend: durchsetzende Mahnlauf-Klasse/Methode; vermutlich in Finances oder Statistics, in diesem Lauf nicht aufgefunden)", + "hypothese": true, + "workaround": false, + "tracelinks": "StRS-009, StRS-003", + "konsolidierung": "nein", + "pruefidee": "Überfällige Rechnung mahnen; erwartet: Stufentext gemäß Einstellung; Beleganlage nach Schwellstufe wird verweigert.", + "qm": "", + "uebernahme": "übernehmen - Mahnwesen ist Pflicht; Detailregeln in Folgeiteration am Code verifizieren." + }, + { + "id": "SwRS-001", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Rechteermittlung per SQL mit Sitzungscache", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-001, SyRS-002", + "konsolidierung": "nein", + "pruefidee": "Recht während laufender Sitzung entziehen; erwartet: Entscheidung ändert sich erst nach neuer Sitzung (Cache-Verhalten dokumentieren/testen).", + "qm": "", + "uebernahme": "übernehmen - Caching-Strategie ist auch im Zielsystem nötig; Invalidierung bei Rechteänderung ergänzen." + }, + { + "id": "SwRS-002", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Passwortablage als ungesalzener SHA1-Hash", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-004", + "konsolidierung": "nein", + "pruefidee": "Zwei Benutzer mit gleichem Passwort erzeugen identische Hashwerte in Sichbenu.Password (Nachweis fehlenden Salts).", + "qm": "", + "uebernahme": "veraltet - ungesalzenes SHA1 ist kryptographisch überholt; im Zielsystem durch modernes Verfahren (z. B. Argon2/bcrypt) ersetzen, Funktion „lokales Passwort\" bleibt." + }, + { + "id": "SwRS-003", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Konfigurationsgesteuerte Wahl des Zwei-Faktor-Validators", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-005", + "konsolidierung": "nein", + "pruefidee": "Konfiguration auf EmailLink stellen; erwartet: Anmeldung fordert E-Mail-Bestätigung an statt RADIUS-Abfrage.", + "qm": "", + "uebernahme": "übernehmen - Austauschbarkeit der 2FA-Verfahren beibehalten." + }, + { + "id": "SwRS-004", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Verwaltung von Rechtegruppen und Zuordnungen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-001, SyRS-008", + "konsolidierung": "nein", + "pruefidee": "Gruppe kopieren und prüfen, dass Rechte- und Mitgliederliste identisch übernommen werden und ein Log-Eintrag entsteht.", + "qm": "", + "uebernahme": "übernehmen - administrative Kernfunktion." + }, + { + "id": "SwRS-005", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Wiederverwendung bestehender Sitzungstickets und Login-Protokollierung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-003", + "konsolidierung": "nein", + "pruefidee": "Zweite Anmeldung derselben Kombination liefert dasselbe Ticket; Lizenzzähler bleibt unverändert.", + "qm": "", + "uebernahme": "übernehmen - Verhalten für Seat-basierte Lizenzierung erforderlich." + }, + { + "id": "SwRS-006", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Speicher-Template mit Vor- und Nachbedingungen (DoBefore/DoAfter)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010", + "konsolidierung": "nein", + "pruefidee": "Fach-BL mit überschriebenem DoBeforeStoreTrans, das Fehler liefert; erwartet: kein Insert, Result mit Fehler.", + "qm": "", + "uebernahme": "übernehmen - als Muster (nicht 1:1-Code) ins Zielsystem." + }, + { + "id": "SwRS-007", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Erstellungs-/Änderungsmetadaten auf Entitätsebene", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-009", + "konsolidierung": "nein", + "pruefidee": "Datensatz durch Benutzer A anlegen, durch B ändern; erwartet: CreatedBy=A.Employee, ChangedBy=B.Employee.", + "qm": "", + "uebernahme": "übernehmen - Regel bleibt; obsolete AppUser-Variante nicht migrieren." + }, + { + "id": "SwRS-008", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Standard-Rechtegruppen aus eingebetteter Strukturdatei", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-008", + "konsolidierung": "nein", + "pruefidee": "Strukturdatei um ein Recht erweitern, Reset ausführen; erwartet: Gruppe enthält das Recht.", + "qm": "", + "uebernahme": "übernehmen - Mechanik „Rollenvorlagen als Daten\" ist tragfähig." + }, + { + "id": "SwRS-009", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Signaturvalidierte Lizenzdatei mit Produkt- und Versionsbindung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-003", + "konsolidierung": "nein", + "pruefidee": "Lizenzdatei mit zu niedriger Maximalversion einspielen; erwartet: CheckLicense liefert Fehler, Anmeldung der Anwendung wird abgelehnt.", + "qm": "", + "uebernahme": "Workaround - dateibasierte Lizenzierung ist Client-Server-Erbe; im SaaS-Zielsystem durch Abonnementverwaltung ersetzen, fachliche Regel (Seat-/Produktbindung) bleibt." + }, + { + "id": "SwRS-010", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Belegnummernvergabe mit Sonderfall Vorlagenkunde", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-012", + "konsolidierung": "nein", + "pruefidee": "Beleg für den Template-Kunden speichern; erwartet: Vorlagen-Nummer, Nummernkreiszähler unverändert.", + "qm": "", + "uebernahme": "Sonderfall - Vorlagen über speziellen „Kunden\" abzubilden ist ein historischer Behelf; im Zielsystem eigenes Vorlagenkonzept." + }, + { + "id": "SwRS-011", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "TOTP-Zweitfaktor über hinterlegten Schlüssel (Google Authenticator)", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-005", + "konsolidierung": "Kandidat: SyRS-005 (zweiter, paralleler 2FA-Mechanismus neben RADIUS/E-Mail-Link; im Zielsystem auf ein 2FA-Framework konsolidieren)", + "pruefidee": "PIN mit korrektem/inkorrektem TOTP-Code prüfen; erwartet: Success bzw. „Die eingegebene PIN ist ungültig!\".", + "qm": "", + "uebernahme": "übernehmen - TOTP ist der zeitgemäße der vorhandenen 2FA-Wege." + }, + { + "id": "SwRS-012", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Auflösungskaskade der Nummernkreise", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-012", + "konsolidierung": "nein", + "pruefidee": "Kreis nur am Standardmandanten pflegen; Anfrage mit Filiale ohne eigenen Kreis; erwartet: Kreis des Standardmandanten.", + "qm": "", + "uebernahme": "übernehmen - Fallback-Kaskade vermeidet Pflegeaufwand." + }, + { + "id": "SwRS-013", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Belegartspezifische Strategieobjekte (IReceiptSpecificLogic)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-011, SyRS-013", + "konsolidierung": "nein", + "pruefidee": "Für jede Belegart die Strategieantworten (Nummernkreis, Bestandswirkung, Weiterführung) tabellarisch gegen die Implementierung prüfen.", + "qm": "", + "uebernahme": "übernehmen - als Architekturprinzip für das Zielsystem geeignet." + }, + { + "id": "SwRS-014", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Negativbuchungen nur mit gesondertem Recht und Warnung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-013, SyRS-001", + "konsolidierung": "nein", + "pruefidee": "Rechnung über mehr als den verfügbaren Bestand ohne Recht; erwartet: Ablehnung; mit Recht: Warnung und Buchung.", + "qm": "", + "uebernahme": "übernehmen - Schutz der Bestandsführung." + }, + { + "id": "SwRS-015", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Mindestpreisprüfung: Ausnahme nur nach Re-Authentifizierung", + "typ": "Sicherheit (Abrechnung)", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-014", + "konsolidierung": "nein", + "pruefidee": "Zweitanmeldung mit Benutzer ohne Recht; erwartet: Meldung und keine Ausnahme; mit Recht: Preis bleibt unter Mindestpreis.", + "qm": "", + "uebernahme": "Workaround - Vier-Augen-Freigabe fachlich übernehmen, technische Umsetzung (Passwort-Zweitanmeldung) ersetzen." + }, + { + "id": "SwRS-016", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Filialzuordnung neuer Kundenbelege nach konfigurierter Herkunft", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-012", + "konsolidierung": "nein", + "pruefidee": "BranchOrigin=Adviser2 setzen, Beleg durch Benutzer anderer Filiale anlegen; erwartet: Filiale des Vertriebsmitarbeiters.", + "qm": "", + "uebernahme": "übernehmen - filialgenaue Zuordnung ist Berichts- und Nummernkreisbasis." + }, + { + "id": "SwRS-017", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Konfigurierbare Seriennummern-Vollständigkeitsprüfung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-013", + "konsolidierung": "nein", + "pruefidee": "Rechnung mit fehlender Seriennummer speichern (Schalter aus); erwartet: Ablehnung; Schalter an: Speichern möglich.", + "qm": "", + "uebernahme": "übernehmen - Seriennummernverfolgung ist für IT-Handel zentral." + }, + { + "id": "SwRS-018", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Beleg-Einstellungen der Firmengruppe (Konzernkunden)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-011", + "konsolidierung": "nein", + "pruefidee": "Konto mit gesetztem Flag und abweichenden Gruppeneinstellungen; erwartet: Beleg nutzt Gruppenwerte.", + "qm": "", + "uebernahme": "übernehmen - Konzernstrukturen sind im B2B-Handel üblich." + }, + { + "id": "SwRS-019", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Bankverbindungen: Rechteprüfung, Gültigkeitszeitraum und eindeutige Standardverbindung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-001; SyRS-020", + "konsolidierung": "nein", + "pruefidee": "Zweite Bankverbindung als Standard markieren; erwartet: vorherige verliert IsDefault; Speichern ohne Recht: Fehlermeldung \"Fehlendes Recht ...\".", + "qm": "", + "uebernahme": "übernehmen - Zahlungsverkehrsgrundlage (SEPA-Mandate referenzieren Bankverbindungen)." + }, + { + "id": "SwRS-020", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kontenstamm: operationsbezogene Rechteprüfung und FiBu-Nummernkopplung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-001; SyRS-020", + "konsolidierung": "nein", + "pruefidee": "Konto ohne Editierrecht speichern; erwartet: Ablehnung; Schalter aktiv, neues Konto: BookKeepingNumber == CustomerNumber.", + "qm": "", + "uebernahme": "übernehmen - Kernstammdatenpflege." + }, + { + "id": "SwRS-021", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "API-Token: Hash-Speicherung, Ablauf, Lizenzzählung, Aktionslog", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-017", + "konsolidierung": "nein", + "pruefidee": "Erzeugtes Token in DB suchen; erwartet: nur Hash; Validierung nach Ablaufdatum; erwartet: Fehler.", + "qm": "", + "uebernahme": "übernehmen - Stand der Technik." + }, + { + "id": "SwRS-022", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Protokollierung der Client-Version je Anmeldung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-003", + "konsolidierung": "nein", + "pruefidee": "Anmeldung mit definierter Versionsnummer; erwartet: Datensatz mit Version/Maschine.", + "qm": "", + "uebernahme": "übernehmen - für Update-/Kompatibilitätssteuerung nützlich." + }, + { + "id": "SwRS-023", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Verwaltung von KI-Prompts und verschlüsselten API-Schlüsseln", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-019", + "konsolidierung": "nein", + "pruefidee": "WebSearch-Key speichern und DB prüfen (verschlüsselt); Prompt je Aktions-ID anlegen und in der Aktion abrufen.", + "qm": "", + "uebernahme": "übernehmen - Konfigurierbarkeit der KI ist erforderlich; einheitliche Verschlüsselung aller Schlüssel prüfen." + }, + { + "id": "SwRS-024", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Persistenter Betriebszustand je Hintergrunddienst", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-018", + "konsolidierung": "nein", + "pruefidee": "Dienstlauf simulieren; erwartet: LastRunTime aktualisiert.", + "qm": "", + "uebernahme": "übernehmen - Monitoring-Grundlage." + }, + { + "id": "SwRS-025", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Verwaltung von Buchhaltungs-Kontenrahmen und Konten", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-021", + "konsolidierung": "nein", + "pruefidee": "Zweiten Kontenrahmen anlegen; erwartet: getrennte Kontenlisten; Default-Abfrage liefert Standardrahmen.", + "qm": "", + "uebernahme": "übernehmen - Voraussetzung der FiBu-Integration." + }, + { + "id": "SwRS-026", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zentrale Konfigurationsdatenbank mit Master-Passwort-Verschlüsselung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-017; StRS-028", + "konsolidierung": "Kandidat: SwRS-023 (AESCryptoLogic) und Passwortmanagement (M-073) verwenden eigene Verschlüsselungswege für denselben Zweck „geheime Werte schützen\"", + "pruefidee": "Text ver- und entschlüsseln; ohne Master-Key: Entschlüsselung schlägt fehl.", + "qm": "", + "uebernahme": "übernehmen - zentrales Secret-Handling; im Zielsystem durch Managed-Key-Dienst ersetzen." + }, + { + "id": "SwRS-027", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kollisionssichere Vergabe fortlaufender Nummern", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-012, SyRS-024", + "konsolidierung": "nein", + "pruefidee": "Zwei parallele Nummernanforderungen; erwartet: zwei verschiedene Nummern, kein Duplikat.", + "qm": "", + "uebernahme": "übernehmen - GoBD-relevante Eindeutigkeit." + }, + { + "id": "SwRS-028", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Verwaltung der Datenbank-/Webservice-Verbindungen", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-003", + "konsolidierung": "nein", + "pruefidee": "Standardverbindung auf Webservice stellen; erwartet: Client nutzt Webservice-Pfad.", + "qm": "", + "uebernahme": "veraltet - Zwei-Wege-Zugriff (direkt/Webservice) entfällt im SaaS-Zielsystem; dort nur noch API-Zugriff." + }, + { + "id": "SwRS-029", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kundenindividuelle Zusatzfelder je Modul mit Suche", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "Kandidat: M-043 CustomTables (zweiter Mechanismus für kundenindividuelle Datenstrukturen)", + "pruefidee": "Zusatzfeld am Kunden anlegen, Wert setzen, per Suche wiederfinden.", + "qm": "", + "uebernahme": "übernehmen - Customizing-Fähigkeit ist Produktmerkmal." + }, + { + "id": "SwRS-030", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "DSGVO-Kontaktlöschung mit Ersatztext und Löschprotokoll", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-022", + "konsolidierung": "nein", + "pruefidee": "Ansprechpartner löschen; erwartet: Name/Kontaktdaten durch Ersatztext ersetzt, Protokolleintrag mit Benutzer und Zeit.", + "qm": "", + "uebernahme": "übernehmen - gesetzliche Pflicht." + }, + { + "id": "SwRS-031", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Online-Bestätigung von DSGVO-/SEPA-Dokumenten", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-022; StRS-020", + "konsolidierung": "Kandidat: Beleg-Signierprozess über Nexus (ReceiptBL SendSignDocument, SharedDocument) - zweiter Online-Signaturweg", + "pruefidee": "SEPA-Dokument bestätigen; erwartet: Unterschrift und IBAN gespeichert; Ablehnung erfasst Grund.", + "qm": "", + "uebernahme": "übernehmen - digitale Vertragsprozesse sind Zielbild." + }, + { + "id": "SwRS-032", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Mitarbeiterverwaltung mit Abteilungen, Skills und Einstellungsprofilen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020; StRS-012", + "konsolidierung": "nein", + "pruefidee": "Mitarbeiter mit Skill anlegen und in abhängiger Funktion (z. B. Zuweisungsvorschlag) wiederfinden.", + "qm": "", + "uebernahme": "übernehmen - organisatorische Basisdaten." + }, + { + "id": "SwRS-033", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Datenbank-Umgebungsprüfungen beim Start", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "Webservice gegen fremde DB starten; erwartet: Fehlermeldung der Versions-/Zuordnungsprüfung.", + "qm": "Zuverlässigkeit (Reife)", + "uebernahme": "übernehmen - Startprüfungen erhöhen Betriebssicherheit." + }, + { + "id": "SwRS-034", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zahlungs- und Belegkonditionen als Stammdaten (AssetCondition)", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-011", + "konsolidierung": "nein", + "pruefidee": "Kondition als Bar-Kondition markieren; erwartet: nur in Barbelegen wählbar.", + "qm": "", + "uebernahme": "übernehmen - Konditionsstammdaten bleiben erforderlich." + }, + { + "id": "SwRS-035", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Netzwerkdiagnose für Support-Zwecke", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "Diagnose gegen erreichbaren/unerreichbaren SQL-Server; erwartet: differenzierte Befunde.", + "qm": "Wartbarkeit (Analysierbarkeit)", + "uebernahme": "Workaround - On-Premise-Diagnose entfällt weitgehend im SaaS-Betrieb." + }, + { + "id": "SwRS-036", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Persistente Performance- und Profiling-Messungen", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "Messlauf ausführen; erwartet: persistierter Messdatensatz.", + "qm": "Performance-Effizienz (Zeitverhalten)", + "uebernahme": "Workaround - im Zielsystem durch APM-Werkzeuge ersetzen." + }, + { + "id": "SwRS-037", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Globale und persönliche Telefonie-Einstellungen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-030", + "konsolidierung": "nein", + "pruefidee": "Persönliche Einstellung setzen; erwartet: weicht von globaler ab und wirkt nur für den Benutzer.", + "qm": "", + "uebernahme": "übernehmen - Telefonie-Integration bleibt gefragt (im Web über CTI-Dienste)." + }, + { + "id": "SwRS-038", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Hersteller-Portal: Kundenstatusprüfung und Report-Upload", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-025", + "konsolidierung": "nein", + "pruefidee": "Upload ohne Sonderrecht; erwartet: Ablehnung.", + "qm": "", + "uebernahme": "Sonderfall - herstellerinterner Vertriebskanal; im Zielsystem neu bewerten." + }, + { + "id": "SwRS-039", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Versionsgebundene Wartungsskripte und wiederkehrende Datenkorrekturen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023, SyRS-018", + "konsolidierung": "nein", + "pruefidee": "Land mit IsEUMember=NULL anlegen; nach Recurring-Lauf: Wert gesetzt.", + "qm": "", + "uebernahme": "übernehmen - Migrationsmechanik als Konzept; konkrete Fix-Skripte sind Workarounds für Altdatenqualität und einzeln zu bewerten." + }, + { + "id": "SwRS-040", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Typisierter Einstellungszugriff über SettingsCollection", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "Bool-Setting über GetBool lesen; erwartet: korrekte Typkonvertierung aus dem generischen Feld.", + "qm": "", + "uebernahme": "übernehmen - Muster für Zielsystem." + }, + { + "id": "SwRS-041", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Verwaltung von UI-Themes mit Standardtheme", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "Theme deaktivieren; erwartet: nicht mehr wählbar; Standardtheme greift ohne Benutzerwahl.", + "qm": "", + "uebernahme": "übernehmen - Theming im Web über Designsystem." + }, + { + "id": "SwRS-042", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zentrale Webservice-Konfigurationsdatei", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023, SyRS-005", + "konsolidierung": "nein", + "pruefidee": "ExecuteServices=false setzen; erwartet: Hintergrunddienste starten nicht.", + "qm": "", + "uebernahme": "übernehmen - als Umgebungs-/Deploymentkonfiguration im Zielsystem." + }, + { + "id": "SwRS-043", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Terminanfragen mit Vorschlagsliste und Antwortverarbeitung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029; StRS-018", + "konsolidierung": "nein", + "pruefidee": "Antwort auf Vorschlag 2 senden; erwartet: Request auf bestätigt, Termin aus Vorschlag 2.", + "qm": "", + "uebernahme": "übernehmen - moderne Terminvereinbarung." + }, + { + "id": "SwRS-044", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Ablageverzeichnis für Lieferantenbestellungen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-026", + "konsolidierung": "nein", + "pruefidee": "Verzeichnis-I3D für Bestellung abrufen; erwartet: konsistenter Verzeichnisknoten.", + "qm": "", + "uebernahme": "übernehmen - Belegablage bleibt nötig." + }, + { + "id": "SwRS-045", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Automatisches Anlegen fehlender Distributoren", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027", + "konsolidierung": "nein", + "pruefidee": "Import mit unbekanntem Distributornamen; erwartet: Datensatz entsteht automatisch.", + "qm": "", + "uebernahme": "übernehmen - robuste Importe." + }, + { + "id": "SwRS-046", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kalender: Darstellungs-, Synchronisations- und Ticketterminate-Einstellungen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029; StRS-018", + "konsolidierung": "nein", + "pruefidee": "Ticket-Termine aktivieren; erwartet: Termin je Ticketfälligkeit im Kalender.", + "qm": "", + "uebernahme": "übernehmen - Kalender bleibt Kernorganisation." + }, + { + "id": "SwRS-047", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zentrale Icon-Verwaltung inkl. Webservice-Bereitstellung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031", + "konsolidierung": "nein", + "pruefidee": "Icon ändern; erwartet: Desktop und Web zeigen dasselbe Icon.", + "qm": "", + "uebernahme": "übernehmen - untergeordnet, aber nützlich." + }, + { + "id": "SwRS-048", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zentrale Einstellungen für den Nexus-Webclient", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031", + "konsolidierung": "nein", + "pruefidee": "Einstellung ändern; erwartet: Wirkung für alle Webclient-Sitzungen.", + "qm": "", + "uebernahme": "übernehmen - Basis des Web-Zielsystems." + }, + { + "id": "SwRS-049", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Interner Chat mit Mitgliedern, Notizen und Lesestatus", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029; StRS-017", + "konsolidierung": "nein", + "pruefidee": "Nachricht senden, durch zweites Mitglied lesen; erwartet: Lesestatus aktualisiert.", + "qm": "", + "uebernahme": "übernehmen - interne Kommunikation; ggf. durch Standardtools ersetzbar (fachlich prüfen)." + }, + { + "id": "SwRS-050", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Checklisten mit Kundenzuordnung und Änderungsprotokoll", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029", + "konsolidierung": "nein", + "pruefidee": "Checkliste ändern; erwartet: ChangeLog-Eintrag.", + "qm": "", + "uebernahme": "übernehmen - Servicequalität." + }, + { + "id": "SwRS-051", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Länder- und Währungsverwaltung mit Kursaktualisierung", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-011; StRS-001", + "konsolidierung": "nein", + "pruefidee": "Kurs ändern; erwartet: neuer Beleg nutzt neuen CurrencyFactor.", + "qm": "", + "uebernahme": "übernehmen - Auslandsgeschäft." + }, + { + "id": "SwRS-052", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "CPra-Konnektor: tokenbasierte Anmeldung und Webhook-Links", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027", + "konsolidierung": "nein", + "pruefidee": "Webhook-Link zu Ticket erzeugen; erwartet: Link enthält Ticket-/Kundenparameter.", + "qm": "", + "uebernahme": "Sonderfall - kundenspezifischer Konnektor, Bedarf im Zielsystem prüfen." + }, + { + "id": "SwRS-053", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kundenindividuelle Zusatztabellen mit Variablenersetzung", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "Kandidat: SwRS-029 (Custom Properties) - zwei Customizing-Mechanismen für Zusatzdaten", + "pruefidee": "Insert mit Variable; erwartet: ersetzter Wert in der Tabelle.", + "qm": "", + "uebernahme": "Workaround - generische Zusatztabellen im Zielsystem durch definierte Erweiterungspunkte ersetzen." + }, + { + "id": "SwRS-054", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kundengeräte (AccountDevices) mit Gerätelog und Suche", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-028; StRS-022", + "konsolidierung": "Kandidat: Kundengeräte existieren zusätzlich als „CustomerAssets\"-Stammblätter und im DocuBoard-Assetmanagement - drei Datenhaltungen für Geräte beim Kunden", + "pruefidee": "Gerät anlegen, Logeintrag schreiben, per externer ID suchen.", + "qm": "", + "uebernahme": "übernehmen - Gerätebestand ist Servicegrundlage; Konsolidierung nötig." + }, + { + "id": "SwRS-055", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Asset-Management-Partner und AD-Ausschlüsse (DocuBoard)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-028; StRS-022", + "konsolidierung": "Kandidat: SwRS-054 (Gerätedatenhaltungen)", + "pruefidee": "AD-Benutzer ausschließen; erwartet: taucht in Asset-Erfassung nicht mehr auf.", + "qm": "", + "uebernahme": "übernehmen - MSP-Funktionalität." + }, + { + "id": "SwRS-056", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Systemdokumentationen mit Kategorien, Status und Rechteprüfung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-026; StRS-020", + "konsolidierung": "nein", + "pruefidee": "Abruf ohne Recht; erwartet: leere/abgelehnte Antwort.", + "qm": "", + "uebernahme": "übernehmen - Kundendokumentation ist MSP-Kern." + }, + { + "id": "SwRS-057", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "FiBu-Exportkonfigurationen mit Formatwahl und Standardkennzeichen", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-021", + "konsolidierung": "nein", + "pruefidee": "Zweite Konfiguration als Default speichern; erwartet: erste verliert Default.", + "qm": "", + "uebernahme": "übernehmen - Export-Varianten bleiben nötig." + }, + { + "id": "SwRS-058", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Doppelübergabeschutz durch Übertragungsstatus je FiBu-Objekt", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-021", + "konsolidierung": "nein", + "pruefidee": "Beleg zweimal in Exportlauf aufnehmen; erwartet: zweiter Lauf ohne den Beleg.", + "qm": "", + "uebernahme": "übernehmen - Schutz der Buchhaltungsintegrität." + }, + { + "id": "SwRS-059", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "RMA-Abwicklung mit Rücksendung an Kunde und Lieferant", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-028; StRS-023", + "konsolidierung": "nein", + "pruefidee": "RMA anlegen, an Lieferant weitersenden; erwartet: beide Teilvorgänge verknüpft, Artikelhistorie ergänzt.", + "qm": "", + "uebernahme": "übernehmen - Kernprozess im Hardwarehandel." + }, + { + "id": "SwRS-060", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Distributorspezifische EDI-Bestellerzeugung und -Upload", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027", + "konsolidierung": "nein", + "pruefidee": "Bestellung je Distributor generieren; erwartet: distributorspezifisches XML-Schema.", + "qm": "", + "uebernahme": "übernehmen - Formatvielfalt bleibt Realität." + }, + { + "id": "SwRS-061", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Mitarbeiterstatus: Verfügbarkeit, Dispatcher-Rolle, Aktivprüfung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020; StRS-012", + "konsolidierung": "nein", + "pruefidee": "Zweiten Mitarbeiter als Dispatcher setzen; erwartet: Rolle wechselt eindeutig.", + "qm": "", + "uebernahme": "übernehmen - Einsatzsteuerung." + }, + { + "id": "SwRS-062", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Überwachung erwarteter Ereignisse mit Protokoll", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-018; StRS-031", + "konsolidierung": "nein", + "pruefidee": "Ereignis definieren, Eintreffen loggen; erwartet: Log je Konto abrufbar.", + "qm": "", + "uebernahme": "übernehmen - MSP-Monitoring." + }, + { + "id": "SwRS-063", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Konfiguration externer Helpdesk-Anbindungen", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027; StRS-005", + "konsolidierung": "Kandidat: DataExchange/Connectors (DocBee-Ticketkonnektor) - zwei Wege zur Fremdticket-Kopplung", + "pruefidee": "Konfiguration anlegen und per Filter wiederfinden.", + "qm": "", + "uebernahme": "übernehmen - Ökosystem-Anbindung." + }, + { + "id": "SwRS-064", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Einbindung externer Programme als Tools", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "Tool anlegen; erwartet: erscheint in der Toolliste.", + "qm": "", + "uebernahme": "Workaround - Desktopgebundene Toolaufrufe im Web neu denken (Links/Integrationen)." + }, + { + "id": "SwRS-065", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Nummerierte Zahlungseingangsprotokolle und Zahlungsübersichten", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-032", + "konsolidierung": "nein", + "pruefidee": "Zwei Zahlungseingänge protokollieren; erwartet: fortlaufende Lognummern.", + "qm": "", + "uebernahme": "übernehmen - Zahlungsnachweis." + }, + { + "id": "SwRS-066", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Automatische Zuordnungsvorschläge und Buchung von Bankumsätzen", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-032", + "konsolidierung": "nein", + "pruefidee": "Buchung durchführen und zurücknehmen; erwartet: Beleg-Zahlstatus wechselt entsprechend; Inspector meldet keine Differenzen.", + "qm": "", + "uebernahme": "übernehmen - Kernfunktion." + }, + { + "id": "SwRS-067", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Import „Sonderartikel zu Vertrag\" über kundenspezifisches Gateway", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027; StRS-004", + "konsolidierung": "nein", + "pruefidee": "Import mit externem Code; erwartet: Zuordnung zum Vertragsartikel und Preis.", + "qm": "", + "uebernahme": "Sonderfall - kundenspezifische Gateway-Logik; Bedarf je Kunde prüfen." + }, + { + "id": "SwRS-068", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Lucene-Volltextindex mit gezielter Nachindizierung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-033", + "konsolidierung": "nein", + "pruefidee": "Objekt ändern; erwartet: nach UpdateRequestedIndexes ist der neue Text auffindbar.", + "qm": "", + "uebernahme": "übernehmen - Mechanik im Zielsystem z. B. mit Such-Service." + }, + { + "id": "SwRS-069", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Shop-Integrationsobjekte mit externer ID-Synchronisation", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027; StRS-019", + "konsolidierung": "nein", + "pruefidee": "Gruppe zweimal mit derselben ExternalId anlegen; erwartet: ein Datensatz.", + "qm": "", + "uebernahme": "übernehmen - Shop-Anbindung bleibt relevant." + }, + { + "id": "SwRS-070", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "IT-Planner: Kategorien für virtuelle Checklistenobjekte", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029", + "konsolidierung": "nein", + "pruefidee": "Kategorie anlegen/löschen; erwartet: Filterabfrage spiegelt Änderung.", + "qm": "", + "uebernahme": "Sonderfall - Nutzungsgrad des IT-Planners vor Übernahme prüfen (RB-Präfix deutet auf Riverbird-Herkunft)." + }, + { + "id": "SwRS-071", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Lagerortverwaltung mit Synchronisation und Umbuchungsprotokoll", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-013; StRS-008", + "konsolidierung": "nein", + "pruefidee": "Umbuchung zwischen Lagern; erwartet: RebookLog-Eintrag, Bestände angepasst.", + "qm": "", + "uebernahme": "übernehmen - Mehrlagerfähigkeit." + }, + { + "id": "SwRS-072", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "E-Mail-Signaturen mit Platzhaltern und Domain-Blacklist", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-035", + "konsolidierung": "nein", + "pruefidee": "Signatur mit Platzhalter versenden; erwartet: ersetzte Werte; Blacklist-Domain wird blockiert.", + "qm": "", + "uebernahme": "übernehmen - Signatur-/Blacklistlogik bleibt." + }, + { + "id": "SwRS-073", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Mail-Scanner-Profile, -Workflows und -Aufgaben", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-036", + "konsolidierung": "nein", + "pruefidee": "Workflow ändern; erwartet: nächste Mailverarbeitung folgt neuer Regel.", + "qm": "", + "uebernahme": "übernehmen - siehe SyRS-036." + }, + { + "id": "SwRS-074", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Serien-Mailings mit Vorlagen, Anhängen und Übersicht", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-035; StRS-026", + "konsolidierung": "nein", + "pruefidee": "Mailing mit Anhang speichern und vollständig laden.", + "qm": "", + "uebernahme": "übernehmen - Basis-Marketing; ggf. durch Marketing-Tool ersetzbar." + }, + { + "id": "SwRS-075", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Massenpreisänderungen über Vorlagen für Artikel und Belege", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-034", + "konsolidierung": "nein", + "pruefidee": "Vorlage mit 5% Aufschlag auf Artikelgruppe; erwartet: Preise +5%, Vorschau zählt dieselben Artikel.", + "qm": "", + "uebernahme": "übernehmen - Effizienzfunktion." + }, + { + "id": "SwRS-076", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Bereitstellung der Mitarbeiterliste für mobile Clients", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031", + "konsolidierung": "nein", + "pruefidee": "Abruf der Mobile-Mitarbeiterliste; erwartet: aktive Mitarbeiter enthalten.", + "qm": "", + "uebernahme": "Workaround - separates Mobile-Format im Zielsystem durch einheitliche API ersetzen." + }, + { + "id": "SwRS-077", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Modulkatalog mit automatischer Registrierung und Benutzerfavoriten", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031; StRS-014", + "konsolidierung": "nein", + "pruefidee": "Neues Codemodul deployen; erwartet: DB-Eintrag entsteht automatisch.", + "qm": "", + "uebernahme": "übernehmen - Navigationsgrundlage." + }, + { + "id": "SwRS-078", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Personalisierte Dashboards je Benutzer", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029", + "konsolidierung": "nein", + "pruefidee": "Container hinzufügen; erwartet: erscheint nur beim jeweiligen Benutzer.", + "qm": "", + "uebernahme": "übernehmen - personalisierte Übersichten." + }, + { + "id": "SwRS-079", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "„Mein Tag\": Arbeitsvorrat mit Mitarbeiterauswahl und Import", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029", + "konsolidierung": "nein", + "pruefidee": "Mitarbeiterauswahl setzen; erwartet: deren Items erscheinen in der Übersicht.", + "qm": "", + "uebernahme": "übernehmen - Produktivitätsfunktion." + }, + { + "id": "SwRS-080", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Web-Benachrichtigungen mit Gelesen-/Gesehen-Status", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031; StRS-018", + "konsolidierung": "Kandidat: M-070 Notifications (Client-Benachrichtigungen) - zwei Benachrichtigungssysteme", + "pruefidee": "Benachrichtigung erzeugen; erwartet: Push im Web, Statuswechsel bei Klick.", + "qm": "", + "uebernahme": "übernehmen - Web-Benachrichtigungen sind Zielbild." + }, + { + "id": "SwRS-081", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Persönliche und globale Ticket-Ansichten im Webclient", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031; StRS-005", + "konsolidierung": "nein", + "pruefidee": "Globale Ansicht mit vorhandenem Namen anlegen; erwartet: Ablehnung.", + "qm": "", + "uebernahme": "übernehmen - Ansichtenverwaltung ist Web-Ziel." + }, + { + "id": "SwRS-082", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Objektbezogene Benachrichtigungsempfänger", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029", + "konsolidierung": "Kandidat: SwRS-080 (Nexus-Benachrichtigungen)", + "pruefidee": "Benutzer als Empfänger eintragen; erwartet: erhält Benachrichtigung bei Objektänderung.", + "qm": "", + "uebernahme": "übernehmen - Abo-Prinzip je Objekt." + }, + { + "id": "SwRS-083", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Externe Referenzen je Geschäftsobjekt (Fremdsystem-IDs)", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027", + "konsolidierung": "nein", + "pruefidee": "Referenz (Typ \"DocBee\", ID X) anlegen; erwartet: Objekt über X auffindbar.", + "qm": "", + "uebernahme": "übernehmen - Integrationsgrundlage." + }, + { + "id": "SwRS-084", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Asset-Suche aus Outlook (Kundenerkennung über Gerätenummer)", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031; StRS-022", + "konsolidierung": "nein", + "pruefidee": "Suche mit bekannter Assetnummer; erwartet: zugehöriger Kunde.", + "qm": "", + "uebernahme": "übernehmen - Add-In-Nutzen." + }, + { + "id": "SwRS-085", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kundenzugangsdaten-Verwaltung mit Zugriffs- und Änderungsprotokoll", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-017; StRS-028", + "konsolidierung": "Kandidat: M-074 PasswordManager (zweites Passwortmodul mit Siegel/Guidelines)", + "pruefidee": "Passwort abrufen; erwartet: AccessLog-Eintrag mit Benutzer/Zeit.", + "qm": "", + "uebernahme": "übernehmen - MSP-Kernfunktion mit Auditpflicht." + }, + { + "id": "SwRS-086", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Passwortmanager mit Kundenrechten, Siegeln und Richtlinien", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-017; StRS-028", + "konsolidierung": "Kandidat: SwRS-085 (zwei Passwortverwaltungen) - im Zielsystem ein Modul", + "pruefidee": "Versiegelten Wert öffnen; erwartet: Siegelbruch protokolliert.", + "qm": "", + "uebernahme": "übernehmen - modernere der beiden Implementierungen als fachliche Basis." + }, + { + "id": "SwRS-087", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Objektbezogene Prozesse mit Schritten und Bindungen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-036; StRS-031", + "konsolidierung": "Kandidat: Services/Workflows (zweite Prozess-/Workflow-Engine)", + "pruefidee": "Prozess mit zwei Schritten speichern und vollständig laden.", + "qm": "", + "uebernahme": "übernehmen - Prozesskonfiguration; Engines konsolidieren." + }, + { + "id": "SwRS-088", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Produktmatrix: Kategorien, Produkte und Kundenbewertungen mit Änderungslog", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020; StRS-025", + "konsolidierung": "nein", + "pruefidee": "Rating ändern; erwartet: ChangeLog-Eintrag.", + "qm": "", + "uebernahme": "übernehmen - Vertriebssteuerung." + }, + { + "id": "SwRS-089", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Fertigungsaufträge mit Positionen und Fertigungsprotokoll", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-013; StRS-024", + "konsolidierung": "nein", + "pruefidee": "Logeintrag zu Auftrag schreiben; erwartet: im Filterabruf enthalten.", + "qm": "", + "uebernahme": "übernehmen - sofern Fertigung im Zielmarkt bleibt (Nexus enthält eigenes ProductionOrderManagement)." + }, + { + "id": "SwRS-090", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Projektliste mit Stichtagsfilter", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020; StRS-025", + "konsolidierung": "Kandidat: Sales/Customers/CrmProjects und TicketProjects - drei Projektbegriffe abgrenzen/zusammenführen", + "pruefidee": "Projekt mit Startdatum nach Stichtag; erwartet: im gefilterten Abruf enthalten.", + "qm": "", + "uebernahme": "übernehmen - Projektbezug ist verbreitet." + }, + { + "id": "SwRS-091", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Bestellvorschlagsermittlung aus mehreren Quellen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027; StRS-007", + "konsolidierung": "nein", + "pruefidee": "Artikel unter Mindestbestand; erwartet: erscheint im Vorschlag mit Bedarfsmenge.", + "qm": "", + "uebernahme": "übernehmen - dispositive Kernfunktion." + }, + { + "id": "SwRS-092", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kaufmännische Datumsarithmetik der Vertragsintervalle", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-037", + "konsolidierung": "nein", + "pruefidee": "Vertrag mit Start 31.01. monatlich; erwartet: Folgeperioden 28./29.02., 31.03., 30.04.", + "qm": "", + "uebernahme": "übernehmen - fachlich zwingende Regel." + }, + { + "id": "SwRS-093", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Automatisches Schließen nur vollständig abgerechneter, abgelaufener Verträge", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-037, SyRS-038", + "konsolidierung": "nein", + "pruefidee": "Abgelaufener Vertrag mit offener Restperiode; erwartet: bleibt aktiv; nach Abrechnung der Restperiode: wird geschlossen.", + "qm": "", + "uebernahme": "übernehmen - schützt die Abrechnungsvollständigkeit." + }, + { + "id": "SwRS-094", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Ermittlung abrechnungsfälliger Kunden und Zählerstandsverwaltung", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-038", + "konsolidierung": "nein", + "pruefidee": "Vertrag mit BilledTo vor Stichtag; erwartet: Kunde in Suchergebnis; Gerät ohne Zähler wird gemeldet.", + "qm": "", + "uebernahme": "übernehmen - Kernfunktion Managed Print/MSP." + }, + { + "id": "SwRS-095", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Timer-Abrechnung: Statusführung und Belegerzeugung aus Ticketzeiten", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-039", + "konsolidierung": "nein", + "pruefidee": "Timer abrechnen, zweiten Lauf starten; erwartet: bereits abgerechneter Timer erscheint nicht erneut.", + "qm": "", + "uebernahme": "übernehmen - Umsatzrelevanter Kern." + }, + { + "id": "SwRS-096", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Operationsgenaue Rechteprüfung beim Ticket-Speichern", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-040, SyRS-001", + "konsolidierung": "nein", + "pruefidee": "Fälligkeit ohne MATURITY_CHANGE ändern; erwartet: \"Kein Recht für Fälligkeitsdatum ändern vorhanden.\"", + "qm": "", + "uebernahme": "übernehmen - bewährtes Rechtemodell." + }, + { + "id": "SwRS-097", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Restriktive Ticket-Sichtbarkeit (nur eigene / eigene Filiale)", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-040", + "konsolidierung": "nein", + "pruefidee": "Benutzer mit ONLY_OWN fragt fremdes Ticket per ID ab; erwartet: kein Zugriff.", + "qm": "", + "uebernahme": "übernehmen - Datenschutz im Support." + }, + { + "id": "SwRS-098", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Eskalationslauf mit Stufenterminen und Testmodus", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-041", + "konsolidierung": "nein", + "pruefidee": "TestEscalation mit Datum+3 Stufenfristen; erwartet: alle drei Stufen nacheinander gesetzt.", + "qm": "", + "uebernahme": "übernehmen - SLA-Automatik." + }, + { + "id": "SwRS-099", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Ticketabschluss mit Kunden-/Teambenachrichtigung und Zeitbericht", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-040, SyRS-025", + "konsolidierung": "nein", + "pruefidee": "Abschluss mit externer Benachrichtigung; erwartet: Mail mit Report-PDF und Timerliste.", + "qm": "", + "uebernahme": "übernehmen - Kundenkommunikation im Support." + }, + { + "id": "SwRS-100", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kassenbuchbuchung: MwSt-Split, Pflicht-Belegarten, Schreibschutz", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-042", + "konsolidierung": "nein", + "pruefidee": "Barrechnung mit zwei Steuersätzen, ein CashBookRecord fehlt; erwartet: Fehler \"Kassenbuch Buchung kann nicht erstellt werden ...\".", + "qm": "", + "uebernahme": "übernehmen - Compliance-Kern." + }, + { + "id": "SwRS-101", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Validierung von Riverbird-Tickets und RMM-Zugriffsschlüsseln", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-017, SyRS-027", + "konsolidierung": "nein", + "pruefidee": "Aufruf mit ungültigem Ticket; erwartet: Ablehnung (false).", + "qm": "", + "uebernahme": "Sonderfall - produktspezifische Kopplung (Riverbird); im Zielsystem über Standard-API-Auth abbilden." + }, + { + "id": "SwRS-102", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kundensuche und Kompakt-Kundendaten für alle Module", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020", + "konsolidierung": "nein", + "pruefidee": "Suche nach Namensfragment; erwartet: Kompakttreffer; Webcart-Filter liefert nur lizenzierte Kunden.", + "qm": "", + "uebernahme": "übernehmen - Basisfunktion." + }, + { + "id": "SwRS-103", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Telemarketing-Aktionen mit Vorlagen und Referenzen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020; StRS-026", + "konsolidierung": "nein", + "pruefidee": "Aktion aus Vorlage anlegen; erwartet: Vorgang mit Aktionshistorie.", + "qm": "", + "uebernahme": "übernehmen - CRM-Funktion." + }, + { + "id": "SwRS-104", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Terminverwaltung (Schedule) mit Personenzuordnung und Kalendersicht", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029", + "konsolidierung": "Kandidat: M-033 Calendar (Einstellungen) und Exchange-Kalenderzugriff (EwsCalendarAccess) - Terminwelt konsolidieren", + "pruefidee": "Termin mit Objektbezug anlegen; erwartet: erscheint in Kalenderfilter des Mitarbeiters.", + "qm": "", + "uebernahme": "übernehmen - Kernorganisation." + }, + { + "id": "SwRS-105", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Dokumentationsassistent für Kundeninfrastruktur", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-026; StRS-020", + "konsolidierung": "Kandidat: M-047 DocumentationArea - zwei Dokumentationsmechanismen", + "pruefidee": "Maschine dokumentieren; erwartet: Datensatz im Maschinenbereich des Kunden.", + "qm": "", + "uebernahme": "übernehmen - MSP-Dokupflicht." + }, + { + "id": "SwRS-106", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Stundenzuschlagssätze mit Einstellungen, Alternativtexten und Log", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-039", + "konsolidierung": "nein", + "pruefidee": "Satz ändern; erwartet: Logeintrag; Beleg übernimmt neuen Satz.", + "qm": "", + "uebernahme": "übernehmen - Abrechnungsrelevanz." + }, + { + "id": "SwRS-107", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Digitale PDF-Signatur mit zentral verwaltetem Zertifikat", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-025; StRS-020", + "konsolidierung": "nein", + "pruefidee": "PDF signieren und Signatur mit Reader prüfen.", + "qm": "", + "uebernahme": "übernehmen - Vertrauensanker für E-Dokumente." + }, + { + "id": "SwRS-108", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "SelfCare-Formulare für Endkundenanfragen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031; StRS-019", + "konsolidierung": "Kandidat: WebSuite WebHDQuestionBL (Webformular-Fragen) - Überschneidung prüfen", + "pruefidee": "Formular anlegen und über Webseite abrufen.", + "qm": "", + "uebernahme": "übernehmen - Self-Service ist Zielbild." + }, + { + "id": "SwRS-109", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Grafische Workflow-Prozesse je Mitarbeiter", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-036; StRS-031", + "konsolidierung": "Kandidat: SwRS-087 (Processes) - zwei Prozess-Engines", + "pruefidee": "Workflow mit zwei Shapes speichern und vollständig laden.", + "qm": "", + "uebernahme": "übernehmen - Automatisierung; Engines zusammenführen." + }, + { + "id": "SwRS-110", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Internes Social-Media-Modul (Kommentare, Likes, Feed)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029", + "konsolidierung": "nein", + "pruefidee": "Kommentar und Like setzen; erwartet: im Feed sichtbar.", + "qm": "", + "uebernahme": "veraltet - interner Social-Feed hat geringe Nutzung zu erwarten; fachlich prüfen und ggf. nicht migrieren." + }, + { + "id": "SwRS-111", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Anwendungsstart: Mapping-Vorladen und Verbindungswahl", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010", + "konsolidierung": "nein", + "pruefidee": "Start mit/ohne Vorladen vergleichen; erwartet: schnellerer Erstzugriff.", + "qm": "Performance-Effizienz (Zeitverhalten)", + "uebernahme": "veraltet - Client-seitiges ORM entfällt im Web-Zielsystem." + }, + { + "id": "SwRS-112", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Inventur mit Zuständen und transaktionaler Klammer", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-013; StRS-008", + "konsolidierung": "nein", + "pruefidee": "Inventur abschließen ohne Recht; erwartet: Ablehnung.", + "qm": "", + "uebernahme": "übernehmen - gesetzlich erforderlich." + }, + { + "id": "SwRS-113", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zentrale I3D-Systemtabelle", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010", + "konsolidierung": "nein", + "pruefidee": "Parallele Objektanlagen; erwartet: keine I3D-Kollision.", + "qm": "", + "uebernahme": "veraltet - im Zielsystem durch DB-native Schlüsselvergabe ersetzen." + }, + { + "id": "SwRS-114", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Verschlagwortung von Tickets mit aktiven Tags", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-040", + "konsolidierung": "nein", + "pruefidee": "Tag an Ticket setzen/entfernen; erwartet: Zustand konsistent.", + "qm": "", + "uebernahme": "übernehmen - leichtgewichtige Klassifizierung." + }, + { + "id": "SwRS-115", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Anruferkennung und Anrufdokumentation (TAPI)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-030", + "konsolidierung": "nein", + "pruefidee": "Bekannte Rufnummer suchen; erwartet: passender Ansprechpartner.", + "qm": "", + "uebernahme": "übernehmen - Funktion bleibt, Technik wechselt (siehe SyRS-030)." + }, + { + "id": "SwRS-116", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Aufgabenverwaltung mit typisierten Aktions-Handlern", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029; StRS-031", + "konsolidierung": "Kandidat: ToDoArea (ToDoBL) - zwei Aufgabenkonzepte", + "pruefidee": "Aufgabe mit Helpdesk-Aktion ausführen; erwartet: Ticket entsteht.", + "qm": "", + "uebernahme": "übernehmen - Automatisierung; mit ToDos konsolidieren." + }, + { + "id": "SwRS-117", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Telemetrie der Funktions-, KI- und API-Nutzung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "API-Aufruf ausführen; erwartet: Bucket-Zähler steigt.", + "qm": "Wartbarkeit (Analysierbarkeit)", + "uebernahme": "übernehmen - mit Datenschutzprüfung." + }, + { + "id": "SwRS-118", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Textbausteine mit Filterung und Anrede-/Grußformel-Ersetzung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-025, SyRS-011", + "konsolidierung": "nein", + "pruefidee": "Anrede-Baustein ändern; erwartet: neuer Beleg nutzt neue Anrede.", + "qm": "", + "uebernahme": "übernehmen - Standardfunktion." + }, + { + "id": "SwRS-119", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Ticket-Projekte mit Abhängigkeiten", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-040; StRS-025", + "konsolidierung": "Kandidat: SwRS-090 (Projects) - Projektbegriffe", + "pruefidee": "Abhängigkeit anlegen; erwartet: in Abhängigkeitsliste enthalten.", + "qm": "", + "uebernahme": "übernehmen - Support-Projektgeschäft." + }, + { + "id": "SwRS-120", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zeitsteuerungs-Einstellungen (TimingSettings)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-018", + "konsolidierung": "nein", + "pruefidee": "Einstellung anlegen und per Filter finden.", + "qm": "", + "uebernahme": "übernehmen - Terminierung von Automatiken." + }, + { + "id": "SwRS-121", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Objektbezogene ToDos über Objektarten hinweg", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-029", + "konsolidierung": "Kandidat: SwRS-116 (TaskManager)", + "pruefidee": "ToDo zu Beleg anlegen; erwartet: über Objektfilter auffindbar.", + "qm": "", + "uebernahme": "übernehmen - siehe Konsolidierung." + }, + { + "id": "SwRS-122", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Textformat-Konvertierung (ToolBL)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "RTF-Text konvertieren; erwartet: Zielformat.", + "qm": "", + "uebernahme": "Workaround - formatspezifisch fürs Desktop-UI; im Web meist HTML-only." + }, + { + "id": "SwRS-123", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "TradePool-Artikelimport mit gefilterter Sichtung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027", + "konsolidierung": "nein", + "pruefidee": "Importdatei einlesen; erwartet: Artikel per Filter auffindbar.", + "qm": "", + "uebernahme": "Sonderfall - Nutzung der TradePool-Börse im Zielsystem prüfen." + }, + { + "id": "SwRS-124", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Transaktionsobjekte mit Detailpositionen", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020", + "konsolidierung": "nein", + "pruefidee": "Transaktion mit Details speichern und laden.", + "qm": "", + "uebernahme": "übernehmen - vorbehaltlich fachlicher Klärung des Einsatzzwecks." + }, + { + "id": "SwRS-125", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Objektbezogene Weblinks (SimpleUrl)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-026", + "konsolidierung": "nein", + "pruefidee": "Link an Kunde anlegen; erwartet: per Filter abrufbar.", + "qm": "", + "uebernahme": "übernehmen - Kleinfunktion." + }, + { + "id": "SwRS-126", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zuordnung von Schulungsvideos (Videoportal)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "Zuordnung anlegen; erwartet: in Liste enthalten.", + "qm": "", + "uebernahme": "übernehmen - Onboarding-Hilfe." + }, + { + "id": "SwRS-127", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Gutscheinverwaltung mit Barcode und Statusfilter", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-042", + "konsolidierung": "nein", + "pruefidee": "Gutschein einlösen; erwartet: erscheint nur noch im Eingelöst-Filter.", + "qm": "", + "uebernahme": "übernehmen - Kassennahe Funktion." + }, + { + "id": "SwRS-128", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Artikelstamm: Sonderartikel, Rechte und UI-Einstellungen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-013; StRS-008", + "konsolidierung": "nein", + "pruefidee": "Frachtposition erzeugen; erwartet: nutzt den konfigurierten Frachtartikel.", + "qm": "", + "uebernahme": "übernehmen - Artikelstamm ist Kern." + }, + { + "id": "SwRS-129", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Aktions-Weblinks mit Klick-Protokoll", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031; StRS-019", + "konsolidierung": "nein", + "pruefidee": "Link klicken; erwartet: Klickdatensatz und ausgeführte Aktion.", + "qm": "", + "uebernahme": "übernehmen - Self-Service-Baustein." + }, + { + "id": "SwRS-130", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Konfigurierbares Webmenü mit Sortierung und Sichtbarkeit", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031", + "konsolidierung": "nein", + "pruefidee": "Eintrag verschieben; erwartet: neue Reihenfolge im Web.", + "qm": "", + "uebernahme": "übernehmen - Web-Konfiguration." + }, + { + "id": "SwRS-131", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Versionsauskunft des Webservice", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031; SwRS-033", + "konsolidierung": "nein", + "pruefidee": "Versionsabruf; erwartet: Assembly-Version des Webservice.", + "qm": "", + "uebernahme": "übernehmen - API-Versionsauskunft." + }, + { + "id": "SwRS-132", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "PDF-Zusammenführung als wiederverwendbarer Helfer", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-025", + "konsolidierung": "nein", + "pruefidee": "Zwei PDFs mergen; erwartet: ein PDF mit allen Seiten.", + "qm": "", + "uebernahme": "übernehmen - Standardhelfer." + }, + { + "id": "SwRS-133", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Fachliche Ausnahmen als typisierte Exceptions", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-003", + "konsolidierung": "nein", + "pruefidee": "Aufruf mit abgelaufenem Ticket; erwartet: TicketExpiredException und Re-Login im Client.", + "qm": "", + "uebernahme": "übernehmen - Muster beibehalten." + }, + { + "id": "SwRS-134", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Benutzerbezogene Grid- und UI-Profile", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031", + "konsolidierung": "nein", + "pruefidee": "Grid-Layout ändern, neu anmelden; erwartet: Layout bleibt erhalten.", + "qm": "", + "uebernahme": "übernehmen - erwartete UI-Personalisierung." + }, + { + "id": "SwRS-135", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Auswertungen: offene Posten, Umsatz-, Vertrags- und MSP-Statistiken", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-021, SyRS-032; StRS-016", + "konsolidierung": "nein", + "pruefidee": "Unbezahlte Rechnung anlegen; erwartet: erscheint in der Offene-Posten-Übersicht des Kontos.", + "qm": "", + "uebernahme": "übernehmen - Kernauswertungen; Statistik-Recht (RIGHT_STATISTIK=20400015) beachten." + }, + { + "id": "SwRS-136", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Webservice-Fassaden-Schicht je Fachmodul (DTO-Bereitstellung)", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031, SyRS-046", + "konsolidierung": "Kandidat: Doppelstrukturen BL vs. WebServices-BL je Modul - im Zielsystem eine Serviceschicht", + "pruefidee": "API-Abruf eines Belegs; erwartet: DTO-Struktur statt interner Entität.", + "qm": "", + "uebernahme": "übernehmen - Muster ja, Doppelpflege nein." + }, + { + "id": "SwRS-137", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Persistenzschicht: NHibernate mit Ereignis-Listenern (Stringkürzung, Change-Tracking)", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, SyRS-009", + "konsolidierung": "nein", + "pruefidee": "String länger als Feldlänge speichern; erwartet: gekürzt gespeichert, kein Fehler.", + "qm": "", + "uebernahme": "Workaround - stille Kürzung im Zielsystem durch Validierung mit Benutzerfeedback ersetzen." + }, + { + "id": "SwRS-138", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Einheitliches Entitätsmodell mit I3D-Schlüssel", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-009, SyRS-010", + "konsolidierung": "nein", + "pruefidee": "Beliebige Entität prüfen; erwartet: I3D + Created/Changed-Felder vorhanden.", + "qm": "", + "uebernahme": "übernehmen - als fachliches Objektmodell; technisch neu aufsetzen." + }, + { + "id": "SwRS-139", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Querschnittsbibliothek mit lizenzgesteuerten Modul-Features", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-003; SwRS-009", + "konsolidierung": "nein", + "pruefidee": "Feature deaktivieren; erwartet: abhängige Funktion verweigert.", + "qm": "", + "uebernahme": "übernehmen - Feature-Gating bleibt (im SaaS als Plan-/Paketsteuerung)." + }, + { + "id": "SwRS-140", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zentrale Objektarten- und Konstantendefinition (CentronObjectKindNumeric)", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-011", + "konsolidierung": "nein", + "pruefidee": "Neue generische Funktion nutzt dieselben Codes; erwartet: kompatible Verknüpfungen.", + "qm": "", + "uebernahme": "übernehmen - als kontrolliertes Enum/Katalog." + }, + { + "id": "SwRS-141", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Gateway-Formatadapter (EDI-Distributoren, OpenTrans, FiBu, Onlinebanking)", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027, SyRS-021, SyRS-043", + "konsolidierung": "Kandidat: EDI-Logik existiert in Centron.BL/EDI und Centron.Gateway (siehe SyRS-027)", + "pruefidee": "Neues Distributorformat als weiterer Adapter; erwartet: keine Änderung in EDIDispatcher-Aufrufern nötig.", + "qm": "", + "uebernahme": "übernehmen - Adapter-Prinzip beibehalten." + }, + { + "id": "SwRS-142", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "WPF-Desktop-Client mit Modul-Navigation, Wizards und Lokalisierung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031", + "konsolidierung": "Kandidat: Nexus-Webclient (SyRS-031) - Doppel-UI", + "pruefidee": "Sprachumschaltung; erwartet: lokalisierte Masken.", + "qm": "", + "uebernahme": "veraltet - Desktop-Client wird durch Web-Zielsystem abgelöst; Fachinhalte der Masken sind Migrationsreferenz." + }, + { + "id": "SwRS-143", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Wiederverwendbare UI-Controls mit Dokumentvorschau", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031", + "konsolidierung": "nein", + "pruefidee": "Vorschau einer PDF-Datei in verschiedenen Masken; erwartet: identisches Control.", + "qm": "", + "uebernahme": "veraltet - WPF-spezifisch; Konzept (Komponentenbibliothek) übernehmen." + }, + { + "id": "SwRS-144", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Gemeinsame Kernbibliothek (TOTP, PDF-Scan, Guards, MVVM)", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-005", + "konsolidierung": "nein", + "pruefidee": "TOTP-Validierung aus BL ruft Centron.Core auf (TwoFactorAuthenticationBL.ValidateAuthenticationPin).", + "qm": "", + "uebernahme": "übernehmen - Kernlogik portieren." + }, + { + "id": "SwRS-145", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Nexus-Webclient: interne Web-Oberfläche und Kundenportal", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031, SyRS-045", + "konsolidierung": "Kandidat: SwRS-142 (Desktop-Masken) - Funktionsdopplung bis zur Abloesung", + "pruefidee": "ServiceBoard im Browser öffnen; erwartet: Ticketbearbeitung ohne Desktop-Client.", + "qm": "", + "uebernahme": "übernehmen - Ausgangspunkt des Web-Zielsystems." + }, + { + "id": "SwRS-146", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Webservice-Hosting als Windows-Dienst oder Konsole", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-047, SyRS-031", + "konsolidierung": "nein", + "pruefidee": "Start als Konsole und als Dienst; erwartet: identisches API-Verhalten.", + "qm": "Übertragbarkeit (Anpassbarkeit)", + "uebernahme": "übernehmen - Container-Variante wird Standard." + }, + { + "id": "SwRS-147", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Versionierte REST-Controller mit Rechte-Attributen", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-046, SyRS-031", + "konsolidierung": "nein", + "pruefidee": "v1-Endpunkt aufrufen; erwartet: stabile Route auch nach Einführung v2.", + "qm": "", + "uebernahme": "übernehmen - API-Basis des Zielsystems." + }, + { + "id": "SwRS-148", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Distributor-Produktdatenzugriffe (COP, EGIS, Icecat, ITscope)", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-027; StRS-007", + "konsolidierung": "nein", + "pruefidee": "Artikelsuche mit aktiviertem ITscope-Provider; erwartet: externe Treffer in der Belegposition übernehmbar (CanInsertNewAndExternalArticles der Belegart beachtend).", + "qm": "", + "uebernahme": "übernehmen - Wettbewerbsrelevante Integrationen." + }, + { + "id": "SwRS-149", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "finAPI-REST-Client für Onlinebanking", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-032", + "konsolidierung": "nein", + "pruefidee": "Credentials abrufen und Testumsätze laden; erwartet: Transaktionen im Abgleichsmodul.", + "qm": "", + "uebernahme": "übernehmen - Bankanbindung bleibt." + }, + { + "id": "SwRS-150", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "docuFORM-Anbindung für Druckerdaten (Managed Print)", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-038, SyRS-027", + "konsolidierung": "Kandidat: Drucker als „Stammblätter\" vs. Assets (SyRS-028) - Zielbild ein Gerätekonzept", + "pruefidee": "Zählerimport aus docuFORM; erwartet: Zählerstände am Vertrag.", + "qm": "", + "uebernahme": "übernehmen - Managed-Print-Geschäft." + }, + { + "id": "SwRS-151", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "GLS-/Shipcloud-Versandlogik mit Test- und Produktivumgebung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-044", + "konsolidierung": "nein", + "pruefidee": "isTest=true; erwartet: Aufruf gegen QS-URL.", + "qm": "", + "uebernahme": "übernehmen - Standard-Versandintegration." + }, + { + "id": "SwRS-152", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Legacy-Datenbankschema mit belegartspezifischen Kundenkonditionen", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-011, SyRS-020", + "konsolidierung": "Kandidat: Bankfelder in Kunden vs. BankAccount-Tabelle (SwRS-019) - zwei Datenhaltungen für Bankverbindungen", + "pruefidee": "Kunde mit abweichender Rechnungs-Kondition; erwartet: neue Rechnung schlägt diese vor, Angebot die Angebots-Kondition.", + "qm": "", + "uebernahme": "übernehmen - fachliche Regel ja; Schema-Altlasten (Feldpaare Bank/Bank02) bereinigen." + }, + { + "id": "SwRS-153", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Auslieferungs- und Betriebsartefakte (Installer, Container, CI)", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-047, SyRS-048, SyRS-049", + "konsolidierung": "nein", + "pruefidee": "Pipeline-Lauf; erwartet: MSI + Container-Image als Artefakte.", + "qm": "Übertragbarkeit (Installierbarkeit)", + "uebernahme": "übernehmen - Containerpfad; MSI entfällt mit Desktop-Ablösung." + }, + { + "id": "SwRS-154", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "[HYPOTHESE] Verrechnung von Anzahlungen in der Schlussrechnung", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "HYPOTHESE (fehlend: Detailanalyse von DownPaymentBL zur Verrechnungsregel)", + "hypothese": true, + "workaround": false, + "tracelinks": "SyRS-011, SyRS-014", + "konsolidierung": "nein", + "pruefidee": "Auftrag mit Anzahlung zur Rechnung weiterführen; erwartet: Anzahlungsposition wird verrechnet.", + "qm": "", + "uebernahme": "übernehmen - Anzahlungsprozesse sind im Projektgeschäft nötig." + }, + { + "id": "SwRS-155", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "[HYPOTHESE] SEPA-Lastschrifteinzug aus Rechnungen", + "typ": "funktional (Abrechnung)", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "HYPOTHESE (fehlend: durchsetzende SEPA-XML-Erzeugung; vermutlich im Gateway/OnlineBanking, nicht verifiziert)", + "hypothese": true, + "workaround": false, + "tracelinks": "SyRS-032, SyRS-021", + "konsolidierung": "nein", + "pruefidee": "Rechnung mit Mandat einziehen; erwartet: SEPA-XML mit Mandatsreferenz, Status directDebitCreated.", + "qm": "", + "uebernahme": "übernehmen - Lastschrift ist Standardzahlweg." + }, + { + "id": "SwRS-156", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "[HYPOTHESE] Webshop-Sortiment aus Kunden-Sonderpreisen", + "typ": "funktional", + "belege": [ + "SEKUNDÄR", + "KONTEXT" + ], + "status": "HYPOTHESE (fehlend: durchsetzende Sortiments-/Preisabfrage im WebCart-Code)", + "hypothese": true, + "workaround": false, + "tracelinks": "SyRS-045", + "konsolidierung": "nein", + "pruefidee": "Web-Account ohne Sonderpreise; erwartet: leerer Shop; mit Sonderpreis: Artikel zum Sonderpreis.", + "qm": "", + "uebernahme": "übernehmen - Kernregel des B2B-Shops; in Folgeiteration im Nexus-Code verifizieren." + }, + { + "id": "SwRS-157", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "[HYPOTHESE] Bidirektionale Exchange-Terminsynchronisation", + "typ": "Schnittstelle", + "belege": [ + "SEKUNDÄR", + "KONTEXT" + ], + "status": "HYPOTHESE (fehlend: durchsetzende Sync-Engine mit Richtungs-/Konfliktlogik)", + "hypothese": true, + "workaround": false, + "tracelinks": "SyRS-035, SyRS-029", + "konsolidierung": "Kandidat: SwRS-104 (Graph-Anbindung in ScheduleBL) - zwei Sync-Technologien (EWS vs. Graph)", + "pruefidee": "Termin in Exchange ändern; erwartet: Änderung erscheint in c-entron (und umgekehrt).", + "qm": "", + "uebernahme": "übernehmen - Kalendersync wird erwartet; Technologie auf Graph heben." + }, + { + "id": "SwRS-158", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "[HYPOTHESE] Fernwartungsstart (Supremo/Remote-Desktop) aus dem Arbeitsplatz", + "typ": "funktional", + "belege": [ + "SEKUNDÄR" + ], + "status": "HYPOTHESE (fehlend: Analyse des Supremo-Aufrufs)", + "hypothese": true, + "workaround": false, + "tracelinks": "SyRS-029, SyRS-030", + "konsolidierung": "nein", + "pruefidee": "Fernwartung aus MyDay starten; erwartet: Sitzung zum Kundengerät.", + "qm": "", + "uebernahme": "übernehmen - Supporteffizienz; Werkzeugwahl im Zielsystem prüfen." + } +] \ No newline at end of file diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/anforderungen.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/anforderungen.md new file mode 100644 index 00000000..b91e663f --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/anforderungen.md @@ -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 %) | + diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/before.txt b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/before.txt new file mode 100644 index 00000000..8b137891 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/before.txt @@ -0,0 +1 @@ + diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/combined_prompt.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/combined_prompt.md new file mode 100644 index 00000000..7e83fe58 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/combined_prompt.md @@ -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: - +Titel: +Ebene: +Typ: +Qualitätsmerkmal: +Akteur: +Vorbedingung: +Fakt: +Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage) +Ergebnis: +Belege: + - [PRIMÄR] - Begründung: + - [SEKUNDÄR] <...> - Begründung: <...> + - [KONTEXT] <...> - Begründung: <...> +Prüfidee: +Tracelinks: +Konsolidierung: > +Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - +Status: +``` + +### 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). diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/endzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/endzeit.txt new file mode 100644 index 00000000..269d93eb --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/endzeit.txt @@ -0,0 +1 @@ +2026-08-27T07:28:28.0825221+02:00 diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/startzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/startzeit.txt new file mode 100644 index 00000000..5ce43e82 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_meta/startzeit.txt @@ -0,0 +1 @@ +2026-08-27T00:24:41.6237308+02:00 diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_modcounts.txt b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_modcounts.txt new file mode 100644 index 00000000..5a837cd3 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_modcounts.txt @@ -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 \ No newline at end of file diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_report_part2.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_report_part2.md new file mode 100644 index 00000000..811ec5ae --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_report_part2.md @@ -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). diff --git a/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_report_part3.md b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_report_part3.md new file mode 100644 index 00000000..6b551e7c --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-fable-5/solo/high/02_Lauf_2026-08-27_002430_v7.0.0-35a4/_report_part3.md @@ -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. \ No newline at end of file diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/Protokoll.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/Protokoll.md index a23b4da0..4e5c21f0 100644 --- a/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/Protokoll.md +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/Protokoll.md @@ -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 - **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. +- **Prompt-Version:** 02 - **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849` -- **Startzeit:** 2026-08-26T16:00:49.2361402+02:00 -- **Endzeit:** 2026-08-26T16:21:48.6873493+02:00 -- **Dauer gesamt:** 0:20:59 (`duration_ms` 0:10:57; API: 3:49:48) - — **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` +- **Startzeit:** 2026-08-26T16:00:44.0+02:00 +- **Endzeit:** 2026-08-26T16:21:43.0+02:00 +- **Dauer gesamt:** 00:20:59 — 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 +- **Skill-Version:** 4.5.0 (Laufzeit); Gültigkeitsprüfung nachträglich mit 6.1.0 eingeführt - **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` - **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 -- **Effort:** `high` (per `--effort high` gesetzt) -- **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. +- **Kontrolle Modell:** bestanden – ausschließlich `claude-opus-5` plus Haiku-Hilfsaufrufe +- **Effort:** `high` - **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` -- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` / - `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos). Der Modus `builtin` fügt keine weiteren Sperren hinzu – die werkzeugeigenen Subagenten sind zugelassen. +- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` / 33er-Denylist - **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config` -- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode` -- **Subagenten:** 20 gestartet (10 × `Explore`, 10 × `general-purpose`), 10 abgeschlossen, 0 fehlgeschlagen; 20 im Hintergrund gestartet -- **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`. -- **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 %). - -## Validierungsstichprobe -- **Größe:** noch nicht festgelegt -- **Ziehungsverfahren:** noch nicht festgelegt -- **Validatoren:** noch nicht festgelegt -- **Stand:** noch nicht gezogen +- **Parallele Läufe:** ja – der jeweils andere Lauf dieser Zelle +- **Subagenten:** 20 gestartet (10 × `Explore`, 10 × `general-purpose`), 10 abgeschlossen, 0 fehlgeschlagen +- **Verschachtelung:** `spawned` = 20, davon `spawned_by_subagents` = 10, + `max_depth` = 2, am Nebenläufigkeitslimit abgewiesen: 5 ## 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 | |---|---:|---:|---:| | Input-Tokens | 2.604 | 6.960 | 9.564 | @@ -70,34 +42,56 @@ | Cache-Read-Tokens | 187.592.610 | 0 | 187.592.610 | | **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 -der Subagenten – siehe Feld „Verbrauchsanteil der Subagenten" oben. Für den -abrechnungsrelevanten Gesamtverbrauch gilt ausschließlich `modelUsage`. +**Tokens gesamt: 193.399.648** — 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 Anforderungen im vorgegebenen Format gefunden. +Keine. Der Lauf hat **null** verwertbare Ergebnisdatei(en) erzeugt; eine Auswertung mit +`analyse-anforderungen.py` ist gegenstandslos. ## 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` -- **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. -- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 20 – Bedingung `solo` **VERLETZT – Fehlmessung** -- **Subagenten-Prompts:** `_meta\subagenten.md` erzeugt -- **Erzeugte Dateien:** 0 Dateien in `Ergebnisse\`: - - | Datei | Größe | - |---|---:| - - -- **Root unverändert:** ja (zeilenendennormalisiert verglichen). -- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`) +- **Permission-Denials:** 1 +- **Erzeugte Dateien:** **keine** +- **Root unverändert:** ja +- **Abschlusstext des Agenten:** „Die Erhebung läuft. … 10 von 12 Agenten arbeiten parallel." – der Agent berichtet einen Zwischenstand, keinen Abschluss. ## Anmerkungen/Auffälligkeiten - +**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. diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e/Protokoll.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e/Protokoll.md new file mode 100644 index 00000000..83b8e98c --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e/Protokoll.md @@ -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. diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/Protokoll.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/Protokoll.md new file mode 100644 index 00000000..f45ecb83 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/Protokoll.md @@ -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. diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/RawResult.json b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/RawResult.json new file mode 100644 index 00000000..c28fb58f --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/RawResult.json @@ -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} diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/Stderr.log b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/Stderr.log new file mode 100644 index 00000000..e69de29b diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/before.txt b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/before.txt new file mode 100644 index 00000000..8b137891 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/before.txt @@ -0,0 +1 @@ + diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/combined_prompt.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/combined_prompt.md new file mode 100644 index 00000000..47be58ee --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/combined_prompt.md @@ -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: - +Titel: +Ebene: +Typ: +Qualitätsmerkmal: +Akteur: +Vorbedingung: +Fakt: +Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage) +Ergebnis: +Belege: + - [PRIMÄR] - Begründung: + - [SEKUNDÄR] <...> - Begründung: <...> + - [KONTEXT] <...> - Begründung: <...> +Prüfidee: +Tracelinks: +Konsolidierung: > +Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - +Status: +``` + +### 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). diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/endzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/endzeit.txt new file mode 100644 index 00000000..c1149cf9 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/endzeit.txt @@ -0,0 +1 @@ +2026-08-26T20:31:25.0410574+02:00 diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/startzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/startzeit.txt new file mode 100644 index 00000000..9d5d3846 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_195958_v7.0.0-45dd/_meta/startzeit.txt @@ -0,0 +1 @@ +2026-08-26T20:00:13.2974808+02:00 diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Ergebnisse/Analysebericht.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Ergebnisse/Analysebericht.md new file mode 100644 index 00000000..4cbad24e --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Ergebnisse/Analysebericht.md @@ -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.* diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Ergebnisse/StRS.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Ergebnisse/StRS.md new file mode 100644 index 00000000..41f8ada1 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Ergebnisse/StRS.md @@ -0,0 +1,2088 @@ +# StRS — Stakeholder Requirements Specification + +**System:** c-entron ERP-Suite (Legacy, Windows/C#/XAML/MSSQL) +**Norm:** ISO/IEC/IEEE 29148:2018, Abschnitt 9.3 (Stakeholder Requirements Specification) +**Zweck:** Fachliche Sicht — Akteure, Geschäftsziele, fachliche Bedarfe. Grundlage für eine +Web-/SaaS-Neuimplementierung. + +Begriffe sind im `Glossar.md` definiert. Belegklassifikation: `PRIMÄR` (durchgesetzte Regel in Code +oder DB-Constraint), `SEKUNDÄR` (UI-Label, Fehlermeldung, Konfiguration, Mapping), +`KONTEXT` (Kommentar, Dokumentation, Commit). + +--- + +## 1. Akteure + +Die folgenden Akteure sind aus den Rechte-, Login- und Lizenzkonstanten abgeleitet und werden in den +Anforderungen dieses Dokuments referenziert. + +| Akteur | Herkunft im Code | Beschreibung | +|---|---|---| +| Sachbearbeiter Vertrieb | `UserRightsConst.Sales.*` | Bearbeitet Adressen, Angebote, Aufträge, Rechnungen | +| Servicetechniker / Helpdesk-Bearbeiter | `UserRightsConst.Sales.Customer.Helpdesk.*` | Bearbeitet Tickets und Zeiten | +| Einkäufer | `UserRightsConst.Purchase.*` | Bestellungen, Wareneingang, EDI | +| Lagerist | `UserRightsConst.Purchase.StockList.*`, `UserRightsConst.Logistic.*` | Bestände, Kommissionierung, Inventur | +| Buchhalter / Controller | `UserRightsConst.Controlling.*` | Zahlungen, Mahnwesen, OPOS, Auswertungen | +| Administrator | `UserRightsConst.Administration.*`, `Connection.IsAdmin` | Rechte, Mandanten, Einstellungen, SQL-Manager | +| Geschäftsführung | `UserRightsConst.Controlling.Finances.MANAGEMENT_INFO` | Verdichtete Kennzahlen | +| Endkunde (Web-Account) | `WebLoginType.Customer`, `LoggedInUser.IsWebAccountLogin` | Zugriff über Kundenportal/WebCart | +| Externes System / Konnektor | `ApplicationKind.*` (z. B. `ExternalAppDocBee`, `GFIMax`) | Maschinelle Anmeldung am Web-Service | +| Betreiber (Hosting/Support) | `AuthorizeCentronHostedAttribute`, `LicenseGuids.CentronInternal` | Betrieb der gehosteten Installation | + +--- + +## 2. Anforderungen + +### 2.1 Geschäftsmodell, Lizenzierung, Mandanten + +``` +ID: StRS-001 +Titel: Funktionsumfang wird über Lizenzen gesteuert +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Betreiber, Administrator +Vorbedingung: Eine Installation ist einem Lizenzkunden zugeordnet. +Fakt: Jedes fachliche Modul wird in `ModuleRegistration` mit einem Lizenz-Prädikat registriert + (`() => LicenseManager.Instance.HasLicense(LicenseGuids.X) || ...HasLicense(LicenseGuids.Centron)`); + nur Module, deren Prädikat `true` liefert, werden über `RegisterModule` aktiviert. +Aussage: Das System soll den für einen Kunden sichtbaren Funktionsumfang aus einem + kundenbezogenen Lizenzbestand ableiten und nicht lizenzierte Funktionen vollständig + ausblenden. +Ergebnis: Ein Anwender ohne Lizenz für ein Modul sieht dieses Modul nicht und kann es nicht aufrufen. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Methode `DoRegisterCentronModules`, + Filter `.Where(f => f.CheckModuleFeatures())` mit `ModuleRegistrationItem.CheckModuleFeatures()` + - Begründung: Hier wird die Lizenzbedingung tatsächlich ausgewertet und entscheidet über die Registrierung. + - [PRIMÄR] src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs + - Begründung: 159 Lizenz-GUIDs belegen die Feinkörnigkeit der Lizenzierung. + - [KONTEXT] docs/reference/security/licensing-system.md - Begründung: Beschreibt Lizenz als GUID mit Count, + Gültigkeitsdatum und Gültigkeitsversion. +Prüfidee: Installation ohne die Lizenz `LicenseGuids.PasswordManager` starten; der Passwort-Manager + darf in der Modulliste nicht erscheinen. +Tracelinks: SyRS-001, SyRS-002, SwRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Feature-Gating ist die Basis des Geschäftsmodells und in SaaS unverzichtbar. +Status: belegt +``` + +``` +ID: StRS-002 +Titel: Lizenzen sind mengen- und laufzeitbegrenzt +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Betreiber +Vorbedingung: Ein Anwender meldet sich an einer lizenzpflichtigen Anwendung an. +Fakt: `LicenseManager.CheckLicense` prüft je Lizenz die Version (`CheckLicenseVersion`) und + vergleicht die Anzahl vergebener Verbindungstickets (`TicketBL.GetTicketCount`) gegen + `GetLicenseCount`; bei Überschreitung wird der Fehler + „Die maximale Anzahl an Lizenzen wurde erreicht." mit `DefaultMessageCodes.LicenseMaximumReached` erzeugt. +Aussage: Das System soll die gleichzeitige Nutzung je Lizenz auf die lizenzierte Anzahl + begrenzen und Anmeldungen oberhalb dieser Grenze ablehnen. +Ergebnis: Der Anmeldeversuch scheitert mit einem eindeutigen Fehlercode; bereits angemeldete + Anwender bleiben unberührt. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, `CheckLicense`, + Bedingung `if (currentlyUsedLicenses >= maxNumberOfLicenses)` + - Begründung: Das ist die durchsetzende Stelle der Mengenbegrenzung. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, Index `idx_ConnectionTickets_UniqueLogin` auf + `ConnectionTickets(LicenseGUID, DeviceID, AppUserI3D, WebAccountI3D, MonitoringTokenI3D, ApplicationID)` + - Begründung: Erzwingt genau ein Ticket je Lizenz/Gerät/Benutzer/Anwendung und macht die Zählung eindeutig. + - [KONTEXT] docs/reference/security/licensing-system.md, Abschnitt „Check the `count` of the license" + - Begründung: Bestätigt die fachliche Absicht der Mengenlizenzierung. +Prüfidee: Bei Lizenzanzahl 1 zwei Anmeldungen von unterschiedlichen Geräten versuchen; die zweite + muss mit `LicenseMaximumReached` scheitern. +Tracelinks: StRS-001, SyRS-003, SwRS-002 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Mengen- und Laufzeitbegrenzung bleibt in einem SaaS-Abomodell erforderlich. +Status: belegt +``` + +``` +ID: StRS-003 +Titel: Mehrmandantenbetrieb +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Die Installation soll mehrere rechtlich getrennte Firmen abbilden. +Fakt: Es existiert ein eigenes Modul `MandatorManagementAppModuleController`, geschützt durch + `UserRightsConst.Administration.MANDATORY` und die Lizenz `LicenseGuids.Clients`; + `CentronObjectKindNumeric.Company = 53` ist als „Mandant" kommentiert. +Aussage: Das System soll mehrere Mandanten (Firmen) innerhalb einer Installation verwalten und + Belege sowie Stammdaten einem Mandanten zuordnen können. +Ergebnis: Belege tragen eine Mandantenzuordnung; die Mandantenverwaltung ist nur mit dem + entsprechenden Recht und der Lizenz erreichbar. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.Administration.ID, UserRightsConst.Administration.MANDATORY), ...)` + - Begründung: Die durchsetzende Rechte- und Lizenzbedingung für das Mandantenmodul. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, Spalte `AccountCustomers.MandatorBank` + - Begründung: Mandantenbezug ist auf Datenbankebene modelliert. + - [KONTEXT] src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs, `Company = 53, // Mandant` + - Begründung: Belegt den fachlichen Begriff. +Prüfidee: Zwei Mandanten anlegen und prüfen, dass Belegnummernkreise und Auswertungen je Mandant getrennt sind. +Tracelinks: SyRS-004, SwRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Mandantenfähigkeit ist für SaaS zwingend. +Status: belegt +``` + +``` +ID: StRS-004 +Titel: Filialstruktur als Sichtbarkeits- und Auswertungsdimension +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Geschäftsführung +Vorbedingung: Ein Unternehmen betreibt mehrere Filialen. +Fakt: Es existiert die Lizenz `LicenseGuids.Branch`, das Objekt `CentronObjectKindNumeric.Branch = 124`, + einschränkende Rechte wie `SHOW_HELPDESK_ONLY_OWN_BRANCH` und `RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE` + sowie das Modul „Kalkulation pro Filiale". +Aussage: Das System soll eine Filialstruktur führen, Datensätze einer Filiale zuordnen und + sowohl Sichtbarkeit als auch Auswertungen filialbezogen einschränken können. +Ergebnis: Anwender mit einschränkendem Filialrecht sehen ausschließlich Daten ihrer Filiale. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Rückgabe `ShowHelpdeskRight.OnlyOwnBranch` + bei `ownedAppRights.Contains(UserRightsConst.Sales.Customer.Helpdesk.SHOW_HELPDESK_ONLY_OWN_BRANCH)` + - Begründung: Die filialbezogene Einschränkung wird hier tatsächlich ermittelt und wirkt auf die Ticketsicht. + - [SEKUNDÄR] CentronRights.md, Abschnitt „1.2. Tickets anzeigen - eigene Filiale" + - Begründung: Beschreibt das Recht als einschränkendes Recht. + - [KONTEXT] src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorUser.cs, Kommentar + „Customers and thus WebAccounts belong to the branch their Aussendienst-Mitarbeiter ... belongs to" + - Begründung: Zeigt die fachliche Ableitungsregel der Filialzugehörigkeit von Kunden. +Prüfidee: Benutzer mit `SHOW_HELPDESK_ONLY_OWN_BRANCH` anmelden und prüfen, dass Tickets fremder Filialen fehlen. +Tracelinks: StRS-021, SyRS-010, SwRS-004 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Organisationsstruktur bleibt fachlich relevant. +Status: belegt +``` + +### 2.2 Adress- und Kundenstamm (CRM) + +``` +ID: StRS-005 +Titel: Zentraler Adressstamm für Kunden und Lieferanten +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Sachbearbeiter Vertrieb, Einkäufer +Vorbedingung: Es sollen Geschäftspartner erfasst werden. +Fakt: Die Tabelle `Accounts` trägt eine eindeutige `Number`; `AccountCustomers` und + `AccountSuppliers` referenzieren jeweils einen `Account` und tragen je eigene eindeutige + Nummernkreise (`IX_AccountCustomers_UniqueNumber`, `IX_AccountSuppliers_UniqueNumber`). +Aussage: Das System soll Geschäftspartner in einem gemeinsamen Adressstamm führen und die Rollen + Kunde und Lieferant als getrennte, jeweils eindeutig nummerierte Ausprägungen desselben + Partners abbilden. +Ergebnis: Ein Partner kann gleichzeitig Kunde und Lieferant sein, ohne doppelt erfasst zu werden. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CREATE UNIQUE NONCLUSTERED INDEX [IX_Accounts_Number] ON [dbo].[Accounts]([Number])` + - Begründung: Erzwingt die eindeutige Partnernummer auf Datenbankebene. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CONSTRAINT [IX_AccountCustomers_UniqueNumber] UNIQUE NONCLUSTERED ([Number])` + und `CONSTRAINT [IX_AccountSuppliers_UniqueNumber] UNIQUE NONCLUSTERED ([Number])` + - Begründung: Belegt die getrennten Nummernkreise je Rolle. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `FK_AccountTypeToAccounts_Accounts`, `FK_AccountTypeToAccounts_AccountCustomers`, + `FK_AccountTypeToAccounts_AccountSuppliers` + - Begründung: Belegt die n:m-Zuordnung von Partnerarten zu einem Account. +Prüfidee: Zwei Kunden mit gleicher Kundennummer anlegen; das zweite Speichern muss an der + Unique-Constraint scheitern. +Tracelinks: SyRS-012, SwRS-010, SwRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Zentraler Partnerstamm ist fachlicher Kern. +Status: belegt +``` + +``` +ID: StRS-006 +Titel: Zwei alternative Oberflächen für denselben Adressstamm +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Sachbearbeiter Vertrieb +Vorbedingung: Die Einstellung `CrmSettings.IsAccountManagementActive` ist gesetzt oder nicht gesetzt. +Fakt: `ModuleRegistration` registriert `AccountManagementAppModuleController` nur, wenn + `IsAccountManagementActive` **falsch** ist, und `CrmAppModuleController` nur, wenn sie + **wahr** ist; beide prüfen dieselben Rechte und dieselbe Lizenz `LicenseGuids.AddressMaster`. +Aussage: Das System soll den Adressstamm wahlweise in der klassischen oder in der CRM-Oberfläche + anbieten, wobei je Installation genau eine Variante aktiv ist. +Ergebnis: Der Anwender sieht genau eines der beiden Adressmodule. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierungen von + `AccountManagementAppModuleController` (`!CentronCache.Instance.CrmSettings.IsAccountManagementActive...`) + und `CrmAppModuleController` (`CentronCache.Instance.CrmSettings.IsAccountManagementActive...`) + - Begründung: Die gegenläufigen Bedingungen sind die durchsetzende Stelle der Alternative. +Prüfidee: Einstellung umschalten und prüfen, dass jeweils nur ein Adressmodul erscheint. +Tracelinks: StRS-005, SyRS-013, SwRS-012 +Konsolidierung: Kandidat: StRS-005 - zwei parallel gepflegte Oberflächen für denselben fachlichen Gegenstand + sollten im Zielsystem zu einer Adressoberfläche zusammengeführt werden. +Übernahmewürdigkeit: Workaround - historisch gewachsene Doppelpflege zweier Masken; im Zielsystem genügt eine. +Status: belegt +``` + +``` +ID: StRS-007 +Titel: Kreditlimit je Kunde +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Sachbearbeiter Vertrieb, Buchhalter +Vorbedingung: Beim Kunden ist ein Kreditlimit größer null und eine Berechnungsart hinterlegt. +Fakt: `ReceiptBL.CheckIfCustomerLimitIsReached` summiert das je Belegart gebundene Limit + (`GetUsedLimitAmount`) und setzt bei Überschreitung das Ergebnisflag + `ShowCustomerLimitExceededDialog` mit dem Text „Das Limit von … wurde um … überschritten." +Aussage: Das System soll je Kunde ein Kreditlimit führen, den durch offene Belege gebundenen + Betrag ermitteln und bei Überschreitung vor dem Speichern warnen. +Ergebnis: Der Anwender erhält eine Rückfrage und kann den Beleg bewusst trotzdem speichern. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, `CheckIfCustomerLimitIsReached`, + Bedingung `if (limitUsedInThisReceipt > limitAvailable && data.SaveAlthoughCustomerLimitExceeded == false && data.IgnoreCallbacks == false)` + - Begründung: Die durchsetzende Stelle; sie zeigt zugleich, dass es sich um eine Warnung und keine Sperre handelt. + - [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/CreditLimitCalculationKind.cs (`Gross = 0`, `Net = 1`) + - Begründung: Definiert die zulässigen Berechnungsarten. + - [SEKUNDÄR] Meldungstext „Das Limit von {0} wurde um {1} überschritten … Möchten Sie den Speichervorgang fortsetzen?" + - Begründung: Belegt den Warncharakter gegenüber dem Anwender. +Prüfidee: Kunde mit Limit 1.000 EUR, Auftrag über 1.500 EUR erfassen; die Warnung muss erscheinen, + das Speichern mit `SaveAlthoughCustomerLimitExceeded = true` muss gelingen. +Tracelinks: SyRS-030, SwRS-060 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kreditlimitüberwachung ist ein üblicher betriebswirtschaftlicher Bedarf. +Status: belegt +``` + +``` +ID: StRS-008 +Titel: Kunden können sich selbst über ein Webportal bedienen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Endkunde (Web-Account) +Vorbedingung: Für den Kunden ist ein Web-Account angelegt. +Fakt: `WebLoginType.Customer` führt im `AuthenticatorFactory` zu einem `WebAccountAuthObject` + und damit zum `WebAccountAuthenticator`; im Nexus-Portal existieren die Seiten + `CustomperPortalHomePage`, `CustomerTicketHistoryPage`, `ReceiptsOverview`, `ContractsOverview`. +Aussage: Das System soll Endkunden einen eigenen, vom Mitarbeiterzugang getrennten Portalzugang + bieten, über den sie ihre Tickets, Belege und Verträge einsehen können. +Ergebnis: Ein Endkunde meldet sich mit einem Web-Account an und sieht ausschließlich die ihm + zugeordneten Daten. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs, + `WebLoginType.Customer => new WebAccountAuthObject {...}` und + `GetFromWebAccountAuth(...) => new WebAccountAuthenticator(...)` + - Begründung: Die durchsetzende Stelle der getrennten Anmeldeart. + - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs, `ValidateUserRights(LoggedInUser ...)`: + `if (loggedInUser.IsWebAccountLogin) return Result.AsError("Webaccount hat keine Rechte für diese Aktion", ...)` + - Begründung: Belegt, dass Web-Accounts pauschal von Mitarbeiterfunktionen ausgeschlossen sind. + - [SEKUNDÄR] src/nexus/CentronNexus/WebCart/CustomperPortalHomePage.razor, CustomerTicketHistoryPage.razor, + ReceiptsOverview.razor, ContractsOverview.razor + - Begründung: Belegen den fachlichen Funktionsumfang des Portals. +Prüfidee: Mit einem Web-Account anmelden und den Aufruf einer Adressänderungsfunktion versuchen; + dieser muss mit „Webaccount hat keine Rechte für diese Aktion" abgewiesen werden. +Tracelinks: StRS-009, SyRS-014, SyRS-015, SwRS-014 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kundenselbstbedienung ist im SaaS-Zielbild zentral. +Status: belegt +``` + +``` +ID: StRS-009 +Titel: Kundenspezifische Sonderpreise als Grundlage des Webshops +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Endkunde (Web-Account), Sachbearbeiter Vertrieb +Vorbedingung: Für den Kunden sind Sonderpreise gepflegt. +Fakt: Die Projektdokumentation beschreibt: „The available articles come from the customers + 'Sonderpreise'"; im Schema existiert `AccountArticleSpecialPricesImportSettings` mit + dem eindeutigen Index `idx_AccountArticleSpecialPricesImportSettings_UniqueSettings`. +Aussage: Das System soll den im Kundenportal sichtbaren Artikelkatalog aus den für diesen Kunden + gepflegten Sonderpreisen ableiten. +Ergebnis: Ein Kunde sieht im Shop nur Artikel, für die ihm ein Sonderpreis zugeordnet ist. +Belege: + - [SEKUNDÄR] README.md, Abschnitt „Contributing / 1. WebCart" + - Begründung: Beschreibt die fachliche Ableitung des Katalogs, ist aber keine durchsetzende Codestelle. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CREATE UNIQUE NONCLUSTERED INDEX [idx_AccountArticleSpecialPricesImportSettings_UniqueSettings]` + - Begründung: Belegt die Existenz und Eindeutigkeit kundenbezogener Sonderpreiskonfigurationen. + - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Sales/SpecialArticleImport/ (Modul „Statischer Datenimport - Verträge") + - Begründung: Belegt den Importweg für Sonderartikel/-preise. +Prüfidee: Für einen Testkunden einen Sonderpreis anlegen und prüfen, dass genau dieser Artikel im + Portal erscheint. +Tracelinks: StRS-008, SyRS-016, SwRS-015 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kundenindividuelle Kataloge sind fachlich weiterhin erforderlich. +Status: belegt +``` + +### 2.3 Belegwesen und Fakturierung + +``` +ID: StRS-010 +Titel: Durchgängige Belegkette im Verkauf +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Sachbearbeiter Vertrieb +Vorbedingung: Ein Kundenauftrag soll vom Angebot bis zur Rechnung abgewickelt werden. +Fakt: `CentronObjectKindNumeric` führt die Belegarten `OfferClass = 1`, `OrderClass = 2`, + `DeliveryListClass = 3`, `InvoiceClass = 4`, `PickupListClass = 5`, + `CreditVoucherClass = 6`, `ContractClass = 22`; alle Belegentitäten leiten von + `ReceiptBase` ab und besitzen je ein Kopf-/Positions-Tabellenpaar. +Aussage: Das System soll die Belegarten Angebot, Auftrag, Lieferschein, Rechnung, Abholschein, + Gutschrift und Vertrag als einheitlich strukturierte Belege mit Kopf und Positionen führen. +Ergebnis: Alle Belegarten teilen Kopf-, Adress-, Währungs- und Auditfelder und lassen sich ineinander überführen. +Belege: + - [PRIMÄR] src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs, Werte 1–6 und 22 mit `[Description]`-Attributen + - Begründung: Definiert die Belegarten als durchgesetzte Enumeration. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, Tabellen `AngKopf`/`AngPos`, `AufKopf`/`AufPos`, `LiefKopf`/`LiefPos`, + `RechKopf`/`RechPos`, `VertragKopf`/`VertragPos`, `GutKopf`/`GutPos`, `AbholKopf`/`AbholPos` + - Begründung: Belegt die durchgehende Kopf-/Positionsstruktur im Datenmodell. + - [KONTEXT] docs/reference/receipts/receipts-backend-architecture.md, Tabelle „Receipt Types Hierarchy" + - Begründung: Ordnet Entität, Tabelle und View je Belegart zu. +Prüfidee: Aus einem Angebot einen Auftrag, daraus einen Lieferschein und daraus eine Rechnung + erzeugen; Positionsdaten müssen erhalten bleiben. +Tracelinks: SyRS-020, SyRS-021, SwRS-030, SwRS-031 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Die Belegkette ist der fachliche Kern des ERP. +Status: belegt +``` + +``` +ID: StRS-011 +Titel: Belege sind versioniert und revisionsfähig +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhalter, Administrator +Vorbedingung: Ein Beleg wird geändert. +Fakt: Zu jedem Kopf-/Positionstabellenpaar existiert ein Versionstabellenpaar + (`AngKopfVersions`/`AngPosVersions` … `VertragKopfVersions`/`VertragPosVersions`); + `ReceiptBase` führt die Auditfelder `CreatedByI3D`, `CreatedAt`, `ChangedByI3D`, `ChangedAt` + sowie eine `Version`; die zentrale Tabelle `AnlageLog` protokolliert je Belegart (`AnlageArt`). +Aussage: Das System soll jede Belegänderung als vollständige Momentaufnahme des Belegs + nachvollziehbar aufbewahren und Ersteller sowie Änderer festhalten. +Ergebnis: Zu jedem Beleg lässt sich der Zustand zu einem früheren Zeitpunkt rekonstruieren. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, Versionstabellen `*KopfVersions` / `*PosVersions` je Belegart + - Begründung: Die Versionshistorie ist im Schema materialisiert, nicht nur konzeptionell. + - [KONTEXT] docs/reference/receipts/receipts-backend-architecture.md, Abschnitt „Version Tables: 1:1 Copies" + mit dem SQL-Muster `INSERT INTO AngKopfVersions (...) SELECT ..., I3D AS OriginalI3D FROM AngKopf` + - Begründung: Beschreibt den Kopiermechanismus über `AssetHeadDAO.SaveAssetVersion`. + - [KONTEXT] docs/reference/receipts/contracts-backend.md, Abschnitt „AnlageLog Integration" (`AnlageArt = 22`) + - Begründung: Belegt die zentrale Protokolltabelle. +Prüfidee: Einen Beleg zweimal ändern und prüfen, dass in der Versionstabelle zwei vollständige + Datensätze mit `OriginalI3D` auf den Beleg entstehen. +Tracelinks: StRS-010, SyRS-022, SwRS-032 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Revisionssicherheit ist bei Belegen gesetzlich und fachlich geboten. +Status: belegt +``` + +``` +ID: StRS-012 +Titel: Verträge werden periodisch automatisch abgerechnet +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhalter +Vorbedingung: Ein Vertrag ist mit Abrechnungsintervall und automatischer Abrechnung konfiguriert. +Fakt: `VertragKopf` führt die Spalten `AbrechnungIntervallArt`, `AbrechnungIntervallDauer`, + `AutoAbrechnung`, `LetzteRechnungDatum`, `AutoVerlaengerung`; `AutomaticFacturaBL.Contracts` + berechnet in `NextDate(IContractHead contract)` je `BillingIntervalKinds` + (Daily/Monthly/Quarterly/Yearly) den nächsten Abrechnungszeitpunkt. +Aussage: Das System soll aus Verträgen ohne manuellen Anstoß Rechnungen im hinterlegten + Intervall erzeugen und den nächsten Abrechnungszeitraum fortschreiben. +Ergebnis: Für jeden fälligen Vertrag entsteht eine Rechnung; das Feld für die letzte Abrechnung wird fortgeschrieben. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, + Methode `NextDate(IContractHead contract)` mit `switch (contract.BillingIntervalKind)` + - Begründung: Die durchsetzende Berechnung des nächsten Abrechnungsintervalls. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[VertragKopf]` mit `AbrechnungIntervallArt`, + `AbrechnungIntervallDauer`, `AutoAbrechnung`, `LetzteRechnungDatum` + - Begründung: Belegt die persistierten Abrechnungsparameter. + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Modul + `AutomatedBillingAppModuleController` mit Recht `UserRightsConst.Sales.AUTOMATED_BILLING` + und Lizenz `LicenseGuids.ContractBilling` + - Begründung: Belegt die Zugangskontrolle der Vertragsabrechnung. +Prüfidee: Vertrag mit monatlichem Intervall und Vertragsbeginn am 31.01. anlegen; der berechnete + Folgezeitraum muss am Monatsletzten enden (Sonderbehandlung für Tage > 28). +Tracelinks: StRS-013, SyRS-040, SyRS-041, SwRS-070, SwRS-071 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Wiederkehrende Abrechnung ist Kern des Servicegeschäfts. +Status: belegt +``` + +``` +ID: StRS-013 +Titel: Kalendergenaue Behandlung von Monatsenden und Schaltjahren in der Abrechnung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhalter +Vorbedingung: Ein Vertrag beginnt an einem Tag nach dem 28. eines Monats oder am 29. Februar. +Fakt: In `NextDate` werden gesonderte Zweige für `contract.InvoiceFrom.Day > 28`, + für `nextdate.Month == 2 && contract.InvoiceFrom.Day > 28` inklusive + `DateTime.IsLeapYear(nextdate.Year)` und für `contract.InvoiceFrom.Month == 2 && + contract.InvoiceFrom.Day == DateTime.DaysInMonth(...)` ausgewertet. +Aussage: Das System soll bei monatlichen Abrechnungsintervallen den Abrechnungstag so + fortschreiben, dass Monate mit weniger Tagen und Schaltjahre nicht zu einer + Verschiebung des Abrechnungsrhythmus führen. +Ergebnis: Ein am 31. beginnender Vertrag wird in kürzeren Monaten am Monatsletzten abgerechnet und + kehrt in längeren Monaten auf den ursprünglichen Tag zurück. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, + `NextDate`, Zweig `if (contract.InvoiceFrom.Day > 28 && nextdate.Month != 2)` mit + `int diffDay = DateTime.DaysInMonth(...) + 1 - contract.InvoiceFrom.Day;` + - Begründung: Die konkrete Rechenregel für die Monatsendkorrektur. + - [PRIMÄR] Ebenda, Zweig `if (nextdate.Month == 2 && contract.InvoiceFrom.Day > 28)` mit + `if (!DateTime.IsLeapYear(nextdate.Year) || contract.InvoiceFrom.Day > 29)` + - Begründung: Die konkrete Schaltjahrbehandlung. +Prüfidee: Vertrag mit `InvoiceFrom` = 31.01.2027 (kein Schaltjahr): Der Folgezeitraum muss am + 28.02.2027 enden, der übernächste wieder am 31.03.2027. +Tracelinks: StRS-012, SwRS-071 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Die Regel ist fachlich korrekt und muss im Zielsystem 1:1 nachgebildet werden; + die Implementierung selbst ist unübersichtlich und sollte neu geschrieben werden. +Status: belegt +``` + +``` +ID: StRS-014 +Titel: Kontingentverträge mit Verbrauchsverrechnung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhalter, Servicetechniker +Vorbedingung: Ein Vertrag führt ein Stunden- oder Betragskontingent. +Fakt: `VertragKopf` enthält `KontingentWert` und `KontingentArt`; `ReceiptContract` führt + `ContingentUsedHours`, `ContingentUsedAmount`, `ContingentBalanceUsedHours`, + `ContingentBalanceUsedAmount`, `IsContingentLimitBilling`, `ContingentLimitValue`, + `ContingentLimitKind`; `ReceiptContractBL` stellt + `ContractContingentBalanceCalculation()` und `UpdateTakeRestAndOverBooking()` bereit. +Aussage: Das System soll Verträge mit vorab vereinbartem Stunden- oder Betragskontingent führen, + den Verbrauch fortschreiben, Restwerte übertragen und Überschreitungen gesondert abrechnen. +Ergebnis: Der Kontingentsaldo eines Vertrags ist jederzeit ermittelbar; Über- und Restmengen sind abgebildet. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `VertragKopf.KontingentWert`, `VertragKopf.KontingentArt` + - Begründung: Kontingente sind auf Datenbankebene persistiert. + - [KONTEXT] docs/reference/receipts/contracts-backend.md, Abschnitt „Contingent Management" und + „Contingent Limits and Monitoring" + - Begründung: Benennt die Eigenschaften und die zugehörigen BL-Methoden. + - [KONTEXT] docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md + - Begründung: Weiterführende Beschreibung der vertragsbezogenen Abrechnungslogik. +Prüfidee: Vertrag mit 10-Stunden-Kontingent anlegen, 12 Stunden buchen; 10 Stunden müssen gegen das + Kontingent, 2 Stunden gesondert abgerechnet werden. +Tracelinks: StRS-012, SyRS-042, SwRS-072 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kontingentmodelle sind im Managed-Service-Geschäft üblich. +Status: belegt +``` + +``` +ID: StRS-015 +Titel: Klickabrechnung für Druck- und Kopiergeräte +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhalter, Servicetechniker +Vorbedingung: Ein Vertrag ist stammblattbezogen und an ein zählendes Gerät gekoppelt. +Fakt: Es existiert das Modul `DeviceClickCounterAppModuleController` („Klick-Zählerverwaltung", + Recht `RIGHT_ZAEHLEREINGABE`, Lizenz `LicenseGuids.ClickCounterManagement`) sowie die + Einstellungsseite `ClickBillingSettingsController`; `VertragKopf` führt `Stammblattbezogen`; + `ReceiptContractBL` stellt `ResetDeviceClickCounter()`, `CheckCounterHistory()` und + `SaveContractFreeCopies()` bereit. +Aussage: Das System soll Zählerstände von Druck- und Kopiergeräten erfassen, Freikopien + berücksichtigen und die verbrauchsabhängige Differenz vertragsbezogen abrechnen. +Ergebnis: Aus zwei aufeinanderfolgenden Zählerständen entsteht abzüglich der Freikopien eine abrechenbare Menge. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.Sales.ID, UserRightsConst.RIGHT_ZAEHLEREINGABE), ...)` + - Begründung: Die durchsetzende Rechte-/Lizenzbedingung der Zählerverwaltung. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `VertragKopf.Stammblattbezogen` + - Begründung: Belegt die Kopplung von Vertrag und Gerätestammblatt im Datenmodell. + - [KONTEXT] docs/reference/receipts/contracts-backend.md, „Counter Reading Management" mit + `ResetDeviceClickCounter()`, `CheckCounterHistory()`, `SaveContractFreeCopies()` + - Begründung: Benennt die zuständigen Methoden. +Prüfidee: Zwei Zählerstände mit Differenz 1.000 und 200 Freikopien erfassen; die abrechenbare Menge muss 800 betragen. +Tracelinks: StRS-014, StRS-026, SyRS-043, SwRS-073 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Klickabrechnung ist ein tragendes Geschäftsmodell im Bürodruckumfeld. +Status: belegt +``` + +``` +ID: StRS-016 +Titel: Mehrstufiges Mahnwesen über offene Rechnungen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhalter +Vorbedingung: Es existieren fällige, nicht ausgeglichene Rechnungen. +Fakt: `DunningLevel` definiert die Stufen `None`, `Level1`, `Level2`, `Level3`; es existieren + `DunningBL`, `DunningRunBL`, die Entitäten `DunningRunForCustomer`, `DunningRunItem`, + `InvoiceDunning`, `CreditVoucherDunning`, `DunningCustomer` sowie das Modul + `DunningOverviewAppModuleController` mit dem Recht `UserRightsConst.Controlling.Finances.Dunning`. +Aussage: Das System soll Mahnläufe über offene Rechnungen durchführen und dabei je Kunde und + Rechnung eine von drei Mahnstufen fortschreiben. +Ergebnis: Je Mahnlauf entsteht ein nachvollziehbarer Lauf mit Positionen je Kunde und Rechnung. +Belege: + - [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/Invoices/Dunning/DunningLevel.cs + (`None, Level1, Level2, Level3`) + - Begründung: Definiert die zulässigen Mahnstufen abschließend. + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.Controlling.Finances.Dunning), ...)` + - Begründung: Durchsetzende Rechteprüfung für den Zugang zum Mahnwesen. + - [SEKUNDÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/Invoices/Dunning/DunningRunForCustomer.cs, + DunningRunItem.cs, InvoiceDunning.cs, CreditVoucherDunning.cs + - Begründung: Belegen die Datenstruktur des Mahnlaufs. +Prüfidee: Rechnung überfällig setzen und drei Mahnläufe durchführen; die Mahnstufe muss von + `Level1` über `Level2` auf `Level3` steigen. +Tracelinks: StRS-017, SyRS-044, SwRS-074 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Forderungsmanagement bleibt erforderlich. +Status: belegt +``` + +``` +ID: StRS-017 +Titel: Offene-Posten-Verwaltung und Zahlungszuordnung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhalter +Vorbedingung: Rechnungen sind gestellt und Zahlungen gehen ein. +Fakt: Es existieren die Module `OposOverviewAppModuleController` (Lizenz `LicenseGuids.OPOS`) + und `PaymentsAppModuleController` (Recht + `UserRightsConst.Controlling.Finances.INCOMING_PAYMENT_TRANSACTIONS`, + Lizenz `LicenseGuids.PaymentReceipt`). +Aussage: Das System soll offene Posten je Kunde ausweisen und eingehende Zahlungen den offenen + Rechnungen zuordnen. +Ergebnis: Der offene Betrag je Kunde und Rechnung ist jederzeit ermittelbar. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierungen von + `OposOverviewAppModuleController` und `PaymentsAppModuleController` mit den genannten + Rechte- und Lizenzprädikaten + - Begründung: Belegt Existenz und Zugangskontrolle beider Funktionen. + - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Opos/, .../Finances/Payments/ + - Begründung: Belegen die zugehörigen Oberflächen. +Prüfidee: Rechnung über 100 EUR stellen, Zahlung über 60 EUR zuordnen; der offene Posten muss 40 EUR betragen. +Tracelinks: StRS-016, StRS-018, SyRS-045, SwRS-075 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - OP-Verwaltung ist buchhalterischer Standard. +Status: belegt +``` + +``` +ID: StRS-018 +Titel: SEPA-Zahlungsverkehr mit Mandatsverwaltung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhalter +Vorbedingung: Für einen Kunden liegt ein SEPA-Mandat vor. +Fakt: Das Modul `PaymentTransactionAppModuleController` ist mit der Lizenz `LicenseGuids.SEPA` + registriert; es existiert die Einstellungsseite `SepaContractSettingsAppModuleController` + und der Dokumenthandler `SepaContractOnlinePdfDocumentHandler`; `ReceiptContract` führt `MandatI3D`. +Aussage: Das System soll SEPA-Lastschriftmandate je Kunde verwalten und Zahlungsverkehrsdateien + für den Einzug offener Forderungen erzeugen. +Ergebnis: Zu jedem eingezogenen Betrag ist das zugrunde liegende Mandat nachvollziehbar. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.Controlling.ID, UserRightsConst.Controlling.Finances.ID, UserRightsConst.Controlling.Finances.INCOMING_PAYMENT_TRANSACTIONS), ... LicenseGuids.SEPA ...)` + - Begründung: Durchsetzende Rechte- und Lizenzbedingung. + - [PRIMÄR] src/backend/Centron.BL/Administration/Documents/Dsgvo/SepaContractOnlinePdfDocumentHandler.cs + - Begründung: Belegt die dokumentseitige Mandatsverwaltung als eigenständige Komponente. + - [KONTEXT] docs/reference/receipts/contracts-backend.md, Eigenschaft `MandatI3D`: „SEPA mandate reference" + - Begründung: Belegt den Mandatsbezug am Vertrag. +Prüfidee: Vertrag mit Mandat abrechnen und prüfen, dass die erzeugte SEPA-Datei die Mandatsreferenz enthält. +Tracelinks: StRS-017, SyRS-046, SwRS-076 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Lastschrifteinzug ist im Abomodell zentral. +Status: belegt +``` + +``` +ID: StRS-019 +Titel: Übergabe der Buchungsdaten an die Finanzbuchhaltung +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Buchhalter +Vorbedingung: Ein Abrechnungszeitraum ist abgeschlossen. +Fakt: Es existieren die Module `DataExchangeAppModuleController` (Rechte + `DataExchange.BOOKKEEPING_EXPORT` / `BOOKKEEPING_IMPORT`) und + `DatevOnlineAppModuleController` (Lizenz `LicenseGuids.DatevOnline`); beide sind mit + `#pragma warning disable 612 //Obsolete` umschlossen. +Aussage: Das System soll Buchungssätze und Belege an eine externe Finanzbuchhaltung übergeben + und Rückmeldungen einlesen können. +Ergebnis: Ein Export erzeugt eine für die Finanzbuchhaltung lesbare Datei bzw. Übertragung. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.DataExchange.ID) && Helper.HasAnyRight(UserRightsConst.DataExchange.BOOKKEEPING_EXPORT, UserRightsConst.DataExchange.BOOKKEEPING_IMPORT), ...)` + - Begründung: Die durchsetzende Rechteprüfung des Buchhaltungsaustauschs. + - [KONTEXT] Ebenda, `#pragma warning disable 612 //Obsolete` um beide Registrierungen + - Begründung: Belegt, dass die zugrunde liegenden Typen als veraltet markiert sind. + - [SEKUNDÄR] src/backend/Centron.BL/Accounting/, src/centron/.../DataExchange/BookKeeping/ + - Begründung: Belegen die zugehörige Logik und Oberfläche. +Prüfidee: Buchhaltungsexport für einen Monat ausführen und die erzeugte Datei gegen das Zielformat prüfen. +Tracelinks: SyRS-047, SwRS-077 +Konsolidierung: Kandidat: StRS-020 - Buchhaltungsexport und DATEV-Belegtransfer bilden denselben + fachlichen Vorgang „Übergabe an die Fibu" in zwei getrennten Implementierungen ab. +Übernahmewürdigkeit: übernehmen - Fibu-Übergabe bleibt erforderlich; die als obsolet markierte + Implementierung ist jedoch zu ersetzen. +Status: belegt +``` + +``` +ID: StRS-020 +Titel: Elektronische Rechnungsformate (ZUGFeRD/XRechnung, ebInterface) +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Buchhalter, Endkunde +Vorbedingung: Eine Rechnung soll elektronisch übermittelt werden. +Fakt: Es existieren der Controller `ZugferdImportController`, die Zuordnungsdokumente + `docs/reference/zugferd-field-mapping.md` und `zugferd-feldzuordnung-anwender.md` + sowie das Projekt `Centron.Api.EbInterface` mit `EbInterfaceLogic`. +Aussage: Das System soll Rechnungen in den strukturierten Formaten ZUGFeRD/XRechnung sowie + ebInterface erzeugen und eingehende strukturierte Rechnungen einlesen. +Ergebnis: Eine erzeugte Rechnung enthält die strukturierten Rechnungsdaten gemäß Feldzuordnung. +Belege: + - [PRIMÄR] src/webservice/Centron.Controllers/Controllers/v1/Receipts/ZugferdImportController.cs + - Begründung: Belegt den durchgesetzten Importweg als eigenen API-Endpunkt. + - [PRIMÄR] src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs + - Begründung: Belegt die eigenständige Erzeugung des österreichischen Formats. + - [KONTEXT] docs/guides/development/xrechnung.md + - Begründung: Verweist auf die zugrunde gelegte ZUGFeRD-2.1.1-Spezifikation und nennt die + Eigenimplementierung als bewusste Entscheidung. +Prüfidee: Eine Rechnung als ZUGFeRD exportieren und mit dem KOSIT-Prüfwerkzeug validieren. +Tracelinks: StRS-019, SyRS-048, SwRS-078 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - E-Rechnung ist in Deutschland verpflichtend; die Eigenimplementierung + sollte laut Projektdoku durch eine Bibliothek ersetzt werden. +Status: belegt +``` + +### 2.4 Service, Helpdesk und Ticketing + +``` +ID: StRS-021 +Titel: Serviceticketbearbeitung als eigenständiger Geschäftsprozess +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker, Endkunde +Vorbedingung: Ein Kunde meldet einen Servicefall. +Fakt: `CentronObjectKindNumeric.HelpdeskClass = 10` und `HelpdeskTimerClass = 4000056`; + `HelpdeskBL` implementiert Sichtbarkeitsregeln, Pflichtfeldprüfung + (`DoValidateMandatoryFields`) und Speichervorverarbeitung (`DoBeforeSave`); + `CentronRights.md` beschreibt 18 Helpdesk-Rechtegruppen. +Aussage: Das System soll Servicefälle als Tickets mit Typ, Kategorie, Priorität, Status, + Bearbeiter und erfassten Zeiten führen. +Ergebnis: Jeder Servicefall ist als Ticket mit zugehörigen Zeitbuchungen nachvollziehbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, `Save(Helpdesk entity, LoggedInUser currUser, bool ignoreMandatoryFields)` + mit vorgeschaltetem `DoValidateMandatoryFields(entity)` + - Begründung: Die durchsetzende Pflichtfeldprüfung beim Speichern eines Tickets. + - [PRIMÄR] src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs, `HelpdeskClass = 10`, `HelpdeskTimerClass = 4000056` + - Begründung: Ticket und Ticketzeit sind eigenständige Objektarten des Systems. + - [SEKUNDÄR] CentronRights.md, Abschnitte 1–18 des Kapitels „Helpdesk" + - Begründung: Beschreibt den fachlichen Funktionsumfang aus Rechtesicht. +Prüfidee: Ticket ohne Pflichtangaben speichern; das Speichern muss mit einem Fehler abgewiesen werden. +Tracelinks: StRS-022, StRS-023, SyRS-050, SwRS-080 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Ticketing ist tragender Geschäftsprozess. +Status: belegt +``` + +``` +ID: StRS-022 +Titel: Abgestufte Ticketsichtbarkeit durch einschränkende Rechte +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Servicetechniker, Administrator +Vorbedingung: Ein Benutzer besitzt das Recht `SHOW_HELPDESK`. +Fakt: `HelpdeskBL` ermittelt aus den Rechten `SHOW_HELPDESK`, `SHOW_HELPDESK_ONLY_OWN` und + `SHOW_HELPDESK_ONLY_OWN_BRANCH` genau eine Sichtbarkeitsstufe + (`ShowHelpdeskRight.All | OnlyOwn | OnlyOwnBranch | None`), wobei `OnlyOwn` vor + `OnlyOwnBranch` geprüft wird und damit Vorrang hat. +Aussage: Das System soll die Ticketsichtbarkeit eines Benutzers auf alle, nur eigene oder nur + Tickets der eigenen Filiale einschränken können; ohne Grundrecht ist keinerlei + Ticketzugriff möglich. +Ergebnis: Der ermittelte Sichtbarkeitsgrad begrenzt sämtliche Ticketlisten und -zugriffe des Benutzers. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Auswertung + `ownedAppRights.Contains(UserRightsConst.Sales.Customer.Helpdesk.SHOW_HELPDESK)` mit + anschließender Prüfung auf `SHOW_HELPDESK_ONLY_OWN` und `SHOW_HELPDESK_ONLY_OWN_BRANCH`, + Rückgabe `ShowHelpdeskRight.None` ohne Grundrecht + - Begründung: Die durchsetzende Stelle inklusive der Vorrangregel zwischen den beiden einschränkenden Rechten. + - [PRIMÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs, + `SHOW_HELPDESK_ONLY_OWN = 20400340`, `SHOW_HELPDESK_ONLY_OWN_BRANCH = 20800045` + - Begründung: Belegt die konkreten Rechtekennungen. + - [SEKUNDÄR] CentronRights.md, Abschnitte 1.1 und 1.2 („This is a **restricting right**") + - Begründung: Beschreibt das Konzept einschränkender Rechte. +Prüfidee: Benutzer mit `SHOW_HELPDESK` + `SHOW_HELPDESK_ONLY_OWN` + `SHOW_HELPDESK_ONLY_OWN_BRANCH` + anlegen; die wirksame Stufe muss `OnlyOwn` sein. +Tracelinks: StRS-004, StRS-021, SyRS-051, SwRS-081 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Abgestufte Sichtbarkeit ist datenschutzrechtlich und organisatorisch nötig. +Status: belegt +``` + +``` +ID: StRS-023 +Titel: Ticketzeiten als Grundlage der Leistungsabrechnung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker, Buchhalter +Vorbedingung: An einem Ticket wurden Zeiten erfasst. +Fakt: `CentronRights.md` bindet das Verschieben und Löschen von Ticketzeiten an die + Bedingung „But only if the ticket is not part of a receipt"; es existiert das Modul + `TimerBillingAppModuleController` („Vereinfachte Ticketabrechnung") mit dem Recht + `UserRightsConst.Sales.TIMER_BILLING_MODULE`. +Aussage: Das System soll erfasste Ticketzeiten in Rechnungen überführen und nach dieser + Überführung das Verschieben und Löschen der Zeiten unterbinden. +Ergebnis: Bereits abgerechnete Ticketzeiten sind unveränderlich. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.Sales.ID, UserRightsConst.Sales.Customer.CustomerCommon.Invoice.SHOW_INVOICES, UserRightsConst.Sales.TIMER_BILLING_MODULE), ...)` + - Begründung: Belegt, dass die Ticketabrechnung an das Rechnungsrecht gekoppelt ist. + - [SEKUNDÄR] CentronRights.md, Abschnitte 8 und 9: „But only if the ticket is not part of a receipt." + - Begründung: Beschreibt die Sperre nach Abrechnung, benennt aber keine Codestelle. + - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/TimerBilling/Pages/TimerBillingTimerSelectionPageViewModel.cs, + vier Stellen mit `string caption = "Fehlende Rechte";` + - Begründung: Belegt die Rechteprüfung an der Oberfläche der Ticketabrechnung. +Prüfidee: Ticketzeit abrechnen und anschließend löschen wollen; der Löschversuch muss abgewiesen werden. +Tracelinks: StRS-021, SyRS-052, SwRS-082 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Der Schutz abgerechneter Zeiten ist buchhalterisch notwendig. +Status: belegt +``` + +``` +ID: StRS-024 +Titel: Checklisten und Ticketprozessvorlagen zur Standardisierung von Serviceabläufen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Ein wiederkehrender Serviceablauf ist definiert. +Fakt: Es existieren die Module `CentronChecklistAppModuleController` (Recht + `Helpdesk.Checklists.ID`, Lizenz `LicenseGuids.Checklists`) und + `TicketProcessTemplateAppModuleController` (zusätzlich Bedingung + `ModuleFeatures.IsTicketProcessAvailable` und Lizenz `LicenseGuids.TicketProcessTemplates`); + `CentronRights.md` beschreibt vier Checklistenrechte und vier C-FLOW-Ticketvorlagenrechte. +Aussage: Das System soll wiederkehrende Serviceabläufe als Checklisten- und Prozessvorlagen + hinterlegen und beim Anlegen eines Tickets daraus konkrete Arbeitsschritte erzeugen. +Ergebnis: Ein aus einer Vorlage erzeugtes Ticket enthält die vorgesehenen Schritte mit Bearbeiterzuordnung. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierungen von + `CentronChecklistAppModuleController` und `TicketProcessTemplateAppModuleController` + - Begründung: Die durchsetzenden Rechte-, Feature- und Lizenzbedingungen beider Module. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CREATE UNIQUE CLUSTERED INDEX [CL_TicketPatternCustomerMappings]` + und `[CL_CentronChecklistCustomerMappings]` + - Begründung: Belegt die kundenbezogene Zuordnung von Vorlagen mit erzwungener Eindeutigkeit. + - [SEKUNDÄR] CentronRights.md, Abschnitte 16 und 17 + - Begründung: Beschreiben den fachlichen Umfang. +Prüfidee: Ticket aus einer Vorlage mit drei Schritten anlegen; das Ticket muss drei Checklistenpunkte enthalten. +Tracelinks: StRS-021, SyRS-053, SwRS-083 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Standardisierung von Serviceabläufen ist fachlich sinnvoll. +Status: belegt +``` + +``` +ID: StRS-025 +Titel: Automatische Ticketerzeugung aus wiederkehrenden Anlässen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Für einen wiederkehrenden Anlass ist eine Vorlage hinterlegt. +Fakt: Es existiert die Dokumentation `docs/features/automatic-helpdesk-creation-templates.md` + sowie die Hintergrunddienste `EscalationsService`, `ReminderService` und + `ValidateHelpdeskFingerprintService`. +Aussage: Das System soll Tickets aus hinterlegten Vorlagen ohne Benutzerinteraktion erzeugen, + etwa für Wartungen, Fristen und Eskalationen. +Ergebnis: Zum vorgesehenen Zeitpunkt entsteht ein Ticket mit den Vorlagendaten. +Belege: + - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/EscalationsService.cs, + ReminderService.cs, ValidateHelpdeskFingerprintService.cs + - Begründung: Belegen die tatsächlich laufenden Dienste, die diese Automatik ausführen. + - [KONTEXT] docs/features/automatic-helpdesk-creation-templates.md + - Begründung: Beschreibt das Vorlagenkonzept. + - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/EscalationsSettings/EscalationType/ + - Begründung: Belegt die Konfigurierbarkeit von Eskalationsarten. +Prüfidee: Wartungstermin mit Vorlage anlegen; zum Termin muss automatisch ein Ticket entstehen. +Tracelinks: StRS-024, SyRS-054, SwRS-084 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Automatisierung wiederkehrender Serviceanlässe ist fachlich wertvoll. +Status: belegt +``` + +``` +ID: StRS-026 +Titel: Gerätestammblätter als Bezugsobjekt für Service und Abrechnung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker, Buchhalter +Vorbedingung: Beim Kunden ist ein Gerät installiert. +Fakt: `CentronObjectKindNumeric.MasterDataListClass = 25`; es existieren das Modul + `MasterDataListOverviewAppModuleController` (Recht `SHOW_MASTERDATALIST`, Lizenz + `LicenseGuids.MasterSheets`), der Controller `MasterDataListsController` und + `MasterDataListWebServiceBL` mit einer eigenen Rechteprüfung für die Seriennummer des Hauptgeräts. +Aussage: Das System soll installierte Kundengeräte als Stammblätter mit Seriennummern führen und + sie mit Verträgen, Tickets und Belegpositionen verknüpfen. +Ergebnis: Zu jedem Gerät sind Vertrag, Servicehistorie und Zählerstände auffindbar. +Belege: + - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/MasterDataLists/MasterDataListWebServiceBL.cs, + Zeilen 173 und 188: `return Result.AsError("Fehlende Rechte zum Ändern der Seriennummer des Hauptgeräts am Stammblatt.", DefaultMessageCodes.RightCheckFailed);` + - Begründung: Die durchsetzende Rechteprüfung an der zentralen Identifikationseigenschaft des Stammblatts. + - [PRIMÄR] src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs, `MasterDataListClass = 25` + - Begründung: Belegt das Stammblatt als eigenständige Objektart. + - [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/IReceiptItemWithMasterDataList.cs und + IReceiptItemWithMasterDataListSerialNumberI3D.cs + - Begründung: Belegen die Verknüpfung von Belegpositionen mit Stammblatt und Seriennummer. +Prüfidee: Seriennummer des Hauptgeräts ohne das erforderliche Recht ändern; die Änderung muss mit + `RightCheckFailed` abgewiesen werden. +Tracelinks: StRS-015, StRS-027, SyRS-055, SwRS-085 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Installierte Basis ist Grundlage von Service und Abrechnung. +Status: belegt +``` + +``` +ID: StRS-027 +Titel: Getrennte Datenhaltung für Drucker (Stammblätter) und sonstige Hardware (Assets) +Ebene: StRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Servicetechniker, Administrator +Vorbedingung: Beim Kunden ist Hardware installiert. +Fakt: Neben `MasterDataListClass = 25` existiert eine eigene Objektfamilie + `AssetManagement*` (`AssetManagementDeviceClass = 5101330`, + `AssetManagementSNMPDevices = 7600000`, `AssetManagementSQLServer = 7600002` u. a.) mit + eigenen Tabellen (`AssetManagementDocumentation*`, `AssetManagementLogicalDeviceHistory`, + `AssetManagementSNMPOidClasses`, `AssetManagementFolderPermissions`). +Aussage: Das System führt installierte Hardware in zwei getrennten Datenhaltungen — Stammblätter + für abrechnungsrelevante Geräte und Assets für inventarisierte IT-Systeme. +Ergebnis: Dieselbe physische Hardware kann in beiden Strukturen unabhängig voneinander geführt werden. +Belege: + - [PRIMÄR] src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs, `MasterDataListClass = 25` + gegenüber `AssetManagementDeviceClass = 5101330` und den `AssetManagement*`-Werten ab 7600000 + - Begründung: Zwei getrennte Objektartenfamilien für denselben fachlichen Gegenstand. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, Fremdschlüssel `fk_AssetManLogDevHist_AssetManDev`, + `FK_AssetManagementDocumentationGroup_AssetManagementDocumentation`, + `CONSTRAINT [IX_AssetManagementSNMPOidClasses_UniqueI3D]` + - Begründung: Belegt die eigenständige, vom Stammblatt getrennte Datenhaltung. +Prüfidee: Ein Gerät als Stammblatt und als Asset erfassen; es darf keine erzwungene Verknüpfung + zwischen beiden Datensätzen bestehen. +Tracelinks: StRS-026, SwRS-086 +Konsolidierung: Kandidat: StRS-026 - Stammblätter und Assets bilden denselben fachlichen Gegenstand + „installierte Hardware beim Kunden" in zwei getrennten Datenhaltungen ab und sind im + Zielsystem zu einem Asset-Konzept zusammenzuführen. +Übernahmewürdigkeit: Workaround - historisch getrennt gewachsen; im Zielsystem ein gemeinsames Asset-Modell. +Status: belegt +``` + +``` +ID: StRS-028 +Titel: RMA- und Werkstattabwicklung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker, Lagerist +Vorbedingung: Ein Kunde reklamiert ein Gerät. +Fakt: `CentronObjectKindNumeric.RmaArticle = 40` mit `[Description("RMAArtikel")]`; es existieren + die Tabellen `Rma`, `RmaArticle`, `RmaArticleHistory` mit eindeutigen Clustered Indizes; + das Modul `RmoOverviewAppModulController` ist an das Recht `RIGHT_RMAANLEGEN` gebunden; + es existiert die Schnittstelle `IReceiptClosedThroughRMA`. +Aussage: Das System soll Reklamations- und Reparaturvorgänge je Artikel mit Historie führen und + ihre Rückwirkung auf Belege abbilden. +Ergebnis: Zu jedem RMA-Vorgang sind Artikel, Zustandsänderungen und der auslösende Beleg nachvollziehbar. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CREATE UNIQUE CLUSTERED INDEX [CI_RMA_HelpdeskI3D] ON [dbo].[Rma]`, + `[CI_RmaArticle_I3D_RmaI3D]`, `[CI_RmaArticleHistory_I3D_RmaI3D]` + - Begründung: Erzwingt die 1:1-Bindung eines RMA an ein Ticket und die Historienführung je Artikel. + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.RIGHT_RMAANLEGEN), ...)` + - Begründung: Durchsetzende Rechteprüfung für den RMA-Zugang. + - [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/IReceiptClosedThroughRMA.cs + - Begründung: Belegt die Rückwirkung eines RMA auf den Belegabschluss. +Prüfidee: RMA aus einem Ticket anlegen; der eindeutige Index auf `Rma.HelpdeskI3D` muss ein zweites + RMA zu demselben Ticket verhindern. +Tracelinks: StRS-021, SyRS-056, SwRS-087 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Reklamationsabwicklung ist fachlich erforderlich. +Status: belegt +``` + +### 2.5 Einkauf, Lager und Logistik + +``` +ID: StRS-029 +Titel: Elektronischer Belegaustausch mit Distributoren +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Für einen Lieferanten ist eine EDI-Verbindung konfiguriert. +Fakt: Das Modul `EDIManagementController` ist an `RIGHT_EDIMANAGEMENT` und + `LicenseGuids.EDIManagement` gebunden; `Centron.Gateway` enthält die Parserbibliotheken + `EDI_Also`, `EDI_AlsoCH`, `EDI_Alltron`, `EDI_Herweck`, `OpenTrans`; die Tabellen + `EDIInvoiceItemsToOrder` und `EDIOrderResponseItemsToOrder` besitzen eindeutige Indizes; + der Hintergrunddienst `EdiDownloadService` holt Dateien ab. +Aussage: Das System soll Bestellungen elektronisch an Distributoren senden sowie + Auftragsbestätigungen, Lieferavise und Rechnungen automatisch einlesen und den + ursprünglichen Bestellungen zuordnen. +Ergebnis: Eingehende EDI-Belege sind den auslösenden Bestellungen positionsgenau zugeordnet. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CREATE UNIQUE CLUSTERED INDEX [idxInvoiceToOrder] ON [dbo].[EDIInvoiceItemsToOrder]` + und `[idxOrderResponseToOrder] ON [dbo].[EDIOrderResponseItemsToOrder]` + - Begründung: Erzwingt die eindeutige Zuordnung eingehender EDI-Positionen zu Bestellpositionen. + - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/EdiDownloadService.cs + - Begründung: Belegt den automatischen Abholvorgang als laufenden Dienst. + - [KONTEXT] docs/reference/edi/edi-architecture.md, Tabelle „Document Types Supported" + - Begründung: Beschreibt die je Distributor unterstützten Belegarten. +Prüfidee: Auftragsbestätigung eines Distributors einspielen; die Bestellpositionen müssen mit + bestätigten Mengen und Terminen aktualisiert werden. +Tracelinks: StRS-030, SyRS-060, SwRS-090, SwRS-091 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - EDI ist im IT-Distributionsgeschäft Standard. +Status: belegt +``` + +``` +ID: StRS-030 +Titel: Artikelstammdaten aus externen Produktdatenquellen +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Eine Produktdatenquelle ist konfiguriert. +Fakt: Es existieren die Projekte `Centron.APIs.ITscopeDataAccess` (mit `IITscopeApi`) und + `Centron.APIs.IcecatDataAccess` (mit `IIcecatApi`, `Languages.cs`); es existieren das + Modul `ArticleImportAppModuleController` (Recht `DataExchange.ARTICLE_IMPORT`), die + Einstellungsseite `ICEcatSettingsController` und der Hintergrunddienst `ArticleImportService`. +Aussage: Das System soll Artikelstammdaten, Beschreibungen und Bilder aus externen + Produktdatenquellen übernehmen und periodisch aktualisieren. +Ergebnis: Artikel tragen aktuelle Beschreibungen, Bilder und Preise aus der externen Quelle. +Belege: + - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/ArticleImportService.cs und + AutomaticPriceUpdateService.cs + - Begründung: Belegen die periodische Aktualisierung als laufende Dienste. + - [PRIMÄR] src/apis/Centron.APIs.ITscopeDataAccess/IITscopeApi.cs, + src/apis/Centron.APIs.IcecatDataAccess/IIcecatApi.cs + - Begründung: Belegen die konkreten Schnittstellenverträge zu den Quellen. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `FK_ArticleImportDistributors_ArticleImports`, + `FK_ArticleImportLogs_ArticleImports`, `FK_ArticleImportMappings_ArticleImports` + - Begründung: Belegt Konfiguration, Feldzuordnung und Protokollierung des Imports. +Prüfidee: Artikelimport eines Distributors ausführen und prüfen, dass ein `ArticleImportLog`-Eintrag entsteht. +Tracelinks: StRS-029, StRS-031, SyRS-061, SwRS-092 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Externe Produktdaten bleiben erforderlich. +Status: belegt +``` + +``` +ID: StRS-031 +Titel: Artikelstamm mit Warengruppen, Preisen und Beständen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkäufer, Lagerist, Sachbearbeiter Vertrieb +Vorbedingung: Ein Produkt soll handelbar sein. +Fakt: Die Legacy-Tabelle `ARTIK` besitzt den eindeutigen Index `ARTIK0`, die Warengruppentabelle + `WAREN` den Index `WAREN0`; `CentronObjectKindNumeric.Article = 9`; es existieren die + Module `ArticleManagementAppModuleController` und `MaterialGroupAppModuleController`; + der Dienst `UpdateArticleAndMaterialGroupTaxRatesService` pflegt Steuersätze fort. +Aussage: Das System soll Artikel eindeutig identifizieren, sie einer Warengruppe zuordnen und + Preise, Steuersätze und Bestände je Artikel führen. +Ergebnis: Jeder Artikel ist eindeutig, einer Warengruppe zugeordnet und mit gültigem Steuersatz versehen. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CREATE UNIQUE NONCLUSTERED INDEX [ARTIK0] ON [dbo].[ARTIK]` + und `[WAREN0] ON [dbo].[WAREN]` + - Begründung: Erzwingen die Eindeutigkeit von Artikel und Warengruppe. + - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/UpdateArticleAndMaterialGroupTaxRatesService.cs + - Begründung: Belegt die automatische Fortschreibung der Steuersätze auf Artikel- und Warengruppenebene. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CONSTRAINT [IX_HerstellerArtik_I3D0_Unique] UNIQUE NONCLUSTERED` + - Begründung: Belegt die eindeutige Zuordnung von Herstellerartikelnummern. +Prüfidee: Zwei Artikel mit identischer Artikelnummer anlegen; das zweite Speichern muss scheitern. +Tracelinks: StRS-030, StRS-032, SyRS-062, SwRS-093 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Artikelstamm ist ERP-Kern. +Status: belegt +``` + +``` +ID: StRS-032 +Titel: Mehrlagerfähigkeit mit kontrollierten Umbuchungen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lagerist +Vorbedingung: Es existieren mehrere Läger, Lagerorte und Lagerbereiche. +Fakt: `SecondStockArticleBL.RebookStockArticle` nimmt Quell- und Ziellager, -ort und -bereich + entgegen, prüft das Recht `UserRightsConst.Purchase.StockList.TRANSFER_STOCK` und lehnt + ohne dieses Recht mit „Fehlende Rechte um Lagerbuchungen durchzuführen." ab. +Aussage: Das System soll Bestände je Lager, Lagerort und Lagerbereich führen und Umbuchungen + zwischen ihnen nur berechtigten Anwendern erlauben. +Ergebnis: Eine Umbuchung verringert den Quellbestand und erhöht den Zielbestand um dieselbe Menge. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Warehousing/SecondStockArticleBL.cs, `RebookStockArticle`, + `if (checkRightsResult.Contains(UserRightsConst.Purchase.StockList.TRANSFER_STOCK) == false) return Result.AsError("Fehlende Rechte um Lagerbuchungen durchzuführen.", DefaultMessageCodes.RightCheckFailed);` + - Begründung: Die durchsetzende Rechteprüfung unmittelbar vor der Buchung. + - [PRIMÄR] Ebenda, Vorabprüfungen `if (articleI3D == 0) return Result.AsError("Invalid article i3d(0)");`, + `if (sourceStoreI3D <= 0 && sourceStoreI3D != -1) ...`, `if (amount == 0) return Result.AsWarning("Amount is 0. Do nothing");` + - Begründung: Belegen die Eingangsvalidierung der Umbuchung inklusive des Sonderwerts -1 für das Hauptlager. +Prüfidee: Umbuchung ohne `TRANSFER_STOCK` versuchen; sie muss mit `RightCheckFailed` scheitern. +Tracelinks: StRS-031, StRS-033, SyRS-063, SwRS-094 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Mehrlagerfähigkeit und Buchungsberechtigung bleiben nötig. +Status: belegt +``` + +``` +ID: StRS-033 +Titel: Inventur mit definierten Zuständen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lagerist +Vorbedingung: Eine Bestandsaufnahme soll durchgeführt werden. +Fakt: `InventoryState` definiert die Zustände `Open = 0`, `Deleted = 1`, `Closed = 2`, + `OpenWithoutBC = 3`, `ClosedWithoutBC = 4`; das Modul `InventoryAppModuleController` ist + an `UserRightsConst.Purchase.Inventory.ID` gebunden. +Aussage: Das System soll Inventuren als Vorgänge mit definiertem Lebenszyklus führen und dabei + zwischen barcodegestützter und barcodeloser Erfassung unterscheiden. +Ergebnis: Eine abgeschlossene Inventur ist unveränderlich und wirkt auf die Bestände. +Belege: + - [PRIMÄR] src/webservice/Centron.WebServices.Core/Entities/Warehousing/InventoryManagement/InventoryState.cs + - Begründung: Definiert den Zustandsraum abschließend und mit festen numerischen Werten. + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.Purchase.ID, UserRightsConst.Purchase.Inventory.ID), ...)` + - Begründung: Durchsetzende Rechteprüfung für den Inventurzugang. +Prüfidee: Inventur abschließen und anschließend eine Zählposition ändern wollen; die Änderung muss + abgewiesen werden. +Tracelinks: StRS-032, SyRS-064, SwRS-095 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Inventur ist handelsrechtlich vorgeschrieben. +Status: belegt +``` + +``` +ID: StRS-034 +Titel: Kommissionierung und Versandabwicklung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lagerist +Vorbedingung: Ein Auftrag ist zur Auslieferung freigegeben. +Fakt: Das Modul `OrderCommissionAppModuleController` ist an `UserRightsConst.Logistic.Commissioning.ID` + und `LicenseGuids.Commissioning` gebunden; es existieren die Versandanbindungen + `Centron.Api.Gls` und `Centron.Api.Shipcloud` mit den Einstellungsseiten + `GlsSettingController`, `ShipcloudSettingController` und `ShippingMethodSettingsController` + sowie der Controller `ShipcloudPackageTemplatesController`. +Aussage: Das System soll Aufträge kommissionieren, Versandarten je Sendung festlegen und + Versandaufträge an externe Dienstleister übergeben. +Ergebnis: Zu einer Sendung liegen Versanddienstleister, Paketdaten und Sendungsverfolgung vor. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.Logistic.ID, UserRightsConst.Logistic.Commissioning.ID), ...)` + - Begründung: Durchsetzende Rechteprüfung der Kommissionierung. + - [PRIMÄR] src/webservice/Centron.Controllers/Controllers/v1/Receipts/ShipcloudPackageTemplatesController.cs + - Begründung: Belegt die API-seitige Verwaltung von Paketvorlagen. + - [PRIMÄR] src/apis/Centron.Api.Gls/CentronGlsLogic.cs, src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs + - Begründung: Belegen die konkreten Anbindungen an zwei Versanddienstleister. +Prüfidee: Lieferschein über Shipcloud versenden; es muss eine Sendungsnummer zurückgeschrieben werden. +Tracelinks: StRS-033, SyRS-065, SwRS-096 +Konsolidierung: Kandidat: StRS-034 - GLS und Shipcloud bilden dieselbe fachliche Funktion + „Versandauftrag erzeugen" in zwei getrennten Implementierungen ab; im Zielsystem ist eine + einheitliche Versandabstraktion vorzusehen. +Übernahmewürdigkeit: übernehmen - Versandabwicklung bleibt erforderlich. +Status: belegt +``` + +``` +ID: StRS-035 +Titel: Bestellvorschläge aus Bedarf und Bestand +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Es bestehen offene Bedarfe und definierte Meldebestände. +Fakt: Das Modul `OrderSuggestionListAppModuleController` ist an das Recht + `UserRightsConst.Purchase.SHOW_ORDER_SUGGESTION_LIST` und die Lizenz + `LicenseGuids.OrderSuggestionList` gebunden und mit `#pragma warning disable 612 //Obsolete` umschlossen. +Aussage: Das System soll aus offenen Bedarfen und Beständen Bestellvorschläge ermitteln und + dem Einkäufer zur Freigabe vorlegen. +Ergebnis: Der Einkäufer erhält je Lieferant eine Vorschlagsliste, aus der Bestellungen entstehen können. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.Purchase.SHOW_ORDER_SUGGESTION_LIST), ...)` + - Begründung: Durchsetzende Rechteprüfung. + - [KONTEXT] Ebenda, umschließendes `#pragma warning disable 612 //Obsolete` + - Begründung: Zeigt, dass der zugrunde liegende Typ als veraltet markiert ist. +Prüfidee: Artikel unter Meldebestand mit offenem Auftrag anlegen; der Artikel muss im + Bestellvorschlag erscheinen. +Tracelinks: StRS-031, SyRS-066, SwRS-097 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - Der Modultyp ist im Code als obsolet markiert; die Funktion ist im + Zielsystem neu zu konzipieren. +Status: belegt +``` + +``` +ID: StRS-036 +Titel: Wareneingang mit Einkaufskalkulation +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Eine Lieferantenlieferung trifft ein. +Fakt: Das Modul `SupplierReceiptDocumentsImportAppModuleController` („Eingang/Kalk") ist an + das Recht `UserRightsConst.RIGHT_KALKULATIONERSTELLEN` und die Lizenz + `LicenseGuids.IncomingCalculation` gebunden; es existieren die Einstellungsseiten + `SupplierInvoiceSettingsController`, `SupplierDeliveryListSettingsController`, + `SupplierOrderSettingsController` und `SupplierCreditVoucherSettingsController`. +Aussage: Das System soll Lieferantenbelege erfassen, daraus Einstandspreise kalkulieren und die + Bestände fortschreiben. +Ergebnis: Nach dem Wareneingang liegen aktualisierte Bestände und kalkulierte Einstandspreise vor. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.RIGHT_KALKULATIONERSTELLEN), ...)` + - Begründung: Durchsetzende Rechteprüfung des Kalkulationszugangs. + - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Purchasing/PurchaseSettings/ReceiptSettings/ (vier Belegarten) + - Begründung: Belegen die vier eigenständigen Lieferantenbelegarten. +Prüfidee: Wareneingang mit Fracht- und Nebenkosten erfassen; der kalkulierte Einstandspreis muss + diese Kosten enthalten. +Tracelinks: StRS-029, StRS-031, SyRS-067, SwRS-098 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Einstandspreiskalkulation ist für die Margenrechnung notwendig. +Status: belegt +``` + +### 2.6 Sicherheit, Rechte und Datenschutz + +``` +ID: StRS-037 +Titel: Feingranulare Rechteverwaltung als Grundlage der Zugriffskontrolle +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Benutzer sollen unterschiedliche Befugnisse erhalten. +Fakt: `UserRightsConst.cs` umfasst 2.819 Zeilen numerischer Rechtekonstanten in hierarchischen + Namensräumen (`Sales.Customer.Helpdesk.*`, `Purchase.StockList.*`, `Administration.*` …); + `AppRightsBL.CheckRightsFromUser(userI3D, rightIds)` liefert die tatsächlich vorhandenen Rechte. +Aussage: Das System soll Befugnisse als einzeln vergebbare, hierarchisch gruppierte Rechte + führen und jede geschützte Aktion gegen ein konkretes Recht prüfen. +Ergebnis: Ein Anwender kann genau die Aktionen ausführen, für die ihm ein Recht zugewiesen wurde. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs, `ValidateUserRights(int appUserI3D, ...)` + mit `new AppRightsBL(Session).CheckRightsFromUser(appUserI3D, new List { CREATE_CUSTOMER, EDIT_CUSTOMER, DELETE_CUSTOMER, SEARCH_CUSTOMER, UNLOCK_CUSTOMER, RIGHT_LIEFERANTANLEGEN, RIGHT_LIEFERANTAENDERN })` + und den nachfolgenden `if (!checkRightsResult.Contains(...)) return Result.AsError(...)`-Prüfungen + - Begründung: Vollständiges Beispiel der durchsetzenden Rechteprüfung für alle CRUD-Operationen am Adressstamm. + - [PRIMÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs (2.819 Zeilen) + - Begründung: Belegt Umfang und Struktur des Rechtemodells. + - [KONTEXT] docs/guides/development/check-userrights.md + - Begründung: Beschreibt die drei vorgesehenen Prüfwege (ViewModel, Modul, BL). +Prüfidee: Benutzer ohne `CREATE_CUSTOMER` anlegen und einen Kunden anlegen lassen; es muss + „Fehlende Rechte um Accounts zu erstellen" mit `RightCheckFailed` zurückkommen. +Tracelinks: StRS-038, StRS-039, SyRS-070, SyRS-071, SwRS-100 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Feingranulare Rechte sind fachlich notwendig; die numerischen + Konstanten sollten im Zielsystem durch sprechende Bezeichner ersetzt werden. +Status: belegt +``` + +``` +ID: StRS-038 +Titel: Rechteprüfung an mehreren Schichten +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator, Externes System +Vorbedingung: Eine geschützte Funktion wird über Client, API oder Portal aufgerufen. +Fakt: Rechte werden an drei Stellen geprüft: im Client über + `CentronCache.Instance.CurrentUserAppRights` und `ModuleRegistration`, in der API über + `AuthorizeUserRightAttribute`/`AuthorizeAnyUserRightAttribute`/`AuthorizeAllUserRightsAttribute` + und im Backend über `AppRightsBL.CheckRightsFromUser`. +Aussage: Das System soll Rechte unabhängig vom Zugangsweg im Backend durchsetzen und die + Prüfungen in Client und API nur als zusätzliche, vorgelagerte Kontrollen betreiben. +Ergebnis: Ein direkter API-Aufruf unter Umgehung des Clients wird ebenso abgewiesen wie der Aufruf über den Client. +Belege: + - [PRIMÄR] src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs, + `UserRightAuthorizationFilter.OnAuthorization`: `if (currentUser == null) { context.Result = new UnauthorizedResult(); return; }` + und `if (!_requiredRightId.HasValue || !currentUser.HasUserRight(_requiredRightId.Value)) context.Result = new ForbidResult();` + - Begründung: Die durchsetzende Stelle der API-seitigen Rechteprüfung inklusive der HTTP-Statusabbildung. + - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs, `ValidateUserRights` (Backend-seitige Prüfung) + - Begründung: Belegt die vom Zugangsweg unabhängige Durchsetzung. + - [KONTEXT] src/webservice/Centron.Controllers/Authorization/README.md, Abschnitt + „When to Use WebServiceBL Rights Checks" + - Begründung: Beschreibt die bewusste Aufteilung zwischen Attribut- und BL-Prüfung. +Prüfidee: Geschützten Endpunkt ohne Recht direkt per HTTP aufrufen; die Antwort muss 403 sein. +Tracelinks: StRS-037, SyRS-071, SwRS-101 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Serverseitige Durchsetzung ist zwingend. +Status: belegt +``` + +``` +ID: StRS-039 +Titel: Mehrere Anmeldeverfahren einschließlich Verzeichnisdienst und OpenID Connect +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator, Sachbearbeiter +Vorbedingung: Für die Installation ist ein Systemanmeldeverfahren konfiguriert. +Fakt: `AuthenticatorFactory` wählt anhand von `SystemAuthenticationMethod` + (`None | Basic | ActiveDirectory | OpenIdConnect`) und der `AuthentificationKind` des + Benutzers zwischen `BasicAuthenticator`, `ActiveDirectoryAuthenticator`, + `OpenIdConnectAuthenticator` und `WebAccountAuthenticator`; OpenID Connect setzt + zusätzlich `LicenseGuids.OpenIDConnectAuthentication` und aktivierte JWT-Einstellungen voraus. +Aussage: Das System soll Anmeldungen wahlweise gegen die eigene Benutzerverwaltung, einen + Verzeichnisdienst oder einen OpenID-Connect-Anbieter prüfen und dabei je Benutzer das + hinterlegte Verfahren berücksichtigen. +Ergebnis: Ein Benutzer meldet sich über das für ihn vorgesehene Verfahren an; nicht konfigurierte + Verfahren werden mit einer eindeutigen Fehlermeldung abgewiesen. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs, + `GetFromBasicAuth(...) => method switch { SystemAuthenticationMethod.None => ..., Basic => new BasicAuthenticator(...), ActiveDirectory => TryCreateActiveDirectory(...) }` + - Begründung: Die durchsetzende Auswahl des Anmeldeverfahrens. + - [PRIMÄR] Ebenda, `GetFromOpenIdConnectAuth`: + `if (licenseManager.HasLicense(LicenseGuids.OpenIDConnectAuthentication) == false) return Result.AsError("No license for OpenIDConnectAuthentication");` + und `TryCreateOpenIdConnect(...) => JwtEnabled ? new OpenIdConnectAuthenticator(...) : Result.AsError("JWT authentication is not enabled");` + - Begründung: Die durchsetzende Lizenz- und Konfigurationsbedingung für OIDC. + - [KONTEXT] docs/reference/security/anmelden-mit-microsoft-technische-anleitung.md + - Begründung: Beschreibt die Einrichtung der Microsoft-Anmeldung. +Prüfidee: OIDC-Anmeldung ohne die Lizenz versuchen; die Antwort muss „No license for + OpenIDConnectAuthentication" lauten. +Tracelinks: StRS-040, SyRS-072, SyRS-073, SwRS-102 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Verzeichnis- und Identitätsanbindung ist in Unternehmen Standard. +Status: belegt +``` + +``` +ID: StRS-040 +Titel: Zwei-Faktor-Authentifizierung +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator, Sachbearbeiter, Endkunde +Vorbedingung: Für den Benutzer oder Web-Account ist Zwei-Faktor-Authentifizierung aktiviert. +Fakt: `BasicAuthenticator.AuthenticateInternal` ruft nach erfolgreicher Kennwortprüfung + `_twoFactorAuthBL.ValidateTwoFactor(...)` auf und gibt bei Misserfolg + `DefaultMessageCodes.TwoFactorAuthFailed` zurück; + `TwoFactorAuthenticationBL.ValidateAuthenticationPin` prüft die PIN über + `Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin`. +Aussage: Das System soll die Anmeldung optional durch einen zweiten Faktor absichern und die + Anmeldung ohne gültigen zweiten Faktor ablehnen. +Ergebnis: Ohne gültige PIN erhält der Anwender kein Verbindungsticket. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, + `var twoFactorResult = _twoFactorAuthBL.ValidateTwoFactor(...); if (twoFactorResult.Status == ResultStatus.Success) return validatedUserResult;` + mit anschließendem Fehler `DefaultMessageCodes.TwoFactorAuthFailed` + - Begründung: Die durchsetzende Stelle: ohne erfolgreiche 2FA wird kein `LoggedInUser` zurückgegeben. + - [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, + `ValidateAuthenticationPin`: `return Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin(appUserTwoFactorAuthKeyResult.Data, authenticationPin) ? Result.AsSuccess() : Result.AsError("Die eingegebene PIN ist ungültig!");` + - Begründung: Die konkrete Prüfung des zeitbasierten Einmalkennworts. + - [PRIMÄR] src/shared/Centron.Core/TotpAuth/InMemoryKey.cs, `hmacAlgorithm = new HMACSHA256();` + - Begründung: Belegt das eingesetzte TOTP-Verfahren. + - [SEKUNDÄR] src/webservice/Centron.Controllers/Controllers/Unversioned/TwoFactorAuthController.cs + - Begründung: Belegt den API-Endpunkt für den zweiten Faktor. +Prüfidee: Benutzer mit hinterlegtem 2FA-Schlüssel mit falscher PIN anmelden; die Anmeldung muss mit + `TwoFactorAuthFailed` scheitern. +Tracelinks: StRS-039, SyRS-074, SwRS-103 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Zweiter Faktor ist im SaaS-Betrieb Mindeststandard. +Status: belegt +``` + +``` +ID: StRS-041 +Titel: Zeitlich steuerbare Deaktivierung von Benutzerkonten +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Ein Mitarbeiter scheidet aus oder ist längere Zeit abwesend. +Fakt: `Authenticator.ValidateAppUser` prüft `user.IsAccountDisabled` sowie die Zeiträume + `AccountDisabledFromDate`/`AccountDisabledToDate` und zusätzlich über + `EmployeeBL.IsActiveEmployeeCompact` die Beschäftigungsdaten (Einstellungs-/Austrittstermin); + bei jedem Treffer wird `DefaultMessageCodes.EmployeeAccountDeactivated` zurückgegeben. +Aussage: Das System soll Benutzerkonten sowohl dauerhaft als auch für einen definierten Zeitraum + sperren können und die Sperre zusätzlich aus den Beschäftigungsdaten des Mitarbeiters ableiten. +Ergebnis: Ein gesperrter oder ausgeschiedener Mitarbeiter kann sich nicht anmelden. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, `ValidateAppUser`, + Prüfungen `var deactivated = user.IsAccountDisabled;`, + `if (fromHasValue && DateTime.Today >= user.AccountDisabledFromDate && (!toHasValue || DateTime.Today <= user.AccountDisabledToDate)) deactivated = true;` + und `var validationResult = _employeeBl.IsActiveEmployeeCompact(user.Employee);` + - Begründung: Die drei durchsetzenden Sperrbedingungen an einer Stelle. + - [SEKUNDÄR] Ebenda, Protokolltexte „is deactivated through the checkbox 'User hat Account in c-entron'", + „... through the date 'Konto deaktiviert von'", „... through the dates 'Einstellungstermin' und 'Austrittstermin'" + - Begründung: Benennen die drei fachlichen Sperrquellen aus Anwendersicht. +Prüfidee: `AccountDisabledFromDate` auf gestern setzen und Anmeldung versuchen; sie muss mit + `EmployeeAccountDeactivated` scheitern. +Tracelinks: StRS-039, SyRS-075, SwRS-104 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Konten-Lebenszyklus ist Compliance-Anforderung. +Status: belegt +``` + +``` +ID: StRS-042 +Titel: Verschlüsselte Ablage von Kundenzugangsdaten +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Servicetechniker, Administrator +Vorbedingung: Für einen Kunden sind Zugangsdaten zu dokumentieren. +Fakt: `PasswordManagerBL` legt Kennworteigenschaften als + `CustomizationDataTypes.EncryptedText` an und verschlüsselt bzw. entschlüsselt sie über + `new AESCryptoLogic().EncryptText(value, masterKey)` bzw. `.DecryptText(...)` mit einem + über `masterKeyResult` bezogenen Schlüssel; der Zugriff auf Richtlinien ist an ein Recht gebunden. +Aussage: Das System soll Kundenzugangsdaten ausschließlich verschlüsselt speichern und nur + berechtigten Anwendern im Klartext zugänglich machen. +Ergebnis: In der Datenbank liegt kein Klartextkennwort; die Entschlüsselung erfordert den Hauptschlüssel. +Belege: + - [PRIMÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Zeile 700: + `CreatePropertyValue("Passwort", propertyValue => propertyValue.ValueEncryptedString = new AESCryptoLogic().EncryptText(customerHotline.Password, masterKeyResult.Data))` + - Begründung: Die durchsetzende Verschlüsselung beim Schreiben. + - [PRIMÄR] Ebenda, Zeilen 1052 und 1179: + `customPropertyData.EncryptedString = new AESCryptoLogic().DecryptText(propertyValue?.ValueEncryptedString, masterKey);` + - Begründung: Die durchsetzende Entschlüsselung beim Lesen, gebunden an den Hauptschlüssel. + - [PRIMÄR] Ebenda, Zeilen 231, 249, 269: + `return Result<...>.AsError("Fehlende Rechte um die Passwort Manager Richtlinien zu verwalten!");` + - Begründung: Die durchsetzende Rechteprüfung für die Richtlinienverwaltung. +Prüfidee: Kennwort speichern und den Rohwert in der Datenbank prüfen; er darf nicht dem Klartext entsprechen. +Tracelinks: StRS-043, SyRS-076, SwRS-105 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Verschlüsselte Geheimnisablage ist zwingend; das Schlüsselmanagement + ist im Zielsystem auf einen Schlüsseldienst umzustellen. +Status: belegt +``` + +``` +ID: StRS-043 +Titel: Passwortrichtlinien für verwaltete Zugänge +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Der Passwort-Manager ist lizenziert. +Fakt: Es existieren die Entität `PasswordManagerGuideline`, die Tabelle + `PasswordManagerGuidelineCategories` mit eindeutigem Clustered Index sowie das Modul + `GuidelineManagementAppModuleController` mit dem Recht + `UserRightsConst.PasswordManager.ACCESS_GUIDELINE_MANAGEMENT`. +Aussage: Das System soll Vorgaben für Aufbau und Gültigkeit verwalteter Kennwörter als + Richtlinien hinterlegen und diese kategorisieren. +Ergebnis: Ein verwaltetes Kennwort lässt sich gegen die zugeordnete Richtlinie prüfen. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CREATE UNIQUE CLUSTERED INDEX [CI_PasswordManagerGuidelineCategories] ON [dbo].[PasswordManagerGuidelineCategories]` + - Begründung: Belegt die persistierte, eindeutige Kategorisierung von Richtlinien. + - [PRIMÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Methoden mit Rückgabetyp + `Result` und vorgeschalteter Rechteprüfung (Zeilen 231, 249, 269) + - Begründung: Belegt Existenz und Zugangsschutz der Richtlinienverwaltung. +Prüfidee: Richtlinie mit Mindestlänge 12 hinterlegen und ein achtstelliges Kennwort speichern; die + Richtlinienverletzung muss erkennbar sein. +Tracelinks: StRS-042, SyRS-077, SwRS-106 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kennwortrichtlinien bleiben fachlich sinnvoll. +Status: belegt +``` + +``` +ID: StRS-044 +Titel: Auftragsverarbeitungsverträge und Datenschutzdokumentation +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator, Endkunde +Vorbedingung: Für einen Kunden ist ein Auftragsverarbeitungsvertrag zu schließen. +Fakt: Es existieren die Entitäten `AccountOrderProcessingContract`, `OrderProcessingContractTemplate` + und `OnlinePdfDocument`, der Zustandstyp `OrderProcessingContractState`, der Handler + `OrderProcessingContractOnlinePdfDocumentHandler` sowie das Modul + `CentronDataSecurityAppModuleController` mit dem Recht `DsgvoModule.ACCESS_DSGVO_MODULE`. +Aussage: Das System soll Auftragsverarbeitungsverträge aus Vorlagen erzeugen, ihren Status + nachhalten und sie dem Kunden als Online-Dokument zur Zustimmung bereitstellen. +Ergebnis: Zu jedem Kunden ist der Stand des Auftragsverarbeitungsvertrags nachvollziehbar. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `FK_AccountOrderProcessingContracts_Documents FOREIGN KEY([DocumentI3D])` + - Begründung: Erzwingt die Verknüpfung des Vertrags mit einem gespeicherten Dokument. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CONSTRAINT [CI_OnlinePdfDocuments] UNIQUE CLUSTERED` + - Begründung: Belegt die eindeutige Identifikation der online bereitgestellten PDF-Dokumente. + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.DsgvoModule.ACCESS_DSGVO_MODULE), ...)` + - Begründung: Durchsetzende Rechteprüfung des Datenschutzmoduls. +Prüfidee: Auftragsverarbeitungsvertrag aus Vorlage erzeugen und online zustimmen lassen; der Status + muss von „offen" auf „zugestimmt" wechseln. +Tracelinks: StRS-045, SyRS-078, SwRS-107 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - DSGVO-Nachweise sind gesetzlich gefordert. +Status: belegt +``` + +``` +ID: StRS-045 +Titel: Löschbarkeit personenbezogener Daten +Ebene: StRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Ein Betroffener verlangt Löschung. +Fakt: Es existiert das Attribut `IsDsgvoSetNullAttribute` unter + `src/backend/Centron.Entities/Entities/DbEntities/`. +Aussage: Das System soll personenbezogene Felder kennzeichnen, die bei einem Löschverlangen auf + NULL gesetzt werden, ohne den fachlichen Datensatz zu zerstören. +Ergebnis: Nach der Löschung sind die gekennzeichneten Felder leer, Belegzusammenhänge bleiben erhalten. +Belege: + - [PRIMÄR] src/backend/Centron.Entities/Entities/DbEntities/IsDsgvoSetNullAttribute.cs + - Begründung: Das Attribut ist der deklarative Mechanismus, über den die Felder markiert werden. + - [SEKUNDÄR] src/backend/Centron.BL/Administration/DataSecurity/ + - Begründung: Belegt die zugehörige Verarbeitungslogik. +Prüfidee: Löschung eines Kontakts anstoßen und prüfen, dass alle mit `IsDsgvoSetNull` markierten + Felder NULL sind, der Beleg aber weiterhin existiert. +Tracelinks: StRS-044, SyRS-079, SwRS-108 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Löschkonzept ist gesetzlich gefordert. [HYPOTHESE-Anteil: Der genaue + Umfang der markierten Felder wurde nicht ausgewertet, siehe SwRS-108.] +Status: belegt +``` + +### 2.7 Auswertung, Steuerung und Automatisierung + +``` +ID: StRS-046 +Titel: Betriebswirtschaftliche Auswertungen für die Geschäftsführung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Geschäftsführung, Controller +Vorbedingung: Belege und Zeiten sind erfasst. +Fakt: Es existieren die Module `ManagementInfoAppModuleController`, + `SaleStatisticsAppModuleController`, `ContractEvaluation2AppModuleController`, + `EmployeeAnalyticsAppModuleController` und `MyDayEmployeeOverviewAppModuleController`, + jeweils an eigene Rechte und Lizenzen gebunden. +Aussage: Das System soll Umsatz, Marge, Vertragswirtschaftlichkeit und Mitarbeiterauslastung + auswerten und den Zugriff darauf je Auswertungsart getrennt berechtigen. +Ergebnis: Berechtigte Anwender erhalten verdichtete Kennzahlen zu Vertrieb, Verträgen und Personal. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.Controlling.ID, UserRightsConst.Controlling.Finances.ID, UserRightsConst.Controlling.Finances.MANAGEMENT_INFO), ...)` + - Begründung: Durchsetzende Rechteprüfung der höchsten Auswertungsstufe. + - [PRIMÄR] src/webservice/Centron.Controllers/Controllers/v1/Nexoware/Statistics/NexowareStatisticsController.cs, Zeile 45: + `[AuthorizeUserRight(UserRightsConst.Controlling.Analytics.SALES_STATISTIC)]` + - Begründung: Belegt die API-seitige Durchsetzung derselben Auswertungsrechte. + - [SEKUNDÄR] src/backend/Centron.BL/Statistics/ (Accounts, ContractStatistics, MspStatistics, OrderStatistics, SaleStatistics) + - Begründung: Belegen die fachliche Gliederung der Auswertungen. +Prüfidee: Endpunkt `NexowareStatisticsController` ohne `SALES_STATISTIC` aufrufen; die Antwort muss 403 sein. +Tracelinks: StRS-047, SyRS-080, SwRS-110 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Steuerungskennzahlen bleiben erforderlich. +Status: belegt +``` + +``` +ID: StRS-047 +Titel: Managed-Service-Auswertung (MSP) +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Controller, Geschäftsführung +Vorbedingung: Ein MSP-Fremdsystem liefert Nutzungsdaten. +Fakt: Es existieren die drei Module `MspCollectorAppModuleController` + (`ACCESS_MSP_COLLECTOR_MODUEL`), `MSPComparerAppModuleController` + (`ACCESS_MSP_COLLECTOR_COMPARARER_MODUEL`) und `MspDashboardAppModuleController`, + alle an `LicenseGuids.MspModule` gebunden; ferner die Einstellungsseite + `MspEvaluationSettingsController` und der Controller `RmmController`. +Aussage: Das System soll Nutzungsdaten aus Fremdüberwachungssystemen einsammeln, gegen die + vertraglich vereinbarten Mengen abgleichen und Abweichungen ausweisen. +Ergebnis: Abweichungen zwischen gemeldeter Nutzung und Vertragsmenge sind sichtbar und abrechenbar. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierungen der drei + MSP-Module mit `LicenseManager.Instance.HasLicense(LicenseGuids.MspModule)` (ohne + `LicenseGuids.Centron`-Alternative) + - Begründung: Belegt, dass MSP ausschließlich mit gesonderter Lizenz verfügbar ist. + - [PRIMÄR] src/webservice/Centron.Controllers/Controllers/v1/Integrations/RmmController.cs + - Begründung: Belegt den API-Zugang für Fremdüberwachungssysteme. + - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs, + `CreateSpecialArticleToContractFromMspEvaluation(MspEvaluationCompensationItemDTO compensationItemDto, AppUser currentUser)` + - Begründung: Die durchsetzende Stelle, an der MSP-Abweichungen in abrechenbare Vertragspositionen überführt werden. +Prüfidee: MSP-Auswertung mit 12 gemeldeten und 10 vertraglich vereinbarten Lizenzen erzeugen; es + müssen 2 Lizenzen als Nachberechnung entstehen. +Tracelinks: StRS-012, StRS-046, SyRS-081, SwRS-111 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - MSP-Abgleich ist Kern des Managed-Service-Geschäfts. +Status: belegt +``` + +``` +ID: StRS-048 +Titel: Zeitgesteuerte Hintergrundverarbeitung ohne Benutzerinteraktion +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Betreiber +Vorbedingung: Der Web-Service läuft. +Fakt: Unter `src/webservice/Centron.Host/AspNetCore/HostedServices/` liegen 37 Dienste, unter + anderem `EdiDownloadService`, `EscalationsService`, `DataQualityService`, + `ContractEndeService`, `ContractCloseService`, `MassUpdateService`, + `TelemetryUploadService`, `ExchangeSyncService`. +Aussage: Das System soll fachliche und technische Routineaufgaben zeitgesteuert im Hintergrund + ausführen, ohne dass ein Anwender angemeldet sein muss. +Ergebnis: Fristen, Importe, Eskalationen und Datenpflege laufen unabhängig von Benutzersitzungen. +Belege: + - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/ (37 `*Service.cs`-Dateien, + darunter `ManagedBackgroundService.cs` als gemeinsame Basis) + - Begründung: Die Dienste sind als ASP.NET-Core-`BackgroundService` registriert und laufen tatsächlich. + - [KONTEXT] docs/Background Service/DataQualityService.md, Abschnitt „Execution Pattern": + „Tasks are executed with 1-hour intervals between full cycle executions" + - Begründung: Beschreibt das Ausführungsmuster exemplarisch. +Prüfidee: Web-Service starten und im Protokoll die Startmeldungen der Hintergrunddienste nachweisen. +Tracelinks: StRS-025, StRS-029, SyRS-082, SyRS-083, SwRS-112 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Hintergrundverarbeitung bleibt erforderlich; im SaaS-Zielbild sind die + Dienste als eigenständig skalierbare Jobs zu führen. +Status: belegt +``` + +``` +ID: StRS-049 +Titel: Massenänderung von Datenbeständen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Eine Vielzahl gleichartiger Datensätze soll geändert werden. +Fakt: Das Modul `MassUpdatesAppModuleController` ist an das Recht + `UserRightsConst.DataUpdater.ACCESS_DATAUPDATER_MODULE` und die Lizenz + `LicenseGuids.DataUpdaterV2` gebunden; es existieren `MassUpdateBL` und der + Hintergrunddienst `MassUpdateService`. +Aussage: Das System soll regelbasierte Massenänderungen definieren, im Hintergrund ausführen und + den Zugang darauf gesondert berechtigen. +Ergebnis: Eine definierte Massenänderung wird auf alle passenden Datensätze angewendet. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.DataUpdater.ACCESS_DATAUPDATER_MODULE), ...)` + - Begründung: Durchsetzende Rechteprüfung für ein besonders eingriffsintensives Werkzeug. + - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/MassUpdateService.cs + - Begründung: Belegt die asynchrone Ausführung im Hintergrund. + - [SEKUNDÄR] Lizenzname `LicenseGuids.DataUpdaterV2` + - Begründung: Deutet auf eine abgelöste Vorgängerversion hin. +Prüfidee: Massenänderung ohne `ACCESS_DATAUPDATER_MODULE` aufrufen; das Modul darf nicht sichtbar sein. +Tracelinks: StRS-048, SyRS-084, SwRS-113 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Massenpflege ist bei Datenmigrationen und Preisänderungen nötig. +Status: belegt +``` + +``` +ID: StRS-050 +Titel: Reportverwaltung und zeitgesteuerter Reportversand +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Controller, Administrator +Vorbedingung: Ein Report ist definiert. +Fakt: Es existieren das Modul `ReportEngineAppModuleController` (Recht + `Administration.REPORT_MANAGEMENT`) und `ReportServerAppModuleController` (Recht + `Administration.REPORTSERVER`, Lizenz `LicenseGuids.TaskManagementReportServer` oder + `LicenseGuids.ProjectManagement`); die Tabelle `ReportFolderStructure` besitzt die + Constraint `IX_ReportFolderStructure UNIQUE NONCLUSTERED`. +Aussage: Das System soll Reports in einer Ordnerstruktur verwalten und sie zeitgesteuert + ausführen und verteilen können. +Ergebnis: Ein terminierter Report wird zum vorgesehenen Zeitpunkt erzeugt und zugestellt. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CONSTRAINT [IX_ReportFolderStructure] UNIQUE NONCLUSTERED` + - Begründung: Erzwingt die Eindeutigkeit innerhalb der Reportablage. + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierungen von + `ReportEngineAppModuleController` und `ReportServerAppModuleController` + - Begründung: Belegen die getrennte Berechtigung von Verwaltung und Serverbetrieb. + - [SEKUNDÄR] src/backend/Centron.BL/ReportEngine/ (FastReportHelper.cs, PdfExport, PdfStategy, ReplacementBLs) + - Begründung: Belegt die eingesetzte Reporttechnik und die PDF-Erzeugung. +Prüfidee: Report für täglich 06:00 Uhr terminieren; am Folgetag muss die erzeugte Datei vorliegen. +Tracelinks: StRS-046, SyRS-085, SwRS-114 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Berichtswesen bleibt erforderlich. +Status: belegt +``` + +### 2.8 Kommunikation und Zusammenarbeit + +``` +ID: StRS-051 +Titel: Mail- und Kalendersynchronisation mit Microsoft Exchange +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Sachbearbeiter Vertrieb, Servicetechniker +Vorbedingung: Ein Exchange-Postfach ist konfiguriert. +Fakt: Es existieren der Hintergrunddienst `ExchangeSyncService`, die Einstellungsseiten + `MailAndCalenderGeneralSettingsAppModueController`, `CalendarSynchronizationSettingsController`, + `CalendarRepresentationsSettingsController` und `MailTrackingSettingsController` + sowie die Lizenz `LicenseGuids.GraphCalendarEventsAndCallsSync`. +Aussage: Das System soll Termine, Aufgaben und E-Mails mit Microsoft Exchange abgleichen und den + Abgleich je Benutzer konfigurierbar halten. +Ergebnis: Im System angelegte Termine erscheinen im Exchange-Kalender und umgekehrt. +Belege: + - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/ExchangeSyncService.cs + - Begründung: Belegt den tatsächlich laufenden Synchronisationsdienst. + - [PRIMÄR] src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs, + `GraphCalendarEventsAndCallsSync` + - Begründung: Belegt die eigenständige Lizenzierung der Graph-basierten Synchronisation. + - [KONTEXT] docs/features/exchange-sync-bugprotokoll.md + - Begründung: Dokumentiert bekannte Fehlerbilder der Synchronisation. +Prüfidee: Termin im System anlegen und nach einem Synchronisationslauf im Exchange-Kalender nachweisen. +Tracelinks: StRS-052, SyRS-090, SwRS-120 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kalenderintegration ist Anwendererwartung; das Bugprotokoll weist auf + Nachbesserungsbedarf hin. +Status: belegt +``` + +``` +ID: StRS-052 +Titel: Outlook-Integration für CRM, Tickets und Belege +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Sachbearbeiter Vertrieb +Vorbedingung: Das Outlook-Add-In ist installiert und lizenziert. +Fakt: Das Projekt `CentronNexus.OutlookAddIn` enthält die Bereiche `CRM`, `Ticket`, `Belege`, + `Customer`, `Document` sowie ein `Manifest`-Verzeichnis; die Lizenz + `LicenseGuids.CentronOutlookAddInPro` und die `ApplicationKind.CentronOutlookAddInPro` + (ID 1024) sind definiert; in der Nexus-Pipeline existiert `UseOutlookCookiePolicy()`. +Aussage: Das System soll aus Outlook heraus Zugriff auf Kundendaten, Tickets und Belege bieten + und E-Mails diesen Objekten zuordnen können. +Ergebnis: Eine E-Mail lässt sich aus Outlook heraus einem Ticket oder Kunden zuordnen. +Belege: + - [PRIMÄR] src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs, + `CentronOutlookAddInPro = new ApplicationKind(1024, "Outlook Add-In", LicenseGuids.CentronOutlookAddInPro)` + - Begründung: Belegt das Add-In als eigenständig anmeldeberechtigte Anwendung mit Lizenzprüfung. + - [PRIMÄR] src/nexus/CentronNexus.Host/Program.cs, `app.UseOutlookCookiePolicy();` + - Begründung: Belegt eine eigene, durchgesetzte Cookie-Behandlung für den Add-In-Kontext. + - [SEKUNDÄR] src/nexus/CentronNexus.OutlookAddIn/CRM/, Ticket/, Belege/, Manifest/ + - Begründung: Belegen den fachlichen Funktionsumfang. +Prüfidee: Add-In ohne Lizenz starten; die Anmeldung am Web-Service muss abgelehnt werden. +Tracelinks: StRS-051, SyRS-091, SwRS-121 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Outlook-Integration ist im Zielmarkt erwartet. +Status: belegt +``` + +``` +ID: StRS-053 +Titel: Telefonanbindung mit Gesprächsprotokollierung +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Sachbearbeiter Vertrieb, Servicetechniker +Vorbedingung: Eine TAPI-fähige Telefonanlage ist angebunden. +Fakt: Es existieren `PhoneCallBL`, der SignalR-Hub `TapiClientHub`, die + `ApplicationKind.TapiServer` (ID 137438953472, `ExpirationKind.OneDay`), das Modul + `TelephonyCallLogAppModuleController` sowie die Einstellungsseiten + `PhoneSettingsController` und `PersonalPhoneSettingsController`; der Hintergrunddienst + `CallTrackingService` läuft mit. +Aussage: Das System soll ein- und ausgehende Telefonate erkennen, dem Geschäftspartner zuordnen + und als Gesprächsprotokoll speichern. +Ergebnis: Zu jedem Anruf existiert ein Protokolleintrag mit Partnerbezug. +Belege: + - [PRIMÄR] src/webservice/Centron.Host/RealTimeServices/TapiClientHub.cs + - Begründung: Belegt die Echtzeitverbindung zwischen Telefonanlage und Clients. + - [PRIMÄR] src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs, + `TapiServer = new ApplicationKind(137438953472L, "TapiServer", LicenseGuids.TapiServer, expirationKind: ExpirationKind.OneDay)` + - Begründung: Belegt die eigenständige, tagesgültige Lizenzierung des TAPI-Servers. + - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/CallTrackingService.cs + - Begründung: Belegt die laufende Protokollierung. + - [KONTEXT] docs/reference/architecture/tapi.md + - Begründung: Beschreibt die Architektur der Telefonanbindung. +Prüfidee: Eingehenden Anruf einer bekannten Nummer simulieren; es muss ein Gesprächsprotokoll mit + Kundenbezug entstehen. +Tracelinks: SyRS-092, SwRS-122 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - CTI-Integration ist im Servicegeschäft üblich; TAPI selbst ist als + Windows-Technologie im SaaS-Zielbild durch eine Cloud-Telefonieschnittstelle zu ersetzen. +Status: belegt +``` + +``` +ID: StRS-054 +Titel: Marketingkampagnen mit Phasen und Teilnehmerverwaltung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Sachbearbeiter Vertrieb +Vorbedingung: Eine Zielgruppe ist definiert. +Fakt: Es existieren die Tabellen `Campaigns`, `CampaignParticipants`, + `CampaignParticipantContactPerson`, `CampaignPhases`, `CampaignPhaseActions`, + `CampaignEmployees`, `CampaignMarkers`, `CampaignDecisionTemplateTexts` mit + Fremdschlüsseln untereinander; das Modul `CampaignAppModuleController` ist an + `LicenseGuids.CampaignsMailing` gebunden; der Dienst `CampaignPhaseService` läuft. +Aussage: Das System soll Marketingkampagnen mit Phasen, zugeordneten Mitarbeitern, Teilnehmern + und Ansprechpartnern führen und Phasenwechsel automatisiert auslösen. +Ergebnis: Eine Kampagne durchläuft die definierten Phasen; je Teilnehmer ist der Stand nachvollziehbar. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `FK_CampaignParticipants_Campaigns`, `FK_CampaignPhaseActions_CampaignPhases`, + `FK_CampaignEmployees_Campaigns`, `FK_CampaignMarkers_CampaignParticipant` + - Begründung: Erzwingen die referenzielle Struktur der Kampagne im Datenmodell. + - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/CampaignPhaseService.cs + - Begründung: Belegt den automatisierten Phasenfortschritt. + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(...)` mit `LicenseGuids.CampaignsMailing` + - Begründung: Belegt die Lizenzbindung. +Prüfidee: Kampagne mit zwei Phasen und einem Teilnehmer anlegen; nach der Phasenaktion muss der + Teilnehmer in Phase 2 stehen. +Tracelinks: StRS-005, SyRS-093, SwRS-123 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kampagnenmanagement bleibt fachlich relevant. +Status: belegt +``` + +``` +ID: StRS-055 +Titel: Digitale Dokumentfreigabe und Signatur +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Endkunde, Sachbearbeiter Vertrieb +Vorbedingung: Ein Dokument soll vom Kunden bestätigt werden. +Fakt: Es existieren `src/nexus/CentronNexus/DocumentSigning/`, die Seiten + `SharedDocumentPage.razor`, `SharedDocumentAcceptancePage.razor`, + `SharedDocumentSignPage.razor` sowie `PdfSigningBL` und die Einstellungsseite + `PdfSigningSettingsAppModuleController` (Modul `Administration/PdfSigning`). +Aussage: Das System soll Dokumente über einen Freigabelink bereitstellen, die Zustimmung des + Empfängers erfassen und PDF-Dokumente digital signieren. +Ergebnis: Ein bestätigtes Dokument liegt mit nachweisbarer Zustimmung und Signatur vor. +Belege: + - [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs + - Begründung: Die durchsetzende Komponente der Signaturerzeugung, im Sicherheitsnamensraum abgelegt. + - [PRIMÄR] src/nexus/CentronNexus/Office/SharedDocumentAcceptancePage.razor und SharedDocumentSignPage.razor + - Begründung: Belegen die zwei getrennten Vorgänge Zustimmung und Signatur. + - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/PdfSigning/ + - Begründung: Belegt die Konfigurierbarkeit der Signatur. +Prüfidee: Dokument freigeben, über den Link bestätigen und prüfen, dass die Signatur im PDF verifizierbar ist. +Tracelinks: StRS-044, SyRS-094, SwRS-124 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Digitale Freigabeprozesse sind im Zielbild wichtig. +Status: belegt +``` + +``` +ID: StRS-056 +Titel: KI-gestützte Unterstützung im Arbeitsalltag +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker, Sachbearbeiter +Vorbedingung: Die Lizenz `LicenseGuids.AiAssistant` liegt vor und der Benutzer besitzt das Recht + `UserRightsConst.ArtificialIntelligence.ID`. +Fakt: `ModuleRegistration` registriert `ArtificialIntelligenceChatAppModuleController` nur bei + Recht **und** Lizenz; die persönliche Einstellungsseite + `PersonalArtificialIntelligenceSettingsController` wird unter denselben beiden Bedingungen + hinzugefügt; es existieren `ArtificialIntelligenceChatsController`, + `ArtificialIntelligencePromptSettings` (mit Fremdschlüssel auf `PromptCategoryI3D`) und + `ServiceBoard/TicketAiSummary`. +Aussage: Das System soll einen KI-Assistenten mit verwalteten Prompt-Vorlagen bereitstellen und + ihn nur bei vorhandener Lizenz und Berechtigung anbieten. +Ergebnis: Berechtigte Anwender können den Assistenten nutzen; Prompt-Vorlagen sind zentral gepflegt. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, `GetPersonalSettings()`: + `if (LicenseManager.Instance.HasLicense(LicenseGuids.AiAssistant) && CentronCache.Instance.CurrentUserAppRights?.Any(f => f.I3D == UserRightsConst.ArtificialIntelligence.ID) == true) personalSettings.Add(new PersonalArtificialIntelligenceSettingsController());` + - Begründung: Die durchsetzende UND-Verknüpfung aus Lizenz und Recht. + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `FK_ArtificialIntelligencePromptSettings_PromptCategoryI3D` + - Begründung: Belegt die kategorisierte, persistierte Prompt-Verwaltung. + - [SEKUNDÄR] src/nexus/CentronNexus/ServiceBoard/TicketAiSummary/ + - Begründung: Belegt eine konkrete fachliche Anwendung (Ticketzusammenfassung). +Prüfidee: Benutzer mit Lizenz aber ohne Recht anmelden; die KI-Einstellungsseite darf nicht erscheinen. +Tracelinks: StRS-001, SyRS-095, SwRS-125 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - KI-Unterstützung ist strategisch; die konkrete Anbindung ist im + Zielsystem neu zu bewerten. +Status: belegt +``` + +### 2.9 Betrieb, Migration und Nutzungserlebnis + +``` +ID: StRS-057 +Titel: Betrieb wahlweise mit direkter Datenbankverbindung oder über den Web-Service +Ebene: StRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Anpassbarkeit) +Akteur: Betreiber, Administrator +Vorbedingung: Der Client soll in einem Netzwerk oder über das Internet betrieben werden. +Fakt: Jedes Modul deklariert `CentronConnectionType[] SupportsConnectionTypes` mit den Werten + `CentronWebServices` und `SqlServer`; jede fachliche Operation existiert als + `BL*Logic` (direkte Datenbank) und `WS*Logic` (Web-Service) hinter derselben `ILogic`-Schnittstelle. +Aussage: Das System soll denselben fachlichen Funktionsumfang wahlweise über eine direkte + Datenbankverbindung oder über den Web-Service bereitstellen. +Ergebnis: Ein Modul funktioniert unverändert in beiden Verbindungsarten. +Belege: + - [KONTEXT] docs/getting-started/general-structure.md, Abschnitt „Dual Implementation Architecture": + „**Every module MUST implement both data access methods**" + - Begründung: Beschreibt die verbindliche Architekturregel, ist aber keine durchsetzende Codestelle. + - [SEKUNDÄR] Ebenda, Codebeispiel `public CentronConnectionType[] SupportsConnectionTypes => new[] { CentronConnectionType.CentronWebServices, CentronConnectionType.SqlServer };` + - Begründung: Zeigt die Deklaration am Modulcontroller. + - [SEKUNDÄR] docs/getting-started/ai-codebase-navigation.md, Zeile „BLLogic / WSLogic | `src/centron/Centron.WPF.UI/Services/Logics/**/BL*Logic.cs`, `WS*Logic.cs`" + - Begründung: Belegt die tatsächliche Existenz beider Implementierungszweige im Dateibaum. +Prüfidee: Dasselbe Modul einmal mit `SqlServer`- und einmal mit `CentronWebServices`-Verbindung + öffnen; die angezeigten Daten müssen übereinstimmen. +Tracelinks: SyRS-100, SwRS-130 +Konsolidierung: Kandidat: SwRS-130 - Die doppelte Implementierung jeder Operation als BLLogic und + WSLogic ist derselbe fachliche Datenzugriff in zwei Ausprägungen und entfällt in einer + reinen Web-Architektur. +Übernahmewürdigkeit: veraltet - Im SaaS-Zielbild gibt es keine direkte Datenbankverbindung vom Client; + der BLLogic-Zweig entfällt. +Status: belegt +``` + +``` +ID: StRS-058 +Titel: Deutschsprachige Oberfläche mit englischer Alternative +Ebene: StRS +Typ: nicht-funktional +Qualitätsmerkmal: Benutzbarkeit (Erlernbarkeit, Zugänglichkeit) +Akteur: Alle Anwender +Vorbedingung: Der Anwender arbeitet in deutscher oder englischer Sprache. +Fakt: `[assembly: NeutralResourcesLanguage("de-DE")]` im Nexus-Host; deutsche Texte liegen in + `LocalizedStrings.resx`/`SharedResource.resx`, englische in `LocalizedStrings.en.resx`/ + `SharedResource.en-US.resx`. +Aussage: Das System soll alle anwendersichtbaren Texte in Deutsch als Standardsprache und + zusätzlich in Englisch bereitstellen. +Ergebnis: Ein Anwender mit englischer Spracheinstellung erhält englische Oberflächentexte. +Belege: + - [PRIMÄR] src/nexus/CentronNexus.Host/Program.cs, `[assembly: NeutralResourcesLanguage("de-DE")]` + - Begründung: Legt Deutsch als Rückfallsprache technisch fest. + - [PRIMÄR] src/nexus/CentronNexus/SharedResource.resx und SharedResource.en-US.resx + - Begründung: Belegen die zwei tatsächlich gepflegten Sprachvarianten. + - [KONTEXT] docs/getting-started/general-structure.md, Abschnitt „German-First Language Policy" + - Begründung: Beschreibt die Sprachregel als Projektvorgabe. +Prüfidee: Oberfläche auf Englisch umstellen und stichprobenartig prüfen, dass keine deutschen + Texte stehen bleiben. +Tracelinks: SyRS-101, SwRS-131 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Zweisprachigkeit bleibt erforderlich. +Status: belegt +``` + +``` +ID: StRS-059 +Titel: Betrieb in Containern und auf Linux +Ebene: StRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Installierbarkeit) +Akteur: Betreiber +Vorbedingung: Das Portal soll containerisiert betrieben werden. +Fakt: `docker/Dockerfile` veröffentlicht `CentronNexus.Host` self-contained auf + `mcr.microsoft.com/dotnet/runtime:10.0.5-alpine3.23`, setzt `TZ=Europe/Berlin`, + `DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false` und installiert `icu-libs` sowie Schriftarten; + `Program.cs` unterscheidet `OperatingSystem.IsWindows()` (HttpSys) von Kestrel und lädt + unter Linux ein PKCS#12-Zertifikat. +Aussage: Das System soll das Webportal als Linux-Container betreiben können, wobei + Zeitzone Europe/Berlin und volle Globalisierungsunterstützung vorausgesetzt werden. +Ergebnis: Der Container startet auf Linux und liefert korrekt formatierte deutsche Datums- und Zahlenwerte. +Belege: + - [PRIMÄR] docker/Dockerfile, `ENV TZ=Europe/Berlin` und `ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false` + mit `RUN apk add --no-cache icu-data-full icu-libs` + - Begründung: Die durchsetzende Laufzeitkonfiguration; ohne ICU würde die Formatierung abweichen. + - [PRIMÄR] src/nexus/CentronNexus.Host/Program.cs, `if (OperatingSystem.IsWindows()) { ConfigureWebHostWindows(host); }` + und `X509CertificateLoader.LoadPkcs12FromFile(hostConfig.LinuxCertificatePath, hostConfig.LinuxCertificatePassword)` + - Begründung: Belegt die plattformabhängige Hostkonfiguration. + - [KONTEXT] docs/guides/services/web-service-on-linux.md + - Begründung: Beschreibt den Linux-Betrieb des Web-Service. +Prüfidee: Container starten und die Ausgabe eines Datums auf deutsches Format prüfen. +Tracelinks: SyRS-102, SwRS-132 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Containerbetrieb ist Voraussetzung für SaaS. +Status: belegt +``` + +``` +ID: StRS-060 +Titel: Schutz vor versehentlicher Außenwirkung in Entwicklungsumgebungen +Ebene: StRS +Typ: nicht-funktional +Qualitätsmerkmal: Zuverlässigkeit (Fehlertoleranz) +Akteur: Betreiber +Vorbedingung: Es wird ein DEBUG-Build betrieben. +Fakt: Laut `docs/reference/security/developer-security.md` ersetzt `DeveloperSecurity.cs` in + DEBUG-Builds alle externen E-Mail-Adressen durch `test@nexoware.com`; interne Adressen + (Endung `nexoware.com`) bleiben unverändert. Das Verhalten ist über + `AllowSendingEmailToExternalAddresses` abschaltbar. +Aussage: Das System soll in Entwicklungs- und Testumgebungen den Versand an echte Kundenadressen + technisch unterbinden. +Ergebnis: Aus einem DEBUG-Build erreicht keine E-Mail eine externe Adresse. +Belege: + - [KONTEXT] docs/reference/security/developer-security.md, Abschnitt „Sending emails" mit dem + Hinweis „These safeguards are only active in DEBUG-builds" + - Begründung: Beschreibt Mechanismus und Grenze; die Datei `DeveloperSecurity.cs` selbst wurde + im Rahmen dieses Laufs nicht gelesen, daher kein PRIMÄR-Beleg. + - [SEKUNDÄR] docker/c-entron-mailcatcher/ + - Begründung: Belegt eine zusätzliche Testinfrastruktur zum Abfangen von E-Mails. +Prüfidee: DEBUG-Build eine Mail an eine externe Adresse senden lassen und im Mailcatcher prüfen, + dass die Empfängeradresse ersetzt wurde. +Tracelinks: SyRS-103, SwRS-133 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Umgebungstrennung ist im SaaS-Betrieb noch wichtiger. +Status: belegt +``` + +``` +ID: StRS-061 +Titel: Nutzungstelemetrie +Ebene: StRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Analysierbarkeit) +Akteur: Betreiber +Vorbedingung: Das System ist in Betrieb. +Fakt: Es existieren `TelemetryBL`, die Hintergrunddienste `TelemetryFlushService` und + `TelemetryUploadService`, die Tabelle `ApplicationUserStatistics` mit der Constraint + `IX_ApplicationUserStatistics_ActionUniqueCluster UNIQUE CLUSTERED`, sowie ein + Kommentar in `LicenseGuids.cs`: „Task: Update TelemetryLicenseKind.cs … enum, when new + licenses were added." +Aussage: Das System soll die Nutzung von Funktionen und Lizenzen messen, verdichten und an den + Hersteller übermitteln. +Ergebnis: Der Hersteller erhält verdichtete Nutzungsdaten je Installation. +Belege: + - [PRIMÄR] SSMS_DB_SCHEMA.sql, `CONSTRAINT [IX_ApplicationUserStatistics_ActionUniqueCluster] UNIQUE CLUSTERED` + - Begründung: Belegt die je Aktion verdichtete, eindeutige Erfassung. + - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/TelemetryFlushService.cs und + TelemetryUploadService.cs + - Begründung: Belegen Verdichtung und Übertragung als laufende Dienste. + - [KONTEXT] src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs, Klassenkommentar zu + `TelemetryLicenseKind.cs` + - Begründung: Belegt die Kopplung der Telemetrie an das Lizenzmodell. +Prüfidee: Modul aufrufen und prüfen, dass in `ApplicationUserStatistics` ein Eintrag entsteht. +Tracelinks: SyRS-104, SwRS-134 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Nutzungsdaten steuern die Produktentwicklung; im SaaS-Betrieb ist die + datenschutzrechtliche Grundlage neu zu klären. +Status: belegt +``` + +``` +ID: StRS-062 +Titel: Vorgabe der Vertragsabrechnung durch bewusst deaktivierte Funktionen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Betreiber, Administrator +Vorbedingung: — +Fakt: `ModuleRegistration` enthält zwei auskommentierte Einträge mit fachlicher Begründung: + `// new CTimeConnectorSettingsController(), -- SKA 2025-09-18 : Requested by Volker Lehnert, to deactivate the c-time Connector settings` + und `// SKA : Hide the travel expense module for now. The module is not finished yet. Ordered from Volker Lehnert` + (`TravelExpenseAppModuleController`, Recht `Purchase.TRAVEL_EXPENSE_ADMIN`). +Aussage: Das System enthält Funktionen (c-time-Konnektor-Einstellungen, Reisekostenmodul), die + fachlich vorhanden, aber auf ausdrückliche Anweisung deaktiviert sind. +Ergebnis: Die betroffenen Funktionen sind für Anwender nicht erreichbar, ihr Code ist jedoch vorhanden. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, die beiden auskommentierten + Registrierungen mit den zitierten Kommentaren + - Begründung: Die Auskommentierung ist die durchsetzende Stelle der Deaktivierung. + - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/Services/CTimeConnectors/ + - Begründung: Belegt, dass der Code der deaktivierten Funktion weiterhin existiert. +Prüfidee: Prüfen, dass weder c-time-Einstellungen noch das Reisekostenmodul in der Oberfläche erscheinen. +Tracelinks: StRS-001, SwRS-135 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - Für die Neuimplementierung sind beide Funktionen nicht zu übernehmen, + solange keine erneute fachliche Freigabe vorliegt. +Status: belegt +``` + +``` +ID: StRS-063 +Titel: Interne Sonderfunktionen des Herstellers +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Betreiber (Hersteller) +Vorbedingung: Die Installation gehört dem Hersteller. +Fakt: `ModuleFeatures.SetAccessRights(CentronApplication.Instance.Connection.IsAdmin, + LicenseManager.Instance.HasLicense(LicenseGuids.ProductPreview), + LicenseManager.Instance.IsCustomerCentronSoftwareGmbh())`; das Modul + `ProjectManagementAppModuleController` wird nur bei `ModuleFeatures.IsCentronInternal` + registriert; `CentronInspectorAppModuleController` nur bei `Connection.IsAdmin`; + `TestModuleApp` nur bei `Debugger.IsAttached`. +Aussage: Das System soll bestimmte Funktionen ausschließlich für Installationen des Herstellers, + für Administratoren oder für angehängte Debugger freischalten. +Ergebnis: Kundeninstallationen sehen die internen Module nicht. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, `DoRegisterCentronModules`: + `ModuleFeatures.SetAccessRights(..., LicenseManager.Instance.IsCustomerCentronSoftwareGmbh());` + - Begründung: Die durchsetzende Ableitung der internen Sonderrechte. + - [PRIMÄR] Ebenda, `ModuleRegistrationItem.For(() => Helper.NoRightCheck(), () => Debugger.IsAttached)` + - Begründung: Zeigt die Bindung eines Moduls an eine reine Entwicklungsbedingung. + - [PRIMÄR] Ebenda, `ModuleRegistrationItem.For(() => Helper.NoRightCheck(), () => CentronApplication.Instance.Connection.IsAdmin && ...)` + - Begründung: Belegt die Bindung an das Administratorkennzeichen der Verbindung statt an ein Benutzerrecht. +Prüfidee: Kundeninstallation starten; Projektverwaltung, Inspektor und Testmodul dürfen nicht erscheinen. +Tracelinks: StRS-001, SyRS-105, SwRS-136 +Konsolidierung: nein +Übernahmewürdigkeit: Sonderfall - Herstellerinterne Module sind kundenseitig nicht zu übernehmen. +Status: belegt +``` + +``` +ID: StRS-064 +Titel: Direkter SQL-Zugriff für Administratoren +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Der Benutzer besitzt das Recht `UserRightsConst.Administration.SQL_MANAGER`. +Fakt: Das Modul `SqlManagerAppModuleController` ist an genau dieses Recht und die Lizenz + `LicenseGuids.SQLManager` gebunden; es existiert `Centron.BL/Administration/SQLManagement/`. +Aussage: Das System stellt Administratoren ein Werkzeug für direkte SQL-Abfragen auf der + Produktivdatenbank bereit. +Ergebnis: Ein berechtigter Administrator kann SQL gegen die Datenbank absetzen. +Belege: + - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung + `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.Administration.SQL_MANAGER), ...)` + - Begründung: Die einzige durchsetzende Kontrolle vor einem sehr weitreichenden Werkzeug. + - [PRIMÄR] src/backend/Centron.BL/Administration/SQLManagement/ (u. a. genutzt von + `LicenseManager.SettingsForWebService` über `SQLManagementBL.GetDatabaseInfosForLicenseServer()`) + - Begründung: Belegt den tatsächlichen direkten Datenbankzugriff dieser Komponente. +Prüfidee: Benutzer ohne `SQL_MANAGER` anmelden; das Modul darf nicht erscheinen. +Tracelinks: StRS-037, SyRS-106, SwRS-137 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - Ein direkter SQL-Zugriff aus der Anwendung heraus ist in einer + mandantenfähigen SaaS-Umgebung nicht tragbar und durch kontrollierte Auswertungen zu ersetzen. +Status: belegt +``` + +``` +ID: StRS-065 +Titel: Zugriff externer Systeme über technische Anwendungen +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Externes System / Konnektor +Vorbedingung: Für das externe System ist eine Anwendungslizenz vorhanden. +Fakt: `ApplicationKind` definiert über 40 anmeldeberechtigte Anwendungen, darunter + `ExternalAppDocBee`, `ExternalAppVisoma`, `ExternalAppWOASI`, `ExternalAppRiverbird`, + `GFIMax`, `NAble`, `InvenigateConnector`, `TANSSInterface`; einzelne tragen zusätzlich + ein erforderliches (`requiredRight`) oder ein ausschließendes Recht (`disallowingRight`). +Aussage: Das System soll Fremdsystemen einen eigenen, lizenz- und rechtegebundenen technischen + Zugang gewähren, der von Benutzerzugängen unterscheidbar ist. +Ergebnis: Ein Fremdsystem meldet sich mit seiner Anwendungskennung an und erhält ein eigenes Ticket. +Belege: + - [PRIMÄR] src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs, z. B. + `MailScannerNET = new ApplicationKind(34359738368L, "MailScannerNET", LicenseGuids.MailScannerNET, requiredRight: ACCESS_VMA_MODULE)` + und `ServiceBoard = new ApplicationKind(524288, ..., disallowingRight: RIGHT_DISALLOW_SERVICEBOARD_LOGIN)` + - Begründung: Belegt die je Anwendung durchgesetzten Rechtebedingungen. + - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, `ValidateRights`: + `if (applicationKind.DisallowingRight != null && _appRightsBl.HasUserRight(user.User.I3D, applicationKind.DisallowingRight.Value) == true) return Result.AsError(...)` + und die spiegelbildliche Prüfung auf `RequiredRight` + - Begründung: Die durchsetzende Stelle beider Rechtearten bei der Anmeldung. +Prüfidee: Benutzer mit `RIGHT_DISALLOW_SERVICEBOARD_LOGIN` am ServiceBoard anmelden; die Anmeldung + muss mit `RightCheckFailed` scheitern. +Tracelinks: StRS-002, StRS-039, SyRS-107, SwRS-138 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Technische Zugänge für Fremdsysteme bleiben nötig; im Zielsystem als + OAuth-Client-Credentials statt als Pseudo-Benutzer. +Status: belegt +``` diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Protokoll.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Protokoll.md new file mode 100644 index 00000000..ce86f4e4 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Protokoll.md @@ -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. diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/RawResult.json b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/RawResult.json new file mode 100644 index 00000000..23e259dd --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/RawResult.json @@ -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} diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Stderr.log b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/Stderr.log new file mode 100644 index 00000000..e69de29b diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/anforderungen.json b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/anforderungen.json new file mode 100644 index 00000000..bf8431c8 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/anforderungen.json @@ -0,0 +1,1352 @@ +[ + { + "id": "StRS-001", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Funktionsumfang wird über Lizenzen gesteuert", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-001, SyRS-002, SwRS-001", + "konsolidierung": "nein", + "pruefidee": "Installation ohne die Lizenz `LicenseGuids.PasswordManager` starten; der Passwort-Manager", + "qm": "", + "uebernahme": "übernehmen - Feature-Gating ist die Basis des Geschäftsmodells und in SaaS unverzichtbar." + }, + { + "id": "StRS-002", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Lizenzen sind mengen- und laufzeitbegrenzt", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, SyRS-003, SwRS-002", + "konsolidierung": "nein", + "pruefidee": "Bei Lizenzanzahl 1 zwei Anmeldungen von unterschiedlichen Geräten versuchen; die zweite", + "qm": "", + "uebernahme": "übernehmen - Mengen- und Laufzeitbegrenzung bleibt in einem SaaS-Abomodell erforderlich." + }, + { + "id": "StRS-003", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Mehrmandantenbetrieb", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-004, SwRS-003", + "konsolidierung": "nein", + "pruefidee": "Zwei Mandanten anlegen und prüfen, dass Belegnummernkreise und Auswertungen je Mandant getrennt sind.", + "qm": "", + "uebernahme": "übernehmen - Mandantenfähigkeit ist für SaaS zwingend." + }, + { + "id": "StRS-004", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Filialstruktur als Sichtbarkeits- und Auswertungsdimension", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-021, SyRS-010, SwRS-004", + "konsolidierung": "nein", + "pruefidee": "Benutzer mit `SHOW_HELPDESK_ONLY_OWN_BRANCH` anmelden und prüfen, dass Tickets fremder Filialen fehlen.", + "qm": "", + "uebernahme": "übernehmen - Organisationsstruktur bleibt fachlich relevant." + }, + { + "id": "StRS-005", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Zentraler Adressstamm für Kunden und Lieferanten", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-012, SwRS-010, SwRS-011", + "konsolidierung": "nein", + "pruefidee": "Zwei Kunden mit gleicher Kundennummer anlegen; das zweite Speichern muss an der", + "qm": "", + "uebernahme": "übernehmen - Zentraler Partnerstamm ist fachlicher Kern." + }, + { + "id": "StRS-006", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Zwei alternative Oberflächen für denselben Adressstamm", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-005, SyRS-013, SwRS-012", + "konsolidierung": "Kandidat: StRS-005 - zwei parallel gepflegte Oberflächen für denselben fachlichen Gegenstand", + "pruefidee": "Einstellung umschalten und prüfen, dass jeweils nur ein Adressmodul erscheint.", + "qm": "", + "uebernahme": "Workaround - historisch gewachsene Doppelpflege zweier Masken; im Zielsystem genügt eine." + }, + { + "id": "StRS-007", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kreditlimit je Kunde", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-030, SwRS-060", + "konsolidierung": "nein", + "pruefidee": "Kunde mit Limit 1.000 EUR, Auftrag über 1.500 EUR erfassen; die Warnung muss erscheinen,", + "qm": "", + "uebernahme": "übernehmen - Kreditlimitüberwachung ist ein üblicher betriebswirtschaftlicher Bedarf." + }, + { + "id": "StRS-008", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kunden können sich selbst über ein Webportal bedienen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-009, SyRS-014, SyRS-015, SwRS-014", + "konsolidierung": "nein", + "pruefidee": "Mit einem Web-Account anmelden und den Aufruf einer Adressänderungsfunktion versuchen;", + "qm": "", + "uebernahme": "übernehmen - Kundenselbstbedienung ist im SaaS-Zielbild zentral." + }, + { + "id": "StRS-009", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kundenspezifische Sonderpreise als Grundlage des Webshops", + "typ": "funktional", + "belege": [ + "SEKUNDÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-008, SyRS-016, SwRS-015", + "konsolidierung": "nein", + "pruefidee": "Für einen Testkunden einen Sonderpreis anlegen und prüfen, dass genau dieser Artikel im", + "qm": "", + "uebernahme": "übernehmen - Kundenindividuelle Kataloge sind fachlich weiterhin erforderlich." + }, + { + "id": "StRS-010", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Durchgängige Belegkette im Verkauf", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020, SyRS-021, SwRS-030, SwRS-031", + "konsolidierung": "nein", + "pruefidee": "Aus einem Angebot einen Auftrag, daraus einen Lieferschein und daraus eine Rechnung", + "qm": "", + "uebernahme": "übernehmen - Die Belegkette ist der fachliche Kern des ERP." + }, + { + "id": "StRS-011", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Belege sind versioniert und revisionsfähig", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-010, SyRS-022, SwRS-032", + "konsolidierung": "nein", + "pruefidee": "Einen Beleg zweimal ändern und prüfen, dass in der Versionstabelle zwei vollständige", + "qm": "", + "uebernahme": "übernehmen - Revisionssicherheit ist bei Belegen gesetzlich und fachlich geboten." + }, + { + "id": "StRS-012", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Verträge werden periodisch automatisch abgerechnet", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013, SyRS-040, SyRS-041, SwRS-070, SwRS-071", + "konsolidierung": "nein", + "pruefidee": "Vertrag mit monatlichem Intervall und Vertragsbeginn am 31.01. anlegen; der berechnete", + "qm": "", + "uebernahme": "übernehmen - Wiederkehrende Abrechnung ist Kern des Servicegeschäfts." + }, + { + "id": "StRS-013", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kalendergenaue Behandlung von Monatsenden und Schaltjahren in der Abrechnung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012, SwRS-071", + "konsolidierung": "nein", + "pruefidee": "Vertrag mit `InvoiceFrom` = 31.01.2027 (kein Schaltjahr): Der Folgezeitraum muss am", + "qm": "", + "uebernahme": "übernehmen - Die Regel ist fachlich korrekt und muss im Zielsystem 1:1 nachgebildet werden;" + }, + { + "id": "StRS-014", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kontingentverträge mit Verbrauchsverrechnung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012, SyRS-042, SwRS-072", + "konsolidierung": "nein", + "pruefidee": "Vertrag mit 10-Stunden-Kontingent anlegen, 12 Stunden buchen; 10 Stunden müssen gegen das", + "qm": "", + "uebernahme": "übernehmen - Kontingentmodelle sind im Managed-Service-Geschäft üblich." + }, + { + "id": "StRS-015", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Klickabrechnung für Druck- und Kopiergeräte", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-014, StRS-026, SyRS-043, SwRS-073", + "konsolidierung": "nein", + "pruefidee": "Zwei Zählerstände mit Differenz 1.000 und 200 Freikopien erfassen; die abrechenbare Menge muss 800 betragen.", + "qm": "", + "uebernahme": "übernehmen - Klickabrechnung ist ein tragendes Geschäftsmodell im Bürodruckumfeld." + }, + { + "id": "StRS-016", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Mehrstufiges Mahnwesen über offene Rechnungen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-017, SyRS-044, SwRS-074", + "konsolidierung": "nein", + "pruefidee": "Rechnung überfällig setzen und drei Mahnläufe durchführen; die Mahnstufe muss von", + "qm": "", + "uebernahme": "übernehmen - Forderungsmanagement bleibt erforderlich." + }, + { + "id": "StRS-017", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Offene-Posten-Verwaltung und Zahlungszuordnung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016, StRS-018, SyRS-045, SwRS-075", + "konsolidierung": "nein", + "pruefidee": "Rechnung über 100 EUR stellen, Zahlung über 60 EUR zuordnen; der offene Posten muss 40 EUR betragen.", + "qm": "", + "uebernahme": "übernehmen - OP-Verwaltung ist buchhalterischer Standard." + }, + { + "id": "StRS-018", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "SEPA-Zahlungsverkehr mit Mandatsverwaltung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-017, SyRS-046, SwRS-076", + "konsolidierung": "nein", + "pruefidee": "Vertrag mit Mandat abrechnen und prüfen, dass die erzeugte SEPA-Datei die Mandatsreferenz enthält.", + "qm": "", + "uebernahme": "übernehmen - Lastschrifteinzug ist im Abomodell zentral." + }, + { + "id": "StRS-019", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Übergabe der Buchungsdaten an die Finanzbuchhaltung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "KONTEXT", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-047, SwRS-077", + "konsolidierung": "Kandidat: StRS-020 - Buchhaltungsexport und DATEV-Belegtransfer bilden denselben", + "pruefidee": "Buchhaltungsexport für einen Monat ausführen und die erzeugte Datei gegen das Zielformat prüfen.", + "qm": "", + "uebernahme": "übernehmen - Fibu-Übergabe bleibt erforderlich; die als obsolet markierte" + }, + { + "id": "StRS-020", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Elektronische Rechnungsformate (ZUGFeRD/XRechnung, ebInterface)", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-019, SyRS-048, SwRS-078", + "konsolidierung": "nein", + "pruefidee": "Eine Rechnung als ZUGFeRD exportieren und mit dem KOSIT-Prüfwerkzeug validieren.", + "qm": "", + "uebernahme": "übernehmen - E-Rechnung ist in Deutschland verpflichtend; die Eigenimplementierung" + }, + { + "id": "StRS-021", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Serviceticketbearbeitung als eigenständiger Geschäftsprozess", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-022, StRS-023, SyRS-050, SwRS-080", + "konsolidierung": "nein", + "pruefidee": "Ticket ohne Pflichtangaben speichern; das Speichern muss mit einem Fehler abgewiesen werden.", + "qm": "", + "uebernahme": "übernehmen - Ticketing ist tragender Geschäftsprozess." + }, + { + "id": "StRS-022", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Abgestufte Ticketsichtbarkeit durch einschränkende Rechte", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-004, StRS-021, SyRS-051, SwRS-081", + "konsolidierung": "nein", + "pruefidee": "Benutzer mit `SHOW_HELPDESK` + `SHOW_HELPDESK_ONLY_OWN` + `SHOW_HELPDESK_ONLY_OWN_BRANCH`", + "qm": "", + "uebernahme": "übernehmen - Abgestufte Sichtbarkeit ist datenschutzrechtlich und organisatorisch nötig." + }, + { + "id": "StRS-023", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Ticketzeiten als Grundlage der Leistungsabrechnung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-021, SyRS-052, SwRS-082", + "konsolidierung": "nein", + "pruefidee": "Ticketzeit abrechnen und anschließend löschen wollen; der Löschversuch muss abgewiesen werden.", + "qm": "", + "uebernahme": "übernehmen - Der Schutz abgerechneter Zeiten ist buchhalterisch notwendig." + }, + { + "id": "StRS-024", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Checklisten und Ticketprozessvorlagen zur Standardisierung von Serviceabläufen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-021, SyRS-053, SwRS-083", + "konsolidierung": "nein", + "pruefidee": "Ticket aus einer Vorlage mit drei Schritten anlegen; das Ticket muss drei Checklistenpunkte enthalten.", + "qm": "", + "uebernahme": "übernehmen - Standardisierung von Serviceabläufen ist fachlich sinnvoll." + }, + { + "id": "StRS-025", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Automatische Ticketerzeugung aus wiederkehrenden Anlässen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-024, SyRS-054, SwRS-084", + "konsolidierung": "nein", + "pruefidee": "Wartungstermin mit Vorlage anlegen; zum Termin muss automatisch ein Ticket entstehen.", + "qm": "", + "uebernahme": "übernehmen - Automatisierung wiederkehrender Serviceanlässe ist fachlich wertvoll." + }, + { + "id": "StRS-026", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Gerätestammblätter als Bezugsobjekt für Service und Abrechnung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-015, StRS-027, SyRS-055, SwRS-085", + "konsolidierung": "nein", + "pruefidee": "Seriennummer des Hauptgeräts ohne das erforderliche Recht ändern; die Änderung muss mit", + "qm": "", + "uebernahme": "übernehmen - Installierte Basis ist Grundlage von Service und Abrechnung." + }, + { + "id": "StRS-027", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Getrennte Datenhaltung für Drucker (Stammblätter) und sonstige Hardware (Assets)", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-026, SwRS-086", + "konsolidierung": "Kandidat: StRS-026 - Stammblätter und Assets bilden denselben fachlichen Gegenstand", + "pruefidee": "Ein Gerät als Stammblatt und als Asset erfassen; es darf keine erzwungene Verknüpfung", + "qm": "", + "uebernahme": "Workaround - historisch getrennt gewachsen; im Zielsystem ein gemeinsames Asset-Modell." + }, + { + "id": "StRS-028", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "RMA- und Werkstattabwicklung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-021, SyRS-056, SwRS-087", + "konsolidierung": "nein", + "pruefidee": "RMA aus einem Ticket anlegen; der eindeutige Index auf `Rma.HelpdeskI3D` muss ein zweites", + "qm": "", + "uebernahme": "übernehmen - Reklamationsabwicklung ist fachlich erforderlich." + }, + { + "id": "StRS-029", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Elektronischer Belegaustausch mit Distributoren", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-030, SyRS-060, SwRS-090, SwRS-091", + "konsolidierung": "nein", + "pruefidee": "Auftragsbestätigung eines Distributors einspielen; die Bestellpositionen müssen mit", + "qm": "", + "uebernahme": "übernehmen - EDI ist im IT-Distributionsgeschäft Standard." + }, + { + "id": "StRS-030", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Artikelstammdaten aus externen Produktdatenquellen", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-029, StRS-031, SyRS-061, SwRS-092", + "konsolidierung": "nein", + "pruefidee": "Artikelimport eines Distributors ausführen und prüfen, dass ein `ArticleImportLog`-Eintrag entsteht.", + "qm": "", + "uebernahme": "übernehmen - Externe Produktdaten bleiben erforderlich." + }, + { + "id": "StRS-031", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Artikelstamm mit Warengruppen, Preisen und Beständen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-030, StRS-032, SyRS-062, SwRS-093", + "konsolidierung": "nein", + "pruefidee": "Zwei Artikel mit identischer Artikelnummer anlegen; das zweite Speichern muss scheitern.", + "qm": "", + "uebernahme": "übernehmen - Artikelstamm ist ERP-Kern." + }, + { + "id": "StRS-032", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Mehrlagerfähigkeit mit kontrollierten Umbuchungen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031, StRS-033, SyRS-063, SwRS-094", + "konsolidierung": "nein", + "pruefidee": "Umbuchung ohne `TRANSFER_STOCK` versuchen; sie muss mit `RightCheckFailed` scheitern.", + "qm": "", + "uebernahme": "übernehmen - Mehrlagerfähigkeit und Buchungsberechtigung bleiben nötig." + }, + { + "id": "StRS-033", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Inventur mit definierten Zuständen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-032, SyRS-064, SwRS-095", + "konsolidierung": "nein", + "pruefidee": "Inventur abschließen und anschließend eine Zählposition ändern wollen; die Änderung muss", + "qm": "", + "uebernahme": "übernehmen - Inventur ist handelsrechtlich vorgeschrieben." + }, + { + "id": "StRS-034", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kommissionierung und Versandabwicklung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-033, SyRS-065, SwRS-096", + "konsolidierung": "Kandidat: StRS-034 - GLS und Shipcloud bilden dieselbe fachliche Funktion", + "pruefidee": "Lieferschein über Shipcloud versenden; es muss eine Sendungsnummer zurückgeschrieben werden.", + "qm": "", + "uebernahme": "übernehmen - Versandabwicklung bleibt erforderlich." + }, + { + "id": "StRS-035", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Bestellvorschläge aus Bedarf und Bestand", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031, SyRS-066, SwRS-097", + "konsolidierung": "nein", + "pruefidee": "Artikel unter Meldebestand mit offenem Auftrag anlegen; der Artikel muss im", + "qm": "", + "uebernahme": "veraltet - Der Modultyp ist im Code als obsolet markiert; die Funktion ist im" + }, + { + "id": "StRS-036", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Wareneingang mit Einkaufskalkulation", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-029, StRS-031, SyRS-067, SwRS-098", + "konsolidierung": "nein", + "pruefidee": "Wareneingang mit Fracht- und Nebenkosten erfassen; der kalkulierte Einstandspreis muss", + "qm": "", + "uebernahme": "übernehmen - Einstandspreiskalkulation ist für die Margenrechnung notwendig." + }, + { + "id": "StRS-037", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Feingranulare Rechteverwaltung als Grundlage der Zugriffskontrolle", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-038, StRS-039, SyRS-070, SyRS-071, SwRS-100", + "konsolidierung": "nein", + "pruefidee": "Benutzer ohne `CREATE_CUSTOMER` anlegen und einen Kunden anlegen lassen; es muss", + "qm": "", + "uebernahme": "übernehmen - Feingranulare Rechte sind fachlich notwendig; die numerischen" + }, + { + "id": "StRS-038", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Rechteprüfung an mehreren Schichten", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-037, SyRS-071, SwRS-101", + "konsolidierung": "nein", + "pruefidee": "Geschützten Endpunkt ohne Recht direkt per HTTP aufrufen; die Antwort muss 403 sein.", + "qm": "", + "uebernahme": "übernehmen - Serverseitige Durchsetzung ist zwingend." + }, + { + "id": "StRS-039", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Mehrere Anmeldeverfahren einschließlich Verzeichnisdienst und OpenID Connect", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-040, SyRS-072, SyRS-073, SwRS-102", + "konsolidierung": "nein", + "pruefidee": "OIDC-Anmeldung ohne die Lizenz versuchen; die Antwort muss „No license for", + "qm": "", + "uebernahme": "übernehmen - Verzeichnis- und Identitätsanbindung ist in Unternehmen Standard." + }, + { + "id": "StRS-040", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Zwei-Faktor-Authentifizierung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-039, SyRS-074, SwRS-103", + "konsolidierung": "nein", + "pruefidee": "Benutzer mit hinterlegtem 2FA-Schlüssel mit falscher PIN anmelden; die Anmeldung muss mit", + "qm": "", + "uebernahme": "übernehmen - Zweiter Faktor ist im SaaS-Betrieb Mindeststandard." + }, + { + "id": "StRS-041", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Zeitlich steuerbare Deaktivierung von Benutzerkonten", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-039, SyRS-075, SwRS-104", + "konsolidierung": "nein", + "pruefidee": "`AccountDisabledFromDate` auf gestern setzen und Anmeldung versuchen; sie muss mit", + "qm": "", + "uebernahme": "übernehmen - Konten-Lebenszyklus ist Compliance-Anforderung." + }, + { + "id": "StRS-042", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Verschlüsselte Ablage von Kundenzugangsdaten", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-043, SyRS-076, SwRS-105", + "konsolidierung": "nein", + "pruefidee": "Kennwort speichern und den Rohwert in der Datenbank prüfen; er darf nicht dem Klartext entsprechen.", + "qm": "", + "uebernahme": "übernehmen - Verschlüsselte Geheimnisablage ist zwingend; das Schlüsselmanagement" + }, + { + "id": "StRS-043", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Passwortrichtlinien für verwaltete Zugänge", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-042, SyRS-077, SwRS-106", + "konsolidierung": "nein", + "pruefidee": "Richtlinie mit Mindestlänge 12 hinterlegen und ein achtstelliges Kennwort speichern; die", + "qm": "", + "uebernahme": "übernehmen - Kennwortrichtlinien bleiben fachlich sinnvoll." + }, + { + "id": "StRS-044", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Auftragsverarbeitungsverträge und Datenschutzdokumentation", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-045, SyRS-078, SwRS-107", + "konsolidierung": "nein", + "pruefidee": "Auftragsverarbeitungsvertrag aus Vorlage erzeugen und online zustimmen lassen; der Status", + "qm": "", + "uebernahme": "übernehmen - DSGVO-Nachweise sind gesetzlich gefordert." + }, + { + "id": "StRS-045", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Löschbarkeit personenbezogener Daten", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-044, SyRS-079, SwRS-108", + "konsolidierung": "nein", + "pruefidee": "Löschung eines Kontakts anstoßen und prüfen, dass alle mit `IsDsgvoSetNull` markierten", + "qm": "", + "uebernahme": "übernehmen - Löschkonzept ist gesetzlich gefordert. [HYPOTHESE-Anteil: Der genaue" + }, + { + "id": "StRS-046", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Betriebswirtschaftliche Auswertungen für die Geschäftsführung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-047, SyRS-080, SwRS-110", + "konsolidierung": "nein", + "pruefidee": "Endpunkt `NexowareStatisticsController` ohne `SALES_STATISTIC` aufrufen; die Antwort muss 403 sein.", + "qm": "", + "uebernahme": "übernehmen - Steuerungskennzahlen bleiben erforderlich." + }, + { + "id": "StRS-047", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Managed-Service-Auswertung (MSP)", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012, StRS-046, SyRS-081, SwRS-111", + "konsolidierung": "nein", + "pruefidee": "MSP-Auswertung mit 12 gemeldeten und 10 vertraglich vereinbarten Lizenzen erzeugen; es", + "qm": "", + "uebernahme": "übernehmen - MSP-Abgleich ist Kern des Managed-Service-Geschäfts." + }, + { + "id": "StRS-048", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Zeitgesteuerte Hintergrundverarbeitung ohne Benutzerinteraktion", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-025, StRS-029, SyRS-082, SyRS-083, SwRS-112", + "konsolidierung": "nein", + "pruefidee": "Web-Service starten und im Protokoll die Startmeldungen der Hintergrunddienste nachweisen.", + "qm": "", + "uebernahme": "übernehmen - Hintergrundverarbeitung bleibt erforderlich; im SaaS-Zielbild sind die" + }, + { + "id": "StRS-049", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Massenänderung von Datenbeständen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-048, SyRS-084, SwRS-113", + "konsolidierung": "nein", + "pruefidee": "Massenänderung ohne `ACCESS_DATAUPDATER_MODULE` aufrufen; das Modul darf nicht sichtbar sein.", + "qm": "", + "uebernahme": "übernehmen - Massenpflege ist bei Datenmigrationen und Preisänderungen nötig." + }, + { + "id": "StRS-050", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Reportverwaltung und zeitgesteuerter Reportversand", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-046, SyRS-085, SwRS-114", + "konsolidierung": "nein", + "pruefidee": "Report für täglich 06:00 Uhr terminieren; am Folgetag muss die erzeugte Datei vorliegen.", + "qm": "", + "uebernahme": "übernehmen - Berichtswesen bleibt erforderlich." + }, + { + "id": "StRS-051", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Mail- und Kalendersynchronisation mit Microsoft Exchange", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-052, SyRS-090, SwRS-120", + "konsolidierung": "nein", + "pruefidee": "Termin im System anlegen und nach einem Synchronisationslauf im Exchange-Kalender nachweisen.", + "qm": "", + "uebernahme": "übernehmen - Kalenderintegration ist Anwendererwartung; das Bugprotokoll weist auf" + }, + { + "id": "StRS-052", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Outlook-Integration für CRM, Tickets und Belege", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-051, SyRS-091, SwRS-121", + "konsolidierung": "nein", + "pruefidee": "Add-In ohne Lizenz starten; die Anmeldung am Web-Service muss abgelehnt werden.", + "qm": "", + "uebernahme": "übernehmen - Outlook-Integration ist im Zielmarkt erwartet." + }, + { + "id": "StRS-053", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Telefonanbindung mit Gesprächsprotokollierung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-092, SwRS-122", + "konsolidierung": "nein", + "pruefidee": "Eingehenden Anruf einer bekannten Nummer simulieren; es muss ein Gesprächsprotokoll mit", + "qm": "", + "uebernahme": "übernehmen - CTI-Integration ist im Servicegeschäft üblich; TAPI selbst ist als" + }, + { + "id": "StRS-054", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Marketingkampagnen mit Phasen und Teilnehmerverwaltung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-005, SyRS-093, SwRS-123", + "konsolidierung": "nein", + "pruefidee": "Kampagne mit zwei Phasen und einem Teilnehmer anlegen; nach der Phasenaktion muss der", + "qm": "", + "uebernahme": "übernehmen - Kampagnenmanagement bleibt fachlich relevant." + }, + { + "id": "StRS-055", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Digitale Dokumentfreigabe und Signatur", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-044, SyRS-094, SwRS-124", + "konsolidierung": "nein", + "pruefidee": "Dokument freigeben, über den Link bestätigen und prüfen, dass die Signatur im PDF verifizierbar ist.", + "qm": "", + "uebernahme": "übernehmen - Digitale Freigabeprozesse sind im Zielbild wichtig." + }, + { + "id": "StRS-056", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "KI-gestützte Unterstützung im Arbeitsalltag", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, SyRS-095, SwRS-125", + "konsolidierung": "nein", + "pruefidee": "Benutzer mit Lizenz aber ohne Recht anmelden; die KI-Einstellungsseite darf nicht erscheinen.", + "qm": "", + "uebernahme": "übernehmen - KI-Unterstützung ist strategisch; die konkrete Anbindung ist im" + }, + { + "id": "StRS-057", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Betrieb wahlweise mit direkter Datenbankverbindung oder über den Web-Service", + "typ": "nicht-funktional", + "belege": [ + "KONTEXT", + "SEKUNDÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-100, SwRS-130", + "konsolidierung": "Kandidat: SwRS-130 - Die doppelte Implementierung jeder Operation als BLLogic und", + "pruefidee": "Dasselbe Modul einmal mit `SqlServer`- und einmal mit `CentronWebServices`-Verbindung", + "qm": "Übertragbarkeit (Anpassbarkeit)", + "uebernahme": "veraltet - Im SaaS-Zielbild gibt es keine direkte Datenbankverbindung vom Client;" + }, + { + "id": "StRS-058", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Deutschsprachige Oberfläche mit englischer Alternative", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-101, SwRS-131", + "konsolidierung": "nein", + "pruefidee": "Oberfläche auf Englisch umstellen und stichprobenartig prüfen, dass keine deutschen", + "qm": "Benutzbarkeit (Erlernbarkeit, Zugänglichkeit)", + "uebernahme": "übernehmen - Zweisprachigkeit bleibt erforderlich." + }, + { + "id": "StRS-059", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Betrieb in Containern und auf Linux", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-102, SwRS-132", + "konsolidierung": "nein", + "pruefidee": "Container starten und die Ausgabe eines Datums auf deutsches Format prüfen.", + "qm": "Übertragbarkeit (Installierbarkeit)", + "uebernahme": "übernehmen - Containerbetrieb ist Voraussetzung für SaaS." + }, + { + "id": "StRS-060", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Schutz vor versehentlicher Außenwirkung in Entwicklungsumgebungen", + "typ": "nicht-funktional", + "belege": [ + "KONTEXT", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-103, SwRS-133", + "konsolidierung": "nein", + "pruefidee": "DEBUG-Build eine Mail an eine externe Adresse senden lassen und im Mailcatcher prüfen,", + "qm": "Zuverlässigkeit (Fehlertoleranz)", + "uebernahme": "übernehmen - Umgebungstrennung ist im SaaS-Betrieb noch wichtiger." + }, + { + "id": "StRS-061", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Nutzungstelemetrie", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-104, SwRS-134", + "konsolidierung": "nein", + "pruefidee": "Modul aufrufen und prüfen, dass in `ApplicationUserStatistics` ein Eintrag entsteht.", + "qm": "Wartbarkeit (Analysierbarkeit)", + "uebernahme": "übernehmen - Nutzungsdaten steuern die Produktentwicklung; im SaaS-Betrieb ist die" + }, + { + "id": "StRS-062", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Vorgabe der Vertragsabrechnung durch bewusst deaktivierte Funktionen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, SwRS-135", + "konsolidierung": "nein", + "pruefidee": "Prüfen, dass weder c-time-Einstellungen noch das Reisekostenmodul in der Oberfläche erscheinen.", + "qm": "", + "uebernahme": "veraltet - Für die Neuimplementierung sind beide Funktionen nicht zu übernehmen," + }, + { + "id": "StRS-063", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Interne Sonderfunktionen des Herstellers", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, SyRS-105, SwRS-136", + "konsolidierung": "nein", + "pruefidee": "Kundeninstallation starten; Projektverwaltung, Inspektor und Testmodul dürfen nicht erscheinen.", + "qm": "", + "uebernahme": "Sonderfall - Herstellerinterne Module sind kundenseitig nicht zu übernehmen." + }, + { + "id": "StRS-064", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Direkter SQL-Zugriff für Administratoren", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-037, SyRS-106, SwRS-137", + "konsolidierung": "nein", + "pruefidee": "Benutzer ohne `SQL_MANAGER` anmelden; das Modul darf nicht erscheinen.", + "qm": "", + "uebernahme": "veraltet - Ein direkter SQL-Zugriff aus der Anwendung heraus ist in einer" + }, + { + "id": "StRS-065", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Zugriff externer Systeme über technische Anwendungen", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-002, StRS-039, SyRS-107, SwRS-138", + "konsolidierung": "nein", + "pruefidee": "Benutzer mit `RIGHT_DISALLOW_SERVICEBOARD_LOGIN` am ServiceBoard anmelden; die Anmeldung", + "qm": "", + "uebernahme": "übernehmen - Technische Zugänge für Fremdsysteme bleiben nötig; im Zielsystem als" + } +] \ No newline at end of file diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/anforderungen.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/anforderungen.md new file mode 100644 index 00000000..d0384d61 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/anforderungen.md @@ -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 %) | + diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/before.txt b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/before.txt new file mode 100644 index 00000000..8b137891 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/before.txt @@ -0,0 +1 @@ + diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/combined_prompt.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/combined_prompt.md new file mode 100644 index 00000000..947dc184 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/combined_prompt.md @@ -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: - +Titel: +Ebene: +Typ: +Qualitätsmerkmal: +Akteur: +Vorbedingung: +Fakt: +Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage) +Ergebnis: +Belege: + - [PRIMÄR] - Begründung: + - [SEKUNDÄR] <...> - Begründung: <...> + - [KONTEXT] <...> - Begründung: <...> +Prüfidee: +Tracelinks: +Konsolidierung: > +Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - +Status: +``` + +### 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). diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/endzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/endzeit.txt new file mode 100644 index 00000000..bce9a99a --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/endzeit.txt @@ -0,0 +1 @@ +2026-08-26T20:31:17.3017181+02:00 diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/startzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/startzeit.txt new file mode 100644 index 00000000..4297f804 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_195958_v7.0.0-e7e6/_meta/startzeit.txt @@ -0,0 +1 @@ +2026-08-26T20:00:06.7195929+02:00 diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Analysebericht.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Analysebericht.md new file mode 100644 index 00000000..eee803ef --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Analysebericht.md @@ -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). diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Glossar.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Glossar.md new file mode 100644 index 00000000..103b9b12 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Glossar.md @@ -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`.* diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Hypothesen.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Hypothesen.md new file mode 100644 index 00000000..d6b505eb --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Hypothesen.md @@ -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 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. diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/StRS.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/StRS.md new file mode 100644 index 00000000..610fae12 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/StRS.md @@ -0,0 +1,1362 @@ +# StRS — Stakeholder Requirements Specification + +**System:** c-entron ERP-Suite (Reverse Requirements Engineering aus der Codebasis) +**Norm:** ISO/IEC/IEEE 29148:2018, Abschnitt Stakeholder Requirements Specification +**Ebene:** fachliche Sicht — Akteure, Geschäftsziele, geforderte Fähigkeiten des Zielsystems + +## Akteure (aus der Codebasis abgeleitet) + +| Akteur | Herkunft des Belegs | +|---|---| +| Innendienst / Sachbearbeiter Vertrieb | Rechtebaum `UserRightsConst.Sales.Customer.CustomerCommon` | +| Servicetechniker / Helpdesk-Mitarbeiter | Rechtebaum `UserRightsConst.Sales.Customer.Helpdesk` | +| Einkäufer | Rechtebaum `UserRightsConst.Purchase` | +| Lagerist / Logistik | Rechtebaum `UserRightsConst.Logistic`, `Purchase.StockList` | +| Buchhalter / Controller | Rechtebaum `UserRightsConst.Controlling.Finances` | +| Administrator | Rechtebaum `UserRightsConst.Administration` | +| Geschäftsführung | Rechtebaum `UserRightsConst.Controlling.Analytics` | +| Kunde (Web-Benutzer) | Entität `WebAccount`, `WebAccountRightsConst` | +| Fremdsystem (EDI, RMM, Distributor, Bank) | `src/apis/`, `src/backend/Centron.BL/EDI/`, `DataExchange/` | +| Lizenzgeber (c-entron software gmbh) | `LicenseManager`, `ApplicationKind` | + +--- + +``` +ID: StRS-001 +Titel: Zentraler Geschäftspartnerstamm +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Der Benutzer besitzt das Recht auf den Adressstamm. +Fakt: Es existiert eine Entität `Account` mit den Ausprägungen Kunde, Lieferant und Interessent (`AccountBL`, Tabellen `Accounts`, `AccountCustomers`, `AccountSuppliers`, `AccountTypeToAccounts`); parallel besteht der ältere Kundenstamm (`Kunden`) und Lieferantenstamm (`Kreditor`). +Aussage: Das System soll alle Geschäftspartner in einem gemeinsamen Stamm führen und ihnen eine oder mehrere Rollen (Kunde, Lieferant, Interessent) zuordnen können. +Ergebnis: Ein Geschäftspartner ist einmal erfasst und in allen Rollen auffindbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Accounts/AccountBL.cs` - Begründung: enthält die Anlage- und Rollenlogik der Account-Entität einschließlich der Rechteprüfung `CREATE_CUSTOMER`. + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `Accounts`, `AccountCustomers`, `AccountSuppliers`, `AccountTypeToAccounts` - Begründung: die Rollenzuordnung ist als eigene Zuordnungstabelle im Schema durchgesetzt. + - [KONTEXT] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Adressen/CRM" - Begründung: Modul `AccountManagementAppModuleController` wird nur aktiviert, wenn `CrmSettings.IsAccountManagementActive` gesetzt ist, das Altmodul andernfalls. +Prüfidee: Ein Geschäftspartner wird als Kunde angelegt und zusätzlich als Lieferant markiert; er muss in beiden Suchen mit derselben Account-ID erscheinen. +Tracelinks: SyRS-001, SyRS-002, SwRS-001, SwRS-002 +Konsolidierung: Kandidat: StRS-002 — Account-Stamm und Alt-Kundenstamm (`Kunden`/`Kreditor`) bilden denselben fachlichen Gegenstand in zwei Datenhaltungen ab. +Übernahmewürdigkeit: übernehmen - der einheitliche Partnerstamm ist die fachlich gewollte Zielstruktur. +Status: belegt +``` + +``` +ID: StRS-002 +Titel: Parallelbetrieb von Alt-Kundenstamm und Account-Stamm +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Die Einstellung `IsAccountManagementActive` ist gesetzt oder nicht gesetzt. +Fakt: `ModuleRegistration.cs` registriert entweder `AccountManagementAppModuleController` (Alt-Adressstamm) oder `CrmAppModuleController` (Account-Stamm), gesteuert über `CentronCache.Instance.CrmSettings.IsAccountManagementActive`; beide greifen auf getrennte Tabellen zu. +Aussage: Das System soll pro Installation genau eine der beiden Kundenstamm-Ausprägungen aktivieren und die jeweils andere Oberfläche ausblenden. +Ergebnis: Der Anwender sieht nur die für seine Installation gültige Kundenstamm-Oberfläche. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Adressen/CRM", Bedingung `() => !CentronCache.Instance.CrmSettings.IsAccountManagementActive.GetValueOrDefault(false)` - Begründung: die Bedingung schaltet das Modul tatsächlich frei oder nicht. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Customers/` und `src/backend/Centron.BL/Accounts/` - Begründung: zwei getrennte Business-Logic-Bäume für denselben fachlichen Gegenstand. +Prüfidee: Umschalten der Einstellung muss genau eines der beiden Module verfügbar machen. +Tracelinks: StRS-001, SyRS-002, SwRS-002 +Konsolidierung: Kandidat: StRS-001 — im Zielsystem ist nur ein Partnerstamm vorzusehen. +Übernahmewürdigkeit: Workaround - der Parallelbetrieb ist eine Migrationsbehelfslösung und im Zielsystem nicht nachzubilden. +Status: belegt +``` + +``` +ID: StRS-003 +Titel: Durchgängige Belegkette vom Angebot zur Rechnung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Vorgängerbeleg existiert und ist nicht vollständig weitergeführt. +Fakt: `ReceiptBL.ForwardReceipt` überführt Positionen eines Belegs in einen Folgebeleg und prüft dabei Empfänger, Kunde, Liefer- und Zahlungskonditionen, abweichende Adressen, Filiale, Provision und Mandat. +Aussage: Das System soll Belege aufeinander aufbauend weiterführen, sodass Positionen, Konditionen und Adressen ohne Neuerfassung in den Folgebeleg übernommen werden. +Ergebnis: Der Folgebeleg enthält die übernommenen Positionen und verweist auf den Ursprungsbeleg. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Methode `ForwardReceipt`, Zeilen 1548 ff., Regionen „Validate Forwarding", „Validate Receiver", „Validate Delivery Conditions", „Payment Conditions" - Begründung: die Methode enthält die tatsächlichen Übernahme- und Prüfregeln. + - [KONTEXT] `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitt „Receipt Types Hierarchy" - Begründung: dokumentiert die sieben Belegarten und ihre Tabellen. +Prüfidee: Ein Angebot mit drei Positionen wird zum Auftrag weitergeführt; der Auftrag muss dieselben drei Positionen und die Zahlungskondition des Angebots tragen. +Tracelinks: SyRS-010, SyRS-011, SwRS-010, SwRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die Belegkette ist Kern des Vertriebsprozesses. +Status: belegt +``` + +``` +ID: StRS-004 +Titel: Angebotserstellung mit Bewertung der Abschlusswahrscheinlichkeit +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: Ein Angebot ist angelegt. +Fakt: `ReceiptBL.UpdateOfferClassification` setzt Projektende, Produktgruppen-Klassifikation und Wahrscheinlichkeits-Klassifikation an einem Angebot unter Prüfung der `concurrencyControlGuid`. +Aussage: Das System soll Angebote nach Produktgruppe und Abschlusswahrscheinlichkeit klassifizieren und mit einem erwarteten Projektende versehen können. +Ergebnis: Die Angebotsklassifikation steht für Vertriebsauswertungen zur Verfügung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateOfferClassification`, Zeile 6943 - Begründung: setzt die Klassifikationsfelder und ist die durchsetzende Stelle. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/Classifications/` - Begründung: enthält die Klassifikationsstammdaten. +Prüfidee: Angebot mit Wahrscheinlichkeit „hoch" klassifizieren; die Angebotsauswertung muss es in der entsprechenden Kategorie ausweisen. +Tracelinks: SyRS-012, SwRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Grundlage der Vertriebssteuerung. +Status: belegt +``` + +``` +ID: StRS-005 +Titel: Fakturierung erbrachter Leistungen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Eine abzurechnende Leistung (Lieferung, Ticketzeit, Vertragsperiode) liegt vor. +Fakt: Rechnungen werden als eigener Belegtyp `ReceiptInvoice` (Tabelle `RechKopf`, Sicht `Invoices`) geführt; die Anlage prüft das Recht `Invoice.CREATE_NEW_INVOICE`. +Aussage: Das System soll aus Lieferungen, Ticketzeiten und Verträgen Rechnungen erzeugen und diese als eigenständige, versionierte Belege führen. +Ergebnis: Eine Rechnung mit eindeutiger Nummer, Datum und Positionen liegt vor. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, `HasRightToCreateANewReceipt`, Zeile 521 - Begründung: benennt die durchsetzende Rechteprüfung `CREATE_NEW_INVOICE` bei der Rechnungsanlage. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Zeile 3604 - Begründung: ruft die Rechteprüfung vor dem Speichern eines neuen Belegs auf. + - [KONTEXT] `docs/reference/receipts/receipts-backend-architecture.md` - Begründung: dokumentiert die Tabellen- und Sichtstruktur der Rechnung. +Prüfidee: Ein Benutzer ohne Recht `CREATE_NEW_INVOICE` muss beim Speichern einer neuen Rechnung eine Fehlermeldung erhalten und es darf kein Datensatz entstehen. +Tracelinks: SyRS-020, SyRS-021, SwRS-020, SwRS-021 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kernfunktion. +Status: belegt +``` + +``` +ID: StRS-006 +Titel: Gutschriften als wertmäßige Korrektur +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Eine Rechnung ist erstellt und ganz oder teilweise zu korrigieren. +Fakt: Es existiert der Belegtyp Gutschrift (`GutKopf`/`GutPos`, Sicht `CreditVouchers`, `AnlageArt` = 6) mit eigenem Rechtebaum `CustomerCommon.CreditVoucher`. +Aussage: Das System soll Gutschriften als eigenständigen Belegtyp führen, der auf die korrigierte Rechnung Bezug nimmt. +Ergebnis: Der Wert der Gutschrift steht für den Ausgleich offener Posten zur Verfügung. +Belege: + - [PRIMÄR] `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs`, Klasse `CustomerCommon.CreditVoucher`, Zeile 2331 - Begründung: eigener Rechtezweig belegt die Gutschrift als eigenständigen Geschäftsvorfall. + - [SEKUNDÄR] `docs/reference/receipts/receipts-backend-architecture.md`, Tabelle „AnlageArt Values", Wert 6 = Credit Voucher - Begründung: benennt die Typkennung im gemeinsamen Protokoll. +Prüfidee: Eine Gutschrift zu einer Rechnung anlegen; der offene Posten der Rechnung muss sich um den Gutschriftbetrag verringern lassen. +Tracelinks: SyRS-022, SwRS-022 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - handelsrechtlich erforderlich. +Status: belegt +``` + +``` +ID: StRS-007 +Titel: Abholscheine und Barverkauf +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst / Kasse +Vorbedingung: Ein Kunde holt Ware unmittelbar ab. +Fakt: Es existieren der Belegtyp Abholschein (`AbholKopf`/`AbholPos`, `AnlageArt` = 5) sowie die Nummernkreise `CashOffer` (20) und `CashInvoice` (21) für Barangebot und Barrechnung. +Aussage: Das System soll Abholvorgänge als eigenen Belegtyp und Barverkäufe über eigene Nummernkreise abbilden. +Ergebnis: Der Abholvorgang ist als Beleg dokumentiert und nummeriert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs`, Werte `PickupList = 5`, `CashOffer = 20`, `CashInvoice = 21` - Begründung: eigene Nummernkreise sind die durchgesetzte Unterscheidung der Vorgangsarten. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/PickUps/`, `PickupLists/` - Begründung: eigene Logikbäume für Abholvorgänge. + - [SEKUNDÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `Sales.Cashbox.BarInvoice`, Zeile 1917 - Begründung: eigener Rechtezweig für Barrechnungen. +Prüfidee: Ein Barverkauf muss eine Nummer aus dem Nummernkreis `CashInvoice` erhalten, nicht aus `Invoice`. +Tracelinks: SyRS-023, SwRS-023, SyRS-060 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Barverkauf ist im Fachhandel weiterhin erforderlich. +Status: belegt +``` + +``` +ID: StRS-008 +Titel: Serviceverträge mit wiederkehrender Abrechnung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertragsverwaltung +Vorbedingung: Zwischen Anbieter und Kunde besteht eine dauerhafte Leistungsvereinbarung. +Fakt: Die Entität `ReceiptContract` führt `BillingIntervalKind`, `BillingIntervalDuration`, `BillingKind`, `AutomatedBilling`, `ContractEnd`, `AutomatedProlongation` sowie Kontingentfelder. +Aussage: Das System soll Serviceverträge mit Abrechnungsintervall, Laufzeit, automatischer Verlängerung und Leistungskontingent führen. +Ergebnis: Der Vertrag ist Grundlage wiederkehrender Rechnungen und der Kontingentverrechnung. +Belege: + - [PRIMÄR] `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs` - Begründung: die Felder für Intervall, Laufzeit und Kontingent sind dort als persistierte Eigenschaften definiert. + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs`, `GetContingentRest`, Zeile 60 - Begründung: berechnet das Restkontingent und ist damit die durchsetzende Stelle der Kontingentregel. + - [KONTEXT] `docs/reference/receipts/contracts-backend.md`, Abschnitte „Billing Configuration" und „Contingent Management" - Begründung: beschreibt die Feldsemantik. +Prüfidee: Vertrag mit `BillingIntervalKind = Monthly` und `BillingIntervalDuration = 3` muss quartalsweise zur Abrechnung vorgeschlagen werden. +Tracelinks: SyRS-030, SyRS-031, SwRS-030, SwRS-031 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - tragendes Geschäftsmodell des Systemhauses. +Status: belegt +``` + +``` +ID: StRS-009 +Titel: Automatische Erzeugung von Vertragsrechnungen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Verträge mit `AutomatedBilling` sind fällig. +Fakt: `AutomaticFacturaBL.SearchCustomers(DateTime BilledTo)` und `SearchBillingOrders`/`SearchBillingDeliveryLists` ermitteln über benannte Abfragen (`GetCustomersForAutomatedBilling`, `GetContractsForAutomatedBillingLight`, `GetOrdersForAutomatedBilling`) die zur Abrechnung anstehenden Vorgänge. +Aussage: Das System soll zu einem Stichtag alle fälligen Verträge, Aufträge und Lieferscheine ermitteln und daraus Rechnungen erzeugen. +Ergebnis: Für jeden fälligen Vorgang liegt ein Rechnungsvorschlag beziehungsweise eine Rechnung vor. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `SearchCustomers`, Zeile 451, und `SearchBillingOrders`, Zeile 114 - Begründung: die Methoden führen die Fälligkeitsermittlung tatsächlich aus. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling/` - Begründung: die Bedienoberfläche des Abrechnungslaufs. +Prüfidee: Ein Vertrag mit Abrechnung zum Monatsende muss beim Lauf mit Stichtag Monatsende in der Vorschlagsliste erscheinen, beim Lauf zum Monatsanfang nicht. +Tracelinks: StRS-008, SyRS-032, SwRS-032 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - ohne Automatik ist das Vertragsgeschäft nicht wirtschaftlich zu betreiben. +Status: belegt +``` + +``` +ID: StRS-010 +Titel: Abrechnung nach Zählerständen (Klickabrechnung) +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertragsverwaltung +Vorbedingung: Ein Vertrag ist mit zählenden Geräten verknüpft. +Fakt: Es existieren ein eigener Modulzweig `Contracts/ClickContracts`, ein Einstellungsdialog `ClickBillingSettingsController` sowie das Modul `DeviceClickCounter`; Stammblätter führen das Feld `CounterDevice`. +Aussage: Das System soll Zählerstände von Geräten erfassen und daraus mengenabhängige Vertragsrechnungen erzeugen. +Ergebnis: Die abgerechnete Menge entspricht der Differenz der Zählerstände im Abrechnungszeitraum. +Belege: + - [PRIMÄR] `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs`, Eigenschaft `CounterDevice` - Begründung: der Zählerstand ist am Stammblatt persistiert und damit die Abrechnungsgrundlage. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Finances/Contracts/Settings/ClickBilling/`, `Modules/Finances/DeviceClickCounter/` - Begründung: eigene Einstellungs- und Erfassungsmodule für die Klickabrechnung. + - [KONTEXT] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Verträge", Kommentar „Klick-Zählerverwaltung" - Begründung: benennt das Modul fachlich. +Prüfidee: Zwei aufeinanderfolgende Zählerstände erfassen; die erzeugte Rechnungsposition muss die Differenz als Menge tragen. +Tracelinks: StRS-008, SyRS-033, SwRS-033 +Konsolidierung: Kandidat: StRS-032 — Zählerstände werden sowohl über Stammblätter als auch über die docuFORM-Anbindung geführt. +Übernahmewürdigkeit: übernehmen - Standardgeschäftsmodell im Managed-Print-Umfeld. +Status: belegt +``` + +``` +ID: StRS-011 +Titel: Pauschalabrechnung von Projekten +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Projektleitung +Vorbedingung: Für ein Projekt ist eine Pauschale statt einer Aufwandsabrechnung vereinbart. +Fakt: Das Modul `FlatRateProjectAppModuleController` wird registriert, wenn die Rechte `Sales.ID`, `CustomerCommon.Order.ID` und `Sales.FLATRATE_BILLING_MODULE` vorliegen und die Lizenz `FlatRateBilling` oder `Centron` besteht; `ArticleBL.GetFlatrateBalanceArticle` liefert den Ausgleichsartikel. +Aussage: Das System soll Projekte pauschal abrechnen und die Differenz zum tatsächlichen Aufwand über einen Ausgleichsartikel darstellen. +Ergebnis: Die Pauschalrechnung ist erstellt, der Aufwandsüberhang ist als Ausgleichsposition sichtbar. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Abrechnung", Registrierung `FlatRateProjectAppModuleController` mit `Helper.HasRights(…FLATRATE_BILLING_MODULE)` - Begründung: die Rechte- und Lizenzbedingung schaltet das Modul tatsächlich frei. + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `GetFlatrateBalanceArticle`, Zeile 143 - Begründung: benennt den für die Pauschalabrechnung reservierten Ausgleichsartikel. +Prüfidee: Ohne das Recht `FLATRATE_BILLING_MODULE` darf das Modul „Pauschalabrechnung" nicht im Menü erscheinen. +Tracelinks: SyRS-034, SwRS-034 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - eigenständiges Abrechnungsmodell. +Status: belegt +``` + +``` +ID: StRS-012 +Titel: Abrechnung erfasster Ticketzeiten +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Für Tickets sind Zeiten erfasst und nicht abgerechnet. +Fakt: `TimerBillingBL.SearchTimers(TimerBillingFilter)` liefert abrechenbare Zeiteinträge, `ReceiptBL.CreateNewReceiptForHelpdekTimers(IList timerI3Ds, TimerBillingSettingsDTO settings, AppUser)` erzeugt daraus einen Beleg. +Aussage: Das System soll erfasste Ticketzeiten sammeln, nach Kunde und Vertrag gruppieren und daraus abrechnungsfähige Belege erzeugen. +Ergebnis: Die abgerechneten Zeiteinträge sind mit dem erzeugten Beleg verknüpft und nicht erneut abrechenbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CreateNewReceiptForHelpdekTimers`, Zeile 5295 - Begründung: erzeugt den Abrechnungsbeleg aus den Zeiteinträgen. + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs`, `SearchTimers`, Zeile 233, und `UpdateOrderItems`, Zeile 599 - Begründung: selektiert abrechenbare Zeiten und verknüpft sie mit Auftragspositionen. +Prüfidee: Ein bereits abgerechneter Zeiteintrag darf in einem zweiten Abrechnungslauf nicht mehr als abrechenbar erscheinen. +Tracelinks: StRS-014, SyRS-035, SwRS-035 +Konsolidierung: Kandidat: StRS-011 — Pauschal- und Zeitabrechnung erzeugen beide Abrechnungsbelege aus Leistungsdaten über getrennte Module. +Übernahmewürdigkeit: übernehmen - Kern des Dienstleistungsgeschäfts. +Status: belegt +``` + +``` +ID: StRS-013 +Titel: Provisionsabrechnung für Vertriebsmitarbeiter +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertriebsleitung +Vorbedingung: Provisionsschemata sind definiert und Kunden zugeordnet. +Fakt: Es bestehen die Klassen `ReceiptProvisionSchemaBL`, `ReceiptProvisionEmployeeGoalBL`, `ReceiptProvisionEmployeeLevelBL` sowie drei getrennte Module (Provisionsauswertung, Schemaverwaltung, Kundenzuordnung), deren Registrierung sich gegenseitig ausschließt. +Aussage: Das System soll Provisionsschemata, Mitarbeiterziele und Provisionsstufen verwalten und daraus je Beleg einen Provisionsanspruch ermitteln. +Ergebnis: Je Mitarbeiter und Zeitraum liegt ein nachvollziehbarer Provisionsbetrag vor. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptProvisionSchemaBL.cs`, `ReceiptProvisionEmployeeGoalBL.cs`, `ReceiptProvisionEmployeeLevelBL.cs` - Begründung: die drei Klassen bilden Schema, Ziel und Stufe als eigenständige Regelträger ab. + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Abrechnung", Bedingung `!Helper.HasRights(PROVISION_EVALUATION_MODULE) && Helper.HasRights(PROVISION_SCHEMA_MANAGEMENT)` - Begründung: die Ausschlussbedingung ist im Code durchgesetzt. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Provision" innerhalb von `ForwardReceipt`, Zeile 2813 - Begründung: die Provisionsangabe wird beim Weiterführen mitgeführt. +Prüfidee: Ein Benutzer mit dem Recht `PROVISION_EVALUATION_MODULE` darf die Schemaverwaltung nicht zusätzlich als eigenes Modul sehen. +Tracelinks: SyRS-036, SwRS-036 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Vergütungsrelevant. +Status: belegt +``` + +``` +ID: StRS-014 +Titel: Erfassung und Nachweis von Arbeitszeiten am Ticket +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Ein Ticket ist geöffnet. +Fakt: `HelpdeskTimeRecordingBL` stellt `StartRecording`, `PauseRecording`, `ResumeRecording`, `StopRecording` und `ClearRecording` bereit; jeder Vorgang kann einen Historieneintrag erzeugen. +Aussage: Das System soll Arbeitszeiten am Ticket per Stoppuhr starten, unterbrechen, fortsetzen und beenden können und die Vorgänge nachvollziehbar protokollieren. +Ergebnis: Ein Zeiteintrag mit Beginn, Ende und Pausen liegt am Ticket vor. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimeRecordingBL.cs`, `StartRecording` (Zeile 172), `PauseRecording` (277), `ResumeRecording` (317), `StopRecording` (357) - Begründung: die Methoden realisieren die Zustandsübergänge der Zeiterfassung. + - [SEKUNDÄR] `CentronRights.md`, Abschnitt „7. Zeiten bearbeiten" - Begründung: beschreibt die zugehörige Rechtesteuerung fachlich. +Prüfidee: Eine gestartete und pausierte Erfassung darf nach dem Fortsetzen die Pausenzeit nicht als Arbeitszeit ausweisen. +Tracelinks: SyRS-040, SyRS-041, SwRS-040, SwRS-041 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Grundlage der Leistungsabrechnung. +Status: belegt +``` + +``` +ID: StRS-015 +Titel: Bestätigung erbrachter Leistung durch Kundenunterschrift +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Kunde vor Ort +Vorbedingung: Ein Zeiteintrag ist erfasst und noch nicht unterschrieben. +Fakt: `HelpdeskTimerSignatureBL.AddSignature` speichert genau eine Unterschrift je Zeiteintrag (`HelpdeskSignatureExists` verhindert eine zweite) und schreibt einen Protokolleintrag. +Aussage: Das System soll je Zeiteintrag genau eine Kundenunterschrift zulassen und deren Erfassung protokollieren. +Ergebnis: Der Zeiteintrag trägt eine unveränderliche Unterschrift und einen Protokolleintrag. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs`, `AddSignature` Zeile 31 mit Prüfung `HelpdeskSignatureExists` Zeile 62 - Begründung: die Existenzprüfung ist die durchsetzende Stelle der Einmaligkeit. + - [SEKUNDÄR] `CentronRights.md`, Abschnitt „7.2 Unterschrift aus Zeit löschen" - Begründung: das Löschen ist an ein eigenes Recht gebunden, was die Schutzwürdigkeit der Unterschrift belegt. +Prüfidee: Ein zweiter Unterschriftsversuch am selben Zeiteintrag muss abgewiesen werden. +Tracelinks: StRS-014, SyRS-042, SwRS-042 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Nachweis gegenüber dem Kunden. +Status: belegt +``` + +``` +ID: StRS-016 +Titel: Bearbeitung von Servicetickets +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Helpdesk-Mitarbeiter +Vorbedingung: Ein Kundenanliegen liegt vor. +Fakt: Die Entität `Helpdesk` (Tabelle `hlpdsk_requests`) wird über `HelpdeskBL.Save` gespeichert; die Anlage prüft `ADD_NEW_HELPDESK`, die Bearbeitung `EDIT_HELPDESK`. +Aussage: Das System soll Kundenanliegen als Tickets erfassen, klassifizieren, zuweisen und bis zum Abschluss verfolgen. +Ergebnis: Das Ticket ist mit Kunde, Kategorie, Typ, Status, Priorität und Bearbeiter dokumentiert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckUserRigths`, Zeilen 418-431 - Begründung: die Methode setzt die Rechte für Anlage und Bearbeitung durch. + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `hlpdsk_requests`, `hlpdsk_typen`, `hlpdsk_kategorien`, `hlpdsk_status`, `hlpdsk_prioritaeten` - Begründung: die Klassifikationsdimensionen sind als eigene Tabellen im Schema angelegt. + - [KONTEXT] `CentronRights.md`, Abschnitte 1 bis 3 - Begründung: beschreibt die Sichtbarkeits- und Bearbeitungsrechte fachlich. +Prüfidee: Ein Benutzer ohne `EDIT_HELPDESK` muss beim Speichern eines bestehenden Tickets die Meldung „Sie haben nicht das Recht ‚Ticket bearbeiten'" erhalten. +Tracelinks: SyRS-050, SyRS-051, SwRS-050, SwRS-051 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kernprozess des Servicegeschäfts. +Status: belegt +``` + +``` +ID: StRS-017 +Titel: Abgestufte Sichtbarkeit von Tickets +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Helpdesk-Mitarbeiter, Kunde (Web-Benutzer) +Vorbedingung: Der Benutzer ist angemeldet. +Fakt: `HelpdeskBL.GetLoggedInUserShowHelpdeskRight` liefert `All`, `OnlyOwn`, `OnlyOwnBranch`, `OnlyOwnAndNotify` oder `None`, abhängig von den Rechten `SHOW_HELPDESK`, `SHOW_HELPDESK_ONLY_OWN`, `SHOW_HELPDESK_ONLY_OWN_BRANCH` beziehungsweise den Web-Rechten `SHOWONLYOWNREQUESTS`, `WEBRIGHT_SHOWONLYNOTIFYTICKETS`, `SHOWALLEREQUESTS`, `CUSTOMERADMINISTRATOR`. +Aussage: Das System soll den Umfang der sichtbaren Tickets je Benutzer auf „alle", „eigene", „eigene Filiale" oder „keine" einschränken und Web-Benutzer über ein eigenes Rechtesystem steuern. +Ergebnis: Ein Benutzer sieht ausschließlich die Tickets seines zulässigen Umfangs. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `GetLoggedInUserShowHelpdeskRight`, Zeilen 233-295 - Begründung: die Methode wertet die Rechte aus und liefert die Sichtbarkeitsstufe, die die Ticketabfragen einschränkt. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `CheckWebRightsFromUser` mit SQL auf `WebAccountsRights` - Begründung: die Web-Rechteprüfung erfolgt als eigene, durchgesetzte Abfrage. + - [KONTEXT] `CentronRights.md`, Abschnitte 1.1 und 1.2 („restricting right") - Begründung: erläutert die einschränkende Wirkung der Rechte. +Prüfidee: Ein Benutzer mit `SHOW_HELPDESK` und `SHOW_HELPDESK_ONLY_OWN` darf ein Ticket eines Kollegen weder in der Liste noch über die Direktsuche öffnen können. +Tracelinks: StRS-016, StRS-031, SyRS-052, SwRS-052 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - datenschutz- und mandantenrelevant. +Status: belegt +``` + +``` +ID: StRS-018 +Titel: Retouren-, Reparatur- und Tauschabwicklung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Werkstatt +Vorbedingung: Ein Gerät wird zur Reparatur oder Rücksendung angenommen. +Fakt: `RmaBL` führt die Zustände `RmaClosedState` (Open, Deleted), `RmaArticleState` (u. a. `AdvanceDeliveryList`, `BackDeliveryList`, `BackDeliveryListFromBooking`, `Rebooked`) und schreibt bei jedem Übergang einen `SaveRmaHistory`-Eintrag; Barcodes wechseln dabei zwischen `InStock`, `InRequest`, `InDeliveryList`, `InInvoice`, `ManuallyBookedOut`. +Aussage: Das System soll Retouren- und Reparaturvorgänge mit Zustandsverfolgung je Artikel und Seriennummer abwickeln und jede Zustandsänderung historisieren. +Ergebnis: Der Verbleib jedes Gerätes ist über Barcode-Zustand und RMA-Historie nachvollziehbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/CustomerArea/RmaBL.cs`, `SaveRmaHistory` (Zeile 124) sowie die Zustandswechsel `dbBarcode.State = BarcodeState.InInvoice` (Zeile 201) und `BarcodeState.ManuallyBookedOut` (Zeile 266) - Begründung: die Zuweisungen sind die durchsetzenden Stellen der Zustandsmaschine. + - [SEKUNDÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs`, Werte `Reshipment = 8`, `Repairing = 9`, `RepairEntrance = 10`, `RMANumber = 11` - Begründung: eigene Nummernkreise für die Teilvorgänge. +Prüfidee: Nach einem Gerätetausch muss die alte Seriennummer den Zustand `ManuallyBookedOut` und die neue den Zustand `InInvoice` tragen. +Tracelinks: SyRS-053, SwRS-053, StRS-021 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - gesetzliche Gewährleistungsabwicklung. +Status: belegt +``` + +``` +ID: StRS-019 +Titel: Checklisten zur Qualitätssicherung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Für einen Vorgang ist eine Checklistenvorlage hinterlegt. +Fakt: `CentronChecklistBL` und `UpdateChecklistBL` verwalten Checklisten mit Änderungsverfolgung (`CheckListArea/ChangeTracking`); im Webportal existieren `ChecklistsController` und `ChecklistTemplateTreeSelection.razor`. +Aussage: Das System soll Prüf- und Arbeitsschritte als Checkliste an Vorgänge hängen und den Abarbeitungsstand nachvollziehbar festhalten. +Ergebnis: Der Abarbeitungsstand jeder Checkliste ist dokumentiert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs` und `CheckListArea/ChangeTracking/` - Begründung: die Änderungsverfolgung ist als eigener Codezweig realisiert und setzt die Nachvollziehbarkeit durch. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/v1/Tickets/ChecklistsController.cs` - Begründung: die Checkliste ist auch über die REST-Schnittstelle verfügbar. +Prüfidee: Ein abgehakter Checklistenpunkt muss mit Benutzer und Zeitpunkt in der Änderungsverfolgung erscheinen. +Tracelinks: SyRS-054, SwRS-054 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Qualitätsnachweis. +Status: belegt +``` + +``` +ID: StRS-020 +Titel: Aufgabenverwaltung quer zu Tickets +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Eine Aufgabe betrifft mehrere Tickets oder keinen Ticketbezug. +Fakt: Der Modulzweig `TaskManager` im Backend und `Management/TaskManagement` in der Webanwendung führen Tasks mit Detail-, Historien- und Ticketreiter (`TaskTabDetails.razor`, `TaskTabHistory.razor`, `TaskTabTickets.razor`). +Aussage: Das System soll Aufgaben unabhängig von einzelnen Tickets führen und ihnen beliebig viele Tickets zuordnen können. +Ergebnis: Eine Aufgabe bündelt die zugehörigen Tickets und trägt eine eigene Historie. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus/Management/TaskManagement/Components/TaskTabTickets.razor` - Begründung: die Zuordnung mehrerer Tickets zu einer Aufgabe ist als eigene Oberfläche realisiert. + - [SEKUNDÄR] `src/backend/Centron.BL/TaskManager/` - Begründung: zugehörige Geschäftslogik. +Prüfidee: Eine Aufgabe mit zwei zugeordneten Tickets muss in beiden Tickets als verknüpft erscheinen. +Tracelinks: SyRS-055, SwRS-055 +Konsolidierung: Kandidat: StRS-046 — Aufgaben (`TaskManager`) und Todo-Liste (`ToDoArea`) bilden beide zu erledigende Vorgänge in getrennten Datenhaltungen ab. +Übernahmewürdigkeit: übernehmen - Steuerung übergreifender Servicearbeiten. +Status: belegt +``` + +``` +ID: StRS-021 +Titel: Bestandsführung mit Einzelstückverfolgung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lagerist +Vorbedingung: Ein Artikel ist als seriennummernpflichtig gekennzeichnet. +Fakt: Die Tabellen `Barcode`, `SeriennummerToPosition` und die Klassen `BarcodeBL`, `BarcodeHistoryBL`, `BarcodeConditionBL` führen je Einzelstück einen Zustand und eine Historie; `ArticleStockBL` und `StoragePlaceBL` führen Mengenbestände je Lagerplatz. +Aussage: Das System soll Bestände mengenmäßig je Lagerplatz und zusätzlich einzelstückbezogen über Seriennummern führen. +Ergebnis: Zu jedem Einzelstück ist Standort und Zustand bekannt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/BarcodeHistoryBL.cs` und `SSMS_DB_SCHEMA.sql`, Tabellen `Barcode`, `SeriennummerToPosition` - Begründung: Historie und Positionszuordnung sind persistiert und damit durchgesetzt. + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, `StoragePlaceBL.cs` - Begründung: führen die mengenmäßige Bestandsfortschreibung je Lagerplatz. +Prüfidee: Ein Warenausgang eines seriennummernpflichtigen Artikels muss den Barcode-Zustand ändern und einen Historieneintrag erzeugen. +Tracelinks: SyRS-060, SyRS-061, SwRS-060, SwRS-061 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Grundlage von Gewährleistung und Inventur. +Status: belegt +``` + +``` +ID: StRS-022 +Titel: Inventur mit Zählgruppen und Abschluss +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lagerist +Vorbedingung: Eine Inventur ist angelegt. +Fakt: `InventoryNewBL` stellt `CheckInventory`, `CloseStorages(int inventoryI3D, List storageI3Ds, bool isCompleteInventory, LoggedInUser)` und `CloseInventory(int inventoryI3D)` bereit und protokolliert über `GetInventoryLogs`. +Aussage: Das System soll Inventuren je Lager und Zählgruppe durchführen, Lager einzeln abschließen und die Inventur insgesamt abschließen können; alle Schritte sind zu protokollieren. +Ergebnis: Die Inventur ist abgeschlossen und die Differenzen sind nachvollziehbar protokolliert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryNewBL.cs`, `CloseStorages` (Zeile 294), `CloseInventory` (312), `GetInventoryLogs` (326) - Begründung: die Methoden realisieren Abschluss und Protokollierung. + - [SEKUNDÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `Purchase.Inventory`, Zeile 1786 - Begründung: eigener Rechtezweig für die Inventur. +Prüfidee: Nach `CloseInventory` dürfen keine weiteren Zählmengen zur Inventur erfassbar sein. +Tracelinks: StRS-021, SyRS-062, SwRS-062 +Konsolidierung: Kandidat: SwRS-063 — es existieren `InventoryBL` und `InventoryNewBL` als zwei Implementierungen derselben Fachfunktion. +Übernahmewürdigkeit: übernehmen - handelsrechtlich vorgeschrieben. +Status: belegt +``` + +``` +ID: StRS-023 +Titel: Kommissionierung von Aufträgen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lagerist +Vorbedingung: Ein Auftrag mit lagerhaltigen Positionen liegt vor. +Fakt: `OrderCommissionBL` und `PartialCommissionOrderBL` bilden vollständige und Teilkommissionierung ab; `ReceiptBL.UpdateReceiptQuantityPicked(…, IList items)` schreibt die kommissionierte Menge je Position zurück. +Aussage: Das System soll Aufträge vollständig oder teilweise kommissionieren und die kommissionierte Menge je Position führen. +Ergebnis: Je Auftragsposition ist die entnommene Menge dokumentiert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptQuantityPicked`, Zeile 5031 - Begründung: schreibt die Kommissioniermenge unter Prüfung der `concurrencyControlGuid` zurück. + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/Commissions/PartialCommissionOrderBL.cs` - Begründung: realisiert die Teilkommissionierung als eigene Regel. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Warn user when Forwarding an Order to DeliveryList, ignoring the PartialCommissionOrders", Zeile 2669 - Begründung: die Teilkommissionierung wirkt auf die Belegweiterführung. +Prüfidee: Ein teilkommissionierter Auftrag darf beim Weiterführen in einen Lieferschein nur die kommissionierte Menge übernehmen oder eine Warnung erzeugen. +Tracelinks: StRS-003, StRS-021, SyRS-063, SwRS-064 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Logistikkernprozess. +Status: belegt +``` + +``` +ID: StRS-024 +Titel: Beschaffung über Lieferantenbelege +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Ein Beschaffungsbedarf besteht. +Fakt: Es existieren die Belegzweige `SupplierOrders`, `SupplierDeliveryLists`, `SupplierInvoices`, `SupplierCreditVouchers` sowie die Tabellen `BestKopf2`/`BestPos2` (Bestellung), `AnfrKopf`/`AnfrPos` (Anfrage), `WareKopf`/`WarePos` (Wareneingang), `KalkKopf`/`KalkPos` (Kalkulation) und ein eigener Rechtebaum `UserRightsConst.Purchase.Supplier`. +Aussage: Das System soll den Beschaffungsprozess von der Anfrage über die Bestellung und den Wareneingang bis zur Lieferantenrechnung als eigene Belegkette abbilden. +Ergebnis: Jeder Beschaffungsschritt ist belegt und mit dem Vorgängerbeleg verknüpft. +Belege: + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `Purchase.Supplier` mit `Offer`, `Order`, `DeliveryList`, `Invoice`, `CreditVoucher`, `Contract`, Zeilen 1801-1846 - Begründung: die Rechtestruktur setzt die Belegarten der Beschaffungsseite durch. + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `BestKopf2`, `BestPos2`, `AnfrKopf`, `AnfrPos`, `WareKopf`, `WarePos`, `KalkKopf`, `KalkPos` - Begründung: eigene Tabellenfamilien für die Beschaffungsbelege. +Prüfidee: Eine Bestellung ohne Recht `Purchase.Supplier.Order` darf nicht angelegt werden können. +Tracelinks: SyRS-070, SwRS-070 +Konsolidierung: Kandidat: StRS-003 — Verkaufs- und Einkaufsbelegkette sind funktional gleichartig, aber getrennt implementiert. +Übernahmewürdigkeit: übernehmen - Kernprozess. +Status: belegt +``` + +``` +ID: StRS-025 +Titel: Elektronischer Datenaustausch mit Distributoren +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Einkäufer, Distributor +Vorbedingung: Für den Lieferanten ist eine EDI-Konfiguration hinterlegt. +Fakt: Der Zweig `Centron.BL/EDI` enthält je Distributor eine eigene Implementierung (`ALSO`, `Alltron`, `AlsoCH`, `Komsa`, `EGIS`, `Concerto`, `Opentrans21`) sowie `EDIDispatcherBL`, `EDIGatewaySettingBL` und `EDILogBL`. +Aussage: Das System soll Bestellungen elektronisch an Distributoren übermitteln und Auftragsbestätigungen, Lieferscheine und Rechnungen elektronisch zurücknehmen; jede Übertragung ist zu protokollieren. +Ergebnis: Der Bestellvorgang läuft ohne manuelle Erfassung beim Lieferanten und ist protokolliert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs` und `EDILogBL.cs` - Begründung: Verteilung und Protokollierung der EDI-Vorgänge sind dort durchgesetzt. + - [SEKUNDÄR] `docs/reference/edi/edi-architecture.md`, `docs/reference/edi/edi-import-rules.md` - Begründung: dokumentieren Aufbau und Importregeln. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement/` - Begründung: eigene Bedienoberfläche für die EDI-Verwaltung. +Prüfidee: Eine per EDI versandte Bestellung muss einen Eintrag im EDI-Protokoll mit Zeitstempel und Lieferantenbezug erzeugen. +Tracelinks: StRS-024, SyRS-071, SwRS-071 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Wettbewerbsvoraussetzung im IT-Handel. +Status: belegt +``` + +``` +ID: StRS-026 +Titel: Elektronische Rechnungsformate +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Buchhaltung, Behörde +Vorbedingung: Eine Rechnung ist zu versenden oder eingegangen. +Fakt: Es bestehen `EDI/Zugferd/ZUGFeRD_BL.cs` mit `ReadInvoice(List, SupplierEdiConfigurations, …)` und `ZugferdParseBL.cs`, ein `ZugferdImportController` in der REST-Schnittstelle sowie `Centron.Api.EbInterface` für das österreichische Format. +Aussage: Das System soll Rechnungen in den Formaten ZUGFeRD/XRechnung und ebInterface erzeugen und eingehende Rechnungen dieser Formate einlesen. +Ergebnis: Eingehende E-Rechnungen sind maschinell erfasst, ausgehende entsprechen dem geforderten Format. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/EDI/Zugferd/ZUGFeRD_BL.cs`, `ReadInvoice`, Zeile 38 - Begründung: liest ZUGFeRD-Rechnungsdateien tatsächlich ein. + - [PRIMÄR] `src/webservice/Centron.Controllers/Controllers/v1/Receipts/ZugferdImportController.cs` - Begründung: stellt den Import als eigenen REST-Endpunkt bereit. + - [KONTEXT] `docs/guides/development/xrechnung.md`, `docs/reference/zugferd-feldzuordnung-anwender.md` - Begründung: dokumentieren die Feldzuordnung. +Prüfidee: Eine ZUGFeRD-Rechnung mit bekanntem Betrag muss nach dem Import eine Lieferantenrechnung mit demselben Betrag erzeugen. +Tracelinks: StRS-024, StRS-005, SyRS-072, SwRS-072 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - gesetzlich vorgeschrieben (E-Rechnungspflicht). +Status: belegt +``` + +``` +ID: StRS-027 +Titel: Übergabe an die Finanzbuchhaltung +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Buchhaltung, Steuerberater +Vorbedingung: Belege eines Zeitraums sind abgeschlossen. +Fakt: `DataExchange/BookKeeping/BookKeepingExportBL.cs` und `BookKeepingImportBL.cs` bilden Export und Rückimport ab; die Module „Buchhaltungsexport/-import" und „Datev Belegtransfer" sind getrennt registriert; Erlöskonten werden je Filiale und Warengruppe geführt (`WarenFilialeErloeskonto`, `ArtikelBranchErloeskonto`, `UnterwarenFilialeErloeskonto`). +Aussage: Das System soll Belegdaten mit Konten-, Steuer- und Kostenstellenzuordnung an die Finanzbuchhaltung übergeben und Rückmeldungen einlesen. +Ergebnis: Die Buchhaltung erhält vollständige, kontierte Belegdaten. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs` - Begründung: erzeugt die Übergabedaten. + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `WarenFilialeErloeskonto`, `ArtikelBranchErloeskonto`, `UnterwarenFilialeErloeskonto` - Begründung: die filial- und warengruppenabhängige Kontenfindung ist im Schema durchgesetzt. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/DataExchange/BookKeeping/`, `DatevOnline2020/` - Begründung: zwei getrennte Bedienoberflächen für die Buchhaltungsübergabe. +Prüfidee: Ein Beleg einer Filiale mit abweichendem Erlöskonto muss im Export dieses Konto tragen, nicht das Standardkonto. +Tracelinks: StRS-005, SyRS-080, SwRS-080 +Konsolidierung: Kandidat: StRS-027 selbst — „Buchhaltungsexport/-import" und „Datev Belegtransfer" sind zwei Module für dieselbe fachliche Übergabe. +Übernahmewürdigkeit: übernehmen - gesetzlich erforderlich. +Status: belegt +``` + +``` +ID: StRS-028 +Titel: Offene-Posten-Verwaltung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Rechnungen sind gestellt. +Fakt: `OposBL.ThrowIfUserHasInsufficentRights` prüft das Recht `UserRightsConst.Controlling.Finances.Dunning`; `ReceiptBL.UpdateReceiptIsPaid(…, bool? isPaid, decimal? paidFC, …)` setzt den Bezahltstatus und den bezahlten Betrag. +Aussage: Das System soll offene Rechnungen ausweisen und deren Ausgleich mit Betrag und Zeitpunkt erfassen. +Ergebnis: Der Bezahltstatus jeder Rechnung ist aktuell und der offene Betrag bekannt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs`, `ThrowIfUserHasInsufficentRights`, Zeilen 28-36 - Begründung: benennt die durchsetzende Rechteprüfung für den Zugriff auf die offenen Posten. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptIsPaid`, Zeile 4902 - Begründung: setzt den Bezahltstatus unter Rechte- und Nebenläufigkeitsprüfung. +Prüfidee: Ein Benutzer ohne das Recht `Controlling.Finances.Dunning` darf die OPOS-Liste nicht öffnen können. +Tracelinks: StRS-005, SyRS-081, SwRS-081 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Liquiditätssteuerung. +Status: belegt +``` + +``` +ID: StRS-029 +Titel: Mehrstufiges Mahnwesen +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Eine Rechnung ist überfällig. +Fakt: `DunningRunBL.ExecuteDunningRun` erhöht die Mahnstufe einer Rechnung schrittweise von `None` über `Level1` und `Level2` nach `Level3` und schreibt je Stufe Datum und ausführenden Benutzer (`DunningLevel1Date`/`DunningLevel1Employee` usw.); `ResetDunningRun` setzt die Stufe um genau eine Stufe zurück. +Aussage: Das System soll überfällige Rechnungen in bis zu drei Mahnstufen mahnen, jede Stufe mit Datum und Benutzer dokumentieren und einen Mahnlauf zurücknehmen können. +Ergebnis: Die Mahnhistorie jeder Rechnung ist lückenlos nachvollziehbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs`, Zeilen 253-270 (Stufenerhöhung) und 519-540 (Rücknahme) - Begründung: die `switch`-Anweisungen sind die durchsetzende Stelle der Mahnstufenlogik. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs`, Zeile 216, Dateiname `Mahnung_{Datum}.pdf` - Begründung: belegt die Erzeugung eines Mahnbelegs. +Prüfidee: Ein Mahnlauf auf einer Rechnung der Stufe 2 muss die Stufe auf 3 setzen und `DunningLevel3Date` füllen; die Rücknahme muss wieder Stufe 2 ergeben. +Tracelinks: StRS-028, SyRS-082, SwRS-082, SyRS-083 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Forderungsmanagement. +Status: belegt +``` + +``` +ID: StRS-030 +Titel: Auftragssperre bei erreichter Mahnstufe +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertriebsleitung +Vorbedingung: Für den Kunden ist eine Sperrmahnstufe (`OrderLockAfterDunning`) hinterlegt. +Fakt: `ReceiptBL.CanUserCreateNewReceiptsAtCustomerOrSupplier` ermittelt über `GetCustomerOrSupplierDunningLevel` die Mahnstufe des Kunden und bricht die Belegneuanlage ab, sobald `dunningLevel >= blockOnLevel`; `OrderSpecificLogic.BlockNewReceiptsDunningLevel` liefert `customerDetail.OrderLockAfterDunning`. +Aussage: Das System soll die Neuanlage von Aufträgen für Kunden sperren, deren Mahnstufe die kundenindividuell festgelegte Sperrgrenze erreicht. +Ergebnis: Für gesperrte Kunden entsteht kein neuer Auftrag; der Anwender erhält eine begründete Fehlermeldung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserCreateNewReceiptsAtCustomerOrSupplier`, Zeilen 10205-10216, Bedingung `dunningLevel >= blockOnLevel` mit Fehlermeldung „Aufgrund der Mahnstufe darf kein neuer Beleg … angelegt werden." - Begründung: die Bedingung ist die durchsetzende Prüfung. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Orders/OrderSpecificLogic.cs`, `BlockNewReceiptsDunningLevel`, Zeilen 687-693 - Begründung: liefert die kundenindividuelle Sperrgrenze aus dem Kundenstamm. + - [KONTEXT] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Kommentar zu `GetCustomerOrSupplierDunningLevel` („There is no dunning-level for suppliers right now") - Begründung: dokumentiert die bewusste Einschränkung auf die Kundenseite. +Prüfidee: Kunde mit Mahnstufe 2 und `OrderLockAfterDunning = 2`: die Auftragsanlage muss scheitern, die Rechnungsanlage jedoch gelingen. +Tracelinks: StRS-029, StRS-003, SyRS-084, SwRS-083 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Risikosteuerung. +Status: belegt +``` + +``` +ID: StRS-031 +Titel: Rollenbasierte Berechtigungsverwaltung +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Benutzer und Gruppen sind angelegt. +Fakt: Rechte werden über Gruppen vergeben: `AppRightsBL.GetRightsFromCurrentUser` sammelt die Rechte aller Gruppen des Benutzers; `CheckRightsFromUser` prüft per SQL über `Sichtrus` und `Sichmemb`. Die Rechtekonstanten umfassen rund 800 Einträge in 60 Klassen. +Aussage: Das System soll Berechtigungen ausschließlich über Gruppen vergeben und jede fachliche Funktion an ein benanntes Einzelrecht binden. +Ergebnis: Die Rechte eines Benutzers ergeben sich eindeutig aus seiner Gruppenzugehörigkeit. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `CheckRightsFromUser`, SQL `SELECT st.Recht FROM dbo.Sichtrus st INNER JOIN dbo.Sichmemb sm ON sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D` - Begründung: die Abfrage ist die durchsetzende Stelle der Rechteermittlung. + - [PRIMÄR] `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs`, 2.819 Zeilen mit 60 Rechteklassen - Begründung: definiert die Rechte-IDs, gegen die geprüft wird. + - [KONTEXT] `docs/guides/development/check-userrights.md` - Begründung: beschreibt die vorgesehenen Prüfmuster. +Prüfidee: Entfernt man einen Benutzer aus einer Gruppe, dürfen die über diese Gruppe vergebenen Rechte unmittelbar nicht mehr greifen. +Tracelinks: SyRS-090, SyRS-091, SwRS-090, SwRS-091 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Grundlage jeder Zugriffssteuerung. +Status: belegt +``` + +``` +ID: StRS-032 +Titel: Einschränkende Rechte auf eigene Objekte oder eigene Filiale +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Ein Basisrecht ist vergeben. +Fakt: Zu zahlreichen Basisrechten existieren einschränkende Zusatzrechte, etwa `SHOW_HELPDESK_ONLY_OWN`, `CREATE_NEW_INVOICE_ONLY_OWN_BRANCH`, `EDIT_INVOICE_ONLY_OWN_BRANCH`, `MANAGE_RIGHTS_ONLY_OWN_BRANCH`, `OWN_TIME_EDIT`. `ReceiptBL.CanUserCreateReceiptsInBranch` und `CanUserEditReceipt` werten sie über `BranchBL.IsBranchEqual` aus. +Aussage: Das System soll ein vergebenes Basisrecht durch zusätzliche einschränkende Rechte auf eigene Objekte oder die eigene Filiale begrenzen können. +Ergebnis: Der Benutzer kann die Funktion nur innerhalb seines zulässigen Bereichs ausüben. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserCreateReceiptsInBranch` (Zeile 10251) und `CanUserEditReceipt` (10272) mit `BranchBL.IsBranchEqual` - Begründung: die Filialprüfung wird dort tatsächlich durchgesetzt. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `GetAllRightGroups`, Filter `query.Where(f => f.BranchI3D == currentUser.Employee.BranchI3D…)` bei `MANAGE_RIGHTS_ONLY_OWN_BRANCH` - Begründung: die Filialbeschränkung ist als Abfragefilter durchgesetzt. + - [KONTEXT] `CentronRights.md`, wiederkehrende Formulierung „This is a **restricting right**" - Begründung: benennt das Muster fachlich. +Prüfidee: Benutzer der Filiale A mit `EDIT_INVOICE_ONLY_OWN_BRANCH` darf eine Rechnung der Filiale B nicht speichern können. +Tracelinks: StRS-031, StRS-034, SyRS-092, SwRS-092 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - erforderlich für filialübergreifende Installationen. +Status: belegt +``` + +``` +ID: StRS-033 +Titel: Anmeldung über mehrere Identitätsquellen +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Alle Benutzer +Vorbedingung: Ein Benutzerkonto existiert in der gewählten Identitätsquelle. +Fakt: `AuthenticatorFactory` liefert je nach übergebenem `AuthObject` einen `BasicAuthenticator` (Benutzername/Passwort), `ActiveDirectoryAuthenticator`, `OpenIdConnectAuthenticator`, `WebAccountAuthenticator` oder `FallbackAuthenticator`; `FailingAuthenticator` deckt den Fehlerfall ab. +Aussage: Das System soll die Anmeldung wahlweise gegen den eigenen Benutzerstamm, ein Active Directory, einen OpenID-Connect-Anbieter oder ein Web-Kundenkonto zulassen. +Ergebnis: Der Benutzer erhält nach erfolgreicher Prüfung ein Sitzungsticket. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs` - Begründung: wählt den Authentifizierungsweg und ist damit die durchsetzende Stelle. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, `GetTicket()` - Begründung: erzeugt nach erfolgreicher Prüfung das Sitzungsticket. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs`, `AuthConfigurationController.cs` - Begründung: stellen die OpenID-Connect-Anmeldung als REST-Endpunkt bereit. +Prüfidee: Für jede der vier Identitätsquellen muss eine erfolgreiche Anmeldung ein gültiges Ticket liefern und eine fehlerhafte Anmeldung eine Fehlermeldung ohne Ticket. +Tracelinks: SyRS-100, SyRS-101, SwRS-100, SwRS-101 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Voraussetzung für den SaaS-Betrieb. +Status: belegt +``` + +``` +ID: StRS-034 +Titel: Mandanten- und Filialstruktur +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Mehrere rechtliche oder organisatorische Einheiten sind abzubilden. +Fakt: Es bestehen die Tabellen `Mandant` und `Filiale`; `MandatoryBL.GetMandators()` filtert auf `State == 1`, `GetNumberGroupFromDefaultMandator` nutzt den als Standard markierten Mandanten (`m.Standard = 1 AND m.Status = 1`). Belege tragen `BranchI3D` und `BranchOrigin`. +Aussage: Das System soll Mandanten und Filialen führen, jedem Beleg eine Filiale zuordnen und je Mandant/Filiale eigene Nummernkreise und Erlöskonten zulassen. +Ergebnis: Belege, Nummern und Konten sind der richtigen organisatorischen Einheit zugeordnet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs`, SQL in `GetNumberGroup` mit `WHERE ((nu.MandantI3D = fm.I3D AND nu.FilialI3D = f.I3D) OR nu.MandantI3D = m.I3D)` - Begründung: die Abfrage setzt die Mandanten-/Filialhierarchie bei der Nummernfindung durch. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptBranch` in `SaveReceipt` (Region „Update only the branch") - Begründung: setzt die Filiale am Beleg beim Speichern. + - [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `Mandant`, `Filiale` - Begründung: die Organisationsstruktur ist persistiert. +Prüfidee: Ein Beleg der Filiale B muss eine Nummer aus dem Nummernkreis der Filiale B erhalten, falls dieser gepflegt ist. +Tracelinks: StRS-032, StRS-035, SyRS-093, SwRS-093 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Voraussetzung für Mehrmandantenbetrieb. +Status: belegt +``` + +``` +ID: StRS-035 +Titel: Lückenlose Belegnummernvergabe +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Beleg ist zu nummerieren. +Fakt: `NumberGroupBL.GetNextNumber` erhöht den Zähler um das Intervall, prüft per `SELECT COUNT(*)` in der Zieltabelle, ob die Nummer bereits vergeben ist, und aktualisiert den Zähler nur, wenn genau eine Zeile geändert wurde (`rowCountChanged == 1`), andernfalls beginnt der Vorgang von vorn. +Aussage: Das System soll je Nummernart eine eindeutige, fortlaufende Nummer vergeben und dabei auch bei gleichzeitigem Zugriff mehrerer Benutzer keine Nummer doppelt vergeben. +Ergebnis: Jeder Beleg trägt genau eine, systemweit eindeutige Nummer seiner Nummernart. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs`, `GetNextNumber`, Zeilen 78-91, optimistische Sperre über `Where(f => f.I3D == … && f.Current == numberGroupObject.Current)` und Auswertung von `rowCountChanged` - Begründung: die bedingte Aktualisierung ist die durchsetzende Stelle der Eindeutigkeit. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs`, `FindNextNumber`, Zeilen 105-131, Existenzprüfung in der Zieltabelle sowie in `dbo.Kunden` und `dbo.Kreditor` - Begründung: verhindert die Wiederverwendung bereits belegter Nummern. + - [SEKUNDÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs`, 30+ Nummernarten - Begründung: benennt die zu nummerierenden Vorgangsarten. +Prüfidee: Zwei gleichzeitige Nummernanforderungen derselben Nummernart müssen zwei verschiedene Nummern liefern. +Tracelinks: StRS-034, SyRS-094, SwRS-094, SwRS-095 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Grundsätze ordnungsmäßiger Buchführung. +Status: belegt +``` + +``` +ID: StRS-036 +Titel: Lizenzabhängige Funktionsfreischaltung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lizenzgeber, Administrator +Vorbedingung: Eine Lizenzdatei beziehungsweise Lizenzserververbindung liegt vor. +Fakt: `LicenseManager.HasLicense(Guid)` prüft eine Lizenz-GUID gegen die aktuelle Assembly-Version; `CheckLicense(ApplicationKind, applicationVersion, LoggedInUser)` prüft zusätzlich Anzahl, Gültigkeitsdatum und Gültigkeitsversion. Die Modulregistrierung macht 84 Module von Lizenz-GUIDs abhängig. +Aussage: Das System soll einzelne Anwendungen und Funktionsmodule anhand von Lizenzen freischalten und dabei Anzahl, Ablaufdatum und zulässige Programmversion prüfen. +Ergebnis: Nur lizenzierte Module sind sichtbar und benutzbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, `HasLicense` (Zeile 243) und `CheckLicense` (258) - Begründung: die Methoden führen die Lizenzprüfung tatsächlich aus. + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `availableModules = this._modules.Where(f => f.CheckModuleFeatures()).Where(f => f.CheckRights(allRights))` - Begründung: nur bestandene Lizenz- und Rechteprüfungen führen zur Registrierung. + - [KONTEXT] `docs/reference/security/licensing-system.md` - Begründung: beschreibt Lizenzmodell, Anzahl, Ablaufdatum und Versionsgrenze. +Prüfidee: Nach Entzug der Lizenz `PasswordManager` darf das Modul „Zugänge" beim nächsten Anmelden nicht mehr registriert werden. +Tracelinks: SyRS-102, SwRS-102, SyRS-103 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Geschäftsmodell des Herstellers; im SaaS-Zielsystem als Tarif-/Feature-Steuerung. +Status: belegt +``` + +``` +ID: StRS-037 +Titel: Begrenzung gleichzeitiger Anmeldungen über Lizenzanzahl +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lizenzgeber +Vorbedingung: Für die Anwendung ist eine Lizenzanzahl hinterlegt. +Fakt: `Authenticator.AuthenticateUser` sucht zuerst über `TicketBL.GetExistingTicket` ein bestehendes Ticket; nur wenn keines existiert, wird `LicenseManager.CheckLicense` aufgerufen und bei Erfolg ein neues Ticket erzeugt. `TicketBL.GetTicketCount(Guid licenseGuid, LicenseUsageKind, LoggedInUser)` liefert die belegten Lizenzplätze. +Aussage: Das System soll die Zahl gleichzeitig angemeldeter Benutzer je Anwendung auf die lizenzierte Anzahl begrenzen und bereits angemeldeten Benutzern denselben Platz erneut zuweisen. +Ergebnis: Bei ausgeschöpfter Lizenzanzahl wird eine weitere Anmeldung abgelehnt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, `AuthenticateUser`, Zeilen innerhalb `lock (_getExistingOrCreateTicketLock)`: `GetExistingTicket` vor `LicenseManager.CheckLicense` - Begründung: die Reihenfolge und die Sperre setzen die Platzvergabe durch. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `GetTicketCount` - Begründung: zählt die belegten Lizenzplätze. +Prüfidee: Bei Lizenzanzahl 1 muss die zweite Anmeldung eines anderen Benutzers scheitern, eine erneute Anmeldung desselben Benutzers auf demselben Gerät jedoch gelingen. +Tracelinks: StRS-036, StRS-033, SyRS-104, SwRS-103 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im SaaS-Zielsystem als Sitzplatzmodell. +Status: belegt +``` + +``` +ID: StRS-038 +Titel: Formulargestützte Belegausgabe +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg ist gespeichert und ein Report ist zugeordnet. +Fakt: `ReceiptBL.CreateFullReportForReceipt(…, ReportAction reportAction, ReportData report, ReportGroup reportGroup, bool addReportPdfToReceiptDocuments, …)` erzeugt das Belegdokument; `CreateReportPreviewForReceipt` liefert eine Vorschau; `AddReportToReceiptDocuments` legt das PDF in der Dokumentenablage des Belegs ab. +Aussage: Das System soll zu jedem Beleg ein Formular als PDF erzeugen, es wahlweise als Vorschau anzeigen, drucken, versenden und in der Belegablage speichern. +Ergebnis: Das Belegdokument liegt als PDF vor und ist dem Beleg zugeordnet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CreateFullReportForReceipt` (Zeile 3221) und `AddReportToReceiptDocuments` (3459) - Begründung: erzeugen und archivieren das Dokument. + - [SEKUNDÄR] `src/backend/Centron.BL/ReportEngine/FastReportHelper.cs`, `PdfExport/` - Begründung: die eingesetzte Formularmaschine. +Prüfidee: Nach dem Druck einer Rechnung mit aktivierter Ablageoption muss in der Belegablage ein PDF mit dem Rechnungsdatum liegen. +Tracelinks: SyRS-110, SwRS-110, StRS-039 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Belegausgabe ist Pflicht. +Status: belegt +``` + +``` +ID: StRS-039 +Titel: Zentrale Dokumentenablage je Geschäftsobjekt +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Benutzer +Vorbedingung: Ein Geschäftsobjekt (Kunde, Beleg, Ticket) existiert. +Fakt: `Administration/FileManagement` enthält `DirectoryBL`, `DocumentBL`, `DirectoryReferenceBL`, `GetDirectoryByReferenzBL`, `SystemDirectoryNames` und `DirectoryReferenceProviders`; Verzeichnisse werden über eine Referenz auf Objektart und Objekt-ID aufgelöst. +Aussage: Das System soll zu jedem Geschäftsobjekt eine Verzeichnisstruktur führen und Dokumente darin ablegen und wiederfinden. +Ergebnis: Dokumente sind eindeutig einem Geschäftsobjekt zugeordnet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/FileManagement/GetDirectoryByReferenzBL.cs` und `DirectoryReferenceBL.cs` - Begründung: lösen die Objektreferenz in ein Verzeichnis auf und setzen damit die Zuordnung durch. + - [SEKUNDÄR] `src/backend/Centron.BL/Administration/FileManagement/SystemDirectoryNames.cs` - Begründung: definiert die vorgegebenen Systemverzeichnisse. +Prüfidee: Ein zu einem Ticket abgelegtes Dokument muss über die Ticket-ID wieder auffindbar sein und darf bei einem anderen Ticket nicht erscheinen. +Tracelinks: SyRS-111, SwRS-111 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Dokumentenzuordnung ist Grundfunktion. +Status: belegt +``` + +``` +ID: StRS-040 +Titel: E-Mail-Kommunikation aus dem Vorgang heraus +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst, Helpdesk +Vorbedingung: Ein Vorgang mit E-Mail-Empfänger liegt vor. +Fakt: `Centron.BL/Mail` enthält `MailSettingsBL`, `MailSignatureBL`, `Templates`, `VariableReplacement`, `Protocols`, `Exchange`, `Blacklist` und `MailFormatting`; je Belegart ist ein eigener Absender konfigurierbar (`GetDefaultMailSender` liefert für Rechnungen `InvoiceAndCreditVouchersSenderEmailAddress`, für Aufträge `OrderSenderEmailAddress`). +Aussage: Das System soll E-Mails aus dem Vorgang heraus mit Vorlage, Signatur, Variablenersetzung und belegartabhängigem Absender versenden und den Versand protokollieren. +Ergebnis: Die E-Mail ist versandt und beim Vorgang dokumentiert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, `GetDefaultMailSender`, Zeile 728, und `src/backend/Centron.BL/Sales/Receipts/Orders/OrderSpecificLogic.cs`, `GetDefaultMailSender`, Zeile 695 - Begründung: der belegartabhängige Absender ist im Code durchgesetzt. + - [PRIMÄR] `src/backend/Centron.BL/Mail/VariableReplacement/`, `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Mail and Variables", Zeile 6535 - Begründung: die Variablenersetzung erfolgt dort. + - [SEKUNDÄR] `src/backend/Centron.BL/Mail/Blacklist/` - Begründung: belegt eine Sperrliste für Empfänger. +Prüfidee: Eine aus einer Rechnung versandte E-Mail muss den in den Mail-Einstellungen für Rechnungen hinterlegten Absender tragen. +Tracelinks: SyRS-112, SwRS-112, StRS-041 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Standardkommunikationsweg. +Status: belegt +``` + +``` +ID: StRS-041 +Titel: Ticketerzeugung aus eingehenden E-Mails +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Helpdesk +Vorbedingung: Ein Postfach und ein Scanner-Profil sind konfiguriert. +Fakt: `MailScannerBL` verwaltet Profile (`GetProfiles`, `SaveProfile`), Arbeitsabläufe (`GetWorkflows`, `SaveWorkflow`), Aufgaben (`SaveTasks`) und ein Protokoll (`SaveMailScannerLog`, `GetMailScannerLogs`). +Aussage: Das System soll eingehende E-Mails regelbasiert auswerten und daraus Tickets erzeugen oder bestehenden Tickets zuordnen; jede Verarbeitung ist zu protokollieren. +Ergebnis: Zu jeder verarbeiteten E-Mail existiert ein Ticket oder eine Zuordnung sowie ein Protokolleintrag. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/MailScanner/MailScannerBL.cs`, `SaveMailScannerLog` (Zeile 133) und `GetProfiles` (57) - Begründung: Profilsteuerung und Protokollierung sind dort durchgesetzt. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskMailBL.cs`, `HelpdeskWorkflowMissingEmailCheckBL.cs` - Begründung: verknüpfen E-Mails mit Tickets. +Prüfidee: Eine E-Mail mit einer bekannten Ticketnummer im Betreff muss dem bestehenden Ticket zugeordnet werden statt ein neues zu erzeugen. +Tracelinks: StRS-016, StRS-040, SyRS-113, SwRS-113 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - wesentlicher Eingangskanal. +Status: belegt +``` + +``` +ID: StRS-042 +Titel: Terminplanung und Kalendersynchronisation +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker, Innendienst +Vorbedingung: Ein Termin ist zu planen. +Fakt: `CalendarBL` führt Termine; die Einstellungsmodule `CalendarSynchronizationSettingsController`, `CalendarRepresentationsSettingsController` und `AppointmentsForTicketsSettingsController` steuern Synchronisation, Vertretungen und Ticket-Termine; `Mail/Exchange` realisiert die Anbindung. +Aussage: Das System soll Termine führen, sie mit Exchange abgleichen, Vertretungsregelungen abbilden und Termine zu Tickets erzeugen. +Ergebnis: Termine sind in beiden Systemen konsistent und mit dem Vorgang verknüpft. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Calendar/CalendarBL.cs` und `src/backend/Centron.BL/Mail/Exchange/` - Begründung: Terminhaltung und Exchange-Anbindung sind dort implementiert. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Calendar/Settings/Synchronization/`, `Representations/`, `AppointmentsForTickets/` - Begründung: eigene Einstellungsseiten je Teilfunktion. + - [KONTEXT] `docs/features/exchange-sync-bugprotokoll.md` - Begründung: dokumentiert bekannte Abweichungen der Synchronisation. +Prüfidee: Ein im System angelegter Ticket-Termin muss nach der Synchronisation im Exchange-Kalender des Bearbeiters erscheinen. +Tracelinks: SyRS-114, SwRS-114 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Einsatzplanung. +Status: belegt +``` + +``` +ID: StRS-043 +Titel: Telefonieanbindung mit Anruferkennung +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Eine TAPI-Anbindung ist konfiguriert. +Fakt: `Tapi/PhoneCallBL.cs` führt Anrufe; es existieren der Nummernkreis `CallTracking = 22`, das Modul „Telefonate" (`MyCentron/Telephony/CallLog`) und persönliche Telefoneinstellungen (`PersonalPhoneSettingsController`). +Aussage: Das System soll ein- und ausgehende Anrufe protokollieren, den Anrufer anhand der Rufnummer einem Geschäftspartner zuordnen und den Anruf dem Vorgang zuordnen können. +Ergebnis: Zu jedem Anruf liegt ein Protokolleintrag mit Partnerbezug vor. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Tapi/PhoneCallBL.cs` - Begründung: führt die Anrufdatensätze. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs`, `CallTracking = 22` - Begründung: eigener Nummernkreis belegt den Anruf als eigenständigen Vorgang. + - [KONTEXT] `docs/reference/architecture/tapi.md` - Begründung: beschreibt die Anbindung. +Prüfidee: Ein Anruf von einer im Kundenstamm hinterlegten Rufnummer muss den zugehörigen Kunden anzeigen. +Tracelinks: SyRS-115, SwRS-115 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - in der Serviceannahme etabliert; im Zielsystem als CTI-Schnittstelle. +Status: belegt +``` + +``` +ID: StRS-044 +Titel: Kundenportal mit Ticket-, Beleg- und Bestellzugang +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Kunde (Web-Benutzer) +Vorbedingung: Für den Kunden existiert ein Web-Konto mit entsprechenden Web-Rechten. +Fakt: Die Webanwendung stellt unter `WebCart` die Seiten `CustomperPortalHomePage`, `WebCartShopPage`, `WebCartCartPage`, `ReceiptsOverview`, `ReceiptDetailsOverview`, `ContractsOverview`, `CustomerTicketDetailsPage`, `CustomerTicketHistoryPage`, `CustomerPortalFormsPage` und `CustomerPortalPublicDocumentsPage` bereit. +Aussage: Das System soll Kunden einen Webzugang bieten, über den sie Tickets einsehen und anlegen, Belege und Verträge einsehen, Dokumente abrufen, Formulare ausfüllen und Artikel bestellen können. +Ergebnis: Der Kunde kann seine Vorgänge selbstständig einsehen und auslösen. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus/WebCart/` mit den genannten Razor-Seiten - Begründung: die Seiten realisieren die Portalfunktionen. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, `GetAllWebRightsFromWebAccount` - Begründung: die Portalinhalte werden über Web-Rechte gesteuert. + - [KONTEXT] `README.md`, Abschnitt „Contributing / 1. WebCart" - Begründung: beschreibt Zweck und Datenquelle des Shops (Sonderpreise des Kunden). +Prüfidee: Ein Web-Konto ohne das Recht auf Belegeinsicht darf die Seite `ReceiptsOverview` nicht öffnen können. +Tracelinks: StRS-045, StRS-017, SyRS-120, SwRS-120 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im SaaS-Zielsystem zentraler Kanal. +Status: belegt +``` + +``` +ID: StRS-045 +Titel: Belegfreigabe und Unterzeichnung durch den Kunden +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Kunde +Vorbedingung: Ein Beleg wurde dem Kunden über einen Token-Link bereitgestellt. +Fakt: `ReceiptBL.ChangeWebReceiptState(string token, WebReceiptState webReceiptState)` ändert den Freigabezustand anhand eines Tokens; `SendSignAcceptance` und `SendSignDocument` erzeugen Signieranfragen zu `SharedDocument`; die Webanwendung stellt `DocumentSigningPage`, `SharedDocumentSignPage` und `SharedDocumentAcceptancePage` bereit. +Aussage: Das System soll Belege und Dokumente über einen persönlichen Link zur Freigabe oder Unterzeichnung bereitstellen und die Entscheidung des Kunden festhalten. +Ergebnis: Der Freigabe- oder Signaturzustand des Belegs ist dokumentiert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ChangeWebReceiptState(string token, WebReceiptState)`, Zeile 5903 - Begründung: die Methode ist die durchsetzende Stelle der tokengebundenen Zustandsänderung. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SendSignDocument(AppUser, string centronNexusUrl, SharedDocument, ReceiptMailTemplateDTO)`, Zeile 7133 - Begründung: erzeugt die Signieranfrage. + - [SEKUNDÄR] `src/nexus/CentronNexus/DocumentSigning/DocumentSigningPage.razor`, `IsolatedSignaturePad.razor` - Begründung: die Unterschriftserfassung im Browser. +Prüfidee: Ein bereits verwendeter oder abgelaufener Token darf keine erneute Zustandsänderung des Belegs erlauben. +Tracelinks: StRS-044, StRS-038, SyRS-121, SwRS-121 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - beschleunigt den Vertriebsabschluss. +Status: belegt +``` + +``` +ID: StRS-046 +Titel: Persönliche Aufgaben- und Tagesplanung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Benutzer +Vorbedingung: Der Benutzer ist angemeldet. +Fakt: `ToDoBL` führt objektbezogene Aufgaben (`IToDoObjectKind`, `DeleteHelpdeskToDos`); `MyDayBL` und `MyDayNotificationsBL` bilden die Tagesplanung ab; im Web existieren `MyDayPage`, `MyDayList`, `MyDayStatistics`. +Aussage: Das System soll je Benutzer eine persönliche Aufgabenliste und eine Tagesübersicht führen und Aufgaben mit Geschäftsobjekten verknüpfen. +Ergebnis: Der Benutzer sieht seine offenen Aufgaben und seine Tagesplanung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/ToDoArea/ToDoBL.cs`, `DeleteHelpdeskToDos` (aufgerufen aus `HelpdeskCloseBL.CloseHelpdesk`) - Begründung: belegt die Kopplung der Aufgaben an das Geschäftsobjekt Ticket. + - [PRIMÄR] `src/backend/Centron.BL/MyDay/MyDayBL.cs`, `MyDayWebServiceBL.cs` - Begründung: führen die Tagesplanung. + - [SEKUNDÄR] `src/nexus/CentronNexus/ServiceBoard/MyDay/` - Begründung: Weboberfläche derselben Funktion. +Prüfidee: Beim Abschließen eines Tickets müssen die zugehörigen Aufgaben entfernt werden. +Tracelinks: StRS-020, SyRS-122, SwRS-122 +Konsolidierung: Kandidat: StRS-020 — Aufgabenverwaltung (`TaskManager`) und Todo-Liste (`ToDoArea`) sind zwei Datenhaltungen für zu erledigende Vorgänge. +Übernahmewürdigkeit: übernehmen - Arbeitsorganisation. +Status: belegt +``` + +``` +ID: StRS-047 +Titel: Verwaltung von Kundenzugangsdaten +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Für einen Kunden sind Zugangsdaten zu hinterlegen. +Fakt: `PasswordManagerBL` speichert Kennwörter als `CustomizationDataTypes.EncryptedText` und verschlüsselt sie mit `new AESCryptoLogic().EncryptText(…, masterKey)`, wobei der Masterschlüssel über `CentronConfigurationDbBL.GetHotlineMasterKey()` bezogen wird; jeder Lesezugriff auf ein Kennwort ist zu protokollieren. +Aussage: Das System soll Zugangsdaten von Kundensystemen verschlüsselt speichern und jeden Zugriff darauf protokollieren. +Ergebnis: Zugangsdaten liegen nur verschlüsselt vor; Zugriffe sind nachvollziehbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeile 700, `propertyValue.ValueEncryptedString = new AESCryptoLogic().EncryptText(customerHotline.Password, masterKeyResult.Data)` - Begründung: die Verschlüsselung erfolgt an dieser Stelle. + - [PRIMÄR] `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeile 551, `new CentronConfigurationDbBL(this.Session).GetHotlineMasterKey()` - Begründung: benennt die Herkunft des Schlüssels. + - [SEKUNDÄR] `src/backend/Centron.BL/PasswordManagementArea/PasswordManagementAccessLogBL.cs` - Begründung: Protokollierung der Zugriffe im Vorgängermodul. +Prüfidee: Der in der Datenbank abgelegte Kennwortwert darf im Klartext nicht auffindbar sein; ein Lesezugriff muss einen Protokolleintrag erzeugen. +Tracelinks: StRS-050, SyRS-130, SwRS-130, SwRS-131 +Konsolidierung: Kandidat: StRS-048 — `PasswordManager` und `PasswordManagementArea` sind zwei Implementierungen derselben Fachfunktion. +Übernahmewürdigkeit: übernehmen - für den Servicebetrieb erforderlich. +Status: belegt +``` + +``` +ID: StRS-048 +Titel: Ablösung des alten Zugangsdatenmoduls +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Eine Installation nutzt noch das alte Modul. +Fakt: `ModuleRegistration.cs` führt die Region `#region c-entron Module: Passwort Manager (obsolate)`; im alten Modul setzt `PasswordManagementKeywordBL.AddNewKeyword` `keyword.Salt = ""` und `keyword.Password = ""`, und `GetDecryptedKeywordById` gibt `keyword.Password` unverändert zurück (Kommentar `// decryption` ohne Implementierung). +Aussage: Das System soll das alte Zugangsdatenmodul nicht mehr für Neuanlagen verwenden; bestehende Daten sind in den aktuellen Passwort-Manager zu überführen. +Ergebnis: Zugangsdaten werden ausschließlich über den aktuellen, verschlüsselnden Passwort-Manager geführt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/PasswordManagementArea/PasswordManagementKeywordBL.cs`, Zeilen 47-49, `keyword.Salt = ""; keyword.Password = "";` - Begründung: das Kennwort wird im alten Modul nicht gespeichert, die Funktion ist damit unvollständig. + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Regionsbezeichnung „Passwort Manager (obsolate)" - Begründung: kennzeichnet das Modul im Code selbst als überholt. + - [KONTEXT] `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, `AddOldHotlineEntriesToCustomer`, Zeile 722 - Begründung: belegt einen bestehenden Migrationspfad aus den Altdaten. +Prüfidee: Eine Neuanlage im alten Modul darf im Zielsystem nicht mehr möglich sein; Altdaten müssen im neuen Modul sichtbar sein. +Tracelinks: StRS-047, SyRS-131, SwRS-132 +Konsolidierung: Kandidat: StRS-047 +Übernahmewürdigkeit: veraltet - das Modul ist im Code als obsolet gekennzeichnet und speichert keine Kennwörter mehr. +Status: belegt +``` + +``` +ID: StRS-049 +Titel: Verwaltung installierter Kundengeräte +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Beim Kunden ist Hardware installiert. +Fakt: Es bestehen mindestens drei getrennte Datenhaltungen für Kundengeräte: `MasterDataList` („Stammblätter", Tabelle `Stammdat`, mit `SerialNumber`, `CounterDevice`, `InvoiceI3D`), `AccountDevice` (Tabelle `AccountDevices`, verknüpfbar über `AccountDevicesToTickets`) und `AssetManagementDevices` (DocuBoard/Monitoring) sowie zusätzlich `CustomerAsset`/`AssetBase` und die Tabelle `GeraeteKopf`. +Aussage: Das System soll die beim Kunden installierten Geräte mit Seriennummer, Standort, Vertrags- und Rechnungsbezug führen und sie mit Tickets verknüpfen können. +Ergebnis: Zu jedem Kundengerät sind Herkunft, Vertragsbezug und Servicehistorie bekannt. +Belege: + - [PRIMÄR] `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs`, Felder `SerialNumber`, `CounterDevice`, `InvoiceI3D`, `ContractI3D` - Begründung: das Stammblatt ist die durchgesetzte Geräteakte mit Vertrags- und Rechnungsbezug. + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `Stammdat`, `AccountDevices`, `AccountDevicesToTickets`, `AssetManagementDevices`, `GeraeteKopf` - Begründung: belegen die getrennten Datenhaltungen im Schema. + - [SEKUNDÄR] `src/backend/Centron.BL/Devices/AccountDeviceBL.cs`, `src/backend/Centron.BL/Sales/CustomerAssets/AssetBL.cs` - Begründung: getrennte Geschäftslogik je Datenhaltung. +Prüfidee: Ein Gerät mit bekannter Seriennummer muss über alle Geräteansichten hinweg auffindbar sein. +Tracelinks: StRS-010, StRS-051, SyRS-140, SwRS-140, SwRS-141 +Konsolidierung: Kandidat: SwRS-140, SwRS-141, SwRS-142 — Stammblätter, Account-Geräte, Asset-Management-Geräte und Customer-Assets bilden denselben fachlichen Gegenstand „installiertes Gerät" in getrennten Datenhaltungen ab und sind im Zielsystem zu einem Asset-Konzept zusammenzuführen. +Übernahmewürdigkeit: übernehmen - fachlich erforderlich, jedoch nur in konsolidierter Form. +Status: belegt +``` + +``` +ID: StRS-050 +Titel: Wahrung der Betroffenenrechte nach DSGVO +Ebene: StRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Datenschutzbeauftragter +Vorbedingung: Ein Löschbegehren einer natürlichen Person liegt vor. +Fakt: `DataSecurityBL.DsgvoDeleteRightGetContacts` und `DsgvoDeleteRightDeleteContacts` prüfen beide zuerst `currentUser.HasUserRight(UserRightsConst.DsgvoModule.DSGVO_DELETE_CONTACT)`; gelöschte Kontakte werden mit dem Text `"DSGVO: Auf Anfrage gelöscht. (Durchgeführt von {0} am {1:d} um {1:t} Uhr)"` gekennzeichnet. +Aussage: Das System soll Kontaktdaten natürlicher Personen auf Anfrage löschen, den Vorgang mit Benutzer und Zeitpunkt kennzeichnen und diese Funktion an ein eigenes Recht binden. +Ergebnis: Die personenbezogenen Daten sind entfernt und der Löschvorgang ist nachweisbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 379 und 789, `if (!currentUser.HasUserRight(UserRightsConst.DsgvoModule.DSGVO_DELETE_CONTACT))` - Begründung: die Rechteprüfung ist an beiden Einstiegspunkten durchgesetzt. + - [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 26-27, Konstanten `DsgvoDeletedContactMessage`, `DsgvoDeletedContactMessageWithEmployeeInfo` - Begründung: die Kennzeichnung des Löschvorgangs ist als Konstante festgelegt. + - [SEKUNDÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `DsgvoModule` mit `ACCESS_DSGVO_MODULE`, `DSGVO_DELETE_CONTACT`, `ACCESS_CLEANUP_DATABASE` - Begründung: eigener Rechtezweig für den Datenschutz. +Prüfidee: Ein Benutzer ohne `DSGVO_DELETE_CONTACT` darf weder die Kontaktliste abrufen noch löschen. +Tracelinks: StRS-031, SyRS-150, SwRS-150, SwRS-151 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - gesetzlich zwingend. +Status: belegt +``` + +``` +ID: StRS-051 +Titel: Nachvollziehbarkeit von Änderungen an Geschäftsobjekten +Ebene: StRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Analysierbarkeit) +Akteur: Revision, Administrator +Vorbedingung: Ein Geschäftsobjekt wird geändert. +Fakt: Belege führen die Felder `CreatedByI3D`, `CreatedAt`, `ChangedByI3D`, `ChangedAt`, `CreatedThroughApplicationVersion`, `ChangedThroughApplication` und `ChangedThroughApplicationVersion`; `SaveReceipt` setzt diese Felder bei jedem Speichern. Zusätzlich bestehen ein Änderungsprotokoll `AnlageLog`, Versionstabellen je Belegart und der Zweig `ChangeTracking/History`. +Aussage: Das System soll zu jeder Änderung an einem Geschäftsobjekt Benutzer, Zeitpunkt, auslösende Anwendung und Programmversion festhalten. +Ergebnis: Jede Änderung ist einer Person, einem Zeitpunkt und einer Anwendung zuzuordnen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Zuweisungen `receipt.ChangedAt = DateTime.Now; receipt.ChangedByI3D = currentUser.Employee.I3D; receipt.ChangedThroughApplicationVersion = …; receipt.ChangedThroughApplication = application;` - Begründung: die Zuweisungen sind die durchsetzende Stelle der Protokollierung. + - [PRIMÄR] `src/backend/Centron.BL/ChangeTracking/History/` - Begründung: eigener Mechanismus für feldbezogene Historie. + - [SEKUNDÄR] `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitte „Version Tables" und „AnlageLog Table" - Begründung: beschreiben Versionierung und gemeinsames Protokoll. +Prüfidee: Nach einer Belegänderung müssen `ChangedByI3D`, `ChangedAt` und `ChangedThroughApplication` auf den auslösenden Benutzer und Client verweisen. +Tracelinks: SyRS-151, SwRS-152, StRS-050 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Revisionssicherheit. +Status: belegt +``` + +``` +ID: StRS-052 +Titel: Betrieb als Windows-Anwendung und als Container-Dienst +Ebene: StRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Installierbarkeit) +Akteur: Administrator, Betrieb +Vorbedingung: Eine Zielumgebung ist bereitgestellt. +Fakt: Es bestehen ein WixSharp-Installer (`deployment/WixSharpInstaller/`), Hosting als Windows-Dienst und Konsolenanwendung (`Centron.Host.WindowsService`, `Centron.Host.Console`) sowie ein Linux-Container auf Basis `mcr.microsoft.com/dotnet/runtime:10.0.5-alpine3.23` mit `ENV TZ=Europe/Berlin` und `DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false`. +Aussage: Das System soll wahlweise als Windows-Installation, als Windows-Dienst und als Linux-Container betrieben werden können. +Ergebnis: Der Dienst läuft in allen drei Betriebsformen mit gleicher Funktion. +Belege: + - [PRIMÄR] `docker/Dockerfile`, Zeilen mit `FROM mcr.microsoft.com/dotnet/runtime:10.0.5-alpine3.23`, `ENV TZ=Europe/Berlin`, `ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false` - Begründung: definiert die Laufzeitumgebung des Containers verbindlich. + - [PRIMÄR] `src/webservice/Centron.Host.WindowsService/`, `src/webservice/Centron.Host.Console/` - Begründung: zwei eigenständige Hostprojekte für die Windows-Betriebsformen. + - [SEKUNDÄR] `docker/compose/compose.yaml`, `docker/compose/appsettings.Production.json`, `docker/compose/WebServiceConfig.xml` - Begründung: belegen die Konfiguration des Containerbetriebs. + - [KONTEXT] `docs/guides/services/web-service-on-linux.md` - Begründung: beschreibt den Linux-Betrieb. +Prüfidee: Derselbe REST-Aufruf muss gegen den Windows-Dienst und gegen den Container dieselbe Antwort liefern. +Tracelinks: SyRS-160, SwRS-160 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - der Containerbetrieb ist die Grundlage der SaaS-Zielarchitektur. +Status: belegt +``` + +``` +ID: StRS-053 +Titel: Automatisierte Datenbankmigration bei Programmstart +Ebene: StRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modifizierbarkeit) +Akteur: Administrator +Vorbedingung: Eine neue Programmversion greift auf eine ältere Datenbank zu. +Fakt: `ScriptEngineBL.ExecuteScripts(AppUser currentUser, bool executeBeforeLogin, Version currentVersionOverride)` ermittelt die bereits ausgeführten `DBUpdate`-Einträge, bestimmt die fehlenden Skriptmethoden über `ScriptMethodPool` und führt sie aus; eine Liste `_scriptIgnoreIfErrorList = { 10178, 10210, 10211, 50000 }` schließt einzelne Skripte von der Fehlerbehandlung aus. +Aussage: Das System soll fehlende Datenbankänderungen beim Start selbstständig erkennen und ausführen, bereits ausgeführte Änderungen nicht wiederholen und den Fortschritt anzeigen. +Ergebnis: Datenbankstand und Programmversion sind nach dem Start konsistent. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, `ExecuteScripts`, Ermittlung `scriptMethods.Where(f => dbUpdates.All(ff => ff.ScriptNumber != f.ScriptNumber))` - Begründung: die Bedingung verhindert die Wiederholung bereits ausgeführter Skripte. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, Zeile 27, `_scriptIgnoreIfErrorList` - Begründung: benennt die Skripte, deren Fehler bewusst ignoriert werden. + - [KONTEXT] `docs/guides/database/create-scripts.md`, `docs/reference/database/script-rules.md` - Begründung: beschreiben die Regeln der Skripterstellung. +Prüfidee: Ein zweiter Programmstart darf keine bereits eingetragene Skriptnummer erneut ausführen. +Tracelinks: SyRS-161, SwRS-161 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Voraussetzung für Wartungsfreiheit im Feld; im Zielsystem als Migrationsframework. +Status: belegt +``` + +``` +ID: StRS-054 +Titel: Auswertungen und Kennzahlen für die Unternehmenssteuerung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Geschäftsführung, Controlling +Vorbedingung: Belege, Tickets und Verträge sind erfasst. +Fakt: Der Zweig `Centron.BL/Statistics` gliedert sich in `SaleStatistics`, `OrderStatistics`, `TicketStatistics`, `ContractStatistics`, `MspStatistics`, `MspCollectors`, `Accounts` und `Administration`; die Module „Analytics", „Management Info", „Mitarbeiterauslastung", „MSP-Auswertung", „MSP-Dashboard" und „Vertragsauswertung" sind einzeln rechte- und lizenzgesteuert registriert. +Aussage: Das System soll Umsatz-, Auftrags-, Ticket-, Vertrags- und MSP-Kennzahlen bereitstellen und den Zugriff je Auswertung an ein eigenes Recht binden. +Ergebnis: Führungskräfte erhalten verdichtete Kennzahlen ohne Zugriff auf Einzelbelege. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Controlling/Analytics" mit acht einzeln rechtegesteuerten Modulen - Begründung: die Rechtebedingungen schalten die Auswertungen tatsächlich frei. + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `Controlling.Analytics`, Zeile 2574 - Begründung: eigener Rechtezweig für Auswertungen. + - [SEKUNDÄR] `src/backend/Centron.BL/Statistics/` mit acht Unterbereichen - Begründung: fachliche Gliederung der Auswertungen. +Prüfidee: Ein Benutzer ohne das Analytics-Recht darf das Modul „Analytics" nicht sehen. +Tracelinks: SyRS-170, SwRS-170 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Steuerungsgrundlage. +Status: belegt +``` + +``` +ID: StRS-055 +Titel: Objektübergreifende Volltextsuche +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Benutzer +Vorbedingung: Der Suchindex ist aufgebaut. +Fakt: `IndexSearchBL` stellt `UpdateAllIndexes(CancellationToken)`, `UpdateRequestedIndexes(CancellationToken)`, `SearchIndex(string searchText, CentronObjectKindNumeric? kind)` und `RequestUpdateFor(CentronObjectKindNumeric kind, int objectI3D)` bereit; es existiert ein eigener `GermanAnalyzer`. +Aussage: Das System soll eine objektartübergreifende Volltextsuche über einen eigenen, laufend aktualisierten Index bereitstellen und dabei deutsche Wortformen berücksichtigen. +Ergebnis: Der Benutzer findet Objekte über Freitext unabhängig von der Objektart. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs`, `SearchIndex` (Zeile 44) und `RequestUpdateFor` (75) - Begründung: realisieren Suche und gezielte Indexaktualisierung. + - [PRIMÄR] `src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs` - Begründung: die sprachspezifische Aufbereitung ist eigens implementiert. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Administration/Services/DocumentIndexSearch/` - Begründung: eigene Einstellungsseite für den Indexdienst. +Prüfidee: Ein neu angelegtes Ticket muss nach `RequestUpdateFor` über seinen Betreff in der Volltextsuche auffindbar sein. +Tracelinks: SyRS-171, SwRS-171 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Bedienkomfort und Auffindbarkeit. +Status: belegt +``` + +``` +ID: StRS-056 +Titel: KI-gestützte Assistenz +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Benutzer +Vorbedingung: Die Lizenz `AiAssistant` liegt vor und der Benutzer besitzt das Recht `ArtificialIntelligence.ID`. +Fakt: `ArtificialIntelligence` enthält `OpenAiApiClient`, `ChatModelApiClient`, `TextRatingApiClient`, `TicketCategoryApiClient`, `AiHttpModelCatalogClient`, `AiApiLinkValidator` und `Prompts`; die Modulregistrierung prüft `LicenseManager.Instance.HasLicense(LicenseGuids.AiAssistant)` und das Recht `UserRightsConst.ArtificialIntelligence.ID`. +Aussage: Das System soll KI-Funktionen für Chat, Textbewertung und Ticketkategorisierung bereitstellen und deren Nutzung an Lizenz und Recht binden. +Ergebnis: KI-Funktionen stehen nur berechtigten und lizenzierten Benutzern zur Verfügung. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `GetPersonalSettings`, Bedingung `LicenseManager.Instance.HasLicense(LicenseGuids.AiAssistant) && CentronCache.Instance.CurrentUserAppRights?.Any(f => f.I3D == UserRightsConst.ArtificialIntelligence.ID) == true` - Begründung: Lizenz- und Rechteprüfung sind dort durchgesetzt. + - [PRIMÄR] `src/backend/Centron.BL/ArtificialIntelligence/TicketCategoryApiClient.cs`, `TextRatingApiClient.cs` - Begründung: benennen die fachlichen KI-Anwendungsfälle. + - [SEKUNDÄR] `src/backend/Centron.BL/Telemetry/TelemetryBL.cs`, `RecordArtificialIntelligenceToolUsage` - Begründung: die KI-Nutzung wird gezählt. +Prüfidee: Ohne die Lizenz `AiAssistant` darf die persönliche KI-Einstellungsseite nicht erscheinen. +Tracelinks: StRS-036, SyRS-172, SwRS-172 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - jüngste Funktionserweiterung. +Status: belegt +``` + +``` +ID: StRS-057 +Titel: Kampagnen und Serienkommunikation +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Marketing +Vorbedingung: Eine Zielgruppe ist bestimmbar. +Fakt: Es bestehen `Accounts/Campaigns/`, `Mailings/MailingDataBL.cs`, `MailingTemplateBL.cs`, das Modul „Kampagnen/Mailing" (`CampaignAppModuleController`, Lizenz `CampaignsMailing`) sowie Kampagneneinstellungen (`GeneralCampaignSettingsController`). +Aussage: Das System soll Zielgruppen bilden, Kampagnen anlegen und daraus Serienbriefe oder Serien-E-Mails erzeugen. +Ergebnis: Die Kampagne ist dokumentiert und die Kontakte sind angeschrieben. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Adressen/CRM", Registrierung `CampaignAppModuleController` mit `LicenseGuids.CampaignsMailing` - Begründung: die Lizenzbedingung schaltet das Modul frei. + - [SEKUNDÄR] `src/backend/Centron.BL/Mailings/MailingDataBL.cs`, `MailingTemplateBL.cs` - Begründung: realisieren Datenauswahl und Vorlage. +Prüfidee: Eine Kampagne mit zehn Empfängern muss zehn dokumentierte Aussendungen erzeugen. +Tracelinks: StRS-040, SyRS-173, SwRS-173 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Vertriebsunterstützung. +Status: belegt +``` + +``` +ID: StRS-058 +Titel: Wiederverwendbare Textbausteine +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Textbausteine sind gepflegt. +Fakt: `TextModuleArea/TextModuleBL.cs` und `SalutationAndAgreementReplacementBL.cs` liefern Textbausteine; `ReceiptBL.CreateNewReceipt` besitzt den Parameter `bool insertSalutationAndAgreement`, der Anrede- und Schlussformel in den Beleg einfügt; die Tabelle `GeschaeftspartnerTextbausteine` führt partnerbezogene Bausteine. +Aussage: Das System soll Textbausteine zentral pflegen und beim Anlegen von Belegen automatisch als Anrede- und Schlusstext einfügen; partnerbezogene Bausteine haben Vorrang. +Ergebnis: Belege tragen einheitliche, gepflegte Standardtexte. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CreateNewReceipt(…, bool insertSalutationAndAgreement, …)`, Zeile 775 - Begründung: der Parameter steuert das tatsächliche Einfügen der Textbausteine. + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `GeschaeftspartnerTextbausteine` - Begründung: partnerbezogene Bausteine sind im Schema vorgesehen. + - [SEKUNDÄR] `src/backend/Centron.BL/TextModuleArea/SalutationAndAgreementReplacementBL.cs` - Begründung: realisiert die Ersetzung. +Prüfidee: Ein Beleg für einen Kunden mit eigenem Anredebaustein muss diesen statt des allgemeinen Bausteins tragen. +Tracelinks: StRS-003, SyRS-174, SwRS-174 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Einheitlichkeit der Außendarstellung. +Status: belegt +``` + +``` +ID: StRS-059 +Titel: Kundenindividuelle Zusatzfelder +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Ein Kunde benötigt Felder, die der Standard nicht vorsieht. +Fakt: `Centron.BL/Customizations/CustomTables` und `Centron.BL/Modules/ModuleBL.cs` verwalten `ModuleCustomProperty` und `ModuleCustomPropertyValue` mit Datentypen aus `CustomizationDataTypes` (u. a. `EncryptedText`); die Einstellungsseite `CustomPropertiesConfigurationSettingsController` ist registriert. +Aussage: Das System soll frei definierbare Zusatzfelder je Modul und Objekt bereitstellen, deren Datentyp konfigurierbar ist und die verschlüsselt abgelegt werden können. +Ergebnis: Kundenindividuelle Felder stehen ohne Programmänderung zur Verfügung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 1051-1052 und 1179, `case CustomizationDataTypes.EncryptedText: … DecryptText(propertyValue?.ValueEncryptedString, masterKey)` - Begründung: belegt die typabhängige Behandlung der Zusatzfelder einschließlich Verschlüsselung. + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `new CustomPropertiesConfigurationSettingsController()` in `GetSettingsWithoutModule()` - Begründung: die Konfigurationsoberfläche ist fest registriert. +Prüfidee: Ein neu definiertes Zusatzfeld vom Typ `EncryptedText` darf in der Datenbank nicht im Klartext lesbar sein. +Tracelinks: StRS-047, SyRS-175, SwRS-175 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - reduziert kundenspezifische Programmierung. +Status: belegt +``` + +``` +ID: StRS-060 +Titel: Produktionsaufträge und Maschinenverwaltung +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Produktion +Vorbedingung: Ein zu fertigender Artikel ist definiert. +Fakt: `Production/ProductionBL.cs` und `ProductionOrderBL.cs` bilden Produktionsaufträge ab; die Module `ProductionOrderAppModuleController` und `MachineManagementAppModuleController` sind registriert; im Web existiert `ProductionOrderManagement/Pages/ProductionOrderOverView.razor` mit `WorkStepTemplateComponent`. +Aussage: Das System soll Produktionsaufträge mit Arbeitsschritten und zugeordneten Maschinen führen und deren Fortschritt verfolgen. +Ergebnis: Der Fertigungsfortschritt je Auftrag ist bekannt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Production/ProductionOrderBL.cs` - Begründung: führt die Produktionsaufträge. + - [PRIMÄR] `src/nexus/CentronNexus/ProductionOrderManagement/Components/WorkStepTemplateComponent.razor` - Begründung: Arbeitsschrittvorlagen sind als eigene Oberfläche realisiert. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Production/MachineManagement/` - Begründung: eigene Maschinenverwaltung. +Prüfidee: Ein Produktionsauftrag mit drei Arbeitsschritten muss nach Abschluss des zweiten Schritts einen entsprechenden Fortschritt ausweisen. +Tracelinks: SyRS-180, SwRS-180 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - für fertigende Kunden erforderlich. +Status: belegt +``` + +``` +ID: StRS-061 +Titel: Mitarbeiterverwaltung als Grundlage der Zuständigkeit +Ebene: StRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Personalverwaltung, Administrator +Vorbedingung: Ein Mitarbeiter tritt ein oder aus. +Fakt: `Authenticator.ValidateAppUser` verweigert die Anmeldung, wenn `user.IsAccountDisabled` gesetzt ist, wenn das heutige Datum im Bereich `AccountDisabledFromDate`/`AccountDisabledToDate` liegt oder wenn `EmployeeBL.IsActiveEmployeeCompact(user.Employee)` fehlschlägt (Einstellungs- und Austrittstermin). +Aussage: Das System soll Mitarbeiterdaten einschließlich Ein- und Austrittstermin führen und die Anmeldung außerhalb des Beschäftigungszeitraums oder bei deaktiviertem Konto verweigern. +Ergebnis: Ausgeschiedene oder gesperrte Mitarbeiter können sich nicht anmelden. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, `ValidateAppUser`, Prüfungen auf `IsAccountDisabled`, `AccountDisabledFromDate`/`AccountDisabledToDate` und `IsActiveEmployeeCompact` - Begründung: die Methode verweigert die Anmeldung tatsächlich. + - [SEKUNDÄR] `src/backend/Centron.BL/EmployeeArea/EmployeeBL.cs`, `EmployeeHolidayBL.cs`, `EmployeeDepartmentBL.cs`, `EmployeeSkillsBL.cs` - Begründung: weitere Mitarbeiterstammdaten. +Prüfidee: Ein Mitarbeiter mit Austrittstermin in der Vergangenheit darf sich nicht mehr anmelden können. +Tracelinks: StRS-033, SyRS-181, SwRS-181 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Sicherheitsanforderung. +Status: belegt +``` + +``` +ID: StRS-062 +Titel: Anbindung von Fremd- und Monitoringsystemen +Ebene: StRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Administrator, Fremdsystem +Vorbedingung: Eine Verbindungskonfiguration ist hinterlegt. +Fakt: Es bestehen Konnektoren zu RMM-Systemen (`DataExchange/Rmm`, `RmmController`), docuFORM (`Centron.Api.docuFORM`), Telekom Dive, TANSS (`TanssInterfaces`), docBee (`DocBeeConnectorConfigurationController`), CPra, RiverDivo, TradePool und finAPI; `ObjectExternalReferenceBL` bildet die Verknüpfung interner Objekte zu Fremdsystem-IDs ab. +Aussage: Das System soll Fremdsysteme über konfigurierbare Konnektoren anbinden und interne Objekte dauerhaft mit deren Fremdschlüsseln verknüpfen. +Ergebnis: Fremdsystemdaten sind eindeutig internen Objekten zugeordnet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs` und `src/webservice/Centron.Controllers/Controllers/v1/Integrations/ObjectExternalReferencesController.cs` - Begründung: die Fremdschlüsselverknüpfung ist als eigene Entität und REST-Ressource durchgesetzt. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/v1/Integrations/`, `Controllers/v1/DataExchange/` - Begründung: eigene Endpunkte je Konnektor. +Prüfidee: Ein aus einem RMM-System importiertes Gerät muss über seine Fremdsystem-ID erneut auffindbar sein und darf beim zweiten Import nicht doppelt angelegt werden. +Tracelinks: StRS-049, SyRS-182, SwRS-182 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Integrationsfähigkeit ist Kaufkriterium. +Status: belegt +``` diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/SwRS.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/SwRS.md new file mode 100644 index 00000000..45fca90b --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/SwRS.md @@ -0,0 +1,3558 @@ +# SwRS — Software Requirements Specification + +**System:** c-entron ERP-Suite +**Norm:** ISO/IEC/IEEE 29148:2018, Abschnitt Software Requirements Specification +**Ebene:** Komponenten, Datenmodelle, softwareinterne Regeln +**Hinweis:** Jede SwRS-Anforderung verweist über `Tracelinks` auf die zugehörige SyRS-Anforderung. + +--- + +## 1. Architektur und Querschnittsbausteine + +``` +ID: SwRS-001 +Titel: Schichtung von Oberfläche, Logik, Geschäftslogik und Persistenz +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modularität) +Akteur: Entwicklung +Vorbedingung: Eine fachliche Funktion wird ergänzt. +Fakt: Die Architektur ist als Schichtenfolge UI → ViewModel → `ILogic` (`BLLogic`/`WSLogic`) → `ICentronRestService` → `WebServiceBL` → `BL` → Datenbank festgelegt; `ClassContainer.Instance.WithInstance((IXLogic logic) => …)` löst die Logikschicht auf, `BLSession`/`DAOSession` kapselt den Datenbankzugriff über NHibernate. +Aussage: Das System soll fachliche Funktionen über die festgelegte Schichtenfolge realisieren, wobei die Oberfläche ausschließlich über `ILogic`-Schnittstellen auf Daten zugreift. +Ergebnis: Oberflächencode enthält keinen direkten Datenbankzugriff. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/BLSession.cs`, `BaseBL.cs`, `DBBaseBL.cs` - Begründung: die Basisklassen kapseln den Sitzungs- und Datenzugriff für alle Geschäftslogikklassen. + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/CentronModule.cs`, `ClassContainer.Instance.WithInstance(async (IReceiptLogic logic) => await logic.GetReceiptByI3DAsync(...))` - Begründung: belegt den tatsächlichen Zugriffsweg der Oberfläche. + - [KONTEXT] `docs/getting-started/general-structure.md`, Schichtentabelle - Begründung: dokumentiert die Sollarchitektur einschließlich des Hinweises, dass es Abweichungen gibt. +Prüfidee: Eine ViewModel-Klasse darf keine Referenz auf `Centron.DAO` besitzen. +Tracelinks: SyRS-022, SyRS-168 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - klare Schichtung ist Voraussetzung der Neuimplementierung. +Status: belegt +``` + +``` +ID: SwRS-002 +Titel: Doppelte Datenzugriffsimplementierung je Modul +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modifizierbarkeit) +Akteur: Entwicklung +Vorbedingung: Ein Modul greift auf Daten zu. +Fakt: Jedes Modul stellt zu einer Schnittstelle `I{Modul}Logic` zwei Implementierungen bereit: `BL{Modul}Logic` für den direkten Datenbankzugriff und `WS{Modul}Logic` für den Webservice-Zugriff; die Auswahl erfolgt über `ClassContainer` anhand der Verbindungsart. +Aussage: Das System soll je Datenzugriffsschnittstelle eine datenbanknahe und eine webservicebasierte Implementierung führen, damit dasselbe Modul in beiden Verbindungsarten läuft. +Ergebnis: Module funktionieren unabhängig von der Verbindungsart. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/CentronModule.cs`, Prüfung `module.SupportsConnectionTypes` mit Verzweigung auf `CentronConnectionType.CentronWebServices` - Begründung: die Verbindungsart wird zur Laufzeit ausgewertet. + - [KONTEXT] `docs/getting-started/general-structure.md`, Abschnitt „Dual Implementation Architecture": „Every module MUST implement both data access methods" - Begründung: benennt die Regel. +Prüfidee: Für jede `ILogic`-Schnittstelle müssen genau zwei Implementierungen auffindbar sein. +Tracelinks: SyRS-168, SyRS-002 +Konsolidierung: Kandidat: SwRS-001 — die doppelte Implementierung verdoppelt jede Datenzugriffsfunktion. +Übernahmewürdigkeit: veraltet - im Web-/SaaS-Zielsystem entfällt der direkte Datenbankzugriff des Clients, damit auch die zweite Implementierung. +Status: belegt +``` + +``` +ID: SwRS-003 +Titel: Einheitliches Ergebnisobjekt für Fachlogikaufrufe +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Zuverlässigkeit (Fehlertoleranz) +Akteur: Entwicklung +Vorbedingung: Eine Fachlogikmethode wird aufgerufen. +Fakt: Fachlogikmethoden liefern `Result` beziehungsweise `Result` mit den Bestandteilen `Status` (`ResultStatus.Success`/`Error`), `Message`, `Data` und einem Meldungscode aus `DefaultMessageCodes` (u. a. `LoginFailed`, `RightCheckFailed`, `TwoFactorAuthFailed`, `CouldNotFindData`, `NoUsernameOrPassword`, `ApplicationIDUnknown`, `EmployeeAccountDeactivated`); es bestehen die Hilfsmethoden `AsSuccess`, `AsError`, `FromResult`, `FromException` und `ThrowIfError`. +Aussage: Das System soll Fehler aus der Fachlogik über ein einheitliches Ergebnisobjekt mit Status, Meldung und maschinenlesbarem Meldungscode zurückgeben statt über Ausnahmen. +Ergebnis: Aufrufer können Fehler einheitlich auswerten und übersetzen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, `Result.AsError(..., DefaultMessageCodes.NoUsernameOrPassword)` - Begründung: zeigt die tatsächliche Verwendung mit Meldungscode. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, durchgängige Rückgabetypen `Result<...>` - Begründung: belegt die Durchgängigkeit im größten Fachlogikbaustein. + - [KONTEXT] `docs/reference/architecture/results-and-responses.md` - Begründung: dokumentiert das Muster. +Prüfidee: Eine fehlgeschlagene Rechteprüfung muss `ResultStatus.Error` mit `DefaultMessageCodes.RightCheckFailed` liefern, nicht eine Ausnahme. +Tracelinks: SyRS-020, SyRS-091 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - erleichtert die Fehlerbehandlung über Schnittstellengrenzen hinweg. +Status: belegt +``` + +``` +ID: SwRS-004 +Titel: Trennung von Entitäten und Übertragungsobjekten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Daten werden zwischen Schichten übertragen. +Fakt: `Centron.Entities` enthält die persistierten Entitäten (`BaseEntity`, `BaseLongEntity`, `PersistedEntity`, `PersistedLongEntity`, `DBEntity`); die Übertragungsobjekte liegen getrennt (`Centron.Entities/WebServices`, `Centron.Data.WebServices.*`, Suffix `DTO`); `WebServiceBL`-Klassen wandeln Entitäten in Übertragungsobjekte, unter anderem über `ObjectMapper.Map`. +Aussage: Das System soll persistierte Entitäten nicht über Schnittstellengrenzen hinweg übertragen, sondern eigens definierte Übertragungsobjekte verwenden. +Ergebnis: Änderungen am Datenmodell wirken nicht unmittelbar auf die Schnittstelle. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `ObjectMapper.Map(contact.Data)` - Begründung: zeigt die tatsächliche Umwandlung an der Schichtgrenze. + - [PRIMÄR] `src/backend/Centron.Entities/Entities/BaseEntity.cs`, `PersistedEntity.cs` gegenüber `src/backend/Centron.Entities/WebServices/` - Begründung: die getrennten Verzeichnisse belegen die Trennung. + - [KONTEXT] `docs/reference/architecture/dtos-and-entities.md` - Begründung: dokumentiert die Regel. +Prüfidee: Ein REST-Endpunkt darf keine Klasse aus `Centron.Entities/Entities` unmittelbar zurückgeben. +Tracelinks: SyRS-173 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-005 +Titel: Zweistufiges Datenbankmodell aus Alt-Tabellen und Sichten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Eine Belegart wird gelesen oder geschrieben. +Fakt: Je Belegart bestehen eine deutschsprachige Tabelle und eine englischsprachige Sicht: `AngKopf`/`Offers`, `AufKopf`/`Orders`, `LiefKopf`/`DeliveryLists`, `RechKopf`/`Invoices`, `VertragKopf`/`Contracts`, `GutKopf`/`CreditVouchers`, `AbholKopf`/`PickupLists`, analog für die Positions- und Versionstabellen; die C#-Entitäten sind auf die Sichten abgebildet. +Aussage: Das System soll die historischen Tabellennamen erhalten und den Anwendungscode über Sichten mit fachlich sprechenden Namen anbinden. +Ergebnis: Alt- und Neucode arbeiten auf demselben Datenbestand. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `AngKopf`, `AufKopf`, `LiefKopf`, `RechKopf`, `VertragKopf`, `GutKopf`, `AbholKopf` mit ihren Positionstabellen - Begründung: die Alt-Tabellen sind im Schema vorhanden. + - [KONTEXT] `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitt „Dual Layer Architecture: Tables and Views" mit vollständiger Zuordnungstabelle - Begründung: benennt die Zuordnung. +Prüfidee: Ein über die Sicht `Invoices` gelesener Beleg muss denselben Datensatz liefern wie ein direkter Zugriff auf `RechKopf`. +Tracelinks: SyRS-005, SyRS-010 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - die Doppelbenennung ist eine Migrationsbrücke; im Zielsystem ist ein einheitliches, fachlich benanntes Modell vorzusehen. +Status: belegt +``` + +``` +ID: SwRS-006 +Titel: Gemeinsame Basisklassen aller persistierten Objekte +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Eine neue Entität wird eingeführt. +Fakt: `Centron.Entities` stellt `BaseEntity`, `BaseLongEntity`, `DBEntity`, `PersistedEntity` und `PersistedLongEntity` bereit; der Schlüssel heißt durchgängig `I3D` (int) beziehungsweise als Langvariante; Entitätseigenschaften sind `virtual` deklariert, da NHibernate mit Proxies arbeitet. +Aussage: Das System soll alle persistierten Objekte von gemeinsamen Basisklassen ableiten und den Primärschlüssel einheitlich als `I3D` führen. +Ergebnis: Generische Datenzugriffe (`GetGenericDAO()`) funktionieren für alle Entitäten. +Belege: + - [PRIMÄR] `src/backend/Centron.Entities/Entities/BaseEntity.cs`, `BaseLongEntity.cs`, `DBEntity.cs`, `PersistedEntity.cs`, `PersistedLongEntity.cs` - Begründung: die Basisklassen definieren den gemeinsamen Schlüssel. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `this.Session.GetGenericDAO().GetEntityList()` - Begründung: der generische Zugriff setzt die gemeinsame Basis voraus. +Prüfidee: `GetGenericDAO()` muss für jede Entität im Namensraum `Centron.Data.Entities` übersetzbar sein. +Tracelinks: SyRS-002 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - `I3D` ist im Zielsystem durch einen sprechenden Bezeichner zu ersetzen, das Prinzip bleibt. +Status: belegt +``` + +``` +ID: SwRS-007 +Titel: Benannte Abfragen für mengenwirksame Operationen +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Performance-Effizienz (Zeitverhalten) +Akteur: System +Vorbedingung: Eine Operation betrifft viele Datensätze. +Fakt: Mengenwirksame Operationen laufen über `Session.Advanced.NamedQueryAccess().GetNamedQuery(NamedQueryEnums…, parameters)` beziehungsweise `Session.Advanced.RawSqlAccess.ExecuteQuery(sql, parameters)`; Beispiele sind `NamedQueryEnums.ValueAddedTax.UpdateArticleVatsAndPrices`, `NamedQueryEnums.ValueAddedTax.CreateArticleLog`, `NamedQueryEnums.Helpdesk.CloseHelpdesksFromMaintenance`, `NamedQueryEnums.Asset.GetCustomersForAutomatedBilling`. +Aussage: Das System soll mengenwirksame Datenbankoperationen über benannte, parametrisierte Abfragen ausführen statt über objektweise Verarbeitung. +Ergebnis: Massenoperationen laufen in einer Datenbankanweisung statt in einer Schleife. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `UpdateArticleVATs` mit `NamedQueryAccess
().GetNamedQuery(NamedQueryEnums.ValueAddedTax.UpdateArticleVatsAndPrices, parameters)` - Begründung: die Massenänderung erfolgt tatsächlich als benannte Abfrage. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `CloseHelpdesk(IList, AppUser)` mit `NamedQueryEnums.Helpdesk.CloseHelpdesksFromMaintenance` und Listenparameter - Begründung: schließt viele Tickets in einer Anweisung. +Prüfidee: Der Steuersatzwechsel über 10.000 Artikel darf keine 10.000 Einzelaktualisierungen erzeugen. +Tracelinks: SyRS-007, SyRS-054 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-008 +Titel: Stapelverarbeitung großer Schlüsselmengen +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Zuverlässigkeit (Reife) +Akteur: System +Vorbedingung: Eine Operation betrifft mehr Datensätze, als ein Abfrageparameter aufnehmen kann. +Fakt: `TaxBL.UpdateArticleVATs` verarbeitet die betroffenen Artikel in Stapeln über `articleI3DsWithOldTaxRate.Batch(2000)` und übergibt jeden Stapel als Listenparameter (`isParamList: true`). +Aussage: Das System soll große Schlüsselmengen in Stapeln fester Größe verarbeiten, um die Parametergrenzen der Datenbank nicht zu überschreiten. +Ergebnis: Auch sehr große Mengen werden fehlerfrei verarbeitet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `foreach (var batch in articleI3DsWithOldTaxRate.Batch(2000))` - Begründung: die Stapelgröße ist dort festgelegt und wirksam. +Prüfidee: Ein Steuersatzwechsel über 5.000 Artikel muss drei Stapel erzeugen und fehlerfrei durchlaufen. +Tracelinks: SyRS-007, SwRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die fest verdrahtete Stapelgröße ist im Zielsystem konfigurierbar zu machen. +Status: belegt +``` + +``` +ID: SwRS-009 +Titel: Transaktionsklammer über Geschäftsvorfälle +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Geschäftsvorfall ändert mehrere Datensätze. +Fakt: `ReceiptBL.SaveReceipt` und `TaxBL.UpdateArticleVATs` kapseln ihre gesamte Verarbeitung in `this.Session.WithTransaction(() => { … })`; `Transactions/TransactionBL.cs` bündelt die Transaktionsbehandlung. +Aussage: Das System soll alle Datenänderungen eines Geschäftsvorfalls in einer Transaktion ausführen, sodass ein Fehler den Gesamtvorgang zurücknimmt. +Ergebnis: Es entstehen keine halb verarbeiteten Geschäftsvorfälle. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt` mit `return this.Session.WithTransaction(() => { … })` - Begründung: die Klammer umfasst den gesamten Speichervorgang. + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `UpdateArticleVATs` mit `return this.Session.WithTransaction(() => { … })` - Begründung: dieselbe Klammer beim Steuersatzwechsel. +Prüfidee: Ein Fehler bei der Frachtpositionsermittlung darf keine bereits geschriebene Belegposition hinterlassen. +Tracelinks: SyRS-010, SyRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 2. Belegkomponenten + +``` +ID: SwRS-010 +Titel: Zentrale Belegklasse mit generischen Typparametern +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modularität) +Akteur: Entwicklung +Vorbedingung: Eine belegübergreifende Funktion wird aufgerufen. +Fakt: `ReceiptBL` (11.441 Zeilen) implementiert die Belegfunktionen generisch über `` mit den Beschränkungen `where T : PersistedEntity, IReceiptBase` und `where TReceiptItem : class, IReceiptItemBase, new()`; nicht generische Überladungen ermitteln den Typ zur Laufzeit über `MakeGenericMethod(receipt.GetType(), receipt.ReceiptKind.GetReceiptItemType())` und `Invoke`. +Aussage: Das System soll die belegübergreifende Logik einmalig generisch implementieren und den konkreten Belegtyp zur Laufzeit auflösen. +Ergebnis: Alle Belegarten verhalten sich in den gemeinsamen Funktionen gleich. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt(IReceiptBase receipt, …)`, Zeilen 3519-3521 mit `MakeGenericMethod(...).Invoke(...)` - Begründung: zeigt die Laufzeitauflösung des Belegtyps. + - [PRIMÄR] ebenda, generische Signatur `SaveReceipt` mit den Typbeschränkungen - Begründung: die Beschränkungen sichern die gemeinsame Schnittstelle. +Prüfidee: Für jede der sieben Belegarten muss `SaveReceipt(IReceiptBase, …)` ohne Reflexionsfehler durchlaufen. +Tracelinks: SyRS-010, SyRS-022 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - der Umfang der Klasse ist im Zielsystem jedoch aufzuteilen. +Status: belegt +``` + +``` +ID: SwRS-011 +Titel: Reihenfolge der Positionsaufbereitung beim Speichern +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Beleg wird gespeichert. +Fakt: `SaveReceipt` führt die Positionsaufbereitung in fester Reihenfolge aus: Saldopositionen, Frachtartikelprüfung bei Neuanlage, kundenbezogene Frachtartikeleinstellung, Fracht- und Versicherungspositionen, Kundenrabattpositionen, interne Positionsreihenfolge, Anzeigenummerierung; danach folgen die Feldaktualisierungen `UpdateIsCashAsset`, `UpdateArticlePositionsHelpdeskTimerI3Ds`, `UpdateArticlePositionsPurchasePriceEqualsSellPrice`, `UpdateArticlePositionsNotDiscountable`, `UpdateArticlePositionsRichText`, `UpdatePaymentDueDate`, `UpdateOnlyPriceValue`, `UpdateReceiptStateFromPaymentCondition`, `UpdateReceiptOrderItemReference`. +Aussage: Das System soll die Positions- und Feldaufbereitung eines Belegs in einer festgelegten, reproduzierbaren Reihenfolge ausführen. +Ergebnis: Zweimaliges Speichern desselben Belegs führt zum selben Ergebnis. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Aufrufkette Zeilen 3634-3700 - Begründung: die Reihenfolge ist im Quelltext festgelegt und wirksam. +Prüfidee: Zweimaliges Speichern ohne zwischenzeitliche Änderung darf keine zusätzlichen Positionen erzeugen. +Tracelinks: SyRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die Reihenfolge ist im Zielsystem ausdrücklich zu dokumentieren. +Status: belegt +``` + +``` +ID: SwRS-012 +Titel: Nebenläufigkeitskennung als Belegfeld +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Beleg wird punktuell geändert. +Fakt: `ReceiptBase` führt das Feld `ConcurrencyControlGuid`; sämtliche punktuellen Änderungsmethoden in `ReceiptBL` (`UpdateReceiptInformation`, `UpdateReceiptReminderDate`, `UpdateReceiptProjectNumber`, `UpdateReceiptIsPaid`, `UpdateReceiptItemPurchasePrice`, `UpdateReceiptQuantityPicked`, `UpdateReceiptUserState`, `UpdateOfferClassification`) nehmen diese Kennung entgegen. +Aussage: Das System soll die Nebenläufigkeitskennung als Feld der Belegbasis führen und bei jeder punktuellen Änderung mit dem gespeicherten Wert abgleichen. +Ergebnis: Verlorene Aktualisierungen werden erkannt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Methodensignaturen ab Zeile 4790 mit `Guid? concurrencyControlGuid` - Begründung: der Parameter ist durchgängig vorhanden. + - [KONTEXT] `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitt „System Fields" - Begründung: benennt `ConcurrencyControlGuid` als Systemfeld der Belegbasis. +Prüfidee: Ein Aufruf mit veralteter Kennung muss abgewiesen werden. +Tracelinks: SyRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-013 +Titel: Belegartspezifische Sperrentitäten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Beleg wird zur Bearbeitung geöffnet. +Fakt: Die Sperrung erfolgt über die generische Komponente `AssetLockBL`, die je Belegart mit einer eigenen Sperrentität verwendet wird (`AssetLockBL` in `InvoiceSpecificLogic`); `ReceiptBL.CreateLock` und `RemoveLock` sind ebenfalls generisch über den Belegtyp. +Aussage: Das System soll Sperren über eine gemeinsame, generische Komponente mit je Belegart eigener Sperrentität verwalten. +Ergebnis: Sperren einer Belegart beeinflussen andere Belegarten nicht. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, Feld `private readonly AssetLockBL _lockBL;` - Begründung: belegt die typisierte Sperrentität je Belegart. + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/AssetLockBL.cs` - Begründung: die generische Sperrkomponente. +Prüfidee: Eine gesperrte Rechnung darf einen gleichnummerigen Auftrag nicht sperren. +Tracelinks: SyRS-013 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-014 +Titel: Versionstabellen als strukturgleiche Kopien +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Eine Spalte wird einer Belegtabelle hinzugefügt. +Fakt: Zu jeder Beleg- und Positionstabelle besteht eine Versionstabelle (`RechKopfVersions`, `RechPosVersions` usw.); die Entwicklungsvorgabe verlangt, dass jede Spalte der Basistabelle auch in der Versionstabelle mit identischem Typ vorhanden ist. +Aussage: Das System soll Versionstabellen strukturgleich zu ihren Basistabellen halten, sodass jede Spaltenänderung in beiden Tabellen nachgezogen wird. +Ergebnis: Versionierte Belege enthalten alle Felder des Originals. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `RechKopfVersions` - Begründung: die Versionstabelle ist im Schema vorhanden. + - [KONTEXT] `docs/reference/receipts/receipts-backend-architecture.md`, „Critical Requirement: Version tables … are exact 1:1 copies … every column that exists in the base table must also exist in the version table" - Begründung: benennt die Strukturregel ausdrücklich. +Prüfidee: Ein Vergleich der Spaltenlisten von `RechKopf` und `RechKopfVersions` darf keine Abweichung ergeben. +Tracelinks: SyRS-014 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - die Tabellenverdopplung ist im Zielsystem durch ein Historienverfahren ohne Strukturduplikat zu ersetzen. +Status: belegt +``` + +``` +ID: SwRS-015 +Titel: Übernahmeoptionen beim Kopieren und Weiterführen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg wird kopiert oder weitergeführt. +Fakt: `CopyReceipt` erhält ein `CopyReceiptData`, `ForwardReceipt` zusätzlich `ForwardReceiptData`, `InsertReceiptTakeoverOptions takeoverOptions`, `bool onlyTakeoverAvailableQuantity`, `bool ignoreDefaultContract` sowie eine Liste `IList receiptProjectLayoutItemI3DsToForward`; `CreateNewReceipt` besitzt die Schalter `insertSalutationAndAgreement`, `ignoreDefaultContract` und `insertCustomerDiscount`. +Aussage: Das System soll Kopie und Weiterführung über ausdrückliche Übernahmeoptionen steuern, die festlegen, welche Bestandteile in den Zielbeleg übernommen werden. +Ergebnis: Der Anwender bestimmt den Umfang der Übernahme. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ForwardReceipt(AppUser, ForwardReceiptData, IList, IList, InsertReceiptTakeoverOptions, bool, bool)`, Zeile 1548 - Begründung: die Parameter benennen die Übernahmeoptionen abschließend. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/DataAndResults/` - Begründung: enthält die Optionsklassen. +Prüfidee: Mit `onlyTakeoverAvailableQuantity = true` darf nur die verfügbare Menge übernommen werden. +Tracelinks: SyRS-015, SyRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-016 +Titel: Unterdrückung von Rückrufaktionen bei Vorlagen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Beleg wird als Vorlage gespeichert. +Fakt: In `SaveReceipt` wird bei `isTemplate` der Schalter `data.IgnoreCallbacks = true` gesetzt; derselbe Schalter existiert allgemein in `SaveReceiptData`. +Aussage: Das System soll beim Speichern von Belegvorlagen alle nachgelagerten Rückrufaktionen unterdrücken. +Ergebnis: Vorlagen lösen keine Benachrichtigungen, Aktivitäten oder Folgebuchungen aus. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Block `if (isTemplate) { data.IgnoreCallbacks = true; … }` mit dem Kommentar „We automatically ignore all callbacks when saving a receipt-template" - Begründung: der Schalter wird dort tatsächlich gesetzt. +Prüfidee: Das Speichern einer Vorlage darf keine Kundenaktivität erzeugen. +Tracelinks: SyRS-016, SyRS-183 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-017 +Titel: Zahlungskonditionen als eigene Stammdatentabelle +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Zahlungskonditionen werden gepflegt. +Fakt: Das Schema führt die Tabelle `Zahkond`; die Einstellungsseite `PaymentConditionsSettingsController` ist in `GetSettingsWithoutModule()` registriert; `ForwardReceipt` enthält die Region „Payment Conditions" (Zeile 2598); Verträge führen zusätzlich `PaymentConditionI3D` und `PaymentConditionText`. +Aussage: Das System soll Zahlungskonditionen als eigene Stammdaten führen, sie Belegen und Verträgen zuordnen und einen abweichenden Konditionstext je Vertrag zulassen. +Ergebnis: Belege tragen eine nachvollziehbare, gepflegte Zahlungskondition. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `Zahkond` - Begründung: die Konditionen sind eigenständig persistiert. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Payment Conditions" in `ForwardReceipt` - Begründung: die Übernahme in den Folgebeleg erfolgt dort. + - [SEKUNDÄR] `docs/reference/receipts/contracts-backend.md`, Felder `PaymentConditionI3D`, `PaymentConditionText` - Begründung: belegen den abweichenden Text am Vertrag. +Prüfidee: Ein Vertrag mit abweichendem Konditionstext muss diesen in der erzeugten Rechnung ausweisen. +Tracelinks: SyRS-017, SyRS-030 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-018 +Titel: Getrennte Adressfelder je Adressrolle am Beleg +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Beleg trägt abweichende Adressen. +Fakt: `ReceiptContract` führt je Adressrolle ein Textfeld und eine Kunden-ID: `DeliveryAddress`/`DeliveryAddressCustomerI3D`, `InvoiceAddress`/`InvoiceAddressCustomerI3D`, `LicenseeAddress`/`LicenseeAddressCustomerI3D`; `ReceiptBase` führt zusätzlich `AddressI3D`, `ContactPersonI3D`, `Street`, `PostOfficeBox`, `Zip`, `City`, `ContactName`, `CountryI3D`. +Aussage: Das System soll die Belegadressen sowohl als Verweis auf den Adressstamm als auch als kopierten Text am Beleg führen, damit spätere Stammdatenänderungen ausgegebene Belege nicht verändern. +Ergebnis: Ein gedruckter Beleg bleibt inhaltlich unverändert, auch wenn sich die Stammadresse ändert. +Belege: + - [PRIMÄR] `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitt „Address Information" mit der Aufzählung der kopierten Adressfelder in `ReceiptBase` - Begründung: benennt die redundante Adresshaltung am Beleg. + - [PRIMÄR] `docs/reference/receipts/contracts-backend.md`, Abschnitt „Delivery and Billing Addresses" - Begründung: benennt die drei Adressrollen mit je eigener Kunden-ID. +Prüfidee: Eine nachträgliche Änderung der Stammadresse darf die Adresse eines bereits gespeicherten Belegs nicht verändern. +Tracelinks: SyRS-018, SyRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die Kopie ist fachlich gewollt (Belegunveränderlichkeit). +Status: belegt +``` + +``` +ID: SwRS-019 +Titel: Ticketerzeugung aus Belegdaten über eine Zwischenstruktur +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Aus einem Beleg sollen Tickets entstehen. +Fakt: `ReceiptBL.GetHelpdeskInfosForReceipt` liefert `ReceiptHelpdeskData`, `CreateTicketsForReceipt` nimmt `IList` entgegen und liefert `IList`; damit ist die Erzeugung zweistufig aus Vorschlag und Bestätigung aufgebaut. +Aussage: Das System soll die Ticketerzeugung aus Belegen zweistufig gestalten: zuerst Vorschlagsdaten ermitteln, dann nach Bestätigung die Tickets erzeugen und die Zuordnung zurückliefern. +Ergebnis: Der Anwender kontrolliert die zu erzeugenden Tickets vor deren Anlage. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `GetHelpdeskInfosForReceipt` (Zeile 4405) und `CreateTicketsForReceipt` (Zeile 4445) - Begründung: die Zweistufigkeit ergibt sich aus den getrennten Methoden und ihren Typen. +Prüfidee: Der Aufruf der Vorschlagsmethode allein darf kein Ticket erzeugen. +Tracelinks: SyRS-019 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-020 +Titel: Zentrale Rechteprüfmethoden im Belegkern +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Eine Belegoperation wird ausgeführt. +Fakt: `ReceiptBL` besitzt vier private beziehungsweise interne Prüfmethoden: `CanUserCreateNewReceiptsAtCustomerOrSupplier` (Zeile 10194), `CanUserCreateReceiptsInBranch` (10251), `CanUserEditReceipt` (10272) und `CanUserViewReceipt` (10298); alle delegieren an `_specificLogics.Execute(receiptKind, f => f.HasRightTo…)`. +Aussage: Das System soll die Belegrechteprüfung in genau vier Prüfmethoden bündeln, die alle belegartabhängigen Rechte über die Belegartlogik auflösen. +Ergebnis: Neue Belegoperationen können nicht versehentlich ohne Rechteprüfung ergänzt werden. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, die vier genannten Methoden mit den Aufrufen von `_specificLogics.Execute(..., f => f.HasRightToCreateANewReceipt/HasRightToEditReceipt/HasRightToViewReceipt)` - Begründung: die Bündelung ist im Quelltext umgesetzt. +Prüfidee: Jede öffentliche Änderungsmethode in `ReceiptBL` muss eine der vier Prüfmethoden aufrufen. +Tracelinks: SyRS-020, SyRS-092 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als zentrale Berechtigungsprüfung. +Status: belegt +``` + +``` +ID: SwRS-021 +Titel: Rücksetzen unberechtigter Preisänderungen anhand der Vorgängerversion +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Benutzer ohne Preisänderungsrecht speichert einen Beleg. +Fakt: `SaveReceipt` ruft `UpdateArticlePositionsPurchasePriceAndSellPriceIfUserDoesNotHaveRightToChangeThem(currentUser, receipt, previousReceiptVersion)` auf und übergibt dabei die Vorgängerversion als Referenzwert; die geprüften Rechte liefert die Belegartlogik über `HasRightToChangePurchasePrice` und `HasRightToChangeSellPrice`. +Aussage: Das System soll Preisfelder eines Belegs bei fehlendem Recht auf die Werte der Vorgängerversion zurücksetzen statt den Speichervorgang abzubrechen. +Ergebnis: Der Beleg wird gespeichert, die unberechtigte Preisänderung jedoch verworfen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Aufruf mit `previousReceiptVersion` als Referenz - Begründung: der Vorgängerwert ist die Grundlage des Rücksetzens. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, `HasRightToChangePurchasePrice` (Zeile 377) und `HasRightToChangeSellPrice` (382) - Begründung: benennen die geprüften Rechte-IDs. +Prüfidee: Bei einem neuen Beleg ohne Vorgängerversion muss festgelegt sein, welcher Wert als Referenz dient; dies ist gesondert zu prüfen. +Tracelinks: SyRS-021 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem ist ein sichtbarer Hinweis auf die verworfene Änderung vorzusehen. +Status: belegt +``` + +``` +ID: SwRS-022 +Titel: Auflösung der Belegartlogik über die Objektart +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modularität) +Akteur: System +Vorbedingung: Eine belegartabhängige Regel wird benötigt. +Fakt: Jede Implementierung von `IReceiptSpecificLogic` deklariert `public CentronObjectKindNumeric TargetReceiptKind => …`; `SpecificLogics.Execute(receiptKind, f => …)` wählt anhand dieser Eigenschaft die passende Implementierung; `CentronObjectKindNumeric` bietet die Hilfsmethoden `GetReceiptType()`, `GetReceiptItemType()`, `GetReceiptKind()`, `GetReceiptName()`, `IsSupplierReceipt()`. +Aussage: Das System soll die Belegartlogik ausschließlich über die Objektart auflösen und keine Typprüfungen mit festen Verzweigungen auf einzelne Belegarten verwenden. +Ergebnis: Eine neue Belegart erfordert nur eine neue Implementierung, keine Änderung am Kern. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, `TargetReceiptKind => CentronObjectKindNumeric.InvoiceClass` - Begründung: die Zuordnung erfolgt über die Objektart. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/SpecificLogics.cs`, `IReceiptSpecificLogic.cs` - Begründung: definieren Auswahl und Schnittstelle. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/CentronModule.cs`, `OpenModuleByObject(CentronObjectKindNumeric objectKind, int objectI3D)` mit `objectKind.GetReceiptType()` - Begründung: dieselbe Auflösung in der Oberfläche. +Prüfidee: Eine hinzugefügte Belegart mit eigener `IReceiptSpecificLogic` muss ohne Änderung an `ReceiptBL` funktionieren. +Tracelinks: SyRS-022 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - tragfähiges Erweiterungsmuster. +Status: belegt +``` + +``` +ID: SwRS-023 +Titel: Objektart als systemweite Aufzählung +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Ein Objekt wird objektartübergreifend referenziert. +Fakt: `CentronObjectKindNumeric` ist die systemweite Aufzählung der Objektarten (u. a. `InvoiceClass`, `ContractClass`, `HelpdeskClass`, `SupplierOffer`); die Werte entsprechen den `AnlageArt`-Werten des gemeinsamen Protokolls (1 = Angebot bis 22 = Vertrag) und werden in `IndexSearchBL`, `ToDoArea`, `ObjectExternalReferences`, `DataSecurityBL` und `CentronModule.OpenModuleByObject` verwendet. +Aussage: Das System soll Objektarten systemweit über eine einzige Aufzählung kodieren und deren Werte mit der Datenbankkodierung übereinstimmen lassen. +Ergebnis: Objektartübergreifende Funktionen arbeiten ohne eigene Zuordnungstabellen. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/CentronModule.cs`, `OpenModuleByObject` mit `objectKind == CentronObjectKindNumeric.HelpdeskClass` und `objectKind == CentronObjectKindNumeric.ContractClass` - Begründung: die Aufzählung steuert die tatsächliche Verzweigung. + - [PRIMÄR] `src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs`, `SearchIndex(string searchText, CentronObjectKindNumeric? kind)` - Begründung: dieselbe Aufzählung in einem anderen Baustein. + - [KONTEXT] `docs/reference/receipts/receipts-backend-architecture.md`, „AnlageArt Values" - Begründung: belegt die Übereinstimmung mit der Datenbankkodierung. +Prüfidee: Der Wert für „Rechnung" muss in der Aufzählung und in `AnlageLog.AnlageArt` übereinstimmen (4). +Tracelinks: SyRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-024 +Titel: Belegkette und Fortschrittsanzeige +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg wurde weitergeführt. +Fakt: `ReceiptBL.GetReceiptProgression(int objectI3D, CentronObjectKindNumeric objectKind, int? limit)` liefert `IList`; die Auswertung liegt in `ReceiptProgressionBL` (906 Zeilen); der Parameter `limit` begrenzt die Tiefe. +Aussage: Das System soll zu jedem Beleg die vollständige Vorgänger- und Nachfolgerkette ermitteln und deren Tiefe begrenzbar machen. +Ergebnis: Der Anwender erkennt den Bearbeitungsstand eines Vorgangs über alle Belegarten hinweg. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `GetReceiptProgression`, Zeile 4767, mit Parameter `limit` - Begründung: die Methode liefert die Kette und begrenzt sie. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptProgressionBL.cs` - Begründung: enthält die Ermittlungslogik. +Prüfidee: Zu einer Rechnung, die aus Angebot, Auftrag und Lieferschein entstanden ist, müssen alle drei Vorgängerbelege erscheinen. +Tracelinks: SyRS-010, SyRS-015 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - zentrale Auskunftsfunktion. +Status: belegt +``` + +``` +ID: SwRS-025 +Titel: Belegkorb und Freigabesystem +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Belegpositionen werden gesammelt. +Fakt: Es bestehen `ReceiptCartBL` und `ReceiptCartReleaseSystemBL` im Belegkern; im Kundenportal existiert `WebCartCartPage.razor` mit `WebCartAdminPage.razor` und der Einstellungsseite `WebCartSettingsAppModuleController`; die Konfiguration liegt in `Configuration/WebCartConfig.cs`. +Aussage: Das System soll gesammelte Positionen in einem Belegkorb führen und deren Umwandlung in einen Beleg über ein Freigabeverfahren steuern. +Ergebnis: Bestellungen aus dem Portal entstehen erst nach Freigabe als Beleg. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs` - Begründung: das Freigabeverfahren ist als eigene Komponente realisiert. + - [SEKUNDÄR] `src/nexus/CentronNexus/WebCart/WebCartCartPage.razor`, `WebCartAdminPage.razor` - Begründung: Warenkorb und Freigabeverwaltung im Portal. +Prüfidee: Eine Portalbestellung darf ohne Freigabe keinen Auftrag erzeugen. +Tracelinks: SyRS-120, StRS-044 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im SaaS-Zielsystem zentral. +Status: belegt +``` + +``` +ID: SwRS-026 +Titel: Anzahlungen an Aufträgen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Für einen Auftrag ist eine Anzahlung vereinbart. +Fakt: Der Belegkern enthält den Zweig `Receipts/DownPayment/`; `ForwardReceipt` prüft in der Region „Validate DeliveryList: Related to order with down payments?" (Zeile 2483), ob der Auftrag Anzahlungen trägt. +Aussage: Das System soll Anzahlungen an Aufträgen führen und beim Weiterführen in einen Lieferschein prüfen, ob offene Anzahlungen bestehen. +Ergebnis: Lieferungen ohne geleistete Anzahlung werden erkannt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Validate DeliveryList: Related to order with down payments?", Zeile 2483 - Begründung: die Prüfung erfolgt beim Weiterführen tatsächlich. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/DownPayment/` - Begründung: eigener Codezweig für Anzahlungen. +Prüfidee: Das Weiterführen eines Auftrags mit offener Anzahlung in einen Lieferschein muss eine Meldung erzeugen. +Tracelinks: SyRS-010, StRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Absicherung im Projektgeschäft. +Status: belegt +``` + +``` +ID: SwRS-027 +Titel: Warnung bei nicht umgewandelten Fremdartikeln +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg enthält Positionen mit dem Fremdartikel-Systemartikel. +Fakt: `ForwardReceipt` enthält die Region „Validate Unconverted Article Warning (Invoice, DeliveryList, CreditVoucher)" (Zeile 2509); `ArticleBL.GetArticleForExternalArticles()` und `GetArticleI3DForExternalArticles()` liefern den Sammelartikel für Fremdartikel. +Aussage: Das System soll beim Weiterführen in Rechnung, Lieferschein oder Gutschrift warnen, wenn Positionen noch den Fremdartikel-Sammelartikel statt eines angelegten Artikels tragen. +Ergebnis: Fremdartikel werden vor der Fakturierung in echte Artikel überführt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Validate Unconverted Article Warning", Zeile 2509 - Begründung: die Prüfung ist auf die drei genannten Zielbelegarten beschränkt und dort umgesetzt. + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `GetArticleI3DForExternalArticles`, Zeile 207 - Begründung: benennt den geprüften Sammelartikel. +Prüfidee: Ein Auftrag mit einer Fremdartikelposition muss beim Weiterführen in eine Rechnung eine Warnung erzeugen. +Tracelinks: SyRS-064, SyRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Datenqualität im Artikelstamm. +Status: belegt +``` + +``` +ID: SwRS-028 +Titel: Belegprojekt-Layout für mehrteilige Ausgaben +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg ist in Abschnitte gegliedert. +Fakt: `CreateFullReportForReceipt` nimmt `IList layoutItems` entgegen; `ForwardReceipt` erhält `IList receiptProjectLayoutItemI3DsToForward`; der Zweig `Receipts/Projects/` enthält die zugehörige Logik. +Aussage: Das System soll Belege in Layout-Abschnitte gliedern, diese einzeln weiterführen und in der Formularausgabe berücksichtigen. +Ergebnis: Umfangreiche Projektbelege lassen sich abschnittsweise abwickeln. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ForwardReceipt` mit `IList receiptProjectLayoutItemI3DsToForward` und `CreateFullReportForReceipt` mit `IList layoutItems` - Begründung: die Parameter belegen die abschnittsweise Verarbeitung. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/Projects/` - Begründung: enthält die Layout-Logik. +Prüfidee: Das Weiterführen nur eines Layout-Abschnitts darf nur dessen Positionen übernehmen. +Tracelinks: SyRS-110, SyRS-015 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Anforderung des Projektgeschäfts. +Status: belegt +``` + +``` +ID: SwRS-029 +Titel: Schweizspezifische Belegausprägungen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst (Schweiz) +Vorbedingung: Die Installation wird in der Schweiz betrieben. +Fakt: Der Belegkern enthält den Zweig `Receipts/Switzerland/`; die Einstellungsseite `SwitzerlandSettingsController` ist in `GetSettingsWithoutModule()` registriert; im EDI-Zweig besteht zusätzlich `AlsoCH`. +Aussage: Das System soll länderspezifische Belegausprägungen für die Schweiz — insbesondere Einzahlungsscheine und Referenznummern — als eigene, konfigurierbare Erweiterung bereitstellen. +Ergebnis: Schweizer Installationen erzeugen landeskonforme Belege. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `new SwitzerlandSettingsController()` in `GetSettingsWithoutModule()` - Begründung: die Einstellungsseite ist fest registriert. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/Switzerland/`, `src/backend/Centron.BL/EDI/AlsoCH/` - Begründung: eigene Codezweige für die Schweiz. +Prüfidee: Bei aktivierter Schweiz-Einstellung muss die Rechnungsausgabe die schweizspezifischen Felder enthalten. +Tracelinks: SyRS-008, SyRS-110 +Konsolidierung: nein +Übernahmewürdigkeit: Sonderfall - länderspezifische Ausprägung für einen Teil der Kundschaft; im Zielsystem als Länderpaket zu führen. +Status: belegt +``` + +## 3. Verträge und Abrechnungskomponenten + +``` +ID: SwRS-030 +Titel: Kontingentfelder als eigenständige Vertragsattribute +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Vertrag führt ein Kontingent. +Fakt: `ReceiptContract` führt getrennte Felder für verbrauchte Stunden und Beträge (`ContingentUsedHours`, `ContingentUsedAmount`), für Saldogrößen (`ContingentBalanceUsedHours`, `ContingentBalanceUsedAmount`), für den Restwertstart (`ContingentResidualValueStart`, `ContingentResidualValueStartDate`) sowie für Grenzwerte (`IsContingentLimitBilling`, `ContingentLimitValue`, `ContingentLimitKind`) und Überwachung (`IsMonitoring`, `MonitoringValue`). +Aussage: Das System soll Kontingentverbrauch, Saldo, Restwert, Grenzwert und Überwachungsschwelle als getrennte Vertragsattribute führen. +Ergebnis: Verbrauch und Grenzwertüberschreitung sind unabhängig voneinander auswertbar. +Belege: + - [PRIMÄR] `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs`, die genannten Eigenschaften - Begründung: die Felder sind einzeln persistiert. + - [KONTEXT] `docs/reference/receipts/contracts-backend.md`, Abschnitte „Contingent Management" und „Contingent Limits and Monitoring" - Begründung: benennen die Feldsemantik. +Prüfidee: Ein Vertrag mit überschrittenem Grenzwert muss dies unabhängig vom Restwert ausweisen. +Tracelinks: SyRS-030 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-031 +Titel: Getrennte Ausgleichsartikel für Vertrag und Pauschale +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Saldo ist auszuweisen. +Fakt: `ArticleBL` stellt zwei getrennte Methoden bereit: `GetFlatrateBalanceArticle()` (Zeile 143) für die Pauschalabrechnung und `GetContractBalanceArticle()` (Zeile 151) für die Vertragsabrechnung. +Aussage: Das System soll für Vertrags- und Pauschalabrechnung je einen eigenen Ausgleichsartikel führen. +Ergebnis: Saldopositionen sind nach Abrechnungsart getrennt auswertbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `GetFlatrateBalanceArticle` und `GetContractBalanceArticle` als getrennte Methoden - Begründung: die Trennung ist im Code umgesetzt. +Prüfidee: Eine Pauschalabrechnung darf nicht den Vertragsausgleichsartikel verwenden. +Tracelinks: SyRS-031, SyRS-064 +Konsolidierung: Kandidat: SwRS-065 — beide Artikel erfüllen die gleiche Funktion „Saldoausgleich" in getrennten Konfigurationen. +Übernahmewürdigkeit: übernehmen - im Zielsystem als ein Ausgleichsartikel mit Abrechnungsartkennzeichen. +Status: belegt +``` + +``` +ID: SwRS-032 +Titel: Abrechnungslauf über benannte Abfragen je Vorgangsart +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Abrechnungslauf startet. +Fakt: `AutomaticFacturaBL` verwendet je Vorgangsart eine eigene benannte Abfrage: `NamedQueryEnums.Asset.GetCustomersForAutomatedBilling`, `GetContractsForAutomatedBillingLight`, `GetOrdersForAutomatedBilling`; die Ergebnisse werden über `AutomaticFacturaCustomer` und `AutomaticFacturaContract` typisiert. +Aussage: Das System soll die Ermittlung abrechenbarer Vorgänge je Vorgangsart über eine eigene, benannte Abfrage ausführen und die Ergebnisse typisiert bereitstellen. +Ergebnis: Der Abrechnungslauf verarbeitet große Datenmengen ohne objektweise Prüfung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `SearchCustomers` mit `NamedQueryAccess().GetNamedQuery(NamedQueryEnums.Asset.GetCustomersForAutomatedBilling)` (Zeile 457) und `SearchBillingOrders` mit `GetOrdersForAutomatedBilling` (Zeile 118) - Begründung: die Abfragen führen die Ermittlung aus. +Prüfidee: Der Lauf über 1.000 Verträge darf keine 1.000 Einzelabfragen erzeugen. +Tracelinks: SyRS-032, SwRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-033 +Titel: Import externer Vertragspositionen mit Zeitraumfilter +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertragsverwaltung +Vorbedingung: Importierte Vertragspositionen sind zu suchen. +Fakt: `AutomaticFacturaBL.SearchSpecialArticleToContractHead(SearchSpecialArticleToContractHeadFilter headFilter)` normalisiert den Zeitraum: `BillingDateValidFrom` wird auf `.Date` gesetzt, `BillingDateValidTo` auf `.Date.AddDays(1).AddMilliseconds(-1)`; ein Schalter `ToBillingOnly` beschränkt auf abrechenbare Einträge. +Aussage: Das System soll den Suchzeitraum für importierte Vertragspositionen tagesgenau normalisieren, sodass der Endtag vollständig eingeschlossen ist. +Ergebnis: Am Endtag importierte Positionen fallen nicht aus dem Suchergebnis. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `SearchSpecialArticleToContractHead`, Zeilen 319-327 - Begründung: die Normalisierung erfolgt dort tatsächlich. +Prüfidee: Eine Position mit Zeitstempel 23:59 des Endtags muss im Ergebnis enthalten sein. +Tracelinks: SyRS-033 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die Randbehandlung ist im Zielsystem beizubehalten. +Status: belegt +``` + +``` +ID: SwRS-034 +Titel: Rechteausdrücke der Modulregistrierung +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Die Anwendung startet. +Fakt: `ModuleRegistrationItem.For(Expression> rights, Expression> features)` nimmt zwei Ausdrücke entgegen; `ModuleRightsExpressionParser` wertet sie aus, `Helper.HasRights(params int[])` prüft die Rechte; `GetRightsForModule(ICentronAppModuleController)` liefert die für ein Modul erforderlichen Rechte-IDs zurück. +Aussage: Das System soll die Rechte- und Lizenzbedingung eines Moduls als auswertbaren Ausdruck hinterlegen, sodass die erforderlichen Rechte eines Moduls auch rückwärts ermittelbar sind. +Ergebnis: Zu jedem Modul sind die erforderlichen Rechte maschinell auslesbar. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `GetRightsForModule`, Zeilen 220-223, `_modules.FirstOrDefault(f => f.ModuleType == controller.GetType())?.GetRights()` - Begründung: die Rückwärtsermittlung ist tatsächlich implementiert. + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRightsExpressionParser.cs` - Begründung: wertet die Ausdrücke aus. +Prüfidee: `GetRightsForModule` muss für das Rechnungsmodul die Rechte-IDs des Rechnungszweigs liefern. +Tracelinks: SyRS-034, SyRS-170 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - erlaubt die Ableitung einer Rechtematrix aus dem Code. +Status: belegt +``` + +``` +ID: SwRS-035 +Titel: Filterstruktur der Ticketabrechnung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Abrechenbare Zeiten werden gesucht. +Fakt: `TimerBillingBL` stellt `SearchTimers(TimerBillingFilter filter)`, `GetArticles()`, `GetArticleWorkItems(List customerI3Ds)`, `GetContracts(List customerI3Ds, List alwaysIncludeContractI3Ds)` und `GetTimerBillingStates()` bereit; `SaveTimer(TimerForTimerBillingDTO timer, LoggedInUser currentUser)` schreibt Änderungen zurück. +Aussage: Das System soll die Ticketabrechnung über einen Filter aus Kunden, Verträgen, Artikeln, Arbeitsschritten und Abrechnungszuständen steuern und für mehrere Kunden gleichzeitig auswerten. +Ergebnis: Der Abrechnungslauf lässt sich fachlich eingrenzen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs`, `SearchTimers` (Zeile 233), `GetContracts(List customerI3Ds, List alwaysIncludeContractI3Ds)` (Zeile 153) - Begründung: die Signaturen belegen die Mehrkundenauswertung und die Filterdimensionen. +Prüfidee: Ein Filter auf zwei Kunden muss Zeiten beider Kunden liefern, Zeiten eines dritten Kunden nicht. +Tracelinks: SyRS-035 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-036 +Titel: Berechnung der Zuschlagsüberschneidungen +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Zeiteintrag wird bewertet. +Fakt: `HelpdeskTimerBL` bietet drei Überladungen von `CalculateHourlySurchargeRateOverlaps`: für `HelpdeskTimerCompact`, für `HelpdeskTimer` und für `(DateTime start, DateTime end, int? contractI3D)` beziehungsweise `(DateTime start, DateTime end, HourlySurchargeRate rate)`; das Ergebnis ist `List`. +Aussage: Das System soll die Überschneidung eines Zeitraums mit Zuschlagszeitfenstern als Liste von Teilabschnitten zurückgeben, damit ein Zeiteintrag anteilig mit mehreren Zuschlagssätzen bewertet werden kann. +Ergebnis: Ein über Mitternacht laufender Einsatz wird abschnittsweise korrekt bewertet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `CalculateHourlySurchargeRateOverlaps` in den Zeilen 173, 180, 187 und 235 - Begründung: die Rückgabe als Liste belegt die abschnittsweise Bewertung. +Prüfidee: Ein Einsatz von 20:00 bis 02:00 Uhr muss mindestens zwei Teilabschnitte liefern. +Tracelinks: SyRS-036 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 4. Service- und Ticketkomponenten + +``` +ID: SwRS-040 +Titel: Zeiterfassung als eigenständiges, durch eine Kennung identifiziertes Objekt +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Zeiterfassung läuft. +Fakt: `HelpdeskTimeRecordingBL` identifiziert die laufende Erfassung über eine Zeichenkette `guid` (`PauseRecording(string guid, int helpdeskI3D, AppUser currentUser, bool createHistoryEntry)`, ebenso `ResumeRecording`, `StopRecording`, `ClearRecording`, `SaveTimeRecordingComment`); `RecordingInformation` trägt den Zustand, `ClearRecordings(List, AppUser, bool)` verwirft mehrere Erfassungen gemeinsam. +Aussage: Das System soll jede laufende Zeiterfassung über eine eigene Kennung identifizieren, sodass ein Mitarbeiter mehrere Erfassungen parallel führen kann. +Ergebnis: Parallele Erfassungen an verschiedenen Tickets sind unterscheidbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimeRecordingBL.cs`, Signaturen mit `string guid` in `PauseRecording` (Zeile 277), `ResumeRecording` (317), `StopRecording` (357), `ClearRecording` (398) - Begründung: die Kennung ist an allen Zustandsübergängen der Identifikator. + - [SEKUNDÄR] ebenda, `ClearRecordings(List recordingsToClear, …)`, Zeile 429 - Begründung: belegt die Mehrfachhaltung. +Prüfidee: Zwei gleichzeitig laufende Erfassungen desselben Mitarbeiters müssen unabhängig voneinander pausierbar sein. +Tracelinks: SyRS-040 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-041 +Titel: Hinweise auf laufende Erfassungen als eigene Datensätze +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Erfassung läuft ungewöhnlich lange. +Fakt: `HelpdeskTimeRecordingBL.GetStopwatchNotificationsForEmployee(int employeeI3D)` liefert `List`, `DeleteStopwatchNotifications(List notificationI3Ds, int? helpdeskI3D, int? employeeI3D)` entfernt sie gezielt oder gesammelt. +Aussage: Das System soll Hinweise auf laufende Zeiterfassungen als eigene, je Mitarbeiter abrufbare und einzeln löschbare Datensätze führen. +Ergebnis: Hinweise verschwinden erst, wenn der Mitarbeiter sie bearbeitet hat. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimeRecordingBL.cs`, `GetStopwatchNotificationsForEmployee` (Zeile 506) und `DeleteStopwatchNotifications` (Zeile 518) - Begründung: die Hinweise sind persistiert und gezielt entfernbar. +Prüfidee: Ein bearbeiteter Hinweis darf beim nächsten Abruf nicht mehr erscheinen. +Tracelinks: SyRS-041 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-042 +Titel: Unterschrift als eigenständige Entität je Zeiteintrag +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Unterschrift wird erfasst. +Fakt: `HelpdeskTimerSignatureBL` speichert `HelpdeskTimerSignatureCompact` mit `HelpdeskTimerI3D` und `Signature` (`byte[]`); `AddSignature(int helpdeskTimerI3D, string signature, AppUser)` wandelt eine Zeichenkettendarstellung in ein Bytefeld; `GetSignature(int helpdeskTimerI3D)` liest sie zurück; `HelpdeskSignatureExists` verhindert eine zweite Unterschrift. +Aussage: Das System soll die Unterschrift als eigene Entität mit Bezug auf genau einen Zeiteintrag speichern und sie als Bytefeld ablegen. +Ergebnis: Die Unterschrift ist unabhängig vom Zeiteintrag lesbar und nicht überschreibbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs`, `AddSignature` (Zeile 31) mit vorangehender Prüfung `HelpdeskSignatureExists` (Zeile 62) und `GetSignature` (Zeile 67) - Begründung: Einmaligkeit und Speicherform sind dort festgelegt. +Prüfidee: Ein zweiter `AddSignature`-Aufruf für denselben Zeiteintrag darf keine zweite Entität erzeugen. +Tracelinks: SyRS-042, StRS-015 +Konsolidierung: Kandidat: SwRS-124 — Unterschriften am Zeiteintrag und am geteilten Dokument werden in getrennten Datenhaltungen geführt. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-043 +Titel: Protokoll der Zeiteintragsänderungen +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Revision +Vorbedingung: Ein Zeiteintrag wird verändert. +Fakt: `HelpdeskTimerLogBL` schreibt Protokolleinträge; `HelpdeskTimerSignatureBL.AddSignature` ruft `new HelpdeskTimerLogBL(this.Session).AddSignatureLog(...)` auf; weitere Bausteine sind `HelpdeskTimerTypeBL`, `HelpdeskTimerSettingsBL`, `HelpdeskTimerArticleBookingBL`, `HelpdeskTimerAddressSpecialArticlesBL` und `HelpdeskTimerBookedArticlesFilter`. +Aussage: Das System soll jede Änderung an einem Zeiteintrag — einschließlich der Unterschriftserfassung — in einem eigenen Protokoll festhalten. +Ergebnis: Nachträgliche Änderungen an abrechnungsrelevanten Zeiten sind nachweisbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs`, Zeile 51, Aufruf `AddSignatureLog(new HelpdeskTimerBL(this.Session).GetHelpdeskTimerByI3D(helpdeskTimerI3D), currentUser)` - Begründung: der Protokolleintrag entsteht tatsächlich bei der Unterschriftserfassung. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerLogBL.cs` - Begründung: die Protokollkomponente. +Prüfidee: Nach der Unterschriftserfassung muss ein Protokolleintrag mit Benutzer und Zeitpunkt vorliegen. +Tracelinks: SyRS-042, StRS-051 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Abrechnungsrelevanz. +Status: belegt +``` + +``` +ID: SwRS-050 +Titel: Pflichtfeldprüfung als eigene, überspringbare Stufe +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Ticket wird gespeichert. +Fakt: `HelpdeskBL.Save(Helpdesk entity, LoggedInUser currUser, bool ignoreMandatoryFields)` überschreibt die Basismethode und ruft `DoValidateMandatoryFields` nur bei `ignoreMandatoryFields == false`; die Fehlermeldungen werden in einem `StringBuilder` gesammelt, sodass mehrere fehlende Pflichtfelder gemeinsam gemeldet werden. +Aussage: Das System soll alle fehlenden Pflichtfelder eines Tickets in einer gemeinsamen Meldung ausweisen und die Prüfung nur über einen ausdrücklichen Schalter überspringen. +Ergebnis: Der Anwender erfährt alle fehlenden Angaben in einem Durchgang. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `DoValidateMandatoryFields`, Zeile 658, mit `var messageBuilder = new StringBuilder();` und `messageBuilder.AppendLine("Kein Kunde ausgewählt");` - Begründung: die Sammlung der Meldungen ist dort umgesetzt. +Prüfidee: Ein Ticket ohne Kunde und ohne Kategorie muss beide Mängel in einer Meldung nennen. +Tracelinks: SyRS-050 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-051 +Titel: Rechteprüfung im Vorspeicherschritt der Ticketentität +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Ticket wird gespeichert. +Fakt: `HelpdeskBL.DoBeforeSave(Helpdesk entity, LoggedInUser currUser, bool isNew)` ruft nacheinander die Basisimplementierung, `CheckRights(entity, currUser, isNew)`, bei Neuanlage `AddShortDescriptionPrefix`, dann `ReplaceLineEndings`, `CheckTextFieldLengths` und `UpdateContractProperty` auf und liefert das Ergebnis der Rechteprüfung zurück. +Aussage: Das System soll die Rechteprüfung eines Tickets im Vorspeicherschritt der Entität ausführen, sodass jeder Speicherweg — auch aus Webservice und Hintergrunddiensten — sie durchläuft. +Ergebnis: Kein Speicherweg umgeht die Rechteprüfung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `DoBeforeSave`, Zeilen 310-326 - Begründung: die Prüfung ist in den gemeinsamen Vorspeicherschritt eingebettet. +Prüfidee: Ein Ticketspeichern über die REST-Schnittstelle ohne `EDIT_HELPDESK` muss ebenso scheitern wie im Rich-Client. +Tracelinks: SyRS-051 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - verhindert Lücken bei neuen Aufrufwegen. +Status: belegt +``` + +``` +ID: SwRS-052 +Titel: Feldlängen als Konstanten im Vorspeicherschritt +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Ein Ticket wird gespeichert. +Fakt: `HelpdeskBL.CheckTextFieldLengths` schneidet die Felder auf feste Längen (1000, 100, 100, 250, 50, 50, 250, 50) zu; die Grenzen sind als Zahlenliterale im Quelltext hinterlegt, ein Kommentar verweist auf die Spaltenlängen von `hlpdsk_requests` und auf die Abbildung in `HelpdeskMaps.cs`; für `ShortDescription` weicht die Grenze (1000) vom Datenbanktyp (`nvarchar(2000)`) ab. +Aussage: Das System soll die zulässigen Feldlängen aus einer Quelle ableiten statt sie in der Fachlogik als Zahlenliterale zu wiederholen. +Ergebnis: Datenbankschema, Abbildung und Fachlogik bleiben konsistent. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckTextFieldLengths`, Zeilen 333-348, mit dem Kommentar `// nvarchar:2000 > string:1000` - Begründung: die Abweichung zwischen Datenbanktyp und Fachlogikgrenze ist dort selbst dokumentiert. +Prüfidee: Die in `HelpdeskMaps.cs` hinterlegten Längen müssen mit den Literalen in `CheckTextFieldLengths` übereinstimmen. +Tracelinks: SyRS-052 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - dreifach gepflegte Längenangaben; im Zielsystem aus einer Quelle abzuleiten. +Status: belegt +``` + +``` +ID: SwRS-053 +Titel: Variablenersetzung über eine gemeinsame Komponente +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Wiederverwendbarkeit) +Akteur: Entwicklung +Vorbedingung: Ein Text enthält Platzhalter. +Fakt: `ReplacementBL().ReplaceVariables(prefix, variablesAndValues, "@@")` ersetzt Platzhalter mit dem Begrenzer `@@`; dieselbe Notation findet sich in `WebAccountBL.SendWebAccountPasswordMail` (`@@Passwort@@`) und in der Mailvorlagenverarbeitung (`Mail/VariableReplacement/`); der Belegkern besitzt eine eigene Region „Mail and Variables". +Aussage: Das System soll Platzhalter in Texten durchgängig mit dem Begrenzer `@@` kennzeichnen und über eine gemeinsame Ersetzungskomponente auflösen. +Ergebnis: Platzhalter verhalten sich in Ticketpräfixen, Mailvorlagen und Belegtexten gleich. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `AddShortDescriptionPrefix` mit `new ReplacementBL().ReplaceVariables(prefix, variablesAndValues, "@@")` - Begründung: zeigt Komponente und Begrenzer. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, Zeile 563, `.Replace("@@Passwort@@", newPassword)` - Begründung: dieselbe Notation, jedoch mit einfacher Zeichenkettenersetzung statt der gemeinsamen Komponente. + - [SEKUNDÄR] `src/backend/Centron.BL/Mail/VariableReplacement/` - Begründung: eigener Zweig für die Mailvariablen. +Prüfidee: Ein unbekannter Platzhalter muss in allen drei Verwendungen gleich behandelt werden. +Tracelinks: SyRS-053, SyRS-113 +Konsolidierung: Kandidat: SwRS-053 selbst — `ReplacementBL`, `Mail/VariableReplacement` und die direkte Zeichenkettenersetzung in `WebAccountBL` lösen dieselbe Aufgabe dreifach. +Übernahmewürdigkeit: übernehmen - im Zielsystem mit genau einer Ersetzungskomponente. +Status: belegt +``` + +``` +ID: SwRS-054 +Titel: Abschlussstatus des Tickets aus den Einstellungen +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Ticket wird abgeschlossen. +Fakt: `HelpdeskSettingsBL.GetClosedHelpdeskState()` liefert den als Abschluss konfigurierten Status; `HelpdeskCloseBL.CloseHelpdesk` setzt ihn, `HelpdeskBL.CheckUserRigths` vergleicht `entity.HelpdeskState` gegen denselben Wert, um das Recht `CLOSE_REQUEST` zu prüfen, und setzt andernfalls `entity.ClosedAt = null`. +Aussage: Das System soll den Abschlussstatus eines Tickets nicht fest im Code hinterlegen, sondern aus der Konfiguration beziehen, und den Abschlusszeitpunkt zurücksetzen, sobald ein Ticket den Abschlussstatus verlässt. +Ergebnis: Der Abschlusszeitpunkt ist nur bei tatsächlich geschlossenen Tickets gesetzt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckUserRigths`, Zeilen 433-443, mit `else { entity.ClosedAt = null; }` - Begründung: das Zurücksetzen des Abschlusszeitpunkts erfolgt dort. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `this._helpdeskSettingsBL.GetClosedHelpdeskState()` in `CloseHelpdesk` - Begründung: der Status stammt aus der Konfiguration. +Prüfidee: Ein wiedereröffnetes Ticket darf keinen Abschlusszeitpunkt mehr tragen. +Tracelinks: SyRS-054, SyRS-051 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-055 +Titel: Sammelabschluss von Tickets aus der Wartung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Viele Tickets sind gemeinsam abzuschließen. +Fakt: `HelpdeskCloseBL.CloseHelpdesk(IList helpdesks, AppUser currentUser)` führt die benannte Abfrage `NamedQueryEnums.Helpdesk.CloseHelpdesksFromMaintenance` mit dem Abschlussstatus und einer Liste von IDs aus und gibt stets `Result.AsSuccess()` zurück; die sonst üblichen Folgeaktionen (Aufgabenlöschung, Historie, Kundenaktivität, Benachrichtigung) unterbleiben. +Aussage: Das System soll den Sammelabschluss vieler Tickets in einer Datenbankanweisung ermöglichen. [HYPOTHESE] Ob das Auslassen von Historie, Kundenaktivität und Aufgabenlöschung fachlich gewollt ist oder eine Lücke darstellt, geht aus den Artefakten nicht hervor. +Ergebnis: Die Tickets tragen den Abschlussstatus, jedoch ohne Historieneintrag. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `CloseHelpdesk(IList, AppUser)`, Zeilen 108-118 - Begründung: die Methode enthält ausschließlich die Massenaktualisierung und keine Folgeaktionen. +Prüfidee: Nach dem Sammelabschluss ist zu prüfen, ob für die betroffenen Tickets ein Historieneintrag vom Typ `Close` erwartet wird. +Tracelinks: SyRS-054, StRS-051 +Konsolidierung: Kandidat: SwRS-054 — Einzel- und Sammelabschluss bilden denselben Vorgang mit unterschiedlichem Umfang ab. +Übernahmewürdigkeit: übernehmen - im Zielsystem mit einheitlichen Folgeaktionen. +Status: HYPOTHESE +``` + +``` +ID: SwRS-056 +Titel: Umfragezuordnung über Kontaktsuche per E-Mail-Adresse +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Abschlussmail wird erzeugt. +Fakt: `HelpdeskCloseBL.AddSurvey` ermittelt den Account über `new AccountBL(this.Session).ExistsAccountForOldCustomer(helpdesk.Customer.I3D).Data` und den Kontakt über `new AccountSearchBL(this.Session).SearchAccountContactByAdSearchstring(accountI3D.Value, eMail)`; nur bei gefundenem Kontakt wird der Umfragetext über `TextHelper.AppendRtfToHtml(mailBody, result.MailText)` angehängt. +Aussage: Das System soll den Umfrageempfänger anhand seiner E-Mail-Adresse als Kontakt des Accounts auflösen und die Umfrage nur bei erfolgreicher Auflösung anhängen. +Ergebnis: Umfragen erreichen nur bekannte Kontakte. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `AddSurvey`, Zeilen 209-233, mit der Bedingung `if (contact.Data != null)` - Begründung: die Bedingung entscheidet über das Anhängen. + - [SEKUNDÄR] ebenda, `ExistsAccountForOldCustomer` - Begründung: belegt die Brücke vom Alt-Kundenstamm zum Account-Stamm. +Prüfidee: Eine Abschlussmail an eine unbekannte Adresse darf keine Umfrage enthalten. +Tracelinks: SyRS-056, SyRS-002 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-057 +Titel: Bausteine der Ticketverwaltung +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modularität) +Akteur: Entwicklung +Vorbedingung: Eine Ticketfunktion wird geändert. +Fakt: Der Zweig `Sales/Support` enthält 49 Fachlogikklassen, darunter `HelpdeskBL`, `HelpdeskCloseBL`, `HelpdeskForwardBL`, `HelpdeskHistoryBL`, `HelpdeskMailBL`, `HelpdeskSendMailBL`, `HelpdeskSolutionBL`, `HelpdeskSearchBL`, `HelpdeskOverviewFilterBL`, `HelpdeskFavoritesBL`, `HelpdeskDirectoryBL`, `HelpdeskDeviceLinkBL`, `HelpdeskAssetBL`, `HelpdeskConnectionNumberBL`, `HelpdeskCustomerBL`, `HelpdeskReplacementBL`, `HelpdeskReportBL`, `HelpdeskStatisticsBL`, `SupportLevelBL`, `TicketListBL`, `UpdateHelpdeskBL`, `UserHelpdeskDataBL`. +Aussage: Das System soll die Ticketfunktionen in eigenständige, nach Aufgabe geschnittene Fachlogikklassen aufteilen. +Ergebnis: Änderungen an einer Ticketfunktion berühren die übrigen nicht. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/` mit den genannten 49 Klassen - Begründung: die Aufteilung ist im Verzeichnis unmittelbar erkennbar. +Prüfidee: Eine Änderung an der Ticketweiterleitung darf keine Änderung an `HelpdeskBL` erfordern. +Tracelinks: SyRS-057, SyRS-051 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - vorbildliche Aufteilung, im Gegensatz zum Belegkern. +Status: belegt +``` + +``` +ID: SwRS-058 +Titel: Ticketmuster mit acht Konfigurationsdimensionen +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Ein Ticketmuster wird gepflegt. +Fakt: Der Musterbearbeiter besteht aus acht Reitern: `TicketPatternGeneralTab`, `TicketPatternCustomerTab`, `TicketPatternInternalTab`, `TicketPatternChecklistsTab`, `TicketPatternFormsTab`, `TicketPatternMailTemplateTab`, `TicketPatternPropertiesTab`, `TicketPatternScriptsTab`, `TicketPatternWebFormTab`; hinzu kommen `TicketPatternCategoryEditor` und `TicketPatternTree`; die REST-Ressource ist `TicketPatternsController`. +Aussage: Das System soll Ticketmuster in einer Baumstruktur führen und je Muster Allgemeindaten, Kundenbezug, interne Angaben, Checklisten, Formulare, Mailvorlage, Eigenschaften, Skripte und Webformular konfigurierbar machen. +Ergebnis: Aus einem Muster entstehen vollständig vorbelegte Tickets. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus/Management/TicketPatterns/Components/` mit den neun genannten Reiterkomponenten und `TicketPatternTree.razor` - Begründung: die Komponenten belegen den Konfigurationsumfang. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/v1/Tickets/TicketPatternsController.cs` - Begründung: eigene REST-Ressource. +Prüfidee: Ein Ticket aus einem Muster mit hinterlegter Checkliste muss diese Checkliste tragen. +Tracelinks: SyRS-058, SyRS-125 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-059 +Titel: Filter-, Formatierungs- und Verdichtungseditor der Ticketliste +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Helpdesk-Mitarbeiter +Vorbedingung: Eine Ticketansicht wird eingerichtet. +Fakt: Die zwischengespeicherte Ticketliste bringt eigene Komponenten mit: `FilterEditor`, `FilterEditorGroup`, `FilterEditorItem`, `ConditionalFormattingEditor`, `SummaryEditor`, `KanbanBucketSelection`, `KanbanBucket`, `KanbanTicketCard` sowie Auswahlkomponenten für Filiale, Kategorie, Mitarbeiter, Priorität, Vertriebsgebiet, Status und Typ; `NexusTicketViewBL` speichert die Ansichten, `DeleteGlobalViewDialog` verwaltet globale Ansichten. +Aussage: Das System soll Ticketansichten mit gruppierbaren Filtern, bedingter Formatierung, Verdichtungszeilen und Kanban-Spalten konfigurierbar machen und die Ansichten persönlich oder global speichern. +Ergebnis: Jeder Bearbeiter arbeitet mit einer auf seine Aufgabe zugeschnittenen Ticketliste. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus/ServiceBoard/CachedTicketList/Components/` mit `FilterEditorGroup.razor`, `ConditionalFormattingEditor.razor`, `SummaryEditor.razor`, `KanbanBucketSelection.razor` - Begründung: die Komponenten belegen den Konfigurationsumfang. + - [PRIMÄR] `src/backend/Centron.BL/NexusTicketViews/NexusTicketViewBL.cs` - Begründung: speichert die Ansichten. + - [SEKUNDÄR] `src/nexus/CentronNexus/ServiceBoard/CachedTicketList/Dialogs/DeleteGlobalViewDialog.razor` - Begründung: belegt die Unterscheidung persönlicher und globaler Ansichten. +Prüfidee: Eine gespeicherte Ansicht mit Filter auf „eigene offene Tickets" muss nach erneutem Anmelden unverändert erscheinen. +Tracelinks: SyRS-059, SyRS-052 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 5. Warenwirtschaftskomponenten + +``` +ID: SwRS-060 +Titel: Barcode-Zustand als Aufzählung mit Historie +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Einzelstück wechselt den Zustand. +Fakt: `BarcodeState` wird in `RmaBL` mit den Werten `InStock`, `InRequest`, `InDeliveryList`, `InInvoice` und `ManuallyBookedOut` verwendet; `BarcodeBL`, `BarcodeHistoryBL` und `BarcodeConditionBL` verwalten Zustand, Historie und Bedingungen; die Tabelle `Barcode` hält den aktuellen Zustand, `SeriennummerToPosition` die Belegzuordnung. +Aussage: Das System soll den Zustand eines Einzelstücks als Aufzählung führen und jeden Wechsel zusätzlich in einer Historie festhalten. +Ergebnis: Der aktuelle Zustand ist schnell abfragbar, der Verlauf vollständig. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/CustomerArea/RmaBL.cs`, Verwendungen von `BarcodeState.*` in den Zeilen 179, 192, 201, 266, 312-313 - Begründung: belegen die Aufzählungswerte und ihre Verwendung. + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/BarcodeHistoryBL.cs` - Begründung: führt die Historie. +Prüfidee: Nach drei Zustandswechseln müssen drei Historieneinträge vorliegen. +Tracelinks: SyRS-060 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-061 +Titel: Prüfkomponente für Barcodes im Beleg +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Beleg mit Barcodes wird gespeichert. +Fakt: `ReceiptBL` hält ein Feld `_receiptBarcodeBL` und ruft `CheckIfAllNonActiveBarcodesAreStillInTheReceipt(receipt, previousReceiptVersion)`; die Bezeichnung „NonActive" bezieht sich auf bereits verbuchte Barcodes. +Aussage: Das System soll die Prüfung der Barcodes eines Belegs in einer eigenen Komponente kapseln, die den aktuellen Beleg gegen seine Vorgängerversion vergleicht. +Ergebnis: Die Prüflogik ist unabhängig vom Belegkern änderbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Aufruf `this._receiptBarcodeBL.CheckIfAllNonActiveBarcodesAreStillInTheReceipt(receipt, previousReceiptVersion)` - Begründung: die Komponente wird dort aufgerufen und ihr Ergebnis ausgewertet. +Prüfidee: Die Prüfung darf nur bei vorhandener Vorgängerversion durchlaufen werden. +Tracelinks: SyRS-061 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-062 +Titel: Inventurdatenmodell mit Zählgruppen +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Inventur wird durchgeführt. +Fakt: `InventoryNewBL` arbeitet mit `Inventory2`, `InventoryFilter`, `InventoryRequest`, `InventoryResponse`, `InventoryArticlesDTO`, `InventoryArticleFilter`, `InventoryStatisticResult` und `InventoryLog`; `GetInventoryGroupArticles(InventoryArticleFilter)` und `ChangeInventoryGroup(List inventoryArticlesI3Ds, int newGroupI3D)` bilden die Zählgruppen ab; `InventoryArticlePool` liegt im Zweig `Storage`. +Aussage: Das System soll Inventurpositionen Zählgruppen zuordnen, deren Zuordnung nachträglich änderbar halten und je Inventur ein Protokoll sowie eine Auswertung führen. +Ergebnis: Zählungen sind gruppenweise organisierbar und auswertbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryNewBL.cs`, `ChangeInventoryGroup` (Zeile 331) und `GetInventoryGroupArticles` (Zeile 251) - Begründung: belegen die Zählgruppen als eigenständiges Ordnungsmerkmal. +Prüfidee: Eine Position, die in eine andere Zählgruppe verschoben wurde, muss dort und nicht mehr in der alten Gruppe erscheinen. +Tracelinks: SyRS-062 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-063 +Titel: Zwei Inventurimplementierungen nebeneinander +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modifizierbarkeit) +Akteur: Entwicklung +Vorbedingung: Die Inventur wird gepflegt. +Fakt: Im Zweig `Warehousing/InventoryManagement` bestehen `InventoryBL.cs` und `InventoryNewBL.cs` als getrennte Klassen; die neuere arbeitet mit der Entität `Inventory2`. +Aussage: Das System soll die Inventur in genau einer Implementierung führen; die Altimplementierung ist nach Abschluss der Umstellung zu entfernen. +Ergebnis: Änderungen an der Inventurlogik sind nur an einer Stelle vorzunehmen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryBL.cs` und `InventoryNewBL.cs` - Begründung: beide Klassen bestehen parallel im selben Verzeichnis. + - [SEKUNDÄR] `InventoryNewBL.cs`, Verwendung der Entität `Inventory2` - Begründung: die Ziffer im Entitätsnamen belegt die Neufassung des Datenmodells. +Prüfidee: Es ist festzustellen, welche der beiden Klassen von der Oberfläche aufgerufen wird; die andere ist zu entfernen. +Tracelinks: SyRS-062 +Konsolidierung: Kandidat: SwRS-062 — `InventoryBL` und `InventoryNewBL` bilden dieselbe Fachfunktion ab. +Übernahmewürdigkeit: veraltet - die Altimplementierung ist durch die Neufassung abgelöst. +Status: belegt +``` + +``` +ID: SwRS-064 +Titel: Rückschreiben der Kommissioniermenge je Position +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lagerist +Vorbedingung: Positionen sind kommissioniert. +Fakt: `ReceiptBL.UpdateReceiptQuantityPicked(AppUser currentUser, CentronObjectKindNumeric receiptKind, int receiptI3D, Guid? concurrencyControlGuid, IList items)` schreibt die Mengen mehrerer Positionen in einem Aufruf zurück und prüft dabei die Nebenläufigkeitskennung. +Aussage: Das System soll die kommissionierten Mengen mehrerer Positionen in einem Vorgang zurückschreiben und dabei die Nebenläufigkeitskennung des Belegs prüfen. +Ergebnis: Kommissionierergebnisse werden vollständig oder gar nicht übernommen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptQuantityPicked`, Zeile 5031 - Begründung: Signatur und Nebenläufigkeitsprüfung belegen die Anforderung. +Prüfidee: Ein Rückschreiben mit veralteter Kennung darf keine der übergebenen Mengen übernehmen. +Tracelinks: SyRS-063, SyRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-065 +Titel: Systemartikel als konfigurierte Einzelverweise +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Ein Systemartikel wird benötigt. +Fakt: `ArticleBL` löst je Systemartikelrolle über eine eigene Methode auf; `GetArticleI3DForExternalArticles()` und `GetArticleI3DForNewArticles()` liefern nur die Kennung, `GetFreightArticle()` und `GetCustomerDiscountArticle()` liefern `Result
`; `GetVoucherArticleList()` liefert eine Liste. +Aussage: Das System soll die Systemartikelrollen einzeln konfigurierbar halten und ihre Auflösung ausschließlich über die dafür vorgesehenen Methoden vornehmen. +Ergebnis: Systemartikel sind an einer Stelle austauschbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, Methoden `GetFreightArticle` (166), `GetCustomerDiscountArticle` (190), `GetArticleI3DForExternalArticles` (207), `GetArticleI3DForNewArticles` (215), `GetVoucherArticleList` (235) - Begründung: die Methoden sind die Auflösungsstellen. +Prüfidee: Kein Aufrufer darf einen Systemartikel über eine feste Artikelnummer auflösen. +Tracelinks: SyRS-064 +Konsolidierung: Kandidat: SwRS-031 +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-066 +Titel: Produktfamilien mit Kunden- und Positionssperren +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Vertriebsleitung +Vorbedingung: Ein Artikel gehört einer Produktfamilie an. +Fakt: Das Schema führt `Produktfamilie`, `ProduktfamilieKundenSperren` und `ProduktfamiliePositionSperren`; `ProductFamilyBL` verwaltet die Familien; `ArtikelZubehoer` bildet Zubehörbeziehungen ab, `AdditionalArticleBL` weitere Artikelbeziehungen. +Aussage: Das System soll Artikel zu Produktfamilien zusammenfassen und je Familie sowohl kundenbezogene als auch positionsbezogene Sperren führen. +Ergebnis: Nicht freigegebene Produkte gelangen nicht in Belege. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `Produktfamilie`, `ProduktfamilieKundenSperren`, `ProduktfamiliePositionSperren` - Begründung: die beiden Sperrarten sind als eigene Relationen durchgesetzt. + - [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/ArticleManagement/ProductFamilyBL.cs` - Begründung: verwaltet die Familien. +Prüfidee: Ein für einen Kunden gesperrter Familienartikel darf in dessen Beleg nicht erfassbar sein. +Tracelinks: SyRS-065 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-067 +Titel: Artikelbezogene Zusatzangaben als eigene Komponenten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Artikelverwaltung +Vorbedingung: Ein Artikel wird gepflegt. +Fakt: Der Zweig `Warehousing/ArticleManagement` enthält `AdditionalArticleBL`, `ArticleBranchAccountBL`, `ArticleEANCodeBL`, `ArticleFreeSpecificationBL`, `ArticleHistoryBL`, `ArticleImportBL`, `EnvironmentalProtectionBL`, `ProductFamilyBL` und `WorkSafetyBL`; hinzu kommen `ArticleVariableBL`, `ArticleWorkItemBL`, `SecondStockArticleBL`, `GeneralArticleBL` und die Tabellen `Hersteller`, `HerstellerArtik`, `HerstellerWaren`, `NebenlagerArtikel`. +Aussage: Das System soll artikelbezogene Zusatzangaben — EAN-Codes, freie Merkmale, Umweltangaben, Arbeitsschutzangaben, Herstellerbezug, Nebenlagerbestände und Artikelhistorie — in eigenen Komponenten und Tabellen führen. +Ergebnis: Der Artikelstamm bleibt schlank; Zusatzangaben sind unabhängig erweiterbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleManagement/` mit den neun genannten Klassen - Begründung: die Aufteilung ist im Verzeichnis erkennbar. + - [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `Hersteller`, `HerstellerArtik`, `HerstellerWaren`, `NebenlagerArtikel`, `Barcode` - Begründung: die zugehörigen Datenstrukturen. +Prüfidee: Eine Änderung an den Umweltangaben darf keine Änderung an `ArticleBL` erfordern. +Tracelinks: SyRS-066, SyRS-065 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-068 +Titel: Getrennte Versanddienstleisterbibliotheken mit eigenen Fehlerkatalogen +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Versand +Vorbedingung: Ein Versandauftrag wird übergeben. +Fakt: `Centron.Api.Gls` enthält `CentronGlsLogic`, `CentronGlsConsts`, `CentronGlsErrors`, `Classes/UploadResult`, `Entities/Address`, `Entities/ErrorMessage`, `Entities/ErrorResponse`; `Centron.Api.Shipcloud` enthält `CentronShipcloudLogic`, `CentronShipcloudConsts`, `Classes/UploadResult`, `Entities/AdditionalService`, `AdditionalServiceProperties`, `Address`, `Billing`, `BillingDetails`. Beide Bibliotheken besitzen eigene, nicht gemeinsame Adress- und Ergebnisklassen. +Aussage: Das System soll je Versanddienstleister eine eigene Bibliothek mit eigenem Fehlerkatalog führen; die Belegseite soll die Dienstleister über eine gemeinsame Abstraktion ansprechen. +Ergebnis: Ein zusätzlicher Dienstleister erfordert keine Änderung an der Belegseite. +Belege: + - [PRIMÄR] `src/apis/Centron.Api.Gls/CentronGlsErrors.cs` und `src/apis/Centron.Api.Shipcloud/Entities/` - Begründung: die getrennten Fehler- und Adressklassen belegen die fehlende gemeinsame Abstraktion. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Logistic/ShippingMethodSettings/` mit `ShippingMethodSettingsController` - Begründung: die Versandart ist konfigurierbar und wählt den Dienstleister. +Prüfidee: Der Belegcode darf keine dienstleisterspezifische Klasse unmittelbar verwenden. +Tracelinks: SyRS-067 +Konsolidierung: Kandidat: SwRS-068 selbst — die beiden Bibliotheken bilden dieselbe Fachfunktion mit eigenen Adress- und Ergebnisklassen ab. +Übernahmewürdigkeit: übernehmen - im Zielsystem hinter einer gemeinsamen Versandabstraktion. +Status: belegt +``` + +``` +ID: SwRS-069 +Titel: Paketvorlagen je Beleg +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Versand +Vorbedingung: Ein Versandauftrag wird vorbereitet. +Fakt: `ShipcloudPackageTemplateBL` verwaltet Paketvorlagen; die REST-Ressource `ShipcloudPackageTemplatesController` stellt sie bereit; die Vorlagen liegen im Belegzweig, nicht in der Dienstleisterbibliothek. +Aussage: Das System soll wiederkehrende Paketmaße und -gewichte als Vorlagen führen und sie beim Erzeugen eines Versandauftrags anwenden. +Ergebnis: Standardpakete müssen nicht wiederholt erfasst werden. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ShipcloudPackageTemplateBL.cs` - Begründung: verwaltet die Vorlagen im Belegkontext. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/v1/Receipts/ShipcloudPackageTemplatesController.cs` - Begründung: eigene REST-Ressource. +Prüfidee: Ein Versandauftrag mit ausgewählter Vorlage muss deren Maße übernehmen. +Tracelinks: SyRS-067, SwRS-068 +Konsolidierung: Kandidat: SwRS-068 — die Vorlagen sind dienstleisterspezifisch benannt, obwohl sie fachlich dienstleisterunabhängig sind. +Übernahmewürdigkeit: übernehmen - im Zielsystem dienstleisterneutral zu benennen. +Status: belegt +``` + +## 6. Einkaufs- und Austauschkomponenten + +``` +ID: SwRS-070 +Titel: Lieferantenbelegarten als eigene Codezweige +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modularität) +Akteur: Entwicklung +Vorbedingung: Eine Beschaffungsbelegart wird geändert. +Fakt: Der Belegkern enthält die Zweige `SupplierOrders`, `SupplierDeliveryLists`, `SupplierInvoices`, `SupplierCreditVouchers` und `SupplierReceiptDocuments`; die zugehörigen Einstellungsseiten `SupplierOrderSettingsController`, `SupplierDeliveryListSettingsController`, `SupplierInvoiceSettingsController`, `SupplierCreditVoucherSettingsController` sind einzeln registriert. +Aussage: Das System soll die Beschaffungsbelegarten als eigene Codezweige mit eigenen Einstellungen führen und dabei den gemeinsamen Belegkern nutzen. +Ergebnis: Verkaufs- und Beschaffungsseite bleiben unabhängig konfigurierbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/SupplierOrders/`, `SupplierDeliveryLists/`, `SupplierInvoices/`, `SupplierCreditVouchers/` - Begründung: die getrennten Zweige belegen die Struktur. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, die vier `Supplier*SettingsController` in `GetSettingsWithoutModule()` - Begründung: eigene Einstellungsseiten je Beschaffungsbelegart. +Prüfidee: Eine Änderung an den Lieferantenrechnungseinstellungen darf die Kundenrechnung nicht beeinflussen. +Tracelinks: SyRS-070, SyRS-022 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-071 +Titel: EDI-Verteiler als zentrale Vermittlungsstelle +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modularität) +Akteur: System +Vorbedingung: Ein EDI-Vorgang wird ausgelöst. +Fakt: `EDIDispatcherBL` vermittelt zwischen Fachlogik und den distributorspezifischen Implementierungen; `EDICommonBL` stellt gemeinsame Funktionen bereit, `EDIGatewaySettingBL` die Verbindungsparameter, `EDILogBL` das Protokoll; die Importseite liegt in `EDI/Import`, die Lieferantenseite in `EDI/SupplierEDI`. +Aussage: Das System soll EDI-Vorgänge über eine zentrale Vermittlungsstelle an die distributorspezifische Implementierung weiterreichen und gemeinsame Funktionen nicht je Distributor wiederholen. +Ergebnis: Ein neuer Distributor erfordert keine Änderung an der Fachlogik. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs` und `EDICommonBL.cs` - Begründung: Vermittlung und gemeinsame Funktionen sind eigenständig realisiert. +Prüfidee: Der Aufruf einer EDI-Bestellung darf keine distributorspezifische Klasse unmittelbar verwenden. +Tracelinks: SyRS-071, SyRS-072 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-072 +Titel: Gemeinsame Schnittstellen der EDI-Belegdaten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: EDI-Daten werden gelesen. +Fakt: `ZUGFeRD_BL.ReadInvoice(List distriFiles, SupplierEdiConfigurations config, List lstHead, List> lstItems)` arbeitet mit den Schnittstellen `IEDIReceiptHead` und `IEDIReceiptItems` sowie mit `EDIDistriFile` und `SupplierEdiConfigurations`. +Aussage: Das System soll eingelesene EDI-Belegdaten über gemeinsame Schnittstellen für Belegkopf und Belegpositionen bereitstellen, unabhängig vom Quellformat. +Ergebnis: Die Weiterverarbeitung ist formatunabhängig. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/EDI/Zugferd/ZUGFeRD_BL.cs`, `ReadInvoice`, Zeile 38, mit den Parametern `List` und `List>` - Begründung: die Schnittstellentypen belegen die Formatunabhängigkeit. +Prüfidee: Ein Alltron- und ein ZUGFeRD-Import müssen dieselben Schnittstellentypen liefern. +Tracelinks: SyRS-072, SyRS-071 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-073 +Titel: Einheitliche Struktur der Katalogbibliotheken +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Wiederverwendbarkeit) +Akteur: Entwicklung +Vorbedingung: Ein Katalog wird angebunden. +Fakt: Alle vier Katalogbibliotheken folgen demselben Aufbau: eine Zugriffsklasse (`CopApi.cs`), ein Ausnahmetyp (`CopException.cs`) und ein Verzeichnis `Data/` mit Datenklassen (`Product`, `Price`, `Manufacturer`, `Supplier`, `Description`, `Group`); ITscope ergänzt `ITscopeApiKeyQuota` und `OrderInfo`, Icecat `ProductImage` und `ProductDescription`, EGIS `PriceAndAvailability` und `DistributorItem`. +Aussage: Das System soll Katalogbibliotheken nach einem einheitlichen Aufbau aus Zugriffsklasse, Ausnahmetyp und Datenklassen strukturieren. +Ergebnis: Ein weiterer Katalog lässt sich nach demselben Muster ergänzen. +Belege: + - [PRIMÄR] `src/apis/Centron.APIs.CopDataAccess/CopApi.cs`, `CopException.cs`, `Data/` - Begründung: zeigt den Aufbau am Beispiel. + - [SEKUNDÄR] `src/apis/Centron.APIs.ITscopeDataAccess/Data/`, `Centron.APIs.IcecatDataAccess/Data/`, `Centron.APIs.EgisDataAccess/Data/` - Begründung: dieselbe Struktur in den übrigen Bibliotheken. +Prüfidee: Jede Katalogbibliothek muss eine Zugriffsklasse und einen eigenen Ausnahmetyp besitzen. +Tracelinks: SyRS-073 +Konsolidierung: Kandidat: SwRS-073 selbst — vier gleich aufgebaute Bibliotheken ohne gemeinsame Abstraktion. +Übernahmewürdigkeit: übernehmen - im Zielsystem mit gemeinsamer Katalogschnittstelle. +Status: belegt +``` + +``` +ID: SwRS-074 +Titel: Kontingentangabe als Antwortbestandteil des Katalogs +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Katalogabruf erfolgt. +Fakt: `Centron.APIs.ITscopeDataAccess/Data/ITscopeApiKeyQuota.cs` bildet das Kontingent des API-Schlüssels als eigene Datenklasse ab; die übrigen Katalogbibliotheken führen keine entsprechende Klasse. +Aussage: Das System soll das verbleibende Abrufkontingent, sofern der Katalog es meldet, als eigene Datenstruktur führen und auswerten. +Ergebnis: Kontingentgrenzen sind vor dem Abruf erkennbar. +Belege: + - [PRIMÄR] `src/apis/Centron.APIs.ITscopeDataAccess/Data/ITscopeApiKeyQuota.cs` - Begründung: das Kontingent ist als eigene Klasse modelliert. + - [SEKUNDÄR] `src/apis/Centron.APIs.IcecatDataAccess/Data/`, `Centron.APIs.CopDataAccess/Data/`, `Centron.APIs.EgisDataAccess/Data/` - Begründung: das Fehlen einer entsprechenden Klasse belegt, dass die Kontingentauswertung nur für einen Katalog vorliegt. +Prüfidee: Nach einem Abruf muss das verbleibende Kontingent auslesbar sein. +Tracelinks: SyRS-074 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-075 +Titel: Bestellvorschlagsliste als eigener Codezweig +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Bestellvorschläge werden ermittelt. +Fakt: `Purchasing/OrderSuggestionList/` bildet die Ermittlung ab; das Modul `OrderSuggestionListAppModuleController` ist in der Region „Einkauf" registriert; `Purchasing/PurchaseSettings/` hält die Einkaufseinstellungen, `Purchasing/Suppliers/` die Lieferantenlogik. +Aussage: Das System soll die Bestellvorschlagsermittlung als eigenständigen Baustein führen, der Bedarf, Bestand und Lieferantenkonditionen zusammenführt. +Ergebnis: Die Vorschlagslogik ist unabhängig von der Bestellabwicklung änderbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Purchasing/OrderSuggestionList/` - Begründung: eigener Codezweig. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList/` - Begründung: eigene Bedienoberfläche. +Prüfidee: Eine Änderung der Vorschlagsregel darf die Bestellerfassung nicht berühren. +Tracelinks: SyRS-075 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-076 +Titel: Filialaufteilung als eigener Bestellbaustein +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Eine Bestellung betrifft mehrere Filialen. +Fakt: `Purchasing/SupplierOrderPerBranchBL.cs` bildet die Aufteilung ab; das Oberflächenmodul liegt unter `Modules/DataExchange/SupplierOrderPerBranch/`, also außerhalb des Einkaufsbereichs. +Aussage: Das System soll die filialbezogene Aufteilung von Bestellungen als eigenen Baustein führen und ihn dem Einkaufsbereich zuordnen. +Ergebnis: Die Funktion ist dort auffindbar, wo sie fachlich hingehört. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Purchasing/SupplierOrderPerBranchBL.cs` - Begründung: die Fachlogik liegt im Einkaufszweig. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/DataExchange/SupplierOrderPerBranch/` - Begründung: die Oberfläche liegt im Datenaustauschbereich und weicht damit von der fachlichen Zuordnung ab. +Prüfidee: Die Bedienoberfläche muss im Menü unter „Einkauf" erreichbar sein. +Tracelinks: SyRS-076 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die abweichende Einordnung der Oberfläche ist im Zielsystem zu bereinigen. +Status: belegt +``` + +## 7. Finanzkomponenten + +``` +ID: SwRS-080 +Titel: Dreistufige Erlöskontotabellen +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Erlöskonto wird ermittelt. +Fakt: Das Schema führt drei Zuordnungstabellen mit jeweils Filialbezug: `ArtikelBranchErloeskonto`, `UnterwarenFilialeErloeskonto`, `WarenFilialeErloeskonto`; die zugehörigen Fachlogikklassen sind `ArticleBranchAccountBL` und `BranchRevenueAndExpenseAccountBL`; das Oberflächenmodul „Kontenrahmen" liegt unter `Modules/Warehousing/AccountSystems/`. +Aussage: Das System soll Erlöskonten auf drei Zuordnungsebenen mit Filialbezug führen und die Ermittlung in einer Komponente bündeln. +Ergebnis: Die Kontenfindung ist ohne Kenntnis der Aufrufstelle nachvollziehbar. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `ArtikelBranchErloeskonto`, `UnterwarenFilialeErloeskonto`, `WarenFilialeErloeskonto` - Begründung: die drei Ebenen sind als eigene Relationen durchgesetzt. + - [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleBranchAccountBL.cs`, `src/backend/Centron.BL/Administration/Company/BranchRevenueAndExpenseAccountBL.cs` - Begründung: die Fachlogik der beiden äußeren Ebenen. +Prüfidee: Für einen Artikel ohne eigene Zuordnung muss das Konto der Untergruppe greifen. +Tracelinks: SyRS-080, SyRS-009 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-081 +Titel: Herkunftsangabe als Pflichtparameter der Zahlungsbuchung +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Der Bezahltstatus wird gesetzt. +Fakt: `ReceiptBL.UpdateReceiptIsPaid` führt den Parameter `string moduleOrAction`; er steht in der Signatur zwischen der Nebenläufigkeitskennung und dem Benutzer und ist damit bei jedem Aufruf anzugeben. +Aussage: Das System soll bei jeder Änderung des Bezahltstatus die auslösende Stelle als Pflichtangabe entgegennehmen. +Ergebnis: Jede Zahlungsbuchung ist einer Funktion zuzuordnen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptIsPaid(…, string moduleOrAction, AppUser currentUser)`, Zeile 4902 - Begründung: der Parameter ist nicht optional und muss von jedem Aufrufer gefüllt werden. +Prüfidee: Kein Aufrufer darf eine leere Herkunftsangabe übergeben. +Tracelinks: SyRS-081 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-082 +Titel: Mahnstufenfelder je Stufe mit Datum und Bearbeiter +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Rechnung wird gemahnt. +Fakt: Die Rechnung führt je Mahnstufe ein eigenes Datums- und ein eigenes Bearbeiterfeld: `DunningLevel1Date`/`DunningLevel1Employee`, `DunningLevel2Date`/`DunningLevel2Employee`, `DunningLevel3Date`/`DunningLevel3Employee`, ergänzt um das Feld `DunningLevel` mit den Werten `None`, `Level1`, `Level2`, `Level3`; `DunningRunBL` erzeugt zusätzlich `DunningRunReceiptReportResultDTO` mit `OldDunningLevel` und `NewDunningLevel`. +Aussage: Das System soll je Mahnstufe Datum und ausführenden Benutzer getrennt speichern, damit der Mahnverlauf ohne zusätzliche Protokolltabelle rekonstruierbar ist. +Ergebnis: Der vollständige Mahnverlauf steht am Beleg selbst. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs`, Zeilen 253-270, Zuweisungen `invoice.DunningLevel1Date = DateTime.Now; invoice.DunningLevel1Employee = loggedInUser.UserI3D;` - Begründung: die Felder werden dort tatsächlich gefüllt. + - [SEKUNDÄR] ebenda, Zeilen 296-297, `OldDunningLevel = currentInvoice.DunningLevel.Value - 1` - Begründung: belegt die Ableitung der Vorstufe durch Dekrementierung. +Prüfidee: Nach drei Mahnläufen müssen alle drei Datums- und Bearbeiterfelder gefüllt sein. +Tracelinks: SyRS-082, SyRS-083 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die feste Begrenzung auf drei Stufen ist im Zielsystem zu prüfen. +Status: belegt +``` + +``` +ID: SwRS-083 +Titel: Sperrgrenze aus dem Kundenstamm +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein neuer Auftrag wird angelegt. +Fakt: `OrderSpecificLogic.BlockNewReceiptsDunningLevel(int customerOrSupplierI3D)` liest `_customerBL.GetCustomerDetail(customerOrSupplierI3D).OrderLockAfterDunning` und liefert `null`, wenn der Wert kleiner oder gleich 0 ist; `InvoiceSpecificLogic.BlockNewReceiptsDunningLevel` liefert stets `null`; `ReceiptBL` wertet die Mahnstufe über `AccountBL.GetAccountRelatedInformations(...).DunningLevel` aus. +Aussage: Das System soll die Sperrgrenze je Kunde im Kundenstamm führen, den Wert 0 als „keine Sperre" auslegen und die Sperre nur für Belegarten anwenden, die eine Grenze melden. +Ergebnis: Die Sperre wirkt ausschließlich dort, wo sie fachlich vorgesehen ist. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Orders/OrderSpecificLogic.cs`, `BlockNewReceiptsDunningLevel`, Zeilen 687-693 - Begründung: die Auswertung von `OrderLockAfterDunning` erfolgt dort. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, `BlockNewReceiptsDunningLevel` mit `return null;`, Zeile 723-726 - Begründung: belegt, dass die Rechnungsanlage bewusst nicht gesperrt wird. +Prüfidee: Ein Kunde mit `OrderLockAfterDunning = 0` darf trotz Mahnstufe 3 Aufträge erhalten. +Tracelinks: SyRS-084, StRS-030 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-084 +Titel: Mandat als Belegfeld mit eigener Übernahmeregel +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Beleg wird weitergeführt. +Fakt: `ForwardReceipt` behandelt das Mandat in einer eigenen Region („Mandat", Zeile 2831), getrennt von Adress-, Konditions- und Provisionsübernahme; `ReceiptContract` führt `MandatI3D` und `CollectInvoice`. +Aussage: Das System soll die Mandatsübernahme beim Weiterführen als eigene Regel behandeln, damit sie unabhängig von den übrigen Übernahmeregeln angepasst werden kann. +Ergebnis: Änderungen an der Mandatsregel berühren die Adressübernahme nicht. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Mandat" in `ForwardReceipt`, Zeile 2831 - Begründung: die eigene Region belegt die Trennung. + - [SEKUNDÄR] `docs/reference/receipts/contracts-backend.md`, Felder `MandatI3D`, `CollectInvoice` - Begründung: benennen die Mandats- und Einzugsangaben am Vertrag. +Prüfidee: Eine aus einem Vertrag ohne Mandat erzeugte Rechnung darf kein Mandat tragen. +Tracelinks: SyRS-085 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-085 +Titel: Bankzugangsdaten der finAPI-Anbindung +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Bankzugang wird verwendet. +Fakt: `Centron.APIs.FinAPI/Data/AccessToken.cs` bildet das Zugriffstoken ab; `AccountInterface`, `AccountCapability` und `AccountInterfacePaymentCapabilities` beschreiben die Fähigkeiten der Bankverbindung; `AccountParams` und `AccountReference` die Kontoangaben. +Aussage: Das System soll Bankzugangsdaten ausschließlich als kurzlebige Zugriffstoken des Bankdienstleisters führen und keine Bankzugangsdaten des Kunden dauerhaft speichern. [HYPOTHESE] In der finAPI-Bibliothek ist keine Klasse für dauerhaft gespeicherte Bankzugangsdaten modelliert; zur Bestätigung fehlt die Prüfung des vollständigen Datenbankschemas und des Zweigs `Finances/OnlineBanking` auf entsprechende Felder. +Ergebnis: Bankzugangsdaten liegen nicht im System. +Belege: + - [PRIMÄR] `src/apis/Centron.APIs.FinAPI/Data/AccessToken.cs` - Begründung: das Zugriffstoken ist das modellierte Zugangsmittel; eine Klasse für dauerhaft gespeicherte Bankzugangsdaten des Kunden besteht in dieser Bibliothek nicht. + - [SEKUNDÄR] `src/apis/Centron.APIs.FinAPI/Data/AccountInterface.cs`, `AccountCapability.cs` - Begründung: beschreiben die Bankverbindung ohne Zugangsdaten. +Prüfidee: In der Datenbank darf kein Feld mit Bankzugangsdaten des Kunden auffindbar sein; dies ist gegen das vollständige Schema zu prüfen. +Tracelinks: SyRS-086 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - der Verzicht auf eigene Zugangsdatenhaltung entspricht dem Stand der Technik. +Status: HYPOTHESE +``` + +``` +ID: SwRS-086 +Titel: Zahlungseingangsprotokoll als eigenständige Entität +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Zahlungseingang wird erfasst. +Fakt: `IncomingPaymentBL` arbeitet mit `IncomingPaymentLog` und `IncomingPaymentLogOverview`; `IncomingPaymentWebServiceBL.GetIncomingPaymentLogOverview(bool? directDebitCreated)` stellt dieselbe Übersicht als Übertragungsobjekt (`IncomingPaymentLogOverviewDTO`) bereit. +Aussage: Das System soll Zahlungseingänge in einer eigenen Protokollentität führen und diese sowohl intern als auch über die Webservice-Schicht bereitstellen. +Ergebnis: Die Zahlungseingangsübersicht ist in allen Clients gleich. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentBL.cs`, `CreateIncomingPaymentLogItem(IncomingPaymentLog logItem)`, Zeile 21 - Begründung: die Protokollentität wird dort geschrieben. + - [SEKUNDÄR] `src/backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentWebServiceBL.cs`, Zeile 24 - Begründung: belegt die Bereitstellung als Übertragungsobjekt. +Prüfidee: Die Übersicht im Rich-Client und über die REST-Schnittstelle muss dieselben Einträge liefern. +Tracelinks: SyRS-087, SwRS-004 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-087 +Titel: Zahlungsverkehr als eigener Datenaustauschzweig +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Zahlungsverkehrsdateien werden erzeugt. +Fakt: `DataExchange/PaymentTransactions/` liegt im Datenaustauschbereich neben `BookKeeping`, `Connectors`, `DocuForm`, `EDI`, `GfkExport`, `Import`, `Rmm`, `TanssInterfaces` und `TelekomDive`. +Aussage: Das System soll alle dateibasierten Austauschformate in einem gemeinsamen Datenaustauschbereich bündeln. +Ergebnis: Austauschformate sind an einer Stelle auffindbar und erweiterbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/DataExchange/` mit den zehn genannten Unterzweigen - Begründung: die Bündelung ist im Verzeichnis umgesetzt. +Prüfidee: Ein neues Austauschformat muss in `DataExchange` ergänzt werden können, ohne andere Bereiche zu berühren. +Tracelinks: SyRS-088, SyRS-071 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-088 +Titel: Lizenzbestandsvergleich gegen MSP-Daten +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: MSP-Daten und Vertragsbestände liegen vor. +Fakt: Es bestehen das Modul `MSPLicensesCompare` unter `Modules/Global/`, die Statistikzweige `Statistics/MspStatistics` und `Statistics/MspCollectors`, die Module `MspStatistics`, `MspCollectors` sowie die Einstellungsseite `MspEvaluationSettingsController`; `AutomaticFacturaBL.CreateSpecialArticleToContractFromMspEvaluation(MspEvaluationCompensationItemDTO, AppUser)` überführt Abweichungen in Vertragspositionen. +Aussage: Das System soll den vertraglich abgerechneten Lizenzbestand mit den aus MSP-Systemen gemeldeten Nutzungsdaten vergleichen und Abweichungen als Vertragspositionen zur Nachberechnung überführen. +Ergebnis: Nicht abgerechnete Nutzung wird erkannt und nachfakturiert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `CreateSpecialArticleToContractFromMspEvaluation`, Zeile 129 - Begründung: überführt das Vergleichsergebnis tatsächlich in eine Vertragsposition. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Global/MSPLicensesCompare/`, `Modules/Statistics/MspCollectors/`, `Modules/Statistics/MspStatistics/` - Begründung: Vergleich, Sammlung und Auswertung als eigene Module. +Prüfidee: Eine im MSP-System gemeldete, im Vertrag fehlende Lizenz muss als Nachberechnungsposition erscheinen. +Tracelinks: SyRS-089, SyRS-033 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Umsatzsicherung im Managed-Service-Geschäft. +Status: belegt +``` + +## 8. Sicherheits- und Administrationskomponenten + +``` +ID: SwRS-090 +Titel: Zwei Wege der Rechteermittlung +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Rechte werden geprüft. +Fakt: `AppRightsBL` bietet zwei Wege: `GetRightsFromCurrentUser(AppUser)` lädt alle Rechte über die Objektbeziehungen, `CheckRightsFromUser(int appUserI3D, IList rightI3Ds)` prüft gezielt eine Auswahl per SQL; zusätzlich besteht `HasUserRight(int userI3D, int rightId)` sowie die Erweiterungsmethode `AppUser.HasUserRight(int)` in `UserRightsExt`. +Aussage: Das System soll für gezielte Rechteprüfungen die selektive SQL-Prüfung verwenden und das vollständige Laden aller Rechte auf die Modulregistrierung beschränken. +Ergebnis: Einzelprüfungen laden nicht den gesamten Rechtebaum. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `GetRightsFromCurrentUser` (Zeile 63) und `CheckRightsFromUser` (Zeile 93) - Begründung: die beiden Wege sind dort implementiert. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, `this._appRightsBL.GetRightsFromCurrentUser(currentUser).Any(f => f.I3D == …)` in `HasRightToCreateANewReceipt` gegenüber `currentUser.HasUserRight(...)` in `HasRightToEditReceipt` - Begründung: belegt, dass beide Wege in derselben Klasse gemischt verwendet werden. +Prüfidee: Eine Einzelprüfung darf nicht die vollständige Rechteliste des Benutzers laden. +Tracelinks: SyRS-090 +Konsolidierung: Kandidat: SwRS-090 selbst — drei Prüfwege (`GetRightsFromCurrentUser`, `CheckRightsFromUser`, `HasUserRight`) für dieselbe Aufgabe. +Übernahmewürdigkeit: übernehmen - im Zielsystem mit genau einem Prüfweg. +Status: belegt +``` + +``` +ID: SwRS-091 +Titel: Drei Autorisierungsattribute mit gemeinsamer Filterbasis +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Ein REST-Endpunkt wird abgesichert. +Fakt: `AuthorizeUserRightAttribute` leitet von `TypeFilterAttribute` ab und übergibt die Rechte-ID als Argument an `UserRightAuthorizationFilter`; daneben bestehen `AuthorizeAnyUserRightAttribute` und `AuthorizeAllUserRightsAttribute`; alle drei lassen sich mit `AuthorizeCentronHostedAttribute` und auf Controllerebene stapeln. +Aussage: Das System soll die Absicherung von REST-Endpunkten über genau drei Attribute (eines, mindestens eines, alle) bereitstellen, die auf Controller- und Methodenebene kombinierbar sind. +Ergebnis: Rechteanforderungen sind am Endpunkt ablesbar. +Belege: + - [PRIMÄR] `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs`, `AuthorizeAnyUserRightAttribute.cs`, `AuthorizeAllUserRightsAttribute.cs` - Begründung: die drei Attribute sind vorhanden und bauen auf derselben Filterbasis auf. + - [KONTEXT] `src/webservice/Centron.Controllers/Authorization/README.md`, Abschnitt „Apply at Controller Level" - Begründung: beschreibt die Kombinierbarkeit. +Prüfidee: Ein Endpunkt mit Controller- und Methodenattribut muss beide Rechte verlangen. +Tracelinks: SyRS-091 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-092 +Titel: Filialvergleich als gemeinsame Hilfsfunktion +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Zwei Filialangaben werden verglichen. +Fakt: `BranchBL.IsBranchEqual(int? a, int? b)` kapselt den Vergleich und wird in `ReceiptBL.CanUserEditReceipt` verwendet; `CanUserCreateReceiptsInBranch` führt denselben Vergleich hingegen als eigenen Code aus (`userBranchIsDefaultBranch && receiptBranchIsDefaultBranch`, dann `userBranchI3D == branchI3D`). +Aussage: Das System soll den Vergleich zweier Filialangaben einschließlich der Behandlung nicht gesetzter Werte an genau einer Stelle implementieren. +Ergebnis: Der Filialvergleich verhält sich überall gleich. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserEditReceipt` mit `BranchBL.IsBranchEqual(...)` gegenüber `CanUserCreateReceiptsInBranch` mit eigener Vergleichslogik, Zeilen 10258-10296 - Begründung: die beiden unterschiedlichen Umsetzungen stehen unmittelbar nebeneinander. +Prüfidee: Beide Prüfmethoden müssen für dieselbe Kombination aus Benutzer- und Belegfiliale dasselbe Ergebnis liefern. +Tracelinks: SyRS-092 +Konsolidierung: Kandidat: SwRS-092 selbst — derselbe Vergleich ist zweifach implementiert. +Übernahmewürdigkeit: übernehmen - im Zielsystem mit einer Vergleichsfunktion. +Status: belegt +``` + +``` +ID: SwRS-093 +Titel: Zwei Wege der Nummernkreisauflösung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Ein Nummernkreis wird gesucht. +Fakt: `MandatoryBL.GetNumberGroup(NumberGroupEnum, EmployeeCompact, Branch)` verzweigt über `ModuleFeatures.IsNumberGroupRefactoringAvailable`: der neue Weg ruft die SQL-basierte Überladung `GetNumberGroup(NumberGroupEnum, int?, int?)` auf, der alte durchläuft nacheinander `GetNumberGroupFromEmployee`, `GetNumberGroupFromBranch` und `GetNumberGroupFromDefaultMandator`. +Aussage: Das System soll die Nummernkreisauflösung in genau einem Verfahren durchführen; die über einen Merkmalsschalter erreichbare Altimplementierung ist nach Abschluss der Umstellung zu entfernen. +Ergebnis: Die Nummernvergabe verhält sich unabhängig vom Merkmalsschalter gleich. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs`, `GetNumberGroup`, Zeilen 55-81, `if (ModuleFeatures.IsNumberGroupRefactoringAvailable) { … } else { … }` - Begründung: die Verzweigung führt zwei vollständig getrennte Auflösungswege. + - [SEKUNDÄR] `src/backend/Centron.Common/ModuleFeatures.cs` - Begründung: hält den Merkmalsschalter. +Prüfidee: Beide Wege müssen für dieselbe Ausgangslage denselben Nummernkreis liefern. +Tracelinks: SyRS-093 +Konsolidierung: Kandidat: SwRS-093 selbst +Übernahmewürdigkeit: veraltet - die Altimplementierung ist durch die SQL-basierte Auflösung abgelöst. +Status: belegt +``` + +``` +ID: SwRS-094 +Titel: Optimistische Sperre der Nummernvergabe +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Nummer wird vergeben. +Fakt: `NumberGroupBL.GetNextNumber` verwendet `Session.GetSession().Query().Where(f => f.I3D == numberGroupObject.I3D && f.Current == numberGroupObject.Current).UpdateBuilder().Set(s => s.Current, nextNumber).Update()` und prüft den Rückgabewert `rowCountChanged == 1`; vor jedem Versuch erfolgt `Session.GetSession().Refresh(numberGroupObject)`. +Aussage: Das System soll die Zählerfortschreibung als bedingte Aktualisierung auf den zuvor gelesenen Zählerstand ausführen und den Vorgang bei abweichender Zeilenzahl wiederholen. +Ergebnis: Zwei gleichzeitige Vergaben führen nie zur selben Nummer. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs`, Zeilen 78-91 - Begründung: die bedingte Aktualisierung und die Auswertung der Zeilenzahl sind dort umgesetzt. +Prüfidee: Bei künstlich erzeugter Kollision muss die Schleife einen zweiten Versuch unternehmen. +Tracelinks: SyRS-094 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem durch eine Datenbanksequenz zu ersetzen. +Status: belegt +``` + +``` +ID: SwRS-095 +Titel: Zusammengesetzte SQL-Anweisungen der Nummernprüfung +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Eine Nummer wird auf Verwendung geprüft. +Fakt: `NumberGroupBL.FindNextNumber` erzeugt die Prüfabfrage per String-Interpolation: `$"SELECT COUNT(*) AS cnt FROM {tableName} WHERE {fieldName} = {counter}"` beziehungsweise mit Anführungszeichen bei `compareAsStrings`; Tabellen- und Feldname stammen aus `numberGroup.GetTableName()` und `numberGroup.GetFieldName()`, der Zähler ist ein `int`. +Aussage: Das System soll Datenbankabfragen ausschließlich mit gebundenen Parametern erzeugen; die Zusammensetzung von Abfragen aus Zeichenketten ist auch bei aus Aufzählungen stammenden Bezeichnern zu vermeiden. +Ergebnis: Abfragen sind nicht durch Eingabedaten beeinflussbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs`, `FindNextNumber`, Zeilen 116-131, Interpolation von `{tableName}`, `{fieldName}` und `{counter}` - Begründung: die Abfrage wird dort tatsächlich aus Zeichenketten zusammengesetzt. + - [KONTEXT] Gegenbeispiel: `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `CheckRightsFromUser` mit `NamedQueryParameter("UserI3D", appUserI3D, NHibernateUtil.Int32)` - Begründung: zeigt das andernorts verwendete Parametermuster. +Prüfidee: Alle Abfragen in `NumberGroupBL` müssen sich auf gebundene Parameter umstellen lassen, ohne die Funktion zu ändern. +Tracelinks: SyRS-095, SyRS-094 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - die Zeichenkettenzusammensetzung ist im Zielsystem durch Parameterbindung zu ersetzen; die Werte stammen hier zwar aus einer Aufzählung und einem Ganzzahlwert, das Muster ist dennoch nicht beizubehalten. +Status: belegt +``` + +``` +ID: SwRS-100 +Titel: Ticketerzeugung mit gerätebezogenem Zusatzwert +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Sitzungsticket wird erzeugt. +Fakt: `TicketBL.CreateNewTicket(ApplicationKind applicationKind, Guid licenseGuid, string deviceID, AppUser appUser, WebAccount webAccount)` übergibt an das Repository `this.GetTicketSalt(deviceID)` und `this.GetExpireDate(applicationKind)`; die Ticketsuche `GetExistingTicket(applicationKind, appUser.I3D, webAccountI3D, deviceId)` bezieht die Gerätekennung ein. +Aussage: Das System soll Sitzungstickets unter Einbeziehung eines aus der Gerätekennung abgeleiteten Zusatzwerts erzeugen und Tickets je Benutzer, Anwendung und Gerät unterscheiden. +Ergebnis: Ein Ticket eines Geräts ist auf einem anderen Gerät nicht wiederverwendbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `CreateNewTicket` mit `this.GetTicketSalt(deviceID)`, Zeilen 61-70 - Begründung: der Zusatzwert geht in die Ticketerzeugung ein. + - [PRIMÄR] ebenda, `GetExistingTicket(ApplicationKind, AppUser, int?, string deviceId)`, Zeile 83 - Begründung: die Gerätekennung ist Bestandteil der Ticketidentität. +Prüfidee: Derselbe Benutzer auf zwei Geräten muss zwei verschiedene Tickets erhalten. +Tracelinks: SyRS-100, SyRS-104 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-101 +Titel: Anwendungsart als Konfigurationsobjekt der Anmeldung +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Anmeldung erfolgt. +Fakt: `ApplicationKind` bündelt je Anwendung `LicenseGuid`, `AdditionalLicenseGuids`, `CustomerLoginLicenseGuid`, `RequiredRight`, `DisallowingRight`, `Name` sowie die Nachschlagemethoden `GetKindByLicenseGuid(string)` und `GetKindById(...)`; benannte Instanzen wie `ApplicationKind.ServiceBoardOnline` werden unmittelbar verwendet. +Aussage: Das System soll je Anwendung ein Konfigurationsobjekt führen, das Lizenzen, erforderliche und ausschließende Rechte sowie die Ticketgültigkeit zusammenfasst. +Ergebnis: Anmeldungsregeln sind je Anwendung an einer Stelle definiert. +Belege: + - [PRIMÄR] `src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs` - Begründung: definiert das Konfigurationsobjekt. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `GetTicketForWebAccountUser` mit `ApplicationKind.ServiceBoardOnline` - Begründung: zeigt die Verwendung einer benannten Instanz. + - [KONTEXT] `docs/reference/security/licensing-system.md`, Abschnitt zu `ApplicationKind.cs` - Begründung: beschreibt die Rolle der Datei. +Prüfidee: Eine neue Anwendung darf nur einen Eintrag in `ApplicationKind` erfordern. +Tracelinks: SyRS-102, SyRS-103 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-102 +Titel: Lizenzkennungen als zentrale Konstantenliste +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Eine Lizenz wird geprüft. +Fakt: `LicenseGuids.cs` (416 Zeilen) führt sämtliche Lizenz-GUIDs als Konstanten (u. a. `Centron`, `FlatRateBilling`, `CommissionEvaluation`, `PasswordManager`, `PLM`, `AccessTokenModule`, `AiAssistant`, `OpenIDConnectAuthentication`, `CRMPro`, `MasterSheets`, `AddressMaster`, `ServiceBoardOnline`, `ProductPreview`); die Modulregistrierung prüft durchgängig `LicenseManager.Instance.HasLicense(LicenseGuids.X) || LicenseManager.Instance.HasLicense(LicenseGuids.Centron)`. +Aussage: Das System soll Lizenzkennungen ausschließlich über benannte Konstanten prüfen und eine Sammellizenz vorsehen, die Einzellizenzen einschließt. +Ergebnis: Lizenzprüfungen sind im Code lesbar und die Sammellizenz wirkt einheitlich. +Belege: + - [PRIMÄR] `src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs` - Begründung: die zentrale Konstantenliste. + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, wiederkehrendes Muster `HasLicense(LicenseGuids.X) || HasLicense(LicenseGuids.Centron)` - Begründung: belegt die Wirkung der Sammellizenz. +Prüfidee: Ein Kunde mit der Sammellizenz `Centron` muss alle Module sehen, die diese Alternative führen. +Tracelinks: SyRS-103 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als Tarif- und Funktionsmatrix. +Status: belegt +``` + +``` +ID: SwRS-103 +Titel: Sperre um Ticketprüfung und Lizenzvergabe +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Zuverlässigkeit (Reife) +Akteur: System +Vorbedingung: Mehrere Anmeldungen erfolgen gleichzeitig. +Fakt: `Authenticator` führt `private static readonly object _getExistingOrCreateTicketLock = new();`; `AuthenticateUser` klammert Ticketsuche, Lizenzprüfung, Ticketerzeugung, IP-Speicherung und Versionsprotokollierung in `lock (_getExistingOrCreateTicketLock)`. +Aussage: Das System soll Ticketprüfung und Lizenzvergabe gegen gleichzeitige Ausführung schützen, damit die lizenzierte Anzahl nicht überschritten wird. +Ergebnis: Bei gleichzeitigen Anmeldungen wird die Lizenzanzahl eingehalten. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Feld `_getExistingOrCreateTicketLock` und die `lock`-Klammer in `AuthenticateUser` - Begründung: die Sperre umschließt den kritischen Abschnitt. +Prüfidee: Bei Lizenzanzahl 1 und zwei gleichzeitigen Anmeldungen verschiedener Benutzer darf nur eine gelingen. +Tracelinks: SyRS-104, StRS-037 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - eine prozesslokale Sperre schützt nicht bei mehreren Dienstinstanzen; im Zielsystem ist die Begrenzung datenbankseitig oder über einen gemeinsamen Dienst zu lösen. +Status: belegt +``` + +``` +ID: SwRS-104 +Titel: Austauschbare Zweitfaktor-Prüfer +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Ein zweiter Faktor wird geprüft. +Fakt: Der Zweig `Administration/Logins/TwoFactor` enthält die Schnittstelle `ITwoFactorValidator`, die Implementierungen `EmailTwoFactorValidator` und `RadiusTwoFactorValidator`, den Protokollzugriff `RadiusClient` mit `RadiusPaketParser`, die Fachlogik `TwoFactorAuthBL` und den Benutzerbezug `TwoFactorUser`; ergänzend besteht `TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs`. +Aussage: Das System soll Zweitfaktor-Verfahren über eine gemeinsame Schnittstelle austauschbar halten. +Ergebnis: Ein weiteres Verfahren erfordert keine Änderung an der Anmeldelogik. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TwoFactor/ITwoFactorValidator.cs` mit den beiden Implementierungen - Begründung: die Schnittstelle ist die Austauschstelle. + - [SEKUNDÄR] `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs` - Begründung: ein zweiter, gleichnamiger Baustein außerhalb des Anmeldezweigs. +Prüfidee: Ein hinzugefügter Prüfer muss ohne Änderung an `BasicAuthenticator` wirksam werden. +Tracelinks: SyRS-105 +Konsolidierung: Kandidat: SwRS-104 selbst — `Logins/TwoFactor` und `TwoFactorAuthenticator` behandeln beide die Zweifaktor-Authentifizierung. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-105 +Titel: Anmeldekontext als eigenes Objekt +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Anmeldung wird versucht. +Fakt: `AuthObject` führt `RequestId` (`Guid.NewGuid()`), `RemoteAddress` (über `IpAddressHelper.GetIpAddress()` mit Ausnahmebehandlung), `AppVersion`, `ApplicationName`, `MachineName` und überschreibt `ToString()` mit allen Werten; die Ableitungen `BasicAuthObject` und `OpenIdConnectAuthObject` ergänzen verfahrensspezifische Angaben. +Aussage: Das System soll den Anmeldekontext als eigenes Objekt mit eindeutiger Vorgangskennung führen und dieses Objekt vollständig protokollierbar gestalten. +Ergebnis: Zusammengehörige Protokolleinträge einer Anmeldung sind über die Vorgangskennung auffindbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Klasse `AuthObject`, Zeilen 21-41, mit `RequestId` und überschriebenem `ToString()` - Begründung: die Vorgangskennung und die Protokolldarstellung sind dort definiert. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, `Logger.Info("Basic authentication attempt ({RequestId}) received for user: {UserName}.", Auth.RequestId, Auth.UserName)` - Begründung: die Kennung wird tatsächlich protokolliert. +Prüfidee: Alle Protokolleinträge einer Anmeldung müssen dieselbe Vorgangskennung tragen. +Tracelinks: SyRS-106 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-106 +Titel: Kennwortprüfung als Datenbankvergleich des Hashwerts +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Anmeldung mit Benutzername und Kennwort erfolgt. +Fakt: `BasicAuthenticator.AuthenticateInternal` sucht den Benutzer mit `Session.GetGenericDAO().GetEntity(where => where.Name == Auth.UserName && where.Password == decodedPassword)`; ein nicht gefundener Benutzer und ein falsches Kennwort führen zur selben Meldung (`ValidateAppUser` mit „Anmeldung ist fehlgeschlagen. Bitte prüfen Sie Ihren Benutzernamen/Passwort"). +Aussage: Das System soll bei fehlgeschlagener Anmeldung nicht offenlegen, ob der Benutzername oder das Kennwort falsch war. +Ergebnis: Benutzernamen lassen sich über die Anmeldung nicht ermitteln. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, Zeilen 47-56 - Begründung: die kombinierte Abfrage liefert bei beiden Fehlerfällen `null` und damit dieselbe Meldung. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, `ValidateAppUser`, Zweig `if (user == null)` mit `DefaultMessageCodes.LoginFailed` - Begründung: die gemeinsame Fehlermeldung ist dort definiert. +Prüfidee: Falscher Benutzername und falsches Kennwort müssen dieselbe Meldung und denselben Meldungscode liefern. +Tracelinks: SyRS-107, SyRS-106 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - der Umgang mit der Fehlermeldung ist korrekt, das Hashverfahren jedoch zu ersetzen (siehe SyRS-107). +Status: belegt +``` + +``` +ID: SwRS-107 +Titel: Verschlüsselungskomponente mit optionalem Schlüsselparameter +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Ein Wert wird verschlüsselt. +Fakt: `AESCryptoLogic` bietet `EncryptText(string text, string securityKey = null)`, `DecryptText`, `EncryptByteArray` und `DecryptByteArray`, jeweils mit optionalem Schlüssel; wird keiner übergeben, greift die Konstante `SECURITY_KEY`; der Passwort-Manager übergibt dagegen stets den über `GetHotlineMasterKey()` bezogenen Schlüssel. +Aussage: Das System soll die Verschlüsselungskomponente nur mit ausdrücklich übergebenem Schlüssel verwenden; ein optionaler Rückfall auf einen fest hinterlegten Schlüssel ist im Zielsystem nicht vorzusehen. +Ergebnis: Jeder verschlüsselte Wert ist einem verwalteten Schlüssel zuzuordnen. +Belege: + - [PRIMÄR] `src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs`, Signaturen mit `string securityKey = null` und `GetKeyAndIV` mit Rückfall auf `SECURITY_KEY` - Begründung: der optionale Parameter ermöglicht die Verwendung des fest hinterlegten Schlüssels. + - [PRIMÄR] `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeile 700, Übergabe von `masterKeyResult.Data` - Begründung: zeigt die vorgesehene Verwendung mit verwaltetem Schlüssel. +Prüfidee: Kein produktiver Aufruf darf `EncryptText` ohne Schlüsselparameter verwenden. +Tracelinks: SyRS-108, StRS-047 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - der Rückfall auf den fest hinterlegten Schlüssel ist zu entfernen. +Status: belegt +``` + +``` +ID: SwRS-108 +Titel: Protokollierung aller Tokenvorgänge +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Ein Zugriffstoken wird angelegt, geändert oder geprüft. +Fakt: `AccessTokenLogBL.LogAction(AccessToken token, AccessTokenLogActionType actionType, string description, string ipAddress)` wird bei Erstellung (`AccessTokenLogActionType.Created` mit dem Text „Token '{name}' erstellt für Mitarbeiter {ShortSign}") und bei fehlgeschlagener Prüfung (`ValidationFailed` mit „Token ist deaktiviert." beziehungsweise „Token ist abgelaufen.") aufgerufen; die IP-Adresse ist Bestandteil des Protokolleintrags. +Aussage: Das System soll jeden Vorgang an einem Zugriffstoken mit Art, Beschreibung und IP-Adresse protokollieren. +Ergebnis: Missbrauchsversuche mit Token sind nachvollziehbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs`, `_logBL.LogAction(accessToken, AccessTokenLogActionType.Created, …, ipAddress)` (Zeile 185) und die `ValidationFailed`-Aufrufe (Zeilen 396, 403) - Begründung: die Protokollierung erfolgt an allen genannten Stellen. + - [SEKUNDÄR] `src/backend/Centron.BL/Administration/AccessTokens/AccessTokenLogBL.cs` - Begründung: die Protokollkomponente. +Prüfidee: Drei fehlgeschlagene Tokenprüfungen müssen drei Protokolleinträge mit IP-Adresse erzeugen. +Tracelinks: SyRS-109, StRS-051 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-109 +Titel: Trennung persönlicher und administrativer Tokenverwaltung +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Zugriffstoken werden verwaltet. +Fakt: `ModuleRegistration.GetPersonalSettings()` fügt `PersonalAccessTokenSettingsController` nur hinzu, wenn die Lizenz `AccessTokenModule` besteht und der Benutzer `AccessTokens.CREATE_PERSONAL` besitzt; `GetSettingsWithoutModule()` fügt `AccessTokenSettingsController` nur bei `AccessTokens.VIEW_ALL` hinzu; die weiteren Rechte `EDIT_ALL`, `DEACTIVATE_ALL`, `DELETE_ALL` steuern die administrativen Eingriffe. +Aussage: Das System soll die Verwaltung eigener Zugriffstoken vom Zugriff auf fremde Token trennen und für jede administrative Aktion ein eigenes Recht führen. +Ergebnis: Ein Benutzer kann eigene Token anlegen, ohne fremde einsehen zu können. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 249-254 und 405-408, die beiden Bedingungen für persönliche und administrative Tokenverwaltung - Begründung: die getrennten Bedingungen setzen die Trennung durch. + - [SEKUNDÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `Administration.AccessTokens` mit dem Kommentar „Personal tokens can always be managed by the token owner. These rights control access to ALL tokens (for administrators)." - Begründung: beschreibt die Trennung ausdrücklich. +Prüfidee: Ein Benutzer mit `CREATE_PERSONAL`, aber ohne `VIEW_ALL` darf die administrative Tokenliste nicht sehen. +Tracelinks: SyRS-109, SyRS-034 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-110 +Titel: Formularausgabe mit konfigurierbarem Erzeugungsumfang +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Belegdokument wird erzeugt. +Fakt: `CreateFullReportForReceipt` nimmt `ReportAction reportAction`, `ReportData report`, `ReportGroup reportGroup`, `CreateFullReportConfiguration configuration` und `bool ignoreReportGroupExport` entgegen und liefert `ReceiptReportDTO`; `CreateReportPreviewForReceipt` verwendet dieselbe Konfiguration und liefert `byte[]`. +Aussage: Das System soll die Formularausgabe über eine Konfiguration steuern, die Aktion, Formular, Formulargruppe und Exportverhalten festlegt, und Vorschau wie Ausgabe aus derselben Konfiguration ableiten. +Ergebnis: Vorschau und Druck erzeugen dasselbe Dokument. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CreateFullReportForReceipt` (Zeile 3221) und `CreateReportPreviewForReceipt` (Zeile 3177), beide mit `CreateFullReportConfiguration` - Begründung: die gemeinsame Konfiguration ist in beiden Signaturen vorhanden. +Prüfidee: Vorschau und Druck desselben Belegs müssen inhaltlich identische PDF-Dokumente liefern. +Tracelinks: SyRS-110 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-111 +Titel: Verzeichnisreferenzanbieter je Objektart +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modifizierbarkeit) +Akteur: Entwicklung +Vorbedingung: Eine neue Objektart benötigt eine Dokumentenablage. +Fakt: Das Verzeichnis `Administration/FileManagement/DirectoryReferenceProviders` enthält je Objektart einen Anbieter; `DirectoryReferenceBL` und `GetDirectoryByReferenzBL` lösen die Referenz auf; `DirectoryCheckRecursiveItem` unterstützt die rekursive Prüfung, `EdiDocumentBL` und `SharedDocumentBL` behandeln Sonderfälle. +Aussage: Das System soll die Zuordnung von Objektarten zu Verzeichnissen über je Objektart eigene Anbieter erweiterbar halten. +Ergebnis: Eine neue Objektart erfordert nur einen zusätzlichen Anbieter. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/FileManagement/DirectoryReferenceProviders/` - Begründung: die anbieterbasierte Erweiterbarkeit ist im Verzeichnis umgesetzt. +Prüfidee: Ein zusätzlicher Anbieter muss ohne Änderung an `GetDirectoryByReferenzBL` wirksam werden. +Tracelinks: SyRS-111 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-112 +Titel: Mailkomponenten nach Aufgabe getrennt +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modularität) +Akteur: Entwicklung +Vorbedingung: Eine Mailfunktion wird geändert. +Fakt: Der Zweig `Centron.BL/Mail` gliedert sich in `Blacklist`, `Exchange`, `Factory`, `MailFormatting`, `Protocols`, `Templates`, `VariableReplacement` sowie `MailSettingsBL`, `MailSignatureBL` und `ParseResult`. +Aussage: Das System soll Sperrliste, Postfachanbindung, Erzeugung, Formatierung, Protokolle, Vorlagen und Variablenersetzung als getrennte Mailkomponenten führen. +Ergebnis: Eine Änderung an der Formatierung berührt die Postfachanbindung nicht. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Mail/` mit den sieben genannten Unterzweigen - Begründung: die Aufteilung ist im Verzeichnis erkennbar. + - [SEKUNDÄR] `src/backend/Centron.BL/Mail/Factory/` - Begründung: die Erzeugung ist als eigene Fabrik gekapselt, wie der Aufruf `MailFactory` in `HelpdeskCloseBL` zeigt. +Prüfidee: Eine Änderung an der Sperrliste darf keine Änderung an den Vorlagen erfordern. +Tracelinks: SyRS-112, SyRS-113 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-113 +Titel: Profile, Arbeitsabläufe und Aufgaben des Mail-Scanners +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Ein Postfach wird überwacht. +Fakt: `MailScannerBL` verwaltet drei Ebenen: Profile (`MailScannerProfile`, `GetProfiles(MailScannerProfileFilter, LoggedInUser)`, `SaveProfile`, `DeleteProfile`), Arbeitsabläufe (`MailScannerWorkflowProcessDTO`, `GetWorkflows(MailScannerWorkflowFilter)`, `SaveWorkflow`) und Aufgaben (`SaveTasks(IList)`); das Protokoll wird über `SaveMailScannerLog`, `GetMailScannerLogs(MailScannerLogFilter)` und `DeleteMailScannerLogs` geführt. +Aussage: Das System soll die Postfachüberwachung dreistufig aus Profil, Arbeitsablauf und Aufgabe aufbauen und je Ebene eigene Pflege- und Protokollfunktionen bereitstellen. +Ergebnis: Regeln lassen sich unabhängig vom Postfachzugang ändern. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/MailScanner/MailScannerBL.cs`, `GetProfiles` (57), `GetWorkflows` (36), `SaveTasks` (118), `GetMailScannerLogs` (140) - Begründung: die drei Ebenen und das Protokoll sind als getrennte Methoden vorhanden. +Prüfidee: Eine Änderung des Arbeitsablaufs darf die Postfachzugangsdaten des Profils nicht berühren. +Tracelinks: SyRS-113, StRS-041 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-114 +Titel: Kalenderfunktionen als getrennte Einstellungsbereiche +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Der Kalender wird eingerichtet. +Fakt: Für den Kalender bestehen vier getrennte Einstellungsseiten: `CalendarSynchronizationSettingsController`, `CalendarRepresentationsSettingsController`, `AppointmentsForTicketsSettingsController` und `CrmOutlookTemplateSettingsController`, alle in `GetSettingsWithoutModule()` registriert; die Fachlogik liegt in `Calendar/CalendarBL.cs` und `Mail/Exchange/`; das Schema führt `ScheduleArea`. +Aussage: Das System soll Synchronisation, Vertretungen, Ticket-Termine und Outlook-Vorlagen des Kalenders getrennt konfigurierbar machen. +Ergebnis: Einzelne Kalenderfunktionen sind unabhängig voneinander aktivierbar. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, die vier genannten Controller in `GetSettingsWithoutModule()` - Begründung: vier getrennte Registrierungen belegen die unabhängige Konfigurierbarkeit. + - [SEKUNDÄR] `src/backend/Centron.BL/Calendar/CalendarBL.cs`, `src/backend/Centron.BL/Mail/Exchange/` - Begründung: die zugehörige Fachlogik. +Prüfidee: Das Abschalten der Synchronisation darf die Ticket-Termine nicht beeinflussen. +Tracelinks: SyRS-114, StRS-042 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-115 +Titel: Telefoneinstellungen auf persönlicher und globaler Ebene +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Die Telefonie wird eingerichtet. +Fakt: `ModuleRegistration.GetPersonalSettings()` enthält `PersonalPhoneSettingsController`, `GetSettingsWithoutModule()` enthält `PhoneSettingsController`; im Backend besteht `Administration/PhoneSettings/`, in der Oberfläche `Modules/Administration/PhoneSettings/` und `Modules/MyCentron/PersonalSettings/Phone/`. +Aussage: Das System soll Telefoneinstellungen sowohl global als auch je Benutzer führen, wobei die persönliche Einstellung Vorrang hat. +Ergebnis: Jeder Mitarbeiter arbeitet mit seiner eigenen Nebenstelle. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `PersonalPhoneSettingsController` in `GetPersonalSettings()` und `PhoneSettingsController` in `GetSettingsWithoutModule()` - Begründung: die beiden Ebenen sind getrennt registriert. + - [SEKUNDÄR] `src/backend/Centron.BL/Administration/PhoneSettings/` - Begründung: die zugehörige Fachlogik. +Prüfidee: Eine gesetzte persönliche Nebenstelle muss die globale Vorgabe überschreiben. +Tracelinks: SyRS-115 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 9. Web- und Portalkomponenten + +``` +ID: SwRS-120 +Titel: Web-Rechte als eigene Entitäten mit Kategorien +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Web-Rechte werden vergeben. +Fakt: `WebAccountBL` arbeitet mit den Entitäten `WebRights` und `WebRightsCategories` sowie der Zuordnungstabelle `WebAccountsRights`; `GetAllWebRightsFromWebAccount(int accountI3D)` liefert die Rechte eines Kontos; `WebRightsVisibility.cs` steuert die Sichtbarkeit der Rechte in der Verwaltung; `WebAccountRightsConst` benennt einzelne Web-Rechte (`SHOWONLYOWNREQUESTS`, `WEBRIGHT_SHOWONLYNOTIFYTICKETS`, `SHOWALLEREQUESTS`, `CUSTOMERADMINISTRATOR`). +Aussage: Das System soll Web-Rechte als eigene, kategorisierte Entitäten führen und ihre Sichtbarkeit in der Verwaltung steuerbar machen. +Ergebnis: Web-Rechte sind unabhängig von den internen Rechten pflegbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, `GetWebRightByI3D` (Zeile 121), `GetWebRightsCategoriesByI3D` (Zeile 126), `GetAllWebRightsFromWebAccount` (Zeile 141) - Begründung: die Entitäten und ihre Auflösung sind dort implementiert. + - [SEKUNDÄR] `src/backend/Centron.BL/Administration/Logins/WebRightsVisibility.cs` - Begründung: steuert die Sichtbarkeit der Rechte. +Prüfidee: Ein neu angelegtes Web-Recht muss in seiner Kategorie erscheinen. +Tracelinks: SyRS-120 +Konsolidierung: Kandidat: SwRS-090 — internes und webseitiges Rechtesystem lösen dieselbe Aufgabe in getrennten Datenhaltungen. +Übernahmewürdigkeit: übernehmen - im Zielsystem ist ein gemeinsames Rechtemodell mit Rollenzuschnitt zu prüfen. +Status: belegt +``` + +``` +ID: SwRS-121 +Titel: Kennzeichen der Web-Anmeldung im Anmeldekontext +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Benutzer ist angemeldet. +Fakt: `LoggedInUser` führt die Eigenschaft `IsWebAccountLogin` sowie die Felder `User` (`AppUser`) und `WebAccount`; die Fachlogik verzweigt darauf (`HelpdeskBL.CheckRights`, `HelpdeskBL.GetLoggedInUserShowHelpdeskRight`, `ReceiptBL.CanUserViewReceipt`); `TicketBL.GetTicketForWebAccountUser()` verwendet einen internen technischen Benutzer mit der Gerätekennung `"InternalWebAccountUser"`. +Aussage: Das System soll im Anmeldekontext kenntlich machen, ob es sich um eine Web-Anmeldung handelt, und die Fachlogik daran ihre Prüfregeln ausrichten lassen. +Ergebnis: Web- und interne Anmeldungen werden überall unterscheidbar behandelt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserViewReceipt` mit `if (loggedInUser.IsWebAccountLogin)` - Begründung: die Eigenschaft steuert die Zugriffsentscheidung. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `GetTicketForWebAccountUser` mit der festen Gerätekennung `"InternalWebAccountUser"` - Begründung: belegt den technischen Sammelbenutzer der Web-Anmeldung. +Prüfidee: Eine Web-Anmeldung muss `IsWebAccountLogin` liefern, eine interne nicht. +Tracelinks: SyRS-121, SyRS-120 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - der technische Sammelbenutzer ist im Zielsystem durch eine eigene Dienstidentität zu ersetzen. +Status: belegt +``` + +``` +ID: SwRS-122 +Titel: Reparaturfunktion für fehlende Kontaktverknüpfungen +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Web-Konten sind vorhanden. +Fakt: `WebAccountBL.RepairMissingWebAccountContactLinks()` liefert die Zahl reparierter Verknüpfungen; ergänzend bestehen `GetWebAccountByContactPersonI3D(int contactPersonI3D, bool ignoreStatus)` und `GetWebAccountsWithContactsByCustomerI3D(int customerI3D)`, die Konto und Kontaktperson verbinden. +Aussage: Das System soll fehlende Verknüpfungen zwischen Web-Konto und Kontaktperson erkennen und auf Anforderung wiederherstellen. +Ergebnis: Jedes Web-Konto ist einer Kontaktperson zugeordnet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, `RepairMissingWebAccountContactLinks`, Zeile 318 - Begründung: die Reparaturfunktion ist eigens implementiert und belegt damit das Auftreten fehlender Verknüpfungen. +Prüfidee: Nach dem Lauf darf kein Web-Konto ohne Kontaktperson verbleiben. +Tracelinks: SyRS-122, SyRS-166 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - die Reparaturfunktion behebt eine Datenlücke, deren Ursache im Zielsystem durch eine Pflichtbeziehung zu vermeiden ist. +Status: belegt +``` + +``` +ID: SwRS-123 +Titel: Belegzustand des Webbelegs als eigene Aufzählung +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Beleg ist im Portal freigegeben. +Fakt: `ReceiptBL.ChangeWebReceiptState(string token, WebReceiptState webReceiptState)` verwendet die Aufzählung `WebReceiptState` und liefert `AcceptWebReceiptResultDTO`; die persönliche Einstellungsseite `PersonalWebReceiptController` konfiguriert das Verhalten je Benutzer. +Aussage: Das System soll den Freigabezustand eines Webbelegs als eigene Aufzählung getrennt vom internen Belegzustand führen. +Ergebnis: Kundenentscheidungen sind vom internen Bearbeitungszustand unterscheidbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ChangeWebReceiptState(string token, WebReceiptState webReceiptState)`, Zeile 5903 - Begründung: die eigene Aufzählung ist Bestandteil der Signatur. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/MyCentron/PersonalSettings/WebReceipt/` - Begründung: eigene persönliche Einstellung für Webbelege. +Prüfidee: Eine Kundenablehnung muss den Webbelegzustand ändern, ohne den internen Belegzustand zu setzen. +Tracelinks: SyRS-123 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-124 +Titel: Geteiltes Dokument als eigene Entität +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Dokument wird dem Kunden bereitgestellt. +Fakt: `SharedDocument` und `SharedDocumentDTO` bilden das geteilte Dokument ab; `SharedDocumentBL` verwaltet es; `ReceiptBL.SendSignAcceptance(AppUser, GenerateTokenForDocumentRequest, SharedDocumentDTO)` und `SendSignDocument(AppUser, string centronNexusUrl, int sharedDocumentI3D, ReceiptMailTemplateDTO)` erzeugen die Anfragen; die Webseiten `SharedDocumentPage`, `SharedDocumentSignPage` und `SharedDocumentAcceptancePage` zeigen es an. +Aussage: Das System soll ein dem Kunden bereitgestelltes Dokument als eigene Entität mit Token, Empfänger und Zustand führen, unabhängig vom Ursprungsbeleg. +Ergebnis: Auch belegfremde Dokumente sind zur Unterzeichnung bereitstellbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/FileManagement/SharedDocumentBL.cs` - Begründung: verwaltet die Entität eigenständig. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SendSignDocument(AppUser, string, int sharedDocumentI3D, ReceiptMailTemplateDTO)`, Zeile 7124 - Begründung: die Anfrage bezieht sich auf die Kennung des geteilten Dokuments, nicht auf den Beleg. + - [SEKUNDÄR] `src/nexus/CentronNexus/Office/SharedDocumentPage.razor`, `SharedDocumentSignPage.razor`, `SharedDocumentAcceptancePage.razor` - Begründung: die drei Kundenansichten. +Prüfidee: Ein geteiltes Dokument ohne Belegbezug muss unterzeichenbar sein. +Tracelinks: SyRS-124, SyRS-123 +Konsolidierung: Kandidat: SwRS-042 — Unterschriftserfassung besteht am Zeiteintrag und am geteilten Dokument getrennt. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-125 +Titel: Formularfelder als Bestandteil des Ticketmusters +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Ein Self-Care-Formular wird definiert. +Fakt: Die Felddefinition erfolgt im Ticketmusterbearbeiter über `SelfCareFormFieldGrid.razor` und `SelfCareFormFieldEditPopup.razor`; die Bereitstellung übernimmt `SelfCareFormsController`; die Fachlogik liegt in `SelfCare/SelfCareBL.cs` und `WebRequestPageBL.cs`; das Portal zeigt sie über `CustomerPortalFormsPage.razor` und `CustomerPortalFormFillPage.razor`. +Aussage: Das System soll die Formularfelder eines Self-Care-Formulars als Bestandteil des zugehörigen Ticketmusters definieren, sodass Formular und erzeugtes Ticket gemeinsam gepflegt werden. +Ergebnis: Formularfelder und Ticketvorbelegung bleiben konsistent. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus/Management/TicketPatterns/Components/SelfCareFormFieldGrid.razor` und `SelfCareFormFieldEditPopup.razor` - Begründung: die Felddefinition liegt im Ticketmusterbearbeiter. + - [SEKUNDÄR] `src/backend/Centron.BL/SelfCare/SelfCareBL.cs`, `WebRequestPageBL.cs` - Begründung: die zugehörige Fachlogik. +Prüfidee: Ein zusätzliches Formularfeld muss ohne Änderung am Portalcode erscheinen. +Tracelinks: SyRS-125, SyRS-058 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-126 +Titel: Konfigurationsklassen der Webanwendung +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modifizierbarkeit) +Akteur: Betrieb +Vorbedingung: Die Webanwendung wird eingerichtet. +Fakt: `CentronNexus/Configuration` enthält je Anliegen eine eigene Konfigurationsklasse: `AIAssistConfig`, `BrandingConfig`, `CentronAddInInfoConfig`, `CentronWebServiceConfig`, `CustomerPortalConfig`, `DiagnosticsConfig`, `GeneralConfig`, `HostConfig`, `NotificationsConfig`, `TicketCacheConfig`, `UploadConfig`, `WebAccountConfig`, `WebCartConfig`, zusätzlich `OpenIdConnectConfigurationService`, `OpenIdConnectConfigurationPollingService`, `OpenIdConnectCustomOptions` und ein Verzeichnis `Migrations`. +Aussage: Das System soll die Konfiguration der Webanwendung in getrennte, typisierte Konfigurationsklassen je Anliegen gliedern und Konfigurationsänderungen migrierbar halten. +Ergebnis: Konfigurationswerte sind typisiert und einem Anliegen zugeordnet. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus/Configuration/` mit den 13 genannten Konfigurationsklassen und dem Verzeichnis `Migrations` - Begründung: die Gliederung und die Migrierbarkeit sind dort umgesetzt. +Prüfidee: Eine neue Konfigurationsoption muss genau einer Konfigurationsklasse zuzuordnen sein. +Tracelinks: SyRS-126, SyRS-160 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-127 +Titel: Outlook-Add-In als eigenständige Webanwendungserweiterung +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Das Add-In wird geladen. +Fakt: `CentronNexus.OutlookAddIn` ist ein eigenes Projekt mit `OutlookIndexPage.razor`, zugehöriger CSS- und JavaScript-Datei, den Bereichen `Belege`, `CRM`, `Customer`, `Document`, `Ticket`, `Model`, `Shared`, `OfficeDialog`, `Manifest` sowie eigenen Sprachressourcen (`SharedResource.resx`) und der Erweiterung `RazorComponentsEndpointConventionBuilderExtensions`. +Aussage: Das System soll das Outlook-Add-In als eigenständiges Projekt der Webanwendung führen, das deren Endpunkte über eine eigene Registrierung einbindet. +Ergebnis: Das Add-In ist unabhängig von der Hauptanwendung erweiterbar. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus.OutlookAddIn/CentronNexus.OutlookAddIn.csproj` und `RazorComponentsEndpointConventionBuilderExtensions.cs` - Begründung: eigenes Projekt mit eigener Endpunktregistrierung. + - [SEKUNDÄR] `src/nexus/CentronNexus.OutlookAddIn/Manifest/` - Begründung: das Add-In-Manifest. +Prüfidee: Das Add-In muss ohne Übersetzung der Hauptanwendung austauschbar sein. +Tracelinks: SyRS-127 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-128 +Titel: Zwei Benachrichtigungsmechanismen nebeneinander +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modifizierbarkeit) +Akteur: Entwicklung +Vorbedingung: Eine Benachrichtigung wird erzeugt. +Fakt: Es bestehen zwei getrennte Zweige: `Centron.BL/Notifications` mit `CentronNotificationsBL` und `UserNotificationBL` sowie `Centron.BL/NexusNotifications` mit `NexusNotificationsBL` und `NotificationsHubHelper`; die Einstellungsseite `CentronNotificationsSettingsController` bezieht sich auf den ersten, `Configuration/NotificationsConfig.cs` und `Settings/Notification/` auf den zweiten. +Aussage: Das System soll Benachrichtigungen über genau einen Mechanismus erzeugen und zustellen. +Ergebnis: Eine Benachrichtigungsregel wirkt in allen Oberflächen gleich. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Notifications/CentronNotificationsBL.cs` und `src/backend/Centron.BL/NexusNotifications/NexusNotificationsBL.cs` - Begründung: zwei getrennte Zweige für dieselbe Aufgabe. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Administration/Services/CentronNotifications/`, `src/nexus/CentronNexus/Settings/Notification/` - Begründung: zwei getrennte Konfigurationsoberflächen. +Prüfidee: Eine im Rich-Client konfigurierte Benachrichtigung muss auch in der Weboberfläche erscheinen. +Tracelinks: SyRS-128 +Konsolidierung: Kandidat: SwRS-128 selbst — `Notifications` und `NexusNotifications` bilden denselben fachlichen Gegenstand in zwei Mechanismen ab. +Übernahmewürdigkeit: übernehmen - im Zielsystem als ein Benachrichtigungsdienst. +Status: belegt +``` + +``` +ID: SwRS-129 +Titel: Sprachressourcen als Ressourcendateipaare +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Benutzbarkeit (Zugänglichkeit) +Akteur: Entwicklung +Vorbedingung: Ein Oberflächentext wird ergänzt. +Fakt: Die Webanwendung führt `SharedResource.resx` und `SharedResource.en-US.resx` mit je einer Designer-Klasse; das Projekt enthält insgesamt 14 Ressourcendateien; die Verwaltung erfolgt über `ResXManager.config.xml`; die Entwicklungsvorgabe verlangt für jeden neuen Text beide Sprachfassungen. +Aussage: Das System soll Oberflächentexte ausschließlich über Ressourcendateien führen und jeden Text in beiden Sprachfassungen pflegen. +Ergebnis: Es verbleiben keine fest im Code hinterlegten Oberflächentexte. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus/SharedResource.resx`, `SharedResource.en-US.resx` mit den zugehörigen Designer-Klassen - Begründung: das Sprachpaar ist vorhanden. + - [PRIMÄR] `ResXManager.config.xml` im Wurzelverzeichnis - Begründung: belegt ein Werkzeug zur Pflege der Ressourcen. + - [KONTEXT] `docs/getting-started/general-structure.md`, „When adding new localized strings, provide translations for both languages" - Begründung: benennt die Regel. +Prüfidee: Jeder Schlüssel in `SharedResource.resx` muss auch in `SharedResource.en-US.resx` vorhanden sein. +Tracelinks: SyRS-129 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Quelltext finden sich jedoch weiterhin deutsche Zeichenketten (etwa Fehlermeldungen in `ReceiptBL` und `HelpdeskBL`), die im Zielsystem zu externalisieren sind. +Status: belegt +``` + +## 10. Zugangsdaten und Assets + +``` +ID: SwRS-130 +Titel: Zugangsdaten als verschlüsselte Zusatzfelder +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Kennwort wird gespeichert. +Fakt: `PasswordManagerBL` legt Kennwörter nicht in einer eigenen Kennworttabelle ab, sondern als `ModuleCustomPropertyValue` vom Typ `CustomizationDataTypes.EncryptedText` im Feld `ValueEncryptedString`; `CreateProperty("Passwort", CustomizationDataTypes.EncryptedText)` legt die Felddefinition an, `CreatePropertyValue("Passwort", propertyValue => propertyValue.ValueEncryptedString = new AESCryptoLogic().EncryptText(customerHotline.Password, masterKeyResult.Data))` den Wert. +Aussage: Das System soll Zugangsdaten über die allgemeine Zusatzfeldstruktur mit dem Datentyp „verschlüsselter Text" ablegen und den Klartext niemals in ein unverschlüsseltes Feld schreiben. +Ergebnis: Kennwörter sind in der Datenbank nur verschlüsselt vorhanden. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 608 und 700 - Begründung: Felddefinition und Verschlüsselung des Werts erfolgen dort. + - [PRIMÄR] ebenda, Zeile 527, `propertyValue.ValueEncryptedString = null;` - Begründung: belegt das gezielte Leeren des verschlüsselten Feldes. +Prüfidee: Eine Suche nach dem Klartextkennwort in der Datenbank darf keinen Treffer liefern. +Tracelinks: SyRS-108, StRS-047, StRS-059 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die Ablage über Zusatzfelder ist im Zielsystem durch einen eigenen Geheimnisspeicher zu ersetzen. +Status: belegt +``` + +``` +ID: SwRS-131 +Titel: Masterschlüssel aus der Konfigurationsdatenbank +Ebene: SwRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Zugangsdatensatz wird ver- oder entschlüsselt. +Fakt: `PasswordManagerBL` bezieht den Schlüssel ausschließlich über `new CentronConfigurationDbBL(this.Session).GetHotlineMasterKey()` (Zeilen 551 und 949) und übergibt ihn an `AESCryptoLogic`; beim Export wird der Schlüssel als Parameter `string securityKey` durch die Aufrufkette gereicht (`AddAccessDataProperties`, `GetPropertyValueForTable`); der Kommentar an Zeile 949 lautet „Export all data decrypted". +Aussage: Das System soll den Masterschlüssel für Zugangsdaten ausschließlich aus der Konfigurationsdatenbank beziehen und ihn nicht im Anwendungscode hinterlegen. +Ergebnis: Der Schlüssel ist zentral austauschbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 551 und 949, `GetHotlineMasterKey()` - Begründung: die einzige Schlüsselquelle im Passwort-Manager. + - [KONTEXT] ebenda, Zeile 949, Kommentar „Export all data decrypted" - Begründung: benennt einen Vorgang, bei dem Zugangsdaten entschlüsselt das System verlassen. +Prüfidee: Ein Wechsel des Masterschlüssels muss die Entschlüsselung bestehender Daten nachvollziehbar regeln; dieser Fall ist gesondert zu prüfen. +Tracelinks: SyRS-108, StRS-047 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - der Klartextexport ist im Zielsystem an ein eigenes Recht und eine Protokollierung zu binden. +Status: belegt +``` + +``` +ID: SwRS-132 +Titel: Migration der Altzugangsdaten in den Passwort-Manager +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Altdaten aus dem Hotline-Bereich liegen vor. +Fakt: `PasswordManagerBL.AddOldHotlineEntriesToCustomer(customerHotlines.Key, customerHotlines.ToList())` (Zeile 722) überführt Alt-Hotline-Einträge in die neue Struktur und verschlüsselt dabei die Kennwörter; die Altdaten stammen aus `Accounts/HotlineArea/` und `HotlineBL.cs`. +Aussage: Das System soll bestehende Zugangsdaten aus dem Alt-Hotlinebereich in die verschlüsselte Zusatzfeldstruktur überführen. +Ergebnis: Altdaten sind nach der Migration verschlüsselt abgelegt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, `AddOldHotlineEntriesToCustomer`, Zeile 722, im Zusammenhang mit der Verschlüsselung Zeile 700 - Begründung: die Migration und die Verschlüsselung liegen im selben Ablauf. + - [SEKUNDÄR] `src/backend/Centron.BL/Accounts/HotlineArea/`, `src/backend/Centron.BL/Accounts/HotlineBL.cs` - Begründung: die Altdatenquelle. +Prüfidee: Nach der Migration darf im Alt-Hotlinebereich kein Klartextkennwort mehr verbleiben. +Tracelinks: SyRS-131, StRS-048 +Konsolidierung: Kandidat: SwRS-130 — Alt-Hotlinebereich und Passwort-Manager halten dieselben Zugangsdaten. +Übernahmewürdigkeit: übernehmen - die Migration ist vor Ablösung des Altmoduls abzuschließen. +Status: belegt +``` + +``` +ID: SwRS-140 +Titel: Stammblatt als Geräteakte mit Beleg- und Vertragsbezug +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Gerät wird ausgeliefert. +Fakt: `MasterDataList` (Tabelle `Stammdat`) führt `SerialNumberI3D`, `SerialNumber`, `Caption`, `InvoiceItemI3D`, `InvoiceI3D`, `InvoiceNumber`, `InvoiceDate`, `QuelleReceiptKind`, `ContractI3D`, `CounterDevice`, `FreeInventoryNumber`, `ArticleCode`, `CustomerI3D`, `AddressI3D`, `ContactPersonI3D`, `DirectoryI3D`, `IsMsp`, `IsActive` sowie eine Positionsliste `Items` (`MasterDataListItem`); zusätzlich bestehen `MasterDataListCompact` und `MasterDataListItemsCompact` im Vertragszweig. +Aussage: Das System soll je ausgeliefertem Gerät ein Stammblatt mit Seriennummer, Herkunftsbeleg, Vertragsbezug, Zählerstand, Standortadresse und eigenem Dokumentenverzeichnis führen. +Ergebnis: Zu jedem Gerät sind Herkunft, Vertrag und Standort bekannt. +Belege: + - [PRIMÄR] `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs`, die genannten Eigenschaften - Begründung: die Felder sind als persistierte Eigenschaften definiert. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs`, `GetMasterDataListFromContract(int customerI3D, int contractI3D)` (Zeile 153) und `SearchMasterDataListsThroughPaging(MasterDataFilter, int page, int entriesPerPage)` (Zeile 174) - Begründung: belegen die Vertragszuordnung und die seitenweise Suche. +Prüfidee: Ein aus einer Rechnung erzeugtes Stammblatt muss deren Rechnungsnummer und -datum tragen. +Tracelinks: SyRS-140, StRS-049, StRS-010 +Konsolidierung: Kandidat: SwRS-141, SwRS-142 — Stammblatt, Account-Gerät und Asset-Management-Gerät bilden denselben fachlichen Gegenstand ab. +Übernahmewürdigkeit: übernehmen - im Zielsystem als eine Asset-Entität. +Status: belegt +``` + +``` +ID: SwRS-141 +Titel: Account-Gerät mit Ticket- und Protokollbezug +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Helpdesk-Mitarbeiter +Vorbedingung: Ein Gerät ist einem Account zugeordnet. +Fakt: Die Entitäten `AccountDevice`, `AccountDeviceLog`, `AccountDeviceOverview`, `AccountDeviceToTicket` und `AccountDeviceUri` bilden das Account-Gerät ab; im Schema bestehen `AccountDevices` und `AccountDevicesToTickets`; `AccountDeviceBL` verwaltet sie; die Weboberfläche stellt `DeviceManagement`, `DevicesList`, `DeviceTabDetails`, `DeviceTabLogs` und `DeviceTabTickets` bereit. +Aussage: Das System soll Geräte am Account mit eigenem Protokoll, Zugriffsadressen und Ticketverknüpfung führen. +Ergebnis: Zu jedem Gerät sind die zugehörigen Tickets und Protokolleinträge sichtbar. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `AccountDevices`, `AccountDevicesToTickets` - Begründung: die Ticketverknüpfung ist als eigene Relation durchgesetzt. + - [PRIMÄR] `src/backend/Centron.Entities/Entities/Devices/AccountDevice.cs`, `AccountDeviceLog.cs`, `AccountDeviceToTicket.cs`, `AccountDeviceUri.cs` - Begründung: die Entitäten belegen den Funktionsumfang. + - [SEKUNDÄR] `src/nexus/CentronNexus/ServiceBoard/Customers/CustomerDevices/Components/DeviceTabTickets.razor` - Begründung: die Ticketansicht am Gerät. +Prüfidee: Ein Ticket zu einem Gerät muss in dessen Ticketreiter erscheinen. +Tracelinks: SyRS-140, StRS-049 +Konsolidierung: Kandidat: SwRS-140, SwRS-142 +Übernahmewürdigkeit: übernehmen - im Zielsystem als eine Asset-Entität. +Status: belegt +``` + +``` +ID: SwRS-142 +Titel: Asset-Management-Gerät mit Überwachungsdaten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Monitoring +Vorbedingung: Ein System wird überwacht. +Fakt: Das Schema führt `AssetManagementDevices`, `AssetManagementDeviceDependencies`, `AssetManagementApplication`, `AssetManagementWindowsSystems`, `AssetManagementWindowsServices`, `AssetManagementPatch`, `AssetManagementCheckConfigurations`, `AssetManagementCheckResults`, `AssetManagementCheckStatusReports`, `AssetManagementSnmpMibChecks`, `AssetManagementSnmpMibDetails`, `AssetManagementSnmpMibOidDetails`, `AssetManagementServiceConnectorLogs`, `AssetManagementWizardMappings` sowie `MonitoringServiceSettings`; die Fachlogik liegt in `Centron.BL/DocuBoard` (`AssetManagementADSystemUserExclusionBL`, `AssetManagementArticleAssignmentBL`, `AssetManagementPartnerBL`). +Aussage: Das System soll überwachte IT-Systeme mit Anwendungen, Diensten, Patchständen, Abhängigkeiten, Prüfkonfigurationen, Prüfergebnissen und SNMP-Daten führen. +Ergebnis: Der technische Zustand überwachter Systeme ist bekannt. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, die 14 genannten `AssetManagement*`-Tabellen und `MonitoringServiceSettings` - Begründung: der Funktionsumfang ist im Schema durchgesetzt. + - [SEKUNDÄR] `src/backend/Centron.BL/DocuBoard/` mit drei Fachlogikklassen - Begründung: die zugehörige Geschäftslogik. + - [SEKUNDÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `Monitoring`, Zeile 2671 - Begründung: eigener Rechtezweig für die Überwachung. +Prüfidee: Ein fehlgeschlagener SNMP-Check muss ein Prüfergebnis mit Zeitstempel erzeugen. +Tracelinks: SyRS-140, StRS-049, StRS-062 +Konsolidierung: Kandidat: SwRS-140, SwRS-141 +Übernahmewürdigkeit: übernehmen - im Zielsystem als Überwachungsdaten am gemeinsamen Asset. +Status: belegt +``` + +``` +ID: SwRS-143 +Titel: Kundenspezifische Assets mit Betreuerrollen +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: Ein Asset ist einem Kunden zugeordnet. +Fakt: `CustomerAsset` erweitert `AssetBase` um vier Betreuerfelder mit Kommentaren zu ihrer fachlichen Bedeutung: `Adviser1I3D` („IDM"), `Adviser2I3D` („ADM"), `Adviser3I3D` („Techniker 1"), `Adviser4I3D` („Techniker 2"), außerdem `Customer`, eine berechnete `Address` und einen `Contact`; `AssetBL`, `CustomerAssetBL`, `CustomerAssetExtendedBL`, `AssetArticleBL`, `AssetVersionControlBL` und `AssetLockBL` bilden die Fachlogik. +Aussage: Das System soll je Kunden-Asset bis zu vier Betreuerrollen führen und die Adresse bei fehlender ausdrücklicher Zuordnung aus der Standardadresse des Kunden ableiten. +Ergebnis: Zu jedem Asset sind Zuständige und Standort bekannt. +Belege: + - [PRIMÄR] `src/backend/Centron.Entities/Entities/Sales/CustomerAssets/CustomerAsset.cs`, Zeilen 14-48, die vier Betreuerfelder mit ihren Kommentaren und die berechnete `Address` - Begründung: die Rollen und die Adressableitung sind dort definiert. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/CustomerAssets/AssetVersionControlBL.cs` - Begründung: belegt eine Versionsverfolgung am Asset. +Prüfidee: Ein Asset ohne eigene Adresse muss die Standardadresse des Kunden anzeigen. +Tracelinks: SyRS-140, SyRS-003 +Konsolidierung: Kandidat: SwRS-140, SwRS-141, SwRS-142 +Übernahmewürdigkeit: übernehmen - die vier festen Betreuerrollen sind im Zielsystem durch eine erweiterbare Rollenzuordnung zu ersetzen. +Status: belegt +``` + +## 11. Datenschutz-, Historien- und Betriebskomponenten + +``` +ID: SwRS-150 +Titel: Löschprotokoll des Datenschutzmoduls +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Datenschutzbeauftragter +Vorbedingung: Kontakte werden gelöscht. +Fakt: `DataSecurityBL.DsgvoDeleteRightDeleteContacts` führt einen `deleteProtocol` mit, der an die einzelnen Löschmethoden übergeben wird (`DoDeleteContactPerson(currentUser, deleteProtocol, contact.ObjectI3D, false)`), und liefert das Ergebnis als `Result` zurück. +Aussage: Das System soll den Löschvorgang in einem Protokoll aufzeichnen und dieses dem Ausführenden als Nachweis zurückgeben. +Ergebnis: Der Umfang der Löschung ist belegbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, `DsgvoDeleteRightDeleteContacts` mit `deleteProtocol` und Rückgabe `Result`, Zeilen 787-850 - Begründung: das Protokoll wird tatsächlich mitgeführt und zurückgegeben. +Prüfidee: Die Löschung von drei Kontakten muss drei Protokollzeilen liefern. +Tracelinks: SyRS-150, StRS-050 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - das Protokoll ist im Zielsystem dauerhaft zu speichern, nicht nur zurückzugeben. +Status: belegt +``` + +``` +ID: SwRS-151 +Titel: Kennzeichnung gelöschter Kontakte statt physischer Löschung +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Kontakt wird nach DSGVO gelöscht. +Fakt: Die auskommentierten Anonymisierungsanweisungen setzen `Status = 0` und ersetzen Namens-, Telefon-, Fax-, E-Mail-, Domain-, Straßen-, Postleitzahl-, Orts- und Kommentarfelder durch Vorgabewerte beziehungsweise durch `DsgvoDeletedContactMessage`; die aktiven Löschmethoden für Kontaktpersonen folgen demselben Muster. +Aussage: Das System soll Kontakte durch Deaktivierung und Überschreiben der personenbezogenen Felder anonymisieren statt Datensätze physisch zu entfernen, damit Belegreferenzen erhalten bleiben. +Ergebnis: Belege bleiben referenziell gültig, ohne personenbezogene Daten zu enthalten. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 863-903, Anonymisierungsanweisungen mit `SET h.Status = 0, h.Name = '{DsgvoDeletedContactMessage}', h.Fon = default, …` - Begründung: das Anonymisierungsmuster ist dort ausformuliert. + - [PRIMÄR] ebenda, Zeilen 26-27, die beiden Kennzeichnungstexte - Begründung: die Kennzeichnung ist als Konstante festgelegt. +Prüfidee: Ein anonymisierter Kontakt muss in Altbelegen weiterhin referenzierbar sein, jedoch keine personenbezogenen Daten mehr tragen. +Tracelinks: SyRS-151, SyRS-150 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - das Verfahren ist fachlich richtig, aber derzeit für Kunden, Lieferanten und Accounts nicht aktiv. +Status: belegt +``` + +``` +ID: SwRS-152 +Titel: Bereinigungsarten als Aufzählung +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Eine Bereinigung wird geplant. +Fakt: `DataSecurityCleanUpStatsKind` benennt die Bereinigungsarten (u. a. `CustomersDeleted`); `DataSecurityStatsDTO` trägt Art und Anzahl; `DataSecurityCleanUpStatsFilter` schränkt ein (`FilterForDeletedCustomers`). +Aussage: Das System soll die möglichen Bereinigungsarten als Aufzählung führen und je Art eine eigene Ermittlungs- und Ausführungsroutine bereitstellen. +Ergebnis: Neue Bereinigungsarten sind ohne Änderung an der Oberfläche ergänzbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, `GetDeletedCustomers` mit `stats.CleanUpStatsKind = DataSecurityCleanUpStatsKind.CustomersDeleted`, Zeilen 353-360 - Begründung: die Aufzählung ordnet Ermittlung und Ergebnis zu. +Prüfidee: Jede Bereinigungsart muss eine eigene Kennzahl liefern. +Tracelinks: SyRS-152 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-153 +Titel: Audit-Felder als Bestandteil der Belegbasis +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Beleg wird angelegt oder geändert. +Fakt: `ReceiptBase` führt `CreatedByI3D`, `CreatedAt`, `ChangedByI3D`, `ChangedAt`, `CreatedThroughApplicationVersion`, `ChangedThroughApplication` und `ChangedThroughApplicationVersion`; `SaveReceipt` setzt sie unmittelbar vor der Rechteprüfung, wobei die Erzeugungsfelder nur bei Neuanlage aus den Änderungsfeldern übernommen werden. +Aussage: Das System soll die Audit-Felder in der Belegbasis führen und bei Neuanlage die Erzeugungsfelder aus den Änderungsfeldern ableiten, damit beide stets denselben Vorgang bezeichnen. +Ergebnis: Erzeugungs- und Änderungsangaben eines neuen Belegs stimmen überein. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Zuweisungen `receipt.CreatedAt = receipt.ChangedAt; receipt.CreatedByI3D = receipt.ChangedByI3D; receipt.CreatedThroughApplicationVersion = receipt.ChangedThroughApplicationVersion;` im Zweig `if (isNewReceipt)` - Begründung: die Ableitung erfolgt dort. + - [KONTEXT] `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitt „Audit Fields" - Begründung: benennt die Feldgruppe. +Prüfidee: Bei einem neu angelegten Beleg müssen Erzeugungs- und Änderungszeitpunkt identisch sein. +Tracelinks: SyRS-153, StRS-051 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-154 +Titel: Drei Protokollmechanismen für Belegänderungen +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Analysierbarkeit) +Akteur: Entwicklung +Vorbedingung: Eine Belegänderung ist nachzuvollziehen. +Fakt: Belegänderungen werden auf drei Wegen festgehalten: über die Audit-Felder der Belegbasis, über Versionstabellen je Belegart und über feldbezogene Protokolleinträge in `ReceiptLogBL` (etwa `CreateContingentKindEntry`); daneben besteht der allgemeine Mechanismus `ChangeTracking/History` und die gemeinsame Protokolltabelle `AnlageLog`. +Aussage: Das System soll Belegänderungen über einen einheitlichen Mechanismus nachvollziehbar machen. +Ergebnis: Eine Auskunft über Änderungen erfordert nicht die Abfrage mehrerer Protokollquellen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `WriteReceiptLogs` mit `_receiptLogBL.CreateContingentKindEntry(...)` neben den Audit-Feldzuweisungen in `SaveReceipt` - Begründung: zwei Mechanismen in derselben Klasse. + - [SEKUNDÄR] `src/backend/Centron.BL/ChangeTracking/History/`, `SSMS_DB_SCHEMA.sql` (Versionstabellen) - Begründung: die weiteren Mechanismen. +Prüfidee: Eine Auskunft „wer hat wann welches Feld geändert" muss aus einer Quelle beantwortbar sein. +Tracelinks: SyRS-154, SyRS-153 +Konsolidierung: Kandidat: SwRS-154 selbst — Audit-Felder, Versionstabellen, `ReceiptLogBL`, `ChangeTracking/History` und `AnlageLog` bilden dieselbe Aufgabe fünffach ab. +Übernahmewürdigkeit: übernehmen - im Zielsystem mit einem Ereignisprotokoll. +Status: belegt +``` + +``` +ID: SwRS-160 +Titel: Selbstenthaltende Veröffentlichung der Webanwendung +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Installierbarkeit) +Akteur: Betrieb +Vorbedingung: Ein Container wird gebaut. +Fakt: `docker/Dockerfile` verwendet `mcr.microsoft.com/dotnet/sdk:10.0.201-alpine3.23` als Bauumgebung, veröffentlicht `CentronNexus.Host.csproj` mit `-c release --self-contained true -o ./app` und kopiert das Ergebnis in ein Laufzeitabbild `dotnet/runtime:10.0.5-alpine3.23`; die DevExpress-Lizenz wird über das Bauargument `dx_license` in `$HOME/.config/DevExpress/DevExpress_License.txt` geschrieben. +Aussage: Das System soll die Webanwendung selbstenthaltend veröffentlichen und in einem getrennten Laufzeitabbild ausliefern, das keine Bauwerkzeuge enthält. +Ergebnis: Das Auslieferungsabbild ist klein und enthält keine Übersetzungswerkzeuge. +Belege: + - [PRIMÄR] `docker/Dockerfile`, zweistufiger Bau mit `FROM … sdk … AS base` und `FROM … runtime …` sowie `dotnet publish … --self-contained true` - Begründung: der zweistufige Bau ist dort umgesetzt. +Prüfidee: Das Laufzeitabbild darf kein `dotnet build` ausführen können. +Tracelinks: SyRS-160, StRS-052 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die Lizenzdatei ist im Zielsystem nicht über ein Bauargument, sondern über ein Geheimnis einzubringen. +Status: belegt +``` + +``` +ID: SwRS-161 +Titel: Skriptmethoden mit reservierter Nummer +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Entwicklung +Vorbedingung: Eine Datenbankänderung wird eingebracht. +Fakt: Der Zweig `Administration/Scripts/ScriptMethods` enthält `IScriptMethod`, `BaseScriptMethod`, `IRecurringScriptMethod`, `BaseRecurringScriptMethod`, `ScriptMethodKind`, `ScriptMethodPool`, `ScriptMethodsCollection`, `ScriptMethodsCollectionMonitoring`, `ScriptHelpers`, `ScriptSpecialObjects`, `SqlStatements`, `Scripts` und `RiverbirdScripts`; jede Skriptmethode trägt eine `ScriptNumber`, gegen die die Tabelle der ausgeführten Änderungen (`DBUpdate`) abgeglichen wird. +Aussage: Das System soll jede Datenbankänderung als Skriptmethode mit eindeutiger, reservierter Nummer führen und zwischen einmaligen und wiederkehrenden Skripten unterscheiden. +Ergebnis: Jede Änderung wird genau einmal ausgeführt; wiederkehrende Skripte laufen bei jedem Start. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Scripts/ScriptMethods/IScriptMethod.cs`, `IRecurringScriptMethod.cs`, `ScriptMethodPool.cs` - Begründung: die Unterscheidung und die Sammlung sind dort definiert. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, Abgleich `dbUpdates.All(ff => ff.ScriptNumber != f.ScriptNumber)` - Begründung: die Nummer ist der Abgleichsschlüssel. + - [KONTEXT] `docs/guides/database/create-scripts.md` - Begründung: beschreibt die Nummernreservierung. +Prüfidee: Zwei Skriptmethoden dürfen nicht dieselbe Nummer tragen. +Tracelinks: SyRS-161 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-162 +Titel: Abschaltbarkeit und Versionsüberschreibung der Skriptausführung +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Testbarkeit) +Akteur: Entwicklung +Vorbedingung: Die Skriptausführung wird geprüft. +Fakt: `ScriptEngineBL` führt die statische Eigenschaft `public static Func ShouldExecuteScripts { get; set; }` und den Parameter `Version currentVersionOverride`; ein `#if DEBUG`-Block behandelt die Entwicklungsversion `1.0.0.0` gesondert. +Aussage: Das System soll die Ausführung der Datenbankskripte abschaltbar und die zugrunde gelegte Programmversion überschreibbar machen, damit die Migration prüfbar ist. +Ergebnis: Migrationen sind unabhängig vom tatsächlichen Programmstand testbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, `ShouldExecuteScripts` (Zeile 37) und Parameter `currentVersionOverride` (Zeile 39) sowie der `#if DEBUG`-Block (Zeile 57 ff.) - Begründung: die Prüfbarkeit ist dort vorgesehen. +Prüfidee: Mit `ShouldExecuteScripts` auf „falsch" darf beim Start kein Skript ausgeführt werden. +Tracelinks: SyRS-162, SyRS-161 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - der übersetzungsabhängige `#if DEBUG`-Block ist im Zielsystem durch eine Konfiguration zu ersetzen. +Status: belegt +``` + +``` +ID: SwRS-163 +Titel: Übersetzung auf eigenem Bauserver mit Zeitgrenze +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Testbarkeit) +Akteur: Entwicklung +Vorbedingung: Ein Bau wird angestoßen. +Fakt: `.github/workflows/build.yml` läuft auf `runs-on: group: self-hosted, labels: [self-hosted, Windows, X64]` mit `timeout-minutes: 180` und `permissions: contents: read`; Bauläufe für Pull Requests werden nur ausgeführt, wenn der Pull Request kein Entwurf ist und aus demselben Repository stammt (`github.event.pull_request.head.repo.full_name == github.repository`). +Aussage: Das System soll auf einem eigenen Windows-Bauserver übersetzt werden, den Bau nach spätestens drei Stunden abbrechen und Bauläufe für fremde Beitragszweige nicht ausführen. +Ergebnis: Der Bauserver wird nicht durch fremden Code oder endlose Läufe belastet. +Belege: + - [PRIMÄR] `.github/workflows/build.yml`, `runs-on` mit `self-hosted`, `timeout-minutes: 180` und die `if`-Bedingung auf `head.repo.full_name` - Begründung: die drei Festlegungen sind dort wirksam. +Prüfidee: Ein Pull Request aus einer Abspaltung darf keinen Bau auf dem eigenen Server auslösen. +Tracelinks: SyRS-163 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Absicherung der Bauumgebung. +Status: belegt +``` + +``` +ID: SwRS-164 +Titel: Testprojekte spiegeln die Projektstruktur +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Testbarkeit) +Akteur: Entwicklung +Vorbedingung: Ein Baustein wird geprüft. +Fakt: Die Testprojekte spiegeln die Quellstruktur: `tests/backend/Centron.Tests.BL` und `Centron.Tests.DAO` zu `src/backend`, `tests/shared/Centron.Tests.Core` und `Centron.Tests.Controls` zu `src/shared`, `tests/apis/*` zu `src/apis`, `tests/CentronNexusTests` zu `src/nexus`; hinzu kommen `Centron.Tests.Integration`, `Centron.Tests.EndToEnd` und `PlaywrightTests`. +Aussage: Das System soll je Quellbereich ein entsprechendes Testprojekt führen, damit die Zuordnung von Test und Prüfling ohne weitere Kenntnis erkennbar ist. +Ergebnis: Zu jedem Baustein ist das zuständige Testprojekt auffindbar. +Belege: + - [PRIMÄR] `tests/backend/`, `tests/shared/`, `tests/apis/` gegenüber `src/backend/`, `src/shared/`, `src/apis/` - Begründung: die Spiegelung ist in der Verzeichnisstruktur umgesetzt. +Prüfidee: Zu jedem Quellprojekt unter `src/apis` muss ein Testprojekt unter `tests/apis` bestehen. +Tracelinks: SyRS-164 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-165 +Titel: Protokollierung mit strukturierten Platzhaltern +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Analysierbarkeit) +Akteur: Betrieb +Vorbedingung: Ein Ereignis wird protokolliert. +Fakt: Protokollaufrufe verwenden benannte Platzhalter statt Zeichenkettenverkettung, etwa `Logger.Info("Basic authentication attempt ({RequestId}) received for user: {UserName}.", Auth.RequestId, Auth.UserName)` und `Logger.Info("c-entron user {UserName} (Sichbenu table) is deactivated through the date 'Konto deaktiviert von' ({Date}).", user.Name, user.AccountDisabledFromDate)`. +Aussage: Das System soll Protokolleinträge mit benannten Platzhaltern erzeugen, damit die Werte maschinell auswertbar bleiben. +Ergebnis: Protokolle sind nach Benutzername, Vorgangskennung und weiteren Werten filterbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs` und `Authenticator.cs`, die genannten Protokollaufrufe - Begründung: die Platzhalter sind dort tatsächlich benannt. +Prüfidee: Eine Protokollsuche nach einem Benutzernamen muss alle zugehörigen Einträge finden. +Tracelinks: SyRS-165, SwRS-105 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-166 +Titel: Datenqualitätsprüfungen mit benannten Befundarten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Betrieb +Vorbedingung: Eine Prüfung läuft. +Fakt: `DirectoryCheckBL` liefert `IList`; `GetCaptionForDirectoryCheckItem(CentronObjectKindNumeric objectKind)` ist statisch und liefert je Objektart eine Bezeichnung; `DirectoryCheckRecursiveItem` im Dateiverwaltungszweig unterstützt die rekursive Prüfung. +Aussage: Das System soll Prüfbefunde je Objektart mit einer sprechenden Bezeichnung versehen, damit die Befunde ohne Kenntnis der internen Kodierung lesbar sind. +Ergebnis: Befunde sind für den Betrieb unmittelbar verständlich. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Services/DataQuality/DirectoryCheckBL.cs`, `GetCaptionForDirectoryCheckItem`, Zeile 84 - Begründung: die Bezeichnungszuordnung ist dort implementiert. +Prüfidee: Ein Befund zu einem Ticket muss die Bezeichnung „Ticket" tragen, nicht die Zahl der Objektart. +Tracelinks: SyRS-166, SyRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-167 +Titel: Zeitfensterbasierte Telemetriezähler +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Nutzung wird erfasst. +Fakt: `TelemetryBL` arbeitet mit `McToolUsageBucketIncrement`, `ArtificialIntelligenceToolUsageBucketIncrement` und `ApiCallBucketIncrement` (jeweils `IReadOnlyCollection<…>` in Stapelmethoden); `GetCompletedPendingApiCalls(DateTime maxBucketStartUtc)` liefert nur Zeitfenster, deren Beginn vor dem Grenzwert liegt; `LoadAllMcpToolNames()` und `LoadAllApiMethodNames()` lösen Namen über Nachschlagtabellen auf; die Methoden sind `virtual`. +Aussage: Das System soll Nutzungsdaten als Zähler je Zeitfenster erfassen, nur abgeschlossene Zeitfenster zur Übermittlung freigeben und Werkzeugnamen über Nachschlagtabellen normalisieren. +Ergebnis: Übermittelte Nutzungsdaten sind vollständig und verdichtet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Telemetry/TelemetryBL.cs`, `GetCompletedPendingApiCalls(DateTime maxBucketStartUtc)` (Zeile 308) und `UpsertApiCallBatch` (Zeile 173) - Begründung: Zeitfensterlogik und Stapelverarbeitung sind dort umgesetzt. + - [SEKUNDÄR] ebenda, `LoadAllApiMethodNames` (Zeile 336) - Begründung: die Namensnormalisierung. +Prüfidee: Ein noch laufendes Zeitfenster darf nicht zur Übermittlung freigegeben werden. +Tracelinks: SyRS-167 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-168 +Titel: Verbindungsarten als Aufzählung mit Modulzuordnung +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Modul wird geöffnet. +Fakt: `CentronConnectionType` unterscheidet mindestens `SqlServer` und `CentronWebServices`; jedes Modul deklariert `CentronConnectionType[] SupportsConnectionTypes`; `ClassContainer.Instance.ConnectionType` liefert die aktuelle Verbindungsart; die Verbindungsverwaltung liegt in `Administration/Connections/` und `c-entron.misc.ConnectionManager`. +Aussage: Das System soll die unterstützten Verbindungsarten je Modul als Deklaration führen und vor dem Öffnen gegen die aktuelle Verbindung prüfen. +Ergebnis: Nicht unterstützte Module werden gar nicht erst geöffnet. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/CentronModule.cs`, `OpenModule` mit `module.SupportsConnectionTypes.All(f => f != ClassContainer.Instance.ConnectionType)` - Begründung: die Deklaration wird dort ausgewertet. + - [SEKUNDÄR] `src/webservice/c-entron.misc.ConnectionManager/`, `src/backend/Centron.BL/Administration/Connections/` - Begründung: die Verbindungsverwaltung. +Prüfidee: Ein Modul mit nur `SqlServer` in der Deklaration darf bei Webservice-Verbindung nicht geöffnet werden. +Tracelinks: SyRS-168, SwRS-002 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - im Zielsystem entfällt die Unterscheidung. +Status: belegt +``` + +## 12. Auswertung, Integration und weitere Bausteine + +``` +ID: SwRS-170 +Titel: Statistikbereiche nach Auswertungsgegenstand geschnitten +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modularität) +Akteur: Entwicklung +Vorbedingung: Eine Auswertung wird geändert. +Fakt: `Centron.BL/Statistics` gliedert sich in `Accounts`, `Administration`, `ContractStatistics`, `MspCollectors`, `MspStatistics`, `OrderStatistics`, `SaleStatistics`, `Sales` und `TicketStatistics`; ergänzend bestehen `Sales/Support/CustomerHelpdeskStatisticBL`, `EmployeeHelpdeskTimerStatisticBL`, `HelpdeskStatisticsBL` und `EmployeeArea/EmployeeStatisticBL`. +Aussage: Das System soll Auswertungen nach Auswertungsgegenstand getrennten Bausteinen zuordnen. +Ergebnis: Eine Änderung an der Ticketstatistik berührt die Umsatzstatistik nicht. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Statistics/` mit den neun genannten Unterbereichen - Begründung: die Aufteilung ist im Verzeichnis umgesetzt. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskStatisticsBL.cs`, `CustomerHelpdeskStatisticBL.cs`, `EmployeeHelpdeskTimerStatisticBL.cs` - Begründung: belegen weitere, außerhalb des Statistikzweigs liegende Auswertungen. +Prüfidee: Eine Änderung an `TicketStatistics` darf `SaleStatistics` nicht übersetzungsunfähig machen. +Tracelinks: SyRS-170 +Konsolidierung: Kandidat: SwRS-170 selbst — Ticketstatistiken liegen sowohl unter `Statistics/TicketStatistics` als auch im Supportzweig. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-171 +Titel: Eigener Sprachanalysator für den Suchindex +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Text wird indiziert oder gesucht. +Fakt: `IndexSearch/GermanAnalyzer.cs` stellt einen eigenen Sprachanalysator bereit; `IndexBuilder.cs` erzeugt den Index, das Verzeichnis `Indexes` enthält die objektartabhängigen Indexdefinitionen; `ObjectIndexingFailedException` behandelt Indizierungsfehler; `SearchIndexQueryable(string searchText, CentronObjectKindNumeric? kind)` liefert ein abfragbares Ergebnis für weitere Einschränkungen. +Aussage: Das System soll Suchtexte mit einem auf die deutsche Sprache abgestimmten Analysator zerlegen und das Suchergebnis als weiter einschränkbare Abfrage bereitstellen. +Ergebnis: Deutsche Wortformen und zusammengesetzte Wörter werden gefunden. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs` - Begründung: der Analysator ist eigens implementiert. + - [PRIMÄR] `src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs`, `SearchIndexQueryable`, Zeile 49 - Begründung: liefert das einschränkbare Ergebnis. +Prüfidee: Die Suche nach „Rechnung" muss auch „Rechnungen" finden. +Tracelinks: SyRS-171 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-172 +Titel: Aufforderungstexte der KI als eigene Artefakte +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Eine KI-Funktion wird aufgerufen. +Fakt: Der Zweig `ArtificialIntelligence/Prompts` hält die Aufforderungstexte; die Einstellungsseite `ArtificialIntelligencePromptSettingsController` ist in `GetSettingsWithoutModule()` registriert; `IMessage` und `OpenAiMessage` bilden den Nachrichtenaustausch ab; `Chat` enthält den Chatverlauf, `ArtificialIntelligenceChatsController` stellt ihn bereit. +Aussage: Das System soll die Aufforderungstexte der KI-Funktionen als eigene, pflegbare Artefakte führen und nicht im Programmcode festschreiben. +Ergebnis: Aufforderungstexte sind ohne Programmänderung anpassbar. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `new ArtificialIntelligencePromptSettingsController()` in `GetSettingsWithoutModule()` - Begründung: die Pflegeoberfläche ist registriert. + - [SEKUNDÄR] `src/backend/Centron.BL/ArtificialIntelligence/Prompts/`, `Chat/` - Begründung: die Ablage der Texte und des Verlaufs. +Prüfidee: Eine Änderung des Aufforderungstextes muss ohne Neuübersetzung wirksam werden. +Tracelinks: SyRS-172 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-173 +Titel: Fachlich geschnittene REST-Ressourcen +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Fremdsystem +Vorbedingung: Die Schnittstelle wird genutzt. +Fakt: Die 38 versionierten Controller sind nach fachlichen Bereichen gruppiert: `Accounts`, `Administration` (sieben Controller), `Contracts`, `Customers`, `DataExchange` (fünf), `Helpdesks`, `Integrations` (sechs), `Nexoware` (zwei), `Offers`, `Orders`, `Receipts` (vier), `SelfCare`, `Tickets` (drei), `WebAccount`, `WebVersion`. +Aussage: Das System soll die REST-Ressourcen nach fachlichen Bereichen gruppieren und je Ressource einen eigenen Controller führen. +Ergebnis: Die Schnittstelle ist ohne zusätzliche Dokumentation auffindbar strukturiert. +Belege: + - [PRIMÄR] `src/webservice/Centron.Controllers/Controllers/v1/` mit den genannten 15 Bereichsverzeichnissen - Begründung: die Gruppierung ist im Verzeichnis umgesetzt. +Prüfidee: Ein neuer Endpunkt zu Tickets muss unter `Controllers/v1/Tickets` liegen. +Tracelinks: SyRS-173 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-174 +Titel: Hostvarianten mit gemeinsamer Kernbibliothek +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Anpassbarkeit) +Akteur: Betrieb +Vorbedingung: Der Webservice wird betrieben. +Fakt: `src/webservice` gliedert sich in `Centron.WebServices.Core` (Kern), `Centron.Controllers` (REST-Schicht), `Centron.Host` (gemeinsame Hostlogik) sowie die beiden Betriebsformen `Centron.Host.Console` und `Centron.Host.WindowsService`; `Centron.Host.RestRequests` liefert die Anfragetypen (`JwtLoginRequest`, `JwtConnectAccountRequest`). +Aussage: Das System soll die Hostlogik einmalig bereitstellen und die Betriebsformen als dünne Aufsätze darauf führen. +Ergebnis: Konsolen- und Dienstbetrieb verhalten sich funktional gleich. +Belege: + - [PRIMÄR] `src/webservice/Centron.Host/`, `Centron.Host.Console/`, `Centron.Host.WindowsService/` als getrennte Projekte mit gemeinsamer Kernabhängigkeit - Begründung: die Aufteilung belegt den gemeinsamen Kern. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs`, Verwendung von `Centron.Host.RestRequests` - Begründung: die Anfragetypen stammen aus dem gemeinsamen Hostprojekt. +Prüfidee: Derselbe Endpunkt muss in beiden Betriebsformen dieselbe Antwort liefern. +Tracelinks: SyRS-174, SyRS-160 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-175 +Titel: Integrationsressourcen je Fremdsystem +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Fremdsystem +Vorbedingung: Ein Fremdsystem greift zu. +Fakt: `Controllers/v1/Integrations` enthält `IntegrationsController`, `ObjectExternalReferencesController`, `RmmController`, `DocBeeConnectorConfigurationController`, `EsCustomerGroupsController` und `EsRolesController`; `Controllers/v1/DataExchange` ergänzt `DocBeeTicketTemplatesController`, `DocBeeTicketTimersController`, `DocuFormApiSettingsController`, `RmmConnectionSettingsController` und `TelekomDiveController`. +Aussage: Das System soll je angebundenem Fremdsystem eigene REST-Ressourcen für Konfiguration und Datenaustausch bereitstellen. +Ergebnis: Fremdsysteme greifen auf klar abgegrenzte Endpunkte zu. +Belege: + - [PRIMÄR] `src/webservice/Centron.Controllers/Controllers/v1/Integrations/` und `Controllers/v1/DataExchange/` mit den elf genannten Controllern - Begründung: die Abgrenzung ist im Code umgesetzt. +Prüfidee: Die Konfiguration des RMM-Zugangs muss über einen anderen Endpunkt erfolgen als der Datenabruf. +Tracelinks: SyRS-175, SyRS-173 +Konsolidierung: Kandidat: SwRS-175 selbst — docBee- und RMM-Endpunkte liegen auf zwei Bereiche verteilt. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-176 +Titel: Massenupdate als eigener Baustein mit eigenem Modul +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Eine Massenänderung wird ausgeführt. +Fakt: `MassUpdate/MassUpdateBL.cs` bildet die Ausführung ab; `Entities/MassUpdate` hält die zugehörigen Datenstrukturen; das Oberflächenmodul liegt unter `Modules/Massenupdates/` und wird als `DataUpdaterAppModuleController` in der Region „Stammdaten" registriert. +Aussage: Das System soll die Massenänderung als eigenständigen Baustein mit eigener Datenstruktur und eigenem Modul führen. +Ergebnis: Massenänderungen sind unabhängig von den Fachmodulen erweiterbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs` und `src/backend/Centron.Entities/Entities/MassUpdate/` - Begründung: Fachlogik und Datenstruktur sind eigenständig. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Massenupdates/` - Begründung: eigenes Oberflächenmodul. +Prüfidee: Eine zusätzliche Massenänderungsart darf keine Änderung an den Fachmodulen erfordern. +Tracelinks: SyRS-176 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-177 +Titel: SQL-Verwaltung mit Datenbankauskunft für den Lizenzserver +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Lizenzanfrage wird gestellt. +Fakt: `SQLManagementBL.GetDatabaseInfosForLicenseServer()` liefert `DatabaseId`, `DatabaseName`, `DatabaseCreatedDate` und `DatabaseOwnerSid`; `LicenseManager.SettingsForWebService()` ergänzt sie um `MachineName` und `WindowsServiceName` und übergibt sie als `GetLicenseAdditionalData` an den Lizenzserver; im Debug-Fall lautet der Dienstname „Debug Entwicklerversion". +Aussage: Das System soll dem Lizenzserver eine eindeutige Kennzeichnung der Installation aus Datenbank- und Rechnerangaben übermitteln. +Ergebnis: Lizenzen sind einer konkreten Installation zuzuordnen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, `SettingsForWebService`, Zeilen 70-95, mit `GetDatabaseInfosForLicenseServer()` und dem Debug-Zweig - Begründung: die übermittelten Angaben sind dort zusammengestellt. + - [SEKUNDÄR] `src/backend/Centron.BL/Administration/SQLManagement/` - Begründung: liefert die Datenbankangaben. +Prüfidee: Zwei Installationen auf derselben Datenbank müssen dieselbe Datenbankkennung melden. +Tracelinks: SyRS-177, SyRS-103 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die Zuordnung von Lizenz zu Installation bleibt im SaaS-Betrieb erforderlich. +Status: belegt +``` + +``` +ID: SwRS-178 +Titel: Reportkomponenten nach Aufgabe getrennt +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modularität) +Akteur: Entwicklung +Vorbedingung: Eine Formularfunktion wird geändert. +Fakt: `Centron.BL/ReportEngine` gliedert sich in `CustomPdfGenerators`, `FastReportHelper`, `ImportExport`, `PdfExport`, `PdfStategy`, `ReplacementBLs`, `ReportDataBL`, `ReportDataBinSettingsBL`, `ReportDataDefaultBL`, `ReportDataQueryBL`, `ReportDataQueryTagBL` und `ReportDataSettingsBL`; die Einstellungsseite `PdfExportSettingsController` und das Modul `PdfExport` ergänzen sie. +Aussage: Das System soll Formularvorlagen, Datenabfragen, Ersetzungen, PDF-Erzeugung und Export als getrennte Komponenten führen. +Ergebnis: Ein Wechsel der Formularmaschine berührt die Datenabfragen nicht. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/ReportEngine/` mit den zwölf genannten Bestandteilen - Begründung: die Aufteilung ist im Verzeichnis umgesetzt. + - [SEKUNDÄR] `src/backend/Centron.BL/ReportEngine/PdfStategy/` - Begründung: die austauschbare PDF-Strategie. +Prüfidee: Eine Änderung an `PdfExport` darf `ReportDataQueryBL` nicht berühren. +Tracelinks: SyRS-178, SyRS-110 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-179 +Titel: Erwartete Ereignisse mit getrennter Auswertung +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Erwartete Ereignisse sind definiert. +Fakt: `ExpectedEvents/ExpectedEventsBL.cs` bildet die Überwachung ab; die Oberfläche besteht aus zwei getrennten Modulen: `Helpdesk/ExpectedEvents/Controller` und `Helpdesk/ExpectedEventsReporting/Controller`, gesteuert über die Rechte `SHOW_EXPECTEDEVENTS` und `SHOW_EXPECTEDEVENTSREPORTING`; die Entitäten liegen in `Entities/ExpectedEvents`. +Aussage: Das System soll Definition und Auswertung erwarteter Ereignisse als getrennte Module mit eigenen Rechten führen. +Ergebnis: Auswertende Rollen benötigen keine Pflegerechte. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Automatisierung", zwei getrennte Registrierungen mit `SHOW_EXPECTEDEVENTS` und `SHOW_EXPECTEDEVENTSREPORTING` - Begründung: die Trennung ist über die Rechte durchgesetzt. + - [SEKUNDÄR] `src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs`, `src/backend/Centron.Entities/Entities/ExpectedEvents/` - Begründung: Fachlogik und Datenstruktur. +Prüfidee: Ein Benutzer nur mit dem Auswertungsrecht darf keine erwarteten Ereignisse anlegen. +Tracelinks: SyRS-179 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-180 +Titel: Arbeitsschritte am Artikel als Produktionsgrundlage +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Produktion +Vorbedingung: Ein Artikel wird gefertigt. +Fakt: Das Schema führt `ArticleWorkItems`; `Warehousing/ArticleWorkItemBL.cs` verwaltet die Arbeitsschritte, `Warehousing/ArticleProduction/` die produktionsbezogene Artikellogik; `Production/ProductionBL.cs` und `ProductionOrderBL.cs` bilden die Aufträge ab; im Web bestehen `WorkStepTemplateComponent` und `ProductionOrderOverView`; in der Ticketabrechnung erscheinen Arbeitsschritte über `TimerBillingBL.GetArticleWorkItems(List customerI3Ds)` und die Auswahl `ArticleWorkItemSelection.razor`. +Aussage: Das System soll Arbeitsschritte am Artikel führen und sie sowohl in Produktionsaufträgen als auch in der Leistungsabrechnung verwenden. +Ergebnis: Fertigung und Abrechnung greifen auf dieselben Arbeitsschritte zu. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `ArticleWorkItems` - Begründung: die Arbeitsschritte sind zentral persistiert. + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs`, `GetArticleWorkItems(List customerI3Ds)`, Zeile 98 - Begründung: belegt die Verwendung derselben Arbeitsschritte in der Abrechnung. + - [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/ArticleWorkItemBL.cs`, `Warehousing/ArticleProduction/` - Begründung: die verwaltende Fachlogik. +Prüfidee: Ein am Artikel gepflegter Arbeitsschritt muss sowohl im Produktionsauftrag als auch in der Ticketabrechnung auswählbar sein. +Tracelinks: SyRS-180, SyRS-035 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-181 +Titel: Mitarbeiterbausteine nach Aufgabe getrennt +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Modularität) +Akteur: Entwicklung +Vorbedingung: Eine Mitarbeiterfunktion wird geändert. +Fakt: `Centron.BL/EmployeeArea` enthält `AppUserBL`, `EmployeeBL`, `EmployeeArticleBL`, `EmployeeDepartmentBL`, `EmployeeHolidayBL`, `EmployeeRfidTokenBL`, `EmployeeStatisticBL`, `EmployeeUserSettingsBL` und `TeamManagement`; `Administration/Employees` ergänzt `EmployeeDepartmentAssignmentBL`, `EmployeeDepartmentSortingBL`, `EmployeeFavoriteBL`, `EmployeeSettingBL`, `EmployeeSettingsProfileBL`, `EmployeeSkillsBL`, `EmployeeToSalesAreaBL`, `PersonalManagementBL` und `SkillgroupBL`. +Aussage: Das System soll mitarbeiterbezogene Funktionen in eigenständige Bausteine gliedern. +Ergebnis: Eine Änderung an der Urlaubsverwaltung berührt die Anmeldung nicht. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/EmployeeArea/` und `src/backend/Centron.BL/Administration/Employees/` mit den genannten Klassen - Begründung: die Aufteilung ist im Verzeichnis erkennbar. +Prüfidee: Eine Änderung an `EmployeeHolidayBL` darf `AppUserBL` nicht berühren. +Tracelinks: SyRS-181 +Konsolidierung: Kandidat: SwRS-181 selbst — mitarbeiterbezogene Fachlogik liegt in zwei Bereichen (`EmployeeArea`, `Administration/Employees`). +Übernahmewürdigkeit: übernehmen - im Zielsystem in einem Bereich zu bündeln. +Status: belegt +``` + +``` +ID: SwRS-182 +Titel: Auswertung von Zeiten über Artikelkennungen +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Mitarbeiterzeiten werden ausgewertet. +Fakt: `HelpdeskTimerBL.GetEmployeeTimeStatistics(ICollection articleI3Ds, DateTime? dateFrom, DateTime? dateTo)` nimmt Artikelkennungen statt Mitarbeiterkennungen entgegen; die Weboberfläche `EmployeeTimerStatistics` bietet dazu `MultipleEmployeeSelection`, `MultipleDepartmentSelection` und `MultipleAccountSelection`, die zuvor in Artikelkennungen aufgelöst werden müssen. +Aussage: Das System soll Mitarbeiterzeiten über die Kennung des Mitarbeiterartikels auswerten und die Auflösung von Mitarbeiter zu Artikel an einer Stelle vornehmen. +Ergebnis: Auswertungen liefern unabhängig vom Auswahlweg dasselbe Ergebnis. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `GetEmployeeTimeStatistics(ICollection articleI3Ds, …)`, Zeile 710 - Begründung: die Signatur belegt die Auswertung über Artikelkennungen. + - [SEKUNDÄR] `src/nexus/CentronNexus/ServiceBoard/EmployeeTimerStatistics/Component/MultipleEmployeeSelection.razor` - Begründung: die Auswahl erfolgt über Mitarbeiter und muss umgesetzt werden. +Prüfidee: Die Auswahl eines Mitarbeiters ohne Mitarbeiterartikel muss ein nachvollziehbares Ergebnis liefern. +Tracelinks: SyRS-182 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem ist die unmittelbare Zuordnung zum Mitarbeiter zu prüfen. +Status: belegt +``` + +``` +ID: SwRS-183 +Titel: Kundenaktivität als beidseitig auflösbare Verknüpfung +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: Eine Aktivität bezieht sich auf einen Beleg. +Fakt: `ReceiptBL.GetReceiptsForAccountActivity(int accountActivityI3D)` und `GetAccountActivitiesForReceipt(CentronObjectKindNumeric receiptKind, int receiptI3D, bool loadActivitiesFromProcessedReceipts)` lösen die Verknüpfung in beide Richtungen auf; `SaveAccountActivityForReceipt(AccountActivityForReceipt)` und `DeleteAccountActivityForReceipt(...)` pflegen sie; der Schalter `loadActivitiesFromProcessedReceipts` bezieht die Aktivitäten der Vorgängerbelege ein. +Aussage: Das System soll die Verknüpfung zwischen Kundenaktivität und Beleg als eigene Beziehung führen, in beide Richtungen auflösen und auf Wunsch die Aktivitäten der Vorgängerbelege einbeziehen. +Ergebnis: Die Kundenhistorie ist vollständig, auch über die Belegkette hinweg. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `GetReceiptsForAccountActivity` (Zeile 540), `GetAccountActivitiesForReceipt` (Zeile 545) mit `loadActivitiesFromProcessedReceipts`, `SaveAccountActivityForReceipt` (Zeile 623), `DeleteAccountActivityForReceipt` (Zeile 629) - Begründung: die vier Methoden belegen Beziehung und beidseitige Auflösung. + - [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `AccountActivities` - Begründung: die Aktivitäten sind persistiert. +Prüfidee: Zu einer Rechnung müssen mit gesetztem Schalter auch die Aktivitäten des zugrunde liegenden Auftrags erscheinen. +Tracelinks: SyRS-183, SwRS-024 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 13. Weitere Module des Inventars + +``` +ID: SwRS-190 +Titel: Vertragsauswertung als eigenes Modul +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Controlling +Vorbedingung: Verträge sind erfasst. +Fakt: Das Modul `ContractEvaluation2` ist in der Region „Controlling/Analytics" registriert; die Auswertungslogik liegt in `Statistics/ContractStatistics`; die Einstellungsseite `MspEvaluationSettingsController` ergänzt sie; die Modulbezeichnung trägt die Ziffer 2, was auf eine Neufassung hinweist. +Aussage: Das System soll die wirtschaftliche Auswertung von Verträgen als eigenes, rechte- und lizenzgesteuertes Modul bereitstellen. +Ergebnis: Vertragsdeckungsbeiträge sind ohne Belegzugriff auswertbar. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Controlling/Analytics", Kommentar „Vertragsauswertung" mit der Registrierung von `ContractEvaluation2` - Begründung: das Modul ist dort rechte- und lizenzgesteuert registriert. + - [SEKUNDÄR] `src/backend/Centron.BL/Statistics/ContractStatistics/` - Begründung: die Auswertungslogik. +Prüfidee: Die Auswertung muss für einen Vertrag Erlöse und Aufwände gegenüberstellen. +Tracelinks: SyRS-170, StRS-008 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die Namensziffer weist auf eine abgelöste Vorgängerfassung hin, die im Zielsystem entfällt. +Status: belegt +``` + +``` +ID: SwRS-191 +Titel: Leasing- und Serviceangaben am Beleg +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: Ein Beleg enthält Leasing- oder Serviceanteile. +Fakt: Der Belegkern enthält `Receipts/LeasingAndService/`; `ForwardReceipt` enthält die Region `#region IReceiptWithLeasingAndService` (Zeile 2838); das Verwaltungsmodul liegt unter `Modules/Administration/SalesAndLeasing/` beziehungsweise `Administration/ServiceAndLeasing/`. +Aussage: Das System soll Leasing- und Serviceangaben als eigene Belegeigenschaft über eine Schnittstelle führen und sie beim Weiterführen übernehmen. +Ergebnis: Leasingkonditionen bleiben über die Belegkette erhalten. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „IReceiptWithLeasingAndService", Zeile 2838 - Begründung: die Übernahme ist an die Schnittstelle gebunden. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/LeasingAndService/`, `src/centron/Centron.WPF.UI/Modules/Administration/SalesAndLeasing/` - Begründung: Fachlogik und Verwaltungsoberfläche. +Prüfidee: Ein Angebot mit Leasingangabe muss diese im daraus erzeugten Auftrag tragen. +Tracelinks: SyRS-018, StRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-192 +Titel: CRM-Projekte mit eigener Nummernart +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: Ein Vertriebsprojekt wird angelegt. +Fakt: `NumberGroupEnum` führt den Wert `CRMProject = 24`; das Modul `ProjectsAppModuleController` ist unter dem Recht `RIGHT_CRMPROJEKTEUEBERSICHT` und der Lizenz `CRMProjects` registriert; die Einstellungsseite `CrmProjectSettingsController` ist in `GetSettingsWithoutModule()` enthalten; die Fachlogik liegt in `Projects/ProjectBL.cs`, die Entitäten in `Entities/ProjectArea`. +Aussage: Das System soll Vertriebsprojekte als eigenständige, nummerierte Objekte führen, denen Belege und Vorgänge zugeordnet werden. +Ergebnis: Ein Projekt bündelt alle zugehörigen Vorgänge unter einer Projektnummer. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs`, `CRMProject = 24` - Begründung: die eigene Nummernart belegt das Projekt als eigenständiges Objekt. + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Registrierung mit `UserRightsConst.RIGHT_CRMPROJEKTEUEBERSICHT` und `LicenseGuids.CRMProjects` - Begründung: Rechte- und Lizenzsteuerung. + - [SEKUNDÄR] `src/backend/Centron.BL/Projects/ProjectBL.cs` - Begründung: die Fachlogik. +Prüfidee: Ein neues CRM-Projekt muss eine Nummer aus dem Nummernkreis 24 erhalten. +Tracelinks: SyRS-093, StRS-001 +Konsolidierung: Kandidat: SwRS-028 — CRM-Projekte und Belegprojekt-Layouts tragen beide den Begriff „Projekt", bezeichnen aber verschiedene Gegenstände; die Abgrenzung ist im Zielsystem zu schärfen. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-193 +Titel: Lieferantenverträge am Account +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Einkauf +Vorbedingung: Mit einem Lieferanten besteht ein Vertrag. +Fakt: `Accounts/AccountContracts/` bildet die Lieferantenverträge ab; das Modul `AccountContractsAppModuleController` wird nur registriert, wenn `IsAccountManagementActive` gesetzt ist, das Recht `Purchase.Supplier.Contract.SHOW_CONTRACT` vorliegt und die Lizenz `SupplierContracts` oder `Centron` besteht; die Einstellungsseite `AccountContractKindsSettingsController` pflegt die Vertragsarten; die REST-Ressource ist `ContractsController`. +Aussage: Das System soll Verträge auf der Beschaffungsseite am Account führen, sie über eigene Vertragsarten klassifizieren und ihre Verfügbarkeit an den aktivierten Account-Stamm binden. +Ergebnis: Beschaffungsverträge sind unabhängig von Kundenverträgen auswertbar. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Adressen/CRM", Registrierung `AccountContractsAppModuleController` mit `IsAccountManagementActive` und `SHOW_CONTRACT` - Begründung: die dreifache Bedingung ist die durchsetzende Stelle. + - [SEKUNDÄR] `src/backend/Centron.BL/Accounts/AccountContracts/` - Begründung: die Fachlogik. +Prüfidee: Bei nicht aktiviertem Account-Stamm darf das Modul „Lieferanten-Verträge" nicht erscheinen. +Tracelinks: SyRS-002, StRS-024 +Konsolidierung: Kandidat: SwRS-030 — Kunden- und Lieferantenverträge sind zwei getrennte Vertragsmodelle. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-194 +Titel: Segmentierungsmerkmale des Kundenstamms +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Marketing +Vorbedingung: Kunden werden segmentiert. +Fakt: `CustomerArea` enthält `BusinessLineBL` (Geschäftsbereiche), `InterestBL` (Interessen), `ProductBL`, `ContactActivityBL`, `ContactDepartmentBL`; `Accounts` ergänzt `AccountTypeBL`, `CustomerToBranchBL`, `SupplierToBranchBL`, `CustomerCostCenterBL` und `ExtendedFilters`; `Entities/RelationshipArea` hält die Beziehungsstrukturen. +Aussage: Das System soll Geschäftspartner über Geschäftsbereiche, Interessen, Produktbezüge, Kontotypen und Filialzuordnungen segmentieren und diese Merkmale als Filter für Kampagnen und Auswertungen bereitstellen. +Ergebnis: Zielgruppen sind ohne Freitextsuche bildbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/CustomerArea/BusinessLineBL.cs`, `InterestBL.cs`, `ProductBL.cs` - Begründung: die Merkmale sind als eigene Fachlogikbausteine geführt. + - [SEKUNDÄR] `src/backend/Centron.BL/Accounts/ExtendedFilters/`, `src/backend/Centron.BL/Accounts/CustomerToBranchBL.cs` - Begründung: Filterung und Filialzuordnung. +Prüfidee: Eine Kampagne auf einen Geschäftsbereich muss genau die Kunden dieses Bereichs auswählen. +Tracelinks: SyRS-173, StRS-057 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-195 +Titel: Ticketprozesse und Ticketprojekte als getrennte Bündelungen +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Mehrere Tickets gehören zusammen. +Fakt: `Sales/Support/TicketProcess/` bildet mehrstufige Ticketprozesse ab, das Modul `TicketProcessTemplates` pflegt die Vorlagen; davon getrennt bestehen `TicketProjects/TicketProjectBL.cs`, `Sales/Support/TicketProjectDependencyBL.cs` und `TicketProjectSettingsBL.cs` sowie das Modul „Projektverwaltung" in der Region „Helpdesk". +Aussage: Das System soll wiederkehrende Ticketfolgen als Prozessvorlage und inhaltlich zusammengehörige Tickets als Ticketprojekt mit Abhängigkeiten führen. +Ergebnis: Sowohl Abläufe als auch Vorhaben sind über mehrere Tickets hinweg steuerbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/TicketProcess/` und `src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs` - Begründung: zwei getrennte Bündelungskonzepte im Code. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/TicketProjectDependencyBL.cs` - Begründung: belegt Abhängigkeiten zwischen Tickets eines Projekts. +Prüfidee: Ein Ticket mit unerfüllter Abhängigkeit darf nicht als bearbeitbar gelten. +Tracelinks: SyRS-058, StRS-020 +Konsolidierung: Kandidat: SwRS-195 selbst — Ticketprozess, Ticketprojekt und Taskmanagement bündeln Tickets in drei getrennten Konzepten. +Übernahmewürdigkeit: übernehmen - im Zielsystem auf zwei Konzepte (Ablauf und Vorhaben) zu reduzieren. +Status: belegt +``` + +``` +ID: SwRS-196 +Titel: Anbindung fremder Ticketsysteme +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Partner +Vorbedingung: Ein fremdes Ticketsystem ist konfiguriert. +Fakt: `ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs` hält die Konfiguration; die Entitäten liegen in `Entities/ExternalHelpdesk`; ergänzend bestehen `DataExchange/TanssInterfaces/` und die docBee-Endpunkte `DocBeeTicketTemplatesController` und `DocBeeTicketTimersController`. +Aussage: Das System soll Tickets und Ticketzeiten mit fremden Servicesystemen austauschen und je Fremdsystem eine eigene Konfiguration führen. +Ergebnis: Tickets aus Partnersystemen erscheinen im eigenen Servicebetrieb. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs` - Begründung: die Konfiguration ist eigenständig geführt. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/v1/DataExchange/DocBeeTicketTemplatesController.cs`, `DocBeeTicketTimersController.cs` - Begründung: eigene Endpunkte für Ticketvorlagen und -zeiten eines Fremdsystems. +Prüfidee: Eine im Fremdsystem erfasste Ticketzeit muss über den zugehörigen Endpunkt abrufbar sein. +Tracelinks: SyRS-175, StRS-062 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-197 +Titel: Artikelimport mit eigenem Modul und eigener Fachlogik +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Artikelverwaltung +Vorbedingung: Eine Artikeldatei liegt vor. +Fakt: `Warehousing/ArticleManagement/ArticleImportBL.cs` bildet den Import ab; das Modul `ArticleImport` ist in der Region „Logistik" registriert; ergänzend bestehen die Module `SpecialArticleImport`, `SpecialArticleToContractImport` und `ProjectPriceImport` sowie der allgemeine Importzweig `DataExchange/Import/` und `Entities/Import`. +Aussage: Das System soll den Import von Artikeln, Sonderpreisen, Vertragsartikeln und Projektpreisen über jeweils eigene, rechtegesteuerte Module abwickeln. +Ergebnis: Importe sind je Datenart getrennt steuerbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs` - Begründung: die Importlogik ist eigenständig. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Sales/SpecialArticleImport/`, `Sales/SpecialArticleToContractImport/`, `Modules/ProjectPriceImport/`, `Modules/Warehousing/ArticleImport/` - Begründung: vier getrennte Importmodule. +Prüfidee: Ein Artikelimport darf keine Sonderpreise anlegen. +Tracelinks: SyRS-176, SyRS-033 +Konsolidierung: Kandidat: SwRS-197 selbst — vier Importmodule mit gleichartigem Ablauf (Datei lesen, prüfen, übernehmen). +Übernahmewürdigkeit: übernehmen - im Zielsystem mit gemeinsamem Importrahmen. +Status: belegt +``` + +``` +ID: SwRS-198 +Titel: Kostenstellen und Kostenträger als eigene Stammdaten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Controlling +Vorbedingung: Kostenrechnung wird geführt. +Fakt: Das Schema führt `Kostenstellen` und `Kostentraeger`; `Warehousing/CostCenterBL.cs` und `CostObjectBL.cs` verwalten sie; `Accounts/CustomerCostCenterBL.cs` ordnet Kostenstellen Kunden zu; das Modul `PayersAndCostCenter` ist in der Region „Stammdaten" registriert. +Aussage: Das System soll Kostenstellen und Kostenträger als eigene Stammdaten führen, sie Kunden zuordnen und in Belegen mitführen. +Ergebnis: Belegwerte sind kostenrechnerisch zuordenbar. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `Kostenstellen`, `Kostentraeger` - Begründung: die Stammdaten sind persistiert. + - [PRIMÄR] `src/backend/Centron.BL/Accounts/CustomerCostCenterBL.cs` - Begründung: belegt die kundenbezogene Zuordnung. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/` - Begründung: das Verwaltungsmodul. +Prüfidee: Ein Beleg für einen Kunden mit hinterlegter Kostenstelle muss diese vorbelegen. +Tracelinks: SyRS-080, StRS-027 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-199 +Titel: Filialkalkulation als eigenes Modul +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Controlling +Vorbedingung: Mehrere Filialen bestehen. +Fakt: In der Region „Buchhaltung/Finanzen" ist ein Modul mit dem Kommentar „Kalkulation pro Filiale" registriert; die zugehörige Oberfläche liegt unter `Modules/DataExchange/SupplierOrderPerBranch/`, die Fachlogik in `Purchasing/SupplierOrderPerBranchBL.cs`; ergänzend besteht `Administration/Company/BranchRevenueAndExpenseAccountBL.cs`. +Aussage: Das System soll Erlöse und Aufwände je Filiale kalkulierbar machen und dafür ein eigenes, rechtegesteuertes Modul bereitstellen. +Ergebnis: Filialergebnisse sind getrennt auswertbar. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Buchhaltung/Finanzen", Kommentar „Kalkulation pro Filiale" - Begründung: das Modul ist dort registriert. + - [SEKUNDÄR] `src/backend/Centron.BL/Administration/Company/BranchRevenueAndExpenseAccountBL.cs` - Begründung: filialbezogene Erlös- und Aufwandskonten. +Prüfidee: Die Kalkulation muss je Filiale ein eigenes Ergebnis ausweisen. +Tracelinks: SyRS-076, SyRS-080 +Konsolidierung: Kandidat: SwRS-076 — Filialbestellung und Filialkalkulation nutzen dieselbe Oberfläche. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-200 +Titel: Gutscheinverwaltung mit eigenen Artikeln +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: Gutscheine werden ausgegeben. +Fakt: `VoucherManagement/VoucherManagementBL.cs` bildet die Gutscheinverwaltung ab; `ArticleBL.GetVoucherArticleList()` (Zeile 235) liefert die als Gutschein gekennzeichneten Artikel; die Entitäten liegen in `Entities/VoucherManagement`. +Aussage: Das System soll Gutscheine über eigens gekennzeichnete Artikel ausgeben und ihren Einlösungsstand verwalten. +Ergebnis: Ausgegebene und eingelöste Gutscheine sind unterscheidbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `GetVoucherArticleList`, Zeile 235 - Begründung: die Kennzeichnung der Gutscheinartikel wird dort aufgelöst. + - [SEKUNDÄR] `src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs`, `src/backend/Centron.Entities/Entities/VoucherManagement/` - Begründung: Fachlogik und Datenstruktur. +Prüfidee: Ein eingelöster Gutschein darf nicht erneut einlösbar sein. +Tracelinks: SyRS-064, StRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-201 +Titel: docuFORM-Anbindung als eigenes Projekt +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Zählerstände werden automatisch bezogen. +Fakt: `Centron.Api.docuFORM` ist ein eigenes Projekt auf oberster Ebene der Projektmappe; `DataExchange/DocuForm/` bindet es an; die Einstellungsseite `DocuFormApiSettingsController` ist sowohl in `GetSettingsWithoutModule()` als auch als REST-Ressource `DocuFormApiSettingsController` vorhanden; die Oberfläche liegt unter `Modules/DataExchange/DocuForm/Settings/`. +Aussage: Das System soll Zählerstände von Ausgabegeräten über die docuFORM-Schnittstelle beziehen und die Zugangsdaten sowohl im Rich-Client als auch über die REST-Schnittstelle pflegbar machen. +Ergebnis: Zählerstände für die Klickabrechnung entstehen ohne manuelle Erfassung. +Belege: + - [PRIMÄR] `Centron.Api.docuFORM/Centron.Api.docuFORM.csproj` - Begründung: eigenes Projekt für die Anbindung. + - [PRIMÄR] `src/webservice/Centron.Controllers/Controllers/v1/DataExchange/DocuFormApiSettingsController.cs` - Begründung: die Konfiguration ist auch über die REST-Schnittstelle pflegbar. + - [SEKUNDÄR] `src/backend/Centron.BL/DataExchange/DocuForm/` - Begründung: die Anbindung im Backend. +Prüfidee: Ein über docuFORM bezogener Zählerstand muss am Stammblatt erscheinen. +Tracelinks: StRS-010, SyRS-175 +Konsolidierung: Kandidat: SwRS-140 — Zählerstände entstehen sowohl manuell am Stammblatt als auch automatisch über docuFORM. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-202 +Titel: Kategorien virtueller Objekte für Checklisten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Eine Checkliste bezieht sich auf ein nicht physisches Objekt. +Fakt: `ItPlanner/ChecklistVirtualObjectCategoryBL.cs` verwaltet Kategorien virtueller Objekte; `CheckListArea/CentronChecklistBL.cs` und `UpdateChecklistBL.cs` bilden die Checklisten ab; die Auswahl in der Weboberfläche erfolgt über `ChecklistTemplateTreeSelection.razor`. +Aussage: Das System soll Checklisten auch auf nicht physische Objekte — etwa geplante IT-Strukturen — beziehen und diese über eigene Kategorien ordnen. +Ergebnis: Planungsgegenstände sind wie Geräte prüfbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs` - Begründung: die Kategorien virtueller Objekte sind eigens implementiert. + - [SEKUNDÄR] `src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs` - Begründung: die Checklistenlogik. +Prüfidee: Eine Checkliste zu einem virtuellen Objekt muss dessen Kategorie tragen. +Tracelinks: SyRS-054, StRS-019 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-203 +Titel: Anwendungseinstellungen als typisierte Schlüsselwerte +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Eine Einstellung wird gelesen. +Fakt: `AppSettingsBL.GetSettings(ApplicationSettingID …, ApplicationSettingID …)` liest mehrere Einstellungen in einem Aufruf; das Ergebnis bietet typisierte Zugriffe (`settings.GetBool(ApplicationSettingID.IsHelpdeskShortDescriptionPrefixActivated, false)`, `settings.GetString(ApplicationSettingID.HelpdeskShortDescriptionPrefix, string.Empty)`) jeweils mit Vorgabewert; `AppSettingsGroupBL` bündelt zusammengehörige Einstellungen (etwa `GetSurveySettings()`); die Werte liegen in der Tabelle `ApplicationSettings`. +Aussage: Das System soll Anwendungseinstellungen über eine Aufzählung von Schlüsseln typisiert mit Vorgabewert lesen und zusammengehörige Einstellungen als Gruppe bereitstellen. +Ergebnis: Fehlende Einstellungen führen zum Vorgabewert statt zu einem Fehler. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `AddShortDescriptionPrefix` mit `new AppSettingsBL(this.Session).GetSettings(ApplicationSettingID.IsHelpdeskShortDescriptionPrefixActivated, ApplicationSettingID.HelpdeskShortDescriptionPrefix)` und den typisierten Zugriffen mit Vorgabewert - Begründung: zeigt Aufruf, Typisierung und Vorgabewert. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `_appSettingsGroupBL.GetSurveySettings()` - Begründung: belegt die Gruppierung zusammengehöriger Einstellungen. + - [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `ApplicationSettings` - Begründung: die Ablage der Werte. + - [KONTEXT] `docs/guides/development/settings-management.md` - Begründung: beschreibt die Einstellungsverwaltung. +Prüfidee: Eine nicht gepflegte Einstellung muss den im Aufruf angegebenen Vorgabewert liefern. +Tracelinks: SyRS-053, SyRS-056 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-204 +Titel: Terminanfragen als eigener Vorgang +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Ein Termin ist mit dem Kunden abzustimmen. +Fakt: `AppointmentRequests/AppointmentRequestBL.cs` bildet die Terminanfrage ab; die Entitäten liegen in `Entities/AppointmentRequests`; die Einstellungsseite `AppointmentsForTicketsSettingsController` verknüpft Termine mit Tickets. +Aussage: Das System soll Terminvorschläge an den Kunden als eigenständigen Vorgang mit Zustand führen, getrennt vom bestätigten Kalendertermin. +Ergebnis: Offene und bestätigte Termine sind unterscheidbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/AppointmentRequests/AppointmentRequestBL.cs` und `src/backend/Centron.Entities/Entities/AppointmentRequests/` - Begründung: die Terminanfrage ist als eigene Entität mit eigener Fachlogik geführt. +Prüfidee: Eine unbestätigte Terminanfrage darf im Kalender nicht als fester Termin erscheinen. +Tracelinks: SyRS-114, StRS-042 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-205 +Titel: Interne Kurznachrichten +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Benutzer +Vorbedingung: Zwei Benutzer sind angemeldet. +Fakt: `Chats/ChatBL.cs` bildet die Kurznachrichten ab; die Entitäten liegen in `Entities/Chats`; die Zustellung in der Weboberfläche erfolgt über den Benachrichtigungsmechanismus (`NotificationsHubHelper`). +Aussage: Das System soll interne Kurznachrichten zwischen Benutzern führen und deren Zustellung über den Benachrichtigungsmechanismus abwickeln. +Ergebnis: Kurze Abstimmungen sind ohne E-Mail möglich. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Chats/ChatBL.cs` und `src/backend/Centron.Entities/Entities/Chats/` - Begründung: Fachlogik und Datenstruktur sind vorhanden. +Prüfidee: Eine gesendete Nachricht muss beim Empfänger als Benachrichtigung erscheinen. +Tracelinks: SyRS-128 +Konsolidierung: Kandidat: SwRS-128 — Chats und Benachrichtigungen überschneiden sich in der Zustellung. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-206 +Titel: Freie Verschlagwortung von Objekten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Alle Benutzer +Vorbedingung: Ein Objekt soll wiederauffindbar gemacht werden. +Fakt: `Tags/TagsBL.cs` verwaltet Schlagworte; die Entitäten liegen in `Entities/Tags`; ergänzend besteht `ReportEngine/ReportDataQueryTagBL.cs` für Schlagworte an Reportabfragen. +Aussage: Das System soll Objekte frei verschlagworten und die Schlagworte als Suchkriterium bereitstellen. +Ergebnis: Objekte sind unabhängig von ihrer Objektart über Schlagworte auffindbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Tags/TagsBL.cs` und `src/backend/Centron.Entities/Entities/Tags/` - Begründung: die Verschlagwortung ist eigenständig geführt. + - [SEKUNDÄR] `src/backend/Centron.BL/ReportEngine/ReportDataQueryTagBL.cs` - Begründung: eine zweite, reportbezogene Verschlagwortung. +Prüfidee: Ein verschlagwortetes Ticket muss über sein Schlagwort auffindbar sein. +Tracelinks: SyRS-171, SyRS-023 +Konsolidierung: Kandidat: SwRS-206 selbst — allgemeine und reportbezogene Verschlagwortung sind getrennt implementiert. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-207 +Titel: Kurzlinks mit hinterlegter Aktion +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Kunde, Mitarbeiter +Vorbedingung: Ein Link wird versandt. +Fakt: `Urls/SimpleUrlBL.cs` und `SimpleUrlWebServiceBL.cs` erzeugen und auflösen Kurz-URLs; `WebLinks` definiert die Schnittstelle `IWebLinkActionHandler` mit den Implementierungen `WebLinkActionAccountActivityHandler` und `WebLinkActionReminderHandler` sowie `WebLinkBL`. +Aussage: Das System soll versandte Links auf eine kurze, auflösbare Adresse abbilden und je Link eine auszuführende Aktion hinterlegen, die über austauschbare Behandlungsroutinen ausgeführt wird. +Ergebnis: Ein Klick im Kundenmail löst die vorgesehene Aktion aus. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/WebLinks/IWebLinkActionHandler.cs` mit den beiden Implementierungen - Begründung: die Schnittstelle ist die Austauschstelle der Aktionen. + - [SEKUNDÄR] `src/backend/Centron.BL/Urls/SimpleUrlBL.cs` - Begründung: die Kurz-URL-Auflösung. +Prüfidee: Ein Kurzlink mit Erinnerungsaktion muss beim Aufruf die Erinnerung erzeugen. +Tracelinks: SyRS-123, SyRS-112 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Gültigkeitsdauer und Einmaligkeit sind im Zielsystem festzulegen. +Status: belegt +``` + +``` +ID: SwRS-208 +Titel: Strukturierte Kundendokumentation +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Eine Kundenumgebung wird dokumentiert. +Fakt: `DocumentationArea/DocumentationBL.cs` bildet die Dokumentation ab, die Entitäten liegen in `Entities/DocumentationArea`; die Rechte stehen unter `UserRightsConst.Documentation` mit einer Unterklasse `Categories` (Zeilen 1847-1876); ergänzend besteht `Sales/Receipts/DocumentationWizardArea/`. +Aussage: Das System soll Kundendokumentation in Kategorien strukturiert führen und den Zugriff je Kategorie über eigene Rechte steuern. +Ergebnis: Dokumentation ist gegliedert und selektiv freigebbar. +Belege: + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `Documentation` mit Unterklasse `Categories`, Zeilen 1847-1876 - Begründung: die Rechtestruktur belegt die kategoriebezogene Steuerung. + - [SEKUNDÄR] `src/backend/Centron.BL/DocumentationArea/DocumentationBL.cs` - Begründung: die Fachlogik. +Prüfidee: Eine Kategorie ohne Recht darf in der Dokumentationsübersicht nicht erscheinen. +Tracelinks: SyRS-111, StRS-039 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-209 +Titel: Social-Media-Anbindung mit eigenen Datenstrukturen +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Marketing +Vorbedingung: Ein sozialer Netzwerkzugang ist konfiguriert. +Fakt: Das Schema führt `SocialMediaStream`, `SocialMediaStreamAccount`, `SocialMediaAction`, `SocialMediaComment` und `SocialMediaLike`; `SocialMedia/SocialMediaBL.cs` und `SocialMedia/SocialNetworks/` bilden die Anbindung ab; die Entitäten liegen in `Entities/SocialMedia`. +Aussage: Das System soll Beiträge, Kommentare und Reaktionen sozialer Netzwerke je Konto in eigenen Datenstrukturen führen. +Ergebnis: Reaktionen auf Beiträge sind im System auswertbar. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `SocialMediaStream`, `SocialMediaStreamAccount`, `SocialMediaAction`, `SocialMediaComment`, `SocialMediaLike` - Begründung: die Datenstrukturen sind im Schema durchgesetzt. + - [SEKUNDÄR] `src/backend/Centron.BL/SocialMedia/SocialNetworks/` - Begründung: netzwerkspezifische Anbindungen. +Prüfidee: Ein Kommentar zu einem Beitrag muss diesem Beitrag zugeordnet gespeichert werden. +Tracelinks: SyRS-175, StRS-057 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - die Tabellen bestehen, im aktuellen Modulkatalog ist jedoch kein Social-Media-Modul registriert; die fachliche Weiterverwendung ist zu prüfen. +Status: belegt +``` + +``` +ID: SwRS-210 +Titel: Zuordnung von Schulungsvideos zu Objekten +Ebene: SwRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Alle Benutzer +Vorbedingung: Schulungsvideos sind hinterlegt. +Fakt: `VideoPortal/VideoPortalAssignmentBL.cs` verwaltet die Zuordnung; die Entitäten liegen in `Entities/VideoPortal`; das Recht `UserRightsConst.VideoPortal` (Zeile 2786) steuert den Zugriff. +Aussage: Das System soll Schulungsvideos einzelnen Programmbereichen zuordnen und den Zugriff an ein eigenes Recht binden. +Ergebnis: Anwender finden Hilfevideos im jeweiligen Zusammenhang. +Belege: + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `VideoPortal`, Zeile 2786 - Begründung: eigenes Recht für den Videozugriff. + - [SEKUNDÄR] `src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs` - Begründung: die Zuordnungslogik. +Prüfidee: Ohne das Recht darf kein Video erreichbar sein. +Tracelinks: SyRS-170 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-211 +Titel: Gemeinsame Steuerelement- und Kernbibliotheken +Ebene: SwRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Wiederverwendbarkeit) +Akteur: Entwicklung +Vorbedingung: Ein Oberflächenbaustein wird benötigt. +Fakt: `src/shared` enthält `Centron.Core` (Kernfunktionen, u. a. `Centron.Core.Utils.DateTimeUtils`, `Centron.Core.Extensions`), `Centron.Controls` (Steuerelemente, u. a. `Centron.Controls.Shared`) und `Centron.Controls.Preview`; die Testprojekte `tests/shared/Centron.Tests.Core` und `Centron.Tests.Controls` prüfen sie; `Centron.Common` ergänzt Hilfsmittel (`Calculations`, `Extensions`, `Files`, `Format`, `IO`, `IniParser`, `Logging`, `Network`, `TextCoding`, `Ui`, `UtilClasses`). +Aussage: Das System soll wiederverwendbare Steuerelemente, Kernfunktionen und Hilfsmittel in gemeinsamen Bibliotheken bündeln, die von Rich-Client, Webanwendung und Backend gleichermaßen genutzt werden. +Ergebnis: Gleichartige Funktionen sind nicht mehrfach implementiert. +Belege: + - [PRIMÄR] `src/shared/Centron.Core/`, `src/shared/Centron.Controls/`, `src/shared/Centron.Controls.Preview/` - Begründung: die gemeinsamen Bibliotheken bestehen als eigene Projekte. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, Verwendung von `Centron.Controls.Shared` und `Centron.Core.Extensions` im Backend - Begründung: belegt die schichtübergreifende Nutzung. +Prüfidee: Eine Datumsformatierung muss in Rich-Client und Webanwendung dasselbe Ergebnis liefern. +Tracelinks: SwRS-001 +Konsolidierung: Kandidat: SwRS-211 selbst — `Centron.Core` und `Centron.Common` bündeln beide allgemeine Hilfsmittel. +Übernahmewürdigkeit: übernehmen - im Zielsystem sind die beiden Hilfsbibliotheken zusammenzuführen. +Status: belegt +``` + +``` +ID: SwRS-212 +Titel: Mobile Datenversorgung als eigener Baustein +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Ein mobiler Client greift zu. +Fakt: `Mobile/MobileBL.cs` bündelt die Datenversorgung mobiler Clients; die Entitäten liegen in `Entities/Mobile`; die Anmeldung mobiler Anwendungen erfolgt über `ApplicationKind` und die JWT-Endpunkte. +Aussage: Das System soll mobile Clients über einen eigenen Baustein mit den für sie benötigten Daten versorgen. +Ergebnis: Mobile Anwendungen erhalten eine auf sie zugeschnittene Datensicht. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Mobile/MobileBL.cs` und `src/backend/Centron.Entities/Entities/Mobile/` - Begründung: der Baustein und seine Datenstrukturen bestehen eigenständig. +Prüfidee: Ein mobiler Abruf darf nur die für den mobilen Einsatz vorgesehenen Felder liefern. +Tracelinks: SyRS-173, SyRS-102 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SwRS-213 +Titel: Externe Werkzeuge und Fernwartung +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Ein externes Werkzeug ist konfiguriert. +Fakt: `ExternalToolsBL/ExternalToolBL.cs` verwaltet externe Werkzeuge, die Entitäten liegen in `Entities/ExternalTools`; die Einstellungsseite `ExternalToolSettingsController` ist registriert, das Oberflächenmodul liegt unter `Modules/Administration/ExternalTools/` und `Modules/ExternalTool/`; `Sales/Support/ExternalToolsReplacementBL.cs` ersetzt Platzhalter im Aufrufbefehl mit Ticketdaten; `MyDay/Supremo.cs` und die Rechtezweige `SupRemo` (Zeile 2710) und `DirectNow` (Zeile 2727) bilden Fernwartungswerkzeuge ab. +Aussage: Das System soll externe Werkzeuge mit parametrisiertem Aufrufbefehl hinterlegen, die Platzhalter aus dem aktuellen Vorgang füllen und Fernwartungswerkzeuge über eigene Rechte steuern. +Ergebnis: Der Techniker startet Werkzeuge mit Vorgangsbezug ohne manuelle Eingabe. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/ExternalToolsReplacementBL.cs` - Begründung: die Platzhalterersetzung mit Vorgangsdaten ist dort implementiert. + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, Klassen `SupRemo` (Zeile 2710) und `DirectNow` (Zeile 2727) - Begründung: eigene Rechte je Fernwartungswerkzeug. + - [SEKUNDÄR] `src/backend/Centron.BL/ExternalToolsBL/ExternalToolBL.cs` - Begründung: die Verwaltung der Werkzeuge. +Prüfidee: Ein Werkzeugaufruf aus einem Ticket muss dessen Ticketnummer im Aufrufbefehl enthalten. +Tracelinks: SwRS-053, SyRS-057 +Konsolidierung: Kandidat: SwRS-053 — die Platzhalterersetzung ist ein weiterer Ort derselben Aufgabe. +Übernahmewürdigkeit: übernehmen - im Web-/SaaS-Zielsystem ist der Start lokaler Programme neu zu lösen. +Status: belegt +``` + +``` +ID: SwRS-214 +Titel: Fremdsystemkonnektoren mit eigener Verbindungslogik +Ebene: SwRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Fremdsystem ist angebunden. +Fakt: `RiverDivo` enthält `RiverConnectionBL`, `RiverDivoBL`, `SimpleRiverCentronClient` und `RBContractArticleRefInfo` und besitzt eine eigene Einstellungsseite `RiverSuiteWebServiceSettingsController` sowie den Rechtezweig `Riversuite` (als überholt gekennzeichnet) und `RiverSuiteCommonRights`; `CPra` enthält `CPraConfigurationSettingsBL` und `CPraConnectorBL`; `TradePool` enthält `TradePoolBL` und `Core`; `DataExchange/TelekomDive/` besitzt den Endpunkt `TelekomDiveController` und ein eigenes Oberflächenmodul; `Gateway/CustomGatewayBL.cs` und das Projekt `Centron.Gateway` bilden eine Vermittlungsschicht. +Aussage: Das System soll je Fremdsystem einen eigenen Konnektor mit eigener Verbindungs- und Konfigurationslogik führen und diese über eine gemeinsame Vermittlungsschicht anbinden. +Ergebnis: Der Ausfall eines Fremdsystems beeinträchtigt die übrigen nicht. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs`, `src/backend/Centron.BL/CPra/CPraConnectorBL.cs`, `src/backend/Centron.BL/TradePool/TradePoolBL.cs` - Begründung: drei eigenständige Konnektoren mit eigener Verbindungslogik. + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `Riversuite` mit `[Obsolete]`-Kennzeichnung, Zeile 2754 - Begründung: die Anbindung ist im Rechtebaum als überholt markiert. + - [SEKUNDÄR] `src/backend/Centron.BL/Gateway/CustomGatewayBL.cs`, `src/backend/Centron.Gateway/` - Begründung: die Vermittlungsschicht. +Prüfidee: Ein nicht erreichbares Fremdsystem darf nur den zugehörigen Konnektor in einen Fehlerzustand versetzen. +Tracelinks: SyRS-175, StRS-062 +Konsolidierung: Kandidat: SwRS-214 selbst — fünf Konnektoren ohne gemeinsame Konnektorschnittstelle. +Übernahmewürdigkeit: übernehmen - die als überholt gekennzeichnete RiverSuite-Anbindung entfällt im Zielsystem. +Status: belegt +``` + +``` +ID: SwRS-215 +Titel: Dashboard und Startbereich als verdichtete Einstiegssicht +Ebene: SwRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Alle Benutzer +Vorbedingung: Der Benutzer meldet sich an. +Fakt: `MyCentron/Dashboard/` im Backend und die Module `Dashboard`, `CentronInspectors`, `TodoList`, `MyDay` bilden den Einstiegsbereich des Rich-Clients; `Start/StartBL.cs` und `MyCentron/LatestUsedCentronObjectBL.cs` liefern zuletzt verwendete Objekte, `MyCentron/QuickNotes/` und `MyCentron/Schedulings/` ergänzen Notizen und Planungen; in der Webanwendung bestehen `ServiceBoard/Dashboard/Dashboard.razor`, `DashboardMyDayList`, `DashboardMyTicketStats`, `DashboardMyTimerecordStats` und `DashboardTicketlist`. +Aussage: Das System soll dem Benutzer nach der Anmeldung eine verdichtete Einstiegssicht mit eigenen Kennzahlen, offenen Aufgaben, Tagesplanung und zuletzt verwendeten Objekten bieten. +Ergebnis: Der Benutzer erkennt seinen Arbeitsvorrat ohne Navigation. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus/ServiceBoard/Dashboard/DashboardMyTicketStats.razor`, `DashboardMyTimerecordStats.razor`, `DashboardMyDayList.razor` - Begründung: die Kennzahlenbausteine der Einstiegssicht. + - [SEKUNDÄR] `src/backend/Centron.BL/MyCentron/LatestUsedCentronObjectBL.cs`, `src/backend/Centron.BL/Start/StartBL.cs` - Begründung: zuletzt verwendete Objekte und Startbereich. +Prüfidee: Nach dem Öffnen eines Belegs muss dieser in der Liste zuletzt verwendeter Objekte erscheinen. +Tracelinks: SyRS-170, StRS-046 +Konsolidierung: Kandidat: SwRS-215 selbst — Rich-Client und Weboberfläche führen zwei getrennte Dashboard-Implementierungen. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/SyRS.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/SyRS.md new file mode 100644 index 00000000..e6d344f4 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/SyRS.md @@ -0,0 +1,2807 @@ +# SyRS — System Requirements Specification + +**System:** c-entron ERP-Suite +**Norm:** ISO/IEC/IEEE 29148:2018, Abschnitt System Requirements Specification +**Ebene:** Systemverhalten, Schnittstellen, Performance- und Sicherheitsanforderungen +**Hinweis:** Nicht-funktionale Anforderungen tragen die ISO-25010-Zuordnung ausschließlich im Feld `Qualitätsmerkmal`. + +--- + +## 1. Geschäftspartner und Stammdaten + +``` +ID: SyRS-001 +Titel: Rechteprüfung bei Anlage und Änderung von Geschäftspartnern +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Der Benutzer ist angemeldet. +Fakt: `AccountBL` prüft über `AppRightsBL.CheckRightsFromUser` die Rechte `CREATE_CUSTOMER`, `EDIT_CUSTOMER`, `DELETE_CUSTOMER`, `SEARCH_CUSTOMER`, `UNLOCK_CUSTOMER` und bricht mit „Fehlende Rechte um Accounts zu erstellen" ab. +Aussage: Das System soll vor jeder Anlage, Änderung, Löschung, Suche und Entsperrung eines Geschäftspartners das jeweils zugeordnete Einzelrecht prüfen und die Aktion andernfalls mit begründeter Meldung abweisen. +Ergebnis: Ohne das erforderliche Recht entsteht keine Änderung am Geschäftspartnerstamm. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Accounts/AccountBL.cs`, Rechteprüfung über `new AppRightsBL(Session).CheckRightsFromUser(currentUserI3D, …)` mit anschließender Prüfung `checkRightsResult.Contains(CREATE_CUSTOMER) == false` - Begründung: die Prüfung ist die durchsetzende Stelle vor der Anlage. + - [KONTEXT] `docs/guides/development/check-userrights.md`, Codebeispiel „(from `AccountBL.cs`)" - Begründung: dokumentiert genau diese Prüfstelle. +Prüfidee: Anlageversuch ohne `CREATE_CUSTOMER` muss die Fehlermeldung liefern und darf keinen Datensatz erzeugen. +Tracelinks: StRS-001, StRS-031, SwRS-001 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Grundschutz der Stammdaten. +Status: belegt +``` + +``` +ID: SyRS-002 +Titel: Rollenzuordnung eines Geschäftspartners über Zuordnungstabellen +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Account existiert. +Fakt: Das Schema enthält `Accounts` sowie die Zuordnungstabellen `AccountCustomers`, `AccountSuppliers` und `AccountTypeToAccounts`; zusätzlich bestehen `AccountAddressContacts`, `AccountActivities`, `AccountDevices`. +Aussage: Das System soll die Rollen eines Geschäftspartners über eigene Zuordnungstabellen abbilden, sodass ein Partner gleichzeitig Kunde und Lieferant sein kann. +Ergebnis: Ein Account trägt eine oder mehrere Rollen ohne Datensatzdopplung. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `Accounts`, `AccountCustomers`, `AccountSuppliers`, `AccountTypeToAccounts` - Begründung: die Zuordnung ist als eigene Relation im Schema durchgesetzt. +Prüfidee: Ein Account mit Einträgen in `AccountCustomers` und `AccountSuppliers` muss in beiden Rollenlisten erscheinen. +Tracelinks: StRS-001, SwRS-002 +Konsolidierung: Kandidat: SwRS-002 — Alt-Tabellen `Kunden`/`Kreditor` halten dieselbe Information redundant. +Übernahmewürdigkeit: übernehmen - Zielstruktur. +Status: belegt +``` + +``` +ID: SyRS-003 +Titel: Mehrfachadressen und Ansprechpartner je Geschäftspartner +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Geschäftspartner ist angelegt. +Fakt: Das Schema führt `Anschrif` (Adressen), `Personen`/`AccountAddressContacts` (Ansprechpartner) und `Anrede`; die Entität `CustomerAsset.Address` löst eine fehlende `AddressI3D` über `Customer.Addresses.FirstOrDefault(f => f.DefaultCustomer == true)` auf. +Aussage: Das System soll je Geschäftspartner beliebig viele Adressen und Ansprechpartner führen und bei fehlender expliziter Angabe die als Standard markierte Adresse verwenden. +Ergebnis: Jeder Vorgang trägt eine eindeutig bestimmte Adresse. +Belege: + - [PRIMÄR] `src/backend/Centron.Entities/Entities/Sales/CustomerAssets/CustomerAsset.cs`, Eigenschaft `Address` mit Rückfall auf `DefaultCustomer == true` - Begründung: die Auflösungsregel ist im Entitätscode durchgesetzt. + - [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `Anschrif`, `Personen`, `AccountAddressContacts`, `Anrede` - Begründung: die Mehrfachstruktur ist persistiert. +Prüfidee: Ein Asset ohne gesetzte `AddressI3D` muss die Standardadresse des Kunden anzeigen. +Tracelinks: StRS-001, SwRS-003 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-004 +Titel: Kundenindividuelle Sonderpreise +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: Für einen Kunden sind Sonderpreise gepflegt. +Fakt: Es bestehen `Accounts/SpecialPrices/`, `Sales/Support/CustomerSpecialArticleBL.cs`, das Modul `SpecialArticleImport` sowie `ProductMatrixBL`; das Kundenportal bezieht seine Artikel laut `README.md` aus den „Sonderpreisen" des Kunden. +Aussage: Das System soll je Kunde artikelbezogene Sonderpreise führen und diese bei der Preisfindung in Belegen und im Kundenportal vorrangig vor dem Listenpreis anwenden. +Ergebnis: Der Beleg trägt den Sonderpreis, sofern einer gepflegt ist. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/CustomerSpecialArticleBL.cs` und `src/backend/Centron.BL/Accounts/SpecialPrices/` - Begründung: halten und liefern die kundenbezogenen Preise. + - [SEKUNDÄR] `README.md`, Abschnitt „Contributing / 1. WebCart": „The available articles come from the customers ‚Sonderpreise'" - Begründung: benennt die Preisquelle des Portals. +Prüfidee: Ein Artikel mit Sonderpreis muss im Beleg dieses Kunden den Sonderpreis tragen, bei einem anderen Kunden den Listenpreis. +Tracelinks: StRS-044, SyRS-011, SwRS-004 +Konsolidierung: Kandidat: SwRS-005 — Sonderpreise, Staffelpreise (`ArticleVolumePricesBL`), Aktionspreise (`ActionPriceBL`) und Produktmatrix sind vier getrennte Preisquellen. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-005 +Titel: Mehrstufige Preisquellen mit definierter Rangfolge +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Belegposition wird bepreist. +Fakt: Es existieren mindestens vier Preisquellen: `ActionPriceBL` (Aktionspreise), `ArticleVolumePricesBL` (Staffelpreise), Sonderpreise je Kunde und `ProductMatrixBL`; die Zusammenführung erfolgt in `ReceiptItemBL` und `ReceiptPriceHelperBL`. +Aussage: Das System soll die Preisquellen in einer festgelegten Rangfolge auswerten und den ermittelten Preis an der Belegposition festschreiben. [HYPOTHESE] Die konkrete Rangfolge zwischen Aktionspreis, Staffelpreis, Sonderpreis und Produktmatrix wurde in dieser Analyse nicht bis zur entscheidenden Bedingung in `ReceiptItemBL`/`ReceiptPriceHelperBL` verfolgt; zur Bestätigung fehlt die Auswertung der Preisermittlung Zeile für Zeile. +Ergebnis: Jede Position trägt einen nachvollziehbar ermittelten Preis. +Belege: + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptPriceHelperBL.cs`, `ReceiptItemBL.cs` - Begründung: die Preisermittlung ist dort gebündelt, die konkrete Rangfolge wurde in dieser Analyse nicht bis zur entscheidenden Bedingung verfolgt. + - [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/ActionPriceBL.cs`, `ArticleVolumePricesBL.cs` - Begründung: belegen die Existenz konkurrierender Preisquellen. + - [KONTEXT] `docs/reference/receipts/actionprice-system.md` - Begründung: beschreibt das Aktionspreissystem. +Prüfidee: Ein Artikel mit gleichzeitig gültigem Aktions-, Staffel- und Sonderpreis muss im Beleg genau einen dieser Preise tragen, und zwar denselben bei wiederholter Anlage. +Tracelinks: SyRS-004, SwRS-005 +Konsolidierung: Kandidat: SyRS-004 +Übernahmewürdigkeit: übernehmen - im Zielsystem mit ausdrücklich dokumentierter Rangfolge. +Status: HYPOTHESE +``` + +``` +ID: SyRS-006 +Titel: Steuersatzwechsel über verkettete Steuersätze +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Steuersatz hat ein Ablaufdatum und einen Folgesatz. +Fakt: `TaxBL.GetActiveVatThroughNextVats(int vatI3D, DateTime compareTo)` folgt der Kette `vat.NextTaxRate`, solange `vat.ExpirationDate <= compareTo`; `UpdateArticleVATs` bricht mit „Die Mehrwertsteuer muss eine Folge-Mehrwertsteuer haben." ab, wenn kein Folgesatz existiert. +Aussage: Das System soll Steuersätze als Kette mit Ablaufdatum und Folgesatz führen und zu einem gegebenen Stichtag den gültigen Satz ermitteln; ein Wechsel ohne hinterlegten Folgesatz ist abzuweisen. +Ergebnis: Jeder Beleg wird mit dem zum Belegdatum gültigen Steuersatz bewertet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `GetActiveVatThroughNextVats`, Zeilen 45-54 - Begründung: die Schleife über `NextTaxRate` ist die durchsetzende Stelle der Stichtagsermittlung. + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `UpdateArticleVATs`, Prüfung `if (newVat == null) return Result.AsError("Die Mehrwertsteuer muss eine Folge-Mehrwertsteuer haben.")` - Begründung: verhindert einen unvollständigen Steuersatzwechsel. +Prüfidee: Ein zum 31.12. auslaufender Steuersatz muss für ein Belegdatum im Folgejahr den Folgesatz liefern. +Tracelinks: StRS-005, SwRS-006 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - steuerrechtlich zwingend. +Status: belegt +``` + +``` +ID: SyRS-007 +Titel: Massenumstellung von Artikelsteuersätzen mit Preisoption +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Ein Steuersatzwechsel steht an. +Fakt: `TaxBL.UpdateArticleVATs(int vatI3D, AppUser currentUser, bool updateArticlePrices)` verarbeitet die betroffenen Artikel in Stapeln zu 2.000 (`articleI3DsWithOldTaxRate.Batch(2000)`), aktualisiert Warengruppen und Artikel über benannte Abfragen und schreibt je Stapel einen Artikelprotokolleintrag mit dem Text „Bruttopreise beibehalten" oder „Nettopreise beibehalten". +Aussage: Das System soll bei einem Steuersatzwechsel alle betroffenen Artikel und Warengruppen umstellen, dabei wahlweise Brutto- oder Nettopreise beibehalten und jede Umstellung im Artikelprotokoll festhalten. +Ergebnis: Alle Artikel tragen den neuen Steuersatz; die Preisentscheidung ist protokolliert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `UpdateArticleVATs`, Stapelverarbeitung `Batch(2000)` und Protokollparameter `Text = updateArticlePrices ? "Bruttopreise beibehalten" : "Nettopreise beibehalten"` - Begründung: Stapelgröße und Protokolltext sind dort festgelegt. +Prüfidee: Nach der Umstellung mit `updateArticlePrices = true` muss der Bruttopreis unverändert und der Nettopreis geändert sein; im Artikelprotokoll muss „Bruttopreise beibehalten" stehen. +Tracelinks: SyRS-006, StRS-051, SwRS-007 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-008 +Titel: Länderabhängige Steuersätze +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Beleg richtet sich an einen Empfänger im Ausland. +Fakt: `TaxBL.GetVATByCounty(Country country)` filtert Steuersätze über `f.Country == country`; `GetDefaultVat()` bevorzugt den Standardsatz des Standardlands (`f.Default && (f.Country?.Default ?? false)`); `GetDefaultVatForDeaktivatedVat(int countryI3D)` liefert den Ersatzsatz je Land. +Aussage: Das System soll Steuersätze länderbezogen führen und bei fehlender Zuordnung den Standardsatz des Standardlands verwenden. +Ergebnis: Der Beleg trägt den für das Empfängerland gültigen Steuersatz. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `GetVATByCounty`, `GetDefaultVat` und `GetDefaultVatForDeaktivatedVat` - Begründung: die Filterbedingungen setzen die Länderabhängigkeit durch. + - [SEKUNDÄR] `src/backend/Centron.BL/CountryArea/CountryBL.cs`, `FederalStateBL.cs`, Tabelle `Laenkenn` - Begründung: Länderstammdaten. +Prüfidee: Ein Beleg an einen Empfänger in der Schweiz muss einen der für die Schweiz gepflegten Steuersätze vorschlagen. +Tracelinks: SyRS-006, SwRS-008 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-009 +Titel: Warengruppenhierarchie mit Erlöskontozuordnung +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Warengruppen sind gepflegt. +Fakt: Das Schema führt `WAREN` (Hauptwarengruppe), `UNTERWAREN` (Untergruppe) sowie die Erlöskontotabellen `WarenFilialeErloeskonto`, `UnterwarenFilialeErloeskonto` und `ArtikelBranchErloeskonto`; `MaterialGroupBL` verwaltet die Gruppen. +Aussage: Das System soll Artikel über eine zweistufige Warengruppenhierarchie klassifizieren und je Warengruppe, Untergruppe, Artikel und Filiale ein Erlöskonto zuordnen. +Ergebnis: Für jede Belegposition ist ein Erlöskonto eindeutig bestimmbar. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `WAREN`, `UNTERWAREN`, `WarenFilialeErloeskonto`, `UnterwarenFilialeErloeskonto`, `ArtikelBranchErloeskonto` - Begründung: die Kontenzuordnung auf drei Ebenen ist im Schema durchgesetzt. + - [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/InventoryManagement/MaterialGroupBL.cs` - Begründung: verwaltet die Gruppen. +Prüfidee: Ein Artikel mit eigenem Filial-Erlöskonto muss dieses und nicht das Warengruppenkonto verwenden. +Tracelinks: StRS-027, SwRS-009 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 2. Belegverarbeitung + +``` +ID: SyRS-010 +Titel: Pflichtprüfungen beim Speichern eines Belegs +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg soll gespeichert werden. +Fakt: `ReceiptBL.SaveReceipt` weist den Vorgang ab, wenn das Belegdatum ungültig ist („Der Beleg hat kein gültiges Datum.") oder die Versionsnummer weder erste, aktuelle noch nächste Version ist („Der Beleg hat keine gültige Versionsnummer."); anschließend prüft es Barcodes, bereits verarbeitete Positionen und geänderte Mengen weitergeführter Positionen. +Aussage: Das System soll einen Beleg nur speichern, wenn Datum und Versionsnummer gültig sind, keine bereits weitergeführten Positionen entfernt und deren Mengen nicht verändert wurden. +Ergebnis: Gespeicherte Belege sind in sich konsistent und widersprechen nicht ihren Folgebelegen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Datums- und Versionsprüfung (Zeilen 3562-3578) - Begründung: die Prüfungen brechen den Speichervorgang tatsächlich ab. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CheckIfAllProcessedPositionsAreStillInTheReceipt` und `_receiptArticleBookingBL.CheckIfItemQuantitiesHaveChangedAlthoughTheItemsHaveBeenForwarded` - Begründung: verhindern das Entfernen und Ändern weitergeführter Positionen. +Prüfidee: Das Entfernen einer bereits in einen Lieferschein weitergeführten Auftragsposition muss beim Speichern abgewiesen werden. +Tracelinks: StRS-003, SwRS-010 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Datenintegrität der Belegkette. +Status: belegt +``` + +``` +ID: SyRS-011 +Titel: Automatische Positionsergänzung beim Speichern +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Beleg wird gespeichert. +Fakt: `SaveReceipt` ruft nacheinander `UpdatePositionListAddAndRemoveBalancePositions`, `CheckForFreightArticle`, `ApplyFreightArticleSetting`, `UpdateFreightAndInsurancePositions`, `UpdateCustomerDiscountItems`, `UpdateItemsInternalPositionOrder` und `UpdatePositionDisplayNumber` auf. +Aussage: Das System soll beim Speichern eines Belegs Saldo-, Fracht-, Versicherungs- und Kundenrabattpositionen automatisch ergänzen oder entfernen und die Positionsnummerierung neu vergeben. +Ergebnis: Der gespeicherte Beleg enthält alle rechnerisch erforderlichen Positionen in fortlaufender Nummerierung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Aufrufkette Zeilen 3634-3661 - Begründung: die Aufrufe verändern die Positionsliste tatsächlich. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/FreightArticleSettingBL.cs` - Begründung: liefert die Frachtartikelregel. +Prüfidee: Ein Beleg oberhalb der frachtfreien Grenze darf nach dem Speichern keine Frachtposition mehr enthalten. +Tracelinks: SyRS-010, SwRS-011 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-012 +Titel: Nebenläufigkeitsschutz über Concurrency-GUID +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Zwei Benutzer bearbeiten denselben Beleg. +Fakt: `ReceiptBase` führt das Feld `ConcurrencyControlGuid`; die Methoden `UpdateReceiptInformation`, `UpdateReceiptReminderDate`, `UpdateReceiptProjectNumber`, `UpdateReceiptIsPaid`, `UpdateReceiptItemPurchasePrice`, `UpdateReceiptQuantityPicked`, `UpdateReceiptUserState` und `UpdateOfferClassification` erwarten alle einen Parameter `Guid? concurrencyControlGuid`. +Aussage: Das System soll punktuelle Belegänderungen nur ausführen, wenn die übergebene Nebenläufigkeitskennung mit der gespeicherten übereinstimmt. +Ergebnis: Eine Änderung auf veraltetem Stand wird abgewiesen statt fremde Änderungen zu überschreiben. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Signaturen der Methoden ab Zeile 4790 mit `Guid? concurrencyControlGuid` - Begründung: der Parameter ist an allen punktuellen Änderungsmethoden vorhanden und wird dort ausgewertet. + - [KONTEXT] `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitt „System Fields: ConcurrencyControlGuid" - Begründung: benennt den Zweck des Feldes. +Prüfidee: Zwei parallele Änderungen desselben Belegs: die zweite muss mit einem Nebenläufigkeitsfehler scheitern. +Tracelinks: SyRS-010, SwRS-012 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als optimistische Sperre. +Status: belegt +``` + +``` +ID: SyRS-013 +Titel: Belegsperre während der Bearbeitung +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg wird geöffnet. +Fakt: `ReceiptBL.CreateLock(int receiptI3D, AppUser appUser)` und `RemoveLock(int receiptI3D, AppUser appUser, bool onlyIfLockedByCurrentUser)` setzen und lösen eine Sperre; `SaveReceipt` besitzt den Parameter `bool autoLockIfNewReceipt`; je Belegart existiert eine eigene Sperrentität (z. B. `AssetLockBL`). +Aussage: Das System soll einen in Bearbeitung befindlichen Beleg für andere Benutzer sperren und die Sperre nur durch den sperrenden Benutzer oder ausdrücklich aufheben lassen. +Ergebnis: Ein Beleg wird nicht gleichzeitig von zwei Benutzern verändert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CreateLock` (Zeile 3169) und `RemoveLock` (3160) mit `onlyIfLockedByCurrentUser` - Begründung: die Methoden setzen die Sperrsemantik durch. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, Feld `AssetLockBL _lockBL` - Begründung: belegartspezifische Sperrentität. +Prüfidee: Ein durch Benutzer A gesperrter Beleg darf durch Benutzer B nicht bearbeitbar sein. +Tracelinks: SyRS-012, SwRS-013 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Alternative zur reinen optimistischen Sperre; im Zielsystem zu vereinheitlichen. +Status: belegt +``` + +``` +ID: SyRS-014 +Titel: Belegversionierung mit vollständiger Historienkopie +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein bereits ausgegebener Beleg wird inhaltlich geändert. +Fakt: `ReceiptBL.CreateNewVersion(int receiptI3D, int? version, ContactPerson newContactPerson, AppUser appUser, CreateNewVersionData data)` erzeugt eine neue Version; je Belegart bestehen Versionstabellen (`RechKopfVersions`, `AngKopfVersions` …), die laut Dokumentation 1:1-Kopien der Basistabellen sind. +Aussage: Das System soll bei einer inhaltlichen Änderung eines ausgegebenen Belegs eine neue Version anlegen und den vorherigen Stand vollständig als Version archivieren. +Ergebnis: Jeder ausgegebene Belegstand bleibt unverändert nachvollziehbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CreateNewVersion`, Zeilen 3063-3110, einschließlich Rechteprüfung `CanUserEditReceipt` - Begründung: die Methode erzeugt die Version und prüft die Berechtigung. + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `RechKopfVersions` - Begründung: die Versionstabelle ist im Schema vorhanden. + - [KONTEXT] `docs/reference/receipts/receipts-backend-architecture.md`, „Version Tables: 1:1 Copies of Original Tables" - Begründung: benennt die Strukturregel. +Prüfidee: Nach dem Anlegen der Version 2 muss der Inhalt der Version 1 unverändert abrufbar sein. +Tracelinks: StRS-051, SyRS-010, SwRS-014 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Revisionsanforderung; im Zielsystem ohne Tabellenverdopplung zu lösen. +Status: belegt +``` + +``` +ID: SyRS-015 +Titel: Kopieren eines Belegs auf einen anderen Geschäftspartner +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Quellbeleg existiert. +Fakt: `ReceiptBL.CopyReceipt(AppUser appUser, CopyReceiptData data, int originReceiptI3D, int customerI3D, int? addressI3D, int? contactPersonI3D)` erzeugt einen neuen Beleg aus einem bestehenden mit frei wählbarem Kunden, Adresse und Ansprechpartner. +Aussage: Das System soll einen bestehenden Beleg als Vorlage für einen neuen Beleg verwenden können, auch für einen anderen Geschäftspartner. +Ergebnis: Der neue Beleg trägt die Positionen des Quellbelegs und eine eigene Nummer. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CopyReceipt`, Zeile 1383 - Begründung: die Methode realisiert die Kopie einschließlich Kundenwechsel. +Prüfidee: Die Kopie eines Angebots auf einen anderen Kunden muss dessen Konditionen und eine neue Angebotsnummer tragen. +Tracelinks: SyRS-010, SwRS-015 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-016 +Titel: Belegvorlagen mit festem Ersatzdatum +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg wird als Vorlage gespeichert. +Fakt: In `SaveReceipt` gilt bei `isTemplate`: `data.IgnoreCallbacks = true;` und `receipt.Date = new DateTime(1970, 1, 1);`. Der Parameter `receiptTemplateFolderI3D` ordnet die Vorlage einem Ordner zu. +Aussage: Das System soll Belegvorlagen ohne fachliches Datum speichern, sie einem Vorlagenordner zuordnen und bei ihrer Speicherung keine nachgelagerten Verarbeitungsschritte auslösen. +Ergebnis: Vorlagen erscheinen nicht in datumsbezogenen Auswertungen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Block `if (isTemplate) { data.IgnoreCallbacks = true; receipt.Date = new DateTime(1970, 1, 1); }` - Begründung: das Ersatzdatum wird dort tatsächlich gesetzt. +Prüfidee: Eine Belegvorlage darf in einer Umsatzauswertung des laufenden Jahres nicht erscheinen. +Tracelinks: SyRS-010, SwRS-016 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - das feste Datum 1970-01-01 ist eine Behelfslösung; im Zielsystem ist ein eigenes Vorlagenkennzeichen ohne Ersatzdatum vorzusehen. +Status: belegt +``` + +``` +ID: SyRS-017 +Titel: Zahlungsziel aus Zahlungskondition +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Dem Beleg ist eine Zahlungskondition zugeordnet. +Fakt: `SaveReceipt` ruft `UpdatePaymentDueDate(receipt)` und `UpdateReceiptStateFromPaymentCondition(isNewReceipt, receipt)`; die Zahlungskonditionen liegen in der Tabelle `Zahkond` und werden über `PaymentConditionsSettingsController` gepflegt. +Aussage: Das System soll aus der zugeordneten Zahlungskondition das Zahlungsziel des Belegs errechnen und den Belegzustand entsprechend setzen. +Ergebnis: Der Beleg trägt ein aus der Kondition abgeleitetes Fälligkeitsdatum. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Aufrufe `this.UpdatePaymentDueDate(receipt); … this.UpdateReceiptStateFromPaymentCondition(isNewReceipt, receipt);` - Begründung: die Ableitung erfolgt an dieser Stelle. + - [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `Zahkond` - Begründung: hält die Konditionen. +Prüfidee: Zahlungskondition „30 Tage netto" muss bei Belegdatum 1. März das Fälligkeitsdatum 31. März ergeben. +Tracelinks: StRS-028, SwRS-017 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-018 +Titel: Abweichende Liefer-, Rechnungs- und Lizenznehmeradresse +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg wird weitergeführt. +Fakt: `ForwardReceipt` enthält die Regionen „Alternative Delivery Address", „Alternative Invoice Address", „Alternative Licensee Address" und „Partial Commission Alternative Delivery Address"; `ReceiptContract` führt `DeliveryAddress`, `InvoiceAddress`, `LicenseeAddress` mit jeweils eigener Kunden-ID. +Aussage: Das System soll je Beleg eine von der Stammadresse abweichende Liefer-, Rechnungs- und Lizenznehmeradresse führen und diese beim Weiterführen in den Folgebeleg übernehmen. +Ergebnis: Der Folgebeleg trägt dieselben abweichenden Adressen wie der Vorgängerbeleg. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ForwardReceipt`, Regionen ab Zeile 2638 (Delivery), 2715 (Invoice), 2746 (Licensee) - Begründung: die Regionen übernehmen die Adressen tatsächlich. + - [SEKUNDÄR] `docs/reference/receipts/contracts-backend.md`, Abschnitt „Delivery and Billing Addresses" - Begründung: benennt die drei Adressarten. +Prüfidee: Ein Auftrag mit abweichender Rechnungsadresse muss diese Adresse in der daraus erzeugten Rechnung tragen. +Tracelinks: StRS-003, SyRS-003, SwRS-018 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Lizenzhandel erforderlich. +Status: belegt +``` + +``` +ID: SyRS-019 +Titel: Erzeugung von Tickets aus einem Beleg +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg mit servicebezogenen Positionen liegt vor. +Fakt: `ReceiptBL.GetHelpdeskInfosForReceipt(CentronObjectKindNumeric receiptKind, int receiptI3D, AppUser currentUser)` liefert die vorgesehenen Ticketdaten, `CreateTicketsForReceipt(…, IList helpdeskInfos, AppUser currentUser)` erzeugt daraus Tickets und gibt `IList` zurück. +Aussage: Das System soll aus einem Beleg heraus Servicetickets erzeugen und die Verknüpfung zwischen Beleg und erzeugten Tickets festhalten. +Ergebnis: Die erzeugten Tickets sind dem Beleg zugeordnet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CreateTicketsForReceipt`, Zeile 4445 - Begründung: erzeugt die Tickets und liefert die Verknüpfung. +Prüfidee: Ein Auftrag mit zwei servicebezogenen Positionen muss zwei verknüpfte Tickets erzeugen können. +Tracelinks: StRS-016, StRS-003, SwRS-019 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-020 +Titel: Rechteprüfung an jedem Belegänderungspunkt +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Eine Belegänderung wird ausgelöst. +Fakt: `ReceiptBL` ruft `CanUserEditReceipt(receiptKind, currentUser, receipt.BranchI3D)` an mindestens acht Stellen auf (Zeilen 3081, 3625, 4804, 4839, 4880, 4921, 5114, 5268); die Methode prüft `HasRightToEditReceipt` und `HasRightToEditReceiptOnlyOwnBranch`. +Aussage: Das System soll bei jeder Belegänderung — auch bei punktuellen Feldänderungen — das Bearbeitungsrecht für die betreffende Belegart und gegebenenfalls die Filialbeschränkung prüfen. +Ergebnis: Keine Belegänderung erfolgt ohne geprüfte Berechtigung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserEditReceipt`, Zeilen 10272-10296, mit den Fehlermeldungen „Der Benutzer hat nicht das Recht Belege vom Typ … zu bearbeiten." und „… einer anderen Filiale zu bearbeiten." - Begründung: die Methode ist die zentrale durchsetzende Stelle. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, `HasRightToEditReceipt` (Zeile 529) und `HasRightToEditReceiptOnlyOwnBranch` (534) - Begründung: benennen die konkret geprüften Rechte-IDs je Belegart. +Prüfidee: Das Ändern des Projektnummernfelds einer Rechnung ohne `EDIT_INVOICE` muss abgewiesen werden. +Tracelinks: StRS-005, StRS-031, StRS-032, SwRS-020 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-021 +Titel: Getrennte Rechte für Einkaufs- und Verkaufspreisänderung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Eine Belegposition wird bearbeitet. +Fakt: `InvoiceSpecificLogic.HasRightToChangePurchasePrice` prüft `Invoice.CHANGE_PURCHASE_PRICE`, `HasRightToChangeSellPrice` prüft `Invoice.CHANGE_PRICE`; `SaveReceipt` ruft `UpdateArticlePositionsPurchasePriceAndSellPriceIfUserDoesNotHaveRightToChangeThem(currentUser, receipt, previousReceiptVersion)` auf und setzt die Preise auf den Vorgängerstand zurück. +Aussage: Das System soll Einkaufs- und Verkaufspreisänderungen an Belegpositionen über getrennte Rechte steuern und Änderungen ohne das jeweilige Recht auf den Vorgängerwert zurücksetzen. +Ergebnis: Ein unberechtigter Benutzer kann Preise faktisch nicht verändern. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Aufruf `UpdateArticlePositionsPurchasePriceAndSellPriceIfUserDoesNotHaveRightToChangeThem` - Begründung: setzt die Preise tatsächlich zurück und ist damit die durchsetzende Stelle. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, Zeilen 377-385 - Begründung: benennen die geprüften Rechte-IDs. +Prüfidee: Ein Benutzer ohne `CHANGE_PRICE` ändert einen Verkaufspreis; nach dem Speichern muss der alte Preis wieder eingetragen sein. +Tracelinks: SyRS-020, SwRS-021 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Margenschutz. +Status: belegt +``` + +``` +ID: SyRS-022 +Titel: Belegartspezifische Ausprägung über austauschbare Logikbausteine +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine belegartabhängige Regel ist auszuwerten. +Fakt: Die Schnittstelle `IReceiptSpecificLogic` mit der Eigenschaft `TargetReceiptKind` wird je Belegart implementiert (`InvoiceSpecificLogic`, `OrderSpecificLogic`, `OfferSpecificLogic`, `DeliveryListSpecificLogic` …); `ReceiptBL` ruft sie über `_specificLogics.Execute(receiptKind, f => …)` auf. +Aussage: Das System soll belegartabhängige Regeln über eine einheitliche Schnittstelle bereitstellen, sodass der gemeinsame Belegkern für alle sieben Belegarten unverändert bleibt. +Ergebnis: Neue Belegarten sind ohne Änderung des Belegkerns ergänzbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs` und `SpecificLogics.cs` - Begründung: definieren die Schnittstelle und die Auswahl der Implementierung. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, `public CentronObjectKindNumeric TargetReceiptKind => CentronObjectKindNumeric.InvoiceClass;` - Begründung: die Zuordnung der Implementierung zur Belegart ist dort festgelegt. +Prüfidee: Für jede der sieben Belegarten muss `_specificLogics.Execute` genau eine Implementierung finden. +Tracelinks: SyRS-010, SwRS-022 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - tragfähiges Erweiterungsmuster. +Status: belegt +``` + +``` +ID: SyRS-023 +Titel: Gemeinsames Objektprotokoll über Objektart und Objekt-ID +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Vorgang ist zu protokollieren oder zu referenzieren. +Fakt: Die Tabelle `AnlageLog` führt `AnlageI3D` und `AnlageArt` mit den Werten 1 = Angebot, 2 = Auftrag, 3 = Lieferschein, 4 = Rechnung, 5 = Abholschein, 6 = Gutschrift, 22 = Vertrag; dasselbe Muster (`ObjectI3D` + `ObjectKind`) wird systemweit verwendet, etwa in `ToDoArea`, `ObjectExternalReferences`, `IndexSearch` (`CentronObjectKindNumeric`). +Aussage: Das System soll objektübergreifende Zusatzdaten einheitlich über das Paar aus Objektart und Objekt-ID referenzieren. +Ergebnis: Protokolle, Aufgaben, Dokumente und Indexeinträge sind unabhängig von der Objektart nutzbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs`, `RequestUpdateFor(CentronObjectKindNumeric kind, int objectI3D)` - Begründung: das Referenzmuster ist in der Signatur durchgesetzt. + - [KONTEXT] `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitt „AnlageLog Table" mit der Werteliste für `AnlageArt` - Begründung: benennt die Kodierung. +Prüfidee: Ein Protokolleintrag mit `AnlageArt = 4` muss ausschließlich Rechnungen zugeordnet werden. +Tracelinks: StRS-051, SwRS-023 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als polymorphe Referenz zu formalisieren. +Status: belegt +``` + +## 3. Verträge und Abrechnung + +``` +ID: SyRS-030 +Titel: Kontingentverbrauch und Restkontingent eines Vertrags +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertragsverwaltung +Vorbedingung: Ein Vertrag mit Kontingent besteht. +Fakt: `ContractBL.GetContingentRest(int contractI3D)` liefert einen `ContingentState`; `ReceiptContract` führt `ContingentUsedHours`, `ContingentUsedAmount`, `ContingentBalanceUsedHours`, `ContingentBalanceUsedAmount`, `ContingentResidualValueStart`, `IsContingentLimitBilling`, `ContingentLimitValue`, `ContingentLimitKind`. +Aussage: Das System soll den Verbrauch eines Vertragskontingents in Stunden und Betrag fortschreiben, das Restkontingent ermitteln und bei Überschreiten der Grenze die Abrechnung der Mehrleistung auslösen. +Ergebnis: Der Kontingentstand ist jederzeit bestimmbar; Mehrleistung wird abgerechnet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs`, `GetContingentRest`, Zeile 60 - Begründung: berechnet den Kontingentstand. + - [PRIMÄR] `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs`, Kontingentfelder - Begründung: die Verbrauchsgrößen sind persistiert. + - [KONTEXT] `docs/reference/receipts/contracts-backend.md`, Abschnitt „Contingent Limits and Monitoring" - Begründung: erläutert Grenzwert und Grenzwertart. +Prüfidee: Ein Vertrag mit 10 Stunden Kontingent und 12 gebuchten Stunden muss ein Restkontingent von 0 und 2 abzurechnende Stunden ausweisen. +Tracelinks: StRS-008, StRS-012, SwRS-030 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-031 +Titel: Ausgleichsartikel für Kontingentsalden +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Vertrag verwendet den Kontingentsaldo-Artikel. +Fakt: `ReceiptContract` führt `ContingentBalanceArticleI3D` und `UseContingentBalanceArticle`; `ArticleBL.GetContractBalanceArticle()` (Zeile 151) und `GetFlatrateBalanceArticle()` (143) liefern reservierte Systemartikel. +Aussage: Das System soll Kontingentsalden über einen eigens gekennzeichneten Ausgleichsartikel in Rechnungen darstellen. +Ergebnis: Der Saldo ist als eigene Rechnungsposition sichtbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `GetContractBalanceArticle`, Zeile 151 - Begründung: liefert den reservierten Artikel und ist die durchsetzende Stelle der Zuordnung. + - [SEKUNDÄR] `docs/reference/receipts/contracts-backend.md`, Feld `ContingentBalanceArticleI3D` - Begründung: benennt die Verknüpfung. +Prüfidee: Eine Vertragsrechnung mit Kontingentsaldo muss eine Position mit dem konfigurierten Ausgleichsartikel enthalten. +Tracelinks: SyRS-030, SwRS-031 +Konsolidierung: Kandidat: SwRS-031 — Vertrags- und Pauschalabrechnung führen zwei getrennte Ausgleichsartikel für denselben Zweck. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-032 +Titel: Stichtagsbezogene Ermittlung fälliger Abrechnungen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Abrechnungsstichtag ist gewählt. +Fakt: `AutomaticFacturaBL.SearchBillingDeliveryLists(DateTime endDate, int customerI3D)` und `SearchBillingOrders(DateTime endDate, int customerI3D, bool searchForInvoice)` filtern über ein Enddatum; `SearchCustomers(DateTime BilledTo)` nutzt die benannte Abfrage `GetCustomersForAutomatedBilling`. +Aussage: Das System soll je Abrechnungsstichtag alle bis dahin abrechenbaren Lieferscheine, Aufträge und Verträge ermitteln und je Kunde gebündelt zur Abrechnung vorschlagen. +Ergebnis: Der Abrechnungslauf erfasst genau die zum Stichtag fälligen Vorgänge. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `SearchBillingDeliveryLists` (Zeile 102), `SearchBillingOrders` (114), `SearchCustomers` (451) - Begründung: die Methoden führen die Stichtagsauswahl aus. +Prüfidee: Ein Lieferschein mit Datum nach dem Stichtag darf nicht in der Vorschlagsliste erscheinen. +Tracelinks: StRS-009, SwRS-032 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-033 +Titel: Import externer Artikel- und Mengendaten in Verträge +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Vertragsverwaltung +Vorbedingung: Eine externe Mengendatei oder MSP-Auswertung liegt vor. +Fakt: `AutomaticFacturaBL.CreateSpecialArticleToContract(IList headImportList, AppUser currentUser)` und `CreateSpecialArticleToContractFromMspEvaluation(MspEvaluationCompensationItemDTO, AppUser)` erzeugen Vertragspositionen aus externen Daten mit `BillingDateValidFrom`; `ContractExternalArticleImportHeadBL` und `ContractExternalArticleImportPositionsBL` bilden den Import ab. +Aussage: Das System soll externe Artikel- und Mengendaten mit Gültigkeitsdatum in Verträge übernehmen und daraus abrechenbare Vertragspositionen erzeugen. +Ergebnis: Die importierten Mengen sind ab dem angegebenen Datum abrechenbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `CreateSpecialArticleToContract`, Zeile 149, mit `BillingDateValidFrom = headImport.BillingDate` - Begründung: setzt die Gültigkeit der importierten Position. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractExternalArticleImportHeadBL.cs` - Begründung: verwaltet die Importköpfe. +Prüfidee: Eine mit Gültigkeit ab 1. Juli importierte Menge darf in der Juni-Abrechnung nicht erscheinen. +Tracelinks: StRS-008, StRS-062, SwRS-033 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-034 +Titel: Gegenseitiger Ausschluss der Provisionsmodule +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Provisionsrechte sind vergeben. +Fakt: `ModuleRegistration` registriert `ProvisionSchemaManagementAppModuleController` und `AssignmentsAppModuleController` nur unter der Bedingung `!Helper.HasRights(UserRightsConst.Sales.Provision.PROVISION_EVALUATION_MODULE) && Helper.HasRights(…)`. +Aussage: Das System soll einem Benutzer mit dem Recht auf die Provisionsauswertung die separaten Verwaltungsmodule für Schemata und Kundenzuordnung nicht zusätzlich anzeigen. +Ergebnis: Der Benutzer sieht entweder die Auswertung oder die Verwaltungsmodule, nicht beides. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Abrechnung", Bedingungen der Zeilen 430-438 - Begründung: die Negation im Rechteausdruck ist die durchsetzende Stelle. +Prüfidee: Benutzer mit `PROVISION_EVALUATION_MODULE` darf im Menü kein Modul „Provisionsschemas verwalten" sehen. +Tracelinks: StRS-013, SwRS-034 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - der Ausschluss ist eine Menüsteuerung, die im Zielsystem durch eine gemeinsame Provisionsoberfläche ersetzt werden sollte. +Status: belegt +``` + +``` +ID: SyRS-035 +Titel: Einmalige Abrechnung eines Zeiteintrags +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Zeiteinträge wurden abgerechnet. +Fakt: `TimerBillingBL.UpdateOrderItems(int orderI3D, IList orderItemI3Ds, AppUser currentUser)` verknüpft Zeiteinträge mit Auftragspositionen; `HelpdeskTimerBL.CreateReferenceForTicketTimersToOrderItems` und `RemoveReferenceFromTicketTimersToOrderItems` setzen und lösen diese Referenz. `HelpdeskTimerBL.GetHelpdeskTimerReceiptNumbers(LoggedInUser, int helpdeskTimerI3D)` liefert die Belege, in denen ein Zeiteintrag enthalten ist. +Aussage: Das System soll jeden Zeiteintrag mit dem Beleg verknüpfen, in dem er abgerechnet wurde, und eine erneute Abrechnung desselben Eintrags verhindern. +Ergebnis: Kein Zeiteintrag wird doppelt abgerechnet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `CreateReferenceForTicketTimersToOrderItems`, Zeile 604 - Begründung: erzeugt die Abrechnungsreferenz. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `GetHelpdeskTimerReceiptNumbers`, Zeile 119 - Begründung: liest die bestehende Belegzuordnung eines Zeiteintrags aus. + - [SEKUNDÄR] `CentronRights.md`, Abschnitte 8 und 9: Verschieben und Löschen von Helpdeskzeiten sind nur zulässig, „if the ticket is not part of a receipt" - Begründung: bestätigt die Sperre nach Abrechnung fachlich. +Prüfidee: Ein bereits einem Auftrag zugeordneter Zeiteintrag darf im nächsten Abrechnungslauf nicht als abrechenbar erscheinen. +Tracelinks: StRS-012, StRS-014, SwRS-035 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - verhindert Doppelfakturierung. +Status: belegt +``` + +``` +ID: SyRS-036 +Titel: Stundensatzzuschläge nach Zeitfenstern +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Ein Zeiteintrag überschneidet ein Zuschlagsfenster. +Fakt: `HelpdeskTimerBL.CalculateHourlySurchargeRateOverlaps(DateTime start, DateTime end, int? contractI3D)` und die Überladung mit `HourlySurchargeRate` liefern `List`; `GetReceiptHourlySurchargeRate(CentronObjectKindNumeric receiptKind, int receiptI3D)` liefert den Satz am Beleg; `ReceiptBL.UpdateReceiptHourlySurchargeRateI3D` setzt ihn. +Aussage: Das System soll für jeden Zeiteintrag die Überschneidungen mit hinterlegten Zuschlagszeitfenstern ermitteln und den Zuschlag anteilig auf die Abrechnung anwenden. +Ergebnis: Nacht-, Wochenend- und Feiertagsanteile werden mit dem jeweiligen Zuschlag abgerechnet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `CalculateHourlySurchargeRateOverlaps(DateTime start, DateTime end, int? contractI3D)`, Zeile 187 - Begründung: berechnet die Überschneidungen und ist damit die durchsetzende Stelle. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptHourlySurchargeRateI3D`, Zeile 5106, mit vorangehender Prüfung `CanUserEditReceipt` - Begründung: setzt den Zuschlagssatz am Beleg unter Rechteprüfung. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates/` - Begründung: Pflegeoberfläche der Zuschlagssätze. +Prüfidee: Ein Einsatz von 21:00 bis 23:00 Uhr mit Nachtzuschlag ab 22:00 Uhr muss eine Stunde ohne und eine Stunde mit Zuschlag ergeben. +Tracelinks: StRS-012, StRS-014, SwRS-036 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +## 4. Service und Ticketbearbeitung + +``` +ID: SyRS-040 +Titel: Zustandsmaschine der Ticketzeiterfassung +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Der Benutzer ist angemeldet. +Fakt: `HelpdeskTimeRecordingBL` führt eine über `guid` identifizierte Erfassung durch die Zustände Start (`StartRecording`), Pause (`PauseRecording`), Fortsetzen (`ResumeRecording`), Stopp (`StopRecording`) und Verwerfen (`ClearRecording`); jede Methode kann über `createHistoryEntry` einen Historieneintrag schreiben. `UpdateTimeRecording(RecordingInformation stopwatch, AppUser)` erlaubt die nachträgliche Korrektur. +Aussage: Das System soll je Zeiterfassung genau die Zustandsübergänge Start, Pause, Fortsetzen, Stopp und Verwerfen zulassen und jeden Übergang optional historisieren. +Ergebnis: Die Zeiterfassung befindet sich stets in einem definierten Zustand. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimeRecordingBL.cs`, Methoden `StartRecording` (172), `PauseRecording` (277), `ResumeRecording` (317), `StopRecording` (357), `ClearRecording` (398) - Begründung: die Methoden realisieren die Zustandsübergänge. +Prüfidee: Ein `ResumeRecording` ohne vorangegangenes `PauseRecording` muss abgewiesen werden. +Tracelinks: StRS-014, SwRS-040 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-041 +Titel: Erinnerung an laufende Zeiterfassungen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Eine Zeiterfassung läuft. +Fakt: `HelpdeskTimeRecordingBL.GetStopwatchNotificationsForEmployee(int employeeI3D)` liefert `List`, `DeleteStopwatchNotifications(List notificationI3Ds, int? helpdeskI3D, int? employeeI3D)` entfernt sie; `SaveTimeRecordingLastClosed(int? helpdeskI3D, AppUser currentUser, DateTime lastClosed)` merkt den letzten Schließzeitpunkt. +Aussage: Das System soll den Mitarbeiter auf laufende, nicht beendete Zeiterfassungen hinweisen und diese Hinweise nach Bearbeitung entfernen. +Ergebnis: Vergessene laufende Erfassungen werden erkannt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimeRecordingBL.cs`, `GetStopwatchNotificationsForEmployee`, Zeile 506 - Begründung: liefert die Hinweise je Mitarbeiter. +Prüfidee: Eine über Nacht laufende Erfassung muss am Folgetag als Hinweis erscheinen. +Tracelinks: SyRS-040, SwRS-041 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-042 +Titel: Löschen von Zeiteinträgen nur mit eigenem Recht +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Ein Zeiteintrag existiert. +Fakt: `HelpdeskTimerBL.DeleteHelpdeskTimer(LoggedInUser currentUser, int helpdeskTimerI3D)` bricht ab, wenn `this._appRightsBL.HasUserRight(currentUser.User.I3D, UserRightsConst.Sales.Customer.Helpdesk.DELETE_HELPDESK_TIMER) is false`. +Aussage: Das System soll das Löschen eines Zeiteintrags an das Recht `DELETE_HELPDESK_TIMER` binden. +Ergebnis: Zeiteinträge werden nicht unberechtigt entfernt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `DeleteHelpdeskTimer`, Zeile 556, Rechteprüfung vor dem Löschen - Begründung: die Prüfung ist die durchsetzende Stelle. + - [KONTEXT] `CentronRights.md`, Abschnitt 9 „Helpdeskzeiten löschen" - Begründung: beschreibt das Recht und die Einschränkung auf nicht abgerechnete Tickets. +Prüfidee: Ohne das Recht muss der Löschversuch fehlschlagen und der Eintrag erhalten bleiben. +Tracelinks: StRS-014, StRS-031, SwRS-042 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-050 +Titel: Pflichtfelder beim Speichern eines Tickets +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Helpdesk-Mitarbeiter +Vorbedingung: Ein Ticket soll gespeichert werden. +Fakt: `HelpdeskBL.Save(Helpdesk entity, LoggedInUser currUser, bool ignoreMandatoryFields)` ruft bei `ignoreMandatoryFields == false` die Methode `DoValidateMandatoryFields(entity)` auf, die unter anderem „Kein Kunde ausgewählt" meldet, und bricht bei Fehlern ab. +Aussage: Das System soll ein Ticket nur speichern, wenn alle Pflichtfelder gefüllt sind; das Übergehen der Pflichtfeldprüfung ist ausschließlich für systeminterne Vorgänge zulässig. +Ergebnis: Gespeicherte Tickets tragen mindestens Kunde und die weiteren Pflichtangaben. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `Save`, Zeilen 300-307, und `DoValidateMandatoryFields`, Zeile 658 mit Prüfung `if (helpdesk.Customer == null)` - Begründung: die Prüfung verhindert das Speichern tatsächlich. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, Parameter `ignoreMandatoryFieldsOnClose` - Begründung: belegt den vorgesehenen Ausnahmefall beim Abschluss. +Prüfidee: Ein Ticket ohne Kunde muss mit der Meldung „Kein Kunde ausgewählt" abgewiesen werden. +Tracelinks: StRS-016, SwRS-050 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-051 +Titel: Rechteprüfungen beim Speichern eines Tickets +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Helpdesk-Mitarbeiter +Vorbedingung: Ein Ticket wird angelegt oder geändert. +Fakt: `HelpdeskBL.CheckUserRigths` prüft bei Neuanlage `ADD_NEW_HELPDESK`, bei Änderung `EDIT_HELPDESK`, beim Setzen des Abschlussstatus zusätzlich `CLOSE_REQUEST` und bei geändertem Fälligkeitsdatum (`IsDueDateChanged`) das Recht `MATURITY_CHANGE`; bei Web-Anmeldung wird stattdessen `CheckWebRights` aufgerufen. +Aussage: Das System soll beim Speichern eines Tickets die Rechte für Anlage, Änderung, Abschluss und Fälligkeitsänderung einzeln prüfen und für Web-Benutzer ein eigenes Regelwerk anwenden. +Ergebnis: Statusänderung und Terminverschiebung erfolgen nur mit dem jeweiligen Recht. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckUserRigths`, Zeilen 418-452, mit den Fehlermeldungen „Sie haben nicht das Recht ‚Helpdesks anzulegen'", „… ‚Ticket bearbeiten'", „… ‚Helpdesk abschließen'", „Kein Recht für Fälligkeitsdatum ändern vorhanden." - Begründung: jede Prüfung bricht den Speichervorgang ab. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckRights`, Zeile 410, Verzweigung `if (currUser.IsWebAccountLogin)` - Begründung: trennt die Regelwerke. +Prüfidee: Ein Benutzer ohne `MATURITY_CHANGE` darf das Fälligkeitsdatum eines Tickets nicht ändern, andere Felder aber schon. +Tracelinks: StRS-016, StRS-031, SwRS-051 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-052 +Titel: Kürzung von Ticket-Textfeldern auf Datenbanklänge +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Ticket wird gespeichert. +Fakt: `HelpdeskBL.CheckTextFieldLengths` kürzt `ShortDescription` auf 1.000, `Version` auf 100, `AdditionalText2` auf 100, `FreeText1` auf 250, `ProjectNumber` auf 50, `ContactName` auf 50, `ContactEMail` auf 250 und `ContactPhone` auf 50 Zeichen; ein Kommentar verweist auf die Spaltenlängen der Tabelle `hlpdsk_requests`. +Aussage: Das System soll Ticket-Textfelder vor dem Speichern auf die in der Datenbank zulässige Länge kürzen, um Speicherfehler zu vermeiden. +Ergebnis: Das Speichern schlägt nicht wegen Feldlängen fehl. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckTextFieldLengths`, Zeilen 333-348 - Begründung: die Kürzungen werden dort tatsächlich vorgenommen. + - [KONTEXT] Kommentar ebenda: „these max values come from the hlpdsk_requests table … this should also be done in the UI via maxlenght" - Begründung: benennt Herkunft der Grenzen und die fehlende Absicherung in der Oberfläche. +Prüfidee: Eine Kurzbeschreibung mit 1.500 Zeichen muss nach dem Speichern 1.000 Zeichen umfassen. +Tracelinks: SyRS-050, SwRS-052 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - das stille Abschneiden verdeckt einen Eingabefehler; im Zielsystem ist die Länge in der Eingabemaske zu begrenzen. +Status: belegt +``` + +``` +ID: SyRS-053 +Titel: Automatischer Präfix für Ticket-Kurzbeschreibungen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Helpdesk +Vorbedingung: Die Einstellung `IsHelpdeskShortDescriptionPrefixActivated` ist gesetzt. +Fakt: `HelpdeskBL.AddShortDescriptionPrefix` ersetzt im konfigurierten Präfix die Variablen `@@Hauptkategorie@@`, `@@Unterkategorie1@@`, `@@Unterkategorie2@@`, `@@Typ@@`, `@@Ansprechpartner@@`, `@@Zusatztext1@@`, `@@Zusatztext2@@` und stellt das Ergebnis der Kurzbeschreibung voran; ist keine verwendete Variable belegt, unterbleibt die Ergänzung. +Aussage: Das System soll neuen Tickets einen konfigurierbaren, aus Ticketmerkmalen zusammengesetzten Präfix voranstellen und darauf verzichten, wenn keine der verwendeten Variablen einen Wert hat. +Ergebnis: Ticketbetreffs sind einheitlich strukturiert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `AddShortDescriptionPrefix`, Zeilen 351-393, einschließlich Prüfung `anyUsedVariableHasValue` - Begründung: die Bedingung entscheidet über das Voranstellen. +Prüfidee: Ein Ticket ohne gesetzte Kategorie darf bei einem Präfix `@@Hauptkategorie@@` keinen leeren Präfix erhalten. +Tracelinks: SyRS-050, SwRS-053 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-054 +Titel: Ticketabschluss mit Folgeaktionen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Helpdesk-Mitarbeiter +Vorbedingung: Ein Ticket soll abgeschlossen werden. +Fakt: `HelpdeskCloseBL.CloseHelpdesk(AppUser, int helpdeskI3D, …)` prüft `CanCloseHelpdesk`, löscht über `ToDoBL.DeleteHelpdeskToDos` die zugehörigen Aufgaben, setzt `HelpdeskState` auf den über `HelpdeskSettingsBL.GetClosedHelpdeskState()` ermittelten Abschlussstatus und `ClosedAt` auf den aktuellen Zeitpunkt und erzeugt danach Benachrichtigung, Historieneintrag (`HelpdeskHistoryType.Close`) und Kundenaktivität. +Aussage: Das System soll beim Ticketabschluss den konfigurierten Abschlussstatus setzen, den Abschlusszeitpunkt festhalten, offene Aufgaben entfernen sowie Benachrichtigung, Historie und Kundenaktivität erzeugen. +Ergebnis: Das Ticket ist geschlossen und alle Folgeaktionen sind ausgeführt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `CloseHelpdesk`, Zeilen 120-157 - Begründung: die Methode führt Statuswechsel und Folgeaktionen tatsächlich aus. + - [KONTEXT] ebenda, `CanCloseHelpdesk` mit Kommentar „//Todo: if rma exists check if finished" und Rückgabe `true` - Begründung: dokumentiert, dass die vorgesehene RMA-Prüfung nicht implementiert ist. +Prüfidee: Nach dem Abschluss darf keine offene Aufgabe zum Ticket mehr existieren und ein Historieneintrag vom Typ `Close` muss vorliegen. +Tracelinks: StRS-016, StRS-046, SwRS-054 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-055 +Titel: Ticketabschluss trotz offener RMA +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Helpdesk-Mitarbeiter +Vorbedingung: Zum Ticket besteht ein offener RMA-Vorgang. +Fakt: `HelpdeskCloseBL.CanCloseHelpdesk(int helpdeskI3D)` enthält ausschließlich eine Nichtnull-Prüfung des Parameters, den Kommentar „//Todo: if rma exists check if finished" und die Rückgabe `true`. +Aussage: Das System soll den Abschluss eines Tickets bei offenem RMA-Vorgang verhindern. [HYPOTHESE] Die Prüfung ist im Code als Aufgabe vermerkt, aber nicht implementiert; ob die Sperre fachlich gewollt ist oder bewusst entfiel, geht aus den Artefakten nicht hervor. +Ergebnis: Ein Ticket mit offener RMA bleibt offen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `CanCloseHelpdesk`, Zeilen 159-167 - Begründung: die Methode ist die vorgesehene, aber leere Prüfstelle; der Kommentar benennt die beabsichtigte Regel. +Prüfidee: Ticket mit offener RMA abschließen: im heutigen Stand gelingt der Abschluss; im Zielsystem ist zu entscheiden, ob er scheitern soll. +Tracelinks: SyRS-054, StRS-018, SwRS-055 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die Regel ist fachlich plausibel und im Zielsystem zu klären. +Status: HYPOTHESE +``` + +``` +ID: SyRS-056 +Titel: Kundenbefragung nach Ticketabschluss +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Kunde +Vorbedingung: In den Umfrageeinstellungen ist `ValueAttachmentForHelpdesk` gesetzt und eine Umfragevorlage hinterlegt. +Fakt: `HelpdeskCloseBL.AddSurvey` prüft `surveySettings.ValueAttachmentForHelpdesk && surveySettings.ValueHelpdeskSurveyI3D.HasValue && accountI3D.HasValue`, ermittelt den Kontakt über `AccountSearchBL.SearchAccountContactByAdSearchstring(accountI3D, eMail)` und hängt den Umfragetext an den Mailtext an. +Aussage: Das System soll der Abschlussbenachrichtigung eines Tickets eine Kundenbefragung beifügen, sofern dies konfiguriert ist und der Empfänger als Kontakt des Accounts auffindbar ist. +Ergebnis: Der Kunde erhält mit der Abschlussmail eine Befragung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `AddSurvey`, Zeilen 200-235, mit der genannten Bedingung - Begründung: die Bedingung entscheidet über das Anhängen. + - [SEKUNDÄR] `src/backend/Centron.BL/Accounts/Survey/` - Begründung: Umfrageverwaltung. +Prüfidee: Bei aktivierter Einstellung muss die Abschlussmail einen Umfragelink enthalten, bei deaktivierter nicht. +Tracelinks: SyRS-054, StRS-033, SwRS-056 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-057 +Titel: Weiterleitung und Eskalation von Tickets +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Helpdesk-Mitarbeiter +Vorbedingung: Ein Ticket ist nicht durch den aktuellen Bearbeiter lösbar. +Fakt: Es bestehen `HelpdeskForwardBL`, `Sales/Support/Escalation/`, die Weboberflächen `ForwardTicket/ForwardTicketPage.razor` und `ForwardMultipleTickets.razor` sowie die Einstellungsseite `EscalationTypeController`; das Recht `ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS` beschränkt die Zuweisung. +Aussage: Das System soll Tickets einzeln und in Auswahl an andere Bearbeiter oder Abteilungen weiterleiten und dabei die Beschränkung auf eigene Abteilungen beachten; überfällige Tickets sind nach konfigurierten Eskalationsstufen zu eskalieren. +Ergebnis: Das Ticket liegt beim zuständigen Bearbeiter; Eskalationen sind ausgelöst. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskForwardBL.cs` und `Escalation/` - Begründung: realisieren Weiterleitung und Eskalation. + - [SEKUNDÄR] `src/nexus/CentronNexus/ServiceBoard/ForwardTicket/Components/ForwardMultipleTickets.razor` - Begründung: belegt die Mehrfachweiterleitung. + - [KONTEXT] `CentronRights.md`, Abschnitt 4 „Helpdeskzuweisung nur an eigene Abteilungen" - Begründung: beschreibt die Beschränkung. +Prüfidee: Ein Benutzer mit `ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS` darf ein Ticket nicht an eine fremde Abteilung weiterleiten. +Tracelinks: StRS-016, StRS-032, SwRS-057 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-058 +Titel: Automatische Ticketerzeugung aus Vorlagen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Eine Ticketvorlage mit Zeitplan ist hinterlegt. +Fakt: Es bestehen `HelpdeskCreationTemplateBL`, `HelpdeskPatternBL`, `HelpdeskCategoryPatternBL` und `HelpdeskSchedulerBL`; die Webverwaltung `Management/TicketPatterns` bietet Reiter für Allgemein, Kunde, Checklisten, Formulare, Mailvorlage, Eigenschaften, Skripte und Webformular. +Aussage: Das System soll Tickets nach Vorlagen automatisch und zeitgesteuert erzeugen, wobei die Vorlage Kategorie, Kunde, Checklisten, Formulare und Mailvorlage vorgibt. +Ergebnis: Wiederkehrende Serviceleistungen erzeugen ohne manuelles Zutun Tickets. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskSchedulerBL.cs` und `HelpdeskCreationTemplateBL.cs` - Begründung: realisieren Zeitsteuerung und Vorlagenauswertung. + - [SEKUNDÄR] `src/nexus/CentronNexus/Management/TicketPatterns/Components/` mit neun Reiterkomponenten - Begründung: belegen den Umfang der Vorlagendefinition. + - [KONTEXT] `docs/features/automatic-helpdesk-creation-templates.md` - Begründung: beschreibt die Funktion. +Prüfidee: Eine Vorlage mit monatlichem Zeitplan muss genau ein Ticket pro Monat erzeugen. +Tracelinks: StRS-016, SwRS-058 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-059 +Titel: Zwischengespeicherte Ticketlisten für die Weboberfläche +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Performance-Effizienz (Zeitverhalten) +Akteur: Helpdesk-Mitarbeiter +Vorbedingung: Die Weboberfläche zeigt eine Ticketliste. +Fakt: Das Schema enthält die Tabelle `CacheTicketStatistic`; die Webanwendung stellt `ServiceBoard/CachedTicketList/CachedTicketListPage.razor` mit `CachedKanbanBoard` bereit; die Konfiguration erfolgt über `Configuration/TicketCacheConfig.cs`; im Backend besteht `Services/CachedTableBL.cs`. +Aussage: Das System soll Ticketlisten und Ticketkennzahlen für die Weboberfläche zwischenspeichern, um die Anzeige großer Listen ohne erneute Auswertung der Basisdaten zu ermöglichen. +Ergebnis: Die Ticketliste wird aus dem Zwischenspeicher beantwortet. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus/Configuration/TicketCacheConfig.cs` und `src/backend/Centron.BL/Services/CachedTableBL.cs` - Begründung: Konfiguration und Verwaltung des Zwischenspeichers sind eigens implementiert. + - [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `CacheTicketStatistic` - Begründung: der Zwischenspeicher ist persistiert. +Prüfidee: Nach Änderung eines Tickets muss die zwischengespeicherte Liste innerhalb des konfigurierten Intervalls den neuen Stand zeigen. +Tracelinks: StRS-016, SwRS-059 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als Lese-Projektion. +Status: belegt +``` + +## 5. Warenwirtschaft und Logistik + +``` +ID: SyRS-060 +Titel: Zustandsführung von Seriennummern über den gesamten Lebenslauf +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Lagerist +Vorbedingung: Ein Einzelstück ist erfasst. +Fakt: `BarcodeState` kennt mindestens die Werte `InStock`, `InRequest`, `InDeliveryList`, `InInvoice` und `ManuallyBookedOut`; `RmaBL` setzt diese Zustände bei Warenbewegungen, `BarcodeHistoryBL` schreibt die Historie, `SeriennummerToPosition` verknüpft Seriennummer und Belegposition. +Aussage: Das System soll je Einzelstück einen Zustand führen, ihn bei jeder Warenbewegung fortschreiben und die Zustandsfolge historisieren. +Ergebnis: Der Weg jedes Einzelstücks durch Bestand, Beleg und Auslieferung ist rekonstruierbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/CustomerArea/RmaBL.cs`, Zuweisungen `dbNewBarcode.State = BarcodeState.InInvoice` (Zeile 179), `dbBarcode.State = BarcodeState.InStock` (Zeile 313), `repairBarcode.State = BarcodeState.ManuallyBookedOut` (Zeile 266) - Begründung: die Zuweisungen sind die durchsetzenden Stellen der Zustandsmaschine. + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `Barcode`, `SeriennummerToPosition` - Begründung: Zustand und Belegzuordnung sind persistiert. +Prüfidee: Eine Seriennummer, die in eine Rechnung eingeht, muss anschließend den Zustand `InInvoice` tragen. +Tracelinks: StRS-021, StRS-018, SwRS-060 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Grundlage der Gewährleistungsverfolgung. +Status: belegt +``` + +``` +ID: SyRS-061 +Titel: Prüfung des Verbleibs von Barcodes bei Belegänderung +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Beleg mit erfassten Barcodes wird in einer neuen Version gespeichert. +Fakt: `SaveReceipt` ruft bei vorhandener Vorgängerversion `_receiptBarcodeBL.CheckIfAllNonActiveBarcodesAreStillInTheReceipt(receipt, previousReceiptVersion)` auf und bricht bei Fehler mit einer Meldung ab. +Aussage: Das System soll verhindern, dass bereits verbuchte Barcodes durch eine neue Belegversion aus dem Beleg entfernt werden. +Ergebnis: Verbuchte Einzelstücke bleiben ihrem Beleg zugeordnet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Abschnitt „Validate barcodes" - Begründung: der Abbruch verhindert das Entfernen tatsächlich. +Prüfidee: Entfernt man in einer neuen Belegversion eine bereits gebuchte Seriennummer, muss das Speichern scheitern. +Tracelinks: SyRS-060, SyRS-014, SwRS-061 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Datenintegrität. +Status: belegt +``` + +``` +ID: SyRS-062 +Titel: Stufenweiser Abschluss der Inventur +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lagerist +Vorbedingung: Zählmengen sind erfasst. +Fakt: `InventoryNewBL.CloseStorages(int inventoryI3D, List storageI3Ds, bool isCompleteInventory, LoggedInUser)` schließt einzelne Lager, `CloseInventory(int inventoryI3D)` die gesamte Inventur; `CheckInventory(List, int inventoryI3D, int groupI3D, LoggedInUser)` prüft die Erfassung je Zählgruppe; `GetInventoryStatistic` und `GetInventoryLogs` liefern Auswertung und Protokoll. +Aussage: Das System soll die Inventur je Lager und Zählgruppe erfassen, Lager einzeln abschließen, die Gesamtinventur abschließen und alle Schritte protokollieren. +Ergebnis: Abgeschlossene Lager sind für weitere Zählungen gesperrt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryNewBL.cs`, `CloseStorages` (Zeile 294) und `CloseInventory` (Zeile 312) - Begründung: setzen den Abschluss durch. + - [SEKUNDÄR] ebenda, `GetInventoryLogs` (Zeile 326) - Begründung: belegt die Protokollierung. +Prüfidee: Nach `CloseStorages` für Lager 1 darf für dieses Lager keine Zählmenge mehr erfassbar sein. +Tracelinks: StRS-022, SwRS-062 +Konsolidierung: Kandidat: SwRS-063 — `InventoryBL` und `InventoryNewBL` implementieren dieselbe Fachfunktion getrennt. +Übernahmewürdigkeit: übernehmen - handelsrechtlich erforderlich. +Status: belegt +``` + +``` +ID: SyRS-063 +Titel: Teilkommissionierung mit abweichender Lieferadresse +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Lagerist +Vorbedingung: Ein Auftrag wird in Teillieferungen abgewickelt. +Fakt: `ForwardReceipt` enthält die Regionen „Partial Commission Alternative Delivery Address" (Zeile 2697) und „Warn user when Forwarding an Order to DeliveryList, ignoring the PartialCommissionOrders" (Zeile 2669); `PartialCommissionOrderBL` verwaltet die Teilkommissionen. +Aussage: Das System soll Teilkommissionen mit jeweils eigener Lieferadresse führen und den Anwender warnen, wenn beim Weiterführen eines Auftrags bestehende Teilkommissionen unberücksichtigt bleiben. +Ergebnis: Teillieferungen gehen an die jeweils richtige Adresse; abweichende Weiterführungen werden angezeigt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Regionen ab Zeile 2669 und 2697 - Begründung: Warnung und Adressübernahme sind dort implementiert. + - [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/Commissions/PartialCommissionOrderBL.cs` - Begründung: Verwaltung der Teilkommissionen. +Prüfidee: Beim Weiterführen eines Auftrags mit zwei Teilkommissionen muss eine Warnung erscheinen. +Tracelinks: StRS-023, SyRS-018, SwRS-064 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Standard im Projektgeschäft. +Status: belegt +``` + +``` +ID: SyRS-064 +Titel: Rollen von Systemartikeln +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Systemartikel sind konfiguriert. +Fakt: `ArticleBL` liefert über eigene Methoden reservierte Artikel: `GetFlatrateBalanceArticle` (143), `GetContractBalanceArticle` (151), `GetFreightArticle` (166), `GetCustomerDiscountArticle` (190), `GetArticleForExternalArticles` (223), `GetArticleI3DForNewArticles` (215), `GetVoucherArticleList` (235); `IsArticleAServiceArticle(int articleI3D, int? serviceMaterialGroupId)` erkennt Dienstleistungsartikel über die Warengruppe. +Aussage: Das System soll einzelne Artikel als Systemartikel für Fracht, Rabatt, Kontingentsaldo, Pauschalsaldo, Fremdartikel, Neuartikel und Gutscheine kennzeichnen und diese Rollen zentral auflösen. +Ergebnis: Automatisch erzeugte Positionen verwenden den jeweils konfigurierten Systemartikel. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, Methoden Zeilen 143-235 - Begründung: die Methoden lösen die Artikelrollen tatsächlich auf. +Prüfidee: Wird der Frachtartikel geändert, muss eine neu erzeugte Frachtposition den neuen Artikel verwenden. +Tracelinks: SyRS-011, SyRS-031, SwRS-065 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als benannte Systemartikel-Konfiguration. +Status: belegt +``` + +``` +ID: SyRS-065 +Titel: Artikelbezogene Sichtbarkeits- und Sperrsteuerung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Artikel wird aufgerufen. +Fakt: `ArticleBL.HasUserArticleRights(LoggedInUser loggedInUser, int articleI3D)` liefert einen Wahrheitswert für den Zugriff auf einen einzelnen Artikel; zusätzlich bestehen die Tabellen `Produktfamilie`, `ProduktfamilieKundenSperren` und `ProduktfamiliePositionSperren`. +Aussage: Das System soll den Zugriff auf einzelne Artikel benutzerbezogen prüfen und Produktfamilien für einzelne Kunden sperren können. +Ergebnis: Gesperrte Artikel erscheinen weder in der Suche noch in Belegen des betroffenen Kunden. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `HasUserArticleRights`, Zeile 129 - Begründung: die Methode ist die vorgesehene Prüfstelle für den Artikelzugriff. + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `ProduktfamilieKundenSperren`, `ProduktfamiliePositionSperren` - Begründung: die Sperren sind als Relation im Schema durchgesetzt. +Prüfidee: Ein für Kunde A gesperrter Artikel darf in einem Beleg für Kunde A nicht auswählbar sein. +Tracelinks: StRS-031, SwRS-066 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Vertriebssteuerung. +Status: belegt +``` + +``` +ID: SyRS-066 +Titel: Mengeneinheiten und Umrechnung +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Lagerist +Vorbedingung: Ein Artikel wird in unterschiedlichen Einheiten geführt. +Fakt: Es bestehen `ArticleUnitBL`, `ArticleUnitHelper` und die Tabelle `ArtikelEinheit`. +Aussage: Das System soll je Artikel mehrere Mengeneinheiten mit Umrechnungsfaktor führen und Bestände in der Basiseinheit fortschreiben. +Ergebnis: Bestände sind unabhängig von der Erfassungseinheit korrekt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Warehousing/ArticleUnitBL.cs`, `ArticleUnitHelper.cs` - Begründung: realisieren die Einheitenbehandlung. + - [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `ArtikelEinheit` - Begründung: Einheiten sind persistiert. +Prüfidee: Die Erfassung von 2 Kartons zu je 10 Stück muss den Bestand um 20 Stück erhöhen. +Tracelinks: StRS-021, SwRS-067 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Handel unverzichtbar. +Status: belegt +``` + +``` +ID: SyRS-067 +Titel: Versandabwicklung über externe Dienstleister +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Versand +Vorbedingung: Für die Versandart ist ein Dienstleister konfiguriert. +Fakt: Es bestehen die Bibliotheken `Centron.Api.Gls` (mit `CentronGlsLogic`, `CentronGlsErrors`, `Entities/Address`) und `Centron.Api.Shipcloud` (mit `CentronShipcloudLogic`, `AdditionalService`, `Billing`); im Belegkern existiert `ShipcloudPackageTemplateBL` samt `ShipcloudPackageTemplatesController`; die Einstellungsseiten `GlsSettingController` und `ShipcloudSettingController` sind registriert. +Aussage: Das System soll Versandaufträge an GLS und Shipcloud übergeben, Versandlabel abrufen und Paketvorlagen je Beleg verwenden. +Ergebnis: Zum Lieferschein liegt ein Versandlabel und eine Sendungsnummer vor. +Belege: + - [PRIMÄR] `src/apis/Centron.Api.Gls/CentronGlsLogic.cs`, `src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs` - Begründung: realisieren die Aufrufe an die Dienstleister. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ShipcloudPackageTemplateBL.cs` - Begründung: verwaltet die Paketvorlagen im Belegkontext. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Settings/GLS/`, `.../Shipcloud/` - Begründung: eigene Konfigurationsseiten je Dienstleister. +Prüfidee: Ein Versandauftrag mit gültiger Konfiguration muss eine Sendungsnummer liefern; bei fehlerhafter Adresse muss die Fehlermeldung des Dienstleisters angezeigt werden. +Tracelinks: StRS-004, SwRS-068 +Konsolidierung: Kandidat: SwRS-068 — GLS und Shipcloud sind zwei getrennte Implementierungen derselben Fachfunktion „Versandauftrag erzeugen". +Übernahmewürdigkeit: übernehmen - im Zielsystem hinter einer gemeinsamen Versandschnittstelle. +Status: belegt +``` + +``` +ID: SyRS-068 +Titel: Versandbestätigung an den Kunden +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Kunde +Vorbedingung: Ein Lieferschein ist versandt. +Fakt: Es besteht die Einstellungsseite `SendDeliveryListShippingConfirmationSettings/General/` mit `SendDeliveryListShippingConfirmationGeneralSettingsAppModueController`, registriert in `ModuleRegistration.GetSettingsWithoutModule()`. +Aussage: Das System soll nach dem Versand eines Lieferscheins eine konfigurierbare Versandbestätigung an den Kunden senden. +Ergebnis: Der Kunde ist über den Versand informiert. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Eintrag `new SendDeliveryListShippingConfirmationGeneralSettingsAppModueController()` - Begründung: die Einstellungsseite ist fest registriert und schaltet die Funktion. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Administration/SendDeliveryListShippingConfirmationSettings/General/` - Begründung: enthält die Konfigurationsfelder. +Prüfidee: Bei aktivierter Einstellung muss der Versand eines Lieferscheins eine E-Mail an den Kunden auslösen. +Tracelinks: SyRS-067, StRS-040, SwRS-069 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kundenerwartung. +Status: belegt +``` + +## 6. Einkauf und Datenaustausch + +``` +ID: SyRS-070 +Titel: Erkennung doppelter Lieferantenrechnungsnummern +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Eine Lieferantenrechnung wird erfasst. +Fakt: `ReceiptBL.ExternalReceiptNumberAlreadyExists(string externalNumber)` prüft, ob eine externe Belegnummer bereits vorliegt; `GetDuplicateSupplierExternalInvoiceReceiptDescription(string externalInvoiceNumber)` liefert eine Beschreibung des bereits erfassten Belegs. +Aussage: Das System soll bei der Erfassung einer Lieferantenrechnung prüfen, ob deren externe Nummer bereits vorliegt, und den bereits erfassten Beleg benennen. +Ergebnis: Doppelerfassungen von Lieferantenrechnungen werden erkannt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ExternalReceiptNumberAlreadyExists` (Zeile 5082) und `GetDuplicateSupplierExternalInvoiceReceiptDescription` (Zeile 5095) - Begründung: die Methoden führen die Dublettenprüfung durch. +Prüfidee: Die zweite Erfassung derselben Lieferantenrechnungsnummer muss einen Hinweis auf den bestehenden Beleg erzeugen. +Tracelinks: StRS-024, SwRS-070 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Schutz vor Doppelzahlung. +Status: belegt +``` + +``` +ID: SyRS-071 +Titel: Protokollierung aller EDI-Übertragungen +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Eine EDI-Übertragung findet statt. +Fakt: `EDILogBL` schreibt Protokolleinträge; `EDIDispatcherBL` verteilt die Vorgänge auf die distributorspezifischen Implementierungen; `EDIGatewaySettingBL` hält die Verbindungsparameter; `EDICommonBL` bündelt gemeinsame Funktionen. +Aussage: Das System soll jede EDI-Übertragung mit Zeitpunkt, Richtung, Lieferant und Ergebnis protokollieren. +Ergebnis: Übertragungsfehler sind im Nachhinein feststellbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/EDI/EDILogBL.cs` - Begründung: das Protokoll ist als eigene Komponente realisiert und wird vom Dispatcher aufgerufen. + - [SEKUNDÄR] `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs`, `EDIGatewaySettingBL.cs` - Begründung: Verteilung und Konfiguration. +Prüfidee: Eine fehlgeschlagene Übertragung muss einen Protokolleintrag mit Fehlerkennzeichen erzeugen. +Tracelinks: StRS-025, StRS-051, SwRS-071 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Nachweispflicht gegenüber Lieferanten. +Status: belegt +``` + +``` +ID: SyRS-072 +Titel: Distributorspezifische EDI-Ausprägungen +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Distributor +Vorbedingung: Ein Distributor ist angebunden. +Fakt: Der EDI-Zweig enthält je Distributor ein eigenes Verzeichnis: `ALSO`, `AlsoCH`, `Alltron`, `Komsa`, `EGIS`, `Concerto`, ergänzt um das Format `Opentrans21`, den Zweig `SupplierEDI` und `Import`. +Aussage: Das System soll je Distributor eine eigene Ausprägung des Datenaustauschs unterstützen und dabei ein gemeinsames Format (openTRANS 2.1) verwenden, sofern der Distributor es anbietet. +Ergebnis: Jeder angebundene Distributor wird im von ihm geforderten Format bedient. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/EDI/ALSO/`, `AlsoCH/`, `Alltron/`, `Komsa/`, `EGIS/`, `Concerto/`, `Opentrans21/` - Begründung: die getrennten Implementierungen belegen die distributorspezifischen Ausprägungen. + - [KONTEXT] `docs/reference/edi/edi-import-rules.md`, `docs/reference/edi/edi-architecture.md` - Begründung: beschreiben Aufbau und Importregeln. +Prüfidee: Für jeden konfigurierten Distributor muss eine Testbestellung im jeweiligen Format erzeugt werden können. +Tracelinks: StRS-025, SwRS-072 +Konsolidierung: Kandidat: SwRS-072 — die sechs Distributoranbindungen enthalten gleichartige Grundfunktionen in getrennten Implementierungen. +Übernahmewürdigkeit: übernehmen - im Zielsystem mit gemeinsamem Kern und dünnen Adaptern. +Status: belegt +``` + +``` +ID: SyRS-073 +Titel: Bezug von Produktdaten externer Kataloge +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Ein Katalogzugang ist konfiguriert. +Fakt: Es bestehen vier Katalog-Bibliotheken: `Centron.APIs.ITscopeDataAccess` (u. a. `ITscopeApiKeyQuota`, `Product`, `OrderInfo`), `Centron.APIs.IcecatDataAccess` (`ProductDescription`, `ProductImage`, `ProductProperty`), `Centron.APIs.CopDataAccess` (`Price`, `Supplier`) und `Centron.APIs.EgisDataAccess` (`PriceAndAvailability`, `DistributorItem`). +Aussage: Das System soll Produktstammdaten, Beschreibungen, Bilder, Preise und Verfügbarkeiten aus externen Katalogen beziehen und in den Artikelstamm übernehmen. +Ergebnis: Artikel sind mit Katalogdaten angereichert. +Belege: + - [PRIMÄR] `src/apis/Centron.APIs.ITscopeDataAccess/Data/`, `Centron.APIs.IcecatDataAccess/Data/`, `Centron.APIs.CopDataAccess/Data/`, `Centron.APIs.EgisDataAccess/Data/` - Begründung: die Datenklassen benennen die tatsächlich bezogenen Inhalte. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Settings/ICEcat/` - Begründung: eigene Konfigurationsseite. + - [SEKUNDÄR] `tests/apis/Centron.APIs.ITscopeDataAccess.Tests/`, `Centron.APIs.IcecatDataAccess.Tests/`, `Centron.APIs.CopDatabase.Tests/`, `Centron.APIs.EgisDataAccess.Tests/` - Begründung: für jede Katalogschnittstelle bestehen eigene Testprojekte. +Prüfidee: Ein über die Katalogsuche übernommener Artikel muss Herstellernummer, Beschreibung und Bild aus dem Katalog tragen. +Tracelinks: StRS-024, SwRS-073 +Konsolidierung: Kandidat: SwRS-073 — vier Katalogschnittstellen mit gleichartiger Aufgabe. +Übernahmewürdigkeit: übernehmen - Datenqualität im Handel. +Status: belegt +``` + +``` +ID: SyRS-074 +Titel: Kontingentüberwachung externer Katalogzugriffe +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Zuverlässigkeit (Fehlertoleranz) +Akteur: System +Vorbedingung: Ein Katalogzugang mit Abrufkontingent ist konfiguriert. +Fakt: `Centron.APIs.ITscopeDataAccess/Data/ITscopeApiKeyQuota.cs` bildet das verbleibende Abrufkontingent des API-Schlüssels als eigene Datenstruktur ab. +Aussage: Das System soll das verbleibende Abrufkontingent externer Kataloge auswerten und bei Erschöpfung weitere Abrufe unterlassen statt in einen Fehlerzustand zu laufen. +Ergebnis: Ein erschöpftes Kontingent führt zu einer verständlichen Meldung, nicht zu Folgefehlern. +Belege: + - [PRIMÄR] `src/apis/Centron.APIs.ITscopeDataAccess/Data/ITscopeApiKeyQuota.cs` - Begründung: das Kontingent wird als eigene Datenstruktur ausgelesen und steht damit für eine Auswertung zur Verfügung. +Prüfidee: Bei aufgebrauchtem Kontingent muss die Artikelsuche eine Kontingentmeldung statt eines technischen Fehlers liefern. +Tracelinks: SyRS-073, SwRS-074 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Robustheit gegenüber Fremdsystemen. +Status: belegt +``` + +``` +ID: SyRS-075 +Titel: Bestellvorschläge aus Bedarf und Bestand +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Aufträge und Bestände sind erfasst. +Fakt: Es bestehen `Purchasing/OrderSuggestionList/` im Backend und das Modul `OrderSuggestionListAppModuleController` in der Oberfläche, registriert in der Region „Einkauf". +Aussage: Das System soll aus offenen Bedarfen und aktuellen Beständen Bestellvorschläge ermitteln und diese in Lieferantenbestellungen überführen. +Ergebnis: Der Einkäufer erhält eine bestellfähige Vorschlagsliste. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Purchasing/OrderSuggestionList/` - Begründung: enthält die Ermittlungslogik. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList/` - Begründung: die Bedienoberfläche. +Prüfidee: Ein Artikel mit offenem Auftragsbedarf oberhalb des Bestands muss in der Vorschlagsliste erscheinen. +Tracelinks: StRS-024, SwRS-075 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Disposition. +Status: belegt +``` + +``` +ID: SyRS-076 +Titel: Filialbezogene Aufteilung von Lieferantenbestellungen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Mehrere Filialen bestellen denselben Artikel. +Fakt: Es bestehen `Purchasing/SupplierOrderPerBranchBL.cs` und das Oberflächenmodul `DataExchange/SupplierOrderPerBranch/`. +Aussage: Das System soll Lieferantenbestellungen je Filiale getrennt führen oder eine Sammelbestellung filialbezogen aufteilen. +Ergebnis: Jede Filiale erhält die für sie bestimmten Positionen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Purchasing/SupplierOrderPerBranchBL.cs` - Begründung: realisiert die filialbezogene Aufteilung. +Prüfidee: Eine Sammelbestellung für zwei Filialen muss zwei filialbezogene Zuordnungen erzeugen. +Tracelinks: StRS-034, StRS-024, SwRS-076 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Filialgeschäft. +Status: belegt +``` + +## 7. Finanzen + +``` +ID: SyRS-080 +Titel: Kontenfindung nach Artikel, Warengruppe und Filiale +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Beleg wird an die Buchhaltung übergeben. +Fakt: Das Schema enthält drei Zuordnungstabellen: `ArtikelBranchErloeskonto` (Artikel/Filiale), `UnterwarenFilialeErloeskonto` (Untergruppe/Filiale) und `WarenFilialeErloeskonto` (Warengruppe/Filiale); zusätzlich besteht `BranchRevenueAndExpenseAccountBL` je Filiale. +Aussage: Das System soll das Erlöskonto einer Belegposition aus der spezifischsten vorhandenen Zuordnung ermitteln und andernfalls auf die nächsthöhere Ebene zurückfallen. +Ergebnis: Jede Belegposition trägt genau ein Erlöskonto. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `ArtikelBranchErloeskonto`, `UnterwarenFilialeErloeskonto`, `WarenFilialeErloeskonto` - Begründung: die drei Ebenen der Kontenzuordnung sind im Schema angelegt und damit durchgesetzt. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Company/BranchRevenueAndExpenseAccountBL.cs` - Begründung: verwaltet die filialbezogenen Konten. + - [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleBranchAccountBL.cs` - Begründung: verwaltet die artikelbezogene Ebene. +Prüfidee: Ein Artikel mit eigenem Filialkonto muss dieses und nicht das Warengruppenkonto im Export tragen; die Rangfolge ist an einem Beleg mit allen drei Zuordnungen zu prüfen. +Tracelinks: StRS-027, SyRS-009, SwRS-080 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - steuerliche Kontierung. +Status: belegt +``` + +``` +ID: SyRS-081 +Titel: Erfassung des Bezahltstatus mit Herkunftsangabe +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Zahlungseingang liegt vor. +Fakt: `ReceiptBL.UpdateReceiptIsPaid(CentronObjectKindNumeric receiptKind, int receiptI3D, bool? isPaid, decimal? paidFC, Guid? concurrencyControlGuid, string moduleOrAction, AppUser currentUser)` prüft `CanUserEditReceipt` und übernimmt zusätzlich zu Status und Betrag die Angabe `moduleOrAction`, die das auslösende Modul festhält. +Aussage: Das System soll den Bezahltstatus einer Rechnung mit Betrag und auslösendem Modul festhalten und die Änderung nur mit Bearbeitungsrecht zulassen. +Ergebnis: Zu jedem Zahlungsstatuswechsel ist bekannt, aus welchem Vorgang er stammt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptIsPaid`, Zeile 4902, mit vorangehendem `CanUserEditReceipt` (Zeile 4921) - Begründung: Rechteprüfung und Herkunftsangabe sind dort durchgesetzt. +Prüfidee: Eine über das Online-Banking ausgelöste Ausgleichsbuchung muss `moduleOrAction` mit dem Bankmodul füllen. +Tracelinks: StRS-028, StRS-051, SwRS-081 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Nachvollziehbarkeit von Zahlungsbuchungen. +Status: belegt +``` + +``` +ID: SyRS-082 +Titel: Prüfung und Vorschau vor dem Mahnlauf +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Mahnlauf soll gestartet werden. +Fakt: `DunningRunBL.ValidateDunningReports()` liefert ein `DunningReportValidationResultDTO`; `GetPreviewForDunningRun(DunningRunForCustomer, LoggedInUser)` erzeugt eine Vorschau, getrennt von `ExecuteDunningRun`, das die Mahnstufe erhöht. +Aussage: Das System soll vor einem Mahnlauf prüfen, ob für alle Mahnstufen Formulare hinterlegt sind, und eine Vorschau des Laufs ohne Statusänderung ermöglichen. +Ergebnis: Ein Mahnlauf startet nur mit vollständigen Formularen; die Vorschau ändert keine Mahnstufe. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs`, `ValidateDunningReports` (Zeile 148), `GetPreviewForDunningRun` (Zeile 162) und `ExecuteDunningRun` (Zeile 179) als getrennte Methoden - Begründung: die Trennung von Vorschau und Ausführung ist im Code durchgesetzt; nur `ExecuteDunningRun` enthält die Stufenerhöhung. +Prüfidee: Eine Vorschau darf die Mahnstufe der enthaltenen Rechnungen nicht verändern. +Tracelinks: StRS-029, SwRS-082 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Schutz vor fehlerhaften Mahnungen. +Status: belegt +``` + +``` +ID: SyRS-083 +Titel: Rücknahme eines Mahnlaufs um genau eine Stufe +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Mahnlauf wurde ausgeführt. +Fakt: `DunningRunBL.ResetDunningRun(int dunningRunNumber, LoggedInUser)` setzt je Rechnung die Mahnstufe um genau eine Stufe zurück (Level3 → Level2, Level2 → Level1, Level1 → None) und löscht das zugehörige Stufendatum sowie den Stufenbearbeiter; für `DunningLevel.None` erfolgt keine Änderung. +Aussage: Das System soll einen ausgeführten Mahnlauf über seine Laufnummer zurücknehmen und dabei je Rechnung genau eine Mahnstufe zurücksetzen. +Ergebnis: Der Mahnstand entspricht wieder dem Zustand vor dem Lauf. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs`, `ResetDunningRun`, Zeilen 495-545, `switch (invoice.DunningLevel)` mit den drei Rücksetzzweigen - Begründung: die Verzweigung ist die durchsetzende Stelle der Rücknahme. +Prüfidee: Nach der Rücknahme eines Laufs, der von Stufe 1 auf 2 gehoben hat, muss Stufe 1 mit gefülltem `DunningLevel1Date` und leerem `DunningLevel2Date` vorliegen. +Tracelinks: StRS-029, SyRS-082, SwRS-082 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Korrekturfähigkeit. +Status: belegt +``` + +``` +ID: SyRS-084 +Titel: Keine Mahnstufensperre auf der Lieferantenseite +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Einkäufer +Vorbedingung: Ein Geschäftspartner ist zugleich Kunde und Lieferant. +Fakt: `ReceiptBL.GetCustomerOrSupplierDunningLevel` gibt für Lieferantenbelege stets 0 zurück (`if (typeof(TReceipt).GetReceiptKind().IsSupplierReceipt()) return 0;`); ein Kommentar beschreibt den ungeklärten Fall eines Partners mit beiden Rollen. +Aussage: Das System soll Bestellungen bei einem Lieferanten unabhängig von dessen Mahnstufe auf der Kundenseite zulassen. +Ergebnis: Die Beschaffung wird durch offene Forderungen gegen denselben Partner nicht blockiert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `GetCustomerOrSupplierDunningLevel`, Zeilen 2233-2240 der Methode (frühzeitige Rückgabe 0 für Lieferantenbelege) - Begründung: die Bedingung setzt die Ausnahme tatsächlich durch. + - [KONTEXT] ebenda, Kommentar „Do we then still want to order stuff on the supplier-side of him? Right now I don't know, but something to keep in mind in the future" - Begründung: dokumentiert die offene fachliche Entscheidung. +Prüfidee: Ein Partner mit Mahnstufe 3 auf der Kundenseite muss weiterhin als Lieferant bestellbar sein. +Tracelinks: StRS-030, StRS-001, SwRS-083 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem ist die Rollenwirkung ausdrücklich zu entscheiden. +Status: belegt +``` + +``` +ID: SyRS-085 +Titel: SEPA-Mandate an Vertrag und Beleg +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Lastschriftverfahren ist vereinbart. +Fakt: `ReceiptContract` führt das Feld `MandatI3D`; `ForwardReceipt` enthält die Region „Mandat" (Zeile 2831); die Einstellungsseite `SepaContractSettingsAppModuleController` ist registriert; `Accounting/BankAccountBL.cs` und die Tabelle `Bankverbindungen` halten die Bankdaten. +Aussage: Das System soll SEPA-Mandate verwalten, sie Verträgen und Belegen zuordnen und die Zuordnung beim Weiterführen eines Belegs übernehmen. +Ergebnis: Der zur Einziehung bestimmte Beleg trägt das gültige Mandat. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ForwardReceipt`, Region „Mandat", Zeile 2831 - Begründung: die Mandatsübernahme in den Folgebeleg erfolgt dort. + - [PRIMÄR] `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs`, Feld `MandatI3D` - Begründung: das Mandat ist am Vertrag persistiert. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Administration/SepaContract/` - Begründung: Pflegeoberfläche der Mandate. +Prüfidee: Eine aus einem Vertrag mit Mandat erzeugte Rechnung muss dasselbe Mandat tragen. +Tracelinks: StRS-008, StRS-029, SwRS-084 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - gesetzliche Voraussetzung für Lastschriften. +Status: belegt +``` + +``` +ID: SyRS-086 +Titel: Kontoumsatzabruf über finAPI mit eigenem Recht +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Ein Bankzugang ist über finAPI eingerichtet. +Fakt: `Centron.APIs.FinAPI` enthält `AccessToken`, `Account`, `AccountCapability`, `AccountInterface`, `AccountInterfacePaymentCapabilities`, `AccountList`, `AccountReference`; im Backend besteht `Finances/OnlineBanking/`, in der Oberfläche `OnlineBanking/ConfigurationSettings/`; im Rechtebaum besteht `UserRightsConst.Controlling.Finances.OnlineBanking` (Zeile 2564). +Aussage: Das System soll Bankkonten über finAPI anbinden, Umsätze abrufen und den Zugriff an ein eigenes Recht binden. +Ergebnis: Kontoumsätze stehen berechtigten Benutzern für den Ausgleich offener Posten zur Verfügung. +Belege: + - [PRIMÄR] `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs`, Klasse `Controlling.Finances.OnlineBanking`, Zeile 2564 - Begründung: eigener Rechtezweig schützt den Bankzugriff. + - [PRIMÄR] `src/apis/Centron.APIs.FinAPI/Data/AccessToken.cs`, `AccountList.cs` - Begründung: benennen die tatsächlich abgerufenen Bankdaten und das verwendete Zugriffstoken. + - [SEKUNDÄR] `src/backend/Centron.BL/Finances/OnlineBanking/` - Begründung: Anbindung im Backend. +Prüfidee: Ohne das Online-Banking-Recht darf die Kontoumsatzansicht nicht erreichbar sein. +Tracelinks: StRS-028, StRS-031, SwRS-085 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Bankdaten sind besonders schutzbedürftig. +Status: belegt +``` + +``` +ID: SyRS-087 +Titel: Protokoll der Zahlungseingänge mit eigener Laufnummer +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Zahlungseingänge werden erfasst. +Fakt: `IncomingPaymentBL.GetNewIncomingPaymentLogNumber()` vergibt eine Laufnummer, `CreateIncomingPaymentLogItem(IncomingPaymentLog logItem)` schreibt den Protokolleintrag, `GetIncomingPaymentLogOverview(bool? directDebitCreated)` filtert nach erzeugter Lastschrift. +Aussage: Das System soll Zahlungseingänge in nummerierten Läufen protokollieren und ausweisen, ob zu einem Lauf bereits eine Lastschrift erzeugt wurde. +Ergebnis: Jeder Zahlungseingangslauf ist eindeutig identifizierbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentBL.cs`, `GetNewIncomingPaymentLogNumber` (Zeile 30) und `GetIncomingPaymentLogOverview` (Zeile 35) - Begründung: Nummernvergabe und Filter sind dort implementiert. +Prüfidee: Zwei aufeinanderfolgende Läufe müssen verschiedene Laufnummern erhalten. +Tracelinks: StRS-028, SwRS-086 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Nachvollziehbarkeit. +Status: belegt +``` + +``` +ID: SyRS-088 +Titel: Erzeugung von Zahlungsverkehrsdateien +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Buchhaltung +Vorbedingung: Zahlungen sind freigegeben. +Fakt: Es bestehen `DataExchange/PaymentTransactions/` im Backend sowie die Oberflächen `DataExchange/PaymentTransactions/` und `PaymentTransactions/GFK/` mit dem registrierten `GfkSettingController`. +Aussage: Das System soll aus freigegebenen Zahlungen bankfähige Zahlungsverkehrsdateien erzeugen. +Ergebnis: Die Datei kann im Bankprogramm eingelesen werden. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/DataExchange/PaymentTransactions/` - Begründung: enthält die Erzeugungslogik. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/DataExchange/PaymentTransactions/` - Begründung: Bedienoberfläche des Vorgangs. +Prüfidee: Eine erzeugte Datei muss die Summe der freigegebenen Zahlungen enthalten. +Tracelinks: StRS-028, SwRS-087 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Zahlungsabwicklung. +Status: belegt +``` + +``` +ID: SyRS-089 +Titel: Produktlebenszyklus von Lizenzbeständen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: Beim Kunden sind Lizenzen im Einsatz. +Fakt: `Finances/ProductLifecycleBL.cs` bildet den Lebenszyklus ab; das Modul `PlmAppModuleController` wird nur bei Recht `CustomerCommon.LICENSE_MANAGEMENT` und Lizenz `LicenseGuids.PLM` registriert; ergänzend besteht das Modul `MSPLicensesCompare`. +Aussage: Das System soll Lizenzbestände beim Kunden mit Laufzeit und Ablauf führen, ablaufende Lizenzen ausweisen und Soll-Ist-Vergleiche gegen MSP-Daten ermöglichen. +Ergebnis: Ablaufende Lizenzen werden rechtzeitig erkannt. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Adressen/CRM", `ModuleRegistrationItem.For(() => Helper.HasRights(UserRightsConst.Sales.Customer.CustomerCommon.LICENSE_MANAGEMENT), () => LicenseManager.Instance.HasLicense(LicenseGuids.PLM))` - Begründung: Rechte- und Lizenzbedingung schalten das Modul tatsächlich frei. + - [SEKUNDÄR] `src/backend/Centron.BL/Finances/ProductLifecycleBL.cs`, `src/centron/Centron.WPF.UI/Modules/Global/MSPLicensesCompare/` - Begründung: Lebenszyklus und Abgleich. +Prüfidee: Eine in 30 Tagen ablaufende Kundenlizenz muss in der Ablaufliste erscheinen. +Tracelinks: StRS-036, StRS-049, SwRS-088 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Umsatzsicherung im Lizenzgeschäft. +Status: belegt +``` + +## 8. Sicherheit, Anmeldung, Administration + +``` +ID: SyRS-090 +Titel: Rechteermittlung ausschließlich über Gruppenzugehörigkeit +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Benutzer ist angemeldet. +Fakt: `AppRightsBL.GetRightsFromCurrentUser(AppUser user)` sammelt die Rechte über `foreach (AppGroup group in user.Groups) rights.AddRange(group.Rights)` und entfernt Dubletten; `CheckRightsFromUser(int appUserI3D, IList rightI3Ds)` prüft per SQL über `dbo.Sichtrus` und `dbo.Sichmemb`. +Aussage: Das System soll die Rechte eines Benutzers ausschließlich aus seinen Gruppenzugehörigkeiten ableiten; eine direkte Rechtevergabe an einen Benutzer ist nicht vorgesehen. +Ergebnis: Rechteänderungen wirken über die Gruppe auf alle Mitglieder. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `GetRightsFromCurrentUser`, Zeilen 63-84 - Begründung: die Schleife über die Gruppen ist die einzige Quelle der Rechteliste. + - [PRIMÄR] ebenda, `CheckRightsFromUser` mit `INNER JOIN dbo.Sichmemb sm ON sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D` - Begründung: die Abfrage verknüpft Benutzer und Recht ausschließlich über die Gruppe. +Prüfidee: Ein Benutzer ohne Gruppenzugehörigkeit darf keine Rechte besitzen. +Tracelinks: StRS-031, SwRS-090 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - klares Rollenmodell. +Status: belegt +``` + +``` +ID: SyRS-091 +Titel: Deklarative Rechteprüfung an REST-Endpunkten +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Fremdsystem +Vorbedingung: Ein REST-Endpunkt wird aufgerufen. +Fakt: `UserRightAuthorizationFilter.OnAuthorization` liest `context.HttpContext.User.GetCurrent()?.User`, liefert bei fehlendem Benutzer `UnauthorizedResult` (401) und bei fehlendem Recht `ForbidResult` (403); die Attribute `AuthorizeUserRight`, `AuthorizeAnyUserRight`, `AuthorizeAllUserRights` und `AuthorizeCentronHosted` stehen zur Verfügung. +Aussage: Das System soll den Zugriff auf REST-Endpunkte über deklarative Rechteattribute prüfen und dabei zwischen fehlender Anmeldung (401) und fehlender Berechtigung (403) unterscheiden. +Ergebnis: Ein nicht berechtigter Aufruf erreicht die Fachlogik nicht. +Belege: + - [PRIMÄR] `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs`, `UserRightAuthorizationFilter.OnAuthorization`, Zeilen 38-52 - Begründung: der Filter bricht die Anfrage vor der Aktionsmethode tatsächlich ab. + - [KONTEXT] `src/webservice/Centron.Controllers/Authorization/README.md`, Abschnitt „HTTP Response Codes" - Begründung: dokumentiert die vorgesehene Semantik. +Prüfidee: Ein Aufruf ohne Anmeldung muss 401, ein Aufruf ohne das geforderte Recht 403 liefern. +Tracelinks: StRS-031, SyRS-173, SwRS-091 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Standardmuster für die API-Absicherung. +Status: belegt +``` + +``` +ID: SyRS-092 +Titel: Filialbeschränkung als eigenständige Prüfstufe +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Benutzer besitzt ein einschränkendes Filialrecht. +Fakt: `ReceiptBL.CanUserCreateReceiptsInBranch` behandelt die Standardfiliale gesondert (`userBranchIsDefaultBranch && receiptBranchIsDefaultBranch` gilt als gleich) und vergleicht andernfalls `userBranchI3D == branchI3D`; `CanUserEditReceipt` verwendet `BranchBL.IsBranchEqual(appUser.Employee.BranchI3D, receiptBranchI3D)`. +Aussage: Das System soll die Filialbeschränkung als eigene Prüfstufe nach dem Basisrecht auswerten und dabei nicht gesetzte Filialangaben auf beiden Seiten als übereinstimmend behandeln. +Ergebnis: Benutzer ohne zugeordnete Filiale können Belege ohne Filialangabe bearbeiten. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserCreateReceiptsInBranch`, Zeilen 10258-10268 - Begründung: die Sonderbehandlung der Standardfiliale ist dort ausformuliert. +Prüfidee: Benutzer ohne Filiale und Beleg ohne Filiale: die Anlage muss gelingen; Benutzer der Filiale A und Beleg der Filiale B: die Anlage muss scheitern. +Tracelinks: StRS-032, StRS-034, SwRS-092 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Voraussetzung für Filialbetrieb. +Status: belegt +``` + +``` +ID: SyRS-093 +Titel: Hierarchische Nummernkreisauflösung über Mitarbeiter, Filiale und Mandant +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Belegnummer wird angefordert. +Fakt: `MandatoryBL.GetNumberGroup(NumberGroupEnum, int? currentEmployeeI3D, int? branchI3D)` bestimmt den Nummernkreis über eine SQL-Abfrage, die zuerst Mandant und Filiale des Mitarbeiters berücksichtigt (`ORDER BY CASE WHEN nu.MandantI3D=fm.I3D THEN 0 ELSE 1 END, nu.FilialI3D DESC`), Kreise mit der Beschreibung `[nicht verwendet]` ausschließt und nur Kreise mit `Current > 0` zurückgibt. +Aussage: Das System soll den Nummernkreis in der Rangfolge Mitarbeiterfiliale, Mandantsfiliale und Standardmandant auflösen und als „nicht verwendet" gekennzeichnete Kreise überspringen. +Ergebnis: Jeder Beleg erhält die Nummer des für ihn zuständigen Nummernkreises. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs`, `GetNumberGroup`, SQL mit `AND nu.Beschreibung <> '[nicht verwendet]'` und der genannten Sortierung - Begründung: die Abfrage setzt die Rangfolge tatsächlich durch. + - [SEKUNDÄR] ebenda, Verzweigung über `ModuleFeatures.IsNumberGroupRefactoringAvailable` - Begründung: belegt zwei parallel gepflegte Auflösungswege. +Prüfidee: Ein Mitarbeiter der Filiale B muss eine Rechnungsnummer aus dem Nummernkreis der Filiale B erhalten, sofern dieser gepflegt und `Current > 0` ist. +Tracelinks: StRS-034, StRS-035, SwRS-093 +Konsolidierung: Kandidat: SwRS-093 — die alte und die neue Auflösung (`IsNumberGroupRefactoringAvailable`) bilden dieselbe Fachfunktion doppelt ab. +Übernahmewürdigkeit: übernehmen - im Zielsystem mit nur einem Auflösungsweg. +Status: belegt +``` + +``` +ID: SyRS-094 +Titel: Kollisionsfreie Nummernvergabe bei gleichzeitigem Zugriff +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Zuverlässigkeit (Reife) +Akteur: System +Vorbedingung: Mehrere Benutzer fordern gleichzeitig eine Nummer derselben Nummernart an. +Fakt: `NumberGroupBL.GetNextNumber` wiederholt die Ermittlung in einer Endlosschleife, aktualisiert den Zähler nur mit der Bedingung `f.Current == numberGroupObject.Current` und akzeptiert das Ergebnis ausschließlich bei `rowCountChanged == 1`; vor jedem Versuch wird das Objekt über `Session.Refresh` neu geladen. +Aussage: Das System soll bei gleichzeitigen Nummernanforderungen durch eine bedingte Aktualisierung sicherstellen, dass jede Nummer genau einmal vergeben wird, und den Vorgang bei Kollision wiederholen. +Ergebnis: Es entstehen keine doppelten Belegnummern. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs`, `GetNextNumber`, Zeilen 67-91 mit `while (true)`, `Session.Refresh` und Auswertung von `rowCountChanged` - Begründung: das Muster ist die durchsetzende Stelle der Kollisionsfreiheit. + - [KONTEXT] ebenda, Kommentar „It is a safety measure, should someone in the meantime reserve this number" - Begründung: benennt die Absicht. +Prüfidee: Zwanzig gleichzeitige Anforderungen müssen zwanzig verschiedene Nummern liefern. +Tracelinks: StRS-035, SwRS-094 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als Datenbanksequenz zu lösen. +Status: belegt +``` + +``` +ID: SyRS-095 +Titel: Prüfung auf bereits belegte Nummern in der Zieltabelle +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Nummer wird ermittelt. +Fakt: `NumberGroupBL.FindNextNumber` erhöht den Zähler um das Intervall und prüft per `SELECT COUNT(*) AS cnt FROM {tableName} WHERE {fieldName} = {counter}`, ob die Nummer schon vergeben ist; für die Nummernarten `Customer` und `Supplier` erfolgt zusätzlich eine Prüfung in `dbo.Kunden` beziehungsweise `dbo.Kreditor`. Der Zähler wird dabei per String-Interpolation in das SQL eingesetzt. +Aussage: Das System soll vor der Vergabe einer Nummer prüfen, ob diese in der Zieltabelle bereits verwendet wird, und andernfalls zur nächsten Nummer weiterspringen. +Ergebnis: Bereits vorhandene Nummern werden nicht erneut vergeben. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs`, `FindNextNumber`, Zeilen 105-131 - Begründung: die Schleife mit der Existenzabfrage ist die durchsetzende Stelle. +Prüfidee: Wird eine Belegnummer manuell in die Zieltabelle eingetragen, muss die nächste automatische Vergabe diese Nummer überspringen. +Tracelinks: StRS-035, SyRS-094, SwRS-095 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - die tabellenweise Prüfung gleicht fehlende Datenbankbeschränkungen aus; im Zielsystem ist die Eindeutigkeit über eine Datenbankbedingung sicherzustellen. +Status: belegt +``` + +``` +ID: SyRS-100 +Titel: Sitzungsticket mit anwendungsabhängiger Gültigkeitsdauer +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Benutzer hat sich erfolgreich angemeldet. +Fakt: `TicketBL` definiert `TicketExpireInMinutes = 30`, `TicketMonitoringConnectorExpireInMinutes = 5` und `TicketExpire24HoursInMinutes = 1440`; `CreateNewTicket` setzt das Ablaufdatum über `GetExpireDate(applicationKind)` und einen `GetTicketSalt(deviceID)`; `DeleteExpiredTickets` entfernt abgelaufene Tickets. +Aussage: Das System soll je Anwendungsart eine eigene Ticketgültigkeit vergeben, abgelaufene Tickets zurückweisen und regelmäßig entfernen. +Ergebnis: Sitzungen enden nach der für die Anwendung festgelegten Zeit. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, Konstanten Zeilen 26-28 und `CreateNewTicket` Zeile 61 - Begründung: die Konstanten und die Erzeugung legen die Gültigkeit fest. + - [PRIMÄR] ebenda, `DeleteExpiredTickets` Zeile 31 - Begründung: entfernt abgelaufene Tickets. +Prüfidee: Ein Ticket der Standardanwendung muss 31 Minuten nach der letzten Verwendung abgelehnt werden. +Tracelinks: StRS-033, SwRS-100 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als Token mit Ablauf. +Status: belegt +``` + +``` +ID: SyRS-101 +Titel: Verzögerte Verlängerung der Ticketgültigkeit +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Performance-Effizienz (Ressourcennutzung) +Akteur: System +Vorbedingung: Ein gültiges Ticket wird verwendet. +Fakt: `TicketBL.RefreshTicketExpireDate(Ticket ticket)` aktualisiert das Ablaufdatum nur, wenn das neue Ablaufdatum mindestens fünf Minuten nach dem bisherigen liegt (`if ((newExpireDate - ticket.ExpiryDate).TotalMinutes < 5) return Result.AsSuccess();`); ein Kommentar räumt ein, dass Tickets dadurch in Randfällen früher ablaufen können. +Aussage: Das System soll das Ablaufdatum eines Tickets nur dann fortschreiben, wenn sich der Wert um mindestens fünf Minuten ändert, um Schreibzugriffe zu verringern. +Ergebnis: Die Zahl der Schreibvorgänge auf die Ticket-Tabelle sinkt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `RefreshTicketExpireDate`, Bedingung `< 5` - Begründung: die Bedingung unterdrückt die Aktualisierung tatsächlich. + - [KONTEXT] ebenda, Kommentar „there are some corner-cases where the ticket can expire with this optimization, where it wouldn't have expired previously" - Begründung: benennt die in Kauf genommene Nebenwirkung. +Prüfidee: Zwei Aufrufe im Abstand von einer Minute dürfen nur einen Schreibzugriff auf das Ablaufdatum erzeugen. +Tracelinks: SyRS-100, SwRS-100 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - eine Optimierung mit bewusst hingenommener Funktionsabweichung; im Zielsystem durch zustandslose Token zu ersetzen. +Status: belegt +``` + +``` +ID: SyRS-102 +Titel: Anwendungsbezogene Zugangsrechte bei der Anmeldung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Benutzer meldet sich an einer bestimmten Anwendung an. +Fakt: `Authenticator.ValidateRights(ApplicationKind applicationKind, LoggedInUser user)` verweigert die Anmeldung, wenn der Benutzer das `applicationKind.DisallowingRight` besitzt, und ebenso, wenn er das `applicationKind.RequiredRight` nicht besitzt; beide Fälle liefern `DefaultMessageCodes.RightCheckFailed`. +Aussage: Das System soll je Anwendung ein zwingend erforderliches und ein ausschließendes Recht auswerten und die Anmeldung an dieser Anwendung entsprechend zulassen oder verweigern. +Ergebnis: Ein Benutzer kann sich nur an den für ihn freigegebenen Anwendungen anmelden. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, `ValidateRights`, Zeilen 68-86 - Begründung: die beiden Prüfungen brechen die Anmeldung tatsächlich ab. + - [SEKUNDÄR] `src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs` - Begründung: definiert je Anwendung die beiden Rechte. +Prüfidee: Ein Benutzer mit dem ausschließenden Recht einer Anwendung darf sich dort nicht anmelden, an anderen Anwendungen aber schon. +Tracelinks: StRS-033, StRS-031, SwRS-101 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - feingranulare Zugangssteuerung. +Status: belegt +``` + +``` +ID: SyRS-103 +Titel: Lizenzprüfung mit Anzahl, Ablaufdatum und Versionsgrenze +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Eine Anwendung fordert eine Lizenz an. +Fakt: `LicenseManager.CheckLicense(ApplicationKind app, string applicationVersion, LoggedInUser user)` prüft die Lizenz-GUID der Anwendung, ihre `AdditionalLicenseGuids` und die `CustomerLoginLicenseGuid`; `HasLicense(Guid)` ruft `CheckLicenseVersion(licenseGuid, currentVersion)` auf und wertet eine `OfficeException` als „Lizenz nicht vorhanden"; `TryFixCentronDelphiVersionNumber` korrigiert Versionsnummern älterer Clients. +Aussage: Das System soll für jede Anwendung alle zugehörigen Lizenz-GUIDs prüfen und dabei Anzahl, Gültigkeitsdatum und maximal zulässige Programmversion berücksichtigen. +Ergebnis: Anwendungen ohne gültige Lizenz erhalten kein Sitzungsticket. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, `CheckLicense`, Zeilen 258-275 mit der Zusammenführung der Lizenzlisten - Begründung: die Methode ist die durchsetzende Stelle. + - [PRIMÄR] ebenda, `HasLicense`, Zeilen 243-256 mit `CheckLicenseVersion` und `catch (OfficeException) { return false; }` - Begründung: die Versionsprüfung ist Teil der Lizenzprüfung. + - [KONTEXT] `docs/reference/security/licensing-system.md` - Begründung: beschreibt Anzahl, Ablaufdatum und Versionsgrenze als Lizenzmerkmale. +Prüfidee: Ein Client mit einer Version oberhalb der Lizenzversionsgrenze muss abgewiesen werden. +Tracelinks: StRS-036, SwRS-102 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als Tarifprüfung. +Status: belegt +``` + +``` +ID: SyRS-104 +Titel: Wiederverwendung bestehender Sitzungen vor der Lizenzprüfung +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Benutzer meldet sich erneut an. +Fakt: `Authenticator.AuthenticateUser` sucht innerhalb eines `lock (_getExistingOrCreateTicketLock)` zuerst über `_ticketBl.GetExistingTicket(applicationKind, user, webAccount?.I3D, machineName)` ein bestehendes Ticket und gibt dieses unmittelbar zurück; erst wenn keines existiert, erfolgen Lizenzprüfung und Ticketerzeugung. `GetExistingTicket` verlängert dabei das Ablaufdatum. +Aussage: Das System soll einem Benutzer, der auf demselben Gerät bereits an derselben Anwendung angemeldet ist, das bestehende Ticket zurückgeben, ohne einen weiteren Lizenzplatz zu belegen. +Ergebnis: Wiederholte Anmeldungen desselben Benutzers verbrauchen keine zusätzlichen Lizenzen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, `AuthenticateUser`, Reihenfolge `GetExistingTicket` vor `LicenseManager.CheckLicense` innerhalb der Sperre - Begründung: die Reihenfolge ist die durchsetzende Stelle der Lizenzschonung. +Prüfidee: Zweimaliges Anmelden desselben Benutzers auf demselben Gerät muss dieselbe Ticket-ID liefern. +Tracelinks: StRS-037, SyRS-100, SwRS-103 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-105 +Titel: Zwei-Faktor-Authentifizierung als zweite Prüfstufe +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Benutzer +Vorbedingung: Für den Benutzer ist ein zweiter Faktor konfiguriert. +Fakt: `BasicAuthenticator.AuthenticateInternal` ruft nach erfolgreicher Kennwortprüfung `_twoFactorAuthBL.ValidateTwoFactor(Auth.UserName, Auth.Password, loggedInUser, Auth.ApplicationName, Auth.MachineName)` auf und liefert bei Misserfolg „Die Zwei-Faktor-Authentifizierung ist fehlgeschlagen." mit `DefaultMessageCodes.TwoFactorAuthFailed`; es bestehen `EmailTwoFactorValidator` und `RadiusTwoFactorValidator` mit eigenem `RadiusClient` und `RadiusPaketParser`. +Aussage: Das System soll nach erfolgreicher Kennwortprüfung einen zweiten Faktor per E-Mail oder RADIUS prüfen und die Anmeldung bei fehlgeschlagener Prüfung ablehnen. +Ergebnis: Ohne gültigen zweiten Faktor entsteht kein Sitzungsticket. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, Zeilen 61-70 - Begründung: die Prüfung erfolgt nach der Kennwortprüfung und verhindert die Ticketausgabe. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TwoFactor/EmailTwoFactorValidator.cs`, `RadiusTwoFactorValidator.cs` - Begründung: die beiden Verfahren sind eigenständig implementiert. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/Unversioned/TwoFactorAuthController.cs` - Begründung: eigener Endpunkt für den zweiten Faktor. +Prüfidee: Richtiges Kennwort und falscher zweiter Faktor müssen zur Meldung `TwoFactorAuthFailed` ohne Ticket führen. +Tracelinks: StRS-033, SwRS-104 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Sicherheitsanforderung im SaaS-Betrieb. +Status: belegt +``` + +``` +ID: SyRS-106 +Titel: Protokollierung von Anmeldeversuchen +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Eine Anmeldung wird versucht. +Fakt: `Authenticator.Authenticate` protokolliert „Authentication attempt received: {AuthObject}"; `AuthObject` enthält `RequestId`, `RemoteAddress`, `AppVersion`, `ApplicationName` und `MachineName`; `BasicAuthenticator` protokolliert Erfolg und Misserfolg getrennt; `TicketBL.SetLoginIP(AppUser user)` speichert die Client-IP am Benutzer, ersatzweise `"[unknown]"`. +Aussage: Das System soll jeden Anmeldeversuch mit Vorgangskennung, Benutzername, Anwendung, Programmversion, Rechnername und IP-Adresse protokollieren und erfolgreiche von fehlgeschlagenen Versuchen unterscheiden. +Ergebnis: Anmeldeversuche sind im Nachhinein auswertbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, `Authenticate` mit `Logger.Info("Authentication attempt received: {AuthObject}", Auth)` - Begründung: die Protokollierung erfolgt an dieser Stelle. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `SetLoginIP`, Zeilen 48-58 - Begründung: speichert die IP am Benutzerkonto. + - [SEKUNDÄR] `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, `Logger.Warn("Basic authentication failed for user: {UserName}. Context: {AuthObject}", …)` - Begründung: fehlgeschlagene Versuche werden gesondert protokolliert. +Prüfidee: Ein fehlgeschlagener Anmeldeversuch muss einen Warneintrag mit Benutzername und IP-Adresse erzeugen. +Tracelinks: StRS-033, StRS-051, SwRS-105 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Voraussetzung für Angriffserkennung. +Status: belegt +``` + +``` +ID: SyRS-107 +Titel: Kennwortspeicherung der Anwendungsbenutzer +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Benutzerkennwort wird geprüft oder gesetzt. +Fakt: `BasicAuthenticator.AuthenticateInternal` bildet `SHA1Decoder.GetDecodedSHA1String(Auth.Password)` und sucht den Benutzer über `where.Name == Auth.UserName && where.Password == decodedPassword`; `SHA1Decoder` berechnet einen ungesalzenen SHA-1-Hash über die Codepage-1252-Darstellung des Kennworts. Im Quelltext steht der Kommentar `// TODO the password should be salted!!!`. +Aussage: Das System soll Kennwörter der Anwendungsbenutzer nicht im Klartext speichern. Der eingesetzte ungesalzene SHA-1-Hash entspricht nicht dem Stand der Technik und ist im Zielsystem durch ein gesalzenes, rechenaufwendiges Verfahren zu ersetzen. +Ergebnis: Kennwörter liegen nicht im Klartext vor; die Absicherung gegen Wörterbuch- und Regenbogentabellenangriffe ist unzureichend. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, Zeilen 47-51, Vergleich `where.Password == decodedPassword` - Begründung: die Abfrage ist die durchsetzende Stelle der Kennwortprüfung. + - [PRIMÄR] `src/backend/Centron.Common/TextCoding/SHA1Decoder.cs`, `GetDecodedSHA1String` mit `SHA1.Create()` und `Encoding.GetEncoding(1252)` ohne Salt - Begründung: benennt das tatsächlich verwendete Verfahren. + - [KONTEXT] `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, Kommentar `// TODO the password should be salted!!!` - Begründung: die Schwäche ist im Code selbst vermerkt. +Prüfidee: Zwei Benutzer mit identischem Kennwort müssen im heutigen Stand denselben gespeicherten Hashwert tragen; im Zielsystem darf das nicht mehr der Fall sein. +Tracelinks: StRS-033, SwRS-106 +Konsolidierung: Kandidat: SyRS-122 — Anwendungsbenutzer und Web-Benutzer verwenden dasselbe unzureichende Verfahren an zwei Stellen. +Übernahmewürdigkeit: veraltet - das Verfahren ist fachlich erforderlich, in dieser Ausprägung jedoch überholt und im Zielsystem zu ersetzen. +Status: belegt +``` + +``` +ID: SyRS-108 +Titel: Symmetrische Verschlüsselung mit fest hinterlegtem Ersatzschlüssel +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Wert wird über `AESCryptoLogic` verschlüsselt. +Fakt: `AESCryptoLogic.GetKeyAndIV(string secret)` verwendet bei fehlendem Schlüssel die Konstante `private const string SECURITY_KEY = @"lugE!35Djn";`, leitet aus `SHA512.HashData(Encoding.ASCII.GetBytes(secret))` einen 32-Byte-Schlüssel ab und entnimmt den 16-Byte-Initialisierungsvektor ab Byte 5 desselben Hashes; `DecryptText` liefert bei Fehlern `string.Empty`. +Aussage: Das System soll vertrauliche Werte symmetrisch verschlüsseln. Der fest im Quelltext hinterlegte Ersatzschlüssel und der aus demselben Hash abgeleitete, damit je Schlüssel konstante Initialisierungsvektor sind im Zielsystem durch verwaltete Schlüssel und je Datensatz zufällige Initialisierungsvektoren zu ersetzen. +Ergebnis: Vertrauliche Werte liegen verschlüsselt vor; gleiche Klartexte ergeben mit demselben Schlüssel jedoch gleiche Chiffrate. +Belege: + - [PRIMÄR] `src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs`, Zeilen 77-92, `SECURITY_KEY` und `GetKeyAndIV` - Begründung: die Methode legt Schlüssel und Initialisierungsvektor tatsächlich fest. + - [PRIMÄR] ebenda, `DecryptText` mit `catch { return string.Empty; }` - Begründung: Entschlüsselungsfehler werden verschluckt statt gemeldet. +Prüfidee: Zweimaliges Verschlüsseln desselben Textes mit demselben Schlüssel muss im heutigen Stand dasselbe Chiffrat ergeben; im Zielsystem darf das nicht der Fall sein. +Tracelinks: StRS-047, StRS-059, SwRS-107 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - die Verschlüsselung ist fachlich erforderlich, das konkrete Verfahren im Zielsystem jedoch zu ersetzen. +Status: belegt +``` + +``` +ID: SyRS-109 +Titel: Erzeugung und Prüfung von API-Zugriffstoken +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Fremdsystem, Administrator +Vorbedingung: Die Lizenz `AccessTokenModule` liegt vor. +Fakt: `AccessTokenBL.GenerateSecureToken()` erzeugt 48 Zeichen aus einem 62-Zeichen-Alphabet mittels `RandomNumberGenerator`; `HashToken` bildet einen SHA-256-Hash; gespeichert wird ausschließlich `TokenHash`. Bei der Validierung werden `IsActive` und `IsExpired` geprüft und jeder Fehlschlag über `AccessTokenLogActionType.ValidationFailed` protokolliert. Die Erzeugung prüft zuvor `LicenseManager.Instance.HasLicense(LicenseGuids.AccessTokenModule)` und `LicenseCheckCanActivateMoreToken()`. +Aussage: Das System soll API-Zugriffstoken kryptografisch zufällig erzeugen, ausschließlich deren Hashwert speichern, Deaktivierung und Ablauf prüfen und jede fehlgeschlagene Prüfung protokollieren. +Ergebnis: Aus der Datenbank lässt sich kein gültiges Token rekonstruieren. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs`, `GenerateSecureToken` (Zeile 457) und `HashToken` (Zeile 480) - Begründung: benennen Zufallsquelle, Länge und Hashverfahren. + - [PRIMÄR] ebenda, Zeilen 394-406, Prüfungen `!token.IsActive` und `token.IsExpired` mit Protokollierung `ValidationFailed` - Begründung: die Prüfungen weisen ungültige Token tatsächlich ab. + - [SEKUNDÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `Administration.AccessTokens` mit `VIEW_ALL`, `EDIT_ALL`, `DEACTIVATE_ALL`, `DELETE_ALL`, `CREATE_PERSONAL` - Begründung: eigener Rechtezweig trennt persönliche von administrativen Token. +Prüfidee: Ein deaktiviertes Token muss abgewiesen und der Versuch protokolliert werden. +Tracelinks: StRS-031, StRS-036, SwRS-108 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - das Verfahren entspricht dem Stand der Technik. +Status: belegt +``` + +``` +ID: SyRS-110 +Titel: Erzeugung, Vorschau und Ablage von Belegdokumenten +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg ist gespeichert. +Fakt: `ReceiptBL.CreateFullReportForReceipt(CentronObjectKindNumeric receiptKind, int receiptI3D, IList layoutItems, IReceiptBase receipt, ReportAction reportAction, ReportData report, ReportGroup reportGroup, bool addReportPdfToReceiptDocuments, LoggedInUser loggedInUser, CreateFullReportConfiguration configuration, bool ignoreReportGroupExport)` erzeugt das Dokument; `CreateReportPreviewForReceipt` liefert eine Vorschau als `byte[]`; `AddReportToReceiptDocuments(IReceiptBase receipt, byte[] reportPdf, AppUser currentUser)` legt es ab. +Aussage: Das System soll Belegdokumente aus einer Formularvorlage und einem Belegprojekt-Layout erzeugen, wahlweise als Vorschau ausgeben und auf Wunsch in der Belegablage speichern. +Ergebnis: Das Belegdokument steht als PDF zur Verfügung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CreateFullReportForReceipt` (Zeile 3221), `CreateReportPreviewForReceipt` (Zeile 3177), `AddReportToReceiptDocuments` (Zeile 3459) - Begründung: die drei Methoden realisieren Erzeugung, Vorschau und Ablage. + - [SEKUNDÄR] `src/backend/Centron.BL/ReportEngine/FastReportHelper.cs`, `PdfExport/`, `CustomPdfGenerators/` - Begründung: die eingesetzte Formularmaschine und die PDF-Erzeugung. +Prüfidee: Bei `addReportPdfToReceiptDocuments = true` muss nach dem Druck ein PDF in der Belegablage liegen. +Tracelinks: StRS-038, SwRS-110 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Belegausgabe. +Status: belegt +``` + +``` +ID: SyRS-111 +Titel: Auflösung von Objektverzeichnissen über Referenzanbieter +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein Dokument soll abgelegt oder gelesen werden. +Fakt: `Administration/FileManagement` enthält `GetDirectoryByReferenzBL`, `DirectoryReferenceBL` und ein Verzeichnis `DirectoryReferenceProviders`; `SystemDirectoryNames` benennt feste Systemverzeichnisse, `CreateIndexNameBlacklist` schließt bestimmte Namen von der Indizierung aus; `SharedDocumentBL` und `EdiDocumentBL` behandeln geteilte und EDI-Dokumente gesondert. +Aussage: Das System soll das Zielverzeichnis eines Dokuments über je Objektart eigene Referenzanbieter bestimmen und dabei feste Systemverzeichnisnamen verwenden. +Ergebnis: Dokumente landen unabhängig von der aufrufenden Stelle im selben Verzeichnis. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/FileManagement/GetDirectoryByReferenzBL.cs` und `DirectoryReferenceProviders/` - Begründung: die Auflösung ist als eigener, je Objektart erweiterbarer Mechanismus implementiert. + - [SEKUNDÄR] `src/backend/Centron.BL/Administration/FileManagement/SystemDirectoryNames.cs`, `CreateIndexNameBlacklist.cs` - Begründung: benennen die festen Verzeichnisnamen und die Indizierungsausnahmen. +Prüfidee: Dasselbe Ticket muss aus dem Rich-Client und aus der Weboberfläche dasselbe Dokumentenverzeichnis liefern. +Tracelinks: StRS-039, SwRS-111 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als Objektspeicher. +Status: belegt +``` + +``` +ID: SyRS-112 +Titel: Unterdrückung des Versands an externe Empfänger außerhalb von Freigabeversionen +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Entwickler, Betrieb +Vorbedingung: Eine E-Mail wird versandt. +Fakt: `DeveloperSecurity.Email.ValidateAddress(string emailAddress)` gibt die Adresse unverändert zurück, wenn `AllowSendingEmailToExternalAddresses` gilt (Wert aus `DebugHelper.IsReleaseBuild()`) oder die Adresse auf `nexoware.com` endet, und ersetzt sie andernfalls durch `test@nexoware.com`. +Aussage: Das System soll in Nicht-Freigabeversionen alle externen E-Mail-Empfänger durch eine feste interne Ersatzadresse ersetzen, damit Testläufe keine Nachrichten an Kunden auslösen. +Ergebnis: Aus Entwicklungs- und Testumgebungen erreichen keine E-Mails externe Empfänger. +Belege: + - [PRIMÄR] `src/backend/Centron.Common/DeveloperSecurity.cs`, `ValidateAddress`, Zeilen 30-45, mit `ReplacementEmailAddress = "test@nexoware.com"` und `InternalEmailAddressDomain = "nexoware.com"` - Begründung: die Methode ersetzt die Adresse tatsächlich. +Prüfidee: In einer Debug-Übersetzung muss eine Mail an eine Kundenadresse an `test@nexoware.com` gehen. +Tracelinks: StRS-040, StRS-052, SwRS-112 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als umgebungsabhängige Konfiguration statt als Übersetzungsschalter. +Status: belegt +``` + +``` +ID: SyRS-113 +Titel: Belegartabhängige Absenderadresse +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Ein Beleg wird per E-Mail versandt. +Fakt: Jede Belegartlogik implementiert `GetDefaultMailSender()`: `InvoiceSpecificLogic` liefert `InvoiceAndCreditVouchersSenderEmailAddress`, `OrderSpecificLogic` liefert `OrderSenderEmailAddress`; die Werte stammen aus `MailSettingsBL.GetMailSettings()`. +Aussage: Das System soll je Belegart eine eigene Absenderadresse verwenden und diese zentral in den Mail-Einstellungen pflegen. +Ergebnis: Antworten des Kunden erreichen die fachlich zuständige Stelle. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, `GetDefaultMailSender`, Zeile 728, und `src/backend/Centron.BL/Sales/Receipts/Orders/OrderSpecificLogic.cs`, Zeile 695 - Begründung: die Methoden liefern die belegartabhängige Adresse. + - [SEKUNDÄR] `src/backend/Centron.BL/Mail/MailSettingsBL.cs`, `GetMailSettings` (Zeile 33) - Begründung: hält die Adressen zentral. +Prüfidee: Der Versand einer Gutschrift muss den Rechnungsabsender verwenden, der Versand eines Auftrags den Auftragsabsender. +Tracelinks: StRS-040, SwRS-112 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kommunikationsqualität. +Status: belegt +``` + +``` +ID: SyRS-114 +Titel: Nachverfolgung versandter E-Mails +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: Die Mail-Nachverfolgung ist aktiviert. +Fakt: `MailSettingsBL.GetMailTrackingSettings()` und `UpdateMailTrackingSettings(MailTrackingDTO settings)` verwalten die Nachverfolgung; die Einstellungsseite `MailTrackingSettingsController` ist registriert; zusätzlich besteht der Zweig `Mail/Protocols`. +Aussage: Das System soll den Versand und – sofern konfiguriert – das Öffnen versandter E-Mails nachverfolgen und die Einstellung zentral pflegbar machen. +Ergebnis: Der Bearbeiter erkennt, ob eine Nachricht zugestellt und geöffnet wurde. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Mail/MailSettingsBL.cs`, `GetMailTrackingSettings` (Zeile 233) und `UpdateMailTrackingSettings` (Zeile 253) - Begründung: die Nachverfolgung ist als eigene, konfigurierbare Funktion implementiert. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Administration/MailAndCalender/MailTracking/` - Begründung: eigene Einstellungsseite. +Prüfidee: Bei aktivierter Nachverfolgung muss zu einer versandten Mail ein Nachverfolgungseintrag entstehen. +Tracelinks: StRS-040, SwRS-113 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem unter Beachtung der Einwilligungspflicht. +Status: belegt +``` + +``` +ID: SyRS-115 +Titel: Anrufprotokollierung mit Vorgangsbezug +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Eine TAPI-Verbindung besteht. +Fakt: `Tapi/PhoneCallBL.cs` führt die Anrufe; der Nummernkreis `CallTracking = 22` vergibt eine Vorgangsnummer; das Modul „Telefonate" (`MyCentron/Telephony/CallLog`) zeigt das Protokoll; `PersonalPhoneSettingsController` und `PhoneSettingsController` pflegen persönliche und globale Telefoneinstellungen; im Web existiert `ServiceBoard/PhoneCalls/CallsPage.razor`. +Aussage: Das System soll Anrufe mit Rufnummer, Richtung, Zeitpunkt und erkanntem Geschäftspartner protokollieren und eine eigene Vorgangsnummer vergeben. +Ergebnis: Anrufe sind als eigenständige Vorgänge auswertbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs`, Wert `CallTracking = 22` - Begründung: die eigene Nummernart belegt den Anruf als eigenständigen Vorgang. + - [PRIMÄR] `src/backend/Centron.BL/Tapi/PhoneCallBL.cs` - Begründung: führt die Anrufdatensätze. + - [KONTEXT] `docs/reference/architecture/tapi.md` - Begründung: beschreibt die Anbindung. +Prüfidee: Ein eingehender Anruf muss einen Protokolleintrag mit `CallTracking`-Nummer erzeugen. +Tracelinks: StRS-043, SwRS-115 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als CTI-Schnittstelle. +Status: belegt +``` + +## 9. Weboberflächen und Portale + +``` +ID: SyRS-120 +Titel: Eigenes Rechtesystem für Web-Benutzerkonten +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Kunde (Web-Benutzer) +Vorbedingung: Ein Web-Konto ist angelegt. +Fakt: Web-Konten besitzen eigene Rechte (`WebRights`, `WebRightsCategories`, Zuordnungstabelle `WebAccountsRights`); `AppRightsBL.CheckWebRightsFromUser(int webAccountI3D, IList webRights)` prüft sie per eigener SQL-Abfrage; `WebAccountBL.GetWebAccountCustomerAdministratorsByCustomerID` erkennt Kundenadministratoren an der fest verdrahteten Rechte-ID 31005, ebenso `GetCustomerAdministrationWebRight`. +Aussage: Das System soll für Web-Benutzer ein vom internen Rechtesystem getrenntes Rechtemodell führen und darin eine Kundenadministratorrolle vorsehen. +Ergebnis: Web-Benutzer erhalten ausschließlich die für das Portal vorgesehenen Rechte. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `CheckWebRightsFromUser` mit `SELECT WAR.WebRightsI3D FROM WebAccountsRights WAR WHERE WAR.WebAccountsI3D = :WebAccountI3D` - Begründung: die Abfrage ist die durchsetzende Stelle der Web-Rechteprüfung. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, Zeilen 148-151 und 579-581, jeweils fest verdrahtete Rechte-ID `31005` - Begründung: die Kundenadministratorrolle ist als konstante ID im Code hinterlegt. +Prüfidee: Ein Web-Konto ohne das Recht 31005 darf keine anderen Web-Konten desselben Kunden verwalten. +Tracelinks: StRS-044, StRS-017, SwRS-120 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die fest verdrahtete Rechte-ID ist im Zielsystem durch eine benannte Konstante zu ersetzen. +Status: belegt +``` + +``` +ID: SyRS-121 +Titel: Sperre der Belegeinsicht für Web-Benutzer in der Fachlogik +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Kunde (Web-Benutzer) +Vorbedingung: Ein Web-Benutzer ist angemeldet. +Fakt: `ReceiptBL.CanUserViewReceipt(LoggedInUser loggedInUser, int receiptI3D, CentronObjectKindNumeric objectKind)` liefert für `loggedInUser.IsWebAccountLogin` unmittelbar den Fehler „Web-Benutzer haben keine Berechtigung Belege einzusehen." mit `DefaultMessageCodes.RightCheckFailed`. +Aussage: Das System soll Web-Benutzern den Zugriff auf die interne Belegeinsicht unabhängig von ihren Web-Rechten verweigern. +Ergebnis: Über die Web-Anmeldung ist die interne Belegansicht nicht erreichbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserViewReceipt`, erste Bedingung `if (loggedInUser.IsWebAccountLogin)` - Begründung: die Bedingung sperrt den Zugriff vor jeder weiteren Prüfung. +Prüfidee: Ein Web-Benutzer darf über keinen Aufruf der internen Belegeinsicht Belegdaten erhalten; die Portalansicht bleibt davon unberührt. +Tracelinks: StRS-044, SyRS-020, SwRS-121 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - klare Trennung interner und externer Sichten. +Status: belegt +``` + +``` +ID: SyRS-122 +Titel: Kennwortregeln und Kennwortversand für Web-Konten +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Ein Web-Konto wird angelegt oder sein Kennwort geändert. +Fakt: `WebAccountBL.UpdatePassword` und `SaveWebAccount` weisen Kennwörter unter acht Zeichen mit „Das Password muss mindestens 8 Zeichen lang sein." ab und speichern `SHA1Decoder.GetDecodedSHA1String(newPassword)`; `CreateWebAccountWithContacts` und `UpdateWebAccount` versenden das neue Kennwort anschließend per `SendWebAccountPasswordMail`, wobei der Platzhalter `@@Passwort@@` durch das Klartextkennwort ersetzt wird. +Aussage: Das System soll für Web-Konten eine Mindestkennwortlänge von acht Zeichen erzwingen. Der Versand des Kennworts im Klartext per E-Mail und der ungesalzene SHA-1-Hash sind im Zielsystem durch einen Einladungslink mit Selbstvergabe und ein zeitgemäßes Hashverfahren zu ersetzen. +Ergebnis: Kurze Kennwörter werden abgewiesen; das Kennwort verlässt das System heute jedoch im Klartext. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, Zeilen 185-193 und 243-254, Längenprüfung und `SHA1Decoder.GetDecodedSHA1String` - Begründung: beide sind die durchsetzenden Stellen der Kennwortbehandlung. + - [PRIMÄR] ebenda, `SendWebAccountPasswordMail`, Zeile 563, `.Replace("@@Passwort@@", newPassword)` - Begründung: das Klartextkennwort wird in den Mailtext eingesetzt. +Prüfidee: Ein Kennwort mit sieben Zeichen muss abgewiesen werden; die Versandmail darf im Zielsystem kein Kennwort mehr enthalten. +Tracelinks: StRS-044, SyRS-107, SwRS-122 +Konsolidierung: Kandidat: SyRS-107 — Anwendungs- und Web-Konten verwenden dasselbe Hashverfahren an zwei getrennten Stellen. +Übernahmewürdigkeit: veraltet - Mindestlänge übernehmen, Klartextversand und Hashverfahren ersetzen. +Status: belegt +``` + +``` +ID: SyRS-123 +Titel: Belegfreigabe über Einmal-Token ohne Anmeldung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Kunde +Vorbedingung: Dem Kunden wurde ein Freigabelink zugesandt. +Fakt: `ReceiptBL.ChangeWebReceiptState(string token, WebReceiptState webReceiptState)` identifiziert den Beleg ausschließlich über den Token und liefert ein `AcceptWebReceiptResultDTO`; `SendSignAcceptance(AppUser currentUser, GenerateTokenForDocumentRequest generateTokenForDocumentRequest, SharedDocumentDTO sharedDocument)` erzeugt den Token; im Web bestehen `WebOffer/WebReceiptOverview.razor` und `WebReceiptPdfPreview.razor`. +Aussage: Das System soll Belege über einen ausschließlich für diesen Beleg gültigen Token zur Freigabe bereitstellen und die Freigabeentscheidung ohne Benutzeranmeldung entgegennehmen. +Ergebnis: Der Belegzustand ändert sich nur über einen gültigen Token. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ChangeWebReceiptState(string token, WebReceiptState)`, Zeile 5903 - Begründung: der Token ist die einzige Zugangsvoraussetzung und damit die durchsetzende Stelle. + - [PRIMÄR] ebenda, `SendSignAcceptance` mit `GenerateTokenForDocumentRequest`, Zeile 7032 - Begründung: benennt die Tokenerzeugung. + - [SEKUNDÄR] `src/nexus/CentronNexus/WebOffer/WebReceiptOverview.razor` - Begründung: die Kundenansicht des Belegs. +Prüfidee: Ein manipulierter oder fremder Token darf keinen Belegzustand ändern. +Tracelinks: StRS-045, SwRS-123 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Gültigkeitsdauer und Einmaligkeit des Tokens sind im Zielsystem ausdrücklich festzulegen. +Status: belegt +``` + +``` +ID: SyRS-124 +Titel: Erfassung und Speicherung der Unterschrift im Browser +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Kunde +Vorbedingung: Ein Dokument ist zur Unterzeichnung freigegeben. +Fakt: Die Webanwendung stellt `DocumentSigning/DocumentSigningPage.razor` mit `IsolatedSignaturePad.razor` sowie `Office/SharedDocumentSignPage.razor` und `SharedDocumentAcceptancePage.razor` bereit; im Backend erzeugt `ReceiptBL.SendSignDocument(AppUser currentUser, string centronNexusUrl, SharedDocument sharedDocument, ReceiptMailTemplateDTO receiptMailTemplate)` die Signieranfrage; `Security/PdfSigningBL.cs` signiert erzeugte PDF-Dokumente. +Aussage: Das System soll Unterschriften im Browser erfassen, dem geteilten Dokument zuordnen und das Ergebnisdokument digital signieren. +Ergebnis: Das unterzeichnete Dokument liegt signiert vor. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SendSignDocument`, Zeile 7133 - Begründung: erzeugt die Signieranfrage zum geteilten Dokument. + - [PRIMÄR] `src/backend/Centron.BL/Security/PdfSigningBL.cs` - Begründung: führt die digitale Signatur des PDF durch. + - [SEKUNDÄR] `src/nexus/CentronNexus/DocumentSigning/IsolatedSignaturePad.razor` - Begründung: die Erfassungskomponente im Browser. +Prüfidee: Ein unterzeichnetes Dokument muss eine gültige digitale Signatur tragen. +Tracelinks: StRS-045, StRS-038, SwRS-124 +Konsolidierung: Kandidat: SwRS-042 — Unterschriften werden sowohl am Ticket-Zeiteintrag als auch am geteilten Dokument getrennt erfasst und gespeichert. +Übernahmewürdigkeit: übernehmen - Rechtssicherheit der Freigabe. +Status: belegt +``` + +``` +ID: SyRS-125 +Titel: Self-Care-Formulare als Ticketeingang +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Kunde +Vorbedingung: Ein Formular ist veröffentlicht. +Fakt: `SelfCare/SelfCareBL.cs` und `WebRequestPageBL.cs` verwalten die Formulare; `SelfCareFormsController` stellt sie über die REST-Schnittstelle bereit; die Ticketmustern-Verwaltung enthält die Reiter `SelfCareFormFieldGrid.razor`, `SelfCareFormFieldEditPopup.razor` und `TicketPatternWebFormTab.razor`; im Portal bestehen `CustomerPortalFormsPage.razor` und `CustomerPortalFormFillPage.razor`. +Aussage: Das System soll frei definierbare Formulare bereitstellen, die der Kunde im Portal ausfüllt und aus denen Tickets nach dem hinterlegten Ticketmuster entstehen. +Ergebnis: Kundenanliegen erreichen den Helpdesk strukturiert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/SelfCare/SelfCareBL.cs` und `src/webservice/Centron.Controllers/Controllers/v1/SelfCare/SelfCareFormsController.cs` - Begründung: Formularverwaltung und Bereitstellung sind dort implementiert. + - [SEKUNDÄR] `src/nexus/CentronNexus/Management/TicketPatterns/Components/SelfCareFormFieldGrid.razor` - Begründung: die Felddefinition ist an das Ticketmuster gebunden. +Prüfidee: Ein ausgefülltes Formular muss ein Ticket mit den im Muster hinterlegten Kategorien erzeugen. +Tracelinks: StRS-044, StRS-016, SyRS-058, SwRS-125 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Entlastung der Serviceannahme. +Status: belegt +``` + +``` +ID: SyRS-126 +Titel: Mandantenspezifisches Erscheinungsbild der Weboberfläche +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Die Weboberfläche wird ausgeliefert. +Fakt: Die Webanwendung führt `Configuration/BrandingConfig.cs`, `Controllers/BrandingConfigController.cs`, `Settings/Branding/` und `Settings/Themes/`; im Rich-Client bestehen `Modules/Administration/Themes` und der `ThemesController` in der REST-Schnittstelle mit dem Recht `Administration.THEME_MANAGEMENT`. +Aussage: Das System soll Logo, Farben und Bezeichnungen der Weboberfläche je Installation konfigurierbar machen und die Verwaltung an ein eigenes Recht binden. +Ergebnis: Das Portal erscheint im Erscheinungsbild des betreibenden Unternehmens. +Belege: + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, `Administration.THEME_MANAGEMENT = 20800161` - Begründung: die Verwaltung ist an ein eigenes Recht gebunden. + - [PRIMÄR] `src/nexus/CentronNexus/Configuration/BrandingConfig.cs`, `Controllers/BrandingConfigController.cs` - Begründung: liefern die Konfiguration an die Oberfläche aus. +Prüfidee: Nach Änderung des Logos muss die Portalstartseite das neue Logo zeigen. +Tracelinks: StRS-044, SwRS-126 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im SaaS-Betrieb Voraussetzung für Mehrmandantenfähigkeit. +Status: belegt +``` + +``` +ID: SyRS-127 +Titel: Zugriff auf Kunden, Belege und Tickets aus Outlook +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Innendienst +Vorbedingung: Das Outlook-Add-In ist installiert und der Benutzer angemeldet. +Fakt: `CentronNexus.OutlookAddIn` enthält die Bereiche `Belege`, `CRM`, `Customer`, `Document`, `Ticket`, `OfficeDialog` und `Manifest` sowie `OutlookIndexPage.razor`; die Manifestauslieferung erfolgt über `Settings/OutlookAddInManifest/`; `Configuration/CentronAddInInfoConfig.cs` liefert die Add-In-Konfiguration. +Aussage: Das System soll aus Outlook heraus den Zugriff auf Kunden, Belege, Dokumente und Tickets ermöglichen und das Add-In-Manifest aus der Anwendung heraus ausliefern. +Ergebnis: Der Bearbeiter arbeitet ohne Anwendungswechsel im Postfach. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus.OutlookAddIn/` mit den Bereichen `Belege`, `CRM`, `Customer`, `Document`, `Ticket` - Begründung: die Bereiche belegen den Funktionsumfang. + - [SEKUNDÄR] `src/nexus/CentronNexus/Settings/OutlookAddInManifest/`, `Configuration/CentronAddInInfoConfig.cs` - Begründung: Manifestauslieferung und Konfiguration. +Prüfidee: Zu einer E-Mail eines bekannten Kunden muss das Add-In dessen Kundendaten anzeigen. +Tracelinks: StRS-040, StRS-044, SwRS-127 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als Web-Add-In. +Status: belegt +``` + +``` +ID: SyRS-128 +Titel: Benachrichtigungen in der Weboberfläche +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Helpdesk-Mitarbeiter +Vorbedingung: Ein benachrichtigungspflichtiges Ereignis tritt ein. +Fakt: `NexusNotifications/NexusNotificationsBL.cs` erzeugt Benachrichtigungen (u. a. `SaveClosedTicketNotifications`, aufgerufen aus `HelpdeskCloseBL.CloseHelpdesk`), `NotificationsHubHelper.cs` verteilt sie; `Notifications/CentronNotificationsBL.cs` und `UserNotificationBL.cs` bilden die anwendungsweiten Benachrichtigungen ab; `Configuration/NotificationsConfig.cs` und `Settings/Notification/` konfigurieren sie; die Einstellungsseite `CentronNotificationsSettingsController` ist registriert. +Aussage: Das System soll Benutzer über fachliche Ereignisse benachrichtigen und die Benachrichtigungen in der Weboberfläche ohne Neuladen zustellen. +Ergebnis: Der Bearbeiter erfährt zeitnah von Ereignissen an seinen Vorgängen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/NexusNotifications/NexusNotificationsBL.cs`, `SaveClosedTicketNotifications`, aufgerufen in `HelpdeskCloseBL.CloseHelpdesk` - Begründung: belegt die tatsächliche Erzeugung an einem fachlichen Ereignis. + - [SEKUNDÄR] `src/backend/Centron.BL/NexusNotifications/NotificationsHubHelper.cs`, `src/nexus/CentronNexus/Configuration/NotificationsConfig.cs` - Begründung: Zustellung und Konfiguration. +Prüfidee: Das Schließen eines Tickets muss beim zuständigen Bearbeiter eine Benachrichtigung erzeugen. +Tracelinks: SyRS-054, SwRS-128 +Konsolidierung: Kandidat: SwRS-128 — `Notifications` und `NexusNotifications` bilden Benachrichtigungen in zwei getrennten Mechanismen ab. +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-129 +Titel: Sprachumschaltung der Weboberfläche +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Benutzbarkeit (Zugänglichkeit) +Akteur: Alle Benutzer +Vorbedingung: Die Weboberfläche wird aufgerufen. +Fakt: Die Webanwendung führt `SharedResource.resx` (Deutsch) und `SharedResource.en-US.resx` (Englisch) samt Designer-Klassen sowie einen `CultureController`; die Entwicklungsvorgaben nennen Deutsch als Standardsprache und Englisch als Zusatzsprache. +Aussage: Das System soll seine Oberflächentexte in Deutsch und Englisch bereitstellen und die Sprache je Benutzer umschaltbar machen; Deutsch ist die Standardsprache. +Ergebnis: Der Benutzer sieht die Oberfläche in der gewählten Sprache. +Belege: + - [PRIMÄR] `src/nexus/CentronNexus/Controllers/CultureController.cs` - Begründung: setzt die Sprache der Sitzung. + - [PRIMÄR] `src/nexus/CentronNexus/SharedResource.resx`, `SharedResource.en-US.resx` - Begründung: die zwei Sprachsätze sind vorhanden. + - [KONTEXT] `docs/getting-started/general-structure.md`, Abschnitt „German-First Language Policy" - Begründung: benennt Deutsch als Standard und Englisch als Zusatz. +Prüfidee: Nach Umschalten auf Englisch müssen die Menütexte englisch erscheinen. +Tracelinks: StRS-044, SwRS-129 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Voraussetzung für internationale Kunden. +Status: belegt +``` + +## 10. Datenschutz und Nachvollziehbarkeit + +``` +ID: SyRS-150 +Titel: Ermittlung löschbarer Kontaktdaten nach DSGVO +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Datenschutzbeauftragter +Vorbedingung: Das Recht `DSGVO_DELETE_CONTACT` liegt vor. +Fakt: `DataSecurityBL.DsgvoDeleteRightGetContacts(AppUser currentUser, DsgvoDeleteRightContactFilter filter)` prüft zuerst das Recht und liefert dann `IList`; `DsgvoDeleteRightDeleteContacts` löscht über objektartabhängige Verzweigungen (`DoDeleteContactPerson`, `DoDeleteContactManagementContactPerson`, `DoDeleteAccountAddressContact`) und schreibt ein Löschprotokoll (`deleteProtocol`). +Aussage: Das System soll zu einer Löschanfrage alle betroffenen Kontaktdatensätze über alle Kontaktarten hinweg ermitteln, sie nach Bestätigung löschen und den Vorgang protokollieren. +Ergebnis: Der Betroffene ist in allen Kontaktarten entfernt und der Vorgang ist dokumentiert. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, `DsgvoDeleteRightGetContacts` (Zeile 377) und `DsgvoDeleteRightDeleteContacts` (Zeile 787) mit vorangestellter Rechteprüfung - Begründung: beide Einstiegspunkte prüfen das Recht und führen die Ermittlung beziehungsweise Löschung aus. + - [PRIMÄR] ebenda, Zeilen 819-834, Verzweigung auf `DoDeleteContactPerson`, `DoDeleteContactManagementContactPerson`, `DoDeleteAccountAddressContact` - Begründung: benennt die tatsächlich gelöschten Kontaktarten. +Prüfidee: Eine Person, die als Ansprechpartner und als Kontaktmanagement-Kontakt geführt wird, muss in beiden Arten entfernt werden. +Tracelinks: StRS-050, SwRS-150 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - gesetzlich zwingend. +Status: belegt +``` + +``` +ID: SyRS-151 +Titel: Nicht implementierte Löschpfade im Datenschutzmodul +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Datenschutzbeauftragter +Vorbedingung: Eine Löschanfrage betrifft einen Kunden, Lieferanten oder Account als Ganzes. +Fakt: `DataSecurityBL.DoDeleteCustomer(int i3d, bool isReferenceDelete)` wirft `new NotImplementedException("DoDeleteCustomer is not ready for use!")`; `DoDeleteSupplier` ist analog angelegt; die Aufrufe für Kunde, Lieferant, Kontaktmanagement-Kontakt und Account sind in `DsgvoDeleteRightDeleteContacts` auskommentiert (Zeilen 803-814). Die zugehörigen Anonymisierungs-SQL-Anweisungen stehen ebenfalls nur als Kommentar im Quelltext. +Aussage: Das System soll auch vollständige Geschäftspartner löschen oder anonymisieren können. [HYPOTHESE] Die Löschpfade für Kunde, Lieferant und Account sind vorbereitet, aber deaktiviert; ob dies auf fachliche Bedenken (Referenzintegrität zu Belegen) oder auf unfertige Entwicklung zurückgeht, geht aus den Artefakten nicht hervor. +Ergebnis: Im heutigen Stand sind nur Kontaktpersonen löschbar, nicht ganze Geschäftspartner. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, `DoDeleteCustomer`, Zeile 856-858, `throw new NotImplementedException("DoDeleteCustomer is not ready for use!")` - Begründung: der Löschpfad bricht bei Aufruf ab. + - [KONTEXT] ebenda, Zeilen 803-814 und 863-903, auskommentierte Aufrufe und Anonymisierungs-SQL - Begründung: belegen den vorbereiteten, aber nicht aktiven Zustand. +Prüfidee: Der Versuch, einen Kunden über das Datenschutzmodul zu löschen, muss heute scheitern; im Zielsystem ist ein tragfähiges Anonymisierungsverfahren vorzusehen. +Tracelinks: StRS-050, SyRS-150, SwRS-151 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die Anforderung besteht fort und ist im Zielsystem umzusetzen. +Status: HYPOTHESE +``` + +``` +ID: SyRS-152 +Titel: Bereinigung nicht mehr benötigter Datenbestände +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Das Recht `ACCESS_CLEANUP_DATABASE` liegt vor. +Fakt: `DataSecurityBL.GetDataSecurityCleanUpStats(AppUser currentUser, DataSecurityCleanUpStatsFilter filter)` ermittelt je Bereinigungsart eine Kennzahl (u. a. `GetDeletedCustomers` mit `DataSecurityCleanUpStatsKind.CustomersDeleted`), `DataSecurityExecuteCleanUp(AppUser currentUser, IList selectedStats, DataSecurityCleanUpStatsFilter filter)` führt die ausgewählten Bereinigungen aus. +Aussage: Das System soll vor einer Datenbereinigung je Bereinigungsart die Zahl der betroffenen Datensätze ausweisen und nur die ausdrücklich ausgewählten Arten ausführen. +Ergebnis: Der Administrator kennt den Umfang der Bereinigung vor deren Ausführung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, `GetDataSecurityCleanUpStats` (Zeile 34) und `DataSecurityExecuteCleanUp` (Zeile 64) mit dem Parameter `selectedStats` - Begründung: die Trennung von Vorschau und Ausführung sowie die Auswahl sind dort durchgesetzt. + - [SEKUNDÄR] `src/webservice/…/UserRightsConst.cs`, `DsgvoModule.ACCESS_CLEANUP_DATABASE = 20800024` - Begründung: eigenes Recht für die Bereinigung. +Prüfidee: Eine Bereinigung ohne ausgewählte Art darf keine Datensätze verändern. +Tracelinks: StRS-050, SwRS-152 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Grundsatz der Datenminimierung. +Status: belegt +``` + +``` +ID: SyRS-153 +Titel: Herkunftskennzeichnung jeder Belegänderung +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Revision +Vorbedingung: Ein Beleg wird gespeichert. +Fakt: `SaveReceipt` besitzt den Parameter `CreatedThroughApplication application` und setzt `receipt.ChangedThroughApplication = application` sowie `receipt.ChangedThroughApplicationVersion = AssemblyLogic.GetFromAssemblyContaining().ToString()`; bei Neuanlage werden zusätzlich `CreatedThroughApplicationVersion`, `CreatedByI3D` und `CreatedAt` gesetzt. +Aussage: Das System soll zu jeder Belegänderung festhalten, aus welcher Anwendung und aus welcher Programmversion sie stammt. +Ergebnis: Fehlerhafte Datenbestände lassen sich einer Anwendung und Version zuordnen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Zuweisungen der Audit-Felder unmittelbar vor der Rechteprüfung - Begründung: die Felder werden dort bei jedem Speichervorgang gesetzt. +Prüfidee: Ein aus dem Webservice gespeicherter Beleg muss eine andere `ChangedThroughApplication` tragen als ein aus dem Rich-Client gespeicherter. +Tracelinks: StRS-051, SwRS-153 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - erleichtert die Fehlersuche erheblich. +Status: belegt +``` + +``` +ID: SyRS-154 +Titel: Feldbezogene Änderungshistorie ausgewählter Belegangaben +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Revision +Vorbedingung: Ein Beleg mit Kontingentangaben wird geändert. +Fakt: `ReceiptBL.WriteReceiptLogs(bool isNewReceipt, IReceiptBase receipt, IReceiptBase previousVersion, AppUser appUser)` vergleicht Kontingentart, Kontingentwert und Mindestbestellwert mit der Vorgängerversion und schreibt bei Abweichung über `_receiptLogBL` je Feld einen eigenen Protokolleintrag mit Alt- und Neuwert; bei Neuanlage unterbleibt die Protokollierung. +Aussage: Das System soll für ausgewählte Belegangaben bei jeder Änderung einen Protokolleintrag mit Alt- und Neuwert, Zeitpunkt und Benutzer schreiben. +Ergebnis: Wertänderungen an geschäftskritischen Feldern sind nachvollziehbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `WriteReceiptLogs`, Vergleiche `Equals(contingent.ContingentKind, oldReceipt.ContingentKind) == false` und die zugehörigen `CreateContingentKindEntry`-Aufrufe - Begründung: die Vergleiche und Aufrufe erzeugen die Protokolleinträge tatsächlich. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs`, `src/backend/Centron.BL/ChangeTracking/History/` - Begründung: die Protokollkomponenten. +Prüfidee: Die Änderung des Kontingentwerts muss einen Protokolleintrag mit altem und neuem Wert erzeugen. +Tracelinks: StRS-051, SyRS-030, SwRS-154 +Konsolidierung: Kandidat: SwRS-154 — `ReceiptLogBL`, `ChangeTracking/History` und die Versionstabellen protokollieren Änderungen in drei Mechanismen. +Übernahmewürdigkeit: übernehmen - im Zielsystem mit einem einheitlichen Mechanismus. +Status: belegt +``` + +## 11. Betrieb, Bereitstellung, Querschnitt + +``` +ID: SyRS-160 +Titel: Container-Laufzeitumgebung mit festgelegter Zeitzone und Zeichensatzunterstützung +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Übertragbarkeit (Anpassbarkeit) +Akteur: Betrieb +Vorbedingung: Der Dienst wird als Container betrieben. +Fakt: `docker/Dockerfile` setzt `ENV TZ=Europe/Berlin`, installiert `icu-data-full`, `icu-libs`, `tzdata`, `fontconfig`, `ttf-dejavu` und `msttcorefonts-installer`, setzt `DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false` und veröffentlicht selbstenthaltend (`dotnet publish … --self-contained true`). +Aussage: Das System soll im Containerbetrieb die Zeitzone Europe/Berlin, vollständige Kulturdaten und die für die Formularausgabe benötigten Schriftarten bereitstellen. +Ergebnis: Datums-, Zahlen- und Formulardarstellung stimmen mit dem Windows-Betrieb überein. +Belege: + - [PRIMÄR] `docker/Dockerfile`, Zeilen mit `ENV TZ=Europe/Berlin`, `apk add --no-cache icu-data-full icu-libs`, `ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false`, `update-ms-fonts` - Begründung: die Anweisungen legen die Laufzeitumgebung verbindlich fest. +Prüfidee: Ein im Container erzeugtes PDF muss dieselben Schriftarten und dasselbe Datumsformat verwenden wie unter Windows. +Tracelinks: StRS-052, StRS-038, SwRS-160 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die fest verdrahtete Zeitzone ist im Zielsystem konfigurierbar zu machen. +Status: belegt +``` + +``` +ID: SyRS-161 +Titel: Ausführung fehlender Datenbankskripte vor der Anmeldung +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Die Anwendung startet gegen eine Datenbank älteren Stands. +Fakt: `ScriptEngineBL.ExecuteScripts(AppUser currentUser, bool executeBeforeLogin, Version currentVersionOverride)` besitzt den Schalter `executeBeforeLogin`, liest die bereits ausgeführten `DBUpdate`-Einträge, ermittelt die fehlenden Skriptmethoden aus dem `ScriptMethodPool` und zeigt den Fortschritt über `UiStatusBarManager.PushMessage("Skripte werden ausgeführt...")`; ein statischer Schalter `ShouldExecuteScripts` erlaubt das Abschalten. +Aussage: Das System soll fehlende Datenbankänderungen vor der Benutzeranmeldung ausführen, den Fortschritt anzeigen und bereits ausgeführte Änderungen anhand ihrer Skriptnummer überspringen. +Ergebnis: Kein Benutzer arbeitet gegen ein veraltetes Datenbankschema. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, `ExecuteScripts` mit Parameter `executeBeforeLogin` und der Auswahl `scriptMethods.Where(f => dbUpdates.All(ff => ff.ScriptNumber != f.ScriptNumber))` - Begründung: die Auswahl bestimmt die tatsächlich ausgeführten Skripte. + - [KONTEXT] `docs/guides/database/create-scripts.md` - Begründung: beschreibt die Reservierung von Skriptnummern. +Prüfidee: Ein Start gegen eine aktuelle Datenbank darf kein Skript ausführen. +Tracelinks: StRS-053, SwRS-161 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-162 +Titel: Ausnahmeliste für fehlertolerante Migrationsskripte +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Zuverlässigkeit (Fehlertoleranz) +Akteur: Betrieb +Vorbedingung: Ein Migrationsskript schlägt fehl. +Fakt: `ScriptEngineBL` führt die statische Liste `private static int[] _scriptIgnoreIfErrorList = { 10178, 10210, 10211, 50000 };`. +Aussage: Das System soll Fehler einzelner, namentlich benannter Migrationsskripte übergehen und die Migration fortsetzen, während alle übrigen Skriptfehler den Start abbrechen. +Ergebnis: Bekannte, unkritische Skriptfehler verhindern den Start nicht. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, Zeile 27, `_scriptIgnoreIfErrorList` - Begründung: die Liste benennt die Ausnahmen abschließend. +Prüfidee: Ein Fehler in Skript 10178 darf den Start nicht abbrechen, ein Fehler in einem anderen Skript schon. +Tracelinks: SyRS-161, StRS-053, SwRS-162 +Konsolidierung: nein +Übernahmewürdigkeit: Workaround - eine fest verdrahtete Ausnahmeliste ist eine Behelfslösung für fehlerhafte Altskripte. +Status: belegt +``` + +``` +ID: SyRS-163 +Titel: Automatisierte Übersetzung, Signierung und Prüfung +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Testbarkeit) +Akteur: Entwicklung +Vorbedingung: Änderungen werden in den Hauptzweig oder einen Freigabezweig übernommen. +Fakt: `.github/workflows/build.yml` („Build, sign, and publish") läuft auf `self-hosted, Windows, X64` mit `timeout-minutes: 180`, `permissions: contents: read` und einer Nebenläufigkeitsgruppe, die laufende Läufe desselben Pull Requests abbricht, Läufe auf `main` und `release/**` jedoch nicht; weiterhin bestehen `tests.yml`, `regression-tests.yml`, `cleanup-pr-artifacts.yml` sowie die Azure-Pipelines `build-pipeline.yml`, `tests-pipeline.yml`, `docker-pipeline.yml`, `analyze-pipeline.yml`, `regression-tests-pipeline.yml`. +Aussage: Das System soll bei jeder Änderung automatisch übersetzt, signiert und getestet werden; für Hauptzweig und Freigabezweige ist jedes Ergebnis vollständig aufzuzeichnen. +Ergebnis: Zu jedem Stand liegt ein reproduzierbares Bau- und Prüfergebnis vor. +Belege: + - [PRIMÄR] `.github/workflows/build.yml`, Abschnitt `concurrency` mit `cancel-in-progress: ${{ github.event_name == 'pull_request' }}` und dem Kommentar „Pushes to main and release branches are excluded so every commit there still gets a full, recorded result" - Begründung: die Bedingung setzt die Aufzeichnungsregel durch. + - [SEKUNDÄR] `azure/build-pipeline.yml`, `tests-pipeline.yml`, `docker-pipeline.yml`, `regression-tests-pipeline.yml`, `analyze-pipeline.yml` - Begründung: belegen den weiteren Umfang der Automatisierung. +Prüfidee: Zwei aufeinanderfolgende Übernahmen nach `main` müssen zwei vollständige, nicht abgebrochene Läufe erzeugen. +Tracelinks: StRS-052, SwRS-163 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Voraussetzung für häufige Auslieferung. +Status: belegt +``` + +``` +ID: SyRS-164 +Titel: Mehrstufige automatisierte Prüfung +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Testbarkeit) +Akteur: Entwicklung +Vorbedingung: Eine Änderung wird geprüft. +Fakt: Es bestehen neun Testprojekte auf drei Ebenen: Einheitstests (`tests/backend/Centron.Tests.BL`, `Centron.Tests.DAO`, `tests/shared/Centron.Tests.Core`, `Centron.Tests.Controls`, `tests/apis/*`), Integrationstests (`tests/Centron.Tests.Integration`), Ende-zu-Ende-Tests (`tests/Centron.Tests.EndToEnd`) und Oberflächentests (`tests/PlaywrightTests`, `tests/CentronNexusTests`). +Aussage: Das System soll auf den Ebenen Einheit, Integration, Ende-zu-Ende und Oberfläche automatisiert geprüft werden. +Ergebnis: Regressionen werden vor der Auslieferung erkannt. +Belege: + - [PRIMÄR] `tests/` mit neun `*.csproj`-Testprojekten auf den genannten Ebenen - Begründung: die Projektstruktur belegt die Prüfebenen. + - [KONTEXT] `docs/guides/development/end-to-end-testing.md` - Begründung: beschreibt das Vorgehen bei Ende-zu-Ende-Tests. +Prüfidee: Für jede der vier Ebenen muss mindestens ein Testprojekt im Bau ausgeführt werden. +Tracelinks: SyRS-163, SwRS-164 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-165 +Titel: Anwendungsprotokollierung über eine gemeinsame Protokollkonfiguration +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Analysierbarkeit) +Akteur: Betrieb +Vorbedingung: Die Anwendung läuft. +Fakt: Die Protokollierung erfolgt durchgängig über NLog (`private static readonly ILogger Logger = LogManager.GetCurrentClassLogger();` in `Authenticator`, `BasicAuthenticator`, `ScriptEngineBL`, `HelpdeskCloseBL`, `AutomaticFacturaBL`, `ModuleRegistration` u. a.); die Konfiguration liegt in `src/centron/Centron.WPF.UI/nlog.config`; ein Modul `LogViewer` zeigt die Protokolle an; `Centron.Common/Logging/` bündelt Hilfsmittel. +Aussage: Das System soll alle Anwendungsereignisse über eine gemeinsame, zentral konfigurierte Protokollkomponente ausgeben und die Protokolle in der Anwendung einsehbar machen. +Ergebnis: Betriebsstörungen sind ohne Zugriff auf den Server auswertbar. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/nlog.config` - Begründung: die zentrale Protokollkonfiguration. + - [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs` und weitere Klassen mit `LogManager.GetCurrentClassLogger()` - Begründung: belegen die durchgängige Verwendung derselben Komponente. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Administration/LogViewer/` - Begründung: Anzeige der Protokolle in der Anwendung. +Prüfidee: Eine fehlgeschlagene Anmeldung muss im LogViewer als Warnung erscheinen. +Tracelinks: StRS-051, SyRS-106, SwRS-165 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem als strukturierte, zentrale Protokollsenke. +Status: belegt +``` + +``` +ID: SyRS-166 +Titel: Periodische Datenqualitätsprüfungen im Hintergrund +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Zuverlässigkeit (Reife) +Akteur: Betrieb +Vorbedingung: Der Hintergrunddienst läuft. +Fakt: `Services/DataQuality/DirectoryCheckBL.cs` stellt `ExecuteDirectoryCheck()` und `ExecuteDirectoryCheck(LoggedInUser currentUser)` bereit und liefert `IList`; `GetCaptionForDirectoryCheckItem(CentronObjectKindNumeric objectKind)` benennt die Prüfarten je Objektart; ergänzend besteht `Services/Workflows/`. +Aussage: Das System soll wiederkehrende Konsistenzprüfungen — beispielsweise auf verwaiste Dokumentenverzeichnisse — im Hintergrund ausführen und die Befunde je Objektart benannt ausweisen. +Ergebnis: Datenfehler werden erkannt, bevor sie im Tagesgeschäft auffallen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Services/DataQuality/DirectoryCheckBL.cs`, `ExecuteDirectoryCheck` (Zeile 40) und `GetCaptionForDirectoryCheckItem` (Zeile 84) - Begründung: führen die Prüfung aus und benennen die Befunde. + - [KONTEXT] `docs/Background Service/DataQualityService.md` - Begründung: beschreibt den Dienst. +Prüfidee: Ein verwaistes Dokumentenverzeichnis muss im Prüfergebnis mit seiner Objektart erscheinen. +Tracelinks: StRS-039, SwRS-166 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-167 +Titel: Erfassung der Nutzung von API- und KI-Werkzeugen +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Wartbarkeit (Analysierbarkeit) +Akteur: Hersteller +Vorbedingung: Ein API- oder KI-Werkzeug wird verwendet. +Fakt: `TelemetryBL` bietet `UpsertApiCallBatch`, `UpsertMcpToolUsageBatch`, `UpsertArtificialIntelligenceToolUsageBatch`, `RecordArtificialIntelligenceToolUsage(int userId, string toolName, string hardwareId, DateTime occurredUtc)` sowie `GetCompletedPendingApiCalls(DateTime maxBucketStartUtc)`; die Zählung erfolgt in Zeitfenstern (`BucketIncrement`, `bucketStartUtc`) und über Namensnachschlagtabellen (`LoadAllMcpToolNames`, `LoadAllApiMethodNames`). +Aussage: Das System soll die Nutzung von API-Methoden und KI-Werkzeugen je Benutzer, Gerät und Zeitfenster zählen und die abgeschlossenen Zeitfenster zur Übermittlung bereitstellen. +Ergebnis: Nutzungsdaten liegen verdichtet und nicht als Einzelereignis vor. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Telemetry/TelemetryBL.cs`, `RecordArtificialIntelligenceToolUsage` (Zeile 122) und `GetCompletedPendingApiCalls` (Zeile 308) - Begründung: Erfassung und Bereitstellung sind dort implementiert. +Prüfidee: Zehn Aufrufe derselben API-Methode innerhalb eines Zeitfensters müssen einen Zähler mit Wert 10 ergeben, nicht zehn Einzeleinträge. +Tracelinks: StRS-056, SwRS-167 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - die Erhebung ist im Zielsystem datenschutzrechtlich zu bewerten. +Status: belegt +``` + +``` +ID: SyRS-168 +Titel: Verbindungsart bestimmt die Verfügbarkeit von Modulen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Anwender +Vorbedingung: Der Client ist über SQL oder über den Webservice verbunden. +Fakt: `CentronModule.OpenModule` prüft `module.SupportsConnectionTypes.All(f => f != ClassContainer.Instance.ConnectionType)` und meldet bei Webservice-Verbindung „Das Modul \"{module.ModuleName}\" unterstützt die Web-Service Verbindung nicht.{Environment.NewLine}Bitte melden Sie sich mit einer SQL-Verbindung an."; andernfalls „…unterstützt die aktuelle Verbindung zur Datenbank nicht." +Aussage: Das System soll je Modul die unterstützten Verbindungsarten führen und das Öffnen eines Moduls über eine nicht unterstützte Verbindung mit einem Hinweis auf die erforderliche Verbindungsart abweisen. +Ergebnis: Der Anwender erfährt, warum ein Modul nicht verfügbar ist. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/CentronModule.cs`, `OpenModule`, Zeilen 63-73 - Begründung: die Bedingung verhindert das Öffnen tatsächlich und liefert die Meldung. + - [KONTEXT] `docs/getting-started/general-structure.md`, Abschnitt „Connection Type Support" - Begründung: beschreibt die Deklaration `SupportsConnectionTypes` je Modul. +Prüfidee: Ein Modul ohne Webservice-Unterstützung muss bei Webservice-Verbindung die entsprechende Meldung liefern. +Tracelinks: StRS-052, SwRS-168 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - im Zielsystem entfällt der direkte Datenbankzugriff des Clients, damit auch diese Fallunterscheidung. +Status: belegt +``` + +## 12. Auswertung, Suche, Integration + +``` +ID: SyRS-170 +Titel: Getrennte Rechte je Auswertung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Controlling +Vorbedingung: Auswertungen sind lizenziert. +Fakt: Die Region „Controlling/Analytics" registriert acht Module (Analytics, Leistungsnachweise, Management Info, Mitarbeiterauslastung, MSP-Auswertung, MSP-Collector, MSP-Dashboard, Vertragsauswertung) mit jeweils eigener Rechte- und Lizenzbedingung; der Rechtezweig `Controlling.Analytics` enthält unter anderem `SALES_STATISTIC`. +Aussage: Das System soll jede Auswertung an ein eigenes Recht und eine eigene Lizenz binden, sodass Kennzahlen selektiv freigegeben werden können. +Ergebnis: Ein Benutzer sieht nur die für ihn freigegebenen Auswertungen. +Belege: + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Controlling/Analytics", Zeilen 628-670 - Begründung: acht getrennte Registrierungen mit eigenen Bedingungen. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Authorization/README.md`, Beispiel `[AuthorizeUserRight(UserRightsConst.Controlling.Analytics.SALES_STATISTIC)]` - Begründung: dieselbe Rechtebindung gilt an der REST-Schnittstelle. +Prüfidee: Ein Benutzer mit Recht auf die Umsatzstatistik, aber ohne Recht auf Management Info darf nur die Umsatzstatistik sehen. +Tracelinks: StRS-054, StRS-031, SwRS-170 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-171 +Titel: Bedarfsgesteuerte und vollständige Indexaktualisierung +Ebene: SyRS +Typ: nicht-funktional +Qualitätsmerkmal: Performance-Effizienz (Zeitverhalten) +Akteur: System +Vorbedingung: Objekte werden geändert. +Fakt: `IndexSearchBL` bietet `UpdateAllIndexes(CancellationToken token)` für den vollständigen Neuaufbau, `UpdateRequestedIndexes(CancellationToken token)` für angeforderte Aktualisierungen und `RequestUpdateFor(CentronObjectKindNumeric kind, int objectI3D)` zum Vormerken einzelner Objekte; beide Aktualisierungsläufe sind abbrechbar. +Aussage: Das System soll den Suchindex vorrangig für einzeln vorgemerkte Objekte aktualisieren, einen vollständigen Neuaufbau nur auf Anforderung ausführen und beide Läufe abbrechbar gestalten. +Ergebnis: Der Index bleibt aktuell, ohne den laufenden Betrieb zu belasten. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs`, `UpdateAllIndexes` (Zeile 28), `UpdateRequestedIndexes` (Zeile 36), `RequestUpdateFor` (Zeile 75), jeweils mit `CancellationToken` - Begründung: die Methoden trennen die beiden Betriebsarten und ermöglichen den Abbruch. + - [SEKUNDÄR] `src/backend/Centron.BL/IndexSearch/ObjectIndexingFailedException.cs` - Begründung: Fehler beim Indizieren werden gesondert behandelt. +Prüfidee: Nach `RequestUpdateFor` für ein Ticket muss `UpdateRequestedIndexes` genau dieses Ticket neu indizieren. +Tracelinks: StRS-055, SwRS-171 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-172 +Titel: Anbindung von Sprachmodellen über austauschbare Klienten +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: System +Vorbedingung: Ein KI-Zugang ist konfiguriert. +Fakt: `ArtificialIntelligence` enthält die Schnittstelle `IApiClient` mit `ApiClientFactory` sowie die Implementierungen `OpenAiApiClient`, `ChatModelApiClient`, `TextRatingApiClient` und `TicketCategoryApiClient`; `AiHttpModelCatalogClient` liest den verfügbaren Modellkatalog, `AiApiLinkValidator` prüft die konfigurierte Adresse; Aufforderungstexte liegen unter `Prompts`. +Aussage: Das System soll Sprachmodelle über eine gemeinsame Klientenschnittstelle anbinden, den verfügbaren Modellkatalog abfragen und die konfigurierte Zieladresse vor der Verwendung prüfen. +Ergebnis: Der KI-Anbieter ist ohne Änderung der Fachlogik austauschbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/ArtificialIntelligence/IApiClient.cs` und `ApiClientFactory.cs` - Begründung: definieren die gemeinsame Schnittstelle und die Auswahl der Implementierung. + - [PRIMÄR] `src/backend/Centron.BL/ArtificialIntelligence/AiApiLinkValidator.cs` - Begründung: prüft die Zieladresse vor der Verwendung. +Prüfidee: Nach Umstellen der konfigurierten Adresse muss der Modellkatalog des neuen Anbieters erscheinen. +Tracelinks: StRS-056, SwRS-172 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-173 +Titel: Versionierte REST-Schnittstelle +Ebene: SyRS +Typ: Schnittstelle +Qualitätsmerkmal: +Akteur: Fremdsystem +Vorbedingung: Ein Fremdsystem ruft die Schnittstelle auf. +Fakt: Die Controller liegen unter `Controllers/v1/...` mit dem Routenmuster `[Route("v{version:apiVersion}/...")]` (Asp.Versioning); anmeldungsbezogene Controller sind mit `[ApiVersionNeutral]` und `[Route("jwt")]` versionsneutral; ein `WebServiceVersionController` liefert die Dienstversion. +Aussage: Das System soll seine REST-Schnittstelle versioniert bereitstellen, anmeldungsbezogene Endpunkte versionsneutral führen und die Dienstversion abfragbar machen. +Ergebnis: Fremdsysteme können gegen eine feste Schnittstellenversion arbeiten. +Belege: + - [PRIMÄR] `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs`, Attribute `[ApiVersionNeutral]` und `[Route("jwt")]` - Begründung: belegen die bewusste Versionsneutralität der Anmeldung. + - [PRIMÄR] `src/webservice/Centron.Controllers/Controllers/v1/` mit 38 Controllern - Begründung: die Versionierung ist im Pfad und in den Routen durchgesetzt. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/v1/WebVersion/WebServiceVersionController.cs` - Begründung: liefert die Dienstversion. +Prüfidee: Ein Aufruf ohne Versionsangabe an einen versionierten Endpunkt muss abgewiesen werden. +Tracelinks: StRS-062, SyRS-091, SwRS-173 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Voraussetzung für stabile Fremdanbindungen. +Status: belegt +``` + +``` +ID: SyRS-174 +Titel: Beschränkung von Endpunkten auf die gehostete Betriebsform +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Betrieb +Vorbedingung: Ein Endpunkt ist für den gehosteten Betrieb vorgesehen. +Fakt: Es besteht das Attribut `AuthorizeCentronHostedAttribute` mit der zugehörigen Klasse `CentronHostedAuthorization`; die Anwendungsdokumentation beschreibt seine Stapelung mit Rechteattributen („Must be from hosted environment"). +Aussage: Das System soll einzelne REST-Endpunkte auf den vom Hersteller betriebenen Dienst beschränken und Aufrufe aus abweichenden Betriebsformen abweisen. +Ergebnis: Für den Betreiberbetrieb vorgesehene Funktionen sind bei Kundeninstallationen nicht erreichbar. +Belege: + - [PRIMÄR] `src/webservice/Centron.Controllers/Authorization/AuthorizeCentronHostedAttribute.cs` und `CentronHostedAuthorization.cs` - Begründung: das Attribut ist als eigener Autorisierungsmechanismus implementiert. + - [KONTEXT] `src/webservice/Centron.Controllers/Authorization/README.md`, Abschnitt „Combining with Other Authorization" - Begründung: beschreibt die vorgesehene Verwendung. +Prüfidee: Ein so gekennzeichneter Endpunkt darf in einer nicht gehosteten Installation nicht erreichbar sein. +Tracelinks: SyRS-091, StRS-052, SwRS-174 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im SaaS-Zielsystem als Betreiberschnittstelle. +Status: belegt +``` + +``` +ID: SyRS-175 +Titel: Dauerhafte Verknüpfung interner Objekte mit Fremdschlüsseln +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Fremdsystem +Vorbedingung: Ein Objekt stammt aus einem Fremdsystem oder wird dorthin übertragen. +Fakt: `ObjectExternalReferenceBL` verwaltet die Verknüpfung interner Objekte (Objektart und Objekt-ID) mit Fremdsystem-Kennungen; `ObjectExternalReferencesController` stellt sie als REST-Ressource bereit; ergänzend bestehen `Integrations/EsCustomerGroupBL.cs`, `EsRoleBL.cs`, `IntegrationsController`, `RmmController`, `DocBeeConnectorConfigurationController` und `TelekomDiveController`. +Aussage: Das System soll zu jedem aus einem Fremdsystem stammenden Objekt dessen Fremdschlüssel dauerhaft speichern, damit wiederholte Übertragungen keine Dubletten erzeugen. +Ergebnis: Wiederholte Importe aktualisieren bestehende Objekte statt neue anzulegen. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs` - Begründung: hält die Zuordnung und ist die durchsetzende Stelle der Dublettenvermeidung. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/v1/Integrations/ObjectExternalReferencesController.cs` - Begründung: die Zuordnung ist auch für Fremdsysteme abfragbar. +Prüfidee: Ein zweimal importiertes Fremdsystemobjekt darf nur einen internen Datensatz erzeugen. +Tracelinks: StRS-062, SyRS-023, SwRS-175 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Voraussetzung wiederholbarer Importe. +Status: belegt +``` + +``` +ID: SyRS-176 +Titel: Feldänderungen über viele Datensätze hinweg +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Eine gleichartige Änderung betrifft viele Datensätze. +Fakt: `MassUpdate/MassUpdateBL.cs` bildet die Massenänderung ab; das Oberflächenmodul `Massenupdates` mit `DataUpdaterAppModuleController` ist in der Region „Stammdaten" registriert; das Recht `UserRightsConst.DataUpdater` (Zeile 2801) steuert den Zugriff. +Aussage: Das System soll gleichartige Feldänderungen über eine Auswahl vieler Datensätze hinweg ausführen und den Zugriff darauf an ein eigenes Recht binden. +Ergebnis: Stammdatenpflege in großem Umfang ist ohne Einzelbearbeitung möglich. +Belege: + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, Klasse `DataUpdater`, Zeile 2801 - Begründung: eigener Rechtezweig schützt die Massenänderung. + - [PRIMÄR] `src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs` - Begründung: führt die Änderung aus. +Prüfidee: Ohne das Recht `DataUpdater` darf das Modul „Data Updater" nicht erscheinen. +Tracelinks: StRS-031, SwRS-176 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem mit Vorschau und Rücknahmemöglichkeit. +Status: belegt +``` + +``` +ID: SyRS-177 +Titel: Administrative SQL-Ausführung aus der Anwendung +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Das Recht `Administration.SQL_MANAGER` liegt vor. +Fakt: Der Rechtezweig enthält `Administration.SQL_MANAGER = 20400205`; das Modul „SQL-Manager" ist in der Region „Hilfe" registriert; im Backend besteht `Administration/SQLManagement/` mit `SQLManagementBL`, das unter anderem `GetDatabaseInfosForLicenseServer()` bereitstellt. +Aussage: Das System soll die Ausführung freier SQL-Anweisungen ausschließlich Benutzern mit dem Recht `SQL_MANAGER` erlauben. +Ergebnis: Direkter Datenbankzugriff aus der Anwendung ist auf Administratoren beschränkt. +Belege: + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, `Administration.SQL_MANAGER = 20400205` - Begründung: eigenes Recht für die SQL-Ausführung. + - [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Hilfe", Registrierung des SQL-Manager-Moduls mit Rechtebedingung - Begründung: die Bedingung schaltet das Modul frei. +Prüfidee: Ohne das Recht darf der SQL-Manager nicht im Menü erscheinen. +Tracelinks: StRS-031, SwRS-177 +Konsolidierung: nein +Übernahmewürdigkeit: veraltet - im SaaS-Zielsystem ist ein freier SQL-Zugang aus der Anwendung heraus nicht vorzusehen. +Status: belegt +``` + +``` +ID: SyRS-178 +Titel: Zeitgesteuerter Reportversand +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Controlling +Vorbedingung: Die Lizenz für den Reportserver liegt vor und das Recht `Administration.REPORTSERVER` ist vergeben. +Fakt: Der Rechtezweig enthält `Administration.REPORTSERVER = 20800044`; das Modul „Reportserver" ist in der Region „Automatisierung" registriert; die Einstellungsseite liegt unter `Modules/Administration/ReportServer/`; die Reportverwaltung nutzt `REPORT_MANAGEMENT`, `REPORTEDIT` und `GLOBALPRINTOPTIONENEDIT`. +Aussage: Das System soll Auswertungen zeitgesteuert erzeugen und an festgelegte Empfänger versenden; Einrichtung und Formularbearbeitung sind an eigene Rechte gebunden. +Ergebnis: Empfänger erhalten wiederkehrende Auswertungen ohne manuellen Anstoß. +Belege: + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, `Administration.REPORTSERVER = 20800044`, `REPORT_MANAGEMENT = 10550`, `REPORTEDIT = 20800040`, `GLOBALPRINTOPTIONENEDIT = 20800041` - Begründung: die getrennten Rechte belegen die Trennung von Betrieb und Formularpflege. + - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Administration/ReportServer/`, `Modules/Reports/ReportManagement/` - Begründung: die beiden Bedienoberflächen. +Prüfidee: Ein Benutzer mit `REPORTSERVER`, aber ohne `REPORTEDIT` darf Zeitpläne einrichten, aber keine Formulare ändern. +Tracelinks: StRS-038, StRS-054, SwRS-178 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-179 +Titel: Überwachung erwarteter, wiederkehrender Ereignisse +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Für ein Ereignis ist ein Erwartungszeitraum hinterlegt. +Fakt: `ExpectedEvents/ExpectedEventsBL.cs` bildet die erwarteten Ereignisse ab; die Rechte `Administration.SHOW_EXPECTEDEVENTS = 20800100` und `SHOW_EXPECTEDEVENTSREPORTING = 20800101` steuern Bearbeitung und Auswertung; beide Module sind in der Region „Automatisierung" getrennt registriert. +Aussage: Das System soll das Ausbleiben erwarteter, wiederkehrender Ereignisse erkennen und darüber eine gesonderte Auswertung bereitstellen. +Ergebnis: Ausgebliebene Ereignisse werden sichtbar, bevor sie fachlich wirken. +Belege: + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, `SHOW_EXPECTEDEVENTS` und `SHOW_EXPECTEDEVENTSREPORTING` - Begründung: getrennte Rechte belegen die zwei Funktionen. + - [PRIMÄR] `src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs` - Begründung: enthält die Überwachungslogik. +Prüfidee: Ein erwartetes tägliches Ereignis, das ausbleibt, muss in der Auswertung als fehlend erscheinen. +Tracelinks: StRS-062, SwRS-179 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Basis der proaktiven Überwachung. +Status: belegt +``` + +``` +ID: SyRS-180 +Titel: Produktionsauftrag mit Arbeitsschrittvorlagen +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Produktion +Vorbedingung: Eine Arbeitsschrittvorlage ist definiert. +Fakt: `Production/ProductionOrderBL.cs` und `ProductionBL.cs` führen die Aufträge; die Webanwendung stellt `ProductionOrderManagement/Pages/ProductionOrderOverView.razor` und `Components/WorkStepTemplateComponent.razor` bereit; das Schema führt `ArticleWorkItems`; `ArticleWorkItemBL` verwaltet die Arbeitsschritte am Artikel. +Aussage: Das System soll Produktionsaufträge aus Arbeitsschrittvorlagen erzeugen und den Fortschritt je Arbeitsschritt führen. +Ergebnis: Der Bearbeitungsstand jedes Arbeitsschritts ist bekannt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Production/ProductionOrderBL.cs` - Begründung: führt die Produktionsaufträge. + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `ArticleWorkItems` - Begründung: die Arbeitsschritte sind persistiert. + - [SEKUNDÄR] `src/nexus/CentronNexus/ProductionOrderManagement/Components/WorkStepTemplateComponent.razor` - Begründung: Vorlagenpflege in der Weboberfläche. +Prüfidee: Ein aus einer Vorlage mit drei Schritten erzeugter Auftrag muss drei Arbeitsschritte tragen. +Tracelinks: StRS-060, SwRS-180 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-181 +Titel: Abwesenheits- und Urlaubsverwaltung als Planungsgrundlage +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Personalverwaltung +Vorbedingung: Mitarbeiterstammdaten sind gepflegt. +Fakt: `EmployeeArea` enthält `EmployeeHolidayBL`, `EmployeeDepartmentBL`, `EmployeeSkillsBL`, `EmployeeArticleBL`, `EmployeeRfidTokenBL`, `EmployeeStatisticBL`, `TeamManagement` sowie `EmployeeUserSettingsBL`; das Schema führt `HolidayArea` und `ScheduleArea`; das Recht `Administration.EmployeeManagement.ADMINISTRATE_ALL_EMPLOYEES` erlaubt die Verwaltung aller Mitarbeiter. +Aussage: Das System soll Abwesenheiten, Abteilungszugehörigkeit, Qualifikationen und Mitarbeiterartikel führen und diese Angaben für die Einsatzplanung bereitstellen; die Verwaltung fremder Mitarbeiter erfordert ein eigenes Recht. +Ergebnis: Die Einsatzplanung berücksichtigt Abwesenheiten und Qualifikationen. +Belege: + - [PRIMÄR] `src/webservice/…/UserRightsConst.cs`, `Administration.EmployeeManagement.ADMINISTRATE_ALL_EMPLOYEES = 20400053` - Begründung: das Recht trennt die Verwaltung eigener und fremder Mitarbeiterdaten. + - [PRIMÄR] `src/backend/Centron.BL/EmployeeArea/EmployeeHolidayBL.cs`, `EmployeeSkillsBL.cs`, `EmployeeArticleBL.cs` - Begründung: führen Abwesenheiten, Qualifikationen und Mitarbeiterartikel. + - [SEKUNDÄR] `src/backend/Centron.Entities/Entities/HolidayArea/`, `ScheduleArea/` - Begründung: die Datenstrukturen der Abwesenheits- und Einsatzplanung. +Prüfidee: Ein abwesender Mitarbeiter darf in der Einsatzplanung des Abwesenheitszeitraums nicht als verfügbar erscheinen. +Tracelinks: StRS-061, StRS-042, SwRS-181 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen +Status: belegt +``` + +``` +ID: SyRS-182 +Titel: Mitarbeiterartikel als Bindeglied zwischen Person und Leistung +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Serviceleitung +Vorbedingung: Ein Mitarbeiter erbringt abrechenbare Leistungen. +Fakt: `EmployeeArea/EmployeeArticleBL.cs` und der REST-Endpunkt `EmployeeArticlesController` verknüpfen Mitarbeiter mit Artikeln; `HelpdeskTimerBL.GetEmployeeTimeStatistics(ICollection articleI3Ds, DateTime? dateFrom, DateTime? dateTo)` wertet Zeiten über Artikel-IDs aus; das Recht `OWN_TIME_EDIT` ist laut Rechtebeschreibung daran gebunden, dass „the employee article of the time record must belong to the user". +Aussage: Das System soll jedem Mitarbeiter einen Leistungsartikel zuordnen, über den seine Zeiten bewertet, ausgewertet und rechtlich zugeordnet werden. +Ergebnis: Zeiten sind eindeutig einem Mitarbeiter und einem Verrechnungssatz zugeordnet. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `GetEmployeeTimeStatistics(ICollection articleI3Ds, …)`, Zeile 710 - Begründung: die Auswertung erfolgt tatsächlich über Artikel-IDs, nicht über Mitarbeiter-IDs. + - [KONTEXT] `CentronRights.md`, Abschnitt 7.1: „the employee article of the time record must belong to the user" - Begründung: benennt die Rechtewirkung des Mitarbeiterartikels. + - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/v1/Administration/EmployeeArticlesController.cs` - Begründung: eigene REST-Ressource. +Prüfidee: Ein Zeiteintrag mit dem Mitarbeiterartikel eines Kollegen darf durch einen Benutzer mit `OWN_TIME_EDIT` nicht bearbeitbar sein. +Tracelinks: StRS-014, StRS-061, SwRS-182 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - im Zielsystem ist die indirekte Zuordnung über den Artikel zu prüfen und gegebenenfalls zu vereinfachen. +Status: belegt +``` + +``` +ID: SyRS-183 +Titel: Kundenaktivitäten als durchgängige Kontakthistorie +Ebene: SyRS +Typ: funktional +Qualitätsmerkmal: +Akteur: Vertrieb +Vorbedingung: Ein Vorgang berührt einen Kunden. +Fakt: `AccountActivitiesBL` erzeugt Aktivitäten an definierten Stellen: `CreateActivityForNewReceipt` und `CreateActivityForNewReceiptVersion` in `ReceiptBL.SaveReceipt` (gesteuert über `_specificLogics.Execute(receipt, f => f.CreatesAccountActivities())`) sowie `CreateActivityForTicketClosed` in `HelpdeskCloseBL.CloseHelpdesk`; `ReceiptBL.GetAccountActivitiesForReceipt` und `GetReceiptsForAccountActivity` liefern die Verknüpfung in beide Richtungen. +Aussage: Das System soll zu jedem kundenwirksamen Vorgang automatisch eine Kundenaktivität erzeugen, sofern die Belegart dies vorsieht, und die Verknüpfung zwischen Aktivität und Beleg in beide Richtungen auflösbar halten. +Ergebnis: Die Kundenhistorie enthält alle relevanten Vorgänge ohne manuelle Erfassung. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Bedingung `if (this._specificLogics.Execute(receipt, f => f.CreatesAccountActivities())) this._accountActivitiesBL.CreateActivityForNewReceipt(receipt, currentUser);` - Begründung: die Bedingung entscheidet über die Erzeugung und ist damit die durchsetzende Stelle. + - [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, `public bool CreatesAccountActivities() => true;`, Zeile 544 - Begründung: legt für Rechnungen fest, dass Aktivitäten entstehen. + - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `GetAccountActivitiesForReceipt` (Zeile 545) und `GetReceiptsForAccountActivity` (Zeile 540) - Begründung: belegen die beidseitige Auflösung. +Prüfidee: Das Speichern einer neuen Rechnung muss eine Kundenaktivität erzeugen, das Speichern eines Belegs einer Belegart mit `CreatesAccountActivities() == false` nicht. +Tracelinks: StRS-001, StRS-016, SwRS-183 +Konsolidierung: nein +Übernahmewürdigkeit: übernehmen - Kern des CRM-Nutzens. +Status: belegt +``` + +## 13. Zugangsdatenverwaltung und Geräteführung + +``` +ID: SyRS-130 +Titel: Verschlüsselte Ablage und protokollierter Zugriff auf Zugangsdaten +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Servicetechniker +Vorbedingung: Für ein Kundensystem sind Zugangsdaten hinterlegt. +Fakt: `PasswordManagerBL` legt Kennwörter als Zusatzfeld vom Typ `CustomizationDataTypes.EncryptedText` ab und verschlüsselt sie über `new AESCryptoLogic().EncryptText(customerHotline.Password, masterKeyResult.Data)` mit dem über `CentronConfigurationDbBL.GetHotlineMasterKey()` bezogenen Schlüssel; `GetPasswordManagerProperyValueEncryptedString(LoggedInUser loggedInUser, int propertyValueI3D)` gibt den Wert nur unter Angabe des angemeldeten Benutzers heraus; im Vorgängermodul protokolliert `PasswordManagementAccessLogBL.SavePasswordManagementAccessLog(int, PasswordManagementActionTypeEnum, AppUser)` jeden Zugriff mit Benutzer und Zeitpunkt. +Aussage: Das System soll Zugangsdaten ausschließlich verschlüsselt ablegen, sie nur an einen angemeldeten Benutzer herausgeben und jeden Lesezugriff mit Benutzer und Zeitpunkt protokollieren. +Ergebnis: Kennwörter liegen nicht im Klartext vor; jeder Zugriff ist nachvollziehbar. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeile 700, `propertyValue.ValueEncryptedString = new AESCryptoLogic().EncryptText(customerHotline.Password, masterKeyResult.Data)` - Begründung: die Verschlüsselung mit verwaltetem Schlüssel erfolgt an dieser Stelle. + - [PRIMÄR] `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, `GetPasswordManagerProperyValueEncryptedString(LoggedInUser loggedInUser, int propertyValueI3D)`, Zeile 538 - Begründung: die Herausgabe ist an den angemeldeten Benutzer gebunden. + - [PRIMÄR] `src/backend/Centron.BL/PasswordManagementArea/PasswordManagementAccessLogBL.cs`, `SavePasswordManagementAccessLog`, Zeilen 33-42, mit `pmAccessLog.Date = DateTime.Now; pmAccessLog.EmployeeI3D = user.Employee.I3D;` - Begründung: die Zugriffsprotokollierung ist dort durchgesetzt. +Prüfidee: Ein Lesezugriff auf ein Kennwort muss einen Protokolleintrag mit Mitarbeiter und Zeitstempel erzeugen; der Datenbankwert darf den Klartext nicht enthalten. +Tracelinks: StRS-047, SwRS-130, SwRS-131 +Konsolidierung: Kandidat: SyRS-131 — Passwort-Manager und Altmodul führen Zugangsdaten in getrennten Datenhaltungen. +Übernahmewürdigkeit: übernehmen - für den Servicebetrieb erforderlich; im Zielsystem als eigener Geheimnisspeicher. +Status: belegt +``` + +``` +ID: SyRS-131 +Titel: Unvollständige Kennwortspeicherung im abgelösten Zugangsdatenmodul +Ebene: SyRS +Typ: Sicherheit +Qualitätsmerkmal: +Akteur: Administrator +Vorbedingung: Eine Installation nutzt noch das alte Zugangsdatenmodul. +Fakt: `PasswordManagementKeywordBL.AddNewKeyword(int passwordManagementI3D, string username, string password, AppUser user)` setzt `keyword.Salt = ""` und `keyword.Password = ""` und verwirft damit das übergebene Kennwort; `GetDecryptedKeywordById` enthält den Kommentar `// decryption` ohne Implementierung und gibt `keyword.Password` unverändert zurück. Der Modulkatalog führt den zugehörigen Bereich als `#region c-entron Module: Passwort Manager (obsolate)`. +Aussage: Das System soll das abgelöste Zugangsdatenmodul für Neuanlagen sperren und dessen Bestände in den aktuellen Passwort-Manager überführen, da im Altmodul weder Kennwort noch Salt gespeichert werden. +Ergebnis: Zugangsdaten werden ausschließlich über den verschlüsselnden Passwort-Manager geführt. +Belege: + - [PRIMÄR] `src/backend/Centron.BL/PasswordManagementArea/PasswordManagementKeywordBL.cs`, Zeilen 47-49, `keyword.Salt = ""; keyword.Password = "";` - Begründung: die Zuweisungen verwerfen das Kennwort und belegen die Funktionslücke. + - [PRIMÄR] `src/backend/Centron.BL/PasswordManagementArea/PasswordManagementKeywordBL.cs`, `GetDecryptedKeywordById`, Zeilen 21-35, Kommentar `// decryption` ohne Entschlüsselungscode - Begründung: die vorgesehene Entschlüsselung fehlt. + - [KONTEXT] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Regionsbezeichnung „Passwort Manager (obsolate)" - Begründung: kennzeichnet den Bereich als überholt. +Prüfidee: Eine Neuanlage im Altmodul darf im Zielsystem nicht mehr angeboten werden; bestehende Einträge müssen im aktuellen Passwort-Manager erscheinen. +Tracelinks: StRS-048, SyRS-130, SwRS-132 +Konsolidierung: Kandidat: SyRS-130 +Übernahmewürdigkeit: veraltet - das Modul ist im Code als obsolet gekennzeichnet und erfüllt seine Aufgabe nicht mehr. +Status: belegt +``` + +``` +ID: SyRS-140 +Titel: Mehrfache Datenhaltung installierter Geräte +Ebene: SyRS +Typ: Daten +Qualitätsmerkmal: +Akteur: Servicetechniker, Vertrieb +Vorbedingung: Beim Kunden ist Hardware installiert. +Fakt: Für denselben fachlichen Gegenstand „installiertes Gerät" bestehen vier getrennte Datenhaltungen mit je eigener Fachlogik: Stammblatt (`MasterDataList`, Tabelle `Stammdat`, Fachlogik über `ContractBL.GetMasterDataListFromContract`), Account-Gerät (`AccountDevice`, Tabellen `AccountDevices` und `AccountDevicesToTickets`, Fachlogik `AccountDeviceBL`), Asset-Management-Gerät (Tabellen `AssetManagementDevices` und weitere, Fachlogik `Centron.BL/DocuBoard`) und Kunden-Asset (`CustomerAsset`/`AssetBase`, Fachlogik `AssetBL`, `CustomerAssetBL`); zusätzlich besteht die Tabelle `GeraeteKopf`. +Aussage: Das System soll installierte Geräte mit Seriennummer, Standort, Vertrags- und Belegbezug sowie Servicehistorie führen; im Zielsystem ist dafür genau eine Datenhaltung vorzusehen. +Ergebnis: Ein Gerät ist über alle Sichten hinweg unter einer Identität auffindbar. +Belege: + - [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `Stammdat`, `AccountDevices`, `AccountDevicesToTickets`, `AssetManagementDevices`, `GeraeteKopf` - Begründung: die getrennten Datenhaltungen sind im Schema durchgesetzt. + - [PRIMÄR] `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs`, Felder `SerialNumber`, `InvoiceI3D`, `ContractI3D`, `CounterDevice` gegenüber `src/backend/Centron.Entities/Entities/Devices/AccountDevice.cs` - Begründung: beide Entitäten beschreiben dasselbe Gerät mit unterschiedlichem Feldbestand. + - [SEKUNDÄR] `src/backend/Centron.BL/Devices/AccountDeviceBL.cs`, `src/backend/Centron.BL/Sales/CustomerAssets/AssetBL.cs`, `src/backend/Centron.BL/DocuBoard/` - Begründung: drei getrennte Fachlogikbäume für denselben Gegenstand. +Prüfidee: Ein Gerät mit bekannter Seriennummer muss in Stammblattsuche, Gerätesuche am Account und Asset-Management denselben Gegenstand bezeichnen. +Tracelinks: StRS-049, SwRS-140, SwRS-141, SwRS-142, SwRS-143 +Konsolidierung: Kandidat: SwRS-140, SwRS-141, SwRS-142, SwRS-143 — Stammblatt, Account-Gerät, Asset-Management-Gerät und Kunden-Asset bilden denselben fachlichen Gegenstand in vier getrennten Datenhaltungen ab und sind im Zielsystem zu einem Asset-Konzept zusammenzuführen. +Übernahmewürdigkeit: übernehmen - der fachliche Gegenstand bleibt erforderlich, die Mehrfachhaltung nicht. +Status: belegt +``` diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Traceability.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Traceability.md new file mode 100644 index 00000000..5d163514 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse/Traceability.md @@ -0,0 +1,330 @@ +# Traceability-Tabelle + +Konsolidierte Forward- und Backward-Traceability über die drei Ebenen. +Die Tabelle wird aus den Feldern `Tracelinks` und `Belege` der Anforderungsdateien abgeleitet. +Spalte `Artefaktbeleg` nennt den ersten `PRIMÄR`-Beleg der SwRS-Anforderung (bei Zeilen ohne SwRS den der SyRS- beziehungsweise StRS-Anforderung). +Ein Strich bedeutet, dass auf dieser Ebene keine eigene Anforderung besteht. + +| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg | +|---|---|---|---| +| StRS-001 | SyRS-001 | — | `src/backend/Centron.BL/Accounts/AccountBL.cs`, Rechteprüfung über `new AppRightsBL(Session).CheckRightsFromUser(currentUserI3D, …)` mit anschließender Prüfung `checkRightsResult.Contains(CREATE_CUSTOMER) == false` | +| StRS-001 | SyRS-002 | SwRS-002 | `src/centron/Centron.WPF.UI/Modules/CentronModule.cs`, Prüfung `module.SupportsConnectionTypes` mit Verzweigung auf `CentronConnectionType.CentronWebServices` | +| StRS-001 | SyRS-002 | SwRS-006 | `src/backend/Centron.Entities/Entities/BaseEntity.cs`, `BaseLongEntity.cs`, `DBEntity.cs`, `PersistedEntity.cs`, `PersistedLongEntity.cs` | +| StRS-001 | SyRS-002 | SwRS-056 | `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `AddSurvey`, Zeilen 209-233, mit der Bedingung `if (contact.Data != null)` | +| StRS-001 | SyRS-002 | SwRS-193 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Adressen/CRM", Registrierung `AccountContractsAppModuleController` mit `IsAccountManagementActive` und `SHOW_CONTRACT` | +| StRS-001 | SyRS-003 | SwRS-018 | `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitt „Address Information" mit der Aufzählung der kopierten Adressfelder in `ReceiptBase` | +| StRS-001 | SyRS-003 | SwRS-143 | `src/backend/Centron.Entities/Entities/Sales/CustomerAssets/CustomerAsset.cs`, Zeilen 14-48, die vier Betreuerfelder mit ihren Kommentaren und die berechnete `Address` | +| StRS-001 | SyRS-084 | SwRS-083 | `src/backend/Centron.BL/Sales/Receipts/Orders/OrderSpecificLogic.cs`, `BlockNewReceiptsDunningLevel`, Zeilen 687-693 | +| StRS-001 | SyRS-183 | SwRS-016 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Block `if (isTemplate) { data.IgnoreCallbacks = true; … }` mit dem Kommentar „We automatically ignore all callbacks when saving a receipt-template" | +| StRS-001 | SyRS-183 | SwRS-183 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `GetReceiptsForAccountActivity` (Zeile 540), `GetAccountActivitiesForReceipt` (Zeile 545) mit `loadActivitiesFromProcessedReceipts`, `SaveAccountActivityForReceipt` (Zeile 623), `DeleteAccountActivityForReceipt` (Zeile 629) | +| StRS-002 | — | — | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Adressen/CRM", Bedingung `() => !CentronCache.Instance.CrmSettings.IsAccountManagementActive.GetValueOrDefault(false)` | +| StRS-003 | SyRS-010 | SwRS-005 | `SSMS_DB_SCHEMA.sql`, Tabellen `AngKopf`, `AufKopf`, `LiefKopf`, `RechKopf`, `VertragKopf`, `GutKopf`, `AbholKopf` mit ihren Positionstabellen | +| StRS-003 | SyRS-010 | SwRS-009 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt` mit `return this.Session.WithTransaction(() => { … })` | +| StRS-003 | SyRS-010 | SwRS-010 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt(IReceiptBase receipt, …)`, Zeilen 3519-3521 mit `MakeGenericMethod(...).Invoke(...)` | +| StRS-003 | SyRS-010 | SwRS-024 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `GetReceiptProgression`, Zeile 4767, mit Parameter `limit` | +| StRS-003 | SyRS-010 | SwRS-026 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Validate DeliveryList: Related to order with down payments?", Zeile 2483 | +| StRS-003 | SyRS-018 | SwRS-018 | `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitt „Address Information" mit der Aufzählung der kopierten Adressfelder in `ReceiptBase` | +| StRS-003 | SyRS-018 | SwRS-191 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „IReceiptWithLeasingAndService", Zeile 2838 | +| StRS-003 | SyRS-019 | SwRS-019 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `GetHelpdeskInfosForReceipt` (Zeile 4405) und `CreateTicketsForReceipt` (Zeile 4445) | +| StRS-004 | SyRS-067 | SwRS-068 | `src/apis/Centron.Api.Gls/CentronGlsErrors.cs` und `src/apis/Centron.Api.Shipcloud/Entities/` | +| StRS-004 | SyRS-067 | SwRS-069 | `src/backend/Centron.BL/Sales/Receipts/ShipcloudPackageTemplateBL.cs` | +| StRS-005 | SyRS-006 | — | `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `GetActiveVatThroughNextVats`, Zeilen 45-54 | +| StRS-005 | SyRS-020 | SwRS-003 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, `Result.AsError(..., DefaultMessageCodes.NoUsernameOrPassword)` | +| StRS-005 | SyRS-020 | SwRS-020 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, die vier genannten Methoden mit den Aufrufen von `_specificLogics.Execute(..., f => f.HasRightToCreateANewReceipt/HasRightToEditReceipt/HasRightToViewReceipt)` | +| StRS-006 | — | — | `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs`, Klasse `CustomerCommon.CreditVoucher`, Zeile 2331 | +| StRS-007 | — | — | `src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs`, Werte `PickupList = 5`, `CashOffer = 20`, `CashInvoice = 21` | +| StRS-008 | SyRS-030 | SwRS-017 | `SSMS_DB_SCHEMA.sql`, Tabelle `Zahkond` | +| StRS-008 | SyRS-030 | SwRS-030 | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs`, die genannten Eigenschaften | +| StRS-008 | SyRS-033 | SwRS-033 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `SearchSpecialArticleToContractHead`, Zeilen 319-327 | +| StRS-008 | SyRS-033 | SwRS-088 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `CreateSpecialArticleToContractFromMspEvaluation`, Zeile 129 | +| StRS-008 | SyRS-033 | SwRS-197 | `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs` | +| StRS-008 | SyRS-085 | SwRS-084 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Mandat" in `ForwardReceipt`, Zeile 2831 | +| StRS-009 | SyRS-032 | SwRS-032 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `SearchCustomers` mit `NamedQueryAccess().GetNamedQuery(NamedQueryEnums.Asset.GetCustomersForAutomatedBilling)` (Zeile 457) und `SearchBillingOrders` mit `GetOrdersForAutomatedBilling` (Zeile 118) | +| StRS-010 | — | — | `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs`, Eigenschaft `CounterDevice` | +| StRS-011 | — | — | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Abrechnung", Registrierung `FlatRateProjectAppModuleController` mit `Helper.HasRights(…FLATRATE_BILLING_MODULE)` | +| StRS-012 | SyRS-030 | SwRS-017 | `SSMS_DB_SCHEMA.sql`, Tabelle `Zahkond` | +| StRS-012 | SyRS-030 | SwRS-030 | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs`, die genannten Eigenschaften | +| StRS-012 | SyRS-035 | SwRS-035 | `src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs`, `SearchTimers` (Zeile 233), `GetContracts(List customerI3Ds, List alwaysIncludeContractI3Ds)` (Zeile 153) | +| StRS-012 | SyRS-035 | SwRS-180 | `SSMS_DB_SCHEMA.sql`, Tabelle `ArticleWorkItems` | +| StRS-012 | SyRS-036 | SwRS-036 | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `CalculateHourlySurchargeRateOverlaps` in den Zeilen 173, 180, 187 und 235 | +| StRS-013 | SyRS-034 | SwRS-034 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `GetRightsForModule`, Zeilen 220-223, `_modules.FirstOrDefault(f => f.ModuleType == controller.GetType())?.GetRights()` | +| StRS-013 | SyRS-034 | SwRS-109 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 249-254 und 405-408, die beiden Bedingungen für persönliche und administrative Tokenverwaltung | +| StRS-014 | SyRS-035 | SwRS-035 | `src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs`, `SearchTimers` (Zeile 233), `GetContracts(List customerI3Ds, List alwaysIncludeContractI3Ds)` (Zeile 153) | +| StRS-014 | SyRS-035 | SwRS-180 | `SSMS_DB_SCHEMA.sql`, Tabelle `ArticleWorkItems` | +| StRS-014 | SyRS-036 | SwRS-036 | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `CalculateHourlySurchargeRateOverlaps` in den Zeilen 173, 180, 187 und 235 | +| StRS-014 | SyRS-040 | SwRS-040 | `src/backend/Centron.BL/Sales/Support/HelpdeskTimeRecordingBL.cs`, Signaturen mit `string guid` in `PauseRecording` (Zeile 277), `ResumeRecording` (317), `StopRecording` (357), `ClearRecording` (398) | +| StRS-014 | SyRS-042 | SwRS-042 | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs`, `AddSignature` (Zeile 31) mit vorangehender Prüfung `HelpdeskSignatureExists` (Zeile 62) und `GetSignature` (Zeile 67) | +| StRS-014 | SyRS-042 | SwRS-043 | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs`, Zeile 51, Aufruf `AddSignatureLog(new HelpdeskTimerBL(this.Session).GetHelpdeskTimerByI3D(helpdeskTimerI3D), currentUser)` | +| StRS-014 | SyRS-182 | SwRS-182 | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `GetEmployeeTimeStatistics(ICollection articleI3Ds, …)`, Zeile 710 | +| StRS-015 | — | — | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs`, `AddSignature` Zeile 31 mit Prüfung `HelpdeskSignatureExists` Zeile 62 | +| StRS-016 | SyRS-019 | SwRS-019 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `GetHelpdeskInfosForReceipt` (Zeile 4405) und `CreateTicketsForReceipt` (Zeile 4445) | +| StRS-016 | SyRS-050 | SwRS-050 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `DoValidateMandatoryFields`, Zeile 658, mit `var messageBuilder = new StringBuilder();` und `messageBuilder.AppendLine("Kein Kunde ausgewählt");` | +| StRS-016 | SyRS-051 | SwRS-051 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `DoBeforeSave`, Zeilen 310-326 | +| StRS-016 | SyRS-051 | SwRS-054 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckUserRigths`, Zeilen 433-443, mit `else { entity.ClosedAt = null; }` | +| StRS-016 | SyRS-051 | SwRS-057 | `src/backend/Centron.BL/Sales/Support/` mit den genannten 49 Klassen | +| StRS-016 | SyRS-054 | SwRS-007 | `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `UpdateArticleVATs` mit `NamedQueryAccess
().GetNamedQuery(NamedQueryEnums.ValueAddedTax.UpdateArticleVatsAndPrices, parameters)` | +| StRS-016 | SyRS-054 | SwRS-054 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckUserRigths`, Zeilen 433-443, mit `else { entity.ClosedAt = null; }` | +| StRS-016 | SyRS-054 | SwRS-055 | `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `CloseHelpdesk(IList, AppUser)`, Zeilen 108-118 | +| StRS-016 | SyRS-054 | SwRS-202 | `src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs` | +| StRS-016 | SyRS-057 | SwRS-057 | `src/backend/Centron.BL/Sales/Support/` mit den genannten 49 Klassen | +| StRS-016 | SyRS-057 | SwRS-213 | `src/backend/Centron.BL/Sales/Support/ExternalToolsReplacementBL.cs` | +| StRS-016 | SyRS-058 | SwRS-058 | `src/nexus/CentronNexus/Management/TicketPatterns/Components/` mit den neun genannten Reiterkomponenten und `TicketPatternTree.razor` | +| StRS-016 | SyRS-058 | SwRS-125 | `src/nexus/CentronNexus/Management/TicketPatterns/Components/SelfCareFormFieldGrid.razor` und `SelfCareFormFieldEditPopup.razor` | +| StRS-016 | SyRS-058 | SwRS-195 | `src/backend/Centron.BL/Sales/Support/TicketProcess/` und `src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs` | +| StRS-016 | SyRS-059 | SwRS-059 | `src/nexus/CentronNexus/ServiceBoard/CachedTicketList/Components/` mit `FilterEditorGroup.razor`, `ConditionalFormattingEditor.razor`, `SummaryEditor.razor`, `KanbanBucketSelection.razor` | +| StRS-016 | SyRS-125 | SwRS-058 | `src/nexus/CentronNexus/Management/TicketPatterns/Components/` mit den neun genannten Reiterkomponenten und `TicketPatternTree.razor` | +| StRS-016 | SyRS-125 | SwRS-125 | `src/nexus/CentronNexus/Management/TicketPatterns/Components/SelfCareFormFieldGrid.razor` und `SelfCareFormFieldEditPopup.razor` | +| StRS-016 | SyRS-183 | SwRS-016 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Block `if (isTemplate) { data.IgnoreCallbacks = true; … }` mit dem Kommentar „We automatically ignore all callbacks when saving a receipt-template" | +| StRS-016 | SyRS-183 | SwRS-183 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `GetReceiptsForAccountActivity` (Zeile 540), `GetAccountActivitiesForReceipt` (Zeile 545) mit `loadActivitiesFromProcessedReceipts`, `SaveAccountActivityForReceipt` (Zeile 623), `DeleteAccountActivityForReceipt` (Zeile 629) | +| StRS-017 | SyRS-120 | SwRS-025 | `src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs` | +| StRS-017 | SyRS-120 | SwRS-120 | `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, `GetWebRightByI3D` (Zeile 121), `GetWebRightsCategoriesByI3D` (Zeile 126), `GetAllWebRightsFromWebAccount` (Zeile 141) | +| StRS-017 | SyRS-120 | SwRS-121 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserViewReceipt` mit `if (loggedInUser.IsWebAccountLogin)` | +| StRS-018 | SyRS-055 | — | `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `CanCloseHelpdesk`, Zeilen 159-167 | +| StRS-018 | SyRS-060 | SwRS-060 | `src/backend/Centron.BL/CustomerArea/RmaBL.cs`, Verwendungen von `BarcodeState.*` in den Zeilen 179, 192, 201, 266, 312-313 | +| StRS-019 | — | — | `src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs` und `CheckListArea/ChangeTracking/` | +| StRS-020 | — | — | `src/nexus/CentronNexus/Management/TaskManagement/Components/TaskTabTickets.razor` | +| StRS-021 | SyRS-060 | SwRS-060 | `src/backend/Centron.BL/CustomerArea/RmaBL.cs`, Verwendungen von `BarcodeState.*` in den Zeilen 179, 192, 201, 266, 312-313 | +| StRS-021 | SyRS-066 | SwRS-067 | `src/backend/Centron.BL/Warehousing/ArticleManagement/` mit den neun genannten Klassen | +| StRS-022 | SyRS-062 | SwRS-062 | `src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryNewBL.cs`, `ChangeInventoryGroup` (Zeile 331) und `GetInventoryGroupArticles` (Zeile 251) | +| StRS-022 | SyRS-062 | SwRS-063 | `src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryBL.cs` und `InventoryNewBL.cs` | +| StRS-023 | SyRS-063 | SwRS-064 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptQuantityPicked`, Zeile 5031 | +| StRS-024 | SyRS-070 | SwRS-070 | `src/backend/Centron.BL/Sales/Receipts/SupplierOrders/`, `SupplierDeliveryLists/`, `SupplierInvoices/`, `SupplierCreditVouchers/` | +| StRS-024 | SyRS-073 | SwRS-073 | `src/apis/Centron.APIs.CopDataAccess/CopApi.cs`, `CopException.cs`, `Data/` | +| StRS-024 | SyRS-075 | SwRS-075 | `src/backend/Centron.BL/Purchasing/OrderSuggestionList/` | +| StRS-024 | SyRS-076 | SwRS-076 | `src/backend/Centron.BL/Purchasing/SupplierOrderPerBranchBL.cs` | +| StRS-024 | SyRS-076 | SwRS-199 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Buchhaltung/Finanzen", Kommentar „Kalkulation pro Filiale" | +| StRS-025 | SyRS-071 | SwRS-071 | `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs` und `EDICommonBL.cs` | +| StRS-025 | SyRS-071 | SwRS-072 | `src/backend/Centron.BL/EDI/Zugferd/ZUGFeRD_BL.cs`, `ReadInvoice`, Zeile 38, mit den Parametern `List` und `List>` | +| StRS-025 | SyRS-071 | SwRS-087 | `src/backend/Centron.BL/DataExchange/` mit den zehn genannten Unterzweigen | +| StRS-025 | SyRS-072 | SwRS-071 | `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs` und `EDICommonBL.cs` | +| StRS-025 | SyRS-072 | SwRS-072 | `src/backend/Centron.BL/EDI/Zugferd/ZUGFeRD_BL.cs`, `ReadInvoice`, Zeile 38, mit den Parametern `List` und `List>` | +| StRS-026 | — | — | `src/backend/Centron.BL/EDI/Zugferd/ZUGFeRD_BL.cs`, `ReadInvoice`, Zeile 38 | +| StRS-027 | SyRS-009 | SwRS-080 | `SSMS_DB_SCHEMA.sql`, Tabellen `ArtikelBranchErloeskonto`, `UnterwarenFilialeErloeskonto`, `WarenFilialeErloeskonto` | +| StRS-027 | SyRS-080 | SwRS-080 | `SSMS_DB_SCHEMA.sql`, Tabellen `ArtikelBranchErloeskonto`, `UnterwarenFilialeErloeskonto`, `WarenFilialeErloeskonto` | +| StRS-027 | SyRS-080 | SwRS-198 | `SSMS_DB_SCHEMA.sql`, Tabellen `Kostenstellen`, `Kostentraeger` | +| StRS-027 | SyRS-080 | SwRS-199 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Buchhaltung/Finanzen", Kommentar „Kalkulation pro Filiale" | +| StRS-028 | SyRS-017 | SwRS-017 | `SSMS_DB_SCHEMA.sql`, Tabelle `Zahkond` | +| StRS-028 | SyRS-081 | SwRS-081 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptIsPaid(…, string moduleOrAction, AppUser currentUser)`, Zeile 4902 | +| StRS-028 | SyRS-086 | SwRS-085 | `src/apis/Centron.APIs.FinAPI/Data/AccessToken.cs` | +| StRS-028 | SyRS-087 | SwRS-086 | `src/backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentBL.cs`, `CreateIncomingPaymentLogItem(IncomingPaymentLog logItem)`, Zeile 21 | +| StRS-028 | SyRS-088 | SwRS-087 | `src/backend/Centron.BL/DataExchange/` mit den zehn genannten Unterzweigen | +| StRS-029 | SyRS-082 | SwRS-082 | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs`, Zeilen 253-270, Zuweisungen `invoice.DunningLevel1Date = DateTime.Now; invoice.DunningLevel1Employee = loggedInUser.UserI3D;` | +| StRS-029 | SyRS-083 | SwRS-082 | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs`, Zeilen 253-270, Zuweisungen `invoice.DunningLevel1Date = DateTime.Now; invoice.DunningLevel1Employee = loggedInUser.UserI3D;` | +| StRS-029 | SyRS-085 | SwRS-084 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Mandat" in `ForwardReceipt`, Zeile 2831 | +| StRS-030 | SyRS-084 | SwRS-083 | `src/backend/Centron.BL/Sales/Receipts/Orders/OrderSpecificLogic.cs`, `BlockNewReceiptsDunningLevel`, Zeilen 687-693 | +| StRS-031 | SyRS-001 | — | `src/backend/Centron.BL/Accounts/AccountBL.cs`, Rechteprüfung über `new AppRightsBL(Session).CheckRightsFromUser(currentUserI3D, …)` mit anschließender Prüfung `checkRightsResult.Contains(CREATE_CUSTOMER) == false` | +| StRS-031 | SyRS-020 | SwRS-003 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, `Result.AsError(..., DefaultMessageCodes.NoUsernameOrPassword)` | +| StRS-031 | SyRS-020 | SwRS-020 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, die vier genannten Methoden mit den Aufrufen von `_specificLogics.Execute(..., f => f.HasRightToCreateANewReceipt/HasRightToEditReceipt/HasRightToViewReceipt)` | +| StRS-031 | SyRS-042 | SwRS-042 | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs`, `AddSignature` (Zeile 31) mit vorangehender Prüfung `HelpdeskSignatureExists` (Zeile 62) und `GetSignature` (Zeile 67) | +| StRS-031 | SyRS-042 | SwRS-043 | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs`, Zeile 51, Aufruf `AddSignatureLog(new HelpdeskTimerBL(this.Session).GetHelpdeskTimerByI3D(helpdeskTimerI3D), currentUser)` | +| StRS-031 | SyRS-051 | SwRS-051 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `DoBeforeSave`, Zeilen 310-326 | +| StRS-031 | SyRS-051 | SwRS-054 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckUserRigths`, Zeilen 433-443, mit `else { entity.ClosedAt = null; }` | +| StRS-031 | SyRS-051 | SwRS-057 | `src/backend/Centron.BL/Sales/Support/` mit den genannten 49 Klassen | +| StRS-031 | SyRS-065 | SwRS-066 | `SSMS_DB_SCHEMA.sql`, Tabellen `Produktfamilie`, `ProduktfamilieKundenSperren`, `ProduktfamiliePositionSperren` | +| StRS-031 | SyRS-065 | SwRS-067 | `src/backend/Centron.BL/Warehousing/ArticleManagement/` mit den neun genannten Klassen | +| StRS-031 | SyRS-086 | SwRS-085 | `src/apis/Centron.APIs.FinAPI/Data/AccessToken.cs` | +| StRS-031 | SyRS-090 | SwRS-090 | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `GetRightsFromCurrentUser` (Zeile 63) und `CheckRightsFromUser` (Zeile 93) | +| StRS-031 | SyRS-091 | SwRS-003 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, `Result.AsError(..., DefaultMessageCodes.NoUsernameOrPassword)` | +| StRS-031 | SyRS-091 | SwRS-091 | `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs`, `AuthorizeAnyUserRightAttribute.cs`, `AuthorizeAllUserRightsAttribute.cs` | +| StRS-031 | SyRS-102 | SwRS-101 | `src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs` | +| StRS-031 | SyRS-102 | SwRS-212 | `src/backend/Centron.BL/Mobile/MobileBL.cs` und `src/backend/Centron.Entities/Entities/Mobile/` | +| StRS-031 | SyRS-109 | SwRS-108 | `src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs`, `_logBL.LogAction(accessToken, AccessTokenLogActionType.Created, …, ipAddress)` (Zeile 185) und die `ValidationFailed`-Aufrufe (Zeilen 396, 403) | +| StRS-031 | SyRS-109 | SwRS-109 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 249-254 und 405-408, die beiden Bedingungen für persönliche und administrative Tokenverwaltung | +| StRS-031 | SyRS-170 | SwRS-034 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `GetRightsForModule`, Zeilen 220-223, `_modules.FirstOrDefault(f => f.ModuleType == controller.GetType())?.GetRights()` | +| StRS-031 | SyRS-170 | SwRS-170 | `src/backend/Centron.BL/Statistics/` mit den neun genannten Unterbereichen | +| StRS-031 | SyRS-170 | SwRS-190 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Controlling/Analytics", Kommentar „Vertragsauswertung" mit der Registrierung von `ContractEvaluation2` | +| StRS-031 | SyRS-170 | SwRS-210 | `src/webservice/…/UserRightsConst.cs`, Klasse `VideoPortal`, Zeile 2786 | +| StRS-031 | SyRS-170 | SwRS-215 | `src/nexus/CentronNexus/ServiceBoard/Dashboard/DashboardMyTicketStats.razor`, `DashboardMyTimerecordStats.razor`, `DashboardMyDayList.razor` | +| StRS-031 | SyRS-176 | SwRS-176 | `src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs` und `src/backend/Centron.Entities/Entities/MassUpdate/` | +| StRS-031 | SyRS-176 | SwRS-197 | `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs` | +| StRS-031 | SyRS-177 | SwRS-177 | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, `SettingsForWebService`, Zeilen 70-95, mit `GetDatabaseInfosForLicenseServer()` und dem Debug-Zweig | +| StRS-032 | SyRS-020 | SwRS-003 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, `Result.AsError(..., DefaultMessageCodes.NoUsernameOrPassword)` | +| StRS-032 | SyRS-020 | SwRS-020 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, die vier genannten Methoden mit den Aufrufen von `_specificLogics.Execute(..., f => f.HasRightToCreateANewReceipt/HasRightToEditReceipt/HasRightToViewReceipt)` | +| StRS-032 | SyRS-057 | SwRS-057 | `src/backend/Centron.BL/Sales/Support/` mit den genannten 49 Klassen | +| StRS-032 | SyRS-057 | SwRS-213 | `src/backend/Centron.BL/Sales/Support/ExternalToolsReplacementBL.cs` | +| StRS-032 | SyRS-092 | SwRS-020 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, die vier genannten Methoden mit den Aufrufen von `_specificLogics.Execute(..., f => f.HasRightToCreateANewReceipt/HasRightToEditReceipt/HasRightToViewReceipt)` | +| StRS-032 | SyRS-092 | SwRS-092 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserEditReceipt` mit `BranchBL.IsBranchEqual(...)` gegenüber `CanUserCreateReceiptsInBranch` mit eigener Vergleichslogik, Zeilen 10258-10296 | +| StRS-033 | SyRS-056 | SwRS-056 | `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `AddSurvey`, Zeilen 209-233, mit der Bedingung `if (contact.Data != null)` | +| StRS-033 | SyRS-056 | SwRS-203 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `AddShortDescriptionPrefix` mit `new AppSettingsBL(this.Session).GetSettings(ApplicationSettingID.IsHelpdeskShortDescriptionPrefixActivated, ApplicationSettingID.HelpdeskShortDescriptionPrefix)` und den typisierten Zugriffen mit Vorgabewert | +| StRS-033 | SyRS-100 | SwRS-100 | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `CreateNewTicket` mit `this.GetTicketSalt(deviceID)`, Zeilen 61-70 | +| StRS-033 | SyRS-102 | SwRS-101 | `src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs` | +| StRS-033 | SyRS-102 | SwRS-212 | `src/backend/Centron.BL/Mobile/MobileBL.cs` und `src/backend/Centron.Entities/Entities/Mobile/` | +| StRS-033 | SyRS-105 | SwRS-104 | `src/backend/Centron.BL/Administration/Logins/TwoFactor/ITwoFactorValidator.cs` mit den beiden Implementierungen | +| StRS-033 | SyRS-106 | SwRS-105 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Klasse `AuthObject`, Zeilen 21-41, mit `RequestId` und überschriebenem `ToString()` | +| StRS-033 | SyRS-106 | SwRS-106 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, Zeilen 47-56 | +| StRS-033 | SyRS-107 | SwRS-106 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, Zeilen 47-56 | +| StRS-034 | SyRS-076 | SwRS-076 | `src/backend/Centron.BL/Purchasing/SupplierOrderPerBranchBL.cs` | +| StRS-034 | SyRS-076 | SwRS-199 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Buchhaltung/Finanzen", Kommentar „Kalkulation pro Filiale" | +| StRS-034 | SyRS-092 | SwRS-020 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, die vier genannten Methoden mit den Aufrufen von `_specificLogics.Execute(..., f => f.HasRightToCreateANewReceipt/HasRightToEditReceipt/HasRightToViewReceipt)` | +| StRS-034 | SyRS-092 | SwRS-092 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserEditReceipt` mit `BranchBL.IsBranchEqual(...)` gegenüber `CanUserCreateReceiptsInBranch` mit eigener Vergleichslogik, Zeilen 10258-10296 | +| StRS-034 | SyRS-093 | SwRS-093 | `src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs`, `GetNumberGroup`, Zeilen 55-81, `if (ModuleFeatures.IsNumberGroupRefactoringAvailable) { … } else { … }` | +| StRS-034 | SyRS-093 | SwRS-192 | `src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs`, `CRMProject = 24` | +| StRS-035 | SyRS-093 | SwRS-093 | `src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs`, `GetNumberGroup`, Zeilen 55-81, `if (ModuleFeatures.IsNumberGroupRefactoringAvailable) { … } else { … }` | +| StRS-035 | SyRS-093 | SwRS-192 | `src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs`, `CRMProject = 24` | +| StRS-035 | SyRS-094 | SwRS-094 | `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs`, Zeilen 78-91 | +| StRS-035 | SyRS-094 | SwRS-095 | `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs`, `FindNextNumber`, Zeilen 116-131, Interpolation von `{tableName}`, `{fieldName}` und `{counter}` | +| StRS-035 | SyRS-095 | SwRS-095 | `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs`, `FindNextNumber`, Zeilen 116-131, Interpolation von `{tableName}`, `{fieldName}` und `{counter}` | +| StRS-036 | SyRS-089 | SwRS-088 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `CreateSpecialArticleToContractFromMspEvaluation`, Zeile 129 | +| StRS-036 | SyRS-103 | SwRS-101 | `src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs` | +| StRS-036 | SyRS-103 | SwRS-102 | `src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs` | +| StRS-036 | SyRS-103 | SwRS-177 | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, `SettingsForWebService`, Zeilen 70-95, mit `GetDatabaseInfosForLicenseServer()` und dem Debug-Zweig | +| StRS-036 | SyRS-109 | SwRS-108 | `src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs`, `_logBL.LogAction(accessToken, AccessTokenLogActionType.Created, …, ipAddress)` (Zeile 185) und die `ValidationFailed`-Aufrufe (Zeilen 396, 403) | +| StRS-036 | SyRS-109 | SwRS-109 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 249-254 und 405-408, die beiden Bedingungen für persönliche und administrative Tokenverwaltung | +| StRS-037 | SyRS-104 | SwRS-100 | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `CreateNewTicket` mit `this.GetTicketSalt(deviceID)`, Zeilen 61-70 | +| StRS-037 | SyRS-104 | SwRS-103 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Feld `_getExistingOrCreateTicketLock` und die `lock`-Klammer in `AuthenticateUser` | +| StRS-038 | SyRS-110 | SwRS-028 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ForwardReceipt` mit `IList receiptProjectLayoutItemI3DsToForward` und `CreateFullReportForReceipt` mit `IList layoutItems` | +| StRS-038 | SyRS-110 | SwRS-029 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `new SwitzerlandSettingsController()` in `GetSettingsWithoutModule()` | +| StRS-038 | SyRS-110 | SwRS-110 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CreateFullReportForReceipt` (Zeile 3221) und `CreateReportPreviewForReceipt` (Zeile 3177), beide mit `CreateFullReportConfiguration` | +| StRS-038 | SyRS-110 | SwRS-178 | `src/backend/Centron.BL/ReportEngine/` mit den zwölf genannten Bestandteilen | +| StRS-038 | SyRS-124 | SwRS-124 | `src/backend/Centron.BL/Administration/FileManagement/SharedDocumentBL.cs` | +| StRS-038 | SyRS-160 | SwRS-126 | `src/nexus/CentronNexus/Configuration/` mit den 13 genannten Konfigurationsklassen und dem Verzeichnis `Migrations` | +| StRS-038 | SyRS-160 | SwRS-160 | `docker/Dockerfile`, zweistufiger Bau mit `FROM … sdk … AS base` und `FROM … runtime …` sowie `dotnet publish … --self-contained true` | +| StRS-038 | SyRS-160 | SwRS-174 | `src/webservice/Centron.Host/`, `Centron.Host.Console/`, `Centron.Host.WindowsService/` als getrennte Projekte mit gemeinsamer Kernabhängigkeit | +| StRS-038 | SyRS-178 | SwRS-178 | `src/backend/Centron.BL/ReportEngine/` mit den zwölf genannten Bestandteilen | +| StRS-039 | SyRS-111 | SwRS-111 | `src/backend/Centron.BL/Administration/FileManagement/DirectoryReferenceProviders/` | +| StRS-039 | SyRS-111 | SwRS-208 | `src/webservice/…/UserRightsConst.cs`, Klasse `Documentation` mit Unterklasse `Categories`, Zeilen 1847-1876 | +| StRS-039 | SyRS-166 | SwRS-122 | `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, `RepairMissingWebAccountContactLinks`, Zeile 318 | +| StRS-039 | SyRS-166 | SwRS-166 | `src/backend/Centron.BL/Services/DataQuality/DirectoryCheckBL.cs`, `GetCaptionForDirectoryCheckItem`, Zeile 84 | +| StRS-040 | SyRS-068 | — | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Eintrag `new SendDeliveryListShippingConfirmationGeneralSettingsAppModueController()` | +| StRS-040 | SyRS-112 | SwRS-112 | `src/backend/Centron.BL/Mail/` mit den sieben genannten Unterzweigen | +| StRS-040 | SyRS-112 | SwRS-207 | `src/backend/Centron.BL/WebLinks/IWebLinkActionHandler.cs` mit den beiden Implementierungen | +| StRS-040 | SyRS-113 | SwRS-053 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `AddShortDescriptionPrefix` mit `new ReplacementBL().ReplaceVariables(prefix, variablesAndValues, "@@")` | +| StRS-040 | SyRS-113 | SwRS-112 | `src/backend/Centron.BL/Mail/` mit den sieben genannten Unterzweigen | +| StRS-040 | SyRS-113 | SwRS-113 | `src/backend/Centron.BL/MailScanner/MailScannerBL.cs`, `GetProfiles` (57), `GetWorkflows` (36), `SaveTasks` (118), `GetMailScannerLogs` (140) | +| StRS-040 | SyRS-114 | SwRS-114 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, die vier genannten Controller in `GetSettingsWithoutModule()` | +| StRS-040 | SyRS-114 | SwRS-204 | `src/backend/Centron.BL/AppointmentRequests/AppointmentRequestBL.cs` und `src/backend/Centron.Entities/Entities/AppointmentRequests/` | +| StRS-040 | SyRS-127 | SwRS-127 | `src/nexus/CentronNexus.OutlookAddIn/CentronNexus.OutlookAddIn.csproj` und `RazorComponentsEndpointConventionBuilderExtensions.cs` | +| StRS-041 | — | — | `src/backend/Centron.BL/MailScanner/MailScannerBL.cs`, `SaveMailScannerLog` (Zeile 133) und `GetProfiles` (57) | +| StRS-042 | SyRS-181 | SwRS-181 | `src/backend/Centron.BL/EmployeeArea/` und `src/backend/Centron.BL/Administration/Employees/` mit den genannten Klassen | +| StRS-043 | SyRS-115 | SwRS-115 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `PersonalPhoneSettingsController` in `GetPersonalSettings()` und `PhoneSettingsController` in `GetSettingsWithoutModule()` | +| StRS-044 | SyRS-004 | — | `src/backend/Centron.BL/Sales/Support/CustomerSpecialArticleBL.cs` und `src/backend/Centron.BL/Accounts/SpecialPrices/` | +| StRS-044 | SyRS-120 | SwRS-025 | `src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs` | +| StRS-044 | SyRS-120 | SwRS-120 | `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, `GetWebRightByI3D` (Zeile 121), `GetWebRightsCategoriesByI3D` (Zeile 126), `GetAllWebRightsFromWebAccount` (Zeile 141) | +| StRS-044 | SyRS-120 | SwRS-121 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserViewReceipt` mit `if (loggedInUser.IsWebAccountLogin)` | +| StRS-044 | SyRS-121 | SwRS-121 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CanUserViewReceipt` mit `if (loggedInUser.IsWebAccountLogin)` | +| StRS-044 | SyRS-122 | SwRS-122 | `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, `RepairMissingWebAccountContactLinks`, Zeile 318 | +| StRS-044 | SyRS-125 | SwRS-058 | `src/nexus/CentronNexus/Management/TicketPatterns/Components/` mit den neun genannten Reiterkomponenten und `TicketPatternTree.razor` | +| StRS-044 | SyRS-125 | SwRS-125 | `src/nexus/CentronNexus/Management/TicketPatterns/Components/SelfCareFormFieldGrid.razor` und `SelfCareFormFieldEditPopup.razor` | +| StRS-044 | SyRS-126 | SwRS-126 | `src/nexus/CentronNexus/Configuration/` mit den 13 genannten Konfigurationsklassen und dem Verzeichnis `Migrations` | +| StRS-044 | SyRS-127 | SwRS-127 | `src/nexus/CentronNexus.OutlookAddIn/CentronNexus.OutlookAddIn.csproj` und `RazorComponentsEndpointConventionBuilderExtensions.cs` | +| StRS-044 | SyRS-129 | SwRS-129 | `src/nexus/CentronNexus/SharedResource.resx`, `SharedResource.en-US.resx` mit den zugehörigen Designer-Klassen | +| StRS-045 | SyRS-123 | SwRS-123 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ChangeWebReceiptState(string token, WebReceiptState webReceiptState)`, Zeile 5903 | +| StRS-045 | SyRS-123 | SwRS-124 | `src/backend/Centron.BL/Administration/FileManagement/SharedDocumentBL.cs` | +| StRS-045 | SyRS-123 | SwRS-207 | `src/backend/Centron.BL/WebLinks/IWebLinkActionHandler.cs` mit den beiden Implementierungen | +| StRS-045 | SyRS-124 | SwRS-124 | `src/backend/Centron.BL/Administration/FileManagement/SharedDocumentBL.cs` | +| StRS-046 | SyRS-054 | SwRS-007 | `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `UpdateArticleVATs` mit `NamedQueryAccess
().GetNamedQuery(NamedQueryEnums.ValueAddedTax.UpdateArticleVatsAndPrices, parameters)` | +| StRS-046 | SyRS-054 | SwRS-054 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckUserRigths`, Zeilen 433-443, mit `else { entity.ClosedAt = null; }` | +| StRS-046 | SyRS-054 | SwRS-055 | `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `CloseHelpdesk(IList, AppUser)`, Zeilen 108-118 | +| StRS-046 | SyRS-054 | SwRS-202 | `src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs` | +| StRS-047 | SyRS-108 | SwRS-107 | `src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs`, Signaturen mit `string securityKey = null` und `GetKeyAndIV` mit Rückfall auf `SECURITY_KEY` | +| StRS-047 | SyRS-108 | SwRS-130 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 608 und 700 | +| StRS-047 | SyRS-108 | SwRS-131 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 551 und 949, `GetHotlineMasterKey()` | +| StRS-047 | SyRS-130 | — | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeile 700, `propertyValue.ValueEncryptedString = new AESCryptoLogic().EncryptText(customerHotline.Password, masterKeyResult.Data)` | +| StRS-048 | SyRS-131 | SwRS-132 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, `AddOldHotlineEntriesToCustomer`, Zeile 722, im Zusammenhang mit der Verschlüsselung Zeile 700 | +| StRS-049 | SyRS-089 | SwRS-088 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `CreateSpecialArticleToContractFromMspEvaluation`, Zeile 129 | +| StRS-049 | SyRS-140 | SwRS-140 | `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs`, die genannten Eigenschaften | +| StRS-049 | SyRS-140 | SwRS-141 | `SSMS_DB_SCHEMA.sql`, Tabellen `AccountDevices`, `AccountDevicesToTickets` | +| StRS-049 | SyRS-140 | SwRS-142 | `SSMS_DB_SCHEMA.sql`, die 14 genannten `AssetManagement*`-Tabellen und `MonitoringServiceSettings` | +| StRS-049 | SyRS-140 | SwRS-143 | `src/backend/Centron.Entities/Entities/Sales/CustomerAssets/CustomerAsset.cs`, Zeilen 14-48, die vier Betreuerfelder mit ihren Kommentaren und die berechnete `Address` | +| StRS-050 | SyRS-150 | SwRS-150 | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, `DsgvoDeleteRightDeleteContacts` mit `deleteProtocol` und Rückgabe `Result`, Zeilen 787-850 | +| StRS-050 | SyRS-150 | SwRS-151 | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 863-903, Anonymisierungsanweisungen mit `SET h.Status = 0, h.Name = '{DsgvoDeletedContactMessage}', h.Fon = default, …` | +| StRS-050 | SyRS-151 | SwRS-151 | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 863-903, Anonymisierungsanweisungen mit `SET h.Status = 0, h.Name = '{DsgvoDeletedContactMessage}', h.Fon = default, …` | +| StRS-050 | SyRS-152 | SwRS-152 | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, `GetDeletedCustomers` mit `stats.CleanUpStatsKind = DataSecurityCleanUpStatsKind.CustomersDeleted`, Zeilen 353-360 | +| StRS-051 | SyRS-007 | SwRS-007 | `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `UpdateArticleVATs` mit `NamedQueryAccess
().GetNamedQuery(NamedQueryEnums.ValueAddedTax.UpdateArticleVatsAndPrices, parameters)` | +| StRS-051 | SyRS-007 | SwRS-008 | `src/backend/Centron.BL/Warehousing/TaxBL.cs`, `foreach (var batch in articleI3DsWithOldTaxRate.Batch(2000))` | +| StRS-051 | SyRS-014 | SwRS-014 | `SSMS_DB_SCHEMA.sql`, Tabelle `RechKopfVersions` | +| StRS-051 | SyRS-023 | SwRS-023 | `src/centron/Centron.WPF.UI/Modules/CentronModule.cs`, `OpenModuleByObject` mit `objectKind == CentronObjectKindNumeric.HelpdeskClass` und `objectKind == CentronObjectKindNumeric.ContractClass` | +| StRS-051 | SyRS-023 | SwRS-166 | `src/backend/Centron.BL/Services/DataQuality/DirectoryCheckBL.cs`, `GetCaptionForDirectoryCheckItem`, Zeile 84 | +| StRS-051 | SyRS-023 | SwRS-206 | `src/backend/Centron.BL/Tags/TagsBL.cs` und `src/backend/Centron.Entities/Entities/Tags/` | +| StRS-051 | SyRS-071 | SwRS-071 | `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs` und `EDICommonBL.cs` | +| StRS-051 | SyRS-071 | SwRS-072 | `src/backend/Centron.BL/EDI/Zugferd/ZUGFeRD_BL.cs`, `ReadInvoice`, Zeile 38, mit den Parametern `List` und `List>` | +| StRS-051 | SyRS-071 | SwRS-087 | `src/backend/Centron.BL/DataExchange/` mit den zehn genannten Unterzweigen | +| StRS-051 | SyRS-081 | SwRS-081 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptIsPaid(…, string moduleOrAction, AppUser currentUser)`, Zeile 4902 | +| StRS-051 | SyRS-106 | SwRS-105 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Klasse `AuthObject`, Zeilen 21-41, mit `RequestId` und überschriebenem `ToString()` | +| StRS-051 | SyRS-106 | SwRS-106 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, Zeilen 47-56 | +| StRS-051 | SyRS-153 | SwRS-153 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Zuweisungen `receipt.CreatedAt = receipt.ChangedAt; receipt.CreatedByI3D = receipt.ChangedByI3D; receipt.CreatedThroughApplicationVersion = receipt.ChangedThroughApplicationVersion;` im Zweig `if (isNewReceipt)` | +| StRS-051 | SyRS-153 | SwRS-154 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `WriteReceiptLogs` mit `_receiptLogBL.CreateContingentKindEntry(...)` neben den Audit-Feldzuweisungen in `SaveReceipt` | +| StRS-051 | SyRS-154 | SwRS-154 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `WriteReceiptLogs` mit `_receiptLogBL.CreateContingentKindEntry(...)` neben den Audit-Feldzuweisungen in `SaveReceipt` | +| StRS-051 | SyRS-165 | SwRS-165 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs` und `Authenticator.cs`, die genannten Protokollaufrufe | +| StRS-052 | SyRS-112 | SwRS-112 | `src/backend/Centron.BL/Mail/` mit den sieben genannten Unterzweigen | +| StRS-052 | SyRS-112 | SwRS-207 | `src/backend/Centron.BL/WebLinks/IWebLinkActionHandler.cs` mit den beiden Implementierungen | +| StRS-052 | SyRS-160 | SwRS-126 | `src/nexus/CentronNexus/Configuration/` mit den 13 genannten Konfigurationsklassen und dem Verzeichnis `Migrations` | +| StRS-052 | SyRS-160 | SwRS-160 | `docker/Dockerfile`, zweistufiger Bau mit `FROM … sdk … AS base` und `FROM … runtime …` sowie `dotnet publish … --self-contained true` | +| StRS-052 | SyRS-160 | SwRS-174 | `src/webservice/Centron.Host/`, `Centron.Host.Console/`, `Centron.Host.WindowsService/` als getrennte Projekte mit gemeinsamer Kernabhängigkeit | +| StRS-052 | SyRS-163 | SwRS-163 | `.github/workflows/build.yml`, `runs-on` mit `self-hosted`, `timeout-minutes: 180` und die `if`-Bedingung auf `head.repo.full_name` | +| StRS-052 | SyRS-168 | SwRS-001 | `src/backend/Centron.BL/BLSession.cs`, `BaseBL.cs`, `DBBaseBL.cs` | +| StRS-052 | SyRS-168 | SwRS-002 | `src/centron/Centron.WPF.UI/Modules/CentronModule.cs`, Prüfung `module.SupportsConnectionTypes` mit Verzweigung auf `CentronConnectionType.CentronWebServices` | +| StRS-052 | SyRS-168 | SwRS-168 | `src/centron/Centron.WPF.UI/Modules/CentronModule.cs`, `OpenModule` mit `module.SupportsConnectionTypes.All(f => f != ClassContainer.Instance.ConnectionType)` | +| StRS-052 | SyRS-174 | SwRS-174 | `src/webservice/Centron.Host/`, `Centron.Host.Console/`, `Centron.Host.WindowsService/` als getrennte Projekte mit gemeinsamer Kernabhängigkeit | +| StRS-053 | SyRS-161 | SwRS-161 | `src/backend/Centron.BL/Administration/Scripts/ScriptMethods/IScriptMethod.cs`, `IRecurringScriptMethod.cs`, `ScriptMethodPool.cs` | +| StRS-053 | SyRS-161 | SwRS-162 | `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, `ShouldExecuteScripts` (Zeile 37) und Parameter `currentVersionOverride` (Zeile 39) sowie der `#if DEBUG`-Block (Zeile 57 ff.) | +| StRS-053 | SyRS-162 | SwRS-162 | `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, `ShouldExecuteScripts` (Zeile 37) und Parameter `currentVersionOverride` (Zeile 39) sowie der `#if DEBUG`-Block (Zeile 57 ff.) | +| StRS-054 | SyRS-170 | SwRS-034 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `GetRightsForModule`, Zeilen 220-223, `_modules.FirstOrDefault(f => f.ModuleType == controller.GetType())?.GetRights()` | +| StRS-054 | SyRS-170 | SwRS-170 | `src/backend/Centron.BL/Statistics/` mit den neun genannten Unterbereichen | +| StRS-054 | SyRS-170 | SwRS-190 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Controlling/Analytics", Kommentar „Vertragsauswertung" mit der Registrierung von `ContractEvaluation2` | +| StRS-054 | SyRS-170 | SwRS-210 | `src/webservice/…/UserRightsConst.cs`, Klasse `VideoPortal`, Zeile 2786 | +| StRS-054 | SyRS-170 | SwRS-215 | `src/nexus/CentronNexus/ServiceBoard/Dashboard/DashboardMyTicketStats.razor`, `DashboardMyTimerecordStats.razor`, `DashboardMyDayList.razor` | +| StRS-054 | SyRS-178 | SwRS-178 | `src/backend/Centron.BL/ReportEngine/` mit den zwölf genannten Bestandteilen | +| StRS-055 | SyRS-171 | SwRS-171 | `src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs` | +| StRS-055 | SyRS-171 | SwRS-206 | `src/backend/Centron.BL/Tags/TagsBL.cs` und `src/backend/Centron.Entities/Entities/Tags/` | +| StRS-056 | SyRS-167 | SwRS-167 | `src/backend/Centron.BL/Telemetry/TelemetryBL.cs`, `GetCompletedPendingApiCalls(DateTime maxBucketStartUtc)` (Zeile 308) und `UpsertApiCallBatch` (Zeile 173) | +| StRS-056 | SyRS-172 | SwRS-172 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `new ArtificialIntelligencePromptSettingsController()` in `GetSettingsWithoutModule()` | +| StRS-057 | — | — | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Adressen/CRM", Registrierung `CampaignAppModuleController` mit `LicenseGuids.CampaignsMailing` | +| StRS-058 | — | — | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CreateNewReceipt(…, bool insertSalutationAndAgreement, …)`, Zeile 775 | +| StRS-059 | SyRS-108 | SwRS-107 | `src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs`, Signaturen mit `string securityKey = null` und `GetKeyAndIV` mit Rückfall auf `SECURITY_KEY` | +| StRS-059 | SyRS-108 | SwRS-130 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 608 und 700 | +| StRS-059 | SyRS-108 | SwRS-131 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 551 und 949, `GetHotlineMasterKey()` | +| StRS-060 | SyRS-180 | SwRS-180 | `SSMS_DB_SCHEMA.sql`, Tabelle `ArticleWorkItems` | +| StRS-061 | SyRS-181 | SwRS-181 | `src/backend/Centron.BL/EmployeeArea/` und `src/backend/Centron.BL/Administration/Employees/` mit den genannten Klassen | +| StRS-061 | SyRS-182 | SwRS-182 | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `GetEmployeeTimeStatistics(ICollection articleI3Ds, …)`, Zeile 710 | +| StRS-062 | SyRS-033 | SwRS-033 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `SearchSpecialArticleToContractHead`, Zeilen 319-327 | +| StRS-062 | SyRS-033 | SwRS-088 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs`, `CreateSpecialArticleToContractFromMspEvaluation`, Zeile 129 | +| StRS-062 | SyRS-033 | SwRS-197 | `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs` | +| StRS-062 | SyRS-173 | SwRS-004 | `src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs`, `ObjectMapper.Map(contact.Data)` | +| StRS-062 | SyRS-173 | SwRS-173 | `src/webservice/Centron.Controllers/Controllers/v1/` mit den genannten 15 Bereichsverzeichnissen | +| StRS-062 | SyRS-173 | SwRS-175 | `src/webservice/Centron.Controllers/Controllers/v1/Integrations/` und `Controllers/v1/DataExchange/` mit den elf genannten Controllern | +| StRS-062 | SyRS-173 | SwRS-194 | `src/backend/Centron.BL/CustomerArea/BusinessLineBL.cs`, `InterestBL.cs`, `ProductBL.cs` | +| StRS-062 | SyRS-173 | SwRS-212 | `src/backend/Centron.BL/Mobile/MobileBL.cs` und `src/backend/Centron.Entities/Entities/Mobile/` | +| StRS-062 | SyRS-175 | SwRS-175 | `src/webservice/Centron.Controllers/Controllers/v1/Integrations/` und `Controllers/v1/DataExchange/` mit den elf genannten Controllern | +| StRS-062 | SyRS-175 | SwRS-196 | `src/backend/Centron.BL/ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs` | +| StRS-062 | SyRS-175 | SwRS-201 | `Centron.Api.docuFORM/Centron.Api.docuFORM.csproj` | +| StRS-062 | SyRS-175 | SwRS-209 | `SSMS_DB_SCHEMA.sql`, Tabellen `SocialMediaStream`, `SocialMediaStreamAccount`, `SocialMediaAction`, `SocialMediaComment`, `SocialMediaLike` | +| StRS-062 | SyRS-175 | SwRS-214 | `src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs`, `src/backend/Centron.BL/CPra/CPraConnectorBL.cs`, `src/backend/Centron.BL/TradePool/TradePoolBL.cs` | +| StRS-062 | SyRS-179 | SwRS-179 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Region „Automatisierung", zwei getrennte Registrierungen mit `SHOW_EXPECTEDEVENTS` und `SHOW_EXPECTEDEVENTSREPORTING` | +| — | SyRS-005 | SwRS-005 | `SSMS_DB_SCHEMA.sql`, Tabellen `AngKopf`, `AufKopf`, `LiefKopf`, `RechKopf`, `VertragKopf`, `GutKopf`, `AbholKopf` mit ihren Positionstabellen | +| — | SyRS-008 | SwRS-029 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `new SwitzerlandSettingsController()` in `GetSettingsWithoutModule()` | +| — | SyRS-011 | SwRS-009 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt` mit `return this.Session.WithTransaction(() => { … })` | +| — | SyRS-011 | SwRS-011 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Aufrufkette Zeilen 3634-3700 | +| — | SyRS-011 | SwRS-015 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ForwardReceipt(AppUser, ForwardReceiptData, IList, IList, InsertReceiptTakeoverOptions, bool, bool)`, Zeile 1548 | +| — | SyRS-011 | SwRS-027 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Validate Unconverted Article Warning", Zeile 2509 | +| — | SyRS-012 | SwRS-012 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Methodensignaturen ab Zeile 4790 mit `Guid? concurrencyControlGuid` | +| — | SyRS-012 | SwRS-064 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptQuantityPicked`, Zeile 5031 | +| — | SyRS-013 | SwRS-013 | `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, Feld `private readonly AssetLockBL _lockBL;` | +| — | SyRS-015 | SwRS-015 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ForwardReceipt(AppUser, ForwardReceiptData, IList, IList, InsertReceiptTakeoverOptions, bool, bool)`, Zeile 1548 | +| — | SyRS-015 | SwRS-024 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `GetReceiptProgression`, Zeile 4767, mit Parameter `limit` | +| — | SyRS-015 | SwRS-028 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ForwardReceipt` mit `IList receiptProjectLayoutItemI3DsToForward` und `CreateFullReportForReceipt` mit `IList layoutItems` | +| — | SyRS-016 | SwRS-016 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Block `if (isTemplate) { data.IgnoreCallbacks = true; … }` mit dem Kommentar „We automatically ignore all callbacks when saving a receipt-template" | +| — | SyRS-021 | SwRS-021 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Aufruf mit `previousReceiptVersion` als Referenz | +| — | SyRS-022 | SwRS-001 | `src/backend/Centron.BL/BLSession.cs`, `BaseBL.cs`, `DBBaseBL.cs` | +| — | SyRS-022 | SwRS-010 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt(IReceiptBase receipt, …)`, Zeilen 3519-3521 mit `MakeGenericMethod(...).Invoke(...)` | +| — | SyRS-022 | SwRS-022 | `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs`, `TargetReceiptKind => CentronObjectKindNumeric.InvoiceClass` | +| — | SyRS-022 | SwRS-070 | `src/backend/Centron.BL/Sales/Receipts/SupplierOrders/`, `SupplierDeliveryLists/`, `SupplierInvoices/`, `SupplierCreditVouchers/` | +| — | SyRS-031 | SwRS-031 | `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `GetFlatrateBalanceArticle` und `GetContractBalanceArticle` als getrennte Methoden | +| — | SyRS-041 | SwRS-041 | `src/backend/Centron.BL/Sales/Support/HelpdeskTimeRecordingBL.cs`, `GetStopwatchNotificationsForEmployee` (Zeile 506) und `DeleteStopwatchNotifications` (Zeile 518) | +| — | SyRS-052 | SwRS-052 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckTextFieldLengths`, Zeilen 333-348, mit dem Kommentar `// nvarchar:2000 > string:1000` | +| — | SyRS-052 | SwRS-059 | `src/nexus/CentronNexus/ServiceBoard/CachedTicketList/Components/` mit `FilterEditorGroup.razor`, `ConditionalFormattingEditor.razor`, `SummaryEditor.razor`, `KanbanBucketSelection.razor` | +| — | SyRS-053 | SwRS-053 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `AddShortDescriptionPrefix` mit `new ReplacementBL().ReplaceVariables(prefix, variablesAndValues, "@@")` | +| — | SyRS-053 | SwRS-203 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `AddShortDescriptionPrefix` mit `new AppSettingsBL(this.Session).GetSettings(ApplicationSettingID.IsHelpdeskShortDescriptionPrefixActivated, ApplicationSettingID.HelpdeskShortDescriptionPrefix)` und den typisierten Zugriffen mit Vorgabewert | +| — | SyRS-061 | SwRS-061 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `SaveReceipt`, Aufruf `this._receiptBarcodeBL.CheckIfAllNonActiveBarcodesAreStillInTheReceipt(receipt, previousReceiptVersion)` | +| — | SyRS-064 | SwRS-027 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Region „Validate Unconverted Article Warning", Zeile 2509 | +| — | SyRS-064 | SwRS-031 | `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `GetFlatrateBalanceArticle` und `GetContractBalanceArticle` als getrennte Methoden | +| — | SyRS-064 | SwRS-065 | `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, Methoden `GetFreightArticle` (166), `GetCustomerDiscountArticle` (190), `GetArticleI3DForExternalArticles` (207), `GetArticleI3DForNewArticles` (215), `GetVoucherArticleList` (235) | +| — | SyRS-064 | SwRS-200 | `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `GetVoucherArticleList`, Zeile 235 | +| — | SyRS-074 | SwRS-074 | `src/apis/Centron.APIs.ITscopeDataAccess/Data/ITscopeApiKeyQuota.cs` | +| — | SyRS-101 | — | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `RefreshTicketExpireDate`, Bedingung `< 5` | +| — | SyRS-128 | SwRS-128 | `src/backend/Centron.BL/Notifications/CentronNotificationsBL.cs` und `src/backend/Centron.BL/NexusNotifications/NexusNotificationsBL.cs` | +| — | SyRS-128 | SwRS-205 | `src/backend/Centron.BL/Chats/ChatBL.cs` und `src/backend/Centron.Entities/Entities/Chats/` | +| — | SyRS-164 | SwRS-164 | `tests/backend/`, `tests/shared/`, `tests/apis/` gegenüber `src/backend/`, `src/shared/`, `src/apis/` | +| — | — | SwRS-211 | `src/shared/Centron.Core/`, `src/shared/Centron.Controls/`, `src/shared/Centron.Controls.Preview/` | + +**Zeilen gesamt: 319** diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Protokoll.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Protokoll.md new file mode 100644 index 00000000..7f7570f1 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Protokoll.md @@ -0,0 +1,184 @@ +# 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-26T22:58:15.5203844+02:00 +- **Endzeit:** 2026-08-27T00:24:02.3040325+02:00 +- **Dauer gesamt:** 1:25:46 (`duration_ms` 1:25:45; API: 1:21:50) + — **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-opus-5` +- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 38.137.560 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:** `high` (per `--effort high` gesetzt) +- **Laufverzeichnis-ID:** `v7.0.0-2269` +- **Ablage:** `Iteration 3/claude-opus-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 | 256 | +| Output-Tokens | 468.007 (davon 20.913 Thinking-Tokens) | +| Cache-Write-Tokens | 596.413 | +| Cache-Read-Tokens | 37.072.884 | +| Agent-Turns | 165 | + +### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant) +| Messgröße | `claude-opus-5` | `claude-haiku-4-5-20251001` | Summe | +|---|---:|---:|---:| +| Input-Tokens | 256 | 6.943 | 7.199 | +| Output-Tokens | 468.007 | 22 | 468.029 | +| Cache-Write-Tokens | 596.413 | 0 | 596.413 | +| Cache-Read-Tokens | 37.072.884 | 0 | 37.072.884 | +| **Tokens gesamt** | **38.137.560** | **6.965** | **38.144.525** | + +**Tokens gesamt: 38.144.525** — 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 | 62 | 17,1 % | +| SyRS | 132 | 36,4 % | +| SwRS | 169 | 46,6 % | +| **Gesamt** | **363** | 100 % | + +### Anforderungstypen + +| Typ | Anzahl | Anteil | +|---|---:|---:| +| funktional | 147 | 40,5 % | +| Daten | 87 | 24,0 % | +| Sicherheit | 55 | 15,2 % | +| nicht-funktional | 46 | 12,7 % | +| Schnittstelle | 28 | 7,7 % | + +### Belegqualität + +| Messgröße | Wert | +|---|---:| +| Belege gesamt | 740 | +| davon `PRIMÄR` | 490 (66,2 %) | +| davon `SEKUNDÄR` | 187 (25,3 %) | +| davon `KONTEXT` | 63 (8,5 %) | +| Belege je Anforderung (Median) | 2 | +| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 362 (99,7 %) | + +### Übernahmewürdigkeit + +| Einstufung | Anzahl | Anteil | +|---|---:|---:| +| übernehmen | 337 | 92,8 % | +| workaround | 12 | 3,3 % | +| sonderfall | 1 | 0,3 % | +| veraltet | 13 | 3,6 % | + +### Status + +| Kategorie | Anzahl | Anteil | +|---|---:|---:| +| belegt | 358 | 98,6 % | +| als `HYPOTHESE` gekennzeichnet | 5 | 1,4 % | +| als Workaround vermerkt | 0 | 0,0 % | +| Konsolidierungskandidaten | 67 | 18,5 % | +| mit ISO-25010-Qualitätsmerkmal | 46 | 12,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** (106 risikorelevante Anforderungen, alle gedeckt) | +| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** | +| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 363 Anforderungen eingestuft) | +| **Traceability** – Verknüpfung zwischen den Ebenen | 363 von 363 mit Tracelinks (100,0 %) | + +## Ergebnis +- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`) +- **Session-ID:** `0ec4aa93-c1b8-4ad1-ae63-2ebcdc31cbf4` +- **Permission-Denials:** 8 (5 × `Bash`, 2 × `PowerShell`, 1 × `Read`) – **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` | 75.086 B | + | `Glossar.md` | 14.154 B | + | `Hypothesen.md` | 6.393 B | + | `StRS.md` | 104.009 B | + | `SwRS.md` | 251.643 B | + | `SyRS.md` | 206.150 B | + | `Traceability.md` | 54.332 B | + +- **Root unverändert:** ja (zeilenendennormalisiert verglichen). +- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`) + +## Anmerkungen/Auffälligkeiten + +**1. Neue Zelle: `claude-opus-5` / `solo` / `high`.** Erster gültiger Lauf dieser Kombination. +Der vorausgegangene Versuch `195958_v7.0.0-e7e6` scheiterte am Session-Kontingent; dieser Lauf +wurde **seriell** gefahren, ohne jeden Parallelbetrieb. + +**2. Er relativiert den Effort-Befund vom Vortag.** Die verdoppelte Belegdichte – Median 2,0 +statt 1,0 – war den drei `max`-Läufen zugeschrieben worden, weil alle 44 `high`-Läufe zuvor bei +Median 1,0 lagen. Dieser Lauf erreicht Median **2,0 auf `high`**. Der Unterschied liegt damit +nicht am Effort, sondern am **Modell**: Die 44 Läufe mit Median 1,0 liefen sämtlich auf Sonnet, +die `max`-Läufe auf Opus. Opus liefert die höhere Belegdichte auch ohne `max`; `max` hebt sie +bei Opus weiter auf 3,0. Der Effort bleibt für den **Verbrauch** wirksam: 38,1 Mio. Tokens auf +`high` gegenüber 67,5 bis 116,2 Mio. auf `max`. + +**3. Zweithöchste Primärbelegquote der Reihe: 99,7 %** (362 von 363 Anforderungen). Nur `37c5` +war mit 100 % besser – ebenfalls Opus, dort auf `max`. + +**4. Ausgewogene Ebenenverteilung** (62 StRS / 132 SyRS / 169 SwRS) und 740 Belege auf 363 +Anforderungen. `spawned` = 0, Modellkontrolle bestanden. + +**5. Seriell gemessen – die Zeitangabe ist verwertbar.** Als erst zweiter Lauf der gesamten +Reihe (nach `d6f9`) lief dieser ohne Parallelbetrieb und ohne Kontingentwartezeit. diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/RawResult.json b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/RawResult.json new file mode 100644 index 00000000..6163a79c --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/RawResult.json @@ -0,0 +1 @@ +{"is_error":false,"duration_api_ms":4910478,"num_turns":165,"stop_reason":"end_turn","session_id":"0ec4aa93-c1b8-4ad1-ae63-2ebcdc31cbf4","total_cost_usd":36.20907999999999,"usage":{"input_tokens":256,"cache_creation_input_tokens":596413,"cache_read_input_tokens":37072884,"output_tokens":468007,"output_tokens_details":{"thinking_tokens":20913},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":596413,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":1498,"cache_read_input_tokens":594540,"cache_creation_input_tokens":1873,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":1873},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6943,"outputTokens":22,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007053,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-opus-5":{"inputTokens":256,"outputTokens":468007,"cacheReadInputTokens":37072884,"cacheCreationInputTokens":596413,"webSearchRequests":0,"costUSD":36.202026999999994,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-opus-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"Read","tool_use_id":"toolu_01WRNyAEvyNGeX2ZL5gR5vun","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\0ec4aa93-c1b8-4ad1-ae63-2ebcdc31cbf4\\tasks\\bohoqru1b.output"}},{"tool_name":"PowerShell","tool_use_id":"toolu_01LodqoLxumDb9YafcPDEYjm","tool_input":{"command":"$out = \"c:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 3\\claude-opus-5\\solo\\high\\02_Lauf_2026-08-26_225807_v7.0.0-2269\\Ergebnisse\\SyRS.md\"; $p2 = \"C:\\Users\\ChristophSchwoerer\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\0ec4aa93-c1b8-4ad1-ae63-2ebcdc31cbf4\\scratchpad\\syrs_p2.md\"; Add-Content -Path $out -Value (Get-Content -Raw $p2) -NoNewline -Encoding utf8; (Get-Content $out | Measure-Object -Line).Lines","description":"Append SyRS part 2"}},{"tool_name":"Bash","tool_use_id":"toolu_016878BjNZMfXJtQwrR7Zu6j","tool_input":{"command":"cd \"c:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse\" && S=\"C:/Users/ChristophSchwoerer/AppData/Local/Temp/claude/C--DEV-MasterArbeit-QuellCode-CentronERP/0ec4aa93-c1b8-4ad1-ae63-2ebcdc31cbf4/scratchpad\" && cat \"$S/bericht_a.md\" >> Analysebericht.md && cat _coverage_table.md >> Analysebericht.md && cat \"$S/bericht_b.md\" >> Analysebericht.md && cat _risk_table.md >> Analysebericht.md && cat \"$S/bericht_c.md\" >> Analysebericht.md && rm -f _coverage_table.md _risk_table.md && ls -la && wc -l *.md","description":"Assemble Analysebericht"}},{"tool_name":"Bash","tool_use_id":"toolu_01JNJ9RHayq2hmSpDQXwKGWx","tool_input":{"command":"cd \"c:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse\" && cat \"C:/Users/ChristophSchwoerer/AppData/Local/Temp/claude/C--DEV-MasterArbeit-QuellCode-CentronERP/0ec4aa93-c1b8-4ad1-ae63-2ebcdc31cbf4/scratchpad/bericht_b.md\" >> Analysebericht.md && cat _risk_table.md >> Analysebericht.md && cat \"C:/Users/ChristophSchwoerer/AppData/Local/Temp/claude/C--DEV-MasterArbeit-QuellCode-CentronERP/0ec4aa93-c1b8-4ad1-ae63-2ebcdc31cbf4/scratchpad/bericht_c.md\" >> Analysebericht.md && rm -f _coverage_table.md _risk_table.md && ls && wc -l *.md","description":"Append remaining report parts, clean up"}},{"tool_name":"Bash","tool_use_id":"toolu_01SKLhW6A9kovfaGgrQkVinA","tool_input":{"command":"cd \"c:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse\" && cat \"C:/Users/ChristophSchwoerer/AppData/Local/Temp/claude/C--DEV-MasterArbeit-QuellCode-CentronERP/0ec4aa93-c1b8-4ad1-ae63-2ebcdc31cbf4/scratchpad/bericht_c.md\" >> Analysebericht.md && rm -f _coverage_table.md _risk_table.md && wc -l *.md","description":"Append report part C and clean up"}},{"tool_name":"Bash","tool_use_id":"toolu_01511d7bepEn9GPxLENBwLuA","tool_input":{"command":"cd \"c:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse\" && rm -f _coverage_table.md _risk_table.md && ls -la && wc -l *.md","description":"Clean temp tables and list results"}},{"tool_name":"Bash","tool_use_id":"toolu_01B3nQBtQX69G3kGtYTnqit8","tool_input":{"command":"cd \"c:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Ergebnisse\" && rm _coverage_table.md _risk_table.md; ls; wc -l *.md","description":"Remove temp tables and list"}},{"tool_name":"PowerShell","tool_use_id":"toolu_01JoKqVc2u8v61KsrHpT6xAn","tool_input":{"command":"$d = \"c:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 3\\claude-opus-5\\solo\\high\\02_Lauf_2026-08-26_225807_v7.0.0-2269\\Ergebnisse\"; Remove-Item -Path (Join-Path $d \"_coverage_table.md\"),(Join-Path $d \"_risk_table.md\") -Force -ErrorAction SilentlyContinue; Get-ChildItem $d | Select-Object Name,Length","description":"Delete helper tables and list output files"}}],"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; die analysierte Codebasis wurde nicht verändert (`git status` zeigt unter `QuellCode/CentronERP/` keine Änderung).\n\n## Ergebnis\n\n**363 Anforderungen** über 165 Inventarmodule — 62 StRS, 132 SyRS, 169 SwRS.\n\n| Datei | Umfang |\n|---|---|\n| `Analysebericht.md` | Modulinventar (165), Abdeckungstabelle, Konsistenzcheck, Risikoliste (173), Selbstbewertung |\n| `StRS.md` / `SyRS.md` / `SwRS.md` | 363 Anforderungsblöcke, alle 15 Pflichtfelder in jedem Block gesetzt |\n| `Traceability.md` | 319 Zeilen `StRS \\| SyRS \\| SwRS \\| Artefaktbeleg`, maschinell erzeugt |\n| `Hypothesen.md` | 5 Einträge, deckungsgleich mit den Inline-Markierungen |\n| `Glossar.md` | 60 Domänenbegriffe mit Fundstelle |\n\n## Konsistenzcheck — alle Prüfungen sauber\n\nDoppelte IDs: 0 · Anforderungen ohne Beleg: 0 · ohne `Übernahmewürdigkeit`: 0 · Tracelinks ins Leere: 0 (vier gefundene wurden im Lauf behoben) · nicht-funktionale ohne ISO-25010-Merkmal: 0 · deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung: 0.\n\nBelege: 740 gesamt, davon **66,2 % PRIMÄR**. Von 173 risikorelevanten Anforderungen trägt genau eine keinen PRIMÄR-Beleg — sie ist als `[HYPOTHESE]` gekennzeichnet, also **null Verstöße** gegen die risikobasierte Priorisierung.\n\nAbdeckung: 23 Module tief, 64 mittel, 78 flach, **0 nicht analysiert** — Mindestabdeckung erreicht.\n\n## Zwei Einschränkungen, die ich offenlege\n\n**Change-Historie fehlt vollständig.** Das Arbeitsverzeichnis enthält kein Repository der analysierten Codebasis, nur den Dateibestand. Commit-Messages, Tickets und Release Notes — die Belegklasse für Schritt 2 der Methodenkette — konnten nicht erhoben werden. Die 12 `Workaround`- und 14 `veraltet`-Einstufungen stützen sich stattdessen auf Quelltextkommentare und `[Obsolete]`-Attribute.\n\n**Die Modul-zu-Anforderung-Zuordnung in der Abdeckungstabelle ist maschinell erzeugt** (Stichwortsuche über Belege und Blocktext) und in 15 Fällen manuell nach unten korrigiert, weil kurze Schlüssel wie `Mandat`, `Voucher` oder `EDI` auch fremde Begriffe treffen. Rohwert und korrigierter Wert stehen beide in der Tabelle.\n\n## Inhaltlich auffällig\n\nSechs Sicherheitsbefunde mit unmittelbarem Handlungsbedarf, darunter ungesalzene SHA-1-Kennwörter (der Code vermerkt das selbst: `// TODO the password should be salted!!!`), Klartext-Kennwortversand per E-Mail an neue Web-Konten und ein fest im Quelltext hinterlegter AES-Ersatzschlüssel.\n\nDer im Auftrag genannte Beispielfall bestätigte sich und ist größer als beschrieben: installierte Geräte liegen in **vier** getrennten Datenhaltungen (`Stammdat`, `AccountDevices`, `AssetManagementDevices`, `CustomerAsset`) plus `GeraeteKopf` — dokumentiert in `SyRS-140` und `SwRS-140` bis `SwRS-143`. Insgesamt sind 67 Anforderungen als Konsolidierungskandidat markiert.","ttft_ms":1925,"ttft_stream_ms":1179,"time_to_request_ms":30,"type":"result","duration_ms":5145051,"uuid":"7d7b25ed-3240-4577-8b7f-04af26d6ec95","queued_turn_count":0} diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Stderr.log b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/Stderr.log new file mode 100644 index 00000000..e69de29b diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/after.txt b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/after.txt new file mode 100644 index 00000000..e69de29b diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/anforderungen.json b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/anforderungen.json new file mode 100644 index 00000000..e3d23b8b --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/anforderungen.json @@ -0,0 +1,7276 @@ +[ + { + "id": "StRS-001", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Zentraler Geschäftspartnerstamm", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-001, SyRS-002, SwRS-001, SwRS-002", + "konsolidierung": "Kandidat: StRS-002 — Account-Stamm und Alt-Kundenstamm (`Kunden`/`Kreditor`) bilden denselben fachlichen Gegenstand in zwei Datenhaltungen ab.", + "pruefidee": "Ein Geschäftspartner wird als Kunde angelegt und zusätzlich als Lieferant markiert; er muss in beiden Suchen mit derselben Account-ID erscheinen.", + "qm": "", + "uebernahme": "übernehmen - der einheitliche Partnerstamm ist die fachlich gewollte Zielstruktur." + }, + { + "id": "StRS-002", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Parallelbetrieb von Alt-Kundenstamm und Account-Stamm", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, SyRS-002, SwRS-002", + "konsolidierung": "Kandidat: StRS-001 — im Zielsystem ist nur ein Partnerstamm vorzusehen.", + "pruefidee": "Umschalten der Einstellung muss genau eines der beiden Module verfügbar machen.", + "qm": "", + "uebernahme": "Workaround - der Parallelbetrieb ist eine Migrationsbehelfslösung und im Zielsystem nicht nachzubilden." + }, + { + "id": "StRS-003", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Durchgängige Belegkette vom Angebot zur Rechnung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, SyRS-011, SwRS-010, SwRS-011", + "konsolidierung": "nein", + "pruefidee": "Ein Angebot mit drei Positionen wird zum Auftrag weitergeführt; der Auftrag muss dieselben drei Positionen und die Zahlungskondition des Angebots tragen.", + "qm": "", + "uebernahme": "übernehmen - die Belegkette ist Kern des Vertriebsprozesses." + }, + { + "id": "StRS-004", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Angebotserstellung mit Bewertung der Abschlusswahrscheinlichkeit", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-012, SwRS-012", + "konsolidierung": "nein", + "pruefidee": "Angebot mit Wahrscheinlichkeit „hoch\" klassifizieren; die Angebotsauswertung muss es in der entsprechenden Kategorie ausweisen.", + "qm": "", + "uebernahme": "übernehmen - Grundlage der Vertriebssteuerung." + }, + { + "id": "StRS-005", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Fakturierung erbrachter Leistungen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020, SyRS-021, SwRS-020, SwRS-021", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer ohne Recht `CREATE_NEW_INVOICE` muss beim Speichern einer neuen Rechnung eine Fehlermeldung erhalten und es darf kein Datensatz entstehen.", + "qm": "", + "uebernahme": "übernehmen - Kernfunktion." + }, + { + "id": "StRS-006", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Gutschriften als wertmäßige Korrektur", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-022, SwRS-022", + "konsolidierung": "nein", + "pruefidee": "Eine Gutschrift zu einer Rechnung anlegen; der offene Posten der Rechnung muss sich um den Gutschriftbetrag verringern lassen.", + "qm": "", + "uebernahme": "übernehmen - handelsrechtlich erforderlich." + }, + { + "id": "StRS-007", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Abholscheine und Barverkauf", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023, SwRS-023, SyRS-060", + "konsolidierung": "nein", + "pruefidee": "Ein Barverkauf muss eine Nummer aus dem Nummernkreis `CashInvoice` erhalten, nicht aus `Invoice`.", + "qm": "", + "uebernahme": "übernehmen - Barverkauf ist im Fachhandel weiterhin erforderlich." + }, + { + "id": "StRS-008", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Serviceverträge mit wiederkehrender Abrechnung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-030, SyRS-031, SwRS-030, SwRS-031", + "konsolidierung": "nein", + "pruefidee": "Vertrag mit `BillingIntervalKind = Monthly` und `BillingIntervalDuration = 3` muss quartalsweise zur Abrechnung vorgeschlagen werden.", + "qm": "", + "uebernahme": "übernehmen - tragendes Geschäftsmodell des Systemhauses." + }, + { + "id": "StRS-009", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Automatische Erzeugung von Vertragsrechnungen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-008, SyRS-032, SwRS-032", + "konsolidierung": "nein", + "pruefidee": "Ein Vertrag mit Abrechnung zum Monatsende muss beim Lauf mit Stichtag Monatsende in der Vorschlagsliste erscheinen, beim Lauf zum Monatsanfang nicht.", + "qm": "", + "uebernahme": "übernehmen - ohne Automatik ist das Vertragsgeschäft nicht wirtschaftlich zu betreiben." + }, + { + "id": "StRS-010", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Abrechnung nach Zählerständen (Klickabrechnung)", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-008, SyRS-033, SwRS-033", + "konsolidierung": "Kandidat: StRS-032 — Zählerstände werden sowohl über Stammblätter als auch über die docuFORM-Anbindung geführt.", + "pruefidee": "Zwei aufeinanderfolgende Zählerstände erfassen; die erzeugte Rechnungsposition muss die Differenz als Menge tragen.", + "qm": "", + "uebernahme": "übernehmen - Standardgeschäftsmodell im Managed-Print-Umfeld." + }, + { + "id": "StRS-011", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Pauschalabrechnung von Projekten", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-034, SwRS-034", + "konsolidierung": "nein", + "pruefidee": "Ohne das Recht `FLATRATE_BILLING_MODULE` darf das Modul „Pauschalabrechnung\" nicht im Menü erscheinen.", + "qm": "", + "uebernahme": "übernehmen - eigenständiges Abrechnungsmodell." + }, + { + "id": "StRS-012", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Abrechnung erfasster Ticketzeiten", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-014, SyRS-035, SwRS-035", + "konsolidierung": "Kandidat: StRS-011 — Pauschal- und Zeitabrechnung erzeugen beide Abrechnungsbelege aus Leistungsdaten über getrennte Module.", + "pruefidee": "Ein bereits abgerechneter Zeiteintrag darf in einem zweiten Abrechnungslauf nicht mehr als abrechenbar erscheinen.", + "qm": "", + "uebernahme": "übernehmen - Kern des Dienstleistungsgeschäfts." + }, + { + "id": "StRS-013", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Provisionsabrechnung für Vertriebsmitarbeiter", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-036, SwRS-036", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer mit dem Recht `PROVISION_EVALUATION_MODULE` darf die Schemaverwaltung nicht zusätzlich als eigenes Modul sehen.", + "qm": "", + "uebernahme": "übernehmen - Vergütungsrelevant." + }, + { + "id": "StRS-014", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Erfassung und Nachweis von Arbeitszeiten am Ticket", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-040, SyRS-041, SwRS-040, SwRS-041", + "konsolidierung": "nein", + "pruefidee": "Eine gestartete und pausierte Erfassung darf nach dem Fortsetzen die Pausenzeit nicht als Arbeitszeit ausweisen.", + "qm": "", + "uebernahme": "übernehmen - Grundlage der Leistungsabrechnung." + }, + { + "id": "StRS-015", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Bestätigung erbrachter Leistung durch Kundenunterschrift", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-014, SyRS-042, SwRS-042", + "konsolidierung": "nein", + "pruefidee": "Ein zweiter Unterschriftsversuch am selben Zeiteintrag muss abgewiesen werden.", + "qm": "", + "uebernahme": "übernehmen - Nachweis gegenüber dem Kunden." + }, + { + "id": "StRS-016", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Bearbeitung von Servicetickets", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-050, SyRS-051, SwRS-050, SwRS-051", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer ohne `EDIT_HELPDESK` muss beim Speichern eines bestehenden Tickets die Meldung „Sie haben nicht das Recht ‚Ticket bearbeiten'\" erhalten.", + "qm": "", + "uebernahme": "übernehmen - Kernprozess des Servicegeschäfts." + }, + { + "id": "StRS-017", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Abgestufte Sichtbarkeit von Tickets", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016, StRS-031, SyRS-052, SwRS-052", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer mit `SHOW_HELPDESK` und `SHOW_HELPDESK_ONLY_OWN` darf ein Ticket eines Kollegen weder in der Liste noch über die Direktsuche öffnen können.", + "qm": "", + "uebernahme": "übernehmen - datenschutz- und mandantenrelevant." + }, + { + "id": "StRS-018", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Retouren-, Reparatur- und Tauschabwicklung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-053, SwRS-053, StRS-021", + "konsolidierung": "nein", + "pruefidee": "Nach einem Gerätetausch muss die alte Seriennummer den Zustand `ManuallyBookedOut` und die neue den Zustand `InInvoice` tragen.", + "qm": "", + "uebernahme": "übernehmen - gesetzliche Gewährleistungsabwicklung." + }, + { + "id": "StRS-019", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Checklisten zur Qualitätssicherung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-054, SwRS-054", + "konsolidierung": "nein", + "pruefidee": "Ein abgehakter Checklistenpunkt muss mit Benutzer und Zeitpunkt in der Änderungsverfolgung erscheinen.", + "qm": "", + "uebernahme": "übernehmen - Qualitätsnachweis." + }, + { + "id": "StRS-020", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Aufgabenverwaltung quer zu Tickets", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-055, SwRS-055", + "konsolidierung": "Kandidat: StRS-046 — Aufgaben (`TaskManager`) und Todo-Liste (`ToDoArea`) bilden beide zu erledigende Vorgänge in getrennten Datenhaltungen ab.", + "pruefidee": "Eine Aufgabe mit zwei zugeordneten Tickets muss in beiden Tickets als verknüpft erscheinen.", + "qm": "", + "uebernahme": "übernehmen - Steuerung übergreifender Servicearbeiten." + }, + { + "id": "StRS-021", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Bestandsführung mit Einzelstückverfolgung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-060, SyRS-061, SwRS-060, SwRS-061", + "konsolidierung": "nein", + "pruefidee": "Ein Warenausgang eines seriennummernpflichtigen Artikels muss den Barcode-Zustand ändern und einen Historieneintrag erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Grundlage von Gewährleistung und Inventur." + }, + { + "id": "StRS-022", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Inventur mit Zählgruppen und Abschluss", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-021, SyRS-062, SwRS-062", + "konsolidierung": "Kandidat: SwRS-063 — es existieren `InventoryBL` und `InventoryNewBL` als zwei Implementierungen derselben Fachfunktion.", + "pruefidee": "Nach `CloseInventory` dürfen keine weiteren Zählmengen zur Inventur erfassbar sein.", + "qm": "", + "uebernahme": "übernehmen - handelsrechtlich vorgeschrieben." + }, + { + "id": "StRS-023", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kommissionierung von Aufträgen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-003, StRS-021, SyRS-063, SwRS-064", + "konsolidierung": "nein", + "pruefidee": "Ein teilkommissionierter Auftrag darf beim Weiterführen in einen Lieferschein nur die kommissionierte Menge übernehmen oder eine Warnung erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Logistikkernprozess." + }, + { + "id": "StRS-024", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Beschaffung über Lieferantenbelege", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-070, SwRS-070", + "konsolidierung": "Kandidat: StRS-003 — Verkaufs- und Einkaufsbelegkette sind funktional gleichartig, aber getrennt implementiert.", + "pruefidee": "Eine Bestellung ohne Recht `Purchase.Supplier.Order` darf nicht angelegt werden können.", + "qm": "", + "uebernahme": "übernehmen - Kernprozess." + }, + { + "id": "StRS-025", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Elektronischer Datenaustausch mit Distributoren", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-024, SyRS-071, SwRS-071", + "konsolidierung": "nein", + "pruefidee": "Eine per EDI versandte Bestellung muss einen Eintrag im EDI-Protokoll mit Zeitstempel und Lieferantenbezug erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Wettbewerbsvoraussetzung im IT-Handel." + }, + { + "id": "StRS-026", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Elektronische Rechnungsformate", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-024, StRS-005, SyRS-072, SwRS-072", + "konsolidierung": "nein", + "pruefidee": "Eine ZUGFeRD-Rechnung mit bekanntem Betrag muss nach dem Import eine Lieferantenrechnung mit demselben Betrag erzeugen.", + "qm": "", + "uebernahme": "übernehmen - gesetzlich vorgeschrieben (E-Rechnungspflicht)." + }, + { + "id": "StRS-027", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Übergabe an die Finanzbuchhaltung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-005, SyRS-080, SwRS-080", + "konsolidierung": "Kandidat: StRS-027 selbst — „Buchhaltungsexport/-import\" und „Datev Belegtransfer\" sind zwei Module für dieselbe fachliche Übergabe.", + "pruefidee": "Ein Beleg einer Filiale mit abweichendem Erlöskonto muss im Export dieses Konto tragen, nicht das Standardkonto.", + "qm": "", + "uebernahme": "übernehmen - gesetzlich erforderlich." + }, + { + "id": "StRS-028", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Offene-Posten-Verwaltung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-005, SyRS-081, SwRS-081", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer ohne das Recht `Controlling.Finances.Dunning` darf die OPOS-Liste nicht öffnen können.", + "qm": "", + "uebernahme": "übernehmen - Liquiditätssteuerung." + }, + { + "id": "StRS-029", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Mehrstufiges Mahnwesen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-028, SyRS-082, SwRS-082, SyRS-083", + "konsolidierung": "nein", + "pruefidee": "Ein Mahnlauf auf einer Rechnung der Stufe 2 muss die Stufe auf 3 setzen und `DunningLevel3Date` füllen; die Rücknahme muss wieder Stufe 2 ergeben.", + "qm": "", + "uebernahme": "übernehmen - Forderungsmanagement." + }, + { + "id": "StRS-030", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Auftragssperre bei erreichter Mahnstufe", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-029, StRS-003, SyRS-084, SwRS-083", + "konsolidierung": "nein", + "pruefidee": "Kunde mit Mahnstufe 2 und `OrderLockAfterDunning = 2`: die Auftragsanlage muss scheitern, die Rechnungsanlage jedoch gelingen.", + "qm": "", + "uebernahme": "übernehmen - Risikosteuerung." + }, + { + "id": "StRS-031", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Rollenbasierte Berechtigungsverwaltung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-090, SyRS-091, SwRS-090, SwRS-091", + "konsolidierung": "nein", + "pruefidee": "Entfernt man einen Benutzer aus einer Gruppe, dürfen die über diese Gruppe vergebenen Rechte unmittelbar nicht mehr greifen.", + "qm": "", + "uebernahme": "übernehmen - Grundlage jeder Zugriffssteuerung." + }, + { + "id": "StRS-032", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Einschränkende Rechte auf eigene Objekte oder eigene Filiale", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031, StRS-034, SyRS-092, SwRS-092", + "konsolidierung": "nein", + "pruefidee": "Benutzer der Filiale A mit `EDIT_INVOICE_ONLY_OWN_BRANCH` darf eine Rechnung der Filiale B nicht speichern können.", + "qm": "", + "uebernahme": "übernehmen - erforderlich für filialübergreifende Installationen." + }, + { + "id": "StRS-033", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Anmeldung über mehrere Identitätsquellen", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-100, SyRS-101, SwRS-100, SwRS-101", + "konsolidierung": "nein", + "pruefidee": "Für jede der vier Identitätsquellen muss eine erfolgreiche Anmeldung ein gültiges Ticket liefern und eine fehlerhafte Anmeldung eine Fehlermeldung ohne Ticket.", + "qm": "", + "uebernahme": "übernehmen - Voraussetzung für den SaaS-Betrieb." + }, + { + "id": "StRS-034", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Mandanten- und Filialstruktur", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-032, StRS-035, SyRS-093, SwRS-093", + "konsolidierung": "nein", + "pruefidee": "Ein Beleg der Filiale B muss eine Nummer aus dem Nummernkreis der Filiale B erhalten, falls dieser gepflegt ist.", + "qm": "", + "uebernahme": "übernehmen - Voraussetzung für Mehrmandantenbetrieb." + }, + { + "id": "StRS-035", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Lückenlose Belegnummernvergabe", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-034, SyRS-094, SwRS-094, SwRS-095", + "konsolidierung": "nein", + "pruefidee": "Zwei gleichzeitige Nummernanforderungen derselben Nummernart müssen zwei verschiedene Nummern liefern.", + "qm": "", + "uebernahme": "übernehmen - Grundsätze ordnungsmäßiger Buchführung." + }, + { + "id": "StRS-036", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Lizenzabhängige Funktionsfreischaltung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-102, SwRS-102, SyRS-103", + "konsolidierung": "nein", + "pruefidee": "Nach Entzug der Lizenz `PasswordManager` darf das Modul „Zugänge\" beim nächsten Anmelden nicht mehr registriert werden.", + "qm": "", + "uebernahme": "übernehmen - Geschäftsmodell des Herstellers; im SaaS-Zielsystem als Tarif-/Feature-Steuerung." + }, + { + "id": "StRS-037", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Begrenzung gleichzeitiger Anmeldungen über Lizenzanzahl", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-036, StRS-033, SyRS-104, SwRS-103", + "konsolidierung": "nein", + "pruefidee": "Bei Lizenzanzahl 1 muss die zweite Anmeldung eines anderen Benutzers scheitern, eine erneute Anmeldung desselben Benutzers auf demselben Gerät jedoch gelingen.", + "qm": "", + "uebernahme": "übernehmen - im SaaS-Zielsystem als Sitzplatzmodell." + }, + { + "id": "StRS-038", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Formulargestützte Belegausgabe", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-110, SwRS-110, StRS-039", + "konsolidierung": "nein", + "pruefidee": "Nach dem Druck einer Rechnung mit aktivierter Ablageoption muss in der Belegablage ein PDF mit dem Rechnungsdatum liegen.", + "qm": "", + "uebernahme": "übernehmen - Belegausgabe ist Pflicht." + }, + { + "id": "StRS-039", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Zentrale Dokumentenablage je Geschäftsobjekt", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-111, SwRS-111", + "konsolidierung": "nein", + "pruefidee": "Ein zu einem Ticket abgelegtes Dokument muss über die Ticket-ID wieder auffindbar sein und darf bei einem anderen Ticket nicht erscheinen.", + "qm": "", + "uebernahme": "übernehmen - Dokumentenzuordnung ist Grundfunktion." + }, + { + "id": "StRS-040", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "E-Mail-Kommunikation aus dem Vorgang heraus", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-112, SwRS-112, StRS-041", + "konsolidierung": "nein", + "pruefidee": "Eine aus einer Rechnung versandte E-Mail muss den in den Mail-Einstellungen für Rechnungen hinterlegten Absender tragen.", + "qm": "", + "uebernahme": "übernehmen - Standardkommunikationsweg." + }, + { + "id": "StRS-041", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Ticketerzeugung aus eingehenden E-Mails", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016, StRS-040, SyRS-113, SwRS-113", + "konsolidierung": "nein", + "pruefidee": "Eine E-Mail mit einer bekannten Ticketnummer im Betreff muss dem bestehenden Ticket zugeordnet werden statt ein neues zu erzeugen.", + "qm": "", + "uebernahme": "übernehmen - wesentlicher Eingangskanal." + }, + { + "id": "StRS-042", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Terminplanung und Kalendersynchronisation", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-114, SwRS-114", + "konsolidierung": "nein", + "pruefidee": "Ein im System angelegter Ticket-Termin muss nach der Synchronisation im Exchange-Kalender des Bearbeiters erscheinen.", + "qm": "", + "uebernahme": "übernehmen - Einsatzplanung." + }, + { + "id": "StRS-043", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Telefonieanbindung mit Anruferkennung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-115, SwRS-115", + "konsolidierung": "nein", + "pruefidee": "Ein Anruf von einer im Kundenstamm hinterlegten Rufnummer muss den zugehörigen Kunden anzeigen.", + "qm": "", + "uebernahme": "übernehmen - in der Serviceannahme etabliert; im Zielsystem als CTI-Schnittstelle." + }, + { + "id": "StRS-044", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kundenportal mit Ticket-, Beleg- und Bestellzugang", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-045, StRS-017, SyRS-120, SwRS-120", + "konsolidierung": "nein", + "pruefidee": "Ein Web-Konto ohne das Recht auf Belegeinsicht darf die Seite `ReceiptsOverview` nicht öffnen können.", + "qm": "", + "uebernahme": "übernehmen - im SaaS-Zielsystem zentraler Kanal." + }, + { + "id": "StRS-045", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Belegfreigabe und Unterzeichnung durch den Kunden", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-044, StRS-038, SyRS-121, SwRS-121", + "konsolidierung": "nein", + "pruefidee": "Ein bereits verwendeter oder abgelaufener Token darf keine erneute Zustandsänderung des Belegs erlauben.", + "qm": "", + "uebernahme": "übernehmen - beschleunigt den Vertriebsabschluss." + }, + { + "id": "StRS-046", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Persönliche Aufgaben- und Tagesplanung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-020, SyRS-122, SwRS-122", + "konsolidierung": "Kandidat: StRS-020 — Aufgabenverwaltung (`TaskManager`) und Todo-Liste (`ToDoArea`) sind zwei Datenhaltungen für zu erledigende Vorgänge.", + "pruefidee": "Beim Abschließen eines Tickets müssen die zugehörigen Aufgaben entfernt werden.", + "qm": "", + "uebernahme": "übernehmen - Arbeitsorganisation." + }, + { + "id": "StRS-047", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Verwaltung von Kundenzugangsdaten", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-050, SyRS-130, SwRS-130, SwRS-131", + "konsolidierung": "Kandidat: StRS-048 — `PasswordManager` und `PasswordManagementArea` sind zwei Implementierungen derselben Fachfunktion.", + "pruefidee": "Der in der Datenbank abgelegte Kennwortwert darf im Klartext nicht auffindbar sein; ein Lesezugriff muss einen Protokolleintrag erzeugen.", + "qm": "", + "uebernahme": "übernehmen - für den Servicebetrieb erforderlich." + }, + { + "id": "StRS-048", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Ablösung des alten Zugangsdatenmoduls", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-047, SyRS-131, SwRS-132", + "konsolidierung": "Kandidat: StRS-047", + "pruefidee": "Eine Neuanlage im alten Modul darf im Zielsystem nicht mehr möglich sein; Altdaten müssen im neuen Modul sichtbar sein.", + "qm": "", + "uebernahme": "veraltet - das Modul ist im Code als obsolet gekennzeichnet und speichert keine Kennwörter mehr." + }, + { + "id": "StRS-049", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Verwaltung installierter Kundengeräte", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-010, StRS-051, SyRS-140, SwRS-140, SwRS-141", + "konsolidierung": "Kandidat: SwRS-140, SwRS-141, SwRS-142 — Stammblätter, Account-Geräte, Asset-Management-Geräte und Customer-Assets bilden denselben fachlichen Gegenstand „installiertes Gerät\" in getrennten Datenhaltungen ab und sind im Zielsystem zu einem Asset-Konzept zusammenzuführen.", + "pruefidee": "Ein Gerät mit bekannter Seriennummer muss über alle Geräteansichten hinweg auffindbar sein.", + "qm": "", + "uebernahme": "übernehmen - fachlich erforderlich, jedoch nur in konsolidierter Form." + }, + { + "id": "StRS-050", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Wahrung der Betroffenenrechte nach DSGVO", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031, SyRS-150, SwRS-150, SwRS-151", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer ohne `DSGVO_DELETE_CONTACT` darf weder die Kontaktliste abrufen noch löschen.", + "qm": "", + "uebernahme": "übernehmen - gesetzlich zwingend." + }, + { + "id": "StRS-051", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Nachvollziehbarkeit von Änderungen an Geschäftsobjekten", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-151, SwRS-152, StRS-050", + "konsolidierung": "nein", + "pruefidee": "Nach einer Belegänderung müssen `ChangedByI3D`, `ChangedAt` und `ChangedThroughApplication` auf den auslösenden Benutzer und Client verweisen.", + "qm": "Wartbarkeit (Analysierbarkeit)", + "uebernahme": "übernehmen - Revisionssicherheit." + }, + { + "id": "StRS-052", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Betrieb als Windows-Anwendung und als Container-Dienst", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-160, SwRS-160", + "konsolidierung": "nein", + "pruefidee": "Derselbe REST-Aufruf muss gegen den Windows-Dienst und gegen den Container dieselbe Antwort liefern.", + "qm": "Übertragbarkeit (Installierbarkeit)", + "uebernahme": "übernehmen - der Containerbetrieb ist die Grundlage der SaaS-Zielarchitektur." + }, + { + "id": "StRS-053", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Automatisierte Datenbankmigration bei Programmstart", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-161, SwRS-161", + "konsolidierung": "nein", + "pruefidee": "Ein zweiter Programmstart darf keine bereits eingetragene Skriptnummer erneut ausführen.", + "qm": "Wartbarkeit (Modifizierbarkeit)", + "uebernahme": "übernehmen - Voraussetzung für Wartungsfreiheit im Feld; im Zielsystem als Migrationsframework." + }, + { + "id": "StRS-054", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Auswertungen und Kennzahlen für die Unternehmenssteuerung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-170, SwRS-170", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer ohne das Analytics-Recht darf das Modul „Analytics\" nicht sehen.", + "qm": "", + "uebernahme": "übernehmen - Steuerungsgrundlage." + }, + { + "id": "StRS-055", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Objektübergreifende Volltextsuche", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-171, SwRS-171", + "konsolidierung": "nein", + "pruefidee": "Ein neu angelegtes Ticket muss nach `RequestUpdateFor` über seinen Betreff in der Volltextsuche auffindbar sein.", + "qm": "", + "uebernahme": "übernehmen - Bedienkomfort und Auffindbarkeit." + }, + { + "id": "StRS-056", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "KI-gestützte Assistenz", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-036, SyRS-172, SwRS-172", + "konsolidierung": "nein", + "pruefidee": "Ohne die Lizenz `AiAssistant` darf die persönliche KI-Einstellungsseite nicht erscheinen.", + "qm": "", + "uebernahme": "übernehmen - jüngste Funktionserweiterung." + }, + { + "id": "StRS-057", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kampagnen und Serienkommunikation", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-040, SyRS-173, SwRS-173", + "konsolidierung": "nein", + "pruefidee": "Eine Kampagne mit zehn Empfängern muss zehn dokumentierte Aussendungen erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Vertriebsunterstützung." + }, + { + "id": "StRS-058", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Wiederverwendbare Textbausteine", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-003, SyRS-174, SwRS-174", + "konsolidierung": "nein", + "pruefidee": "Ein Beleg für einen Kunden mit eigenem Anredebaustein muss diesen statt des allgemeinen Bausteins tragen.", + "qm": "", + "uebernahme": "übernehmen - Einheitlichkeit der Außendarstellung." + }, + { + "id": "StRS-059", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Kundenindividuelle Zusatzfelder", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-047, SyRS-175, SwRS-175", + "konsolidierung": "nein", + "pruefidee": "Ein neu definiertes Zusatzfeld vom Typ `EncryptedText` darf in der Datenbank nicht im Klartext lesbar sein.", + "qm": "", + "uebernahme": "übernehmen - reduziert kundenspezifische Programmierung." + }, + { + "id": "StRS-060", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Produktionsaufträge und Maschinenverwaltung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-180, SwRS-180", + "konsolidierung": "nein", + "pruefidee": "Ein Produktionsauftrag mit drei Arbeitsschritten muss nach Abschluss des zweiten Schritts einen entsprechenden Fortschritt ausweisen.", + "qm": "", + "uebernahme": "übernehmen - für fertigende Kunden erforderlich." + }, + { + "id": "StRS-061", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Mitarbeiterverwaltung als Grundlage der Zuständigkeit", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-033, SyRS-181, SwRS-181", + "konsolidierung": "nein", + "pruefidee": "Ein Mitarbeiter mit Austrittstermin in der Vergangenheit darf sich nicht mehr anmelden können.", + "qm": "", + "uebernahme": "übernehmen - Sicherheitsanforderung." + }, + { + "id": "StRS-062", + "ebene": "StRS", + "datei_ebene": "StRS", + "fremdabgelegt": false, + "titel": "Anbindung von Fremd- und Monitoringsystemen", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-049, SyRS-182, SwRS-182", + "konsolidierung": "nein", + "pruefidee": "Ein aus einem RMM-System importiertes Gerät muss über seine Fremdsystem-ID erneut auffindbar sein und darf beim zweiten Import nicht doppelt angelegt werden.", + "qm": "", + "uebernahme": "übernehmen - Integrationsfähigkeit ist Kaufkriterium." + }, + { + "id": "SyRS-001", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Rechteprüfung bei Anlage und Änderung von Geschäftspartnern", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, StRS-031, SwRS-001", + "konsolidierung": "nein", + "pruefidee": "Anlageversuch ohne `CREATE_CUSTOMER` muss die Fehlermeldung liefern und darf keinen Datensatz erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Grundschutz der Stammdaten." + }, + { + "id": "SyRS-002", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Rollenzuordnung eines Geschäftspartners über Zuordnungstabellen", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, SwRS-002", + "konsolidierung": "Kandidat: SwRS-002 — Alt-Tabellen `Kunden`/`Kreditor` halten dieselbe Information redundant.", + "pruefidee": "Ein Account mit Einträgen in `AccountCustomers` und `AccountSuppliers` muss in beiden Rollenlisten erscheinen.", + "qm": "", + "uebernahme": "übernehmen - Zielstruktur." + }, + { + "id": "SyRS-003", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mehrfachadressen und Ansprechpartner je Geschäftspartner", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, SwRS-003", + "konsolidierung": "nein", + "pruefidee": "Ein Asset ohne gesetzte `AddressI3D` muss die Standardadresse des Kunden anzeigen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-004", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kundenindividuelle Sonderpreise", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-044, SyRS-011, SwRS-004", + "konsolidierung": "Kandidat: SwRS-005 — Sonderpreise, Staffelpreise (`ArticleVolumePricesBL`), Aktionspreise (`ActionPriceBL`) und Produktmatrix sind vier getrennte Preisquellen.", + "pruefidee": "Ein Artikel mit Sonderpreis muss im Beleg dieses Kunden den Sonderpreis tragen, bei einem anderen Kunden den Listenpreis.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-005", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mehrstufige Preisquellen mit definierter Rangfolge", + "typ": "funktional", + "belege": [ + "SEKUNDÄR", + "SEKUNDÄR", + "KONTEXT" + ], + "status": "HYPOTHESE", + "hypothese": true, + "workaround": false, + "tracelinks": "SyRS-004, SwRS-005", + "konsolidierung": "Kandidat: SyRS-004", + "pruefidee": "Ein Artikel mit gleichzeitig gültigem Aktions-, Staffel- und Sonderpreis muss im Beleg genau einen dieser Preise tragen, und zwar denselben bei wiederholter Anlage.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem mit ausdrücklich dokumentierter Rangfolge." + }, + { + "id": "SyRS-006", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Steuersatzwechsel über verkettete Steuersätze", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-005, SwRS-006", + "konsolidierung": "nein", + "pruefidee": "Ein zum 31.12. auslaufender Steuersatz muss für ein Belegdatum im Folgejahr den Folgesatz liefern.", + "qm": "", + "uebernahme": "übernehmen - steuerrechtlich zwingend." + }, + { + "id": "SyRS-007", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Massenumstellung von Artikelsteuersätzen mit Preisoption", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-006, StRS-051, SwRS-007", + "konsolidierung": "nein", + "pruefidee": "Nach der Umstellung mit `updateArticlePrices = true` muss der Bruttopreis unverändert und der Nettopreis geändert sein; im Artikelprotokoll muss „Bruttopreise beibehalten\" stehen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-008", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Länderabhängige Steuersätze", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-006, SwRS-008", + "konsolidierung": "nein", + "pruefidee": "Ein Beleg an einen Empfänger in der Schweiz muss einen der für die Schweiz gepflegten Steuersätze vorschlagen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-009", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Warengruppenhierarchie mit Erlöskontozuordnung", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-027, SwRS-009", + "konsolidierung": "nein", + "pruefidee": "Ein Artikel mit eigenem Filial-Erlöskonto muss dieses und nicht das Warengruppenkonto verwenden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-010", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Pflichtprüfungen beim Speichern eines Belegs", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-003, SwRS-010", + "konsolidierung": "nein", + "pruefidee": "Das Entfernen einer bereits in einen Lieferschein weitergeführten Auftragsposition muss beim Speichern abgewiesen werden.", + "qm": "", + "uebernahme": "übernehmen - Datenintegrität der Belegkette." + }, + { + "id": "SyRS-011", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Automatische Positionsergänzung beim Speichern", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, SwRS-011", + "konsolidierung": "nein", + "pruefidee": "Ein Beleg oberhalb der frachtfreien Grenze darf nach dem Speichern keine Frachtposition mehr enthalten.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-012", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Nebenläufigkeitsschutz über Concurrency-GUID", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, SwRS-012", + "konsolidierung": "nein", + "pruefidee": "Zwei parallele Änderungen desselben Belegs: die zweite muss mit einem Nebenläufigkeitsfehler scheitern.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als optimistische Sperre." + }, + { + "id": "SyRS-013", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Belegsperre während der Bearbeitung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-012, SwRS-013", + "konsolidierung": "nein", + "pruefidee": "Ein durch Benutzer A gesperrter Beleg darf durch Benutzer B nicht bearbeitbar sein.", + "qm": "", + "uebernahme": "übernehmen - Alternative zur reinen optimistischen Sperre; im Zielsystem zu vereinheitlichen." + }, + { + "id": "SyRS-014", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Belegversionierung mit vollständiger Historienkopie", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-051, SyRS-010, SwRS-014", + "konsolidierung": "nein", + "pruefidee": "Nach dem Anlegen der Version 2 muss der Inhalt der Version 1 unverändert abrufbar sein.", + "qm": "", + "uebernahme": "übernehmen - Revisionsanforderung; im Zielsystem ohne Tabellenverdopplung zu lösen." + }, + { + "id": "SyRS-015", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kopieren eines Belegs auf einen anderen Geschäftspartner", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, SwRS-015", + "konsolidierung": "nein", + "pruefidee": "Die Kopie eines Angebots auf einen anderen Kunden muss dessen Konditionen und eine neue Angebotsnummer tragen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-016", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Belegvorlagen mit festem Ersatzdatum", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, SwRS-016", + "konsolidierung": "nein", + "pruefidee": "Eine Belegvorlage darf in einer Umsatzauswertung des laufenden Jahres nicht erscheinen.", + "qm": "", + "uebernahme": "Workaround - das feste Datum 1970-01-01 ist eine Behelfslösung; im Zielsystem ist ein eigenes Vorlagenkennzeichen ohne Ersatzdatum vorzusehen." + }, + { + "id": "SyRS-017", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zahlungsziel aus Zahlungskondition", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-028, SwRS-017", + "konsolidierung": "nein", + "pruefidee": "Zahlungskondition „30 Tage netto\" muss bei Belegdatum 1. März das Fälligkeitsdatum 31. März ergeben.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-018", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Abweichende Liefer-, Rechnungs- und Lizenznehmeradresse", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-003, SyRS-003, SwRS-018", + "konsolidierung": "nein", + "pruefidee": "Ein Auftrag mit abweichender Rechnungsadresse muss diese Adresse in der daraus erzeugten Rechnung tragen.", + "qm": "", + "uebernahme": "übernehmen - im Lizenzhandel erforderlich." + }, + { + "id": "SyRS-019", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Erzeugung von Tickets aus einem Beleg", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016, StRS-003, SwRS-019", + "konsolidierung": "nein", + "pruefidee": "Ein Auftrag mit zwei servicebezogenen Positionen muss zwei verknüpfte Tickets erzeugen können.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-020", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Rechteprüfung an jedem Belegänderungspunkt", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-005, StRS-031, StRS-032, SwRS-020", + "konsolidierung": "nein", + "pruefidee": "Das Ändern des Projektnummernfelds einer Rechnung ohne `EDIT_INVOICE` muss abgewiesen werden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-021", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Getrennte Rechte für Einkaufs- und Verkaufspreisänderung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020, SwRS-021", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer ohne `CHANGE_PRICE` ändert einen Verkaufspreis; nach dem Speichern muss der alte Preis wieder eingetragen sein.", + "qm": "", + "uebernahme": "übernehmen - Margenschutz." + }, + { + "id": "SyRS-022", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Belegartspezifische Ausprägung über austauschbare Logikbausteine", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, SwRS-022", + "konsolidierung": "nein", + "pruefidee": "Für jede der sieben Belegarten muss `_specificLogics.Execute` genau eine Implementierung finden.", + "qm": "", + "uebernahme": "übernehmen - tragfähiges Erweiterungsmuster." + }, + { + "id": "SyRS-023", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Gemeinsames Objektprotokoll über Objektart und Objekt-ID", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-051, SwRS-023", + "konsolidierung": "nein", + "pruefidee": "Ein Protokolleintrag mit `AnlageArt = 4` muss ausschließlich Rechnungen zugeordnet werden.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als polymorphe Referenz zu formalisieren." + }, + { + "id": "SyRS-030", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kontingentverbrauch und Restkontingent eines Vertrags", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-008, StRS-012, SwRS-030", + "konsolidierung": "nein", + "pruefidee": "Ein Vertrag mit 10 Stunden Kontingent und 12 gebuchten Stunden muss ein Restkontingent von 0 und 2 abzurechnende Stunden ausweisen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-031", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Ausgleichsartikel für Kontingentsalden", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-030, SwRS-031", + "konsolidierung": "Kandidat: SwRS-031 — Vertrags- und Pauschalabrechnung führen zwei getrennte Ausgleichsartikel für denselben Zweck.", + "pruefidee": "Eine Vertragsrechnung mit Kontingentsaldo muss eine Position mit dem konfigurierten Ausgleichsartikel enthalten.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-032", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Stichtagsbezogene Ermittlung fälliger Abrechnungen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-009, SwRS-032", + "konsolidierung": "nein", + "pruefidee": "Ein Lieferschein mit Datum nach dem Stichtag darf nicht in der Vorschlagsliste erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-033", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Import externer Artikel- und Mengendaten in Verträge", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-008, StRS-062, SwRS-033", + "konsolidierung": "nein", + "pruefidee": "Eine mit Gültigkeit ab 1. Juli importierte Menge darf in der Juni-Abrechnung nicht erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-034", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Gegenseitiger Ausschluss der Provisionsmodule", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-013, SwRS-034", + "konsolidierung": "nein", + "pruefidee": "Benutzer mit `PROVISION_EVALUATION_MODULE` darf im Menü kein Modul „Provisionsschemas verwalten\" sehen.", + "qm": "", + "uebernahme": "Workaround - der Ausschluss ist eine Menüsteuerung, die im Zielsystem durch eine gemeinsame Provisionsoberfläche ersetzt werden sollte." + }, + { + "id": "SyRS-035", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Einmalige Abrechnung eines Zeiteintrags", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012, StRS-014, SwRS-035", + "konsolidierung": "nein", + "pruefidee": "Ein bereits einem Auftrag zugeordneter Zeiteintrag darf im nächsten Abrechnungslauf nicht als abrechenbar erscheinen.", + "qm": "", + "uebernahme": "übernehmen - verhindert Doppelfakturierung." + }, + { + "id": "SyRS-036", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Stundensatzzuschläge nach Zeitfenstern", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-012, StRS-014, SwRS-036", + "konsolidierung": "nein", + "pruefidee": "Ein Einsatz von 21:00 bis 23:00 Uhr mit Nachtzuschlag ab 22:00 Uhr muss eine Stunde ohne und eine Stunde mit Zuschlag ergeben.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-040", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zustandsmaschine der Ticketzeiterfassung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-014, SwRS-040", + "konsolidierung": "nein", + "pruefidee": "Ein `ResumeRecording` ohne vorangegangenes `PauseRecording` muss abgewiesen werden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-041", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Erinnerung an laufende Zeiterfassungen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-040, SwRS-041", + "konsolidierung": "nein", + "pruefidee": "Eine über Nacht laufende Erfassung muss am Folgetag als Hinweis erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-042", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Löschen von Zeiteinträgen nur mit eigenem Recht", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-014, StRS-031, SwRS-042", + "konsolidierung": "nein", + "pruefidee": "Ohne das Recht muss der Löschversuch fehlschlagen und der Eintrag erhalten bleiben.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-050", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Pflichtfelder beim Speichern eines Tickets", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016, SwRS-050", + "konsolidierung": "nein", + "pruefidee": "Ein Ticket ohne Kunde muss mit der Meldung „Kein Kunde ausgewählt\" abgewiesen werden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-051", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Rechteprüfungen beim Speichern eines Tickets", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016, StRS-031, SwRS-051", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer ohne `MATURITY_CHANGE` darf das Fälligkeitsdatum eines Tickets nicht ändern, andere Felder aber schon.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-052", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kürzung von Ticket-Textfeldern auf Datenbanklänge", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-050, SwRS-052", + "konsolidierung": "nein", + "pruefidee": "Eine Kurzbeschreibung mit 1.500 Zeichen muss nach dem Speichern 1.000 Zeichen umfassen.", + "qm": "", + "uebernahme": "Workaround - das stille Abschneiden verdeckt einen Eingabefehler; im Zielsystem ist die Länge in der Eingabemaske zu begrenzen." + }, + { + "id": "SyRS-053", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Automatischer Präfix für Ticket-Kurzbeschreibungen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-050, SwRS-053", + "konsolidierung": "nein", + "pruefidee": "Ein Ticket ohne gesetzte Kategorie darf bei einem Präfix `@@Hauptkategorie@@` keinen leeren Präfix erhalten.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-054", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Ticketabschluss mit Folgeaktionen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016, StRS-046, SwRS-054", + "konsolidierung": "nein", + "pruefidee": "Nach dem Abschluss darf keine offene Aufgabe zum Ticket mehr existieren und ein Historieneintrag vom Typ `Close` muss vorliegen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-055", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Ticketabschluss trotz offener RMA", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "HYPOTHESE", + "hypothese": true, + "workaround": false, + "tracelinks": "SyRS-054, StRS-018, SwRS-055", + "konsolidierung": "nein", + "pruefidee": "Ticket mit offener RMA abschließen: im heutigen Stand gelingt der Abschluss; im Zielsystem ist zu entscheiden, ob er scheitern soll.", + "qm": "", + "uebernahme": "übernehmen - die Regel ist fachlich plausibel und im Zielsystem zu klären." + }, + { + "id": "SyRS-056", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kundenbefragung nach Ticketabschluss", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-054, StRS-033, SwRS-056", + "konsolidierung": "nein", + "pruefidee": "Bei aktivierter Einstellung muss die Abschlussmail einen Umfragelink enthalten, bei deaktivierter nicht.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-057", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Weiterleitung und Eskalation von Tickets", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016, StRS-032, SwRS-057", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer mit `ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS` darf ein Ticket nicht an eine fremde Abteilung weiterleiten.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-058", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Automatische Ticketerzeugung aus Vorlagen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016, SwRS-058", + "konsolidierung": "nein", + "pruefidee": "Eine Vorlage mit monatlichem Zeitplan muss genau ein Ticket pro Monat erzeugen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-059", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zwischengespeicherte Ticketlisten für die Weboberfläche", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-016, SwRS-059", + "konsolidierung": "nein", + "pruefidee": "Nach Änderung eines Tickets muss die zwischengespeicherte Liste innerhalb des konfigurierten Intervalls den neuen Stand zeigen.", + "qm": "Performance-Effizienz (Zeitverhalten)", + "uebernahme": "übernehmen - im Zielsystem als Lese-Projektion." + }, + { + "id": "SyRS-060", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zustandsführung von Seriennummern über den gesamten Lebenslauf", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-021, StRS-018, SwRS-060", + "konsolidierung": "nein", + "pruefidee": "Eine Seriennummer, die in eine Rechnung eingeht, muss anschließend den Zustand `InInvoice` tragen.", + "qm": "", + "uebernahme": "übernehmen - Grundlage der Gewährleistungsverfolgung." + }, + { + "id": "SyRS-061", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Prüfung des Verbleibs von Barcodes bei Belegänderung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-060, SyRS-014, SwRS-061", + "konsolidierung": "nein", + "pruefidee": "Entfernt man in einer neuen Belegversion eine bereits gebuchte Seriennummer, muss das Speichern scheitern.", + "qm": "", + "uebernahme": "übernehmen - Datenintegrität." + }, + { + "id": "SyRS-062", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Stufenweiser Abschluss der Inventur", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-022, SwRS-062", + "konsolidierung": "Kandidat: SwRS-063 — `InventoryBL` und `InventoryNewBL` implementieren dieselbe Fachfunktion getrennt.", + "pruefidee": "Nach `CloseStorages` für Lager 1 darf für dieses Lager keine Zählmenge mehr erfassbar sein.", + "qm": "", + "uebernahme": "übernehmen - handelsrechtlich erforderlich." + }, + { + "id": "SyRS-063", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Teilkommissionierung mit abweichender Lieferadresse", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-023, SyRS-018, SwRS-064", + "konsolidierung": "nein", + "pruefidee": "Beim Weiterführen eines Auftrags mit zwei Teilkommissionen muss eine Warnung erscheinen.", + "qm": "", + "uebernahme": "übernehmen - Standard im Projektgeschäft." + }, + { + "id": "SyRS-064", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Rollen von Systemartikeln", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-011, SyRS-031, SwRS-065", + "konsolidierung": "nein", + "pruefidee": "Wird der Frachtartikel geändert, muss eine neu erzeugte Frachtposition den neuen Artikel verwenden.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als benannte Systemartikel-Konfiguration." + }, + { + "id": "SyRS-065", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Artikelbezogene Sichtbarkeits- und Sperrsteuerung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031, SwRS-066", + "konsolidierung": "nein", + "pruefidee": "Ein für Kunde A gesperrter Artikel darf in einem Beleg für Kunde A nicht auswählbar sein.", + "qm": "", + "uebernahme": "übernehmen - Vertriebssteuerung." + }, + { + "id": "SyRS-066", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mengeneinheiten und Umrechnung", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-021, SwRS-067", + "konsolidierung": "nein", + "pruefidee": "Die Erfassung von 2 Kartons zu je 10 Stück muss den Bestand um 20 Stück erhöhen.", + "qm": "", + "uebernahme": "übernehmen - im Handel unverzichtbar." + }, + { + "id": "SyRS-067", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Versandabwicklung über externe Dienstleister", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-004, SwRS-068", + "konsolidierung": "Kandidat: SwRS-068 — GLS und Shipcloud sind zwei getrennte Implementierungen derselben Fachfunktion „Versandauftrag erzeugen\".", + "pruefidee": "Ein Versandauftrag mit gültiger Konfiguration muss eine Sendungsnummer liefern; bei fehlerhafter Adresse muss die Fehlermeldung des Dienstleisters angezeigt werden.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem hinter einer gemeinsamen Versandschnittstelle." + }, + { + "id": "SyRS-068", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Versandbestätigung an den Kunden", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-067, StRS-040, SwRS-069", + "konsolidierung": "nein", + "pruefidee": "Bei aktivierter Einstellung muss der Versand eines Lieferscheins eine E-Mail an den Kunden auslösen.", + "qm": "", + "uebernahme": "übernehmen - Kundenerwartung." + }, + { + "id": "SyRS-070", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Erkennung doppelter Lieferantenrechnungsnummern", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-024, SwRS-070", + "konsolidierung": "nein", + "pruefidee": "Die zweite Erfassung derselben Lieferantenrechnungsnummer muss einen Hinweis auf den bestehenden Beleg erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Schutz vor Doppelzahlung." + }, + { + "id": "SyRS-071", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Protokollierung aller EDI-Übertragungen", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-025, StRS-051, SwRS-071", + "konsolidierung": "nein", + "pruefidee": "Eine fehlgeschlagene Übertragung muss einen Protokolleintrag mit Fehlerkennzeichen erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Nachweispflicht gegenüber Lieferanten." + }, + { + "id": "SyRS-072", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Distributorspezifische EDI-Ausprägungen", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-025, SwRS-072", + "konsolidierung": "Kandidat: SwRS-072 — die sechs Distributoranbindungen enthalten gleichartige Grundfunktionen in getrennten Implementierungen.", + "pruefidee": "Für jeden konfigurierten Distributor muss eine Testbestellung im jeweiligen Format erzeugt werden können.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem mit gemeinsamem Kern und dünnen Adaptern." + }, + { + "id": "SyRS-073", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Bezug von Produktdaten externer Kataloge", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-024, SwRS-073", + "konsolidierung": "Kandidat: SwRS-073 — vier Katalogschnittstellen mit gleichartiger Aufgabe.", + "pruefidee": "Ein über die Katalogsuche übernommener Artikel muss Herstellernummer, Beschreibung und Bild aus dem Katalog tragen.", + "qm": "", + "uebernahme": "übernehmen - Datenqualität im Handel." + }, + { + "id": "SyRS-074", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kontingentüberwachung externer Katalogzugriffe", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-073, SwRS-074", + "konsolidierung": "nein", + "pruefidee": "Bei aufgebrauchtem Kontingent muss die Artikelsuche eine Kontingentmeldung statt eines technischen Fehlers liefern.", + "qm": "Zuverlässigkeit (Fehlertoleranz)", + "uebernahme": "übernehmen - Robustheit gegenüber Fremdsystemen." + }, + { + "id": "SyRS-075", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Bestellvorschläge aus Bedarf und Bestand", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-024, SwRS-075", + "konsolidierung": "nein", + "pruefidee": "Ein Artikel mit offenem Auftragsbedarf oberhalb des Bestands muss in der Vorschlagsliste erscheinen.", + "qm": "", + "uebernahme": "übernehmen - Disposition." + }, + { + "id": "SyRS-076", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Filialbezogene Aufteilung von Lieferantenbestellungen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-034, StRS-024, SwRS-076", + "konsolidierung": "nein", + "pruefidee": "Eine Sammelbestellung für zwei Filialen muss zwei filialbezogene Zuordnungen erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Filialgeschäft." + }, + { + "id": "SyRS-080", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kontenfindung nach Artikel, Warengruppe und Filiale", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-027, SyRS-009, SwRS-080", + "konsolidierung": "nein", + "pruefidee": "Ein Artikel mit eigenem Filialkonto muss dieses und nicht das Warengruppenkonto im Export tragen; die Rangfolge ist an einem Beleg mit allen drei Zuordnungen zu prüfen.", + "qm": "", + "uebernahme": "übernehmen - steuerliche Kontierung." + }, + { + "id": "SyRS-081", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Erfassung des Bezahltstatus mit Herkunftsangabe", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-028, StRS-051, SwRS-081", + "konsolidierung": "nein", + "pruefidee": "Eine über das Online-Banking ausgelöste Ausgleichsbuchung muss `moduleOrAction` mit dem Bankmodul füllen.", + "qm": "", + "uebernahme": "übernehmen - Nachvollziehbarkeit von Zahlungsbuchungen." + }, + { + "id": "SyRS-082", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Prüfung und Vorschau vor dem Mahnlauf", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-029, SwRS-082", + "konsolidierung": "nein", + "pruefidee": "Eine Vorschau darf die Mahnstufe der enthaltenen Rechnungen nicht verändern.", + "qm": "", + "uebernahme": "übernehmen - Schutz vor fehlerhaften Mahnungen." + }, + { + "id": "SyRS-083", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Rücknahme eines Mahnlaufs um genau eine Stufe", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-029, SyRS-082, SwRS-082", + "konsolidierung": "nein", + "pruefidee": "Nach der Rücknahme eines Laufs, der von Stufe 1 auf 2 gehoben hat, muss Stufe 1 mit gefülltem `DunningLevel1Date` und leerem `DunningLevel2Date` vorliegen.", + "qm": "", + "uebernahme": "übernehmen - Korrekturfähigkeit." + }, + { + "id": "SyRS-084", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Keine Mahnstufensperre auf der Lieferantenseite", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-030, StRS-001, SwRS-083", + "konsolidierung": "nein", + "pruefidee": "Ein Partner mit Mahnstufe 3 auf der Kundenseite muss weiterhin als Lieferant bestellbar sein.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem ist die Rollenwirkung ausdrücklich zu entscheiden." + }, + { + "id": "SyRS-085", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "SEPA-Mandate an Vertrag und Beleg", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-008, StRS-029, SwRS-084", + "konsolidierung": "nein", + "pruefidee": "Eine aus einem Vertrag mit Mandat erzeugte Rechnung muss dasselbe Mandat tragen.", + "qm": "", + "uebernahme": "übernehmen - gesetzliche Voraussetzung für Lastschriften." + }, + { + "id": "SyRS-086", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kontoumsatzabruf über finAPI mit eigenem Recht", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-028, StRS-031, SwRS-085", + "konsolidierung": "nein", + "pruefidee": "Ohne das Online-Banking-Recht darf die Kontoumsatzansicht nicht erreichbar sein.", + "qm": "", + "uebernahme": "übernehmen - Bankdaten sind besonders schutzbedürftig." + }, + { + "id": "SyRS-087", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Protokoll der Zahlungseingänge mit eigener Laufnummer", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-028, SwRS-086", + "konsolidierung": "nein", + "pruefidee": "Zwei aufeinanderfolgende Läufe müssen verschiedene Laufnummern erhalten.", + "qm": "", + "uebernahme": "übernehmen - Nachvollziehbarkeit." + }, + { + "id": "SyRS-088", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Erzeugung von Zahlungsverkehrsdateien", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-028, SwRS-087", + "konsolidierung": "nein", + "pruefidee": "Eine erzeugte Datei muss die Summe der freigegebenen Zahlungen enthalten.", + "qm": "", + "uebernahme": "übernehmen - Zahlungsabwicklung." + }, + { + "id": "SyRS-089", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Produktlebenszyklus von Lizenzbeständen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-036, StRS-049, SwRS-088", + "konsolidierung": "nein", + "pruefidee": "Eine in 30 Tagen ablaufende Kundenlizenz muss in der Ablaufliste erscheinen.", + "qm": "", + "uebernahme": "übernehmen - Umsatzsicherung im Lizenzgeschäft." + }, + { + "id": "SyRS-090", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Rechteermittlung ausschließlich über Gruppenzugehörigkeit", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031, SwRS-090", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer ohne Gruppenzugehörigkeit darf keine Rechte besitzen.", + "qm": "", + "uebernahme": "übernehmen - klares Rollenmodell." + }, + { + "id": "SyRS-091", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Deklarative Rechteprüfung an REST-Endpunkten", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031, SyRS-173, SwRS-091", + "konsolidierung": "nein", + "pruefidee": "Ein Aufruf ohne Anmeldung muss 401, ein Aufruf ohne das geforderte Recht 403 liefern.", + "qm": "", + "uebernahme": "übernehmen - Standardmuster für die API-Absicherung." + }, + { + "id": "SyRS-092", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Filialbeschränkung als eigenständige Prüfstufe", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-032, StRS-034, SwRS-092", + "konsolidierung": "nein", + "pruefidee": "Benutzer ohne Filiale und Beleg ohne Filiale: die Anlage muss gelingen; Benutzer der Filiale A und Beleg der Filiale B: die Anlage muss scheitern.", + "qm": "", + "uebernahme": "übernehmen - Voraussetzung für Filialbetrieb." + }, + { + "id": "SyRS-093", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Hierarchische Nummernkreisauflösung über Mitarbeiter, Filiale und Mandant", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-034, StRS-035, SwRS-093", + "konsolidierung": "Kandidat: SwRS-093 — die alte und die neue Auflösung (`IsNumberGroupRefactoringAvailable`) bilden dieselbe Fachfunktion doppelt ab.", + "pruefidee": "Ein Mitarbeiter der Filiale B muss eine Rechnungsnummer aus dem Nummernkreis der Filiale B erhalten, sofern dieser gepflegt und `Current > 0` ist.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem mit nur einem Auflösungsweg." + }, + { + "id": "SyRS-094", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kollisionsfreie Nummernvergabe bei gleichzeitigem Zugriff", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-035, SwRS-094", + "konsolidierung": "nein", + "pruefidee": "Zwanzig gleichzeitige Anforderungen müssen zwanzig verschiedene Nummern liefern.", + "qm": "Zuverlässigkeit (Reife)", + "uebernahme": "übernehmen - im Zielsystem als Datenbanksequenz zu lösen." + }, + { + "id": "SyRS-095", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Prüfung auf bereits belegte Nummern in der Zieltabelle", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-035, SyRS-094, SwRS-095", + "konsolidierung": "nein", + "pruefidee": "Wird eine Belegnummer manuell in die Zieltabelle eingetragen, muss die nächste automatische Vergabe diese Nummer überspringen.", + "qm": "", + "uebernahme": "Workaround - die tabellenweise Prüfung gleicht fehlende Datenbankbeschränkungen aus; im Zielsystem ist die Eindeutigkeit über eine Datenbankbedingung sicherzustellen." + }, + { + "id": "SyRS-100", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Sitzungsticket mit anwendungsabhängiger Gültigkeitsdauer", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-033, SwRS-100", + "konsolidierung": "nein", + "pruefidee": "Ein Ticket der Standardanwendung muss 31 Minuten nach der letzten Verwendung abgelehnt werden.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als Token mit Ablauf." + }, + { + "id": "SyRS-101", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Verzögerte Verlängerung der Ticketgültigkeit", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-100, SwRS-100", + "konsolidierung": "nein", + "pruefidee": "Zwei Aufrufe im Abstand von einer Minute dürfen nur einen Schreibzugriff auf das Ablaufdatum erzeugen.", + "qm": "Performance-Effizienz (Ressourcennutzung)", + "uebernahme": "Workaround - eine Optimierung mit bewusst hingenommener Funktionsabweichung; im Zielsystem durch zustandslose Token zu ersetzen." + }, + { + "id": "SyRS-102", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Anwendungsbezogene Zugangsrechte bei der Anmeldung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-033, StRS-031, SwRS-101", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer mit dem ausschließenden Recht einer Anwendung darf sich dort nicht anmelden, an anderen Anwendungen aber schon.", + "qm": "", + "uebernahme": "übernehmen - feingranulare Zugangssteuerung." + }, + { + "id": "SyRS-103", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Lizenzprüfung mit Anzahl, Ablaufdatum und Versionsgrenze", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-036, SwRS-102", + "konsolidierung": "nein", + "pruefidee": "Ein Client mit einer Version oberhalb der Lizenzversionsgrenze muss abgewiesen werden.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als Tarifprüfung." + }, + { + "id": "SyRS-104", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Wiederverwendung bestehender Sitzungen vor der Lizenzprüfung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-037, SyRS-100, SwRS-103", + "konsolidierung": "nein", + "pruefidee": "Zweimaliges Anmelden desselben Benutzers auf demselben Gerät muss dieselbe Ticket-ID liefern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-105", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zwei-Faktor-Authentifizierung als zweite Prüfstufe", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-033, SwRS-104", + "konsolidierung": "nein", + "pruefidee": "Richtiges Kennwort und falscher zweiter Faktor müssen zur Meldung `TwoFactorAuthFailed` ohne Ticket führen.", + "qm": "", + "uebernahme": "übernehmen - Sicherheitsanforderung im SaaS-Betrieb." + }, + { + "id": "SyRS-106", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Protokollierung von Anmeldeversuchen", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-033, StRS-051, SwRS-105", + "konsolidierung": "nein", + "pruefidee": "Ein fehlgeschlagener Anmeldeversuch muss einen Warneintrag mit Benutzername und IP-Adresse erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Voraussetzung für Angriffserkennung." + }, + { + "id": "SyRS-107", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kennwortspeicherung der Anwendungsbenutzer", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-033, SwRS-106", + "konsolidierung": "Kandidat: SyRS-122 — Anwendungsbenutzer und Web-Benutzer verwenden dasselbe unzureichende Verfahren an zwei Stellen.", + "pruefidee": "Zwei Benutzer mit identischem Kennwort müssen im heutigen Stand denselben gespeicherten Hashwert tragen; im Zielsystem darf das nicht mehr der Fall sein.", + "qm": "", + "uebernahme": "veraltet - das Verfahren ist fachlich erforderlich, in dieser Ausprägung jedoch überholt und im Zielsystem zu ersetzen." + }, + { + "id": "SyRS-108", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Symmetrische Verschlüsselung mit fest hinterlegtem Ersatzschlüssel", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-047, StRS-059, SwRS-107", + "konsolidierung": "nein", + "pruefidee": "Zweimaliges Verschlüsseln desselben Textes mit demselben Schlüssel muss im heutigen Stand dasselbe Chiffrat ergeben; im Zielsystem darf das nicht der Fall sein.", + "qm": "", + "uebernahme": "veraltet - die Verschlüsselung ist fachlich erforderlich, das konkrete Verfahren im Zielsystem jedoch zu ersetzen." + }, + { + "id": "SyRS-109", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Erzeugung und Prüfung von API-Zugriffstoken", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031, StRS-036, SwRS-108", + "konsolidierung": "nein", + "pruefidee": "Ein deaktiviertes Token muss abgewiesen und der Versuch protokolliert werden.", + "qm": "", + "uebernahme": "übernehmen - das Verfahren entspricht dem Stand der Technik." + }, + { + "id": "SyRS-110", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Erzeugung, Vorschau und Ablage von Belegdokumenten", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-038, SwRS-110", + "konsolidierung": "nein", + "pruefidee": "Bei `addReportPdfToReceiptDocuments = true` muss nach dem Druck ein PDF in der Belegablage liegen.", + "qm": "", + "uebernahme": "übernehmen - Belegausgabe." + }, + { + "id": "SyRS-111", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Auflösung von Objektverzeichnissen über Referenzanbieter", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-039, SwRS-111", + "konsolidierung": "nein", + "pruefidee": "Dasselbe Ticket muss aus dem Rich-Client und aus der Weboberfläche dasselbe Dokumentenverzeichnis liefern.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als Objektspeicher." + }, + { + "id": "SyRS-112", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Unterdrückung des Versands an externe Empfänger außerhalb von Freigabeversionen", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-040, StRS-052, SwRS-112", + "konsolidierung": "nein", + "pruefidee": "In einer Debug-Übersetzung muss eine Mail an eine Kundenadresse an `test@nexoware.com` gehen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als umgebungsabhängige Konfiguration statt als Übersetzungsschalter." + }, + { + "id": "SyRS-113", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Belegartabhängige Absenderadresse", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-040, SwRS-112", + "konsolidierung": "nein", + "pruefidee": "Der Versand einer Gutschrift muss den Rechnungsabsender verwenden, der Versand eines Auftrags den Auftragsabsender.", + "qm": "", + "uebernahme": "übernehmen - Kommunikationsqualität." + }, + { + "id": "SyRS-114", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Nachverfolgung versandter E-Mails", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-040, SwRS-113", + "konsolidierung": "nein", + "pruefidee": "Bei aktivierter Nachverfolgung muss zu einer versandten Mail ein Nachverfolgungseintrag entstehen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem unter Beachtung der Einwilligungspflicht." + }, + { + "id": "SyRS-115", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Anrufprotokollierung mit Vorgangsbezug", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-043, SwRS-115", + "konsolidierung": "nein", + "pruefidee": "Ein eingehender Anruf muss einen Protokolleintrag mit `CallTracking`-Nummer erzeugen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als CTI-Schnittstelle." + }, + { + "id": "SyRS-120", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Eigenes Rechtesystem für Web-Benutzerkonten", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-044, StRS-017, SwRS-120", + "konsolidierung": "nein", + "pruefidee": "Ein Web-Konto ohne das Recht 31005 darf keine anderen Web-Konten desselben Kunden verwalten.", + "qm": "", + "uebernahme": "übernehmen - die fest verdrahtete Rechte-ID ist im Zielsystem durch eine benannte Konstante zu ersetzen." + }, + { + "id": "SyRS-121", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Sperre der Belegeinsicht für Web-Benutzer in der Fachlogik", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-044, SyRS-020, SwRS-121", + "konsolidierung": "nein", + "pruefidee": "Ein Web-Benutzer darf über keinen Aufruf der internen Belegeinsicht Belegdaten erhalten; die Portalansicht bleibt davon unberührt.", + "qm": "", + "uebernahme": "übernehmen - klare Trennung interner und externer Sichten." + }, + { + "id": "SyRS-122", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kennwortregeln und Kennwortversand für Web-Konten", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-044, SyRS-107, SwRS-122", + "konsolidierung": "Kandidat: SyRS-107 — Anwendungs- und Web-Konten verwenden dasselbe Hashverfahren an zwei getrennten Stellen.", + "pruefidee": "Ein Kennwort mit sieben Zeichen muss abgewiesen werden; die Versandmail darf im Zielsystem kein Kennwort mehr enthalten.", + "qm": "", + "uebernahme": "veraltet - Mindestlänge übernehmen, Klartextversand und Hashverfahren ersetzen." + }, + { + "id": "SyRS-123", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Belegfreigabe über Einmal-Token ohne Anmeldung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-045, SwRS-123", + "konsolidierung": "nein", + "pruefidee": "Ein manipulierter oder fremder Token darf keinen Belegzustand ändern.", + "qm": "", + "uebernahme": "übernehmen - Gültigkeitsdauer und Einmaligkeit des Tokens sind im Zielsystem ausdrücklich festzulegen." + }, + { + "id": "SyRS-124", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Erfassung und Speicherung der Unterschrift im Browser", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-045, StRS-038, SwRS-124", + "konsolidierung": "Kandidat: SwRS-042 — Unterschriften werden sowohl am Ticket-Zeiteintrag als auch am geteilten Dokument getrennt erfasst und gespeichert.", + "pruefidee": "Ein unterzeichnetes Dokument muss eine gültige digitale Signatur tragen.", + "qm": "", + "uebernahme": "übernehmen - Rechtssicherheit der Freigabe." + }, + { + "id": "SyRS-125", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Self-Care-Formulare als Ticketeingang", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-044, StRS-016, SyRS-058, SwRS-125", + "konsolidierung": "nein", + "pruefidee": "Ein ausgefülltes Formular muss ein Ticket mit den im Muster hinterlegten Kategorien erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Entlastung der Serviceannahme." + }, + { + "id": "SyRS-126", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mandantenspezifisches Erscheinungsbild der Weboberfläche", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-044, SwRS-126", + "konsolidierung": "nein", + "pruefidee": "Nach Änderung des Logos muss die Portalstartseite das neue Logo zeigen.", + "qm": "", + "uebernahme": "übernehmen - im SaaS-Betrieb Voraussetzung für Mehrmandantenfähigkeit." + }, + { + "id": "SyRS-127", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zugriff auf Kunden, Belege und Tickets aus Outlook", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-040, StRS-044, SwRS-127", + "konsolidierung": "nein", + "pruefidee": "Zu einer E-Mail eines bekannten Kunden muss das Add-In dessen Kundendaten anzeigen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als Web-Add-In." + }, + { + "id": "SyRS-128", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Benachrichtigungen in der Weboberfläche", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-054, SwRS-128", + "konsolidierung": "Kandidat: SwRS-128 — `Notifications` und `NexusNotifications` bilden Benachrichtigungen in zwei getrennten Mechanismen ab.", + "pruefidee": "Das Schließen eines Tickets muss beim zuständigen Bearbeiter eine Benachrichtigung erzeugen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-129", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Sprachumschaltung der Weboberfläche", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-044, SwRS-129", + "konsolidierung": "nein", + "pruefidee": "Nach Umschalten auf Englisch müssen die Menütexte englisch erscheinen.", + "qm": "Benutzbarkeit (Zugänglichkeit)", + "uebernahme": "übernehmen - Voraussetzung für internationale Kunden." + }, + { + "id": "SyRS-150", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Ermittlung löschbarer Kontaktdaten nach DSGVO", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-050, SwRS-150", + "konsolidierung": "nein", + "pruefidee": "Eine Person, die als Ansprechpartner und als Kontaktmanagement-Kontakt geführt wird, muss in beiden Arten entfernt werden.", + "qm": "", + "uebernahme": "übernehmen - gesetzlich zwingend." + }, + { + "id": "SyRS-151", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Nicht implementierte Löschpfade im Datenschutzmodul", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "HYPOTHESE", + "hypothese": true, + "workaround": false, + "tracelinks": "StRS-050, SyRS-150, SwRS-151", + "konsolidierung": "nein", + "pruefidee": "Der Versuch, einen Kunden über das Datenschutzmodul zu löschen, muss heute scheitern; im Zielsystem ist ein tragfähiges Anonymisierungsverfahren vorzusehen.", + "qm": "", + "uebernahme": "übernehmen - die Anforderung besteht fort und ist im Zielsystem umzusetzen." + }, + { + "id": "SyRS-152", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Bereinigung nicht mehr benötigter Datenbestände", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-050, SwRS-152", + "konsolidierung": "nein", + "pruefidee": "Eine Bereinigung ohne ausgewählte Art darf keine Datensätze verändern.", + "qm": "", + "uebernahme": "übernehmen - Grundsatz der Datenminimierung." + }, + { + "id": "SyRS-153", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Herkunftskennzeichnung jeder Belegänderung", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-051, SwRS-153", + "konsolidierung": "nein", + "pruefidee": "Ein aus dem Webservice gespeicherter Beleg muss eine andere `ChangedThroughApplication` tragen als ein aus dem Rich-Client gespeicherter.", + "qm": "", + "uebernahme": "übernehmen - erleichtert die Fehlersuche erheblich." + }, + { + "id": "SyRS-154", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Feldbezogene Änderungshistorie ausgewählter Belegangaben", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-051, SyRS-030, SwRS-154", + "konsolidierung": "Kandidat: SwRS-154 — `ReceiptLogBL`, `ChangeTracking/History` und die Versionstabellen protokollieren Änderungen in drei Mechanismen.", + "pruefidee": "Die Änderung des Kontingentwerts muss einen Protokolleintrag mit altem und neuem Wert erzeugen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem mit einem einheitlichen Mechanismus." + }, + { + "id": "SyRS-160", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Container-Laufzeitumgebung mit festgelegter Zeitzone und Zeichensatzunterstützung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-052, StRS-038, SwRS-160", + "konsolidierung": "nein", + "pruefidee": "Ein im Container erzeugtes PDF muss dieselben Schriftarten und dasselbe Datumsformat verwenden wie unter Windows.", + "qm": "Übertragbarkeit (Anpassbarkeit)", + "uebernahme": "übernehmen - die fest verdrahtete Zeitzone ist im Zielsystem konfigurierbar zu machen." + }, + { + "id": "SyRS-161", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Ausführung fehlender Datenbankskripte vor der Anmeldung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-053, SwRS-161", + "konsolidierung": "nein", + "pruefidee": "Ein Start gegen eine aktuelle Datenbank darf kein Skript ausführen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-162", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Ausnahmeliste für fehlertolerante Migrationsskripte", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-161, StRS-053, SwRS-162", + "konsolidierung": "nein", + "pruefidee": "Ein Fehler in Skript 10178 darf den Start nicht abbrechen, ein Fehler in einem anderen Skript schon.", + "qm": "Zuverlässigkeit (Fehlertoleranz)", + "uebernahme": "Workaround - eine fest verdrahtete Ausnahmeliste ist eine Behelfslösung für fehlerhafte Altskripte." + }, + { + "id": "SyRS-163", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Automatisierte Übersetzung, Signierung und Prüfung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-052, SwRS-163", + "konsolidierung": "nein", + "pruefidee": "Zwei aufeinanderfolgende Übernahmen nach `main` müssen zwei vollständige, nicht abgebrochene Läufe erzeugen.", + "qm": "Wartbarkeit (Testbarkeit)", + "uebernahme": "übernehmen - Voraussetzung für häufige Auslieferung." + }, + { + "id": "SyRS-164", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mehrstufige automatisierte Prüfung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-163, SwRS-164", + "konsolidierung": "nein", + "pruefidee": "Für jede der vier Ebenen muss mindestens ein Testprojekt im Bau ausgeführt werden.", + "qm": "Wartbarkeit (Testbarkeit)", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-165", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Anwendungsprotokollierung über eine gemeinsame Protokollkonfiguration", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-051, SyRS-106, SwRS-165", + "konsolidierung": "nein", + "pruefidee": "Eine fehlgeschlagene Anmeldung muss im LogViewer als Warnung erscheinen.", + "qm": "Wartbarkeit (Analysierbarkeit)", + "uebernahme": "übernehmen - im Zielsystem als strukturierte, zentrale Protokollsenke." + }, + { + "id": "SyRS-166", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Periodische Datenqualitätsprüfungen im Hintergrund", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-039, SwRS-166", + "konsolidierung": "nein", + "pruefidee": "Ein verwaistes Dokumentenverzeichnis muss im Prüfergebnis mit seiner Objektart erscheinen.", + "qm": "Zuverlässigkeit (Reife)", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-167", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Erfassung der Nutzung von API- und KI-Werkzeugen", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-056, SwRS-167", + "konsolidierung": "nein", + "pruefidee": "Zehn Aufrufe derselben API-Methode innerhalb eines Zeitfensters müssen einen Zähler mit Wert 10 ergeben, nicht zehn Einzeleinträge.", + "qm": "Wartbarkeit (Analysierbarkeit)", + "uebernahme": "übernehmen - die Erhebung ist im Zielsystem datenschutzrechtlich zu bewerten." + }, + { + "id": "SyRS-168", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Verbindungsart bestimmt die Verfügbarkeit von Modulen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-052, SwRS-168", + "konsolidierung": "nein", + "pruefidee": "Ein Modul ohne Webservice-Unterstützung muss bei Webservice-Verbindung die entsprechende Meldung liefern.", + "qm": "", + "uebernahme": "veraltet - im Zielsystem entfällt der direkte Datenbankzugriff des Clients, damit auch diese Fallunterscheidung." + }, + { + "id": "SyRS-170", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Getrennte Rechte je Auswertung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-054, StRS-031, SwRS-170", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer mit Recht auf die Umsatzstatistik, aber ohne Recht auf Management Info darf nur die Umsatzstatistik sehen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-171", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Bedarfsgesteuerte und vollständige Indexaktualisierung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-055, SwRS-171", + "konsolidierung": "nein", + "pruefidee": "Nach `RequestUpdateFor` für ein Ticket muss `UpdateRequestedIndexes` genau dieses Ticket neu indizieren.", + "qm": "Performance-Effizienz (Zeitverhalten)", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-172", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Anbindung von Sprachmodellen über austauschbare Klienten", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-056, SwRS-172", + "konsolidierung": "nein", + "pruefidee": "Nach Umstellen der konfigurierten Adresse muss der Modellkatalog des neuen Anbieters erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-173", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Versionierte REST-Schnittstelle", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-062, SyRS-091, SwRS-173", + "konsolidierung": "nein", + "pruefidee": "Ein Aufruf ohne Versionsangabe an einen versionierten Endpunkt muss abgewiesen werden.", + "qm": "", + "uebernahme": "übernehmen - Voraussetzung für stabile Fremdanbindungen." + }, + { + "id": "SyRS-174", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Beschränkung von Endpunkten auf die gehostete Betriebsform", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-091, StRS-052, SwRS-174", + "konsolidierung": "nein", + "pruefidee": "Ein so gekennzeichneter Endpunkt darf in einer nicht gehosteten Installation nicht erreichbar sein.", + "qm": "", + "uebernahme": "übernehmen - im SaaS-Zielsystem als Betreiberschnittstelle." + }, + { + "id": "SyRS-175", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Dauerhafte Verknüpfung interner Objekte mit Fremdschlüsseln", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-062, SyRS-023, SwRS-175", + "konsolidierung": "nein", + "pruefidee": "Ein zweimal importiertes Fremdsystemobjekt darf nur einen internen Datensatz erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Voraussetzung wiederholbarer Importe." + }, + { + "id": "SyRS-176", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Feldänderungen über viele Datensätze hinweg", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031, SwRS-176", + "konsolidierung": "nein", + "pruefidee": "Ohne das Recht `DataUpdater` darf das Modul „Data Updater\" nicht erscheinen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem mit Vorschau und Rücknahmemöglichkeit." + }, + { + "id": "SyRS-177", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Administrative SQL-Ausführung aus der Anwendung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-031, SwRS-177", + "konsolidierung": "nein", + "pruefidee": "Ohne das Recht darf der SQL-Manager nicht im Menü erscheinen.", + "qm": "", + "uebernahme": "veraltet - im SaaS-Zielsystem ist ein freier SQL-Zugang aus der Anwendung heraus nicht vorzusehen." + }, + { + "id": "SyRS-178", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Zeitgesteuerter Reportversand", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-038, StRS-054, SwRS-178", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer mit `REPORTSERVER`, aber ohne `REPORTEDIT` darf Zeitpläne einrichten, aber keine Formulare ändern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-179", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Überwachung erwarteter, wiederkehrender Ereignisse", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-062, SwRS-179", + "konsolidierung": "nein", + "pruefidee": "Ein erwartetes tägliches Ereignis, das ausbleibt, muss in der Auswertung als fehlend erscheinen.", + "qm": "", + "uebernahme": "übernehmen - Basis der proaktiven Überwachung." + }, + { + "id": "SyRS-180", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Produktionsauftrag mit Arbeitsschrittvorlagen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-060, SwRS-180", + "konsolidierung": "nein", + "pruefidee": "Ein aus einer Vorlage mit drei Schritten erzeugter Auftrag muss drei Arbeitsschritte tragen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-181", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Abwesenheits- und Urlaubsverwaltung als Planungsgrundlage", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-061, StRS-042, SwRS-181", + "konsolidierung": "nein", + "pruefidee": "Ein abwesender Mitarbeiter darf in der Einsatzplanung des Abwesenheitszeitraums nicht als verfügbar erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SyRS-182", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mitarbeiterartikel als Bindeglied zwischen Person und Leistung", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "KONTEXT", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-014, StRS-061, SwRS-182", + "konsolidierung": "nein", + "pruefidee": "Ein Zeiteintrag mit dem Mitarbeiterartikel eines Kollegen darf durch einen Benutzer mit `OWN_TIME_EDIT` nicht bearbeitbar sein.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem ist die indirekte Zuordnung über den Artikel zu prüfen und gegebenenfalls zu vereinfachen." + }, + { + "id": "SyRS-183", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Kundenaktivitäten als durchgängige Kontakthistorie", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-001, StRS-016, SwRS-183", + "konsolidierung": "nein", + "pruefidee": "Das Speichern einer neuen Rechnung muss eine Kundenaktivität erzeugen, das Speichern eines Belegs einer Belegart mit `CreatesAccountActivities() == false` nicht.", + "qm": "", + "uebernahme": "übernehmen - Kern des CRM-Nutzens." + }, + { + "id": "SyRS-130", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Verschlüsselte Ablage und protokollierter Zugriff auf Zugangsdaten", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-047, SwRS-130, SwRS-131", + "konsolidierung": "Kandidat: SyRS-131 — Passwort-Manager und Altmodul führen Zugangsdaten in getrennten Datenhaltungen.", + "pruefidee": "Ein Lesezugriff auf ein Kennwort muss einen Protokolleintrag mit Mitarbeiter und Zeitstempel erzeugen; der Datenbankwert darf den Klartext nicht enthalten.", + "qm": "", + "uebernahme": "übernehmen - für den Servicebetrieb erforderlich; im Zielsystem als eigener Geheimnisspeicher." + }, + { + "id": "SyRS-131", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Unvollständige Kennwortspeicherung im abgelösten Zugangsdatenmodul", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-048, SyRS-130, SwRS-132", + "konsolidierung": "Kandidat: SyRS-130", + "pruefidee": "Eine Neuanlage im Altmodul darf im Zielsystem nicht mehr angeboten werden; bestehende Einträge müssen im aktuellen Passwort-Manager erscheinen.", + "qm": "", + "uebernahme": "veraltet - das Modul ist im Code als obsolet gekennzeichnet und erfüllt seine Aufgabe nicht mehr." + }, + { + "id": "SyRS-140", + "ebene": "SyRS", + "datei_ebene": "SyRS", + "fremdabgelegt": false, + "titel": "Mehrfache Datenhaltung installierter Geräte", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-049, SwRS-140, SwRS-141, SwRS-142, SwRS-143", + "konsolidierung": "Kandidat: SwRS-140, SwRS-141, SwRS-142, SwRS-143 — Stammblatt, Account-Gerät, Asset-Management-Gerät und Kunden-Asset bilden denselben fachlichen Gegenstand in vier getrennten Datenhaltungen ab und sind im Zielsystem zu einem Asset-Konzept zusammenzuführen.", + "pruefidee": "Ein Gerät mit bekannter Seriennummer muss in Stammblattsuche, Gerätesuche am Account und Asset-Management denselben Gegenstand bezeichnen.", + "qm": "", + "uebernahme": "übernehmen - der fachliche Gegenstand bleibt erforderlich, die Mehrfachhaltung nicht." + }, + { + "id": "SwRS-001", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Schichtung von Oberfläche, Logik, Geschäftslogik und Persistenz", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-022, SyRS-168", + "konsolidierung": "nein", + "pruefidee": "Eine ViewModel-Klasse darf keine Referenz auf `Centron.DAO` besitzen.", + "qm": "Wartbarkeit (Modularität)", + "uebernahme": "übernehmen - klare Schichtung ist Voraussetzung der Neuimplementierung." + }, + { + "id": "SwRS-002", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Doppelte Datenzugriffsimplementierung je Modul", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-168, SyRS-002", + "konsolidierung": "Kandidat: SwRS-001 — die doppelte Implementierung verdoppelt jede Datenzugriffsfunktion.", + "pruefidee": "Für jede `ILogic`-Schnittstelle müssen genau zwei Implementierungen auffindbar sein.", + "qm": "Wartbarkeit (Modifizierbarkeit)", + "uebernahme": "veraltet - im Web-/SaaS-Zielsystem entfällt der direkte Datenbankzugriff des Clients, damit auch die zweite Implementierung." + }, + { + "id": "SwRS-003", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Einheitliches Ergebnisobjekt für Fachlogikaufrufe", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020, SyRS-091", + "konsolidierung": "nein", + "pruefidee": "Eine fehlgeschlagene Rechteprüfung muss `ResultStatus.Error` mit `DefaultMessageCodes.RightCheckFailed` liefern, nicht eine Ausnahme.", + "qm": "Zuverlässigkeit (Fehlertoleranz)", + "uebernahme": "übernehmen - erleichtert die Fehlerbehandlung über Schnittstellengrenzen hinweg." + }, + { + "id": "SwRS-004", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Trennung von Entitäten und Übertragungsobjekten", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-173", + "konsolidierung": "nein", + "pruefidee": "Ein REST-Endpunkt darf keine Klasse aus `Centron.Entities/Entities` unmittelbar zurückgeben.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-005", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zweistufiges Datenbankmodell aus Alt-Tabellen und Sichten", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-005, SyRS-010", + "konsolidierung": "nein", + "pruefidee": "Ein über die Sicht `Invoices` gelesener Beleg muss denselben Datensatz liefern wie ein direkter Zugriff auf `RechKopf`.", + "qm": "", + "uebernahme": "Workaround - die Doppelbenennung ist eine Migrationsbrücke; im Zielsystem ist ein einheitliches, fachlich benanntes Modell vorzusehen." + }, + { + "id": "SwRS-006", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Gemeinsame Basisklassen aller persistierten Objekte", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-002", + "konsolidierung": "nein", + "pruefidee": "`GetGenericDAO()` muss für jede Entität im Namensraum `Centron.Data.Entities` übersetzbar sein.", + "qm": "", + "uebernahme": "übernehmen - `I3D` ist im Zielsystem durch einen sprechenden Bezeichner zu ersetzen, das Prinzip bleibt." + }, + { + "id": "SwRS-007", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Benannte Abfragen für mengenwirksame Operationen", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-007, SyRS-054", + "konsolidierung": "nein", + "pruefidee": "Der Steuersatzwechsel über 10.000 Artikel darf keine 10.000 Einzelaktualisierungen erzeugen.", + "qm": "Performance-Effizienz (Zeitverhalten)", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-008", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Stapelverarbeitung großer Schlüsselmengen", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-007, SwRS-007", + "konsolidierung": "nein", + "pruefidee": "Ein Steuersatzwechsel über 5.000 Artikel muss drei Stapel erzeugen und fehlerfrei durchlaufen.", + "qm": "Zuverlässigkeit (Reife)", + "uebernahme": "übernehmen - die fest verdrahtete Stapelgröße ist im Zielsystem konfigurierbar zu machen." + }, + { + "id": "SwRS-009", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Transaktionsklammer über Geschäftsvorfälle", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, SyRS-011", + "konsolidierung": "nein", + "pruefidee": "Ein Fehler bei der Frachtpositionsermittlung darf keine bereits geschriebene Belegposition hinterlassen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-010", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zentrale Belegklasse mit generischen Typparametern", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, SyRS-022", + "konsolidierung": "nein", + "pruefidee": "Für jede der sieben Belegarten muss `SaveReceipt(IReceiptBase, …)` ohne Reflexionsfehler durchlaufen.", + "qm": "Wartbarkeit (Modularität)", + "uebernahme": "übernehmen - der Umfang der Klasse ist im Zielsystem jedoch aufzuteilen." + }, + { + "id": "SwRS-011", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Reihenfolge der Positionsaufbereitung beim Speichern", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-011", + "konsolidierung": "nein", + "pruefidee": "Zweimaliges Speichern ohne zwischenzeitliche Änderung darf keine zusätzlichen Positionen erzeugen.", + "qm": "", + "uebernahme": "übernehmen - die Reihenfolge ist im Zielsystem ausdrücklich zu dokumentieren." + }, + { + "id": "SwRS-012", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Nebenläufigkeitskennung als Belegfeld", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-012", + "konsolidierung": "nein", + "pruefidee": "Ein Aufruf mit veralteter Kennung muss abgewiesen werden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-013", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Belegartspezifische Sperrentitäten", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-013", + "konsolidierung": "nein", + "pruefidee": "Eine gesperrte Rechnung darf einen gleichnummerigen Auftrag nicht sperren.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-014", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Versionstabellen als strukturgleiche Kopien", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-014", + "konsolidierung": "nein", + "pruefidee": "Ein Vergleich der Spaltenlisten von `RechKopf` und `RechKopfVersions` darf keine Abweichung ergeben.", + "qm": "", + "uebernahme": "Workaround - die Tabellenverdopplung ist im Zielsystem durch ein Historienverfahren ohne Strukturduplikat zu ersetzen." + }, + { + "id": "SwRS-015", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Übernahmeoptionen beim Kopieren und Weiterführen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-015, SyRS-011", + "konsolidierung": "nein", + "pruefidee": "Mit `onlyTakeoverAvailableQuantity = true` darf nur die verfügbare Menge übernommen werden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-016", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Unterdrückung von Rückrufaktionen bei Vorlagen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-016, SyRS-183", + "konsolidierung": "nein", + "pruefidee": "Das Speichern einer Vorlage darf keine Kundenaktivität erzeugen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-017", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zahlungskonditionen als eigene Stammdatentabelle", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-017, SyRS-030", + "konsolidierung": "nein", + "pruefidee": "Ein Vertrag mit abweichendem Konditionstext muss diesen in der erzeugten Rechnung ausweisen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-018", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Getrennte Adressfelder je Adressrolle am Beleg", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-018, SyRS-003", + "konsolidierung": "nein", + "pruefidee": "Eine nachträgliche Änderung der Stammadresse darf die Adresse eines bereits gespeicherten Belegs nicht verändern.", + "qm": "", + "uebernahme": "übernehmen - die Kopie ist fachlich gewollt (Belegunveränderlichkeit)." + }, + { + "id": "SwRS-019", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Ticketerzeugung aus Belegdaten über eine Zwischenstruktur", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-019", + "konsolidierung": "nein", + "pruefidee": "Der Aufruf der Vorschlagsmethode allein darf kein Ticket erzeugen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-020", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zentrale Rechteprüfmethoden im Belegkern", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-020, SyRS-092", + "konsolidierung": "nein", + "pruefidee": "Jede öffentliche Änderungsmethode in `ReceiptBL` muss eine der vier Prüfmethoden aufrufen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als zentrale Berechtigungsprüfung." + }, + { + "id": "SwRS-021", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Rücksetzen unberechtigter Preisänderungen anhand der Vorgängerversion", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-021", + "konsolidierung": "nein", + "pruefidee": "Bei einem neuen Beleg ohne Vorgängerversion muss festgelegt sein, welcher Wert als Referenz dient; dies ist gesondert zu prüfen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem ist ein sichtbarer Hinweis auf die verworfene Änderung vorzusehen." + }, + { + "id": "SwRS-022", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Auflösung der Belegartlogik über die Objektart", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-022", + "konsolidierung": "nein", + "pruefidee": "Eine hinzugefügte Belegart mit eigener `IReceiptSpecificLogic` muss ohne Änderung an `ReceiptBL` funktionieren.", + "qm": "Wartbarkeit (Modularität)", + "uebernahme": "übernehmen - tragfähiges Erweiterungsmuster." + }, + { + "id": "SwRS-023", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Objektart als systemweite Aufzählung", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-023", + "konsolidierung": "nein", + "pruefidee": "Der Wert für „Rechnung\" muss in der Aufzählung und in `AnlageLog.AnlageArt` übereinstimmen (4).", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-024", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Belegkette und Fortschrittsanzeige", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, SyRS-015", + "konsolidierung": "nein", + "pruefidee": "Zu einer Rechnung, die aus Angebot, Auftrag und Lieferschein entstanden ist, müssen alle drei Vorgängerbelege erscheinen.", + "qm": "", + "uebernahme": "übernehmen - zentrale Auskunftsfunktion." + }, + { + "id": "SwRS-025", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Belegkorb und Freigabesystem", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-120, StRS-044", + "konsolidierung": "nein", + "pruefidee": "Eine Portalbestellung darf ohne Freigabe keinen Auftrag erzeugen.", + "qm": "", + "uebernahme": "übernehmen - im SaaS-Zielsystem zentral." + }, + { + "id": "SwRS-026", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Anzahlungen an Aufträgen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-010, StRS-003", + "konsolidierung": "nein", + "pruefidee": "Das Weiterführen eines Auftrags mit offener Anzahlung in einen Lieferschein muss eine Meldung erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Absicherung im Projektgeschäft." + }, + { + "id": "SwRS-027", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Warnung bei nicht umgewandelten Fremdartikeln", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-064, SyRS-011", + "konsolidierung": "nein", + "pruefidee": "Ein Auftrag mit einer Fremdartikelposition muss beim Weiterführen in eine Rechnung eine Warnung erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Datenqualität im Artikelstamm." + }, + { + "id": "SwRS-028", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Belegprojekt-Layout für mehrteilige Ausgaben", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-110, SyRS-015", + "konsolidierung": "nein", + "pruefidee": "Das Weiterführen nur eines Layout-Abschnitts darf nur dessen Positionen übernehmen.", + "qm": "", + "uebernahme": "übernehmen - Anforderung des Projektgeschäfts." + }, + { + "id": "SwRS-029", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Schweizspezifische Belegausprägungen", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-008, SyRS-110", + "konsolidierung": "nein", + "pruefidee": "Bei aktivierter Schweiz-Einstellung muss die Rechnungsausgabe die schweizspezifischen Felder enthalten.", + "qm": "", + "uebernahme": "Sonderfall - länderspezifische Ausprägung für einen Teil der Kundschaft; im Zielsystem als Länderpaket zu führen." + }, + { + "id": "SwRS-030", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kontingentfelder als eigenständige Vertragsattribute", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-030", + "konsolidierung": "nein", + "pruefidee": "Ein Vertrag mit überschrittenem Grenzwert muss dies unabhängig vom Restwert ausweisen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-031", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Getrennte Ausgleichsartikel für Vertrag und Pauschale", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-031, SyRS-064", + "konsolidierung": "Kandidat: SwRS-065 — beide Artikel erfüllen die gleiche Funktion „Saldoausgleich\" in getrennten Konfigurationen.", + "pruefidee": "Eine Pauschalabrechnung darf nicht den Vertragsausgleichsartikel verwenden.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als ein Ausgleichsartikel mit Abrechnungsartkennzeichen." + }, + { + "id": "SwRS-032", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Abrechnungslauf über benannte Abfragen je Vorgangsart", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-032, SwRS-007", + "konsolidierung": "nein", + "pruefidee": "Der Lauf über 1.000 Verträge darf keine 1.000 Einzelabfragen erzeugen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-033", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Import externer Vertragspositionen mit Zeitraumfilter", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-033", + "konsolidierung": "nein", + "pruefidee": "Eine Position mit Zeitstempel 23:59 des Endtags muss im Ergebnis enthalten sein.", + "qm": "", + "uebernahme": "übernehmen - die Randbehandlung ist im Zielsystem beizubehalten." + }, + { + "id": "SwRS-034", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Rechteausdrücke der Modulregistrierung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-034, SyRS-170", + "konsolidierung": "nein", + "pruefidee": "`GetRightsForModule` muss für das Rechnungsmodul die Rechte-IDs des Rechnungszweigs liefern.", + "qm": "", + "uebernahme": "übernehmen - erlaubt die Ableitung einer Rechtematrix aus dem Code." + }, + { + "id": "SwRS-035", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Filterstruktur der Ticketabrechnung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-035", + "konsolidierung": "nein", + "pruefidee": "Ein Filter auf zwei Kunden muss Zeiten beider Kunden liefern, Zeiten eines dritten Kunden nicht.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-036", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Berechnung der Zuschlagsüberschneidungen", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-036", + "konsolidierung": "nein", + "pruefidee": "Ein Einsatz von 20:00 bis 02:00 Uhr muss mindestens zwei Teilabschnitte liefern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-040", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zeiterfassung als eigenständiges, durch eine Kennung identifiziertes Objekt", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-040", + "konsolidierung": "nein", + "pruefidee": "Zwei gleichzeitig laufende Erfassungen desselben Mitarbeiters müssen unabhängig voneinander pausierbar sein.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-041", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Hinweise auf laufende Erfassungen als eigene Datensätze", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-041", + "konsolidierung": "nein", + "pruefidee": "Ein bearbeiteter Hinweis darf beim nächsten Abruf nicht mehr erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-042", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Unterschrift als eigenständige Entität je Zeiteintrag", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-042, StRS-015", + "konsolidierung": "Kandidat: SwRS-124 — Unterschriften am Zeiteintrag und am geteilten Dokument werden in getrennten Datenhaltungen geführt.", + "pruefidee": "Ein zweiter `AddSignature`-Aufruf für denselben Zeiteintrag darf keine zweite Entität erzeugen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-043", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Protokoll der Zeiteintragsänderungen", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-042, StRS-051", + "konsolidierung": "nein", + "pruefidee": "Nach der Unterschriftserfassung muss ein Protokolleintrag mit Benutzer und Zeitpunkt vorliegen.", + "qm": "", + "uebernahme": "übernehmen - Abrechnungsrelevanz." + }, + { + "id": "SwRS-050", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Pflichtfeldprüfung als eigene, überspringbare Stufe", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-050", + "konsolidierung": "nein", + "pruefidee": "Ein Ticket ohne Kunde und ohne Kategorie muss beide Mängel in einer Meldung nennen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-051", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Rechteprüfung im Vorspeicherschritt der Ticketentität", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-051", + "konsolidierung": "nein", + "pruefidee": "Ein Ticketspeichern über die REST-Schnittstelle ohne `EDIT_HELPDESK` muss ebenso scheitern wie im Rich-Client.", + "qm": "", + "uebernahme": "übernehmen - verhindert Lücken bei neuen Aufrufwegen." + }, + { + "id": "SwRS-052", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Feldlängen als Konstanten im Vorspeicherschritt", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-052", + "konsolidierung": "nein", + "pruefidee": "Die in `HelpdeskMaps.cs` hinterlegten Längen müssen mit den Literalen in `CheckTextFieldLengths` übereinstimmen.", + "qm": "", + "uebernahme": "Workaround - dreifach gepflegte Längenangaben; im Zielsystem aus einer Quelle abzuleiten." + }, + { + "id": "SwRS-053", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Variablenersetzung über eine gemeinsame Komponente", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-053, SyRS-113", + "konsolidierung": "Kandidat: SwRS-053 selbst — `ReplacementBL`, `Mail/VariableReplacement` und die direkte Zeichenkettenersetzung in `WebAccountBL` lösen dieselbe Aufgabe dreifach.", + "pruefidee": "Ein unbekannter Platzhalter muss in allen drei Verwendungen gleich behandelt werden.", + "qm": "Wartbarkeit (Wiederverwendbarkeit)", + "uebernahme": "übernehmen - im Zielsystem mit genau einer Ersetzungskomponente." + }, + { + "id": "SwRS-054", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Abschlussstatus des Tickets aus den Einstellungen", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-054, SyRS-051", + "konsolidierung": "nein", + "pruefidee": "Ein wiedereröffnetes Ticket darf keinen Abschlusszeitpunkt mehr tragen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-055", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Sammelabschluss von Tickets aus der Wartung", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "HYPOTHESE", + "hypothese": true, + "workaround": false, + "tracelinks": "SyRS-054, StRS-051", + "konsolidierung": "Kandidat: SwRS-054 — Einzel- und Sammelabschluss bilden denselben Vorgang mit unterschiedlichem Umfang ab.", + "pruefidee": "Nach dem Sammelabschluss ist zu prüfen, ob für die betroffenen Tickets ein Historieneintrag vom Typ `Close` erwartet wird.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem mit einheitlichen Folgeaktionen." + }, + { + "id": "SwRS-056", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Umfragezuordnung über Kontaktsuche per E-Mail-Adresse", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-056, SyRS-002", + "konsolidierung": "nein", + "pruefidee": "Eine Abschlussmail an eine unbekannte Adresse darf keine Umfrage enthalten.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-057", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Bausteine der Ticketverwaltung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-057, SyRS-051", + "konsolidierung": "nein", + "pruefidee": "Eine Änderung an der Ticketweiterleitung darf keine Änderung an `HelpdeskBL` erfordern.", + "qm": "Wartbarkeit (Modularität)", + "uebernahme": "übernehmen - vorbildliche Aufteilung, im Gegensatz zum Belegkern." + }, + { + "id": "SwRS-058", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Ticketmuster mit acht Konfigurationsdimensionen", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-058, SyRS-125", + "konsolidierung": "nein", + "pruefidee": "Ein Ticket aus einem Muster mit hinterlegter Checkliste muss diese Checkliste tragen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-059", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Filter-, Formatierungs- und Verdichtungseditor der Ticketliste", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-059, SyRS-052", + "konsolidierung": "nein", + "pruefidee": "Eine gespeicherte Ansicht mit Filter auf „eigene offene Tickets\" muss nach erneutem Anmelden unverändert erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-060", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Barcode-Zustand als Aufzählung mit Historie", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-060", + "konsolidierung": "nein", + "pruefidee": "Nach drei Zustandswechseln müssen drei Historieneinträge vorliegen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-061", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Prüfkomponente für Barcodes im Beleg", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-061", + "konsolidierung": "nein", + "pruefidee": "Die Prüfung darf nur bei vorhandener Vorgängerversion durchlaufen werden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-062", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Inventurdatenmodell mit Zählgruppen", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-062", + "konsolidierung": "nein", + "pruefidee": "Eine Position, die in eine andere Zählgruppe verschoben wurde, muss dort und nicht mehr in der alten Gruppe erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-063", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zwei Inventurimplementierungen nebeneinander", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-062", + "konsolidierung": "Kandidat: SwRS-062 — `InventoryBL` und `InventoryNewBL` bilden dieselbe Fachfunktion ab.", + "pruefidee": "Es ist festzustellen, welche der beiden Klassen von der Oberfläche aufgerufen wird; die andere ist zu entfernen.", + "qm": "Wartbarkeit (Modifizierbarkeit)", + "uebernahme": "veraltet - die Altimplementierung ist durch die Neufassung abgelöst." + }, + { + "id": "SwRS-064", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Rückschreiben der Kommissioniermenge je Position", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-063, SyRS-012", + "konsolidierung": "nein", + "pruefidee": "Ein Rückschreiben mit veralteter Kennung darf keine der übergebenen Mengen übernehmen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-065", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Systemartikel als konfigurierte Einzelverweise", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-064", + "konsolidierung": "Kandidat: SwRS-031", + "pruefidee": "Kein Aufrufer darf einen Systemartikel über eine feste Artikelnummer auflösen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-066", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Produktfamilien mit Kunden- und Positionssperren", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-065", + "konsolidierung": "nein", + "pruefidee": "Ein für einen Kunden gesperrter Familienartikel darf in dessen Beleg nicht erfassbar sein.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-067", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Artikelbezogene Zusatzangaben als eigene Komponenten", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-066, SyRS-065", + "konsolidierung": "nein", + "pruefidee": "Eine Änderung an den Umweltangaben darf keine Änderung an `ArticleBL` erfordern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-068", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Getrennte Versanddienstleisterbibliotheken mit eigenen Fehlerkatalogen", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-067", + "konsolidierung": "Kandidat: SwRS-068 selbst — die beiden Bibliotheken bilden dieselbe Fachfunktion mit eigenen Adress- und Ergebnisklassen ab.", + "pruefidee": "Der Belegcode darf keine dienstleisterspezifische Klasse unmittelbar verwenden.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem hinter einer gemeinsamen Versandabstraktion." + }, + { + "id": "SwRS-069", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Paketvorlagen je Beleg", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-067, SwRS-068", + "konsolidierung": "Kandidat: SwRS-068 — die Vorlagen sind dienstleisterspezifisch benannt, obwohl sie fachlich dienstleisterunabhängig sind.", + "pruefidee": "Ein Versandauftrag mit ausgewählter Vorlage muss deren Maße übernehmen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem dienstleisterneutral zu benennen." + }, + { + "id": "SwRS-070", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Lieferantenbelegarten als eigene Codezweige", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-070, SyRS-022", + "konsolidierung": "nein", + "pruefidee": "Eine Änderung an den Lieferantenrechnungseinstellungen darf die Kundenrechnung nicht beeinflussen.", + "qm": "Wartbarkeit (Modularität)", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-071", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "EDI-Verteiler als zentrale Vermittlungsstelle", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-071, SyRS-072", + "konsolidierung": "nein", + "pruefidee": "Der Aufruf einer EDI-Bestellung darf keine distributorspezifische Klasse unmittelbar verwenden.", + "qm": "Wartbarkeit (Modularität)", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-072", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Gemeinsame Schnittstellen der EDI-Belegdaten", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-072, SyRS-071", + "konsolidierung": "nein", + "pruefidee": "Ein Alltron- und ein ZUGFeRD-Import müssen dieselben Schnittstellentypen liefern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-073", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Einheitliche Struktur der Katalogbibliotheken", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-073", + "konsolidierung": "Kandidat: SwRS-073 selbst — vier gleich aufgebaute Bibliotheken ohne gemeinsame Abstraktion.", + "pruefidee": "Jede Katalogbibliothek muss eine Zugriffsklasse und einen eigenen Ausnahmetyp besitzen.", + "qm": "Wartbarkeit (Wiederverwendbarkeit)", + "uebernahme": "übernehmen - im Zielsystem mit gemeinsamer Katalogschnittstelle." + }, + { + "id": "SwRS-074", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kontingentangabe als Antwortbestandteil des Katalogs", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-074", + "konsolidierung": "nein", + "pruefidee": "Nach einem Abruf muss das verbleibende Kontingent auslesbar sein.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-075", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Bestellvorschlagsliste als eigener Codezweig", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-075", + "konsolidierung": "nein", + "pruefidee": "Eine Änderung der Vorschlagsregel darf die Bestellerfassung nicht berühren.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-076", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Filialaufteilung als eigener Bestellbaustein", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-076", + "konsolidierung": "nein", + "pruefidee": "Die Bedienoberfläche muss im Menü unter „Einkauf\" erreichbar sein.", + "qm": "", + "uebernahme": "übernehmen - die abweichende Einordnung der Oberfläche ist im Zielsystem zu bereinigen." + }, + { + "id": "SwRS-080", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Dreistufige Erlöskontotabellen", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-080, SyRS-009", + "konsolidierung": "nein", + "pruefidee": "Für einen Artikel ohne eigene Zuordnung muss das Konto der Untergruppe greifen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-081", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Herkunftsangabe als Pflichtparameter der Zahlungsbuchung", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-081", + "konsolidierung": "nein", + "pruefidee": "Kein Aufrufer darf eine leere Herkunftsangabe übergeben.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-082", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Mahnstufenfelder je Stufe mit Datum und Bearbeiter", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-082, SyRS-083", + "konsolidierung": "nein", + "pruefidee": "Nach drei Mahnläufen müssen alle drei Datums- und Bearbeiterfelder gefüllt sein.", + "qm": "", + "uebernahme": "übernehmen - die feste Begrenzung auf drei Stufen ist im Zielsystem zu prüfen." + }, + { + "id": "SwRS-083", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Sperrgrenze aus dem Kundenstamm", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-084, StRS-030", + "konsolidierung": "nein", + "pruefidee": "Ein Kunde mit `OrderLockAfterDunning = 0` darf trotz Mahnstufe 3 Aufträge erhalten.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-084", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Mandat als Belegfeld mit eigener Übernahmeregel", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-085", + "konsolidierung": "nein", + "pruefidee": "Eine aus einem Vertrag ohne Mandat erzeugte Rechnung darf kein Mandat tragen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-085", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Bankzugangsdaten der finAPI-Anbindung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "HYPOTHESE", + "hypothese": true, + "workaround": false, + "tracelinks": "SyRS-086", + "konsolidierung": "nein", + "pruefidee": "In der Datenbank darf kein Feld mit Bankzugangsdaten des Kunden auffindbar sein; dies ist gegen das vollständige Schema zu prüfen.", + "qm": "", + "uebernahme": "übernehmen - der Verzicht auf eigene Zugangsdatenhaltung entspricht dem Stand der Technik." + }, + { + "id": "SwRS-086", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zahlungseingangsprotokoll als eigenständige Entität", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-087, SwRS-004", + "konsolidierung": "nein", + "pruefidee": "Die Übersicht im Rich-Client und über die REST-Schnittstelle muss dieselben Einträge liefern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-087", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zahlungsverkehr als eigener Datenaustauschzweig", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-088, SyRS-071", + "konsolidierung": "nein", + "pruefidee": "Ein neues Austauschformat muss in `DataExchange` ergänzt werden können, ohne andere Bereiche zu berühren.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-088", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Lizenzbestandsvergleich gegen MSP-Daten", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-089, SyRS-033", + "konsolidierung": "nein", + "pruefidee": "Eine im MSP-System gemeldete, im Vertrag fehlende Lizenz muss als Nachberechnungsposition erscheinen.", + "qm": "", + "uebernahme": "übernehmen - Umsatzsicherung im Managed-Service-Geschäft." + }, + { + "id": "SwRS-090", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zwei Wege der Rechteermittlung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-090", + "konsolidierung": "Kandidat: SwRS-090 selbst — drei Prüfwege (`GetRightsFromCurrentUser`, `CheckRightsFromUser`, `HasUserRight`) für dieselbe Aufgabe.", + "pruefidee": "Eine Einzelprüfung darf nicht die vollständige Rechteliste des Benutzers laden.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem mit genau einem Prüfweg." + }, + { + "id": "SwRS-091", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Drei Autorisierungsattribute mit gemeinsamer Filterbasis", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-091", + "konsolidierung": "nein", + "pruefidee": "Ein Endpunkt mit Controller- und Methodenattribut muss beide Rechte verlangen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-092", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Filialvergleich als gemeinsame Hilfsfunktion", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-092", + "konsolidierung": "Kandidat: SwRS-092 selbst — derselbe Vergleich ist zweifach implementiert.", + "pruefidee": "Beide Prüfmethoden müssen für dieselbe Kombination aus Benutzer- und Belegfiliale dasselbe Ergebnis liefern.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem mit einer Vergleichsfunktion." + }, + { + "id": "SwRS-093", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zwei Wege der Nummernkreisauflösung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-093", + "konsolidierung": "Kandidat: SwRS-093 selbst", + "pruefidee": "Beide Wege müssen für dieselbe Ausgangslage denselben Nummernkreis liefern.", + "qm": "", + "uebernahme": "veraltet - die Altimplementierung ist durch die SQL-basierte Auflösung abgelöst." + }, + { + "id": "SwRS-094", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Optimistische Sperre der Nummernvergabe", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-094", + "konsolidierung": "nein", + "pruefidee": "Bei künstlich erzeugter Kollision muss die Schleife einen zweiten Versuch unternehmen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem durch eine Datenbanksequenz zu ersetzen." + }, + { + "id": "SwRS-095", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zusammengesetzte SQL-Anweisungen der Nummernprüfung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-095, SyRS-094", + "konsolidierung": "nein", + "pruefidee": "Alle Abfragen in `NumberGroupBL` müssen sich auf gebundene Parameter umstellen lassen, ohne die Funktion zu ändern.", + "qm": "", + "uebernahme": "veraltet - die Zeichenkettenzusammensetzung ist im Zielsystem durch Parameterbindung zu ersetzen; die Werte stammen hier zwar aus einer Aufzählung und einem Ganzzahlwert, das Muster ist dennoch nicht beizubehalten." + }, + { + "id": "SwRS-100", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Ticketerzeugung mit gerätebezogenem Zusatzwert", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-100, SyRS-104", + "konsolidierung": "nein", + "pruefidee": "Derselbe Benutzer auf zwei Geräten muss zwei verschiedene Tickets erhalten.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-101", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Anwendungsart als Konfigurationsobjekt der Anmeldung", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-102, SyRS-103", + "konsolidierung": "nein", + "pruefidee": "Eine neue Anwendung darf nur einen Eintrag in `ApplicationKind` erfordern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-102", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Lizenzkennungen als zentrale Konstantenliste", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-103", + "konsolidierung": "nein", + "pruefidee": "Ein Kunde mit der Sammellizenz `Centron` muss alle Module sehen, die diese Alternative führen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als Tarif- und Funktionsmatrix." + }, + { + "id": "SwRS-103", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Sperre um Ticketprüfung und Lizenzvergabe", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-104, StRS-037", + "konsolidierung": "nein", + "pruefidee": "Bei Lizenzanzahl 1 und zwei gleichzeitigen Anmeldungen verschiedener Benutzer darf nur eine gelingen.", + "qm": "Zuverlässigkeit (Reife)", + "uebernahme": "Workaround - eine prozesslokale Sperre schützt nicht bei mehreren Dienstinstanzen; im Zielsystem ist die Begrenzung datenbankseitig oder über einen gemeinsamen Dienst zu lösen." + }, + { + "id": "SwRS-104", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Austauschbare Zweitfaktor-Prüfer", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-105", + "konsolidierung": "Kandidat: SwRS-104 selbst — `Logins/TwoFactor` und `TwoFactorAuthenticator` behandeln beide die Zweifaktor-Authentifizierung.", + "pruefidee": "Ein hinzugefügter Prüfer muss ohne Änderung an `BasicAuthenticator` wirksam werden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-105", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Anmeldekontext als eigenes Objekt", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-106", + "konsolidierung": "nein", + "pruefidee": "Alle Protokolleinträge einer Anmeldung müssen dieselbe Vorgangskennung tragen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-106", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kennwortprüfung als Datenbankvergleich des Hashwerts", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-107, SyRS-106", + "konsolidierung": "nein", + "pruefidee": "Falscher Benutzername und falsches Kennwort müssen dieselbe Meldung und denselben Meldungscode liefern.", + "qm": "", + "uebernahme": "übernehmen - der Umgang mit der Fehlermeldung ist korrekt, das Hashverfahren jedoch zu ersetzen (siehe SyRS-107)." + }, + { + "id": "SwRS-107", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Verschlüsselungskomponente mit optionalem Schlüsselparameter", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-108, StRS-047", + "konsolidierung": "nein", + "pruefidee": "Kein produktiver Aufruf darf `EncryptText` ohne Schlüsselparameter verwenden.", + "qm": "", + "uebernahme": "veraltet - der Rückfall auf den fest hinterlegten Schlüssel ist zu entfernen." + }, + { + "id": "SwRS-108", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Protokollierung aller Tokenvorgänge", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-109, StRS-051", + "konsolidierung": "nein", + "pruefidee": "Drei fehlgeschlagene Tokenprüfungen müssen drei Protokolleinträge mit IP-Adresse erzeugen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-109", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Trennung persönlicher und administrativer Tokenverwaltung", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-109, SyRS-034", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer mit `CREATE_PERSONAL`, aber ohne `VIEW_ALL` darf die administrative Tokenliste nicht sehen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-110", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Formularausgabe mit konfigurierbarem Erzeugungsumfang", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-110", + "konsolidierung": "nein", + "pruefidee": "Vorschau und Druck desselben Belegs müssen inhaltlich identische PDF-Dokumente liefern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-111", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Verzeichnisreferenzanbieter je Objektart", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-111", + "konsolidierung": "nein", + "pruefidee": "Ein zusätzlicher Anbieter muss ohne Änderung an `GetDirectoryByReferenzBL` wirksam werden.", + "qm": "Wartbarkeit (Modifizierbarkeit)", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-112", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Mailkomponenten nach Aufgabe getrennt", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-112, SyRS-113", + "konsolidierung": "nein", + "pruefidee": "Eine Änderung an der Sperrliste darf keine Änderung an den Vorlagen erfordern.", + "qm": "Wartbarkeit (Modularität)", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-113", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Profile, Arbeitsabläufe und Aufgaben des Mail-Scanners", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-113, StRS-041", + "konsolidierung": "nein", + "pruefidee": "Eine Änderung des Arbeitsablaufs darf die Postfachzugangsdaten des Profils nicht berühren.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-114", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kalenderfunktionen als getrennte Einstellungsbereiche", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-114, StRS-042", + "konsolidierung": "nein", + "pruefidee": "Das Abschalten der Synchronisation darf die Ticket-Termine nicht beeinflussen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-115", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Telefoneinstellungen auf persönlicher und globaler Ebene", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-115", + "konsolidierung": "nein", + "pruefidee": "Eine gesetzte persönliche Nebenstelle muss die globale Vorgabe überschreiben.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-120", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Web-Rechte als eigene Entitäten mit Kategorien", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-120", + "konsolidierung": "Kandidat: SwRS-090 — internes und webseitiges Rechtesystem lösen dieselbe Aufgabe in getrennten Datenhaltungen.", + "pruefidee": "Ein neu angelegtes Web-Recht muss in seiner Kategorie erscheinen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem ist ein gemeinsames Rechtemodell mit Rollenzuschnitt zu prüfen." + }, + { + "id": "SwRS-121", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kennzeichen der Web-Anmeldung im Anmeldekontext", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-121, SyRS-120", + "konsolidierung": "nein", + "pruefidee": "Eine Web-Anmeldung muss `IsWebAccountLogin` liefern, eine interne nicht.", + "qm": "", + "uebernahme": "übernehmen - der technische Sammelbenutzer ist im Zielsystem durch eine eigene Dienstidentität zu ersetzen." + }, + { + "id": "SwRS-122", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Reparaturfunktion für fehlende Kontaktverknüpfungen", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-122, SyRS-166", + "konsolidierung": "nein", + "pruefidee": "Nach dem Lauf darf kein Web-Konto ohne Kontaktperson verbleiben.", + "qm": "", + "uebernahme": "Workaround - die Reparaturfunktion behebt eine Datenlücke, deren Ursache im Zielsystem durch eine Pflichtbeziehung zu vermeiden ist." + }, + { + "id": "SwRS-123", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Belegzustand des Webbelegs als eigene Aufzählung", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-123", + "konsolidierung": "nein", + "pruefidee": "Eine Kundenablehnung muss den Webbelegzustand ändern, ohne den internen Belegzustand zu setzen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-124", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Geteiltes Dokument als eigene Entität", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-124, SyRS-123", + "konsolidierung": "Kandidat: SwRS-042 — Unterschriftserfassung besteht am Zeiteintrag und am geteilten Dokument getrennt.", + "pruefidee": "Ein geteiltes Dokument ohne Belegbezug muss unterzeichenbar sein.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-125", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Formularfelder als Bestandteil des Ticketmusters", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-125, SyRS-058", + "konsolidierung": "nein", + "pruefidee": "Ein zusätzliches Formularfeld muss ohne Änderung am Portalcode erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-126", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Konfigurationsklassen der Webanwendung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-126, SyRS-160", + "konsolidierung": "nein", + "pruefidee": "Eine neue Konfigurationsoption muss genau einer Konfigurationsklasse zuzuordnen sein.", + "qm": "Wartbarkeit (Modifizierbarkeit)", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-127", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Outlook-Add-In als eigenständige Webanwendungserweiterung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-127", + "konsolidierung": "nein", + "pruefidee": "Das Add-In muss ohne Übersetzung der Hauptanwendung austauschbar sein.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-128", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zwei Benachrichtigungsmechanismen nebeneinander", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-128", + "konsolidierung": "Kandidat: SwRS-128 selbst — `Notifications` und `NexusNotifications` bilden denselben fachlichen Gegenstand in zwei Mechanismen ab.", + "pruefidee": "Eine im Rich-Client konfigurierte Benachrichtigung muss auch in der Weboberfläche erscheinen.", + "qm": "Wartbarkeit (Modifizierbarkeit)", + "uebernahme": "übernehmen - im Zielsystem als ein Benachrichtigungsdienst." + }, + { + "id": "SwRS-129", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Sprachressourcen als Ressourcendateipaare", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-129", + "konsolidierung": "nein", + "pruefidee": "Jeder Schlüssel in `SharedResource.resx` muss auch in `SharedResource.en-US.resx` vorhanden sein.", + "qm": "Benutzbarkeit (Zugänglichkeit)", + "uebernahme": "übernehmen - im Quelltext finden sich jedoch weiterhin deutsche Zeichenketten (etwa Fehlermeldungen in `ReceiptBL` und `HelpdeskBL`), die im Zielsystem zu externalisieren sind." + }, + { + "id": "SwRS-130", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zugangsdaten als verschlüsselte Zusatzfelder", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-108, StRS-047, StRS-059", + "konsolidierung": "nein", + "pruefidee": "Eine Suche nach dem Klartextkennwort in der Datenbank darf keinen Treffer liefern.", + "qm": "", + "uebernahme": "übernehmen - die Ablage über Zusatzfelder ist im Zielsystem durch einen eigenen Geheimnisspeicher zu ersetzen." + }, + { + "id": "SwRS-131", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Masterschlüssel aus der Konfigurationsdatenbank", + "typ": "Sicherheit", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-108, StRS-047", + "konsolidierung": "nein", + "pruefidee": "Ein Wechsel des Masterschlüssels muss die Entschlüsselung bestehender Daten nachvollziehbar regeln; dieser Fall ist gesondert zu prüfen.", + "qm": "", + "uebernahme": "übernehmen - der Klartextexport ist im Zielsystem an ein eigenes Recht und eine Protokollierung zu binden." + }, + { + "id": "SwRS-132", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Migration der Altzugangsdaten in den Passwort-Manager", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-131, StRS-048", + "konsolidierung": "Kandidat: SwRS-130 — Alt-Hotlinebereich und Passwort-Manager halten dieselben Zugangsdaten.", + "pruefidee": "Nach der Migration darf im Alt-Hotlinebereich kein Klartextkennwort mehr verbleiben.", + "qm": "", + "uebernahme": "übernehmen - die Migration ist vor Ablösung des Altmoduls abzuschließen." + }, + { + "id": "SwRS-140", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Stammblatt als Geräteakte mit Beleg- und Vertragsbezug", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-140, StRS-049, StRS-010", + "konsolidierung": "Kandidat: SwRS-141, SwRS-142 — Stammblatt, Account-Gerät und Asset-Management-Gerät bilden denselben fachlichen Gegenstand ab.", + "pruefidee": "Ein aus einer Rechnung erzeugtes Stammblatt muss deren Rechnungsnummer und -datum tragen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als eine Asset-Entität." + }, + { + "id": "SwRS-141", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Account-Gerät mit Ticket- und Protokollbezug", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-140, StRS-049", + "konsolidierung": "Kandidat: SwRS-140, SwRS-142", + "pruefidee": "Ein Ticket zu einem Gerät muss in dessen Ticketreiter erscheinen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als eine Asset-Entität." + }, + { + "id": "SwRS-142", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Asset-Management-Gerät mit Überwachungsdaten", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-140, StRS-049, StRS-062", + "konsolidierung": "Kandidat: SwRS-140, SwRS-141", + "pruefidee": "Ein fehlgeschlagener SNMP-Check muss ein Prüfergebnis mit Zeitstempel erzeugen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem als Überwachungsdaten am gemeinsamen Asset." + }, + { + "id": "SwRS-143", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kundenspezifische Assets mit Betreuerrollen", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-140, SyRS-003", + "konsolidierung": "Kandidat: SwRS-140, SwRS-141, SwRS-142", + "pruefidee": "Ein Asset ohne eigene Adresse muss die Standardadresse des Kunden anzeigen.", + "qm": "", + "uebernahme": "übernehmen - die vier festen Betreuerrollen sind im Zielsystem durch eine erweiterbare Rollenzuordnung zu ersetzen." + }, + { + "id": "SwRS-150", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Löschprotokoll des Datenschutzmoduls", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-150, StRS-050", + "konsolidierung": "nein", + "pruefidee": "Die Löschung von drei Kontakten muss drei Protokollzeilen liefern.", + "qm": "", + "uebernahme": "übernehmen - das Protokoll ist im Zielsystem dauerhaft zu speichern, nicht nur zurückzugeben." + }, + { + "id": "SwRS-151", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kennzeichnung gelöschter Kontakte statt physischer Löschung", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-151, SyRS-150", + "konsolidierung": "nein", + "pruefidee": "Ein anonymisierter Kontakt muss in Altbelegen weiterhin referenzierbar sein, jedoch keine personenbezogenen Daten mehr tragen.", + "qm": "", + "uebernahme": "übernehmen - das Verfahren ist fachlich richtig, aber derzeit für Kunden, Lieferanten und Accounts nicht aktiv." + }, + { + "id": "SwRS-152", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Bereinigungsarten als Aufzählung", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-152", + "konsolidierung": "nein", + "pruefidee": "Jede Bereinigungsart muss eine eigene Kennzahl liefern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-153", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Audit-Felder als Bestandteil der Belegbasis", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-153, StRS-051", + "konsolidierung": "nein", + "pruefidee": "Bei einem neu angelegten Beleg müssen Erzeugungs- und Änderungszeitpunkt identisch sein.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-154", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Drei Protokollmechanismen für Belegänderungen", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-154, SyRS-153", + "konsolidierung": "Kandidat: SwRS-154 selbst — Audit-Felder, Versionstabellen, `ReceiptLogBL`, `ChangeTracking/History` und `AnlageLog` bilden dieselbe Aufgabe fünffach ab.", + "pruefidee": "Eine Auskunft „wer hat wann welches Feld geändert\" muss aus einer Quelle beantwortbar sein.", + "qm": "Wartbarkeit (Analysierbarkeit)", + "uebernahme": "übernehmen - im Zielsystem mit einem Ereignisprotokoll." + }, + { + "id": "SwRS-160", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Selbstenthaltende Veröffentlichung der Webanwendung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-160, StRS-052", + "konsolidierung": "nein", + "pruefidee": "Das Laufzeitabbild darf kein `dotnet build` ausführen können.", + "qm": "Übertragbarkeit (Installierbarkeit)", + "uebernahme": "übernehmen - die Lizenzdatei ist im Zielsystem nicht über ein Bauargument, sondern über ein Geheimnis einzubringen." + }, + { + "id": "SwRS-161", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Skriptmethoden mit reservierter Nummer", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-161", + "konsolidierung": "nein", + "pruefidee": "Zwei Skriptmethoden dürfen nicht dieselbe Nummer tragen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-162", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Abschaltbarkeit und Versionsüberschreibung der Skriptausführung", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-162, SyRS-161", + "konsolidierung": "nein", + "pruefidee": "Mit `ShouldExecuteScripts` auf „falsch\" darf beim Start kein Skript ausgeführt werden.", + "qm": "Wartbarkeit (Testbarkeit)", + "uebernahme": "übernehmen - der übersetzungsabhängige `#if DEBUG`-Block ist im Zielsystem durch eine Konfiguration zu ersetzen." + }, + { + "id": "SwRS-163", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Übersetzung auf eigenem Bauserver mit Zeitgrenze", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-163", + "konsolidierung": "nein", + "pruefidee": "Ein Pull Request aus einer Abspaltung darf keinen Bau auf dem eigenen Server auslösen.", + "qm": "Wartbarkeit (Testbarkeit)", + "uebernahme": "übernehmen - Absicherung der Bauumgebung." + }, + { + "id": "SwRS-164", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Testprojekte spiegeln die Projektstruktur", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-164", + "konsolidierung": "nein", + "pruefidee": "Zu jedem Quellprojekt unter `src/apis` muss ein Testprojekt unter `tests/apis` bestehen.", + "qm": "Wartbarkeit (Testbarkeit)", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-165", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Protokollierung mit strukturierten Platzhaltern", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-165, SwRS-105", + "konsolidierung": "nein", + "pruefidee": "Eine Protokollsuche nach einem Benutzernamen muss alle zugehörigen Einträge finden.", + "qm": "Wartbarkeit (Analysierbarkeit)", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-166", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Datenqualitätsprüfungen mit benannten Befundarten", + "typ": "Daten", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-166, SyRS-023", + "konsolidierung": "nein", + "pruefidee": "Ein Befund zu einem Ticket muss die Bezeichnung „Ticket\" tragen, nicht die Zahl der Objektart.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-167", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zeitfensterbasierte Telemetriezähler", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-167", + "konsolidierung": "nein", + "pruefidee": "Ein noch laufendes Zeitfenster darf nicht zur Übermittlung freigegeben werden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-168", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Verbindungsarten als Aufzählung mit Modulzuordnung", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-168, SwRS-002", + "konsolidierung": "nein", + "pruefidee": "Ein Modul mit nur `SqlServer` in der Deklaration darf bei Webservice-Verbindung nicht geöffnet werden.", + "qm": "", + "uebernahme": "veraltet - im Zielsystem entfällt die Unterscheidung." + }, + { + "id": "SwRS-170", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Statistikbereiche nach Auswertungsgegenstand geschnitten", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-170", + "konsolidierung": "Kandidat: SwRS-170 selbst — Ticketstatistiken liegen sowohl unter `Statistics/TicketStatistics` als auch im Supportzweig.", + "pruefidee": "Eine Änderung an `TicketStatistics` darf `SaleStatistics` nicht übersetzungsunfähig machen.", + "qm": "Wartbarkeit (Modularität)", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-171", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Eigener Sprachanalysator für den Suchindex", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-171", + "konsolidierung": "nein", + "pruefidee": "Die Suche nach „Rechnung\" muss auch „Rechnungen\" finden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-172", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Aufforderungstexte der KI als eigene Artefakte", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-172", + "konsolidierung": "nein", + "pruefidee": "Eine Änderung des Aufforderungstextes muss ohne Neuübersetzung wirksam werden.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-173", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Fachlich geschnittene REST-Ressourcen", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-173", + "konsolidierung": "nein", + "pruefidee": "Ein neuer Endpunkt zu Tickets muss unter `Controllers/v1/Tickets` liegen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-174", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Hostvarianten mit gemeinsamer Kernbibliothek", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-174, SyRS-160", + "konsolidierung": "nein", + "pruefidee": "Derselbe Endpunkt muss in beiden Betriebsformen dieselbe Antwort liefern.", + "qm": "Übertragbarkeit (Anpassbarkeit)", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-175", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Integrationsressourcen je Fremdsystem", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-175, SyRS-173", + "konsolidierung": "Kandidat: SwRS-175 selbst — docBee- und RMM-Endpunkte liegen auf zwei Bereiche verteilt.", + "pruefidee": "Die Konfiguration des RMM-Zugangs muss über einen anderen Endpunkt erfolgen als der Datenabruf.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-176", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Massenupdate als eigener Baustein mit eigenem Modul", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-176", + "konsolidierung": "nein", + "pruefidee": "Eine zusätzliche Massenänderungsart darf keine Änderung an den Fachmodulen erfordern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-177", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "SQL-Verwaltung mit Datenbankauskunft für den Lizenzserver", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-177, SyRS-103", + "konsolidierung": "nein", + "pruefidee": "Zwei Installationen auf derselben Datenbank müssen dieselbe Datenbankkennung melden.", + "qm": "", + "uebernahme": "übernehmen - die Zuordnung von Lizenz zu Installation bleibt im SaaS-Betrieb erforderlich." + }, + { + "id": "SwRS-178", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Reportkomponenten nach Aufgabe getrennt", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-178, SyRS-110", + "konsolidierung": "nein", + "pruefidee": "Eine Änderung an `PdfExport` darf `ReportDataQueryBL` nicht berühren.", + "qm": "Wartbarkeit (Modularität)", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-179", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Erwartete Ereignisse mit getrennter Auswertung", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-179", + "konsolidierung": "nein", + "pruefidee": "Ein Benutzer nur mit dem Auswertungsrecht darf keine erwarteten Ereignisse anlegen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-180", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Arbeitsschritte am Artikel als Produktionsgrundlage", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-180, SyRS-035", + "konsolidierung": "nein", + "pruefidee": "Ein am Artikel gepflegter Arbeitsschritt muss sowohl im Produktionsauftrag als auch in der Ticketabrechnung auswählbar sein.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-181", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Mitarbeiterbausteine nach Aufgabe getrennt", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-181", + "konsolidierung": "Kandidat: SwRS-181 selbst — mitarbeiterbezogene Fachlogik liegt in zwei Bereichen (`EmployeeArea`, `Administration/Employees`).", + "pruefidee": "Eine Änderung an `EmployeeHolidayBL` darf `AppUserBL` nicht berühren.", + "qm": "Wartbarkeit (Modularität)", + "uebernahme": "übernehmen - im Zielsystem in einem Bereich zu bündeln." + }, + { + "id": "SwRS-182", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Auswertung von Zeiten über Artikelkennungen", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-182", + "konsolidierung": "nein", + "pruefidee": "Die Auswahl eines Mitarbeiters ohne Mitarbeiterartikel muss ein nachvollziehbares Ergebnis liefern.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem ist die unmittelbare Zuordnung zum Mitarbeiter zu prüfen." + }, + { + "id": "SwRS-183", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kundenaktivität als beidseitig auflösbare Verknüpfung", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-183, SwRS-024", + "konsolidierung": "nein", + "pruefidee": "Zu einer Rechnung müssen mit gesetztem Schalter auch die Aktivitäten des zugrunde liegenden Auftrags erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-190", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Vertragsauswertung als eigenes Modul", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-170, StRS-008", + "konsolidierung": "nein", + "pruefidee": "Die Auswertung muss für einen Vertrag Erlöse und Aufwände gegenüberstellen.", + "qm": "", + "uebernahme": "übernehmen - die Namensziffer weist auf eine abgelöste Vorgängerfassung hin, die im Zielsystem entfällt." + }, + { + "id": "SwRS-191", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Leasing- und Serviceangaben am Beleg", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-018, StRS-003", + "konsolidierung": "nein", + "pruefidee": "Ein Angebot mit Leasingangabe muss diese im daraus erzeugten Auftrag tragen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-192", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "CRM-Projekte mit eigener Nummernart", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-093, StRS-001", + "konsolidierung": "Kandidat: SwRS-028 — CRM-Projekte und Belegprojekt-Layouts tragen beide den Begriff „Projekt\", bezeichnen aber verschiedene Gegenstände; die Abgrenzung ist im Zielsystem zu schärfen.", + "pruefidee": "Ein neues CRM-Projekt muss eine Nummer aus dem Nummernkreis 24 erhalten.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-193", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Lieferantenverträge am Account", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-002, StRS-024", + "konsolidierung": "Kandidat: SwRS-030 — Kunden- und Lieferantenverträge sind zwei getrennte Vertragsmodelle.", + "pruefidee": "Bei nicht aktiviertem Account-Stamm darf das Modul „Lieferanten-Verträge\" nicht erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-194", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Segmentierungsmerkmale des Kundenstamms", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-173, StRS-057", + "konsolidierung": "nein", + "pruefidee": "Eine Kampagne auf einen Geschäftsbereich muss genau die Kunden dieses Bereichs auswählen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-195", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Ticketprozesse und Ticketprojekte als getrennte Bündelungen", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-058, StRS-020", + "konsolidierung": "Kandidat: SwRS-195 selbst — Ticketprozess, Ticketprojekt und Taskmanagement bündeln Tickets in drei getrennten Konzepten.", + "pruefidee": "Ein Ticket mit unerfüllter Abhängigkeit darf nicht als bearbeitbar gelten.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem auf zwei Konzepte (Ablauf und Vorhaben) zu reduzieren." + }, + { + "id": "SwRS-196", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Anbindung fremder Ticketsysteme", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-175, StRS-062", + "konsolidierung": "nein", + "pruefidee": "Eine im Fremdsystem erfasste Ticketzeit muss über den zugehörigen Endpunkt abrufbar sein.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-197", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Artikelimport mit eigenem Modul und eigener Fachlogik", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-176, SyRS-033", + "konsolidierung": "Kandidat: SwRS-197 selbst — vier Importmodule mit gleichartigem Ablauf (Datei lesen, prüfen, übernehmen).", + "pruefidee": "Ein Artikelimport darf keine Sonderpreise anlegen.", + "qm": "", + "uebernahme": "übernehmen - im Zielsystem mit gemeinsamem Importrahmen." + }, + { + "id": "SwRS-198", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kostenstellen und Kostenträger als eigene Stammdaten", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-080, StRS-027", + "konsolidierung": "nein", + "pruefidee": "Ein Beleg für einen Kunden mit hinterlegter Kostenstelle muss diese vorbelegen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-199", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Filialkalkulation als eigenes Modul", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-076, SyRS-080", + "konsolidierung": "Kandidat: SwRS-076 — Filialbestellung und Filialkalkulation nutzen dieselbe Oberfläche.", + "pruefidee": "Die Kalkulation muss je Filiale ein eigenes Ergebnis ausweisen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-200", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Gutscheinverwaltung mit eigenen Artikeln", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-064, StRS-007", + "konsolidierung": "nein", + "pruefidee": "Ein eingelöster Gutschein darf nicht erneut einlösbar sein.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-201", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "docuFORM-Anbindung als eigenes Projekt", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "StRS-010, SyRS-175", + "konsolidierung": "Kandidat: SwRS-140 — Zählerstände entstehen sowohl manuell am Stammblatt als auch automatisch über docuFORM.", + "pruefidee": "Ein über docuFORM bezogener Zählerstand muss am Stammblatt erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-202", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kategorien virtueller Objekte für Checklisten", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-054, StRS-019", + "konsolidierung": "nein", + "pruefidee": "Eine Checkliste zu einem virtuellen Objekt muss dessen Kategorie tragen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-203", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Anwendungseinstellungen als typisierte Schlüsselwerte", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR", + "KONTEXT" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-053, SyRS-056", + "konsolidierung": "nein", + "pruefidee": "Eine nicht gepflegte Einstellung muss den im Aufruf angegebenen Vorgabewert liefern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-204", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Terminanfragen als eigener Vorgang", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-114, StRS-042", + "konsolidierung": "nein", + "pruefidee": "Eine unbestätigte Terminanfrage darf im Kalender nicht als fester Termin erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-205", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Interne Kurznachrichten", + "typ": "funktional", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-128", + "konsolidierung": "Kandidat: SwRS-128 — Chats und Benachrichtigungen überschneiden sich in der Zustellung.", + "pruefidee": "Eine gesendete Nachricht muss beim Empfänger als Benachrichtigung erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-206", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Freie Verschlagwortung von Objekten", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-171, SyRS-023", + "konsolidierung": "Kandidat: SwRS-206 selbst — allgemeine und reportbezogene Verschlagwortung sind getrennt implementiert.", + "pruefidee": "Ein verschlagwortetes Ticket muss über sein Schlagwort auffindbar sein.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-207", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Kurzlinks mit hinterlegter Aktion", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-123, SyRS-112", + "konsolidierung": "nein", + "pruefidee": "Ein Kurzlink mit Erinnerungsaktion muss beim Aufruf die Erinnerung erzeugen.", + "qm": "", + "uebernahme": "übernehmen - Gültigkeitsdauer und Einmaligkeit sind im Zielsystem festzulegen." + }, + { + "id": "SwRS-208", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Strukturierte Kundendokumentation", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-111, StRS-039", + "konsolidierung": "nein", + "pruefidee": "Eine Kategorie ohne Recht darf in der Dokumentationsübersicht nicht erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-209", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Social-Media-Anbindung mit eigenen Datenstrukturen", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-175, StRS-057", + "konsolidierung": "nein", + "pruefidee": "Ein Kommentar zu einem Beitrag muss diesem Beitrag zugeordnet gespeichert werden.", + "qm": "", + "uebernahme": "veraltet - die Tabellen bestehen, im aktuellen Modulkatalog ist jedoch kein Social-Media-Modul registriert; die fachliche Weiterverwendung ist zu prüfen." + }, + { + "id": "SwRS-210", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Zuordnung von Schulungsvideos zu Objekten", + "typ": "Daten", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-170", + "konsolidierung": "nein", + "pruefidee": "Ohne das Recht darf kein Video erreichbar sein.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-211", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Gemeinsame Steuerelement- und Kernbibliotheken", + "typ": "nicht-funktional", + "belege": [ + "PRIMÄR", + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SwRS-001", + "konsolidierung": "Kandidat: SwRS-211 selbst — `Centron.Core` und `Centron.Common` bündeln beide allgemeine Hilfsmittel.", + "pruefidee": "Eine Datumsformatierung muss in Rich-Client und Webanwendung dasselbe Ergebnis liefern.", + "qm": "Wartbarkeit (Wiederverwendbarkeit)", + "uebernahme": "übernehmen - im Zielsystem sind die beiden Hilfsbibliotheken zusammenzuführen." + }, + { + "id": "SwRS-212", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Mobile Datenversorgung als eigener Baustein", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-173, SyRS-102", + "konsolidierung": "nein", + "pruefidee": "Ein mobiler Abruf darf nur die für den mobilen Einsatz vorgesehenen Felder liefern.", + "qm": "", + "uebernahme": "übernehmen" + }, + { + "id": "SwRS-213", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Externe Werkzeuge und Fernwartung", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SwRS-053, SyRS-057", + "konsolidierung": "Kandidat: SwRS-053 — die Platzhalterersetzung ist ein weiterer Ort derselben Aufgabe.", + "pruefidee": "Ein Werkzeugaufruf aus einem Ticket muss dessen Ticketnummer im Aufrufbefehl enthalten.", + "qm": "", + "uebernahme": "übernehmen - im Web-/SaaS-Zielsystem ist der Start lokaler Programme neu zu lösen." + }, + { + "id": "SwRS-214", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Fremdsystemkonnektoren mit eigener Verbindungslogik", + "typ": "Schnittstelle", + "belege": [ + "PRIMÄR", + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-175, StRS-062", + "konsolidierung": "Kandidat: SwRS-214 selbst — fünf Konnektoren ohne gemeinsame Konnektorschnittstelle.", + "pruefidee": "Ein nicht erreichbares Fremdsystem darf nur den zugehörigen Konnektor in einen Fehlerzustand versetzen.", + "qm": "", + "uebernahme": "übernehmen - die als überholt gekennzeichnete RiverSuite-Anbindung entfällt im Zielsystem." + }, + { + "id": "SwRS-215", + "ebene": "SwRS", + "datei_ebene": "SwRS", + "fremdabgelegt": false, + "titel": "Dashboard und Startbereich als verdichtete Einstiegssicht", + "typ": "funktional", + "belege": [ + "PRIMÄR", + "SEKUNDÄR" + ], + "status": "belegt", + "hypothese": false, + "workaround": false, + "tracelinks": "SyRS-170, StRS-046", + "konsolidierung": "Kandidat: SwRS-215 selbst — Rich-Client und Weboberfläche führen zwei getrennte Dashboard-Implementierungen.", + "pruefidee": "Nach dem Öffnen eines Belegs muss dieser in der Liste zuletzt verwendeter Objekte erscheinen.", + "qm": "", + "uebernahme": "übernehmen" + } +] \ No newline at end of file diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/anforderungen.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/anforderungen.md new file mode 100644 index 00000000..5a67c65a --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/anforderungen.md @@ -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 | 62 | 17,1 % | +| SyRS | 132 | 36,4 % | +| SwRS | 169 | 46,6 % | +| **Gesamt** | **363** | 100 % | + +### Anforderungstypen + +| Typ | Anzahl | Anteil | +|---|---:|---:| +| funktional | 147 | 40,5 % | +| Daten | 87 | 24,0 % | +| Sicherheit | 55 | 15,2 % | +| nicht-funktional | 46 | 12,7 % | +| Schnittstelle | 28 | 7,7 % | + +### Belegqualität + +| Messgröße | Wert | +|---|---:| +| Belege gesamt | 740 | +| davon `PRIMÄR` | 490 (66,2 %) | +| davon `SEKUNDÄR` | 187 (25,3 %) | +| davon `KONTEXT` | 63 (8,5 %) | +| Belege je Anforderung (Median) | 2 | +| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 362 (99,7 %) | + +### Übernahmewürdigkeit + +| Einstufung | Anzahl | Anteil | +|---|---:|---:| +| übernehmen | 337 | 92,8 % | +| workaround | 12 | 3,3 % | +| sonderfall | 1 | 0,3 % | +| veraltet | 13 | 3,6 % | + +### Status + +| Kategorie | Anzahl | Anteil | +|---|---:|---:| +| belegt | 358 | 98,6 % | +| als `HYPOTHESE` gekennzeichnet | 5 | 1,4 % | +| als Workaround vermerkt | 0 | 0,0 % | +| Konsolidierungskandidaten | 67 | 18,5 % | +| mit ISO-25010-Qualitätsmerkmal | 46 | 12,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** (106 risikorelevante Anforderungen, alle gedeckt) | +| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** | +| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 363 Anforderungen eingestuft) | +| **Traceability** – Verknüpfung zwischen den Ebenen | 363 von 363 mit Tracelinks (100,0 %) | + diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/before.txt b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/before.txt new file mode 100644 index 00000000..8b137891 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/before.txt @@ -0,0 +1 @@ + diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/combined_prompt.md b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/combined_prompt.md new file mode 100644 index 00000000..e5351af9 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/combined_prompt.md @@ -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: - +Titel: +Ebene: +Typ: +Qualitätsmerkmal: +Akteur: +Vorbedingung: +Fakt: +Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage) +Ergebnis: +Belege: + - [PRIMÄR] - Begründung: + - [SEKUNDÄR] <...> - Begründung: <...> + - [KONTEXT] <...> - Begründung: <...> +Prüfidee: +Tracelinks: +Konsolidierung: > +Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - +Status: +``` + +### 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_225807_v7.0.0-2269\Ergebnisse\`. +Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis). diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/endzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/endzeit.txt new file mode 100644 index 00000000..e3180ffd --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/endzeit.txt @@ -0,0 +1 @@ +2026-08-27T00:24:02.3040325+02:00 diff --git a/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/startzeit.txt b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/startzeit.txt new file mode 100644 index 00000000..42992326 --- /dev/null +++ b/Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/high/02_Lauf_2026-08-26_225807_v7.0.0-2269/_meta/startzeit.txt @@ -0,0 +1 @@ +2026-08-26T22:58:15.5203844+02:00 diff --git a/Versuche/Versuch_02/01_Agents.json b/Versuche/Versuch_02/01_Agents.json new file mode 100644 index 00000000..7de332d3 --- /dev/null +++ b/Versuche/Versuch_02/01_Agents.json @@ -0,0 +1,34 @@ +{ + "modulinventar": { + "description": "Schritt 0: erstellt das vollständige Modulinventar als Bezugsgröße für die Abdeckung, mit Buchführung über zugeordnete und nicht zugeordnete Quelldateien. Erzeugt KEINE Anforderungen.", + "prompt": "Du erstellst das Modulinventar für ein Reverse-Requirements-Engineering-Vorhaben an einer Legacy-ERP-Suite. Du formulierst KEINE Anforderungen. Deine einzige Aufgabe ist eine vollständige, belegte und nachrechenbare Bestandsaufnahme.\n\n## Vorgehen\n\n1. Erschließe die Struktur aus den Projektdateien, nicht aus Vermutungen: Solution- und Projektdateien, Verzeichnisbaum, Modul-Registrierungen im Code, Rechtekonstanten, Tabellen des Datenbankschemas.\n2. Erfasse JEDES fachliche Modul und JEDE technische Querschnittskomponente. Ein Modul, das hier fehlt, existiert für die gesamte weitere Analyse nicht — das Inventar ist die Bezugsgröße für die Mindestabdeckung.\n3. Nimm das Datenbankschema ausdrücklich mit auf: Ein Schema-Dump im Arbeitsverzeichnis ist eine erstrangige Strukturquelle. Ordne die Tabellengruppen den fachlichen Modulen zu, soweit die Namensgebung das trägt.\n\n## Was du je Eintrag lieferst\n\n`ID` (M001, M002, … fortlaufend, stabil sortiert) | `Modul` | `Art` (fachlich | technisch) | `Pfad` | `Dateien` (Anzahl Quelldateien) | `Aufgabe` (ein Satz) | `Belegquelle` (woraus du die Aufgabe abgeleitet hast: Klassenname, UI-String, Kommentar, Tabellenname)\n\n## Harte Regeln\n\n- **Der Aufgabensatz muss belegt sein.** Leite ihn aus dem ab, was du tatsächlich gelesen hast. Ein Ordnername ist kein Beleg. Kannst du die Aufgabe nicht bestimmen, schreibe `Aufgabe unbestimmt` plus Begründung — aber lasse das Modul NICHT weg.\n- **Kein Zuschnitt nach Bequemlichkeit.** Weder alles in wenige Großmodule zusammenfassen noch jede Datei zu einem Modul erklären. Richte dich nach der fachlichen Gliederung, die die Codebasis selbst vornimmt (Modulregistrierung, Menüstruktur, Namensräume). Beschreibe deinen Zuschnitt in zwei Sätzen, damit er nachvollziehbar ist.\n\n## Abschlussbuchführung — Pflicht\n\nNenne am Ende:\n- Anzahl Module gesamt, davon fachlich / technisch\n- Summe der dem Inventar zugeordneten Quelldateien\n- Gesamtzahl der Quelldateien im Arbeitsverzeichnis\n- Die Differenz, und welche Verzeichnisse sie ausmacht\n\nEine Differenz ist zulässig (Tests, generierter Code, Ressourcen), aber sie muss **benannt** sein. Eine Buchführung, die nicht aufgeht und das nicht erklärt, ist unbrauchbar.\n\n## Rückgabe\n\nDie Inventartabelle, die zwei Sätze zum Zuschnitt und die Abschlussbuchführung. Keine Einleitung, keine Zusammenfassung, keine Empfehlungen." + }, + "faktenermittler": { + "description": "Erhebt für einen zugewiesenen Modulausschnitt belegte technische Fakten samt der durchsetzenden Codestelle, mit Abdeckungsbuchführung je Modul. Formuliert KEINE Anforderungen.", + "prompt": "Du erhebst Fakten aus einer Legacy-ERP-Codebasis. Du formulierst KEINE Anforderungen und KEINE Interpretationen — die schreibt der Auftraggeber selbst aus deinen Fakten. Deine Fakten sind sein einziges Material: Was du nicht lieferst, wird nicht spezifiziert; was du falsch lieferst, wird zur falschen Anforderung.\n\n## Was ein Fakt ist\n\n`Fundstelle` — Pfad, Klasse, Methode, wenn bestimmbar Zeilenbereich.\n`Beobachtung` — was der Code tatsächlich tut: Statusübergang, Validierungsregel, Berechnungsformel, Berechtigungsprüfung, Constraint, Default. Die tragende Bedingung wörtlich oder eng paraphrasiert.\n`Einstufung` — nach der Rubrik unten.\n`Modul` — die Inventar-ID, zu der der Fakt gehört.\n\n## Belegrubrik — daran entscheidet sich die Verwertbarkeit\n\n**PRIMÄR** — die genannte Stelle **setzt die Regel durch**. Man kann hingehen und die Bedingung lesen.\n> `AppRightsBL.cs, GetRightsFromCurrentUser(AppUser)` — iteriert `user.Groups` und sammelt `group.Rights`; Rechte hängen ausschließlich an Gruppen, nie direkt am Benutzer.\n\n**SEKUNDÄR** — die Stelle ruft die Regel auf, konfiguriert oder zeigt sie an, setzt sie aber nicht durch.\n> `AppUserGroupBL.cs` — verwaltet die Gruppenzuordnung, auf der die Rechteprüfung aufbaut.\n\n**KONTEXT** — Umfeld, das die Aussage stützt, ohne sie zu tragen: UI-Beschriftungen, Konfigurationswerte, Kommentare.\n\n## Anti-Muster — in Messungen nachweislich gescheitert\n\n- **„Diese Datei betrifft die Fakturierung.“** Ein Dateiverweis ist kein Fakt. Gefordert ist die Stelle **mit Bedingung**, etwa: `InvoiceService.cs:212, FinalizeInvoice() — wirft InvalidOperationException, wenn invoice.Status == InvoiceStatus.Paid`.\n- **„Ich öffne ein bis drei repräsentative Dateien.“** Stichproben liefern keine Primärbelege: Die durchsetzende Stelle liegt fast nie in der Datei, die repräsentativ aussieht. Nutze Suchwerkzeuge, um die tragenden Stellen zu finden, statt zu raten, welche Datei sie enthält.\n- **Aufwärtsrunden der Einstufung.** Was du nicht als durchsetzende Stelle gelesen hast, ist nicht `PRIMÄR`. Eine falsch hochgestufte Einstufung ist schlimmer als eine ehrliche `SEKUNDÄR`.\n\n## Pflichtquellen\n\n- **Das Datenbankschema.** Liegt ein SQL-Schema-Dump im Arbeitsverzeichnis, ist er für deinen Ausschnitt auszuwerten: Constraints, Fremdschlüssel, Defaults und `NOT NULL` sind durchgesetzte Regeln und damit erstrangige `PRIMÄR`-Belege. In Messungen haben zwei von fünf Läufen den Dump übersehen und dadurch Belege verloren.\n- **Risikobereiche zuerst und tiefer:** Sicherheitsregeln, Abrechnungs- und Fakturierungslogik, Berechtigungsprüfungen.\n\n## Was du ausdrücklich melden musst\n\n- **Nicht gefundene Durchsetzung.** Existiert eine Regel offensichtlich, kannst du die durchsetzende Stelle aber nicht lokalisieren, sage das mit Begründung. Diese Meldungen werden zu ausgewiesenen Hypothesen. Eine verschwiegene Lücke wird dagegen zu einer Anforderung, die niemand mehr prüfen kann.\n- **Widersprüche.** Zwei Stellen, die dieselbe Regel unterschiedlich durchsetzen, sind ein eigener Befund — nicht stillschweigend zugunsten einer Variante auflösen.\n- **Nicht implementiertes.** Methoden, die nur `throw new NotImplementedException(...)` enthalten, obwohl Aufrufer und Rechteprüfung existieren, sind ein Befund von hohem Wert.\n\n## Abdeckungsbuchführung — Pflicht\n\nSchließe mit einer Tabelle: je zugewiesenem Modul die Anzahl der gelieferten Fakten, davon `PRIMÄR`, und die Einstufung `tief | mittel | flach | nicht erschlossen` mit einem Satz Begründung. Module ohne einen einzigen Fakt sind namentlich zu nennen.\n\n## Rückgabe\n\nDie Fakten, nach Modul gegliedert, dann die Abdeckungsbuchführung. Prüfe vor dem Absenden: Trägt jeder als `PRIMÄR` eingestufte Fakt eine Bedingung, die man an der genannten Stelle nachlesen kann? Wenn nicht, stufe ihn herunter." + }, + "strs-autor": { + "description": "Formuliert ausschließlich Stakeholder-Anforderungen (StRS) im vorgegebenen Blockformat aus gelieferten Fakten.", + "prompt": "Du formulierst **ausschließlich Stakeholder-Anforderungen (StRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nStRS beschreibt die **fachliche Sicht**: Akteure, Geschäftsziele, Geschäftsregeln, fachliche Ergebnisse. Nicht, wie das System das technisch löst.\n\n**Grenztest — wende ihn auf jede `Aussage` an, bevor du sie stehen lässt:** Nennt der Satz eine Klasse, eine Methode, eine Tabelle, ein Protokoll oder eine Schnittstelle, gehört er nicht auf diese Ebene. Formuliere ihn fachlich um oder verwirf ihn und setze stattdessen einen Tracelink. Der Fakt darf und soll technisch sein — die `Aussage` nicht.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Keine Anforderung ohne Beleg.** Fundstelle und Einstufung werden aus den gelieferten Fakten **unverändert** übernommen. Du stufst nichts hoch und erfindest nichts. Findest du keinen Fakt für einen Sachverhalt, schreibst du keine Anforderung — du meldest die Lücke.\n- **`Fakt` und `Aussage` sind zwei verschiedene Dinge.** `Fakt` ist die belegte Beobachtung, `Aussage` die fachliche Soll-Formulierung („Das System soll …“). Wer beides vermischt, erzeugt eine Anforderung, deren Belegbarkeit nicht mehr prüfbar ist.\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen einen `PRIMÄR`-Beleg **oder** `[HYPOTHESE]` in `Status`. Einen dritten Weg gibt es nicht. Dies ist die Regel, die in Messungen am häufigsten verfehlt wurde — prüfe sie bei jeder einzelnen Anforderung.\n- **Belege mehrfach, wo die Faktenlage es hergibt.** Ein einzelner Beleg ist zulässig, aber kein Ziel; Anforderungen mit mehreren unabhängigen Belegen sind belastbarer.\n- **`Prüfidee` ist Pflicht** und muss ein prüfbares Kriterium nennen. „Wird getestet“ ist keine Prüfidee. „Benutzer A ist nur Gruppe X zugeordnet, X besitzt Recht R nicht → Aufruf einer mit R geschützten Aktion muss verweigert werden“ ist eine.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, niemals im Feld `Typ`.\n\n## Selbstprüfung vor dem Absenden\n\nGeh deine Blöcke durch und beantworte für dich: Wie viele Anforderungen hast du geschrieben? Wie viele davon sind risikorelevant, und tragen die **alle** entweder `PRIMÄR` oder `[HYPOTHESE]`? Gibt es doppelte IDs? Nenne diese drei Zahlen am Ende deiner Rückgabe.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die drei Zahlen der Selbstprüfung und eine Liste der Sachverhalte, für die dir Fakten fehlten." + }, + "syrs-autor": { + "description": "Formuliert ausschließlich System-Anforderungen (SyRS) im vorgegebenen Blockformat aus gelieferten Fakten.", + "prompt": "Du formulierst **ausschließlich System-Anforderungen (SyRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nSyRS beschreibt das **beobachtbare Systemverhalten an den Systemgrenzen**: Schnittstellen, Statusmaschinen, Validierungen, Performance- und Sicherheitsverhalten.\n\n**Grenztest nach oben:** Beschreibt deine `Aussage` ein Geschäftsziel, ohne Systemverhalten zu nennen, gehört sie auf die StRS-Ebene.\n**Grenztest nach unten:** Beschreibt sie internen Aufbau — Klassenstruktur, Persistenzweg, Algorithmus —, gehört sie auf die SwRS-Ebene. Verwende Tracelinks statt die Grenze zu überschreiten.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Keine Anforderung ohne Beleg;** Fundstelle und Einstufung unverändert übernehmen, nichts hochstufen.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Diese Regel wurde in Messungen am häufigsten verfehlt — prüfe sie einzeln.\n- **Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung** in `Tracelinks`. Existiert keine, benenne die fachliche Lücke ausdrücklich, statt das Feld leer zu lassen.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, nicht im `Typ`. Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.\n- **`Prüfidee` ist Pflicht** und nennt ein prüfbares Kriterium.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl geschriebener Anforderungen; Anzahl risikorelevanter und ob **alle** gedeckt sind; Anzahl ohne StRS-Tracelink. Nenne die drei Zahlen am Ende.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten." + }, + "swrs-autor": { + "description": "Formuliert ausschließlich Software-Anforderungen (SwRS) im vorgegebenen Blockformat aus gelieferten Fakten, einschließlich Konsolidierungsprüfung.", + "prompt": "Du formulierst **ausschließlich Software-Anforderungen (SwRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene\n\nSwRS beschreibt die **softwareinterne Sicht**: Komponenten, Datenmodelle, Persistenzregeln, interne Algorithmen und Berechnungsvorschriften, softwareinterne Constraints. Was an der Systemgrenze beobachtbar ist, gehört auf die SyRS-Ebene.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Keine Anforderung ohne Beleg;** nichts hochstufen, nichts erfinden.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Einzeln prüfen.\n- **Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung** in `Tracelinks`.\n- **Datenbank-Constraints sind erstrangige Belege.** Fremdschlüssel, `NOT NULL`, Defaults und Check-Constraints aus dem Schema sind durchgesetzte Regeln und als `PRIMÄR` einzustufen.\n\n## Konsolidierungsprüfung — deine besondere Zuständigkeit\n\nDie Codebasis enthält fachliche Redundanz: Dieselbe Funktion kann in getrennten Modulen unterschiedlich implementiert sein. Prüfe bei jeder Anforderung, ob eine andere denselben fachlichen Gegenstand abbildet, und trage den Fall in `Konsolidierung` ein.\n\n**Kalibrierung.** Gemeint sind *fachlich gleichartige Konzepte in getrennten Implementierungen*. Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter“ geführt, sonstige Hardware getrennt davon als „Assets“ — zwei Datenhaltungen für denselben fachlichen Gegenstand, im Zielsystem zu einem Asset-Konzept zusammenzuführen.\n\n**Kein Konsolidierungsfall** sind zwei Anforderungen, die denselben Sachverhalt aus Sicht verschiedener Ebenen beschreiben — dafür sind die Tracelinks da. In Messungen schwankte der Anteil der Konsolidierungskandidaten zwischen 2,4 % und 35,2 %; die Spanne entstand fast vollständig dadurch, dass Ebenendopplungen fälschlich als Konsolidierungsfall gezählt wurden.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl Anforderungen; Anzahl risikorelevanter und ob alle gedeckt; Anzahl Konsolidierungskandidaten und für zwei davon je ein Satz, warum es sich um getrennte Implementierungen desselben Gegenstands handelt.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten." + }, + "belegpruefer": { + "description": "Prüft stichprobenartig, ob als PRIMÄR ausgewiesene Belege der Realität standhalten, indem er die zitierte Stelle öffnet. Korrigiert nichts, meldet Abweichungen.", + "prompt": "Du prüfst Belege gegen die Codebasis. Du korrigierst nichts und schreibst keine Anforderungen um — du meldest, was der Prüfung nicht standhält.\n\nDein Auftrag entsteht aus einer gemessenen Schwäche: Anforderungssätze wiesen zwischen 34,6 % und 100 % Primärbelegquote auf. Eine hohe Quote ist wertlos, wenn die Einstufung nicht trägt. Du prüfst, ob sie trägt.\n\n## Vorgehen\n\nFür jeden dir zugewiesenen Beleg:\n\n1. **Öffne die zitierte Stelle.** Existiert die Datei? Die Klasse? Die Methode? Stimmt der Zeilenbereich ungefähr?\n2. **Lies die genannte Bedingung.** Steht dort tatsächlich, was der Beleg behauptet?\n3. **Prüfe die Einstufung.** Setzt diese Stelle die Regel wirklich **durch** — oder ruft sie sie nur auf, konfiguriert oder zeigt sie an? Letzteres ist `SEKUNDÄR`, nicht `PRIMÄR`.\n4. **Prüfe die Deckung.** Trägt die Bedingung die Aussage der Anforderung vollständig, oder nur einen Teil davon?\n\n## Urteil je Beleg\n\n`bestätigt` — Stelle existiert, Bedingung steht dort, Einstufung trägt.\n`einstufung zu hoch` — Stelle existiert, setzt die Regel aber nicht durch. Nenne die korrekte Einstufung.\n`stelle nicht auffindbar` — Datei, Klasse oder Methode existiert nicht wie zitiert.\n`aussage nicht gedeckt` — Stelle existiert, trägt aber eine andere oder engere Aussage als behauptet. Beschreibe die Abweichung.\n\n## Harte Regeln\n\n- **Urteile nur, was du gelesen hast.** Findest du eine Stelle nicht, sage `stelle nicht auffindbar` — schließe nicht aus Plausibilität auf `bestätigt`.\n- **Sei streng bei der Einstufung.** Im Zweifel `einstufung zu hoch`. Ein zu Unrecht bestätigter Primärbeleg ist der teuerste Fehler in diesem Verfahren: Er lässt eine unbelegte Anforderung als belegt erscheinen.\n- **Kürze nichts ab.** Kein „und weitere“. Jeder zugewiesene Beleg bekommt ein Urteil.\n\n## Rückgabe\n\nTabelle `Anforderungs-ID | Beleg | Urteil | Anmerkung`, danach die Zählung: geprüfte Belege, davon bestätigt, zu hoch eingestuft, nicht auffindbar, nicht gedeckt. Bei null Beanstandungen sage das ausdrücklich." + }, + "konsistenzpruefer": { + "description": "Prüft einen fertigen Anforderungssatz vollständig gegen die Vorgaben des Auftrags und meldet jeden Verstoß mit ID. Korrigiert nichts.", + "prompt": "Du prüfst einen fertigen Anforderungssatz gegen die Vorgaben des Auftrags. Du korrigierst nichts und formulierst nichts um — du lieferst dem Auftraggeber eine vollständige Mängelliste, damit er entscheidet.\n\nPrüfe **vollständig und mit absoluten Zahlen**, nicht beispielhaft. Eine Stichprobe ist hier wertlos: In Messungen meldete ein Agent „alle 36 risikorelevanten Anforderungen gedeckt“, während die maschinelle Prüfung 51 fand und eine davon ungedeckt war — er hatte gegen einen zu engen eigenen Risikobegriff geprüft.\n\n## Prüfpunkte\n\n1. **Belegpflicht** — Anforderungen ohne jeden Beleg. Jede ID nennen.\n2. **Risikobasierte Priorisierung** — Anforderungen vom Typ Sicherheit, Abrechnung oder Berechtigungen ohne `PRIMÄR`-Beleg und ohne `[HYPOTHESE]`. **Gehe hier Anforderung für Anforderung vor, nicht überschlägig.** Lege deinen Risikobegriff offen: Nach welchem Kriterium hast du eine Anforderung als risikorelevant eingestuft? Ein enger Begriff lässt Verstöße unentdeckt.\n3. **Verifizierbarkeit** — fehlende Prüfidee, oder Prüfidee ohne prüfbares Kriterium („wird getestet“, „muss funktionieren“).\n4. **Traceability** — Anforderungen ohne Tracelinks; Tracelinks auf nicht existierende IDs; SwRS ohne SyRS-Bezug; SyRS ohne StRS-Bezug.\n5. **Formtreue** — doppelte IDs; Lücken in der Nummerierung; fehlende Pflichtfelder; nicht-funktionale Anforderungen ohne ISO-25010-Merkmal; Merkmale, die fälschlich im Feld `Typ` stehen.\n6. **Ebenentreue** — Anforderungen, deren `Aussage` nicht zur angegebenen Ebene passt (etwa eine Klassen- oder Tabellenaussage auf StRS-Ebene). Zusätzlich: Blöcke, die in der Datei einer **anderen** Ebene abgelegt sind — das kommt vor und macht die Dreiteilung an der Dateistruktur unlesbar.\n7. **Deckungsgleichheit der Hypothesen** — stimmt die Sammeldatei mit den Inline-Kennzeichnungen überein? Nenne Differenzen in beide Richtungen.\n8. **Abdeckung** — Module des Inventars ohne eine einzige Anforderung und ohne dokumentierte Begründung.\n\n## Rückgabe\n\nJe Prüfpunkt: Anzahl Verstöße, Gesamtzahl geprüfter Anforderungen, vollständige Liste der betroffenen IDs. Danach eine Gesamtzählung. Bei null Verstößen in einem Punkt sage das ausdrücklich.\n\nSchätze nichts. Kürze keine Liste mit „und weitere“ ab. Wenn du einen Prüfpunkt nicht vollständig prüfen konntest, sage welchen und warum — das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht." + }, + "iso29148-orchestrator": { + "description": "Führt die Teilergebnisse der Ebenen zur konsolidierten Spezifikation nach ISO/IEC/IEEE 29148 zusammen und stellt Struktur, Traceability und Deckungsgleichheit her. Formuliert keine neuen Anforderungen.", + "prompt": "Du führst die Teilergebnisse der drei Ebenen zu **einer** Spezifikation nach ISO/IEC/IEEE 29148 zusammen. Du formulierst **keine neuen Anforderungen** und änderst keine Aussagen — du stellst her, was erst am zusammengeführten Bestand entstehen kann.\n\nDeine Rolle existiert, weil verteilte Bearbeitung drei Dinge nicht von selbst erzeugt: eine durchgängige Nummerierung, eine beidseitig geschlossene Traceability und eine Hypothesenliste, die zum Bestand passt.\n\n## Was du herstellst\n\n1. **Durchgängige Nummerierung.** Je Ebene lückenlos, ohne Doppelvergabe. Musst du umnummerieren, ziehst du **alle** Verweise mit — Tracelinks, Traceability-Tabelle, Hypothesenliste, Abdeckungstabelle. Eine halb gezogene Umnummerierung ist schlimmer als die Lücke.\n2. **Beidseitige Traceability.** Jede SwRS verweist auf ihre SyRS, jede SyRS auf ihre StRS. Zusätzlich die konsolidierte Tabelle `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`. Verweise, die ins Leere zeigen, meldest du — du erfindest kein Ziel.\n3. **Deckungsgleiche Hypothesenliste.** Die Sammeldatei wird aus dem zusammengeführten Bestand erzeugt, nicht aus den Teilbeständen. Sie muss exakt die Anforderungen enthalten, die inline als `[HYPOTHESE]` gekennzeichnet sind — in beide Richtungen geprüft.\n4. **Abdeckungstabelle über das gemeinsame Inventar.** Jedes Modul mit der Zahl der auf es entfallenden Anforderungen. Module ohne Anforderung nennst du namentlich; sie brauchen eine dokumentierte Begründung.\n5. **Ergebnisstruktur** in der vom Auftrag geforderten Form und Dateiaufteilung.\n\n## Worauf du an den Nahtstellen besonders achtest\n\nDie Fehler verteilter Bearbeitung sitzen an den Rändern der Ausschnitte:\n\n- **Derselbe Sachverhalt zweimal**, von zwei Bearbeitern aus unterschiedlicher Richtung beschrieben. Das ist kein Konsolidierungsfall im fachlichen Sinn, sondern eine Doublette — melde sie als solche.\n- **Ebenenfehler**: eine Aussage über Klassen oder Tabellen auf StRS-Ebene, ein Geschäftsziel auf SwRS-Ebene. Du meldest den Fall, verschiebst ihn aber nicht eigenmächtig — die Aussage müsste dabei umformuliert werden, und das ist Sache des zuständigen Autors.\n- **Belege, die nur im fremden Ausschnitt existieren** und beim Zusammenführen ihren Bezug verlieren.\n- **Blöcke in der Datei einer anderen Ebene.** Die Ebene steht im Block; die Ablage muss ihr folgen, sonst ist die Dreiteilung an der Dateistruktur nicht mehr ablesbar.\n\n## Harte Regeln\n\n- **Keine neue Anforderung, keine geänderte `Aussage`, keine hochgestufte Belegeinstufung.** Fällt dir eine Lücke auf, meldest du sie.\n- **Kein stilles Löschen.** Entfernst du eine Doublette nicht selbst, sondern meldest sie — und wenn du zusammenführst, dann nur nach ausdrücklichem Auftrag und unter Angabe beider Ursprungs-IDs.\n- **Zähle, statt zu schätzen.** Jede Aussage über den Bestand nennt absolute Zahlen.\n\n## Rückgabe\n\nDie zusammengeführte Struktur, danach ein Übergabebericht: Anzahl Anforderungen je Ebene, Anzahl umnummerierter IDs, Anzahl geschlossener und offener Tracelinks, Differenzen zwischen Hypothesenliste und Inline-Kennzeichnung, Module ohne Anforderung, gefundene Doubletten und Ebenenfehler — jeweils mit IDs." + } +} diff --git a/Versuche/Versuch_02/01_Prompt.md b/Versuche/Versuch_02/01_Prompt.md new file mode 100644 index 00000000..906059d0 --- /dev/null +++ b/Versuche/Versuch_02/01_Prompt.md @@ -0,0 +1,172 @@ +# Versuch 02 - Agentengestuetzt - Prompt-Version 02-A + +## Metadaten +- **Versuch:** V2 Agentengestützt (rollenspezialisierte Agentendateien) +- **Prompt-Version:** 02-A (Prompt-Version 02 aus Versuch 01, angepasst an Agentendateien) +- **Basis:** `Versuche/Versuch_01/02_Prompt.md`, SHA-256 `F9B2A1AA…0D7849` +- **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:** Prompt-Version 02 unterstellt an einer Stelle stillschweigend, dass **ein** Bearbeiter die gesamte Kette durchläuft: Sie ordnet Schritte zeitlich (erst Inventar, dann Mindestabdeckung, dann Vertiefung), vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck über das Ergebnis. Wird die Arbeit auf mehrere Rollen verteilt, sind diese Vorgaben nicht mehr von selbst erfüllt: IDs können kollidieren, die Reihenfolge kann rollenweise auseinanderlaufen, und ein Konsistenzcheck über den eigenen Teil ist keiner über das Ganze. + + Ergänzt wird deshalb ausschließlich ein Abschnitt zur **Arbeitsteilung**. Er benennt keine Rollen und schreibt keinen Zuschnitt vor — welche Rollen es gibt, stellt der Versuchsaufbau bei. + + | Änderung | Grund | + |---|---| + | Neuer Abschnitt „Arbeitsteilung" | macht Reihenfolge, ID-Vergabe und Konsistenzprüfung auch bei verteilter Bearbeitung verbindlich | + + Unverändert bleiben Auftrag, Scope, Vorgehensschritte 0 bis 6, Blockformat, Belegklassifikation, Prüfidee, Tracelinks, Konsolidierungsbegriff und Ergebnisstruktur. Der fachliche Auftrag ist mit Versuch 1 identisch; abweichend ist allein, dass die Bearbeitung verteilt erfolgen kann. + +> 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. + +### Arbeitsteilung + +Die Bearbeitung kann auf mehrere Bearbeiter verteilt werden. Ist das der Fall, gelten zusätzlich die folgenden Regeln; wird alles von einem Bearbeiter erledigt, sind sie ohne Wirkung. + +- **Zuständigkeit vor Bearbeitung klären.** Lege fest, wer welchen Ausschnitt bearbeitet, bevor die erste Anforderung entsteht, und halte die Aufteilung im `Analysebericht.md` fest. Ohne festgelegte Zuständigkeit entstehen Lücken zwischen den Ausschnitten und Doppelarbeit an ihren Rändern. +- **ID-Bereiche vorab vergeben, überschneidungsfrei und lückenlos.** Jeder Bearbeiter erhält einen eigenen Nummernbereich je Ebene. Zusammengeführt muss die Nummerierung je Ebene lückenlos sein; doppelte IDs sind unzulässig. +- **Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Bearbeiter.** Führt ein Ausschnitt zu einer Aussage, die auf eine andere Ebene gehört, wird sie dort geführt und über Tracelinks verbunden — nicht auf der eigenen Ebene belassen, weil sie dort anfiel. +- **Die Reihenfolge aus dem Abschnitt Vorgehen gilt über alle Bearbeiter hinweg.** Die Mindestabdeckung ist erreicht, wenn **jedes** Modul des gemeinsamen Inventars mindestens eine Anforderung trägt — nicht, wenn jeder Bearbeiter seinen Ausschnitt abgedeckt hat. Erst danach beginnt die Vertiefung. +- **Der Konsistenzcheck gilt dem zusammengeführten Ergebnis.** Eine Prüfung des eigenen Beitrags ersetzt ihn nicht. Zu prüfen sind insbesondere die Übergänge zwischen den Ausschnitten: Tracelinks, die ins Leere zeigen, doppelt beschriebene Sachverhalte an den Rändern und Belege, die nur im fremden Ausschnitt existieren. +- **Die Sammeldatei der Hypothesen wird zuletzt aus dem zusammengeführten Bestand erzeugt** und muss mit den Inline-Kennzeichnungen deckungsgleich sein. + +### Formatvorgabe pro Anforderung + +``` +ID: - +Titel: +Ebene: +Typ: +Qualitätsmerkmal: +Akteur: +Vorbedingung: +Fakt: +Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage) +Ergebnis: +Belege: + - [PRIMÄR] - Begründung: + - [SEKUNDÄR] <...> - Begründung: <...> + - [KONTEXT] <...> - Begründung: <...> +Prüfidee: +Tracelinks: +Konsolidierung: > +Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - +Status: +``` + +### 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? diff --git a/Versuche/Versuch_02/README.md b/Versuche/Versuch_02/README.md new file mode 100644 index 00000000..ac916ad3 --- /dev/null +++ b/Versuche/Versuch_02/README.md @@ -0,0 +1,147 @@ +# Versuch 02 – Agentengestützt (V2) + +Rollenspezialisierte Agentendateien statt eines einzelnen Threads. Agentenmodus des Skills: +`custom`; die Rollen werden per `--agents` übergeben. + +## Dateien + +| Datei | SHA-256 | Zweck | +|---|---|---| +| `01_Prompt.md` | `DCDC0E3F…B71BCF` | Analyseanweisung, Prompt-Version **02-A** | +| `01_Agents.json` | `6943EECD…AF1696` | acht Agentenrollen | + +## Der Prompt: abgeleitet aus V1, angepasst an Agentendateien + +Prompt-Version **02-A** entsteht aus `Versuche/Versuch_01/02_Prompt.md` +(`F9B2A1AA…0D7849`) durch **eine** Ergänzung: den Abschnitt **Arbeitsteilung**. Alles Übrige – +Auftrag, Scope, Vorgehensschritte 0 bis 6, Blockformat, Belegklassifikation, Prüfidee, +Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur – ist unverändert. + +**Warum die Ergänzung nötig ist.** Prompt-Version 02 unterstellt an mehreren Stellen +stillschweigend, dass *ein* Bearbeiter die gesamte Kette durchläuft: Sie ordnet Schritte zeitlich +(erst Inventar, dann Mindestabdeckung, dann Vertiefung), vergibt fortlaufende IDs und verlangt am +Ende einen Konsistenzcheck über das Ergebnis. Wird die Arbeit auf Rollen verteilt, ist nichts +davon mehr von selbst erfüllt: IDs kollidieren, die Reihenfolge läuft rollenweise auseinander, +und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen. + +Der Abschnitt nennt **keine Rolle** und schreibt **keinen Zuschnitt** vor – welche Rollen es +gibt, stellt der Versuchsaufbau bei. Seine vier Kernsätze: + +- ID-Bereiche vorab vergeben, überschneidungsfrei; zusammengeführt je Ebene lückenlos +- **Die Ebene ergibt sich aus dem Inhalt, nicht aus dem Bearbeiter** – fällt in einem Ausschnitt + eine fremde Ebene an, wird sie dort geführt und über Tracelinks verbunden +- Die Mindestabdeckung ist erreicht, wenn **jedes Modul des gemeinsamen Inventars** eine + Anforderung trägt – nicht, wenn jeder seinen Ausschnitt abgedeckt hat +- Der Konsistenzcheck gilt dem **zusammengeführten** Ergebnis, mit besonderem Blick auf die + Ränder der Ausschnitte + +Der Abschnitt gilt ausdrücklich nur bei verteilter Bearbeitung; bei einem einzelnen Bearbeiter +ist er wirkungslos. Damit bleibt der Prompt auch für einen `solo`-Lauf gültig und der fachliche +Auftrag über V1, V2 und V3 identisch. + +## Die acht Rollen + +| Rolle | Aufgabe | Schreibt Anforderungen? | +|---|---|---| +| `modulinventar` | Schritt 0: vollständiges Inventar samt Abdeckungsbuchführung | nein | +| `faktenermittler` | belegte Fakten samt durchsetzender Codestelle, je Modulausschnitt | nein | +| `strs-autor` | Stakeholder-Ebene | ja, nur StRS | +| `syrs-autor` | Systemebene | ja, nur SyRS | +| `swrs-autor` | Softwareebene, zusätzlich Konsolidierungsprüfung | ja, nur SwRS | +| `iso29148-orchestrator` | führt die Ebenen zur Spezifikation zusammen | nein | +| `belegpruefer` | öffnet zitierte Stellen und prüft, ob `PRIMÄR` trägt | nein | +| `konsistenzpruefer` | vollständige Regelprüfung gegen die Promptvorgaben | nein | + +Die vier von der Arbeit genannten Rollen – Stakeholder, System, Software und +ISO-29148-Orchestrator – sind damit besetzt; `modulinventar`, `faktenermittler`, `belegpruefer` +und `konsistenzpruefer` kommen aus den Messungen hinzu. + +**Der Orchestrator delegiert nicht.** Er startet keine Subagenten und schreibt keine +Anforderungen, sondern stellt her, was erst am zusammengeführten Bestand entstehen kann: +durchgängige Nummerierung samt mitgezogener Verweise, beidseitig geschlossene Traceability, eine +aus dem Gesamtbestand erzeugte Hypothesenliste, die Abdeckungstabelle über das gemeinsame +Inventar. Ein delegierender Orchestrator erzeugte eine zweite Ebene, deren Subagenten-Prompts +nicht protokollierbar sind – in Versuch 1 blieben so 18 von 31 Aufrufen unerfassbar. + +## Woraus die Rollen abgeleitet sind + +Jede Regel in den Agentenprompts ist an einen gemessenen Befund aus den 17 Läufen von +Versuch 1 gekoppelt: + +**Drei Autoren statt einem** – die Ebenenverteilung schwankte bei identischem Prompt von +92,7 % StRS bis 89,4 % SwRS. Ursache: Der Prompt verlangt in Schritt 0b je Modul eine +Anforderung, sagt aber nicht, auf welcher Ebene. Getrennte Autoren machen die Verteilung +strukturell statt emergent. + +**Der `faktenermittler` ist aus den Läufen abgeschrieben.** Drei `builtin`-Läufe, gleiche +Bedingung, unterschiedliche Beauftragung der Subagenten: + +| Lauf | Auftragsart | Anforderungen mit Primärbeleg | +|---|---|---:| +| `4048` | „concrete, citable FACTS only … find the EXACT enforcing location" | 97,8 % | +| `fb24` | „Research …" mit Faktenpflicht | 96,9 % | +| `f8b4` | „quickly inspect … open 1-3 representative files" | 46,4 % | + +Nicht die Zahl der Subagenten entscheidet, sondern ob Tiefe oder Breite beauftragt wird. Das +Stichproben-Verbot im Prompt der Rolle folgt direkt daraus. + +**Der `belegpruefer` ist neu.** Die Primärbelegquote schwankte über 17 Läufe zwischen 34,6 % und +100 %. Eine hohe Quote ist wertlos, wenn die Einstufung nicht trägt – geprüft wurde sie bis dahin +nie. + +**Der `konsistenzpruefer` adressiert den am häufigsten verfehlten Prüfpunkt.** Die risikobasierte +Priorisierung scheiterte in 9 von 16 gültigen Läufen, im schlimmsten Fall bei 18 von 49 +Anforderungen. In einem Lauf meldete der Agent „alle 36 gedeckt", während die maschinelle Prüfung +51 risikorelevante Anforderungen fand – er hatte gegen einen zu engen eigenen Risikobegriff +geprüft. Die Rolle muss ihren Risikobegriff deshalb offenlegen. + +## Ausführung + +Der Skill `run-experiment` übernimmt das im Modus `custom`. Ablage der Läufe: +`//custom//`. + +## Wichtig: `--safe-mode` ist hier nicht verwendbar + +`--safe-mode` schaltet ausweislich der CLI-Hilfe „all customizations (CLAUDE.md, skills, plugins, +hooks, **MCP servers, custom commands and agents**, output styles, …)" ab – also genau das, was +dieser Versuch untersucht. 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}` | + +**Ohne diesen Test wäre der erste Lauf stillschweigend als V1-Lauf gemessen worden**: `--agents` +hätte keine Wirkung gehabt, der Lauf hätte fehlerfrei durchlaufen und Anforderungen erzeugt – nur +eben ohne die Rollen, die den Versuch ausmachen. + +**Der Ersatz** (Skill 7.0.0): kein `--safe-mode`, stattdessen `--strict-mcp-config` und +`--disallowedTools Skill WebSearch WebFetch SlashCommand` zusätzlich zur 33er-Denylist. +Gegengeprüft mit derselben Werkzeugabfrage: `VORGELADEN: NICHTS VORGELADEN` · `SKILLS: KEINE` · +`WEB: KEIN WEBZUGRIFF` · alle 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:** Plugins, Hooks und Output-Styles. Auf der Versuchsmaschine ist +davon nichts konfiguriert, das ist aber eine Eigenschaft der Umgebung und keine Garantie. Der +Skill verlangt deshalb vor jedem Lauf eine Umgebungsprüfung, deren Ergebnis ins Protokoll geht. + +**Folge für die Vergleichbarkeit:** Läufe dieses Versuchs sind hinsichtlich der Isolation nicht +unmittelbar mit den `solo`- und `builtin`-Läufen aus Versuch 1 vergleichbar. Der Unterschied ist +benannt und begrenzt – er betrifft Plugins, Hooks und Output-Styles, nicht CLAUDE.md, Skills, +Webzugriff oder MCP. + +## Offene Punkte vor dem ersten Lauf + +1. **`extract-subagenten.py` ist nicht gegen `custom`-Typen geprüft.** Es erwartet die + eingebauten Typen `Explore` und `general-purpose`; mit `--agents` heißen sie + `faktenermittler`, `strs-autor` und so fort. +2. **Die Modellbedingung ist bei Delegation über `--model` allein nicht herstellbar.** Zwei + dokumentierte Fälle aus Versuch 1: bei Fable liefen die Subagenten auf `claude-opus-5[1m]`, + bei Opus entfielen 18,5 Mio. Tokens (4,72 %) auf `claude-sonnet-5`. Nach jedem Lauf + `modelUsage` prüfen und die Modellbedingung nicht als gesichert annehmen. +3. **Hintergrund-Subagenten und Zeitlimit.** Der Skill setzt seit 6.1.0 + `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`; ohne diese Einstellung bricht der Headless-Modus + nach 600 s ab und meldet dabei `is_error: false` bei null Ergebnisdateien. +4. **Umgebungsprüfung** auf Hooks, Plugins und Output-Styles im User-Profil – siehe oben. diff --git a/Versuche/Versuch_03/01_Agents.json b/Versuche/Versuch_03/01_Agents.json new file mode 100644 index 00000000..bcad52d5 --- /dev/null +++ b/Versuche/Versuch_03/01_Agents.json @@ -0,0 +1,46 @@ +{ + "modulinventar": { + "description": "Schritt 0: erstellt das vollständige Modulinventar als Bezugsgröße für die Abdeckung, mit Buchführung über zugeordnete und nicht zugeordnete Quelldateien. Erzeugt KEINE Anforderungen.", + "prompt": "Du erstellst das Modulinventar für ein Reverse-Requirements-Engineering-Vorhaben an einer Legacy-ERP-Suite. Du formulierst KEINE Anforderungen. Deine einzige Aufgabe ist eine vollständige, belegte und nachrechenbare Bestandsaufnahme.\n\n## Vorgehen\n\n1. Erschließe die Struktur aus den Projektdateien, nicht aus Vermutungen: Solution- und Projektdateien, Verzeichnisbaum, Modul-Registrierungen im Code, Rechtekonstanten, Tabellen des Datenbankschemas.\n2. Erfasse JEDES fachliche Modul und JEDE technische Querschnittskomponente. Ein Modul, das hier fehlt, existiert für die gesamte weitere Analyse nicht — das Inventar ist die Bezugsgröße für die Mindestabdeckung.\n3. Nimm das Datenbankschema ausdrücklich mit auf: Ein Schema-Dump im Arbeitsverzeichnis ist eine erstrangige Strukturquelle. Ordne die Tabellengruppen den fachlichen Modulen zu, soweit die Namensgebung das trägt.\n\n## Was du je Eintrag lieferst\n\n`ID` (M001, M002, … fortlaufend, stabil sortiert) | `Modul` | `Art` (fachlich | technisch) | `Pfad` | `Dateien` (Anzahl Quelldateien) | `Aufgabe` (ein Satz) | `Belegquelle` (woraus du die Aufgabe abgeleitet hast: Klassenname, UI-String, Kommentar, Tabellenname)\n\n## Harte Regeln\n\n- **Der Aufgabensatz muss belegt sein.** Leite ihn aus dem ab, was du tatsächlich gelesen hast. Ein Ordnername ist kein Beleg. Kannst du die Aufgabe nicht bestimmen, schreibe `Aufgabe unbestimmt` plus Begründung — aber lasse das Modul NICHT weg.\n- **Kein Zuschnitt nach Bequemlichkeit.** Weder alles in wenige Großmodule zusammenfassen noch jede Datei zu einem Modul erklären. Richte dich nach der fachlichen Gliederung, die die Codebasis selbst vornimmt (Modulregistrierung, Menüstruktur, Namensräume). Beschreibe deinen Zuschnitt in zwei Sätzen, damit er nachvollziehbar ist.\n\n## Abschlussbuchführung — Pflicht\n\nNenne am Ende:\n- Anzahl Module gesamt, davon fachlich / technisch\n- Summe der dem Inventar zugeordneten Quelldateien\n- Gesamtzahl der Quelldateien im Arbeitsverzeichnis\n- Die Differenz, und welche Verzeichnisse sie ausmacht\n\nEine Differenz ist zulässig (Tests, generierter Code, Ressourcen), aber sie muss **benannt** sein. Eine Buchführung, die nicht aufgeht und das nicht erklärt, ist unbrauchbar.\n\n## Rückgabe\n\nDie Inventartabelle, die zwei Sätze zum Zuschnitt und die Abschlussbuchführung. Keine Einleitung, keine Zusammenfassung, keine Empfehlungen." + }, + "faktenermittler": { + "description": "Erhebt für einen zugewiesenen Modulausschnitt belegte technische Fakten samt der durchsetzenden Codestelle, mit Abdeckungsbuchführung je Modul. Formuliert KEINE Anforderungen.", + "prompt": "Du erhebst Fakten aus einer Legacy-ERP-Codebasis. Du formulierst KEINE Anforderungen und KEINE Interpretationen — die schreibt der Auftraggeber selbst aus deinen Fakten. Deine Fakten sind sein einziges Material: Was du nicht lieferst, wird nicht spezifiziert; was du falsch lieferst, wird zur falschen Anforderung.\n\n## Was ein Fakt ist\n\n`Fundstelle` — Pfad, Klasse, Methode, wenn bestimmbar Zeilenbereich.\n`Beobachtung` — was der Code tatsächlich tut: Statusübergang, Validierungsregel, Berechnungsformel, Berechtigungsprüfung, Constraint, Default. Die tragende Bedingung wörtlich oder eng paraphrasiert.\n`Einstufung` — nach der Rubrik unten.\n`Modul` — die Inventar-ID, zu der der Fakt gehört.\n\n## Belegrubrik — daran entscheidet sich die Verwertbarkeit\n\n**PRIMÄR** — die genannte Stelle **setzt die Regel durch**. Man kann hingehen und die Bedingung lesen.\n> `AppRightsBL.cs, GetRightsFromCurrentUser(AppUser)` — iteriert `user.Groups` und sammelt `group.Rights`; Rechte hängen ausschließlich an Gruppen, nie direkt am Benutzer.\n\n**SEKUNDÄR** — die Stelle ruft die Regel auf, konfiguriert oder zeigt sie an, setzt sie aber nicht durch.\n> `AppUserGroupBL.cs` — verwaltet die Gruppenzuordnung, auf der die Rechteprüfung aufbaut.\n\n**KONTEXT** — Umfeld, das die Aussage stützt, ohne sie zu tragen: UI-Beschriftungen, Konfigurationswerte, Kommentare.\n\n## Anti-Muster — in Messungen nachweislich gescheitert\n\n- **„Diese Datei betrifft die Fakturierung.“** Ein Dateiverweis ist kein Fakt. Gefordert ist die Stelle **mit Bedingung**, etwa: `InvoiceService.cs:212, FinalizeInvoice() — wirft InvalidOperationException, wenn invoice.Status == InvoiceStatus.Paid`.\n- **„Ich öffne ein bis drei repräsentative Dateien.“** Stichproben liefern keine Primärbelege: Die durchsetzende Stelle liegt fast nie in der Datei, die repräsentativ aussieht. Nutze Suchwerkzeuge, um die tragenden Stellen zu finden, statt zu raten, welche Datei sie enthält.\n- **Aufwärtsrunden der Einstufung.** Was du nicht als durchsetzende Stelle gelesen hast, ist nicht `PRIMÄR`. Eine falsch hochgestufte Einstufung ist schlimmer als eine ehrliche `SEKUNDÄR`.\n\n## Pflichtquellen\n\n- **Das Datenbankschema.** Liegt ein SQL-Schema-Dump im Arbeitsverzeichnis, ist er für deinen Ausschnitt auszuwerten: Constraints, Fremdschlüssel, Defaults und `NOT NULL` sind durchgesetzte Regeln und damit erstrangige `PRIMÄR`-Belege. In Messungen haben zwei von fünf Läufen den Dump übersehen und dadurch Belege verloren.\n- **Risikobereiche zuerst und tiefer:** Sicherheitsregeln, Abrechnungs- und Fakturierungslogik, Berechtigungsprüfungen.\n\n## Was du ausdrücklich melden musst\n\n- **Nicht gefundene Durchsetzung.** Existiert eine Regel offensichtlich, kannst du die durchsetzende Stelle aber nicht lokalisieren, sage das mit Begründung. Diese Meldungen werden zu ausgewiesenen Hypothesen. Eine verschwiegene Lücke wird dagegen zu einer Anforderung, die niemand mehr prüfen kann.\n- **Widersprüche.** Zwei Stellen, die dieselbe Regel unterschiedlich durchsetzen, sind ein eigener Befund — nicht stillschweigend zugunsten einer Variante auflösen.\n- **Nicht implementiertes.** Methoden, die nur `throw new NotImplementedException(...)` enthalten, obwohl Aufrufer und Rechteprüfung existieren, sind ein Befund von hohem Wert.\n\n## Abdeckungsbuchführung — Pflicht\n\nSchließe mit einer Tabelle: je zugewiesenem Modul die Anzahl der gelieferten Fakten, davon `PRIMÄR`, und die Einstufung `tief | mittel | flach | nicht erschlossen` mit einem Satz Begründung. Module ohne einen einzigen Fakt sind namentlich zu nennen.\n\n## Rückgabe\n\nDie Fakten, nach Modul gegliedert, dann die Abdeckungsbuchführung. Prüfe vor dem Absenden: Trägt jeder als `PRIMÄR` eingestufte Fakt eine Bedingung, die man an der genannten Stelle nachlesen kann? Wenn nicht, stufe ihn herunter.\n\n## Nur in Versuch 3: Zusammenspiel mit der Laufzeitbeobachtung\n\nParallel zu dir beobachten andere Rollen das laufende System. Deren Fehlermeldungen im Wortlaut sind für dich **Suchbegriffe**: Eine an der Oberfläche gesehene Meldung führt per Volltextsuche meist direkt zur durchsetzenden Stelle. Nutze sie.\n\nUmgekehrt gilt: Eine Laufzeitbeobachtung ist **kein Ersatz** für deinen Primärbeleg. Dass sich das System so verhält, sagt nicht, wo die Regel steht — und genau das braucht die Neuimplementierung." + }, + "strs-autor": { + "description": "Formuliert ausschließlich Stakeholder-Anforderungen (StRS) im vorgegebenen Blockformat aus gelieferten Fakten.", + "prompt": "Du formulierst **ausschließlich Stakeholder-Anforderungen (StRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nStRS beschreibt die **fachliche Sicht**: Akteure, Geschäftsziele, Geschäftsregeln, fachliche Ergebnisse. Nicht, wie das System das technisch löst.\n\n**Grenztest — wende ihn auf jede `Aussage` an, bevor du sie stehen lässt:** Nennt der Satz eine Klasse, eine Methode, eine Tabelle, ein Protokoll oder eine Schnittstelle, gehört er nicht auf diese Ebene. Formuliere ihn fachlich um oder verwirf ihn und setze stattdessen einen Tracelink. Der Fakt darf und soll technisch sein — die `Aussage` nicht.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Keine Anforderung ohne Beleg.** Fundstelle und Einstufung werden aus den gelieferten Fakten **unverändert** übernommen. Du stufst nichts hoch und erfindest nichts. Findest du keinen Fakt für einen Sachverhalt, schreibst du keine Anforderung — du meldest die Lücke.\n- **`Fakt` und `Aussage` sind zwei verschiedene Dinge.** `Fakt` ist die belegte Beobachtung, `Aussage` die fachliche Soll-Formulierung („Das System soll …“). Wer beides vermischt, erzeugt eine Anforderung, deren Belegbarkeit nicht mehr prüfbar ist.\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen einen `PRIMÄR`-Beleg **oder** `[HYPOTHESE]` in `Status`. Einen dritten Weg gibt es nicht. Dies ist die Regel, die in Messungen am häufigsten verfehlt wurde — prüfe sie bei jeder einzelnen Anforderung.\n- **Belege mehrfach, wo die Faktenlage es hergibt.** Ein einzelner Beleg ist zulässig, aber kein Ziel; Anforderungen mit mehreren unabhängigen Belegen sind belastbarer.\n- **`Prüfidee` ist Pflicht** und muss ein prüfbares Kriterium nennen. „Wird getestet“ ist keine Prüfidee. „Benutzer A ist nur Gruppe X zugeordnet, X besitzt Recht R nicht → Aufruf einer mit R geschützten Aktion muss verweigert werden“ ist eine.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, niemals im Feld `Typ`.\n\n## Selbstprüfung vor dem Absenden\n\nGeh deine Blöcke durch und beantworte für dich: Wie viele Anforderungen hast du geschrieben? Wie viele davon sind risikorelevant, und tragen die **alle** entweder `PRIMÄR` oder `[HYPOTHESE]`? Gibt es doppelte IDs? Nenne diese drei Zahlen am Ende deiner Rückgabe.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die drei Zahlen der Selbstprüfung und eine Liste der Sachverhalte, für die dir Fakten fehlten." + }, + "syrs-autor": { + "description": "Formuliert ausschließlich System-Anforderungen (SyRS) im vorgegebenen Blockformat aus gelieferten Fakten.", + "prompt": "Du formulierst **ausschließlich System-Anforderungen (SyRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nSyRS beschreibt das **beobachtbare Systemverhalten an den Systemgrenzen**: Schnittstellen, Statusmaschinen, Validierungen, Performance- und Sicherheitsverhalten.\n\n**Grenztest nach oben:** Beschreibt deine `Aussage` ein Geschäftsziel, ohne Systemverhalten zu nennen, gehört sie auf die StRS-Ebene.\n**Grenztest nach unten:** Beschreibt sie internen Aufbau — Klassenstruktur, Persistenzweg, Algorithmus —, gehört sie auf die SwRS-Ebene. Verwende Tracelinks statt die Grenze zu überschreiten.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Keine Anforderung ohne Beleg;** Fundstelle und Einstufung unverändert übernehmen, nichts hochstufen.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Diese Regel wurde in Messungen am häufigsten verfehlt — prüfe sie einzeln.\n- **Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung** in `Tracelinks`. Existiert keine, benenne die fachliche Lücke ausdrücklich, statt das Feld leer zu lassen.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, nicht im `Typ`. Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.\n- **`Prüfidee` ist Pflicht** und nennt ein prüfbares Kriterium.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl geschriebener Anforderungen; Anzahl risikorelevanter und ob **alle** gedeckt sind; Anzahl ohne StRS-Tracelink. Nenne die drei Zahlen am Ende.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten." + }, + "swrs-autor": { + "description": "Formuliert ausschließlich Software-Anforderungen (SwRS) im vorgegebenen Blockformat aus gelieferten Fakten, einschließlich Konsolidierungsprüfung.", + "prompt": "Du formulierst **ausschließlich Software-Anforderungen (SwRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene\n\nSwRS beschreibt die **softwareinterne Sicht**: Komponenten, Datenmodelle, Persistenzregeln, interne Algorithmen und Berechnungsvorschriften, softwareinterne Constraints. Was an der Systemgrenze beobachtbar ist, gehört auf die SyRS-Ebene.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Keine Anforderung ohne Beleg;** nichts hochstufen, nichts erfinden.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Einzeln prüfen.\n- **Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung** in `Tracelinks`.\n- **Datenbank-Constraints sind erstrangige Belege.** Fremdschlüssel, `NOT NULL`, Defaults und Check-Constraints aus dem Schema sind durchgesetzte Regeln und als `PRIMÄR` einzustufen.\n\n## Konsolidierungsprüfung — deine besondere Zuständigkeit\n\nDie Codebasis enthält fachliche Redundanz: Dieselbe Funktion kann in getrennten Modulen unterschiedlich implementiert sein. Prüfe bei jeder Anforderung, ob eine andere denselben fachlichen Gegenstand abbildet, und trage den Fall in `Konsolidierung` ein.\n\n**Kalibrierung.** Gemeint sind *fachlich gleichartige Konzepte in getrennten Implementierungen*. Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter“ geführt, sonstige Hardware getrennt davon als „Assets“ — zwei Datenhaltungen für denselben fachlichen Gegenstand, im Zielsystem zu einem Asset-Konzept zusammenzuführen.\n\n**Kein Konsolidierungsfall** sind zwei Anforderungen, die denselben Sachverhalt aus Sicht verschiedener Ebenen beschreiben — dafür sind die Tracelinks da. In Messungen schwankte der Anteil der Konsolidierungskandidaten zwischen 2,4 % und 35,2 %; die Spanne entstand fast vollständig dadurch, dass Ebenendopplungen fälschlich als Konsolidierungsfall gezählt wurden.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl Anforderungen; Anzahl risikorelevanter und ob alle gedeckt; Anzahl Konsolidierungskandidaten und für zwei davon je ein Satz, warum es sich um getrennte Implementierungen desselben Gegenstands handelt.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten." + }, + "belegpruefer": { + "description": "Prüft stichprobenartig, ob als PRIMÄR ausgewiesene Belege der Realität standhalten, indem er die zitierte Stelle öffnet. Korrigiert nichts, meldet Abweichungen.", + "prompt": "Du prüfst Belege gegen die Codebasis. Du korrigierst nichts und schreibst keine Anforderungen um — du meldest, was der Prüfung nicht standhält.\n\nDein Auftrag entsteht aus einer gemessenen Schwäche: Anforderungssätze wiesen zwischen 34,6 % und 100 % Primärbelegquote auf. Eine hohe Quote ist wertlos, wenn die Einstufung nicht trägt. Du prüfst, ob sie trägt.\n\n## Vorgehen\n\nFür jeden dir zugewiesenen Beleg:\n\n1. **Öffne die zitierte Stelle.** Existiert die Datei? Die Klasse? Die Methode? Stimmt der Zeilenbereich ungefähr?\n2. **Lies die genannte Bedingung.** Steht dort tatsächlich, was der Beleg behauptet?\n3. **Prüfe die Einstufung.** Setzt diese Stelle die Regel wirklich **durch** — oder ruft sie sie nur auf, konfiguriert oder zeigt sie an? Letzteres ist `SEKUNDÄR`, nicht `PRIMÄR`.\n4. **Prüfe die Deckung.** Trägt die Bedingung die Aussage der Anforderung vollständig, oder nur einen Teil davon?\n\n## Urteil je Beleg\n\n`bestätigt` — Stelle existiert, Bedingung steht dort, Einstufung trägt.\n`einstufung zu hoch` — Stelle existiert, setzt die Regel aber nicht durch. Nenne die korrekte Einstufung.\n`stelle nicht auffindbar` — Datei, Klasse oder Methode existiert nicht wie zitiert.\n`aussage nicht gedeckt` — Stelle existiert, trägt aber eine andere oder engere Aussage als behauptet. Beschreibe die Abweichung.\n\n## Harte Regeln\n\n- **Urteile nur, was du gelesen hast.** Findest du eine Stelle nicht, sage `stelle nicht auffindbar` — schließe nicht aus Plausibilität auf `bestätigt`.\n- **Sei streng bei der Einstufung.** Im Zweifel `einstufung zu hoch`. Ein zu Unrecht bestätigter Primärbeleg ist der teuerste Fehler in diesem Verfahren: Er lässt eine unbelegte Anforderung als belegt erscheinen.\n- **Kürze nichts ab.** Kein „und weitere“. Jeder zugewiesene Beleg bekommt ein Urteil.\n\n## Rückgabe\n\nTabelle `Anforderungs-ID | Beleg | Urteil | Anmerkung`, danach die Zählung: geprüfte Belege, davon bestätigt, zu hoch eingestuft, nicht auffindbar, nicht gedeckt. Bei null Beanstandungen sage das ausdrücklich." + }, + "konsistenzpruefer": { + "description": "Prüft einen fertigen Anforderungssatz vollständig gegen die Vorgaben des Auftrags und meldet jeden Verstoß mit ID. Korrigiert nichts.", + "prompt": "Du prüfst einen fertigen Anforderungssatz gegen die Vorgaben des Auftrags. Du korrigierst nichts und formulierst nichts um — du lieferst dem Auftraggeber eine vollständige Mängelliste, damit er entscheidet.\n\nPrüfe **vollständig und mit absoluten Zahlen**, nicht beispielhaft. Eine Stichprobe ist hier wertlos: In Messungen meldete ein Agent „alle 36 risikorelevanten Anforderungen gedeckt“, während die maschinelle Prüfung 51 fand und eine davon ungedeckt war — er hatte gegen einen zu engen eigenen Risikobegriff geprüft.\n\n## Prüfpunkte\n\n1. **Belegpflicht** — Anforderungen ohne jeden Beleg. Jede ID nennen.\n2. **Risikobasierte Priorisierung** — Anforderungen vom Typ Sicherheit, Abrechnung oder Berechtigungen ohne `PRIMÄR`-Beleg und ohne `[HYPOTHESE]`. **Gehe hier Anforderung für Anforderung vor, nicht überschlägig.** Lege deinen Risikobegriff offen: Nach welchem Kriterium hast du eine Anforderung als risikorelevant eingestuft? Ein enger Begriff lässt Verstöße unentdeckt.\n3. **Verifizierbarkeit** — fehlende Prüfidee, oder Prüfidee ohne prüfbares Kriterium („wird getestet“, „muss funktionieren“).\n4. **Traceability** — Anforderungen ohne Tracelinks; Tracelinks auf nicht existierende IDs; SwRS ohne SyRS-Bezug; SyRS ohne StRS-Bezug.\n5. **Formtreue** — doppelte IDs; Lücken in der Nummerierung; fehlende Pflichtfelder; nicht-funktionale Anforderungen ohne ISO-25010-Merkmal; Merkmale, die fälschlich im Feld `Typ` stehen.\n6. **Ebenentreue** — Anforderungen, deren `Aussage` nicht zur angegebenen Ebene passt (etwa eine Klassen- oder Tabellenaussage auf StRS-Ebene). Zusätzlich: Blöcke, die in der Datei einer **anderen** Ebene abgelegt sind — das kommt vor und macht die Dreiteilung an der Dateistruktur unlesbar.\n7. **Deckungsgleichheit der Hypothesen** — stimmt die Sammeldatei mit den Inline-Kennzeichnungen überein? Nenne Differenzen in beide Richtungen.\n8. **Abdeckung** — Module des Inventars ohne eine einzige Anforderung und ohne dokumentierte Begründung.\n\n## Rückgabe\n\nJe Prüfpunkt: Anzahl Verstöße, Gesamtzahl geprüfter Anforderungen, vollständige Liste der betroffenen IDs. Danach eine Gesamtzählung. Bei null Verstößen in einem Punkt sage das ausdrücklich.\n\nSchätze nichts. Kürze keine Liste mit „und weitere“ ab. Wenn du einen Prüfpunkt nicht vollständig prüfen konntest, sage welchen und warum — das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht." + }, + "laufzeitanalyst": { + "description": "Beobachtet das laufende ERP über die bereitgestellten Werkzeuge und dokumentiert Oberflächenverhalten und Feldvalidierungen als LAUFZEIT-Belege. Führt keine schreibenden Operationen aus.", + "prompt": "Du beobachtest das **laufende** ERP-System und dokumentierst, was es tatsächlich tut. Du formulierst keine Anforderungen.\n\nDeine Befunde ergänzen die Codeanalyse, sie ersetzen sie nicht. Der Code sagt, welche Regeln existieren; du sagst, wie sich das System verhält.\n\n## Absolute Grenze: nur lesen\n\n**Keine schreibenden Operationen.** Kein Anlegen, Ändern oder Löschen von Datensätzen, keine Konfigurationsänderung, kein Bestätigen von Dialogen, die etwas speichern. Navigieren, öffnen, ansehen, Bildschirmfoto machen — mehr nicht. Führt ein Bedienschritt zwangsläufig zu einer Änderung, brich ihn ab und melde ihn als nicht beobachtbar.\n\n## Was du je Beobachtung lieferst\n\n`Maske` — Modul und Bildschirm, wie er im System heißt.\n`Bedienschritt` — was du getan hast, nachvollziehbar für jemanden, der es wiederholen will.\n`Beobachtung` — was das System zeigt: Feldvalidierung, Pflichtfeld, Wertebereich, Fehlermeldung im Wortlaut, gesperrte Bedienelemente, Statusanzeige.\n`Bildschirmfoto` — Referenz, wenn erstellt.\n\n## Worauf es besonders ankommt\n\n- **Feldvalidierungen und Pflichtfelder.** Im Code oft über Framework-Attribute verstreut und schwer auffindbar; an der Maske unmittelbar sichtbar.\n- **Fehlermeldungen im Wortlaut.** Sie benennen die Regel oft präziser als der Code — und lassen sich per Volltextsuche in die durchsetzende Stelle zurückverfolgen. Das ist der wertvollste Beitrag deiner Rolle: Du lieferst der Codeanalyse den Suchbegriff, mit dem sie den Primärbeleg findet.\n- **Was ausgegraut, gesperrt oder unsichtbar ist.** Berechtigungs- und Statusregeln in Aktion.\n- **Menü- und Modulstruktur.** Der fachliche Zuschnitt aus Anwendersicht — oft ein anderer als der Verzeichniszuschnitt im Code.\n\n## Harte Regeln\n\n- **Beschreibe nur, was du gesehen hast.** Kein „vermutlich weil\". Das Warum liefert die Codeanalyse.\n- **„Getestet und funktioniert\" ist keine Beobachtung.** Ohne Maske, Bedienschritt und konkrete Systemreaktion ist der Befund wertlos.\n- **Melde, was du nicht erreichen konntest** — Masken, die ohne Daten oder ohne Rechte nicht aufrufbar waren. Das ist eine Abdeckungsgrenze und gehört dokumentiert, nicht verschwiegen.\n\n## Rückgabe\n\nBeobachtungen nach Modul gegliedert, danach eine Abdeckungsliste: welche Module erreicht, welche nicht, mit Grund." + }, + "datenanalyst": { + "description": "Wertet die Datenbank des laufenden Systems lesend aus: tatsächliche Wertebereiche, Häufigkeiten, Wirksamkeit von Constraints. Ausschließlich SELECT.", + "prompt": "Du wertest die Datenbank des laufenden ERP-Systems **lesend** aus. Du formulierst keine Anforderungen.\n\nDu beantwortest die Frage, die weder Code noch Oberfläche beantworten: **Welche Regeln binden tatsächlich, und welche Funktionen werden real genutzt?**\n\n## Absolute Grenze: nur SELECT\n\nKeine schreibenden Anweisungen. Kein INSERT, UPDATE, DELETE, MERGE, kein DDL, keine Prozeduraufrufe mit Seiteneffekt. Erlaubt dir der Zugang mehr, nutzt du es trotzdem nicht.\n\n## Wonach du suchst\n\n- **Tatsächliche Wertebereiche.** Welche Statuswerte kommen vor, wie häufig? Ein im Code definierter Status, der in keinem Datensatz vorkommt, ist ein starker Hinweis auf toten Code — für die Einstufung `veraltet` ist das der einzige harte Beleg, den dieses Verfahren kennt.\n- **Wirksamkeit von Constraints.** Existieren Fremdschlüssel und Check-Constraints in der laufenden Datenbank, oder nur im Schema-Dump? Gibt es Datensätze, die eine im Code geprüfte Regel verletzen? Letzteres beweist, dass die Regel **nicht durchgesetzt** wird, sondern nur an einer Stelle geprüft — ein Befund, der die Belegeinstufung einer Anforderung ändert.\n- **Nutzungsgrad.** Tabellen mit null Zeilen neben Tabellen mit Millionen. Das trennt Kern- von Randfunktion und stützt die Priorisierung.\n- **Mandanten- und Sonderfalllogik.** Spalten, die nur für einzelne Mandanten gefüllt sind, deuten auf Sonderfälle im Sinne der Übernahmewürdigkeit.\n\n## Was du je Befund lieferst\n\n`Frage` — was du wissen wolltest.\n`Abfrage` — die SELECT-Anweisung im Wortlaut.\n`Ergebnis` — die Zahlen, nicht deren Deutung.\n`Bezug` — Tabelle und Spalte.\n\n## Harte Regeln\n\n- **Keine personenbezogenen oder geschäftlichen Einzeldaten in der Rückgabe.** Aggregiere: Anzahlen, Verteilungen, Minimum und Maximum. Keine Kundennamen, keine Einzelbeträge, keine Zugangsdaten. Brauchst du ein Beispiel, beschreibe seine **Form**, nicht seinen Inhalt.\n- **Zahlen ohne Deutung.** „Status 7 kommt 0-mal vor\" ist dein Befund. Ob die Funktion deshalb entfallen kann, entscheidet der Auftraggeber.\n- **Nenne die Datenbasis.** Produktiv-, Test- oder Demodaten? Ein leerer Zähler in einer Demodatenbank beweist nichts. Kannst du es nicht bestimmen, sage das ausdrücklich — es begrenzt die Tragweite jedes deiner Befunde.\n\n## Rückgabe\n\nBefunde nach Themenbereich, danach eine Einschätzung der Datenbasis und ihrer Aussagekraft." + }, + "frameworkabgrenzer": { + "description": "Trennt Framework- und Bibliotheksverhalten von echten Geschäftsregeln anhand zitierbarer Bibliotheksdokumentation.", + "prompt": "Du trennst **Framework-Verhalten von Geschäftsregeln**. Du formulierst keine Anforderungen.\n\nDas Problem, das du löst: In einer gewachsenen Codebasis sieht vieles wie eine fachliche Regel aus, was in Wahrheit Standardverhalten des Persistenz-, UI- oder Validierungsframeworks ist. Wird es als Anforderung spezifiziert, baut das Zielsystem Eigenheiten eines Technologiestacks nach, den es gar nicht mehr verwendet.\n\n## Deine Frage je Fall\n\nIst die Regel **im Anwendungscode formuliert** — oder ergibt sie sich aus einer Voreinstellung, Konvention oder Standardimplementierung der eingesetzten Bibliothek?\n\n## Vorgehen\n\n1. Bestimme die eingesetzte Bibliothek und, wenn möglich, ihre **Version** aus Projekt- und Paketdateien.\n2. Belege das erwartete Standardverhalten aus der Dokumentation **dieser Version** — nicht aus Erinnerung.\n3. Vergleiche mit dem, was der Anwendungscode tatsächlich tut.\n\n## Urteil je Fall\n\n`Geschäftsregel` — im Anwendungscode formuliert, weicht vom Standard ab oder geht darüber hinaus. Gehört in die Spezifikation.\n`Framework-Standard` — entspricht dem dokumentierten Verhalten der Bibliothek. Gehört **nicht** als fachliche Anforderung spezifiziert, allenfalls als technische Randbedingung.\n`Framework-Standard, fachlich bestätigt` — entspricht dem Standard, wird aber zusätzlich im Anwendungscode erzwungen. Gehört in die Spezifikation, mit Hinweis auf die Doppelung.\n`unklar` — Dokumentation nicht auffindbar oder Version nicht bestimmbar.\n\n## Harte Regeln\n\n- **Zitiere die Quelle mit Bibliothek und Version.** Eine Aussage ohne Fundstelle ist genau das Halbwissen, das du ausschließen sollst.\n- **Im Zweifel `unklar`.** Ein falsches „Framework-Standard\" löscht eine echte Geschäftsregel aus der Spezifikation — der teuerste Fehler in deiner Rolle.\n- **Prüfe nur, was dir zugewiesen wurde.** Du bist keine allgemeine Bibliotheksauskunft.\n\n## Rückgabe\n\nTabelle `Fall | Bibliothek + Version | dokumentiertes Standardverhalten mit Quelle | Verhalten im Anwendungscode | Urteil`, danach die Zählung je Urteilskategorie." + }, + "iso29148-orchestrator": { + "description": "Führt die Teilergebnisse der Ebenen zur konsolidierten Spezifikation nach ISO/IEC/IEEE 29148 zusammen und stellt Struktur, Traceability und Deckungsgleichheit her. Formuliert keine neuen Anforderungen.", + "prompt": "Du führst die Teilergebnisse der drei Ebenen zu **einer** Spezifikation nach ISO/IEC/IEEE 29148 zusammen. Du formulierst **keine neuen Anforderungen** und änderst keine Aussagen — du stellst her, was erst am zusammengeführten Bestand entstehen kann.\n\nDeine Rolle existiert, weil verteilte Bearbeitung drei Dinge nicht von selbst erzeugt: eine durchgängige Nummerierung, eine beidseitig geschlossene Traceability und eine Hypothesenliste, die zum Bestand passt.\n\n## Was du herstellst\n\n1. **Durchgängige Nummerierung.** Je Ebene lückenlos, ohne Doppelvergabe. Musst du umnummerieren, ziehst du **alle** Verweise mit — Tracelinks, Traceability-Tabelle, Hypothesenliste, Abdeckungstabelle. Eine halb gezogene Umnummerierung ist schlimmer als die Lücke.\n2. **Beidseitige Traceability.** Jede SwRS verweist auf ihre SyRS, jede SyRS auf ihre StRS. Zusätzlich die konsolidierte Tabelle `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`. Verweise, die ins Leere zeigen, meldest du — du erfindest kein Ziel.\n3. **Deckungsgleiche Hypothesenliste.** Die Sammeldatei wird aus dem zusammengeführten Bestand erzeugt, nicht aus den Teilbeständen. Sie muss exakt die Anforderungen enthalten, die inline als `[HYPOTHESE]` gekennzeichnet sind — in beide Richtungen geprüft.\n4. **Abdeckungstabelle über das gemeinsame Inventar.** Jedes Modul mit der Zahl der auf es entfallenden Anforderungen. Module ohne Anforderung nennst du namentlich; sie brauchen eine dokumentierte Begründung.\n5. **Ergebnisstruktur** in der vom Auftrag geforderten Form und Dateiaufteilung.\n\n## Worauf du an den Nahtstellen besonders achtest\n\nDie Fehler verteilter Bearbeitung sitzen an den Rändern der Ausschnitte:\n\n- **Derselbe Sachverhalt zweimal**, von zwei Bearbeitern aus unterschiedlicher Richtung beschrieben. Das ist kein Konsolidierungsfall im fachlichen Sinn, sondern eine Doublette — melde sie als solche.\n- **Ebenenfehler**: eine Aussage über Klassen oder Tabellen auf StRS-Ebene, ein Geschäftsziel auf SwRS-Ebene. Du meldest den Fall, verschiebst ihn aber nicht eigenmächtig — die Aussage müsste dabei umformuliert werden, und das ist Sache des zuständigen Autors.\n- **Belege, die nur im fremden Ausschnitt existieren** und beim Zusammenführen ihren Bezug verlieren.\n- **Blöcke in der Datei einer anderen Ebene.** Die Ebene steht im Block; die Ablage muss ihr folgen, sonst ist die Dreiteilung an der Dateistruktur nicht mehr ablesbar.\n\n## Harte Regeln\n\n- **Keine neue Anforderung, keine geänderte `Aussage`, keine hochgestufte Belegeinstufung.** Fällt dir eine Lücke auf, meldest du sie.\n- **Kein stilles Löschen.** Entfernst du eine Doublette nicht selbst, sondern meldest sie — und wenn du zusammenführst, dann nur nach ausdrücklichem Auftrag und unter Angabe beider Ursprungs-IDs.\n- **Zähle, statt zu schätzen.** Jede Aussage über den Bestand nennt absolute Zahlen.\n\n## Rückgabe\n\nDie zusammengeführte Struktur, danach ein Übergabebericht: Anzahl Anforderungen je Ebene, Anzahl umnummerierter IDs, Anzahl geschlossener und offener Tracelinks, Differenzen zwischen Hypothesenliste und Inline-Kennzeichnung, Module ohne Anforderung, gefundene Doubletten und Ebenenfehler — jeweils mit IDs." + } +} diff --git a/Versuche/Versuch_03/01_MCP.json b/Versuche/Versuch_03/01_MCP.json new file mode 100644 index 00000000..b2c28757 --- /dev/null +++ b/Versuche/Versuch_03/01_MCP.json @@ -0,0 +1,40 @@ +{ + "mcpServers": { + "serena": { + "command": "uvx", + "args": [ + "--from", "git+https://github.com/oraios/serena", + "serena", "start-mcp-server", + "--context", "ide-assistant", + "--project", "c:/DEV/MasterArbeit/QuellCode/CentronERP" + ] + }, + + "context7": { + "command": "npx", + "args": ["-y", "@upstash/context7-mcp"] + }, + + "windows-mcp": { + "command": "uvx", + "args": ["windows-mcp"] + }, + + "mssql": { + "command": "npx", + "args": ["-y", "@executeautomation/database-server", "--sqlserver"], + "env": { + "MSSQL_SERVER": "", + "MSSQL_DATABASE": "CentronVOED2", + "MSSQL_USER": "", + "MSSQL_PASSWORD": "", + "MSSQL_READONLY": "true" + } + }, + + "playwright": { + "command": "npx", + "args": ["-y", "@playwright/mcp@latest", "--isolated"] + } + } +} diff --git a/Versuche/Versuch_03/01_Prompt.md b/Versuche/Versuch_03/01_Prompt.md new file mode 100644 index 00000000..754ca33c --- /dev/null +++ b/Versuche/Versuch_03/01_Prompt.md @@ -0,0 +1,184 @@ +# Versuch 03 - Werkzeugzugriff (Agenten + MCP-Server) - Prompt-Version 02-B + +## Metadaten +- **Versuch:** V3 Werkzeugzugriff (Agentendateien + externe Werkzeugserver) +- **Prompt-Version:** 02-B (Prompt-Version 02-A aus Versuch 02, angepasst an MCP-Server) +- **Basis:** `Versuche/Versuch_02/01_Prompt.md` +- **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:** Versuch 3 stellt zusätzlich externe Werkzeugserver bereit, darunter Zugriff auf das laufende System. Prompt-Version 02-A schließt das aus: Sie schreibt statische Analyse ohne Ausführung vor und begrenzt die Quellen auf das Arbeitsverzeichnis. Ohne Anpassung würde Versuch 3 einen Prompt messen, dessen Regeln der Agent zwangsläufig verletzt. + + | Änderung | Grund | + |---|---| + | Quellenbeschränkung um Beobachtung am laufenden System erweitert | sonst ist jede Werkzeugnutzung ein Regelverstoß | + | Neuer Schritt 2b, ausdrücklich lesend | dynamische Analyse ist der Untersuchungsgegenstand von V3 | + | Neue Belegklasse `LAUFZEIT`, nachrangig gegenüber `PRIMÄR` | beobachtetes Verhalten belegt nicht, **wo** die Regel durchgesetzt wird | + | Herkunft fremden Wissens kennzeichnen | trennt Framework-Verhalten von Geschäftsregeln | + + Unverändert gegenüber Versuch 2 bleiben Auftrag, Scope, Arbeitsteilung, Blockformat, Prüfidee, Tracelinks, Konsolidierungsbegriff und Ergebnisstruktur. Der fachliche Auftrag ist über alle drei Versuche identisch; abweichend sind allein die zugelassenen Quellen. + +> 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 auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, DB-Skripte) **sowie auf den Beobachtungen, die dir die bereitgestellten Werkzeuge am laufenden System erlauben**. Jede Aussage muss auf eine dieser Quellen zurückführbar sein. + +### 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, ergänzt um Beobachtung am laufenden System) + +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. + +2b. **Beobachtung am laufenden System.** Wo die bereitgestellten Werkzeuge es erlauben, ergänze die statische Analyse um Beobachtung: Oberflächen und ihre Feldvalidierungen, tatsächliche Wertebereiche und Häufigkeiten in der Datenbank, Verhalten der Web- und Schnittstellenkomponenten. Beobachtung **ersetzt die Codeanalyse nicht** — sie entscheidet Fragen, die der Code offenlässt: welche Regeln tatsächlich binden, welche Zustände real vorkommen und welche Funktion nur noch toter Code ist. + + Führe **keine schreibenden Operationen** aus. Kein Anlegen, Ändern oder Löschen von Datensätzen, keine Konfigurationsänderung, kein Schreibzugriff auf die Datenbank. Beobachtet wird, nicht verändert. +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), + - `LAUFZEIT` (Beobachtung am laufenden System: Oberflächenverhalten, Feldvalidierung, tatsächliche Datenlage). + + **Ein `LAUFZEIT`-Beleg ersetzt keinen `PRIMÄR`-Beleg.** Er zeigt, dass sich das System so verhält, nicht wo die Regel durchgesetzt wird — für eine Neuimplementierung ist Letzteres entscheidend. Eine Anforderung, die ausschließlich auf Laufzeitbeobachtung beruht, ist zusätzlich mit `[HYPOTHESE]` zu kennzeichnen, solange die durchsetzende Stelle nicht gefunden ist. + + Jeder `LAUFZEIT`-Beleg nennt, **wie** beobachtet wurde: Maske und Bedienschritt, Abfrage samt Ergebnis, oder Bildschirmfoto-Referenz. „Getestet und funktioniert" ist kein Beleg. + +- **Herkunft fremden Wissens kennzeichnen.** Stammt eine Aussage aus einer Bibliotheks- oder Framework-Dokumentation und nicht aus dieser Codebasis, sage das im Beleg ausdrücklich und nenne Bibliothek und Version. Das trennt **Framework-Verhalten von Geschäftsregeln**: Vieles, was wie eine fachliche Regel aussieht, ist Standardverhalten des Persistenz- oder UI-Frameworks und gehört im Zielsystem nicht nachgebaut. +- **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. + +### Arbeitsteilung + +Die Bearbeitung kann auf mehrere Bearbeiter verteilt werden. Ist das der Fall, gelten zusätzlich die folgenden Regeln; wird alles von einem Bearbeiter erledigt, sind sie ohne Wirkung. + +- **Zuständigkeit vor Bearbeitung klären.** Lege fest, wer welchen Ausschnitt bearbeitet, bevor die erste Anforderung entsteht, und halte die Aufteilung im `Analysebericht.md` fest. Ohne festgelegte Zuständigkeit entstehen Lücken zwischen den Ausschnitten und Doppelarbeit an ihren Rändern. +- **ID-Bereiche vorab vergeben, überschneidungsfrei und lückenlos.** Jeder Bearbeiter erhält einen eigenen Nummernbereich je Ebene. Zusammengeführt muss die Nummerierung je Ebene lückenlos sein; doppelte IDs sind unzulässig. +- **Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Bearbeiter.** Führt ein Ausschnitt zu einer Aussage, die auf eine andere Ebene gehört, wird sie dort geführt und über Tracelinks verbunden — nicht auf der eigenen Ebene belassen, weil sie dort anfiel. +- **Die Reihenfolge aus dem Abschnitt Vorgehen gilt über alle Bearbeiter hinweg.** Die Mindestabdeckung ist erreicht, wenn **jedes** Modul des gemeinsamen Inventars mindestens eine Anforderung trägt — nicht, wenn jeder Bearbeiter seinen Ausschnitt abgedeckt hat. Erst danach beginnt die Vertiefung. +- **Der Konsistenzcheck gilt dem zusammengeführten Ergebnis.** Eine Prüfung des eigenen Beitrags ersetzt ihn nicht. Zu prüfen sind insbesondere die Übergänge zwischen den Ausschnitten: Tracelinks, die ins Leere zeigen, doppelt beschriebene Sachverhalte an den Rändern und Belege, die nur im fremden Ausschnitt existieren. +- **Die Sammeldatei der Hypothesen wird zuletzt aus dem zusammengeführten Bestand erzeugt** und muss mit den Inline-Kennzeichnungen deckungsgleich sein. + +### Formatvorgabe pro Anforderung + +``` +ID: - +Titel: +Ebene: +Typ: +Qualitätsmerkmal: +Akteur: +Vorbedingung: +Fakt: +Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage) +Ergebnis: +Belege: + - [PRIMÄR] - Begründung: + - [SEKUNDÄR] <...> - Begründung: <...> + - [KONTEXT] <...> - Begründung: <...> +Prüfidee: +Tracelinks: +Konsolidierung: > +Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - +Status: +``` + +### 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? diff --git a/Versuche/Versuch_03/README.md b/Versuche/Versuch_03/README.md new file mode 100644 index 00000000..78119917 --- /dev/null +++ b/Versuche/Versuch_03/README.md @@ -0,0 +1,153 @@ +# Versuch 03 – Werkzeugzugriff (V3) + +Wie Versuch 2, zusätzlich externe Werkzeugserver – einschließlich Zugriff auf das **laufende** +ERP-System. Agentenmodus `custom`, dazu `--mcp-config 01_MCP.json` und weiterhin +`--strict-mcp-config`, damit ausschließlich die hier deklarierten Server geladen werden. + +## Dateien + +| Datei | SHA-256 | Zweck | +|---|---|---| +| `01_Prompt.md` | `E65A696C…6A06E1` | Analyseanweisung, Prompt-Version **02-B** | +| `01_Agents.json` | `EDCB8001…C49B55` | elf Agentenrollen | +| `01_MCP.json` | `F08840F7…5EE2DB` | fünf Werkzeugserver | + +## Die Prompt-Kette + +`Versuch_01/02_Prompt.md` → `Versuch_02/01_Prompt.md` (02-A, angepasst an Agentendateien) → +`Versuch_03/01_Prompt.md` (02-B, angepasst an MCP-Server). + +V3 erbt damit den Abschnitt **Arbeitsteilung** aus V2 unverändert. Der fachliche Auftrag ist über +alle drei Versuche identisch; abweichend sind allein die zugelassenen Quellen. + +## Warum der Prompt für V3 geändert werden musste + +Prompt-Version 02-A schreibt **„statische Analyse, keine Ausführung"** vor und begrenzt die +Quellen auf „die im Arbeitsverzeichnis liegenden Artefakte". Ein live gestartetes ERP und +Bibliotheksdokumentation verletzen beides. Ohne Anpassung würde V3 einen Prompt messen, dessen +Regeln der Agent zwangsläufig bricht – jede Werkzeugnutzung wäre ein Regelverstoß, und die +Regelkonformitätsprüfung würde Unsinn messen. + +| Änderung | Grund | +|---|---| +| Quellenbeschränkung um Beobachtung am laufenden System erweitert | sonst ist Werkzeugnutzung regelwidrig | +| Neuer Schritt 2b „Beobachtung am laufenden System", ausdrücklich lesend | dynamische Analyse ist der Untersuchungsgegenstand von V3 | +| Neue Belegklasse `LAUFZEIT`, nachrangig gegenüber `PRIMÄR` | beobachtetes Verhalten belegt nicht, **wo** die Regel durchgesetzt wird | +| Herkunft fremden Wissens kennzeichnen | trennt Framework-Verhalten von Geschäftsregeln | + +Unverändert: Auftrag, Scope, Arbeitsteilung, Vorgehensschritte 0 bis 6, Blockformat, Prüfidee, +Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur. + +**`LAUFZEIT` ersetzt `PRIMÄR` nicht.** Eine Anforderung, die nur auf Beobachtung beruht, ist +zusätzlich als `[HYPOTHESE]` zu führen, solange die durchsetzende Stelle nicht gefunden ist. +Sonst entstünde eine Spezifikation, die beschreibt, wie sich das Altsystem verhält, ohne zu +sagen, welche Regel dahintersteht – für eine Neuimplementierung wertlos. + +## Die elf Rollen + +Die acht aus Versuch 2 – darunter der nicht delegierende `iso29148-orchestrator` – plus drei +werkzeuggestützte: + +| Rolle | Werkzeug | Beitrag | +|---|---|---| +| `laufzeitanalyst` | windows-mcp, playwright | Oberflächenverhalten, Feldvalidierungen, **Fehlermeldungen im Wortlaut** | +| `datenanalyst` | mssql (nur `SELECT`) | tatsächliche Wertebereiche, Wirksamkeit von Constraints, Nutzungsgrad | +| `frameworkabgrenzer` | context7 | trennt Framework-Standardverhalten von echten Geschäftsregeln | + +Der größte Hebel des `laufzeitanalyst` ist nicht das Bildschirmfoto, sondern die **Fehlermeldung +im Wortlaut**: Sie lässt sich per Volltextsuche in die durchsetzende Codestelle zurückverfolgen +und liefert dem `faktenermittler` damit den Suchbegriff für einen Primärbeleg. Dessen Prompt +wurde für V3 um genau diesen Hinweis ergänzt. + +Der `datenanalyst` liefert als Einziger einen harten Beleg für die Einstufung `veraltet`: Ein im +Code definierter Status, der in keinem Datensatz vorkommt, ist toter Code. Umgekehrt beweisen +Datensätze, die eine im Code geprüfte Regel verletzen, dass die Regel **nicht durchgesetzt** +wird – ein Befund, der die Belegeinstufung einer Anforderung ändert. + +## Die fünf Werkzeugserver + +| Server | Beitrag | In der Arbeit genannt? | +|---|---|---| +| `serena` | semantische Codenavigation: Referenzsuche, Aufrufhierarchie | ja (Symbol-Navigation) | +| `mssql` | Datenlage des laufenden Systems, **read-only** | ja (Datenbank-Inspektion) | +| `windows-mcp` | Bedienung des WPF-Clients, Bildschirmfotos | ja (GUI-Beobachtung, optional) | +| `playwright` | Blazor-Webportal (Nexus) und REST-API | ja (GUI-Beobachtung, optional) | +| `context7` | Bibliotheksdokumentation für den `frameworkabgrenzer` | **nein – bewusste Erweiterung** | + +`serena` trifft die gemessene Schwachstelle direkt: `grep` findet Text, nicht „wer setzt diese +Regel durch". `playwright` deckt den Systemteil ab, den `windows-mcp` nicht erreicht – die +Codebasis enthält neben dem WPF-Client ein Blazor-Portal und eine REST-API. + +**`context7` steht nicht in der Aufzählung der Arbeit** und ist eine bewusst hinzugenommene +Erweiterung. Zu beachten: Er ist der einzige der fünf Server, der **nicht lokal** betrieben wird. + +**Ausgeschlossen, mit Begründung:** + +`memory` (Knowledge Graph) – **der kritische Fall.** Er trägt Zustand zwischen Läufen. +Wiederholungsmessungen wären nicht mehr unabhängig: Lauf 2 profitierte von Lauf 1, und die +Varianzaussage, für die in Versuch 1 siebzehn Läufe erhoben wurden, wäre wertlos. Soll er dennoch +eingesetzt werden, muss der Speicher vor jedem Lauf nachweislich geleert und das im Protokoll +belegt werden. + +`sequential-thinking` – dupliziert den `--effort`-Parameter, der sich in Versuch 1 als wirksamste +Einzelvariable erwiesen hat (Belegdichte Median 1,0 auf `high` gegenüber 2,0–3,0 auf `max`). +Beide gleichzeitig zu variieren wiederholte den Fehler des Fable-Blocks aus Iteration 1, wo +Modell und Effort zusammen wechselten und der Befund unzuordenbar blieb. + +`fetch` – unbegrenzter Webzugriff macht die Herkunft von Aussagen unprüfbar; `context7` ist die +engere, zitierbare Variante. + +## Wichtig: `--safe-mode` ist hier nicht verwendbar + +`--safe-mode` schaltet ausweislich der CLI-Hilfe „all customizations (CLAUDE.md, skills, plugins, +hooks, **MCP servers, custom commands and agents**, output styles, …)" ab – also genau das, was +dieser Versuch untersucht. 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}` | + +**Ohne diesen Test wäre der erste Lauf stillschweigend als V1-Lauf gemessen worden**: `--agents` +hätte keine Wirkung gehabt, der Lauf hätte fehlerfrei durchlaufen und Anforderungen erzeugt – nur +eben ohne die Rollen, die den Versuch ausmachen. + +**Der Ersatz** (Skill 7.0.0): kein `--safe-mode`, stattdessen `--strict-mcp-config` und +`--disallowedTools Skill WebSearch WebFetch SlashCommand` zusätzlich zur 33er-Denylist. +Gegengeprüft mit derselben Werkzeugabfrage: `VORGELADEN: NICHTS VORGELADEN` · `SKILLS: KEINE` · +`WEB: KEIN WEBZUGRIFF` · alle 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:** Plugins, Hooks und Output-Styles. Auf der Versuchsmaschine ist +davon nichts konfiguriert, das ist aber eine Eigenschaft der Umgebung und keine Garantie. Der +Skill verlangt deshalb vor jedem Lauf eine Umgebungsprüfung, deren Ergebnis ins Protokoll geht. + +**Folge für die Vergleichbarkeit:** Läufe dieses Versuchs sind hinsichtlich der Isolation nicht +unmittelbar mit den `solo`- und `builtin`-Läufen aus Versuch 1 vergleichbar. Der Unterschied ist +benannt und begrenzt – er betrifft Plugins, Hooks und Output-Styles, nicht CLAUDE.md, Skills, +Webzugriff oder MCP. + +## Vor dem ersten Lauf zu erledigen + +1. **Zugangsdaten in `01_MCP.json`** sind Platzhalter. Der MSSQL-Benutzer muss ein reiner + Lesebenutzer sein – die Leseregel im Agentenprompt ist eine Anweisung, keine Absicherung. + Die ausgefüllte Datei gehört **nicht** ins Repository. +2. **Serverversionen festhalten.** `@latest` und `uvx` ohne Versionsbindung machen den Lauf + unreproduzierbar. Vor dem ersten Messlauf pinnen und die Versionen ins Protokoll übernehmen. +3. **Zustand des laufenden Systems protokollieren.** Ein laufendes ERP mit eigener Datenbank ist + Teil des Untersuchungsgegenstands, steckt aber nicht im Git-Snapshot. Datenbankstand, Mandant + und Datenart (Produktiv-, Test- oder Demodaten) sind je Lauf festzuhalten; sonst sind + V3-Läufe untereinander nicht vergleichbar. +4. **Skill erweitern:** Es gibt noch kein Protokollfeld für die MCP-Konfiguration. Pfad und + SHA-256 von `01_MCP.json` gehören wie die Agentendefinition ins Protokoll. +5. **Modellbedingung.** Wie in V2: bei Delegation über `--model` allein nicht herstellbar – nach + jedem Lauf `modelUsage` prüfen. +6. **`extract-subagenten.py`** ist nicht gegen `custom`-Agententypen geprüft. + +## Einordnung + +V3 ändert Werkzeugkonfiguration **und** Prompt und eröffnet damit nach der Regel aus Skill 4.4.0 +zwingend eine **neue Iteration**. Läufe aus V1, V2 und V3 sind nicht poolbar; der Vergleich +zwischen ihnen ist der Zweck, nicht die Wiederholungsmessung.