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

TensorX-Matrix: erste vollstaendig besetzte Matrix, 918 Anforderungen

Browse Source 
Sechs Zellen - z-ai/glm-5.3-flash und qwen/qwen3.8-flash-next je solo,
builtin und custom - alle mit dem kompletten Artefaktsatz von sieben
Dateien. 47,1 Mio. Tokens in 6,4 Stunden, hochgerechnet rund $3,25.

Das Matrixskript heisst jetzt _matrix.ps1 und nimmt -Provider und
-Effort; die LM-Studio-Ladeparameter werden nur noch lokal uebergeben.
Vor dem Start bestaetigte ein Smoke-Test den TensorX-Pfad unter den
seither geaenderten Bedingungen (Denylist, Spiegel, Freigabemuster):
Anmeldung, Modellkontrolle, wirksame Effort-Variante und Dateiuebernahme.

Befund: Die Anforderungsanzahl haette in die Irre gefuehrt. Qwens
custom-Lauf liegt mit 157 Anforderungen im Mittelfeld, ist aber
qualitativ zusammengebrochen - 61 Prozent ohne jeden Beleg, 17 Prozent
mit Primaerbeleg, 40 Prozent Hypothesen, gegenueber 0 Prozent ohne Beleg
und 79 bis 98 Prozent Primaerbelegen in den uebrigen fuenf Laeufen. Er
lieferte zugleich weniger als builtin bei 37 Prozent mehr Tokens.

Der Moduseffekt ist modellabhaengig: Bei GLM steigt der Ertrag monoton
von 126 ueber 139 auf 216 bei durchgaengig hoher Belegqualitaet, bei Qwen
ist builtin das Optimum. Die Annahme, rollenspezialisierte Agenten seien
generell ueberlegen, traegt damit nicht.

Qwens custom-Lauf meldet exit_code 1 bei finish_reason stop und ohne
Timeout, nachdem alle 24 Subagenten zurueckkamen und sieben Dateien
entstanden. Er ist als gueltig mit Vorbehalt gefuehrt, die Ursache offen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Christoph Schwörer
2026-09-02 16:21:31 +02:00
co-authored by Claude Opus 5
parent 6c5c26a2e4
commit e2c3a0e8f8
135 changed files with 102006 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Adapter.log
+5
View File
@@ -0,0 +1,5 @@
[2026-09-02T07:56:50.425489+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\high\03_Lauf_2026-09-02_095648_v13.0.0-77c1\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\high\03_Lauf_2026-09-02_095648_v13.0.0-77c1\Ergebnisse)
[2026-09-02T07:56:50.519897+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=builtin; Effort=high (uebergeben=True); Stall-Timeout=0s
[2026-09-02T08:42:40.702163+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
[2026-09-02T08:42:42.038102+00:00] OpenCode export: Exporting session: ses_f9ee10b97ffeSh7qClgcgd0uz4
[2026-09-02T08:42:42.094727+00:00] Ende: Exitcode=0; Status=success; Turns=32; Tokens=4316088; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\high\03_Lauf_2026-09-02_095648_v13.0.0-77c1\RawResult.json
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse/Analysebericht.md
+335
View File
@@ -0,0 +1,335 @@
# Analysebericht
Reverse Requirements Engineering der c-entron ERP-Suite (Iteration 03, Baseline Prompt-only).
Analysierte Codebasis: c-entron ERP (C#/XAML/WPF + Blazor, MSSQL, NHibernate). Nur statische Analyse, keine Ausführung, keine Änderung der Codebasis.
Alle Belegpfade sind relativ zum Arbeitsverzeichnis (Stammverzeichnis der Codebasis) angegeben.
**Methodik:** Schritt 0 (Modulinventar) vor der ersten Anforderung; Schritt 0b (Mindestabdeckung) vor Vertiefung; Schritt 0c (Vertiefung nach Risiko: Authentifizierung, Berechtigungen, Abrechnung/Nummernwesen zuerst). Werkzeug: Dateisuche, Quelltext-Lesen, rein lesende Kommandos, werkzeugeigene Subagenten (7 Teilanalysen); kritische Belege (PRIMÄR) wurden zusätzlich einzeln verifiziert (≈ 25 Stichproben über Suchwerkzeug).
**Ergebnisumfang:** 139 Anforderungen — 22 StRS, 38 SyRS, 79 SwRS — auf genau den 7 vorgegebenen Dateien. 5 Hypothesen (SyRS-36, SwRS-5, SwRS-6, SwRS-19, SwRS-53).
---
## 1. Modulinventar (Schritt 0, vor der ersten Anforderung erstellt)
Das Inventar ist die Bezugsgröße der Abdeckung. Es wurde während der Analyse ergänzt, aber nicht gekürzt.
| Nr | Modul / Komponente | Pfad | Fachliche Aufgabe |
|---|---|---|---|
| M01 | Anmelde-/Sitzungsverwaltung | src\backend\Centron.BL\Administration\Logins | Anmeldekette (Basic/AD/OIDC), Connection-Tickets, Access Tokens, 2FA-Gate |
| M02 | Rechteverwaltung | src\backend\Centron.BL\Administration\Rights | RBAC-Prüfungen (Sichbenu/Sichmemb/Sichtrus), Standardrechte, Cache |
| M03 | Lizenzverwaltung | src\backend\Centron.BL\Administration\Licensing | Lizenzprüfung, Sitzplätze, Modullizenzen |
| M04 | System-/Webservice-Konfiguration | src\backend\Centron.BL\Administration\WebServiceConfiguration, Administration\Settings | WebServiceConfig.xml, App-/ApplicationSettings |
| M05 | Nummernkreise & Firmenstammdaten | src\backend\Centron.BL\Administration\Company | Zählervergabe je Objektart, Mandantenstammdaten |
| M06 | Zentrale Konfigurations-DB / MasterKey | src\backend\Centron.BL\Administration\CentronConfigDb (+SQLManagement) | CenConf-Zugriff, MasterKey-Speicher, DB-Infos für Lizenzserver |
| M07 | Passwort-Manager | src\backend\Centron.BL\PasswordManager | verschlüsselter Vault für Kundenzugangsdaten |
| M08 | Legacy-Passwortablage | src\backend\Centron.BL\PasswordManagementArea | Klartextablage mit Zugriffsprotokoll (Altmodul) |
| M09 | TOTP-Zwei-Faktor-Modul | src\backend\Centron.BL\TwoFactorAuthenticator | Authenticator-App-PIN-Prüfung |
| M10 | PDF-Signierung | src\backend\Centron.BL\Security | TSA-/Zertifikatseinstellungen, PDF-Signatur |
| M11 | Beleg-Engine | src\backend\Centron.BL\Sales\Receipts | alle Belegarten: Status, Storno, Nummern, ESR, Barcode, Weiterverarbeitung |
| M12 | Mahnwesen | src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning | Mahnstufen, Mahnläufe, Historie |
| M13 | Zeiterfassung / Helpdesk-Timer | src\backend\Centron.BL\Sales\Support, WebServices\Sales\Support | Timer-Schutz- und Rechteregeln |
| M14 | Kalender / Terminplanung | src\backend\Centron.BL\Sales\Calendar (+BL\Calendar) | Terminregeln, Zuweisungsrechte, Graph-Sync |
| M15 | Kundenstamm | src\backend\Centron.BL\Accounts | Kundenverwaltung, Sonderpreise, offene Posten |
| M16 | Bankverbindungen | src\backend\Centron.BL\Accounting | Kundenbankkonten (SEPA-/Mandatsquelle) |
| M17 | Zahlungen & Online-Banking-Buchung | src\backend\Centron.BL\Finances | Zahlungsverbuchung, Zuordnung zu Rechnungen |
| M18 | Einkauf | src\backend\Centron.BL\Purchasing | Lieferantenstamm, filialbezogene Bestellungen, Vorschlagslisten |
| M19 | Artikel & Lager & Steuer | src\backend\Centron.BL\Warehousing | Artikelstamm, MwSt-Kette (TaxBL), Katalogimporte, Lager |
| M20 | Produktion | src\backend\Centron.BL\Production | Fertigungsaufträge/-items (lizenzgebunden) |
| M21 | Prozess-/Workflow-Engine | src\backend\Centron.BL\Processes | konfigurierbare Prozesse, Validierung, Mail-Scanner-Anbindung |
| M22 | Ticketprojekte | src\backend\Centron.BL\TicketProjects | Projektvorgänge, Nummerierung, Soft-Delete |
| M23 | Asset-Management / DocuBoard | src\backend\Centron.BL\DocuBoard | AD-Anbindung, Geräte-/Benutzer-Assets |
| M24 | Mail-Scanner-Anbindung | src\backend\Centron.BL\MailScanner | automatisierte Eingangsverarbeitung |
| M25 | Änderungshistorie (BL) | src\backend\Centron.BL\ChangeTracking | Import-Historie (Feld-Tracking liegt in DAO) |
| M26 | Statistiken | src\backend\Centron.BL\Statistics | gecachte Umsatz-/Ticket-/Auftragsstatistiken |
| M27 | MyDay | src\backend\Centron.BL\MyDay | Tagesarbeitsplatz, Arbeitspakete |
| M28 | MyCentron | src\backend\Centron.BL\MyCentron | persönliche Dashboards |
| M29 | Chats | src\backend\Centron.BL\Chats | interner Chat |
| M30 | Benachrichtigungen | src\backend\Centron.BL\Notifications, NexusNotifications | zentrale/lokale Meldungen |
| M31 | IT-Planer | src\backend\Centron.BL\ItPlanner | Checklisten-Kategorien, Helpdesk-Sync |
| M32 | Kundengeräte | src\backend\Centron.BL\Devices | Geräteverwaltung mit Soft-Delete/Protokoll |
| M33 | ProductMatrix | src\backend\Centron.BL\ProductMatrix | Produktmatrix-Auswertungen |
| M34 | Berichts-Engine | src\backend\Centron.BL\ReportEngine, Reporting | PDF-Strategien, Reportverwaltung |
| M35 | Massenupdates | src\backend\Centron.BL\MassUpdate | Massenänderungsvorlagen |
| M36 | Textbausteine | src\backend\Centron.BL\TextModuleArea | Beleg-/Kommunikationstexte |
| M37 | TradePool | src\backend\Centron.BL\TradePool | Partnertausch-Katalogimport |
| M38 | Kunden-Selbstservice & Videoportal | src\backend\Centron.BL\SelfCare, VideoPortal | Formulare, Videzuweisungen |
| M39 | KI-Anbindung | src\backend\Centron.BL\ArtificialIntelligence | Multi-Anbieter-KI-Clients, Kontextfenster |
| M40 | Telemetrie | src\backend\Centron.BL\Telemetry | Telemetrie-/Lizenzkind-Zuordnung |
| M41 | Datenaustausch / Buchhaltung | src\backend\Centron.BL\DataExchange | Buchhaltungsex-/Import, EDI-Orchestrierung, Connectors (DocBee, Tanss, Rmm u. a.) |
| M42 | BL-Webservice-Orchestrierung | src\backend\Centron.BL\WebServices | ~464 *WebServiceBL als Dienstfassade der Fachlogik |
| M43 | Mitarbeiterverwaltung | src\backend\Centron.BL\EmployeeArea | AppUser-Verwaltung, Urlaub (Altmodul) |
| M44 | Wiedervorlagen | src\backend\Centron.BL\ToDoArea | typisierte Frist-/Erinnerungsobjekte |
| M45 | Checklisten | src\backend\Centron.BL\CheckListArea | Checklisten und Vorlagen an Fachobjekten |
| M46 | Aufgaben-Manager | src\backend\Centron.BL\TaskManager | wiederkehrende Aufgaben mit Aktionen |
| M47 | Logistik-Einstellungen | src\backend\Centron.BL\Logistics | Kommissionier-/Lagerregeln |
| M48 | Telefonprotokoll | src\backend\Centron.BL\Tapi | Anrufjournal (TAPI/Graph) |
| M49 | Mail-Infrastruktur | src\backend\Centron.BL\Mail, Mailings | SMTP/EWS/Graph, verschlüsselte Geheimnisse, Serienmails |
| M50 | Wissensobjekte | src\backend\Centron.BL\Tags, IndexSearch, DocumentationArea | Tags, Volltextsuche, Dokumentation |
| M51 | Handel-Dienste | src\backend\Centron.BL\VoucherManagement, Buying, BusinessPartner | Gutscheinbarcodes, Distributor-/Lieferantensuche |
| M52 | Objektverknüpfungen | src\backend\Centron.BL\ObjectExternalReferences, Urls, WebLinks, Customizations | externe Referenzen, Links, benutzerdefinierte Tabellen |
| M53 | Stammdaten-/Systemdienste | src\backend\Centron.BL\SystemArea, Modules, Start, Storage, CountryArea, Transactions, SocialMedia | Systemtabelle, Modulregistrierung, Währungskurse, Social Stream, veraltete Module |
| M54 | Datenschicht (DAO) | src\backend\Centron.DAO | NHibernate, 983 Mappings, NamedQueries, Change-Tracking-Listener, Repositories |
| M55 | Entitätsmodell | src\backend\Centron.Entities | 1.179 Dateien, 743 BaseEntity-Klassen |
| M56 | Schnittstellen / Verträge | src\backend\Centron.Interfaces | Rechte-/Lizenzkonstanten, Fachverträge |
| M57 | Common-Bibliothek | src\backend\Centron.Common | Hash/AES (TextCoding), Logging, IO, Ini, Netz |
| M58 | Core-Bibliothek | src\shared\Centron.Core | TOTP, PdfScanning, ImprintParser, Mvvm |
| M59 | Gateway EDI-Verteilermodelle | src\backend\Centron.Gateway\EDI_*, OpenTrans*, Concerto | XSD-Nachrichtenmodelle je Distributor |
| M60 | Gateway ZUGFeRD-Modell | src\backend\Centron.Gateway\ZUGFeRD21_Extended | generiertes CII-Schema-Objektmodell |
| M61 | Gateway OnlineBanking | src\backend\Centron.Gateway\OnlineBanking | FinTS/HBCI-Client (libfintx) |
| M62 | Gateway DataExchange | src\backend\Centron.Gateway\DataExchange | 15+ Buchhaltungsformate, SEPA-Generator |
| M63 | Gateway Import/Export & Portal | src\backend\Centron.Gateway\Import, Export, MspCollector, Portal | EDI-Dispatch (Avnet/BBG), MSP-Abrechnungen, Portal-Client |
| M64 | Web-Service-Host | src\webservice\Centron.Host (Stamm) | Start/Lizenzvorprüfung, Hosting, CORS, Timeouts, SignalR-Registrierung |
| M65 | Legacy-REST-Vertrag | src\webservice\Centron.Host\Services | 1.254 WebInvoke-Methoden in Domain-Parts |
| M66 | WcfBridge & Interceptors | src\webservice\Centron.Host\AspNetCore\WcfBridge | /REST, /RESTC, Interceptor-Kette (Auth, Logging, Telemetrie) |
| M67 | Echtzeithubs | src\webservice\Centron.Host\AspNetCore\SignalR, RealTimeServices | 4 Hubs, Ticket-Mapping, SecretKey-Policy |
| M68 | Hintergrunddienste & Telemetrie | src\webservice\Centron.Host\AspNetCore\HostedServices, Telemetry | ~35 geplante Dienste, Telemetrie-Upload |
| M69 | Hilfe-Seite | src\webservice\Centron.Host\HelpPage | generierte API-Dokumentation |
| M70 | Moderne Controller-API | src\webservice\Centron.Controllers | 41 Controller, Autorisierungsattribute, JWT-Austausch, ZUGFeRD-Import |
| M71 | WebServices.Core (Client/DTOs) | src\webservice\Centron.WebServices.Core | Clientverbindung, Request/Ticket, DTOs, ReceiptPriceHelper |
| M72 | Host-Varianten & ConnectionManager | src\webservice\Centron.Host.Console, WindowsService, c-entron.misc.ConnectionManager | Docker/Konsole/Windows-Dienst, Admintool mit Health-Check |
| M73 | Nexus-Host | src\nexus\CentronNexus.Host | Blazor-Server-Host, Cookie/OIDC, Ports |
| M74 | ServiceBoard | src\nexus\CentronNexus\ServiceBoard | Ticketlisten, Dispatch, Scheduler, MyDay-Integration |
| M75 | WebCart | src\nexus\CentronNexus\WebCart | Kunden-Shop mit Freigabewesen |
| M76 | WebOffer | src\nexus\CentronNexus\WebOffer | Token-basiertes Online-Angebot |
| M77 | Dokument-Signierung & geteilte Dokumente | src\nexus\CentronNexus\DocumentSigning, Office | SEPA-/AVV-/Belegsignatur, PDF-Bereitstellung |
| M78 | Produktions-Terminal | src\nexus\CentronNexus\ProductionOrderManagement | Shopfloor-Terminal für Arbeitsschritte |
| M79 | Management & Settings | src\nexus\CentronNexus\Management, Settings, Controllers | Admin-Router, OIDC-/Branding-Einstellungen |
| M80 | Outlook-Add-in | src\nexus\CentronNexus.OutlookAddIn | Kunden/Tickets/Belege im Mail-Kontext |
| M81 | Desktop-Shell | src\centron\Centron.WPF.UI | App/FrontWindow, Anmeldung, Modulregistrierung, Heartbeat |
| M82 | Modulframework | src\centron\Centron.WPF.UI.Extension | Modul-/MVVM-Verträge |
| M83 | Oberflächen-/Verwaltungsbibliothek | src\centron\Centron.WPF.UI Views, Managers, Localization, Start | Dialoge, Lokalisierung, Command-Palette |
| M84 | finAPI-Client | src\apis\Centron.APIs.FinAPI | Banking-REST (Konten, Transaktionen) |
| M85 | ebInterface-Client | src\apis\Centron.Api.EbInterface | österreichische E-Rechnung 4p3 |
| M86 | Versand-Clients | src\apis\Centron.Api.Gls, Centron.Api.Shipcloud | Labels, Tracking |
| M87 | Artikeldaten-Clients | src\apis\Centron.APIs.CopDataAccess, EgisDataAccess, IcecatDataAccess, ITscopeDataAccess | Produkt-/Marktdaten |
| M88 | Datenbankschema | SSMS_DB_SCHEMA.sql | vollständiges MSSQL-Schema (76.793 Zeilen), Constraints |
| M89 | Build / Deployment | deployment, azure, docker, scripts, assemblies | WiX-Installer, Pipelines, Container, Signierung |
| M90 | Tests | tests | 378 Dateien (Unit/DAO/Integration/E2E/Playwright) |
| M91 | Projektdokumentation | docs, README.md, CentronRights.md, .github | Architektur-/Feature-Doku, Rechtekatalog, Contribution-Regeln |
---
## 2. Abdeckungstabelle (Schritt 0b/0c)
Einstufung: `tief` (Regeln mit PRIMÄR-Belegen und Zustandslogik), `mittel` (Kernregeln belegt, Randbereich offen), `flach` (≥ 1 belegbare Anforderung, Umfang nur gestreift), `nicht analysiert` (— tritt nicht auf). Jede Zeile des Inventars ist enthalten; jedes Modul hat ≥ 1 Anforderung.
| Nr | Modul | Abdeckung | Anzahl Anforderungen | Anforderungs-IDs |
|---|---|---|---|---|
| M01 | Anmelde-/Sitzungsverwaltung | tief | 8 | SyRS-2, SyRS-3, SyRS-4, SwRS-1, SwRS-2, SwRS-4, SwRS-5, SwRS-6 |
| M02 | Rechteverwaltung | tief | 4 | SyRS-7, SwRS-7, SwRS-8, SwRS-9 |
| M03 | Lizenzverwaltung | tief | 3 | SyRS-9, SyRS-36, SwRS-36 |
| M04 | System-/Webservice-Konfiguration | mittel | 2 | SyRS-12, SwRS-48 |
| M05 | Nummernkreise & Firmenstammdaten | tief | 2 | SwRS-10, SwRS-11 |
| M06 | Zentrale Konfigurations-DB / MasterKey | mittel | 1 | SwRS-22 |
| M07 | Passwort-Manager | tief | 1 | SwRS-22 |
| M08 | Legacy-Passwortablage | mittel | 1 | SwRS-23 |
| M09 | TOTP-Zwei-Faktor-Modul | mittel | 2 | SwRS-26, SwRS-53 |
| M10 | PDF-Signierung | flach | 1 | SwRS-24 |
| M11 | Beleg-Engine | tief | 9 | SwRS-11, SwRS-13, SwRS-14, SwRS-15, SwRS-16, SwRS-17, SwRS-20, SwRS-45, SwRS-46 |
| M12 | Mahnwesen | tief | 2 | SwRS-18, SwRS-19 |
| M13 | Zeiterfassung / Helpdesk-Timer | tief | 2 | SwRS-20, SwRS-21 |
| M14 | Kalender / Terminplanung | flach | 1 | SwRS-55 |
| M15 | Kundenstamm | mittel | 2 | SwRS-29, SwRS-46 |
| M16 | Bankverbindungen | flach | 1 | SwRS-56 |
| M17 | Zahlungen & Online-Banking-Buchung | tief | 3 | SyRS-17, SwRS-16, SwRS-44 |
| M18 | Einkauf | flach | 1 | SwRS-57 |
| M19 | Artikel & Lager & Steuer | tief | 3 | SwRS-13, SwRS-15, SwRS-54 |
| M20 | Produktion | mittel | 2 | StRS-11, SwRS-33 |
| M21 | Prozess-/Workflow-Engine | flach | 1 | SwRS-58 |
| M22 | Ticketprojekte | flach | 1 | SwRS-59 |
| M23 | Asset-Management / DocuBoard | flach | 1 | SwRS-60 |
| M24 | Mail-Scanner-Anbindung | flach | 1 | SwRS-58 |
| M25 | Änderungshistorie (BL) | flach | 1 | SwRS-39 |
| M26 | Statistiken | mittel | 1 | SwRS-51 |
| M27 | MyDay | flach | 1 | SwRS-61 |
| M28 | MyCentron | flach | 1 | SwRS-62 |
| M29 | Chats | flach | 1 | SyRS-8 |
| M30 | Benachrichtigungen | flach | 1 | SyRS-8 |
| M31 | IT-Planer | flach | 1 | SwRS-63 |
| M32 | Kundengeräte | flach | 1 | SwRS-64 |
| M33 | ProductMatrix | flach | 1 | SwRS-65 |
| M34 | Berichts-Engine | mittel | 1 | SyRS-30 |
| M35 | Massenupdates | flach | 1 | SwRS-66 |
| M36 | Textbausteine | flach | 1 | SwRS-52 |
| M37 | TradePool | flach | 1 | SwRS-67 |
| M38 | Kunden-Selbstservice & Videoportal | flach | 1 | SwRS-68 |
| M39 | KI-Anbindung | mittel | 1 | SyRS-34 |
| M40 | Telemetrie | flach | 1 | SyRS-24 |
| M41 | Datenaustausch / Buchhaltung | tief | 2 | SwRS-42, SwRS-45 |
| M42 | BL-Webservice-Orchestrierung | mittel | 1 | SyRS-6 |
| M43 | Mitarbeiterverwaltung | flach | 1 | SwRS-69 |
| M44 | Wiedervorlagen | flach | 1 | SwRS-70 |
| M45 | Checklisten | flach | 1 | SwRS-71 |
| M46 | Aufgaben-Manager | flach | 1 | SwRS-72 |
| M47 | Logistik-Einstellungen | flach | 1 | SwRS-73 |
| M48 | Telefonprotokoll | flach | 1 | SyRS-33 |
| M49 | Mail-Infrastruktur | flach | 2 | SyRS-29, SwRS-74 |
| M50 | Wissensobjekte | flach | 1 | SwRS-75 |
| M51 | Handel-Dienste | flach | 1 | SwRS-76 |
| M52 | Objektverknüpfungen | flach | 1 | SwRS-77 |
| M53 | Stammdaten-/Systemdienste | flach | 1 | SwRS-78 |
| M54 | Datenschicht (DAO) | tief | 4 | SyRS-23, SwRS-39, SwRS-40, SwRS-41 |
| M55 | Entitätsmodell | flach | 1 | SwRS-40 |
| M56 | Schnittstellen / Verträge | flach | 2 | SwRS-9, SwRS-49 |
| M57 | Common-Bibliothek | tief | 2 | SwRS-1, SwRS-22 |
| M58 | Core-Bibliothek | flach | 1 | SwRS-26 |
| M59 | Gateway EDI-Verteilermodelle | flach | 1 | SyRS-19 |
| M60 | Gateway ZUGFeRD-Modell | flach | 1 | SyRS-15 |
| M61 | Gateway OnlineBanking | tief | 1 | SwRS-44 |
| M62 | Gateway DataExchange | tief | 2 | SwRS-43, SwRS-45 |
| M63 | Gateway Import/Export & Portal | flach | 2 | SyRS-19, SyRS-35 |
| M64 | Web-Service-Host | tief | 5 | SyRS-9, SyRS-10, SyRS-11, SyRS-13, SyRS-26 |
| M65 | Legacy-REST-Vertrag | mittel | 1 | SyRS-6 |
| M66 | WcfBridge & Interceptors | tief | 1 | SwRS-79 |
| M67 | Echtzeithubs | mittel | 1 | SyRS-8 |
| M68 | Hintergrunddienste & Telemetrie | mittel | 2 | SyRS-10, SyRS-24 |
| M69 | Hilfe-Seite | flach | 1 | SyRS-37 |
| M70 | Moderne Controller-API | tief | 2 | SyRS-7, SyRS-16 |
| M71 | WebServices.Core (Client/DTOs) | mittel | 2 | SyRS-6, SwRS-14 |
| M72 | Host-Varianten & ConnectionManager | flach | 2 | SyRS-11, SyRS-12 |
| M73 | Nexus-Host | tief | 1 | SyRS-14 |
| M74 | ServiceBoard | tief | 2 | SwRS-34, SwRS-35 |
| M75 | WebCart | tief | 2 | SwRS-29, SwRS-30 |
| M76 | WebOffer | tief | 1 | SwRS-31 |
| M77 | Dokument-Signierung & geteilte Dokumente | mittel | 1 | SwRS-32 |
| M78 | Produktions-Terminal | mittel | 1 | SwRS-33 |
| M79 | Management & Settings | mittel | 1 | SwRS-35 |
| M80 | Outlook-Add-in | mittel | 1 | SyRS-31 |
| M81 | Desktop-Shell | tief | 3 | SwRS-36, SwRS-37, SwRS-38 |
| M82 | Modulframework | flach | 1 | SwRS-36 |
| M83 | Oberflächen-/Verwaltungsbibliothek | flach | 1 | SyRS-27 |
| M84 | finAPI-Client | mittel | 1 | SwRS-49 |
| M85 | ebInterface-Client | mittel | 1 | SwRS-50 |
| M86 | Versand-Clients | mittel | 1 | SwRS-47 |
| M87 | Artikeldaten-Clients | flach | 1 | SyRS-20 |
| M88 | Datenbankschema | tief | 2 | SyRS-22, SwRS-12 |
| M89 | Build / Deployment | flach | 1 | SyRS-32 |
| M90 | Tests | flach | 1 | SyRS-32 |
| M91 | Projektdokumentation | flach | 1 | SwRS-9, SwRS-42 |
---
## 3. Konsistenzcheck über das gesamte Anforderungs-Set
Maschinell geprüft (Skript über die drei Anforderungsdateien):
| Prüfpunkt | Ergebnis |
|---|---|
| Doppelte / mehrfach vergebene IDs | **0** — 139 IDs (StRS 22, SyRS 38, SwRS 79), jede einmalig |
| Anforderungen ohne Beleg | **0** — alle 139 Anforderungen führen einen `Belege:`-Abschnitt |
| Anforderungen ohne `Übernahmewürdigkeit` | **0** — 139/139 gesetzt |
| Tracelinks auf nicht existierende IDs | **0** — alle referenzierten StRS-/SyRS-/SwRS-IDs existieren |
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung | **keine gefunden** — fachlich gleichartige Konzepte in getrennten Implementierungen sind markiert (s. u.); Derselbe-Sachverhalt-auf-mehreren-Ebenen-Fälle (z. B. StRS-4 ↔ SwRS-16 Belegstatus, StRS-13 ↔ SwRS-42 E-Rechnung) sind bewusst **keine** Konsolidierungsfälle und über Tracelinks verbunden |
| Hypothesen-Abgleich `Hypothesen.md` ↔ Inline-Markierungen | **deckungsgleich** — Inline: SyRS-36, SwRS-5, SwRS-6, SwRS-19, SwRS-53 (maschinell extrahiert); `Hypothesen.md` nennt exakt diese fünf, keine zusätzlichen freien Fragen |
Konsolidierungskandidaten (Feld `Konsolidierung` in den Anforderungen):
| Kandidat | Anforderungen | Konflikt |
|---|---|---|
| Kundenzugangsdaten-Ablage | SwRS-22 ↔ SwRS-23 | Passwort-Manager (AES-Vault) vs. Legacy-Passwortablage (Klartext) — zwei Datenhaltungen für denselben Gegenstand |
| Zweitfaktor-Mechanismen | SwRS-25 ↔ SwRS-26 ↔ SwRS-28 (auch SwRS-27) | TOTP-Modul, RADIUS/E-Mail-Link-Gate und separater TOTP-Code als parallel existierende Implementierungen eines fachlichen Zwecks |
| Geheimnisverwaltung | SwRS-48 ↔ SwRS-49 ↔ SwRS-74 | vier Ablageformen für Zugangsdaten (Klartext-Einstellungen, Entitäten, Quelltextkonstanten, AES-verschlüsselte Sonderfälle) |
| Nummernvergabe | SwRS-10 ↔ SwRS-11 | Zählermechanik vs. belegartspezifischer Pfad inkl. separater Vorlagenzähler |
| Asset-Konzept | SwRS-60 ↔ SwRS-64 (und vorgegebener Fall „Stammblätter vs. Assets") | Geräte/Assets in mehreren Datenhaltungen (Devices, DocuBoard, Stammblätter) — im Zielsystem zu einem Asset-Konzept zusammenführen |
---
## 4. Liste der risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
Belegsituation: `PRIMÄR` = durchsetzende Stelle (Datei/Klasse/Methode/Prüfung) benannt; sonst `[HYPOTHESE]`.
| ID | Titel | Risikobereich | PRIMÄR vorhanden? | Kennzeichnung |
|---|---|---|---|---|
| SwRS-1 | Passwortprüfung SHA-1 | Sicherheit | ja (BasicAuthenticator.AuthenticateInternal) | belegt |
| SwRS-2 | Kennwort-Mindestlängen | Sicherheit | ja (UsersBL.IsValidAppUserPassword; WebAccountBL.UpdatePassword) | belegt |
| SwRS-3 | Kennwort per Klartext-Mail | Sicherheit | ja (WebAccountBL.SendWebAccountPasswordMail) | belegt |
| SwRS-4 | Konto-Sperrkriterien | Sicherheit | ja (Authenticator.ValidateAppUser) | belegt |
| SwRS-5 | Kennwortalter ohne Ablaufprüfung | Sicherheit | nein | **HYPOTHESE** |
| SwRS-6 | Keine Fehlversuchs-Sperre | Sicherheit | nein | **HYPOTHESE** |
| SwRS-7 | RBAC-Prüfung mit Cache | Berechtigung | ja (AppRightsBL.HasUserRight) | belegt |
| SwRS-8 | Standardrechte-Seed | Berechtigung | ja (AppRightsBL.GetDefaultRightsStructureFileContent) | belegt |
| SwRS-9 | Helpdesk-Rechtekatalog | Berechtigung | ja (HelpdeskTimerWebServiceBL — EDIT_TIME/OWN_TIME_EDIT) | belegt |
| SwRS-13 | MwSt-Satzkette nach Belegdatum | Abrechnung | ja (TaxBL.GetTaxRateForReceiptItem) | belegt |
| SwRS-14 | Preis-/Steuerberechnung, Rundung | Abrechnung | ja (ReceiptPriceHelper.CalculateTaxPrice) | belegt |
| SwRS-15 | MwSt-Pflicht / Ausweisbarkeit | Abrechnung | ja (ReceiptItemBL; ReceiptBL) | belegt |
| SwRS-16 | Belegstatusmaschine + Zahlungskopplung | Abrechnung | ja (ReceiptBL, Zeilen 4925-4950) | belegt |
| SwRS-17 | Stornierung mit Schutzbedingungen | Abrechnung | ja (ReceiptInvoiceBL, Zeilen 154-186) | belegt |
| SwRS-18 | Mahnstufen + Protokoll | Abrechnung | ja (DunningRunBL.ExecuteDunningRun) | belegt |
| SwRS-19 | Mahnlauf-Auswahlkriterien | Abrechnung | nein | **HYPOTHESE** |
| SwRS-20 | Abgerechnete Zeiten gesperrt | Abrechnung | ja (HelpdeskTimerWebServiceBL.CheckTimerCanBeMoved/ThrowIfInvalidHelpdeskTimer) | belegt |
| SwRS-21 | Zeiterfassungs-Rechte | Berechtigung/Abrechnung | ja (HelpdeskTimerWebServiceBL, Zeilen 359-377) | belegt |
| SwRS-22 | Passwort-Manager-Vault + Exportrecht | Sicherheit | ja (PasswordManagerBL, Zeilen 551/700/894) | belegt |
| SwRS-23 | Legacy-Passwortablage Klartext | Sicherheit | ja (PasswordManagementKeywordBL) | belegt |
| SwRS-24 | PDF-Signatur-Einstellungen geschützt | Sicherheit | ja (PdfSigningBL, Zeile 60) | belegt |
| SwRS-25 | 2FA-Regelwerk | Sicherheit | ja (TwoFactorAuthBL.ValidateTwoFactor/HasToValidateTwoFactor) | belegt |
| SwRS-26 | TOTP-Eigenschaften | Sicherheit | ja (TwoFactorAuthenticator + TwoFactorAuthenticationBL) | belegt |
| SwRS-27 | E-Mail-2FA 120 s in-memory | Sicherheit | ja (EmailTwoFactorValidator.ValidateCredentials) | belegt |
| SwRS-28 | RADIUS-Secret verschlüsselt | Sicherheit | ja (RadiusTwoFactorValidator; WebServiceConfigSerializer) | belegt |
| SwRS-35 | Nexus-Anmeldetypen/Lizenzgates | Berechtigung | ja (AuthService.Login; Authorize-Attribute) | belegt |
| SwRS-36 | Modulregistrierung nach Lizenz/Rechten | Berechtigung | ja (ModuleRegistration.DoRegisterCentronModules) | belegt |
| SwRS-48 | Zugangsdaten unverschlüsselt | Sicherheit | ja (ApplicationSettingID + ReceiptWebServiceBL-Klartextlesung) | belegt |
| SwRS-49 | finAPI-Geheimnisse im Quelltext | Sicherheit | ja (OnlineBankingFinApiBL.GetFinApiClientCredentials) | belegt |
| SwRS-51 | Ticketstatistik nur mit Controlling-Recht | Berechtigung | ja (CacheTicketStatisticsBL.GetAll) | belegt |
| SwRS-53 | TOTP-Schlüsselspeicherung | Sicherheit | nein | **HYPOTHESE** |
| SwRS-69 | Benutzerkontenverwaltung rechtlich geschützt | Berechtigung | ja (AppUserBL.SaveOrUpdateAppUser, Zeilen 138-140) | belegt |
| SwRS-79 | Legacy-REST: Ticket-/Anwendungs-/Web-Account-Prüfung | Sicherheit/Berechtigung | ja (AuthenticateInterceptor.InterceptExecution) | belegt |
| SyRS-3 | Access-Token-Authentifizierung | Sicherheit | ja (AccessTokenBL.ValidateToken) | belegt |
| SyRS-4 | Anmeldeverfahren | Sicherheit | ja (AuthenticatorFactory; Authenticator.ValidateRights) | belegt |
| SyRS-5 | Zwei-Faktor-Authentifizierung | Sicherheit | ja (TwoFactorAuthBL; BasicAuthenticator) | belegt |
| SyRS-7 | API-Rechteautorisierung (401/403) | Berechtigung | ja (UserRightAuthorizationFilter.OnAuthorization) | belegt |
| SyRS-13 | HTTPS optional, CORS offen | Sicherheit | ja (CentronHost.UseCors/UseHttps-Zweig) | belegt |
| SyRS-14 | Portal-Auth (Cookie/OIDC/Ports) | Sicherheit | ja (Program.AddCookie/AddOpenIdConnect) | belegt |
| SyRS-36 | Verhalten nach Lizenzablauf | Sicherheit/Lizenz | nein | **HYPOTHESE** |
**Verstoßbilanz:** Keine risikorelevante Anforderung ist ohne PRIMÄR-Beleg und gleichzeitig als `belegt` geführt; die fünf Fälle ohne PRIMÄR-Beleg (SwRS-5, SwRS-6, SwRS-19, SwRS-53, SyRS-36) sind konsequent als `[HYPOTHESE]` markiert.
---
## 5. Bekannte Lücken (offene Punkte ohne zugehörige Anforderung)
Diese Punkte sind bewusst **nicht** als Anforderungen/Hypothesen formuliert worden, weil sie keine belegbare Aussage über das Bestandssystem tragen:
1. **Ticket-Statusmaschine des Helpdesks** (Statuswerte, Übergänge, Aktivitäten) ist nur über Rechte-/Timer-Belegteile sichtbar; das vollständige Statusmodell (inkl. C-FLOW-Vorlagen) wurde nicht extrahiert.
2. **Beleg-Weiterverarbeitungsgraph** (`ReceiptProgressionBL`, `ForwardReceipt*`, `IReceiptSpecificLogic`-Verzweigungen) ist nur punktuell belegt; ein vollständiger Belegfluss-Graph wäre eigene Iteration.
3. **`RechKopf.FreigabeStatus`** (Freigabewesen) — Semantik der Werte ungeklärt.
4. **ZUGFeRD21_Extended-Objektmodell** wird im Quellbestand nicht instanziiert (Suchbefund); es dient vermutlich nur als Schema-Referenz — Verwendungsentscheidung offen.
5. **BBG-Export** (`BBGExport.Export`) ist ein leerer Stub; der tatsächliche Versand läuft über `BBGWebserviceConnect` — ob der Export-Dispatcher aktiv genutzt wird, ist unklar.
6. **CAMT-Import** existiert nicht (nur MT940/Swift via FinTS und finAPI-JSON); **Zahlungsausgang** via finAPI ist nicht implementiert (nur Datenmodelle).
7. **E-Mail-2FA bei mehreren Dienstinstanzen**: Codes liegen prozesslokal (`ConcurrentDictionary`); Load-Balancing-Verhalten ist undefiniert.
8. **TOTP-Wiederholungsschutz**: PINs im Toleranzfenster werden mehrfach akzeptiert (kein Replay-Guard).
9. **Klartext-Übertragung des Kennworts** zum Dienst (clientseitige Hashing-Vorstufen im Delphi-Client nicht im Quellbestand).
10. **Centron.Office.Client** (Lizenzbibliothek) ist nicht im Quellbestand; Ablauf-/Grace-Verhalten unklar (→ SyRS-36).
11. **KanbanPage** im ServiceBoard ist ein funktionsloser Prototyp (leerer Karten-Loop).
12. **Veraltete Module**: `BL\Storage\StorageBL` („Obsolete … Replaced with InventoryBL"), `EmployeeHolidayBL` („obsolete and should be deleted"), Mailing-Daten nur Version 2, `Centron.Core.TotpAuth` ohne gefundene Verwendung.
13. **Rate-Limiting/Throttling** am Web-Service ist im Quellbestand nicht vorhanden (vermutlich extern zu lösen).
14. **Nexus-Kundenformulare/öffentliche Dokumente** (CustomerPortalForm*/PublicDocuments-Seiten) nur oberflächlich gesichtet.
---
## 6. Selbstbewertung
**Modultiefe (absolute Zahlen):**
- tief: **24** Module (u. a. Anmelde-/Sitzungsverwaltung, Rechte, Lizenz, Nummernkreise, Beleg-Engine, Mahnwesen, Zeiterfassung, DAO, Common/TextCoding, Gateway OnlineBanking/DataExchange, Web-Service-Host, WcfBridge, Controller-API, Nexus-Host/ServiceBoard/WebCart/WebOffer, Desktop-Shell, DB-Schema)
- mittel: **21** Module
- flach: **46** Module
- nicht analysiert: **0** Module (kein Inventareintrag ohne Anforderung oder Begründung)
**Mindestabdeckung:** Erreicht — alle 91 Inventarmodule haben ≥ 1 Anforderung (Abdeckungstabelle, Spalte Anforderungs-IDs). Kein Modul musste als `nicht analysiert` geführt werden; der > 10 %-Schwellenwert ist damit unberührt. Die Vertiefung (Schritt 0c) wurde zuerst auf Authentifizierung, Berechtigungen und Abrechnung/Nummernwesen angewendet.
**Dünne Belegstellen** (hoher SEKUNDÄR-/KONTEXT-Anteil oder Hypothese):
- SwRS-65 (ProductMatrix), SwRS-57 (Einkaufsprozess), SwRS-63 (IT-Planer-Sync), SwRS-76 (Gutscheine), SwRS-77 (externe Referenzen) — jeweils nur Struktur-/Konfigurationsbelege, keine tiefere Regelprüfung.
- Hypothesen: SwRS-5 (Kennwortalter), SwRS-6 (Login-Sperre), SwRS-19 (Mahnlauf-Auswahl), SwRS-53 (TOTP-Speicherung), SyRS-36 (Lizenzablauf) — Ursache jeweils: Logik liegt außerhalb des sichtbaren Quellbestands (Delphi-Vorgänger, externe Bibliothek) oder wurde im Pfad nicht gefunden (negative Beobachtung, nie ein Beweis).
- UI-nahe Bereiche (WPF-Views, WebCart-Seiten) tragen überwiegend SEKUNDÄR-Belege (Labels, Seitenattribute), weil die durchsetzende Logik serverseitig liegt.
**Hypothesenführung:** Fünf Hypothesen sind geführt, weil Codebasis-Größe (≈ 77k Zeilen DB-Schema, 1.254 REST-Methoden, 983 Mappings) eine lücklose Erkundung bei diesem Umfang unrealistisch macht; jede Hypothese nennt die fehlende Information konkret. Keine einzige Hypothese zu führen wäre hier unplausibel gewesen.
**Erkenntnisse für eine Folge-Iteration (Nachschlag lohnt):**
1. **Helpdesk-Ticketstatusmodell** vollständig extrahieren (Status-/Aktivitätsenum, C-FLOW-Vorlagen) — höchste fachliche Dichte, bisher nur rechte-/zeitenseitig belegt.
2. **Beleg-Weiterverarbeitung** (`ReceiptProgressionBL`, `ForwardReceipt*`, `IReceiptSpecificLogic`) als Zustandsgraph aufnehmen — relevant für jede Neuimplementierung der Belegkette.
3. **Mahnlauf-Auswahllogik** (SwRS-19) nachvollziehen und Hypothese auflösen.
4. **`FreigabeStatus`/Freigabewesen** am Beleg klären.
5. **tests\Centron.Tests.EndToEnd (312 Dateien)** als „lebende Spezifikation" auswerten — dort sind erwartbare Systemverhalten kodifiziert.
6. **Nexus-Kundenportal-Formulare** (SelfCare/Forms) vertiefen — Kundenselbstservice ist strategisch.
7. **EDI-Nachrichtenflüsse in BL\EDI** (Opentrans21OrderBL, SupplierEdiBL) prüfen — die Gateway-Ordner enthalten nur Schemaklassen, die Orchestrierung lag außerhalb der Vertiefung.
8. **Deployment-Sicherheit** (HTTPS-Zwang, CORS, Secret-Management) als Zielsystem-Anforderung aus SwRS-48/SyRS-13 ableiten — die Bestandsbefunde sind Migrationsrisiken, nicht Vorbilder.
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse/Glossar.md
+51
View File
@@ -0,0 +1,51 @@
# Glossar
Domänenbegriffe, wie sie in StRS/SyRS/SwRS verwendet werden. Technische Bezeichner (Klassen, Spalten) verbleiben in der Originalsprache (Deutsch/Englisch der Codebasis).
| Begriff | Definition |
|---|---|
| **Beleg (Receipt)** | Oberbegriff für alle Vertriebs-/Einkaufsdokumente (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Barbeleg, Abruf/Contract, Bestellung, Wareneingang, Lieferantenrechnung). Technisch: `RechKopf`/`RechPos` u. a. Kopf-/Positionstabellen, BL-Klasse `ReceiptBL`. |
| **Belegkette (Forwarding)** | Weiterverarbeitung eines Belegs in den nächsten Belegtyp (Angebot→Auftrag→Lieferschein→Rechnung) unter Positionsübernahme. |
| **Ticket (Helpdesk)** | Servicevorgang im Helpdesk (Anfrage, Bearbeitung, Zeiten, Servicebericht). |
| **Ticket (Connection-Ticket)** | **Nicht** Helpdesk-Ticket: opaque Sitzungs-Token nach Anmeldung; läuft standardmäßig nach 30 Minuten ab (`TicketBL`). Begriffspaar im Glossar bewusst getrennt, um Mehrdeutigkeit zu vermeiden. |
| **Access Token** | Langlebiges API-Token (48 Zeichen, SHA-256-gehash) für maschinelle Zugriffe (`AccessTokenBL`). |
| **Mandant** | Hier nicht multi-tenant im Datenbestand: ein Kundenbetrieb = eine Installation = eine Datenbank (StRS-2). |
| **Filiale (Branch)** | Organisationseinheit innerhalb eines Mandanten; Basis einschränkender Rechte ("nur eigene Filiale"). |
| **Nummernkreis (NumberGroup)** | Zählerkonfiguration (`Nummernkreis`-Tabelle: NummerArt, BereichVon/Bis, Aktuell, Intervall) für fortlaufende Nummern je Objektart; Vergabe per Vergleichs-und-Tausch-Update (`NumberGroupBL`). |
| **Mahnstufe (DunningLevel)** | Eskalationsstufe None/Level1/Level2/Level3 im Mahnwesen; je Stufe Datum/Mitarbeiter protokolliert (`Mahnlauf`-Tabelle). |
| **Offene Posten** | Nicht vollständig bezahlte Rechnungen (`GrossPriceComplete - PayedGrossAmount - CreditVoucherGrossAmount`); Löschsperre für Stammdaten (SwRS-46). |
| **Gutschrift (CreditVoucher)** | Guthabenbeleg (`GutKopf`), Nummernkreis 6; wird durch Zahlungsüberschuss/Rückgabe erzeugt. |
| **Sonderpreis (SpecialPrice)** | Kunden-/Kundenklassen-spezifische Preisvereinbarung; Basis des WebCart-Artikelangebots (SwRS-29). |
| **Web-Account (WebAccount)** | Portal-Benutzerkonto eines Kunden des Anwenderbetriebs (Adressstamm), abgegrenzt vom internen `AppUser`; eigene Rechte (`WebAccountRightsConst`). |
| **Stammblatt / Asset** | Gerät/Ressource eines Kunden; im Bestand mehrere Datenhaltungen (Drucker als "Stammblätter", sonstige Hardware als "Assets", `Devices`, `DocuBoard`) — Konsolidierungskandidat (Analysebericht). |
| **ServiceBoard** | Blazor-Arbeitsbereich für Servicemitarbeiter (Ticketlisten, Scheduler, Zeiterfassung, Weiterleitung). |
| **WebCart** | Kunden-Shop im Portal (Sonderpreise, vier-Augen-Freigabe, Bestellung → Auftrag). |
| **WebReceipt / WebOffer** | Token-basiertes elektronisches Angebot mit Kundenannahme/Signatur (`/weboffer/{Token}`). |
| **Arbeitsschritt (ProductionOrderItem)** | Produktionsauftragsposition am Shopfloor-Terminal; Zustände OpenNotStarted/InProgression/Finished; exklusive Belegung (SwRS-33). |
| **Zweitfaktor (2FA)** | Zweite Authentifizierung: RADIUS, E-Mail-Link oder TOTP (Authenticator-App); globaler Schalter + Benutzer-Opt-in + Merkfristen (`TwoFactorAuthBL`). |
| **TOTP** | Zeitbasiertes Einmalpasswort, 6 Ziffern, 30-Sekunden-Schritte, ±4 Minuten Toleranz (RFC-6238-Muster, `GoogleAuthenticator`). |
| **QES** | Qualifizierte elektronische Signatur — im Bestand **nicht** implementiert; Signatur ist einfache elektronische Signatur (Grafik/Upload). |
| **Leitweg-ID** | Öffentlich-rechtliche Empfängerreferenz; ihr Vorhandensein erzwingt XRechnung-Konformität (SwRS-42). |
| **ZUGFeRD / XRechnung / Factur-X** | Deutsche/Europäische E-Rechnungsstandards; XML (UN/CEFACT CII) wird in die Rechnungs-PDF eingebettet (`factur-x.xml`). |
| **ebInterface** | Österreichisches E-Rechnungsformat (Version 4p3 implementiert). |
| **pain.008.001.08** | ISO-20022-Nachrichtentyp für SEPA-Lastschriften (CORE/B2B, Sequenztypen FRST/RCUR/OOFF/FNAL). |
| **MT940 / Swift-Segmente** | Bankkontobank-Transaktionsformat, hier via FinTS/libfintx geladen. |
| **FinTS / HBCI** | Deutsches Online-Banking-Protokoll (libfintx-Client inkl. TAN-Verfahren, decoupled "922"). |
| **finAPI** | Externer Banking-Dienst (OAuth, Kontenverbindung per Web Form, Transaktionen). |
| **Buchhaltungsnummer** | Pflichtmerkmal je Adresse für den Buchhaltungsexport (SwRS-45). |
| **I3D** | Integer-Primärschlüssel der Codebasis (z. B. `AppUser.I3D`, `RechKopf.I3D`). |
| **Named Query** | Benanntes SQL/HQL-Statement im eingebetteten Pool `NamedQueryPool.xml` (`NamedQueryManager`). |
| **ChangeLog** | Feld-Level-Änderungsprotokoll (PreUpdate-Listener): Objekt, Eigenschaft, Alt-/Neuwert, Benutzer. |
| **Wiedervorlage (ToDo)** | Frist-/Erinnerungsobjekt, typisiert an Fachbereiche gebunden (`ToDoBL`). |
| **MyDay** | Persönlicher Tagesarbeitsplatz (Arbeitselemente, Telefonate, Zeiten). |
| **MyCentron** | Persönliche Startseite mit Dashboard-Containern. |
| **TradePool** | Partnertausch-/Handelsartikel-Pool aus XML-Katalogimporten. |
| **Gateway (Centron.Gateway)** | Integrationskomponente: EDI-Formate, OpenTrans/BMEcat, ZUGFeRD-Modell, OnlineBanking, SEPA, Portal, Import/Export. |
| **EDI** | Elektronischer Datenaustausch mit Distributoren (Alltron, ALSO, EGIS, Komsa, Herweck, Avnet, BBG). |
| **Connection Manager** | WPF-Admintool für `WebServiceConfig.xml` inkl. SQL-Server-Health-Check. |
| **ApplicationKind** | Kennzeichnung der anmeldefähigen Anwendung (Desktop, Monitoring-Connector, Web …); steuert Ticketlaufzeit und Rechtegate. |
| **LicenseGuid** | GUID-Bezeichner einer Produktlizenz (`LicenseGuids`, z. B. `ProductionManagement`, `WebCart2`, `ServiceBoardWebDev`). |
| **Sitzplatz (License Seat)** | Belegte Lizenz = aktive Sitzung; Zählung je Lizenz/Benutzer/Gerät (`GetTicketCount`). |
| **E-Rechnungs-Profil** | XRechnung (öffentlicher Sektor) vs. EN16931/Comfort; bestimmt durch Leitweg-ID. |
| **RMM** | Remote Monitoring & Management-Integration (Controller/Settings im Webservice). |
| **DocBee / Nexoware / Tanss / Telekom Dive** | Externe Systeme/Kooperationen mit Connector-Schicht im Webservice. |
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse/Hypothesen.md
+45
View File
@@ -0,0 +1,45 @@
# Hypothesen
Alle Anforderungen mit `[HYPOTHESE]`-Kennzeichnung. Diese Liste enthält genau die Anforderungen, deren `Status`-Feld in StRS/SyRS/SwRS auf `HYPOTHESE` steht — keine weiteren freien Fragen (offene Punkte ohne zugehörige Anforderung stehen in der Selbstbewertung des Analyseberichts).
---
## SyRS-36 — Verhalten nach Lizenzablauf
- **Ebene:** SyRS (Systemverhalten)
- **Aussage:** Das System soll nach Lizenzablauf den Betrieb verweigern bzw. auf Lesen beschränken; das genaue Ablaufverhalten (Sperrzeitpunkt, Grace-Period, Restfunktionalität) ist aus der vorliegenden Codebasis nicht belegbar.
- **Was belegt ist:** Startabbruch bei ungültiger Lizenz (`src\webservice\Centron.Host\CentronHost.cs` — TryLoadLicense vor DB-Verbindung/-Update, CheckLicense.ThrowIfError); Modulausblendung ohne Lizenz (`src\centron\Centron.WPF.UI\Modules\ModuleRegistration.cs`); Sitzplatzablehnung (`LicenseManager.cs`, Zeilen 280-282).
- **Was fehlt:** Die Laufzeit-Ablauflogik liegt in der externen Bibliothek `Centron.Office.Client` (Namespace `Centron.Office.Client.Licensing.Version3`), die nicht im Quellbestand enthalten ist.
- **Offene Frage:** Welches Verhalten gilt im laufenden Betrieb bei Lizenzablauf (Sofortsperre? Lesemodus? Frist)?
## SwRS-5 — Kennwortalter-Felder ohne erzwungene Ablaufprüfung
- **Ebene:** SwRS (Sicherheitsregel)
- **Aussage:** Das System soll Kennwortalter konfigurierbar überwachen und abgelaufene Kennwörter beim Anmelden erzwingen; eine solche Prüfung ist im .NET-Anmelpfad nicht belegbar.
- **Was belegt ist:** Datenfelder `PasswordValidDurationDays` (`KennAendNachTagen`) und `LastPasswordChangedDate` (`LetzKennAend`) am AppUser (`src\backend\Centron.Entities\Entities\Administration\AppUser.cs`); `UpdatePassword` setzt das Datum (`UsersBL.cs`); keine Sperre gefunden.
- **Was fehlt:** Eine Anmeldezeitige Prüfung der beiden Felder; ggf. Verlagerung in den Delphi-Vorgänger oder externe Komponenten.
- **Offene Frage:** Wird das Kennwortalter tatsächlich irgendwo erzwungen, oder sind die Felder dead configuration?
## SwRS-6 — Keine serverseitige Sperre nach fehlgeschlagenen Anmeldungen
- **Ebene:** SwRS (Sicherheitsregel)
- **Aussage:** Das System soll wiederholte fehlgeschlagene Anmeldungen begrenzen (temporäre Sperre/Ratenbegrenzung); eine serverseitige Umsetzung ist im Quellbestand nicht belegbar.
- **Was belegt ist:** Der vollständig geprüfte Anmelpfad (`BasicAuthenticator.cs` → `Authenticator.cs` → `TicketBL.cs`) enthält keinen Fehlerzähler, kein Lockout, kein Rate-Limit; Felder `AuthenticationFailed`/`IsLoggedIn` existieren am AppUser ohne gefundene Logik.
- **Was fehlt:** Jeglicher belegbare Sperrmechanismus; mögliche Kompensation über Netzhürden/AD ist nicht im Artefakt sichtbar.
- **Offene Frage:** Besteht Brute-Force-Schutz außerhalb des .NET-Dienstes (Firewall, AD-Account-Policy, Reverse Proxy)?
## SwRS-19 — Auswahl der Rechnungen für einen Mahnlauf
- **Ebene:** SwRS (Abrechnungsregel)
- **Aussage:** Das System soll Rechnungen für einen Mahnlauf nach Fälligkeit und Mahnstopp-Kriterien auswählen; die genauen Auswahlkriterien (Fristen je Stufe, Stoppregeln) sind aus der Codebasis nicht belegbar.
- **Was belegt ist:** Mahnstufenmaschine Level1-3 inkl. Protokolltabelle `Mahnlauf` (`DunningRunBL.cs`, `SSMS_DB_SCHEMA.sql` Zeile 20016); Steuerfelder am Rechnungskopf (`FaelligAm`, `Mahnstufe`, `MahnStop`, `DunningStopBegin/End`); Vorlauf `GetPreviewForDunningRun` existiert.
- **Was fehlt:** Die innere Filterlogik der Auswahl (welche Fälligkeits-/Stoppregeln greifen je Stufe) wurde im Vorlauf nicht vollständig nachvollzogen.
- **Offene Frage:** Welche exakten Kriterien wählt ein Mahnlauf aus (Fälligkeitsfrist je Stufe, MahnStop-Semantik, Storni/Gutschriften-Ausschluss)?
## SwRS-53 — TOTP-Schlüsselspeicherung
- **Ebene:** SwRS (Sicherheitsregel)
- **Aussage:** Das System soll TOTP-Schlüssel verschlüsselt speichern; ob dies der Fall ist, ist aus der Codebasis nicht belegbar.
- **Was belegt ist:** Schlüsselabruf/-speicherung über Named Queries `GetAppUserTwoFactorAuthKey`/`UpdateAppUserTwoFactorAuthKey` (`src\backend\Centron.BL\TwoFactorAuthenticator\TwoFactorAuthenticationBL.cs`).
- **Was fehlt:** Eine Verschlüsselungsroutine an diesen Aufrufen wurde nicht gefunden; Klartext-Speicherung ist nicht bewiesen, nur Verschlüsselung ist unbelegt.
- **Offene Frage:** Liegt der TOTP-Schlüssel als Base32-Klartext in der Datenbank oder verschlüsselt?
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse/StRS.md
+489
View File
@@ -0,0 +1,489 @@
# StRS — Stakeholder Requirements Specification
Reverse Requirements Engineering der c-entron ERP-Suite (Legacy, C#/XAML, MSSQL) nach ISO/IEC/IEEE 29148:2018.
Belegpfade sind relativ zum Arbeitsverzeichnis (Codebasis-Stammverzeichnis) angegeben.
Ebene StRS = fachliche Sicht: Akteure, Geschäftsziele, fachliche Leistungen des Systems.
---
ID: StRS-1
Titel: ERP-Gesamtsuite für IT-Systemhäuser
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsleitung des Anwenderbetriebs, Mitarbeiter (Innen-/Außendienst)
Vorbedingung: Installation mit gültiger Lizenz und eigener Datenbank
Fakt: Die Codebasis enthält nebeneinander Fachdomänen für Helpdesk/Tickets, Vertrieb (Belege), Einkauf, Lager, Produktion, Finanzen,CRM, IT-Planung, Remote-Management und Portal (Verzeichnisse src\backend\Centron.BL\* mit je eigenen Business-Logik-Klassen; Projektdokumentation in docs\reference\ mit Referenzen zu receipts backend, security/licensing, edi architecture).
Aussage: Das System soll als integrierte ERP-Suite für IT-Systemhäuser und Handelsbetriebe die Prozesse Vertrieb, Beschaffung, Lager, Produktion, Service (Tickets/Zeiterfassung), Finanzwesen, CRM und IT-Asset-Management in einer gemeinsamen Datenhaltung abbilden.
Ergebnis: Ein Betriebsdatenträger deckt den kompletten Auftrags- und Servicezyklus ab, ohne Systemwechsel.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs (Klasse ReceiptBL, ~11.400 Zeilen, Beleg-Engine für alle Belegarten) - Begründung: zentrale, alle Belegarten abdeckende Fachlogik beweist integrierte Vertriebsverarbeitung.
- [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\ModuleRegistration.cs (29 Modulordner u. a. Sales, Helpdesk, Warehousing, Production, Finances, OnlineBanking, PasswordManager) - Begründung: Modulumfang der Oberfläche spiegelt die Fachdomänen.
- [KONTEXT] docs\reference\ (u. a. receipts backend, security/licensing, edi architecture) - Begründung: Projektdokumentation bestätigt die Domänenaufteilung.
Prüfidee: Für jede Fachdomäne existiert mindestens eine ablauffähige Prozedur von der Erfassung bis zur Abrechnung in derselben Datenbank (Nachweis über Modulliste und DB-Schema).
Tracelinks: SyRS-1, SyRS-6
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernzweck des Systems, für Neuimplementierung maßgeblich.
Status: belegt
---
ID: StRS-2
Titel: Installationsbasierte Mandanten- und Wartungsstruktur
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Betreiber/Hosting-Partner, c-entron Software GmbH (Hersteller)
Vorbedingung: Pro Kundenbetrieb existiert eine eigene Installation mit eigener Datenbank
Fakt: Die Datenzugriffsschicht arbeitet mit genau einer Verbindungszeichenfolge je Installation (src\backend\Centron.DAO\DAOFactory.cs, Methode SetConnection/InitializeAsyncInternal); Lizenzserver-Abgleich übermittelt installationsbezogene Daten (src\backend\Centron.BL\Administration\SQLManagement\DatabaseInfosForLicenseServer.cs).
Aussage: Das System soll pro Kundenbetrieb als eigenständige Installation (eigene Datenbank, eigener Web-Service) betrieben werden; Mandanttrennung ergibt sich aus der Installation, nicht aus mandantenfähigen Tabellen.
Ergebnis: Daten verschiedener Kundenbetriebe sind physisch getrennt; Wartung/Lizenzierung erfolgt je Installation.
Belege:
- [PRIMÄR] src\backend\Centron.DAO\DAOFactory.cs - DAOFactory.SetConnection: NHibernate-Konfiguration mit genau einer ConnectionString-Property - Begründung: technisch durchgesetzt: nur eine Datenbank je Prozess.
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql (Datenbank CentronVOED2, Kompatibilitätslevel 160) - Begründung: ausgeliefertes Leerschema je Installation.
- [KONTEXT] src\backend\Centron.BL\Administration\Licensing\LicenseManager.cs (SettingsForWebService: Lizenzcache "c-entron Web-Service", Übergabe von DB-Infos an Lizenzserver) - Begründung: Lizenzmodell ist installationsbezogen.
Prüfidee: Zwei Installationen mit getrennten Verbindungszeichenfolgen führen zu vollständig getrennten Datenbeständen ohne Überschneidung.
Tracelinks: SyRS-12, SyRS-32, SyRS-24
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - bewährtes Hosting-Modell; im Zielsystem (SaaS) neu zu bewerten (Mandantenkonzept).
Status: belegt
---
ID: StRS-3
Titel: Service- und Helpdeskprozesse mit Zeiterfassung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Servicemitarbeiter, Dispatcher, Kunde (über Portal)
Vorbedingung: Anwender ist mit Helpdesk-Rechten angemeldet
Fakt: Fachdomänen Helpdesk/Tickets, Zeiterfassung (HelpdeskTimer), Serviceberichte und Eskalations-/Erinnerungsdienste existieren nebeneinander (src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskTimerWebServiceBL.cs; src\webservice\Centron.Host\AspNetCore\HostedServices\ mit ReminderService/EscalationsService); Rechtekatalog in CentronRights.md.
Aussage: Das System soll Serviceanfragen als Tickets erfassen, zuweisen, priorisieren, mit Zeiterfassung und Serviceberichten abwickeln und über Fälligkeiten/Eskalationen automatisch nachhalten.
Ergebnis: Vom Kundenanliegen bis zur abrechnungsfähigen Zeitbuchung ist der Serviceprozess lückenlos nachvollzogen.
Belege:
- [PRIMÄR] src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskTimerWebServiceBL.cs - ThrowIfInvalidHelpdeskTimer/CheckTimerCanBeMoved (Zeiten-Schutzregeln) - Begründung: Kernregeln des Serviceprozesses sind im Code durchgesetzt.
- [SEKUNDÄR] CentronRights.md (Rechtekatalog Helpdesk: anzeigen/anlegen/bearbeiten/Zeiten/abschließen) - Begründung: beschreibt die fachlichen Rollenrechte des Prozesses.
- [KONTEXT] src\webservice\Centron.Host\AspNetCore\HostedServices\ (ReminderService, EscalationsService) - Begründung: automatische Nachhaltung gehört zum Prozess.
Prüfidee: Ein Ticket durchläuft Anlage→Zuweisung→Zeitbuchung→Servicebericht→Abrechnung; Fälligkeitsüberschreitung erzeugt eine Eskalationsbenachrichtigung.
Tracelinks: SyRS-10, SyRS-14
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernleistung des Anwenderbetriebs.
Status: belegt
---
ID: StRS-4
Titel: Vertriebsbelegkette von Angebot bis Gutschrift
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Innendienst, Kunde
Vorbedingung: Kundenstamm und Artikelstamm gepflegt
Fakt: Belegarten Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abruf/Contract, Barbeleg sind als eigene BL-Klassen mit je eigenem Nummernkreis modelliert (src\backend\Centron.BL\Administration\Company\NumberGroupEnum.cs: Offer=1, Order=2, DeliveryList=3, Invoice=4, CreditVoucher=6, CashOffer=20, CashInvoice=21 u. a.; typed Sub-BLs in src\backend\Centron.BL\Sales\Receipts\).
Aussage: Das System soll den gesamten Vertriebsprozess über eine Belegkette (Angebot → Auftrag → Lieferschein → Rechnung → Gutschrift) mit durchgängiger Positionsübernahme und eigenen Nummernkreisen je Belegart abbilden.
Ergebnis: Jede Vertriebstätigkeit ist über eine lückenlos nummerierte Belegkette abrechnbar und prüfbar.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs - UpdateReceiptNumber (Zeile 7265) über NumberGroupBL - Begründung: Nummernvergabe je Belegart ist code-seitig durchgesetzt.
- [PRIMÄR] src\backend\Centron.BL\Administration\Company\NumberGroupEnum.cs (Belegart→Nummernkreis-Zuordnung inkl. Zieltabelle RechKopf/AngKopf/AufKopf/GutKopf) - Begründung: Belegarten und Zieltabellen sind fest verdrahtet.
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql (Tabellen AngKopf, AufKopf, RechKopf, GutKopf, RechPos) - Begründung: Datenhaltung der Belegkette.
Prüfidee: Aus einem Angebot wird per Weiterverarbeitung ein Auftrag mit übernommenen Positionen erzeugt; jede Stufe erhält eine fortlaufende, artenspezifische Nummer.
Tracelinks: SyRS-6, SwRS-11, SwRS-16
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess; Belegarten-Vielfalt im Zielsystem konsolidiert modellieren.
Status: belegt
---
ID: StRS-5
Titel: Beschaffung und Lieferantenabrechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Einkauf, Wareneingang, Kreditorenbuchhaltung
Vorbedingung: Lieferantenstamm und Distributor-Zugänge vorhanden
Fakt: Einkauf ist als Domäne mit Lieferantenstamm, filialbezogenen Bestellungen und Bestellvorschlagslisten implementiert (src\backend\Centron.BL\Purchasing\: SupplierBL.cs, SupplierOrderPerBranchBL.cs, OrderSuggestionListBL.cs); Lieferantenbelege (Bestellung/Wareneingang/Lieferantenrechnung) liegen in der Beleg-Engine (src\backend\Centron.BL\Sales\Receipts\SupplierReceiptDocuments\, Nummernkreise PurchaseOrder=17, Intake=18, VendorInvoice=19 in NumberGroupEnum.cs).
Aussage: Das System soll Beschaffung von Bestellvorschlag über Lieferantenbestellung und Wareneingang bis zur Lieferantenrechnung abbilden, je Filiale getrennt.
Ergebnis: Eingehende Lieferantenrechnungen sind gegen Bestellungen und Wareneingänge prüfbar und buchbar.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs (Beleg-Engine verarbeitet auch Lieferantenbelege; ReceiptAddressKind, ForwardReceipt-Flüsse) - Begründung: Lieferantenbelege nutzen dieselbe durchgesetzte Beleglogik.
- [SEKUNDÄR] src\backend\Centron.BL\Purchasing\OrderSuggestionListBL.cs / SupplierOrderPerBranchBL.cs - Begründung: Klassenstruktur belegt filialbezogene Bestelllogik und Vorschlagswesen.
- [KONTEXT] src\backend\Centron.BL\Administration\Company\NumberGroupEnum.cs (PurchaseOrder, Intake, VendorInvoice, SupplierCreditVoucher) - Begründung: eigene Nummernkreise belegen die Belegarten des Einkaufs.
Prüfidee: Aus einer Bedarfsliste entsteht eine filialbezogene Bestellung; Wareneingang und Lieferantenrechnung werden gegen sie referenziert.
Tracelinks: SyRS-6, SyRS-19
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess.
Status: belegt
---
ID: StRS-6
Titel: Finanzprozesse: Zahlungen, Mahnwesen, Online-Banking, Buchhaltungsübergabe
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Finanzbuchhaltung, Bank (extern)
Vorbedingung: Rechnungen mit offenen Posten vorhanden; Bankanbindung konfiguriert
Fakt: Domänen für Zahlungseingänge, Online-Banking-Buchung, Mahnwesen und Buchhaltungsexport existieren (src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingAccountTransactionsBL.cs - BookAmountsForAccountTransacitons; src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs; src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs).
Aussage: Das System soll Zahlungseingänge (manuell und aus Online-Banking) Rechnungen zuordnen, überfällige Forderungen mehrstufig mahnen und Belege in gängige Buchhaltungsformate exportieren.
Ergebnis: Offene Posten sind stets aktuell; Debitorenbuchhaltung arbeitet mit automatisiertem Zahlungsabgleich und Mahn- sowie Exportläufen.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingAccountTransactionsBL.cs - BookAmountsForAccountTransacitons (Zeile 883), CloseCreditVoucher setzt State=Completed (Zeile 932) - Begründung: Zahlungsverbuchung schließt Belege automatisch, code-seitig durchgesetzt.
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs - ExecuteDunningRun (Stufen None→Level1→Level2→Level3, Zeilen 253-268) - Begründung: Mahnstufen sind implementierte Zustandsmaschine.
- [SEKUNDÄR] src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs (Fabrik über BookKeepingExportTypes: DATEV, Sage, Abacus u. a.) - Begründung: Formatliste belegt Buchhaltungsübergabe.
Prüfidee: Ein eingegangener Bankbetrag wird automatisch einer Rechnung zugeordnet; bei Überschreitung der Frist läuft eine Mahnung Stufe 1, danach 2, danach 3.
Tracelinks: SyRS-17, SyRS-18, SyRS-21
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess der Debitorenbearbeitung.
Status: belegt
---
ID: StRS-7
Titel: Rollenbasierte Zugriffskontrolle auf Organisationsebene
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Administrator, Vorgesetzte, Datenschutzbeauftragte
Vorbedingung: Benutzer und Gruppen eingerichtet
Fakt: Klassisches RBAC: Benutzer (Sichbenu) → Gruppenmitgliedschaft (Sichmemb) → Rechte (Sichtrus); Rechteprüfung zentral in src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs (HasUserRight, SQL-Join über Sichtrus/Sichmemb), Verwaltung von Benutzern selbst rechtegeschützt (src\backend\Centron.BL\EmployeeArea\AppUserBL.cs, Zeile 138: RIGHT_PERSONALMANAGEMENT).
Aussage: Das System soll Zugriffe über rollenbasierte Rechte steuern: Rechte werden Gruppen zugewiesen, Benutzer sind Gruppenmitglieder; einschränkende Rechte (z. B. "nur eigene", "nur eigene Filiale") verfeinern die Sichtbarkeit datenschutzgerecht.
Ergebnis: Jeder Nutzer sieht und verarbeitet genau die Daten, die seine Rolle erlaubt.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs - HasUserRight (Zeile 644, SQL "SELECT st.Recht ... INNER JOIN Sichmemb ... WHERE sm.Benutzer = :UserI3D") - benennt die durchsetzende Stelle für Berechtigungen.
- [PRIMÄR] src\backend\Centron.BL\EmployeeArea\AppUserBL.cs - SaveOrUpdateAppUser (Zeile 138: ablehnende Rechteprüfung) - Begründung: Beispiel einer durchgesetzten Rechteprüfung vor einer Operation.
- [KONTEXT] CentronRights.md (dokumentierter Rechtekatalog mit einschränkenden Rechten) - Begründung: fachliche Intention der Rechteverfeinerung.
Prüfidee: Ein Benutzer ohne Helpdesk-Recht sieht keine Tickets; mit "nur eigene" sieht er ausschließlich eigene Vorgänge.
Tracelinks: SyRS-4, SyRS-5, SyRS-7, SwRS-7, SwRS-9
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - RBAC-Modell und einschränkende Rechte für Zielsystem festzuschreiben.
Status: belegt
---
ID: StRS-8
Titel: Modulares Lizenzmodell mit Sitzplatzkontrolle
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: c-entron Software GmbH (Lizenzgeber), Betreiber
Vorbedingung: Lizenz über Lizenzserver bezogen; Web-Service verbunden
Fakt: Lizenzverwaltung über GUID-Produktlizenzen (src\backend\Centron.Interfaces\Administration\Logins\LicenseGuids.cs, 416 Zeilen); Sitzplatzprüfung an der Anmeldung (src\backend\Centron.BL\Administration\Licensing\LicenseManager.cs, Zeilen 280-282: "Die maximale Anzahl an Lizenzen wurde erreicht."); Lizenzquote vor DB-Strukturaktualisierung geprüft (CentronHost.cs, Start).
Aussage: Das System soll Funktionsumfang und Nutzungskapazität über ein Lizenzmodell steuern: Module sind lizenzgebunden, gleichzeitige Sitzungen sind auf erworbene Sitzplätze begrenzt.
Ergebnis: Ohne Lizenz bleibt ein Modul unbenutzbar; überzählige Anmeldungen werden abgewiesen.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Administration\Licensing\LicenseManager.cs - CheckLicense (Zeilen 280-282, Vergleich GetTicketCount gegen GetLicenseCount) - Begründung: Sitzplatzgrenze wird an der Anmeldung durchgesetzt.
- [PRIMÄR] src\backend\Centron.BL\Production\ProductionOrderBL.cs (jede Methode: HasLicense(ProductionManagement), sonst Exception) - Begründung: Modullizenz wird bei jedem Zugriff durchgesetzt.
- [KONTEXT] src\backend\Centron.Interfaces\Administration\Logins\LicenseGuids.cs - Begründung: Lizenzkatalog als Vertragsobjekt.
Prüfidee: Bei erschöpften Sitzplätzen schlägt die Anmeldung mit klarer Meldung fehl; ein ungelizenzierter Modulzugriff wirft eine Fehlermeldung.
Tracelinks: SyRS-2, SyRS-9, SyRS-25, SyRS-36
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Geschäftsmodell des Herstellers; SaaS-Ausprägung neu gestalten.
Status: belegt
---
ID: StRS-9
Titel: Kundenportal/Selbstservice mit Shop und Vorgangseinsicht
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Kunde des Anwenderbetriebs (Web-Account), Prüfer/Besteller im Kundenbetrieb
Vorbedingung: Web-Account im Adressstamm angelegt; Kunde aktiv
Fakt: Blazor-Portal "Nexus" mit WebCart (Shop), Kunden-Tickets, Belegeinsicht und Formularen; Shop greift auf Sonderpreise des Kunden zu (src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs - SearchArticles filtert auf Sonderpreise); vier-Augen-Freigabe über Web-Account-Rechte (src\nexus\CentronNexus\WebCart\Components\WebCartClearance.razor).
Aussage: Das System soll Kunden über ein Web-Portal Selbstservice bieten: Artikelbestellung auf Basis kundenindividueller Sonderpreise mit optionaler vier-Augen-Freigabe, Einsicht in eigene Vorgänge und Formulare.
Ergebnis: Kunden bestellen ohne Medienbruch zu kundenindividuellen Konditionen; interne Freigaberegeln des Kundenbetriebs werden abgebildet.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs - SearchArticles (Guard "Only web-account can search webcart articles"; Filter auf Sonderpreis-Artikel) - Begründung: Shop-Grundregel (nur Sonderpreisartikel, nur Web-Accounts) durchgesetzt.
- [PRIMÄR] src\nexus\CentronNexus\WebCart\Components\WebCartClearance.razor (Zustände ReadyForCheck/Checked mit WEBRIGHT_WEBCART2_CHECK_CART/ORDER_CART) - Begründung: vier-Augen-Freigabe ist code-seitig verdrahtet.
- [SEKUNDÄR] README.md (Beitragende-Hinweis: WebCart für Kunden der Kunden; Artikel aus Sonderpreisen) - Begründung: beschreibt fachliche Zielgruppe.
Prüfidee: Ein Web-Account sieht ausschließlich Artikel mit aktiver Sonderpreis-Vereinbarung; Bestellung ohne Besteller-Freigabe bleibt im Zustand "geprüft".
Tracelinks: SyRS-14, SwRS-29, SwRS-30
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - strategisches Portalfeature.
Status: belegt
---
ID: StRS-10
Titel: Elektronischer Angebotsversand mit Kundenannahme und Signatur
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Kunde (extern, ohne Login), Vertrieb
Vorbedingung: Angebot als WebReceipt freigegeben; Nexus-URL und Signaturdokument konfiguriert
Fakt: Token-basierte anonyme Angebotsseiten (/weboffer/{Token}) mit customer-seitiger Mengenänderung, Annahme und Signatur; feingranulare Steuerung über vom Mitarbeiter gesetzte Freigaben (src\nexus\CentronNexus\WebOffer\WebReceiptOverview.razor, AllowAcceptReceipt/AllowChangeQuantity); Backend erzeugt daraus Aufträge (src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs - ChangeWebReceiptState/AcceptWebReceipt).
Aussage: Das System soll Angebote elektronisch an Kunden versenden, damit diese online Mengen prüfen/ändern, das Angebot annehmen oder ablehnen und - wo gefordert - digital unterschreiben; die Annahme erzeugt automatisch einen Auftrag.
Ergebnis: Angebotsbestätigungen kommen ohne Postweg/PDF-Rücklauf zustande und fließen direkt in die Auftragsbearbeitung.
Belege:
- [PRIMÄR] src\nexus\CentronNexus\WebOffer\WebReceiptOverview.razor (Zeilen 593-600: _canExecuteAction/_canChangeQuantity nur bei Allow*-Flags und aktiver WebReceipt) - Begründung: Kundenhandlungen sind serverseitig vorgegebenen Freigaben unterworfen.
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs - ChangeWebReceiptState (Prüfung Nexus-URL und Signaturdokument-Part; Verzweigung AcceptFullWebReceipt→AcceptWebReceipt) - Begründung: Auftragsentstehung und Voraussetzungen sind code-seitig durchgesetzt.
- [KONTEXT] src\backend\Centron.Interfaces\Sales\Receipts\WebReceipt\WebReceiptState.cs (Zustandsenum) - Begründung: Zustandsmodell des elektronischen Angebots.
Prüfidee: Kunde nimmt Angebot ohne Änderung an → Auftrag entsteht und Bestätigungsmail geht raus; mit Mengenänderung entsteht eine Änderungsanfrage statt Auftragserteilung.
Tracelinks: SyRS-14, SwRS-31
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - digitales Vertriebsfeature.
Status: belegt
---
ID: StRS-11
Titel: Produktionssteuerung am Shopfloor
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Produktionsmitarbeiter, Fertigungsleitung
Vorbedingung: Lizenz Produktionsmanagement; Arbeitsplätze/Maschinen eingerichtet
Fakt: Produktion ist vollständig lizenzgebunden (src\backend\Centron.BL\Production\ProductionOrderBL.cs - jede Methode prüft HasLicense); Shopfloor-Terminal zur Arbeitschritt-Übernahme mit Belegungsschutz (src\nexus\CentronNexus\ProductionOrderManagement\Components\WorkStepTemplateComponent.razor - Meldung "Arbeitsschritt bereits belegt").
Aussage: Das System soll Fertigungsaufträge in Arbeitsschritte zerlegen, die am Shopfloor-Terminal je Arbeitsplatz/Maschine übernommen und fertiggestellt werden; eine parallele Übernahme durch zwei Mitarbeiter ist auszuschließen.
Ergebnis: Der Fertigungsfortschritt ist in Echtzeit je Maschine sichtbar; Doppelbearbeitung wird verhindert.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Production\ProductionOrderBL.cs (Lizenzgate in jedem Zugriff) - Begründung: Zugriffsschutz ist durchgesetzt.
- [PRIMÄR] src\nexus\CentronNexus\ProductionOrderManagement\Components\WorkStepTemplateComponent.razor - TakeWorkstep mit Server-Abgleich und Belegungshinweis - Begründung: Exklusivvergabe von Arbeitsschritten im Code.
- [SEKUNDÄR] src\nexus\CentronNexus\ProductionOrderManagement\Components\WorkStepTemplateComponent.razor (Zustandsfarben Finished/InProgression/OpenNotStarted) - Begründung: Zustandsdarstellung für das Terminal.
Prüfidee: Zwei Terminals versuchen gleichzeitig denselben Arbeitsschritt zu übernehmen: der zweite erhält "Arbeitsschritt bereits belegt".
Tracelinks: SyRS-9, SwRS-33
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - kundenspezifische Fertigungssteuerung.
Status: belegt
---
ID: StRS-12
Titel: Distributor- und Marktdatenintegration
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Einkauf/Vertrieb, externe Distributoren und Marktdatenanbieter
Vorbedingung: Zugangsdaten zu Distributor-/Marktdatendiensten hinterlegt
Fakt: Gateway mit Distributor-EDI-Formaten (Alltron, ALSO/ALSO CH, EGIS, Herweck, Komsa, Concerto, OpenTrans/BMEcat), Import-/Export-Fabrik und Avnet-Parser (src\backend\Centron.Gateway\EDI_*, OpenTrans, Import\EDI, Export\EDI); Marktdaten-Clients für COP, EGIS, Icecat, ITscope (src\apis\Centron.APIs.*); Produktkatalogimporte inkl. Wortmann (src\backend\Centron.BL\Warehousing\ArticleManagement\ArticleImportBL.cs).
Aussage: Das System soll Bestellungen, Preis- und Verfügbarkeitsanfragen sowie Katalog- und Artikeldaten mit Distributoren und Marktdatenplattformen austauschen, um Bestell- und Katalogpflege zu automatisieren.
Ergebnis: Bestellungen gehen elektronisch an Distributoren; Artikelstamm wird aus Katalogen/Marktdaten gespeist.
Belege:
- [PRIMÄR] src\backend\Centron.Gateway\Import\EDI\IEDIGatewayImport.cs (ImportOrder-Vertrag; Umsetzung Avnet.cs) - Begründung: EDI-Import ist als Schnittstellenvertrag implementiert.
- [PRIMÄR] src\backend\Centron.Gateway\Export\EDI\BBGWebserviceConnect.cs - Upload (Zugangsdaten-Prüfungen, Doctype INVOIC) - Begründung: ausgehender EDI-Versand ist code-seitig implementiert.
- [SEKUNDÄR] src\apis\Centron.APIs.ITscopeDataAccess\ITscopeApi.cs (REST-API 2.1, products/deals) - Begründung: Marktdatenabgleich ist real.
Prüfidee: Ein Bestellvorschlag wird als EDI-Order an einen Distributor übertragen; eine Katalogdatei (Wortmann) importiert Artikel in den Stamm.
Tracelinks: SyRS-19, SyRS-20
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Automatisierungsgrad ist Wettbewerbsvorteil; einzelne Altformate prüfen (veraltet).
Status: belegt
---
ID: StRS-13
Titel: E-Rechnungs-Compliance (ZUGFeRD/XRechnung/ebInterface)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb/Buchhaltung, öffentliche Auftraggeber, Steuerbehörden
Vorbedingung: Rechnung abgeschlossen; E-Rechnungseinstellungen aktiviert
Fakt: E-Rechnungsgenerierung für ZUGFeRD 1.0 und XRechnung 1.2-3.0.1 inkl. Einbettung ins Rechnungs-PDF (src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs; Leitweg-ID entscheidet XRechnung vs. Comfort, Zeilen 153, 193), ebInterface 4p3 für Österreich (src\apis\Centron.Api.EbInterface\EbInterfaceLogic.cs), ZUGFeRD-Import von Lieferantenrechnungen (src\webservice\Centron.Controllers\Controllers\v1\Receipts\ZugferdImportController.cs).
Aussage: Das System soll Rechnungen als konforme E-Rechnungen (ZUGFeRD/XRechnung inkl. PDF-Einbettung, für Österreich ebInterface) erzeugen und eingehende E-Rechnungen automatisch auslesbar machen.
Ergebnis: Rechnungen erfüllen die regulatorischen Vorgaben je Empfängerland/Empfängertyp.
Belege:
- [PRIMÄR] src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs - GetZugferFormat/GenerateZugferdFile (Versionen, Leitweg-ID, Typcodes 380/381 in Zeile 1309) - Begründung: Normkonforme Generierung ist code-seitig umgesetzt.
- [PRIMÄR] src\apis\Centron.Api.EbInterface\EbInterfaceLogic.cs - GenerateXmlDocument (Namespace 4p3, GeneratingSystem "C-ENTRON") - Begründung: österreichisches Format ist real implementiert.
- [KONTEXT] docs\reference\zugferd* (Field-Mapping-Doku) - Begründung: Projektdokumentation zum Mapping.
Prüfidee: Eine XRechnung 3.0.1 mit Leitweg-ID wird als PDF mit eingebettetem factur-x.xml erzeugt und von einem Prüftool akzeptiert.
Tracelinks: SyRS-15, SyRS-16, SwRS-42, SwRS-50
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - regulatorisch zwingend.
Status: belegt
---
ID: StRS-14
Titel: Nachvollziehbarkeit von Änderungen (Audit)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Revision, Datenschutzbeauftragte, Serviceleitung
Vorbedingung: Änderungsverfolgung für die betroffenen Objektarten aktiviert
Fakt: Feld-Level-Änderungsprotokoll über NHibernate-PreUpdate-Listener in Tabelle ChangeLog mit Alt-/Neuwert und Benutzer (src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs, CreateChangeLog; Opt-in per [TrackChanges]-Attribute in src\backend\Centron.Interfaces\ChangeTracking\).
Aussage: Das System soll fachliche Änderungen an sensiblen Objekten mit Benutzer, Feld, Alt- und Neuwert protokollieren, um Revision und Nachvollziehbarkeit zu ermöglichen.
Ergebnis: Für protokollierte Objektarten ist rekonstruierbar, wer welches Feld wann wie geändert hat.
Belege:
- [PRIMÄR] src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs - OnPreUpdate/CreateChangeLog (Beschreibungsmuster "{0} wurde von {1} auf {2} geändert.") - Begründung: Protokollschrreibung ist technisch durchgesetzt.
- [PRIMÄR] src\backend\Centron.DAO\Mappings\ChangeTracking\ChangeLogMaps.cs (Table "ChangeLog") - Begründung: persistente Protokollhaltung.
- [KONTEXT] src\backend\Centron.Interfaces\ChangeTracking\ ([ChangeTrackingConfiguration]/[TrackChanges]) - Begründung: Opt-in-Mechanismus dokumentiert.
Prüfidee: Ändert ein Nutzer ein protokolliertes Feld, erscheint in ChangeLog genau ein Eintrag mit Alt-/Neuwert und Benutzer.
Tracelinks: SyRS-23, SwRS-39
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Auditfähigkeit ist Zielvorgabe; Umfang (Insert/Delete) im Zielsystem erweitern.
Status: belegt
---
ID: StRS-15
Titel: Zusammenarbeit: Chat, Benachrichtigungen, Telefonie, Mail
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mitarbeiter (innen/außen), Anrufer
Vorbedingung: Web-Service läuft; Mail-/TAPI-Infrastruktur angebunden
Fakt: Echtzeit-Kommunikation über SignalR-Hubs (Notifications, Chat, Verfügbarkeitsstatus, TAPI; src\webservice\Centron.Host\AspNetCore\SignalR\CentronSignalR.cs), Telefonjournal (src\backend\Centron.BL\Tapi\PhoneCallBL.cs), Mailinfrastruktur mit SMTP/EWS/Graph (src\backend\Centron.BL\Mail\MailSettingsBL.cs).
Aussage: Das System soll Teamkommunikation (Chat), Ereignisbenachrichtigungen, Anwesenheit und Telefonie (Anrufjournal, Bildschirm-Popups) sowie E-Mail-Kommunikation integriert anbieten.
Ergebnis: Mitarbeiter bearbeiten Kundenkontakte ohne Medienbruch zwischen Telefon, Mail, Chat und Fachanwendung.
Belege:
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\SignalR\CentronSignalR.cs - MapHub<NotificationsHub>("/Realtime/notifications") u. a. (4 Hubs) - Begründung: Echtzeitanbindung ist serverseitig verdrahtet.
- [SEKUNDÄR] src\backend\Centron.BL\Mail\MailSettingsBL.cs (SMTP/Exchange/Graph-Einstellungen, verschlüsselt) - Begründung: Mail-Protokollvielfalt belegt Kanalintegration.
- [KONTEXT] src\backend\Centron.BL\Tapi\PhoneCallBL.cs (Sanitierung der Endzeiten) - Begründung: Anrufjournal ist real im Betrieb.
Prüfidee: Ein eingehender Anruf öffnet das Kundendossier; eine Chatnachricht erscheint ohne Seitenreload beim Empfänger.
Tracelinks: SyRS-8, SyRS-29, SyRS-33
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: StRS-16
Titel: Dokumenten- und Wissensmanagement
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mitarbeiter, Serviceleitung
Vorbedingung: Reportvorlagen/Textbausteine/Videozuweisungen vorhanden
Fakt: Berichtswesen mit Reportverwaltung und PDF-Ausgabestrategien (src\backend\Centron.BL\ReportEngine\PdfStategy\PdfStrategies.cs - Default/PdfCreator/SevenPdf mit FastReport-Fallback), Textbausteine je Belegart (src\backend\Centron.BL\TextModuleArea\TextModuleBL.cs), Videoportal mit Rechteprüfung und Wiedervorlagen (src\backend\Centron.BL\VideoPortal\VideoPortalAssignmentBL.cs).
Aussage: Das System soll Belege und Auswertungen über konfigurierbare Reportvorlagen erzeugen, wiederkehrende Texte als Textbausteine führen und Schulungsvideos gezielt zuweisen können.
Ergebnis: Dokumenterzeugung ist ohne Programmierung anpassbar; Wissen wird systematisch verteilt.
Belege:
- [PRIMÄR] src\backend\Centron.BL\ReportEngine\PdfStategy\PdfStrategies.cs (Strategiewahl mit 30-Minuten-Fallback) - Begründung: Ausgabestrategie ist code-seitig geregelt.
- [SEKUNDÄR] src\backend\Centron.BL\TextModuleArea\TextModuleBL.cs (neuester Baustein je Typ gewinnt) - Begründung: Versionierungsregel der Textbausteine.
- [PRIMÄR] src\backend\Centron.BL\VideoPortal\VideoPortalAssignmentBL.cs (Recht "Video-Portal Zuweisung", danach automatische Wiedervorlagen) - Begründung: Zuweisungsprozess ist implementiert.
Prüfidee: Eine Rechnung wird mit einer ausgetauschten Reportvorlage gedruckt; eine Videzuweisung erzeugt beim Mitarbeiter automatisch eine Wiedervorlage.
Tracelinks: SyRS-30
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: StRS-17
Titel: Controlling und Auswertungen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsführung, Controlling
Vorbedingung: Statistik-Cache/Datenbasis vorhanden; Controlling-Rechte gesetzt
Fakt: Umsatz-, Auftrags- und Ticketstatistiken mit rechtegeschütztem Zugriff (src\backend\Centron.BL\Statistics\TicketStatistics\CacheTicketStatisticsBL.cs, Zeile 28: MANAGEMENT_INFO-Recht), ProductMatrix-Auswertungen über NamedQueries (src\backend\Centron.BL\ProductMatrix\), Mitarbeiteilerauslastung (CentronRights.md: RIGHT_MITARBEITERAUSLASTUNG).
Aussage: Das System soll Entscheidungsgrundlagen (Umsatz, Auslastung, Ticketstatistik, Produktslices) bereitstellen; sensible Auswertungen sind an Controlling-Rechte gebunden.
Ergebnis: Führungskräfte erhalten konsolidierte Kennzahlen ohne direkte Datenbankabfragen.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Statistics\TicketStatistics\CacheTicketStatisticsBL.cs - GetAll (Rechtsprüfung vor Datenausgabe) - Begründung: Zugriffsschutz auf Auswertungen ist durchgesetzt.
- [SEKUNDÄR] src\backend\Centron.BL\ProductMatrix\ (Auswertungen über NamedQueryPool) - Begründung: Auswertungsmechanismus real.
- [KONTEXT] CentronRights.md (Auslastungsrechte, nur eigene Filiale) - Begründung: Auswertungssichtbarkeit fachlich definiert.
Prüfidee: Benutzer ohne Management-Info-Recht erhält bei Ticketstatistik eine Rechte-Fehlermeldung.
Tracelinks: SyRS-7, SwRS-51
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: StRS-18
Titel: Mobile Nutzung und Outlook-Einbindung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Außendienst-/Service-Mitarbeiter
Vorbedingung: Outlook mit Add-in bzw. mobile Datenquelle verfügbar
Fakt: Outlook-Add-in (Office.js/Blazor Taskpane) für Kundensuche per Absenderadresse, Dokumente, Ticketanlage und Belegsuche (src\nexus\CentronNexus.OutlookAddIn\OutlookIndexPage.razor; Ticketanlage mit .eml-Ablage ≤ 25 MB in src\nexus\CentronNexus.OutlookAddIn\Shared\CreateNewTicket.razor); Mobiler Datenbereich (src\backend\Centron.BL\Mobile\MobileBL.cs).
Aussage: Das System soll Arbeitswege in Outlook und auf mobilen Endgeräten unterstützen: Kundendaten, Vorgänge und Belege aus Mail-Kontext heraus aufrufen und aus E-Mails direkt Tickets erzeugen.
Ergebnis: Kontaktaufnahmen werden ohne Wechsel in die Fachoberfläche dokumentiert.
Belege:
- [PRIMÄR] src\nexus\CentronNexus.OutlookAddIn\Shared\CreateNewTicket.razor (Ticketanlage + exportEmailAsEml, maxAllowedSize 25 MB) - Begründung: Kernaufgabe "Ticket aus E-Mail" ist implementiert.
- [SEKUNDÄR] src\nexus\CentronNexus.OutlookAddIn\Manifest\Manifest.xml (MessageRead/ComposeCommandSurface) - Begründung: Einbindungspunkte in Outlook.
- [SEKUNDÄR] src\backend\Centron.BL\Mobile\MobileBL.cs (GetMobileEmployee, GetContactPersonImage) - Begründung: Mobiler Datenzugriff existiert.
Prüfidee: Aus einer geöffneten E-Mail entsteht per Dialog ein Helpdesk-Ticket inkl. .eml-Anhang im Ticketordner.
Tracelinks: SyRS-31, SyRS-38
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: StRS-19
Titel: KI-gestützte Assistenz
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mitarbeiter, KI-Anbieter (extern)
Vorbedingung: KI-Modell/Anbieter konfiguriert; ggf. Lizenz gesetzt
Fakt: KI-Clients für mehrere Anbieter (OpenAI/GPT, Mistral, Google Gemini, Claude) inkl. Kontextfensterauflösung (src\backend\Centron.BL\ArtificialIntelligence\ mit IAiModelClient-Implementierungen); Ticketzusammenfassungen im Outlook-Add-in (CentronService.CreateTicketSummary).
Aussage: Das System soll KI-Modelle als Assistenten einbinden (Chat, Textbewertung, Ticketkategorisierung/Zusammenfassung), um Routinearbeit zu unterstützen.
Ergebnis: Nutzer erhalten KI-Unterstützung direkt in Fachprozessen.
Belege:
- [PRIMÄR] src\backend\Centron.BL\ArtificialIntelligence\ (IAiModelClient: OpenAiChatModelClient, MistralAiChatModelClient, GoogleGeminiChatModelClient, ClaudeCodeChatModelClient; AiModelContextWindowResolver) - Begründung: Mehranbieter-KI-Anbindung ist implementiert.
- [SEKUNDÄR] src\nexus\CentronNexus.OutlookAddIn\TicketDetailsDialog.razor (CreateTicketSummary) - Begründung: KI-Ausgabe in Fachdialog integriert.
- [KONTEXT] src\webservice\Centron.Host\AspNetCore\WcfBridge\Interception\Interceptors\McpToolUsageTelemetryInterceptor.cs - Begründung: auch KI-Toolnutzung wird getelemetriert.
Prüfidee: Ein Ticket-Dialog liefert eine KI-Zusammenfassung; Konfigurationswechsel des Anbieters ändert das dahinterliegende Modell.
Tracelinks: SyRS-34
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - strategisches Thema; Datenschutzkonkretisierung im Zielsystem nötig.
Status: belegt
---
ID: StRS-20
Titel: Personal- und Zeitverwaltung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Personalabteilung, Führungskräfte, Mitarbeiter
Vorbedingung: Mitarbeiterstamm gepflegt
Fakt: Mitarbeiter-/Benutzerverwaltung mit Rechteprüfung (src\backend\Centron.BL\EmployeeArea\AppUserBL.cs, Zeile 138), Kalender-/Terminplanung mit Zuweisungsrecht (src\backend\Centron.BL\Sales\Calendar\ScheduleBL.cs, Zeilen 98-114), Auslastungssichtbarkeiten (CentronRights.md), Urlaubshistorie (src\backend\Centron.DAO\Holiday\HolidayDAO.cs); MyDay-Arbeitsplatz (src\backend\Centron.BL\MyDay\MyDayBL.cs).
Aussage: Das System soll Stammdaten von Mitarbeitern und Benutzern, Termin-/Urlaubsplanung, Auslastungssicht und persönlichen Arbeitsplatz (MyDay) verwalten; Änderungen an Personalstammdaten sind rechtegeschützt.
Ergebnis: Personalprozesse laufen mit Rollenschutz und tagesaktueller Auslastung ab.
Belege:
- [PRIMÄR] src\backend\Centron.BL\EmployeeArea\AppUserBL.cs - SaveOrUpdateAppUser (RIGHT_PERSONALMANAGEMENT-Prüfung) - Begründung: Personalverwaltung ist rechtegeschützt durchgesetzt.
- [PRIMÄR] src\backend\Centron.BL\Sales\Calendar\ScheduleBL.cs - DoBeforeSave (Enddatum-Prüfung; RIGHT_TERMINPLANUNGTERMINANDEREMMAZUWEISEN bei Zuweisung an andere) - Begründung: Terminregeln sind implementiert.
- [KONTEXT] src\backend\Centron.BL\EmployeeArea\EmployeeHolidayBL.cs (Header "obsolete and should be deleted") - Begründung: Urlaubsfunktion als Altlast markiert.
Prüfidee: Ein Nutzer ohne Personalmanagement-Recht kann Benutzerkonten nicht speichern; Terminzuweisung an Dritte ohne Recht wird abgelehnt.
Tracelinks: SyRS-7, SwRS-21, SwRS-55
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; Urlaubsaltlast als veraltet ausmustern.
Status: belegt
---
ID: StRS-21
Titel: Lager, Kommissionierung und Versandboxen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Lagermitarbeiter, Versand
Vorbedingung: Artikel-/Lagerstamm gepflegt; ggf. Versanddienst konfiguriert
Fakt: Lager-/Kommissionierlogistik mit E-Mail-Benachrichtigung nur bei vollständiger Kommissionierung (src\backend\Centron.BL\Logistics\LogisticSettings\LogisticSettingsBL.cs - SendEmailOnlyWhenFullyCommissioned), Lagerumbuchungen/Zweitlager (LogisticSettingsBL), Versandlabels über GLS/Shipcloud (src\apis\Centron.Api.Gls\CentronGlsLogic.cs, src\apis\Centron.Api.Shipcloud\CentronShipcloudLogic.cs).
Aussage: Das System soll Lagerbestände, Kommissionierung und Versand (Labels, Sendungsverfolgung über GLS/Shipcloud) abdecken und den Versandstart per Regel steuern.
Ergebnis: Sendungen werden korrekt deklariert und der Lagerprozess endet mit dokumentiertem Versand.
Belege:
- [SEKUNDÄR] src\backend\Centron.BL\Logistics\LogisticSettings\LogisticSettingsBL.cs - GetSettings (Konfigschalter SendEmailOnlyWhenFullyCommissioned) - Begründung: Prozessregel konfigurierbar belegt.
- [PRIMÄR] src\apis\Centron.Api.Gls\CentronGlsLogic.cs - DoValidateShipment (max. 50 Referenzen/30 Pakete) - Begründung: Versandvalidierung ist code-seitig durchgesetzt.
- [PRIMÄR] src\apis\Centron.Api.Shipcloud\CentronShipcloudLogic.cs - CreateShipmentAsync (Label-/Tracking-Rückgabe) - Begründung: Labelerzeugung implementiert.
Prüfidee: Eine unvollständig kommissionierte Position erzeugt keine Versandmail; GLS-Sendung über 30 Pakete wird abgewiesen.
Tracelinks: SyRS-10, SyRS-20, SwRS-47
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: StRS-22
Titel: IT-Planung, Kunden-Assets und Wissensobjekte
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: IT-Verantwortliche des Anwenderbetriebs, Techniker
Vorbedingung: IT-Planer-/Asset-Lizenzen gesetzt
Fakt: IT-Planer synchronisiert Checklisten-Kategorien mit Helpdesk-Typen (src\backend\Centron.BL\ItPlanner\ChecklistVirtualObjectCategoryBL.cs), Kundengeräte mit Soft-Delete und Protokoll (src\backend\Centron.BL\Devices\AccountDeviceBL.cs), Asset-Management mit AD-Anbindung (src\backend\Centron.BL\DocuBoard\), Volltextindex für Tickets/Kunden (src\backend\Centron.BL\IndexSearch\IndexSearchBL.cs).
Aussage: Das System soll die betreute IT-Landschaft der Kunden (Geräte, Lizenzen, Checklisten, AD-Benutzer) planen, dokumentieren und durchsuchbar machen.
Ergebnis: Techniker haben ein vollständiges Bild der Kundeninfrastruktur inkl. Historie.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Devices\AccountDeviceBL.cs - DeleteAccountDevice (IsDeleted=true + Protokolleintrag) - Begründung: Soft-Delete mit Audit ist durchgesetzt.
- [SEKUNDÄR] src\backend\Centron.BL\ItPlanner\ChecklistVirtualObjectCategoryBL.cs (Abgleich mit Helpdesk-Kategorien) - Begründung: Synchronisationslogik real.
- [PRIMÄR] src\backend\Centron.BL\IndexSearch\IndexSearchBL.cs (Objektindizes TicketFulltextIndex/AccountFulltextIndex, AND-Verknüpfung der Suchbegriffe) - Begründung: Volltextsuche ist implementiert.
Prüfidee: Gelöschtes Gerät bleibt mit Protokolleintrag in der Historie; Suchbegriff "Server Windows" findet nur Objekte, die beide Begriffe enthalten.
Tracelinks: SyRS-9, SwRS-64, SwRS-75
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; im Zielsystem mit einem einheitlichen Asset-Konzept konsolidieren (vgl. Analysebericht, Konsolidierung).
Status: belegt
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse/SwRS.md
+1673
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse/SyRS.md
+831
View File
@@ -0,0 +1,831 @@
# SyRS — System Requirements Specification
Systemebene: Systemverhalten, Schnittstellen, nicht-funktionale Anforderungen.
Belegpfade relativ zum Arbeitsverzeichnis. Tracelinks nach oben auf StRS, nach unten auf SwRS.
---
ID: SyRS-1
Titel: Mehrschichtige Systemlandschaft mit zentralem Web-Service
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Kompatibilität
Akteur: System
Vorbedingung: Installation vorhanden
Fakt: Desktop-Client (WPF), Web-Portal (Blazor Server) und Webservices/Worker greifen über einen zentralen Web-Service (Centron.Host) auf die Business-Logik und die MSSQL-Datenbank zu; Nexus verbindet sich per konfigurierter URL (src\nexus\CentronNexus\Shared\Centron\CentronService.cs - GetConnection liest URL aus Konfiguration).
Aussage: Das System soll aus Desktop-Client, Web-Portal und Integrationsdiensten bestehen, die ausschließlich über den zentralen Web-Service auf Geschäftslogik und Daten zugreifen (kein direkter DB-Zugriff der Clients).
Ergebnis: Eine einzige fachliche Logikinstanz bedient alle Kanäle.
Belege:
- [PRIMÄR] src\nexus\CentronNexus\Shared\Centron\CentronService.cs - GetConnection ("no URL found in the configuration" ohne Web-Service-URL) - Begründung: Nexus verbindet sich nachweislich nur per HTTP/Web-Service.
- [SEKUNDÄR] src\webservice\Centron.Host\Services\ICentronRestService.cs (1.254 WebInvoke-Methoden) - Begründung: Umfang des zentralen Dienstes.
- [KONTEXT] README.md (c-entron Nexus = Web-Frontend; Login über c-entron.NET Adressstamm) - Begründung: Architekturbild.
Prüfidee: Kein Clientprozess hält eine DB-Verbindungszeichenfolge; alle Fachdaten laufen über den Web-Service.
Tracelinks: StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Architekturmuster für SaaS Zielsystem.
Status: belegt
---
ID: SyRS-2
Titel: Sitzungsmodell mit Connection-Tickets
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Client, Web-Service
Vorbedingung: Erfolgreiche Anmeldung
Fakt: Tickets laufen standardmäßig nach 30 Minuten ab (Monitoring-Connector 5 Minuten, konfigurierbar, 24-Stunden-Variante; src\backend\Centron.BL\Administration\Logins\TicketBL.cs, Zeile 26 ff.); gleitende Verlängerung mit 5-Minuten-Kohärenz (RefreshTicketExpireDate); Bereinigung abgelaufener Tickets jede Minute (src\webservice\Centron.Host\AspNetCore\HostedServices\ConnectionTicketService.cs).
Aussage: Das System soll Sitzungen als opake Tickets führen, die nach Inaktivität ablaufen, gleitend verlängert und serverseitig regelmäßig bereinigt werden.
Ergebnis: Verwaiste Sitzungen belegen keine Sitzplätze mehr; Inaktivität beendet den Zugriff.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Administration\Logins\TicketBL.cs - TicketExpireInMinutes = 30 / RefreshTicketExpireDate ((newExpireDate - ticket.ExpiryDate).TotalMinutes < 5) - Begründung: Lebensdauer und Verlängerungsregel sind durchgesetzt.
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\HostedServices\ConnectionTicketService.cs - DeleteExpiredTickets alle 1 Minute - Begründung: Bereinigungslauf implementiert.
- [KONTEXT] src\backend\Centron.DAO\Repositories\Administration\Logins\TicketRepository.cs (Sitzungszählung pro Lizenz/Benutzer) - Begründung: Kopplung an Sitzplätze.
Prüfidee: Nach 30 Minuten Inaktivität schlägt der nächste Aufruf mit InvalidTicket fehl; aktive Nutzer werden nicht ausgeloggt.
Tracelinks: StRS-8, SwRS-38
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; Zeitwerte im Zielsystem konfigurierbar gestalten.
Status: belegt
---
ID: SyRS-3
Titel: Access-Token-Authentifizierung für API-Zugriffe
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Integrationspartner/API-Nutzer, Web-Service
Vorbedingung: Token-Modul lizenziert; Token ausgestellt
Fakt: API-Tokens sind 48-Zeichen-Zufallswerte, werden als SHA-256-Hash gespeichert, können deaktiviert/ablaufen und unterliegen Lizenzgrenzen (src\backend\Centron.BL\Administration\AccessTokens\AccessTokenBL.cs - ValidateToken, Zeile 377: HashToken, "Token ist deaktiviert.", "Token ist abgelaufen.").
Aussage: Das System soll maschinelle Zugriffe über Access-Tokens erlauben, die nie im Klartext gespeichert werden und aktivierbar/ablaufbar sind.
Ergebnis: Token-Leak ist einzelvalidierbar und widerrufbar.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Administration\AccessTokens\AccessTokenBL.cs - ValidateToken (SHA-256-Hashvergleich, IsActive/IsExpired-Prüfung) - Begründung: Tokenprüfung inkl. Hashspeicherung durchgesetzt.
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs (Ticket ODER Access Token als Bearer) - Begründung: Akzeptanz beider Tokenarten am Gateway.
- [KONTEXT] src\webservice\Centron.Controllers\Controllers\v1\Administration\AccessTokensController.cs - Begründung: Verwaltungsendpunkte vorhanden.
Prüfidee: Datenbank enthält nur Token-Hashes; deaktiviertes Token führt zu HTTP-401-artiger Ablehnung.
Tracelinks: StRS-8
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - modernes API-Zugriffsmuster.
Status: belegt
---
ID: SyRS-4
Titel: Mehrfache Anmeldeverfahren (Basic, Active Directory, OpenID Connect)
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Benutzer, Web-Service, AD/IdP (extern)
Vorbedingung: Systemauthentifizierungsmethode konfiguriert
Fakt: Authenticator-Fabrik wählt je SystemAuthenticationMethod (None/Basic/ActiveDirectory/OIDC) einen Authenticator (src\backend\Centron.BL\Administration\Logins\Auth\AuthenticatorFactory.cs, Zeile 99 ff.); AD/OIDC erfordern Lizenz bzw. JWT-Aktivierung; pro-Benutzer-Überschreibung erzwingt fehlschlagenden Basis-Login für Windows/OIDC-Konten.
Aussage: Das System soll Passwortanmeldung, Active-Directory-Anmeldung und OpenID-Connect-Anmeldung (SSO) unterstützen; die Methode ist zentral konfigurierbar und benutzerbezogen überschreibbar.
Ergebnis: Einheitliche Anmeldeaufrufe, unterschiedliche Backends.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Administration\Logins\Auth\AuthenticatorFactory.cs - GetFromBasicAuth (Switch über SystemAuthenticationMethod) - Begründung: Verfahrensauswahl ist technisch durchgesetzt.
- [PRIMÄR] src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs - ValidateRights (DisallowingRight/RequiredRight je Anwendung) - Begründung: Anwendungen können Anmeldung rechteabhängig sperren/erlauben.
- [SEKUNDÄR] src\webservice\Centron.Controllers\Controllers\Unversioned\JwtAuthController.cs (JWT→Ticket-Austausch) - Begründung: SSO-Brücke real.
Prüfidee: Bei AD-Modus schlägt Passwortanmeldung eines AD-Kontos fehl; OIDC-Benutzer erhalten nach IdP-Login ein c-entron-Ticket.
Tracelinks: StRS-7, SwRS-1, SwRS-4
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; OIDC als strategisches Verfahren priorisieren.
Status: belegt
---
ID: SyRS-5
Titel: Zwei-Faktor-Authentifizierung (RADIUS, E-Mail-Link, TOTP)
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Benutzer, Web-Service, RADIUS-Server, Mailserver
Vorbedingung: 2FA global aktiviert; Benutzer mit 2FA eingerichtet
Fakt: 2FA-Gate vor Ticketausstellung (src\backend\Centron.BL\Administration\Logins\TwoFactor\TwoFactorAuthBL.cs - ValidateTwoFactor/HasToValidateTwoFactor, Zeilen 41/90/130); Validatoren RADIUS und E-Mail-Link; separates TOTP-Modul mit Google-Authenticator-App (src\backend\Centron.BL\TwoFactorAuthenticator\TwoFactorAuthenticationBL.cs); Merkfristen in Kalendertagen je Benutzer/Konfiguration (TwoFactorAuthLastLogin).
Aussage: Das System soll für dafür eingerichtete Benutzer eine zweite Authentifizierungsfaktor-Prüfung (RADIUS, E-Mail-Link oder Authenticator-App) durchsetzen, mit konfigurierbarer Merkfrist je Gerät.
Ergebnis: Anmeldung ohne zweiten Faktor wird abgewiesen; zeitweise Merkung spart wiederholte Eingaben.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Administration\Logins\TwoFactor\TwoFactorAuthBL.cs - ValidateTwoFactor (globaler Schalter, per-user-Opt-in, Kalendertage-Frist) - Begründung: 2FA-Durchsetzung am Anmeldepfad.
- [PRIMÄR] src\backend\Centron.BL\Administration\Logins\Auth\BasicAuthenticator.cs - AuthenticateInternal (nach Passwortprüfung: _twoFactorAuthBL.ValidateTwoFactor → TwoFactorAuthFailed) - Begründung: Gate sitzt in der Anmeldekette.
- [SEKUNDÄR] src\backend\Centron.BL\Administration\Logins\TwoFactor\RadiusTwoFactorValidator.cs / EmailTwoFactorValidator.cs - Begründung: konkrete Faktor-Verfahren.
Prüfidee: Benutzer mit 2FA erhält nach korrektem Passwort einen zweiten Prüfaufruf; falscher Faktor verhindert die Ticketausstellung.
Tracelinks: StRS-7, SwRS-25, SwRS-26, SwRS-27, SwRS-28, SwRS-53
Konsolidierung: Kandidat: SwRS-26 (TOTP-Modul) und SwRS-28 (RADIUS/E-Mail) - zwei getrennte 2FA-Implementierungen für denselben fachlichen Zweck, im Zielsystem zusammenführen.
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-6
Titel: Legacy-REST-Dienst unter /REST und /RESTC
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Clients (WPF, Nexus, Add-ins), Web-Service
Vorbedingung: Web-Service gestartet
Fakt: WCF-artiger Vertrag wird auf ASP.NET-Core-Endpunkte /REST (unkomprimiert) und /RESTC (komprimiert) abgebildet; doppelte URL-Templates verhindern den Start (src\webservice\Centron.Host\AspNetCore\WcfBridge\CentronWcfBridge.cs, Zeilen 37-38, 62); 1.254 Methoden in Interface-Parts (src\webservice\Centron.Host\Services\ICentronRestService.cs).
Aussage: Das System soll seinen gesamten Fachdienst als einheitliche REST-Schnittstelle in zwei Endpunktvarianten (unkomprimiert/komprimiert) bereitstellen; URL-Kollisionen sind Startfehler.
Ergebnis: Alle Clients nutzen eine konsistente Schnittstelle mit komprimierbarem Transport.
Belege:
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\WcfBridge\CentronWcfBridge.cs - MapCentronRestService("/REST", false)/("/RESTC", true) + InvalidOperationException bei Doppel-URL - Begründung: Endpunktstruktur und Kollisionsschutz durchgesetzt.
- [SEKUNDÄR] src\webservice\Centron.WebServices.Core\Connections\CentronWebService.cs (Client-Basisadresse ".../RESTC/", infinite timeout) - Begründung: Clientseite bestätigt Endpunkt-/Kompressionskontrakt.
- [KONTEXT] src\webservice\Centron.WebServices.Core\Messages\Request.cs (Ticket-DataMember in jedem Request) - Begründung: einheitlicher Sitzungsparameter.
Prüfidee: Identischer Aufruf auf /REST und /RESTC liefert gleiche Antwort; doppelt vergebene UriTemplate verhindert Dienststart mit klarer Meldung.
Tracelinks: StRS-1, StRS-4, StRS-5, SwRS-10, SwRS-11, SwRS-79
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen als Vertragsbasis; neue Oberfläche zusätzlich (siehe SyRS-7).
Status: belegt
---
ID: SyRS-7
Titel: Moderne REST-API mit deklarativer Rechteprüfung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Web-Portal/Integratoren, Web-Service
Vorbedingung: Gültiges Ticket/Token im Request
Fakt: Neue Controller-Schicht (41 Controller, v1/Unversioned) mit Attributen AuthorizeUserRight/AuthorizeAnyUserRight/AuthorizeAllUserRights; Filter antwortet 401 ohne Nutzer und 403 ohne Recht (src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs, Zeilen 45-51); alle Controller erfordern Autorisierung (CentronHost.cs - MapControllers().RequireAuthorization()).
Aussage: Das System soll neue API-Endpunkte deklarativ mit c-entron-Rechten schützen: ohne Anmeldung 401, ohne Recht 403.
Ergebnis: Konsistente Autorisierungssemantik über alle modernen Endpunkte.
Belege:
- [PRIMÄR] src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs - UserRightAuthorizationFilter.OnAuthorization (UnauthorizedResult/ForbidResult) - Begründung: durchsetzende Stelle der Rechteprüfung.
- [PRIMÄR] src\webservice\Centron.Host\CentronHost.cs - Configure (MapControllers().RequireAuthorization()) - Begründung: Globaler Autorisierungszwang.
- [SEKUNDÄR] src\webservice\Centron.Controllers\Authorization\README.md - Begründung: dokumentierte Semantik.
Prüfidee: Anonyme Anfrage → 401; angemeldeter Nutzer ohne Recht → 403; mit Recht → 200.
Tracelinks: StRS-7, StRS-17, StRS-20, SwRS-7, SwRS-9, SwRS-21, SwRS-51, SwRS-69
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-8
Titel: Echtzeithubs über SignalR
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Clients, Web-Service
Vorbedingung: Gültiges Ticket (Hub-Verbindung autorisiert)
Fakt: Vier Hubs unter /Realtime: notifications, chat, availabilityStatus, tapi (src\webservice\Centron.Host\AspNetCore\SignalR\CentronSignalR.cs); Hubs erben [Authorize] und bilden Ticket→ConnectionId ab (CentronHub.cs); Server-zu-Server-Authentifizierung über Shared SecretKey (src\webservice\Centron.Host\RealTimeServices\SecretKeyHandler.cs).
Aussage: Das System soll Ereignisse (Benachrichtigungen, Chat, Anwesenheit, Telefonie) in Echtzeit an verbundene Clients pushen, pro Ticket adressierbar.
Ergebnis: Clients erhalten Ereignisse ohne Polling.
Belege:
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\SignalR\CentronSignalR.cs - MapHub<...>(...) für 4 Hubs - Begründung: Hubs sind serverseitig fest verdrahtet.
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\SignalR\CentronHub.cs - [Authorize] + Ticket→Connection-Map - Begründung: Hubzugriff ist ticketgebunden.
- [SEKUNDÄR] src\webservice\Centron.Host\RealTimeServices\SecretKeyHandler.cs (Vergleich des Bearer-SecretKeys) - Begründung: Maschinen-zu-Maschinen-Zugang.
Prüfidee: Push einer Benachrichtigung erscheint beim Zielclient < 1 s; unbefugte Hubverbindung wird abgewiesen.
Tracelinks: StRS-15, SwRS-34
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-9
Titel: Lizenzprüfung beim Start und Sitzplatzkontrolle
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Web-Service, Lizenzserver (extern)
Vorbedingung: Lizenzdatei/Lizenzserver erreichbar
Fakt: Start prüft Lizenz vor Datenbankverbindung/-update ("We have to check the license first..."; src\webservice\Centron.Host\CentronHost.cs - Start/TryLoadLicense vor SetupDatabaseConnection); Anmeldung zählt aktive Tickets gegen Lizenzanzahl (src\backend\Centron.BL\Administration\Licensing\LicenseManager.cs, Zeilen 280-282); Sitzplatzzählung je Benutzersitzung (src\backend\Centron.DAO\Repositories\Administration\Logins\TicketRepository.cs - GetTicketCount, GroupBy LicenseGUID/UserI3D/WebAccountI3D).
Aussage: Das System soll beim Start die Lizenz prüfen (sonst Abbruch) und bei der Anmeldung Sitzplätze nach aktiven Sitzungen je Lizenz begrenzen.
Ergebnis: Ohne gültige Lizenz startet der Dienst nicht; Überbelegung wird abgewiesen.
Belege:
- [PRIMÄR] src\webservice\Centron.Host\CentronHost.cs - Start (TryLoadLicense vor SetupDatabaseConnection; CheckLicense.ThrowIfError vor DB-Update) - Begründung: Startreihenfolge erzwingt Lizenzvorprüfung.
- [PRIMÄR] src\backend\Centron.BL\Administration\Licensing\LicenseManager.cs - CheckLicense (aktuelle vs. maximale Lizenzen, Fehlermeldung "Die maximale Anzahl an Lizenzen wurde erreicht.") - Begründung: Sitzplatzgrenze an der Anmeldung.
- [SEKUNDÄR] src\backend\Centron.DAO\Repositories\Administration\Logins\TicketRepository.cs - GetTicketCount (Zähllogik je UsageKind) - Begründung: Zählbasis Sitzung je Benutzer/Gerät.
Prüfidee: Lizenzserver ausgefallen → Dienststart bricht ab; n+1-te gleichzeitige Anmeldung bei n Plätzen schlägt fehl.
Tracelinks: StRS-8, StRS-11, StRS-22, SwRS-36
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-10
Titel: Hintergrunddienste im Web-Service
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (Scheduler)
Vorbedingung: ExecuteServices aktiviert
Fakt: ~35 ManagedBackgroundServices (Ticketbereinigung, Reminder, Eskalationen, Exchange-Sync, Telemetrie-Flush, Preisupdates, Volltextindex u. a.), nur bei ExecuteServices=true registriert (src\webservice\Centron.Host\CentronHost.cs - AddHostedService-Abschnitt; src\webservice\Centron.Host\AspNetCore\HostedServices\).
Aussage: Das System soll periodische Wartungs- und Geschäftsjobs (Erinnerungen, Eskalationen, Synchronisation, Indizierung) als konfigurierbare Hintergrunddienste ausführen; rein dienliche Instanzen können sie deaktivieren.
Ergebnis: Zeitgesteuerte Prozesse laufen zentral und konfigurierbar.
Belege:
- [PRIMÄR] src\webservice\Centron.Host\CentronHost.cs - Configure (if (WebServiceConfigHelper.Current?.ExecuteServices == true) { ...AddHostedService... }) - Begründung: Aktivierungsschalter technisch durchgesetzt.
- [SEKUNDÄR] src\webservice\Centron.Host\AspNetCore\HostedServices\ConnectionTicketService.cs (GetExecutionInterval = 1 Minute) - Begründung: exemplarischer Dienstintervall.
- [KONTEXT] src\webservice\Centron.Host\AspNetCore\HostedServices\ (Verzeichnis mit ~35 Diensten) - Begründung: Dienstumfang.
Prüfidee: ExecuteServices=false → keine Erinnerungsmails/Indizierungsläufe; true → Dienste laufen im Minutenraster.
Tracelinks: StRS-3, StRS-6, StRS-21, SwRS-18, SwRS-72
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-11
Titel: Hosting-Varianten (Windows-Service, Konsole/Docker, http.sys/Kestrel)
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Übertragbarkeit (Portierbarkeit)
Akteur: Betreiber
Vorbedingung: Betriebssystem Windows oder Linux
Fakt: Windows-Service-Wrapper (src\webservice\Centron.Host.WindowsService\CentronService.cs - OnStart → CentronHost.Instance.Start()), plattformübergreifender Konsolenhost für Docker (src\webservice\Centron.Host.Console\Program.cs mit Befehlen start/hardware-id/configure), http.sys unter Windows und Kestrel unter Linux inkl. HTTPS-Zertifikatsoption (src\webservice\Centron.Host\CentronHost.cs - UseHttpSys/UseKestrel).
Aussage: Das System soll als Windows-Dienst, als plattformunabhängiger Konsolendienst (Container) und auf den Webservern http.sys (Windows) bzw. Kestrel (Linux) betreibbar sein.
Ergebnis: Derselbe Dienst läuft on-premise wie containerisiert.
Belege:
- [PRIMÄR] src\webservice\Centron.Host\CentronHost.cs - Start (OperatingSystem.IsWindows() → UseHttpSys, sonst UseKestrel mit UseHttps bei https-Schema) - Begründung: Hostingentscheidung im Code.
- [SEKUNDÄR] docker\c-entron-webservice\Dockerfile (self-contained Centron.Host.Console auf Alpine) - Begründung: Containerbetrieb vorgesehen.
- [SEKUNDÄR] src\webservice\Centron.Host.Console\Program.cs - configure-Befehl (Port/PublicUrl/ConnectionString) - Begründung: Headless-Initialkonfiguration.
Prüfidee: Derselbe Artefaktstart unter Windows als Dienst und unter Linux im Container bedient identische Endpunkte.
Tracelinks: StRS-1, SyRS-32
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-12
Titel: Zentrale Dienstkonfiguration (WebServiceConfig.xml, ConnectionManager)
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Administrator
Vorbedingung: Installationszugriff
Fakt: Konfigurationsdatei WebServiceConfig.xml mit Adresse, öffentlicher Adresse, TLS-Zertifikat, AD, 2FA, Proxy, SecretKey (src\backend\Centron.BL\Administration\WebServiceConfiguration\WebServiceConfig.cs; Standardadresse http://localhost:1234/CentronService in WebServiceConfigHelper.cs); WPF-Verwaltungswerkzeug c-entron Connection Manager (src\webservice\c-entron.misc.ConnectionManager\) inkl. SQL-Server-Health-Check (SQLServerCheckToolViewModel.cs).
Aussage: Das System soll seine Betriebsparameter (Adresse, Zertifikat, Authentifizierung, Proxy, Hintergrunddienste) über eine zentrale Konfigurationsdatei steuern, verwaltet über ein dediziertes Admintool mit Datenbank-Health-Check.
Ergebnis: Betriebliche Änderungen erfolgen ohne Neukompilierung.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Administration\WebServiceConfiguration\WebServiceConfig.cs (WebServiceAddress/PublicWebServiceAddress/WebServiceCertificateFilePath/WebServiceCertificatePassword) - Begründung: Konfigurationsmodell mit TLS-Optionen.
- [SEKUNDÄR] src\webservice\c-entron.misc.ConnectionManager\ConnectionManagerViewModel.cs (Felder für 2FA-Typ, RADIUS, Lizenzserver-Status) - Begründung: Admintool-Funktionsumfang.
- [KONTEXT] docker\compose\WebServiceConfig.xml (Beispielkonfig) - Begründung: Deploymentbeispiel.
Prüfidee: Ändern der Adresse/Zertifikatspfade in der XML und Neustart bringt den Dienst an die neue Adresse; Health-Check prüft MAXDOP/Speicher/Recovery-Modell.
Tracelinks: StRS-2, SwRS-48
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; im SaaS-Zielsystem durch zentrale Konfigurationsverwaltung ersetzen.
Status: belegt
---
ID: SyRS-13
Titel: Transportverschlüsselung optional, CORS uneingeschränkt
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Sicherheit
Akteur: Betreiber, Angreifer (Bedrohungsperspektive)
Vorbedingung: Web-Service im Netz erreichbar
Fakt: HTTPS nur, wenn konfigurierte Adresse https-Schema trägt (CentronHost.cs - UseKestrel + UseHttps mit PKCS12-Zertifikat aus Konfiguration); keine UseHttpsRedirection/UseHsts im Quellbestand; CORS vollständig offen (b.UseCors(d => d.AllowAnyOrigin().AllowAnyHeader().AllowAnyMethod()); CentronHost.cs).
Aussage: Das System erlaubt aktuell Klartext-Betrieb und belässt CORS uneingeschränkt; Transportverschlüsselung und CORS-Beschränkung sind Betreiberpflicht.
Ergebnis: Ohne Betreibermaßnahmen läuft der Verkehr unverschlüsselt mit offenem CORS.
Belege:
- [PRIMÄR] src\webservice\Centron.Host\CentronHost.cs - UseCors(AllowAnyOrigin/AnyHeader/AnyMethod) - Begründung: Offenheit ist im Code fixiert.
- [PRIMÄR] src\webservice\Centron.Host\CentronHost.cs - HTTPS-Zweig nur bei https-Schema + Zertifikat aus WebServiceConfig - Begründung: Verschlüsselung ist Option, kein Zwang.
- [KONTEXT] Suchbefund: kein Auftreten von UseHttpsRedirection/UseHsts in src\webservice - Begründung: negative Beobachtung dokumentiert.
Prüfidee: HTTP-Aufruf ohne TLS wird akzeptiert; Preflight von beliebiger Origin wird erlaubt - jeweils als Sicherheitslücke zu bewerten.
Tracelinks: StRS-1, SyRS-12
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - historisch gewachsene Betreiberfreiheit; im Zielsystem HTTPS erzwingen und CORS einschränken.
Status: belegt
---
ID: SyRS-14
Titel: Web-Portal-Authentifizierung (Cookie 12 h, OIDC, Porttrennung)
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Mitarbeiter, Kunden-Web-Account, IdP (Microsoft Entra)
Vorbedingung: Nexus-Host gestartet; ggf. OIDC konfiguriert
Fakt: Cookie-Authentifizierung mit 12-Stunden-MaxAge und OIDC (code flow, SaveTokens) im Nexus-Host (src\nexus\CentronNexus.Host\Program.cs, Zeilen 264-287); zwei Anmeldetypen User/Webaccount als Claim (src\nexus\CentronNexus\Shared\Authorization\CentronAuthorization.cs); Kundenportal optional auf separatem Port (Shared\Authorization\PortAuthorization.cs - HostPort 8050).
Aussage: Das System soll das Web-Portal über Browser-Cookie (max. 12 Stunden) und optionalen Entra-OIDC-Login absichern und kann Kundenportal und Mitarbeiterportal auf getrennten Ports betreiben.
Ergebnis: Portalzugriffe sind sessiongebunden; Kunde und Mitarbeiter nutzen getrennte Zugangskanäle.
Belege:
- [PRIMÄR] src\nexus\CentronNexus.Host\Program.cs - AddCookie(MaxAge = TimeSpan.FromHours(12)) + AddOpenIdConnect(ResponseType "code") - Begründung: Authentifizierungssetup implementiert.
- [PRIMÄR] src\nexus\CentronNexus\Shared\Authorization\CentronAuthorization.cs - LoginPrefix/UserLoginType/WebAccountLoginType - Begründung: Anmeldetyp-Trennung durchgesetzt.
- [SEKUNDÄR] src\nexus\CentronNexus\Shared\Authorization\PortAuthorization.cs - Begründung: Porttrenn-Mechanismus.
Prüfidee: Nach 12 Stunden ist die Portal-Cookie-Sitzung abgelaufen; Mitarbeiterportalseite ist vom Kundenport nicht erreichbar (bei getrennten Ports).
Tracelinks: StRS-9, StRS-10, SwRS-35
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-15
Titel: E-Rechnungsgenerierung ZUGFeRD/XRechnung mit PDF-Einbettung
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Web-Service, Rechnungsempfänger
Vorbedingung: Rechnung vorhanden; Feature-Setting IsZugferdInvoiceActive aktiv
Fakt: Versionen von ZUGFeRD 1.0 bis XRechnung 3.0.1 ("ZUGFeRD 2.3.3 & 2.4 & 2.5 (gültig ab 07.05.2025)") mit NewestActiveZugferdVersion (src\webservice\Centron.WebServices.Core\Entities\Sales\Receipts\Invoices\ZugferdKind.cs, Zeile 6); Kundenflag ExportZUGFeRDDocument übersteuert Mandanteneinstellung; Leitweg-ID bestimmt XRechnung-/EN16931-Profil (src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs, Zeilen 153/193); XML wird ins Rechnungs-PDF eingebettet (CreateZugferdConformPdfDocument, Anhang factur-x.xml).
Aussage: Das System soll E-Rechnungen je Empfänger in der geforderten Version/Profile erzeugen (XRechnung bei Leitweg-ID, sonst EN16931/Comfort), kundenspezifisch ein-/ausschaltbar, mit im PDF eingebetteter XML.
Ergebnis: Jede Rechnung kann normkonform elektronisch zugestellt werden.
Belege:
- [PRIMÄR] src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs - GetZugferFormat/GenerateZugferdFile/CreateZugferdConformPdfDocument - Begründung: Versions-/Profillogik und PDF-Einbettung implementiert.
- [PRIMÄR] src\webservice\Centron.WebServices.Core\Entities\Sales\Receipts\Invoices\ZugferdKind.cs (Versionskatalog inkl. Gültigkeitshinweis) - Begründung: Unterstützte Versionen enumeriert.
- [SEKUNDÄR] src\backend\Centron.Interfaces\Accounts\IAccountCustomer.cs (ExportZUGFeRDDocument-Flag, Zeile 98) - Begründung: Kundenoverride.
Prüfidee: Rechnung an öffentlichen Auftraggeber mit Leitweg-ID erzeugt XRechnung-Konformitätslevel; Kundenflag aus → ZUGFeRD deaktiviert mit Warnung.
Tracelinks: StRS-13, SwRS-42
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - regulatorisch.
Status: belegt
---
ID: SyRS-16
Titel: E-Rechnungsimport für Lieferantenrechnungen
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Kreditorenbearbeiter, Web-Service
Vorbedingung: ZUGFeRD-PDF/XML einer Lieferantenrechnung vorliegend
Fakt: REST-Endpunkt POST parse nimmt Dateibytes entgegen und liefert ZugferdInvoiceDTO (src\webservice\Centron.Controllers\Controllers\v1\Receipts\ZugferdImportController.cs - ParseZugferdFile); der Import liest Kopf, Positionen und Seriennummern aus dem Dokument; docs\reference\zugferd* dokumentiert das Feldmapping.
Aussage: Das System soll eingehende ZUGFeRD-/XRechnung-Dokumente parsen und als Vorlage für Lieferantenbelege bereitstellen (Kopf, Positionen, Seriennummern, Artikelabgleich).
Ergebnis: Lieferantenrechnungen werden ohne manuelle Datenerfassung erfasst.
Belege:
- [PRIMÄR] src\webservice\Centron.Controllers\Controllers\v1\Receipts\ZugferdImportController.cs - ParseZugferdFile ([HttpPost("parse")], byte[] → DTO) - Begründung: Importendpunkt implementiert.
- [KONTEXT] docs\reference\zugferd* - Begründung: Mapping-Dokumentation des Imports.
Prüfidee: Upload eines ZUGFeRD-PDFs liefert Kopf-/Positionsdto, dessen Beträge mit dem Dokument übereinstimmen.
Tracelinks: StRS-13
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-17
Titel: Online-Banking-Anbindung (FinTS/HBCI und finAPI)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Finanzbuchhaltung, Banken, finAPI (extern)
Vorbedingung: Bankzugang konfiguriert; Lizenz gesetzt
Fakt: Zwei Bankwege: FinTS via libfintx (src\backend\Centron.Gateway\OnlineBanking\OnlineBankingConnectionLibfintx.cs - TestConnectionForFinTSConfiguration, TAN-Dialoge inkl. decoupled 922) und finAPI-REST (src\apis\Centron.APIs.FinAPI\FinApiClient.cs - OAuth-Token, bankConnections, accounts, transactions; Web-Form-Import); Umsatzimport bucht gegen Rechnungen (src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingAccountTransactionsBL.cs).
Aussage: Das System soll Bankkonten über FinTS/HBCI oder finAPI anbinden, Umsätze laden und dem Zahlungsabgleich zuordnen, inklusive TAN-Verfahren.
Ergebnis: Zahlungseingänge werden automatisiert importiert und zugeordnet.
Belege:
- [PRIMÄR] src\backend\Centron.Gateway\OnlineBanking\OnlineBankingConnectionLibfintx.cs - LoadOnlineBankingTransactionsByFinTS (Swift/MT940-Segmente → DTO) - Begründung: Bankabruf implementiert.
- [PRIMÄR] src\apis\Centron.APIs.FinAPI\FinApiConstants.cs (TokenPath/BankConnectionsPath/TransactionsPath) - Begründung: finAPI-Operationsumfang.
- [PRIMÄR] src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingAccountTransactionsBL.cs - BookAmountsForAccountTransacitons (Zeile 883) - Begründung: Verbuchung der Umsätze.
Prüfidee: Abgerufener Kontoauszug erzeugt passende Transaktionszeilen; zugeordneter Betrag schließt die Rechnung ab.
Tracelinks: StRS-6, SwRS-44, SwRS-49
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; Zahlungsausgang über finAPI im Zielsystem klären (Lücke).
Status: belegt
---
ID: SyRS-18
Titel: SEPA-Lastschriftexport (pain.008.001.08)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Finanzbuchhaltung, Bank
Vorbedingung: Lastschrifteinzüge vorbereitet; Mandate vorhanden
Fakt: SEPA-Generator erzeugt pain.008.001.08 mit B2B/CORE je Verfahren (src\backend\Centron.Gateway\DataExchange\PaymentTransactions\Sepa\SepaFileGeneratorV2.cs, Zeilen 33, 129), Sequenztypen in getrennten PmtInf-Blöcken, Namenskürzung auf 70 Zeichen; beigefügtes TVS-Schema pain.008.001.02_GBIC_3.xsd.
Aussage: Das System soll Lastschriften als ISO-20022-pain.008-Dateien im Format 008.001.08 erzeugen, getrennt nach Verfahrens- und Sequenzgruppen.
Ergebnis: Banken können die Datei direkt verarbeiten.
Belege:
- [PRIMÄR] src\backend\Centron.Gateway\DataExchange\PaymentTransactions\Sepa\SepaFileGeneratorV2.cs - GenerateXmlSepaFile (Namespace-Zeile 33; B2B/CORE Zeile 129) - Begründung: Formatgenerierung durchgesetzt.
- [SEKUNDÄR] src\backend\Centron.Gateway\DataExchange\PaymentTransactions\Sepa\pain.008.001.02_GBIC_3.xsd (TVS-Subset, B2B/CORE-Doku) - Begründung: Validierungsschema beigelegt.
Prüfidee: Exportierte XML validiert gegen das beiliegende Schema; CORE- und B2B-Lastschriften liegen in getrennten PmtInf-Blöcken.
Tracelinks: StRS-6, SwRS-43
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-19
Titel: EDI-Import/-Export mit Distributoren
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Einkauf/Vertrieb, Distributoren (Alltron, ALSO, EGIS, Komsa, Herweck, Avnet, BBG)
Vorbedingung: EDI-Gateway-Einstellungen gepflegt
Fakt: Import-Vertrag mit GatewayKind und ImportOrder (src\backend\Centron.Gateway\Import\EDI\IEDIGatewayImport.cs; Umsetzung Avnet.cs); Export-Dispatcher je EdiGatewayKind inkl. BBG-Versand via SOAP mit Nutzer/Passwort-Prüfung (src\backend\Centron.Gateway\Export\EDI\EDIGatewayExport.cs; BBGWebserviceConnect.cs - Upload, Doctype INVOIC); XSD-Modellklassen je Distributor (src\backend\Centron.Gateway\EDI_*).
Aussage: Das System soll Bestellungen von Distributoren importieren und Belege/Bestellungen als EDI-Nachrichten je Distributorformat exportieren.
Ergebnis: Elektronischer Handelsverkehr in Distributorspezifischen Formaten.
Belege:
- [PRIMÄR] src\backend\Centron.Gateway\Import\EDI\IEDIGatewayImport.cs (GatewayKind/ImportOrder(Stream)) - Begründung: Importvertrag.
- [PRIMÄR] src\backend\Centron.Gateway\Export\EDI\BBGWebserviceConnect.cs - Upload (leere Zugangsdaten → Fehlermeldungen, DocumentPost INVOIC) - Begründung: Exportversand mit Validierung.
- [SEKUNDÄR] src\backend\Centron.Gateway\EDI_Alltron\ (XSD-Klassen order/orderresponse/invoice/delivery_note) - Begründung: Nachrichtenschemata.
Prüfidee: Avnet-Orderdatei erzeugt Bestellentwurf; Export einer Rechnung als INVOIC an BBG mit korrekten Sender-/Empfänger-IDs.
Tracelinks: StRS-5, StRS-12, SwRS-48
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; BBG-Export als veraltet prüfen (Exportklasse ohne Rumpf, siehe Selbstbewertung).
Status: belegt
---
ID: SyRS-20
Titel: Artikeldaten- und Versanddienste (Icecat, ITscope, COP, EGIS, GLS, Shipcloud)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Vertrieb/Einkauf, Marktdaten-/Versandanbieter
Vorbedingung: API-Zugangsdaten in Einstellungen
Fakt: Marktdaten-Clients per REST/SOAP (src\apis\Centron.APIs.IcecatDataAccess\IcecatApi.cs - Basic-Auth ISO-8859-1; ITscopeApi.cs - API 2.1; CopApi.cs - SOAP getArticles; EgisApi.cs - Platzhalter-Konto abgelehnt); Versandclients (src\apis\Centron.Api.Gls\CentronGlsLogic.cs; CentronShipcloudLogic.cs - Basic-Auth mit API-Key).
Aussage: Das System soll Artikelbilder/-daten aus Marktdatenplattformen und Versandlabels über Transportdienst-APIs abrufen, jeweils mit hinterlegten Zugangsdaten.
Ergebnis: Artikel sind mit Marktdaten angereichert; Sendungen werden elektronisch angemeldet.
Belege:
- [PRIMÄR] src\apis\Centron.Api.Shipcloud\CentronShipcloudLogic.cs - CreateShipmentAsync (Authorization: Basic, Tracking-/Label-URLs zurück) - Begründung: Versand-API real angebunden.
- [PRIMÄR] src\apis\Centron.Api.Gls\CentronGlsLogic.cs - DoValidateShipment (Limits 50 Referenzen/30 Pakete) - Begründung: Validierung implementiert.
- [SEKUNDÄR] src\apis\Centron.APIs.IcecatDataAccess\IcecatApi.cs (SendRequestAsync mit Basic-Auth) - Begründung: Marktdatenabruf real.
Prüfidee: Artikelimport von ITscope füllt Hersteller-/EAN-Daten; Shipcloud-Labelerstellung liefert Tracking-URL.
Tracelinks: StRS-12, StRS-21, SwRS-47, SwRS-54
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-21
Titel: Buchhaltungsexport und -import (DATEV u. a.)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Finanzbuchhaltung, Steuerberater-Systeme
Vorbedingung: Buchhaltungsnummern gepflegt
Fakt: Exportfabrik mit 15+ Formaten (DATEV Ascii/XML-Online 2012+2020, Abacus, Addison, Sage 50/Office Line, SAP, Navision, Lexware, GDI, Schilling AS400, Europa3000, Stotax, Custom; src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs - InvokeExportClass, Zeilen 1574-1607); Basisklasse erzwingt Buchhaltungsnummer (src\backend\Centron.Gateway\DataExchange\BookKeeping\BookKeepingFileExport.cs - "Adresse {0} hat keine Buchhaltungsnummer."); DATEV-Belegtransfer lizenzgebunden.
Aussage: Das System soll Belege in gängige Buchhaltungsformate exportieren und Rückimportformate (Stotax, DATEV AccountingPro, Abacus u. a.) verarbeiten, mit Pflichtprüfung der Buchhaltungsnummern.
Ergebnis: Finanzdaten wandern ohne Doppelbuchung in die externe Buchhaltung und zurück.
Belege:
- [PRIMÄR] src\backend\Centron.Gateway\DataExchange\BookKeeping\BookKeepingFileExport.cs (fehlende Buchhaltungsnummer → Fehler) - Begründung: Stammdatenpflicht durchgesetzt.
- [PRIMÄR] src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs - InvokeExportClass (Formatfabrik) - Begründung: Formatpalette implementiert.
- [KONTEXT] src\backend\Centron.Interfaces\Administration\Logins\LicenseGuids.cs (DatevOnline) - Begründung: Lizenzbindung des DATEV-Belegtransfers.
Prüfidee: Export ohne Buchhaltungsnummer wird je Adresse abgewiesen; DATEV-XML-Datei wird vom Steuerberater-Import akzeptiert.
Tracelinks: StRS-6, SwRS-45
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; veraltete Formate (AS400/Europa3000) prüfen.
Status: belegt
---
ID: SyRS-22
Titel: Datenbankplattform MSSQL mit Legacy-Schema
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System, DBA
Vorbedingung: SQL Server bereitgestellt
Fakt: Ausgeliefertes Schema-Script (SSMS_DB_SCHEMA.sql, 76.793 Zeilen, Datenbank CentronVOED2, Kompatibilitätslevel 160) mit deutschen Tabellennamen (Kunden, RechKopf, RechPos, Nummernkreis, Sichtrus/Sichmemb/Sichbenu, Mahnlauf, ChangeLog); UNIQUE-Constraints für Kunden-/Lieferantennummern (Zeilen 3784, 3854); Belegnummern ohne UNIQUE-Constraint (RechKopf.Nummer, Zeile 3233).
Aussage: Das System speichert Daten in einer MSSQL-Datenbank mit historisch deutschem Schema; fachliche Einzigartigkeit ist teils durch DB-Constraints, teils nur durch Anwendungslogik gesichert.
Ergebnis: Datenmodell ist konsolidiert reproduzierbar; Constraint-Lücken sind bekannt.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql - IX_AccountCustomers_UniqueNumber (Zeile 3784), IX_AccountSuppliers_UniqueNumber (Zeile 3854) - Begründung: DB-seitige Einzigartigkeit nachweisbar.
- [PRIMÄR] SSMS_DB_SCHEMA.sql - RechKopf-Definition (Nummer [int] NOT NULL ohne Unique, Zeile 3233) - Begründung: Abwesenheit des Constraints belegt (Lücke).
- [SEKUNDÄR] src\backend\Centron.DAO\Mappings\CustomerArea\CustomerBaseMaps.cs (Table("Kunden"), Map ... Column("Gesperrt")) - Begründung: Entities binden an deutsche Spalten.
Prüfidee: Doppelte Kundennummer löst DB-Fehler aus; doppelte Belegnummer ist DB-seitig möglich (nur Applogik verhindert sie).
Tracelinks: StRS-1, StRS-2, SwRS-12, SwRS-40
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; Spaltennamen im Zielsystem freigestellt, Constraint-Lücken schließen.
Status: belegt
---
ID: SyRS-23
Titel: OR-Mapping- und Datenschicht mit Änderungsverfolgung
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Datenbankverbindung konfiguriert
Fakt: FluentNHibernate mit Custom-MS-SQL-Dialekt, Mappings aus Assembly, globale Listener (ChangeTracking, String-Kürzung) (src\backend\Centron.DAO\DAOFactory.cs - InitializeAsyncInternal); Feld-Änderungsprotokoll in ChangeLog (src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs); 983 Mapping-Dateien (src\backend\Centron.DAO\Mappings\); NamedQueryPool als eingebettete XML-Ressource (src\backend\Centron.DAO\NamedQueries\NamedQueryManager.cs).
Aussage: Das System soll alle Datenzugriffe über eine ORM-Schicht mit deklarativen Mappings führen und ausgewählte Feldänderungen automatisch protokollieren.
Ergebnis: Datenzugriff ist zentral konfigurierbar; Änderungsnachweise entstehen ohne Fachcode.
Belege:
- [PRIMÄR] src\backend\Centron.DAO\DAOFactory.cs - AppendListeners (PreUpdate: ChangeTrackingEventListener, TruncateStringsEventListener) - Begründung: Listener-Verkabelung durchgesetzt.
- [PRIMÄR] src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs - CreateChangeLog (Alt/Neu/Benutzer) - Begründung: Protokollschreibung implementiert.
- [SEKUNDÄR] src\backend\Centron.DAO\NamedQueries\NamedQueryManager.cs (Manifest-Ressource "NamedQueryPool.xml", Fehler bei fehlender Query) - Begründung: SQL-Pool-Mechanik.
Prüfidee: Update eines [TrackChanges]-Feldes erzeugt genau einen ChangeLog-Eintrag; fehlender NamedQuery-Eintrag wirft benannte Ausnahme.
Tracelinks: StRS-14, SwRS-39, SwRS-40, SwRS-41
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; ORM-Wahl im Zielsystem frei, Auditkonzept übernehmen.
Status: belegt
---
ID: SyRS-24
Titel: Anonyme Nutzungs-Telemetrie
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: Hersteller (c-entron), System
Vorbedingung: Web-Service läuft; Telemetrie-Upload erreichbar
Fakt: Telemetrie-Aggregator mit DB-GUID/Hardware-ID und HTTP-Upload plus Flush-/Upload-Hintergrunddienste (src\webservice\Centron.Host\AspNetCore\Telemetry\; HttpTelemetryUploadClient; TelemetryFlushService); Telemetrie-Arten zugeordnet (src\backend\Centron.BL\Telemetry\).
Aussage: Das System soll anonyme Nutzungs- und Betriebsdaten sammeln und periodisch an den Hersteller übermitteln.
Ergebnis: Hersteller erhält Betriebskennzahlen ohne Personenbezug.
Belege:
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\Telemetry\HttpTelemetryUploadClient.cs (Upload-Client) - Begründung: Übermittlung implementiert.
- [SEKUNDÄR] src\webservice\Centron.Host\AspNetCore\HostedServices\ (TelemetryFlushService) - Begründung: periodischer Versand.
- [KONTEXT] src\backend\Centron.BL\Telemetry\ (License-/Telemetrie-Kind-Mapping) - Begründung: Datenkategorien.
Prüfidee: Telemetriedatensatz enthält Installations-GUID/Softwarekennzahlen, keine Kundendaten/Personenbezug (Feldprüfung).
Tracelinks: StRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen mit Datenschutzkonkretisierung (Zielsystem: Opt-in prüfen).
Status: belegt
---
ID: SyRS-25
Titel: Verbindungs-Heartbeat alle 5 Minuten
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Desktop-Client, Web-Service
Vorbedingung: Client angemeldet
Fakt: Client-Heartbeat-Timer alle 5 Minuten (IsValidTicket-Aufruf); bei Fehler wird der Nutzer blockiert mit Hinweis auf Lizenzknappheit (src\centron\Centron.WPF.UI\ConnectionHeartbeatTimer.cs - Start/TimerTick, BlockUserFromUsingCentron); Logout setzt Anmeldedaten zurück, damit keine Geistersitzungen Sitze belegen (src\centron\Centron.WPF.UI\Services\WebServices\CentronWebServiceConnection.cs).
Aussage: Das System soll die Verbindung periodisch prüfen und den Nutzer bei Verbindungsverlust sperren bis zur Wiederanmeldung; Abmeldungen müssen Sitzplätze sofort freigeben.
Ergebnis: Sitzplatzbelegung und Verbindungszustand bleiben konsistent.
Belege:
- [PRIMÄR] src\centron\Centron.WPF.UI\ConnectionHeartbeatTimer.cs - Start (Change(5 min, 5 min)) und TimerTick → BlockUserFromUsingCentron - Begründung: Herzschlag und Sperrverhalten clientseitig durchgesetzt.
- [PRIMÄR] src\centron\Centron.WPF.UI\Services\WebServices\CentronWebServiceConnection.cs - Logout (Zurücksetzen der Anmeldedaten, Kommentar "not use up a license") - Begründung: Sitzplatzfreigabe-Regel implementiert.
- [KONTEXT] src\webservice\Centron.Host\Services\CentronRestService.cs - IsValidTicket (Heartbeat-Endpunkt) - Begründung: serverseitiger Prüfaufruf.
Prüfidee: Netzwerkunterbrechung > 5 Minuten sperrt die Oberfläche; nach Abmeldung ist der Sitzplatz sofort wieder frei.
Tracelinks: StRS-8, SwRS-38
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-26
Titel: Erweiterte Zeitüberschreitungen für Langläufer
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Leistungseffizienz
Akteur: Clients, Web-Service
Vorbedingung: Langlaufende Operationen (Berichte, Importe)
Fakt: http.sys-Idle/RequestQueue-Timeouts und KeepAlive auf 30 Minuten (src\webservice\Centron.Host\CentronHost.cs - options.Timeouts/Limits.KeepAliveTimeout = TimeSpan.FromMinutes(30)); Client-HttpClient mit Timeout.InfiniteTimeSpan (src\webservice\Centron.WebServices.Core\Connections\CentronWebService.cs).
Aussage: Das System soll langlaufende Operationen (Großexporte, Berichte, Importe) durch 30-Minuten-Server-Timeouts und unbegrenzte Client-Timeouts ermöglichen.
Ergebnis: Große Datenmengen werden ohne Abbruch verarbeitet.
Belege:
- [PRIMÄR] src\webservice\Centron.Host\CentronHost.cs (Timeouts 30 Minuten) - Begründung: Serverseiten-Timeouts fix konfiguriert.
- [PRIMÄR] src\webservice\Centron.WebServices.Core\Connections\CentronWebService.cs (Timeout = Timeout.InfiniteTimeSpan, Kommentar >15-Minuten-Methoden) - Begründung: Clientseite bewusst unbegrenzt.
Prüfidee: Ein 20-minütiger Berichtslauf läuft ohne Timeout-Abbruch durch.
Tracelinks: StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - lange Synchrontransaktionen als Altlast; Zielsystem asynchron/quittungsbasiert gestalten.
Status: belegt
---
ID: SyRS-27
Titel: Lokalisierung mit Deutsch als Standard
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Benutzbarkeit
Akteur: Benutzer
Vorbedingung: Client gestartet
Fakt: Sprachauswahl de-DE (Standard) und en-US nur in Dev-Builds (src\centron\Centron.WPF.UI\Modules\Administration\Connections\LoginDialogViewModel.cs - Languages.Add(de-DE); if (IsDevBuild) en-US); Sprachwahl persistiert in Registry (src\centron\Centron.WPF.UI\Localization\LocalizationHelper.cs); Ressourcen LocalizedStrings.resx + LocalizedStrings.en.resx.
Aussage: Das System soll mehrsprachig ausgelegt sein; produktiv wird Deutsch als Standard- und alleinige Oberflächensprache geführt.
Ergebnis: Nutzer arbeiten konsistent auf Deutsch; englische Texte sind vorbereitet.
Belege:
- [PRIMÄR] src\centron\Centron.WPF.UI\Modules\Administration\Connections\LoginDialogViewModel.cs (Sprachliste, Dev-Build-Filter) - Begründung: Sprachverfügbarkeit im Code geregelt.
- [SEKUNDÄR] src\centron\Centron.WPF.UI\Localization\LocalizationHelper.cs (Registry-Schlüssel c-entron\Language) - Begründung: Persistenz der Wahl.
- [KONTEXT] src\centron\Centron.WPF.UI\Resources\LocalizedStrings.en.resx - Begründung: Übersetzungsbasis vorhanden.
Prüfidee: Im Produktionsbuild ist nur de-DE wählbar; Sprachwahl übersteht Neustart.
Tracelinks: StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; Englischrollout im Zielsystem entscheiden.
Status: belegt
---
ID: SyRS-28
Titel: Versionskompatibilität Client/Web-Service
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Kompatibilität
Akteur: Administrator, Clients
Vorbedingung: Update wird eingespielt
Fakt: Anmeldung nur, wenn die ersten drei Versionsstellen von Client und Web-Service übereinstimmen (src\centron\Centron.WPF.UI\Modules\Administration\Connections\LoginDialogViewModel.cs - Kommentar "Only allow login when the first 3 version-numbers match"); Web-Service-Version als Endpunkt (src\webservice\Centron.Controllers\Controllers\WebServiceVersionController).
Aussage: Das System soll Client-/Dienst-Inkompatibilitäten durch Versionsgleichheit auf Major.Minor.Build bei der Anmeldung verhindern.
Ergebnis: Mischbetrieb inkompatibler Versionen wird abgewiesen.
Belege:
- [PRIMÄR] src\centron\Centron.WPF.UI\Modules\Administration\Connections\LoginDialogViewModel.cs - DoLogin (Versionsvergleich mit deutscher Fehlermeldung) - Begründung: Sperre clientseitig durchgesetzt.
- [SEKUNDÄR] src\webservice\Centron.Controllers\Controllers\WebServiceVersionController.cs - Begründung: Version abfragbar.
Prüfidee: Client 14.1.2 meldet sich bei Dienst 14.1.3 abgewiesen, bei 14.1.2 erfolgreich.
Tracelinks: StRS-2, SwRS-37
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; Zielsystem: flexible Kompatibilitätsmatrix statt Striktheit erwägen.
Status: belegt
---
ID: SyRS-29
Titel: Mail-Infrastruktur (SMTP/EWS/Graph, Vorlagen, Scanner)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System, Mailserver
Vorbedingung: Mail-Zugangsdaten konfiguriert
Fakt: Mailversand/Abholung über SMTP, Exchange-EWS und Microsoft Graph; Zugangsdaten (inkl. GraphAppSecret) werden AES-verschlüsselt gespeichert (src\backend\Centron.BL\Mail\MailSettingsBL.cs - _cryptoLogic, EncryptText/DecryptText Zeilen 133/227); eingehende Mails durchlaufen Scanner/Prozessengine (src\backend\Centron.BL\MailScanner\, src\backend\Centron.BL\Processes\).
Aussage: Das System soll E-Mail als Ein- und Ausgangskanal über mehrere Protokolle bedienen, Zugangsdaten verschlüsselt halten und eingehende Mails automatisiert verarbeiten.
Ergebnis: Beleg-/Ticketkommunikation läuft systemgestützt; Geheimnisse liegen verschlüsselt.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Mail\MailSettingsBL.cs - Speichern/Lesen der GraphAppSecret mit AESCryptoLogic.EncryptText/DecryptText - Begründung: Verschlüsselung der Mailgeheimnisse durchgesetzt.
- [SEKUNDÄR] src\backend\Centron.BL\MailScanner\ (Verarbeitungsanbindung) - Begründung: Eingangsverarbeitung real.
- [KONTEXT] src\backend\Centron.BL\Mailings\MailingDataBL.cs (nur Version-2-Mailings laden) - Begründung: Serienmail-Versionierung.
Prüfidee: In den Einstellungen ist kein Graph-Geheimnis im Klartext ablesbar; eingehende Mail mit Betreffregel erzeugt Prozessaufruf.
Tracelinks: StRS-15, StRS-3, SwRS-52, SwRS-74
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; Graph bevorzugen (SMTP-Basic schrittweise ablösen).
Status: belegt
---
ID: SyRS-30
Titel: Berichts- und PDF-Engine mit Ausweichstrategie
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit
Akteur: System, Drucker/PDF-Dienste
Vorbedingung: Reportvorlagen installiert
Fakt: PDF-Ausgabe über austauschbare Strategien (Default, PdfCreator, SevenPdf) mit FastReport-Fallback und 30-minütiger Ausfall-Kühlphase (src\backend\Centron.BL\ReportEngine\PdfStategy\PdfStrategies.cs - "Should a PDF-Strategy fail, we use for the next 30 minutes the fallback strategy."); Reportverwaltung (src\backend\Centron.BL\Reporting\ReportsBL.cs).
Aussage: Das System soll Berichte/PDF über konfigurierbare Strategien erzeugen und bei Strategieausfall automatisch auf eine Fallback-Strategie umschalten.
Ergebnis: Dokumentausgabe bleibt auch bei Störung eines Ausgabewegs verfügbar.
Belege:
- [PRIMÄR] src\backend\Centron.BL\ReportEngine\PdfStategy\PdfStrategies.cs (Strategiewahl + Fallback-Kommentar/Logik) - Begründung: Umschaltverhalten implementiert.
- [SEKUNDÄR] src\backend\Centron.BL\Reporting\ (ReportsBL) - Begründung: Vorlagenverwaltung.
Prüfidee: Ausfall des PDF-Druckers schaltet für 30 Minuten auf SevenPdf/FastReport um; danach Rückversuch.
Tracelinks: StRS-16
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-31
Titel: Outlook-Add-in-Anbindung
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Outlook-Benutzer, Nexus-Host
Vorbedingung: Add-in installiert; Cookie-/Iframe-Politik gesetzt
Fakt: Office.js-Taskpane mit Registerkarten Kunden/Dokumente/Ticket/Belege (src\nexus\CentronNexus.OutlookAddIn\OutlookIndexPage.razor - GetEmailData-Interop), Ticketanlage mit .eml-Ablage ≤ 25 MB (Shared\CreateNewTicket.razor), Manifest für Read/Compose (Manifest\Manifest.xml), SameSite=None/Secure-Cookies im Iframe (Host Program.cs - UseOutlookCookiePolicy).
Aussage: Das System soll in Outlook eingebettet Kunden, Dokumente, Tickets und Belege im Mailkontext bereitstellen und E-Mails als Tickets mit Originalemail abbilden.
Ergebnis: Mailprozesse werden ohne App-Wechsel erledigt.
Belege:
- [PRIMÄR] src\nexus\CentronNexus.OutlookAddIn\Shared\CreateNewTicket.razor (Ticketanlage + exportEmailAsEml mit maxAllowedSize 25 MB) - Begründung: Kernaufgabe implementiert.
- [SEKUNDÄR] src\nexus\CentronNexus.OutlookAddIn\Manifest\Manifest.xml - Begründung: Einbindungspunkte.
- [SEKUNDÄR] src\nexus\CentronNexus.Host\Program.cs (UseOutlookCookiePolicy) - Begründung: Iframe-Cookie-Spezialbehandlung.
Prüfidee: Add-in zeigt Absenderkunden; Ticketanlage speichert .eml; über 25 MB wird abgelehnt.
Tracelinks: StRS-18
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-32
Titel: Build-, Signier- und Installationskette
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: Hersteller/CI, Betreiber
Vorbedingung: Build-Pipeline läuft
Fakt: Azure-Pipelines für Web-Service und Blazor-Portal mit TrustedSigning-Codesignatur (azure\build-templates\build-web-service.yaml - TrustedSigning@0), WiX-MSI-Installer für Client und Web-Service (deployment\centron\CentronSetupProject\Product.wxs - "c-entron.NET", Manufacturer NEXOWARE; WebServiceSetupProject), Docker-Images (docker\), Regressionstest-Pipeline (azure\regression-tests-pipeline.yml).
Aussage: Das System soll reproduzierbar gebaut, Authenticode-signiert, als MSI installiert und als Container lieferbar sein; Tests laufen in Pipelines.
Ergebnis: Lieferqualität ist automatisiert gesichert.
Belege:
- [PRIMÄR] azure\build-templates\build-web-service.yaml - TrustedSigning@0 für Centron.Host.WindowsService.exe/ConnectionManager - Begründung: Signatur automatisiert.
- [SEKUNDÄR] deployment\centron\CentronSetupProject\Product.wxs (Produktdefinition, UpgradeCode, Desktop-Shortcut) - Begründung: Installerumfang.
- [SEKUNDÄR] azure\regression-tests-pipeline.yml - Begründung: Testautomatisierung.
Prüfidee: MSI-Installation erzeugt Program Files-Eintrag und Protokollregistrierung; Signatur der EXE ist nachweisbar.
Tracelinks: StRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-33
Titel: Telefonie-Integration (TAPI, MS Graph Anrufprotokolle)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Mitarbeiter, Telefonanlage/Microsoft Teams
Vorbedingung: TAPI-Linie bzw. Graph-Berechtigungen
Fakt: Anrufjournal mit TAPI und Microsoft-Graph-Call-Records (src\backend\Centron.BL\Tapi\PhoneCallBL.cs - SaveOrUpdateCall mit Endzeit-Sanitierung); Realtime-Hub /Realtime/tapi (src\webservice\Centron.Host\AspNetCore\SignalR\CentronSignalR.cs); TAPI-Bibliothek als Assembly beigelegt (assemblies\tapi\Traysoft.AddTapi.dll).
Aussage: Das System soll Anrufereignisse (ein-/ausgehend, Dauer) protokollieren und in Echtzeit an Clients melden.
Ergebnis: Telefonkommunikation ist im Kundenkontext dokumentiert.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Tapi\PhoneCallBL.cs - SaveOrUpdateCall (Endzeit-Sanitierung) - Begründung: Anrufspeicherung implementiert.
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\SignalR\CentronSignalR.cs - MapHub<TapiClientHub>("/Realtime/tapi") - Begründung: Telefonie-Hub verdrahtet.
- [KONTEXT] assemblies\tapi\README - Begründung: Drittanbieterkomponente.
Prüfidee: Eingehender Anruf erzeugt Journaleintrag mit Richtung/Dauer und Popup am Client.
Tracelinks: StRS-15
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-34
Titel: KI-Modellanbindung
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System, KI-Anbieter
Vorbedingung: Modell-/API-Zugangsdaten konfiguriert
Fakt: KI-Clients für OpenAI-GPT-Familie, Mistral, Google Gemini und Claude mit Kontextfensterauflösung und Modellkatalog (src\backend\Centron.BL\ArtificialIntelligence\ - IAiModelClient, AiModelContextWindowResolver, AiHttpModelCatalogClient mit z. B. "gemini-2.5-pro"/"gemini-2.5-flash"); Zusatzclients TextRating/TicketCategory.
Aussage: Das System soll austauschbare KI-Modelldienste konfigurierbar anbinden und deren Eingabekontexte modellgrenzkonform kürzen.
Ergebnis: KI-Funktionen sind Anbieter-unabhängig nutzbar.
Belege:
- [PRIMÄR] src\backend\Centron.BL\ArtificialIntelligence\AiModelContextWindowResolver.cs (Kontextfenster je Modell) - Begründung: Begrenzungslogik implementiert.
- [SEKUNDÄR] src\backend\Centron.BL\ArtificialIntelligence\AiHttpModelCatalogClient.cs (Fallback-Katalog inkl. "gemini-2.5-pro", "gemini-2.5-flash") - Begründung: Modellkatalog real.
- [KONTEXT] src\webservice\Centron.Host\AspNetCore\WcfBridge\Interception\Interceptors\McpToolUsageTelemetryInterceptor.cs - Begründung: KI-Toolnutzung getelemetriert.
Prüfidee: Wechsel des konfigurierten Anbieters ändert Modellnutzung; überlanges Kontextfenster wird modellkonform gekürzt.
Tracelinks: StRS-19
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-35
Titel: Portaldienste (c-suite-Portal)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Web-Service, c-entron Portal
Vorbedingung: Internetzugang zum Portal
Fakt: Portal-Client mit festen Konstanten (WCF-Schlüssel, URL https://c-suite.c-entron.de/CentronPortalService) für Downloads (Web-Service-Installer) und generische JSON-POSTs (src\backend\Centron.Gateway\Portal\PortalConstants.cs; WebServiceAccess.cs - Execute).
Aussage: Das System soll Herstellerportaldienste (Download von Installerpaketen, Benachrichtigungen) integrieren.
Ergebnis: Installationen aktualisieren sich aus dem Herstellerportal.
Belege:
- [PRIMÄR] src\backend\Centron.Gateway\Portal\WebServiceAccess.cs - Execute (generischer JSON-POST via DataContractJsonSerializer) - Begründung: Portalkommunikation implementiert.
- [KONTEXT] src\backend\Centron.Gateway\Portal\PortalConstants.cs (PORTAL_WCFSERVICE_URL/KEY) - Begründung: fester Portalendpunkt.
Prüfidee: Downloadanfrage liefert Installerpaket; Portal nicht erreichbar → klarer Fehler.
Tracelinks: StRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen.
Status: belegt
---
ID: SyRS-36
Titel: Verhalten nach Lizenzablauf
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Betreiber, Hersteller
Vorbedingung: Lizenz abgelaufen/ungültig
Fakt: Sichtbar ist: Startabbruch bei ungültiger Lizenz (CentronHost.cs), Ausblenden lizenzloser Module (ModuleRegistration.cs), Fehlermeldung bei Sitzplatzüberschreitung. Das Verhalten eines laufenden Systems nach Lizenzablauf (Weiterbetrieb lesend? Sperrung?) wird von der externen Bibliothek Centron.Office.Client bestimmt, die nicht im Quellbestand liegt.
Aussage: [HYPOTHESE] Das System soll nach Lizenzablauf den Betrieb verweigern bzw. auf Lesen beschränken; das genaue Ablaufverhalten (Sperrzeitpunkt, Grace-Period) ist aus der vorliegenden Codebasis nicht belegbar.
Ergebnis: Offen: Wann genau greift die Sperre, welche Restfunktionalität bleibt.
Belege:
- [PRIMÄR] src\webservice\Centron.Host\CentronHost.cs - Start (TryLoadLicense vor DB; CheckLicense.ThrowIfError) - Begründung: belegt nur Startfall, nicht Laufzeitablauf.
- [KONTEXT] Externe Bibliothek Centron.Office.Client (Namespace Licensing.Version3) nicht im Quellbestand - Begründung: die entscheidende Ablauflogik ist nicht einsehbar.
Prüfidee: Test: Systemdatum über Lizenzende setzen und Verhalten von Dienst/Client dokumentieren.
Tracelinks: StRS-8
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Ablaufverhalten im Zielsystem bewusst festlegen.
Status: HYPOTHESE
---
ID: SyRS-37
Titel: Selbstdokumentierende Hilfeseite (HelpPage)
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Integrator/Administrator
Vorbedingung: ActivateHelpPage=true
Fakt: Generierte API-Hilfeseiten unter /Help bzw. /REST/Help nur wenn ActivateHelpPage=true (src\webservice\Centron.Host\HelpPage\CentronHelpPage.cs; Registrierung MapCentronHelpPage in CentronHost.cs), mit Metadaten und Dummy-Instanzen.
Aussage: Das System soll eine abschaltbare, selbst generierte Schnittstellendokumentation bereitstellen.
Ergebnis: Integratoren finden Methoden-/Typdokumentation ohne externe Doku.
Belege:
- [PRIMÄR] src\webservice\Centron.Host\HelpPage\CentronHelpPage.cs (Aktivierung über Konfiguration) - Begründung: Feature-Schalter implementiert.
- [SEKUNDÄR] src\webservice\Centron.Host\HelpPage\DummyInstances (Beispielinhalte) - Begründung: Hilfsinhalte.
Prüfidee: Bei false liefert /Help keinen Inhalt; bei true werden alle WebInvoke-Methoden gelistet.
Tracelinks: StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; produktiv deaktiviert betreiben (Sicherheit).
Status: belegt
---
ID: SyRS-38
Titel: Mobiler Datenbereich
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mobile Client/Einbindung
Vorbedingung: Web-Service erreichbar
Fakt: Schmaler mobiler Datenbereich mit Mitarbeiter-, Kontaktbild- und Kundendatenabfragen (src\backend\Centron.BL\Mobile\MobileBL.cs - GetMobileEmployee/GetContactPersonImage; src\backend\Centron.DAO\Mobile\MobileDAO.cs - MobileCustomer-Kriterienabfragen); kein eigener mobiler API-Controller.
Aussage: Das System soll einen schlanken mobilen Datenzugriff (Mitarbeiter, Kontaktbilder, Kundenauswahl) bereitstellen; die mobile App-Anbindung erfolgt über den Legacy-REST-Dienst.
Ergebnis: Mobile Endgeräte erhalten Basisdaten ohne vollwertige Oberfläche.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Mobile\MobileBL.cs (GetMobileEmployee, GetContactPersonImage base64) - Begründung: mobiler Datendienst implementiert.
- [SEKUNDÄR] src\backend\Centron.DAO\Mobile\MobileDAO.cs - Begründung: Datenzugriffsschicht.
Prüfidee: Mobilabfrage liefert Mitarbeiter-/Kontaktbilddaten; ohne Ticket/Beleg-Funktionsumfang.
Tracelinks: StRS-18
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen; Ausbaufähigkeit im Zielsystem klären.
Status: belegt
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse/Traceability.md
+135
View File
@@ -0,0 +1,135 @@
# Traceability (StRS → SyRS → SwRS → Artefaktbeleg)
Konsolidierte Traceability-Tabelle. Je Zeile ein SyRS- bzw. SwRS-Bezug; "—" bedeutet, dass auf dieser Ebene keine eigene untergeordnete Anforderung geführt wird. Belege als repräsentativer Hauptbeleg (vollständige Beleglisten in den Anforderungsdateien).
## StRS → SyRS
| StRS-ID | SyRS-ID | Artefaktbeleg |
|---|---|---|
| StRS-1 | SyRS-1 | src\nexus\CentronNexus\Shared\Centron\CentronService.cs (GetConnection) |
| StRS-2 | SyRS-12 | src\backend\Centron.BL\Administration\WebServiceConfiguration\WebServiceConfig.cs |
| StRS-3 | SyRS-10 | src\webservice\Centron.Host\CentronHost.cs (AddHostedService-Abschnitt) |
| StRS-4 | SyRS-6 | src\webservice\Centron.Host\AspNetCore\WcfBridge\CentronWcfBridge.cs (/REST, /RESTC) |
| StRS-5 | SyRS-19 | src\backend\Centron.Gateway\Import\EDI\IEDIGatewayImport.cs |
| StRS-6 | SyRS-17 | src\backend\Centron.Gateway\OnlineBanking\OnlineBankingConnectionLibfintx.cs |
| StRS-7 | SyRS-7 | src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs |
| StRS-8 | SyRS-9 | src\webservice\Centron.Host\CentronHost.cs (TryLoadLicense vor DB) |
| StRS-9 | SyRS-14 | src\nexus\CentronNexus.Host\Program.cs (Cookie 12 h, OIDC) |
| StRS-10 | SyRS-14 | src\nexus\CentronNexus\WebOffer\WebReceiptOverview.razor |
| StRS-11 | SyRS-9 | src\backend\Centron.BL\Production\ProductionOrderBL.cs (Lizenzgate) |
| StRS-12 | SyRS-20 | src\apis\Centron.Api.Shipcloud\CentronShipcloudLogic.cs |
| StRS-13 | SyRS-15 | src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs |
| StRS-14 | SyRS-23 | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
| StRS-15 | SyRS-8 | src\webservice\Centron.Host\AspNetCore\SignalR\CentronSignalR.cs |
| StRS-16 | SyRS-30 | src\backend\Centron.BL\ReportEngine\PdfStategy\PdfStrategies.cs |
| StRS-17 | SyRS-7 | src\backend\Centron.BL\Statistics\TicketStatistics\CacheTicketStatisticsBL.cs |
| StRS-18 | SyRS-31 | src\nexus\CentronNexus.OutlookAddIn\Shared\CreateNewTicket.razor |
| StRS-19 | SyRS-34 | src\backend\Centron.BL\ArtificialIntelligence\ (IAiModelClient) |
| StRS-20 | SyRS-7 | src\backend\Centron.BL\EmployeeArea\AppUserBL.cs (Zeile 138) |
| StRS-21 | SyRS-10 | src\backend\Centron.BL\Logistics\LogisticSettings\LogisticSettingsBL.cs |
| StRS-22 | SyRS-9 | src\backend\Centron.BL\Devices\AccountDeviceBL.cs |
## SyRS → SwRS
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|---|---|---|---|
| StRS-7 | SyRS-4 | SwRS-1 | src\backend\Centron.BL\Administration\Logins\Auth\BasicAuthenticator.cs (Zeilen 46-50) |
| StRS-7 | SyRS-4 | SwRS-2 | src\backend\Centron.BL\Administration\Logins\UsersBL.cs (IsValidAppUserPassword) |
| StRS-15 | SyRS-29 | SwRS-3 | src\backend\Centron.BL\Administration\Logins\WebAccountBL.cs (Zeile 529) |
| StRS-7 | SyRS-4 | SwRS-4 | src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs (ValidateAppUser) |
| StRS-7 | SyRS-4 | SwRS-5 | src\backend\Centron.Entities\Entities\Administration\AppUser.cs (KennAendNachTagen) |
| StRS-7 | SyRS-4 | SwRS-6 | src\backend\Centron.Entities\Entities\Administration\AppUser.cs (AuthenticationFailed) |
| StRS-7 | SyRS-7 | SwRS-7 | src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs (Zeile 644) |
| StRS-7 | SyRS-7 | SwRS-8 | src\backend\Centron.BL\Administration\Rights\DefaultRightsStructure.txt |
| StRS-7 | SyRS-7 | SwRS-9 | CentronRights.md + UserRightsConst.cs |
| StRS-1 | SyRS-6 | SwRS-10 | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs (Zeilen 67-90) |
| StRS-4 | SyRS-6 | SwRS-11 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs (Zeile 7265) |
| StRS-2 | SyRS-22 | SwRS-12 | SSMS_DB_SCHEMA.sql (Zeilen 3784/3854/3233) |
| StRS-6 | SyRS-6 | SwRS-13 | src\backend\Centron.BL\Warehousing\TaxBL.cs (Zeilen 207-232) |
| StRS-6 | SyRS-6 | SwRS-14 | src\webservice\Centron.WebServices.Core\Helper\ReceiptPriceHelper.cs (Zeilen 232-251) |
| StRS-6 | SyRS-6 | SwRS-15 | src\backend\Centron.BL\Sales\Receipts\ReceiptItemBL.cs (Zeilen 4089-4098) |
| StRS-6 | SyRS-6 | SwRS-16 | src\backend\Centron.Interfaces\Sales\Receipts\ReceiptState.cs |
| StRS-6 | SyRS-6 | SwRS-17 | src\backend\Centron.BL\Sales\Receipts\Invoices\ReceiptInvoiceBL.cs (Zeilen 154-186) |
| StRS-3 | SyRS-10 | SwRS-18 | src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs |
| StRS-3 | SyRS-10 | SwRS-19 | SSMS_DB_SCHEMA.sql (FaelligAm/Mahnstufe/MahnStop) |
| StRS-6 | SyRS-6 | SwRS-20 | src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskTimerWebServiceBL.cs (Zeilen 327-337, 591-601) |
| StRS-20 | SyRS-7 | SwRS-21 | src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskTimerWebServiceBL.cs (Zeilen 359-377) |
| StRS-7 | SyRS-7 | SwRS-22 | src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs (Zeilen 551/700/894) |
| StRS-7 | SyRS-7 | SwRS-23 | src\backend\Centron.BL\PasswordManagementArea\PasswordManagementKeywordBL.cs |
| StRS-7 | SyRS-7 | SwRS-24 | src\backend\Centron.BL\Security\PdfSigningBL.cs (Zeilen 60-101) |
| StRS-7 | SyRS-5 | SwRS-25 | src\backend\Centron.BL\Administration\Logins\TwoFactor\TwoFactorAuthBL.cs |
| StRS-7 | SyRS-5 | SwRS-26 | src\shared\Centron.Core\GoogleAuthenticator\TwoFactorAuthenticator.cs |
| StRS-7 | SyRS-5 | SwRS-27 | src\backend\Centron.BL\Administration\Logins\TwoFactor\EmailTwoFactorValidator.cs |
| StRS-7 | SyRS-5 | SwRS-28 | src\backend\Centron.BL\Administration\Logins\TwoFactor\RadiusTwoFactorValidator.cs |
| StRS-9 | SyRS-14 | SwRS-29 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs (SearchArticles) |
| StRS-9 | SyRS-14 | SwRS-30 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartReleaseSystemBL.cs (Zeilen 179-193) |
| StRS-10 | SyRS-14 | SwRS-31 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs (ChangeWebReceiptState) |
| StRS-10 | SyRS-14 | SwRS-32 | src\nexus\CentronNexus\DocumentSigning\DocumentSigningPage.razor |
| StRS-11 | SyRS-9 | SwRS-33 | src\nexus\CentronNexus\ProductionOrderManagement\Components\WorkStepTemplateComponent.razor |
| StRS-3 | SyRS-8 | SwRS-34 | src\nexus\CentronNexus\ServiceBoard\ForwardTicket\Components\ForwardTicket.razor |
| StRS-9 | SyRS-14 | SwRS-35 | src\nexus\CentronNexus\Shared\Auth\AuthService.cs |
| StRS-8 | SyRS-9 | SwRS-36 | src\centron\Centron.WPF.UI\Modules\ModuleRegistration.cs |
| StRS-2 | SyRS-28 | SwRS-37 | src\centron\Centron.WPF.UI\Modules\Administration\Connections\LoginDialogViewModel.cs |
| StRS-8 | SyRS-25 | SwRS-38 | src\centron\Centron.WPF.UI\ConnectionHeartbeatTimer.cs |
| StRS-14 | SyRS-23 | SwRS-39 | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs (Zeilen 80/112/138) |
| StRS-2 | SyRS-22 | SwRS-40 | src\backend\Centron.DAO\Mappings\CustomerArea\CustomerBaseMaps.cs |
| StRS-2 | SyRS-23 | SwRS-41 | src\backend\Centron.DAO\NamedQueries\NamedQueryManager.cs |
| StRS-13 | SyRS-15 | SwRS-42 | src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs (Zeilen 1309/1534) |
| StRS-6 | SyRS-18 | SwRS-43 | src\backend\Centron.Gateway\DataExchange\PaymentTransactions\Sepa\SepaFileGeneratorV2.cs |
| StRS-6 | SyRS-17 | SwRS-44 | src\backend\Centron.Gateway\OnlineBanking\OnlineBankingConnectionLibfintx.cs |
| StRS-6 | SyRS-21 | SwRS-45 | src\backend\Centron.Gateway\DataExchange\BookKeeping\BookKeepingFileExport.cs |
| StRS-6 | SyRS-6 | SwRS-46 | src\backend\Centron.BL\Accounts\AccountBL.cs (Zeilen 776-798) |
| StRS-12 | SyRS-20 | SwRS-47 | src\apis\Centron.Api.Gls\CentronGlsLogic.cs (DoValidateShipment) |
| StRS-12 | SyRS-12 | SwRS-48 | src\backend\Centron.Interfaces\Administration\Settings\ApplicationSettingID.cs |
| StRS-6 | SyRS-17 | SwRS-49 | src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingFinApiBL.cs |
| StRS-13 | SyRS-15 | SwRS-50 | src\apis\Centron.Api.EbInterface\EbInterfaceLogic.cs |
| StRS-17 | SyRS-7 | SwRS-51 | src\backend\Centron.BL\Statistics\TicketStatistics\CacheTicketStatisticsBL.cs (Zeilen 28-31) |
| StRS-16 | SyRS-29 | SwRS-52 | src\backend\Centron.BL\TextModuleArea\TextModuleBL.cs |
| StRS-7 | SyRS-5 | SwRS-53 | src\backend\Centron.BL\TwoFactorAuthenticator\TwoFactorAuthenticationBL.cs |
| StRS-12 | SyRS-20 | SwRS-54 | src\backend\Centron.BL\Warehousing\ArticleManagement\ArticleImportBL.cs |
| StRS-20 | SyRS-6 | SwRS-55 | src\backend\Centron.BL\Sales\Calendar\ScheduleBL.cs (Zeilen 98-114) |
| StRS-6 | SyRS-18 | SwRS-56 | src\backend\Centron.BL\Accounting\BankAccountBL.cs |
| StRS-5 | SyRS-6 | SwRS-57 | src\backend\Centron.BL\Purchasing\SupplierOrderPerBranchBL.cs |
| StRS-3 | SyRS-10 | SwRS-58 | src\backend\Centron.BL\Processes\ProcessBL.cs |
| StRS-3 | SyRS-6 | SwRS-59 | src\backend\Centron.BL\TicketProjects\TicketProjectBL.cs |
| StRS-22 | SyRS-6 | SwRS-60 | src\backend\Centron.BL\DocuBoard\AssetManagementADSystemUserExclusionBL.cs |
| StRS-20 | SyRS-6 | SwRS-61 | src\backend\Centron.BL\MyDay\MyDayBL.cs (SaveWorkItemBatch) |
| StRS-16 | SyRS-6 | SwRS-62 | src\backend\Centron.BL\MyCentron\Dashboard\DashboardContainerBL.cs |
| StRS-22 | SyRS-6 | SwRS-63 | src\backend\Centron.BL\ItPlanner\ChecklistVirtualObjectCategoryBL.cs |
| StRS-22 | SyRS-6 | SwRS-64 | src\backend\Centron.BL\Devices\AccountDeviceBL.cs (DeleteAccountDevice) |
| StRS-17 | SyRS-23 | SwRS-65 | src\backend\Centron.BL\ProductMatrix\ |
| StRS-16 | SyRS-6 | SwRS-66 | src\backend\Centron.BL\MassUpdate\MassUpdateBL.cs |
| StRS-12 | SyRS-6 | SwRS-67 | src\backend\Centron.BL\TradePool\TradePoolBL.cs |
| StRS-16 | SyRS-7 | SwRS-68 | src\backend\Centron.BL\VideoPortal\VideoPortalAssignmentBL.cs |
| StRS-20 | SyRS-7 | SwRS-69 | src\backend\Centron.BL\EmployeeArea\AppUserBL.cs (Zeilen 138-140) |
| StRS-3 | SyRS-10 | SwRS-70 | src\backend\Centron.BL\ToDoArea\ToDoBL.cs (FillObjectKindsListe) |
| StRS-3 | SyRS-7 | SwRS-71 | src\backend\Centron.BL\CheckListArea\CentronChecklistBL.cs |
| StRS-16 | SyRS-10 | SwRS-72 | src\backend\Centron.BL\TaskManager\TaskManagementTaskBL.cs |
| StRS-21 | SyRS-10 | SwRS-73 | src\backend\Centron.BL\Logistics\LogisticSettings\LogisticSettingsBL.cs |
| StRS-15 | SyRS-29 | SwRS-74 | src\backend\Centron.BL\Mail\MailSettingsBL.cs (Zeilen 133/227) |
| StRS-22 | SyRS-6 | SwRS-75 | src\backend\Centron.BL\IndexSearch\IndexSearchBL.cs |
| StRS-12 | SyRS-23 | SwRS-76 | src\backend\Centron.BL\VoucherManagement\VoucherManagementBL.cs |
| StRS-18 | SyRS-6 | SwRS-77 | src\backend\Centron.BL\ObjectExternalReferences\ObjectExternalReferenceBL.cs |
| StRS-6 | SyRS-6 | SwRS-78 | src\backend\Centron.BL\CountryArea\CountryBL.cs (UpdateCurrencyRateByCountry) |
| StRS-7 | SyRS-6 | SwRS-79 | src\webservice\Centron.Host\AspNetCore\WcfBridge\Interception\Interceptors\AuthenticateInterceptor.cs |
## SyRS ohne eigenen SwRS-Bezug (untere Ebene entfällt)
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|---|---|---|---|
| StRS-8 | SyRS-2 | — | src\backend\Centron.BL\Administration\Logins\TicketBL.cs (TicketExpireInMinutes) |
| StRS-8 | SyRS-3 | — | src\backend\Centron.BL\Administration\AccessTokens\AccessTokenBL.cs (ValidateToken) |
| StRS-1 | SyRS-11 | — | src\webservice\Centron.Host\CentronHost.cs (UseHttpSys/UseKestrel) |
| StRS-1 | SyRS-13 | — | src\webservice\Centron.Host\CentronHost.cs (UseCors AllowAnyOrigin) |
| StRS-13 | SyRS-16 | — | src\webservice\Centron.Controllers\Controllers\v1\Receipts\ZugferdImportController.cs |
| StRS-1 | SyRS-26 | — | src\webservice\Centron.WebServices.Core\Connections\CentronWebService.cs (InfiniteTimeSpan) |
| StRS-1 | SyRS-27 | — | src\centron\Centron.WPF.UI\Modules\Administration\Connections\LoginDialogViewModel.cs (Sprachliste) |
| StRS-18 | SyRS-31 | — | src\nexus\CentronNexus.OutlookAddIn\Manifest\Manifest.xml |
| StRS-2 | SyRS-32 | — | azure\build-templates\build-web-service.yaml (TrustedSigning) |
| StRS-15 | SyRS-33 | — | src\backend\Centron.BL\Tapi\PhoneCallBL.cs |
| StRS-19 | SyRS-34 | — | src\backend\Centron.BL\ArtificialIntelligence\AiModelContextWindowResolver.cs |
| StRS-2 | SyRS-35 | — | src\backend\Centron.Gateway\Portal\WebServiceAccess.cs |
| StRS-8 | SyRS-36 | — | (HYPOTHESE, Lizenzablauf im Betrieb) Centron.Office.Client nicht im Quellbestand |
| StRS-1 | SyRS-37 | — | src\webservice\Centron.Host\HelpPage\CentronHelpPage.cs |
| StRS-18 | SyRS-38 | — | src\backend\Centron.BL\Mobile\MobileBL.cs |
| StRS-2 | SyRS-24 | — | src\webservice\Centron.Host\AspNetCore\Telemetry\HttpTelemetryUploadClient.cs |
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/OpenCode.log
View File
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/OpenCodeEvents.jsonl
+164
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Protokoll.md
+126
View File
@@ -0,0 +1,126 @@
# Messprotokoll – Iteration 16/z-ai/glm-5.3-flash/builtin/high
> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
## Lauf
- **Prompt-Datei:** `03_Prompt.md`
- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
- **Startzeit:** 2026-09-02T09:56:48.7486096+02:00
- **Endzeit:** 2026-09-02T10:42:42.1186240+02:00
- **Dauer gesamt:** 00:45:50 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
## Werkzeugkonfiguration
- **Skill-Version:** 13.0.0
- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider tensorx` (Adapter-Version 2.5.2)
- **CLI-Version:** OpenCode 1.18.25
- **Modell (angefordert):** `z-ai/glm-5.3-flash`
- **Modell (tatsaechlich):** `z-ai/glm-5.3-flash`
- **Kontrolle Modell:** bestanden
- **Effort:** `high` angefordert, **wirksam** (`effort_applied: true`)
- **Ablage:** `Iteration 16/z-ai/glm-5.3-flash/builtin/high/`
- **Agentenmodus:** `builtin`
- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
- **Sampling-Parameter:** nicht steuerbar
- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
- **Subagenten:** `spawned` = 7, `completed` = 7, `failed` = 0
- **Rollen:** {"explore": 7}
## Validierungsstichprobe
- **Stand:** entfaellt
## Verbrauch
| Messgroesse | Wert |
|---|---|
| Input-Tokens | 3.270.497 |
| Output-Tokens | 97.270 |
| Reasoning-Tokens | 39.969 |
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
| Agent-Turns | 32 |
**Tokens gesamt: 4.316.088.** Kosten `0` – lokaler Betrieb ().
## Gefundene Anforderungen
## 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 | 22 | 15,8 % |
| SyRS | 38 | 27,3 % |
| SwRS | 79 | 56,8 % |
| **Gesamt** | **139** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 54 | 38,8 % |
| Sicherheit | 32 | 23,0 % |
| Daten | 22 | 15,8 % |
| Schnittstelle | 20 | 14,4 % |
| nicht-funktional | 11 | 7,9 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 339 |
| davon `PRIMÄR` | 200 (59,0 %) |
| davon `SEKUNDÄR` | 76 (22,4 %) |
| davon `KONTEXT` | 63 (18,6 %) |
| Belege je Anforderung (Median) | 3 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 133 (95,7 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 132 | 95,0 % |
| workaround | 5 | 3,6 % |
| veraltet | 2 | 1,4 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 134 | 96,4 % |
| als `HYPOTHESE` gekennzeichnet | 5 | 3,6 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 12 | 8,6 % |
| mit ISO-25010-Qualitätsmerkmal | 11 | 7,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** (48 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 139 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 139 von 139 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
- **Session-ID:** `ses_f9ee10b97ffeSh7qClgcgd0uz4`
- **Werkzeugaufrufe:** 76 – {"read": 3, "bash": 12, "task": 7, "grep": 30, "write": 7, "edit": 17}
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 7
- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
- **Root unveraendert:** ja
- **Fehlermeldungen:** []
## Anmerkungen/Auffaelligkeiten
*(von Hand zu ergaenzen)*
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/RawResult.json
+844
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Stderr.log
+5
View File
@@ -0,0 +1,5 @@
[2026-09-02T07:56:50.425489+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\high\03_Lauf_2026-09-02_095648_v13.0.0-77c1\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\high\03_Lauf_2026-09-02_095648_v13.0.0-77c1\Ergebnisse)
[2026-09-02T07:56:50.519897+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=builtin; Effort=high (uebergeben=True); Stall-Timeout=0s
[2026-09-02T08:42:40.702163+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
[2026-09-02T08:42:42.038102+00:00] OpenCode export: Exporting session: ses_f9ee10b97ffeSh7qClgcgd0uz4
[2026-09-02T08:42:42.094727+00:00] Ende: Exitcode=0; Status=success; Turns=32; Tokens=4316088; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\high\03_Lauf_2026-09-02_095648_v13.0.0-77c1\RawResult.json
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/after.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/anforderungen.json
+2843
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/anforderungen.md
+64
View File
@@ -0,0 +1,64 @@
## Gefundene Anforderungen
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
### Verteilung über die Ebenen
| Ebene | Anzahl | Anteil |
|---|---:|---:|
| StRS | 22 | 15,8 % |
| SyRS | 38 | 27,3 % |
| SwRS | 79 | 56,8 % |
| **Gesamt** | **139** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 54 | 38,8 % |
| Sicherheit | 32 | 23,0 % |
| Daten | 22 | 15,8 % |
| Schnittstelle | 20 | 14,4 % |
| nicht-funktional | 11 | 7,9 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 339 |
| davon `PRIMÄR` | 200 (59,0 %) |
| davon `SEKUNDÄR` | 76 (22,4 %) |
| davon `KONTEXT` | 63 (18,6 %) |
| Belege je Anforderung (Median) | 3 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 133 (95,7 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 132 | 95,0 % |
| workaround | 5 | 3,6 % |
| veraltet | 2 | 1,4 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 134 | 96,4 % |
| als `HYPOTHESE` gekennzeichnet | 5 | 3,6 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 12 | 8,6 % |
| mit ISO-25010-Qualitätsmerkmal | 11 | 7,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** (48 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 139 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 139 von 139 mit Tracelinks (100,0 %) |
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/before.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/combined_prompt.md
+175
View File
@@ -0,0 +1,175 @@
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
## Metadaten
- **Versuch:** V1 Baseline (Prompt-only)
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-28
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
| Änderung | Auslösender Befund |
|---|---|
---
## Prompt
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
### Auftrag
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
### Vorgehen (statische Analyse, keine Ausführung)
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
### Pflicht-Eigenschaften jeder Anforderung
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
- **Belegklassifikation:** Kennzeichne jeden Beleg als
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
### Formatvorgabe pro Anforderung
```
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
Titel: <kurzer Titel>
Ebene: <StRS | SyRS | SwRS>
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
Akteur: <Rolle / System / Komponente>
Vorbedingung: <Zustand vor Auslösen>
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
Belege:
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
- [SEKUNDÄR] <...> - Begründung: <...>
- [KONTEXT] <...> - Begründung: <...>
Prüfidee: <Akzeptanzkriterium oder Testidee>
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
Status: <belegt | HYPOTHESE>
```
### Traceability
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
### Nicht-funktionale Anforderungen
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
### Konsolidierungsbedarf
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
```text
Ergebnisse/
StRS.md
SyRS.md
SwRS.md
Traceability.md (oder Traceability.csv)
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
Selbstbewertung, bekannte Lücken)
```
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
Verzeichnissen, das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis sowie
die werkzeugeigenen Subagenten.
Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
Werkzeugserver, Webzugriff.
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
Werkzeuge zu ersetzen.
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\high\03_Lauf_2026-09-02_095648_v13.0.0-77c1\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T10:42:42.1186240+02:00
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/opencode-config.json
+234
View File
@@ -0,0 +1,234 @@
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"tensorx": {
"npm": "@ai-sdk/openai-compatible",
"name": "TensorX",
"options": {
"baseURL": "https://api.tensorx.ai/v1"
},
"models": {
"qwen/qwen3.8-flash-next": {
"name": "Qwen 3.8 Flash Next",
"limit": {
"context": 262144,
"output": 131072
},
"variants": {
"low": {
"thinking": {
"type": "enabled",
"level": "low"
}
},
"medium": {
"thinking": {
"type": "enabled",
"level": "medium"
}
},
"high": {
"thinking": {
"type": "enabled",
"level": "high"
}
},
"xhigh": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
},
"max": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
}
}
},
"z-ai/glm-5.2": {
"name": "GLM 5.2",
"limit": {
"context": 1048576,
"output": 131072
},
"variants": {
"low": {
"thinking": {
"type": "enabled",
"level": "low"
}
},
"medium": {
"thinking": {
"type": "enabled",
"level": "medium"
}
},
"high": {
"thinking": {
"type": "enabled",
"level": "high"
}
},
"xhigh": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
},
"max": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
}
}
},
"z-ai/glm-5.3-flash": {
"name": "GLM 5.3 Flash",
"variants": {
"low": {
"thinking": {
"type": "enabled",
"level": "low"
}
},
"medium": {
"thinking": {
"type": "enabled",
"level": "medium"
}
},
"high": {
"thinking": {
"type": "enabled",
"level": "high"
}
},
"xhigh": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
},
"max": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
}
}
},
"moonshotai/kimi-k3": {
"name": "Kimi K3",
"limit": {
"context": 1048576,
"output": 131072
}
}
}
}
},
"model": "tensorx/z-ai/glm-5.3-flash",
"permission": {
"*": "deny",
"read": "allow",
"glob": "allow",
"grep": "allow",
"list": "allow",
"edit": {
"*": "deny",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/spiegel/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/spiegel/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/spiegel/Ergebnisse/**": "allow"
},
"external_directory": {
"*": "deny",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/spiegel/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/spiegel/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/spiegel/Ergebnisse/**": "allow"
},
"bash": {
"*": "allow",
"rm *": "deny",
"rmdir *": "deny",
"mv *": "deny",
"cp *": "deny",
"dd *": "deny",
"truncate *": "deny",
"chmod *": "deny",
"chown *": "deny",
"ln *": "deny",
"tee *": "deny",
"sed -i*": "deny",
"git checkout*": "deny",
"git restore*": "deny",
"git clean*": "deny",
"git reset*": "deny",
"git add*": "deny",
"git commit*": "deny",
"git push*": "deny",
"git fetch*": "deny",
"git pull*": "deny",
"git remote*": "deny",
"dotnet *": "deny",
"msbuild *": "deny",
"npm install*": "deny",
"nuget *": "deny",
"Remove-Item *": "deny",
"Move-Item *": "deny",
"Copy-Item *": "deny",
"New-Item *": "deny",
"Set-Content *": "deny",
"Add-Content *": "deny",
"Clear-Content *": "deny",
"Out-File *": "deny",
"Set-ItemProperty *": "deny",
"Rename-Item *": "deny"
},
"task": {
"*": "deny",
"general": "allow",
"explore": "allow"
},
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"question": "deny"
},
"agent": {
"build": {
"model": "tensorx/z-ai/glm-5.3-flash",
"mode": "primary"
},
"general": {
"model": "tensorx/z-ai/glm-5.3-flash",
"mode": "subagent"
},
"explore": {
"model": "tensorx/z-ai/glm-5.3-flash",
"mode": "subagent"
}
},
"default_agent": "build"
}
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/opencode-session.json
+4760
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T09:56:48.7486096+02:00
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Adapter.log
+5
View File
@@ -0,0 +1,5 @@
[2026-09-02T07:34:03.171666+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\Ergebnisse)
[2026-09-02T07:34:03.337272+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=solo; Effort=high (uebergeben=True); Stall-Timeout=0s
[2026-09-02T07:56:46.598851+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
[2026-09-02T07:56:48.097160+00:00] OpenCode export: Exporting session: ses_f9ef5eeddffeI5bgXF54VzIYO7
[2026-09-02T07:56:48.149249+00:00] Ende: Exitcode=0; Status=success; Turns=71; Tokens=6336907; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\RawResult.json
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse/Analysebericht.md
+315
View File
@@ -0,0 +1,315 @@
# Analysebericht (c-entron ERP-Suite)
## 1. Laufübersicht
| Angabe | Wert |
|---|---|
| Untersuchungsgegenstand | c-entron ERP-Suite (gesamte Codebasis im Arbeitsverzeichnis, keine Modulbeschränkung) |
| Version laut version.json | 2.0.2611-alpha (.NET 10 SDK, global.json) |
| Teilsysteme | Centron.BL / Centron.DAO / Centron.Entities / Centron.Interfaces (Backend), Centron.WPF.UI (Desktop), Centron.Host + Centron.Controllers (Webservice-API), CentronNexus (Blazor-Portal, WebCart, ServiceBoard, OutlookAddIn), Centron.Gateway (EDI/DATEV/OpenTrans/ZUGFeRD), src\apis (FinAPI, GLS, Shipcloud, Icecat, ITscope, Cop, Egis, ebInterface), Centron.Common/Centron.Core (Querschnitt) |
| DB-Schema | SSMS_DB_SCHEMA.sql (1.558 CREATE-Table-Anweisungen, 76.793 Zeilen) |
| Vorgehen | RRE-Methodenkette: Schritt 0 Modulinventar → 0b Mindestabdeckung → 0c Vertiefung nach Risiko → Artefakterhebung → technische Analyse → semantische Interpretation → Formalisierung → Traceability |
| Ergebnisumfang | 126 Anforderungen (StRS 16, SyRS 55, SwRS 55), 242 Belege (160 PRIMÄR, 75 SEKUNDÄR, 7 KONTEXT), 4 Hypothesen |
| Reihenfolge | Inventar **vor** erster Anforderung erstellt; Mindestabdeckung vor Vertiefung; Vertiefung zuerst in Berechtigungen, Beleg-/Abrechnungslogik, Nummernkreisen, Authentifizierung (ReceiptBL, NumberGroupBL, UserRightsConst, TicketAuthenticationHandler, TwoFactorAuthBL, DunningRunBL, BookKeepingExportBL) |
---
## 2. Modulinventar (Schritt 0)
Legende Abdeckung: `tief` = mehrere Anforderungen, Kernlogik ausgewertet (Klassen-/Methodenlektüre) · `mittel` = Hauptbelege ausgewertet, Randaspekte nicht · `flach` = mindestens ein belegter Befund (Schema, Klasse, Struktur) · `nicht analysiert` = kein belegbarer Befund.
### A. Administration & System
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| A1 | Benutzerverwaltung (AppUser) | src\backend\Centron.BL\Administration\Logins\UsersBL.cs | Interne Benutzerkonten, Passwortprüfung/-änderung, Zuordnung zu Mitarbeitern | tief | SwRS-004 |
| A2 | Web-Accounts (Kundenportal-Login) | src\backend\Centron.BL\Administration\Logins\WebAccountBL.cs | Portalbenutzer je Kunde mit eigener Rechteverwaltung | tief | SyRS-005, SwRS-005 |
| A3 | Rechtemodell (UserRightsConst) | src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs; CentronRights.md | Zentraler Berechtigungskatalog (766 Rechte) inkl. einschränkender Rechte | tief | SyRS-002, SwRS-001 |
| A4 | API-Autorisierung | src\webservice\Centron.Controllers\Authorization\ | Deklarative Rechteprüfung an Endpunkten (401/403) | tief | SyRS-002, SwRS-002 |
| A5 | Authentifizierungsdienste | src\backend\Centron.BL\Administration\Logins\Auth\ | Verfahrensauswahl (Basic, Active Directory, OpenIdConnect, Fallback) | mittel | SyRS-003 |
| A6 | Ticket-/Token-Authentifizierung | src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs | Sitzungstickets/Access-Tokens mit IP-/Methodenbindung | tief | SyRS-001, SwRS-003 |
| A7 | Zwei-Faktor-Authentifizierung | src\backend\Centron.BL\Administration\Logins\TwoFactor\; src\shared\Centron.Core\TotpAuth | 2FA global/je Benutzer mit Gültigkeitsdauer und Validatoren | tief | SyRS-004, SwRS-006 |
| A8 | Lizenzierung | src\backend\Centron.BL\Administration\Licensing\ | Modulfreigaben über Lizenzprodukte (LicenseGuids, FileLicenseCache) | tief | SyRS-006, SwRS-007 |
| A9 | Mandanten- & Filialverwaltung | src\backend\Centron.BL\Administration\Masterdata\; SSMS_DB_SCHEMA.sql (Mandant, Filiale) | Mandanten-/Filialstammdaten und -zuordnungen | mittel | SyRS-007, SwRS-009 |
| A10 | Nummernkreise | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs | Kollisionsfreie Fachnummernvergabe je Mandant/Filiale | tief | SyRS-008, SwRS-008, SwRS-009 |
| A11 | Anwendungseinstellungen (AppSettings) | src\backend\Centron.BL\Administration\Settings\ | Datenbankgestützte Verhaltensschalter für Fachregeln | mittel | SyRS-009, SwRS-010 |
| A12 | SQL-Verwaltung & Skripte | src\backend\Centron.BL\Administration\Scripts\, \SQLManagement | Wartungs-/Reparaturfunktionen als Skriptmethoden | flach | SyRS-010, SwRS-011 |
| A13 | Dateiablagen & Datenschutzordner | src\backend\Centron.BL\Administration\FileManagement\ (inkl. Dsgvo-Provider) | Objektbezogene Dokumentablagen | flach | SyRS-011, SwRS-012 |
| A14 | Änderungsverfolgung | src\backend\Centron.BL\ChangeTracking\; src\backend\Centron.DAO\ChangeTracking | Protokollierung geänderter Objekte | flach | SyRS-012, SwRS-031 |
### B. CRM / Adressstamm
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| B1 | Kundenstamm | SSMS_DB_SCHEMA.sql (Kunden, Anschrif, Personen, Kontakte); src\backend\Centron.BL\WebServices\Sales\CustomerWebServiceBL.cs | Kunden mit Adressen, Ansprechpartnern, Konzernzuordnung | mittel | SyRS-013, SwRS-013 |
| B2 | Lieferantenstamm | SSMS_DB_SCHEMA.sql (Kreditor, LieferantenToFiliale) | Lieferantenstammdaten mit Filialzuordnung | mittel | SyRS-014, SwRS-014 |
| B3 | Kontakte & Anschriften | SSMS_DB_SCHEMA.sql (Kontakte, KontaktePersonen, AnsprechpartnerBeziehung) | Kontaktpersonen und -beziehungen je Partner | flach | SyRS-013, SwRS-013 |
| B4 | Vertriebssteuerung & Klassifizierung | SSMS_DB_SCHEMA.sql (Vertriebssteuerung, Vertriebsgebiete, KundenHerkunft, KundenKlassifizierung) | Vertriebssteuerungs- und Klassifikationsdaten | flach | SyRS-015, SwRS-015 |
| B5 | Sonderpreise & Sondervereinbarungen | src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs; Tabelle Sonderaktionen | Kundenspezifische Preisvereinbarungen als Preisquelle | tief | SyRS-019, SwRS-019 |
### C. Vertrieb
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| C1 | Belegsystem (Kopf/Positionen) | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs; SSMS_DB_SCHEMA.sql (Ang/Auf/Lief/Rech/Gut/Abhol/Vertrag/Anfr-Köpfe) | Einheitliche Belegkette Vertrieb mit belegartenspezifischen Strategien | tief | SyRS-016, SwRS-016, SwRS-017 |
| C2 | Belegversionierung & Sperrung | ReceiptBL.cs:3063-3175; Tabellen *Versions | Versionshistorie und exklusive Bearbeitungssperre | tief | SyRS-017, SyRS-018, SwRS-018 |
| C3 | Preisfindung | src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs | Kaskadierte Preisquellen inkl. Mengen-/Einkaufspreisen und USt | tief | SyRS-019, SwRS-019 |
| C4 | Belegfreigabe / Warenkorb | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs, ReceiptCartReleaseSystemBL.cs | Belegkörbe mit Freigabeverarbeitung | mittel | SyRS-020, SwRS-020 |
| C5 | Provisionen | src\backend\Centron.BL\Sales\Receipts\ReceiptProvisionSchemaBL.cs u. Verwandte | Provisionsberechnung nach Schema/Stufe/Ziel | flach | SyRS-024, SwRS-024 |
| C6 | Vertragsverwaltung | SSMS_DB_SCHEMA.sql (VertragKopf/-Pos, VertragRechKopfZuordnung, VertragsArt) | Verträge, Kontingente, Vertragsrechnungszuordnung | mittel | SyRS-016, SwRS-016 |
| C7 | Mahnwesen | src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningBL.cs, DunningRunBL.cs | Gestuftes Mahnwesen mit Protokollierung | tief | SyRS-021, SwRS-021 |
| C8 | OPOS & Zahlungseingang | src\backend\Centron.BL\Sales\Receipts\Invoices\Opos\OposBL.cs; Tabellen Zahlungseingang/-Log | Zahlungszuordnung und offene Posten | mittel | SyRS-022, SwRS-022 |
| C9 | RMA | src\backend\Centron.BL\CustomerArea\RmaBL.cs, RmaSendKindBL.cs; WPF-Modul Rma | Retourenabwicklung mit Belegerzeugung | flach | SyRS-052, SwRS-052 |
| C10 | Kassenbuch | src\backend\Centron.BL\Sales\CashBooks\ | Kassenbuchführung mit Belegauto-Buchung | tief | SyRS-023, SwRS-023 |
| C11 | Anfragen & Angebotsbewertung | SSMS_DB_SCHEMA.sql (AnfrKopf/-Pos+Versions, AngebotBewertung, AngebotVerloren) | Kundenanfragen und Angebotsverfolgung | flach | SyRS-052, SwRS-052 |
### D. Einkauf
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| D1 | Bestellwesen | SSMS_DB_SCHEMA.sql (BestKopf2/BestPos2); src\backend\Centron.BL\Sales\Receipts\SupplierOrders\SupplierOrderBL.cs | Einkaufsbestellungen inkl. EDI-Übermittlung | mittel | SyRS-025, SwRS-025 |
| D2 | Wareneingang & Lieferantenbelege | src\backend\Centron.BL\Sales\Receipts\SupplierDeliveryLists\, SupplierReceiptDocuments\ (PdfScanning) | Wareneingang, Lieferantenrechnungen, PDF-Extraktion | mittel | SyRS-026, SwRS-026 |
### E. Lager
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| E1 | Artikelstamm | src\backend\Centron.BL\Warehousing\ArticleBL.cs u. a.; Tabellen ARTIK/WAREN/UNTERWAREN | Artikel mit Set-Struktur, Einheiten, Barcodes, Erlöskonten | tief | SyRS-027, SwRS-027 |
| E2 | Produktfamilien | SSMS_DB_SCHEMA.sql (Produktfamilie*); ProductFamilyBL.cs | Artikelgruppen mit Verkaufsperren | flach | SwRS-047 |
| E3 | Bestandsführung | src\backend\Centron.BL\Warehousing\StockManagement\ArticleStockBL.cs; Tabellen Warehouses/Lagerort/Lagerplatz | Bestände je Artikel/Lager, Bedarfe, Einkaufspreise | tief | SyRS-028, SwRS-028 |
| E4 | Seriennummern & Barcode | src\backend\Centron.DAO\Mappings\Warehousing\SerialNumberMaps.cs; Tabellen SeriennummerToPosition, Barcode* | Stückverfolgung über Belege | mittel | SyRS-029, SwRS-029 |
| E5 | Inventur | src\backend\Centron.BL\Warehousing\InventoryManagement\InventoryBL.cs, InventoryNewBL.cs | Zählung und Bestandsabgleich | flach | SyRS-030 |
### F. Fertigung
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| F1 | Produktionsaufträge | src\backend\Centron.BL\Warehousing\ArticleProduction\ArticleProductionBL.cs; Tabellen ArticleProduction* | Lizenzpflichtige Fertigungsaufträge mit Schritten/Material | mittel | SyRS-031 |
### G. Service / Helpdesk
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| G1 | Tickets / Helpdesk | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs, HelpdeskStatusBL.cs u. a.; Tabellen hlpdsk_* | Ticketbearbeitung mit Statuskatalog, Historie, Kategorien | tief | SyRS-032, SwRS-030, SwRS-031 |
| G2 | Ticket-Zeiterfassung & Abrechnung | src\backend\Centron.BL\Sales\Support\HelpdeskTimerBL.cs; ReceiptBL.cs:5295; Tabellen hlpdsk_timer | Zeiteinträge und Belegbildung daraus | tief | SyRS-033, SwRS-032 |
| G3 | Eskalation & Benachrichtigungen | src\backend\Centron.BL\Sales\Support\Escalation\; NexusNotifications | Überfälligkeit und Ereignisbenachrichtigung | flach | SyRS-034, SwRS-033 |
| G4 | Externe Ticketsysteme (DocBee) | src\backend\Centron.BL\DataExchange\Connectors\DocBee* | Ticket-/Zeitabgleich mit externem System | flach | SyRS-044 |
| G5 | Geräte-/Anlagenbindung am Ticket | SSMS_DB_SCHEMA.sql (AccountDevices, AccountDevicesToTickets); HelpdeskAssetBL.cs | Gerät-zu-Ticket-Zuordnung für Service | flach | SyRS-053, SwRS-053 |
### H. Projekte & Organisation
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| H1 | Projektleitung | SSMS_DB_SCHEMA.sql (CRMProjekt, CRMProjektObjekt); CrmProjectWebServiceBL.cs | Projekte mit Objekten und Belegbezug | flach | SyRS-052, SwRS-052 |
| H2 | Aufgaben & Checklisten | src\backend\Centron.BL\TaskManager\, CheckListArea\; Tabelle ToDoListe | ToDos, Aufgaben, Checklisten (auch C-FLOW-Vorlagen) | flach | SyRS-050, SwRS-050 |
| H3 | Kalender & Terminplanung | Tabellen Terminplanung*; src\backend\Centron.BL\MyDay\, AppointmentRequests\ | Termine, Teilnehmer, Terminanfragen/-vorschläge | flach | SyRS-050, SwRS-050 |
| H4 | Mitarbeiterverwaltung | src\backend\Centron.BL\EmployeeArea\; Tabellen Personal, PersonalGruppen, AGLohngruppe | Personalstamm, Gruppen, Lohngruppen | flach | SyRS-051, SwRS-051 |
| H5 | Zeiterfassung & CTime-Connector | src\backend\Centron.BL\Services\CTimeConnectors\; src\backend\Centron.BL\Time\ | Zeiterfassungssynchronisation (inkrementell) | mittel | SyRS-051, SwRS-051 |
### I. Finanzen
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| I1 | Buchhaltungsexport (DATEV) | src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs; src\backend\Centron.Gateway\DataExchange\BookKeeping\ | DATEV-kompatible Exporte mit Revisionsmetadaten | tief | SyRS-035, SwRS-034 |
| I2 | Online-Banking (FinAPI) | src\backend\Centron.BL\Finances\OnlineBanking\; src\apis\Centron.APIs.FinAPI\ | PSD2-Bankanbindung, Umsätze, Zahlungen | tief | SyRS-036, SwRS-035 |
| I3 | Leasing-/Serviceabrechnung | src\backend\Centron.BL\Sales\Receipts\LeasingAndService\ | Wiederkehrende Raten und Logs | mittel | SyRS-037, SwRS-036 |
| I4 | Kostenstellen & Kostenträger | SSMS_DB_SCHEMA.sql (Kostenstellen, Kostentraeger); ReceiptCostCenterAndCostObjectBL.cs | Kostenzuordnung in Belegpositionen | flach | SyRS-016, SwRS-016 |
| I5 | Statistik & Controlling | src\backend\Centron.BL\Statistics\ (u. a. TicketStatistics); Tabelle CacheTicketStatistic | Vorberechnete Auswertungen | flach | SyRS-049, SwRS-049 |
### J. Kommunikation
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| J1 | E-Mail & Textbausteine | src\backend\Centron.BL\Mail\; TextModuleArea\; Tabelle GeschaeftspartnerTextbausteine | Prozess-Mails mit Partner-Vorlagen | mittel | SyRS-055, SwRS-055 |
| J2 | Mail-Scanner (VMA) | src\backend\Centron.BL\MailScanner\MailScannerBL.cs | Automatisierte E-Mail-Verarbeitung mit verschlüsselten Profilen | mittel | SyRS-038, SwRS-037 |
| J3 | Mailings & Telemarketing | src\backend\Centron.BL\Mailings\; Tabelle TelemarketingParticipants | Kampagnen und Telefonmarketing | flach | SyRS-054, SwRS-055 |
| J4 | Chats & Social Media | src\backend\Centron.BL\Chats\, SocialMedia\; Tabellen SocialMedia* | Interne Chats und Social-Media-Interaktionen | flach | SyRS-054, SwRS-055 |
### K. Dokumente & Suche
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| K1 | Dokumentenablage (DocuBoard) | src\backend\Centron.BL\DocuBoard\; Anlage*-Tabellen | Objektbezogene Dokumentablage/Freigaben | flach | SyRS-011, SwRS-012 |
| K2 | Report-Engine | src\backend\Centron.BL\ReportEngine\ (26 Klassen), Reporting | Beleg- und Auswertungsberichte inkl. PDF-Archivierung | mittel | SyRS-016, SyRS-049 |
| K3 | Volltextsuche | src\backend\Centron.BL\IndexSearch\ (TicketFulltextIndex, GermanAnalyzer) | Volltextindizes mit deutscher Sprachanalyse | flach | SyRS-049, SwRS-049 |
### L. Schnittstellen
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| L1 | EDI-Gateway | src\backend\Centron.BL\EDI\; src\backend\Centron.Gateway\EDI_* | Lieferanten-EDI (Alltron, ALSO, EGIS, Komsa, Concerto, Herweck, OpenTrans) | tief | SyRS-039, SwRS-038 |
| L2 | E-Rechnung (ZUGFeRD/XRechnung) | src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs | E-Rechnungsexporte in mehreren Varianten | tief | SyRS-040, SwRS-039 |
| L3 | Versand (GLS/Shipcloud) | src\apis\Centron.Api.Gls\, Centron.Api.Shipcloud\; ShipcloudPackageTemplateBL.cs | Paketlabels über Versanddienste | mittel | SyRS-041, SwRS-040 |
| L4 | Produktinformationsdienste | src\apis\Centron.APIs.IcecatDataAccess\, ITscopeDataAccess\, CopDataAccess\, EgisDataAccess\ | Artikelanreicherung aus Katalogdiensten | mittel | SyRS-046, SwRS-044 |
| L5 | Workflow-Engine | src\backend\Centron.BL\Services\Workflows\ | Konfigurierbare Prozessautomatisierung | flach | SyRS-047, SwRS-045 |
| L6 | Outlook-Integration | src\nexus\CentronNexus.OutlookAddIn\ | Belege/Tickets/Dokumente aus Outlook | mittel | SyRS-048, SwRS-046 |
### M. Web
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| M1 | Nexus-Portal | src\nexus\CentronNexus\ (Blazor, Host) | Kunden-/Mitarbeiter-Webzugang zur Suite | mittel | SyRS-042 |
| M2 | WebCart / Shop | src\nexus\CentronNexus\WebCart\; README.md | Kunden-Shop auf Basis von Sonderpreisen | tief | SyRS-042, SwRS-041 |
| M3 | WebOffer | src\nexus\CentronNexus\WebOffer\ | Angebotsansicht/-freigabe im Portal | flach | SyRS-042 |
| M4 | ServiceBoard | src\nexus\CentronNexus\ServiceBoard\ | Kanban-/Listenansichten für Tickets und CRM | mittel | SyRS-032 |
| M5 | Dokumentensignierung | src\nexus\CentronNexus\DocumentSigning\ | Externe Signierung (Pad/PDF-Upload) | mittel | SyRS-043, SwRS-042 |
| M6 | Webservice-API | src\webservice\Centron.Controllers\, Centron.Host\ | Versionierte REST-API mit Swagger und Tickets | tief | SyRS-044, SwRS-002, SwRS-003 |
### N. Sonstige Module
| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
|---|---|---|---|---|---|
| N1 | Passwort-Manager | src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs | Verschlüsselte Ablage vertraulicher Zugangsdaten | tief | SyRS-045, SwRS-043 |
| N2 | Gutscheinverwaltung | src\backend\Centron.BL\VoucherManagement\VoucherManagementBL.cs | Gutscheinlebenszyklus (frei/ausgegeben/eingelöst) | flach | SyRS-054, SwRS-054 |
| N3 | Qualitätsmanagement (QM) | src\centron\Centron.WPF.UI\Modules\QM\; Tabellen AGPrufvorschrift, APlan* | QM-Einstellungen, Prüfgründe, Arbeitspläne | flach | SyRS-052, SwRS-052 |
| N4 | Asset-Management & Monitoring | Tabellen AssetManagement*; src\backend\Centron.BL\WebServices\RiverSuiteAssetManagment\, ItPlanner | Geräteinventar, SNMP-/Windows-Prüfungen, Netzwerkplanung | flach | SyRS-053, SwRS-053 |
| N5 | Telefonie (CTI) | src\backend\Centron.BL\Tapi\; TapiNumber-Mapping | Anruf-/Nummernzuordnung | flach | SyRS-054, SwRS-055 |
| N6 | Video-Portal & Hilfe | src\backend\Centron.BL\VideoPortal\ | Schulungs-/Hilfevideos | flach | SyRS-042 |
| N7 | Deployment & Installation | docker\, deployment\ (WiX), azure\ (Pipelines) | Container-, Installer- und Pipeline-Betrieb | mittel | SyRS-044, SwRS-048 |
| N8 | Weblinks & Oberflächenanpassungen | src\backend\Centron.BL\WebLinks\, Customizations\, Administration\Themes | URL-Verknüpfungen, Themes, Mandantenanpassungen | flach | SyRS-009 |
**Inventarsumme: 80 Module.** Das Inventar wurde vor der ersten Anforderung erstellt und im Verlauf nur ergänzt, nicht gekürzt.
---
## 3. Abdeckungstabelle (Konsolidiert)
| Abdeckung | Module (Anzahl) | Anteil | Beispiele |
|---|---|---|---|
| tief | 25 | 31,3 % | A1, A2, A3, A4, A6, A7, A8, A10, B5, C1, C2, C3, C7, C10, E1, E3, G1, G2, I1, I2, L1, L2, M2, M6, N1 |
| mittel | 24 | 30,0 % | A5, A9, A11, B1, B2, C4, C6, C8, D1, D2, E4, F1, H5, I3, J1, J2, K2, L3, L4, L6, M1, M4, M5, N7 |
| flach | 31 | 38,7 % | A12, A13, A14, B3, B4, C5, C9, C11, E2, E5, G3, G4, G5, H1, H2, H3, H4, I4, I5, J3, J4, K1, K3, L5, M3, N2, N3, N4, N5, N6, N8 |
| nicht analysiert | 0 | 0,0 % | – |
| **Gesamt** | **80** | **100 %** | – |
**Mindestabdeckung:** Erreicht — jedes der 80 Module hat mindestens eine zugeordnete Anforderung (siehe Spalte "Anforderungen" im Inventar); kein Modul ist als `nicht analysiert` geführt. Der Schwellenwert "> 10 % nicht analysiert = unvollständige Erkundung" ist damit nicht berührt.
---
## 4. Konsistenzcheck über das gesamte Anforderungs-Set
| Prüfpunkt | Ergebnis |
|---|---|
| Doppelte oder mehrfach vergebene IDs | Keine (StRS: 16, SyRS: 55, SwRS: 55; keine Lücken, keine Duplikate — automatisiert geprüft) |
| Anforderungen ohne Beleg | Keine; jede Anforderung führt mindestens einen Beleg mit Begründung |
| Anforderungen ohne `Übernahmewürdigkeit` | Keine (126/126) |
| Tracelinks auf nicht existierende IDs | Keine (alle 126 `Tracelinks`-Felder gegen den ID-Bestand geprüft) |
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung | Keine bekannt; 10 Anforderungen führen Konsolidierungskandidaten (s. u.) |
| Abgleich `Hypothesen.md` ↔ Inline-Markierungen | Übereinstimmend: 4 Anforderungen mit `Status: HYPOTHESE` (SyRS-030, SyRS-031, SyRS-034, SwRS-042) und genau dieselben 4 in `Hypothesen.md`; keine freien Fragen in Hypothesen.md, weitere offene Punkte stehen in Abschnitt 6 |
| Beleggesamtheit | 242 Belege: 160 PRIMÄR, 75 SEKUNDÄR, 7 KONTEXT |
**Konsolidierungskandidaten** (Feld `Konsolidierung`):
| Anforderung | Kandidat |
|---|---|
| SyRS-012, StRS-016 (Change Tracking) | ChangeTracking-Schicht vs. Beleg-Versions-/Logtabellen — zwei Verfolgungsmechanismen |
| SyRS-013, SwRS-013 | Kundenstamm; Kandidat Kunden-/Lieferantenstamm → einheitlicher Partnerstamm (auch SyRS-014/SwRS-014) |
| SyRS-030 | InventoryBL vs. InventoryNewBL — zwei Inventurgenerationen |
| SwRS-016 | Kopf-/Positions-/Versionstabellen je Belegart (9+ Tabellenpaare) → generalisierter Belegkern |
| SwRS-025 | BestKopf2/-Pos2 (Zweite Bestelltabellen-Generation) → in Belegkern integrieren |
| SyRS-041, SwRS-040 | GLS-Adapter vs. Shipcloud-Adapter — einheitliche Versandabstraktion |
| SyRS-052, SwRS-052 | RMA-Belegerzeugung (CreateReceiptFromRma) vs. reguläre Belegkette |
| SyRS-053, SwRS-053 | AssetManagementDevices vs. AccountDevices vs. GeraeteKopf — drei Geräte-/Anlagen-Datenhaltungen |
| StRS-015 | Sammelanforderung: Stammblätter vs. Assets; Kunden-/Kreditor-Stämme; Belegart-Tabellen |
---
## 5. Liste der risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
Belegsituation je Anforderung; "PRIMÄR: ja" bedeutet, dass mindestens ein PRIMÄR-Beleg mit benannter durchsetzender Stelle (Datei/Klasse/Methode/Prüfung) vorliegt.
| ID | Titel | Risikobereich | PRIMÄR | Anmerkung |
|---|---|---|---|---|
| StRS-001 | Geschützter Systemzugang | Sicherheit | ja | TicketAuthenticationHandler, WebAccountBL |
| StRS-002 | Rechtegesteuerte Funktionserbringung | Berechtigungen | ja | UserRightAuthorizationFilter, UserRightsConst |
| StRS-011 | Geheim- und Datenschutz | Sicherheit | ja | AES im Passwort-Manager, VMA-Profilverschlüsselung |
| SyRS-001 | API-Authentifizierung per Ticket/AccessToken | Sicherheit | ja | ValidateTicketOrAccessToken |
| SyRS-002 | Feingranulare Rechteprüfung | Berechtigungen | ja | OnAuthorization (401/403) |
| SyRS-003 | Austauschbare Authentifizierungsverfahren | Sicherheit | ja | ChangeOwnPassword-Sperrregel |
| SyRS-004 | Zwei-Faktor-Authentifizierung | Sicherheit | ja | ValidateTwoFactor/HasToValidateTwoFactor |
| SyRS-005 | Portal-Login (Web-Accounts) | Berechtigungen | ja | LoginWithWebAccount, WebRight 31005 |
| SyRS-006 | Lizenzabhängige Modulfreigabe | Berechtigungen | ja | FinAPI-/Produktions-Lizenzgates |
| SyRS-008 | Zentrale Nummernvergabe | Abrechnung | ja | Optimistische Sperre in GetNextNumber |
| SyRS-017 | Belegsperrung | Abrechnung/Integrität | ja | TryLockReceipt in CreateNewVersion |
| SyRS-019 | Preisfindung | Abrechnung | ja | ReceiptItemPriceBL-Quellenkaskade |
| SyRS-021 | Mahnprozesse | Abrechnung | ja | DunningRunBL-Stufenlogik |
| SyRS-022 | Zahlungseingang/OPOS | Abrechnung | ja (schwach) | PRIMÄR stützt sich auf BL-/Schemaebene; Methodenrumpf von OposBL nicht im Detail ausgewertet — Belegdicke als dünn markiert |
| SyRS-023 | Kassenbuchführung | Abrechnung | ja | CashBookBookingBL-Buchungstechnik |
| SyRS-033 | Ticketzeiterfassung & Belegbildung | Abrechnung | ja | CreateNewReceiptForHelpdekTimers; Zeitrechte |
| SyRS-035 | Buchhaltungsexport | Abrechnung | ja | SaveExportSettings (DefaultExport, Metadaten) |
| SyRS-036 | Online-Banking (FinAPI) | Abrechnung/Sicherheit | ja | Credentials-Gate mit Lizenzprüfung |
| SyRS-038 | Mail-Scanner (VMA) | Sicherheit | ja | Rechteprüfung + Profilverschlüsselung |
| SyRS-040 | E-Rechnung (ZUGFeRD/XRechnung) | Abrechnung | ja | Format-/Varianten-/Leitweg-Regeln |
| SyRS-045 | Passwort-Manager | Sicherheit | ja | AES + Masterkey-Punkte |
| SwRS-001 | Rechtekonstanten-Katalog | Berechtigungen | ja | UserRightsConst |
| SwRS-002 | 401/403-Filter | Berechtigungen | ja | OnAuthorization |
| SwRS-003 | Token-Validierung | Sicherheit | ja | IP-/Methodenbindung |
| SwRS-004 | Passwortregeln | Sicherheit | ja | UsersBL (SHA1, Mindestlänge, externe Auth) |
| SwRS-005 | Web-Account-Regeln | Berechtigungen | ja | Loginfilter, 31005 |
| SwRS-006 | 2FA-Validatoren | Sicherheit | ja | ITwoFactorValidator-Abstraktion |
| SwRS-007 | Lizenzprodukt-Modell | Berechtigungen | ja | LicenseManager-Settings |
| SwRS-008 | Nummernkreis-Algorithmus | Abrechnung | ja | Lückenschluss, optimistische Sperre |
| SwRS-018 | Sperr-/Versionsvalidierungen | Abrechnung/Integrität | ja | Validierungskette in CreateNewVersion |
| SwRS-019 | Preisquellen-Kaskade | Abrechnung | ja | Caches/Quellen in ReceiptItemPriceBL |
| SwRS-021 | Mahnfelder | Abrechnung | ja | Feldzuweisungen DunningRunBL |
| SwRS-022 | Zahlungseingangs-Datenmodell | Abrechnung | ja | Schema (Zahlungseingang/-Log) |
| SwRS-023 | Kassenbuch-Buchungstechnik | Abrechnung | ja | USt-Split, idempotente Neubuchung |
| SwRS-028 | Bestands-/Einkaufspreisfortschreibung | Abrechnung | ja | UpdateArticlePurchasePrice |
| SwRS-032 | Timer→Beleg-Bildung | Abrechnung | ja | CreateNewReceiptForHelpdekTimers + Zeitrechte |
| SwRS-034 | DATEV-Exportkonfiguration | Abrechnung | ja | Metadaten-/Einzigkeitsregel |
| SwRS-035 | FinAPI-Credentials-Gate | Abrechnung/Sicherheit | ja | Lizenzprüfung vor Credentials |
| SwRS-037 | VMA-Profilverschlüsselung | Sicherheit | ja | Encrypt/Decrypt + Rechtecode |
| SwRS-039 | ZUGFeRD-Varianten/Leitweg-ID | Abrechnung | ja | InvoiceZugferdBL |
| SwRS-043 | Passwort-Manager-AES | Sicherheit | ja | AESCryptoLogic-Punkte |
**Verstoßbilanz:** Keine risikorelevante Anforderung trägt den Status `HYPOTHESE`; die risikobasierte Priorisierung ist erfüllt. Einzige Einschränkung: SyRS-022 (PRIMÄR auf BL-/Schemaebene statt geprüfter Methodenlogik) — als dünn belegt vermerkt.
---
## 6. Belegdicke und offene Punkte
**Anforderungen mit Status `HYPOTHESE` (4):** SyRS-030 (Inventur — Abweichungsbuchung unbelegt), SyRS-031 (Produktion — Rückmeldung/Materialverbrauch unbelegt), SyRS-034 (Eskalation — Auslöse-/Zeitgeberlogik unbelegt), SwRS-042 (Signierseite — serverseitige Token-Validierung und Ablageziel unbelegt). Details in `Hypothesen.md`.
**Offene Teilfragen zu Anforderungen mit Status `belegt`** (bewusst nicht in Hypothesen.md, da der belegte Kern trägt):
1. **Passwort-Speicherung** (SwRS-004/SwRS-005): SHA1-Hash ist belegt; die Frage nach einer vorhandenen Passwort-Rücksetzfunktion für Web-Accounts blieb offen.
2. **Masterkey-Verwaltung** (SwRS-043): Quelle (CentronConfigurationDb) ist belegt; Schutz, Rotation und Zugriffskontrolle des Masterkeys sind nicht belegt.
3. **Ticket-/Token-Gültigkeitsdauer** (SwRS-003): Validierung mit IP/Methode ist belegt; Ablaufdauer und Verhalten bei IP-Wechsel (Roaming) sind nicht belegt.
4. **Mehrstufige Freigaben** (SwRS-020): Korb-Freigabesystem ist belegt; ob mehrstufige Freigabeketten (mehrere Rollen) möglich sind, ist nicht belegt.
5. **Preisstichtag** (SwRS-019): Quellenkaskade ist belegt; ob bei Belegfortführung Preise eingefroren oder neu abgeleitet werden, ist nicht belegt.
6. **DATEV-Formatversionen** (SwRS-034): Ascii/XML-Online/2020 sind belegt; die tatsächlich unterstützte DATEV-Version je Kunde ist nicht belegt.
7. **Container-Mandantenmodell** (SwRS-048): Deployment-Komponenten sind belegt; ob ein Container mandantengetrennt oder single-tenant betrieben wird, ist nicht belegt.
8. **Signaturstufe** (SwRS-042): Die rechtliche Stufe (einfach/fortgeschritten/qualifiziert) der Dokumentensignierung ist nicht belegt.
9. **OPOS-Buchungslogik** (SyRS-022/SwRS-022): Schema und BL-Existenz sind belegt; die innere Zuordnungslogik (Teilzahlungen, Skonti) wurde nicht im Detail ausgewertet.
**Dünn belegte Stellen (hoher SEKUNDÄR/KONTEXT-Anteil):** StRS-013 (Deployment: nur SEKUNDÄR — Artefakte sind Konfigurationsdateien, keine durchgesetzte Logik), StRS-015 (Konsolidierung: SEKUNDÄR/KONTEXT — Befund beruht auf Schema-Mustern und Vorgabe), SwRS-048 (Deployment: nur SEKUNDÄR). Diese Anforderungsbereiche sind nicht risikorelevant; für die Vertiefung genügt eine Folge-Iteration mit Lektüre der Setup-/Pipeline-Definitionen.
---
## 7. Selbstbewertung
**1) Wie viele Module wurden tief, mittel, flach bzw. gar nicht analysiert?**
Von 80 Inventarmodulen: 25 tief (31,3 %), 24 mittel (30,0 %), 31 flach (38,7 %), 0 nicht analysiert (0 %). Absolute Zahlen: 25 / 24 / 31 / 0.
**2) Wurde die Mindestabdeckung erreicht?**
Ja. Jedes der 80 Module hat mindestens eine Anforderung (Zuordnung in der Inventartabelle, Spalte "Anforderungen"). Kein Modul ist `nicht analysiert` und damit entfällt auch eine Begründungspflicht dafür.
**3) An welchen Stellen war der Beleg dünn?**
- SyRS-022/SwRS-022 (OPOS/Zahlungseingang): PRIMÄR stützt sich auf BL-/Schemaebene; die Zuordnungslogik im Methodenrumpf wurde nicht geprüft — im Risikoabschnitt als "schwach" markiert.
- Die vier HYPOTHESE-Anforderungen (SyRS-030, SyRS-031, SyRS-034, SwRS-042) beruhen jeweils auf Vorhandenseinsbelegen (BL/Schema/UI), nicht auf gelesener Ausführungslogik.
- Deployment-Bereich (StRS-013, SwRS-048): ausschließlich SEKUNDÄR-Belege (Konfigurations-/Pipeline-Dateien).
- Randmodule J3/J4, N3, N5, N6 (flach): Beleg meist über Schema-/Klassenpräsenz, fachliche Regeln nur teilweise sichtbar.
- Belegverteilung insgesamt: 160 PRIMÄR / 75 SEKUNDÄR / 7 KONTEXT; 7 Anforderungen führen SEKUNDÄR/KONTEXT ohne PRIMÄR (StRS-013, StRS-015, SwRS-048 — alle nicht risikorelevant).
**4) Wurde keine einzige Hypothese geführt?**
Doch — vier Anforderungen sind als HYPOTHESE geführt (SyRS-030, SyRS-031, SyRS-034, SwRS-042); eine Analyse ohne offene Punkte wäre bei 1.558 DB-Tabellen und diesem Codeumfang unplausibel gewesen. Die Hypothesenzahl ist bewusst knapp gehalten: Sie deckt nur Vollaussagen ohne durchsetzenden Beleg ab; sub-Aspekt-Fragen belegter Anforderungen stehen in Abschnitt 6, um den Abgleich Inline ↔ Hypothesen.md eindeutig zu halten.
**5) Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?**
- **ReceiptBL-Monolith:** 11.441 Zeilen generische Beleglogik; eine gezielte Lektüre der Weiterverarbeitungs-/Buchungspfade (Forward, ArticleBooking) würde die Abrechnungsanforderungen (SyRS-016/019, SwRS-018/019) weiter erhärten.
- **OposBL/IncomingPaymentBL:** Methodenrümpfe der Zahlungszuordnung lesen (hebt SyRS-022 von "schwach" auf solide PRIMÄR).
- **EscalationBL und HelpdeskSchedulerBL:** Auslöse-/Zeitgeberlogik lesen (auflöst HYPOTHESE SyRS-034).
- **InventoryNewBL:** Buchungspfad der Abweichungsbuchung lesen (auflöst HYPOTHESE SyRS-030).
- **ArticleProductionBL-Schrittabwicklung:** Rückmeldungsbuchung lesen (auflöst HYPOTHESE SyRS-031).
- **Nexus-Dokumentensignierung:** serverseitige Token-Validierung und Ablageziel der signierten PDFs (auflöst HYPOTHESE SwRS-042).
- **Deployment:** compose.yaml/WiX-Definitionen im Detail auswerten, um das Betriebsmodell (Mandanten je Container?) zu klären.
- **AccessTokens/AccessTokenBL:** Langzeit-Token-Richtlinien (Gültigkeit, Sperrung) für eine schlüssigere Sicherheitsanforderung.
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse/Glossar.md
+85
View File
@@ -0,0 +1,85 @@
# Glossar (c-entron ERP-Suite)
Domänenbegriffe, die in den Anforderungen verwendet werden. Technische Bezeichner bleiben in der Originalsprache.
## Beleg- und Vertriebsbegriffe
| Begriff | Definition |
|---|---|
| **Beleg (Receipt/Asset)** | Oberbegriff für alle Geschäftsdokumente mit Kopf- und Positionsebene: Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag, Anzahlung, Anfrage sowie die Lieferantenvarianten (Bestellung, Lieferschein, Rechnung, Gutschrift). Im Code generisch als `IReceiptBase`/`IReceiptSpecificLogic` abgebildet. |
| **AngKopf/AngPos** | Datenhaltung des Angebots (Kopf/Position). Entsprechend AufKopf (Auftrag), LiefKopf (Lieferschein), RechKopf (Rechnung), GutKopf (Gutschrift), AbholKopf (Abholschein), AnfrKopf (Anfrage), VertragKopf (Vertrag), BestKopf2 (Einkaufsbestellung, Generation 2). |
| **Weiterverarbeitung (Forward)** | Überführung eines Belegs in einen Folgeberleg (z. B. Angebot → Auftrag, Rechnung → Gutschrift). Geregelt über `CanBeForwardedInto()` der Belegstrategie. |
| **Belegversion** | Historisierte Fassung eines Belegs; jede Änderung erzeugt Version n+1, gespeichert in `*Versions`-Tabellen. |
| **Belegsperrung (Lock)** | Exklusive Bearbeitungssperre auf Belegen (`TryLockReceipt`/`UnLockReceipt`). |
| **ReceiptCart (Belegkorb)** | Sammelbehälter für Belegentwürfe inkl. Freigabesystem; Portaleingänge (WebCart) landen hier. |
| **Sondervereinbarung (Special Agreement)** | Kundenspezifische Preisvereinbarung, die in der Preisfindungskaskade Vorrang vor Listen-/Mengenpreisen hat. |
| **Sonderpreise** | Artikel-/Kundenpreise im Adressstamm; Fundament des Portal-Shops (WebCart). |
| **Mahnstufe (DunningLevel)** | Stufe des Mahnwesens je Rechnung (None → Level1 → Level2 → Level3) mit Stufendatum und -bearbeiter. |
| **OPOS (Offene Posten)** | Noch nicht ausgeglichene Forderungen; Verarbeitung über OposBL/OposRunBL. |
| **Kassenbuch (CashBook)** | Kassenbuchführung mit Zeilen je USt-Satz; Belegzahlungen werden automatisch gebucht (InvoiceI3D-Rückverweis). |
| **Provision (ReceiptProvision)** | Verkaufsprovisionsanspruch aus Belegen, geregelt über Schema-, Stufen- und Zieldaten. |
| **Leasing-/Service-Rate** | Wiederkehrende Abrechnungseinheit (LeasingRate/ServiceRate) mit zugehörigem Log. |
## Stammdaten
| Begriff | Definition |
|---|---|
| **Mandant (Mandant)** | Rechtlich eigenständige Organisationseinheit; belegt MandatorI3D in Fachtabellen. |
| **Filiale (Branch/Filiale)** | Standort je Mandant; BranchI3D in Fachtabellen; besitzt eigene Nummernkreise und Erlöskontenzuordnungen. |
| **Kundenstamm (Kunden)** | Kundenstammdaten mit Adressen (Anschrif), Personen, Kontakten und Konzernzuordnung (KundeToKonzern). |
| **Lieferantenstamm (Kreditor)** | Lieferantenstammdaten mit eigener Nummernvergabe und Filialzuordnung. |
| **Artikel (ARTIK/WAREN/UNTERWAREN)** | Artikelstamm mit Einheiten, Zubehör, Unterartikeln, Barcode(s) und Erlöskonten je Branche/Filiale. |
| **Seriennummer (SerialNumber)** | Stückindividuelle Verfolgungseinheit, an Belegpositionen gebunden (SeriennummerToPosition). |
| **Produktfamilie** | Gruppierung von Artikeln mit Verkaufsperren je Kunde/Position. |
| **Nummernkreis (NumberGroup)** | Konfigurierbarer Zähler (RangeFrom/RangeTo, Interval) je Nummernart, Mandant und Filiale. |
| **USt-Satz (MwstSatz)** | Umsatzsteuersatz; Land-/Zeitpunktbezogen in der Preisfindung und Kassenbuch-Aufteilung. |
## Benutzer, Rechte, Betrieb
| Begriff | Definition |
|---|---|
| **AppUser** | Interner Benutzer des Systems (angemeldet über Authenticator-Verfahren). |
| **WebAccount** | Portalbenutzer eines Kunden (Kundenportal/Shop), mit eigenen WebRights; Status=1 bedeutet aktiv. |
| **UserRight** | Berechtigung aus dem zentralen Rechtekatalog (UserRightsConst, numerische IDs); einschränkende Rechte (z. B. "nur eigene Tickets") verengen die Sicht. |
| **Ticket/AccessToken** | Anmeldeweis der API: Sitzungsticket bzw. langfristiger Token, gebunden an Client-IP und API-Methode. |
| **2FA (Two-Factor-Auth)** | Zweistufige Anmeldung mit Validatoren (E-Mail, RADIUS, TOTP) und Gültigkeitsdauer je Benutzer/Anwendung/Gerät. |
| **Lizenz (LicenseGuid)** | Signierte Modulfreigabe (z. B. ProductionManagement, OnlineBanking_FinApi), geprüft über LicenseManager. |
| **AppSettings** | Datenbankgestützte Verhaltensschalter (AppSettingsConst), z. B. Kassenbuch-Filialregel, globale Sondervereinbarungen. |
| **Ablage (FileManagement)** | Objektbezogene Dokumentablage; Pfadbildung über DirectoryReferenceProviders je Objektart. |
## Service, Projekte, Anlagen
| Begriff | Definition |
|---|---|
| **Ticket (Helpdesk/hlpdsk_request)** | Servicetransaktion mit konfigurierbaren Status, Prioritäten, Kategorien, Historie und Zeiteinträgen. |
| **Abschlusszustand (Closed Helpdesk State)** | Definierter Status "Abgeschlossen" im Statuskatalog; Abschluss setzt ClosedAt, Historie und Aktivität. |
| **Timer (hlpdsk_timer)** | Zeiteintrag am Ticket; Grundlage der Serviceabrechnung (Timer → Beleg). |
| **C-FLOW-Ticketvorlage** | Wiederverwendbare Ticketvorlage mit Kategorien (Rechtefamilie im Rechtekatalog). |
| **Projekt (CRMProjekt)** | Projekthaltung mit Objekten (CRMProjektObjekt) und projektspezifischen Belegen/Ansichten. |
| **RMA** | Retourenprozess mit Sendungsart (RmaSendKind) und Belegerzeugung aus Retouren. |
| **Asset/Gerät** | Kundengerät/Anlage in einer von drei parallelen Haltungen (AssetManagementDevices, AccountDevices, GeraeteKopf) - Konsolidierungskandidat. |
| **IT-Planer** | Netzwerk-/Infrastrukturplanung der Kundenumgebung (NetworkStructure, ItPlanner). |
## Schnittstellen und Formate
| Begriff | Definition |
|---|---|
| **EDI (Electronic Data Interchange)** | Elektronischer Datenaustausch mit Lieferanten (Alltron, ALSO/AlsoCH, EGIS, Komsa, Concerto, Herweck) über den EDI-Dispatcher. |
| **OpenTrans 2.1** | XML-Austauschformat für Bestellungen/Warenkörbe im EDI-Adapter Opentrans21. |
| **ZUGFeRD/XRechnung** | Deutsche E-Rechnungsformate; Varianten Comfort und XInvoice, Auslösung über Leitweg-ID. |
| **Leitweg-ID** | Behördliche Empfangsidentifikation für XRechnungen. |
| **DATEV-Export** | Buchhaltungsübergabe (DatevAscii, DatevXmlOnline/2020) mit genau einer Default-Exportkonfiguration. |
| **FinAPI** | PSD2-Bankenschnittstelle (Konten, Umsätze, Zahlungen), lizenzgebunden. |
| **GLS / Shipcloud** | Versanddienst-Adapter für Paketlabels auf Basis von Paketvorlagen. |
| **Icecat / ITscope / Cop / Egis** | Externe Produktinformationsdienste für Artikelanreicherung und Belegsuche. |
| **CTime** | Externe Zeiterfassung, inkrementell synchronisiert (LastTransferDate). |
| **VMA (Virtual Mail Assistant)** | Mail-Scanner-Modul mit Profilen (verschlüsselte Zugangsdaten) und Workflows; Recht ACCESS_VMA_MODULE. |
| **DocBee** | Externes Ticketsystem, angebunden über Connector-BLs. |
## Qualitäts-/Nicht-funktionale Begriffe (ISO 25010)
| Begriff | Definition |
|---|---|
| **Qualitätsmerkmal** | Zuordnung nicht-funktionaler Anforderungen zu ISO/IEC 25010-Merkmalen (u. a. Leistungseffizienz, Übertragbarkeit, Zuverlässigkeit, Rückverfolgbarkeit/Wartbarkeit). |
| **Revisionssicherheit** | Nachvollziehbare, unverfälschbare Dokumentation von Erstellung/Änderung (Metadaten, Versionen, Protokolltabellen). |
| **Optimistische Sperre** | Parallelitätstechnik der Nummernvergabe: bedingtes UPDATE nur bei unverändertem Zählerstand, sonst Wiederholung. |
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse/Hypothesen.md
+59
View File
@@ -0,0 +1,59 @@
# Hypothesen (c-entron ERP-Suite)
Diese Datei enthält genau die Anforderungen, deren `Status`-Feld `HYPOTHESE` trägt. Offene Teilfragen zu Anforderungen mit Status `belegt` sind bewusst **nicht** hier aufgeführt; sie stehen in der Selbstbewertung des `Analysebericht.md` (Abschnitt "Belegdicke und offene Punkte").
---
## SyRS-030 – Inventur
**Aussage (Anforderung):** Das System soll Inventuren je Lager/Materialgruppe führen, Zählergebnisse erfassen und Abweichungen buchen.
**Belegter Kern:** Eigenständige Inventurlogik in zwei Generationen (InventoryBL, InventoryNewBL) sowie Materialgruppenebene sind im Code vorhanden (src\backend\Centron.BL\Warehousing\InventoryManagement\InventoryBL.cs, InventoryNewBL.cs, MaterialGroupBL.cs).
**Hypothesenanteil:** Ob und wie Abweichungsbuchungen (Bestandskorrekturbuchungen aus Zählergebnissen) durchgeführt werden und ob Bestände während der Zählung gesperrt werden, ist aus den gelesenen Artefakten nicht nachweisbar.
**Offene Frage:** Welche Buchungslogik erzeugt die Bestandskorrektur aus der Zähldifferenz, und welche Sperrmechanismen gelten während einer laufenden Inventur?
**Bestätigung fehlt, weil:** Der Inhalt von InventoryNewBL (Buchungspfad, Transaktionsverhalten) nicht vollständig ausgewertet wurde.
---
## SyRS-031 – Produktionsaufträge
**Aussage (Anforderung):** Das System soll Fertigungsaufträge mit Arbeitsschritten und Materialverbrauch verwalten, sobald die Lizenz vorliegt.
**Belegter Kern:** Datenmodell (ArticleProductionOrders, ArticleProductionOrderStepItems, Arbeitsplan-Tabellen), Lizenzsperre mit Fehlermeldung und Materialverwaltung (ArticleProductionMaterial) sind belegt (src\backend\Centron.BL\Warehousing\ArticleProduction\ArticleProductionBL.cs:30-56; SSMS_DB_SCHEMA.sql).
**Hypothesenanteil:** Ob der Abschluss eines Produktionsschritts Materialverbrauch auf den Bestand bucht (Produktionsrückmeldung), ist nicht belegt.
**Offene Frage:** Führt die Schrittrückmeldung zu Bestandsbuchungen der verbrauchten Artikel, und wie wird Fertigwarenbestand gebucht?
**Bestätigung fehlt, weil:** Die Ausführungspfade der Schrittabwicklung (Booking-/Backflush-Logik) nicht ausgewertet wurden.
---
## SyRS-034 – Eskalation und Benachrichtigungen
**Aussage (Anforderung):** Das System soll überfällige/kritische Tickets an definierte Empfängergruppen eskalieren und Ereignisse (z. B. Abschluss) benachrichtigen.
**Belegter Kern:** Eskalationsmodul mit Empfängerklassen (EscalationBL, EscalationReceiversEnum), Benachrichtigungen bei Ticketabschluss (NexusNotificationsBL-Aufruf in HelpdeskCloseBL:149) und Notify-Historientabelle sind belegt.
**Hypothesenanteil:** Die Auslösebedingungen und Zeitgeber der Eskalation (Regelkatalog, Scheduling, Schwellen) sind nicht belegt.
**Offene Frage:** Nach welchen Regeln und in welchen Zeitabständen löst das System Eskalationen aus, und wo ist der Auslöser konfiguriert?
**Bestätigung fehlt, weil:** Der innere Ablauf von EscalationBL (Auslöseprüfung, ggf. Scheduler-Anbindung) nicht ausgewertet wurde.
---
## SwRS-042 – Signierseite (Dokumentensignierung)
**Aussage (Anforderung):** Das System soll externe Signierung über eine Token-Seite mit Signaturpad oder hochgeladener unterschriebener PDF durchführen und den Abschlussstatus anzeigen.
**Belegter Kern:** Signier-/Upload-/Statusinteraktion (Guid-Parameter, Signaturpad, InputFile accept=".pdf", Signierort, "Erfolgreich signiert", Freigabesperre) ist in DocumentSigningPage.razor belegt.
**Hypothesenanteil:** Wohin das signierte Dokument abgelegt und wie der Token (Guid) serverseitig validiert wird, ist aus der UI-Seite allein nicht nachweisbar.
**Offene Frage:** Welche serverseitige Prüfung schützt den Signiervorgang (Token-Gültigkeit, einmalige Nutzung), und in welche Objektablage wird das signierte PDF geschrieben?
**Bestätigung fehlt, weil:** Die Aufruf-/Ablage-Endpunkte hinter der Razor-Seite nicht ausgewertet wurden.
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse/StRS.md
+320
View File
@@ -0,0 +1,320 @@
# StRS – Stakeholder Requirements Specification (c-entron ERP-Suite)
Reverse Requirements Engineering der c-entron ERP-Suite (c-entron.NET WPF-Client, c-entron Webservice-API, c-entron Nexus Web-Portal, Centron.BL/DAO/Entities, Centron.Gateway, externe API-Adapter). Grundlage: statische Analyse der Artefakte im Arbeitsverzeichnis (Quellcode, DB-Schema `SSMS_DB_SCHEMA.sql`, Konfiguration, UI-Ressourcen, Deployment-Skripte). Version der Codebasis laut `version.json`: 2.0.2611-alpha.
Stakeholder (aus Artefakten abgeleitet): Geschäftsführung/Controlling, Vertrieb, Einkauf, Lager/Logistik, Service/Helpdesk, Finanzbuchhaltung, Systemadministration, Mitarbeiter (interne Benutzer), Kunden (Portal-/Web-Accounts), Lieferanten (EDI-Partner), Steuer-/Buchhaltungsaußenstellen (DATEV/E-Rechnung), Softwarebetrieb/Hosting.
---
ID: StRS-001
Titel: Geschützter Systemzugang für alle Benutzer
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Interne Benutzer, Portal-Kunden, Systemadministration
Vorbedingung: Benutzerkonto existiert (AppUser oder WebAccount); System ist erreichbar.
Fakt: Alle Zugangswege (Webservice-API, WPF-Client, Nexus-Portal) führen Anmeldevorgänge durch: die API validiert Tickets/Access-Tokens mit Client-IP und aufgerufener Methode (src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs), der Client authentifiziert über eine Authenticator-Fabrik mit Basic-/AD-/OpenIdConnect-Verfahren (src\backend\Centron.BL\Administration\Logins\Auth\AuthenticatorFactory.cs), Portal-Kunden melden sich über WebAccounts an (src\backend\Centron.BL\Administration\Logins\WebAccountBL.cs, LoginWithWebAccount).
Aussage: Das System soll jedem Benutzer nur nach erfolgreicher, individualisierbarer Anmeldung Zugriff auf Geschäftsdaten gewähren und alle Anmeldeverfahren (lokal, Active Directory/Entra, OpenIdConnect, Portal-Konto) über einen gemeinsamen Mechanismus abwickeln.
Ergebnis: Nicht angemeldete Zugriffe werden abgewiesen; jede Sitzung ist einem Benutzerkonto zuordenbar.
Belege:
- [PRIMÄR] TicketAuthenticationHandler.HandleAuthenticateAsync / ValidateTicketOrAccessToken (src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs:44-95) - Begründung: durchgesetzte Authentifizierungspflicht vor jedem API-Aufruf; ohne Ticket schlägt die Authentifizierung fehl.
- [PRIMÄR] WebAccountBL.LoginWithWebAccount (src\backend\Centron.BL\Administration\Logins\WebAccountBL.cs:54-61) - Begründung: durchgesetzte Passwortprüfung und Statusbedingung (Status == 1) für Portal-Logins.
- [SEKUNDÄR] AuthenticatorFactory (src\backend\Centron.BL\Administration\Logins\Auth\AuthenticatorFactory.cs) - Begründung: Auswahlmechanismus der Anmeldeverfahren, stützt die gemeinsame Abwicklung.
Prüfidee: API-Aufruf ohne gültiges Ticket wird abgelehnt; Login mit gesperrtem WebAccount (Status ≠ 1) scheitert; jede erfolgreiche Anmeldung erzeugt einen dem Benutzer zuordenbaren Ticket-Datensatz.
Tracelinks: SyRS-001, SyRS-003, SyRS-004, SyRS-005
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - individualisierbarer Login ist Grundvoraussetzung für Prüfpflicht und Mandantentrennung.
Status: belegt
ID: StRS-002
Titel: Rechtegesteuerte Funktionserbringung
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Systemadministration, alle internen Benutzer
Vorbedingung: Benutzer ist angemeldet; Rechtekatalog ist gepflegt.
Fakt: Der Code zentralisiert über 760 benannte Rechtekonstanten (src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs, "NEXT ID: 20800174"), dokumentiert Rechte inkl. einschränkender Rechte je Funktion in CentronRights.md und erzwingt Rechteprüfung deklarativ an API-Endpunkten (src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs mit 401/403-Semantik).
Aussage: Das System soll Geschäftsfunktionen nur an Benutzer mit der jeweils zuständigen Berechtigung erbringen; Berechtigungen sind administrativ je Benutzer zuordbar und wirken auf Menü, Aktion und Datenzugriff.
Ergebnis: Funktionen ohne Berechtigung sind unsichtbar bzw. werden serverseitig verweigert (403).
Belege:
- [PRIMÄR] UserRightAuthorizationFilter.OnAuthorization (src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs:38-56) - Begründung: durchgesetzte Rechteprüfung vor Ausführung der Endpunkt-Logik mit 401/403.
- [PRIMÄR] UserRightsConst (src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs, 766 Konstanten) - Begründung: durchgesetztes, zentrales Berechtigungsvokabular im Code.
- [KONTEXT] CentronRights.md (Abschnitt Helpdesk/Kalender) - Begründung: dokumentierte Fachsemantik der Rechte, z. B. einschränkende Rechte "nur eigene Tickets".
Prüfidee: Ein Benutzer ohne Recht X erhält auf einen mit Recht X geschützten Endpunkt 403; Menüpunkte ohne Recht sind ausgeblendet (Sichtbarkeitssteuerung).
Tracelinks: SyRS-002, SwRS-001, SwRS-002
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Berechtigungsmodell ist fachlich weiter erforderlich; Ablösung veralteter Rechte-IDs sinnvoll.
Status: belegt
ID: StRS-003
Titel: Mandanten- und Filialfähigkeit
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mandatsverwaltung, Filialleitung
Vorbedingung: Mandanten- und Filialstammdaten sind angelegt.
Fakt: Datenmodell enthält Tabellen Mandant und Filiale (SSMS_DB_SCHEMA.sql); Belege, Benutzer und Nummernkreise tragen MandatorI3D/BranchI3D (z. B. NumberGroupBL.CreateNumberGroups(int mandantI3D, int? branchI3D)); Nummernkreise werden je Mandant und je Filiale angelegt (RefreshAllNumberGroups).
Aussage: Das System soll mehrere rechtlich eigenständige Mandanten sowie mehrere Filialen je Mandant mit getrennten Stammdaten, Belegnummern und Zuordnungen verwalten.
Ergebnis: Daten je Mandant/Filiale sind getrennt auswertbar; Nummernkreise kollidieren nicht über Filialgrenzen hinweg.
Belege:
- [PRIMÄR] NumberGroupBL.RefreshAllNumberGroups / CreateNumberGroups (src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:136-152) - Begründung: durchgesetzte Anlage von Nummernkreisen je Mandant und Filiale.
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql: CREATE TABLE [dbo].[Mandant], [dbo].[Filiale], [dbo].[WarenFilialeErloeskonto] - Begründung: Datenmodell trägt Mandanten-/Filialdimension bis auf Erlöskonten.
Prüfidee: Zwei Filialen desselben Mandanten vergeben dieselbe Belegnummer aus separaten Nummernkreisen ohne Kollision; Mandant A sieht keine Belege von Mandant B.
Tracelinks: SyRS-007, SyRS-008, SwRS-008, SwRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Multi-Mandantenfähigkeit ist Kernanforderung für SaaS-Betrieb.
Status: belegt
ID: StRS-004
Titel: Beleggestützter Vertriebsprozess von Angebot bis Rechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Innendienst
Vorbedingung: Kundenstammsatz existiert; Benutzer hat Belegrechte.
Fakt: Der Code implementiert ein einheitliches Belegsystem für Angebote, Aufträge, Lieferscheine, Abholscheine, Rechnungen, Gutschriften und Verträge über generische Receipt-BLs mit Belegart-spezifischen Strategien (src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs, SpecificLogics.cs); Belegkopf-/Positions- und Versionstabellen existieren je Belegart (AngKopf/-Versions, AufKopf/-Versions, LiefKopf/-Versions, RechKopf/-Versions, GutKopf/-Versions, AbholKopf/-Versions).
Aussage: Das System soll den Vertriebsprozess als Kette einheitlich strukturierter Belege (Angebot → Auftrag → Lieferschein → Rechnung, inkl. Gutschrift/Abholung) abbilden, mit Weiterverarbeitung (Forward) zwischen Belegarten, Versionierung und Sperrung gegen parallele Bearbeitung.
Ergebnis: Jede Vertriebsentscheidung ist als versionierter, gesperrter Beleg dokumentiert und nachvollziehbar fortgeschrieben.
Belege:
- [PRIMÄR] ReceiptBL.CreateNewVersion / CreateLock / RemoveLock (src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:3063-3175) - Begründung: durchgesetzte Versions- und Sperrlogik auf Belegen.
- [PRIMÄR] SSMS_DB_SCHEMA.sql: RechKopfVersions, AufPosVersions u. a. Versions- und Kopf-/Positionstabellen je Belegart - Begründung: Persistenz der Belegkette inkl. Versionen.
- [SEKUNDÄR] InvoiceSpecificLogic.CanBeForwardedInto => CreditVoucherClass (src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:280) - Begründung: regelt zulässige Belegübergänge (Rechnung → Gutschrift).
Prüfidee: Aus einem Angebot wird per Weiterverarbeitung ein Auftrag erzeugt; gleichzeitig geöffnete Bearbeitung durch zwei Benutzer erzeugt eine Sperrmeldung; jede Änderung erzeugt Version n+1.
Tracelinks: SyRS-016, SyRS-017, SyRS-018, SyRS-020, SwRS-016, SwRS-017, SwRS-018
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Belegkette ist Kernfachlichkeit; Implementierungsdetails (623-KB-Monolith ReceiptBL.cs) sind im Zielsystem zu zergliedern.
Status: belegt
ID: StRS-005
Titel: Verbindliche Preisfindung aus Stammdaten und Vereinbarungen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Controlling
Vorbedingung: Artikel, Kundensonderpreise/Sondervereinbarungen und USt-Sätze sind gepflegt.
Fakt: Die Preisfindung speist sich aus Sondervereinbarungen, Mengenpreisen, Einkaufspreisen je Lager und Ländereinstellungen und wird zentral in ReceiptItemPriceBL berechnet; Schalter wie OrderHasGlobalSpecialAgreement/OfferHasGlobalSpecialAgreement steuern die Geltung (src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs:29-79).
Aussage: Das System soll Belegpositionen verbindlich aus gepflegten Preisquellen (Sondervereinbarungen, Sonderpreise, Mengenpreise, Artikel-/Einkaufspreise) und gültigen USt-Sätzen ableiten, damit angebotene und fakturierte Preise übereinstimmen.
Ergebnis: Belegpreise sind deterministisch aus Stammdaten hergeleitet und nachvollziehbar.
Belege:
- [PRIMÄR] ReceiptItemPriceBL (src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs, Konstruktor & Caches für SpecialAgreement/ArticleVolumePrices/ArticlePurchasePriceInWarehouse) - Begründung: zentrale, durchgesetzte Preisberechnungsstelle.
- [SEKUNDÄR] Tabellen Sonderaktionen, Zahkond, MwstSatz (SSMS_DB_SCHEMA.sql) - Begründung: Preis- und Steuergrundlagen im Datenmodell.
Prüfidee: Für einen Kunden mit Sondervereinbarung wird der vereinbarte Preis – nicht der Listenpreis – in Angebot, Auftrag und Rechnung angesetzt; ohne Vereinbarung gilt der Artikel-/Listenpreis.
Tracelinks: SyRS-019, SwRS-019
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Preisfindung ist abrechnungskritisch; Quellkaskade im Zielsystem explizit dokumentieren.
Status: belegt
ID: StRS-006
Titel: Forderungsmanagement mit gestuftem Mahnwesen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Finanzbuchhaltung, Debitorenbuchhaltung
Vorbedingung: Offene Rechnungen (OPOS) existieren; Mahnkonfiguration ist gepflegt.
Fakt: Rechnungen tragen Mahnstufen-Felder (DunningLevel, DunningLevel1/2/3Date, DunningLevel1/2/3Employee); der Mahnlauf setzt Stufen 1→2→3 mit Datum und Bearbeiter und kann Stufen zurücknehmen (src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs:253-268, 519-539).
Aussage: Das System soll offene Forderungen in bis zu drei Mahnstufen verfolgen, jede Mahnung mit Datum und Bearbeiter protokollieren und Stufenrücknahmen unterstützen.
Ergebnis: Mahnhistorie je Rechnung ist nachvollziehbar; Inkasso-Übergabe basiert auf Stufe 3.
Belege:
- [PRIMÄR] DunningRunBL (src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs:253-268, 519-539) - Begründung: durchgesetzte Stufenlogik inkl. Zuordnung von Datum und Employee.
- [SEKUNDÄR] Tabelle Mahnlauf (SSMS_DB_SCHEMA.sql) - Begründung: Persistenz der Mahnläufe.
Prüfidee: Mahnlauf erhöht Stufe je Rechnung um genau eine Stufe und setzt Stufendatum/Bearbeiter; Rücknahme setzt Felder zurück und protokolliert die Übergänge.
Tracelinks: SyRS-021, SyRS-022, SwRS-021, SwRS-022
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Forderungsmanagement ist abrechnungskritisch.
Status: belegt
ID: StRS-007
Titel: Beschaffung und Lagerhaltung mit Verfügbarkeitsnachweis
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Einkauf, Lager, Vertrieb
Vorbedingung: Artikelstamm und Lagerorte sind angelegt.
Fakt: Datenmodell enthält Bestellkopf/-positionen (BestKopf2/BestPos2), Wareneingangsbelege (WareKopf/WarePos), Lagerorte/-plätze (Warehouses, Lagerort, Lagerplatz) und Bestandsabfragen mit Bedarfsermittlung (ArticleStockBL.GetArticleStockDemands, src\backend\Centron.BL\Warehousing\StockManagement\ArticleStockBL.cs:42-44); Bestandsbuchungen wirken auf Barcode/Seriennummern (ArticleStockBL.IncreaseArticleStock, Kommentar zu ScanBarcodes).
Aussage: Das System soll Beschaffung (Bestellung → Wareneingang) und Lagerhaltung (Bestände je Artikel und Lagerort, Seriennummern, Inventur) so führen, dass Vertrieb und Service jederzeit die Verfügbarkeit und Herkunft von Material nachweisen können.
Ergebnis: Bestände, Bedarfe und Seriennummern sind je Lagerort nachweisbar.
Belege:
- [PRIMÄR] ArticleStockBL.UpdateArticleStock / IncreaseArticleStock (src\backend\Centron.BL\Warehousing\StockManagement\ArticleStockBL.cs:47-61) - Begründung: durchgesetzte Bestandsfortschreibung.
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql: BestKopf2, BestPos2, WareKopf, WarePos, Warehouses, Lagerort, Lagerplatz - Begründung: Beschaffungs- und Lagerdatenmodell.
Prüfidee: Wareneingang auf Bestellung erhöht Bestand am gewählten Lagerort; Auslieferung per Lieferschein vermindert ihn; Seriennummernbuchung wirkt nur bei aktivem ScanBarcodes auf den Bestand.
Tracelinks: SyRS-025, SyRS-026, SyRS-027, SyRS-028, SyRS-029, SyRS-030, SwRS-025, SwRS-026, SwRS-027, SwRS-028, SwRS-029
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Lager- und Beschaffungslogik ist fachlich weiter erforderlich.
Status: belegt
ID: StRS-008
Titel: Servicedienstleistungen mit Zeitaufwand und Abrechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Service/Helpdesk, Vertrieb, Kunde
Vorbedingung: Ticket existiert; Mitarbeiter-/Artikelstämme sind gepflegt.
Fakt: Tickets haben konfigurierbare Status mit festem "Abgeschlossen"-Zustand, Pflichtfeldprüfung und Historie beim Abschluss (HelpdeskStatusBL, HelpdeskCloseBL:120-151); Zeiterfassung (hlpdsk_timer) ist an Tickets gebunden und wird zu Belegen mit Positionen verdichtet (ReceiptBL.CreateNewReceiptForHelpdekTimers, ReceiptBL.cs:5295).
Aussage: Das System soll Serviceaufträge als Tickets mit Statusworkflow, Zeiterfassung und Abrechnung (Timer → Beleg) führen, damit erbrachte Leistungen nachvollzehbar dokumentiert und fakturiert werden.
Ergebnis: Aus Tickets und Zeiteinträgen entstehen prüffähige Belege; Ticketverlauf und -zeiten sind historisiert.
Belege:
- [PRIMÄR] HelpdeskCloseBL.CloseHelpdesk (src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:120-151) - Begründung: durchgesetzte Abschlusslogik mit Pflichtfeldprüfung, ClosedAt, Historie und Benachrichtigung.
- [PRIMÄR] ReceiptBL.CreateNewReceiptForHelpdekTimers (src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:5295) - Begründung: durchgesetzte Belegbildung aus Zeiteinträgen.
- [SEKUNDÄR] Tabellen hlpdsk_requests, hlpdsk_status, hlpdsk_timer, hlpdsk_history (SSMS_DB_SCHEMA.sql) - Begründung: Ticket-, Status-, Zeit- und Historiendatenhaltung.
Prüfidee: Ticketabschluss ohne Pflichtfeldinhalte wird verweigert; aus zwei Zeiteinträgen entsteht ein Beleg mit zwei Positionen und den gebuchten Artikeln.
Tracelinks: SyRS-032, SyRS-033, SyRS-034, SyRS-053, SwRS-030, SwRS-031, SwRS-032
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Serviceprozess mit Zeitabrechnung ist Kernfachlichkeit.
Status: belegt
ID: StRS-009
Titel: Revisionssichere Finanzdokumentation und Buchhaltungsübergabe
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Finanzbuchhaltung, Steuerberater/Wirtschaftsprüfung
Vorbedingung: Belege sind gebucht; Exportkonfiguration existiert.
Fakt: Buchhaltungsexporte (DATEV Ascii/XML-Online) sind als Konfigurationsobjekte mit Erstell-/Änderungs-Metadaten (CreatedDate, CreatedVersion, CreatedBy, ChangedDate, ChangedBy) und genau einer DefaultExport-Konfiguration persistiert (src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs:91-125); Belegversionen bleiben als eigene Versionstabellen erhalten.
Aussage: Das System soll Finanzdaten revisionssicher dokumentieren und in standardisierten Formaten (u. a. DATEV) an die Finanzbuchhaltung übergeben, inkl. nachvollziehbarer Erstell-/Änderungsangaben je Exportkonfiguration.
Ergebnis: Exporte sind rekonstruierbar; genau eine Exportkonfiguration ist als Standard aktiv.
Belege:
- [PRIMÄR] BookKeepingExportBL.SaveExportSettings (src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs:91-125) - Begründung: durchgesetzte Metadatenpflege und DefaultExport-Eindeutigkeit.
- [SEKUNDÄR] Centron.Gateway\DataExchange\BookKeeping (DatevAscii, DatevXmlOnline, DatevXMLOnline2020) - Begründung: Formatimplementierungen für den Übergabestandard.
Prüfidee: Nach Anlage einer neuen DefaultExport-Konfiguration ist genau eine Konfiguration als Standard markiert; jede Änderung trägt geänderten Benutzer/Version.
Tracelinks: SyRS-035, SyRS-018, SwRS-034
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Buchhaltungsübergabe ist gesetzlich motiviert.
Status: belegt
ID: StRS-010
Titel: Elektronischer Geschäftsverkehr mit Lieferanten, Kunden und Behörden
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Einkauf, Vertrieb, Lieferanten (EDI), Kunden (Portal), Empfänger von E-Rechnungen
Vorbedingung: Partnerkonfigurationen (EDI/Portal/FinAPI) sind eingerichtet.
Fakt: Ein EDI-Dispatcher verteilt Bestell-/Warenkorbprozesse auf Lieferantenprotokolle (Alltron, ALSO/AlsoCH, EGIS, Komsa, OpenTrans 2.1) (src\backend\Centron.BL\EDI\EDIDispatcherBL.cs, EDI\SupplierEDI\SupplierEdiBL.*); Rechnungen werden als ZUGFeRD/XRechnung exportiert (InvoiceZugferdBL, inkl. Leitweg-ID und Comfort/XInvoice-Varianten); Kunden bestellen über ein Web-Shop-Modul (src\nexus\CentronNexus\WebCart) auf Basis ihrer Sonderpreise (README.md, Abschnitt WebCart).
Aussage: Das System soll Geschäftsdaten elektronisch mit Lieferanten (Bestellungen/Lieferscheine), Kunden (Portal/Shop, Angebotsfreigabe, Signierung) und E-Rechnungsempfängern austauschen.
Ergebnis: Bestellungen, Bestätigungen, E-Rechnungen und Portaltransaktionen laufen ohne manuelle Datenübernahme.
Belege:
- [PRIMÄR] EDIDispatcherBL und SupplierEdiBL je Partner (src\backend\Centron.BL\EDI\EDIDispatcherBL.cs; src\backend\Centron.BL\EDI\SupplierEDI\SupplierEdiBL.Alltron.cs u. a.) - Begründung: durchgesetzte Partnerzuordnung und Protokollverarbeitung.
- [PRIMÄR] InvoiceZugferdBL.GenerateZugferdFile (src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs:124-155) - Begründung: durchgesetzte E-Rechnungserzeugung inkl. Leitweg-ID.
- [SEKUNDÄR] README.md (WebCart-Abschnitt) - Begründung: beschreibt Fachregel "Artikel kommen aus den Sonderpreisen des Kunden".
Prüfidee: Eingelesene OpenTrans-Bestellung erzeugt einen Bestellbeleg; exportierte ZUGFeRD-Datei enthält Leitweg-ID und ist schema-valid; Portal-Bestellung landet als Belegentwurf im System.
Tracelinks: SyRS-039, SyRS-040, SyRS-041, SyRS-042, SyRS-044, SyRS-046, SwRS-038, SwRS-039, SwRS-041, SwRS-044
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - elektronischer Datenaustausch ist fachlich weiter erforderlich; Partnerliste ist konfigurierbar zu halten.
Status: belegt
ID: StRS-011
Titel: Geheim- und Datenschutz für sensible Daten
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Datenschutzbeauftragter, Systemadministration, alle Benutzer
Vorbedingung: System ist installiert; Datenschutzkonfiguration (DSGVO-Ordner, Verschlüsselungsschlüssel) existiert.
Fakt: Passwörter im Passwort-Manager werden mit AES und einem Masterkey aus der zentralen Konfigurations-DB verschlüsselt (src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs:700, 1051-1052, 1179); Mail-Scanner-Profile verschlüsseln Zugangsdaten vor der Speicherung (MailScannerBL.SaveProfile); DSGVO-Verzeichnisanbieter existieren (src\backend\Centron.BL\Administration\FileManagement\DirectoryReferenceProviders\Dsgvo); Zugangsdaten sind faktisch als SHA1-Hash gespeichert (UsersBL, WebAccountBL).
Aussage: Das System soll vertrauliche Daten (Kundenpasswörter, Dienst-Zugangsdaten, personenbezogene Ablagen) nur verschlüsselt bzw. zugriffsbeschränkt speichern und verarbeiten und DSGVO-relevante Dokumentation eigenständig verwalten.
Ergebnis: Sensible Werte liegen nicht im Klartext in der Datenbank; DSGVO-Ablagen sind getrennt verwaltbar.
Belege:
- [PRIMÄR] PasswordManagerBL (src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs:700, 1051-1052) - Begründung: durchgesetzte AES-Verschlüsselung mit Masterkey vor Persistenz.
- [PRIMÄR] MailScannerBL.SaveProfile (src\backend\Centron.BL\MailScanner\MailScannerBL.cs:74-84) - Begründung: durchgesetzte Ver-/Entschlüsselung der Profil-Zugangsdaten.
- [KONTEXT] src\backend\Centron.BL\Administration\FileManagement\DirectoryReferenceProviders\Dsgvo - Begründung: dokumentierte DSGVO-Ablagestruktur; SHA1-Hashspeicherung (UsersBL.cs:107, WebAccountBL.cs:56) ist als Altlast im Zielsystem zu ersetzen.
Prüfidee: In der Datenbank ist für Passwort-Manager-Werte nur Ciphertext enthalten; Entschlüsselung gelingt nur mit gültigem Masterkey; DSGVO-Dokumente sind nur über den DSGVO-Ordneranbieter erreichbar.
Tracelinks: SyRS-011, SyRS-038, SyRS-045, SwRS-037, SwRS-043
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - SHA1-Hashspeicherung ist historisch überholt und im Zielsystem durch starke Hashverfahren (z. B. Argon2/bcrypt) zu ersetzen; Verschlüsselungsidee bleibt.
Status: belegt
ID: StRS-012
Titel: Lizenzgesteuerte Funktionsausprägung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsführung, Softwareanbieter, Systemadministration
Vorbedingung: Lizenzdatei ist eingespielt.
Fakt: Funktionsmodule werden lizenzabhängig freigegeben: Online-Banking prüft LicenseGuids.OnlineBanking_FinApi (OnlineBankingFinApiBL.cs:33), Produktion prüft LicenseGuids.ProductionManagement und verweigert ohne Lizenz mit Fehlermeldung (ArticleProductionBL.cs:34-56); LicenseManager stellt HasLicense/CheckLicense bereit (src\backend\Centron.BL\Administration\Licensing\LicenseManager.cs:31-39).
Aussage: Das System soll dessen Funktionsumfang je Kundeneinsatz über Lizenzen steuern, sodass lizenzpflichtige Module erst bei gültiger Lizenz nutzbar sind.
Ergebnis: Nicht lizenzierte Module sind gesperrt bzw. liefern leere Daten mit klarer Meldung.
Belege:
- [PRIMÄR] OnlineBankingFinApiBL.GetFinApiClientCredentials (src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingFinApiBL.cs:29-49) - Begründung: durchgesetzte Lizenzprüfung vor Freigabe der FinAPI-Credentials.
- [PRIMÄR] ArticleProductionBL (src\backend\Centron.BL\Warehousing\ArticleProduction\ArticleProductionBL.cs:34-56) - Begründung: durchgesetzte Lizenzsperre mit Ausnahme-/Fehlermeldung.
- [SEKUNDÄR] LicenseManager.HasLicense/GetLicenseCount (src\backend\Centron.BL\Administration\Licensing\LicenseManager.cs:31-39) - Begründung: zentrale Lizenzschnittstelle.
Prüfidee: Ohne Produktionslizenz liefert der Produktionszugriff nur leere Daten bzw. eine Fehlermeldung; mit Lizenz sind Produktionsaufträge vollständig nutzbar.
Tracelinks: SyRS-006, SyRS-031, SyRS-036, SwRS-007, SwRS-035
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Lizenzsteuerung ist Geschäftsmodellbestandteil des Anbieters.
Status: belegt
ID: StRS-013
Titel: Web- und Cloud-Betriebsfähigkeit der Suite
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Portierbarkeit / Betriebbarkeit (ISO 25010: Übertragbarkeit, Wartbarkeit)
Akteur: Softwarebetrieb, Hosting, Entwicklung
Vorbedingung: Zielplattform (Server/Container) ist verfügbar.
Fakt: Die Suite wird über Docker-Images (docker\c-entron-webservice\Dockerfile, docker\c-entron-api\Dockerfile, docker\compose\compose.yaml), WiX-Installationspakete (deployment\centron\CentronSetupProject\Product.wxs) und Azure-DevOps-Build-/Testpipelines (azure\build-pipeline.yml, azure\tests-pipeline.yml) gebaut und betrieben; Ziel ist laut Auftrag eine Web-/SaaS-Neuimplementierung.
Aussage: Das System soll containerisiert/automatisiert installier- und betreibbar sein, sodass Bereitstellung, Aktualisierung und Regressionstests wiederholbar erfolgen können.
Ergebnis: Deployment und Tests laufen pipeline-gesteuert; Installation ist ohne manuelle Einzelritte wiederholbar.
Belege:
- [SEKUNDÄR] docker\compose\compose.yaml und docker\c-entron-webservice\Dockerfile - Begründung: konkrete Containerisierung von Webservice und Abhängigkeiten.
- [SEKUNDÄR] azure\build-pipeline.yml, azure\tests-pipeline.yml, azure\regression-tests-pipeline.yml - Begründung: automatisierte Build-/Testkette.
- [SEKUNDÄR] deployment\centron\CentronSetupProject\Product.wxs - Begründung: klassische Desktop-Installation als zweiter Betriebsweg.
Prüfidee: Aus dem Repository lässt sich der Webservice per Pipeline bauen und in einen Container deployen; Regressionstests laufen gegen die bereitgestellte Instanz.
Tracelinks: SyRS-044, SwRS-048
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - automatisierter Betrieb ist Voraussetzung für SaaS.
Status: belegt
ID: StRS-014
Titel: Organisation, Personal und Terminsteuerung im System führen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Führungskräfte, Mitarbeiter
Vorbedingung: Personalstamm ist angelegt; Benutzer sind Mitarbeitern zugeordnet.
Fakt: Personal- und Gruppenstammdaten (Tabellen Personal, PersonalGruppen), Terminplanung (Terminplanung, TerminplanungPerson), Aufgaben/ToDos (ToDoListe) und Zeiterfassung inkl. externem CTime-Connector (src\backend\Centron.BL\Services\CTimeConnectors\CTimeConnectorBL.cs) sind Bestandteil der Suite; Kalender-/Auslastungsrechte sind dokumentiert (CentronRights.md, Abschnitt Mitarbeiterauslastung).
Aussage: Das System soll interne Organisation (Personal, Termine, Aufgaben, geleistete Zeiten) so führen, dass Auslastung, Fälligkeiten und Leistungszeiten je Mitarbeiter auswertbar sind.
Ergebnis: Führungskräfte können Auslastung und Fälligkeiten je Mitarbeiter einsehen (rechtebeschränkt).
Belege:
- [PRIMÄR] CTimeConnectorBL (src\backend\Centron.BL\Services\CTimeConnectors\CTimeConnectorBL.cs) - Begründung: durchgesetzter Zeitsynchronisationsdienst mit Übertragungsdatum.
- [KONTEXT] CentronRights.md (Mitarbeiterauslastung: nur eigene Filiale) - Begründung: dokumentierte Fachregel zur Auslastungssicht.
- [SEKUNDÄR] Tabellen Personal, PersonalGruppen, Terminplanung, TerminplanungPerson, ToDoListe (SSMS_DB_SCHEMA.sql) - Begründung: Organisationsdatenhaltung.
Prüfidee: Termin mit zugeordneter Person erscheint im Personkalender; CTime-Import überträgt nur Zeitsätze nach dem letzten Übertragungsdatum.
Tracelinks: SyRS-050, SyRS-051
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Personal-/Zeitdaten tragen Abrechnung und Auslastung.
Status: belegt
ID: StRS-015
Titel: Konsolidierte Datenhaltung gleichartiger Geschäftsobjekte
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsführung, Systemadministration
Vorbedingung: Migrationsprojekt ist gestartet.
Fakt: Die Codebasis hält gleichartige Konzepte doppelt: Drucker werden als "Stammblätter" und sonstige Hardware getrennt als "Assets" geführt (vorgegebene Konsolidierungsbeispiel-Regel; Stammblatt-/Asset-Datenhaltung im Modul Devices/AssetManagement), es existieren parallel Beleg-Kopf- und Versionstabellen je Belegart sowie getrennte Kunden-/Lieferantenstämme (Kunden, Kreditor) mit eigenen Nummernkreisen.
Aussage: Das Zielsystem soll gleichartige Geschäftsobjekte (Hardware/Drucker, Belegarten, Partner) auf konsolidierte Konzepte abbilden, um Doppelhaltung und Inkonsistenzen zu vermeiden.
Ergebnis: Ein Objekttyp existiert genau einmal; bestehende Doppelhaltungen werden bei Migration zusammengeführt.
Belege:
- [SEKUNDÄR] Tabellen AssetManagementDevices, AccountDevices, GeraeteKopf (SSMS_DB_SCHEMA.sql) - Begründung: drei parallele Geräte-/Asset-Datenhaltungen im Schema.
- [KONTEXT] Vorgabe der Auswertung (Konsolidierungsbegriff, Drucker/Asset-Beispiel) - Begründung: benennt das Doppelhaltungsmuster als fachlich bekannt.
Prüfidee: Im Zielsystem ist ein Gerät/Drucker in genau einer Datenhaltung abgelegt; Belege referenzieren dieses Konzept eindeutig.
Tracelinks: SyRS-027, SyRS-053, SwRS-047
Konsolidierung: Kandidat: Stammblätter vs. Assets; Kunden/Kreditor-Stämme; Belegart-Kopf-/Versionstabellen
Übernahmewürdigkeit: übernehmen - Konsolidierung ist Ziel der Neuimplementierung; Altstrukturen sind `veraltet` für das Zielsystem.
Status: belegt
ID: StRS-016
Titel: Nachvollziehbare Änderungsverfolgung sensibler Objekte
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Rückverfolgbarkeit (ISO 25010: Zuverlässigkeit/Wartbarkeit)
Akteur: Compliance/Audit, Systemadministration
Vorbedingung: Change-Tracking ist aktiviert.
Fakt: Die Suite enthält ein Change-Tracking-Modul (src\backend\Centron.BL\ChangeTracking) mit eigener Persistenzschicht (src\backend\Centron.DAO\ChangeTracking) und Interface-Layer (src\backend\Centron.Interfaces\ChangeTracking); Belegabschlüsse erzeugen Historien- und Aktivitätsdatensätze (HelpdeskCloseBL:150-151: HistoryForActionType, CreateActivityForTicketClosed).
Aussage: Das System soll fachlich relevante Änderungen (z. B. Belegabschluss, Statuswechsel) mit Wer-Hat-Wann-Angaben protokollieren, damit Änderungen auditierbar sind.
Ergebnis: Für geprüfte Objekttypen existieren Änderungsprotokolle mit Benutzer und Zeitpunkt.
Belege:
- [PRIMÄR] HelpdeskCloseBL (src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:150-151) - Begründung: durchgesetzte Historien-/Aktivitätserzeugung beim Abschluss.
- [SEKUNDÄR] src\backend\Centron.BL\ChangeTracking und src\backend\Centron.DAO\ChangeTracking - Begründung: Vorhandensein einer Change-Tracking-Architektur; Granularität im Detail im Zielsystem zu spezifizieren.
Prüfidee: Abschluss eines Tickets erzeugt einen Historieneintrag mit Benutzer und Zeitstempel; Änderungen an getrackten Entitäten sind im Change-Log nachweisbar.
Tracelinks: SyRS-012, SyRS-018, SyRS-032, SwRS-031
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Auditierbarkeit ist für ERP-Prozesse erforderlich.
Status: belegt
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse/SwRS.md
+1031
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse/SyRS.md
+1050
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse/Traceability.md
+79
View File
@@ -0,0 +1,79 @@
# Traceability (c-entron ERP-Suite)
Konsolidierte Traceability-Tabelle über alle drei Ebenen. Zuordnung: Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung (siehe `Tracelinks` in SwRS.md), jede SyRS-Anforderung die zugehörige StRS-Anforderung (siehe `Tracelinks` in SyRS.md). Diese Tabelle fasst die Beziehungen je Belegkette zusammen und verknüpft mit dem Hauptartefaktbeleg.
## Traceability-Tabelle (StRS | SyRS | SwRS | Artefaktbeleg)
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (Hauptquelle) |
|---|---|---|---|
| StRS-001 | SyRS-001 | SwRS-003 | TicketAuthenticationHandler.cs:44-95 (src\webservice\Centron.Host\AspNetCore) |
| StRS-001 | SyRS-001 | SwRS-002 | AuthorizeUserRightAttribute.cs:38-56 + TicketAuthenticationHandler.cs |
| StRS-001 | SyRS-003 | SwRS-004 | UsersBL.cs:56-130 (src\backend\Centron.BL\Administration\Logins) |
| StRS-001 | SyRS-004 | SwRS-006 | TwoFactorAuthBL.cs:33-120 (…\Logins\TwoFactor) |
| StRS-001 | SyRS-005 | SwRS-005 | WebAccountBL.cs:54-61 (…\Logins) |
| StRS-002 | SyRS-002 | SwRS-001 | UserRightsConst.cs (766 Konstanten) + UserRightAuthorizationFilter |
| StRS-003 | SyRS-007 | SwRS-009 | NumberGroupBL.cs:136-152; SSMS_DB_SCHEMA.sql (Mandant, Filiale) |
| StRS-003 | SyRS-008 | SwRS-008 | NumberGroupBL.cs:62-134 (GetNextNumber/FindNextNumber) |
| StRS-004 | SyRS-016 | SwRS-016, SwRS-017 | ReceiptBL.cs; SpecificLogics.cs; SSMS_DB_SCHEMA.sql (Kopf-/Pos-/Versions-Tabellen) |
| StRS-004 | SyRS-017 | SwRS-018 | ReceiptBL.cs:3085-3096 (TryLockReceipt) |
| StRS-004 | SyRS-018 | SwRS-018 | ReceiptBL.cs:3068-3157 (CreateNewVersion) |
| StRS-004 | SyRS-020 | SwRS-020 | ReceiptCartReleaseSystemBL.cs; CurrentCartService.cs:24-43 |
| StRS-005 | SyRS-019 | SwRS-019 | ReceiptItemPriceBL.cs:29-79 |
| StRS-006 | SyRS-021 | SwRS-021 | DunningRunBL.cs:253-268, 519-539 |
| StRS-006 | SyRS-022 | SwRS-022 | OposBL.cs; SSMS_DB_SCHEMA.sql (Zahlungseingang/-Log) |
| StRS-007 | SyRS-025 | SwRS-025 | SupplierOrderBL.cs; SSMS_DB_SCHEMA.sql (BestKopf2/BestPos2) |
| StRS-007 | SyRS-026 | SwRS-026 | SupplierReceiptDocumentBL.cs; PdfScanning\StrategyHandler\* |
| StRS-007 | SyRS-027 | SwRS-027 | SSMS_DB_SCHEMA.sql (ARTIK/WAREN/UNTERWAREN); ArticleBL.cs |
| StRS-007 | SyRS-028 | SwRS-028 | ArticleStockBL.cs:47-148 |
| StRS-007 | SyRS-029 | SwRS-029 | SSMS_DB_SCHEMA.sql (SeriennummerToPosition, Barcode*) |
| StRS-007 | SyRS-030 | SwRS-028 | InventoryNewBL.cs (Status HYPOTHESE, s. Hypothesen.md) |
| StRS-008 | SyRS-032 | SwRS-030, SwRS-031 | HelpdeskStatusBL.cs:75-100; HelpdeskCloseBL.cs:120-151 |
| StRS-008 | SyRS-033 | SwRS-032 | ReceiptBL.cs:5295 (CreateNewReceiptForHelpdekTimers); CentronRights.md |
| StRS-008 | SyRS-034 | SwRS-033 | EscalationBL.cs; EscalationReceiversEnum.cs (Status HYPOTHESE) |
| StRS-008 | SyRS-053 | SwRS-053 | SSMS_DB_SCHEMA.sql (AccountDevicesToTickets, GeraeteKopf) |
| StRS-009 | SyRS-018 | SwRS-016, SwRS-018 | ReceiptBL.cs:3068-3157; SSMS_DB_SCHEMA.sql (*Versions) |
| StRS-009 | SyRS-035 | SwRS-034 | BookKeepingExportBL.cs:91-125; Gateway DataExchange\BookKeeping |
| StRS-009 | SyRS-043 | SwRS-042 | DocumentSigningPage.razor (Status HYPOTHESE) |
| StRS-010 | SyRS-039 | SwRS-038 | EDIDispatcherBL.cs; SupplierEdiBL.* (src\backend\Centron.BL\EDI) |
| StRS-010 | SyRS-040 | SwRS-039 | InvoiceZugferdBL.cs:85-155 |
| StRS-010 | SyRS-041 | SwRS-040 | ShipcloudPackageTemplateBL.cs; Centron.Api.Gls/Shipcloud |
| StRS-010 | SyRS-042 | SwRS-041 | WebCart\Helpers\*; README.md (WebCart) |
| StRS-010 | SyRS-044 | SwRS-002, SwRS-048 | RegisterCentronApiVersioning/Swagger; docker\*, azure\* |
| StRS-010 | SyRS-046 | SwRS-044 | ArticleSearch\*ExternalArticleSearchProvider.cs; src\apis\*DataAccess |
| StRS-011 | SyRS-011 | SwRS-012, SwRS-048 | DirectoryReferenceProviders\* (inkl. Dsgvo) |
| StRS-011 | SyRS-038 | SwRS-037 | MailScannerBL.cs:57-84 |
| StRS-011 | SyRS-045 | SwRS-043 | PasswordManagerBL.cs:608, 700, 949, 1051-1052 |
| StRS-012 | SyRS-006 | SwRS-007 | LicenseManager.cs:24-158; OnlineBankingFinApiBL.cs:29-49 |
| StRS-012 | SyRS-031 | SwRS-028 | ArticleProductionBL.cs:30-56 (Status HYPOTHESE bzgl. Rückmeldung) |
| StRS-012 | SyRS-036 | SwRS-035 | OnlineBankingFinApiBL.cs; FinApiClient.cs |
| StRS-013 | SyRS-044 | SwRS-048 | RegisterCentronApiVersioning.cs; docker\c-entron-webservice\Dockerfile |
| StRS-014 | SyRS-050 | SwRS-050 | SSMS_DB_SCHEMA.sql (Terminplanung*, ToDoListe); CentronRights.md (Kalender) |
| StRS-014 | SyRS-051 | SwRS-051 | CTimeConnectorBL.cs; CTimeConnectorLastTransferDate |
| StRS-014 | SyRS-055 | SwRS-055 | HelpdeskSendMailBL.cs; GeschaeftspartnerTextbausteine |
| StRS-015 | SyRS-027 | SwRS-047 | SSMS_DB_SCHEMA.sql (Produktfamilie*Sperren); ProductFamilyBL.cs |
| StRS-015 | SyRS-013 | SwRS-013 | SSMS_DB_SCHEMA.sql (Kunden/Anschrif/Personen) |
| StRS-015 | SyRS-014 | SwRS-014 | SSMS_DB_SCHEMA.sql (Kreditor); NumberGroupBL.cs:124-131 |
| StRS-015 | SyRS-015 | SwRS-015 | SSMS_DB_SCHEMA.sql (Vertriebssteuerung, AngebotVerloren) |
| StRS-015 | SyRS-053 | SwRS-053 | SSMS_DB_SCHEMA.sql (AssetManagement*, GeraeteKopf) |
| StRS-016 | SyRS-012 | SwRS-031 | ChangeTracking\* (BL/DAO/Interfaces); HelpdeskCloseBL.cs:150-151 |
| StRS-016 | SyRS-018 | SwRS-016 | ReceiptBL.cs (Versionslogik); SSMS_DB_SCHEMA.sql (*Versions) |
| StRS-016 | SyRS-032 | SwRS-030 | HelpdeskStatusBL.cs; HelpdeskCloseBL.cs (Historie) |
| StRS-016 | SyRS-049 | SwRS-049 | CacheTicketStatisticsBL.cs; TicketFulltextIndex.cs; GermanAnalyzer.cs |
| StRS-016 | SyRS-052 | SwRS-052 | SSMS_DB_SCHEMA.sql (CRMProjekt, AnfrKopf-Versions, Rma); RmaBL.cs |
| StRS-016 | SyRS-054 | SwRS-054, SwRS-055 | VoucherManagementBL.cs:17-24; TapiNumberMaps.cs; SocialMedia* |
## Ergänzende Zuordnungen (SyRS ohne eigene Zeile oben)
| SyRS-ID | StRS-ID | SwRS-ID | Artefaktbeleg |
|---|---|---|---|
| SyRS-009 | StRS-014 | SwRS-010 | CashBookBookingBL.cs:53; ReceiptItemPriceBL.cs:78-79 |
| SyRS-010 | StRS-014 | SwRS-011 | Scripts\ScriptMethods\RecurringScriptMethods\* |
| SyRS-047 | StRS-013 | SwRS-045 | WorkflowProcessBL.cs; WorkflowShapeBL.cs |
| SyRS-048 | StRS-013 | SwRS-046 | CentronNexus.OutlookAddIn\* (Belege/Ticket/Document) |
| SyRS-054 | StRS-016 | SwRS-054, SwRS-055 | VoucherManagementBL.cs; SocialMedia*-Tabellen |
## Konsistenzregeln der Tabelle
- Jede Zeile bildet eine Belegkette StRS → SyRS → SwRS; Mehrfachnennungen sind zulässig (n:1-Konsolidierung).
- Zeilen mit "(Status HYPOTHESE)" verweisen auf Anforderungen, deren Vollaussage als Hypothese geführt wird (siehe Hypothesen.md): SyRS-030, SyRS-031, SyRS-034, SwRS-042.
- Die Vollständigkeit der Beziehungen ist zusätzlich über die `Tracelinks`-Felder in den drei Spezifikationsdateien prüfbar.
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/OpenCode.log
View File
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/OpenCodeEvents.jsonl
+267
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Protokoll.md
+125
View File
@@ -0,0 +1,125 @@
# Messprotokoll – Iteration 16/z-ai/glm-5.3-flash/solo/high
> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
## Lauf
- **Prompt-Datei:** `03_Prompt.md`
- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
- **Startzeit:** 2026-09-02T09:34:01.4984399+02:00
- **Endzeit:** 2026-09-02T09:56:48.1729325+02:00
- **Dauer gesamt:** 00:22:43 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
## Werkzeugkonfiguration
- **Skill-Version:** 13.0.0
- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider tensorx` (Adapter-Version 2.5.2)
- **CLI-Version:** OpenCode 1.18.25
- **Modell (angefordert):** `z-ai/glm-5.3-flash`
- **Modell (tatsaechlich):** `z-ai/glm-5.3-flash`
- **Kontrolle Modell:** bestanden
- **Effort:** `high` angefordert, **wirksam** (`effort_applied: true`)
- **Ablage:** `Iteration 16/z-ai/glm-5.3-flash/solo/high/`
- **Agentenmodus:** `solo`
- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
- **Sampling-Parameter:** nicht steuerbar
- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
- **Subagenten:** `spawned` = 0, `completed` = 0, `failed` = 0
- **Rollen:** {}
## Validierungsstichprobe
- **Stand:** entfaellt
## Verbrauch
| Messgroesse | Wert |
|---|---|
| Input-Tokens | 2.411.196 |
| Output-Tokens | 88.920 |
| Reasoning-Tokens | 42.935 |
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
| Agent-Turns | 71 |
**Tokens gesamt: 6.336.907.** Kosten `0` – lokaler Betrieb ().
## Gefundene Anforderungen
## 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 | 16 | 12,7 % |
| SyRS | 55 | 43,7 % |
| SwRS | 55 | 43,7 % |
| **Gesamt** | **126** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 53 | 42,1 % |
| Daten | 33 | 26,2 % |
| Sicherheit | 17 | 13,5 % |
| Schnittstelle | 16 | 12,7 % |
| nicht-funktional | 7 | 5,6 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 242 |
| davon `PRIMÄR` | 160 (66,1 %) |
| davon `SEKUNDÄR` | 75 (31,0 %) |
| davon `KONTEXT` | 7 (2,9 %) |
| Belege je Anforderung (Median) | 2,0 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 123 (97,6 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 113 | 89,7 % |
| workaround | 13 | 10,3 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 122 | 96,8 % |
| als `HYPOTHESE` gekennzeichnet | 4 | 3,2 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 15 | 11,9 % |
| mit ISO-25010-Qualitätsmerkmal | 7 | 5,6 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (32 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 126 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 126 von 126 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
- **Session-ID:** `ses_f9ef5eeddffeI5bgXF54VzIYO7`
- **Werkzeugaufrufe:** 111 – {"bash": 74, "read": 9, "write": 7, "edit": 21}
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – korrekt fuer solo
- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
- **Root unveraendert:** ja
- **Fehlermeldungen:** []
## Anmerkungen/Auffaelligkeiten
*(von Hand zu ergaenzen)*
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/RawResult.json
+1108
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Stderr.log
+5
View File
@@ -0,0 +1,5 @@
[2026-09-02T07:34:03.171666+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\Ergebnisse)
[2026-09-02T07:34:03.337272+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=solo; Effort=high (uebergeben=True); Stall-Timeout=0s
[2026-09-02T07:56:46.598851+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
[2026-09-02T07:56:48.097160+00:00] OpenCode export: Exporting session: ses_f9ef5eeddffeI5bgXF54VzIYO7
[2026-09-02T07:56:48.149249+00:00] Ende: Exitcode=0; Status=success; Turns=71; Tokens=6336907; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\RawResult.json
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/after.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/anforderungen.json
+2512
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/anforderungen.md
+63
View File
@@ -0,0 +1,63 @@
## 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 | 16 | 12,7 % |
| SyRS | 55 | 43,7 % |
| SwRS | 55 | 43,7 % |
| **Gesamt** | **126** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 53 | 42,1 % |
| Daten | 33 | 26,2 % |
| Sicherheit | 17 | 13,5 % |
| Schnittstelle | 16 | 12,7 % |
| nicht-funktional | 7 | 5,6 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 242 |
| davon `PRIMÄR` | 160 (66,1 %) |
| davon `SEKUNDÄR` | 75 (31,0 %) |
| davon `KONTEXT` | 7 (2,9 %) |
| Belege je Anforderung (Median) | 2,0 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 123 (97,6 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 113 | 89,7 % |
| workaround | 13 | 10,3 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 122 | 96,8 % |
| als `HYPOTHESE` gekennzeichnet | 4 | 3,2 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 15 | 11,9 % |
| mit ISO-25010-Qualitätsmerkmal | 7 | 5,6 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (32 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 126 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 126 von 126 mit Tracelinks (100,0 %) |
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/before.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/combined_prompt.md
+174
View File
@@ -0,0 +1,174 @@
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
## Metadaten
- **Versuch:** V1 Baseline (Prompt-only)
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-28
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
| Änderung | Auslösender Befund |
|---|---|
---
## Prompt
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
### Auftrag
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
### Vorgehen (statische Analyse, keine Ausführung)
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
### Pflicht-Eigenschaften jeder Anforderung
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
- **Belegklassifikation:** Kennzeichne jeden Beleg als
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
### Formatvorgabe pro Anforderung
```
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
Titel: <kurzer Titel>
Ebene: <StRS | SyRS | SwRS>
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
Akteur: <Rolle / System / Komponente>
Vorbedingung: <Zustand vor Auslösen>
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
Belege:
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
- [SEKUNDÄR] <...> - Begründung: <...>
- [KONTEXT] <...> - Begründung: <...>
Prüfidee: <Akzeptanzkriterium oder Testidee>
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
Status: <belegt | HYPOTHESE>
```
### Traceability
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
### Nicht-funktionale Anforderungen
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
### Konsolidierungsbedarf
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
```text
Ergebnisse/
StRS.md
SyRS.md
SwRS.md
Traceability.md (oder Traceability.csv)
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
Selbstbewertung, bekannte Lücken)
```
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
Verzeichnissen sowie das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis.
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver,
Webzugriff.
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
Werkzeuge zu ersetzen.
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T09:56:48.1729325+02:00
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/opencode-config.json
+230
View File
@@ -0,0 +1,230 @@
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"tensorx": {
"npm": "@ai-sdk/openai-compatible",
"name": "TensorX",
"options": {
"baseURL": "https://api.tensorx.ai/v1"
},
"models": {
"qwen/qwen3.8-flash-next": {
"name": "Qwen 3.8 Flash Next",
"limit": {
"context": 262144,
"output": 131072
},
"variants": {
"low": {
"thinking": {
"type": "enabled",
"level": "low"
}
},
"medium": {
"thinking": {
"type": "enabled",
"level": "medium"
}
},
"high": {
"thinking": {
"type": "enabled",
"level": "high"
}
},
"xhigh": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
},
"max": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
}
}
},
"z-ai/glm-5.2": {
"name": "GLM 5.2",
"limit": {
"context": 1048576,
"output": 131072
},
"variants": {
"low": {
"thinking": {
"type": "enabled",
"level": "low"
}
},
"medium": {
"thinking": {
"type": "enabled",
"level": "medium"
}
},
"high": {
"thinking": {
"type": "enabled",
"level": "high"
}
},
"xhigh": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
},
"max": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
}
}
},
"z-ai/glm-5.3-flash": {
"name": "GLM 5.3 Flash",
"variants": {
"low": {
"thinking": {
"type": "enabled",
"level": "low"
}
},
"medium": {
"thinking": {
"type": "enabled",
"level": "medium"
}
},
"high": {
"thinking": {
"type": "enabled",
"level": "high"
}
},
"xhigh": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
},
"max": {
"thinking": {
"type": "enabled",
"level": "xhigh"
}
}
}
},
"moonshotai/kimi-k3": {
"name": "Kimi K3",
"limit": {
"context": 1048576,
"output": 131072
}
}
}
}
},
"model": "tensorx/z-ai/glm-5.3-flash",
"permission": {
"*": "deny",
"read": "allow",
"glob": "allow",
"grep": "allow",
"list": "allow",
"edit": {
"*": "deny",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/spiegel/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/spiegel/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/spiegel/Ergebnisse/**": "allow"
},
"external_directory": {
"*": "deny",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/spiegel/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/spiegel/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/spiegel/Ergebnisse/**": "allow"
},
"bash": {
"*": "allow",
"rm *": "deny",
"rmdir *": "deny",
"mv *": "deny",
"cp *": "deny",
"dd *": "deny",
"truncate *": "deny",
"chmod *": "deny",
"chown *": "deny",
"ln *": "deny",
"tee *": "deny",
"sed -i*": "deny",
"git checkout*": "deny",
"git restore*": "deny",
"git clean*": "deny",
"git reset*": "deny",
"git add*": "deny",
"git commit*": "deny",
"git push*": "deny",
"git fetch*": "deny",
"git pull*": "deny",
"git remote*": "deny",
"dotnet *": "deny",
"msbuild *": "deny",
"npm install*": "deny",
"nuget *": "deny",
"Remove-Item *": "deny",
"Move-Item *": "deny",
"Copy-Item *": "deny",
"New-Item *": "deny",
"Set-Content *": "deny",
"Add-Content *": "deny",
"Clear-Content *": "deny",
"Out-File *": "deny",
"Set-ItemProperty *": "deny",
"Rename-Item *": "deny"
},
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"question": "deny"
},
"agent": {
"build": {
"model": "tensorx/z-ai/glm-5.3-flash",
"mode": "primary"
},
"general": {
"model": "tensorx/z-ai/glm-5.3-flash",
"mode": "subagent"
},
"explore": {
"model": "tensorx/z-ai/glm-5.3-flash",
"mode": "subagent"
}
},
"default_agent": "build"
}
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/opencode-session.json
+8310
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T09:34:01.4984399+02:00