Gowler/Masterarbeit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Lots of runs

Browse Source
This commit is contained in:
Christoph Schwörer
2026-08-26 16:37:24 +02:00
parent f349d189c7
commit 844b4e5569
823 changed files with 198980 additions and 125 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/Analysebericht.md
+388
View File
@@ -0,0 +1,388 @@
# Analysebericht
Iteration 02 · c-entron ERP-Suite · 2026-08-26
## 0. Vorgehen dieser Iteration
Gemäß Prompt-Vorgabe wurde vor der ersten Anforderung ein vollständiges Modulinventar erstellt (Abschnitt 1). Jedes Modul erhielt danach mindestens eine Anforderung (Mindestabdeckung, Abschnitt 2), bevor einzelne Module vertieft wurden. Die Vertiefung (Schritt 0c) konzentrierte sich auf Sicherheit, Berechtigungen sowie Abrechnungs-/Fakturierungslogik: Rechtesystem (`AppRightsBL`, `Sichtrus`/`Sichmemb`), Authentifizierung (`BasicAuthenticator`, Zwei-Faktor), Passwortverwaltung, Mahnwesen/OPOS, Rechnungssperren und lizenzgesteuerte Module.
Als Werkzeuge standen in diesem Lauf ausschließlich Dateisuche/-lektüre und Kommandozeilenbefehle im Arbeitsverzeichnis zur Verfügung (keine Subagenten, keine externen Werkzeugserver). Die Tiefe der Belege variiert entsprechend: Für Risikobereiche wurde der tatsächliche Kontrollfluss gelesen (PRIMÄR-fähig), für die Breite wurden Klassennamen/Methodensignaturen aus Verzeichnislisten und kurzen Dateiauszügen herangezogen (überwiegend SEKUNDÄR).
## 1. Modulinventar
Bezugsgröße: gesamte Codebasis (`C:\DEV\MasterArbeit\QuellCode\CentronERP`). Granularität: fachliche/technische Einheiten auf Ebene der Top-Level-Ordner unterhalb der jeweiligen Assembly (primär `Centron.BL`, da dort die fachliche Logik der übrigen Schichten gebündelt ist). Pfade sind relativ zum Arbeitsverzeichnis.
### 1.1 Fachliche Kernmodule (`src/backend/Centron.BL`)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M001 | Accounting | `src/backend/Centron.BL/Accounting` | Bankkontenverwaltung für Kunden (`BankAccountBL`). |
| M002 | Accounts | `src/backend/Centron.BL/Accounts` | Kunden-/Lieferantenstammdaten, Adressen, Kontakte, Aktivitäten, Marketing, Sonderpreise, Hotline-Zuordnung. |
| M003 | Administration | `src/backend/Centron.BL/Administration` | Systemverwaltung: Mandanten/Filialen, Rechte, Lizenzierung, Datensicherheit/DSGVO, Firmendaten, Mitarbeiterverwaltung, Dateiverwaltung, Einstellungen. |
| M004 | AppointmentRequests | `src/backend/Centron.BL/AppointmentRequests` | Terminanfragen per Mail an Kunden inkl. Antwortverarbeitung (`AppointmentRequestBL`). |
| M005 | ArtificialIntelligence | `src/backend/Centron.BL/ArtificialIntelligence` | KI-Anbindung (OpenAI-kompatible API) für Chat, Ticketkategorisierung, Textbewertung. |
| M006 | BusinessPartner | `src/backend/Centron.BL/BusinessPartner` | Lieferantensuche und lieferantenseitige Asset-Zuordnung. |
| M007 | Buying | `src/backend/Centron.BL/Buying` | Einkaufslogik, externe Anbindungen (`Buying/External`). |
| M008 | CPra | `src/backend/Centron.BL/CPra` | Anbindung an externen Cloud-Provisioning-Dienst c-pra.c-entron.de. |
| M009 | Calendar | `src/backend/Centron.BL/Calendar` | Kalenderdarstellungseinstellungen (Helpdesk-Zeitanzeige). |
| M010 | CentronIcons | `src/backend/Centron.BL/CentronIcons` | Verwaltung von Icon-Ressourcen inkl. Webservice-Bereitstellung. |
| M011 | CentronNexus (BL) | `src/backend/Centron.BL/CentronNexus` | Konfigurationseinstellungen für die Anbindung an das Nexus-Portal. |
| M012 | ChangeTracking | `src/backend/Centron.BL/ChangeTracking` | Änderungshistorie von Objekten (`History`). |
| M013 | Chats | `src/backend/Centron.BL/Chats` | Interner Chat zwischen Mitarbeitern/Kundenbezug. |
| M014 | CheckListArea | `src/backend/Centron.BL/CheckListArea` | Checklisten-Verwaltung inkl. Änderungsverfolgung. |
| M015 | Core (BL) | `src/backend/Centron.BL/Core` | Kryptographie-Hilfsfunktionen (Passwort-Hash/Salt), Textersetzung. |
| M016 | CountryArea | `src/backend/Centron.BL/CountryArea` | Länder- und Bundesländerstammdaten. |
| M017 | CustomerArea | `src/backend/Centron.BL/CustomerArea` | Branchen, Kontaktaktivitäten, Interessen, RMA-Zuordnung. |
| M018 | Customizations | `src/backend/Centron.BL/Customizations` | Kundenspezifische Zusatztabellen (`CustomTables`). |
| M019 | DataExchange | `src/backend/Centron.BL/DataExchange` | Datenaustausch: Buchhaltungsexport, Zahlungsverkehr, DocuForm, GFK-Export, Import, RMM, Tanss, TelekomDive. |
| M020 | Devices | `src/backend/Centron.BL/Devices` | Geräte-/Asset-Konten der Kunden. |
| M021 | DocuBoard | `src/backend/Centron.BL/DocuBoard` | Asset-Management (Partner, Artikelzuordnung, AD-Systembenutzer-Ausschluss). |
| M022 | DocumentationArea | `src/backend/Centron.BL/DocumentationArea` | Freitext-Dokumentation zu Objekten. |
| M023 | EDI | `src/backend/Centron.BL/EDI` | Elektronischer Datenaustausch mit Lieferanten (ALSO, Alltron, AlsoCH, EGIS, Komsa, Concerto, Opentrans, Zugferd). |
| M024 | EmployeeArea | `src/backend/Centron.BL/EmployeeArea` | Mitarbeiter-/Benutzerkonten, Abteilungen, Urlaub, RFID-Token, Skills. |
| M025 | ExpectedEvents | `src/backend/Centron.BL/ExpectedEvents` | Erwartete wiederkehrende Ereignisse je Wochentag (SLA-/Monitoring-Fristen). |
| M026 | ExternalHelpdesk | `src/backend/Centron.BL/ExternalHelpdesk` | Konfiguration externer Helpdesk-Anbindungen. |
| M027 | ExternalToolsBL | `src/backend/Centron.BL/ExternalToolsBL` | Einbindung externer Werkzeuge in die Oberfläche. |
| M028 | Finances (BL) | `src/backend/Centron.BL/Finances` | Zahlungseingänge, Onlinebanking-Anbindung, Zahlungen, Produktlebenszyklus. |
| M029 | GUI | `src/backend/Centron.BL/GUI` | Oberflächenprofile, benutzerspezifische Grid-Einstellungen, Import. |
| M030 | Gateway (BL) | `src/backend/Centron.BL/Gateway` | Individuelle Gateway-Importe (u. a. Sonderartikel-zu-Vertrag). |
| M031 | Helpers | `src/backend/Centron.BL/Helpers` | Technische Hilfsfunktionen (PDF, Bild, Word, Strings, Logging). |
| M032 | IndexSearch | `src/backend/Centron.BL/IndexSearch` | Volltextsuche (Ticket-, Kontenindex) auf Basis eigener Indexer. |
| M033 | Integrations | `src/backend/Centron.BL/Integrations` | Zwischenspeicherung von Rollen/Kundengruppen einer externen „ElectronicSales"-Anbindung. |
| M034 | ItPlanner | `src/backend/Centron.BL/ItPlanner` | Kategorien für Checklisten-Objekte. |
| M035 | Logistics | `src/backend/Centron.BL/Logistics` | Logistikeinstellungen, Lagerbezug (`LogisticSettings`, `Warehousing`). |
| M036 | Mail | `src/backend/Centron.BL/Mail` | E-Mail-Versand/-Vorlagen, Exchange-Anbindung, Blacklist, Variablenersetzung. |
| M037 | MailScanner | `src/backend/Centron.BL/MailScanner` | Automatisierte Mail-Verarbeitung als Workflow-Prozess, rechtegeschützt. |
| M038 | Mailings | `src/backend/Centron.BL/Mailings` | Mailing-/Kampagnendaten und -vorlagen. |
| M039 | MassUpdate | `src/backend/Centron.BL/MassUpdate` | Massenaktualisierung von Datensätzen über mehrere Fachbereiche. |
| M040 | Mobile | `src/backend/Centron.BL/Mobile` | Datenbereitstellung für mobile Mitarbeiter-/Kontaktanwendung. |
| M041 | Modules | `src/backend/Centron.BL/Modules` | Verwaltung der Anwendungsmodule/-kategorien inkl. Selbstregistrierung. |
| M042 | MyCentron | `src/backend/Centron.BL/MyCentron` | Persönlicher Arbeitsbereich: Dashboard, Notizen, Terminplanung. |
| M043 | MyDay | `src/backend/Centron.BL/MyDay` | Tagesübersicht und Benachrichtigungen je Mitarbeiter. |
| M044 | NexusNotifications | `src/backend/Centron.BL/NexusNotifications` | Benachrichtigungs-Hub für das Nexus-Portal. |
| M045 | NexusTicketViews | `src/backend/Centron.BL/NexusTicketViews` | Persönliche/geteilte Ticketansichten für Nexus-Nutzer. |
| M046 | Notifications | `src/backend/Centron.BL/Notifications` | Zentrale Systembenachrichtigungen. |
| M047 | ObjectExternalReferences | `src/backend/Centron.BL/ObjectExternalReferences` | Verknüpfung von c-entron-Objekten mit externen Systemreferenzen. |
| M048 | Outlook | `src/backend/Centron.BL/Outlook` | Suche nach Asset-Zuordnungen für das Outlook-Add-in. |
| M049 | PasswordManagementArea | `src/backend/Centron.BL/PasswordManagementArea` | Kundenbezogene Zugangsdatenverwaltung inkl. Zugriffsprotokoll. |
| M050 | PasswordManager | `src/backend/Centron.BL/PasswordManager` | Kernlogik des internen Passwortmanagers (Kategorien, Suche). |
| M051 | Processes | `src/backend/Centron.BL/Processes` | Generische Workflow-Prozess-Engine (Shapes, Bindings). |
| M052 | ProductMatrix | `src/backend/Centron.BL/ProductMatrix` | Produktmatrix-Kategorien/-Produkte je Kunde. |
| M053 | Production | `src/backend/Centron.BL/Production` | Fertigungsaufträge, lizenzpflichtig. |
| M054 | Projects | `src/backend/Centron.BL/Projects` | Projektstammdaten. |
| M055 | Purchasing | `src/backend/Centron.BL/Purchasing` | Bestellvorschläge, Einkaufseinstellungen, Lieferantenverwaltung. |
| M056 | ReportEngine | `src/backend/Centron.BL/ReportEngine` | Report-/PDF-Generierung (FastReport), Vorlagenverwaltung, Im-/Export. |
| M057 | Reporting | `src/backend/Centron.BL/Reporting` | Verknüpfung von Reports mit Herkunftsobjekten. |
| M058 | Resources | `src/backend/Centron.BL/Resources` | Lokalisierte Zeichenketten, FTP-URL-Konstanten. |
| M059 | RiverDivo | `src/backend/Centron.BL/RiverDivo` | Web-Service-Schicht für die externe Riverbird-/RiverDivo-Anwendung. |
| M060 | Sales | `src/backend/Centron.BL/Sales` | Vertrieb: Belege (Angebote, Aufträge, Lieferscheine, Rechnungen, Mahnwesen, OPOS), Kunden, Kassenbücher, Marketing, Support. |
| M061 | Security | `src/backend/Centron.BL/Security` | PDF-Signierung (qualifizierte elektronische Signatur/Zeitstempel). |
| M062 | SelfCare | `src/backend/Centron.BL/SelfCare` | Kunden-Selfcare-Portal (Formulare, Web-Requests). |
| M063 | Services (BL) | `src/backend/Centron.BL/Services` | Cached-Table-Infrastruktur, Datenqualitätsprüfungen, Workflow-Anbindung. |
| M064 | SocialMedia | `src/backend/Centron.BL/SocialMedia` | Verarbeitung von Social-Media-Kommentaren/-Aktionen. |
| M065 | Start | `src/backend/Centron.BL/Start` | Startlogik der Anwendung. |
| M066 | Statistics | `src/backend/Centron.BL/Statistics` | Auswertungen: Konten, Verwaltung, Verträge, MSP, Bestellungen, Verkauf, Tickets. |
| M067 | Storage | `src/backend/Centron.BL/Storage` | Historische Lagerbestands-Logik – Datei besteht laut Kommentar vollständig aus auskommentiertem, obsoletem Code (ersetzt durch `InventoryBL`). |
| M068 | SystemArea | `src/backend/Centron.BL/SystemArea` | Systemweite I3D-Tabelle (technischer Systemzustand). |
| M069 | Tags | `src/backend/Centron.BL/Tags` | Tagging-Funktion, u. a. für Tickets. |
| M070 | Tapi | `src/backend/Centron.BL/Tapi` | Telefonie-Anbindung (Anruferkennung über Microsoft Graph Call Records). |
| M071 | TaskManager | `src/backend/Centron.BL/TaskManager` | Aufgabenverwaltung mit Aktions-Handlern. |
| M072 | Telemetry | `src/backend/Centron.BL/Telemetry` | Nutzungstelemetrie (u. a. MCP-Tool-Nutzung) mit Batch-Upsert. |
| M073 | TextModuleArea | `src/backend/Centron.BL/TextModuleArea` | Textbausteine für Anrede/Grußformel je Belegart. |
| M074 | TicketProjects | `src/backend/Centron.BL/TicketProjects` | Verknüpfung von Tickets zu Projekten inkl. Abhängigkeiten. |
| M075 | Time | `src/backend/Centron.BL/Time` | Zeiterfassungseinstellungen. |
| M076 | ToDoArea | `src/backend/Centron.BL/ToDoArea` | Persönliche To-Do-Verwaltung. |
| M077 | Tools | `src/backend/Centron.BL/Tools` | Textformat-Konvertierung (RTF/HTML/Plain). |
| M078 | TradePool | `src/backend/Centron.BL/TradePool` | Handelspool-Anbindung (`TradePoolBL`, `Core`). |
| M079 | Transactions | `src/backend/Centron.BL/Transactions` | Nachvollziehbare Transaktionsprotokolle je Benutzer. |
| M080 | TwoFactorAuthenticator | `src/backend/Centron.BL/TwoFactorAuthenticator` | Verwaltung/Prüfung des TOTP-Schlüssels je Benutzer. |
| M081 | Urls | `src/backend/Centron.BL/Urls` | Kurz-/Web-URL-Verwaltung. |
| M082 | VideoPortal | `src/backend/Centron.BL/VideoPortal` | Zuweisung von Video-Portal-Inhalten, rechtegeschützt. |
| M083 | VoucherManagement | `src/backend/Centron.BL/VoucherManagement` | Gutschein-/Barcode-Verwaltung. |
| M084 | Warehousing | `src/backend/Centron.BL/Warehousing` | Artikel-, Barcode-, Bestands-, Kommissionierungs- und Steuerverwaltung. |
| M085 | WebLinks | `src/backend/Centron.BL/WebLinks` | Konfigurierbare Web-Link-Aktionen (u. a. Kundenaktivitäten). |
| M086 | WebServices (BL-Fassade) | `src/backend/Centron.BL/WebServices` | Webservice-seitige Spiegelung der Fachdomänen (DTO-Mapping/-Konfiguration je Bereich), 72 Unterordner. |
| M087 | WebSuite | `src/backend/Centron.BL/WebSuite` | Web-Administrationsfunktionen (Mitarbeiter, Einstellungen) für Web-Oberflächen. |
| M088 | WebVersion | `src/backend/Centron.BL/WebVersion` | Auslesen der Webservice-Assembly-Version. |
### 1.2 Externe API-Integrationen (`src/apis`)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M089 | Centron.APIs.CopDataAccess | `src/apis/Centron.APIs.CopDataAccess` | SOAP-Anbindung an die COP-Lieferanten-Plattform (inkl. mitgelieferter API-Dokumentation). |
| M090 | Centron.APIs.EgisDataAccess | `src/apis/Centron.APIs.EgisDataAccess` | Anbindung an die EGIS-Lieferanten-API. |
| M091 | Centron.APIs.FinAPI | `src/apis/Centron.APIs.FinAPI` | Anbindung an FinAPI zur Bankkontoabfrage (Kontoauszüge). |
| M092 | Centron.APIs.ITscopeDataAccess | `src/apis/Centron.APIs.ITscopeDataAccess` | Produktdatenabfrage über die ITscope-API. |
| M093 | Centron.APIs.IcecatDataAccess | `src/apis/Centron.APIs.IcecatDataAccess` | Produktdatenabfrage über die Icecat-API. |
| M094 | Centron.Api.EbInterface | `src/apis/Centron.Api.EbInterface` | Erstellung von E-Rechnungen im österreichischen ebInterface-Format. |
| M095 | Centron.Api.Gls | `src/apis/Centron.Api.Gls` | Anbindung an den Versanddienstleister GLS. |
| M096 | Centron.Api.Shipcloud | `src/apis/Centron.Api.Shipcloud` | Anbindung an den Versanddienstleister Shipcloud. |
### 1.3 Webservice-Hostschicht (`src/webservice`)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M097 | Centron.Controllers | `src/webservice/Centron.Controllers` | REST-Controller inkl. Autorisierungs-Attributen (`AuthorizeUserRightAttribute` u. a.). |
| M098 | Centron.Host | `src/webservice/Centron.Host` | ASP.NET-Core-Hostprozess inkl. Realtime-Services. |
| M099 | Centron.Host.Console | `src/webservice/Centron.Host.Console` | Konsolen-Startprogramm des Webservice-Hosts. |
| M100 | Centron.Host.WindowsService | `src/webservice/Centron.Host.WindowsService` | Betrieb des Webservice-Hosts als Windows-Dienst. |
| M101 | Centron.WebServices.Core | `src/webservice/Centron.WebServices.Core` | Kernbibliothek für Webservice-Kommunikation (Connections, HttpClients, Messages). |
| M102 | c-entron.misc.ConnectionManager | `src/webservice/c-entron.misc.ConnectionManager` | Eigenständiges Tool zur Konfiguration von DB-/Serververbindungen. |
### 1.4 Nexus-Portal (`src/nexus`)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M103 | CentronNexus | `src/nexus/CentronNexus` | Blazor-Ticketportal/Serviceboard inkl. Dokumentensignierung und Produktionsauftragsverwaltung. |
| M104 | CentronNexus.Host | `src/nexus/CentronNexus.Host` | Hostprozess der Nexus-Blazor-Anwendung. |
| M105 | CentronNexus.OutlookAddIn | `src/nexus/CentronNexus.OutlookAddIn` | Outlook-Add-in zur Anzeige von CRM-/Belegdaten. |
### 1.5 Geteilte Infrastruktur (`src/shared`, `src/backend` Infrastruktur)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M106 | Centron.Controls | `src/shared/Centron.Controls` | Wiederverwendbare WPF-Steuerelemente mit eingebetteter Fachlogik (Checklisten, Kundenverwaltung u. a.). |
| M107 | Centron.Controls.Preview | `src/shared/Centron.Controls.Preview` | Vorschauanwendung zum isolierten Testen von Steuerelementen. |
| M108 | Centron.Core (shared) | `src/shared/Centron.Core` | Kernbibliothek: TOTP/GoogleAuthenticator, PDF-Scanning, Threading-Hilfen. |
| M109 | Centron.Common | `src/backend/Centron.Common` | Gemeinsame Konstanten, Berechnungen, Erweiterungsmethoden. |
| M110 | Centron.DAO | `src/backend/Centron.DAO` | Datenzugriffsschicht (ADO.NET, generische DAOs, Sessions). |
| M111 | Centron.Entities | `src/backend/Centron.Entities` | Persistente Entitätsklassen (ORM-Modell). |
| M112 | Centron.Gateway | `src/backend/Centron.Gateway` | Technische Gateway-Schicht für EDI-/Banking-Anbindungen. |
| M113 | Centron.Interfaces | `src/backend/Centron.Interfaces` | Schnittstellenverträge zwischen BL und übrigen Schichten. |
### 1.6 UI-Shell und Erweiterungs-Framework (`src/centron`)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M114 | Centron.WPF.UI (Shell) | `src/centron/Centron.WPF.UI` | WPF-Hauptanwendung: Anmeldung, Ribbon-Navigation, Modulregistrierung (~30 fachliche UI-Module, siehe unten). |
| M115 | Centron.WPF.UI.Extension | `src/centron/Centron.WPF.UI.Extension` | Plugin-/Erweiterbarkeitsframework für UI-Module (MVVM-Basisklassen, Commands, Extensibility). |
**Hinweis zu den UI-Modulen:** `Centron.WPF.UI/Modules` enthält 29 UI-Bereiche (Administration, ArtificialIntelligence, Calendar, DataExchange, ExternalTool, Finances, Global, Gui, Helpdesk, Logistic, Massenupdates, MyCentron, OnlineBanking, PLM, PasswordManager, PayersAndCostCenter, Production, ProjectManagement, ProjectPriceImport, Purchasing, QM, Reports, Rma, Sales, Statistics, Survey, TelekomDive, Warehousing, Dashboard), die überwiegend 1:1 die BL-Fachmodule M001–M088 als Präsentationsschicht spiegeln. Sie werden nicht als eigene Inventarzeilen geführt, sondern als Beleg (SEKUNDÄR, „UI-Spiegelung") den jeweiligen BL-Modulen zugeordnet, um Doppelzählung zu vermeiden – mit Ausnahme von M114/M115, die die UI-Schicht als Ganzes (Shell, Rechteprüfung im Client, Erweiterbarkeit) referenzieren.
### 1.7 Betrieb, Datenmodell, Referenzdokumente
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M116 | Datenbankschema | `SSMS_DB_SCHEMA.sql` | Vollständiges SQL-Server-DDL-Skript (77.660 Zeilen), Referenz für Tabellen/Constraints. |
| M117 | Rechtekatalog | `CentronRights.md` | Gepflegte fachliche Dokumentation aller Benutzerrechte inkl. einschränkender Rechte. |
| M118 | Deployment/Installer | `deployment/` (WixSharpInstaller, centron, riverbird) | Erstellung von Installationspaketen für Desktop-Anwendung und Riverbird. |
| M119 | Docker/Containerisierung | `docker/` | Container-Definitionen für API, Webservice, Mailcatcher, Regressionstest-DB. |
| M120 | CI/CD-Pipelines (Desktop) | `azure/` | Azure-Pipelines für Build/Analyse/Regressionstests der WPF-Anwendung. |
| M121 | CI/CD-Pipelines (Nexus) | `azure-blazor/` | Azure-Pipelines für Nexus inkl. dedizierter `security-pipeline.yaml`. |
| M122 | Betriebsdokumentation | `docs/` | Feature-/Betriebs-/Referenzdokumentation (Ersatz für separate Change-Historie). |
**Summe Inventar:** 122 Zeilen (M001–M122).
## 2. Abdeckungstabelle
Einstufung je Modul: `tief` (mehrere Anforderungen, PRIMÄR-Beleg für Kernregel gelesen) · `mittel` (Anforderung(en) mit mind. einem gelesenen Quelltextauszug) · `flach` (Anforderung auf Basis von Verzeichnis-/Dateinamen, kein Quelltext gelesen) · `nicht analysiert`.
| Nr | Modul | Einstufung | Anzahl Anforderungen | Bemerkung |
|---|---|---|---|---|
| M001 | Accounting | mittel | 1 | `BankAccountBL.cs` gelesen |
| M002 | Accounts | mittel | 2 | Teilbereiche gelesen (Struktur), Kernklassen nicht vollständig |
| M003 | Administration | tief | 6 | Rights, DataSecurity, Logins/Auth, Licensing gelesen |
| M004 | AppointmentRequests | mittel | 1 | `AppointmentRequestBL.cs` gelesen |
| M005 | ArtificialIntelligence | mittel | 2 | `OpenAiApiClient.cs` (Auszug) gelesen |
| M006 | BusinessPartner | mittel | 1 | `SupplierAssetBL.cs` gelesen |
| M007 | Buying | flach | 1 | nur Verzeichnisstruktur |
| M008 | CPra | mittel | 1 | `CPraConnectorBL.cs` gelesen |
| M009 | Calendar | mittel | 1 | `CalendarBL.cs` gelesen |
| M010 | CentronIcons | flach | 1 | nur Verzeichnisstruktur |
| M011 | CentronNexus (BL) | mittel | 1 | `CentronNexusBL.cs` gelesen |
| M012 | ChangeTracking | flach | 1 | nur Verzeichnisstruktur |
| M013 | Chats | mittel | 1 | `ChatBL.cs` gelesen |
| M014 | CheckListArea | mittel | 1 | `CentronChecklistBL.cs` gelesen |
| M015 | Core (BL) | tief | 1 | `CryptoUtils.cs` vollständig gelesen (Sicherheitsbefund) |
| M016 | CountryArea | mittel | 1 | `CountryBL.cs` gelesen |
| M017 | CustomerArea | flach | 1 | nur Verzeichnisstruktur |
| M018 | Customizations | flach | 1 | nur Verzeichnisstruktur |
| M019 | DataExchange | flach | 1 | nur Verzeichnisstruktur |
| M020 | Devices | mittel | 1 | `AccountDeviceBL.cs` gelesen |
| M021 | DocuBoard | mittel | 1 | `AssetManagementPartnerBL.cs` gelesen |
| M022 | DocumentationArea | flach | 1 | nur Verzeichnisstruktur |
| M023 | EDI | mittel | 1 | `EDIDispatcherBL.cs` (Auszug) gelesen |
| M024 | EmployeeArea | mittel | 2 | `AppUserBL.cs` (Auszug) gelesen |
| M025 | ExpectedEvents | mittel | 1 | `ExpectedEventsBL.cs` gelesen |
| M026 | ExternalHelpdesk | mittel | 1 | `ExternalHelpdeskConfigurationBL.cs` gelesen |
| M027 | ExternalToolsBL | flach | 1 | nur Verzeichnisstruktur |
| M028 | Finances (BL) | flach | 1 | nur Verzeichnisstruktur |
| M029 | GUI | mittel | 1 | `UserGridBL.cs` gelesen |
| M030 | Gateway (BL) | mittel | 1 | `CustomGatewayBL.cs` (Auszug) gelesen |
| M031 | Helpers | flach | 1 | nur Verzeichnisstruktur |
| M032 | IndexSearch | mittel | 1 | `IndexSearchBL.cs` (Auszug) gelesen |
| M033 | Integrations | mittel | 1 | `EsRoleBL.cs` gelesen |
| M034 | ItPlanner | mittel | 1 | `ChecklistVirtualObjectCategoryBL.cs` (Auszug) gelesen |
| M035 | Logistics | flach | 1 | nur Verzeichnisstruktur |
| M036 | Mail | flach | 1 | nur Verzeichnisstruktur |
| M037 | MailScanner | mittel | 1 | `MailScannerBL.cs` (Auszug, Rechteprüfung) gelesen |
| M038 | Mailings | flach | 1 | nur Verzeichnisstruktur |
| M039 | MassUpdate | mittel | 1 | `MassUpdateBL.cs` (Auszug) gelesen |
| M040 | Mobile | mittel | 1 | `MobileBL.cs` vollständig gelesen |
| M041 | Modules | mittel | 1 | `ModuleBL.cs` (Auszug) gelesen |
| M042 | MyCentron | flach | 1 | nur Verzeichnisstruktur |
| M043 | MyDay | flach | 1 | nur Verzeichnisstruktur |
| M044 | NexusNotifications | flach | 1 | nur Verzeichnisstruktur |
| M045 | NexusTicketViews | mittel | 1 | `NexusTicketViewBL.cs` (Auszug) gelesen |
| M046 | Notifications | mittel | 1 | `CentronNotificationsBL.cs` (Auszug) gelesen |
| M047 | ObjectExternalReferences | mittel | 1 | `ObjectExternalReferenceBL.cs` (Auszug) gelesen |
| M048 | Outlook | mittel | 1 | `OutlookAssetKindSearchBL.cs` (Auszug) gelesen |
| M049 | PasswordManagementArea | flach | 1 | nur Verzeichnisstruktur |
| M050 | PasswordManager | mittel | 1 | `PasswordManagerBL.cs` (Auszug) gelesen |
| M051 | Processes | mittel | 1 | `ProcessBL.cs` (Auszug) gelesen |
| M052 | ProductMatrix | mittel | 1 | `ProductMatrixBL.cs` (Auszug) gelesen |
| M053 | Production | tief | 1 | `ProductionOrderBL.cs` gelesen (Lizenzprüfung) |
| M054 | Projects | mittel | 1 | `ProjectBL.cs` vollständig gelesen |
| M055 | Purchasing | flach | 1 | nur Verzeichnisstruktur |
| M056 | ReportEngine | flach | 1 | nur Verzeichnisstruktur |
| M057 | Reporting | mittel | 1 | `ReportsBL.cs` (Auszug) gelesen |
| M058 | Resources | flach | 1 | nur Verzeichnisstruktur |
| M059 | RiverDivo | mittel | 1 | `RiverDivoBL.cs` (Auszug) gelesen |
| M060 | Sales | tief | 8 | Invoices, Dunning, OPOS, Lock-Mechanismus gelesen |
| M061 | Security | tief | 1 | `PdfSigningBL.cs` gelesen (Rechteprüfung, Zertifikat) |
| M062 | SelfCare | mittel | 1 | `SelfCareBL.cs` (Auszug) gelesen |
| M063 | Services (BL) | flach | 1 | nur Verzeichnisstruktur |
| M064 | SocialMedia | mittel | 1 | `SocialMediaBL.cs` (Auszug) gelesen |
| M065 | Start | flach | 1 | nur Verzeichnisstruktur |
| M066 | Statistics | flach | 1 | nur Verzeichnisstruktur |
| M067 | Storage | mittel | 1 | `StorageBL.cs` gelesen (vollständig obsolet) |
| M068 | SystemArea | mittel | 1 | `SystemTableI3DBL.cs` vollständig gelesen |
| M069 | Tags | mittel | 1 | `TagsBL.cs` (Auszug) gelesen |
| M070 | Tapi | mittel | 1 | `PhoneCallBL.cs` (Auszug) gelesen |
| M071 | TaskManager | flach | 1 | nur Verzeichnisstruktur |
| M072 | Telemetry | mittel | 1 | `TelemetryBL.cs` (Auszug, SQL-Merge) gelesen |
| M073 | TextModuleArea | mittel | 1 | `TextModuleBL.cs` (Auszug) gelesen |
| M074 | TicketProjects | mittel | 1 | `TicketProjectBL.cs` (Auszug) gelesen |
| M075 | Time | mittel | 1 | `TimingSettingsBL.cs` (Auszug) gelesen |
| M076 | ToDoArea | flach | 1 | nur Verzeichnisstruktur |
| M077 | Tools | mittel | 1 | `ToolBL.cs` (Auszug) gelesen |
| M078 | TradePool | flach | 1 | nur Verzeichnisstruktur |
| M079 | Transactions | mittel | 1 | `TransactionBL.cs` (Auszug) gelesen |
| M080 | TwoFactorAuthenticator | tief | 1 | `TwoFactorAuthenticationBL.cs` vollständig gelesen |
| M081 | Urls | mittel | 1 | `SimpleUrlBL.cs` (Auszug) gelesen |
| M082 | VideoPortal | mittel | 1 | `VideoPortalAssignmentBL.cs` (Auszug, Rechteprüfung) gelesen |
| M083 | VoucherManagement | mittel | 1 | `VoucherManagementBL.cs` vollständig gelesen |
| M084 | Warehousing | mittel | 1 | `TaxBL.cs` (Auszug) gelesen |
| M085 | WebLinks | mittel | 1 | `WebLinkBL.cs` (Auszug) gelesen |
| M086 | WebServices (BL-Fassade) | flach | 1 | nur Verzeichnisstruktur (72 Unterordner, stichprobenhaft) |
| M087 | WebSuite | flach | 1 | nur Verzeichnisstruktur |
| M088 | WebVersion | mittel | 1 | `VersionBL.cs` vollständig gelesen |
| M089 | Centron.APIs.CopDataAccess | flach | 1 | nur Verzeichnisstruktur |
| M090 | Centron.APIs.EgisDataAccess | flach | 1 | nur Verzeichnisstruktur |
| M091 | Centron.APIs.FinAPI | flach | 1 | nur Verzeichnisstruktur |
| M092 | Centron.APIs.ITscopeDataAccess | flach | 1 | nur Verzeichnisstruktur |
| M093 | Centron.APIs.IcecatDataAccess | flach | 1 | nur Verzeichnisstruktur |
| M094 | Centron.Api.EbInterface | flach | 1 | nur Verzeichnisstruktur |
| M095 | Centron.Api.Gls | flach | 1 | nur Verzeichnisstruktur |
| M096 | Centron.Api.Shipcloud | flach | 1 | nur Verzeichnisstruktur |
| M097 | Centron.Controllers | tief | 1 | `AuthorizeUserRightAttribute.cs` vollständig gelesen |
| M098 | Centron.Host | flach | 1 | nur Verzeichnisstruktur |
| M099 | Centron.Host.Console | flach | 1 | nur Verzeichnisstruktur |
| M100 | Centron.Host.WindowsService | flach | 1 | nur Verzeichnisstruktur |
| M101 | Centron.WebServices.Core | flach | 1 | nur Verzeichnisstruktur |
| M102 | c-entron.misc.ConnectionManager | flach | 1 | nur Verzeichnisstruktur |
| M103 | CentronNexus | flach | 1 | nur Verzeichnisstruktur |
| M104 | CentronNexus.Host | flach | 1 | nur Verzeichnisstruktur |
| M105 | CentronNexus.OutlookAddIn | flach | 1 | nur Verzeichnisstruktur |
| M106 | Centron.Controls | flach | 1 | nur Verzeichnisstruktur |
| M107 | Centron.Controls.Preview | flach | 1 | nur Verzeichnisstruktur |
| M108 | Centron.Core (shared) | flach | 1 | nur Verzeichnisstruktur |
| M109 | Centron.Common | flach | 1 | nur Verzeichnisstruktur |
| M110 | Centron.DAO | flach | 1 | nur Verzeichnisstruktur |
| M111 | Centron.Entities | flach | 1 | nur Verzeichnisstruktur |
| M112 | Centron.Gateway | flach | 1 | nur Verzeichnisstruktur |
| M113 | Centron.Interfaces | flach | 1 | nur Verzeichnisstruktur |
| M114 | Centron.WPF.UI (Shell) | flach | 1 | Verzeichnisstruktur, keine XAML/Code-Behind gelesen |
| M115 | Centron.WPF.UI.Extension | flach | 1 | nur Verzeichnisstruktur |
| M116 | Datenbankschema | mittel | 1 | `Sichtrus`/`Sichmemb`/`Sichrech`-DDL gelesen |
| M117 | Rechtekatalog | tief | 1 | `CentronRights.md` (Auszug) gelesen |
| M118 | Deployment/Installer | flach | 1 | nur Verzeichnisstruktur |
| M119 | Docker/Containerisierung | flach | 1 | nur Verzeichnisstruktur |
| M120 | CI/CD-Pipelines (Desktop) | flach | 1 | nur Verzeichnisstruktur |
| M121 | CI/CD-Pipelines (Nexus) | flach | 1 | nur Verzeichnisstruktur (Dateiname `security-pipeline.yaml` als Indiz) |
| M122 | Betriebsdokumentation | flach | 1 | nur Verzeichnisstruktur |
**Ergebnis:** 122/122 Module mit mindestens einer Anforderung (Mindestabdeckung erreicht, keine Zeile `nicht analysiert`). Tief: 8 Module. Mittel: 46 Module. Flach: 68 Module.
**Korrektur zur Spalte „Anzahl Anforderungen":** Die obige Spalte wurde vor der eigentlichen Formulierung der Anforderungen als Planungsschätzung angelegt. Nach Fertigstellung von StRS/SyRS/SwRS liegt die tatsächliche Gesamtzahl bei 211 Anforderungen (134 StRS + 39 SyRS + 38 SwRS) statt der ursprünglich geschätzten 137. Die Abweichung entsteht, weil die risikofokussierte Vertiefung (Abschnitt 0c) für die acht „tief" eingestuften Module (M003, M015, M053, M060, M061, M080, M097, M117) deutlich mehr Anforderungen über alle drei Ebenen hervorgebracht hat als ursprünglich geschätzt – konkret u. a.: M003/Administration ≈ 20 Anforderungen (Rechtesystem, Authentifizierung, Lizenzierung, DSGVO), M060/Sales ≈ 7 (Belegprozess, Sperre, Mahnwesen/OPOS), M061/Security ≈ 4, M080/TwoFactorAuthenticator ≈ 6, M097/Controllers ≈ 4, M117/Rechtekatalog ≈ 4, M053/Production ≈ 5. Die übrigen 114 Module liegen weiterhin überwiegend bei 1–3 Anforderungen, entsprechend der „flach"/„mittel"-Einstufung. Die genaue Zuordnung ergibt sich aus den Artefaktbelegen der einzelnen Anforderungen (StRS.md/SyRS.md/SwRS.md) sowie aus `Traceability.md`; die Einstufung tief/mittel/flach je Modul bleibt unverändert gültig.
## 3. Konsistenzcheck
**Automatisiert geprüft** (Bash/grep über die finalen Dateien StRS.md, SyRS.md, SwRS.md):
- **Doppelte oder mehrfach vergebene IDs:** Keine gefunden. StRS-1…StRS-134 (134 IDs), SyRS-1…SyRS-39 (39 IDs), SwRS-1…SwRS-38 (38 IDs) sind jeweils lückenlos und eindeutig durchnummeriert.
- **Anforderungen ohne Beleg:** Keine gefunden. Jeder der 211 Anforderungsblöcke enthält mindestens eine Zeile unter `Belege:` (134/39/38 `Belege:`-Header, 135/40/38 tatsächliche `[PRIMÄR]`/`[SEKUNDÄR]`/`[KONTEXT]`-Zeilen – die Differenz ergibt sich aus Anforderungen mit zwei Belegen, z. B. StRS-130).
- **Anforderungen ohne Angabe zur `Übernahmewürdigkeit`:** Keine gefunden. 134/39/38 `Übernahmewürdigkeit:`-Zeilen entsprechen exakt der Anzahl der IDs je Datei.
- **Tracelinks auf nicht existierende IDs:** Keine gefunden. Alle 98 in `Tracelinks:`-Feldern referenzierten IDs sowie alle 23 in `Konsolidierung:`-Feldern referenzierten IDs sind in der Menge der 211 tatsächlich vergebenen IDs enthalten (per Skriptvergleich verifiziert).
- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk:** Bei der Erstellung wurden 12 Konsolidierungskandidaten explizit markiert (u. a. StRS-20/21/125 „Stammblatt"/Asset-Konsolidierung als Beispielfall aus der Aufgabenstellung, StRS-67/68 ITscope/Icecat, StRS-70/71 GLS/Shipcloud, StRS-69/134 ebInterface/ZUGFeRD, StRS-73/123 und SwRS-22 Host-Doppelbetrieb, StRS-96/SyRS-36 CryptoUtils/SHA1Decoder, StRS-90/125 Rechtekatalog/ES-Rollen, SwRS-37 OposBL/DunningBL-Methodenduplikat). Eine manuelle Vollprüfung aller 211×210 möglichen Paare auf semantische Deckungsgleichheit wurde in dieser Iteration nicht durchgeführt; verbleibende, nicht markierte Überschneidungen (z. B. zwischen StRS-2/StRS-17 im Bereich Kundenstammdaten) sind nicht auszuschließen und ein Punkt für die Folge-Iteration.
- **Status-Werte:** Ausschließlich `belegt` (180×) und `HYPOTHESE` (31×) verwendet, keine abweichenden Werte.
- **Risikorelevante Anforderungen mit `Typ: Sicherheit` und `Status: belegt` ohne `[PRIMÄR]`-Beleg:** Keine gefunden (automatisiert geprüft über alle 36 Anforderungen mit `Typ: Sicherheit`).
**Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit Belegsituation:
| ID | Titel | PRIMÄR-Beleg? | Status |
|---|---|---|---|
| StRS-72 | Rechtebasierte Autorisierung von REST-Endpunkten | ja | belegt |
| StRS-96 | Kryptographische Basisfunktionen (Passwort-Hash/Salt) | ja | belegt |
| StRS-99 | Qualifizierte elektronische PDF-Signatur | ja | belegt |
| StRS-118 | Zwei-Faktor-Schlüsselverwaltung je Benutzer | ja | belegt |
| StRS-120 | Rechtegeschützte Video-Portal-Zuweisung | ja | belegt |
| StRS-124 | Serverseitige Speicherung des KI-API-Schlüssels | ja | belegt |
| StRS-127 | Richtlinienkonformität von Passworteinträgen | nein | **HYPOTHESE** |
| StRS-128 | DSGVO-konforme Datenbereinigung | ja | belegt |
| StRS-129 | Mehrstufige Anmeldesicherheit (Zwei-Faktor-Pflicht) | ja | belegt |
| StRS-130 | Modernisierung der Passwortspeicherung | ja | belegt |
| StRS-131 | Nachvollziehbare Belegsperre bei paralleler Bearbeitung | ja | belegt |
| StRS-132 | Zugriffsschutz für Mahnwesen und offene Posten | ja | belegt |
| StRS-133 | Rechtepflicht für qualifizierte PDF-Signatur-Einstellungen | ja | belegt |
| SyRS-8 | Lizenzprüfung als systemweiter Cross-Cutting-Concern | ja | belegt |
| SyRS-19 | DSGVO-Löschprotokollierung mit Bearbeiterzuordnung | ja | belegt |
| SyRS-23 | Sperrung von Bankverbindungen ohne Autorisierung | ja | belegt |
| SyRS-24 | Rechtegeschützter Zugriff auf den Virtual-Mail-Assistant | ja | belegt |
| SyRS-25 | Rechtegeschützte Video-Portal-Zuweisung | ja | belegt |
| SyRS-27 | Named-Query-basierter Zugriff auf sicherheitsrelevante 2FA-Daten | ja | belegt |
| SyRS-28 | Serverseitige Filialbeschränkung für Rechtegruppenverwaltung | ja | belegt |
| SyRS-30 | Zeitgesteuerte Kontoaktivierung/-deaktivierung | ja | belegt |
| SyRS-31 | Rechtegeschützter Zugriff auf den Passwortmanager | nein | **HYPOTHESE** |
| SyRS-32 | Konsistente Lizenzsperre für Produktionsaufträge | ja | belegt |
| SyRS-33 | Zweistufige Autorisierung: UI-Sichtbarkeit und Server-Durchsetzung | ja | belegt |
| SyRS-34 | Verschlüsselte Speicherung von Drittanbieter-API-Schlüsseln | ja | belegt |
| SyRS-35 | Verpflichtender zweiter Faktor bei jeder Basis-Anmeldung | ja | belegt |
| SyRS-36 | Fehlende Salzung bei der Passwort-Hash-Bildung im Anmeldepfad | ja | belegt |
| SyRS-38 | Identisches Rechteprüfmuster für OPOS und Mahnwesen | ja | belegt |
| SyRS-39 | Administratorpflicht für qualifizierte Signatureinstellungen | ja | belegt |
| SwRS-19 | Named-Query-Parameter-Bindung als durchgängiges Zugriffsmuster | ja | belegt |
| SwRS-23 | AES-basierte Verschlüsselungslogik als wiederverwendbare Klasse | nein | **HYPOTHESE** |
| SwRS-32 | Zentrale Entschlüsselungsstelle unmittelbar vor externem HTTP-Aufruf | ja | belegt |
| SwRS-33 | Filter-basierte Autorisierungskomponente 401/403 | ja | belegt |
| SwRS-34 | Sequenzielle Kombination Passwort-/TOTP-Prüfung | ja | belegt |
| SwRS-35 | SHA1Decoder als zentrale, kryptographisch veraltete Hash-Komponente | ja | belegt |
| SwRS-37 | Identische Rechteprüfmethode in zwei Klassen | nein | **HYPOTHESE** |
| SwRS-38 | Verschlüsselte Speicherung TSA-Server-Passwort | ja | belegt |
Ergebnis: 32 von 36 risikorelevanten Anforderungen (88,9 %) tragen einen `PRIMÄR`-Beleg; die verbleibenden 4 sind korrekt als `[HYPOTHESE]` gekennzeichnet, keine Anforderung verstößt gegen die risikobasierte Priorisierungsregel.
**Abgleich `Hypothesen.md` gegen Inline-Markierungen:** Übereinstimmend geprüft – `Hypothesen.md` nennt exakt die 31 Anforderungen (StRS: 18, SyRS: 6, SwRS: 7), die in den drei Spezifikationsdateien mit `Status: HYPOTHESE` markiert sind (automatisiert per Skript abgeglichen, siehe Befehle in der Laufhistorie), keine zusätzlichen freien Fragen ohne zugehörige Anforderung.
## 4. Abdeckungstabelle
Siehe Abschnitt 2 (oben) – die dort geführte Tabelle ist die geforderte Abdeckungstabelle auf Basis des Modulinventars aus Schritt 0; jede Inventarzeile (M001–M122) ist darin mit Einstufung (tief/mittel/flach) und Anzahl der Anforderungen (siehe Korrekturhinweis) vertreten.
## 5. Selbstbewertung
**Tiefe der Analyse je Modul:** Von 122 Inventarmodulen wurden 8 tief (6,6 %), 46 mittel (37,7 %) und 68 flach (55,7 %) analysiert; kein Modul blieb unanalysiert. „Tief" bedeutet hier: der tatsächliche Kontrollfluss (nicht nur Signaturen) wurde gelesen und mit mindestens einer `[PRIMÄR]`-Belegstelle in einer risikorelevanten Anforderung hinterlegt. Die acht tiefen Module konzentrieren sich erwartungsgemäß auf die im Auftrag genannten Vertiefungsschwerpunkte: Sicherheitsregeln (Administration/Rights, Security/PdfSigning, TwoFactorAuthenticator, Controllers/Authorization), Abrechnungs-/Fakturierungslogik (Sales/Receipts) und Berechtigungsprüfungen (Administration/Rights, Rechtekatalog).
**Mindestabdeckung:** Erreicht – alle 122 Module besitzen mindestens eine Anforderung. Bei der Erstabfassung von StRS.md wurden 28 Module (M015, M058, M060–M083, M099, M100) zunächst versehentlich ohne eigenen StRS-Eintrag übersprungen (ein Nummerierungssprung bei der fortlaufenden Erstellung); dies wurde noch im selben Lauf durch eine Selbstprüfung erkannt und durch die Anforderungen StRS-96 bis StRS-123 korrigiert, bevor das Dokument als abgeschlossen galt. Dieser Vorfall zeigt, dass die fortlaufende Nummerierung bei einer Spezifikation dieser Größe (134 StRS-Einträge) ein reales Fehlerrisiko birgt und in einer Folge-Iteration durch eine zusätzliche automatisierte Zwischenprüfung (Soll-/Ist-Abgleich Modulinventar vs. erzeugte StRS-IDs) abgesichert werden sollte.
**Stellen mit dünnem Beleg:** 68 der 122 Module wurden ausschließlich anhand von Verzeichnis-/Dateinamen (ohne Lektüre des Methodenkörpers) beurteilt und sind entsprechend mit `SEKUNDÄR`- oder `KONTEXT`-Belegen bzw. direkt als `[HYPOTHESE]` geführt (18 der 31 Hypothesen betreffen genau solche „nur Verzeichnisstruktur gelesen"-Fälle auf StRS-Ebene). Besonders dünn belegt sind: die gesamte Deployment-/CI-CD-Infrastruktur (M118–M121, StRS-91/93/94), die Betriebsdokumentation (M122, StRS-95) sowie mehrere kleinere BL-Module, bei denen nur ein Klassenname, aber keine Methode gelesen wurde (z. B. M078/TradePool, StRS-116).
**Warum nicht null Hypothesen:** Bei einer Codebasis dieser Größe (>75 fachliche BL-Ordner allein in `Centron.BL`, 72 zusätzliche WebServices-Unterordner, 8 externe API-Projekte, ein 77.660-Zeilen-DB-Schema) und dem in diesem Lauf verfügbaren Werkzeugsatz (ausschließlich Dateisuche/-lektüre und Kommandozeile, keine Codeausführung, keine Subagenten) ist eine vollständige Tiefenlektüre aller Module in einem einzelnen Lauf nicht leistbar. 31 Hypothesen (14,7 % aller Anforderungen) sind das ehrliche Ergebnis dieser bewussten Breite-vor-Tiefe-Priorisierung, nicht ein Zeichen mangelnder Sorgfalt bei den tatsächlich gelesenen Stellen (dort: 32 von 36 risikorelevanten Anforderungen mit `PRIMÄR`-Beleg).
**Wesentlicher inhaltlicher Befund dieser Iteration:** Die Authentifizierungslogik (`BasicAuthenticator.cs`, `UsersBL.cs`) speichert und vergleicht Passwörter nachweislich über einen ungesalzenen SHA1-Hash; der Produktivcode selbst enthält dazu den Entwicklerkommentar „// TODO the password should be salted!!!“ (StRS-130, SyRS-36, SwRS-35). Dies ist der gravierendste Einzelbefund dieser Iteration und sollte bei einer Neuimplementierung vorrangig behandelt werden (Übernahmewürdigkeit: veraltet).
**Empfehlungen für eine Folge-Iteration:**
1. Vertiefung der 68 „flach" eingestuften Module, beginnend mit den größten (WebServices mit 72 Unterordnern; Statistics; ReportEngine; Mail; DataExchange; EDI-Lieferantenanbindungen ALSO/Alltron/Komsa/EGIS im Detail).
2. Verifikation der offenen Hypothesen mit größtem Risikobezug zuerst: SyRS-31 (Passwortmanager-Rechteprüfung), SwRS-37 (mögliche Code-Duplizierung OposBL/DunningBL), SwRS-23 (Beziehung CryptoControl/AESCryptoLogic).
3. Vollständige, systematische Paarvergleichsprüfung auf Konsolidierungskandidaten über alle 211 Anforderungen hinweg (in dieser Iteration nur exemplarisch, nicht vollständig durchgeführt).
4. Lektüre der bislang nur über Verzeichnisstruktur erfassten Deployment-/CI-CD-Artefakte (`azure/`, `azure-blazor/`, `deployment/`, `docker/`), da diese für die SyRS-Betriebsanforderungen der geplanten SaaS-Neuimplementierung besonders relevant sind.
5. Prüfung, ob die in StRS-96 dokumentierte, offenbar ungenutzte `CryptoUtils.CreatePasswordHash`-Implementierung tatsächlich an keiner Stelle aufgerufen wird (in dieser Iteration nur stichprobenhaft geprüft).
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/Glossar.md
+29
View File
@@ -0,0 +1,29 @@
# Glossar
Domänenbegriffe, die in den Anforderungen (StRS/SyRS/SwRS) dieser Iteration verwendet werden. Technische Bezeichner sind in ihrer Originalsprache belassen.
| Begriff | Bedeutung |
|---|---|
| **I3D** | Primärschlüssel-Konvention in der c-entron-Datenbank; nahezu jede Entität führt ein Feld `I3D` als eindeutigen Identifikator (z. B. `Session.GetGenericDAO<T>().GetById(i3D)`). |
| **Mandant / Mandantorship** | Fachlicher Betreiber-/Kundenkontext innerhalb einer c-entron-Installation; verwaltet über `MandatorBL` (`src/backend/Centron.BL/Administration/Company/MandatorBL.cs`). Eine Installation kann mehrere Mandanten führen. |
| **Filiale / Branch** | Organisatorische Untereinheit eines Mandanten; mehrere Rechte sind auf „nur eigene Filiale" einschränkbar (`BranchI3D`, siehe `CentronRights.md`). |
| **Recht / AppRight** | Einzelne Berechtigung im Rechtesystem, gespeichert in Tabelle `Sichrech`, Zuordnung zu Gruppen über `Sichtrus`; ein Benutzer erbt Rechte über seine Gruppenmitgliedschaft (`Sichmemb`). |
| **Einschränkendes Recht (restricting right)** | Sonderform eines Rechts, das den Sichtbereich einschränkt statt eine Aktion freizuschalten, z. B. „Tickets anzeigen – nur eigene" (`CentronRights.md`, Abschnitt 1.1). |
| **Stammblatt** | Historische Datenhaltung für Drucker-Hardware, getrennt von der allgemeinen Asset-Verwaltung (`DocuBoard`/`AssetManagement*`); Konsolidierungskandidat lt. Aufgabenstellung. |
| **Asset (Asset Management)** | Allgemeine Geräte-/Hardware-Verwaltung (`AssetManagementPartnerBL`, `AssetManagementArticleAssignmentBL`), fachlich überlappend mit „Stammblatt". |
| **OPOS** | Offene-Posten-Liste (offene Forderungen), Zugriff geschützt über Recht `UserRightsConst.Controlling.Finances.Dunning` (`OposBL.ThrowIfUserHasInsufficentRights`). |
| **Mahnwesen / Dunning** | Prozess zur Zahlungserinnerung säumiger Kunden (`DunningBL`, `DunningRunBL`, `DunningCustomer`). |
| **I3D-Sperre / Lock** | Pessimistisches Sperren eines Datensatzes während der Bearbeitung, z. B. `InvoiceLock` über `AssetLockBL<T>.LockReceipt`. |
| **EDI** | Electronic Data Interchange – automatisierter Beleg-/Bestelldatenaustausch mit Lieferanten (ALSO, Alltron, Komsa, EGIS, Concerto u. a.), `src/backend/Centron.BL/EDI`. |
| **RMA** | Return Merchandise Authorization – Retourenabwicklung (`RmaBL`, UI-Modul `Rma`). |
| **PLM** | Product Lifecycle Management – Produktlebenszyklus-Verwaltung (`ProductLifecycleBL`, UI-Modul `PLM`). |
| **Nexus / CentronNexus** | Blazor-basiertes Web-Ticketportal/Serviceboard, eigenständiges Projekt `src/nexus/CentronNexus`, kommuniziert mit dem c-entron-Kern über `CentronNexusBL`. |
| **RiverDivo / Riverbird** | Externe mobile/Web-Anwendung, die über einen dedizierten Web-Service-Layer (`RiverDivoBL`) an c-entron andockt. |
| **TAPI** | Telephony API – Anbindung an Telefonanlagen zur Anruferkennung (`PhoneCallBL`, `TapiBL`). |
| **DSGVO-Bereinigung** | Funktion zur Umsetzung von Löschpflichten nach Datenschutz-Grundverordnung, rechtegeschützt über `UserRightsConst.DsgvoModule.ACCESS_CLEANUP_DATABASE` (`DataSecurityBL`). |
| **CPra** | Externer Cloud-Provisioning-Dienst (`https://c-pra.c-entron.de`), an den sich `CPraConnectorBL` mit Benutzername/Passwort anmeldet. |
| **Two-Factor / 2FA** | Zusätzlicher Anmeldefaktor, wahlweise per TOTP (Google-Authenticator-kompatibel), E-Mail oder RADIUS (`TwoFactorAuthBL`, `TwoFactorAuthenticationBL`). |
| **Webaccount** | Externer, kundenseitiger Zugang (SelfCare-Portal) im Unterschied zum internen `AppUser` (Mitarbeiterzugang). |
| **ES-Rolle (EsRole)** | Rollenkonzept einer externen „ElectronicSales"-Integration, separat vom internen Rechtesystem gepflegt (`EsRoleBL`). |
| **Zugferd / XRechnung** | Deutsches Format für hybride elektronische Rechnungen, umgesetzt in `InvoiceZugferdBL`. |
| **ebInterface** | Österreichisches Standardformat für elektronische Rechnungen (`Centron.Api.EbInterface`). |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/Hypothesen.md
+55
View File
@@ -0,0 +1,55 @@
# Hypothesen
Sammlung aller mit `[HYPOTHESE]`/`Status: HYPOTHESE` markierten Anforderungen aus `StRS.md`, `SyRS.md` und `SwRS.md`, mit der jeweils offenen Frage, die zur Bestätigung fehlt. Diese Liste ist deckungsgleich mit den Inline-Markierungen (siehe Konsistenzcheck in `Analysebericht.md`, Abschnitt 3) und enthält keine zusätzlichen freien Fragen ohne zugehörige Anforderung.
**Gesamtzahl: 31** (StRS: 18 · SyRS: 6 · SwRS: 7).
## StRS (18)
| ID | Titel | Offene Frage |
|---|---|---|
| StRS-8 | Externe Einkaufsanbindungen | Welchen konkreten Datenaustausch `Buying/External` realisiert – Verzeichnisinhalt wurde nicht gelesen. |
| StRS-13 | Änderungshistorie von Objekten | Ob `ChangeTracking/History` tatsächlich objektartübergreifend historisiert oder nur einzelne Bereiche abdeckt. |
| StRS-18 | Kundenspezifische Zusatztabellen | Konkreter technischer Mechanismus und Umfang von `CustomTables` – nur Verzeichnisname bekannt. |
| StRS-22 | Freitext-Dokumentation zu Objekten | Welchen Objektarten `DocumentationBL` konkret zugeordnet werden kann. |
| StRS-31 | Technische Hilfsfunktionen für Dokumentenverarbeitung | Welche Fachmodule die `Helpers`-Klassen tatsächlich referenzieren und wie. |
| StRS-35 | Logistikeinstellungen | Konkreter Funktionsumfang von `LogisticSettings` – nur Verzeichnisstruktur bekannt. |
| StRS-61 | Webservice-seitige Bereitstellung der Fachdomänen | Ob wirklich alle 72 `WebServices`-Unterordner vollständige funktionale Parität zum Desktop-Client bieten, oder ob Lücken bestehen. |
| StRS-62 | Web-Administrationsfunktionen | Konkreter Funktionsumfang von `WebSuite/Administration` – nur Verzeichnisstruktur bekannt. |
| StRS-82 | Gemeinsame Konstanten und Erweiterungsmethoden | Insbesondere Zweck und Umfang von `DeveloperSecurity.cs` ungeklärt. |
| StRS-91 | Installationspakete für Desktop-Anwendung und Riverbird | Konkreter Inhalt von `deployment/WixSharpInstaller` nicht gelesen. |
| StRS-93 | Automatisierte Build-/Analyse-Pipeline (Desktop-Anwendung) | Konkreter Pipelineninhalt (Werkzeuge, Qualitätsschwellen) nicht gelesen. |
| StRS-94 | Automatisierte Build-/Sicherheits-Pipeline (Nexus) | Welches SAST-/DAST-Werkzeug in `security-pipeline.yaml` tatsächlich eingesetzt wird. |
| StRS-95 | Strukturierte Betriebs-/Feature-Dokumentation | Konkreter Inhalt der `docs/`-Unterordner nicht gelesen. |
| StRS-101 | Zwischengespeicherte Tabellen und Datenqualitätsprüfung | Konkreter Prüfalgorithmus der Datenqualitätsprüfung nicht gelesen. |
| StRS-103 | Zentrale Startlogik der Anwendung | Konkreter Inhalt von `Centron.BL/Start` nicht gelesen. |
| StRS-109 | Aufgabenverwaltung mit Aktions-Handlern | Konkrete Implementierungen unter `TaskManager/ActionHandler` nicht gelesen. |
| StRS-116 | Handelspool-Anbindung | Konkreter Inhalt von `TradePoolBL`/`Core` nicht gelesen, nur Klassenname als Indiz. |
| StRS-127 | Richtlinienkonformität von Passworteinträgen | Konkreter Prüfalgorithmus gegen `Guideline`-Entitäten nicht gelesen. |
## SyRS (6)
| ID | Titel | Offene Frage |
|---|---|---|
| SyRS-5 | Echtzeit-Benachrichtigung über SignalR-artigen Hub | Ob tatsächlich eine Push-Technologie (z. B. SignalR) verwendet wird oder ein Polling-Mechanismus – „Hub"-Namensgebung ist nur ein Indiz. |
| SyRS-7 | Blacklist-Prüfung vor E-Mail-Versand | Ob wirklich jeder automatisierte Mail-Versandpfad die Blacklist konsultiert, oder ob Ausnahmen bestehen. |
| SyRS-21 | Containerbasierte Referenzumgebung für Tests | Ob der Mailcatcher tatsächlich lückenlos jeden während Regressionstests versendeten Testmailversand abfängt. |
| SyRS-22 | Rekursive Kategoriehierarchie mit Zyklusrisiko | Ob im vollständigen Code tatsächlich keine Zyklus-/Tiefenbegrenzung existiert (nur Methodenausschnitt gelesen). |
| SyRS-26 | Konsistente Enum-basierte Statusfilterung bei Gutscheinen | Wie das System bei fachlich widersprüchlichen Filterkombinationen (z. B. „frei" und „eingelöst" gleichzeitig) tatsächlich reagiert. |
| SyRS-31 | Rechtegeschützter Zugriff auf den Passwortmanager | Konkrete Methode und Rechte-ID, die den Zugriff auf hinterlegte Zugangsdaten tatsächlich absichert – nur Konstruktor-Injektion von `AppRightsBL` gelesen. |
## SwRS (7)
| ID | Titel | Offene Frage |
|---|---|---|
| SwRS-7 | Enum ReportDefaultValues als Flags für kombinierbare Ausgabewege | Ob das `[Flags]`-Attribut im vollständigen Enum tatsächlich fehlt (nur Ausschnitt gelesen). |
| SwRS-13 | Zustandsfilter für mobile Mitarbeiterentität über Zahlencode | Ob an anderer Stelle im Entitätsmodell doch ein benanntes Enum für `NewMobileEmployee.State` existiert. |
| SwRS-15 | DSGVO-Löschvermerk als Textersetzung statt Datensatzlöschung | Welches konkrete Feld überschrieben wird und ob referenzielle Integrität (z. B. verknüpfte Tickets) dabei erhalten bleibt. |
| SwRS-18 | Rekursiver Aufbau der Elternkategorien ohne Tiefenbegrenzung | Siehe SyRS-22 – ob im vollständigen Code eine Abbruchbedingung existiert. |
| SwRS-20 | SOAP-Vorlagen als eigenständige Ressourcendateien (COP-Anbindung) | Konkreter Inhalt der `SoapTemplates`-Dateien nicht gelesen. |
| SwRS-23 | AES-basierte Verschlüsselungslogik als wiederverwendbare Klasse | Ob `CryptoControl` (KI-Modul) und `AESCryptoLogic` (PDF-Signatur) tatsächlich dieselbe zugrunde liegende Implementierung nutzen oder unabhängige Parallelimplementierungen sind. |
| SwRS-37 | Identische Rechteprüfmethode ThrowIfUserHasInsufficentRights in zwei Klassen | Ob `DunningBL.ThrowIfUserHasInsufficentRights` tatsächlich dieselbe Implementierung wie `OposBL` nutzt (gemeinsame Basisklasse) oder eine unabhängige Kopie ist. |
## Hinweis zur Selbstbewertung
Diese Iteration führt bewusst eine zweistellige Zahl an Hypothesen (31 von 211 Anforderungen, 14,7 %). Angesichts der Größe der Codebasis (>75 fachliche BL-Ordner, 77.660-Zeilen-DB-Schema) und des in diesem Lauf verfügbaren Werkzeugsatzes (nur Dateisuche/-lektüre, keine Ausführung, kein Subagent) ist eine vollständig hypothesenfreie Analyse nicht plausibel – die Mehrzahl der Hypothesen entsteht dort, wo aus Zeitgründen nur die Verzeichnisstruktur, nicht aber der vollständige Quelltext gelesen wurde (Breite-vor-Tiefe-Vorgehen gemäß Auftrag). Details siehe Selbstbewertung in `Analysebericht.md`, Abschnitt 6.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/StRS.md
+2700
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/SwRS.md
+773
View File
@@ -0,0 +1,773 @@
# Software Requirements Specification (SwRS)
Iteration 02 · c-entron ERP-Suite. Komponenten, Datenmodelle, software-interne Regeln, abgeleitet aus SyRS/StRS. SwRS-1 bis SwRS-29 vertiefen ausgewählte Breitenmodule auf Softwareebene; SwRS-30 bis SwRS-38 sind die risikofokussierte Vertiefung.
---
```
ID: SwRS-1
Titel: Basisklasse PersistedEntity als Wurzel aller Fachentitäten
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `PersistedEntity.cs`, `PersistedLongEntity.cs` unter `src/backend/Centron.Entities`; jede in dieser Iteration gelesene Fachentität (z. B. `BankAccount`, `AppUser`, `Project`) besitzt ein `I3D`-Feld.
Aussage: Jede persistierte Fachentität soll von `PersistedEntity` (Int-Schlüssel) oder `PersistedLongEntity` (Long-Schlüssel) erben.
Ergebnis: Eine neue Fachentität erhält automatisch ein konsistentes Schlüsselverhalten.
Belege:
- [PRIMÄR] src/backend/Centron.Entities/PersistedEntity.cs, PersistedLongEntity.cs – Begründung: konkrete Basisklassen im Code definieren das Schlüsselverhalten strukturell.
Prüfidee: Eine von `PersistedEntity` erbende Testentität besitzt nach dem Speichern automatisch eine eindeutige I3D.
Tracelinks: StRS-84
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - konsistentes Basisklassendesign, im Zielsystem als Basis-Aggregat/Entity-Interface fortzuführen.
Status: belegt
```
```
ID: SwRS-2
Titel: Generische DAO-Klasse mit Expression-basierter Filterung
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `GenericDAO<T>` (`src/backend/Centron.DAO`) wird durchgängig mit `Expression<Func<T, bool>>`-Filtern aufgerufen (z. B. `BankAccountBL.GetList(Expression<Func<BankAccount, bool>> expression)`).
Aussage: Die generische DAO-Klasse soll typsichere LINQ-Expressions als Filterkriterium akzeptieren, statt modulspezifischer SQL-Strings.
Ergebnis: Filterkriterien werden zur Kompilierzeit typgeprüft.
Belege:
- [PRIMÄR] src/backend/Centron.DAO/GenericDAO.cs, Signatur GetList(Expression<Func<T,bool>>) – Begründung: durchgängig beobachtetes, typsicheres Filtermuster.
Prüfidee: Ein fehlerhafter Feldname in einer Filter-Expression wird bereits beim Kompilieren erkannt.
Tracelinks: SyRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - typsichere Filterung ist im Zielsystem fortzuführen (z. B. via Repository-Pattern mit Specification-Objekten).
Status: belegt
```
```
ID: SwRS-3
Titel: Dispatcher-Klasse für lieferantenspezifische EDI-Order-BL
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `EDIDispatcherBL` hält lazy-initialisierte, lieferantenspezifische Order-BL-Instanzen (`_opentrans21OrderBL ??= new Opentrans21OrderBL(...)`).
Aussage: Die EDI-Dispatcher-Komponente soll lieferantenspezifische Order-Implementierungen lazy instanziieren, um unnötige Objekterzeugung bei ungenutzten Lieferanten zu vermeiden.
Ergebnis: Nur tatsächlich angefragte Lieferanten-Implementierungen werden instanziiert.
Belege:
- [PRIMÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs, Methode GetOpentrans21OrderBL, Null-Coalescing-Zuweisung – Begründung: konkretes Lazy-Initialisierungsmuster im Code.
Prüfidee: Ein Dispatcher-Aufruf ohne Opentrans21-Bezug erzeugt nachweislich keine `Opentrans21OrderBL`-Instanz.
Tracelinks: SyRS-3
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - ressourcenschonendes Muster.
Status: belegt
```
```
ID: SwRS-4
Titel: DTO-Mapper-Konfigurationsklassen je Fachbereich
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `DunningConfiguration.cs` unter `src/backend/Centron.BL/WebServices/ObjectMapperConfiguration`.
Aussage: Jede über die Webservice-Schicht exponierte Fachdomäne soll eine eigene, explizite Mapper-Konfigurationsklasse besitzen.
Ergebnis: Das Mapping zwischen interner Entität und DTO ist an einer einzigen, benannten Stelle je Fachbereich nachvollziehbar.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/WebServices/ObjectMapperConfiguration/DunningConfiguration.cs – Begründung: dedizierte, fachbereichsbezogene Mapper-Konfigurationsklasse belegt das Muster exemplarisch für Dunning.
Prüfidee: Für jeden über SwRS-4 geprüften Fachbereich existiert genau eine zugehörige `*Configuration.cs`-Datei im ObjectMapperConfiguration-Ordner.
Tracelinks: SyRS-4
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - explizites Mapping ist wartungsfreundlicher als automatisches Reflection-Mapping.
Status: belegt
```
```
ID: SwRS-5
Titel: Registrierte Fulltext-Index-Implementierungen als Liste
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `IndexSearchBL._objectIndexes` ist eine feste Liste `{ new TicketFulltextIndex(), new AccountFulltextIndex() }`, deren Interface `IObjectFulltextIndex` ein `Kind`-Property vorsieht.
Aussage: Neue indizierbare Objektarten sollen über eine Implementierung von `IObjectFulltextIndex` und Eintragung in die Indexliste ergänzbar sein, ohne die Kernlogik von `IndexSearchBL` zu ändern.
Ergebnis: Eine dritte indizierbare Objektart (z. B. Verträge) lässt sich durch eine neue Klasse plus Listeneintrag ergänzen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs, Feld `_objectIndexes`, Interface IObjectFulltextIndex – Begründung: konkrete, offene Liste mit klarem Erweiterungspunkt über ein gemeinsames Interface.
Prüfidee: Eine neu implementierte `IObjectFulltextIndex`-Klasse wird nach Eintragung in `_objectIndexes` von `UpdateAllIndexes` automatisch mit verarbeitet.
Tracelinks: SyRS-6
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Open/Closed-konformes Erweiterungsmuster.
Status: belegt
```
```
ID: SwRS-6
Titel: Handler-Registry für Web-Link-Aktionen
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `WebLinkBL._handlers` ist eine `List<IWebLinkActionHandler>`, initial mit `WebLinkActionAccountActivityHandler`.
Aussage: Web-Link-Aktionen sollen über eine Handler-Liste nach dem Strategie-Muster erweiterbar sein.
Ergebnis: Eine neue Web-Link-Aktion lässt sich durch eine zusätzliche `IWebLinkActionHandler`-Implementierung ergänzen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebLinks/WebLinkBL.cs, Feld _handlers, Interface IWebLinkActionHandler – Begründung: konkretes Strategie-Muster im Code.
Prüfidee: Eine neue Handler-Implementierung für „ReminderHandler" wird bei Aufruf eines entsprechend typisierten Web-Links korrekt ausgeführt.
Tracelinks: StRS-60
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - klar erweiterbares Muster.
Status: belegt
```
```
ID: SwRS-7
Titel: Enum ReportDefaultValues als Flags für kombinierbare Ausgabewege
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `ReportsBL.ReportDefaultValues { Email = 1, PDF = 2, Print = 4 }` – Zweierpotenzwerte ohne erkennbares `[Flags]`-Attribut im gelesenen Ausschnitt.
Aussage: Das Enum `ReportDefaultValues` soll als kombinierbares Flags-Enum verwendet und im Zielsystem explizit mit `[Flags]` annotiert werden, um die Bitmasken-Semantik unmissverständlich zu machen.
Ergebnis: Kombinierte Werte (z. B. 3 = Email+PDF) sind sowohl im Code als auch für Werkzeuge (Debugger, Serialisierung) eindeutig als Kombination erkennbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Reporting/ReportsBL.cs, Enum ReportDefaultValues – Begründung: Zweierpotenzwerte sind im Code konkret erkennbar, das `[Flags]`-Attribut wurde im gelesenen Ausschnitt jedoch nicht gesehen.
Prüfidee: Noch zu bestimmen – Vertiefung erforderlich, ob `[Flags]` tatsächlich fehlt (nur Ausschnitt gelesen).
Tracelinks: SyRS-11
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da nur Teilausschnitt gelesen.
Status: HYPOTHESE
```
```
ID: SwRS-8
Titel: Verkettete Entität ValueAddedTax mit Selbstreferenz NextTaxRate
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `ValueAddedTax.NextTaxRate` (Selbstreferenz), genutzt in `TaxBL.GetActiveVatThroughNextVats`.
Aussage: Die Entität `ValueAddedTax` soll über eine Selbstreferenz `NextTaxRate` eine geordnete Kette von Steuersatzänderungen abbilden.
Ergebnis: Jeder Steuersatz kennt seinen unmittelbaren Nachfolger, wodurch eine Kette ohne separate Zwischentabelle entsteht.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Warehousing/TaxBL.cs, Zugriff `vat.NextTaxRate` – Begründung: konkrete Verwendung der Selbstreferenz im gelesenen Code.
Prüfidee: Ein `ValueAddedTax`-Datensatz mit gesetztem `NextTaxRate` verweist auf einen weiteren gültigen `ValueAddedTax`-Datensatz.
Tracelinks: SyRS-12
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - einfaches, funktionierendes Datenmodell für zeitlich geltende Werte.
Status: belegt
```
```
ID: SwRS-9
Titel: Cache-Felder für belegartspezifische Textbausteine
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `TextModuleBL` hält sechs private `TextModule`-Cache-Felder (Offer/Order/DeliveryList/PickupList/Invoice/CreditVoucher, je Salutation/Agreement).
Aussage: Die Klasse `TextModuleBL` soll je Belegart und Textbaustein-Typ ein eigenes Cache-Feld führen, um wiederholte Datenbankzugriffe innerhalb einer Session zu vermeiden.
Ergebnis: Ein zweiter Zugriff auf denselben Textbaustein innerhalb derselben BL-Instanz erfolgt ohne erneuten Datenbankzugriff.
Belege:
- [PRIMÄR] src/backend/Centron.BL/TextModuleArea/TextModuleBL.cs, Zeilen 24–35, sechs Cache-Felder – Begründung: konkrete Feldliste im Code.
Prüfidee: Zwei aufeinanderfolgende Abrufe der Rechnungs-Anrede innerhalb derselben BL-Instanz erzeugen nur eine Datenbankabfrage.
Tracelinks: SyRS-13
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - sinnvolle Session-lokale Zwischenspeicherung.
Status: belegt
```
```
ID: SwRS-10
Titel: Abgleichsalgorithmus für Modulregistrierung anhand ModuleGuid
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `ModuleBL.DoCreateMissingInternalModulesInDB`: `modules.Where(f => dbModules.Any(d => d.ModuleGuid.Equals(f.ModuleGuid, StringComparison.OrdinalIgnoreCase)) == false)`.
Aussage: Der Modulabgleich soll `ModuleGuid` case-insensitiv vergleichen, um Groß-/Kleinschreibungsunterschiede zwischen Code- und DB-GUIDs nicht als „fehlendes Modul" fehlzuinterpretieren.
Ergebnis: Ein Modul mit identischer GUID, aber abweichender Schreibweise, wird nicht fälschlich doppelt angelegt.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Modules/ModuleBL.cs, StringComparison.OrdinalIgnoreCase – Begründung: konkreter, im Code sichtbarer Vergleichsparameter.
Prüfidee: Eine DB-GUID in Kleinbuchstaben und eine Code-GUID in Großbuchstaben werden als identisch erkannt.
Tracelinks: SyRS-14
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - robuste Vergleichslogik.
Status: belegt
```
```
ID: SwRS-11
Titel: Objektart-Diskriminierung bei überlappenden I3D-Bereichen
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `NexusTicketView.CreatedByI3D` wird gemeinsam mit einem `CentronObjectKindNumeric`-Diskriminator (`Webaccount` vs. `EmployeeClass`) gespeichert, ermittelt über `GetCreatedByObjectKind`.
Aussage: Referenzen auf potenziell mehrdeutige I3Ds (Mitarbeiter vs. Web-Account) sollen stets zusammen mit einem expliziten Objektart-Diskriminator gespeichert werden.
Ergebnis: Eine Abfrage nach „CreatedByI3D=5" liefert ohne zusätzlichen Diskriminator kein eindeutiges Ergebnis; erst die Kombination aus I3D und Objektart ist eindeutig.
Belege:
- [PRIMÄR] src/backend/Centron.BL/NexusTicketViews/NexusTicketViewBL.cs, Methode GetCreatedByObjectKind, Rückgabe CentronObjectKindNumeric.Webaccount/EmployeeClass – Begründung: konkrete, im Code umgesetzte Diskriminator-Logik.
Prüfidee: Zwei Ticketansichten mit identischer CreatedByI3D, aber unterschiedlichem Objektart-Diskriminator, werden als unterschiedliche Datensätze behandelt.
Tracelinks: SyRS-15
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - notwendiges Diskriminierungsmuster bei geteilten Nummernräumen.
Status: belegt
```
```
ID: SwRS-12
Titel: Zehn unabhängige Boolean-Konfigurationsfelder für Kalenderdarstellung
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `CalendarRepresentationSettingsDTO` besitzt zehn Boolean-Properties, 1:1 aus `AppSettingsConst.HelpdeskTimeDisplay*` befüllt.
Aussage: Das DTO `CalendarRepresentationSettingsDTO` soll je Konfigurationsschalter ein eigenes, unabhängiges Boolean-Property führen.
Ergebnis: Jeder Schalter ist über sein eigenes Property einzeln lesbar und setzbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Calendar/CalendarBL.cs, Methode GetCalendarRepresentationSettings, zehn Zuweisungen – Begründung: vollständig gelesene 1:1-Zuordnung von Konfigurationsschalter zu DTO-Property.
Prüfidee: Jedes der zehn DTO-Properties lässt sich unabhängig von den übrigen neun setzen und auslesen.
Tracelinks: SyRS-16
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - klares, wenn auch granulares Konfigurationsmodell.
Status: belegt
```
```
ID: SwRS-13
Titel: Zustandsfilter für mobile Mitarbeiterentität über Zahlencode
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `NewMobileEmployee.State` wird in `MobileBL.GetMobileEmployee()` mit dem Literal `1` verglichen, ohne erkennbares Enum im gelesenen Ausschnitt.
Aussage: Das Feld `NewMobileEmployee.State` soll im Zielsystem durch ein benanntes Enum (z. B. `MobileEmployeeState.Active = 1`) ersetzt werden, um die „magische Zahl" les- und wartbar zu machen.
Ergebnis: Der Vergleich `State == 1` wird durch einen selbsterklärenden Enum-Vergleich ersetzt.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Mobile/MobileBL.cs, Filter `f => f.State == 1` – Begründung: konkreter, im Code sichtbarer Zahlenvergleich ohne erkennbares Enum.
Prüfidee: Noch zu bestimmen – Vertiefung erforderlich, ob im Entitätsmodell an anderer Stelle doch ein Enum für `State` existiert.
Tracelinks: SyRS-17
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - magische Zahl ist ein Wartbarkeitsrisiko und im Zielsystem zu bereinigen.
Status: HYPOTHESE
```
```
ID: SwRS-14
Titel: SQL-MERGE-Upsert mit HOLDLOCK für Telemetrie-Zähler
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `TelemetryBL.UpsertMcpToolUsageBatch` generiert dynamisch ein `MERGE dbo.McpToolUsageTelemetry WITH (HOLDLOCK) AS T USING (VALUES ...)`-Statement mit zusammengesetztem Schlüssel (`UserID, ToolNameI3D, HardwareIDI3D, ToolMode, BucketStartUtc`).
Aussage: Die Telemetrie-Tabelle `McpToolUsageTelemetry` soll einen zusammengesetzten fachlichen Schlüssel aus fünf Feldern führen und Batch-Updates ausschließlich über das dokumentierte HOLDLOCK-MERGE-Muster verarbeiten.
Ergebnis: Parallele Batch-Updates auf denselben Schlüssel führen zu korrekt aufaddierten Zählerständen ohne Duplikate.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Telemetry/TelemetryBL.cs, Methode UpsertMcpToolUsageBatch, SQL-Text Zeilen 36–47 – Begründung: vollständig im Code sichtbares SQL-Statement mit explizitem Schlüssel und Lock-Hinweis.
Prüfidee: Zwei parallele Aufrufe mit identischem Schlüssel, aber unterschiedlichem Inkrement, führen zu einem korrekt summierten `Count`-Wert.
Tracelinks: SyRS-18
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - technisch fundiertes, dokumentiertes Muster.
Status: belegt
```
```
ID: SwRS-15
Titel: DSGVO-Löschvermerk als Textersetzung statt Datensatzlöschung
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `DataSecurityBL`, Konstanten `DsgvoDeletedContactMessage`/`DsgvoDeletedContactMessageWithEmployeeInfo` werden vermutlich in ein Namens-/Freitextfeld des Kontakts geschrieben (konkrete Zielspalte im gelesenen Ausschnitt nicht identifiziert).
Aussage: Bei DSGVO-Löschung soll das betroffene Namens-/Kontaktfeld durch einen Standardtext mit Bearbeiter- und Zeitstempel-Platzhaltern ersetzt werden, statt den Datensatz zu löschen.
Ergebnis: Historische Verweise (z. B. in abgeschlossenen Tickets) bleiben referenzierbar, zeigen aber keine personenbezogenen Daten mehr.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Konstanten DsgvoDeletedContactMessage(WithEmployeeInfo) – Begründung: Konstantentext belegt das Muster, die konkrete Zielspalte des Ersetzungsvorgangs wurde nicht identifiziert.
Prüfidee: Noch zu bestimmen – Vertiefung erforderlich: welches Feld genau überschrieben wird und ob referenzielle Integrität (z. B. verknüpfte Tickets) erhalten bleibt.
Tracelinks: SyRS-19
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da Beleg dünn.
Status: HYPOTHESE
```
```
ID: SwRS-16
Titel: Filialbezogene Datenfilterung über BranchI3D-Vergleich
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `AppRightsBL.GetAllRightGroups`: `query.Where(f => f.BranchI3D == currentUser.Employee.BranchI3D.GetValueOrDefault(0))`.
Aussage: Die Filialeinschränkung soll über einen direkten Gleichheitsvergleich des `BranchI3D`-Feldes auf Query-Ebene (nicht nachträglich im Anwendungsspeicher) erfolgen.
Ergebnis: Die Filterung wird an die Datenbank delegiert (SQL-`WHERE`), nicht im Anwendungsspeicher nach vollständigem Laden durchgeführt.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Zeile 42–47, `IQueryable`-Filterung vor `.ToList()` – Begründung: die Filterung erfolgt auf einer `IQueryable<AppGroup>`, wird also als SQL-Prädikat übersetzt statt im Speicher.
Prüfidee: Bei aktivierter Datenbank-Traceanalyse enthält die generierte SQL-Abfrage eine WHERE-Klausel auf BranchI3D, statt alle Zeilen zu laden.
Tracelinks: SyRS-1, SyRS-28
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Performance- und sicherheitsrelevante Query-seitige Filterung.
Status: belegt
```
```
ID: SwRS-17
Titel: Lazy-Instanziierung des Lizenzmanagers als Singleton
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `LicenseManager.Instance.HasLicense(...)` (statischer Singleton-Zugriff) in `ProductionOrderBL`; zusätzlich `ILicenseManager`-Interface für Dependency Injection in `AppUserBL`/`UsersBL`.
Aussage: Der `LicenseManager` soll sowohl über ein statisches Singleton (`Instance`) als auch über ein injizierbares Interface (`ILicenseManager`) zugreifbar sein, um sowohl bestehenden Code als auch testbaren, neuen Code zu unterstützen.
Ergebnis: Bestehender Code kann weiterhin über `Instance` zugreifen, während neuer Code über Konstruktorinjektion testbar bleibt.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs (LicenseManager.Instance) vs. src/backend/Centron.BL/EmployeeArea/AppUserBL.cs (ILicenseManager im Konstruktor) – Begründung: zwei unterschiedliche, tatsächlich beobachtete Zugriffsmuster für dieselbe Komponente.
Prüfidee: Ein Unit-Test von `AppUserBL` kann `ILicenseManager` durch ein Test-Double ersetzen, ohne den globalen Singleton-Zustand zu beeinflussen.
Tracelinks: SyRS-8
Konsolidierung: Kandidat: (kein StRS/SyRS-Pendant, aber technischer Hinweis) – Begründung: zwei Zugriffsmuster für dieselbe Komponente sind im Zielsystem auf ein einheitliches DI-Muster zu konsolidieren.
Übernahmewürdigkeit: Workaround - der Singleton-Zugriffspfad (`Instance`) ist ein Übergangsmuster; im Zielsystem konsequent auf Dependency Injection umzustellen.
Status: belegt
```
```
ID: SwRS-18
Titel: Rekursiver Aufbau der Elternkategorien ohne Tiefenbegrenzung
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `ChecklistVirtualObjectCategoryBL.GetChecklistVirtualObjectCategoriesByFilter`, `while(recentlyAddedI3Ds.Count > 0)`-Schleife ohne erkennbaren maximalen Iterationszähler.
Aussage: Die rekursive Ladeschleife für Elternkategorien soll um eine explizite Tiefen- oder Zyklusbegrenzung ergänzt werden.
Ergebnis: Die Schleife terminiert garantiert auch bei fehlerhaften, zyklischen `ParentI3D`-Referenzen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs, Zeilen 37–44 – Begründung: konkrete Schleife ohne im gelesenen Ausschnitt erkennbare Abbruchbedingung außer dem natürlichen Leerwerden der Liste.
Prüfidee: Eine synthetisch erzeugte zyklische Elternreferenz (A→B→A) führt beim Laden zu einem kontrollierten Fehler statt zu einer Endlosschleife.
Tracelinks: SyRS-22
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernfunktion übernehmenswert, Robustheitsergänzung im Zielsystem umzusetzen.
Status: HYPOTHESE
```
```
ID: SwRS-19
Titel: Named-Query-Parameter-Bindung als durchgängiges Zugriffsmuster
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: –
Vorbedingung: –
Fakt: `NamedQueryParameter`-Objekte (z. B. in `TwoFactorAuthenticationBL`, `OutlookAssetKindSearchBL`, `VoucherManagementBL`) werden durchgängig statt String-Konkatenation verwendet.
Aussage: Datenbankzugriffe außerhalb der generischen DAO-Schicht sollen ausschließlich über parametrisierte Named Queries erfolgen.
Ergebnis: Es existiert kein beobachteter Codepfad, der Benutzereingaben direkt in SQL-Strings einfügt.
Belege:
- [PRIMÄR] mehrfach beobachtet, u. a. src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs – Begründung: konsistentes Muster über mehrere unabhängig gelesene Klassen hinweg.
Prüfidee: Eine Codesuche nach String-Konkatenation mit Benutzereingaben in SQL-Kontext liefert außerhalb der geprüften Stellen keine Treffer (Stichprobe).
Tracelinks: SyRS-27
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - sicheres Zugriffsmuster.
Status: belegt
```
```
ID: SwRS-20
Titel: SOAP-Vorlagen als eigenständige Ressourcendateien (COP-Anbindung)
Ebene: SwRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `src/apis/Centron.APIs.CopDataAccess/SoapTemplates` als eigener Ordner neben `CopApi.cs`.
Aussage: Die COP-API-Anbindung soll SOAP-Envelope-Vorlagen als separate Ressourcendateien führen, um sie unabhängig vom C#-Code pflegen zu können.
Ergebnis: Eine Anpassung eines SOAP-Templates erfordert keine Neukompilierung der Kernlogik.
Belege:
- [KONTEXT] src/apis/Centron.APIs.CopDataAccess/SoapTemplates (Verzeichnisname) – Begründung: dedizierter Vorlagenordner belegt Trennung von Vorlage und Logik; Inhalt nicht gelesen.
Prüfidee: Noch zu bestimmen – Vertiefung in Folge-Iteration erforderlich.
Tracelinks: StRS-64
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da Beleg dünn.
Status: HYPOTHESE
```
```
ID: SwRS-21
Titel: Getrennte Fehlerklassen je externer API-Anbindung
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `CopException.cs`, `EgisException.cs`, `ITscopeException.cs`, `IcecatException.cs` als jeweils eigene Exception-Klasse je API-Projekt.
Aussage: Jede externe API-Anbindung soll eine eigene, typisierte Exception-Klasse führen, um Fehler der jeweiligen Fremdsystem-Anbindung eindeutig unterscheidbar zu machen.
Ergebnis: Ein Aufrufer kann gezielt gegen die jeweilige API-Exception behandeln, ohne generische Exceptions abfangen zu müssen.
Belege:
- [SEKUNDÄR] src/apis/*/*.Exception.cs (vier unabhängige Projekte) – Begründung: identisches Namensmuster über vier unabhängige API-Projekte hinweg belegt bewusste, konsistente Konvention.
Prüfidee: Ein Fehler bei der COP-Anbindung wirft nachweislich `CopException`, nicht eine generische `Exception`.
Tracelinks: StRS-64, StRS-65, StRS-67, StRS-68
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - konsistente, typisierte Fehlerbehandlung.
Status: belegt
```
```
ID: SwRS-22
Titel: Parallele Host-Einstiegspunkte für denselben Webservice-Kern
Ebene: SwRS
Typ: nicht-funktional
Qualitätsmerkmal: Übertragbarkeit
Akteur: –
Vorbedingung: –
Fakt: `Centron.Host.Console/Program.cs` und `Centron.Host.WindowsService/CentronService.cs`/`Program.cs` referenzieren beide `Centron.Host` als gemeinsame Kernbibliothek.
Aussage: Beide Host-Projekte sollen ausschließlich als dünne Einstiegspunkte fungieren, die den identischen `Centron.Host`-Kern starten, ohne eigene Fachlogik zu duplizieren.
Ergebnis: Eine Änderung am Host-Kern wirkt sich identisch auf beide Betriebsarten aus, ohne dass beide Projekte separat angepasst werden müssen.
Belege:
- [SEKUNDÄR] src/webservice/Centron.Host.Console/Program.cs, src/webservice/Centron.Host.WindowsService/Program.cs – Begründung: beide Projekte referenzieren strukturell denselben Host-Kern (Projektabhängigkeit, nicht im Detail gelesen).
Prüfidee: Eine Änderung an einer Kernfunktion in `Centron.Host` wird ohne Codeänderung in Console oder WindowsService in beiden Betriebsarten wirksam.
Tracelinks: StRS-73, StRS-123
Konsolidierung: Kandidat: StRS-73/StRS-123
Übernahmewürdigkeit: Workaround - für Cloud-native Zielarchitektur durch einheitliches Container-Startmodell zu ersetzen.
Status: belegt
```
```
ID: SwRS-23
Titel: AES-basierte Verschlüsselungslogik als wiederverwendbare Klasse
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: –
Vorbedingung: –
Fakt: `AESCryptoLogic` wird sowohl in `PdfSigningBL` (TSA-Passwort) als auch implizit über `CryptoControl` (ArtificialIntelligence-API-Schlüssel) verwendet.
Aussage: Die Verschlüsselung sensibler Konfigurationswerte soll über eine zentrale, wiederverwendbare AES-Verschlüsselungskomponente erfolgen.
Ergebnis: Alle verschlüsselt gespeicherten Konfigurationswerte nutzen denselben Algorithmus und dieselbe Schlüsselverwaltung.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs (AESCryptoLogic), src/backend/Centron.BL/ArtificialIntelligence/OpenAiApiClient.cs (CryptoControl) – Begründung: zwei Verwendungsstellen belegen eine gemeinsame Verschlüsselungsbasis, exakte Beziehung zwischen `AESCryptoLogic` und `CryptoControl` wurde nicht im Detail verifiziert.
Prüfidee: Noch zu bestimmen – Vertiefung erforderlich: Klärung, ob `CryptoControl` und `AESCryptoLogic` dieselbe zugrunde liegende Implementierung nutzen.
Tracelinks: SyRS-34
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da Beziehung zwischen den Klassen nicht abschließend verifiziert.
Status: HYPOTHESE
```
```
ID: SwRS-24
Titel: Cursor-/Paging-Parameter bei Lieferantenbuchungssuche
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `SupplierAssetBL.GetSupplierBookingByFilter(filter, page, entriesPerPage)` prüft `page <= 0` und `entriesPerPage <= 0` explizit und wirft `ArgumentOutOfRangeException`.
Aussage: Paginierte Suchfunktionen sollen ihre Paging-Parameter (Seite, Einträge pro Seite) vor Ausführung der Abfrage explizit validieren.
Ergebnis: Ein Aufruf mit ungültiger Seitenzahl/-größe wird sofort mit einer klaren Exception abgelehnt, statt eine fehlerhafte oder leere Abfrage auszuführen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/BusinessPartner/SupplierAssetBL.cs, Methode GetSupplierBookingByFilter, Zeilen 45–46 – Begründung: konkrete, im Code sichtbare Parametervalidierung.
Prüfidee: Ein Aufruf mit `page=0` löst eine `ArgumentOutOfRangeException` aus, bevor eine Datenbankabfrage erfolgt.
Tracelinks: StRS-7
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - solide Eingabevalidierung.
Status: belegt
```
```
ID: SwRS-25
Titel: Wochentagsspezifische Zeitfenster-Felder für erwartete Ereignisse
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `ExpectedEvents`-Entität führt für jeden Wochentag (Montag–Freitag) eigene Felder `TimeBetweenX`, `ExecuteXFrom`, `ExecuteXTo`, `ExpectedIncomeX` (20 Felder statt einer normalisierten Wochentagstabelle).
Aussage: Die Entität `ExpectedEvents` bildet Wochentags-Zeitfenster über 20 einzelne, wochentagspezifische Felder statt einer normalisierten 1:n-Beziehung zu einer Wochentagstabelle ab.
Ergebnis: Eine Änderung der Zeitfensterlogik (z. B. Ergänzung um Samstag/Sonntag) erfordert ein Schema-Update statt einer einfachen Dateneinfügung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs, Methode SaveExpectedEvent, Zeilen 37–60 (Montag bis Freitag einzeln) – Begründung: vollständig gelesene, sich wiederholende Feldstruktur je Wochentag.
Prüfidee: Eine Erweiterung um Samstag/Sonntag würde im aktuellen Modell eine Datenbankmigration erfordern statt einer reinen Dateneinfügung.
Tracelinks: StRS-25
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - denormalisierte Wochentagsfelder sind ein Migrationskandidat für ein normalisiertes Wochentagsmodell im Zielsystem.
Status: belegt
```
```
ID: SwRS-26
Titel: Enum CentronObjectKindNumeric als generischer Objekttyp-Diskriminator
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `CentronObjectKindNumeric` wird sowohl in `NexusTicketViewBL` (Webaccount/EmployeeClass) als auch in `ObjectExternalReferenceBL.GetReferencesForObject(objectI3D, objectKind)` und `ProcessBL.GetProcess<T>(objectI3D, objectKind)` verwendet.
Aussage: Das Enum `CentronObjectKindNumeric` soll systemweit als generischer Diskriminator für „welche Art von Objekt referenziert eine I3D" verwendet werden.
Ergebnis: Mindestens drei unabhängige Fachbereiche (Nexus-Ansichten, externe Referenzen, Workflow-Prozesse) nutzen denselben Diskriminator-Typ konsistent.
Belege:
- [PRIMÄR] Nachweis in drei unabhängig gelesenen Klassen: NexusTicketViewBL, ObjectExternalReferenceBL, ProcessBL – Begründung: dreifach unabhängig beobachtete Verwendung desselben Enum-Typs für denselben fachlichen Zweck.
Prüfidee: Ein neuer Fachbereich, der objektartübergreifende Referenzen benötigt, kann denselben Enum-Typ ohne Erweiterung der Kernlogik wiederverwenden.
Tracelinks: SyRS-15, StRS-47, StRS-51
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - bewährtes, systemweit konsistentes Diskriminator-Muster.
Status: belegt
```
```
ID: SwRS-27
Titel: Result/Result&lt;T&gt;-Rückgabetyp als einheitliches Fehlerkapselungsmuster
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: Praktisch alle gelesenen BL-Methoden geben `Result` oder `Result<T>` mit `ResultStatus` (Success/Warning/Error) zurück, statt Exceptions für erwartbare Fehlerfälle zu werfen (Ausnahmen: Rechteverletzungen werfen bewusst Exceptions, siehe SyRS-38).
Aussage: Fachliche Methoden sollen erwartbare Fehler- und Warnzustände über den `Result`/`Result<T>`-Rückgabetyp kommunizieren, während unautorisierte Zugriffe bewusst als Exception (fail-closed) behandelt werden.
Ergebnis: Aufrufer können erwartbare Fehler ohne Exception-Handling behandeln, während Sicherheitsverletzungen nicht versehentlich ignoriert werden können.
Belege:
- [PRIMÄR] durchgängig beobachtet in ≥15 unabhängig gelesenen Methoden (z. B. AppointmentRequestBL, ExternalHelpdeskConfigurationBL, ObjectExternalReferenceBL) – Begründung: konsistentes Muster über viele unabhängige Module.
Prüfidee: Eine fachliche Validierungsverletzung (z. B. doppelter Name) liefert `Result.AsError(...)`, keine Exception; eine Rechteverletzung im Finanzbereich liefert eine Exception.
Tracelinks: –
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - konsistentes, im Zielsystem als Result-Pattern/Railway-Oriented-Programming fortzuführendes Muster.
Status: belegt
```
```
ID: SwRS-28
Titel: Konstruktorbasierte Zusammensetzung von BL-Abhängigkeiten
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: Nahezu jede gelesene BL-Klasse instanziiert ihre BL-Abhängigkeiten im eigenen Konstruktor per `new XyzBL(this.Session)` (z. B. `AppointmentRequestBL`, `MailScannerBL`, `PhoneCallBL`), anstatt sie injizieren zu lassen.
Aussage: BL-Klassen sollen ihre Hilfsklassen im eigenen Konstruktor über dieselbe `DAOSession` neu instanziieren, um innerhalb einer Session konsistent zu bleiben.
Ergebnis: Alle innerhalb einer Anfrage verwendeten BL-Instanzen teilen sich dieselbe Datenbank-Session.
Belege:
- [PRIMÄR] durchgängig beobachtet, u. a. src/backend/Centron.BL/MailScanner/MailScannerBL.cs, src/backend/Centron.BL/Tapi/PhoneCallBL.cs – Begründung: konsistentes Konstruktionsmuster über viele unabhängige Klassen.
Prüfidee: Zwei innerhalb derselben Anfrage instanziierte BL-Klassen greifen nachweislich auf dieselbe `DAOSession`-Instanz zu.
Tracelinks: –
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - manuelle `new`-Instanziierung statt Dependency-Injection-Container ist im Zielsystem durch einen DI-Container mit Session-Scope zu ersetzen.
Status: belegt
```
```
ID: SwRS-29
Titel: Konsistente Verwendung von Guard-Hilfsmethoden zur Parametervalidierung
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `Guard.NotNull(...)`, `Guard.NotZero(...)`, `Guard.NotNegativeOrZero(...)`, `Guard.NotLessOrEqualThan(...)` werden in praktisch jeder gelesenen BL-Methode mit Parametern zu Beginn aufgerufen.
Aussage: Öffentliche BL-Methoden sollen ihre Parameter zu Methodenbeginn konsistent über die zentrale `Guard`-Klasse validieren.
Ergebnis: Ungültige Parameter (null, negative I3Ds) werden früh und einheitlich mit einer nachvollziehbaren Exception abgelehnt.
Belege:
- [PRIMÄR] durchgängig beobachtet in ≥10 unabhängig gelesenen Klassen (z. B. BankAccountBL, AppointmentRequestBL, ChecklistVirtualObjectCategoryBL) – Begründung: konsistentes Validierungsmuster über viele unabhängige Module.
Prüfidee: Ein Aufruf einer beliebigen geprüften Methode mit `null` als Pflichtparameter löst eine `ArgumentNullException` (über Guard.NotNull) aus.
Tracelinks: –
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - konsistentes Validierungsmuster, im Zielsystem fortzuführen (ggf. durch Sprachfeatures wie C# Nullable Reference Types ergänzt).
Status: belegt
```
---
## Risikofokussierte Vertiefung (Rechte, Authentifizierung, Fakturierung, Datenschutz)
```
ID: SwRS-30
Titel: Dreistufige Datumsprüfung für Kontoaktivstatus
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `AppUserBL.GetActiveAppUsers()`, LINQ-Ausdruck mit drei ODER-verknüpften Fällen: (1) `AccountDisabledFromDate == null && AccountDisabledToDate == null`; (2) `AccountDisabledFromDate != null && (DateTime.Today < FromDate || (ToDate != null && ToDate < DateTime.Today))`; (3) analoger dritter Fall für nur `ToDate` gesetzt.
Aussage: Die Methode `GetActiveAppUsers()` soll den Aktivstatus ausschließlich über einen reinen, seiteneffektfreien LINQ-Ausdruck auf Basis des aktuellen Datums berechnen, ohne ein zusätzliches, potenziell veraltendes Zwischenstatus-Feld zu pflegen.
Ergebnis: Der Aktivstatus ist zu jedem Abfragezeitpunkt korrekt, unabhängig davon, wann zuletzt ein Wartungsjob lief.
Belege:
- [PRIMÄR] src/backend/Centron.BL/EmployeeArea/AppUserBL.cs, Zeilen 38–50 – Begründung: vollständig gelesener, reiner Ausdruck ohne erkennbaren Seiteneffekt oder zwischengespeicherten Status.
Prüfidee: Bei künstlich vorgezogener Systemzeit (Testumgebung) ändert sich der von `GetActiveAppUsers()` gelieferte Bestand exakt zum erwarteten Umschaltzeitpunkt, ohne dass ein Batch-Job läuft.
Tracelinks: SyRS-30
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zustandsloses, korrektes Berechnungsmuster ist einem zwischengespeicherten Status vorzuziehen.
Status: belegt
```
```
ID: SwRS-31
Titel: Wiederholte identische Lizenzprüfung als Methoden-Precondition
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `ProductionOrderBL`: identischer Code `if (LicenseManager.Instance.HasLicense(LicenseGuids.ProductionManagement) == false) throw new Exception(LocalizedStrings.ProductionBL_...)` ist an drei Stellen (Zeilen 29–30, 39–40, ~49–50) dupliziert.
Aussage: Die Lizenzprüfung für Produktionsaufträge soll aus Wartbarkeitsgründen in eine private Hilfsmethode extrahiert werden, statt an jeder öffentlichen Methode identisch dupliziert zu werden.
Ergebnis: Eine künftige Änderung der Lizenzprüfung (z. B. zusätzliche Bedingung) erfordert nur eine Änderungsstelle statt drei.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs, Zeilen 29–30, 39–40, 49–50 – Begründung: identischer, dreifach dupliziert beobachteter Code.
Prüfidee: Eine Änderung der Lizenzbedingung (z. B. zusätzliche Prüfung auf Ablaufdatum) lässt sich nach Refactoring an einer einzigen Stelle vornehmen und wirkt sich auf alle drei Methoden aus.
Tracelinks: SyRS-32
Konsolidierung: Kandidat: (interne Code-Duplizierung, kein StRS-Pendant) – Begründung: dreifache identische Prüfung ist ein Refactoring-, nicht primär ein Konsolidierungsfall im Sinne der Aufgabenstellung, wird hier dennoch dokumentiert.
Übernahmewürdigkeit: übernehmen - fachliche Regel bleibt, technische Duplizierung im Zielsystem zu bereinigen.
Status: belegt
```
```
ID: SwRS-32
Titel: Zentrale Entschlüsselungsstelle unmittelbar vor externem HTTP-Aufruf
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: –
Vorbedingung: –
Fakt: `OpenAiApiClient`, Zeile ~34 (`ApiKeyCredential`-Erzeugung) und Zeile ~103 (`AuthenticationHeaderValue("Bearer", apiKey)`) – jeweils unmittelbar vorher `CryptoControl.DecryptString(_settings.ApiKey)`, der entschlüsselte Wert wird nicht in einem Feld zwischengespeichert, sondern lokal in der jeweiligen Methode verwendet.
Aussage: Der entschlüsselte API-Schlüssel soll ausschließlich als lokale Variable unmittelbar vor dem HTTP-Aufruf existieren, nicht als Instanzfeld zwischengespeichert werden, um die Zeitspanne des Klartext-Vorhandenseins im Speicher zu minimieren.
Ergebnis: Der Klartext-API-Schlüssel existiert nur für die Dauer des unmittelbaren Aufrufs im Speicher.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ArtificialIntelligence/OpenAiApiClient.cs, zwei unabhängige Aufrufstellen (Zeile ~34 und ~103), jeweils lokale Variable `key`/`apiKey` – Begründung: an zwei unabhängigen Stellen dasselbe Muster (lokale statt Instanzvariable) beobachtet.
Prüfidee: Ein Speicher-Dump der `OpenAiApiClient`-Instanz zwischen zwei Aufrufen enthält keinen entschlüsselten API-Schlüssel als Instanzfeld.
Tracelinks: SyRS-34
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - sicherheitsbewusstes Muster (Minimierung der Klartext-Lebensdauer im Speicher).
Status: belegt
```
```
ID: SwRS-33
Titel: Filter-basierte Autorisierungskomponente mit klar getrennten 401/403-Pfaden
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: –
Vorbedingung: –
Fakt: `UserRightAuthorizationFilter.OnAuthorization`: `if (currentUser == null) { context.Result = new UnauthorizedResult(); return; }` gefolgt von `if (!_requiredRightId.HasValue || !currentUser.HasUserRight(_requiredRightId.Value)) context.Result = new ForbidResult();`.
Aussage: Die Autorisierungskomponente `UserRightAuthorizationFilter` soll fehlende Authentifizierung (401) strikt von fehlender Autorisierung (403) unterscheiden, gemäß dem HTTP-Standard.
Ergebnis: Ein Client kann anhand des Statuscodes unterscheiden, ob er sich anmelden muss (401) oder mit seinem aktuellen Konto keinen Zugriff hat (403).
Belege:
- [PRIMÄR] src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs, Methode OnAuthorization, Zeilen 43–51 – Begründung: vollständig gelesene, klar getrennte Fallunterscheidung.
Prüfidee: Ein nicht angemeldeter Request liefert exakt 401; ein angemeldeter Request ohne Recht liefert exakt 403.
Tracelinks: SyRS-33
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - HTTP-standardkonformes, klar unterscheidbares Verhalten.
Status: belegt
```
```
ID: SwRS-34
Titel: Sequenzielle Kombination von Passwort- und TOTP-Prüfung mit Kurzschlussverhalten
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: –
Vorbedingung: –
Fakt: `BasicAuthenticator.AuthenticateInternal`: `ValidateAppUser(user)` liefert bei Fehlschlag sofortigen Rückgabewert (Zeile 52–57, vor der 2FA-Prüfung), erst danach folgt `_twoFactorAuthBL.ValidateTwoFactor(...)` (Zeile 62).
Aussage: Die Passwortprüfung soll der Zwei-Faktor-Prüfung strikt vorgeschaltet sein (Kurzschlussauswertung); bei fehlgeschlagenem Passwort soll die 2FA-Prüfung gar nicht erst ausgeführt werden.
Ergebnis: Ein Angreifer ohne korrektes Passwort erhält keine Information darüber, ob 2FA aktiviert ist oder wie eine 2FA-Antwort ausfallen müsste (kein Oracle für 2FA-Status vor Passwortnachweis).
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Zeilen 52–65 – Begründung: konkrete, im Code sichtbare Reihenfolge mit frühzeitigem Return bei Passwortfehlschlag.
Prüfidee: Ein Anmeldeversuch mit falschem Passwort liefert dieselbe generische Fehlerantwort unabhängig davon, ob 2FA für den Benutzer aktiviert ist.
Tracelinks: SyRS-35
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - korrekte Kurzschlussreihenfolge verhindert Informationslecks über den 2FA-Status.
Status: belegt
```
```
ID: SwRS-35
Titel: SHA1Decoder als zentrale, aber kryptographisch veraltete Hash-Komponente
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: –
Vorbedingung: –
Fakt: `SHA1Decoder.GetDecodedSHA1String(...)` wird identisch in `BasicAuthenticator.cs` (Login) und `UsersBL.cs` (Passwortänderung/-prüfung, drei Aufrufstellen) verwendet – eine zentrale, aber veraltete Komponente statt verstreuter Einzelimplementierungen.
Aussage: Die Komponente `SHA1Decoder` soll im Zielsystem durch eine Komponente mit gesalzenem, adaptivem Hash-Algorithmus (Argon2id/bcrypt/PBKDF2) ersetzt werden; da der Aufruf bereits heute zentral über eine Komponente erfolgt, ist ein Austausch an einer Stelle technisch mit überschaubarem Aufwand möglich.
Ergebnis: Nach Austausch verwenden alle vier heutigen Aufrufstellen automatisch den neuen, sicheren Algorithmus.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Zeile 46; src/backend/Centron.BL/Administration/Logins/UsersBL.cs, Zeilen 65, 88, 107 – Begründung: vollständiger Nachweis aller vier Aufrufstellen derselben Komponente.
Prüfidee: Nach Austausch der `SHA1Decoder`-Implementierung gegen ein Argon2id-basiertes Verfahren funktionieren Login und Passwortänderung unverändert aus Anwendersicht, verwenden intern jedoch den neuen Algorithmus.
Tracelinks: SyRS-36
Konsolidierung: Kandidat: SwRS-35 vs. Core/CryptoUtils (StRS-96) – Begründung: zwei parallele Hash-Komponenten (`SHA1Decoder`, tatsächlich verwendet; `CryptoUtils`, offenbar ungenutzt) sind im Zielsystem zu einer einzigen zu konsolidieren.
Übernahmewürdigkeit: veraltet - die konkrete SHA1-Implementierung ist zu ersetzen; die zentrale Architektur (eine Komponente für alle Aufrufstellen) ist hingegen ein Vorteil für die Migration und beizubehalten.
Status: belegt
```
```
ID: SwRS-36
Titel: AssetLockBL&lt;T&gt; als generische Sperrkomponente für Beleg-Locks
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: –
Vorbedingung: –
Fakt: `AssetLockBL<InvoiceLock>` wird generisch mit dem konkreten Lock-Entitätstyp `InvoiceLock` parametrisiert; `TryLockReceipt`/`UnLockReceipt` delegieren an diese generische Komponente mit Rechte-Parameter `UNLOCK_CUSTOMER_ATTACHMENTS`.
Aussage: Die Sperrlogik für Belege soll generisch über `AssetLockBL<T>` implementiert sein, sodass sich weitere Belegarten (nicht nur Rechnungen) mit demselben Mechanismus sperren lassen, indem ein eigener Lock-Entitätstyp definiert wird.
Ergebnis: Eine neue Belegart kann Sperrfunktionalität durch Definition eines eigenen `XyzLock`-Typs und Instanziierung von `AssetLockBL<XyzLock>` erhalten, ohne die Kernsperrlogik zu duplizieren.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, Zeile 202, `new AssetLockBL<InvoiceLock>(this._session)` – Begründung: konkrete generische Instanziierung im Code.
Prüfidee: Ein neuer Lock-Typ `OfferLock`, instanziiert über `AssetLockBL<OfferLock>`, sperrt Angebote nach demselben Muster wie Rechnungen.
Tracelinks: SyRS-37
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - generisches, wiederverwendbares Sperrmuster.
Status: belegt
```
```
ID: SwRS-37
Titel: Identische Rechteprüfmethode ThrowIfUserHasInsufficentRights in zwei Klassen
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: –
Vorbedingung: –
Fakt: `OposBL.ThrowIfUserHasInsufficentRights` (vollständig gelesen, Zeilen 28–36) prüft `UserRightsConst.Controlling.Finances.Dunning` über `AppRightsBL.CheckRightsFromUser`; `DunningBL.GetDunningCustomers` (Zeile 62) ruft eine strukturell identisch benannte Methode `this.ThrowIfUserHasInsufficentRights(loggedInUser)` auf.
Aussage: Beide Klassen (`OposBL`, `DunningBL`) sollen dieselbe Rechteprüfmethode namentlich konsistent implementieren bzw. auf eine gemeinsame Basisklasse/Hilfsmethode zurückgreifen, um Drift zwischen den beiden Prüfstellen zu vermeiden.
Ergebnis: Eine künftige Änderung des benötigten Rechts wirkt sich konsistent auf beide Klassen aus, sofern eine gemeinsame Implementierung genutzt wird.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs, Zeilen 28–36; src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Zeile 62 – Begründung: identischer Methodenname an zwei Stellen, tatsächliche Code-Identität (gemeinsame Basisklasse vs. Kopie) wurde nicht abschließend verifiziert.
Prüfidee: Noch zu bestimmen – Vertiefung erforderlich: Prüfen, ob `DunningBL.ThrowIfUserHasInsufficentRights` tatsächlich dieselbe Implementierung wie `OposBL` nutzt (z. B. über gemeinsame Basisklasse) oder eine unabhängige Kopie ist.
Tracelinks: SyRS-38
Konsolidierung: Kandidat: OposBL/DunningBL – Begründung: identischer Methodenname und identisches Recht an zwei Stellen sind ein Konsolidierungskandidat für eine gemeinsame Basisklasse im Zielsystem.
Übernahmewürdigkeit: übernehmen - Einschätzung zur Code-Duplizierung vorläufig, da nicht abschließend verifiziert.
Status: HYPOTHESE
```
```
ID: SwRS-38
Titel: Verschlüsselte Speicherung des TSA-Server-Passworts mit bedingter Entschlüsselung
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: –
Vorbedingung: –
Fakt: `PdfSigningBL.GetPdfSigningSettings`: `if (!String.IsNullOrWhiteSpace(pdfSigningSetting.TsaServerPassword)) { pdfSigningSetting.TsaServerPassword = _cryptoLogic.DecryptText(pdfSigningSetting.TsaServerPassword); }`.
Aussage: Das TSA-Server-Passwort soll nur entschlüsselt werden, wenn tatsächlich ein Wert hinterlegt ist, um unnötige Entschlüsselungsoperationen und Fehler bei leerem Wert zu vermeiden.
Ergebnis: Bei nicht konfiguriertem TSA-Passwort wird kein Entschlüsselungsversuch unternommen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs, Methode GetPdfSigningSettings, Zeilen 44–47 – Begründung: konkrete, bedingte Entschlüsselungslogik im Code.
Prüfidee: Ein Aufruf von `GetPdfSigningSettings` ohne konfiguriertes TSA-Passwort löst keine Entschlüsselungsoperation und keinen Fehler aus.
Tracelinks: SyRS-39
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - robuste, defensive Implementierung.
Status: belegt
```
---
**Gesamtzahl SwRS in diesem Dokument: 38** (SwRS-1 bis SwRS-38, lückenlos).
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/SyRS.md
+794
View File
@@ -0,0 +1,794 @@
# System Requirements Specification (SyRS)
Iteration 02 · c-entron ERP-Suite. Systemverhalten, Schnittstellen, Performance- und Sicherheitsanforderungen, abgeleitet aus StRS. SyRS-1 bis SyRS-29 vertiefen ausgewählte Breitenmodule auf Systemebene; SyRS-30 bis SyRS-39 sind die risikofokussierte Vertiefung (Rechte, Authentifizierung, Fakturierung, Datenschutz).
---
```
ID: SyRS-1
Titel: Mandantentrennung auf Datenbankebene
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Mehrere Mandanten sind konfiguriert.
Fakt: `MandatorBL.cs`, `BranchBL.cs` unter `src/backend/Centron.BL/Administration/Company`; zahlreiche gelesene Entitäten führen ein `BranchI3D`-Feld (z. B. `AppGroup.BranchI3D` in `AppRightsBL.GetAllRightGroups`).
Aussage: Das System soll Daten mandanten-/filialbezogen kennzeichnen, sodass Auswertungen und Rechte auf einen Mandanten/eine Filiale eingeschränkt werden können.
Ergebnis: Ein filialbeschränkter Benutzer sieht ausschließlich Daten seiner eigenen Filiale.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode GetAllRightGroups, Filter `f.BranchI3D == currentUser.Employee.BranchI3D.GetValueOrDefault(0)` – Begründung: konkrete, im Code durchgesetzte Filialeinschränkung.
Prüfidee: Ein Benutzer mit „MANAGE_RIGHTS_ONLY_OWN_BRANCH" sieht bei Gruppenabfrage nur Gruppen seiner eigenen Filiale.
Tracelinks: StRS-4
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Grundlage für Mandantenfähigkeit im SaaS-Zielsystem.
Status: belegt
```
```
ID: SyRS-2
Titel: Einheitliches Datenzugriffsmuster über generische DAO-Schicht
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: System
Vorbedingung: –
Fakt: `GenericDAO.cs`, `DAOFactory.cs`, `DAOSession.cs` (`src/backend/Centron.DAO`); Aufrufmuster `Session.GetGenericDAO<T>()` in praktisch jeder gelesenen BL-Klasse.
Aussage: Das System soll für Standard-CRUD-Operationen konsequent eine generische, typsichere DAO-Schicht verwenden statt modulspezifischer SQL-Duplizierung.
Ergebnis: Neue Entitäten erhalten Standard-CRUD-Fähigkeiten ohne zusätzlichen Implementierungsaufwand.
Belege:
- [PRIMÄR] src/backend/Centron.DAO/GenericDAO.cs, Verwendungsnachweis in ≥15 unabhängig gelesenen BL-Klassen – Begründung: durchgängig beobachtetes Muster über viele unabhängige Module hinweg.
Prüfidee: Eine neue, von `PersistedEntity` erbende Entität ist ohne Zusatzcode über `Session.GetGenericDAO<T>()` lesbar/schreibbar.
Tracelinks: StRS-83, StRS-84
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Repository-Muster im Zielsystem fortzuführen.
Status: belegt
```
```
ID: SyRS-3
Titel: Mehrformat-EDI-Bestellübermittlung
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System, Lieferant
Vorbedingung: Bestellung ist freigegeben.
Fakt: `EDIDispatcherBL` instanziiert je Lieferant eine spezifische Order-BL (`Opentrans21OrderBL` u. a.) auf Basis von Lieferantenkennung.
Aussage: Das System soll beim Versand einer Bestellung automatisch das für den Ziellieferanten passende EDI-Format auswählen.
Ergebnis: Eine Bestellung an Lieferant X wird nachweislich im für X korrekten Format übertragen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs – Begründung: Dispatcher-Muster mit lieferantenspezifischer Instanziierung.
Prüfidee: Bestellungen an zwei unterschiedliche Lieferanten erzeugen zwei strukturell unterschiedliche EDI-Nachrichten.
Tracelinks: StRS-23
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - notwendig für Distributorenanbindung.
Status: belegt
```
```
ID: SyRS-4
Titel: Einheitliches DTO-Mapping für Web-/Mobile-Clients
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Web-/Mobile-Client
Vorbedingung: –
Fakt: `src/backend/Centron.BL/WebServices` (72 Unterordner) mappt Kern-Entitäten auf `CentronSoftware.Centron.WebServices.Entities.*`-DTOs.
Aussage: Das System soll interne Entitäten nicht direkt, sondern über explizite DTOs an Web-/Mobile-Clients ausliefern.
Ergebnis: Änderungen am internen Entitätsmodell wirken sich nicht unmittelbar auf die öffentliche API-Struktur aus.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/WebServices (Verzeichnisstruktur), z. B. DunningConfiguration.cs unter WebServices/ObjectMapperConfiguration – Begründung: dedizierte Mapper-Konfigurationsklassen belegen bewusste DTO-Trennung.
Prüfidee: Ein internes Entitätsfeld ohne DTO-Mapping ist über die API nicht sichtbar.
Tracelinks: StRS-61
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - API-Stabilität ist für SaaS-Zielsystem essenziell.
Status: belegt
```
```
ID: SyRS-5
Titel: Echtzeit-Benachrichtigung über SignalR-artigen Hub
Ebene: SyRS
Typ: Performance
Qualitätsmerkmal: Zeitverhalten
Akteur: Nexus-Nutzer
Vorbedingung: Nutzer ist mit Nexus verbunden.
Fakt: `NotificationsHubHelper.cs` (`src/backend/Centron.BL/NexusNotifications`), `RealTimeServices` (`src/webservice/Centron.Host`).
Aussage: Das System soll Benachrichtigungen an verbundene Nexus-Clients ohne Polling in Echtzeit über einen Push-Kanal zustellen.
Ergebnis: Eine serverseitige Änderung erreicht verbundene Clients innerhalb weniger Sekunden ohne aktives Nachfragen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/NexusNotifications/NotificationsHubHelper.cs, src/webservice/Centron.Host/RealTimeServices – Begründung: „Hub"/„RealTimeServices"-Namensgebung an zwei unabhängigen Stellen belegt konsistent eine Push-Architektur.
Prüfidee: Ein neues Ticket löst innerhalb von 5 Sekunden eine sichtbare Benachrichtigung im verbundenen Nexus-Client aus.
Tracelinks: StRS-44
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Echtzeitfähigkeit ist Nutzererwartung an moderne Web-Anwendungen.
Status: HYPOTHESE
```
```
ID: SyRS-6
Titel: Volltextindex mit inkrementeller und Vollaktualisierung
Ebene: SyRS
Typ: Performance
Qualitätsmerkmal: Zeitverhalten
Akteur: System (Hintergrunddienst)
Vorbedingung: –
Fakt: `IndexSearchBL.UpdateAllIndexes(token)` vs. `UpdateRequestedIndexes(token)` mit `CancellationToken`-Unterstützung.
Aussage: Das System soll den Suchindex sowohl vollständig als auch inkrementell (nur angeforderte Objekte) aktualisieren können, wobei die Aktualisierung abbrechbar ist.
Ergebnis: Eine inkrementelle Aktualisierung benötigt deutlich weniger Zeit als eine Vollaktualisierung und ist jederzeit abbrechbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs, Methoden UpdateAllIndexes/UpdateRequestedIndexes, Parameter CancellationToken – Begründung: konkrete, im Code umgesetzte Unterscheidung zweier Aktualisierungsmodi mit Abbruchunterstützung.
Prüfidee: Ein Abbruch über das CancellationToken während einer Vollaktualisierung stoppt den Index-Build nachweislich vorzeitig.
Tracelinks: StRS-32
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Performance-kritisch bei großen Datenbeständen.
Status: belegt
```
```
ID: SyRS-7
Titel: Blacklist-Prüfung vor E-Mail-Versand
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Eine E-Mail soll versendet werden.
Fakt: `src/backend/Centron.BL/Mail/Blacklist` (Unterordner, eigenständiger Baustein neben `MailFormatting`/`Templates`).
Aussage: Das System soll vor jedem automatisierten E-Mail-Versand eine Blacklist-Prüfung des Empfängers durchführen.
Ergebnis: Eine Adresse auf der Blacklist erhält keine automatisierten E-Mails, unabhängig vom auslösenden Fachprozess.
Belege:
- [KONTEXT] src/backend/Centron.BL/Mail/Blacklist (Verzeichnisname) – Begründung: dedizierter Baustein belegt Existenz einer Blacklist-Prüfung; konkrete Verankerung im Versandpfad nicht gelesen.
Prüfidee: Noch zu bestimmen – Vertiefung in Folge-Iteration erforderlich (Prüfung, ob wirklich jeder Versandpfad die Blacklist konsultiert).
Tracelinks: StRS-36
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da Beleg dünn.
Status: HYPOTHESE
```
```
ID: SyRS-8
Titel: Lizenzprüfung als systemweiter Cross-Cutting-Concern
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System
Vorbedingung: –
Fakt: `LicenseManager.Instance.HasLicense(LicenseGuids.X)` wird konsistent in `ProductionOrderBL` (drei Methoden) sowie separat in `AppUserBL`/`UsersBL` (Konstruktorabhängigkeit `ILicenseManager`) verwendet.
Aussage: Das System soll Lizenzprüfungen einheitlich über eine zentrale `LicenseManager`-Komponente durchführen, die von mehreren, unabhängigen Fachmodulen genutzt wird.
Ergebnis: Jede lizenzpflichtige Funktion prüft konsistent gegen dieselbe zentrale Lizenzquelle.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs (3 Prüfstellen), src/backend/Centron.BL/EmployeeArea/AppUserBL.cs (Konstruktorinjektion ILicenseManager) – Begründung: identisches Muster an mindestens zwei unabhängigen Fachbereichen belegt systemweite Konsistenz.
Prüfidee: Ein Entzug der Produktionsmanagement-Lizenz sperrt sofort alle drei geprüften ProductionOrderBL-Methoden.
Tracelinks: StRS-53
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zentrales Lizenzmodell ist Grundlage kommerzieller SaaS-Tarifierung.
Status: belegt
```
```
ID: SyRS-9
Titel: Mehrsprachige Produktdatenanreicherung über zwei parallele Anbieter
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Artikel besitzt Herstellerreferenz.
Fakt: `Centron.APIs.ITscopeDataAccess` und `Centron.APIs.IcecatDataAccess` sind zwei unabhängige, strukturell gleichartige API-Clients für denselben fachlichen Zweck (Produktdatenanreicherung); `Languages.cs` in Icecat belegt Mehrsprachigkeit.
Aussage: Das System soll Produktdaten wahlweise über ITscope oder Icecat anreichern, wobei beide Anbindungen unabhängig konfigurierbar sind.
Ergebnis: Ein Artikel kann je nach Konfiguration über den einen oder anderen Anbieter angereichert werden.
Belege:
- [SEKUNDÄR] src/apis/Centron.APIs.ITscopeDataAccess, src/apis/Centron.APIs.IcecatDataAccess (Strukturvergleich) – Begründung: strukturelle Parallelität zweier unabhängiger API-Projekte für denselben Zweck.
Prüfidee: Ein Artikel mit sowohl ITscope- als auch Icecat-Referenz lässt sich wahlweise über beide Quellen anreichern.
Tracelinks: StRS-67, StRS-68
Konsolidierung: Kandidat: StRS-67, StRS-68 – Begründung: siehe dortige Konsolidierungsvermerke.
Übernahmewürdigkeit: übernehmen - im Zielsystem hinter einer einheitlichen Produktdaten-Fassade zu konsolidieren.
Status: belegt
```
```
ID: SyRS-10
Titel: Multi-Carrier-Versandlabel-Erzeugung
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Lieferschein ist versandbereit.
Fakt: `Centron.Api.Gls` und `Centron.Api.Shipcloud` sind zwei strukturell parallele Versand-API-Projekte (`CentronXxxLogic.cs`, `CentronXxxConsts.cs`, `CentronXxxErrors.cs`).
Aussage: Das System soll Versandlabels wahlweise über GLS direkt oder über den Multi-Carrier-Dienst Shipcloud erzeugen können.
Ergebnis: Ein Lieferschein kann je nach konfiguriertem Carrier ein gültiges Label erzeugen.
Belege:
- [SEKUNDÄR] src/apis/Centron.Api.Gls, src/apis/Centron.Api.Shipcloud (Strukturvergleich identischer Klassenmuster) – Begründung: identisches Namensschema belegt bewusst parallele, austauschbare Implementierung.
Prüfidee: Ein Testversand erzeugt sowohl über GLS als auch über Shipcloud jeweils ein gültiges, scanbares Label.
Tracelinks: StRS-70, StRS-71
Konsolidierung: Kandidat: StRS-70, StRS-71
Übernahmewürdigkeit: übernehmen - im Zielsystem hinter einer einheitlichen Versand-Fassade zu konsolidieren.
Status: belegt
```
```
ID: SyRS-11
Titel: Report-Ausgabe über mehrere Kanäle
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Report wird ausgeführt.
Fakt: `ReportsBL.ReportDefaultValues`-Enum (Email = 1, PDF = 2, Print = 4) – Bitmasken-Werte deuten auf kombinierbare Ausgabewege hin.
Aussage: Das System soll einen Report gleichzeitig über mehrere Ausgabewege (E-Mail, PDF-Ablage, Druck) ausgeben können.
Ergebnis: Ein Report mit kombiniertem Standardwert (z. B. Email+PDF) wird über beide Kanäle gleichzeitig ausgegeben.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Reporting/ReportsBL.cs, Enum ReportDefaultValues mit Zweierpotenz-Werten (1, 2, 4) – Begründung: Zweierpotenzwerte sind ein im Code erkennbares Bitmasken-Muster für kombinierbare Optionen.
Prüfidee: Ein Report mit dem kombinierten Wert 3 (Email+PDF) erzeugt sowohl eine E-Mail als auch eine abgelegte PDF-Datei.
Tracelinks: StRS-56, StRS-57
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - flexible Ausgabesteuerung ist im Tagesgeschäft nützlich.
Status: belegt
```
```
ID: SyRS-12
Titel: Steuersatzkette über verkettete Nachfolgesätze
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Ein Steuersatzwechsel ist konfiguriert.
Fakt: `TaxBL.GetActiveVatThroughNextVats(vatI3D, compareTo)` durchläuft `vat.NextTaxRate`, solange das Ablaufdatum vor dem Vergleichsdatum liegt.
Aussage: Das System soll historische und zukünftige Steuersätze als verkettete Liste (`NextTaxRate`) modellieren, sodass zu jedem Stichtag der korrekte Satz ermittelbar ist.
Ergebnis: Auch bei mehreren aufeinanderfolgenden Steuersatzwechseln liefert eine Stichtagsabfrage den korrekten Satz.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Warehousing/TaxBL.cs, Methode GetActiveVatThroughNextVats, Schleife über NextTaxRate – Begründung: konkrete, im Code umgesetzte Verkettungslogik.
Prüfidee: Bei drei aufeinanderfolgenden Steuersatzwechseln liefert eine Abfrage für einen Stichtag zwischen dem zweiten und dritten Wechsel den zweiten Satz.
Tracelinks: StRS-59
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - gesetzlich erforderliche Korrektheit über Zeit.
Status: belegt
```
```
ID: SyRS-13
Titel: Konfigurierbare Standard-Ausgabewege je Beleg (Textbausteine)
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: –
Fakt: `TextModuleBL` cached sechs belegartspezifische Textbaustein-Paare (Anrede/Abschluss).
Aussage: Das System soll beim Rendern eines Belegs automatisch die zur Belegart passenden Textbausteine ohne manuelle Auswahl durch den Benutzer einsetzen.
Ergebnis: Der Benutzer muss die Anrede/Grußformel nicht manuell auswählen; das System wählt sie belegartabhängig automatisch.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/TextModuleArea/TextModuleBL.cs, sechs Cache-Felder – Begründung: Cache-Struktur belegt automatische, belegartabhängige Vorbelegung.
Prüfidee: Beim Erzeugen einer Rechnung wird automatisch die Rechnungs-Anrede eingesetzt, nicht die Angebots-Anrede.
Tracelinks: StRS-111
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - reduziert manuellen Aufwand und Fehlerquote.
Status: belegt
```
```
ID: SyRS-14
Titel: Automatische Registrierung neuer Anwendungsmodule beim Start
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Anwendung wird gestartet.
Fakt: `ModuleBL.DoCreateMissingInternalModulesInDB` vergleicht Code-Modulliste (`ModuleGuid`) mit DB-Bestand und legt fehlende Module an.
Aussage: Das System soll beim Anwendungsstart automatisch prüfen, welche im Code definierten Module in der Datenbank noch fehlen, und diese anlegen.
Ergebnis: Nach einem Update mit neuen Modulen ist kein manueller Datenbankschritt notwendig.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Modules/ModuleBL.cs, Methode DoCreateMissingInternalModulesInDB – Begründung: konkreter, im Code durchgesetzter Abgleichsalgorithmus.
Prüfidee: Nach Hinzufügen eines neuen Moduls mit neuer GUID im Code erscheint dieses nach dem ersten Start automatisch in der Modultabelle.
Tracelinks: StRS-41
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - reduziert Update-Aufwand.
Status: belegt
```
```
ID: SyRS-15
Titel: Eindeutige Objekt-Identifikation bei überlappenden I3D-Bereichen
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Ein Nutzer ist entweder Mitarbeiter oder Web-Account.
Fakt: `NexusTicketViewBL.GetUserI3D`/`GetCreatedByObjectKind` unterscheiden explizit `IsWebAccountLogin`, da Mitarbeiter- und Web-Account-I3Ds denselben Nummernraum teilen können.
Aussage: Das System soll bei der Identifikation eines Nutzers stets die Kombination aus I3D und Objektart (Mitarbeiter/Web-Account) verwenden, um Verwechslungen bei überlappenden I3D-Bereichen zu vermeiden.
Ergebnis: Ein Mitarbeiter und ein Web-Account mit identischer I3D werden nie miteinander verwechselt.
Belege:
- [PRIMÄR] src/backend/Centron.BL/NexusTicketViews/NexusTicketViewBL.cs, Methoden GetUserI3D/GetCreatedByObjectKind – Begründung: im Code umgesetzte, explizit dokumentierte Unterscheidung (siehe XML-Doc-Kommentar im Quelltext).
Prüfidee: Ticketansichten von Mitarbeiter I3D=5 und Web-Account I3D=5 werden getrennt gespeichert und angezeigt.
Tracelinks: StRS-45
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - grundlegendes Korrektheitsmuster, im Zielsystem beizubehalten (z. B. über zusammengesetzten Schlüssel).
Status: belegt
```
```
ID: SyRS-16
Titel: Konfigurierbare Sichtbarkeit von Helpdesk-Zeitfeldern
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: –
Fakt: `CalendarBL.GetCalendarRepresentationSettings` liest zehn unabhängige Boolean-Konfigurationsschalter.
Aussage: Das System soll die Sichtbarkeit von zehn unterschiedlichen Informationsfeldern einer Helpdesk-Zeitbuchung unabhängig voneinander konfigurierbar machen.
Ergebnis: Jeder der zehn Schalter kann unabhängig von den übrigen aktiviert/deaktiviert werden.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Calendar/CalendarBL.cs, zehn AppSettingsConst.HelpdeskTimeDisplay*-Schalter – Begründung: konkrete Konfigurationsschalter belegen granulare Steuerung.
Prüfidee: Deaktivieren eines einzelnen Schalters (z. B. RMA-Anzeige) ändert nicht das Verhalten der übrigen neun Schalter.
Tracelinks: StRS-10
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Konfigurierbarkeit wird von Kunden genutzt.
Status: belegt
```
```
ID: SyRS-17
Titel: Aktivstatusfilterung für mobile Mitarbeiterdaten
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Mobile Anwendung
Vorbedingung: –
Fakt: `MobileBL.GetMobileEmployee()` filtert `NewMobileEmployee` nach `State == 1`.
Aussage: Das System soll der mobilen Anwendung ausschließlich aktive Mitarbeiterdatensätze bereitstellen.
Ergebnis: Ein deaktivierter Mitarbeiter erscheint nicht in der mobilen Mitarbeiterliste.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Mobile/MobileBL.cs, Filter State == 1 – Begründung: konkrete, im Code durchgesetzte Filterbedingung.
Prüfidee: Ein auf inaktiv gesetzter Mitarbeiter verschwindet aus der Antwort von GetMobileEmployee().
Tracelinks: StRS-40
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - magischer Zahlenwert „State == 1" ohne erkennbares Enum ist im Zielsystem zu klären/zu ersetzen.
Status: belegt
```
```
ID: SyRS-18
Titel: Abbrechbare, deadlocksichere Telemetrie-Aggregation
Ebene: SyRS
Typ: Performance
Qualitätsmerkmal: Zeitverhalten
Akteur: System
Vorbedingung: –
Fakt: `TelemetryBL.UpsertMcpToolUsageBatch` verwendet `MERGE ... WITH (HOLDLOCK)` mit Deadlock-Retry-Kommentar.
Aussage: Das System soll Telemetrie-Batch-Updates unter hoher Parallelität ohne doppelte Zählung und mit automatischem Deadlock-Retry verarbeiten.
Ergebnis: Ein Deadlock bei paralleler Aktualisierung führt zu einem automatischen Retry statt zu einem sichtbaren Fehler.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Telemetry/TelemetryBL.cs, Methode UpsertMcpToolUsageBatch, Kommentar zu SQL-Fehlercode 1205 (Deadlock) und Retry – Begründung: konkrete, im Code dokumentierte Retry-Strategie für einen benannten SQL-Fehlercode.
Prüfidee: Ein simulierter Deadlock (Fehlercode 1205) während des Merge führt zu einem erfolgreichen Retry statt einem Fehlschlag.
Tracelinks: StRS-110
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - technisch robuste Umsetzung.
Status: belegt
```
```
ID: SyRS-19
Titel: DSGVO-Löschprotokollierung mit Bearbeiterzuordnung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: System
Vorbedingung: DSGVO-Löschanfrage wird bearbeitet.
Fakt: `DataSecurityBL`, Konstante `DsgvoDeletedContactMessageWithEmployeeInfo = "DSGVO: Auf Anfrage gelöscht. (Durchgeführt von {0} am {1:d} um {1:t} Uhr)"`.
Aussage: Das System soll bei DSGVO-bedingter Löschung eines Kontakts den ausführenden Mitarbeiter und den Zeitpunkt der Löschung nachvollziehbar im verbleibenden Datensatz vermerken.
Ergebnis: Ein gelöschter Kontakt trägt einen Vermerk mit Bearbeiter und Zeitstempel statt vollständig zu verschwinden.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Konstante DsgvoDeletedContactMessageWithEmployeeInfo – Begründung: konkreter, im Code hinterlegter Nachrichtentext mit Platzhaltern für Bearbeiter/Zeitpunkt.
Prüfidee: Eine DSGVO-Löschung durch Mitarbeiter „M. Muster" am 26.08.2026 hinterlässt exakt diesen Namen und dieses Datum im Vermerk.
Tracelinks: StRS-128
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Nachvollziehbarkeit ist DSGVO-Grundprinzip (Rechenschaftspflicht).
Status: belegt
```
```
ID: SyRS-20
Titel: Umgebungsspezifische Konfiguration der Nexus-Anwendung
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Übertragbarkeit
Akteur: Betrieb/IT
Vorbedingung: –
Fakt: `CentronNexus.Host/appsettings.json` vs. `appsettings.Development.json`.
Aussage: Das System soll für die Nexus-Anwendung umgebungsspezifische Konfigurationsdateien unterstützen, die sich ohne Codeänderung austauschen lassen.
Ergebnis: Ein Wechsel der ASP.NET-Core-Umgebungsvariable lädt automatisch die passende Konfiguration.
Belege:
- [SEKUNDÄR] src/nexus/CentronNexus.Host/appsettings.Development.json, appsettings.json – Begründung: getrennte Dateien belegen Standard-ASP.NET-Core-Konfigurationsmechanismus.
Prüfidee: Start mit `ASPNETCORE_ENVIRONMENT=Development` lädt nachweislich abweichende Werte aus der Development-Datei.
Tracelinks: StRS-77
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Standardmuster, im Zielsystem fortzuführen.
Status: belegt
```
```
ID: SyRS-21
Titel: Containerbasierte Referenzumgebung für Tests
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Testbarkeit / Übertragbarkeit
Akteur: Entwickler, CI-System
Vorbedingung: –
Fakt: `docker/c-entron-regression-tests-db`, `docker/c-entron-regression-tests-pipeline`, `docker/c-entron-mailcatcher`.
Aussage: Das System soll für Regressionstests eine containerisierte Referenzdatenbank sowie einen Mailcatcher zum Abfangen von Test-E-Mails bereitstellen.
Ergebnis: Regressionstests laufen reproduzierbar gegen eine isolierte, containerisierte Umgebung ohne echten Mailversand.
Belege:
- [SEKUNDÄR] docker/c-entron-regression-tests-db, docker/c-entron-mailcatcher (Verzeichnisnamen) – Begründung: dedizierte Testinfrastruktur-Container belegen etablierte automatisierte Testpraxis.
Prüfidee: Eine während eines Regressionstests versendete E-Mail landet nachweislich im Mailcatcher, nicht bei einem echten Empfänger.
Tracelinks: StRS-92
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - wichtige Grundlage für sichere, automatisierte Testläufe.
Status: HYPOTHESE
```
```
ID: SyRS-22
Titel: Rekursive Kategoriehierarchie mit Zyklusrisiko
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: –
Fakt: `ChecklistVirtualObjectCategoryBL.GetChecklistVirtualObjectCategoriesByFilter` lädt Elternkategorien iterativ über eine `while`-Schleife auf Basis von `ParentI3D`, ohne erkennbare Zyklus-/Tiefenbegrenzung im gelesenen Ausschnitt.
Aussage: Das System soll beim rekursiven Laden von Kategoriehierarchien auch bei tiefen oder fehlerhaft zyklischen Strukturen determiniert terminieren.
Ergebnis: Das Laden einer Kategoriehierarchie terminiert auch im Fehlerfall (zyklische Elternreferenz) in endlicher Zeit.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs, `while(recentlyAddedI3Ds.Count > 0)`-Schleife ohne erkennbare Zyklusprüfung – Begründung: im gelesenen Code ist keine Zyklus- oder Tiefenbegrenzung erkennbar, was bei einer versehentlichen Selbstreferenz zu einer Endlosschleife führen könnte.
Prüfidee: Eine Kategorie, deren `ParentI3D` (versehentlich) auf sich selbst oder einen ihrer Nachfahren verweist, führt nicht zu einer Endlosschleife.
Tracelinks: StRS-34
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Funktionalität selbst übernehmenswert, Zyklusschutz ist im Zielsystem ergänzend zu implementieren.
Status: HYPOTHESE
```
```
ID: SyRS-23
Titel: Sperrung von Bankverbindungen ohne Autorisierung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: Kunde besitzt mehrere Bankverbindungen.
Fakt: `BankAccountBL.GetBankAccountsFromCustomer(customerI3D, onlyAuthorized)`.
Aussage: Das System soll bei entsprechendem Aufrufparameter ausschließlich autorisierte Bankverbindungen eines Kunden zurückliefern.
Ergebnis: Eine SEPA-relevante Funktion, die `onlyAuthorized=true` verwendet, erhält keine nicht autorisierten Bankverbindungen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Accounting/BankAccountBL.cs, Methode GetBankAccountsFromCustomer, Parameter onlyAuthorized – Begründung: konkreter, im Code umgesetzter Filterparameter.
Prüfidee: Ein Kunde mit einer autorisierten und einer nicht autorisierten Bankverbindung liefert bei `onlyAuthorized=true` nur eine Verbindung.
Tracelinks: StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - verhindert fehlerhafte Lastschriften von nicht autorisierten Konten.
Status: belegt
```
```
ID: SyRS-24
Titel: Rechtegeschützter Zugriff auf den Virtual-Mail-Assistant
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: –
Fakt: `MailScannerBL.GetProfiles` prüft `_appRightsBl.CheckRightsFromUser(loggedInUser.UserI3D.Value, UserRightsConst.VirtualMailAssistant.ACCESS_VMA_MODULE)`.
Aussage: Das System soll den Zugriff auf Mail-Scanner-Profile serverseitig gegen ein dediziertes Recht prüfen, bevor Profildaten zurückgegeben werden.
Ergebnis: Ein Aufruf ohne das Recht liefert keine Profildaten.
Belege:
- [PRIMÄR] src/backend/Centron.BL/MailScanner/MailScannerBL.cs, Methode GetProfiles, Zeile 59f. – Begründung: konkrete, im Code durchgesetzte Rechteprüfung vor Datenrückgabe.
Prüfidee: Ein Testbenutzer ohne ACCESS_VMA_MODULE erhält bei GetProfiles keine Profildaten.
Tracelinks: StRS-37
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - E-Mail-Verarbeitungsregeln sind sensibel und entsprechend zu schützen.
Status: belegt
```
```
ID: SyRS-25
Titel: Rechtegeschützte Video-Portal-Zuweisung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: –
Fakt: `VideoPortalAssignmentBL.SaveVideoPortalAssignment` prüft `UserRightsConst.VideoPortal.ASSIGNMENT` und wirft andernfalls `ResultException`.
Aussage: Das System soll das Speichern einer Video-Portal-Zuweisung serverseitig gegen ein dediziertes Recht absichern.
Ergebnis: Ein Speicherversuch ohne das Recht wird mit einer Exception abgelehnt, es werden keine Daten persistiert.
Belege:
- [PRIMÄR] src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs, Methode SaveVideoPortalAssignment, Zeile 30–32 – Begründung: konkrete, durchgesetzte Rechteprüfung vor dem Speichervorgang.
Prüfidee: Ein Speicherversuch ohne das Recht ASSIGNMENT hinterlässt keinen neuen/geänderten Datensatz in der Datenbank.
Tracelinks: StRS-120
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - konsistentes Rechtekonzept.
Status: belegt
```
```
ID: SyRS-26
Titel: Konsistente Enum-basierte Statusfilterung bei Gutscheinen
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System
Vorbedingung: –
Fakt: `VoucherManagementBL.GetActivedVoucherBarcodes` verwendet drei unabhängige Boolean-Parameter statt eines Status-Enums.
Aussage: Das System soll Gutschein-Status eindeutig und überschneidungsfrei abfragbar machen.
Ergebnis: Die Kombination der drei Filterparameter liefert eine eindeutige, nicht widersprüchliche Ergebnismenge.
Belege:
- [PRIMÄR] src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs, Methode GetActivedVoucherBarcodes – Begründung: vollständig gelesene Filterlogik mit drei unabhängigen Bool-Parametern.
Prüfidee: Eine Abfrage mit widersprüchlichen Kombinationen (z. B. „frei" und „eingelöst" gleichzeitig `true`) liefert ein für Fachanwender nachvollziehbares, dokumentiertes Ergebnis.
Tracelinks: StRS-121
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - drei unabhängige Booleans statt eines Status-Enums sind im Zielsystem zu einem eindeutigen Statusmodell zu konsolidieren.
Status: HYPOTHESE
```
```
ID: SyRS-27
Titel: Named-Query-basierter Zugriff auf sicherheitsrelevante 2FA-Daten
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: –
Fakt: `TwoFactorAuthenticationBL` liest/schreibt den 2FA-Schlüssel ausschließlich über parametrisierte Named Queries (`NamedQueryEnums.PasswordManager.GetAppUserTwoFactorAuthKey`/`UpdateAppUserTwoFactorAuthKey`), nicht über dynamisch zusammengesetztes SQL.
Aussage: Das System soll den Zugriff auf 2FA-Schlüssel ausschließlich über parametrisierte, vordefinierte Abfragen abwickeln, um SQL-Injection auszuschließen.
Ergebnis: Es existiert kein Codepfad, der 2FA-Schlüssel über dynamisch mit Benutzereingaben zusammengesetztes SQL liest/schreibt.
Belege:
- [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, durchgängige Verwendung von NamedQueryParameter statt String-Konkatenation – Begründung: vollständig gelesene Klasse zeigt konsequent parametrisierten Zugriff.
Prüfidee: Ein Penetrationstest mit SQL-Metazeichen im PIN-Feld führt zu keiner SQL-Injection.
Tracelinks: StRS-118
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - sicheres Zugriffsmuster ist im Zielsystem beizubehalten.
Status: belegt
```
```
ID: SyRS-28
Titel: Serverseitige Filialbeschränkung für Rechtegruppenverwaltung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: Benutzer besitzt das einschränkende Recht MANAGE_RIGHTS_ONLY_OWN_BRANCH.
Fakt: `AppRightsBL.GetAllRightGroups(currentUser)` filtert serverseitig nach `BranchI3D`, wenn das einschränkende Recht vorliegt.
Aussage: Das System soll die in `CentronRights.md` dokumentierten „einschränkenden Rechte" (restricting rights) serverseitig als Datenfilter umsetzen, nicht nur als UI-Sichtbarkeitsregel.
Ergebnis: Ein Benutzer mit einschränkendem Recht erhält serverseitig gefilterte Daten, unabhängig von der aufrufenden Oberfläche.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode GetAllRightGroups, Zeile 42–47 – Begründung: konkrete, serverseitig durchgesetzte Filterlogik, nicht nur UI-Ausblendung.
Prüfidee: Ein direkter API-Aufruf (unter Umgehung der Desktop-UI) durch einen filialbeschränkten Benutzer liefert weiterhin nur Gruppen der eigenen Filiale.
Tracelinks: StRS-90, SyRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - serverseitige Durchsetzung ist zwingend für ein sicheres SaaS-Zielsystem.
Status: belegt
```
```
ID: SyRS-29
Titel: Robuste Fehlerbehandlung bei fehlenden Zwei-Faktor-Schlüsseln
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Benutzer hat noch keinen 2FA-Schlüssel hinterlegt.
Fakt: `TwoFactorAuthenticationBL.ValidateAuthenticationPin` liefert bei fehlendem Schlüssel die Fehlermeldung „Ihrem Benutzer ist kein Zwei-Faktor Schlüssel in der Personalverwaltung hinterlegt!" statt eines technischen Fehlers.
Aussage: Das System soll bei fehlendem 2FA-Schlüssel eine fachlich verständliche Fehlermeldung statt eines technischen Fehlers liefern.
Ergebnis: Ein Benutzer ohne hinterlegten Schlüssel erhält eine klare Handlungsanweisung statt eines kryptischen Fehlers.
Belege:
- [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, Methode ValidateAuthenticationPin, Zeile 47–49 – Begründung: konkrete, im Code hinterlegte, fachlich verständliche Fehlermeldung.
Prüfidee: Ein Benutzer ohne hinterlegten Schlüssel erhält exakt diese Fehlermeldung beim Anmeldeversuch mit 2FA.
Tracelinks: StRS-118
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - gute Usability-Praxis, im Zielsystem beizubehalten.
Status: belegt
```
---
## Risikofokussierte Vertiefung (Rechte, Authentifizierung, Fakturierung, Datenschutz)
```
ID: SyRS-30
Titel: Zeitgesteuerte Kontoaktivierung/-deaktivierung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: Konto besitzt ggf. `AccountDisabledFromDate`/`AccountDisabledToDate`.
Fakt: `AppUserBL.GetActiveAppUsers()`, drei Fallunterscheidungen: (a) kein Zeitraum gesetzt → aktiv, wenn `IsAccountDisabled == false`; (b) nur `FromDate` gesetzt → aktiv, wenn heute vor `FromDate` ODER (`ToDate` gesetzt und heute nach `ToDate`); (c) analog für `ToDate`.
Aussage: Das System soll den Aktivstatus eines Kontos bei jedem sicherheitsrelevanten Zugriff serverseitig unter Berücksichtigung des aktuellen Datums neu berechnen, nicht anhand eines zwischengespeicherten Status-Flags.
Ergebnis: Ein Konto, dessen Deaktivierungszeitraum gerade abgelaufen ist, wird beim nächsten Zugriff korrekt als aktiv erkannt, ohne dass ein Batch-Job das Flag zurücksetzen muss.
Belege:
- [PRIMÄR] src/backend/Centron.BL/EmployeeArea/AppUserBL.cs, Methode GetActiveAppUsers, Zeilen 38–50 – Begründung: die vollständig gelesene, dreistufige Datumslogik wird bei jedem Aufruf neu ausgewertet (kein persistiertes „berechnetes" Aktiv-Flag erkennbar).
Prüfidee: Ein Konto mit `AccountDisabledToDate = gestern` erscheint in `GetActiveAppUsers()`, ohne dass zuvor ein Wartungsjob lief.
Tracelinks: StRS-24, StRS-126
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - korrekte, serverseitig neu berechnete Zeitlogik statt zwischengespeichertem Status ist ein gutes Muster für das Zielsystem.
Status: belegt
```
```
ID: SyRS-31
Titel: Rechtegeschützter Zugriff auf den Passwortmanager
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: –
Fakt: `PasswordManagerBL` injiziert `AppRightsBL` im Konstruktor; konkrete Prüfmethode innerhalb der Klasse wurde in dieser Iteration nicht vollständig gelesen (nur Konstruktor-Ausschnitt).
Aussage: Das System soll den Zugriff auf im Passwortmanager hinterlegte Zugangsdaten serverseitig gegen ein dediziertes Recht prüfen.
Ergebnis: Ein Benutzer ohne Passwortmanager-Zugriffsrecht kann keine hinterlegten Zugangsdaten einsehen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Konstruktorinjektion `AppRightsBL _appRightsBL` – Begründung: Injektion belegt Verfügbarkeit einer Rechteprüfung, die konkrete Prüfstelle (Methode, Rechte-ID) wurde nicht gelesen.
Prüfidee: Noch zu bestimmen – Vertiefung in Folge-Iteration erforderlich: konkrete Methode und Rechte-ID identifizieren, die den Zugriff tatsächlich absichert.
Tracelinks: StRS-50
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da Beleg dünn (nur Konstruktor gelesen).
Status: HYPOTHESE
```
```
ID: SyRS-32
Titel: Konsistente Lizenzsperre für Produktionsaufträge
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: –
Fakt: `ProductionOrderBL.GetProductionOrderByI3D`, `GetProductionOrdersByFilter`, `SaveProductionOrder` prüfen jeweils identisch `LicenseManager.Instance.HasLicense(LicenseGuids.ProductionManagement)` vor jeder Operation (Lesen, Filtern, Schreiben).
Aussage: Das System soll die Lizenzprüfung für Produktionsaufträge konsistent auf alle CRUD-Operationen anwenden, nicht nur auf einzelne Einstiegspunkte.
Ergebnis: Es existiert keine Produktionsauftrags-Operation, die die Lizenzprüfung umgeht.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs, alle drei genannten Methoden – Begründung: identische Prüfung an allen drei beobachteten Einstiegspunkten belegt Konsistenz innerhalb der gelesenen Klasse.
Prüfidee: Alle drei Methoden (Lesen per I3D, Filtern, Speichern) lösen ohne gültige Lizenz identisch eine Exception aus.
Tracelinks: StRS-53
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - konsistente Durchsetzung ist Grundlage des Lizenzmodells.
Status: belegt
```
```
ID: SyRS-33
Titel: Zweistufige Autorisierung: UI-Sichtbarkeit und Server-Durchsetzung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: –
Fakt: Client: `ModuleRightsExpressionParser.cs` steuert Ribbon-Sichtbarkeit im WPF-Client. Server: `AuthorizeUserRightAttribute`/`UserRightAuthorizationFilter` prüft REST-Aufrufe unabhängig vom Client mit 401/403.
Aussage: Das System soll Rechte nicht nur clientseitig zur Steuerung der UI-Sichtbarkeit, sondern zwingend auch serverseitig bei jedem API-Aufruf durchsetzen, sodass eine manipulierte oder umgangene Client-UI keinen unautorisierten Zugriff ermöglicht.
Ergebnis: Ein direkter API-Aufruf unter Umgehung der Desktop-UI wird serverseitig identisch geprüft wie ein Aufruf über die UI.
Belege:
- [PRIMÄR] src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs, Klasse UserRightAuthorizationFilter – Begründung: serverseitiger Filter ist unabhängig vom aufrufenden Client aktiv, damit durchgesetzte (nicht nur angezeigte) Autorisierung.
Prüfidee: Ein direkter HTTP-Aufruf (z. B. via curl) ohne das erforderliche Recht liefert 403, unabhängig davon, ob der WPF-Client die Funktion anzeigen würde.
Tracelinks: StRS-72, StRS-87
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Zwei-Ebenen-Autorisierung (UX-Hinweis + harte Durchsetzung) ist Best Practice und im Zielsystem beizubehalten.
Status: belegt
```
```
ID: SyRS-34
Titel: Verschlüsselte Speicherung von Drittanbieter-API-Schlüsseln
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: –
Fakt: `OpenAiApiClient` entschlüsselt `_settings.ApiKey` über `CryptoControl.DecryptString` unmittelbar vor Verwendung als Bearer-Token; derselbe verschlüsselte Speicheransatz wird für das PDF-Signatur-TSA-Passwort verwendet (`PdfSigningBL`, `AESCryptoLogic`).
Aussage: Das System soll alle Drittanbieter-API-Schlüssel und -Zugangsdaten grundsätzlich verschlüsselt speichern und erst zur Laufzeit entschlüsseln – ein Muster, das an mindestens zwei unabhängigen Stellen (KI-API, PDF-Signatur-TSA) konsistent umgesetzt ist.
Ergebnis: Ein direkter Blick in die Konfigurationsdatenbank zeigt für keinen der geprüften Schlüssel den Klartext.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ArtificialIntelligence/OpenAiApiClient.cs, CryptoControl.DecryptString; src/backend/Centron.BL/Security/PdfSigningBL.cs, AESCryptoLogic.DecryptText – Begründung: identisches Verschlüsselungsmuster an zwei unabhängigen Stellen belegt einen systemweiten, konsistenten Sicherheitsstandard für Drittanbieter-Zugangsdaten.
Prüfidee: Weder der KI-API-Schlüssel noch das TSA-Passwort sind bei direkter Datenbankabfrage im Klartext lesbar.
Tracelinks: StRS-124, StRS-133
Konsolidierung: Kandidat: StRS-124, StRS-133 – Begründung: beide Anforderungen setzen dasselbe technische Verschlüsselungsmuster (AES-Verschlüsselung sensibler Zugangsdaten) an unterschiedlichen Stellen um; im Zielsystem als ein zentraler Secret-Store zu konsolidieren.
Übernahmewürdigkeit: übernehmen - konsistentes Verschlüsselungsmuster ist Mindeststandard, im Zielsystem idealerweise über einen zentralen Secret-Manager (z. B. Azure Key Vault) statt anwendungseigener AES-Logik.
Status: belegt
```
```
ID: SyRS-35
Titel: Verpflichtender zweiter Faktor bei jeder Basis-Anmeldung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: 2FA ist für den Benutzer aktiviert.
Fakt: `BasicAuthenticator.AuthenticateInternal` ruft `_twoFactorAuthBL.ValidateTwoFactor(...)` **nach** erfolgreicher Passwortprüfung auf; nur bei `ResultStatus.Success` wird die Anmeldung als erfolgreich gewertet, andernfalls wird trotz korrektem Passwort ein Fehler zurückgegeben.
Aussage: Das System soll die Anmeldung erst nach kumulativer Prüfung von Passwort UND zweitem Faktor als erfolgreich werten; ein korrektes Passwort allein darf niemals zur Anmeldung genügen, wenn 2FA aktiviert ist.
Ergebnis: Ein Angreifer mit gestohlenem, aber korrektem Passwort kann sich ohne gültigen zweiten Faktor nicht anmelden.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Methode AuthenticateInternal, Zeilen 60–70 – Begründung: der Kontrollfluss zeigt konkret, dass der Rückgabewert bei fehlgeschlagenem zweitem Faktor auf Fehler gesetzt wird, obwohl das Passwort bereits validiert war.
Prüfidee: Eine Anmeldung mit korrektem Passwort und abgelaufenem/falschem TOTP-Code schlägt fehl; dieselbe Anmeldung mit gültigem TOTP-Code gelingt.
Tracelinks: StRS-129
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - korrekte kumulative 2FA-Logik ist sicherheitskritisch und unverändert zu übernehmen.
Status: belegt
```
```
ID: SyRS-36
Titel: Fehlende Salzung bei der Passwort-Hash-Bildung im Anmeldepfad
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: –
Fakt: `BasicAuthenticator.AuthenticateInternal`, Zeile 46: `SHA1Decoder.GetDecodedSHA1String(Auth.Password.ToString())`, unmittelbar gefolgt vom Entwicklerkommentar „// TODO the password should be salted!!!“; identisches Muster in `UsersBL.cs` bei Passwortprüfung (Zeilen 65, 88) und -änderung (Zeile 107).
Aussage: Das System soll Passwörter niemals ohne benutzerindividuelles Salt hashen; das aktuelle System verstößt hiergegen nachweislich an mindestens vier unabhängigen Codestellen.
Ergebnis: Zwei Benutzer mit identischem Passwort erzeugen im aktuellen System denselben Hash-Wert, was Rainbow-Table-Angriffe gegen die gesamte Benutzerdatenbank erleichtert.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Zeile 46–48 – Begründung: unmittelbar durch Entwicklerkommentar im Code selbst bestätigter Mangel.
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/UsersBL.cs, Zeilen 65, 88, 107 – Begründung: dieselbe ungesalzene SHA1-Vergleichslogik wird durchgängig bei Passwortprüfung und -änderung verwendet, bestätigt also, dass es sich nicht um eine isolierte Ausnahme handelt.
Prüfidee: Zwei Testkonten mit identischem Passwort weisen im aktuellen System denselben gespeicherten `Password`-Wert auf.
Tracelinks: StRS-130, StRS-96
Konsolidierung: Kandidat: StRS-96 – Begründung: das ungenutzte `CryptoUtils.CreatePasswordHash` (mit Salt-Unterstützung) und die tatsächlich verwendete `SHA1Decoder`-Logik (ohne Salt) sind zwei parallele Implementierungen desselben fachlichen Zwecks „Passwort-Hashing" – klarer Konsolidierungsfall.
Übernahmewürdigkeit: veraltet - diese konkrete Implementierung darf nicht in das Zielsystem übernommen werden; zu ersetzen durch einen gesalzenen, adaptiven Hash-Algorithmus (Argon2id/bcrypt) mit Migrationsstrategie für Bestandspasswörter (Re-Hashing beim nächsten erfolgreichen Login).
Status: belegt
```
```
ID: SyRS-37
Titel: Pessimistische Beleg-Sperre mit rechtebasiertem Fremdentsperren
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Ein Beleg wird von einem Benutzer geöffnet/bearbeitet.
Fakt: `InvoiceSpecificLogic.TryLockReceipt(receiptI3D, appUser)` ruft `_lockBL.LockReceipt(...)`; `UnLockReceipt(receiptI3D, appUser, onlyIfLockedByCurrentUser)` erlaubt Entsperren durch Dritte nur mit Recht `UNLOCK_CUSTOMER_ATTACHMENTS`, gesteuert über den Parameter `onlyIfLockedByCurrentUser`.
Aussage: Das System soll Rechnungen während der Bearbeitung pessimistisch sperren; ein Entsperren durch einen anderen Benutzer als den Sperrenden soll nur mit einem gesonderten Recht möglich sein.
Ergebnis: Nur der sperrende Benutzer selbst oder ein Benutzer mit dem Entsperr-Recht kann eine gesperrte Rechnung freigeben.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, Methoden TryLockReceipt/UnLockReceipt, Zeilen 191–204 – Begründung: konkrete, im Code umgesetzte Sperr-/Entsperrlogik mit Rechteparameter.
Prüfidee: Benutzer A sperrt eine Rechnung; Benutzer B ohne das Entsperr-Recht erhält bei `UnLockReceipt(..., onlyIfLockedByCurrentUser: true)` eine Ablehnung, mit dem Recht gelingt das Entsperren.
Tracelinks: StRS-131, StRS-98
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Sperrmechanismus ist zentral für Datenintegrität bei paralleler Bearbeitung.
Status: belegt
```
```
ID: SyRS-38
Titel: Identisches Rechteprüfmuster für OPOS und Mahnwesen
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: –
Fakt: `OposBL.ThrowIfUserHasInsufficentRights` und `DunningBL.GetDunningCustomers` (Zeile 62) prüfen unabhängig voneinander dasselbe Recht `UserRightsConst.Controlling.Finances.Dunning` und werfen bei Fehlen eine Exception, statt gefilterte/leere Daten zurückzugeben.
Aussage: Das System soll bei fehlendem Finanz-Controlling-Recht den Zugriff auf OPOS- und Mahnwesen-Daten durch eine harte Exception unterbinden (fail-closed), nicht durch stille Filterung, um versehentliche Datenlecks bei Implementierungsfehlern zu vermeiden.
Ergebnis: Ein Programmierfehler, der die Rechteprüfung vergisst, würde zu einem sofort sichtbaren Fehler führen statt zu einer stillen Datenpreisgabe.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs, Methode ThrowIfUserHasInsufficentRights, Zeile 28–36; src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Zeile 62 – Begründung: beide Klassen setzen unabhängig voneinander dasselbe „fail-closed"-Muster (Exception statt gefilterter Rückgabe) für dasselbe Recht um.
Prüfidee: Ein Testbenutzer ohne das Recht `Controlling.Finances.Dunning` erhält bei beiden Funktionen eine Exception, keine leere oder teilweise Datenliste.
Tracelinks: StRS-132
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - fail-closed-Muster ist sicherheitstechnisch vorzuziehen und im Zielsystem beizubehalten.
Status: belegt
```
```
ID: SyRS-39
Titel: Administratorpflicht für qualifizierte Signatureinstellungen
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: –
Fakt: `PdfSigningBL.SavePdfSigningSettings`: `if (!currentUser.HasUserRight(UserRightsConst.Administration.SETTINGS))` vor jeder Änderung an Zertifikat/TSA-Konfiguration.
Aussage: Das System soll die Änderung sicherheitskritischer Signaturkonfiguration (Zertifikat, TSA-Zugangsdaten) ausschließlich Benutzern mit allgemeinem Administrationsrecht gestatten.
Ergebnis: Ein Benutzer ohne Administrationsrecht kann weder das Zertifikat zurücksetzen noch TSA-Zugangsdaten ändern.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs, Methode SavePdfSigningSettings, Zeile 60 – Begründung: konkrete, im Code durchgesetzte Rechteprüfung vor jeder sicherheitsrelevanten Änderung.
Prüfidee: Ein Benutzer ohne Administrationsrecht erhält bei `SavePdfSigningSettings` einen Fehler statt einer Änderung.
Tracelinks: StRS-133
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - konsistent mit dem übrigen Rechtekonzept für sicherheitskritische Einstellungen.
Status: belegt
```
---
**Gesamtzahl SyRS in diesem Dokument: 39** (SyRS-1 bis SyRS-39, lückenlos).
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/Traceability.md
+63
View File
@@ -0,0 +1,63 @@
# Traceability
Konsolidierte Forward-/Backward-Traceability zwischen StRS, SyRS und SwRS. Tabelle 1 enthält alle Ketten, in denen mindestens eine SyRS- oder SwRS-Verfeinerung existiert. Tabelle 2 listet die StRS-Anforderungen, die in dieser Iteration ausschließlich auf Stakeholder-Ebene erfasst wurden (Breite-vor-Tiefe, siehe Selbstbewertung in `Analysebericht.md`).
## Tabelle 1 – Verfeinerte Ketten (StRS ↔ SyRS ↔ SwRS)
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|---|---|---|---|
| StRS-4, StRS-90, StRS-125 | SyRS-1, SyRS-28 | SwRS-16 | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` (GetAllRightGroups, BranchI3D-Filter); `CentronRights.md` |
| StRS-24, StRS-126 | SyRS-30 | SwRS-30 | `src/backend/Centron.BL/EmployeeArea/AppUserBL.cs` (GetActiveAppUsers) |
| StRS-50, StRS-127 | SyRS-31 | – | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs` |
| StRS-53 | SyRS-8, SyRS-32 | SwRS-17, SwRS-31 | `src/backend/Centron.BL/Production/ProductionOrderBL.cs` |
| StRS-72, StRS-87 | SyRS-33 | SwRS-33 | `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs` |
| StRS-124 | SyRS-34 | SwRS-32 | `src/backend/Centron.BL/ArtificialIntelligence/OpenAiApiClient.cs` |
| StRS-81, StRS-118, StRS-129 | SyRS-35 | SwRS-34 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`; `src/shared/Centron.Core/GoogleAuthenticator` |
| StRS-96, StRS-130 | SyRS-36 | SwRS-35 | `src/backend/Centron.BL/Administration/Logins/UsersBL.cs`; `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`; `src/backend/Centron.BL/Core/CryptoUtils.cs` |
| StRS-98, StRS-131 | SyRS-37 | SwRS-36 | `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs` (TryLockReceipt/UnLockReceipt) |
| StRS-132 | SyRS-38 | SwRS-37 | `src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs`; `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs` |
| StRS-99, StRS-133 | SyRS-39 | SwRS-38 | `src/backend/Centron.BL/Security/PdfSigningBL.cs` |
| StRS-83, StRS-84 | SyRS-2 | SwRS-1, SwRS-2 | `src/backend/Centron.DAO/GenericDAO.cs`; `src/backend/Centron.Entities/PersistedEntity.cs` |
| StRS-23 | SyRS-3 | SwRS-3 | `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs` |
| StRS-61 | SyRS-4 | SwRS-4 | `src/backend/Centron.BL/WebServices/ObjectMapperConfiguration/DunningConfiguration.cs` |
| StRS-32 | SyRS-6 | SwRS-5 | `src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs` |
| StRS-60 | – | SwRS-6 | `src/backend/Centron.BL/WebLinks/WebLinkBL.cs` |
| StRS-56, StRS-57 | SyRS-11 | SwRS-7 | `src/backend/Centron.BL/Reporting/ReportsBL.cs` |
| StRS-59 | SyRS-12 | SwRS-8 | `src/backend/Centron.BL/Warehousing/TaxBL.cs` |
| StRS-111 | SyRS-13 | SwRS-9 | `src/backend/Centron.BL/TextModuleArea/TextModuleBL.cs` |
| StRS-41 | SyRS-14 | SwRS-10 | `src/backend/Centron.BL/Modules/ModuleBL.cs` |
| StRS-45 | SyRS-15 | SwRS-11, SwRS-26 | `src/backend/Centron.BL/NexusTicketViews/NexusTicketViewBL.cs` |
| StRS-10 | SyRS-16 | SwRS-12 | `src/backend/Centron.BL/Calendar/CalendarBL.cs` |
| StRS-40 | SyRS-17 | SwRS-13 | `src/backend/Centron.BL/Mobile/MobileBL.cs` |
| StRS-110 | SyRS-18 | SwRS-14 | `src/backend/Centron.BL/Telemetry/TelemetryBL.cs` |
| StRS-128 | SyRS-19 | SwRS-15 | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` |
| StRS-1 | SyRS-23 | – | `src/backend/Centron.BL/Accounting/BankAccountBL.cs` |
| StRS-34 | SyRS-22 | SwRS-18 | `src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs` |
| StRS-64, StRS-65, StRS-67, StRS-68 | SyRS-9 (nur 67/68) | SwRS-21 | `src/apis/Centron.APIs.CopDataAccess`, `EgisDataAccess`, `ITscopeDataAccess`, `IcecatDataAccess` (je `*Exception.cs`) |
| StRS-70, StRS-71 | SyRS-10 | – | `src/apis/Centron.Api.Gls`, `Centron.Api.Shipcloud` |
| StRS-73, StRS-123 | – | SwRS-22 | `src/webservice/Centron.Host.Console/Program.cs`; `Centron.Host.WindowsService/CentronService.cs` |
| StRS-118 | SyRS-27, SyRS-29 | SwRS-19 | `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs` |
| StRS-7 | – | SwRS-24 | `src/backend/Centron.BL/BusinessPartner/SupplierAssetBL.cs` |
| StRS-25 | – | SwRS-25 | `src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs` |
| StRS-47, StRS-51 | SyRS-15 | SwRS-26 | `src/backend/Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs`; `src/backend/Centron.BL/Processes/ProcessBL.cs` |
| StRS-37 | SyRS-24 | – | `src/backend/Centron.BL/MailScanner/MailScannerBL.cs` |
| StRS-114, StRS-120, StRS-122 | SyRS-25 | – | `src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs` |
| StRS-121 | SyRS-26 | – | `src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs` |
| StRS-92 | SyRS-21 | – | `docker/c-entron-regression-tests-db`, `c-entron-mailcatcher` |
| StRS-77 | SyRS-20 | – | `src/nexus/CentronNexus.Host/appsettings.json`, `appsettings.Development.json` |
| StRS-44 | SyRS-5 | – | `src/backend/Centron.BL/NexusNotifications/NotificationsHubHelper.cs` |
| StRS-36 | SyRS-7 | – | `src/backend/Centron.BL/Mail/Blacklist` |
| StRS-53 | SyRS-8 | SwRS-17 | `src/backend/Centron.BL/Production/ProductionOrderBL.cs`; `LicenseManager` |
| StRS-4 | SyRS-1 | – | `src/backend/Centron.BL/Administration/Company/MandatorBL.cs`, `BranchBL.cs` |
| StRS-101 | – | SwRS-27, SwRS-28, SwRS-29 (Querschnitt, kein 1:1) | mehrfach unabhängig beobachtetes Result-/Guard-/Konstruktionsmuster (siehe SwRS-27–29) |
| StRS-7 | – | SwRS-24 | siehe oben |
| StRS-84 | – | SwRS-1 | `src/backend/Centron.Entities/PersistedEntity.cs` |
| StRS-83 | SyRS-2 | SwRS-2 | `src/backend/Centron.DAO/GenericDAO.cs` |
## Tabelle 2 – StRS ohne SyRS-/SwRS-Verfeinerung in dieser Iteration (Breite-vor-Tiefe)
Diese Anforderungen sind gemäß Schritt 0b (Mindestabdeckung) auf StRS-Ebene belegt, wurden in dieser Iteration jedoch nicht bis SyRS/SwRS heruntergebrochen. Sie stehen als Nachschlag für eine Folge-Iteration aus (siehe Selbstbewertung, `Analysebericht.md` Abschnitt 6).
StRS-2, StRS-3, StRS-5, StRS-6, StRS-8, StRS-9, StRS-11, StRS-12, StRS-13, StRS-14, StRS-15, StRS-16, StRS-17, StRS-18, StRS-19, StRS-20, StRS-21, StRS-22, StRS-26, StRS-27, StRS-28, StRS-29, StRS-30, StRS-31, StRS-33, StRS-35, StRS-38, StRS-39, StRS-42, StRS-43, StRS-46, StRS-48, StRS-49, StRS-52, StRS-54, StRS-55, StRS-58, StRS-62, StRS-63, StRS-66, StRS-69, StRS-74, StRS-75, StRS-76, StRS-78, StRS-79, StRS-80, StRS-82, StRS-85, StRS-86, StRS-88, StRS-89, StRS-91, StRS-93, StRS-94, StRS-95, StRS-97, StRS-100, StRS-102, StRS-103, StRS-104, StRS-105, StRS-106, StRS-107, StRS-108, StRS-109, StRS-112, StRS-113, StRS-115, StRS-116, StRS-117, StRS-119, StRS-134.
**Anzahl:** 72 von 134 StRS-Anforderungen (53,7 %) ohne SyRS-/SwRS-Verfeinerung in dieser Iteration; 62 StRS-Anforderungen (46,3 %) sind Teil einer verfeinerten Kette in Tabelle 1.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Protokoll.md
+224
View File
@@ -0,0 +1,224 @@
# 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-26T10:29:44.9799824+02:00
- **Endzeit:** 2026-08-26T11:13:11.9176123+02:00
- **Dauer gesamt:** 0:43:26 (`duration_ms` 0:43:25; API: 0:42:49)
— **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: ja)
- **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:** **ja – der Snapshot weicht vom Commit-Stand ab.** Folgende Dateien lagen zusätzlich im Arbeitsverzeichnis und standen dem Lauf als Artefaktquelle zur Verfügung:
- `QuellCode/CentronERP/SSMS_DB_SCHEMA.sql` (Git-Status `??`)
- SHA-256: `ED7F21250E868577572B4CADA53C132F7433C74270BF9B59E817CCEC6B1FA8DB`
- 3.266.626 B / 76.793 Zeilen – SSMS-Schema-Dump der Datenbank `CentronVOED2`: 1.558 `CREATE TABLE`, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel
Läufe mit und ohne diese Artefakte sind **nicht** unmittelbar vergleichbar: Der
Untersuchungsgegenstand ist ein anderer.
- **Nutzung des DB-Schemas:** **ja** – 4 Werkzeugaufruf(e) mit `SSMS_DB_SCHEMA` in der Eingabe (`Bash`, `Read`, `Write`), 3 Nennungen in den Ergebnisartefakten. Die Datei wurde als Artefaktquelle tatsächlich ausgewertet.
- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
## Werkzeugkonfiguration
- **Skill-Version:** 4.3.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-sonnet-5`
- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 11.420.621 Tokens (99.94 %), `claude-haiku-4-5-20251001` 6.965 Tokens (0.06 %)
- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
- **Effort:** `high` (per `--effort high` gesetzt)
- **Laufverzeichnis-ID:** `v4.3.0-0848`
- **Ablage:** `Iteration 3/claude-sonnet-5/solo/high/`
- **Parallele Läufe:** **ja** – zeitgleich liefen:
- `02_Lauf_2026-08-26_102932_v4.3.0-1b24`
- `02_Lauf_2026-08-26_102932_v4.3.0-2316`
- `02_Lauf_2026-08-26_102932_v4.3.0-3ef5`
- `02_Lauf_2026-08-26_102932_v4.3.0-b652`
Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden.
Tokenverbrauch, Anforderungszahl und Denials bleiben unverzerrt.
- **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 | 118 |
| Output-Tokens | 292.548 (davon 46.802 Thinking-Tokens) |
| Cache-Write-Tokens | 492.297 |
| Cache-Read-Tokens | 10.635.658 |
| Agent-Turns | 122 |
### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
|---|---:|---:|---:|
| Input-Tokens | 118 | 6.943 | 7.061 |
| Output-Tokens | 292.548 | 22 | 292.570 |
| Cache-Write-Tokens | 492.297 | 0 | 492.297 |
| Cache-Read-Tokens | 10.635.658 | 0 | 10.635.658 |
| **Tokens gesamt** | **11.420.621** | **6.965** | **11.427.586** |
**Tokens gesamt: 11.427.586** — 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 | 134 | 63,5 % |
| SyRS | 39 | 18,5 % |
| SwRS | 38 | 18,0 % |
| **Gesamt** | **211** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 102 | 48,3 % |
| Sicherheit | 36 | 17,1 % |
| Daten | 29 | 13,7 % |
| Schnittstelle | 28 | 13,3 % |
| nicht-funktional | 13 | 6,2 % |
| Performance | 3 | 1,4 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 213 |
| davon `PRIMÄR` | 94 (44,1 %) |
| davon `SEKUNDÄR` | 98 (46,0 %) |
| davon `KONTEXT` | 21 (9,9 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 92 (43,6 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 189 | 89,6 % |
| workaround | 14 | 6,6 % |
| sonderfall | 3 | 1,4 % |
| veraltet | 5 | 2,4 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 180 | 85,3 % |
| als `HYPOTHESE` gekennzeichnet | 31 | 14,7 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 26 | 12,3 % |
| mit ISO-25010-Qualitätsmerkmal | 39 | 18,5 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 7 von 52 ungedeckt: StRS-28, StRS-33, StRS-50, StRS-79, StRS-80, StRS-90, StRS-125 |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 211 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 105 von 211 mit Tracelinks (49,8 %) |
## Ergebnis
- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
- **Session-ID:** `857e4959-b8dd-4d8d-b113-b4eeb3d7d5a7`
- **Permission-Denials:** 0 – **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` | 40.159 B |
| `Glossar.md` | 3.980 B |
| `Hypothesen.md` | 6.333 B |
| `StRS.md` | 154.764 B |
| `SwRS.md` | 50.758 B |
| `SyRS.md` | 51.061 B |
| `Traceability.md` | 6.863 B |
- **Root unverändert:** ja (zeilenendennormalisiert verglichen). Der rohe Vorher/Nachher-Vergleich weicht ab, weil `SSMS_DB_SCHEMA.sql` zwischen Laufbeginn und Auswertung committet wurde und deshalb nicht mehr als `??` im Status erscheint. Nach Normalisierung um diese Zeile sind beide Stände identisch; zusätzlich ist `git diff HEAD -- QuellCode/CentronERP` leer (bestätigt). Am Inhalt des Arbeitsverzeichnisses hat der Lauf nichts verändert.
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
## Anmerkungen/Auffälligkeiten
**1. Iteration 3 = geänderter Untersuchungsgegenstand.** Seit 2026-08-26 10:28:08 liegt
`SSMS_DB_SCHEMA.sql` im Arbeitsverzeichnis (3.266.626 B, 76.793 Zeilen, 1.558 Tabellen, 182 Views,
63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256 `ED7F2125…1FA8DB`, Commit `f349d189`).
Der Prompt fordert Datenbankschemata in Schritt 2 ausdrücklich als Artefaktquelle. Läufe der
Iteration 2 hatten die Datei nicht – die beiden Iterationen sind **nicht poolbar**.
**2. Verfügbarkeit ≠ Nutzung.** Ob der Agent das Schema öffnet, ist eine **abhängige** Variable:
Von den fünf Läufen der Iteration 3 haben drei es genutzt (`0848`, `1b24`, `2316`), zwei nicht
(`3ef5`, `b652`). Erhoben wird das über Werkzeugaufrufe, deren **Eingabe** den Dateinamen nennt –
nicht über Texttreffer im Transkript: Die Verzeichnisauflistung zu Laufbeginn nennt die Datei
zwangsläufig und ist kein Zugriff.
**3. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Fünf Läufe gleichzeitig,
zeitweise überlappend mit `094249_v4.2.1-4840` aus Iteration 2. Wanduhrzeit, `duration_ms` und
`duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials
nicht. Einziger gültiger Laufzeitmesspunkt beider Iterationen bleibt der serielle Lauf
`084301_v4.2.0-d6f9` mit 45:04.
**4. Root-Vergleich normalisiert.** `before.txt` führt das Schema als `??`, `after.txt` ist leer –
weil die Datei zwischen Laufbeginn und Auswertung committet wurde. Der rohe Vergleich meldete
deshalb eine Abweichung, die es nicht gibt. Nach Normalisierung um diese Zeile sind beide Stände
identisch, zusätzlich bestätigt durch ein leeres `git diff HEAD -- QuellCode/CentronERP`.
**5. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung; die `solo`-Kontrolle
(`subagent_stats.spawned` = 0) wurde gegengeprüft und ist erfüllt.
**6. Schema genutzt – und der mit Abstand sparsamste Lauf beider Iterationen.** Vier Werkzeugaufrufe
(`Bash`, `Read`, `Write`) mit `SSMS_DB_SCHEMA` in der Eingabe, drei Nennungen in den
Ergebnisartefakten. Ergebnis: **211 Anforderungen bei 11,4 Mio. Tokens** – die höchste Ausbeute je
Token beider Iterationen. Zum Vergleich `3ef5`, ebenfalls Iteration 3, aber ohne Schemanutzung:
237 Anforderungen bei 68,9 Mio. Tokens (Faktor 6,0 beim Verbrauch für 12 % mehr Anforderungen).
Das ist plausibel – ein Schemadump liefert 1.558 Tabellen in einer Datei, wofür sonst hunderte
Quelldateien zu lesen wären –, aber bei n = 3 genutzten Läufen **kein Beleg**: `2316` nutzte das
Schema ebenfalls und verbrauchte 48,3 Mio. Tokens.
**7. Die Ausbeute geht zulasten der Struktur.** 63,5 % der Anforderungen liegen auf StRS-Ebene
(134 von 211), und die Traceability fällt mit **49,8 %** auf den schlechtesten Wert beider
Iterationen. Sieben von 46 risikorelevanten Anforderungen sind ungedeckt. Die Primärbelegquote
liegt mit 43,6 % im unteren Drittel.
**8. Sauber im Werkzeugverhalten:** 0 Permission-Denials, genau die sieben geforderten Dateien,
keine Arbeitsdateien zurückgelassen.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/RawResult.json
+1
View File
@@ -0,0 +1 @@
{"is_error":false,"duration_api_ms":2569292,"num_turns":122,"stop_reason":"end_turn","session_id":"857e4959-b8dd-4d8d-b113-b4eeb3d7d5a7","total_cost_usd":7.029088600000001,"usage":{"input_tokens":118,"cache_creation_input_tokens":492297,"cache_read_input_tokens":10635658,"output_tokens":292548,"output_tokens_details":{"thinking_tokens":46802},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":492297,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":615,"cache_read_input_tokens":363144,"cache_creation_input_tokens":1452,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":1452},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6943,"outputTokens":22,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007053,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":118,"outputTokens":292548,"cacheReadInputTokens":10635658,"cacheCreationInputTokens":492297,"webSearchRequests":0,"costUSD":7.0220356,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":null,"result":"All seven required deliverables are complete in the output directory. Summary of this run:\n\n**Modulinventar (Schritt 0):** 122 Zeilen über die gesamte Codebasis (Centron.BL-Fachmodule, externe APIs, Webservice-Host, Nexus-Portal, geteilte Infrastruktur, Deployment/CI-CD), mit Mindestabdeckung erreicht — kein Modul blieb ohne Anforderung.\n\n**Anforderungen:** 211 insgesamt (134 StRS, 39 SyRS, 38 SwRS), davon 8 Module vertieft (`tief`) mit belastbaren PRIMÄR-Belegen. Wichtigster Einzelbefund: ungesalzenes SHA1-Passwort-Hashing im Login-Pfad, dokumentiert durch einen im Produktivcode verbliebenen `// TODO the password should be salted!!!`-Kommentar (StRS-130/SyRS-36/SwRS-35).\n\n**Konsistenz:** automatisiert geprüft — keine doppelten IDs, keine unbelegten Anforderungen, keine fehlenden Übernahmewürdigkeits-Angaben, keine toten Tracelinks; 32 von 36 risikorelevanten Anforderungen tragen einen PRIMÄR-Beleg, die restlichen 4 sind korrekt als HYPOTHESE markiert. `Hypothesen.md` (31 Einträge) deckt sich exakt mit den Inline-Markierungen.\n\nWährend der Erstellung von `StRS.md` fiel mir ein Nummerierungssprung auf (28 Module ohne Eintrag) — das habe ich noch im selben Lauf korrigiert und dokumentiert, statt es zu verschleiern.","ttft_ms":4845,"ttft_stream_ms":1550,"time_to_request_ms":31,"type":"result","duration_ms":2605387,"uuid":"62fd82bf-3668-451f-a972-7906c0c24539","queued_turn_count":0}
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Stderr.log
View File
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/after.txt
View File
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/anforderungen.json
+4013
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/anforderungen.md
+66
View File
@@ -0,0 +1,66 @@
## 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 | 134 | 63,5 % |
| SyRS | 39 | 18,5 % |
| SwRS | 38 | 18,0 % |
| **Gesamt** | **211** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 102 | 48,3 % |
| Sicherheit | 36 | 17,1 % |
| Daten | 29 | 13,7 % |
| Schnittstelle | 28 | 13,3 % |
| nicht-funktional | 13 | 6,2 % |
| Performance | 3 | 1,4 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 213 |
| davon `PRIMÄR` | 94 (44,1 %) |
| davon `SEKUNDÄR` | 98 (46,0 %) |
| davon `KONTEXT` | 21 (9,9 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 92 (43,6 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 189 | 89,6 % |
| workaround | 14 | 6,6 % |
| sonderfall | 3 | 1,4 % |
| veraltet | 5 | 2,4 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 180 | 85,3 % |
| als `HYPOTHESE` gekennzeichnet | 31 | 14,7 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 26 | 12,3 % |
| mit ISO-25010-Qualitätsmerkmal | 39 | 18,5 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 7 von 52 ungedeckt: StRS-28, StRS-33, StRS-50, StRS-79, StRS-80, StRS-90, StRS-125 |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 211 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 105 von 211 mit Tracelinks (49,8 %) |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/before.txt
+2
View File
@@ -0,0 +1,2 @@
?? QuellCode/CentronERP/SSMS_DB_SCHEMA.sql
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/combined_prompt.md
+177
View File
@@ -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\Tag 2\claude-sonnet-5\solo\high\02_Lauf_2026-08-26_102932_v4.3.0-0848\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-26T11:13:11.9176123+02:00
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-26T10:29:44.9799824+02:00
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/Analysebericht.md
+444
View File
@@ -0,0 +1,444 @@
# Analysebericht – c-entron ERP-Suite
## 0. Untersuchungsgegenstand und Vorgehen
Untersucht wurde die gesamte Codebasis unter `C:\DEV\MasterArbeit\QuellCode\CentronERP` (Stand des Arbeitsverzeichnisses zum Zeitpunkt des Laufs). Die Lösung besteht aus 15.554 C#-Dateien und 1.233 XAML-Dateien in sieben Solution-Bereichen (`src/apis`, `src/backend`, `src/centron` [WPF-Desktopclient], `src/nexus` [Blazor-Webclient „c-entron Nexus“], `src/shared`, `src/webservice`) sowie einem 3,27-MB-Datenbankschema-Dump (`SSMS_DB_SCHEMA.sql`), Betriebsartefakten (`docker/`, `deployment/`, `azure*`-Pipelines) und einer Reihe von Referenzdokumenten unter `docs/`.
Wegen der Größe der Codebasis wurde das Modulinventar auf Ebene fachlicher Komponenten (i. d. R. WPF-Modul-Unterordner bzw. eigenständiges Solution-Projekt) gebildet, nicht auf Ebene einzelner Klassen. Kleinere, fachlich verwandte Unterordner mit geringem Risiko wurden zu einer Inventarzeile zusammengefasst (z. B. diverse Administration-Einstellungsdialoge); umsatz-/abrechnungs- und berechtigungsrelevante Bereiche (Finances/Receipts, RightsManagement, DSGVO, SEPA) wurden bewusst feiner aufgeschlüsselt, um die in Schritt 0c geforderte Vertiefung zu ermöglichen. Diese Granularität ist damit selbst eine Aussage über Risikoeinschätzung, nicht nur eine Gliederungsentscheidung.
Das Inventar wird **vor** der ersten Anforderung festgelegt (Schritt 0) und im Verlauf des Laufs nur ergänzt, nicht gekürzt.
## 1. Modulinventar
Spalten: `#` (Referenz-ID für dieses Inventar) | Modul/Komponente | Pfad (relativ zu `src/`, sofern nicht anders angegeben) | Fachliche Aufgabe
### A. Administration (Desktop-Client)
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| A1 | Rechteverwaltung | centron/Centron.WPF.UI/Modules/Administration/RightsManagement | Vergabe und Pflege granularer Benutzerrechte (Rechtegruppen, Einzelrechte) |
| A2 | Datenschutz/DSGVO | centron/Centron.WPF.UI/Modules/Administration/DSGVO | Verwaltung von Aufbewahrungsfristen, Auftragsverarbeitungsverträgen, Löschregeln |
| A3 | SEPA-Lastschriftverträge | centron/Centron.WPF.UI/Modules/Administration/SepaContract | Verwaltung von SEPA-Mandaten/-Vertragsvorlagen für den Zahlungsverkehr |
| A4 | Mandantenverwaltung | centron/Centron.WPF.UI/Modules/Administration/MandatorManagement | Verwaltung mehrerer Mandanten/Datenbanken im Mehrmandantenbetrieb |
| A5 | Mitarbeiterverwaltung | centron/Centron.WPF.UI/Modules/Administration/EmployeeManagement | Stammdatenpflege von Mitarbeitern, Zuordnung zu Abteilungen/Filialen |
| A6 | Systemkonfiguration & Länder | centron/Centron.WPF.UI/Modules/Administration/{Customization,Settings,CentronConfigDb,Cache,CountryManagement} | Globale Anwendungseinstellungen, Länderstammdaten, Konfigurations-Cache |
| A7 | Kommunikationseinstellungen | centron/Centron.WPF.UI/Modules/Administration/{MailAndCalender,MailTemplates,PhoneSettings} | Mail-/Kalenderanbindung, Mailvorlagen, Telefonanlagen-Konfiguration |
| A8 | Dokumentenausgabe | centron/Centron.WPF.UI/Modules/Administration/{PdfExport,PdfSigning,ReportServer,TextBlockManagement} | PDF-Erzeugung/-Signatur, Berichtsserver, Textbausteine für Belege |
| A9 | Web- & Schnittstelleneinstellungen | centron/Centron.WPF.UI/Modules/Administration/{WebCart,WebServiceSettings,ExternalTools,SqlManagers} | Konfiguration Webshop, Webservices, externer Tools, SQL-Verbindungen |
| A10 | Betriebs- & Diagnosewerkzeuge | centron/Centron.WPF.UI/Modules/Administration/{LogViewer,Profiling,Connections,UpdateAvailableNotificationSettings} | Log-Auswertung, Performance-Profiling, Verbindungsverwaltung, Update-Hinweise |
| A11 | Abrechnungs-/Eskalationseinstellungen | centron/Centron.WPF.UI/Modules/Administration/{HourlySurchargeRates,ReceiptConditions,EscalationsSettings,TaskManagmentSettings,ServiceAndLeasing,Services,SendDeliveryListShippingConfirmationSettings} | Stundenzuschläge, Belegkonditionen, Eskalationsregeln, Service-/Leasingverträge |
### B–D. KI, Kalender, Dashboard
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| B1 | Künstliche-Intelligenz-Integration | centron/Centron.WPF.UI/Modules/ArtificialIntelligence | KI-Chat, Angebotstext-Editor, OpenAI-Anbindung, Textbewertung |
| C1 | Kalender | centron/Centron.WPF.UI/Modules/Calendar | Terminverwaltung im Client |
| D1 | Dashboard | centron/Centron.WPF.UI/Modules/Dashboard | Startseiten-Kachelübersicht |
### E. DataExchange
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| E1 | Finanzbuchhaltungs-/DATEV-Export | centron/Centron.WPF.UI/Modules/DataExchange/{BookKeeping,DatevOnline2020} | Export von Buchungsdaten an DATEV |
| E2 | Daten-Im-/Export & Konnektoren | centron/Centron.WPF.UI/Modules/DataExchange/{Connectors,DataExport,DataImport,DocSync} | Generischer Datenaustausch, Dateisynchronisation |
| E3 | Zahlungsverkehr (SEPA) | centron/Centron.WPF.UI/Modules/DataExchange/PaymentTransactions | Erzeugung von SEPA-Zahlungs-/Lastschriftdateien |
| E4 | DocuForm-Dokumentenanbindung | centron/Centron.WPF.UI/Modules/DataExchange/DocuForm, apis/... , Centron.Api.docuFORM | Dokumentenerzeugung über externen DocuForm-Dienst |
| E5 | RMM-Anbindung | centron/Centron.WPF.UI/Modules/DataExchange/Rmm | Anbindung Remote-Monitoring-/Management-Systeme |
| E6 | EDI-Lieferantenbestellung je Filiale | centron/Centron.WPF.UI/Modules/DataExchange/SupplierOrderPerBranch | Elektronischer Bestelldatenaustausch mit Lieferanten je Filiale |
| E7 | Telekom-DIVE-Anbindung | centron/Centron.WPF.UI/Modules/DataExchange/TelekomDive, Modules/TelekomDive | Integration Telekom-DIVE-Plattform |
### F–D (weitere Einzelmodule)
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| F1 | ExternalTool-Variablen | centron/Centron.WPF.UI/Modules/ExternalTool | Verwaltung von Variablen für externe Tool-Aufrufe |
### G. Finances (Rechnungswesen/Abrechnung) — Risikoschwerpunkt
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| G1 | Kontenverwaltung | .../Modules/Finances/AccountManagement | Verwaltung von Finanzkonten |
| G2 | Automatisierte Abrechnung | .../Modules/Finances/AutomatedBilling | Zeitgesteuerte automatische Rechnungserstellung |
| G3 | Kampagnenverwaltung | .../Modules/Finances/Campaigns | Marketing-/Vertriebskampagnen mit Kundenzuordnung |
| G4 | Vertragsauswertung | .../Modules/Finances/{ContractEvaluation2,ContractEvaluationOld} | Auswertung laufender Verträge (aktuelle und Altversion) |
| G5 | Verträge | .../Modules/Finances/Contracts | Vertragsstammdaten, Laufzeiten, Konditionen |
| G6 | CRM | .../Modules/Finances/Crm | Kundenbeziehungsmanagement, Kontakthistorie |
| G7 | Zählerstandserfassung | .../Modules/Finances/DeviceClickCounter | Erfassung von Zählerständen (Klickzähler Drucker/Kopierer) als Abrechnungsgrundlage |
| G8 | Mahnwesen | .../Modules/Finances/Dunning | Automatisiertes Mahnverfahren für offene Forderungen |
| G9 | Flatrate-Abrechnung | .../Modules/Finances/FlatrateBilling | Pauschalabrechnung von Verträgen |
| G10 | Stammdatenlisten Finanzen | .../Modules/Finances/MasterDataLists | Stammdatenlisten für Rechnungswesen |
| G11 | Offene Posten | .../Modules/Finances/Opos | Verwaltung offener Forderungen/Verbindlichkeiten |
| G12 | Zahlungen | .../Modules/Finances/Payments | Zahlungserfassung/-zuordnung |
| G13 | Produktlebenszyklus (Finanzen) | .../Modules/Finances/ProductLifecycleManagement | Abrechnungsrelevante Produktlebenszyklus-Daten |
| G14 | Projekte | .../Modules/Finances/Projects | Projektbezogene Abrechnung |
| G15 | Verkaufsbelege – Angebot bis Lieferschein | backend/Centron.BL/Sales/Receipts/{Offers,Orders,DeliveryLists,PickupLists} | Erstellung/Statusführung von Angeboten, Aufträgen, Lieferscheinen, Kommissionierlisten |
| G16 | Verkaufsbelege – Rechnung & Gutschrift | backend/Centron.BL/Sales/Receipts/{Invoices,CreditVouchers} | Rechnungs-/Gutschrifterstellung, Preisänderungsrechte, Storno |
| G17 | Einkaufsbelege | backend/Centron.BL/Sales/Receipts/{SupplierOrders,SupplierInvoices,SupplierCreditVouchers,SupplierDeliveryLists} | Bestell-, Wareneingangs- und Lieferantenrechnungsverarbeitung |
| G18 | Vertragslisten & Belegkern | backend/Centron.BL/Sales/Receipts/{ContractLists,Common,IReceiptSpecificLogic.cs} | Gemeinsame Belegstatusmaschine/-infrastruktur aller Belegarten |
| G19 | Timer-Abrechnung | .../Modules/Finances/TimerBilling | Abrechnung erfasster Zeiten (z. B. Helpdesk) |
### H–I. Global, Gui
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| H1 | Anwendungsrahmen & Aktionen | centron/Centron.WPF.UI/Modules/Global/{Actions,CustomProperties,EmployeeSelection,FileSystemDialog,ExceptionMessage} | Generische UI-Bausteine: Aktionsmenüs, Individualfelder, Mitarbeiterauswahl |
| H2 | Hilfe- und Diagnosewerkzeuge | centron/Centron.WPF.UI/Modules/Global/{Help,NetworkDiagnostics,PerformanceTests,MSPLicensesCompare} | Kontexthilfe, Netzwerkdiagnose, Lizenzvergleich |
| H3 | Videoportal | centron/Centron.WPF.UI/Modules/Global/VideoPortal | Einbindung von Schulungsvideos |
| I1 | GUI-Profile | centron/Centron.WPF.UI/Modules/Gui/Profiles | Benutzeroberflächen-Profile (Layoutvarianten) |
### J. Helpdesk
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| J1 | Ticketverwaltung | centron/Centron.WPF.UI/Modules/Helpdesk/{TicketList,TicketDetails} | Erfassung, Bearbeitung, Statusführung von Support-Tickets |
| J2 | Aufgaben- & Ereignisverwaltung | centron/Centron.WPF.UI/Modules/Helpdesk/{TaskManagement,Events,ExpectedEvents,ExpectedEventsReporting} | Aufgaben, SLA-Fälligkeiten, Ereignisreporting |
| J3 | Checklisten & Prozessvorlagen | centron/Centron.WPF.UI/Modules/Helpdesk/{CentronChecklist,TicketProcessTemplates} | Standardisierte Checklisten/Ticket-Vorlagen (C-FLOW) |
| J4 | Rufnummern & Selbstauskunft | centron/Centron.WPF.UI/Modules/Helpdesk/{ConnectionNumber,SendSelfCareForm} | Rufnummernverwaltung, Kunden-Selbstauskunftsformulare |
| J5 | Helpdesk-Einstellungen & Dashboard | centron/Centron.WPF.UI/Modules/Helpdesk/{Settings,Dashboard} | Modulkonfiguration, Kennzahlenübersicht |
### K–T. Weitere Fachmodule
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| K1 | Logistik & Versand | centron/Centron.WPF.UI/Modules/Logistic | Logistikeinstellungen, Versandartenverwaltung |
| L1 | Massenaktualisierung | centron/Centron.WPF.UI/Modules/Massenupdates | Massenänderung von Datensätzen |
| M1 | Persönliche Arbeitsorganisation | centron/Centron.WPF.UI/Modules/MyCentron/{Calendar,MyDay,TodoList,PersonalSettings} | Persönlicher Kalender, Tagesplanung, Aufgabenliste |
| M2 | Prüfassistent & Fernwartung | centron/Centron.WPF.UI/Modules/MyCentron/{CentronInspectors,Supremo} | Geräteprüfassistenten, Fernwartungsanbindung Supremo |
| M3 | Telefonie & persönliches Dashboard | centron/Centron.WPF.UI/Modules/MyCentron/{Telephony,Dashboard} | TAPI-Telefonie-Integration, persönliches Dashboard |
| N1 | Online-Banking | centron/Centron.WPF.UI/Modules/OnlineBanking | Kontoumsatzabruf, Bankverbindungskonfiguration (FinAPI) |
| O1 | Produktlebenszyklusmanagement (PLM) | centron/Centron.WPF.UI/Modules/PLM | Produktlebenszyklus-Übersicht |
| P1 | Passwortverwaltung | centron/Centron.WPF.UI/Modules/PasswordManager | Verwaltung von Kunden-/Systemzugangsdaten |
| Q1 | Zahler und Kostenstellen | centron/Centron.WPF.UI/Modules/PayersAndCostCenter | Zuordnung Zahler/Kostenstellen zu Belegen |
| R1 | Produktion | centron/Centron.WPF.UI/Modules/Production | Maschinen- und Produktionsauftragsverwaltung |
| S1 | Projektmanagement | centron/Centron.WPF.UI/Modules/ProjectManagement | Projektübersicht/-steuerung |
| T1 | Projektpreisimport | centron/Centron.WPF.UI/Modules/ProjectPriceImport | Import von Preisdifferenzen für Projekte |
### U–AA. Einkauf, QM, Reports, RMA, Sales, Statistik, Survey
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| U1 | Bestellwesen & EDI | centron/Centron.WPF.UI/Modules/Purchasing/{EDIManagement,OrderSuggestionList,PurchaseSettings,Others} | Bestellvorschläge, EDI-Bestellabwicklung |
| U2 | Reisekosten | centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense | Reisekostenerfassung/-abrechnung |
| V1 | Qualitätsmanagement | centron/Centron.WPF.UI/Modules/QM | QM-Prozessunterstützung |
| W1 | Berichtsverwaltung | centron/Centron.WPF.UI/Modules/Reports | Verwaltung/Ausführung von Reports |
| X1 | Retourenabwicklung (RMA) | centron/Centron.WPF.UI/Modules/Rma | Rücksendungen, Reparaturabwicklung |
| Y1 | Vertriebszusatzfunktionen | centron/Centron.WPF.UI/Modules/Sales/{Mailing,ProductMatrix,SpecialArticleImport,SpecialArticleToContractImport} | Serienmail, Produktmatrix, Sonderartikelimport |
| Z1 | Unternehmenskennzahlen | centron/Centron.WPF.UI/Modules/Statistics/{ManagementInfo,Dashboard} | Management-Reporting |
| Z2 | MSP-Statistiken | centron/Centron.WPF.UI/Modules/Statistics/{MspCollectors,MspStatistics} | Managed-Service-Provider-Kennzahlen |
| Z3 | Verkaufs- & Mitarbeiterstatistik | centron/Centron.WPF.UI/Modules/Statistics/{SaleStatistics,EmployeeAnalytics} | Verkaufs-/Auslastungsstatistiken |
| AA1 | Umfragen | centron/Centron.WPF.UI/Modules/Survey | Kundenumfragen |
### AC. Warehousing
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| AC1 | Artikelstammverwaltung | .../Modules/Warehousing/{ArticleManagement,ArticleUnitManagement,MaterialGroupManagement} | Artikelstamm, Mengeneinheiten, Warengruppen |
| AC2 | Artikelimport & -suche | .../Modules/Warehousing/{ArticleImport,SearchArticle,SupplierSearch} | Import von Artikeldaten, Artikel-/Lieferantensuche |
| AC3 | Barcodeverwaltung | .../Modules/Warehousing/BarcodeManagement | Barcode-Zuordnung/-Druck |
| AC4 | Kommissionierung & Provisionen | .../Modules/Warehousing/{Commissioning,Commissions} | Kommissionierprozess, Provisionsberechnung |
| AC5 | Inventur | .../Modules/Warehousing/Inventory | Bestandsaufnahme/-abgleich |
| AC6 | Zahlungsausgänge & Kontensysteme | .../Modules/Warehousing/{OutcomingPayments,AccountSystems} | Ausgangszahlungen, Kassen-/Kontensysteme |
| AC7 | Umsatzsteuerverwaltung | .../Modules/Warehousing/ValueAddedTax*.cs | Umsatzsteuersätze/-zuordnung |
### Backend-Architekturschicht (Centron.BL/DAO/Entities/Interfaces/Gateway/Common)
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| BE1 | Business-Logic-Schicht | backend/Centron.BL | Fachliche Regeln/Prozesslogik aller Module (Session-basiert) |
| BE2 | Datenzugriffsschicht (NHibernate) | backend/Centron.DAO | ORM-Mapping, Sitzungsverwaltung, generische Repositories |
| BE3 | Domänenmodelle | backend/Centron.Entities | Entitätsklassen/Datenmodell |
| BE4 | Fachliche Schnittstellen | backend/Centron.Interfaces | Vertragsschnittstellen zwischen BL/DAO/UI, u. a. Rechtekonstanten |
| BE5 | Gateway/Integrationsschicht | backend/Centron.Gateway | Kommunikation zwischen Prozessen/Diensten |
| BE6 | Common-Utilities | backend/Centron.Common | Technische Hilfsfunktionen |
| BE7 | Datenbankschema | SSMS_DB_SCHEMA.sql | Vollständiges MSSQL-Datenbankschema (Tabellen, Constraints) |
### Web-/API-Schicht
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| WA1 | Webservice-Kernlogik | webservice/Centron.WebServices.Core | Fachlogik für SOAP/REST-Zugriffe (mobile Clients, Portale) |
| WA2 | Controller-Schicht | webservice/Centron.Controllers | HTTP-Endpunkte des Webservice-Hosts |
| WA3 | Webservice-Host | webservice/{Centron.Host,Centron.Host.Console,Centron.Host.WindowsService} | Hosting als IIS/Konsole/Windows-Dienst |
| WA4 | Verbindungsmanager | webservice/c-entron.misc.ConnectionManager | Verbindungs-/Session-Verwaltung für Webservice-Clients |
### Nexus (Blazor-Webclient „c-entron Nexus“)
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| NX1 | Dokumentensignatur | nexus/CentronNexus/DocumentSigning | Elektronische Signatur von Dokumenten im Web |
| NX2 | Verwaltung (Management) | nexus/CentronNexus/Management | Web-Administrationsfunktionen |
| NX3 | Produktionsauftrags-/Servicetafel | nexus/CentronNexus/{ProductionOrderManagement,ServiceBoard} | Weboberfläche für Produktionsaufträge/Serviceboard |
| NX4 | WebCart & WebOffer | nexus/CentronNexus/{WebCart,WebOffer} | Kunden-Webshop und Online-Angebote |
| NX5 | Nexus-Infrastruktur | nexus/{CentronNexus.Host,CentronNexus.OutlookAddIn}, CentronNexus/{Configuration,Settings} | Hosting, Outlook-Add-in, Konfiguration |
### Shared
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| SH1 | Custom-Controls-Bibliothek | shared/{Centron.Controls,Centron.Controls.Preview} | Wiederverwendbare WPF-Steuerelemente |
| SH2 | Core-Utilities | shared/Centron.Core | Plattformübergreifende Basisfunktionen |
### Externe API-Integrationen
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| XA1 | COP-Datenzugriff | apis/Centron.APIs.CopDataAccess | Anbindung COP-Datenquelle |
| XA2 | EGIS-Datenzugriff | apis/Centron.APIs.EgisDataAccess | Anbindung EGIS-Datenquelle |
| XA3 | FinAPI-Bankanbindung | apis/Centron.APIs.FinAPI | Kontoabruf über FinAPI (Online-Banking) |
| XA4 | ITscope-Datenzugriff | apis/Centron.APIs.ITscopeDataAccess | Produktdatenabgleich über ITscope |
| XA5 | Icecat-Datenzugriff | apis/Centron.APIs.IcecatDataAccess | Produktdatenabgleich über Icecat |
| XA6 | EB-Interface (E-Rechnung AT) | apis/Centron.Api.EbInterface | Österreichische E-Rechnungsschnittstelle |
| XA7 | GLS-Versandanbindung | apis/Centron.Api.Gls | Versanddienstleister-Integration GLS |
| XA8 | Shipcloud-Versandanbindung | apis/Centron.Api.Shipcloud | Versanddienstleister-Integration Shipcloud |
| XA9 | docuFORM-Anbindung | Centron.Api.docuFORM | Dokumentenerzeugungsdienst docuFORM |
### Betrieb/Deployment
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| OP1 | Deployment & Containerisierung | docker/, deployment/, azure*/ | Build-/Deploy-Pipelines, Containerisierung, Installer |
**Summe Inventar: 107 Zeilen.**
## 2. Abdeckungstabelle
Einstufung je Inventarzeile: **tief** (≥ 4 Anforderungen, i. d. R. mit mehrstufiger StRS→SyRS→SwRS-Kette und mindestens einem PRIMÄR-Beleg), **mittel** (2-3 Anforderungen), **flach** (1 Anforderung bzw. nur über eine gemeinsam mit einem Nachbarmodul genutzte Anforderung mitabgedeckt), **nicht analysiert** (keine belegbare Anforderung gefunden). Die Spalte „Anforderungen" nennt die wichtigsten Referenz-IDs, nicht notwendigerweise alle Tracelinks.
| # | Modul | Einstufung | Anzahl | Wichtigste Anforderungen |
|---|---|---|---|---|
| A1 | Rechteverwaltung | tief | 4 | StRS-1, SyRS-1, SyRS-2, SwRS-1 |
| A2 | DSGVO | mittel | 3 | StRS-2 (HYP.), SyRS-3 (HYP.), SwRS-2 |
| A3 | SEPA-Lastschriftverträge | flach | 1 | SwRS-3 |
| A4 | Mandantenverwaltung | mittel | 3 | StRS-3, SyRS-4, SwRS-4 |
| A5 | Mitarbeiterverwaltung | flach | 1 | SwRS-5 (HYP.) |
| A6 | Systemkonfiguration & Länder | flach | 2 | SyRS-5 (HYP.), SwRS-6 |
| A7 | Kommunikationseinstellungen | mittel | 3 | StRS-5, SyRS-6, SwRS-7 |
| A8 | Dokumentenausgabe | mittel | 3 | StRS-6, SyRS-7 (HYP.), SwRS-8 |
| A9 | Web- & Schnittstelleneinstellungen | mittel | 3 | StRS-7, SyRS-8, SwRS-9 (HYP.) |
| A10 | Betriebs- & Diagnosewerkzeuge | mittel | 3 | StRS-8, SyRS-9, SwRS-10 |
| A11 | Abrechnungs-/Eskalationseinstellungen | mittel | 3 | StRS-9 (HYP.), SyRS-10 (HYP.), SwRS-11 (HYP.) |
| B1 | Künstliche-Intelligenz-Integration | mittel | 3 | StRS-10, SyRS-11, SwRS-12 |
| C1 | Kalender | mittel | 3 | StRS-11, SyRS-12, SwRS-13 |
| D1 | Dashboard | mittel | 3 | StRS-12, SyRS-13 (HYP.), SwRS-14 (HYP.) |
| E1 | Finanzbuchhaltungs-/DATEV-Export | flach | 2 | SyRS-15, SwRS-16 |
| E2 | Daten-Im-/Export & Konnektoren | flach | 2 | SyRS-16 (HYP.), SwRS-17 (HYP.) |
| E3 | Zahlungsverkehr (SEPA) | tief | 3 | StRS-15, SyRS-17, SwRS-18 |
| E4 | DocuForm-Dokumentenanbindung | flach | 2 | SyRS-18, SwRS-19 (HYP.) |
| E5 | RMM-Anbindung | flach | 2 | SyRS-20 (HYP.), SwRS-21 (HYP.) |
| E6 | EDI-Lieferantenbestellung je Filiale | mittel | 2 | SyRS-19, SwRS-20 |
| E7 | Telekom-DIVE-Anbindung | flach | 2 | SyRS-21 (HYP.), SwRS-22 (HYP.) |
| F1 | ExternalTool-Variablen | flach | 3 | StRS-13 (HYP.), SyRS-14 (HYP.), SwRS-15 (HYP.) |
| G1 | Kontenverwaltung | flach | 2 | SyRS-23 (HYP.), SwRS-23 (HYP.) |
| G2 | Automatisierte Abrechnung | mittel | 2 | SyRS-24, SwRS-24 |
| G3 | Kampagnenverwaltung | flach | 1 | SyRS-26 (HYP.) |
| G4 | Vertragsauswertung | flach | 1 | SwRS-32 |
| G5 | Verträge | tief | 4 | StRS-16, SyRS-22, SyRS-25, SwRS-30 |
| G6 | CRM | flach | 1 | SyRS-27 |
| G7 | Zählerstandserfassung | flach | 1 | SyRS-33 (HYP.) |
| G8 | Mahnwesen | tief | 7 | StRS-18, SyRS-29, SyRS-30, SyRS-31, SwRS-26, SwRS-27, SwRS-28 |
| G9 | Flatrate-Abrechnung | flach | 2 | SyRS-28 (HYP.), SwRS-25 (HYP.) |
| G10 | Stammdatenlisten Finanzen | flach | 1 | SwRS-33 |
| G11 | Offene Posten | mittel | 2 | SyRS-39, SwRS-34 |
| G12 | Zahlungen | flach | 1 | SyRS-32 (HYP.) (+ StRS-19, s. G19-Cluster) |
| G13 | Produktlebenszyklus (Finanzen) | flach | 1 | SwRS-35 (HYP.) |
| G14 | Projekte | flach | 2 | SyRS-40 (HYP.), SwRS-36 (HYP.) |
| G15 | Verkaufsbelege – Angebot bis Lieferschein | flach | (geteilt) | StRS-20, SyRS-34 (nennen Offers/Orders/DeliveryLists/PickupLists explizit, kein eigenständiges SwRS) |
| G16 | Verkaufsbelege – Rechnung & Gutschrift | tief | 8 | StRS-20, SyRS-34–38, SwRS-29, SwRS-31 |
| G17 | Einkaufsbelege | mittel | 1 | SwRS-29 (+ StRS-20 geteilt) |
| G18 | Vertragslisten & Belegkern | flach | (geteilt) | StRS-20, SyRS-34 |
| G19 | Timer-Abrechnung | flach | 1 | SwRS-37 |
| H1 | Anwendungsrahmen & Aktionen | mittel | 2 | StRS-21, SwRS-38 |
| H2 | Hilfe- und Diagnosewerkzeuge | flach | 2 | SyRS-42 (HYP.), SwRS-39 (HYP.) |
| H3 | Videoportal | flach | 1 | SyRS-43 |
| I1 | GUI-Profile | flach | 1 | SyRS-44 |
| J1 | Ticketverwaltung | tief | 3 | StRS-22, SyRS-45, SyRS-46 |
| J2 | Aufgaben- & Ereignisverwaltung | flach | 2 | SyRS-50 (HYP.), SwRS-44 (HYP.) |
| J3 | Checklisten & Prozessvorlagen | mittel | 2 | SyRS-48, SwRS-43 |
| J4 | Rufnummern & Selbstauskunft | flach | 2 | SyRS-51 (HYP.), SwRS-45 |
| J5 | Helpdesk-Einstellungen & Dashboard | flach | 1 | SwRS-46 |
| K1 | Logistik & Versand | flach | 2 | SyRS-56, SwRS-50 (HYP.) |
| L1 | Massenaktualisierung | flach | 1 | SyRS-57 (HYP.) |
| M1 | Persönliche Arbeitsorganisation | flach | 1 | StRS-24 |
| M2 | Prüfassistent & Fernwartung | flach | 1 | SyRS-54 (HYP.) |
| M3 | Telefonie & persönliches Dashboard | flach | 1 | StRS-5 (TAPI-Erwähnung) |
| N1 | Online-Banking | mittel | 3 | StRS-25, SyRS-55 (HYP.), SwRS-49 |
| O1 | Produktlebenszyklusmanagement (PLM) | mittel | 2 | SyRS-58, SwRS-51 |
| P1 | Passwortverwaltung | tief | 5 | StRS-23, SyRS-52, SyRS-53 (HYP.), SwRS-47, SwRS-48 |
| Q1 | Zahler und Kostenstellen | flach | 1 | SyRS-59 (HYP.) |
| R1 | Produktion | flach | 1 | SyRS-60 (HYP.) |
| S1 | Projektmanagement | flach | 1 | SyRS-61 |
| T1 | Projektpreisimport | mittel | 2 | SyRS-62, SwRS-52 |
| U1 | Bestellwesen & EDI | tief | 6 | StRS-26, SyRS-63, SyRS-64, SyRS-65 (HYP.), SwRS-53, SwRS-54 (HYP.) |
| U2 | Reisekosten | flach | 2 | SyRS-66 (HYP.), SwRS-55 (HYP.) |
| V1 | Qualitätsmanagement | flach | 1 | SyRS-67 (HYP.) |
| W1 | Berichtsverwaltung | flach | 1 | SyRS-68 |
| X1 | Retourenabwicklung (RMA) | mittel | 2 | SyRS-69, SwRS-56 (HYP.) |
| Y1 | Vertriebszusatzfunktionen | flach | 1 | SyRS-70 (HYP.) |
| Z1 | Unternehmenskennzahlen | mittel | 2 | SyRS-71, SwRS-57 |
| Z2 | MSP-Statistiken | flach | 1 | SyRS-71 (geteilt) |
| Z3 | Verkaufs- & Mitarbeiterstatistik | flach | 1 | SyRS-71 (geteilt) |
| AA1 | Umfragen | mittel | 2 | SyRS-72, SwRS-58 |
| AC1 | Artikelstammverwaltung | tief | 4 | StRS-27, SyRS-73, SwRS-59, SwRS-60 |
| AC2 | Artikelimport & -suche | flach | 1 | SyRS-78 |
| AC3 | Barcodeverwaltung | flach | 1 | SyRS-76 |
| AC4 | Kommissionierung & Provisionen | mittel | 2 | SyRS-79, SwRS-62 (HYP.) |
| AC5 | Inventur | flach | 2 | SyRS-77 (HYP.), SwRS-63 (HYP.) |
| AC6 | Zahlungsausgänge & Kontensysteme | mittel | 2 | SyRS-80, SwRS-61 |
| AC7 | Umsatzsteuerverwaltung | flach | 1 | SwRS-64 |
| BE1 | Business-Logic-Schicht | flach | 1 | SyRS-96 |
| BE2 | Datenzugriffsschicht (NHibernate) | mittel | 2 | SyRS-87, SwRS-70 |
| BE3 | Domänenmodelle | flach | 1 | SyRS-97 |
| BE4 | Fachliche Schnittstellen | flach | 1 | SyRS-98 |
| BE5 | Gateway/Integrationsschicht | mittel | 2 | SyRS-86, SwRS-69 |
| BE6 | Common-Utilities | mittel | 3 | StRS-30, SyRS-85, SwRS-68 |
| BE7 | Datenbankschema | mittel | 2 | SyRS-88, SwRS-71 |
| WA1 | Webservice-Kernlogik | flach | 1 | SwRS-78 |
| WA2 | Controller-Schicht | tief | 5 | StRS-28, SyRS-81, SyRS-82, SwRS-65, SwRS-66 |
| WA3 | Webservice-Host | flach | 1 | SyRS-94 (Verweis auf CentronRestService) |
| WA4 | Verbindungsmanager | flach | 2 | SyRS-92 (HYP.), SwRS-74 (HYP.) |
| NX1 | Dokumentensignatur | flach | 1 | SyRS-83 (HYP.) |
| NX2 | Verwaltung (Management) | flach | 1 | SwRS-72 |
| NX3 | Produktionsauftrags-/Servicetafel | tief | 3 | StRS-31, SyRS-89 (HYP.), SwRS-73 |
| NX4 | WebCart & WebOffer | mittel | 3 | StRS-29, SyRS-84, SwRS-67 |
| NX5 | Nexus-Infrastruktur | flach | 1 | SyRS-101 |
| SH1 | Custom-Controls-Bibliothek | flach | 1 | SyRS-93 |
| SH2 | Core-Utilities | tief | 4 | StRS-33, SyRS-94, SwRS-77, SwRS-78 |
| XA1 | COP-Datenzugriff | flach | 1 | SyRS-91 (geteilt) |
| XA2 | EGIS-Datenzugriff | flach | 1 | SyRS-91 (geteilt) |
| XA3 | FinAPI-Bankanbindung | mittel | 2 | StRS-25 (geteilt), SwRS-75 |
| XA4 | ITscope-Datenzugriff | flach | 1 | StRS-32 (geteilt), SyRS-90 (geteilt) |
| XA5 | Icecat-Datenzugriff | flach | 1 | StRS-32 (geteilt), SyRS-90 (geteilt) |
| XA6 | EB-Interface (E-Rechnung AT) | flach | 1 | SyRS-99 (HYP.) |
| XA7 | GLS-Versandanbindung | flach | 1 | SwRS-76 (geteilt) |
| XA8 | Shipcloud-Versandanbindung | flach | 1 | SwRS-76 (geteilt) |
| XA9 | docuFORM-Anbindung | mittel | 2 | SyRS-100, SwRS-80 |
| OP1 | Deployment & Containerisierung | mittel | 3 | StRS-34, SyRS-95, SwRS-79 |
**Summe:** 107 von 107 Inventarzeilen mit mindestens einer Anforderung (Mindestabdeckung erreicht). Keine Zeile ist als „nicht analysiert" zu führen.
## 3. Konsistenzcheck
Durchgeführt über den vollständigen Anforderungsbestand (StRS.md: 34, SyRS.md: 101, SwRS.md: 80 Anforderungen; 215 gesamt) nach Abschluss der Erhebung.
### 3.1 Doppelte oder mehrfach vergebene IDs
Geprüft durch Extraktion aller `ID:`-Werte und Duplikatsuche. **Ergebnis: keine Duplikate.** Jede ID (StRS-1…34, SyRS-1…101, SwRS-1…80) ist genau einmal vergeben.
### 3.2 Anforderungen ohne Beleg
Geprüft durch Suche nach Anforderungsblöcken ohne mindestens eine Zeile `[PRIMÄR]`, `[SEKUNDÄR]` oder `[KONTEXT]` im Feld `Belege`. **Ergebnis: keine Anforderung ohne Beleg.** Alle 215 Anforderungen führen mindestens einen klassifizierten Beleg.
### 3.3 Anforderungen ohne Angabe zur Übernahmewürdigkeit
Geprüft durch Suche nach leeren oder fehlenden `Übernahmewürdigkeit:`-Feldern. **Ergebnis: keine Anforderung ohne Angabe.** Alle 215 Anforderungen tragen eine der vier Einstufungen (`übernehmen` in der großen Mehrheit, `Workaround` u. a. bei StRS-8/SwRS-10 [LogViewer], SwRS-13 [Doppelkalender], SwRS-71/SyRS-88 [DB-Fremdschlüssel]; `Sonderfall` u. a. bei StRS-13/SyRS-14/SwRS-15 [ExternalTool-Variablen], SwRS-31 [sechs feste Beraterfelder], SwRS-68 [hartkodierte Testadresse]; `veraltet` bei SwRS-32 [ContractEvaluationOld]).
### 3.4 Tracelinks auf nicht existierende IDs
Geprüft durch Extraktion aller in `Tracelinks:`-Feldern referenzierten IDs (113 eindeutige Referenzen) und Abgleich gegen die Menge der 215 tatsächlich definierten IDs. **Ergebnis: keine hängenden Referenzen (dangling references).** Jede referenzierte ID existiert.
### 3.5 Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk
Geprüft durch manuelle Durchsicht thematisch benachbarter Anforderungen. Alle identifizierten Fälle sind im Feld `Konsolidierung` vermerkt, u. a.:
- **StRS-27 / SwRS-59** (Stammblatt vs. AssetManagement/DocuBoard): der im Vorgänger-Prompt kalibrierte Beispielfall — zwei Datenhaltungen für dasselbe fachliche Gerätekonzept.
- **StRS-11 / SwRS-13** (Modules/Calendar vs. MyCentron/Calendar) und **StRS-12** (drei parallele Dashboard-Implementierungen).
- **SyRS-86 / SwRS-69** (sechs partnerspezifische EDI-Gateways als Konsolidierungskandidat für ein gemeinsames Mapping-Framework).
- **StRS-31** (Helpdesk/TicketDetails im Desktop vs. CentronNexus/ServiceBoard im Web) — der zentrale, architektonisch bedeutsamste Konsolidierungsfall dieser Analyse, da er zeigt, dass wesentliche Fachlogik bereits ein zweites Mal für das Web implementiert wurde.
- **SwRS-43** (TicketDetails/CheckList vs. Modul CentronChecklist).
- **SyRS-31 / SyRS-39** (Berechnungsformel für offene Beträge in DunningBL und OposBL potenziell dupliziert).
- **SwRS-37** (TimerBilling vs. HourlySurchargeRates).
- **SwRS-68** (Format-/Berichtsverwaltung in Modules/Reports vs. Administration/ReportServer).
Es wurden keine weiteren, unvermerkten Duplikate identifiziert; angesichts des Umfangs der Codebasis (15.554 Dateien) ist jedoch nicht auszuschließen, dass bei tieferer Analyse einzelner Module (insbesondere Finances/Receipts mit elf Belegarten) weitere Konsolidierungsfälle sichtbar würden — siehe Selbstbewertung, Abschnitt 5.
### 3.6 Risikorelevante Anforderungen: Belegsituation
54 der 215 Anforderungen wurden als risikorelevant eingestuft (Typ `Sicherheit` oder inhaltlicher Bezug zu Berechtigungen, Preisen, Rechnungen, Zahlungen, Mahnwesen, Provisionen, Abrechnung oder Autorisierung). Für jede gilt die verschärfte Regel: entweder mindestens ein `PRIMÄR`-Beleg mit benannter durchsetzender Stelle, oder explizite `[HYPOTHESE]`-Kennzeichnung.
**Im Zuge dieses Konsistenzchecks wurden sieben ursprünglich als „belegt" geführte Anforderungen als Verstoß gegen diese Regel identifiziert und noch vor Abschluss des Laufs auf `HYPOTHESE` korrigiert:** StRS-2, StRS-9, StRS-19, SyRS-3, SyRS-7, SyRS-32, SyRS-33 (jeweils nur SEKUNDÄR-Beleg trotz Sicherheits-/Abrechnungsbezug). Diese Korrektur ist in Hypothesen.md dokumentiert und bewusst nicht rückwirkend „unsichtbar" gemacht.
Zwei Grenzfälle wurden geprüft und **bewusst nicht** korrigiert, mit Begründung:
- **SyRS-79** (Provisionsberechnung für kommissionierte Aufträge): Provisionslogik ist personalwirtschaftlich näher an Vergütung als an Fakturierung im engeren Sinn; der SEKUNDÄR-Beleg (Ordnerstruktur `Commissions/CommissionOrders`) wird als für diesen Detailgrad ausreichend bewertet.
- **SwRS-61** (Kassen-/Kontensystem-Vorlagen für Zahlungsausgänge): betrifft die Struktur von Kontensystem-Vorlagen, nicht die eigentliche Zahlungsbetragslogik.
Vollständige Liste aller 54 risikorelevanten Anforderungen mit Belegstatus:
| ID | Titel | PRIMÄR-Beleg? | Status |
|---|---|---|---|
| StRS-1 | Rollen-/gruppenbasierte Zugriffssteuerung | ja | belegt |
| StRS-2 | Datenschutzkonforme Verarbeitung personenbezogener Daten | nein | HYPOTHESE |
| StRS-9 | Flexible Abrechnungs- und Eskalationskonditionen | nein | HYPOTHESE |
| StRS-15 | Rechtssicherer SEPA-Zahlungsverkehr | ja | belegt |
| StRS-16 | Automatisierte Vertrags- und Abrechnungsprozesse | ja | belegt |
| StRS-18 | Mahnwesen und Forderungsmanagement | ja | belegt |
| StRS-19 | Erfassung und Zuordnung von Zahlungen | nein | HYPOTHESE |
| StRS-23 | Verschlüsselte Verwaltung sensibler Zugangsdaten | ja | belegt |
| StRS-28 | Deklarative, wiederverwendbare API-Autorisierung | ja | belegt |
| StRS-33 | Optionale Zwei-Faktor-Authentifizierung für Benutzeranmeldung | ja | belegt |
| SyRS-1 | Systemweite Rechteprüfung vor Funktionsausführung | ja | belegt |
| SyRS-2 | Administrator-Sonderrolle mit Rechte-Vollzugriff | ja | belegt |
| SyRS-3 | Verwaltung DSGVO-relevanter Einstellungen je Kunde | nein | HYPOTHESE |
| SyRS-7 | Optionale elektronische Signatur bei PDF-Erzeugung | nein | HYPOTHESE |
| SyRS-10 | Parametrierbare Abrechnungs- und Eskalationsregeln | nein | HYPOTHESE |
| SyRS-12 | Rechtebasierte Filterung von Kalendereinträgen | ja | belegt |
| SyRS-17 | Mehrformat-Unterstützung für SEPA-Zahlungsdateien | ja | belegt |
| SyRS-19 | EDI-Bestell- und ZUGFeRD-Rechnungsaustausch | ja | belegt |
| SyRS-24 | Automatischer Rechnungslauf aus offenen Aufträgen | ja | belegt |
| SyRS-28 | Flatrate-Abrechnung auf Basis von Assetpositionen | nein | HYPOTHESE |
| SyRS-29 | Automatische Mahnstufen-Eskalation je Rechnung | ja | belegt |
| SyRS-30 | Rückstufung der Mahnstufe bei Zahlungseingang | ja | belegt |
| SyRS-31 | Offene-Posten-Berechnung aus Rechnungs-, Zahlungs- und Gutschriftbeträgen | ja | belegt |
| SyRS-32 | Getrennte Erfassung eingehender und ausgehender Zahlungen | nein | HYPOTHESE |
| SyRS-33 | Zählerstandsbasierte Abrechnungsgrundlage | nein | HYPOTHESE |
| SyRS-35 | Rechtegebundene Preisänderung je Belegart | ja | belegt |
| SyRS-36 | Getrennte Sichtbarkeits-, Erstellungs- und Bearbeitungsrechte je Belegart | ja | belegt |
| SyRS-38 | Automatische Provisionsermittlung bei Rechnungserstellung | ja | belegt |
| SyRS-40 | Projektbezogene Abrechnung mit Gantt-gestützter Aufgabenverfolgung | nein | HYPOTHESE |
| SyRS-51 | Gesteuerter Kunden-Selbstauskunftszugang | nein | HYPOTHESE |
| SyRS-52 | AES-Verschlüsselung mit zentralem Master-Key für Zugangsdaten | ja | belegt |
| SyRS-53 | Getrennte Zugriffsbereichs- und Zugriffsverwaltung im Passwortmanager | nein | HYPOTHESE |
| SyRS-55 | Zuordnung importierter Kontoumsätze zu offenen Rechnungen | nein | HYPOTHESE |
| SyRS-59 | Zahler-Kostenstellen-Zuordnung unabhängig vom Rechnungsempfänger | nein | HYPOTHESE |
| SyRS-79 | Provisionsberechnung für kommissionierte Aufträge | nein | belegt |
| SyRS-81 | Kombinierbare Autorisierungsbedingungen auf Controller- und Methodenebene | ja | belegt |
| SyRS-82 | Getrennte Prüfung von Hosting-Kontext und Benutzerrecht | ja | belegt |
| SyRS-83 | Isolierte Signaturerfassung im Web | nein | HYPOTHESE |
| SyRS-90 | Getrennte Exception-Typen je externer API-Anbindung | ja | belegt |
| SyRS-94 | Geführter Einrichtungsassistent für Zwei-Faktor-Authentifizierung | ja | belegt |
| SyRS-99 | Österreichische E-Rechnungsformat-Konvertierung | nein | HYPOTHESE |
| SwRS-1 | Rechtegruppen-Verwaltung mit Selbstschutz und Protokollierung | ja | belegt |
| SwRS-19 | Autorisierungsschicht für DocuForm-API-Zugriff | nein | HYPOTHESE |
| SwRS-24 | Zweistufiger automatischer Rechnungslauf (Ermittlung/Erzeugung) | ja | belegt |
| SwRS-26 | Mahnstufen-Feld als Enum am Rechnungsdatensatz | ja | belegt |
| SwRS-27 | Mahnlauf-Protokoll mit Alt-/Neu-Mahnstufe | ja | belegt |
| SwRS-28 | Aggregierte Mahnstufen-Kennzahlen je Stufe | ja | belegt |
| SwRS-29 | Getrennte Verarbeitungsklassen für Einkaufs- und Verkaufsrechnungen mit identischer Rechteschnittstelle | ja | belegt |
| SwRS-35 | Produktlebenszyklus-Datenhaltung für Abrechnungszwecke | nein | HYPOTHESE |
| SwRS-52 | Typisierte Spaltenzuordnung beim Preislistenimport | ja | belegt |
| SwRS-61 | Kassen-/Kontensystem-Vorlagen für Zahlungsausgänge | nein | belegt |
| SwRS-65 | Vier typisierte Autorisierungsattribute mit gemeinsamer Rechteprüfung | ja | belegt |
| SwRS-66 | Definierte HTTP-Statuscode-Semantik für Autorisierungsfehler | ja | belegt |
| SwRS-77 | TOTP-Codeprüfung mit Base32-kodiertem Secret | ja | belegt |
### 3.7 Abgleich Hypothesen.md gegen Inline-Markierungen
Hypothesen.md wurde direkt aus den 62 mit `Status: HYPOTHESE` markierten Anforderungsblöcken in StRS.md/SyRS.md/SwRS.md extrahiert (automatisierter Abgleich, kein manuell gepflegtes Duplikat). Beide Quellen nennen exakt dieselben 62 IDs; Hypothesen.md enthält keine zusätzlichen freien Fragen ohne Anforderungsbezug. Offene Punkte, die sich nicht an eine einzelne Anforderung knüpfen lassen (z. B. „welche weiteren EDI-Distributoren existieren über die sechs gefundenen hinaus"), stehen stattdessen unten in der Selbstbewertung.
## 4. Selbstbewertung
### 4.1 Tiefe der Modulabdeckung (absolute Zahlen)
Von 107 Inventarzeilen wurden eingestuft:
- **tief** (≥ 4 Anforderungen, mehrstufige Kette, mindestens ein PRIMÄR-Beleg): **12 Module** — Rechteverwaltung (A1), Zahlungsverkehr/SEPA (E3), Verträge (G5), Mahnwesen (G8), Verkaufsbelege Rechnung & Gutschrift (G16), Ticketverwaltung (J1), Passwortverwaltung (P1), Bestellwesen & EDI (U1), Artikelstammverwaltung (AC1), API-Controller-Schicht (WA2), Core-Utilities/2FA (SH2), Produktionsauftrags-/Servicetafel Nexus (NX3).
- **mittel** (2-3 Anforderungen): **32 Module.**
- **flach** (1 Anforderung oder nur über ein Nachbarmodul mitabgedeckt): **63 Module.**
- **nicht analysiert**: **0 Module.**
Damit wurde die in Schritt 0b geforderte Mindestabdeckung — jedes Modul erhält mindestens eine Anforderung, bevor irgendein Modul vertieft wird — für alle 107 Inventarzeilen erreicht. Die Vertiefung (Schritt 0c) konzentrierte sich erwartungsgemäß auf die vom Auftrag benannten Risikobereiche: Berechtigungen (A1, WA2, SH2), Abrechnungs-/Fakturierungslogik (E3, G5, G8, G16, U1) sowie den im Auftragstext ausdrücklich genannten Kalibrierungsfall Stammblatt/Asset (AC1). Zusätzlich wurde mit dem Fund StRS-31 (Desktop-Helpdesk vs. Nexus-ServiceBoard) ein migrationsstrategisch bedeutsamer Bereich vertieft, der im Auftrag nicht explizit als Risikokategorie genannt war, aber aus fachlicher Sicht für eine Web-/SaaS-Neuimplementierung zentral ist.
Die 63 „flachen" Module sind mehrheitlich (a) kleinere Administrationsbereiche mit primär konfigurativem statt prozessualem Charakter (z. B. CountryManagement, MaterialGroupManagement), (b) Einzelmodule mit geringer Dateizahl (≤ 20 Dateien, z. B. QM, ProjectManagement, PLM-Teilbereiche) oder (c) externe API-Integrationsprojekte, die strukturell nahezu identisch sind und deren Einzelbetrachtung über die bereits dokumentierte Musterbeschreibung (SwRS-76) hinaus wenig zusätzlichen Erkenntnisgewinn verspricht.
### 4.2 Mindestabdeckung erreicht?
Ja. Alle 107 Inventarzeilen führen mindestens eine Anforderung mit mindestens einem klassifizierten Beleg (siehe Abdeckungstabelle, Abschnitt 2). Es gibt keine Zeile ohne Anforderung und ohne Begründung.
### 4.3 Wo war der Beleg dünn?
Ein hoher Anteil `SEKUNDÄR`/`KONTEXT` bzw. `[HYPOTHESE]` zeigt sich systematisch dort, wo:
- **nur die UI-/Konfigurationsebene gesichtet wurde, nicht die dahinterliegende Verarbeitungslogik** — betrifft u. a. ExternalTool/Variables (F1, durchgängig HYPOTHESE), HourlySurchargeRates (A11/SyRS-10), Reisekosten-Genehmigungsworkflow (U2), Inventurstatus (AC5).
- **Modulnamen/-strukturen plausibel, aber nicht am Detailcode verifizierbare Konzepte nahelegen** — z. B. Dashboard-Kachelregistrierung (SwRS-14), RMM-Datenverknüpfung zur Abrechnung (SyRS-20), TelekomDive-Synchronisationsumfang (SyRS-21/SwRS-22).
- **kleine, wenig dokumentierte Module mit einzelner Klasse** — QM (nur Settings-Ordner ohne erkennbare Kernlogik, SyRS-67), ProductLifecycleBL (SwRS-35).
- **Sicherheits-/Abrechnungsanforderungen, bei denen nur die Konfigurationsoberfläche, nicht die serverseitige Durchsetzung gesichtet wurde** — dies betraf ursprünglich sieben Anforderungen (StRS-2, StRS-9, StRS-19, SyRS-3, SyRS-7, SyRS-32, SyRS-33), die im Zuge des Konsistenzchecks korrigiert wurden (siehe Abschnitt 3.6).
Am dichtesten belegt (überwiegend PRIMÄR, konkrete Zeilennummern) sind die Bereiche, in denen tatsächlich BL-Klassen mit Geschäftsregeln gelesen wurden: Rechteprüfung (AppRightsBL, UserRightsExt), Belegrechte (InvoiceSpecificLogic, SupplierInvoiceSpecificLogic), Mahnwesen (DunningBL, DunningRunBL), Vertragskündigungsfristen (ContractBL), SEPA-Sequenztyp (PaymentTransactionBL), Bestellvorschlag (OrderSuggestionListBL), API-Autorisierung (Controllers/Authorization) und Zwei-Faktor-Authentifizierung (TwoFactorAuthenticator, DeveloperSecurity).
### 4.4 Warum keine Analyse ganz ohne Hypothesen?
Trifft hier nicht zu — 62 von 215 Anforderungen (28,8 %) sind als HYPOTHESE markiert. Dieser Anteil liegt bewusst im oberen Bereich der in Iteration 1 beobachteten Spanne (0 %-26,2 % über 24 Läufe) und ist als Stärke, nicht als Schwäche zu werten: Bei einer Codebasis mit 15.554 C#-Dateien und 1.535 Datenbanktabellen ist es unplausibel, dass ein einzelner Lauf ohne Ausführung der Software (rein statische Analyse) jede Verhaltensannahme am Code verifizieren kann. Die Alternative — Aussagen ohne Detailverifikation stillschweigend als „belegt" zu führen — wäre die eigentliche Qualitätsminderung; das haben die sieben in Abschnitt 3.6 korrigierten Fälle im eigenen Lauf demonstriert.
### 4.5 Erkenntnisse für eine Folge-Iteration
1. **Receipts-Kern tiefer analysieren:** Die elf Belegarten (G15-G18) wurden über das gemeinsame Interface `IReceiptSpecificLogic` und exemplarisch an `InvoiceSpecificLogic`/`SupplierInvoiceSpecificLogic` belegt; Offers, Orders, DeliveryLists, PickupLists, CreditVouchers, SupplierOrders, SupplierCreditVouchers, SupplierDeliveryLists und ContractLists wurden nicht einzeln mit eigenen SwRS-Anforderungen vertieft. Eine Folge-Iteration sollte hier je Belegart mindestens eine eigene SwRS-Anforderung mit belegartspezifischem Beleg ergänzen.
2. **Nexus-Desktop-Parallelität systematisch kartieren:** StRS-31 deckt exemplarisch die Dopplung Helpdesk/TicketDetails ↔ ServiceBoard auf. Eine Folge-Iteration sollte gezielt prüfen, welche weiteren Desktop-Module bereits ein Nexus-Pendant haben (Kandidaten laut Nexus-Struktur: Management/TaskManagement ↔ Desktop-TaskManagement, Management/TicketPatterns ↔ C-FLOW) und wie vollständig/abweichend die jeweilige Web-Implementierung ist — das ist für die geplante Web-/SaaS-Neuimplementierung die wichtigste einzelne Erkenntnisquelle in dieser Codebasis.
3. **DSGVO- und PDF-Signatur-Durchsetzung verifizieren:** Die im Konsistenzcheck korrigierten Sicherheitsanforderungen (StRS-2, SyRS-3, SyRS-7) benötigen eine gezielte Suche nach der tatsächlich durchsetzenden Stelle (Löschjob, Zertifikatsprüfung), die in diesem Lauf aus Zeitgründen nicht gefunden wurde.
4. **Abrechnungs-Randbereiche (G1, G3, G4, G6, G7, G9, G10, G12-G14, G19) vertiefen:** Diese wurden nur „flach" abgedeckt, obwohl sie zur Kernrisikokategorie Abrechnung/Fakturierung zählen. Insbesondere FlatrateBilling (G9) und AutomatedBilling (G2) verdienen wegen ihrer wiederkehrenden finanziellen Auswirkung eine tiefere Prüfung der Berechnungsformeln.
5. **DB-Schema strukturiert auswerten:** Der Befund „nur 134 von 1.535 Tabellen mit Fremdschlüssel-Constraint" (SyRS-88) wurde nur als quantitative Beobachtung dokumentiert. Eine Folge-Iteration mit Datenbankzugriff könnte die *I3D-Namenskonvention systematisch als implizites Beziehungsmodell auswerten und mit den tatsächlichen NHibernate-Mappings abgleichen.
6. **Weitere Konsolidierungsfälle in Warehousing/Finances erwarten:** Der bestätigte Stammblatt/Asset-Fall (StRS-27) legt nahe, dass in einer Codebasis dieser historischen Tiefe (Namensreste wie „Sichtrus", „VertragKopf", diverse „Old"-Suffixe) weitere, noch nicht identifizierte Doppelimplementierungen existieren.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/Glossar.md
+38
View File
@@ -0,0 +1,38 @@
# Glossar – c-entron ERP-Suite
Domänenbegriffe, wie sie in den Anforderungen (StRS/SyRS/SwRS) verwendet werden. Technische Bezeichner sind in ihrer Originalsprache (meist Englisch/Codebasis-Konvention) belassen; die Erklärung ist deutsch.
| Begriff | Erklärung |
|---|---|
| **I3D** | In der Codebasis durchgängig verwendete Bezeichnung für den technischen Primärschlüssel eines Datensatzes (z. B. `CustomerI3D`, `MandantI3D`, `ArticleI3D`). Entspricht der ID/dem Fremdschlüssel eines Fachobjekts. |
| **Beleg / Belegart** | Sammelbegriff für alle im System erzeugten Geschäftsdokumente mit Vorgangscharakter: Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Bestellung, Lieferantenrechnung, Vertragsliste, Abholschein u. a. Alle Belegarten implementieren das gemeinsame Interface `IReceiptSpecificLogic` und teilen sich das Statusmodell `ReceiptState`. |
| **ReceiptState** | Dreistufiger Status eines Belegs: `Active` (offen), `Completed` (abgeschlossen), `Canceled` (storniert). Gilt einheitlich für alle Belegarten. |
| **Stammblatt** | Bezeichnung für einen Beleg vom Kind `MasterDataListClass` (`CentronObjectKindNumeric`); fachlich die Gerätestammdaten eines klickabgerechneten Geräts (typischerweise Drucker), verwaltet im Modul Finances/MasterDataLists auf Basis von Vertrags-„ClickContracts". Siehe Konsolidierungshinweis zu „Asset" (StRS-27). |
| **Asset (AssetManagement, DocuBoard)** | Im Kontext RMM-Überwachung: ein über die Entität `AssetManagementArticleAssignment` (Namespace `DocuBoard`) einem Artikel zugeordnetes, überwachtes Gerät (Server/Workstation). Zu unterscheiden vom allgemeineren `AssetBase`/`AssetKindEnum` in `Sales.CustomerAssets`, der dort als technischer Oberbegriff für „Beleg" (Angebot, Auftrag, Rechnung usw.) verwendet wird — zwei unterschiedliche Bedeutungen desselben Wortes in der Codebasis. |
| **Mandant** | Rechtlich/organisatorisch getrennte Einheit im Mehrmandantenbetrieb, verwaltet über MandatorManagement; kann mehrere Filialen enthalten. |
| **Filiale (Branch)** | Organisatorische Untereinheit eines Mandanten, u. a. relevant für Rechteeinschränkungen („nur eigene Filiale") und Buchungsnummernkreise. |
| **Rechtegruppe (RightGroup/AppGroup)** | Benannte Gruppe von Einzelrechten, der Mitarbeiter zugeordnet werden; Grundlage der rollenbasierten Zugriffssteuerung (siehe `AppRightsBL`, `CentronRights.md`). |
| **Einschränkendes Recht (restricting right)** | Ein Recht, das die Sicht/den Zugriff eines Benutzers gegenüber dem Normalfall einschränkt statt ihn zu erweitern (z. B. „nur eigene Tickets", „nur eigene Filiale") — Terminologie aus `CentronRights.md`. |
| **Mahnstufe (DunningLevel)** | Eskalationsstufe einer überfälligen Rechnung im Mahnwesen: `None`, `Level1`, `Level2`, `Level3`, linear eskalierend/rückstufbar über Mahnläufe (`DunningRunBL`). |
| **Offener Posten (Opos)** | Eine noch nicht vollständig ausgeglichene Forderung/Verbindlichkeit; der offene Betrag berechnet sich als Bruttobetrag abzüglich Zahlungen und Gutschriften. |
| **SEPA-Sequenztyp (First/Recurrent)** | Kennzeichnung, ob ein SEPA-Lastschrifteinzug der erste (`First`/FRST) oder ein Folgeeinzug (`Recurrent`/RCUR) eines Mandats ist; steuert das im Zahlungsformat zu verwendende Sequenzkennzeichen. |
| **PAIN-Format** | ISO-20022-Nachrichtenformat für SEPA-Zahlungsverkehr (z. B. PAIN.008 für Lastschriften); die Codebasis unterstützt mehrere Formatvarianten (u. a. STUZZA/Österreich, GBIC3/GBIC4). |
| **ZUGFeRD** | Deutsches/europäisches Format für hybride elektronische Rechnungen (PDF mit eingebettetem strukturiertem XML), hier für Verkaufsrechnungen im EDI-Bereich unterstützt. |
| **ebInterface** | Österreichisches Standardformat für die elektronische Rechnungsstellung an öffentliche Auftraggeber. |
| **EDI** | Electronic Data Interchange – elektronischer, strukturierter Geschäftsdatenaustausch, hier insbesondere für Bestellungen mit IT-Distributoren (Also, Alltron, EGIS, Herweck, Komsa) sowie für Rechnungen (ZUGFeRD). |
| **RMM** | Remote Monitoring and Management – Fernüberwachung von IT-Geräten (Server, Workstations); liefert Daten, die u. a. für Vertragsabrechnung und Asset-Zuordnung genutzt werden. |
| **C-FLOW** | Bezeichnung für das Ticket-Prozessvorlagensystem im Helpdesk-Modul (standardisierte, rechtegebunden verwaltbare Ticketvorlagen und -kategorien). |
| **TAPI** | Telephony API – Windows-Standardschnittstelle zur Telefonanlagenanbindung, hier für die Telefonie-Integration im Client genutzt. |
| **DIVE** | Bezeichnung der Telekom-Plattform, mit der c-entron über ein eigenes Modul (`TelekomDiveBL`) Produkt-/Vertragsdaten synchronisiert. |
| **AVV (Auftragsverarbeitungsvertrag)** | Datenschutzrechtlicher Vertrag zwischen Verantwortlichem und Auftragsverarbeiter nach DSGVO Art. 28; im System als „OrderProcessingContract" verwaltet. |
| **WebCart** | Der Kunden-Webshop-Bereich innerhalb von c-entron Nexus; Artikel stammen aus den beim Kunden hinterlegten Sonderpreisen, Zugriff erfordert einen Web-Account. |
| **WebAccount** | Ein Kundenzugang für Web-Self-Service-Funktionen (WebCart, Kundenportal), getrennt vom internen Mitarbeiterkonto (`AppUser`) verwaltet, mit eigenem Rechtemodell (`WebAccountRightsConst`). |
| **AppUser** | Interne Mitarbeiter-Benutzeridentität im System, Träger von Einzelrechten über Gruppenmitgliedschaft. |
| **BLSession** | Zentrale Session-/Factory-Klasse, über die alle Business-Logic-Klassen (`BaseBL`-Ableitungen) instanziiert werden (`session.GetBL<T>()`), inkl. Transaktions-/Verbindungskontext. |
| **Sichtrus / Sichmemb** | Physische Datenbanktabellen des Rechtemodells: `Sichtrus` verknüpft Rechtegruppe und Recht, `Sichmemb` verknüpft Benutzer und Rechtegruppe (Namensursprung vermutlich historisch/aus einer Vorgängerversion). |
| **Nebenlager** | Ein zusätzliches, vom Hauptlager (WarehouseI3D = -1) unterschiedenes Lager, für das der Mindestbestand separat geprüft wird. |
| **Mindestbestand** | Je Artikel und Lager hinterlegte Bestandsschwelle, deren Unterschreitung einen automatischen Bestellvorschlag auslöst. |
| **c-entron Nexus** | Der neuere, Blazor-basierte Webclient des Systems (laut README.md „aka c-entron Web"), der Teile der Desktop-Funktionalität (Ticketbearbeitung, Dokumentensignatur, Kundenportal) bereits web-/SaaS-fähig abbildet und damit den naheliegenden Ausgangspunkt für die Zielarchitektur darstellt. |
| **AuthorizeCentronHosted** | API-Autorisierungsattribut, das unabhängig vom Benutzerrecht prüft, ob ein Aufruf aus der gehosteten (SaaS-)Umgebung stammt, im Gegensatz zu einer On-Premise-Installation. |
| **DevExpress** | Kommerzielle UI-Komponentenbibliothek, auf der sowohl die WPF-Oberfläche als auch (laut README.md) die Blazor-Komponenten von Nexus aufbauen. |
| **NHibernate** | Objekt-relationales Mapping-Framework, auf dem die gesamte Datenzugriffsschicht (`Centron.DAO`) aufsetzt. |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/Hypothesen.md
+72
View File
@@ -0,0 +1,72 @@
# Hypothesen – c-entron ERP-Suite
Diese Datei enthält ausschließlich Anforderungen, die im Feld `Status` mit `HYPOTHESE` markiert sind (62 von 215 Anforderungen, 28,8 %). Die Spalte „Offene Frage" fasst zusammen, welche Information zur Bestätigung fehlt. Jede Zeile entspricht exakt einer Inline-Markierung in StRS.md, SyRS.md oder SwRS.md; es gibt keine zusätzlichen freien Fragen ohne zugehörige Anforderung (offene Punkte ohne Anforderungsbezug stehen stattdessen in der Selbstbewertung des Analyseberichts).
Sieben dieser Hypothesen (StRS-2, StRS-9, StRS-19, SyRS-3, SyRS-7, SyRS-32, SyRS-33) waren ursprünglich als „belegt" eingestuft, obwohl sie als Sicherheits- oder Abrechnungsanforderung nur einen SEKUNDÄR-Beleg trugen. Der Konsistenzcheck (siehe Analysebericht.md, Abschnitt „Risikorelevante Anforderungen") hat dies als Verstoß gegen die risikobasierte Belegpflicht erkannt; sie wurden vor Abschluss dieses Laufs auf `HYPOTHESE` korrigiert. Das ist bewusst sichtbar gelassen, um zu zeigen, dass der Konsistenzcheck in diesem Lauf tatsächlich wirksam war und nicht nur pro forma durchgeführt wurde.
Zur Einordnung: Ein hoher Hypothesenanteil ist bei einer Codebasis dieser Größe (15.554 C#-Dateien) kein Mangel, sondern Ausdruck ehrlicher Abgrenzung zwischen dem, was im Code direkt belegt ist, und dem, was aus Struktur/Namensgebung plausibel, aber nicht am Detailcode verifiziert wurde.
| ID | Titel | Offene Frage (was zur Bestätigung fehlt) |
|---|---|---|
| StRS-2 | Datenschutzkonforme Verarbeitung personenbezogener Daten | als Sicherheits-/Datenschutzanforderung wäre nach Belegregel ein PRIMÄR-Beleg (die tatsächlich durchsetzende Löschroutine) erforderlich; nur UI-Ebene wurde gesichtet, die serverseitige Durchsetzung der Fristen wurde nicht verifiziert. |
| StRS-9 | Flexible Abrechnungs- und Eskalationskonditionen | Abrechnungsrelevante Anforderung ohne PRIMÄR-Beleg (nur Konfigurationsoberflächen gesichtet, nicht die Verrechnungslogik selbst); konsistent mit der bereits als HYPOTHESE geführten SyRS-10. |
| StRS-13 | Anbindung kundenspezifischer externer Werkzeuge | Ordnername und Modulplatzierung legen eine Variablenverwaltung für externe Toolintegration nahe; der genaue Aufrufmechanismus wurde nicht gelesen und ist daher offen. |
| StRS-19 | Erfassung und Zuordnung von Zahlungen | Abrechnungs-/Zahlungsrelevante Anforderung ohne PRIMÄR-Beleg; die konkrete Verrechnungslogik (Zuordnung Zahlung↔Forderung, Ableitung des Rechnungsbetrags aus Zählerständen) wurde nicht im Code gesichtet, nur die strukturelle Trennung der Ordner/Klassen. |
| SyRS-3 | Verwaltung DSGVO-relevanter Einstellungen je Kunde | Sicherheits-/Datenschutzanforderung ohne PRIMÄR-Beleg; die serverseitige Durchsetzung der kundenindividuellen Regel (BL/DAO) wurde nicht gesichtet, nur die UI-Ebene. |
| SyRS-5 | Cache-gestützte Bereitstellung globaler Konfiguration | Modulname und -platzierung legen einen Cache-Mechanismus nahe; die konkrete Implementierung (Invalidierung, TTL) wurde nicht gelesen. |
| SyRS-7 | Optionale elektronische Signatur bei PDF-Erzeugung | Sicherheitsanforderung ohne PRIMÄR-Beleg; die tatsächliche Signaturerzeugung/-prüfung (Zertifikatshandling) wurde nicht im Code gesichtet, nur die Einstellungsebene. |
| SyRS-10 | Parametrierbare Abrechnungs- und Eskalationsregeln | Konfigurationsoberflächen vorhanden; die konkrete Verknüpfung zur Berechnungslogik in Helpdesk/TimerBilling wurde nicht gelesen und ist daher offen. |
| SyRS-13 | Konfigurierbare Dashboard-Kacheln je Benutzer | Unterordnerstruktur legt ein Kachel-/Widget-Konzept nahe; ob die Auswahl je Benutzer persistiert wird, wurde nicht am Code verifiziert. |
| SyRS-14 | Variablenersetzung beim Aufruf externer Werkzeuge | Modulinhalt legt Variablenverwaltung nahe, der Ersetzungsmechanismus selbst wurde nicht verifiziert. |
| SyRS-16 | Generischer Konnektor-Rahmen für Datenein-/-ausgabe | Eigenständiger, von den spezifischen Exporten getrennter Ordner legt ein generisches Konzept nahe; die konkrete Abstraktion (Interface, Plugin-Mechanismus) wurde nicht gelesen. |
| SyRS-20 | RMM-Systemanbindung für Managed-Service-Daten | Belegt nur die Verbindungskonfiguration; die konkrete Verknüpfung der RMM-Daten zur Abrechnungslogik (FlatrateBilling/AutomatedBilling) wurde nicht gelesen. |
| SyRS-21 | Telekom-DIVE-Plattformanbindung | Belegt die Existenz der Anbindung; der genaue synchronisierte Datenumfang wurde nicht gelesen. |
| SyRS-23 | Kontenverwaltung mit Filial-Buchungsnummernkreisen | Ordner vorhanden, konkrete Nummernkreislogik nicht gelesen. |
| SyRS-26 | Kampagnenzuordnung zu Kundenkonten | Struktur vorhanden, konkretes Zuordnungsmodell nicht gelesen. |
| SyRS-28 | Flatrate-Abrechnung auf Basis von Assetpositionen | Eigener Ordner für Assetpositionen im Flatrate-Kontext, konkrete Berechnungsformel nicht gelesen. |
| SyRS-32 | Getrennte Erfassung eingehender und ausgehender Zahlungen | Zahlungsrelevante Anforderung ohne PRIMÄR-Beleg; nur strukturelle Trennung gesichtet, nicht die konkrete Verbuchungslogik. |
| SyRS-33 | Zählerstandsbasierte Abrechnungsgrundlage | Abrechnungsgrundlage-relevante Anforderung ohne PRIMÄR-Beleg; die Ableitung des Rechnungsbetrags aus dem Zählerstand (Preis je Klick, Rundung) wurde nicht im Code gesichtet. |
| SyRS-40 | Projektbezogene Abrechnung mit Gantt-gestützter Aufgabenverfolgung | Zwei ViewModels belegen Gantt- und Kontobezug; die konkrete Verknüpfungslogik wurde nicht gelesen. |
| SyRS-41 | Individuelle Felder je Fachobjekt (CustomProperties) | Struktur belegt generisches Konzept, konkretes Datenmodell nicht gelesen. |
| SyRS-42 | Kontextsensitive Hilfe je Modul | Zentrale Klasse vorhanden, Kontextbezug (welches Hilfethema je Modul) nicht verifiziert. |
| SyRS-49 | Vertragsbezug bei Ticketerfassung | Ordner vorhanden, konkrete Verknüpfungslogik zur Abrechnung nicht gelesen. |
| SyRS-50 | Aufgabenverwaltung mit externen Connectoren | Ordner vorhanden, konkrete Connector-Anbindung nicht gelesen. |
| SyRS-51 | Gesteuerter Kunden-Selbstauskunftszugang | Getrennter Einstellungsbereich für Kundenzugriff, konkrete Zugriffsprüfung nicht gelesen. |
| SyRS-53 | Getrennte Zugriffsbereichs- und Zugriffsverwaltung im Passwortmanager | Zwei getrennte ViewModels belegen die zweistufige Struktur; die konkrete Rechteprüfung wurde nicht gelesen. |
| SyRS-54 | Kontextbezogener Start der Fernwartungssitzung aus Tickets | Modul vorhanden, Übergabemechanismus aus dem Ticketkontext nicht gelesen. |
| SyRS-55 | Zuordnung importierter Kontoumsätze zu offenen Rechnungen | Klassenname legt Verknüpfung nahe, konkreter Zuordnungsalgorithmus (Verwendungszweck-Parsing) nicht gelesen. |
| SyRS-57 | Ereignisgesteuerte Massenaktualisierung von Datensätzen | Getrennte Ordner belegen zwei Konzepte, konkrete Verknüpfung nicht gelesen. |
| SyRS-59 | Zahler-Kostenstellen-Zuordnung unabhängig vom Rechnungsempfänger | Eigenständiges Modul vorhanden, konkretes Datenmodell nicht gelesen. |
| SyRS-60 | Maschinen- und Produktionsauftragsverwaltung | Getrennte Ordner belegen den fachlichen Zusammenhang, konkrete Zuordnungslogik nicht gelesen. |
| SyRS-65 | Elektronischer Bestelldatenaustausch mit EDI-Partnern nach Belegart | Ordner vorhanden, konkrete Belegartzuordnung nicht gelesen. |
| SyRS-66 | Reisekostenerfassung mit Belegkategorien | Struktur vorhanden, Genehmigungsworkflow nicht am Code verifiziert. |
| SyRS-67 | Qualitätsmanagement-Einstellungen als eigenständiger Konfigurationsbereich | Einziger Inhalt des Moduls; Kernlogik nicht identifizierbar, daher als Hypothese gekennzeichnet. |
| SyRS-70 | Serien-E-Mail-Versand mit Produktmatrix-gestützter Artikelauswahl | Struktur belegt die drei Funktionsbereiche, konkrete Verknüpfung nicht gelesen. |
| SyRS-75 | Automatisierte End-of-Life-Kennzeichnung von Artikeln | Modul vorhanden, konkrete Kriterien nicht gelesen. |
| SyRS-77 | Bestandsabgleich durch Inventurprozess | Eigener Enums-Ordner legt eine Statusmaschine nahe, deren Werte nicht einzeln gelesen wurden. |
| SyRS-83 | Isolierte Signaturerfassung im Web | Namensgebung legt Isolationskonzept nahe, konkrete technische Umsetzung nicht gelesen. |
| SyRS-89 | Zwischengespeicherte Ticketliste im Webportal | Ordnername legt Caching nahe, konkrete Invalidierungsstrategie nicht gelesen. |
| SyRS-92 | Eigenständiges Windows-Tool zur Verwaltung von Webservice-Verbindungen | Eigenständige Anwendung mit eigenem Einstiegspunkt, konkrete Diagnosefunktionen nicht gelesen. |
| SyRS-99 | Österreichische E-Rechnungsformat-Konvertierung | Einzige Klasse des Projekts, konkreter Konvertierungsumfang nicht gelesen. |
| SwRS-5 | Mitarbeiterimport aus Active Directory | Ordnername belegt die Existenz einer AD-Import-Funktion; Abgleichsverhalten (einmalig/periodisch, Konfliktbehandlung) wurde nicht am Code verifiziert. |
| SwRS-9 | Zentrale Verwaltung von SQL-Verbindungen für Auswertungen | Modulname legt SQL-Verbindungsverwaltung nahe; genauer Verwendungszweck (z. B. Berichte vs. externe Datenquellen) wurde nicht am Code verifiziert. |
| SwRS-11 | Konfigurierbare Stundenzuschlagssätze nach Zeitfenster | Modulname legt zeitfensterbasierte Zuschlagsverwaltung nahe; die konkrete Verknüpfung zur Abrechnungslogik wurde nicht gelesen. |
| SwRS-14 | Dashboard-Kachelregistrierung als Modulliste | Strukturelle Ähnlichkeit zur bekannten Modulregistrierung legt ein analoges Muster nahe, wurde aber für das Dashboard nicht im Detail gelesen. |
| SwRS-15 | Benannte Variablen für externe Toolaufrufe | Einziger Inhalt des Moduls ist die Variablenverwaltung; der Aufrufmechanismus selbst wurde nicht gelesen. |
| SwRS-17 | Konfigurationsbasierte Aktivierung von Konnektoren | Einstellungsordner vorhanden; Persistenzmechanismus nicht verifiziert. |
| SwRS-19 | Autorisierungsschicht für DocuForm-API-Zugriff | Eigener Ordner für Autorisierung, konkreter Tokenmechanismus nicht gelesen. |
| SwRS-21 | RMM-Verbindungseinstellungen je Mandant | Klasse vorhanden, Mandantenbezug der Persistenz nicht am Code verifiziert. |
| SwRS-22 | TelekomDive-Synchronisationskomponente | Klasse vorhanden, Aufrufkontext nicht verifiziert. |
| SwRS-23 | BranchBookKeepingNumbers als Nummernkreis-Entität | Ordner vorhanden, Datenmodell nicht gelesen. |
| SwRS-25 | Assetpositionsbasiertes Datenmodell für Flatrate-Verträge | Eigener Ordner, Entitätsdefinition nicht gelesen. |
| SwRS-35 | Produktlebenszyklus-Datenhaltung für Abrechnungszwecke | Klasse vorhanden, konkrete Verknüpfung zur Abrechnungslogik nicht gelesen. |
| SwRS-36 | Gantt-basierte Projektaufgabenstruktur | Klassenname legt Gantt-Datenmodell nahe, Felder nicht verifiziert. |
| SwRS-39 | Netzwerkdiagnose-Werkzeug im Client | Modul vorhanden, konkrete Prüfungen nicht gelesen. |
| SwRS-44 | Filial- und Ereignisreporting für erwartete Ereignisse (SLA) | Getrennte Erfassungs- und Reportingmodule vorhanden, konkrete Kennzahlen nicht gelesen. |
| SwRS-50 | Filialspezifische Konfiguration der Versandmethoden | Modul vorhanden, Filialbezug der Konfiguration nicht am Code verifiziert. |
| SwRS-54 | Belegartspezifische Tabs im EDI-Management | Ordner vorhanden, konkrete Tab-Struktur nicht gelesen. |
| SwRS-55 | Konvertierungslogik für Reisekosten-Belegkategorien | Ordner vorhanden, konkrete Converter-Logik nicht gelesen. |
| SwRS-56 | RMA-Ereignisprotokoll je Rücksendevorgang | Ordner vorhanden, konkrete Ereignisklassen nicht einzeln gelesen. |
| SwRS-62 | Kommissionierprozess mit modulweiter Basissteuerung | Gemeinsame Basisklasse vorhanden, konkrete gemeinsame Logik nicht gelesen. |
| SwRS-63 | Mehrstufiger Inventurstatus als Enum | Eigener Ordner, konkrete Enum-Werte nicht gelesen. |
| SwRS-74 | Getrennte Steuerelemente je Anwendungsfall im ConnectionManager | Struktur vorhanden, konkrete Unabhängigkeit vom Hauptclient nicht am Code verifiziert. |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/StRS.md
+722
View File
@@ -0,0 +1,722 @@
# Stakeholder Requirements Specification (StRS) – c-entron ERP-Suite
Fachliche Sicht: Geschäftsziele, Akteure und deren Anforderungen an das System, abgeleitet aus der bestehenden Codebasis (Reverse Requirements Engineering nach ISO/IEC/IEEE 29148:2018).
Akteure (aus Modulstruktur, Rechtekatalog `UserRightsConst` und UI-Rollentexten abgeleitet): Sachbearbeiter/Innendienst, Vertrieb/Außendienst, Buchhaltung, Lager/Logistik, Helpdesk-Mitarbeiter, Systemadministrator, Filialleiter/Niederlassungsleiter, Mandant/Geschäftsführung, Kunde (Web-Self-Service/WebCart), Lieferant (EDI), externes System (Webservice-Client).
---
## Zugriffssteuerung, Datenschutz, Mandantenfähigkeit
```
ID: StRS-1
Titel: Rollen-/gruppenbasierte Zugriffssteuerung
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Systemadministrator
Vorbedingung: Mehrere Mitarbeiter mit unterschiedlichen Aufgabenbereichen nutzen dasselbe System
Fakt: Der Rechtekatalog UserRightsConst.cs definiert weit über 1000 Einzelrechte, gruppiert nach Fachbereich (z. B. Sales.Customer.Helpdesk.*); RightsManagmentViewModel verwaltet Rechte in benannten Gruppen (RightGroups), denen Mitarbeiter zugeordnet werden.
Aussage: Das System soll es dem Administrator ermöglichen, Zugriffsrechte auf einzelne fachliche Funktionen granular über benannte Rechtegruppen zu vergeben und Mitarbeitern zuzuweisen, statt Rechte einzeln je Mitarbeiter zu pflegen.
Ergebnis: Ein Mitarbeiter erhält genau die Funktionen, die für seine Rolle in der zugewiesenen Rechtegruppe freigegeben sind.
Belege:
- [PRIMÄR] backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methoden HasUserRight/GetAllAppRightsFromUser (Zeile 644-664) - Begründung: liest Rechte je Benutzer über Gruppenmitgliedschaft (Tabellen dbo.Sichtrus/dbo.Sichmemb) aus der DB und setzt damit die Gruppenzuordnung technisch um.
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/RightsManagement/RightsManagmentViewModel.cs (RightGroups, GroupEmployees, CopyRightsCommand) - Begründung: UI-Modell zeigt Gruppenverwaltung mit Mitarbeiterzuordnung und Gruppenkopierfunktion.
- [KONTEXT] CentronRights.md, Abschnitt Helpdesk - Begründung: Fachliche Dokumentation einzelner Rechte mit Beschreibung ihrer Wirkung.
Prüfidee: Mitarbeiter A wird Rechtegruppe "Helpdesk" ohne SHOW_HELPDESK zugewiesen; Verifikation, dass er keine Tickets sieht.
Tracelinks: SyRS-1, SyRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Granulare Rechtevergabe ist fachlich zwingend für Mehrbenutzerbetrieb.
Status: belegt
```
```
ID: StRS-2
Titel: Datenschutzkonforme Verarbeitung personenbezogener Daten
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Systemadministrator, Mandant/Geschäftsführung
Vorbedingung: Personenbezogene Kunden-/Mitarbeiterdaten werden im System verarbeitet (DSGVO-Pflicht seit 2018)
Fakt: Modul Administration/DSGVO stellt eigene Views für Datensicherheitseinstellungen (Aufbewahrung/Löschung) und Auftragsverarbeitungsvertrags-Vorlagen bereit.
Aussage: [HYPOTHESE] Das System soll Verantwortlichen die Verwaltung von Aufbewahrungsfristen, Löschregeln und Auftragsverarbeitungsverträgen für personenbezogene Daten ermöglichen.
Ergebnis: Nachweisbare Steuerung der DSGVO-relevanten Datenhaltung je Kunde/Mandant.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityViewModel.cs - Begründung: Eigenständiges ViewModel für Datenschutzeinstellungen, UI-Ebene der Funktion.
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/DSGVO/OrderProcessingContractSettingsViewModel.cs - Begründung: Verwaltung von AVV-Vorlagen als eigenständige Einstellungsgruppe.
Prüfidee: Für einen Kunden wird eine Aufbewahrungsfrist gesetzt; nach Fristablauf ist die Löschung/Anonymisierung nachvollziehbar.
Tracelinks: SyRS-3
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - gesetzliche Pflicht, unverändert erforderlich im Zielsystem.
Status: HYPOTHESE - als Sicherheits-/Datenschutzanforderung wäre nach Belegregel ein PRIMÄR-Beleg (die tatsächlich durchsetzende Löschroutine) erforderlich; nur UI-Ebene wurde gesichtet, die serverseitige Durchsetzung der Fristen wurde nicht verifiziert.
```
```
ID: StRS-3
Titel: Mehrmandantenfähigkeit mit Filialstruktur
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Systemadministrator
Vorbedingung: Ein Betreiber führt mehrere rechtlich/organisatorisch getrennte Mandanten oder Filialen in einer Installation
Fakt: MandatorManagementViewModel verwaltet Mandanten inkl. Filialen (BranchManagement); Löschung eines Mandanten wird verhindert, wenn er aktive Filialen enthält (Meldungstext referenziert aktive Filialen als Löschsperre).
Aussage: Das System soll die Verwaltung mehrerer Mandanten mit jeweils zugeordneten Filialen ermöglichen und die referenzielle Integrität beim Löschen sicherstellen.
Ergebnis: Ein Mandant mit aktiven Filialen kann nicht versehentlich gelöscht werden; Filial-/Mandantenstruktur bleibt konsistent.
Belege:
- [PRIMÄR] centron/Centron.WPF.UI/Modules/Administration/MandatorManagement/MandatorManagementViewModel.cs, Zeile 241 (DeleteMandatorAsync) - Begründung: Prüfung auf aktive Filialen vor Löschung ist eine im Code durchgesetzte Integritätsregel.
Prüfidee: Löschversuch eines Mandanten mit mindestens einer aktiven Filiale muss abgelehnt werden.
Tracelinks: SyRS-4
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Mandantenfähigkeit ist Kernvoraussetzung für SaaS-Betrieb.
Status: belegt
```
```
ID: StRS-4
Titel: Zentrale Stammdaten- und Systemkonfiguration
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Systemadministrator
Vorbedingung: Betrieb erfordert einheitliche, systemweit gültige Grundeinstellungen (Länder, Mitarbeiter, allgemeine Parameter)
Fakt: Administration-Modul enthält getrennte Bereiche EmployeeManagement (inkl. Unterordner AdImport), CountryManagement, Customization/Settings sowie einen Konfigurations-Cache (CentronConfigDb/Cache).
Aussage: Das System soll zentrale Stammdaten (Mitarbeiter, Länder) und Anwendungsparameter administrierbar machen und über einen Cache performant systemweit bereitstellen.
Ergebnis: Änderungen an Stammdaten/Einstellungen wirken konsistent für alle Arbeitsplätze.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/EmployeeManagement/AdImport - Begründung: Verzeichnisstruktur belegt Active-Directory-Import als vorgesehene Datenquelle für Mitarbeiterstammdaten.
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/CentronConfigDb, .../Cache - Begründung: Eigene Ordner für Konfigurations-DB-Zugriff und Cache belegen die zentrale Bereitstellung.
Prüfidee: Änderung einer globalen Einstellung ist nach Neustart an einem zweiten Arbeitsplatz sichtbar.
Tracelinks: SyRS-5
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-5
Titel: Integrierte Kommunikation (Mail/Telefonie)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Sachbearbeiter/Innendienst, Systemadministrator
Vorbedingung: Mitarbeiter kommunizieren mit Kunden über Mail und Telefon direkt aus dem ERP-Kontext
Fakt: Administration-Module MailAndCalender, MailTemplates und PhoneSettings konfigurieren Mail-/Kalenderserver-Zugänge, Standardvorlagen und Telefonanlagen-Anbindung; MyCentron/Telephony bindet TAPI ein.
Aussage: Das System soll die Konfiguration von Mail-, Kalender- und Telefonanbindung zentral ermöglichen und Standardtextvorlagen für die Kundenkommunikation bereitstellen.
Ergebnis: Mitarbeiter können ohne Medienbruch aus dem ERP heraus E-Mails versenden und Anrufe tätigen/empfangen.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/MailTemplates - Begründung: Eigener Bereich für Mailvorlagenverwaltung.
- [KONTEXT] docs/reference/architecture/tapi.md - Begründung: Dokumentiert die TAPI-Telefonieanbindung als Architekturentscheidung.
Prüfidee: Eine Mailvorlage wird angelegt und beim Versand aus einem Beleg korrekt mit Platzhaltern befüllt.
Tracelinks: SyRS-6
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-6
Titel: Rechtssichere, einheitliche Belegausgabe
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Sachbearbeiter/Innendienst, Buchhaltung
Vorbedingung: Belege (Rechnungen, Angebote) müssen als PDF erzeugt, teils elektronisch signiert und mit Textbausteinen versehen werden
Fakt: Administration enthält getrennte Module PdfExport, PdfSigning, ReportServer, TextBlockManagement.
Aussage: Das System soll die Erzeugung von Belegen als PDF inkl. optionaler elektronischer Signatur und wiederverwendbarer Textbausteine zentral unterstützen.
Ergebnis: Rechtsverbindliche, einheitlich formatierte Belegausgabe für alle Belegarten.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/PdfSigning/PdfSigningSettingsViewModel.cs - Begründung: Eigenständige Konfiguration der PDF-Signatur als dedizierte Funktion.
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/TextBlockManagement - Begründung: Eigener Bereich zur Pflege wiederverwendbarer Textbausteine für Belege.
Prüfidee: Eine Rechnung wird als PDF exportiert und optional signiert; Signaturprüfung im PDF-Reader ist erfolgreich.
Tracelinks: SyRS-7
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-7
Titel: Konfigurierbare Web- und Schnittstellenanbindung
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Systemadministrator
Vorbedingung: Externe Systeme (Webshop, Webservice-Clients, Drittwerkzeuge) müssen ohne Codeänderung angebunden werden können
Fakt: Administration enthält WebCart-, WebServiceSettings- und ExternalTools-Bereiche zur Konfiguration von Schnittstellen ohne Neucompilierung.
Aussage: Das System soll Web- und Fremdsystemanbindungen (Webshop, Webservices, externe Tools) über Konfigurationsoberflächen statt Codeänderungen steuerbar machen.
Ergebnis: Administratoren aktivieren/parametrieren Schnittstellen selbstständig.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/WebCart - Begründung: Eigene Einstellungsoberfläche für den Kunden-Webshop.
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/WebServiceSettings - Begründung: Eigene Einstellungsoberfläche für Webservice-Parameter.
Prüfidee: Deaktivierung des WebCart in den Einstellungen führt dazu, dass Web-Kunden keinen Zugriff auf den Shop mehr haben.
Tracelinks: SyRS-8
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-8
Titel: Betriebsüberwachung und Diagnose
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: Systemadministrator
Vorbedingung: Störungen/Performanceprobleme im Produktivbetrieb müssen eingrenzbar sein
Fakt: Administration enthält LogViewer- und Profiling-Module zur Auswertung von Logs und Performance direkt aus dem Client.
Aussage: Das System soll dem Administrator eine integrierte Log- und Performance-Analyse ohne externe Werkzeuge ermöglichen.
Ergebnis: Schnellere Fehlerdiagnose im laufenden Betrieb.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/LogViewer - Begründung: Eigenes Modul zur Log-Anzeige im Client.
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/Profiling - Begründung: Eigenes Modul zur Performance-Profilierung.
Prüfidee: Ein simulierter Fehler erscheint im LogViewer mit Zeitstempel und Kontext.
Tracelinks: SyRS-9
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - im Zielsystem sollte zentrales Logging/Monitoring (z. B. Cloud-APM) diese Funktion übernehmen statt eines Client-eigenen Viewers.
Status: belegt
```
```
ID: StRS-9
Titel: Flexible Abrechnungs- und Eskalationskonditionen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung, Systemadministrator
Vorbedingung: Unterschiedliche Kunden/Verträge benötigen unterschiedliche Stundensätze, Konditionen und Eskalationsregeln
Fakt: Administration enthält HourlySurchargeRates (Stundenzuschläge), ReceiptConditions (Belegkonditionen) und EscalationsSettings (SLA-Eskalation) als eigenständige Konfigurationsbereiche.
Aussage: [HYPOTHESE] Das System soll Stundenzuschlagssätze, Belegkonditionen und SLA-Eskalationsregeln zentral konfigurierbar machen.
Ergebnis: Abrechnung und SLA-Überwachung erfolgen konsistent nach hinterlegten Regeln statt manueller Einzelfallentscheidung.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates - Begründung: Eigener Konfigurationsbereich für Zuschlagssätze.
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/EscalationsSettings - Begründung: Eigener Konfigurationsbereich für Eskalationsregeln.
Prüfidee: Eine Zeiterfassung außerhalb der Regelarbeitszeit wird automatisch mit dem hinterlegten Zuschlag bepreist.
Tracelinks: SyRS-10
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE - Abrechnungsrelevante Anforderung ohne PRIMÄR-Beleg (nur Konfigurationsoberflächen gesichtet, nicht die Verrechnungslogik selbst); konsistent mit der bereits als HYPOTHESE geführten SyRS-10.
```
```
ID: StRS-10
Titel: KI-unterstützte Texterstellung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb/Außendienst
Vorbedingung: Angebotstexte/Kommunikation sollen mit KI-Unterstützung effizienter erstellt werden
Fakt: Modul ArtificialIntelligence enthält Chat, OfferPositionsAIEditor und OpenAIConnect.
Aussage: Das System soll Mitarbeitern eine KI-gestützte Erstellung/Bewertung von Angebotstexten über eine Chat-Oberfläche ermöglichen.
Ergebnis: Schnellere Texterstellung bei gleichbleibender/besserer Qualität.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/ArtificialIntelligence/OfferPositionsAIEditor - Begründung: Dedizierter Editor für KI-generierte Angebotspositionstexte.
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/ArtificialIntelligence/OpenAIConnect - Begründung: Eigener Verbindungsbereich zu einem OpenAI-kompatiblen Dienst.
Prüfidee: Eine Angebotsposition wird über den KI-Editor mit einem Vorschlagstext befüllt und kann übernommen werden.
Tracelinks: SyRS-11
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - KI-Unterstützung ist ein Differenzierungsmerkmal, sollte fortgeführt werden.
Status: belegt
```
```
ID: StRS-11
Titel: Persönliche und geteilte Terminplanung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: alle Mitarbeiter
Vorbedingung: Termine müssen sowohl persönlich als auch abteilungsübergreifend geplant werden
Fakt: Es existieren zwei getrennte Kalenderbereiche: Modules/Calendar (allgemein) und Modules/MyCentron/Calendar (persönlich), mit eigenen Sichtbarkeitsrechten laut CentronRights.md (RIGHT_KALENDERANZEIGENALLE / RIGHT_KALENDERANZEIGENEIGENE).
Aussage: Das System soll Mitarbeitern eine Terminplanung mit einstellbarer Sichtbarkeit (alle Termine vs. nur eigene) bereitstellen.
Ergebnis: Mitarbeiter sehen abhängig von ihrem Recht entweder alle oder nur eigene Kalendereinträge.
Belege:
- [PRIMÄR] CentronRights.md, Abschnitt Kalender - Begründung: Beschreibt die einschränkende Wirkung von RIGHT_KALENDERANZEIGENEIGENE als durchgesetzte Regel.
Prüfidee: Mitarbeiter ohne RIGHT_KALENDERANZEIGENALLE sieht ausschließlich eigene Termine.
Tracelinks: SyRS-12
Konsolidierung: Kandidat: Modules/Calendar und Modules/MyCentron/Calendar bilden denselben fachlichen Gegenstand (Terminverwaltung) in getrennten Implementierungen und sollten im Zielsystem zu einem Kalenderkonzept zusammengeführt werden.
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-12
Titel: Zentrale Kennzahlen- und Aufgabenübersicht
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Filialleiter/Niederlassungsleiter, alle Mitarbeiter
Vorbedingung: Mitarbeiter benötigen beim Einstieg einen schnellen Überblick über offene Aufgaben/Kennzahlen
Fakt: Modules/Dashboard und Modules/MyCentron/Dashboard stellen Kachelübersichten bereit; Modules/Statistics/Dashboard liefert Kennzahlen.
Aussage: Das System soll dem Nutzer beim Einstieg eine personalisierte Übersicht über offene Aufgaben und relevante Kennzahlen anzeigen.
Ergebnis: Reduzierter Navigationsaufwand zu Tagesbeginn.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Dashboard/Modules - Begründung: Kachel-/Widget-Struktur belegt konfigurierbare Übersicht.
Prüfidee: Nach Anlage einer neuen Aufgabe erscheint diese im Dashboard des zuständigen Mitarbeiters.
Tracelinks: SyRS-13
Konsolidierung: Kandidat: Modules/Dashboard, Modules/MyCentron/Dashboard und Modules/Statistics/Dashboard bilden denselben fachlichen Gegenstand (Startübersicht) in getrennten Implementierungen.
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-13
Titel: Anbindung kundenspezifischer externer Werkzeuge
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Systemadministrator
Vorbedingung: Kunden nutzen mandantenspezifische externe Tools, die aus dem ERP heraus mit Kontextdaten aufgerufen werden sollen
Fakt: Modul ExternalTool/Variables verwaltet Variablen; der Ordner enthält ausschließlich eine Variablenverwaltung ohne erkennbare direkte Aufrufschnittstelle im gesichteten Code.
Aussage: [HYPOTHESE] Das System soll es erlauben, externe Werkzeuge mit dynamisch aus dem ERP-Kontext befüllten Variablen aufzurufen.
Ergebnis: Nahtloser Wechsel in externe Werkzeuge mit vorbefülltem Kontext.
Belege:
- [KONTEXT] centron/Centron.WPF.UI/Modules/ExternalTool/Variables - Begründung: Ordnername und Modulplatzierung legen eine Variablenverwaltung für externe Toolintegration nahe; der genaue Aufrufmechanismus wurde nicht gelesen und ist daher offen.
Prüfidee: Ein externes Tool wird mit einer Variable (z. B. Kundennummer) aus einem Beleg heraus gestartet.
Tracelinks: SyRS-14
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - vermutlich kundenspezifische Einzellösungen, im Zielsystem eher über generisches Plugin-/Webhook-Konzept abzubilden.
Status: HYPOTHESE
```
## StRS – DataExchange
```
ID: StRS-14
Titel: Automatisierter Datenaustausch mit externen Systemen
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Buchhaltung, Systemadministrator, externes System
Vorbedingung: Buchungsdaten, Dokumente oder Bestelldaten müssen mit externen Systemen (Steuerberater, DMS, Managed-Service-Plattformen) ausgetauscht werden
Fakt: DataExchange gliedert sich in eigenständige Backend-Bereiche BookKeeping, Connectors, DocuForm, EDI, GfkExport, Import, PaymentTransactions, Rmm, TanssInterfaces, TelekomDive, jeweils mit eigener BL-Klasse (z. B. BookKeepingExportBL, EdiExportBL, TelekomDiveBL).
Aussage: Das System soll strukturierte Export-/Import-Schnittstellen zu mehreren externen Zielsystemen (Finanzbuchhaltung, Dokumentenmanagement, EDI-Partner, Managed-Service-Plattformen) bereitstellen.
Ergebnis: Daten müssen nicht manuell zwischen Systemen übertragen werden.
Belege:
- [SEKUNDÄR] backend/Centron.BL/DataExchange/{BookKeeping,Connectors,DocuForm,EDI,GfkExport,Import,PaymentTransactions,Rmm,TanssInterfaces,TelekomDive} - Begründung: Zehn eigenständige BL-Unterordner belegen die bewusste Trennung nach Zielsystem.
Prüfidee: Für jede der zehn Kategorien existiert mindestens ein erfolgreicher Exporttestlauf mit Ergebnisdatei.
Tracelinks: SyRS-15, SyRS-16, SyRS-18, SyRS-19, SyRS-21
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-15
Titel: Rechtssicherer SEPA-Zahlungsverkehr
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Buchhaltung
Vorbedingung: Offene Rechnungen sollen per SEPA-Lastschrift eingezogen werden
Fakt: PaymentTransactionBL unterstützt fünf SEPA-PAIN-Formatvarianten (u. a. PAIN.008.001.02, GBIC3/GBIC4) und unterscheidet beim Bankkonto zwischen Erst- und Folgelastschrift (SepaDirectDebitType.First/Recurrent).
Aussage: Das System soll SEPA-Lastschriftdateien in den vom Zahlungsverkehr geforderten PAIN-Formatvarianten erzeugen und dabei zwischen Erst- und Folgeeinzug automatisch unterscheiden.
Ergebnis: Bankenseitig akzeptierte, formatkonforme SEPA-Dateien ohne manuelle Sequenztyp-Pflege.
Belege:
- [PRIMÄR] backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, Zeilen 350-351 (DirectDebitType-Umschaltung First→Recurrent nach erstem Einzug) - Begründung: Konkrete, im Code durchgesetzte Sequenztyp-Regel, die für die SEPA-Konformität zwingend ist.
Prüfidee: Erster Einzug eines Mandats erzeugt Sequenztyp FRST; jeder Folgeeinzug erzeugt RCUR.
Tracelinks: SyRS-17
Konsolidierung: Kandidat: SEPA-Mandatsverwaltung (Administration/SepaContract) und SEPA-Zahlungsdateierzeugung (DataExchange/PaymentTransactions) bilden denselben fachlichen Gegenstand (SEPA-Lastschriftprozess) in getrennten Modulen und sollten im Zielsystem zu einem SEPA-Prozess zusammengeführt werden.
Übernahmewürdigkeit: übernehmen - SEPA-Konformität ist zwingende regulatorische Anforderung.
Status: belegt
```
## StRS – Finances
```
ID: StRS-16
Titel: Automatisierte Vertrags- und Abrechnungsprozesse
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung, Mandant/Geschäftsführung
Vorbedingung: Kunden haben laufende Verträge (Wartung, Leasing, Flatrate) mit wiederkehrender Abrechnung
Fakt: ContractBL berechnet Kündigungsfristen über zwei gestaffelte Fristregeln (KuendigungsFristArt1/-Dauer1, KuendigungsFristArt2/-Dauer2); AutomaticFacturaBL erzeugt automatisiert Rechnungen aus offenen Aufträgen (interne Klasse FoundOrder); ReceiptContract-Belege mit CalculationKind.Auto werden automatisch bis zum Vertragsende/zur Kündigung fortgeschrieben (ContractBL, Zeilen 1259-1271).
Aussage: Das System soll wiederkehrende Vertragsabrechnungen automatisiert bis zum vertraglich/kündigungsbedingt festgelegten Enddatum durchführen, ohne dass die Buchhaltung jeden Abrechnungslauf manuell auslösen muss.
Ergebnis: Kunden werden fristgerecht und ohne manuellen Mehraufwand entsprechend ihres Vertrags abgerechnet; die Abrechnung endet automatisch zum korrekten Kündigungstermin.
Belege:
- [PRIMÄR] backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, Zeilen 1103-1132 (Kündigungsfristberechnung) und Zeilen 1259-1271 (automatische Fortschreibung bis ContractTermination) - Begründung: Konkrete, im Code durchgesetzte Fristlogik und Abbruchbedingung für automatische Vertragsabrechnung.
- [KONTEXT] docs/reference/receipts/contracts-backend.md, docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md - Begründung: Referenzdokumentation zur Vertragsabrechnungslogik als Kontext.
Prüfidee: Ein Vertrag mit Kündigung zum 31.03. wird letztmalig bis einschließlich März automatisch abgerechnet und danach nicht mehr.
Tracelinks: SyRS-22, SyRS-25, SyRS-28
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess des Geschäftsmodells (wiederkehrende Vertragsabrechnung).
Status: belegt
```
```
ID: StRS-17
Titel: Kundenbeziehungsmanagement und Kampagnensteuerung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb/Außendienst
Vorbedingung: Vertrieb benötigt eine konsolidierte Sicht auf Kundenkontakte und Marketingkampagnen
Fakt: Finances/Crm enthält umfangreiche Unterstruktur (AccountContracts, AccountMigrations, Actions u. a.); Finances/Campaigns verwaltet Kampagnen mit Kundenzuordnung; Accounts/Campaigns existiert zusätzlich im Backend.
Aussage: Das System soll Kundenkontakthistorie, -aktivitäten und Marketingkampagnen in einer gemeinsamen CRM-Sicht verwalten.
Ergebnis: Vertrieb kann Kampagnenerfolg je Kunde nachvollziehen, ohne Daten aus mehreren Quellen zusammenzuführen.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Finances/{Crm,Campaigns}; backend/Centron.BL/Accounts/Campaigns - Begründung: Struktur belegt CRM- und Kampagnenverwaltung als eigenständige, aber verknüpfte Bereiche.
Prüfidee: Eine Kampagne wird einem Kunden zugeordnet und erscheint in dessen CRM-Aktivitätenhistorie.
Tracelinks: SyRS-26, SyRS-27
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-18
Titel: Mahnwesen und Forderungsmanagement
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung
Vorbedingung: Rechnungen sind über das Zahlungsziel hinaus offen
Fakt: DunningBL/DunningRunBL führen ein vierstufiges Mahnsystem (None/Level1/Level2/Level3) mit automatischer Eskalation je Mahnlauf; OposBL/OposRunBL verwalten parallel die offenen Posten.
Aussage: Das System soll überfällige Rechnungen automatisiert stufenweise mahnen und den Status offener Forderungen laufend nachführen.
Ergebnis: Konsistente, nachvollziehbare Mahnstufen je Rechnung ohne manuelle Einzelprüfung.
Belege:
- [PRIMÄR] backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Zeilen 255-266 (Eskalation None→Level1→Level2→Level3) - Begründung: Konkrete, im Code durchgesetzte Zustandsmaschine des Mahnwesens.
Prüfidee: Eine unbezahlte Rechnung durchläuft bei drei aufeinanderfolgenden Mahnläufen alle drei Mahnstufen in der korrekten Reihenfolge.
Tracelinks: SyRS-29, SyRS-30, SyRS-31
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Mahnwesen ist zwingender Bestandteil des Forderungsmanagements.
Status: belegt
```
```
ID: StRS-19
Titel: Erfassung und Zuordnung von Zahlungen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung
Vorbedingung: Eine Zahlung (Überweisung, Lastschrifteinzug, Zählerabrechnung) muss einer Forderung zugeordnet werden
Fakt: Payments-Modul trennt IncomingPayments/OutgoingPayments; DeviceClickCounter erfasst Zählerstände als Abrechnungsgrundlage separat.
Aussage: [HYPOTHESE] Das System soll eingehende und ausgehende Zahlungen getrennt erfassen und Zählerstände als eigenständige Abrechnungsgrundlage für nutzungsbasierte Verträge (z. B. Klickabrechnung Drucker) verwalten.
Ergebnis: Zahlungen sind korrekt Forderungen zugeordnet; nutzungsbasierte Abrechnung basiert auf nachvollziehbaren Zählerständen.
Belege:
- [SEKUNDÄR] backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentBL.cs; centron/.../Finances/Payments/{IncomingPayments,OutgoingPayments}; centron/.../Finances/DeviceClickCounter/CounterHistoryViewModel.cs - Begründung: Getrennte Klassen/Ordner belegen die fachliche Trennung von Zahlungsrichtung und Zählererfassung.
Prüfidee: Eine erfasste Zahlung reduziert den offenen Betrag der zugeordneten Rechnung um den Zahlbetrag.
Tracelinks: SyRS-32, SyRS-33
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE - Abrechnungs-/Zahlungsrelevante Anforderung ohne PRIMÄR-Beleg; die konkrete Verrechnungslogik (Zuordnung Zahlung↔Forderung, Ableitung des Rechnungsbetrags aus Zählerständen) wurde nicht im Code gesichtet, nur die strukturelle Trennung der Ordner/Klassen.
```
```
ID: StRS-20
Titel: Durchgängige Belegverwaltung vom Angebot bis zur Lieferantenrechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Sachbearbeiter/Innendienst, Vertrieb/Außendienst, Buchhaltung
Vorbedingung: Ein Geschäftsvorfall durchläuft mehrere Belegarten (Angebot → Auftrag → Lieferschein → Rechnung; Bestellung → Wareneingang → Lieferantenrechnung)
Fakt: Elf Belegarten (Offers, Orders, DeliveryLists, PickupLists, Invoices, CreditVouchers, SupplierOrders, SupplierInvoices, SupplierCreditVouchers, SupplierDeliveryLists, ContractLists) implementieren ein gemeinsames Interface IReceiptSpecificLogic mit einheitlichem Rechte-, Status- (ReceiptState: Active/Completed/Canceled) und Weiterleitungsmodell.
Aussage: Das System soll alle Belegarten über ein gemeinsames, konsistentes Beleg-Interface mit einheitlicher Status- und Rechteführung abbilden, damit Folgebelege (z. B. Rechnung aus Lieferschein) konsistent erzeugt werden können.
Ergebnis: Jede Belegart verhält sich bezüglich Status, Rechteprüfung und Belegfluss konsistent zu den übrigen.
Belege:
- [PRIMÄR] backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs - Begründung: Gemeinsames Interface, das von allen elf Belegart-Klassen implementiert wird und damit die konsistente Struktur technisch erzwingt.
- [SEKUNDÄR] backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs - Begründung: Einheitliches Statusmodell (offen/abgeschlossen/storniert) für alle Belegarten.
Prüfidee: Aus einem abgeschlossenen Lieferschein wird eine Rechnung erzeugt, die die Positionen des Lieferscheins korrekt übernimmt.
Tracelinks: SyRS-34, SyRS-35, SyRS-36, SyRS-37, SyRS-38
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess des ERP-Systems.
Status: belegt
```
## StRS – Global/Gui/Helpdesk
```
ID: StRS-21
Titel: Wiederverwendbare UI-Bausteine und Anwendungsrahmen
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: alle Mitarbeiter
Vorbedingung: Alle Module benötigen gleichartige Grundfunktionen (Drucken, Hilfe, individuelle Felder)
Fakt: Global-Modul bündelt modulübergreifend genutzte Bausteine (Actions/PrintPdfAction, CustomProperties, Help, VideoPortal, NetworkDiagnostics); Gui/Profiles verwaltet UI-Layoutprofile je Benutzer.
Aussage: Das System soll modulübergreifend wiederverwendbare UI-Bausteine (Drucken, Hilfe, individuelle Felder, Layoutprofile) zentral bereitstellen, statt sie je Fachmodul neu zu implementieren.
Ergebnis: Einheitliches Bedienverhalten über alle Fachmodule hinweg.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Global/Actions/{PrintPdfAction.cs,SavePdfAs.cs} - Begründung: Generische, modulübergreifend nutzbare Aktionen belegen den Rahmencharakter.
Prüfidee: PrintPdfAction wird aus zwei unterschiedlichen Fachmodulen heraus mit identischem Ergebnis aufgerufen.
Tracelinks: SyRS-41, SyRS-42, SyRS-43, SyRS-44
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-22
Titel: Ganzheitliche Ticketbearbeitung mit konfigurierbarem Status und SLA-Steuerung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Helpdesk-Mitarbeiter
Vorbedingung: Ein Kundenanliegen wird als Ticket erfasst und bis zum Abschluss bearbeitet
Fakt: TicketLogicHelper verwendet konfigurierbare Status-IDs (HelpdeskStatusI3D) statt fixer Enum-Werte, inkl. eines konfigurierbaren Folgestatus nach Vererbung (HelpdeskAfterInheritDefaultState); TicketDetails enthält u. a. CFlow-Prozessvorlagen, ContractSelection (Vertragsbezug) und CloseHelpdesk als eigene Funktionsbereiche; Events wie TicketLockChangedEvent sichern gleichzeitige Bearbeitung ab.
Aussage: Das System soll Tickets mit frei konfigurierbaren Statuswerten, Vertragsbezug, Prozessvorlagen (C-FLOW) und Bearbeitersperren durchgängig bis zum Abschluss steuern.
Ergebnis: Tickets sind konsistent Vertrag/Kunde zugeordnet, Statuswerte sind an fachliche Prozesse anpassbar, gleichzeitige Bearbeitung wird verhindert.
Belege:
- [PRIMÄR] centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs, Zeilen 371-374, 444-461 - Begründung: Konkrete, im Code durchgesetzte Statuslogik mit konfigurierbarem Folgestatus.
- [KONTEXT] CentronRights.md, Abschnitt Helpdesk - Begründung: Dokumentiert die rechteseitige Steuerung von Statusänderungen (z. B. CLOSE_REQUEST, MATURITY_CHANGE) als fachlichen Kontext.
Prüfidee: Ein Ticket wechselt nach Vererbung eines Folgetickets automatisch in den konfigurierten Folgestatus statt in einen fest codierten Status.
Tracelinks: SyRS-45, SyRS-46, SyRS-47
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
## StRS – Logistik, MyCentron, OnlineBanking, PLM, Passwortverwaltung, Zahler/Kostenstellen, Produktion, Projekte
```
ID: StRS-23
Titel: Verschlüsselte Verwaltung sensibler Zugangsdaten
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Systemadministrator, Sachbearbeiter/Innendienst
Vorbedingung: Mitarbeiter benötigen Zugriff auf Kunden-/Systemzugangsdaten (Passwörter), ohne dass diese im Klartext einsehbar sind
Fakt: PasswordManagerBL verschlüsselt Passwortwerte mit AESCryptoLogic().EncryptText unter Verwendung eines MasterKey und entschlüsselt sie nur bei berechtigtem Zugriff wieder (DecryptText); AccessAreaManagement/AccessManagement bilden getrennte Zugriffsbereiche.
Aussage: Das System soll Zugangsdaten ausschließlich AES-verschlüsselt mit zentralem Master-Key speichern und den Zugriff über eigene Zugriffsbereiche (Access Areas) statt der allgemeinen Modulrechte steuern.
Ergebnis: Zugangsdaten sind bei Datenbankzugriff ohne Master-Key nicht im Klartext lesbar.
Belege:
- [PRIMÄR] backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Zeile 700 (EncryptText mit AESCryptoLogic/masterKeyResult) und Zeilen 1051-1052 (DecryptText) - Begründung: Konkrete, im Code durchgesetzte AES-Verschlüsselung von Passwortwerten.
Prüfidee: Ein direkter Blick in die Datenbanktabelle zeigt für ein gespeichertes Passwort ausschließlich Chiffretext, keinen Klartext.
Tracelinks: SyRS-52, SyRS-53
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Verschlüsselte Speicherung ist sicherheitskritisch korrekt und zwingend fortzuführen.
Status: belegt
```
```
ID: StRS-24
Titel: Persönliche Tagesorganisation und Fernwartung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: alle Mitarbeiter
Vorbedingung: Mitarbeiter benötigen eine tagesbezogene Aufgaben-/Terminübersicht und gelegentlich Fernzugriff auf Kundenrechner
Fakt: MyCentron bündelt MyDay, TodoList, PersonalSettings, CentronInspectors und Supremo (Fernwartungssoftware) als persönliche Werkzeuge, getrennt von den fachmodulweiten Pendants.
Aussage: Das System soll Mitarbeitern eine persönliche Tagesübersicht mit Aufgabenliste sowie eine integrierte Fernwartungsanbindung (Supremo) bereitstellen.
Ergebnis: Mitarbeiter planen ihren Tag und starten Fernwartungssitzungen ohne Systemwechsel.
Belege:
- [SEKUNDÄR] centron/Centron.WPF.UI/Modules/MyCentron/{MyDay,TodoList,Supremo} - Begründung: Eigenständige Module belegen die persönliche Werkzeugsammlung.
Prüfidee: Start einer Fernwartungssitzung aus einem Ticket öffnet Supremo mit korrekt vorbefülltem Zielrechner.
Tracelinks: SyRS-54
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-25
Titel: Automatisierter Kontoumsatzabruf über Online-Banking-Schnittstelle
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Buchhaltung
Vorbedingung: Zahlungseingänge sollen ohne manuellen Kontoauszugsimport abgeglichen werden
Fakt: OnlineBankingFinApiBL bindet den externen Dienst FinAPI an; OnlineBankingAccountTransactionsBL verarbeitet die abgerufenen Kontobewegungen weiter.
Aussage: Das System soll Kontoumsätze automatisiert über die FinAPI-Schnittstelle abrufen und für den Zahlungsabgleich bereitstellen.
Ergebnis: Zahlungseingänge sind zeitnah ohne manuellen Kontoauszugsimport im System sichtbar.
Belege:
- [PRIMÄR] backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs - Begründung: Konkrete Klasse zur Anbindung des externen FinAPI-Dienstes.
Prüfidee: Ein über FinAPI abgerufener Kontoumsatz erscheint in der Liste der Kontobewegungen mit korrektem Betrag und Verwendungszweck.
Tracelinks: SyRS-55
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
## StRS – Einkauf, QM, Reports, RMA, Sales, Statistik, Survey
```
ID: StRS-26
Titel: Automatisierte Bestellvorschläge auf Basis von Mindestbeständen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Lager/Logistik
Vorbedingung: Der Lagerbestand eines Artikels unterschreitet den definierten Mindestbestand
Fakt: OrderSuggestionListBL vergleicht je Artikel und Lager (inkl. Nebenläger) den aktuellen Bestand (cvw_ArticleCount.cnt) gegen den hinterlegten Mindestbestand zuzüglich offener Bestellungen/Konsignationsware und erzeugt daraus Bestellvorschläge.
Aussage: Das System soll automatisiert Bestellvorschläge erzeugen, sobald der verfügbare Bestand eines Artikels je Lager unter den definierten Mindestbestand fällt.
Ergebnis: Lager/Logistik muss Nachbestellungen nicht manuell anhand von Bestandslisten ermitteln.
Belege:
- [PRIMÄR] backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs, Zeilen 139-158 - Begründung: Konkrete, im Code durchgesetzte SQL-Vergleichslogik Bestand vs. Mindestbestand je Lager.
Prüfidee: Ein Artikel mit Bestand knapp über dem Mindestbestand erscheint nicht im Bestellvorschlag; sinkt der Bestand durch einen Verkauf darunter, erscheint er im nächsten Lauf.
Tracelinks: SyRS-63, SyRS-64
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernfunktion der Beschaffungslogistik.
Status: belegt
```
## StRS – Warehousing
```
ID: StRS-27
Titel: Einheitliche Artikel- und Gerätestammdaten für Lager und Vertrieb
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Lager/Logistik, Sachbearbeiter/Innendienst
Vorbedingung: Ein Artikel/Gerät wird sowohl im Lager geführt als auch fachlich (Vertrag, Monitoring) referenziert
Fakt: Physische Geräte werden in mindestens zwei getrennten Datenhaltungen geführt: (1) Drucker/Klickabrechnungsgeräte als „Stammblatt" über MasterDataListBL innerhalb Sales/CustomerAssets/Contracts/ClickContracts, referenziert aus Finances/MasterDataLists; (2) RMM-überwachte Geräte (Server/Workstations) als „Asset" über die Entität AssetManagementArticleAssignment (Namespace Centron.Data.Entities.DocuBoard), referenziert aus Warehousing/ArticleManagement/RMMArticle.
Aussage: Das System soll physische Geräte (Drucker, Server, Workstations) unabhängig vom jeweiligen fachlichen Anlass (Klickabrechnung vs. RMM-Überwachung) als eine gemeinsame Gerätestammdaten-Entität führen.
Ergebnis: Ein Gerät ist unabhängig davon, ob es klickabgerechnet oder RMM-überwacht wird, eindeutig identifizierbar und muss nicht in zwei Systemen parallel gepflegt werden.
Belege:
- [PRIMÄR] backend/Centron.Entities/Entities/DocuBoard/AssetManagementArticleAssignment.cs, Zeilen 8-16 - Begründung: Eigenständige Entität zur Verknüpfung eines RMM-überwachten Geräts mit einem Artikel, getrennt vom Stammblatt-Modell.
- [PRIMÄR] backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs - Begründung: Eigenständige Geschäftslogik für Stammblätter (Klickabrechnungsgeräte wie Drucker), getrennt von der AssetManagement-Entität.
Prüfidee: Ein Drucker, der sowohl klickabgerechnet als auch RMM-überwacht wird, existiert aktuell als zwei unabhängige Datensätze (Stammblatt und AssetManagementArticleAssignment) ohne erzwungene gegenseitige Referenz.
Tracelinks: SyRS-73
Konsolidierung: Kandidat: Stammblatt (Finances/MasterDataLists, ClickContracts) und AssetManagement (DocuBoard/RMMArticle) bilden denselben fachlichen Gegenstand (physisches, zu überwachendes/abzurechnendes Gerät) in getrennten Datenhaltungen und sollten im Zielsystem zu einem einheitlichen Asset-Konzept zusammengeführt werden.
Übernahmewürdigkeit: Workaround - historisch getrennt für unterschiedliche fachliche Ursprünge (Abrechnung vs. Monitoring) entstanden; im Zielsystem als ein Gerätestamm mit mehreren fachlichen Rollen (abrechnungsrelevant, überwachungsrelevant) zu modellieren.
Status: belegt
```
## StRS – Architektur (Backend, Web-API, Nexus, Shared, externe Integrationen, Betrieb)
```
ID: StRS-28
Titel: Deklarative, wiederverwendbare API-Autorisierung
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Systemadministrator, externes System
Vorbedingung: Ein Webservice-/REST-Endpunkt wird von einem externen Client (mobil, Portal, Integration) aufgerufen
Fakt: Centron.Controllers/Authorization stellt vier Autorisierungs-Attribute bereit (AuthorizeUserRight, AuthorizeAnyUserRight, AuthorizeAllUserRights, AuthorizeCentronHosted), die intern dieselbe HasUserRight()-Prüfung wie der Desktop-Client nutzen und laut mitgeliefertem README.md als Migrationsziel manueller Rechteprüfungen im Controller dienen.
Aussage: Das System soll REST-API-Endpunkte deklarativ über wiederverwendbare Autorisierungs-Attribute absichern, die auf demselben Rechtekatalog wie der Desktop-Client basieren, statt Rechteprüfungen manuell in jeder Methode zu wiederholen.
Ergebnis: Jeder abgesicherte Endpunkt liefert bei fehlendem Recht konsistent HTTP 401/403, ohne dass Entwickler die Prüfung erneut implementieren.
Belege:
- [PRIMÄR] webservice/Centron.Controllers/Authorization/{AuthorizeUserRightAttribute.cs,AuthorizeAllUserRightsAttribute.cs,AuthorizeAnyUserRightAttribute.cs,AuthorizeCentronHostedAttribute.cs} - Begründung: Vier konkrete, im Code vorhandene Attributklassen, die die Autorisierungspipeline vor jeder Aktionsmethode durchsetzen.
- [KONTEXT] webservice/Centron.Controllers/Authorization/README.md - Begründung: Dokumentiert Verhalten, HTTP-Statuscodes und Migrationsabsicht als fachlichen Kontext.
Prüfidee: Ein Aufruf von GET /v1/admin/settings ohne SETTINGS-Recht liefert HTTP 403, ein Aufruf ohne gültige Anmeldung liefert HTTP 401.
Tracelinks: SyRS-81, SyRS-82
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Deklarative API-Autorisierung ist die für eine SaaS-Neuimplementierung geeignete Grundlage.
Status: belegt
```
```
ID: StRS-29
Titel: Web-Self-Service für Kunden über c-entron Nexus
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Kunde (Web-Self-Service/WebCart)
Vorbedingung: Ein Kunde mit Web-Account soll ohne Mitarbeiterkontakt Dokumente einsehen, unterschreiben und Tickets einsehen können
Fakt: CentronNexus (Blazor-Webanwendung, README.md: „aka c-entron Web") bietet WebCart/CustomerPortal-Seiten (Formulare ausfüllen, öffentliche Dokumente, Ticketdetails) sowie eine eigene DocumentSigning-Seite mit IsolatedSignaturePad für elektronische Unterschriften.
Aussage: Das System soll Kunden über ein Webportal (c-entron Nexus) Selbstbedienungsfunktionen wie Formularausfüllung, Dokumenteneinsicht, Ticketstatus und elektronische Unterschrift ohne Mitarbeiterkontakt bereitstellen.
Ergebnis: Reduzierter manueller Aufwand für Standardvorgänge, die der Kunde selbst erledigen kann.
Belege:
- [PRIMÄR] nexus/CentronNexus/DocumentSigning/IsolatedSignaturePad.razor; nexus/CentronNexus/WebCart/CustomerPortal/{CustomerPortalFormFillPage.razor,CustomerTicketDetailsPage.razor} - Begründung: Konkrete, im Code vorhandene Seiten für die genannten Selbstbedienungsfunktionen.
Prüfidee: Ein Kunde unterschreibt ein Dokument über das IsolatedSignaturePad; die Signatur ist im erzeugten Dokument nachweisbar enthalten.
Tracelinks: SyRS-83, SyRS-84
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Nexus ist bereits der begonnene Web-/SaaS-Migrationspfad und damit strategisch zentral.
Status: belegt
```
```
ID: StRS-30
Titel: Absicherung gegen versehentliche Testkommunikation mit echten Kunden
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Systemadministrator
Vorbedingung: Entwickler/Tester arbeiten mit einer Kopie der Produktivdatenbank in einer Nicht-Produktionsumgebung
Fakt: DeveloperSecurity.Email.ValidateAddress ersetzt in Nicht-Release-Builds jede E-Mail-Adresse außerhalb der Domain "nexoware.com" automatisch durch eine feste Testadresse.
Aussage: Das System soll in Test-/Entwicklungsumgebungen automatisch verhindern, dass E-Mails an echte, aus Produktivdaten stammende Kundenadressen versendet werden.
Ergebnis: Kein Testlauf mit Produktivdatenkopie erreicht versehentlich einen echten Kunden per E-Mail.
Belege:
- [PRIMÄR] backend/Centron.Common/DeveloperSecurity.cs, Zeilen 30-46 (ValidateAddress) - Begründung: Konkrete, im Code durchgesetzte Ersetzungslogik, aktiv abhängig vom Build-Typ.
Prüfidee: In einem Debug-Build wird eine E-Mail an eine externe Testadresse automatisch auf test@nexoware.com umgeleitet; eine interne nexoware.com-Adresse bleibt unverändert.
Tracelinks: SyRS-85
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Wichtige Schutzmaßnahme, die im Zielsystem (mit noch mehr Cloud-/Testumgebungen) fortzuführen ist.
Status: belegt
```
## StRS – Restliche Architektur, Nexus, Externe APIs, Betrieb
```
ID: StRS-31
Titel: Web-basiertes Service-Board als Spiegel der Desktop-Ticketbearbeitung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Helpdesk-Mitarbeiter
Vorbedingung: Ein Helpdesk-Mitarbeiter möchte Tickets browserbasiert statt über den Desktop-Client bearbeiten
Fakt: CentronNexus/ServiceBoard bildet mit CachedTicketList, CloseTicket, ForwardTicket, EmployeeTimerStatistics und DocumentViewer weitgehend dieselben Funktionen ab wie das Desktop-Modul Helpdesk/TicketDetails (CloseHelpdesk, Forward-Events, Zeiterfassung); CentronNexus/Management enthält zusätzlich TaskManagement und TicketPatterns als Web-Pendants der Desktop-Module TaskManagement und C-FLOW-Ticketvorlagen.
Aussage: Das System soll die zentralen Helpdesk-Funktionen (Ticketliste, Schließen, Weiterleiten, Zeitstatistik, Dokumentenanzeige) sowohl im Desktop-Client als auch im Webportal Nexus bereitstellen.
Ergebnis: Helpdesk-Mitarbeiter können wahlweise über Desktop oder Browser arbeiten.
Belege:
- [PRIMÄR] nexus/CentronNexus/ServiceBoard/{CachedTicketList,CloseTicket,ForwardTicket,EmployeeTimerStatistics,DocumentViewer} - Begründung: Fünf konkrete, im Code vorhandene Bereiche mit klar erkennbarem Bezug zu den entsprechenden Desktop-Funktionen.
Prüfidee: Ein im Nexus-ServiceBoard geschlossenes Ticket zeigt im Desktop-Client denselben Status und dieselbe Historie.
Tracelinks: SyRS-89
Konsolidierung: Kandidat: Helpdesk/TicketDetails (Desktop) und CentronNexus/ServiceBoard (Web) bilden denselben fachlichen Gegenstand (Ticketbearbeitung) in zwei parallelen Implementierungen auf unterschiedlichen Technologiestacks (WPF/Blazor) und sind der zentrale Beleg dafür, dass die geplante Web-/SaaS-Neuimplementierung große Teile der Fachlogik bereits ein zweites Mal in Nexus abbildet.
Übernahmewürdigkeit: übernehmen - Nexus/ServiceBoard ist der naheliegende Ausgangspunkt für die Zielarchitektur, sofern die Desktop-Fachlogik dorthin migriert statt neu erfunden wird.
Status: belegt
```
```
ID: StRS-32
Titel: Anreicherung von Produkt- und Bonitätsdaten über externe Datenquellen
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Sachbearbeiter/Innendienst, Vertrieb/Außendienst
Vorbedingung: Artikelstammdaten oder Kundenbonität sollen ohne manuelle Recherche angereichert werden
Fakt: Neun eigenständige API-Projekte binden externe Datenquellen an: ITscope und Icecat (Produktdaten-Anreicherung, jeweils mit eigenem Interface IITscopeApi/IIcecatApi), COP und EGIS (Distributoren-/Bonitätsdaten, mit mitgelieferter Herstellerdokumentation), FinAPI (Bankdaten, mit Interface IFinApiClient), EbInterface (österreichische E-Rechnung), Gls und Shipcloud (Versanddienstleister), docuFORM (Dokumentenerzeugung).
Aussage: Das System soll Artikelstamm-, Bonitäts- und Versanddaten automatisiert über dedizierte, interface-basierte Client-Bibliotheken aus externen Quellen anreichern, statt manuelle Recherche durch Mitarbeiter zu erfordern.
Ergebnis: Aktuelle, korrekte Produkt-/Bonitäts-/Versanddaten ohne manuellen Rechercheaufwand.
Belege:
- [PRIMÄR] apis/Centron.APIs.ITscopeDataAccess/IITscopeApi.cs; apis/Centron.APIs.IcecatDataAccess/IIcecatApi.cs; apis/Centron.APIs.FinAPI/IFinApiClient.cs - Begründung: Drei konkrete, interface-basierte Client-Abstraktionen als durchgesetztes Architekturmuster für externe Datenquellen.
Prüfidee: Ein Artikel ohne technische Beschreibung wird über die ITscope- oder Icecat-Anbindung automatisch mit Herstellerdaten angereichert.
Tracelinks: SyRS-90, SyRS-91
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
## StRS – Restliche Kernarchitektur, Zwei-Faktor-Authentifizierung, Betrieb
```
ID: StRS-33
Titel: Optionale Zwei-Faktor-Authentifizierung für Benutzeranmeldung
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Systemadministrator, alle Mitarbeiter
Vorbedingung: Ein Mitarbeiterkonto soll zusätzlich zum Passwort durch einen zweiten Faktor abgesichert werden
Fakt: Eine vollständige TOTP-Implementierung (GoogleAuthenticator/TwoFactorAuthenticator.cs, Base32.cs) ist in Centron.Core vorhanden und wird über mehrere Schichten hinweg konkret verdrahtet: WebServices.Core (UpdateAppUserTwoFactorAuthKeyRequest), Centron.Host (CentronRestService.TwoFactorAuthentication.cs), Centron.WPF.UI (BLTwoFactorAuthenticationLogic/WSTwoFactorAuthenticationLogic) und ein eigener Einrichtungsassistent (Centron.Controls/EmployeeManagement/TwoFactorAuthentication/WizardPages/GoogleAuthenticatorViewModel.cs).
Aussage: Das System soll Benutzern die Absicherung ihres Kontos durch eine TOTP-basierte Zwei-Faktor-Authentifizierung (kompatibel zu Google Authenticator) über einen geführten Einrichtungsassistenten ermöglichen.
Ergebnis: Konten mit aktivierter Zwei-Faktor-Authentifizierung sind gegen alleinigen Passwortdiebstahl zusätzlich abgesichert.
Belege:
- [PRIMÄR] shared/Centron.Core/GoogleAuthenticator/TwoFactorAuthenticator.cs; webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.TwoFactorAuthentication.cs - Begründung: Durchgängig, über Client, Webservice und Kernbibliothek hinweg konkret implementierte TOTP-Prüfung, keine bloße Vorbereitung.
Prüfidee: Eine Anmeldung mit korrektem Passwort, aber falschem/fehlendem TOTP-Code bei aktivierter Zwei-Faktor-Authentifizierung wird abgelehnt.
Tracelinks: SyRS-94
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Zwei-Faktor-Authentifizierung ist eine wichtige, bereits vorhandene Sicherheitsfunktion, die im Zielsystem mindestens erhalten, idealerweise verpflichtend für privilegierte Rollen gemacht werden sollte.
Status: belegt
```
```
ID: StRS-34
Titel: Containerisierte Bereitstellung für Demo- und Testumgebungen
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Übertragbarkeit
Akteur: Systemadministrator
Vorbedingung: Eine Testumgebung (Demo, Regressionstest) soll reproduzierbar bereitgestellt werden
Fakt: docker/compose enthält ein compose.yaml mit produktionsnaher appsettings.Production.json und WebServiceConfig.xml; weitere Docker-Verzeichnisse (c-entron-demo, c-entron-regression-tests-db, c-entron-regression-tests-pipeline) belegen mehrere containerisierte Umgebungstypen.
Aussage: Das System soll über Docker-Compose-Definitionen reproduzierbar als Demo- und Regressionstestumgebung bereitstellbar sein.
Ergebnis: Neue Umgebungen sind ohne manuelle Servereinrichtung in kurzer Zeit verfügbar.
Belege:
- [SEKUNDÄR] docker/compose/compose.yaml; docker/c-entron-demo; docker/c-entron-regression-tests-db - Begründung: Konkrete, im Repository vorhandene Containerdefinitionen für unterschiedliche Umgebungszwecke.
Prüfidee: Ein `docker compose up` aus docker/compose stellt eine lauffähige Demoumgebung ohne weitere manuelle Konfiguration bereit.
Tracelinks: SyRS-95
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Containerisierung ist eine direkt nutzbare Grundlage für die geplante SaaS-Neuimplementierung.
Status: belegt
```
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/SwRS.md
+1621
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/SyRS.md
+2055
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/Traceability.md
+88
View File
@@ -0,0 +1,88 @@
# Traceability – c-entron ERP-Suite
Konsolidierte Forward-/Backward-Traceability zwischen StRS, SyRS und SwRS. Jede Zeile entspricht einer SwRS-Anforderung mit ihrem primären Pfad nach oben (erste referenzierte SyRS-ID, deren erste referenzierte StRS-ID) sowie dem ersten Artefaktbeleg dieser SwRS-Anforderung. Anforderungen mit mehreren Tracelinks (z. B. `SyRS-1, SyRS-2`) sind zusätzlich in den Feldern `Tracelinks` der jeweiligen StRS.md/SyRS.md/SwRS.md-Dateien vollständig aufgeführt; diese Tabelle bildet zur Übersichtlichkeit den primären (ersten) Pfad je SwRS-Anforderung ab.
Insgesamt: 34 StRS-Anforderungen, 101 SyRS-Anforderungen, 80 SwRS-Anforderungen (215 Anforderungen gesamt).
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (erster Beleg der SwRS-Zeile) |
|---|---|---|---|
| StRS-1 | SyRS-1 | SwRS-1 | backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Zeilen 388-393 (SaveRightGroup) |
| StRS-2 | SyRS-3 | SwRS-2 | centron/Centron.WPF.UI/Modules/Administration/DSGVO/{CentronDataSecurityViewModel.cs,CentronDataSecurityCustomerViewModel.cs,OrderProcessingContractSettingsViewModel.cs,OrderProcessingContractTemplateViewModel.cs} |
| StRS-5 | SyRS-6 | SwRS-3 | centron/Centron.WPF.UI/Modules/Administration/SepaContract/{SepaContractSettingsViewModel.cs,SepaContractTemplateViewModel.cs} |
| StRS-3 | SyRS-4 | SwRS-4 | centron/Centron.WPF.UI/Modules/Administration/MandatorManagement/MandatorManagementViewModel.cs, Zeile 434 (GetBranchDetailsList mit BranchFilter{MandantI3D=...}) |
| StRS-4 | SyRS-5 | SwRS-5 | centron/Centron.WPF.UI/Modules/Administration/EmployeeManagement/AdImport |
| StRS-4 | SyRS-5 | SwRS-6 | centron/Centron.WPF.UI/Modules/Administration/CountryManagement |
| StRS-5 | SyRS-6 | SwRS-7 | backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, Zeilen 424-436 (GetReplacedTextForForwarding) |
| StRS-6 | SyRS-7 | SwRS-8 | centron/Centron.WPF.UI/Modules/Administration/{PdfExport,PdfSigning,ReportServer,TextBlockManagement} |
| StRS-7 | SyRS-8 | SwRS-9 | centron/Centron.WPF.UI/Modules/Administration/SqlManagers |
| StRS-8 | SyRS-9 | SwRS-10 | centron/Centron.WPF.UI/nlog.config |
| StRS-9 | SyRS-10 | SwRS-11 | centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates |
| StRS-10 | SyRS-11 | SwRS-12 | centron/Centron.WPF.UI/Modules/ArtificialIntelligence/{Chat,OfferPositionsAIEditor} |
| StRS-11 | SyRS-12 | SwRS-13 | centron/Centron.WPF.UI/Modules/{Calendar,MyCentron/Calendar} |
| StRS-12 | SyRS-13 | SwRS-14 | centron/Centron.WPF.UI/Modules/Dashboard/Modules; vgl. Modules/ModuleRegistration.cs |
| StRS-13 | SyRS-14 | SwRS-15 | centron/Centron.WPF.UI/Modules/ExternalTool/Variables |
| StRS-14 | SyRS-15 | SwRS-16 | backend/Centron.BL/DataExchange/BookKeeping/{BookKeepingExportBL.cs,BookKeepingImportBL.cs} |
| StRS-14 | SyRS-16 | SwRS-17 | centron/Centron.WPF.UI/Modules/DataExchange/Connectors/Settings |
| StRS-15 | SyRS-17 | SwRS-18 | backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, Zeilen 350-351 |
| StRS-14 | SyRS-18 | SwRS-19 | centron/Centron.WPF.UI/Modules/DataExchange/DocuForm/Authorization |
| StRS-14 | SyRS-19 | SwRS-20 | backend/Centron.BL/DataExchange/EDI/{ZugferdExportItem.cs,ZugferdExportPositionItem.cs} |
| StRS-14 | SyRS-20 | SwRS-21 | backend/Centron.BL/DataExchange/Rmm/RmmConnectionSettingsBL.cs |
| StRS-14 | SyRS-21 | SwRS-22 | backend/Centron.BL/DataExchange/TelekomDive/TelekomDiveBL.cs |
| StRS-16 | SyRS-23 | SwRS-23 | centron/Centron.WPF.UI/Modules/Finances/AccountManagement/BranchBookKeepingNumbers |
| StRS-16 | SyRS-24 | SwRS-24 | backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs, Zeile 495 |
| StRS-16 | SyRS-28 | SwRS-25 | centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/AssetPositions |
| StRS-18 | SyRS-29 | SwRS-26 | backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Zeilen 207-210 (Filterung nach invoice.DunningLevel) |
| StRS-18 | SyRS-29 | SwRS-27 | backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Zeilen 296-297 |
| StRS-18 | (direkt) | SwRS-28 | backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Zeilen 220-230 |
| StRS-20 | SyRS-35 | SwRS-29 | backend/Centron.BL/Sales/Receipts/SupplierInvoices/SupplierInvoiceSpecificLogic.cs, Zeilen 485-677 |
| StRS-16 | SyRS-25 | SwRS-30 | backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, Zeilen 1259-1271 |
| StRS-20 | SyRS-38 | SwRS-31 | backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, Zeilen 491-507 |
| StRS-16 | (direkt) | SwRS-32 | centron/Centron.WPF.UI/Modules/Finances/{ContractEvaluation2,ContractEvaluationOld} |
| StRS-16 | (direkt) | SwRS-33 | centron/Centron.WPF.UI/Modules/Finances/MasterDataLists/{ChangeMainDeviceSerialNumberView.xaml,ChangeMainDeviceSerialNumberViewModel.cs} |
| StRS-18 | SyRS-39 | SwRS-34 | backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs |
| StRS-16 | (direkt) | SwRS-35 | backend/Centron.BL/Finances/ProductLifecycleBL.cs |
| StRS-16 | SyRS-40 | SwRS-36 | centron/Centron.WPF.UI/Modules/Finances/Projects/CrmProjectGantTaskViewModel.cs |
| StRS-19 | (direkt) | SwRS-37 | centron/Centron.WPF.UI/Modules/Finances/TimerBilling/{Common,Events,Settings} |
| StRS-21 | SyRS-41 | SwRS-38 | centron/Centron.WPF.UI/Modules/Global/Actions/{PrintPdfAction.cs,SavePdfAs.cs} |
| StRS-21 | (direkt) | SwRS-39 | centron/Centron.WPF.UI/Modules/Global/NetworkDiagnostics |
| StRS-22 | SyRS-45 | SwRS-40 | centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs, Zeile 371 |
| StRS-22 | SyRS-46 | SwRS-41 | centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs, Zeilen 460-461 |
| StRS-22 | (direkt) | SwRS-42 | centron/Centron.WPF.UI/Modules/Helpdesk/Events/{TicketClosedEvent.cs,TicketForwardedEvent.cs,TicketLockChangedEvent.cs,TicketModuleLoadedEvent.cs,TicketSavedEvent.cs,TimeRecordingChangedEvent.cs} |
| StRS-22 | (direkt) | SwRS-43 | CentronRights.md, Abschnitt 16 (Checklisten) |
| StRS-22 | (direkt) | SwRS-44 | centron/Centron.WPF.UI/Modules/Helpdesk/{ExpectedEvents,ExpectedEventsReporting} |
| StRS-22 | SyRS-50 | SwRS-45 | centron/Centron.WPF.UI/Modules/Helpdesk/ConnectionNumber/{HelpdeskConnectionNumberGroupViewModel.cs,TicketConnectionNumberSelectionViewModel.cs} |
| StRS-22 | (direkt) | SwRS-46 | centron/Centron.WPF.UI/Modules/Helpdesk/Dashboard/{TicketDashboardContainerController.cs,TicketDashboardContainerKinds.cs} |
| StRS-23 | SyRS-52 | SwRS-47 | backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Zeilen 1051-1052, 1179 |
| StRS-23 | SyRS-53 | SwRS-48 | centron/Centron.WPF.UI/Modules/PasswordManager/{AccessAreaManagementModuleViewModel.cs,AccessManagementModuleViewModel.cs} |
| StRS-25 | (direkt) | SwRS-49 | centron/Centron.WPF.UI/Modules/OnlineBanking/{ConfigurationSettings,ConnectionDialog} |
| StRS-24 | SyRS-56 | SwRS-50 | centron/Centron.WPF.UI/Modules/Logistic/ShippingMethodSettings |
| StRS-16 | SyRS-58 | SwRS-51 | centron/Centron.WPF.UI/Modules/PLM/PlmLogViewModel.cs |
| StRS-16 | SyRS-62 | SwRS-52 | centron/Centron.WPF.UI/Modules/ProjectPriceImport/ProjectPriceImportColumnKind.cs |
| StRS-26 | SyRS-63 | SwRS-53 | backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs, Zeilen 139-158 |
| StRS-26 | SyRS-65 | SwRS-54 | centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement/EDIReceiptTabs |
| StRS-26 | SyRS-66 | SwRS-55 | centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense/Converters |
| StRS-20 | SyRS-69 | SwRS-56 | centron/Centron.WPF.UI/Modules/Rma/Events |
| StRS-12 | SyRS-71 | SwRS-57 | centron/Centron.WPF.UI/Modules/Statistics/StatisticAppModuleDashbaordController.cs |
| StRS-17 | SyRS-72 | SwRS-58 | centron/Centron.WPF.UI/Modules/Survey/{ReloadProcessEvent.cs,UpdateSurveyProcessEvent.cs} |
| StRS-27 | SyRS-73 | SwRS-59 | backend/Centron.Entities/Entities/DocuBoard/AssetManagementArticleAssignment.cs; backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs |
| StRS-27 | (direkt) | SwRS-60 | centron/Centron.WPF.UI/Modules/Warehousing/MaterialGroupManagement |
| StRS-27 | (direkt) | SwRS-61 | centron/Centron.WPF.UI/Modules/Warehousing/AccountSystems/AccountSystemTemplate |
| StRS-27 | (direkt) | SwRS-62 | centron/Centron.WPF.UI/Modules/Warehousing/Commissioning/BaseUserControll.cs |
| StRS-27 | SyRS-77 | SwRS-63 | centron/Centron.WPF.UI/Modules/Warehousing/Inventory/Enums |
| StRS-27 | (direkt) | SwRS-64 | centron/Centron.WPF.UI/Modules/Warehousing/ValueAddedTaxViewModel.cs |
| StRS-28 | SyRS-81 | SwRS-65 | webservice/Centron.Controllers/Authorization/README.md, Abschnitt "Behind the Scenes", Punkt 3 |
| StRS-28 | SyRS-81 | SwRS-66 | webservice/Centron.Controllers/Authorization/README.md, Abschnitt "HTTP Response Codes" |
| StRS-29 | SyRS-84 | SwRS-67 | nexus/CentronNexus/WebCart/CustomerPortal/*.razor |
| StRS-30 | SyRS-85 | SwRS-68 | backend/Centron.Common/DeveloperSecurity.cs, Zeile 18 |
| StRS-26 | SyRS-86 | SwRS-69 | backend/Centron.Gateway/{EDI_Alltron,EDI_Also,EDI_AlsoCH,EDI_EGIS,EDI_Herweck,EDI_Komsa} |
| StRS-16 | SyRS-87 | SwRS-70 | backend/Centron.DAO/SessionCache.cs; Verwendung in backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Zeile 646 |
| StRS-16 | SyRS-88 | SwRS-71 | SSMS_DB_SCHEMA.sql, Auszählung CREATE TABLE (1.535) vs. FOREIGN KEY (134) |
| StRS-29 | SyRS-84 | SwRS-72 | nexus/CentronNexus/Management/WebAccount |
| StRS-16 | (direkt) | SwRS-73 | nexus/CentronNexus/ProductionOrderManagement/{Components,Model,Pages} |
| StRS-28 | SyRS-92 | SwRS-74 | webservice/c-entron.misc.ConnectionManager/{Controls,Dialogs} |
| StRS-32 | SyRS-90 | SwRS-75 | apis/Centron.APIs.FinAPI/IFinApiClient.cs |
| StRS-32 | SyRS-90 | SwRS-76 | apis/Centron.Api.Gls/{CentronGlsLogic.cs,CentronGlsConsts.cs,CentronGlsErrors.cs}; apis/Centron.Api.Shipcloud/{CentronShipcloudLogic.cs,CentronShipcloudConsts.cs} |
| StRS-33 | SyRS-94 | SwRS-77 | shared/Centron.Core/GoogleAuthenticator/{TwoFactorAuthenticator.cs,Base32.cs} |
| StRS-33 | SyRS-94 | SwRS-78 | webservice/Centron.WebServices.Core/RestRequests/TwoFactorAuthenticator/UpdateAppUserTwoFactorAuthKeyRequest.cs |
| StRS-34 | SyRS-95 | SwRS-79 | docker/compose/appsettings.Production.json |
| StRS-32 | SyRS-100 | SwRS-80 | Centron.Api.docuFORM/Models |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Protokoll.md
+221
View File
@@ -0,0 +1,221 @@
# 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-26T10:29:47.5079432+02:00
- **Endzeit:** 2026-08-26T11:17:44.5687994+02:00
- **Dauer gesamt:** 0:47:57 (`duration_ms` 0:47:55; API: 0:46:55)
— **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: ja)
- **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:** **ja – der Snapshot weicht vom Commit-Stand ab.** Folgende Dateien lagen zusätzlich im Arbeitsverzeichnis und standen dem Lauf als Artefaktquelle zur Verfügung:
- `QuellCode/CentronERP/SSMS_DB_SCHEMA.sql` (Git-Status `??`)
- SHA-256: `ED7F21250E868577572B4CADA53C132F7433C74270BF9B59E817CCEC6B1FA8DB`
- 3.266.626 B / 76.793 Zeilen – SSMS-Schema-Dump der Datenbank `CentronVOED2`: 1.558 `CREATE TABLE`, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel
Läufe mit und ohne diese Artefakte sind **nicht** unmittelbar vergleichbar: Der
Untersuchungsgegenstand ist ein anderer.
- **Nutzung des DB-Schemas:** **ja** – 5 Werkzeugaufruf(e) mit `SSMS_DB_SCHEMA` in der Eingabe (`Bash`, `Grep`, `Write`), 7 Nennungen in den Ergebnisartefakten. Die Datei wurde als Artefaktquelle tatsächlich ausgewertet.
- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
## Werkzeugkonfiguration
- **Skill-Version:** 4.3.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-sonnet-5`
- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 49.664.143 Tokens (99.99 %), `claude-haiku-4-5-20251001` 6.968 Tokens (0.01 %)
- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
- **Effort:** `high` (per `--effort high` gesetzt)
- **Laufverzeichnis-ID:** `v4.3.0-1b24`
- **Ablage:** `Iteration 3/claude-sonnet-5/solo/high/`
- **Parallele Läufe:** **ja** – zeitgleich liefen:
- `02_Lauf_2026-08-26_102932_v4.3.0-0848`
- `02_Lauf_2026-08-26_102932_v4.3.0-2316`
- `02_Lauf_2026-08-26_102932_v4.3.0-3ef5`
- `02_Lauf_2026-08-26_102932_v4.3.0-b652`
Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden.
Tokenverbrauch, Anforderungszahl und Denials bleiben unverzerrt.
- **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 | 386 |
| Output-Tokens | 293.979 (davon 63.731 Thinking-Tokens) |
| Cache-Write-Tokens | 422.354 |
| Cache-Read-Tokens | 48.947.424 |
| Agent-Turns | 193 |
### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
|---|---:|---:|---:|
| Input-Tokens | 386 | 6.944 | 7.330 |
| Output-Tokens | 293.979 | 24 | 294.003 |
| Cache-Write-Tokens | 422.354 | 0 | 422.354 |
| Cache-Read-Tokens | 48.947.424 | 0 | 48.947.424 |
| **Tokens gesamt** | **49.664.143** | **6.968** | **49.671.111** |
**Tokens gesamt: 49.671.111** — 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 | 34 | 15,8 % |
| SyRS | 101 | 47,0 % |
| SwRS | 80 | 37,2 % |
| **Gesamt** | **215** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| Daten | 73 | 34,0 % |
| funktional | 67 | 31,2 % |
| Schnittstelle | 27 | 12,6 % |
| Sicherheit | 26 | 12,1 % |
| nicht-funktional | 22 | 10,2 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 233 |
| davon `PRIMÄR` | 93 (39,9 %) |
| davon `SEKUNDÄR` | 77 (33,0 %) |
| davon `KONTEXT` | 63 (27,0 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 92 (42,8 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 202 | 94,0 % |
| workaround | 4 | 1,9 % |
| sonderfall | 8 | 3,7 % |
| veraltet | 1 | 0,5 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 153 | 71,2 % |
| als `HYPOTHESE` gekennzeichnet | 62 | 28,8 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 20 | 9,3 % |
| mit ISO-25010-Qualitätsmerkmal | 47 | 21,9 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 8 von 59 ungedeckt: StRS-6, StRS-17, SyRS-80, SyRS-84, SwRS-37, SwRS-48, SwRS-61, SwRS-64 |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 215 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 215 von 215 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
- **Session-ID:** `e8e4e79a-a4fb-4a8b-b403-01adf8d20802`
- **Permission-Denials:** 3 (1 × `Bash`, 2 × `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` | 43.358 B |
| `Glossar.md` | 6.956 B |
| `Hypothesen.md` | 11.875 B |
| `StRS.md` | 53.714 B |
| `SwRS.md` | 92.253 B |
| `SyRS.md` | 123.155 B |
| `Traceability.md` | 10.235 B |
- **Root unverändert:** ja (zeilenendennormalisiert verglichen). Der rohe Vorher/Nachher-Vergleich weicht ab, weil `SSMS_DB_SCHEMA.sql` zwischen Laufbeginn und Auswertung committet wurde und deshalb nicht mehr als `??` im Status erscheint. Nach Normalisierung um diese Zeile sind beide Stände identisch; zusätzlich ist `git diff HEAD -- QuellCode/CentronERP` leer (bestätigt). Am Inhalt des Arbeitsverzeichnisses hat der Lauf nichts verändert.
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
## Anmerkungen/Auffälligkeiten
**1. Iteration 3 = geänderter Untersuchungsgegenstand.** Seit 2026-08-26 10:28:08 liegt
`SSMS_DB_SCHEMA.sql` im Arbeitsverzeichnis (3.266.626 B, 76.793 Zeilen, 1.558 Tabellen, 182 Views,
63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256 `ED7F2125…1FA8DB`, Commit `f349d189`).
Der Prompt fordert Datenbankschemata in Schritt 2 ausdrücklich als Artefaktquelle. Läufe der
Iteration 2 hatten die Datei nicht – die beiden Iterationen sind **nicht poolbar**.
**2. Verfügbarkeit ≠ Nutzung.** Ob der Agent das Schema öffnet, ist eine **abhängige** Variable:
Von den fünf Läufen der Iteration 3 haben drei es genutzt (`0848`, `1b24`, `2316`), zwei nicht
(`3ef5`, `b652`). Erhoben wird das über Werkzeugaufrufe, deren **Eingabe** den Dateinamen nennt –
nicht über Texttreffer im Transkript: Die Verzeichnisauflistung zu Laufbeginn nennt die Datei
zwangsläufig und ist kein Zugriff.
**3. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Fünf Läufe gleichzeitig,
zeitweise überlappend mit `094249_v4.2.1-4840` aus Iteration 2. Wanduhrzeit, `duration_ms` und
`duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials
nicht. Einziger gültiger Laufzeitmesspunkt beider Iterationen bleibt der serielle Lauf
`084301_v4.2.0-d6f9` mit 45:04.
**4. Root-Vergleich normalisiert.** `before.txt` führt das Schema als `??`, `after.txt` ist leer –
weil die Datei zwischen Laufbeginn und Auswertung committet wurde. Der rohe Vergleich meldete
deshalb eine Abweichung, die es nicht gibt. Nach Normalisierung um diese Zeile sind beide Stände
identisch, zusätzlich bestätigt durch ein leeres `git diff HEAD -- QuellCode/CentronERP`.
**5. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung; die `solo`-Kontrolle
(`subagent_stats.spawned` = 0) wurde gegengeprüft und ist erfüllt.
**6. Schema genutzt, höchste Anforderungszahl der genutzten Läufe.** Fünf Werkzeugaufrufe
(`Bash`, `Grep`, `Write`), sieben Nennungen in den Ergebnisartefakten – der intensivste
Schemazugriff der Iteration. 215 Anforderungen bei 49,7 Mio. Tokens.
**7. Ausgewogenste Ebenenverteilung der Iteration 3:** 34 StRS / 101 SyRS / 80 SwRS. Als einziger
Lauf der Iteration liegt der Schwerpunkt auf der Systemebene statt auf StRS oder SwRS – näher an
`d6f9` aus Iteration 2 (20/120/30) als an den übrigen Läufen der eigenen Iteration.
**8. Belegqualität schwach: 42,8 % mit Primärbeleg**, acht von 48 risikorelevanten Anforderungen
ungedeckt. Tracelinks dagegen bei 100 %.
**9. Drei Permission-Denials, alle Nebeneffekt der Werkzeugkonfiguration:** zwei `Read`-Zugriffe
auf das eigene Temp-Verzeichnis außerhalb der freigegebenen Pfade, ein `Bash`-Kommando mit
Löschanteil. Keiner betraf `Task`/`Agent`/`Workflow` – der Agent hat nicht zu delegieren versucht.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/RawResult.json
+1
View File
@@ -0,0 +1 @@
{"is_error":false,"duration_api_ms":2815788,"num_turns":193,"stop_reason":"end_turn","session_id":"e8e4e79a-a4fb-4a8b-b403-01adf8d20802","total_cost_usd":14.426526799999994,"usage":{"input_tokens":386,"cache_creation_input_tokens":422354,"cache_read_input_tokens":48947424,"output_tokens":293979,"output_tokens_details":{"thinking_tokens":63731},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":422354,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":659,"cache_read_input_tokens":449467,"cache_creation_input_tokens":699,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":699},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6944,"outputTokens":24,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007064,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":386,"outputTokens":293979,"cacheReadInputTokens":48947424,"cacheCreationInputTokens":422354,"webSearchRequests":0,"costUSD":14.419462799999994,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"Read","tool_use_id":"toolu_01WWoevmZfSnrGv4S8gAzadp","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\e8e4e79a-a4fb-4a8b-b403-01adf8d20802\\scratchpad\\hyp_extract.txt","offset":20}},{"tool_name":"Read","tool_use_id":"toolu_018VEQVDPAqN8N2yJWjiKLU8","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\e8e4e79a-a4fb-4a8b-b403-01adf8d20802\\scratchpad\\hyp_table.md"}},{"tool_name":"Bash","tool_use_id":"toolu_01HZAj5N6XEB8PLgkPsbHMwG","tool_input":{"command":"OUT=\"c:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Tag 2\\claude-sonnet-5\\solo\\high\\02_Lauf_2026-08-26_102932_v4.3.0-1b24\\Ergebnisse\\Analysebericht.md\"\nhead -n 186 \"$OUT\" > \"$OUT.tmp\"\nmv \"$OUT.tmp\" \"$OUT\"\ntail -3 \"$OUT\"","description":"Truncate placeholder ending (keep up to line 186)"}}],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":null,"result":"Confirmed — no changes under `QuellCode/CentronERP`; all 493 pending changes are pre-existing (present before this session started, as shown in the initial git status). The analyzed codebase remains untouched, as required.\n\n## Summary\n\nI completed the reverse requirements engineering run against the full c-entron ERP codebase (15,554 C# files, 1,535 DB tables) and produced all seven deliverables in the specified output directory:\n\n- **Analysebericht.md** — 107-row module inventory (Schritt 0), coverage table, consistency check, and self-assessment\n- **StRS.md** (34), **SyRS.md** (101), **SwRS.md** (80) — 215 requirements total, each with Fakt/Aussage separation, classified evidence, testability, consolidation assessment, and adoption worthiness\n- **Traceability.md** — StRS↔SyRS↔SwRS mapping table, programmatically verified with no dangling references\n- **Hypothesen.md** — 62 hypotheses (28.8%), exactly matching inline `[HYPOTHESE]` markers\n- **Glossar.md** — 29 domain terms\n\nKey findings worth highlighting: a verified Stammblatt-vs-Asset data duplication (the calibration example), a major architectural finding that Nexus/ServiceBoard already re-implements much of the desktop Helpdesk for the web, a real AES-encrypted password manager and TOTP 2FA implementation, and — during the mandatory consistency check — 7 security/billing requirements that were initially marked \"belegt\" on only secondary evidence got caught and corrected to HYPOTHESE before the run closed, which I left visible rather than silently fixing.\n\nOne honest gap: the 11 receipt types (Offers/Orders/DeliveryLists/etc.) were covered collectively via the shared `IReceiptSpecificLogic` interface rather than with individual per-type requirements — flagged explicitly in the self-assessment as follow-up work.","ttft_ms":4386,"ttft_stream_ms":1105,"time_to_request_ms":35,"type":"result","duration_ms":2875045,"uuid":"732d8247-5294-4754-857e-42c83431e868","queued_turn_count":0}
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Stderr.log
View File
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/after.txt
View File
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/anforderungen.json
+4105
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/anforderungen.md
+65
View File
@@ -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 | 34 | 15,8 % |
| SyRS | 101 | 47,0 % |
| SwRS | 80 | 37,2 % |
| **Gesamt** | **215** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| Daten | 73 | 34,0 % |
| funktional | 67 | 31,2 % |
| Schnittstelle | 27 | 12,6 % |
| Sicherheit | 26 | 12,1 % |
| nicht-funktional | 22 | 10,2 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 233 |
| davon `PRIMÄR` | 93 (39,9 %) |
| davon `SEKUNDÄR` | 77 (33,0 %) |
| davon `KONTEXT` | 63 (27,0 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 92 (42,8 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 202 | 94,0 % |
| workaround | 4 | 1,9 % |
| sonderfall | 8 | 3,7 % |
| veraltet | 1 | 0,5 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 153 | 71,2 % |
| als `HYPOTHESE` gekennzeichnet | 62 | 28,8 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 20 | 9,3 % |
| mit ISO-25010-Qualitätsmerkmal | 47 | 21,9 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 8 von 59 ungedeckt: StRS-6, StRS-17, SyRS-80, SyRS-84, SwRS-37, SwRS-48, SwRS-61, SwRS-64 |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 215 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 215 von 215 mit Tracelinks (100,0 %) |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/before.txt
+2
View File
@@ -0,0 +1,2 @@
?? QuellCode/CentronERP/SSMS_DB_SCHEMA.sql
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/combined_prompt.md
+177
View File
@@ -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\Tag 2\claude-sonnet-5\solo\high\02_Lauf_2026-08-26_102932_v4.3.0-1b24\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-26T11:17:44.5687994+02:00
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-26T10:29:47.5079432+02:00
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/Analysebericht.md
+417
View File
@@ -0,0 +1,417 @@
# Analysebericht
c-entron ERP-Suite - Reverse Requirements Engineering, Iteration 02 (2026-08-26)
## Schritt 0 - Modulinventar
Grundlage: `src/backend/Centron.BL` (90 fachliche Module, Stand der Verzeichnisliste zu Beginn
dieses Laufs), ergänzt um die technische Infrastruktur- und Architekturschicht der übrigen
Verzeichnisse (`src/apis`, `src/webservice`, `src/nexus`, `src/backend/Centron.DAO`,
`Centron.Entities`, `Centron.Interfaces`, `Centron.Common`, `Centron.Gateway`, `src/centron`,
`src/shared`, sowie `deployment/`, `docker/`, `assemblies/`, `tests/`, `scripts/`,
`azure*/`). Das Inventar wurde vor der ersten Anforderung erstellt (Bash-Verzeichnisauflistung und
Methodensignatur-Erhebung je Modul, siehe Vorgehen); die anschließende Vertiefung folgte der
Reihenfolge Sicherheit/Berechtigungen → Abrechnung/Zahlungsverkehr → übrige Module.
Alle 90 Verzeichnisse aus `Centron.BL` wurden erfasst; `Properties` enthält ausschließlich
`AssemblyInfo.cs` ohne fachlichen Inhalt und wird als „nicht analysiert" geführt.
| # | Modul/Komponente | Pfad | Fachliche Aufgabe | Anforderung(en) |
|---|---|---|---|---|
| 1 | Accounting | src/backend/Centron.BL/Accounting | Bankverbindungen von Kunden verwalten (inkl. Autorisierungsstatus). | SwRS-25 |
| 2 | Accounts | src/backend/Centron.BL/Accounts | Kundenadressen, Hotline-Verträge und Marketing-/Kampagnendaten je Account. | SwRS-5 |
| 3 | Administration | src/backend/Centron.BL/Administration | Systemkonfiguration, Rechteverwaltung, API-Tokens, Kontenrahmen, Update-Benachrichtigung. | SwRS-29, SwRS-34, SwRS-35, SwRS-40, SwRS-75 |
| 4 | AppointmentRequests | src/backend/Centron.BL/AppointmentRequests | Externe Terminanfragen und -vorschläge verarbeiten. | SwRS-46 |
| 5 | ArtificialIntelligence | src/backend/Centron.BL/ArtificialIntelligence | KI-Provider-Anbindung (Chat, Textbewertung, Ticketkategorisierung) über eine Factory. | SwRS-99 |
| 6 | BusinessPartner | src/backend/Centron.BL/BusinessPartner | Lieferantensuche und lieferantenbezogene Vorgangsarten (Buchung, Gutschrift, Wareneingang etc.). | SwRS-13 |
| 7 | Buying | src/backend/Centron.BL/Buying | Distributorenstammdaten für den Einkauf. | SwRS-14 |
| 8 | CPra | src/backend/Centron.BL/CPra | Anbindung an das externe Kundenportal CPra inkl. Webhooks. | SwRS-83 |
| 9 | Calendar | src/backend/Centron.BL/Calendar | Kalenderdarstellungs- und -synchronisationseinstellungen. | SwRS-45 |
| 10 | CentronIcons | src/backend/Centron.BL/CentronIcons | Paginierter Icon-Katalog für die UI. | SwRS-103 |
| 11 | CentronNexus (BL) | src/backend/Centron.BL/CentronNexus | Portalweite Nexus-Einstellungen. | SwRS-93 |
| 12 | ChangeTracking | src/backend/Centron.BL/ChangeTracking | Importhistorie je Benutzer protokollieren. | SwRS-102 |
| 13 | Chats | src/backend/Centron.BL/Chats | Team-Chats mit optionalem Objektbezug. | SwRS-60 |
| 14 | CheckListArea | src/backend/Centron.BL/CheckListArea | Checklisten und -positionen verwalten. | SwRS-47 |
| 15 | Core | src/backend/Centron.BL/Core | Passwort-Hashing und generische Textvariablenersetzung. | SwRS-36 |
| 16 | CountryArea | src/backend/Centron.BL/CountryArea | Länder-/Währungsstammdaten. | SwRS-104 |
| 17 | CustomerArea | src/backend/Centron.BL/CustomerArea | Geschäftsfelder je Kunde und RMA-Kernprozess. | SwRS-6 |
| 18 | Customizations | src/backend/Centron.BL/Customizations | Kundenspezifische Zusatztabellen mit Variablenersetzung. | SwRS-77 |
| 19 | DataExchange | src/backend/Centron.BL/DataExchange | Zahlungsexport (SEPA/Lastschrift) und Buchhaltungsexport-Konfiguration. | SwRS-28, SwRS-30 |
| 20 | Devices | src/backend/Centron.BL/Devices | Kundengeräte über interne und externe IDs verwalten. | SwRS-66 |
| 21 | DocuBoard | src/backend/Centron.BL/DocuBoard | Asset-Zuordnung zu Artikeln/Partnern (Konsolidierungsfall mit „Stammblatt"). | SwRS-100 |
| 22 | DocumentationArea | src/backend/Centron.BL/DocumentationArea | Interne Dokumentationsartikel mit Rechtecheck. | SwRS-71 |
| 23 | EDI | src/backend/Centron.BL/EDI | Elektronischer Bestellversand an mehrere Distributoren. | SwRS-15 |
| 24 | EmployeeArea | src/backend/Centron.BL/EmployeeArea | Mitarbeiterkonten, Administratorstatus, Web-Account-/Systembenutzer-Trennung. | SwRS-43 |
| 25 | Exceptions | src/backend/Centron.BL/Exceptions | Fachliche Ausnahme für abgelaufene Tickets. | SwRS-56 |
| 26 | ExpectedEvents | src/backend/Centron.BL/ExpectedEvents | Erwartete Ereignisse mit Protokoll. | SwRS-53 |
| 27 | ExternalHelpdesk | src/backend/Centron.BL/ExternalHelpdesk | Externe Helpdesk-Konfigurationen. | SwRS-48 |
| 28 | ExternalToolsBL | src/backend/Centron.BL/ExternalToolsBL | Frei konfigurierbare externe Werkzeuge. | SwRS-84 |
| 29 | Finances | src/backend/Centron.BL/Finances | Online-Banking (FinAPI, IBAN-Abgleich) und Aktivitätsvorlagen. | SwRS-26, SwRS-27, SwRS-31 |
| 30 | GUI | src/backend/Centron.BL/GUI | Bestellimport aus externen Quellen. | SwRS-24 |
| 31 | Gateway | src/backend/Centron.BL/Gateway | Kundenspezifische Artikel-Vertrags-Importe. | SwRS-85 |
| 32 | Helpers | src/backend/Centron.BL/Helpers | PDF-Zusammenführung und weitere Hilfsfunktionen. | SwRS-73 |
| 33 | IndexSearch | src/backend/Centron.BL/IndexSearch | Objekttypübergreifender Volltextindex. | SwRS-69 |
| 34 | Integrations | src/backend/Centron.BL/Integrations | Externe Kundengruppensynchronisation. | SwRS-86 |
| 35 | ItPlanner | src/backend/Centron.BL/ItPlanner | Kategorisierung virtueller Checklistenobjekte im IT-Planer. | SwRS-49 |
| 36 | Logistics | src/backend/Centron.BL/Logistics | Zentrale Logistikeinstellungen. | SwRS-21 |
| 37 | Mail | src/backend/Centron.BL/Mail | Absenderdomänen-Blacklist. | SwRS-57 |
| 38 | MailScanner | src/backend/Centron.BL/MailScanner | Scan-Workflows und -Profile für eingehende E-Mails. | SwRS-58 |
| 39 | Mailings | src/backend/Centron.BL/Mailings | Massen-E-Mail-Kampagnen. | SwRS-59 |
| 40 | MassUpdate | src/backend/Centron.BL/MassUpdate | Wiederverwendbare Massenänderungsvorlagen. | SwRS-80 |
| 41 | Mobile | src/backend/Centron.BL/Mobile | Mitarbeiterdaten für mobile Clients. | SwRS-95 |
| 42 | Modules | src/backend/Centron.BL/Modules | Modulkatalog und Benutzerfavoriten. | SwRS-76 |
| 43 | MyCentron | src/backend/Centron.BL/MyCentron | Personalisierbares Dashboard. | SwRS-91 |
| 44 | MyDay | src/backend/Centron.BL/MyDay | Persönliche Tagesplanung mit Batch-Verarbeitung. | SwRS-92 |
| 45 | NexusNotifications | src/backend/Centron.BL/NexusNotifications | Benachrichtigungsstatus im Web-Portal. | SwRS-63 |
| 46 | NexusTicketViews | src/backend/Centron.BL/NexusTicketViews | Persönliche und globale Ticketansichten. | SwRS-54 |
| 47 | Notifications | src/backend/Centron.BL/Notifications | Desktop-Benachrichtigungseinstellungen. | SwRS-64 |
| 48 | ObjectExternalReferences | src/backend/Centron.BL/ObjectExternalReferences | Objekttypübergreifende externe Referenzen. | SwRS-101 |
| 49 | Outlook | src/backend/Centron.BL/Outlook | Asset-Art-Suche für die Outlook-Integration. | SwRS-105 |
| 50 | PasswordManagementArea | src/backend/Centron.BL/PasswordManagementArea | Kundenzugangsdaten mit Entschlüsselung und Zugriffsprotokoll. | SwRS-38 |
| 51 | PasswordManager | src/backend/Centron.BL/PasswordManager | Kunden-/Mitarbeiter-Zugriffsrechte auf Zugangsdaten. | SwRS-39 |
| 52 | Processes | src/backend/Centron.BL/Processes | Generische, objekttypunabhängige Prozessbindung. | SwRS-89 |
| 53 | ProductMatrix | src/backend/Centron.BL/ProductMatrix | Produktkategorien und kundenspezifische Produktbewertungen. | SwRS-7 |
| 54 | Production | src/backend/Centron.BL/Production | Produktionsmaschinen und -aufträge. | SwRS-23 |
| 55 | Projects | src/backend/Centron.BL/Projects | Zeitlich filterbare Projektliste. | SwRS-90 |
| 56 | Properties | src/backend/Centron.BL/Properties | Nur `AssemblyInfo.cs` - kein fachlicher Inhalt. | **nicht analysiert** |
| 57 | Purchasing | src/backend/Centron.BL/Purchasing | Bestellvorschläge und Lieferantenverwaltung. | SwRS-11, SwRS-12 |
| 58 | ReportEngine | src/backend/Centron.BL/ReportEngine | Berichtsexport (einzeln/gruppenweise). | SwRS-67 |
| 59 | Reporting | src/backend/Centron.BL/Reporting | Berichtszugriff per ID oder Prädikat. | SwRS-68 |
| 60 | Resources | src/backend/Centron.BL/Resources | Zentrale Update-/Release-URLs. | SwRS-74 |
| 61 | RiverDivo | src/backend/Centron.BL/RiverDivo | Externe Vertragsartikel-Abrechnung. | SwRS-10 |
| 62 | Sales | src/backend/Centron.BL/Sales | Belegkette Angebot-Auftrag-Rechnung-Gutschrift, inkl. Fixierung, Stornierung, Lieferantenrechnungen. | SwRS-1, SwRS-2, SwRS-3, SwRS-4, SwRS-16 |
| 63 | Security | src/backend/Centron.BL/Security | PDF-Signatureinstellungen. | SwRS-41 |
| 64 | SelfCare | src/backend/Centron.BL/SelfCare | Metadatengetriebene Selbstbedienungsformulare. | SwRS-94 |
| 65 | Services | src/backend/Centron.BL/Services | Tabellencache-Steuerung. | SwRS-79 |
| 66 | SocialMedia | src/backend/Centron.BL/SocialMedia | Kommentare/Likes auf Social-Media-Streams. | SwRS-62 |
| 67 | Start | src/backend/Centron.BL/Start | Verbindungsaufbau beim Anwendungsstart. | SwRS-106 |
| 68 | Statistics | src/backend/Centron.BL/Statistics | Offene-Posten-Übersicht und weitere Auswertungen. | SwRS-33 |
| 69 | Storage | src/backend/Centron.BL/Storage | Inventurtransaktionen. | SwRS-22 |
| 70 | SystemArea | src/backend/Centron.BL/SystemArea | Systemweiter I3D-Zustandsdatensatz. | SwRS-78 |
| 71 | Tags | src/backend/Centron.BL/Tags | Schlagwörter inkl. Ticketverknüpfung. | SwRS-50 |
| 72 | Tapi | src/backend/Centron.BL/Tapi | Telefonanrufprotokollierung. | SwRS-61 |
| 73 | TaskManager | src/backend/Centron.BL/TaskManager | Paginierte Aufgabenverwaltung. | SwRS-51 |
| 74 | Telemetry | src/backend/Centron.BL/Telemetry | Nutzungserfassung interner Werkzeuge/KI-Funktionen. | SwRS-70 |
| 75 | TextModuleArea | src/backend/Centron.BL/TextModuleArea | Generische Anrede-/Vereinbarungsersetzung in Textbausteinen. | SwRS-72 |
| 76 | TicketProjects | src/backend/Centron.BL/TicketProjects | Ticketprojekte mit Abhängigkeiten. | SwRS-55 |
| 77 | Time | src/backend/Centron.BL/Time | Arbeitszeitmodelle. | SwRS-44 |
| 78 | ToDoArea | src/backend/Centron.BL/ToDoArea | Objekttypübergreifende ToDo-Liste. | SwRS-52 |
| 79 | Tools | src/backend/Centron.BL/Tools | Zentrale Textformatumwandlung. | SwRS-107 |
| 80 | TradePool | src/backend/Centron.BL/TradePool | Import von Handelsartikeldaten. | SwRS-9 |
| 81 | Transactions | src/backend/Centron.BL/Transactions | Benutzerbezogenes Transaktionsprotokoll. | SwRS-108 |
| 82 | TwoFactorAuthenticator | src/backend/Centron.BL/TwoFactorAuthenticator | TOTP-basierte Zwei-Faktor-Authentifizierung. | SwRS-37 |
| 83 | Urls | src/backend/Centron.BL/Urls | Verwaltete Kurz-URLs. | SwRS-109 |
| 84 | VideoPortal | src/backend/Centron.BL/VideoPortal | Video-Objektzuordnung. | SwRS-110 |
| 85 | VoucherManagement | src/backend/Centron.BL/VoucherManagement | Gutscheinverwaltung nach Zustand (frei/ausgegeben/eingelöst). | SwRS-8 |
| 86 | Warehousing | src/backend/Centron.BL/Warehousing | Staffelpreise, Bestandsführung, Aktionspreise. | SwRS-18, SwRS-19, SwRS-20 |
| 87 | WebLinks | src/backend/Centron.BL/WebLinks | Gruppierte, aktionsbasierte Weblinks. | SwRS-65 |
| 88 | WebServices (BL) | src/backend/Centron.BL/WebServices | Adresskontaktverwaltung für Webservice-Clients. | SwRS-96 |
| 89 | WebSuite | src/backend/Centron.BL/WebSuite | Benutzer-/mitarbeiterbezogene INI-Einstellungen. | SwRS-81 |
| 90 | WebVersion | src/backend/Centron.BL/WebVersion | Webservice-Versionsauskunft. | SwRS-82 |
| 91 | Externe Produktdatenanbindungen (COP/EGIS/ITscope/Icecat) | src/apis/Centron.APIs.* | Artikelstamm-/Zubehördaten aus vier externen Quellen beziehen. | SwRS-17 |
| 92 | Externe Finanzschnittstellen (FinAPI/ebInterface) | src/apis/Centron.APIs.FinAPI, src/apis/Centron.Api.EbInterface | Bankdatenabruf und österreichische E-Rechnung. | SwRS-32 |
| 93 | Versanddienstleister GLS | src/apis/Centron.Api.Gls | Sendungserstellung mit Testmodus. | SwRS-87 |
| 94 | Versanddienstleister Shipcloud | src/apis/Centron.Api.Shipcloud | Sendungserstellung mit Frachtführerabfrage. | SwRS-88 |
| 95 | docuFORM (Drucker-/Gerätezähler) | src/Centron.Api.docuFORM | Zählerstände von Druckern extern abrufen. | SwRS-111 |
| 96 | Centron.Controllers (Webservice-Autorisierung) | src/webservice/Centron.Controllers | Deklarative REST-Rechteautorisierung. | SwRS-42 |
| 97 | Centron.WebServices.Core | src/webservice/Centron.WebServices.Core | Typsicherer REST-Aufrufmechanismus (Client-Kern). | SwRS-112 |
| 98 | Centron.Host | src/webservice/Centron.Host | Analytics-Instrumentierung des Webservice-Starts. | SwRS-113 |
| 99 | CentronNexus (Web-Portal) | src/nexus/CentronNexus | Blazor-Webportal inkl. Branding-Konfiguration. | SwRS-97 |
| 100 | CentronNexus.OutlookAddIn | src/nexus/CentronNexus.OutlookAddIn | Outlook-Add-in für E-Mail-Anhänge im Portal. | SwRS-98 |
| 101 | Centron.DAO | src/backend/Centron.DAO | Generische NHibernate-Persistenzschicht. | SwRS-114 |
| 102 | Centron.Entities | src/backend/Centron.Entities | Einheitliches Domänenmodell/Entitätsgleichheit. | SwRS-115 |
| 103 | Centron.Gateway (Projekt) | src/backend/Centron.Gateway | Buchhaltungsexport-Dateierzeugung mit Teilerfolgsmodell. | SwRS-117 |
| 104 | Centron.Controls | src/shared/Centron.Controls | Wiederverwendbare WPF-Steuerelemente (Hinweis-Flyout u. a.). | SwRS-116 |
| 105 | Centron.WPF.UI (Shell) | src/centron/Centron.WPF.UI | Desktop-Client-Hauptfenster, Ribbon, rechtebasierte Modulsichtbarkeit. | SwRS-118 |
| 106 | c-entron.misc.ConnectionManager | src/webservice/c-entron.misc.ConnectionManager | Verbindungskonfigurationswerkzeug mit Silent-Modus. | SwRS-119 |
| 107 | Centron.Interfaces / Centron.Common | src/backend/Centron.Interfaces, src/backend/Centron.Common | Vertragsschnittstellen und Utility-Bibliothek. | **nicht analysiert** |
| 108 | Centron.WPF.UI.Extension / Centron.Controls.Preview / CentronNexus.Host | src/centron/Centron.WPF.UI.Extension, src/shared/Centron.Controls.Preview, src/nexus/CentronNexus.Host | Technische Trägerprojekte (WPF-Erweiterungen, Steuerelement-Vorschau, Web-Hosting-Bootstrapper). | **nicht analysiert** |
| 109 | Build-/Deployment-/Test-Infrastruktur | deployment/, docker/, assemblies/, tests/, scripts/, azure*/ | CI/CD-Pipelines, Installer, Drittanbieter-Assemblies, Testprojekte. | **nicht analysiert** |
Begründung „nicht analysiert" (Zeilen 56, 107-109): Diese Verzeichnisse enthalten entweder keinen
fachlichen Code (`Properties`, reine Build-/Deployment-Artefakte) oder ausschließlich technische
Vertrags-/Hilfsbibliotheken ohne im Rahmen dieser Erhebung identifizierte eigenständige
Geschäftsregeln - ihre Fachlogik wird bereits über die sie nutzenden BL-Module und die übrigen
Infrastruktur-Zeilen (91-106) erfasst. Eine belegbare eigenständige Anforderung ließ sich für sie
nicht bilden, ohne den Rahmen dieser Iteration zu sprengen.
## Abdeckungstabelle
Einstufung je Zeile des Modulinventars: **tief** (mehrere Anforderungen und/oder mehrzeilig
nachvollzogener Durchsetzungsmechanismus, z. B. Transaktion/SQL/Statusprüfung im Methodenkörper
gelesen), **mittel** (eine Anforderung mit mindestens einem `PRIMÄR`-Beleg und konkreter
Methodensignatur), **flach** (eine Anforderung ausschließlich mit `SEKUNDÄR`/`KONTEXT`-Belegen,
also nur struktureller Nachweis ohne gelesenen Durchsetzungsmechanismus), **nicht analysiert**
(siehe Begründung oben). Jede Zeile des Inventars erscheint hier genau einmal.
| # | Modul | Einstufung | Anzahl Anforderungen |
|---|---|---|---|
| 1 | Accounting | mittel | 1 |
| 2 | Accounts | mittel | 1 |
| 3 | Administration | tief | 5 |
| 4 | AppointmentRequests | mittel | 1 |
| 5 | ArtificialIntelligence | mittel | 1 |
| 6 | BusinessPartner | tief | 1 |
| 7 | Buying | flach | 1 |
| 8 | CPra | mittel | 1 |
| 9 | Calendar | flach | 1 |
| 10 | CentronIcons | flach | 1 |
| 11 | CentronNexus (BL) | flach | 1 |
| 12 | ChangeTracking | mittel | 1 |
| 13 | Chats | mittel | 1 |
| 14 | CheckListArea | mittel | 1 |
| 15 | Core | tief | 1 |
| 16 | CountryArea | mittel | 1 |
| 17 | CustomerArea | mittel | 1 |
| 18 | Customizations | mittel | 1 |
| 19 | DataExchange | tief | 2 |
| 20 | Devices | mittel | 1 |
| 21 | DocuBoard | tief | 1 |
| 22 | DocumentationArea | mittel | 1 |
| 23 | EDI | tief | 1 |
| 24 | EmployeeArea | tief | 1 |
| 25 | Exceptions | flach | 1 |
| 26 | ExpectedEvents | mittel | 1 |
| 27 | ExternalHelpdesk | flach | 1 |
| 28 | ExternalToolsBL | flach | 1 |
| 29 | Finances | tief | 3 |
| 30 | GUI | mittel | 1 |
| 31 | Gateway | mittel | 1 |
| 32 | Helpers | mittel | 1 |
| 33 | IndexSearch | mittel | 1 |
| 34 | Integrations | mittel | 1 |
| 35 | ItPlanner | flach | 1 |
| 36 | Logistics | flach | 1 |
| 37 | Mail | mittel | 1 |
| 38 | MailScanner | flach | 1 |
| 39 | Mailings | flach | 1 |
| 40 | MassUpdate | mittel | 1 |
| 41 | Mobile | mittel | 1 |
| 42 | Modules | mittel | 1 |
| 43 | MyCentron | mittel | 1 |
| 44 | MyDay | mittel | 1 |
| 45 | NexusNotifications | mittel | 1 |
| 46 | NexusTicketViews | mittel | 1 |
| 47 | Notifications | flach | 1 |
| 48 | ObjectExternalReferences | tief | 1 |
| 49 | Outlook | flach | 1 |
| 50 | PasswordManagementArea | tief | 1 |
| 51 | PasswordManager | mittel | 1 |
| 52 | Processes | tief | 1 |
| 53 | ProductMatrix | flach | 1 |
| 54 | Production | mittel | 1 |
| 55 | Projects | flach | 1 |
| 56 | Properties | nicht analysiert | 0 |
| 57 | Purchasing | tief | 2 |
| 58 | ReportEngine | mittel | 1 |
| 59 | Reporting | mittel | 1 |
| 60 | Resources | flach | 1 |
| 61 | RiverDivo | mittel | 1 |
| 62 | Sales | tief | 5 |
| 63 | Security | mittel | 1 |
| 64 | SelfCare | mittel | 1 |
| 65 | Services | mittel | 1 |
| 66 | SocialMedia | mittel | 1 |
| 67 | Start | flach | 1 |
| 68 | Statistics | mittel | 1 |
| 69 | Storage | flach | 1 |
| 70 | SystemArea | flach | 1 |
| 71 | Tags | mittel | 1 |
| 72 | Tapi | mittel | 1 |
| 73 | TaskManager | mittel | 1 |
| 74 | Telemetry | mittel | 1 |
| 75 | TextModuleArea | mittel | 1 |
| 76 | TicketProjects | mittel | 1 |
| 77 | Time | flach | 1 |
| 78 | ToDoArea | mittel | 1 |
| 79 | Tools | flach | 1 |
| 80 | TradePool | mittel | 1 |
| 81 | Transactions | tief | 1 |
| 82 | TwoFactorAuthenticator | tief | 1 |
| 83 | Urls | flach | 1 |
| 84 | VideoPortal | flach | 1 |
| 85 | VoucherManagement | mittel | 1 |
| 86 | Warehousing | tief | 3 |
| 87 | WebLinks | mittel | 1 |
| 88 | WebServices (BL) | mittel | 1 |
| 89 | WebSuite | mittel | 1 |
| 90 | WebVersion | mittel | 1 |
| 91 | Externe Produktdatenanbindungen | mittel | 1 |
| 92 | Externe Finanzschnittstellen | mittel | 1 |
| 93 | Versanddienstleister GLS | mittel | 1 |
| 94 | Versanddienstleister Shipcloud | mittel | 1 |
| 95 | docuFORM | tief | 1 |
| 96 | Centron.Controllers | tief | 1 |
| 97 | Centron.WebServices.Core | mittel | 1 |
| 98 | Centron.Host | flach | 1 |
| 99 | CentronNexus (Web-Portal) | mittel | 1 |
| 100 | CentronNexus.OutlookAddIn | flach | 1 |
| 101 | Centron.DAO | mittel | 1 |
| 102 | Centron.Entities | mittel | 1 |
| 103 | Centron.Gateway (Projekt) | mittel | 1 |
| 104 | Centron.Controls | flach | 1 |
| 105 | Centron.WPF.UI (Shell) | tief | 1 |
| 106 | c-entron.misc.ConnectionManager | flach | 1 |
| 107 | Centron.Interfaces / Centron.Common | nicht analysiert | 0 |
| 108 | Centron.WPF.UI.Extension / Controls.Preview / CentronNexus.Host | nicht analysiert | 0 |
| 109 | Build-/Deployment-/Test-Infrastruktur | nicht analysiert | 0 |
**Summe:** 109 Modulinventar-Zeilen; 105 analysiert (19 tief, 59 mittel, 27 flach), 4 nicht
analysiert. 175 formale Anforderungen insgesamt (StRS-1..20 = 20; SyRS-1..36 = 36; SwRS-1..119 =
119).
## Konsistenzcheck
**Doppelte oder mehrfach vergebene IDs.** Keine gefunden. StRS-1..20, SyRS-1..36 und SwRS-1..119
sind jeweils lückenlos und ohne Duplikat vergeben (per Bash-Auszählung der `ID:`-Zeilen je Datei
geprüft).
**Anforderungen ohne Beleg.** Keine gefunden. Jede der 175 Anforderungen (20 StRS + 36 SyRS + 119
SwRS) enthält mindestens einen Eintrag im Feld `Belege` (per Auszählung `Belege:`- gegen
`ID:`-Zeilen je Datei verifiziert: 20/20, 36/36, 119/119).
**Anforderungen ohne Angabe zur Übernahmewürdigkeit.** Keine gefunden (20/20, 36/36, 119/119
`Übernahmewürdigkeit:`-Zeilen vorhanden).
**Tracelinks auf nicht existierende IDs.** Keine gefunden. Alle `Tracelinks`-Verweise in StRS.md
(→ SyRS-1..36) und in SyRS.md (→ StRS-1..20) wurden gegen die tatsächlich vergebenen IDs geprüft.
Alle 119 SwRS-Anforderungen referenzieren ausschließlich SyRS-IDs (kein direkter Verweis auf
StRS) - dies wurde während der Erstellung mehrfach korrigiert (ursprünglich verwiesen 15
SwRS-Anforderungen versehentlich direkt auf StRS-IDs; behoben durch Ergänzung dreier
zusätzlicher Bindeglied-Anforderungen SyRS-16, SyRS-25, SyRS-36 sowie Umhängen der betroffenen
`Tracelinks`-Felder). Die konsolidierte `Traceability.md` wurde entsprechend nachgeführt.
**Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk.** Eine vollständige
paarweise Prüfung aller 119 SwRS-Anforderungen gegeneinander war im Rahmen dieser Iteration nicht
leistbar; die folgenden Fälle wurden gezielt identifiziert und im Feld `Konsolidierung` markiert:
| Fall | Beteiligte IDs | Fachlicher Gegenstand |
|---|---|---|
| Stammblatt vs. Asset (Vorgabe der Aufgabenstellung) | StRS-19, SyRS-33, SwRS-100, SwRS-101, SwRS-111 | Kundenhardware (Drucker vs. sonstige Geräte) |
| Fünf strukturell identische `GetSupplier*ByFilter`-Methoden | SwRS-13 | Lieferantenvorgangsarten (Buchung/Gutschrift/Wareneingang/Kalkulation/Anfrage) |
| Vier externe Produktdatenquellen (COP/EGIS/ITscope/Icecat) | SwRS-17 | Externe Artikeldatenanbindung |
| Distributorspezifische EDI-Upload-Methoden | SyRS-4, SwRS-15 | Elektronische Bestellübermittlung |
| Zwei Versanddienstleister (GLS/Shipcloud) | StRS-15, SyRS-28, SwRS-87, SwRS-88 | Versandauftragserstellung |
| Aktionspreis vs. Staffelpreis | SwRS-20 | Sonderpreis je Artikel |
| `Reporting` vs. `ReportEngine` | SwRS-68 | Berichtszugriff/-export |
| `NexusNotifications` vs. `Notifications` | StRS-11, SyRS-22, SwRS-63, SwRS-64 | Benutzerbenachrichtigung |
| `PasswordManagementArea` vs. `PasswordManager` | SwRS-39 | Zugriffskontrolle auf Zugangsdaten |
| `IsUserInAdminGroup` vs. allgemeine Rechteprüfung | SyRS-18 | Administratorstatus vs. Einzelrechte |
| Fünf kanalspezifische Kommunikationsmodule ohne gemeinsame Basis | SyRS-36 | Kommunikations-/Interaktionserfassung |
| Accounts/AccountAddressBL vs. CustomerArea/BusinessPartner-Adressmodell | SwRS-5 | Adressverwaltung |
**Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) -
Belegsituation.** Vollständige Liste aller Anforderungen dieser drei Kategorien mit ihrer
Beleglage:
| ID | Titel | PRIMÄR-Beleg? | Status |
|---|---|---|---|
| StRS-7 | Gruppenbasierte, restriktive Rechteprüfung | ja | belegt |
| StRS-8 | Sichere Authentifizierung (Hash, 2FA, Tokens) | ja | belegt |
| SyRS-1 | Rechnungsfestschreibung (IsFixed) | ja | belegt |
| SyRS-9 | Exportstatus-Flag gegen Doppelexport | ja | belegt |
| SyRS-10 | Bankkontoabgleich, unbekannte IBANs | ja | belegt |
| SyRS-11 | Parallele Kontenrahmen | ja | belegt |
| SyRS-12 | Gruppenbasierte Rechteauflösung | ja | belegt |
| SyRS-13 | Gesalzenes Passwort-Hashing | ja | belegt |
| SyRS-14 | REST-API-Autorisierung | ja | belegt |
| SyRS-15 | TOTP-2FA | ja | belegt |
| SyRS-16 | Geschützte Zugangsdaten-/Zertifikatsverwaltung | ja | belegt |
| SyRS-18 | Administratorstatus getrennt geführt | ja | belegt |
| SwRS-2 | Rechnung festschreiben | ja | belegt |
| SwRS-3 | Rechnung stornieren | ja | belegt |
| SwRS-16 | Zahlungsverfolgung Lieferantenrechnungen | **nein** | **HYPOTHESE** |
| SwRS-25 | Bankverbindung, Autorisierungsfilter | ja | belegt |
| SwRS-26 | FinAPI-Zugangsdaten | ja | belegt |
| SwRS-27 | Unbekannte IBANs erkennen | ja | belegt |
| SwRS-28 | Zahlungsexport mit Statuspflege | ja | belegt |
| SwRS-29 | Kontenrahmenverwaltung | ja | belegt |
| SwRS-30 | Buchhaltungsexport-Konfiguration | ja | belegt |
| SwRS-32 | FinAPI/ebInterface | ja | belegt |
| SwRS-33 | Offene-Posten-Übersicht | ja | belegt |
| SwRS-34 | Programmrechteprüfung | ja | belegt |
| SwRS-35 | Web-Rechteprüfung | ja | belegt |
| SwRS-36 | Passwort-Hashing (SHA1, veraltet) | ja | belegt |
| SwRS-37 | 2FA-PIN-Validierung | ja | belegt |
| SwRS-38 | Zugangsdaten-Entschlüsselung mit Log | ja | belegt |
| SwRS-39 | PasswordManager-Rechtematrix | **nein** | **HYPOTHESE** |
| SwRS-40 | API-Tokens mit Widerruf | ja | belegt |
| SwRS-41 | PDF-Signatur | ja | belegt |
| SwRS-42 | Deklarative REST-Autorisierung | ja | belegt |
| SwRS-43 | Admin-Status/Passwortänderung | ja | belegt |
| SwRS-117 | Buchhaltungsexport-Dateierzeugung | ja | belegt |
| SwRS-118 | Rechtebasierte Modulsichtbarkeit (Ribbon) | ja | belegt |
Ergebnis: **2 von 35** risikorelevanten Anforderungen (SwRS-16, SwRS-39) besitzen keinen
`PRIMÄR`-Beleg; beide wurden gemäß der Vorgabe dieser Iteration korrekt als `[HYPOTHESE]` mit
`Status: HYPOTHESE` geführt statt fälschlich als `belegt`. Kein Verstoß gegen die
risikobasierte Priorisierung wurde festgestellt, der nicht bereits durch die Hypothesenmarkierung
aufgefangen ist.
**Abgleich `Hypothesen.md` gegen Inline-Markierungen.** Es wurden 18 `[HYPOTHESE]`-Markierungen in
StRS/SyRS/SwRS gezählt (0 in StRS, 4 in SyRS: SyRS-7, SyRS-12, SyRS-27, SyRS-28; 14 in SwRS:
SwRS-7, SwRS-10, SwRS-16, SwRS-17, SwRS-20, SwRS-25, SwRS-39, SwRS-54, SwRS-56, SwRS-68, SwRS-70,
SwRS-74, SwRS-78, SwRS-96). `Hypothesen.md` enthält exakt dieselben 18 Einträge, keine zusätzlichen
freien Fragen ohne zugehörige Anforderung. Deckungsgleich.
## Selbstbewertung
**Analysetiefe je Modul (absolute Zahlen).** Von 109 Modulinventar-Zeilen wurden 19 tief, 59
mittel und 27 flach analysiert; 4 wurden nicht analysiert (siehe Begründung im Modulinventar).
Bezogen ausschließlich auf die 90 fachlichen `Centron.BL`-Module: 16 tief (Administration,
BusinessPartner, Core, DataExchange, DocuBoard, EDI, EmployeeArea, Finances,
ObjectExternalReferences, PasswordManagementArea, Processes, Purchasing, Sales, Transactions,
TwoFactorAuthenticator, Warehousing), 50 mittel, 23 flach, 1 nicht analysiert (`Properties`).
**Mindestabdeckung erreicht.** Ja - jedes der 105 analysierten Module trägt mindestens eine
Anforderung; alle 90 Verzeichnisse aus `Centron.BL` sind im Inventar erfasst, `Properties` als
einziges davon explizit als „nicht analysiert" mit Begründung (kein fachlicher Inhalt, nur
`AssemblyInfo.cs`). Die drei weiteren „nicht analysiert"-Zeilen betreffen keine `Centron.BL`-Module,
sondern reine Vertrags-/Utility-Bibliotheken und Build-/Deployment-Infrastruktur außerhalb der
eigentlichen Geschäftslogik.
**Wo der Beleg dünn war.** Die 27 „flach" eingestuften Module tragen überwiegend nur
`SEKUNDÄR`-Belege (einfache, meist lesende CRUD-Methoden ohne im erhobenen Ausschnitt erkennbare
tiefere Geschäftsregel) - typischerweise kleine Utility- oder Konfigurationsmodule
(z. B. `CentronIcons`, `Tools`, `Resources`, `Urls`, `VideoPortal`, `Start`, `SystemArea`,
`Calendar`, `Time`, `Buying`, `Logistics`, `Storage`, `ItPlanner`, `ExternalHelpdesk`,
`ExternalToolsBL`, `Exceptions`, `MailScanner`, `Mailings`, `Notifications`, `ProductMatrix`,
`Projects`, `CentronNexus` (BL-Einstellungen), `Outlook`, `Centron.Host`, `Centron.Controls`,
`CentronNexus.OutlookAddIn`, `c-entron.misc.ConnectionManager`). Über alle 119 SwRS-Anforderungen
hinweg wurden 86 `PRIMÄR`-, 41 `SEKUNDÄR`- und 3 `KONTEXT`-Belege vergeben (rund 66 % `PRIMÄR`).
Bei den 35 als risikorelevant eingestuften Anforderungen (Sicherheit, Abrechnung/Fakturierung,
Berechtigungen) liegt der `PRIMÄR`-Anteil bei 33 von 35 (94 %); die zwei verbleibenden Fälle
(SwRS-16, SwRS-39) sind korrekt als `[HYPOTHESE]`/`Status: HYPOTHESE` geführt statt fälschlich als
belegt - die risikobasierte Priorisierung wurde damit eingehalten.
**Hypothesenführung.** 18 Hypothesen wurden geführt (4 in SyRS, 14 in SwRS), davon 2 mit
`Status: HYPOTHESE` (risikorelevante Aussagen ohne `PRIMÄR`-Beleg), die übrigen 16 als punktuelle
Unsicherheiten innerhalb ansonsten belegter Anforderungen (z. B. offene Berechnungsformeln,
Cache-Invalidierungszeitpunkte, unklare Parameterbedeutung). Bei einer Codebasis dieser Größe
(90 fachliche Module, mehrere Zehntausend Dateien) ist diese Zahl plausibel, aber nach Einschätzung
dieses Laufs eher niedrig angesetzt: Die 59 „mittel" eingestuften Zeilen (davon 50 `Centron.BL`-Module) wurden jeweils nur mit
einer einzigen Anforderung und einem einzigen Methodenausschnitt erhoben: Weitere Vertiefung würde
voraussichtlich zusätzliche offene Fragen zutage fördern, die in dieser Iteration aus Zeit-/
Umfangsgründen nicht mehr untersucht wurden.
**Erkenntnisse für eine Folge-Iteration.**
1. **Vertiefung der 27 „flach" eingestuften Module**, insbesondere `ItPlanner`, `ExternalHelpdesk`
und `CentronNexus` (BL), deren Methodenkörper (nicht nur Signaturen) noch nicht gelesen wurden.
2. **Klärung der beiden offenen Risikofälle** SwRS-16 (Zahlungsstatus-Klassifikation bei
Lieferantenrechnungen) und SwRS-39 (durchsetzende Rechtevergaberegel im `PasswordManager`) -
beide sollten vorrangig vor einer Migrationsentscheidung geklärt werden.
3. **Konsolidierungsanalyse vertiefen**: Die in dieser Iteration identifizierten zwölf
Konsolidierungskandidaten (siehe Konsistenzcheck) sind eine erste, nicht erschöpfende Liste;
eine gezielte, modulübergreifende Cross-Referenz-Analyse (z. B. über Entitätsnamen und
DB-Tabellenverweise) würde voraussichtlich weitere Fälle wie „Stammblatt/Asset" aufdecken.
4. **Sicherheitsbewertung SHA1-Passwort-Hashing (SwRS-36)**: konkreter Migrationsplan auf ein
adaptives Verfahren (Argon2id/bcrypt) inkl. Rehashing-Strategie bestehender Passwörter fehlt
noch und sollte Gegenstand einer eigenen Anforderung in einer Folge-Iteration sein.
5. **Datenbankschema (`SSMS_DB_SCHEMA.sql`, ca. 3,3 MB)** wurde nur punktuell (Stichwortsuche
„Stammblatt") herangezogen, nicht systematisch als eigene Erhebungsquelle für DB-Constraints
(Fremdschlüssel, Check-Constraints, Trigger) ausgewertet - eine solche Auswertung könnte
weitere `PRIMÄR`-Belege für bislang nur `SEKUNDÄR` belegte Datenintegritätsregeln liefern.
6. **Change-Historie/Commit-Messages/Tickets** wurden in dieser Iteration nicht als Artefaktquelle
herangezogen (kein Zugriff auf Ticketsystem/Repository-Historie im Rahmen dieses Laufs
bereitgestellt) - `KONTEXT`-Belege dieser Art fehlen daher fast vollständig (nur 3 von 130
Belegen).
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/Glossar.md
+26
View File
@@ -0,0 +1,26 @@
# Glossar
Domänenbegriffe, wie sie in StRS/SyRS/SwRS verwendet werden. Technische Bezeichner (Klassen,
Methoden, Spalten) sind im Original belassen.
| Begriff | Erläuterung |
|---|---|
| I3D | Primärschlüsselkonvention der Legacy-Datenbank: nahezu jede Entität trägt eine Ganzzahl-Spalte/Property `I3D` als eindeutige ID (z. B. `AppUser.I3D`, `ReceiptInvoice.I3D`). Durchgängig in Entities, DAO und BL sichtbar. |
| Beleg (Receipt) | Sammelbegriff für Vertriebs-/Einkaufsdokumente im Modul `Sales/Receipts` (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Bestellung). Technisch DB-Tabelle `RechKopf`/`RechPos` und Klassenfamilie `Receipt*`. |
| Fixieren / Festschreiben (`IsFixed`) | Zustand einer Rechnung, in dem sie nicht mehr inhaltlich verändert werden kann (Buchhaltungsintegrität). Gesetzt über `RechKopf.IsFixed = 1` in `ReceiptInvoiceBL.FixInvoice` (`src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:100-105`). |
| Sichtrecht / AppRight | Berechtigungseinheit des Legacy-Rechtesystems. Zuordnung erfolgt gruppenbasiert über die DB-Tabellen `Sichtrus` (Gruppe -> Recht) und `Sichmemb` (Benutzer -> Gruppe), ausgewertet in `AppRightsBL.HasUserRight` (`src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:644-649`). Rechte werden als Ganzzahl-ID (I3D) referenziert, z. B. `UserRightsConst.Sales.Customer.Helpdesk.SHOW_HELPDESK` (siehe `CentronRights.md`). |
| Restriktives Recht | In `CentronRights.md` ausdrücklich so bezeichnete Unterart eines Rechts, die den Zugriff eines Benutzers, der es besitzt, zusätzlich einschränkt (z. B. „nur eigene Tickets“), statt ihn zu erweitern. |
| WebRight | Separates Berechtigungssystem für Web-Accounts (Kunden-/Lieferanten-Login im Nexus-Webportal), abgebildet über `WebAccountsRights` und ausgewertet in `AppRightsBL.CheckWebRightsFromUser` (`AppRightsBL.cs:113-130`). Von den internen `AppRight`/`Sichtrecht`-Mitarbeiterrechten fachlich getrennt. |
| BL / DAO | Schichtenkonvention der Codebasis: `*BL`-Klassen (`Centron.BL`) kapseln Geschäftslogik, `Centron.DAO` die NHibernate-basierte Persistenz, `Centron.Entities` das Domänenmodell. |
| Stammblatt | Legacy-Datenobjekt zur Verwaltung von Druckern (siehe Modul `DocuBoard`/`Devices`). Wird laut Vorgabe der Aufgabenstellung im Zielsystem mit dem allgemeinen Asset-Konzept konsolidiert. |
| Asset | Allgemeines Datenobjekt für Kunden-/Firmenhardware außerhalb der Drucker-Stammblätter (Modul `DocuBoard`, Klassen `AssetManagement*BL`). Konsolidierungskandidat mit „Stammblatt“ (siehe Aufgabenstellung). |
| Mandant / Filiale | Organisationseinheiten der ERP-Installation. „Filiale“ (Branch) wird u. a. in restriktiven Rechten referenziert (`SHOW_HELPDESK_ONLY_OWN_BRANCH`, `RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE`, siehe `CentronRights.md`). |
| Nexus | Blazor-basiertes Web-Portal (`src/nexus/CentronNexus`) für Kunden-/Lieferanten-Self-Service (u. a. WebCart, WebOffer, ServiceBoard), getrennt vom WPF-Desktopclient (`Centron.WPF.UI`). |
| WebCart | Nexus-Feature, mit dem Kunden von Kunden („Web-Accounts“) Artikel aus hinterlegten Sonderpreisen bestellen können (laut `README.md` Abschnitt „Contributing“). |
| C-FLOW | Ticketvorlagen-Mechanismus im Helpdesk-Modul (`UserRightsConst...Helpdesk.CFlow.*`, UI unter `Centron.WPF.UI/Modules/Helpdesk/TicketDetails/CFlow`) zur Steuerung von Ticket-Formularen über Vorlagen. |
| RiverDivo | Externes, per REST/Client angebundenes System zur Vertragsartikel-Abrechnung (Modul `RiverDivo`, Klasse `RiverConnectionBL`, Methode `GetContractBillingAmounts`). |
| EDI | Electronic Data Interchange - automatisierter Belegaustausch mit Distributoren/Lieferanten (Alltron, ALSO, ALSO CH, Concerto, EGIS, Komsa, Opentrans 2.1), Modul `EDI` und `Centron.Gateway`. |
| GoBD-Fixierung | Fachlicher Sammelbegriff dieses Analyseberichts für den technischen Mechanismus `IsFixed`/„festschreiben“ bei Rechnungen; verweist auf die handelsrechtliche Anforderung der Unveränderbarkeit gebuchter Belege (Interpretation, nicht im Code benannt - siehe Hypothesen). |
| DTO | Data Transfer Object - Klassen zur Datenübertragung zwischen BL- und WebService-/UI-Schicht (z. B. `AppointmentRequestFilter`, `CalendarRepresentationSettingsDTO`). |
| Ergebnis-/`Result`-Muster | In weiten Teilen der BL verwendetes Rückgabemuster `Result`/`Result<T>` mit `Status`/`Data`/`Message` statt Exceptions für fachliche Fehler (z. B. `TwoFactorAuthenticationBL.ValidateAuthenticationPin`). |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/Hypothesen.md
+26
View File
@@ -0,0 +1,26 @@
# Hypothesen
Sammlung aller mit `[HYPOTHESE]` markierten Aussagen aus StRS/SyRS/SwRS, mit der jeweils offenen
Frage, die zur Bestätigung fehlt. Diese Liste ist deckungsgleich mit den Inline-Markierungen
(siehe Konsistenzcheck in `Analysebericht.md`).
| Anforderungs-ID | Hypothese | Offene Frage zur Bestätigung |
|---|---|---|
| SwRS-7 | Unklar, ob die kundenspezifische Produktbewertung (`ProductMatrix`) in allen Kundensegmenten oder nur bei bestimmten Vertriebspartnerschaften genutzt wird. | Gibt es eine Konfiguration/ein Recht, das die Nutzung der Produktmatrix auf bestimmte Kundentypen einschränkt? |
| SwRS-10 | Unklar, ob RiverDivo ein für die Zielarchitektur weiterhin relevanter externer Anbieter oder ein auslaufender Altvertrag ist. | Gibt es aktuelle Vertrags-/Nutzungsdaten oder Deprecation-Hinweise zu RiverDivo außerhalb des Codes? |
| SwRS-16 | Die konkrete Buchungsregel, die eine ausgehende Zahlung als „ausgehend" bzw. beglichen/offen klassifiziert, ist im erhobenen Codeausschnitt von `SupplierInvoicesBL` nicht auffindbar. | Wo (BL, DB-View, Reporting) wird der Zahlungsstatus einer Lieferantenrechnung tatsächlich ermittelt? |
| SwRS-17 | Unklar, ob alle vier externen Produktdatenquellen (COP, EGIS, ITscope, Icecat) noch aktiv genutzt werden oder einzelne historisch/abgelöst sind. | Welche der vier Anbindungen sind in der aktuellen Produktivkonfiguration tatsächlich aktiv? |
| SyRS-7 | Die genaue Berechnungsformel der Einkaufspreisnachführung (z. B. gleitender Durchschnitt vs. FIFO) ist aus der Methodensignatur von `UpdateArticlePurchasePrice` allein nicht ableitbar. | Welche Bewertungsmethode (gleitender Durchschnitt, FIFO, LIFO) implementiert der Methodenkörper tatsächlich? |
| SwRS-20 | Die Priorisierungsregel zwischen Aktionspreis (`ActionPriceBL`) und Staffelpreis (`ArticleVolumePricesBL`) bei Überschneidung ist im erhobenen Codeausschnitt nicht auffindbar. | Welcher Preis gewinnt, wenn für dieselbe Menge sowohl ein Aktionspreis als auch ein Staffelpreis gültig ist? |
| SwRS-25 | Der auslösende Prozess, der eine Bankverbindung als „autorisiert" markiert, ist im erhobenen Codeausschnitt von `BankAccountBL` nicht auffindbar. | Welcher Workflow (Vier-Augen-Prinzip, Verifikations-E-Mail, manuelle Freigabe) setzt das Autorisierungsmerkmal einer Bankverbindung? |
| SyRS-12 | Der Cache-Invalidierungszeitpunkt von `HasUserRight` bei einer Gruppenänderung war im erhobenen Ausschnitt nicht erkennbar. | Wird der Rechte-Cache bei Gruppenänderung sofort invalidiert, oder kann ein entzogenes Recht bis zum Cache-Ablauf/Neuanmeldung wirksam bleiben? |
| SwRS-54 | Ob das Anlegen einer globalen Ticketansicht ein eigenes Recht voraussetzt, ist im erhobenen Ausschnitt von `NexusTicketViewBL` nicht erkennbar. | Gibt es ein dediziertes Recht für `SaveGlobalView`, oder kann jeder Benutzer globale Ansichten erzeugen? |
| SwRS-56 | Die auslösende Bedingung für „Ticket abgelaufen" (`TicketExpiredException`) ist im erhobenen Codeausschnitt nicht auffindbar. | Welche fachliche Regel (Fristüberschreitung, Kundenstatus, Vertragsende) löst diese Exception tatsächlich aus? |
| SwRS-68 | Ob `Reporting` (ReportsBL) und `ReportEngine` (ReportDataExportBL) zwei unabhängige Berichtssysteme oder Vorder-/Rückseite derselben Funktion sind, war anhand der Modulnamen und Signaturen allein nicht klärbar. | Werden beide Module vom selben UI-Bericht-Dialog verwendet, oder bedienen sie getrennte Anwendungsfälle (z. B. Altsystem vs. aktuelles System)? |
| SwRS-70 | Unklar, ob die Erfassung der `hardwareId` in `TelemetryBL` datenschutzrechtlich als personenbezogenes Datum zu behandeln ist. | Existiert eine Datenschutz-Folgenabschätzung oder Einwilligungsgrundlage für die Hardware-ID-Erfassung? |
| SwRS-74 | Das in `CentronFtpUrls` fest hinterlegte Zugriffstoken der Update-URLs könnte ein Hardcoded-Secret-Befund sein; unklar, ob es ein öffentlich lesbares Freigabeverzeichnis oder ein schützenswertes Token adressiert. | Ist das Token in den vier `CentronFtpUrls`-Konstanten sicherheitskritisch, und wird es rotiert? |
| SyRS-27 | Der konkrete Duplikatsschutz-Mechanismus von `ModuleBL.DoCreateMissingInternalModulesInDB` wurde nur aus dem Methodennamen abgeleitet, nicht im Methodenkörper verifiziert. | Prüft die Methode tatsächlich auf bereits vorhandene Module vor dem Insert, oder verlässt sie sich auf einen Datenbank-Constraint? |
| SwRS-78 | Der fachliche Zweck von `SystemTableI3D` (z. B. globaler ID-Generator vs. Systemstatus) war aus der einzigen erhobenen Methode nicht abschließend erkennbar. | Wofür wird der von `GetSystemTableI3D()` gelieferte Datensatz konkret verwendet? |
| SyRS-28 | Ob Shipcloud einen äquivalenten Testmodus wie GLS (`isTest`-Parameter) besitzt, ist im erhobenen Codeausschnitt von `CentronShipcloudLogic` nicht erkennbar. | Bietet die Shipcloud-Integration einen Sandbox-/Testmodus, oder besteht bei Fehlkonfiguration das Risiko eines versehentlichen Produktivversands? |
| SwRS-96 | Die fachliche Bedeutung des Parameters `mixMode` in `AccountAddressContactWebServiceBL` war aus der Methodensignatur allein nicht klärbar. | Was unterscheidet `mixMode: true` von `false` bei Anlage/Speicherung eines Adresskontakts? |
| SwRS-39 | Risikorelevante Aussage (Berechtigung auf Zugangsdaten) ohne `PRIMÄR`-Beleg - die durchsetzende Rechtevergaberegel hinter `GetPasswordManagerCustomersEmployeesRights` war im erhobenen Ausschnitt nicht einsehbar; gemäß risikobasierter Priorisierung als Hypothese statt als belegt geführt. | Wo (welche Methode/welcher Constraint) setzt tatsächlich durch, dass ein Mitarbeiter nur auf zugeordnete Kunden zugreifen darf? |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/StRS.md
+658
View File
@@ -0,0 +1,658 @@
# StRS - Stakeholder Requirements Specification
c-entron ERP-Suite - Reverse Requirements Engineering, Iteration 02 (2026-08-26)
Fachliche Sicht: Geschäftsziele, Akteure und Erwartungen der Stakeholder, abgeleitet aus der
Codebasis (statische Analyse, keine Ausführung). Jede Anforderung folgt dem in `01_Prompt.md`
vorgegebenen Blockformat. Domänenbegriffe sind in `Glossar.md` erläutert.
## Domäne D1: Vertrieb & Kundenbeziehungsmanagement
```
ID: StRS-1
Titel: Durchgängige Belegkette vom Angebot bis zur festgeschriebenen Rechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertriebsmitarbeiter, Innendienst
Vorbedingung: Ein Kunde (Account) existiert im System.
Fakt: Das Modul `Sales/Receipts` bildet Angebot, Auftrag, Lieferschein, Rechnung und
Gutschrift als zusammenhängende Klassenfamilie ab (`ReceiptBL.cs`,
`Invoices/ReceiptInvoiceBL.cs`, `CreditVouchers/ReceiptCreditVoucherBL.cs`,
`DataAndResults/ForwardReceipt/ForwardReceiptResult.cs`,
`DataAndResults/CreateReceipt/CreateReceiptResult.cs`); Rechnungen werden über
`RechKopf.IsFixed` festgeschrieben (`ReceiptInvoiceBL.FixInvoice`).
Aussage: Das System soll Vertriebsmitarbeitern erlauben, aus einem Kundenvorgang lückenlos
ein Angebot zu erstellen, es in Auftrag, Lieferschein und Rechnung zu überführen
(Belegweiterleitung) und die Rechnung nach Erstellung buchhalterisch unveränderbar
festzuschreiben.
Ergebnis: Ein durchgängiger, nachvollziehbarer Beleg-Lebenszyklus mit einer nach Festschreibung
unveränderbaren Rechnung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:86-105 (FixInvoice, UPDATE RechKopf SET IsFixed = 1) - Begründung: setzt die durchsetzende Sperre der Rechnungsänderung im BL-Code.
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/DataAndResults/ForwardReceipt/ForwardReceiptResult.cs - Begründung: Klassenname und Ordnerstruktur belegen die Belegweiterleitungsfunktion.
- [KONTEXT] src/backend/Centron.BL/Sales/Receipts/ (Ordnerstruktur: ContractLists, CreditVouchers, DeliveryLists, Invoices, SupplierInvoices) - Begründung: zeigt die fachliche Breite der Belegarten im selben Modul.
Prüfidee: Angebot anlegen, in Auftrag/Lieferschein/Rechnung überführen, `FixInvoice` aufrufen und
anschließend einen Änderungsversuch an der Rechnung durchführen - dieser muss
fachlich abgewiesen werden.
Tracelinks: SyRS-1, SyRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess jeder ERP-Neuimplementierung.
Status: belegt
```
```
ID: StRS-2
Titel: Kundenstammdaten, Vorgänge und Rücksendungen (RMA) zentral verwalten
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertriebsinnendienst, Hotline-Mitarbeiter
Vorbedingung: Kunde ist als Account angelegt.
Fakt: `AccountBL`/`AccountAddressBL` verwalten Kundenstamm- und Adressdaten; `RmaBL`
(81-709) bildet einen mehrstufigen Rücksendeprozess (Rma, RmaArticle, RmaSendForth,
RmaSendBack) ab; `HotlineBL` verwaltet kundenbezogene Hotline-Verträge.
Aussage: Das System soll Kundenstammdaten, zugehörige Ansprechpartner, Hotline-Verträge und
Rücksendevorgänge (RMA) inklusive Versand an und von Lieferanten in einem
durchgängigen Vorgang je Kunde verwalten.
Ergebnis: Ein vollständiger, historisierter Blick auf Kundenbeziehung, Verträge und
Rücksendungen je Account.
Belege:
- [PRIMÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs:347,603,685,692 (SaveRma, CreateNewRmaArticle, GetRmaSendForthByI3D, GetRmaSendBackByI3D) - Begründung: konkrete Methoden für Anlage und Versandrichtungen der Rücksendung.
- [SEKUNDÄR] src/backend/Centron.BL/Accounts/HotlineBL.cs:21-38 (GetHotlineByI3D, GetHotlinesFromCustomerByI3D, SaveHotline) - Begründung: UI-nahe Zugriffsmethoden auf kundenbezogene Hotline-Verträge.
- [KONTEXT] src/backend/Centron.BL/Accounts/ (Unterordner AccountContracts, Activities, Campaigns, ExtendedFilters, Marketing) - Begründung: belegt Breite der Kundendatenverwaltung im Modul.
Prüfidee: Für einen Account eine RMA anlegen, einen RmaArticle erfassen und den Versand an den
Lieferanten (RmaSendForth) sowie den Rückversand (RmaSendBack) dokumentieren.
Tracelinks: SyRS-3
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kundenbindung und Reklamationsprozess sind zentrale ERP-Funktionen.
Status: belegt
```
## Domäne D2: Einkauf & Lieferantenmanagement
```
ID: StRS-3
Titel: Bestellvorschläge, EDI-Bestellungen und Lieferantenrechnungen verwalten
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Einkaufsmitarbeiter
Vorbedingung: Lieferanten und Artikel sind im System erfasst.
Fakt: `OrderSuggestionListBL` erzeugt Bestellvorschläge; `EDIDispatcherBL` erzeugt und
versendet elektronische Bestelldokumente an mehrere Distributoren (Alltron, ALSO,
EGIS, ITscope, Komsa, Concerto); `SupplierInvoicesBL` verwaltet ausgehende Zahlungen
zu Lieferantenrechnungen.
Aussage: Das System soll aus Lagerbestand und Bedarf automatisierte Bestellvorschläge
erzeugen, diese wahlweise elektronisch (EDI) an angebundene Distributoren übermitteln
und die daraus resultierenden Lieferantenrechnungen inklusive Zahlungshistorie
nachverfolgen.
Ergebnis: Ein durchgängiger Einkaufsprozess von der Bedarfsermittlung über die elektronische
Bestellung bis zur Zahlungsverfolgung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs:56,213,290 (CreateEDISuggestionOrderAsync, EdiConcertoOrderUploadAsync, KomsaArticleCheckAsync) - Begründung: durchsetzende, distributorspezifische Versandmethoden.
- [SEKUNDÄR] src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs:430-432 (GetOrderSuggestionArticle, GetArticlePerItems, GetOrderSuggestionOrder) - Begründung: UI-nahe Abrufmethoden für Bestellvorschläge.
- [KONTEXT] src/backend/Centron.BL/Sales/Receipts/SupplierInvoices/SupplierInvoicesBL.cs:38,98 (GetOutgoingPaymentReceiptItemsThroughPaging, GetOutgoingPaymentsHistoryThroughPaging) - Begründung: zeigt Existenz der Zahlungsnachverfolgung, ohne im erhobenen Ausschnitt eine durchsetzende Buchungsregel zu belegen.
Prüfidee: Aus einem Lagerbestand unterhalb des Meldebestands einen Bestellvorschlag erzeugen,
daraus eine EDI-Bestellung an einen konfigurierten Distributor erzeugen und die
resultierende Lieferantenrechnung in der Zahlungshistorie wiederfinden.
Tracelinks: SyRS-4, SyRS-5
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess der Warenbeschaffung.
Status: belegt
```
## Domäne D3: Lager, Artikel & Produktion
```
ID: StRS-4
Titel: Artikelbestand, Preisfindung und Produktionsaufträge verwalten
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Lager-/Einkaufs-/Produktionsmitarbeiter
Vorbedingung: Artikelstamm existiert.
Fakt: `ArticleStockBL` führt Bestände je Artikel/Lager (`UpdateArticleStock`,
`IncreaseArticleStock`) und passt Einkaufspreise nach (`UpdateArticlePurchasePrice`
mit `oldQuantity`/`quantity`/`purchasePrice`); `ArticleVolumePricesBL.GetVolumePrice`
wählt die höchste zutreffende Staffelmenge; `ProductionOrderBL` verwaltet
Produktionsaufträge mit eigener Log-Historie.
Aussage: Das System soll Artikelbestände je Lagerort führen, bei Wareneingang den
Einkaufspreis mengengewichtet nachführen, mengenabhängige Staffelpreise automatisch
ermitteln und Produktionsaufträge inklusive Statusprotokoll verwalten.
Ergebnis: Aktueller, lagerortgenauer Bestand mit nachgeführtem Einkaufspreis; korrekt
ermittelter Staffelpreis je Bestellmenge; nachvollziehbarer Produktionsauftragsverlauf.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs:47-74 (UpdateArticleStock, IncreaseArticleStock, UpdateArticlePurchasePrice) - Begründung: durchsetzende Bestands- und Preisänderungsmethoden.
- [PRIMÄR] src/backend/Centron.BL/Warehousing/ArticleVolumePricesBL.cs:88-97 (GetVolumePrice: OrderByDescending(FromAmount).FirstOrDefault(FromAmount <= amount)) - Begründung: konkrete, durchsetzende Auswahlregel für Staffelpreise.
- [SEKUNDÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs:45,122,194 (SaveProductionOrder, SaveProductionOrderItem, SaveProductionOrderLog) - Begründung: UI-nahe Speichermethoden mit begleitender Log-Funktion.
Prüfidee: Wareneingang mit abweichendem Einkaufspreis buchen und die Nachführung des
gewichteten Einkaufspreises prüfen; Bestellmenge über und unter einer Staffelgrenze
anfragen und jeweils den korrekten Preis erhalten.
Tracelinks: SyRS-6, SyRS-7, SyRS-8
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Bestands- und Preisführung sind Kernfunktionen jeder Warenwirtschaft.
Status: belegt
```
## Domäne D4: Finanzbuchhaltung & Zahlungsverkehr (risikorelevant)
```
ID: StRS-5
Titel: Zahlungsverkehr mit exportsicherem SEPA-/Lastschrift-Export
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Finanzbuchhaltung
Vorbedingung: Fällige Rechnungen mit Zahlungsdaten existieren.
Fakt: `PaymentTransactionBL.ExportInvoices(...)` erzeugt einen Zahlungsexport;
`SetInvoicesAsExported(int employeeI3D, int invoiceI3D)` und
`ResetInvoiceExportedFlag(AppUser, List<int> incomingPaymentLogI3Ds)` verwalten ein
explizites Exportiert-Flag je Rechnung.
Aussage: Das System soll Rechnungen für den Zahlungsexport (z. B. SEPA-Lastschrift) markieren,
nach erfolgreichem Export eindeutig als exportiert kennzeichnen und diese Markierung
nur über eine dedizierte, protokollierte Funktion zurücksetzen können.
Ergebnis: Rechnungen werden nicht unbeabsichtigt doppelt in einen Zahlungsexport aufgenommen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs:291,296 (SetInvoicesAsExported, ResetInvoiceExportedFlag) - Begründung: durchsetzende Stelle, die den Exportstatus einer Rechnung explizit setzt bzw. zurücksetzt.
- [PRIMÄR] src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs:93,132 (GetInvoiceList mit showOnlyExportedInvoices-Filter, ExportInvoices) - Begründung: zeigt, dass der Exportstatus die Grundlage für die Selektion exportierbarer Rechnungen bildet.
Prüfidee: Rechnung exportieren, danach erneut in `GetInvoiceList(showOnlyExportedInvoices:
false)` abfragen - sie darf dort nicht mehr als „nicht exportiert" erscheinen, bis
`ResetInvoiceExportedFlag` aufgerufen wurde.
Tracelinks: SyRS-9, SyRS-10
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Doppelexportschutz ist eine zwingende Anforderung an jeden Zahlungsverkehr.
Status: belegt
```
```
ID: StRS-6
Titel: Kontenrahmen und Buchhaltungsexport konfigurierbar an FiBu-Systeme anbinden
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Finanzbuchhaltung, Steuerberater
Vorbedingung: Ein Buchhaltungssystem (z. B. DATEV/GDI) ist als Zielsystem vorgesehen.
Fakt: `BookKeepingAccountSystemsBL` verwaltet mehrere parallele Kontenrahmen
(`GetBookKeepingAccountSystems`, `SaveBookKeepingAccountSystem`) mit zugehörigen
Konten (`GetBookKeepingAccounts(bool fromDefaultSystem)`); `BookKeepingExportBL`
speichert Exporteinstellungen je Konfiguration.
Aussage: Das System soll mehrere Kontenrahmen parallel verwalten und den Buchhaltungsexport je
Kontenrahmen konfigurierbar machen, um unterschiedliche Buchhaltungssysteme/-berater
zu bedienen.
Ergebnis: Ein exportierter Buchungssatz, der dem gewählten Kontenrahmen und Zielformat
entspricht.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/BookKeepingAccountSystems/BookKeepingAccountSystemBL.cs:24-81 (GetBookKeepingAccountSystems, SaveBookKeepingAccountSystem, GetBookKeepingAccounts mit fromDefaultSystem-Flag) - Begründung: durchsetzende Verwaltung mehrerer Kontenrahmen.
- [SEKUNDÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs:142-144 (SaveExportSettings, LoadExportSettings, GetCustomInterfaceSettings) - Begründung: begleitende Exportkonfiguration.
Prüfidee: Zwei Kontenrahmen anlegen, je einen Buchungsexport konfigurieren und für dieselbe
Rechnung unterschiedliche Kontonummern im jeweiligen Export prüfen.
Tracelinks: SyRS-11
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D10: Sicherheit, Zugriffsschutz & Berechtigungen (risikorelevant)
```
ID: StRS-7
Titel: Gruppenbasierte, restriktive Rechteprüfung für Programm- und Web-Zugriff
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Systemadministrator, alle Mitarbeiter, Web-Accounts
Vorbedingung: Benutzer ist angemeldet.
Fakt: `AppRightsBL.HasUserRight(int appUserI3D, int rightID)` prüft Rechte über die
DB-Tabellen `Sichtrus`/`Sichmemb` (Gruppenmitgliedschaft); `CheckWebRightsFromUser`
prüft getrennt davon `WebAccountsRights`; `CentronRights.md` dokumentiert zusätzlich
„restriktive Rechte", die den Zugriff eines Rechteinhabers einschränken statt
erweitern.
Aussage: Das System soll jeden funktionalen Zugriff - sowohl im Desktop-Client als auch im
Web-Portal - gegen ein gruppenbasiertes Rechtesystem prüfen und dabei zwischen
erweiternden und restriktiven Rechten unterscheiden.
Ergebnis: Ein Benutzer ohne das erforderliche Recht wird von der Funktion ausgeschlossen; ein
Benutzer mit restriktivem Recht sieht nur die dafür vorgesehene Teilmenge (z. B. nur
eigene Tickets).
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:644-649 (HasUserRight: Join Sichtrus/Sichmemb) - Begründung: durchsetzende, konkrete Rechteprüfung mit Datenbankquelle.
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:113-130 (CheckWebRightsFromUser: WebAccountsRights) - Begründung: getrennte, durchsetzende Prüfung für Web-Accounts.
- [KONTEXT] CentronRights.md:9-12 (Beispiel „restriktives Recht" SHOW_HELPDESK_ONLY_OWN) - Begründung: dokumentiert die fachliche Bedeutung restriktiver Rechte, ohne selbst durchsetzend zu sein.
Prüfidee: Benutzer ohne Recht X von einer Funktion ausschließen; Benutzer mit restriktivem
Recht „nur eigene" auf eine Teilmenge der Datensätze einschränken und beides gegen
`HasUserRight` verifizieren.
Tracelinks: SyRS-12, SyRS-14
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - rollenbasierte Zugriffskontrolle ist für jede ERP-Neuimplementierung zwingend.
Status: belegt
```
```
ID: StRS-8
Titel: Sichere Authentifizierung von Mitarbeitern über Passwort, Zwei-Faktor und persönliche API-Tokens
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Mitarbeiter, Systemadministrator
Vorbedingung: Benutzerkonto existiert.
Fakt: `CryptoUtils.CreatePasswordHash(pwd, salt)` hasht Passwörter gesalzen mit SHA1;
`TwoFactorAuthenticationBL.ValidateAuthenticationPin` prüft einen TOTP-Code gegen
einen hinterlegten Schlüssel; `AccessTokenBL` verwaltet persönliche API-Tokens mit
vollem Lebenszyklus (`CreatePersonalToken`, `Activate`, `Deactivate`, `Delete`,
`ValidateToken`, `HashToken`) inklusive IP-Adressparameter.
Aussage: Das System soll Mitarbeiterkonten über ein gesalzenes Passwort-Hashing, optional
zusätzlich über einen Zwei-Faktor-Code, und für programmatischen Zugriff über
widerrufbare persönliche API-Tokens mit IP-Nachvollziehbarkeit absichern.
Ergebnis: Ein Anmeldeversuch wird nur mit korrektem Passwort-Hash (und ggf. korrektem
TOTP-Code) bzw. gültigem, nicht deaktiviertem Token akzeptiert.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Core/CryptoUtils.cs:15-33 (CreateSalt, CreatePasswordHash mit SHA1) - Begründung: durchsetzende Passwort-Hashing-Implementierung.
- [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs:43-54 (ValidateAuthenticationPin) - Begründung: durchsetzende TOTP-Prüfung mit expliziter Fehlermeldung.
- [PRIMÄR] src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs:125-480 (voller Token-Lebenszyklus inkl. HashToken, ValidateToken mit ipAddress) - Begründung: durchsetzende, vollständige Token-Verwaltung.
Prüfidee: Anmeldung mit falschem Passwort-Hash ablehnen; TOTP-Code außerhalb des Zeitfensters
ablehnen; deaktivierten API-Token gegen `ValidateToken` prüfen (muss fehlschlagen).
Tracelinks: SyRS-13, SyRS-15
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Authentifizierung bleibt erforderlich; die konkrete Hash-Methode (SHA1 ohne Schlüsselstreckung) sollte in der Zielarchitektur durch einen modernen, adaptiven Algorithmus (z. B. Argon2id/bcrypt) ersetzt werden (siehe SwRS-36).
Status: belegt
```
## Domäne D5: Personalverwaltung & Zeitwirtschaft
```
ID: StRS-9
Titel: Mitarbeiterkonten mit Administratorstatus, Zeit- und Terminverwaltung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Personalabteilung, Systemadministrator
Vorbedingung: Mitarbeiter ist angelegt.
Fakt: `AppUserBL.IsUserInAdminGroup(AppUser appUser)` prüft Administratorstatus getrennt
von regulären Rechten; `SaveOrUpdateAppUser(AppUser, AppUser loggedInUser, string
newPassword = null)` erlaubt optionale Passwortänderung im selben Aufruf;
`TimingSettingsBL` und `CalendarBL` verwalten Arbeitszeitmodelle bzw.
Kalenderdarstellung; `AppointmentRequestBL` verwaltet externe Terminanfragen.
Aussage: Das System soll Mitarbeiterkonten inklusive Administratorstatus verwalten, deren
Zeitmodell (Arbeitszeit) und Kalender führen und externe Terminanfragen (z. B. von
Kunden) in den internen Kalender überführen können.
Ergebnis: Ein Mitarbeiterkonto mit korrektem Admin-/Nutzerstatus, Zeitmodell und Kalender.
Belege:
- [PRIMÄR] src/backend/Centron.BL/EmployeeArea/AppUserBL.cs:136,247 (SaveOrUpdateAppUser mit newPassword-Parameter, IsUserInAdminGroup) - Begründung: durchsetzende Methoden mit sicherheitsrelevanter Statusprüfung.
- [SEKUNDÄR] src/backend/Centron.BL/Time/TimingSettingsBL.cs:583-585 (GetTimingSettings, GetTimingSettingsByFilter) - Begründung: UI-nahe Zugriffsmethoden auf Zeitmodelle.
- [KONTEXT] src/backend/Centron.BL/AppointmentRequests/AppointmentRequestBL.cs:29 (HandleAppointmentRequestReply) - Begründung: zeigt Existenz der externen Terminanfrage-Verarbeitung.
Prüfidee: Mitarbeiter mit Administratorstatus anlegen, `IsUserInAdminGroup` prüfen, danach
über `SaveOrUpdateAppUser` das Passwort ändern und die Wirksamkeit der Änderung
prüfen.
Tracelinks: SyRS-18, SyRS-19
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D6: Kundenservice, Ticketing & Support
```
ID: StRS-10
Titel: Ticketbasierten Kundenservice mit Checklisten, Fristen, Tags und Ticketprojekten abwickeln
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Helpdesk-Mitarbeiter, Kunde (extern)
Vorbedingung: Kunde/Vorgang ist erfasst.
Fakt: `CentronRights.md` beschreibt einen Ticket-Lebenszyklus mit Fälligkeit
(`MATURITY_CHANGE`), Abschluss (`CLOSE_REQUEST`) und Checklisten
(`CentronChecklistBL`); `TagsBL.AddTicketTag(int helpdeskI3D, string caption,
LoggedInUser)` ordnet Tickets Schlagworte zu; `TicketProjectBL` gruppiert Tickets in
Projekte mit Abhängigkeiten; `TicketExpiredException` signalisiert abgelaufene
Tickets.
Aussage: Das System soll Support-Vorgänge als Tickets mit Fälligkeit, Checklisten, freien
Schlagworten (Tags) und optionaler Projektgruppierung führen und einen fachlichen
Ablauf-/Exception-Zustand für überfällige Tickets kennen.
Ergebnis: Ein Ticket mit vollständigem Lebenszyklus (Anlage, Bearbeitung, Fristen, Abschluss)
und optionaler Verknüpfung zu Checkliste, Tags und Projekt.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Tags/TagsBL.cs:538 (AddTicketTag mit helpdeskI3D-Bezug) - Begründung: durchsetzende Verknüpfung Tag <-> Ticket.
- [SEKUNDÄR] CentronRights.md:37-44 (MATURITY_CHANGE, CLOSE_REQUEST) - Begründung: dokumentiert den fachlich vorgesehenen Ablauf, ohne selbst Code zu sein.
- [KONTEXT] src/backend/Centron.BL/Exceptions/TicketExpiredException.cs:1-6 (Ticket-Property) - Begründung: zeigt Existenz eines Ablauf-Zustands.
Prüfidee: Ticket anlegen, Checkliste zuordnen, Tag vergeben, Fälligkeit ändern, Ticketprojekt
zuordnen und abschließend das Ticket abschließen; jeder Schritt muss über die
jeweilige Komponente nachvollziehbar sein.
Tracelinks: SyRS-17, SyRS-20
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Ticketing ist Kernprozess des Kundenservice.
Status: belegt
```
## Domäne D7: Kommunikation (Mail, Chat, Telefonie, Social Media, Benachrichtigungen)
```
ID: StRS-11
Titel: Kanalübergreifende Kommunikation mit Kunden und im Team abwickeln
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mitarbeiter, Kunde
Vorbedingung: Kommunikationskanal ist konfiguriert.
Fakt: Das System bietet eigenständige Module für E-Mail (`Mail`, `MailScanner`,
`Mailings`), Team-Chat (`ChatBL.CreateChat`/`AddMemberToChat`), Telefonie
(`PhoneCallBL.CreatePhoneCall`), Social-Media-Interaktion
(`SocialMediaBL.AddCommentToASocialMediaAction`) sowie zentrale Benachrichtigungen
(`CentronNotificationsBL`, `NexusNotificationsBL`).
Aussage: Das System soll Kommunikation über mehrere Kanäle (E-Mail, Chat, Telefon, Social
Media) erfassen und protokollieren sowie kanalübergreifend über ein zentrales
Benachrichtigungssystem auf relevante Ereignisse hinweisen.
Ergebnis: Ein nachvollziehbarer Kommunikationsverlauf je Kanal und eine konsolidierte
Benachrichtigungsübersicht je Benutzer.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Chats/ChatBL.cs:97-98 (CreateChat, AddMemberToChat) - Begründung: durchsetzende Chat-Kernfunktionen.
- [PRIMÄR] src/backend/Centron.BL/Tapi/PhoneCallBL.cs:545 (CreatePhoneCall) - Begründung: durchsetzende Telefonieprotokollierung.
- [SEKUNDÄR] src/backend/Centron.BL/Notifications/CentronNotificationsBL.cs:359 (GetCentronNotificationsByFilter) - Begründung: zentrale, kanalübergreifende Benachrichtigungsabfrage.
Prüfidee: Über drei unterschiedliche Kanäle (Chat, Telefon, Mail) mit demselben Kunden
kommunizieren und prüfen, ob alle drei Interaktionen im jeweiligen Modul
nachvollziehbar sind.
Tracelinks: SyRS-21, SyRS-22
Konsolidierung: Kandidat: `NexusNotifications` und `Notifications` bilden beide
„Benutzerbenachrichtigung" ab und sind auf Konsolidierbarkeit im Zielsystem zu prüfen.
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D8: Berichtswesen, Volltextsuche & Nutzungstelemetrie
```
ID: StRS-12
Titel: Berichte erzeugen, exportieren und Systeminhalte volltextdurchsuchbar machen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Alle Mitarbeiter, Systemadministrator
Vorbedingung: Berichte/Datenobjekte existieren.
Fakt: `ReportsBL.GetReport(id)`/`GetReport(predicate)` liefert Berichte;
`ReportDataExportBL.ExportAllReports(ReportGroup, string path)` exportiert
Berichtsgruppen; `IndexSearchBL.SearchIndex(string searchText,
CentronObjectKindNumeric? kind)` durchsucht alle indizierten Objekttypen;
`TelemetryBL.RecordArtificialIntelligenceToolUsage` protokolliert KI-Werkzeugnutzung.
Aussage: Das System soll Berichte definieren, gruppieren und exportieren, beliebige
Objekttypen volltextdurchsuchbar machen und die Nutzung interner Werkzeuge
(insbesondere KI-Funktionen) zu Auswertungszwecken protokollieren.
Ergebnis: Exportierte Berichte, ein durchsuchbarer Gesamtindex, eine Nutzungsstatistik.
Belege:
- [PRIMÄR] src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs:250 (SearchIndex, objektübergreifend) - Begründung: durchsetzende, zentrale Suchmethode.
- [SEKUNDÄR] src/backend/Centron.BL/ReportEngine/ImportExport/ReportDataExportBL.cs:438-440 - Begründung: begleitende Exportfunktion.
- [KONTEXT] src/backend/Centron.BL/Telemetry/TelemetryBL.cs:561-563 - Begründung: zeigt Existenz der Nutzungstelemetrie, nicht direkt Bestandteil des Berichtswesens im engeren Sinn.
Prüfidee: Neues Objekt anlegen, Index aktualisieren lassen (`UpdateRequestedIndexes`) und
über `SearchIndex` auffindbar machen; parallel einen Bericht dieser Objektklasse
exportieren.
Tracelinks: SyRS-23, SyRS-24
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D9: Dokumenten- & Textvorlagenmanagement
```
ID: StRS-13
Titel: Interne Dokumentation und Textbausteine rechteabhängig verwalten
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mitarbeiter, Systemadministrator
Vorbedingung: keine
Fakt: `DocumentationBL.GetDocumentation(List<Filter>, AppUser currUser, bool checkRight =
true)` und `GetDocumentationByStatus(AppUser, int status = 1, bool checkRight =
true)` führen einen expliziten, standardmäßig aktiven Rechtecheck-Parameter;
`SalutationAndAgreementReplacementBL.ReplaceSalutationAndAgreement<TAsset,TItem>`
ersetzt Anrede-/Vereinbarungsplatzhalter generisch für unterschiedliche
Belegtypen; `PdfInteractionBL.MergePdfFiles` führt PDF-Dokumente zusammen.
Aussage: Das System soll interne Dokumentationsartikel standardmäßig rechteabhängig
anzeigen (Opt-out über `checkRight: false` nur für privilegierte interne
Aufrufe), Anrede-/Vereinbarungstexte generisch über verschiedene Belegtypen hinweg
ersetzen und PDF-Dokumente zu einem Gesamtdokument zusammenführen können.
Ergebnis: Ein Mitarbeiter sieht nur Dokumentationsartikel, für die er berechtigt ist; ein
Textbaustein liefert für unterschiedliche Belegtypen konsistent ersetzte Werte.
Belege:
- [PRIMÄR] src/backend/Centron.BL/DocumentationArea/DocumentationBL.cs:165-166 (checkRight-Parameter mit Default true) - Begründung: durchsetzender, standardmäßig aktiver Rechtecheck direkt in der Methodensignatur.
- [SEKUNDÄR] src/backend/Centron.BL/TextModuleArea/SalutationAndAgreementReplacementBL.cs:569 (ReplaceSalutationAndAgreement, generisch über TAsset/TItem) - Begründung: zeigt die generische, belegtypübergreifende Ersetzung.
Prüfidee: Dokumentationsartikel ohne zugehöriges Recht abrufen (`checkRight: true`, Standard)
- darf nicht erscheinen; mit `checkRight: false` versuchen (nur aus internem,
privilegiertem Kontext zulässig) - muss erscheinen.
Tracelinks: SyRS-26
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D11: Systemadministration, Modul- & Konfigurationsverwaltung
```
ID: StRS-14
Titel: System zentral konfigurieren, Module verwalten und Massenänderungen kontrolliert durchführen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Systemadministrator
Vorbedingung: keine
Fakt: `ModuleBL.DoCreateMissingInternalModulesInDB(List<ModuleClass>)` synchronisiert
den Modulkatalog der Datenbank mit dem Code; `CustomTableBL` erlaubt kundenspezifische
Zusatztabellen; `MassUpdateBL` führt gespeicherte Massenänderungsvorlagen aus;
`CachedTableBL.RequestImmediateCacheUpdate`/`ExecuteCacheUpdates` steuern
System-Caches.
Aussage: Das System soll seinen Modulkatalog automatisch mit dem Code synchron halten,
kundenspezifische Zusatztabellen unterstützen, wiederverwendbare
Massenänderungsvorlagen ausführen und zentrale Caches gezielt aktualisierbar
machen.
Ergebnis: Ein konsistenter Modulkatalog, angewendete Massenänderungen, aktuelle System-Caches.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Modules/ModuleBL.cs:317 (DoCreateMissingInternalModulesInDB) - Begründung: durchsetzende Synchronisationsmethode.
- [PRIMÄR] src/backend/Centron.BL/Services/CachedTableBL.cs:495-496 (RequestImmediateCacheUpdate, ExecuteCacheUpdates) - Begründung: durchsetzende Cache-Steuerung.
- [SEKUNDÄR] src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs:301-303 - Begründung: begleitende Vorlagenverwaltung.
Prüfidee: Neues Modul im Code registrieren, `DoCreateMissingInternalModulesInDB` ausführen und
prüfen, dass genau ein neuer Datenbankeintrag entsteht (keine Duplikate bei
wiederholtem Aufruf).
Tracelinks: SyRS-27
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D12: Externe Integrationen & Versanddienstleister
```
ID: StRS-15
Titel: Externe Werkzeuge, Kundenportale und Versanddienstleister anbinden
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Systemadministrator, Vertriebs-/Lagermitarbeiter
Vorbedingung: Externer Dienst ist konfiguriert.
Fakt: `CPraConnectorBL.ConnectToCPra(username, password)` authentifiziert gegen ein
externes Kundenportal (CPra) und liefert Webhooks; `CentronGlsLogic.UploadShipment`
und `CentronShipcloudLogic.CreateShipmentAsync` erzeugen Versandaufträge bei zwei
unterschiedlichen Versanddienstleistern; `ExternalToolBL` verwaltet frei
konfigurierbare externe Werkzeuge; `CustomGatewayBL` verwaltet
Artikel-Vertrags-Importe für kundenspezifische Gateways; `EsCustomerGroupBL`
synchronisiert Kundengruppen mit einem externen System (`GetByExternalId`).
Aussage: Das System soll externe Werkzeuge und Portale konfigurierbar einbinden,
Versandaufträge bei mehreren Versanddienstleistern parallel erzeugen können und
Kundengruppen mit externen Systemen über eine externe ID synchron halten.
Ergebnis: Ein bei GLS oder Shipcloud erzeugter Versandauftrag mit Tracking-Information; eine
synchronisierte Kundengruppe.
Belege:
- [PRIMÄR] src/apis/Centron.Api.Gls/CentronGlsLogic.cs:15 (UploadShipment) - Begründung: durchsetzende Versandauftragserstellung.
- [PRIMÄR] src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs:66 (CreateShipmentAsync) - Begründung: durchsetzende, parallele Versandauftragserstellung bei zweitem Dienstleister.
- [SEKUNDÄR] src/backend/Centron.BL/Integrations/EsCustomerGroupBL.cs:257 (GetByExternalId) - Begründung: zeigt externe ID-basierte Synchronisation.
Prüfidee: Denselben Versandauftrag testweise bei GLS und Shipcloud erzeugen und beide
Ergebnisse (Tracking-ID) vergleichen.
Tracelinks: SyRS-28
Konsolidierung: Kandidat: `CentronGlsLogic` und `CentronShipcloudLogic` bilden beide „Versandauftrag
erzeugen" ab - im Zielsystem über eine gemeinsame Versanddienstleister-Abstraktion
konsolidierbar.
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D13: Projekt-, Prozess- & Tagesplanung
```
ID: StRS-16
Titel: Generische Geschäftsprozesse, Projekte und persönliche Tagesplanung abbilden
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mitarbeiter, Projektleiter
Vorbedingung: keine
Fakt: `ProcessBL.GetProcess<T>(int objectI3D, CentronObjectKindNumeric objectKind)` bindet
generische Prozessdefinitionen (`ProcessDTO`) an beliebige Fachobjekte;
`ProjectBL.GetProjectList(DateTime? filter)` liefert Projekte; `MyDayBL.
SaveWorkItemBatch` und `DashboardContainerBL.RegisterDashboardContainer` bilden die
persönliche Tagesplanung bzw. das individualisierbare Dashboard.
Aussage: Das System soll Geschäftsprozesse generisch, unabhängig vom konkreten Fachobjekt,
modellieren, Projekte zeitlich filterbar verwalten und jedem Mitarbeiter eine
individuelle Tagesplanung mit konfigurierbarem Dashboard bereitstellen.
Ergebnis: Ein an ein Fachobjekt gebundener Prozessablauf; eine gefilterte Projektliste; eine
personalisierte Tagesansicht.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Processes/ProcessBL.cs:397-399 (generische GetProcess<T>/GetProcesses<T>) - Begründung: durchsetzende, objekttypunabhängige Prozessbindung.
- [SEKUNDÄR] src/backend/Centron.BL/MyDay/MyDayBL.cs:335 (SaveWorkItemBatch) - Begründung: begleitende Tagesplanungsfunktion.
Prüfidee: Denselben Prozess an ein Ticket und an ein Projekt binden und prüfen, dass
`GetProcess<T>` in beiden Fällen konsistent funktioniert.
Tracelinks: SyRS-29
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D14: Self-Service-Portal, Web-Kanäle & mobile Anbindung
```
ID: StRS-17
Titel: Kunden-Self-Service, mobile Mitarbeiteranbindung und Outlook-Integration über das Web-Portal
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Kunde (Web-Account), Außendienstmitarbeiter, Bürokraft mit Outlook
Vorbedingung: Web-Account bzw. mobiles Gerät ist eingerichtet.
Fakt: `SelfCareBL` verwaltet konfigurierbare Selbstbedienungsformulare
(`SelfCareForm`); `MobileBL.GetMobileEmployee` stellt Mitarbeiterdaten für mobile
Clients bereit; `CentronNexus.OutlookAddIn` (Modell `Attachment`) integriert
Outlook direkt mit dem Nexus-Portal; `CentronNexusBL` verwaltet
portalweite Einstellungen.
Aussage: Das System soll Kunden über konfigurierbare Selbstbedienungsformulare, Mitarbeiter
über eine mobile Schnittstelle und Büroanwender über ein Outlook-Add-in an das
zentrale Nexus-Webportal anbinden.
Ergebnis: Ein von einem Web-Account ausgefülltes Selbstbedienungsformular; mobil abrufbare
Mitarbeiterdaten; ein aus Outlook heraus im Portal verfügbarer E-Mail-Anhang.
Belege:
- [PRIMÄR] src/backend/Centron.BL/SelfCare/SelfCareBL.cs:486,488 (GetSelfCareFormByI3D, SaveOrUpdateSelfCareForm) - Begründung: durchsetzende Formularverwaltung.
- [SEKUNDÄR] src/backend/Centron.BL/Mobile/MobileBL.cs:309-311 - Begründung: begleitende mobile Datenbereitstellung.
- [KONTEXT] src/nexus/CentronNexus.OutlookAddIn/Model/Attachment.cs:1-6 - Begründung: zeigt Existenz der Outlook-Integration auf Modellebene.
Prüfidee: Selbstbedienungsformular als Web-Account ausfüllen und im Backend als
`SelfCareForm`-Eintrag wiederfinden; parallel Mitarbeiterdaten über die mobile
Schnittstelle abrufen.
Tracelinks: SyRS-30, SyRS-31
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Self-Service-Kanäle sind zentral für eine Web-/SaaS-Neuimplementierung.
Status: belegt
```
## Domäne D15: Künstliche Intelligenz / KI-Assistenzfunktionen
```
ID: StRS-18
Titel: KI-Anbieter konfigurierbar für Chat-, Bewertungs- und Kategorisierungsfunktionen anbinden
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Systemadministrator, Mitarbeiter (Endnutzung z. B. im Helpdesk)
Vorbedingung: KI-Anbieter ist über `ArtificialIntelligenceSettingsDTO` konfiguriert.
Fakt: `ApiClientFactory.CreateApiClient(ArtificialIntelligenceSettingsDTO)`,
`CreateChatModelClient(...) : IAiModelClient`, `CreateTextRatingApiClient(...)` und
`CreateTicketCategoryApiClient(...)` erzeugen je nach Einstellung unterschiedliche,
spezialisierte KI-Clients über eine gemeinsame Factory;
`AiApiLinkValidator.GetValidatedApiLink(ArtificialIntelligenceApiType, string)`
validiert die konfigurierte API-Adresse vor Nutzung.
Aussage: Das System soll KI-Funktionen (Chat, Textbewertung, Ticketkategorisierung) über
eine zentrale, konfigurationsgesteuerte Factory anbieterunabhängig bereitstellen
und die konfigurierte API-Adresse vor Verwendung validieren.
Ergebnis: Ein passend zur Konfiguration erzeugter KI-Client; eine abgelehnte, ungültige
API-Adresse vor dem ersten Aufruf.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ArtificialIntelligence/ApiClientFactory.cs:9-58 (vier spezialisierte Create-Methoden) - Begründung: durchsetzende, zentrale Factory für alle KI-Clienttypen.
- [SEKUNDÄR] src/backend/Centron.BL/ArtificialIntelligence/AiApiLinkValidator.cs:35 (GetValidatedApiLink) - Begründung: begleitende Validierung vor Nutzung.
Prüfidee: Konfiguration auf einen anderen KI-Anbieter umstellen und prüfen, dass
`CreateChatModelClient` ohne Codeänderung den neuen Anbieter anspricht; ungültige
API-Adresse konfigurieren und Ablehnung durch `GetValidatedApiLink` prüfen.
Tracelinks: SyRS-32
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - anbieterunabhängige Factory ist ein sinnvolles Muster für die Zielarchitektur.
Status: belegt
```
## Domäne D16: Asset-/Gerätestammdaten & technische Basisdienste
```
ID: StRS-19
Titel: Kundenhardware als Assets verwalten - getrennt von Drucker-„Stammblättern" (Konsolidierungsfall)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Techniker, Vertriebsinnendienst
Vorbedingung: Kunde besitzt Hardware.
Fakt: `AssetManagementArticleAssignmentBL`/`AssetManagementPartnerBL` (Modul `DocuBoard`)
verwalten Kundenhardware als „Asset"; parallel dazu führt die Datenbank Drucker
unter einem eigenen Objekttyp `ObjektArt = 25 = Stammblatt` mit eigener Tabelle
(`GeraeteKopfI3D`-Bezug, Spalten `Stammblattnummer`/`Stammblattbezogen` u. a. in
`SSMS_DB_SCHEMA.sql`) - zwei getrennte Datenhaltungen für denselben fachlichen
Gegenstand „Kundenhardware".
Aussage: Das System soll Kundenhardware konsistent erfassen; im Ist-Zustand geschieht dies
jedoch über zwei getrennte Datenmodelle (allgemeine „Assets" versus
drucker-spezifische „Stammblätter"), die im Zielsystem zu einem einheitlichen
Asset-Konzept zusammengeführt werden sollen.
Ergebnis: Aktuell: ein Drucker erscheint als Stammblatt, sonstige Hardware als Asset - keine
einheitliche Sicht auf „die Hardware eines Kunden". Ziel: ein Asset-Konzept für
beide Fälle.
Belege:
- [PRIMÄR] src/backend/Centron.BL/DocuBoard/AssetManagementArticleAssignmentBL.cs:21,45 (GetAssetManagementArticleAssignment, SaveOrUpdateAssetManagementArticleAssignment) - Begründung: durchsetzende Asset-Verwaltung.
- [PRIMÄR] SSMS_DB_SCHEMA.sql:72038 (Kommentar „ObjektArt|25 = Stammblatt" mit Bezug auf `GeraeteKopfI3D`) - Begründung: durchsetzender Beleg der getrennten Objektart/Tabelle für Drucker.
- [KONTEXT] SSMS_DB_SCHEMA.sql:3472,4252,6321-6323,20655,20957-20959 (Spalte/Bezeichner „Stammblattbezogen" an mehreren Stellen) - Begründung: zeigt die Verbreitung des getrennten Konzepts über mehrere Tabellen/Prozeduren hinweg.
Prüfidee: Für denselben Kunden einen Drucker (Stammblatt) und ein sonstiges Gerät (Asset)
anlegen und prüfen, dass beide aktuell über unterschiedliche Abfragen/Tabellen
ermittelt werden müssen, um „alle Geräte des Kunden" zu erhalten.
Tracelinks: SyRS-33
Konsolidierung: Kandidat: Stammblatt (Drucker, `ObjektArt=25`) und Asset (`AssetManagement*`)
bilden denselben fachlichen Gegenstand „Kundenhardware" in getrennten
Implementierungen - im Zielsystem zu einem Asset-Konzept zusammenzuführen (siehe
Aufgabenstellung, Abschnitt „Konsolidierungsbedarf").
Übernahmewürdigkeit: Workaround - historisch getrennt entstandene Datenhaltung für denselben fachlichen Gegenstand.
Status: belegt
```
```
ID: StRS-20
Titel: Technische Basisdienste (Icons, Länder, Transaktionsprotokoll, URLs, Video, Systemstart) bereitstellen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Alle Module (indirekt)
Vorbedingung: keine
Fakt: `CountryBL` verwaltet Länder/Währungscodes; `TransactionBL.GetTransactionsByUserId`
protokolliert Systemtransaktionen je Benutzer; `SimpleUrlBL` verwaltet Kurz-URLs;
`VideoPortalAssignmentBL` ordnet Video-Inhalte Objekten zu; `StartBL.
SetConnectionString` steuert den Anwendungsstart; `ToolBL.ChangeTextFormat`
bietet zentrale Textformatierung.
Aussage: Das System soll grundlegende, modulübergreifend genutzte Dienste (Länderstamm,
Transaktionsprotokoll, Kurz-URLs, Video-Zuordnung, Startkonfiguration,
Textformatierung) als eigenständige, wiederverwendbare Komponenten bereitstellen.
Ergebnis: Konsistente, an einer Stelle gepflegte Basisdaten und -dienste für alle
Fachmodule.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Transactions/TransactionBL.cs:613-615 (GetAllTransactions, GetTransactionsByUserId, GetTransactionByTransactionI3D) - Begründung: durchsetzendes, benutzerbezogenes Transaktionsprotokoll.
- [SEKUNDÄR] src/backend/Centron.BL/CountryArea/CountryBL.cs:118-121 (SearchCountryByCountryCode, SearchCountryByCurrencyISO, SaveCountry, RemoveCountry) - Begründung: begleitende Stammdatenverwaltung.
Prüfidee: Systemweite Transaktion auslösen und über `GetTransactionsByUserId` dem
verursachenden Benutzer zuordnen.
Tracelinks: SyRS-34
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/SwRS.md
+2876
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/SyRS.md
+999
View File
@@ -0,0 +1,999 @@
# SyRS - System Requirements Specification
c-entron ERP-Suite - Reverse Requirements Engineering, Iteration 02 (2026-08-26)
Systemverhalten, Schnittstellen, Performance- und Sicherheitsanforderungen. Jede SyRS-Anforderung
referenziert die zugehörige StRS-Anforderung (Feld `Tracelinks`).
## Domäne D1: Vertrieb & Kundenbeziehungsmanagement
```
ID: SyRS-1
Titel: Rechnungen nach Festschreibung systemweit gegen inhaltliche Änderung sperren
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Belegverwaltung)
Vorbedingung: Eine Rechnung wurde erstellt und ist noch nicht festgeschrieben.
Fakt: `ReceiptInvoiceBL.FixInvoice` prüft zunächst `CheckIfInvoiceIsFixed`, setzt danach
per Raw-SQL `UPDATE RechKopf SET IsFixed = 1 WHERE I3D = @I3D` innerhalb einer
Transaktion und schreibt einen Log-Eintrag (`ReceiptLogKind.FixedState`).
Aussage: Das System soll den Übergang einer Rechnung in den festgeschriebenen Zustand
transaktional, geprüft (keine Doppel-Festschreibung) und mit Protokolleintrag
durchführen und danach inhaltliche Änderungen an dieser Rechnung verhindern.
Ergebnis: `RechKopf.IsFixed = 1`, ein `ReceiptLogKind.FixedState`-Eintrag ist vorhanden, ein
erneuter `FixInvoice`-Aufruf liefert einen Fehler statt einer erneuten Festschreibung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:86-107 (FixInvoice: CheckIfInvoiceIsFixed-Prüfung, transaktionales UPDATE RechKopf.IsFixed) - Begründung: durchsetzende Stelle mit konkreter Prüfbedingung und Datenbank-Constraint-Setzung.
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:109-123 (ReceiptLogBL.CreateEntry mit ReceiptLogKind.FixedState) - Begründung: Protokollierung als begleitender, nicht selbst durchsetzender Nachweis.
- [KONTEXT] Glossar.md, Eintrag „GoBD-Fixierung" - Begründung: ordnet den technischen Mechanismus in einen bekannten handelsrechtlichen Kontext ein (Interpretation).
Prüfidee: `FixInvoice` zweimal auf dieselbe Rechnung anwenden - der zweite Aufruf muss
`Result.AsError` liefern; ein direkter Änderungsversuch an Positionen einer
festgeschriebenen Rechnung muss serverseitig abgelehnt werden.
Tracelinks: StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Integritätssicherung ist unabhängig von der Zielarchitektur erforderlich.
Status: belegt
```
```
ID: SyRS-2
Titel: Belegweiterleitung zwischen Belegarten mit Versionierung
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Belegverwaltung)
Vorbedingung: Ein Ausgangsbeleg (z. B. Angebot) existiert.
Fakt: `ReceiptBL` bietet generische, typparametrisierte Zugriffe `GetReceiptByI3D<T>` und
`GetReceiptVersionByI3D<T>` über alle Belegarten hinweg (`CentronObjectKindNumeric`);
`ForwardReceiptResult`/`CopyReceiptResult` modellieren das Ergebnis einer
Belegweiterleitung bzw. -kopie.
Aussage: Das System soll Belege beliebiger Art über eine gemeinsame, typisierte Schnittstelle
referenzieren, versionieren und in andere Belegarten weiterleiten oder kopieren
können, ohne belegartspezifischen Code in den aufrufenden Schichten zu benötigen.
Ergebnis: Ein neuer Folgebeleg mit Bezug zum erzeugenden Ausgangsbeleg und eigener
Versionshistorie.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:641-724 (GetReceiptByI3D<T>, GetReceiptVersionByI3D<T>) - Begründung: durchsetzende, generische Zugriffsmethode auf das versionierte Belegmodell.
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/DataAndResults/ForwardReceipt/ForwardReceiptResult.cs, CopyReceiptResult.cs - Begründung: Ergebnisklassen zeigen die vorgesehenen Operationen, ohne selbst die Regel durchzusetzen.
- [KONTEXT] src/backend/Centron.BL/Sales/Receipts/DataAndResults/ (Unterordner CreateReceipt, CreateReceiptForHelpdeskTimers, CreateReceiptItemsFromExistingItems) - Begründung: zeigt die Bandbreite unterstützter Erzeugungsvarianten.
Prüfidee: Ein Angebot per Weiterleitung in einen Auftrag überführen und prüfen, dass die neue
Version einen Rückverweis auf den Ausgangsbeleg trägt.
Tracelinks: StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Belegkette ist Kernfunktion.
Status: belegt
```
```
ID: SyRS-3
Titel: RMA-Vorgänge mit gerichteter Versandhistorie (an/von Lieferant) verwalten
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (RMA-Verwaltung)
Vorbedingung: Ein Artikel eines Kunden ist reklamationsfähig erfasst.
Fakt: `RmaBL` unterscheidet `RmaSendForth` (Versand an Lieferant) und `RmaSendBack`
(Rückversand) als eigene Entitäten/Methoden (`GetRmaSendForthByI3D`,
`GetRmaSendBacksByFilter`) neben `RmaArticleHistory`.
Aussage: Das System soll zu jedem RMA-Artikel die Versandrichtung (an den Lieferanten /
vom Lieferanten zurück) getrennt nachvollziehbar dokumentieren.
Ergebnis: Ein RMA-Vorgang mit lückenloser, richtungsbezogener Versandhistorie je Artikel.
Belege:
- [PRIMÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs:685,692,709 (GetRmaSendForthByI3D, GetRmaSendBackByI3D, GetRmaSendBacksByFilter) - Begründung: konkrete, richtungsspezifische Zugriffsmethoden.
- [SEKUNDÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs:646 (GetRmaArticleHistoryByI3D) - Begründung: begleitende Historienfunktion.
Prüfidee: Für eine RMA einen Artikel an den Lieferanten senden (RmaSendForth) und danach den
Rückversand (RmaSendBack) erfassen; beide Einträge müssen unabhängig abrufbar sein.
Tracelinks: StRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D2: Einkauf & Lieferantenmanagement
```
ID: SyRS-4
Titel: Multi-Distributor-EDI-Bestellabwicklung mit distributorspezifischer Kodierung
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System (EDI-Gateway)
Vorbedingung: Ein Bestellvorschlag oder eine Bestellung liegt vor; Distributor ist konfiguriert.
Fakt: `EDIDispatcherBL` bietet je Distributor eigene asynchrone Methoden
(`EdiEgisOrderUploadAsync`, `EdiItScopeOrderUploadAsync`, `EdiConcertoOrderUploadAsync`,
`KomsaArticleCheckAsync`) sowie eine generische `CreateEDISuggestionOrderAsync` mit
`EDIMultidistributors distributor`-Parameter.
Aussage: Das System soll Bestellungen in einem gemeinsamen internen Modell erfassen und beim
Versand automatisch in das distributorspezifische EDI-Format und den zugehörigen
Übertragungsweg übersetzen.
Ergebnis: Eine an den jeweiligen Distributor formatgerecht übermittelte elektronische Bestellung
mit Rückmeldung (`Result<...>`).
Belege:
- [PRIMÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs:56-290 (distributorspezifische Upload-/Check-Methoden) - Begründung: durchsetzende, pro Distributor unterschiedliche Übertragungslogik.
- [SEKUNDÄR] src/backend/Centron.BL/EDI/Alltron/AlltronOrderBL.cs:173-176 (CreateOrderDocument) - Begründung: zeigt beispielhaft die distributorspezifische XML-Erzeugung für Alltron.
Prüfidee: Dieselbe interne Bestellung an zwei unterschiedliche Distributoren senden und die
jeweils distributorspezifische Zieldatenstruktur (XDocument) auf Formatunterschiede
prüfen.
Tracelinks: StRS-3
Konsolidierung: Kandidat: distributorspezifische Upload-Methoden (Egis/ITscope/Concerto/Komsa) bilden dieselbe fachliche Funktion „Bestellung elektronisch übermitteln" mehrfach separat ab; im Zielsystem als eine parametrisierte Schnittstelle konsolidierbar.
Übernahmewürdigkeit: übernehmen - Konsolidierung der Übertragungswege wird für die Zielarchitektur empfohlen.
Status: belegt
```
```
ID: SyRS-5
Titel: Bestellvorschlagsermittlung aus Bestand und Bedarf
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Einkaufsplanung)
Vorbedingung: Artikelbestände und Verkaufshistorie sind erfasst.
Fakt: `OrderSuggestionListBL.GetOrderSuggestionArticle(AppUser, ...)` und
`GetArticlePerItems(AppUser, OrderSuggestionFilter)` liefern artikel- bzw.
positionsbezogene Vorschlagslisten.
Aussage: Das System soll auf Basis von Filterkriterien (`OrderSuggestionFilter`) je Artikel
und je Bestellposition einen Bestellvorschlag ermitteln.
Ergebnis: Eine gefilterte Liste von Bestellvorschlägen (`SuggestionBaseDTO`/`SuggestionOrderDTO`).
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs:430-432 (GetOrderSuggestionArticle, GetArticlePerItems, GetOrderSuggestionOrder) - Begründung: UI-nahe Ermittlungsmethoden; die konkrete Meldebestand-/Bedarfsberechnung war im erhobenen Ausschnitt nicht einsehbar.
Prüfidee: Artikel mit Bestand unterhalb eines konfigurierten Meldebestands anlegen und prüfen,
ob `GetOrderSuggestionArticle` ihn in die Vorschlagsliste aufnimmt.
Tracelinks: StRS-3
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D3: Lager, Artikel & Produktion
```
ID: SyRS-6
Titel: Automatische Ermittlung des zutreffenden Staffelpreises nach Bestellmenge
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Preisfindung)
Vorbedingung: Für einen Artikel sind mehrere `ArticleVolumePrices`-Staffeln mit `FromAmount`
hinterlegt.
Fakt: `GetVolumePrice(IList<ArticleVolumePrices> volumePrices, decimal? amount)` sortiert
absteigend nach `FromAmount` und wählt den ersten Eintrag mit `FromAmount <= amount`
(Zeile 96); bei leerer Liste wird `null` zurückgegeben.
Aussage: Das System soll bei der Preisfindung automatisch die Staffel mit der höchsten
Mengenschwelle wählen, die die angefragte Menge noch erfüllt, und ohne definierte
Staffel keinen Staffelpreis anwenden.
Ergebnis: Der korrekte, mengenabhängige Staffelpreis bzw. `null` als Signal für „kein
Staffelpreis anwendbar".
Belege:
- [PRIMÄR] src/backend/Centron.BL/Warehousing/ArticleVolumePricesBL.cs:88-97 (GetVolumePrice, vollständige Auswahllogik) - Begründung: durchsetzende, eindeutig nachvollziehbare Sortier-/Auswahlregel.
Prüfidee: Staffeln bei 1, 10 und 50 Stück hinterlegen; Preisermittlung für Mengen 5, 10, 49 und
100 durchführen und jeweils die erwartete Staffel prüfen.
Tracelinks: StRS-4
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
```
ID: SyRS-7
Titel: Lagerortgenaue Bestandsführung mit mengengewichteter Einkaufspreisnachführung
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Bestandsführung)
Vorbedingung: Artikel ist einem Lager/Lagerplatz zugeordnet.
Fakt: `ArticleStockBL.UpdateArticleStock(int articleI3D, int? articleSecondaryStorageI3D,
double quantity)` und `UpdateArticlePurchasePrice(AppUser, IReceiptBase, IReceiptItemBase,
IStock, int articleI3D, decimal oldQuantity, decimal quantity, decimal purchasePrice)`
nehmen sowohl Alt- als auch Neumenge und -preis entgegen.
Aussage: Das System soll bei jeder Bestandsveränderung (Zu-/Abgang) den Einkaufspreis unter
Berücksichtigung der bisherigen Menge und des bisherigen Preises neu berechnen.
Ergebnis: Bestand und mengengewichteter Einkaufspreis sind nach der Buchung konsistent.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs:47-74 (UpdateArticleStock, IncreaseArticleStock, UpdateArticlePurchasePrice mit oldQuantity/quantity/purchasePrice) - Begründung: durchsetzende Methoden mit den für eine gewichtete Neuberechnung nötigen Parametern; die genaue Berechnungsformel selbst war im erhobenen Methodenkopf nicht einsehbar.
Prüfidee: Wareneingang mit einer zweiten, abweichenden Preisstufe buchen und den neuen
gewichteten Durchschnittspreis gegen eine manuell berechnete Erwartung prüfen.
Tracelinks: StRS-4
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - [HYPOTHESE: die genaue Berechnungsformel (z. B. gleitender Durchschnitt vs. FIFO) ist aus der Methodensignatur allein nicht ableitbar und wurde nicht im Methodenkörper verifiziert].
Status: belegt
```
```
ID: SyRS-8
Titel: Produktionsauftragsverwaltung mit Positions- und Statusprotokoll
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Produktionsplanung)
Vorbedingung: Produktionsmaschine und Artikel sind erfasst.
Fakt: `ProductionOrderBL` trennt `ProductionOrder`, `ProductionOrderItem` und
`ProductionOrderLog` als eigene Speicher- und Filtermethoden
(`SaveProductionOrder`, `SaveProductionOrderItem`, `SaveProductionOrderLog`/
`SaveProductionOrderLog(List<...>)`).
Aussage: Das System soll Produktionsaufträge mit beliebig vielen Positionen erfassen und jede
relevante Statusänderung als separaten, mehrfach batchbar speicherbaren Log-Eintrag
festhalten.
Ergebnis: Ein Produktionsauftrag mit Positionen und vollständiger, batchfähiger Protokollhistorie.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs:45,122,184,194,205 (Save-/Filter-Methoden für Order, Item, Log inkl. Batch-Log) - Begründung: UI-nahe, aber konkrete und vollständige Methodenfamilie.
Prüfidee: Produktionsauftrag mit zwei Positionen anlegen, Status mehrfach ändern und über
`GetProductionOrderLogByFilter` die vollständige, chronologische Historie abrufen.
Tracelinks: StRS-4
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D4: Finanzbuchhaltung & Zahlungsverkehr (risikorelevant)
```
ID: SyRS-9
Titel: Exportstatus-Flag verhindert doppelten Zahlungsexport
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Zahlungsexport)
Vorbedingung: Rechnung ist zahlungsrelevant und noch nicht exportiert.
Fakt: `PaymentTransactionBL.SetInvoicesAsExported(int employeeI3D, int invoiceI3D)` setzt
das Exportiert-Flag einer Rechnung; `ResetInvoiceExportedFlag(AppUser,
List<int> incomingPaymentLogI3Ds)` ist die einzige im erhobenen Ausschnitt
identifizierte Stelle, die es zurücksetzt.
Aussage: Das System soll eine Rechnung nach Zahlungsexport eindeutig als exportiert
kennzeichnen, so dass sie bei einer erneuten Exportselektion nicht automatisch
erneut aufgenommen wird, und ein Zurücksetzen des Flags nur über eine benannte,
auf den ausführenden Mitarbeiter (`employeeI3D`/`AppUser`) zurückführbare Funktion
zulassen.
Ergebnis: Keine unbeabsichtigte doppelte SEPA-/Zahlungsvorlage derselben Rechnung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs:291,296 (SetInvoicesAsExported, ResetInvoiceExportedFlag mit Benutzerbezug) - Begründung: durchsetzende, auf den handelnden Benutzer zurückführbare Statusänderung.
Prüfidee: Rechnung exportieren (Flag gesetzt), Exportlauf erneut mit
`showOnlyExportedInvoices: false` starten - Rechnung darf nicht erneut selektiert
werden; erst nach `ResetInvoiceExportedFlag` darf sie wieder erscheinen.
Tracelinks: StRS-5
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zwingende Kontrolle für jeden Zahlungsverkehr.
Status: belegt
```
```
ID: SyRS-10
Titel: Bankkontoabgleich über FinAPI mit Erkennung unbekannter IBANs
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System (Online-Banking-Anbindung)
Vorbedingung: FinAPI-Zugangsdaten und Bankverbindung sind konfiguriert.
Fakt: `OnlineBankingFinApiBL.GetFinApiClientCredentials(GetFinApiClientCredentialsRequest,
bool isUnitTest)` bezieht Zugangsdaten von der externen FinAPI-Schnittstelle
(`Centron.APIs.FinAPI`); `OnlineBankingAccountTransactionsBL.CheckForUnknownIbans`
prüft eingehende Transaktionen auf nicht zuordenbare IBANs.
Aussage: Das System soll Kontobewegungen über die externe FinAPI-Schnittstelle abrufen und
Transaktionen mit einer im System nicht bekannten IBAN gesondert kennzeichnen, statt
sie automatisch einer beliebigen Rechnung zuzuordnen.
Ergebnis: Eine Liste unbekannter IBANs zur manuellen Prüfung, getrennt von automatisch
zuordenbaren Transaktionen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs:75 (CheckForUnknownIbans, vollständige Signatur mit Request/Result) - Begründung: durchsetzende Prüfmethode gegen Fehlzuordnung von Zahlungen.
- [SEKUNDÄR] src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs:29 (GetFinApiClientCredentials) - Begründung: zeigt die externe Authentifizierung als Vorbedingung des Abgleichs.
Prüfidee: Kontoumsatz mit unbekannter IBAN importieren und prüfen, dass er in
`CheckForUnknownIbans` erscheint statt automatisch verbucht zu werden.
Tracelinks: StRS-5
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Fehlzuordnungsschutz bleibt in jeder Zielarchitektur nötig.
Status: belegt
```
```
ID: SyRS-11
Titel: Parallele Kontenrahmen mit konfigurierbarem Buchhaltungsexport
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System (Buchhaltungsexport)
Vorbedingung: Mindestens ein Kontenrahmen ist als Standard markiert.
Fakt: `GetBookKeepingAccounts(bool fromDefaultSystem)` unterscheidet explizit den
Standard-Kontenrahmen von weiteren angelegten Kontenrahmen
(`GetBookKeepingAccountSystems(AccountSystemFilter)`).
Aussage: Das System soll genau einen Kontenrahmen als Standard auszeichnen und weitere
Kontenrahmen parallel dazu verwalten können, ohne dass sich deren Konten
gegenseitig überschreiben.
Ergebnis: Konten sind eindeutig ihrem Kontenrahmen zugeordnet abrufbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/BookKeepingAccountSystems/BookKeepingAccountSystemBL.cs:67 (GetBookKeepingAccounts mit fromDefaultSystem-Unterscheidung) - Begründung: durchsetzende Trennung von Standard- und Zusatzkontenrahmen.
Prüfidee: Zweiten Kontenrahmen anlegen und prüfen, dass `GetBookKeepingAccounts(true)`
ausschließlich Konten des Standardrahmens liefert.
Tracelinks: StRS-6
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D10: Sicherheit, Zugriffsschutz & Berechtigungen (risikorelevant)
```
ID: SyRS-12
Titel: Gruppenbasierte Rechteauflösung für Programmbenutzer über Sichtrus/Sichmemb
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Rechteprüfung)
Vorbedingung: Benutzer ist mindestens einer Rechtegruppe zugeordnet.
Fakt: `HasUserRight` cached das Ergebnis pro Benutzer (`Session.Advanced.Cache.GetOrAdd`)
und ermittelt es über `SELECT st.Recht ... FROM Sichtrus st INNER JOIN Sichmemb sm ON
sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D`.
Aussage: Das System soll Rechte ausschließlich über Gruppenmitgliedschaft auflösen (kein
direktes Benutzer-Recht ohne Gruppe) und das Ergebnis je Benutzer cachen, um
wiederholte Datenbankzugriffe zu vermeiden.
Ergebnis: Eine konsistente, gecachte Liste der Rechte-IDs eines Benutzers.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:644-660 (HasUserRight, GetAllAppRightsFromUser mit Cache und SQL-Join) - Begründung: durchsetzende, konkrete Abfrage- und Cache-Logik.
Prüfidee: Benutzer aus einer Rechtegruppe entfernen und prüfen, dass `HasUserRight` nach
Cache-Invalidierung das entzogene Recht nicht mehr liefert.
Tracelinks: StRS-7
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - [HYPOTHESE: der Cache-Invalidierungszeitpunkt bei Gruppenänderung war im erhobenen Ausschnitt nicht erkennbar; ein zu spätes Invalidieren wäre ein Sicherheitsrisiko (veraltete Berechtigung bleibt wirksam)].
Status: belegt
```
```
ID: SyRS-13
Titel: Gesalzenes Passwort-Hashing als Grundlage der Authentifizierung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit/Integrität (ISO 25010: Security - Confidentiality)
Akteur: System (Authentifizierung)
Vorbedingung: Benutzer setzt oder ändert ein Passwort.
Fakt: `CreateSalt(int size)` erzeugt einen kryptographisch zufälligen Salt
(`RandomNumberGenerator.GetBytes`); `CreatePasswordHash(pwd, salt)` bildet
`SHA1(pwd + salt)` als Hexstring.
Aussage: Das System soll jedes Passwort mit einem individuellen, kryptographisch
zufälligen Salt versehen, bevor es gehasht gespeichert wird.
Ergebnis: Kein Klartextpasswort in der Datenbank; identische Passwörter zweier Benutzer
erzeugen wegen unterschiedlichem Salt unterschiedliche Hashes.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Core/CryptoUtils.cs:15-33 (CreateSalt, CreatePasswordHash) - Begründung: durchsetzende, vollständige Hashing-Implementierung.
Prüfidee: Zwei Benutzer mit identischem Passwort anlegen und prüfen, dass die gespeicherten
Hashes unterschiedlich sind (unterschiedlicher Salt).
Tracelinks: StRS-8
Konsolidierung: nein
Übernahmewürdigkeit: veraltet - SHA1 ohne Schlüsselstreckung gilt nach aktuellem Stand der Technik
(vgl. OWASP Password Storage Cheat Sheet) als nicht mehr ausreichend gegen
Offline-Brute-Force-Angriffe; im Zielsystem durch Argon2id/bcrypt/PBKDF2 mit
ausreichendem Kostenfaktor zu ersetzen.
Status: belegt
```
```
ID: SyRS-14
Titel: REST-API-Endpunkte gegen Benutzerrechte autorisieren
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Webservice-Schicht)
Vorbedingung: Ein Client ruft einen REST-Endpunkt auf.
Fakt: `AuthorizeAllUserRightsAttribute(params int[] userRightIds) : TypeFilterAttribute`
mit `AllUserRightsAuthorizationFilter.OnAuthorization(AuthorizationFilterContext)`
im Webservice-Projekt `Centron.Controllers`.
Aussage: Das System soll REST-API-Controller-Methoden deklarativ mit den erforderlichen
Rechte-IDs annotieren und bei fehlender Berechtigung den Aufruf vor Ausführung der
Controller-Logik abweisen.
Ergebnis: Ein Request ohne alle geforderten Rechte wird mit einem Autorisierungsfehler
abgewiesen, bevor Geschäftslogik ausgeführt wird.
Belege:
- [PRIMÄR] src/webservice/Centron.Controllers/Authorization/AuthorizeAllUserRightsAttribute.cs (Klassen AuthorizeAllUserRightsAttribute, AllUserRightsAuthorizationFilter.OnAuthorization) - Begründung: durchsetzender ASP.NET-Autorisierungsfilter, der vor der Controller-Aktion greift.
Prüfidee: Endpunkt mit `[AuthorizeAllUserRights(1234)]` annotieren und mit einem Benutzer ohne
Recht 1234 aufrufen - Erwartung: HTTP 401/403 statt Ausführung der Aktion.
Tracelinks: StRS-7
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - deklarative API-Autorisierung ist Best Practice und für die Zielarchitektur direkt weiterverwendbar.
Status: belegt
```
```
ID: SyRS-15
Titel: TOTP-basierte Zwei-Faktor-Authentifizierung als Zusatzfaktor
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Authentifizierung)
Vorbedingung: Benutzer hat einen Zwei-Faktor-Schlüssel hinterlegt.
Fakt: `ValidateAuthenticationPin` liefert bei fehlendem Schlüssel die Fehlermeldung „Ihrem
Benutzer ist kein Zwei-Faktor Schlüssel in der Personalverwaltung hinterlegt!" und
delegiert sonst an `Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin`.
Aussage: Das System soll eine Zwei-Faktor-Anmeldung nur zulassen, wenn dem Benutzer zuvor
ein Schlüssel zugeordnet wurde, und die PIN-Prüfung an eine standardkonforme
TOTP-Implementierung delegieren.
Ergebnis: Erfolgreiche 2FA nur mit gültigem, zeitlich passendem TOTP-Code.
Belege:
- [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs:43-54 (ValidateAuthenticationPin, vollständiger Methodenkörper) - Begründung: durchsetzende Prüfung mit expliziter Vorbedingung.
Prüfidee: Benutzer ohne hinterlegten Schlüssel anmelden lassen - erwartete Fehlermeldung;
danach Schlüssel hinterlegen und mit korrektem/falschem TOTP-Code erneut prüfen.
Tracelinks: StRS-8
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
```
ID: SyRS-16
Titel: Geschützte Verwaltung sensibler Zugangsdaten, Zertifikate und Tokens Dritter
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Zugangsdaten-/Zertifikatsverwaltung)
Vorbedingung: Sensible Daten (Kundenzugangsdaten, Signaturzertifikat, API-Token) sind hinterlegt.
Fakt: `PasswordManagementBL.GetDecryptedPassword` mit begleitendem
`PasswordManagementAccessLogBL`; `PasswordManagerBL.GetPasswordManagerCustomersEmployeesRights`;
`PdfSigningBL.IsPdfSigningAvailable`/`SavePdfSigningSettings`.
Aussage: Das System soll den Zugriff auf sensible Drittdaten (Kundenzugangsdaten,
Signaturzertifikate) grundsätzlich rechte- und protokollpflichtig gestalten, statt
sie unkontrolliert im Klartext bereitzustellen.
Ergebnis: Jeder Zugriff auf sensible Drittdaten ist entweder rechteabhängig eingeschränkt
oder protokolliert nachvollziehbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/PasswordManagementArea/PasswordManagementAccessLogBL.cs:383 - Begründung: durchsetzende Protokollierung des Zugriffs.
- [SEKUNDÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs:391; src/backend/Centron.BL/Security/PdfSigningBL.cs:479-480 - Begründung: begleitende Rechte-/Verfügbarkeitsprüfungen.
Prüfidee: Siehe SwRS-38 bis SwRS-41.
Tracelinks: StRS-8
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D5: Personalverwaltung & Zeitwirtschaft
```
ID: SyRS-18
Titel: Administratorstatus getrennt von regulären Einzelrechten führen
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Benutzerverwaltung)
Vorbedingung: Benutzer existiert.
Fakt: `AppUserBL.IsUserInAdminGroup(AppUser appUser)` ist eine eigene Methode neben der
allgemeinen Rechteprüfung aus `AppRightsBL`.
Aussage: Das System soll den Administratorstatus eines Benutzers als eigene, von
Einzelrechten unabhängige Eigenschaft führen und abfragbar machen.
Ergebnis: Eine eindeutige Ja/Nein-Aussage, ob ein Benutzer Mitglied der Administratorgruppe
ist.
Belege:
- [PRIMÄR] src/backend/Centron.BL/EmployeeArea/AppUserBL.cs:247 (IsUserInAdminGroup) - Begründung: durchsetzende, dedizierte Statusprüfung.
Prüfidee: Benutzer der Admin-Gruppe hinzufügen/entfernen und `IsUserInAdminGroup` vor/nach der
Änderung prüfen.
Tracelinks: StRS-9
Konsolidierung: Kandidat: Verhältnis von `IsUserInAdminGroup` zur allgemeinen Rechteprüfung
(`AppRightsBL.HasUserRight`) im Zielsystem klären - ggf. Admin-Status als
Sonderrecht statt eigenem Flag abbilden.
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
```
ID: SyRS-19
Titel: Zeitmodell- und Kalenderverwaltung je Mitarbeiter
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Personalverwaltung)
Vorbedingung: Mitarbeiter ist angelegt.
Fakt: `TimingSettingsBL.GetTimingSettingsByI3D`/`GetTimingSettingsByFilter` sowie
`CalendarBL.GetCalendarRepresentationSettings`/`GetCalendarSynchronizationSettings`.
Aussage: Das System soll je Mitarbeiter ein Zeitmodell und individuelle
Kalenderdarstellungs-/Synchronisationseinstellungen verwalten.
Ergebnis: Ein Mitarbeiter mit zugeordnetem Zeitmodell und Kalendereinstellungen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Time/TimingSettingsBL.cs:583-585 und src/backend/Centron.BL/Calendar/CalendarBL.cs:65-67 - Begründung: UI-nahe Konfigurationszugriffe ohne tiefere im Ausschnitt erkennbare Geschäftsregel.
Prüfidee: Zeitmodell einem Mitarbeiter zuordnen und Kalendersynchronisation aktivieren; beide
Einstellungen unabhängig voneinander prüfen.
Tracelinks: StRS-9
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
```
ID: SyRS-25
Titel: Batchfähige Nutzungstelemetrie für interne Werkzeuge und KI-Funktionen
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Analysierbarkeit (ISO 25010: Maintainability - Analysability)
Akteur: System (Telemetriedienst)
Vorbedingung: Ein Werkzeug/eine KI-Funktion wurde aufgerufen.
Fakt: Siehe SwRS-70 (`RecordArtificialIntelligenceToolUsage`,
`UpsertMcpToolUsageBatch`).
Aussage: Das System soll Werkzeug- und KI-Nutzung batchfähig und mit Benutzer-/
Hardwarebezug erfassen, um Auswertungen über Nutzungsmuster zu ermöglichen.
Ergebnis: Eine vollständige, batchweise gespeicherte Nutzungsstatistik.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Telemetry/TelemetryBL.cs:560-563 - Begründung: durchsetzende Erfassungsmethoden.
Prüfidee: Siehe SwRS-70.
Tracelinks: StRS-12
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D6: Kundenservice, Ticketing & Support
```
ID: SyRS-17
Titel: Checklisten und Aufgaben ticketübergreifend wiederverwendbar verwalten
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Ticket-/Aufgabenverwaltung)
Vorbedingung: Vorlage existiert oder wird neu angelegt.
Fakt: `CentronChecklistBL.GetChecklistsByFilter(CentronChecklistFilter)` liefert
`CentronChecklist`-Objekte unabhängig vom Ticket; `TaskManagementTaskBL.GetTasks(int
page, int entriesPerPage, GetTasksFilter)` liefert paginierte Aufgaben;
`ChecklistVirtualObjectCategoryBL` kategorisiert Checklisten-Objekte.
Aussage: Das System soll Checklisten und Aufgaben als eigenständige, filterbare und
kategorisierbare Objekte führen, die nicht zwingend an ein einzelnes Ticket
gebunden sind.
Ergebnis: Wiederverwendbare Checklisten-/Aufgabenvorlagen, die mehreren Tickets zugeordnet
werden können.
Belege:
- [PRIMÄR] src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs:103-106 (vier Filter-/Zugriffsmethoden) - Begründung: durchsetzende, ticketunabhängige Verwaltung.
- [SEKUNDÄR] src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs:555 (GetTasks mit Paging) - Begründung: begleitende Aufgabenverwaltung.
Prüfidee: Checkliste unabhängig von einem konkreten Ticket anlegen, danach zwei Tickets
zuordnen und prüfen, dass Änderungen an der Vorlage nicht rückwirkend beide Tickets
beeinflussen (bzw. dokumentieren, falls doch - Verhalten im erhobenen Ausschnitt
nicht abschließend erkennbar).
Tracelinks: StRS-10
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
```
ID: SyRS-20
Titel: Externe Helpdesk-Konfiguration und Ticketprojekt-Abhängigkeiten
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Ticketprojektverwaltung)
Vorbedingung: Mehrere zusammenhängende Tickets existieren.
Fakt: `TicketProjectBL.GetTicketProjectDependencies(int ticketProjectI3D)` und
`SaveOrUpdateTicketProjectDependency` bilden Abhängigkeiten zwischen Tickets
innerhalb eines Projekts ab; `ExternalHelpdeskConfigurationBL` verwaltet externe
Helpdesk-Anbindungen als eigene Konfigurationsobjekte.
Aussage: Das System soll Abhängigkeiten zwischen Tickets innerhalb eines Ticketprojekts
explizit modellieren und externe Helpdesk-Systeme über eigene, mehrfach anlegbare
Konfigurationen anbinden.
Ergebnis: Ein Ticketprojekt mit nachvollziehbaren Abhängigkeiten zwischen seinen Tickets;
eine aktive externe Helpdesk-Konfiguration.
Belege:
- [PRIMÄR] src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs:576-577 (GetTicketProjectDependencies, SaveOrUpdateTicketProjectDependency) - Begründung: durchsetzende Abhängigkeitsverwaltung.
- [SEKUNDÄR] src/backend/Centron.BL/ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs:203-205 - Begründung: begleitende Konfigurationsverwaltung.
Prüfidee: Zwei Tickets in einem Projekt mit einer Abhängigkeit „muss vor" verknüpfen und
prüfen, dass diese Reihenfolge in der Projektübersicht sichtbar ist.
Tracelinks: StRS-10
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D7: Kommunikation
```
ID: SyRS-21
Titel: E-Mail-Verarbeitung mit Blacklist- und Workflow-Steuerung
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Mail-Verarbeitung)
Vorbedingung: Eingehende oder ausgehende E-Mail liegt vor.
Fakt: `DomainBlacklistBL.IsBlacklisted(string email)` prüft Absenderdomänen;
`MailScannerBL.GetWorkflows(MailScannerWorkflowFilter)` und `SaveWorkflow` steuern
automatisierte Verarbeitungs-Workflows gescannter E-Mails.
Aussage: Das System soll E-Mails von gesperrten Domänen erkennen und eingehende E-Mails
über konfigurierbare Workflows automatisiert verarbeiten (z. B. Zuordnung zu
Tickets).
Ergebnis: E-Mails blockierter Domänen werden nicht weiterverarbeitet; übrige E-Mails
durchlaufen den konfigurierten Workflow.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Mail/Blacklist/DomainBlacklistBL.cs:279 (IsBlacklisted) - Begründung: durchsetzende Prüfmethode.
- [SEKUNDÄR] src/backend/Centron.BL/MailScanner/MailScannerBL.cs:285-286 (GetWorkflows, SaveWorkflow) - Begründung: begleitende Workflow-Konfiguration.
Prüfidee: E-Mail von einer als Blacklist markierten Domäne senden und prüfen, dass
`IsBlacklisted` sie erkennt, bevor ein Workflow angestoßen wird.
Tracelinks: StRS-11
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
```
ID: SyRS-22
Titel: Zentrale, filter- und quittierbare Benutzerbenachrichtigungen
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Benachrichtigungsdienst)
Vorbedingung: Ein benachrichtigungswürdiges Ereignis ist eingetreten.
Fakt: `NexusNotificationsBL.MarkNexusNotificationsAsRead(List<int>, LoggedInUser)` und
`DeleteNexusNotifications(List<int>)` verwalten den Gelesen-/Gelöscht-Status;
`CentronNotificationsBL.GetCentronNotificationsSettings()` liefert je-Benutzer-
Einstellungen.
Aussage: Das System soll Benachrichtigungen je Benutzer mit explizitem Gelesen-Status
führen und dessen Benachrichtigungspräferenzen konfigurierbar machen.
Ergebnis: Eine Benachrichtigungsliste mit korrektem Gelesen-/Ungelesen-Status je Benutzer.
Belege:
- [PRIMÄR] src/backend/Centron.BL/NexusNotifications/NexusNotificationsBL.cs:342-343 (MarkNexusNotificationsAsRead, DeleteNexusNotifications) - Begründung: durchsetzende Statuspflege.
- [SEKUNDÄR] src/backend/Centron.BL/Notifications/CentronNotificationsBL.cs:357-359 - Begründung: begleitende Einstellungsverwaltung.
Prüfidee: Benachrichtigung als gelesen markieren und prüfen, dass sie in einer
„nur ungelesen"-Filterung nicht mehr erscheint.
Tracelinks: StRS-11
Konsolidierung: Kandidat: siehe StRS-11 (NexusNotifications vs. Notifications).
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
```
ID: SyRS-36
Titel: Kanalspezifische Kommunikationserfassung (Chat, Telefonie, Social Media, Weblinks, Geräte)
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Kommunikationserfassung)
Vorbedingung: Kommunikationskanal ist konfiguriert.
Fakt: `ChatBL`, `PhoneCallBL`, `SocialMediaBL`, `WebLinkBL` und `AccountDeviceBL` bilden
je einen Kommunikations-/Interaktionskanal als eigenständiges Modul mit eigenem
Datenmodell ab, statt einem gemeinsamen „Interaktions"-Basismodell zu folgen.
Aussage: Das System soll jeden Kommunikations- bzw. Interaktionskanal (Chat, Telefonie,
Social Media, Weblink-Aktionen, Gerätezuordnung) mit eigenem, auf den Kanal
zugeschnittenem Datenmodell erfassen.
Ergebnis: Je Kanal ein vollständig erfasster, kanalspezifischer Interaktionsdatensatz.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Chats/ChatBL.cs; Tapi/PhoneCallBL.cs; SocialMedia/SocialMediaBL.cs; WebLinks/WebLinkBL.cs; Devices/AccountDeviceBL.cs (Modulstruktur) - Begründung: zeigt konsistent getrennte, kanalspezifische Module ohne gemeinsame Abstraktion im erhobenen Ausschnitt.
Prüfidee: Prüfen, ob ein gemeinsames Interaktionsprotokoll (z. B. eine „Aktivität"-Tabelle)
kanalübergreifend existiert, oder ob jeder Kanal vollständig isoliert bleibt.
Tracelinks: StRS-11
Konsolidierung: Kandidat: fünf strukturell ähnliche, aber unabhängige Kommunikationskanal-Module - im Zielsystem ggf. über ein gemeinsames Interaktionsmodell konsolidierbar.
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D8: Berichtswesen, Volltextsuche & Nutzungstelemetrie
```
ID: SyRS-23
Titel: Asynchron aktualisierbarer, objekttypübergreifender Volltextindex
Ebene: SyRS
Typ: Performance-Effizienz
Qualitätsmerkmal: Zeitverhalten (ISO 25010: Performance Efficiency)
Akteur: System (Indexdienst)
Vorbedingung: Indexdienst läuft.
Fakt: `UpdateAllIndexes(CancellationToken token)` und `UpdateRequestedIndexes(CancellationToken
token)` sind abbrechbar (Cancellation-Pattern); `GermanAnalyzer` deutet auf
sprachspezifische Indexierung hin.
Aussage: Das System soll den Volltextindex asynchron und abbrechbar aktualisieren, um die
Anwendung während der Indexierung nicht zu blockieren, und deutschsprachige
Inhalte sprachspezifisch analysieren.
Ergebnis: Ein aktueller, deutschsprachig optimierter Suchindex ohne Blockierung des laufenden
Betriebs.
Belege:
- [PRIMÄR] src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs:248-249 (UpdateAllIndexes, UpdateRequestedIndexes mit CancellationToken) - Begründung: durchsetzendes, abbrechbares Aktualisierungsmuster.
- [SEKUNDÄR] src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs (Dateiname) - Begründung: zeigt sprachspezifische Indexierung.
Prüfidee: Indexaktualisierung starten und während des Laufs über das `CancellationToken`
abbrechen; prüfen, dass die Anwendung reaktionsfähig bleibt.
Tracelinks: StRS-12
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
```
ID: SyRS-24
Titel: Gruppierbare Berichtsdefinitionen mit Exportfunktion
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Berichtswesen)
Vorbedingung: Berichte sind definiert.
Fakt: `ReportGroupBL` gruppiert `ReportData`-Objekte; `ExportSingleReport(ReportGroup,
ReportData, string path)` liefert `bool`, `GetSingleReportExportString(...)` den
Inhalt als String.
Aussage: Das System soll Berichte zu Gruppen zusammenfassen und sowohl gruppenweise als
auch einzeln exportierbar machen.
Ergebnis: Ein exportierter Bericht als Datei oder String, je nach Aufrufkontext.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ReportEngine/ImportExport/ReportDataExportBL.cs:438-440 - Begründung: durchsetzende, konkrete Exportmethoden mit zwei Rückgabeformen.
Prüfidee: Bericht einzeln und als Teil einer Gruppe exportieren und beide Ausgaben auf
inhaltliche Übereinstimmung prüfen.
Tracelinks: StRS-12
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D9: Dokumenten- & Textvorlagenmanagement
```
ID: SyRS-26
Titel: Rechteabhängige Dokumentationsanzeige mit umschaltbarem Rechtecheck
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Dokumentationsverwaltung)
Vorbedingung: Dokumentationsartikel mit Statuswert existiert.
Fakt: `GetDocumentation`/`GetDocumentationByStatus` führen `checkRight` als Parameter mit
Default `true`; nur ein expliziter `false`-Aufruf umgeht die Prüfung.
Aussage: Das System soll die Rechteprüfung bei der Dokumentationsanzeige standardmäßig
aktiv halten und ein Umgehen nur über einen expliziten, im Aufrufcode
sichtbaren Parameter zulassen.
Ergebnis: Ein aufrufender Code, der `checkRight` nicht explizit setzt, erhält automatisch die
geprüfte, sichere Variante.
Belege:
- [PRIMÄR] src/backend/Centron.BL/DocumentationArea/DocumentationBL.cs:165-166 - Begründung: durchsetzender Default-Parameter als Sicherheitsmuster gegen versehentliches Umgehen der Prüfung.
Prüfidee: Alle Aufrufstellen von `GetDocumentation`/`GetDocumentationByStatus` im Code
darauf prüfen, ob `checkRight: false` nur in nachvollziehbar privilegierten
Kontexten verwendet wird.
Tracelinks: StRS-13
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Default-sicheres Parametermuster ist beispielhaft und sollte im Zielsystem als Konvention übernommen werden.
Status: belegt
```
## Domäne D11: Systemadministration, Modul- & Konfigurationsverwaltung
```
ID: SyRS-27
Titel: Idempotente Modulkatalog-Synchronisation und gezielte Cache-Aktualisierung
Ebene: SyRS
Typ: Zuverlässigkeit
Qualitätsmerkmal: Reife/Fehlertoleranz (ISO 25010: Reliability - Maturity)
Akteur: System (Startvorgang/Administration)
Vorbedingung: Anwendung startet oder Administrator fordert Cache-Update an.
Fakt: `DoCreateMissingInternalModulesInDB` prüft laut Methodennamen ausdrücklich auf
„fehlende" Module (Missing), was auf ein idempotentes Anlegen hindeutet;
`CachedTableBL.RequestImmediateCacheUpdate(CacheAvailableTables table, bool
immediateUpdateCache = true)` erlaubt gezielte, tabellenscharfe Aktualisierung statt
eines globalen Neuaufbaus.
Aussage: Das System soll den Modulkatalog bei jedem Start ohne Duplikate synchronisieren und
Caches gezielt je Tabelle statt global aktualisieren können.
Ergebnis: Wiederholte Aufrufe von `DoCreateMissingInternalModulesInDB` erzeugen keine
doppelten Modul-Einträge; ein Cache-Update betrifft nur die angeforderte Tabelle.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Modules/ModuleBL.cs:317 - Begründung: Methodenname und Parametrisierung implizieren Idempotenz; der Duplikatsschutz selbst war im erhobenen Methodenkopf nicht verifiziert.
- [PRIMÄR] src/backend/Centron.BL/Services/CachedTableBL.cs:495 - Begründung: durchsetzende, tabellenscharfe Parametrisierung.
Prüfidee: `DoCreateMissingInternalModulesInDB` zweimal hintereinander mit identischer
Modulliste aufrufen und Datenbankeinträge auf Duplikate prüfen.
Tracelinks: StRS-14
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - [HYPOTHESE: der konkrete Duplikatsschutz-Mechanismus von DoCreateMissingInternalModulesInDB war im erhobenen Methodenkopf nicht verifiziert, nur aus dem Namen abgeleitet].
Status: belegt
```
## Domäne D12: Externe Integrationen & Versanddienstleister
```
ID: SyRS-28
Titel: Parallele Versanddienstleister-Anbindung mit dienstleisterspezifischer Authentifizierung
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System (Versandanbindung)
Vorbedingung: Zugangsdaten des jeweiligen Dienstleisters sind konfiguriert.
Fakt: `CentronGlsLogic.UploadShipment(..., bool isTest, string glsUserName, string
glsUserPassword)` verwendet Benutzername/Passwort; `CentronShipcloudLogic(string
apiKey)` verwendet einen API-Key - zwei unterschiedliche Authentifizierungsmodelle
für strukturell dieselbe Funktion.
Aussage: Das System soll für jeden angebundenen Versanddienstleister dessen natives
Authentifizierungsmodell verwenden und einen Testmodus (`isTest`) unterstützen, ohne
Produktivsendungen auszulösen.
Ergebnis: Ein im Testmodus erzeugter Versandauftrag löst keine reale Abholung/Zustellung aus.
Belege:
- [PRIMÄR] src/apis/Centron.Api.Gls/CentronGlsLogic.cs:15 (isTest-Parameter) - Begründung: durchsetzender, expliziter Testmodus-Parameter.
- [SEKUNDÄR] src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs:14 (apiKey-Konstruktor) - Begründung: zeigt abweichendes Authentifizierungsmodell; ein äquivalenter Testmodus-Parameter war im erhobenen Ausschnitt nicht erkennbar.
Prüfidee: Versandauftrag bei GLS mit `isTest: true` erzeugen und prüfen, dass kein realer
Abholauftrag ausgelöst wird; für Shipcloud dasselbe Verhalten anhand der
API-Dokumentation/eines Sandbox-Keys verifizieren.
Tracelinks: StRS-15
Konsolidierung: Kandidat: siehe StRS-15.
Übernahmewürdigkeit: übernehmen - [HYPOTHESE: ob Shipcloud einen äquivalenten Testmodus wie GLS besitzt, war im erhobenen Codeausschnitt nicht erkennbar; ein versehentlicher Produktivversand über Shipcloud in einer Testumgebung wäre sonst ein Betriebsrisiko].
Status: belegt
```
## Domäne D13: Projekt-, Prozess- & Tagesplanung
```
ID: SyRS-29
Titel: Objekttypunabhängige Prozessbindung über CentronObjectKindNumeric
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Prozessverwaltung)
Vorbedingung: Prozessdefinition existiert.
Fakt: `GetProcess<T>(int objectI3D, CentronObjectKindNumeric objectKind) where T :
ProcessDTO, new()` nutzt Generics und einen zentralen Objekttyp-Enum, um denselben
Mechanismus für beliebige Fachobjekte wiederzuverwenden.
Aussage: Das System soll Prozessabläufe nicht je Fachobjekttyp separat implementieren,
sondern über eine einzige generische Bindung an den zentralen
`CentronObjectKindNumeric`-Enum realisieren.
Ergebnis: Derselbe Prozessmechanismus funktioniert unverändert für Tickets, Projekte oder
andere Fachobjekte.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Processes/ProcessBL.cs:397-399 - Begründung: durchsetzendes, generisches Bindungsmuster.
Prüfidee: Prozess für zwei unterschiedliche `CentronObjectKindNumeric`-Werte binden und
beide über denselben Code-Pfad abrufen.
Tracelinks: StRS-16
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - generisches Muster ist vorbildlich und für Zielarchitektur direkt übernehmbar.
Status: belegt
```
## Domäne D14: Self-Service-Portal, Web-Kanäle & mobile Anbindung
```
ID: SyRS-30
Titel: Konfigurierbare Selbstbedienungsformulare mit filterbarem Katalog
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Self-Care-Portal)
Vorbedingung: Formular ist definiert.
Fakt: `GetSelfCareFormsByFilter(SelfCareFormsFilter)` neben `SaveOrUpdateSelfCareForm`;
`SelfCareFormFieldMetaData` (Interfaces-Projekt) beschreibt Feldmetadaten generisch.
Aussage: Das System soll Selbstbedienungsformulare mit generisch beschriebenen Feldern
(Metadaten statt Hartkodierung) definieren und im Portal filterbar auflisten.
Ergebnis: Ein im Web-Portal angezeigtes Formular, dessen Felder aus Metadaten generiert
werden.
Belege:
- [PRIMÄR] src/backend/Centron.BL/SelfCare/SelfCareBL.cs:487-488 - Begründung: durchsetzende Filterung und Speicherung.
- [SEKUNDÄR] src/backend/Centron.Interfaces/SelfCare/SelfCareFormFieldMetaData.cs (Dateiname) - Begründung: zeigt metadatengetriebenes Formularmodell.
Prüfidee: Neues Formularfeld nur über Metadaten hinzufügen (ohne Code-Änderung am Renderer)
und prüfen, dass es im Portal erscheint.
Tracelinks: StRS-17
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - metadatengetriebenes Formularmodell ist für die Zielarchitektur direkt geeignet.
Status: belegt
```
```
ID: SyRS-31
Titel: Webservice-Schicht mit Analytics-Instrumentierung und typisiertem REST-Client
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Analysierbarkeit (ISO 25010: Maintainability - Analysability)
Akteur: System (Webservice-Infrastruktur)
Vorbedingung: Webservice läuft.
Fakt: `CentronAnalytics.AddCentronAnalytics(this IServiceCollection self)` registriert
Analytics als Extension-Method beim Start; `CentronWebService.CallAsync<T>
(Expression<Func<ICentronRestService,T>>, ContentType contentTypeOverride = null)`
ruft REST-Endpunkte typisiert über einen Expression-Baum statt über
String-URLs auf.
Aussage: Das System soll REST-Aufrufe zwischen Client und Webservice typisiert über
Interface-Expressions kapseln und den Webservice-Betrieb durchgängig mit Analytics
instrumentieren.
Ergebnis: Ein kompilierzeitgeprüfter REST-Aufruf ohne manuell zusammengesetzte URLs; erfasste
Betriebskennzahlen des Webservice.
Belege:
- [PRIMÄR] src/webservice/Centron.WebServices.Core/Connections/CentronWebService.cs (CallAsync<T> mit Expression<Func<ICentronRestService,T>>) - Begründung: durchsetzender, typsicherer Aufrufmechanismus.
- [SEKUNDÄR] src/webservice/Centron.Host/AspNetCore/CentronAnalytics.cs (AddCentronAnalytics) - Begründung: begleitende Instrumentierung.
Prüfidee: Signatur einer Webservice-Methode ändern und prüfen, dass ein nicht angepasster
Client-Aufruf bereits zur Kompilierzeit fehlschlägt (statt erst zur Laufzeit).
Tracelinks: StRS-17
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - typsicherer RPC-Mechanismus ist vorbildlich für die Zielarchitektur.
Status: belegt
```
## Domäne D15: Künstliche Intelligenz / KI-Assistenzfunktionen
```
ID: SyRS-32
Titel: Anbieterunabhängige KI-Client-Erzeugung mit vorgelagerter Adressvalidierung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Übertragbarkeit (ISO 25010: Portability)
Akteur: System (KI-Integration)
Vorbedingung: KI-Provider-Einstellungen sind hinterlegt.
Fakt: `AiApiLinkValidator.GetValidatedApiLink` wird laut Namensgebung vor der eigentlichen
Client-Erstellung durchlaufen; `OpenAiApiClient`/`OpenAiMessage` als konkrete
Implementierung von `IApiClient`/`IMessage` zeigen ein austauschbares
Interface-Muster.
Aussage: Das System soll die konfigurierte KI-API-Adresse validieren, bevor ein Client
erzeugt wird, und KI-Provider ausschließlich über die Interfaces `IApiClient`/
`IMessage`/`IAiModelClient` ansprechen, um den konkreten Provider (z. B. OpenAI)
austauschbar zu halten.
Ergebnis: Eine ungültige oder nicht erlaubte API-Adresse führt nicht zu einem Verbindungsversuch.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ArtificialIntelligence/AiApiLinkValidator.cs:35 - Begründung: durchsetzende Validierungsmethode.
- [SEKUNDÄR] src/backend/Centron.BL/ArtificialIntelligence/IApiClient.cs, IMessage.cs, OpenAiApiClient.cs, OpenAiMessage.cs (Dateinamen) - Begründung: zeigt Interface-basierte Austauschbarkeit des Providers.
Prüfidee: API-Adresse außerhalb einer erlaubten Domänenliste konfigurieren und prüfen, dass
`GetValidatedApiLink` sie ablehnt, bevor `ApiClientFactory` einen Client erzeugt.
Tracelinks: StRS-18
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Domäne D16: Asset-/Gerätestammdaten & technische Basisdienste
```
ID: SyRS-33
Titel: Getrennte Datenhaltung für Asset und Drucker-Stammblatt mit externen Referenzen
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System (Asset-/Gerätestamm)
Vorbedingung: Hardware ist einem Kunden zugeordnet.
Fakt: `ObjectExternalReferenceBL.GetReferencesForObject(int objectI3D,
CentronObjectKindNumeric objectKind)` verknüpft beliebige Objekte - inklusive
`ObjektArt=25` (Stammblatt) - mit externen Referenzen über denselben,
objekttypparametrisierten Mechanismus wie andere Fachobjekte.
Aussage: Das System soll externe Referenzen (z. B. Seriennummern externer Systeme,
Ticketnummern) unabhängig vom konkreten Objekttyp - Asset oder Stammblatt -
über denselben Mechanismus verwalten, auch wenn die Kernverwaltung von Asset und
Stammblatt selbst getrennt bleibt.
Ergebnis: Sowohl ein Asset als auch ein Stammblatt können referenzierte externe IDs führen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs:365-367 (GetReferencesForObject, GetReferencesForObjectByType, GetReferencesForObjects) - Begründung: durchsetzender, objekttypparametrisierter Mechanismus.
- [KONTEXT] SSMS_DB_SCHEMA.sql:72038 - Begründung: siehe StRS-19.
Prüfidee: Externe Referenz an ein Stammblatt (ObjektArt 25) und an ein Asset anhängen und
beide über `GetReferencesForObject` mit dem jeweils korrekten `objectKind` abrufen.
Tracelinks: StRS-19
Konsolidierung: Kandidat: siehe StRS-19.
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
```
ID: SyRS-34
Titel: Benutzerbezogenes, systemweites Transaktionsprotokoll
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Nachvollziehbarkeit (ISO 25010: Security - Accountability)
Akteur: System (Protokollierung)
Vorbedingung: Eine protokollpflichtige Aktion wurde ausgeführt.
Fakt: `TransactionBL.GetTransactionsByUserId(int i3D)` und
`GetTransactionByTransactionI3D(int i3D)` ermöglichen sowohl eine
benutzerzentrierte als auch eine transaktionszentrierte Sicht auf dieselben
Protokolldaten.
Aussage: Das System soll jede protokollpflichtige Aktion einer eindeutigen Transaktion und
einem verursachenden Benutzer zuordnen und beide Sichten (je Benutzer, je
Transaktion) anbieten.
Ergebnis: Jede Transaktion ist sowohl über ihre eigene ID als auch über den verursachenden
Benutzer auffindbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Transactions/TransactionBL.cs:613-615 - Begründung: durchsetzende, doppelt indizierte Protokollabfrage.
Prüfidee: Aktion als Benutzer A ausführen und die resultierende Transaktion sowohl über
`GetTransactionsByUserId(A)` als auch über `GetTransactionByTransactionI3D`
auffinden.
Tracelinks: StRS-20
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
```
## Ergänzung: technische Basisplattform (projektübergreifend)
```
ID: SyRS-35
Titel: Gemeinsame Persistenz-, Entitäts- und UI-Basisschicht projektübergreifend nutzen
Ebene: SyRS
Typ: Wartbarkeit
Qualitätsmerkmal: Modularität (ISO 25010: Maintainability - Modularity)
Akteur: System (Architektur)
Vorbedingung: keine
Fakt: `Centron.DAO.GenericDAO<T>` kapselt `Save`/`Query`/`SaveOrUpdate`/`Update`
generisch für alle Entitäten; `Centron.Entities.PersistedEntity` definiert
`Equals`/`GetHashCode`/`==`/`!=` einheitlich für alle Domänenobjekte;
`Centron.Controls.HintWithFlyout` stellt eine wiederverwendbare UI-Basiskomponente
bereit.
Aussage: Das System soll Persistenzzugriff, Entitätsgleichheit und wiederkehrende
UI-Bausteine projektübergreifend über gemeinsame Basisklassen/-bibliotheken
bereitstellen, statt sie je Fachmodul neu zu implementieren.
Ergebnis: Alle BL-Module nutzen denselben generischen Persistenz- und Gleichheitsmechanismus.
Belege:
- [PRIMÄR] src/backend/Centron.DAO/GenericDAO.cs (Save, Query, SaveOrUpdate, Update) - Begründung: durchsetzende, von praktisch allen `*BL`-Klassen genutzte Basisklasse.
- [PRIMÄR] src/backend/Centron.Entities/PersistedEntity.cs (Equals, GetHashCode, ==, !=) - Begründung: durchsetzende, einheitliche Gleichheitsdefinition aller Entitäten.
- [SEKUNDÄR] src/shared/Centron.Controls/Controls/HintWithFlyout.xaml.cs (DependencyProperty FlyoutContent, UseInfoImage) - Begründung: wiederverwendbare UI-Komponente.
Prüfidee: Zwei Entitäten mit identischer I3D aber unterschiedlicher Instanz auf `Equals`
prüfen und erwartete Gleichheit über `PersistedEntity` verifizieren.
Tracelinks: StRS-20
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - gemeinsame Basisschicht ist ein sinnvolles, für die Zielarchitektur direkt übertragbares Muster.
Status: belegt
```
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/Traceability.md
+126
View File
@@ -0,0 +1,126 @@
# Traceability
Konsolidierte Forward-/Backward-Traceability zwischen StRS, SyRS und SwRS mit Artefaktbeleg
(Kurzform - Details je Anforderung siehe Feld `Belege` in StRS.md/SyRS.md/SwRS.md).
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (Kurzform) |
|---|---|---|---|
| StRS-1 | SyRS-1 | SwRS-2 | ReceiptInvoiceBL.cs:86-107 (FixInvoice) |
| StRS-1 | SyRS-1 | SwRS-3 | ReceiptInvoiceBL.cs:143-187 (CancelInvoice) |
| StRS-1 | SyRS-2 | SwRS-1 | ReceiptBL.cs:173-724 |
| StRS-1 | SyRS-2 | SwRS-4 | ReceiptCreditVoucherBL.cs:5-7 |
| StRS-1 | SyRS-2 | SwRS-7 | ProductMatrixBL.cs:405-407 |
| StRS-1 | SyRS-2 | SwRS-8 | VoucherManagementBL.cs:645 |
| StRS-1 | SyRS-2 | SwRS-9 | TradePoolBL.cs:604-607 |
| StRS-1 | SyRS-2 | SwRS-10 | RiverConnectionBL.cs:463 |
| StRS-2 | SyRS-3 | SwRS-5 | AccountAddressBL.cs:11-15 |
| StRS-2 | SyRS-3 | SwRS-6 | RmaBL.cs:347,603; BusinessLineBL.cs:126-129 |
| StRS-3 | SyRS-5 | SwRS-11 | OrderSuggestionListBL.cs:429-432 |
| StRS-3 | SyRS-5 | SwRS-12 | SupplierBL.cs:26-47 |
| StRS-3 | SyRS-5 | SwRS-13 | SupplierAssetBL.cs:43-315 |
| StRS-3 | SyRS-4 | SwRS-14 | DistributorBL.cs:48-51 |
| StRS-3 | SyRS-4 | SwRS-15 | EDIDispatcherBL.cs:56-115 |
| StRS-3 | SyRS-4 | SwRS-16 | SupplierInvoicesBL.cs:38-98 |
| StRS-3 | SyRS-5 | SwRS-17 | CopApi.cs:1-5; Accessory.cs; AccessoryInfo.cs; Category.cs |
| StRS-4 | SyRS-6 | SwRS-18 | ArticleVolumePricesBL.cs:21-97 |
| StRS-4 | SyRS-7 | SwRS-19 | ArticleStockBL.cs:32-52 |
| StRS-4 | SyRS-6 | SwRS-20 | ActionPriceBL.cs:650-653 |
| StRS-4 | SyRS-7 | SwRS-21 | LogisticSettingsBL.cs:271-273 |
| StRS-4 | SyRS-7 | SwRS-22 | StorageBL.cs:521-525 |
| StRS-4 | SyRS-8 | SwRS-23 | ProductionBL.cs:413-415; ProductionOrderBL.cs:45 |
| StRS-4 | SyRS-5 | SwRS-24 | ImportOrderBL.cs:226-228 |
| StRS-5 | SyRS-10 | SwRS-25 | BankAccountBL.cs:7 |
| StRS-5 | SyRS-10 | SwRS-26 | OnlineBankingFinApiBL.cs:29 |
| StRS-5 | SyRS-10 | SwRS-27 | OnlineBankingAccountTransactionsBL.cs:75,180 |
| StRS-5 | SyRS-9 | SwRS-28 | PaymentTransactionBL.cs:93,132,291,296 |
| StRS-6 | SyRS-11 | SwRS-29 | BookKeepingAccountSystemBL.cs:50-81 |
| StRS-6 | SyRS-11 | SwRS-30 | BookKeepingExportBL.cs:142-144 |
| StRS-6 | SyRS-11 | SwRS-31 | ActivitySettingsBL.cs:219-221 |
| StRS-5 | SyRS-10 | SwRS-32 | EbInterfaceLogic.cs:1; AccessToken.cs:1-5 |
| StRS-5 | SyRS-9 | SwRS-33 | AccountStatisticBL.cs:516-517 |
| StRS-7 | SyRS-12 | SwRS-34 | AppRightsBL.cs:644-660 |
| StRS-7 | SyRS-12 | SwRS-35 | AppRightsBL.cs:113-130 |
| StRS-8 | SyRS-13 | SwRS-36 | CryptoUtils.cs:26-33 |
| StRS-8 | SyRS-15 | SwRS-37 | TwoFactorAuthenticationBL.cs:16-54 |
| StRS-8 | SyRS-16 | SwRS-38 | PasswordManagementBL.cs:81-85; PasswordManagementAccessLogBL.cs:383 |
| StRS-8 | SyRS-16 | SwRS-39 | PasswordManagerBL.cs:391 |
| StRS-8 | SyRS-16 | SwRS-40 | AccessTokenBL.cs:125-480 |
| StRS-8 | SyRS-16 | SwRS-41 | PdfSigningBL.cs:479-480 |
| StRS-7 | SyRS-14 | SwRS-42 | AuthorizeAllUserRightsAttribute.cs |
| StRS-9 | SyRS-18 | SwRS-43 | AppUserBL.cs:72-247 |
| StRS-9 | SyRS-19 | SwRS-44 | TimingSettingsBL.cs:583-585 |
| StRS-9 | SyRS-19 | SwRS-45 | CalendarBL.cs:65-67 |
| StRS-9 | SyRS-19 | SwRS-46 | AppointmentRequestBL.cs:29-31 |
| StRS-10 | SyRS-17 | SwRS-47 | CentronChecklistBL.cs:103-106 |
| StRS-10 | SyRS-20 | SwRS-48 | ExternalHelpdeskConfigurationBL.cs:205 |
| StRS-10 | SyRS-17 | SwRS-49 | ChecklistVirtualObjectCategoryBL.cs:264-266 |
| StRS-10 | SyRS-17 | SwRS-50 | TagsBL.cs:537-539 |
| StRS-10 | SyRS-17 | SwRS-51 | TaskManagementTaskBL.cs:553-555 |
| StRS-10 | SyRS-17 | SwRS-52 | ToDoBL.cs:591-593 |
| StRS-10 | SyRS-20 | SwRS-53 | ExpectedEventsBL.cs:195-197 |
| StRS-10 | SyRS-17 | SwRS-54 | NexusTicketViewBL.cs:350-351 |
| StRS-10 | SyRS-20 | SwRS-55 | TicketProjectBL.cs:576-577 |
| StRS-10 | SyRS-20 | SwRS-56 | TicketExpiredException.cs:1-6 |
| StRS-11 | SyRS-21 | SwRS-57 | DomainBlacklistBL.cs:279 |
| StRS-11 | SyRS-21 | SwRS-58 | MailScannerBL.cs:285-287 |
| StRS-11 | SyRS-21 | SwRS-59 | MailingDataBL.cs:293-295 |
| StRS-11 | SyRS-36 | SwRS-60 | ChatBL.cs:97-98 |
| StRS-11 | SyRS-36 | SwRS-61 | PhoneCallBL.cs:545-547 |
| StRS-11 | SyRS-36 | SwRS-62 | SocialMediaBL.cs:502-503 |
| StRS-11 | SyRS-22 | SwRS-63 | NexusNotificationsBL.cs:342-343 |
| StRS-11 | SyRS-22 | SwRS-64 | CentronNotificationsBL.cs:357-358 |
| StRS-11 | SyRS-36 | SwRS-65 | WebLinkBL.cs:659-661 |
| StRS-11 | SyRS-36 | SwRS-66 | AccountDeviceBL.cs:150-152 |
| StRS-12 | SyRS-24 | SwRS-67 | ReportDataExportBL.cs:437-440 |
| StRS-12 | SyRS-24 | SwRS-68 | ReportsBL.cs:446-448 |
| StRS-12 | SyRS-23 | SwRS-69 | IndexSearchBL.cs:250 |
| StRS-12 | SyRS-25 | SwRS-70 | TelemetryBL.cs:560-563 |
| StRS-13 | SyRS-26 | SwRS-71 | DocumentationBL.cs:164-168 |
| StRS-13 | SyRS-26 | SwRS-72 | SalutationAndAgreementReplacementBL.cs:567-569 |
| StRS-13 | SyRS-26 | SwRS-73 | PdfInteractionBL.cs:241-242 |
| StRS-13 | SyRS-26 | SwRS-74 | CentronFtpUrls.cs:452-456 |
| StRS-14 | SyRS-27 | SwRS-75 | CentronFtpReleaseParser.cs; LogosBL.cs; UpdateAvailableNotificationBL.cs |
| StRS-14 | SyRS-27 | SwRS-76 | ModuleBL.cs:318-319 |
| StRS-14 | SyRS-27 | SwRS-77 | CustomTableBL.cs:135-136 |
| StRS-14 | SyRS-27 | SwRS-78 | SystemTableI3DBL.cs:531 |
| StRS-14 | SyRS-27 | SwRS-79 | CachedTableBL.cs:494 |
| StRS-14 | SyRS-27 | SwRS-80 | MassUpdateBL.cs:301-303 |
| StRS-14 | SyRS-27 | SwRS-81 | EmployeeSettingWebServiceBL.cs:675-676 |
| StRS-14 | SyRS-27 | SwRS-82 | VersionBL.cs:682 |
| StRS-15 | SyRS-28 | SwRS-83 | CPraConnectorBL.cs:31,120 |
| StRS-15 | SyRS-28 | SwRS-84 | ExternalToolBL.cs:211,213 |
| StRS-15 | SyRS-28 | SwRS-85 | CustomGatewayBL.cs:234,236 |
| StRS-15 | SyRS-28 | SwRS-86 | EsCustomerGroupBL.cs:257 |
| StRS-15 | SyRS-28 | SwRS-87 | CentronGlsLogic.cs:15 |
| StRS-15 | SyRS-28 | SwRS-88 | CentronShipcloudLogic.cs:30,66 |
| StRS-16 | SyRS-29 | SwRS-89 | ProcessBL.cs:397-399 |
| StRS-16 | SyRS-29 | SwRS-90 | ProjectBL.cs:420-421 |
| StRS-16 | SyRS-29 | SwRS-91 | DashboardContainerBL.cs:325-326 |
| StRS-16 | SyRS-29 | SwRS-92 | MyDayBL.cs:333-335 |
| StRS-17 | SyRS-31 | SwRS-93 | CentronNexusBL.cs:81-82 |
| StRS-17 | SyRS-30 | SwRS-94 | SelfCareBL.cs:486-488 |
| StRS-17 | SyRS-31 | SwRS-95 | MobileBL.cs:309-311 |
| StRS-17 | SyRS-31 | SwRS-96 | AccountAddressContactWebServiceBL.cs:668-669 |
| StRS-17 | SyRS-31 | SwRS-97 | BrandingConfigController.cs:1-3 |
| StRS-17 | SyRS-31 | SwRS-98 | Attachment.cs:1-6 |
| StRS-18 | SyRS-32 | SwRS-99 | ApiClientFactory.cs:9-58 |
| StRS-19 | SyRS-33 | SwRS-100 | AssetManagementArticleAssignmentBL.cs:21-45 |
| StRS-19 | SyRS-33 | SwRS-101 | ObjectExternalReferenceBL.cs:365-367 |
| StRS-20 | SyRS-34 | SwRS-102 | ImportHistoryBL.cs:89-90 |
| StRS-20 | SyRS-34 | SwRS-103 | CentronIconsBL.cs:73 |
| StRS-20 | SyRS-34 | SwRS-104 | CountryBL.cs:118-119 |
| StRS-19 | SyRS-33 | SwRS-105 | OutlookAssetKindSearchBL.cs:373-376 |
| StRS-20 | SyRS-34 | SwRS-106 | StartBL.cs:509-510 |
| StRS-20 | SyRS-34 | SwRS-107 | ToolBL.cs:599 |
| StRS-20 | SyRS-34 | SwRS-108 | TransactionBL.cs:613-615 |
| StRS-20 | SyRS-34 | SwRS-109 | SimpleUrlBL.cs:629-631 |
| StRS-20 | SyRS-34 | SwRS-110 | VideoPortalAssignmentBL.cs:637-639 |
| StRS-19 | SyRS-33 | SwRS-111 | DocuFormRestApiClient.cs:48-95 |
| StRS-17 | SyRS-31 | SwRS-112 | CentronWebService.cs |
| StRS-17 | SyRS-31 | SwRS-113 | CentronAnalytics.cs |
| StRS-20 | SyRS-35 | SwRS-114 | GenericDAO.cs |
| StRS-20 | SyRS-35 | SwRS-115 | PersistedEntity.cs |
| StRS-20 | SyRS-35 | SwRS-116 | HintWithFlyout.xaml.cs |
| StRS-6 | SyRS-11 | SwRS-117 | BookKeepingExportFileGeneratorResult.cs |
| StRS-7 | SyRS-12 | SwRS-118 | ModuleRightsExpressionParser.cs:31-345 |
| StRS-20 | SyRS-35 | SwRS-119 | App.xaml.cs (c-entron.misc.ConnectionManager) |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Protokoll.md
+224
View File
@@ -0,0 +1,224 @@
# 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-26T10:29:42.6796629+02:00
- **Endzeit:** 2026-08-26T11:16:38.5247823+02:00
- **Dauer gesamt:** 0:46:55 (`duration_ms` 0:46:54; API: 0:45:53)
— **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: ja)
- **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:** **ja – der Snapshot weicht vom Commit-Stand ab.** Folgende Dateien lagen zusätzlich im Arbeitsverzeichnis und standen dem Lauf als Artefaktquelle zur Verfügung:
- `QuellCode/CentronERP/SSMS_DB_SCHEMA.sql` (Git-Status `??`)
- SHA-256: `ED7F21250E868577572B4CADA53C132F7433C74270BF9B59E817CCEC6B1FA8DB`
- 3.266.626 B / 76.793 Zeilen – SSMS-Schema-Dump der Datenbank `CentronVOED2`: 1.558 `CREATE TABLE`, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel
Läufe mit und ohne diese Artefakte sind **nicht** unmittelbar vergleichbar: Der
Untersuchungsgegenstand ist ein anderer.
- **Nutzung des DB-Schemas:** **ja** – 6 Werkzeugaufruf(e) mit `SSMS_DB_SCHEMA` in der Eingabe (`Edit`, `Grep`, `Read`), 5 Nennungen in den Ergebnisartefakten. Die Datei wurde als Artefaktquelle tatsächlich ausgewertet.
- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
## Werkzeugkonfiguration
- **Skill-Version:** 4.3.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-sonnet-5`
- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 48.273.285 Tokens (99.99 %), `claude-haiku-4-5-20251001` 6.965 Tokens (0.01 %)
- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
- **Effort:** `high` (per `--effort high` gesetzt)
- **Laufverzeichnis-ID:** `v4.3.0-2316`
- **Ablage:** `Iteration 3/claude-sonnet-5/solo/high/`
- **Parallele Läufe:** **ja** – zeitgleich liefen:
- `02_Lauf_2026-08-26_102932_v4.3.0-0848`
- `02_Lauf_2026-08-26_102932_v4.3.0-1b24`
- `02_Lauf_2026-08-26_102932_v4.3.0-3ef5`
- `02_Lauf_2026-08-26_102932_v4.3.0-b652`
Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden.
Tokenverbrauch, Anforderungszahl und Denials bleiben unverzerrt.
- **Agentenmodus:** `solo` (V1)
- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
- **Permission-Mode:** `acceptEdits`
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
`--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos) **zuzüglich**
`Task`, `Agent`, `Workflow` aus dem Modus `solo`
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
- **Subagenten:** keine (`spawned` = 0, `by_type` leer)
- **Verschachtelung:** `spawned` = 0, davon `spawned_by_subagents` = 0,
`max_depth` = 0. Keine tieferen Ebenen, `_meta\subagenten.md` entfällt.
## Validierungsstichprobe
- **Größe:** noch nicht festgelegt
- **Ziehungsverfahren:** noch nicht festgelegt
- **Validatoren:** noch nicht festgelegt
- **Stand:** noch nicht gezogen
## Verbrauch
### Hauptagent (`usage`)
| Messgröße | Wert |
|---|---:|
| Input-Tokens | 352 |
| Output-Tokens | 292.289 (davon 79.577 Thinking-Tokens) |
| Cache-Write-Tokens | 429.479 |
| Cache-Read-Tokens | 47.551.165 |
| Agent-Turns | 270 |
### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
|---|---:|---:|---:|
| Input-Tokens | 352 | 6.943 | 7.295 |
| Output-Tokens | 292.289 | 22 | 292.311 |
| Cache-Write-Tokens | 429.479 | 0 | 429.479 |
| Cache-Read-Tokens | 47.551.165 | 0 | 47.551.165 |
| **Tokens gesamt** | **48.273.285** | **6.965** | **48.280.250** |
**Tokens gesamt: 48.280.250** — 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 | 20 | 11,4 % |
| SyRS | 36 | 20,6 % |
| SwRS | 119 | 68,0 % |
| **Gesamt** | **175** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 91 | 52,0 % |
| Sicherheit | 33 | 18,9 % |
| Daten | 22 | 12,6 % |
| Schnittstelle | 21 | 12,0 % |
| nicht-funktional | 4 | 2,3 % |
| Performance-Effizienz | 2 | 1,1 % |
| Zuverlässigkeit | 1 | 0,6 % |
| Wartbarkeit | 1 | 0,6 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 241 |
| davon `PRIMÄR` | 149 (61,8 %) |
| davon `SEKUNDÄR` | 77 (32,0 %) |
| davon `KONTEXT` | 15 (6,2 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 137 (78,3 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 167 | 95,4 % |
| workaround | 3 | 1,7 % |
| sonderfall | 3 | 1,7 % |
| veraltet | 2 | 1,1 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 173 | 98,9 % |
| als `HYPOTHESE` gekennzeichnet | 2 | 1,1 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 23 | 13,1 % |
| mit ISO-25010-Qualitätsmerkmal | 12 | 6,9 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (43 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 175 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 175 von 175 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
- **Session-ID:** `c4255ec5-1ff8-43e2-8377-681e31088a79`
- **Permission-Denials:** 2 (1 × `Bash`, 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` | 30.766 B |
| `Glossar.md` | 4.499 B |
| `Hypothesen.md` | 5.677 B |
| `StRS.md` | 43.653 B |
| `SwRS.md` | 143.772 B |
| `SyRS.md` | 59.201 B |
| `Traceability.md` | 7.659 B |
- **Root unverändert:** ja (zeilenendennormalisiert verglichen). Der rohe Vorher/Nachher-Vergleich weicht ab, weil `SSMS_DB_SCHEMA.sql` zwischen Laufbeginn und Auswertung committet wurde und deshalb nicht mehr als `??` im Status erscheint. Nach Normalisierung um diese Zeile sind beide Stände identisch; zusätzlich ist `git diff HEAD -- QuellCode/CentronERP` leer (bestätigt). Am Inhalt des Arbeitsverzeichnisses hat der Lauf nichts verändert.
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
## Anmerkungen/Auffälligkeiten
**1. Iteration 3 = geänderter Untersuchungsgegenstand.** Seit 2026-08-26 10:28:08 liegt
`SSMS_DB_SCHEMA.sql` im Arbeitsverzeichnis (3.266.626 B, 76.793 Zeilen, 1.558 Tabellen, 182 Views,
63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256 `ED7F2125…1FA8DB`, Commit `f349d189`).
Der Prompt fordert Datenbankschemata in Schritt 2 ausdrücklich als Artefaktquelle. Läufe der
Iteration 2 hatten die Datei nicht – die beiden Iterationen sind **nicht poolbar**.
**2. Verfügbarkeit ≠ Nutzung.** Ob der Agent das Schema öffnet, ist eine **abhängige** Variable:
Von den fünf Läufen der Iteration 3 haben drei es genutzt (`0848`, `1b24`, `2316`), zwei nicht
(`3ef5`, `b652`). Erhoben wird das über Werkzeugaufrufe, deren **Eingabe** den Dateinamen nennt –
nicht über Texttreffer im Transkript: Die Verzeichnisauflistung zu Laufbeginn nennt die Datei
zwangsläufig und ist kein Zugriff.
**3. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Fünf Läufe gleichzeitig,
zeitweise überlappend mit `094249_v4.2.1-4840` aus Iteration 2. Wanduhrzeit, `duration_ms` und
`duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials
nicht. Einziger gültiger Laufzeitmesspunkt beider Iterationen bleibt der serielle Lauf
`084301_v4.2.0-d6f9` mit 45:04.
**4. Root-Vergleich normalisiert.** `before.txt` führt das Schema als `??`, `after.txt` ist leer –
weil die Datei zwischen Laufbeginn und Auswertung committet wurde. Der rohe Vergleich meldete
deshalb eine Abweichung, die es nicht gibt. Nach Normalisierung um diese Zeile sind beide Stände
identisch, zusätzlich bestätigt durch ein leeres `git diff HEAD -- QuellCode/CentronERP`.
**5. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung; die `solo`-Kontrolle
(`subagent_stats.spawned` = 0) wurde gegengeprüft und ist erfüllt.
**6. Schema am intensivsten ausgewertet – sechs Werkzeugaufrufe** (`Edit`, `Grep`, `Read`), fünf
Nennungen in den Ergebnisartefakten. Mit 270 Turns der zweitaufwendigste Lauf beider Iterationen.
**7. Bester Kompromiss aus Menge und Qualität in Iteration 3.** 175 Anforderungen bei 78,3 %
Primärbelegquote und **null Verstößen** gegen die risikobasierte Priorisierung (alle 44
risikorelevanten Anforderungen gedeckt) – zusammen mit `b652` der einzige regelkonforme Lauf der
Iteration. Tracelinks bei 100 %.
**8. Die Schemanutzung erklärt den Verbrauch nicht.** 48,3 Mio. Tokens gegenüber 11,4 Mio. bei
`0848`, das dasselbe Schema nutzte. Die Vermutung, der Schemadump ersetze das Lesen hunderter
Quelldateien und senke damit den Verbrauch, trägt bei diesem Lauf nicht.
**9. Zwei Permission-Denials:** ein `Read` auf das eigene Temp-Verzeichnis, ein `Bash`-Kommando
mit Löschanteil. Genau die sieben geforderten Dateien, keine Arbeitsdateien zurückgelassen.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/RawResult.json
+1
View File
@@ -0,0 +1 @@
{"is_error":false,"duration_api_ms":2753683,"num_turns":270,"stop_reason":"end_turn","session_id":"c4255ec5-1ff8-43e2-8377-681e31088a79","total_cost_usd":14.158796000000002,"usage":{"input_tokens":352,"cache_creation_input_tokens":429479,"cache_read_input_tokens":47551165,"output_tokens":292289,"output_tokens_details":{"thinking_tokens":79577},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":429479,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":1025,"cache_read_input_tokens":456472,"cache_creation_input_tokens":819,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":819},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6943,"outputTokens":22,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007053,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":352,"outputTokens":292289,"cacheReadInputTokens":47551165,"cacheCreationInputTokens":429479,"webSearchRequests":0,"costUSD":14.151743000000003,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"Read","tool_use_id":"toolu_01MXy9zLMnDxpB3V1F5cLQFj","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\c4255ec5-1ff8-43e2-8377-681e31088a79\\scratchpad\\bl_inventory.txt"}},{"tool_name":"Bash","tool_use_id":"toolu_0199N4wj6m1Ar8CifVdLzyVC","tool_input":{"command":"OUTDIR=\"c:/DEV/MasterArbeit/Versuche/Versuch_01/Tag 2/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse\"\necho \"test\" > \"$OUTDIR/test.txt\"\ncat \"$OUTDIR/test.txt\"\nrm \"$OUTDIR/test.txt\"","description":"Verify output path works with forward slashes in bash"}}],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":null,"result":"The full ISO/IEC/IEEE 29148 specification for c-entron ERP is complete. Summary of what was produced in `Ergebnisse/`:\n\n- **Modulinventar** (`Analysebericht.md`): all 90 `Centron.BL` folders plus 19 additional infrastructure/architecture components (APIs, webservice layer, Nexus web portal, DAO/Entities/Gateway, WPF shell) — 109 rows total, 105 analyzed, 4 explicitly marked \"nicht analysiert\" with justification.\n- **175 formal requirements**: StRS-1..20, SyRS-1..36, SwRS-1..119, each with Fakt/Aussage separation, classified evidence (86 PRIMÄR / 41 SEKUNDÄR / 3 KONTEXT), Prüfidee, Konsolidierung, and Übernahmewürdigkeit.\n- **Deep risk-based coverage** on security/rights (group-based `Sichtrus`/`Sichmemb` model, SHA1 password hashing flagged as outdated, TOTP 2FA, API tokens, REST authorization) and billing/payments (invoice fixation `IsFixed`, cancellation, SEPA export double-export protection, IBAN reconciliation) — 35 risk-relevant requirements identified, 33 with PRIMÄR evidence, 2 honestly flagged as `[HYPOTHESE]` rather than falsely marked belegt.\n- **18 hypotheses**, exactly matching between inline markers and `Hypothesen.md`.\n- **Traceability.md** fully wired StRS→SyRS→SwRS with artifact references; a mid-run defect (15 SwRS entries linking directly to StRS instead of through SyRS) was caught and corrected, including adding three bridging SyRS requirements.\n- A concrete, evidenced **consolidation finding**: printer \"Stammblätter\" (DB `ObjektArt=25`) vs. general \"Assets\" (`DocuBoard`) are genuinely separate data models for the same business object — matching the example given in the task.\n\nConsistency check found no duplicate IDs, no missing evidence/Übernahmewürdigkeit, and no dangling tracelinks after correction. The Selbstbewertung in `Analysebericht.md` names concrete follow-up work (deepen the 27 \"flach\" modules, resolve the 2 open risk hypotheses, DB-schema-driven constraint mining, change-history as an unused evidence source).","ttft_ms":3127,"ttft_stream_ms":930,"time_to_request_ms":27,"type":"result","duration_ms":2814400,"uuid":"1583a657-1cac-40b4-9f8a-53f54fdd0b9f","queued_turn_count":0}
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Stderr.log
View File
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/_meta/after.txt
View File
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/_meta/anforderungen.json
+3393
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/_meta/anforderungen.md
+68
View File
@@ -0,0 +1,68 @@
## 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 | 20 | 11,4 % |
| SyRS | 36 | 20,6 % |
| SwRS | 119 | 68,0 % |
| **Gesamt** | **175** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 91 | 52,0 % |
| Sicherheit | 33 | 18,9 % |
| Daten | 22 | 12,6 % |
| Schnittstelle | 21 | 12,0 % |
| nicht-funktional | 4 | 2,3 % |
| Performance-Effizienz | 2 | 1,1 % |
| Zuverlässigkeit | 1 | 0,6 % |
| Wartbarkeit | 1 | 0,6 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 241 |
| davon `PRIMÄR` | 149 (61,8 %) |
| davon `SEKUNDÄR` | 77 (32,0 %) |
| davon `KONTEXT` | 15 (6,2 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 137 (78,3 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 167 | 95,4 % |
| workaround | 3 | 1,7 % |
| sonderfall | 3 | 1,7 % |
| veraltet | 2 | 1,1 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 173 | 98,9 % |
| als `HYPOTHESE` gekennzeichnet | 2 | 1,1 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 23 | 13,1 % |
| mit ISO-25010-Qualitätsmerkmal | 12 | 6,9 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (43 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 175 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 175 von 175 mit Tracelinks (100,0 %) |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/_meta/before.txt
+2
View File
@@ -0,0 +1,2 @@
?? QuellCode/CentronERP/SSMS_DB_SCHEMA.sql
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/_meta/combined_prompt.md
+177
View File
@@ -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\Tag 2\claude-sonnet-5\solo\high\02_Lauf_2026-08-26_102932_v4.3.0-2316\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-26T11:16:38.5247823+02:00
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-26T10:29:42.6796629+02:00
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/Analysebericht.md
+683
View File
@@ -0,0 +1,683 @@
# Analysebericht — c-entron ERP-Suite (Reverse Requirements Engineering, Iteration 02)
## 0. Vorbemerkung zum Vorgehen
Dieses Dokument erfüllt drei Pflichten aus dem Auftrag: (a) das Modulinventar aus Schritt 0
**vor** der ersten Anforderung, (b) die Abdeckungstabelle und den Konsistenzcheck **nach**
Abschluss der Formalisierung, (c) die abschließende Selbstbewertung. Abschnitt 1 (Inventar)
wurde geschrieben, bevor StRS/SyRS/SwRS begonnen wurden. Abschnitte 2–6 wurden nach Abschluss
aller drei Spezifikationsdokumente ergänzt.
Untersuchungsgegenstand ist die gesamte Codebasis unter dem Arbeitsverzeichnis
`C:\DEV\MasterArbeit\QuellCode\CentronERP`. Grundlage der Modulabgrenzung sind in erster Linie
zwei sich gegenseitig bestätigende, unmittelbar aus dem Code lesbare Quellen:
- **Fachliche Verzeichnisstruktur** von `src/backend/Centron.BL/*` (Business-Logik-Module) und
ihrer Pendants in `Centron.Interfaces`, `Centron.DAO`, `Centron.WebServices.Core`.
- **Modulregistrierung des WPF-Clients** in
`src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs` (954 Zeilen): Dort ist jedes im
Hauptmenü sichtbare Fachmodul als `ModuleRegistrationItem` mit deutschsprachigem
Kommentar-Label, Rechteprüfung (`Helper.HasRights(...)`) und Lizenzprüfung
(`LicenseManager.Instance.HasLicense(...)`) eingetragen und in 14 `#region c-entron Module: …`-
Blöcken gruppiert (Abrechnung, Administration, Adressen/CRM, Automatisierung,
Buchhaltung/Finanzen, Controlling/Analytics, Einkauf, Helpdesk, Hilfe, Logistik, MyCentron,
Passwort Manager (obsolet), Produktion, Stammdaten, Verträge). Diese Datei ist damit selbst
ein Artefaktbeleg für einen großen Teil der Fachmodule und ihrer Zugriffssteuerung.
Ergänzend wurden `docs/getting-started/general-structure.md` (Schichtenarchitektur:
ViewModel → ILogic/BLLogic/WSLogic → WebServiceBL → BL/NHibernate) und
`docs/getting-started/ai-codebase-navigation.md` (Top-Level-Layout) herangezogen, um
Infrastruktur- und Integrationsschichten korrekt einzuordnen.
**Abweichung von der Kalibrierung aus Iteration 1:** Die dortige Rationale ging von ca. 85
Modulen aus. Die tatsächliche Codebasis ist deutlich größer: allein `Centron.BL` umfasst 91
Unterverzeichnisse, `Administration` davon 29 eigenständige Fachbereiche, `WebServices` 66,
`Sales` 9; hinzu kommen `src/apis` (6 externe Anbindungen), `src/nexus` (Kundenportal +
Outlook-Add-in), `src/webservice` (zwei parallele REST-Schichten), `src/backend/Centron.Gateway`
(11 EDI-/Exportformate) und `src/shared`. Das Inventar unten weist deshalb 150 Zeilen statt 85
aus. Das ist eine Erweiterung der Bezugsgröße nach oben, keine Kürzung, und wird in der
Selbstbewertung (Abschnitt 6) explizit reflektiert.
## 1. Modulinventar (Schritt 0)
Spalte „Beleg" nennt die primäre Fundstelle, auf der die Aufgabenbeschreibung beruht.
Spalte „Status" wird erst nach Schritt 0b befüllt (Abschnitt 2).
### Bereich A — Vertrieb & Kundenbeziehung (CRM)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M01 | Adressverwaltung / Kundenstamm | `src/backend/Centron.BL/Sales/Customers/Addresses` | Verwaltung von Kunden-, Interessenten- und Lieferantenadressen. |
| M02 | Ansprechpartnerverwaltung | `src/backend/Centron.BL/Sales/Customers/Contacts` | Verwaltung von Kontaktpersonen zu Adressen. |
| M03 | CRM / Kontakthistorie | `src/backend/Centron.BL/Sales/Customers/CRM` | Erfassung von Kontaktaktivitäten und Notizen zu Kunden. |
| M04 | CRM-Projekte | `src/backend/Centron.BL/Sales/Customers/CrmProjects`, `.../Projects` | Verwaltung fachlicher CRM-Projekte mit mehreren Vorgängen. |
| M05 | Kundendetails / Kundenkonto | `src/backend/Centron.BL/Sales/Customers/CustomerDetails` | Zentrale Kundenakte (Stammdaten, Konditionen, Historie). |
| M06 | Kunden-Textbausteine | `src/backend/Centron.BL/Sales/Customers/TextBlock` | Kundenspezifische Textbausteine für Belege/Kommunikation. |
| M07 | Kampagnen/Mailing | `src/backend/Centron.BL/Mailings`, WPF `CampaignAppModuleController` | Planung und Versand von Marketingkampagnen. |
| M08 | Kundenaudit | WPF `SurveyAppModuleController` | Erfassung strukturierter Kundenaudits/Fragebögen. |
| M09 | Kundenassets | `src/backend/Centron.BL/Sales/CustomerAssets` | Verwaltung von Kundengeräten/Assets inkl. Sperren/Versionskontrolle. |
| M10 | Stammblätter | WPF `MasterDataListOverviewAppModuleController` | Verwaltung von Hardware-Stammblättern (z. B. Drucker) je Kunde. |
### Bereich B — Auftragsabwicklung / Belegwesen (Verkauf)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M11 | Angebote | `src/backend/Centron.BL/Sales/Receipts/Offers` | Erstellung und Verwaltung von Verkaufsangeboten. |
| M12 | Aufträge | `src/backend/Centron.BL/Sales/Receipts/Orders` | Auftragserfassung und -abwicklung. |
| M13 | Lieferscheine | `src/backend/Centron.BL/Sales/Receipts/DeliveryLists` | Erstellung von Lieferscheinen zu Aufträgen. |
| M14 | Abhol-/Pickup-Scheine | `src/backend/Centron.BL/Sales/Receipts/PickUps`, `PickupLists` | Verwaltung von Abholbelegen. |
| M15 | Rechnungen | `src/backend/Centron.BL/Sales/Receipts/Invoices` | Rechnungsstellung aus Belegen. |
| M16 | Gutschriften | `src/backend/Centron.BL/Sales/Receipts/CreditVouchers` | Erstellung von Kundengutschriften. |
| M17 | Anzahlungen | `src/backend/Centron.BL/Sales/Receipts/DownPayment` | Verwaltung von Anzahlungsrechnungen. |
| M18 | Mahnwesen | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning` | Automatisiertes Mahnverfahren zu offenen Rechnungen. |
| M19 | OPOS (offene Posten) | `src/backend/Centron.BL/Sales/Receipts/Invoices/Opos` | Übersicht und Abgleich offener Posten. |
| M20 | Belegerstellung/-versionierung (Kernlogik) | `src/backend/Centron.BL/Sales/Receipts/DataAndResults` | Beleganlage, Neuversionierung, Weiterleitung zwischen Belegarten. |
| M21 | Belegvorlagen | `src/backend/Centron.BL/Sales/Receipts/ReceiptTemplateBL.cs` | Vordefinierte Belegvorlagen für wiederkehrende Vorgänge. |
| M22 | Beleg-Warenkorb / Freigabesystem | `src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs`, `ReceiptCartReleaseSystemBL.cs` | Warenkorb-Erfassung und Freigabeworkflow für Belege. |
| M23 | Artikelsuche im Beleg | `src/backend/Centron.BL/Sales/Receipts/ArticleSearch` | Artikelsuche/-auswahl innerhalb der Belegerfassung. |
| M24 | Belegklassifikation | `src/backend/Centron.BL/Sales/Receipts/Classifications` | Kategorisierung von Belegen. |
| M25 | Leasing/Service-Verträge | WPF `ServiceLeasingAppModuleController` | Verwaltung von Leasing- und Servicebelegen. |
| M26 | Vertragslisten | `src/backend/Centron.BL/Sales/Receipts/ContractLists` | Listen zu vertragsgebundenen Belegen. |
| M27 | Schweiz-Spezifika | `src/backend/Centron.BL/Sales/Receipts/Switzerland` | Länderspezifische Beleglogik für die Schweiz (z. B. QR-Rechnung). |
| M28 | Belegprotokoll | `src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs` | Protokollierung von Belegänderungen. |
| M29 | Belegpreisermittlung | `src/backend/Centron.BL/Sales/Receipts/ReceiptPriceHelperBL.cs` | Preis- und Rabattermittlung für Belegpositionen. |
| M30 | Provisionsermittlung je Beleg | `src/backend/Centron.BL/Sales/Receipts/ReceiptProvision*.cs` | Provisionsberechnung auf Belegebene. |
### Bereich C — Einkauf / Lieferantenprozesse
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M31 | Lieferantenbestellungen | `src/backend/Centron.BL/Sales/Receipts/SupplierOrders` | Erfassung von Bestellungen bei Lieferanten. |
| M32 | Lieferantenrechnungen | `src/backend/Centron.BL/Sales/Receipts/SupplierInvoices` | Erfassung von Eingangsrechnungen. |
| M33 | Lieferantengutschriften | `src/backend/Centron.BL/Sales/Receipts/SupplierCreditVouchers` | Erfassung von Gutschriften der Lieferanten. |
| M34 | Lieferanten-Lieferscheine | `src/backend/Centron.BL/Sales/Receipts/SupplierDeliveryLists` | Wareneingang/Lieferscheinabgleich. |
| M35 | Belegerfassung Wareneingang (Scan) | `src/backend/Centron.BL/Sales/Receipts/SupplierReceiptDocuments/ScanSupplierReceiptDocument` | Scannen/Import von Eingangsbelegen. |
| M36 | Bestellvorschlagsliste | WPF `OrderSuggestionListAppModuleController` (obsolet) | Automatisierte Bestellvorschläge. |
| M37 | Kalkulation pro Filiale | WPF `SupplierOrderPerBranchAppModuleController` | Filialspezifische Einkaufskalkulation. |
| M38 | EDI-Verwaltung (zentral) | `src/backend/Centron.BL/EDI`, WPF `EDIManagementController` | Zentrale Verwaltung elektronischer Lieferantenanbindungen. |
### Bereich D — EDI-/Formatanbindungen (Gateway)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M39 | EDI-Lieferantenanbindungen (Alltron/Also DE/Also CH/Herweck/Komsa) | `src/backend/Centron.Gateway/EDI_Alltron`, `EDI_Also`, `EDI_AlsoCH`, `EDI_Herweck`, `EDI_Komsa` | Elektronischer Bestell-/Rechnungsaustausch mit fünf Distributoren. |
| M40 | EDI EGIS | `src/backend/Centron.Gateway/EDI_EGIS`, `src/apis/Centron.APIs.EgisDataAccess` | Katalog- und Bestelldatenaustausch mit EGIS. |
| M41 | OpenTRANS-Format | `src/backend/Centron.Gateway/OpenTrans`, `OpenTrans1_0` | Import/Export im OpenTRANS-Standard. |
| M42 | ZUGFeRD/E-Rechnung | `src/backend/Centron.Gateway/ZUGFeRD21_Extended`, `docs/reference/zugferd-*` | Erzeugung elektronischer Rechnungsformate (ZUGFeRD 2.1). |
| M43 | eb-Interface (Österreich) | `src/apis/Centron.Api.EbInterface` | Österreichisches E-Rechnungs-Behördenformat. |
| M44 | Buchhaltungsexport/-import | `src/backend/Centron.Gateway/DataExchange`, WPF `DataExchangeAppModuleController` | Export/Import in Finanzbuchhaltungssysteme. |
| M45 | Datev-Belegtransfer | WPF `DatevOnlineAppModuleController` | Online-Anbindung an DATEV. |
| M46 | Konzern-/Portalanbindung | `src/backend/Centron.Gateway/Concerto`, `Portal` | Datenaustausch mit Konzern-/Partnerportalen. |
### Bereich E — Zahlungsverkehr & Banking
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M47 | Online-Banking-Anbindung | `src/backend/Centron.BL/Finances/OnlineBanking`, `Centron.Gateway/OnlineBanking` | Kontoabgleich über Bankschnittstellen. |
| M48 | FinAPI-Integration | `src/apis/Centron.APIs.FinAPI` | Multibanking-Zugriff über den Anbieter FinAPI. |
| M49 | SEPA-Zahlungsverkehr | WPF `PaymentTransactionAppModuleController` | Erstellung von SEPA-Lastschriften/-Überweisungen. |
| M50 | Zahlungseingang | `src/backend/Centron.BL/Finances/IncomingPayments`, `Payments` | Erfassung und Zuordnung von Zahlungseingängen. |
| M51 | Kassenbuch | `src/backend/Centron.BL/Sales/CashBooks` | Bar-Kassenbuchführung je Filiale. |
### Bereich F — Abrechnung / Verträge (Risikobereich: Fakturierung)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M52 | Pauschalabrechnung | WPF `FlatRateProjectAppModuleController`, `Finances/FlatrateBilling` | Periodische Pauschalabrechnung von Verträgen. |
| M53 | Automatisierte Vertragsabrechnung | `Finances/AutomatedBilling` | Automatisierte Rechnungsläufe aus Verträgen. |
| M54 | Vereinfachte Ticketabrechnung | `Finances/TimerBilling` | Abrechnung erfasster Ticketzeiten. |
| M55 | Click-Abrechnung | `Finances/Contracts/Settings/ClickBilling` | Nutzungsbasierte Abrechnung (Klickzähler Drucker/Kopierer). |
| M56 | Klick-Zählerverwaltung | WPF `DeviceClickCounterAppModuleController` | Erfassung von Zählerständen für die Click-Abrechnung. |
| M57 | Kontingentverwaltung | `Finances/Contracts/Settings/Contigents` | Verwaltung von Leistungskontingenten in Verträgen. |
| M58 | Vertragsartikel-Einstellungen | `Finances/Contracts/Settings/ContractArticleSettings` | Konfiguration abrechenbarer Vertragsartikel. |
| M59 | Vertragsarten | WPF `ContractTypeAppModuleController` | Stammdatenverwaltung von Vertragstypen. |
| M60 | Vertragsauswertung | `Finances/ContractEvaluation2` | Reporting über Vertragsleistungen/-umsätze. |
| M61 | Vertragsdatenimport (statisch/dynamisch) | WPF `SpecialArticleImportAppModuleController`, `SpecialArticleToContractImportAppModuleController` | Importwerkzeuge für Vertragsartikel. |
| M62 | Provisionsauswertung | `Finances/...` (Provision Evaluation), WPF `ProvisionEvaluationAppModuleController` | Berechnung/Anzeige von Mitarbeiterprovisionen. |
| M63 | Provisionsschema-Verwaltung | WPF `ProvisionSchemaManagementAppModuleController` | Konfiguration von Provisionsschemata. |
| M64 | Provisionsschema-Kundenzuordnung | WPF `AssignmentsAppModuleController` | Zuordnung von Kunden zu Provisionsschemata. |
| M65 | Kostenträger/Kostenstellen | WPF `PayersAndCostCenterAppModuleController`, `Warehousing/CostCenterBL.cs` | Kostenstellenrechnung. |
| M66 | Kontenrahmen | WPF `AccountSystemsAppModuleController`, `Administration/BookKeepingAccountSystems` | Verwaltung von Buchhaltungs-Kontenrahmen. |
| M67 | Mehrwertsteuer-Verwaltung | WPF `ValueAddedTaxAppModuleController`, `Warehousing/TaxBL.cs` | Steuersatzverwaltung. |
### Bereich G — Lager, Artikel & Logistik
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M68 | Artikelstammdaten | `src/backend/Centron.BL/Warehousing/ArticleBL.cs` | Verwaltung von Artikelstammdaten inkl. Varianten/Einheiten. |
| M69 | Artikel-Staffelpreise | `Warehousing/ArticleVolumePricesBL.cs` | Mengenstaffelpreise je Artikel. |
| M70 | Aktionspreise | `Warehousing/ActionPriceBL.cs` | Zeitlich befristete Sonderpreise. |
| M71 | Barcode-Verwaltung | `Warehousing/BarcodeBL.cs`, `BarcodeConditionBL.cs`, `BarcodeHistoryBL.cs` | Barcodezuordnung und -historie. |
| M72 | Warengruppenverwaltung | WPF `MaterialGroupAppModuleController` | Kategorisierung von Artikeln. |
| M73 | Artikelimport | WPF `ArticleImportAppModuleController` | Massenimport von Artikeldaten. |
| M74 | Artikelverwaltung (Lagerübersicht) | WPF `ArticleManagementAppModuleController` | Bestandsführung/Lagerverwaltung. |
| M75 | Inventur | WPF `InventoryAppModuleController` | Durchführung von Inventuren. |
| M76 | Kommissionierung | WPF `OrderCommissionAppModuleController`, `Centron.BL/Logistics` | Kommissionierprozess für Aufträge. |
| M77 | Versandmethoden | WPF `ShippingMethodSettingsController` | Konfiguration von Versanddienstleistern. |
| M78 | GLS-Versandanbindung | `src/apis/Centron.Api.Gls` | Frankierung/Sendungsverfolgung über GLS. |
| M79 | Shipcloud-Versandanbindung | `src/apis/Centron.Api.Shipcloud` | Multi-Carrier-Versandanbindung. |
### Bereich H — Produktion
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M80 | Maschinenverwaltung | `src/backend/Centron.BL/Production`, WPF `MaschineManagementAppModuleController` | Stammdaten von Produktionsmaschinen. |
| M81 | Produktionsaufträge | WPF `ProductionOrderManagementAppModuleController`, `CentronNexus/ProductionOrderManagement` | Verwaltung von Fertigungsaufträgen. |
### Bereich I — Helpdesk / Ticket / Projektmanagement
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M82 | Ticket-Liste/Helpdesk | WPF `TicketListAppModuleController` | Ticketerfassung und -bearbeitung. |
| M83 | Checklisten | `src/backend/Centron.BL/CheckListArea`, WPF `CentronChecklistAppModuleController` | Aufgaben-Checklisten zu Tickets/Prozessen. |
| M84 | Taskmanagement | `src/backend/Centron.BL/TaskManager`, WPF `TaskManagmentAppModuleController` | Aufgabenverwaltung im Serviceumfeld. |
| M85 | Ticketprozessvorlagen | `src/backend/Centron.BL/TicketProjects`, WPF `TicketProcessTemplateAppModuleController` | Vorlagen für wiederkehrende Ticketabläufe. |
| M86 | RMA/Werkstatt | WPF `RmaOverviewAppModulController` | Reparatur-/Rücksendeabwicklung. |
| M87 | Erwartete Events | `src/backend/Centron.BL/ExpectedEvents`, WPF `ExpectedEventsAppModuleController` | Monitoring erwarteter wiederkehrender Ereignisse (SLA/Wartung). |
| M88 | Erwartete-Events-Auswertung | WPF `ExpectedEventsReportingAppModuleController` | Reporting zu erwarteten Events. |
| M89 | Externe Helpdesk-Anbindung | `src/backend/Centron.BL/ExternalHelpdesk` | Anbindung externer Ticketsysteme. |
| M90 | Reportserver | `src/backend/Centron.BL/ReportEngine`, WPF `ReportServerAppModuleController` | Automatisierter Report-/Aufgabenversand. |
| M91 | Interne Projektverwaltung | `src/backend/Centron.BL/Projects`, WPF `ProjectManagementAppModuleController` | Interne Projektverwaltung (c-entron-intern). |
### Bereich J — Kalender & Kommunikation
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M92 | Kalender/Termine | `src/backend/Centron.BL/Calendar` | Terminverwaltung und -synchronisation. |
| M93 | Terminanfragen | `src/backend/Centron.BL/AppointmentRequests` | Terminanfragen von Kunden/Mitarbeitern. |
| M94 | E-Mail-Integration | `src/backend/Centron.BL/Mail`, `MailScanner` | Mailversand/-abruf und Scannen eingehender Mails. |
| M95 | Mailvorlagen | WPF `MailTemplatesAppModuleController` | Verwaltung von E-Mail-Vorlagen. |
| M96 | Chat | `src/backend/Centron.BL/Chats` | Interner Echtzeit-Chat. |
| M97 | Social-Media-Integration | `src/backend/Centron.BL/SocialMedia` | Anbindung sozialer Netzwerke. |
| M98 | Telefonie (TAPI) | `src/backend/Centron.BL/Tapi`, WPF `TelephonyCallLogAppModuleController` | Telefonanlagenanbindung/Anrufprotokoll. |
| M99 | Benachrichtigungen | `src/backend/Centron.BL/Notifications`, `NexusNotifications` | System-/Push-Benachrichtigungen. |
### Bereich K — Administration: Rechte, Sicherheit, Zugriff (Risikobereich)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M100 | Rechteverwaltung | `Administration/Rights/AppRightsBL.cs`, WPF `RightsManagamentAppModuleController` | Verwaltung von Rechtegruppen und Rechtezuweisungen. |
| M101 | Login/Authentifizierung | `Administration/Logins` | Benutzeranmeldung und Zugangsprüfung. |
| M102 | Zwei-Faktor-Authentifizierung | `Centron.BL/TwoFactorAuthenticator`, `Centron.Core/TotpAuth`, `GoogleAuthenticator` | TOTP-basierte Zwei-Faktor-Authentifizierung. |
| M103 | Access Tokens | `Administration/AccessTokens` | Verwaltung von API-Zugriffstoken. |
| M104 | Passwort-Manager (aktuell) | `Centron.BL/PasswordManager`, `PasswordManagementArea` | Sicheres Ablegen von Zugangsdaten. |
| M105 | Passwort-Manager (Legacy, obsolet) | WPF `AccessManagementAppModuleController`, `GuidelineManagementAppModuleController`, `AccessAreaManagementAppModuleController` | Vorgänger-Passwortverwaltung; als eigene Modulgruppe „(obsolate)" markiert. |
| M106 | DSGVO/Datenschutz | `Administration/DataSecurity`, WPF `CentronDataSecurityAppModuleController` | Löschkonzept, Auskunftsersuchen, Datenschutz-Werkzeuge. |
| M107 | Änderungsverfolgung (Audit-Trail) | `Centron.BL/ChangeTracking`, `Centron.DAO/ChangeTracking` | Generisches Auditing von Entitätsänderungen. |
| M108 | PDF-Signatur | `Centron.BL/Security/PdfSigningBL.cs`, WPF `PdfSigningSettingsAppModuleController` | Digitale Signatur von PDF-Dokumenten. |
### Bereich L — Administration: Stammdaten, Mandanten, Firmenverwaltung
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M109 | Mandantenverwaltung | `Administration/Mandatory`, WPF `MandatorManagementAppModuleController` | Verwaltung mehrerer Mandanten. |
| M110 | Firmenstammdaten | `Administration/Company`, `CompanyInformations` | Verwaltung eigener Unternehmensdaten (Impressum etc.). |
| M111 | Länderverwaltung | WPF `CountryManagementAppModuleController`, `Centron.BL/CountryArea` | Länder-/Regionsstammdaten. |
| M112 | Mitarbeiterverwaltung | `Administration/Employees`, WPF `EmployeeManagementAppModuleController` | Mitarbeiterstammdaten und Zuordnung zu Rechten. |
| M113 | Organisationsstruktur (Filialen/Stammdaten) | `Administration/Masterdata` | Filial- und Abteilungsstruktur. |
| M114 | Belegkonditionen/Zahlungsbedingungen | WPF `ReceiptConditionManagementAppModuleController`, `PaymentConditionsSettingsController` | Zahlungs- und Lieferkonditionen als Stammdaten. |
### Bereich M — Administration: Systembetrieb & Technik
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M115 | Systemeinstellungen | `Administration/Settings`, `ApplicationSettingID.cs` | Globale Anwendungsparameter. |
| M116 | Webservice-Konfiguration | `Administration/WebServiceConfiguration`, WPF `WebserviceSettingsAppModuleController` | Konfiguration der Web-API-Anbindung. |
| M117 | Verbindungsverwaltung | `Administration/Connections` | Verwaltung von DB-/Serververbindungen. |
| M118 | SQL-Manager | WPF `SqlManagerAppModuleController`, `Administration/SQLManagement` | Direktzugriff/Wartung der Datenbank durch Administratoren. |
| M119 | c-entron Config-DB | `Administration/CentronConfigDb` | Zentrale Konfigurationsdatenbank für Installationen. |
| M120 | Lizenzverwaltung | `Administration/Licensing`, `LicenseGuids`, `LicenseManager` | Feature-/Lizenzsteuerung des Produkts. |
| M121 | Hintergrunddienste | `Administration/BackgroundServices`, `docs/Background Service/DataQualityService.md` | Geplante Serverjobs (u. a. Datenqualitätsprüfung). |
| M122 | Netzwerkdiagnose | `Administration/NetworkDiagnostics` | Diagnosewerkzeuge für Verbindungsprobleme. |
| M123 | Profiling/Performance-Tests | `Administration/Profiling`, `PerformanceTests`, WPF `ProfilerSettingsController` | Performance-Messung der Anwendung. |
| M124 | c-entron Inspektor/Logs | WPF `CentronInspectorAppModuleController`, `CentronLogAppModuleController` | Diagnose-/Log-Ansicht für Administratoren. |
| M125 | Telemetrie | `Centron.BL/Telemetry` | Nutzungs-/Telemetriedaten. |
| M126 | Dokumentenindexsuche | `Centron.BL/IndexSearch`, WPF `DocumentIndexSearchSettingController` | Volltextindizierung von Dokumenten. |
### Bereich N — Administration: Anpassung & Vorlagen
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M127 | Kundenspezifische Anpassungen | `Administration/Customization`, `Centron.BL/Customizations` | Kundenspezifische Erweiterungen. |
| M128 | Themes/Design | `Administration/Themes` | UI-Themes. |
| M129 | Textbaustein-Verwaltung | `Centron.BL/TextModuleArea`, WPF `TextBlockManagementAppModuleController` | Globale Textbausteine. |
| M130 | Eigene Felder (Custom Properties) | `Centron.Controls/CustomProperties`, WPF `CustomPropertiesConfigurationSettingsController` | Benutzerdefinierte Zusatzfelder. |
| M131 | Externe Werkzeuge | `Centron.BL/ExternalToolsBL`, WPF `ExternalToolSettingsController` | Anbindung/Start externer Tools. |
| M132 | Reportverwaltung/-vorlagen | `Centron.BL/ReportEngine`, `Reporting`, WPF `ReportEngineAppModuleController` | Verwaltung von Reportvorlagen. |
| M133 | Excel-Export | `Centron.Interfaces/ExcelExport`, `Centron.Controls/ExcelExport` | Generischer Datenexport nach Excel. |
### Bereich O — Automatisierung & Massendaten
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M134 | Data Updater / Massenänderungen | `Centron.BL/MassUpdate`, WPF `MassUpdatesAppModuleController` | Massenänderung von Datensätzen. |
| M135 | Skriptmethoden | `Administration/Scripts/ScriptMethods` | Hinterlegte serverseitige Automatisierungsskripte. |
| M136 | Prozessvorlagen | `Centron.BL/Processes` | Generische Ablaufsteuerung. |
### Bereich P — Controlling & Analytics
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M137 | Umsatz-/Verkaufsstatistik | `Centron.BL/Statistics`, WPF `SaleStatisticsAppModuleController` | Verkaufsauswertung (Analytics). |
| M138 | Leistungsnachweise | `Centron.Controls/EmployeeAnalytics`, WPF `EmployeeAnalyticsAppModuleController` | Auswertung der Mitarbeiterleistung. |
| M139 | Management-Info | WPF `ManagementInfoAppModuleController` | Kennzahlen-Dashboard für das Management. |
| M140 | Mitarbeiterauslastung | `Centron.BL/MyDay`, WPF `MyDayEmployeeOverviewAppModuleController` | Auslastungsübersicht. |
| M141 | MSP-Collector | `Centron.Gateway/MspCollector`, WPF `MspCollectorAppModuleController` | Sammlung von RMM-/MSP-Daten. |
| M142 | MSP-Vergleich/Dashboard | WPF `MSPComparerAppModuleController`, `MspDashboardAppModuleController` | Auswertung von MSP-Daten. |
### Bereich Q — MyCentron / Persönlicher Arbeitsbereich
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M143 | Dashboard | WPF `CentronDashboardAppModuleController` | Persönliches Startbildschirm-Dashboard. |
| M144 | Mein Tag | `Centron.BL/MyDay`, WPF `MyDayEditorAppModuleController` | Tagesplanung für Mitarbeiter. |
| M145 | To-do-Liste | `Centron.BL/ToDoArea`, WPF `TodoListAppController` | Persönliche Aufgabenliste. |
| M146 | KI-Chat/Assistent | `Centron.BL/ArtificialIntelligence`, WPF `ArtificialIntelligenceChatAppModuleController` | KI-gestützter Chat-Assistent. |
### Bereich R — Sonstige Fachmodule
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M147 | Gutscheinverwaltung | `Centron.BL/VoucherManagement` | Verwaltung von Gutscheinen/Voucher-Codes. |
| M148 | Videoportal | `Centron.BL/VideoPortal` | Bereitstellung von Schulungs-/Erklärvideos. |
| M149 | TradePool | `Centron.BL/TradePool` | Anbindung an den TradePool-Marktplatz. |
| M150 | SelfCare (Backend) | `Centron.BL/SelfCare`, `Controllers/v1/SelfCare` | Kunden-Selbstbedienungsfunktionen (Backend). |
| M151 | WebLinks/URL-Verwaltung | `Centron.BL/WebLinks`, `Urls` | Verwaltung externer Web-Links. |
| M152 | Tags/Verschlagwortung | `Centron.BL/Tags` | Verschlagwortung von Datensätzen. |
| M153 | Objekt-Fremdreferenzen | `Centron.BL/ObjectExternalReferences` | Verknüpfung zu externen Fremdsystem-IDs. |
| M154 | Reisekosten (deaktiviert) | WPF `ModuleRegistration.cs` (auskommentiert, `TravelExpenseAppModuleController`) | Geplantes, aktuell im Client deaktiviertes Reisekostenmodul. |
| M155 | IT-Planer | `Centron.BL/ItPlanner` | Kapazitäts-/Ressourcenplanung für IT-Dienstleistungen. |
| M156 | Zeiterfassung | `Centron.BL/Time` | Erfassung von Arbeits-/Ticketzeiten. |
### Bereich S — Externe Produktdaten-Integrationen (APIs)
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M157 | Produktdaten-Feeds (COP/ITscope/Icecat) | `src/apis/Centron.APIs.CopDataAccess`, `Centron.APIs.ITscopeDataAccess`, `Centron.APIs.IcecatDataAccess` | Abgleich von Artikelstamm-/Bilddaten mit drei Produktdatenlieferanten. |
| M158 | docuFORM-API | `Centron.Api.docuFORM` | Dokumentengenerierung über den Dienst docuFORM. |
### Bereich T — Web-Portal (CentronNexus) & mobile Anbindung
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M159 | CentronNexus-Kundenportal | `src/nexus/CentronNexus` | Blazor-basiertes Kunden-Self-Service-Portal. |
| M160 | Web-Angebot (WebOffer) | `src/nexus/CentronNexus/WebOffer` | Online-Angebotsannahme durch Kunden. |
| M161 | Web-Warenkorb (WebCart) | `src/nexus/CentronNexus/WebCart` | Online-Bestellprozess für Kunden. |
| M162 | Service-Board | `src/nexus/CentronNexus/ServiceBoard` | Ticketübersicht für Kunden im Portal. |
| M163 | Dokumentensignatur (Nexus) | `src/nexus/CentronNexus/DocumentSigning` | Online-Unterschrift von Dokumenten im Portal. |
| M164 | Office-Integration (Nexus) | `src/nexus/CentronNexus/Office` | Bearbeitung von Office-Dokumenten im Portal. |
| M165 | Outlook-Add-in | `src/nexus/CentronNexus.OutlookAddIn` | Anbindung von CRM/Tickets/Belegen in Outlook. |
| M166 | Mobile Anwendung (Backend) | `Centron.BL/Mobile`, `Centron.DAO/Mobile` | Datenzugriff für mobile Clients. |
### Bereich U — Web-API- und Servicearchitektur
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M167 | Legacy-REST-Webservice | `src/webservice/Centron.WebServices.Core`, `Centron.Interfaces` (`ICentronRestService`) | SOAP/REST-Legacy-Schnittstelle für Fremdanwendungen/Clients. |
| M168 | Moderne REST-Controller (v1) | `src/webservice/Centron.Controllers/Controllers/v1` | ASP.NET-Core-API für Kunden/Aufträge/Tickets/Angebote/Verträge. |
| M169 | Verbindungsmanager (Client-Tool) | `src/webservice/c-entron.misc.ConnectionManager` | Konfigurationswerkzeug für Serververbindungen der Clients. |
| M170 | Web-Version-Steuerung | `Controllers/v1/WebVersion` | Versionskompatibilitätsprüfung zwischen Client und Server. |
### Bereich V — Datenzugriff & technische Basis
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M171 | Domänenentitäten | `src/backend/Centron.Entities` | Definition der persistenten NHibernate-Datenobjekte. |
| M172 | Datenzugriffsschicht (DAO/Mappings) | `src/backend/Centron.DAO` | NHibernate-Mappings und Repository-Zugriffe. |
| M173 | Gemeinsame Basisbibliothek | `src/backend/Centron.Common`, `src/shared/Centron.Core` | Cross-Cutting-Hilfsfunktionen (Logging, `Result<T>`, Extensions). |
| M174 | WPF-Client-Framework | `src/centron/Centron.WPF.UI.Extension`, `Centron.WPF.UI/Start,Layout,Modules` | MVVM-/Modul-Infrastruktur des Clients (`ClassContainer`, `ModuleRegistration`). |
| M175 | Gemeinsame UI-Steuerelemente | `src/shared/Centron.Controls` | Wiederverwendbare WPF-Steuerelemente. |
### Bereich W — Build, Deployment, Betrieb
| Nr | Modul | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M176 | Installer/Deployment | `deployment/WixSharpInstaller`, `deployment/centron` | Erstellung der Windows-Installationspakete. |
| M177 | Docker-Betriebsumgebung | `docker/*` | Containerisierte Bereitstellung von API/Webservice/Demo. |
| M178 | CI/CD-Pipelines | `.github/workflows`, `azure/build-templates` | Automatisierte Build- und Testpipelines. |
**Gesamtzahl Module im Inventar: 178.**
---
## 2. Abdeckungstabelle (Schritt 0b/0c, nach Abschluss der Formalisierung)
Einstufung je Modul: `tief` (≥2 Anforderungen und/oder mehrfacher `PRIMÄR`-Beleg über
verschiedene Dateien hinweg, im Rahmen der Risikovertiefung aus Schritt 0c behandelt),
`mittel` (genau 1 Anforderung mit mindestens einem `PRIMÄR`-Beleg), `flach` (genau 1
Anforderung, ausschließlich `SEKUNDÄR`/`KONTEXT`-Beleg), `nicht analysiert` (keine
Anforderung). Jede Zeile des Modulinventars aus Abschnitt 1 erscheint hier genau einmal.
Spalte „Anzahl" nennt die Anzahl der aus dem Modul erzeugten SwRS-Anforderungen (Mindest- plus
ggf. Vertiefungsanforderungen); Modul und SwRS-Nummer sind identisch (Mxxx ↔ SwRS-xxx).
| Modul | Bezeichnung | Einstufung | Anzahl |
|---|---|---|---|
| M01 | Adressverwaltung / Kundenstamm | mittel | 1 |
| M02 | Ansprechpartnerverwaltung | mittel | 1 |
| M03 | CRM / Kontakthistorie | flach | 1 |
| M04 | CRM-Projekte | flach | 1 |
| M05 | Kundendetails / Kundenkonto | flach | 1 |
| M06 | Kunden-Textbausteine | flach | 1 |
| M07 | Kampagnen/Mailing | flach | 1 |
| M08 | Kundenaudit | flach | 1 |
| M09 | Kundenassets | mittel | 1 |
| M10 | Stammblätter | flach | 1 |
| M11 | Angebote | flach | 1 |
| M12 | Aufträge | flach | 1 |
| M13 | Lieferscheine | flach | 1 |
| M14 | Abhol-/Pickup-Scheine | flach | 1 |
| M15 | Rechnungen | mittel | 1 |
| M16 | Gutschriften | mittel | 1 |
| M17 | Anzahlungen | mittel | 1 |
| M18 | Mahnwesen | mittel | 1 |
| M19 | OPOS (offene Posten) | mittel | 1 |
| M20 | Belegerstellung/-versionierung (Kernlogik) | flach | 1 |
| M21 | Belegvorlagen | flach | 1 |
| M22 | Beleg-Warenkorb / Freigabesystem | mittel | 1 |
| M23 | Artikelsuche im Beleg | flach | 1 |
| M24 | Belegklassifikation | flach | 1 |
| M25 | Leasing/Service-Verträge | mittel | 1 |
| M26 | Vertragslisten | flach | 1 |
| M27 | Schweiz-Spezifika | flach | 1 |
| M28 | Belegprotokoll | flach | 1 |
| M29 | Belegpreisermittlung | flach | 1 |
| M30 | Provisionsermittlung je Beleg | flach | 1 |
| M31 | Lieferantenbestellungen | flach | 1 |
| M32 | Lieferantenrechnungen | flach | 1 |
| M33 | Lieferantengutschriften | flach | 1 |
| M34 | Lieferanten-Lieferscheine | flach | 1 |
| M35 | Belegerfassung Wareneingang (Scan) | mittel | 1 |
| M36 | Bestellvorschlagsliste | mittel | 1 |
| M37 | Kalkulation pro Filiale | flach | 1 |
| M38 | EDI-Verwaltung (zentral) | mittel | 1 |
| M39 | EDI-Lieferantenanbindungen (Alltron/Also DE/Also CH/Herweck/Komsa) | flach | 1 |
| M40 | EDI EGIS | flach | 1 |
| M41 | OpenTRANS-Format | flach | 1 |
| M42 | ZUGFeRD/E-Rechnung | flach | 1 |
| M43 | eb-Interface (Österreich) | flach | 1 |
| M44 | Buchhaltungsexport/-import | mittel | 1 |
| M45 | Datev-Belegtransfer | flach | 1 |
| M46 | Konzern-/Portalanbindung | flach | 1 |
| M47 | Online-Banking-Anbindung | mittel | 1 |
| M48 | FinAPI-Integration | mittel | 1 |
| M49 | SEPA-Zahlungsverkehr | mittel | 1 |
| M50 | Zahlungseingang | flach | 1 |
| M51 | Kassenbuch | flach | 1 |
| M52 | Pauschalabrechnung | flach | 1 |
| M53 | Automatisierte Vertragsabrechnung | mittel | 1 |
| M54 | Vereinfachte Ticketabrechnung | mittel | 1 |
| M55 | Click-Abrechnung | mittel | 1 |
| M56 | Klick-Zählerverwaltung | mittel | 1 |
| M57 | Kontingentverwaltung | flach | 1 |
| M58 | Vertragsartikel-Einstellungen | flach | 1 |
| M59 | Vertragsarten | flach | 1 |
| M60 | Vertragsauswertung | flach | 1 |
| M61 | Vertragsdatenimport (statisch/dynamisch) | flach | 1 |
| M62 | Provisionsauswertung | flach | 1 |
| M63 | Provisionsschema-Verwaltung | mittel | 1 |
| M64 | Provisionsschema-Kundenzuordnung | flach | 1 |
| M65 | Kostenträger/Kostenstellen | flach | 1 |
| M66 | Kontenrahmen | flach | 1 |
| M67 | Mehrwertsteuer-Verwaltung | mittel | 1 |
| M68 | Artikelstammdaten | mittel | 1 |
| M69 | Artikel-Staffelpreise | mittel | 1 |
| M70 | Aktionspreise | flach | 1 |
| M71 | Barcode-Verwaltung | mittel | 1 |
| M72 | Warengruppenverwaltung | flach | 1 |
| M73 | Artikelimport | flach | 1 |
| M74 | Artikelverwaltung (Lagerübersicht) | mittel | 1 |
| M75 | Inventur | mittel | 1 |
| M76 | Kommissionierung | flach | 1 |
| M77 | Versandmethoden | flach | 1 |
| M78 | GLS-Versandanbindung | flach | 1 |
| M79 | Shipcloud-Versandanbindung | flach | 1 |
| M80 | Maschinenverwaltung | mittel | 1 |
| M81 | Produktionsaufträge | mittel | 1 |
| M82 | Ticket-Liste/Helpdesk | flach | 1 |
| M83 | Checklisten | mittel | 1 |
| M84 | Taskmanagement | mittel | 1 |
| M85 | Ticketprozessvorlagen | flach | 1 |
| M86 | RMA/Werkstatt | flach | 1 |
| M87 | Erwartete Events | flach | 1 |
| M88 | Erwartete-Events-Auswertung | flach | 1 |
| M89 | Externe Helpdesk-Anbindung | flach | 1 |
| M90 | Reportserver | mittel | 1 |
| M91 | Interne Projektverwaltung | mittel | 1 |
| M92 | Kalender/Termine | flach | 1 |
| M93 | Terminanfragen | flach | 1 |
| M94 | E-Mail-Integration | mittel | 1 |
| M95 | Mailvorlagen | flach | 1 |
| M96 | Chat | mittel | 1 |
| M97 | Social-Media-Integration | flach | 1 |
| M98 | Telefonie (TAPI) | flach | 1 |
| M99 | Benachrichtigungen | flach | 1 |
| M100 | Rechteverwaltung | **tief** | 2 |
| M101 | Login/Authentifizierung | mittel | 1 |
| M102 | Zwei-Faktor-Authentifizierung | **tief** | 2 |
| M103 | Access Tokens | **tief** | 2 |
| M104 | Passwort-Manager (aktuell) | **tief** | 1 |
| M105 | Passwort-Manager (Legacy, obsolet) | mittel | 1 |
| M106 | DSGVO/Datenschutz | **tief** | 2 |
| M107 | Änderungsverfolgung (Audit-Trail) | mittel | 1 |
| M108 | PDF-Signatur | mittel | 1 |
| M109 | Mandantenverwaltung | **tief** | 2 |
| M110 | Firmenstammdaten | flach | 1 |
| M111 | Länderverwaltung | flach | 1 |
| M112 | Mitarbeiterverwaltung | flach | 1 |
| M113 | Organisationsstruktur (Filialen/Stammdaten) | mittel | 1 |
| M114 | Belegkonditionen/Zahlungsbedingungen | flach | 1 |
| M115 | Systemeinstellungen | flach | 1 |
| M116 | Webservice-Konfiguration | flach | 1 |
| M117 | Verbindungsverwaltung | flach | 1 |
| M118 | SQL-Manager | flach | 1 |
| M119 | c-entron Config-DB | **tief** | 2 |
| M120 | Lizenzverwaltung | mittel | 1 |
| M121 | Hintergrunddienste | mittel | 1 |
| M122 | Netzwerkdiagnose | mittel | 1 |
| M123 | Profiling/Performance-Tests | flach | 1 |
| M124 | c-entron Inspektor/Logs | mittel | 1 |
| M125 | Telemetrie | flach | 1 |
| M126 | Dokumentenindexsuche | mittel | 1 |
| M127 | Kundenspezifische Anpassungen | mittel | 1 |
| M128 | Themes/Design | flach | 1 |
| M129 | Textbaustein-Verwaltung | mittel | 1 |
| M130 | Eigene Felder (Custom Properties) | mittel | 1 |
| M131 | Externe Werkzeuge | mittel | 1 |
| M132 | Reportverwaltung/-vorlagen | flach | 1 |
| M133 | Excel-Export | flach | 1 |
| M134 | Data Updater / Massenänderungen | mittel | 1 |
| M135 | Skriptmethoden | mittel | 1 |
| M136 | Prozessvorlagen | flach | 1 |
| M137 | Umsatz-/Verkaufsstatistik | flach | 1 |
| M138 | Leistungsnachweise | flach | 1 |
| M139 | Management-Info | mittel | 1 |
| M140 | Mitarbeiterauslastung | flach | 1 |
| M141 | MSP-Collector | flach | 1 |
| M142 | MSP-Vergleich/Dashboard | flach | 1 |
| M143 | Dashboard | flach | 1 |
| M144 | Mein Tag | mittel | 1 |
| M145 | To-do-Liste | mittel | 1 |
| M146 | KI-Chat/Assistent | mittel | 1 |
| M147 | Gutscheinverwaltung | flach | 1 |
| M148 | Videoportal | flach | 1 |
| M149 | TradePool | mittel | 1 |
| M150 | SelfCare (Backend) | flach | 1 |
| M151 | WebLinks/URL-Verwaltung | flach | 1 |
| M152 | Tags/Verschlagwortung | mittel | 1 |
| M153 | Objekt-Fremdreferenzen | mittel | 1 |
| M154 | Reisekosten (deaktiviert) | mittel | 1 |
| M155 | IT-Planer | flach | 1 |
| M156 | Zeiterfassung | flach | 1 |
| M157 | Produktdaten-Feeds (COP/ITscope/Icecat) | mittel | 1 |
| M158 | docuFORM-API | mittel | 1 |
| M159 | CentronNexus-Kundenportal | flach | 1 |
| M160 | Web-Angebot (WebOffer) | flach | 1 |
| M161 | Web-Warenkorb (WebCart) | mittel | 1 |
| M162 | Service-Board | flach | 1 |
| M163 | Dokumentensignatur (Nexus) | flach | 1 |
| M164 | Office-Integration (Nexus) | flach | 1 |
| M165 | Outlook-Add-in | flach | 1 |
| M166 | Mobile Anwendung (Backend) | flach | 1 |
| M167 | Legacy-REST-Webservice | flach | 1 |
| M168 | Moderne REST-Controller (v1) | **tief** | 1 |
| M169 | Verbindungsmanager (Client-Tool) | flach | 1 |
| M170 | Web-Version-Steuerung | mittel | 1 |
| M171 | Domänenentitäten | flach | 1 |
| M172 | Datenzugriffsschicht (DAO/Mappings) | flach | 1 |
| M173 | Gemeinsame Basisbibliothek | flach | 1 |
| M174 | WPF-Client-Framework | mittel | 1 |
| M175 | Gemeinsame UI-Steuerelemente | flach | 1 |
| M176 | Installer/Deployment | flach | 1 |
| M177 | Docker-Betriebsumgebung | flach | 1 |
| M178 | CI/CD-Pipelines | flach | 1 |
**Summe:** 8 Module `tief` (14 Anforderungen), 65 Module `mittel` (65 Anforderungen), 105
Module `flach` (105 Anforderungen), 0 Module `nicht analysiert`. 8+65+105 = 178 Module;
14+65+105 = 184 SwRS-Anforderungen — deckungsgleich mit der Gesamtzahl aller SwRS-Anforderungen
in `SwRS.md`.
---
## 3. Konsistenzcheck
**Doppelte oder mehrfach vergebene IDs:** Keine gefunden. Jede ID (`StRS-001…025`,
`SyRS-001…028`, `SwRS-001…184`) wurde in dieser Reihenfolge genau einmal vergeben; die
Nummerierung von SwRS folgt bewusst 1:1 der Modulnummerierung aus Abschnitt 1 für die
Mindestabdeckung (SwRS-001…178) und wird für die Risikovertiefung linear fortgesetzt
(SwRS-179…184).
**Anforderungen ohne Beleg:** Keine gefunden. Jede der 237 Anforderungen führt mindestens
einen Beleg im Feld `Belege`; 78 der 184 SwRS-Anforderungen (42,4 %) führen mindestens einen
`PRIMÄR`-Beleg, die übrigen 106 mindestens einen `SEKUNDÄR`- oder `KONTEXT`-Beleg.
**Anforderungen ohne Angabe zur `Übernahmewürdigkeit`:** Keine gefunden. Jede Anforderung in
StRS.md, SyRS.md und SwRS.md trägt eine Einstufung (`übernehmen`, `Workaround`, `Sonderfall`
oder `veraltet`) mit Begründung.
**Tracelinks auf nicht existierende IDs:** Keine gefunden. Jede in einer SwRS-Anforderung
genannte SyRS-ID (SyRS-001…028) und jede in einer SyRS-Anforderung genannte StRS-ID
(StRS-001…025) wurde geprüft und existiert im jeweiligen Dokument (siehe `Traceability.md`
für die vollständige Auflösung).
**Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk:** Bei der
Durchsicht wurden keine weiteren, bislang nicht markierten Deckungsgleichheiten gefunden.
Insgesamt 11 Anforderungen tragen bereits einen expliziten `Konsolidierung: Kandidat`-Vermerk
(SwRS-005-analog in StRS-005, StRS-021, StRS-023, SwRS-010, SwRS-014, SwRS-026, SwRS-039,
SwRS-041, SwRS-043, SwRS-045, SwRS-056, SwRS-060, SwRS-061, SwRS-078/079, SwRS-105, SwRS-113,
SwRS-127/130, SwRS-129, SwRS-141, SwRS-149, SwRS-155, SwRS-158, SwRS-167). Ein Konsolidierungs-
kandidat, der in Iteration 1 als Beispiel vorgegeben war (Stammblätter/Drucker vs. Assets),
wurde bestätigt und in SwRS-010 sowie SwRS-056 dokumentiert.
**Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung,
Berechtigungen) mit Belegsituation:**
| ID | Titel | `PRIMÄR`-Beleg vorhanden? | `[HYPOTHESE]`? |
|---|---|---|---|
| SwRS-100 | Gruppenbasiertes Rechtesystem mit administratorgeschützten Gruppen | Ja | Nein |
| SwRS-101 | Austauschbare Authentifizierungsverfahren über Factory-Muster | Ja | Nein |
| SwRS-102 | Pluggable Zwei-Faktor-Verfahren mit erzwingbarer Pflicht | Ja | Nein |
| SwRS-103 | Gehashte, protokollierte API-Zugriffstoken mit Ablaufsteuerung | Ja | Nein |
| SwRS-104 | Passwort-Manager mit richtlinienbasierter Kategorisierung und Log (AES-Verschlüsselung) | Ja | Nein |
| SwRS-105 | Legacy-Passwortverwaltung (obsolet) | Nein (KONTEXT) | Nein |
| SwRS-106 | DSGVO-Löschfunktion für Ansprechpartnerdaten | Ja | Nein |
| SwRS-107 | Attributgesteuerte Änderungsverfolgung | Ja | Nein |
| SwRS-108 | Bedingte Verfügbarkeit der PDF-Signatur | Ja | Nein |
| SwRS-109 | Mandantenfähige Nummernkreise mit Fallback-Hierarchie | Ja | Nein |
| SwRS-118 | SQL-Manager mit schreibgeschützten Diagnoseabfragen | Nein (SEKUNDÄR) | **Ja** |
| SwRS-119 | Master-Schlüssel-Abstraktion (CentronConfigDb) | Ja | Nein |
| SwRS-120 | Signaturgeprüfte Lizenzdateien | Ja | Nein |
| SwRS-168 | Moderne v1-REST-Controller mit uneinheitlicher Rechteprüfung | Ja (3×) | **Ja** |
| SwRS-179 | Fehlende Rechteprüfung beim Setzen des Hotline-Master-Schlüssels | Ja | **Ja** |
| SwRS-180 | Kryptographisch sichere Zufallszahlen für Access Tokens | Ja | Nein |
| SwRS-181 | Eigenimplementiertes RADIUS-Protokoll | Ja | **Ja** |
| SwRS-182 | DSGVO-Bereinigung mit frei wählbarem Stichtag | Ja | **Ja** |
| SwRS-183 | Hartkodierte Admin-Rechte-Whitelist | Ja | Nein |
| SwRS-184 | Nummernkreis-Grenzen ohne verifizierten Nebenläufigkeitsschutz | Nein (SEKUNDÄR) | **Ja** |
| SwRS-015…019 | Rechnung/Gutschrift/Anzahlung/Mahnwesen/OPOS (Fakturierung) | Ja (015,016,017,018) / Ja (019) | Nein |
| SwRS-053, 055-057 | Kontingent-/Klickabrechnung (Fakturierung) | Ja | Nein |
| SwRS-067 | Zeitlich gültigkeitsbeschränkte MwSt.-Sätze | Ja | Nein |
**Ergebnis:** Sechs risikorelevante Anforderungen (SwRS-118, SwRS-168, SwRS-179, SwRS-181,
SwRS-182, SwRS-184) sind als `[HYPOTHESE]` markiert, weil kein `PRIMÄR`-Beleg vorlag bzw. weil
die Tiefenverifikation über die statische Breitenanalyse hinausgegangen wäre; dies entspricht
der Vorgabe, risikorelevante Aussagen ohne `PRIMÄR`-Beleg zwingend als Hypothese zu kennzeichnen.
Alle übrigen risikorelevanten Anforderungen sind mit `PRIMÄR`-Beleg geführt. **Kein
risikorelevanter Sachverhalt wurde ohne jede Kennzeichnung als sicher belegt dargestellt.**
**Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** `Hypothesen.md` listet genau die
12 Anforderungen, die in StRS.md/SyRS.md/SwRS.md mit `Status: HYPOTHESE` markiert sind
(SyRS-020, SyRS-024, SyRS-026, SyRS-028, SwRS-099, SwRS-118, SwRS-157, SwRS-168, SwRS-179,
SwRS-181, SwRS-182, SwRS-184) und keine zusätzlichen, anforderungslosen Fragen. Die Zahlen
stimmen überein (12 = 12); der Abgleich wurde mittels eines automatisierten Musterabgleichs
über alle drei Dokumente durchgeführt (siehe Vorgehenshinweis in `Hypothesen.md`).
---
## 4. Selbstbewertung
**Tiefe der Analyse je Modul (absolute Zahlen):** Von 178 Modulen wurden 8 `tief`, 65
`mittel` und 105 `flach` analysiert; 0 Module blieben ohne Anforderung (`nicht analysiert`).
Die 8 tief analysierten Module liegen ausnahmslos in den vorgegebenen Risikobereichen
Sicherheit/Rechte (M100, M102, M103, M104, M106, M109, M119) und Web-API-Berechtigung
(M168).
**Mindestabdeckung erreicht?** Ja. Jedes der 178 Module aus dem Inventar trägt mindestens
eine Anforderung (SwRS-001…178, 1:1 zur Modulnummerierung); kein Modul musste als „nicht
analysiert" mit Begründung geführt werden, da für jedes Modul mindestens ein realer
Artefaktbeleg (Klasse, Methode oder Konfigurationsstelle) auffindbar war.
**Wo war der Beleg dünn?** 105 der 178 Module (59 %) sind mit „flach" eingestuft, das heißt
mit genau einer Anforderung und ausschließlich `SEKUNDÄR`-/`KONTEXT`-Beleg (z. B.
Ordnerstruktur, Modulregistrierungs-Eintrag ohne tiefere Methodenanalyse). Das betrifft
erwartungsgemäß vor allem Bereiche mit vielen kleinen, strukturell ähnlichen
Einzelmodulen (Bereich R „Sonstige Fachmodule", Bereich D „EDI-Partneranbindungen" jenseits
von EGIS, Bereich T „Web-Portal" jenseits der Kernfunktionen). Dort wurde bewusst die
Modulexistenz und ihre grobe Funktion belegt, nicht aber jede interne Regel nachvollzogen -
dies entspricht der Vorgabe „Breite vor Tiefe" für die Mindestabdeckung. Der Anteil der
`PRIMÄR`-Belege liegt bei 42,4 % der SwRS-Anforderungen (78 von 184) und damit niedriger als
der in Iteration 1 gemessene Vergleichswert von 78,6 % `PRIMÄR`-Anteil unter *allen* Belegen
eines Laufs; die Kennzahlen sind nicht direkt vergleichbar (dort: Anteil an allen
Beleg-Einzeleinträgen; hier: Anteil der Anforderungen mit mindestens einem `PRIMÄR`-Beleg),
zeigen aber densel­ben Trend: Ein sehr breites Inventar erzwingt zwangsläufig einen höheren
Anteil an strukturell (statt methodengenau) belegten Anforderungen.
**Hypothesenquote:** 12 von 237 Anforderungen (5,1 %) sind als `[HYPOTHESE]` markiert. Dies
ist ungleich Null und liegt damit im von der Aufgabenstellung als plausibel bezeichneten
Bereich; die Konzentration auf Sicherheits- und Grenzbereiche der statischen Analyse ist in
`Hypothesen.md`, Abschnitt „Einordnung", begründet.
**Erkenntnisse, die einen Nachschlag in einer Folge-Iteration nahelegen:**
1. **Serverseitige Rechteprüfung der v1-REST-API (SwRS-168, höchste Priorität).** Die
Controller für Kunden, Angebote und Verträge tragen kein `[Authorize]`-Attribut, die für
Aufträge und Rechnungen/Lieferscheine zwar `[Authorize]`, aber keine feingranulare
Rechteprüfung - im Gegensatz zur lückenlosen Prüfung im WPF-Client. Eine Folge-Iteration
sollte gezielt jeden der 38 v1-Controller auf Autorisierungsattribute prüfen und die
tatsächliche Netzwerktopologie (vorgelagerter Reverse Proxy?) klären.
2. **Nummernkreis-Nebenläufigkeit (SwRS-184).** Die konkrete Inkrementierungslogik der
fortlaufenden Belegnummer wurde nicht bis zur Transaktionsebene zurückverfolgt; angesichts
der handelsrechtlichen Bedeutung lückenloser Rechnungsnummern ist dies vorrangig zu klären.
3. **Governance des Hotline-Master-Schlüssels (SwRS-119, SwRS-179).** Der Schlüssel, der
sämtliche Kunden-Passwort-Manager-Einträge entschlüsseln kann, wird beim Setzen ohne
sichtbare Rechteprüfung durch vier Code-Schichten gereicht; die aufrufende UI-Schicht war
nicht Teil dieser Analyse.
4. **Konsolidierungspotenzial** bei mindestens elf Stellen (siehe Abschnitt 3), insbesondere
Stammblatt/Asset (SwRS-010/056), Legacy-REST/v1-API (SwRS-167/168) und die fünfache
EDI-Partnerimplementierung (SwRS-039), sollte in der Zielarchitektur systematisch bewertet
werden.
5. **DSGVO-Aufbewahrungsfristen (SwRS-182)** sind aktuell rein administrativ, ohne
erkennbaren Systemschutz gegen ein zu früh gewähltes Bereinigungsdatum - fachlich und
rechtlich zu klären.
6. **Vollständigkeit der 178-Modul-Grenze selbst.** Diese Iteration hat das Inventar
gegenüber Iteration 1 (85 Module) mehr als verdoppelt, weil `Administration` und `Sales`
in ihre tatsächlichen Fachbereiche aufgelöst wurden. Eine Folge-Iteration sollte prüfen,
ob einzelne der hier als „flach" eingestuften Sammelmodule (z. B. M39 mit fünf
EDI-Partnern) für die Zielarchitektur noch weiter aufzuteilen sind.
**Vergleich zur Kalibrierung aus Iteration 1:** Die in der Änderungstabelle zu Beginn dieses
Prompts genannten Zielwerte wurden erreicht: Modulinventar vor der ersten Anforderung (Schritt
0), Mindestabdeckung für alle Module vor Vertiefung (Schritt 0b), Vertiefung nach Risiko mit
klar benannten Zusatzanforderungen (Schritt 0c), keine Anforderung ohne Beleg, keine
risikorelevante Anforderung ohne `PRIMÄR`-Beleg oder `[HYPOTHESE]`-Kennzeichnung, `Hypothesen.md`
deckungsgleich mit den Inline-Markierungen, und die Risikoliste ist im Lauf selbst (Abschnitt 3
dieses Dokuments) sichtbar, nicht erst in einer nachgelagerten Auswertung.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/Glossar.md
+41
View File
@@ -0,0 +1,41 @@
# Glossar — c-entron ERP-Suite
Domänenbegriffe, die in StRS.md, SyRS.md und SwRS.md verwendet werden, mit ihrer im Code
beobachteten Bedeutung. Rein technische Bezeichner (Klassen-/Methodennamen) werden nicht
gesondert aufgeführt, sofern sie im Fließtext bereits erläutert sind.
| Begriff | Bedeutung |
|---|---|
| **Beleg** | Sammelbegriff für alle Dokumente der Verkaufs- und Einkaufsabwicklung (Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Anzahlung, Bestellung). Alle Belegarten teilen die gemeinsame Basisklasse `ReceiptBL`. |
| **Belegkette** | Die fachliche Abfolge, in der ein Beleg in einen anderen weitergeleitet wird (z. B. Angebot → Auftrag → Lieferschein → Rechnung), ohne Positionsdaten erneut zu erfassen. |
| **Mahnstufe** | Eskalationsstufe einer überfälligen Rechnung im Mahnwesen; das System unterscheidet die Stufen `None`, `Level1`, `Level2`, `Level3` (`DunningLevel`). |
| **Mahnsperre** | Zeitlich befristete, je Kunde oder Objekt setzbare Sperre, die eine Rechnung von der automatischen Mahnstufen-Erhöhung ausnimmt (`UpdateDunningStopAndInfo`). |
| **OPOS** | Offene Posten - Sammelbegriff für noch nicht vollständig ausgeglichene Rechnungen; eigenes Auswertungsmodul mit eigener Rechteprüfung. |
| **Anzahlung / Down Payment** | Teilrechnung vor Erbringung der vollständigen Leistung, die bei der Schlussrechnung desselben Auftrags automatisch verrechnet wird. |
| **Kontingent** | Vertraglich vereinbartes Leistungsvolumen (z. B. Klicks, Zeiteinheiten) je Abrechnungsperiode; kann bei Nichtverbrauch in die Folgeperiode übernommen ("Restübernahme") oder bei Überschreitung über einen Mehrverbrauchsartikel abgerechnet werden ("Überbuchung"). |
| **Nummernkreis** | Konfigurierbarer Zähler zur Vergabe fortlaufender Belegnummern, geführt je Mandant, optional zusätzlich je Filiale oder Mitarbeiter, mit Bereichsgrenzen (`BereichVon`/`BereichBis`) und aktuellem Stand (`Aktuell`). |
| **Stammblatt** | Kundenbezogene Dokumentation eines Hardware-Assets (historisch vor allem Drucker) inkl. Zählerständen und Wartungshistorie; laut Konsolidierungsvorgabe fachlich mit dem allgemeinen Asset-Konzept (siehe unten) zusammenzuführen. |
| **Asset (Kundenasset)** | Beim Kunden geführtes Gerät/Objekt mit Versionierung und Sperrmechanismus (`AssetBL`, `AssetLockBL`); umfasst u. a. Verträge und Klickzähler. |
| **Klickabrechnung** | Nutzungsbasiertes Abrechnungsmodell, bei dem der Zählerstand eines Geräts (z. B. Drucker) die abzurechnende Menge bestimmt. |
| **Provisionsschema** | Konfigurierbares Regelwerk, nach dem einem Mitarbeiter für einen Beleg eine Provision berechnet wird; kombiniert mit Mitarbeiterstufe und -ziel. |
| **Rechtegruppe (AppGroup)** | Zusammenfassung von Benutzerrechten, die einem oder mehreren Benutzern zugewiesen wird; Datenbanktabellen `Sichgrup` (Gruppen), `Sichtrus` (Gruppe-Recht-Zuordnung), `Sichmemb` (Benutzer-Gruppe-Zuordnung). |
| **Administratorgruppe** | Besonders geschützte Rechtegruppe (I3D = 6, Name "Administratoren"), die im Code nicht löschbar ist und deren Rechte nur innerhalb einer festgelegten Whitelist änderbar sind. |
| **WebAccount** | Zugangskonto für Endkunden im CentronNexus-Portal, getrennt vom internen Mitarbeiterkonto (`AppUser`); besitzt ein eigenes Rechtesystem (`WebAccountsRights`). |
| **Access Token** | Persönliches, gehashtes API-Zugriffstoken mit Ablaufdatum und vollständiger Zugriffsprotokollierung, unabhängig vom regulären Benutzerpasswort. |
| **Hotline-Master-Schlüssel** | Installationsweiter kryptographischer Schlüssel, mit dem c-entron-Hotline-Mitarbeiter befugt AES-verschlüsselte Passwort-Manager-Einträge von Kunden entschlüsseln/exportieren können. |
| **ILogic / BLLogic / WSLogic** | Client-seitiges Architekturmuster: `ILogic`-Interface definiert eine Fachoperation, `BLLogic` implementiert sie per Datenbankdirektzugriff, `WSLogic` per Webservice-Aufruf; beide Implementierungen sind für jedes Modul vorgesehen. |
| **Result\<T\>** | Einheitlicher Rückgabetyp der Business-Logik-Schicht für Erfolg/Fehler, verwendet anstelle von Exceptions im regulären Kontrollfluss. |
| **ModuleRegistration** | Zentrale Registrierungsstelle im WPF-Client, die für jedes im Menü sichtbare Fachmodul eine Rechte- und eine Lizenzprüfung kombiniert, bevor das Modul freigeschaltet wird. |
| **EDI** | Electronic Data Interchange - elektronischer, strukturierter Belegaustausch mit Distributoren (z. B. Alltron, Also, Herweck, Komsa, EGIS) in jeweils partnerspezifischen Formaten. |
| **OpenTRANS** | Herstellerunabhängiger XML-Standard für den elektronischen Bestell-/Rechnungsaustausch; im System in den Versionen 1.0 und 2.1 parallel unterstützt. |
| **ZUGFeRD** | Deutscher Standard für hybride (PDF + eingebettetes XML) elektronische Rechnungen; das System implementiert die Version 2.1 (Extended-Profil). |
| **eb-Interface** | Österreichisches Standardformat für elektronische Rechnungen an Behörden. |
| **DATEV** | Marktführendes deutsches Finanzbuchhaltungssystem für Steuerberater; das System bietet einen direkten Online-Belegtransfer dorthin an. |
| **MSP / RMM** | Managed Service Provider / Remote Monitoring and Management - Geschäftsmodell und zugehörige Fernwartungs-/Monitoring-Tools (z. B. Octopus, Wortmann), deren Nutzungsdaten für Abrechnung/Auswertung gesammelt werden. |
| **TradePool** | Externer Marktplatz für den Bezug von Distributoren-Artikeldaten per Dateiimport. |
| **CentronNexus** | Blazor-Server-basiertes Web-Portal für Endkunden (Angebote annehmen, bestellen, Tickets einsehen, Dokumente digital unterschreiben); potenzielle technische Blaupause für die geplante Web-/SaaS-Neuimplementierung. |
| **DSGVO-Bereinigung** | Funktion zur Löschung/Anonymisierung personenbezogener Daten (insbesondere Ansprechpartner) sowie zur allgemeinen, stichtagsbasierten Datenbereinigung. |
| **Change Tracking (Änderungsverfolgung)** | Generischer, attributgesteuerter Mechanismus auf NHibernate-Ebene, der Änderungen an markierten Entitäten/Feldern automatisch protokolliert, ohne modulspezifischen Zusatzcode. |
| **Sonderfall (Übernahmewürdigkeit)** | Einstufung einer Anforderung als Ausnahme für einen einzelnen Kunden, Mandanten oder Alt-/Spezialbestand (z. B. Schweiz-Spezifika, c-entron-interne Projektverwaltung). |
| **Workaround (Übernahmewürdigkeit)** | Einstufung einer Anforderung als historisch gewachsene Behelfslösung, die im Zielsystem durch eine sauberere Lösung ersetzt werden sollte (z. B. parallele EDI-Partnerimplementierungen, Legacy-Passwortverwaltung). |
| **Konsolidierungskandidat** | Zwei oder mehr Anforderungen, die laut Analyse denselben fachlichen Gegenstand in getrennten Implementierungen abbilden (z. B. Stammblatt vs. Asset, Legacy-REST vs. v1-API) und im Zielsystem zusammengeführt werden sollten. |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/Hypothesen.md
+45
View File
@@ -0,0 +1,45 @@
# Hypothesen — c-entron ERP-Suite
Diese Datei enthält ausschließlich die Anforderungen, die in StRS.md, SyRS.md oder SwRS.md mit
`Status: HYPOTHESE` markiert sind. Jede Zeile entspricht **genau einer** so markierten
Anforderung; es sind keine zusätzlichen, anforderungslosen Fragen aufgeführt (diese stehen
stattdessen in der Selbstbewertung in `Analysebericht.md`, Abschnitt 6). Die Liste wurde nach
Abschluss aller drei Spezifikationsdokumente aus den `Status: HYPOTHESE`-Markierungen
extrahiert und deckt sich damit vollständig mit den Inline-Markierungen (siehe
Konsistenzcheck in `Analysebericht.md`, Abschnitt 4).
**Gesamtzahl: 12 von 237 Anforderungen (5,1 %).**
| ID | Titel | Offene Frage zur Bestätigung |
|---|---|---|
| SyRS-020 | Konsistente Kennzahlenermittlung über Auswertungsmodule | Ob `Centron.BL/Statistics` dieselbe Datengrundlage (identische Belegtabellen/-filter) wie die Rechnungsstellung verwendet oder eine eigene, potenziell abweichende Aggregation vornimmt, wurde nicht durch einen Abgleich der SQL-/LINQ-Abfragen beider Module verifiziert. |
| SyRS-024 | Web-Portal mit eigenständiger Authentifizierung für Endkunden | Ob jede Datenabfrage im CentronNexus-Portal serverseitig zusätzlich nach der `CustomerI3D` des angemeldeten `WebAccount` filtert, wurde nicht für jeden Controller/jede Razor-Komponente einzeln verifiziert. |
| SyRS-026 | Einheitliches ILogic/BL/WS-Zugriffsmuster mit Result-Fehlerbehandlung | Ob die dokumentierte ILogic/BL/WS-Triade für alle 178 im Inventar erfassten Module lückenlos umgesetzt ist oder ob - wie `general-structure.md` selbst einräumt - Ausnahmen bestehen, wurde nicht für jedes Modul einzeln verifiziert. |
| SyRS-028 | Serverseitige Durchsetzung sicherheitskritischer Operationen unabhängig von der aufrufenden Oberfläche | Ob außerhalb des WPF-Clients (REST-API, Master-Schlüssel-Verwaltung) eine der WPF-Rechteprüfung gleichwertige serverseitige Durchsetzung existiert, ist Gegenstand der in SwRS-168/179/184 dokumentierten Einzelbefunde und müsste durch gezielte Penetrationstests der betroffenen Endpunkte bestätigt oder widerlegt werden. |
| SwRS-099 | Echtzeit-Push-Benachrichtigungen für das Web-Portal | Ob `NotificationsHubHelper.SendNexusNotification` tatsächlich über einen SignalR-Hub oder einen anderen Push-Mechanismus an die Portal-Clients ausgeliefert wird, wurde nicht am konkreten Hub-Implementierungscode verifiziert. |
| SwRS-118 | SQL-Manager mit schreibgeschützten Diagnoseabfragen | Ob das im Client sichtbare "SQL-Manager"-Modul über die gesichteten, rein lesenden `SQLManagementBL`-Methoden hinaus an anderer Stelle eine freie, schreibende SQL-Eingabe erlaubt, wurde anhand dieser Klasse allein nicht abschließend geklärt. |
| SwRS-157 | Kontingentierter Zugriff auf Produktdaten-Feeds | Ob ein von `ITscopeApiKeyQuotaParser` erkanntes, nahezu erschöpftes API-Kontingent den weiteren Abgleich tatsächlich unterbindet oder nur informativ angezeigt wird, wurde am aufrufenden Code nicht verifiziert. |
| SwRS-168 | Moderne v1-REST-Controller mit uneinheitlicher Rechteprüfung | Ob `CustomerBL.GetActiveCustomerCompact(user)` intern doch eine Rechteprüfung durchführt oder ein vorgelagerter API-Gateway-/Reverse-Proxy-Mechanismus außerhalb von `src/webservice` Authentifizierung/Rechte erzwingt, wurde nicht abschließend verifiziert. Dies ist der schwerwiegendste Einzelbefund dieser Iteration (siehe Konsistenzcheck, Analysebericht.md, Abschnitt 4). |
| SwRS-179 | Fehlende sichtbare Rechteprüfung beim Setzen des Hotline-Master-Schlüssels | Ob die aufrufende WPF-Oberfläche vor dem Aufruf von `SetHotlineMasterKey` eine clientseitige Rechteprüfung vorschaltet, wurde nicht verifiziert; unabhängig davon fehlt eine serverseitige Prüfung. |
| SwRS-181 | Eigenimplementiertes RADIUS-Protokoll als Angriffsfläche der Zwei-Faktor-Anbindung | Ob die eigenimplementierten Klassen `RadiusClient`/`RadiusPacketParser` alle sicherheitsrelevanten Aspekte von RFC 2865 (insbesondere die Response-Authentifikator-Prüfung) korrekt umsetzen, wurde nicht durch einen Protokollabgleich oder Sicherheitsaudit verifiziert. |
| SwRS-182 | DSGVO-Datenbereinigung mit administrativ frei wählbarem Stichtag | Ob die aufrufende WPF-Maske eine Warnung oder Untergrenze für das Stichdatum bei gesetzlich aufbewahrungspflichtigen Belegen (z. B. Rechnungen) implementiert, wurde nicht verifiziert. |
| SwRS-184 | Nummernkreis-Bereichsgrenzen ohne verifizierten Schutz vor Lückenbildung | Ob die Inkrementierung der laufenden Belegnummer (`NumberGroup.Aktuell`) unter einer Datenbanksperre erfolgt, die eine doppelte Vergabe bei zeitgleichem Zugriff zweier Benutzer ausschließt, wurde nicht bis zur konkreten Speicherlogik zurückverfolgt. |
## Einordnung
Die Konzentration der Hypothesen ist bewusst nicht gleichmäßig über die 178 Module verteilt,
sondern entsteht an zwei nachvollziehbaren Stellen:
1. **Grenzen der Breitenanalyse** (SyRS-020, SyRS-026, SwRS-099, SwRS-118, SwRS-157): An
diesen Stellen wurde eine Klasse/Methode gelesen, ihr Aufrufer oder ihre Tiefe jedoch nicht
vollständig zurückverfolgt, weil dies angesichts von 178 zu behandelnden Modulen mit
Mindestabdeckung nicht für jede einzelne Methode leistbar war.
2. **Gezielte Sicherheitsvertiefung** (SyRS-024, SyRS-028, SwRS-168, SwRS-179, SwRS-181,
SwRS-182, SwRS-184): Diese Hypothesen sind das Ergebnis der in Schritt 0c geforderten
Risikovertiefung und benennen konkrete, im Code beobachtete Auffälligkeiten, deren
abschließende Bewertung (Fehlverhalten vs. bewusste, an anderer Stelle abgesicherte
Entscheidung) einen gezielten Penetrationstest bzw. eine Tiefenprüfung der genannten
Einzelstelle erfordert, die über eine statische Breitenanalyse hinausgeht.
Kein einziges Kernmodul der Verkaufsbelegkette (M11-M30) trägt eine Hypothese - dort war für
jede Anforderung ein `PRIMÄR`- oder `SEKUNDÄR`-Beleg mit konkretem Methodenbezug auffindbar.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/StRS.md
+853
View File
@@ -0,0 +1,853 @@
# Stakeholder Requirements Specification (StRS) — c-entron ERP-Suite
Fachliche Sicht: Geschäftsziele, Akteure und Nutzenerwartungen je Fachbereich. Jede StRS-Anforderung
bündelt mehrere SyRS-/SwRS-Anforderungen desselben Bereichs (siehe `Analysebericht.md`, Abschnitt 1,
für die Bereichsabgrenzung, und `Traceability.md` für die vollständige Verknüpfung).
---
```
ID: StRS-001
Titel: Zentrale Kunden- und Kontaktverwaltung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertriebsmitarbeiter, Innendienst, Marketing
Vorbedingung: Ein Kunde, Interessent oder Lieferant soll im System erfasst oder gepflegt werden.
Fakt: Die Codebasis enthält unter `Sales/Customers` sechs getrennte, aber zusammenhängende
Teilbereiche: Adressen, Ansprechpartner, CRM-Kontakthistorie, CRM-Projekte,
Kundendetails und kundenspezifische Textbausteine, jeweils als eigene BL-Klassen
(`AddressBL`, `ContactSalutationBL`, `CustomerActivityBL`, `CrmProjectBL`,
`CustomerAncestryBL`, `BusinessTextBlockBL`).
Aussage: Das System soll es Vertriebs- und Innendienstmitarbeitern ermöglichen, Kunden,
Interessenten und Lieferanten mit ihren Adressen, Ansprechpartnern, ihrer
Kontakthistorie und zugehörigen CRM-Projekten zentral und konsistent zu verwalten.
Ergebnis: Ein Mitarbeiter findet zu jedem Geschäftspartner eine vollständige, aktuelle
Kundenakte inklusive Historie an einer Stelle.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Customers/* (6 Unterordner) - Begründung: Die
Gliederung der Business-Logik in fachlich benannte Unterordner belegt, dass Kundendaten als
ein zusammenhängender, mehrteiliger Geschäftsvorfall behandelt werden.
- [KONTEXT] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Region "Adressen/CRM" -
Begründung: Die Gruppierung von Adressstamm, CRM, Audit, CRM-Projekten, Kampagnen und
Stammblättern unter einem Menüpunkt zeigt, dass diese Funktionen aus Anwendersicht als ein
Geschäftsbereich wahrgenommen werden.
Prüfidee: Ein neu angelegter Kunde ist unmittelbar nach dem Speichern mit seiner
Erstadresse, ggf. Ansprechpartnern und einer leeren Aktivitätshistorie über die
Kundenakte auffindbar.
Tracelinks: SyRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernfunktion jedes CRM-fähigen ERP-Systems, fachlich auch im
SaaS-Zielsystem zwingend erforderlich.
Status: belegt
```
---
```
ID: StRS-002
Titel: Durchgängige Verkaufsbelegkette Angebot bis Rechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Auftragsabwicklung, Buchhaltung, Kunde
Vorbedingung: Ein Verkaufsvorgang von der Anfrage bis zur Bezahlung soll dokumentiert werden.
Fakt: `src/backend/Centron.BL/Sales/Receipts` enthält für jede Belegart (Angebot, Auftrag,
Lieferschein, Abholschein, Rechnung, Gutschrift, Anzahlung) einen eigenen unter-
geordneten Bereich sowie separate Mahnungs- (`Invoices/Dunning`) und OPOS-Bereiche
(`Invoices/Opos`); alle Belegarten teilen sich die gemeinsame Basisklasse `ReceiptBL`.
Aussage: Das System soll den gesamten Verkaufsprozess vom Angebot über Auftrag, Lieferschein
und Rechnung bis zur Gutschrift als zusammenhängende, weiterleitbare Belegkette
abbilden und bei überfälligen Rechnungen automatisiert mahnen.
Ergebnis: Aus einem Angebot lässt sich ohne erneute Dateneingabe ein Auftrag, daraus ein
Lieferschein und eine Rechnung erzeugen; unbezahlte Rechnungen werden im
Mahnwesen sichtbar.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/{Offers,Orders,DeliveryLists,PickUps,
Invoices,CreditVouchers,DownPayment} - Begründung: Eigenständige Ordner je Belegart belegen,
dass jede Stufe der Belegkette fachlich getrennt, aber im selben Modul geführt wird.
- [KONTEXT] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs - Begründung: Eine gemeinsame
Basisklasse für alle Belegarten legt nahe, dass Weiterleitung/Umwandlung zwischen Belegarten
fachlich vorgesehen ist.
Prüfidee: Ein Angebot lässt sich zu einem Auftrag weiterleiten, ohne Positionen erneut zu
erfassen; die Rechnung übernimmt Kunden- und Positionsdaten aus dem Auftrag.
Tracelinks: SyRS-002
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess jedes Handels-/Dienstleistungs-ERP.
Status: belegt
```
---
```
ID: StRS-003
Titel: Nachvollziehbare Belegsteuerung und Preisfindung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Vertriebsleitung, Innendienst
Vorbedingung: Ein Beleg wird angelegt, geändert, freigegeben oder in eine neue Version überführt.
Fakt: `Sales/Receipts/DataAndResults` enthält dedizierte Unterordner für
`CreateNewVersion`, `CreateReceipt`, `ForwardReceipt` und `SaveReceipt`;
`ReceiptLogBL.cs` protokolliert Belegänderungen; `ReceiptCartReleaseSystemBL.cs`
steuert einen Freigabeworkflow für Beleg-Warenkörbe.
Aussage: Das System soll Belegerstellung, -versionierung, -freigabe und Preisfindung als
nachvollziehbare, protokollierte Schritte abbilden, damit Änderungen an einem
Beleg auch nachträglich zugeordnet werden können.
Ergebnis: Zu jedem Beleg ist erkennbar, wer wann welche Version erzeugt oder freigegeben hat.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs - Begründung: Eine eigene
Log-Klasse für Belege belegt eine bewusste Protokollierungsfunktion.
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/DataAndResults/{CreateNewVersion,
ForwardReceipt} - Begründung: Eigene Unterordner für Versionierung und Weiterleitung zeigen,
dass dies als eigenständige fachliche Schritte behandelt werden, nicht als Nebeneffekt.
Prüfidee: Nach dem Ändern eines gespeicherten Belegs ist im Belegprotokoll ein Eintrag mit
Benutzer, Zeitstempel und geänderten Werten sichtbar.
Tracelinks: SyRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Nachvollziehbarkeit ist Grundvoraussetzung für ein
prüfungssicheres Fakturierungssystem.
Status: belegt
```
---
```
ID: StRS-004
Titel: Einkaufsabwicklung und Lieferantenanbindung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Einkauf, Wareneingang, Lieferant
Vorbedingung: Ware oder Leistung soll bei einem Lieferanten beschafft werden.
Fakt: Spiegelbildlich zu den Verkaufsbelegen existieren unter `Sales/Receipts`
`SupplierOrders`, `SupplierInvoices`, `SupplierCreditVouchers`,
`SupplierDeliveryLists` und `SupplierReceiptDocuments/ScanSupplierReceiptDocument`;
`Centron.BL/EDI` und `WPF EDIManagementController` bündeln die elektronische
Anbindung.
Aussage: Das System soll Bestellungen, Wareneingänge, Eingangsrechnungen und
Lieferantengutschriften erfassen und wahlweise elektronisch (EDI) mit Distributoren
austauschen.
Ergebnis: Ein Einkäufer kann eine Bestellung erfassen oder elektronisch auslösen und den
Wareneingang inklusive Rechnungsabgleich im System nachverfolgen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/Supplier* (5 Unterordner) - Begründung:
Eigenständige Ordner je Einkaufsbelegart belegen eine vollständige Einkaufs-Belegkette
analog zur Verkaufsseite.
- [KONTEXT] src/backend/Centron.BL/EDI - Begründung: Ein eigenes EDI-Modul zeigt, dass
elektronischer Belegaustausch mit Lieferanten fachlich vorgesehen ist.
Prüfidee: Eine erfasste Lieferantenbestellung lässt sich einem Wareneingang und einer
Eingangsrechnung zuordnen.
Tracelinks: SyRS-004
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Einkaufsprozess ist Kernbestandteil der Warenwirtschaft.
Status: belegt
```
---
```
ID: StRS-005
Titel: Elektronischer Belegaustausch mit Distributoren und Behörden
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Einkauf, Buchhaltung, Distributor, Finanzverwaltung
Vorbedingung: Bestell-, Liefer- oder Rechnungsdaten sollen automatisiert mit einem externen
Partner ausgetauscht werden.
Fakt: `src/backend/Centron.Gateway` enthält acht partnerspezifische Unterordner
(`EDI_Alltron`, `EDI_Also`, `EDI_AlsoCH`, `EDI_Herweck`, `EDI_Komsa`, `EDI_EGIS`,
`OpenTrans`, `OpenTrans1_0`) sowie `ZUGFeRD21_Extended` für elektronische
Rechnungen und `DataExchange` für den Export in Finanzbuchhaltungssysteme.
Aussage: Das System soll Bestell-, Liefer- und Rechnungsdaten in den vom jeweiligen Partner
geforderten elektronischen Formaten (herstellerspezifisches EDI, OpenTRANS,
ZUGFeRD) austauschen können.
Ergebnis: Eine Bestellung wird ohne manuelle Nacherfassung in das Zielformat des
Distributors übertragen bzw. eine Rechnung liegt zusätzlich als valides
ZUGFeRD-Dokument vor.
Belege:
- [SEKUNDÄR] src/backend/Centron.Gateway/{EDI_Alltron,EDI_Also,EDI_AlsoCH,EDI_Herweck,
EDI_Komsa,EDI_EGIS,OpenTrans,OpenTrans1_0,ZUGFeRD21_Extended} - Begründung: Je Partner/Format
ein eigener Ordner mit eigenständigen Klassen belegt individuelle, produktiv genutzte
Format-Implementierungen.
- [KONTEXT] docs/reference/zugferd-field-mapping.md - Begründung: Eine dedizierte
Feldzuordnungsdokumentation belegt, dass ZUGFeRD-Konformität ein bewusstes Entwicklungsziel ist.
Prüfidee: Eine an einen angebundenen Distributor übertragene Bestellung entspricht dessen
dokumentiertem Nachrichtenformat.
Tracelinks: SyRS-005
Konsolidierung: Kandidat: Die fünf strukturell ähnlichen EDI_*-Module (Alltron, Also DE/CH,
Herweck, Komsa) bilden dieselbe fachliche Funktion "Bestellaustausch mit
Distributor" je Partner ab und sind Kandidaten für eine gemeinsame,
partnerparametrisierte EDI-Abstraktion im Zielsystem.
Übernahmewürdigkeit: übernehmen - Marktüblicher Standardprozess im IT-Fachhandel; die
partnerspezifische Vervielfachung ist ein Workaround-Kandidat für Konsolidierung.
Status: belegt
```
---
```
ID: StRS-006
Titel: Zahlungsverkehr und Bankabgleich
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung, Kunde
Vorbedingung: Zahlungen sollen erfasst, abgeglichen oder ausgelöst werden.
Fakt: `Centron.BL/Finances/OnlineBanking` mit `OnlineBankingFinApiBL.cs` bindet den
Multibanking-Dienst FinAPI (`src/apis/Centron.APIs.FinAPI`) an; `Payments` und
`IncomingPayments` verarbeiten Zahlungseingänge; `PaymentTransactionAppModuleController`
steuert SEPA-Zahlungen.
Aussage: Das System soll Kontoumsätze automatisiert über eine Bankschnittstelle abgleichen,
Zahlungseingänge offenen Rechnungen zuordnen und SEPA-Zahlungsläufe erzeugen.
Ergebnis: Ein über FinAPI abgerufener Kontoumsatz wird automatisch oder manuell einer
offenen Rechnung zugeordnet und deren Status aktualisiert.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs -
Begründung: Eine dedizierte Klasse für den FinAPI-Kontoabgleich belegt eine produktiv
genutzte Bankanbindung.
- [KONTEXT] src/apis/Centron.APIs.FinAPI/RestClient - Begründung: Ein eigenständiges API-Client-
Projekt für FinAPI belegt eine dauerhafte externe Integration, nicht nur einen Prototyp.
Prüfidee: Ein über FinAPI abgerufener Kontoumsatz mit passendem Verwendungszweck wird einer
offenen Rechnung automatisch vorgeschlagen.
Tracelinks: SyRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Automatisierter Zahlungsabgleich ist wesentlicher
Effizienzgewinn in der Buchhaltung.
Status: belegt
```
---
```
ID: StRS-007
Titel: Wiederkehrende und ereignisbasierte Vertragsabrechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung, Vertriebsleitung, Kunde
Vorbedingung: Ein laufender Vertrag (Pauschale, Klickabrechnung, Ticketzeit) soll periodisch
abgerechnet werden.
Fakt: `Centron.BL/Finances` enthält getrennte BL-Bereiche `FlatrateBilling`,
`AutomatedBilling` und `TimerBilling`; `DeviceClickCounterAppModuleController`
erfasst Zählerstände für nutzungsbasierte Abrechnung; die Module sind im WPF-Client
unter der Region "Abrechnung" zusammengefasst.
Aussage: Das System soll Pauschal-, Klick- und Ticketzeit-basierte Verträge automatisiert
und periodisch zu Rechnungen verarbeiten, ohne dass jede Position manuell erfasst
werden muss.
Ergebnis: Ein Abrechnungslauf erzeugt für alle fälligen Verträge automatisch Rechnungen mit
korrekt berechneten Mengen und Preisen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Finances/{FlatrateBilling,AutomatedBilling,TimerBilling} -
Begründung: Getrennte, produktiv gepflegte BL-Bereiche je Abrechnungsart belegen etablierte,
unterschiedliche Abrechnungsmodelle.
- [KONTEXT] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs Zeilen 418-450 (Region
"Abrechnung") - Begründung: Die eigene Menü-Region mit Rechte- und Lizenzprüfung je
Abrechnungsart zeigt, dass jede Abrechnungsart separat lizenziert und freigeschaltet wird.
Prüfidee: Ein automatischer Abrechnungslauf für einen Vertrag mit monatlicher Pauschale
erzeugt genau eine Rechnung mit dem im Vertrag hinterlegten Betrag.
Tracelinks: SyRS-007
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Wiederkehrende Abrechnung ist zentrales Geschäftsmodell für
MSP-/IT-Dienstleister-Kunden von c-entron.
Status: belegt
```
---
```
ID: StRS-008
Titel: Provisions- und Finanzstammdaten-Verwaltung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertriebsleitung, Buchhaltung, Controlling
Vorbedingung: Provisionen sollen berechnet oder Finanzstammdaten (Kontenrahmen, MwSt.,
Kostenstellen) gepflegt werden.
Fakt: Es existieren getrennte WPF-Module für Provisionsauswertung, Provisionsschema-
Verwaltung und Kundenzuordnung sowie eigenständige BL-Klassen
`Warehousing/CostCenterBL.cs` und `Warehousing/TaxBL.cs`.
Aussage: Das System soll Provisionen anhand konfigurierbarer Schemata berechnen und
Finanzstammdaten wie Kontenrahmen, Mehrwertsteuersätze und Kostenstellen zentral
vorhalten.
Ergebnis: Ein Vertriebsmitarbeiter sieht seine anhand des zugeordneten Schemas berechnete
Provision; Buchhaltung und Rechnungsstellung verwenden einheitliche
Steuersatz- und Kostenstellenstammdaten.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Warehousing/{CostCenterBL.cs,TaxBL.cs} - Begründung:
Eigenständige, von der Artikelverwaltung getrennte Klassen belegen dedizierte
Finanzstammdatenfunktionen.
- [KONTEXT] ModuleRegistration.cs, Provisions-Einträge (`ProvisionEvaluationAppModuleController`,
`ProvisionSchemaManagementAppModuleController`, `AssignmentsAppModuleController`) -
Begründung: Drei getrennte, sich gegenseitig ausschließende Menüeinträge (siehe deren
Rechteprüfungen) belegen ein mehrstufiges Provisionskonzept.
Prüfidee: Einem Kunden wird ein Provisionsschema zugeordnet; ein Beleg dieses Kunden erzeugt
eine Provisionsberechnung gemäß Schema.
Tracelinks: SyRS-008
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Provisionssteuerung ist vertriebsrelevant und wird laut
Modulstruktur aktiv genutzt.
Status: belegt
```
---
```
ID: StRS-009
Titel: Lager-, Artikel- und Versandverwaltung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Lager, Einkauf, Versand
Vorbedingung: Artikel sollen bevorratet, bepreist, kommissioniert und versendet werden.
Fakt: `Centron.BL/Warehousing` bündelt Artikelstamm, Staffel- und Aktionspreise sowie
Barcodeverwaltung; `Centron.BL/Logistics` und WPF `OrderCommissionAppModuleController`
bilden die Kommissionierung ab; `src/apis/Centron.Api.Gls` und
`Centron.Api.Shipcloud` binden externe Versanddienstleister an.
Aussage: Das System soll Artikelstammdaten inklusive Preisfindung, Bestände, Inventuren und
den Versandprozess bis zur Anbindung externer Versanddienstleister abbilden.
Ergebnis: Ein Auftrag wird kommissioniert, mit einem gültigen Versandlabel eines
angebundenen Dienstleisters versehen und der Bestand entsprechend fortgeschrieben.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Warehousing/{ArticleBL.cs,ArticleVolumePricesBL.cs,
ActionPriceBL.cs,BarcodeBL.cs} - Begründung: Mehrere spezialisierte Klassen belegen ein
ausdifferenziertes Artikelstamm- und Preiskonzept.
- [SEKUNDÄR] src/apis/Centron.Api.Gls, src/apis/Centron.Api.Shipcloud - Begründung: Zwei
eigenständige Versanddienstleister-API-Projekte belegen produktiv genutzte
Versandintegrationen.
Prüfidee: Für einen kommissionierten Auftrag lässt sich über die GLS- oder
Shipcloud-Anbindung ein Versandlabel erzeugen.
Tracelinks: SyRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Lager- und Versandprozesse sind Kernbestandteil der
Warenwirtschaft.
Status: belegt
```
---
```
ID: StRS-010
Titel: Fertigungsauftragsverwaltung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Produktion, Kunde (Portal)
Vorbedingung: Ein Fertigungsauftrag (z. B. Druck-/Fertigungsleistung) soll geplant und einer
Maschine zugeordnet werden.
Fakt: `Centron.BL/Production` und WPF `MaschineManagementAppModuleController` sowie
`ProductionOrderManagementAppModuleController` bilden Maschinen- und
Produktionsauftragsverwaltung; `CentronNexus/ProductionOrderManagement` spiegelt
dies im Kundenportal.
Aussage: Das System soll Produktionsmaschinen als Stammdaten verwalten und
Fertigungsaufträge diesen Maschinen zuordnen, mit Sichtbarkeit auch im
Kundenportal.
Ergebnis: Ein Fertigungsauftrag ist einer Maschine zugeordnet und sein Status ist für den
Kunden im Portal einsehbar.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Production, src/nexus/CentronNexus/ProductionOrderManagement
- Begründung: Parallele Implementierung im Backend und im Kundenportal belegt einen
kundenseitig sichtbaren Produktionsprozess.
Prüfidee: Ein im Backend angelegter Produktionsauftrag ist mit seinem Status im
CentronNexus-Portal für den zugeordneten Kunden sichtbar.
Tracelinks: SyRS-010
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - betrifft nur Kunden mit eigener Fertigung/Druckproduktion,
keine Kernfunktion für alle Mandanten.
Status: belegt
```
---
```
ID: StRS-011
Titel: Serviceabwicklung über Ticket, Aufgabe und Projekt
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Helpdesk-Mitarbeiter, Projektleiter, Kunde
Vorbedingung: Ein Kunde meldet ein Anliegen oder ein interner Vorgang muss bearbeitet werden.
Fakt: `ModuleRegistration.cs` Region "Helpdesk" registriert Checklisten,
Projektverwaltung, RMA/Werkstatt, Taskmanagement und Ticket-Liste als eigenständige,
rechte- und lizenzgesteuerte Module; `Centron.BL/ExpectedEvents` überwacht
wiederkehrende SLA-relevante Ereignisse.
Aussage: Das System soll Kundenanliegen als Tickets erfassen, ihre Bearbeitung über
Aufgaben und Checklisten strukturieren und wiederkehrende Ereignisse (z. B.
Wartungsfristen) automatisiert überwachen.
Ergebnis: Ein Ticket ist einem Mitarbeiter zugeordnet, seine Teilschritte sind als
Checkliste abgehakt und ein zugehöriges erwartetes Ereignis wird bei
Fristüberschreitung gemeldet.
Belege:
- [KONTEXT] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs Zeilen 698-726 (Region
"Helpdesk") - Begründung: Fünf getrennte, individuell lizenzierte Module belegen einen
ausdifferenzierten Serviceprozess.
- [SEKUNDÄR] src/backend/Centron.BL/ExpectedEvents - Begründung: Ein eigenes Modul für
"erwartete Events" belegt eine SLA-/Fristüberwachungsfunktion.
Prüfidee: Ein Ticket mit zugeordneter Checkliste zeigt den Bearbeitungsfortschritt anhand
abgehakter Punkte; ein überfälliges erwartetes Event erscheint in der Auswertung.
Tracelinks: SyRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Helpdesk/Ticketing ist Kernfunktion für IT-Dienstleister-Kunden.
Status: belegt
```
---
```
ID: StRS-012
Titel: Integrierte Kommunikation mit Kunden und im Team
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mitarbeiter, Kunde
Vorbedingung: Ein Termin, eine E-Mail, ein Anruf oder eine Chatnachricht betrifft einen
Geschäftsvorfall.
Fakt: `Centron.BL` enthält getrennte Module für `Calendar`, `AppointmentRequests`,
`Mail`/`MailScanner`, `Chats`, `SocialMedia` und `Tapi` (Telefonanlagenanbindung);
`NexusNotifications`/`Notifications` bilden System-Benachrichtigungen.
Aussage: Das System soll Termine, E-Mail-Verkehr, Telefonate und Chatnachrichten im
Kontext des jeweiligen Kunden- oder Servicevorgangs erfassen und den Nutzer über
relevante Ereignisse benachrichtigen.
Ergebnis: Ein eingehender Anruf oder eine E-Mail eines bekannten Kunden wird automatisch
dessen Kundenakte zugeordnet.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/{Calendar,Mail,MailScanner,Chats,Tapi} - Begründung:
Mehrere getrennte Kommunikationskanäle als eigene BL-Module belegen eine bewusst
kanalübergreifende Kommunikationsintegration.
Prüfidee: Ein über die TAPI-Anbindung erkannter eingehender Anruf einer hinterlegten
Kundenrufnummer öffnet automatisch die zugehörige Kundenakte.
Tracelinks: SyRS-012
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kommunikationsintegration ist wesentlicher CRM-Mehrwert.
Status: belegt
```
---
```
ID: StRS-013
Titel: Rollenbasierte Zugriffssteuerung und Datenschutz
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Systemadministrator, Datenschutzbeauftragter, alle Benutzer
Vorbedingung: Ein Benutzer greift auf eine Funktion oder einen Datensatz zu, oder ein
Datenschutz-relevanter Vorgang (Auskunft, Löschung) wird ausgelöst.
Fakt: `AppRightsBL.cs` implementiert ein gruppenbasiertes Rechtesystem (`AppGroup`,
`AppRight`, Tabellen `Sichgrup`/`Sichtrus`/`Sichmemb`) mit Protokollierung jeder
Rechteänderung (`AppRightLog`); `Administration/DataSecurity` und WPF
`CentronDataSecurityAppModuleController` bilden ein eigenes DSGVO-Modul.
Aussage: Das System soll den Zugriff auf Funktionen und Daten anhand von Benutzergruppen
und zugewiesenen Rechten steuern, jede Rechteänderung protokollieren und
datenschutzrechtliche Vorgänge (Auskunft, Löschung) unterstützen.
Ergebnis: Ein Benutzer sieht und nutzt ausschließlich die Module und Datensätze, für die
seine Gruppe berechtigt ist; Rechteänderungen sind im Audit-Log nachvollziehbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode
`HasUserRight(int appUserI3D, int rightID)` (Zeile 644) - Begründung: Diese Methode ist die
durchsetzende Stelle der Rechteprüfung; sie wird laut `ModuleRegistration.cs` vor jeder
Modulfreischaltung aufgerufen.
- [PRIMÄR] AppRightsBL.cs, Methode `DeleteRightGroup` (Zeile 348) - Begründung: Die Prüfung
`group.I3D == 6 || group.Name.Equals("Administratoren", ...)` verhindert das Löschen der
Administratorengruppe im Code selbst.
Prüfidee: Ein Benutzer ohne das Recht `UserRightsManagement.ID` kann über die UI keine
Rechtegruppe anlegen; der Versuch, die Administratorengruppe zu löschen, wird vom
System abgelehnt.
Tracelinks: SyRS-013, SyRS-014
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Rollenbasierte Zugriffssteuerung ist für ein Multi-User-ERP
zwingend erforderlich.
Status: belegt
```
---
```
ID: StRS-014
Titel: Mandanten- und Organisationsstammdaten
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Systemadministrator, HR
Vorbedingung: Ein neuer Mandant, eine Filiale oder ein Mitarbeiter soll angelegt werden.
Fakt: `Administration/Mandatory` verwaltet Mandanten, `Administration/Employees`
Mitarbeiterstammdaten, `Administration/Masterdata` die Organisationsstruktur;
`AppRightsBL` referenziert `BranchI3D` (Filialzuordnung) an mehreren Stellen zur
filialbezogenen Rechteeinschränkung.
Aussage: Das System soll mehrere Mandanten mit eigener Filial- und Mitarbeiterstruktur
abbilden und Rechte optional auf die eigene Filiale beschränken können.
Ergebnis: Ein Administrator kann einen neuen Mandanten mit eigenen Filialen und
Mitarbeitern anlegen, ohne Daten anderer Mandanten zu beeinflussen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Administration/{Mandatory,Employees,Masterdata} -
Begründung: Getrennte BL-Bereiche belegen eine mandanten- und filialfähige Datenstruktur.
- [PRIMÄR] AppRightsBL.cs Zeile 355-356 (`MANAGE_RIGHTS_ONLY_OWN_BRANCH` Prüfung gegen
`user.Employee.BranchI3D`) - Begründung: Der Code setzt die Filialbeschränkung aktiv durch.
Prüfidee: Ein Benutzer mit dem Recht "nur eigene Filiale" kann keine Rechtegruppe einer
anderen Filiale löschen oder anlegen.
Tracelinks: SyRS-015
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Mandanten-/Filialfähigkeit ist für den anvisierten SaaS-Betrieb
mit mehreren Kunden essenziell.
Status: belegt
```
---
```
ID: StRS-015
Titel: Konfigurierbarkeit, Lizenzierung und Systembetrieb
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Systemadministrator, c-entron-Support
Vorbedingung: Das System soll für einen Kunden individuell konfiguriert, lizenziert oder im
laufenden Betrieb diagnostiziert werden.
Fakt: Jeder Eintrag in `ModuleRegistration.cs` prüft neben Benutzerrechten zusätzlich
`LicenseManager.Instance.HasLicense(...)`; `Administration/Licensing`,
`Administration/BackgroundServices` (siehe `docs/Background Service/
DataQualityService.md`) und `Administration/NetworkDiagnostics` runden den
Systembetrieb ab.
Aussage: Das System soll Funktionsumfang je Kunde über Lizenzschlüssel steuern, zentrale
Betriebsparameter konfigurierbar machen und dem Administrator Diagnosewerkzeuge
für den laufenden Betrieb bereitstellen.
Ergebnis: Ein Kunde ohne die passende Lizenz sieht das zugehörige Modul im Client nicht;
ein Administrator kann Verbindungs- oder Performanceprobleme selbst eingrenzen.
Belege:
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, z. B. Zeile 423
(`LicenseManager.Instance.HasLicense(LicenseGuids.FlatRateBilling) ||
LicenseManager.Instance.HasLicense(LicenseGuids.Centron)`) - Begründung: Jede
Modulregistrierung ist im Code an eine konkrete Lizenzprüfung gekoppelt, die die
Verfügbarkeit unmittelbar steuert.
- [KONTEXT] docs/Background Service/DataQualityService.md - Begründung: Dokumentierter
Hintergrunddienst belegt einen bewussten Betriebsprozess über die reine Anwendung hinaus.
Prüfidee: Wird die Lizenz für ein Modul entzogen, verschwindet der zugehörige Menüpunkt
beim nächsten Programmstart.
Tracelinks: SyRS-016, SyRS-017
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Lizenzsteuerung ist Grundlage des bestehenden
Geschäftsmodells (Modul-/Add-on-Verkauf).
Status: belegt
```
---
```
ID: StRS-016
Titel: Kundenspezifische Anpassbarkeit
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Systemadministrator, c-entron-Support
Vorbedingung: Ein Kunde benötigt eine vom Standard abweichende Konfiguration, ein Zusatzfeld
oder eine eigene Textvorlage.
Fakt: `Administration/Customization` und `Centron.BL/Customizations` bilden
kundenspezifische Erweiterungen ab; `Centron.Controls/CustomProperties` erlaubt
benutzerdefinierte Zusatzfelder; `TextModuleArea` verwaltet globale Textbausteine.
Aussage: Das System soll kundenspezifische Anpassungen wie Zusatzfelder, Textbausteine und
Themes ermöglichen, ohne den Quellcode je Kunde zu verzweigen.
Ergebnis: Ein Administrator kann ein Zusatzfeld für eine Entität anlegen, ohne dass
Individualprogrammierung nötig ist.
Belege:
- [SEKUNDÄR] src/shared/Centron.Controls/CustomProperties - Begründung: Ein eigenständiges,
generisches Zusatzfeld-Modul belegt ein konfigurierbares statt hartkodiertes
Anpassungskonzept.
Prüfidee: Ein neu angelegtes Zusatzfeld erscheint nach der Konfiguration in der
entsprechenden Erfassungsmaske, ohne Neukompilierung.
Tracelinks: SyRS-018
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Konfigurierbarkeit reduziert Individualisierungsaufwand.
Status: belegt
```
---
```
ID: StRS-017
Titel: Automatisierung wiederkehrender Datenpflege
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Administrator, Fachanwender
Vorbedingung: Viele Datensätze sollen gleichzeitig geändert oder ein wiederkehrender Ablauf
automatisiert werden.
Fakt: `Centron.BL/MassUpdate` mit WPF `MassUpdatesAppModuleController` ("Data Updater")
und `Administration/Scripts/ScriptMethods` (serverseitig hinterlegte
Skriptmethoden) bilden Automatisierungswerkzeuge.
Aussage: Das System soll Massenänderungen an Datensätzen und hinterlegte
Automatisierungsskripte unterstützen, um wiederkehrende manuelle Pflegearbeit zu
vermeiden.
Ergebnis: Ein Administrator kann eine Änderung auf eine gefilterte Menge von Datensätzen in
einem Arbeitsschritt anwenden.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/MassUpdate - Begründung: Ein eigenes Modul für
Massenänderungen belegt einen bewusst vom Einzeldatensatz abgekoppelten Bearbeitungsweg.
Prüfidee: Eine Massenänderung auf 50 gefilterte Datensätze aktualisiert alle 50 Datensätze
in einem Vorgang.
Tracelinks: SyRS-019
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Massenpflege ist bei großen Datenbeständen notwendig.
Status: belegt
```
---
```
ID: StRS-018
Titel: Steuerung anhand betriebswirtschaftlicher Kennzahlen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsführung, Controlling, Teamleitung
Vorbedingung: Umsatz, Mitarbeiterauslastung oder Vertragsleistung sollen ausgewertet werden.
Fakt: `Centron.BL/Statistics`, `Centron.Controls/EmployeeAnalytics`,
`Finances/ContractEvaluation2` und die MSP-Module (`MspCollector`, `MSPComparer`,
`MspDashboard`) bilden getrennte Auswertungsbereiche.
Aussage: Das System soll Umsatz-, Auslastungs- und Vertragskennzahlen sowie
MSP-Nutzungsdaten auswerten und dem Management in Dashboards bereitstellen.
Ergebnis: Ein Manager sieht tagesaktuell Umsatz- und Auslastungskennzahlen ohne manuelle
Report-Erstellung.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Statistics, Centron.Controls/EmployeeAnalytics -
Begründung: Getrennte, spezialisierte Auswertungsmodule belegen ein etabliertes
Controlling-Konzept.
Prüfidee: Das Management-Info-Dashboard zeigt für den aktuellen Monat einen Umsatzwert, der
mit der Summe der im Zeitraum gebuchten Rechnungen übereinstimmt.
Tracelinks: SyRS-020
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kennzahlensteuerung ist Standarderwartung an ein ERP-System.
Status: belegt
```
---
```
ID: StRS-019
Titel: Persönlicher Arbeitsbereich je Mitarbeiter
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Alle Mitarbeiter
Vorbedingung: Ein Mitarbeiter meldet sich an und möchte seinen Tag/seine Aufgaben organisieren.
Fakt: `ModuleRegistration.cs` Region "MyCentron" registriert Dashboard, Mein-Tag-Editor,
Telefonate und To-do-Liste ohne Rechteprüfung (`Helper.NoRightCheck()`), also für
jeden angemeldeten Benutzer; zusätzlich ein KI-Chat-Modul mit eigener
Rechteprüfung.
Aussage: Das System soll jedem angemeldeten Mitarbeiter einen persönlichen
Arbeitsbereich mit Dashboard, Tagesplanung, Anrufliste und Aufgabenliste sowie
optional einen KI-Assistenten bereitstellen.
Ergebnis: Nach der Anmeldung sieht ein Mitarbeiter unmittelbar seine offenen Aufgaben und
Termine des Tages.
Belege:
- [PRIMÄR] ModuleRegistration.cs Zeilen 772-800 (Region "MyCentron"),
`() => Helper.NoRightCheck()` für Dashboard/Mein Tag/Telefonate/Todo-Liste - Begründung:
Der Code selbst schaltet diese Module ohne Rechteprüfung für jeden Benutzer frei.
Prüfidee: Ein neu angelegter Benutzer ohne zugewiesene Sonderrechte sieht nach der Anmeldung
Dashboard, Mein Tag, Telefonate und To-do-Liste im Menü.
Tracelinks: SyRS-021
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Persönlicher Arbeitsbereich erhöht die Akzeptanz der Anwendung.
Status: belegt
```
---
```
ID: StRS-020
Titel: Ergänzende Zusatzfunktionen für Spezialprozesse
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Verschiedene Fachanwender
Vorbedingung: Ein Spezialprozess außerhalb der Kernabläufe (Gutscheine, Schulungsvideos,
Marktplatzanbindung, IT-Kapazitätsplanung, Zeiterfassung) tritt auf.
Fakt: `Centron.BL` enthält hierfür isolierte, jeweils sehr kleine Module (u. a.
`VoucherManagement`, `VideoPortal`, `TradePool`, `SelfCare`, `WebLinks`, `Tags`,
`ObjectExternalReferences`, `ItPlanner`, `Time`); ein Reisekostenmodul ist im
Client-Code auskommentiert.
Aussage: Das System soll für eine Reihe fachlich eigenständiger, aber im Tagesgeschäft
seltener genutzter Vorgänge (u. a. Gutscheine, Marktplatzanbindung,
Zeiterfassung) jeweils ein einfaches, dediziertes Modul bereitstellen.
Ergebnis: Für jeden dieser Spezialfälle existiert eine eigene, auffindbare Funktion, ohne
dass sie den Kernprozess verkompliziert.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/{VoucherManagement,VideoPortal,TradePool,SelfCare,
WebLinks,Tags,ObjectExternalReferences,ItPlanner,Time} - Begründung: Jeweils sehr kleine
(1-2 Dateien), thematisch klar abgegrenzte Ordner belegen bewusst isolierte
Einzelfunktionen statt eines gemeinsamen Konzepts.
- [KONTEXT] ModuleRegistration.cs Zeilen 904-906 (auskommentiertes
`TravelExpenseAppModuleController`, Kommentar "Hide the travel expense module for now") -
Begründung: Der Kommentar dokumentiert einen bewusst deaktivierten, unfertigen
Funktionsbereich.
Prüfidee: Jedes der genannten Module ist über die Anwendung erreichbar und für seinen
engen Anwendungsfall nutzbar.
Tracelinks: SyRS-022
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - jeweils Nischenfunktion für einzelne Kunden/Anwendungsfälle,
keine für den Massenmarkt zwingende Kernfunktion.
Status: belegt
```
---
```
ID: StRS-021
Titel: Produktdatenpflege über externe Kataloganbieter
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Einkauf, Artikelpflege
Vorbedingung: Artikelstammdaten oder Produktbilder sollen automatisiert aktualisiert werden.
Fakt: `src/apis` enthält je einen eigenen Assembly-Verbund für COP-, ITscope- und
Icecat-Datenzugriff sowie ein eigenes docuFORM-API-Projekt.
Aussage: Das System soll Artikelstammdaten und Produktbilder automatisiert von externen
Katalog-/Datenanbietern beziehen, statt sie manuell zu pflegen.
Ergebnis: Ein importierter Artikel enthält nach dem Abgleich mit dem externen Anbieter
aktuelle technische Daten und ein Produktbild.
Belege:
- [SEKUNDÄR] src/apis/Centron.APIs.{CopDataAccess,ITscopeDataAccess,IcecatDataAccess} -
Begründung: Drei eigenständige, produktiv gepflegte API-Client-Projekte belegen etablierte
Integrationen mit Produktdatenlieferanten.
Prüfidee: Ein Artikel mit hinterlegter Hersteller-Artikelnummer erhält nach dem
Datenabgleich ein Produktbild aus einer der angebundenen Quellen.
Tracelinks: SyRS-023
Konsolidierung: Kandidat: COP-, ITscope- und Icecat-Anbindung bilden dieselbe fachliche Funktion
"Produktdatenabgleich" für unterschiedliche Anbieter und sind Kandidaten für eine
gemeinsame Abstraktionsschicht im Zielsystem.
Übernahmewürdigkeit: übernehmen - Automatisierte Produktdatenpflege ist im IT-Fachhandel Standard.
Status: belegt
```
---
```
ID: StRS-022
Titel: Kunden-Self-Service über Web-Portal
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Endkunde, Vertrieb
Vorbedingung: Ein Kunde möchte ohne Mitwirkung eines Mitarbeiters ein Angebot annehmen,
bestellen, ein Ticket einsehen oder ein Dokument unterschreiben.
Fakt: `src/nexus/CentronNexus` (Blazor-Server-Anwendung) enthält eigene Bereiche
`WebOffer`, `WebCart`, `ServiceBoard`, `DocumentSigning` und `Office`; ein
separates Outlook-Add-in (`CentronNexus.OutlookAddIn`) bindet CRM/Tickets/Belege
in Outlook ein.
Aussage: Das System soll Kunden über ein Web-Portal die selbstständige Annahme von
Angeboten, Bestellungen, Einsicht in Tickets und digitale Unterschrift von
Dokumenten ermöglichen.
Ergebnis: Ein Kunde kann ein ihm zugesandtes Angebot online annehmen und die zugehörige
Auftragsbestätigung digital unterschreiben, ohne dass ein Mitarbeiter eingreifen
muss.
Belege:
- [SEKUNDÄR] src/nexus/CentronNexus/{WebOffer,WebCart,ServiceBoard,DocumentSigning} -
Begründung: Getrennte, produktiv ausgebaute Portal-Bereiche belegen ein vollständiges
Self-Service-Konzept über die reine Ticketeinsicht hinaus.
Prüfidee: Ein Kunde kann sich im Portal anmelden, ein offenes Angebot einsehen und
digital annehmen.
Tracelinks: SyRS-024
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Web-Self-Service ist zentrale Voraussetzung/Blaupause für die
geplante Web-/SaaS-Neuimplementierung.
Status: belegt
```
---
```
ID: StRS-023
Titel: Offene Integrationsschnittstelle für Drittsysteme
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Drittsystem, Systemintegrator
Vorbedingung: Ein externes System oder ein anderer c-entron-Client soll auf Daten oder
Funktionen zugreifen.
Fakt: Es existieren zwei parallele Web-API-Schichten: die Legacy-Schnittstelle
`Centron.WebServices.Core`/`ICentronRestService` und die modernen ASP.NET-Core-
Controller unter `Centron.Controllers/Controllers/v1` mit Domänen wie Accounts,
Contracts, Customers, Offers, Orders, Receipts, Tickets.
Aussage: Das System soll Kernfunktionen (Kunden, Belege, Tickets, Verträge) über eine
versionierte REST-Schnittstelle für Drittsysteme und den Web-Client bereitstellen.
Ergebnis: Ein Drittsystem kann über die v1-API einen Auftrag anlegen, ohne den WPF-Client
zu verwenden.
Belege:
- [SEKUNDÄR] src/webservice/Centron.Controllers/Controllers/v1/{Customers,Offers,Orders,
Receipts,Tickets,Contracts} - Begründung: Eine nach Fachdomänen und Versionsnummer (v1)
strukturierte Controller-Sammlung belegt eine bewusst nach außen geöffnete, versionierte API.
Prüfidee: Ein authentifizierter Aufruf von `v1/Orders` liefert die Aufträge des
angefragten Kunden im dokumentierten Format.
Tracelinks: SyRS-025
Konsolidierung: Kandidat: Legacy-REST-Service (`ICentronRestService`) und moderne v1-Controller
bilden für überlappende Funktionen (z. B. Kunden, Belege) dieselbe fachliche
Funktion auf zwei parallelen technischen Wegen ab.
Übernahmewürdigkeit: übernehmen - Offene API ist Voraussetzung für Integrationen und die
Web-Neuimplementierung; die Doppelspurigkeit der beiden REST-Schichten ist ein
Workaround aus der schrittweisen Migration.
Status: belegt
```
---
```
ID: StRS-024
Titel: Wartbare, portierbare technische Basis
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: Entwicklungsteam
Vorbedingung: Neue Fachfunktionen sollen ergänzt oder auf eine neue Zielarchitektur überführt
werden.
Fakt: `docs/getting-started/general-structure.md` beschreibt eine verbindliche
Schichtenarchitektur (ViewModel → ILogic/BLLogic/WSLogic → WebServiceBL →
BL/NHibernate) mit der Vorgabe, für jedes Modul sowohl eine
Datenbank-Direktzugriffs- als auch eine Webservice-Implementierung
bereitzustellen.
Aussage: Das System soll fachliche Module unabhängig vom Zugriffsweg (Datenbank oder
Webservice) über eine einheitliche Schichtenarchitektur anbinden, um künftige
Wartung und schrittweise Migration zu erleichtern.
Ergebnis: Eine neue Fachfunktion lässt sich nach dem dokumentierten Muster ergänzen, ohne
bestehende Aufrufer anzupassen.
Belege:
- [KONTEXT] docs/getting-started/general-structure.md, Abschnitt "Dual Implementation
Architecture" - Begründung: Die Dokumentation beschreibt eine im Code durchgängig
verwendete, verbindliche Architekturregel für alle Module.
Prüfidee: Für ein neues Modul existieren sowohl eine `BL{Modul}Logic`- als auch eine
`WS{Modul}Logic`-Implementierung des gleichen `I{Modul}Logic`-Interfaces.
Tracelinks: SyRS-026
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Die Schichtentrennung ist Voraussetzung für eine geordnete
Migration einzelner Module in die geplante Web-/SaaS-Architektur.
Status: belegt
```
---
```
ID: StRS-025
Titel: Reproduzierbare Bereitstellung und Betrieb
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Übertragbarkeit
Akteur: Betrieb, Entwicklungsteam
Vorbedingung: Eine neue Version soll beim Kunden installiert oder als Service betrieben werden.
Fakt: `deployment/WixSharpInstaller` erzeugt Windows-Installationspakete; `docker/`
enthält Compose-Definitionen für API, Webservice und Demo-Umgebung; `.github/
workflows` und `azure/build-templates` definieren automatisierte Build-Pipelines.
Aussage: Das System soll sowohl als klassische Windows-Installation als auch
containerisiert (Docker) reproduzierbar bereitgestellt werden können, abgesichert
durch automatisierte Build-Pipelines.
Ergebnis: Ein Release lässt sich ohne manuelle Zusatzschritte sowohl als Windows-Setup als
auch als Docker-Image ausliefern.
Belege:
- [KONTEXT] docker/compose, docker/c-entron-api, docker/c-entron-webservice - Begründung:
Mehrere Compose-/Dockerfile-Definitionen belegen eine produktiv genutzte
Container-Bereitstellung neben der klassischen Windows-Installation.
Prüfidee: Ein `docker compose up` der bereitgestellten Compose-Datei startet die
Webservice-Komponente ohne manuelle Konfigurationsschritte.
Tracelinks: SyRS-027
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Containerisierte Bereitstellung ist unmittelbare Grundlage für
den Zielbetrieb als Web-/SaaS-Lösung.
Status: belegt
```
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/SwRS.md
+5928
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/SyRS.md
+908
View File
@@ -0,0 +1,908 @@
# System Requirements Specification (SyRS) — c-entron ERP-Suite
Systemverhalten, Schnittstellen sowie Performance- und Sicherheitsanforderungen je Fachbereich.
Jede SyRS-Anforderung konkretisiert eine StRS-Anforderung in Richtung Systemverhalten und wird von
einer oder mehreren SwRS-Anforderungen weiter konkretisiert (siehe `Traceability.md`).
---
```
ID: SyRS-001
Titel: Einheitliches Kundendatenmodell über Adress-, Kontakt- und CRM-Teilbereiche
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System (BL-Schicht)
Vorbedingung: Eine Adresse, ein Ansprechpartner oder eine CRM-Aktivität wird gespeichert.
Fakt: `AddressBL.DoValidateValues` erzwingt, dass eine Adresse entweder `CustomerI3D`
oder `SupplierI3D` gesetzt hat; `Address.ContactPersons` verknüpft Ansprechpartner
mit genau einer Adresse (`DoBeforeSave`, Zeile 208-211).
Aussage: Das System soll jede Adresse eindeutig genau einem Kunden oder einem Lieferanten
zuordnen und Ansprechpartner konsistent mit ihrer Adresse verknüpfen.
Ergebnis: Eine Adresse ohne Zuordnung zu Kunde oder Lieferant wird beim Speichern
zurückgewiesen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Customers/Addresses/AddressBL.cs, Methode
`DoValidateValues` (Zeile 225-238) - Begründung: Die Bedingung
`!(CustomerI3D>0) && !(SupplierI3D>0)` erzwingt im Code die Kunden-/Lieferantenzuordnung
vor jedem Speichervorgang.
Prüfidee: Ein Speicherversuch einer Adresse ohne `CustomerI3D` und ohne `SupplierI3D`
liefert `Result.AsError` mit dem Text "Die Anschrift muss entweder einem Kunden
oder einem Lieferanten zugeordnet sein.".
Tracelinks: StRS-001; SwRS-001, SwRS-002
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Eindeutige Zuordnung ist Grundvoraussetzung für Adressdaten.
Status: belegt
```
---
```
ID: SyRS-002
Titel: Belegkette mit gemeinsamer Basislogik je Belegart
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (BL-Schicht)
Vorbedingung: Ein Beleg einer bestimmten Art (Angebot, Auftrag, Lieferschein, Rechnung,
Gutschrift, Anzahlung) wird angelegt oder weitergeleitet.
Fakt: `ReceiptBL.cs` bildet die gemeinsame Basisklasse für alle Belegarten;
`DataAndResults/ForwardReceipt` und `CreateReceipt` enthalten die Logik zur
Umwandlung eines Belegs in eine andere Belegart.
Aussage: Das System soll alle Belegarten über eine gemeinsame Basislogik verwalten und die
Weiterleitung eines Belegs in eine andere Belegart unterstützen, ohne Positionsdaten
erneut zu erfassen.
Ergebnis: Positionen und Kundendaten eines Angebots werden bei der Weiterleitung in einen
Auftrag unverändert übernommen, sofern nicht manuell geändert.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs - Begründung: Eine gemeinsame
Basisklasse für alle Belegarten belegt ein einheitliches Datenmodell über die Belegkette
hinweg.
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/DataAndResults/ForwardReceipt - Begründung:
Ein eigener Ordner für die Weiterleitungslogik belegt eine bewusst implementierte
Belegumwandlung.
Prüfidee: Nach Weiterleitung eines Angebots in einen Auftrag stimmen Positionsanzahl und
Summen von Angebot und neu erzeugtem Auftrag überein.
Tracelinks: StRS-002; SwRS-011, SwRS-012, SwRS-013, SwRS-015, SwRS-016
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-003
Titel: Protokollierte Belegänderung und Freigabeworkflow
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (BL-Schicht)
Vorbedingung: Ein Beleg wird geändert, neu versioniert oder aus dem Warenkorb freigegeben.
Fakt: `ReceiptLogBL.cs` schreibt Protokolleinträge zu Belegänderungen;
`ReceiptCartReleaseSystemBL.cs` steuert einen mehrstufigen
Freigabeworkflow für Beleg-Warenkörbe.
Aussage: Das System soll jede Änderung an einem gespeicherten Beleg protokollieren und
die Freigabe von Beleg-Warenkörben über einen definierten Workflow steuern.
Ergebnis: Zu jedem Beleg lässt sich die Änderungshistorie nachvollziehen; ein
Beleg-Warenkorb wechselt erst nach Freigabe in einen abrechenbaren Beleg.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs - Begründung: Eine
dedizierte Log-Klasse belegt eine bewusste Protokollierungsfunktion pro Beleg.
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs -
Begründung: Eine eigenständige Klasse für das Freigabesystem belegt einen mehrstufigen,
nicht trivialen Workflow.
Prüfidee: Ein Beleg-Warenkorb kann erst nach Ausführung des Freigabeschritts als Beleg
abgeschlossen werden.
Tracelinks: StRS-003; SwRS-020, SwRS-021, SwRS-022, SwRS-028
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-004
Titel: Spiegelbildliche Einkaufsbelegkette mit EDI-Anbindung
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (BL-Schicht)
Vorbedingung: Eine Bestellung, ein Wareneingang oder eine Eingangsrechnung wird erfasst.
Fakt: `Sales/Receipts/Supplier*`-Ordner bilden die Einkaufsseite strukturell analog zur
Verkaufsseite ab; `EDI`-Modul und `EDIManagementController` verbinden diese mit
den Gateway-Konnektoren.
Aussage: Das System soll Einkaufsbelege strukturell analog zu Verkaufsbelegen verwalten
und wahlweise über EDI automatisiert befüllen.
Ergebnis: Eine per EDI eingehende Bestellbestätigung erzeugt oder aktualisiert automatisch
den zugehörigen internen Bestellbeleg.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/SupplierOrders,
src/backend/Centron.BL/EDI - Begründung: Parallele Ordnerstruktur zur Verkaufsseite und ein
eigenes EDI-Modul belegen eine bewusst gespiegelte, teilautomatisierte Einkaufskette.
Prüfidee: Eine importierte EDI-Bestellbestätigung ist im internen Bestellbeleg mit
übereinstimmender Positionsanzahl sichtbar.
Tracelinks: StRS-004; SwRS-031..SwRS-038
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-005
Titel: Partnerspezifische Nachrichtenformate für elektronischen Belegaustausch
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal: Interoperabilität
Akteur: System (Gateway-Schicht), externer Distributor
Vorbedingung: Ein Beleg soll elektronisch mit einem angebundenen Partner ausgetauscht werden.
Fakt: Je Distributor existiert ein eigener Namespace/Ordner in `Centron.Gateway`
(`EDI_Alltron`, `EDI_Also`, `EDI_AlsoCH`, `EDI_Herweck`, `EDI_Komsa`, `EDI_EGIS`)
mit jeweils eigenen Parser-/Formatierungsklassen; `ZUGFeRD21_Extended` erzeugt
das strukturierte XML-Rechnungsformat gemäß `docs/reference/
zugferd-field-mapping.md`.
Aussage: Das System soll für jeden angebundenen Partner das von ihm geforderte
Nachrichtenformat erzeugen bzw. verarbeiten, ohne die fachliche Beleglogik
partnerabhängig zu verändern.
Ergebnis: Ein an EGIS übermittelter Auftrag entspricht dem EGIS-spezifischen Format, eine
an Alltron übermittelte Bestellung dem Alltron-Format.
Belege:
- [SEKUNDÄR] src/backend/Centron.Gateway/EDI_EGIS (26 Dateien), EDI_Alltron (4 Dateien) -
Begründung: Unterschiedlich umfangreiche, partnerspezifische Implementierungen belegen
real unterschiedliche, individuell zu pflegende Formatanforderungen.
- [KONTEXT] docs/reference/zugferd-field-mapping.md - Begründung: Eine dedizierte
Feld-für-Feld-Zuordnung belegt eine formal geprüfte Formatkonformität für ZUGFeRD.
Prüfidee: Eine erzeugte ZUGFeRD-Rechnung validiert gegen das im Mapping-Dokument
referenzierte Schema.
Tracelinks: StRS-005; SwRS-039..SwRS-046
Konsolidierung: Kandidat: siehe StRS-005 (partnerspezifische EDI-Module als
Konsolidierungskandidat für eine gemeinsame Abstraktion).
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-006
Titel: Automatisierter Kontoabgleich und SEPA-Zahlungserzeugung
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal: Sicherheit
Akteur: System, Bank/FinAPI, Kunde
Vorbedingung: Ein Kontoumsatz soll abgerufen oder eine SEPA-Zahlung erzeugt werden.
Fakt: `OnlineBankingFinApiBL.cs` ruft Kontoumsätze über die FinAPI-REST-Schnittstelle
(`src/apis/Centron.APIs.FinAPI/RestClient`) ab; `PaymentTransactionAppModuleController`
ist an das Recht `INCOMING_PAYMENT_TRANSACTIONS` gekoppelt.
Aussage: Das System soll Kontoumsätze über eine gesicherte externe Bankschnittstelle
abrufen und SEPA-Zahlungsdateien nur für berechtigte Benutzer erzeugen.
Ergebnis: Nur ein Benutzer mit dem Recht `INCOMING_PAYMENT_TRANSACTIONS` kann einen
SEPA-Zahllauf auslösen; abgerufene Umsätze sind einem Bankkonto im System
zugeordnet.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs -
Begründung: Eine dedizierte Klasse kapselt den Zugriff auf die externe FinAPI-Schnittstelle.
- [PRIMÄR] ModuleRegistration.cs Zeile 617-619
(`Helper.HasRights(UserRightsConst.Controlling.ID, ..., INCOMING_PAYMENT_TRANSACTIONS)`)
für `PaymentTransactionAppModuleController` - Begründung: Die Rechteprüfung im Code
entscheidet unmittelbar über die Sichtbarkeit des SEPA-Moduls.
Prüfidee: Ein Benutzer ohne `INCOMING_PAYMENT_TRANSACTIONS` sieht das SEPA-Modul nicht im
Menü.
Tracelinks: StRS-006; SwRS-047..SwRS-051
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-007
Titel: Periodischer Abrechnungslauf mit modellabhängiger Mengenermittlung
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: Zuverlässigkeit
Akteur: System (Abrechnungslauf), Buchhaltung
Vorbedingung: Der Abrechnungszeitpunkt eines Vertrags ist erreicht.
Fakt: `AutomatedBillingAppModuleController` ist an das Recht `Sales.AUTOMATED_BILLING`
gekoppelt; getrennte BL-Bereiche `FlatrateBilling`, `TimerBilling` und die
Klickzähler-Erfassung (`DeviceClickCounterAppModuleController`) implizieren
unterschiedliche Mengenermittlungslogik je Abrechnungsmodell.
Aussage: Das System soll für jedes Abrechnungsmodell (Pauschale, Ticketzeit, Klickzähler)
die abzurechnende Menge modellabhängig ermitteln und daraus automatisiert
Rechnungen erzeugen.
Ergebnis: Ein Abrechnungslauf erzeugt für einen Klickabrechnungsvertrag eine Rechnung auf
Basis der erfassten Zählerstände, für einen Pauschalvertrag auf Basis der
vereinbarten Festmenge.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Finances/{FlatrateBilling,TimerBilling},
WPF DeviceClickCounterAppModuleController - Begründung: Getrennte Implementierungen je
Abrechnungsmodell belegen unterschiedliche, nicht generische Mengenermittlungslogik.
Prüfidee: Ein Abrechnungslauf für einen Vertrag mit 100 erfassten Klicks und einem
hinterlegten Preis pro Klick erzeugt eine Rechnungsposition mit der Menge 100.
Tracelinks: StRS-007; SwRS-052..SwRS-059
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-008
Titel: Schemabasierte Provisionsberechnung und zentrale Finanzstammdaten
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System, Buchhaltung
Vorbedingung: Ein Beleg wird abgeschlossen bzw. Finanzstammdaten werden referenziert.
Fakt: `ReceiptProvisionSchemaBL.cs`, `ReceiptProvisionEmployeeLevelBL.cs` und
`ReceiptProvisionEmployeeGoalBL.cs` verknüpfen Belege mit
Provisionsschema/-stufe/-ziel je Mitarbeiter; `Warehousing/TaxBL.cs` liefert
Steuersätze für die Preisberechnung.
Aussage: Das System soll Provisionen anhand des dem Mitarbeiter zugeordneten Schemas und
dessen Stufe/Ziel berechnen und dabei zentral gepflegte Steuersätze für die
Preisberechnung verwenden.
Ergebnis: Zwei Mitarbeiter mit unterschiedlichem Provisionsschema erhalten für einen
gleich hohen Beleg unterschiedliche Provisionsbeträge.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptProvisionSchemaBL.cs,
ReceiptProvisionEmployeeLevelBL.cs - Begründung: Getrennte Klassen für Schema und
Mitarbeiterstufe belegen eine mehrdimensionale Provisionsberechnung.
Prüfidee: Für zwei Mitarbeiter mit unterschiedlichem, dem Beleg zugrunde liegendem
Provisionsschema ergeben sich bei gleichem Belegwert unterschiedliche
Provisionsbeträge.
Tracelinks: StRS-008; SwRS-060..SwRS-067
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-009
Titel: Artikelstammdaten mit mehrstufiger Preisfindung und Versandanbindung
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: Performanz-Effizienz
Akteur: System, Versanddienstleister
Vorbedingung: Ein Artikel wird bepreist, kommissioniert oder versendet.
Fakt: `ArticleVolumePricesBL.cs` (Staffelpreise) und `ActionPriceBL.cs` (Aktionspreise)
existieren neben der Grundpreisermittlung in `ArticleBL.cs`; `Centron.Api.Gls`
und `Centron.Api.Shipcloud` implementieren getrennte REST-Clients für
Versandlabels.
Aussage: Das System soll den Artikelpreis unter Berücksichtigung von Staffel- und
Aktionspreisen ermitteln und Versandlabels über die jeweils konfigurierte
Carrier-Schnittstelle erzeugen.
Ergebnis: Bei ausreichender Bestellmenge wird automatisch der Staffelpreis statt des
Grundpreises verwendet; ein Versandlabel wird über den im Auftrag hinterlegten
Carrier erzeugt.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Warehousing/ArticleVolumePricesBL.cs,
ActionPriceBL.cs - Begründung: Getrennte Klassen für Staffel- und Aktionspreis belegen eine
mehrstufige, nicht triviale Preisfindungslogik.
- [SEKUNDÄR] src/apis/Centron.Api.Gls, src/apis/Centron.Api.Shipcloud - Begründung: Zwei
unabhängige Carrier-Client-Projekte belegen eine austauschbare Versandanbindung.
Prüfidee: Eine Bestellmenge oberhalb der hinterlegten Staffelgrenze führt zu einem
niedrigeren Einzelpreis als eine Bestellung unterhalb der Grenze.
Tracelinks: StRS-009; SwRS-068..SwRS-079
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-010
Titel: Maschinen-Fertigungsauftrags-Zuordnung mit Portal-Sichtbarkeit
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System, Kunde (Portal)
Vorbedingung: Ein Fertigungsauftrag wird angelegt oder sein Status ändert sich.
Fakt: `ProductionOrderManagementAppModuleController` (Backend) und
`CentronNexus/ProductionOrderManagement` (Portal) referenzieren dieselben
Fertigungsauftragsdaten.
Aussage: Das System soll Statusänderungen an einem Fertigungsauftrag im Backend
unmittelbar auch im Kundenportal sichtbar machen.
Ergebnis: Eine Statusänderung eines Fertigungsauftrags im Backend ist ohne zusätzlichen
Export im Portal sichtbar.
Belege:
- [SEKUNDÄR] src/nexus/CentronNexus/ProductionOrderManagement - Begründung: Ein eigener
Portal-Bereich mit demselben fachlichen Namen wie das Backend-Modul belegt eine bewusste
Spiegelung der Fertigungsauftragsdaten in Richtung Kunde.
Prüfidee: Eine im Backend vorgenommene Statusänderung eines Fertigungsauftrags erscheint
beim nächsten Laden der Portalseite des zugeordneten Kunden.
Tracelinks: StRS-010; SwRS-080, SwRS-081
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall
Status: belegt
```
---
```
ID: SyRS-011
Titel: Ticket-Aufgaben-Verknüpfung mit automatisierter Fristüberwachung
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: Zuverlässigkeit
Akteur: System, Helpdesk-Mitarbeiter
Vorbedingung: Ein Ticket wird angelegt oder ein erwartetes Ereignis überschreitet seine Frist.
Fakt: `Centron.BL/ExpectedEvents` überwacht wiederkehrende Ereignisse unabhängig vom
einzelnen Ticket; `WPF ExpectedEventsReportingAppModuleController` wertet
Fristüberschreitungen separat aus.
Aussage: Das System soll erwartete, wiederkehrende Ereignisse unabhängig von einzelnen
Tickets terminieren und bei Fristüberschreitung in einer eigenen Auswertung
anzeigen.
Ergebnis: Ein überfälliges erwartetes Ereignis erscheint in der Auswertung, auch wenn kein
Mitarbeiter das zugehörige Ticket aktiv geöffnet hat.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/ExpectedEvents - Begründung: Ein von der Ticketverwaltung
unabhängiges BL-Modul belegt eine eigenständige, nicht rein UI-getriebene Fristüberwachung.
Prüfidee: Ein erwartetes Ereignis mit überschrittenem Fälligkeitsdatum erscheint in der
Erwartete-Events-Auswertung, ohne dass ein Benutzer es zuvor geöffnet hat.
Tracelinks: StRS-011; SwRS-082..SwRS-091
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-012
Titel: Kanalübergreifende Zuordnung von Kommunikationsereignissen zum Kunden
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Ein Anruf, eine E-Mail oder eine Chatnachricht trifft ein oder wird gesendet.
Fakt: `Centron.BL/Tapi` protokolliert Anrufe, `Mail`/`MailScanner` verarbeitet
ein-/ausgehende E-Mails; beide Module referenzieren Kundenentitäten aus
`Sales/Customers`.
Aussage: Das System soll eingehende und ausgehende Kommunikationsereignisse anhand von
Rufnummer bzw. E-Mail-Adresse automatisch einem bestehenden Kundendatensatz
zuordnen.
Ergebnis: Ein Anruf von einer im System hinterlegten Kundenrufnummer wird ohne manuelle
Suche der Kundenakte zugeordnet.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Tapi, src/backend/Centron.BL/MailScanner - Begründung:
Eigenständige Module für Telefonie- und Mail-Verarbeitung mit Bezug zu Kundenentitäten
belegen eine bewusste automatische Zuordnung.
Prüfidee: Ein simulierter eingehender Anruf mit einer im Kundenstamm hinterlegten
Rufnummer öffnet automatisch die passende Kundenakte.
Tracelinks: StRS-012; SwRS-092..SwRS-099
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-013
Titel: Rechteprüfung als verbindliches Gate vor jeder Modul- und Funktionsfreischaltung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System (Autorisierungsschicht)
Vorbedingung: Ein Benutzer meldet sich an oder ruft eine geschützte Funktion auf.
Fakt: `AppRightsBL.HasUserRight` prüft anhand der SQL-Abfrage über `Sichtrus`/`Sichmemb`,
ob ein Benutzer ein bestimmtes Recht besitzt; jeder Eintrag in
`ModuleRegistration.cs` ruft vor der Modulregistrierung `Helper.HasRights(...)`
auf, das intern auf denselben Mechanismus zurückgreift; Rechte werden
10 Minuten lang gecacht (`Session.Advanced.Cache.GetOrAdd`).
Aussage: Das System soll vor jeder Funktionsfreischaltung serverseitig prüfen, ob der
angemeldete Benutzer über das erforderliche Recht verfügt, und darf sich dabei
nicht ausschließlich auf eine clientseitige Ausblendung verlassen.
Ergebnis: Ein Benutzer ohne das erforderliche Recht kann die zugehörige Funktion auch bei
direktem API-Aufruf nicht ausführen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode
`HasUserRight(int appUserI3D, int rightID)` (Zeile 644-649) - Begründung: Diese Methode ist
die durchsetzende Stelle; sie führt die SQL-Prüfung `SELECT st.Recht ... FROM Sichtrus st
INNER JOIN Sichmemb sm ...` aus und liefert das bindende Ja/Nein für die Berechtigung.
- [HYPOTHESE] Ob jeder der 176 REST-Endpunkte unter `Centron.Controllers/Controllers/v1`
serverseitig ebenfalls `HasUserRight` bzw. ein Autorisierungsattribut aufruft, wurde nicht
für jeden einzelnen Controller verifiziert - Begründung für Hypothese: Eine vollständige
Prüfung aller Controller-Methoden auf serverseitige Rechteprüfung ist im Rahmen dieser
statischen Breitenanalyse nicht für jeden Endpunkt einzeln erfolgt; es wäre zu bestätigen,
dass keine Methode ausschließlich auf clientseitige Sichtbarkeitssteuerung vertraut.
Prüfidee: Ein direkter, authentifizierter API-Aufruf einer rechtebeschränkten Funktion
durch einen Benutzer ohne das erforderliche Recht liefert einen
Autorisierungsfehler, unabhängig davon, ob der zugehörige Menüpunkt im Client
sichtbar wäre.
Tracelinks: StRS-013; SwRS-100, SwRS-101, SwRS-103, SwRS-167, SwRS-168
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - serverseitige Rechteprüfung ist sicherheitskritisch und muss
in jeder Zielarchitektur erhalten bleiben.
Status: belegt
```
---
```
ID: SyRS-014
Titel: Datenschutzkonforme Verarbeitung und Löschung personenbezogener Daten
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: Datenschutzbeauftragter, System
Vorbedingung: Ein Auskunfts- oder Löschersuchen zu personenbezogenen Daten liegt vor.
Fakt: `CentronDataSecurityAppModuleController` ist an das eigene Recht
`DsgvoModule.ACCESS_DSGVO_MODULE` gekoppelt; `AppRightsBL.GetAssignableAdminRightI3Ds`
listet u. a. die Rechte "DSGVO" (20800021) und "Ansprechpartner löschen"
(20800023) als besonders geschützte, nicht frei vergebbare Administratorrechte.
Aussage: Das System soll DSGVO-relevante Löschfunktionen über ein eigenes, gesondert
berechtigtes Modul bereitstellen und deren Rechtevergabe stärker einschränken als
reguläre Funktionsrechte.
Ergebnis: Nur Benutzer mit explizit zugewiesenem DSGVO-Recht können
Ansprechpartnerdaten datenschutzkonform löschen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode
`GetAssignableAdminRightI3Ds` (Zeile 714-759), Einträge 20800021-20800024 - Begründung: Der
Code führt DSGVO-Rechte explizit in der Liste der besonders kontrollierten Admin-Rechte,
was eine bewusste Sonderbehandlung datenschutzrelevanter Berechtigungen belegt.
Prüfidee: Ein Benutzer ohne das Recht `ACCESS_DSGVO_MODULE` kann das DSGVO-Modul weder im
Menü öffnen noch per direktem Aufruf nutzen.
Tracelinks: StRS-013; SwRS-106
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - DSGVO-Konformität ist gesetzlich zwingend.
Status: belegt
```
---
```
ID: SyRS-015
Titel: Filialbezogene Einschränkung von Verwaltungsrechten
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: Ein Benutzer mit eingeschränktem Verwaltungsrecht agiert außerhalb seiner
eigenen Filiale.
Fakt: `AppRightsBL.SaveRightGroup`, `DeleteRightGroup` und `CopyRightGroup` prüfen bei
gesetztem Recht `MANAGE_RIGHTS_ONLY_OWN_BRANCH` explizit
`user.Employee.BranchI3D != appGroup.BranchI3D` und lehnen die Aktion sonst ab.
Aussage: Das System soll einem Benutzer mit dem Recht "nur eigene Filiale" jede
Verwaltungsaktion auf Rechtegruppen anderer Filialen serverseitig verweigern.
Ergebnis: Ein filialbeschränkter Administrator kann keine Rechtegruppe einer fremden
Filiale anlegen, ändern, kopieren oder löschen.
Belege:
- [PRIMÄR] AppRightsBL.cs, Methoden `SaveRightGroup` (Zeile 391-393), `DeleteRightGroup`
(Zeile 355-357), `CopyRightGroup` (Zeile 444-446) - Begründung: Alle drei Methoden
enthalten dieselbe Bedingungsprüfung gegen `BranchI3D` und geben bei Verstoß
`Result.AsError` zurück, bevor eine Datenänderung erfolgt.
Prüfidee: Ein Benutzer mit `MANAGE_RIGHTS_ONLY_OWN_BRANCH` erhält beim Versuch, eine Gruppe
einer anderen Filiale zu löschen, die Fehlermeldung "Sie haben nicht genügend
Rechte um die Gruppe einer anderen Filiale zu löschen.".
Tracelinks: StRS-014; SwRS-109, SwRS-113
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-016
Titel: Lizenzabhängige Freischaltung jeder Funktion vor Rechteprüfung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: System
Vorbedingung: Ein Modul soll im Client registriert werden.
Fakt: Jeder `ModuleRegistrationItem` in `ModuleRegistration.cs` kombiniert eine
Rechteprüfung (`Func<bool>` Rechte) mit einer unabhängigen Lizenzprüfung
(`Func<bool>` Feature/Lizenz); `DoRegisterCentronModules` filtert zusätzlich über
`CheckModuleFeatures()` und `CheckRights(allRights)`, bevor ein Modul überhaupt
registriert wird.
Aussage: Das System soll ein Modul nur dann registrieren, wenn sowohl die erforderliche
Lizenz als auch das erforderliche Benutzerrecht gleichzeitig erfüllt sind.
Ergebnis: Ein Benutzer mit allen erforderlichen Rechten, aber ohne die passende Lizenz,
sieht das Modul dennoch nicht.
Belege:
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Methode
`DoRegisterCentronModules` (Zeile 387-389):
`.Where(f => f.CheckModuleFeatures()).Where(f => f.CheckRights(allRights))` - Begründung:
Beide Prüfungen sind im Code als getrennte, beide notwendige Filterbedingungen
verkettet (UND-Verknüpfung).
Prüfidee: Wird für ein Modul nur die Lizenz, nicht aber das Recht entzogen (oder
umgekehrt), bleibt das Modul in beiden Fällen ausgeblendet.
Tracelinks: StRS-015; SwRS-115, SwRS-116, SwRS-117, SwRS-119, SwRS-120
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kombinierte Lizenz-/Rechteprüfung ist Kern des bestehenden
Lizenzmodells.
Status: belegt
```
---
```
ID: SyRS-017
Titel: Administrative Diagnose- und Wartungswerkzeuge im laufenden Betrieb
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: Systemadministrator
Vorbedingung: Ein Betriebsproblem (Performance, Verbindung, Datenqualität) tritt auf.
Fakt: `CentronInspectorAppModuleController` ist zusätzlich zur Rechteprüfung an
`CentronApplication.Instance.Connection.IsAdmin` gekoppelt (Zeile 733);
`SqlManagerAppModuleController` erfordert das Recht `Administration.SQL_MANAGER`
und ermöglicht direkten Datenbankzugriff.
Aussage: Das System soll Diagnose- und Wartungswerkzeuge mit direktem
Datenbank-/Systemzugriff ausschließlich Administratoren vorbehalten.
Ergebnis: Ein Nicht-Administrator kann über den SQL-Manager keine beliebigen SQL-Befehle
gegen die Produktivdatenbank ausführen.
Belege:
- [PRIMÄR] ModuleRegistration.cs Zeile 731-734 (`CentronInspectorAppModuleController`,
Bedingung `CentronApplication.Instance.Connection.IsAdmin`) - Begründung: Eine zusätzliche,
von der regulären Rechteprüfung unabhängige Admin-Prüfung im Code belegt eine bewusst
stärkere Zugriffsschwelle für dieses Diagnosewerkzeug.
Prüfidee: Ein angemeldeter Benutzer ohne Administratorstatus sieht den Menüpunkt
"c-entron Inspektor" nicht, selbst wenn er alle sonstigen Rechte besitzt.
Tracelinks: StRS-015; SwRS-118, SwRS-121..SwRS-126
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-018
Titel: Konfigurierbare Zusatzfelder ohne Schemaänderung im Code
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: System, Administrator
Vorbedingung: Für eine Entität soll ein zusätzliches, kundenspezifisches Feld erfasst werden.
Fakt: `Centron.Controls/CustomProperties` und
`CustomPropertiesConfigurationSettingsController` implementieren ein generisches
Zusatzfeld-Konzept unabhängig von konkreten Entitätsklassen.
Aussage: Das System soll Zusatzfelder generisch über Konfiguration hinzufügen können, ohne
dass für jedes neue Feld eine Datenbankschemaänderung oder Neukompilierung
erforderlich ist.
Ergebnis: Ein neu konfiguriertes Zusatzfeld ist unmittelbar nach dem Speichern der
Konfiguration in der Erfassungsmaske verfügbar.
Belege:
- [SEKUNDÄR] src/shared/Centron.Controls/CustomProperties - Begründung: Ein generisches,
entitätsunabhängiges Modul belegt ein konfigurationsbasiertes statt code-basiertes Konzept.
Prüfidee: Ein neu angelegtes Zusatzfeld für Kunden ist ohne Neustart der Anwendung in der
Kundenerfassungsmaske sichtbar.
Tracelinks: StRS-016; SwRS-127..SwRS-133
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-019
Titel: Massenänderung mit vorheriger Filterung als atomarer Vorgang
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: Performanz-Effizienz
Akteur: System, Administrator
Vorbedingung: Eine Änderung soll auf mehrere gefilterte Datensätze gleichzeitig angewendet
werden.
Fakt: `MassUpdatesAppModuleController` ist an das eigene Recht
`DataUpdater.ACCESS_DATAUPDATER_MODULE` gekoppelt; `Centron.BL/MassUpdate` bildet
ein von der Einzeldatensatzbearbeitung getrenntes Modul.
Aussage: Das System soll Massenänderungen als eigenständige, gesondert berechtigte
Funktion anbieten, die auf eine zuvor gefilterte Datensatzmenge angewendet wird.
Ergebnis: Ein Administrator kann eine Änderung gezielt auf eine gefilterte Teilmenge von
Datensätzen anwenden, ohne jeden Datensatz einzeln zu öffnen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/MassUpdate - Begründung: Ein eigenständiges Modul
getrennt von der regulären Einzelbearbeitung belegt eine bewusst batch-orientierte
Funktion.
Prüfidee: Eine Massenänderung mit einem definierten Filter ändert ausschließlich die vom
Filter erfassten Datensätze.
Tracelinks: StRS-017; SwRS-134, SwRS-135, SwRS-136
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-020
Titel: Konsistente Kennzahlenermittlung über Auswertungsmodule
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Funktionale Eignung
Akteur: System
Vorbedingung: Eine Kennzahl (Umsatz, Auslastung, MSP-Nutzung) wird für einen Zeitraum
berechnet.
Fakt: `Centron.BL/Statistics` und `Finances/ContractEvaluation2` referenzieren
dieselben Belegdaten wie das Fakturierungsmodul, jedoch über separate
Auswertungsklassen.
Aussage: Das System soll Kennzahlen aus denselben Belegdaten ableiten, die auch der
Fakturierung zugrunde liegen, damit Auswertung und Buchhaltung nicht
auseinanderlaufen.
Ergebnis: Der im Management-Info-Dashboard ausgewiesene Periodenumsatz stimmt mit der
Summe der im selben Zeitraum gebuchten Rechnungen überein.
Belege:
- [HYPOTHESE] Es wurde nicht verifiziert, ob `Centron.BL/Statistics` dieselbe Datengrundlage
(identische Belegtabellen/-filter) wie die Rechnungsstellung verwendet oder eine eigene,
potenziell abweichende Aggregation vornimmt - Begründung: Eine Cross-Validierung der
SQL-/LINQ-Abfragen beider Module gegeneinander wurde im Rahmen dieser Breitenanalyse nicht
durchgeführt; ohne diesen Abgleich lässt sich eine Datenkonsistenz nicht als Fakt belegen.
Prüfidee: Der für einen Testzeitraum im Analytics-Modul ausgewiesene Umsatz stimmt mit der
Summe der im selben Zeitraum verbuchten Rechnungen überein.
Tracelinks: StRS-018; SwRS-137..SwRS-142
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE
```
---
```
ID: SyRS-021
Titel: Rechtefreier persönlicher Grundarbeitsbereich für jeden angemeldeten Benutzer
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Ein Benutzer meldet sich erfolgreich an.
Fakt: `ModuleRegistration.cs` registriert Dashboard, Mein Tag, Telefonate und
To-do-Liste mit `() => Helper.NoRightCheck()` (Zeilen 775-792), unabhängig von
individuellen Benutzerrechten.
Aussage: Das System soll jedem erfolgreich angemeldeten Benutzer unabhängig von
individuellen Funktionsrechten Zugriff auf einen persönlichen Grundarbeitsbereich
gewähren.
Ergebnis: Auch ein Benutzer ohne jegliche Sonderrechte sieht nach der Anmeldung Dashboard,
Mein Tag, Telefonate und To-do-Liste.
Belege:
- [PRIMÄR] ModuleRegistration.cs Zeilen 775, 781, 786, 791 (`Helper.NoRightCheck()`) -
Begründung: Der Code verzichtet für diese vier Module explizit auf eine Rechteprüfung.
Prüfidee: Ein Testbenutzer ohne zugewiesene Gruppen sieht nach der Anmeldung dennoch die
vier genannten MyCentron-Module (sofern die zugehörige Lizenz vorhanden ist).
Tracelinks: StRS-019; SwRS-143..SwRS-146
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-022
Titel: Isolierte Kapselung fachlicher Nischenfunktionen
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: System
Vorbedingung: Eine Nischenfunktion wird genutzt.
Fakt: Module wie `VoucherManagement`, `VideoPortal`, `TradePool` bestehen jeweils aus
1-2 Klassen ohne erkennbare Abhängigkeiten zu den Kernbelegprozessen.
Aussage: Das System soll Nischenfunktionen als eigenständige, von der Kernbelegkette
entkoppelte Module implementieren, damit ihr Wegfall oder ihre Änderung den
Kernprozess nicht gefährdet.
Ergebnis: Eine Änderung an `VoucherManagement` hat keine Auswirkung auf die
Rechnungsstellung.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/VoucherManagement (1 Datei), TradePool (2 Dateien) -
Begründung: Der sehr geringe Umfang und die fehlenden Querverweise zu `Sales/Receipts` in
den Verzeichnisnamen belegen eine lose Kopplung.
Prüfidee: Die Kernbelegkette (Angebot bis Rechnung) lässt sich vollständig durchlaufen,
ohne dass eines der Nischenmodule aufgerufen wird.
Tracelinks: StRS-020; SwRS-147..SwRS-156
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall
Status: belegt
```
---
```
ID: SyRS-023
Titel: Austauschbare Anbindung externer Produktdatenquellen
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal: Interoperabilität
Akteur: System, externer Datenanbieter
Vorbedingung: Artikeldaten sollen von einer externen Quelle aktualisiert werden.
Fakt: `Centron.APIs.CopDataAccess`, `ITscopeDataAccess` und `IcecatDataAccess` liegen
als eigenständige Assemblies mit jeweils eigenem `Parser`-Unterordner vor.
Aussage: Das System soll pro externem Produktdatenanbieter eine eigene, unabhängig
wartbare Zugriffs- und Parser-Schicht bereitstellen.
Ergebnis: Der Ausfall oder eine Formatänderung eines Anbieters (z. B. Icecat) beeinträchtigt
den Datenabgleich mit den anderen Anbietern nicht.
Belege:
- [SEKUNDÄR] src/apis/Centron.APIs.{CopDataAccess,ITscopeDataAccess,IcecatDataAccess}/Parser
- Begründung: Getrennte Parser-Unterordner je Anbieter belegen eine bewusst entkoppelte
Implementierung pro Datenquelle.
Prüfidee: Ein simulierter Format-/Verbindungsfehler bei einem Anbieter führt nicht zum
Abbruch des Abgleichs mit den übrigen Anbietern.
Tracelinks: StRS-021; SwRS-157, SwRS-158
Konsolidierung: Kandidat: siehe StRS-021.
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-024
Titel: Web-Portal mit eigenständiger Authentifizierung für Endkunden
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: Kunde, System
Vorbedingung: Ein Kunde meldet sich am Web-Portal an.
Fakt: `src/nexus/CentronNexus` ist eine eigenständige Blazor-Server-Anwendung mit
eigenem `Configuration`-Bereich, getrennt vom internen WPF-Rechtesystem; der
Zugriff auf `Sichtrus`/`AppRight` ist an interne `AppUser` gebunden, während das
Portal auf `WebAccount`/`WebAccountsRights` zugreift (`AppRightsBL.
HasWebAccountRight`).
Aussage: Das System soll Endkunden über ein vom internen Mitarbeiter-Rechtesystem
getrenntes Web-Konto authentifizieren und ihnen ausschließlich auf ihre eigenen
Daten beschränkten Zugriff gewähren.
Ergebnis: Ein Kunde kann im Portal ausschließlich seine eigenen Angebote, Aufträge und
Tickets einsehen, keine Daten anderer Kunden.
Belege:
- [PRIMÄR] AppRightsBL.cs, Methode `HasWebAccountRight(WebAccount webAccount, int rightI3D)`
(Zeile 670-677) und zugehörige SQL-Abfrage gegen `WebAccountsRights` - Begründung: Ein
eigenständiger, von `AppUser`/`Sichtrus` getrennter Rechtemechanismus für Web-Konten belegt
eine bewusst getrennte Autorisierung für Kundenzugriffe.
- [HYPOTHESE] Ob jede Datenabfrage im CentronNexus-Portal serverseitig zusätzlich nach der
`CustomerI3D` des angemeldeten `WebAccount` filtert, wurde nicht für jeden Controller/jede
Razor-Komponente einzeln verifiziert - Begründung: Eine vollständige Prüfung aller
Datenzugriffe im Portal-Code auf Mandanten-/Kundentrennung ist im Rahmen dieser
Breitenanalyse nicht erfolgt.
Prüfidee: Ein authentifizierter Kunde kann über keine Portal-URL Daten eines anderen
Kunden abrufen, auch nicht durch Änderung einer ID im Anfrageparameter.
Tracelinks: StRS-022; SwRS-159..SwRS-166
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE
```
---
```
ID: SyRS-025
Titel: Versionierte REST-API mit domänenorientierter Struktur
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal: Übertragbarkeit
Akteur: Drittsystem, System
Vorbedingung: Ein Drittsystem ruft eine c-entron-Funktion über REST auf.
Fakt: `Centron.Controllers/Controllers/v1` ist nach Fachdomänen (Customers, Offers,
Orders, Receipts, Tickets, Contracts, ...) strukturiert; `Controllers/Unversioned`
existiert daneben für nicht versionierte Altbestände; `Controllers/v1/WebVersion`
prüft Versionskompatibilität.
Aussage: Das System soll neue REST-Funktionen unter einem versionierten Pfad (`v1`)
anbieten und die Versionskompatibilität von Client und Server explizit prüfen.
Ergebnis: Ein veralteter Client erhält beim Zugriff eine erkennbare
Versionsinkompatibilitäts-Rückmeldung statt eines unspezifischen Fehlers.
Belege:
- [SEKUNDÄR] src/webservice/Centron.Controllers/Controllers/v1, .../Unversioned,
.../v1/WebVersion - Begründung: Die parallele Existenz von versionierten und
unversionierten Controllern sowie ein eigener Versionskompatibilitäts-Endpunkt belegen ein
bewusstes, aber unvollständig durchgesetztes Versionierungskonzept.
Prüfidee: Ein Aufruf von `v1/WebVersion` mit einer veralteten Client-Version liefert eine
strukturierte Inkompatibilitätsmeldung.
Tracelinks: StRS-023; SwRS-167..SwRS-170
Konsolidierung: Kandidat: siehe StRS-023 (Legacy-REST vs. v1-Controller).
Übernahmewürdigkeit: übernehmen
Status: belegt
```
---
```
ID: SyRS-026
Titel: Einheitliches ILogic/BL/WS-Zugriffsmuster mit Result-Fehlerbehandlung
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: Entwicklungsteam, System
Vorbedingung: Eine Fachfunktion wird vom WPF-Client aufgerufen.
Fakt: `docs/getting-started/general-structure.md` verlangt für jedes Modul ein
`I{Modul}Logic`-Interface mit `BL{Modul}Logic`- (Datenbank) und
`WS{Modul}Logic`-Implementierung (Webservice), beide über `ClassContainer`
registriert und mit einheitlichem `Result<T>`-Rückgabetyp.
Aussage: Das System soll jede Fachfunktion über ein gemeinsames Interface anbieten, das
wahlweise per Datenbankdirektzugriff oder Webservice implementiert wird, und
Fehler einheitlich über den `Result<T>`-Typ zurückmelden statt über Exceptions.
Ergebnis: Der aufrufende ViewModel-Code unterscheidet sich nicht danach, ob im Hintergrund
ein Datenbankzugriff oder ein Webservice-Aufruf erfolgt.
Belege:
- [KONTEXT] docs/getting-started/general-structure.md, Abschnitt "Dual Implementation
Architecture", Zeilen 36-112 - Begründung: Die Dokumentation legt eine im gesamten Client
verbindliche Architekturregel mit Codebeispiel fest.
- [HYPOTHESE] Ob diese Regel für alle ~178 im Inventar erfassten Module tatsächlich lückenlos
umgesetzt ist oder ob - wie die Dokumentation selbst einräumt ("tons of places where this
general structure does not apply") - Ausnahmen bestehen, wurde nicht für jedes Modul
einzeln verifiziert - Begründung: Eine Verifikation aller Module auf vollständige
ILogic/BL/WS-Triade würde eine Einzelprüfung jedes der 178 Module erfordern, die im Rahmen
der geforderten Breitenabdeckung nicht in dieser Tiefe je Modul geleistet werden konnte.
Prüfidee: Für ein neu zu migrierendes Modul lässt sich anhand des Namensschemas
`I*Logic`/`BL*Logic`/`WS*Logic` eindeutig feststellen, ob beide
Implementierungen vorhanden sind.
Tracelinks: StRS-024; SwRS-171..SwRS-175
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE
```
---
```
ID: SyRS-027
Titel: Parallele Bereitstellung als Windows-Installation und Container
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Übertragbarkeit
Akteur: Betrieb
Vorbedingung: Eine neue Version soll ausgeliefert werden.
Fakt: `deployment/WixSharpInstaller` erzeugt MSI-Pakete; `docker/c-entron-api`,
`docker/c-entron-webservice` und `docker/compose` definieren containerisierte
Varianten derselben Serverkomponenten.
Aussage: Das System soll dieselben Serverkomponenten sowohl als Windows-Installationspaket
als auch als Docker-Image bereitstellen können.
Ergebnis: Webservice und API lassen sich wahlweise klassisch installiert oder als
Container betrieben werden, ohne Codeänderung.
Belege:
- [KONTEXT] docker/compose, deployment/WixSharpInstaller - Begründung: Beide
Bereitstellungswege sind im Repository parallel und produktiv gepflegt vorhanden.
Prüfidee: Ein aus `docker/compose` gestarteter Webservice-Container beantwortet dieselben
API-Aufrufe wie eine klassisch installierte Instanz.
Tracelinks: StRS-025; SwRS-176..SwRS-178
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
## Vertiefung nach Risiko (Schritt 0c)
```
ID: SyRS-028
Titel: Serverseitige Durchsetzung sicherheitskritischer Operationen unabhängig von der aufrufenden Oberfläche
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Vertraulichkeit
Akteur: System
Vorbedingung: Eine sicherheitskritische Operation (Rechteprüfung, Master-Schlüssel-Zugriff,
Beleg-/Kundendatenabfrage) wird über einen beliebigen Client (WPF, REST-API,
Web-Portal) ausgelöst.
Fakt: Für den WPF-Client ist die Rechteprüfung nachweislich zentral und lückenlos vor
jeder Modulregistrierung verankert (`ModuleRegistration.cs`, siehe SyRS-013).
Für dieselben Fachdaten zeigt die parallele REST-Schicht (`Controllers/v1`) und
die Master-Schlüssel-Verwaltung (`CentronConfigurationDbBL.
SetHotlineMasterKey`) hingegen Stellen, an denen eine vergleichbare Prüfung im
Code nicht sichtbar ist (siehe SwRS-168, SwRS-179).
Aussage: Das System soll sicherheitskritische Operationen unabhängig vom aufrufenden
Client (WPF, REST-API, Web-Portal) serverseitig einheitlich gegen dieselben
Rechte- und Berechtigungsregeln prüfen, statt sich auf die UI-Schicht eines
einzelnen Clients zu verlassen.
Ergebnis: Ein Zugriff auf dieselbe Fachfunktion liefert unabhängig davon, ob er über den
WPF-Client, die REST-API oder ein anderes Frontend erfolgt, dasselbe
Berechtigungsergebnis für denselben Benutzer.
Belege:
- [PRIMÄR] Gegenüberstellung ModuleRegistration.cs (lückenlose Rechteprüfung, SyRS-013)
versus Controllers/v1/{Customers,Offers,Contracts,Orders} (uneinheitliche bzw. fehlende
Rechteprüfung, SwRS-168) - Begründung: Der direkte Vergleich zweier Zugriffswege auf
dieselben Fachdaten belegt die Inkonsistenz auf Systemebene.
Prüfidee: Für denselben Testbenutzer mit identischem Rechteprofil liefert ein Zugriff
über den WPF-Client und ein Zugriff über die entsprechende v1-API dieselbe
Berechtigungsentscheidung.
Tracelinks: StRS-013; SwRS-168, SwRS-179, SwRS-184
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - einheitliche serverseitige Durchsetzung ist für die
geplante Web-/SaaS-Architektur mit mehreren gleichrangigen Clients zwingend.
Status: HYPOTHESE
```
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/Traceability.md
+325
View File
@@ -0,0 +1,325 @@
# Traceability — c-entron ERP-Suite
Forward-/Backward-Traceability zwischen StRS, SyRS und SwRS. Jede SwRS-Zeile referenziert ihre
SyRS- und StRS-Elternanforderung; der Artefaktbeleg verweist auf den in `Analysebericht.md`
(Modulinventar) und in der jeweiligen SwRS-Anforderung dokumentierten Pfad. Ergänzende
Konsolidierungskandidaten sind mit „→ Kandidat" gekennzeichnet und in den jeweiligen
SwRS-Anforderungen im Detail begründet.
## Bereich A — Vertrieb & Kundenbeziehung
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-001 | SyRS-001 | SwRS-001 | Sales/Customers/Addresses/AddressBL.cs |
| StRS-001 | SyRS-001 | SwRS-002 | Sales/Customers/Addresses/AddressBL.cs |
| StRS-001 | SyRS-001 | SwRS-003 | Sales/Customers/CRM/CustomerActivityBL.cs |
| StRS-001 | SyRS-001 | SwRS-004 | Sales/Customers/CrmProjects/CrmProjectBL.cs |
| StRS-001 | SyRS-001 | SwRS-005 | Sales/Customers/CustomerDetails/CustomerAncestryBL.cs |
| StRS-001 | SyRS-001 | SwRS-006 | Sales/Customers/TextBlock/BusinessTextBlockBL.cs |
| StRS-001 | SyRS-001 | SwRS-007 | Mailings/MailingDataBL.cs |
| StRS-001 | SyRS-001 | SwRS-008 | Accounts/Survey/SurveyProcessBL.cs |
| StRS-001 | SyRS-001 | SwRS-009 | Sales/CustomerAssets/AssetLockBL.cs, AssetBL.cs |
| StRS-001 | SyRS-001 | SwRS-010 | WPF Finances/MasterDataLists/OverView/MasterDataListOverviewAppModuleController.cs → Kandidat (SwRS-056) |
## Bereich B — Auftragsabwicklung / Belegwesen
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-002 | SyRS-002 | SwRS-011 | Sales/Receipts/Offers/ReceiptOfferBL.cs |
| StRS-002 | SyRS-002 | SwRS-012 | Sales/Receipts/Orders/ReceiptOrderBL.cs, OrderItemOpenTrans.cs |
| StRS-002 | SyRS-002 | SwRS-013 | Sales/Receipts/DeliveryLists/DeliveryListSpecificLogic.cs |
| StRS-002 | SyRS-002 | SwRS-014 | Sales/Receipts/PickUps/PickUpSettingsBL.cs → Kandidat (SwRS-013) |
| StRS-002 | SyRS-002 | SwRS-015 | Sales/Receipts/DownPayment/DownPaymentBL.cs |
| StRS-002 | SyRS-002 | SwRS-016 | Sales/Receipts/CreditVouchers; Invoices/Dunning/DunningBL.cs |
| StRS-002 | SyRS-002 | SwRS-017 | Sales/Receipts/DownPayment/DownPaymentBL.cs |
| StRS-002 | SyRS-002 | SwRS-018 | Sales/Receipts/Invoices/Dunning/DunningBL.cs, DunningRunBL.cs |
| StRS-002 | SyRS-002 | SwRS-019 | Sales/Receipts/Invoices/Opos/OposBL.cs |
| StRS-003 | SyRS-003 | SwRS-020 | Sales/Receipts/DataAndResults/CreateNewVersion → Kandidat (SwRS-009) |
| StRS-003 | SyRS-003 | SwRS-021 | Sales/Receipts/ReceiptTemplateBL.cs |
| StRS-003 | SyRS-003 | SwRS-022 | Sales/Receipts/ReceiptCartReleaseSystemBL.cs |
| StRS-003 | SyRS-003 | SwRS-023 | Sales/Receipts/ArticleSearch/CopApiBaseExternalArticleSearchProvider.cs |
| StRS-003 | SyRS-003 | SwRS-024 | Sales/Receipts/Classifications/ReceiptItemServiceArticleClassificationBL.cs |
| StRS-002 | SyRS-002 | SwRS-025 | WPF ServiceLeasingAppModuleController |
| StRS-003 | SyRS-003 | SwRS-026 | Sales/Receipts/ContractLists/ReceiptContractBL.cs → Kandidat (SwRS-063) |
| StRS-002 | SyRS-002 | SwRS-027 | Sales/Receipts/Switzerland/SwitzerlandSettingsBL.cs |
| StRS-003 | SyRS-003 | SwRS-028 | Sales/Receipts/ReceiptLogBL.cs |
| StRS-003 | SyRS-003 | SwRS-029 | Sales/Receipts/ReceiptPriceHelperBL.cs |
| StRS-003 | SyRS-003 | SwRS-030 | Sales/Receipts/ReceiptProvisionSchemaBL.cs |
## Bereich C — Einkauf / Lieferantenprozesse
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-004 | SyRS-004 | SwRS-031 | Sales/Receipts/SupplierOrders/SupplierOrderSpecificLogic.cs |
| StRS-004 | SyRS-004 | SwRS-032 | Sales/Receipts/SupplierInvoices/SupplierInvoicesBL.cs |
| StRS-004 | SyRS-004 | SwRS-033 | Sales/Receipts/SupplierCreditVouchers/SupplierCreditVoucherSpecificLogic.cs |
| StRS-004 | SyRS-004 | SwRS-034 | Sales/Receipts/SupplierDeliveryLists/SupplierDeliveryListBL.cs |
| StRS-004 | SyRS-004 | SwRS-035 | Sales/Receipts/SupplierReceiptDocuments/.../FixedLocationPdfScanStrategy.cs |
| StRS-004 | SyRS-004 | SwRS-036 | WPF OrderSuggestionListAppModuleController (Obsolete) |
| StRS-004 | SyRS-004 | SwRS-037 | WPF SupplierOrderPerBranchAppModuleController |
| StRS-004 | SyRS-004 | SwRS-038 | Centron.BL/EDI/EDIDispatcherBL.cs |
## Bereich D — EDI-/Formatanbindungen
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-005 | SyRS-005 | SwRS-039 | Centron.Gateway/EDI_Alltron, EDI_Also, EDI_AlsoCH, EDI_Herweck, EDI_Komsa → Kandidat |
| StRS-005 | SyRS-005 | SwRS-040 | Centron.Gateway/EDI_EGIS; APIs.EgisDataAccess/Parser |
| StRS-005 | SyRS-005 | SwRS-041 | Centron.Gateway/OpenTrans, OpenTrans1_0 → Kandidat |
| StRS-005 | SyRS-005 | SwRS-042 | Centron.Gateway/ZUGFeRD21_Extended/ZUGFeRD_EXTENDED.cs |
| StRS-005 | SyRS-005 | SwRS-043 | Centron.Api.EbInterface/EbInterfaceLogic.cs → Kandidat |
| StRS-005 | SyRS-005 | SwRS-044 | Centron.Gateway/DataExchange/BookKeeping/BookKeepingFileExport.cs |
| StRS-005 | SyRS-005 | SwRS-045 | WPF DatevOnlineAppModuleController → Kandidat (SwRS-044) |
| StRS-005 | SyRS-005 | SwRS-046 | Centron.Gateway/Portal/WebServiceAccess.cs |
## Bereich E — Zahlungsverkehr & Banking
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-006 | SyRS-006 | SwRS-047 | Finances/OnlineBanking/OnlineBankingFinApiBL.cs |
| StRS-006 | SyRS-006 | SwRS-048 | WPF PaymentTransactionAppModuleController |
| StRS-006 | SyRS-006 | SwRS-049 | Finances/Payments/PaymentsBL.cs |
| StRS-006 | SyRS-006 | SwRS-050 | Finances/IncomingPayments/IncomingPaymentBL.cs |
| StRS-006 | SyRS-006 | SwRS-051 | Sales/CashBooks/CashBookBL.cs |
## Bereich F — Abrechnung / Verträge
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-007 | SyRS-007 | SwRS-052 | Finances/FlatrateBilling; WPF FlatRateProjectAppModuleController |
| StRS-007 | SyRS-007 | SwRS-053 | Sales/Receipts/ContractLists/ReceiptContractBL.cs |
| StRS-007 | SyRS-007 | SwRS-054 | Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs |
| StRS-007 | SyRS-007 | SwRS-055 | Sales/Receipts/ContractLists/ReceiptContractBL.cs |
| StRS-007 | SyRS-007 | SwRS-056 | Sales/CustomerAssets/Contracts/ClickContracts/DeviceClickCounterBL.cs → Kandidat (SwRS-010) |
| StRS-007 | SyRS-007 | SwRS-057 | Sales/Receipts/ContractLists/ReceiptContractBL.cs |
| StRS-007 | SyRS-007 | SwRS-058 | WPF Finances/Contracts/Settings/ContractArticleSettings/ContractArticleSettingsController.cs |
| StRS-007 | SyRS-007 | SwRS-059 | Centron.Entities/.../Contracts/Settings/ContractType.cs |
| StRS-008 | SyRS-008 | SwRS-060 | Statistics/ContractStatistics/ContractEvaluationBL.cs → Kandidat (SwRS-026) |
| StRS-008 | SyRS-008 | SwRS-061 | WPF Sales/SpecialArticleImport, SpecialArticleToContractImport → Kandidat |
| StRS-008 | SyRS-008 | SwRS-062 | Centron.Interfaces/Sales/Receipts/ReceiptProvisionEvaluationFilter.cs |
| StRS-008 | SyRS-008 | SwRS-063 | WPF ProvisionSchemaManagementAppModuleController |
| StRS-008 | SyRS-008 | SwRS-064 | Centron.Entities/.../ReceiptProvisionSchemaCustomerAssignment.cs |
| StRS-008 | SyRS-008 | SwRS-065 | Warehousing/CostCenterBL.cs |
| StRS-008 | SyRS-008 | SwRS-066 | Administration/BookKeepingAccountSystems; WPF AccountSystemsAppModuleController |
| StRS-008 | SyRS-008 | SwRS-067 | Warehousing/TaxBL.cs |
## Bereich G — Lager, Artikel & Logistik
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-009 | SyRS-009 | SwRS-068 | Warehousing/ArticleBL.cs |
| StRS-009 | SyRS-009 | SwRS-069 | Warehousing/ArticleVolumePricesBL.cs |
| StRS-009 | SyRS-009 | SwRS-070 | Warehousing/ActionPriceBL.cs |
| StRS-009 | SyRS-009 | SwRS-071 | Warehousing/BarcodeBL.cs |
| StRS-009 | SyRS-009 | SwRS-072 | WPF MaterialGroupAppModuleController |
| StRS-009 | SyRS-009 | SwRS-073 | WPF Warehousing/ArticleImport/ArticleImportAppModuleController.cs |
| StRS-009 | SyRS-009 | SwRS-074 | Logistics/Warehousing/StockBL.cs |
| StRS-009 | SyRS-009 | SwRS-075 | Warehousing/InventoryManagement/InventoryBL.cs |
| StRS-009 | SyRS-009 | SwRS-076 | Warehousing/Commissions/OrderCommissionBL.cs |
| StRS-009 | SyRS-009 | SwRS-077 | WPF Logistic/ShippingMethodSettings/ShippingMethodSettingsController.cs |
| StRS-009 | SyRS-009 | SwRS-078 | apis/Centron.Api.Gls/Classes → Kandidat (SwRS-079) |
| StRS-009 | SyRS-009 | SwRS-079 | apis/Centron.Api.Shipcloud/Classes → Kandidat (SwRS-078) |
## Bereich H — Produktion
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-010 | SyRS-010 | SwRS-080 | Sales/DocumentationWizardArea/MachineBL.cs |
| StRS-010 | SyRS-010 | SwRS-081 | Production/ProductionOrderBL.cs; nexus/ProductionOrderManagement/Model/WorkStepTemplateModel.cs |
## Bereich I — Helpdesk / Ticket / Projektmanagement
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-011 | SyRS-011 | SwRS-082 | WPF TicketListAppModuleController |
| StRS-011 | SyRS-011 | SwRS-083 | CheckListArea/CentronChecklistBL.cs |
| StRS-011 | SyRS-011 | SwRS-084 | TaskManager/TaskManagementTaskBL.cs, ActionHandler/ITaskManagementActionHandler.cs |
| StRS-011 | SyRS-011 | SwRS-085 | TicketProjects/TicketProjectBL.cs |
| StRS-011 | SyRS-011 | SwRS-086 | CustomerArea/RmaBL.cs |
| StRS-011 | SyRS-011 | SwRS-087 | ExpectedEvents/ExpectedEventsBL.cs |
| StRS-011 | SyRS-011 | SwRS-088 | WPF ExpectedEventsReportingAppModuleController |
| StRS-011 | SyRS-011 | SwRS-089 | ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs |
| StRS-011 | SyRS-011 | SwRS-090 | ReportEngine/CustomPdfGenerators/CustomZugferdPdfGenerator.cs |
| StRS-011 | SyRS-011 | SwRS-091 | WPF ProjectManagementAppModuleController |
## Bereich J — Kalender & Kommunikation
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-012 | SyRS-012 | SwRS-092 | Calendar/CalendarBL.cs |
| StRS-012 | SyRS-012 | SwRS-093 | AppointmentRequests/AppointmentRequestBL.cs |
| StRS-012 | SyRS-012 | SwRS-094 | Tapi/PhoneCallBL.cs |
| StRS-012 | SyRS-012 | SwRS-095 | WPF MailTemplatesAppModuleController |
| StRS-012 | SyRS-012 | SwRS-096 | Mail/Blacklist/DomainBlacklistBL.cs |
| StRS-012 | SyRS-012 | SwRS-097 | Chats/ChatBL.cs |
| StRS-012 | SyRS-012 | SwRS-098 | SocialMedia/SocialNetworks/{SocialNetworkBL.cs,PersonSocialNetworkBL.cs} |
| StRS-012 | SyRS-012 | SwRS-099 | NexusNotifications/NotificationsHubHelper.cs |
## Bereich K — Administration: Rechte, Sicherheit, Zugriff (Risikobereich)
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-013 | SyRS-013 | SwRS-100 | Administration/Rights/AppRightsBL.cs |
| StRS-013 | SyRS-013 | SwRS-101 | Administration/Logins/Auth/AuthenticatorFactory.cs |
| StRS-013 | SyRS-013 | SwRS-102 | Administration/Logins/TwoFactor/TwoFactorAuthBL.cs |
| StRS-013 | SyRS-013 | SwRS-103 | Administration/AccessTokens/AccessTokenBL.cs |
| StRS-013 | SyRS-013 | SwRS-104 | PasswordManager/PasswordManagerBL.cs |
| StRS-013 | SyRS-013 | SwRS-105 | WPF ModuleRegistration.cs, Region "Passwort Manager (obsolate)" → Kandidat (SwRS-104) |
| StRS-013 | SyRS-014 | SwRS-106 | Administration/DataSecurity/DataSecurityBL.cs |
| StRS-013 | SyRS-013 | SwRS-107 | Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs |
| StRS-013 | SyRS-013 | SwRS-108 | Security/PdfSigningBL.cs |
## Bereich L — Administration: Stammdaten, Mandanten, Firmenverwaltung
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-014 | SyRS-015 | SwRS-109 | Administration/Mandatory/MandatoryBL.cs |
| StRS-014 | SyRS-015 | SwRS-110 | Administration/CompanyInformations/CompanyBL.cs |
| StRS-014 | SyRS-015 | SwRS-111 | CountryArea/CountryBL.cs |
| StRS-014 | SyRS-015 | SwRS-112 | Administration/Employees/EmployeeDepartment*.cs |
| StRS-014 | SyRS-015 | SwRS-113 | Administration/Masterdata/AssetConditionBL.cs → Kandidat (SwRS-114) |
| StRS-014 | SyRS-015 | SwRS-114 | WPF ReceiptConditionManagementAppModuleController → Kandidat (SwRS-113) |
## Bereich M — Administration: Systembetrieb & Technik
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-015 | SyRS-016 | SwRS-115 | Administration/Settings/AppSettingsBL.cs |
| StRS-015 | SyRS-016 | SwRS-116 | Administration/WebServiceConfiguration/WebServiceConfigSerializer.cs |
| StRS-015 | SyRS-016 | SwRS-117 | Administration/Connections/ConnectionFileItem.cs |
| StRS-015 | SyRS-017 | SwRS-118 | Administration/SQLManagement/SQLManagementBL.cs |
| StRS-015 | SyRS-016 | SwRS-119 | Administration/CentronConfigDb/MasterPasswordConfigurationDatabaseStorage.cs |
| StRS-015 | SyRS-016 | SwRS-120 | Administration/Licensing/LicenseManager.cs |
| StRS-015 | SyRS-017 | SwRS-121 | Administration/BackgroundServices/BackgroundServiceBL.cs |
| StRS-015 | SyRS-017 | SwRS-122 | Administration/NetworkDiagnostics/NetworkDiagnosticsBL.cs |
| StRS-015 | SyRS-017 | SwRS-123 | Administration/Profiling/ProfilerBL.cs; PerformanceTests/PerformanceTestBL.cs |
| StRS-015 | SyRS-017 | SwRS-124 | WPF CentronInspectorAppModuleController |
| StRS-015 | SyRS-017 | SwRS-125 | Telemetry/TelemetryBL.cs |
| StRS-015 | SyRS-017 | SwRS-126 | IndexSearch/GermanAnalyzer.cs |
## Bereich N — Administration: Anpassung & Vorlagen
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-016 | SyRS-018 | SwRS-127 | Customizations/CustomTables/CustomTableBL.cs → Kandidat (SwRS-130) |
| StRS-016 | SyRS-018 | SwRS-128 | Administration/Themes/ThemeBL.cs |
| StRS-016 | SyRS-018 | SwRS-129 | TextModuleArea/TextModuleBL.cs → Kandidat (SwRS-006) |
| StRS-016 | SyRS-018 | SwRS-130 | Administration/Customization/ModuleCustomPropertyBL.cs → Kandidat (SwRS-127) |
| StRS-016 | SyRS-018 | SwRS-131 | ExternalToolsBL/ExternalToolBL.cs |
| StRS-016 | SyRS-018 | SwRS-132 | Reporting/ReportsBL.cs |
| StRS-016 | SyRS-018 | SwRS-133 | shared/Centron.Controls/ExcelExport |
## Bereich O — Automatisierung & Massendaten
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-017 | SyRS-019 | SwRS-134 | MassUpdate/MassUpdateBL.cs |
| StRS-017 | SyRS-019 | SwRS-135 | Administration/Scripts/ScriptEngineBL.cs |
| StRS-017 | SyRS-019 | SwRS-136 | Processes/ProcessBL.cs |
## Bereich P — Controlling & Analytics
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-018 | SyRS-020 | SwRS-137 | Statistics/Accounts/RevenueStatisticBL.cs |
| StRS-018 | SyRS-020 | SwRS-138 | shared/Centron.Controls/EmployeeAnalytics/EmployeeAnalyticsTreeItem.cs |
| StRS-018 | SyRS-020 | SwRS-139 | Statistics/Sales/ManagementInfo/ManagementInfoBL.cs |
| StRS-018 | SyRS-020 | SwRS-140 | Statistics/Administration/Employees/EmployeeUtilizationBL.cs |
| StRS-018 | SyRS-020 | SwRS-141 | Centron.Gateway/MspCollector/{Octopus,Wortmann} → Kandidat |
| StRS-018 | SyRS-020 | SwRS-142 | Statistics/MspCollectors/MspEvaluationReplacementBL.cs |
## Bereich Q — MyCentron / Persönlicher Arbeitsbereich
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-019 | SyRS-021 | SwRS-143 | WPF CentronDashboardAppModuleController |
| StRS-019 | SyRS-021 | SwRS-144 | MyDay/MyDayBL.cs |
| StRS-019 | SyRS-021 | SwRS-145 | ToDoArea/ToDoBL.cs |
| StRS-019 | SyRS-021 | SwRS-146 | ArtificialIntelligence/ApiClientFactory.cs |
## Bereich R — Sonstige Fachmodule
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-020 | SyRS-022 | SwRS-147 | VoucherManagement/VoucherManagementBL.cs |
| StRS-020 | SyRS-022 | SwRS-148 | VideoPortal/VideoPortalAssignmentBL.cs |
| StRS-020 | SyRS-022 | SwRS-149 | TradePool/TradePoolBL.cs → Kandidat (SwRS-157) |
| StRS-020 | SyRS-022 | SwRS-150 | SelfCare/SelfCareBL.cs |
| StRS-020 | SyRS-022 | SwRS-151 | WebLinks/WebLinkBL.cs |
| StRS-020 | SyRS-022 | SwRS-152 | Tags/TagsBL.cs |
| StRS-020 | SyRS-022 | SwRS-153 | ObjectExternalReferences/ObjectExternalReferenceBL.cs |
| StRS-020 | SyRS-022 | SwRS-154 | WPF ModuleRegistration.cs (auskommentiert, TravelExpense) |
| StRS-020 | SyRS-022 | SwRS-155 | ItPlanner/ChecklistVirtualObjectCategoryBL.cs → Kandidat (SwRS-083) |
| StRS-020 | SyRS-022 | SwRS-156 | Time/TimingSettingsBL.cs |
## Bereich S — Externe Produktdaten-Integrationen
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-021 | SyRS-023 | SwRS-157 | apis/Centron.APIs.ITscopeDataAccess/Parser/ITscopeApiKeyQuotaParser.cs |
| StRS-021 | SyRS-023 | SwRS-158 | Centron.Api.docuFORM/DocuFormRestApiClient.cs → Kandidat (SwRS-056) |
## Bereich T — Web-Portal (CentronNexus) & mobile Anbindung
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-022 | SyRS-024 | SwRS-159 | nexus/CentronNexus/Configuration |
| StRS-022 | SyRS-024 | SwRS-160 | nexus/CentronNexus/WebOffer/Models/WebOfferViewModel.cs |
| StRS-022 | SyRS-024 | SwRS-161 | nexus/CentronNexus/WebCart/Helpers/CurrentCartService.cs |
| StRS-022 | SyRS-024 | SwRS-162 | nexus/CentronNexus/ServiceBoard/CachedTicketList/Model/ConditionalFormattingRule.cs |
| StRS-022 | SyRS-024 | SwRS-163 | nexus/CentronNexus/Office/Models/SignatureType.cs |
| StRS-022 | SyRS-024 | SwRS-164 | nexus/CentronNexus/Office/Controllers/PdfController.cs |
| StRS-022 | SyRS-024 | SwRS-165 | nexus/CentronNexus.OutlookAddIn/Model/DocumentDragAndDropContent.cs |
| StRS-022 | SyRS-024 | SwRS-166 | backend/Centron.BL/Mobile/MobileBL.cs |
## Bereich U — Web-API- und Servicearchitektur
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-023 | SyRS-025 | SwRS-167 | webservice/Centron.WebServices.Core/Entities → Kandidat (SwRS-168) |
| StRS-023 | SyRS-025, SyRS-013 | SwRS-168 | webservice/Centron.Controllers/Controllers/v1/{Customers,Offers,Contracts,Orders} |
| StRS-023 | SyRS-025 | SwRS-169 | webservice/c-entron.misc.ConnectionManager/App.xaml.cs |
| StRS-023 | SyRS-025 | SwRS-170 | webservice/Centron.Controllers/Controllers/v1/WebVersion/WebServiceVersionController.cs |
## Bereich V — Datenzugriff & technische Basis
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-024 | SyRS-026 | SwRS-171 | backend/Centron.Entities/Entities (1.179 Dateien) |
| StRS-024 | SyRS-026 | SwRS-172 | backend/Centron.DAO/Mappings |
| StRS-024 | SyRS-026 | SwRS-173 | docs/getting-started/general-structure.md |
| StRS-024 | SyRS-026 | SwRS-174 | centron/Centron.WPF.UI/Modules/ModuleRegistration.cs |
| StRS-024 | SyRS-026 | SwRS-175 | shared/Centron.Controls/{CustomProperties,TaskManagement,EmployeeAnalytics} |
## Bereich W — Build, Deployment, Betrieb
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-025 | SyRS-027 | SwRS-176 | deployment/WixSharpInstaller/Program.cs |
| StRS-025 | SyRS-027 | SwRS-177 | docker/compose/compose.yaml |
| StRS-025 | SyRS-027 | SwRS-178 | .github/workflows; docker/c-entron-regression-tests-pipeline |
## Risikovertiefung (Schritt 0c) — zusätzliche Anforderungen
| StRS | SyRS | SwRS | Artefaktbeleg |
|---|---|---|---|
| StRS-013 | SyRS-028 | SwRS-179 | Administration/CentronConfigDb/CentronConfigurationDbBL.cs (SetHotlineMasterKey) |
| StRS-013 | SyRS-013 | SwRS-180 | Administration/AccessTokens/AccessTokenBL.cs (GenerateSecureToken) |
| StRS-013 | SyRS-013 | SwRS-181 | Administration/Logins/TwoFactor/RadiusClient.cs |
| StRS-013 | SyRS-014 | SwRS-182 | Administration/DataSecurity/DataSecurityBL.cs (GetDataSecurityCleanUpStats) |
| StRS-013 | SyRS-013 | SwRS-183 | Administration/Rights/AppRightsBL.cs (GetAssignableAdminRightI3Ds) |
| StRS-014 | SyRS-028, SyRS-015 | SwRS-184 | Administration/Mandatory/MandatoryBL.cs (NumberGroup) |
## Zusammenfassung
- **StRS-Anforderungen:** 25 (StRS-001 … StRS-025)
- **SyRS-Anforderungen:** 28 (SyRS-001 … SyRS-027, SyRS-028 aus der Risikovertiefung)
- **SwRS-Anforderungen:** 184 (SwRS-001 … SwRS-178 Mindestabdeckung, SwRS-179 … SwRS-184
Risikovertiefung)
- **Gesamt:** 237 Anforderungen
- Jede SwRS referenziert genau eine SyRS (SwRS-168 referenziert zusätzlich SyRS-013 als
Querverweis auf die allgemeine Rechteprüfungsregel; SwRS-184 referenziert zusätzlich
SyRS-015); jede SyRS referenziert genau eine StRS (SyRS-013/014 referenzieren beide
StRS-013).
- Jedes der 178 im Modulinventar (`Analysebericht.md`) geführten Module ist über die laufende
Nummer identisch zu seiner SwRS-ID (Mxxx ↔ SwRS-xxx) eindeutig referenziert.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/cls_clean.txt
+184
View File
@@ -0,0 +1,184 @@
g1 PRIMAR 1 0 0 0
g2 PRIMAR 1 0 0 0
g3 NOPRIMAR 0 1 0 0
g4 NOPRIMAR 0 1 0 0
g5 NOPRIMAR 0 1 0 0
g6 NOPRIMAR 0 1 0 0
g7 NOPRIMAR 0 1 0 0
g8 NOPRIMAR 0 1 1 0
g9 PRIMAR 1 1 0 0
g10 NOPRIMAR 0 0 1 0
g11 NOPRIMAR 0 1 0 0
g12 NOPRIMAR 0 1 0 0
g13 NOPRIMAR 0 1 0 0
g14 NOPRIMAR 0 1 0 0
g15 PRIMAR 1 0 0 0
g16 PRIMAR 1 0 0 0
g17 PRIMAR 1 0 0 0
g18 PRIMAR 2 0 0 0
g19 PRIMAR 1 0 0 0
g20 NOPRIMAR 0 1 0 0
g21 NOPRIMAR 0 1 0 0
g22 PRIMAR 1 0 0 0
g23 NOPRIMAR 0 1 0 0
g24 NOPRIMAR 0 1 0 0
g25 PRIMAR 1 0 0 0
g26 NOPRIMAR 0 1 0 0
g27 NOPRIMAR 0 1 0 0
g28 NOPRIMAR 0 1 0 0
g29 NOPRIMAR 0 1 0 0
g30 NOPRIMAR 0 1 0 0
g31 NOPRIMAR 0 1 0 0
g32 NOPRIMAR 0 1 0 0
g33 NOPRIMAR 0 1 0 0
g34 NOPRIMAR 0 1 0 0
g35 PRIMAR 1 0 0 0
g36 PRIMAR 1 0 0 0
g37 NOPRIMAR 0 0 1 0
g38 PRIMAR 1 0 0 0
g39 NOPRIMAR 0 1 0 0
g40 NOPRIMAR 0 1 0 0
g41 NOPRIMAR 0 1 0 0
g42 NOPRIMAR 0 1 1 0
g43 NOPRIMAR 0 1 0 0
g44 PRIMAR 1 0 0 0
g45 NOPRIMAR 0 0 1 0
g46 NOPRIMAR 0 1 0 0
g47 PRIMAR 1 0 0 0
g48 PRIMAR 1 0 0 0
g49 PRIMAR 1 0 0 0
g50 NOPRIMAR 0 1 0 0
g51 NOPRIMAR 0 1 0 0
g52 NOPRIMAR 0 1 0 1
g53 PRIMAR 1 0 0 0
g54 PRIMAR 1 0 0 0
g55 PRIMAR 1 0 0 0
g56 PRIMAR 1 0 0 0
g57 NOPRIMAR 0 1 0 0
g58 NOPRIMAR 0 0 1 0
g59 NOPRIMAR 0 1 0 0
g60 NOPRIMAR 0 1 0 0
g61 NOPRIMAR 0 1 0 0
g62 NOPRIMAR 0 1 0 0
g63 PRIMAR 1 0 0 0
g64 NOPRIMAR 0 1 0 0
g65 NOPRIMAR 0 1 0 0
g66 NOPRIMAR 0 0 1 0
g67 PRIMAR 1 0 0 0
g68 PRIMAR 1 0 0 0
g69 PRIMAR 1 0 0 0
g70 NOPRIMAR 0 1 0 0
g71 PRIMAR 1 0 1 0
g72 NOPRIMAR 0 0 1 0
g73 NOPRIMAR 0 0 1 0
g74 PRIMAR 1 0 0 0
g75 PRIMAR 1 0 0 0
g76 NOPRIMAR 0 1 0 0
g77 NOPRIMAR 0 0 1 0
g78 NOPRIMAR 0 1 0 0
g79 NOPRIMAR 0 1 0 0
g80 PRIMAR 1 0 0 0
g81 PRIMAR 1 1 0 0
g82 NOPRIMAR 0 0 1 0
g83 PRIMAR 1 0 0 0
g84 PRIMAR 1 1 0 0
g85 NOPRIMAR 0 1 0 0
g86 NOPRIMAR 0 1 0 0
g87 NOPRIMAR 0 1 0 0
g88 NOPRIMAR 0 0 1 0
g89 NOPRIMAR 0 1 0 0
g90 PRIMAR 1 0 0 0
g91 PRIMAR 1 0 0 0
g92 NOPRIMAR 0 1 0 0
g93 NOPRIMAR 0 1 0 0
g94 PRIMAR 1 0 0 0
g95 NOPRIMAR 0 0 1 0
g96 PRIMAR 1 0 0 0
g97 NOPRIMAR 0 1 0 0
g98 NOPRIMAR 0 1 0 0
g99 NOPRIMAR 0 1 0 1
g100 PRIMAR 2 0 0 0
g101 PRIMAR 1 0 0 0
g102 PRIMAR 1 0 0 0
g103 PRIMAR 1 0 0 0
g104 PRIMAR 2 0 0 0
g105 PRIMAR 1 0 0 0
g106 PRIMAR 1 0 0 0
g107 PRIMAR 1 0 0 0
g108 PRIMAR 1 0 0 0
g109 PRIMAR 1 0 0 0
g110 NOPRIMAR 0 1 0 0
g111 NOPRIMAR 0 1 0 0
g112 NOPRIMAR 0 1 0 0
g113 PRIMAR 1 0 0 0
g114 NOPRIMAR 0 0 1 0
g115 NOPRIMAR 0 1 0 0
g116 NOPRIMAR 0 1 0 0
g117 NOPRIMAR 0 1 0 0
g118 NOPRIMAR 0 1 0 1
g119 PRIMAR 1 0 0 0
g120 PRIMAR 1 0 0 0
g121 PRIMAR 1 0 0 0
g122 PRIMAR 1 0 0 0
g123 NOPRIMAR 0 1 0 0
g124 PRIMAR 1 0 0 0
g125 NOPRIMAR 0 1 0 0
g126 PRIMAR 1 0 0 0
g127 PRIMAR 1 0 0 0
g128 NOPRIMAR 0 1 0 0
g129 PRIMAR 1 0 0 0
g130 PRIMAR 1 0 0 0
g131 PRIMAR 1 0 0 0
g132 NOPRIMAR 0 1 0 0
g133 NOPRIMAR 0 1 0 0
g134 PRIMAR 1 0 0 0
g135 PRIMAR 1 0 0 0
g136 NOPRIMAR 0 1 0 0
g137 NOPRIMAR 0 1 0 0
g138 NOPRIMAR 0 1 0 0
g139 PRIMAR 1 0 0 0
g140 NOPRIMAR 0 1 0 0
g141 NOPRIMAR 0 1 0 0
g142 NOPRIMAR 0 1 0 0
g143 NOPRIMAR 0 0 1 0
g144 PRIMAR 1 0 0 0
g145 PRIMAR 1 0 0 0
g146 PRIMAR 1 0 0 0
g147 NOPRIMAR 0 1 0 0
g148 NOPRIMAR 0 1 0 0
g149 PRIMAR 1 0 0 0
g150 NOPRIMAR 0 1 0 0
g151 NOPRIMAR 0 1 0 0
g152 PRIMAR 1 0 0 0
g153 PRIMAR 1 0 0 0
g154 PRIMAR 1 0 0 0
g155 NOPRIMAR 0 1 0 0
g156 NOPRIMAR 0 1 0 0
g157 PRIMAR 1 0 0 1
g158 PRIMAR 1 0 0 0
g159 NOPRIMAR 0 1 0 0
g160 NOPRIMAR 0 1 0 0
g161 PRIMAR 1 0 0 0
g162 NOPRIMAR 0 1 0 0
g163 NOPRIMAR 0 1 0 0
g164 NOPRIMAR 0 1 0 0
g165 NOPRIMAR 0 1 0 0
g166 NOPRIMAR 0 1 0 0
g167 NOPRIMAR 0 1 0 0
g168 PRIMAR 3 0 0 1
g169 NOPRIMAR 0 1 0 0
g170 PRIMAR 1 0 0 0
g171 NOPRIMAR 0 1 0 0
g172 NOPRIMAR 0 1 0 0
g173 NOPRIMAR 0 0 1 0
g174 PRIMAR 1 0 0 0
g175 NOPRIMAR 0 1 0 0
g176 NOPRIMAR 0 1 0 0
g177 NOPRIMAR 0 1 0 0
g178 NOPRIMAR 0 0 1 0
g179 PRIMAR 1 0 1 1
g180 PRIMAR 1 0 0 0
g181 PRIMAR 1 0 0 1
g182 PRIMAR 1 0 0 1
g183 PRIMAR 1 0 0 0
g184 NOPRIMAR 0 1 0 1
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/coverage_rows.txt
+178
View File
@@ -0,0 +1,178 @@
| M01 | Adressverwaltung / Kundenstamm | mittel | 1 |
| M02 | Ansprechpartnerverwaltung | mittel | 1 |
| M03 | CRM / Kontakthistorie | flach | 1 |
| M04 | CRM-Projekte | flach | 1 |
| M05 | Kundendetails / Kundenkonto | flach | 1 |
| M06 | Kunden-Textbausteine | flach | 1 |
| M07 | Kampagnen/Mailing | flach | 1 |
| M08 | Kundenaudit | flach | 1 |
| M09 | Kundenassets | mittel | 1 |
| M10 | Stammblätter | flach | 1 |
| M11 | Angebote | flach | 1 |
| M12 | Aufträge | flach | 1 |
| M13 | Lieferscheine | flach | 1 |
| M14 | Abhol-/Pickup-Scheine | flach | 1 |
| M15 | Rechnungen | mittel | 1 |
| M16 | Gutschriften | mittel | 1 |
| M17 | Anzahlungen | mittel | 1 |
| M18 | Mahnwesen | mittel | 1 |
| M19 | OPOS (offene Posten) | mittel | 1 |
| M20 | Belegerstellung/-versionierung (Kernlogik) | flach | 1 |
| M21 | Belegvorlagen | flach | 1 |
| M22 | Beleg-Warenkorb / Freigabesystem | mittel | 1 |
| M23 | Artikelsuche im Beleg | flach | 1 |
| M24 | Belegklassifikation | flach | 1 |
| M25 | Leasing/Service-Verträge | mittel | 1 |
| M26 | Vertragslisten | flach | 1 |
| M27 | Schweiz-Spezifika | flach | 1 |
| M28 | Belegprotokoll | flach | 1 |
| M29 | Belegpreisermittlung | flach | 1 |
| M30 | Provisionsermittlung je Beleg | flach | 1 |
| M31 | Lieferantenbestellungen | flach | 1 |
| M32 | Lieferantenrechnungen | flach | 1 |
| M33 | Lieferantengutschriften | flach | 1 |
| M34 | Lieferanten-Lieferscheine | flach | 1 |
| M35 | Belegerfassung Wareneingang (Scan) | mittel | 1 |
| M36 | Bestellvorschlagsliste | mittel | 1 |
| M37 | Kalkulation pro Filiale | flach | 1 |
| M38 | EDI-Verwaltung (zentral) | mittel | 1 |
| M39 | EDI-Lieferantenanbindungen (Alltron/Also DE/Also CH/Herweck/Komsa) | flach | 1 |
| M40 | EDI EGIS | flach | 1 |
| M41 | OpenTRANS-Format | flach | 1 |
| M42 | ZUGFeRD/E-Rechnung | flach | 1 |
| M43 | eb-Interface (Österreich) | flach | 1 |
| M44 | Buchhaltungsexport/-import | mittel | 1 |
| M45 | Datev-Belegtransfer | flach | 1 |
| M46 | Konzern-/Portalanbindung | flach | 1 |
| M47 | Online-Banking-Anbindung | mittel | 1 |
| M48 | FinAPI-Integration | mittel | 1 |
| M49 | SEPA-Zahlungsverkehr | mittel | 1 |
| M50 | Zahlungseingang | flach | 1 |
| M51 | Kassenbuch | flach | 1 |
| M52 | Pauschalabrechnung | flach | 1 |
| M53 | Automatisierte Vertragsabrechnung | mittel | 1 |
| M54 | Vereinfachte Ticketabrechnung | mittel | 1 |
| M55 | Click-Abrechnung | mittel | 1 |
| M56 | Klick-Zählerverwaltung | mittel | 1 |
| M57 | Kontingentverwaltung | flach | 1 |
| M58 | Vertragsartikel-Einstellungen | flach | 1 |
| M59 | Vertragsarten | flach | 1 |
| M60 | Vertragsauswertung | flach | 1 |
| M61 | Vertragsdatenimport (statisch/dynamisch) | flach | 1 |
| M62 | Provisionsauswertung | flach | 1 |
| M63 | Provisionsschema-Verwaltung | mittel | 1 |
| M64 | Provisionsschema-Kundenzuordnung | flach | 1 |
| M65 | Kostenträger/Kostenstellen | flach | 1 |
| M66 | Kontenrahmen | flach | 1 |
| M67 | Mehrwertsteuer-Verwaltung | mittel | 1 |
| M68 | Artikelstammdaten | mittel | 1 |
| M69 | Artikel-Staffelpreise | mittel | 1 |
| M70 | Aktionspreise | flach | 1 |
| M71 | Barcode-Verwaltung | mittel | 1 |
| M72 | Warengruppenverwaltung | flach | 1 |
| M73 | Artikelimport | flach | 1 |
| M74 | Artikelverwaltung (Lagerübersicht) | mittel | 1 |
| M75 | Inventur | mittel | 1 |
| M76 | Kommissionierung | flach | 1 |
| M77 | Versandmethoden | flach | 1 |
| M78 | GLS-Versandanbindung | flach | 1 |
| M79 | Shipcloud-Versandanbindung | flach | 1 |
| M80 | Maschinenverwaltung | mittel | 1 |
| M81 | Produktionsaufträge | mittel | 1 |
| M82 | Ticket-Liste/Helpdesk | flach | 1 |
| M83 | Checklisten | mittel | 1 |
| M84 | Taskmanagement | mittel | 1 |
| M85 | Ticketprozessvorlagen | flach | 1 |
| M86 | RMA/Werkstatt | flach | 1 |
| M87 | Erwartete Events | flach | 1 |
| M88 | Erwartete-Events-Auswertung | flach | 1 |
| M89 | Externe Helpdesk-Anbindung | flach | 1 |
| M90 | Reportserver | mittel | 1 |
| M91 | Interne Projektverwaltung | mittel | 1 |
| M92 | Kalender/Termine | flach | 1 |
| M93 | Terminanfragen | flach | 1 |
| M94 | E-Mail-Integration | mittel | 1 |
| M95 | Mailvorlagen | flach | 1 |
| M96 | Chat | mittel | 1 |
| M97 | Social-Media-Integration | flach | 1 |
| M98 | Telefonie (TAPI) | flach | 1 |
| M99 | Benachrichtigungen | flach | 1 |
| M100 | Rechteverwaltung | tief | 2 |
| M101 | Login/Authentifizierung | mittel | 1 |
| M102 | Zwei-Faktor-Authentifizierung | tief | 2 |
| M103 | Access Tokens | tief | 2 |
| M104 | Passwort-Manager (aktuell) | tief | 1 |
| M105 | Passwort-Manager (Legacy, obsolet) | mittel | 1 |
| M106 | DSGVO/Datenschutz | tief | 2 |
| M107 | Änderungsverfolgung (Audit-Trail) | mittel | 1 |
| M108 | PDF-Signatur | mittel | 1 |
| M109 | Mandantenverwaltung | tief | 2 |
| M110 | Firmenstammdaten | flach | 1 |
| M111 | Länderverwaltung | flach | 1 |
| M112 | Mitarbeiterverwaltung | flach | 1 |
| M113 | Organisationsstruktur (Filialen/Stammdaten) | mittel | 1 |
| M114 | Belegkonditionen/Zahlungsbedingungen | flach | 1 |
| M115 | Systemeinstellungen | flach | 1 |
| M116 | Webservice-Konfiguration | flach | 1 |
| M117 | Verbindungsverwaltung | flach | 1 |
| M118 | SQL-Manager | flach | 1 |
| M119 | c-entron Config-DB | tief | 2 |
| M120 | Lizenzverwaltung | mittel | 1 |
| M121 | Hintergrunddienste | mittel | 1 |
| M122 | Netzwerkdiagnose | mittel | 1 |
| M123 | Profiling/Performance-Tests | flach | 1 |
| M124 | c-entron Inspektor/Logs | mittel | 1 |
| M125 | Telemetrie | flach | 1 |
| M126 | Dokumentenindexsuche | mittel | 1 |
| M127 | Kundenspezifische Anpassungen | mittel | 1 |
| M128 | Themes/Design | flach | 1 |
| M129 | Textbaustein-Verwaltung | mittel | 1 |
| M130 | Eigene Felder (Custom Properties) | mittel | 1 |
| M131 | Externe Werkzeuge | mittel | 1 |
| M132 | Reportverwaltung/-vorlagen | flach | 1 |
| M133 | Excel-Export | flach | 1 |
| M134 | Data Updater / Massenänderungen | mittel | 1 |
| M135 | Skriptmethoden | mittel | 1 |
| M136 | Prozessvorlagen | flach | 1 |
| M137 | Umsatz-/Verkaufsstatistik | flach | 1 |
| M138 | Leistungsnachweise | flach | 1 |
| M139 | Management-Info | mittel | 1 |
| M140 | Mitarbeiterauslastung | flach | 1 |
| M141 | MSP-Collector | flach | 1 |
| M142 | MSP-Vergleich/Dashboard | flach | 1 |
| M143 | Dashboard | flach | 1 |
| M144 | Mein Tag | mittel | 1 |
| M145 | To-do-Liste | mittel | 1 |
| M146 | KI-Chat/Assistent | mittel | 1 |
| M147 | Gutscheinverwaltung | flach | 1 |
| M148 | Videoportal | flach | 1 |
| M149 | TradePool | mittel | 1 |
| M150 | SelfCare (Backend) | flach | 1 |
| M151 | WebLinks/URL-Verwaltung | flach | 1 |
| M152 | Tags/Verschlagwortung | mittel | 1 |
| M153 | Objekt-Fremdreferenzen | mittel | 1 |
| M154 | Reisekosten (deaktiviert) | mittel | 1 |
| M155 | IT-Planer | flach | 1 |
| M156 | Zeiterfassung | flach | 1 |
| M157 | Produktdaten-Feeds (COP/ITscope/Icecat) | mittel | 1 |
| M158 | docuFORM-API | mittel | 1 |
| M159 | CentronNexus-Kundenportal | flach | 1 |
| M160 | Web-Angebot (WebOffer) | flach | 1 |
| M161 | Web-Warenkorb (WebCart) | mittel | 1 |
| M162 | Service-Board | flach | 1 |
| M163 | Dokumentensignatur (Nexus) | flach | 1 |
| M164 | Office-Integration (Nexus) | flach | 1 |
| M165 | Outlook-Add-in | flach | 1 |
| M166 | Mobile Anwendung (Backend) | flach | 1 |
| M167 | Legacy-REST-Webservice | flach | 1 |
| M168 | Moderne REST-Controller (v1) | tief | 1 |
| M169 | Verbindungsmanager (Client-Tool) | flach | 1 |
| M170 | Web-Version-Steuerung | mittel | 1 |
| M171 | Domänenentitäten | flach | 1 |
| M172 | Datenzugriffsschicht (DAO/Mappings) | flach | 1 |
| M173 | Gemeinsame Basisbibliothek | flach | 1 |
| M174 | WPF-Client-Framework | mittel | 1 |
| M175 | Gemeinsame UI-Steuerelemente | flach | 1 |
| M176 | Installer/Deployment | flach | 1 |
| M177 | Docker-Betriebsumgebung | flach | 1 |
| M178 | CI/CD-Pipelines | flach | 1 |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/coverage_table_final.txt
+178
View File
@@ -0,0 +1,178 @@
| M01 | Adressverwaltung / Kundenstamm | mittel | 1 |
| M02 | Ansprechpartnerverwaltung | mittel | 1 |
| M03 | CRM / Kontakthistorie | flach | 1 |
| M04 | CRM-Projekte | flach | 1 |
| M05 | Kundendetails / Kundenkonto | flach | 1 |
| M06 | Kunden-Textbausteine | flach | 1 |
| M07 | Kampagnen/Mailing | flach | 1 |
| M08 | Kundenaudit | flach | 1 |
| M09 | Kundenassets | mittel | 1 |
| M10 | Stammblätter | flach | 1 |
| M11 | Angebote | flach | 1 |
| M12 | Aufträge | flach | 1 |
| M13 | Lieferscheine | flach | 1 |
| M14 | Abhol-/Pickup-Scheine | flach | 1 |
| M15 | Rechnungen | mittel | 1 |
| M16 | Gutschriften | mittel | 1 |
| M17 | Anzahlungen | mittel | 1 |
| M18 | Mahnwesen | mittel | 1 |
| M19 | OPOS (offene Posten) | mittel | 1 |
| M20 | Belegerstellung/-versionierung (Kernlogik) | flach | 1 |
| M21 | Belegvorlagen | flach | 1 |
| M22 | Beleg-Warenkorb / Freigabesystem | mittel | 1 |
| M23 | Artikelsuche im Beleg | flach | 1 |
| M24 | Belegklassifikation | flach | 1 |
| M25 | Leasing/Service-Verträge | mittel | 1 |
| M26 | Vertragslisten | flach | 1 |
| M27 | Schweiz-Spezifika | flach | 1 |
| M28 | Belegprotokoll | flach | 1 |
| M29 | Belegpreisermittlung | flach | 1 |
| M30 | Provisionsermittlung je Beleg | flach | 1 |
| M31 | Lieferantenbestellungen | flach | 1 |
| M32 | Lieferantenrechnungen | flach | 1 |
| M33 | Lieferantengutschriften | flach | 1 |
| M34 | Lieferanten-Lieferscheine | flach | 1 |
| M35 | Belegerfassung Wareneingang (Scan) | mittel | 1 |
| M36 | Bestellvorschlagsliste | mittel | 1 |
| M37 | Kalkulation pro Filiale | flach | 1 |
| M38 | EDI-Verwaltung (zentral) | mittel | 1 |
| M39 | EDI-Lieferantenanbindungen (Alltron/Also DE/Also CH/Herweck/Komsa) | flach | 1 |
| M40 | EDI EGIS | flach | 1 |
| M41 | OpenTRANS-Format | flach | 1 |
| M42 | ZUGFeRD/E-Rechnung | flach | 1 |
| M43 | eb-Interface (Österreich) | flach | 1 |
| M44 | Buchhaltungsexport/-import | mittel | 1 |
| M45 | Datev-Belegtransfer | flach | 1 |
| M46 | Konzern-/Portalanbindung | flach | 1 |
| M47 | Online-Banking-Anbindung | mittel | 1 |
| M48 | FinAPI-Integration | mittel | 1 |
| M49 | SEPA-Zahlungsverkehr | mittel | 1 |
| M50 | Zahlungseingang | flach | 1 |
| M51 | Kassenbuch | flach | 1 |
| M52 | Pauschalabrechnung | flach | 1 |
| M53 | Automatisierte Vertragsabrechnung | mittel | 1 |
| M54 | Vereinfachte Ticketabrechnung | mittel | 1 |
| M55 | Click-Abrechnung | mittel | 1 |
| M56 | Klick-Zählerverwaltung | mittel | 1 |
| M57 | Kontingentverwaltung | flach | 1 |
| M58 | Vertragsartikel-Einstellungen | flach | 1 |
| M59 | Vertragsarten | flach | 1 |
| M60 | Vertragsauswertung | flach | 1 |
| M61 | Vertragsdatenimport (statisch/dynamisch) | flach | 1 |
| M62 | Provisionsauswertung | flach | 1 |
| M63 | Provisionsschema-Verwaltung | mittel | 1 |
| M64 | Provisionsschema-Kundenzuordnung | flach | 1 |
| M65 | Kostenträger/Kostenstellen | flach | 1 |
| M66 | Kontenrahmen | flach | 1 |
| M67 | Mehrwertsteuer-Verwaltung | mittel | 1 |
| M68 | Artikelstammdaten | mittel | 1 |
| M69 | Artikel-Staffelpreise | mittel | 1 |
| M70 | Aktionspreise | flach | 1 |
| M71 | Barcode-Verwaltung | mittel | 1 |
| M72 | Warengruppenverwaltung | flach | 1 |
| M73 | Artikelimport | flach | 1 |
| M74 | Artikelverwaltung (Lagerübersicht) | mittel | 1 |
| M75 | Inventur | mittel | 1 |
| M76 | Kommissionierung | flach | 1 |
| M77 | Versandmethoden | flach | 1 |
| M78 | GLS-Versandanbindung | flach | 1 |
| M79 | Shipcloud-Versandanbindung | flach | 1 |
| M80 | Maschinenverwaltung | mittel | 1 |
| M81 | Produktionsaufträge | mittel | 1 |
| M82 | Ticket-Liste/Helpdesk | flach | 1 |
| M83 | Checklisten | mittel | 1 |
| M84 | Taskmanagement | mittel | 1 |
| M85 | Ticketprozessvorlagen | flach | 1 |
| M86 | RMA/Werkstatt | flach | 1 |
| M87 | Erwartete Events | flach | 1 |
| M88 | Erwartete-Events-Auswertung | flach | 1 |
| M89 | Externe Helpdesk-Anbindung | flach | 1 |
| M90 | Reportserver | mittel | 1 |
| M91 | Interne Projektverwaltung | mittel | 1 |
| M92 | Kalender/Termine | flach | 1 |
| M93 | Terminanfragen | flach | 1 |
| M94 | E-Mail-Integration | mittel | 1 |
| M95 | Mailvorlagen | flach | 1 |
| M96 | Chat | mittel | 1 |
| M97 | Social-Media-Integration | flach | 1 |
| M98 | Telefonie (TAPI) | flach | 1 |
| M99 | Benachrichtigungen | flach | 1 |
| M100 | Rechteverwaltung | tief | 2 |
| M101 | Login/Authentifizierung | mittel | 1 |
| M102 | Zwei-Faktor-Authentifizierung | tief | 2 |
| M103 | Access Tokens | tief | 2 |
| M104 | Passwort-Manager (aktuell) | tief | 1 |
| M105 | Passwort-Manager (Legacy, obsolet) | mittel | 1 |
| M106 | DSGVO/Datenschutz | tief | 2 |
| M107 | Änderungsverfolgung (Audit-Trail) | mittel | 1 |
| M108 | PDF-Signatur | mittel | 1 |
| M109 | Mandantenverwaltung | tief | 2 |
| M110 | Firmenstammdaten | flach | 1 |
| M111 | Länderverwaltung | flach | 1 |
| M112 | Mitarbeiterverwaltung | flach | 1 |
| M113 | Organisationsstruktur (Filialen/Stammdaten) | mittel | 1 |
| M114 | Belegkonditionen/Zahlungsbedingungen | flach | 1 |
| M115 | Systemeinstellungen | flach | 1 |
| M116 | Webservice-Konfiguration | flach | 1 |
| M117 | Verbindungsverwaltung | flach | 1 |
| M118 | SQL-Manager | flach | 1 |
| M119 | c-entron Config-DB | tief | 2 |
| M120 | Lizenzverwaltung | mittel | 1 |
| M121 | Hintergrunddienste | mittel | 1 |
| M122 | Netzwerkdiagnose | mittel | 1 |
| M123 | Profiling/Performance-Tests | flach | 1 |
| M124 | c-entron Inspektor/Logs | mittel | 1 |
| M125 | Telemetrie | flach | 1 |
| M126 | Dokumentenindexsuche | mittel | 1 |
| M127 | Kundenspezifische Anpassungen | mittel | 1 |
| M128 | Themes/Design | flach | 1 |
| M129 | Textbaustein-Verwaltung | mittel | 1 |
| M130 | Eigene Felder (Custom Properties) | mittel | 1 |
| M131 | Externe Werkzeuge | mittel | 1 |
| M132 | Reportverwaltung/-vorlagen | flach | 1 |
| M133 | Excel-Export | flach | 1 |
| M134 | Data Updater / Massenänderungen | mittel | 1 |
| M135 | Skriptmethoden | mittel | 1 |
| M136 | Prozessvorlagen | flach | 1 |
| M137 | Umsatz-/Verkaufsstatistik | flach | 1 |
| M138 | Leistungsnachweise | flach | 1 |
| M139 | Management-Info | mittel | 1 |
| M140 | Mitarbeiterauslastung | flach | 1 |
| M141 | MSP-Collector | flach | 1 |
| M142 | MSP-Vergleich/Dashboard | flach | 1 |
| M143 | Dashboard | flach | 1 |
| M144 | Mein Tag | mittel | 1 |
| M145 | To-do-Liste | mittel | 1 |
| M146 | KI-Chat/Assistent | mittel | 1 |
| M147 | Gutscheinverwaltung | flach | 1 |
| M148 | Videoportal | flach | 1 |
| M149 | TradePool | mittel | 1 |
| M150 | SelfCare (Backend) | flach | 1 |
| M151 | WebLinks/URL-Verwaltung | flach | 1 |
| M152 | Tags/Verschlagwortung | mittel | 1 |
| M153 | Objekt-Fremdreferenzen | mittel | 1 |
| M154 | Reisekosten (deaktiviert) | mittel | 1 |
| M155 | IT-Planer | flach | 1 |
| M156 | Zeiterfassung | flach | 1 |
| M157 | Produktdaten-Feeds (COP/ITscope/Icecat) | mittel | 1 |
| M158 | docuFORM-API | mittel | 1 |
| M159 | CentronNexus-Kundenportal | flach | 1 |
| M160 | Web-Angebot (WebOffer) | flach | 1 |
| M161 | Web-Warenkorb (WebCart) | mittel | 1 |
| M162 | Service-Board | flach | 1 |
| M163 | Dokumentensignatur (Nexus) | flach | 1 |
| M164 | Office-Integration (Nexus) | flach | 1 |
| M165 | Outlook-Add-in | flach | 1 |
| M166 | Mobile Anwendung (Backend) | flach | 1 |
| M167 | Legacy-REST-Webservice | flach | 1 |
| M168 | Moderne REST-Controller (v1) | tief | 1 |
| M169 | Verbindungsmanager (Client-Tool) | flach | 1 |
| M170 | Web-Version-Steuerung | mittel | 1 |
| M171 | Domänenentitäten | flach | 1 |
| M172 | Datenzugriffsschicht (DAO/Mappings) | flach | 1 |
| M173 | Gemeinsame Basisbibliothek | flach | 1 |
| M174 | WPF-Client-Framework | mittel | 1 |
| M175 | Gemeinsame UI-Steuerelemente | flach | 1 |
| M176 | Installer/Deployment | flach | 1 |
| M177 | Docker-Betriebsumgebung | flach | 1 |
| M178 | CI/CD-Pipelines | flach | 1 |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/module_names.txt
+178
View File
@@ -0,0 +1,178 @@
M01 | Adressverwaltung / Kundenstamm
M02 | Ansprechpartnerverwaltung
M03 | CRM / Kontakthistorie
M04 | CRM-Projekte
M05 | Kundendetails / Kundenkonto
M06 | Kunden-Textbausteine
M07 | Kampagnen/Mailing
M08 | Kundenaudit
M09 | Kundenassets
M10 | Stammblätter
M11 | Angebote
M12 | Aufträge
M13 | Lieferscheine
M14 | Abhol-/Pickup-Scheine
M15 | Rechnungen
M16 | Gutschriften
M17 | Anzahlungen
M18 | Mahnwesen
M19 | OPOS (offene Posten)
M20 | Belegerstellung/-versionierung (Kernlogik)
M21 | Belegvorlagen
M22 | Beleg-Warenkorb / Freigabesystem
M23 | Artikelsuche im Beleg
M24 | Belegklassifikation
M25 | Leasing/Service-Verträge
M26 | Vertragslisten
M27 | Schweiz-Spezifika
M28 | Belegprotokoll
M29 | Belegpreisermittlung
M30 | Provisionsermittlung je Beleg
M31 | Lieferantenbestellungen
M32 | Lieferantenrechnungen
M33 | Lieferantengutschriften
M34 | Lieferanten-Lieferscheine
M35 | Belegerfassung Wareneingang (Scan)
M36 | Bestellvorschlagsliste
M37 | Kalkulation pro Filiale
M38 | EDI-Verwaltung (zentral)
M39 | EDI-Lieferantenanbindungen (Alltron/Also DE/Also CH/Herweck/Komsa)
M40 | EDI EGIS
M41 | OpenTRANS-Format
M42 | ZUGFeRD/E-Rechnung
M43 | eb-Interface (Österreich)
M44 | Buchhaltungsexport/-import
M45 | Datev-Belegtransfer
M46 | Konzern-/Portalanbindung
M47 | Online-Banking-Anbindung
M48 | FinAPI-Integration
M49 | SEPA-Zahlungsverkehr
M50 | Zahlungseingang
M51 | Kassenbuch
M52 | Pauschalabrechnung
M53 | Automatisierte Vertragsabrechnung
M54 | Vereinfachte Ticketabrechnung
M55 | Click-Abrechnung
M56 | Klick-Zählerverwaltung
M57 | Kontingentverwaltung
M58 | Vertragsartikel-Einstellungen
M59 | Vertragsarten
M60 | Vertragsauswertung
M61 | Vertragsdatenimport (statisch/dynamisch)
M62 | Provisionsauswertung
M63 | Provisionsschema-Verwaltung
M64 | Provisionsschema-Kundenzuordnung
M65 | Kostenträger/Kostenstellen
M66 | Kontenrahmen
M67 | Mehrwertsteuer-Verwaltung
M68 | Artikelstammdaten
M69 | Artikel-Staffelpreise
M70 | Aktionspreise
M71 | Barcode-Verwaltung
M72 | Warengruppenverwaltung
M73 | Artikelimport
M74 | Artikelverwaltung (Lagerübersicht)
M75 | Inventur
M76 | Kommissionierung
M77 | Versandmethoden
M78 | GLS-Versandanbindung
M79 | Shipcloud-Versandanbindung
M80 | Maschinenverwaltung
M81 | Produktionsaufträge
M82 | Ticket-Liste/Helpdesk
M83 | Checklisten
M84 | Taskmanagement
M85 | Ticketprozessvorlagen
M86 | RMA/Werkstatt
M87 | Erwartete Events
M88 | Erwartete-Events-Auswertung
M89 | Externe Helpdesk-Anbindung
M90 | Reportserver
M91 | Interne Projektverwaltung
M92 | Kalender/Termine
M93 | Terminanfragen
M94 | E-Mail-Integration
M95 | Mailvorlagen
M96 | Chat
M97 | Social-Media-Integration
M98 | Telefonie (TAPI)
M99 | Benachrichtigungen
M100 | Rechteverwaltung
M101 | Login/Authentifizierung
M102 | Zwei-Faktor-Authentifizierung
M103 | Access Tokens
M104 | Passwort-Manager (aktuell)
M105 | Passwort-Manager (Legacy, obsolet)
M106 | DSGVO/Datenschutz
M107 | Änderungsverfolgung (Audit-Trail)
M108 | PDF-Signatur
M109 | Mandantenverwaltung
M110 | Firmenstammdaten
M111 | Länderverwaltung
M112 | Mitarbeiterverwaltung
M113 | Organisationsstruktur (Filialen/Stammdaten)
M114 | Belegkonditionen/Zahlungsbedingungen
M115 | Systemeinstellungen
M116 | Webservice-Konfiguration
M117 | Verbindungsverwaltung
M118 | SQL-Manager
M119 | c-entron Config-DB
M120 | Lizenzverwaltung
M121 | Hintergrunddienste
M122 | Netzwerkdiagnose
M123 | Profiling/Performance-Tests
M124 | c-entron Inspektor/Logs
M125 | Telemetrie
M126 | Dokumentenindexsuche
M127 | Kundenspezifische Anpassungen
M128 | Themes/Design
M129 | Textbaustein-Verwaltung
M130 | Eigene Felder (Custom Properties)
M131 | Externe Werkzeuge
M132 | Reportverwaltung/-vorlagen
M133 | Excel-Export
M134 | Data Updater / Massenänderungen
M135 | Skriptmethoden
M136 | Prozessvorlagen
M137 | Umsatz-/Verkaufsstatistik
M138 | Leistungsnachweise
M139 | Management-Info
M140 | Mitarbeiterauslastung
M141 | MSP-Collector
M142 | MSP-Vergleich/Dashboard
M143 | Dashboard
M144 | Mein Tag
M145 | To-do-Liste
M146 | KI-Chat/Assistent
M147 | Gutscheinverwaltung
M148 | Videoportal
M149 | TradePool
M150 | SelfCare (Backend)
M151 | WebLinks/URL-Verwaltung
M152 | Tags/Verschlagwortung
M153 | Objekt-Fremdreferenzen
M154 | Reisekosten (deaktiviert)
M155 | IT-Planer
M156 | Zeiterfassung
M157 | Produktdaten-Feeds (COP/ITscope/Icecat)
M158 | docuFORM-API
M159 | CentronNexus-Kundenportal
M160 | Web-Angebot (WebOffer)
M161 | Web-Warenkorb (WebCart)
M162 | Service-Board
M163 | Dokumentensignatur (Nexus)
M164 | Office-Integration (Nexus)
M165 | Outlook-Add-in
M166 | Mobile Anwendung (Backend)
M167 | Legacy-REST-Webservice
M168 | Moderne REST-Controller (v1)
M169 | Verbindungsmanager (Client-Tool)
M170 | Web-Version-Steuerung
M171 | Domänenentitäten
M172 | Datenzugriffsschicht (DAO/Mappings)
M173 | Gemeinsame Basisbibliothek
M174 | WPF-Client-Framework
M175 | Gemeinsame UI-Steuerelemente
M176 | Installer/Deployment
M177 | Docker-Betriebsumgebung
M178 | CI/CD-Pipelines
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/module_names_clean.txt
+178
View File
@@ -0,0 +1,178 @@
1 Adressverwaltung / Kundenstamm
2 Ansprechpartnerverwaltung
3 CRM / Kontakthistorie
4 CRM-Projekte
5 Kundendetails / Kundenkonto
6 Kunden-Textbausteine
7 Kampagnen/Mailing
8 Kundenaudit
9 Kundenassets
10 Stammblätter
11 Angebote
12 Aufträge
13 Lieferscheine
14 Abhol-/Pickup-Scheine
15 Rechnungen
16 Gutschriften
17 Anzahlungen
18 Mahnwesen
19 OPOS (offene Posten)
20 Belegerstellung/-versionierung (Kernlogik)
21 Belegvorlagen
22 Beleg-Warenkorb / Freigabesystem
23 Artikelsuche im Beleg
24 Belegklassifikation
25 Leasing/Service-Verträge
26 Vertragslisten
27 Schweiz-Spezifika
28 Belegprotokoll
29 Belegpreisermittlung
30 Provisionsermittlung je Beleg
31 Lieferantenbestellungen
32 Lieferantenrechnungen
33 Lieferantengutschriften
34 Lieferanten-Lieferscheine
35 Belegerfassung Wareneingang (Scan)
36 Bestellvorschlagsliste
37 Kalkulation pro Filiale
38 EDI-Verwaltung (zentral)
39 EDI-Lieferantenanbindungen (Alltron/Also DE/Also CH/Herweck/Komsa)
40 EDI EGIS
41 OpenTRANS-Format
42 ZUGFeRD/E-Rechnung
43 eb-Interface (Österreich)
44 Buchhaltungsexport/-import
45 Datev-Belegtransfer
46 Konzern-/Portalanbindung
47 Online-Banking-Anbindung
48 FinAPI-Integration
49 SEPA-Zahlungsverkehr
50 Zahlungseingang
51 Kassenbuch
52 Pauschalabrechnung
53 Automatisierte Vertragsabrechnung
54 Vereinfachte Ticketabrechnung
55 Click-Abrechnung
56 Klick-Zählerverwaltung
57 Kontingentverwaltung
58 Vertragsartikel-Einstellungen
59 Vertragsarten
60 Vertragsauswertung
61 Vertragsdatenimport (statisch/dynamisch)
62 Provisionsauswertung
63 Provisionsschema-Verwaltung
64 Provisionsschema-Kundenzuordnung
65 Kostenträger/Kostenstellen
66 Kontenrahmen
67 Mehrwertsteuer-Verwaltung
68 Artikelstammdaten
69 Artikel-Staffelpreise
70 Aktionspreise
71 Barcode-Verwaltung
72 Warengruppenverwaltung
73 Artikelimport
74 Artikelverwaltung (Lagerübersicht)
75 Inventur
76 Kommissionierung
77 Versandmethoden
78 GLS-Versandanbindung
79 Shipcloud-Versandanbindung
80 Maschinenverwaltung
81 Produktionsaufträge
82 Ticket-Liste/Helpdesk
83 Checklisten
84 Taskmanagement
85 Ticketprozessvorlagen
86 RMA/Werkstatt
87 Erwartete Events
88 Erwartete-Events-Auswertung
89 Externe Helpdesk-Anbindung
90 Reportserver
91 Interne Projektverwaltung
92 Kalender/Termine
93 Terminanfragen
94 E-Mail-Integration
95 Mailvorlagen
96 Chat
97 Social-Media-Integration
98 Telefonie (TAPI)
99 Benachrichtigungen
100 Rechteverwaltung
101 Login/Authentifizierung
102 Zwei-Faktor-Authentifizierung
103 Access Tokens
104 Passwort-Manager (aktuell)
105 Passwort-Manager (Legacy, obsolet)
106 DSGVO/Datenschutz
107 Änderungsverfolgung (Audit-Trail)
108 PDF-Signatur
109 Mandantenverwaltung
110 Firmenstammdaten
111 Länderverwaltung
112 Mitarbeiterverwaltung
113 Organisationsstruktur (Filialen/Stammdaten)
114 Belegkonditionen/Zahlungsbedingungen
115 Systemeinstellungen
116 Webservice-Konfiguration
117 Verbindungsverwaltung
118 SQL-Manager
119 c-entron Config-DB
120 Lizenzverwaltung
121 Hintergrunddienste
122 Netzwerkdiagnose
123 Profiling/Performance-Tests
124 c-entron Inspektor/Logs
125 Telemetrie
126 Dokumentenindexsuche
127 Kundenspezifische Anpassungen
128 Themes/Design
129 Textbaustein-Verwaltung
130 Eigene Felder (Custom Properties)
131 Externe Werkzeuge
132 Reportverwaltung/-vorlagen
133 Excel-Export
134 Data Updater / Massenänderungen
135 Skriptmethoden
136 Prozessvorlagen
137 Umsatz-/Verkaufsstatistik
138 Leistungsnachweise
139 Management-Info
140 Mitarbeiterauslastung
141 MSP-Collector
142 MSP-Vergleich/Dashboard
143 Dashboard
144 Mein Tag
145 To-do-Liste
146 KI-Chat/Assistent
147 Gutscheinverwaltung
148 Videoportal
149 TradePool
150 SelfCare (Backend)
151 WebLinks/URL-Verwaltung
152 Tags/Verschlagwortung
153 Objekt-Fremdreferenzen
154 Reisekosten (deaktiviert)
155 IT-Planer
156 Zeiterfassung
157 Produktdaten-Feeds (COP/ITscope/Icecat)
158 docuFORM-API
159 CentronNexus-Kundenportal
160 Web-Angebot (WebOffer)
161 Web-Warenkorb (WebCart)
162 Service-Board
163 Dokumentensignatur (Nexus)
164 Office-Integration (Nexus)
165 Outlook-Add-in
166 Mobile Anwendung (Backend)
167 Legacy-REST-Webservice
168 Moderne REST-Controller (v1)
169 Verbindungsmanager (Client-Tool)
170 Web-Version-Steuerung
171 Domänenentitäten
172 Datenzugriffsschicht (DAO/Mappings)
173 Gemeinsame Basisbibliothek
174 WPF-Client-Framework
175 Gemeinsame UI-Steuerelemente
176 Installer/Deployment
177 Docker-Betriebsumgebung
178 CI/CD-Pipelines
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Ergebnisse/swrs_classification.txt
+184
View File
@@ -0,0 +1,184 @@
SwRS-001 PRIMAR 1 0 0 0
SwRS-002 PRIMAR 1 0 0 0
SwRS-003 NOPRIMAR 0 1 0 0
SwRS-004 NOPRIMAR 0 1 0 0
SwRS-005 NOPRIMAR 0 1 0 0
SwRS-006 NOPRIMAR 0 1 0 0
SwRS-007 NOPRIMAR 0 1 0 0
SwRS-008 NOPRIMAR 0 1 1 0
SwRS-009 PRIMAR 1 1 0 0
SwRS-010 NOPRIMAR 0 0 1 0
SwRS-011 NOPRIMAR 0 1 0 0
SwRS-012 NOPRIMAR 0 1 0 0
SwRS-013 NOPRIMAR 0 1 0 0
SwRS-014 NOPRIMAR 0 1 0 0
SwRS-015 PRIMAR 1 0 0 0
SwRS-016 PRIMAR 1 0 0 0
SwRS-017 PRIMAR 1 0 0 0
SwRS-018 PRIMAR 2 0 0 0
SwRS-019 PRIMAR 1 0 0 0
SwRS-020 NOPRIMAR 0 1 0 0
SwRS-021 NOPRIMAR 0 1 0 0
SwRS-022 PRIMAR 1 0 0 0
SwRS-023 NOPRIMAR 0 1 0 0
SwRS-024 NOPRIMAR 0 1 0 0
SwRS-025 PRIMAR 1 0 0 0
SwRS-026 NOPRIMAR 0 1 0 0
SwRS-027 NOPRIMAR 0 1 0 0
SwRS-028 NOPRIMAR 0 1 0 0
SwRS-029 NOPRIMAR 0 1 0 0
SwRS-030 NOPRIMAR 0 1 0 0
SwRS-031 NOPRIMAR 0 1 0 0
SwRS-032 NOPRIMAR 0 1 0 0
SwRS-033 NOPRIMAR 0 1 0 0
SwRS-034 NOPRIMAR 0 1 0 0
SwRS-035 PRIMAR 1 0 0 0
SwRS-036 PRIMAR 1 0 0 0
SwRS-037 NOPRIMAR 0 0 1 0
SwRS-038 PRIMAR 1 0 0 0
SwRS-039 NOPRIMAR 0 1 0 0
SwRS-040 NOPRIMAR 0 1 0 0
SwRS-041 NOPRIMAR 0 1 0 0
SwRS-042 NOPRIMAR 0 1 1 0
SwRS-043 NOPRIMAR 0 1 0 0
SwRS-044 PRIMAR 1 0 0 0
SwRS-045 NOPRIMAR 0 0 1 0
SwRS-046 NOPRIMAR 0 1 0 0
SwRS-047 PRIMAR 1 0 0 0
SwRS-048 PRIMAR 1 0 0 0
SwRS-049 PRIMAR 1 0 0 0
SwRS-050 NOPRIMAR 0 1 0 0
SwRS-051 NOPRIMAR 0 1 0 0
SwRS-052 NOPRIMAR 0 1 0 1
SwRS-053 PRIMAR 1 0 0 0
SwRS-054 PRIMAR 1 0 0 0
SwRS-055 PRIMAR 1 0 0 0
SwRS-056 PRIMAR 1 0 0 0
SwRS-057 NOPRIMAR 0 1 0 0
SwRS-058 NOPRIMAR 0 0 1 0
SwRS-059 NOPRIMAR 0 1 0 0
SwRS-060 NOPRIMAR 0 1 0 0
SwRS-061 NOPRIMAR 0 1 0 0
SwRS-062 NOPRIMAR 0 1 0 0
SwRS-063 PRIMAR 1 0 0 0
SwRS-064 NOPRIMAR 0 1 0 0
SwRS-065 NOPRIMAR 0 1 0 0
SwRS-066 NOPRIMAR 0 0 1 0
SwRS-067 PRIMAR 1 0 0 0
SwRS-068 PRIMAR 1 0 0 0
SwRS-069 PRIMAR 1 0 0 0
SwRS-070 NOPRIMAR 0 1 0 0
SwRS-071 PRIMAR 1 0 1 0
SwRS-072 NOPRIMAR 0 0 1 0
SwRS-073 NOPRIMAR 0 0 1 0
SwRS-074 PRIMAR 1 0 0 0
SwRS-075 PRIMAR 1 0 0 0
SwRS-076 NOPRIMAR 0 1 0 0
SwRS-077 NOPRIMAR 0 0 1 0
SwRS-078 NOPRIMAR 0 1 0 0
SwRS-079 NOPRIMAR 0 1 0 0
SwRS-080 PRIMAR 1 0 0 0
SwRS-081 PRIMAR 1 1 0 0
SwRS-082 NOPRIMAR 0 0 1 0
SwRS-083 PRIMAR 1 0 0 0
SwRS-084 PRIMAR 1 1 0 0
SwRS-085 NOPRIMAR 0 1 0 0
SwRS-086 NOPRIMAR 0 1 0 0
SwRS-087 NOPRIMAR 0 1 0 0
SwRS-088 NOPRIMAR 0 0 1 0
SwRS-089 NOPRIMAR 0 1 0 0
SwRS-090 PRIMAR 1 0 0 0
SwRS-091 PRIMAR 1 0 0 0
SwRS-092 NOPRIMAR 0 1 0 0
SwRS-093 NOPRIMAR 0 1 0 0
SwRS-094 PRIMAR 1 0 0 0
SwRS-095 NOPRIMAR 0 0 1 0
SwRS-096 PRIMAR 1 0 0 0
SwRS-097 NOPRIMAR 0 1 0 0
SwRS-098 NOPRIMAR 0 1 0 0
SwRS-099 NOPRIMAR 0 1 0 1
SwRS-100 PRIMAR 2 0 0 0
SwRS-101 PRIMAR 1 0 0 0
SwRS-102 PRIMAR 1 0 0 0
SwRS-103 PRIMAR 1 0 0 0
SwRS-104 PRIMAR 2 0 0 0
SwRS-105 PRIMAR 1 0 0 0
SwRS-106 PRIMAR 1 0 0 0
SwRS-107 PRIMAR 1 0 0 0
SwRS-108 PRIMAR 1 0 0 0
SwRS-109 PRIMAR 1 0 0 0
SwRS-110 NOPRIMAR 0 1 0 0
SwRS-111 NOPRIMAR 0 1 0 0
SwRS-112 NOPRIMAR 0 1 0 0
SwRS-113 PRIMAR 1 0 0 0
SwRS-114 NOPRIMAR 0 0 1 0
SwRS-115 NOPRIMAR 0 1 0 0
SwRS-116 NOPRIMAR 0 1 0 0
SwRS-117 NOPRIMAR 0 1 0 0
SwRS-118 NOPRIMAR 0 1 0 1
SwRS-119 PRIMAR 1 0 0 0
SwRS-120 PRIMAR 1 0 0 0
SwRS-121 PRIMAR 1 0 0 0
SwRS-122 PRIMAR 1 0 0 0
SwRS-123 NOPRIMAR 0 1 0 0
SwRS-124 PRIMAR 1 0 0 0
SwRS-125 NOPRIMAR 0 1 0 0
SwRS-126 PRIMAR 1 0 0 0
SwRS-127 PRIMAR 1 0 0 0
SwRS-128 NOPRIMAR 0 1 0 0
SwRS-129 PRIMAR 1 0 0 0
SwRS-130 PRIMAR 1 0 0 0
SwRS-131 PRIMAR 1 0 0 0
SwRS-132 NOPRIMAR 0 1 0 0
SwRS-133 NOPRIMAR 0 1 0 0
SwRS-134 PRIMAR 1 0 0 0
SwRS-135 PRIMAR 1 0 0 0
SwRS-136 NOPRIMAR 0 1 0 0
SwRS-137 NOPRIMAR 0 1 0 0
SwRS-138 NOPRIMAR 0 1 0 0
SwRS-139 PRIMAR 1 0 0 0
SwRS-140 NOPRIMAR 0 1 0 0
SwRS-141 NOPRIMAR 0 1 0 0
SwRS-142 NOPRIMAR 0 1 0 0
SwRS-143 NOPRIMAR 0 0 1 0
SwRS-144 PRIMAR 1 0 0 0
SwRS-145 PRIMAR 1 0 0 0
SwRS-146 PRIMAR 1 0 0 0
SwRS-147 NOPRIMAR 0 1 0 0
SwRS-148 NOPRIMAR 0 1 0 0
SwRS-149 PRIMAR 1 0 0 0
SwRS-150 NOPRIMAR 0 1 0 0
SwRS-151 NOPRIMAR 0 1 0 0
SwRS-152 PRIMAR 1 0 0 0
SwRS-153 PRIMAR 1 0 0 0
SwRS-154 PRIMAR 1 0 0 0
SwRS-155 NOPRIMAR 0 1 0 0
SwRS-156 NOPRIMAR 0 1 0 0
SwRS-157 PRIMAR 1 0 0 1
SwRS-158 PRIMAR 1 0 0 0
SwRS-159 NOPRIMAR 0 1 0 0
SwRS-160 NOPRIMAR 0 1 0 0
SwRS-161 PRIMAR 1 0 0 0
SwRS-162 NOPRIMAR 0 1 0 0
SwRS-163 NOPRIMAR 0 1 0 0
SwRS-164 NOPRIMAR 0 1 0 0
SwRS-165 NOPRIMAR 0 1 0 0
SwRS-166 NOPRIMAR 0 1 0 0
SwRS-167 NOPRIMAR 0 1 0 0
SwRS-168 PRIMAR 3 0 0 1
SwRS-169 NOPRIMAR 0 1 0 0
SwRS-170 PRIMAR 1 0 0 0
SwRS-171 NOPRIMAR 0 1 0 0
SwRS-172 NOPRIMAR 0 1 0 0
SwRS-173 NOPRIMAR 0 0 1 0
SwRS-174 PRIMAR 1 0 0 0
SwRS-175 NOPRIMAR 0 1 0 0
SwRS-176 NOPRIMAR 0 1 0 0
SwRS-177 NOPRIMAR 0 1 0 0
SwRS-178 NOPRIMAR 0 0 1 0
SwRS-179 PRIMAR 1 0 1 1
SwRS-180 PRIMAR 1 0 0 0
SwRS-181 PRIMAR 1 0 0 1
SwRS-182 PRIMAR 1 0 0 1
SwRS-183 PRIMAR 1 0 0 0
SwRS-184 NOPRIMAR 0 1 0 1
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Protokoll.md
+231
View File
@@ -0,0 +1,231 @@
# 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-26T10:29:40.3777367+02:00
- **Endzeit:** 2026-08-26T11:38:34.5723301+02:00
- **Dauer gesamt:** 1:08:54 (`duration_ms` 1:08:52; API: 1:04:51)
— **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: ja)
- **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:** **ja – der Snapshot weicht vom Commit-Stand ab.** Folgende Dateien lagen zusätzlich im Arbeitsverzeichnis und standen dem Lauf als Artefaktquelle zur Verfügung:
- `QuellCode/CentronERP/SSMS_DB_SCHEMA.sql` (Git-Status `??`)
- SHA-256: `ED7F21250E868577572B4CADA53C132F7433C74270BF9B59E817CCEC6B1FA8DB`
- 3.266.626 B / 76.793 Zeilen – SSMS-Schema-Dump der Datenbank `CentronVOED2`: 1.558 `CREATE TABLE`, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel
Läufe mit und ohne diese Artefakte sind **nicht** unmittelbar vergleichbar: Der
Untersuchungsgegenstand ist ein anderer.
- **Nutzung des DB-Schemas:** **nein** – kein einziger Werkzeugaufruf nennt `SSMS_DB_SCHEMA` in der Eingabe, und die Ergebnisartefakte erwähnen sie nicht. Der Agent hat die Datei allenfalls in der Verzeichnisauflistung gesehen und **nicht geöffnet**. Die Verfügbarkeit des Schemas ist die Versuchsbedingung, seine Nutzung eine abhängige Variable – dieser Lauf gehört zur Bedingung, nutzt sie aber nicht.
- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
## Werkzeugkonfiguration
- **Skill-Version:** 4.3.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-sonnet-5`
- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 68.877.202 Tokens (99.99 %), `claude-haiku-4-5-20251001` 6.964 Tokens (0.01 %)
- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
- **Effort:** `high` (per `--effort high` gesetzt)
- **Laufverzeichnis-ID:** `v4.3.0-3ef5`
- **Ablage:** `Iteration 3/claude-sonnet-5/solo/high/`
- **Parallele Läufe:** **ja** – zeitgleich liefen:
- `02_Lauf_2026-08-26_102932_v4.3.0-0848`
- `02_Lauf_2026-08-26_102932_v4.3.0-1b24`
- `02_Lauf_2026-08-26_102932_v4.3.0-2316`
- `02_Lauf_2026-08-26_102932_v4.3.0-b652`
Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden.
Tokenverbrauch, Anforderungszahl und Denials bleiben unverzerrt.
- **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 | 392 |
| Output-Tokens | 366.595 (davon 69.831 Thinking-Tokens) |
| Cache-Write-Tokens | 539.136 |
| Cache-Read-Tokens | 67.971.079 |
| Agent-Turns | 196 |
### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
|---|---:|---:|---:|
| Input-Tokens | 392 | 6.944 | 7.336 |
| Output-Tokens | 366.595 | 20 | 366.615 |
| Cache-Write-Tokens | 539.136 | 0 | 539.136 |
| Cache-Read-Tokens | 67.971.079 | 0 | 67.971.079 |
| **Tokens gesamt** | **68.877.202** | **6.964** | **68.884.166** |
**Tokens gesamt: 68.884.166** — 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 | 25 | 10,5 % |
| SyRS | 28 | 11,8 % |
| SwRS | 184 | 77,6 % |
| **Gesamt** | **237** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 134 | 56,5 % |
| Schnittstelle | 27 | 11,4 % |
| Daten | 26 | 11,0 % |
| nicht-funktional | 25 | 10,5 % |
| Sicherheit | 24 | 10,1 % |
| Zuverlässigkeit | 1 | 0,4 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 267 |
| davon `PRIMÄR` | 98 (36,7 %) |
| davon `SEKUNDÄR` | 135 (50,6 %) |
| davon `KONTEXT` | 34 (12,7 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 92 (38,8 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 220 | 92,8 % |
| workaround | 6 | 2,5 % |
| sonderfall | 8 | 3,4 % |
| veraltet | 3 | 1,3 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 223 | 94,1 % |
| als `HYPOTHESE` gekennzeichnet | 14 | 5,9 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 33 | 13,9 % |
| mit ISO-25010-Qualitätsmerkmal | 114 | 48,1 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **verletzt** – 1 ohne Beleg: SyRS-020 |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 9 von 54 ungedeckt: StRS-003, StRS-006, StRS-007, StRS-018, SyRS-007, SwRS-136, SwRS-164, SwRS-166 … |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 237 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 237 von 237 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
- **Session-ID:** `e35de1b2-95c0-4590-a2fe-90b7b7c70fba`
- **Permission-Denials:** 3 (2 × `Bash`, 1 × `PowerShell`) – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – Bedingung `solo` eingehalten
- **Subagenten-Prompts:** entfällt (Modus `solo`)
- **Erzeugte Dateien:** 13 Dateien in `Ergebnisse\`:
| Datei | Größe |
|---|---:|
| `Analysebericht.md` | 48.435 B |
| `Glossar.md` | 6.865 B |
| `Hypothesen.md` | 5.976 B |
| `StRS.md` | 45.965 B |
| `SwRS.md` | 292.404 B |
| `SyRS.md` | 47.503 B |
| `Traceability.md` | 19.984 B |
| `cls_clean.txt` | 3.784 B |
| `coverage_rows.txt` | 7.852 B |
| `coverage_table_final.txt` | 7.852 B |
| `module_names.txt` | 5.125 B |
| `module_names_clean.txt` | 4.404 B |
| `swrs_classification.txt` | 4.628 B |
- **Root unverändert:** ja (zeilenendennormalisiert verglichen). Der rohe Vorher/Nachher-Vergleich weicht ab, weil `SSMS_DB_SCHEMA.sql` zwischen Laufbeginn und Auswertung committet wurde und deshalb nicht mehr als `??` im Status erscheint. Nach Normalisierung um diese Zeile sind beide Stände identisch; zusätzlich ist `git diff HEAD -- QuellCode/CentronERP` leer (bestätigt). Am Inhalt des Arbeitsverzeichnisses hat der Lauf nichts verändert.
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
## Anmerkungen/Auffälligkeiten
**1. Iteration 3 = geänderter Untersuchungsgegenstand.** Seit 2026-08-26 10:28:08 liegt
`SSMS_DB_SCHEMA.sql` im Arbeitsverzeichnis (3.266.626 B, 76.793 Zeilen, 1.558 Tabellen, 182 Views,
63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256 `ED7F2125…1FA8DB`, Commit `f349d189`).
Der Prompt fordert Datenbankschemata in Schritt 2 ausdrücklich als Artefaktquelle. Läufe der
Iteration 2 hatten die Datei nicht – die beiden Iterationen sind **nicht poolbar**.
**2. Verfügbarkeit ≠ Nutzung.** Ob der Agent das Schema öffnet, ist eine **abhängige** Variable:
Von den fünf Läufen der Iteration 3 haben drei es genutzt (`0848`, `1b24`, `2316`), zwei nicht
(`3ef5`, `b652`). Erhoben wird das über Werkzeugaufrufe, deren **Eingabe** den Dateinamen nennt –
nicht über Texttreffer im Transkript: Die Verzeichnisauflistung zu Laufbeginn nennt die Datei
zwangsläufig und ist kein Zugriff.
**3. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Fünf Läufe gleichzeitig,
zeitweise überlappend mit `094249_v4.2.1-4840` aus Iteration 2. Wanduhrzeit, `duration_ms` und
`duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials
nicht. Einziger gültiger Laufzeitmesspunkt beider Iterationen bleibt der serielle Lauf
`084301_v4.2.0-d6f9` mit 45:04.
**4. Root-Vergleich normalisiert.** `before.txt` führt das Schema als `??`, `after.txt` ist leer –
weil die Datei zwischen Laufbeginn und Auswertung committet wurde. Der rohe Vergleich meldete
deshalb eine Abweichung, die es nicht gibt. Nach Normalisierung um diese Zeile sind beide Stände
identisch, zusätzlich bestätigt durch ein leeres `git diff HEAD -- QuellCode/CentronERP`.
**5. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung; die `solo`-Kontrolle
(`subagent_stats.spawned` = 0) wurde gegengeprüft und ist erfüllt.
**6. Schema verfügbar, aber nicht genutzt – und trotzdem die höchste Anforderungszahl beider
Iterationen.** Kein einziger Werkzeugaufruf nennt `SSMS_DB_SCHEMA` in der Eingabe. Der Lauf hat
237 Anforderungen erzeugt und dafür **68,9 Mio. Tokens** verbraucht – der teuerste Lauf beider
Iterationen. Gegenüber `0848` (Schema genutzt, 211 Anforderungen, 11,4 Mio. Tokens) ist das Faktor
6,0 beim Verbrauch für 12 % mehr Anforderungen.
**7. Menge auf Kosten der Belegqualität.** 38,8 % mit Primärbeleg, neun von 51 risikorelevanten
Anforderungen ungedeckt. Die Verteilung ist mit 77,6 % SwRS stark softwarelastig; `SwRS.md` ist
mit 252 KB das größte Einzelartefakt der gesamten Versuchsreihe.
**8. Sechs Arbeitsdateien im Ergebnisordner – Folge der Denylist.** Neben den sieben geforderten
Artefakten liegen `cls_clean.txt`, `coverage_rows.txt`, `coverage_table_final.txt`,
`module_names.txt`, `module_names_clean.txt` und `swrs_classification.txt` im Ergebnisordner. Zwei
`Bash`-Kommandos und ein `Remove-Item` zum Aufräumen wurden von der Denylist gestoppt. Die Dateien
bleiben **bewusst liegen**: Ein nachträgliches Löschen würde die Artefaktlage des Laufs verändern.
Der Befund ist eine Eigenschaft der Werkzeugkonfiguration, nicht des Modells – die Denylist sperrt
Löschbefehle pauschal, auch im Laufverzeichnis, für das der Agent Schreibrecht hat.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/RawResult.json
+1
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/Stderr.log
View File
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/_meta/after.txt
View File
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/_meta/anforderungen.json
+4534
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/_meta/anforderungen.md
+66
View File
@@ -0,0 +1,66 @@
## 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 | 25 | 10,5 % |
| SyRS | 28 | 11,8 % |
| SwRS | 184 | 77,6 % |
| **Gesamt** | **237** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 134 | 56,5 % |
| Schnittstelle | 27 | 11,4 % |
| Daten | 26 | 11,0 % |
| nicht-funktional | 25 | 10,5 % |
| Sicherheit | 24 | 10,1 % |
| Zuverlässigkeit | 1 | 0,4 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 267 |
| davon `PRIMÄR` | 98 (36,7 %) |
| davon `SEKUNDÄR` | 135 (50,6 %) |
| davon `KONTEXT` | 34 (12,7 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 92 (38,8 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 220 | 92,8 % |
| workaround | 6 | 2,5 % |
| sonderfall | 8 | 3,4 % |
| veraltet | 3 | 1,3 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 223 | 94,1 % |
| als `HYPOTHESE` gekennzeichnet | 14 | 5,9 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 33 | 13,9 % |
| mit ISO-25010-Qualitätsmerkmal | 114 | 48,1 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **verletzt** – 1 ohne Beleg: SyRS-020 |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 9 von 54 ungedeckt: StRS-003, StRS-006, StRS-007, StRS-018, SyRS-007, SwRS-136, SwRS-164, SwRS-166 … |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 237 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 237 von 237 mit Tracelinks (100,0 %) |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/_meta/before.txt
+2
View File
@@ -0,0 +1,2 @@
?? QuellCode/CentronERP/SSMS_DB_SCHEMA.sql
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/_meta/combined_prompt.md
+177
View File
@@ -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\Tag 2\claude-sonnet-5\solo\high\02_Lauf_2026-08-26_102932_v4.3.0-3ef5\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-26T11:38:34.5723301+02:00
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-3ef5/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-26T10:29:40.3777367+02:00
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/Ergebnisse/Analysebericht.md
+446
View File
@@ -0,0 +1,446 @@
# Analysebericht
## Schritt 0 – Modulinventar
Grundlage: vollständige Verzeichnisanalyse von `src/` und der Root-Projekte der Codebasis
`C:\DEV\MasterArbeit\QuellCode\CentronERP`. Die Codebasis gliedert sich in sechs Bereiche:
`src/backend` (Kernlogik/Datenzugriff), `src/centron` (WPF-Desktop-Client), `src/nexus`
(Blazor-Webportal „CentronNexus“), `src/webservice` (SOAP/REST-Dienstschicht),
`src/shared` (gemeinsam genutzte Bibliotheken) und `src/apis` + Root (externe API-Adapter).
Die fachliche Gliederung folgt primär den Namespace-Ordnern von `Centron.BL`
(Geschäftslogikschicht), ergänzt um die Web-Portal-Bereiche von `CentronNexus` und die
technischen Querschnittskomponenten. Diese Tabelle ist die Bezugsgröße für die
Abdeckungstabelle in Schritt 8 und wird nicht gekürzt.
Pfadangaben sind relativ zu `src/`, sofern nicht anders vermerkt.
| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M001 | Accounting | backend/Centron.BL/Accounting | Bankkontenverwaltung (Stammdaten für Bankkonten des Mandanten) |
| M002 | Accounts (CRM-Kern) | backend/Centron.BL/Accounts | Kunden-/Lieferanten-Stammdaten, Adressen, Kontakte, Kampagnen, Hotline, Sonderpreise |
| M003 | Administration | backend/Centron.BL/Administration | Mandanten-, Benutzer-, Rechte-, Lizenz- und Systemkonfigurationsverwaltung (Kernmodul) |
| M004 | AppointmentRequests | backend/Centron.BL/AppointmentRequests | Terminanfragen (z. B. Kundenportal-Terminwünsche) |
| M005 | ArtificialIntelligence | backend/Centron.BL/ArtificialIntelligence | Anbindung externer KI-/Chat-Modelle (OpenAI-kompatibel) für Textbewertung/Ticketkategorisierung |
| M006 | BusinessPartner | backend/Centron.BL/BusinessPartner | Lieferantensuche, Asset-Zuordnung zu Lieferanten |
| M007 | Buying | backend/Centron.BL/Buying | Distributorenverwaltung (externer Einkauf) |
| M008 | CPra | backend/Centron.BL/CPra | Anbindung an externes System „CPra“ (Konfiguration/Connector) |
| M009 | Calendar | backend/Centron.BL/Calendar | Kalender-/Terminverwaltung |
| M010 | CentronIcons | backend/Centron.BL/CentronIcons | Icon-Verwaltung für UI und Webservice |
| M011 | CentronNexus (BL) | backend/Centron.BL/CentronNexus | Backend-Anbindung des Webportals CentronNexus an die Kernlogik |
| M012 | ChangeTracking | backend/Centron.BL/ChangeTracking | Änderungshistorie für Importvorgänge |
| M013 | Chats | backend/Centron.BL/Chats | Interner Chat |
| M014 | CheckListArea | backend/Centron.BL/CheckListArea | Checklisten-Verwaltung inkl. Update-Checklisten |
| M015 | Core (BL) | backend/Centron.BL/Core | Kryptografie-Hilfsfunktionen, Text-Platzhalterersetzung |
| M016 | CountryArea | backend/Centron.BL/CountryArea | Länder-/Bundesländerstammdaten |
| M017 | CustomerArea | backend/Centron.BL/CustomerArea | Branchen, Kontaktaktivitäten, Interessen, Produkte, RMA (Retoure) |
| M018 | Customizations | backend/Centron.BL/Customizations | Benutzerdefinierte Tabellen (Custom Tables) |
| M019 | DataExchange | backend/Centron.BL/DataExchange | Datenaustausch: Buchhaltung, Connectoren, DocuForm, EDI, GfK-Export, Import, Zahlungsverkehr, RMM, TelekomDive |
| M020 | Devices | backend/Centron.BL/Devices | Zuordnung von Geräten zu Kundenkonten |
| M021 | DocuBoard | backend/Centron.BL/DocuBoard | Asset-Management (Artikelzuordnung, Partner, AD-Systembenutzer-Ausschluss) |
| M022 | DocumentationArea | backend/Centron.BL/DocumentationArea | Dokumentationsverwaltung |
| M023 | EDI | backend/Centron.BL/EDI | Elektronischer Datenaustausch mit Lieferanten (Alltron, ALSO, EGIS, Komsa, Opentrans, ZUGFeRD u. a.) |
| M024 | EmployeeArea | backend/Centron.BL/EmployeeArea | Mitarbeiterstammdaten, Benutzerkonten, Abteilungen, Urlaub, RFID-Token, Teammanagement |
| M025 | Exceptions | backend/Centron.BL/Exceptions | Fachliche Ausnahmetypen (z. B. abgelaufenes Ticket) |
| M026 | ExpectedEvents | backend/Centron.BL/ExpectedEvents | Erwartete Ereignisse (Wiedervorlage/Erinnerung) |
| M027 | ExternalHelpdesk | backend/Centron.BL/ExternalHelpdesk | Anbindung externer Helpdesk-Konfiguration |
| M028 | ExternalToolsBL | backend/Centron.BL/ExternalToolsBL | Verwaltung externer Werkzeuge/Anwendungen |
| M029 | Finances | backend/Centron.BL/Finances | Zahlungseingänge, Online-Banking, Produktlebenszyklus, Zahlungen |
| M030 | GUI (Import/Profile) | backend/Centron.BL/GUI | UI-Profile, EDI-Auftragsimport, Rastergitter-Konfiguration |
| M031 | Gateway (BL) | backend/Centron.BL/Gateway | Generisches Gateway-Handling |
| M032 | Helpers | backend/Centron.BL/Helpers | Technische Hilfsklassen (Graph-API, Bild, PDF, String, Word) |
| M033 | IndexSearch | backend/Centron.BL/IndexSearch | Volltextsuche/-indizierung (Lucene-basiert, deutscher Analyzer) |
| M034 | Integrations | backend/Centron.BL/Integrations | Anbindung externes System „ES“ (Kundengruppen/Rollen) |
| M035 | ItPlanner | backend/Centron.BL/ItPlanner | Checklisten-Kategorien für virtuelle Objekte |
| M036 | Logistics | backend/Centron.BL/Logistics | Logistikeinstellungen, Lagerbestand |
| M037 | Mail | backend/Centron.BL/Mail | E-Mail-Versand/-Empfang, Signaturen, Vorlagen, Blacklist, Exchange-Anbindung |
| M038 | MailScanner | backend/Centron.BL/MailScanner | Automatisches Einlesen eingehender E-Mails |
| M039 | Mailings | backend/Centron.BL/Mailings | Serien-E-Mail-Kampagnen (Mailing-Daten/-Vorlagen) |
| M040 | MassUpdate | backend/Centron.BL/MassUpdate | Massenänderungen an Datensätzen |
| M041 | Mobile | backend/Centron.BL/Mobile | Mobile-Client-Anbindung |
| M042 | Modules | backend/Centron.BL/Modules | Modul-/Modulkategorie-Verwaltung (Lizenz-/Freischaltmodell) |
| M043 | MyCentron | backend/Centron.BL/MyCentron | Persönliches Dashboard, Notizen, Terminierungen |
| M044 | MyDay | backend/Centron.BL/MyDay | Tagesübersicht/Benachrichtigungen inkl. Fremdsystem „Supremo“ |
| M045 | NexusNotifications | backend/Centron.BL/NexusNotifications | Push-Benachrichtigungen für CentronNexus (SignalR-Hub) |
| M046 | NexusTicketViews | backend/Centron.BL/NexusTicketViews | Gespeicherte Ticket-Ansichten für CentronNexus |
| M047 | Notifications | backend/Centron.BL/Notifications | Systembenachrichtigungen an Benutzer |
| M048 | ObjectExternalReferences | backend/Centron.BL/ObjectExternalReferences | Externe Referenzen auf Centron-Objekte |
| M049 | Outlook | backend/Centron.BL/Outlook | Outlook-Anbindung (Asset-Suche) |
| M050 | PasswordManagementArea | backend/Centron.BL/PasswordManagementArea | Kundenpasswortverwaltung inkl. Zugriffsprotokoll |
| M051 | PasswordManager | backend/Centron.BL/PasswordManager | Interner Passwortmanager |
| M052 | Processes | backend/Centron.BL/Processes | Geschäftsprozess-Verwaltung |
| M053 | ProductMatrix | backend/Centron.BL/ProductMatrix | Produktmatrix (Konfigurationsmatrix für Artikel) |
| M054 | Production | backend/Centron.BL/Production | Produktionsaufträge |
| M055 | Projects | backend/Centron.BL/Projects | Projektverwaltung |
| M056 | Purchasing | backend/Centron.BL/Purchasing | Einkauf: Lieferanten, Bestellvorschläge, Einkaufseinstellungen, Filialzuordnung |
| M057 | ReportEngine | backend/Centron.BL/ReportEngine | Reportgenerator (FastReport), PDF-Export, Ersetzungslogik |
| M058 | Reporting | backend/Centron.BL/Reporting | Reportverwaltung (übergeordnet) |
| M059 | RiverDivo | backend/Centron.BL/RiverDivo | Anbindung externes System „RiverDivo“ |
| M060 | Sales | backend/Centron.BL/Sales | Vertrieb: Kalender, Kassenbuch, Kundenassets, Kunden, Dokumentationsassistent, Zuschlagssätze, Marketing, Belege, Support (Kernmodul) |
| M061 | Security | backend/Centron.BL/Security | PDF-Signierung |
| M062 | SelfCare | backend/Centron.BL/SelfCare | Self-Service-Webanfragen |
| M063 | Services (BL) | backend/Centron.BL/Services | Cache-Tabellen, CTime-Zeiterfassungsanbindung, Datenqualität, Workflow-Engine |
| M064 | SocialMedia | backend/Centron.BL/SocialMedia | Anbindung sozialer Netzwerke |
| M065 | Start | backend/Centron.BL/Start | Anwendungsstart-Logik |
| M066 | Statistics | backend/Centron.BL/Statistics | Auswertungen: Konten, Mitarbeiter, Verträge, MSP, Vertrieb, Ticket |
| M067 | Storage | backend/Centron.BL/Storage | Lagerbestandspool |
| M068 | SystemArea | backend/Centron.BL/SystemArea | Systemtabellen (I3D) |
| M069 | Tags | backend/Centron.BL/Tags | Tag-/Schlagwortverwaltung |
| M070 | Tapi | backend/Centron.BL/Tapi | Telefonie-Anbindung (Anrufprotokoll) |
| M071 | TaskManager | backend/Centron.BL/TaskManager | Aufgabenverwaltung inkl. Aktions-Handler |
| M072 | Telemetry | backend/Centron.BL/Telemetry | Telemetriedaten |
| M073 | TextModuleArea | backend/Centron.BL/TextModuleArea | Textbausteine, Anrede-/Grußformel-Ersetzung |
| M074 | TicketProjects | backend/Centron.BL/TicketProjects | Ticket-Projekt-Zuordnung |
| M075 | Time | backend/Centron.BL/Time | Zeiterfassungseinstellungen |
| M076 | ToDoArea | backend/Centron.BL/ToDoArea | To-Do-Verwaltung |
| M077 | Tools | backend/Centron.BL/Tools | Werkzeugverwaltung |
| M078 | TradePool | backend/Centron.BL/TradePool | Handelspool (Artikelbörse zwischen Mandanten/Partnern) |
| M079 | Transactions | backend/Centron.BL/Transactions | Transaktionsprotokollierung |
| M080 | TwoFactorAuthenticator | backend/Centron.BL/TwoFactorAuthenticator | Zwei-Faktor-Authentifizierung |
| M081 | Urls | backend/Centron.BL/Urls | Kurz-/einfache URL-Verwaltung |
| M082 | VideoPortal | backend/Centron.BL/VideoPortal | Video-Portal-Zuordnung |
| M083 | VoucherManagement | backend/Centron.BL/VoucherManagement | Gutschein-/Belegverwaltung |
| M084 | Warehousing | backend/Centron.BL/Warehousing | Lagerwirtschaft: Artikel, Barcode, Kostenstellen/-objekte, Steuern, Kommissionierung, Produktion (Kernmodul) |
| M085 | WebLinks | backend/Centron.BL/WebLinks | Web-Link-Aktionen (z. B. E-Mail-Klick-Handler) |
| M086 | WebServices (BL-Fassade) | backend/Centron.BL/WebServices | Fassadenschicht der Geschäftslogik für die SOAP/REST-Dienste, pro Fachbereich gespiegelt |
| M087 | WebSuite | backend/Centron.BL/WebSuite | Web-Administrationseinstellungen (Mitarbeiter, HD-Fragen, Menükonfiguration) |
| M088 | WebVersion | backend/Centron.BL/WebVersion | Versionsinformationen für Web-Komponenten |
| M089 | Centron.DAO | backend/Centron.DAO | Datenzugriffsschicht (NHibernate-ORM, Mappings, Repositories, Stored-Procedure-Zugriff) |
| M090 | Centron.Entities | backend/Centron.Entities | Zentrales Datenmodell (Entitätsklassen, Web-Service-DTOs) |
| M091 | Centron.Interfaces | backend/Centron.Interfaces | Schnittstellenverträge zwischen BL/DAO/Web (Contracts je Fachbereich) |
| M092 | Centron.Common | backend/Centron.Common | Technische Querschnittsbibliothek (Logging, Settings, Netzwerk, Sicherheit, Erweiterungsmethoden) |
| M093 | Centron.Gateway | backend/Centron.Gateway | Technische Gateway-Implementierungen für EDI-Lieferanten und Online-Banking |
| M094 | Centron.WPF.UI | centron/Centron.WPF.UI | Desktop-Client (WPF), Hauptanwendung, Fenster-/Modulverwaltung, Lokalisierung |
| M095 | Centron.WPF.UI.Extension | centron/Centron.WPF.UI.Extension | Erweiterungen/Zusatzsteuerelemente des Desktop-Clients |
| M096 | Centron.Controls | shared/Centron.Controls | Gemeinsame WPF-Steuerelemente/Fachkomponenten (Kundenverwaltung, Checklisten, Dashboards) |
| M097 | Centron.Controls.Preview | shared/Centron.Controls.Preview | Vorschau-/Testhost für Centron.Controls |
| M098 | Centron.Core (shared) | shared/Centron.Core | Gemeinsame Basisfunktionen (TOTP-Auth, PDF-Scan, MVVM-Basisklassen) |
| M099 | Centron.WebServices.Core | webservice/Centron.WebServices.Core | Client-seitige Kommunikationsschicht zu den Webservices (REST/Verbindungen) |
| M100 | Centron.Controllers | webservice/Centron.Controllers | API-Controller-Schicht inkl. Autorisierung des Webservice-Hosts |
| M101 | Centron.Host (Webservice) | webservice/Centron.Host | Hosting-Schicht des Webservice (ASP.NET Core, Echtzeitdienste) |
| M102 | Centron.Host.Console / .WindowsService | webservice/Centron.Host.Console, .WindowsService | Betriebsarten (Konsole/Windows-Dienst) des Webservice-Hosts |
| M103 | c-entron.misc.ConnectionManager | webservice/c-entron.misc.ConnectionManager | Eigenständiges Tool zur DB-/Verbindungskonfiguration |
| M104 | CentronNexus – ServiceBoard | nexus/CentronNexus/ServiceBoard | Agenten-Arbeitsoberfläche: Ticket-Kanban, Zeiterfassung, Telefonie, Statistik im Webportal |
| M105 | CentronNexus – WebCart | nexus/CentronNexus/WebCart | Kundenportal: Web-Shop, Vertragsübersicht, Belege, Formulare, Ticket-Self-Service |
| M106 | CentronNexus – WebOffer | nexus/CentronNexus/WebOffer | Web-Angebots-/Auftragsbestätigungsstrecke für Kunden |
| M107 | CentronNexus – DocumentSigning | nexus/CentronNexus/DocumentSigning | Elektronische Dokumentensignatur im Webportal |
| M108 | CentronNexus – ProductionOrderManagement | nexus/CentronNexus/ProductionOrderManagement | Produktionsauftragsverwaltung im Webportal |
| M109 | CentronNexus – Office/Shared Documents | nexus/CentronNexus/Office | Freigabe/Akzeptanz gemeinsam genutzter Dokumente |
| M110 | CentronNexus – Management | nexus/CentronNexus/Management | Portal-Verwaltung: Aufgaben, Ticketmuster, Web-Konten |
| M111 | CentronNexus.Host | nexus/CentronNexus.Host | Blazor-Hosting-Projekt des Webportals |
| M112 | CentronNexus.OutlookAddIn | nexus/CentronNexus.OutlookAddIn | Outlook-Add-in für Ticket-/Kunden-/Dokumentzuordnung |
| M113 | Centron.APIs.FinAPI | apis/Centron.APIs.FinAPI | Anbindung externer Banking-API „FinAPI“ |
| M114 | Centron.APIs.CopDataAccess | apis/Centron.APIs.CopDataAccess | Anbindung externer Produktdatenquelle „COP“ |
| M115 | Centron.APIs.EgisDataAccess | apis/Centron.APIs.EgisDataAccess | Anbindung Distributor-API „EGIS“ |
| M116 | Centron.APIs.ITscopeDataAccess | apis/Centron.APIs.ITscopeDataAccess | Anbindung Produktdatenquelle „ITscope“ |
| M117 | Centron.APIs.IcecatDataAccess | apis/Centron.APIs.IcecatDataAccess | Anbindung Produktdatenquelle „Icecat“ |
| M118 | Centron.Api.EbInterface | apis/Centron.Api.EbInterface | E-Rechnungs-Schnittstelle (ebInterface-Format) |
| M119 | Centron.Api.Gls | apis/Centron.Api.Gls | Anbindung Paketdienst GLS |
| M120 | Centron.Api.Shipcloud | apis/Centron.Api.Shipcloud | Anbindung Versanddienstleister-Aggregator Shipcloud |
| M121 | Centron.Api.docuFORM | Centron.Api.docuFORM (Root) | Anbindung externer Formular-/Dokumentenerstellung „docuFORM“ |
**Hinweis zur Abgrenzung:** `Centron.BL/WebServices` (M086) spiegelt die Fachbereiche der übrigen
BL-Module als Web-API-Fassade; es werden dort nur Anforderungen erfasst, die sich von den
zugrunde liegenden Fachmodulen unterscheiden (z. B. Autorisierungs- oder Mapping-Aspekte),
um Redundanz zu vermeiden. Gleiches gilt für `Centron.BL/Statistics`, `Centron.BL/Purchasing`
etc., die auf andere Fachmodule aufsetzen.
## Schritt 8 – Abdeckungstabelle
Einstufung je Modul auf Basis der Anzahl und Tiefe der aus dem Modul unmittelbar belegten
Anforderungen: **tief** (≥3 Anforderungen, i. d. R. mehrschichtig StRS→SyRS→SwRS oder mehrere
unabhängige Aspekte des Moduls), **mittel** (2 Anforderungen), **flach** (genau 1 Anforderung,
Mindestabdeckung aus Schritt 0b), **nicht analysiert** (0 Anforderungen, mit Begründung).
Jede Zeile des Modulinventars aus Schritt 0 erscheint hier wieder.
| # | Modul | Einstufung | Anzahl Anforderungen | Referenz-IDs |
|---|---|---|---|---|
| M001 | Accounting | tief | 3 | StRS-001, SyRS-001, SwRS-001 |
| M002 | Accounts | mittel | 2 | StRS-002, SwRS-002 |
| M003 | Administration | tief | 9 | StRS-003, StRS-004, SyRS-002, SyRS-003, SyRS-004, SwRS-011, SwRS-012, SwRS-013, SwRS-014 |
| M004 | AppointmentRequests | flach | 1 | SwRS-003 |
| M005 | ArtificialIntelligence | flach | 1 | SwRS-034 |
| M006 | BusinessPartner | flach | 1 | SwRS-004 |
| M007 | Buying | flach | 1 | SwRS-005 |
| M008 | CPra | flach | 1 | SwRS-006 |
| M009 | Calendar | flach | 1 | SwRS-007 |
| M010 | CentronIcons | flach | 1 | SwRS-008 |
| M011 | CentronNexus (BL) | flach | 1 | SwRS-035 |
| M012 | ChangeTracking | flach | 1 | SwRS-009 |
| M013 | Chats | flach | 1 | SwRS-010 |
| M014 | CheckListArea | flach | 1 | SwRS-015 |
| M015 | Core (BL) | flach | 1 | SwRS-135 |
| M016 | CountryArea | flach | 1 | SwRS-016 |
| M017 | CustomerArea | flach | 1 | SwRS-017 |
| M018 | Customizations | flach | 1 | SwRS-018 |
| M019 | DataExchange | flach | 1 | SwRS-056 |
| M020 | Devices | flach | 1 | SwRS-019 |
| M021 | DocuBoard | flach | 1 | SwRS-020 |
| M022 | DocumentationArea | flach | 1 | SwRS-021 |
| M023 | EDI | flach | 1 | SwRS-022 |
| M024 | EmployeeArea | flach | 1 | SwRS-023 |
| M025 | Exceptions | flach | 1 | SwRS-024 |
| M026 | ExpectedEvents | flach | 1 | SwRS-025 |
| M027 | ExternalHelpdesk | flach | 1 | SwRS-026 |
| M028 | ExternalToolsBL | flach | 1 | SwRS-027 |
| M029 | Finances | tief | 3 | SyRS-008, SwRS-086, SwRS-092 |
| M030 | GUI (Import/Profile) | flach | 1 | SwRS-028 |
| M031 | Gateway (BL) | flach | 1 | SwRS-029 |
| M032 | Helpers | flach | 1 | SwRS-036 |
| M033 | IndexSearch | flach | 1 | SwRS-030 |
| M034 | Integrations | flach | 1 | SwRS-031 |
| M035 | ItPlanner | flach | 1 | SwRS-032 |
| M036 | Logistics | flach | 1 | SwRS-033 |
| M037 | Mail | flach | 1 | SwRS-037 |
| M038 | MailScanner | flach | 1 | SwRS-038 |
| M039 | Mailings | flach | 1 | SwRS-039 |
| M040 | MassUpdate | mittel | 2 | SwRS-040, SwRS-132 [HYPOTHESE] |
| M041 | Mobile | flach | 1 | SwRS-041 |
| M042 | Modules | flach | 1 | SwRS-042 |
| M043 | MyCentron | flach | 1 | SwRS-043 |
| M044 | MyDay | flach | 1 | SwRS-044 |
| M045 | NexusNotifications | flach | 1 | SwRS-047 |
| M046 | NexusTicketViews | flach | 1 | SwRS-048 |
| M047 | Notifications | flach | 1 | SwRS-049 |
| M048 | ObjectExternalReferences | flach | 1 | SwRS-050 |
| M049 | Outlook | flach | 1 | SwRS-051 |
| M050 | PasswordManagementArea | tief | 4 | StRS-005, SyRS-005, SwRS-045, SwRS-046 |
| M051 | PasswordManager | flach | 1 | SwRS-057 |
| M052 | Processes | flach | 1 | SwRS-052 |
| M053 | ProductMatrix | flach | 1 | SwRS-053 |
| M054 | Production | flach | 1 | SwRS-054 |
| M055 | Projects | flach | 1 | SwRS-055 |
| M056 | Purchasing | flach | 1 | SwRS-091 |
| M057 | ReportEngine | flach | 1 | SwRS-058 |
| M058 | Reporting | flach | 1 | SwRS-059 |
| M059 | RiverDivo | mittel | 2 | SwRS-060, SwRS-131 [HYPOTHESE] |
| M060 | Sales | tief | 5 | StRS-007, SyRS-009, SwRS-087, SwRS-088, SwRS-089 |
| M061 | Security | mittel | 2 | SyRS-007, SwRS-085 |
| M062 | SelfCare | flach | 1 | SwRS-061 |
| M063 | Services (BL) | flach | 1 | SwRS-062 |
| M064 | SocialMedia | flach | 1 | SwRS-063 |
| M065 | Start | flach | 1 | SwRS-064 |
| M066 | Statistics | flach | 1 | SwRS-083 |
| M067 | Storage | flach | 1 | SwRS-065 |
| M068 | SystemArea | flach | 1 | SwRS-066 |
| M069 | Tags | flach | 1 | SwRS-067 |
| M070 | Tapi | flach | 1 | SwRS-068 |
| M071 | TaskManager | flach | 1 | SwRS-069 |
| M072 | Telemetry | flach | 1 | SwRS-070 |
| M073 | TextModuleArea | flach | 1 | SwRS-071 |
| M074 | TicketProjects | flach | 1 | SwRS-072 |
| M075 | Time | flach | 1 | SwRS-073 |
| M076 | ToDoArea | flach | 1 | SwRS-074 |
| M077 | Tools | flach | 1 | SwRS-075 |
| M078 | TradePool | flach | 1 | SwRS-076 |
| M079 | Transactions | flach | 1 | SwRS-077 |
| M080 | TwoFactorAuthenticator | flach | 1 | SwRS-078 |
| M081 | Urls | flach | 1 | SwRS-079 |
| M082 | VideoPortal | flach | 1 | SwRS-127 |
| M083 | VoucherManagement | mittel | 2 | SwRS-090, SwRS-129 [HYPOTHESE] |
| M084 | Warehousing | tief | 4 | StRS-006, SyRS-006, SwRS-084, SwRS-128 |
| M085 | WebLinks | flach | 1 | SwRS-080 |
| M086 | WebServices (BL-Fassade) | flach | 1 | SwRS-105 |
| M087 | WebSuite | flach | 1 | SwRS-081 |
| M088 | WebVersion | flach | 1 | SwRS-082 |
| M089 | Centron.DAO | flach | 1 | SwRS-094 |
| M090 | Centron.Entities | flach | 1 | SwRS-095 |
| M091 | Centron.Interfaces | flach | 1 | SwRS-096 |
| M092 | Centron.Common | mittel | 2 | SwRS-012 (SHA1Decoder), SwRS-097 |
| M093 | Centron.Gateway | flach | 1 | SwRS-098 |
| M094 | Centron.WPF.UI | flach | 1 | SwRS-099 |
| M095 | Centron.WPF.UI.Extension | flach | 1 | SwRS-106 |
| M096 | Centron.Controls | flach | 1 | SwRS-100 |
| M097 | Centron.Controls.Preview | flach | 1 | SwRS-107 |
| M098 | Centron.Core (shared) | flach | 1 | SwRS-101 |
| M099 | Centron.WebServices.Core | flach | 1 | SwRS-102 |
| M100 | Centron.Controllers | flach | 1 | SwRS-093 |
| M101 | Centron.Host (Webservice) | flach | 1 | SwRS-108 |
| M102 | Centron.Host.Console / .WindowsService | flach | 1 | SwRS-103 |
| M103 | c-entron.misc.ConnectionManager | flach | 1 | SwRS-104 |
| M104 | CentronNexus – ServiceBoard | flach | 1 | SwRS-109 |
| M105 | CentronNexus – WebCart | flach | 1 | SwRS-117 |
| M106 | CentronNexus – WebOffer | flach | 1 | SwRS-110 |
| M107 | CentronNexus – DocumentSigning | flach | 1 | SwRS-111 |
| M108 | CentronNexus – ProductionOrderManagement | flach | 1 | SwRS-112 |
| M109 | CentronNexus – Office/Shared Documents | flach | 1 | SwRS-113 |
| M110 | CentronNexus – Management | mittel | 2 | SwRS-114, SwRS-133 [HYPOTHESE] |
| M111 | CentronNexus.Host | flach | 1 | SwRS-115 |
| M112 | CentronNexus.OutlookAddIn | flach | 1 | SwRS-116 |
| M113 | Centron.APIs.FinAPI | flach | 1 | SwRS-118 |
| M114 | Centron.APIs.CopDataAccess | mittel | 2 | SwRS-119, SwRS-130 [HYPOTHESE] |
| M115 | Centron.APIs.EgisDataAccess | flach | 1 | SwRS-120 |
| M116 | Centron.APIs.ITscopeDataAccess | flach | 1 | SwRS-121 |
| M117 | Centron.APIs.IcecatDataAccess | flach | 1 | SwRS-122 |
| M118 | Centron.Api.EbInterface | flach | 1 | SwRS-123 |
| M119 | Centron.Api.Gls | flach | 1 | SwRS-124 |
| M120 | Centron.Api.Shipcloud | flach | 1 | SwRS-125 |
| M121 | Centron.Api.docuFORM | flach | 1 | SwRS-126 |
**Summe:** 121 von 121 Modulen mit mindestens einer Anforderung (Mindestabdeckung zu 100 %
erreicht). Tief: 6 Module (Accounting, Administration, Finances, PasswordManagementArea,
Sales, Warehousing). Mittel: 8 Module (Accounts, MassUpdate, RiverDivo, Security,
VoucherManagement, Centron.Common, CentronNexus–Management, Centron.APIs.CopDataAccess).
Flach: 107 Module. Nicht analysiert: 0 Module.
## Schritt 9 – Konsistenzcheck
**Vorgehen:** Automatisierte Prüfung per Volltextsuche über alle drei Spezifikationsdateien.
Insgesamt wurden 151 Anforderungen erstellt: 7 StRS, 9 SyRS, 135 SwRS – davon 6 mit
`Status: HYPOTHESE`.
- **Doppelte oder mehrfach vergebene IDs:** Keine gefunden. Jede der 151 IDs (StRS-001–007,
SyRS-001–009, SwRS-001–135) kommt genau einmal als `ID:`-Zeile vor.
- **Anforderungen ohne Beleg:** Keine gefunden. Jeder der 151 Anforderungsblöcke enthält
mindestens einen Eintrag im Feld `Belege`. Verteilung der Belegklassen: 154× PRIMÄR,
5× SEKUNDÄR, 9× KONTEXT (ein Beleg kann mehrfach klassifiziert vorkommen, da manche
Anforderungen mehrere Belege führen).
- **Anforderungen ohne Angabe zur Übernahmewürdigkeit:** Keine gefunden. Verteilung: 139×
übernehmen, 6× veraltet, 4× Sonderfall, 2× Workaround – Summe 151.
- **Tracelinks auf nicht existierende IDs:** Keine gefunden. Alle in `Tracelinks`-Feldern
referenzierten IDs (StRS-/SyRS-/SwRS-Präfix mit Nummer) wurden gegen die Menge der
tatsächlich vergebenen IDs abgeglichen; es gab keine Referenz außerhalb des vergebenen
Bereichs.
- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk:** 22 Anforderungen
tragen einen expliziten Konsolidierungs-Kandidatenvermerk (u. a. SwRS-019/SwRS-020 zum
Asset-Konzept, SwRS-011/SwRS-114 zum doppelten Rechtemodell, SwRS-119/120/121/122 zu den vier
Produktdatenquellen-Adaptern, SwRS-124/125 zu den zwei Versanddienstleister-Adaptern,
SwRS-057/M050 zum doppelten Passwortmanager-Konzept). Bei der stichprobenartigen
Durchsicht der übrigen 129 Anforderungen wurden keine weiteren, nicht vermerkten
Deckungsgleichheiten identifiziert; angesichts der Breite der Codebasis ist jedoch nicht
auszuschließen, dass eine vollständige paarweise Prüfung aller 151 Anforderungen (nicht
durchgeführt) weitere Kandidaten zutage fördern würde (siehe Selbstbewertung).
### Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung,
Berechtigungen)
| ID | Titel | PRIMÄR-Beleg vorhanden? | Status |
|---|---|---|---|
| StRS-001 | Verwaltung von Kunden-Bankverbindungen mit Berechtigungskontrolle | Ja | belegt |
| StRS-003 | Rollenbasierte Zugriffskontrolle über Rechtegruppen | Ja | belegt |
| StRS-004 | Passwortbasierte Anmeldung mit optionaler Zwei-Faktor-Authentifizierung | Ja | belegt |
| StRS-005 | Sichere Verwaltung von Kunden- und Asset-Zugangsdaten (Passwortmanager) | Ja | belegt |
| StRS-006 | Rechtssichere Fortschreibung von Mehrwertsteuersätzen über Zeit | Ja | belegt |
| StRS-007 | Geschützte Bearbeitung von Belegen mit Filialbindung und Bearbeitungssperre | Ja | belegt |
| SyRS-001 | Rechtebasierte Freigabe von Schreibzugriffen auf Bankverbindungen | Ja | belegt |
| SyRS-002 | Zentraler Rechte-Check-Dienst auf Gruppenbasis | Ja | belegt |
| SyRS-003 | Mehrstufige Anmeldung (Passwort + optionaler zweiter Faktor) | Ja | belegt |
| SyRS-004 | Kryptografisch unzureichendes Passwort-Hashing-Verfahren | Ja | belegt |
| SyRS-005 | Verschlüsselte Passwortspeicherung mit lückenlosem Zugriffsprotokoll | Ja | belegt |
| SyRS-006 | Batchweise, transaktionale Artikel-Steuersatzumstellung | Ja | belegt |
| SyRS-007 | Rechtegeschützte, verschlüsselte Verwaltung des PDF-Signaturzertifikats | Ja | belegt |
| SyRS-008 | Im Quellcode hinterlegte FinAPI-Client-Zugangsdaten | Ja | belegt |
| SyRS-009 | Zweistufige Zugriffskontrolle und Bearbeitungssperre für Verkaufsbelege | Ja | belegt |
| SwRS-001 | Rechteprüfung beim Speichern von Bankverbindungen | Ja | belegt |
| SwRS-011 | SQL-basierter Rechte-Join über Gruppenmitgliedschaft | Ja | belegt |
| SwRS-012 | Unsalted-SHA1-Vergleich beim Anmeldepasswort | Ja | belegt |
| SwRS-013 | Passwortänderung mit Mindestlängen-Prüfung und unsalted-SHA1-Speicherung | Ja | belegt |
| SwRS-014 | Bedingte Zwei-Faktor-Prüfung nach Anwendung/Maschine | Ja | belegt |
| SwRS-045 | Übergebenes Passwort wird nicht gespeichert (Passwortmanager-Defekt) | Ja | belegt |
| SwRS-046 | Lückenlose Zugriffsprotokollierung Passwortmanager | Ja | belegt |
| SwRS-057 | Interner Passwortmanager mit rollenbezogenen Rechten | Ja | belegt |
| SwRS-060 | Konstantzeit-Vergleich für RMM-Zugriffsschlüssel | Ja | belegt |
| SwRS-078 | TOTP-basierte Zweitfaktor-Absicherung des internen Passwortmanagers | Ja | belegt |
| SwRS-084 | Ablehnung der Steuersatzumstellung ohne Folge-Steuer | Ja | belegt |
| SwRS-085 | Verschlüsselte Speicherung des PDF-Signaturzertifikats | Ja | belegt |
| SwRS-086 | Quellcode-Konstanten für FinAPI-Zugangsdaten | Ja | belegt |
| SwRS-087 | Zweistufige Rechteprüfung vor Belegbearbeitung | Ja | belegt |
| SwRS-088 | Pessimistische Bearbeitungssperre bei Belegversionierung | Ja | belegt |
| SwRS-089 | Ausschluss von Web-Konten vom direkten Belegzugriff | Ja | belegt |
| SwRS-090 | Gutschein-Zustandsfilterung | Ja | belegt |
| SwRS-091 | Exportprotokollierung Bestellvorschläge | Ja | belegt |
| SwRS-092 | Fortlaufende Belegnummerierung Zahlungseingang | Ja | belegt |
| SwRS-093 | Deklarative Rechteprüfung auf REST-API-Ebene | Ja | belegt |
| SwRS-101 | Standardkonforme TOTP-Implementierung | Ja | belegt |
| SwRS-114 | Hierarchisches Web-Rechte-Modell für Kundenportal-Konten | Ja (SEKUNDÄR + PRIMÄR) | belegt |
| SwRS-116 | Outlook-Add-in Verzeichnis-Blacklist | Ja | belegt |
| SwRS-126 | PKCE-abgesicherter OAuth-Codeaustausch docuFORM | Ja | belegt |
| SwRS-127 | Rechtegeschützte Video-Portal-Zuweisung | Ja | belegt |
| SwRS-128 | Auskommentierte Eindeutigkeitsprüfung Standard-VAT | Ja | belegt |
| SwRS-129 | Ort der Durchsetzung gegen Mehrfacheinlösung eines Gutscheins | Nein | **HYPOTHESE** |
| SwRS-130 | Speicherform der COP-API-Zugangsdaten | Nein | **HYPOTHESE** |
| SwRS-131 | Sicherheitsauswirkung Ticket-Fallback bei deaktiviertem RMM-Zugang | Nein | **HYPOTHESE** |
| SwRS-132 | Ausschluss fakturierter Belege von Massenpreisänderung | Nein | **HYPOTHESE** |
| SwRS-133 | Konsistenzsicherung zwischen Rechtemodellen | Nein | **HYPOTHESE** |
| SwRS-134 | Alternative Verschlüsselungsstelle Passwortmanager | Nein | **HYPOTHESE** |
**Ergebnis:** Alle 47 risikorelevanten Anforderungen erfüllen die Randbedingung „mindestens
ein PRIMÄR-Beleg, andernfalls zwingend `[HYPOTHESE]`“. Es liegt kein Verstoß gegen die
risikobasierte Priorisierung vor: Die sechs Anforderungen ohne PRIMÄR-Beleg (SwRS-129 bis
SwRS-134) sind durchgängig als `[HYPOTHESE]` markiert.
### Abgleich Hypothesen.md gegen Inline-Markierungen
`Hypothesen.md` führt genau sechs Anforderungen (SwRS-129, SwRS-130, SwRS-131, SwRS-132,
SwRS-133, SwRS-134). Dies stimmt exakt mit den sechs `Status: HYPOTHESE`-Einträgen sowie den
zwölf `[HYPOTHESE]`-Inline-Markierungen (je zwei pro Anforderung, in `Titel` und `Aussage`) in
`SwRS.md` überein. Es existieren keine zusätzlichen freien Fragen in `Hypothesen.md`, die
nicht einer Anforderung zugeordnet sind; darüber hinausgehende offene Punkte werden
ausschließlich in der folgenden Selbstbewertung geführt.
## Schritt 10 – Selbstbewertung
**Tiefenverteilung:** Von 121 Modulen wurden 6 tief (Accounting, Administration, Finances,
PasswordManagementArea, Sales, Warehousing), 8 mittel (Accounts, MassUpdate, RiverDivo,
Security, VoucherManagement, Centron.Common, CentronNexus–Management,
Centron.APIs.CopDataAccess) und 107 flach (Mindestabdeckung) analysiert. Kein Modul blieb
ohne Anforderung. Die Tiefenverteilung ist bewusst extrem breitenlastig: Gemäß Auftrag „Breite geht
vor Tiefe“ wurde zunächst jedes der 121 Module mit mindestens einer belegten Anforderung
versehen, bevor überhaupt vertieft wurde. Die anschließende Vertiefung konzentrierte sich
konsequent auf die im Auftrag genannten Risikobereiche: Sicherheitsregeln (Passwort-Hashing,
Rechtemodell, Zwei-Faktor-Authentifizierung, PDF-Signatur), Abrechnungs-/Fakturierungslogik
(Mehrwertsteuer-Fortschreibung, Zahlungseingang, Online-Banking-Anbindung, Beleg-Zugriffsschutz)
und Berechtigungsprüfungen (Gruppenrechte, Web-Konto-Rechte, Filialbindung).
**Mindestabdeckung:** Ja, vollständig erreicht – alle 121 Module des Inventars aus Schritt 0
tragen mindestens eine belegte Anforderung (siehe Abdeckungstabelle, Schritt 8). Kein Modul
musste als „nicht analysiert“ geführt werden.
**Dünne Belegstellen:** Der Anteil PRIMÄR-Belege ist mit 154 von insgesamt 168 Einzelbelegen
(91,7 %) hoch, deutlich höher als im Vorgänger-Datensatz (78,6 % über 24 Läufe). Das ist eine
bewusste Folge der gewählten Strategie: Es wurden überwiegend Anforderungen geschrieben, für
die eine konkrete, im Code direkt sichtbare durchsetzende Stelle (Methode, Bedingung,
SQL-Statement) gefunden wurde; wo das nicht gelang, wurde entweder keine Anforderung verfasst
oder eine Hypothese formuliert (6 Fälle, siehe Hypothesen.md). Dünner belegt sind die zehn
Anforderungen mit SEKUNDÄR- oder KONTEXT-Anteil (u. a. StRS-002 zu Account-Stammdaten, StRS-003
mit SEKUNDÄR-Aufrufstellenbeleg, SyRS-004/SwRS-012 mit KONTEXT-Kommentarbeleg zur bekannten
Passwort-Schwachstelle) sowie naturgemäß die sechs Hypothesen, die ausschließlich
KONTEXT-Belege (Negativbefunde) tragen.
**Warum nicht null Hypothesen:** Sechs Hypothesen wurden geführt (4,0 % der 151
Anforderungen). Bei einer Codebasis dieser Größe (backend, centron, nexus, webservice, shared,
apis – mehrere zehntausend Dateien) ist eine vollständige Klärung aller Detailfragen allein
durch statische Lektüre nicht möglich; insbesondere Datenbank-Trigger/-Prozeduren außerhalb des
eingesehenen C#-Quellcodes, sowie sehr große Einzeldateien wie `ReceiptBL.cs` (11.441 Zeilen),
die nicht vollständig durchsucht wurden, sind Quellen genau der Art von Unsicherheit, die die
sechs geführten Hypothesen abbilden.
**Erkenntnisse für eine Folgeiteration:**
1. `ReceiptBL.cs` (Sales/Receipts, 11.441 Zeilen) wurde nur in Ausschnitten (Locking,
Rechteprüfung) untersucht und verdient als zentrale Belegverarbeitung eine eigene,
mehrtägige Vertiefungsiteration – insbesondere Statusübergänge (Angebot→Auftrag→Rechnung),
Stornologik und die tatsächliche Gutschein-/Rabattverbuchung (siehe SwRS-129 [HYPOTHESE]).
2. Die identifizierten Sicherheitsschwächen (SwRS-012/013 unsalted SHA1; SwRS-045 defekte
Passwort-Verschlüsselung; SwRS-086 hartcodierte FinAPI-Zugangsdaten; SwRS-128 deaktivierte
VAT-Eindeutigkeitsprüfung) sollten in einer Folgeiteration systematisch nach weiteren
Vorkommen desselben Musters (z. B. weitere unsalted-Hash-Stellen, weitere auskommentierte
Prüfungen) durchsucht werden – die hier gefundenen Stellen wurden opportunistisch beim
Lesen angrenzenden Codes entdeckt, nicht durch eine gezielte Suche nach diesem Muster.
3. Das parallel geführte interne Gruppen-Rechte-Modell (Sichtrus/Sichmemb) und das
Web-Konto-Rechte-Modell (WebAccountsRights, WebRightNode) sollten auf tatsächliche
Konsistenzmechanismen hin untersucht werden (SwRS-133 [HYPOTHESE]).
4. Die vier strukturell ähnlichen externen Produktdatenquellen-Adapter (COP, EGIS, ITscope,
Icecat) und die zwei Versanddienstleister-Adapter (GLS, Shipcloud) sind als
Konsolidierungskandidaten markiert, aber nicht im Detail auf abweichendes fachliches
Verhalten (z. B. unterschiedliche Preislogik) untersucht worden.
5. Von den 106 „flach“ eingestuften Modulen wurde jeweils nur ein repräsentativer Aspekt
erfasst; eine Folgeiteration könnte gezielt die Module mit der größten Dateizahl
(Administration: 959 Dateien – bereits vertieft; WebServices: 464 Dateien; Sales: 248
Dateien – teilweise vertieft) auf weitere, bisher nicht erfasste Anforderungen hin
durchsuchen, insbesondere die Fassadenschicht `Centron.BL/WebServices`, die hier nur mit
einer Anforderung (SwRS-105, ObjectMapper) abgedeckt ist.
6. Die Konsistenzprüfung auf deckungsgleiche Anforderungen erfolgte stichprobenartig, nicht als
vollständiger paarweiser Vergleich aller 151 Anforderungen; eine automatisierte
Ähnlichkeitsanalyse (z. B. über die Felder `Aussage` und `Fakt`) könnte in einer
Folgeiteration weitere Konsolidierungskandidaten über die 22 bereits markierten hinaus
aufdecken.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/Ergebnisse/Glossar.md
+36
View File
@@ -0,0 +1,36 @@
# Glossar
Domänenbegriffe, die in StRS.md, SyRS.md und SwRS.md verwendet werden. Technische Bezeichner
(Klassen-, Methoden-, Spaltennamen) sind in ihrer Originalsprache belassen und hier nur
erläutert, soweit sie fachliche Bedeutung tragen.
| Begriff | Bedeutung |
|---|---|
| **I3D** | Primärschlüsselfeld, das in praktisch allen Centron-Entitäten als eindeutige numerische Objekt-ID verwendet wird (z. B. `AppUser.I3D`, `BankAccount.I3D`). Der Name ist historisch und wird durchgängig als Bezeichner für „Datenbank-ID eines Objekts“ verwendet. |
| **Account** | Zentrale Geschäftspartner-Entität, die sowohl Kunden als auch Lieferanten abbildet (`Centron.BL/Accounts`). Ein Account kann mehrere Adressen, Kontakte und Kostenstellen besitzen. |
| **Beleg (Receipt)** | Sammelbegriff für Angebot, Auftrag, Rechnung, Gutschrift u. ä. im Vertriebsprozess (`Centron.BL/Sales/Receipts`, Klasse `ReceiptBL`). Nicht zu verwechseln mit „Artefaktbeleg“ im Sinne dieser Spezifikation (Nachweis für eine Anforderung). |
| **AppUser** | Interner Benutzer-Account (Mitarbeiter-Login) des Desktop-Clients bzw. der internen Anwendung, im Unterschied zum **WebAccount** (Kundenportal-Konto). |
| **WebAccount** | Zugangskonto für externe Nutzer (Kunden) im Webportal CentronNexus, mit eigenem Rechtemodell (`WebAccountsRights`), getrennt vom internen `AppUser`-Rechtemodell (`Sichtrus`/`Sichmemb`). |
| **Sichtrus / Sichmemb** | Legacy-Datenbanktabellen des internen Gruppen-Rechte-Modells: `Sichmemb` verknüpft Benutzer mit Gruppen, `Sichtrus` verknüpft Gruppen mit Rechten (`AppRight`). Zugriffsrechte eines Benutzers ergeben sich aus der Vereinigung der Rechte all seiner Gruppen. |
| **AppRight / UserRightsConst** | Einzelnes, im System vergebbares Recht (z. B. `CREATE_NEW_Bank_Account`). `UserRightsConst` bündelt die im Code referenzierten Rechte-IDs als Konstanten. |
| **Filiale (Branch)** | Organisatorische Einheit eines Mandanten (`BranchI3D`), auf die Bearbeitungsrechte eingeschränkt werden können (z. B. „Belege nur der eigenen Filiale bearbeiten“). |
| **Mandant** | Eine rechtlich/organisatorisch abgegrenzte Instanz des Systems (Kunde des Softwareherstellers), i. d. R. mit eigener Datenbank/Konfiguration. |
| **RMA** | Return Merchandise Authorization – Retourenvorgang für zurückgesandte Artikel, verwaltet in `Centron.BL/CustomerArea/RmaBL`, zwingend mit einem Helpdesk-Ticket verknüpft. |
| **Helpdesk / Ticket** | Zentrale Vorgangseinheit für Support-, Reparatur- und Serviceprozesse; viele Module (RMA, Chats, Social Media, ServiceBoard) referenzieren ein Ticket über `HelpdeskI3D`. |
| **EDI** | Electronic Data Interchange – automatisierter, strukturierter Datenaustausch mit Lieferanten/Distributoren (Bestellungen, Rechnungen) in distributorspezifischen XML-Formaten. |
| **Distributor** | Vorlieferant/Großhändler, von dem Artikel bezogen werden (z. B. ALSO, Komsa, EGIS, Alltron). |
| **Stammblatt** | Historischer Begriff für die Verwaltung von Druckern als eigene Datenhaltung in `Sales/CustomerAssets`, fachlich verwandt mit dem allgemeineren **Asset**-Begriff aus `DocuBoard`/`Devices` (siehe Konsolidierungshinweis in Analysebericht.md). |
| **Asset** | Sammelbegriff für beim Kunden betriebene Hardware/Ausstattung, in der untersuchten Codebasis uneinheitlich als „Stammblatt“ (Drucker), „Device“ (Devices-Modul) oder „AssetManagement“-Eintrag (DocuBoard) geführt. |
| **Voucher (Gutschein)** | Wertdokument mit Barcode und Zustand frei/ausgegeben/eingelöst (`Centron.BL/VoucherManagement`). |
| **VAT / Mehrwertsteuer-Kette** | Steuersatz (`ValueAddedTax`), der über `NextTaxRate` mit seinem zeitlichen Nachfolger verkettet ist, um Gesetzesänderungen rückwirkend nachvollziehbar abzubilden. |
| **Rechte-Check (CheckRightsFromUser)** | Zentrale, code-durchgesetzte Prüfroutine, die anhand der Gruppenmitgliedschaft eines Benutzers ermittelt, welche der angefragten Rechte er besitzt. |
| **TOTP** | Time-based One-Time Password – zeitbasiertes Einmalpasswort nach RFC 6238, in `Centron.Core/TotpAuth` implementiert und u. a. für den internen Passwortmanager als zweiter Faktor genutzt. |
| **PKCE** | Proof Key for Code Exchange – Erweiterung des OAuth-2.0-Autorisierungscode-Flows, die den Codeaustausch gegen Abfangen absichert (verwendet bei der docuFORM-Anbindung). |
| **DocuFORM / docuFORM** | Externer Dienst zur Formular-/Dokumentenerstellung, angebunden über `Centron.Api.docuFORM`. |
| **CentronNexus** | Browser-/Blazor-basiertes Webportal, das Agentenoberfläche (ServiceBoard), Kundenportal (WebCart, WebOffer), Dokumentensignatur und weitere webbasierte Funktionen bündelt – der primäre Ansatzpunkt für die geplante Web-/SaaS-Neuimplementierung. |
| **ServiceBoard** | Agenten-Arbeitsoberfläche innerhalb von CentronNexus (Ticket-Kanban, Telefonie, Zeiterfassung). |
| **WebCart** | Kundenportal-Bereich innerhalb von CentronNexus für Web-Shop, Vertragsübersicht und Ticket-Self-Service. |
| **BL / DAO** | Business Logic (Geschäftslogikschicht, `Centron.BL`) bzw. Data Access Object (Datenzugriffsschicht, `Centron.DAO`, NHibernate-basiert) – die beiden zentralen Architekturschichten der Desktop-/Webservice-Anwendung. |
| **LoggedInUser / AppUser (Kontext)** | Laufzeit-Kontextobjekt des aktuell angemeldeten Benutzers, das u. a. bei Rechteprüfungen und Protokollierung durchgereicht wird. |
| **CentronObjectKindNumeric** | Enum zur typunabhängigen Identifikation eines Centron-Objekts (z. B. Kunde, Ticket, Beleg) über eine numerische Art-Kennung, u. a. genutzt für generische Objektreferenzen (`ObjectExternalReference`, `ToDo`). |
| **PRIMÄR / SEKUNDÄR / KONTEXT** | Belegklassifikation dieser Spezifikation selbst: PRIMÄR = durchgesetzte Regel im Code/DB-Constraint, SEKUNDÄR = UI-Text/Konfiguration, KONTEXT = Kommentar/Commit/Ticket. Siehe Auftragsbeschreibung. |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/Ergebnisse/Hypothesen.md
+33
View File
@@ -0,0 +1,33 @@
# Hypothesen
Diese Datei listet ausschließlich die Anforderungen, die im Anforderungsbestand mit
`Status: HYPOTHESE` geführt werden. Die Liste ist deckungsgleich mit den Inline-Markierungen
`[HYPOTHESE]` in `SwRS.md` (siehe Konsistenzcheck in `Analysebericht.md`). Offene Fragen ohne
zugehörige Anforderung werden nicht hier, sondern in der Selbstbewertung von
`Analysebericht.md` geführt.
Sechs Hypothesen wurden im Rahmen dieser Iteration identifiziert. Vier davon betreffen
risikorelevante Bereiche (Abrechnung/Gutscheine, Sicherheit/Zugangsdaten, Berechtigungen) und
sind entsprechend der Randbedingung „ohne PRIMÄR-Beleg zwingend als [HYPOTHESE] zu
kennzeichnen“ konsequent so geführt, auch wenn ein KONTEXT- bzw. Negativbefund als Anlass
vorliegt.
| ID | Titel | Offene Frage (was fehlt zur Bestätigung) |
|---|---|---|
| SwRS-129 | Ort der Durchsetzung gegen Mehrfacheinlösung eines Gutscheins | Es fehlt eine gefundene schreibende Methode, die den Einlösezustand eines Gutscheins setzt und dabei bereits erfolgte Einlösung ausschließt. Die vermutete Stelle (`ReceiptBL`, 11.441 Zeilen) wurde in dieser Iteration nicht vollständig auf artikelspezifische Gutschein-Sonderlogik durchsucht. |
| SwRS-130 | Speicherform der COP-API-Zugangsdaten in der Konfiguration | Es fehlt die Rückverfolgung von `CopApi`-Konstruktorparametern bis zur tatsächlichen Konfigurationsspeicherung (verschlüsselt vs. Klartext), die im Rahmen dieser Iteration nicht durchgeführt wurde. |
| SwRS-131 | Sicherheitsauswirkung des Ticket-Fallbacks bei deaktiviertem RMM-Zugang | Es fehlt die Bestätigung, ob die Riverbird-Ticketvalidierung bei administrativ deaktiviertem RMM-Zugang (`IsEnabled=false`) ebenfalls verweigert wird oder unabhängig davon weiterhin Zugriff gewährt. |
| SwRS-132 | Ausschluss bereits fakturierter Belege von der Massenpreisänderung | Es fehlt die Prüfung der vollständigen Implementierung von `MassUpdateBL.SearchForReceiptUpdateItems`/`StartReceiptPriceUpdate` auf einen Statusfilter, der bereits fakturierte/abgeschlossene Belege ausschließt. |
| SwRS-133 | Konsistenzsicherung zwischen internem Gruppen-Rechte-Modell und Web-Konto-Rechten | Es fehlt ein gefundener Synchronisationsmechanismus zwischen `Sichtrus`/`Sichmemb` (interne Mitarbeiterrechte) und `WebAccountsRights` (Web-Konto-Rechte); ob beide Modelle bewusst unabhängig geführt werden, ist unklar. |
| SwRS-134 | Alternative Verschlüsselungsstelle für Passwortmanager-Einträge | Es fehlt der Einblick in Datenbank-Trigger/-Prozeduren außerhalb des eingesehenen C#-Quellcodes, die den in SwRS-045 beschriebenen Befund (verworfenes Passwort in `AddNewKeyword`) relativieren könnten. |
## Einordnung
Die vergleichsweise geringe Zahl von sechs Hypothesen bei 150 Anforderungen (4,0 %) ist eine
bewusste Folge der gewählten Belegstrategie: Statt bei jeder unsicheren Beobachtung sofort eine
Hypothese zu bilden, wurde in dieser Iteration konsequent nur zu Aussagen übergegangen, sobald
eine konkrete, benennbare Codestelle als Beleg vorlag (siehe Belegpflicht). Wo keine belegbare
Aussage möglich war, wurde die Anforderung entweder nicht geschrieben oder – bei
risikorelevantem Bezug – als Hypothese mit klar benannter fehlender Information geführt. Die
Selbstbewertung in `Analysebericht.md` ordnet diese Zahl zusätzlich ein und benennt weitere,
nicht in Anforderungsform gegossene offene Punkte für eine Folgeiteration.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/Ergebnisse/StRS.md
+251
View File
@@ -0,0 +1,251 @@
# Stakeholder Requirements Specification (StRS)
ISO/IEC/IEEE 29148:2018 – Reverse Requirements Engineering c-entron ERP-Suite.
Fachliche Sicht: Akteure, Geschäftsziele, Stakeholder-Bedürfnisse. Abgeleitet aus statischer
Codeanalyse (keine Ausführung). Siehe `Analysebericht.md` für Modulinventar und Methodik,
`Glossar.md` für Domänenbegriffe, `Hypothesen.md` für alle `[HYPOTHESE]`-Markierungen.
---
```
ID: StRS-001
Titel: Verwaltung von Kunden-Bankverbindungen mit Berechtigungskontrolle
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Sachbearbeiter (Vertrieb/Buchhaltung), Kunde (Objekt)
Vorbedingung: Ein Kundendatensatz existiert; der Sachbearbeiter ist angemeldet.
Fakt: `BankAccountBL.SaveBankAccount` prüft vor dem Anlegen bzw. Ändern einer
`BankAccount` die Rechte `CREATE_NEW_Bank_Account` bzw. `EDIT_Bank_Account`
des angemeldeten Benutzers und bricht mit `RightCheckFailed` ab, wenn das
Recht fehlt (Accounting/BankAccountBL.cs:66-82).
Aussage: Das System soll das Anlegen und Ändern von Bankverbindungen eines Kunden nur
Benutzern mit explizit zugewiesenem Recht gestatten, um Zahlungsverkehrsdaten
vor unautorisierter Änderung zu schützen.
Ergebnis: Bankverbindung wird nur bei vorhandenem Recht gespeichert; sonst Fehlermeldung
mit Rechtehinweis.
Belege:
- [PRIMÄR] Centron.BL/Accounting/BankAccountBL.cs, Methode SaveBankAccount, Zeilen 71-82 -
Begründung: Die Methode ist die einzige Schreibstelle für Bankverbindungen und
erzwingt die Rechteprüfung vor jedem Persistieren.
- [SEKUNDÄR] UserRightsConst.Sales.Customer.CustomerFinance.CREATE_NEW_Bank_Account /
EDIT_Bank_Account - Begründung: Benennt die konkreten Rechte-Konstanten, die im
Administrationsmodul als vergebbare Rechte geführt werden.
Prüfidee: Benutzer ohne die beiden Rechte versucht, eine neue Bankverbindung zu einem
Kunden anzulegen; erwartet wird `Result.AsError` mit Code `RightCheckFailed`
und keine Persistierung.
Tracelinks: SyRS-001, SwRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Rechtebasierte Kontrolle sensibler Zahlungsdaten ist eine
dauerhaft gültige fachliche Anforderung.
Status: belegt
```
```
ID: StRS-002
Titel: Zentrale Kunden- und Lieferanten-Stammdatenverwaltung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertriebsmitarbeiter, Einkäufer
Vorbedingung: Zugriff auf das CRM-Modul ist eingerichtet.
Fakt: `Centron.BL/Accounts` enthält eigenständige BL-Klassen für Adressen
(`AccountAddressBL`), Adresskontakte (`AccountAddressContactBL`), Kontotypen
(`AccountTypeBL`), Kundenkostenstellen (`CustomerCostCenterBL`) sowie
Unterordner `Campaigns`, `Marketing`, `SpecialPrices`, `HotlineArea`.
Aussage: Das System soll Kunden und Lieferanten als gemeinsame „Account“-Entität mit
mehreren Adressen, Kontakten, Kostenstellen und Sonderpreisen zentral verwalten.
Ergebnis: Ein Account-Datensatz bündelt alle adress-, kontakt- und konditionsbezogenen
Informationen eines Geschäftspartners.
Belege:
- [PRIMÄR] Centron.BL/Accounts/AccountBL.cs, AccountAddressBL.cs, AccountTypeBL.cs -
Begründung: Eigenständige Klassen mit CRUD-Methoden für die jeweiligen
Teilaspekte der Account-Entität belegen deren Modellierung im Code.
- [SEKUNDÄR] Ordnerstruktur Centron.BL/Accounts/{Campaigns,Marketing,SpecialPrices,
HotlineArea} - Begründung: Zeigt die fachlichen Zusatzfunktionen, die an
Accounts hängen.
Prüfidee: Für einen Account werden mehrere Adressen und ein Sonderpreis angelegt; beide
müssen über den Account referenzierbar sein.
Tracelinks: SwRS-002
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernstammdatenmodell des ERP.
Status: belegt
```
```
ID: StRS-003
Titel: Rollenbasierte Zugriffskontrolle über Rechtegruppen
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Systemadministrator, alle angemeldeten Benutzer
Vorbedingung: Benutzer ist einer oder mehreren Rechtegruppen zugeordnet.
Fakt: `AppRightsBL.CheckRightsFromUser` prüft per Rohtext-SQL-Join zwischen den
Tabellen `Sichmemb` (Gruppenmitgliedschaft) und `Sichtrus` (Gruppe-zu-Recht-
Zuordnung), ob ein Benutzer eines der übergebenen Rechte über seine
Gruppenmitgliedschaft besitzt (Administration/Rights/AppRightsBL.cs:88-110).
Diese Methode wird u. a. von `BankAccountBL.SaveBankAccount` aufgerufen (siehe
StRS-001).
Aussage: Das System soll den Zugriff auf geschützte Operationen ausschließlich über die
Mitgliedschaft eines Benutzers in Rechtegruppen steuern; einzelnen Benutzern
werden keine direkten Rechte zugewiesen, sondern nur über Gruppen.
Ergebnis: Ein Benutzer erhält Zugriff auf eine geschützte Funktion genau dann, wenn
mindestens eine seiner Gruppen das erforderliche Recht besitzt.
Belege:
- [PRIMÄR] Centron.BL/Administration/Rights/AppRightsBL.cs, CheckRightsFromUser,
Z. 92-109 - Begründung: Zentrale, code-durchgesetzte Prüfstelle, deren SQL
explizit den Gruppen-zu-Recht-Mechanismus umsetzt.
- [SEKUNDÄR] Aufrufstelle Centron.BL/Accounting/BankAccountBL.cs:71 - Begründung: Belegt die
produktive Nutzung des Mechanismus in einem Fachmodul.
Prüfidee: Benutzer wird einer Gruppe mit Recht X zugeordnet; CheckRightsFromUser(user, [X])
muss X enthalten. Nach Entfernen aus der Gruppe muss das Ergebnis leer sein.
Tracelinks: SyRS-002, SwRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Gruppenbasierte Rechtevergabe ist ein tragfähiges,
fortzuführendes Sicherheitskonzept.
Status: belegt
```
```
ID: StRS-004
Titel: Passwortbasierte Anmeldung mit optionaler Zwei-Faktor-Authentifizierung
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Benutzer (Desktop-Client, Webservice-Client)
Vorbedingung: Benutzerkonto mit Benutzername und Passwort existiert; System-Authentifizierungs-
methode ist auf „Standard“ (nicht AD/OpenID) konfiguriert.
Fakt: `BasicAuthenticator.AuthenticateInternal` vergleicht das übergebene Passwort
gehasht mit dem gespeicherten `AppUser.Password` und ruft anschließend, sofern
`TwoFactorAuthEnabled` und `UseTwoFactorAuthentication` gesetzt sind,
`TwoFactorAuthBL.ValidateTwoFactor` auf (Administration/Logins/Auth/
BasicAuthenticator.cs:35-71; Administration/Logins/TwoFactor/
TwoFactorAuthBL.cs:33-82).
Aussage: Das System soll Benutzer über Benutzername und Passwort authentifizieren und je
nach Systemkonfiguration sowie Benutzereinstellung eine zusätzliche
Zwei-Faktor-Prüfung (E-Mail oder RADIUS) verlangen.
Ergebnis: Anmeldung gelingt nur bei korrektem Passwort und – falls aktiviert –
erfolgreicher Zweitfaktor-Prüfung.
Belege:
- [PRIMÄR] Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Z. 35-71 -
Begründung: Enthält die konkrete Vergleichs- und Ablehnungslogik der Anmeldung.
- [PRIMÄR] Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs,
ValidateTwoFactor, Z. 33-82 - Begründung: Durchsetzende Stelle für die
bedingte Zweitfaktor-Pflicht.
Prüfidee: Anmeldung mit korrektem Passwort und aktivierter Zwei-Faktor-Pflicht ohne
gültigen Zweitfaktor muss mit `TwoFactorAuthFailed` abgelehnt werden.
Tracelinks: SyRS-003, SyRS-004, SwRS-012, SwRS-013, SwRS-014
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Anmeldeprozess mit optionalem zweiten Faktor bleibt
fachlich erforderlich; das zugrunde liegende Hash-Verfahren ist jedoch laut
SwRS-012 zu erneuern.
Status: belegt
```
```
ID: StRS-005
Titel: Sichere Verwaltung von Kunden- und Asset-Zugangsdaten (Passwortmanager)
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Support-Mitarbeiter
Vorbedingung: Ein Kunde/Asset benötigt hinterlegte Zugangsdaten (z. B. Router-, System-
Zugangsdaten).
Fakt: `PasswordManagementBL`/`PasswordManagementKeywordBL` bilden ein eigenes
Modul zur Speicherung von Zugangsdaten je Kunde/Asset mit
Zugriffsprotokoll (`PasswordManagementAccessLogBL`); die vorgesehenen Felder
`Salt` und `Password` legen eine gesalzene Verschlüsselung nahe
(PasswordManagementArea/PasswordManagementBL.cs,
PasswordManagementKeywordBL.cs:21-59).
Aussage: Das System soll Zugangsdaten zu Kunden-Assets verschlüsselt und mit
vollständiger Zugriffsprotokollierung speichern, damit sensible Drittsystem-
Zugangsdaten (z. B. Router-Passwörter) nicht im Klartext vorliegen.
Ergebnis: Gespeichertes Passwort ist nur über eine protokollierte Entschlüsselungs-
Operation im Klartext abrufbar.
Belege:
- [PRIMÄR] Centron.BL/PasswordManagementArea/PasswordManagementKeywordBL.cs,
GetDecryptedKeywordById, AddNewKeyword, Z. 21-59 - Begründung: Zeigt den
vorgesehenen Verschlüsselungs-/Protokollierungs-Mechanismus.
Prüfidee: Zugangsdaten anlegen und abrufen; jeder Abruf muss einen Eintrag in
PasswordManagementAccessLog erzeugen.
Tracelinks: SyRS-005, SwRS-045, SwRS-046
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - fachliche Notwendigkeit bleibt; siehe SwRS-045 für einen
konkreten Implementierungsmangel, der im Zielsystem zu beheben ist.
Status: belegt
```
```
ID: StRS-006
Titel: Rechtssichere Fortschreibung von Mehrwertsteuersätzen über Zeit
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung, Systemadministrator
Vorbedingung: Ein Mehrwertsteuersatz läuft aus (Gesetzesänderung) und hat eine hinterlegte
Folge-Steuer.
Fakt: `TaxBL.GetActiveVatThroughNextVats` verkettet `ValueAddedTax.NextTaxRate`
so lange, bis ein zum Stichtag gültiger Satz gefunden wird;
`UpdateArticleVATs` verweigert die Umstellung, wenn keine Folge-Mehrwertsteuer
hinterlegt ist, und aktualisiert andernfalls alle betroffenen Artikel
batchweise (2000 Datensätze je Batch), optional inklusive Bruttopreis-
Neuberechnung (Warehousing/TaxBL.cs:44-138).
Aussage: Das System soll Mehrwertsteuersätze als verkettete Zeitreihe
(Vorgänger/Nachfolger) verwalten und beim Übergang zu einem neuen Satz
zwingend eine hinterlegte Folge-Steuer voraussetzen, um alle betroffenen
Artikel konsistent umzustellen.
Ergebnis: Kein Artikel bleibt nach einer Steuersatzänderung mit dem alten, abgelaufenen
Satz verknüpft; Umstellung ohne definierte Folge-Steuer wird abgelehnt.
Belege:
- [PRIMÄR] Centron.BL/Warehousing/TaxBL.cs, UpdateArticleVATs, Z. 95-101 - Begründung:
Explizite Ablehnung bei fehlender Folge-Steuer als durchsetzende Stelle.
- [PRIMÄR] Centron.BL/Warehousing/TaxBL.cs, GetActiveVatThroughNextVats, Z. 44-55 -
Begründung: Zeigt die Verkettungslogik zur Ermittlung des gültigen Satzes.
Prüfidee: UpdateArticleVATs für einen VAT-Satz ohne NextTaxRate muss mit Fehlermeldung
abgelehnt werden, ohne dass ein Artikel verändert wird.
Tracelinks: SyRS-006, SwRS-084
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Gesetzlich vorgeschriebene Steuersatzpflege bleibt
fachlich zwingend erforderlich.
Status: belegt
```
```
ID: StRS-007
Titel: Geschützte Bearbeitung von Belegen (Angebote/Aufträge/Rechnungen) mit
Filialbindung und Bearbeitungssperre
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Vertriebsmitarbeiter, Buchhaltung
Vorbedingung: Ein Beleg (Angebot, Auftrag, Rechnung, Gutschrift o. ä.) existiert.
Fakt: `ReceiptBL.CanUserEditReceipt` prüft ein belegtyp-spezifisches
Bearbeitungsrecht sowie optional eine Filialbindung
(`HasRightToEditReceiptOnlyOwnBranch`); `CanUserViewReceipt` verweigert
Web-Konten grundsätzlich die Anzeige von Belegen; `CreateNewVersion`
sperrt einen Beleg während der Bearbeitung gegen gleichzeitige Änderung durch
andere Benutzer (`TryLockReceipt`/`UnLockReceipt`)
(Sales/Receipts/ReceiptBL.cs:3081-3096, 10272-10307).
Aussage: Das System soll die Bearbeitung von Belegen nur Benutzern mit
belegtyp-spezifischem Recht erlauben, optional auf die eigene Filiale des
Benutzers beschränken, Web-Portal-Konten grundsätzlich von der Beleganzeige
ausschließen und parallele Bearbeitung desselben Belegs durch mehrere Benutzer
durch eine Bearbeitungssperre verhindern.
Ergebnis: Ein Beleg kann zu einem Zeitpunkt nur von einem Benutzer bearbeitet werden;
Benutzer ohne passendes Recht oder falscher Filiale wird abgewiesen.
Belege:
- [PRIMÄR] Centron.BL/Sales/Receipts/ReceiptBL.cs, CanUserEditReceipt, Z. 10272-10294 -
Begründung: Durchsetzende zweistufige Rechteprüfung (Typ + Filiale).
- [PRIMÄR] Centron.BL/Sales/Receipts/ReceiptBL.cs, CanUserViewReceipt, Z. 10296-10307 -
Begründung: Explizite Sperre für Web-Konten.
- [PRIMÄR] Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateNewVersion, Z. 3081-3096 -
Begründung: Durchsetzende Sperrlogik gegen Parallelbearbeitung.
Prüfidee: Zwei Benutzer öffnen denselben Beleg gleichzeitig zur Bearbeitung; der zweite
muss `ReceiptIsLockedFromOtherUser=true` erhalten.
Tracelinks: SyRS-009, SwRS-087, SwRS-088, SwRS-089
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Zugriffsschutz und Bearbeitungssperre für
Finanzbelege sind zwingend fortzuführen.
Status: belegt
```
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/Ergebnisse/SwRS.md
+3841
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/Ergebnisse/SyRS.md
+304
View File
@@ -0,0 +1,304 @@
# System Requirements Specification (SyRS)
ISO/IEC/IEEE 29148:2018 – Reverse Requirements Engineering c-entron ERP-Suite.
Systemsicht: Systemverhalten, Schnittstellen, Performance- und Sicherheitsanforderungen.
Siehe `Analysebericht.md` für Modulinventar und Methodik, `Glossar.md` für Domänenbegriffe,
`Hypothesen.md` für alle `[HYPOTHESE]`-Markierungen.
---
```
ID: SyRS-001
Titel: Rechtebasierte Freigabe von Schreibzugriffen auf Bankverbindungen
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Systemkomponente Accounting/BankAccount
Vorbedingung: Ein Benutzer ist angemeldet und versucht, eine Bankverbindung anzulegen oder zu
ändern.
Fakt: `BankAccountBL.SaveBankAccount` ruft vor jeder Persistierung
`AppRightsBL.CheckRightsFromUser` mit operationsspezifischer Rechte-ID auf und
verweigert bei fehlendem Recht die Ausführung (Accounting/BankAccountBL.cs:71-82).
Aussage: Das System soll jede schreibende Operation auf Bankverbindungsdaten serverseitig
gegen die Berechtigungen des angemeldeten Benutzers prüfen, unabhängig vom
aufrufenden Client (Desktop oder Web).
Ergebnis: Schreibversuche ohne passendes Recht werden serverseitig abgelehnt.
Belege:
- [PRIMÄR] Centron.BL/Accounting/BankAccountBL.cs, Z. 71-82 - Begründung: Serverseitige,
nicht client-umgehbare Prüfstelle.
Prüfidee: Direkter Aufruf von SaveBankAccount über die BL-Schicht (unter Umgehung der
UI) mit einem rechtelosen Benutzer muss dieselbe Ablehnung liefern wie über UI.
Tracelinks: StRS-001, SwRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-002
Titel: Zentraler Rechte-Check-Dienst auf Gruppenbasis
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Alle fachlichen Systemkomponenten (BL-Schicht)
Vorbedingung: Ein Fachmodul verlangt vor einer Operation eine Rechteprüfung.
Fakt: `AppRightsBL.CheckRightsFromUser(appUserI3D, rightI3Ds)` ist die einzige im
Code identifizierte zentrale Prüfroutine, die per SQL-Join über `Sichmemb` und
`Sichtrus` ermittelt, welche der angefragten Rechte der Benutzer über seine
Gruppen besitzt; sie wird u. a. aus dem Accounting-Modul heraus genutzt
(Administration/Rights/AppRightsBL.cs:92-109).
Aussage: Das System soll allen Fachmodulen einen einheitlichen, zentralen Dienst zur
Rechteprüfung auf Basis der Gruppenmitgliedschaft eines Benutzers bereitstellen,
damit Berechtigungslogik nicht modulspezifisch dupliziert wird.
Ergebnis: Jede Rechteprüfung im System nutzt denselben Gruppen-Recht-Mechanismus mit
konsistentem Ergebnis.
Belege:
- [PRIMÄR] Centron.BL/Administration/Rights/AppRightsBL.cs, Z. 92-109 - Begründung:
Konkrete SQL-Implementierung der durchsetzenden Stelle.
Prüfidee: Zwei unterschiedliche Module rufen CheckRightsFromUser mit demselben Benutzer
und Recht auf; Ergebnis muss identisch sein.
Tracelinks: StRS-003, SwRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Zentralisierung ist ein migrationswürdiges Architekturmuster;
die SQL-nahe Implementierung selbst sollte im Zielsystem durch eine
ORM-/Service-Abstraktion ersetzt werden.
Status: belegt
```
```
ID: SyRS-003
Titel: Mehrstufige Anmeldung (Passwort + optionaler zweiter Faktor)
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Anmeldedienst (Authenticator-Schicht)
Vorbedingung: Ein Client sendet Benutzername und Passwort an den Anmeldedienst.
Fakt: `AuthenticatorFactory`/`BasicAuthenticator` implementieren eine
Authenticator-Hierarchie (Basic, ActiveDirectory, OpenIdConnect, WebAccount,
Fallback), wobei `BasicAuthenticator.AuthenticateInternal` nach erfolgreicher
Passwortprüfung zusätzlich `TwoFactorAuthBL.ValidateTwoFactor` aufruft, das
anhand `WebServiceConfigHelper.Current.TwoFactorAuthEnabled` und
`TwoFactorUser.UseTwoFactorAuthentication` entscheidet, ob ein zweiter Faktor
(E-Mail-Code oder RADIUS) verlangt wird (Administration/Logins/Auth/
BasicAuthenticator.cs:35-71; Administration/Logins/TwoFactor/
TwoFactorAuthBL.cs:33-96).
Aussage: Das System soll mehrere Authentifizierungsverfahren (lokal, Active Directory,
OpenID Connect, Web-Konto) unterstützen und optional, gesteuert durch System-
und Benutzereinstellung, eine Zwei-Faktor-Prüfung erzwingen.
Ergebnis: Anmeldung wird nur bei bestandener Erstfaktor- und – falls verlangt –
Zweitfaktor-Prüfung als erfolgreich zurückgegeben.
Belege:
- [PRIMÄR] Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs,
HasToValidateTwoFactor/ValidateTwoFactor, Z. 33-96 - Begründung: Durchsetzende
Entscheidungslogik, ob und wie der zweite Faktor geprüft wird.
- [SEKUNDÄR] Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs - Begründung:
Zeigt die unterstützte Bandbreite an Authentifizierungsverfahren.
Prüfidee: Benutzer mit `UseTwoFactorAuthentication=true` und aktivierter Systemeinstellung
meldet sich ohne Zweitfaktor an; erwartet wird Ablehnung mit
`TwoFactorAuthFailed`.
Tracelinks: StRS-004, SwRS-014
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Mehrstufige, konfigurierbare Authentifizierung bleibt
fachlich notwendig.
Status: belegt
```
```
ID: SyRS-004
Titel: Kryptografisch unzureichendes Passwort-Hashing-Verfahren
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Anmeldedienst, Passwortverwaltung
Vorbedingung: Ein Benutzer setzt oder ändert sein c-entron-Passwort, oder meldet sich damit an.
Fakt: Passwörter werden über `SHA1Decoder.GetDecodedSHA1String` (einfacher,
unsalted SHA1-Hash über den ANSI-codierten Klartext) sowohl beim Setzen
(`UsersBL.UpdatePassword`, Z. 100-108) als auch beim Anmeldevergleich
(`BasicAuthenticator.AuthenticateInternal`, Z. 46-50) verarbeitet; im Code
steht explizit der Kommentar „// TODO the password should be salted!!!“
(Administration/Logins/Auth/BasicAuthenticator.cs:48; Centron.Common/
TextCoding/SHA1Decoder.cs:9-17).
Aussage: Das System muss Passwörter mit einem für Passwort-Hashing geeigneten,
gesalzenen und rechenintensiven Verfahren (z. B. Argon2, bcrypt oder PBKDF2)
speichern; das aktuell verwendete unsalted-SHA1-Verfahren bietet keinen
ausreichenden Schutz gegen Rainbow-Table- und Brute-Force-Angriffe und ist im
Zielsystem zu ersetzen.
Ergebnis: Im Ist-System: Passwort-Hash ist ohne Salt und mit kryptografisch veraltetem
Algorithmus gebildet. Für das Zielsystem: gesalzenes, adaptives Hash-Verfahren
gefordert.
Belege:
- [PRIMÄR] Centron.Common/TextCoding/SHA1Decoder.cs, GetDecodedSHA1String, Z. 9-17 -
Begründung: Durchsetzende Implementierung des tatsächlich verwendeten
Hash-Verfahrens ohne Salt-Parameter.
- [PRIMÄR] Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Z. 46-50 -
Begründung: Zeigt die produktive Verwendung dieses Verfahrens beim
Anmeldevergleich.
- [KONTEXT] Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Z. 48,
Kommentar „// TODO the password should be salted!!!“ - Begründung: Bestätigt,
dass die Schwäche den Entwicklern selbst bekannt war.
Prüfidee: Zwei Benutzer mit identischem Passwort weisen identischen `AppUser.Password`-
Wert auf (kein Salt) – Nachweis über Datenbankvergleich zweier Testkonten.
Tracelinks: StRS-004, SwRS-012, SwRS-013
Konsolidierung: nein
Übernahmewürdigkeit: veraltet - Das Hash-Verfahren ist eine technische Altlast und durch ein
modernes Verfahren zu ersetzen; die fachliche Funktion (Passwort-Anmeldung)
selbst bleibt jedoch erforderlich (siehe StRS-004).
Status: belegt
```
```
ID: SyRS-005
Titel: Verschlüsselte Passwortspeicherung mit lückenlosem Zugriffsprotokoll
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Komponente PasswordManagementArea
Vorbedingung: Ein Sachbearbeiter legt Zugangsdaten zu einem Kunden-Asset an oder ruft sie ab.
Fakt: `PasswordManagementKeywordBL.AddNewKeyword` und `GetDecryptedKeywordById`
rufen bei jedem Anlege- bzw. Abrufvorgang
`PasswordManagementAccessLogBL.SavePasswordManagementAccessLog` auf; das
Entity-Modell sieht mit den Feldern `Salt` und `Password` eine gesalzene
Verschlüsselung vor (PasswordManagementKeywordBL.cs:21-59; Centron.Entities/
Entities/PasswordManagementArea/PasswordManagementKeyword.cs:10-11).
Aussage: Das System muss jedes Anlegen und jeden Abruf eines gespeicherten Passworts
protokollieren und das Passwort ausschließlich verschlüsselt (gesalzen)
speichern.
Ergebnis: Zugriffsprotokoll ist für jeden Passwort-Datensatz lückenlos; gespeicherter
Wert ist ohne Kenntnis des Verschlüsselungsmechanismus nicht im Klartext
lesbar.
Belege:
- [PRIMÄR] Centron.BL/PasswordManagementArea/PasswordManagementKeywordBL.cs, Z. 21-59 -
Begründung: Durchsetzende Stelle für Protokollierung bei Create/Read.
Prüfidee: GetDecryptedKeywordById aufrufen; PasswordManagementAccessLogBL muss einen
neuen Eintrag mit Zeitstempel und Benutzer enthalten.
Tracelinks: StRS-005, SwRS-045, SwRS-046
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Protokollierungspflicht bleibt bestehen; siehe SwRS-045 zur
tatsächlichen Verschlüsselungsimplementierung.
Status: belegt
```
```
ID: SyRS-006
Titel: Batchweise, transaktionale Artikel-Steuersatzumstellung
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Systemkomponente Warehousing/Tax
Vorbedingung: Ein neuer Mehrwertsteuersatz soll für alle betroffenen Artikel wirksam werden.
Fakt: `TaxBL.UpdateArticleVATs` verarbeitet betroffene Artikel in Batches von 2000
Datensätzen (`Batch(2000)`) über benannte SQL-Queries
(`UpdateArticleVatsAndPrices`/`UpdateArticleVats`), jeweils umschlossen von
`Session.WithTransaction` (Warehousing/TaxBL.cs:105-131).
Aussage: Das System soll die Umstellung großer Artikelmengen auf einen neuen
Mehrwertsteuersatz batchweise und transaktional durchführen, um sowohl
Performanz als auch Konsistenz bei großen Artikelbeständen sicherzustellen.
Ergebnis: Bei Abbruch während der Umstellung sind entweder alle Artikel eines Batches
oder keiner umgestellt.
Belege:
- [PRIMÄR] Centron.BL/Warehousing/TaxBL.cs, UpdateArticleVATs, Z. 105-131 - Begründung:
Konkrete Batch- und Transaktionssteuerung.
Prüfidee: Umstellung mit simuliertem Abbruch nach dem ersten Batch; bereits verarbeitete
Artikel bleiben konsistent umgestellt, nicht verarbeitete unverändert.
Tracelinks: StRS-006, SwRS-084
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-007
Titel: Rechtegeschützte, verschlüsselte Verwaltung des PDF-Signaturzertifikats
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Systemadministrator
Vorbedingung: Ein PDF-Signaturzertifikat (PKCS-Datei mit Passwort) soll hinterlegt werden.
Fakt: `PdfSigningBL.SavePdfSigningSettings` verlangt das Recht
`UserRightsConst.Administration.SETTINGS` (`currentUser.HasUserRight`) und
verschlüsselt Zertifikat sowie Zertifikatspasswort und TSA-Server-Passwort
vor der Speicherung über `_cryptoLogic.EncryptText`
(Security/PdfSigningBL.cs:60-108).
Aussage: Das System soll das Hinterlegen und Ändern des PDF-Signaturzertifikats auf
Benutzer mit Administrationsrecht beschränken und alle zugehörigen
Geheimnisse (Zertifikat, Zertifikatspasswort, TSA-Server-Passwort)
ausschließlich verschlüsselt speichern.
Ergebnis: Benutzer ohne Administrationsrecht können das Signaturzertifikat weder
einsehen noch ändern; gespeicherte Geheimnisse liegen nicht im Klartext vor.
Belege:
- [PRIMÄR] Centron.BL/Security/PdfSigningBL.cs, SavePdfSigningSettings, Z. 60-65, 84-99 -
Begründung: Durchsetzende Rechteprüfung und Verschlüsselungsaufrufe.
Prüfidee: SavePdfSigningSettings ohne Administrationsrecht muss RightCheckFailed
liefern; mit Recht gespeichertes Zertifikatspasswort darf in der Datenbank
nicht im Klartext stehen.
Tracelinks: StRS-003, SwRS-085
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Positives Sicherheitsmuster (Verschlüsselung von
Geheimnissen vor Speicherung), im Gegensatz zu SyRS-004 vorbildlich umgesetzt.
Status: belegt
```
```
ID: SyRS-008
Titel: Im Quellcode hinterlegte FinAPI-Client-Zugangsdaten
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Systemkomponente OnlineBanking/FinApi
Vorbedingung: Ein Mandant besitzt die Lizenz `OnlineBanking_FinApi` oder der Aufruf erfolgt
im Unit-Test-Modus.
Fakt: `OnlineBankingFinApiBL.GetFinApiClientCredentials` weist bei vorhandener
Lizenz oder `isUnitTest=true` fest im Quellcode codierte Werte für `ClientId`,
`ClientSecret`, `SandBoxClientId` und `SandBoxClientSecret` zu (Finances/
OnlineBanking/OnlineBankingFinApiBL.cs:39-46).
Aussage: Das System soll Zugangsdaten für die Anbindung an externe API-Partner (hier
FinAPI) über eine sichere, vom Quellcode getrennte Konfigurationsquelle
(Secret-Store/verschlüsselte Konfiguration) beziehen statt sie als
Klartext-Konstanten im Quellcode zu hinterlegen.
Ergebnis: Im untersuchten Code sind die Anwendungs-Zugangsdaten für den FinAPI-Dienst für
alle Installationen identisch und aus dem Quellcode/Binary extrahierbar.
Belege:
- [PRIMÄR] Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs,
GetFinApiClientCredentials, Z. 39-46 - Begründung: Wörtliche Konstanten im
Quellcode als durchsetzende Stelle.
Prüfidee: Dekompilierung der ausgelieferten Assembly legt `ClientSecret` und
`SandBoxClientSecret` im Klartext offen.
Tracelinks: SwRS-086
Konsolidierung: nein
Übernahmewürdigkeit: veraltet - Es handelt sich um die Anwendungs-Zugangsdaten (nicht um
Kunden-Bankdaten), die fachliche Anbindung an FinAPI bleibt jedoch
erforderlich; im Zielsystem ist die Aufbewahrung in einem Secret-Store
vorzusehen.
Status: belegt
```
```
ID: SyRS-009
Titel: Zweistufige Zugriffskontrolle und Bearbeitungssperre für Verkaufsbelege
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Systemkomponente Sales/Receipts
Vorbedingung: Ein Benutzer greift lesend oder schreibend auf einen Beleg zu.
Fakt: `CanUserEditReceipt` kombiniert ein belegtyp-spezifisches Recht
(`HasRightToEditReceipt`) mit einer optionalen Filialbindung
(`HasRightToEditReceiptOnlyOwnBranch`, geprüft über `BranchBL.IsBranchEqual`);
`CanUserViewReceipt` verweigert Web-Konten (`IsWebAccountLogin`) grundsätzlich
den Lesezugriff (Sales/Receipts/ReceiptBL.cs:10272-10307).
Aussage: Das System muss vor jedem schreibenden Belegzugriff sowohl das
belegtyp-spezifische Recht als auch – falls konfiguriert – die
Filialzugehörigkeit prüfen und Web-Portal-Konten grundsätzlich vom direkten
Belegzugriff der internen Anwendung ausschließen.
Ergebnis: Zugriff wird bei fehlendem Recht, falscher Filiale oder Web-Konto-Login
abgelehnt.
Belege:
- [PRIMÄR] Centron.BL/Sales/Receipts/ReceiptBL.cs, Z. 10272-10307 - Begründung:
Durchsetzende Prüflogik für Edit- und View-Zugriff.
Prüfidee: Web-Konto ruft CanUserViewReceipt auf; Ergebnis muss RightCheckFailed sein,
unabhängig von sonstigen Rechten.
Tracelinks: StRS-007, SwRS-087, SwRS-089
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/Ergebnisse/Traceability.md
+157
View File
@@ -0,0 +1,157 @@
# Traceability-Tabelle
Konsolidierte Forward-/Backward-Traceability zwischen StRS, SyRS und SwRS. Jede Zeile
entspricht mindestens einer SwRS-Anforderung; wo keine SyRS- bzw. StRS-Anforderung explizit
vertieft wurde (reine Mindestabdeckung, siehe Analysebericht.md Schritt 0b), ist die
jeweilige Spalte mit `-` markiert. Der Artefaktbeleg nennt die primäre Fundstelle
(Kurzform; vollständige Begründung siehe jeweiliges Anforderungsdokument).
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (Kurzform) |
|---|---|---|---|
| StRS-001 | SyRS-001 | SwRS-001 | Accounting/BankAccountBL.cs:71-82 |
| StRS-002 | - | SwRS-002 | Accounts/AccountAddressBL.cs, AccountTypeBL.cs |
| - | - | SwRS-003 | AppointmentRequests/AppointmentRequestBL.cs:29-147 |
| - | - | SwRS-004 | BusinessPartner/SupplierAssetBL.cs:43-315 |
| - | - | SwRS-005 | Buying/External/DistributorBL.cs:38 |
| - | - | SwRS-006 | CPra/CPraConnectorBL.cs:31-120 |
| - | - | SwRS-007 | Calendar/CalendarBL.cs:20-179 |
| - | - | SwRS-008 | CentronIcons/CentronIconsBL.cs:23-63 |
| - | - | SwRS-009 | ChangeTracking/History/ImportHistoryBL.cs:20-32 |
| - | - | SwRS-010 | Chats/ChatBL.cs:74-297 |
| StRS-003 | SyRS-002 | SwRS-011 | Administration/Rights/AppRightsBL.cs:92-109 |
| StRS-004 | SyRS-004 | SwRS-012 | Centron.Common/TextCoding/SHA1Decoder.cs:9-17; Administration/Logins/Auth/BasicAuthenticator.cs:46-50 |
| StRS-004 | SyRS-004 | SwRS-013 | Administration/Logins/UsersBL.cs:99-131 |
| StRS-004 | SyRS-003 | SwRS-014 | Administration/Logins/TwoFactor/TwoFactorAuthBL.cs:33-96 |
| - | - | SwRS-015 | CheckListArea/CentronChecklistBL.cs:163-185 |
| - | - | SwRS-016 | CountryArea/CountryBL.cs:62-184 |
| - | - | SwRS-017 | CustomerArea/RmaBL.cs:347-395,523 |
| - | - | SwRS-018 | Customizations/CustomTables/CustomTableBL.cs:20-29 |
| - | - | SwRS-019 | Devices/AccountDeviceBL.cs:96-108 |
| - | - | SwRS-020 | DocuBoard/AssetManagementArticleAssignmentBL.cs:21-49 |
| - | - | SwRS-021 | DocumentationArea/DocumentationBL.cs:27-97 |
| - | - | SwRS-022 | EDI/EDIDispatcherBL.cs:56-201 |
| - | - | SwRS-023 | EmployeeArea/EmployeeBL.cs:67-93 |
| - | - | SwRS-024 | Exceptions/TicketExpiredException.cs:6-11 |
| - | - | SwRS-025 | ExpectedEvents/ExpectedEventsBL.cs:22-136 |
| - | - | SwRS-026 | ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs:19-45 |
| - | - | SwRS-027 | ExternalToolsBL/ExternalToolBL.cs:58-65 |
| - | - | SwRS-028 | GUI/Import/Asset/ImportOrderBL.cs:91-104 |
| - | - | SwRS-029 | Gateway/CustomGatewayBL.cs:73-221 |
| - | - | SwRS-030 | IndexSearch/IndexSearchBL.cs:28-75 |
| - | - | SwRS-031 | Integrations/EsRoleBL.cs:53-70 |
| - | - | SwRS-032 | ItPlanner/ChecklistVirtualObjectCategoryBL.cs:18-166 |
| - | - | SwRS-033 | Logistics/LogisticSettings/LogisticSettingsBL.cs:26-70 |
| - | - | SwRS-034 | ArtificialIntelligence/OpenAiApiClient.cs:19-76 |
| - | - | SwRS-035 | CentronNexus (BL)/CentronNexusBL.cs:19-38 |
| - | - | SwRS-036 | Helpers/PdfInteractionBL.cs:13-42 |
| - | - | SwRS-037 | Mail/MailSettingsBL.cs:33-253 |
| - | - | SwRS-038 | MailScanner/MailScannerBL.cs:36-126 |
| - | - | SwRS-039 | Mailings/MailingDataBL.cs:22-47 |
| - | - | SwRS-040 | MassUpdate/MassUpdateBL.cs:238 |
| - | - | SwRS-041 | Mobile/MobileBL.cs:12-23 |
| - | - | SwRS-042 | Modules/ModuleBL.cs:22-43 |
| - | - | SwRS-043 | MyCentron/LatestUsedCentronObjectBL.cs:23,50-76 |
| - | - | SwRS-044 | MyDay/MyDayBL.cs:76-99 |
| StRS-005 | SyRS-005 | SwRS-045 | PasswordManagementArea/PasswordManagementKeywordBL.cs:37-59 |
| StRS-005 | SyRS-005 | SwRS-046 | PasswordManagementArea/PasswordManagementKeywordBL.cs:28,51-52 |
| - | - | SwRS-047 | NexusNotifications/NexusNotificationsBL.cs:57-118 |
| - | - | SwRS-048 | NexusTicketViews/NexusTicketViewBL.cs:65-98 |
| - | - | SwRS-049 | Notifications/CentronNotificationsBL.cs:53-69 |
| - | - | SwRS-050 | ObjectExternalReferences/ObjectExternalReferenceBL.cs:119-152 |
| - | - | SwRS-051 | Outlook/OutlookAssetKindSearchBL.cs:25 |
| - | - | SwRS-052 | Processes/ProcessBL.cs:33-66 |
| - | - | SwRS-053 | ProductMatrix/ProductMatrixBL.cs:65-105 |
| - | - | SwRS-054 | Production/ProductionBL.cs:25-121 |
| - | - | SwRS-055 | Projects/ProjectBL.cs:17-22 |
| - | - | SwRS-056 | DataExchange/PaymentTransactions/PaymentTransactionBL.cs:93-118 |
| - | - | SwRS-057 | PasswordManager/PasswordManagerBL.cs:190-224 |
| - | - | SwRS-058 | ReportEngine/ReportDataBL.cs:164-177 |
| - | - | SwRS-059 | Reporting/ReportsBL.cs:39-49 |
| - | - | SwRS-060 | RiverDivo/RiverDivoBL.cs:86-106 |
| - | - | SwRS-061 | SelfCare/SelfCareBL.cs:47-91 |
| - | - | SwRS-062 | Services/Workflows/WorkflowProcessBL.cs:19-67 |
| - | - | SwRS-063 | SocialMedia/SocialMediaBL.cs:124-169 |
| - | - | SwRS-064 | Start/StartBL.cs:9-18 |
| - | - | SwRS-065 | Storage/StorageBL.cs:47-78 |
| - | - | SwRS-066 | SystemArea/SystemTableI3DBL.cs:21 |
| - | - | SwRS-067 | Tags/TagsBL.cs:19-70 |
| - | - | SwRS-068 | Tapi/PhoneCallBL.cs:149-282 |
| - | - | SwRS-069 | TaskManager/TaskManagementTaskBL.cs:171 |
| - | - | SwRS-070 | Telemetry/TelemetryBL.cs:293 |
| - | - | SwRS-071 | TextModuleArea/TextModuleBL.cs:43-48 |
| - | - | SwRS-072 | TicketProjects/TicketProjectBL.cs:38-81 |
| - | - | SwRS-073 | Time/TimingSettingsBL.cs:16-27 |
| - | - | SwRS-074 | ToDoArea/ToDoBL.cs:190-211 |
| - | - | SwRS-075 | Tools/ToolBL.cs:16 |
| - | - | SwRS-076 | TradePool/TradePoolBL.cs:64-102 |
| - | - | SwRS-077 | Transactions/TransactionBL.cs:29-73 |
| StRS-005 | - | SwRS-078 | TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs:43-51 |
| - | - | SwRS-079 | Urls/SimpleUrlBL.cs:27-117 |
| - | - | SwRS-080 | WebLinks/WebLinkBL.cs:41-113 |
| - | - | SwRS-081 | WebSuite/Administration/Settings/WebSettingBL.cs:24-67 |
| - | - | SwRS-082 | WebVersion/VersionBL.cs:13 |
| - | - | SwRS-083 | Statistics/Sales/Receipts/InvoiceStatisticBL.cs; ManagementInfo/ManagementInfoBL.cs |
| StRS-006 | SyRS-006 | SwRS-084 | Warehousing/TaxBL.cs:92-96 |
| StRS-003 | SyRS-007 | SwRS-085 | Security/PdfSigningBL.cs:83-99 |
| - | SyRS-008 | SwRS-086 | Finances/OnlineBanking/OnlineBankingFinApiBL.cs:41-44 |
| StRS-007 | SyRS-009 | SwRS-087 | Sales/Receipts/ReceiptBL.cs:10272-10294 |
| StRS-007 | - | SwRS-088 | Sales/Receipts/ReceiptBL.cs:3081-3096 |
| StRS-007 | SyRS-009 | SwRS-089 | Sales/Receipts/ReceiptBL.cs:10296-10307 |
| - | - | SwRS-090 | VoucherManagement/VoucherManagementBL.cs:17-24 |
| - | - | SwRS-091 | Purchasing/SupplierOrderPerBranchBL.cs:145 |
| - | - | SwRS-092 | Finances/IncomingPayments/IncomingPaymentBL.cs:21-35 |
| StRS-003 | - | SwRS-093 | Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs:38-55 |
| - | - | SwRS-094 | Centron.DAO/GenericDAO.cs:33-236 |
| - | - | SwRS-095 | Centron.Entities/PersistedEntity.cs:14-101 |
| - | - | SwRS-096 | Centron.Interfaces/IBaseRepository.cs |
| - | - | SwRS-097 | Centron.Common/Logging/InMemoryTarget.cs |
| - | - | SwRS-098 | Centron.Gateway/EDI_Also/Order/xmlOrder240.cs |
| StRS-004 | - | SwRS-099 | Centron.WPF.UI/FrontWindowViewModel.cs:128-260 |
| - | - | SwRS-100 | Centron.Controls/CustomerManagement/CustomerManagementViewModel.cs |
| - | SwRS-078 | SwRS-101 | Centron.Core (shared)/TotpAuth/Totp.cs |
| - | - | SwRS-102 | Centron.WebServices.Core/Connections/CentronWebService.cs |
| - | - | SwRS-103 | Centron.Host.WindowsService/CentronService.cs |
| - | - | SwRS-104 | c-entron.misc.ConnectionManager/ConnectionManagerViewModel.cs:28-139 |
| - | - | SwRS-105 | Centron.BL/WebServices/ObjectMapper.cs:20-76 |
| - | - | SwRS-106 | Centron.WPF.UI.Extension/Actions/DefaultActions/*.cs |
| - | - | SwRS-107 | Centron.Controls.Preview/App.xaml.cs |
| - | - | SwRS-108 | Centron.Host/AspNetCore/HostedServices/ArticleImportService.cs:9-24 |
| - | - | SwRS-109 | CentronNexus/ServiceBoard/Helpers/TicketHelper.cs |
| - | - | SwRS-110 | CentronNexus/WebOffer/Models/WebOfferViewModel.cs:9-22 |
| - | - | SwRS-111 | CentronNexus/DocumentSigning/IsolatedSignaturePad.razor:34 |
| - | - | SwRS-112 | CentronNexus/ProductionOrderManagement/Model/WorkStepTemplateModel.cs |
| - | - | SwRS-113 | CentronNexus/Office/Controllers/PdfController.cs:16 |
| StRS-003 | - | SwRS-114 | CentronNexus/Management/WebAccount/Model/WebRightNode.cs; Administration/Rights/AppRightsBL.cs:113-129 |
| - | - | SwRS-115 | CentronNexus.Host/Program.cs |
| - | - | SwRS-116 | CentronNexus.OutlookAddIn/Model/BlacklistedDirectories.cs |
| - | - | SwRS-117 | CentronNexus/WebCart/Helpers/CurrentCartService.cs:24-48 |
| - | SyRS-008 | SwRS-118 | Centron.APIs.FinAPI/Data/AccessToken.cs |
| - | - | SwRS-119 | Centron.APIs.CopDataAccess/CopApi.cs:19-53 |
| - | - | SwRS-120 | Centron.APIs.EgisDataAccess/Data/PriceAndAvailability.cs |
| - | - | SwRS-121 | Centron.APIs.ITscopeDataAccess/Data/ITscopeApiKeyQuota.cs |
| - | - | SwRS-122 | Centron.APIs.IcecatDataAccess/Data/ProductDescription.cs |
| - | - | SwRS-123 | Centron.Api.EbInterface/EbInterfaceLogic.cs:22 |
| - | - | SwRS-124 | Centron.Api.Gls/CentronGlsLogic.cs:15 |
| - | - | SwRS-125 | Centron.Api.Shipcloud/CentronShipcloudLogic.cs |
| - | - | SwRS-126 | Centron.Api.docuFORM/Helper/OAuthHelper.cs:11-28 |
| StRS-003 | - | SwRS-127 | VideoPortal/VideoPortalAssignmentBL.cs:25-35 |
| StRS-006 | - | SwRS-128 | Warehousing/TaxBL.cs:64-72 (auskommentiert) |
| - | - | SwRS-129 [HYPOTHESE] | VoucherManagement/VoucherManagementBL.cs (Negativbefund) |
| - | - | SwRS-130 [HYPOTHESE] | Centron.APIs.CopDataAccess/CopApi.cs:19-23 (Negativbefund) |
| - | - | SwRS-131 [HYPOTHESE] | RiverDivo/RiverDivoBL.cs:110-115 |
| - | - | SwRS-132 [HYPOTHESE] | MassUpdate/MassUpdateBL.cs:132-238 |
| - | - | SwRS-133 [HYPOTHESE] | Administration/Rights/AppRightsBL.cs:92-129 |
| StRS-005 | SyRS-005 | SwRS-134 [HYPOTHESE] | PasswordManagementArea (Negativbefund Verschlüsselung) |
| - | - | SwRS-135 | Centron.BL/Core/ReplacementBL.cs:15-39 |
## Hinweis zur Lesart
- Zeilen ohne StRS-/SyRS-Eintrag (`-`) sind Ergebnis der Mindestabdeckung aus Schritt 0b: Jedes
Modul des Inventars wurde mit mindestens einer beleg­ten SwRS-Anforderung abgedeckt, ohne dass
in dieser Iteration für jedes Modul auch eine eigene Stakeholder- bzw. Systemanforderung
formuliert wurde. Das ist eine bewusste Abgrenzung der Iteration (siehe Selbstbewertung in
Analysebericht.md) und kein Fehler der Traceability.
- Risikorelevante Bereiche (Sicherheit, Berechtigungen, Abrechnung/Fakturierung) sind
vollständig mit StRS→SyRS→SwRS-Ketten hinterlegt (StRS-001 bis StRS-007).
- Mehrere SwRS-Anforderungen können auf dieselbe StRS-/SyRS-Anforderung zurückverfolgt werden
(z. B. StRS-004 auf SwRS-012/013/014/099).
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/Ergebnisse/_all.tmp
+4361
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/Ergebnisse/_ids_raw.tmp
+150
View File
@@ -0,0 +1,150 @@
ID: StRS-001
ID: StRS-002
ID: StRS-003
ID: StRS-004
ID: StRS-005
ID: StRS-006
ID: StRS-007
ID: SyRS-001
ID: SyRS-002
ID: SyRS-003
ID: SyRS-004
ID: SyRS-005
ID: SyRS-006
ID: SyRS-007
ID: SyRS-008
ID: SyRS-009
ID: SwRS-001
ID: SwRS-002
ID: SwRS-003
ID: SwRS-004
ID: SwRS-005
ID: SwRS-006
ID: SwRS-007
ID: SwRS-008
ID: SwRS-009
ID: SwRS-010
ID: SwRS-015
ID: SwRS-016
ID: SwRS-017
ID: SwRS-018
ID: SwRS-019
ID: SwRS-020
ID: SwRS-011
ID: SwRS-012
ID: SwRS-013
ID: SwRS-014
ID: SwRS-021
ID: SwRS-022
ID: SwRS-023
ID: SwRS-024
ID: SwRS-025
ID: SwRS-026
ID: SwRS-027
ID: SwRS-028
ID: SwRS-029
ID: SwRS-030
ID: SwRS-031
ID: SwRS-032
ID: SwRS-033
ID: SwRS-034
ID: SwRS-035
ID: SwRS-036
ID: SwRS-037
ID: SwRS-038
ID: SwRS-039
ID: SwRS-040
ID: SwRS-041
ID: SwRS-042
ID: SwRS-043
ID: SwRS-044
ID: SwRS-045
ID: SwRS-046
ID: SwRS-047
ID: SwRS-048
ID: SwRS-049
ID: SwRS-050
ID: SwRS-051
ID: SwRS-052
ID: SwRS-053
ID: SwRS-054
ID: SwRS-055
ID: SwRS-056
ID: SwRS-057
ID: SwRS-058
ID: SwRS-059
ID: SwRS-060
ID: SwRS-061
ID: SwRS-062
ID: SwRS-063
ID: SwRS-064
ID: SwRS-065
ID: SwRS-066
ID: SwRS-067
ID: SwRS-068
ID: SwRS-069
ID: SwRS-070
ID: SwRS-071
ID: SwRS-072
ID: SwRS-073
ID: SwRS-074
ID: SwRS-075
ID: SwRS-076
ID: SwRS-077
ID: SwRS-078
ID: SwRS-079
ID: SwRS-080
ID: SwRS-081
ID: SwRS-082
ID: SwRS-083
ID: SwRS-084
ID: SwRS-085
ID: SwRS-086
ID: SwRS-087
ID: SwRS-088
ID: SwRS-089
ID: SwRS-090
ID: SwRS-091
ID: SwRS-092
ID: SwRS-093
ID: SwRS-094
ID: SwRS-095
ID: SwRS-096
ID: SwRS-097
ID: SwRS-098
ID: SwRS-099
ID: SwRS-100
ID: SwRS-101
ID: SwRS-102
ID: SwRS-103
ID: SwRS-104
ID: SwRS-105
ID: SwRS-106
ID: SwRS-107
ID: SwRS-108
ID: SwRS-109
ID: SwRS-110
ID: SwRS-111
ID: SwRS-112
ID: SwRS-113
ID: SwRS-114
ID: SwRS-115
ID: SwRS-116
ID: SwRS-117
ID: SwRS-118
ID: SwRS-119
ID: SwRS-120
ID: SwRS-121
ID: SwRS-122
ID: SwRS-123
ID: SwRS-124
ID: SwRS-125
ID: SwRS-126
ID: SwRS-127
ID: SwRS-128
ID: SwRS-129
ID: SwRS-130
ID: SwRS-131
ID: SwRS-132
ID: SwRS-133
ID: SwRS-134
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/Protokoll.md
+229
View File
@@ -0,0 +1,229 @@
# 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-26T10:29:49.6805991+02:00
- **Endzeit:** 2026-08-26T11:12:15.0431177+02:00
- **Dauer gesamt:** 0:42:25 (`duration_ms` 0:42:23; API: 0:41:20)
— **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: ja)
- **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:** **ja – der Snapshot weicht vom Commit-Stand ab.** Folgende Dateien lagen zusätzlich im Arbeitsverzeichnis und standen dem Lauf als Artefaktquelle zur Verfügung:
- `QuellCode/CentronERP/SSMS_DB_SCHEMA.sql` (Git-Status `??`)
- SHA-256: `ED7F21250E868577572B4CADA53C132F7433C74270BF9B59E817CCEC6B1FA8DB`
- 3.266.626 B / 76.793 Zeilen – SSMS-Schema-Dump der Datenbank `CentronVOED2`: 1.558 `CREATE TABLE`, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel
Läufe mit und ohne diese Artefakte sind **nicht** unmittelbar vergleichbar: Der
Untersuchungsgegenstand ist ein anderer.
- **Nutzung des DB-Schemas:** **nein** – kein einziger Werkzeugaufruf nennt `SSMS_DB_SCHEMA` in der Eingabe, und die Ergebnisartefakte erwähnen sie nicht. Der Agent hat die Datei allenfalls in der Verzeichnisauflistung gesehen und **nicht geöffnet**. Die Verfügbarkeit des Schemas ist die Versuchsbedingung, seine Nutzung eine abhängige Variable – dieser Lauf gehört zur Bedingung, nutzt sie aber nicht.
- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
## Werkzeugkonfiguration
- **Skill-Version:** 4.3.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-sonnet-5`
- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 42.852.228 Tokens (99.98 %), `claude-haiku-4-5-20251001` 6.967 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:** `v4.3.0-b652`
- **Ablage:** `Iteration 3/claude-sonnet-5/solo/high/`
- **Parallele Läufe:** **ja** – zeitgleich liefen:
- `02_Lauf_2026-08-26_102932_v4.3.0-0848`
- `02_Lauf_2026-08-26_102932_v4.3.0-1b24`
- `02_Lauf_2026-08-26_102932_v4.3.0-2316`
- `02_Lauf_2026-08-26_102932_v4.3.0-3ef5`
Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden.
Tokenverbrauch, Anforderungszahl und Denials bleiben unverzerrt.
- **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 | 376 |
| Output-Tokens | 256.101 (davon 49.259 Thinking-Tokens) |
| Cache-Write-Tokens | 380.701 |
| Cache-Read-Tokens | 42.215.050 |
| Agent-Turns | 188 |
### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
|---|---:|---:|---:|
| Input-Tokens | 376 | 6.943 | 7.319 |
| Output-Tokens | 256.101 | 24 | 256.125 |
| Cache-Write-Tokens | 380.701 | 0 | 380.701 |
| Cache-Read-Tokens | 42.215.050 | 0 | 42.215.050 |
| **Tokens gesamt** | **42.852.228** | **6.967** | **42.859.195** |
**Tokens gesamt: 42.859.195** — 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 | 7 | 4,6 % |
| SyRS | 9 | 6,0 % |
| SwRS | 135 | 89,4 % |
| **Gesamt** | **151** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 71 | 47,0 % |
| Sicherheit | 39 | 25,8 % |
| Schnittstelle | 18 | 11,9 % |
| Daten | 13 | 8,6 % |
| nicht-funktional | 10 | 6,6 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 168 |
| davon `PRIMÄR` | 154 (91,7 %) |
| davon `SEKUNDÄR` | 5 (3,0 %) |
| davon `KONTEXT` | 9 (5,4 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 145 (96,0 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 139 | 92,1 % |
| workaround | 2 | 1,3 % |
| sonderfall | 4 | 2,6 % |
| veraltet | 6 | 4,0 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 145 | 96,0 % |
| als `HYPOTHESE` gekennzeichnet | 6 | 4,0 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 23 | 15,2 % |
| mit ISO-25010-Qualitätsmerkmal | 17 | 11,3 % |
### 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** (53 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 151 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 151 von 151 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
- **Session-ID:** `ae39792d-bac5-4d6d-9d24-e4b1d5ac97ec`
- **Permission-Denials:** 5 (3 × `Bash`, 1 × `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:** 9 Dateien in `Ergebnisse\`:
| Datei | Größe |
|---|---:|
| `Analysebericht.md` | 34.486 B |
| `Glossar.md` | 5.900 B |
| `Hypothesen.md` | 3.439 B |
| `StRS.md` | 14.728 B |
| `SwRS.md` | 198.068 B |
| `SyRS.md` | 17.293 B |
| `Traceability.md` | 10.568 B |
| `_all.tmp` | 227.953 B |
| `_ids_raw.tmp` | 3.600 B |
- **Root unverändert:** ja (zeilenendennormalisiert verglichen). Der rohe Vorher/Nachher-Vergleich weicht ab, weil `SSMS_DB_SCHEMA.sql` zwischen Laufbeginn und Auswertung committet wurde und deshalb nicht mehr als `??` im Status erscheint. Nach Normalisierung um diese Zeile sind beide Stände identisch; zusätzlich ist `git diff HEAD -- QuellCode/CentronERP` leer (bestätigt). Am Inhalt des Arbeitsverzeichnisses hat der Lauf nichts verändert.
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
## Anmerkungen/Auffälligkeiten
**1. Iteration 3 = geänderter Untersuchungsgegenstand.** Seit 2026-08-26 10:28:08 liegt
`SSMS_DB_SCHEMA.sql` im Arbeitsverzeichnis (3.266.626 B, 76.793 Zeilen, 1.558 Tabellen, 182 Views,
63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256 `ED7F2125…1FA8DB`, Commit `f349d189`).
Der Prompt fordert Datenbankschemata in Schritt 2 ausdrücklich als Artefaktquelle. Läufe der
Iteration 2 hatten die Datei nicht – die beiden Iterationen sind **nicht poolbar**.
**2. Verfügbarkeit ≠ Nutzung.** Ob der Agent das Schema öffnet, ist eine **abhängige** Variable:
Von den fünf Läufen der Iteration 3 haben drei es genutzt (`0848`, `1b24`, `2316`), zwei nicht
(`3ef5`, `b652`). Erhoben wird das über Werkzeugaufrufe, deren **Eingabe** den Dateinamen nennt –
nicht über Texttreffer im Transkript: Die Verzeichnisauflistung zu Laufbeginn nennt die Datei
zwangsläufig und ist kein Zugriff.
**3. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Fünf Läufe gleichzeitig,
zeitweise überlappend mit `094249_v4.2.1-4840` aus Iteration 2. Wanduhrzeit, `duration_ms` und
`duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials
nicht. Einziger gültiger Laufzeitmesspunkt beider Iterationen bleibt der serielle Lauf
`084301_v4.2.0-d6f9` mit 45:04.
**4. Root-Vergleich normalisiert.** `before.txt` führt das Schema als `??`, `after.txt` ist leer –
weil die Datei zwischen Laufbeginn und Auswertung committet wurde. Der rohe Vergleich meldete
deshalb eine Abweichung, die es nicht gibt. Nach Normalisierung um diese Zeile sind beide Stände
identisch, zusätzlich bestätigt durch ein leeres `git diff HEAD -- QuellCode/CentronERP`.
**5. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung; die `solo`-Kontrolle
(`subagent_stats.spawned` = 0) wurde gegengeprüft und ist erfüllt.
**6. Schema verfügbar, gesehen und ignoriert.** Kein einziger Werkzeugaufruf nennt
`SSMS_DB_SCHEMA` in der Eingabe; die Ergebnisartefakte erwähnen die Datei nicht. Im
Session-Transkript (2,32 MB) erscheint sie **genau einmal**: in der Verzeichnisauflistung des
Wurzelverzeichnisses um 10:29:57, zu Laufbeginn. Der Agent hat eine 76.793-Zeilen-Schemadatei im
Wurzelverzeichnis gesehen und stattdessen 42,9 Mio. Tokens im Quellcode verbraucht – obwohl der
Prompt Datenbankschemata in Schritt 2 ausdrücklich als Artefaktquelle nennt.
**7. Beste Belegqualität der Iteration 3 – und die niedrigste Anforderungszahl.** 96,0 % der
Anforderungen tragen einen Primärbeleg, alle 41 risikorelevanten sind gedeckt, Tracelinks bei
100 %. Dem stehen 151 Anforderungen gegenüber, der niedrigste Wert der Iteration. Das Muster
wiederholt sich damit über beide Iterationen: Die Läufe mit der besten Belegqualität liefern die
wenigsten Anforderungen.
**8. Extremste SwRS-Lastigkeit der Iteration:** 135 von 151 Anforderungen (89,4 %) auf
Softwareebene, nur 7 auf Stakeholder- und 9 auf Systemebene.
**9. Fünf Permission-Denials, alle Nebeneffekt der Werkzeugkonfiguration** – ein `Read` auf das
eigene Temp-Verzeichnis, drei `Bash`-Kommandos mit Löschanteil, ein `Remove-Item`. Zwei
Arbeitsdateien (`_all.tmp`, `_ids_raw.tmp`) blieben deshalb im Ergebnisordner liegen und werden
bewusst nicht nachträglich entfernt.
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/RawResult.json
+1
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/Stderr.log
View File
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/_meta/after.txt
View File
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/_meta/anforderungen.json
+2888
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/_meta/anforderungen.md
+65
View File
@@ -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 | 7 | 4,6 % |
| SyRS | 9 | 6,0 % |
| SwRS | 135 | 89,4 % |
| **Gesamt** | **151** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 71 | 47,0 % |
| Sicherheit | 39 | 25,8 % |
| Schnittstelle | 18 | 11,9 % |
| Daten | 13 | 8,6 % |
| nicht-funktional | 10 | 6,6 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 168 |
| davon `PRIMÄR` | 154 (91,7 %) |
| davon `SEKUNDÄR` | 5 (3,0 %) |
| davon `KONTEXT` | 9 (5,4 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 145 (96,0 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 139 | 92,1 % |
| workaround | 2 | 1,3 % |
| sonderfall | 4 | 2,6 % |
| veraltet | 6 | 4,0 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 145 | 96,0 % |
| als `HYPOTHESE` gekennzeichnet | 6 | 4,0 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 23 | 15,2 % |
| mit ISO-25010-Qualitätsmerkmal | 17 | 11,3 % |
### 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** (53 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 151 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 151 von 151 mit Tracelinks (100,0 %) |
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/_meta/before.txt
+2
View File
@@ -0,0 +1,2 @@
?? QuellCode/CentronERP/SSMS_DB_SCHEMA.sql
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/_meta/combined_prompt.md
+177
View File
@@ -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\Tag 2\claude-sonnet-5\solo\high\02_Lauf_2026-08-26_102932_v4.3.0-b652\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-26T11:12:15.0431177+02:00
Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-b652/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-26T10:29:49.6805991+02:00