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) <noreply@anthropic.com>
This commit is contained in:
Christoph Schwörer
2026-08-27 08:03:00 +02:00
co-authored by Claude Opus 5
parent affde3a45f
commit 3d5b691bfa
89 changed files with 39498 additions and 104 deletions
@@ -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.*
@@ -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.
@@ -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}
@@ -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 %) |
@@ -0,0 +1,177 @@
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
## Metadaten
- **Versuch:** V1 Baseline (Prompt-only)
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-26
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
| Änderung | Auslösender Befund |
|---|---|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
---
## Prompt
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
### Auftrag
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
### Vorgehen (statische Analyse, keine Ausführung)
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
### Pflicht-Eigenschaften jeder Anforderung
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
- **Belegklassifikation:** Kennzeichne jeden Beleg als
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
### Formatvorgabe pro Anforderung
```
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
Titel: <kurzer Titel>
Ebene: <StRS | SyRS | SwRS>
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
Akteur: <Rolle / System / Komponente>
Vorbedingung: <Zustand vor Auslösen>
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
Belege:
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
- [SEKUNDÄR] <...> - Begründung: <...>
- [KONTEXT] <...> - Begründung: <...>
Prüfidee: <Akzeptanzkriterium oder Testidee>
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
Status: <belegt | HYPOTHESE>
```
### Traceability
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
### Nicht-funktionale Anforderungen
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
### Konsolidierungsbedarf
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
```
Ergebnisse/
StRS.md
SyRS.md
SwRS.md
Traceability.md (oder Traceability.csv)
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
Selbstbewertung, bekannte Lücken)
```
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
---
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
Kommandozeilenbefehlen im Arbeitsverzeichnis.
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
Werkzeuge zu ersetzen.
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-opus-5\solo\high\02_Lauf_2026-08-26_195958_v7.0.0-e7e6\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
2026-08-26T20:31:17.3017181+02:00
@@ -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).
@@ -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`.*
@@ -0,0 +1,141 @@
# Hypothesen
Diese Datei enthält **genau** die Anforderungen, die in `StRS.md`, `SyRS.md` und `SwRS.md` mit
`Status: HYPOTHESE` und der Inline-Markierung `[HYPOTHESE]` gekennzeichnet sind — keine weiteren
freien Fragen. Offene Punkte ohne zugehörige Anforderung sind in der Selbstbewertung des
`Analysebericht.md` (Abschnitt 5) aufgeführt.
**Anzahl: 5** von 360 Anforderungen (1,4 %).
---
## SyRS-005 — Mehrstufige Preisquellen mit definierter Rangfolge
| | |
|---|---|
| **Ebene** | SyRS |
| **Typ** | funktional |
| **Übernahmewürdigkeit** | übernehmen |
**Belegte Beobachtung:** Es bestehen mindestens vier konkurrierende Preisquellen — `ActionPriceBL`
(Aktionspreise), `ArticleVolumePricesBL` (Staffelpreise), kundenbezogene Sonderpreise
(`Accounts/SpecialPrices/`, `CustomerSpecialArticleBL`) und `ProductMatrixBL`. Die Zusammenführung
erfolgt in `ReceiptItemBL` (4.290 Zeilen) und `ReceiptPriceHelperBL` (130 Zeilen).
**Offene Frage:** In welcher Rangfolge werden die vier Preisquellen ausgewertet, und welche gewinnt
bei gleichzeitiger Gültigkeit?
**Was zur Bestätigung fehlt:** Eine zeilenweise Auswertung der Preisermittlung in `ReceiptItemBL`
bis zu der Bedingung, die die Quelle auswählt. In dieser Analyse wurde nur die API-Oberfläche der
beteiligten Klassen erfasst, nicht der Entscheidungspfad.
**Warum als Hypothese geführt:** Die Preisfindung ist abrechnungsrelevant. Ohne benannte
durchsetzende Stelle darf die Aussage nach der Regel zur risikobasierten Priorisierung nicht als
belegt geführt werden.
---
## SyRS-055 — Ticketabschluss trotz offener RMA
| | |
|---|---|
| **Ebene** | SyRS |
| **Typ** | funktional |
| **Übernahmewürdigkeit** | übernehmen |
**Belegte Beobachtung:** `HelpdeskCloseBL.CanCloseHelpdesk(int helpdeskI3D)` (Zeilen 159-167)
enthält ausschließlich eine Nichtnull-Prüfung des Parameters, den Kommentar
`//Todo: if rma exists check if finished` und die Rückgabe `true`. Die Methode ist damit die
vorgesehene, aber leere Prüfstelle.
**Offene Frage:** Soll der Abschluss eines Tickets bei einem offenen RMA-Vorgang verhindert werden?
**Was zur Bestätigung fehlt:** Eine fachliche Aussage darüber, ob die im Kommentar vermerkte Regel
gewollt ist oder bewusst nicht umgesetzt wurde. Aus den Artefakten ist nur ersichtlich, dass sie
vorgesehen war.
**Warum als Hypothese geführt:** Der Kommentar belegt eine Absicht, nicht eine durchgesetzte Regel.
---
## SyRS-151 — Nicht implementierte Löschpfade im Datenschutzmodul
| | |
|---|---|
| **Ebene** | SyRS |
| **Typ** | Sicherheit |
| **Übernahmewürdigkeit** | übernehmen |
**Belegte Beobachtung:** `DataSecurityBL.DoDeleteCustomer(int i3d, bool isReferenceDelete)` wirft
`new NotImplementedException("DoDeleteCustomer is not ready for use!")` (Zeile 856-858);
`DoDeleteSupplier` ist analog angelegt. In `DsgvoDeleteRightDeleteContacts` sind die Aufrufe für
Kunde, Lieferant, Kontaktmanagement-Kontakt und Account auskommentiert (Zeilen 803-814), ebenso die
zugehörigen Anonymisierungs-SQL-Anweisungen (Zeilen 863-903).
**Offene Frage:** Warum sind die Löschpfade für vollständige Geschäftspartner deaktiviert — aus
fachlichen Bedenken wegen der Referenzintegrität zu Belegen, oder weil die Entwicklung nicht
abgeschlossen wurde? Und wie wird ein Löschbegehren, das einen ganzen Geschäftspartner betrifft,
heute bearbeitet?
**Was zur Bestätigung fehlt:** Eine fachliche Festlegung, welche Datensätze bei einem Löschbegehren
zu anonymisieren sind und welche aus handels- und steuerrechtlichen Aufbewahrungsgründen erhalten
bleiben müssen.
**Warum als Hypothese geführt:** Die Anforderung ist datenschutzrechtlich zwingend, im heutigen
Stand aber nachweislich nicht erfüllt. Sie wird als offener Punkt geführt, nicht als belegte
Systemeigenschaft.
---
## SwRS-055 — Sammelabschluss von Tickets aus der Wartung
| | |
|---|---|
| **Ebene** | SwRS |
| **Typ** | funktional |
| **Übernahmewürdigkeit** | übernehmen |
**Belegte Beobachtung:** `HelpdeskCloseBL.CloseHelpdesk(IList<HelpdeskCompact> helpdesks, AppUser currentUser)`
(Zeilen 108-118) führt ausschließlich die benannte Abfrage
`NamedQueryEnums.Helpdesk.CloseHelpdesksFromMaintenance` mit dem Abschlussstatus und einer Liste von
IDs aus und gibt stets `Result.AsSuccess()` zurück. Die beim Einzelabschluss
(`CloseHelpdesk(AppUser, int helpdeskI3D, …)`) ausgeführten Folgeaktionen — Löschen der zugehörigen
Aufgaben, Historieneintrag `HelpdeskHistoryType.Close`, Kundenaktivität, Benachrichtigung —
unterbleiben.
**Offene Frage:** Ist das Auslassen der Folgeaktionen beim Sammelabschluss fachlich gewollt (etwa
weil es sich um eine reine Datenbereinigung handelt), oder handelt es sich um eine Lücke in der
Nachvollziehbarkeit?
**Was zur Bestätigung fehlt:** Die Aufrufstellen des Sammelabschlusses und die fachliche Absicht des
Wartungsvorgangs. Der Name der benannten Abfrage („FromMaintenance") deutet auf eine Bereinigung
hin, belegt sie aber nicht.
**Warum als Hypothese geführt:** Der Sammelabschluss verändert Ticketzustände ohne Protokolleintrag.
Ob das zulässig ist, lässt sich aus den Artefakten nicht entscheiden.
---
## SwRS-085 — Bankzugangsdaten der finAPI-Anbindung
| | |
|---|---|
| **Ebene** | SwRS |
| **Typ** | Sicherheit |
| **Übernahmewürdigkeit** | übernehmen |
**Belegte Beobachtung:** `Centron.APIs.FinAPI/Data/` modelliert `AccessToken`, `Account`,
`AccountCapability`, `AccountInterface`, `AccountInterfacePaymentCapabilities`, `AccountList`,
`AccountParams` und `AccountReference`. Eine Klasse für dauerhaft gespeicherte Bankzugangsdaten des
Kunden (Zugangskennung, PIN) besteht in dieser Bibliothek nicht.
**Offene Frage:** Speichert das System an anderer Stelle — etwa im Zweig `Finances/OnlineBanking` oder
in der Datenbank — Bankzugangsdaten des Kunden im Klartext oder verschlüsselt?
**Was zur Bestätigung fehlt:** Eine vollständige Durchsicht des Zweigs `Finances/OnlineBanking` sowie
eine Suche im Datenbankschema nach Feldern für Bankzugangsdaten. Die Abwesenheit einer entsprechenden
Klasse in der API-Bibliothek ist kein Beweis für die Abwesenheit im Gesamtsystem.
**Warum als Hypothese geführt:** Die Aussage ist sicherheitsrelevant und stützt sich auf das Fehlen
eines Artefakts, nicht auf eine durchgesetzte Regel. Ein Negativbefund aus einer Teilmenge trägt die
Aussage nicht.
@@ -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<LoggedInUser>.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<AutomaticFacturaCustomer>().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<int> customerI3Ds, List<int> 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<int> customerI3Ds, List<int> 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<int> 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<Article>().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<HelpdeskCompact>, 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<IEDIReceiptHead>` und `List<List<IEDIReceiptItems>>` |
| 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<IEDIReceiptHead>` und `List<List<IEDIReceiptItems>>` |
| 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<LoggedInUser>.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<LoggedInUser>.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<LoggedInUser>.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<int> receiptProjectLayoutItemI3DsToForward` und `CreateFullReportForReceipt` mit `IList<ReceiptProjectLayoutItem> 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<Article>().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<HelpdeskCompact>, 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<string>`, 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<Article>().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<IEDIReceiptHead>` und `List<List<IEDIReceiptItems>>` |
| 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<int> 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<AccountAddressContact, AccountAddressContactDTO>(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<TReceipt, TReceiptItem>(AppUser, ForwardReceiptData, IList<ReceiptToForward>, IList<int>, 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<InvoiceLock> _lockBL;` |
| — | SyRS-015 | SwRS-015 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `ForwardReceipt<TReceipt, TReceiptItem>(AppUser, ForwardReceiptData, IList<ReceiptToForward>, IList<int>, 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<int> receiptProjectLayoutItemI3DsToForward` und `CreateFullReportForReceipt` mit `IList<ReceiptProjectLayoutItem> 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**
@@ -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.
@@ -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 %) |
@@ -0,0 +1,177 @@
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
## Metadaten
- **Versuch:** V1 Baseline (Prompt-only)
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-26
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
| Änderung | Auslösender Befund |
|---|---|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
---
## Prompt
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
### Auftrag
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
### Vorgehen (statische Analyse, keine Ausführung)
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
### Pflicht-Eigenschaften jeder Anforderung
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
- **Belegklassifikation:** Kennzeichne jeden Beleg als
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
### Formatvorgabe pro Anforderung
```
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
Titel: <kurzer Titel>
Ebene: <StRS | SyRS | SwRS>
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
Akteur: <Rolle / System / Komponente>
Vorbedingung: <Zustand vor Auslösen>
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
Belege:
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
- [SEKUNDÄR] <...> - Begründung: <...>
- [KONTEXT] <...> - Begründung: <...>
Prüfidee: <Akzeptanzkriterium oder Testidee>
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
Status: <belegt | HYPOTHESE>
```
### Traceability
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
### Nicht-funktionale Anforderungen
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
### Konsolidierungsbedarf
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
```
Ergebnisse/
StRS.md
SyRS.md
SwRS.md
Traceability.md (oder Traceability.csv)
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
Selbstbewertung, bekannte Lücken)
```
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
---
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
Kommandozeilenbefehlen im Arbeitsverzeichnis.
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
Werkzeuge zu ersetzen.
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-opus-5\solo\high\02_Lauf_2026-08-26_225807_v7.0.0-2269\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
2026-08-27T00:24:02.3040325+02:00