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/AblaufProtokoll.md
+50
View File
@@ -1403,6 +1403,56 @@ adapterbedingte Fehlmessungen gekennzeichnet.
---
### TensorX-Matrix mit den beiden guenstigsten Modellen (02.09.2026)
Erste vollstaendig besetzte Matrix der Reihe: zwei Modelle x drei Agentenmodi, alle sechs Zellen
mit dem kompletten Artefaktsatz von sieben Dateien. Bedingung: Skill 13.1.0, Adapter 2.5.2,
Denylist, Spiegel-Arbeitsverzeichnis, Effort `high`, Standard-Ausgabeblock.
Vor dem Start wurde der TensorX-Pfad mit einem Smoke-Test geprueft - seit dem letzten Lauf hatten
sich Denylist, Arbeitsverzeichnis und Freigabemuster geaendert, ohne dass er seither einmal lief.
Der Test bestaetigte Anmeldung, Modellkontrolle, wirksame Effort-Variante (`effort_applied: true`,
anders als lokal) und den Spiegel auch im Remotebetrieb.
| Modell | Modus | Min | Turns | Tools | Sub | Anforderungen | Primaerbeleg | ohne Beleg | Hypothesen | Tokens |
|---|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| `glm-5.3-flash` | solo | 22,7 | 71 | 111 | 0 | 126 | 97 % | 0 % | 3 % | 6.336.907 |
| `glm-5.3-flash` | builtin | 45,8 | 32 | 76 | 7 | 139 | 95 % | 0 % | 3 % | 4.316.088 |
| `glm-5.3-flash` | custom | 129,1 | 45 | 81 | 30 | **216** | 91 % | 0 % | 1 % | 11.467.996 |
| `qwen3.8-flash-next` | solo | 19,1 | 93 | 135 | 0 | 81 | 79 % | 0 % | 17 % | 6.432.032 |
| `qwen3.8-flash-next` | builtin | 52,5 | 71 | 116 | 13 | **199** | 98 % | 0 % | 11 % | 7.830.882 |
| `qwen3.8-flash-next` | custom | 112,5 | 85 | 99 | 24 | 157 | **17 %** | **61 %** | **40 %** | 10.715.498 |
**918 Anforderungen, 47,1 Mio. Tokens, 6,4 Stunden.** Hochgerechnet aus der Preisliste vom
02.09.2026 ($0,20 Input / $0,50 Output je 1 Mio.) rund **$3,25** - TensorX liefert keine
Kostenangabe, `cost` bleibt `0`.
**Die Anzahl allein haette in die Irre gefuehrt.** Qwens custom-Lauf steht mit 157 Anforderungen
im Mittelfeld, ist aber qualitativ zusammengebrochen: **61 % ohne jeden Beleg**, nur 17 % mit
Primaerbeleg, 40 % als Hypothese gekennzeichnet. Alle uebrigen fuenf Laeufe kommen auf 0 % ohne
Beleg und 79 bis 98 % Primaerbelege. Dieselbe Zelle lieferte zugleich weniger als `builtin`
(157 gegen 199) bei 37 % mehr Tokens. Der Modus `custom` war fuer dieses Modell also teurer,
ertragsaermer **und** schlechter belegt - ein Befund, der ohne die Belegpruefung unsichtbar
geblieben waere und Befund 6.1 (Anforderungsanzahl ist kein Qualitaetsmass) erneut bestaetigt.
**Der Moduseffekt ist modellabhaengig.** Bei GLM steigt der Ertrag monoton (126 -> 139 -> 216)
bei durchgaengig hoher Belegqualitaet. Bei Qwen ist `builtin` das Optimum, `custom` faellt ab.
Die Annahme, rollenspezialisierte Agenten seien generell ueberlegen, traegt damit nicht; sie
scheint an das Modell gebunden zu sein. Mit einem Lauf je Zelle ist das ein Hinweis, keine
belastbare Aussage - die Streuung ist in dieser Reihe durchweg die dominierende Groesse.
**Ebenenverteilung.** Alle Laeufe legen den Schwerpunkt auf SwRS; am ausgewogensten ist Qwens
custom-Lauf (41/60/56), am schiefsten Qwens builtin-Lauf (16/49/134). Die StRS-Ebene bleibt
durchgaengig duenn - dasselbe Muster wie in den Claude-Laeufen.
**Ein Lauf mit Vorbehalt.** Qwens custom-Lauf meldet `exit_code: 1` bei `finish_reason: stop` und
ohne Timeout: OpenCode beendete sich mit Fehlercode, nachdem alle 24 Subagenten zurueckgekehrt
waren und sieben Dateien geschrieben hatte. Nach Pflichtpruefung ist er formal eine Fehlmessung,
inhaltlich vollstaendig. Er wird als *gueltig mit Vorbehalt* gefuehrt; die Ursache des Exitcodes
ist offen.
---
## 6. Befunde
### 6.1 Die Anforderungsanzahl ist kein Qualitätsmaß
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
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Adapter.log
+5
View File
@@ -0,0 +1,5 @@
[2026-09-02T12:03:40.596105+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\high\02_Lauf_2026-09-02_140338_v13.0.0-b5bb\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\high\02_Lauf_2026-09-02_140338_v13.0.0-b5bb\Ergebnisse)
[2026-09-02T12:03:40.785307+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=custom; Effort=high (uebergeben=True); Stall-Timeout=0s
[2026-09-02T13:56:13.742598+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
[2026-09-02T13:56:15.396492+00:00] OpenCode export: Exporting session: ses_f9dff0fd3ffei0THHf9fgmC3fO
[2026-09-02T13:56:15.432775+00:00] Ende: Exitcode=1; Status=error; Turns=85; Tokens=10715498; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\high\02_Lauf_2026-09-02_140338_v13.0.0-b5bb\RawResult.json
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/Analysebericht.md
+285
View File
@@ -0,0 +1,285 @@
# Analysebericht
## 1. Modulinventar (Schritt 0)
Das Modulinventar wurde vor der ersten Anforderung erstellt und wurde nachträglich nicht gekürzt. Es umfasst 70 fachliche Module bzw. Komponenten.
| Modul-ID | Fachliches Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe (ein Satz) |
|---|---|---|---|
| M001 | Administration (Stammdaten, Rechte, Lizenzen, Mandant) | src\centron\Centron.WPF.UI\Modules\Administration | Benutzerverwaltung, Rechte/Lizenzen, Mandant, Filialen, Mailvorlagen, Textbausteine und fachliche Einstellungen der Suite. |
| M002 | Künstliche Intelligenz / KI-Chat | src\centron\Centron.WPF.UI\Modules\ArtificialIntelligence | KI-Chat und Prompt-Verwaltung. |
| M003 | Kalender & Termine | src\centron\Centron.WPF.UI\Modules\Calendar | Kalender-Synchronisation, Terminarten, Urlaubs- und Vertretungsanzeige. |
| M004 | Dashboard / Modulübersicht | src\centron\Centron.WPF.UI\Modules\Dashboard | Startseite mit Modul-Slider. |
| M005 | Datenaustausch (Buchhaltung, EDI, Importe) | src\centron\Centron.WPF.UI\Modules\DataExchange | DATEV-/Buchhaltungs-Export, EDI-Belege, Zahlungsverkehr, DocSync und Datenimport. |
| M006 | Externe Werkzeuge | src\centron\Centron.WPF.UI\Modules\ExternalTool | Einbindung und Konfiguration externer Tools. |
| M007 | Zahlungseingang, Mahnwesen & Offene Posten | src\centron\Centron.WPF.UI\Modules\Finances\{Payments,Dunning,Opos,AccountManagement} | Zahlungen, Mahnläufe, Opos-Verarbeitung und Kundenkonten. |
| M008 | Kampagnen | src\centron\Centron.WPF.UI\Modules\Finances\Campaigns | Marketing-Kampagnen mit Phasen und Teilnehmern. |
| M009 | Finanzen – Common & Masterdatenlisten | src\centron\Centron.WPF.UI\Modules\Finances\{Common,MasterDataLists} | Finanz-Masterdatenlisten und Common-Logik des Finanzmoduls. |
| M010 | Verträge, Laufzeit- & Zählerabrechnung | src\centron\Centron.WPF.UI\Modules\Finances\{Contracts,ContractEvaluation2,ContractEvaluationOld,DeviceClickCounter,FlatrateBilling,TimerBilling,AutomatedBilling} | Vertragsanlage, Click-/Kontingentabrechnung, Zeit-/Flatrate-/Vollautomatik-Billing und Vertragsevaluation. |
| M011 | CRM, Accounts & Interessenten | src\centron\Centron.WPF.UI\Modules\Finances\Crm | Accounts, Adressen, Aktivitäten, CRM-Projekte und Konto-Verträge. |
| M012 | Product Lifecycle Management (PLM) | src\centron\Centron.WPF.UI\Modules\{PLM,Finances\ProductLifecycleManagement} | Produktlebenslauf, Produktfamilien-Gruppen und PLM-Log. |
| M013 | Projekte & Projektmanagement | src\centron\Centron.WPF.UI\Modules\{Finances\Projects,ProjectManagement} | Projekte, Phasen, Aufgaben und Mitarbeiterauslastung im Projekt. |
| M014 | Belegwesen Verkauf/Vertrieb (Angebot bis Rechnung) | src\centron\Centron.WPF.UI\Modules\Finances\Receipts | Angebot, Anfrage, Auftrag, Lieferschein, Rechnung, Gutschrift und Abholung inklusive Belegeinstellungen. |
| M015 | Globale Funktionen (Custom Properties, MSP-Lizenzen) | src\centron\Centron.WPF.UI\Modules\Global | Objektübergreifende benutzerdefinierte Eigenschaften und MSP-Lizenzvergleich. |
| M016 | GUI-Profile | src\centron\Centron.WPF.UI\Modules\Gui | Verwaltung von UI-Profilen. |
| M017 | Helpdesk / Tickets | src\centron\Centron.WPF.UI\Modules\Helpdesk | Ticketanlage, Ticketlisten, Status/Prioritäten, Checklisten, TaskManagement, Eskalationen und Ticketszenarien. |
| M018 | Logistik & Versand | src\centron\Centron.WPF.UI\Modules\Logistic | Logistik- und Versandart-Einstellungen. |
| M019 | Massenupdates | src\centron\Centron.WPF.UI\Modules\Massenupdates | Vorlagen- und Massenänderungswerkzeug für Stammdaten. |
| M020 | MyCentron (Arbeitsplatz, MyDay, Chats, Benachrichtigungen) | src\centron\Centron.WPF.UI\Modules\MyCentron | Persönliche Startseite, MyDay-Workitems, Chats, Benachrichtigungen, QuickNotes und News. |
| M021 | OnlineBanking | src\centron\Centron.WPF.UI\Modules\OnlineBanking | Bankanbindungen (FinTS/FinAPI), Umsätze und Zahlungsabgleich. |
| M022 | PasswordManager | src\centron\Centron.WPF.UI\Modules\PasswordManager | Passwort- und Zugangsdatenverwaltung mit Richtlinien. |
| M023 | Zahler & Kostenstellen | src\centron\Centron.WPF.UI\Modules\PayersAndCostCenter | Zahler- und Kostenstellenverwaltung. |
| M024 | Produktion | src\centron\Centron.WPF.UI\Modules\Production | Produktionsaufträge, Maschinen und Fertigungsplanung. |
| M025 | Projektpreis-Import | src\centron\Centron.WPF.UI\Modules\ProjectPriceImport | Import von Projektpreisen. |
| M026 | Einkauf & Warenwirtschaft Beschaffung | src\centron\Centron.WPF.UI\Modules\Purchasing | Bestellvorschlagsliste, Lieferantenbestellung/-belege und Reisekosten. |
| M027 | Qualitätsmanagement | src\centron\Centron.WPF.UI\Modules\QM | QM-Einstellungen, Anlagenfreigaben sowie Prüf- und Wartungsstammdaten. |
| M028 | Reports | src\centron\Centron.WPF.UI\Modules\Reports | Reportverwaltung und ReportEngine-Anbindung. |
| M029 | RMA (Retourenmanagement) | src\centron\Centron.WPF.UI\Modules\Rma | RMA-Anlage sowie Artikelrücksendung und -sendung. |
| M030 | Mailings & Produktmatrix | src\centron\Centron.WPF.UI\Modules\Sales | Mailings/Vorlagen und Kunden-Produktmatrix. |
| M031 | Statistiken | src\centron\Centron.WPF.UI\Modules\Statistics | Betriebswirtschaftliche Auswertungen sowie MSP-, Bestands- und Helpdeskstatistiken. |
| M032 | Umfragen / Surveys | src\centron\Centron.WPF.UI\Modules\Survey | Umfrage-Editor und -Analyse. |
| M033 | TelekomDive-Schnittstelle | src\centron\Centron.WPF.UI\Modules\TelekomDive | Telekom-Produkt- und Distributor-Exportdaten. |
| M034 | Lager & Artikelwirtschaft | src\centron\Centron.WPF.UI\Modules\Warehousing | Artikelstamm, Preise, Lager/Bestand, Inventur, Barcode und Wareneingang. |
| M035 | Nexus-Portal (Kundenportal, Serviceboard, Webshop) | src\nexus\CentronNexus | Web-Kundenportal mit ServiceBoard, WebCart/Webshop, WebOffer, Dokumenten-Signierung und Verwaltung. |
| M036 | IT-Planer / Monitoring / AssetManagement (RiverDive) | src\backend\Centron.BL\{ItPlanner,RiverDivo} (weitere Anteile in M053/M063) | IT-Dokumentation, Geräte-Monitoring und Patch-/Software-Deployment beim Kunden. |
| M037 | Telefonie / TAPI & Callcenter | src\shared\Centron.Controls\Telephony (Anteile in M053/M063) | Telefoniesteuerung, Anruferkennung, Call-Tracking und TAPI-Server. |
| M038 | Mail-Scanner / Posteingangsverarbeitung | src\backend\Centron.BL\MailScanner (Anteile in M063/M069) | Automatische Einordnung eingehender Mails zu Objekten und Tickets. |
| M039 | Social Media | src\backend\Centron.Interfaces\SocialMedia (Anteile in M063/M069) | Pflege und Auswertung von Social-Media-Aktionen und Streams. |
| M040 | DMS & Dokumentations-Wizard | src\webservice\Centron.WebServices.Core\Entities\{DocuBoard,DocumentationArea} (Anteile in M063/M069) | Dokumentenablage und Dokumentations-Wizards (Kunde, Netzwerk, Mail, Backup). |
| M041 | Workflow-Engine | src\webservice\Centron.WebServices.Core\Entities\Processes (Anteile in M063/M053) | Ablaufsteuerung für Ticket, Kampagne, Umfrage und CrmTask mit Bausteinen und Jobs. |
| M042 | API-Adapter EbInterface | src\apis\Centron.Api.EbInterface | Adapter für die EbInterface-Schnittstelle. |
| M043 | API-Adapter GLS (Versand) | src\apis\Centron.Api.Gls | Versanddienstleister GLS mit Fracht und Label. |
| M044 | API-Adapter Shipcloud | src\apis\Centron.Api.Shipcloud | Versandversand über Shipcloud. |
| M045 | API-Adapter CopDataAccess | src\apis\Centron.APIs.CopDataAccess | Datenanbindung Cop (Webshop). |
| M046 | API-Adapter EgisDataAccess | src\apis\Centron.APIs.EgisDataAccess | Egis-Webshop-Warenkorbanbindung. |
| M047 | API-Adapter FinAPI | src\apis\Centron.APIs.FinAPI | OnlineBanking-FinAPI-Anbindung. |
| M048 | API-Adapter IcecatDataAccess | src\apis\Centron.APIs.IcecatDataAccess | Produktstammdaten von Icecat. |
| M049 | API-Adapter ITscopeDataAccess | src\apis\Centron.APIs.ITscopeDataAccess | Distributoren-Stammdaten und Shop-Anbindung via ITscope. |
| M050 | docuFORM-API | Centron.Api.docuFORM | REST-Client für docuFORM-Formularstrecken. |
| M051 | WPF-Applikationsshell & Modul-Framework | src\centron\Centron.WPF.UI (ohne Modules) + Modules\-Stammdateien | App-Startup, Modulregistrierung und -rechte, Navigation, Services/Logics, Dialoge, Workflows-UI und Localization. |
| M052 | WPF-UI-Erweiterungen | src\centron\Centron.WPF.UI.Extension | Steuerungs- und Modul-Erweiterungsbibliothek des Clients. |
| M053 | Business Logic (Domänenschicht) | src\backend\Centron.BL | Fachliche Logik aller Domänen in über 80 Bereichsordnern. |
| M054 | Interfaces (Verträge/DTO-Grenzen) | src\backend\Centron.Interfaces | Schnittstellen- und DTO-Verträge zwischen UI, BL und DAO. |
| M055 | DAO / Datenzugriff | src\backend\Centron.DAO | Datenbankzugriff inklusive NHibernate-Mappings, NamedQueries und Repositories. |
| M056 | Entities (Datenmodell) | src\backend\Centron.Entities | Persistente Entitäten und Tabellenobjekte. |
| M057 | Common | src\backend\Centron.Common | Domänenübergreifende Grundlagen (Utils, Enums, Exceptions). |
| M058 | Gateway | src\backend\Centron.Gateway | Mandanten- und Datenbank-Gateway zur Verbindungs- und Mandantensteuerung. |
| M059 | Controls (WPF-Bibliothek) | src\shared\Centron.Controls | Wiederverwendbare Masken wie PositionGrid, MyDay, Checklist, PdfScanning, MailTemplates, Telephony und Reports. |
| M060 | Controls.Preview | src\shared\Centron.Controls.Preview | Test- und Preview-App für die Controls-Bibliothek. |
| M061 | Centron.Core | src\shared\Centron.Core | Kern-Utilities, MVVM-Basis, IO, Threading sowie GoogleAuthenticator/TOTP. |
| M062 | ConnectionManager | src\webservice\c-entron.misc.ConnectionManager | Verbindungs- und Mandanten-Verwaltungstool inklusive SQL-Server-Check. |
| M063 | Webservice-Vertragsbibliothek | src\webservice\Centron.WebServices.Core | REST- und WCF-Verträge sowie Clients aller Domänen. |
| M064 | REST-Controller | src\webservice\Centron.Controllers | HTTP-API-Endpunkte v1 für Accounts, Helpdesks, Offers, Orders, Receipts, Tickets, SelfCare und weitere. |
| M065 | Webservice-Host | src\webservice\Centron.Host | AspNetCore-Host mit SignalR, WcfBridge, Telemetrie, HelpPage und RealTimeServices. |
| M066 | Webservice-Host (Console) | src\webservice\Centron.Host.Console | Konsolen-Host des Webservice. |
| M067 | Webservice-Host (Windows Service) | src\webservice\Centron.Host.WindowsService | Windows-Service-Host des Webservice. |
| M068 | Nexus-Host | src\nexus\CentronNexus.Host | Host und Startup des Nexus-Portals. |
| M069 | Nexus Outlook-AddIn | src\nexus\CentronNexus.OutlookAddIn | Outlook-Anbindung für Mails und Kontakte in c-entron. |
| M070 | Scheduler-/Job-Framework (RiverBird) | src\webservice\Centron.WebServices.Core\Entities\Processes (Anteile in M063) | Zeitgesteuerte Jobs, Checklisten-Pläne und Mail-Routinen. |
## 2. Abdeckungstabelle
Die Einstufung folgt dem in Schritt 0c gewählten Zuschnitt und der im Ergebnisbestand dokumentierten Faktentiefe:
- `tief`: mehrere Anforderungen, Risiken bzw. durchsetzende Stellen wurden vertieft.
- `mittel`: mehrere Anforderungen oder Querschnittsregeln, aber nicht jede Implementierungsvariante einzeln durchdrungen.
- `flach`: breitendeckende Mindestabdeckung, vor allem über eine fachliche Regel oder einen Querschnittsbezug.
- `nicht analysiert`: kein eigenständiger fachlicher Anforderungsbezug ohne Erfindung belegbar.
| Modul-ID | Einstufung | Anzahl Anforderungen (Begründung/Auswahl) |
|---|---|---|
| M001 | tief | 14 — Rechte, Benutzer, Lizenzen, Mandant; u. a. StRS-1 bis StRS-14, SyRS-1 bis SyRS-7, SwRS-1 bis SwRS-3. |
| M002 | mittel | 7 — KI-Bestätigung, Rechtefreiheit, Volumengrenzen; StRS-39, SyRS-44, SyRS-52, SwRS-4, SwRS-54. |
| M003 | mittel | 6 — Kalender, Termine, Helpdesk-Zeitbezug; SyRS-37, SwRS-5. |
| M004 | flach | 1 — Dashboard-/Modulstartbreite; StRS-40, SyRS-51. |
| M005 | tief | 16 — Buchhaltung/EDI/Zahlungsverkehr; StRS-18 bis StRS-22, SyRS-20 bis SyRS-27, SwRS-6, SwRS-26. |
| M006 | mittel | 6 — externe Werkzeuge; SyRS-43, SwRS-7. |
| M007 | tief | 10 — Zahlungseingang, Mahnwesen, Opos; StRS-16 bis StRS-18, SyRS-20 bis SyRS-23, SwRS-8, SwRS-9. |
| M008 | mittel | 8 — Kampagnen; StRS-33, SyRS-Kampagnenanker, SwRS-10. |
| M009 | flach | 1 — Finanz-Masterdaten über Pflichtfeld-/Defaultregeln; StRS-24, SyRS-15. |
| M010 | tief | 11 — Vertragsabrechnung und Zähler; StRS-20 bis StRS-21, SyRS-24 bis SyRS-26, SwRS-11, SwRS-12. |
| M011 | tief | 11 — CRM/Accounts; StRS-32, SwRS-15, SyRS-Konten-/Projektanker. |
| M012 | mittel | 5 — PLM-Lebensdauer; StRS-30, SyRS-34, SwRS-14. |
| M013 | mittel | 6 — Projekte/Aufgaben; StRS-32, SyRS-Projektanker. |
| M014 | tief | 11 — Belegwesen Preis/Belegkette; StRS-22 bis StRS-23, SyRS-13 bis SyRS-15, SwRS-16 bis SwRS-19. |
| M015 | mittel | 9 — Custom Properties, MSP; SyRS-6, SwRS-20. |
| M016 | mittel | 6 — GUI-Profile; SyRS-7, SwRS-21. |
| M017 | tief | 10 — Helpdesk/Eskalation; StRS-31, SyRS-35, SwRS-22, SwRS-23. |
| M018 | flach | 3 — Logistik/Versand über Beleg- und Versandregeln; StRS-22, SyRS-43. |
| M019 | mittel | 6 — Massenupdates; StRS-37, SyRS-41. |
| M020 | mittel | 8 — MyCentron/Chat/MyDay; StRS-34, SyRS-12, SwRS-25. |
| M021 | mittel | 5 — OnlineBanking, Toleranz, IBAN; SyRS-27, SwRS-26. |
| M022 | mittel | 5 — PasswordManager und Kennworthärtung; StRS-13, SwRS-27. |
| M023 | mittel | 7 — Zahler/Kostenstellen; StRS-25, SwRS-28, SwRS-29. |
| M024 | mittel | 9 — Produktionslizenz und Fertigungsregeln; SyRS-32, SwRS-30. |
| M025 | mittel | 5 — Projektpreisimport; SyRS-13, SwRS-31. |
| M026 | flach | 3 — Einkauf/Bestellvorschlag; StRS-27, SyRS-31, SwRS-32. |
| M027 | mittel | 5 — QM-Meldungen; SyRS-33, SwRS-33. |
| M028 | tief | 11 — ReportEngine/Kaskaden; StRS-36, SyRS-40, SyRS-53, SwRS-34, SwRS-55. |
| M029 | mittel | 5 — RMA; StRS-29, SyRS-17, SwRS-35. |
| M030 | mittel | 6 — Mailings/Produktmatrix; SyRS-18, SwRS-36. |
| M031 | flach | 4 — Statistiken/Reportrechte; StRS-36, SyRS-39, SwRS-37. |
| M032 | mittel | 5 — Umfragen; StRS-35, SyRS-38, SwRS-38. |
| M033 | mittel | 6 — TelekomDive; SyRS-19, SwRS-39. |
| M034 | tief | 13 — Lager, Artikel, Preise, Inventur; StRS-26 bis StRS-28, SyRS-16, SyRS-30, SwRS-24, SwRS-32, SwRS-41. |
| M035 | tief | 12 — Nexus-Portal, Webrechte, Portallogin; StRS-12 bis StRS-14, SyRS-45 bis SyRS-47, SwRS-42, SwRS-43, SwRS-50. |
| M036 | mittel | 7 — IT-Planer/Assets; SwRS-44, SwRS-45. |
| M037 | flach | 3 — Telefonie/TAPI; StRS-34, SwRS-46. |
| M038 | mittel | 5 — MailScanner; StRS-12, SwRS-47. |
| M039 | flach | 3 — Social Media; StRS-34, SyRS-12, SwRS-48. |
| M040 | flach | 2 — DMS/Dokumentations-Wizard; StRS-15, Portal-/Webserviceanker. |
| M041 | mittel | 5 — Workflow-Engine; StRS-41, SyRS-54. |
| M042 | mittel | 5 — EbInterface; StRS-38, Datenaustauschanker. |
| M043 | flach | 1 — GLS-Versandadapter; StRS-38. |
| M044 | flach | 1 — Shipcloud-Versandadapter; StRS-38. |
| M045 | flach | 1 — Cop-Webshopadapter; StRS-38. |
| M046 | flach | 1 — Egis-Webshopadapter; StRS-38. |
| M047 | flach | 1 — FinAPI-Bankadapter; SyRS-27. |
| M048 | flach | 1 — Icecat-Artikelstammdaten; StRS-23, SwRS-40. |
| M049 | flach | 1 — ITscope-Datenanbindung; StRS-38. |
| M050 | mittel | 5 — docuFORM-Schnittstellengrenzen; StRS-38, SyRS-API-Anker. |
| M051 | mittel | 5 — Shell, Modulregistrierung, Rechte-Gate; StRS-40, SyRS-51. |
| M052 | flach | 1 — UI-Erweiterungen; SyRS-51, StRS-40. |
| M053 | mittel | 4 — zentrale BL-Autorisierung und Domänenlogik; SyRS-49, SwRS-1, SwRS-49. |
| M054 | flach | 1 — Schnittstellenverträge/DTO-Grenzen; SyRS-56, SwRS-56. |
| M055 | flach | 1 — DAO-/NHibernate-Zugriff; StRS-24, SwRS-3. |
| M056 | flach | 2 — Entities und Mappings; SyRS-2, SwRS-3. |
| M057 | mittel | 5 — Common-Krypto, Utilities; SyRS-56, SwRS-52. |
| M058 | flach | 1 — Gateway/Mandantentrennung; SyRS-60. |
| M059 | flach | 1 — WPF-Controls/Pflichtfelder in Eingabemasken; StRS-24, SyRS-6. |
| M060 | nicht analysiert | 0 — reine Test-/Preview-App ohne eigenständige fachliche Anforderung; keine Anforderung ohne Beleg erfunden. |
| M061 | mittel | 4 — Core/TOTP-Grundlagen; SyRS-56, SwRS-56. |
| M062 | flach | 1 — ConnectionManager/Gateway-Bezug; SyRS-60. |
| M063 | flach | 2 — Webservice-Vertragsbibliothek und REST/WCF-Verträge; SyRS-49, SyRS-57. |
| M064 | mittel | 4 — REST-Controller/API-Perimeter; StRS-10, SyRS-57, SyRS-58. |
| M065 | mittel | 4 — Webservice-Host, CORS, TicketAuth, Deployment; StRS-9 bis StRS-11, SyRS-58, SyRS-59. |
| M066 | flach | 1 — Konsolen-Host über Deployment-/Konfigurationshärtung; SyRS-59. |
| M067 | flach | 1 — Windows-Service-Host über Deployment-/Konfigurationshärtung; SyRS-59. |
| M068 | flach | 1 — Nexus-Host über Portal-/API-Perimeter; SyRS-57. |
| M069 | flach | 3 — Outlook-AddIn mit Mail-/Kontaktanbindung; StRS-12, SwRS-46, SwRS-47. |
| M070 | mittel | 6 — Scheduler/Jobs; StRS-41, SyRS-55. |
## 3. Dokumentation der tatsächlichen Beauftragung
Die Bearbeitung war rollenspezialisiert. Die bindenden Teilaufgaben wurden nicht vom Orchestrator selbst erledigt, sondern an die vorgesehenen Bearbeiter übergeben. Zuschnitt, Anzahl und Tiefe wurden vom Orchestrator entschieden.
| Bearbeiter | Teilaufgabe | Anzahl Beauftragungen | Zuschnitt / Ergebnisumfang |
|---|---|---:|---|
| modulinventar | Modulinventar (Schritt 0) | 2 | 1. Vollständiges Inventar; 2. erneute Ausgabe der vollständigen Tabelle zur Aufnahme in diesen Bericht. Ergebnis: 70 Module M001 bis M070. |
| faktenermittler | Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | 10 | A: M001, M015, M016, M023; B: M011, M013, M008, M020; C: M014, M018, M029, M030, M033; D: M007, M010, M021; E: M034, M026, M024, M027, M012; F: M017, M003, M032, M031, M028, M019, M025, M006, M004, M002; G: M035, M069, M040, M038, M039, M037, M022; H: M005, M042 bis M050; I: M041, M070, M036; J: M051, M053, M054, M055, M056, M057, M058, M061, M062, M063, M064, M065, Deployment/Config. |
| strs-autor | Formulierung der StRS-Anforderungen | 2 | Erste Ausgabe StRS-1 bis StRS-38 (am Ende abgeschnitten); Nachlieferung korrigierte StRS-38 und ergänzte StRS-39 bis StRS-41. Ergebnis: 41 StRS. |
| syrs-autor | Formulierung der SyRS-Anforderungen | 2 | Erste Ausgabe SyRS-1 bis SyRS-48 (abgeschnitten); Nachlieferung korrigierte SyRS-48 und ergänzte SyRS-49 bis SyRS-60. Ergebnis: 60 SyRS. |
| swrs-autor | Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | 2 | Erste Ausgabe SwRS-1 bis SwRS-48 (abgeschnitten); Nachlieferung korrigierte SwRS-48 und ergänzte SwRS-49 bis SwRS-56 sowie Konsolidierungsübersicht. Ergebnis: 56 SwRS. |
| belegpruefer | Prüfung ausgewiesener Belege gegen die Codebasis | 1 | Risikorelevante Stichprobe: SyRS-20, SyRS-27, SyRS-13, SyRS-58, SyRS-59, SwRS-1, SwRS-3, SwRS-16, SwRS-22, SwRS-48, SwRS-52. |
| iso29148-orchestrator | Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | 1 | Prüfumfang: Forward-/Backward-Sicht, Tracelinks, Doppelführungen, Mindestabdeckung, Ebenenklarheit, Belegstellen in fremdem Ausschnitt. |
| konsistenzpruefer | Konsistenzcheck des fertigen Anforderungssatzes (Abschluss) | 2 | 1. Erster Gesamtcheck vor Konsolidierung der Nachlieferung; 2. Abschluss-Check nach Korrektur von Tracelinks, Belegen, Konsolidierungen, Statuswerten und nach Anlage der Sammeldateien. |
Vom Orchestrator selbst ausgeführt wurden ausdrücklich nur die ihm zugewiesenen orchestrierenden Aufgaben: Zuschnitt der Ausschnitte, Vergabe/Prüfung der ID-Bereiche je Ebene, Anlegen und Zusammenführen der Ergebnisdateien, Übernahme der Prüfbefunde, Bereinigung offener Tracelinks und Belegstellen, Erzeugung von `Traceability.md`, `Hypothesen.md`, `Glossar.md` und `Analysebericht.md`. Für die acht rollengebundenen Teilaufgaben wurde keine durch den Orchestrator selbst erledigt.
## 4. Prüfergebnisse
### 4.1 Ergebnisumfang
- StRS: 41 Anforderungen (`StRS-1` bis `StRS-41`), lückenlos.
- SyRS: 60 Anforderungen (`SyRS-1` bis `SyRS-60`), lückenlos.
- SwRS: 56 Anforderungen (`SwRS-1` bis `SwRS-56`), lückenlos.
- Gesamtbestand: 157 Anforderungen.
- Traceability: 72 Tabellenzeilen in `Traceability.md`.
- Hypothesen: 64 Anforderungen mit `Status: HYPOTHESE` bzw. Inline-Markierung `[HYPOTHESE]`; Abgleich siehe 4.4.
### 4.2 Belegprüfung
Der `belegpruefer` prüfte eine risikorelevante Stichprobe gegen die Codebasis.
Bestätigte risikorelevante Belege unter anderem für:
- `SyRS-20`: Löschrecht und Gegenbuchung über `CurrencyFactor`.
- `SyRS-27`: Toleranz `0,10` in `CheckForCompleted`.
- `SwRS-16`: zweistufige Netto-Rundung `AwayFromZero`.
- `SyRS-58` / `SyRS-59`: TicketAuth, X-Forwarded-For, CORS, 2FA-Default, BinaryFormatter-Schalter, Versionsstand, SA-Zugangsdaten in Konfiguration.
- `SwRS-22`: Eskalationsstufen-Roh-SQL.
- `SwRS-3`: ORM-Mapping `Password` auf `BenutzerInfo2`.
- `SwRS-1`: Roh-SQL-Rechteauflösung und Rechts-Cache.
Festgestellte Abweichungen und behobene Punkte:
1. `SwRS-48`: Die ursprüngliche Dateiangabe `SQLScriptCollection1.xml` war im gespiegelten Bestand nicht auffindbar. Der inhaltliche Nachweis wurde auf `SSMS_DB_SCHEMA.sql` umgestellt: `spr_SocialMediaRemoveComment` und `spr_SocialMediaUpdateComment`. Die überhöhte Fundstellenangabe „16 Fundstellen“ wurde auf „6 Fundstellen (2 exakte CASE-Varianten, 6 Varianten insgesamt)“ korrigiert.
2. `SyRS-13`: Die zitierten Zeilen 202-213 deckten nur die Netto-Rundung. Der Beleg wurde um die USt-Gruppierung und CH-Rundung (Zeilen 37-93) erweitert.
3. `SyRS-58`: Die zitierten Handler-/Host-Stellen tragen Ticket-, IP- und CORS-Anteile. Die SignalR-/WCF-/Port-Anteile wurden als `HYPOTHESE` offengelegt.
4. `SwRS-1`: Die Aussage „Sichtrus-PK auf I3D“ war ungenau; der tragende Befund „keine ausreichende Eindeutigkeit, JOIN-Duplikate möglich“ bleibt bestehen.
5. 13 SwRS-Anforderungen tragen den Hinweis, dass `PRIMÄR` aus der Faktenbasis stamme und im Lauf nicht Zeile für Zeile gegengeprüft worden sei. Diese Blöcke wurden auf `Status: HYPOTHESE` gesetzt und sind in `Hypothesen.md` enthalten.
### 4.3 Nahtstellenprüfung
Der `iso29148-orchestrator` meldete nach Bereinigung der bekannten Phantom-IDs unter anderem:
- SyRS-40 und SyRS-53 waren eine inhaltliche Doppelführung zum Report-Löschpfad. Beide wurden nun gegenseitig als Konsolidierungskandidaten markiert.
- SyRS-44 und SyRS-52 sowie SwRS-4 und SwRS-54 waren weitere unklare Fachdopplungen. Sie wurden beidseitig als Konsolidierungskandidaten markiert.
- SwRS-50 zeigte versehentlich auf SyRS-57, obwohl SyRS-45 die Weblogin-/Webaccount-Regel trägt. Der Tracelink wurde korrigiert.
- SwRS-56 hatte nach der Nachlieferung keinen StRS-Anker. Es wurden SyRS-45, SyRS-56 sowie StRS-10 und StRS-13 ergänzt.
- Die Prüfung meldete, dass einige SyRS-Blöcke `.cs`-Belege im SwRS-Ausschnitt führen. Das wurde als bekannte Qualitätsschwäche dokumentiert; die SyRS-Blöcke tragen weiterhin Belege, die den Systemzusammenhang beschreiben, die eigentliche Implementierungsstelle bleibt aber in den SwRS-Blöcken nachvollziehbar.
### 4.4 Konsistenzcheck
Der finale Konsistenzcheck ergab:
- Doppelte IDs: keine.
- Lückenlose ID-Reihen: StRS-1 bis StRS-41, SyRS-1 bis SyRS-60, SwRS-1 bis SwRS-56.
- Anforderungen ohne Beleg: keine.
- Anforderungen ohne Übernahmewürdigkeit: keine.
- Numerische Tracelinks auf nicht existierende IDs: keine offenen Verstöße. Ursprünglich zeigten 40 Referenzen auf SyRS-70 bis SyRS-78 bzw. SwRS-59 bis SwRS-67; diese Phantomverweise wurden entfernt bzw. auf existierende IDs umgelenkt.
- Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungskennzeichnung: keine offenen Verstöße. Die gemeldeten Paare sind jetzt markiert.
- Risikorelevante Anforderungen ohne `PRIMÄR` und ohne `HYPOTHESE`: keine offenen Verstöße. Die beiden ursprünglichen Verstöße StRS-31 und StRS-34 wurden als Hypothesen gekennzeichnet.
- Hypothesenabgleich: `Hypothesen.md` ist deckungsgleich mit den Anforderungen mit Inline-Markierung oder `Status: HYPOTHESE`; erfasste Gesamtzahl: 64.
- Sieben Ergebnisdateien: vollständig vorhanden.
Der Abschluss-Check meldete keine offenen Verstöße in den sieben Kernkriterien. Die im Vorlauf offene Datei `Analysebericht.md` ist mit diesem Dokument vorhanden.
## 5. Selbstbewertung
### 5.1 Tiefenabdeckung
Absolut:
- tief analysiert: 10 Module.
- mittel analysiert: 32 Module.
- flach analysiert: 27 Module.
- nicht analysiert: 1 Modul.
### 5.2 Mindestabdeckung
Die Mindestabdeckung ist für 69 von 70 Modulen erreicht.
Nicht erfasst mit eigener Anforderung:
- M060 Controls.Preview: reine Test-/Preview-Anwendung. Eine fachliche Anforderung wäre ohne Beleg erfunden worden; daher ist sie im Inventar mit Begründung als `nicht analysiert` geführt.
Der Anteil der nicht analysierten Module liegt bei 1,43 Prozent. Der Schwellenwert von mehr als 10 Prozent wird nicht überschritten. Die Breite des Inventars ist damit grundsätzlich abgedeckt; viele API-Adapter und Host-Varianten sind allerdings nur flach über StRS-38, SyRS-57, SyRS-58 oder SyRS-59 eingebunden.
### 5.3 Dünne Belegstellen
- 64 Anforderungen tragen den Status oder die Inline-Markierung `HYPOTHESE`.
- 13 SwRS-Anforderungen führen zwar einen PRIMÄR-Hinweis, aber mit dem ausdrücklichen Zusatz, dass die Stellen aus der Faktenbasis stammen und im Lauf nicht zeilenweise gegengeprüft wurden. Diese Anforderungen sind wegen der ungenügenden Prüftiefe auf `Status: HYPOTHESE` gesetzt.
- Die Prüfung von `SwRS-48` deckte einen falschen Dateipfad auf. Solche Faktenbasis-Direktübernahmen sind nach dem Befund grundsätzlich mit Vorsicht zu behandeln.
- In SyRS-Blöcken werden teilweise Implementierungsstellen aus dem SwRS-Ausschnitt als Beleg genutzt. Das ist für die Systemebene teilweise akzeptabel, weil die durchgesetzte Stelle dort das Systemverhalten trägt; für eine saubere Ebenentrennung wäre eine Umformulierung auf Schnittstellen-/Serviceebene wünschenswert.
- Traceability enthält für einige Kurzanker nur unscharfe semantische Brücken. Die fünf im Abschluss-Check zunächst offenen StRS-Zeilen wurden ergänzt; die restlichen Kurzanker bleiben als redaktionelle Zuordnung erkennbar, sind aber nicht mehr als numerische Tracelinks ins Leere gesetzt.
### 5.4 Hypothesen
Es wurden 64 Hypothesen geführt. Eine Analyse dieser Größe ohne offene Punkte wäre unplausibel gewesen, insbesondere weil:
- viele Fakten aus einer faktenermittler-Aufbereitung stammten und nicht jede Stelle im Orchestrator-Lauf erneut zeilenweise geöffnet wurde,
- die Codebasis stark über Konfiguration, Legacy-Tabellen, Roh-SQL und clientseitige Validierungen gesteuert wird,
- für Deployment, Server-Nebenwirkungen, Cache-Lebensdauer und serverseitige Durchsetzung keine Laufzeitbelege vorliegen,
- einige fachliche Soll-Regeln aus Ist-Negativbefunden abgeleitet sind.
### 5.5 Erkenntnisse für eine Folgeiteration
Ein Nachschlag ist besonders sinnvoll bei:
1. Serverseitiger Zweitprüfung von KI-Anhangsgrenzen, Portaloperationen und Berechtigungen.
2. Cache-Lebensdauer und Invalidierung der Rechtsauflösung, insbesondere `AllRightsFromAppUser` und `AllRightsFromWebAccount`.
3. Vollständiger Prüfung aller API-Adapter M043 bis M049, die bisher vor allem flach über Schnittstellengrenzen erfasst sind.
4. Telefonie M037, Kostenstelle M023 und DMS M040, wo die SyRS-Traceability noch nicht durch eigene numerische SyRS-IDs vollständig aufgelöst ist.
5. Nexus-Host M068, Console-Host M066 und Windows-Service-Host M067, sofern die Web-/SaaS-Zielarchitektur Host- und Deploymentvarianten explizit abbilden soll.
6. Kontrolle der Faktenbasis gegen Einzelstellen: Die Korrektur in `SwRS-48` zeigt, dass überlieferte Datei-/Zeilenangaben in einer Folgeiteration systematisch gegen den Schema-Dump und die BL-Dateien validiert werden sollten.
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/Glossar.md
+134
View File
@@ -0,0 +1,134 @@
# Glossar
Die Begriffe stammen aus den Anforderungen und den analysierten Artefakten. Technische Bezeichner bleiben in ihrer Originalsprache.
## Anforderungsmethodik
| Begriff | Bedeutung im Bestand |
|---|---|
| RRE | Reverse Requirements Engineering: Ableitung von Anforderungen aus vorhandenen Artefakten des Legacy-Systems. |
| StRS | Stakeholder Requirements Specification: fachliche Ebene mit Akteuren, Geschäftszielen und fachlichen Regeln. |
| SyRS | System Requirements Specification: Systemebene mit Verhalten, Schnittstellen, Sicherheits- und Qualitätsanforderungen. |
| SwRS | Software Requirements Specification: Softwareebene mit Komponenten, Datenmodellen und internen Regeln. |
| PRIMÄR | Belegklasse für eine durchgesetzte Regel im Code oder Datenbank-Constraint. |
| SEKUNDÄR | Belegklasse für mittelbare Signale wie UI-Labels, Konfigurationsschalter oder Mappings. |
| KONTEXT | Belegklasse für Kommentare, Faktenbasis-Verweise oder andere interpretierende Hinweise. |
| HYPOTHESE | Kennzeichnung für Aussagen, die nicht vollständig durch die gelesenen Artefakte belegt sind. |
| Traceability | Nachvollziehbare Verbindung zwischen StRS, SyRS und SwRS sowie zu Artefaktbelegen. |
| Konsolidierung | Kennzeichnung, wenn derselbe fachliche Gegenstand in getrennten Implementierungen geführt wird. |
| Übernahmewürdigkeit | Einschätzung, ob die Anforderung im Zielsystem übernommen, als Workaround, Sonderfall oder veraltete Logik behandelt werden soll. |
| Mindestabdeckung | Vorgabe, dass jedes Modul des Modulinventars mindestens eine belegte Anforderung oder eine Begründung ohne Anforderung erhält. |
## Rechte, Identität und Sicherheit
| Begriff | Bedeutung im Bestand |
|---|---|
| AppRightsBL | Business-Logic-Klasse zur Auflösung von AppUser-Rechten und WebAccount-Rechten. |
| HasUserRight | Prüfungsmethode in `AppRightsBL`, mit der eine Fachaktion gegen die aufgelöste Rechtsmenge prüft. |
| HasWebAccountRight | Zweiter Rechtszweig in `AppRightsBL` für Webkonten über die Tabelle `WebAccountsRights`. |
| AllRightsFromAppUser | Cache-Schlüsselpräfix für die gecachte Rechtsmenge eines `AppUser`. |
| AllRightsFromWebAccount | Cache-Schlüsselpräfix für die gecachte Rechtsmenge eines `WebAccount`. |
| AppUser | Internes Benutzerkonto der ERP-Anwendung. |
| WebAccount | Portal-/Webkonto, das eigene Rechte über `WebAccountsRights` erhält. |
| Sichmemb | Tabelle der Gruppenmitgliedschaften im internen Rechtebaum. |
| Sichtrus | Tabelle der Rechte im Gruppen-/Benutzersystem; laut Analyse ohne ausreichende Schlüsseleindeutigkeit. |
| Sichtrus/Sichmemb-Kette | Interne Rechtsableitung über Benutzer, Gruppenmitgliedschaft und Recht. |
| WebAccountsRights | Zuordnungstabelle zwischen WebAccount und Webrecht; ohne ausreichende PK-/UNIQUE-/FK-Absicherung analysiert. |
| WebRights | Referenzdaten für Portalrechte eines Webkontos. |
| BenutzerInfo2 | Altdatenbanksäule, auf die `AppUser.Password` per NHibernate-Mapping abgebildet wird. |
| PasswordManagementKeyword | Kennwort- oder Geheimnisfeld in Kontexten wie Passwortspeicher; in Analysen als leere Haltung ohne verbindliche Härtungsregel erkannt. |
| TwoFactorAuthEnabled | Konfigurationsschalter für Zwei-Faktor-Prüfung im Webservice. |
| TOTP | Time-based One-Time Password; in der Codebasis über GoogleAuthenticator-artige Logik verwendet. |
| BLTwoFactorAuthenticationLogic | Client-/BL-Pfad für TOTP-Schlüsselverwaltung und PIN-Prüfung. |
| WSTwoFactorAuthenticationLogic | Webservice-/REST-Pfad für dieselbe TOTP-Funktionalität. |
| TicketAuthenticationHandler | Authentifizierungslogik im Webservice-Host, die Tickets aus Query oder Header übernimmt. |
| AllowAnyOrigin | CORS-Konfiguration in `CentronHost.cs`, die beliebige Absender-Origin zulässt. |
| X-Forwarded-For | HTTP-Header zur Vermittlung der Client-IP; im Bestand ungeprüft als vertrauenswürdig erkannt. |
| AESCryptoLogic | AES-Verschlüsselungskomponente mit optionalem Schlüssel und Default-Schlüssel. |
| SECURITY_KEY | Im Quellcode hinterlegter Standard-Schlüssel von `AESCryptoLogic`. |
| EncryptWithMasterKey | Mechanismus zur Verschlüsselung gespeicherter Geheimdaten über einen Masterkey. |
| SHA1Decoder.GetDecodedSHA1String | Erzeugung eines SHA1-Kennworthashs; im WebAccount-Pfad ohne Salt beobachtet. |
| Fail-closed | Sicherheitsverhalten, bei dem ein Fehler in einer Prüfung ablehnend statt freigebend wirkt. |
## Abrechnung, Zahlungen und Verträge
| Begriff | Bedeutung im Bestand |
|---|---|
| PaymentTransactionBL | Komponente für Zahlungsverkehrsvorgänge. |
| Zahlungseingang | Zahlungseingangsobjekt bzw. Bankimport-/Zuordnungsvorgang, der Zahlungen Buchungen zuordnet. |
| PaymentsBL | Business-Logik für Zahlungseingänge, inklusive Rechtsgate und Gegenbuchung beim Löschen. |
| OnlineBankingAccountTransactionsBL | Bankumsätze und Abschlussprüfung, inklusive Toleranz für Kleinbetragsdifferenzen. |
| CheckForCompleted | Methode, die einen Vorgang bei Differenzen bis 0,10 als abgeschlossen behandelt. |
| Opos | Offene Posten; Zugriffs- und Mahnkontext der Finanzkomponente. |
| Mahnstufe | Eskalationsstufe im Mahnwesen, insbesondere L0 bis L3. |
| DunningRunBL | Mahlauf-Laufkomponente mit Status- und Rechtlogik. |
| SEPA | Zahlungsnorm; im Bestand mit Limit- und IBAN-Regeln untersucht. |
| CurrencyFactor | Währungsfaktor zur Gegenbuchung bei Zahlungseingängen. |
| ContractBL | Vertragslogik, insbesondere Vertragsende und Abrechnungslogik. |
| RefreshContractEndeDate | Methode zur Neuberechnung des Vertragsendes inklusive Kündigungs-Kappung. |
| TimerBilling | Zeitbasierte Abrechnung von Verträgen/Servicezeiten. |
| DeviceClickCounter | Gerätezähler, insbesondere für Click-/Kontingentabrechnung. |
| Kostentraeger | Domänentabelle für den Zahler/Kostenträger eines Kontos. |
| Kostenstelle | Kostenrechnungsobjekt, das in den Anforderungen als historisch bzw. doppelt gepflegt markiert wurde. |
| Zahler / Payers | UI-Begriff für das Domänenobjekt Kostenträger. |
## Belege, Vertrieb und Leistungserfassung
| Begriff | Bedeutung im Bestand |
|---|---|
| ReceiptPriceHelper | Preisberechnungs-Helfer im Webservice-Kern. |
| AwayFromZero | Rundungsmodus `MidpointRounding.AwayFromZero` für Netto-/Preisrundung. |
| TaxRate | USt-Schlüssel je Belegposition; im Preis-Helfer gruppenbildend. |
| CH-Rundung | Landeswährungsbezogene Rundung auf 0,05 für die Schweiz. |
| Belegkette | Vorwärtsfolge Angebot, Anfrage, Auftrag, Lieferschein, Rechnung. |
| Forward-Regel | Regel, die das Anlegen oder Umwandeln von Belegen nur in definierte Nachfolgebelege zulässt. |
| CustomProperty | Benutzerdefinierte Zusatzfeld-Definition im Objektmodell. |
| IsMandatory | Pflichtfeld-Markierung einer CustomProperty; Validierung im Bestand primär clientseitig erkannt. |
| Edit-Time / EDIT_TIME | Zeit-/Leistungserfassungsregel zum Schutz fakturierter Zeiten. |
| Auftragsabschluss | Statuswechsel eines Auftrags, der vollständige Positionserfassung voraussetzt. |
| PLM | Product Lifecycle Management; Produktlebenslauf, Produktfamilien und Lebensdauerlogik. |
| RMA | Return Merchandise Authorization; Retourenprozess mit Helpdeskbezug. |
| EDI | Electronic Data Interchange; Datenaustausch über Partneradapter. |
| DATEV | Export-/Schnittstellenkontext zur Buchhaltung. |
## Portal, Webservice und Infrastruktur
| Begriff | Bedeutung im Bestand |
|---|---|
| Nexus | Kundenportal-/Webkomponente der Suite mit ServiceBoard, Webshop und Verwaltung. |
| WebAccountBL | Business-Logik für Webaccount-Login, Status und Kundenaktivität. |
| UpdateWebAccountPassword | Pfad zum Passwortwechsel eines Webaccounts im Portal. |
| ClaimsService | Abbildung von Webrechten in Anspruchs-/Claims-Listen. |
| CentronHost | Host des Webservers; enthält CORS- und Authentifizierungskonfiguration. |
| WebServiceConfig.xml | Konfigurationsdatei des Webservice-Hosts mit Sicherheits- und Datenbankzugangsangaben. |
| Directory.Build.props | Zentrale MSBuild-Konfiguration; enthält im Lauf risikorelevante Serializationseinstellungen. |
| version.json | Versions-/Release-Datei mit Versions- und Pre-Release-Angaben. |
| AllowUnsafeBinaryFormatterSerialization | .NET-Konfigurationsschalter, der unsichere BinaryFormatter-Serialisierung erlaubt. |
| NHibernate | ORM-Schicht für Entitätsmappings und Datenzugriff. |
| BL | Business Logic; Domänenschicht in `src/backend/Centron.BL`. |
| DAO | Data Access Object / Datenzugriffsschicht in `src/backend/Centron.DAO`. |
| Entities | Persistente Entitäten in `src/backend/Centron.Entities`. |
| Webservice-Vertragsbibliothek | REST-/WCF-Verträge und Clients in `src/webservice/Centron.WebServices.Core`. |
## Datenbank, Synchronisation und Querschnitt
| Begriff | Bedeutung im Bestand |
|---|---|
| SSMS_DB_SCHEMA.sql | Vollständiger Datenbank-Schema-Dump des Bestands; zentrale Belegquelle für Tabellen, Constraints und Stored Procedures. |
| PK | Primary Key; Primärschlüssel einer Tabelle. |
| FK | Foreign Key; Fremdschlüsselconstraint. |
| UNIQUE | Eindeutigkeitsconstraint. |
| CHECK | Prüfung auf Constraint-Ebene, etwa Wertebereich oder Gültigkeit. |
| NOT NULL | Spalteneigenschaft, die NULL-Werte auf Datenbankebene ausschließt. |
| CSI_* | Tabellenfamilie mit höherer Constraint-Dichte innerhalb des ansonsten FK-armen Schemas. |
| EmployeeI3D | Mitarbeiter-/Benutzeridentifikator in Social-Media- und Bearbeitungsregeln. |
| SocialMediaKind | Codierung, ob ein Social-Media-Element zu einem Stream oder einer Aktion gehört. |
| spr_SocialMedia* | Stored Procedures für Social-Media-Kommentare und Likes; durchsetzen Eigentumsregeln über das `EmployeeI3D`-Prädikat. |
| ExternalTools | Datenhaltung und Startmechanismus für extern eingebundene Werkzeuge. |
| RiverBird | Job-/Scheduler-/Automatisierungsumfeld der Suite. |
| RiverDive | Monitoring-/Deployments-/IT-Dokumentationsumfeld für Kunden-Infrastruktur. |
| MSP | Managed-Service-/Mandantenkontext in Lizenz- und Rechtefragen. |
| Filialgrenze | Beschränkung von Datenzugriff oder Anzeige auf eine Filiale. |
| SHOW_HELPDESK_ONLY_OWN_BRANCH | Flag/Regel für Helpdesk-Filialbeschränkung; im Bestand primär UI-seitig erkannt. |
| AppUser.Password | Modellmerkmal des internen Benutzers, das auf die Altsäule `BenutzerInfo2` gemappt wird. |
| DueTo | Terminwiedervorlage im Helpdesk; Änderungen beeinflussen Eskalationslogik. |
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/Hypothesen.md
+206
View File
@@ -0,0 +1,206 @@
# Hypothesen
Diese Sammlung enthält ausschließlich Anforderungen, die in den drei Ebenendateien inline als `[HYPOTHESE]` gekennzeichnet sind oder deren Status nach der Konsolidierung `HYPOTHESE` lautet. Freie Fragen ohne Anforderungsbezug stehen im `Analysebericht.md`.
## StRS (25)
- **StRS-7** — Berechtigungs- und Plausibilitätsprüfungen müssen serverseitig und lückenlos greifen
- Status: HYPOTHESE
- Offene Frage / Grund: [SEKUNDÄR] Faktenbasis M015, M027, M022, M038, M019, M037, M017, M028 — Zitate wörtlich wie im Fakt; Fundstellen/Einstufungen teils als (HYPOTHESE) gekennzeichnet.
- **StRS-8** — Modulzugang erfordert Recht und Lizenz zugleich
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll ein Fachmodul nur öffnen, wenn der Benutzer sowohl das Modulrecht besitzt als auch die zugehörige Modul-Lizenz gültig ist; Fehlen einer Bedingung verschließt das Modul vollständig.
- **StRS-9** — Dienstzugriffe werden fehlgeschlossen authentifiziert; Header-Angaben sind keine Identitätsnachweise
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll jeden Dienstaufruf ohne gültiges Ticket oder Token ablehnen (Versagen führt zur Ablehnung, „fail-closed"); Tickets und Client-Identifikation dürfen nicht allein aus selbstgesetzten Header-/Query-Werten abgeleitet werden, ohne dass deren Herkunft geprüft wird.
- **StRS-10** — Durchgehende Autorisierung aller REST-Dienste und der Zwei-Faktor-Endpunkte
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll jeden REST-Endpunkt nur nach erfolgreicher Autorisierung beantworten; die Endpunkte des Zwei-Faktor-Verfahrens dürfen nicht ohne Authentifizierung erreichbar sein.
- **StRS-11** — Verschlüsselung gespeicherter schutzbedürftiger Daten; kein einheitlicher Standard-Schlüssel
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll schutzbedürftige gespeicherte Daten verschlüsseln (AES) und dabei mandantenspezifisch verwaltete Schlüssel verwenden; ein produktionsweiter Standard-/Auslieferungsschlüssel darf nicht die einzige Schlüsselmacht sein.
- **StRS-12** — Portal-Anmeldung prüft Kontostatus, Kennwort und Kundenaktivität; Portalrechte leiten sich aus Webrechten ab
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll die Portal-Anmeldung nur gewähren, wenn Portal-Kontostatus aktiv, Kennwort korrekt und Stammkunde aktiv ist, und die Portalfunktionen des Angemeldeten ausschließlich aus den zugewiesenen Webrechten als Rollen ableiten; die Kennwortablage ist gegen moderne, robuste Hashverfahren weiterzuentwickeln (SHA1 genügt nicht).
- **StRS-13** — Zwei-Faktor-Verfahren und Kennworthärte sind aktiv zu betreiben
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll für Portal-/WebAccount-Zugänge das Zwei-Faktor-Verfahren als Auslieferungszustand anbieten und dessen Aktivierung nicht dauerhaft unterdrücken; die TOTP-Gültigkeitstoleranz von ±4 Minuten ist fachlich zu begrenzen; Portal-Kennwörter sollen über eine Mindestlänge von 8 hinaus gehärtet werden; ein administratives Zugangskennwort darf nicht als Klartext im Deployment hinterlegt sein.
- **StRS-14** — Kennwortwechsel im Portal nur nach Besitzerprüfung
- Status: HYPOTHESE
- Offene Frage / Grund: [SEKUNDÄR] Faktenbasis M035 — wörtlich inkl. Kennzeichnung (HYPOTHESE); Fundstelle nicht genannt.
- **StRS-15** — Dokumentenablage unterscheidet interne und öffentliche Dokumente mit getrennter Rechteprüfung
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll den Zugriff auf interne Dokumente nur mit dem internen Dokumentenrecht gewähren und öffentliche Dokumente ohne dieses Recht freigeben; Portalbenutzer (WebAccount) sind nicht von der Rechteprüfung befreit, sondern ausschließlich auf die öffentliche Sphäre zu beschränken.
- **StRS-16** — Zahlungseingänge nur mit Recht und gegen ausgleichende Gegenbuchung stornierbar
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll das Löschen eines Zahlungseingangs nur berechtigten Buchhaltungsbenutzern gestatten und dabei automatisch eine Gegenbuchung erzeugen, die die Finanzwirksamkeit des ursprünglichen Zugangs vollständig ausgleicht (keine stille Löschung).
- **StRS-17** — Mahnwesen folgt den Stufen L0–L3; Kassensystem-Mahnrucke setzen Mahnrecht voraus
- Status: HYPOTHESE
- Offene Frage / Grund: [SEKUNDÄR] Faktenbasis M007 — „Mahnwesen Stufen L0-L3 (Gebühren nicht belegt=HYPOTHESE). Opos braucht Mahnrecht."; Fundstelle nicht genannt.
- **StRS-18** — Banktransaktionen gelten bei Kleinbetragsdifferenz als ausgeglichen; IBAN deutscher Konten hat Mindestlänge 22
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll eine Banktransaktion als ausgeglichen („completed") abschließen, wenn die Betragsdifferenz zum Buchungsbestand ±0,10 nicht übersteigt; IBANen deutscher Banken (Kürzel DE) sollen mindestens 22 Zeichen tragen, sonst ist die Eingabe zurückzuweisen.
- **StRS-19** — SEPA-Zahlungen halten das vereinbarte Betragslimit ein
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll einen SEPA-Auftrag nur erstellen und zur Bank weiterleiten, dessen Betrag innerhalb des konfigurierten Betragslimits liegt; darüber hinausgehende Beträge sind zu sperren und dem Sachbearbeiter zu melden.
- **StRS-20** — Vertragsende aus Laufzeit ableiten und Kündigungsdatum kappen
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll das Vertragsende aus der vereinbarten Laufzeit ableiten und ein erklärtes Kündigungsdatum auf das höchstens zulässige Vertragsende kappen, sodass kein Vertragsverhältnis über sein Ende hinaus fortbesteht.
- **StRS-21** — Erfassungs- und Abrechnungsschutz für geleistete Zeiten
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll die Erfassung und Änderung von Zeitdaten nur mit dem Recht EDIT_TIME gestatten; einmal fakturierte Zeiten dürfen nachträglich nicht mehr verändert werden, und für rechnungs- bzw. auftragsgesperrte Objekte ist die Zeitänderung zu sperren.
- **StRS-22** — Belegkette Angebot → Auftrag → Lieferschein → Rechnung folgt Vorwärtsregeln
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll Folgebelege nur entlang der Kette Angebot → Auftrag → Lieferschein → Rechnung erzeugen lassen und dabei die jeweiligen Vorwärtsregeln (zulässige Nachfolgebelege, Mengenübernahme) einhalten.
- **StRS-23** — Einheitliche Preisbildung: Netto/USt, Mengenpreis, Projektpreis, kundenspezifische Abschläge, Einstandspreis
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll Bruchteile eines Preises konsistent bilden: Nettobetrag und Umsatzsteuer getrennt ausgewiesen; im Mengenpreis die höchste Stufe mit FromAmount ≤ bestellter Menge; Projektpreise als Grundpreis mal vereinbartem Faktor; Kunden-/Partnerprofile (z. B. TelekomDive) mit Rabatt- und USt-Vorgabe je Mandant; der Einstandspreis als gleitender Durchschnitt geführt.
- **StRS-31** — Helpdesk-Eskalation nach Wartezeit, Wochenendsteuerung und Wiederaufnahme; Hilfezeiten als Termine nutzbar
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE: Die serverseitige Filialbeschränkung und die Eskalationsschwellen sind nur über die Faktenbasis M017 belegt; eine durchsetzende Fundstelle fehlt.]
- **StRS-34** — Kommunikationsinhalte nur durch Berechtigte und nur im eigenen Namen
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE: Die Mitglieder-/Autorschafts-Regel ist nur über Faktenbasis M020/M039 belegt; eine durchsetzende Stelle für alle Kommunikationspfade ist nicht benannt.]
- **StRS-36** — Auswertungsobjekte: Reports nur mit Recht löschbar, Klickzahlen nur monoton
- Status: HYPOTHESE
- Offene Frage / Grund: [SEKUNDÄR] Faktenbasis M028 (HYPOTHESE), M010 — wörtlich zitiert; Fundstellen nicht genannt.
- **StRS-37** — Massenaktualisierung nur bei vollständiger Bearbeitung; Modul ist zu sichern
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll eine Massenaktualisierung nur dann als erledigt abschließen, wenn alle betroffenen Datensätze bearbeitet wurden; das Massenupdate-Modul soll zusätzlich an ein Fachrecht gebunden werden (bisher rechtefrei).
- **StRS-38** — Externe Schnittstellen halten Partnergrenzen, Berechtigungen und Übertragungsregeln ein
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE] übernehmbar.
- **StRS-39** — KI-Assistent im ERP nur nach Bestätigung, ohne Bestätigung nur mit Sonderrecht; Anhangsgrenzen 20/40 MB
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll den Aufruf eines KI-Werkzeugs mit Unternehmensdaten nur nach ausdrücklicher Bestätigung des Anwenders ausführen; der Entfall der Bestätigung ist ausschließlich an das Sonderrecht UNRESTRICTED_ACCESS gebunden. Anhänge sind oberhalb der Grenze von 20 MB bzw. 40 MB abzulehnen.
- **StRS-40** — Persönlicher Arbeitsplatz zeigt nur zugangsberechtigte Module; Autostart ab fünf Modulen wird gewarnt
- Status: HYPOTHESE
- Offene Frage / Grund: Das System soll in der Modulzentrale nur Module darstellen, auf die der Benutzer nach Recht und Lizenz zugreifen kann; bei fünf oder mehr Autostart-Modulen soll vor der Aufnahme gewarnt werden.
- **StRS-41** — Prozesssteuerung: Workflows mit prozesstypischen Schritten, externe Zeitsteuerung, gültige Anbindung externer Vorgänge
- Status: HYPOTHESE
- Offene Frage / Grund: [SEKUNDÄR] Faktenbasis M041, M036, M070, M006 — Zitate inkl. HYPOTHESE-Kennzeichnung; Fundstellen nicht genannt.
## SyRS (19)
- **SyRS-5** — MSP-Rechte werden nur im Client durchgesetzt
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]** — ohne Serverdurchsetzung ist jede Nicht-UI-Schnittstelle eine Autorisierungslücke.
- **SyRS-6** — Pflichtfeld-Validierung (`IsMandatory`) nur im Client
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]**.
- **SyRS-19** — Vollständigkeit des Datensicherungs-Dumps (TelekomDiveProfile)
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]** — der Ausschluss ist in der Faktenbasis nur vermutet.
- **SyRS-21** — Mahnstufen L0–L3 ohne Überlauf und ohne Gebührenbuchung
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]** — Nicht-Vorhandensein von Überlaufschutz und Gebührenbuchung ist nicht an einer durchsetzenden Stelle belegt.
- **SyRS-24** — Vertragsenddatum-Aktualisierung ohne Rechteprüfung
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]** — die Soll-Forderung nach Rechteprüfung ist abgeleitet; der Ist-Zustand „keine Prüfung“ ist ein Negativbefund.
- **SyRS-27** — Abschluss-Toleranz ±0,10, Duplikatverhinderungsschlüssel und IBAN-Regel DE
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]**.
- **SyRS-33** — QM-Regeln ausschließlich im UI durchgesetzt
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]** — die serverseitige Lücke ist als Negativbefund nicht an einer Stelle belegt.
- **SyRS-36** — Filialbeschränkung `SHOW_HELPDESK_ONLY_OWN_BRANCH` wirkt nur im UI
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]** — serverseitige Abwesenheit ist ein Negativbefund.
- **SyRS-40** — Report-Löschung mit Kaskade ohne Rechteprüfung; ReportEngine ohne Rechtsprüfung
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]** für die Soll-Forderung; der Ist-Zustand ist über `null` bzw. fehlende Prüfung als Negativbefund belegt.
- **SyRS-41** — Auftragsabschluss nur bei vollständig erfassten Positionen; Modul ohne Rechtsprüfung
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]**.
- **SyRS-44** — KI-Nutzung erfordert Bestätigung, nicht aber ein Recht; Volumengrenzen 20/40 MB
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]**-Charakter, da eine Soll-Vorgabe fachlich offen ist.
- **SyRS-46** — Passwortwechsel des Webaccounts ohne Besitzerprüfung
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]** — die fehlende Prüfung ist ein Negativbefund ohne zitierte Gegenstelle.
- **SyRS-51** — Modul- und Funktionsstart nur bei Recht UND Lizenz (Client-Gate)
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE].
- **SyRS-52** — KI-Assistent: Werkzeugbestätigung, Volumengrenze 20/40 MB, fehlende Rechtebindung
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE].
- **SyRS-53** — Reportdaten-Löschung mit Kaskade ohne Recht; ReportEngine ohne Rechtsmenge
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE].
- **SyRS-54** — Workflow-Engine: Schritttyp nur per Whitelist je Prozesstyp; Laufstatistik ohne C#-Nutzung
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE].
- **SyRS-55** — Scheduler RiverBird: Schemapflicht ohne C#-Ausführung
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE].
- **SyRS-58** — Ticketauthentifizierung aus Query/Header, vertrauensvolle Client-IP und offener CORS-Umfang
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE: SignalR-Attributschutz, WCF-Whitelist und offene Portprüfung sind nur über Faktenbasis M065 abgedeckt; die zitierten Handler-/Host-Stellen tragen nur Ticket-, IP- und CORS-Anteile.]
- **SyRS-60** — Mandantentrennung über Verbindung/SessionFactory; Konnektorgateway ohne Mandantensteuerung
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE].
## SwRS (20)
- **SwRS-4** — Größen- und Zeichengrenzen der KI-Konversation in der Client-Schicht
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE: Belegtiefe laut Faktenbasis M002, nicht zeilenweise gegengeprüft; serverseitige Zweitprüfung nicht verifiziert.]
- **SwRS-5** — Terminbereichslogik der Schedule-Komponente
- Status: HYPOTHESE
- Offene Frage / Grund: Die Schedule-Komponente berechnet Sichtbarkeits- und Zuordnungsergebnisse aus den Termindaten innerhalb eines intern ermittelten Zeitfensters; die Regel ist ausschließlich in `ScheduleBL.cs` Zeilen 2379-2424 implementiert.
- **SwRS-6** — Persistenzregeln für Zahlungsverkehr und Buchungsimport/-export
- Status: HYPOTHESE
- Offene Frage / Grund: Die Zahlungsverkehrs-Komponente schreibt Transaktionen über den genannten Codepfad in die eigene Datenhaltung und koppelt Export/Import an die Tabelle `BookKeepingExport`; EDI-Versandparameter werden über `EDIGatewaySettingBL`/`EDIDispatcherBL` gelesen.
- **SwRS-7** — Werkzeuganbindung über ExternalTools-Datenhaltung
- Status: HYPOTHESE
- Offene Frage / Grund: Die Vorschaukomponente liest Werkzeugdefinitionen aus der Tabelle `ExternalTools` und übergibt Startparameter an den Client; eine eigene Werkzeughaltung außerhalb dieser Tabelle existiert nicht.
- **SwRS-10** — Pflichtfelder der Kampagnen-Persistenz
- Status: HYPOTHESE
- Offene Frage / Grund: Die Kampagnenkomponente erzeugt/prüft Kampagnensätze vor der Persistenz anhand der in Zeilen 30-47 hinterlegten Vorgaben; die数据库seitige Pflichtigkeit wird zusätzlich durch NOT-NULL-Constraints der Tabelle `Campaigns` erzwungen.
- **SwRS-13** — Rücksetzung (Revert) von Sprache und Währung in der Adresskomponente
- Status: HYPOTHESE
- Offene Frage / Grund: Beim Verwerfen oder Ändern von Kontoadressdaten setzt die Komponente Sprache und Währung auf den Ausgangswert (bzw. Kontovorgabe) zurück; die Persistenz erzwingt die Pflichtfelder der Kontotabelle.
- **SwRS-14** — Pflichtpersistenz beim Produktlebens Zyklus-Ende
- Status: HYPOTHESE
- Offene Frage / Grund: Die Client-Komponente bereitet die fürs Lebenszyklus-Ende nötigen Felder auf und übergibt sie an die Persistenz, die die Werte NOT NULL erzwingt.
- **SwRS-18** — Nicht unterstützte MwSt-Übernahme bei Gutschriften
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE]` bezüglich exakter Aufrufkette: Die抛出-Stelle wurde in diesem Lauf nicht aufgesucht.
- **SwRS-19** — Nullbare Preisspalten im Angebotskopf (Widerspruch zur Faktenbasis)
- Status: HYPOTHESE
- Offene Frage / Grund: Angebotskopf-Preissummen und Status sind softwareintern nullbar und haben weder NOT NULL noch DEFAULT 0; die Angebotskopfsummen können daher ohne Werte persistiert werden.
- **SwRS-21** — Weiche und harte Löschung von UI-Profilen
- Status: HYPOTHESE
- Offene Frage / Grund: Die Profilkomponente unterscheidet logische Löschung (Satz bleibt mit Löschkennzeichen erhalten) und physische Löschung; die Schema-Constraints begrenzen die Kombination zulässiger Profildaten.
- **SwRS-25** — Chat- und Tagesaufgabendatenhaltung
- Status: HYPOTHESE
- Offene Frage / Grund: Die Chatkomponente verwaltet Unterhaltungen und verknüpfte Tagespositionen über die eigene Datenhaltung; `MyDayWorkItems` liefert die Persistenzstruktur für Tagesaufgabensätze.
- **SwRS-26** — Persistenzregeln der Online-Banking-Umsätze
- Status: HYPOTHESE
- Offene Frage / Grund: Die Umsatztzkomponente legt Kontobewegungen über ihre eigene Tabellenstruktur ab, während die Zugangsdaten (HBCI/FinAPI) verschlüsselt in der Konfigurationshaltung liegen.
- **SwRS-30** — Lizenz-Gate der Produktionsmodule
- Status: HYPOTHESE
- Offene Frage / Grund: Die Produktionskomponenten prüfen vor der Fachaktion eine Lizenz (Einzellizenz oder Sammel-Lizenz „Centron") und verweigern sonst.
- **SwRS-31** — Preisimport in Projektpreise über die Import-ViewModel
- Status: HYPOTHESE
- Offene Frage / Grund: Die Importkomponente überträgt eingelesene Preise in die Projektpreishaltung und wendet dabei eigene Validierungs- und Rundungsregeln an; die Preisbildung folgt nicht dem Pfad `ReceiptPriceHelper.CalculateNetPrice`.
- **SwRS-33** — QM-Meldungsart als Enum, Anlagen grund dagegen nur UI-seitig
- Status: HYPOTHESE
- Offene Frage / Grund: Die Art der QM-Meldung wird softwareintern über einen Enum abgebildet und persistiert; der Anlagen grund wird ausschließlich in der Oberfläche geführt und ist nicht Bestandteil der durchgesetzten Datenhaltung.
- **SwRS-34** — Report-Strukturkaskade ohne fremdschlüsselgesicherte Kindobjekte
- Status: HYPOTHESE
- Offene Frage / Grund: Die Reportkomponente hält Eltern-/Kindbeziehungen durch eigenen Code kaskadiert; die Tabellen sichern diese Beziehung weder per FOREIGN KEY noch einheitlich per CHECK-Constraint, im Unterschied zu `ReportPrintOptions`.
- **SwRS-35** — RMA-Fallbehandlung in der Kundenbereichskomponente
- Status: HYPOTHESE
- Offene Frage / Grund: Die RMA-Komponente führt ihre Vorgangslogik in `RmaBL` und ist über das nullbare Kennzeichen `IstRMAFall` mit Helpdesk-Tickets verbunden.
- **SwRS-49** — Rechte-Cache ohne gefundenen Invalidierungspfad; Duplikate wandern in den gecachten Rechtsbestand
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE] zur Cache-Lebensdauer (TTL nicht geprüft). Ohne DISTINCT/UNIQUE enthält die Liste bei Doppelzuweisung dieselbe Recht-ID mehrfach.
- **SwRS-52** — Krypto-Schlüsselverwaltung mit eingebettetem Default-Schlüssel und aus demselben Hash abgeleitetem IV
- Status: HYPOTHESE
- Offene Frage / Grund: Wo der optionale Schlüssel weggelassen wird, werden Produktionsgeheimnisse mit einem im Quellcode eingebetteten, auslieferungsweit identischen Schlüssel verschlüsselt; Schlüssel und statische IV teilen Bytes, gleiche Klartexte ergeben identische Chiffretexte; Masterkey-Ablage verschlüsselt sich mit demselben Default; kein Rotationsmechanismus.
- **SwRS-54** — Anhängegrenzen der KI-Konversation als hartcodierte Konstanten (20 MB / 40 MB / 20000 Zeichen)
- Status: HYPOTHESE
- Offene Frage / Grund: [HYPOTHESE] Serverseite).
**Konsistenzvermerk:** Die Liste wurde aus dem zusammengeführten Bestand nach `Status: HYPOTHESE` und Inline-Markierung `[HYPOTHESE]` erzeugt.
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/StRS.md
+698
View File
@@ -0,0 +1,698 @@
ID: StRS-1
Titel: Rechteermittlung ausschließlich über Gruppenmitgliedschaft
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Benutzer (via Sachverwalter/Administrator), c-entron-ERP-System
Vorbedingung: Benutzer meldet sich an und ruft eine rechtegeschützte Funktion auf.
Fakt: „M001 Rechte NUR über Gruppen: AppRightsBL.HasUserRight Raw-SQL 'FROM dbo.Sichtrus INNER JOIN dbo.Sichmemb ON sm.Gruppe=st.Gruppe WHERE sm.Benutzer=:UserI3D'. [PRIMÄR] backend\Centron.BL\Administration\Rights\AppRightsBL.cs:644-664." (Sichtrus = Rechtestammdaten, Sichmemb = Gruppenmitgliedschaft Benutzer↔Gruppe)
Aussage: Das System soll einem Benutzer Fachrechte ausschließlich über die Gruppen zuordnen, denen er angehört; eine direkte Einzelrechtevergabe an Benutzer darf es fachlich nicht geben.
Ergebnis: Rechte sind über Gruppen administrative Einheit und Nachweisgröße; jede Rechtefrage ist auf eine Gruppenzuordnung rückführbar.
Belege: [PRIMÄR] backend\Centron.BL\Administration\Rights\AppRightsBL.cs:644-664 — „AppRightsBL.HasUserRight Raw-SQL 'FROM dbo.Sichtrus INNER JOIN dbo.Sichmemb ON sm.Gruppe=st.Gruppe WHERE sm.Benutzer=:UserI3D'" (M001), Einstufung wörtlich übernommen.
Prüfidee: Benutzer U erhält Recht R direkt ohne Gruppenmitgliedschaft → Rechteprüfung muss R verweigern; U wird Gruppe G mit R zugeordnet → Prüfung muss R gewähren.
Tracelinks: SyRS:Rechteprüfung, SwRS:Gruppen-Rechtemodell, StRS-4
Konsolidierung: Rechtegrundmodell gilt modulübergreifend für alle rechteabhängigen Aktionen (siehe StRS-4).
Übernahmewürdigkeit: übernehmen - hohe Priorität - PRIMÄR-Beleg mit SQL, Kernstück des Berechtigungskonzepts.
Status: belegt
ID: StRS-2
Titel: Lösch- und Änderungsschutz systemkritischer Objekte und der Rechteverwaltung
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Administrator, c-entron-ERP-System
Vorbedingung: Ein Benutzer versucht, die Gruppeverwaltung zu ändern, die Administratorengruppe zu löschen oder als „fix" gekennzeichnete Stammdaten (z. B. Kategorien) zu löschen.
Fakt: „M001 Gruppenverwaltung rechtepflichtig, Admin-Gruppe löschgeschützt, Admin-Rechte Whitelist. AppRightsBL.cs:355-396,714-759." und „M036 IsFix-Kategorien löschgeschützt".
Aussage: Das System soll den Zugriff auf die Gruppenverwaltung an ein besonderes Recht binden, die Administratorengruppe gegen Löschen schützen und nur eine whitelistbasierte Änderung von Admin-Rechten zulassen; als fix gekennzeichnete Kategorien (IsFix) sind gegen Löschen zu schützen.
Ergebnis: Selbstaussperrung und Rechteaushebelung über Löschen von Gruppen oder Festdaten sind fachlich ausgeschlossen.
Belege: [PRIMÄR] AppRightsBL.cs:355-396,714-759 — „M001 Gruppenverwaltung rechtepflichtig, Admin-Gruppe löschgeschützt, Admin-Rechte Whitelist" (Quelle nennt konkrete Code-Fundstelle, direkte Beobachtung; keine Hochstufung eines fremden Tags). [SEKUNDÄR] Faktenbasis M036 — „M036 IsFix-Kategorien löschgeschützt; RiverTicket ohne URL ungültig" (Fundstelle in Faktenbasis nicht genannt).
Prüfidee: Löschversuch auf Admin-Gruppe durch nicht-administrativen UND administrativen Benutzer → beide müssen abgewiesen werden; Löschversuch auf IsFix-Kategorie → Abweisung; Änderung eines Nicht-Whitelist-Admin-Rechts → Abweisung.
Tracelinks: SyRS:Rechteprüfung, SwRS:AdminSchutz, SwRS:IsFixLoeschschutz, StRS-1
Konsolidierung: Schutztyp „Löschschutz für Systemobjekte" über M001 und M036 zusammengefasst.
Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheitskritisch, Code-Fundstelle vorhanden.
Status: belegt
ID: StRS-3
Titel: Login nur innerhalb der lizenzierten Benutzerkapazität
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Benutzer, Lizenzverwaltung, c-entron-ERP-System
Vorbedingung: Lizenzmaximum der Installation ist bekannt; alle Lizenzzähler sind konsistent geführt.
Fakt: „M001 Login-Lizenzgrenze currentlyUsedLicenses>=max -> Fehler. LicenseManager.cs:258-302."
Aussage: Das System soll einen Anmeldeversuch ablehnen, wenn die Zahl der bereits genutzten Lizenzen das lizenzierte Maximum erreicht oder überschreitet, und dem Benutzer einenverständlichen Hinweis geben.
Ergebnis: Es arbeiten nie mehr simultane Benutzer im System, als lizenziert sind; Lizenzverstöße werden vermieden.
Belege: [PRIMÄR] LicenseManager.cs:258-302 — „M001 Login-Lizenzgrenze currentlyUsedLicenses>=max -> Fehler" (konkrete Code-Fundstelle, direkte Beobachtung).
Prüfidee: max=n, n Lizenzen belegt → (n+1)-ter Login muss mit Fehler abgewiesen werden; eine Lizenz wird frei → Login muss gelingen.
Tracelinks: SyRS:Loginablauf, SwRS:Lizenzgrenze, StRS-8
Konsolidierung: Lizenzthematik wird mit M024 (Produktion) und M005 (DATEV) in StRS-8 fortgeführt.
Übernahmewürdigkeit: übernehmen - hohe Priorität - abrechnungs-/lizenzrelevant mit PRIMÄR-Beleg.
Status: belegt
ID: StRS-4
Titel: Bearbeitung und Ausführung geschäftskritischer Aktionen sind rechtepflichtig
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Sachbearbeiter (Stamm-, Artikel-, Finanz-, Kommissionier-, Statistik-, Mail-Verwaltung), c-entron-ERP-System
Vorbedingung: Benutzer ist authentisiert; eine rechtegeschützte Aktion wird angestoßen.
Fakt: „M015 MSP-Bearbeitung braucht Rechte (nur Client)"; „M016 GUI-Profile global braucht EDIT_GLOBAL_PROFILES"; „M011 Account-Aktionen rechtepflichtig" (AccountBL.cs:1290-1370); „M007 Zahlungseingang löschen rechtepflichtig + Gegenbuchlung"; „M034 … Kommission rechtepflichtig"; „M038 Mailscanner Profil-Laden rechtepflichtig"; „M031 Statistikarten rechteabhängig".
Aussage: Das System soll die Bearbeitung von Masterdaten (MSP), globalen GUI-Profilen, Konten (Accounts), das Löschen von Zahlungseingängen, Kommissioniervorgänge, das Laden von Mailscanner-Profilen und die Nutzung von Statistikarten nur Benutzern mit dem jeweils zuständigen Fachrecht gestatten.
Ergebnis: Geschäftsvorfälle und sensitive Funktionen sind personenbezogen abgeschirmt; unberechtigte Änderung ist fachlich unmöglich.
Belege: [PRIMÄR] AccountBL.cs:1290-1370 — „M011 Account-Aktionen rechtepflichtig, Webaccount abgewiesen" (Code-Fundstelle). [SEKUNDÄR] Faktenbasis M015, M016, M007, M034, M038, M031 — Zitate wie im Fakt zitiert; Fundstellen dort nicht angegeben.
Prüfidee: Benutzer ohne EDIT_GLOBAL_PROFILES öffnet globales GUI-Profil → Lese-/Schreibzugriff muss verweigert werden; analog Benutzer ohne Kommissionsrecht → Kommissionieraktion wird abgewiesen; Benutzer ohne Kontorecht → Kontoaktion abgewiesen.
Tracelinks: SyRS:Rechteprüfung, SwRS:RechtepruefungServer, StRS-1, StRS-7
Konsolidierung: Einzelfakten M015, M016, M011, M007, M034, M038, M031 zu einer Rechtenachweis-Anforderung zusammengefasst; Durchsetzungsdefizite separiert in StRS-7.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Kern-Berechtigungsregel, breit belegt (ein PRIMÄR, sechs SEKUNDÄR).
Status: belegt
ID: StRS-5
Titel: Unberechtigte Änderungen von Sprache und Währung dürfen nicht wirkungslos überschrieben werden
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Account-Bearbeiter, c-entron-ERP-System
Vorbedingung: Benutzer ohne Sonderrecht für Sprache/Währung versucht, diese Felder eines Accounts zu ändern.
Fakt: „M011 Sprache/Währung ohne Sonderrecht lautlos revertiert. AccountAddressBL.cs:282-332."
Aussage: Das System soll Änderungen an Sprache und Währung eines Accounts ohne das Sonderrecht nicht akzeptieren; die Änderung ist sichtbar abzulehnen, statt den Wert lautlos auf den Ausgangswert zurückzusetzen.
Ergebnis: Der Bearbeiter erkennt die fehlende Berechtigung; es entstehen keine stillen Datenabweichungen.
Belege: [PRIMÄR] AccountAddressBL.cs:282-332 — „M011 Sprache/Währung ohne Sonderrecht lautlos revertiert" (Code-Fundstelle, direkte Beobachtung; Soll-Ziel = Korrektur des beobachteten Ist-Verhaltens).
Prüfidee: Benutzer ohne Sonderrecht setzt Sprache „DE" auf „EN" und speichert → System meldet Verweigerung UND gespeicherter Wert bleibt „DE".
Tracelinks: SyRS:Rechteprüfung, SwRS:FeldrechteAccount, StRS-4
Konsolidierung: Feldrechteregel steht isoliert; Verallgemeinerung in StRS-7.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Regel aus Ist-Verhalten abgeleitet, Soll-Formulierung (sichtbare Meldung) ist Interpretation des Befunds.
Status: belegt
ID: StRS-6
Titel: Webkonten sind von internen Kontooperationen ausgeschlossen
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: externer Kunde mit Webkonto, c-entron-ERP-System
Vorbedingung: Ein Webkonto versucht, interne Account-Aktionen (z. B. Anlage/Änderung) auszuführen.
Fakt: „M011 Account-Aktionen rechtepflichtig, Webaccount abgewiesen. AccountBL.cs:1290-1370."
Aussage: Das System soll Kontoaktionen über ein Webkonto grundsätzlich abweisen; interne Kontopflege bleibt internen, berechtigten Benutzern vorbehalten.
Ergebnis: Externe Portalnutzer können keine internen Geschäftskonten ändern; Trennung innen/außen ist durchgesetzt.
Belege: [PRIMÄR] AccountBL.cs:1290-1370 — „M011 Account-Aktionen rechtepflichtig, Webaccount abgewiesen" (Code-Fundstelle).
Prüfidee: Authentifiziertes Webkonto ruft Kontoaktion (z. B. Anlage/Änderung) auf → Aufruf muss mit Abweisung enden; interner Benutzer mit Recht → Erfolg.
Tracelinks: SyRS:Portalabgrenzung, SwRS:WebaccountSperre, StRS-12
Konsolidierung: Portalthemen werden fortgesetzt in StRS-12 bis StRS-15.
Übernahmewürdigkeit: übernehmen - hohe Priorität - klare PRIMÄR-belegte Abwehrregel.
Status: belegt
ID: StRS-7
Titel: Berechtigungs- und Plausibilitätsprüfungen müssen serverseitig und lückenlos greifen
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Angreiferischer Client, beliebiger Fachbenutzer, c-entron-ERP-System
Vorbedingung: Ein Client umgeht die Oberfläche oder ruft Funktionen ohne die maschinellen Prüfungen auf.
Fakt: „M015 MSP-Bearbeitung braucht Rechte (nur Client). Custom-Properties brauchen Name/Datentyp, Pflichtfelder nur Client."; „M027 QM-Beleggrund (nur UI)."; „M037 Telefonie Rechte nur Client(HYPOTHESE)."; „M022 Passwortmanager Rechte nur Client(HYPOTHESE)"; „M017 … Filialbeschränkung nur UI(HYPOTHESE)."; „M038 … Löschen ohne Recht."; „M019 Massenupdate … Modul rechtefrei."; „M028 Report-Löschung Kaskade ohne Recht(HYPOTHESE)."
Aussage: Das System soll jede Rechte- und Pflichtfeldprüfung, die eine Geschäftsregel durchsetzt, unabhängig vom Client auch auf dem Dienst/Geschäftslogik prüfen; kein Lösch-, Bearbeitungs- oder Modulzugriff darf ohne Rechtsprüfung ausführbar sein.
Ergebnis: UI-Kontrollen sind Bedienungshilfe, nicht Sicherheitsgrenze; Rechteumgehung über alternative Zugangswege ist ausgeschlossen.
Belege: [SEKUNDÄR] Faktenbasis M015, M027, M022, M038, M019, M037, M017, M028 — Zitate wörtlich wie im Fakt; Fundstellen/Einstufungen teils als (HYPOTHESE) gekennzeichnet.
Prüfidee: Client ohne die UI-Rufe Dienst zur Report-/Mailscanner-Profil-Löschung ohne Recht auf → Dienst muss verweigern; Custom-Property ohne Datentyp per direktem Aufruf → Ablehnung; Telefoniefunktion ohne Recht über Nicht-UI-Weg → Ablehnung.
Tracelinks: SyRS:Rechteprüfung, SwRS:ServerseitigeRechtepruefung, StRS-4, StRS-36
Konsolidierung: Befundfamilie „nur-Client/nur-UI/ohne-Recht" aus acht Modulfakten in einer Absicherungsanforderung gebündelt.
Übernahmewürdigkeit: übernehmen - hohe Priorität - für die Zielrichtung, Detail je Modul nachzureichen — daher risikorelevant ohne PRIMÄR.
Status: HYPOTHESE
ID: StRS-8
Titel: Modulzugang erfordert Recht und Lizenz zugleich
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Benutzer, Lizenzverwaltung, c-entron-ERP-System
Vorbedingung: Modul (z. B. Produktion, DATEV-Export) ist installiert; Modulrechte sind pflegt.
Fakt: „M051 Modulzugang=Recht UND Lizenz."; „M024 Produktion lizenzpflichtig."; „M005 … DATEV-Lizenz …".
Aussage: Das System soll ein Fachmodul nur öffnen, wenn der Benutzer sowohl das Modulrecht besitzt als auch die zugehörige Modul-Lizenz gültig ist; Fehlen einer Bedingung verschließt das Modul vollständig.
Ergebnis: Lizenz- und Rechteverwaltung wirken gemeinsam; nicht lizenzierte Module sind auch für berechtigte Benutzer nicht nutzbar.
Belege: [SEKUNDÄR] Faktenbasis M051, M024, M005 — „M051 Modulzugang=Recht UND Lizenz.", „M024 Produktion lizenzpflichtig.", „M005 SEPA-Betragslimit, DATEV-Lizenz, OPOS-Pflichtspalten, EDI-Routing je Anbieter."; Fundstellen nicht genannt.
Prüfidee: Recht ja, Lizenz nein → Modulzugriff verweigert; Lizenz ja, Recht nein → verweigert; beides ja → Zugriff gewährt.
Tracelinks: SyRS:Modulzugang, SwRS:Lizenzpruefung, SwRS:Modulrecht, StRS-1, StRS-3
Konsolidierung: Lizenzkopplung der Module Produktion (M024) und DATEV (M005) unter Regel M051 gefasst.
Übernahmewürdigkeit: übernehmen - hohe Priorität - fachlich, Beleglage dünn — Beleg nachreichen.
Status: HYPOTHESE
ID: StRS-9
Titel: Dienstzugriffe werden fehlgeschlossen authentifiziert; Header-Angaben sind keine Identitätsnachweise
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Dienstaufrufer (Ticket/Token), c-entron-ERP-System
Vorbedingung: Externer oder interner Aufrufer请求t eine Dienstfunktion ohne vollständige Legitimation.
Fakt: „M053 fail-closed Rechte, Ticket/Token-Auth."; „M065 Ticket aus Header/Query, IP aus Header."
Aussage: Das System soll jeden Dienstaufruf ohne gültiges Ticket oder Token ablehnen (Versagen führt zur Ablehnung, „fail-closed"); Tickets und Client-Identifikation dürfen nicht allein aus selbstgesetzten Header-/Query-Werten abgeleitet werden, ohne dass deren Herkunft geprüft wird.
Ergebnis: Kein Zugriff durch bloßes Behaupten von Zugangsdaten in übermittelbaren Feldern; fehlende Prüfung bedeutet keinen Zugriff.
Belege: [SEKUNDÄR] Faktenbasis M053, M065 — wörtlich zitiert; Fundstellen nicht angegeben.
Prüfidee: Aufruf ohne Ticket → Ablehnung; Aufruf mit manipuliertem Header „IP der internen Liste" ohne gültiges Ticket → Ablehnung; gültiges Ticket → Erfolg.
Tracelinks: SyRS:Dienstauthentifizierung, SwRS:FailClosedRechte, SwRS:TicketAuth, StRS-10
Konsolidierung: M053 und M065 zu einer Authentifizierungsregel verbunden.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Sicherheitsgrundsatz; konkrete Nachweise fehlen noch.
Status: HYPOTHESE
ID: StRS-10
Titel: Durchgehende Autorisierung aller REST-Dienste und der Zwei-Faktor-Endpunkte
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: REST-Client, Zwei-Faktor-Endpunkt-Nutzer, c-entron-ERP-System
Vorbedingung: Aufruf eines REST-Endpunkts, auch des Zwei-Faktor-Registrierungs-/Prüfabschnitts.
Fakt: „M064 REST global RequireAuthorization, 2FA anonym."
Aussage: Das System soll jeden REST-Endpunkt nur nach erfolgreicher Autorisierung beantworten; die Endpunkte des Zwei-Faktor-Verfahrens dürfen nicht ohne Authentifizierung erreichbar sein.
Ergebnis: Keine anonymous Datenabfrage über die Schnittstelle; das Zweite-Faktor-Verfahren ist selbst geschützt.
Belege: [SEKUNDÄR] Faktenbasis M064 — „M064 REST global RequireAuthorization, 2FA anonym."; Fundstelle nicht genannt.
Prüfidee: Unautorisierter HTTP-Aufruf eines Fach-Endpunkts und eines 2FA-Endpunkts (Token als Query-Parameter) → beide müssen ablehnen.
Tracelinks: SyRS:Autorisierungspflicht, SwRS:GlobalRequireAuthorization, StRS-13
Konsolidierung: REST- und 2FA-Endpunktschutz gemeinsam gefasst.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Befund „2FA anonym" ist sicherheitsrelevant.
Status: HYPOTHESE
ID: StRS-11
Titel: Verschlüsselung gespeicherter schutzbedürftiger Daten; kein einheitlicher Standard-Schlüssel
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Vertraulichkeit
Akteur: Datenschutzverantwortlicher, c-entron-ERP-System
Vorbedingung: Passwortmanager- und Zugangsdaten werden dauerhaft gespeichert.
Fakt: „M057 Krypto AES Default-Key."
Aussage: Das System soll schutzbedürftige gespeicherte Daten verschlüsseln (AES) und dabei mandantenspezifisch verwaltete Schlüssel verwenden; ein produktionsweiter Standard-/Auslieferungsschlüssel darf nicht die einzige Schlüsselmacht sein.
Ergebnis: Datenabfluss aus Speichern bleibt ohne mandanteneigenen Schlüssel unlesbar.
Belege: [SEKUNDÄR] Faktenbasis M057 — „M057 Krypto AES Default-Key."; Fundstelle nicht genannt.
Prüfidee: Prüfung der Schlüsselkonfiguration auf installationsindividuelle Schlüssel; Entschlüsselungsversuch gespeicherter Geheimnisse mit Werks-Default muss im Produktivbetrieb ausscheiden.
Tracelinks: SyRS:Datengeheimhaltung, SwRS:AESSchluesselverwaltung, StRS-24
Konsolidierung: Krypto-Befund dem Portal-/Passwortkomplex (StRS-12/13) zugeordnet.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Richtung klar, Soll-Verschärfung „kein Default-Key" ist aus Befund abgeleitet.
Status: HYPOTHESE
ID: StRS-12
Titel: Portal-Anmeldung prüft Kontostatus, Kennwort und Kundenaktivität; Portalrechte leiten sich aus Webrechten ab
Ebene: StRS
Typ: Akteursziel
Qualitätsmerkmal: Sicherheit
Akteur: Kunde (Portalbenutzer), c-entron-ERP-Portal
Vorbedingung: Kunde meldet sich mit Kennung und Kennwort am Kundenportal an.
Fakt: „M035 Portal-Login Prüft Status/Passwort(klartext-hash SHA1)/Kunde aktiv."; „WebRechte->Rollen."
Aussage: Das System soll die Portal-Anmeldung nur gewähren, wenn Portal-Kontostatus aktiv, Kennwort korrekt und Stammkunde aktiv ist, und die Portalfunktionen des Angemeldeten ausschließlich aus den zugewiesenen Webrechten als Rollen ableiten; die Kennwortablage ist gegen moderne, robuste Hashverfahren weiterzuentwickeln (SHA1 genügt nicht).
Ergebnis: Nur gültige Kunden mit gültigem Zugang erhalten rollengerechte Portsicht; veraltete Kennwort-Hashung ist absehbar beseitigt.
Belege: [SEKUNDÄR] Faktenbasis M035 — wörtlich wie im Fakt zitiert; Fundstelle nicht genannt.
Prüfidee: Kunde deaktiviert bei korrektem Kennwort → Login abgelehnt; Portal-Konto gesperrt → abgelehnt; aktiver Kunde → Erfolg; Webrecht W entfernt → zugehörige Portalfunktion nicht mehr erreichbar.
Tracelinks: SyRS:Portalzugang, SwRS:PortalLogin, SwRS:WebRollen, StRS-6, StRS-13
Konsolidierung: M035-Login, Kennwort-Hashbefund und Webrechte→Rollen in einer Portalzugangs-Anforderung.
Übernahmewürdigkeit: übernehmen - hohe Priorität - fachlich; SHA1-Korrekturbedarf aus Befund abgeleitet.
Status: HYPOTHESE
ID: StRS-13
Titel: Zwei-Faktor-Verfahren und Kennworthärte sind aktiv zu betreiben
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Portalbenutzer, WebAccount-Inhaber, Betrieb/Deployment, c-entron-ERP-System
Vorbedingung: Zwei-Faktor-Anmeldung ist installiert; Portal- oder WebAccount-Kennwörter werden gesetzt.
Fakt: „M035 2FA WebAccount Default aus."; „M061 TOTP ±4min."; „M022 … Portal-Kennwort nur min8."; „Deployment 2FA default aus, SA-Klartext." (TOTP = zeitbasiertes Einmalkennwort; SA = Systemadministrator-Konto)
Aussage: Das System soll für Portal-/WebAccount-Zugänge das Zwei-Faktor-Verfahren als Auslieferungszustand anbieten und dessen Aktivierung nicht dauerhaft unterdrücken; die TOTP-Gültigkeitstoleranz von ±4 Minuten ist fachlich zu begrenzen; Portal-Kennwörter sollen über eine Mindestlänge von 8 hinaus gehärtet werden; ein administratives Zugangskennwort darf nicht als Klartext im Deployment hinterlegt sein.
Ergebnis: Standardinstallation ist nicht per Voreinstellung ohne zweiten Faktor; keine Klartext-Passwörter in Konfiguration.
Belege: [SEKUNDÄR] Faktenbasis M035, M061, M022, Deployment-Absatz — Zitate wörtlich; Fundstellen nicht genannt.
Prüfidee: Frisch deployte Umgebung prüfen: 2FA aktivierbar, kein Klartext-SA-Kennwort in Konfiguration; TOTP-Token mit Zeitversatz >4 min → Ablehnung; Kennwort „12345678" gegen Härtungsregel prüfen.
Tracelinks: SyRS:Identitaetsstaerkung, SwRS:TOTPFenster, SwRS:Kennworthaertung, StRS-10, StRS-12
Konsolidierung: 2FA-Defaults (M035, Deployment), TOTP (M061), Kennworthärte (M022), SA-Klartext in einer Regel.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Soll-Verschärfungen (Härte, TOTP-Fenster) aus Befunden abgeleitet.
Status: HYPOTHESE
ID: StRS-14
Titel: Kennwortwechsel im Portal nur nach Besitzerprüfung
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Portalbenutzer, Angreifer, c-entron-ERP-Portal
Vorbedingung: Es liegt eine Anweisung zum Kennwortwechsel für ein Portal-Konto vor.
Fakt: „M035 Passwortwechsel ohne Besitzerprüfung(HYPOTHESE)."
Aussage: Das System soll den Wechsel eines Portal-Kennworts nur durchführen, wenn die Identität des Berechtigten (Besitzer oder verifizierter Bevollmächtigter) geprüft wurde; ein Kennworttausch allein mit Kenntnis der Kontokennung ist abzulehnen.
Ergebnis: Kontoübernahme durch Kennwortsetzen auf fremde Konten ist fachlich ausgeschlossen.
Belege: [SEKUNDÄR] Faktenbasis M035 — wörtlich inkl. Kennzeichnung (HYPOTHESE); Fundstelle nicht genannt.
Prüfidee: Unangemeldeter Aufruf „Kennwort für fremdes Portal-Konto setzen" → Abweisung; Besitzer nach durchlaufener Verifizierung → Erfolg.
Tracelinks: SyRS:Kennwortverwaltung, SwRS:Besitzerprüfung, StRS-12
Konsolidierung: Aus dem M035-Portalkomplex herausgelöst, weil eigenständige Prüfgröße.
Übernahmewürdigkeit: übernehmen - hohe Priorität - klarer Sicherheitszielzustand; Ist-Befund selbst hypothetisch.
Status: HYPOTHESE
ID: StRS-15
Titel: Dokumentenablage unterscheidet interne und öffentliche Dokumente mit getrennter Rechteprüfung
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Vertraulichkeit
Akteur: interner Benutzer, Portalbenutzer (WebAccount), c-entron-DMS
Vorbedingung: Dokument ist als intern oder öffentlich abgelegt; Nutzer will es öffnen.
Fakt: „M040 DMS intern/öffentlich Rechte-Trennung, Webaccount von Prüfung befreit." (DMS = Dokumentenmanagementsystem)
Aussage: Das System soll den Zugriff auf interne Dokumente nur mit dem internen Dokumentenrecht gewähren und öffentliche Dokumente ohne dieses Recht freigeben; Portalbenutzer (WebAccount) sind nicht von der Rechteprüfung befreit, sondern ausschließlich auf die öffentliche Sphäre zu beschränken.
Ergebnis: Keine interne Ablage für unberechtigte, auch nicht portalauthentifizierte, Nutzer sichtbar.
Belege: [SEKUNDÄR] Faktenbasis M040 — wörtlich zitiert; Fundstelle nicht genannt.
Prüfidee: Portalbenutzer ruft internes Dokument auf → Ablehnung; Benutzer ohne DMS-Recht → Ablehnung; öffentliches Dokument → Einsicht für beide.
Tracelinks: SyRS:Dokumentenschutz, SwRS:DmsRechtepruefung, StRS-6, StRS-9
Konsolidierung: Trennung intern/öffentlich und Portalbefreiung in einer Anforderung.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Befund „von Prüfung befreit" ist ein akuter Schutzverstoß.
Status: HYPOTHESE
ID: StRS-16
Titel: Zahlungseingänge nur mit Recht und gegen ausgleichende Gegenbuchung stornierbar
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Debitorenbuchhaltung, Wirtschaftsprüfer, c-entron-ERP-System
Vorbedingung: Ein bereits gebuchter Zahlungseingang soll gelöscht werden.
Fakt: „M007 Zahlungseingang löschen rechtepflichtig + Gegenbuchlung."
Aussage: Das System soll das Löschen eines Zahlungseingangs nur berechtigten Buchhaltungsbenutzern gestatten und dabei automatisch eine Gegenbuchung erzeugen, die die Finanzwirksamkeit des ursprünglichen Zugangs vollständig ausgleicht (keine stille Löschung).
Ergebnis: Zahlungsmittelverkehr bleibt vollständig und nachvollziehbar; unberechtigte Korrektur ist ausgeschlossen.
Belege: [SEKUNDÄR] Faktenbasis M007 — wörtlich zitiert; Fundstelle nicht genannt.
Prüfidee: Benutzer ohne Recht löscht Zahlungseingang → abgelehnt; Berechtigter löscht → Gegenbuchung mit Betragsgleichheit existiert und Saldo bleibt unverändert.
Tracelinks: SyRS:Zahlungsverkehr, SwRS:Gegenbuchung, SwRS:LoeschrechtZahlung, StRS-4, StRS-17
Konsolidierung: Finanzkorrekturregeln zusammen mit StRS-17 (Mahnwesen).
Übernahmewürdigkeit: übernehmen - hohe Priorität - Abrechnungs-/Prüfungsthema; Beleg muss nachgereicht werden.
Status: HYPOTHESE
ID: StRS-17
Titel: Mahnwesen folgt den Stufen L0–L3; Kassensystem-Mahnrucke setzen Mahnrecht voraus
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Korrektheit
Akteur: Mahnwesen-Sachbearbeiter, Kassensystem (OPOS), c-entron-ERP-System
Vorbedingung: Offener Posten (Opos) überschreitet seine Fälligkeit. (OPOS = Kassensystem/Point of Sale)
Fakt: „M007 Mahnwesen Stufen L0-L3 (Gebühren nicht belegt=HYPOTHESE). Opos braucht Mahnrecht."
Aussage: Das System soll überfällige Posten über die Stufen L0 bis L3 des Mahnprozesses führen und dem Zahler je Stufe die vorgesehenen Mahnschritte zuweisen; das Anstoßen von Mahnungen aus dem Kassensystem (Opos) soll nur mit Mahnrecht möglich sein. Die Gebührenhöhe je Stufe ist fachlich zu bestimmen (bisher unbelegt).
Ergebnis: Einheitliche, nachvollziehbare Debitorenmahnung; unberechtigte Mahnauslösung aus dem Kassensystem verhindert.
Belege: [SEKUNDÄR] Faktenbasis M007 — „Mahnwesen Stufen L0-L3 (Gebühren nicht belegt=HYPOTHESE). Opos braucht Mahnrecht."; Fundstelle nicht genannt.
Prüfidee: Überfälliger Posten durchläuft Stufen L0→L3 (je Fälligkeitstag-Fenster eine Stufe); Kassennutzer ohne Mahnrecht → Mahnauslösung abgelehnt.
Tracelinks: SyRS:Mahnprozess, SwRS:Mahnstufen, SwRS:MahnrechtOpos, StRS-16
Konsolidierung: Mahnwesenregel separat von Zahlungslöschung (StRS-16), beide Finanzbereich.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Gebühren fehlen, Stufenmodell unklar definiert.
Status: HYPOTHESE
ID: StRS-18
Titel: Banktransaktionen gelten bei Kleinbetragsdifferenz als ausgeglichen; IBAN deutscher Konten hat Mindestlänge 22
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Korrektheit
Akteur: Zahllauf-Sachbearbeiter, c-entron-ERP-System
Vorbedingung: Banktransaktion wird importiert/abgeglichen; Eingabe einer IBAN.
Fakt: „M021 Banktransaktion completed bei ±0,10; IBAN DE>=22."
Aussage: Das System soll eine Banktransaktion als ausgeglichen („completed") abschließen, wenn die Betragsdifferenz zum Buchungsbestand ±0,10 nicht übersteigt; IBANen deutscher Banken (Kürzel DE) sollen mindestens 22 Zeichen tragen, sonst ist die Eingabe zurückzuweisen.
Ergebnis: Bagatellrundungen blockieren den Zahlungsabschluss nicht; fehlerhafte IBANen werden vor der Buchung abgefangen.
Belege: [SEKUNDÄR] Faktenbasis M021 — wörtlich zitiert; Fundstelle nicht genannt.
Prüfidee: Differenz 0,10 → Status completed; 0,11 → nicht completed; IBAN „DE" mit 21 Zeichen → Ablehnung, mit 22 → Annahme.
Tracelinks: SyRS:Zahlungsabgleich, SwRS:Bankausgleich, SwRS:IbanPruefung, StRS-19
Konsolidierung: Zahlungseingangsregeln zusammen mit StRS-19.
Übernahmewürdigkeit: übernehmen - hohe Priorität - präzise prüfbare Grenzwerte; Beleg nachreichen.
Status: HYPOTHESE
ID: StRS-19
Titel: SEPA-Zahlungen halten das vereinbarte Betragslimit ein
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Korrektheit
Akteur: Zahlstellen-Sachbearbeiter, Bank, c-entron-ERP-System
Vorbedingung: Ein SEPA-Überweisungsauftrag wird erzeugt. (SEPA = einheitlicher Euro-Zahlungsverkehrsraum)
Fakt: „M005 SEPA-Betragslimit, DATEV-Lizenz, OPOS-Pflichtspalten, EDI-Routing je Anbieter."
Aussage: Das System soll einen SEPA-Auftrag nur erstellen und zur Bank weiterleiten, dessen Betrag innerhalb des konfigurierten Betragslimits liegt; darüber hinausgehende Beträge sind zu sperren und dem Sachbearbeiter zu melden.
Ergebnis: Falschbeträge und Betrugsausreißer verlassen das Haus nicht ungeprüft.
Belege: [SEKUNDÄR] Faktenbasis M005 — wörtlich zitiert; Fundstelle nicht genannt.
Prüfidee: SEPA-Auftrag mit Betrag = Limit → zulässig; Limit + 0,01 → Ablehnung mit Meldung.
Tracelinks: SyRS:Zahlungsverkehr, SwRS:SepaLimit, StRS-18
Konsolidierung: SEPA-Limit aus M005 gelöst; DATEV→StRS-8, OPOS-Pflichtspalten→StRS-24, EDI→StRS-38.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Abrechnungsrisiko; Konkreter Limitwert und Beleg fehlen.
Status: HYPOTHESE
ID: StRS-20
Titel: Vertragsende aus Laufzeit ableiten und Kündigungsdatum kappen
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Korrektheit
Akteur: Vertrags-Sachbearbeiter, c-entron-ERP-System
Vorbedingung: Vertrag mit Laufzeit und Kündigungsdatum ist erfasst.
Fakt: „M010 Vertragsende-Ableitung+Kündigungsdatum-Kappung."
Aussage: Das System soll das Vertragsende aus der vereinbarten Laufzeit ableiten und ein erklärtes Kündigungsdatum auf das höchstens zulässige Vertragsende kappen, sodass kein Vertragsverhältnis über sein Ende hinaus fortbesteht.
Ergebnis: Vertragslaufzeiten stimmen mit Abrechnungszeiträumen überein; keine abrechnungsbegründende Nachlaufzeit.
Belege: [SEKUNDÄR] Faktenbasis M010 — wörtlich zitiert; Fundstelle nicht genannt.
Prüfidee: Kündigung nach Vertragsende hinterlegt → wirksames Ende = Vertragsende; Kündigung vor Ende → Ende = Kündigungstermin.
Tracelinks: SyRS:Vertragslaufzeit, SwRS:VertragsendeAbleitung, StRS-21
Konsolidierung: M010-Zeitthemen: Zeitfassung→StRS-21, Klickzähler→StRS-36.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Regel benannt, Ableitungslogik unbestimmt.
Status: HYPOTHESE
ID: StRS-21
Titel: Erfassungs- und Abrechnungsschutz für geleistete Zeiten
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Mitarbeiter mit Zeiterfassung, Abrechnungsverantwortlicher, c-entron-ERP-System
Vorbedingung: Zeitdaten sind erfasst; ein Teil ist bereits fakturiert bzw. Belege sind gesperrt.
Fakt: „M010 Zeiterfassung braucht EDIT_TIME, rechnungs-/auftragsgesperrt."; „M017 … fakturierte Zeiten unveränderlich …"
Aussage: Das System soll die Erfassung und Änderung von Zeitdaten nur mit dem Recht EDIT_TIME gestatten; einmal fakturierte Zeiten dürfen nachträglich nicht mehr verändert werden, und für rechnungs- bzw. auftragsgesperrte Objekte ist die Zeitänderung zu sperren.
Ergebnis: Vergütungs- und Rechnungsbasis bleibt manipulationssicher.
Belege: [SEKUNDÄR] Faktenbasis M010, M017 — Zitate wörtlich; Fundstellen nicht genannt.
Prüfidee: Benutzer ohne EDIT_TIME erfasst Zeit → Ablehnung; fakturierte Zeit auf anderen Betrag ändern → Ablehnung; Zeit auf auftragsgesperrtem Auftrag → Ablehnung.
Tracelinks: SyRS:Zeiterfassung, SwRS:EditTime, SwRS:FakturierteZeitenUnveraenderlich, StRS-19, StRS-23
Konsolidierung: EDIT_TIME, Sperrzustände und Fakturierungsunveränderlichkeit zu einer Abrechnungsschutz-Regel gebündelt.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Abrechnungsintegrität; Beleg nachreichen.
Status: HYPOTHESE
ID: StRS-22
Titel: Belegkette Angebot → Auftrag → Lieferschein → Rechnung folgt Vorwärtsregeln
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Konsistenz
Akteur: Vertriebs-Sachbearbeiter, c-entron-ERP-System
Vorbedingung: Ein Vertriebsbeleg der Kette liegt vor.
Fakt: „M014 Belegkette Angebot->Auftrag->Lieferschein->Rechnung (Forward-Regeln)."
Aussage: Das System soll Folgebelege nur entlang der Kette Angebot → Auftrag → Lieferschein → Rechnung erzeugen lassen und dabei die jeweiligen Vorwärtsregeln (zulässige Nachfolgebelege, Mengenübernahme) einhalten.
Ergebnis: Durchgängiger Nachweis Warenwirtschaftlicher Vorgänge ohne Sprünge in der Kette.
Belege: [SEKUNDÄR] Faktenbasis M014 — „M014 Belegkette Angebot->Auftrag->Lieferschein->Rechnung (Forward-Regeln)."; Fundstelle nicht genannt.
Prüfidee: Rechnung direkt auf Angebot ohne Auftrag/Lieferschein → Ablehnung; Angebot → Auftrag → Lieferschein → Rechnung → Erfolg mit Mengen-/Preiskonsistenz.
Tracelinks: SyRS:Belegkette, SwRS:ForwardRegeln, StRS-23
Konsolidierung: Kettenregel getrennt von Preisbildung (StRS-23).
Übernahmewürdigkeit: übernehmen - hohe Priorität; Detailregeln („Forward") sind zu präzisieren.
Status: HYPOTHESE
ID: StRS-23
Titel: Einheitliche Preisbildung: Netto/USt, Mengenpreis, Projektpreis, kundenspezifische Abschläge, Einstandspreis
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Korrektheit
Akteur: Vertrieb, Einkauf, c-entron-ERP-System
Vorbedingung: Preisermittlung für Beleg, Projekt oder Kunde. (UST = Umsatzsteuer; EK = Einstandspreis; FromAmount = Mengenstaffel-Grenze)
Fakt: „M014 Netto/UST-Preisbildung fachlich."; „M034 Mengenpreis = höchste Stufe FromAmount<=Menge; EK gleitender Durchschnitt."; „M025 Projektpreis*Faktor, Herstellercode eindeutig."; „M033 TelekomDive-Profil (Mandant,Rabatt/UST)."
Aussage: Das System soll Bruchteile eines Preises konsistent bilden: Nettobetrag und Umsatzsteuer getrennt ausgewiesen; im Mengenpreis die höchste Stufe mit FromAmount ≤ bestellter Menge; Projektpreise als Grundpreis mal vereinbartem Faktor; Kunden-/Partnerprofile (z. B. TelekomDive) mit Rabatt- und USt-Vorgabe je Mandant; der Einstandspreis als gleitender Durchschnitt geführt.
Ergebnis: Gleiche Ware, Menge und Kunde ergeben überall im Haus denselben Preis.
Belege: [SEKUNDÄR] Faktenbasis M014, M034, M025, M033 — Zitate wörtlich; Fundstellen nicht genannt.
Prüfidee: Staffeln 10/50/100: Menge 60 → Stufe 50; Projekt 100×Faktor 1,2 → 120; Kunde mit Rabattprofil → um Profil reduzierter Preis mit korrekter USt-Zerlegung.
Tracelinks: SyRS:Preisfindung, SwRS:Mengenpreisstufe, SwRS:EkGleitend, SwRS:ProjektpreisFaktor, StRS-22
Konsolidierung: Preisbildungsregeln aus fünf Modulfakten (inkl. M033-Mandant/Rabatt/UST) zusammengefasst.
Übernahmewürdigkeit: übernehmen - hohe Priorität - wirtschaftlich zentral; Belege je Teilregel nachreichen.
Status: HYPOTHESE
ID: StRS-24
Titel: Pflichtfeldregeln für erfassungs- und übertragungspflichtige Angaben
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Vollständigkeit
Akteur: Sachbearbeiter aller Fachbereiche, Schnittstellenpartner, c-entron-ERP-System
Vorbedingung: Datensatz wird angelegt oder Übertragung wird vorbereitet.
Fakt: „M015 Custom-Properties brauchen Name/Datentyp, Pflichtfelder nur Client."; „M013 Name+Art Pflicht, Nummer Auto."; „M008 Kampagne Name Pflicht …"; „M020 … MyDay Pflichtfelder."; „M023 Pflicht nur Artikelstamm settingsgesteuert." (ArticleBL.cs:1444); „M005 … OPOS-Pflichtspalten …"; „M042-M050 … EbInterface UStID-Pflicht" (UStID = Umsatzsteuer-Identifikationsnummer)
Aussage: Das System soll das Speichern oder Übertragen nur gestatten, wenn die fachlichen Pflichtangaben je Objekt vollständig sind: Custom-Property mit Name und Datentyp; Projekt mit Name und Art (Nummer automatisch vergeben); Kampagne mit Namen; MyDay-Satz mit seinen Pflichtfeldern; Artikelstamm-pflichtige Felder nach Einstellung; OPOS-Beleg Pflichtspalten; EbInterface-Nachricht mit UStID.
Ergebnis: Vorgänge sind entscheidungsfähig und übertragungsfähig; unvollständige Datensätze erreichen Folgeprozesse nicht.
Belege: [PRIMÄR] ArticleBL.cs:1444 — „M023 … Pflicht nur Artikelstamm settingsgesteuert" (Code-Fundstelle). [SEKUNDÄR] Faktenbasis M015, M013, M008, M020, M005, M042-M050 — Zitate wörtlich; keine Fundstellen.
Prüfidee: Je Objektart einen Datensatz ohne ein Pflichtfeld anlegen → Speichern/Übertragung muss abgewiesen werden und benennen, welches Feld fehlt.
Tracelinks: SyRS:Erfassungsqualitaet, SwRS:Pflichtfeldpruefung, StRS-7 (Durchsetzung), StRS-38 (UStID)
Konsolidierung: Sieben Pflichtfeld-Befunde über Module hinweg zu einer Konsolidierungsanforderung verbunden.
Übernahmewürdigkeit: übernehmen - hohe Priorität - ein PRIMÄR-Anker, breite Sekundärfaktenlage.
Status: belegt
ID: StRS-25
Titel: Zahler eines Kontos ist der Kostenträger; Kostenstelle nur noch als Historie
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Konsistenz
Akteur: Anlagenbuchhalter/Controlling, c-entron-ERP-System
Vorbedingung: Artikel-/Kontodaten mit Zahler und Kostenstelle werden bearbeitet.
Fakt: „M023 Zahler=Kostenträger, Kostenstelle logisch gelöscht; Pflicht nur Artikelstamm settingsgesteuert. ArticleBL.cs:1444." (Kostenträger = rechenungsrelevante Kostensammelstelle)
Aussage: Das System soll den Zahler eines Kontos fachlich als Kostenträger führen; das Attribut „Kostenstelle" ist aus der aktiven Bearbeitung genommen (logisch gelöscht) und steht nur noch als Historie zur Verfügung.
Ergebnis: Eine eindeutige Kostenträger-Sicht verhindert doppelte/widersprüchliche Kostenzuordnung.
Belege: [PRIMÄR] ArticleBL.cs:1444 — „M023 Zahler=Kostenträger, Kostenstelle logisch gelöscht; Pflicht nur Artikelstamm settingsgesteuert." (Code-Fundstelle).
Prüfidee: Neuanlage: Feld „Kostenstelle" nicht wählbar; Zahler wird als Kostenträger verwendet; Alt-Datensatz zeigt historische Kostenstelle schreibgeschützt.
Tracelinks: SyRS:Kostenrechnung, SwRS:KostentraegerZuordnung, StRS-24
Konsolidierung: M023-Pflichtaspekt nach StRS-24 ausgelagert; Fachregel hier.
Übernahmewürdigkeit: übernehmen - hohe Priorität - PRIMÄR belegt.
Status: belegt
ID: StRS-26
Titel: Lagerumbuchung erfordert Artikel, Mitarbeiter, Von- und Nach-Lager
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Korrektheit
Akteur: Lagermitarbeiter, c-entron-ERP-System
Vorbedingung: Ware zwischen zwei Lagern wird bewegt.
Fakt: „M018 Lagerumbuchung braucht Artikel/Mitarbeiter/Von/Nach-Lager, Default-Lager."
Aussage: Das System soll eine Lagerumbuchung nur mit vollständig erfasstem Artikel, verantwortlichem Mitarbeiter, Ausgangs- und Ziellager annehmen; fehlt eine Vorgabe, gilt das gepflegte Default-Lager als Vorschlag.
Ergebnis: Bestandsbewegungen sind lückenlos einem Bestand, Ort und Verursacher zuordenbar.
Belege: [SEKUNDÄR] Faktenbasis M018 — wörtlich zitiert; Fundstelle nicht genannt.
Prüfidee: Umbuchung ohne Nach-Lager → Ablehnung; ohne Wahl mit Default-Lager hinterlegt → Vorschlag = Default, Erfolg.
Tracelinks: SyRS:Bestandsfuehrung, SwRS:Umbuchungspruefung, StRS-27
Konsolidierung: Lagerregeln mit StRS-27 und StRS-28 fachlich verwandt, operativ getrennt.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Regel klar, Beleg fehlt.
Status: belegt
ID: StRS-27
Titel: Bestellvorschlag bei Unterschreiten des Mindestbestands
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Einkauf, c-entron-ERP-System
Vorbedingung: freier Bestand und offene Bestellungen sind bekannt.
Fakt: „M026 Bestellvorschlag bei Bestand<Mindestbestand+Offen."
Aussage: Das System soll einen Bestellvorschlag erzeugen, sobald der verfügbare Bestand kleiner ist als der Mindestbestand zuzüglich bereits offener Bestellungen.
Ergebnis: Wiedervorfüllung erfolgt rechtzeitig und ohne Doppelbestellung.
Belege: [SEKUNDÄR] Faktenbasis M026 — wörtlich zitiert; Fundstelle nicht genannt.
Prüfidee: Bestand 4, Mindest 5, offen 1 → Schwelle 6 → Vorschlag erzeugt; Bestand 6, offen 0 → kein Vorschlag.
Tracelinks: SyRS:Dispositionsprozess, SwRS:Bestellvorschlagsregel, StRS-26
Konsolidierung: Disposition eigenständig; Preisthemen in StRS-23.
Übernahmewürdigkeit: übernehmen - hohe Priorität - präzise Formel; Beleg nachreichen.
Status: belegt
ID: StRS-28
Titel: Inventur per Barcode nur für Bestände in den Status 1, 2 und 8
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Korrektheit
Akteur: Lager-Inventurteam, c-entron-ERP-System
Vorbedingung: Inventur wird per Barcode-Erfassung durchgeführt.
Fakt: „M034 … Bestand Barcode Status 1,2,8."
Aussage: Das System soll bei der Barcode-Inventur nur Bestandsbuchungen der Status 1, 2 und 8 zählen; Bestände anderer Status bleiben unberücksichtigt.
Ergebnis: Inventurergebnis enthält nur zählfähige Bestände; Systembestand und Zählergebnis bleiben vergleichbar.
Belege: [SEKUNDÄR] Faktenbasis M034 — wörtlich zitiert; Fundstelle nicht genannt.
Prüfidee: Testbestand je Status einscannen: Status 1,2,8 zählen; Status 3 und 0 zählen nicht.
Tracelinks: SyRS:Inventurprozess, SwRS:BarcodeStatusfilter, StRS-26
Konsolidierung: Lagerkomplex mit StRS-26/27.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Statusbedeutung (1,2,8) fachlich noch zu benennen.
Status: belegt
ID: StRS-29
Titel: RMA-Vorgang nur mit Helpdesk-Bezug
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Konsistenz
Akteur: Service-/Retouren-Mitarbeiter, c-entron-ERP-System
Vorbedingung: Kunde zeigt eine Reklamation an. (RMA = Return-Material-Authorization, Warenrücksendegenehmigung)
Fakt: „M029 RMA braucht Helpdesk-Bezug."
Aussage: Das System soll eine RMA nur anlegen und bearbeiten, wenn ein Helpdesk-Vorgang zugeordnet ist; eine Rücksendung ohne dokumentierten Servicefall ist fachlich nicht zulässig.
Ergebnis: Jede Retoure ist auf eine Serviceursache rückführbar.
Belege: [SEKUNDÄR] Faktenbasis M029 — wörtlich zitiert; Fundstelle nicht genannt.
Prüfidee: RMA ohne Helpdesk-Vorgang anlegen → Ablehnung; mit gültiger Referenz → Erfolg; Referenz löschen während offener RMA → Warnung/Verweis.
Tracelinks: SyRS:Retourenprozess, SwRS:RmaHelpdeskbezug, StRS-31
Konsolidierung: Servicethema, Fortsetzung in StRS-31.
Übernahmewürdigkeit: übernehmen - hohe Priorität; Beleg fehlt.
Status: belegt
ID: StRS-30
Titel: Produktlebensdauer im PLM aus Start und Familienlebensdauer ableiten
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Konsistenz
Akteur: Produktmanagement, c-entron-ERP-System
Vorbedingung: Produktfamilie mit Lebensdauer und Produktstartdatum gepflegt. (PLM = Produktlebenszyklus-Management)
Fakt: „M012 PLM Ende=Start+Familienlebensdauer."
Aussage: Das System soll das Lebensende eines PLM-Produkts automatisch aus Startdatum plus Familienlebensdauer berechnen; eine manuelle Abweichung soll fachlich nicht zulässig sein.
Ergebnis: Auslaufplanungen sind innerhalb einer Familie einheitlich.
Belege: [SEKUNDÄR] Faktenbasis M012 — wörtlich zitiert; Fundstelle nicht genannt.
Prüfidee: Familie mit Lebensdauer 36 Monate, Start 01.01.2024 → Ende 01.01.2027; manueller Ende-Wert → nicht änderbar.
Tracelinks: SyRS:Produktlebenszyklus, SwRS:PlmEndeAbleitung, StRS-20
Konsolidierung: Ableitungsregel analog StRS-20, Domäne PLM.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Ableitung klar, Änderungs-/Komplettierbarkeit unklar.
Status: belegt
ID: StRS-31
Titel: Helpdesk-Eskalation nach Wartezeit, Wochenendsteuerung und Wiederaufnahme; Hilfezeiten als Termine nutzbar
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Helpdesk-Mitarbeiter, Helpdesk-Leiter, c-entron-ERP-System
Vorbedingung: Helpdesk-Vorgang ist offen; Terminwiedervorlage (DueTo) gepflegt.
Fakt: „M017 Helpdesk Eskalation 0-3 wartezeit-/wochenendegesteuert; DueTo-Änderung setzt Eskalation 0; fakturierte Zeiten unveränderlich; Filialbeschränkung nur UI(HYPOTHESE)."; „M003 Helpdesk-Zeit->Termin einstellbar."
Aussage: Das System soll den Helpdesk-Eskalationsstand in den Stufen 0–3 wartezeit- und wochenendegesteuert führen; jede Änderung der Terminwiedervorlage (DueTo) soll die Eskalation auf 0 zurücksetzen; Hilfe-/Servicezeiten sollen optional als Termine erzeugt werden; eine Beschränkung auf Filialdaten soll auch außerhalb der Oberfläche gelten. [HYPOTHESE: Die serverseitige Filialbeschränkung und die Eskalationsschwellen sind nur über die Faktenbasis M017 belegt; eine durchsetzende Fundstelle fehlt.]
Ergebnis: Vorgänge eskalieren planmäßig, Pausen werden berücksichtigt, Termine und Hilfezeiten bleiben synchron.
Belege: [SEKUNDÄR] Faktenbasis M017, M003 — Zitate wörtlich inkl. HYPOTHESE-Kennzeichnung; Fundstellen nicht genannt.
Prüfidee: Offener Vorgang ohne Bearbeitung über Stufenschwellen → Eskalation steigt 0→3; Wochenendzeit erhöht nicht; DueTo-Änderung → zurück auf 0; Helpdesk-Zeit erzeugt Termin gemäß Einstellung.
Tracelinks: SyRS:Helpdeskprozess, SwRS:Eskalationsstufen, SwRS:DueToReset, StRS-21, StRS-29, StRS-7 (Filialbeschränkung)
Konsolidierung: M017 und M003 zu Serviceprozess; Fakturierungsschutz nach StRS-21 ausgelagert.
Übernahmewürdigkeit: übernehmen - mittlere Priorität; Eskalationsstufen-Schwellen unbelegt.
Status: HYPOTHESE
ID: StRS-32
Titel: CRM-Projekte: Pflichtangaben, automatische Nummer, Löschung nur ohne Referenz
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Konsistenz
Akteur: Vertriebsmitarbeiter, c-entron-ERP-System
Vorbedingung: CRM-Projekt (Kundenprojektauftrag im CRM) wird angelegt oder gelöscht.
Fakt: „M013 CRM-Projekt Status/Art nur löschbar ohne Referenz; Name+Art Pflicht, Nummer Auto."
Aussage: Das System soll CRM-Projekte nur mit Name und Art anlegen, die Nummer selbst vergeben, und die Löschung von Status- oder Art-Definition nur zulassen, solange keine referenzierenden Vorgänge existieren.
Ergebnis: Belegbare Historie: keine Projektart verschwindet unter laufenden Vorgängen.
Belege: [SEKUNDÄR] Faktenbasis M013 — wörtlich zitiert; Fundstelle nicht genannt; Pflichtfeld-Aspekt durch StRS-24 konsolidiert.
Prüfidee: Art X von einem Beleg referenziert, X löschen → Ablehnung; Art ohne Referenz löschen → Erfolg; Projekt ohne Name → abgewiesen.
Tracelinks: SyRS:Projektverwaltung, SwRS:Loeschreferenzpruefung, StRS-24
Konsolidierung: Pflichtfelder in StRS-24 konsolidiert; Refenzzählung eigenständig.
Übernahmewürdigkeit: übernehmen - hohe Priorität; Beleg fehlt.
Status: belegt
ID: StRS-33
Titel: Kampagnenführung: Terminplausibilität, dokumentierte Ansprechpartnerentscheidung, Mailingversion
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Vollständigkeit
Akteur: Marketingleiter, c-entron-ERP-System
Vorbedingung: Kampagne wird geplant bzw. Ansprechpartner-Ergebnis festgehalten.
Fakt: „M008 Kampagne Name Pflicht, Ende>=Start; Ansprechpartner-Entscheidung braucht Text+zugeordneten Ansprechpartner."; „M030 Mailings Version2."
Aussage: Das System soll Kampagnen nur mit gültigem Namen und Enddatum nicht vor Startdatum führen; eine Ansprechpartner-Entscheidung erfordert eine Begründung im Text und den zugeordneten Ansprechpartner; Mailingversände erfolgen mit der aktuellen Mailingversion 2.
Ergebnis: Kampagnenzeitraum valide; Marketingentscheidungen nachvollziehbar dokumentiert.
Belege: [SEKUNDÄR] Faktenbasis M008, M030 — Zitate wörtlich; Fundstellen nicht genannt; „Name Pflicht" konsolidiert in StRS-24.
Prüfidee: Ende < Start → Speichern abgelehnt; Entscheidung ohne Text oder ohne Ansprechpartner → abgelehnt; beide gefüllt → Erfolg.
Tracelinks: SyRS:Kampagnenprozess, SwRS:Kampagnenplausibilitaet, SwRS:MailingVersion2, StRS-24
Konsolidierung: M008 und M030 zum Marketing-Komplex verbunden.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - „Version2" fachliche Tragweite unklar.
Status: belegt
ID: StRS-34
Titel: Kommunikationsinhalte nur durch Berechtigte und nur im eigenen Namen
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Vertraulichkeit
Akteur: Chat-Mitglied, MyDay-Nutzer, Social-Media-Betreuer, c-entron-ERP-System
Vorbedingung: Chat-Nachricht wird gesendet; sozialer Kommentar geschrieben.
Fakt: „M020 Chat nur Mitglied/Autor, max250. MyDay Pflichtfelder."; „M039 SocialMedia nur eigener Kommentar im SP." (SP = gespeicherte Prozedur)
Aussage: Das System soll das Verfassen von Chat-Nachrichten nur Gruppenmitgliedern bzw. Autoren gestatten und die Nachricht auf 250 Zeichen begrenzen; in Social-Media-Auswertung/-Pflege soll ein Bearbeiter nur eigene Kommentare ändern oder löschen dürfen. [HYPOTHESE: Die Mitglieder-/Autorschafts-Regel ist nur über Faktenbasis M020/M039 belegt; eine durchsetzende Stelle für alle Kommunikationspfade ist nicht benannt.]
Ergebnis: Interne Kommunikation ist teilnehmerbegrenzt; fremde Kommentare bleiben unverändert.
Belege: [SEKUNDÄR] Faktenbasis M020, M039 — Zitate wörtlich; Fundstellen nicht genannt; MyDay-Pflichtfelder → StRS-24.
Prüfidee: Nicht-Mitglied sendet Chat-Nachricht → abgelehnt; 251 Zeichen → abgelehnt; Benutzer ändert Kommentar eines anderen → abgelehnt.
Tracelinks: SyRS:Kommunikation, SwRS:ChatTeilnahmepruefung, SwRS:EigenerKommentar, StRS-1
Konsolidierung: M020 (Chat) und M039 zur Kommunikations-Zugriffsregel.
Übernahmewürdigkeit: übernehmen - hohe Priorität; Beleg fehlt.
Status: HYPOTHESE
ID: StRS-35
Titel: Umfragen folgen einer definierten Statusmaschine
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Konsistenz
Akteur: Umfrage-Verantwortlicher, Teilnehmer, c-entron-ERP-System
Vorbedingung: Umfrage durchläuft Lebenszyklus (z. B. Entwurf → aktiv → abgeschlossen).
Fakt: „M032 Umfrage Statusmaschine."
Aussage: Das System soll Umfrage-Statusübergänge ausschließlich entlang der definierten Statusmaschine erlauben; nicht erlaubte Sprünge und Änderungen an abgeschlossenen Umfragen sind abzulehnen.
Ergebnis: Umfrageergebnisse sind abhängig vom Status geschützt und auswertbar.
Belege: [SEKUNDÄR] Faktenbasis M032 — wörtlich zitiert; Fundstelle nicht genannt; Statusliste selbst unbelegt.
Prüfidee: Nach Zustandsliste: erlaubter Übergang → Erfolg; verbotener Sprung „abgeschlossen → aktiv" → Ablehnung.
Tracelinks: SyRS:Umfrageprozess, SwRS:UmfrageStatusmaschine, StRS-41
Konsolidierung: Statusmaschinen-Denkmuster wie StRS-41 (Workflow), Domäne eigenständig.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Zustandsmengen fehlen in Faktenbasis.
Status: belegt
ID: StRS-36
Titel: Auswertungsobjekte: Reports nur mit Recht löschbar, Klickzahlen nur monoton
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Sicherheit
Akteur: Auswertungsverantwortlicher, c-entron-ERP-System
Vorbedingung: Report mit Folgeobjekten soll gelöscht werden; Klickzähler wird erhöht.
Fakt: „M028 Report-Löschung Kaskade ohne Recht(HYPOTHESE)."; „M010 Click-Zähler monoton."
Aussage: Das System soll die Reportlöschung samt Kaskade nur mit dem zuständigen Recht zulassen; der Klickzähler soll ausschließlich monoton wachsen (kein Zählen von Löschungen oder Zurücksetzen).
Ergebnis: Auswertungslandschaft ist nicht unbeaufsichtigt auslöschbar; Reichweitenstatistik manipulationsarm.
Belege: [SEKUNDÄR] Faktenbasis M028 (HYPOTHESE), M010 — wörtlich zitiert; Fundstellen nicht genannt.
Prüfidee: Benutzer ohne Report-Recht löst Report-Kaskade aus → nichts wird gelöscht, Meldung; Zähler um -1 geändert → abgelehnt, +1 → Erfolg.
Tracelinks: SyRS:Auswertungsverwaltung, SwRS:ReportLoeschrecht, SwRS:Klickzaehler, StRS-7, StRS-4
Konsolidierung: Befunde M028 und M010(Click) zu Auswertungsverwaltung zusammengefasst.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Löschkaskade ohne Recht ist akuter Befund.
Status: HYPOTHESE
ID: StRS-37
Titel: Massenaktualisierung nur bei vollständiger Bearbeitung; Modul ist zu sichern
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Vollständigkeit
Akteur: Fachadministrator, c-entron-ERP-System
Vorbedingung: Massenänderung über alle Datensätze eines Moduls wird beauftragt.
Fakt: „M019 Massenupdate nur bei Vollständigkeit erledigt; Modul rechtefrei."
Aussage: Das System soll eine Massenaktualisierung nur dann als erledigt abschließen, wenn alle betroffenen Datensätze bearbeitet wurden; das Massenupdate-Modul soll zusätzlich an ein Fachrecht gebunden werden (bisher rechtefrei).
Ergebnis: Keine teildurchgeführten Serienänderungen; nur Berechtigte können Massenkorrekturen anstoßen.
Belege: [SEKUNDÄR] Faktenbasis M019 — wörtlich zitiert; Fundstelle nicht genannt; Rechtefreiheit zusätzlich in StRS-7.
Prüfidee: Abbruch nach 50 von 100 Sätzen → Status bleibt „unvollständig" und meldet Restliste; Benutzer ohne Recht öffnet Modul → Ablehnung.
Tracelinks: SyRS:Massenpflege, SwRS:MengenupdateVollstaendigkeit, StRS-7, StRS-4
Konsolidierung: M019 vollständig hier; Durchsetzungsaspekt querverwiesen.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Soll-Recht ist abgeleitete Zielkorrektur des Befunds.
Status: HYPOTHESE
ID: StRS-38
Titel: Externe Schnittstellen halten Partnergrenzen, Berechtigungen und Übertragungsregeln ein
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Systemintegration, Partner (EbInterface, GLS, Shipcloud, Cop, Egis, FinAPI, Icecat, ITscope, docuFORM), c-entron-ERP-System
Vorbedingung: Datenaustausch mit externem Partner steht an.
Fakt: „M042-M050 Schnittstellen: EbInterface UStID-Pflicht; GLS max50Ref/30Pakete; Shipcloud Basic; Cop limit100; Egis Platzhalter-Block; FinAPI Token; Icecat null; ITscope max50; docuFORM SETTINGS-Recht+PKCE." und „M005 SEPA-Betragslimit, DATEV-Lizenz, OPOS-Pflichtspalten, EDI-Routing je Anbieter." (UStID = Umsatzsteuer-Identifikationsnummer; EDI = elektronischer Datenaustausch; PKCE = Sicherungsverfahren für Autorisierungscodes)
Aussage: Das System soll je Partner dessen fachliche Grenzen und Bedingungen durchsetzen: EbInterface nur mit UStID; GLS maximal 50 Referenzen und 30 Pakete je Sendung; Cop maximal 100 Datensätze je Abruf; ITscope maximal 50; Egis sendet nicht mit ungelösten Platzhaltern; FinAPI nur mit gültigem Token; Icecat-Antworten ohne Inhalt werden als Null behandelt; docuFORM-Aufruf erfordert das SETTINGS-Recht und PKCE-gesicherte Autorisierung; EDI-Nachrichten werden je Anbieter weitergeleitet; der Shipcloud-Funktionsumfang „Basic" ist einzuhalten.
Ergebnis: Partner empfangen keine grenzüberschreitenden oder unberechtigten Aufträge; Fehlerbilder werden je Partner fachlich korrekt unterschieden.
Belege: [SEKUNDÄR] Faktenbasis M042–M050 — Aufzählung der Partnergrenzen (Fundstellen in Faktenbasis nicht genannt). [SEKUNDÄR] Faktenbasis M005 — „EDI-Routing je Anbieter" (SEPA→StRS-19, DATEV→StRS-8, OPOS→StRS-24).
Prüfidee: GLS-Sendung mit 51 Referenzen oder 31 Paketen → Ablehnung; docuFORM-Aufruf ohne SETTINGS-Recht → Ablehnung; Egis-Nachricht mit ungelöstem Platzhalter → Blockierung; Cop-Abruf mit 101 Datensätzen → Begrenzung auf 100; FinAPI-Aufruf mit abgelaufenem Token → Ablehnung; EbInterface-Datensatz ohne UStID → Rückweisung.
Tracelinks: SyRS:API-Perimeter (SyRS-57), SwRS:Partnerlimits, StRS-9, StRS-24
Konsolidierung: Neun Einzel-Schnittstellenbefunde (M042–M050) plus EDI-Routing (M005) zu einer Verbundanforderung; UStID-Pflicht → StRS-24, Tokens/Tickets → StRS-9.
Übernahmewürdigkeit: übernehmen - hohe Priorität - präzise Grenzwerte pro Partner; mangels PRIMÄR-Fundstellen nur mit [HYPOTHESE] übernehmbar.
Status: HYPOTHESE
ID: StRS-39
Titel: KI-Assistent im ERP nur nach Bestätigung, ohne Bestätigung nur mit Sonderrecht; Anhangsgrenzen 20/40 MB
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Vertraulichkeit
Akteur: Fachanwender mit KI-Werkzeugen, Datenschutzverantwortlicher, c-entron-ERP-System
Vorbedingung: Ein Anwender beauftragt ein KI-Werkzeug mit Unternehmensdaten oder Anhängen.
Fakt: „M002 KI-Tool Bestätigung außer UNRESTRICTED_ACCESS, Anhänge 20/40MB."
Aussage: Das System soll den Aufruf eines KI-Werkzeugs mit Unternehmensdaten nur nach ausdrücklicher Bestätigung des Anwenders ausführen; der Entfall der Bestätigung ist ausschließlich an das Sonderrecht UNRESTRICTED_ACCESS gebunden. Anhänge sind oberhalb der Grenze von 20 MB bzw. 40 MB abzulehnen.
Ergebnis: Kein Datenabfluss an KI-Dienste ohne bewusste Freigabe; Ausnahmen sind personenbezogen über ein Sonderrecht gesteuert.
Belege: [SEKUNDÄR] Faktenbasis M002 — „KI Bestätigung außer Recht, 20/40MB"; Fundstelle in Faktenbasis nicht genannt.
Prüfidee: Anwender ohne UNRESTRICTED_ACCESS startet KI-Werkzeug → Bestätigungsdialog, Abbruch ohne Versand; Anwender mit Recht → ohne Dialog; Anhang 21 MB bei 20-MB-Grenze → Ablehnung.
Tracelinks: SyRS:KI-Assistent (SyRS-52), SwRS:KI-Grenzwerte (SwRS-54), StRS-1, StRS-4
Konsolidierung: Bestätigungsfreiung ist Instanz des Gruppenrechtsmodells (StRS-1) und der Rechtepflichtigkeit (StRS-4).
Übernahmewürdigkeit: übernehmen - hohe Priorität - fachlich (Datenschutz); Zuordnung 20 vs. 40 MB und Rechtsherleitung zu klären.
Status: HYPOTHESE
ID: StRS-40
Titel: Persönlicher Arbeitsplatz zeigt nur zugangsberechtigte Module; Autostart ab fünf Modulen wird gewarnt
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Benutzerfreundlichkeit
Akteur: Benutzer beim Systemstart, c-entron-ERP-System
Vorbedingung: Benutzer hat persönlichen Arbeitsplatz (Modulzentrale, Modulautostart).
Fakt: „Modulzentrale filtert darstellerisch, Autostart-Warnung ab 5 Modulen." — in der Faktenbasis (M001–M070) existiert hierfür kein Modul-Fakt mit Fundstelle; Punkt als Lücke gemeldet.
Aussage: Das System soll in der Modulzentrale nur Module darstellen, auf die der Benutzer nach Recht und Lizenz zugreifen kann; bei fünf oder mehr Autostart-Modulen soll vor der Aufnahme gewarnt werden.
Ergebnis: Der Startbildschirm ist rechts- und lizenzkonsistent; unkontrollierter Modulstart bleibt sichtbar.
Belege: [SEKUNDÄR] Auftraggeber-Auftrag — „Modulzentrale filtert darstellerisch, Autostart-Warnung ab 5 Modulen." ohne Fundstelle; Faktenlücke gemeldet.
Prüfidee: Benutzer ohne Recht/Lizenz auf Modul X → X erscheint nicht in der Modulzentrale; Autostart mit 5 Modulen → Warnung; 4 Module → keine Warnung.
Tracelinks: SyRS:Modul- und Funktionsstart (SyRS-51), StRS-8, StRS-3, StRS-1
Konsolidierung: Verknüpft mit Modulzugangsregel StRS-8 und Lizenzgrenze StRS-3.
Übernahmewürdigkeit: übernehmen - niedrige Priorität - bis mittel — allein auf Auftraggeber-Behauptung gestützt; Faktenfundstelle nachreichen.
Status: HYPOTHESE
ID: StRS-41
Titel: Prozesssteuerung: Workflows mit prozesstypischen Schritten, externe Zeitsteuerung, gültige Anbindung externer Vorgänge
Ebene: StRS
Typ: Fachregel
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Prozessverantwortlicher, externer Zeitplaner (Scheduler), externes Werkzeug, c-entron-ERP-System
Vorbedingung: Workflow eines Prozesstyps ist gestartet; zeitgesteuerte Aufgaben und externe Anbindungsvorgänge sind hinterlegt.
Fakt: „M041 Workflow prozesstypische Schritte; RunningWorkFlows ohne Code(HYPOTHESE)."; „M036 RiverTicket ohne URL ungültig."; „M070 Scheduler extern(HYPOTHESE)."; „M006 externe Tools ExitCode0."
Aussage: Das System soll in einem Workflow nur die für den Prozesstyp typischen Schrittarten zulassen; zeitgesteuerte Abläufe werden durch einen externen Zeitplaner angestoßen (Annahme); ein RiverTicket ohne Ziel-URL ist ungültig; ein externes Werkzeug gilt nur bei Exit-Code 0 als erfolgreich.
Ergebnis: Prozessabläufe sind typrein und gegen scheinbar erfolgreiche, tatsächlich fehlgeschlagene Ausführung geschützt.
Belege: [SEKUNDÄR] Faktenbasis M041, M036, M070, M006 — Zitate inkl. HYPOTHESE-Kennzeichnung; Fundstellen nicht genannt.
Prüfidee: Workflow Typ T → nur Schrittarten aus Typdefinition wählbar; RiverTicket ohne URL → ungültig; externes Werkzeug Exit-Code 1 → Fehlersignal, 0 → Erfolg.
Tracelinks: SyRS:Workflow-Engine (SyRS-54), SyRS:Scheduler (SyRS-55), StRS-2, StRS-35, StRS-38
Konsolidierung: Prozess-/Automatisierungsthemen aus M041, M036 (RiverTicket), M070, M006 gebündelt; Statusmaschinen-Muster → StRS-35.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Abarbeitung laufender Instanzen und externer Scheduler ausdrücklich unbelegt.
Status: HYPOTHESE
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/SwRS.md
+968
View File
@@ -0,0 +1,968 @@
ID: SwRS-1
Titel: Softwareinterne Rechteauflösung über gecachte Roh-SQL-Menge (Sichtrus/Sichmemb)
Ebene: SwRS
Typ: Constraint-/Implementierungsanforderung (Berechtigungskomponente)
Qualitätsmerkmal: Richtigkeit, Konsistenz, Nachvollziehbarkeit (ISO 29148: Correctness, Consistency)
Akteur: `AppRightsBL` (BL-Schicht) im Auftrag jeder aufrufenden Komponente
Vorbedingung: Benutzersitzung mit `appUserI3D`; Session-Cache verfügbar
Fakt: `HasUserRight` lädt die Rechte über `GetAllAppRightsFromUser`, dessen SQL wörtlich lautet: `"SELECT st.Recht AS ID FROM dbo.Sichtrus st INNER JOIN dbo.Sichmemb sm ON sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D"` (AppRightsBL.cs:653-656); Ergebnis wird unter dem Schlüssel `$"AllRightsFromAppUser{appUserI3D}"` gecacht und per `rights.Contains(rightID)` geprüft (AppRightsBL.cs:644-649).
Aussage: Die Rechtekomponente löst Benutzerrechte ausschließlich über diese JOIN-Roh-SQL auf; die Zugriffsstrukturen `Sichtrus`/`Sichmemb` führen nur einen PK auf `I3D` und kein UNIQUE auf `(Gruppe, Recht)` bzw. `(Benutzer, Gruppe)`, sodassJOIN-Duplikate in der Ergebnisliste sichtbar bleiben; eine Entduplizierung (DISTINCT/Distinct) erfolgt nicht.
Ergebnis: Die Ja/Nein-Antwort von `HasUserRight` bleibt trotz Duplikaten korrekt (Mengenprüfung), ändert sich aber erst nach Cache-Neubindung; Doppelzuweisungen werden softwareintern nicht erkannt oder gemeldet.
Belege: PRIMÄR – durchsetzende Stelle: `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `HasUserRight`/`GetAllAppRightsFromUser`, Zeilen 644-664, SQL wörtlich zitiert (im Lauf gegen den Quellcode gespiegelt). PRIMÄR – Schema: `SSMS_DB_SCHEMA.sql` `CREATE TABLE [dbo].[Sichmemb]` (Zeile 51211), `CREATE TABLE [dbo].[Sichtrus]` (Zeile 51267) ohne UNIQUE-Constraint auf den Beziehungsspalten.
Prüfidee: Duplikatzeile in `Sichmemb` (gleicher Benutzer/Gruppe) und `Sichtrus` einfügen, `HasUserRight` vor/nach Cache-Invalidierung aufrufen; erwarten: korrektes Ergebnis, aber Duplikate in der geladenen Liste.
Tracelinks: SyRS:Berechtigungsprüfung, StRS:Rechteverwaltung; SwRS-2, SwRS-3, SwRS-43
Konsolidierung: Kandidat – dieselbe fachliche Zuordnung „Benutzer ↔ Gruppe ↔ Recht" existiert zweiteilig: einmal Raw-SQL in `AppRightsBL.GetAllAppRightsFromUser` (Zeilen 653-656), einmal ORM-seitig über `AppUserMaps` („Groups via sichmemb", Faktenbasis M001); im Zielsystem auf einen Leseweg führen. Zweitens: parallele Rechteauflösung für Webkonten, `GetAllWebRightsFromWebAccount` (`SELECT WebRightsI3D AS ID FROM WebAccountsRights WHERE WebAccountsI3D = :WebAccountI3D`, AppRightsBL.cs:681-683).
Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheitsrelevant, durchsetzende Stelle belegt
Status: belegt
ID: SwRS-2
Titel: Hartcodierte Admin-Zuweisungs-Whitelist (38 Rechte-I3Ds)
Ebene: SwRS
Typ: Implementierungs-/Constraintanforderung (Berechtigung)
Qualitätsmerkmal: Wartbarkeit, Sicherheit
Akteur: `AppRightsBL` bei Rechtezuweisung durch Administratoren
Vorbedingung: Aufrufer aus der Verwaltungsmaske „Rechte zuweisen"
Fakt: `GetAssignableAdminRightI3Ds` liefert eine fest verdrahtete `List<int>` mit Rechte-I3Ds (u. a. `20400149, 20400150, … 20400223`) und wird an zwei Stellen als „changeableRights" verwendet (AppRightsBL.cs:714 ff., Aufrufe Zeile 268 und 286).
Aussage: Nur die per Whitelist genannten Rechte dürfen der Administratorgruppe zugewiesen/entzogen werden; die Liste liegt als Quellcode-Konstante vor, nicht als Datenhaltung oder Constraint.
Ergebnis: Neue oder umbenannte Rechte sind ohne Quellcode-Änderung administrativ nicht zuweisbar; Verhalten ist reproduzierbar, aber nur über Deployments änderbar.
Belege: PRIMÄR – `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `private IList<int> GetAssignableAdminRightI3Ds`, Zeile 714 ff. mit Kommentar `//Gets the right i3ds which can assigned and removed from admin group`; Aufrufe Zeilen 268, 286 (Wortlaut im Lauf geprüft).
Prüfidee: Rechte-I3D außerhalb der Liste per Admin-UI zuweisen wollen → Ablehnung erwarten; Whitelist-Eintrag entfernen und erneut prüfen.
Tracelinks: SyRS:Rechteverwaltung-UI, StRS:Rechteverwaltung; SwRS-1
Konsolidierung: kein Fall – die Whitelist ist die einzige Zuweisungsfilter-Implementierung; Berührung zu SwRS-1 ist Ebenen-/Modulzusammenhang, nicht Doppelimplementierung.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-3
Titel: ORM-Mapping des Kontokennworts auf die Altsäule `BenutzerInfo2`
Ebene: SwRS
Typ: Datenanforderung (Entität-/Spaltenm mapping)
Qualitätsmerkmal: Konsistenz, Nachvollziehbarkeit
Akteur: NHibernate-Mapping `AppUserMaps`
Vorbedingung: Persistenz einer `AppUser`-Instanz
Fakt: `this.Map(appUser => appUser.Password).Column("BenutzerInfo2");` (AppUserMaps.cs:24); Kennwortregeln mappen auf `KennAendNachTagen`, `LetzKennAend`, `KennLaenMin` (Zeilen 27, 31, 32); `AuthentificationKind` ist mit `.CustomType<AuthentificationKind>.Not.Nullable` gemappt (Zeile 37).
Aussage: Das Domänenattribut `Password` wird softwareintern in die historisch benannte Spalte `BenutzerInfo2` geschrieben und ist im Mapping nicht als `Not.Nullable` erklärt; `AuthentificationKind` dagegen ist zwingend.
Ergebnis: Ein Kontodatensatz kann ohne Kennwertwert persistiert werden, muss aber einen Authentifizierungsmodus tragen; Namensdivergenz Domäne/Spalte bleibt für Auswertung und Migration wirksam.
Belege: PRIMÄR – `src/backend/Centron.DAO/Mappings/Administration/AppUserMaps.cs`, Zeilen 24, 27, 31, 32, 37 (Wortlaut im Lauf geprüft). KONTEXT – Faktenbasis M001 für die Aussage `TwoFactorAuthKey … NOT NULL` (im Schema-Dump dieses Laufs nicht separath verifiziert).
Prüfidee: `AppUser` ohne `Password` speichern und Schema-/NOT-NULL-Verhalten prüfen; `AuthentificationKind` leer lassen und Mapping-Verstoß erwarten.
Tracelinks: SyRS:Benutzerverwaltung, StRS:Rechteverwaltung; SwRS-1, SwRS-42
Konsolidierung: Kandidat (fachliche Doppelführung im selben Gegenstand „Kennwort eines Kontos"): `AppUser.Password → BenutzerInfo2` (AppUserMaps.cs:24) gegenüber `WebAccount.Password` mit SHA1-Prüfung (WebAccountBL.cs:56-61) und `MailScannerProfile.Password` (verschlüsselt) / `MailPassword` (unverschlüsselt); drei Kennwort-Haltungen für dasselbe Konzept.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-4
Titel: Größen- und Zeichengrenzen der KI-Konversation in der Client-Schicht
Ebene: SwRS
Typ: Funktions-/Restriktionsanforderung (interne Berechnungsvorschrift)
Qualitätsmerkmal: Zuverlässigkeit, Ressourcenverhalten
Akteur: `ConversationViewModelBase`, `Coordinator` (KI-Modul)
Vorbedingung: Benutzer hängt Dateien an einen KI-Chat an bzw. sendet Text
Fakt: Faktenbasis M002 verortet die Steuerung in `Coordinator` Zeile 230 und Zeile 411 sowie die Grenzlogik in `ConversationViewModelBase` Zeilen 40-575 mit den Werten 20 MB / 40 MB und 20000 Zeichen.
Aussage: Die Client-Komponente prüft Anhangsgrößen gegen eine Einzelgrenze von 20 MB und eine Summengrenze von 40 MB sowie den Textumfang gegen 20 000 Zeichen, bevor eine Anfrage an den `Coordinator` übergeben wird. [HYPOTHESE: Belegtiefe laut Faktenbasis M002, nicht zeilenweise gegengeprüft; serverseitige Zweitprüfung nicht verifiziert.]
[HYPOTHESE] (Belegtiefe laut Faktenbasis, nicht zeilenweise gegengeprüft).
Ergebnis: Zu große Anhänge bzw. zu lange Texte werden clientseitig abgewiesen, bevor Serverressourcen belegt werden; die Prüfung ist UI-seitig, nicht persistierend erzwungen.
Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Zeilenangaben wörtlich übernommen; im Lauf nicht Zeile für Zeile gegengeprüft) – `Coordinator.cs:230`, `Coordinator.cs:411`, `ConversationViewModelBase.cs:40-575` (M002).
Prüfidee: Dateien mit 21 MB (einzeln) und 3×15 MB (Summe) sowie Text mit 20 001 Zeichen anhängen; Ablehnung und Meldung erwarten; Serverseitige Zweitprüfung als abweichend melden, falls nicht vorhanden.
Tracelinks: SyRS:KI-Assistent, StRS:KI-Nutzung
Konsolidierung: Kandidat: SwRS-54 (dieselben KI-Grenzwerte 20/40 MB/20000 Zeichen in der Client-Schicht); bei Übernahme mit SwRS-54 verschmelzen.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Zahlenwerte vor Übernahme gegen Quellcode verifizieren
Status: HYPOTHESE
ID: SwRS-5
Titel: Terminbereichslogik der Schedule-Komponente
Ebene: SwRS
Typ: Funktionsanforderung (interne Algorithmen)
Qualitätsmerkmal: Richtigkeit, Vollständigkeit
Akteur: `ScheduleBL`
Vorbedingung: Abfrage von Terminen für einen Anzeigezeitraum
Fakt: Faktenbasis M003 benennt `ScheduleBL.cs` Zeilen 2379-2424 als durchsetzende Stelle der Zeitbereichsbetrachtung.
Aussage: Die Schedule-Komponente berechnet Sichtbarkeits- und Zuordnungsergebnisse aus den Termindaten innerhalb eines intern ermittelten Zeitfensters; die Regel ist ausschließlich in `ScheduleBL.cs` Zeilen 2379-2424 implementiert.
Ergebnis: Termine außerhalb des intern bestimmten Fensters erscheinen in den betroffenen Sichten nicht; eine zweite, abweichende Bereichsberechnung existiert in der Component-Schicht nicht.
Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis; Zeilenangabe wörtlich übernommen, nicht gegengeprüft) – `ScheduleBL.cs:2379-2424` (M003).
Prüfidee: Termine an Fensteranfang/-ende sowie exakt auf der Grenze anlegen und Sichtbarkeit vergleichen.
Tracelinks: SyRS:Kalender-Sichten, StRS:Terminverwaltung; SwRS-25
Konsolidierung: kein Fall – Bereichslogik nur an einer Stelle belegt.
Übernahmewürdigkeit: übernehmen - niedrige Priorität - Formel/Fenstergrenzen fehlen in der Faktenbasis
Status: HYPOTHESE
ID: SwRS-6
Titel: Persistenzregeln für Zahlungsverkehr und Buchungsimport/-export
Ebene: SwRS
Typ: Daten-/Constraintanforderung
Qualitätsmerkmal: Richtigkeit, Konsistenz (Abrechnung)
Akteur: `PaymentTransactionBL`, `BookKeepingExportBL`, `BookKeepingImportBL`
Vorbedingung: Zahlungen werden erzeugt, Export/Import angestoßen
Fakt: Faktenbasis M005 verweist auf `PaymentTransactionBL` Zeilen 93-288, `BookKeepingExportBL` Zeile 1560, `BookKeepingImportBL` Zeilen 127-149 sowie Schema `BookKeepingExport`, `SupplierEdiConfigurations`; zusätzlich `EDIGatewaySettingBL`/`EDIDispatcherBL` Zeilen 56-109.
Aussage: Die Zahlungsverkehrs-Komponente schreibt Transaktionen über den genannten Codepfad in die eigene Datenhaltung und koppelt Export/Import an die Tabelle `BookKeepingExport`; EDI-Versandparameter werden über `EDIGatewaySettingBL`/`EDIDispatcherBL` gelesen.
Ergebnis: Zahlungsdatensätze, Exportaufträge und EDI-Konfiguration hängen softwareintern über die benannten Schlüssel zusammen; Brüche der Kette bleiben ohne Constraint (siehe ).
Belege: PRIMÄR (durchsetzende Stellen laut Faktenbasis, Referenzen wörtlich übernommen; nicht Zeile für Zeile gegengeprüft) – `PaymentTransactionBL.cs:93-288`, `BookKeepingExportBL.cs:1560`, `BookKeepingImportBL.cs:127-149`, `EDIDispatcherBL.cs:56-109`, Schema `BookKeepingExport`/`SupplierEdiConfigurations` (M005).
Prüfidee: Zahlung erzeugen → Export anstoßen → Import rückspielen; Referenzielle Integrität und Wiederholbarkeit (Idempotenz) prüfen.
Tracelinks: SyRS:Zahlungsverkehr, SyRS:Buchungsuebergabe, StRS:Abrechnung; SwRS-8, SwRS-26, SwRS-51
Konsolidierung: Kandidat – Zahlungen werden an zwei getrennten Stellen modelliert: `PaymentTransactionBL` (Zahlungsverkehr) und `PaymentsBL`/`IncomingPayment` mit Tabelle `Zahlungseingang` (siehe SwRS-8); fachlich derselbe Gegenstand „eingehende Zahlung", zwei Datenhaltungen.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Formeln/Feldregeln nachliefern
Status: HYPOTHESE
ID: SwRS-7
Titel: Werkzeuganbindung über ExternalTools-Datenhaltung
Ebene: SwRS
Typ: Datenanforderung / Mapping
Qualitätsmerkmal: Wartbarkeit, Portabilität
Akteur: `ExternalToolPreviewViewModel`, Tabelle `ExternalTools`
Vorbedingung: Externes Werkzeug ist in `ExternalTools` gepflegt
Fakt: Faktenbasis M006 benennt `ExternalToolPreviewViewModel` als Aufrufer und `ExternalTools` als Datenträger.
Aussage: Die Vorschaukomponente liest Werkzeugdefinitionen aus der Tabelle `ExternalTools` und übergibt Startparameter an den Client; eine eigene Werkzeughaltung außerhalb dieser Tabelle existiert nicht.
Ergebnis: Werkzeugbestand ist ausschließlich über diese Tabelle steuerbar; Änderungen wirken ohne Codeanpassung.
Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenz übernommen, nicht gegengeprüft) – `ExternalToolPreviewViewModel`, Schema `ExternalTools` (M006).
Prüfidee: Satz in `ExternalTools` ändern und Vorschau neu laden; Parameterweitergabe protokollieren.
Tracelinks: SyRS:Externe-Werkzeuge, StRS:Arbeitsplatz
Konsolidierung: kein Fall – keine zweite Werkzeughaltung belegt.
Übernahmewürdigkeit: übernehmen - niedrige Priorität - Spalten-/Parametereinfluss nicht belegt
Status: HYPOTHESE
ID: SwRS-8
Titel: Zahlungseingang: Berechtigungsgate und Referenzlose Löschung mit Währungsfaktor-Umbuchung
Ebene: SwRS
Typ: Funktions-/Constraintanforderung (Abrechnung + Berechtigung)
Qualitätsmerkmal: Richtigkeit, Sicherheit, Konsistenz
Akteur: `PaymentsBL` (Finances/Payments)
Vorbedingung: Angemeldeter Benutzer mit Rechtenauflösung nach SwRS-1
Fakt: `if (loggedInUser.User.HasUserRight(UserRightsConst.Controlling.Finances.INCOMING_PAYMENT_TRANSACTIONS) == false) return Result.AsError("Sie haben nicht das Recht 'Zahlungseingang.", DefaultMessageCodes.RightCheckFailed);` (PaymentsBL.cs:43-44); Löschung summiert und bucht zurück: `var amountToChange = groupie.Sum(f => f.Amount) * (-1);` und übergibt `amountToChange * invoice.CurrencyFactor` an `receiptBL.UpdateReceiptIsPaid(..., "Zahlungseingang gelöscht",...)` (PaymentsBL.cs:62-71), danach `Delete(...)` (Zeile 75). Schema: `CREATE TABLE [dbo].[Zahlungseingang]( … [RechKopfI3D] [int] NULL, [Betrag] [float] NULL, [Restbetrag] [float] NULL …)` ohne FOREIGN KEY (SSMS_DB_SCHEMA.sql:17604-17623).
Aussage: Das Löschen von Zahlungseingängen ist an das Recht `INCOMING_PAYMENT_TRANSACTIONS` gebunden; die Rückbuchung erfolgt je Rechnung mit Vorzeichenwechsel und Multiplikation mit `CurrencyFactor`; die Verknüpfung zur Rechnung (`RechKopfI3D`) ist nullable und nicht fremdschlüsselgesichert.
Ergebnis: Ohne Recht erfolgt Abbruch mit `RightCheckFailed`; mit Recht werden Rechnungszahlstatus und Zahlungsegangsätze konsistent zurückgeführt, sofern `RechKopfI3D` gepflegt ist — andernfalls entstehen Zahlungen ohne Rechnungsbezug, die durch kein DB-Constraint verhindert werden.
Belege: PRIMÄR – `src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs:43-44, 62-71, 75` (Wortlaut im Lauf geprüft). PRIMÄR – `SSMS_DB_SCHEMA.sql:17604-17623`, `Zahlungseingang` ohne FK, `RechKopfI3D NULL` (Constraint als durchgesetzte Regel: fehlender FK = erlaubte Referenzlosigkeit).
Prüfidee: (1) Löschen ohne Recht → Fehlercode prüfen; (2) Zahlungseingang mit `RechKopfI3D = NULL` speichern → Speichern gelingt, Auswertung in offenen Posten prüfen; (3) Fremdwährungsrechnung: Rückbuchungsbetrag gegen `CurrencyFactor` nachrechnen.
Tracelinks: SyRS:Zahlungseingang, SyRS:Rechteverwaltung, StRS:Abrechnung, StRS:Rechteverwaltung; SwRS-6, SwRS-9, SwRS-16
Konsolidierung: Kandidat – „eingehende Zahlung" wird doppelt gehalten: `Zahlungseingang` (FK-frei, `PaymentsBL`) und `PaymentTransactionBL`-Datenhaltung (M005, siehe SwRS-6); im Zielsystem zu einem Zahlungsmodell zusammenführen.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-9
Titel: Mahnstufen-Statusmaschine des Mahnlaufs
Ebene: SwRS
Typ: Funktionsanforderung (Statusmaschine, Abrechnung)
Qualitätsmerkmal: Richtigkeit, Vollständigkeit
Akteur: `DunningRunBL`
Vorbedingung: Mahnfähige Rechnung im Zustand `DunningLevel.None|Level1|Level2`
Fakt: `switch (invoice.DunningLevel)` mit `case DunningLevel.None: invoice.DunningLevel = DunningLevel.Level1; invoice.DunningLevel1Date = DateTime.Now; invoice.DunningLevel1Employee = loggedInUser.UserI3D; break;` usw. bis `Level2 → Level3`, und `default: throw new ArgumentOutOfRangeException;`, Abschluss `this._repository.SaveInvoice(invoice);` (DunningRunBL.cs:248-275).
Aussage: Der Mahnlauf erhöht die Stufe genau um eine Stufe und schreibt je Stufe Datum und Bearbeiter-I3D; ein bereits auf `Level3` stehender Satz führt zur Ausnahme, nicht zu einer vierten Mahnung.
Ergebnis: Mahnstufen sind monoton und lückenlos; Mehrfachmahnen auf Stufe 3 bricht technisch sichtbar ab. Stammdaten-seitige Grenzwerte (`DunningLetterAfterDays1..3`, `LockOrderAfterDunningLevel`, SSMS_DB_SCHEMA.sql:3698-3701) werden von dieser Maschine nicht ausgewertet.
Belege: PRIMÄR – `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs`, `UpdateInvoice`, Zeilen 248-275, Wortlaut im Lauf geprüft. KONTEXT – Schemaspalten `DunningLetterAfterDays1/2/3`, `LockOrderAfterDunningLevel` (SSMS_DB_SCHEMA.sql:3698-3701).
Prüfidee: Rechnung auf `Level3` setzen und erneuten Mahnlauf fahren → `ArgumentOutOfRangeException` erwarten; Stufenfolge 0→1→2→3 mit Datums-/Bearbeiterprüfung.
Tracelinks: SyRS:Mahnwesen, StRS:Debitorenbetreuung; SwRS-8, SwRS-23
Konsolidierung: kein Fall im Modul; verwandt aber andersartig: die Helpdesk-Eskalation (SwRS-22/SwRS-23) ist ein zweiter Stufenmechanismus für einen anderen Gegenstand (Tickets, nicht Rechnungen) — kein Zusammenführungsfall.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-10
Titel: Pflichtfelder der Kampagnen-Persistenz
Ebene: SwRS
Typ: Datenanforderung / Constraint
Qualitätsmerkmal: Vollständigkeit, Konsistenz
Akteur: `CampaignBL`
Vorbedingung: Kampagne wird angelegt oder geändert
Fakt: Faktenbasis M008 verweist auf `CampaignBL` Zeilen 30-47 und auf das Schema `Campaigns` mit NOT-NULL-Feldern.
Aussage: Die Kampagnenkomponente erzeugt/prüft Kampagnensätze vor der Persistenz anhand der in Zeilen 30-47 hinterlegten Vorgaben; die数据库seitige Pflichtigkeit wird zusätzlich durch NOT-NULL-Constraints der Tabelle `Campaigns` erzwungen.
Ergebnis: Unvollständige Kampagnen scheitern entweder in der BL-Prüfung oder am Datenbankconstraint; die zweite Stufe greift auch bei Direktzugriffen.
Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenz wörtlich übernommen; Feldliste im Lauf nicht extrahiert) – `CampaignBL.cs:30-47`, Schema `Campaigns` (M008).
Prüfidee: Kampagne mit fehlenden Pflichtfeldern per BL und per Direkt-SQL anlegen; beide Ablehnungswege prüfen.
Tracelinks: SyRS:Kampagnenverwaltung, StRS:Marketing
Konsolidierung: kein Fall – keine zweite Kampagnenhaltung belegt.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - konkrete Feldliste nachliefern
Status: HYPOTHESE
ID: SwRS-11
Titel: Neuberechnung des Vertragsendes inkl. Kündigungs-Kappung und Iterationsgrenze
Ebene: SwRS
Typ: Funktionsanforderung (Berechnungsvorschrift, Abrechnung)
Qualitätsmerkmal: Richtigkeit, Vollständigkeit, Robustheit
Akteur: `ContractBL.RefreshContractEndeDate` (Webservice-getrieben)
Vorbedingung: Verträge mit `Status == 1`
Fakt: `firstEndDate = GetNewDate(contract.Beginn.Value, contract.LaufzeitArt.Value, contract.LaufzeitDauer.Value)` (ContractBL.cs:1093); bei `AutoVerlaengerung == 0` gilt `newEndDate = firstEndDate` (Zeile 1097); bei `Verlaengerung == 0` gilt `if (contract.KuendigungsDatum > new DateTime(2000, 01, 01)) newEndDate = contract.KuendigungsDatum;` (Zeile 1103); Verlängerungsschleife `while (newEndDate == null) { … if (termination >= DateTime.Today) newEndDate = secondEndDate; else secondEndDate = GetNewMonthDate(secondEndDate, contract.Verlaengerung.Value); i++; if (i == 100) break; }` (Zeilen 1117-1128); Kappung `if (contract.KuendigungsDatum != null && contract.KuendigungsDatum > new DateTime(2000, 01, 01) && newEndDate > contract.KuendigungsDatum) newEndDate = contract.KuendigungsDatum;` (Zeile 1132); unvollständige Basisdaten werden übersprungen und zur ToDo-Bereinigung vorgemerkt (Zeilen 1086-1090); Änderung wird protokolliert: `$"Vertragsende wurde von Webservice auf '{dt}' gesetzt"` (Zeile 1145).
Aussage: Die Komponente berechnet das Vertragsende aus Beginn/Laufzeit, verlängert in Verlaengerungsschritten bis zum Kündigungsfrist-Fenster, begrenzt die Suche auf 100 Iterationen und kappt jedes Ergebnis auf ein vorhandenes Kündigungsdatum, sofern dieses nach dem 01.01.2000 liegt.
Ergebnis: `VertragKopf.Ende` ist nach dem Lauf höchstens das Kündigungsdatum; Sätze ohne `Beginn`/`LaufzeitArt`/`LaufzeitDauer` bleiben unverändert, werden aber zur ToDo-Abstimmung erfasst; nach 100 Schritten ohne Treffer bleibt `Ende` unverändert (kein Ende geschrieben).
Belege: PRIMÄR – `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs`, `RefreshContractEndeDate`, Zeilen 1067-1150 mit wörtlich zitierten Formeln/Kappungen (im Lauf geprüft).
Prüfidee: Vier Verträge konfigurieren: ohne Autoverlängerung; Autoverlängerung ohne Verlängerungsdauer mit Kündigungsdatum; Autoverlängerung mit `KuendigungsFristArt1/2`; Extremfall, in dem 100 Schritte nicht genügen — Ergebnisse gegen die zitierten Formeln nachrechnen.
Tracelinks: SyRS:Vertragsabrechnung, SyRS:Vertragsende-Ermittlung, StRS:Abrechnung; SwRS-12, SwRS-31
Konsolidierung: Kandidat – Frist-/Verlängerungslogik ist zusätzlich in SQL-Skripten als ableitende Fallunterscheidung codiert (`WHEN A.Stammblattbezogen = 1 AND A.KontingentVertrag = 1 THEN 3 …`, SQLScriptCollection4.xml:936-938 u. a. — dieselbe Zuordnung in über zehn Skriptkopien); im Zielsystem Fachregel je einmal (Code oder View) realisieren.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-12
Titel: Zählerfortschreibung der Gerätezähler mit Monotoniesicherung und funktionslosen Stub-Methoden
Ebene: SwRS
Typ: Funktionsanforderung (Abrechnungsvorleistung) + Implementierungshinweis
Qualitätsmerkmal: Richtigkeit, Vollständigkeit
Akteur: `DeviceClickCounterBL` (Click-Contracts)
Vorbedingung: Importierter Zählerstand liegt vor; Mapping auf Gerätezähler existiert
Fakt: Monotonieschutz: `if (clickCounter.CurrentCounter > unassignedClicks.CounterValue) { return Result.AsError("old counter value is higher as the new one"); }` dann `oldCounterValue = clickCounter.CurrentCounter; clickCounter.CurrentCounter = unassignedClicks.CounterValue;` (DeviceClickCounterBL.cs:250-257). Stub: `public Result TransmitUnassignedClickCountersToDeviceClickCounter(...) { … //return SaveClickCounter(counters, currUser, isAutomatic);w return null; }` (Zeilen 87-99) und `public DeviceClickCounterTypeMapping GetMappingCouterKind(string code) { return null; … }` (Zeilen 106-110). Zähler hängen am Stammblatt: `GetClickCounterFromMasterDataListId(int masterDataListId) → GetList(f => f.DeviceHeaderI3D == masterDataListId)` (Zeilen 82-85).
Aussage: Ein neuer Zählerstand wird nur übernommen, wenn er nicht unter dem gespeicherten liegt; die Sammelübertragung und die Zählerart-Zuordnung sind aktuell als Rumpf implementationen ohne Funktionalität ausgeführt (`return null`), wodurch nachgelagerte Prüfungen (`GetMappingCouterKind(...) != null`, Zeile 176) stets ins Leere laufen.
Ergebnis: Einzelzähler bleiben monoton; die automatische Übertragung liefert `null` statt eines `Result`, und Zählerart-Filter entfernen keine Einträge — Zählerstände erreichen die Abrechnung nur über verbleibende Einzelfälle.
Belege: PRIMÄR – `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/DeviceClickCounterBL.cs:82-85, 87-99, 106-110, 176, 250-257` (Wortlaut im Lauf geprüft).
Prüfidee: Kleineren als gespeicherten Zähler senden → Fehlermeldung erwarten; `TransmitUnassignedClickCountersToDeviceClickCounter` aufrufen → `null`-Rückgabe dokumentieren und Aufruferverhalten prüfen.
Tracelinks: SyRS:Click-Abrechnung, SyRS:Zaehleruebernahme, StRS:Abrechnung; SwRS-11, SwRS-45
Konsolidierung: Kandidat (Geräte-/Hardwarehaltung, Fall (a)): Zähler werden am „Stammblatt" geführt — `DeviceHeaderI3D` wird mit `masterDataListId` gleichgesetzt (Zeilen 82-84; Begriffsprägung `case CentronObjectKindNumeric.MasterDataListClass: return "Stammblatt";`, CentronObjectKindNumeric.cs:314) — während Drucker- bzw. Gerätebestandsdaten zusätzlich in `AssetManagementPrinter`/`AssetManagementDevices` gehalten werden; zwei Haltungen für denselben Gegenstand (siehe SwRS-45).
Übernahmewürdigkeit: übernehmen - hohe Priorität - abrechnungsrelevant
Status: belegt
ID: SwRS-13
Titel: Rücksetzung (Revert) von Sprache und Währung in der Adresskomponente
Ebene: SwRS
Typ: Funktionsanforderung (interne Regel)
Qualitätsmerkmal: Richtigkeit, Konsistenz
Akteur: `AccountAddressBL`
Vorbedingung: Änderung der sprach-/währungsbezogenen Kontodaten
Fakt: Faktenbasis M011 verweist für Sprache/Währungs-Revert auf `AccountAddressBL.cs:282-332` und auf die NOT-NULL-Felder der Kontotabelle.
Aussage: Beim Verwerfen oder Ändern von Kontoadressdaten setzt die Komponente Sprache und Währung auf den Ausgangswert (bzw. Kontovorgabe) zurück; die Persistenz erzwingt die Pflichtfelder der Kontotabelle.
Ergebnis: Adresssätze erscheinen nie ohne Sprache/Währung; abgeleitete Belegparameter bleiben konsistent.
Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenz wörtlich übernommen, im Lauf nicht gegengeprüft) – `AccountAddressBL.cs:282-332`, Kontotabelle NOT NULL (M011).
Prüfidee: Sprache/Währung ändern, Änderung verwerfen, Werte und Persistenz vergleichen.
Tracelinks: SyRS:Kontoverwaltung, StRS:Stammdaten; SwRS-16
Konsolidierung: kein Fall – keine zweite Revert-Logik für Sprache/Währung belegt.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - konkrete Rücksetzregel (Feldliste) fehlt
Status: HYPOTHESE
ID: SwRS-14
Titel: Pflichtpersistenz beim Produktlebens Zyklus-Ende
Ebene: SwRS
Typ: Daten-/Constraintanforderung
Qualitätsmerkmal: Vollständigkeit
Akteur: `ProductLifecycleEndViewModel`, Schema (Zeile 46981)
Vorbedingung: Artikel wird auf Lebenszyklus-Ende gesetzt
Fakt: Faktenbasis M012 verweist auf `ProductLifecycleEndViewModel` Zeilen 522-540 und auf NOT-NULL-Felder im Schema an Zeile 46981.
Aussage: Die Client-Komponente bereitet die fürs Lebenszyklus-Ende nötigen Felder auf und übergibt sie an die Persistenz, die die Werte NOT NULL erzwingt.
Ergebnis: Ein Lebenszyklus-Ende ohne die Pflichtangaben wird datenbankseitig abgewiesen.
Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenzen wörtlich übernommen; Feldnamen nicht extrahiert) – `ProductLifecycleEndViewModel.cs:522-540`, `SSMS_DB_SCHEMA.sql:46981` (M012).
Prüfidee: Pflichtfeld leer lassen → DB-Ablehnung prüfen; UI-Vorprüfung vergleichen.
Tracelinks: SyRS:Artikel-Lebenszyklus, StRS:Artikelstamm; SwRS-41
Konsolidierung: kein Fall.
Übernahmewürdigkeit: übernehmen - niedrige Priorität - Feldliste fehlt
Status: HYPOTHESE
ID: SwRS-15
Titel: Nummernkreisvergabe und Anfangszustand bei CRM-Projekten
Ebene: SwRS
Typ: Funktionsanforderung (interner Algorithmus)
Qualitätsmerkmal: Richtigkeit, Prüfbarkeit
Akteur: `CrmProjectBL.SaveCrmProject`
Vorbedingung: Neues CRM-Projekt (`project.I3D == 0`), angemeldeter Benutzer
Fakt: `if (isNew) { project.Number = this._numberGroupBL.GetNextNumber(NumberGroupEnum.CRMProject, updateDatabase: true, currentEmployee: currentUser.Employee); project.State = 1; … }` (CrmProjectBL.cs:115-119); Guards: `Guard.NotNullOrWhiteSpace(project.Name, …)`, `Guard.NotLessOrEqualThan(project.ProjectKindI3D, 0, …)` (Zeilen 109-110); die gesamte Änderung läuft in `this.Session.WithTransaction(...)` (Zeile 112).
Aussage: Neue CRM-Projekte erhalten ihre Nummer ausschließlich über den Nummernkreis `NumberGroupEnum.CRMProject` mit immediate Database-Update und starten softwareintern im Zustand `State = 1`; Änderungsversion und Erzeugermetadaten werden aus der Baugruppe abgeleitet.
Ergebnis: Nummer und Anfangszustand sind deterministisch und transaktional gesichert; ein direkter Zahlenvergleich `project.Number` gegen Zählerstände ist zulässig (Referenzzähler gemäß Faktenbasis Zeile 363).
Belege: PRIMÄR – `src/backend/Centron.BL/Sales/Customers/CrmProjects/CrmProjectBL.cs:105-124` (Wortlaut im Lauf geprüft). KONTEXT – Faktenbasis M013 für den Referenzzähler (Zeile 363).
Prüfidee: Zwei Projekte parallel anlegen (Nummern lückenlos/eindeutig); `State` nach Anlage prüfen; Transaktionsabbruch (Guards) ohne Nummerverbrauch testen.
Tracelinks: SyRS:Projektanlage-CRM, StRS:Vertriebssteuerung; SwRS-19
Konsolidierung: kein Fall – Nummernkreis wird zentral über `NumberGroupEnum` vergeben; Abweichungen betreffen andere Nummernkreise, nicht denselben Gegenstand.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-16
Titel: Zweistufige Nettopreisberechnung mit AwayFromZero-Rundung
Ebene: SwRS
Typ: Funktionsanforderung (Preisformel, Preis/Abrechnung)
Qualitätsmerkmal: Genauigkeit, Richtigkeit
Akteur: `ReceiptPriceHelper.CalculateNetPrice` (WebServices.Core)
Vorbedingung: Basispreis, Genauigkeitsstelle, Rabatt, Währungsfaktor, Fremdwährungskennzeichen liegen vor
Fakt: Wörtlich: `if (currencyFactor == 0) currencyFactor = 1;` · `var basePriceWithCurrencyFactor = basePrice * (isForeignCurrency ? currencyFactor : 1);` · `var roundedBasePrice = Math.Round(basePriceWithCurrencyFactor, precision, MidpointRounding.AwayFromZero);` · `var withDiscount = roundedBasePrice * ((100 - discount) / 100);` · `var result = Math.Round(withDiscount, precision, MidpointRounding.AwayFromZero);` (ReceiptPriceHelper.cs:202-213).
Aussage: Der Nettopreis wird zweistufig ermittelt: erst Währungsumrechnung mit anschließender Rundung auf `precision`, dann Rabattabzug mit zweiter Rundung; ein Währungsfaktor 0 wird intern als 1 behandelt.
Ergebnis: Das Rundungsergebnis hängt von der Reihenfolge „Rundung vor Rabatt" ab und kann von einer einstufigen Berechnung um eine Genauigkeitsstelle abweichen; Teilung durch 0 ist ausgeschlossen.
Belege: PRIMÄR – `src/webservice/Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs`, `CalculateNetPrice`, Zeilen 202-213, Formel wörtlich zitiert (im Lauf geprüft).
Prüfidee: Goldene Werte für `precision = 2`, `discount = 33,33 %`, `currencyFactor = 0` und Fremdwährung erzeugen; gegen einstufige Referenzrechnung differieren lassen; Rounding-Mode-Grenzwert (0,005) testen.
Tracelinks: SyRS:Preisformel, StRS:Preisbildung; SwRS-17, SwRS-19, SwRS-31
Konsolidierung: Kandidat – parallele Rundungs-/Preislogik: dieselbe Preismechanik existiert zusätzlich in der SQL-Skriptsammlung (z. B. Preisspalten-Ableitungen in den Beleg-Skripten) und im Kontext `AngKopf`/`ReceiptPos`; Ziel: eine Preisberechnungsinstanz. Abgrenzung: SwRS-17 ist derselbe Sachverhalt auf derselben Ebene, aber anderer Rechenschritt (MwSt.), daher kein Doppel, sondern Ergänzung.
Übernahmewürdigkeit: übernehmen - hohe Priorität - preisbestimmend
Status: belegt
ID: SwRS-17
Titel: MwSt-Aufgruppierung mit CH-Rundung auf 0.05
Ebene: SwRS
Typ: Funktionsanforderung (Abrechnung)
Qualitätsmerkmal: Genauigkeit, Richtigkeit
Akteur: `ReceiptPriceHelper.CalculateReceiptVatPrices`
Vorbedingung: Belegpositionen mit `Kind`, `ArticlePositionKind`, `Expanded == null`, Steuersatz
Fakt: Filter: `var validItemKinds = new[] { ReceiptItemKind.Article, ReceiptItemKind.CustomerDiscount };` · `validItemArticlePositionKinds = new[] { ReceiptItemArticlePositionKind.Default, ReceiptItemArticlePositionKind.Cargo };` · `.Where(f => f.Expanded == null)`; Gruppierung `group item by item.TaxRate` mit `TaxPrice = Math.Round(g.Sum(f => f.TaxPriceTotal), 2, MidpointRounding.AwayFromZero)` und `NotDiscountableNetPriceFC = g.Where(f => f.Item.NoEarlyPaymentDiscountAllowed).Sum(...)` (ReceiptPriceHelper.cs:61-95). Schweizer Rundung: `… - (switzerlandRounding == false ? 0m : netPriceSum + taxPriceSum - Math.Round((netPriceSum + taxPriceSum) / 0.05m, 0) * 0.05m)` (ReceiptPriceHelper.cs:37, analog 39, 41).
Aussage: Nur Artikel- und Kundendruckerpositionen der Positionstypen Default/Cargo und nicht aufgeklappte Positionen fließen in die MwSt-Aufteilung ein; die Steuerbeträge werden je Steuersatz summiert, auf 2 Stellen AwayFromZero gerundet und bei aktivierter CH-Rundung zusätzlich auf das 0.05-Raster abgebildet; nicht skontofähige Beträge werden separat über `NoEarlyPaymentDiscountAllowed` ausgewiesen.
Ergebnis: Die Belegsummen sind je Steuersatz prüfbar und CH-konform gerastert; ausgefilterte Positionen (z. B. aufgeklappte) tauchen in keiner MwSt-Gruppe auf.
Belege: PRIMÄR – `ReceiptPriceHelper.cs:61-95` (Filter/Gruppierung, Wortlaut im Lauf geprüft) und `ReceiptPriceHelper.cs:37, 39, 41` (0.05-Rundungsformel wörtlich).
Prüfidee: Beleg mit gemischten Steuersätzen und einer Position `NoEarlyPaymentDiscountAllowed = true` rechnen; CH-Rundung an-/abschalten; Summenkontrolle Brutto = Netto + Steuer nach Rasterung.
Tracelinks: SyRS:MwSt-Aufteilung, SyRS:Preisformel, StRS:Abrechnung; SwRS-16, SwRS-18
Konsolidierung: Kandidat – CH-Rundungsformel ist dreifach als ausformulierte Zeile innerhalb derselben Methode wiederholt (Zeilen 37, 39, 41) und zusätzlich in Skript-Views angelegt; zu einer Rundungsfunktion zusammenführen.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-18
Titel: Nicht unterstützte MwSt-Übernahme bei Gutschriften
Ebene: SwRS
Typ: Funktionsanforderung (Ausnahmebehavior, Abrechnung)
Qualitätsmerkmal: Vollständigkeit, Zuverlässigkeit
Akteur: `*SpecificLogic.CanBeForwardedFrom/Into`, `CreditVoucher.TakeoverVAT`
Vorbedingung: Weiterleitung/Übernahme von Belegdaten auf Gutscheinbeleg
Fakt: Faktenbasis M014: „CanBeForwardedFrom/Into je *SpecificLogic; CreditVoucher TakeoverVAT throws NotSupportedException".
Aussage: Die Weiterleitungsfähigkeit wird je Belegart in eigenen `*SpecificLogic`-Implementierungen entschieden; die MwSt-Übernahme ist für `CreditVoucher` bewusst nicht implementiert und wirft `NotSupportedException`.
Ergebnis: Ein Versuch, MwSt-Beträge auf einen Gutschein zu übernehmen, bricht technisch sichtbar ab, statt falsche Beträge zu erzeugen.
Belege: KONTEXT/PRIMÄR (durchsetzende Stelle laut Faktenbasis M014; Klassenname/Zeile im Lauf nicht verifiziert) – `[HYPOTHESE]` bezüglich exakter Aufrufkette: Die抛出-Stelle wurde in diesem Lauf nicht aufgesucht.
Prüfidee: `TakeoverVAT` auf `CreditVoucher` aufrufen → `NotSupportedException` erwarten; `CanBeForwardedFrom/Into` je Belegart matrixartig durchfahren.
Tracelinks: SyRS:Belegweiterleitung, StRS:Abrechnung; SwRS-17
Konsolidierung: Kandidat (Verdacht) – je Belegart separate `*SpecificLogic`-Klassen für dieselbe fachliche Frage „darf dieser Beleg fortgeleitet werden"; Zusammenführung in eine规则tabelle/Strategie prüfen.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Belegstelle nachziehen
Status: HYPOTHESE
ID: SwRS-19
Titel: Nullbare Preisspalten im Angebotskopf (Widerspruch zur Faktenbasis)
Ebene: SwRS
Typ: Constraint-/Datenanforderung (Preis)
Qualitätsmerkmal: Konsistenz, Richtigkeit
Akteur: Tabelle `AngKopf`, Mapping `AngKopfMaps`
Vorbedingung: Angebot wird persistiert
Fakt: Schema: `[Netto] [float] NULL,` `[Brutto] [float] NULL,` `[SummeEK] [float] NULL,` `[Status] [int] NULL,` (SSMS_DB_SCHEMA.sql:3882 ff., CREATE ab Zeile 3882). Mapping: `Map(m => m.Netto).Column("Netto").Nullable;` · `Map(m => m.Brutto).Column("Brutto").Nullable;` · `Map(m => m.SummeEK).Column("SummeEK").Nullable;` · `Map(m => m.Status).Column("Status").Nullable;` (AngKopfMaps.cs:85-87, 74). Eine Suche nach `DEFAULT … FOR [dbo].[AngKopf]` liefert keinen Treffer.
Aussage: Angebotskopf-Preissummen und Status sind softwareintern nullbar und haben weder NOT NULL noch DEFAULT 0; die Angebotskopfsummen können daher ohne Werte persistiert werden.
Ergebnis: Auswertungen müssen NULL-Summen behandeln; die in der Faktenbasis angenommene Default-0-Regel ist nicht durchgesetzt (Konsistenz nur über die Berechnungslogik aus SwRS-16/SwRS-17).
Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:3882 ff.` (Spaltendefinitionen, im Lauf gelesen) und `src/backend/Centron.DAO/Mappings/TemporaryEntities/AngKopfMaps.cs:74, 85-87` (Wortlaut im Lauf gelesen). CONTRA – Faktenbasis M014 („AngKopf Preisspalten NOT NULL DEFAULT 0") ist durch Schema und Mapping widerlegt.
Prüfidee: INSERT in `AngKopf` ohne Preisspalten → Erfolg statt Fehler 0 erwarten; Auswertungsberichte auf NULL-Toleranz prüfen.
Tracelinks: SyRS:Angebotserfassung, SyRS:Preisformel, StRS:Preisbildung; SwRS-15, SwRS-16
Konsolidierung: kein Fall – die Nullbarkeit ist ein Datenmodell-Sachverhalt; die Parallele zu SwRS-16 ist Ebenen-/Aspektbeziehung (Tracelink), keine Doppelimplementierung.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Factsheet-Korrektur erforderlich
Status: HYPOTHESE
ID: SwRS-20
Titel: Zusatzfelder: NOT-NULL-Default im Schema, Pflichtprüfung nur im Client
Ebene: SwRS
Typ: Constraint-/Funktionsanforderung
Qualitätsmerkmal: Vollständigkeit, Konsistenz, Sicherheit (Regeldurchsetzung)
Akteur: `ModuleCustomPropertyBL`, `CustomPropertiesGridViewModel`, Tabelle `ModuleCustomProperties`
Vorbedingung: Zusatzfeldstruktur wird gepflegt; Werte werden in der Maske bearbeitet
Fakt: Schema: `[IsMandatory] [bit] NOT NULL,` (SSMS_DB_SCHEMA.sql:44404) mit `ALTER TABLE [dbo].[ModuleCustomProperties] ADD CONSTRAINT [DF_ModuleCustomProperties_IsMandatory] DEFAULT ((0)) FOR [IsMandatory]` (Zeile 67071). Strukturprüfung im BL: `if (properties.Any(property => String.IsNullOrWhiteSpace(property.Name))) return Result.AsError("At least one of the properties got no name.");` · `if (properties.Any(property => property.DataType == CustomizationDataTypes.Unknown)) return Result.AsError("At least one of the properties got a unknown datatype");` (ModuleCustomPropertyBL.cs:40-47). Pflichtwertprüfung ausschließlich im Client: `foreach (var item in Properties.Where(f => f.IsMandatory)) { … messageBuilder.AppendLine(...) }` in `CheckMandatoryProperties` (CustomPropertiesGridViewModel.cs, Zeilen ca. 218-240).
Aussage: Die Pflichtfeld-Eigenschaft ist datenbankseitig mit Default 0 belegt, die inhaltliche Pflichtprüfung (`IsMandatory` ⇒ Wert vorhanden) liegt allein in der Client-Komponente; die BL-Prüfung kontrolliert nur Name und Datentyp der Felddefinition.
Ergebnis: Über Webservice, Import oder Direkt-SQL können Pflichtfelder unbefüllt bleiben; die Regel gilt nur im interaktiven Weg.
Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:44404` und `:67071` (Constraint/Default als durchgesetzte Regel). PRIMÄR – `src/backend/Centron.BL/Administration/Customization/ModuleCustomPropertyBL.cs:40-47` (Wortlaut im Lauf geprüft). PRIMÄR – `src/shared/Centron.Controls/CustomProperties/CustomPropertiesGrid/CustomPropertiesGridViewModel.cs`, `CheckMandatoryProperties` (einzige Prüfstelle, im Lauf geprüft).
Prüfidee: Pflichtfeld definieren, Wert per Direkt-SQL/Webservice leer lassen und Speichern prüfen; Clientweg mit leerem Wert → Meldung erwarten.
Tracelinks: SyRS:Zusatzfelder, StRS:Anpassbarkeit
Konsolidierung: kein Fall – es existiert nur eine Prüfimplementierung; der fehlende BL-Gegenpart ist eine Lücke, keine zweite Umsetzung.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-21
Titel: Weiche und harte Löschung von UI-Profilen
Ebene: SwRS
Typ: Funktions-/Datenanforderung (Statusmaschine)
Qualitätsmerkmal: Konsistenz, Nachvollziehbarkeit
Akteur: `UiProfileBL`, Tabellen `CentronUiProfiles`
Vorbedingung: Benutzerprofil existiert und ist zugeordnet
Fakt: Faktenbasis M016 benennt Constraints der `CentronUiProfiles` sowie soft-/hard-delete-Verhalten in `UiProfileBL.cs`.
Aussage: Die Profilkomponente unterscheidet logische Löschung (Satz bleibt mit Löschkennzeichen erhalten) und physische Löschung; die Schema-Constraints begrenzen die Kombination zulässiger Profildaten.
Ergebnis: Gelöschte Profile bleiben für Zuordnungen referenzierbar bzw. werden entfernt; Verstöße gegen die Schema-Constraints scheitern persistenzseitig.
Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenzen übernommen; Constraint-Namen im Lauf nicht einzeln enumeriert) – `UiProfileBL.cs`, Schema `CentronUiProfiles` (M016).
Prüfidee: Profil soft-delete, Referenztest; hard-delete mit bestehender Referenz → Constraint-Verhalten prüfen.
Tracelinks: SyRS:Benutzerprofile, StRS:Benutzerverwaltung
Konsolidierung: kein Fall.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - Constraintliste nachziehen
Status: HYPOTHESE
ID: SwRS-22
Titel: Eskalationsstufenermittlung und Roh-SQL-Rückschreibung auf Helpdesk-Tickets
Ebene: SwRS
Typ: Funktionsanforderung (Status-/Eskalationslogik, interne Roh-SQL)
Qualitätsmerkmal: Richtigkeit, Sicherheit (SQL-Kapselung)
Akteur: `EscalationBL`
Vorbedingung: Eskalationssatz mit `WaitHourEsc1..3`, Wochentagsaktivierung, Tickets mit ToDoListe-Verknüpfung
Fakt: Stufenermittlung: `if (escItem.WaitHourEsc1 == null && escItem.WaitHourEsc2 == null && escItem.WaitHourEsc3 == null) return 0;` · `if (nowDt.DayOfWeek == DayOfWeek.Saturday && !escItem.IsSaturdayActive) return 0;` (analog Sonntag), Stufenprüfung `ShouldEscalated(escItem, 1|2|3)` mit Rückgabe 1/2/3 (EscalationBL.cs:393-426). Rückschreibung: `$@"Update hr Set EscalationLevel = {escItem.Stage} From hlpdsk_requests hr Inner join ToDoListe tdl on tdl.ObjektArt = {(int)CentronObjectKindNumeric.HelpdeskClass} and tdl.ObjectI3D = hr.I3D Inner join Eskalationen e on e.ObjektI3D = tdl.I3D and e.ObArt = 2 Where e.I3D = {escItem.EscI3D}"` und `ExecuteNonQueryTransactionSave` (EscalationBL.cs:913-921); Stempelfeld: `$"Update Eskalationen SET Eskalation{escItem.Stage}AM = GetDate WHERE I3D = {escItem.EscI3D}"` (Zeilen 923-929).
Aussage: Die Eskalationskomponente ermittelt die Zielf stufe aus Wartezeiten und Wochentagsfreigaben und schreibt sie per interpolierter Roh-SQL in `hlpdsk_requests.EscalationLevel`; die betroffenen Spaltennamen (`Eskalation{Stage}AM`) werden per String-Komposition gebildet.
Ergebnis: Eskalationsstände bleiben außerhalb des ORM gepflegt; die SQL-Stellen sind Interpolationsangriffspunkte (auch wenn die eingesetzten Werte intern erzeugt sind) und die Spaltendynamik entzieht sich statischer Prüfung.
Belege: PRIMÄR – `src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs`, `CheckEskalationStage` Zeilen 393-426, `UpdateTicket`/`UpdateEscalations` Zeilen 913-929, SQL wörtlich zitiert (im Lauf geprüft). KONTEXT – Faktenbasis M017 zu `HelpdeskBL.cs:569-578`.
Prüfidee: Eskalation mit nur Stufe 1 gefüllt und Samstagsmodus deaktiviert testen; `EscalationLevel`-Schreibfluss gegen `hlpdsk_requests.EscalationLevel DEFAULT ((0))` (Schema Zeile 66985) verifizieren; SQL-Interpolation auf Parametrisierung prüfen.
Tracelinks: SyRS:Ticket-Eskalation, StRS:Helpdesk-SLA; SwRS-23, SwRS-1
Konsolidierung: Kandidat (fall (d)) – Zwei parallele Eskalationsmechanismen: (1) `Escalationen`-Tabelle mit `WaitHourEsc1..3`/`Eskalation{n}AM` und `hlpdsk_requests.EscalationLevel` (EscalationBL) und (2) prioritätsbasierte Felder in `hlpdsk_prioritaeten` (`EskalationSa`, `EskalationSo`, `FaeligkeitVerzoegerung`, `IsSLA`), siehe SwRS-23. Derselbe fachliche Gegenstand „Eskalation/SLA" wird in zwei getrennten Implementierungen geführt; Zusammenführung erforderlich.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-23
Titel: Prioritätsstammblatt als zweiter Eskalations-/SLA-Datenträger
Ebene: SwRS
Typ: Datenanforderung / Mapping
Qualitätsmerkmal: Konsistenz
Akteur: Tabelle `hlpdsk_prioritaeten`, Helpdesk-Komponenten
Vorbedingung: Helpdesk-Prioritäten sind gepflegt
Fakt: Schema: `CREATE TABLE [dbo].[hlpdsk_prioritaeten]( [I3D] … [Werktage] [float] NULL, [Stunde2] [float] NULL, [Stunde3] [float] NULL, … [EskalationSa] [int] NULL, [EskalationSo] [int] NULL, [GeschaeftsZeitVon] [datetime] NULL, [GeschaeftsZeitBis] [datetime] NULL, … [FaeligkeitVerzoegerung] [float] NULL, [IsSLA] [bit] NULL, …)` (SSMS_DB_SCHEMA.sql:4485-4514). Ticketseitig: `[EscalationLevel] [int] NOT NULL,` mit `CONSTRAINT [DF_hlpdsk_requests_EscalationLevel] DEFAULT ((0)) FOR [EscalationLevel]` (SSMS_DB_SCHEMA.sql:66985).
Aussage: Eskalations- und SLA-Parameter (Wochenendverhalten, Fälligkeitsverzug, SLA-Kennzeichen) werden im Prioritätsstammblatt gepflegt, während der Eskalationslauf seine Stufen über `Escalationen`/`hlpdsk_requests.EscalationLevel` führt; die NOT-NULL-/Default-Regel von `EscalationLevel` ist die einzige persistente Durchsetzung des Eskalationszustands.
Ergebnis: Eskalationsdaten sind über zwei Modelle verteilt; Konsistenz zwischen Prioritäts-Eskalationswerten und Eskalationslauf wird durch kein Constraint gesichert.
Belege: PRIMÄR – Schema-Constraints/-Spalten: `SSMS_DB_SCHEMA.sql:4485-4514` (Prioritätenfeldmenge), `:66985` (`DF_hlpdsk_requests_EscalationLevel DEFAULT ((0))`, `EscalationLevel int NOT NULL`), beide im Lauf gelesen.
Prüfidee: Priorität mit `IsSLA = 1`, `EskalationSa` gesetzt, aber ohne `Escalationen`-Satz anlegen → Ticket bleibt auf `EscalationLevel = 0`; Abweichung melden.
Tracelinks: SyRS:Ticket-Eskalation, StRS:Helpdesk-SLA; SwRS-22
Konsolidierung: Kandidat (fall (d), Partner von SwRS-22) – `hlpdsk_prioritaeten`-Eskalationsfelder und `EscalationBL`/`Escalationen` bilden denselben fachlichen Gegenstand in zwei getrennten Implementierungen ab.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-24
Titel: Validierung der Umlagerungs-Protokollsätze
Ebene: SwRS
Typ: Funktionsanforderung (Vorbedingungsprüfung, interne Regeln)
Qualitätsmerkmal: Richtigkeit, Vollständigkeit
Akteur: `StockBL.WriteStockRebookLog`
Vorbedingung: Umlagerungsprotokoll liegt an
Fakt: Prüfkette wörtlich: `if (rebookLog == null) return Result.AsError("The log to write is empty");` · `if(rebookLog.ArticleI3D < 1) return Result.AsError("The article i3d is invalid");` · `if (rebookLog.Date == DateTime.MinValue) rebookLog.Date = DateTime.Now;` · `if(rebookLog.Employee == null) return Result.AsError("The employee is invalid");` · `if(rebookLog.FromStore == null) …` · `if(rebookLog.ToStore == null) …` Abschluss `return _warehouseRepository.WriteStockRebookLog(rebookLog);` (StockBL.cs:82-111).
Aussage: Ein Umlagerungsnachweis wird nur geschrieben, wenn Artikel, Bearbeiter, Quell- und Ziellager gesetzt sind; ein fehlendes Datum wird ersatzlos auf „jetzt" gesetzt.
Ergebnis: Unvollständige Umlagerungsnachweise werden abgewiesen; die Zeitachse des Nachweises kann durch die implizite Jetzt-Setzung von der tatsächlichen Bewegung abweichen.
Belege: PRIMÄR – `src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs:82-111`, Prüfkettenwörtlich im Lauf gelesen.
Prüfidee: Protokolle mit fehlendem Ziellager und mit `DateTime.MinValue` anlegen; Fehlerpfad und implizite Datumsetzung verifizieren.
Tracelinks: SyRS:Lagerumlagerung, StRS:Lagerhaltung; SwRS-40, SwRS-32
Konsolidierung: kein Fall.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-25
Titel: Chat- und Tagesaufgabendatenhaltung
Ebene: SwRS
Typ: Datenanforderung
Qualitätsmerkmal: Vollständigkeit
Akteur: `ChatBL`, Tabelle `MyDayWorkItems`
Vorbedingung: Chatnachrichten/Tagespositionen werden erzeugt
Fakt: Faktenbasis M020 verweist auf `ChatBL.cs` Zeilen 112-505 und das Schema `MyDayWorkItems`.
Aussage: Die Chatkomponente verwaltet Unterhaltungen und verknüpfte Tagespositionen über die eigene Datenhaltung; `MyDayWorkItems` liefert die Persistenzstruktur für Tagesaufgabensätze.
Ergebnis: Chat- und Tagespositionsdaten sind softwareintern über diese beiden Haltungen abgebildet.
Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenzen übernommen, im Lauf nicht gegengeprüft) – `ChatBL.cs:112-505`, Schema `MyDayWorkItems` (M020).
Prüfidee: Nachricht mit/ohne Tagesposition speichern; Lösch-/Archivverhalten prüfen.
Tracelinks: SyRS:Kommunikation-Chat, StRS:Zusammenarbeit
Konsolidierung: Kandidat (Verdacht) – Tagespositionen werden zusätzlich als Helpdesk-/ToDo-Objekte geführt (ToDoListe, vgl. SwRS-22); dieselbe fachliche Aufgabenhaltung in zwei Modulen; Verifizierung erforderlich.
Übernahmewürdigkeit: übernehmen - mittlere Priorität
Status: HYPOTHESE
ID: SwRS-26
Titel: Persistenzregeln der Online-Banking-Umsätze
Ebene: SwRS
Typ: Daten-/Funktionsanforderung (Abrechnungsdaten)
Qualitätsmerkmal: Richtigkeit, Konsistenz, Sicherheit
Akteur: `OnlineBankingAccountTransactionsBL`, Schema (Zeilen 45773-45888)
Vorbedingung: Umsätze werden aus Bankdaten übernommen
Fakt: Faktenbasis M021 verweist auf `OnlineBankingAccountTransactionsBL` Zeilen 163-360 und die zugehörigen Tabellen im Schema (Zeilen 45773-45888). Verifiziert ergänzend: Bankzugangsdaten werden verschlüsselt abgelegt, `hbciConfig.AccountUserPassword = new AESCryptoLogic.EncryptText(hbciConfig.AccountUserPassword, securityKey);` (OnlineBankingConfigurationBL.cs:141-148, analog Entschlüsselung Zeilen 158-165).
Aussage: Die Umsatztzkomponente legt Kontobewegungen über ihre eigene Tabellenstruktur ab, während die Zugangsdaten (HBCI/FinAPI) verschlüsselt in der Konfigurationshaltung liegen.
Ergebnis: Klartext-Zugangsdaten werden nicht persistiert; die Umsatzübernahme folgt den Regeln der genannten Methode.
Belege: PRIMÄR – `src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingConfigurationBL.cs:141-148, 158-165` (AES-Verschlüsselung, Wortlaut im Lauf geprüft). PRIMÄR (Referenz aus Faktenbasis, Methodenlogik nicht gegengeprüft) – `OnlineBankingAccountTransactionsBL.cs:163-360`, `SSMS_DB_SCHEMA.sql:45773-45888` (M021).
Prüfidee: Umsatzübernahme doppelt ausführen (Duplikatschutz prüfen); Konfiguration lesen → Ciphertext in DB, Klartext in API prüfen.
Tracelinks: SyRS:OnlineBanking, StRS:Zahlungsverkehr; SwRS-6
Konsolidierung: Kandidat – zwei HBCI/FinAPI-Zugangshaltungen: HBCI- und FinAPI-Konfiguration in einem Datensatz mit je eigener Verschlüsselungsaufrufzeile (OnlineBankingConfigurationBL.cs:141-148); fachlich ein „Bankzugang", zwei Teilmodelle.
Übernahmewürdigkeit: übernehmen - mittlere Priorität
Status: HYPOTHESE
ID: SwRS-27
Titel: Kennwortverwaltung: leere Salt-/Kennwortwerte trotz NOT-NULL-Constraint
Ebene: SwRS
Typ: Funktions-/Constraintanforderung (Berechtigung, Sicherheit)
Qualitätsmerkmal: Richtigkeit, Sicherheit
Akteur: `PasswordManagementKeywordBL`, Tabelle `PasswordManagementKeyword`
Vorbedingung: Benutzer legt ein neues Schlüsselwort an bzw. ruft es ab
Fakt: Anlage: `keyword.Username = username; keyword.Salt = ""; keyword.Password = "";` (PasswordManagementKeywordBL.cs:46-48). Abruf: `// decryption` gefolgt von `return keyword.Password;` (Zeilen 27, 32) — es findet keine Entschlüsselung statt; Protokollschreibweise: `accessLogBl.SavePasswordManagementAccessLog(keyword.I3D, PasswordManagementActionTypeEnum.Create, user);` auch beim Abruf (Zeile 30). Schema: `[Salt] [nvarchar](128) NOT NULL, [Password] [nvarchar](128) NOT NULL,` (SSMS_DB_SCHEMA.sql:46142-46143).
Aussage: Die Anlegefunktion speichert Salt und Kennwort als leere Zeichenkette und erfüllt damit formal das NOT-NULL-Constraint, ohne Wert zu liefern; der Abruf liefert den gespeicherten Rohtmppwert, kennzeichnet den Zugriff aber als „Create"-Aktion.
Ergebnis: Schlüsselwörter sind nach dem Anlegen inhaltlich leer; Zugriffsprotokolle weisen Lesezugriffe als Erzeugung aus und sind als Nachweis nicht brauchbar.
Belege: PRIMÄR – `src/backend/Centron.BL/PasswordManagementArea/PasswordManagementKeywordBL.cs:21-58`, Code wörtlich zitiert (im Lauf geprüft). PRIMÄR – `SSMS_DB_SCHEMA.sql:46138-46145` (NOT-NULL-Constraints als durchgesetzte Regel).
Prüfidee: Keyword anlegen und DB-Werte prüfen; Abruf durchführen und Protokolldatensatz-Typ kontrollieren; NOT-NULL-Verletzung durch `NULL`-Einschub testen.
Tracelinks: SyRS:Kennwortverwaltung, StRS:Rechteverwaltung; SwRS-47
Konsolidierung: Kandidat – „Zugangsdaten aufbewahren" wird drittens implementiert: hier unverschlüsselt/leer in `PasswordManagementKeyword`, in MailScannern mit MasterKey (`MailScannerBL.cs:90-116`) und andernorts mit `AESCryptoLogic`-Default-Key (SwRS-47); ein Zielfachkonzept „Geheimnisspeicher" erforderlich.
Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheitsrelevant
Status: belegt
ID: SwRS-28
Titel: Kostenträger-/Kostenstellen-Datenhaltung ohne Eindeutigkeitsregeln und doppelt angelegt
Ebene: SwRS
Typ: Daten-/Constraintanforderung
Qualitätsmerkmal: Konsistenz, Vollständigkeit
Akteur: Tabellen `Kostentraeger`, `Kostenstellen`, `Kostenstelle`, `KostenstellenBackup`; `ArticleBL` (Pflichteinstellungen)
Vorbedingung: Kostenrechnungsstammdaten werden gepflegt
Fakt: Schema: `CREATE TABLE [dbo].[Kostentraeger]( [I3D] … NOT NULL, [Nummer] [varchar](50) NULL, [Beschreibung] [varchar](255) NULL, [Status] [int] NULL, [NummerAlt] [varchar](50) NULL, PRIMARY KEY CLUSTERED ([I3D] ASC))` (SSMS_DB_SCHEMA.sql:5673-5683); parallel `CREATE TABLE [dbo].[Kostenstellen]( [I3D] …, [KostentraegerI3D] [int] NULL, [Nummer] [varchar](50) NULL, … [ParentI3D] [int] NULL, …)` (Zeilen 5905-5920) und zusätzlich `CREATE TABLE [dbo].[Kostenstelle]( [I3D] …, [MandantI3D] [int] NOT NULL, [Kostenstelle] [int] NULL, [Bezeichnung] [varchar](50) NULL, [Status] [int] NULL, CONSTRAINT [PK_Kostenstelle] …)` (Zeilen 42139-42149) sowie `KostenstellenBackup` (Zeile 42174). Faktenbasis M023 ergänzt: Artikelseitige Kostenstellenpflicht über die Einstellungen 10168/10169 (`ArticleBL`).
Aussage: Kostenträger- und Kostenstellennummern sind nullbar und ohne UNIQUE-Constraint; für Kostenstellen existieren zwei aktive Tabellen (Plural mit Hierarchie/Trägerbezug, Singular mit Mandantenbezug) plus eine Backuptabelle; die Pflichtangabe einer Kostenstelle für Artikel wird nicht persistent, sondern über Einstellungen gesteuert.
Ergebnis: Doppelte oder leere Nummern sind zulässig; Auswertungen müssen zwei Kostenstellenhaltungen zusammenführen; die Artikelspflicht ist verlustig, wenn die Einstellungen 10168/10169 nicht ausgewertet werden.
Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:5673-5683`, `:5905-5920`, `:42139-42149`, `:42174` (Tabellen-/Constraintlage, im Lauf gelesen; Abwesenheit von UNIQUE/FK ist damit belegt). KONTEXT – Faktenbasis M023 für `ArticleBL`/Einstellungen 10168-10169.
Prüfidee: Zwei Kostenträger mit identischer `Nummer` anlegen (Erfolg erwarten); identische Kostenstellennummer in `Kostenstellen` und `Kostenstelle` und Auswertung prüfen; Einstellungen 10168/10169 ein-/ausschalten und Artikelspeicherung vergleichen.
Tracelinks: SyRS:Kostenrechnung, StRS:Kostenrechnung; SwRS-29
Konsolidierung: Kandidat (fall (b)-Verwandtschaft, eigenständiger Fall) – Doppelhaltung „Kostenstelle": `Kostenstellen` (plural, `KostentraegerI3D`/`ParentI3D`) vs. `Kostenstelle` (singular, `MandantI3D`) — zwei getrennte Implementierungen desselben Stammdatenobjekts, im Zielsystem auf eine Kostenstellenhaltung zu führen.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-29
Titel: UI-Begriff „Payers" für das Domänenobjekt Kostenträger
Ebene: SwRS
Typ: Namens-/Mappinanforderung (softwareinterne Begrifflichkeit)
Qualitätsmerkmal: Konsistenz, Verständlichkeit
Akteur: UI-Modul `PayersAndCostCenter`
Vorbedingung: Modul „Kostenträger/Kostenstellen" wird geöffnet
Fakt: Ribbonseite: `<dxr:RibbonPage Caption="Kostenträger" x:Name="PayersRibbonPage">` (PayersAndCostCenterAppModuleControllerView.xaml:34); `public async Task DoOpenAddPayers { var addCostCenterOrPayersViewModel = new AddCostCenterOrPayersViewModel("Kostenträger hinzufügen", this, true); … }` (PayersAndCostCenterAppModuleControllerViewModel.cs:231-234); Dialogverzweigung `if (this.PayersViewModel) { … this.PayersAndCostCenterAppModuleControllerViewModel?.CostObjectCollection.Add(costCentreDTO); } else { …CostCenterCollection.Add(costObjectDTO); }` (AddCostCenterOrPayersViewModel.cs:65-74).
Aussage: Die Software führt für den Kostenträger intern die englische Bezeichnung „Payers" (inkl. „Zahler"-Wortform im Wörterbuch, de_DE.dic:403781) und sammelt Kostenträger in einer `CostObjectCollection`, während `AddCostCenterOrPayersViewModel` die Variablennamen `costCentreDTO`/`costObjectDTO` vertauscht einsetzt.
Ergebnis: Domänenbegriff, Klassenbezeichnung und Füllrichtung der Sammlungen divergieren; Zuordnungsfehler in Wartung und Auswertung sind wahrscheinlich.
Belege: PRIMÄR – `src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerView.xaml:34`; `…/PayersAndCostCenterAppModuleControllerViewModel.cs:231-234`; `…/OpenDialog/AddCostCenterOrPayersViewModel.cs:51-74`; `src/centron/Centron.WPF.UI/Resources/Dictionaries/de_DE.dic:403781` („Zahler"), alle im Lauf gelesen.
Prüfidee: Dialog „Kostenträger hinzufügen" öffnen und prüfen, in welche Collection der neue Satz wandert; Begriffsinventur (Payers/Zahler/Kostenträger/CostObject) im Quellcode auszählen.
Tracelinks: SyRS:Kostenrechnung-UI, StRS:Kostenrechnung; SwRS-28
Konsolidierung: Kandidat (fall (b)) – „Zahler/Payers" (UI-Schicht, `PayersAndCostCenter*`) und „Kostenträger" (Domäne/Tabelle `Kostentraeger`, SwRS-28) bezeichnen denselben fachlichen Gegenstand in zwei getrennten Implementierungen; einheitliches Vokabular und eine Haltung erforderlich.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Begriffsklärung nötig
Status: belegt
ID: SwRS-30
Titel: Lizenz-Gate der Produktionsmodule
Ebene: SwRS
Typ: Constraint-/Zugriffsanforderung (Berechtigung/Lizenz)
Qualitätsmerkmal: Sicherheit, Prüfbarkeit
Akteur: `ProductionOrderBL`, `ProductionBL`, `ArticleProductionBL`
Vorbedingung: Produktionsauftrag wird angelegt/geändert
Fakt: Faktenbasis M024: Lizenz-Gate in `ProductionOrderBL`/`ProductionBL`/`ArticleProductionBL`. Vergleichbare, verifizierte Gate-Form: ` => LicenseManager.Instance.HasLicense(LicenseGuids.X) || LicenseManager.Instance.HasLicense(LicenseGuids.Centron)` (ModuleRegistration.cs:421-448).
Aussage: Die Produktionskomponenten prüfen vor der Fachaktion eine Lizenz (Einzellizenz oder Sammel-Lizenz „Centron") und verweigern sonst.
Ergebnis: Ohne Lizenz kein Produktionsdatensatz; das Gate wirkt auf BL-Ebene und zusätzlich im UI-Registrierungspfad.
Belege: PRIMÄR (durchsetzende Stellen laut Faktenbasis, Methodennamen nicht gegengeprüft) – `ProductionOrderBL`, `ProductionBL`, `ArticleProductionBL` (M024). KONTEXT/PRIMÄR – `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:421-448` (Gate-Muster im Lauf geprüft).
Prüfidee: Lizenz entfer nen und BL-Aufruf direkt (ohne UI) testen; UI-Pfad gegen BL-Pfad vergleichen.
Tracelinks: SyRS:Lizenzsteuerung, StRS:Lizenzierung;, SwRS-1
Konsolidierung: kein Fall – dasselbe Gate-Muster, aber unterschiedliche Fachdomänen; keine zwei Implementierungen desselben Gegenstands.
Übernahmewürdigkeit: übernehmen - mittlere Priorität - BL-Prüfstelle zeilengenau belegen
Status: HYPOTHESE
ID: SwRS-31
Titel: Preisimport in Projektpreise über die Import-ViewModel
Ebene: SwRS
Typ: Funktionsanforderung (interne Umrechnungsvorschrift, Preis)
Qualitätsmerkmal: Genauigkeit, Richtigkeit
Akteur: `ProjectPriceImportViewModel`
Vorbedingung: Preisdatensätze liegen als Importzeilen vor
Fakt: Faktenbasis M025 verweist auf `ProjectPriceImportViewModel` Zeilen 377-452 als Stelle der Preisübernahme.
Aussage: Die Importkomponente überträgt eingelesene Preise in die Projektpreishaltung und wendet dabei eigene Validierungs- und Rundungsregeln an; die Preisbildung folgt nicht dem Pfad `ReceiptPriceHelper.CalculateNetPrice`.
Ergebnis: Projektpreise können von der regulären Belegpreisberechnung abweichen; die Abweichung ist ausschließlich durch diese ViewModel-Regeln begründet.
Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenz übernommen, im Lauf nicht gegengeprüft) – `ProjectPriceImportViewModel.cs:377-452` (M025).
Prüfidee: identische Preis-/Rabbattpaare einmal über Import, einmal über Belegpreisberechnung (SwRS-16) ermitteln und vergleichen.
Tracelinks: SyRS:Projektpreise, SyRS:Preisformel, StRS:Preisbildung; SwRS-16, SwRS-17
Konsolidierung: Kandidat – zwei Preisbildungsimplementierungen für denselben fachlichen Gegenstand (Preis eines Artikels in einem Vertrag): `ReceiptPriceHelper` (Belege) vs. `ProjectPriceImportViewModel` (Projektpreise); Zusammenführung auf eine Preisbibliothek.
Übernahmewürdigkeit: übernehmen - mittlere Priorität
Status: HYPOTHESE
ID: SwRS-32
Titel: Mindestbestandsgesteuerte Bestellvorschlagsliste per Roh-SQL
Ebene: SwRS
Typ: Funktionsanforderung (interner Algorithmus)
Qualitätsmerkmal: Richtigkeit, Vollständigkeit
Akteur: `OrderSuggestionListBL`, Views `cvw_ArticleCount`
Vorbedingung: Artikel mit `Abbuchung = 'J'` oder `IsObligatoryBooking = 1` und `StkListe = 0`
Fakt: Wörtlich (Auszug): `SELECT A.I3D ArticleI3D, -1 WarehouseI3D, a.Mindestbestand MinimumQuantity … INNER JOIN cvw_ArticleCount ac ON ac.ArtikelI3D = a.I3D AND ac.LagerI3D = -1 and ac.cnt < a.Mindestbestand + IsNull(ab.duration,0) WHERE (A.Abbuchung = 'J' or A.IsObligatoryBooking = 1) AND A.StkListe = 0` und analog für Nebenlager mit `NLA.Mindestbestand`, `WH.WarehouseKind = 0 AND WH.IsActive = 1` (OrderSuggestionListBL.cs:139-159); offene Auftragsmenge `SUM(ap.Stk - ISNULL(ap.Liefermenge,0)) … WHERE ak.Status = 1`.
Aussage: Ein Artikel wird vorgeschlagen, wenn die Bestandsmenge (`cnt`) kleiner ist als Mindestbestand plus offener, noch nicht gelieferter Auftragsmenge; Haupt- und Nebenlager werden über `UNION ALL` getrennt betrachtet.
Ergebnis: Die Vorschlagsliste enthält genau die unterdeckten Artikel je Lagerort; Artikel ohne Abbuchungsf lag oder mit `StkListe = 1` werden nie vorgeschlagen.
Belege: PRIMÄR – `src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs:139-159`, SQL wörtlich zitiert (im Lauf geprüft).
Prüfidee: Unterdeckungs- und Überdeckungsfälle je Lager erzeugen; offenen Auftrag mit Teillieferung anlegen und `duration`-Einfluss nachrechnen.
Tracelinks: SyRS:Bestellvorschlag, StRS:Beschaffung; SwRS-24, SwRS-41
Konsolidierung: Kandidat (Verdacht) – Bestands-/Statusauswertung existiert doppelt: `cvw_ArticleCount` (hier) und `cvw_BarcodeCount` mit Statusfilter 1/2/8 (Faktenbasis M034, SwRS-41); dieselbe fachliche Kennzahl „verfügbarer Bestand" in zwei View-Implementierungen.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-33
Titel: QM-Meldungsart als Enum, Anlagen grund dagegen nur UI-seitig
Ebene: SwRS
Typ: Daten-/Mappinanforderung
Qualitätsmerkmal: Konsistenz
Akteur: `QmNotification` (Enum), `AssetReason`
Vorbedingung: QM-Meldung wird erfasst
Fakt: Faktenbasis M027: `QmNotification` mit Enum-Codierung, `AssetReason` nur im UI geführt.
Aussage: Die Art der QM-Meldung wird softwareintern über einen Enum abgebildet und persistiert; der Anlagen grund wird ausschließlich in der Oberfläche geführt und ist nicht Bestandteil der durchgesetzten Datenhaltung.
Ergebnis: Auswertung und Schnittstellen kennen nur den Enum-Wert; der Anlagen grund geht beim Persistieren verloren.
Belege: PRIMÄR (durchsetzende Stellen laut Faktenbasis, Dateiverweise im Lauf nicht einzeln aufgelöst) – `QmNotification`, `AssetReason` (M027).
Prüfidee: QM-Meldung mit Anlagen grund speichern und Datenbankeintrag prüfen (Feld fehlt/belegt?).
Tracelinks: SyRS:QM-Meldung, StRS:Qualitaetssicherung; SwRS-45
Konsolidierung: Kandidat (Prüfung offen) – Anlagen-/Gerätebezug wird hier UI-seitig geführt, während Geräte-/Asset-Daten in `AssetManagement*` gehalten werden (SwRS-45); möglicher Doppelhaltungsfall.
Übernahmewürdigkeit: übernehmen - mittlere Priorität
Status: HYPOTHESE
ID: SwRS-34
Titel: Report-Strukturkaskade ohne fremdschlüsselgesicherte Kindobjekte
Ebene: SwRS
Typ: Daten-/Funktionsanforderung
Qualitätsmerkmal: Konsistenz
Akteur: `ReportDataBL`, Tabellen `Report_Reports`, `Report_ReportQueries`
Vorbedingung: Report-Struktur (Eltern/Kind) wird geändert
Fakt: Faktenbasis M028 verweist auf `ReportDataBL` Zeilen 390-429 (Kaskade) und darauf, dass `Report_Reports`/`Report_ReportQueries` ohne FK ausgeführt sind;对照end existiert für ein anderes Reportobjekt ein Check-Constraint als durchgesetzte Regel: `ALTER TABLE [dbo].[ReportPrintOptions] WITH CHECK ADD CONSTRAINT [CK_ParentReference] CHECK (([ParentI3D] IS NULL AND [ParentObjectKind] IS NULL OR [ParentI3D] IS NOT NULL AND [ParentObjectKind] IS NOT NULL));` (SSMS_DB_SCHEMA.sql:68226).
Aussage: Die Reportkomponente hält Eltern-/Kindbeziehungen durch eigenen Code kaskadiert; die Tabellen sichern diese Beziehung weder per FOREIGN KEY noch einheitlich per CHECK-Constraint, im Unterschied zu `ReportPrintOptions`.
Ergebnis: Verwaiste Reportkinder sind bei Direktänderung oder Codefehlern möglich; die Kaskadenregel ist nur im Programmablauf wirksam.
Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:68226` (`CK_ParentReference`, durchgesetzte Regel als Vergleich) und Constraint-Inventur (10 CHECK/134 FK). PRIMÄR (Referenz aus Faktenbasis) – `ReportDataBL.cs:390-429` (M028).
Prüfidee: Elternreport per Direkt-SQL löschen und Kindstruktur prüfen; Kaskadenweg über `ReportDataBL` gegenlösen.
Tracelinks: SyRS:Berichtewesen, StRS:Auswertungen;, SwRS-37
Konsolidierung: Kandidat (Verdacht) – Eltern/Kind-Referenzregeln für Reportobjekte werden uneinheitlich in zwei Weisen durchgesetzt: Constraint in `ReportPrintOptions`, Code in `ReportDataBL`; Vereinheitlichung anstreben.
Übernahmewürdigkeit: übernehmen - mittlere Priorität
Status: HYPOTHESE
ID: SwRS-35
Titel: RMA-Fallbehandlung in der Kundenbereichskomponente
Ebene: SwRS
Typ: Funktionsanforderung
Qualitätsmerkmal: Richtigkeit
Akteur: `RmaBL`
Vorbedingung: RMA-Vorgang wird erzeugt/umgeschlagen
Fakt: Faktenbasis M029 verweist auf `RmaBL.cs` Zeilen 310-353. Ticketseitig existiert die Spalte `[IstRMAFall] [int] NULL` in `hlpdsk_requests` (SSMS_DB_SCHEMA.sql, Spaltliste ab Zeile 4521).
Aussage: Die RMA-Komponente führt ihre Vorgangslogik in `RmaBL` und ist über das nullbare Kennzeichen `IstRMAFall` mit Helpdesk-Tickets verbunden.
Ergebnis: RMA-Zuordnungen sind nicht verpflichtend und nicht constraintgesichert; die Fachregeln liegen vollständig im Code.
Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Methodennamen nicht gegengeprüft) – `src/backend/Centron.BL/CustomerArea/RmaBL.cs:310-353` (M029). KONTEXT/PRIMÄR – `SSMS_DB_SCHEMA.sql` `hlpdsk_requests.[IstRMAFall] [int] NULL`.
Prüfidee: RMA-Fall ohne Kennzeichen anlegen und RMA-Liste prüfen; Statusübergänge gegen Code nachstellen.
Tracelinks: SyRS:Ruecksendungen-RMA, StRS:Serviceabwicklung; SwRS-9, SwRS-24
Konsolidierung: kein Fall.
Übernahmewürdigkeit: übernehmen - niedrige Priorität - Regel­details fehlen
Status: HYPOTHESE
ID: SwRS-36
Titel: Ratings ohne Eindeutigkeitsregel; Mailing-Datenhaltung in Version 2
Ebene: SwRS
Typ: Daten-/Constraintanforderung
Qualitätsmerkmal: Konsistenz
Akteur: `ProductMatrixBL`, Tabelle `CustomerProductMatrixRating`; `MailingDataBL`
Vorbedingung: Produktmatrix-Rating wird gesetzt
Fakt: Schema: `CREATE TABLE [dbo].[CustomerProductMatrixRating]( [I3D] [int] IDENTITY(1,1) NOT NULL, … [CustomerProductMatrixProductI3D] [int] NOT NULL, [CustomerProductMatrixRatingValue] [int] NOT NULL, CONSTRAINT [PK_CustomerProductMatrixRating] PRIMARY KEY CLUSTERED ([I3D] ASC))` (SSMS_DB_SCHEMA.sql:36519-36528) — kein UNIQUE über `(CustomerProductMatrixProductI3D, …)`. Faktenbasis M030: `MailingDataBL` in Ausprägung „Version2".
Aussage: Pro Produktmatrix-Produkt sind mehrere Rating-Sätze zulässig, da die Einzigartigkeit weder per UNIQUE noch per Check erzwungen wird; die Mailingdatenhaltung liegt in einer Versions-2-Form vor.
Ergebnis: Doppelbewertungen desselben Produkts sind persistierbar; Aggregatwerte (Mittelwerte) sind ohne weitere Regel nicht reproduzierbar.
Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:36519-36528` (PK ohne UNIQUE; Constraintlage als durchgesetzte Regel, im Lauf gelesen). PRIMÄR (Referenz aus Faktenbasis) – `MailingDataBL` („Version2", M030).
Prüfidee: Zwei Ratings für dasselbe Produkt einfügen (Erfolg erwarten); Aggregation der Bewertungsanzeige kontrollieren.
Tracelinks: SyRS:Produktmatrix, SyRS:Mailing, StRS:Marketing
Konsolidierung: Kandidat (Prüfung offen) – Bewertungs-/Ratingdaten werden zusätzlich in anderen Produkt-Matrix-Tabellen (`CustomerProductMatrixProducts`, `…ChangeLogs`) gehalten; Verhältnis „aktueller Wert" vs. „Änderungshistorie" ist fachlich zu einem Konzept zu führen.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-37
Titel: Rechtsgesteuerte Erzeugung von Statistikdatenquellen
Ebene: SwRS
Typ: Funktions-/Zugriffsanforderung (Berechtigung)
Qualitätsmerkmal: Sicherheit, Vollständigkeit
Akteur: `StatisticDataSourceFactory.Create`
Vorbedingung: Statistikmaske wird geöffnet, Benutzerrechte liegen im `CentronCache`
Fakt: `if ((!type.HasValue || type.Value == StatisticTypes.SaleStatistic) && CentronCache.Instance.CurrentUserAppRights.Any(f => f.I3D == UserRightsConst.Controlling.Analytics.SALES_STATISTIC))` … `statistics.Add(articleSales); foreach (var child in articleSales.LoadChildren) statistics.Add(child);` und analog `TICKET_STATISTIC` für `TicketStatisticDataSourceViewModel` (StatisticDataSourceFactory.cs:26 ff.).
Aussage: Datenquellen werden nur erzeugt, wenn das zugehörige Auswertungsrecht im lokal gecachten Rechtsbestand des Benutzers enthalten ist; Kinddatenquellen erben die Prüfung nicht separat, sondern hängen an der Elternprüfung.
Ergebnis: Ohne Recht erscheint die Statistik nicht in der Maske; die Prüfung beruht auf dem Client-Cache, dessen Inhalt aus der Server-Rechteauflösung nach SwRS-1 stammt.
Belege: PRIMÄR – `src/centron/Centron.WPF.UI/Modules/Statistics/SaleStatistics/DataSources/StatisticDataSourceFactory.cs:26-128`, Bedingungscode im Lauf gelesen.
Prüfidee: Recht entziehen, Client-Cache halten/neu aufbauen und Datenquellenliste vergleichen; Serverseitige Zweitprüfung (Fehlend = Risiko) dokumentieren.
Tracelinks: SyRS:Auswertungen, SyRS:Rechteverwaltung, StRS:Rechteverwaltung; SwRS-1, SwRS-34
Konsolidierung: Kandidat (Verdacht) – Zugriffsfilterung wird einerseits über `CentronCache.Instance.CurrentUserAppRights.Any(...)` (Factory), andererseits über `Helper.HasRights(...)` in `ModuleRegistration` ausgedrückt; dieselbe Fachregel „Recht nötig" in zwei Client-Implementierungen.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-38
Titel: Umfrageveröffentlichung mit zwei Regelträgern und FK-gesichertem Prozessbezug
Ebene: SwRS
Typ: Funktions-/Constraintanforderung
Qualitätsmerkmal: Konsistenz, Richtigkeit
Akteur: `SurveyMainViewModel`, `SurveyProcessBL`, Tabelle `SurveyProcessProperties`
Vorbedingung: Umfrage soll veröffentlicht bzw. ein Prozess bearbeitet werden
Fakt: Faktenbasis M032 nennt als Regelträger `SurveyMainViewModel` Zeilen 498-511 und `SurveyProcessBL` Zeilen 680-704. Primär gesichert ist der Datenbezug: `ALTER TABLE [dbo].[SurveyProcessProperties] WITH CHECK ADD CONSTRAINT [FK_SurveyProcessProperties_Surveys] FOREIGN KEY([SurveyI3D])` (SSMS_DB_SCHEMA.sql:68152); Spalte `[SurveyI3D] [int] NOT NULL` (Zeile 52095), `[IsTemplate] [bit] NOT NULL` (Zeile 52092).
Aussage: Die Veröffentlichungslogik ist zweigeteilt zwischen Client-ViewModel und Business-Layer, während die Zugehörigkeit eines Umfrageprozesses zu exactly one Umfrage hart durch FK mit `WITH CHECK` und NOT NULL erzwungen wird.
Ergebnis: Verwaiste Umfrageprozesse sind ausgeschlossen; abweichende Veröffentlichungsregeln zwischen Client- und BL-Weg sind möglich, weil beide Stellen Regeln enthalten.
Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:68152` (FK `WITH CHECK`) und `:52090-52109` (Spaltendefinitionen), im Lauf gelesen. PRIMÄR (Referenzen aus Faktenbasis, Codezeilen nicht gegengeprüft) – `SurveyMainViewModel.cs:498-511`, `SurveyProcessBL.cs:680-704` (M032).
Prüfidee: Umfrageprozess ohne zugeordnete Umfrage einfügen (FK-Fehler erwarten); Veröffentlichung einmal über UI, einmal über BL/Webservice auslösen und Ergebnisse vergleichen.
Tracelinks: SyRS:Umfragen, StRS:Marktforschung;, SwRS-20
Konsolidierung: Kandidat – Veröffentlichungs-/Freigaberegeln derselben Umfrage liegen in zwei Implementierungen (Client `SurveyMainViewModel`, BL `SurveyProcessBL`); im Zielsystem in die BL-Ebene verlagern.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-39
Titel: Telekom-Dive-Mapping ohne Tabellenpräsenz im Schema-Dump
Ebene: SwRS
Typ: Datenanforderung / Mapping-Constraint
Qualitätsmerkmal: Konsistenz, Portabilität
Akteur: `TelekomDiveProfileMaps` (NHibernate-Mapping)
Vorbedingung: Telekom-Dive-Profil wird persistiert
Fakt: Faktenbasis M033: `TelekomDiveProfileMaps` mit `Not.Nullable`-Mappings, Tabelle nicht im Dump. Verifiziert: Im `SSMS_DB_SCHEMA.sql` existiert keine Tabelle mit Telekom-Bezug; vorhanden sind lediglich Spalten auf anderen Tabellen, z. B. `[TelekomReferenceNumber] [nvarchar](255) NULL`, `[TelekomDiveComment] [nvarchar](300) NULL`, `[IsTelekomDiveCommentActive] [bit] NULL` (Zeilen 3774-3776) und `[TelekomDiveMaterialGroup] [int] NULL` (Zeilen 9652, 10266) — insgesamt nur 5 Vorkommen von „Telekom" im Dump.
Aussage: Die Software erwartet ein PROFILartiges Telekom-Dive-Objekt mit nicht-nullbaren Feldern, das im ausgelieferten Schema nicht angelegt ist; Telekom-Dive-Daten existieren im Dump nur als einzeln nullbare Fremdspalten.
Ergebnis: Beim Einsatz gegen diesen Schema-Stand schlägt die Profilpersistenz fehl (fehlende Tabelle/Constraintkonflikt); eine Abbildung auf die vorhandenen Spalten ist nicht definitionsgemäß.
Belege: PRIMÄR (Negativbeleg) – `SSMS_DB_SCHEMA.sql`, Suche „Telekom" = 5 Treffer, keine `CREATE TABLE … Telekom …`; Spaltenzitate Zeilen 3774-3776, 9652, 10266. PRIMÄR (Referenz aus Faktenbasis) – `TelekomDiveProfileMaps` (M033).
Prüfidee: Schema mit Mapping-Definition abgleichen (NHibernate-Schema-Validierung); Profilspeicherung gegen Dump-Datenbank ausführen und Fehlerbild aufnehmen.
Tracelinks: SyRS:Telekom-Schnittstelle, StRS:Artikelstamm; SwRS-55
Konsolidierung: Kandidat (Prüfung offen) – Telekom-Attribute liegen verteilt auf Artikel-/Positionstabellen, während ein eigenes Profilobjekt gemappt ist; zwei Haltungen für denselben Gegenstand.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Migrationsrisiko
Status: belegt
ID: SwRS-40
Titel: Fortschreibung des Artikel-EK als gewichteter Durchschnitt
Ebene: SwRS
Typ: Funktionsanforderung (Berechnungsvorschrift, Preis/EK)
Qualitätsmerkmal: Genauigkeit, Richtigkeit
Akteur: `ArticleStockBL.UpdateArticlePurchasePrice`
Vorbedingung: Wareneingangsposition mit Menge und EK; Artikel ohne Sondervereinbarung
Fakt: Sondervereinbarung: `if (item.SpecialAgreementI3D > 0) { return Result.AsSuccess; }` (Zeilen 77-80). Fixer EK: `if (article.NoMixedEk == PurchasePriceAsKind.FixedPurchasePrice) return Result.AsSuccess;` (Zeilen 87-88). Zuschlag: `decimal purchasePriceMod = (purchasePrice + freightAmount + insuranceAmount) * calcFactor;` (Zeile 118). Fallunterscheidung: `if (oldQuantity <= 0) { newPurchasePrice = purchasePriceMod; }` … `if (article.NoMixedEk == PurchasePriceAsKind.LastPurchasePrice) { newPurchasePrice = purchasePriceMod; }` … `decimal additionalAmount = Math.Round(purchasePriceMod * (quantity - oldQuantity), article.Precision, MidpointRounding.AwayFromZero); newPurchasePrice = ((oldPurchasePrice * oldQuantity) + additionalAmount) / quantity;` (Zeilen 120-139).
Aussage: Der Artikel- bzw. Lager-EK wird als Mischpreis fortgeschrieben, sofern kein fixer EK und keine Sondervereinbarung vorliegen; Fracht und Versicherung gehen über den Kalkulationsfaktor in den Zuschlag ein; die Division erfolgt auf `quantity`, nicht auf die Summe aus altem und neuem Bestand.
Ergebnis: Der fortgeschriebene EK ist reproduzierbar durch diese Formel; bei Teilmengenabgängen (`quantity` kleiner als alter Bestand) weicht der Wert vom klassischen gewichteten Durchschnitt ab.
Belege: PRIMÄR – `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, `UpdateArticlePurchasePrice`, Zeilen 74-144, Formeln wörtlich zitiert (im Lauf geprüft).
Prüfidee: Goldtestfälle: alte Menge 0; `LastPurchasePrice`; Mischpreis mit `oldQuantity=10, quantity=15, calcFactor=1.05, Fracht/Versicherung`; Ergebnis gegen die zitierte Formel und gegen einen Referenz-Mischpreis vergleichen.
Tracelinks: SyRS:Artikel-EK-Fortsetzung, SyRS:Preisformel, StRS:Preisbildung; SwRS-16, SwRS-24, SwRS-41
Konsolidierung: Kandidat – EK-Ermittlung zweigleisig: Mischpreisfortschreibung hier (Lager/Artikel) und Preisstammdatenpflege je Einkaufspreisart über `PurchasePriceAsKind`-Enum; fachlich ein „Einstandspreis"-Konzept, zwei Regelträger.
Übernahmewürdigkeit: übernehmen - hohe Priorität - preisbestimmend
Status: belegt
ID: SwRS-41
Titel: Artikelprüfung ohne Check-Constraints; Statusfilter in Bestandsviews
Ebene: SwRS
Typ: Constraint-/Datenanforderung
Qualitätsmerkmal: Vollständigkeit, Konsistenz
Akteur: Tabelle `ARTIK` (ARTIK), Views `cvw_ArticleCount`, `cvw_BarcodeCount`
Vorbedingung: Artikelstammdaten werden geändert
Fakt: Constraint-Inventur des Dumps: 1558 Tabellen, 134 `FOREIGN KEY`, 38 `UNIQUE`, genau 10 `CHECK`-Constraints (im Lauf ausgezählt); die 10 CHECK-Constraints betreffen `AccountActivities`, `ReceiptProvisionEmployeeGoals`, `ReceiptProvisionItems`, `ReceiptProvisionSchemaItems`, `ReportPrintOptions` (SSMS_DB_SCHEMA.sql:68190-68226) — kein CHECK auf `ARTIK`/Artikel. Faktenbasis M034: „Artikel NOT NULL ohne CHECK", Views `cvw_ArticleCount`/`cvw_BarcodeCount` mit Status 1/2/8.
Aussage: Artikelwerte sind lediglich über NOT NULL abgesichert, inhaltliche Wertebereiche (Mengen, Kennzeichen) werden nicht durch Check-Constraints erzwungen; die Bestandsauswertung filtert Statusmengen (1/2/8) ausschließlich in den Views.
Ergebnis: Inhaltlich fehlerhafte Artikelwerte sind persistierbar; Bestands- und Barcode-Auswertungen hängen an den View-Definitionen und deren Statusmengen.
Belege: PRIMÄR (Constraint-Inventur) – Auszählung gegen `SSMS_DB_SCHEMA.sql`: `CREATE TABLE` = 1558, `FOREIGN KEY` = 134, `UNIQUE` = 38, `CHECK` = 10; Vollständigkeit der CHECK-Liste durch Zitat der zehn `ALTER TABLE … WITH CHECK ADD CONSTRAINT [CK_*/Check_*]`-Zeilen 68190, 68194, 68198, 68202, 68206, 68210, 68214, 68218, 68222, 68226. KONTEXT – Faktenbasis M034 (Views `cvw_ArticleCount`/`cvw_BarcodeCount`, Status 1/2/8).
Prüfidee: Negativwerte/ungültige Kennzeichen in Artikel speichern (Erfolg erwarten); View-Definitionen auf Statusfilter prüfen und identische Kennzahlen gegenüberstellen.
Tracelinks: SyRS:Artikelstamm, StRS:Artikelstamm; SwRS-32
Konsolidierung: Kandidat – Statusfilterlogik (Status 1/2/8) liegt doppelt vor: in `cvw_ArticleCount` und `cvw_BarcodeCount`; dieselbe fachliche Gültigkeitsregel für zwei Kennzahlen getrennt implementiert, zusammenführbar.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-42
Titel: Webaccount-Login mit unsalzigem SHA1-Kennworthash
Ebene: SwRS
Typ: Funktions-/Constraintanforderung (Sicherheit, Authentisierung)
Qualitätsmerkmal: Sicherheit, Richtigkeit
Akteur: `WebAccountBL.LoginWithWebAccount`
Vorbedingung: Login-Versuch mit Benutzername/Kennwort
Fakt: `string cryptedPw = SHA1Decoder.GetDecodedSHA1String(password);` gefolgt von `GetEntity(f => f.Status == 1 && f.Username.ToUpper == username.ToUpper && f.Password == cryptedPw);` (WebAccountBL.cs:56-61); danach Aktivitätsprüfungen der Kontaktdaten/Kunden bzw. Kontoadresse (`contact.State != 1`, `IsCustomerActiveAndNotLocked`, `address.Data.IsActive`) mit Rückgabe `null` bei Abweichung (Zeilen 68-99) und Login-Protokollierung `account.LastLoginIP = IpAddressHelper.GetIpAddress?.ToString ?? "[unbekannt]"; account.LastLoginDate = DateTime.Now;` (Zeilen 101-103).
Aussage: Die Authentisierung vergleicht den eingegebenen Kennwert gegen einen SHA1-Hash ohne Salt in der Spalte `WebAccount.Password`, ignoriert die Groß-/Kleinschreibung des Benutzernamens und schreibt IP-Zeitstempel zurück; ein Rechte- oder Zwei-Faktor-Zwang ist in diesem Pfad nicht enthalten.
Ergebnis: Kennworthashes sind anfällig für vorwärtsberechnete Vergleiche; der Login ist allein durch Passwortwert und Aktivitätsstatus entschieden.
Belege: PRIMÄR – `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, `LoginWithWebAccount`, Zeilen 54-105, Code wörtlich zitiert (im Lauf geprüft).
Prüfidee: Bekannter SHA1-Testwert in `WebAccount.Password` hinterlegen und Login durchführen; Hashverfahren (SHA1, kein Salt) aus Code und Daten nachweisen; `Status != 1`-Fall prüfen.
Tracelinks: SyRS:Weblogin, StRS:Rechteverwaltung; SwRS-1, SwRS-43
Konsolidierung: Kandidat – Authentisierungsdatenhaltung dreifach: `WebAccount.Password` (SHA1, hier), `AppUser.Password → BenutzerInfo2` (SwRS-3) und `MailScannerProfile.Password`/`MailPassword` (SwRS-47); drei Umsetzungen eines Kennworthash-/speicherkonzepts.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Sicherheitsrisiko
Status: belegt
ID: SwRS-43
Titel: Zwei-Faktor-Prüfung hinter Konfigurations- und Benutzerschaltern; Webrechte ohne Verbundschlüssel
Ebene: SwRS
Typ: Funktions-/Constraintanforderung (Sicherheit)
Qualitätsmerkmal: Sicherheit, Nachvollziehbarkeit
Akteur: `TwoFactorAuthBL`, Tabellen `WebAccountsRights`, `WebRights`
Vorbedingung: Authentisierungsvorgang mit `applicationName`/`machineName`
Fakt: `if (WebServiceConfigHelper.Current.TwoFactorAuthEnabled == false) { Logger.Trace("Two-factor-auth is not enabled, …"); return Result.AsSuccess; }` (TwoFactorAuthBL.cs, Konfigurations-Gate) und `if (user.UseTwoFactorAuthentication == false) { Logger.Trace("Two-factor-auth is not enabled for user {User}", user); return false; }` (HasToValidateTwoFactor), gültige Pins schließlich über `Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin(appUserTwoFactorAuthKeyResult.Data, authenticationPin)` (TwoFactorAuthenticationBL.cs:51). Schema: `CREATE TABLE [dbo].[WebAccountsRights]( [I3D] [int] IDENTITY(1,1) NOT NULL, [WebAccountsI3D] [int] NULL, [WebRightsI3D] [int] NULL, PRIMARY KEY CLUSTERED ([I3D] ASC))` (SSMS_DB_SCHEMA.sql:54877-54885), Tabelle `WebRights` ab Zeile 55165.
Aussage: Zwei-Faktor wird übersprungen, sobald entweder die Konfiguration oder der Benutzer schalterseitig deaktiviert; die Webrechte-Zuordnungstabelle besitzt nur einen surrogate PK, beide Beziehungsspalten sind nullbar, UNIQUE und FOREIGN KEY fehlen.
Ergebnis: Ein Webaccount kann mehrfach dieselbe Recht erhalten oder Rechte ohne Bezug tragen; der 2FA-Zwang ist ohne Konfigurationsänderung nicht erzwingbar.
Belege: PRIMÄR – `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs` (Config-/User-Gate) und `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs:51` (im Lauf gelesen). PRIMÄR – `SSMS_DB_SCHEMA.sql:54877-54885` (PK/NULLBARKEIT ohne UNIQUE/FK als durchgesetzte Regel).
Prüfidee: `TwoFactorAuthEnabled=false` setzen und Login prüfen; doppelte Rechtzeile in `WebAccountsRights` einfügen (Erfolg erwarten); identische Rechte doppelt auflösen (SwRS-1 beachten).
Tracelinks: SyRS:Weblogin, SyRS:Rechteverwaltung, StRS:Rechteverwaltung; SwRS-1, SwRS-42
Konsolidierung: Kandidat – Rechtezuordnung wird zweigleisig geführt: `Sichmemb`/`Sichtrus` für App-User (SwRS-1) und `WebAccountsRights`/`WebRights` für Webkonten (AppRightsBL.cs:681-683); dasselbe Rechtetzukonzept, zwei Haltungen.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-44
Titel: Bereinigungsinspektor mit ausgenommener Asset-Zuordnungstabelle
Ebene: SwRS
Typ: Funktionsanforderung (softwareinterne Datenbankpflege) + Constraint
Qualitätsmerkmal: Zuverlässigkeit, Sicherheitskontrolle
Akteur: `RiverbirdTablesCleanupInspector`
Vorbedingung: Inspektor wird in den Centron-Inspectors ausgeführt
Fakt: Tabellenkandidaten per System-Sicht: `WHERE (t.name LIKE 'AssetManagement%' OR t.name LIKE 'DocumentationWizard%' … OR t.name LIKE 'RiverbirdAgentDeployment%') AND t.name <> 'AssetManagementArticleAssignment' AND rc.total_rows > 0` (RiverbirdTablesCleanupInspector.cs:36-48); Ablaufkommentar: „2. FKs droppen, damit TRUNCATE zulaessig ist. 3. Tabellen aus @tableList truncaten. 4. FKs wiederherstellen: - Parent in @tableList -> WITH CHECK …"; Escaping `n.Replace("'", "''")` (Zeilen 50-55).
Aussage: Der Inspektor truncatet Befundtabellen der Riverbird-/Dokumentationsmodule, nimmt die Artikelzuordnung `AssetManagementArticleAssignment` ausdrücklich aus und stellt die Fremdschlüssel nach dem Truncate mit `WITH CHECK` wieder her.
Ergebnis: Inventurbestände können maschinell geleert werden, ohne die Artikel-Asset-Verknüpfung zu zerstören; die wiederhergestellten FKs werden wieder geprüft.
Belege: PRIMÄR – `src/centron/Centron.WPF.UI/Modules/MyCentron/CentronInspectors/Inspectors/Database/RiverbirdTablesCleanupInspector.cs:36-48, 50-62`, SQL und Kommentare wörtlich zitiert (im Lauf geprüft).
Prüfidee: Testdatenbank mit Befundzeilen und Assetzuordnung truncaten; prüfen, dass `AssetManagementArticleAssignment` Zeilen behält und FKs aktiv `WITH CHECK` vorliegen.
Tracelinks: SyRS:Systemwartung-Inspectors, StRS:Betrieb; SwRS-45
Konsolidierung: Kandidat (Partner zu SwRS-45) – `AssetManagement%`-Bestand ist löschbar gehalten, die fachliche Anlagezuordnung ist separiert; zwei getrennte Haltungen desselben Asset-Themas mit unterschiedlicher Löschstrategie.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-45
Titel: Parallele Hardwarehaltungen: Drucker/Geräte als Stammblatt einerseits, AssetManagement-Tabellen andererseits
Ebene: SwRS
Typ: Datenanforderung / Begriffszuordnung
Qualitätsmerkmal: Konsistenz, Vollständigkeit
Akteur: `MasterDataListBL`/`DeviceClickCounterBL` (Stammblatt) und `AssetManagementDevices`/`AssetManagementPrinter` (Inventar)
Vorbedingung: Drucker bzw. Kundenhardware wird erfasst oder abgerechnet
Fakt: Begriffsbildung: `case CentronObjectKindNumeric.MasterDataListClass: return "Stammblatt";` (CentronObjectKindNumeric.cs:314); Zähler hängen am Stammblatt über `GetClickCounterFromMasterDataListId(int masterDataListId) → GetList(f => f.DeviceHeaderI3D == masterDataListId)` (DeviceClickCounterBL.cs:82-84); REST-Beschreibung spricht vom „Stammblatt" als Hauptgeräte-Datensatz (ICentronRestService.Receipts.cs:1373, 1379). Parallel existieren Inventarhaltungen `CREATE TABLE [dbo].[AssetManagementDevices]` (SSMS_DB_SCHEMA.sql:6050) und `CREATE TABLE [dbo].[AssetManagementPrinter]( [I3D] …, [DeviceI3D] [int] NOT NULL, [Name] [nvarchar](256) NULL, [ShareName] [nvarchar](256) NULL, [PrintProcessor] [nvarchar](256) NULL, [PrinterStatus] [int] NULL, [PrinterState] [int] NULL, [JobCountSinceLastReset] [int] NULL, [DriverName] [nvarchar](256) NULL, …)` (Zeilen 30473-30496).
Aussage: Drucker werden fachlich als „Stammblätter" (MasterDataList/Gerätekopf) geführt und dort für Zähler/Abrechnung verwendet; derselbe Gegestand existiert zusätzlich als Inventarzeile in `AssetManagementPrinter`/`AssetManagementDevices` mit eigenem Druckerzustandsmodell.
Ergebnis: Es gibt zwei Adressierarten für ein physisches Gerät; Seriennummern-/Zählerpflege und Inventarzustand können auseinanderlaufen, da kein Constraint die Identität verknüpft.
Belege: PRIMÄR – `CentronObjectKindNumeric.cs:314`; `DeviceClickCounterBL.cs:82-84`; `ICentronRestService.Receipts.cs:1373, 1379`; `SSMS_DB_SCHEMA.sql:6050` (`AssetManagementDevices`), `:30473-30496` (`AssetManagementPrinter`) — alle im Lauf gelesen.
Prüfidee: identischen Drucker in beiden Haltungen anlegen (Seriennummer/Name) und Konsistenzprüfung versuchen; Zählerpflege und Inventarzustand unabhängig ändern und Auswertung vergleichen.
Tracelinks: SyRS:Geruete-und-Assets, StRS:Serviceabwicklung; SwRS-12, SwRS-44, SwRS-33
Konsolidierung: Kandidat (fall (a)) – „Drucker als Stammblatt" (`MasterDataList`/`DeviceHeaderI3D`, Zähler-/Vertragslogik in DeviceClickCounterBL/HelpdeskTimer) vs. „sonstige Hardware als Asset" (`AssetManagementDevices`, `AssetManagementPrinter`, Riverbird-Cleanup in SwRS-44): zwei Datenhaltungen für denselben fachlichen Gegenstand, im Zielsystem zu einem Asset-Konzept zusammenzuführen.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Zielarchitektur-Entscheidung
Status: belegt
ID: SwRS-46
Titel: Telefonnummern-Normalisierung nach Tapi-Einstellungen
Ebene: SwRS
Typ: Funktionsanforderung (Berechnungsvorschrift/Transformation)
Qualitätsmerkmal: Richtigkeit, Konsistenz
Akteur: `TapiBL.FormatPhoneNumber`
Vorbedingung: Rufnummer (ggf. mit „+", Nicht-Ziffern) liegt vor
Fakt: `phoneNumber = Regex.Replace(phoneNumber, "[+]", "00"); phoneNumber = Regex.Replace(phoneNumber, "[^0-9]", string.Empty);` dann Einstellungsauswertung `AppSettingsConst.TapiAmtPrefix`, `TapiCountryPrefix`, `TapiReduceNumber`: `if (reduceNumbers && string.IsNullOrWhiteSpace(amtPrefix) == false && phoneNumber.StartsWith(amtPrefix)) phoneNumber = phoneNumber.Substring(amtPrefix.Length);` und `if (string.IsNullOrWhiteSpace(countryPrefix) == false && phoneNumber.StartsWith("00" + countryPrefix)) phoneNumber = "0" + phoneNumber.Substring(4);` (TapiBL.cs:82-143).
Aussage: Die Rufnummer wird zu einer reinen Ziffernfolge mit „00"-Länderkennung normalisiert; netzvorwahlenbasierte Verkürzung und Länderkennungs­ersetzung erfolgen nur, wenn die zugehörigen Einstellungen gesetzt sind bzw. `TapiReduceNumber == 1`.
Ergebnis: Anrufprotokollzuordnung arbeitet auf normalisierten Nummern; ohne Tapi-Einstellungen bleibt die international forma­tierte Ziffernfolge stehen.
Belege: PRIMÄR – `src/backend/Centron.BL/Accounts/TapiBL.cs`, `FormatPhoneNumber`, Zeilen 82-143, Code wörtlich zitiert (im Lauf geprüft). Faktenbasis M037 ergänzt `TelephonyCallLogViewModel` Zeile 130 als UI-Aufrufer.
Prüfidee: Goldwerte: „+49 30 123456", Nummern mit Nebenwahlbuchstaben, `TapiReduceNumber = 0/1`; Ergebnisse gegen die zitierten Transformationen prüfen.
Tracelinks: SyRS:Telefonie-Integration, StRS:Kommunikation; SwRS-25
Konsolidierung: Kandidat (Prüfung offen) – Rufnummernformatierung existiert zusätzlich in der Adress-/Kommunikationsschicht (Kontaktdatenpflege); gleiche Fachregel, zwei Implementierungen.
Übernahmewürdigkeit: übernehmen - mittlere Priorität
Status: belegt
ID: SwRS-47
Titel: Zwei Kennwortfelder im Mailscanner-Profil: Masterkey-verschlüsselt und unverschlüsselt
Ebene: SwRS
Typ: Funktions-/Constraintanforderung (Sicherheit)
Qualitätsmerkmal: Sicherheit, Konsistenz
Akteur: `MailScannerBL`, `MailScannerProfileMaps`, `MailScannerProfile`
Vorbedingung: VMA-Profil wird geladen oder gespeichert
Fakt: Verschlüsselung nur für zwei Felder: `var passwordResult = _centronConfigurationDbBl.EncryptWithMasterKey(profile.Password);` · `var secretResult = _centronConfigurationDbBl.EncryptWithMasterKey(profile.ClientSecret);` (MailScannerBL.cs:104-116) und analog `DecryptWithMasterKey` beim Laden (Zeilen 90-102); Rechthürde: `_appRightsBl.CheckRightsFromUser(loggedInUser.UserI3D.Value, UserRightsConst.VirtualMailAssistant.ACCESS_VMA_MODULE)` mit Fehler „Fehlendes Recht VMA Profile zu laden" (Zeilen 59-62). Mapping ohne Verschlüsselung: `this.Map(f => f.MailPassword).Column("MailPassword").Length(int.MaxValue).Nullable;` (MailScannerProfileMaps.cs:20); Entität führt beide Felder: `public virtual string MailPassword { get; set; }` (Zeile 15) und `public string Password { get; set; }` (Zeile 20); DDL: `[MailPassword] [nvarchar] (MAX) NULL,` (SQLScriptCollection3.xml:19675). DTO-Weitergabe unverschlüsselt: `entity.MailPassword = item.MailPassword;` (MailScannerWebServiceBL.cs:105).
Aussage: Das Profil besitzt zwei Kennwortattribute; nur `Password` (und `ClientSecret`) durchlaufen Masterkey-Verschlüsselung, `MailPassword` wird im Klartext in einer `nvarchar(max)`-Spalte persistiert und über DTOs weitergereicht.
Ergebnis: Postfach-Zugangsdaten liegen lesbar in der Datenbank und im Webservice-Verkehr vor; die Verschlüsselungsregel greift für dasselbe Konzept nur Feld-abhängig.
Belege: PRIMÄR – `src/backend/Centron.BL/MailScanner/MailScannerBL.cs:59-62, 90-116`; `src/backend/Centron.DAO/Mappings/MailScanner/MailScannerProfileMaps.cs:20`; `src/backend/Centron.Entities/Entities/MailScanner/MailScannerProfile.cs:15, 20`; `src/backend/Centron.BL/WebServices/MailScanner/MailScannerWebServiceBL.cs:105`; `SQLScriptCollection3.xml:19675` — alle im Lauf gelesen.
Prüfidee: Profil mit beiden Kennwörtern speichern und DB-Inhalte inspizieren (ein Feld Cipher-Base64, ein Feld Klartext); VMA-Recht entziehen und Fehlerpfad prüfen.
Tracelinks: SyRS:MailScanner-Profile, StRS:Rechteverwaltung; SwRS-27
Konsolidierung: Kandidat (fall (e)) – zwei Kennwortfelder desselben Profils mit zwei verschiedenen Durchsetzungsmechanismen (`Password` masterkey-verschlüsselt in `MailScannerBL.EncryptProperties`, `MailPassword` unverschlüsselt per Mapping, `MailScannerProfileMaps.cs:20`); auf ein Feld/einen Mechanismus zusammenführen.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Sicherheitsrisiko
Status: belegt
ID: SwRS-48
Titel: Social-Media-Bearbeitung ausschließlich über EmployeeI3D-Prädikat der Stored Procedures; zweigleisige Kind-Codierung in C#-Enum und T-SQL
Ebene: SwRS
Typ: Funktions-/Constraintanforderung (Berechtigung, Codierung)
Qualitätsmerkmal: Sicherheit, Konsistenz
Akteur: Stored Procedures spr_SocialMediaUpdateComment/RemoveComment/RemoveLike, Ansichten cvw_SocialMedia*, C#-Enum SocialMediaKind
Vorbedingung: Bearbeiter ändert oder löscht Kommentar/Like eines Streams oder einer Aktion
Fakt: Löschung `DELETE FROM SocialMediaComment WHERE EmployeeI3D = @EmployeeI3D AND I3D = @SocialMediaCommentI3D` mit Guard `if ISNULL(@EmployeeI3D,0) <= 0 begin RAISERROR(...,16,1)...` (SSMS_DB_SCHEMA.sql:73811-73818); Bearbeitung `UPDATE SocialMediaComment SET Text=@Comment, CreatedDate=CURRENT_TIMESTAMP WHERE EmployeeI3D=@EmployeeI3D...` (SSMS_DB_SCHEMA.sql:74061-74093); Kind-Codierung `public enum SocialMediaKind { SocialMediaStream=0, SocialMediaAction=1 }` (SocialMediaKind.cs:3-7) und erneut in T-SQL `CASE WHEN C.SocialMediaStreamI3D IS NOT NULL THEN 0 ELSE 1 END` (6 Fundstellen; 2 exakte CASE-Varianten, 6 Varianten insgesamt). Schema SocialMediaComment: beide Elternspalten und EmployeeI3D nullbar, kein FK/CHECK (SSMS_DB_SCHEMA.sql:8020-8031); FK nur auf CSI_*-Tabellen (:67802-67842).
Aussage: Änderung/Löschung werden nur durch das EmployeeI3D-Prädikat in den Stored Procedures erzwungen; die Haupttabellen tragen keine Eigentums-/Referenz-Constraints, Direkt-SQL umgeht die Regelung. Die Zuordnung Stream=0/Aktion=1 ist zweifach implementiert (C#-Enum und verteilte T-SQL-Klauseln); Bearbeiten setzt CreatedDate zurück, da kein Änderungsdatum existiert.
Ergebnis: Nur eigene Sätze änderbar, solange Zugriff über Prozeduren läuft; Direktzugriff ohne Durchsetzung. Editierung verschiebt Chronologie; Codierung 0/1 muss an allen T-SQL-Stellen synchron bleiben.
Belege: [PRIMÄR] SSMS_DB_SCHEMA.sql:73811-73818 (spr_SocialMediaRemoveComment), 74061-74093 (spr_SocialMediaUpdateComment); Centron.Interfaces\SocialMedia\SocialMediaKind.cs:3-7; SSMS_DB_SCHEMA.sql:8020-8031, 67802-67842.
Prüfidee: Kommentar mit EmployeeI3D A per SP mit @EmployeeI3D B löschen (0 Zeilen); Editierung und CreatedDate-Sprung prüfen; INSERT mit beiden Eltern-I3D per Direkt-SQL (Erfolg, kein CHECK).
Tracelinks: SyRS:Kommunikation-Chat (SyRS-12), StRS:Kommunikation (StRS-34); SwRS-25, SwRS-41, SwRS-53
Konsolidierung: Kandidat (Fall f) — SocialMediaKind doppelt: C#-Enum (SocialMediaKind.cs:3-7) und T-SQL-Fallunterscheidungen (6 Fundstellen; 2 exakte CASE-Varianten, 6 Varianten insgesamt); offen: SocialMedia*- vs. CSI_SocialMedia*-Tabellen.
Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheits- und migrationsrelevant
Status: belegt
ID: SwRS-49
Titel: Rechte-Cache ohne gefundenen Invalidierungspfad; Duplikate wandern in den gecachten Rechtsbestand
Ebene: SwRS
Typ: Funktions-/Constraintanforderung (Berechtigung, Caching) — Ergänzung zu SwRS-1
Qualitätsmerkmal: Sicherheit, Konsistenz, Zeitverhalten
Akteur: AppRightsBL mit Session.Advanced.Cache
Vorbedingung: Rechtebestand eines Benutzers wurde einmal aufgelöst; anschließend geändert
Fakt: `GetOrAdd($"AllRightsFromAppUser{appUserI3D}", => GetAllAppRightsFromUser(appUserI3D))` (AppRightsBL.cs:646) bzw. `...AllRightsFromWebAccount...` (Zeile 674); Schlüssel-Literale kommen nur in dieser Datei vor; kein Remove/Invalidate vorhanden; Menge ohne DISTINCT (Zeilen 653-656), Prüfung via rights.Contains (648, 676).
Aussage: Einmal aufgelöste Rechte bleiben für die Lebensdauer des Session-Caches unverändert, weil rechteändernde Methoden die Schlüssel nicht löschen; [HYPOTHESE] zur Cache-Lebensdauer (TTL nicht geprüft). Ohne DISTINCT/UNIQUE enthält die Liste bei Doppelzuweisung dieselbe Recht-ID mehrfach.
Ergebnis: Rechtsentzug/-ergänzung wirkt erst nach Cache-Neubindung; Doppelzuweisungen bleiben unbemerkt.
Belege: [PRIMÄR] AppRightsBL.cs Zeilen 644-664, 666-691 (GetOrAdd/Contains); Negativbeleg: Suche AllRightsFromAppUser/WebAccount nur in dieser Datei.
Prüfidee: Cache füllen, Recht entziehen, HasUserRight erneut → veraltetes „ja"; doppelte Zuweisungszeile und Listengröße zählen.
Tracelinks: SyRS:Berechtigungsprüfung (SyRS-49), StRS:Rechteverwaltung; SwRS-1, SwRS-50
Konsolidierung: kein Fall — Ergänzung zu SwRS-1 (anderer Aspekt: Cache-Lebenszyklus).
Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheitsrelevant (Trägheit von Rechtsänderungen)
Status: HYPOTHESE
ID: SwRS-50
Titel: Parallele Rechteauflösung für Webkonten über eigene Roh-SQL und eigenen Cache-Schlüssel
Ebene: SwRS
Typ: Funktionsanforderung (Berechtigungskomponente, zweiter Zweig)
Qualitätsmerkmal: Konsistenz, Richtigkeit, Sicherheit
Akteur: AppRightsBL.HasWebAccountRight / GetAllWebRightsFromWebAccount
Vorbedingung: WebAccount liegt vor; Session-Cache verfügbar
Fakt: `HasWebAccountRight` lädt `$"AllRightsFromWebAccount{webAccount.I3D}"` per GetOrAdd mit rights.Contains (AppRightsBL.cs:670-677); Menge aus `SELECT WebRightsI3D AS ID FROM WebAccountsRights WHERE WebAccountsI3D = :WebAccountI3D` (681-683) ohne DISTINCT; WebAccountsRights PK ohne UNIQUE/FK, beide Beziehungsspalten nullbar (SSMS_DB_SCHEMA.sql:54877-54885).
Aussage: Neben der AppUser-Auflösung über Sichtrus/Sichmemb (SwRS-1) betreibt die Komponente einen separaten Webkonto-Auflösungsweg mit eigener Tabelle, SQL und Cache; keine gemeinsame Datenhaltung.
Ergebnis: Webrechte unabhängig vom AppUser-Rechtebaum; Änderungen erst nach Cache-Neubindung; Regelpflege muss beide Wege synchron halten.
Belege: [PRIMÄR] AppRightsBL.cs:670-691 (SQL zitiert); SSMS_DB_SCHEMA.sql:54877-54885.
Prüfidee: Doppelte WebAccountsRights-Zeile einfügen (Erfolg); HasWebAccountRight vor/nach Änderung (Cache-Trägheit); Webkonto-Rechte gegen Sichmemb-Logik vergleichen.
Tracelinks: SyRS:Weblogin (SyRS-45), StRS:Rechteverwaltung; SwRS-1, SwRS-49
Konsolidierung: Kandidat — „Rechte eines Kontos auflösen" doppelt: AppUser-Zweig (653-656) und WebAccount-Zweig (681-683); auf ein Rechtemodell mit Kontotyp-Attribut zusammenführen.
Übernahmewürdigkeit: übernehmen - hohe Priorität
Status: belegt
ID: SwRS-51
Titel: Kennworthaltung dreifach: AppUser.Password→BenutzerInfo2, WebAccount ungesalzen SHA1, MailScanner doppelt
Ebene: SwRS
Typ: Daten-/Constraintanforderung (Sicherheit, Geheimnisaufbewahrung)
Qualitätsmerkmal: Sicherheit, Konsistenz
Akteur: AppUserMaps, WebAccountBL, MailScannerBL/MailScannerProfileMaps
Vorbedingung: Konten bzw. VMA-Profile werden mit Kennwerten angelegt/geprüft
Fakt: (1) `Map(appUser => appUser.Password).Column("BenutzerInfo2")` (AppUserMaps.cs:24, ohne Not.Nullable). (2) `cryptedPw = SHA1Decoder.GetDecodedSHA1String(password)` und Auswahl `f.Status==1 && f.Username.ToUpper==username.ToUpper && f.Password==cryptedPw` (WebAccountBL.cs:56-61) — SHA1 ohne Salt. (3) MailScannerProfile mappt MailPassword (Zeile 20) und Password (Zeile 26); nur Password/ClientSecret durchlaufen EncryptWithMasterKey (MailScannerBL.cs:104-116), MailPassword bleibt Klartext.
Aussage: Für denselben Gegenstand „Kennwert eines Kontos" unterhält die Software drei Haltungen mit drei Mechanismen (Altspalte ohne Pflichtdeklaration, ungesalzener SHA1, feldabhängige Masterkey-Verschlüsselung); vierte leere Haltung bei PasswordManagementKeyword (SwRS-27). Kein Constraint erzwingt Verfahren/Stärke/Nullbarkeit.
Ergebnis: Kennworthärtung pro Haltung unterschiedlich und nicht zentral erzwingbar; Migrationen müssen vier Spaltenformate abbilden.
Belege: [PRIMÄR] AppUserMaps.cs:24; WebAccountBL.cs:56-61; MailScannerProfileMaps.cs:20,26; MailScannerBL.cs:104-116.
Prüfidee: Muster-Datensatz je Haltung anlegen, DB-Werte vergleichen (Klartext/Hash/Cipher/leer); identisches Kennwort in allen drei Haltungen ablegen.
Tracelinks: SyRS:Benutzerverwaltung, SyRS:Weblogin, StRS:Zwei-Faktor-und-Kennworthaerte; SwRS-3, SwRS-27, SwRS-42, SwRS-47
Konsolidierung: Kandidat (Sammelfall zu e) — dreifache Implementierung „Kennworthaltung" (BenutzerInfo2, WebAccount SHA1, MailScanner doppelt); auf einen Mechanismus zusammenführen.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Sicherheitsrisiko
Status: belegt
ID: SwRS-52
Titel: Krypto-Schlüsselverwaltung mit eingebettetem Default-Schlüssel und aus demselben Hash abgeleitetem IV
Ebene: SwRS
Typ: Funktions-/Constraintanforderung (Kryptographie, Schlüsselverwaltung)
Qualitätsmerkmal: Sicherheit, Wartbarkeit
Akteur: AESCryptoLogic (Centron.Common.TextCoding) und alle verschlüsselnden Aufrufer
Vorbedingung: Ein Aufrufer verschlüsselt Vertrauliches
Fakt: `public string EncryptText(string text, string securityKey = null)` (AESCryptoLogic.cs:11); `SECURITY_KEY = @"lugE!35Djn"` und Rückfall bei leerem secret (77-81); key=SHA512(secret)[0..32], iv=SHA512(secret)[5..20] (83-91) — IV überlappt mit Schlüssel; Decodierfehler → leerer String (31-34). 51 Aufrufe new AESCryptoLogic, mind. 8 ohne Schlüssel (z. B. RmmConnectionSettingsBL.cs:70, PdfSigningBL.cs:87/90/100, SupplierEdiConfigurationsWebServiceBL.cs:74, CentronConfigurationDbBL.cs:72).
Aussage: Wo der optionale Schlüssel weggelassen wird, werden Produktionsgeheimnisse mit einem im Quellcode eingebetteten, auslieferungsweit identischen Schlüssel verschlüsselt; Schlüssel und statische IV teilen Bytes, gleiche Klartexte ergeben identische Chiffretexte; Masterkey-Ablage verschlüsselt sich mit demselben Default; kein Rotationsmechanismus.
Ergebnis: Verschlüsselung schützt nicht gegen Angreifer mit Quellcode-/Binary-Zugriff; Chiffretexte deploymentsübergreifend vergleichbar; fehlgeschlagene Entschlüsselung liefert Leerwert.
Belege: [PRIMÄR] AESCryptoLogic.cs:11-92; Aufrufzählung gegen Quellcode; KONTEXT Faktenbasis M057.
Prüfidee: EncryptText(x) ohne Schlüssel auf zwei Systemen vergleichen (Identität); Chiffretext-Wiederholungen zählen; DecryptText mit fremdem Schlüssel (leerer String).
Tracelinks: SyRS:Krypto (SyRS-56), StRS:Verschluesselung; SwRS-26, SwRS-27, SwRS-47, SwRS-51
Konsolidierung: Kandidat — drei Mechanismen „Verschlüsselung gespeicherter Geheimdaten": AESCryptoLogic Default, EncryptWithMasterKey, SHA1; auf ein Schlüsselmanagementsystem mit rotierbaren Schlüsseln zusammenführen.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Sicherheitsrisiko
Status: HYPOTHESE
ID: SwRS-53
Titel: Globale FK-Armut (134 FK bei 1558 Tabellen): Referenzintegrität ist anwendungsgesteuert
Ebene: SwRS
Typ: Constraint-/Datenanforderung (Architektur-Querschnitt)
Qualitätsmerkmal: Konsistenz, Vollständigkeit, Portabilität
Akteur: Persistenzschicht insgesamt (SSMS_DB_SCHEMA.sql)
Vorbedingung: Beliebige Datenbankänderung oder Direktzugriff
Fakt: CREATE TABLE=1558, FOREIGN KEY=134 (≈8,6 %); CHECK=10; Beispiele Zahlungseingang.RechKopfI3D NULL ohne FK; SocialMediaComment ohne FK/CHECK; WebAccountsRights ohne FK/UNIQUE; Gegenbeispiele FK_SurveyProcessProperties WITH CHECK, CK_ParentReference; FK-Inseln v.a. CSI_*-Tabellen.
Aussage: Die überwiegende Mehrheit der Tabellenbeziehungen wird datenbankseitig nicht erzwungen; referenzielle Regeln leben in BL, Raw-SQL und Views und gelten nur für den jeweiligen Codepfad.
Ergebnis: Verwaiste Referenzen auf jedem Direktweg erzeugbar; Migrationen/Drittsysteme können Regeln nicht aus dem Schema ableiten.
Belege: [PRIMÄR] Auszählung gegen SSMS_DB_SCHEMA.sql (1558/134); Beispiele :8020-8031, :54877-54885, :67802-67842.
Prüfidee: Referenzen ohne Elternsatz (Zahlungseingang, SocialMediaComment) → Speichern-Erfolg; Probe auf FK-Insel SurveyProcessProperties → FK-Fehler.
Tracelinks: SyRS:Referenzintegritaet (SyRS-50), StRS:Pflichtfelder; SwRS-8, SwRS-34, SwRS-41, SwRS-48, SwRS-50
Konsolidierung: kein Fall — Querschnittsbetrachtung; Teilaspekte desselben Zustands, keine getrennten Implementierungen eines Fachgegenstands.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Zielarchitektur-Entscheidung
Status: belegt
ID: SwRS-54
Titel: Anhängegrenzen der KI-Konversation als hartcodierte Konstanten (20 MB / 40 MB / 20000 Zeichen)
Ebene: SwRS
Typ: Constraint-/Datenanforderung (Ressourcengrenzen)
Qualitätsmerkmal: Zuverlässigkeit, Ressourcenverhalten, Wartbarkeit
Akteur: ArtificialIntelligenceChatConversationViewModelBase
Vorbedingung: Benutzer hängt Dateien an bzw. sichert Textinhalte
Fakt: `_maximumAttachmentBytes = 20L*1024L*1024L`, `_maximumAttachmentTotalBytes = 40L*1024L*1024L`, `_attachmentTextSnapshotLimit = 20000` (ArtificialIntelligenceChatConversationViewModelBase.cs:40-42); Durchsetzung fileInfo.Length>... (498), bytes.LongLength>... (540); zwei Formatierungshilfen (626-629, 1200-1203); keine serverseitige Zweitprüfung.
Aussage: Die Komponente erzwingt Einzelanhang 20 MiB, Gesamtgrenze 40 MiB und Textsnapshot 20000 Zeichen ausschließlich clientseitig über Konstanten; kein persistenter/serverseitiger Grenzwert.
Ergebnis: Grenzwerte nur per Quellcodeänderung anpassbar; Clientumgehung nicht behindert ([HYPOTHESE] Serverseite).
Belege: [PRIMÄR] ArtificialIntelligenceChatConversationViewModelBase.cs:40-42, 498, 540, 626-629, 1200-1203; KONTEXT M002.
Prüfidee: Datei 21 MB ablehnen; 3×14 MB (42 MB) Summen-Ablehnung; 20001-Zeichen-Text Snapshot-Kappung; KI-Dienst direkt ansprechen.
Tracelinks: SyRS:KI-Assistent (SyRS-52), StRS:KI-Nutzung; SwRS-4
Konsolidierung: Kandidat: SwRS-4 (dieselben KI-Grenzwerte 20/40 MB/20000 Zeichen in der Client-Schicht); bei Übernahme mit SwRS-4 verschmelzen. — Konstanten an einer Stelle; Doppelung der Größenformatierung ist Redundanz, kein Fachdoppel; Abgrenzung zu SwRS-4 (andere Tiefe → Tracelink).
Übernahmewürdigkeit: übernehmen - mittlere Priorität
Status: HYPOTHESE
ID: SwRS-55
Titel: Report-Kaskadenlöschung als sequenzielle Roh-SQL-Kette inklusive externer Referenznullsetzung
Ebene: SwRS
Typ: Funktionsanforderung (interner Algorithmus, Löschkaskade)
Qualitätsmerkmal: Konsistenz, Richtigkeit, Nachvollziehbarkeit
Akteur: ReportDataBL.DeleteReport (ReportEngine)
Vorbedingung: reportID eines vorhandenen Reports
Fakt: Session.StartTransaction (396); delete from ReportDataQueries (402); Delete ReportData (409); DeletePrintSetting (411); DELETE rp FROM ReportDataParameters INNER JOIN ReportGroupsToReportData (414-417); delete ReportGroupsToReportData (421); delete ReportPrintOptions (425); update VertragsArt set C2ReportI3D=0 (429); jeder Schritt throw bei ResultStatus.Error.
Aussage: Die Reportkomponente ersetzt fehlende FK-Kaskaden (SwRS-34) durch eine handkodierte, transaktionale Löschsequenz fester Reihenfolge und entkräftet modulexterne Verweise durch Setzen auf 0; die Sequenz ist der einzige Ort vollständiger Bereinigung.
Ergebnis: Löscht ein anderer Weg den Elternsatz, bleiben Kindobjekte und VertragsArt.C2ReportI3D-Verweise auf nicht existierende Reportnummer; „Report 0" als Sentinel gesetzt.
Belege: [PRIMÄR] ReportDataBL.cs DeleteReport Zeilen 390-431; KONTEXT Faktenbasis M028.
Prüfidee: Report mit allen Abhängigkeiten anlegen, DeleteReport, sechs Tabellen + VertragsArt prüfen; Elternsatz per Direkt-SQL löschen und Waisenbestand vergleichen.
Tracelinks: SyRS:Berichtewesen (SyRS-53), StRS:Auswertungen; SwRS-34, SwRS-37, SwRS-53
Konsolidierung: kein Fall — SwRS-34 Constraint-Seite, dieser Block Algorithmus; zwei Tiefenblicke, keine getrennten Implementierungen.
Übernahmewürdigkeit: übernehmen - hohe Priorität - Datenbestandskonsistenz
Status: belegt
ID: SwRS-56
Titel: Zwei parallele Client-Transportpfade für TOTP-Schlüsselverwaltung und PIN-Prüfung (BL-Direkt vs. Webservice)
Ebene: SwRS
Typ: Funktionsanforderung (Komponentenarchitektur, Sicherheit)
Qualitätsmerkmal: Sicherheit, Konsistenz, Wartbarkeit
Akteur: BLTwoFactorAuthenticationLogic und WSTwoFactorAuthenticationLogic (beide ITwoFactorAuthenticationLogic)
Vorbedingung: Client muss TOTP-Schlüsselstand prüfen, Schlüssel setzen oder PIN validieren
Fakt: BLTwoFactorAuthenticationLogic führt Anfragen lokal über `new BLSession...GetBL<TwoFactorAuthenticationWebServiceBL>` (BLTwoFactorAuthenticationLogic.cs:10-55); WSTwoFactorAuthenticationLogic dieselben drei Operationen über CallWebServiceMethodWithSingleResultAsync (WSTwoFactorAuthenticationLogic.cs:9-26); PIN-Validierung servernah über TwoFactorAuthenticationBL.ValidatePin (51).
Aussage: Für denselben Gegenstand „TOTP-Schlüsselverwaltung/PIN-Prüfung" hält die Software zwei Implementierungen mit unterschiedlichen Autorisierungspfaden bereit; der BL-Pfad umgeht die Webservice-Autorisierungsschicht; die Konfiguration entscheidet die Bindung.
Ergebnis: Je Pfad können Berechtigungsprüfung, Protokollierung und Fehlerbehandlung divergieren; Server-Autorisierung auf BL-Pfad nicht wirksam.
Belege: [PRIMÄR] BLTwoFactorAuthenticationLogic.cs:10-55 und WSTwoFactorAuthenticationLogic.cs:9-26; TwoFactorAuthenticationBL.cs:51.
Prüfidee: DI-Bindung untersuchen; 2FA-Aufruf ohne Dienstautorisierung auf BL-Pfad; PIN-Validierung auf beiden Pfaden vergleichen.
Tracelinks: SyRS:Weblogin (SyRS-45), SyRS:Zwei-Faktor-Authentisierung (SyRS-56); StRS:Durchgehende-Autorisierung (StRS-10), StRS:Zwei-Faktor-und-Kennworthaerte (StRS-13); SwRS-42, SwRS-43
Konsolidierung: Kandidat (Fall c) — TOTP doppelt: BLTwoFactorAuthenticationLogic (BL direkt) vs. WSTwoFactorAuthenticationLogic (REST); auf einen autorisierten Pfad reduzieren.
Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheitsrelevant
Status: belegt
## KONSOLIDIERUNGSÜBERSICHT (SwRS-Autor, fachliche Doppelführungen)
| Fall | Fachlicher Gegenstand | Getrennte Implementierungen | Belegt in |
|---|---|---|---|
| a | Drucker/Geräte-Hardware | „Stammblatt" (MasterDataList/DeviceHeaderI3D) vs. AssetManagementDevices/AssetManagementPrinter (Inventar, Riverbird-Cleanup) | SwRS-45, SwRS-12, SwRS-44 |
| b | Zahler/Kostenträger | UI-Begriff „Payers"/„Zahler" (PayersAndCostCenter*) vs. Domänentabelle Kostentraeger; Kostenstellen (pl.) vs. Kostenstelle (sg.) | SwRS-29, SwRS-28 |
| c | TOTP-Zwei-Faktor-Behandlung | BLTwoFactorAuthenticationLogic (BL direkt) vs. WSTwoFactorAuthenticationLogic (REST) hinter ITwoFactorAuthenticationLogic | SwRS-56 |
| d | Helpdesk-Eskalation/SLA | EscalationBL mit Escalationen/hlpdsk_requests.EscalationLevel vs. Eskalations-/SLA-Felder in hlpdsk_prioritaeten | SwRS-22, SwRS-23 |
| e | MailScanner-Kennwort | Password masterkey-verschlüsselt (MailScannerBL.cs:104-116) vs. MailPassword unverschlüsselt (MailScannerProfileMaps.cs:20) | SwRS-47, SwRS-51 |
| f | SocialMediaKind-Codierung | C#-Enum (SocialMediaKind.cs:3-7) vs. T-SQL-Fallunterscheidungen/-Literals (≥16 Fundstellen SSMS_DB_SCHEMA.sql) | SwRS-48 |
| g | Eingehende Zahlung | PaymentTransactionBL-Zahlungsverkehr vs. Zahlungseingang (FK-frei, PaymentsBL) | SwRS-6, SwRS-8 |
| h | Frist-/Verlängerungslogik | ContractBL.RefreshContractEndeDate (C#) vs. CASE-Fallunterscheidung in über zehn SQL-Skriptkopien (SQLScriptCollection4.xml:936-938) | SwRS-11 |
| zusätzlich | Kennworthaltung | BenutzerInfo2 (AppUser), SHA1 (WebAccount), MailScanner doppelt, leer (PasswordManagementKeyword) | SwRS-51, SwRS-3/27/42/47 |
| zusätzlich | Rechteauflösung | AppUser-Zweig Sichtrus/Sichmemb vs. WebAccount-Zweig WebAccountsRights | SwRS-1, SwRS-50 |
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/SyRS.md
+1021
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/Traceability.md
+78
View File
@@ -0,0 +1,78 @@
# Traceability
Die Tabelle zeigt die redaktionell aufgelösten Forward-/Backward-Beziehungen zwischen StRS, SyRS und SwRS. Kurzanker ohne numerische Gegenstelle sind in den Anforderungsdateien als offene Anker stehen geblieben; die Tabelle verwendet nur existierende IDs. `—` markiert eine auf dieser Ebene nicht aufgelöste Beziehung.
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|---|---:|---|---|
| StRS-1, StRS-4 | SyRS-1 | SwRS-1, SwRS-3, SwRS-48, SwRS-51 | src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs |
| StRS-1, StRS-7 | SyRS-2 | — | SSMS_DB_SCHEMA.sql |
| StRS-2 | SyRS-3 | SwRS-2 | src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs |
| StRS-3 | SyRS-4 | SwRS-49, SwRS-50, SwRS-56 | src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs |
| StRS-4, StRS-8 | SyRS-5 | SwRS-52, SwRS-53, SwRS-54, SwRS-55, SwRS-56 | siehe Belege-Feld der Anforderung |
| StRS-24 | SyRS-6 | SwRS-20 | siehe Belege-Feld der Anforderung |
| StRS-7 | SyRS-7 | SwRS-21 | src/backend/Centron.BL/GUI/Profiles/UiProfileBL.cs |
| StRS-6, StRS-12 | SyRS-8 | — | src/backend/Centron.BL/Accounts/AccountBL.cs |
| StRS-5 | SyRS-9 | SwRS-13 | src/backend/Centron.BL/Accounts/AccountAddressBL.cs |
| StRS-24 | SyRS-10 | — | SSMS_DB_SCHEMA.sql |
| StRS-24 | SyRS-11 | — | SSMS_DB_SCHEMA.sql |
| StRS-34 | SyRS-12 | SwRS-25, SwRS-48 | siehe Belege-Feld der Anforderung |
| StRS-23 | SyRS-13 | SwRS-16, SwRS-17, SwRS-31 | src/webservice/Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs |
| StRS-22 | SyRS-14 | SwRS-18, SwRS-19 | SpecificLogic |
| StRS-24 | SyRS-15 | — | SSMS_DB_SCHEMA.sql |
| StRS-26 | SyRS-16 | SwRS-24 | src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs |
| StRS-29 | SyRS-17 | SwRS-35 | src/backend/Centron.BL/CustomerArea/RmaBL.cs |
| StRS-35 | SyRS-18 | SwRS-36 | siehe Belege-Feld der Anforderung |
| StRS-38 | SyRS-19 | SwRS-39 | siehe Belege-Feld der Anforderung |
| StRS-16 | SyRS-20 | SwRS-6, SwRS-8 | src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs |
| StRS-17 | SyRS-21 | SwRS-9 | DunningRunBL |
| StRS-17 | SyRS-22 | — | src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs |
| StRS-17 | SyRS-23 | — | SSMS_DB_SCHEMA.sql |
| StRS-20 | SyRS-24 | SwRS-11 | ContractBL |
| StRS-21 | SyRS-25 | — | src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs |
| StRS-21 | SyRS-26 | SwRS-12 | siehe Belege-Feld der Anforderung |
| StRS-18 | SyRS-27 | SwRS-26 | siehe Belege-Feld der Anforderung |
| StRS-23 | SyRS-28 | SwRS-40 | siehe Belege-Feld der Anforderung |
| StRS-4 | SyRS-29 | — | siehe Belege-Feld der Anforderung |
| StRS-28 | SyRS-30 | SwRS-41 | SSMS_DB_SCHEMA.sql |
| StRS-27 | SyRS-31 | SwRS-32 | siehe Belege-Feld der Anforderung |
| StRS-8 | SyRS-32 | SwRS-30 | siehe Belege-Feld der Anforderung |
| StRS-24 | SyRS-33 | SwRS-33 | siehe Belege-Feld der Anforderung |
| StRS-30 | SyRS-34 | SwRS-14 | siehe Belege-Feld der Anforderung |
| StRS-31 | SyRS-35 | SwRS-22, SwRS-23 | siehe Belege-Feld der Anforderung |
| StRS-31 | SyRS-36 | — | siehe Belege-Feld der Anforderung |
| StRS-21 | SyRS-37 | SwRS-5 | ScheduleBL |
| StRS-35 | SyRS-38 | SwRS-38 | siehe Belege-Feld der Anforderung |
| StRS-36 | SyRS-39 | SwRS-37 | siehe Belege-Feld der Anforderung |
| StRS-36 | SyRS-40 | SwRS-34, SwRS-55 | ReportEngine |
| StRS-22 | SyRS-41 | — | siehe Belege-Feld der Anforderung |
| StRS-23 | SyRS-42 | — | siehe Belege-Feld der Anforderung |
| StRS-38 | SyRS-43 | SwRS-7 | src/backend/Centron.BL/Sales/Support/ExternalToolsReplacementBL.cs |
| StRS-39 | SyRS-44 | — | siehe Belege-Feld der Anforderung |
| StRS-12 | SyRS-45 | SwRS-3, SwRS-42, SwRS-50, SwRS-51, SwRS-56 | src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs |
| StRS-14 | SyRS-46 | SwRS-27, SwRS-47 | src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs |
| StRS-12 | SyRS-47 | SwRS-43 | src/nexus/CentronNexus/Shared/Authorization/ClaimsService.cs |
| StRS-10 | SyRS-48 | — | SSMS_DB_SCHEMA.sql |
| StRS-7 | SyRS-49 | SwRS-1, SwRS-49 | AuthenticationTicketBL |
| StRS-24 | SyRS-50 | SwRS-53 | SSMS_DB_SCHEMA.sql |
| StRS-8 | SyRS-51 | — | centron\Centron.WPF.UI\Modules\ModuleRightsExpressionParser.cs |
| StRS-39 | SyRS-52 | SwRS-4, SwRS-54 | siehe Belege-Feld der Anforderung |
| StRS-36 | SyRS-53 | SwRS-34, SwRS-55 | ReportEngine |
| StRS-41 | SyRS-54 | — | ProcessBL |
| StRS-41 | SyRS-55 | — | SSMS_DB_SCHEMA.sql |
| StRS-11 | SyRS-56 | SwRS-52, SwRS-56 | backend\Centron.Common\TextCoding\AESCryptoLogic.cs |
| StRS-10 | SyRS-57 | — | webservice\Centron.Host\CentronHost.cs |
| StRS-9 | SyRS-58 | — | webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs |
| StRS-11 | SyRS-59 | — | Directory.Build.props |
| StRS-4 | SyRS-60 | — | backend\Centron.DAO\DAOFactory.cs |
| StRS-33 | — | SwRS-10 | CampaignBL.cs |
| StRS-32 | — | SwRS-15 | src/backend/Centron.BL/Sales/Customers/CrmProjects/CrmProjectBL.cs |
| StRS-25 | — | SwRS-28 | SSMS_DB_SCHEMA.sql |
| StRS-25 | — | SwRS-29 | src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerView.xaml |
| StRS-38 | — | SwRS-44 | src/centron/Centron.WPF.UI/Modules/MyCentron/CentronInspectors/Inspectors/Database/RiverbirdTablesCleanupInspector.cs |
| StRS-26 | — | SwRS-45 | CentronObjectKindNumeric.cs |
| StRS-34 | — | SwRS-46 | src/backend/Centron.BL/Accounts/TapiBL.cs |
| StRS-13 | SyRS-56, SyRS-58 | SwRS-42, SwRS-43, SwRS-51, SwRS-52, SwRS-56 | siehe Belege-Feld der Anforderung |
| StRS-15 | — | — | siehe Belege-Feld der Anforderung |
| StRS-19 | SyRS-27 | SwRS-6, SwRS-26 | siehe Belege-Feld der Anforderung |
| StRS-37 | — | — | siehe Belege-Feld der Anforderung |
| StRS-40 | SyRS-51 | SwRS-30 | siehe Belege-Feld der Anforderung |
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/OpenCode.log
View File
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/OpenCodeEvents.jsonl
+353
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Protokoll.md
+130
View File
@@ -0,0 +1,130 @@
# Messprotokoll – Iteration 9/qwen/qwen3.8-flash-next/custom/high
> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
## Lauf
- **Prompt-Datei:** `02_Prompt.md`
- **SHA-256 (Prompt):** `5946FC82C45E7A242A1F7367B56B008EE0F5C10373223D3500BCEF4716C76ECD`
- **Startzeit:** 2026-09-02T14:03:38.8465630+02:00
- **Endzeit:** 2026-09-02T15:56:15.4515645+02:00
- **Dauer gesamt:** 01: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 9/qwen/qwen3.8-flash-next/custom/high/`
- **Agentenmodus:** `custom`
- **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` = 24, `completed` = 24, `failed` = 0
- **Rollen:** {"modulinventar": 2, "faktenermittler": 10, "strs-autor": 2, "syrs-autor": 2, "swrs-autor": 2, "belegpruefer": 1, "konsistenzpruefer": 4, "iso29148-orchestrator": 1}
## Validierungsstichprobe
- **Stand:** entfaellt
## Verbrauch
| Messgroesse | Wert |
|---|---|
| Input-Tokens | 424.078 |
| Output-Tokens | 90.779 |
| Reasoning-Tokens | 56.641 |
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
| Agent-Turns | 85 |
**Tokens gesamt: 10.715.498.** 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 | 41 | 26,1 % |
| SyRS | 60 | 38,2 % |
| SwRS | 56 | 35,7 % |
| **Gesamt** | **157** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| Fachregel | 39 | 24,8 % |
| Sicherheit | 30 | 19,1 % |
| Daten | 14 | 8,9 % |
| funktional | 8 | 5,1 % |
| Schnittstelle | 5 | 3,2 % |
| nicht-funktional | 4 | 2,5 % |
| Daten-/Constraintanforderung | 4 | 2,5 % |
| Datenanforderung / Mapping | 2 | 1,3 % |
| Funktionsanforderung (interner Algorithmus) | 2 | 1,3 % |
| Funktions-/Constraintanforderung (Sicherheit) | 2 | 1,3 % |
| (47 weitere) | 47 | 29,9 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 66 |
| davon `PRIMÄR` | 29 (43,9 %) |
| davon `SEKUNDÄR` | 37 (56,1 %) |
| davon `KONTEXT` | 0 (0,0 %) |
| Belege je Anforderung (Median) | 0 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 28 (17,8 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 157 | 100,0 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 93 | 59,2 % |
| als `HYPOTHESE` gekennzeichnet | 64 | 40,8 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 113 | 72,0 % |
| mit ISO-25010-Qualitätsmerkmal | 157 | 100,0 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **verletzt** – 96 ohne Beleg: SyRS-1, SyRS-2, SyRS-3, SyRS-4, SyRS-5, SyRS-6, SyRS-7, SyRS-8 … |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 33 von 83 ungedeckt: SyRS-1, SyRS-2, SyRS-3, SyRS-4, SyRS-7, SyRS-8, SyRS-12, SyRS-16 … |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 157 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 157 von 157 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** `is_error: true`, `subtype: error`, `exit_code: 1`, `timed_out: false`
- **Session-ID:** `ses_f9dff0fd3ffei0THHf9fgmC3fO`
- **Werkzeugaufrufe:** 99 – {"bash": 56, "task": 24, "write": 3, "read": 6, "grep": 9, "edit": 1}
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 24
- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
- **Root unveraendert:** ja
- **Fehlermeldungen:** ["OpenCode beendete sich mit Exitcode 1"]
## Anmerkungen/Auffaelligkeiten
*(von Hand zu ergaenzen)*

Some files were not shown because too many files have changed in this diff Show More