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/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Adapter.log
+5
View File
@@ -0,0 +1,5 @@
[2026-09-02T11:11:03.761390+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\Ergebnisse)
[2026-09-02T11:11:03.862020+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=builtin; Effort=high (uebergeben=True); Stall-Timeout=0s
[2026-09-02T12:03:36.484593+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
[2026-09-02T12:03:38.004876+00:00] OpenCode export: Exporting session: ses_f9e2f37dbffePXP0P4ACRLx8cN
[2026-09-02T12:03:38.084502+00:00] Ende: Exitcode=0; Status=success; Turns=71; Tokens=7830882; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\RawResult.json
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/Analysebericht.md
+221
View File
@@ -0,0 +1,221 @@
# Analysebericht
Reverse Requirements Engineering der c-entron ERP-Suite (Baseline, prompt-only). Stand: nach Konsistenzbereinigung.
Stufen: **tief** = mehrere Anforderungen inkl. verifizierter Durchsetzungsstellen; **mittel** = eigene Anforderung(en) mit PRIMÄR-Beleg; **flach** = Modulinventar + Stichprobe (API-Sicht), keine/eine Requirement; **nicht analysiert** = mit Begründung.
## 1. Ergebnisübersicht
| Kennzahl | Wert |
|---|---|
| Anforderungen gesamt | 199 (StRS 16, SyRS 49, SwRS 134) |
| Belegzeilen | 323 (davon 256 PRIMÄR, Rest SEKUNDÄR/KONTEXT) |
| Anforderungen ohne Beleg | 0 |
| Anforderungen ohne Übernahmewürdigkeit | 0 |
| Hypothesen | 23 (5 SyRS, 18 SwRS, 0 StRS) → Hypothesen.md |
| Konsolidierungskandidaten | 165 |
| Verdikte ≠ „übernehmen" | 31 (Workaround 8, Sonderfall 7, veraltet 6, unklar 4, Mischformen 6) |
| Analysierte Module (Inventar) | 117 von 117 (=100 %); nicht-analysiert-Anteil 0 % (Ziel ≤10 % eingehalten) |
## 2. Modulinventar und Abdeckung
### 2.1 Backend-Fachmodule `src\backend\Centron.BL\` (88 Module, ohne bin/obj/Properties/Resources)
| Modul | .cs | Stufe | Anf. | Kernsatz |
|---|---|---|---|---|
| Administration | 959 | tief | 42 | Rechte, Logins/2FA, Lizenzen, Settings, Config-DB, Customizing, Diagnostik, Themes, KI |
| Sales | 248 | tief | 24 | Belegfluss, Rechnungen, Mahnen, Zahlungen, Helpdesk/SLA, Shop-Preisstellung |
| WebServices | 464 | mittel | 4 | *WebServiceBL-Schicht als REST-Backend (strukturell analysiert, Details je Fachbereich offen) |
| Warehousing | 40 | mittel | 2 | Kommissionierung/Barcode mit Rechteprüfung, EK-Fortschreibung |
| Accounts | 29 | mittel | 4 | Account-Stamm, Nummernvergabe, Filterzwang für Web-Accounts |
| EDI | 27 | mittel | 1 | EDIDispatcher: Bestellungen hinaus, Antworten herein |
| DataExchange | 23 | mittel | 5 | Buchhaltungsexport (DATEV/SAP), E-Rechnung, Exportkonfiguration |
| Mail | 20 | mittel | 1 | austauschbare Mail-Protokollclients, verschlüsselte Secrets |
| Statistics | 16 | mittel | 1 | Cache-Statistiken + benutzereigene Definitionen |
| Services | 11 | mittel | 1 | CachedTableBL-Selbstreparatur/Sofortaktualisierung |
| EmployeeArea | 9 | mittel | 5 | Employee↔AppUser-Mapping, Verfügbarkeit, Dispatcher, Abteilungen, Einstellungen |
| Finances | 9 | mittel | 1 | PaymentsBL-Rückbuchung über zentralen Buchungspunkt |
| CustomerArea | 7 | mittel | 1 | Branchenzuweisungen atomar ersetzen |
| Purchasing | 4 | mittel | 2 | Bestellvorschlagsliste, bereichsübergreifender Lieferantenexport |
| TaskManager | 4 | mittel | 2 | wiederkehrende Aufgaben mit Lizenz-/Aktionsvalidierung |
| MyDay | 7 | flach | 1 | Tagesplanungs-Batches mit gemeinsamer BatchId |
| Production | 2 | flach | 2 | Fertigungsaufträge filterbar; Lizenzpflicht |
| NexusTicketViews | 1 | flach | 2 | Ticket-Ansichten mit Besitzer-/Namensregeln |
| CountryArea | 2 | mittel | 3 | Inlandsland, Defaultland, EZB-Kursimport |
| IndexSearch | 7 | flach | 1 | deutsche Volltextsuche (Stemming, ALL-Semantik) |
| ReportEngine | 26 | mittel | 1 | PDF-Strategien mit PDF/A3-Fallback; Berichte/Archivierung |
| RiverDivo | 4 | flach | 1 | Gegenstelle externes Ticketsystem (River Suite) |
| WebLinks | 4 | flach | 1 | Weblink→CRM-Aktivität |
| Modules | 3 | flach | 1 | Modulstamm-Autoanlage, Favoriten |
| CheckListArea | 3 | flach | 1 | Checklisten-Pflicht-Caption, transaktional |
| Mailings | 2 | flach | 1 | Mailing-Gesamtaggregat laden |
| Notifications | 2 | flach | 1 | Empfängerlisten-Sync + Meldungs-Cleanup |
| NexusNotifications | 2 | flach | 1 | rohe SQL-Verwaltung je Empfänger |
| MyCentron | 4 | flach | 1 | benutzergetrennte Dashboardcontainer |
| TextModuleArea | 2 | flach | 1 | Textbaustein-Resolver benutzer>kunde>global |
| TradePool | 2 | flach | 1 | Handelspool-XML-Import |
| Urls | 2 | flach | 1 | durchsuchbare Objekt-URLs |
| ToDoArea | 2 | flach | 1 | zentraler ToDo-Typkatalog (>30 Objektarten) |
| SelfCare | 2 | flach | 1 | Formular→Helpdesk-Ticket (Kette teiloffen) |
| Integrations | 2 | flach | 1 | ElectronicSales-Gruppen/Rollen-Spiegel (Hypothese) |
| CPra | 2 | flach | 1 | c-pra-Token/Webhooks |
| WebSuite | 5 | flach | 1 | Web-Einstellungen nach Login-Art getrennt |
| PasswordManagementArea | 6 | flach | 1 | Alt-Passwortverwaltung (Hypothese: Nutzung offen) |
| Security | 1 | flach | 1 | PDF-Signatur mit Zertifikatskonfiguration |
| TwoFactorAuthenticator | 1 | flach | 1 | personengebundener 2FA-Schlüssel (Erzwingerstelle Hypothese) |
| PasswordManager | 1 | flach | 1 | Export nur mit Recht/Lizenz/Masterkey |
| DocumentationArea | 1 | flach | 1 | interne Doku nur mit Leserecht |
| Tags | 1 | flach | 1 | Tag-Reaktivierung beim Verschlagworten |
| Tapi | 1 | flach | 1 | CTI-Rufnummern-Suchkaskade |
| Outlook | 1 | flach | 1 | Kundensuche nach Gerätenummer (Modulminimal) |
| SocialMedia | 1 | flach | 1 | Kommentare/Likes via DB-Prozeduren (Hypothese) |
| VideoPortal | 1 | flach | 1 | Videozuweisung rechtsgeprüft + ToDo-Kopplung |
| DocuBoard | 3 | flach | 1 | Partner-Aggregat-Speicherung |
| AppointmentRequests | 1 | flach | 1 | Terminanfrage-Antwort gegen Exchange |
| Calendar | 1 | flach | 1 | Kalender-/Outlook-Sync-Einstellungen |
| Chats | 1 | flach | 1 | Chat-Guards (250 Zeichen, Autor, Soft-Delete) |
| MassUpdate | 1 | flach | 1 | Massenänderungs-Vorlagen (Rechte offen) |
| Processes | 1 | flach | 1 | Prozessmodell-Validierung/Atomarität |
| ExpectedEvents | 1 | flach | 1 | Überwachungsdefinitionen mit Löschkaskade |
| Devices | 1 | flach | 1 | Geräte-Soft-Delete mit Protokoll |
| Logistics | 1 | flach | 1 | Umlagerungsprotokoll validiert |
| Buying | 1 | flach | 1 | Distributor-Autoanlage bei Import |
| ProductMatrix | 1 | flach | 1 | Kunden-Produktmatrix mit Historie |
| Projects | 1 | flach | 1 | nur Lese-API (Hypothese: auslaufend) |
| TicketProjects | 1 | flach | 1 | Nummernkreis + Soft-Delete-Aufgaben |
| Time | 1 | flach | 1 | Zeiterfassungs-Settings (Zweck offen) |
| Transactions | 1 | flach | 1 | Transaktionen je Benutzer (Zweck offen) |
| VoucherManagement | 1 | flach | 1 | Gutschein-Barcodes per NamedQuery (Hypothese) |
| ExternalHelpdesk | 1 | flach | 1 | Config-CRUD je Kunde/Kundenort |
| ExternalToolsBL | 1 | flach | 1 | externe Tools mit Variablenersetzung |
| ItPlanner | 1 | flach | 1 | virtuelle Checklistenkategorien-Sync |
| ObjectExternalReferences | 1 | flach | 1 | typisierte Fremdsystem-Referenzen |
| Telemetry | 1 | flach | 1 | Telemetrie-Buckets mit Upload-Markierung |
| WebVersion | 1 | flach | 1 | Versionsauskunft |
| Reporting | 1 | flach | 1 | Legacy-Report-BLOB-Verwaltung |
| Gateway | 1 | flach | 1 | Custom-Gateway openTRANS (Hypothese) |
| Customizations | 1 | flach | 1 | Custom-Tabellen-Platzhalter |
| MailScanner | 1 | flach | 1 | VMA-Profile recht+verschlüsselt |
| SystemArea | 1 | flach | 1 | Systemzähler-Einzelinstanz |
| ArtificialIntelligence | 25 | mittel | 1 | KI-Chat-Historie; Provider-Familie (OpenAI/Gemini/Mistral/Claude) |
| Accounting | 1 | flach | 0 | BankAccount-CRUD inkl. Belegrückgriff (gelesen, keine eigene Requirement) |
| BusinessPartner | 2 | flach | 0 | Lieferanten-Suche/Anlagen-Buchungen (gelesen; Datenmodell in StRS-005) |
| Core | 2 | flach | 0 | CryptoUtils, Variablen-Ersetzung (gelesen) |
| Exceptions | 1 | flach | 0 | TicketExpiredException (gelesen) |
| GUI | 6 | flach | 0 | UserGrid/ImportOrder/UiProfile (APIs gelesen) |
| Helpers | 6 | flach | 0 | Graph/PDF/Word/Image-/String-Helfer (APIs gelesen) |
| Mobile | 1 | flach | 0 | MobileEmployee-Lesen inkl. Bild (gelesen) |
| Start | 1 | flach | 0 | Mapping-Start/ConnectionString (gelesen) |
| Storage | 2 | flach | 0 | StorageBL komplett auskommentiert („obsolete"), nur statischer InventoryArticlePool |
| Tools | 1 | flach | 0 | ToolBL nur ChangeTextFormat (gelesen) |
| ChangeTracking | 1 | flach | 0 | ImportHistoryBL; Kernlistener liegt unter Centron.DAO |
| CentronNexus | 1 | flach | 0 | Nexus-Settings Get/Update (gelesen) |
| CentronIcons | 2 | flach | 0 | Icon-/Ressourcenbestand ohne Fachlogik |
### 2.2 Persistenz und Verträge
| Modul | Stufe | Anf. | Kernsatz |
|---|---|---|---|
| Centron.DAO (Mappings, NamedQueries, Repositories, ChangeTracking, UserTypes) | tief | 10 | ORM-Konventionen, Query-Pool, Audit-/Historie-Erzeugung |
| Centron.Entities (1179 Dateien) | mittel | 4 | I3D-/Legacy-Abbildung, ObjectType-Nummern, Audit-Basisklasse |
| Centron.Interfaces | mittel | 2 | Contract-First-Schicht (Details nur oberflächlich) |
| Centron.Common | flach | 1 | Querschnittsbibliothek Logging/Netzwerk/Codierung |
| src\shared\Centron.Core (TotpAuth) | flach | 1 | TOTP-Bibliothek |
| SSMS_DB_SCHEMA.sql | mittel | 5 | RechKopf/RechPos, Zahkond, cvw_InvoiceDunnings als Datenbasis |
### 2.3 Webservice (5 Projekte)
| Modul | Stufe | Anf. | Kernsatz |
|---|---|---|---|
| Centron.Host (Host-Regie, Auth-Schemas, TicketHandler) | tief | 6 | globales RequireAuthorization, HttpSys/Kestrel, Dienstbetrieb |
| Centron.Controllers (Authorization-Filter, API-Versionierung, GlobalExceptionFilter) | tief | 4 | 401/403-Filter, Namespace-Versionierung, 500-Pfad |
| Centron.WebServices.Core (CentronWebService-Client) | flach | 1 | RESTC-Kanal, Kompression, Proxy |
| Centron.Host.WindowsService | flach | 1 | Fehlerkapselung OnStart/OnStop |
| c-entron.misc.ConnectionManager | flach | 1 | Diagnose-Werkzeug |
### 2.4 Nexus (6 Bereiche)
| Modul | Stufe | Anf. | Kernsatz |
|---|---|---|---|
| CentronNexus.Host (Program.cs) | tief | 3 | Cookie+OIDC-Registrierung, iframe/Cookie-Middleware |
| WebCart (Kundenportal) | tief | 6 | Port-/Loginzwang, Sortiment, Preis, Prüfstufe, Ticketseiten |
| ServiceBoard | mittel | 3 | Login-/Lizenz-/Portschutz, Kanban, TicketCache |
| Shared (Auth, TicketCache, NotificationHub, SignalR) | tief | 6 | Open-Redirect-Schutz, AuthController, Push-Zustellung |
| Office (PdfController/FilePreview) | flach | 1 | Cache-PDF-Auslieferung |
| DocumentSigning + WebOffer | mittel | 3 | Signatur-/Akzeptanzstrecke, tokenierte Angebotsseite |
### 2.5 Desktop (1 Modul) und APIs (9 Adapter)
| Modul | Stufe | Anf. | Kernsatz |
|---|---|---|---|
| Centron.WPF.UI (Shell, Login, Module, Finances-Masken) | tief | 6 | Single-Instance, Login-Gate, Layout/Pflichtfelder/Feldvalidierung |
| Centron.Api.Gls | flach | 2 | Sendungsupload mit Vorabvalidierung |
| Centron.Api.Shipcloud | flach | 1 | Sendungsanlage/Carrier-Abruf |
| Centron.Api.EbInterface | flach | 1 | eb:interface 4.3 (AT) |
| Centron.APIs.CopDataAccess | flach | 1 | SOAP-Session-Produktdaten |
| Centron.APIs.EgisDataAccess | flach | 2 | EGIS-Artikelsuche |
| Centron.APIs.FinAPI | flach | 1 | PSD2-Bankdaten |
| Centron.APIs.IcecatDataAccess | flach | 1 | Produktinhalte je EAN |
| Centron.APIs.ITscopeDataAccess | flach | 2 | Produkte/Angebote/Deals |
| Centron.Api.docuFORM | flach | 1 | Gerätezähler OAuth2-PKCE |
### 2.6 Dokumentation/Modelle
| Artefakt | Stufe | Anf. | Kernsatz |
|---|---|---|---|
| README.md | flach | 2 | WebCart-Zieldefinition |
| CentronRights.md | flach | 2 | Semantik einschränkender Rechte |
### 2.7 Abdeckungsblatt (Stufen je Komponente)
| Stufe | Module | Anteil |
|---|---|---|
| tief | 8 (Administration, Sales, DAO, Centron.Host, Controllers, WebCart, Shared, WPF-UI) | 6,8 % |
| mittel | 24 | 20,5 % |
| flach | 85 | 72,6 % |
| nicht analysiert | 0 | 0 % |
Damit ist jede Inventarzeile mindestens flach erfasst; tiefe Durchdringung liegt planmäßig bei Sicherheit, Abrechnung, Portal und Plattform.
## 3. Risikorelevante Anforderungen (Sicherheit, Abrechnung, Berechtigungen)
Prüfregel: jede riskante Anforderung hat PRIMÄR-Beleg der Durchsetzungsstelle **oder** ist als HYPOTHESE markiert. Ergebnis: 32/32-Sicherheitsanforderungen erfüllt (30 mit PRIMÄR, 2 als HYPOTHESE markiert).
### 3.1 Zugriff & Authentifizierung (PRIMÄR-belegt)
StRS-004 (AppRightsBL, AppUserGroupBL), SyRS-001 (UserRightAuthorizationFilter), SyRS-002 (TwoFactorAuthBL/RadiusClient/EmailValidator), SyRS-003 (CentronHostedHandler), SyRS-004 (DataSecurityBL), SyRS-005 (Authenticator/LicenseManager/TicketBL), SyRS-006 (TicketAuthenticationHandler + RequireAuthorization), SyRS-007 (Nexus Program.cs/AuthController), StRS-006/SyRS-016/SyRS-018 (ReceiptCartBL-Guards), SwRS-001 (AppRightsBL fail-closed), SwRS-003 (BasicAuthenticator), SwRS-018 (OrderCommissionBL), SwRS-024 (ProductionBL), SwRS-044 (ServiceBoard _Imports), SwRS-051 (AuthController Redirect), SwRS-053/054 (TicketAuthenticationHandler), SwRS-066/070 (docuFORM PKCE, MailScanner), SwRS-077 (VideoPortalAssignmentBL), SwRS-107 (DocumentationBL), SwRS-127 (HelpdeskBL.CheckUserRigths), SwRS-129 (FrontWindow.Login), SwRS-040 (ReceiptCartBL Rechte-/Prüfstufenguard, nachgetragen), SwRS-008 (PasswordManagerBL), SwRS-009 (DataSecurityBL Anonymisierung).
### 3.2 Sicherheit mit Hypothesenstatus (offene Erzwingerstelle)
SwRS-004 (2FA-PIN: Erzwingerstelle im Login-Ablauf offen), SwRS-005 (Alt-Passwortnutzung offen), SwRS-006 (Rechtsprüfung bei Signatur-Settings offen), SwRS-007 (Datenfilter „nur eigene Tickets" auf BL-Seite offen), SwRS-055 (TOTP-Prüfstelle offen), SyRS-019/020/021 (Token-Lebenszyklus, Servervalidierung, Cache-Id-Zugriff).
### 3.3 Abrechnung/Berechtigung (PRIMÄR-belegt)
StRS-003/StRS-011/StRS-016; SyRS-010 (ReceiptBL.UpdateReceiptNumber), SyRS-011 (HandleIsAlreadyExported/CancelInvoice), SyRS-012 (DunningRunBL transaktional), SyRS-013 (UpdateReceiptIsPaid mit ConcurrencyGuid), SyRS-014 (InvoiceSpecificLogic), SyRS-015/017 (ReceiptCartBL), SyRS-041 (Skonto), SwRS-010..014 (Storno/Preise), SwRS-019 (EK-Fortschreibung), SwRS-102 (PDF/A3), SwRS-108 (Textbausteine), SwRS-123 (Gutscheine, HYPOTHESE), SwRS-131 (Pflichtfelder).
## 4. Konsistenzprüfung (Ergebnis nach Bereinigung)
| Prüfpunkt | Ergebnis |
|---|---|
| Doppelte IDs | 0 (199 eindeutige IDs: StRS-001..016, SyRS-001..049, SwRS-001..134, lückenlose Sequenzen) |
| Anforderungen ohne Belege | 0 |
| Anforderungen ohne Übernahmewürdigkeit | 0 |
| Verwaiste Trace-Links | 0 (vor Bereinigung: 0 toter Verweis, aber 29 semantisch falsche Eltern→Kind-Referenzen; alle korrigiert) |
| Kind→Elter-Rückwärtsverfolgung | vollständig (100 %) |
| Elter→Kind-Vorwärtsverfolgung | selektiv geführt; vollständige Rekonstruktion über Kind→Elter (in Traceability.md begründet) |
| Deckungsgleiches ohne Konsolidierungsmarkierung | 0 aufgefundene Duplikatpaare bleiben unmarkiert; u.a. markiert: NumberGroupBL↔MandatoryBL (SwRS-099), AppSettings-Zwillinge (SyRS-029/SwRS-096), Abteilungs-Parallelimplementierung (SwRS-032), Alt-/Neu-Reports (SwRS-103), Portal-Rechtefamilie (SyRS-016..018) |
| Hypothesen-Abgleich | 23 Inline-Markierungen = 23 Einträge Hypothesen.md |
| Sicherheits-/Abrechnungsregeln | 32/32 mit PRIMÄR oder HYPOTHESE (siehe 3.) |
| Konsolidierungszähler StRS↔SyRS↔SwRS | Geschwisterlinks SyRS-010↔044, SyRS-039↔011 als Querverweise kenntlich gemacht |
## 5. Dünne Belegstellen (Nachsteuerung nötig)
1. Logik außerhalb des Quellcode-Bestands: DB-Prozeduren „SocialMedia.*" (SwRS-075), NamedQuery-SQL (SwRS-123), gespeicherte Sichten.
2. Erzwingerstellen nicht ablesbar: 2FA-PIN-Aufrufpfad (SwRS-004/055), PDF-Signatur-Settings (SwRS-006), WebCart-Ticketfilter (SwRS-007), Token-Erzeugung WebOffer (SyRS-019), Backend-Signaturvalidierung (SyRS-020), Cache-Id-Autorisierung (SyRS-021).
3. Zweck/Nutzung unklar: Projects, Transactions, Time/TimingSettings, VoucherManagement, ElectronicSales-Sync (SwRS-119/122/121/123/134), Alt-Passwortkeywords (SwRS-005).
4. Nebenläufigkeit/Risiken dokumentiert, aber nicht bewertet: Mahnlauf „Max+1" (SyRS-012), Auto-Sync bei Abfrage (SwRS-118), best-effort ChangeLog (SwRS-093).
## 6. Selbstbewertung (absolut)
- Erfasst: 199 Anforderungen; 16 StRS decken 100 % der SyRS-Eltern; jede SyRS hat 1–2 StRS-Eltern; 84 % der SwRS (113/134) nennen eine SyRS als direkten Elter, der Rest referenziert direkt die StRS (begründet: Ein-Modul-Funktionalitäten ohne Systemverhalten eigener Art).
- Belegt: 323 Belege, davon 256 PRIMÄR (Durchsetzungsstelle), 199/199 Anforderungen mindestens ein Beleg.
- Hypothesen: 23 (11,6 %), alle mit Prüffrage in Hypothesen.md; keine Requirement ohne Status.
- Verworfen/abgestuft statt „übernehmen": 31 Verdikte (Workaround 8, Sonderfall 7, veraltet 6, unklar 4, Mischungen 6).
- Modulinventar: 117 Zeilen, alle mit Kennsatz; Stufen: tief 8, mittel 24, flach 85, nicht analysiert 0.
- Bekannte Grenzen des Laufs: WebServices-Schicht (464 Klassen) nur strukturell; Entities/DAO nur stichprobenartig; ReportEngine, Calendar, Statistics, Warehousing nur anzapfend; DB-Prozeduren/NamedQuery-SQL nicht im Bestand; UI (WPF/Nexus-Seiten) nur an Belegstellen gelesen; Performanz-/Verfügbarkeits-NFVs außerhalb des Quellcodes nicht messbar (deshalb 0 Benchmark-Anforderungen).
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/Glossar.md
+95
View File
@@ -0,0 +1,95 @@
# Glossar
Fach- und Systembegriffe der c-entron ERP-Suite, wie aus den Artefakten abgeleitet. Links in eckigen Klammern zeigen auf prägende Anforderungen.
## Identität, Rechte, Lizenz
| Begriff | Bedeutung |
|---|---|
| I3D | Zentraler ganzzahliger Primärschlüssel aller Datenbankobjekte (allgegenwärtige Konvention `Id(a => a.I3D)`). [SyRS-034] |
| Employee | Personalstammdatensatz (Mitarbeiter); eigenständige Identität neben dem Zugang. [StRS-007] |
| AppUser | Interner Systemzugang (Login, Rechtegruppen, 2FA); per Mapping an einen Employee gebunden. [SwRS-029] |
| Web-Account | Portalzugang eines Endkunden; dritte Identitätsart mit eigener Rechtequelle WebRights. [StRS-006] |
| Recht / Rechtegruppe | Deklarierte Berechtigung, gruppenweise über Sichusr/Sichmemb an AppUser; Prüfung zentral über AppRightsBL.HasUserRight (Fail-closed). [SwRS-001] |
| Einschränkendendes Recht (restricting right) | Recht, das andere Rechte entzieht; in der Admin-Gruppe nur eingeschränkt zuweisbar. [StRS-004] |
| WebRights | Portalrechte (z. B. "Warenkorb bestellen", "Tickets abschließen"), serverseitig erzwungen. [SyRS-018] |
| Lizenz / CentronInternal | Modulare Lizenzpflicht; interne Funktionen nur mit CentronInternal-Lizenz. [SyRS-003] |
| Sitzungsticket | Zeitlich begrenztes Authentifizierungsticket je Anwendung (30/5/1440 Minuten). [SyRS-005] |
| Access-Token | Personengebundener API-Nachweis (Bearer/access_token), mit Client-Kontext validiert. [SwRS-002, SwRS-054] |
| 2FA / TOTP | Zweitfaktor per RADIUS, E-Mail-Link (Login) oder TOTP-Bibliothek (Schlüssel). [SyRS-002, SwRS-004, SwRS-055] |
| Masterkey | AES-Master-Passwort der Konfigurations-DB zum Entschlüsseln von Secrets. [SyRS-030] |
## Organisation und Mandantenmodell
| Begriff | Bedeutung |
|---|---|
| Mandant | Rechtlich-organisatorische Oberinstanz mit eigenem Default-Land und Nummernkreisen. [StRS-009, StRS-016] |
| Filiale (Branch) | Unterhalb des Mandanten mit genau einem Default-Lager plus Sekundärlagern. [StRS-010] |
| Inlandsland | Über den Default-Mandanten deterministisch abgeleitetes Steuer-/Preisland. [SwRS-042] |
| Account / Kunde / Lieferant | Neuer, maßgeblicher Adressstamm (Account*, AccountCustomer, AccountSupplier) als Migrationsziel der Altstämme Customer/Address/Supplier. [StRS-005] |
## Beleg- und Zahlungswesen
| Begriff | Bedeutung |
|---|---|
| Beleg / Belegart | Urkundentypisiertes Fachobjekt mit Kopf/Positionen (Tabelle RechKopf/RechPos), nummernkreis- und pflichtgeführt. [StRS-003, StRS-016] |
| Belegfluss / Herkunft | Verknüpfung Ursprungs→Folgebeleg über RechPos.UrsprungI3D/UrsprungArt. [SwRS-010] |
| Zahkond / Zahlungsbedingung | Zentral gepflegte Kondition mit Zahlungsziel und bis zu drei Skontostaffeln. [StRS-011] |
| Skonto | Skonto1..3 (Prozent/Tage) je Zahlungsbedingung, mit Textbaustein-Vorschau gegen Testrechnung. [SwRS-012, SwRS-034] |
| Mahnstufe | Eskalationsstufe None→1→2→3 im transaktionalen Mahnlauf über fällige aktive Rechnungen. [SyRS-012] |
| Opos | Offene Posten; Auswertung auf derselben Belegbasis wie der Mahnlauf. [StRS-003] |
| IsReceiptExported | Kennzeichnung "an Buchhaltung übergeben"; steuert Versionszwang und Stornoverbot. [SyRS-011] |
| Sonderpreis / Sondervereinbarung | Kundenindividuelle Artikelvereinbarung; begrenzt das Shop-Sortiment und die Nettopreisstellung. [SyRS-017, SyRS-015] |
| Preishierarchie | Preisfindung Vertrag > Sonderpreis > Staffelpreis, zweistufig gerundet. [SwRS-013, SwRS-014] |
## Helpdesk und Organisation
| Begriff | Bedeutung |
|---|---|
| Ticket (Helpdesk) | Servicevorgang mit Statusmaschine, SLA-Priorität, Historie und Abschluss-Checkliste. [StRS-013, SyRS-043, SwRS-127] |
| SLA-Priorität | Aus dem Servicevertrag erzwungene Ticketpriorität inkl. abgeleitetem Fälligkeitsdatum. [StRS-012] |
| Abschluss-Checkliste | Checkliste mit CanClose-Punkten; offen ⇒ Abschluss blockiert. [SwRS-127, SwRS-114] |
| ToDo / Wiedervorlage | Bereichsübergreifende Aufgabenliste mit über 30 registrierten Objektarten. [StRS-014] |
| ObjectKind / ObjectI3D / ObjectType | Typisierte Objektreferenz mit zentraler, unveränderlicher Typnummernliste. [SwRS-112] |
## Portal, Kanäle und Integrationen
| Begriff | Bedeutung |
|---|---|
| WebCart / Kundenportal | Endkunden-Selfservice (Shop, Warenkorb, Tickets, Dokumente) auf eigenem Port, nur Web-Account-Login. [SyRS-016] |
| Prüfstufe | Vier-Augen-Freigabe im Warenkorb (bereit zur Prüfung → geprüft). [SwRS-040] |
| ServiceBoard | Mitarbeiter-Browserarbeitsplatz im Nexus mit Login-, Lizenz- und Portschutz. [SwRS-044] |
| WebOffer | Loginfreie, token-gesteuerte Angebotsansicht. [SyRS-019] |
| SharedDocument / Signierstrecke | Token-basierte Dokumentenfreigabe mit Zeichnungs-/Typ-/Upload-Signatur (SEPA: IBAN-Pflicht). [SyRS-020] |
| RESTC | Standardisierter komprimierter REST-Kanal des Zentralklienten. [SyRS-025] |
| openTRANS | XML-Austauschformat für EDI-Bestellungen/Antworten; Custom-Gateway für Sonderfälle. [SyRS-045, SwRS-133] |
| ZUGFeRD / XRechnung / eb:interface | Normkonforme E-Rechnungsformate (DE/AT). [SyRS-040, SwRS-058] |
| Handelspool / EGIS / ITscope / Icecat / Cop | Distributor-/Poolquellen für Fremdarticlelnhalte und -preise. [SyRS-046] |
| c-pra | Externer Freigabe-/Workflowdienst (Nexoware Smartflow) mit Token-Login und Webhooks. [SwRS-115] |
| Riverbird / River Suite | Externes Ticketsystem mit Helpdesk-Gegenstelle und DB-/WebService-Trennregel. [SyRS-048, SwRS-098] |
| docuFORM | Gerätezähler-Fernübermittlung per OAuth2-PKCE. [SwRS-066] |
## Technik und Plattform
| Begriff | Bedeutung |
|---|---|
| WebServiceBL | Service-spezifische BL-Schicht der REST-Dienste (464 Klassen). [SyRS-028] |
| NamedQuery / NamedQueryPool | Zentral gepflegte SQL-/HQL-Abfragen statt SQL im Code. [SyRS-035] |
| DBUpdate / ScriptEngine | Versionsgesteuerte, idempotente Datenbankmigration mit Protokoll. [SyRS-023] |
| ChangeTracking / ChangeLog | Attributsgesteuerte Feldänderungs-Historie im Persistenzlayer (Update-only, best-effort). [SyRS-033, SwRS-093] |
| CreatedBy/CreatedDate/CreatedVersion | Auditfelder der DBEntity-Basisklasse, Repository-erzwungen. [SwRS-110] |
| Soft-Delete | Löschung durch Deaktivierung (IsActive/Deleted) statt Zeilenentfernung. [SwRS-023, SwRS-120] |
| Nummernkreis (NumberGroup) | Fortschreibender Zähler je Mandant/Filiale/Belegart mit Intervall und Delegation. [SyRS-044, SwRS-099] |
| HostedService / ExecuteServices | Hintergrunddienste, zentral per Konfigurationsflag schaltbar. [SyRS-022, SwRS-084] |
| TicketCache (Nexus) | Prozessweiter Singleton-Cache mit HostedService-Synchronisation. [SyRS-037] |
| AppSetting / ApplicationSetting | Zwei Settings-Generationen mit fehlertolerantem On-Demand-Default. [SyRS-029, SwRS-096] |
| DSGVO-Löschung / Anonymisierung | Rechtegebundene Nullung personenbezogener Ansprechpartnerfelder mit Löschprotokoll. [SyRS-004, SwRS-009] |
## Arbeitsbegriffe dieser Spezifikation
| Begriff | Bedeutung |
|---|---|
| PRIMÄR / SEKUNDÄR / KONTEXT | Belegklassen: Durchsetzungsstelle im Quelltext / Struktur- oder Modellbeleg / dokumentarischer Kontext. |
| HYPOTHESE | Status: fachliche Regel plausibel, aber Durchsetzung/Zweck nicht vollständig artefaktbelegt; offen in Hypothesen.md. |
| Übernahmewürdigkeit | Verdikt für das Migrationsziel: übernehmen / Workaround / Sonderfall / veraltet / unklar. |
| Konsolidierung | Markierung von Anforderungen, die inhaltlich zusammenzuführen sind (Duplikate/Parallelimplementierungen). |
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/Hypothesen.md
+102
View File
@@ -0,0 +1,102 @@
# Hypothesen-Liste
Enthält exakt die Anforderungen mit `Status: HYPOTHESE` aus StRS.md, SyRS.md und SwRS.md (Abgleich: 0 StRS, 5 SyRS, 18 SwRS = 23). Zu jeder Hypothese: Grund der Markierung und offene Frage zur Bestätigung.
## SyRS
### SyRS-019 – Token-basierte Angebotsansicht ohne Login
- Offen: Token-Erzeugung, Ablauf und Rate-Limiting sind nicht nachgewiesen; der Token-Erzeugungscode wurde nicht gefunden.
- Prüfen: Erzeugungsstelle des Receipt-Access-Tokens incl. Gültigkeitsdauer und Wiederverwendungsschutz.
### SyRS-020 – Signatur- und Akzeptanzstrecke für freigegebene Dokumente
- Offen: serverseitige Validierung außerhalb der UI (CanAccept) nicht nachgewiesen.
- Prüfen: Confirm/Decline-Endpunkte im Backend auf unabhängige Signatur-/IBAN-Prüfung.
### SyRS-021 – PDF-Auslieferung über gemeinsamen Office-Cache-Endpunkt
- Offen: Zugriffskontrolle auf Cache-Ids nicht sichtbar.
- Prüfen: `getcachedfile/{id}/{filename}` mit fremder/erratener Cache-Id (Authorisierung, Ratenbegrenzung).
### SyRS-025 – Standardisierter komprimierter REST-Kanal „RESTC"
- Offen: „unbegrenztes Timeout" nur durch Kommentar belegt.
- Prüfen: tatsächliche Timeout-/CancellationToken-Implementierung des CentronWebService-Clients.
### SyRS-039 – Buchhaltungsexport in austauschbare Zielsystemformate
- Offen: Detailregeln je Zielformat (DATEV, SAP, ...) nicht analysiert; nur Struktur und Default-Regel belegt.
- Prüfen: Format-Builder je Zielsystem inkl. Kontenfindung und Stornologik.
## SwRS
### SwRS-004 – Prüfung des personengebundenen Zwei-Faktor-Schlüssels
- Offen: aufrufende Erzwingerstelle im Login-Ablauf nicht nachgewiesen.
- Prüfen: alle Login-Endpunkte/Masken daraufhin, ob `ValidateAuthenticationPin` zwingend aufgerufen wird.
### SwRS-005 – Alt-Passwortverwaltung (Keywords) – Migrationsbedarf
- Offen: keine Belege für aktive Nutzung (UI-/Aktivierungsnachweis fehlt).
- Prüfen: Referenzsuche nach Konsumenten; Entsorgung entscheiden.
### SwRS-006 – Elektronische PDF-Signatur mit geschützter Zertifikatskonfiguration
- Offen: Rechtsprüfung beim Pflegen der Signatur-Einstellungen nicht im Detail verifiziert.
- Prüfen: Save-Pfad von `PdfSigningBL` auf Rights-Guard.
### SwRS-007 – Ticketansichten im Kundenportal nach Web-Rechten differenzieren
- Offen: eigentliche Datenfilterung „nur eigene Tickets" nicht im Detail nachgewiesen.
- Prüfen: BL-Seite der Ticketlisten im WebCart auf WebAccount-/Vertriebsgebietsfilter.
### SwRS-035 – Preis- und Rabatttransparenz im Shop
- Offen: Priorisierung von Sondervereinbarungen innerhalb der Preisfindung nicht vollständig nachverfolgt.
- Prüfen: `ReceiptPriceHelper`-Kette bei gleichzeitiger Sondervereinbarung + Staffelpreis.
### SwRS-036 – SelfCare-Formular erzeugt Helpdesk-Ticket
- Offen: Trigger→Ticket-Ausführungskette nicht vollständig verfolgt.
- Prüfen: ActionHandler-Kette vom Formular-Save bis zur Helpdesk-Anlage.
### SwRS-046 – Fertigungsübersicht mit Arbeitsplatz- und Mitarbeiterauswahl
- Offen: fachliche Vervollständigung unklar.
- Prüfen: Rückfrage an Fachbereich Produktion; Seiten-Rohtext lesen.
### SwRS-054 – Client-Kontext (IP, API-Methode) in der Access-Token-Validierung
- Offen: konkrete IP-/Methoden-Bindungsregel in `AccessTokenBL.ValidateToken` nicht eingesehen.
- Prüfen: ValidateToken-Quelltext inkl. Edge Cases (Proxy-IP, Methodswechsel).
### SwRS-055 – TOTP-Zwei-Faktor-Bibliothek im Plattformkern
- Offen: erzwungene Prüfstelle im Login-Pfad nicht gezeigt.
- Prüfen: Konsumenten von `Totp.cs` im Anmelde-/Einstellungen-Pfad.
### SwRS-056 – Schnittstellenmodul als Contract-First-Schicht
- Offen: Einzelinterface-Inhalte nur oberflächlich geprüft.
- Prüfen: Stichprobe der Interface-Definitionen gegen Implementierungen.
### SwRS-057 – Gemeinsame Querschnittsbibliothek (Logging, Settings, Netzwerk, Codierung)
- Offen: Detailverhalten der Klassen nicht gelesen.
- Prüfen: AESCryptoLogic-Schlüsselherkunft und Logging-Rotation.
### SwRS-075 – Interne Social-Media-Kommentare/Likes über gespeicherte Prozeduren
- Offen: Kernlogik liegt in DB-Prozeduren, deren Inhalt nicht im Artefaktbestand liegt.
- Prüfen: Prozeduren „SocialMedia.*" aus SSMS-Export oder Server beschaffen.
### SwRS-119 – Projektliste mit Erstellungsdatumfilter (rumpfhaft)
- Offen: Save/Delete nirgends belegt; Modul möglicherweise auslaufend.
- Prüfen: Referenzsuche nach `ProjectBL`-Konsumenten.
### SwRS-121 – Zeiterfassungs-Stammeinstellungen pflegen
- Offen: fachlicher Zweck der Settings nicht ableitbar (keine Konsumenten belegt).
- Prüfen: Konsumenten von `TimingSetting` identifizieren (Timer/CTime).
### SwRS-122 – Benutzerbezogene Transaktionen mit Kategorie-Details
- Offen: Verwendungszweck nicht aus Artefakten belegt.
- Prüfen: UI-/Webservice-Konsumenten der TransactionBL.
### SwRS-123 – Aktive Gutschein-Barcodes per NamedQuery
- Offen: SQL im NamedQuery-Pool; Zustandssemantik nicht verifizierbar.
- Prüfen: NamedQuery `VoucherManagementGetVoucherArticles` + Flags gegen Testdaten.
### SwRS-133 – Custom-Gateway-BL für kundenindividuelle openTRANS-Integrationen
- Offen: Methodenumfang nicht gelesen; REST-Aufrufverbindung nur vermutet.
- Prüfen: `CustomGatewayBL`-Methoden und `CentronRestService.CustomGateway.cs` durchgehen.
### SwRS-134 – Externe ElectronicSales-Gruppen/Rollen lokal spiegeln
- Offen: eigentlicher Sync-Abruf liegt außerhalb des Moduls; End-to-End-Verhalten unbelegt.
- Prüfen: Sync-Initiator (Hintergrunddienst/Webservice) identifizieren.
## Begründung der Hypothesen-Quote
Die 23 Hypothesen betreffen überwiegend (a) Logik außerhalb des Quellcode-Bestands (DB-Prozeduren, NamedQuery-SQL, externe Systeme), (b) nicht gelesene Konsumenten-/Erzwingerstellen und (c) möglicherweise auslaufende Module. Alle Sicherheits- und Abrechnungsanforderungen mit zweifelhaftem Durchsetzungsbeleg sind markiert; keine StRS-Hypothese, weil jede StRS mehrere unabhängige PRIMÄR-Belege hat.
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/StRS.md
+345
View File
@@ -0,0 +1,345 @@
# StRS - Stakeholder Requirements Specification
Quelle: c-entron ERP-Suite (Reverse Requirements Engineering, ISO/IEC/IEEE 29148:2018).
Alle Pfade relativ zum Arbeitsverzeichnis. Belegklassen: PRIMÄR / SEKUNDÄR / KONTEXT.
---
ID: StRS-001
Titel: Ein gemeinsames ERP-System für alle Fachprozesse
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: ERP-Anwender (Vertrieb, Einkauf, Lager, Service, Finanzen)
Vorbedingung: Client ist gestartet, Benutzer ist angemeldet
Fakt: WPF-Shell `FrontWindow` exportiert `OpenModule/CloseModule/DockModule`; unter `src\centron\Centron.WPF.UI\Modules\` existieren 29 Fachmodule (Finances, Helpdesk, Warehousing, Production, ...), jedes mit Modul-Controller; das Webfront CentronNexus ergänzt Browser-Zugriffe.
Aussage: Das System soll alle ERP-Fachprozesse (Angebot bis Rechnung, Einkauf bis Lager, Helpdesk bis Finanzen) in einer gemeinsamen, modular erweiterbaren Anwendung bereitstellen.
Ergebnis: Alle Fachbereiche sind über eine Shell mit öffn-/schließbaren Modulen erreichbar; kein Fachbereich läuft als Insellösung.
Belege:
- [PRIMÄR] src\centron\Centron.WPF.UI\FrontWindow.xaml.cs, OpenModule/CloseModule/DockModule - Begründung: zentraler Modulvertrag der Gesamtleistung
- [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\ (29 Modulordner), src\centron\Centron.WPF.UI.Extension\Modules\ICentronAppModule.cs - Begründung: Modularchitektur als Systemprinzip
Prüfidee: Jedes der 29 Fachmodule lässt sich ohne Neustart öffnen, andocken und schließen.
Tracelinks: SyRS-024, SyRS-025, SyRS-026, SyRS-027, SyRS-028
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - modulare Gesamt-ERP-Idee ist das tragende Produktversprechen
Status: belegt
---
ID: StRS-002
Titel: Endkunden wickeln Bestellung und Service selbstständig im Kundenportal ab
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Endkunde eines c-entron-Kunden (Web-Account), Kundenadministrator
Vorbedingung: Mandant hat WebCart-Lizenz, Kunde besitzt Sonderpreise und Web-Accounts
Fakt: README: "The webcart is a feature primarily intended for the customers of our customers"; Portal unter `/customerportal` mit Tickets, Formularen, Dokumenten, Belegen/Verträgen sowie Shop/Warenkorb; Bestell-/Prüfrechte werden serverseitig in `ReceiptCartBL` erzwungen.
Aussage: Das System soll Endkunden den kompletten Selbstbedienungspfad (Sonderpreis-Sortiment → Warenkorb → Bestellung, Tickets/Formulare/Dokumente) ohne ERP-Benutzer öffnen, wobei der Kundenadministrator Rechte und Benutzer selbst verwaltet.
Ergebnis: Bestellungen und Servicevorgänge erreichen das ERP ohne manuelle Erfassung durch den c-entron-Kunden.
Belege:
- [SEKUNDÄR] README.md, Zeilen 31-36 - Begründung: dokumentiertes Ziel des WebCart
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs, Rechte-/Portprüfungen (Zeilen 133, 859-864) - Begründung: der Selbstbedienungspfad ist serverseitig erzwungen implementiert
- [SEKUNDÄR] src\nexus\CentronNexus\WebCart\CustomperPortalHomePage.razor, Route `/customerportal` - Begründung: Portalbündel als eigene Startseite
Prüfidee: Durchlauf ohne ERP-Benutzer: Shop-Suche → Warenkorb → Bestellung mit Bestellrecht; Formular erzeugt Helpdesk-Ticket.
Tracelinks: SyRS-016, SyRS-017, SyRS-018, SyRS-019, SyRS-020, SyRS-021
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zentrales Wachstums-/Entlastungsziel
Status: belegt
---
ID: StRS-003
Titel: Lückenloser, nachvollziehbarer Belegfluss vom Ursprungsbeleg bis zum Mahnlauf
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Debitorenbuchhaltung
Vorbedingung: Auftrag oder Lieferschein mit Positionen existiert
Fakt: `ReceiptProgressionBL.GetRelatedItemsForObject` ermittelt Ursprungs-/Folgebelege über `RechPos.UrsprungI3D/UrsprungArt`; `InvoiceSpecificLogic` deklariert `CanBeForwardedFrom/Into`; Mahnwesen/Opos greifen auf dieselbe RechKopf-Basis zu (View `cvw_InvoiceDunnings`).
Aussage: Das System soll jeden Beleg über seine Positionsherkunft lückenlos mit Ursprungs- und Folgebelegen verknüpfen und diese Kette für Fakturierung, Mahnwesen und Debitorensteuerung nutzbar machen.
Ergebnis: Zu jeder Rechnung sind Vorbelege und Weiterverarbeitungen eindeutig bestimmbar; nur überfällige aktive Rechnungen erreichen Mahn-/Opos-Läufe.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptProgressionBL.cs, GetRelatedItemsForObject/CreateOriginReceiptsSql - Begründung: Belegkette technisch über alle Belegarten erzwungen
- [SEKUNDÄR] src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs, CanBeForwardedFrom/Into (Zeilen 279-280) - Begründung: definierte Übergänge des Belegflusses
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, View [dbo].[cvw_InvoiceDunnings] - Begründung: Auswertungen setzen auf derselben Belegbasis auf
Prüfidee: Auftrag → Rechnung; beide erscheinen im Belegfluss; bezahlte Rechnung taucht im Mahnlauf nicht auf.
Tracelinks: SyRS-012, SyRS-013, SyRS-014, SyRS-039, SyRS-040, SyRS-041
Konsolidierung: Kandidat: Sammelthema "Belegfluss Auftragsabwicklung" mit Lieferschein/RMA-Verzweigungen (ReceiptProgressionBL)
Übernahmewürdigkeit: übernehmen - tragendes Prinzip der Auftragsabwicklung
Status: belegt
---
ID: StRS-004
Titel: Wer darf was - selbstverwaltetes Rechte- und Lizenzmodell mit Selbstschutz
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Benutzer mit Recht UserRightsManagement; Administratoren
Vorbedingung: Anmeldung an der c-entron-Verwaltung
Fakt: `AppRightsBL.SaveRightGroup` prüft `HasUserRight(UserRightsManagement)` und bei `MANAGE_RIGHTS_ONLY_OWN_BRANCH` die Filialzugehörigkeit; `DeleteRightGroup` verbietet das Löschen der Gruppe I3D==6/"Administratoren"; in der Admin-Gruppe sind nur freigegebene einschränkende Rechte zuweisbar.
Aussage: Das System soll das Anlegen, Ändern und Löschen von Rechtegruppen nur berechtigten Benutzern gestatten, bei Filialbindung auf die eigene Filiale beschränken und die Administratorengruppe gegen Löschung/Entrechtung schützen.
Ergebnis: Nicht berechtigte/filialfremde Anfragen werden abgewiesen; Admin-Gruppe bleibt erhalten.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs, SaveRightGroup/DeleteRightGroup - Begründung: exakte Durchsetzungsstellen inkl. Bedingungen
- [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppUserGroupBL.cs, IsAdministratorGroupI3D (`groupI3D == 6`) - Begründung: harter Admin-Gruppenschutz
- [SEKUNDÄR] CentronRights.md, Abschnitt "This is a restricting right" - Begründung: Fachsemantik einschränkender Rechte
Prüfidee: Benutzer ohne UserRightsManagement legt Gruppe an → Fehler; Admin-Gruppe löschen → Fehler; filialfremde Gruppe bei MANAGE_RIGHTS_ONLY_OWN_BRANCH → Fehler.
Tracelinks: SyRS-001, SyRS-002, SyRS-003, SyRS-004, SyRS-005, SyRS-006, SyRS-007, SyRS-008, SyRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - klare Gewaltenteilung und Selbstschutzregel
Status: belegt
---
ID: StRS-005
Titel: Ein maßgeblicher Adress-/Kundenstamm statt paralleler Datenhaltungen
Ebene: StRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Datenverantwortliche, Systemarchitektur
Vorbedingung: Altstruktur (Customer/Address/ContactPerson) und neuer Account-Stamm koexistieren
Fakt: Entities `CustomerArea\Customer.cs` (DeliveryConditionI3D) und `Accounts\AccountCustomer.cs` (ReceiptConditionDeliveryI3D) führen Parallelfelder; `Supplier` (Businesspartner) und `AccountSupplier` (Accounts) führen Frachtfelder doppelt; `AccountMigrationBL` nutzt NamedQuery "MigrateWebAccountsFromOldCustomerStructure".
Aussage: Das System soll Kunden-, Liefer- und Ansprechpartnerdaten an einer maßgeblichen Stelle (Account-Stamm) führen; das Zielsystem überführt die Altbestände (CustomerArea, Supplier) und legt sie still.
Ergebnis: Ein Kundenstamm mit einer Konditionenquelle; keine Divergenz zwischen Supplier.Name und Account.Name/Frachtsätzen.
Belege:
- [PRIMÄR] src\backend\Centron.Entities\Entities\CustomerArea\Customer.cs, DeliveryConditionI3D - Begründung: Altmodell mit Konditionsfeldern
- [PRIMÄR] src\backend\Centron.Entities\Entities\Accounts\AccountCustomer.cs, ReceiptConditionDeliveryI3D - Begründung: Neumodell mit denselben Fachmerkmalen
- [PRIMÄR] src\backend\Centron.BL\Accounts\AccountMigrations\AccountMigrationBL.cs, MigrateWebAccountsFromOldCustomerStructure - Begründung: dokumentierter Migrationslauf Alt→Neu
- [PRIMÄR] src\backend\Centron.Entities\Entities\Businesspartner\Supplier.cs vs. src\backend\Centron.Entities\Entities\Accounts\AccountSupplier.cs - Begründung: doppelter Lieferantendatenbestand
Prüfidee: Zähl-Query: Module, die noch Customer/Address (alt) lesen, vs. Account/AccountAddress; Ziel: Differenz = 0.
Tracelinks: SwRS-027, SwRS-028, SwRS-031, SwRS-132
Konsolidierung: Kandidat: Muster "zwei Datenhaltungen für denselben Fachgegenstand" wie beim Prompt-Beispiel Drucker-Stammblätter vs. Assets
Übernahmewürdigkeit: Workaround - Parallelhaltung ist Migrations-Zustand, Ziel ist der eine Stamm
Status: belegt
---
ID: StRS-006
Titel: Web-Accounts sehen ausschließlich Daten ihres eigenen Kunden
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Endkunde (Web-Account-Login)
Vorbedingung: Web-Account ist mit Account/Customer verknüpft
Fakt: `AccountAddressBL` erzwingt `filter.AccountI3Ds = { WebAccount.AccountI3D }`; `AccountSearchBL` filtert bei `IsWebAccountLogin` auf `WebAccount.CustomerI3D`; `ReceiptCartBL.SearchArticles` begrenzt auf `WebAccount.CustomerI3D` (Zeilen 228-244).
Aussage: Das System soll jede Adress-, Konto-, Beleg- und Artikelsuche im Kundenportal zwingend auf den Stammkunden des angemeldeten Web-Accounts einschränken.
Ergebnis: Kunden sehen im Self-Service nur eigene Daten; Mandantendaten bleiben abgeschottet.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Accounts\AccountAddressBL.cs, Filterzwang (Zeilen 75-79) - Begründung: erzwungener Mandantenzwang
- [PRIMÄR] src\backend\Centron.BL\Accounts\AccountSearchBL.cs, IsWebAccountLogin-Filter (Zeilen 294-299) - Begründung: gleiche Regel zweite Stelle
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs, Zeilen 228-244 - Begründung: Kundenisolierung im Shop
Prüfidee: Webservice-Aufruf mit Web-Account-Token; fremde Kunde-I3D im Filter muss ignoriert/abgewiesen werden.
Tracelinks: SyRS-016, SyRS-017, SyRS-018
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zentrale Mandantentrennung des Portals
Status: belegt
---
ID: StRS-007
Titel: Personalstamm (Employee) und Zugang (AppUser/Web-Account) sind getrennte Identitäten
Ebene: StRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Administration, System
Vorbedingung: Employee existiert; Zugangsdaten werden unabhängig gepflegt
Fakt: `AppUserBL.GetAppUserObjectForEmployee(employeeId)`/`GetAppUserI3DForEmployee` mappen Mitarbeiter→Login; `SaveOrUpdateAppUser` führt separates Passwortargument; Web-Accounts sind dritte Identitätsart mit eigener Rechtequelle (`WebRights`).
Aussage: Das System soll Personalstammdaten und Zugangsdaten als getrennte Konzepte mit definierter Zuordnung führen, damit Passwort-/Lizenzverwaltung den Personalstamm nicht ändert.
Ergebnis: Sperrung/Änderung eines Zugangs ohne Eingriff in Personaldaten; drei Akteursidentitäten (Employee, AppUser, Web-Account) sauber unterscheidbar.
Belege:
- [PRIMÄR] src\backend\Centron.BL\EmployeeArea\AppUserBL.cs, GetAppUserObjectForEmployee - Begründung: explizite Mapping-Methoden belegen Zwei-Konzept-Design
- [SEKUNDÄR] src\backend\Centron.BL\NexusTicketViews\NexusTicketViewBL.cs, Doku zu geteiltem I3D-Bereich von Employee/Web-Account - Begründung: Identitäten teilen sich Nummernkreise, daher Typ needed
Prüfidee: AppUser eines Employees sperren; Employee-Daten bleiben lesbar, Zugriffe des Logins scheitern.
Tracelinks: SwRS-029, SwRS-032, SwRS-052
Konsolidierung: Kandidat: Identitätskonzepte Employee/AppUser/Web-Account im Zielsystem auf ein Identitätsmodell führen
Übernahmewürdigkeit: übernehmen - saubere Rollen-/Identitätstrennung
Status: belegt
---
ID: StRS-008
Titel: Verfügbarkeit und Rolle des Mitarbeiters steuern die Arbeitsverteilung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mitarbeiter, Disponent
Vorbedingung: Mitarbeiter ist aktiv (`IsActiveEmployeeCompact`-Prüfung)
Fakt: `EmployeeBL` bietet `SetDispatcher`, `IsActiveEmployeeCompact`, `UpdateEmployeeAvailability(employeeI3D, EmployeeAvailability)`.
Aussage: Das System soll je Mitarbeiter eine schaltbare Verfügbarkeit und eine Dispatcher-Eigenschaft führen und diese vor weiterleitungsrelevanten Aktionen (Ticketweitergabe, Zuteilung) prüfen.
Ergebnis: Tickets/Aufgaben erreichen nur verfügbare, rollengerecht eingestellte Mitarbeiter.
Belege:
- [PRIMÄR] src\backend\Centron.BL\EmployeeArea\EmployeeBL.cs, SetDispatcher/UpdateEmployeeAvailability/IsActiveEmployeeCompact (Zeilen 67-127) - Begründung: Steuerungsmethoden inkl. Aktivitätsprüfung
Prüfidee: Inaktiven Mitarbeiter als Dispatcher setzen → Fehlerresult; Zuweisung an Abwesenden verhindert.
Tracelinks: SyRS-002
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: StRS-009
Titel: Deterministische Länder-, Währungs- und Inlandsbasis
Ebene: StRS
Typ: Daten
Qualitätsmerkmal:
Akteur: _any user; Buchhaltung
Vorbedingung: Default-Mandant mit Land gepflegt; genau ein Defaultland markiert
Fakt: `CountryBL.GetInlandCountry` liefert `MandatorBL.GetDefaultMandator().Country` (offenes TODO zur Filialland-Prüfung); `GetDefaultCountry` filtert `f.Default`; `UpdateCurrencyRateByRateDictionary` importiert EZB-Kurse.
Aussage: Das System soll das für Preise/Steuern maßgebliche Inlandsland deterministisch aus dem Default-Mandanten ableiten und tagesaktuelle Wechselkurse je Währung bereitstellen.
Ergebnis: Belege, Steuern und Fremdwährungspreise rechnen auf einer eindeutigen Länderbasis.
Belege:
- [PRIMÄR] src\backend\Centron.BL\CountryArea\CountryBL.cs, GetInlandCountry/GetDefaultCountry - Begründung: Implementierung inkl. TODO als bekannte Lücke
- [PRIMÄR] src\backend\Centron.BL\CountryArea\CountryBL.cs, UpdateCurrencyRateByRateDictionary (EZB-XML) - Begründung: Kursimport durchgesetzt
Prüfidee: Default-Mandant auf zweites Land setzen; Inlandslogik neuer Belege folgt dem neuen Land.
Tracelinks: SwRS-041, SwRS-042
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen (TODO Filialland als Nachsteuerung)
Status: belegt
---
ID: StRS-010
Titel: Filial- und Lagerstruktur je Mandant
Ebene: StRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Administration, Logistik
Vorbedingung: Mandant mit Filialen angelegt
Fakt: `BranchBL.SaveAssignedSecondaryStocks` verwaltet je Filiale genau ein Default-Lager plus Sekundärlager atomar; `GetBranchesForSelection` stellt Pseudo-Einträge "Hauptsitz"/"Alle Filialen" bereit.
Aussage: Das System soll Mandanten, Filialen und Lager mit je genauem Default-Lager je Filiale abbilden und in allen Masken einheitlich auswahlbar machen.
Ergebnis: Deterministische Lager- und Filialzuordnung von Belegen, Beständen und Benutzern.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Administration\Company\BranchBL.cs, SaveAssignedSecondaryStocks (Zeilen 72-154) - Begründung: Default-Lager-Rotation im Transaktionsblock
- [PRIMÄR] src\backend\Centron.BL\Administration\Company\BranchBL.cs, GetBranchesForSelection/IsBranchEqual - Begründung: einheitliche Filialfilter-Semantik
Prüfidee: Zweites Default-Lager setzen → altes entfällt; Filialauswahl enthält genau einen "Alle Filialen"-Eintrag.
Tracelinks: SwRS-030, SwRS-031
Konsolidierung: Kandidat: Organisationskonzepte Firma (Company) vs. Mandant vs. Filiale zusammenführen
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: StRS-011
Titel: Zahlungs- und Lieferkonditionen zentral pflegen, Skonto aussteuerbar
Ebene: StRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Finanz-/Einkaufsabteilung
Vorbedingung: Masterdatenpflege geöffnet
Fakt: `AssetCondition` führt bis zu drei Skonto-Staffeln (Skonto1..3 OffDay/Percent) mit verwalteten Texten; `AssetConditionBL.GetAssetConditionTextPreview` rendert Platzhalter gegen eine Testrechnung und meldet Fehler ohne Rechnungsbestand.
Aussage: Das System soll Zahlungs-/Lieferkonditionen mit Skonto-Staffeln zentral pflegen, in Belege, Textbausteine und E-Rechnung übernehmen und die Auswirkung per Vorschau verifizierbar machen.
Ergebnis: Einheitliche Konditionen für Belege/Materialgruppen; Fälligkeit und Skonto sind aus einer Quelle abgeleitet.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Administration\Masterdata\AssetConditionBL.cs, GetAssetConditionTextPreview (Zeilen 34-55) - Begründung: Skonto-Feldsemantik und Fehlerpfad belegt
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[Zahkond] mit Skonto1/Skonto2, LaenPer1..3 - Begründung: Datenmodell der Skontostufen
Prüfidee: Zahlungsbedingung "2 % / 14 Tage, netto 30"; Rechnung speichern → Fälligkeit und Skontotext stimmen; E-Rechnung enthält SKONTO-Angaben.
Tracelinks: SyRS-013, SyRS-015, SyRS-040, SyRS-041, SwRS-012, SwRS-013, SwRS-014, SwRS-034
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: StRS-012
Titel: SLA-Zusagen aus Serviceverträgen verbindlich durchsetzen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Helpdesk-Bearbeiter, Kunde mit Servicevertrag
Vorbedingung: Ticket einem Servicevertrag zugeordnet
Fakt: `UpdateHelpdeskBL.UpdatePriority` verwirft abweichende Prioritäten ("Die Priorität wird durch den gewählten Vertrag vorgegeben."); `GetDueDateFromPriority` leitet das Fälligkeitsdatum ab; `HelpdeskPriority.IsSLA` und `Contract.SLAPriority` verknüpfen Vertrag und Ticket.
Aussage: Das System soll bei SLA-Verträgen die Ticketpriorität verbindlich aus dem Vertrag ableiten und daraus das Fälligkeitsdatum automatisch berechnen; manuelle Abweichungen sind unzulässig.
Ergebnis: Verträge werden eingehalten; Fälligkeit/Priorität springen automatisch bei Vertragswechsel; Beteiligte werden benachrichtigt.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Sales\Support\UpdateHelpdeskBL.cs, UpdatePriority (Zeilen 281-326), SetContract (Zeilen 430-455) - Begründung: Durchsetzungsstellen der SLA-Kette
- [SEKUNDÄR] src\backend\Centron.Entities\Entities\CustomerArea\Support\HelpdeskPriority.cs, IsSLA - Begründung: SLA-Kennzeichen im Datenmodell
Prüfidee: SLA-Vertrag setzen, abweichende Priorität wählen → Fehler; Vertragswechsel → Priorität+DueDate springen.
Tracelinks: keine abgeleitete Anforderung - SLA-Kette abschließend in UpdateHelpdeskBL belegt
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zentrales Service-Vermarktungsmerkmal
Status: belegt
---
ID: StRS-013
Titel: Nachvollziehbare Ticketbearbeitung mit beschränkter Sichtbarkeit
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Interne Bearbeiter, Kunde (Web-Account)
Vorbedingung: Ticket existiert, Benutzer angemeldet
Fakt: `HelpdeskBL.GetHelpdeskRequest` prüft Vertriebsgebietsrechte (`EmployeeToSalesAreaBL`) und blendet `IsOnlyInternalVisible`-Tickets für Web-Logins mit einheitlichem Fehler "Ticket nicht gefunden!" aus.
Aussage: Das System soll Ticketzugriff nach internen Rechten (Vertriebsgebiet) und Kanälen (Kunde/sichtbarkeit) steuern, ohne Kunden die Existenz interner Tickets zu verraten, und jede Statusänderung historisieren.
Ergebnis: Berechtigte sehen Tickets, Unberechtigte erhalten einen einheitlichen Nicht-gefunden-Fehler; Statushistorie ist vollständig.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs, GetHelpdeskRequest (Zeilen 113-146) - Begründung: Rechte-/Kanalfilter durchgesetzt
- [PRIMÄR] src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs, SetHelpdeskAction (Zeilen 558-609) - Begründung: Statushistorie im Speicherpfad
Prüfidee: Web-Account öffnet internes Ticket → CouldNotFindData; fremdes Vertriebsgebiet → RightCheckFailed; Statuswechsel erzeugt Historieneintrag.
Tracelinks: SyRS-037, SyRS-038, SyRS-043, SyRS-048, SwRS-043, SwRS-045, SwRS-047, SwRS-049, SwRS-050, SwRS-127
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: StRS-014
Titel: Wiedervorlagen und Aufgaben über alle Fachbereiche bündeln
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: alle Fachbereiche
Vorbedingung: Quellvorgang (Beleg, Helpdesk, Urlaub, Kommissionierung ...) erzeugt Wiedervorlage
Fakt: `ToDoBL.FillObjectKindsListe` registriert über 30 `ToDoObjectKind`-Einträge (Name, Area, AssetKind); `TaskManagementTaskBL.SaveOrUpdateTask` erzwingt valide Aktion/Wiederkehr und Lizenz.
Aussage: Das System soll Wiedervorlagen aller Fachbereiche in einer strukturierten ToDo-Liste mit Typ/Bereich/Objektbezug führen und wiederkehrende Aufgaben nur bei valider, lizenzierter Aktion anlegen.
Ergebnis: Ein Einstiegspunkt zeigt bereichsübergreifende Aufgaben; keine defekten oder unlizenzierten Automationen.
Belege:
- [PRIMÄR] src\backend\Centron.BL\ToDoArea\ToDoBL.cs, FillObjectKindsListe (Zeilen 69-118) - Begründung: zentraler Typkatalog
- [PRIMÄR] src\backend\Centron.BL\TaskManager\TaskManagementTaskBL.cs, SaveOrUpdateTask (Zeilen 40-97) - Begründung: Validierungs-/Lizenzprüfung
Prüfidee: ToDo je registriertem Typ anlegen → in Liste mit korrektem Bereichstext; Aufgabe mit ungültiger Wiederkehr → Fehlerresult.
Tracelinks: SwRS-074, SwRS-077, SwRS-079
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: StRS-015
Titel: Nachvollziehbarkeit von Datenänderungen (Wer, Was, Wann)
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit / Sicherheitsfunktionalität (ISO 25010)
Akteur: Prüfer, Fachanwender, System
Vorbedingung: Änderung an getracktem Objekt durch angemeldeten Benutzer
Fakt: `ChangeTrackingEventListener` (NHibernate IPreUpdateEventListener) schreibt je geänderter Property Alt-/Neuwert, Benutzer und Datum in `ChangeLog`; Repositories belegen CreatedBy/CreatedDate/CreatedVersion automatisch; Soft-Delete plus Log Tabellen (Geräte, Umlagerungen, Belegprotokolle) ergänzen.
Aussage: Das System soll Änderungen an als überwachungswürdig deklarierten Feldern automatisch mit Alt-/Neuwert, Benutzer und Zeitpunkt protokollieren und Herkunftsfelder (Ersteller/-zeitpunkt/-version) beim Anlegen zwangsläufig setzen.
Ergebnis: Auditgrundlage ohne Fachcode; Löschung erfolgt,revidierbar per Soft-Delete mit Log.
Belege:
- [PRIMÄR] src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs, OnPreUpdate/CreateChangeLog (Zeilen 52-142) - Begründung: zentrale, automatische Protokollierung
- [PRIMÄR] src\backend\Centron.DAO\Repositories\Accounts\AccountRepository.cs, CreateNewAccount (Zeilen 39-52) - Begründung: Auditfelder im Repository-Muster
Prüfidee: Getrackte Property ändern → genau ein ChangeLog-Satz mit korrektem Benutzer; Neuanlage setzt CreatedVersion = Assemblyversion.
Tracelinks: SyRS-004, SyRS-033, SwRS-020, SwRS-023, SwRS-047, SwRS-082, SwRS-086, SwRS-093, SwRS-094, SwRS-110
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Audit-Basis; Lücken (kein Insert/Delete-Tracking) im Zielsystem schließen
Status: belegt
---
ID: StRS-016
Titel: Lückenlose, prüfsichere Nummernvergabe (GoBD)
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Funktionale Sicherheit (ISO 25010)
Akteur: System bei jeder Beleg-/Stammdatenanlage
Vorbedingung: Nummernkreise je Mandant/Filiale gepflegt
Fakt: `NumberGroupBL.GetNextNumber` vergibt und fortschreibende Nummern je Mandant/Filiale; `MandatoryBL` priorisiert filialbezogene Kreise vor dem Standardmandanten und überspringt verbrauchte (`Aktuell<=0`); Vergabe ohne manuelle Eingabe in allen Belegarten.
Aussage: Das System soll alle Nummern (Belege, Adressen, Ticketprojekte) fortlaufend, lückenlos und mandanten-/filialbezogen aus Nummernkreisen vergeben, ohne dass Benutzer Nummern setzen können.
Ergebnis: Keine Doppelvergabe; Nummerierung ist revisionssicher und je Mandant/Filiale getrennt.
Belege:
- [PRIMÄR] src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs, GetNextNumber/CreateNumberGroups - Begründung: zentrale Vergabestelle
- [PRIMÄR] src\backend\Centron.BL\Administration\Mandatory\MandatoryBL.cs, GetNumberGroup (ORDER BY Mandantenpriorität) - Begründung: Delegation Mandant→Filiale→Standard
Prüfidee: Paralleles Neuanlegen → keine Duplikate, Zähler monoton; Filiale mit eigenem Kreis wird vor Standardmandant gezogen.
Tracelinks: SyRS-010, SyRS-039, SyRS-044, SwRS-026, SwRS-099, SwRS-120
Konsolidierung: Kandidat: Nummernkreislogik (Company) und Nummernkreis-Delegation (Mandatory) zusammenführen
Übernahmewürdigkeit: übernehmen - GoBD-Kernanforderung
Status: belegt
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/SwRS.md
+2740
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/SyRS.md
+1033
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/Traceability.md
+224
View File
@@ -0,0 +1,224 @@
# Traceability-Matrix
Rückwärts-/Vorwärtsverfolgung über alle 199 Anforderungen (16 StRS, 49 SyRS, 134 SwRS).
„Verfolgung" = Inhalt des Feldes Tracelinks im jeweiligen Anforderungsblock; „Hauptartefakt" = erster PRIMÄR-Beleg (sonst SEKUNDÄR/KONTEXT). Alle Pfade relativ zum Arbeitsverzeichnis.
## StRS-Ebene
| StRS-ID | Titel | Verfolgung (abgeleitete Anforderungen) | Hauptartefakt |
|---|---|---|---|
| StRS-001 | Ein gemeinsames ERP-System für alle Fachprozesse | SyRS-024, SyRS-025, SyRS-026, SyRS-027, SyRS-028 | src\centron\Centron.WPF.UI\FrontWindow.xaml.cs |
| StRS-002 | Endkunden wickeln Bestellung und Service selbstständig im Kundenportal ab | SyRS-016, SyRS-017, SyRS-018, SyRS-019, SyRS-020, SyRS-021 | README.md (SEKUNDÄR); ReceiptCartBL.cs (PRIMÄR) |
| StRS-003 | Lückenloser, nachvollziehbarer Belegfluss vom Ursprungsbeleg bis zum Mahnlauf | SyRS-012, SyRS-013, SyRS-014, SyRS-039, SyRS-040, SyRS-041 | src\backend\Centron.BL\Sales\Receipts\ReceiptProgressionBL.cs |
| StRS-004 | Wer darf was – selbstverwaltetes Rechte- und Lizenzmodell mit Selbstschutz | SyRS-001, SyRS-002, SyRS-003, SyRS-004, SyRS-005, SyRS-006, SyRS-007, SyRS-008, SyRS-009 | src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs |
| StRS-005 | Ein maßgeblicher Adress-/Kundenstamm statt paralleler Datenhaltungen | SwRS-027, SwRS-028, SwRS-031, SwRS-132 | src\backend\Centron.Entities\Entities\CustomerArea\Customer.cs |
| StRS-006 | Web-Accounts sehen ausschließlich Daten ihres eigenen Kunden | SyRS-016, SyRS-017, SyRS-018 | src\backend\Centron.BL\Accounts\AccountAddressBL.cs |
| StRS-007 | Personalstamm (Employee) und Zugang (AppUser/Web-Account) sind getrennte Identitäten | SwRS-029, SwRS-032, SwRS-052 | src\backend\Centron.BL\EmployeeArea\AppUserBL.cs |
| StRS-008 | Verfügbarkeit und Rolle des Mitarbeiters steuern die Arbeitsverteilung | SyRS-002 | src\backend\Centron.BL\EmployeeArea\EmployeeBL.cs |
| StRS-009 | Deterministische Länder-, Währungs- und Inlandsbasis | SwRS-041, SwRS-042 | src\backend\Centron.BL\CountryArea\CountryBL.cs |
| StRS-010 | Filial- und Lagerstruktur je Mandant | SwRS-030, SwRS-031 | src\backend\Centron.BL\Administration\Company\BranchBL.cs |
| StRS-011 | Zahlungs- und Lieferkonditionen zentral pflegen, Skonto aussteuerbar | SyRS-013, SyRS-015, SyRS-040, SyRS-041, SwRS-012, SwRS-013, SwRS-014, SwRS-034 | src\backend\Centron.BL\Administration\Masterdata\AssetConditionBL.cs |
| StRS-012 | SLA-Zusagen aus Serviceverträgen verbindlich durchsetzen | keine abgeleitete Anforderung (SLA-Kette abschließend in UpdateHelpdeskBL belegt) | src\backend\Centron.BL\Sales\Support\UpdateHelpdeskBL.cs |
| StRS-013 | Nachvollziehbare Ticketbearbeitung mit beschränkter Sichtbarkeit | SyRS-037, SyRS-038, SyRS-043, SyRS-048, SwRS-043, SwRS-045, SwRS-047, SwRS-049, SwRS-050, SwRS-127 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
| StRS-014 | Wiedervorlagen und Aufgaben über alle Fachbereiche bündeln | SwRS-074, SwRS-077, SwRS-079 | src\backend\Centron.BL\ToDoArea\ToDoBL.cs |
| StRS-015 | Nachvollziehbarkeit von Datenänderungen (Wer, Was, Wann) | SyRS-004, SyRS-033, SwRS-020, SwRS-023, SwRS-047, SwRS-082, SwRS-086, SwRS-093, SwRS-094, SwRS-110 | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
| StRS-016 | Lückenlose, prüfsichere Nummernvergabe (GoBD) | SyRS-010, SyRS-039, SyRS-044, SwRS-026, SwRS-099, SwRS-120 | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs |
## SyRS-Ebene
| SyRS-ID | Titel | Eltern (StRS) | Kinder | Hauptartefakt |
|---|---|---|---|---|
| SyRS-001 | API-Aufrufe nur mit deklariertem Benutzerrecht | StRS-004 | SwRS-001, SwRS-002 | src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs |
| SyRS-002 | Mehrstufiger Anmeldeprozess mit Zweitfaktor (RADIUS oder E-Mail-Link) | StRS-004, StRS-008 | SwRS-003, SwRS-004 | src\backend\Centron.BL\Administration\Logins\TwoFactor\TwoFactorAuthBL.cs |
| SyRS-003 | Lizenz- und Hosted-Schranke für interne Funktionen und Modulzugriffe | StRS-004 | SwRS-006, SwRS-024 | src\webservice\Centron.Controllers\Authorization\CentronHostedAuthorization.cs |
| SyRS-004 | DSGVO-Löschung personenbezogener Daten nur für Berechtigte, mit Protokoll | StRS-004, StRS-015 | SwRS-009 | src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs |
| SyRS-005 | Ticketvergabe nach Rechts- und Lizenzprüfung, zeitlich befristet | StRS-004 | SwRS-003 | src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs |
| SyRS-006 | Every REST request must pass ticket/token authentication | StRS-004 | SwRS-002, SwRS-053, SwRS-054 | src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs |
| SyRS-007 | Nexus-Host authentifiziert per Cookie/Ticket oder OIDC und stellt Sitzung aus | StRS-004 | SwRS-044, SwRS-051 | src\nexus\CentronNexus.Host\Program.cs |
| SyRS-008 | Umschaltung der Systemauthentifizierung auf OpenID Connect (Entra ID) | StRS-004 | – | src\nexus\CentronNexus\Configuration\OpenIdConnectConfigurationService.cs |
| SyRS-009 | Outlook-AddIn-Einbettung mit iframe-fähiger Cookie-Policy | StRS-004 | – | src\nexus\CentronNexus.Host\Program.cs |
| SyRS-010 | Fortlaufende Rechnungsnummern je Nummernkreis | StRS-016, StRS-003 | SyRS-044 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
| SyRS-011 | Rechnungsexport-Kennzeichnung steuert Änderung und Storno | StRS-003 | SwRS-011 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
| SyRS-012 | Mahnlauf: stufenweise Eskalation überfälliger Rechnungen, transaktional | StRS-003 | – | src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs |
| SyRS-013 | Zahlungsstatus nur über zentralen, protokollierten Buchungspunkt | StRS-003, StRS-011 | – | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
| SyRS-014 | Belegweiterverarbeitung nur entlang definierter Regeln je Belegart | StRS-003 | SwRS-010 | src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs |
| SyRS-015 | Kundenindividuelle Preise im Web-Shop mit nachvollziehbarer Rabattanzeige | StRS-002, StRS-011 | SwRS-013, SwRS-035 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
| SyRS-016 | Kundenportal nur für Web-Account-Login über den Kundenportal-Port | StRS-002, StRS-006 | SwRS-007, SwRS-036 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
| SyRS-017 | Shop-Sortiment auf aktive Sonderpreise des Kunden beschränken | StRS-002, StRS-006 | – | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
| SyRS-018 | Warenkorb-Bestellung nur mit Web-Recht und Prüfstufe | StRS-002, StRS-006 | SwRS-040 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
| SyRS-019 | Token-basierte Angebotsansicht ohne Login | StRS-002 | – | src\backend\Centron.BL\WebServices\Sales\Receipts\ReceiptWebServiceBL.cs |
| SyRS-020 | Signatur- und Akzeptanzstrecke für freigegebene Dokumente | StRS-002 | – | src\nexus\CentronNexus\DocumentSigning\DocumentSigningPage.razor |
| SyRS-021 | PDF-Auslieferung über gemeinsamen Office-Cache-Endpunkt | StRS-002 | – | src\nexus\CentronNexus\Office\Controllers\PdfController.cs |
| SyRS-022 | Hintergrunddienste zentral über Konfigurationsflag steuerbar | StRS-001 | SwRS-084 | src\webservice\Centron.Host\CentronHost.cs |
| SyRS-023 | Versionsgesteuerte, idempotente Datenbankmigration mit Protokoll | StRS-001 | – | src\backend\Centron.BL\Administration\Scripts\ScriptEngineBL.cs |
| SyRS-024 | REST-API-Versionierung und einheitliche Fehlerbehandlung | StRS-001 | – | src\webservice\Centron.Host\AspNetCore\RegisterCentronApiVersioning.cs |
| SyRS-025 | Standardisierter komprimierter REST-Kanal „RESTC" | StRS-001 | – | src\webservice\Centron.WebServices.Core\Connections\CentronWebService.cs |
| SyRS-026 | Plattformabhängiger Webserver-Betrieb (HttpSys/Kestrel) | StRS-001 | – | src\webservice\Centron.Host\CentronHost.cs |
| SyRS-027 | Betrieb als Windows-Dienst mit Fehlerkapselung | StRS-001 | – | src\webservice\Centron.Host.WindowsService\CentronService.cs |
| SyRS-028 | Service-spezifische BL-Schicht (*WebServiceBL) | StRS-001 | – | src\backend\Centron.BL\WebServices\Administration\Logins\TicketWebServiceBL.cs |
| SyRS-029 | Zentrales Konfigurationswertesystem (AppSettings/ApplicationSettings) | StRS-001 | SwRS-096 | src\backend\Centron.BL\Administration\Settings\AppSettingsBL.cs |
| SyRS-030 | Zentrale Konfigurations-DB mit verschlüsseltem Hotline-Masterkey | StRS-004 | – | src\backend\Centron.BL\Administration\CentronConfigDb\CentronConfigurationDbBL.cs |
| SyRS-031 | WebService-Konfigurationsdatei mit verschlüsselten Geheimnissen | StRS-004 | – | src\backend\Centron.BL\Administration\WebServiceConfiguration\WebServiceConfigSerializer.cs |
| SyRS-032 | Client-Verbindungsprofile mit AES-verschlüsselten Passwörtern | StRS-004 | – | src\backend\Centron.BL\Administration\Connections\ConnectionBL.cs |
| SyRS-033 | Attributsgesteuerte Feldänderungs-Historie im Persistenzlayer | StRS-015 | – | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
| SyRS-034 | Einheitliches ORM-Mapping auf Legacy-Schema (PK I3D) | StRS-001 | – | src\backend\Centron.DAO\Mappings\BaseMaps.cs |
| SyRS-035 | Zentrale SQL-Abfragen in einem NamedQuery-Pool | StRS-001 | – | src\backend\Centron.DAO\NamedQueries\NamedQueryManager.cs |
| SyRS-036 | Rohe SQL-Zugriffe transaktionsgebunden über die ORM-Session | StRS-001 | – | src\backend\Centron.DAO\AdoNETDataAccess\RawSqlAccessDAO.cs |
| SyRS-037 | Serverseitiger Ticket-Cache mit Hintergrund-Synchronisation | StRS-013, StRS-001 | SwRS-048 | src\nexus\CentronNexus\Shared\Services\TicketCacheService.cs |
| SyRS-038 | Push-Zustellung von Benachrichtigungen per SignalR | StRS-013 | SwRS-049, SwRS-050 | src\nexus\CentronNexus\Shared\Services\SignalRNotificationsService.cs |
| SyRS-039 | Buchhaltungsexport in austauschbare Zielsystemformate | StRS-003, StRS-016 | SyRS-011, SwRS-067, SwRS-133 | src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs |
| SyRS-040 | Normkonforme E-Rechnungsformate (ZUGFeRD/XRechnung, eb:interface) | StRS-003, StRS-011 | – | src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs |
| SyRS-041 | Zahlungsziel- und Skontoermittlung aus der Zahlungsbedingung | StRS-003, StRS-011 | SwRS-012 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
| SyRS-042 | Statistik-Caches mit Selbstreparatur und Sofortaktualisierung | StRS-001 | SwRS-104 | src\backend\Centron.BL\Services\CachedTableBL.cs |
| SyRS-043 | Helpdesk-Statusmaschine als konfigurierbare Übergänge | StRS-013 | SwRS-043, SwRS-045, SwRS-047, SwRS-127 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
| SyRS-044 | Nummernkreis-Delegation Mandant→Filiale→Standard | StRS-016 | SyRS-010, SwRS-026, SwRS-099 | src\backend\Centron.BL\Administration\Mandatory\MandatoryBL.cs |
| SyRS-045 | Lieferanten-EDI: Bestellungen hinaus, Antworten herein | StRS-001, StRS-003 | SwRS-016, SwRS-065 | src\backend\Centron.BL\EDI\EDIDispatcherBL.cs |
| SyRS-046 | Fremddaten-Produktanreicherung über Distributor-/Poolschnittstellen | StRS-001 | – | src\apis\Centron.APIs.EgisDataAccess\EgisApi.cs |
| SyRS-047 | Paketversand über externe Carrier-Plattformen | StRS-001 | – | src\apis\Centron.Api.Gls\CentronGlsLogic.cs |
| SyRS-048 | Helpdesk-Gegenstelle für externes Ticketsystem (River Suite/Riverbird) | StRS-013 | – | src\backend\Centron.BL\RiverDivo\RiverDivoBL.cs |
| SyRS-049 | Mandanten-Installationsstatus und Installer-Download | StRS-001 | – | src\backend\Centron.BL\Administration\Portal\PortalWebServiceAccessBL.cs |
## SwRS-Ebene
| SwRS-ID | Titel | Eltern | Hauptartefakt |
|---|---|---|---|
| SwRS-001 | Zentrale, gecachte Rechtsprüfung mit Fail-closed-Semantik | SyRS-001, StRS-004 | src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs |
| SwRS-002 | Sichere Behandlung personengebundener API-Access-Tokens | SyRS-001, SyRS-006, StRS-004 | src\backend\Centron.BL\Administration\AccessTokens\AccessTokenBL.cs |
| SwRS-003 | Passwortanmeldung nur für aktive, nicht gesperrte Konten | SyRS-002, SyRS-005, StRS-004 | src\backend\Centron.BL\Administration\Logins\Auth\BasicAuthenticator.cs |
| SwRS-004 | Prüfung des personengebundenen Zwei-Faktor-Schlüssels | SyRS-002, StRS-004 | src\backend\Centron.BL\TwoFactorAuthenticator\TwoFactorAuthenticationBL.cs |
| SwRS-005 | Alt-Passwortverwaltung (Keywords) – Migrationsbedarf | SyRS-030, StRS-004 | src\backend\Centron.BL\PasswordManagementArea\PasswordManagementKeywordBL.cs (SEKUNDÄR) |
| SwRS-006 | Elektronische PDF-Signatur mit geschützter Zertifikatskonfiguration | SyRS-003, StRS-003 | src\backend\Centron.BL\Security\PdfSigningBL.cs |
| SwRS-007 | Ticketansichten im Kundenportal nach Web-Rechten differenzieren | SyRS-016, StRS-002 | src\nexus\CentronNexus\WebCart\CustomerTicketDetailsPage.razor (SEKUNDÄR) |
| SwRS-008 | Passwort-Manager: Export nur mit Recht, Lizenz und Masterkey | SyRS-003, SyRS-030, StRS-004 | src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs |
| SwRS-009 | Anonymisierung von Ansprechpartnern mit Löschprotokoll | SyRS-004, StRS-004 | src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs |
| SwRS-010 | Weiterverarbeitungsregeln und Herkunftsbindung je Belegart | SyRS-014, StRS-003 | src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs |
| SwRS-011 | Rechnungsstorno: Guard-Kette und historisierende Neufassung | SyRS-011, StRS-003 | src\backend\Centron.BL\Sales\Receipts\Invoices\ReceiptInvoiceBL.cs |
| SwRS-012 | Skontoberechnung und -text je Zahlungsbedingung | SyRS-041, StRS-011 | src\backend\Centron.BL\Administration\Masterdata\AssetConditionTextReplacementBL.cs |
| SwRS-013 | Preishierarchie der Belegposition (Vertrag > Sonderpreis > Staffelpreis) | StRS-011, SyRS-015 | src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs |
| SwRS-014 | Zweistufige Preisrundung mit artikelbezogener Genauigkeit | StRS-011, SyRS-040 | src\backend\Centron.BL\Sales\Receipts\ReceiptPriceHelperBL.cs |
| SwRS-015 | Distributoren automatisch bei Import anlegen | StRS-001 | src\backend\Centron.BL\Buying\External\DistributorBL.cs |
| SwRS-016 | Bestellvorschlagsliste aus öffentlichem Bedarf und Mindestbestand | StRS-001, SyRS-045 | src\backend\Centron.BL\Purchasing\OrderSuggestionList\OrderSuggestionListBL.cs |
| SwRS-017 | Bereichsübergreifender Export von Lieferantenrechnungen/Timerleistungen | StRS-003 | src\backend\Centron.BL\Purchasing\SupplierOrderPerBranchBL.cs |
| SwRS-018 | Rechteprüfung in Kommissionierung und Barcodeerzeugung | SyRS-001, StRS-004 | src\backend\Centron.BL\Warehousing\Commissions\OrderCommissionBL.cs |
| SwRS-019 | Fortschreibung des Artikel-EK aus Wareneingangspreisen | StRS-003, StRS-011 | src\backend\Centron.BL\Warehousing\StockManagement\ArticleStockBL.cs |
| SwRS-020 | Validierte Protokollierung von Lagerumlagerungen | StRS-015 | src\backend\Centron.BL\Logistics\Warehousing\StockBL.cs |
| SwRS-021 | Kunden-Produktmatrix mit Bewertungshistorie | StRS-001 | src\backend\Centron.BL\ProductMatrix\ProductMatrixBL.cs |
| SwRS-022 | Fertigungsaufträge nach Maschine/Maschinenart filterbar | StRS-001 | src\backend\Centron.BL\Production\ProductionOrderBL.cs |
| SwRS-023 | Geräteverwaltung mit Soft-Delete und Protokoll | StRS-015 | src\backend\Centron.BL\Devices\AccountDeviceBL.cs |
| SwRS-024 | Produktionsmanagement durchgehend lizenzgeprüft | SyRS-003, StRS-004 | src\backend\Centron.BL\Production\ProductionBL.cs |
| SwRS-025 | Handelspool-Artikelimport aus Distributor-XML | SyRS-046, StRS-001 | src\backend\Centron.BL\TradePool\Core\TradePoolXmlLogic.cs |
| SwRS-026 | Automatische Nummernvergabe für Account, Kunde und Lieferant | StRS-016, SyRS-044 | src\backend\Centron.BL\Accounts\AccountBL.cs |
| SwRS-027 | Genau eine Standardadresse je Account | StRS-005 | src\backend\Centron.BL\Accounts\AccountAddressBL.cs |
| SwRS-028 | Branchenzuweisungen atomar ersetzen | StRS-005 | src\backend\Centron.BL\CustomerArea\BusinessLineBL.cs |
| SwRS-029 | Explizite Zuordnung Employee → AppUser | StRS-007 | src\backend\Centron.BL\EmployeeArea\AppUserBL.cs |
| SwRS-030 | Filialauswahl mit Pseudo-Einträgen Hauptsitz/Alle Filialen | StRS-010 | src\backend\Centron.BL\Administration\Company\BranchBL.cs |
| SwRS-031 | Firmenübersicht als reines Lese-API | StRS-005, StRS-010 | src\backend\Centron.BL\Administration\CompanyInformations\CompanyBL.cs |
| SwRS-032 | Abteilungen benutzerbezogen laden und pflegen (Parallelimplementierung) | StRS-007 | src\backend\Centron.BL\Administration\Employees\EmployeeDepartmentBL.cs |
| SwRS-033 | Persistente persönliche Mitarbeitereinstellungen | StRS-001 | src\backend\Centron.BL\Administration\Employees\EmployeeSettingBL.cs |
| SwRS-034 | Konditionstextvorschau gegen echte Testrechnung | StRS-011 | src\backend\Centron.BL\Administration\Masterdata\AssetConditionBL.cs |
| SwRS-035 | Preis- und Rabatttransparenz im Shop | SyRS-015, StRS-002 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
| SwRS-036 | SelfCare-Formular erzeugt Helpdesk-Ticket | SyRS-016, StRS-002 | src\backend\Centron.BL\SelfCare\SelfCareBL.cs |
| SwRS-037 | Weblink-Aktion legt CRM-Aktivität für den Betreuer an | StRS-001 | src\backend\Centron.BL\WebLinks\WebLinkActionAccountActivityHandler.cs |
| SwRS-038 | Versionsauskunft des Webservices | StRS-001 | src\backend\Centron.BL\WebVersion\VersionBL.cs |
| SwRS-039 | Web-Einstellungen strikt nach Login-Art getrennt | StRS-006, StRS-001 | src\backend\Centron.BL\WebSuite\Administration\Settings\WebSettingBL.cs |
| SwRS-040 | Warenkorb-Prüfstufe und Kundenadmin-Oberfläche | SyRS-018, StRS-002 | src\nexus\CentronNexus\WebCart\Helpers\UserViewModel.cs (SEKUNDÄR) |
| SwRS-041 | Täglicher Devisenkursimport aus dem EZB-Feed | StRS-009 | src\backend\Centron.BL\CountryArea\CountryBL.cs |
| SwRS-042 | Inlandsland aus dem Default-Mandanten ableiten | StRS-009 | src\backend\Centron.BL\CountryArea\CountryBL.cs |
| SwRS-043 | Ticket-Statuswechsel per Drag-and-Drop im Kanban | SyRS-043, StRS-013 | src\nexus\CentronNexus\ServiceBoard\CachedTicketList\Components\KanbanBucket.razor |
| SwRS-044 | ServiceBoard-Seiten durch Login-, Lizenz- und Portschutz | SyRS-007, SyRS-003, StRS-013 | src\nexus\CentronNexus\ServiceBoard\_Imports.razor |
| SwRS-045 | Automatische Status-Defaults bei Anlage und Übernahme | SyRS-043, StRS-013 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
| SwRS-046 | Fertigungsübersicht mit Arbeitsplatz- und Mitarbeiterauswahl | StRS-001 | src\nexus\CentronNexus\ProductionOrderManagement\Pages\ProductionOrderOverView.razor |
| SwRS-047 | Lückenlose Ticketstatus-Historie im Speicherpfad | SyRS-043, StRS-013, StRS-015 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
| SwRS-048 | Prozessweiter Ticketcache im Nexus (Singleton + HostedService) | SyRS-037, StRS-013 | src\nexus\CentronNexus\Shared\Services\TicketCacheService.cs |
| SwRS-049 | NexusNotifications je Empfänger verwalten (Raw-SQL) | SyRS-038, StRS-013 | src\backend\Centron.BL\NexusNotifications\NexusNotificationsBL.cs |
| SwRS-050 | NotificationHub filtert pro Benutzer und unterscheidet Schedule-Typen | SyRS-038, StRS-013 | src\nexus\CentronNexus\Shared\Services\NotificationHub.cs |
| SwRS-051 | Nur lokale Redirect-Ziele bei An-/Abmeldung (Open-Redirect-Schutz) | SyRS-007, StRS-004 | src\nexus\CentronNexus\Shared\Auth\AuthController.cs |
| SwRS-052 | Ticket-Ansichten mit Besitzer- und Namensregeln | StRS-013, StRS-007 | src\backend\Centron.BL\NexusTicketViews\NexusTicketViewBL.cs |
| SwRS-053 | Ticketauthentifizierungs-Handler als Durchsetzungsstelle | SyRS-006, StRS-004 | src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs |
| SwRS-054 | Client-Kontext (IP, API-Methode) in der Access-Token-Validierung | SyRS-006, StRS-004 | src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs |
| SwRS-055 | TOTP-Zwei-Faktor-Bibliothek im Plattformkern | StRS-004 | src\shared\Centron.Core\TotpAuth\Totp.cs |
| SwRS-056 | Schnittstellenmodul als Contract-First-Schicht | StRS-001 | src\backend\Centron.Interfaces (Ordnerstruktur) |
| SwRS-057 | Gemeinsame Querschnittsbibliothek (Logging, Settings, Netzwerk, Codierung) | StRS-001 | src\backend\Centron.Common\Network\IpAddressHelper.cs |
| SwRS-058 | eb:interface-4.3-E-Rechnung für Österreich | SyRS-040, StRS-003 | src\apis\Centron.Api.EbInterface\EbInterfaceLogic.cs |
| SwRS-059 | GLS-Sendungsupload mit Vorabvalidierung | SyRS-047, StRS-001 | src\apis\Centron.Api.Gls\CentronGlsLogic.cs |
| SwRS-060 | Sendungsanlage und Carrier-Abruf über Shipcloud | SyRS-047, StRS-001 | src\apis\Centron.Api.Shipcloud\CentronShipcloudLogic.cs |
| SwRS-061 | Produktdaten per SOAP-Session vom Cop-System | SyRS-046, StRS-001 | src\apis\Centron.APIs.CopDataAccess\CopApi.cs |
| SwRS-062 | EGIS-Artikelsuche mit Preis und Verfügbarkeit | SyRS-046, StRS-001 | src\apis\Centron.APIs.EgisDataAccess\EgisApi.cs |
| SwRS-063 | PSD2-Bankdatenabruf über finapi | StRS-003, StRS-011 | src\apis\Centron.APIs.FinAPI\FinApiClient.cs |
| SwRS-064 | Icecat-Produktinhalte (Text/Bild/Specs) je EAN | SyRS-046, StRS-001 | src\apis\Centron.APIs.IcecatDataAccess\IcecatApi.cs |
| SwRS-065 | ITscope-Produkte, Angebote und Deals inkl. Archivierung | SyRS-046, SyRS-045 | src\apis\Centron.APIs.ITscopeDataAccess\ITscopeApi.cs |
| SwRS-066 | docuFORM-Gerätezähler über OAuth2-PKCE | StRS-001, StRS-003 | Centron.Api.docuFORM\DocuFormRestApiClient.cs |
| SwRS-067 | Eindeutige Standard-Exportkonfiguration je Mandant | SyRS-039, StRS-003 | src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs |
| SwRS-068 | E-Mail-Versand über austauschbare Protokollclients, Secrets verschlüsselt | StRS-001 | src\backend\Centron.BL\Mail\Factory\CentronMailFactory.cs |
| SwRS-069 | Mailing als vollständiges Aggregat laden | StRS-001 | src\backend\Centron.BL\Mailings\MailingDataBL.cs |
| SwRS-070 | MailScanner-Profile nur mit VMA-Recht, Passwörter verschlüsselt | SyRS-001, SyRS-030, StRS-004 | src\backend\Centron.BL\MailScanner\MailScannerBL.cs |
| SwRS-071 | Chat-Nachrichten: Mitgliederzugriff, Autorschaft, Löschschutz | StRS-001 | src\backend\Centron.BL\Chats\ChatBL.cs |
| SwRS-072 | Kundensuche im Outlook-AddIn über Gerätenummer | SyRS-035, StRS-001 | src\backend\Centron.BL\Outlook\OutlookAssetKindSearchBL.cs |
| SwRS-073 | CTI-Anruferidentifikation über mehrstufige Rufnummernsuche | StRS-001 | src\backend\Centron.BL\Tapi\PhoneCallBL.cs |
| SwRS-074 | Empfängerlisten je Objekt deckungsgleich halten, Meldungen auto-cleanupen | StRS-014 | src\backend\Centron.BL\Notifications\UserNotificationBL.cs |
| SwRS-075 | Interne Social-Media-Kommentare/Likes über gespeicherte Prozeduren | StRS-001 | src\backend\Centron.BL\SocialMedia\SocialMediaBL.cs |
| SwRS-076 | DocuBoard-Partner als konsistentes Aggregat speichern | StRS-001 | src\backend\Centron.BL\DocuBoard\AssetManagementPartnerBL.cs |
| SwRS-077 | Videozuweisungen rechtsgeprüft mit ToDo-Kopplung | StRS-014, StRS-004 | src\backend\Centron.BL\VideoPortal\VideoPortalAssignmentBL.cs |
| SwRS-078 | Terminanfrage-Antwort gegen Exchange-Kalender verarbeiten | StRS-001 | src\backend\Centron.BL\AppointmentRequests\AppointmentRequestBL.cs |
| SwRS-079 | Wiederkehrende Aufgaben nur mit valider Aktion und Lizenz | StRS-014 | src\backend\Centron.BL\TaskManager\TaskManagementTaskBL.cs |
| SwRS-080 | Kalenderdarstellung und Outlook-Synchronisation konfigurieren | StRS-001 | src\backend\Centron.BL\Calendar\CalendarBL.cs |
| SwRS-081 | Tagesplanungs-Batches mit gemeinsamer Kennung | StRS-001 | src\backend\Centron.BL\MyDay\MyDayBL.cs |
| SwRS-082 | Erwartete Ereignisse je Kunde mit Löschkaskade | StRS-015, StRS-001 | src\backend\Centron.BL\ExpectedEvents\ExpectedEventsBL.cs |
| SwRS-083 | Persönliche Dashboardcontainer je Benutzer | StRS-001 | src\backend\Centron.BL\MyCentron\Dashboard\DashboardContainerBL.cs |
| SwRS-084 | Hintergrunddienste namentlich erfassen und zentral aktivieren | SyRS-022, StRS-001 | src\backend\Centron.BL\Administration\BackgroundServices\BackgroundServiceBL.cs |
| SwRS-085 | SQL-Server-Betriebsdiagnostik für Administratoren | StRS-001 | src\backend\Centron.BL\Administration\SQLManagement\SQLManagementBL.cs |
| SwRS-086 | Automatische, referenzierte Objektverzeichnisse im Dokumentenmanagement | StRS-001, StRS-015 | src\backend\Centron.BL\Administration\FileManagement\DirectoryReferenceProviders\DirectoryReferenceProviderBase.cs |
| SwRS-087 | Theme-Verwaltung mit unantastbarem Standard-Theme | StRS-001 | src\backend\Centron.BL\Administration\Themes\ThemeBL.cs |
| SwRS-088 | Strukturierter Netzwerk-/SQL-Diagnosebericht | StRS-001 | src\backend\Centron.BL\Administration\NetworkDiagnostics\NetworkDiagnosticsBL.cs |
| SwRS-089 | Profilaufzeichnungen aufbewahrungsgesteuert aggregieren | StRS-001 | src\backend\Centron.BL\Administration\Profiling\ProfilerBL.cs |
| SwRS-090 | Telefonie-Einstellungen in drei Ebenen | StRS-001 | src\backend\Centron.BL\Administration\PhoneSettings\PhoneSettingsBL.cs |
| SwRS-091 | Benutzerdefinierte Modul-Eigenschaften ohne Schemaänderung | StRS-001 | src\backend\Centron.BL\Administration\Customization\ModuleCustomPropertyBL.cs |
| SwRS-092 | Custom-Tabellen mit Platzhalterbefüllung aus dem Fachobjekt | StRS-001 | src\backend\Centron.BL\Customizations\CustomTables\CustomTableBL.cs |
| SwRS-093 | ChangeLog-Schreibregeln des ChangeTracking-Listeners | SyRS-033, StRS-015 | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
| SwRS-094 | Wiederverwendbare Massenänderungs-Vorlagen | StRS-001, StRS-015 | src\backend\Centron.BL\MassUpdate\MassUpdateBL.cs |
| SwRS-095 | Prozessmodelle nur mit gültigen Schritttypen, atomar gespeichert | StRS-001 | src\backend\Centron.BL\Processes\ProcessBL.cs |
| SwRS-096 | Fehlende ApplicationSettings on-demand mit Default anlegen | SyRS-029, StRS-001 | src\backend\Centron.BL\Administration\Settings\AppSettingsBL.cs |
| SwRS-097 | Verbindungsdatei mit Fallbackkette und Trust-Optionen | SyRS-032 | src\backend\Centron.BL\Administration\Connections\ConnectionBL.cs |
| SwRS-098 | Registry-Präferenzen und Typ-Isolation WebService/DB | StRS-001 | src\backend\Centron.BL\Administration\Environments\RegistryBL.cs |
| SwRS-099 | Nummernkreis-Fortschreibung mit Intervall und Restzähler | SyRS-044, StRS-016 | src\backend\Centron.BL\Administration\Mandatory\MandatoryBL.cs |
| SwRS-100 | Versionsmeldung je Maschine/Benutzer mit Portal-Upload | SyRS-049, StRS-001 | src\backend\Centron.BL\Administration\Applications\ApplicationVersionBL.cs |
| SwRS-101 | Systemzähler als Einzelinstanz-Lieferant | StRS-001 | src\backend\Centron.BL\SystemArea\SystemTableI3DBL.cs |
| SwRS-102 | PDF-Ausgabestrategie mit PDF/A3-Pflicht-Fallback | StRS-003, StRS-001 | src\backend\Centron.BL\ReportEngine\PdfStategy\PdfStrategies.cs |
| SwRS-103 | Alt-Reportdefinitionen (Legacy "Reports") verwalten | StRS-001 | src\backend\Centron.BL\Reporting\ReportsBL.cs |
| SwRS-104 | Statistiken aus vorberechneten Cache-Tabellen mit Eigenstatistiken | SyRS-042, StRS-001 | src\backend\Centron.BL\Statistics\OrderStatistics\CacheOrderStatisticsBL.cs |
| SwRS-105 | Deutsche Volltextsuche mit Stemming UND-Verknüpfung | StRS-001 | src\backend\Centron.BL\IndexSearch\IndexSearchBL.cs |
| SwRS-106 | Telemetrie-Buckets mit Upload-Kennzeichnung | StRS-001 | src\backend\Centron.BL\Telemetry\TelemetryBL.cs |
| SwRS-107 | Interne Dokumentation nur mit Leseberechtigung | StRS-004 | src\backend\Centron.BL\DocumentationArea\DocumentationBL.cs |
| SwRS-108 | Spezifischster Textbaustein je Benutzer/Kunde ermitteln | StRS-011, StRS-003 | src\backend\Centron.BL\TextModuleArea\TextModuleBL.cs |
| SwRS-109 | Tags beim Verschlagworten reaktivieren | StRS-013 | src\backend\Centron.BL\Tags\TagsBL.cs |
| SwRS-110 | Auditfelder beim Anlegen über Repositories erzwingen | StRS-015 | src\backend\Centron.DAO\Repositories\Accounts\AccountRepository.cs |
| SwRS-111 | Feldlängen über typisierte UserTypes abbilden (Trunkierungsschutz) | StRS-001 | src\backend\Centron.DAO\UserTypes\TruncatedStringUserType.cs |
| SwRS-112 | Zentrale Objekttyp-Nummern als domänenübergreifender Standard | StRS-001 | src\backend\Centron.Entities\Entities\ObjectTypes\ObjectType.cs |
| SwRS-113 | KI-Chats strikt benutzergetrennt mit persistierter Historie | StRS-001 | src\backend\Centron.BL\Administration\ArtificialIntelligence\Chat\ArtificialIntelligenceChatBL.cs |
| SwRS-114 | Checklisten an Objekte mit Pflicht-Caption, atomar gespeichert | StRS-013 | src\backend\Centron.BL\CheckListArea\CentronChecklistBL.cs |
| SwRS-115 | Anbindung an c-pra (Nexoware Smartflow) | SyRS-046 | src\backend\Centron.BL\CPra\CPraConnectorBL.cs |
| SwRS-116 | Externe-Helpdesk-Konfiguration je Kunde/Kundenort | StRS-013 | src\backend\Centron.BL\ExternalHelpdesk\ExternalHelpdeskConfigurationBL.cs |
| SwRS-117 | Externe Tools mit Namenspflicht und Variablenersetzung | StRS-001 | src\backend\Centron.BL\ExternalToolsBL\ExternalToolBL.cs |
| SwRS-118 | Helpdesk-Typen/Kategorien automatisch als virtuelle Checklistenkategorien | StRS-013 | src\backend\Centron.BL\ItPlanner\ChecklistVirtualObjectCategoryBL.cs |
| SwRS-119 | Projektliste mit Erstellungsdatumfilter (rumpfhaft) | StRS-001 | src\backend\Centron.BL\Projects\ProjectBL.cs |
| SwRS-120 | Ticketprojekte mit eigener Nummer und Soft-Delete-Aufgaben | StRS-016, StRS-013 | src\backend\Centron.BL\TicketProjects\TicketProjectBL.cs |
| SwRS-121 | Zeiterfassungs-Stammeinstellungen pflegen | StRS-001 | src\backend\Centron.BL\Time\TimingSettingsBL.cs |
| SwRS-122 | Benutzerbezogene Transaktionen mit Kategorie-Details | StRS-001 | src\backend\Centron.BL\Transactions\TransactionBL.cs |
| SwRS-123 | Aktive Gutschein-Barcodes per NamedQuery | StRS-003 | src\backend\Centron.BL\VoucherManagement\VoucherManagementBL.cs |
| SwRS-124 | URLs als sichtbare, durchsuchbare Objekt-Links | StRS-001 | src\backend\Centron.BL\Urls\SimpleUrlBL.cs |
| SwRS-125 | Objekt↔Fremdsystem-Referenzen typisiert verwalten | StRS-001 | src\backend\Centron.BL\ObjectExternalReferences\ObjectExternalReferenceBL.cs |
| SwRS-126 | Modulstamm automatisch ergänzen, Favoriten je Mitarbeiter | StRS-001 | src\backend\Centron.BL\Modules\ModuleBL.cs |
| SwRS-127 | Ticketabschluss nur mit Recht und erledigter Abschluss-Checkliste | SyRS-043, StRS-013 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
| SwRS-128 | Single-Instance-Start der Desktop-Anwendung | StRS-001 | src\centron\Centron.WPF.UI\App.xaml.cs |
| SwRS-129 | Anmeldung als Pflicht-Gate vor der Arbeitsfläche | SyRS-002, StRS-004 | src\centron\Centron.WPF.UI\FrontWindow.xaml.cs |
| SwRS-130 | Modul-Layout je Benutzerprofil speichern/zurücksetzen | StRS-001 | src\centron\Centron.WPF.UI\FrontWindow.xaml.cs |
| SwRS-131 | Konfigurierbare Pflichtfelder in der Belegmaske | StRS-011, StRS-003 | src\centron\Centron.WPF.UI\Modules\Finances\Receipts\ReceiptViewModel.cs |
| SwRS-132 | Inline-Feldvalidierung E-Mail/IBAN in der Adressmaske | StRS-005 | src\centron\Centron.WPF.UI\Modules\Finances\Crm\Info\CrmInfoTabView.xaml.cs |
| SwRS-133 | Custom-Gateway-BL für kundenindividuelle openTRANS-Integrationen | SyRS-039, StRS-001 | src\backend\Centron.BL\Gateway\CustomGatewayBL.cs |
| SwRS-134 | Externe ElectronicSales-Gruppen/Rollen lokal spiegeln | StRS-001 | src\backend\Centron.BL\Integrations\EsCustomerGroupBL.cs |
## Hinweise zur Matrix
1. Die Verfolgung ist vollständig in Richtung Kind→Elter: jede Anforderung listet ihre Eltern in Tracelinks. In Richtung Elter→Kind werden die wesentlichen direkten Kinder genannt; SwRS, die nur eine StRS als groben Rahmen referenzieren, werden dort nicht repetitiv aufgelistet (Deduplizierung über die Kind→Elter-Spalten).
2. SyRS-010↔SyRS-044 und SyRS-039↔SyRS-011 sind Geschwisterlinks (Querverweise, keine Eltern-Kind-Beziehungen).
3. StRS-012 besitzt keine abgeleitete Anforderung; die Durchsetzung ist vollständig im PRIMÄR-Beleg (UpdateHelpdeskBL) dokumentiert.
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/OpenCode.log
View File
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/OpenCodeEvents.jsonl
+330
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Protokoll.md
+129
View File
@@ -0,0 +1,129 @@
# Messprotokoll – Iteration 16/qwen/qwen3.8-flash-next/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-02T13:11:02.2153173+02:00
- **Endzeit:** 2026-09-02T14:03:38.1060735+02:00
- **Dauer gesamt:** 00:52:32 (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):** `qwen/qwen3.8-flash-next`
- **Modell (tatsaechlich):** `qwen/qwen3.8-flash-next`
- **Kontrolle Modell:** bestanden
- **Effort:** `high` angefordert, **wirksam** (`effort_applied: true`)
- **Ablage:** `Iteration 16/qwen/qwen3.8-flash-next/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` = 13, `completed` = 13, `failed` = 0
- **Rollen:** {"explore": 13}
## Validierungsstichprobe
- **Stand:** entfaellt
## Verbrauch
| Messgroesse | Wert |
|---|---|
| Input-Tokens | 501.335 |
| Output-Tokens | 194.782 |
| Reasoning-Tokens | 68.781 |
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
| Agent-Turns | 71 |
**Tokens gesamt: 7.830.882.** 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 | 8,0 % |
| SyRS | 49 | 24,6 % |
| SwRS | 134 | 67,3 % |
| **Gesamt** | **199** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 95 | 47,7 % |
| Sicherheit | 32 | 16,1 % |
| nicht-funktional | 28 | 14,1 % |
| Schnittstelle | 26 | 13,1 % |
| Daten | 17 | 8,5 % |
| Datenschutz | 1 | 0,5 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 323 |
| davon `PRIMÄR` | 256 (79,3 %) |
| davon `SEKUNDÄR` | 66 (20,4 %) |
| davon `KONTEXT` | 1 (0,3 %) |
| Belege je Anforderung (Median) | 2 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 197 (99,0 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 171 | 85,9 % |
| workaround | 9 | 4,5 % |
| sonderfall | 12 | 6,0 % |
| veraltet | 4 | 2,0 % |
| (sonstige Angabe) | 3 | 1,5 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 176 | 88,4 % |
| als `HYPOTHESE` gekennzeichnet | 23 | 11,6 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 170 | 85,4 % |
| mit ISO-25010-Qualitätsmerkmal | 60 | 30,2 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (51 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 199 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 199 von 199 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
- **Session-ID:** `ses_f9e2f37dbffePXP0P4ACRLx8cN`
- **Werkzeugaufrufe:** 116 – {"bash": 50, "task": 13, "grep": 2, "write": 10, "read": 6, "edit": 35}
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 13
- **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/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/RawResult.json
+1225
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Stderr.log
+5
View File
@@ -0,0 +1,5 @@
[2026-09-02T11:11:03.761390+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\Ergebnisse)
[2026-09-02T11:11:03.862020+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=builtin; Effort=high (uebergeben=True); Stall-Timeout=0s
[2026-09-02T12:03:36.484593+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
[2026-09-02T12:03:38.004876+00:00] OpenCode export: Exporting session: ses_f9e2f37dbffePXP0P4ACRLx8cN
[2026-09-02T12:03:38.084502+00:00] Ende: Exitcode=0; Status=success; Turns=71; Tokens=7830882; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\RawResult.json
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/after.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/anforderungen.json
+3907
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/anforderungen.md
+67
View File
@@ -0,0 +1,67 @@
## 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 | 8,0 % |
| SyRS | 49 | 24,6 % |
| SwRS | 134 | 67,3 % |
| **Gesamt** | **199** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 95 | 47,7 % |
| Sicherheit | 32 | 16,1 % |
| nicht-funktional | 28 | 14,1 % |
| Schnittstelle | 26 | 13,1 % |
| Daten | 17 | 8,5 % |
| Datenschutz | 1 | 0,5 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 323 |
| davon `PRIMÄR` | 256 (79,3 %) |
| davon `SEKUNDÄR` | 66 (20,4 %) |
| davon `KONTEXT` | 1 (0,3 %) |
| Belege je Anforderung (Median) | 2 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 197 (99,0 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 171 | 85,9 % |
| workaround | 9 | 4,5 % |
| sonderfall | 12 | 6,0 % |
| veraltet | 4 | 2,0 % |
| (sonstige Angabe) | 3 | 1,5 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 176 | 88,4 % |
| als `HYPOTHESE` gekennzeichnet | 23 | 11,6 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 170 | 85,4 % |
| mit ISO-25010-Qualitätsmerkmal | 60 | 30,2 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (51 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 199 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 199 von 199 mit Tracelinks (100,0 %) |
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/before.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_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\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T14:03:38.1060735+02:00
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_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/qwen/qwen3.8-flash-next",
"permission": {
"*": "deny",
"read": "allow",
"glob": "allow",
"grep": "allow",
"list": "allow",
"edit": {
"*": "deny",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse/**": "allow"
},
"external_directory": {
"*": "deny",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_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/qwen/qwen3.8-flash-next",
"mode": "primary"
},
"general": {
"model": "tensorx/qwen/qwen3.8-flash-next",
"mode": "subagent"
},
"explore": {
"model": "tensorx/qwen/qwen3.8-flash-next",
"mode": "subagent"
}
},
"default_agent": "build"
}
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/opencode-session.json
+9344
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T13:11:02.2153173+02:00
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Adapter.log
+5
View File
@@ -0,0 +1,5 @@
[2026-09-02T10:51:56.684623+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\Ergebnisse)
[2026-09-02T10:51:56.851524+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=solo; Effort=high (uebergeben=True); Stall-Timeout=0s
[2026-09-02T11:11:00.336010+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
[2026-09-02T11:11:01.630042+00:00] OpenCode export: Exporting session: ses_f9e40b88cffesSzknb1eFPiSFP
[2026-09-02T11:11:01.680205+00:00] Ende: Exitcode=0; Status=success; Turns=93; Tokens=6432032; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\RawResult.json
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/Analysebericht.md
+160
View File
@@ -0,0 +1,160 @@
# Analysebericht
Reverse Requirements Engineering der c-entron ERP-Suite (statische Analyse, keine Programmausführung).
Umfang des Arbeitsverzeichnisses: ~16.800 C#/XAML-Quelldateien, `SSMS_DB_SCHEMA.sql` mit 1.558 Tabellen-Definitionen, zusätzlich Konfigurations-, Deployment- und Dokumentationsartefakte.
---
## 1. Modulinventar (Schritt 0) und Abdeckungstabelle
Das Inventar wurde vor der ersten Anforderung aus der Verzeichnisstruktur des Arbeitsverzeichnisses erhoben (Schritt 0) und ist Bezugsgröße der Abdeckung. Fachlich zusammengehörige Unterordner sind zu einem Modul zusammengefasst; die Spalte „Anforderungen“ verknüpft jede Zeile mit mindestens einer Requirement-ID (Schritt 0b). Einstufung: `tief` = Quellcode/Schema der durchsetzenden Stelle gelesen; `mittel` = Teile des Codes/Schema gelesen; `flach` = Belege überwiegend Dateinamen-/Ordner Ebene (SEKUNDÄR), Anforderung bewusst schmal gehalten.
| # | Modul / Komponente | Pfad | Fachliche Aufgabe (ein Satz) | Einstufung | Anforderungen |
|---|---|---|---|---|---|
| 1 | Build- und Versionskonfiguration | `Centron.sln`, `Directory.Build.props`, `global.json`, `version.json`, `nuget.config` | Einheitliche Build-/, .NET- und Versionsverwaltung über alle Projekte. | flach | SwRS-34, SyRS-29 |
| 2 | Datenbankschema | `SSMS_DB_SCHEMA.sql` | Vollständige DDL-Abbildung der MSSQL-Datenbank inkl. Indizes und Versionstabellen. | tief | SwRS-1..6, SwRS-11, SwRS-12, SwRS-32, SyRS-23, SyRS-27 |
| 3 | Rechte-Dokumentation | `CentronRights.md` | Fachbeschreibung der Helpdesk-/Kalender-/Auslastungsrechte inkl. einschränkender Rechte. | tief | StRS-3, StRS-9, SyRS-4, SyRS-14, SwRS-13 |
| 4 | Projekt-Dokumentation | `README.md`, `docs/` | Architektur- und Feature-Doku (WebCart, Helpdesk-Templates, Sync-Bugprotokoll). | mittel | StRS-8, SyRS-15, StRS-3 |
| 5 | CI/CD-Pipelines | `azure/`, `azure-blazor/`, `.github/` | Build-, Test-, Regression-, Playwright- und Security-Pipelines. | flach | SyRS-29 |
| 6 | Testinfrastruktur | `tests/` (Unit, Integration, EndToEnd, Playwright, Nexus) | Automatisierte Prüfung der Backend-, API- und Web-Ebene. | flach | SyRS-29 |
| 7 | Drittbinaries/-pakete | `assemblies/`, `nugets/` | Vorhaltungen von 7-PDF, Outlook-PIAs, TAPI-, WPF-Bibliotheken. | nicht analysiert | – (Binärartefakte ohne Quellcode; fachliche Relevanz nur aus Ordnernamen erschließbar, als Beleg nicht verwertbar) |
| 8 | Bau-/Umgebungsskripte | `scripts/` | Umgebungs-/Pfad-/Dependency-Helfer für Build und Betrieb. | nicht analysiert | – (reine Infrastruktur-Hilfsskripte ohne Fachlogik; nur Dateiauflistung erfolgt) |
| 9 | Versand-APIs | `src/apis/Centron.Api.Gls`, `src/apis/Centron.Api.Shipcloud` | Versandanmeldung/Label bei Speditionsdienstleistern. | flach | SyRS-10 |
| 10 | ebInterface-API | `src/apis/Centron.Api.EbInterface` | Erzeugung österreichischer E-Rechnungen (Schema 4.3). | mittel | StRS-6, SyRS-9, SwRS-22 |
| 11 | Lieferanten-Datenzugriff | `src/apis/Centron.APIs.CopDataAccess`, `EgisDataAccess` | SOAP-/Template-basierter Lieferantenabruf (comLine, EGIS). | flach | SyRS-11 |
| 12 | Bank-API | `src/apis/Centron.APIs.FinAPI` | REST-Zugang zum Onlinebanking-Dienstleister FinAPI. | flach | SyRS-13 |
| 13 | Produktdaten-APIs | `src/apis/Centron.APIs.IcecatDataAccess`, `ITscopeDataAccess` | Produktstammdaten-/Vergleichsquellen für Artikelanreicherung. | flach | SyRS-12, StRS-13 |
| 14 | docuFORM-Signatur-API | `Centron.Api.docuFORM/` | REST-Client für den elektronischen Signaturdienst docuFORM. | flach | StRS-15, SyRS-20 |
| 15 | Beleg-/Fakturierungslogik | `src/backend/Centron.BL/Sales/Receipts/` | Anlage, Prüfung, Preise, Limit, Druck von Angebot bis Gutschrift. | tief | StRS-2, SyRS-7, SyRS-8, SyRS-30, SwRS-17..20 |
| 16 | Helpdesk/Support | `src/backend/Centron.BL/Sales/Support/`, `BL/CheckListArea`, `BL/TaskManager`, `WPF/Modules/Helpdesk` | Ticketbearbeitung, Status, Zeiten, Checklisten, Historie. | mittel | StRS-3, SwRS-10, SyRS-14, SyRS-19 |
| 17 | Kunden-/Vertriebsdaten | `src/backend/Centron.BL/Sales/Customers`, `Sales/CustomerAssets`, `Marketing`, `HourlySurchargeRates` | Kundenbezug der Belege, Kunden-Hardware, Markt- und Zuschlagsdaten. | flach | StRS-5, StRS-8 |
| 18 | Adressstamm | `src/backend/Centron.BL/Accounts/` | Adresse/Anrede/Kostenstellen/Filialzuordnung von Kunden und Lieferanten. | mittel | StRS-1, SwRS-32 |
| 19 | Zahlungsverkehr/Kasse/Bank | `src/backend/Centron.BL/Accounting/`, `Sales/CashBooks/`, `Finances/Payments`, `Finances/IncomingPayments`, `Finances/OnlineBanking`, `WPF/Modules/OnlineBanking`, `Modules/Finances/Payments|Opos` | Konten, Zahlungsein-/ausgänge, offene Posten, Banking-Kanäle. | mittel | StRS-6, SyRS-13, SwRS-3 |
| 20 | Vertrags-/Abo-Abrechnung + Mahnwesen UI | `src/centron/Centron.WPF.UI/Modules/Finances` (AutomatedBilling, FlatrateBilling, TimerBilling, ContractEvaluation2/Old, Dunning, Campaigns, Contracts), `BL/VoucherManagement` | Wiederkehrende Abrechnung, Mahnläufe, Verträge, Gutscheine. | tief | StRS-7, StRS-6, SwRS-5, SwRS-31 |
| 21 | Login/Administration | `src/backend/Centron.BL/Administration/Logins`, `Rights`, `WPF/Modules/Administration` | Authentifizierung, Benutzerverwaltung, Konfiguration. | tief | SyRS-2, SwRS-14, StRS-9 |
| 22 | Kalender/Terminanfragen | `src/backend/Centron.BL/Calendar/`, `AppointmentRequests/`, `WPF/Modules/Calendar` | Terminplanung und Terminanfragen. | flach | StRS-10 |
| 23 | Künstliche Intelligenz | `src/backend/Centron.BL/ArtificialIntelligence/` | KI-Unterstützung (u. a. Ticketkategorien, Chat in AutomatedBilling). | nicht analysiert | – (nur Dateinamen `TicketCategoryApiClient.cs`, `AutomatedBillingView.ArtificialIntelligence.cs` gesichtet; Aussagequalität für belastbare Requirement nicht erreichbar, keine Halluzination) |
| 24 | Kernverschlüsselung | `src/backend/Centron.BL/Core/` | Passwort-Hashing/Salt, Ersetzungslogik. | tief | SyRS-6, SwRS-16 |
| 25 | Länder-/Währungsdaten | `src/backend/Centron.BL/CountryArea/` | Länder, Standardland, Währungssymbole. | flach | SwRS-3 |
| 26 | CPra-Konnektor | `src/backend/Centron.BL/CPra/` | Webhook-basierter Konnektor (Bedeutung der Abkürzung unbekannt). | nicht analysiert | – (nur `CPraConnectorBL`/`WebhookResponse`-Gerüst gesehen; fachliche Semantik nicht belegbar) |
| 27 | Kundenportal-Daten/SelfCare | `src/backend/Centron.BL/CustomerArea/`, `SelfCare/`, `Controllers/SelfCare`, `Nexus/WebCart/CustomerPortal*` | Selfcare-Formulare und Kundenportal-Inhalte. | flach | StRS-8, SyRS-15 |
| 28 | Geräte-/Assetverwaltung | `src/backend/Centron.BL/Devices/`, `Sales/CustomerAssets`, Schema `AssetManagementDevices` | Kunden-Hardware/Bestandsgeräte. | flach | StRS-5 |
| 29 | Dokumentenablage | `src/backend/Centron.BL/Storage/`, `DocuBoard/`, `DocumentationArea/`, `WPF/CentronFileSystem` | Dateiablage mit Objektbindung. | flach | StRS-15 |
| 30 | E-Rechnung/EDI-Export | `src/backend/Centron.BL/EDI/`, `DataExchange/EDI/` (Zugferd), `Gateway/ZUGFeRD21_Extended` | ZUGFeRD/XRechnung/Import. | mittel | StRS-6, SyRS-9, SwRS-21 |
| 31 | Mitarbeiterdaten | `src/backend/Centron.BL/EmployeeArea/` | AppUser/Mitarbeiter-Stammdaten inkl. 2FA-Schlüsselablage. | flach | StRS-9, SwRS-15 |
| 32 | Benachrichtigungen | `src/backend/Centron.BL/Notifications/`, `NexusNotifications/`, `ExpectedEvents/` | Ereignisbenachrichtigung an Clients. | flach | SyRS-16 |
| 33 | Fremd-Integrationen | `BL/ExternalHelpdesk/`, `ExternalToolsBL/`, `Integrations/` (DocBee, RMM), `Controllers/Integrations/` | Anbindung Fremdsysteme an Tickets/Infrastruktur. | flach | SyRS-19, SyRS-20 |
| 34 | EDI-Gateway | `src/backend/Centron.Gateway/` (Concerto, EDI_Alltron/Also/AlsoCH/EGIS/Herweck/Komsa, OpenTrans, Import/Export, MspCollector) | Kapselung aller Lieferanten-Nachrichtenformate. | mittel | StRS-4, SyRS-11, SwRS-23 |
| 35 | BL-Infrastruktur | `BL/Modules`, `Helpers`, `GUI`, `Start`, `Tools`, `Exceptions`, `Processes`, `Services`, `SystemArea`, `WebServices`, `WebVersion` | Querschnittsdienste, Result-Muster, Session-Infrastruktur. | mittel | SwRS-8, SwRS-9, SyRS-1 |
| 36 | Volltextsuche | `src/backend/Centron.BL/IndexSearch/` | Indexaufbau/-suche inkl. deutscher Sprachanalyse. | mittel | SyRS-17, SwRS-29 |
| 37 | E-Mail/Kommunikation | `BL/Mail`, `Mailings`, `MailScanner`, `Outlook`, `Nexus.OutlookAddIn`, `docker/c-entron-mailcatcher` | Mail-Workflows, Mailscanner-Profile, Outlook-Anbindung. | mittel | StRS-10, SyRS-19 |
| 38 | Massenupdates | `BL/MassUpdate/`, `WPF/Modules/Massenupdates` | Serienänderungen an Fachobjekten. | flach | SwRS-35 |
| 39 | Mobiler Zugriff | `BL/Mobile/`, `DAO/Mobile/` | Eigene Daten-/Logikschicht für mobile Clients. | flach | StRS-11 |
| 40 | Zusammenarbeit/Kollaboration | `BL/MyCentron`, `MyDay`, `ToDoArea`, `Tags`, `Chats`, `SocialMedia`, `VideoPortal`, `WPF/Modules/Dashboard|MyCentron|Survey` | Tagesplanung, Aufgaben, Tags, Chat, Umfragen. | flach | StRS-10 |
| 41 | Telefonie | `BL/Tapi/`, `Controls/Telephony`, `WPF/Modules/TelekomDive`, `assemblies/tapi`, `TapiClientHub` | Click-to-Dial/Anrufereignisse (TAPI + TelekomDive). | flach | SyRS-21 |
| 42 | Projekte/Fertigung/Planung | `BL/Projects`, `TicketProjects`, `Production`, `ProductMatrix`, `ItPlanner`, `WPF/Modules/ProjectManagement|Production|QM|Rma|PLM|ProjectPriceImport`, `Nexus/ProductionOrderManagement` | Projekte, Fertigungsaufträge, Qualität, Instandsetzung, IT-Planung. | flach | StRS-11, StRS-12 |
| 43 | Einkauf/Logistik/Handel | `BL/Purchasing`, `TradePool`, `WPF/Modules/Purchasing|Logistic|Warehousing` | Bestellungen je Filiale, Gebrauchtwaren-Import, Lagerlogistik. | flach | StRS-4, SwRS-12 |
| 44 | Berichtswesen | `BL/ReportEngine`, `Reporting`, `DAO/Statistics`, `WPF/Modules/Reports|Statistics`, `Controllers/Statistics` | Reports, Druck, Statistiken, Nexoware-Kennzahlen. | mittel | StRS-12, SyRS-18 |
| 45 | PDF-Signatur (intern) | `src/backend/Centron.BL/Security/` | PDF-Signaturverarbeitung. | mittel | StRS-15, SyRS-20 |
| 46 | Passwort-/2FA-Verwaltung | `BL/PasswordManager`, `PasswordManagementArea`, `TwoFactorAuthenticator`, `Core/GoogleAuthenticator|TotpAuth` | TOTP-Schlüsselverwaltung und -prüfung. | tief | StRS-9, SyRS-5, SwRS-15 |
| 47 | Textbausteine/Vorlagen | `BL/TextModuleArea`, `DAO/TextModuleArea`, `ReceiptTemplateBL`, `HelpdeskPatternBL`, `Controllers/Tickets/TicketPatternsController.cs` | variable Texte und Vorlagen je Objektart. | flach | SyRS-30 |
| 48 | Zeiterfassung | `BL/Time/`, `Sales/Support/HelpdeskTimer*`, `Modules/Finances/TimerBilling` | Zeiten inkl. Abrechnungsüberleitung. | mittel | SyRS-14, StRS-3, StRS-7 |
| 49 | Riverbird-Kopplung | `BL/RiverDivo/`, `deployment/riverbird` | Synchronisation mit Abo-Plattform des Herstellers. | mittel | StRS-14, SyRS-22 |
| 50 | Artikel-/Lagerlogik | `src/backend/Centron.BL/Warehousing/` | Artikelstamm-Pflege, Barcodes, Staffelpreise, Zweitlager. | mittel | StRS-5, SwRS-11, SwRS-12 |
| 51 | Telemetrie/Logging | `BL/Telemetry/`, `Common/Logging/` | Laufzeitprotokolle, In-Memory-Diagnose. | mittel | SyRS-28, SwRS-26 |
| 52 | Verweise/Links | `BL/Urls`, `WebLinks`, `ObjectExternalReferences`, `Controllers/Integrations/ObjectExternalReferences` | Externe Referenzen/Links an Fachobjekten. | flach | StRS-10 |
| 53 | Querschnittsbibliothek | `src/backend/Centron.Common/` | Logging, Settings, Format, IniParser, Benutzer-Utilities. | mittel | SwRS-26, SwRS-8 |
| 54 | Datenschicht | `src/backend/Centron.DAO/` (NHibernate, NamedQueries, ChangeTracking, Mappings, Statistics) | Persistierung, Abfragen, Änderungsnachverfolgung. | mittel | SwRS-7, SwRS-24, SwRS-25 |
| 55 | Entitäten | `src/backend/Centron.Entities/` | Datenmodell-Klassen (z. B. Mahnlauf). | mittel | SwRS-5 |
| 56 | Verträge/Schnittstellen | `src/backend/Centron.Interfaces/` | BL-/Gateway-Verträge als Interfaces. | flach | SyRS-1, SwRS-8 |
| 57 | WPF-Client Shell+Module | `src/centron/Centron.WPF.UI/` (29 Module, Dialogs, Wizards, Localization, Managers) | Desktop-Oberfläche, Modulnavigation, Masken. | mittel | StRS-12, SwRS-27, SwRS-35 |
| 58 | WPF-Erweiterungsbibliothek | `src/centron/Centron.WPF.UI.Extension/` | MVVM-, Commands-, Converter-Framework. | flach | SwRS-27 |
| 59 | Steuerelements-Bibliothek | `src/shared/Centron.Controls*` | Wiederverwendbare Funktionscontrols (PositionGrid, Mail, PDF-Scan …). | mittel | StRS-10, StRS-15, SwRS-30 |
| 60 | Kernbibliothek | `src/shared/Centron.Core/` | MVVM, TOTP, Threading, IO/Xml-Utilities. | mittel | SyRS-5, SwRS-15 |
| 61 | API-Host | `src/webservice/Centron.Host/`, `.Console`, `.WindowsService`, `RealTimeServices` | Request-Pipeline, Auth-Schemes, SignalR-Hubs, Hosting-Varianten. | tief | StRS-16, SyRS-1, SyRS-2, SyRS-16, SwRS-8, SwRS-28 |
| 62 | API-Controller | `src/webservice/Centron.Controllers/` | REST-Endpunkte inkl. Authorization-Attribute. | tief | StRS-9, SyRS-3, SyRS-4, SwRS-13 |
| 63 | Webservice-Core/Clientlib | `src/webservice/Centron.WebServices.Core/` | REST-Client, Message-/Entity-Grundlage, `UserRightsConst`. | mittel | SwRS-13, SwRS-9 |
| 64 | ConnectionManager | `src/webservice/c-entron.misc.ConnectionManager/` | Client-Konfiguration, Hardware-ID, Lizenz, SQL-Servercheck. | mittel | SwRS-33, SyRS-25 |
| 65 | Nexus-Webanwendung | `src/nexus/CentronNexus/` (WebCart, WebOffer, ServiceBoard, Office, DocumentSigning, ProductionOrderManagement, Settings, Authorization) | Kunden-/Service-Portal und Web-Arbeitsplätze (Blazor). | mittel | StRS-8, StRS-11, SyRS-15, SwRS-20 |
| 66 | Nexus-Host | `src/nexus/CentronNexus.Host/` | Start/Hosting der Blazor-App. | flach | SyRS-1 |
| 67 | Outlook-AddIn | `src/nexus/CentronNexus.OutlookAddIn/` | E-Mail-Anbindung an Tickets aus Outlook. | flach | SyRS-19 |
| 68 | Container-Betrieb | `docker/` (compose, Images für db/webservice/nexus/mailcatcher/regression-db) | Referenz-Deployment als Compose-Stack. | tief | StRS-16, SyRS-1, SyRS-19, SyRS-25, SyRS-29 |
| 69 | Installations-/Deploy-Artefakte | `deployment/` (WixSharpInstaller, centron, riverbird) | Windows-Installer und zielgruppenspezifisches Deployment. | flach | StRS-16, StRS-14 |
| 70 | Feature-Dokumente | `docs/features/` | Funktionsdoku (automatische Ticketanlage, Sync-Bugprotokoll). | flach | StRS-3 |
**Abdeckungsstatistik:** 70 Module; tief = 10, mittel = 25, flach = 31, nicht analysiert = 4 (5,7 % < 10 %-Schwelle; Begründungen in der Tabelle).
---
## 2. Konsistenzcheck (skriptgestützt über alle drei Anforderungsdateien)
| Prüfpunkt | Ergebnis |
|---|---|
| Doppelte/mehrfach vergebene IDs | **0 Duplikate** bei 81 Anforderungen (16 StRS, 30 SyRS, 35 SwRS; IDs je Ebene lückenlos 1..n). |
| Anforderungen ohne Beleg | **0** – jeder Block enthält mindestens einen klassifizierten Beleg. |
| Anforderungen ohne `Übernahmewürdigkeit` | **0** – Feld in allen 81 Blöcken gefüllt. |
| Tracelinks auf nicht existierende IDs | **0 Verweise ins Leere** (alle referenzierten IDs vorhanden). |
| SwRS→SyRS-Rückkopplung | Nach Korrektur verweist **jede** SwRS-Anforderung auf ≥1 SyRS; **jede** SyRS auf ≥1 StRS. |
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk | Kontrolliert für: EDI-Partner (SyRS-11, SwRS-11-Gateway-Zeile), Vertragsbewertung Alt/Neu (StRS-7↔SwRS-31), ZUGFeRD-Alt/Neu (SyRS-9↔SwRS-21), Signatur intern/extern (SyRS-20↔StRS-15), Versand-Adapter (SyRS-10), Produktimport (StRS-13↔SyRS-12), 2FA/Passwort (SyRS-5↔SwRS-15), DMS-Vierfachpfade (StRS-15) – alle als Konsolidierungskandidat markiert bzw. über Tracelinks getrennt. |
| Abgleich `Hypothesen.md` ↔ Inline-Markierungen | **exakt 14 = 14**: StRS-14, SyRS-13, SyRS-20, SyRS-21, SyRS-22, SyRS-25, SwRS-5, SwRS-12, SwRS-19, SwRS-24, SwRS-25, SwRS-31, SwRS-33, SwRS-35 – identisch in beiden Nachweisen; `Hypothesen.md` enthält keine freien Punkte ohne Anforderung. |
| `Status`-Feld nur mit `belegt`/`HYPOTHESE` | eingehalten; Workaround/Sonderfall/veraltet ausschließlich in `Übernahmewürdigkeit`. |
## 3. Liste der risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
| ID | Titel | PRIMÄR-Beleg vorhanden? | Belegsituation |
|---|---|---|---|
| StRS-2 | Verkaufsprozess inkl. Bonitätsüberwachung | ja (`ReceiptBL` Limit-/Mahnstufencode) | belegt |
| StRS-6 | Debitoren/Mahnen/E-Rechnung | ja (`RechKopf`-Schema, `InvoiceZugferdBL`) | belegt |
| StRS-7 | Vertrags-/Abo-Abrechnung | ja (`GutscheinZuRechnung`-Schema) | belegt |
| StRS-9 | Benutzerberechtigungen | ja (`AuthorizeUserRightAttribute`, `ReceiptBL`) | belegt |
| SyRS-2 | Ticket-/Token-Authentisierung | ja (`TicketAuthenticationHandler`) | belegt |
| SyRS-3 | JWT-Login mit Anwendungsprüfung | ja (`JwtAuthController.LoginWithBearer`) | belegt |
| SyRS-4 | Deklarative API-Rechteprüfung | ja (`AuthorizeUserRightAttribute`) | belegt |
| SyRS-5 | 2FA (TOTP) | ja (`TwoFactorAuthenticationBL.ValidateAuthenticationPin`) | belegt |
| SyRS-6 | Passwort-Hashing | ja (`CryptoUtils.CreatePasswordHash`) | belegt |
| SyRS-7 | Kreditlimit-Prüfung | ja (`ReceiptBL.cs:8636`) | belegt |
| SyRS-8 | Belegsperre ab Mahnstufe | ja (`ReceiptBL.cs:10194`) | belegt |
| SyRS-9 | E-Rechnungsformate | ja (`InvoiceZugferdBL.GetZugferFormat`, `EbInterfaceLogic.ValidateValues`) | belegt |
| SyRS-13 | Onlinebanking | nein (nur SEKUNDÄR) | **HYPOTHESE** (korrekt markiert) |
| SyRS-14 | Zeiterfassung→Fakturierung | ja (`HelpdeskTimerBL.cs:554-556` Rechtsprüfung; `:119-142` Belegzuordnung) | belegt |
| SyRS-22 | Riverbird-Sync (Vertragsdaten) | nein (nur KONTEXT-Klassendoku) | **HYPOTHESE** (korrekt markiert) |
| SyRS-24 | Belegversionierung/Protokollierung | ja (30 `*Versions`-Tabellen, `ReceiptLogBL`-Aufrufe) | belegt |
| SyRS-25 | Lizenz-/Hardwarebindung | nein (nur SEKUNDÄR-Umgebung) | **HYPOTHESE** (korrekt markiert) |
| SwRS-3 | RechKopf Zahlungs-/Mahnfelder | ja (Spaltendefinitionen) | belegt |
| SwRS-5 | Mahnlauf-Entität | nein belastbar (Entitätsdeklaration, keine Prüfung) | **HYPOTHESE** (korrekt markiert) |
| SwRS-13 | Rechtekonstantenbaum | ja (`UserRightsConst.cs`) | belegt |
| SwRS-14 | Ticketvalidierungsroutine | ja (`AuthenticationTicketBL.cs:25-47`) | belegt |
| SwRS-15 | TOTP-Schlüsselverwaltung | ja (`TwoFactorAuthenticationBL`) | belegt |
| SwRS-16 | SHA-1-Passwort-Hash | ja (`CryptoUtils.cs:26-33`) | belegt |
| SwRS-17 | Limitalgorithmus | ja (Methode vollständig) | belegt |
| SwRS-18 | Beleganlage-Gate | ja | belegt |
| SwRS-21 | ZUGFeRD/Auswahl | ja | belegt |
| SwRS-22 | ebInterface-Export | ja | belegt |
| SwRS-25 | Change-Tracking | nein (nur Ordner/Kommentar) | **HYPOTHESE** (korrekt markiert) |
| SwRS-31 | Vertragsbewertung Alt/Neu | nein (nur Ordnerbelege) | **HYPOTHESE** (korrekt markiert) |
| StRS-14 | Riverbird-Geschäftsmodell | nein | **HYPOTHESE** (korrekt markiert) |
| SwRS-35 | Massenupdates (Zugriff auf Belege/Stammdaten) | nein | **HYPOTHESE** (korrekt markiert) |
Keine risikorelevante Anforderung liegt ohne PRIMÄR-Beleg mit Status `belegt` vor.
## 4. Bekannte Lücken
- Keine Laufzeit-/DB-Analyse möglich: Zustandsautomaten, Zahlenwerte (z. B. `MaxReceiptProgressionSize`) und Konfigurationsprofile bleiben punktuell offen.
- `docs/`-Bestand ist dünn (wenige Feature-Dokumente); Change-Historie nur über `changelog.txt` des Nexus verfügbar, keine Commit-Messages im Spiegel.
- Nicht gelesene Großdateien: `ReceiptBL.cs` umfasst ~11.500 Zeilen; gelesen wurden die risikorelevanten Abschnitte (Limit, Mahnstufe, Web-Änderungen, Textvariablen, Preis-/Log-Ausschnitte).
## 5. Selbstbewertung
- **Analysetiefe über alle 70 Module des Inventars:** 10 tief, 25 mittel, 31 flach, 4 gar nicht (`assemblies`/`nugets`, `scripts`, `BL/ArtificialIntelligence`, `BL/CPra` – Begründungen je Zeile in der Tabelle). Das sind 5,7 % nicht analysiert, unter der 10 %-Schwelle.
- **Mindestabdeckung:** erreicht – jedes analysierte Modul hat ≥1 Anforderung; die 4 nicht analysierten Module tragen eine Begründung statt einer Requirement.
- **Dünne Belegstellen:** hoher SEKUNDÄR-/KONTEXT-Anteil dort, wo nur Verzeichnis- und Dateinamen als Beweismittel dienten (Module 9, 11–14, 22, 25, 27, 28, 32, 38–43); `[HYPOTHESE]` bei 14 von 81 Anforderungen (17 %), schwerpunktmäßig Riverbird (2), Doku-basierte Signatur-/Telefonie/Lizenzthemen und Datenmodell-Fragezeichen (Mahnlauf-Persistenz, ChangeTracking, ContractEvaluation-Migrationsstand).
- **Hypothesen:** 14 offene Punkte geführt – bei einer Codebasis dieser Größe (1.558 Tabellen, 16.800 Dateien) unausweichlich; das Nicht-Führen weiterer Hypothesen wäre eher ein Alarmsignal.
- **Nachschlag für eine Folge-Iteration empfohlen:**
1. `HelpdeskCloseBL`/`HelpdeskTimerBookedArticlesFilter` im Detail lesen (Abrechnungs-Sperrlogik der Zeiten vollständig belegen).
2. `AccessTokenBL` + `AccessTokensController` (Gültigkeit, Rotation, IP-Bindung der Access-Token).
3. `Modules/Finances/Dunning/DunningRunViewModel` + Mahnlauf-DAO: echte Mahnstufen-Berechnungsregeln und Fristenberechnung.
4. Lizenz-/Hardware-ID-Prüfung im Startpfad von `CentronHost.cs`/`Program.cs` lokalisieren (risikorelevant, aktuell Hypothese).
5. `ContractEvaluation2`-Regelsatz extrahieren (Abrechnungslogik für Zielsystem-Spezifikation vertiefen).
6. `MahnlaufMaps`-Frage klären (endgültige vs. temporäre Tabelle) – relevant für Datenmigration.
*Stand: Lauf vom 2026-09-02, v13.0.0-af37; Analyse rein statisch, Codebasis unverändert.*
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/Glossar.md
+40
View File
@@ -0,0 +1,40 @@
# Glossar
Domänenbegriffe, wie sie aus der Codebasis abgeleitet wurden (technische Bezeichner in Originalsprache).
| Begriff | Bedeutung im System | Erstverwendung |
|---|---|---|
| Mandant | Rechtliches Unternehmen/Installation auf der Plattform; Filialen tragen `MandantI3D` | StRS-1, SwRS-4 |
| Filiale | Betriebseinheit eines Mandanten mit eigener Adresse, Preisliste, Buchhaltungsnummer; `IsDefault` steuert Standard | StRS-1, SwRS-4 |
| Beleg | Oberbegriff für Verkaufsdokumente; Implementierung als Kopf-/Positionstabellen je Art (`AngKopf` Angebot, `AufKopf` Auftrag, `RechKopf` Rechnung, `GutKopf` Gutschrift, `RepaKopf` Reparatur) | StRS-2, SwRS-2 |
| Belegkette / Receipt Progression | Nachverfolgbare Folge von Belegen über Herkunftsschlüssel (`OriginKind`, `OriginReceiptI3D`, `AusAuf`) | StRS-2, SwRS-19 |
| AppUser | Interner Benutzer des Systems (Mitarbeiter), identifiziert über `AppUserI3D` | SyRS-2, SwRS-15 |
| Web-Account | Externer Kunden-Zugang für Nexus/WebCart, im Adressstamm gepflegt, von AppUser getrennt autorisiert | StRS-8, SyRS-15 |
| Mahnstufe | Eskalationsstufe des Mahnprozesses je Geschäftspartner (`RechKopf.Mahnstufe`, Mahnung1–3); kann Belegneuanlagen sperren | StRS-6, SyRS-8 |
| Mahnlauf | Ausgeführter Mahndurchgang als Protokollsatz (`Mahnlauf`-Tabelle mit Alt-/Neu-Status) | SwRS-5 |
| Kreditlimit (CreditLimit) | Vom Kunden akzeptierter offener Zahlungshöchstbetrag; Prüfung netto oder brutto (`CreditLimitCalculationKind`) | SyRS-7, SwRS-17 |
| Restricted/Restricting Right | Einschränkung eines Fachrechts auf „nur eigene Objekte / eigene Filiale / eigene Abteilung“ (z. B. `SHOW_HELPDESK_ONLY_OWN`) | StRS-9, SwRS-13 |
| Sonderpreise | Kundenindividuelle Preise; Grundlage des WebCart-Shops | StRS-8 |
| HelpdeskState | Konfigurierbarer Ticketstatus inkl. Abschlussstatus; Löschschutz bei Verwendung | SwRS-10 |
| Ticket (Helpdesk) | Supportvorgang mit Status, Priorität, Kategorien, Zeiten, Checklisten, Historie | StRS-3 |
| Hilfe-/Ticketzeit (HelpdeskTimer) | Zeiterfassung am Ticket, mit Anfahrtsartikeln; nach Abrechnung unveränderbar | SyRS-14 |
| Checkliste / C-FLOW | Punktelisten am Ticket; C-FLOW bezeichnet Ticketvorlagen-/Pattern-Funktion | StRS-3 (Rechte 16–17) |
| ZUGFeRD / XRechnung | Deutsches Format strukturierte E-Rechnung; `ZugferdKind`-Enum wählte Versionen bis `XInvoice_3_0_1` | SyRS-9 |
| ebInterface | Österreichisches E-Rechnungs-XML-Format (Schema 4.3 implementiert) | SyRS-9, SwRS-22 |
| Concerto / OpenTrans | Lieferanten-/Bestellnachrichtenformate des Gateway-Layers | SyRS-11, SwRS-23 |
| EDI-Partner | Implementierte Großhandelsanbindungen: Alltron, Also (DE/CH), EGIS, Herweck, Komsa, comLine (Cop) | SyRS-11 |
| Icecat / ITscope | Externe Produktdatenquellen für Artikelanreicherung | StRS-13 |
| FinAPI / FinTS (libfintx) | Onlinebanking-Kanäle (REST-API bzw. Bankstandard) | SyRS-13 |
| Riverbird / RiverDivo | Abo-/Vertragsplattform des Herstellers; Sync zwischen Riverbird- und c-entron-Webservice | StRS-14, SwRS-22 (Syn. RiverDivoBL) |
| DocBee / docuFORM | Externe Dokumenten-Processing- bzw. Signaturdienste mit eigenen Controllern/Clients | SyRS-20, StRS-10 |
| RMM | Remote-Monitoring-&-Management-Integration (`RmmController`, `RmmConnectionSettingsController`) | StRS-10 (Kontext) |
| TelekomDive | Cloud-Telefonie-Anbieterintegration | SyRS-21 |
| TAPI | Windows-Telefonie-API-Legacy-Anbindung | SyRS-21 |
| WebCart | Kunden-Shop in Nexus mit kundenspezifischen Sonderpreisen | StRS-8 |
| ServiceBoard / ProductionOrderManagement / DocumentSigning | Nexus-Webbereiche für Service-Cockpit, Fertigungsaufträge, Dokumentenunterschrift | StRS-11 |
| Versionstabelle (`*Versions`) | Historie je Belegkop/-position (z. B. `AngKopfVersions`) | SyRS-24, SwRS-2 |
| LockUser | Bearbeitungssperre am Belegkopf (Sperrvermerk, wer bearbeitet) | SwRS-3 |
| Status-Spalte / Weichlöschung | Systemweites Muster: `Status` für Gültigkeit, `Geloescht*`-Spalten statt physischem DELETE | SwRS-6 |
| ConnectionManager | separates Konfigurations-/Diagnosetool des Desktop-Clients (Hardware-ID, Lizenz, Servercheck) | SwRS-33 |
| Nexus | Weboberfläche (Blazor) des Systems, intern auch „c-entron Web“ | StRS-8 |
| c-entron.NET | Bezeichnung des Desktop-Clients/Produkts in Rechten und Doku | StRS-9 |
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/Hypothesen.md
+20
View File
@@ -0,0 +1,20 @@
# Hypothesen
Sammlung aller Anforderungen, die in StRS/SyRS/SwRS mit Status `HYPOTHESE` markiert sind. Offene Punkte ohne zugehörige Anforderung stehen in der Selbstbewertung des Analyseberichts.
| ID | Titel | Offene Frage / fehlende Information |
|---|---|---|
| StRS-14 | Verknüpfung mit der Riverbird-Abonnementplattform | Welches Geschäftsmodell und welcher Synchronisationsumfang (Vertrag, Artikel, Status) konkret über Riverbird/Divo abgebildet wird, ist nur aus Klassendoku-Kommentaren erschlossen; Schnittstellenverträge/Beispieldaten fehlen im Artefaktbestand. |
| SyRS-13 | Onlinebanking-Anbindung (FinAPI, HBCI/FinTS) | Die konkrete Regel, nach der importierte Kontoumsätze offenen Rechnungen zugeordnet werden (Verwendungszweck-Matching, Toleranzen), wurde in `IncomingPaymentBL` nicht nachgewiesen; ebenso, welcher Kanal (FinAPI vs. FinTS) produktiv primär ist. |
| SyRS-20 | Dokumentensignatur über docuFORM und PDF-Signing | Das Statusmodell des Signaturflusses (welche Zustände, wer signiert, Verfallsregeln) ist aus `PdfSigningBL`/`DocuFormRestApiClient` nicht vollständig ablesbar; API-Doku des Anbieters fehlt. |
| SyRS-21 | Telefonie-Integration (TAPI, TelekomDive) | Funktionsbreite beider Kanäle (Anruflistorik? Click-to-Dial nur ausgehend?) und ihr Nutzungsstatus sind nicht belegt; `PhoneCallBL` wurde nicht im Detail gelesen. |
| SyRS-22 | bidirektionale Riverbird-Synchronisation | Fachlicher Umfang der Synchronisation (welche Entitäten, welche Trigger) basiert nur auf den Klassenkommentaren von `RiverConnectionBL`/`RiverDivoBL`. |
| SyRS-25 | Lizenzierung an Hardware-ID gebunden | Der Durchsetzungspunkt der Lizenzprüfung im Startpfad (Client und Webservice) wurde nicht lokalisiert; Verhalten bei Lizenzfehler (Sperrung vs. Warnung) unbelegt. |
| SwRS-5 | Mahnlauf-Entität als Protokollsatz je Mahnstufe | Unklar, ob `Mahnlauf` endgültige Persistenz hat oder in eine finale Tabelle überführt wird (Mapping liegt unter `TemporaryEntities`). |
| SwRS-12 | Lagerbestand je Artikel | Bestandsbewegungsregeln (Reservierung durch Aufträge, Sperrbestand, Kommissionierbestand) sind aus `ArtikelBestand`-Tabelle und BL-Namen nicht belegbar. |
| SwRS-19 | Belegverlauf (Receipt Progression) mit Größenbegrenzung | Konkreter Wert von `MaxReceiptProgressionSize` sowie Sortier-/Filterlogik der Progressionsanzeige wurden nicht extrahiert. |
| SwRS-24 | Temporäres Entity-Mapping für Mahnlauf | Grund der Ablage unter `TemporaryEntities` (Restmigration? Zwischenlösung?) bleibt aus den Artefakten entscheidungslos. |
| SwRS-25 | DAO-seitiges Change-Tracking | Funktionsumfang des `ChangeTracking`-DAO (welche Tabellen/Felder getrackt werden, Aufbewahrung) ist nicht aus dem gelesenen Code ersichtlich. |
| SwRS-31 | Vertragsbewertung Alt (ContractEvaluationOld) neben Neu | Welche Implementierung produktiv genutzt wird und wie der Altbestand migriert wurde/wird, ist ohne Laufzeitanalyse nicht bestimmbar. |
| SwRS-33 | Client-Konfigurations-/Verbindungsverwaltung ConnectionManager | Prüftiefe des `SQLServerCheckTool` und Verhalten bei Konfigurationsänderungen (Neustartpflicht) sind nicht belegt. |
| SwRS-35 | Massenaktualisierung von Fachdaten | Welche Objektarten/Felder massenänderbar sind und wie Berechtigungen greifen, ist nur über die Existenz von BL- und Modulordner belegt. |
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/StRS.md
+351
View File
@@ -0,0 +1,351 @@
# StRS – Stakeholder Requirements Specification
Quellsystem: c-entron ERP-Suite (c-entron.NET / c-entron Nexus). Alle Anforderungen rückwärts aus der Codebasis abgeleitet (statische Analyse, keine Ausführung).
---
ID: StRS-1
Titel: Mandanten- und Filialfähiges Wirtschaftssystem
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsführung, Systemadministrator
Vorbedingung: Ein Unternehmen (Mandant) betreibt eine oder mehrere Filialen.
Fakt: DB-Tabelle `Filiale` enthält Spalten `MandantI3D`, `IsDefault`, `FilialStatus`, `Buchhaltungsnummer`, `Preisliste`; viele Fachtabellen führen `Status`/`Geloescht*`-Spalten (z. B. `GeloeschtVonI3D`, `GeloeschtAm` in `Filiale`). Rechtetexte differenzieren Datenzugriff auf Filialebene („nur eigene Filiale“, `CentronRights.md`, Punkte 1.2, 2.1).
Aussage: Das System soll die Daten und Prozesse mehrerer Unternehmen (Mandanten) und mehrerer Filialen je Mandant trennen und auswertbar halten.
Ergebnis: Fachdaten (Belege, Kunden, Filialzuordnungen) sind eindeutig Mandant und Filiale zuordenbar; Berechtigungen können auf die eigene Filiale eingeschränkt werden.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql`, `CREATE TABLE [dbo].[Filiale]` (Zeile ~43903, Spalten `MandantI3D`, `IsDefault`, `GeloeschtVonI3D`) - Schema schreibt Mandanten-/Filialbezug strukturell fest.
- [SEKUNDÄR] `CentronRights.md`, Punkte 1.2/2.1 (`SHOW_HELPDESK_ONLY_OWN_BRANCH`, `CREATE_HELPDESK_ONLY_OWN_BRANCH`) - fachliche Filialtrennung als Nutzeranforderung dokumentiert.
Prüfidee: Zwei Filialen anlegen; ein Benutzer mit „nur eigene Filiale“-Recht sieht Tickets/Belege der anderen Filiale nicht.
Tracelinks: SyRS-23, SwRS-4, SwRS-32
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Mandanten-/Filialfähigkeit ist Kernanforderung eines ERP-Zielsystems.
Status: belegt
---
ID: StRS-2
Titel: Durchgängiger Verkaufsprozess vom Angebot bis zur Rechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Innendienst, Außendienst, Kaufmännischer Leiter
Vorbedingung: Kunde ist im Adressstamm gepflegt.
Fakt: DB enthält Belegkopf-/Positionstabellen `AngKopf`/`AngPos` (Angebot), `AufKopf`/`AufPos` (Auftrag), `RechKopf`/`RechPos` (Rechnung), `GutKopf` (Gutschrift) mit Herkunftsverweisen (`AusAuf`, `OriginKind`, `OriginReceiptI3D`); `ReceiptProgressionBL` bildet die Belegfolge ab; `ReceiptBL` prüft beim Speichern Kreditlimit und Mahnstufe des Kunden.
Aussage: Das System soll den Verkaufsprozess als Belegkette (Angebot → Auftrag → Lieferschein → Rechnung → Gutschrift) mit Vererbung von Positionen und Herkunftsnachweis unterstützen und dabei die Bonität des Kunden überwachen.
Ergebnis: Folgebelege übernehmen Positionen aus dem Ursprungsbeleg; Überschreitung des Kreditlimits oder aktive Mahnstufe lösen Warnung bzw. Sperre aus.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:8636` (`CheckIfCustomerLimitIsReached`), `:10194` (`CanUserCreateNewReceiptsAtCustomerOrSupplier` inkl. Mahnstufenprüfung) - durchgesetzte Geschäftsregeln.
- [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `AngKopf`, `AufKopf`, `RechKopf`, `GutKopf`; Spalten `AusAuf` (Herkunft Auftrag) in `RechKopf` - Datenmodell der Belegkette.
- [KONTEXT] `src/backend/Centron.BL/Sales/Receipts/ReceiptProgressionBL.cs` - eigene BL für „Receipt Progression“ belegt das Konzept der Belegfolgedarstellung.
Prüfidee: Aus einem Auftrag einen Lieferschein erzeugen; Positionen und Kundenbezug sind identisch; nach Setzen von Mahnstufe 1 (mit Sperrkonfiguration) scheitert die Anlagen neuer Belege mit Fehlermeldung.
Tracelinks: SyRS-7, SyRS-8, SyRS-9, SwRS-2, SwRS-17, SwRS-18, SwRS-19
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - KERN-Prozess, für die Neuimplementierung zwingend.
Status: belegt
---
ID: StRS-3
Titel: Kunden-Support mit Tickets, Zeiten und Checklisten
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Support-Mitarbeiter, technischer Dienstleister, Kunde (im Portal)
Vorbedingung: Ticketanlage-Berechtigung liegt vor; Tickettypen/Kategorien sind gepflegt.
Fakt: `CentronRights.md` beschreibt Ticketrechte inkl. einschränkender Rechte (nur eigene Tickets, eigene Filiale, Zuweisung nur an eigene Abteilungen); `HelpdeskStatusBL` verwaltet konfigurierbare Ticketstatus und blockiert das Löschen verwendeteter Status; `HelpdeskTimer*`-BL-Klasse erfasst Zeiten am Ticket; Nexus-Changelog dokumentiert Zeiterfassung, Historie, Weiterleitungen und Checklisten im Ticket.
Aussage: Das System soll ein Ticketssystem mit konfigurierbaren Status, Prioritäten, Kategorien, Zuweisungen, Zeiterfassung, Checklisten und Kundenkommunikation bereitstellen; Zeiten sollen abrechenbar an Belege überleitbar sein.
Ergebnis: Tickets sind von Erfassung bis Abschluss nachverfolgbar; geleistete Zeiten sind für die Fakturierung verfügbar und vor unberechtigter Änderung geschützt.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskStatusBL.cs:75-100` (`DeleteHelpdeskStatus` zählt Verwendung und verhindert Löschen) - erzwungene Referenzintegrität.
- [SEKUNDÄR] `CentronRights.md`, Helpdesk-Abschnitt 1-17 - fachliche Rechtebeschreibung.
- [KONTEXT] `src/nexus/CentronNexus/changelog.txt` (Zeiteintrag, Historie, Weiterleitungen) - gelebte Nutzung.
Prüfidee: Ticketstatus mit referenzierenden Tickets löschen → Fehlermeldung „wird in … verwendet“. Zeit eines abgerechneten Tickets verschieben → abgelehnt (Recht `MOVE_HELPDESK_TIMER` greift nur bei nicht abgerechneten Zeiten).
Tracelinks: SyRS-14, SyRS-19, SwRS-10, StRS-8
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zentrales Arbeitswerkzeug der Support-Rolle.
Status: belegt
---
ID: StRS-4
Titel: Wareneinkauf mit elektronischer Lieferantenanbindung
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Einkauf, Großhandelslieferant
Vorbedingung: Lieferantenstamm und EDI-Verbindung sind konfiguriert.
Fakt: `Centron.Gateway` enthält EDI-Implementierungen für `EDI_Alltron`, `EDI_Also`, `EDI_AlsoCH`, `EDI_EGIS`, `EDI_Herweck`, `EDI_Komsa`, `Concerto` (XSD `ConcertoOrder.xsd`), `OpenTrans`; `Centron.APIs.EgisDataAccess`/`CopDataAccess` mit SOAP-/Request-Templates; `Purchasing/SupplierOrderPerBranchBL.cs` (filialbezogene Bestellungen).
Aussage: Das System soll Bestellungen und Auftragsstatus elektronisch mit mehreren Großhandelslieferanten austauschen (EDI) und Lieferantendaten (Verfügbarkeit, Preise) übernehmen.
Ergebnis: Bestellung geht elektronisch beim Lieferanten ein; Artikelstammdaten und Bestellstatus werden automatisch zurückgespielt.
Belege:
- [PRIMÄR] `src/backend/Centron.Gateway/Concerto/ConcertoOrder.xsd` - verbindliches Schnittstellen-Layout einer Bestell-Schnittstelle.
- [SEKUNDÄR] Verzeichnisliste `src/backend/Centron.Gateway/EDI_*`, `src/apis/Centron.APIs.EgisDataAccess/RequestTemplates` - benannte Partnerintegrationen.
- [KONTEXT] `src/webservice/Centron.Controllers/Controllers/DataExchange/*` (DocBee, Rmm, TelekomDive, DocuForm) - Datenaustausch-API.
Prüfidee: Musterbestellung an Test-EDI-Partner senden; XSD-Validierung des Ausgangsdokuments erfolgreich; Statusimport aktualisiert die Bestellposition.
Tracelinks: SyRS-11, SyRS-12, SwRS-23
Konsolidierung: Kandidat: die je Lieferanten getrennten EDI-Implementierungen (EDI_Alltron, EDI_Also, EDI_EGIS, EDI_Komsa, EDI_Herweck) bilden dasselbe Konzept „Lieferantenanbindung“ ab; im Zielsystem als konfigurierbare Connector-Plattform zusammenführen.
Übernahmewürdigkeit: übernehmen - ohne EDI ist das Tagesgeschäft (Tagesaktuelle Preise/Verfügbarkeiten) nicht möglich; konkrete Partnerliste ist Sonderfall-behaftet.
Status: belegt
---
ID: StRS-5
Titel: Zentraler Artikelstamm mit Lagern und Preisen
Ebene: StRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Einkauf, Vertrieb, Lager
Vorbedingung: Artikel- und Lagerdaten sind gepflegt.
Fakt: DB-Tabelle `Artikel` mit Zubehör, Alternativartikel, Ersatzteilen, Stücklisten (`ArtikelStueckliste`), Arbeitsplänen (`ArtikelArbeitsplan`), `ArtikelPreis`, `ArtikelBestand`, Einheiten (`ArtikelEinheit`); `Warehousing/BarcodeBL.cs`, `ArticleVolumePricesBL.cs` (Staffelpreise), `SecondStockArticleBL.cs`.
Aussage: Das System soll einen zentralen Artikelstamm mit Varianten, Einheiten, Preisstrukturen (Grundpreis, Staffeln, Sonderpreise je Kunde), Beständen, Barcodes und Produktionsdaten (Stückliste, Arbeitsplan) führen.
Ergebnis: Alle Belegarten greifen auf denselben Artikelstamm zu; Bestands- und Preisangaben sind je Filiale/Lager auswertbar.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabellen `Artikel`, `ArtikelPreis`, `ArtikelBestand`, `ArtikelStueckliste`, `ArtikelEinheit` - Datenmodell.
- [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/ArticleVolumePricesBL.cs`, `BarcodeBL.cs` - Preis-/Barcode-Logik vorhanden.
Prüfidee: Artikel mit Staffelpreis anlegen; Staffelauswahl auf Auftrag wirkt auf den Nettopreis (Feld `WithStaffelPrice` im Beleg, siehe `ReceiptBL.cs:10543`).
Tracelinks: SyRS-12, SwRS-11, SwRS-12
Konsolidierung: Kandidat: „Stammblätter“ (Drucker) und „AssetManagementDevices“ führen denselben Hardware-Gegenstand doppelt (Beispiel aus dem Auftrag); Zusammenführung in ein Asset-Konzept.
Übernahmewürdigkeit: übernehmen - Artikelstamm ist Fundament aller Belegprozesse.
Status: belegt
---
ID: StRS-6
Titel: Debitorenbewirtschaftung: Zahlungseingang, Mahnwesen, elektronische Rechnungsformate
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung, Kreditorenbuchhaltung, Kunde
Vorbedingung: Offene Rechnungen vorhanden; Bankkonto angebunden.
Fakt: `RechKopf` enthält `FaelligAm`, `Mahnung1Datum`–`Mahnung3Datum`, `Mahnstufe`, `MahnStop`, `Bezahlt`; Entität `Mahnlauf` (`src/backend/Centron.Entities/Entities/DbEntities/Mahnlauf.cs`) protokolliert je Mahnstufe mit Bearbeiter und Soft-Delete; `Finances/IncomingPayments`, `Finances/OnlineBanking` (FinAPI), `InvoiceZugferdBL` erzeugt ZUGFeRD/XRechnung, `EbInterfaceLogic` erzeugt ebInterface 4.3 (Österreich).
Aussage: Das System soll offene Posten verwalten, Zahlungseingänge (auch per Onlinebanking-Umsätzen) zuordnen, ein stufenweises Mahnwesen mit Protokollierung unterstützen und Rechnungen in gesetzlichen elektronischen Formaten (ZUGFeRD/XRechnung, ebInterface) ausleiten.
Ergebnis: Mahnstufen erhöhen/entsperren sich nach Vollzug; Ausgangsrechnungen sind revisionssicher als Hybrid-PDF/Elektronische Rechnung verfügbar.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` `RechKopf` (`Mahnstufe`, `Mahnung1..3Datum`, `MahnStop`, `Bezahlt`) - datenbankseitige Abbildung des Mahnprozesses; `ReceiptBL.cs:10194` erzwingt Sperrlogik aus Mahnstufe.
- [PRIMÄR] `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs:85-99` (`GetZugferFormat` wählt ZUGFeRD 1.0 / XInvoice 3.0.1) - Formatentscheidung im Code.
- [SEKUNDÄR] `src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs` - Umsatzübernahme.
Prüfidee: Rechnung mit Fälligkeitsverzug in Mahnlauf aufnehmen → Mahnstufe steigt, `Mahnlauf`-Satz mit Bearbeiter geschrieben; XRechnung-Ausgabe validiert gegen Schematron.
Tracelinks: SyRS-8, SyRS-9, SyRS-13, SwRS-3, SwRS-5, SwRS-21
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - gesetzlich (E-Rechnungspflicht) und betrieblich erforderlich.
Status: belegt
---
ID: StRS-7
Titel: Wiederkehrende Abrechnung eigener Verträge (Abo-/Vertragsabrechnung)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Service-Vertragsgestaltung, Fakturierung
Vorbedingung: Kundenvertrag (Wartung/Flatrate/Lizenz) existiert.
Fakt: WPF-Modul `src/centron/Centron.WPF.UI/Modules/Finances` enthält `AutomatedBilling`, `FlatrateBilling`, `TimerBilling`, `ContractEvaluation2` und `ContractEvaluationOld`, `Campaigns`, `Opos`; `Finances/ProductLifecycleBL.cs`; `GutscheinZuRechnung`-Tabelle im Schema.
Aussage: Das System soll wiederkehrende Entgelte aus Kundenverträgen (Pauschalen, Zeiterfassungs-Abos, nutzungsbasierte Modelle) automatisch abrechnungsreif machen.
Ergebnis: Verträge erzeugen periodisch Abrechnungspositionen/Belege; alt- und neu-Version der Vertragsbewertung sind getrennt führbar.
Belege:
- [SEKUNDÄR] Modulverzeichnisse `Modules/Finances/AutomatedBilling`, `FlatrateBilling`, `TimerBilling`, `ContractEvaluation2` - benannte Abrechnungsart-Funktionen.
- [PRIMÄR] `SSMS_DB_SCHEMA.sql`, Tabelle `GutscheinZuRechnung` - Zuordnung Gutscheine→Rechnungen erzwungen.
- [KONTEXT] Vorhandensein `ContractEvaluationOld` neben `ContractEvaluation2` - Migrationshistorie.
Prüfidee: Monatspauschalen-Vertrag anlegen; Abrechnungslauf erzeugt Rechnung mit Vertragsposition; Kündigung stoppt weitere Abrechnung.
Tracelinks: SyRS-22, SwRS-31, SwRS-34
Konsolidierung: Kandidat: `ContractEvaluationOld` und `ContractEvaluation2` bilden dieselbe Funktion in zwei Ständen ab → nur Neuversion übernehmen.
Übernahmewürdigkeit: übernehmen (Neuversion); `ContractEvaluationOld` = veraltet.
Status: belegt
---
ID: StRS-8
Titel: Selbstbedienungsportal für Kunden (c-entron Nexus)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Endkunde des c-entron-Kunden, Web-Account
Vorbedingung: Kunde besitzt Web-Account mit Sonderpreisliste.
Fakt: `README.md`: WebCart für „customers of our customers“, Artikel aus „Sonderpreise“, Login als Web-Account; Nexus-Seiten `WebCart/ContractsOverview.razor`, `ReceiptDetailsOverview.razor`, `CustomerTicketDetailsPage.razor`, `CustomerPortalPublicDocumentsPage.razor`; Autorisierungsattribute `AuthorizeLoginUserAttribute` / `AuthorizeLoginWebAccountAttribute`.
Aussage: Das System soll Kunden im Webportal eigene Tickets (Anlage, Historie), Verträge, Belege/Rechnungen, öffentliche Dokumente und einen Shop mit kundenspezifischen Sonderpreisen bieten.
Ergebnis: Externe Kunden arbeiten am Ticket mit, ohne den Desktop-Client zu benutzen; Zugriffe sind auf Web-Account-Daten beschränkt.
Belege:
- [PRIMÄR] `src/nexus/CentronNexus/Shared/Authorization/Attributes/AuthorizeLoginWebAccountAttribute.cs` - erzwungene Unterscheidung interner Benutzer vs. Web-Account.
- [SEKUNDÄR] `src/nexus/CentronNexus/WebCart/*.razor` - Portal-Funktionsumfang aus Seitennamen.
- [KONTEXT] `README.md` Zeilen 31-36 - fachliche Beschreibung des WebCart.
Prüfidee: Web-Account ohne eigene Sonderpreise sieht keine Artikel; Ticketansicht zeigt nur Tickets des eigenen Kundenkreises.
Tracelinks: StRS-3, SyRS-15, SwRS-20
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - klar differenzierendes Kundenbedürfnis.
Status: belegt
---
ID: StRS-9
Titel: Feingranulare Benutzerberechtigungen im Betrieb
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Datenschutzbeauftragter, Administration, Mitarbeiter
Vorbedingung: Benutzer, Rollen/Gruppen und Rechte sind gepflegt.
Fakt: `CentronRights.md` definiert Rechte inkl. „restricting rights“ (nur eigene Tickets, nur eigene Filiale, nur eigene Zeiten); `UserRightsConst.cs` als Konstantenbaum; API-Attribute `[AuthorizeUserRight]`, `[AuthorizeAnyUserRight]`, `[AuthorizeAllUserRights]` mit 401/403-Semantik (`Centron.Controllers/Authorization/README.md`).
Aussage: Das System soll für jedes Fachrecht einschränkende Varianten (nur eigene Objekte, eigene Filiale, eigene Abteilung) unterstützen und Berechtigungen sowohl im Desktop-Client als auch in der Web-API einheitlich durchsetzen.
Ergebnis: Datenzugriff und Funktionen sind rollenscharf begrenzt; fehlende Rechte werden konsistent abgewiesen.
Belege:
- [PRIMÄR] `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs` (+ `AuthorizeAnyUserRightAttribute.cs`, `AuthorizeAllUserRightsAttribute.cs`) - durchgesetzte Prüfung im Request-Pipeline; README beschreibt Filter-Ausführung und 401/403.
- [SEKUNDÄR] `CentronRights.md` - fachliche Rechtebeschreibung.
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:10194ff.` (`HasRightToCreateANewReceipt` via SpecificLogics) - Rechtsprüfung vor Beleganlage.
Prüfidee: Benutzer ohne `ADD_NEW_HELPDESK` ruft Ticket-API auf → 403; mit `SHOW_HELPDESK_ONLY_OWN` sieht er nur Tickets, in denen er Bearbeiter/Verantwortlicher ist.
Tracelinks: SyRS-4, SyRS-5, SyRS-6, SwRS-13, SwRS-15, SwRS-16
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Compliance-relevant.
Status: belegt
---
ID: StRS-10
Titel: Interne Kommunikation und Zusammenarbeit
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mitarbeiter
Vorbedingung: Benutzer ist angemeldet.
Fakt: BL-Ordner `Mail`, `Mailings`, `MailScanner` (Eingehende Mails → Workflow-Profile/Tasks), `Chats`, `Notifications`, `Calendar`, `ToDoArea`, `MyDay`, `TaskManager`, `Tags`; `HelpdeskMailBL` verknüpft Mails mit Tickets; `Outlook`-BL und `CentronNexus.OutlookAddIn`.
Aussage: Das System soll E-Mail-Eingang automatisiert in Aufgaben/Tickets überführen, Kalender, Aufgaben („Mein Tag“), Chat und Benachrichtigungen integrieren und Mails an Objekte (Tickets, Belege) andocken.
Ergebnis: Ein- und ausgehende Kommunikation ist am Vorgang nachvollziehbar; wiederkehrende Mail-Eingänge (z. B. Störungsmails) erzeugen automatisch Tickets.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/MailScanner/MailScannerBL.cs` (`SaveWorkflow`, `GetProfiles`, `SaveTasks`) - durchgesetzte Workflow-/Task-Erzeugung aus Mails.
- [SEKUNDÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskMailBL.cs` - Mail-Ticket-Verknüpfung.
Prüfidee: Testmail an gescanntes Postfach; konfiguriertes Profil erzeugt Ticket/Task; Log-Eintrag vorhanden.
Tracelinks: SyRS-16, SyRS-19, SwRS-26
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Effizienzkernfunktionen.
Status: belegt
---
ID: StRS-11
Titel: Zugriff von unterwegs und aus Browser/Office
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Außendienst, Techniker, Führungskraft
Vorbedingung: Benutzer hat Web-Zugang.
Fakt: Nexus-Blazor-App mit `ServiceBoard`, `Office`, `ProductionOrderManagement`, `DocumentSigning`, `WebOffer`; BL-Ordner `Mobile`; `CentronNexus.OutlookAddIn`; `src/apis/Centron.Api.Gls`/`Shipcloud` für Versandprozesse; changelog.txt beschreibt „Mein Tag“, Ticketplanung etc. im Web.
Aussage: Das System soll Kernfunktionen (Tickets, Aufträge/Produktion, Angebote, Unterschriften, Tagesplanung) plattformunabhängig im Browser und in Office bereitstellen.
Ergebnis: Nutzer erledigen Support- und Vertriebsvorgänge ohne Desktop-Client; Aktionen sind mit denselben Rechten abgesichert wie im Client.
Belege:
- [SEKUNDÄR] Verzeichnisse `src/nexus/CentronNexus/{ServiceBoard,Office,ProductionOrderManagement,DocumentSigning,WebOffer}` - benannte Web-Funktionen.
- [KONTEXT] `src/nexus/CentronNexus/changelog.txt` (Mein Tag, Zeitplanung, Ticketdetails im Web).
Prüfidee: Gleiche Ticketaktion (Statuswechsel) in WPF und Nexus; identische Rechteprüfung und Historieneintrag.
Tracelinks: SyRS-1, SyRS-15, SyRS-20, SyRS-16
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Zielrichtung der Web-/SaaS-Neuimplementierung.
Status: belegt
---
ID: StRS-12
Titel: Auswertung, Berichte und Kennzahlen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsführung, Controlling, Sachgebietsleitung
Vorbedingung: Transaktionsdaten vorhanden.
Fakt: WPF-Module `Reports`, `Statistics`; `Centron.DAO/Statistics`; BL `ReportEngine` (Reportvorlagen, `HelpdeskHtmlTemplateManager`, `CustomZugferdPdfGenerator`); Controller `Statistics/NexowareStatisticsController.cs`; `HelpdeskStatisticsBL`, `ReceiptProvision*BL` (Provisionen).
Aussage: Das System soll betriebswirtschaftliche Auswertungen (Umsatz, Provision, Ticketstatistiken, Produktlebenszyklus) als Reports und Statistiken bereitstellen und dabei Berechtigungen beachten (z. B. Recht `SALES_STATISTIC`).
Ergebnis: Führungskraft erhält rechtsbasiert filterbare Kennzahlen und druckbare Berichte.
Belege:
- [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Reports`, `Modules/Statistics` - Report-/Statistik-Module.
- [PRIMÄR] `src/webservice/Centron.Controllers/Authorization/README.md` (Beispiel `[AuthorizeUserRight(UserRightsConst.Controlling.Analytics.SALES_STATISTIC)]`) - Rechtegesicherte Statistik-Endpunkte.
- [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptProvisionSchemaBL.cs` u. a. - Provisionssystematik.
Prüfidee: Benutzer ohne `SALES_STATISTIC` ruft Statistik-Endpunkt auf → 403; Report-Export als PDF/Excel möglich.
Tracelinks: SyRS-18, SwRS-29
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Standardbedarf; konkrete Reportvorlagen einzeln prüfen.
Status: belegt
---
ID: StRS-13
Titel: Externe Produktdatenquellen für den Shop-/Vertriebsbetrieb
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Einkauf, E-Commerce-Verantwortlicher
Vorbedingung: Zugangsdaten zu Datenquellen hinterlegt.
Fakt: `Centron.APIs.IcecatDataAccess` (IcecatApi, Sprachen), `Centron.APIs.ITscopeDataAccess` (Parser), `Centron.APIs.CopDataAccess` (SOAP-Templates), `ProductMatrix`-BL-Ordner.
Aussage: Das System soll Produktstammdaten (Beschreibungen, Bilder, Klassifikationen) aus externen Quellen (Icecat, ITscope u. a.) übernehmen und pflegen.
Ergebnis: Artikel erhalten pflegierte Produktinformationen ohne manuelle Erfassung.
Belege:
- [SEKUNDÄR] `src/apis/Centron.APIs.IcecatDataAccess/IcecatApi.cs`, `Languages.cs`, `src/apis/Centron.APIs.ITscopeDataAccess/Parser` - benannte Produktdaten-APIs.
- [SEKUNDÄR] `src/backend/Centron.BL/ProductMatrix` - Produktmatrix-Funktionalität.
Prüfidee: Icecat-Abruf für Artikelnummer befüllt Artikeltext/Bild-Felder (ArtikelBilder-Tabelle vorhanden).
Tracelinks: SyRS-12, StRS-5
Konsolidierung: Kandidat: Produktdaten-Anreicherung (Icecat/ITscope) und Lieferantenkatalog-Importe (EDI/EGIS) verfolgen dasselbe Ziel „Artikelstammdaten anreichern“; gemeinsame Import-Pipeline im Zielsystem.
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: StRS-14
Titel: Verknüpfung mit der Riverbird-Abonnementplattform
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: c-entron-Hersteller, Wiederverkäufer
Vorbedingung: Riverbird-Vertrag vorhanden.
Fakt: `src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs` Doku-Kommentar: „all calls, that the c-entron Web-Service makes to the Riverbird Web-Service“; `RBContractArticleRefInfo.cs` (Vertrags-Artikel-Referenz); `deployment/riverbird` vorhanden.
Aussage: Das System soll Vertrags-/Abonnementdaten mit der Riverbird-Plattform synchronisieren (in beide Richtungen).
Ergebnis: Riverbird-Verträge spiegeln sich als Artikel/Positionen im c-entron, Änderungsmeldungen werden übernommen.
Belege:
- [KONTEXT] `src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs` (Klassendoku) + `RiverDivoBL.cs` („methods, that the Riverbird Web-Service calls in the c-entron Web-Service“) - beidseitige Synchronisation implementiert; nur durch Doku-Kommentare gestützt.
- [SEKUNDÄR] `deployment/riverbird` - Deployment-Ziel für Riverbird-Variante.
Prüfidee: Simulierter Riverbird-Callback aktualisiert lokalen Vertragsdatensatz.
Tracelinks: SyRS-22
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall -herstellerseitige Plattformkopplung, für generische Neuimplementierung optional.
Status: HYPOTHESE (Details des Geschäftsmodells und Synchronisationsumfang nicht im Code belegt)
---
ID: StRS-15
Titel: Digitale Dokumentenablage, Unterschrift und Dokumentenflüsse
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Sachbearbeiter, Recht/Compliance
Vorbedingung: Dokumentenverzeichnisstruktur existiert.
Fakt: `src/centron/Centron.WPF.UI/CentronFileSystem`, `Centron.Controls/CentronFileSystem`; BL `Storage`, `DocuBoard`, `DocumentationArea`; `Security/PdfSigningBL.cs`; API `Centron.Api.docuFORM` (DocuFormRestApiClient); Nexus-Modul `DocumentSigning`; Tabellen `ArtikelDateiLinks`, `DocDirI3D` in `RechKopf`; Controller `DocBee*`.
Aussage: Das System soll Dokumente objektscharf ablegen (Belege, Tickets, Artikel), den signierbaren Durchlauf (elektronische Unterschrift) unterstützen und Lösch-/Änderungshistorie von Dokumentbezügen wahren.
Ergebnis: Zu jedem Fachobjekt sind Dateien und deren Historie auffindbar; unterschriftspflichtige Dokumente durchlaufen einen Signaturprozess.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Security/PdfSigningBL.cs` - Signaturverarbeitung im Code.
- [SEKUNDÄR] `SSMS_DB_SCHEMA.sql` `RechKopf.DocDirI3D` - Dokumentverzeichnis am Beleg.
- [SEKUNDÄR] `Centron.Api.docuFORM/DocuFormRestApiClient.cs` - externer Signaturdienst.
Prüfidee: Rechnung im Signaturprozess bereitstellen; nach Signatur ist signiertes PDF anstelle des Originals im Beleg-Dokumentenverzeichnis verknüpft.
Tracelinks: SyRS-20, SwRS-33
Konsolidierung: Kandidat: interne Ablage (CentronFileSystem), DocuBoard, docuFORM und DocBee decken „Dokumentenlebenszyklus“ in vier Implementierungen ab → im Zielsystem zu einer DMS-Komponente konsolidieren.
Übernahmewürdigkeit: übernehmen - Compliance-Relevanz.
Status: belegt
---
ID: StRS-16
Titel: Betrieb im eigenen Rechenzentrum und als Container/SaaS
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Übertragbarkeit
Akteur: IT-Betrieb, c-entron als Hersteller
Vorbedingung: Zielumgebung existiert.
Fakt: `docker/compose/compose.yaml` startet db (MSSQL), webservice, smtp (mailcatcher), nexus als Container; Azure-Pipelines (`azure/build-pipeline.yml`, `azure/security-pipeline.yaml`, `azure/playwright-pipeline.yml`); Installationspaket `deployment/WixSharpInstaller`; Hosts `Centron.Host.Console`, `Centron.Host.WindowsService`.
Aussage: Das Gesamtsystem soll sowohl klassisch (Windows-Installation, Windows-Service) als auch containerisiert (Docker, Linux) deploybar bleiben.
Ergebnis: Auslieferung erfolgt je nach Kundenmodell als Installer oder Compose-Stack; Build/Deployment laufen automatisiert.
Belege:
- [PRIMÄR] `docker/compose/compose.yaml` (Zeilen 1-50, Services db/webservice/smtp/nexus, `Centron.Host.Console` als Linux-Startbefehl) - Containerbetrieb real implementiert.
- [SEKUNDÄR] `deployment/WixSharpInstaller`, `deployment/riverbird` - klassische Auslieferung.
- [KONTEXT] `azure/*.yml` - CI/CD-Ketten.
Prüfidee: `docker compose up` in Testumgebung bringt alle vier Services; Healthchecks grün.
Tracelinks: SyRS-1, SyRS-25, SyRS-29, SwRS-34
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Zielarchitektur SaaS.
Status: belegt
---
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/SwRS.md
+709
View File
@@ -0,0 +1,709 @@
# SwRS – Software Requirements Specification
Komponenten, Datenmodelle und software-interne Regeln. Jede Anforderung referenziert ihre übergeordnete SyRS-Anforderung.
---
ID: SwRS-1
Titel: Monolithische MSSQL-Datenbank mit deutschsprachigem Schema
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Datenbank (MSSQL, Schema dbo)
Vorbedingung: Schema deployed.
Fakt: `SSMS_DB_SCHEMA.sql` definiert 1558 Tabellen mit deutschen Fachnamen (`Kunden`, `Artikel`, `AngKopf`, `AufKopf`, `RechKopf`, `Mahnlauf`, `Filiale`); Prim keys `I3D` (IDENTITY) bzw. `ID`; keine UNIQUE- oder CHECK-Constraints im Dump auffindbar (Integrität liegt in der Anwendung).
Aussage: Der Software-Kern greift auf einen MSSQL-Monolithen mit historisch gewachsenem, deutsch benanntem Schema zu; Geschäftsregeln werden nicht über DB-Constraints, sondern über die Anwendungsschicht durchgesetzt.
Ergebnis: Schemaverständnis ist Voraussetzung für jede Migration; Constraint-Armut bedeutet Migrationsrisiko (Datenqualität muss neu abgesichert werden).
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` (1558x `CREATE TABLE [dbo].[...]`; Suche nach `ADD CONSTRAINT ... UNIQUE` und `CHECK (` ergibt 0 Treffer) - faktischer Constraint-Zustand.
Prüfidee: Schema-Scan im Migrationswerkzeug zählt Tabellen/Constraints und meldet fehlende Unique-Constraints als Risiko.
Tracelinks: SyRS-27, SyRS-23
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen (Dateninhalt), Benennung/Constraint-Armut = Neuimplementierung mit Domänenmodell.
Status: belegt
---
ID: SwRS-2
Titel: Belegdatenmodell: Kopf/Position/Version je Belegart
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Rechnungs-/Auftragsmodule
Vorbedingung: -.
Fakt: Schema-Tabellen `AngKopf`/`AngPos`, `AufKopf`/`AufPos`, `RechKopf`/`RechPos`, `GutKopf`/`GutPos` plus je `...Versions`-Tabellen (30 `*Versions`-Tabellen gesamt); `RechKopf.Version`-Spalte; Herkunftsreferenzen über `OriginKind`/`OriginReceiptI3D` (Belegpositionen) und `AusAuf`.
Aussage: Jede Belegart ist als Kopf-/Positions-/Versionstabellen-Tripel mit Herkunftsspalten implementiert; Änderungen erzeugen Versionssätze statt Überschreiben.
Ergebnis: Historie je Beleg ist rekonstruierbar; Belegkette ist über Herkunftsschlüssel traversierbar.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` (`CREATE TABLE [dbo].[RechKopf]` mit `Version` NOT NULL; `GutKopfVersions`, `AngKopfVersions`, `AufKopfVersions`) - real implementiertes Muster.
Prüfidee: Zweimaliges Speichern eines Belegs erzeugt zwei Sätze in Kopf- und Versions-Tabelle.
Tracelinks: SyRS-24, StRS-2
Konsolidierung: Kandidat: je Belegart eigene Tabellensysteme (Ang/Auf/Rech/Gut/Repa/RepEingang...) - im Ziel ein generisches Belegmodell mit Typ-Diskriminator erwägen.
Übernahmewürdigkeit: übernehmen (Konzept), Tabellenform je Art = Historie.
Status: belegt
---
ID: SwRS-3
Titel: Rechnungskopftabelle RechKopf mit Zahlungs- und Mahnfeldern
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Fakturierung, Mahnwesen
Vorbedingung: -.
Fakt: `RechKopf`-Spalten u. a.: `Netto`/`Brutto`/`SummeEK` als SQL-`float`, `Waehrungs`-Gruppe (`CurrencyString`, `CurrencyFactor`, `CurrencyI3D`), `ZahlKond`/`ZahlKondID`, `FaelligAm`, `Bezahlt`, `Mahnung1Datum`–`Mahnung3Datum` (+Bearbeiter), `MahnStop`, `Mahnstufe`, `LockUser`, `Status`, `Teillieferung`, `MwStNichtAusweisbar`, `LeistungImAusland`, abweichende Liefer-/Rechnungsadressen (`LiefKund*`, `RechKund*`).
Aussage: Die Rechnungskopfspeicherung umfasst Zahlungsbedingungen, Währung (mit Faktor), Zahlstatus, dreistufige Mahnhistorie, Bearbeitungssperre (`LockUser`) und Steuer-Varianten; Beträge sind als Gleitkomma (`float`) abgelegt.
Ergebnis: Alle Mahn-/Zahlungsregeln (SyRS-7/8) greifen auf diese Felder zu; float-Beträge erfordern in der Neuimplementierung die Umstellung auf `decimal`.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` `CREATE TABLE [dbo].[RechKopf]` (`[Netto] [float]`, `[Mahnstufe] [int]`, `[LockUser] [nvarchar](50)`) - direkte Spaltendefinitionen.
Prüfidee: Roundtrip-Test 0,1+0,2: Summenberechnung über float zeigt Rundungsproblem → Migration auf decimal gefordert.
Tracelinks: SyRS-7, SyRS-8, StRS-6
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen (Feldbreite), float-Typ = veraltet (Muss korrigiert werden).
Status: belegt
---
ID: SwRS-4
Titel: Filial-/Mandantentabelle mit Weichlöschung
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Administration
Vorbedingung: -.
Fakt: `Filiale` mit `MandantI3D`, `IsDefault`, `FilialStatus`, `Status`, `GeloeschtVonI3D`, `GeloeschtAm`, `Buchhaltungsnummer`, `Preisliste`, `KundenI3D`/`AnschriftI3D`/`PersonenI3D` (Filiale ist selbst als Kunde abgebildet).
Aussage: Filialen werden mandantengeführt mit Default-Kennzeichen, eigener Preisliste und Buchhaltungsnummer gepflegt; das Löschen erfolgt weich über `Geloescht*`-Spalten.
Ergebnis: Filialstamm bleibt auswertbar; Default-Filiale steuert Standardprozesse.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` `CREATE TABLE [dbo].[Filiale]` - Spaltenganzheit.
Prüfidee: Filiale löschen → Zeile bleibt, `GeloeschtAm` gesetzt, nicht mehr in Auswahl.
Tracelinks: SyRS-23, StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-5
Titel: Mahnlauf-Entität als Protokollsatz je Mahnstufe
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Mahnwesen
Vorbedingung: Mahnlauf wird ausgeführt.
Fakt: `src/backend/Centron.Entities/Entities/DbEntities/Mahnlauf.cs`: Felder `Datum`, `BearbeiterI3D`, `RechKopfI3D`, `Mahnart`, `MahnstatusAlt`, `MahnstatusNeu`, `MahnDatum`, `MahnBearbeiterI3D`, `MahnLaufNr`, `GeloeschtDatum`, `GeloeschtBearbeiterI3D`; NHibernate-Mapping in `Centron.DAO/Mappings/TemporaryEntities/MahnlaufMaps.cs`.
Aussage: Jeder Mahnvorgang wird als Mahnlauf-Satz mit Alt-/Neu-Status, Bearbeiter und Laufnummer protokolliert; Stornierte Läufe werden weich gelöscht.
Ergebnis: Mahnhistorie je Rechnung ist vollständig rekonstruierbar.
Belege:
- [PRIMÄR] `src/backend/Centron.Entities/Entities/DbEntities/Mahnlauf.cs` - Entitätsfelder als Datenvertrag.
Prüfidee: Mahnlauf starten → Satz mit MahnstatusAlt/Neu; Mahnlauf stornieren → GeloeschtDatum gesetzt.
Tracelinks: SyRS-8, StRS-6
Konsolidierung: Kandidat: Mahnstatus auch als Duplikat-Felder in `RechKopf` (Mahnung1..3Datum) - ein normalisiertes Mahnjournal im Ziel.
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE (Zuordnung „TemporaryEntities“: Ist die Persistenz endgültig oder Zwischenstand? unmöglich aus Artefakt entschieden)
---
ID: SwRS-6
Titel: Systemweiches Status-/Soft-Delete-Muster
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: alle DAO-Schichten
Vorbedingung: -.
Fakt: Schema-Indexmuster `CREATE NONCLUSTERED INDEX [..._Status]` auf fast allen Tabellen; `Status`-Spalten (z. B. `Filiale.Status`, `Mahnlauf.Status`, `ArtikelWartungsartikel.Status`); Löschspalten `GeloeschtDatum`/`GeloeschtBearbeiterI3D`/`GeloeschtVonI3D`/`GeloeschtAm`.
Aussage: Die Software führt Lösch- und Gültigkeitsstatus als Spaltenmuster über alle Entitäten; Fachabfragen filtern standardmäßig nach `Status`.
Ergebnis: Einheitliche Lösch-/Archivsemantik; Migrationswerkzeug kann nach diesem Muster migrieren.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` (z. B. `ArtikelWartungsartikel_Status`, `AnschriftSonderartikel_Status` Indizes; Löschspalten in `Mahnlauf`, `Filiale`) - flächendeckendes Muster.
Prüfidee: beliebige Liste: weich gelöschte Datensätze fehlen; Statusfilter-Regression.
Tracelinks: SyRS-23
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Prinzip; Implementierung als Weich-Löschung beibehalten.
Status: belegt
---
ID: SwRS-7
Titel: Datenschicht mit NHibernate plus NamedQueries/AdoNET
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Centron.DAO
Vorbedingung: -.
Fakt: `Centron.DAO/NHibernateConfiguration`, `Mappings`, `NamedQueries` (`NamedQueryEnums` inkl. Familie `PasswordManager.*`), `AdoNETDataAccess`, `DAOConnections`, `NHibernateLogging`; `ChangeTracking`-Ordner.
Aussage: Die Datenschicht kombiniert ein ORM (NHibernate Mappings) mit benannten SQL-Queries für Massen-/Spezialoperationen; Änderungsnachverfolgung ist DAO-seitig vorbereitet.
Ergebnis: Datenbankzugriff ist an einer Stelle gekapselt; SQL-Details sind aus dem Code auslagerbar.
Belege:
- [PRIMÄR] `src/backend/Centron.DAO/NHibernateConfiguration` + `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs` (Nutzung `NamedQueryEnums.PasswordManager.UpdateAppUserTwoFactorAuthKey`) - reale Verdrahtung ORM+NamedQueries.
Prüfidee: Query-Änderung (.hbm.xml/Named Query) ohne C#-Änderung wirksam.
Tracelinks: SyRS-1, SwRS-8
Konsolidierung: Kandidat: ORM- und AdoNET-Pfade für dieselbe CRUD-Funktionalität → ein Datenzugriffsparadigma im Ziel.
Übernahmewürdigkeit: Konzept übernehmen; NHibernate-Implementierung = Migrationsentscheidung (veraltet zugunsten moderner ORM/EF).
Status: belegt
---
ID: SwRS-8
Titel: BLSession/BaseBL-Kompositionsmuster der Geschäftslogik
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Centron.BL
Vorbedingung: -.
Fakt: Alle BL-Klassen erben `BaseBL` mit `DAOSession`-Konstruktor (`TwoFactorAuthenticationBL`, `HelpdeskStatusBL`, `RiverDivoBL` ...); Zugriff via `session.GetBL<XxxBL>()` (z. B. `TicketAuthenticationHandler`, `JwtAuthController`); `BLSession` als Unit-of-Work.
Aussage: Die Geschäftslogik ist in Session-gebildene Business-Logik-Klassen organisationiert, die über eine Sitzungs-Fassade gemeinsam mit Transaktions-/Session-Kontext instanziiert werden.
Ergebnis: Konsistenz des Datenbankkontextes über ein Use-Case; Testbarkeit über Session-Mocks.
Belege:
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs` (`using BLSession ... session.GetBL<AuthenticationTicketBL>()`) - real genutztes Muster.
Prüfidee: Use-Case über zwei BLs schreibt in einer Session; Fehler → kein teilweise Commit.
Tracelinks: SyRS-1, SwRS-9
Konsolidierung: nein
Übernahmewürdigkeit: Konzept (Service-Schicht) übernehmen; Klassenhierarchie-Details = frei neu.
Status: belegt
---
ID: SwRS-9
Titel: Result-Pattern statt Exceptions für Fachregeln
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: BL-APIs
Vorbedingung: -.
Fakt: Rückgabetypen `Result`, `Result<T>` mit Status Success/Error/Warning und Meldung im gesamten Code (z. B. `ReceiptBL.CanUserCreateNewReceiptsAtCustomerOrSupplier` liefert `Result.AsError($"Aufgrund der Mahnstufe ...")`; `Result.AsWarning` in `InvoiceZugferdBL.GetZugferFormat`); Guard-Klassen für Vorbedingungen.
Aussage: Fachliche Ablehnungen werden als Result-Objekte mit Meldung zurückgegeben; Exceptions bleiben technischen Ausnahmen vorbehalten.
Ergebnis: UI und API können Ablehnungsgründe einheitlich anzeigen; Rule-Checks sind testbar.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:10201-10214` - fachfehler als Result.Error mit Meldung.
Prüfidee: Regeltests behaupten Status+Meldung ohne Exception-Fänge.
Tracelinks: SyRS-4, SwRS-8
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - bewährtes Muster für die Neuimplementierung.
Status: belegt
---
ID: SwRS-10
Titel: Konfigurierbare Ticketstatus mit Verwendungsschutz
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Helpdesk-Verwaltung
Vorbedingung: Benutzer mit Rechtekontext.
Fakt: `HelpdeskStatusBL.GetStatus/GetClosedHelpdeskStatus/SaveHelpdeskStatus`; `DeleteHelpdeskStatus` zählt referenzierende Tickets und antwortet mit Fehler „Der Status '...' kann nicht gelöscht werden! Er wird in ... verwendet.“; Icon-Normalisierung beim Speichern.
Aussage: Ticketstatus sind vom Kunden konfigurierbare Datensätze; ein Abschlussstatus ist besonders ausgezeichnet; die Löschung verwendeteter Status wird softwareseitig verhindert.
Ergebnis: Statuskonfiguration darf Workflows nicht brechen.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskStatusBL.cs:75-100` - Löschschutz mit Referenzzählung.
Prüfidee: Status mit 1 Referenz löschen → Fehlermeldung mit Anzahl; ohne Referenz → Löschung ok.
Tracelinks: StRS-3, SyRS-14
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-11
Titel: Artikelstammmodell mit Preis-/Einheiten-/Strukturtabellen
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Warenwirtschaft
Vorbedingung: -.
Fakt: Schema: `Artikel`, `ArtikelPreis`, `ArtikelEinheit`, `ArtikelBestand`, `ArtikelStueckliste`, `ArtikelAlternativartikel`, `ArtikelErsatzteile`, `ArtikelZubehoer`, `ArtikelBilder`, `ArtikelText`, `ArtikelSpezifikationen`/`ArtikelToSpez`, `ArtikelKalkulation`, `ArtikelVar`; BL `Warehousing/ArticleUnitHelper`, `ArticleVolumePricesBL`, `SecondStockArticleBL`.
Aussage: Artikel bestehen aus Basisdatensatz plus Preis-, Bestands-, Struktur- (Stückliste/Varianten) und Merkmastabellen; Zweitlager-Artikel und Staffelpreise sind eigene Konzepte.
Ergebnis: Vollständige Artikelsteuerung für Beschaffung, Lager und Verkauf.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` Tabellenliste `Artikel*` - Datenmodell.
Prüfidee: Variante (ArtikelVar) mit eigenem Preis anlegbar; Staffelpreistabelle liefert Preis je Menge.
Tracelinks: StRS-5, SyRS-12
Konsolidierung: Kandidat: `ArtikelBilder`+`ArtikelDateiLinks`+Zubehör/alternativ/Ersatzteil-Tabellen - einheitliche Artikel-Relationen im Ziel.
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-12
Titel: Lagerbestand je Artikel (`ArtikelBestand`)
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Lager/Logistik
Vorbedingung: -.
Fakt: Tabelle `ArtikelBestand` im Schema; Barcode-Handling `BarcodeBL`/`BarcodeHistoryBL`; WPF-Module `Warehousing`, `Logistic`.
Aussage: Das System führt Lagerbestände je Artikel (mit Historie über Barcode-Scans) als Grundlage für Verfügbarkeitsangaben in Belegen.
Ergebnis: Verfügbarkeit und Kommissionierung greifen auf dieselbe Bestandsführung zu.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` Tabelle `ArtikelBestand` - Bestandsdatenhaltung.
- [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/BarcodeHistoryBL.cs` - Scanhistorie.
Prüfidee: Wareneingangs-Verbuchung erhöht Bestand; Verkauf reduziert ihn (Vorbehalten/Offen separat?).
Tracelinks: SyRS-1, StRS-5, StRS-4
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE (Bestandsbewegungsregeln - Reservierung, Sperrbestand - nicht im Detail belegt)
---
ID: SwRS-13
Titel: UserRightsConst: zentraler Rechtekonstantenbaum
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: alle Fachmodule
Vorbedingung: -.
Fakt: `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs` als verschachtelte Konstantenklassen (`UserRightsConst.Sales.Customer.Helpdesk.*`, `UserRightsConst.Admin.*`, `Controlling.Analytics.*`); `CentronRights.md` dokumentiert Teile daraus inkl. Semantik „restricting right“; Hinweis im Pfad `EntitiesWrongPlace` (verlegter Code).
Aussage: Alle Fachrechte sind als eindeutige Konstanten in einem benannten Baum definiert und werden client- wie serverseitig gegen dieselbe Quelle geprüft.
Ergebnis: Rechte sind auffindbar, dokumentierbar und reproduzierbar prüfbar.
Belege:
- [PRIMÄR] `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs` - maßgebliche Konstantenquelle.
- [SEKUNDÄR] `CentronRights.md` - dokumentierte Teilmengen inkl. restriktiver Semantik.
Prüfidee: Refintegrity-Test: jede im UI/API referenzierte Konstante existiert genau einmal.
Tracelinks: SyRS-4, StRS-9
Konsolidierung: Kandidat: Pfad „EntitiesWrongPlace“ signalisiert Duplikat-/Fehlablegung → Ziel: ein Identity-/Rights-Modul.
Übernahmewürdigkeit: übernehmen (Konzept), Dateiablegung = Workaround.
Status: belegt
---
ID: SwRS-14
Titel: AuthentisierungsTicket-Validierung (Ticket → Access-Token Fallback)
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: AuthenticationTicketBL, TicketBL, AccessTokenBL
Vorbedingung: Token im Request.
Fakt: `AuthenticationTicketBL.GetAuthTicketInfo(authTicket, ipAddress, apiMethod)`: zuerst `_ticketBL.GetTicket(...)`, bei Fehlschlag `_accessTokenBL.ValidateToken(token, ipAddress, apiMethod)`; Ergebnis `AuthTicketInfo` mit `AppUserI3D`, `IsConnectedThroughAccessToken`; Exception `TicketExpiredException` existiert.
Aussage: Die zentrale Validierungsroutine löst zuerst Sitzungs-Tickets auf und fällt auf maschinelle Access-Token zurück, wobei IP und API-Methode in die Access-Token-Prüfung einfließen.
Ergebnis: Beide Authentisierungsarten münden in dieselbe Nutzeridentität für die Rechteprüfung.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/AuthenticationTicketBL.cs:25-47` - Prüfende Stelle mit Fallback-Reihenfolge.
Prüfidee: Ticket- und Token-Request erzeugen dieselbe `AppUserI3D`; abgelaufenes Ticket → Fail.
Tracelinks: SyRS-2, SyRS-3, SwRS-15
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen (Konzept); duale Tokenwelt = Migrationskonsolidierung (siehe SyRS-2).
Status: belegt
---
ID: SwRS-15
Titel: TOTP-Schlüsselverwaltung je AppUser
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: TwoFactorAuthenticationBL
Vorbedingung: AppUser vorhanden.
Fakt: `TwoFactorAuthenticationBL.AppUserTwoFactorAuthKeyExists`, `UpdateAppUserTwoFactorAuthKey` (Named Query `PasswordManager.UpdateAppUserTwoFactorAuthKey`), `ValidateAuthenticationPin` via `Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin`; Schlüssel je `AppUserI3D` in den Personenstammdaten („in der Personalverwaltung hinterlegt“ laut Fehlertext).
Aussage: Der TOTP-Schlüssel wird je Benutzer persistiert, kann gesetzt/geprüft werden, und das Fehlen wird mit Fachmeldung quittiert statt still zugelassen.
Ergebnis: 2FA ist pro Benutzer aktivierbar und prüfbar; fehlender Schlüssel ist sichtbar.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs` (Zeilen 16-54) - vollständiger Prüf-/Setzpfad inkl. Fehlermeldungen.
Prüfidee: Schlüssel setzen → Exists==true; PIN gegen falschen Schlüssel → „ungültig“.
Tracelinks: SyRS-5, StRS-9
Konsolidierung: Kandidat: Named-Query-Familie „PasswordManager“ für 2FA und Passwortverwaltung → Identitätsmodul.
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-16
Titel: SHA-1-Passwort-Hash-Implementierung (Legacy)
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: CryptoUtils
Vorbedingung: -.
Fakt: `CryptoUtils.CreatePasswordHash`: `SHA1.Create().ComputeHash(UTF8(pwd + salt))`, Hex-Darstellung; Salt via `RandomNumberGenerator` (kryptografisch sicher), aber Hash-Funktion schnell/SHA-1.
Aussage: Die aktuelle Passwortaufbereitung verwendet SHA-1 über Passwort+Salt-Konkatenation; diese Implementierung darf im Zielsystem nur noch als Lesepfad für Migrationsexistierenden dienen.
Ergebnis: Kein Neusetzen von SHA-1-Hashes; Migrationspfad auf Argon2/PBKDF2.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Core/CryptoUtils.cs:26-33` - exakte Implementationsstelle.
Prüfidee: Unit-Test gegen bekannten Vektor; Migrationsflag „Hash-Algorythmus“ pro Benutzer.
Tracelinks: SyRS-6, StRS-9
Konsolidierung: nein
Übernahmewürdigkeit: veraltet (als Speicherverfahren), Lese-/Migrationszweck befristet übernehmen.
Status: belegt
---
ID: SwRS-17
Titel: Limitberechnungsalgorithmus (Netto/Brutto, Herkunftsverrechnung)
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: ReceiptBL
Vorbedingung: Speichern eines Kundenbelegs.
Fakt: `CheckIfCustomerLimitIsReached`: Modus aus `CreditLimitCalculationKind` (1=Net, sonst Gross; null/2/`CreditLimit<=0` ⇒ Prüfung deaktiviert); Aggregation über alle Belegarten via `TakesPlaceInLimitCalculation`; Abzug bereits verbrauchter Beträge des vorherigen Versionsstands und von Herkunftsbelegen (`GetLimitUsedInOriginReceipts`); Dialog `ShowCustomerLimitExceededDialog`; Fortsetzung nur mit `SaveAlthoughCustomerLimitExceeded=true`; Fortschreibung `customer.CreditLimitAvailable`.
Aussage: Die Kreditlimitprüfung berechnet den Limitverbrauch belegartübergreifend netto oder brutto, verrechnet Vorversion und Herkunftbelege doppelt schützend, erzwingt eine Bestätigungsdialog-Schwelle und führt den verfügbaren Rest im Kundenstamm fort.
Ergebnis: deterministischer, testbarer Limitwert pro Speichervorgang ohne Doppelzählungen.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:8636-8735` - vollständige Methode inkl. Bedingungen.
Prüfidee: Testfallmatriz: Modus Net/Gross; Lieferschein nach Anzahlung (Herkunft) zählt nicht doppelt; Bestätigungsflag.
Tracelinks: SyRS-7, SwRS-3
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Exaktgeschäftsregel für Neuimplementierung.
Status: belegt
---
ID: SwRS-18
Titel: Beleganlage-Gate: Recht + Mahnstufe
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: ReceiptBL, SpecificLogics je Belegart
Vorbedingung: Neuanlage eines Belegs.
Fakt: `CanUserCreateNewReceiptsAtCustomerOrSupplier`: (1) `HasRightToCreateANewReceipt(appUser)` je Belegart sonst Fehler „Der Benutzer hat nicht das Recht neue Belege ... anzulegen.“; (2) `GetCustomerOrSupplierDunningLevel<TReceipt>() > 0` und `BlockNewReceiptsDunningLevel(...) > 0 && dunningLevel >= blockOnLevel` ⇒ Fehler.
Aussage: Vor jeder Belegneuanlage erzwingt eine einzige Backend-Methode beide Gates (Fachrecht, Mahnstufenschwelle je Belegart) - UI-Konfiguration kann die Prüfung nicht umgehen.
Ergebnis: Manipulationssichere Anlagelogik für Auftrag/Angebot/Rechnung etc.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:10194-10222` - Prüfende Stelle.
Prüfidee: Direkter Aufruf ohne UI-Rechte → Fehler; DunningLevel-Schwelle grenzwertig testen (== und >).
Tracelinks: SyRS-8, StRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-19
Titel: Belegverlauf (Receipt Progression) mit Größenbegrenzung
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: ReceiptProgressionBL
Vorbedingung: Beleg-Objektreferenz (objectI3D/objectKind).
Fakt: `ReceiptProgressionBL.GetReceiptProgression(objectI3D, objectKind, limit)` mit `MaxReceiptProgressionSize`; Rückgabe `ReceiptProgressionInfoDTO`-Liste; `GetDirectoryI3DsFromReceiptProgression` für Dokumentenaufrufe.
Aussage: Das System stellt den vollständigen Belegfolgepfad eines Objekts (Angebot→…→Rechnung, inkl. Gutschriften) begrenzt auf eine Maximaltiefe bereit und leitet Dokumentverzeichnisse daraus ab.
Ergebnis: Sachbearbeiter sieht Proesskette eines Vorgangs ohne unbegrenzte Abfragen.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptProgressionBL.cs` (Methoden_signaturen inkl. limit/MaxReceiptProgressionSize) - implementierte Begrenzung.
Prüfidee: Kette mit 20 Stufen → genau 20 Einträge, Reihenfolge korrekt.
Tracelinks: StRS-2, SyRS-24
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE (konkreter Zahlenwert von MaxReceiptProgressionSize nicht extrahiert; Sortier-/Filterlogik nicht im Detail gelesen)
---
ID: SwRS-20
Titel: Tokenbasierte Kundenänderungen an Web-Belegen
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Web-Kunde, ReceiptBL
Vorbedingung: Beleg mit Token/Änderungsanfrage-Bezug.
Fakt: `ReceiptBL.GetWebReceiptItemChangeRequests(filter)`, `ChangeWebReceiptPurchaseOrderNumber(token, ...)` (Zeile 5936), `ChangeWebReceiptAddress(token, ReceiptAddressKind, ...)` (Zeile 6116) - Änderungsvorgänge gegen Token statt gegen vollen Benutzerkontext.
Aussage: Das System erlaubt authentifizierte Portaländerungen (Liefer-/Rechnungsadresse, Bestellnummer) ausschließlich über gültige Belegtokens und protokolliert sie als Änderungsanfragen für den Sachbearbeiter.
Ergebnis: Externe Änderung ohne vollen Schreibzugriff; interne Freigabe bleibt erhalten.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:5894-6116` - Token-Methoden inkl. Filtertyp.
Prüfidee: Ungültiger Token → Fehler; gültiger Token → Änderung landet als Change-Request, nicht als direkte Änderung.
Tracelinks: SyRS-15, StRS-8
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-21
Titel: ZUGFeRD-/XRechnung-Formatauswahl und Import
Ebene: SwRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: InvoiceZugferdBL, ZugferdParseBL
Vorbedingung: Kunde mit Exportprofil.
Fakt: `InvoiceZugferdBL.GetZugferFormat(bool? exportZUGFeRD, ReceiptInvoiceSettingsDTO settings)` → `ZugferdKind.ZUGFeRD_1_0` (Warnung „Zugferd is deactivated for customer“), sonst `settings.ActiveZugferdInterface` (Default `ZugferdKind.ZUGFeRD_XInvoice_3_0_1`); Datei `InvoiceZugferdBL.Zugferd10.cs` (Alt-Parser), `ZugferdParseBL.cs`, Gateway `ZUGFeRD21_Extended`, `ZugferdImportController`.
Aussage: Format und Version der elektronischen Rechnung werden pro Konfiguration aufgelöst und gecacht; Altformate bleiben importierbar.
Ergebnis: Konformer Ausgang nach aktuellem Standard, Importhistorie bleibt lesbar.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs:85-100` - Formatentscheidung + Cache-Key.
Prüfidee: Umstellung `ActiveZugferdInterface` → Ausgang wechselt Format ohne Codeeingriff.
Tracelinks: SyRS-9, StRS-6
Konsolidierung: Kandidat: `Zugferd10`-Altcode vs. XInvoice - Altimport beibehalten, Ausgang nur aktuell.
Übernahmewürdigkeit: Ausgang übernehmen; ZUGFeRD-1.0-Ausgang veraltet.
Status: belegt
---
ID: SwRS-22
Titel: ebInterface-4.3-Export mit Vorvalidierung
Ebene: SwRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: EbInterfaceLogic
Vorbedingung: österreichischer Rechnungsempfänger.
Fakt: `EbInterfaceLogic.GenerateFile(ReceiptInfo)`: `ValidateValues` vor Dokumenterzeugung; festes Namespace-`http://www.ebinterface.at/schema/4p3/`; Datums-/Betragsformate (en-US-Kultur für Zahlen).
Aussage: Der ebInterface-Export validiert Rechnungswerte vor der XML-Erzeugung gegen die 4.3er-Spezifikation und nutzt stabile Formatkonstanten.
Ergebnis: Abweisungsarme AT-E-Rechnungen.
Belege:
- [PRIMÄR] `src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs` (`_ebNamespace`, `ValidateValues`, `DATEFORMAT`, `AMOUNTFORMAT`) - implementierte Validierung.
Prüfidee: Rechnung ohne UID → Fehler vor Ausgabe; positives XML validiert gegen Schema.
Tracelinks: SyRS-9, StRS-6
Konsolidierung: Kandidat: neben ZUGFeRD zweiter E-Rechnungs-Provider → gemeinsames E-Rechnungs-Subsystem.
Übernahmewürdigkeit: übernehmen (AT-Markt).
Status: belegt
---
ID: SwRS-23
Titel: Gateway-Kapselung: XSD-gestützte Bestellnachrichten
Ebene: SwRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Centron.Gateway
Vorbedingung: -.
Fakt: `Centron.Gateway/Concerto/ConcertoOrder.cs` + `ConcertoOrder.xsd` ( Serialisierung via XSD), `OpenTrans`/`OpenTrans1_0` (zwei Versionen), `Import`/`Export`-Ordner, `MspCollector`.
Aussage: Ausgehende/nachrichtenförmige Datenaustausche werden im Gateway-Layer über typisierte, schema-validierte Modelle abgebildet; Versionsverzweigungen (OpenTrans 1.0/aktuell) sind gekapselt.
Ergebnis: Partnerformate ohne Einfluss auf Fachlogik austauschbar.
Belege:
- [PRIMÄR] `src/backend/Centron.Gateway/Concerto/ConcertoOrder.xsd` - Schema als Vertragsanker.
- [SEKUNDÄR] `OpenTrans`/`OpenTrans1_0` Nebeneinander - Versionskapselung.
Prüfidee: Serialisierte Bestellung gegen XSD validieren; ältere OpenTrans-Version testbar.
Tracelinks: SyRS-11, StRS-4
Konsolidierung: Kandidat: OpenTrans 1_0 Alt +aktuell, Concerto +EDI_* Formate - ein Connector-SDK.
Übernahmewürdigkeit: Konzept übernehmen; Altversionen = veraltet.
Status: belegt
---
ID: SwRS-24
Titel: Temporäres Entity-Mapping für Mahnlauf
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Centron.DAO/Mappings/TemporaryEntities
Vorbedingung: -.
Fakt: `MahnlaufMaps.cs` liegt im Ordner `TemporaryEntities`, obwohl `Mahnlauf` eine Dauerentität ist; reguläre Mappings liegen in `Centron.DAO/Mappings`.
Aussage: Das Mapping des Mahnlaufs ist provisorisch abgelegt; die finale Persistenzstrategie des Mahnjournals ist im Bestand nicht eindeutig entscheidbar.
Ergebnis: Bei Migration ist die Mahnlauf-Historie gezielt zu verifizieren.
Belege:
- [SEKUNDÄR] `src/backend/Centron.DAO/Mappings/TemporaryEntities/MahnlaufMaps.cs` (Ordnerbezeichnung) - Ablageklassifikation „temporär“.
Prüfidee: Zählen der Mahnlauf-Sätze vor/nach Migrationslauf.
Tracelinks: SwRS-5, SyRS-8
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - provisorische Ablage gezielt auflösen.
Status: HYPOTHESE (Warum „Temporary“? Restmigration oder Zwischenlösung - Beleg fehlt)
---
ID: SwRS-25
Titel: DAO-seitiges Change-Tracking
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Centron.DAO/ChangeTracking
Vorbedingung: -.
Fakt: Ordner `Centron.DAO/ChangeTracking`; Kommentar im `ReceiptBL`-Limitpfad: „Change-tracking should do the trick here“ (zur Nachführung von `CreditLimitAvailable`).
Aussage: Änderungen an persistierten Entitäten werden auf DAO-Ebene nachverfolgt und dienen als Grundlage für Protokollierung und abgeleitete Feldaktualisierung.
Ergebnis: Änderungsprotokolle speisen Revision und Statistik ohne manuelle Logging-Aufrufe.
Belege:
- [SEKUNDÄR] `src/backend/Centron.DAO/ChangeTracking` (Ordner), `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs` (Kommentar zur Nutzung) - Mechanismus vorhanden.
Prüfidee: Feldänderung → Tracking-Eintrag ohne BL-seitiges Logging.
Tracelinks: SyRS-24, SwRS-7
Konsolidierung: Kandidat: ChangeTracking + `ReceiptLogBL` + Nexus-Historie - ein Audit-Abo.
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE (funktionsumfang der Tracking-Tabellen nicht aus Artefakten belegt)
---
ID: SwRS-26
Titel: In-Memory-Logging-Ziel für Live-Diagnose
Ebene: SwRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Centron.Common/Logging
Vorbedingung: Logging initialisiert.
Fakt: `InMemoryTarget.cs`/`InMemoryLogging.cs`/`LogEntry.cs` in `Centron.Common/Logging`; Nexus zeigt Log-Kategorien in Systeminfo (Changelog).
Aussage: Das System puffert Logeinträge speicherintern, um sie in UI-Diagnosmasken ohne Datei-/DB-Lesezugriff darzustellen.
Ergebnis: Support-Diagnosgespräche mit Live-Logs aus der Sitzung.
Belege:
- [PRIMÄR] `src/backend/Centron.Common/Logging/InMemoryTarget.cs` - implementierter Appender.
Prüfidee: Fehler provozieren → Eintrag sofort in Systeminfo sichtbar; Ringpuffer-Grenze (Größe?) testen.
Tracelinks: SyRS-28
Konsolidierung: Kandidat: InMemory-Log vs. NLog-Datei (LogManager) - zentrale Logging-Pipeline.
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-27
Titel: WPF-Modulsystem mit AppModuleControllern
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Centron.WPF.UI
Vorbedingung: Client gestartet.
Fakt: 29 Modulordner in `Centron.WPF.UI/Modules`; je Modul `*AppModuleController.cs` + `View.xaml` + `ViewModel.cs` (Beispiel `Finances/Dunning/DunningOverviewAppModuleController.cs`); `Centron.WPF.UI.Extension` mit `Mvvm`, `Modules`, `Extensibility`.
Aussage: Die Desktop-Oberfläche ist modular nach Fachgebieten aufgebaut; jedes Fachmodul wird über einen Modulcontroller mit eigenem View/ViewModel-Lifecycle eingebunden.
Ergebnis: Funktionen sind einzeln aktivierbar; Neuimplementierung kann Modul-und Rollenmodell direkt übernehmen.
Belege:
- [PRIMÄR] `src/centron/Centron.WPF.UI/Modules/Finances/Dunning/DunningOverviewAppModuleController.cs` - Modulcontroller-Pattern real.
- [SEKUNDÄR] Modulverzeichnisliste (Administration … Warehousing) - Funktionsbreite.
Prüfidee: Modul ohne Berechtigung öffnet keine Navigation/View.
Tracelinks: SyRS-1, SyRS-4, StRS-9, StRS-12, SwRS-30
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen (modulare Struktur), WPF-Technologie = Client-Austausch gegen Web.
Status: belegt
---
ID: SwRS-28
Titel: Absicherung der Echtzeit-Hubs mit Secret Key
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: SignalR-Hubs
Vorbedingung: Hub-Konfiguration.
Fakt: `RealTimeServices/SecretKeyRequirement.cs` und `SecretKeyHandler.cs` (Handler prüft Secret beim Hub-Zugriff).
Aussage: Der Aufbau von SignalR-Verbindungen ist nur mit gültigem Secret Key zulässig.
Ergebnis: Keine anonymen Echtzeit-Abonnements von Benachrichtigungen/Chat.
Belege:
- [PRIMÄR] `src/webservice/Centron.Host/RealTimeServices/SecretKeyHandler.cs` - durchgesetzte Prüfung.
Prüfidee: Hub-Connect ohne Header/Query-Secret → Handshake-Fehler.
Tracelinks: SyRS-16, SyRS-21
Konsolidierung: Kandidat: Secret-Key-Pfad neben Ticket/JWT - einheitliche Hub-Authentifizierung.
Übernahmewürdigkeit: Konzept übernehmen; Secret-Key-Mechanik = Workaround.
Status: belegt
---
ID: SwRS-29
Titel: IndexBuilder mit deutschem Analyzer
Ebene: SwRS
Typ: nicht-funktional
Qualitätsmerkmal: Performance-Effizienz
Akteur: IndexSearch-Subsystem
Vorbedingung: -.
Fakt: `IndexSearch/IndexBuilder.cs`, `GermanAnalyzer.cs`, `Indexes/TicketFulltextIndex.cs`, `ObjectIndexingFailedException`.
Aussage: Die Volltextindizes werden dediziert aufgebaut und mit sprachspezifischer Analyse (Deutsch) versehen; Indexierungsfehler werden als typisierte Exception behandelt.
Ergebnis: Sprachlich sinnvolle Suchtreffer; robuste Index-Pipeline.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs` - implementierte Sprachanalyse.
Prüfidee: Lemmata-Test („bestellungen“→„bestellung“); fehlgeschlagene Indexierung zählt hoch, aber reißt Suche nicht ab.
Tracelinks: SyRS-17
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-30
Titel: Wiederverwendbare Steuerelements-Bibliothek Centron.Controls
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal: Wartbarkeit
Akteur: WPF-Clients (Desktop, ConnectionManager)
Vorbedingung: -.
Fakt: `src/shared/Centron.Controls` mit 40+ Funktionsordnern (PositionGrid, MailTemplates, PasswordManager, Telephony, PdfScanning, ExcelExport, TaskManagement, CustomerManagement, EmailTemplate, FileViewer, Webservice …) + `Centron.Controls.Preview`; `Centron.Core` (Mvvm, GoogleAuthenticator, TotpAuth, Threading, PdfScanning).
Aussage: UI-Funktionsbausteine und Kernutils (MVVM, TOTP, Threading, PDF) sind in gemeinsamen Bibliotheken gekapselt und werden von mehreren Hosts genutzt.
Ergebnis: Konsistente Bedienung; Migrationsobjekt klar abgrenzbar.
Belege:
- [SEKUNDÄR] Ordnerbestand `src/shared/Centron.Controls/*` - Bausteinbibliothek real in Nutzung.
Prüfidee: Steuerelement in zwei Hosts mit gleicher Konfiguration testen.
Tracelinks: SyRS-1, StRS-10, StRS-15, SwRS-27
Konsolidierung: Kandidat: Controls- und Nexus-Komponenten doppeln Dialoge (Mail-Editor, Datei-Viewer) → geteilte Komponenten-Bibliothek im Web-Stack.
Übernahmewürdigkeit: übernehmen (Pattern), konkrete Controls = WPF-Sonderbau.
Status: belegt
---
ID: SwRS-31
Titel: Vertragsbewertung Alt (ContractEvaluationOld) neben Neu (ContractEvaluation2)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertragsabrechnung
Vorbedingung: Verträge im Bestand.
Fakt: Zwei parallele Modulordner `Centron.WPF.UI/Modules/Finances/ContractEvaluationOld` und `ContractEvaluation2` in derselben Anwendung.
Aussage: Die Vertragsbewertung existiert in zwei Implementierungsgenerationen gleichzeitig; der Migrationszustand (welcher Bestand nutzt welche Version?) ist aus dem Code nicht eindeutig ableitbar.
Ergebnis: Nur die aktuelle Generation ist in das Zielsystem zu übernehmen; Altbestand erfordert eine Datenüberführungsprüfung.
Belege:
- [SEKUNDÄR] Verzeichnisse `Modules/Finances/ContractEvaluationOld`, `Modules/Finances/ContractEvaluation2` - Nebeneinander im Produktivbaum.
Prüfidee: Navigationsanalyse: welcher Einstieg führt noch zur Old-Version?
Tracelinks: SyRS-14, SyRS-22, StRS-7
Konsolidierung: Kandidat: ContractEvaluationOld/2 = dieselbe Funktion zweier Stände; Old löschen.
Übernahmewürdigkeit: veraltet (Old), übernehmen (2).
Status: HYPOTHESE (Nutzungsverteilung Alt/Neu unbekannt)
---
ID: SwRS-32
Titel: Kunden-Filialzuordnung und Kundenkostenstellen
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Adressstamm
Vorbedingung: -.
Fakt: `Accounts/CustomerToBranchBL.cs`, `Accounts/CustomerCostCenterBL.cs`, `AccountTypeBL.cs`, `AccountAddressContactBL.cs`; Tabellen `KundeToKonzern`, `AbweichendeAnschrift`.
Aussage: Kunden können mehreren Filialen zugeordnet und um Kostenstellen/Konzernstrukturen sowie abweichende Anschriften erweitert werden.
Ergebnis: Beleg-/Auswertungslogik kann Filial- und Kostenstellenbezug nutzen.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Accounts/CustomerToBranchBL.cs` + `SSMS_DB_SCHEMA.sql` (`KundeToKonzern`, `AbweichendeAnschrift`) - Modell + Pflege-BL.
Prüfidee: Kunde zwei Filialen zuordnen; Beleg zeigt je Filialcontext korrekte Konditionen.
Tracelinks: SyRS-23, StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-33
Titel: Client-Konfigurations-/Verbindungsverwaltung ConnectionManager
Ebene: SwRS
Typ: nicht-funktional
Qualitätsmerkmal:
Akteur: IT-Betrieb
Vorbedingung: Client-Installation.
Fakt: `c-entron.misc.ConnectionManager` mit Views `ConnectionManagerView`, `HardwareIdView`, `LicenseView`, `TwoFactorAuthTestView`, `SQLServerCheckTool`, `AdditionalServiceViewModel`; Compose mountet `WebServiceConfig.xml`.
Aussage: Das System stellt ein Konfigurationswerkzeug bereit, mit dem Zielverbindungen (Webservice/DB), Hardware-ID/Lizenz und Zusatzdienste geprüft und gesetzt werden.
Ergebnis: Installation/Diagnose ohne manuelle Config-Eingriffe.
Belege:
- [SEKUNDÄR] View/ViewModel-Namen in `c-entron.misc.ConnectionManager` + `docker/compose/compose.yaml` (WebServiceConfig.xml) - Funktionsumfang benannt.
Prüfidee: SQL-Servercheck gegen Testinstanz; Config-Änderung übernimmt Client ohne manuellen Neustart (prüfen).
Tracelinks: SyRS-25, SyRS-2
Konsolidierung: Kandidat: ConnectionManager vs. zentrale Server-Konfiguration (`ConfigurationController.cs`) - ein Konfigurations-Hub.
Übernahmewürdigkeit: übernehmen (Diagnosegedanke); Desktop-Tool = Web-Admin counterpart.
Status: HYPOTHESE (Prüftiefe des SQLServerCheckTool nicht belegt)
---
ID: SwRS-34
Titel: Automatische Versionsableitung (Nerdbank.GitVersioning)
Ebene: SwRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: Build
Vorbedingung: Git-Repository.
Fakt: `version.json` (Nerdbank.GitVersioning-Schema, `version: 2.0.2611-alpha`, cloudBuild enabled); Changelog-Versionsserien (`2409.x`) im Nexus.
Aussage: Die Produktversion wird aus dem Versionsverwaltungszustand automatisch abgeleitet; Buildnummern sind reproduzierbar.
Ergebnis: Nachvollziehbare Auslieferungen je Build.
Belege:
- [PRIMÄR] `version.json` (Schema-URL Nerdbank.GitVersioning, Version 2.0.2611-alpha) - eingerichtetes Werkzeug.
Prüfidee: Build-Assembly-Version == berechnete GitVersion.
Tracelinks: SyRS-29, StRS-16
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-35
Titel: Massenaktualisierung von Fachdaten
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Sachbearbeiter/Administration
Vorbedingung: Auswahl von Zielobjekten.
Fakt: Dedizierte BL `src/backend/Centron.BL/MassUpdate` und WPF-Modul `src/centron/Centron.WPF.UI/Modules/Massenupdates` (Modulordner und BL-Ordner existieren nebeneinander).
Aussage: Das System soll Massenänderungen an Fachobjekten (Stammdaten/Belege) über eine geführte Funktion bündeln.
Ergebnis: Pflegeaufwand für Serienänderungen sinkt; Änderungen bleiben protokolliert (zu prüfen).
Belege:
- [SEKUNDÄR] `src/backend/Centron.BL/MassUpdate` + `src/centron/Centron.WPF.UI/Modules/Massenupdates` - eigene BL+Modul für „Massenupdates“ benennen die Funktion.
Prüfidee: Sammeländerung an mehreren Artikeldatensätzen; Anzahl geänderter Sätze == Auswahl.
Tracelinks: SyRS-1, StRS-5
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Standard-ERP-Pflegefunktion.
Status: HYPOTHESE (umgeschaltbare Felder/Objektarten und Berechtigungsanbindung aus Ordnernamen nicht ableitbar)
---
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/SyRS.md
+631
View File
@@ -0,0 +1,631 @@
# SyRS – System Requirements Specification
Systemverhalten, Schnittstellen, Sicherheits- und Performance-Anforderungen. Ebene über den Anforderungen der SwRS.
---
ID: SyRS-1
Titel: Dreischichtige Client-Server-Architektur mit zentralem Webservice
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: WPF-Client, Nexus-Web, c-entron Webservice (Centron.Host), MSSQL
Vorbedingung: Webservice Instanz läuft (Port 4321 im Compose-Stack).
Fakt: `docker/compose/compose.yaml` definiert Services `db` (MSSQL), `webservice` (`Centron.Host.Console`), `nexus` (`CentronNexus.Host`); WPF-Client greift über `Centron.WebServices.Core/RestRequests` auf REST-Endpunkte von `Centron.Host` zu; Host bietet Swagger/API-Versionierung (`RegisterCentronApiVersioning.cs`, `RegisterCentronSwagger.cs`).
Aussage: Das System soll alle Fachfunktionen zentral in einem Webservice bündeln, auf den Desktop-Client (WPF) und Web-Frontends (Nexus/Blazor) über versionierte REST-Schnittstellen zugreifen; die Datenbank (MSSQL) wird ausschließlich vom Webservice erreicht.
Ergebnis: Neue Frontends können ohne Geschäftslogik-Änderung angebunden werden; API-Verträge sind versioniert.
Belege:
- [PRIMÄR] `docker/compose/compose.yaml` - reale Topologie: nur webservice hat DB-Abhängigkeit (`depends_on: db`), Nexus hängt am Webservice.
- [SEKUNDÄR] `src/webservice/Centron.Host/Logic/RegisterCentronApiVersioning.cs` - API-Versionierung eingerichtet.
- [SEKUNDÄR] `src/shared/Centron.WebServices.Core/RestRequests` - Client-seitiger REST-Layer.
Prüfidee: Nexus ohne direkten DB-Zugriff deploybar (Environment zeigt keine Connectionstring-Abhängigkeit); gleiche Business-Regel (Kreditlimit) greift über Client und API.
Tracelinks: StRS-1, StRS-16, SyRS-2, SwRS-8, SwRS-34
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - genau die Zielarchitektur der Neuimplementierung.
Status: belegt
---
ID: SyRS-2
Titel: Authentisierung über Authentifizierungs-Tickets und Access-Token
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Webservice (TicketAuthenticationHandler), Client, Drittsystem
Vorbedingung: Client hat Login durchlaufen bzw. Access-Token erhalten.
Fakt: `src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs`: extrahiert Token aus Request, validiert über `AuthenticationTicketBL.GetAuthTicketInfo(token, ipAddress, apiMethod)` (erst ConnectionTicket, dann Access-Token-Fallback mit IP- und API-Methodenprüfung) und setzt Claims (`UserIdentifier`, `AuthenticationTypeIdentifier`).
Aussage: Das System soll jede API-Anfrage gegen ein serverseitig verwaltetes Ticket oder einen Access-Token authentisieren und dabei Client-IP und aufgerufene Methode in die Validierung einbeziehen.
Ergebnis: Unbekannte/abgelaufene Tokens führen zu Authentisierungsfehler; der Nutzer ist einer AppUser-Identität zugeordnet.
Belege:
- [PRIMÄR] `src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs` (`HandleAuthenticateAsync`, `ValidateTicketOrAccessToken` mit ipAddress/apiMethod-Parametern) - durchgesetzte Prüfung.
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/AuthenticationTicketBL.cs:25-47` - Ticket-zuerst-, Access-Token-Fallback-Logik.
Prüfidee: Request ohne Ticket → 401 „No authentication ticket found“; Ticket fremder IP → Validierungsfehlertest gemäss Access-Token-Konfiguration.
Tracelinks: StRS-9, SyRS-3, SyRS-4, SwRS-14
Konsolidierung: Kandidat: Ticket-Login (interne Clients), Access-Token (Maschine-Maschine) und WebAccount-Login (Nexus) sind drei Authentisierungswege; im Zielsystem auf ein Token-Konzept (OAuth2/OIDC) konsolidieren.
Übernahmewürdigkeit: übernehmen (Konzept), die Ticket-Implementierung selbst ist ein Migrationskandidat (Workaround-charakter).
Status: belegt
---
ID: SyRS-3
Titel: Client-Anmeldung per JWT-Bearer mit Anwendungsprüfung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: WPF-Client (Login), Authentifikator
Vorbedingung: Client-Installation besitzt Application-Guid; Nutzer kennt Zugangsdaten.
Fakt: `JwtAuthController` (`[Route("jwt")]`, `POST jwt/login`): verlangt JwtBearer-Principal, ermittelt `ApplicationGuidHelper.GetDecryptedApplicationGuid(...)` je Applikation, übergibt `JwtLoginRequest` (Device, AppVersion) an `AuthenticatorFactory.GetAuthenticator(...)`.
Aussage: Das System soll die Client-Anmeldung über einen JWT-Login-Endpunkt abwickeln, dabei die aufrufende Anwendung (Application-Guid), Gerät und App-Version verifizieren und die eigentliche Prüfung an eine austauschbare Authentifikator-Implementierung delegieren.
Ergebnis: Nur registrierte Anwendungen erhalten ein Sitzungsticket; Anmeldeversuche sind mit Gerät/AppVersion protokolliert.
Belege:
- [PRIMÄR] `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs` (`LoginWithBearer`, Prüfung `ClaimsIdentity.IsAuthenticated`, Application-Guid-Abgleich) - durchgesetzte Prüfkette.
Prüfidee: Login mit unbekanntem Application-Parameter → BadRequest „Application not found.“; Login ohne Bearer-Token → 401.
Tracelinks: StRS-9, SyRS-2, SyRS-5, SyRS-25, SwRS-14
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Muster für Mandanten-/App-Registrierung im SaaS.
Status: belegt
---
ID: SyRS-4
Titel: Deklarative Rechteprüfung in der Web-API (401/403)
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: API-Consumer, Authorization-Filter
Vorbedingung: Anfrage ist authentisiert (SyRS-2/3).
Fakt: `Centron.Controllers/Authorization/` implementiert `AuthorizeUserRightAttribute`, `AuthorizeAnyUserRightAttribute`, `AuthorizeUserRightsAllAttribute`/`AuthorizeAllUserRightsAttribute` sowie `AuthorizeCentronHostedAttribute`; README dokumentiert Filter-Ausführung vor der Action und HTTP-Codes 401 (nicht authentisiert) / 403 (Recht fehlt); einschränkende Rechte laut `CentronRights.md` (nur eigene, nur eigene Filiale/Abteilung).
Aussage: Das System soll jede API-Operation deklarativ an Fachrechte binden (einzeln, ODER-Verknüpfung, UND-Verknüpfung, Hosted-Umgebung) und fehlende Rechte mit 403 ablehnen; daten einschränkende Rechte sind zusätzlich in den Abfragen umzusetzen.
Ergebnis: Funktions- und Datenumfang jeder API-Antwort entsprechen dem Rollenbild des Nutzers.
Belege:
- [PRIMÄR] `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs` - durchgesetzte Prüfung im Authorization-Filter.
- [SEKUNDÄR] `src/webservice/Centron.Controllers/Authorization/README.md` - dokumentierte 401/403-Semantik und Kombinierbarkeit.
- [SEKUNDÄR] `CentronRights.md` (restricting rights) - Datenfilter-Konzept.
Prüfidee: Parameterisierter Rechte-Matrix-Test: je Controller-Endpunkt mit/ohne Recht aufrufen; erwartete Codes 200/403.
Tracelinks: StRS-9, StRS-12, SwRS-13
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Must-have für Mehrmandanten-SaaS.
Status: belegt
---
ID: SyRS-5
Titel: Zwei-Faktor-Authentisierung (TOTP) für Benutzer
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Benutzer, Authentisator-App, Webservice
Vorbedingung: Dem Benutzer ist ein TwoFactorAuthKey hinterlegt.
Fakt: `TwoFactorAuthenticationBL.ValidateAuthenticationPin` prüft PIN gegen den je AppUser gespeicherten `TwoFactorAuthKey` über `Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin`; Fehler: „Ihrem Benutzer ist kein Zwei-Faktor Schlüssel … hinterlegt!“, „Die eingegebene PIN ist ungültig!“; `TwoFactorAuthController` in der API; `ConnectionManager` besitzt `TwoFactorAuthTestView`.
Aussage: Das System soll für Benutzer mit hinterlegtem TOTP-Schlüssel die Anmeldung um eine zeitbasierte Einmal-PIN erweitern und die PIN serverseitig gegen den Benutzerschlüssel validieren.
Ergebnis: Ohne gültige TOTP-PIN keine Anmeldung; Benutzer ohne Schlüssel bekommt klare Meldung.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs:43-54` (`ValidateAuthenticationPin`) - durchgesetzte Prüfung.
- [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/Unversioned/TwoFactorAuthController.cs` - API-Zugang.
Prüfidee: Abgelaufene TOTP-PIN (>30 s) wird abgelehnt; PIN-Validierung ohne hinterlegten Schlüssel liefert definierten Fehler.
Tracelinks: StRS-9, SwRS-15, SwRS-16
Konsolidierung: Kandidat: `PasswordManager`/`PasswordManagementArea`-BL und `TwoFactorAuthenticator`-BL nutzen dieselbe Named-Query-Familie (`NamedQueryEnums.PasswordManager.*`) → im Zielsystem eine Identitätskomponente.
Übernahmewürdigkeit: übernehmen - Sicherheitsstandard.
Status: belegt
---
ID: SyRS-6
Titel: Passwort-Hashing (SHA-1 + Salt) – Migrationsrisiko
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Authentifizierung
Vorbedingung: Benutzer legt Passwort an / ändert es.
Fakt: `Centron.BL/Core/CryptoUtils.cs`: `CreateSalt(size)` (Base64 `RandomNumberGenerator`), `CreatePasswordHash(pwd, salt)` = SHA-1 über `pwd + salt`, Hex-Ausgabe; kein langsamer Key-Derivation-Algorithmus (kein PBKDF2/BCrypt/Argon2 im Core).
Aussage: Das Zielsystem soll Passwörter mit einem modernen, rechenintensiven Hashverfahren (z. B. Argon2id/PBKDF2) speichern; die bestehende SHA-1+Salt-Darstellung dient nur als Kompatibilitätsformat für die Migration.
Ergebnis: Migrierte Passwörter werden bei erster Anmeldung transparent hochgehängt; Neuanlagen nutzen das moderne Verfahren.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Core/CryptoUtils.cs:26-33` (`SHA1.Create()` über `pwd + salt`) - Ist-Implementierung der durchgesetzten Hashbildung.
Prüfidee: Migrations-Unit-Test: alter SHA1-Hash + korrektes Passwort → Login ok und Hash auf neuen Algorithmus gesetzt.
Tracelinks: StRS-9, SyRS-5, SwRS-16
Konsolidierung: nein
Übernahmewürdigkeit: Workaround (SHA1-Verfahren historisch) - Verfahren ersetzen, Anforderung (Gespeicherte Passwörter) bleibt.
Status: belegt
---
ID: SyRS-7
Titel: Kreditlimit-Prüfung beim Speichern kundenbezogener Belege
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Beleg-Save-Logik, Sachbearbeiter
Vorbedingung: Kunde hat `CreditLimit > 0` und Limitberechnungsart (Netto/Brutto) ungleich deaktiviert.
Fakt: `ReceiptBL.CheckIfCustomerLimitIsReached` (Zeile 8636): summiert verbrauchtes Limit über alle belegarten (`TakesPlaceInLimitCalculation`), verrechnet Herkunftbelege, vergleicht mit `customer.CreditLimit`, setzt `ShowCustomerLimitExceededDialog` mit Differenztext „Das Limit von … wurde um … überschritten.“; speichert `CreditLimitAvailable`; Überspringbar via `SaveAlthoughCustomerLimitExceeded` (Vier-Augen-Bestätigung im UI).
Aussage: Das System soll beim Speichern jedes kundenbezogenen Belegs prüfen, ob das Kreditlimit des Kunden (netto oder brutto je Kundeneinstellung) durch alle offenen Belege ausgeschöpft wäre, und den Speichervorgang nur nach bewusster Bestätigung des Bearbeiters fortlassen.
Ergebnis: Limitüberschreitung ist sichtbar, bestätigungspflichtig und im Kundenstamm (`CreditLimitAvailable`) nachgeführt.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:8636-8692` - Prüfende Stelle inkl. Bedingung und Dialogsetzung.
Prüfidee: Kunde Limit 1000, offene Belege 900, neuer Beleg 200 → Dialog mit Differenz 100; ohne Bestätigung wird nicht gespeichert.
Tracelinks: StRS-2, StRS-6, SwRS-3, SwRS-17
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zentrales Zahlungsziel-Risikomanagement.
Status: belegt
---
ID: SyRS-8
Titel: Belegsperre ab Mahnstufe des Kunden/Lieferanten
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Beleg-Neuanlage-Logik, Buchhaltung
Vorbedingung: Für Kunde/Lieferant existiert Mahnstufe > 0; Belegart hat Sperrkonfiguration (`BlockNewReceiptsDunningLevel`).
Fakt: `ReceiptBL.CanUserCreateNewReceiptsAtCustomerOrSupplier` (Zeile 10194ff.): prüft Rechts-Berechtigung der Belegart und danach `GetCustomerOrSupplierDunningLevel<TReceipt>`; bei `dunningLevel >= blockOnLevel` Fehler „Aufgrund der Mahnstufe darf kein neuer Beleg vom Typ … angelegt werden.“; Mahnstufenfelder in `RechKopf` (`Mahnstufe`, `Mahnung1..3Datum`, `MahnStop`).
Aussage: Das System soll die Neuanlage von Belegen je Belegart sperren, sobald der Geschäftspartner eine konfigurierte Mahnstufe erreicht hat, und die Sperre vor jeder Anlage (nicht nur im UI) durchsetzen.
Ergebnis: Zahlungsverzügige Kunden können keine neuen Aufträge/Rechnungen auslösen; Verstoßversuch liefert definierte Fehlermeldung.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:10194-10218` (`CanUserCreateNewReceiptsAtCustomerOrSupplier`) - Prüfende Stelle mit Bedingung `dunningLevel >= blockOnLevel`.
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` `RechKopf.Mahnstufe`/`MahnStop` - persistierte Basis der Prüfung.
Prüfidee: Mahnstufe 2 setzen (Sperrschwelle 2); API-Anlage eines neuen Angebots schlägt mit der o. g. Meldung fehl; MahnStop ignoriert Sperre je nach Konfiguration.
Tracelinks: StRS-2, StRS-6, SwRS-5, SwRS-18
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Bonitätssteuerung.
Status: belegt
---
ID: SyRS-9
Titel: Elektronische Rechnungen: ZUGFeRD/XRechnung und ebInterface
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Rechnungsausgang, Empfängerbehörden, österreichische Kunden
Vorbedingung: Rechnung ist erzeugt; Kundeneinstellung zum Exportprofil existiert.
Fakt: `InvoiceZugferdBL.GetZugferFormat` wählt `ZugferdKind` (u. a. `ZUGFeRD_1_0`, `ZUGFeRD_XInvoice_3_0_1`) aus Kundeneinstellung `ActiveZugferdInterface`, Hinweis „for the local setting the newest version of XRechnung should be used“; `Centron.Gateway/ZUGFeRD21_Extended`; `EbInterfaceLogic` mit Namespace `http://www.ebinterface.at/schema/4p3/` inkl. Vorab-Validierung (`ValidateValues`); `ZugferdImportController` (Eingangsverarbeitung), `CustomZugferdPdfGenerator` (Hybrid-PDF).
Aussage: Das System soll ausgehende Rechnungen je Empfängerland im vorgeschriebenen Strukturierten Format erzeugen (DE: ZUGFeRD/XRechnung, AT: ebInterface 4.3) und eingehende E-Rechnungen importieren können; Formatversionen sind konfigurierbar.
Ergebnis: Revisionssichere E-Rechnungs-Ausgabe und -eingangsverarbeitung; Formatwahl pro Kunde/Empfänger.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs:85-100` - Formatentscheidende Stelle.
- [PRIMÄR] `src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs` (`GenerateFile` mit `ValidateValues`, Namespace 4p3) - erzwungenes Formatlayout.
- [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/Receipts/ZugferdImportController.cs` - Eingangs-Endpunkt.
Prüfidee: XRechnung-Validierung (Schematron) für Musterrechnung erfolgreich; ebInterface-Ausgabe validiert gegen XML-Schema 4.3; deaktivierte Kundeneinstellung erzeugt nur PDF.
Tracelinks: StRS-6, SwRS-21, SwRS-22
Konsolidierung: Kandidat: ZUGFeRD 1.0 Alt-Pfade (`InvoiceZugferdBL.Zugferd10.cs`) vs. XRechnung 3 - nur aktuelles Profil übernehmen.
Übernahmewürdigkeit: übernehmen (gesetzlich); ZUGFeRD 1.0 Alt-Parser = veraltet.
Status: belegt
---
ID: SyRS-10
Titel: Versanddienstleister-Anbindung (Shipcloud, GLS)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Logistik/Versand, Spediteur
Vorbedingung: Beleg ist versandbereit; Versandeinstellungen konfiguriert.
Fakt: `src/apis/Centron.Api.Shipcloud` (Klassen `UploadResult`, `Helpers`, `Entities`), `src/apis/Centron.Api.Gls` (Klassen/Entities), `ShipcloudPackageTemplateBL.cs` und `ShipcloudPackageTemplatesController.cs` (Vorlagenverwaltung), WPF-Modul `Logistic`.
Aussage: Das System soll Packstücke für ausgehende Belege über Versanddienstleister (Shipcloud, GLS) anmelden und Label/Sendungsstatus in den Beleg übernehmen.
Ergebnis: Sendungsnummer/Label hängen am Beleg; Statusänderungen sind nachvollziehbar.
Belege:
- [SEKUNDÄR] `src/apis/Centron.Api.Shipcloud/Classes/UploadResult.cs`, `src/apis/Centron.Api.Gls/Classes/UploadResult.cs` - Upload-Antwortverarbeitung zweier Dienstleister.
- [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/ShipcloudPackageTemplateBL.cs` - Paketvorlagen-Verwaltung.
Prüfidee: Musterbeleg → Label-PDF + Sendungsnummer im Beleg; Storno löscht Referenz.
Tracelinks: StRS-2, StRS-11
Konsolidierung: Kandidat: Shipcloud- und GLS-Adapter abstrahieren denselben Vorgang „Versandanmeldung“ → ein Carrier-Adapter-Konzept.
Übernahmewürdigkeit: übernehmen (Konzept); konkrete Anbieter = konfigurierbare Konnektoren.
Status: belegt
---
ID: SyRS-11
Titel: EDI-Anbindung mehrerer Großhandelslieferanten
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Einkaufssystem, Lieferanten-EDIs (Alltron, Also/AlsoCH, EGIS, Herweck, Komsa, Concerto, OpenTrans)
Vorbedingung: Partner-Konfiguration aktiv.
Fakt: `src/backend/Centron.Gateway/EDI_Alltron`, `EDI_Also`, `EDI_AlsoCH`, `EDI_EGIS`, `EDI_Herweck`, `EDI_Komsa` (je eigener Implementierungsordner), `Concerto/ConcertoOrder.xsd` (bestellungs-XSD), `OpenTrans`/`OpenTrans1_0` (Bestellformat), `Centron.APIs.EgisDataAccess` (RequestTemplates/Parser), `Centron.APIs.CopDataAccess` (SoapTemplates/Parser).
Aussage: Das System soll ausgehende Bestellungen und eingehende Auftrags-/Artikeldaten mit mehreren Lieferantenformaten konvertieren; neue Lieferanten sollen als weiterer Connector ohne Kernänderung ergänzbar sein.
Ergebnis: Lieferantenindividuelle Formate werden über einen Gateway-Layer (Centron.Gateway) gekapselt; Kernsystem bleibt formatfrei.
Belege:
- [PRIMÄR] `src/backend/Centron.Gateway/Concerto/ConcertoOrder.xsd` - verbindliches Nachrichtenschema einer Bestellung.
- [SEKUNDÄR] Verzeichnisstruktur `Centron.Gateway/EDI_*` - Connector je Partner real vorhanden.
Prüfidee: XSD-Validierung aller ausgehenden Bestellungen eines Partners gegen dessen Schema-Ordner.
Tracelinks: StRS-4, StRS-13, SwRS-23
Konsolidierung: Kandidat: alle `EDI_*`-Ordner + `CopDataAccess`/`EgisDataAccess` - gleiche Funktion „Lieferantenanbindung“ in ≥6 Implementationen; Ziel: ein Connector-Framework mit Partner-Konfiguration.
Übernahmewürdigkeit: übernehmen - EDI ist betriebskritisch.
Status: belegt
---
ID: SyRS-12
Titel: Produktdaten-Services (Icecat, ITscope)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Artikelstamm-Pflege
Vorbedingung: API-Zugang zu Datenquelle konfiguriert.
Fakt: `IcecatApi.cs`/`IIcecatApi.cs` mit Sprachenumgebung (`Languages.cs`), `ITscopeDataAccess` mit eigenem Parser-Layer, `CopDataAccess` SOAP-Templates.
Aussage: Das System soll Produktinformationen (Texte, Bilder, Merkmale) über definierte Services abrufen und mehrsprachig in den Artikelstamm übernehmen können.
Ergebnis: Artikelanreicherung erfolgt automatisiert; Quellen sind austauschbar.
Belege:
- [SEKUNDÄR] `src/apis/Centron.APIs.IcecatDataAccess/IIcecatApi.cs`, `Languages.cs` - API-Vertrag + Sprachsupport.
Prüfidee: Abruf eines bekannten Artikels; Merkmalsliste und Bild-URLs im Datensatz.
Tracelinks: StRS-5, StRS-13
Konsolidierung: Kandidat: wie StRS-13 (Import-Pipeline).
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-13
Titel: Onlinebanking-Anbindung (FinAPI, HBCI/FinTS)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Buchhaltung, Bank
Vorbedingung: Bankkonto konfiguriert (FinAPI-Zugang oder HBCI-Credentials).
Fakt: `Finances/OnlineBanking/OnlineBankingFinApiBL.cs` + `src/apis/Centron.APIs.FinAPI/FinApiClient.cs` (REST-FinAPI), `Centron.Gateway/OnlineBanking/OnlineBankingConnectionLibfintx.cs` (FinTS-Bibliothek), `Finances/IncomingPayments/IncomingPaymentBL.cs` (Zuordnung Zahlungseingänge), `Accounting/BankAccountBL.cs`.
Aussage: Das System soll Kontoumsätze und Überweisungen über Onlinebanking-Kanäle (FinAPI, alternativ FinTS) austauschen und Zahlungseingänge zur offenen-Posten-Verrechnung bereitstellen.
Ergebnis: Zahlungseingänge werden zur automatischen Rechnungs-Zuordnung angeboten (siehe `RechKopf.Bezahlt`); Kontoauszüge liegen im System vor.
Belege:
- [SEKUNDÄR] `src/backend/Centron.Gateway/OnlineBanking/OnlineBankingConnectionLibfintx.cs` - FinTS-Verbindung implementiert.
- [SEKUNDÄR] `src/apis/Centron.APIs.FinAPI/FinApiClient.cs` - FinAPI-REST-Client.
- [SEKUNDÄR] `src/backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentBL.cs` - Eingangsverbuchung.
Prüfidee: Testsandbox-Umsatz → Vorschlag zur Zuordnung an Rechnung (Match über Betrag/Verwendungszweck).
Tracelinks: StRS-6, SwRS-3
Konsolidierung: Kandidat: FinAPI- und FinTS-Pfade erfüllen denselben Zweck → ein Banking-Konnektor mit Kanal-Auswahl.
Übernahmewürdigkeit: übernehmen; FinTS-Legacy-Pfad = Kandidat für Sonderfall/veraltet.
Status: HYPOTHESE (die konkrete Umsatz→OP-Zuordnungsregel wurde nicht im Detail gelesen)
---
ID: SyRS-14
Titel: Zeiterfassung als Fakturierungsgrundlage
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Techniker, Support, Fakturierung
Vorbedingung: Ticket/Auftrag mit Zeiterfassungsrecht offen.
Fakt: `HelpdeskTimerBL`, `HelpdeskTimerArticleBookingBL` (Verrechnung auf Artikel), `HelpdeskTimerAddressSpecialArticlesBL` (Anfahrtsartikel), Rechte `EDIT_TIME`/`OWN_TIME_EDIT`/`MOVE_HELPDESK_TIMER`/`DELETE_HELPDESK_TIMER` (CentronRights.md: Verschieben/Löschen nur, wenn Ticket „not part of a receipt“); `Finances/TimerBilling`; Nexus-Zeiterfassungs-Verbesserungen im Changelog.
Aussage: Das System soll geleistete Zeiten inkl. Anfahrtspauschalen erfassen, gegen Mitarbeiter-/Kundenartikel bewerten und erst nach Freigabe unveränderbar in die Abrechnung überführen; Änderungen nach Abrechnung sind gesperrt.
Ergebnis: Abrechnungsreife Zeiten sind manipulationssicher; Abhol-/Stornofälle bleiben konsistent.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs:554-556` (`DeleteHelpdeskTimer` prüft `HasUserRight(..., UserRightsConst.Sales.Customer.Helpdesk.DELETE_HELPDESK_TIMER)` vor Löschung) - durchgesetzte Rechtsprüfung; `:119-142` belegt die Zuordnung der Zeit zu Auftrags-/Lieferschein-/Rechnungspositionen (`OrderAssetItemI3D`, `DeliveryListAssetItemI3D`, `InvoiceAssetItemI3D`).
- [KONTEXT] `CentronRights.md` Punkte 8/9 (`MOVE_HELPDESK_TIMER`, `DELETE_HELPDESK_TIMER`: „But only if the ticket is not part of a receipt“) - dokumentierte, im Rechtssystem verankerte Grenze.
- [SEKUNDÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerArticleBookingBL.cs` - Artikel-Verrechnung der Zeiten.
Prüfidee: Zeit auf abgerechnetem Ticket verschieben → abgelehnt; Zeit mit Anfahrtsartikel erzeugt korrekte Belegposition.
Tracelinks: StRS-3, StRS-7, SwRS-31
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - direkte Erlösrelevanz.
Status: belegt
---
ID: SyRS-15
Titel: Portal-Zugriff für Kunden über Web-Accounts
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Kunde, Nexus (Blazor), Webservice
Vorbedingung: Web-Account (Adressstamm) mit Berechtigung existiert.
Fakt: `AuthorizeLoginUserAttribute` vs. `AuthorizeLoginWebAccountAttribute` + zugehörige „Views“ (`AuthorizeLoginUserView`, `AuthorizeLoginWebAccountView`) im Nexus-Authorization-Ordner; `WebAccountController.cs` in der API; `WebReceipt*`-Methoden in `ReceiptBL` (Adress-/Bestellnummern-Änderung per Token durch Web-Kunden, `GetWebReceiptItemChangeRequests`); README-WebCart-Beschreibung.
Aussage: Das System soll externe Web-Accounts von internen Mitarbeitern daten- und funktionsseitig trennen; Web-Kunden dürfen nur an Objekten mit Token/Account-Bezug Änderungen vornehmen (z. B. Belegadresse, Bestellnummer, Artikelwunsch).
Ergebnis: Externe Eingaben sind auf den eigenen Datenkreis begrenzt und werden im Beleg-Workflow (Änderungsanfrage) geführt.
Belege:
- [PRIMÄR] `src/nexus/CentronNexus/Shared/Authorization/Attributes/AuthorizeLoginWebAccountAttribute.cs` - erzwungene Account-Art-Prüfung.
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:5894-6116` (`GetWebReceiptItemChangeRequests`, `ChangeWebReceiptAddress` per Token) - tokenbasierte Kundenänderung.
Prüfidee: Web-Account-Kunde ändert Belegadresse eines Fremd-Kunden (falscher Token) → Fehler; Änderungen erscheinen als Änderungsanfrage im Bearbeiter-Cockpit.
Tracelinks: StRS-8, SyRS-2, SwRS-20
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-16
Titel: Echtzeit-Benachrichtigung und Chat über SignalR
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Clients, Webservice-Hubs
Vorbedingung: Client authentifiziert; Hub erreichbar.
Fakt: `src/webservice/Centron.Host/RealTimeServices` enthält `NotificationsHub`, `ChatHub`, `AvailabilityStatusHub`, `TapiClientHub` mit `SecretKeyHandler`/`SecretKeyRequirement`; `Centron.BL/NexusNotifications`, `Notifications`, `Chats`.
Aussage: Das System soll Statuswechsel, Chats, Erreichbarkeit und Telefonie-Ereignisse in Echtzeit an alle aktiven Clients verteilen; Hub-Zugriff ist über Secret-Key abgesichert.
Ergebnis: Mehrbenutzer-Clients bleiben ohne manuelles Aktualisieren konsistent.
Belege:
- [PRIMÄR] `src/webservice/Centron.Host/RealTimeServices/SecretKeyHandler.cs` - durchgesetzte Hub-Absicherung.
- [SEKUNDÄR] Hub-Dateinamen (`NotificationsHub.cs` u. a.) - Echtzeit-Kanäle.
Prüfidee: Statuswechsel in Client A erscheint ohne Reload in Client B; unautorisierter Hub-Aufbau scheitert.
Tracelinks: StRS-10, StRS-11
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-17
Titel: Volltextsuche über zentrale Indizes
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Alle Fachanwender
Vorbedingung: Indizes sind aufgebaut.
Fakt: `Centron.BL/IndexSearch` mit `IndexBuilder.cs`, `GermanAnalyzer.cs`, `Indexes/TicketFulltextIndex.cs`; Exception `ObjectIndexingFailedException`.
Aussage: Das System soll objektübergreifende Volltextsuche (u. a. Tickets) mit deutscher Sprachanalyse bereitstellen und Indexfehler protokollieren statt die Anwendung abbrechen lassen.
Ergebnis: Schnelles Finden von Vorgängen über Freitext.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs` + `TicketFulltextIndex.cs` - implementierte Suche/Analyse.
Prüfidee: Suchbegriff im Tickettext findet Ticket; Wortform „Rechnungen“ findet „Rechnung“ (Stemming-Test).
Tracelinks: StRS-3, StRS-12, SwRS-29
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-18
Titel: Report-/Berichte-Engine (FastReport, DevExpress)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Reports, Druck-/Export-Kette
Vorbedingung: Reportvorlage vorhanden.
Fakt: `Centron.BL/ReportEngine` (u. a. `CustomPdfGenerators/CustomZugferdPdfGenerator.cs`, `Templates/HelpdeskHtmlTemplateManager.cs`), `Centron.DAO/Reporting`, `Centron.Interfaces/CentronReportEngine`; `Centron.BL.csproj` referenziert `FastReport.Net.Pro`, `FastReport.Core.Skia`, `DevExpress.Document.Processor` (Serverseitige PDF-/Reportverarbeitung inkl. Skia/Linux-Native-Assets).
Aussage: Das System soll Berichte serverseitig rendern (PDF/Druck/Excel) und plattformunabhängig (Windows und Linux-Container) ausführen.
Ergebnis: Belegdruck und Reports funktionieren im Windows-Client und im Docker-Betrieb.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Centron.BL.csproj` (PackageReferences FastReport.SkiaDrawing, SkiaSharp.NativeAssets.Linux, Kommentar zu FastReport-Bug) - real genutzte Renderkette inkl. Linux.
- [SEKUNDÄR] ReportEngine-Ordnerstruktur - Vorlagenverwaltung.
Prüfidee: Beleg-Report im Linux-Container erzeugen → PDF identisch zum Windows-Lauf.
Tracelinks: StRS-12, StRS-6
Konsolidierung: Kandidat: FastReport- und DevExpress-Renderpfade parallel → eine Render-Engine wählen.
Übernahmewürdigkeit: übernehmen (Konzept), Lizenz-/Bibliotheken-Doppelung = Konsolidierungsfall.
Status: belegt
---
ID: SyRS-19
Titel: E-Mail-Integration und automatisierte Ticketentstehung
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Postfächer, MailScanner, Outlook
Vorbedingung: MailScanner-Profil konfiguriert.
Fakt: `MailScannerBL` (`GetProfiles`, `SaveWorkflow`, `SaveTasks`, `DeleteMailScannerLogs`), `HelpdeskMailBL`, `Outlook`-BL + `CentronNexus.OutlookAddIn`, docker `c-entron-mailcatcher` (SMTP-Test), Compose-Service `smtp` (Port 1025/1080).
Aussage: Das System soll eingehende E-Mails nach Profilen/Workflows verarbeiten (Antwort/Ticket/Task), Mails an Tickets andocken und Outlook-Anbindung bereitstellen; ein SMTP-Relay ist Teil der Referenzinstallation.
Ergebnis: Supportanfragen aus E-Mails entstehen automatisiert und sind als Mail-Historie belegbar.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/MailScanner/MailScannerBL.cs` - Workflow/Tasks-Engine.
- [SEKUNDÄR] `docker/compose/compose.yaml` Service `smtp` - betrieblicher Mail-Pfad.
Prüfidee: Mail an Sammeladresse erzeugt Ticket gemäß Profil; Log-Eintrag; doppelte Mail erzeugt kein Duplikat (zu prüfen).
Tracelinks: StRS-3, StRS-10, SwRS-26
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-20
Titel: Dokumentensignatur über docuFORM und PDF-Signing
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Beleg-/Vertragsprocess, docuFORM-Dienst
Vorbedingung: Dokument liegt vor; Signaturflow aktiviert.
Fakt: `Centron.Api.docuFORM/DocuFormRestApiClient.cs` (+ `DocuFormRestApiConstants`, `IDocuFormApiClient`), `src/backend/Centron.BL/Security/PdfSigningBL.cs`, Nexus-Ordner `DocumentSigning`, `DocuFormApiSettingsController.cs`.
Aussage: Das System soll Dokumente in einen externen Signaturdienst (docuFORM) geben, Status rückführen und signierte PDFs im Dokumentenbestand des Fachobjekts bereitstellen.
Ergebnis: Unterschriftenprozess medienbruchfrei; Signaturstatus am Vorgang sichtbar.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Security/PdfSigningBL.cs` - serverseitige Signaturlogik.
- [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/DataExchange/DocuFormApiSettingsController.cs` - Konfigurations-API.
Prüfidee: Test-Signaturflow: Statusübergänge (erstellt→versendet→signiert), signiertes PDF im DocDir.
Tracelinks: StRS-15, StRS-11, SyRS-15
Konsolidierung: Kandidat: docuFORM-Signatur vs. PdfSigningBL (intern) - ein Signatur-Framework mit Providern.
Übernahmewürdigkeit: übernehmen (Konzept); docuFORM-Anbindung = austauschbarer Provider.
Status: HYPOTHESE (Statusmodell des Signaturflows nicht im Detail belegt)
---
ID: SyRS-21
Titel: Telefonie-Integration (TAPI, TelekomDive)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Service-Desk-Mitarbeiter, Telefonanlage
Vorbedingung: TAPI-Client läuft; TelekomDive-Zugang konfiguriert.
Fakt: `assemblies/tapi` (Bibliothek), `Centron.Controls/Telephony`, `Centron.BL/Tapi/PhoneCallBL.cs`, `TapiClientHub` (SignalR), `TelekomDiveController.cs` + `TelekomDive`-WPF-Modul; Changelog: „Telefonnummer … anklicken, um Telefonverbindung über externe Software aufzubauen“.
Aussage: Das System soll Klick-zu-Call aus Kunden-/Ticketdaten und Anruf-Events (Client-Hub) unterstützen, angebunden an Telefonie-Dienste (TAPI-basiert sowie TelekomDive).
Ergebnis: Anrufhistorie/Verbindungsherstellung sind arbeitsplatzübergreifend verfügbar.
Belege:
- [SEKUNDÄR] `src/webservice/Centron.Host/RealTimeServices/TapiClientHub.cs` - Telefonie-Ereignisverteilung.
- [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/DataExchange/TelekomDiveController.cs` + `src/centron/Centron.WPF.UI/Modules/TelekomDive` - Providerintegration.
Prüfidee: Klick auf Telefonnummer im Ticket löst CTI-Aktion aus; Event erscheint im Client.
Tracelinks: StRS-10, StRS-11, SyRS-16
Konsolidierung: Kandidat: TAPI (lokal) und TelekomDive (Cloud) - zwei Wege für „Click-to-Dial“.
Übernahmewürdigkeit: TAPI = veraltet (Windows-only Legacy); TelekomDive = Sonderfall (Anbieterbindung).
Status: HYPOTHESE (Konkrete Funktionsbreite beider Kanäle nicht im Detail belegt)
---
ID: SyRS-22
Titel: bidirektionale Riverbird-Synchronisation
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: c-entron Webservice, Riverbird Web-Service
Vorbedingung: Mandant über Riverbird bezogen.
Fakt: `RiverConnectionBL` (Klassendoku: ausgehende Rufe des c-entron Webservice nach Riverbird), `RiverDivoBL` (eingehende Rufe von Riverbird in c-entron), `RBContractArticleRefInfo` (Vertrag↔Artikel-Referenz), `deployment/riverbird`.
Aussage: Das System soll die Kopplung an die Riverbird-Plattform in beide Richtungen aufrechterhalten (Vertrags→Artikel-Beziehungen, Statusänderungen).
Ergebnis: Vertragsdaten bleiben über Systemgrenzen konsistent.
Belege:
- [KONTEXT] `src/backend/Centron.BL/RiverDivo/RiverDivoBL.cs` + `RiverConnectionBL.cs` (Klassendoku) - Implementierung beider Richtungen behauptet; einzelne prüfende Methoden nicht verifiziert.
Prüfidee: Simulierter Riverbird-Call auf `RiverDivoBL`-Methode; Referenztabelle wird nachgeführt.
Tracelinks: StRS-14, StRS-7
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - plattformspezifische Kopplung des Herstellers.
Status: HYPOTHESE (fachlicher Sync-Umfang nur aus Doku-Kommentaren erschlossen)
---
ID: SyRS-23
Titel: Datenhaltung mit Mandanten-, Filial- und Löschstatus
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Datenbank, alle Module
Vorbedingung: Mandant/Filiale im System gepflegt.
Fakt: `Filiale.MandantI3D`, `KundeToKonzern`-Tabelle, `Accounts/CustomerToBranchBL.cs`, `CustomerCostCenterBL.cs`; Rechte mit Filialbezug (`CentronRights.md`); `Status`-Spalten breit indexiert (viele `*_Status`-Indizes im Schema); Soft-Delete-Muster `Geloescht*` (z. B. `Filiale.GeloeschtVonI3D`, `Mahnlauf.GeloeschtDatum`).
Aussage: Das System soll Fachdaten dauerhaft mit Mandant/Filiale referenzieren, Löschungen als Kennzeichnung (Status/Deleted) statt physischem Löschen abbilden und damit Auswertbarkeit und Revision erhalten.
Ergebnis: Kein Datenverlust durch Löschen; Auswertungen je Filiale/Mandant möglich.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` `Filiale` (`MandantI3D`, `GeloeschtVonI3D`, `Status`), Indexmuster `*_Status` - erzwungene Struktur.
- [SEKUNDÄR] `src/backend/Centron.BL/Accounts/CustomerToBranchBL.cs` - Filialzuordnung gepflegt.
Prüfidee: Objekt „löschen“ → Datensatz bleibt mit Löschkennzeichen erhalten und verschwindet aus Fachlisten.
Tracelinks: StRS-1, SwRS-4, SwRS-6
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - revisionsfreundlich.
Status: belegt
---
ID: SyRS-24
Titel: Versionierung und Protokollierung von Belegen und Änderungen
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Revision, Sachbearbeiter
Vorbedingung: Beleg wird gespeichert.
Fakt: 30 `*Versions`-Tabellen im Schema (u. a. `AngKopfVersions`, `AufKopfVersions`, `RechKopfVersions`, `GutKopfVersions`); `ReceiptBL` schreibt Logeinträge (`ReceiptLogBL.CreateReceiptItemEntry(… "der Rabatt" …)`, `CreateWithStaffelPriceEntry`); `Centron.DAO/ChangeTracking`; Nexus-Ticket-Historie (Changelog).
Aussage: Das System soll jede Belegänderung als neue Version erhalten und wertändernde Eingriffe (Preise, Rabatte, Konditionen) protokollieren; die Änderungshistorie ist im Objekt einsehbar.
Ergebnis: Nachvollziehbarkeit wer/wann/was bei Preis- und Konditionsänderungen.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql`, 30 Tabellen `CREATE TABLE …Versions` - Versionshaltung strukturell erzwungen.
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:10543-10709` (Anlage von Log-Einträgen bei Staffelpreis-/Rabattänderung) - durchgesetztes Protokollieren.
Prüfidee: Rabatt auf Position ändern; Log zeigt alten/neuen Wert + Benutzer + Zeit; Versionsvergleich liefert Differenz.
Tracelinks: StRS-2, StRS-6, SwRS-2, SwRS-25
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Audit-Anforderung.
Status: belegt
---
ID: SyRS-25
Titel: Lizenzierung an Hardware-ID gebunden
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Vertrauenswürdigkeit/Sicherheit
Akteur: Hersteller c-entron, Betrieb
Vorbedingung: Installation registriert.
Fakt: Compose-Env `HARDWARE_ID: LinuxV1.<Base64>`; `c-entron.misc.ConnectionManager` mit `HardwareIdView/ViewModel` und `LicenseView/LicenseViewModel`; `LicenseController.cs` in der API; Nexus enthält `Management`-Bereich.
Aussage: Das System soll die Inbetriebnahme an eine Lizenzprüfung binden, die installationsindividuell (Hardware-ID) vergeben wird.
Ergebnis: Unlizenzierte Installationen nehmen den Betrieb nicht auf bzw. sind meldungspflichtig.
Belege:
- [SEKUNDÄR] `docker/compose/compose.yaml` (`HARDWARE_ID`-Variable), `ConnectionManager`-Masken - Ausweis des Lizenzmodells.
- [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/Administration/LicenseController.cs` - Lizenz-API.
Prüfidee: Start ohne/ungültige HARDWARE_ID → Lizenzfehler; gültige ID → Start.
Tracelinks: SyRS-3, StRS-16
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - Hersteller-Lizenzmodell; im SaaS-Modell durch Mandanten-Abrechnung ersetzbar.
Status: HYPOTHESE (Durchsetzungspunkt der Lizenzprüfung im Startpfad nicht lokalisiert)
---
ID: SyRS-26
Titel: Zwei- und mehrsprachige Benutzeroberfläche (DE/EN)
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Anpassungsfähigkeit
Akteur: Deutsch-/englischsprachige Nutzer
Vorbedingung: Kultur am Benutzer/Browser gesetzt.
Fakt: Nexus-`SharedResource.resx` + `SharedResource.en-US.resx`; WPF-`Localization`-Ordner; `Centron.Host/LocalizationHandler.cs`; Nexus `CultureController.cs`; Icecat-API mit Sprachenumgebung.
Aussage: Das System soll UI-Texte ressourcenbasiert lokalisiert ausliefern und die Kultur pro Benutzer/Sitzung auflösen.
Ergebnis: Gleiche Funktionen in DE und EN; neue Sprachen ohne Codeänderung.
Belege:
- [SEKUNDÄR] `src/nexus/CentronNexus/SharedResource.en-US.resx`, `SharedResource.resx`, `src/webservice/Centron.Host/Services/LocalizationHandler.cs` - Ressourcen + Laufzeitauflösung.
Prüfidee: Kultur auf en-US setzen → alle Labels englisch; fehlende Ressource führt zu definiertem Fallback.
Tracelinks: StRS-11
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-27
Titel: Datenbank-Performance durch Fremdenschlüssel-/Status-Indizes
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Performance-Effizienz
Akteur: Datenbank
Vorbedingung: Schema deployed.
Fakt: `SSMS_DB_SCHEMA.sql` enthält tausende `CREATE NONCLUSTERED INDEX`-Statements, darunter systematisch Indizes auf Fremdschlüssel (z. B. `AngKopf_KundenID`, `AufKopf_KundenID`) und Status-Spalten (`*_Status`).
Aussage: Das Datenmodell soll Join- und Filterpfade (Kunde, Status) durch nicht-gruppierte Sekundärindizes abdecken, damit listengestützte Fachmasken auch bei Millionendatenvolumen antworten.
Ergebnis: Typische Fachabfragen (Kundensicht, Statuslisten) laufen indexgestützt.
Belege:
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` (Indexblöcke ab Zeile ~55800, z. B. `CREATE NONCLUSTERED INDEX [AufKopf_KundenID] ON [dbo].[AufKopf]`) - real gesetzte Indizes.
Prüfidee: Abfrageplan für „Belege je Kunde/Status“ zeigt Index-Seek statt Table-Scan.
Tracelinks: StRS-2, SwRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen (Prinzip; konkretes Indexwerk wird neu abgeleitet).
Status: belegt
---
ID: SyRS-28
Titel: Zentrale Protokollierung und Laufzeitdiagnose
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Betrieb, Support
Vorbedingung: Anwendung läuft.
Fakt: `Centron.Common/Logging` (`InMemoryLogging.cs`, `InMemoryTarget.cs`, `LogEntry.cs`); Log-Nutzung via `LogManager.GetCurrentClassLogger()` (log4net-artig); Changelog: „In den Logs unter Systeminfo wird nun auch der CallStack angezeigt“; Nexus-Systeminfo-Log-Kategorien.
Aussage: Das System soll Laufzeit- und Fehlerereignisse strukturiert protokollieren (inkl. Stack) und dem Support im Client/Web als Logbereiche bereitstellen.
Ergebnis: Fehlerfälle sind ohne Debugging rekonstruierbar.
Belege:
- [PRIMÄR] `src/backend/Centron.Common/Logging/InMemoryTarget.cs` - implementierter Appender.
- [KONTEXT] `src/nexus/CentronNexus/changelog.txt` (CallStack in Logs) - gelebte Diagnose.
Prüfidee: Provokierter Fehler → Logeintrag mit Category, Level, Stack; in Systeminfo einsehbar.
Tracelinks: StRS-16, SwRS-26
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-29
Titel: CI/CD und Sicherheitsprüfung als Build-Pipelines
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: Entwicklung, Betrieb
Vorbedingung: Repository-Änderung.
Fakt: `azure/build-pipeline.yml`, `tests-pipeline.yml`, `regression-tests-pipeline.yml`, `playwright-pipeline.yml`, `security-pipeline.yaml`, `deploy-on-testenv.yaml`, `analyze-pipeline.yml`; `.github`-Ordner; `docker/c-entron-regression-tests-db`.
Aussage: Das System soll Build, Unit-/Integrations-/Regressionstests, UI-End-to-End-Tests und Sicherheitsanalysen als automatisierte Pipelines ausführen und auf Testumgebungen deployen.
Ergebnis: Qualitätssicherung ist in den Auslieferungspfad integriert.
Belege:
- [SEKUNDÄR] Dateibestand `azure/*.yml` (Pipelines für build/test/regression/playwright/security/deploy) - definierte QA-Kette.
- [SEKUNDÄR] `tests/Centron.Tests.EndToEnd`, `tests/PlaywrightTests` - Testprojekte.
Prüfidee: Branch-Push löst Build+Tests+Security-Scan aus; Pipeline-Feed zeigt Ergebnisse.
Tracelinks: StRS-16, SwRS-34
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-30
Titel: Mehrsprachige Belegtexte, Textbausteine und Vorlagen
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Sachbearbeiter, Fakturierung
Vorbedingung: Textmodule/Vorlagen gepflegt.
Fakt: `Centron.BL/TextModuleArea`, `Centron.DAO/TextModuleArea`; `ReceiptTemplateBL.cs`; `HelpdeskCreationTemplateBL`, `HelpdeskPatternBL`, `TicketPatternsController.cs`; `ReplaceTextVariables`/`ReplaceCommonReceiptVariableValues` in `ReceiptBL.cs:6602-6649`.
Aussage: Das System soll Beleg- und Tickettexte über Variablen-Textbausteine erzeugen (Belegnummern, Kundendaten, Mitarbeiterdaten eingesetzt) und Vorlagen je Beleg-/Ticketart pflegbar halten.
Ergebnis: Einheitliche, konfigurierbare Ausgangstexte ohne Hartcodierung.
Belege:
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:6602-6649` (Ersetzungsmethoden) - durchgeführte Textersetzung.
Prüfidee: Vorlage mit `{Belegnummer}`-Variable → erzeugtes PDF enthält reale Nummer; ohne Vorlage greift Standard.
Tracelinks: StRS-2, StRS-3
Konsolidierung: Kandidat: Belegvorlagen (`ReceiptTemplateBL`) und Ticketvorlagen (`HelpdeskPatternBL`, `TicketPatternsController`) - gemeinsames Template-Subsystem im Ziel.
Übernahmewürdigkeit: übernehmen
Status: belegt
---
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/Traceability.md
+66
View File
@@ -0,0 +1,66 @@
# Traceability
Konsolidierte Traceability-Tabelle (Forward/Backward zwischen StRS ↔ SyRS ↔ SwRS). Zeilen je SyRS-Anforderung; SwRS-Spalte listet die darunter rangierenden Komponenten-/Datenanforderungen.
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (Kernbeleg) |
|---|---|---|---|
| StRS-1 | SyRS-23 | SwRS-4, SwRS-6, SwRS-32 | `SSMS_DB_SCHEMA.sql` Tabelle `Filiale` (`MandantI3D`, `Geloescht*`), Indexmuster `*_Status` |
| StRS-1 | SyRS-1 | SwRS-7, SwRS-8 | `docker/compose/compose.yaml`; `BLSession.GetBL`-Muster |
| StRS-2 | SyRS-7 | SwRS-3, SwRS-17 | `ReceiptBL.cs:8636` (`CheckIfCustomerLimitIsReached`) |
| StRS-2 | SyRS-8 | SwRS-5, SwRS-18 | `ReceiptBL.cs:10194` (Mahnstufengate), `RechKopf.Mahnstufe` |
| StRS-2 | SyRS-24 | SwRS-2, SwRS-25 | 30 Tabellen `*Versions`; `ReceiptLogBL`-Aufrufe |
| StRS-2 | SyRS-30 | SwRS-2 | `ReceiptBL.cs:6602ff.` (Textvariablen), `ReceiptTemplateBL` |
| StRS-2 | – (Fachkette) | SwRS-19 | `ReceiptProgressionBL.cs` |
| StRS-2 | SyRS-10 | – | `ShipcloudPackageTemplateBL.cs`, `Centron.Api.Gls/Shipcloud` |
| StRS-3 | SyRS-14 | SwRS-10 | `CentronRights.md` 7–9; `HelpdeskTimerArticleBookingBL.cs` |
| StRS-3 | SyRS-19 | SwRS-10 | `HelpdeskMailBL.cs`, `MailScannerBL.cs` |
| StRS-4 | SyRS-11 | SwRS-23 | `Centron.Gateway/EDI_*`, `Concerto/ConcertoOrder.xsd` |
| StRS-5 | SyRS-12 | SwRS-11, SwRS-12 | Tabellen `Artikel*`; `Warehousing/ArticleVolumePricesBL.cs` |
| StRS-6 | SyRS-9 | SwRS-3, SwRS-21, SwRS-22 | `InvoiceZugferdBL.cs:85-100`; `EbInterfaceLogic.cs` |
| StRS-6 | SyRS-13 | SwRS-3 | `OnlineBankingFinApiBL.cs`, `OnlineBankingConnectionLibfintx.cs` |
| StRS-6 | SyRS-8 | SwRS-5 | `Mahnlauf.cs` |
| StRS-7 | SyRS-14 | SwRS-31 | `Modules/Finances/TimerBilling`, `ContractEvaluation2` |
| StRS-7 | SyRS-22 | SwRS-31 | `RiverDivo`-Klassendoku |
| StRS-8 | SyRS-15 | SwRS-20 | `AuthorizeLoginWebAccountAttribute.cs`; `ReceiptBL.cs:5894-6116` |
| StRS-9 | SyRS-2 | SwRS-14 | `TicketAuthenticationHandler.cs`, `AuthenticationTicketBL.cs:25-47` |
| StRS-9 | SyRS-3 | SwRS-14 | `JwtAuthController.cs` |
| StRS-9 | SyRS-4 | SwRS-13 | `AuthorizeUserRightAttribute.cs`; `UserRightsConst.cs` |
| StRS-9 | SyRS-5 | SwRS-15, SwRS-16 | `TwoFactorAuthenticationBL.cs:43-54` |
| StRS-9 | SyRS-6 | SwRS-16 | `CryptoUtils.cs:26-33` |
| StRS-10 | SyRS-16 | SwRS-28 | `RealTimeServices/SecretKeyHandler.cs` |
| StRS-10 | SyRS-19 | – | `MailScannerBL.cs` |
| StRS-10 | – (UI) | SwRS-30 | `src/shared/Centron.Controls/*` |
| StRS-11 | SyRS-1 | – | Compose-Topologie |
| StRS-11 | SyRS-20 | – | `DocumentSigning` (Nexus), `Centron.Api.docuFORM` |
| StRS-11 | SyRS-21 | – | `TapiClientHub.cs`, `TelekomDiveController.cs` |
| StRS-12 | SyRS-17 | SwRS-29 | `IndexSearch/GermanAnalyzer.cs` |
| StRS-12 | SyRS-18 | – | `Centron.BL.csproj` (FastReport/Skia) |
| StRS-13 | SyRS-12 | – | `Centron.APIs.IcecatDataAccess/IIcecatApi.cs`, `ITscopeDataAccess` |
| StRS-14 | SyRS-22 | – | `RiverConnectionBL.cs`, `RiverDivoBL.cs` |
| StRS-15 | SyRS-20 | SwRS-33 | `PdfSigningBL.cs`; `ConnectionManager` |
| StRS-16 | SyRS-25 | SwRS-33 | `HARDWARE_ID` (compose), `LicenseController.cs` |
| StRS-16 | SyRS-27 | SwRS-1 | `SSMS_DB_SCHEMA.sql` Indexblöcke |
| StRS-16 | SyRS-28 | SwRS-26 | `Common/Logging/InMemoryTarget.cs` |
| StRS-16 | SyRS-29 | SwRS-34 | `azure/*.yml`; `version.json` |
| StRS-1,5,6,9 | SyRS-23 | SwRS-1, SwRS-2 | Schema-Gesamtbefund (Tabellen/Constraint-Armut) |
## Rückwärtskette (StRS → Mengen)
| StRS | zugehörige SyRS | zugehörige SwRS |
|---|---|---|
| StRS-1 | SyRS-1, SyRS-23 | SwRS-1, SwRS-4, SwRS-6, SwRS-7, SwRS-8, SwRS-32 |
| StRS-2 | SyRS-7, SyRS-8, SyRS-10, SyRS-24, SyRS-30 | SwRS-2, SwRS-3, SwRS-17, SwRS-18, SwRS-19, SwRS-25 |
| StRS-3 | SyRS-14, SyRS-19 | SwRS-10 |
| StRS-4 | SyRS-11, SyRS-12 | SwRS-11, SwRS-23 |
| StRS-5 | SyRS-12 | SwRS-11, SwRS-12 |
| StRS-6 | SyRS-8, SyRS-9, SyRS-13 | SwRS-3, SwRS-5, SwRS-17, SwRS-18, SwRS-21, SwRS-22 |
| StRS-7 | SyRS-14, SyRS-22 | SwRS-31 |
| StRS-8 | SyRS-15 | SwRS-20 |
| StRS-9 | SyRS-2, SyRS-3, SyRS-4, SyRS-5, SyRS-6 | SwRS-13, SwRS-14, SwRS-15, SwRS-16 |
| StRS-10 | SyRS-16, SyRS-19 | SwRS-26, SwRS-28, SwRS-30 |
| StRS-11 | SyRS-1, SyRS-15, SyRS-16, SyRS-20, SyRS-21 | SwRS-20, SwRS-33 |
| StRS-12 | SyRS-17, SyRS-18 | SwRS-29 |
| StRS-13 | SyRS-12 | – |
| StRS-14 | SyRS-22 | – |
| StRS-15 | SyRS-20 | SwRS-30, SwRS-33 |
| StRS-16 | SyRS-25, SyRS-27, SyRS-28, SyRS-29 | SwRS-1, SwRS-26, SwRS-34 |
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/OpenCode.log
View File
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/OpenCodeEvents.jsonl
+414
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Protokoll.md
+126
View File
@@ -0,0 +1,126 @@
# Messprotokoll – Iteration 16/qwen/qwen3.8-flash-next/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-02T12:51:54.8940173+02:00
- **Endzeit:** 2026-09-02T13:11:01.6994339+02:00
- **Dauer gesamt:** 00:19:03 (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):** `qwen/qwen3.8-flash-next`
- **Modell (tatsaechlich):** `qwen/qwen3.8-flash-next`
- **Kontrolle Modell:** bestanden
- **Effort:** `high` angefordert, **wirksam** (`effort_applied: true`)
- **Ablage:** `Iteration 16/qwen/qwen3.8-flash-next/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 | 110.962 |
| Output-Tokens | 68.116 |
| Reasoning-Tokens | 23.770 |
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
| Agent-Turns | 93 |
**Tokens gesamt: 6.432.032.** 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 | 19,8 % |
| SyRS | 30 | 37,0 % |
| SwRS | 35 | 43,2 % |
| **Gesamt** | **81** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 19 | 23,5 % |
| Schnittstelle | 19 | 23,5 % |
| Daten | 18 | 22,2 % |
| Sicherheit | 15 | 18,5 % |
| nicht-funktional | 10 | 12,3 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 137 |
| davon `PRIMÄR` | 72 (52,6 %) |
| davon `SEKUNDÄR` | 54 (39,4 %) |
| davon `KONTEXT` | 11 (8,0 %) |
| Belege je Anforderung (Median) | 2 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 64 (79,0 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 75 | 92,6 % |
| workaround | 2 | 2,5 % |
| sonderfall | 4 | 4,9 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 67 | 82,7 % |
| als `HYPOTHESE` gekennzeichnet | 14 | 17,3 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 31 | 38,3 % |
| mit ISO-25010-Qualitätsmerkmal | 11 | 13,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]` | **verletzt** – 3 von 27 ungedeckt: StRS-11, SyRS-29, SwRS-30 |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 81 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 81 von 81 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
- **Session-ID:** `ses_f9e40b88cffesSzknb1eFPiSFP`
- **Werkzeugaufrufe:** 135 – {"bash": 80, "read": 11, "write": 8, "edit": 36}
- **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/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/RawResult.json
+1276
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Stderr.log
+5
View File
@@ -0,0 +1,5 @@
[2026-09-02T10:51:56.684623+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\Ergebnisse)
[2026-09-02T10:51:56.851524+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=solo; Effort=high (uebergeben=True); Stall-Timeout=0s
[2026-09-02T11:11:00.336010+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
[2026-09-02T11:11:01.630042+00:00] OpenCode export: Exporting session: ses_f9e40b88cffesSzknb1eFPiSFP
[2026-09-02T11:11:01.680205+00:00] Ende: Exitcode=0; Status=success; Turns=93; Tokens=6432032; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\RawResult.json
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/after.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/anforderungen.json
+1597
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_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 | 16 | 19,8 % |
| SyRS | 30 | 37,0 % |
| SwRS | 35 | 43,2 % |
| **Gesamt** | **81** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 19 | 23,5 % |
| Schnittstelle | 19 | 23,5 % |
| Daten | 18 | 22,2 % |
| Sicherheit | 15 | 18,5 % |
| nicht-funktional | 10 | 12,3 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 137 |
| davon `PRIMÄR` | 72 (52,6 %) |
| davon `SEKUNDÄR` | 54 (39,4 %) |
| davon `KONTEXT` | 11 (8,0 %) |
| Belege je Anforderung (Median) | 2 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 64 (79,0 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 75 | 92,6 % |
| workaround | 2 | 2,5 % |
| sonderfall | 4 | 4,9 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 67 | 82,7 % |
| als `HYPOTHESE` gekennzeichnet | 14 | 17,3 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 31 | 38,3 % |
| mit ISO-25010-Qualitätsmerkmal | 11 | 13,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]` | **verletzt** – 3 von 27 ungedeckt: StRS-11, SyRS-29, SwRS-30 |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 81 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 81 von 81 mit Tracelinks (100,0 %) |
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/before.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_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\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T13:11:01.6994339+02:00
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_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/qwen/qwen3.8-flash-next",
"permission": {
"*": "deny",
"read": "allow",
"glob": "allow",
"grep": "allow",
"list": "allow",
"edit": {
"*": "deny",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse/**": "allow"
},
"external_directory": {
"*": "deny",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_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/qwen/qwen3.8-flash-next",
"mode": "primary"
},
"general": {
"model": "tensorx/qwen/qwen3.8-flash-next",
"mode": "subagent"
},
"explore": {
"model": "tensorx/qwen/qwen3.8-flash-next",
"mode": "subagent"
}
},
"default_agent": "build"
}
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/opencode-session.json
+11537
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T12:51:54.8940173+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/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