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

TensorX-Matrix: erste vollstaendig besetzte Matrix, 918 Anforderungen

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

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

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

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

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

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Christoph Schwörer
2026-09-02 16:21:31 +02:00
co-authored by Claude Opus 5
parent 6c5c26a2e4
commit e2c3a0e8f8
135 changed files with 102006 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Versuche/Versuch_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)*
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/RawResult.json
+1130
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/Stderr.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/_meta/after.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/anforderungen.json
+2798
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/_meta/anforderungen.md
+68
View File
@@ -0,0 +1,68 @@
## Gefundene Anforderungen
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
### Verteilung über die Ebenen
| Ebene | Anzahl | Anteil |
|---|---:|---:|
| StRS | 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 %) |
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/before.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/combined_prompt.md
+218
View File
@@ -0,0 +1,218 @@
# Versuch 02 - Agentengestuetzt - Prompt-Version 03-A
## Metadaten
- **Versuch:** V2 Agentengestützt (rollenspezialisierte Agentendateien)
- **Prompt-Version:** 03-A (Prompt-Version 03 aus Versuch 01, angepasst an verteilte Bearbeitung)
- **Basis:** `Versuche/Versuch_01/03_Prompt.md`, SHA-256 `B8C8764F…C030F07`
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-31
- **Vorgänger:** `01_Prompt.md` (Prompt-Version 02-A, SHA-256 `DCDC0E3F…B71BCF`), **kein Lauf durchgeführt**
- **Änderungsgrund gegenüber `01_Prompt.md`:** Version 02-A leitete sich von Prompt-Version **02** ab. Versuch 1 ist inzwischen auf Prompt-Version **03** weitergelaufen (Iteration 8 und 9). Ein V2-Lauf gegen 02-A würde sich von den Vergleichsläufen in **zwei** Größen unterscheiden — Agentenrollen *und* Prompt-Version — und wäre als Wirkungsnachweis der Rollen unbrauchbar. Version 03-A setzt deshalb auf Prompt-Version 03 auf.
| Änderung gegenüber `Versuch_01/03_Prompt.md` | Grund |
|---|---|
| Neuer Abschnitt „Arbeitsteilung" | Prompt-Version 03 unterstellt stillschweigend **einen** Bearbeiter: Sie ordnet die Schritte zeitlich, vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck über das Ergebnis. Bei verteilter Bearbeitung ist nichts davon von selbst erfüllt — IDs kollidieren, die Reihenfolge läuft rollenweise auseinander, und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen. |
| In der Arbeitsteilung: Ergebnisstruktur gilt unabhängig von der Aufteilung | Die 7-Datei-Regel aus Version 03 entstand an einem `solo`-Lauf (Kimi legte `SwRS-Ergaenzungen.md` an, 18 Anforderungen fielen aus der Auswertung). Bei verteilter Bearbeitung ist eine Datei je Bearbeiter der nächstliegende Fehler — die Regel wird dort ausdrücklich wiederholt. |
| In der Arbeitsteilung: **Zuständigkeitsbindung** — eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, wird von ihm ausgeführt | V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Der Smoke-Test vom 26.08. zeigte, dass von acht beigestellten Rollen nur zwei genutzt wurden — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist **statisch** deklariert und gehasht und damit eine reproduzierbare Bedingung; sie ist nicht mit den laufzeitabhängigen Adapterinjektionen aus Iteration 8 zu verwechseln, die Lauf 34 unpoolbar machten. |
| In der Arbeitsteilung: frei bleiben Zuschnitt, Anzahl, Reihenfolge und Tiefe | Gebunden wird **wer** eine Teilaufgabe ausführt, nicht **wie viel** davon getan wird. Zerlegungstiefe und Aufrufzahl bleiben Untersuchungsgegenstand wie in V1b. |
| In der Arbeitsteilung: Dokumentationspflicht zur tatsächlichen Beauftragung | Die Bindung wirkt auf Promptebene und ist damit nicht technisch erzwungen, sondern selbst eine Messgröße. Nur wenn im Lauf festgehalten ist, wer was ausgeführt hat, ist die Einhaltung gegen `subagent_stats` und die Subagenten-Prompts prüfbar. |
| Angehängte Tabellenzeilen und Schlussblockquote aus `03_Prompt.md` an ihren Platz gerückt | In `03_Prompt.md` stehen zwei Zeilen der Änderungstabelle **nach** dem Abschnitt „Abschluss" und die Tabelle im Metadatenblock ist leer. Da der Skill die **gesamte** Datei sendet (`_meta/combined_prompt.md`), gingen beide Fehlstellen in jeden Lauf der Iterationen 8 und 9 mit ein. |
**Der Prompt nennt keine Rolle namentlich.** Er formuliert die Bindung abstrakt; welche Rollen es gibt und wofür sie zuständig sind, stellt der Versuchsaufbau im Block Werkzeugkontext bei. Damit bleibt dieselbe Prompt-Datei auch für einen `solo`-Lauf ohne Rollen gültig — der fachliche Auftrag ist über V1, V2 und V3 identisch, und die Rollenbindung bleibt die einzige unabhängige Variable. Anzahl der Aufrufe, Zerlegungstiefe und Turn-Anzahl werden weiterhin **nicht** vorgegeben; sie bleiben Teil der Untersuchung.
Unverändert gegenüber Prompt-Version 03 bleiben: Auftrag, Scope, Vorgehensschritte 0 bis 6, Pflicht-Eigenschaften, Blockformat, Belegklassifikation, Prüfidee, Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur, Randbedingungen und Abschluss. Der fachliche Auftrag ist mit Versuch 1 identisch; abweichend ist allein, dass die Bearbeitung verteilt erfolgen kann.
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge und Agentenrollen im jeweiligen Lauf
> zur Verfügung stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau
> beim Start bei.
---
## Prompt
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
### Auftrag
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
### Vorgehen (statische Analyse, keine Ausführung)
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **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.
### Arbeitsteilung
Die Bearbeitung wird auf mehrere Bearbeiter verteilt. **Stellt der Versuchsaufbau für eine Teilaufgabe einen dafür vorgesehenen Bearbeiter bereit, ist diese Teilaufgabe von ihm auszuführen** — nicht von dir selbst und nicht von einem anderen. Welche Bearbeiter bereitstehen und wofür sie zuständig sind, nennt der Versuchsaufbau; diese Zuständigkeit ist Teil der Aufgabenstellung und keine Empfehlung. Stellt der Versuchsaufbau keine Bearbeiter bereit, bearbeitest du alles selbst und dieser Abschnitt ist ohne Wirkung.
- **Frei bleibt, wie du die Bearbeiter einsetzt.** Den Zuschnitt der Ausschnitte, die Anzahl der Aufträge je Bearbeiter, ihre Reihenfolge, die Tiefe und ob du nachfasst, entscheidest du. Gebunden ist allein, **wer** eine Teilaufgabe ausführt. Teilaufgaben, für die kein Bearbeiter vorgesehen ist — insbesondere der Zuschnitt, die Beauftragung, das Anlegen der Ergebnisdateien und die Übernahme der zurückgemeldeten Befunde —, führst du selbst aus.
- **Zuständigkeit vor Bearbeitung klären.** Lege fest, wer welchen Ausschnitt bearbeitet, bevor die erste Anforderung entsteht. Ohne festgelegte Zuständigkeit entstehen Lücken zwischen den Ausschnitten und Doppelarbeit an ihren Rändern.
- **ID-Bereiche vorab vergeben, überschneidungsfrei und lückenlos.** Jeder Bearbeiter erhält einen eigenen Nummernbereich je Ebene. Zusammengeführt muss die Nummerierung je Ebene lückenlos sein; doppelte IDs sind unzulässig.
- **Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Bearbeiter.** Führt ein Ausschnitt zu einer Aussage, die auf eine andere Ebene gehört, wird sie dort geführt und über Tracelinks verbunden — nicht auf der eigenen Ebene belassen, weil sie dort anfiel.
- **Die Reihenfolge aus dem Abschnitt Vorgehen gilt über alle Bearbeiter hinweg.** Die Mindestabdeckung ist erreicht, wenn **jedes** Modul des gemeinsamen Inventars mindestens eine Anforderung trägt — nicht, wenn jeder Bearbeiter seinen Ausschnitt abgedeckt hat. Erst danach beginnt die Vertiefung.
- **Der Konsistenzcheck gilt dem zusammengeführten Ergebnis.** Eine Prüfung des eigenen Beitrags ersetzt ihn nicht. Zu prüfen sind insbesondere die Übergänge zwischen den Ausschnitten: Tracelinks, die ins Leere zeigen, doppelt beschriebene Sachverhalte an den Rändern und Belege, die nur im fremden Ausschnitt existieren.
- **Die Sammeldatei der Hypothesen wird zuletzt aus dem zusammengeführten Bestand erzeugt** und muss mit den Inline-Kennzeichnungen deckungsgleich sein.
- **Die Ergebnisstruktur ist von der Arbeitsteilung unabhängig.** Es entstehen genau die sieben vorgegebenen Dateien — keine Datei und kein Abschnitt je Bearbeiter.
**Dokumentationspflicht.** Halte im `Analysebericht.md` fest, welchen Bearbeiter du für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt hast. Hast du eine zugewiesene Teilaufgabe ausnahmsweise selbst ausgeführt, nenne sie ausdrücklich und begründe es. Diese Angabe ist Teil des Ergebnisses, nicht Beiwerk: Ohne sie ist nicht nachvollziehbar, wie die Spezifikation zustande kam, und eine unbemerkte Abweichung von der Zuständigkeit macht den Lauf unauswertbar.
### 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?
### 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 beigestellten Agentenrollen modulinventar, faktenermittler, strs-autor, syrs-autor,
swrs-autor, belegpruefer, konsistenzpruefer und iso29148-orchestrator.
Nicht verfügbar sind: externe Werkzeugserver, Webzugriff.
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
Werkzeuge zu ersetzen.
Für die folgenden Teilaufgaben stehen vorgesehene Bearbeiter bereit. Führe diese
Teilaufgaben durch den jeweils genannten Bearbeiter aus, nicht selbst:
| Teilaufgabe | Vorgesehener Bearbeiter |
|---|---|
| Modulinventar (Schritt 0) | modulinventar |
| Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | faktenermittler |
| Formulierung der StRS-Anforderungen | strs-autor |
| Formulierung der SyRS-Anforderungen | syrs-autor |
| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
| Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | iso29148-orchestrator |
| Konsistenzcheck des fertigen Anforderungssatzes (Abschnitt Abschluss) | konsistenzpruefer |
Zuschnitt, Anzahl der Aufträge je Bearbeiter, deren Reihenfolge und die Tiefe
entscheidest du. Gebunden ist allein, wer eine Teilaufgabe ausführt. Die Bearbeiter
lesen nur; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen
bleiben deine Aufgabe.
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
`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\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T15:56:15.4515645+02:00
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/opencode-config.json
+648
View File
@@ -0,0 +1,648 @@
{
"$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_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse": "allow",
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"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": "allow",
"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/**": "allow",
"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/Ergebnisse": "allow",
"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/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/spiegel/Ergebnisse/**": "allow"
},
"external_directory": {
"*": "deny",
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse": "allow",
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"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": "allow",
"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/**": "allow",
"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/Ergebnisse": "allow",
"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/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_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",
"modulinventar": "allow",
"faktenermittler": "allow",
"strs-autor": "allow",
"syrs-autor": "allow",
"swrs-autor": "allow",
"belegpruefer": "allow",
"konsistenzpruefer": "allow",
"iso29148-orchestrator": "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"
},
"modulinventar": {
"description": "Schritt 0: erstellt das vollständige Modulinventar als Bezugsgröße für die Abdeckung, mit Buchführung über zugeordnete und nicht zugeordnete Quelldateien. Erzeugt KEINE Anforderungen.",
"mode": "subagent",
"model": "tensorx/qwen/qwen3.8-flash-next",
"prompt": "Du erstellst das Modulinventar für ein Reverse-Requirements-Engineering-Vorhaben an einer Legacy-ERP-Suite. Du formulierst KEINE Anforderungen. Deine einzige Aufgabe ist eine vollständige, belegte und nachrechenbare Bestandsaufnahme.\n\n## Vorgehen\n\n1. Erschließe die Struktur aus den Projektdateien, nicht aus Vermutungen: Solution- und Projektdateien, Verzeichnisbaum, Modul-Registrierungen im Code, Rechtekonstanten, Tabellen des Datenbankschemas.\n2. Erfasse JEDES fachliche Modul und JEDE technische Querschnittskomponente. Ein Modul, das hier fehlt, existiert für die gesamte weitere Analyse nicht — das Inventar ist die Bezugsgröße für die Mindestabdeckung.\n3. Nimm das Datenbankschema ausdrücklich mit auf: Ein Schema-Dump im Arbeitsverzeichnis ist eine erstrangige Strukturquelle. Ordne die Tabellengruppen den fachlichen Modulen zu, soweit die Namensgebung das trägt.\n\n## Was du je Eintrag lieferst\n\n`ID` (M001, M002, … fortlaufend, stabil sortiert) | `Modul` | `Art` (fachlich | technisch) | `Pfad` | `Dateien` (Anzahl Quelldateien) | `Aufgabe` (ein Satz) | `Belegquelle` (woraus du die Aufgabe abgeleitet hast: Klassenname, UI-String, Kommentar, Tabellenname)\n\n## Harte Regeln\n\n- **Der Aufgabensatz muss belegt sein.** Leite ihn aus dem ab, was du tatsächlich gelesen hast. Ein Ordnername ist kein Beleg. Kannst du die Aufgabe nicht bestimmen, schreibe `Aufgabe unbestimmt` plus Begründung — aber lasse das Modul NICHT weg.\n- **Kein Zuschnitt nach Bequemlichkeit.** Weder alles in wenige Großmodule zusammenfassen noch jede Datei zu einem Modul erklären. Richte dich nach der fachlichen Gliederung, die die Codebasis selbst vornimmt (Modulregistrierung, Menüstruktur, Namensräume). Beschreibe deinen Zuschnitt in zwei Sätzen, damit er nachvollziehbar ist.\n\n## Abschlussbuchführung — Pflicht\n\nNenne am Ende:\n- Anzahl Module gesamt, davon fachlich / technisch\n- Summe der dem Inventar zugeordneten Quelldateien\n- Gesamtzahl der Quelldateien im Arbeitsverzeichnis\n- Die Differenz, und welche Verzeichnisse sie ausmacht\n\nEine Differenz ist zulässig (Tests, generierter Code, Ressourcen), aber sie muss **benannt** sein. Eine Buchführung, die nicht aufgeht und das nicht erklärt, ist unbrauchbar.\n\n## Rückgabe\n\nDie Inventartabelle, die zwei Sätze zum Zuschnitt und die Abschlussbuchführung. Keine Einleitung, keine Zusammenfassung, keine Empfehlungen.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"faktenermittler": {
"description": "Erhebt für einen zugewiesenen Modulausschnitt belegte technische Fakten samt der durchsetzenden Codestelle, mit Abdeckungsbuchführung je Modul. Formuliert KEINE Anforderungen.",
"mode": "subagent",
"model": "tensorx/qwen/qwen3.8-flash-next",
"prompt": "Du erhebst Fakten aus einer Legacy-ERP-Codebasis. Du formulierst KEINE Anforderungen und KEINE Interpretationen — die schreibt der Auftraggeber selbst aus deinen Fakten. Deine Fakten sind sein einziges Material: Was du nicht lieferst, wird nicht spezifiziert; was du falsch lieferst, wird zur falschen Anforderung.\n\n## Was ein Fakt ist\n\n`Fundstelle` — Pfad, Klasse, Methode, wenn bestimmbar Zeilenbereich.\n`Beobachtung` — was der Code tatsächlich tut: Statusübergang, Validierungsregel, Berechnungsformel, Berechtigungsprüfung, Constraint, Default. Die tragende Bedingung wörtlich oder eng paraphrasiert.\n`Einstufung` — nach der Rubrik unten.\n`Modul` — die Inventar-ID, zu der der Fakt gehört.\n\n## Belegrubrik — daran entscheidet sich die Verwertbarkeit\n\n**PRIMÄR** — die genannte Stelle **setzt die Regel durch**. Man kann hingehen und die Bedingung lesen.\n> `AppRightsBL.cs, GetRightsFromCurrentUser(AppUser)` — iteriert `user.Groups` und sammelt `group.Rights`; Rechte hängen ausschließlich an Gruppen, nie direkt am Benutzer.\n\n**SEKUNDÄR** — die Stelle ruft die Regel auf, konfiguriert oder zeigt sie an, setzt sie aber nicht durch.\n> `AppUserGroupBL.cs` — verwaltet die Gruppenzuordnung, auf der die Rechteprüfung aufbaut.\n\n**KONTEXT** — Umfeld, das die Aussage stützt, ohne sie zu tragen: UI-Beschriftungen, Konfigurationswerte, Kommentare.\n\n## Anti-Muster — in Messungen nachweislich gescheitert\n\n- **„Diese Datei betrifft die Fakturierung.“** Ein Dateiverweis ist kein Fakt. Gefordert ist die Stelle **mit Bedingung**, etwa: `InvoiceService.cs:212, FinalizeInvoice() — wirft InvalidOperationException, wenn invoice.Status == InvoiceStatus.Paid`.\n- **„Ich öffne ein bis drei repräsentative Dateien.“** Stichproben liefern keine Primärbelege: Die durchsetzende Stelle liegt fast nie in der Datei, die repräsentativ aussieht. Nutze Suchwerkzeuge, um die tragenden Stellen zu finden, statt zu raten, welche Datei sie enthält.\n- **Aufwärtsrunden der Einstufung.** Was du nicht als durchsetzende Stelle gelesen hast, ist nicht `PRIMÄR`. Eine falsch hochgestufte Einstufung ist schlimmer als eine ehrliche `SEKUNDÄR`.\n\n## Pflichtquellen\n\n- **Das Datenbankschema.** Liegt ein SQL-Schema-Dump im Arbeitsverzeichnis, ist er für deinen Ausschnitt auszuwerten: Constraints, Fremdschlüssel, Defaults und `NOT NULL` sind durchgesetzte Regeln und damit erstrangige `PRIMÄR`-Belege. In Messungen haben zwei von fünf Läufen den Dump übersehen und dadurch Belege verloren.\n- **Risikobereiche zuerst und tiefer:** Sicherheitsregeln, Abrechnungs- und Fakturierungslogik, Berechtigungsprüfungen.\n\n## Was du ausdrücklich melden musst\n\n- **Nicht gefundene Durchsetzung.** Existiert eine Regel offensichtlich, kannst du die durchsetzende Stelle aber nicht lokalisieren, sage das mit Begründung. Diese Meldungen werden zu ausgewiesenen Hypothesen. Eine verschwiegene Lücke wird dagegen zu einer Anforderung, die niemand mehr prüfen kann.\n- **Widersprüche.** Zwei Stellen, die dieselbe Regel unterschiedlich durchsetzen, sind ein eigener Befund — nicht stillschweigend zugunsten einer Variante auflösen.\n- **Nicht implementiertes.** Methoden, die nur `throw new NotImplementedException(...)` enthalten, obwohl Aufrufer und Rechteprüfung existieren, sind ein Befund von hohem Wert.\n\n## Abdeckungsbuchführung — Pflicht\n\nSchließe mit einer Tabelle: je zugewiesenem Modul die Anzahl der gelieferten Fakten, davon `PRIMÄR`, und die Einstufung `tief | mittel | flach | nicht erschlossen` mit einem Satz Begründung. Module ohne einen einzigen Fakt sind namentlich zu nennen.\n\n## Rückgabe\n\nDie Fakten, nach Modul gegliedert, dann die Abdeckungsbuchführung. Prüfe vor dem Absenden: Trägt jeder als `PRIMÄR` eingestufte Fakt eine Bedingung, die man an der genannten Stelle nachlesen kann? Wenn nicht, stufe ihn herunter.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"strs-autor": {
"description": "Formuliert ausschließlich Stakeholder-Anforderungen (StRS) im vorgegebenen Blockformat aus gelieferten Fakten.",
"mode": "subagent",
"model": "tensorx/qwen/qwen3.8-flash-next",
"prompt": "Du formulierst **ausschließlich Stakeholder-Anforderungen (StRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nStRS beschreibt die **fachliche Sicht**: Akteure, Geschäftsziele, Geschäftsregeln, fachliche Ergebnisse. Nicht, wie das System das technisch löst.\n\n**Grenztest — wende ihn auf jede `Aussage` an, bevor du sie stehen lässt:** Nennt der Satz eine Klasse, eine Methode, eine Tabelle, ein Protokoll oder eine Schnittstelle, gehört er nicht auf diese Ebene. Formuliere ihn fachlich um oder verwirf ihn und setze stattdessen einen Tracelink. Der Fakt darf und soll technisch sein — die `Aussage` nicht.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg.** Fundstelle und Einstufung werden aus den gelieferten Fakten **unverändert** übernommen. Du stufst nichts hoch und erfindest nichts. Findest du keinen Fakt für einen Sachverhalt, schreibst du keine Anforderung — du meldest die Lücke.\n- **`Fakt` und `Aussage` sind zwei verschiedene Dinge.** `Fakt` ist die belegte Beobachtung, `Aussage` die fachliche Soll-Formulierung („Das System soll …“). Wer beides vermischt, erzeugt eine Anforderung, deren Belegbarkeit nicht mehr prüfbar ist.\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen einen `PRIMÄR`-Beleg **oder** `[HYPOTHESE]` in `Status`. Einen dritten Weg gibt es nicht. Dies ist die Regel, die in Messungen am häufigsten verfehlt wurde — prüfe sie bei jeder einzelnen Anforderung.\n- **Belege mehrfach, wo die Faktenlage es hergibt.** Ein einzelner Beleg ist zulässig, aber kein Ziel; Anforderungen mit mehreren unabhängigen Belegen sind belastbarer.\n- **`Prüfidee` ist Pflicht** und muss ein prüfbares Kriterium nennen. „Wird getestet“ ist keine Prüfidee. „Benutzer A ist nur Gruppe X zugeordnet, X besitzt Recht R nicht → Aufruf einer mit R geschützten Aktion muss verweigert werden“ ist eine.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, niemals im Feld `Typ`.\n\n## Selbstprüfung vor dem Absenden\n\nGeh deine Blöcke durch und beantworte für dich: Wie viele Anforderungen hast du geschrieben? Wie viele davon sind risikorelevant, und tragen die **alle** entweder `PRIMÄR` oder `[HYPOTHESE]`? Gibt es doppelte IDs? Nenne diese drei Zahlen am Ende deiner Rückgabe.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die drei Zahlen der Selbstprüfung und eine Liste der Sachverhalte, für die dir Fakten fehlten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"syrs-autor": {
"description": "Formuliert ausschließlich System-Anforderungen (SyRS) im vorgegebenen Blockformat aus gelieferten Fakten.",
"mode": "subagent",
"model": "tensorx/qwen/qwen3.8-flash-next",
"prompt": "Du formulierst **ausschließlich System-Anforderungen (SyRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nSyRS beschreibt das **beobachtbare Systemverhalten an den Systemgrenzen**: Schnittstellen, Statusmaschinen, Validierungen, Performance- und Sicherheitsverhalten.\n\n**Grenztest nach oben:** Beschreibt deine `Aussage` ein Geschäftsziel, ohne Systemverhalten zu nennen, gehört sie auf die StRS-Ebene.\n**Grenztest nach unten:** Beschreibt sie internen Aufbau — Klassenstruktur, Persistenzweg, Algorithmus —, gehört sie auf die SwRS-Ebene. Verwende Tracelinks statt die Grenze zu überschreiten.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg;** Fundstelle und Einstufung unverändert übernehmen, nichts hochstufen.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Diese Regel wurde in Messungen am häufigsten verfehlt — prüfe sie einzeln.\n- **Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung** in `Tracelinks`. Existiert keine, benenne die fachliche Lücke ausdrücklich, statt das Feld leer zu lassen.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, nicht im `Typ`. Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.\n- **`Prüfidee` ist Pflicht** und nennt ein prüfbares Kriterium.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl geschriebener Anforderungen; Anzahl risikorelevanter und ob **alle** gedeckt sind; Anzahl ohne StRS-Tracelink. Nenne die drei Zahlen am Ende.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"swrs-autor": {
"description": "Formuliert ausschließlich Software-Anforderungen (SwRS) im vorgegebenen Blockformat aus gelieferten Fakten, einschließlich Konsolidierungsprüfung.",
"mode": "subagent",
"model": "tensorx/qwen/qwen3.8-flash-next",
"prompt": "Du formulierst **ausschließlich Software-Anforderungen (SwRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene\n\nSwRS beschreibt die **softwareinterne Sicht**: Komponenten, Datenmodelle, Persistenzregeln, interne Algorithmen und Berechnungsvorschriften, softwareinterne Constraints. Was an der Systemgrenze beobachtbar ist, gehört auf die SyRS-Ebene.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg;** nichts hochstufen, nichts erfinden.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Einzeln prüfen.\n- **Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung** in `Tracelinks`.\n- **Datenbank-Constraints sind erstrangige Belege.** Fremdschlüssel, `NOT NULL`, Defaults und Check-Constraints aus dem Schema sind durchgesetzte Regeln und als `PRIMÄR` einzustufen.\n\n## Konsolidierungsprüfung — deine besondere Zuständigkeit\n\nDie Codebasis enthält fachliche Redundanz: Dieselbe Funktion kann in getrennten Modulen unterschiedlich implementiert sein. Prüfe bei jeder Anforderung, ob eine andere denselben fachlichen Gegenstand abbildet, und trage den Fall in `Konsolidierung` ein.\n\n**Kalibrierung.** Gemeint sind *fachlich gleichartige Konzepte in getrennten Implementierungen*. Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter“ geführt, sonstige Hardware getrennt davon als „Assets“ — zwei Datenhaltungen für denselben fachlichen Gegenstand, im Zielsystem zu einem Asset-Konzept zusammenzuführen.\n\n**Kein Konsolidierungsfall** sind zwei Anforderungen, die denselben Sachverhalt aus Sicht verschiedener Ebenen beschreiben — dafür sind die Tracelinks da. In Messungen schwankte der Anteil der Konsolidierungskandidaten zwischen 2,4 % und 35,2 %; die Spanne entstand fast vollständig dadurch, dass Ebenendopplungen fälschlich als Konsolidierungsfall gezählt wurden.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl Anforderungen; Anzahl risikorelevanter und ob alle gedeckt; Anzahl Konsolidierungskandidaten und für zwei davon je ein Satz, warum es sich um getrennte Implementierungen desselben Gegenstands handelt.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"belegpruefer": {
"description": "Prüft die ihm zugewiesenen Belege gegen die Codebasis, indem er die zitierte Stelle öffnet und die Einstufung nachrechnet. Der Umfang der Prüfung ist genau das, was ihm zugewiesen wird. Korrigiert nichts, meldet Abweichungen.",
"mode": "subagent",
"model": "tensorx/qwen/qwen3.8-flash-next",
"prompt": "Du prüfst Belege gegen die Codebasis. Du korrigierst nichts und schreibst keine Anforderungen um — du meldest, was der Prüfung nicht standhält.\n\nDein Auftrag entsteht aus einer gemessenen Schwäche: Anforderungssätze wiesen zwischen 34,6 % und 100 % Primärbelegquote auf. Eine hohe Quote ist wertlos, wenn die Einstufung nicht trägt. Du prüfst, ob sie trägt.\n\n## Vorgehen\n\nFür jeden dir zugewiesenen Beleg:\n\n1. **Öffne die zitierte Stelle.** Existiert die Datei? Die Klasse? Die Methode? Stimmt der Zeilenbereich ungefähr?\n2. **Lies die genannte Bedingung.** Steht dort tatsächlich, was der Beleg behauptet?\n3. **Prüfe die Einstufung.** Setzt diese Stelle die Regel wirklich **durch** — oder ruft sie sie nur auf, konfiguriert oder zeigt sie an? Letzteres ist `SEKUNDÄR`, nicht `PRIMÄR`.\n4. **Prüfe die Deckung.** Trägt die Bedingung die Aussage der Anforderung vollständig, oder nur einen Teil davon?\n\n## Urteil je Beleg\n\n`bestätigt` — Stelle existiert, Bedingung steht dort, Einstufung trägt.\n`einstufung zu hoch` — Stelle existiert, setzt die Regel aber nicht durch. Nenne die korrekte Einstufung.\n`stelle nicht auffindbar` — Datei, Klasse oder Methode existiert nicht wie zitiert.\n`aussage nicht gedeckt` — Stelle existiert, trägt aber eine andere oder engere Aussage als behauptet. Beschreibe die Abweichung.\n\n## Harte Regeln\n\n- **Urteile nur, was du gelesen hast.** Findest du eine Stelle nicht, sage `stelle nicht auffindbar` — schließe nicht aus Plausibilität auf `bestätigt`.\n- **Sei streng bei der Einstufung.** Im Zweifel `einstufung zu hoch`. Ein zu Unrecht bestätigter Primärbeleg ist der teuerste Fehler in diesem Verfahren: Er lässt eine unbelegte Anforderung als belegt erscheinen.\n- **Kürze nichts ab.** Kein „und weitere“. Jeder zugewiesene Beleg bekommt ein Urteil.\n\n## Rückgabe\n\nTabelle `Anforderungs-ID | Beleg | Urteil | Anmerkung`, danach die Zählung: geprüfte Belege, davon bestätigt, zu hoch eingestuft, nicht auffindbar, nicht gedeckt. Bei null Beanstandungen sage das ausdrücklich. Nenne außerdem, wie viele Belege dir zugewiesen wurden und — soweit dir mitgeteilt — auf welchen Gesamtbestand sie sich beziehen. Ohne diese Bezugsgröße ist deine Zählung nicht einzuordnen.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"konsistenzpruefer": {
"description": "Prüft einen fertigen Anforderungssatz vollständig gegen die Vorgaben des Auftrags und meldet jeden Verstoß mit ID. Korrigiert nichts.",
"mode": "subagent",
"model": "tensorx/qwen/qwen3.8-flash-next",
"prompt": "Du prüfst einen fertigen Anforderungssatz gegen die Vorgaben des Auftrags. Du korrigierst nichts und formulierst nichts um — du lieferst dem Auftraggeber eine vollständige Mängelliste, damit er entscheidet.\n\nPrüfe **vollständig und mit absoluten Zahlen**, nicht beispielhaft. Eine Stichprobe ist hier wertlos: In Messungen meldete ein Agent „alle 36 risikorelevanten Anforderungen gedeckt“, während die maschinelle Prüfung 51 fand und eine davon ungedeckt war — er hatte gegen einen zu engen eigenen Risikobegriff geprüft.\n\n## Prüfpunkte\n\n1. **Belegpflicht** — Anforderungen ohne jeden Beleg. Jede ID nennen.\n2. **Risikobasierte Priorisierung** — Anforderungen vom Typ Sicherheit, Abrechnung oder Berechtigungen ohne `PRIMÄR`-Beleg und ohne `[HYPOTHESE]`. **Gehe hier Anforderung für Anforderung vor, nicht überschlägig.** Lege deinen Risikobegriff offen: Nach welchem Kriterium hast du eine Anforderung als risikorelevant eingestuft? Ein enger Begriff lässt Verstöße unentdeckt.\n3. **Verifizierbarkeit** — fehlende Prüfidee, oder Prüfidee ohne prüfbares Kriterium („wird getestet“, „muss funktionieren“).\n4. **Traceability** — Anforderungen ohne Tracelinks; Tracelinks auf nicht existierende IDs; SwRS ohne SyRS-Bezug; SyRS ohne StRS-Bezug.\n5. **Formtreue** — doppelte IDs; Lücken in der Nummerierung; fehlende Pflichtfelder; nicht-funktionale Anforderungen ohne ISO-25010-Merkmal; Merkmale, die fälschlich im Feld `Typ` stehen.\n6. **Ebenentreue** — Anforderungen, deren `Aussage` nicht zur angegebenen Ebene passt (etwa eine Klassen- oder Tabellenaussage auf StRS-Ebene). Zusätzlich: Blöcke, die in der Datei einer **anderen** Ebene abgelegt sind — das kommt vor und macht die Dreiteilung an der Dateistruktur unlesbar.\n7. **Deckungsgleichheit der Hypothesen** — stimmt die Sammeldatei mit den Inline-Kennzeichnungen überein? Nenne Differenzen in beide Richtungen.\n8. **Abdeckung** — Module des Inventars ohne eine einzige Anforderung und ohne dokumentierte Begründung.\n9. **Ergebnisstruktur** — Es dürfen ausschließlich die sieben vorgegebenen Dateien existieren (`StRS.md`, `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`, `Analysebericht.md`). Nenne jede zusätzliche Datei und die Zahl der darin liegenden Anforderungen — sie werden von der Auswertung nicht erfasst.\n10. **Erkundungstiefe** — Anteil der Module, die als `nicht analysiert` geführt werden, in absoluten Zahlen und in Prozent. Über 10 % ist ein Hinweis auf unvollständige Erkundung.\n11. **Zuständigkeitsbindung** — Ist im `Analysebericht.md` festgehalten, welcher Bearbeiter für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt wurde? Nenne jede Teilaufgabe, für die ein Bearbeiter vorgesehen war und die laut Bericht dennoch selbst ausgeführt wurde, sowie jede Teilaufgabe, zu der die Angabe ganz fehlt. Beides ist ein Verstoß; eine nicht offengelegte Abweichung wiegt schwerer als eine begründete.\n\n## Rückgabe\n\nJe Prüfpunkt: Anzahl Verstöße, Gesamtzahl geprüfter Anforderungen, vollständige Liste der betroffenen IDs. Danach eine Gesamtzählung. Bei null Verstößen in einem Punkt sage das ausdrücklich.\n\nSchätze nichts. Kürze keine Liste mit „und weitere“ ab. Wenn du einen Prüfpunkt nicht vollständig prüfen konntest, sage welchen und warum — das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"iso29148-orchestrator": {
"description": "Prüft den zusammengeführten Bestand der drei Ebenen gegen die Anforderungen an eine Spezifikation nach ISO/IEC/IEEE 29148 und liefert einen Übergabebericht mit konkreten, ausführbaren Anweisungen. Formuliert keine neuen Anforderungen und ändert nichts selbst.",
"mode": "subagent",
"model": "tensorx/qwen/qwen3.8-flash-next",
"prompt": "Du prüfst, ob die Teilergebnisse der drei Ebenen **eine** Spezifikation nach ISO/IEC/IEEE 29148 ergeben, und lieferst deinem Auftraggeber die Anweisungen, die dazu noch fehlen. Du formulierst **keine neuen Anforderungen**, änderst keine Aussagen und schreibst keine Dateien — du lieferst einen Übergabebericht, den dein Auftraggeber ausführt.\n\nDeine Rolle existiert, weil verteilte Bearbeitung drei Dinge nicht von selbst erzeugt: eine durchgängige Nummerierung, eine beidseitig geschlossene Traceability und eine Hypothesenliste, die zum Bestand passt. Keines davon ist am Teilbestand feststellbar — nur am zusammengeführten.\n\n## Was du prüfst und wozu du anweist\n\n1. **Durchgängige Nummerierung.** Je Ebene lückenlos, ohne Doppelvergabe. Ist umzunummerieren, lieferst du die vollständige Zuordnung `alt → neu` **und** die Liste aller Stellen, die mitzuziehen sind: Tracelinks, Traceability-Tabelle, Hypothesenliste, Abdeckungstabelle. Eine halb gezogene Umnummerierung ist schlimmer als die Lücke — liefere die Liste vollständig oder benenne, warum du sie nicht vollständig aufstellen konntest.\n2. **Beidseitige Traceability.** Jede SwRS verweist auf ihre SyRS, jede SyRS auf ihre StRS. Nenne jeden Verweis, der ins Leere zeigt, und jede Anforderung ohne Gegenstück — ein Ziel erfindest du nicht. Für die konsolidierte Tabelle `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg` lieferst du die Zeilen, die aus dem vorliegenden Bestand belegbar sind.\n3. **Deckungsgleiche Hypothesenliste.** Die Sammeldatei muss exakt die Anforderungen enthalten, die inline als `[HYPOTHESE]` gekennzeichnet sind. Prüfe in beide Richtungen und nenne beide Differenzmengen mit IDs.\n4. **Abdeckungstabelle über das gemeinsame Inventar.** Jedes Modul mit der Zahl der auf es entfallenden Anforderungen. Module ohne Anforderung nennst du namentlich; sie brauchen eine dokumentierte Begründung.\n5. **Ergebnisstruktur.** Es dürfen ausschließlich die sieben vorgegebenen Dateien existieren. Melde zusätzliche Dateien, fehlende Dateien und Blöcke, die in der Datei einer anderen Ebene abgelegt sind.\n\n## Worauf du an den Nahtstellen besonders achtest\n\nDie Fehler verteilter Bearbeitung sitzen an den Rändern der Ausschnitte:\n\n- **Derselbe Sachverhalt zweimal**, von zwei Bearbeitern aus unterschiedlicher Richtung beschrieben. Das ist kein Konsolidierungsfall im fachlichen Sinn, sondern eine Doublette — melde sie als solche, mit beiden IDs.\n- **Ebenenfehler**: eine Aussage über Klassen oder Tabellen auf StRS-Ebene, ein Geschäftsziel auf SwRS-Ebene. Du meldest den Fall und nennst die Zielebene, verschiebst ihn aber nicht — beim Verschieben müsste die Aussage umformuliert werden, und das ist Sache des zuständigen Autors.\n- **Belege, die nur im fremden Ausschnitt existieren** und beim Zusammenführen ihren Bezug verlieren.\n\n## Harte Regeln\n\n- **Keine neue Anforderung, keine geänderte `Aussage`, keine hochgestufte Belegeinstufung, keine Datei.** Fällt dir eine Lücke auf, meldest du sie.\n- **Kein stilles Löschen und kein stilles Zusammenführen.** Doubletten werden gemeldet, mit beiden Ursprungs-IDs; ob zusammengeführt wird, entscheidet dein Auftraggeber.\n- **Zähle, statt zu schätzen.** Jede Aussage über den Bestand nennt absolute Zahlen. Kürze keine Liste mit „und weitere\" ab.\n- **Konntest du einen Punkt nicht vollständig prüfen** — etwa weil dir ein Teilbestand nicht vorliegt —, sage welchen und warum. Das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht.\n\n## Rückgabe\n\nDer Übergabebericht: Anzahl Anforderungen je Ebene, die Umnummerierungsanweisungen samt mitzuziehender Verweise, geschlossene und offene Tracelinks, die Zeilen der Traceability-Tabelle, Differenzen zwischen Hypothesenliste und Inline-Kennzeichnung, Module ohne Anforderung, gefundene Doubletten und Ebenenfehler — jeweils mit IDs.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
}
},
"default_agent": "build"
}
Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/opencode-session.json
+9844
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/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T14:03:38.8465630+02:00
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Adapter.log
+5
View File
@@ -0,0 +1,5 @@
[2026-09-02T08:42:44.122853+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\Ergebnisse)
[2026-09-02T08:42:44.241827+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=custom; Effort=high (uebergeben=True); Stall-Timeout=0s
[2026-09-02T10:51:52.441929+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
[2026-09-02T10:51:54.138218+00:00] OpenCode export: Exporting session: ses_f9eb70d9bffeU6O643v8e3i1th
[2026-09-02T10:51:54.222501+00:00] Ende: Exitcode=0; Status=success; Turns=45; Tokens=11467996; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\RawResult.json
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/Analysebericht.md
+360
View File
@@ -0,0 +1,360 @@
# Analysebericht
Reverse Requirements Engineering - c-entron ERP-Suite (V2, agentengestützt, verteilt). Zeistempel des Laufs: 2026-09-02. Arbeitsverzeichnis: `02_Lauf_2026-09-02_104242_v13.0.0-b971\_meta\spiegel` (Spiegel der Codebasis; `src` ist ein Windows-Junction auf den Quellcode). Es entstehen genau die sieben vorgegebenen Dateien (StRS.md, SyRS.md, SwRS.md, Traceability.md, Hypothesen.md, Glossar.md, Analysebericht.md).
## 1. Modulinventar (Schritt 0)
Erstellt durch den Bearbeiter **modulinventar** vor der ersten Anforderung; Bezugsgröße der Abdeckung. 141 Module (111 fachlich / 30 technisch), 15.268 zugeordnete Quelldateien (.cs/.razor ohne bin/obj/packages), Differenz zu 15.273 Gesamtquelldateien: 5 BL-Basisdateien im Projektroot (BaseBL, BLSession, DBBaseBL, SystemInfoLogger, AssemblyInfo - BL-Infrastruktur, keinem Fachordner zugeordnet).
| Modul | Pfad | Fachliche Aufgabe | Dateien (ca.) |
|---|---|---|---|
| M001 Accounting | src\backend\Centron.BL\Accounting | Bankverbindungslogik (BankAccountBL). | 1 |
| M002 Accounts | src\backend\Centron.BL\Accounts | Adressstamm Kunden/Lieferanten, Adressen, Kontakte, Suche. | 29 |
| M003 Administration | src\backend\Centron.BL\Administration | Lizenzen, Benutzerrechte, Logins, Mandanten, Mitarbeiter, SQL-Verwaltung. | 959 |
| M004 AppointmentRequests | src\backend\Centron.BL\AppointmentRequests | Terminanfragen. | 1 |
| M005 ArtificialIntelligence | src\backend\Centron.BL\ArtificialIntelligence | KI-Chatdienste, Modellkatalog, Link-Validierung. | 25 |
| M006 BusinessPartner | src\backend\Centron.BL\BusinessPartner | Lieferantensuche und Lieferanten-Assets. | 2 |
| M007 Buying | src\backend\Centron.BL\Buying | Großhändler/Distributoren. | 1 |
| M008 Calendar | src\backend\Centron.BL\Calendar | Kalenderlogik. | 1 |
| M009 CentronIcons | src\backend\Centron.BL\CentronIcons | Zentrale Icons inkl. Webservice-Abgleich. | 2 |
| M010 CentronNexus (BL) | src\backend\Centron.BL\CentronNexus | BL-Anbindung Nexus-Webclient. | 1 |
| M011 ChangeTracking | src\backend\Centron.BL\ChangeTracking | Änderungsverfolgung über Import-Historien. | 1 |
| M012 Chats | src\backend\Centron.BL\Chats | Chatlogik. | 1 |
| M013 CheckListArea | src\backend\Centron.BL\CheckListArea | Checklisten inkl. Kaskade und Änderungsprotokoll. | 3 |
| M014 Core (BL) | src\backend\Centron.BL\Core | Krypto- und Platzhalterhelfer. | 2 |
| M015 CountryArea | src\backend\Centron.BL\CountryArea | Länder- und Bundeslandstammdaten. | 2 |
| M016 CPra | src\backend\Centron.BL\CPra | Konfiguration/Connector externer CPra-Dienst. | 2 |
| M017 CustomerArea | src\backend\Centron.BL\CustomerArea | Branchen, Kontaktaktivitäten, Interessen, RMA. | 7 |
| M018 Customizations | src\backend\Centron.BL\Customizations | Kundenspezifische Tabellen. | 1 |
| M019 DataExchange | src\backend\Centron.BL\DataExchange | Buchhaltungs-Export/-Import, DocBee-Connector. | 23 |
| M020 Devices | src\backend\Centron.BL\Devices | Kundengeräte. | 1 |
| M021 DocuBoard | src\backend\Centron.BL\DocuBoard | Asset-Zuordnungen zu Artikeln/Partnern, AD-Ausschlüsse. | 3 |
| M022 DocumentationArea | src\backend\Centron.BL\DocumentationArea | Dokumentationsverwaltung. | 1 |
| M023 EDI | src\backend\Centron.BL\EDI | EDI-Dispatcher und Händler-Bestelllogik. | 27 |
| M024 EmployeeArea | src\backend\Centron.BL\EmployeeArea | Mitarbeiter, Urlaubsdaten, RFID-Tokens, Abteilungen. | 9 |
| M025 Exceptions | src\backend\Centron.BL\Exceptions | Zentrale BL-Exception-Typen. | 1 |
| M026 ExpectedEvents | src\backend\Centron.BL\ExpectedEvents | Erwartete Events (automatisierte Ereignisprüfung). | 1 |
| M027 ExternalHelpdesk | src\backend\Centron.BL\ExternalHelpdesk | Konfiguration externer Helpdesks. | 1 |
| M028 ExternalToolsBL | src\backend\Centron.BL\ExternalToolsBL | Externe Werkzeuge (URL-Vorlagen). | 1 |
| M029 Finances | src\backend\Centron.BL\Finances | Zahlungseingänge, Online-Banking, Produktlebenszyklen. | 9 |
| M030 Gateway (BL) | src\backend\Centron.BL\Gateway | Benutzerdefinierte Gateways (Sonderartikel-Import). | 1 |
| M031 GUI (BL) | src\backend\Centron.BL\GUI | Benutzergrids, UI-Profile, Session-Logging. | 6 |
| M032 Helpers (BL) | src\backend\Centron.BL\Helpers | Graph-Service, PDF/Word, Bilder. | 6 |
| M033 IndexSearch | src\backend\Centron.BL\IndexSearch | Volltextindex mit deutscher Analyse. | 7 |
| M034 Integrations | src\backend\Centron.BL\Integrations | Kundengruppen/Rollen eines externen Systems. | 2 |
| M035 ItPlanner | src\backend\Centron.BL\ItPlanner | IT-Planer, virtuelle Objektkategorien. | 1 |
| M036 Logistics | src\backend\Centron.BL\Logistics | Lagereinstellungen, Bestandslogik. | 2 |
| M037 Mail | src\backend\Centron.BL\Mail | E-Mail (Exchange/EWS/SMTP/Graph), Signaturen, Domänen-Blacklist. | 20 |
| M038 Mailings | src\backend\Centron.BL\Mailings | Serienmailing-Daten und -Vorlagen. | 2 |
| M039 MailScanner | src\backend\Centron.BL\MailScanner | Virtueller Mailassistent (VMA). | 1 |
| M040 MassUpdate | src\backend\Centron.BL\MassUpdate | Massenaktualisierung von Daten. | 1 |
| M041 Mobile | src\backend\Centron.BL\Mobile | Mobile Clients. | 1 |
| M042 Modules | src\backend\Centron.BL\Modules | Lizenzierbare Module und Kategorien. | 3 |
| M043 MyCentron (BL) | src\backend\Centron.BL\MyCentron | Dashboard, Kurznotizen, zuletzt verwendet. | 4 |
| M044 MyDay | src\backend\Centron.BL\MyDay | „Mein Tag"-Arbeitsplatz, Webservice, Berichtskonnektoren. | 7 |
| M045 NexusNotifications | src\backend\Centron.BL\NexusNotifications | Benachrichtigungsversand an Nexus. | 2 |
| M046 NexusTicketViews | src\backend\Centron.BL\NexusTicketViews | Ticket-Ansichten für Nexus. | 1 |
| M047 Notifications | src\backend\Centron.BL\Notifications | Benutzer- und Systembenachrichtigungen. | 2 |
| M048 ObjectExternalReferences | src\backend\Centron.BL\ObjectExternalReferences | Fremdreferenzen zu c-entron-Objekten. | 1 |
| M049 Outlook | src\backend\Centron.BL\Outlook | Outlook-seitige Asset-/Objektsuche. | 1 |
| M050 PasswordManagementArea | src\backend\Centron.BL\PasswordManagementArea | Passwort-Management mit Zugriffs-Logs. | 6 |
| M051 PasswordManager | src\backend\Centron.BL\PasswordManager | Passwort-Manager (Richtlinien, Export). | 1 |
| M052 Processes | src\backend\Centron.BL\Processes | Prozessverwaltung (Workflow-Schritte). | 1 |
| M053 Production | src\backend\Centron.BL\Production | Produktion und Produktionsaufträge. | 2 |
| M054 ProductMatrix | src\backend\Centron.BL\ProductMatrix | Produktmatrix-Logik. | 1 |
| M055 Projects | src\backend\Centron.BL\Projects | Projektverwaltungslogik. | 1 |
| M056 Purchasing | src\backend\Centron.BL\Purchasing | Lieferanten, Bestellvorschlagsliste, Filial-Kalkulation. | 4 |
| M057 ReportEngine | src\backend\Centron.BL\ReportEngine | Report-Engine (FastReport), Reportdaten-Abfragen. | 26 |
| M058 Reporting | src\backend\Centron.BL\Reporting | Berichtslogik (Legacy). | 1 |
| M059 RiverDivo | src\backend\Centron.BL\RiverDivo | River/Divo-RMM-Anbindung. | 4 |
| M060 Sales | src\backend\Centron.BL\Sales | Belege (Receipts), Kassenbücher, Kunden, Marketing, Support/Helpdesk. | 248 |
| M061 Security | src\backend\Centron.BL\Security | PDF-Signierung. | 1 |
| M062 SelfCare | src\backend\Centron.BL\SelfCare | Kundenportal-/Webformularlogik. | 2 |
| M063 Services | src\backend\Centron.BL\Services | Hintergrund-/Connectordienste (CachedTables, cTime, DirectoryCheck). | 11 |
| M064 SocialMedia | src\backend\Centron.BL\SocialMedia | Personen-Verknüpfung soziale Netzwerke. | 3 |
| M065 Start | src\backend\Centron.BL\Start | Start-/Initialisierungslogik. | 1 |
| M066 Statistics | src\backend\Centron.BL\Statistics | Umsatz, Mitarbeiterauslastung, Verträge. | 16 |
| M067 Storage | src\backend\Centron.BL\Storage | Lager-/Inventur-Altbestand (stillgelegt). | 2 |
| M068 SystemArea | src\backend\Centron.BL\SystemArea | Zugriff auf Systemtabellen. | 1 |
| M069 Tags | src\backend\Centron.BL\Tags | Verschlagwortung von Objekten. | 1 |
| M070 Tapi | src\backend\Centron.BL\Tapi | TAPI-Telefonie, Anrufprotokolle. | 1 |
| M071 TaskManager | src\backend\Centron.BL\TaskManager | Aufgabenverwaltung mit Helpdesk-Aktionstypen. | 4 |
| M072 Telemetry | src\backend\Centron.BL\Telemetry | Telemetrie-/Diagnoselogik. | 1 |
| M073 TextModuleArea | src\backend\Centron.BL\TextModuleArea | Textbausteine, Anrede-/Grußformel-Ersetzung. | 2 |
| M074 TicketProjects | src\backend\Centron.BL\TicketProjects | Projektzuordnung von Tickets. | 1 |
| M075 Time | src\backend\Centron.BL\Time | Einstellungen Zeiterfassung/Timing. | 1 |
| M076 ToDoArea | src\backend\Centron.BL\ToDoArea | To-do-Verwaltung über Objektarten. | 2 |
| M077 Tools | src\backend\Centron.BL\Tools | Werkzeuglogik (Textformate). | 1 |
| M078 TradePool | src\backend\Centron.BL\TradePool | Handelsverbund-Logik mit XML-Austausch. | 2 |
| M079 Transactions | src\backend\Centron.BL\Transactions | Spesen-/Transaktionsbuchungen. | 1 |
| M080 TwoFactorAuthenticator | src\backend\Centron.BL\TwoFactorAuthenticator | Zwei-Faktor-Authentifizierung (TOTP). | 1 |
| M081 Urls | src\backend\Centron.BL\Urls | Einfache URLs mit Webservice-Anbindung. | 2 |
| M082 VideoPortal | src\backend\Centron.BL\VideoPortal | Zuordnungen im Videoportal. | 1 |
| M083 VoucherManagement | src\backend\Centron.BL\VoucherManagement | Gutscheinbelegverwaltung. | 1 |
| M084 Warehousing | src\backend\Centron.BL\Warehousing | Artikel, Einheiten/Varianten, Aktionspreise, Bestände. | 40 |
| M085 WebLinks | src\backend\Centron.BL\WebLinks | Weblinks mit Aktionen auf Kontenaktivitäten. | 4 |
| M086 WebServices (BL-Fassade) | src\backend\Centron.BL\WebServices | *WebServiceBL je Fachbereich, bedient Webservice-Hosts. | 464 |
| M087 WebSuite | src\backend\Centron.BL\WebSuite | Webeinstellungen, Web-Helpdesk-Fragen. | 5 |
| M088 WebVersion | src\backend\Centron.BL\WebVersion | Versionsprüfung gegen den Webservice. | 1 |
| M089 Centron.Common | src\backend\Centron.Common | Hilfs-, Format-, Konstantenklassen, Debug-Sicherheit, Feature-Schalter. | 56 |
| M090 Centron.DAO | src\backend\Centron.DAO | Datenzugriff (NHibernate/ADO.NET, Mappings, Repositories). | 1129 |
| M091 Centron.Entities | src\backend\Centron.Entities | Fachliche Entitäten inkl. Webservice-Entitäten. | 1183 |
| M092 Centron.Gateway | src\backend\Centron.Gateway | EDI-Händler, OpenTrans, ZUGFeRD, Online-Banking, MspCollector. | 103 |
| M093 Centron.Interfaces | src\backend\Centron.Interfaces | Schnittstellen-/Kontraktdefinitionen, Konstanten. | 762 |
| M094 Centron.Api.EbInterface | src\apis\Centron.Api.EbInterface | Österreichische E-Rechnungen (ebInterface). | 2 |
| M095 Centron.Api.Gls | src\apis\Centron.Api.Gls | GLS-Versandanbindung. | 15 |
| M096 Centron.Api.Shipcloud | src\apis\Centron.Api.Shipcloud | Shipcloud-Versand-API. | 29 |
| M097 Centron.APIs.CopDataAccess | src\apis\Centron.APIs.CopDataAccess | SOAP-Datenzugriff CopData. | 14 |
| M098 Centron.APIs.EgisDataAccess | src\apis\Centron.APIs.EgisDataAccess | SOAP-Datenzugriff Egis. | 18 |
| M099 Centron.APIs.FinAPI | src\apis\Centron.APIs.FinAPI | REST-Client FinAPI-Bankdienstleistungen. | 70 |
| M100 Centron.APIs.IcecatDataAccess | src\apis\Centron.APIs.IcecatDataAccess | Produktstammdaten über Icecat. | 14 |
| M101 Centron.APIs.ITscopeDataAccess | src\apis\Centron.APIs.ITscopeDataAccess | Produktstammdaten über ITscope. | 22 |
| M102 Centron.WebServices.Core | src\webservice\Centron.WebServices.Core | Service-Kern (Verbindungen, REST-Requests, Interception). | 2528 |
| M103 Centron.Host | src\webservice\Centron.Host | ASP.NET-Host mit Fach- und Real-Time-Diensten. | 156 |
| M104 Centron.Host.Console | src\webservice\Centron.Host.Console | Konsolen-Startvariante. | 2 |
| M105 Centron.Host.WindowsService | src\webservice\Centron.Host.WindowsService | Windows-Dienst-Startvariante. | 3 |
| M106 Centron.Controllers | src\webservice\Centron.Controllers | Controller- und Autorisierungsschicht. | 54 |
| M107 c-entron.misc.ConnectionManager | src\webservice\c-entron.misc.ConnectionManager | Verbindungs-/SQL-Server-Prüftool. | 26 |
| M108 Centron.WPF.UI (Shell) | src\centron\Centron.WPF.UI | WPF-Shell: Modulregistrierung, Lokalisierung, Wizards, ViewModels. | 1205 |
| M109 Centron.WPF.UI.Extension | src\centron\Centron.WPF.UI.Extension | MVVM-/Erweiterungsframework (Actions, Commands, Extensibility). | 158 |
| M110 WPF-Maske: Finances | src\centron\Centron.WPF.UI\Modules\Finances | Abrechnungsmasken: Vertrags-/Ticketabrechnung, Mahnung, OPOS, SEPA, Verträge. | 1664 |
| M111 WPF-Maske: Warehousing | src\centron\Centron.WPF.UI\Modules\Warehousing | Lagermasken: Artikel, Import, Inventur, Kommissionierung. | 426 |
| M112 WPF-Maske: Administration | src\centron\Centron.WPF.UI\Modules\Administration | Verwaltungsmasken: Mandanten, Mitarbeiter, Rechte, DSGVO, SQL-Manager, Lizenzen. | 261 |
| M113 WPF-Maske: Helpdesk | src\centron\Centron.WPF.UI\Modules\Helpdesk | Ticket-Liste, Taskmanagement, Checklisten, Prozessvorlagen. | 254 |
| M114 WPF-Maske: DataExchange | src\centron\Centron.WPF.UI\Modules\DataExchange | Buchhaltungsexport/-import, DATEV, DocSync. | 178 |
| M115 WPF-Maske: MyCentron | src\centron\Centron.WPF.UI\Modules\MyCentron | Dashboard, Mein Tag, Todo, Telefonate, persönliche Einstellungen. | 169 |
| M116 WPF-Maske: Statistics | src\centron\Centron.WPF.UI\Modules\Statistics | Controlling/Analytics: Vertriebsstatistik, Management Info, MSP, Auslastung. | 111 |
| M117 WPF-Maske: Purchasing | src\centron\Centron.WPF.UI\Modules\Purchasing | Bestellvorschlagsliste, EDI-Verwaltung, Eingangsbelege. | 105 |
| M118 WPF-Maske: Global | src\centron\Centron.WPF.UI\Modules\Global | Custom Properties, MSP-Lizenzvergleich. | 89 |
| M119 WPF-Maske: OnlineBanking | src\centron\Centron.WPF.UI\Modules\OnlineBanking | FinTS/FinAPI-Konfiguration, Zuordnung Banktransaktionen. | 68 |
| M120 WPF-Maske: ArtificialIntelligence | src\centron\Centron.WPF.UI\Modules\ArtificialIntelligence | KI-Assistent-Chat und KI-Einstellungen. | 58 |
| M121 WPF-Maske: Survey | src\centron\Centron.WPF.UI\Modules\Survey | Audit-/Umfragewesen. | 46 |
| M122 WPF-Maske: Massenupdates | src\centron\Centron.WPF.UI\Modules\Massenupdates | Data-Updater für Massenaktualisierungen. | 34 |
| M123 WPF-Maske: Sales | src\centron\Centron.WPF.UI\Modules\Sales | Produktmatrix, Sonderartikel-Import zu Verträgen. | 34 |
| M124 WPF-Maske: Rma | src\centron\Centron.WPF.UI\Modules\Rma | RMA-/Werkstatt-Abwicklung. | 24 |
| M125 CentronNexus (Blazor) | src\nexus\CentronNexus | Webclient: WebCart/Shop, WebOffer, ServiceBoard, Dokument-Signierung. | 756 (296 .cs + 460 .razor) |
| M126 CentronNexus.Host | src\nexus\CentronNexus.Host | Host der Blazor-Anwendung. | 3 |
| M127 CentronNexus.OutlookAddIn | src\nexus\CentronNexus.OutlookAddIn | Outlook-Add-In mit c-entron-Funktionen. | 53 |
| M128 Centron.Controls | src\shared\Centron.Controls | WPF-Steuerelementbibliothek je Fachbereich. | 742 |
| M129 Centron.Controls.Preview | src\shared\Centron.Controls.Preview | Preview-Varianten der Steuerelemente (Test-Harness). | 43 |
| M130 Centron.Core | src\shared\Centron.Core | MVVM, TOTP/Google-Auth, PDF-Scanning, Threading. | 72 |
| M131 Datenbankschema | SSMS_DB_SCHEMA.sql | Vollständiges MSSQL-Schema (1535 dbo-Tabellen, Präfixgruppen). | 1 (76.793 Zeilen) |
| M132 Tests | tests\ | Unit-, Integrations-, E2E- und Playwright-Tests. | 378 .cs (3.659 gesamt) |
| M133 Deployment | deployment\ | Installationsbau centron/riverbird, WixSharp-Installer. | 21 |
| M134 Docker | docker\ | Images/Compose für API, Webservice, Demo, Regression. | 18 |
| M135 Scripts | scripts\ | Datenbank- und Wartungsskripte, Build-Targets. | 19 |
| M136 Azure-Pipelines | azure\ | Pipelines Build, Tests, Regression, Docker. | 13 |
| M137 Azure-Pipelines Blazor | azure-blazor\ | Pipelines Nexus: Unit-Tests, Playwright, Security-Scan. | 6 |
| M138 GitHub-Workflows | .github\ | GitHub-Actions und Workflows. | 5 |
| M139 Docs | docs\ | Projektdokumentation Architektur, Belege, Rechte, UI, Dienste. | 54 |
| M140 Centron.Api.docuFORM | Centron.Api.docuFORM\ | REST-Client DocuFORM (Geräte-/Zählerdaten). | 75 |
| M141 Assemblies | assemblies\ | Eingecheckte Fremd-Binärdateien (7pdf, Outlook, RDP, TAPI, WPF-Themes). | 9 |
Buchführung (aus dem modulinventar-Lauf): 141 Module; nicht zugeordnete Quelldateien: 5 BL-Basisdateien (oben); nicht als Quellcode gezählt: Root-Konfiguration/Build-Dateien, .vscode, nugets (13 Dritt-Pakete), ~3.281 Nicht-Code-Dateien in tests (Test-/Erwartungsdaten). Die abweichende Formulierung des M108-Eintrags im Rohinventar (fehlerhafte Tabellenzeile) wurde beim Übernehmen berichtigt.
## 2. Abdeckungstabelle
Stufe = Einstufung aus den faktenermittler-Läufen; Anzahl = Anforderungen, die aus dem Modul erzeugt wurden (alle Ebenen). Jede Inventarzeile ist vertreten; Mindestabdeckung (≥ 1 Anforderung je Modul) ist damit erfüllt.
| Modul | Stufe | Anzahl | Abgedeckt durch |
|---|---|---|---|
| M001 | mittel | 1 | SwRS-1 |
| M002 | tief | 2 | SwRS-24; StRS-19/20 |
| M003 | tief | 7 | SwRS-49/50/51/52; StRS-1/3; SyRS-1..6 |
| M004 | mittel | 1 | SwRS-116 |
| M005 | mittel | 2 | SwRS-53; StRS-4 |
| M006 | mittel | 1 | SwRS-25 |
| M007 | flach | 1 | SwRS-36 |
| M008 | flach | 1 | SwRS-117 |
| M009 | flach | 1 | SwRS-118 |
| M010 | flach | 1 | SwRS-89 |
| M011 | flach | 1 | SwRS-119 |
| M012 | tief | 1 | SwRS-120 |
| M013 | tief | 2 | SwRS-15; StRS-19 |
| M014 | mittel | 2 | SwRS-140; SwRS-122 (ReplacementBL) |
| M015 | mittel | 2 | SwRS-26; StRS-20 |
| M016 | mittel | 1 | SwRS-121 |
| M017 | mittel | 2 | SwRS-27; StRS-18 |
| M018 | flach | 1 | SwRS-122 (CustomTableBL) |
| M019 | mittel | 4 | SwRS-2/3; StRS-9/11 |
| M020 | mittel | 2 | SwRS-28; StRS-19 |
| M021 | mittel | 1 | SwRS-123 |
| M022 | tief | 1 | SwRS-124 |
| M023 | mittel | 2 | SwRS-37; StRS-21 |
| M024 | mittel | 4 | SwRS-61/62; StRS-3/26 |
| M025 | flach | 1 | SwRS-125 |
| M026 | mittel | 1 | SwRS-126 |
| M027 | flach | 2 | SwRS-127/128 |
| M028 | flach | 1 | SwRS-29 |
| M029 | mittel | 5 | SwRS-4/5/6; StRS-3/8 |
| M030 | tief | 1 | SwRS-63 |
| M031 | mittel | 3 | SwRS-64/107; StRS-2 |
| M032 | mittel | 1 | SwRS-129 |
| M033 | tief | 2 | SwRS-130; SyRS-34 |
| M034 | mittel | 1 | SwRS-65 |
| M035 | mittel | 2 | SwRS-16; StRS-19 |
| M036 | mittel | 3 | SwRS-38; StRS-18/21 |
| M037 | tief | 4 | SwRS-131; StRS-15; SyRS-31; (Kanal/SMTP in SyRS-29/30) |
| M038 | mittel | 1 | SwRS-132 |
| M039 | tief | 2 | SwRS-133; StRS-3 |
| M040 | tief | 3 | SwRS-66/108; StRS-13 |
| M041 | flach | 1 | SwRS-89 |
| M042 | flach | 1 | SwRS-54 |
| M043 | mittel | 1 | SwRS-67 |
| M044 | tief | 2 | SwRS-68; StRS-26 |
| M045 | tief | 2 | SwRS-90; SyRS-32 |
| M046 | tief | 1 | SwRS-91 |
| M047 | mittel | 2 | SwRS-92; SyRS-33 |
| M048 | mittel | 2 | SwRS-30; StRS-20 |
| M049 | flach | 1 | SwRS-93 |
| M050 | mittel | 2 | SwRS-55; StRS-5 |
| M051 | mittel | 2 | SwRS-55; StRS-5/25 |
| M052 | mittel | 1 | SwRS-134 |
| M053 | tief | 2 | SwRS-39; StRS-25 |
| M054 | mittel | 1 | SwRS-40 |
| M055 | flach | 1 | SwRS-135 |
| M056 | tief | 2 | SwRS-41; StRS-21 |
| M057 | tief | 4 | SwRS-136/137; StRS-30; SwRS-137 |
| M058 | mittel | 1 | SwRS-138 |
| M059 | tief | 3 | SwRS-69/70; StRS-24 |
| M060 | tief | 5 | SwRS-7/8/9/10; StRS-7 |
| M061 | tief | 2 | SwRS-56; StRS-3 |
| M062 | mittel | 2 | SwRS-17; StRS-15 |
| M063 | tief | 3 | SyRS-25/26/27 |
| M064 | flach | 1 | SwRS-31 |
| M065 | nicht analysiert | 1 | SwRS-144 (nur Stubs - Begründung unten) |
| M066 | mittel | 1 | SwRS-143 |
| M067 | flach | 1 | SwRS-42 |
| M068 | flach | 1 | SwRS-145 |
| M069 | mittel | 2 | SwRS-32; StRS-20 |
| M070 | mittel | 1 | SwRS-146 |
| M071 | tief | 2 | SwRS-18; StRS-17 |
| M072 | mittel | 1 | SyRS-28 |
| M073 | tief | 1 | SwRS-33 |
| M074 | mittel | 3 | SwRS-19; StRS-17/20 |
| M075 | flach | 1 | SwRS-71 |
| M076 | tief | 3 | SwRS-72/73; StRS-2 |
| M077 | flach | 1 | SwRS-74 |
| M078 | mittel | 3 | SwRS-75/76; StRS-24 |
| M079 | mittel | 1 | SwRS-77 |
| M080 | flach | 2 | SwRS-57; StRS-1 |
| M081 | flach | 1 | SwRS-34 |
| M082 | mittel | 1 | SwRS-139 |
| M083 | flach | 2 | SwRS-11; StRS-12 [HYP] |
| M084 | tief | 4 | SwRS-43/44; StRS-21 |
| M085 | tief | 2 | SwRS-35; StRS-15 |
| M086 | flach | 3 | SwRS-81/82; SyRS-11 |
| M087 | mittel | 1 | SwRS-20 |
| M088 | flach | 2 | SwRS-58; SyRS-37 |
| M089 | mittel | 2 | SwRS-141/142 |
| M090 | tief | 4 | SyRS-20/21/22/23 |
| M091 | mittel | 1 | SyRS-24 |
| M092 | mittel | 2 | SwRS-45; StRS-8 |
| M093 | flach | 1 | SyRS-24 |
| M094 | mittel | 2 | SwRS-99; StRS-14 |
| M095 | tief | 2 | SwRS-100; StRS-24 |
| M096 | mittel | 2 | SwRS-101; StRS-24 |
| M097 | tief | 2 | SwRS-102; StRS-24 |
| M098 | tief | 2 | SwRS-103; StRS-24 |
| M099 | tief | 3 | SwRS-104; StRS-8/24 |
| M100 | mittel | 2 | SwRS-105; StRS-24 |
| M101 | tief | 2 | SwRS-105; StRS-24 |
| M102 | mittel | 2 | SwRS-83; SyRS-19 |
| M103 | tief | 6 | SwRS-84/85; SyRS-8/9/12; StRS-1/6 |
| M104 | flach | 2 | SwRS-86; SyRS-36 |
| M105 | flach | 2 | SwRS-86; SyRS-35 |
| M106 | mittel | 2 | SwRS-87; SyRS-10 |
| M107 | flach | 2 | SwRS-88; SyRS-36 |
| M108 | tief | 4 | SwRS-109/110; StRS-2/25 |
| M109 | flach | 1 | SwRS-109 (Interface-Vertrag im Beleg) |
| M110 | mittel | 2 | SwRS-12; StRS-10 |
| M111 | mittel | 3 | SwRS-46; StRS-22/23 |
| M112 | mittel | 2 | SwRS-59 [HYP]; StRS-2 |
| M113 | mittel | 3 | SwRS-21/22; StRS-16 |
| M114 | flach | 2 | SwRS-13; StRS-11 |
| M115 | mittel | 3 | SwRS-78/111; StRS-25 |
| M116 | mittel | 3 | SwRS-79/112; StRS-2 |
| M117 | tief | 2 | SwRS-47; StRS-21 |
| M118 | flach | 3 | SwRS-80/112; StRS-25 |
| M119 | mittel | 2 | SwRS-14; StRS-8 |
| M120 | flach | 2 | SwRS-60; StRS-4 |
| M121 | mittel | 1 | SwRS-113 |
| M122 | mittel | 1 | SwRS-113 |
| M123 | mittel | 3 | SwRS-48; StRS-13/22 |
| M124 | tief | 2 | SwRS-23; StRS-18 |
| M125 | mittel | 4 | SwRS-94/95/96; StRS-6/15 |
| M126 | mittel | 3 | SwRS-97; SyRS-17/18; StRS-6 |
| M127 | flach | 1 | SwRS-98 |
| M128 | flach | 1 | SwRS-114 |
| M129 | flach | 1 | StRS-27/SyRS-38 (Preview-Testharness, kein Produktionspfad) |
| M130 | mittel | 2 | SwRS-115; StRS-1 |
| M131 | tief | 2 | SyRS-23; StRS-20 |
| M132 | mittel | 2 | SyRS-39; StRS-29 |
| M133 | mittel | 2 | SyRS-38; StRS-27 |
| M134 | mittel | 3 | SyRS-38; StRS-27/29 |
| M135 | mittel | 3 | SyRS-38/39; StRS-29 |
| M136 | mittel | 2 | SyRS-39; StRS-29 |
| M137 | mittel | 2 | SyRS-39; StRS-29 |
| M138 | flach | 2 | SyRS-39; StRS-29 |
| M139 | mittel | 2 | SyRS-40; StRS-29 |
| M140 | tief | 2 | SwRS-106; StRS-24 |
| M141 | flach | 1 | SyRS-38 |
**Stufenzählung:** tief 37, mittel 67, flach 36, nicht analysiert 1 (M065) = 141. **Mindestabdeckung: erfüllt** - jedes Modul trägt mindestens eine Anforderung. Das einzige als `nicht analysiert` geführte Modul ist M065 (Start-BL): beide Methoden sind auskommentierte Stubs ohne jede durchsetzbare Stelle; die Funktionslosigkeit ist belegt und als SwRS-144 dokumentiert. 1 von 141 Modulen = 0,7 %, die 10-%-Warnschwelle ist damit klar unterschritten.
## 3. Arbeitsteilung (Dokumentationspflicht)
Die Zuständigkeitsbindung wurde eingehalten: alle gebundenen Teilaufgaben wurden durch den jeweils vorgesehenen Bearbeiter ausgeführt. Beauftragungen (22 Agentenaufträge):
| Bearbeiter | Aufträge | Zuschnitt |
|---|---|---|
| modulinventar | 1 | gesamte Codebasis → Inventar M001-M141 inkl. Buchführung |
| faktenermittler | 13 | Ausschnitte A (Finanzen: M001, M019, M029, M060, M083, M110, M114, M119), B (Support: M013, M035, M062, M071, M074, M087, M113, M124), C (Stammdaten: M002, M006, M015, M017, M020, M028, M048, M064, M069, M073, M081, M085), D (Einkauf/Lager: M007, M023, M036, M053, M054, M056, M067, M084, M092, M111, M117, M123), E (Admin/Sicherheit: M003, M005, M042, M050, M051, M061, M080, M088, M112, M120), F (Webservices: M086-M107), G1 (Nexus/Outlook: M010, M041, M045-M047, M049, M125-M127), G2 (APIs: M094-M101, M140), H (WPF/Shared: M031, M040, M108, M109, M115, M116, M118, M121, M122, M128-M130), I1 (Kommunikation: 17 Module M004-M082), I2 (Datenhaltung: M014, M025, M032, M063, M089-M093), I3 (Restfachlogik: 19 Module M018-M079), L (DB/Build/CI/Doku: M131-M141); die Ausschnitte decken M001-M141 überschneidungsfrei |
| strs-autor | 1 | StRS aus den 13 Faktenberichten; ID-Bereich StRS-1..40, gestellt 30 (StRS-1..30) |
| syrs-autor | 1 | SyRS aus den Faktenberichten + StRS-ID-Liste; ID-Bereich SyRS-1..60, gestellt 40 (SyRS-1..40) |
| swrs-autor | 4 | (1) Ausschnitt A-E → SwRS-1..60; (1a) Nachlieferung 16 Module ohne Fakten im ersten Durchlauf → SwRS-61..80; (2) Ausschnitt F-H → SwRS-81..115; (3) Ausschnitt I-L → SwRS-121..163. ID-Bereiche überschneidungsfrei vergeben (1-80, 81-120, 121-180) |
| belegpruefer | 1 | 12 Stichproben risikorelevanter Anforderungen (StRS-7/9, SyRS-2/9/12, SwRS-8/9/49/55/61/137/146) gegen den Code |
| iso29148-orchestrator | 1 | Gesamtbestand 216 Anforderungen gegen ISO/IEC/IEEE 29148, Schwerpunkt Nahtstellen |
| konsistenzpruefer | 1 | Vollständiger Abschluss-Konsistenzcheck (Abschnitt „Abschluss") |
**Eigenständig ausgeführt (Auftraggeber):** Zuschnitt der 13 Ausschnitte, ID-Bereichsvergabe, Reihenfolge der Aufträge (Inventar → 13× Fakten → StRS → SyRS → SwRS×4 → Prüfung×3), Anlegen der sieben Ergebnisdateien, Übernahme der Rückmeldungen. Dazu gehörten ausdrücklich: Entdoppelung von SwRS-Anforderungen, die zwischen der Nachlieferung des Auftrags A-E (SwRS-61..80) und dem Auftrag I-L (SwRS-121..163) für dieselben Module (M024, M030, M034, M043, M044, M059, M075, M076, M077, M078, M079) entstanden - die Erstfassungen wurden behalten, die Zweitfassungen entfernt und der verbleibende Bestand lückenlos zu SwRS-1..146 neu nummeriert; vier Querverweise auf umnummerierte/entfallene IDs wurden korrigiert. **Keine der gebundenen Teilaufgaben (Inventar, Faktenerhebung, Anforderungsformulierung, Belegprüfung, Nahtstellenprüfung, Konsistenzprüfung) wurde vom Auftraggeber selbst ausgeführt.**
## 4. Konsistenzcheck (Abschnitt „Abschluss")
Ergebnis der drei Prüfläufe (Volltextprüfung durch konsistenzpruefer und iso29148-orchestrator, Stichprobe durch belegpruefer):
- **Doppelte/mehrfach vergebene IDs:** keine. StRS-1..30, SyRS-1..40, SwRS-1..146 lückenlos ohne Dubletten.
- **Anforderungen ohne Beleg:** keine (216/216 mit nichtleerem Belege-Feld).
- **Anforderungen ohne Übernahmewürdigkeit:** keine (216/216).
- **Tracelinks auf nicht existierende IDs:** keine. Nach Prüfbefund korrigiert: SwRS-81 → zusätzlich SyRS-11; SwRS-50 → zusätzlich SyRS-4; SwRS-86/SwRS-88 → zusätzlich SyRS-36; SwRS-115 → zusätzlich SyRS-5; SwRS-137/SwRS-138 → SyRS-20 durch SyRS-21 ersetzt (Raw-SQL liegt sachlich beim Roh-SQL-Zugriff, nicht beim DAO-Lebenszyklus).
- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung:** nach Prüfbefund markiert: SwRS-108 ↔ SwRS-66 (Massenpreisaktualisierung, M040), SwRS-81 ↔ SyRS-11, SwRS-50 ↔ SyRS-4, SwRS-86/SwRS-88 ↔ SyRS-36. Weitere Konsolidierungskandidaten sind in den Blöcken markiert (u. a. Aktionspreis Maske/BL, Textbaustein-Löschsemantiken, Versand-Clients GLS/Shipcloud, OAuth finAPI/docuFORM, Passwortprüfstellen BasicAuthenticator/TradePoolBL, 2FA zweifach, Platzhalterersetzung zweifach, Raw-SQL-Ausführung zweifach, StorageBL veraltet).
- **Liste der risikorelevanten Anforderungen (konsistenzpruefer, 104):** StRS: 1-17, 22-26, 30; SyRS: 1-13, 16-19, 27; SwRS: Typ Sicherheit 6, 22, 24, 39, 49-53, 55-57, 59-61, 69, 70, 72, 79, 81, 82, 84, 87, 94, 96, 97, 114, 115, 120, 121, 124, 128, 133, 139-143; Qualitätsmerkmal Sicherheit 137, 138; abrechnungsrelevant 2-5, 7-14, 43-48, 63, 66, 99, 108, 136. **Belegsituation: 101 von 104 tragen einen PRIMÄR-Beleg mit durchsetzender Stelle; ohne PRIMÄR genau 3 (StRS-12, SwRS-59, SwRS-128), alle drei als [HYPOTHESE] gekennzeichnet. 0 Verstöße gegen die risikobasierte Priorisierung.**
- **Abgleich Hypothesen.md gegen Inline-Markierungen:** deckungsgleich. Inline mit Status HYPOTHESE: genau StRS-12, StRS-30, SwRS-59, SwRS-128; Hypothesen.md nennt genau diese vier und keine freien Fragen. SyRS führt keine Hypothese.
- **Belegstichprobe (belegpruefer):** 12 von 12 geprüfte Stellen bestätigt (Datei, Klasse, Methode, Bedingung stimmen im Kern); keine Abweichungen.
- **Traceability-Konsistenz:** nach Prüfbefund korrigiert: Tabellenzeile SwRS-114 (SyRS-/StRS-Spalten vertauscht) berichtigt; SyRS-34-Tracelink-Feld normiert (Anker StRS-30, fachliche Entsprechung fehlt - dokumentierte Lücke).
- **Ergebnisstruktur:** genau die sieben vorgegebenen Dateien; keine Ergänzungs- oder Teil-Dateien. (Der Prüfbefund „Analysebericht.md fehlt" bezog sich auf den Prüfzeitpunkt vor dieser Nachlieferung.)
## 5. Selbstbewertung
- **Erkundungstiefe:** 37 Module tief, 67 mittel, 36 flach, 1 nicht analysiert (M065, nur Stubs). Große Fachmodule (M060 Sales 248, M086 WebServices 464, M102 Core 2528, M003 Administration 959, M090 DAO 1129, M108 Shell 1205) wurden als gezielte Stichprobe der Hauptklassen erschlossen, nicht vollständig gelesen - das ist in den faktenermittler-Tabellen je Modul ausgewiesen.
- **Mindestabdeckung:** erreicht; jedes der 141 Module trägt mindestens eine Anforderung (siehe Abdeckungstabelle). Ein Modul ohne Anforderung und ohne Begründung existiert nicht.
- **Dünne Beleglage (hoher SEKUNDÄR/KONTEXT-Anteil):** die technischen Kleinst- und Infrastrukturmodule M025, M042, M065, M068, M075, M088, M129, M139, M141 - dort trägt teilweise das Schema oder die Dateistruktur die Aussage statt durchgesetzter Fachregeln. Hypothesen: 4 (StRS-12, StRS-30, SwRS-59, SwRS-128); eine Analyse ohne offene Punkte wäre bei dieser Codebasis unplausibel und wurde nicht behauptet.
- **Erkenntnisse für eine Folge-Iteration (Nachschlag lohnt):**
1. Gutschein-Einlösung (M083): Schreibpfade (Aktivierung/Einlösung) im Webservice/Webshop lokalisieren - Grundlage für StRS-12/SwRS-11.
2. Serverseitige Helpdesk-Statuslogik (HelpdeskBL, Sales.Support): die für StRS-16/SwRS-21/22 zitierte Abschlussprüfung liegt außerhalb der geprüften Maskenmodule.
3. Backend-Rechteprüfung für SqlManager/Reportabfragen (SwRS-59) und ExternalHelpdesk-Konfiguration (SwRS-128): beide als Hypothese geführt, Webservice-Schicht war nicht im Ausschnitt.
4. Mandanten-/Datenbanktrennung je Anfrage: im Host nicht gefunden (eine konfigurierte Verbindungszeichenfolge, Meldung in SwRS-85/SyRS-9) - für den SaaS-Zielentwurf zentral zu klären.
5. Serverseitige Spiegelprüfungen zu UI-Gates: Dokument-Signierung/SEPA (M125), Outlook-Verzeichnis-Blacklist (M127), Fremd-Todo-Zugriff (M115), Aktionspreis-BL-Validierung (M084/M111) - Kanalübergreifende Durchsetzung (StRS-22) ist Zielableitung.
6. ReceiptBL (11.441 Zeilen) nur ausschnittweise; Belegkette/Ursprungsarten (ReceiptProgressionBL) und Vertragsabrechnung (M110: AutomatedBilling/FlatrateBilling/SEPA-Masken) unbelesen.
7. Preisbildung im WebCart serverseitig (M125-Meldung) - für StRS-22 zu verifizieren.
- **Im Zielsystem zu korrigierende Defekte (aus der Analyse):** ungesalzenes SHA1-Passwort (M003, Kommentar im Code), Passwort-Neuanlage speichert das Passwort nie (M050), Kontaktaktivitäts-Löschschutz deaktiviert (M017), Mailing-Filterzuweisung fehlt (M038), Icon-Kategoriefilter wirkungslos (M009), Outlook-AssetKind-Alias-Bug (M049), vertauschte Kalender-Settings-Schlüssel (M008), SN-Scan-Dialog unvollständig (M111), Online-Banking-Converter NotImplementedException (M119), unendlicher Client-Timeout (M102), pauschale CORS-Policy (M103).
## 6. Bekannte Lücken (Struktur des Anforderungssatzes)
- **Ebenensprung direkt auf StRS** (SwRS ohne eigene SyRS-Verankerung, in Traceability.md dokumentiert): SwRS-99 bis SwRS-106 (Externe-Dienst-Clients) und SwRS-108 (Massenupdate-Ausschlussregeln) - fachlich projektlokale Schnittstellen-/Ausschlussregeln ohne eigenes systemweites Gegenstück; vermittelt über StRS-24 bzw. StRS-14.
- **SyRS ohne SwRS-Gegenstück** (dokumentiert): SyRS-4 (Anmeldekette, BL-Seite über SwRS-50 verlinkt), SyRS-7 (Web-Konto-Kaskade, M003-Bereich), SyRS-26 (CTime-Sync, Modul M063 über SyRS-25/26/27 abgedeckt), SyRS-31 (Blacklist-Abgleich BL-seitig in M037 geprüft, SwRS-131 verweist), SyRS-36 (Konsolen-Werkzeuge, SwRS-86/88 verlinken nach Korrektur), SyRS-39/40 (QS-Pipelines/Doku - reine Betriebsebene, bewusst ohne SwRS).
- **SyRS-34 ↔ StRS-30:** formaler Anker; eine fachliche StRS-Verankerung der Volltextsuche fehlt - als Abdeckungslücke dokumentiert.
- **SwRS-125:** nur Klassendefinition belegt (SEKUNDÄR), Wurfstelle außerhalb der Stichprobe; als Nicht-Risikoanforderung mit SEKUNDÄR-Beleg geführt, Übernahmewürdigkeit „Sonderfall".
- **SwRS-144:** grenzwertig als Anforderung (beschreibt Funktionsabwesenheit); bewusst als belegte Beobachtung geführt (Übernahmewürdigkeit „Sonderfall").
- **Kosmetik:** Notation des Qualitätsmerkmal-Felds schwankt („-" vs. leeres Feld); ISO-29148-Befunde SwRS-122 (doppelte Semantik „null bzw. string.Empty") und SwRS-142 (Debugger-Gates nahe an der Implementierung) sind als Anmerkungen im Bericht des Orchestrators dokumentiert.
- **Proxy-Befund des Konsistenzpruefers** („M063, M091, M129, M139 ohne Anforderungsbezug") beruht auf der Suche nach den M-Nummern im Anforderungstext; tatsächlich sind diese Module über SyRS-25/26/27 (M063), SyRS-24 (M091), StRS-27/SyRS-38 (M129) und SyRS-40 (M139) abgedeckt - siehe Abdeckungstabelle.
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/Glossar.md
+49
View File
@@ -0,0 +1,49 @@
# Glossar
Domänen- und Systembegriffe, die in den Anforderungen verwendet werden (technische Bezeichner im Original).
| Begriff | Definition |
|---|---|
| Adressstamm (Account) | Konto-Datensatz für Kunde oder Lieferant inkl. Adressen, Kontakten; Tabelle Accounts; eindeutige Kunden-/Lieferantennummer. |
| Beleg (Receipt) | Verkaufs-/Einkaufsdokument (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift); Kopf in RechKopf/AufKopf/GutKopf, Positionen in RechPos usw.; Belegversionen mit ConcurrencyControlGuid. |
| Belegstatus | Zustandsmodell der Belege (ReceiptState: Active, Completed, Canceled u. a.); „bezahlt", „storniert", „festgeschrieben (IsFixed)". |
| OPOS | Offene Posten; Forderungsstand je Rechnung; wird aus Belegzahlungen fortgeschrieben (UpdateOpos). |
| SEPA-Mandat | Lastschriftmandat mit Zahlungsart (First/Recurrent/Last/Single) und Gültigkeitsfenster (ValidFrom/ValidTo). |
| Kassenbuch | Sammlung von Bar-Buchungen (CashBookRecord) je MwSt-Split; Abschluss (ClosedDate) schützt Buchungen. |
| FIBU | Finanzbuchhaltung; Export/Import von Belegdaten (BookKeepingExport/Import, PORTRECH/PORTWARE-Flags). |
| Mahnstopp | Befristete Sperre des Mahnlaufs je Kunde oder Rechnung (DunningStop), tagesgenau. |
| Gutschein | Wertgutschein mit Status frei/aktiviert/eingelöst, abgeleitet über GutscheinZuRechnung → RechPos. |
| Ticket / Helpdesk | Supportvorgang (hlpdsk_*); Bearbeitersperre, Statusmodell, Abschlussprüfung (CanHelpdeskClose). |
| Checkliste (CentronChecklist) | Prüfliste mit hierarchischen Items; Caption-Pflicht, Statuskaskade, Soft-Delete, Versionslog. |
| RMA | Rückgabe-/Reklamationvorgang; lagergebunden (RMA-Lager RmaOwn/RmaCustomer), aktionstypabhängige Pflichten. |
| Lager (Stock/Warehouse) | Bestandshaltung je Filiale; Vorgabelager (IsDefault), vier RMA-Sonderlager; Umbuchungsprotokoll. |
| Artikel (Article) | Stammsatz mit Einkaufspreis-Strategie (Fixed/Last/Misch-EK), Aufschlagstabellen, ScanBarcode-Pflicht für SN-Buchungen. |
| Bestellvorschlag (OrderSuggestionList) | SQL-basierte Vorschlagsliste aus Bedarf − Bestand + Zulauf unter Sperr-/SV-Kriterien. |
| EDI | Elektronischer Datenaustausch mit Distributoren (Alltron, Also, Komsa, ITscope über OpenTrans 2.1); Format-Routing, Kreditorcode-Pflicht. |
| Distributor | Externer Großhändler als Stammsatz (State-Flag), automatische Neuanlage beim Import. |
| Nummernkreis (NumberGroup) | Lückenlose Nummernvergabe je Objektart mit Fallback-Kette Mitarbeiter → Filiale → Standardmandant. |
| Mandant | Datenhaltungs-/Verwaltungseinheit des ERP-Betriebs; im Webservice eine konfigurierte Datenbankverbindung (keine mandantenweise Trennung je Anfrage belegt). |
| Filiale / Niederlassung (Branch) | Organisatorische Untereinheit; Rechte variieren (z. B. SHOW_HELPDESK_ONLY_OWN_BRANCH, MANAGEMENT_INFO_ONLY_OWN_BRANCH). |
| Recht (UserRight) | Feingranulare Berechtigungskonstante, ausschließlich an Gruppen vergeben (Sichtrus/Sichmemb); Beispiele: ADD_NEW_HELPDESK, INCOMING_PAYMENT_TRANSACTIONS, EDIT_GLOBAL_PROFILES. |
| Lizenz (LicenseGuids) | Produkt-/Modullizenz (Concurrent-User-Beschränkung, Versionsschranke); Modulsichtbarkeit = Rechte UND Lizenz, Centron-Vollizenz als Fallback (Ausnahmen: MSP, PasswordManager, Produktion, AI, PLM). |
| Ticket (Sitzung) | Anmeldungssitzung am Webservice (AuthenticationTicketBL), slide-Verlängert, parallel zu Access-Token; NICHT mit Helpdesk-Ticket verwechseln. |
| Access-Token | Dauerhafter API-Zugangs-Token mit Own-or-Right-Verwaltung (VIEW_ALL/EDIT_ALL/DELETE_ALL/CREATE_PERSONAL). |
| WebAccount | Portal-Login eines Kunden (Status 1, SHA1-Prüfung, Aktiv-Kaskade Konto→Kunde→Kontakt→Adresse). |
| Nexus | Blazor-Webclient „c-entron Nexus" (Mitarbeiterbereich + Kundenportal, Port-Trennung). |
| ServiceBoard | Weboberflächen-/Formularkomponente; Basis-URL für öffentliche Webformulare (SelfCare). |
| VMA (Virtual Mail Assistant) | MailScanner-Profile mit Modulrecht ACCESS_VMA_MODULE und Master-Key-Verschlüsselung. |
| MSP | Managed-Services-Produktbereich (MspCollector/MspModule) ohne Centron-Lizenz-Fallback. |
| I3D | Systemweiter ganzzahliger Primärschlüssel (IDENTITY) aller Tabellen; Entitätsidentität; Zahlenraum teilt sich zwischen Employee und WebAccount (Eindeutigkeit nur mit ObjectKind). |
| ObjectKind | Objektartnummer (CentronObjectKindNumeric), stabiler Wire-Contract (OfferClass=1, InvoiceClass=4, CustomerClass=5000012). |
| ConcurrencyControlGuid | Optimistische Sperre auf Belegköpfen; Mismatch → ReceiptConcurrencyConflictOnSave. |
| Soft-Delete | Logische Löschung über Status/IsActive/IsDeleted statt physischem DELETE. |
| Named Query | In NamedQueryPool.xml hinterlegte, per Enum adressierte SQL-Abfrage. |
| CachedTable | Lokale Statistik-/Cache-Tabellen mit transaktionalem Update, Stale-Lock-Recovery (>10 min). |
| RESTC | Webservice-Protokoll: REST-POST unter „/REST"+UriTemplate (komprimierte Variante /RESTC) mit Ticket im Request. |
| SecretKey-Policy | Statischer Bearer-Schlüssel für den SignalR-NotificationsHub (aus WebService-Konfiguration). |
| Master-Key | Hotline-seitiger Schlüssel zur Ver-/Entschlüsselung sensibler Konfigurationen (AESCryptoLogic/EncryptWithMasterKey). |
| ebInterface | Österreichisches E-Rechnungsformat (Schema 4p3) mit USt-ID-/Reverse-Charge-Validierung. |
| ZUGFeRD / OpenTrans | Austauschformate für E-Rechnung (ZUGFeRD 2.1) und Bestell-EDI (OpenTrans 1.0/2.1), xsd-generierte Klassen im Gateway. |
| PRIMÄR / SEKUNDÄR / KONTEXT | Belegklassifikation: durchgesetzte Regel im Code/DB-Constraint / UI-Text, Konfiguration, Mapping / Kommentar, README, Ticketreferenz. |
| [HYPOTHESE] | Kennzeichnung unbelegter oder nur teilweise belegter Aussagen mit Angabe der fehlenden Information. |
| Übernahmewürdigkeit | Einstufung übernehmen / Workaround / Sonderfall / veraltet zur fachlichen Zukunft der Anforderung im Zielsystem. |
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/Hypothesen.md
+12
View File
@@ -0,0 +1,12 @@
# Hypothesen
Sammlung aller mit [HYPOTHESE] markierten Anforderungen (deckungsgleich mit den Inline-Kennzeichnungen in StRS.md/SyRS.md/SwRS.md). Offene Punkte ohne zugehörige Anforderung stehen in Analysebericht.md (Selbstbewertung, bekannte Lücken).
| ID | Titel | Fehlende Information (warum Hypothese) | Offene Frage |
|---|---|---|---|
| StRS-12 | Gutschein-Lebenszyklus mit verbindlicher Einlösung | Die schreibende Einlöse-/Aktivierungslogik für Gutscheine ist im Modul M083 nicht auffindbar; nur die Leseklassifikation über Belegrückverweise ist belegt. | Wo/wie wird ein Gutschein aktiviert und eingelöst, und welche Regel verhindert die doppelte Einlösung? |
| StRS-30 | Berichte ohne unbeschränkten Datenzugriff | Die Rohtext-SQL-Ausführung (M057/M058) ist belegt; eine Schutzregel existiert an der Stelle nicht - die gewünschte Beschränkung ist Zielbild, nicht Beobachtung. | Wie ist der kontrollierte Rahmen für Berichtsdefinitionen im Zielsystem konkret auszugestalten (Rechte, Parametrisierung, Mandantensicht)? |
| SwRS-59 | Mandanten-KI-Anweisungen und Reportabfragen: Rechte-/Lizenz-Gate | UI-Gate (AI-Lizenz + MANDATORY) ist belegt; die Backend-Durchsetzung liegt außerhalb des untersuchten Ausschnitts (IReportLogic.ReportEngineExecuteQuery nicht geprüft). | Prüft der Webservice die SqlManager-/Reportabfragen backendseitig nach Recht? |
| SwRS-128 | ExternalHelpdesk-Konfiguration: Rechteprüfung am Webservice-Zugang | Die BL enthält keine Rechteprüfung; der aufrufende Webservice-Kontext lag außerhalb des untersuchten Ausschnitts. | Prüft der Webservice-Zugang auf ExternalHelpdesk-Konfigurationen eine Modulrechtsprüfung? |
Keine weiteren Hypothesen. SyRS führt keine Hypothese; SwRS führt genau SwRS-59 und SwRS-128.
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/StRS.md
+591
View File
@@ -0,0 +1,591 @@
# StRS - Stakeholder Requirements Specification
Reverse Requirements Engineering - c-entron ERP-Suite (WPF-Client, Webservice-Host, Blazor-Webclient Nexus, MSSQL). Basis: statische Analyse der Codebasis (Arbeitsverzeichnis). Evidenzkonvention: Belege stammen aus den faktenermittler-Berichten zu den Modulen M001-M141 des Modulinventars (siehe Analysebericht.md); Modulkürzel verweisen auf die dort genannte durchsetzende Stelle (Datei/Klasse/Methode/Bedingung). Risikorelevante Anforderungen (Abrechnung/Fakturierung, Berechtigungen, Sicherheit) tragen PRIMÄR-Belege oder sind als [HYPOTHESE] markiert.
---
ID: StRS-1
Titel: Authentifizierung mit Zweifaktorprüfung und Lizenzvorbehalt beim Zugang
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Benutzer (Mitarbeiter/Administration); System (Zugangskontrolle)
Vorbedingung: Benutzerkonto existiert; Konto-/Mitarbeiterstatus aktiv; Lizenzbestand vorhanden
Fakt: Login-Kette prüft gruppenbasierte Rechte (Sichtrus/Sichmemb), Konto-/Mitarbeiterstatus und Verbots-/Pflichtrechte je Anwendungstyp; 2FA schaltbar, TOTP gegen pro-Benutzer-Key (RFC-Konfiguration); Concurrent-User-Lizenzen als Startvoraussetzung; Admin-Gruppe löschgeschützt (M003, M080, M130, M103).
Aussage: Das System soll den Zugang nur aktiven, berechtigten Benutzern nach erfolgreicher Authentifizierung - mit zweitem Faktor, wo freigeschaltet - und nur bei verfügbarer Lizenz gewähren.
Ergebnis: Zugang besteht ausschließlich für gültige Konten mit erfüllter Faktor- und Lizenzbedingung; gesperrte Konten bleiben ausgesperrt.
Belege:
- [PRIMÄR] M003 (AppRightsBL.HasUserRight/CheckRightsFromUser, Authenticator.AuthenticateUser/ValidateRights, LicenseManager.CheckLicense, UsersBL.UpdatePassword, WebAccountBL.LoginWithWebAccount) - Begründung: Zugangskontrolle mit Durchsetzung im Anmeldeprozess.
- [PRIMÄR] M080 (TwoFactorAuthenticationBL.ValidateAuthenticationPin) - Begründung: zweiter Faktor benutzergebunden erzwungen.
- [SEKUNDÄR] M130 (Totp.VerifyParameters) - Begründung: Konfigurationsdetail zum zweiten Faktor.
- [PRIMÄR] M103 (CentronHost.Start: TryLoadLicense vor DB-Setup) - Begründung: Zugang ohne Lizenz verweigert.
Prüfidee: Gesperrtes Konto, Benutzer ohne freigegebenen Zweifaktor und Anmeldung ohne freie Lizenz führen jeweils zur Ablehnung; aktiver Benutzer mit 2FA gelangt hinein.
Tracelinks: StRS-2; StRS-3; StRS-25
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Rechte-/Status-/Lizenzkette belastbar; Passwort-Hashing wegen Widerspruchs M003/M014 neu festzulegen.
Status: belegt
ID: StRS-2
Titel: Kanalübergreifende Durchsetzung von Berechtigungen durch das System
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: System (Geschäftslogik); Administration (Rechtepflege)
Vorbedingung: Benutzer ist authentifiziert; Rechte-, Filial- und Lizenzstammdaten liegen vor
Fakt: BL-Fassade prüft Rechte pro Operation, auch für den WPF-Kanal (M086); alle API-Controller RequireAuthorization, Endpunkt-Rechtefilter antwortet 401/403 (M103, M106); Modulsichtbarkeit = Rechte UND Lizenz, auch Settings gefiltert (M108); WPF-Admin blendet nach Rechten/Lizenz aus, Backend entscheidet (M112); Statistik mit Filialrechtefilter (M116), globale UI-Profile nur mit EDIT_GLOBAL_PROFILES (M031), fremde Todos verwerfen nur mit Recht (M076).
Aussage: Das System soll jede fachliche Operation und jeden Datenzugriff - ungeachtet der verwendeten Bedienoberfläche - anhand von Rollen-, Filial- und Lizenzrechten selbst prüfen und unberechtigte Zugriffe ablehnen.
Ergebnis: Unberechtigte Operationen werden zentral abgelehnt; Ausblendungen in Bedienoberflächen sind nur ergänzend, nie die einzige Sperre.
Belege:
- [PRIMÄR] M086 (AccessTokenWebServiceBL.GetById/Delete mit Own-or-Right-Muster; Kommentar: Rights-Checks bewusst in der BL) - Begründung: zentrale Prüfung unabhängig vom Kanal.
- [PRIMÄR] M106 (UserRightAuthorizationFilter.OnAuthorization, AllUserRightsAuthorizationFilter) - Begründung: Ablehnung unberechtigter Zugriffe (401/403) ist implementiert.
- [PRIMÄR] M108 (ModuleRegistration.DoRegisterCentronModules/CheckRights/CheckModuleFeatures; GetSettingsWithoutModule) - Begründung: Sichtbarkeit folgt der Systementscheidung.
- [PRIMÄR] M112 (MandatorManagementViewModel.SaveMandatorInstructionPrompt; SettingsContainerViewModel) - Begründung: Backend ist maßgeblich, UI blendet nur aus.
Prüfidee: Benutzer mit Recht R, dem Recht S fehlt, ruft eine S-geschützte Aktion über Desktop und Webschnittstelle auf → beide Aufrufe werden systemseitig abgelehnt.
Tracelinks: StRS-1; StRS-10; StRS-25
Konsolidierung: Kandidat: M116 (Filialrechtefilter, ManagementInfoViewModel), M031 (EDIT_GLOBAL_PROFILES, UiProfileBL), M076 (fremde Todos verwerfen, ToDoBL.UpdateTodoDiscardedFlag) als Einzelfälle derselben Regel
Übernahmewürdigkeit: übernehmen - zentrale Prüfung pro Operation als Grundprinzip festhalten; Rechtetabellen-Details sind SwRS-Thema.
Status: belegt
ID: StRS-3
Titel: Kein Klartext für Passwörter, Schlüssel und Tokens
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Sicherheit (Vertraulichkeit)
Akteur: System
Vorbedingung: Zugangsdaten/Geheimnisse werden gespeichert, angezeigt oder gesucht
Fakt: Passwort-Hash SHA1+Salt (M014; M003-Kommentar nennt „ungesalzenes SHA1"); KI-Keys verschlüsselt (M005); RFID-Tokens verschlüsselt, Klartext nie in der Suchform (M024); VMA-Profile rechtegeschützt, Passwörter verschlüsselt (M039); PDF-Signatur verschlüsselt konfiguriert (M061); Bankkonfiguration verschlüsselt (M029).
Aussage: Das System soll Zugangsdaten und Geheimnisse (Passwörter, Schlüssel, Tokens, Bank- und Signaturkonfiguration) niemals im Klartext ablegen, anzeigen oder durchsuchbar halten; Passwörter nur als nicht umkehrbare Hashwerte (mit Salt), sonstige Geheimnisse nur verschlüsselt.
Ergebnis: Geheimnisse liegen ausschließlich gehasht bzw. verschlüsselt vor; Suche und Protokolle liefern keinen Klartext.
Belege:
- [PRIMÄR] M014 (CryptoUtils.CreatePasswordHash mit Salt; TradePoolBL.SaveUser) - Begründung: Passwörter werden gehasht mit Salt abgelegt.
- [PRIMÄR] M024 (EmployeeRfidTokenBL.CreateFilterExpression: EncryptWithMasterKey vor Suche; Schema EmployeeRfidTokens.RfidTokenEncrypted NOT NULL) - Begründung: Suchpfad schließt Klartext aus.
- [PRIMÄR] M039 (MailScannerBL.SaveProfile/EncryptProperties) - Begründung: Zugangsdaten verschlüsselt geführt.
- [PRIMÄR] M061 (PdfSigningBL.DoGetCertificate: AESCryptoLogic für Zertifikat/Passwort) - Begründung: Signaturgeheimnisse geschützt.
Prüfidee: Abfragen auf den Speicherstellen für Passwörter/Tokens/Keys liefern keinen Klartext; die Suchfunktion findet keine Geheimnisinhalte.
Tracelinks: StRS-1; StRS-4; StRS-8
Konsolidierung: Kandidat: M005 (GetApiKey: CryptoControl.DecryptString), M029 (OnlineBankingConfigurationBL.GetSecurityKey, AESCryptoLogic mit Hotline-Master-Key) unter dieselbe Regel
Übernahmewürdigkeit: übernehmen - Grundsatz fortführen; das Hashverfahren (SHA1) ist für die Neuimplementierung zu ersetzen.
Status: belegt
ID: StRS-4
Titel: KI-Funktionen nur freigegeben und mit Benutzerverantwortung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Benutzer; System
Vorbedingung: KI-Funktion eingerichtet; Zieladresse bekannt
Fakt: KI-Endpunkte sind an eine HTTPS-Host-Allowlist gebunden, Keys verschlüsselt (M005); KI-Tool-Aufrufe unterliegen einer Bestätigungspflicht (M120).
Aussage: Das System soll KI-gestützte Aktionen nur gegenüber freigegebenen Zielen und erst nach ausdrücklicher Bestätigung des Benutzers ausführen.
Ergebnis: Kein KI-Aufruf ohne Ziel-Freigabe und ohne Benutzerbestätigung.
Belege:
- [PRIMÄR] M005 (AiApiLinkValidator.GetValidatedApiLink/IsLocalOrPrivateHost) - Begründung: Zielbeschränkung ist durchgesetzt.
- [PRIMÄR] M120 (ArtificialIntelligenceChatCoordinator: RequiresConfirmation → ConfirmAsync, sonst kein Aufruf) - Begründung: menschliche Freigabe vor Ausführung.
Prüfidee: Aufruf gegen ein nicht freigegebenes Ziel wird abgelehnt; ohne bestätigende Benutzeraktion erfolgt keine Ausführung.
Tracelinks: StRS-2; StRS-3
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Allowlist- und Bestätigungsprinzip für den SaaS-Betrieb fortführen.
Status: belegt
ID: StRS-5
Titel: Passwort-Tresor mit Abrufprotokoll und kontrolliertem Export
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Benutzer mit Tresorberechtigung; System
Vorbedingung: Tresoreintrag existiert; Benutzer ist authentifiziert
Fakt: Passwort-Management protokolliert jeden Abruf (M050); Export braucht Lizenz UND Recht (M051); Beobachtung: Neuanlage speichert das Passwort nicht (Bug, M050).
Aussage: Das System soll jeden Abruf eines Tresoreintrags protokollieren und Exporte nur bei Vorliegen von besonderem Recht und Lizenz zulassen; bei Neuanlage ist das Passwort zuverlässig abzulegen.
Ergebnis: Jeder Abruf ist Person und Zeitpunkt zuordenbar; Export ohne Recht/Lizenz wird abgelehnt; neu angelegte Einträge liefern ihr Passwort korrekt.
Belege:
- [PRIMÄR] M050 (PasswordManagementKeywordBL.GetDecryptedKeywordById: SavePasswordManagementAccessLog vor jeder Rückgabe; Schema PasswordManagementAccessLog NOT NULL) - Begründung: Nachvollziehbarkeit jedes Zugriffs ist implementiert.
- [PRIMÄR] M051 (PasswordManagerBL.GetAllCustomerAccountsWithAccessData: HasLicense + EXPORT_ACCESS_AND_PASSWORD_DATA) - Begründung: Export doppelt kontrolliert.
- [SEKUNDÄR] M050 (PasswordManagementKeywordBL.AddNewKeyword: password-Parameter wird nie gespeichert) - Begründung: Fehlerbeobachtung, Ziel daraus abgeleitet.
Prüfidee: Abruf erzeugt Protokolleintrag mit Benutzer/Zeitpunkt; Benutzer ohne Exportrecht erhält eine Ablehnung; nach Neuanlage liefert ein Abruf das hinterlegte Passwort.
Tracelinks: StRS-1; StRS-3; StRS-25
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Abrufprotokoll und Rechte-/Lizenzprüfung fortführen; Neuanlagen-Fehler (M050) ist zu beheben.
Status: belegt
ID: StRS-6
Titel: Gesicherter Webzugang mit getrennten Portalen
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Sicherheit
Akteur: Kunde (Kundenportal); Mitarbeiter (Mitarbeiterbereich); System
Vorbedingung: Webclient „Nexus" ist erreichbar; Portale sind konfiguriert
Fakt: Nexus-Host erzwingt HTTPS, Mitarbeiter-/Kundenportal-Port-Trennung als Zugriffsregel, Anmeldung über Cookie/OIDC (M126); Open-Redirect-Schutz im Blazor-Client (M125); SignalR-Hubs geschützt (M103).
Aussage: Das System soll Webzugriffe ausschließlich verschlüsselt anbieten, Mitarbeiter- und Kundenportal als getrennte Zugriffswege führen und Umleitungen so begrenzen, dass Benutzer nicht auf fremde Ziele gelangen.
Ergebnis: Unverschlüsselte Zugriffe werden abgelehnt; portalübergreifende Zugriffe bleiben ausgeschlossen; Umleitungsziele bleiben im kontrollierten Rahmen.
Belege:
- [PRIMÄR] M126 (Program.cs ConfigureWebHostLinux nur Https/Http; PortAuthorization.PortHandler prüft LocalPort) - Begründung: Verschlüsselung und Trennung sind erzwungen.
- [PRIMÄR] M125 (Shared/Auth/AuthController.GetSafeReturnUrl: IsLocalUrl-Prüfung) - Begründung: Schutz gegen manipulierte Umleitungen.
- [PRIMÄR] M103 (SecretKeyHandler + [Authorize]-Hubs) - Begründung: Echtzeitkanäle stehen nicht offen.
Prüfidee: Klartext-HTTP-Anfrage wird abgelehnt bzw. auf HTTPS geführt; Kundenportal ist über den Mitarbeiterzugang nicht erreichbar und umgekehrt; manipulierter Umleitungsparameter wird verworfen.
Tracelinks: StRS-1; StRS-2; StRS-15
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Verschlüsselungszwang und Portaltrennung als Grundschutz fortführen.
Status: belegt
ID: StRS-7
Titel: Belegstatus mit Änderungs-, Storno- und Gleichzeitigkeitsregeln
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Buchhaltung/Fakturierung (Rolle); System
Vorbedingung: Beleg existiert in einem Status (bezahlt/storniert/festgeschrieben)
Fakt: Belegstatus bezahlt/storniert/festgeschrieben mit Rechte-, Storno-, Export- und Concurrency-Regeln; Kassenbuchabschluss schützt enthaltene Buchungen (M060); optimistische Sperr-GUID auf Belegköpfen, verschachtelte Transaktionen (M090).
Aussage: Das System soll fertiggestellte und bezahlte Belege vor unberechtigter Änderung und vor gleichzeitigen widersprüchlichen Bearbeitungen schützen; Stornierung nur nach Prüf- und Rechteordnung, abgeschlossene Kassenperioden bleiben unveränderlich.
Ergebnis: Statuswechsel und Storni erfolgen nur regelkonform; gleichzeitige Änderungen verursachen keinen stillen Datenverlust.
Belege:
- [PRIMÄR] M060 (ReceiptBL.UpdateReceiptIsPaid Z.4902; ReceiptInvoiceBL.CancelInvoice Z.143; FixInvoice Z.86; CashBookBookingBL.DeleteCashBookBooking) - Begründung: Geschäftsregeln am Beleg sind durchgesetzt.
- [PRIMÄR] M090 (SaveReceiptRepository.GetExistingReceiptTableCheckConcurrency: ConcurrencyControlGuid-Mismatch → ReceiptConcurrencyConflictException) - Begründung: Gleichzeitigkeitsmechanismus vorhanden.
Prüfidee: Zwei gleichzeitige Änderungen desselben Belegs → zweite wird abgelehnt; Änderung eines festgeschriebenen Belegs ohne Stornorecht wird verweigert; Buchung im abgeschlossenen Kassenbuch bleibt fix.
Tracelinks: StRS-8; StRS-13
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Status- und Schutzmodell ist Kern der Abrechnungsintegrität.
Status: belegt
ID: StRS-8
Titel: Verbuchung von Zahlungseingängen mit Zuweisungsgrenze
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Buchhaltung (Rolle); System
Vorbedingung: Rechnung/Gutschrift mit offener Forderung vorhanden; Bankanbindung konfiguriert
Fakt: Zahlungseingänge inkl. Online-Banking-Verbuchung unter Rechnungs-/Gutscheinstatus-Regeln, verschlüsselte Bankkonfiguration (M029); FinTS-Zugangsdaten, TAN-Dialog nötig (M092); Zuweisung von Zahlungseingängen begrenzt auf Eingang und Forderung (M119).
Aussage: Das System soll Zahlungseingänge nur in Höhe des tatsächlichen Eingangs und nur bis zur Höhe der offenen Forderung zuordnen; der elektronische Bankzugriff erfordert geschützte Zugangsdaten und eine gesonderte Freigabe.
Ergebnis: Keine Überzuweisung und keine Zuweisung über den Eingang hinaus; Bankzugriffe laufen geschützt mit Freigabeverfahren.
Belege:
- [PRIMÄR] M119 (OnlineBankingTransactionAssignmentViewModel.CheckNewAssignedAmount: Ablehnung bei Eingangs-/Forderungsüberschreitung) - Begründung: Zuweisungsgrenze ist durchgesetzt.
- [PRIMÄR] M029 (OnlineBankingAccountTransactionsBL.BookAmountToAssignedInvoice Z.1042; OnlineBankingConfigurationBL mit AESCryptoLogic) - Begründung: Statusregeln und Konfigurationsschutz vorhanden.
- [SEKUNDÄR] M092 (OnlineBankingConnectionLibfintx.LoadOnlineBankingTransactionsByFinTS/WaitForTanAsync) - Begründung: Freigabeverfahren beim Bankzugang belegt.
Prüfidee: Zuweisung oberhalb der offenen Forderung oder des Eingangs wird abgelehnt; Bankabruf ohne Freigabe schlägt fehl; Bankkonfiguration ist nicht im Klartext lesbar.
Tracelinks: StRS-7; StRS-3; StRS-9
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Zuweisungsgrenze und geschützter Bankzugang sind abrechnungsrelevant und belastbar.
Status: belegt
ID: StRS-9
Titel: SEPA-Mandatsverwaltung mit Gültigkeit und Löschschutz
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Buchhaltung (Rolle); System
Vorbedingung: Kunde mit Mandat; Lastschriften können aktiv sein
Fakt: Bankverbindungen/Mandate rechtegeschützt mit Mandats-Gültigkeitsfenster und Löschschutz bei aktiven Lastschriften (M001); FIBU-Export/-Import führt SEPA-Mandatsfortschreibung mit harten Vorbedingungen durch (M019).
Aussage: Das System soll Mandate nur innerhalb ihres Gültigkeitsfensters nutzen, Mandatsänderungen fortschreiben und Mandate nicht löschen, solange Lastschriften darauf laufen; Verwaltung nur für berechtigte Rollen.
Ergebnis: Abgelaufene/widerrufene Mandate erzeugen keine Lastschriften; aktive Bezüge verhindern Löschung.
Belege:
- [PRIMÄR] M001 (BankAccountBL.SaveBankAccount mit CheckRightsFromUser; DeleteBankAccount: DependencyCheckFailed bei aktiven Lastschriften; GetBankAccountsFromCustomer: Gültigkeitsfenster) - Begründung: Schutzregeln am Mandat sind durchgesetzt.
- [PRIMÄR] M019 (PaymentTransactionBL.RefreshBankInformation: Mandatstyp/Gültigkeit nach Export) - Begründung: Fortschreibung nur regelkonform.
Prüfidee: Lastschrift auf ein Mandat außerhalb des Gültigkeitsfensters wird abgelehnt; Löschversuch bei aktiver Lastschrift scheitert; ohne Mandatsrecht ist keine Änderung möglich.
Tracelinks: StRS-8; StRS-11
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Mandatsregeln sind zahlungsverkehrsrechtlich zwingend.
Status: belegt
ID: StRS-10
Titel: Mahnprozess mit tagesgenauem Mahnstopp
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Buchhaltung (Rolle); System
Vorbedingung: Offene Forderungen; Mahnlauf geplant
Fakt: Mahnstopp je Kunde und je Rechnung, tagesgenau, rechtegeprüft (M110).
Aussage: Das System soll für Kunden und einzelne Rechnungen einen befristeten Mahnstopp führen und Mahnungen nur durch berechtigte Benutzer auslösen; der Stopp wirkt zum genauen Datum.
Ergebnis: Gesperrte Kunden/Rechnungen erhalten im Stoppzeitraum keine Mahnung; Mahnstopp nur mit Recht änderbar.
Belege:
- [PRIMÄR] M110 (DunningStopViewModel.GetUpdatedIsDunningStopActive Z.213; CanAccept Z.164 mit HasEditDunningstopRight) - Begründung: Stopp- und Rechteprüfung sind durchgesetzt.
Prüfidee: Mahnlauf am Stoppdatum lässt gesperrte Positionen aus; Benutzer ohne Mahnrecht kann den Stopp weder setzen noch umgehen.
Tracelinks: StRS-2; StRS-8
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - tagesgenaue Stopps sind kundenerhaltend und präzise.
Status: belegt
ID: StRS-11
Titel: Finanzbuchhaltungs-Export und -Import nur nach Vorprüfung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Buchhaltung (Rolle); System
Vorbedingung: Belege sind gebucht; Zielsystem/Format bestimmt
Fakt: FIBU-Export/-Import mit harten Vorbedingungen und SEPA-Mandatsfortschreibung (M019); Exportmaske erzwingt Vorab-Laden, Formate im Code hinterlegt (M114).
Aussage: Das System soll Finanzbuchhaltungs-Exporte und -Importe nur ausführen, wenn alle Vorbedingungen (u. a. vollständiges Vorab-Laden der Belege) erfüllt sind; ungeprüfte Datenmengen werden nicht übertragen.
Ergebnis: Nur vollständig geladene und geprüfte Belegmengen gehen in Export/Import; abgebrochene Läufe hinterlassen keine Teilübertragung.
Belege:
- [PRIMÄR] M114 (BookKeepingExportDataCustomerReceiptsViewModel.ExportData Z.208: ExportDataPreview-Pflicht) - Begründung: Vorbedingung ist erzwungen.
- [PRIMÄR] M019 (BookKeepingImportBL.CheckMandatoryColumnKinds/StartImport mit Trigger-Handling in Transaktion) - Begründung: Vorbedingungen blockieren inkonsistente Läufe.
Prüfidee: Export ohne vorheriges Laden bzw. mit verletzter Vorbedingung wird abgelehnt; Abbruch erzeugt keine Teilübertragung.
Tracelinks: StRS-7; StRS-9
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Vorbedingungsprinzip belastbar; im Code festgelegte Formate bei Neuimplementierung konfigurierbar denken.
Status: belegt
ID: StRS-12
Titel: [HYPOTHESE] Gutschein-Lebenszyklus mit verbindlicher Einlösung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Vertrieb/Kasse (Rolle); System
Vorbedingung: Gutschein liegt in einem Status (frei/aktiviert/eingelöst) vor
Fakt: Gutscheinstatus frei/aktiviert/eingelöst über Belegrückverweise; die Durchsetzungsstelle der Einlösung ist nicht lokalisiert (M083).
Aussage: Das System soll Gutscheine nur einmal und nur im Zustand „aktiviert" einlösbar machen; jede Einlösung ist über Rückverweise auf den auslösenden Vorgang nachvollziehbar.
Ergebnis: Doppelte Einlösung und Einlösung nicht aktivierter Gutscheine werden verhindert; Einlösungen sind vorgangsbezogen nachvollziehbar.
Belege:
- [SEKUNDÄR] M083 (VoucherManagementBL.GetActivedVoucherBarcodes; NamedQuery VoucherManagementGetVoucherArticles) - Begründung: Statusmodell belegt, Durchsetzung offen.
- [KONTEXT] M083 (keine schreibende Einlöse-/Aktivierungslogik im Modul auffindbar) - Begründung: Beleglage lückenhaft, Hypothese nötig.
Prüfidee: Zweiter Einlösversuch desselben Gutscheins und Einlösung eines nicht aktivierten Gutscheins werden abgelehnt; jede Einlösung verweist auf ihren Vorgang.
Tracelinks: StRS-7; StRS-8
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - Statusmodell übernehmen; verbindliche Einlösungsdurchsetzung muss in der Neuimplementierung erst garantiert werden.
Status: HYPOTHESE
ID: StRS-13
Titel: Massenänderung ohne Eingriff in fertiggestellte Verkaufsbelege
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Vertrieb/Backoffice (Rolle); System
Vorbedingung: Massenänderung auf eine Belegauswahl angestoßen
Fakt: Massenupdate nur für aktive Belege, niemals für Rechnungen/Gutschriften im Verkaufsfall, mit Protokollierung (M040).
Aussage: Das System soll Massenänderungen auf aktive Belege beschränken und fertiggestellte Rechnungen und Gutschriften niemals massenweise verändern; jede Massenänderung ist protokolliert.
Ergebnis: Abgeschlossene Verkaufsbelege bleiben massenänderungsfest; Auswirkungen jeder Massenaktion sind nachvollziehbar.
Belege:
- [PRIMÄR] M040 (MassUpdateBL.StartReceiptPriceUpdate Z.259/272: nur ReceiptState.Active, ObjectKind InvoiceClass/CreditVoucherClass ausgeschlossen) - Begründung: Ausschluss und Protokollierung sind durchgesetzt.
Prüfidee: Massenlauf über eine Auswahl mit Rechnungen/Gutschriften ändert diese nicht und wird protokolliert; nur aktive Belege ändern sich.
Tracelinks: StRS-7; StRS-14
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Schutz fertiger Verkaufsbelege ist abrechnungskritisch.
Status: belegt
ID: StRS-14
Titel: E-Rechnungen nur nach inhaltsseitiger Prüfung übermitteln
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Fakturierung (Rolle); System
Vorbedingung: Rechnung ist fertiggestellt; E-Rechnungsformat ist bestimmt
Fakt: ebInterface 4.3 als E-Rechnungsformat mit Validierung von Umsatzsteuer-IDs und Reverse-Charge-Fällen (M094).
Aussage: Das System soll ausgehende E-Rechnungen vor Übermittlung automatisch auf Umsatzsteuerkennzeichnung und Reverse-Charge-Besonderheiten prüfen und nur konforme Rechnungen übermitteln.
Ergebnis: Nicht konforme Rechnungen werden zur Korrektur zurückgewiesen; übermittelte E-Rechnungen erfüllen das vereinbarte Format.
Belege:
- [PRIMÄR] M094 (EbInterfaceLogic.ValidateValues Z.303-341; DoCreateTaxNode Z.207-221) - Begründung: Prüfpflicht vor Versand ist implementiert.
Prüfidee: Rechnung mit fehlerhafter/fehlender USt-ID oder unklarem Reverse-Charge-Fall wird beim Erzeugen des E-Rechnungsformats abgelehnt; konforme Rechnung wird übermittelt.
Tracelinks: StRS-7; StRS-13
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Validierung vor Versand bleibt Pflicht; Formatversion ist je Zielmarkt anzupassen.
Status: belegt
ID: StRS-15
Titel: Externe Kunden-Vorgänge prüfgesichert, befristet und regelkonform zuordnen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Kunde (extern); System
Vorbedingung: Kunde erhält Link/Formular; Unterschrifts- oder SEPA-Vorgang offen
Fakt: Externe Dokumentensignierung/SEPA mit Pflichtprüfung, WebCart mit serverseitigen Sonderpreisen, öffentliche Webformulare nach Muster+Rechten (M125); SelfCare-Webformulare mit befristeten Links, Default 7 Tage (M062); Mail-Empfang mit Domänen-Blacklist zum Schutz der Kundenerkennung (M037); Weblinks lösen CRM-Aktivitäten beim Berater aus, DSGVO-Default-User (M085).
Aussage: Das System soll externe Kunden-Vorgänge (Formulare, Signierung, SEPA, Warenkorb) nur nach Pflichtprüfung, über zeitlich befristete und rechtesteuerbare Zugänge abwickeln; eingehende Kommunikation darf Kunden nur regel- und datenschutzkonform zugeordnet werden.
Ergebnis: Externe Vorgänge laufen prüfgesichert und befristet; die Kundenzuordnung bleibt regelkonform und datenschutzgerecht.
Belege:
- [PRIMÄR] M125 (DocumentSigningPage.razor CanAccept/IsValidIban; PublicWebFormPage.razor: TicketPattern.IsPublic && IsActive) - Begründung: Prüfpflicht bei externen Wertvorgängen ist verankert.
- [PRIMÄR] M062 (SelfCareBL.GetWebFormByGuid Z.307-326: Link-Expiration, Default 7 Tage) - Begründung: zeitliche Begrenzung ist durchgesetzt.
- [PRIMÄR] M037 (DomainBlacklistBL.IsBlacklisted; ContactPersonBL.SearchAddressContactByEmailAddress) - Begründung: Zuordnungsregel ist implementiert.
- [SEKUNDÄR] M085 (WebLinkBL.SaveWebLinkClick mit DSGVO-Default-User) - Begründung: datenschutzkonforme Zuordnung belegt.
Prüfidee: Abgelaufener Formularlink wird abgelehnt; SEPA-/Signaturvorgang ohne bestandene Pflichtprüfung wird nicht abgeschlossen; Mail aus gesperrter Domäne erzeugt keine automatische Kundenzuordnung.
Tracelinks: StRS-6; StRS-22
Konsolidierung: Kandidat: M125, M062, M037, M085 zu einer Regel für externe Kundenkanäle zusammengeführt
Übernahmewürdigkeit: übernehmen - Pflichtprüfung, Befristung und regelkonforme Zuordnung sind DSGVO- und abrechnungsrelevant.
Status: belegt
ID: StRS-16
Titel: Ticketabschluss nur mit zentraler Freigabe und ohne offene Zeiten
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Supporter (Rolle); System
Vorbedingung: Ticket in Bearbeitung; Zeiten erfasst
Fakt: Ticketabschluss nur mit Serverfreigabe, ohne offene Zeiten, mit Sperrenlogik; Status-Defaults löschgeschützt (M113).
Aussage: Das System soll den Abschluss eines Tickets nur zentral freigeben, wenn keine offenen Zeiten mehr vorhanden sind, und gleichzeitige Bearbeitungen sperren; Abschlusszustände sind löschgeschützt.
Ergebnis: Tickets schließen nur in vollständig erfasstem, unstrittigem Zustand; gleichzeitig bearbeitete Tickets kollidieren nicht.
Belege:
- [PRIMÄR] M113 (CloseHelpdeskHelper.CloseHelpdesk Z.28-139: CanClose-Serverprüfung, nonCalculatedTimers>0 → Abbruch; TicketLogicHelper.GetTicketAndPromptUnlock) - Begründung: Abschlussregeln sind serverseitig durchgesetzt.
Prüfidee: Abschlussversuch mit offener Zeit wird abgelehnt; gleichzeitiger Abschluss durch zwei Benutzer führt zu genau einem Abschluss; Abschlusszustand lässt sich nicht löschen.
Tracelinks: StRS-7; StRS-17
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zentrale Abschlussfreigabe sichert abrechnungsrelevante Zeiterfassung.
Status: belegt
ID: StRS-17
Titel: Automatische Ticketerstellung nur mit Lizenz und Recht
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: System (automatische Erstellung); Administrator (Konfiguration)
Vorbedingung: Automatisierungsquelle vorhanden; Ticketprojekt eingerichtet
Fakt: Automatische Ticketerstellung braucht ServiceBoard-Lizenz UND Recht, Serientask-Lebenszyklus (M071); Ticketprojekte mit Nummernkreis, Soft-Delete (M074).
Aussage: Das System soll Tickets automatisch nur erzeugen, wenn Lizenz und besonderes Recht vorliegen; jedes Ticket entsteht in einem Projekt mit eindeutiger Nummer, gelöschte Projekte bleiben rekonstruierbar.
Ergebnis: Keine automatischen Tickets ohne Berechtigung/Lizenz; Nummern bleiben projektbezogen eindeutig.
Belege:
- [PRIMÄR] M071 (TaskManagementHelpdeskActionHandler.Execute Z.50-58: HasLicense + ADD_NEW_HELPDESK) - Begründung: Doppelbedingung ist durchgesetzt.
- [PRIMÄR] M074 (TicketProjectBL.SaveOrUpdateTicketProject: Nummernkreis; DeleteTicketProjectTask: Soft-Delete) - Begründung: eindeutige Nummern und rekonstruierbare Projekte.
Prüfidee: Ohne Recht bzw. ohne Lizenz entsteht kein automatisches Ticket; erzeugte Tickets tragen projekt-eindeutige Nummern.
Tracelinks: StRS-2; StRS-25; StRS-20
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Doppelbedingung Lizenz+Recht verhindert unbefugte Massenerstellung.
Status: belegt
ID: StRS-18
Titel: RMA-Prozess mit Lagerbindung und richtungsgebundenen Schritten
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Support/Lager (Rolle); System
Vorbedingung: Rückgabe/Reklamation vorliegt; Lager zugeordnet
Fakt: RMA mit Lagerbindung, aktionstypabhängigen Pflichten und Einbahnstraßen-Sperren (M124); Lagermodell enthält 4 RMA-Lager und Filial-Vorgabelager (M036).
Aussage: Das System soll Rückgaben lagergebunden führen, Pflichtangaben vom Aktionstyp abhängig machen und Bearbeitungsschritte nur in der vorgesehenen Richtung zulassen.
Ergebnis: RMAs sind jederzeit lagerbezogen nachvollziehbar; Fehlreihenfolgen und Pflichtverletzungen werden abgelehnt.
Belege:
- [PRIMÄR] M124 (RmaOverviewViewModel.NewRma Z.86-126; SendForthViewModel.CheckForthState Z.337-409 und Z.626-629) - Begründung: Prozessrichtung und Pflichten sind durchgesetzt.
- [SEKUNDÄR] M036 (StockBL.LoadOpenWarehouses: vier RMA-Lager ausgeschlossen) - Begründung: Lagerkontext für RMA belegt.
Prüfidee: RMA-Schritt gegen die vorgesehene Richtung wird abgelehnt; Aktionstyp ohne erfüllte Pflichtangaben ist nicht speicherbar; Bestand bewegt sich nur über zugeordnete (RMA-)Lager.
Tracelinks: StRS-16; StRS-21
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - richtungsgebundene Rückgabeprozesse verhindern Bestandsfehler.
Status: belegt
ID: StRS-19
Titel: Löschschutz für verwendete Stammdaten und nachvollziehbare Löschung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Stammdatenpflege (Rolle); System
Vorbedingung: Stammdatum existiert; Verwendungen möglich (Posten, Tickets, Verträge, Belege)
Fakt: Adressstamm rechtegeprüft mit Löschschutz bei offenen Posten/Tickets/Verträgen (M002); Geräte-Soft-Delete mit Protokoll (M020); Checklisten mit Pflichtfeldern, beidseitiger Kaskade, Soft-Delete inkl. Log (M013); Fix-Kategorien löschgeschützt (M035).
Aussage: Das System soll Stammdaten nicht endgültig löschen, solange sie geschäftlich in Verwendung sind; Löschung erfolgt als rekonstruierbare, protokollierte Entfernung, feste Referenzkataloge bleiben löschgeschützt.
Ergebnis: Keine verwaisten Geschäftsvorfälle; Löschungen sind protokolliert und rekonstruierbar.
Belege:
- [PRIMÄR] M002 (AccountBL.DeleteAccount Z.752-803: Abbruch bei OPOS/Helpdesk/Verträgen) - Begründung: Löschschutz ist durchgesetzt.
- [PRIMÄR] M013 (CentronChecklistBL.DeleteCentronChecklist: IsActive=false; CentronChecklistLogs) - Begründung: protokollierte, rekonstruierbare Löschung.
- [PRIMÄR] M020 (AccountDeviceBL.DeleteAccountDevice: IsDeleted + Log) - Begründung: gleiche Löschsemantik für Geräte.
- [PRIMÄR] M035 (ChecklistVirtualObjectCategoryBL.DeleteChecklistVirtualCategory: IsFix-Sperre) - Begründung: Systemkataloge bleiben erhalten.
Prüfidee: Löschversuch einer Adresse mit offenen Posten/Tickets/Verträgen wird abgelehnt; zulässige Löschung erzeugt einen Logeintrag und bleibt wiederherstellbar; Fix-Kategorie ist nicht löschbar.
Tracelinks: StRS-20; StRS-2
Konsolidierung: Kandidat: M002, M013, M020, M035 als gemeinsame Löschsemantik zusammengeführt
Übernahmewürdigkeit: übernehmen - einheitliche Löschsemantik verhindert Datenverlust in laufenden Vorfällen.
Status: belegt
ID: StRS-20
Titel: Eindeutige Identifikation, Nummernvergabe und verlässliche Referenzdaten
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Stammdatenpflege/Vertrieb (Rolle); System
Vorbedingung: Neues Objekt (Adresse, Ticket, Kunde/Lieferant) wird angelegt; Fremdreferenz oder Tag wird erfasst
Fakt: Adressstamm mit automatischer Nummernvergabe (M002); Fremdreferenzen eindeutig (M048); Tags case-insensitive, Dedup nur im Code (M069); Unique-Nummern für Kunden/Lieferanten (M131); Ticketprojekte mit Nummernkreis (M074); Länder/Währung mit EZB-Kursversorgung (M015).
Aussage: Das System soll Geschäftsobjekte über eindeutige, systemvergebene Nummern identifizieren, Fremdreferenzen nur einmal je Ziel zulassen und Dubletten bei Tags verhindern; Währungsreferenzkurse stammen aus einer autoritativen Quelle.
Ergebnis: Jedes Objekt ist eindeutig adressierbar; keine doppelten Fremdverweise oder Tag-Dubletten; Kursdaten sind herkunftsgesichert.
Belege:
- [PRIMÄR] M002 (AccountBL.GetNewAccount: GetNextNumber(NumberGroupEnum.Account); Schema IX_AccountCustomers_UniqueNumber) - Begründung: Nummernvergabe ist systemseitig durchgesetzt.
- [PRIMÄR] M048 (ObjectExternalReferenceBL.CreateReference: Dublettenprüfung) - Begründung: Eindeutigkeit ist erzwungen.
- [SEKUNDÄR] M069 (TagsBL.GetTag/AddTag; kein Unique-Index auf dbo.Tags) - Begründung: Verhalten belegt, Durchsetzung nur im Code (Schwäche).
- [SEKUNDÄR] M015 (CountryBL.UpdateCurrencyRateByRateDictionary: EZB-URL) - Begründung: autoritative Kursquelle belegt.
Prüfidee: Zwei Neuanlagen erhalten unterschiedliche Nummern; dieselbe Fremdreferenz ist nicht zweimal speicherbar; „kunde" und „Kunde" führen zu einem Tag; Kursabruf weist EZB-Herkunft aus.
Tracelinks: StRS-19; StRS-17
Konsolidierung: Kandidat: M002, M048, M069, M131, M015 als Identifikations-/Referenzregel zusammengeführt
Übernahmewürdigkeit: übernehmen - eindeutige Nummern sind Integrationsgrundlage; Dublettenerkennung „nur Code" (M069) ist systemseitig zu ersetzen.
Status: belegt
ID: StRS-21
Titel: Beschaffung von Bedarfsermittlung bis Einkaufspreisfortschreibung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Einkauf (Rolle); System
Vorbedingung: Bedarfs-/Bestandsdaten und Lieferantenvorgaben vorhanden
Fakt: Bestellvorschlag aus Bedarf−Bestand+Zulauf, SV-Preisablauf, Filial-Export (M056); Filial-Vorgabelager (M036); elektronische Bestellungen (EDI) erzwingen Kreditorcodes/Restmengen mit Format-Routing (M023); Bestellmenge, Mindestbestellmenge nur Warnung, EDI-Abgleich mit Toleranz 0,005 (M117); EK-Fortschreibung fix/letzter/mischt, Doppelbuchungsschutz, Aufschlagstabellen (M084).
Aussage: Das System soll Beschaffungsbedarf zu prüffähigen Bestellvorschlägen verdichten, elektronisch übermittelte Bestellungen nur mit vollständigen Lieferantenvorgaben ausführen und Einkaufspreise nach gewählter Strategie fortschreiben; Doppelbuchungen werden ausgeschlossen.
Ergebnis: Vorschläge decken den Bedarf ab; unvollständige Bestellübermittlungen werden abgelehnt; EK-Preise folgen nachvollziehbar der Strategie ohne Doppelbuchungen.
Belege:
- [PRIMÄR] M023 (AlltronOrderBL.BuildOrderBody: Kreditorcode-Pflicht; EDIDispatcherBL.CreateEDISuggestionOrderAsync) - Begründung: Vollständigkeitszwang ist durchgesetzt.
- [PRIMÄR] M084 (ArticleStockBL.UpdateArticlePurchasePrice; ArticleLogBL.WriteAmountChangeLog: Doppelbuchungsschutz) - Begründung: Preisstrategie und Schutz sind implementiert.
- [SEKUNDÄR] M056 (OrderSuggestionListBL._sqlArticle) - Begründung: Vorschlagslogik belegt.
- [SEKUNDÄR] M117 (EDIInvoiceViewModel.GetItemsToUpdate: Toleranz 0,005) - Begründung: Toleranzverhalten belegt.
Prüfidee: Vorschlag entspricht Bedarf−Bestand+Zulauf; Bestellübermittlung ohne Kreditorcode wird abgelehnt; Doppelbuchung desselben Wareneingangs wird verhindert; Abweichung über 0,005 fällt im Abgleich auf.
Tracelinks: StRS-18; StRS-22
Konsolidierung: Kandidat: M056, M023, M117, M084, M036 als Beschaffungsregel zusammengeführt
Übernahmewürdigkeit: übernehmen - Kernbeschaffung belastbar; „Mindestmenge nur Warnung" (M117) und EK-Strategie „mischt" (M084) sind bewusst zu prüfen.
Status: belegt
ID: StRS-22
Titel: Kanalübergreifend gültige Verkaufspreise
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Vertrieb/Preispflege (Rolle); System
Vorbedingung: Aktions-/Sonderpreis definiert; Verkaufsvorgang (Maske oder Web) läuft
Fakt: Aktionspreise mit Pflichtangaben nur in der Maske geprüft, Kommissionier-Kappung, SN-Scan unvollständig (M111); WebCart rechnet Sonderpreise serverseitig (M125).
Aussage: Das System soll Preisregeln für Aktions- und Sonderpreise unabhängig vom Verkaufskanal einheitlich und zentral durchsetzen; Preisangaben dürfen nicht nur in einer einzelnen Eingabemaske geprüft werden.
Ergebnis: Derselbe Preis gilt in Desktop und Web; maskenbasierte Umgehungen sind ausgeschlossen.
Belege:
- [PRIMÄR] M125 (WebCartShopPage.razor: CalculatedPrice vom Webservice) - Begründung: zentrale Preisdurchsetzung im Web ist belegt.
- [PRIMÄR] M111 (AddActionPriceViewModel.Ok: Pflichtprüfung ausschließlich in der Maske; ActionPriceBL nur CRUD) - Begründung: beobachtete Durchsetzungslücke als Zielableitung.
Prüfidee: Derselbe Artikel mit Aktion zeigt in Desktop-Maske und Web-Warenkorb denselben Preis; eine gegen die Aktionsregel verstoßende Preiseingabe wird auch ohne Maske abgelehnt.
Tracelinks: StRS-21; StRS-15; StRS-13
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - heutige Prüfung nur in der Maske (M111) ist eine Lücke; Ziel ist kanalübergreifende zentrale Durchsetzung.
Status: belegt
ID: StRS-23
Titel: Vollständige Kommissionier- und Seriennummernerfassung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Lager/Kommissionierung (Rolle); System
Vorbedingung: Auftrag zur Kommissionierung freigegeben; serielle Artikel enthalten
Fakt: Kommissionier-Kappung und unvollständige SN-Scan-Maske als Beobachtung (M111).
Aussage: Das System soll Entnahmemengen nicht stillschweigend unter den bestätigten Mengen kappen und Seriennummern bei der Kommissionierung vollständig erfassen.
Ergebnis: Kommissionierte Mengen und Seriennummern entsprechen vollständig den Auftragsangaben; Abweichungen werden sichtbar gemacht.
Belege:
- [PRIMÄR] M111 (PositionViewModel.Done-Setter: value > Amount → Kappung; SNscannViewModel.ScannBarcode: NotImplementedException) - Begründung: implementiertes (mangelhaftes) Verhalten als Beobachtung.
Prüfidee: Auftrag mit 10 Stück Serienartikel verlangt 10 erfasste Seriennummern; weniger Scans blockieren die Übergabe; eine Kappung erzeugt einen sichtbaren Abweichungshinweis statt stiller Anpassung.
Tracelinks: StRS-21; StRS-18
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - Kappung und unvollständige SN-Scan-Maske (M111) sind Mängel; Neuimplementierung soll vollständige Erfassung erzwingen.
Status: belegt
ID: StRS-24
Titel: Externe Dienste authentifiziert, limitiert und kundenkontextbezogen einbinden
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: System (Integrationen); Administration
Vorbedingung: Partnerdienst (Versand, Daten, Finanz, Fernwartung) ist beauftragt; Zugangsdaten liegen verschlüsselt vor
Fakt: GLS Basic-Auth, Limits 50 Referenzen/30 Pakete (M095); Shipcloud API-Key (M096); COP SOAP mit Credentials im Body (M097); Egis HTML-escaped Credentials im TransactionHeader (M098); FinAPI OAuth2 mit Token-Gate (M099); Icecat Basic-Auth (M100); ITscope Basic „AccountId§Mail:ApiKey", Limit 50/Request (M101); docuFORM OAuth2+PKCE mit Zählerständen (M140); RiverDivo RMM mit timing-sicherem Access-Key, Web-Konten nur eigener Kunde (M059); TradePool XML-Schema-Zwang, Salted-Hash-Login (M078).
Aussage: Das System soll externe Dienste nur über deren vorgesehene, authentifizierte Anbindungen einbinden, deren Mengenlimits einhalten und Fernwartungszugriffe auf den jeweiligen Kunden beschränken.
Ergebnis: Partneraufrufe laufen authentifiziert und limitiert; Fernwartung greift nur auf den eigenen Kunden zu; Form-/Schemaverstöße werden abgelehnt.
Belege:
- [PRIMÄR] M099 (RestClientBase.GetJsonWebToken/SendRequestWithAccessToken: Token-Gate) - Begründung: Zugang nur mit gültigem Token durchgesetzt.
- [PRIMÄR] M059 (RiverDivoBL.ValidateRmmAccessKey: FixedTimeEquals; RiverConnectionBL: Web-Konten nur eigener Kunde) - Begründung: Beschränkung auf den Kundenkontext ist durchgesetzt.
- [PRIMÄR] M101 (ITscopeApi.GetUsernameForAuth; Limit 50/Request) - Begründung: Anmeldeschema und Mengenlimit belegt.
- [PRIMÄR] M095 (CentronGlsLogic.DoValidateShipment: Limits) - Begründung: Mengenlimits sind festgelegt.
Prüfidee: Aufruf ohne gültige Zugangsdaten/Token wird abgelehnt; Limitüberschreitung (z. B. 31 Pakete, 51 Referenzen) wird verhindert; Fernwartungskonto eines Kunden erreicht keine Daten fremder Kunden.
Tracelinks: StRS-3; StRS-6
Konsolidierung: Kandidat: M095-M101, M140, M059, M078 als gemeinsames Anbindungsmuster zusammengeführt
Übernahmewürdigkeit: übernehmen - Muster (Auth, Limits, Kundenkontext) fortführen; Credentials im Body (M097) bzw. escaped (M098) sind je Partner neu zu bewerten.
Status: belegt
ID: StRS-25
Titel: Funktionsumfang folgt der erworbenen Lizenz
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Lizenznehmer/Kunde; Administrator; System
Vorbedingung: Lizenzumfang ist definiert; Module installiert
Fakt: Modulsichtbarkeit = Rechte UND Lizenz, Centron-Vollizenz als Fallback mit Ausnahmen (MSP/PasswordManager/Produktion/AI/PLM), Settings ebenfalls gefiltert (M108); Produktion lizenzgebunden (M053); ServiceBoard-Lizenzbedingung (M071); Export-Lizenzbedingung im Passwort-Manager (M051); MyCentron lizenzoffen für alle (M115).
Aussage: Das System soll den verfügbaren Funktionsumfang aus der erworbenen Lizenz ableiten und lizenzlose Funktionen weder anbieten noch ausführen; Ausnahmen sind bewusst definiert.
Ergebnis: Nutzer sehen und erreichen nur lizenzierte Funktionen; Lizenzüberschreitungen werden abgelehnt.
Belege:
- [PRIMÄR] M108 (ModuleRegistrationItem.CheckModuleFeatures: HasLicense(LicenseGuids.X) || HasLicense(LicenseGuids.Centron); GetSettingsWithoutModule) - Begründung: Lizenzfilter ist durchgesetzt.
- [PRIMÄR] M053 (ProductionOrderBL/ProductionBL: Lizenz-Gate vor jedem Get/Save) - Begründung: Modulzugang ohne Lizenz verweigert.
- [PRIMÄR] M071 (TaskManagementHelpdeskActionHandler: ServiceBoard-Lizenz) - Begründung: Lizenzbedingung am Feature.
- [PRIMÄR] M115 (ModuleRegistration Z.774-792: MyCentron mit NoRightCheck, nur Lizenz) - Begründung: bewusste Ausnahme dokumentiert.
Prüfidee: Benutzer ohne entsprechende Lizenz sieht das Modul nicht und erhält beim Direktaufruf eine Ablehnung; MyCentron bleibt ohne Zusatzlizenz erreichbar.
Tracelinks: StRS-2; StRS-17; StRS-5
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Zentralregel gilt; Lizenzausnahmen (MSP/PasswordManager/Produktion/AI/PLM, MyCentron) als Sonderfälle mitführen.
Status: belegt
ID: StRS-26
Titel: Verpflichtender Tagesabschluss mit automatischer Vertretung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Außendienst/Service (Rolle); System
Vorbedingung: Arbeitstag im Tageskalender erfasst; Abwesenheit (Urlaub/Krankheit) gemeldet
Fakt: MyDay erzwingt den Tagesabschluss; bei Urlaub/Krankheit schließt der Systemuser den Tag automatisch ab (M044); die in M024 enthaltene alte Urlaubslogik ist stillgelegt/veraltet.
Aussage: Das System soll Arbeitstage verpflichtend abschließen und bei gemeldeter Abwesenheit den Abschluss automatisch im Namen des Systems vornehmen, damit keine Tage offen bleiben.
Ergebnis: Kein dauerhaft offener Arbeitstag; abwesende Mitarbeiter erhalten systemverantwortete Abschlüsse.
Belege:
- [PRIMÄR] M044 (MyDayNotificationsBL.GetDayNotifiedNotifications: Auto-Finalisierung mit Systemuser) - Begründung: Abschlusspflicht und Vertretung sind durchgesetzt.
- [KONTEXT] M024 (EmployeeHolidayBL: obsolete, Markierung im Code) - Begründung: belegt nur, dass die alte Urlaubslogik nicht fortgeführt wird.
Prüfidee: Ein offener Tag ohne Benutzerabschluss wird zum Stichtag automatisch geschlossen (bei Abwesenheit durch den Systemuser); ohne Abwesenheit blockiert/erinnert das System bis zum Abschluss.
Tracelinks: StRS-16
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Abschlusspflicht mit Vertretung sichert Auswertungs- und Abrechnungsbasis; die alte Urlaubslogik (M024) ist veraltet und wird nicht übernommen.
Status: belegt
ID: StRS-27
Titel: Mehrfache Bereitstellungsart für Betrieb und Auslieferung
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Übertragbarkeit (Installierbarkeit)
Akteur: Betrieb/IT-Dienstleister
Vorbedingung: Zielsystem (Windows-Server oder Containerplattform) verfügbar
Fakt: MSI-Installer, Nexus läuft als Windows-Dienst (M133); Docker-Setup mit DB+Webservice+SMTP+Nexus inkl. ACR (M134).
Aussage: Das System soll sowohl klassisch installierbar (als Dienst) als auch containerisiert bereitstellbar sein, damit Kundenbetrieb und Entwicklungsumgebung aus derselben Auslieferung entstehen.
Ergebnis: Installation per Installer bzw. Container-Stack ist wiederholbar durchführbar.
Belege:
- [PRIMÄR] M133 (WixSharpInstaller/Program.cs: ServiceInstaller Name=CentronNexus, Start auto) - Begründung: klassische Bereitstellungsart ist etabliert.
- [SEKUNDÄR] M134 (docker/compose/compose.yaml: Stack db, webservice, smtp, nexus) - Begründung: containerisierte Bereitstellung ist etabliert.
Prüfidee: Auf einem leeren Zielsystem gelingt die Installation sowohl per MSI/Dienst als auch per Container-Stack; beide Varianten starten und sind erreichbar.
Tracelinks: StRS-28; StRS-29
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - beide Bereitstellungsarten für den SaaS-Mandantenbetrieb weiterentwickeln.
Status: belegt
ID: StRS-28
Titel: Kontrolliertes Fehlerverhalten und blockadefreier Betrieb
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit
Akteur: System (Host/Dienste)
Vorbedingung: Dienst/Konsole startet; Nebensysteme (Telemetrie, Caches) laufen
Fakt: Konsolen-/Dienststart mit Selbstbeendigung bei Fehlern (M104/M105); Telemetrie deadlock-sicher (M072).
Aussage: Das System soll bei Startfehlern kontrolliert und nachvollziehbar beenden statt in inkonsistentem Zustand weiterzulaufen; Nebensysteme dürfen den Hauptbetrieb nicht blockieren.
Ergebnis: Fehlstarts hinterlassen keine „halben" Dienste; Störungen in Nebensystemen beeinträchtigen Kernfunktionen nicht.
Belege:
- [PRIMÄR] M105 (CentronService.OnStart: Startfehler → this.Stop()) - Begründung: kontrollierte Beendigung ist implementiert.
- [PRIMÄR] M072 (TelemetryBL.UpsertApiCallBatch: ExecuteWithDeadlockRetry) - Begründung: Nebensystem blockiert nicht.
Prüfidee: Ein erzwungener Startfehler führt zu sauberer Beendigung mit Fehlermeldung; eine Telemetriestörung verlangsamt oder blockiert Kernfunktionen nicht messbar.
Tracelinks: StRS-27
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - „Fail fast" und Entkopplung von Nebensystemen für den SaaS-Betrieb fortführen.
Status: belegt
ID: StRS-29
Titel: Automatisierte Qualitätssicherung vor jeder Freigabe
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit (Modifizierbarkeit)
Akteur: Entwicklungsteam/CI-System
Vorbedingung: Änderung ist eingecheckt
Fakt: Tests Unit/Integration/E2E/Playwright (M132); CI mit Build, Unit-, Regression- und Playwright-Matrix (M135-M137); täglicher CodeQL-Scan (M138); Docker/ACR als Testträger (M134).
Aussage: Das System (Entwicklungsprozess) soll jede Änderung vor Freigabe automatisiert bauen, in allen Teststufen prüfen und täglich auf Sicherheitsschwachstellen untersuchen; nicht bestandene Läufe blockieren die Freigabe.
Ergebnis: Freigaben erfolgen nur nach bestandenem automatisiertem Nachweis; Sicherheitsbefunde werden täglich sichtbar.
Belege:
- [PRIMÄR] M135 (Centron.Scripts/Program.cs: Target-Kette build inkl. end-to-end-tests) - Begründung: Prüfstufen sind automatisiert verankert.
- [PRIMÄR] M137 (security-pipeline.yaml: cron, CodeQL-Init/Analyze) - Begründung: Sicherheitsprüfung ist täglich terminiert.
- [SEKUNDÄR] M132 (tests-Baum: 8 Testprojekte inkl. Playwright) - Begründung: Teststufenbestand belegt.
Prüfidee: Ein Check-in mit fehlgeschlagenem Test oder CodeQL-Befund blockiert die Freigabe; ein vollständiger Lauf erzeugt das Freigabeartefakt.
Tracelinks: StRS-27; StRS-3
Konsolidierung: Kandidat: M132, M135, M136, M137, M138 zu einer QS-Regel zusammengeführt
Übernahmewürdigkeit: übernehmen - automatisierte QS ist Voraussetzung für belastbare SaaS-Releases.
Status: belegt
ID: StRS-30
Titel: [HYPOTHESE] Berichte ohne unbeschränkten Datenzugriff
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Sicherheit (Zugriffskontrolle)
Akteur: Berichtsverfasser/Report-Nutzer (Rolle); System
Vorbedingung: Bericht wird definiert oder ausgeführt
Fakt: Berichte liegen als Rohtext-SQL vor und sind als Sicherheitsrisiko bewertet (M057/M058).
Aussage: Das System soll Berichte so bereitstellen, dass über Berichtsdefinitionen keine unbeschränkten Abfragen auf Geschäftsdaten und keine Manipulationen möglich sind; Berichtserstellung erfolgt in einem kontrollierten Rahmen.
Ergebnis: Berichtsnutzer erreichen nur vorgesehene Daten; manipulierte oder übermäßige Abfragen werden verhindert.
Belege:
- [PRIMÄR] M057 (ReportDataBL.ExecuteQuery: Parameter per Stringverkettung in Rohtext-SQL; ReportsBL.GetRawSqlResult Z.110-113) - Begründung: Risikobeobachtung an durchsetzender Stelle; gewünschte Schutzregel existiert dort nicht.
Prüfidee: Ein Bericht ohne definierte Datenbeschränkung wird abgelehnt; ein Versuch, über eine Berichtsdefinition schreibend oder mandantenübergreifend zu lesen, scheitert.
Tracelinks: StRS-2; StRS-16
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - Rohtext-SQL ist nicht übernahmewürdig; das Zielbild (kontrollierte Berichtsdefinitionen) ist in SyRS/SwRS auszugestalten.
Status: HYPOTHESE
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/SwRS.md
+2491
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/SyRS.md
+744
View File
@@ -0,0 +1,744 @@
# SyRS - System Requirements Specification
Reverse Requirements Engineering - c-entron ERP-Suite. Ebene: Systemverhalten, Schnittstellen, Betrieb, Datenhaltung, Sicherheit. Tracelinks zeigen auf StRS (Ergebnisse\StRS.md); SwRS verlinkt nachfolgend auf diese Datei.
---
ID: SyRS-1
Titel: Rechteermittlung ausschließlich über Gruppen
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Authentifizierung/Autorisierung)
Vorbedingung: Benutzer mit Gruppenmitgliedschaften in Sichmemb/Sichtrus
Fakt: AppRightsBL.HasUserRight (AppRightsBL.cs Z.644-664) und CheckRightsFromUser (Z.95-111) ermitteln Rechte per SQL „Sichtrus INNER JOIN Sichmemb WHERE sm.Benutzer=:UserI3D", gecacht in AllRightsFromAppUser{I3D}; Rechte hängen nur an Gruppen; SichProtokoll als Rechte-Log (SSMS_DB_SCHEMA.sql Z.51211-51271).
Aussage: Das System soll Zugriffsrechte ausschließlich über Gruppenmitgliedschaften ermitteln, das Ergebnis pro Benutzer cachen und Rechteänderungen in SichProtokoll protokollieren.
Ergebnis: Nur Gruppenrechte gelten; Direktvergabe an Benutzer ist ausgeschlossen; Rechte-Log geführt.
Belege:
- [PRIMÄR] AppRightsBL.HasUserRight / CheckRightsFromUser (AppRightsBL.cs Z.644-664, Z.95-111), Bedingung SQL-Join Sichtrus/Sichmemb je Benutzer - Begründung: durchgesetzte Rechteermittlungsregel
- [PRIMÄR] SSMS_DB_SCHEMA.sql Z.51211-51271 (Sichmemb/Sichtrus ohne FK, SichProtokoll) - Begründung: Schema verankert Gruppenprinzip und Log
Prüfidee: Benutzer in Gruppe mit Recht X erhält X; Entzug der Gruppenmitgliedschaft entzieht X nach Cache-Neuaufbau; Eintrag in SichProtokoll vorhanden.
Tracelinks: StRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - bewährtes Gruppenprinzip mit Rechte-Log
Status: belegt
ID: SyRS-2
Titel: Lizenzpflicht für Webservice-Start, Token und Hardwarebindung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Webservice-Host / Lizenzverwaltung)
Vorbedingung: Lizenzdaten für Lizenz-GUID vorhanden
Fakt: LicenseManager.CheckLicense (LicenseManager.cs Z.258-302) ruft je GUID CheckLicenseVersion; LoadLicenses wirft bei fehlender Lizenz → Web-Service-Start schlägt fehl (Kommentar CentronHost.Start: Webservice-Version > lizenzierter Produktstand → Fehler); SQLManagementBL.GetDatabaseInfosForLicenseServer (Z.181-204) liefert DatabaseId/Name/CreatedDate/OwnerSid (Hardwarebindung); TicketWebServiceBL.GetWebServiceToken: ohne erfolgreiche Lizenzermittlung kein Token (SHA1-dekodierter Produkt-ID-Wert).
Aussage: Das System soll den Webservice nur mit gültiger, versionsschrankenkonformer Lizenz starten, Datenbankkennzahlen an den Lizenzserver melden und Webservice-Token erst nach erfolgreicher Lizenzermittlung ausgeben.
Ergebnis: Ohne/mit ungültiger Lizenz kein Start und keine Token-Ausgabe; Hardwarebindung aktiv.
Belege:
- [PRIMÄR] LicenseManager.CheckLicense (LicenseManager.cs Z.258-302) + LoadLicenses, Bedingung fehlende/unpassende Lizenz → Exception - Begründung: durchgesetzte Lizenzschranke
- [PRIMÄR] SQLManagementBL.GetDatabaseInfosForLicenseServer (Z.181-204); TicketWebServiceBL.GetWebServiceToken (Bedingung: Lizenzermittlung erfolgreich) - Begründung: Hardwarebindung und Token-Kopplung
Prüfidee: Lizenz entfernen → Startabbruch; Tokenanfrage ohne Lizenz → Fehler; Webservice-Version über lizenziertem Stand → Startfehler.
Tracelinks: StRS-1, StRS-25
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zentrale Lizenzdurchsetzung
Status: belegt
ID: SyRS-3
Titel: Begrenzung gleichzeitiger Tickets auf Lizenzanzahl
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Lizenzverwaltung)
Vorbedingung: Lizenzierte Anzahl abrufbar; Ticketanzahl ermittelbar
Fakt: LicenseManager.CheckLicense (LicenseManager.cs Z.258-302): wenn TicketBL.GetTicketCount >= GetLicenseCount → Fehler „Die maximale Anzahl an Lizenzen wurde erreicht."
Aussage: Das System soll die Anzahl gleichzeitiger Tickets gegen die lizenzierte Anzahl begrenzen und Überschreitungen mit definierter Fehlermeldung ablehnen.
Ergebnis: Login/Ticket-Erstellung über die Grenze scheitert mit der zitierten Meldung.
Belege:
- [PRIMÄR] LicenseManager.CheckLicense (LicenseManager.cs Z.258-302), Bedingung TicketBL.GetTicketCount >= GetLicenseCount - Begründung: durchgesetzte Mengenschranke
Prüfidee: Bei GetLicenseCount = n wird der (n+1). gleichzeitige Ticketabruf mit der genannten Fehlermeldung abgewiesen.
Tracelinks: StRS-1, StRS-25
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-4
Titel: Login-Abweisung nach Rechten und Kontostatus
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Authentifizierung)
Vorbedingung: Loginversuch gegen ApplicationKind
Fakt: Authenticator.ValidateRights (Z.68-86): Login abgewiesen bei DisallowingRight==true bzw. RequiredRight==false je ApplicationKind; AuthenticateUser (Z.109-155): Rechteprüfung vor Lizenz unter lock, existierendes Ticket wird ohne neue Lizenzprüfung wiederverwendet; ValidateAppUser (Z.157-218): Prüfung IsAccountDisabled, AccountDisabledFromDate/ToDate, IsActiveEmployeeCompact.
Aussage: Das System soll Logins bei anwendungsabhängig fehlenden Pflichtrechten oder vorliegenden Sperrrechten sowie bei gesperrten/zeitlich begrenzten/inaktiven Konten ablehnen und ein existierendes Ticket ohne erneute Lizenzprüfung wiederverwenden.
Ergebnis: Abgewiesene Logins erhalten kein Ticket; wiederverwendete Tickets verbrauchen keine zusätzliche Lizenz.
Belege:
- [PRIMÄR] Authenticator.ValidateRights (Z.68-86), Bedingung DisallowingRight==true || RequiredRight==false - Begründung: durchgesetzte Rechte-/Anwendungsschranke
- [PRIMÄR] Authenticator.ValidateAppUser (Z.157-218) und AuthenticateUser (Z.109-155) - Begründung: Kontostatus- und Ticket-Wiederverwendungsregel
Prüfidee: Gesperrtes Konto → Login abgewiesen; zweiter Login desselben Benutzers führt nicht zu erneutem Lizenzabzug.
Tracelinks: StRS-1, StRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-5
Titel: Zweifaktor-Authentifizierung nach Schaltung und Gültigkeit
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (2FA)
Vorbedingung: Login mit 2FA-Einstellungen (global/benutzerbezogen)
Fakt: TwoFactorAuthBL.ValidateTwoFactor/HasToValidateTwoFactor (Z.33-135): keine Prüfung wenn TwoFactorAuthEnabled==false oder user.UseTwoFactorAuthentication==false; immer Prüfung wenn requireTwoFactorAuth oder twoFactorAuthIsValidDuration<=0; sonst Gültigkeit = lastTwoFactorAuth.Date.AddDays(duration) (tagesgenau); Typen RadiusServer/EmailLink, sonst ArgumentOutOfRangeException.
Aussage: Das System soll 2FA je globaler Schaltung und Benutzereinstellung erzwingen bzw. aussetzen, die Gültigkeit tagesgenau nach Ablaufdatum bestimmen und unbekannte 2FA-Typen mit Ausnahme ablehnen.
Ergebnis: Nur gültige 2FA-Sitzungen überspringen die erneute Prüfung; unbekannte Typen brechen ab.
Belege:
- [PRIMÄR] TwoFactorAuthBL.ValidateTwoFactor / HasToValidateTwoFactor (Z.33-135), Bedingung TwoFactorAuthEnabled / UseTwoFactorAuthentication / requireTwoFactorAuth / duration - Begründung: durchgesetzte 2FA-Regeln
Prüfidee: Abgelaufene 2FA-Gültigkeit → erneute Prüfpflicht; unbekannter Typ → ArgumentOutOfRangeException.
Tracelinks: StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-6
Titel: Passwortprüfung und Passwortänderungsregeln
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Benutzerverwaltung)
Vorbedingung: Lokaler c-entron-Benutzer
Fakt: BasicAuthenticator.AuthenticateInternal (Z.35-71): Vergleich Name + SHA1-Password; Kommentar Z.48 „// TODO the password should be salted!!!"; UsersBL.UpdatePassword: nur Mindestlänge (PasswordMinLength) als Regel; AD/Entra/OIDC-Benutzer dürfen das c-entron-Passwort nicht ändern.
Aussage: Das System soll lokale Logins gegen Name + SHA1-Hash prüfen, Passwortänderungen nur bei Einhaltung der Mindestlänge zulassen und extern verwalteten (AD/Entra/OIDC) Konten die lokale Passwortänderung verweigern.
Ergebnis: Externe Konten können kein lokales Passwort setzen; Passwortregeln greifen nur lokal.
Belege:
- [PRIMÄR] BasicAuthenticator.AuthenticateInternal (Z.35-71), Bedingung Name+SHA1-Password-Vergleich - Begründung: durchgesetztes Authentifizierungsverfahren
- [SEKUNDÄR] UsersBL.UpdatePassword (PasswordMinLength; Ausschluss AD/Entra/OIDC) - Begründung: Passwortregel im Code
Prüfidee: Falsches SHA1-Passwort → Abweisung; AD-Benutzer versucht Passwortänderung → Ablehnung; zu kurzes Passwort → Ablehnung.
Tracelinks: StRS-1, StRS-3
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - SHA1 ohne Salt laut TODO-Kommentar bekannt unsicher; Umstellung auf gesalzenes Verfahren anstreben
Status: belegt
ID: SyRS-7
Titel: Web-Konto-Login-Kaskade mit Protokollierung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Web-Portal-Authentifizierung)
Vorbedingung: WebAccount mit Status 1
Fakt: WebAccountBL.LoginWithWebAccount (Z.54-102): Status==1 && Username.ToUpper() && SHA1-Password; anschließende Kaskade IsCustomerActiveAndNotLocked, contact.IsActive, address.IsActive, IsAccountActiveAndNotLocked; schreibt LastLoginIP/LastLoginDate.
Aussage: Das System soll Web-Konto-Logins nur bei aktiver, nicht gesperrter Kette (Konto → Kunde → Kontakt → Adresse) zulassen und LastLoginIP/LastLoginDate fortgeschreiben.
Ergebnis: Inaktive oder gesperrte Kettenglieder blockieren den Login; letzter Login ist nachvollziehbar.
Belege:
- [PRIMÄR] WebAccountBL.LoginWithWebAccount (Z.54-102), Bedingung Status==1, Kaskadenprüfungen - Begründung: durchgesetzte Login-Kaskade
Prüfidee: Gesperrter Kunde mit aktivem WebAccount → Login abgewiesen; erfolgreicher Login setzt LastLoginIP/LastLoginDate.
Tracelinks: StRS-6, StRS-15
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-8
Titel: Ticket-Authentifizierung am Host (Bearer/Query)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System (Centron.Host)
Vorbedingung: HTTP-Aufruf mit Ticket
Fakt: Centron.Host TicketAuthenticationHandler.HandleAuthenticateAsync: Ticket aus Query-Parameter access_token oder Header „Authorization: Bearer" (exakt 2 Teile); leer/ungültig → AuthenticateResult.Fail; Validierung via AuthenticationTicketBL.GetAuthTicketInfo(token, ipAddress, apiMethod); Claims: NameIdentifier=Token, AuthenticationTypeIdentifier (AccessToken vs Ticket), UserIdentifier=AppUserI3D.
Aussage: Das System soll Dienste ausschließlich per Query-Token oder Bearer-Header authentifizieren, ungültige Tickets mit Fail ablehnen und den validierten Kontext als Claims bereitstellen.
Ergebnis: Nur Tickets/Access Tokens mit gültiger GetAuthTicketInfo-Prüfung gelangen durch.
Belege:
- [PRIMÄR] TicketAuthenticationHandler.HandleAuthenticateAsync (Centron.Host), Bedingung Header „Authorization: Bearer" mit exakt 2 Teilen / access_token - Begründung: durchgesetzte Ticket-Authentifizierung
Prüfidee: Aufruf ohne/ mit defektem Header → AuthenticateResult.Fail; gültiges Token erzeugt Claims UserIdentifier/NameIdentifier.
Tracelinks: StRS-1
Konsolidierung: Kandidat: Ticketvalidierung doppelt implementiert (TicketAuthenticationHandler im Host und AuthenticateInterceptor, M103) - eine Quelle für Ticketprüfung anstreben
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-9
Titel: Interceptor-Durchsetzung: Ticketpflicht, Beschränkungen, Slide-Refresh
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Centron.Host Interceptors)
Vorbedingung: Authentifizierter Dienstaufruf
Fakt: AuthenticateInterceptor (Priority 10): request.Ticket leer → „You need to provide a ticket"; applicationIsBlocked = attribute.Applications.Count>0 && !Contains(ticketApplicationKind); webAccountIsBlocked = WebAccountI3D != null && !AllowWebAccountLogin; blockiert → StatusCode.Failed bzw. InvalidTicket ohne invocation.Proceed(); TicketBL.RefreshTicketExpireDate (Slide-Verlängerung); Access Tokens ohne Anwendungsbeschränkung (Kommentar); IP-Ermittlung X-Forwarded-For → X-Real-IP → RemoteIpAddress; Kommentar Z.33-37: Beschränkung deckt nur eine Richtung; LoggedInUserInterceptor (Priority 20) setzt LoggedInUserManager.AppUserI3D/Ticket/IsAccessToken/WebAccountI3D/LicenseGuid, Double-Logging im AccessTokenLog per Flag verhindert.
Aussage: Das System soll jeden Dienstaufruf auf Ticketpflicht sowie Anwendungs- und Web-Konto-Beschränkung prüfen, blockierte Aufrufe ohne Ausführung ablehnen, gültige Tickets slidend verlängern und den Aufrufkontext zentral setzen.
Ergebnis: Blockierte Aufrufe erreichen die Fachlogik nicht; Ticketablauf verschiebt sich bei Nutzung; Kontext steht dem Aufruf konsistent zur Verfügung.
Belege:
- [PRIMÄR] AuthenticateInterceptor (Priority 10), Bedingung applicationIsBlocked / webAccountIsBlocked / leeres Ticket - Begründung: durchgesetzte Aufrufschranken (M103)
- [PRIMÄR] LoggedInUserInterceptor (Priority 20), Setting des LoggedInUserManager + Double-Log-Flag - Begründung: Kontextsetzung pro Aufruf
Prüfidee: Ticket einer unzulässigen Anwendung → Failed/InvalidTicket ohne Methodenaufruf; aufeinanderfolgende Aufrufe verlängern Ticketablauf.
Tracelinks: StRS-1, StRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Einschränkungsrichtung laut Kommentar dokumentieren
Status: belegt
ID: SyRS-10
Titel: HTTP-Autorisierung 401/403 fail-closed
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Centron.Controllers)
Vorbedingung: Controller-Aufruf mit Rechtefilter
Fakt: Centron.Controllers UserRightAuthorizationFilter: currentUser==null → UnauthorizedResult (401); !HasUserRight(requiredRightId) → ForbidResult (403); AllUserRightsAuthorizationFilter: UND-Verknüpfung aller Rechte, leere Liste → ForbidResult (fail-closed); ApiUserUtils.GetCurrent: ClaimsPrincipal → GetLoggedInUserByToken.
Aussage: Das System soll Controller-Aufrufe ohne authentifizierten Benutzer mit 401 und ohne erforderliches Recht mit 403 ablehnen; Mehrfachrechte UND-verknüpfen und eine leere Rechtefestlegung ablehnen (fail-closed).
Ergebnis: Kein unautorisierter oder unterprivilegierter Zugriff auf Controller-Routen.
Belege:
- [PRIMÄR] UserRightAuthorizationFilter / AllUserRightsAuthorizationFilter (Centron.Controllers), Bedingung currentUser==null → 401, !HasUserRight → 403, leere Liste → 403 - Begründung: durchgesetzte Autorisierung
Prüfidee: Aufruf ohne Benutzer → 401; mit Benutzer ohne Recht → 403; AllUserRights mit leerer Rechtefestlegung → 403.
Tracelinks: StRS-2
Konsolidierung: Kandidat: Rechteprüfung in MVC-Filtern und in BL-Kanälen (siehe AccessTokenWebServiceBL-Kommentar) doppelt verankert
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-11
Titel: Access-Token-Verwaltung nach Own-or-Right
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (Token-Verwaltung)
Vorbedingung: Angemeldeter Benutzer mit/ohne VIEW_ALL
Fakt: AccessTokenWebServiceBL.GetById/Delete (Centron.BL\WebServices\Administration\AccessTokens): Own-or-Right (VIEW_ALL); Delete ohne Own-Token-Ausnahme nur mit DELETE_ALL; CreatePersonalToken zwingend eigener Employee; Kommentar: Rights-Checks bewusst in der BL, damit auch der WPF-ILogic-Kanal respektiert wird.
Aussage: Das System soll Access-Token sichtbar/löschbar nur nach Own-or-Right-Prüfung (VIEW_ALL, Löschen ohne Own-Token nur mit DELETE_ALL) behandeln und persönliche Token zwingend für den eigenen Employee anlegen.
Ergebnis: Kein fremdes Token ohne Sonderrecht einsehbar/löschbar.
Belege:
- [PRIMÄR] AccessTokenWebServiceBL.GetById / Delete (Centron.BL\WebServices\Administration\AccessTokens), Bedingung Own-or-Right VIEW_ALL / DELETE_ALL - Begründung: durchgesetzte Tokenrechte
Prüfidee: Benutzer ohne VIEW_ALL erhält fremdes Token nicht; Delete eines fremden Tokens ohne DELETE_ALL wird abgewiesen.
Tracelinks: StRS-2, StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - BL-seitige Prüfung deckt beide Kanäle (REST und WPF-ILogic)
Status: belegt
ID: SyRS-12
Titel: Host-Start-Härtung: Lizenz vor DB, JWT-Pflicht
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (CentronHost)
Vorbedingung: Host-Start
Fakt: CentronHost.Start: TryLoadLicense vor SetupDatabaseConnection (Kommentar: License check throws wenn Lizenz ungültig oder Webservice-Version > lizenzierter Produktstand); MapControllers().RequireAuthorization(); JWT-Bearer mit ValidateIssuer/Audience/Lifetime/IssuerSigningKey, RequireSignedTokens, RequireExpirationTime, ValidateTokenReplay=true.
Aussage: Das System soll beim Start zuerst die Lizenz (inkl. Versionsschranke) laden, alle Controller autorisierungspflichtig machen und JWTs vollständig (Aussteller, Audience, Lebensdauer, Signatur, Ablauf, Token-Replay) validieren.
Ergebnis: Kein Betrieb ohne gültige Lizenz; unsignierte, abgelaufene oder wiederverwendete JWTs werden abgewiesen.
Belege:
- [PRIMÄR] CentronHost.Start (Reihenfolge TryLoadLicense → SetupDatabaseConnection; MapControllers().RequireAuthorization(); JWT-Bearer-Optionen inkl. ValidateTokenReplay=true) - Begründung: durchgesetzte Start- und JWT-Regeln
Prüfidee: Unsigniertes/abgelaufenes JWT → 401; Token-Replay → Ablehnung; Lizenzfehler bricht Start vor DB-Setup ab.
Tracelinks: StRS-6, StRS-25
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-13
Titel: Pauschale CORS-Freigabe des Hosts
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (CentronHost)
Vorbedingung: Host läuft
Fakt: CentronHost.Start: CORS AllowAnyOrigin / AllowAnyHeader / AllowAnyMethod.
Aussage: Das System soll Cross-Origin-Anfragen aktuell pauschal (jede Origin, jeder Header, jede Methode) zulassen, bis eine restriktivere Richtlinie konfiguriert ist.
Ergebnis: Browser-Aufrufe fremder Origins werden nicht per CORS blockiert.
Belege:
- [PRIMÄR] CentronHost.Start (CORS-Policy AllowAnyOrigin/AllowAnyHeader/AllowAnyMethod) - Begründung: durchgesetzte Policy im Host-Setup
Prüfidee: Preflight/Request mit fremdem Origin liefert CORS-Freigabe-Header ohne Ablehnung.
Tracelinks: StRS-6
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - pauschale CORS-Policy aus Sicherheitssicht zu weit; Origin-Allowliste anstreben
Status: belegt
ID: SyRS-14
Titel: Hintergrunddienste nur bei freigeschaltetem ExecuteServices
Ebene: SyRS
Typ: Betrieb
Qualitätsmerkmal:
Akteur: System (CentronHost)
Vorbedingung: Host-Start mit WebServiceConfig
Fakt: CentronHost.Start: Hosted Services nur wenn WebServiceConfigHelper.Current.ExecuteServices==true.
Aussage: Das System soll die im Host registrierten Hintergrunddienste nur starten, wenn die Konfiguration ExecuteServices aktiviert.
Ergebnis: Ohne Schaltung laufen keine Host-Hintergrunddienste.
Belege:
- [PRIMÄR] CentronHost.Start, Bedingung WebServiceConfigHelper.Current.ExecuteServices==true - Begründung: durchgesetzte Startbedingung für Hosted Services
Prüfidee: ExecuteServices=false → keine registrierten IHostedService werden gestartet; true → Start aller Dienste.
Tracelinks: StRS-24
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-15
Titel: Protokoll REST/POST ohne SOAP, URI-Eindeutigkeit
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System (CentronWcfBridge / Centron.Host)
Vorbedingung: Host-Start mit registrierten Diensten
Fakt: CentronWcfBridge.MapCentronRestService: jede ICentronRestService-Methode als MapPost(„/REST"+UriTemplate) bzw. /RESTC (Compression); duplicateUris → InvalidOperationException beim Start; Grep „SOAP" in Centron.Host: 0 Treffer.
Aussage: Das System soll alle Webservice-Methoden ausschließlich als REST-POST (komprimierbar über /RESTC) bereitstellen und doppelte URIs mit Startabbruch (InvalidOperationException) quittieren.
Ergebnis: Einheitliches POST-Protokoll; URI-Kollisionen verhindern fehlerhaften Start.
Belege:
- [PRIMÄR] MapCentronRestService (MapPost je Methode; duplicateUris → InvalidOperationException) - Begründung: durchgesetzte Routing-Regel
- [KONTEXT] Grep „SOAP" in Centron.Host: 0 Treffer - Begründung: Protokollbestimmung REST/POST
Prüfidee: Doppelte UriTemplate in zwei Diensten → Startabbruch; jede Methode ist nur per POST erreichbar.
Tracelinks: StRS-24, StRS-6
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-16
Titel: Hub-Autorisierung mit SecretKey-Policy
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (SignalR-Hubs)
Vorbedingung: SignalR-Verbindungsaufbau
Fakt: SecretKeyHandler.HandleRequirementAsync: nur wenn authHeader.StartsWith(„Bearer ") && secretKey == requirement.SecretKey → Succeed; NotificationsHub [Authorize(Policy=„SecretKey")] mit statischem Schlüssel aus WebServiceConfigHelper; AvailabilityStatusHub/ChatHub/TapiClientHub nur [Authorize].
Aussage: Das System soll alle SignalR-Hubs autorisierungspflichtig machen und den NotificationsHub zusätzlich per statischem Bearer-SecretKey aus der Webservice-Konfiguration absichern.
Ergebnis: Verbindungen ohne gültigen Bearer-SecretKey bzw. Autorisierung werden abgelehnt.
Belege:
- [PRIMÄR] SecretKeyHandler.HandleRequirementAsync, Bedingung StartsWith(„Bearer ") && secretKey == requirement.SecretKey - Begründung: durchgesetzte Hub-Schranke
Prüfidee: NotificationsHub-Verbindung ohne korrekten SecretKey → abgewiesen; andere Hubs ohne [Authorize]-Nachweis → abgewiesen.
Tracelinks: StRS-24, StRS-17
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - statischer Schlüssel ohne Rotation; austauschbares Geheimnis anstreben
Status: belegt
ID: SyRS-17
Titel: Nexus-Host-Schemata und Port-Autorisierung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (CentronNexus.Host)
Vorbedingung: Nexus-Host-Start unter Linux
Fakt: CentronNexus.Host Program.cs ConfigureWebHostLinux (M126): nur UriSchemeHttps (PKCS12 aus HostConfig) oder UriSchemeHttp, sonst InvalidDataException; Kestrel auf Host-Port (Default 8050) plus CustomerPortalConfig.Port wenn gesetzt; PortAuthorization.PortHandler: ohne Portal-Port-Konfiguration immer erfolgreich, sonst nur wenn http.Connection.LocalPort == AllowedPort.
Aussage: Das System soll den Nexus-Host nur mit HTTPS (PKCS12) oder HTTP starten, den Host-Port (Default 8050) plus optionalen Portal-Port binden und Zugriffe auf dem Portal-Port nur bei übereinstimmendem lokalen Port zulassen.
Ergebnis: Unbekannte Schemata verhindern den Start; Portal-Port akzeptiert nur autorisierte Verbindungen.
Belege:
- [PRIMÄR] ConfigureWebHostLinux (M126), Bedingung UriSchemeHttps/UriSchemeHttp sonst InvalidDataException - Begründung: durchgesetzte Schema-Schranke
- [PRIMÄR] PortAuthorization.PortHandler (Bedingung http.Connection.LocalPort == AllowedPort) - Begründung: durchgesetzte Port-Prüfung
Prüfidee: Konfiguration mit ftp-Schema → Startabbruch; Request auf Portal-Port mit fremdem LocalPort → abgewiesen.
Tracelinks: StRS-6
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-18
Titel: Portal-Cookie- und OIDC-Authentifizierung
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (CentronNexus.Host Portal)
Vorbedingung: Portal-Zugriff
Fakt: CentronNexus.Host (M126): Cookie-Auth LoginPath=/auth, MaxAge 12h, SameSite Lax; OIDC mit OnRemoteFailure-Handler.
Aussage: Das System soll Portal-Logins per Cookie (LoginPath /auth, MaxAge 12 h, SameSite Lax) und OIDC-Anmeldungen mit behandelter Remote-Failure absichern.
Ergebnis: Cookies laufen nach 12 h ab; OIDC-Fehler führen in definierte Fehlerbehandlung statt Absturz.
Belege:
- [PRIMÄR] CentronNexus.Host Program.cs (Cookie-Optionen LoginPath/MaxAge/SameSite; OIDC OnRemoteFailure) (M126) - Begründung: durchgesetzte Auth-Konfiguration
Prüfidee: Cookie nach 12 h ungültig; fehlgeschlagener OIDC-Redirect landet im OnRemoteFailure-Handler.
Tracelinks: StRS-6, StRS-15
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-19
Titel: Client-Verkehr: RESTC/POST, Ticket-Pflicht, unendlicher Timeout
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Client (CentronWebService) ↔ System
Vorbedingung: Bestehende Dienstverbindung
Fakt: CentronWebService (Centron.WebServices.Core\Connections): BaseAddress + „/RESTC/", jede Methode HttpMethod.Post, Header Accept-Language, Content-Type/Content-Type-Version (Default CompressedDataContractSerializer); StatusCode != OK → Exception „Connection failed on method ..."; Timeout = InfiniteTimeSpan (bewusst, lange Methoden >15 min); Request/Request<T>: [DataMember] public string Ticket an Basisklasse aller Anfragen; serverseitig PRIMÄR: leerer Ticket → „You need to provide a ticket" (AuthenticateInterceptor).
Aussage: Das System soll den Client-Verkehr als komprimierbares REST-POST mit Ticket-DataMember in jeder Anfrage abwickeln, Nicht-OK-Statuscodes als Ausnahme melden und keinen Client-Timeout setzen (lange Methoden >15 min).
Ergebnis: Einheitlicher, fehlertoleranter Verkehr für langlaufende Operationen.
Belege:
- [PRIMÄR] AuthenticateInterceptor (M103), Bedingung request.Ticket leer → „You need to provide a ticket" - Begründung: serverseitig durchgesetzte Ticketpflicht
- [SEKUNDÄR] CentronWebService Connections (RESTC/POST, StatusCode-Exception, InfiniteTimeSpan) + Request<T> [DataMember] Ticket - Begründung: Client-Protokollkonvention
Prüfidee: Anfrage ohne Ticket wird serverseitig abgewiesen; HTTP-Fehlerstatus erzeugt „Connection failed on method ...".
Tracelinks: StRS-24, StRS-1
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - unendlicher Timeout ist bewusst gewählt; dafür Server-seitige Ablaufkontrolle vorsehen
Status: belegt
ID: SyRS-20
Titel: Zentrale DAO-Schicht mit stiller String-Kürzung
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System (DAO/NHibernate)
Vorbedingung: Datenzugriff über DAOFactory
Fakt: DAOFactory.InitializeAsyncInternal (Z.89-129): NHibernate/FluentNHibernate, MsSqlConfiguration.MsSql2008 mit CentronMsSql2008Dialect, DefaultSchema(„dbo"), Mappings AddFromAssemblyOf<BaseMaps<BaseEntity>>; Listener PreUpdate: ChangeTracking/WhyIsMyEntityUpdated/TruncateStrings/StringOrBinary (nur DEBUG), PreInsert: TruncateStrings+StringOrBinary; GetSession (Z.166-178): ohne IsInitialized/HasConnection → InvalidOperationException; Warten in 50-ms-Schleife während SessionFactory-Neuaufbau; TruncateStringsEventListener.TruncateStringsIfNeeded (Z.37-51): zu lange Strings still auf Mappable-Länge gekürzt (Substring).
Aussage: Das System soll den gesamten Datenzugriff über eine zentrale NHibernate-DAO-Schicht (Schema dbo) führen, Zugriffe vor Initialisierung ablehnen, SessionFactory-Neuaufbau abwarten und zu lange Strings vor Insert/Update still auf die Ziellänge kürzen.
Ergebnis: Keine SQL-Fehler durch Überlängen; uninitialisierte Zugriffe scheitern kontrolliert.
Belege:
- [PRIMÄR] DAOFactory.InitializeAsyncInternal (Z.89-129) / GetSession (Z.166-178), Bedingung !IsInitialized || !HasConnection → InvalidOperationException - Begründung: durchgesetzte Lebenszyklusregeln
- [PRIMÄR] TruncateStringsEventListener.TruncateStringsIfNeeded (Z.37-51), PreInsert/PreUpdate Substring - Begründung: durchgesetzte Kürzungsregel
Prüfidee: Insert eines 300-Zeichen-Werts in varchar(100)-Spalte wird ohne Fehler gekürzt gespeichert; Zugriff vor Init → InvalidOperationException.
Tracelinks: StRS-28
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - stilles Kürzen maskiert Datenverlust; Validierung an der Oberfläche anstreben
Status: belegt
ID: SyRS-21
Titel: Zählerbasiertes Transaktionsmanagement inkl. Roh-SQL
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System (DAOSession)
Vorbedingung: Verschachtelte Geschäftsoperationen auf einer Session
Fakt: DAOSession (Z.89-124, 226-239): verschachtelte Transaktionen über Zähler; Commit nur bei Zählerstand 0, sonst „The transaction has already ended..."; RollbackTransaction setzt Zähler auf 0; Dispose rollt offene Transaktion zurück; WithTransaction (Z.145-182): Commit nur bei ResultStatus.Success, sonst Rollback; bei Exception Rollback + Rethrow; RawSqlAccessDAO (Z.31-79): Roh-SQL über Session.Connection.CreateCommand(), enlistet in Session.GetCurrentTransaction().
Aussage: Das System soll verschachtelte Transaktionen zählerbasiert nur am äußeren Rand committen, bei Misserfolg, Ausnahme oder Dispose vollständig zurückrollen und Roh-SQL in die laufende Session-Transaktion einbetten.
Ergebnis: Kein Teilcommit in verschachtelten Operationen.
Belege:
- [PRIMÄR] DAOSession (Z.89-124, Z.145-182, Z.226-239), Bedingung Zählerstand 0 / ResultStatus.Success - Begründung: durchgesetzte Transaktionsregeln
- [PRIMÄR] RawSqlAccessDAO (Z.31-79), Enlistment in GetCurrentTransaction() - Begründung: Roh-SQL teilnimmt an Transaktion
Prüfidee: Exception in verschachtelter WithTransaction rollt alles zurück; inneres Commit vor Zähler 0 wird mit definierter Meldung abgewiesen.
Tracelinks: StRS-7
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-22
Titel: Beleg-Concurrency über ConcurrencyControlGuid
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System (Belegsicherung)
Vorbedingung: Beleg gleichzeitig durch zwei Sätze bearbeitet
Fakt: SaveReceiptRepository.GetExistingReceiptTableCheckConcurrency (Z.200-207): ConcurrencyControlGuid != receipt.ConcurrencyControlGuid → ReceiptConcurrencyConflictException; Fang → Result-Fehlercode ReceiptConcurrencyConflictOnSave; Muster je Belegart (RechKopf/AufKopf/GutKopf).
Aussage: Das System soll gleichzeitige Belegänderungen über den Vergleich von ConcurrencyControlGuid erkennen und als Result-Misserfolg ReceiptConcurrencyConflictOnSave melden.
Ergebnis: Zweit speichernder Satz erhält definierten Konfliktfehler statt stiller Überschreibung.
Belege:
- [PRIMÄR] SaveReceiptRepository.GetExistingReceiptTableCheckConcurrency (Z.200-207), Bedingung ConcurrencyControlGuid != receipt.ConcurrencyControlGuid - Begründung: durchgesetzte Optimistic-Concurrency-Prüfung
Prüfidee: Zwei Sessions laden denselben Beleg; erstes Speichern gelingt, zweites mit altem Guid → ReceiptConcurrencyConflictOnSave.
Tracelinks: StRS-7
Konsolidierung: Kandidat: Muster in drei Belegarten (RechKopf/AufKopf/GutKopf) wiederholt - generische Prüfung prüfen
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-23
Titel: Datenbank-Schema-Rahmen und anwendungsseitige Integrität
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System (Datenhaltung)
Vorbedingung: Datenbank nach SSMS_DB_SCHEMA
Fakt: SSMS_DB_SCHEMA.sql: 1535 dbo-Tabellen, nur 134 FOREIGN KEYs, 0 CHECK-Constraints; IDENTITY(1,1) in 1471 Tabellen (I3D), nur 33 uniqueidentifier; IX_AccountCustomers_UniqueNumber (Z.3784) / IX_AccountSuppliers_UniqueNumber (Z.3854); RechKopf (Z.3231ff): Nummer/Version/Datum/KundenID NOT NULL, Status NULL, IsFixed bit NOT NULL, Preisfelder DEFAULT 0; 3 FKs WITH NOCHECK (ArticleImport); Textbausteine-Tabellen statt Sprachspalten; Referenzintegrität der Kerntabellen liegt in der Anwendung.
Aussage: Das System soll das Schema als I3D-IDENTITY-Modell mit wenigen DB-FKs und ohne CHECK-Constraints betreiben und Referenzintegrität der Kerntabellen anwendungsseitig plus Eindeutigkeit der Kunden-/Lieferantennummern über Unique-Indizes sicherstellen.
Ergebnis: Schema ist homogen (dbo, I3D); Nummern-Eindeutigkeit DB-seitig erzwungen; RI-Verletzungen müssen von der Anwendung verhindert werden.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql (Z.3784, Z.3854 Unique-Indizes; Z.3231ff RechKopf NOT NULL/DEFAULT; Zählung 1535 Tabellen/134 FKs/0 CHECKs) - Begründung: Schema als durchgesetzte Basis
Prüfidee: Doppelte Kunden-UniqueNumber → DB-Fehler; RechKopf ohne Nummer → DB-Fehler; verwaiste Detailzeilen sind DB-seitig möglich (RI-Prüfung nur in Anwendung).
Tracelinks: StRS-20, StRS-19
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - bewusst dünn restraintes Schema; RI-Gewährleistung liegt auf Anwendungsseite und muss getestet werden
Status: belegt
ID: SyRS-24
Titel: Entitätsidentität über I3D und stabile Objektart-Nummern
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System (Entitätsmodell)
Vorbedingung: Persistente Entität mit I3D > 0
Fakt: PersistedEntity.operator == (Z.14-61): Gleichheit bei I3D>0 allein über I3D (proxy-sicher), GetHashCode über I3D (Z.86-99); BaseEntity: [DataContract], virtual int I3D; CentronObjectKindNumeric (M093): stabile Objektart-Nummern als wire contract (OfferClass=1, InvoiceClass=4, CustomerClass=5000012), neue Werte nur am Ende (Kommentar).
Aussage: Das System soll die Entitätsidentität bei positivem I3D ausschließlich über I3D bestimmen und Objektart-Nummern als stabilen Wire-Contract führen, der nur am Ende erweitert wird.
Ergebnis: Proxy-sichere Gleichheit; nummerierte Objektarten bleiben über Releases hinweg zuordnungsfest.
Belege:
- [PRIMÄR] PersistedEntity.operator == (Z.14-61) / GetHashCode (Z.86-99), Bedingung I3D > 0 - Begründung: durchgesetzte Identitätsregel
- [PRIMÄR] CentronObjectKindNumeric (M093), Kompatibilitätskommentar „nur am Ende erweitern" - Begründung: Wire-Contract-Garantie
Prüfidee: Zwei Instanzen gleicher Klasse mit gleichem I3D sind gleich (auch als Proxy); bestehende Objektart-Nummern ändern sich bei Release nicht.
Tracelinks: StRS-20
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-25
Titel: Cache-Update-Verfahren mit Recovery und Statistik-Neuaufbau
Ebene: SyRS
Typ: Betrieb
Qualitätsmerkmal:
Akteur: System (CachedTableBL)
Vorbedingung: Cache-Tabellen mit CachedTableStatistics
Fakt: CachedTableBL.ExecuteCacheUpdates (Z.98-110): Auswahl (IsUpdateRequested || LastUpdated==null || LastUpdated < heute) && (!IsUpdating || LastUpdated < DateTime.Now.AddMinutes(-10)) → hängengebliebene Updates >10 min werden erneut verarbeitet; ExecuteUpdateCache (Z.188-245): IsUpdating=true, StartTransaction, bei Fehler Rollback + Flag zurück, bei Erfolg LastUpdated=now + Commit; UpdateCacheSalesStatistic (Z.252, 1029): TruncateTable(CacheSalesStatistic) + Raw-SQL INSERT SELECT über cvw_InvoicePos/cvw_CreditVoucherPos mit rk.Status IN (1,2), commandTimeout 1800s; Schema CachedTableStatistics: TableName/IsUpdateRequested/IsUpdating NOT NULL.
Aussage: Das System soll Cache-Tabellen bedarfs- bzw. taggesteuert mit 10-Minuten-Recovery hängender Läufe transaktional aktualisieren und die Vertriebsstatistik über Truncate+INSERT SELECT nur aus Belegen mit Status 1/2 mit 1800-s-Timeout neu aufbauen.
Ergebnis: Hängende Läufe werden automatisch wiederholt; Fehler rollen inklusive IsUpdating-Flag zurück; Statistik enthält nur gebuchte/stornierte Belege (Status 1,2).
Belege:
- [PRIMÄR] CachedTableBL.ExecuteCacheUpdates (Z.98-110) / ExecuteUpdateCache (Z.188-245), Bedingung Update-Auswahl und Rollback-Handling - Begründung: durchgesetzte Cache-Steuerung
- [PRIMÄR] UpdateCacheSalesStatistic (Z.252, Z.1029), Bedingung rk.Status IN (1,2), commandTimeout 1800s - Begründung: durchgesetzter Statistik-Neuaufbau
Prüfidee: IsUpdating=true mit LastUpdated >10 min alt → erneuter Lauf; Fehler während Update → IsUpdating zurückgesetzt, keine Teildaten.
Tracelinks: StRS-26, StRS-30
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-26
Titel: CTime-Synchronisation nur bei Aktivierung
Ebene: SyRS
Typ: Betrieb
Qualitätsmerkmal:
Akteur: System (CTimeConnectorBL)
Vorbedingung: Zeitwirtschafts-Import konfiguriert
Fakt: CTimeConnectorBL (Z.116-166): nur bei IsSyncActive; Items ohne TimeTrackIn/Out oder EmployeeEmail übersprungen; Mapping 1→Urlaub, 2→Krankheit, 3→Überstunden.
Aussage: Das System soll CTime-Daten nur bei aktivierter Synchronisation importieren, unvollständige Posten (fehlende Zeitstempel oder E-Mail) überspringen und Abwesenheitstypen 1/2/3 auf Urlaub/Krankheit/Überstunden mappen.
Ergebnis: Ohne IsSyncActive kein Import; unvollständige Items erzeugen keine Teildaten.
Belege:
- [PRIMÄR] CTimeConnectorBL (Z.116-166), Bedingung IsSyncActive / Skip-Regeln / Mapping-Tabelle - Begründung: durchgesetzte Sync-Regeln
Prüfidee: IsSyncActive=false → kein Datentransfer; Item ohne EmployeeEmail → übersprungen; Typ 2 → Krankheit.
Tracelinks: StRS-24
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-27
Titel: Verzeichnisprüfung nur für Admin-Gruppen-Logins
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: System (DirectoryCheckBL)
Vorbedingung: Aufruf von ExecuteDirectoryCheck
Fakt: DirectoryCheckBL.ExecuteDirectoryCheck (Z.52-56): nur wenn currentUser.IsCentronUserLogin && IsUserInAdminGroup, sonst „Login does not have the rights to execute this method."
Aussage: Das System soll Verzeichnisprüfungen nur für Centron-Logins mit Admin-Gruppenmitgliedschaft ausführen und andere Aufrufe mit definierter Fehlermeldung ablehnen.
Ergebnis: Keine Verzeichnisprüfung durch Web-Konten oder Nicht-Admins.
Belege:
- [PRIMÄR] DirectoryCheckBL.ExecuteDirectoryCheck (Z.52-56), Bedingung IsCentronUserLogin && IsUserInAdminGroup - Begründung: durchgesetzte Rechtebedingung
Prüfidee: Nicht-Admin-Login ruft Methode → zitierte Fehlermeldung; Web-Konto → abgewiesen.
Tracelinks: StRS-2
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-28
Titel: Idempotente API-Telemetrie mit Deadlock-Wiederholung
Ebene: SyRS
Typ: Betrieb
Qualitätsmerkmal:
Akteur: System (TelemetryBL)
Vorbedingung: dbo.ApiCallTelemetry vorhanden
Fakt: TelemetryBL.UpsertApiCallBatch: MERGE dbo.ApiCallTelemetry WITH (HOLDLOCK), Match inkl. ISNULL(LicenseKind,-1); ExecuteWithDeadlockRetry (max 5 Versuche, SQL-Fehler 1205/2627/2601); InsertMissingNames: Unique-Verstoß 2627 wird verschluckt, I3D nachgelesen (idempotent).
Aussage: Das System soll API-Aufruf-Telemetrie per MERGE idempotent fortschreiben und Deadlock-/Unique-Verstöße (SQL 1205/2627/2601) bis zu 5-mal wiederholen bzw. nachlesen.
Ergebnis: Telemetrie geht bei Parallelität nicht verloren und doppelt sich nicht.
Belege:
- [PRIMÄR] TelemetryBL.UpsertApiCallBatch (MERGE WITH (HOLDLOCK), Match ISNULL(LicenseKind,-1)) + ExecuteWithDeadlockRetry (max 5, Fehler 1205/2627/2601) - Begründung: durchgesetzte Upsert-/Retry-Regeln
Prüfidee: Zwei parallele Batches mit identischem Schlüssel erzeugen genau einen Datensatz; simulierter Deadlock wird bis 5-mal wiederholt.
Tracelinks: StRS-29
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-29
Titel: Zentrale Mailkanalwahl und Graph-Kanal-Regeln
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System (Mailversand)
Vorbedingung: ApplicationSetting CentronWebserviceMailType gesetzt
Fakt: CentronMailFactory.GetMail (Z.29-53): Versandkanal aus ApplicationSetting CentronWebserviceMailType (Exchange/Graph/default SMTPMail); TestMails.IsEnabled schaltet auf TestMail; GraphServiceClientHelper.GetConfig (Z.94-109): GraphAppId/Tenant/Secret leer → InvalidConfiguration; GraphServiceClient mit ClientSecretCredential, Scope https://graph.microsoft.com/.default; GetUser: ohne Fallback-Adresse Fehler; GraphMail.GetAttachments (Z.279-320): Anhang <3 MB inline, 3-150 MB über Upload-Session, ≥150 MB übersprungen mit Warnlog.
Aussage: Das System soll den Mailversandkanal zentral per ApplicationSetting wählen (Testmodus über TestMails), den Graph-Kanal nur bei vollständiger Konfiguration (AppId/Tenant/Secret) starten und Anhänge nach Größenklassen behandeln (inline <3 MB, Upload-Session 3-150 MB, ≥150 MB überspringen mit Warnlog).
Ergebnis: Nur ein Kanal je Konfiguration; Graph ohne Konfiguration scheitert kontrolliert; Riesenanhänge blockieren den Versand nicht.
Belege:
- [PRIMÄR] CentronMailFactory.GetMail (Z.29-53), Bedingung CentronWebserviceMailType / TestMails.IsEnabled - Begründung: durchgesetzte Kanalwahl
- [PRIMÄR] GraphServiceClientHelper.GetConfig (Z.94-109), Bedingung leere Felder → InvalidConfiguration; GraphMail.GetAttachments (Z.279-320) Größenklassen - Begründung: durchgesetzte Graph-Regeln
Prüfidee: Leere Graph-AppId → InvalidConfiguration; 200-MB-Anhang → übersprungen mit Warnlog, Mail versendet Rest.
Tracelinks: StRS-17, StRS-24
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-30
Titel: SMTP-Versandregeln inkl. Empfängervalidierung
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: System (SMTPMail)
Vorbedingung: SMTP-Einstellungen vorhanden
Fakt: SMTPMail.CreateSmtpClient (Z.119-170): leerer SmtpHost → ResultException; EnableSsl = (Host == „smtp.office365.com" || settings.SmtpSslActive); Timeout Math.Max(15, settings.TimeOut)*1000; CreateMailMessage: ungültige TO/CC/BCC → Warning-Ausschluss, ungültiger Absender → AsError.
Aussage: Das System soll SMTP-Versand ohne Host ablehnen, SSL nur beim office365-Host oder bei expliziter Einstellung aktivieren, das Timeout auf mindestens 15 s setzen und ungültige Empfänger warnend auszuschließen, ungültige Absender aber als Fehler zu werten.
Ergebnis: Kein Versand ohne Host; Empfängerfehler degradieren, Absenderfehler brechen ab.
Belege:
- [PRIMÄR] SMTPMail.CreateSmtpClient (Z.119-170), Bedingung leerer SmtpHost → ResultException; EnableSsl-Formel; Timeout Math.Max(15, TimeOut)*1000 - Begründung: durchgesetzte SMTP-Regeln
Prüfidee: SmtpHost leer → ResultException; eine ungültige CC-Adresse → Warnung, Rest versendet; ungültiger Absender → Fehler.
Tracelinks: StRS-17
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-31
Titel: E-Mail-Domain-Blacklist und Kundenerkennung
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System (DomainBlacklistBL)
Vorbedingung: E-Mail-Adresse zur Kundensuche
Fakt: DomainBlacklistBL.IsBlacklisted (Z.15-35): Einträge mit @-Präfix exakt („@"+emailDomain), sonst Regex „[@.]domain"; keine @-Teile → AsError „Malformed E-Mail address"; durchgesetzt in ContactPersonBL.SearchAddressContactByEmailAddress nur wenn Setting IsCustomerDetectionOverEMailDomainActive && !blacklisted; Schema dbo.EMailDomainBlacklist (Z.39208): Domain varchar(256) NOT NULL, State NOT NULL.
Aussage: Das System soll E-Mail-Domänen gegen die Blacklist prüfen (Exaktvergleich bei @-Präfix-Einträgen, sonst Muster [@.]domain), fehlerhafte Adressen als Fehler werten und die Kundenerkennung über E-Mail-Domäne nur bei aktivem Setting und nicht gesperrter Domäne durchführen.
Ergebnis: Gesperrte Domänen führen nicht zur Kundenzuordnung; defekte Adressen werden als Fehler gemeldet.
Belege:
- [PRIMÄR] DomainBlacklistBL.IsBlacklisted (Z.15-35), Bedingung @-Präfix-Exaktvergleich vs. Regex - Begründung: durchgesetzte Blacklist-Logik
- [PRIMÄR] SSMS_DB_SCHEMA.sql Z.39208 (dbo.EMailDomainBlacklist, Domain varchar(256) NOT NULL) - Begründung: Schema der Blacklist
Prüfidee: Blacklist-Eintrag „@freemail.example" trifft nicht „user@sub.freemail.example", Eintrag „freemail.example" trifft Teilstring; Erkennung deaktiviert → keine Zuordnung.
Tracelinks: StRS-15
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-32
Titel: Ticket-Benachrichtigungen ohne Selbstbenachrichtigung
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (NexusNotificationsBL)
Vorbedingung: Ticketereignis (Kommentar/Mention/Forward)
Fakt: NexusNotificationsBL.SaveSimpleTicketNotifications (Z.206-211): Auslöser erhält keine eigene Benachrichtigung außer informAll; Mentions per Regex „\[(?<name>@[^\]]+):(?<id>\d+)\]" → Typ MentionedInComment; SaveForwardTicketNotifications: TicketAssigned/TicketUnassigned, Auslöser ausgeschlossen; NotificationsHubHelper.SendNexusNotification = statischer Delegat, Default No-op (Host registriert Push).
Aussage: Das System soll Ticket-Benachrichtigungen ohne Selbstbenachrichtigung des Auslösers (Ausnahme informAll), Mention-Benachrichtigungen per definierter Regex und Zuweisungs-/Entzugsmeldungen bei Forward erzeugen; ohne Host-Registrierung läuft der Push als No-op.
Ergebnis: Adressaten erhalten nur fremdveranlasste Ereignisse; Push-Transport ist austauschbar.
Belege:
- [PRIMÄR] NexusNotificationsBL.SaveSimpleTicketNotifications (Z.206-211) / SaveForwardTicketNotifications, Bedingung Auslöser-Ausschluss außer informAll - Begründung: durchgesetzte Adressatenregeln
Prüfidee: Kommentierer wird bei eigenem Kommentar nicht benachrichtigt; „[Name:123]" erzeugt MentionedInComment; Forward benachrichtigt neue/entfernte Zuweisungen ohne Auslöser.
Tracelinks: StRS-17, StRS-16
Konsolidierung: Kandidat: Auslöser-Ausschluss in SaveSimple- und SaveForward-Pfad doppelt implementiert
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-33
Titel: Automatische Bereinigung zentraler Benachrichtigungen
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (CentronNotificationsBL)
Vorbedingung: Notification-Einstellungen geladen
Fakt: CentronNotificationsBL.CleanupCentronNotifications (Z.53-68): Bereinigung nur bei settings.DeleteAutomatically; Löschfilter CreatedDate <= now - DeleteAfterDays; CreateFilterExpression: OnlyErrors → LogKind Error || PartlyError.
Aussage: Das System soll zentrale Benachrichtigungen nur bei aktivierter automatischer Löschung und nur älter als DeleteAfterDays bereinigen; der OnlyErrors-Filter beschränkt die Auswahl auf LogKind Error bzw. PartlyError.
Ergebnis: Ohne Schaltung keine Löschung; Altbestand ist konfigurierbar begrenzbar.
Belege:
- [PRIMÄR] CentronNotificationsBL.CleanupCentronNotifications (Z.53-68), Bedingung settings.DeleteAutomatically / DeleteAfterDays - Begründung: durchgesetzte Bereinigungsregeln
Prüfidee: DeleteAutomatically=false → Bestand bleibt; DeleteAfterDays=7 löscht nur Meldungen älter als 7 Tage; OnlyErrors erfasst ausschließlich Error/PartlyError.
Tracelinks: StRS-17
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-34
Titel: Volltextsuche mit Stemming und AND-Semantik
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System (IndexSearchBL)
Vorbedingung: Aufgebauter Suchindex
Fakt: IndexSearchBL.SearchIndexQueryable (Z.54-72): Stemming (AllowShortWords=true, AllowAlterations=false), Einzel-Queries StartsWith(stemmed), INNER JOIN über (ObjectI3D, Kind) → AND-Semantik; UpdateIndexForObject: fehlgeschlagene Objekte in statischem ConcurrentDictionary, künftig übersprungen; IndexBuilder/GermanAnalyzer: kurze Wörter ≤3 verworfen, Stopwörter nach Stemming.
Aussage: Das System soll die Volltextsuche über gestemmte Präfix-Queries mit AND-Semantik je Objekt (Join über ObjectI3D und Kind) ausführen, Wörter ≤3 Zeichen und Stopwörter verwerfen und dauerhaft fehlgeschlagene Indexobjekte überspringen.
Ergebnis: Mehrbegriffsabfragen liefern nur Objekte, die alle Begriffe treffen; Indexierung wird durch Einzelfehler nicht blockiert.
Belege:
- [PRIMÄR] IndexSearchBL.SearchIndexQueryable (Z.54-72), INNER JOIN über (ObjectI3D, Kind) → AND-Semantik - Begründung: durchgesetzte Suchsemantik
- [PRIMÄR] IndexBuilder/GermanAnalyzer (Wörter ≤3 verworfen, Stopwörter nach Stemming; ConcurrentDictionary für Fehlobjekte) - Begründung: durchgesetzte Indexregeln
Prüfidee: Suche „berlin kunde" liefert nur Objekte mit beiden (gestemmten) Begriffen; einmal fehlgeschlagenes Objekt wird bei Folgeindexierungen übersprungen.
Tracelinks: StRS-30
Konsolidierung: keine Dublette; dokumentierte Abdeckungslücke: die Volltextsuche hat keine fachliche Entsprechung auf StRS, der Link auf StRS-30 (Berichte) ist nur formaler Anker (siehe Analysebericht, bekannte Lücken).
Übernahmewürdigkeit: Sonderfall - stilles Überspringen fehlgeschlagener Objekte kann Indexlücken erzeugen; Reparaturpfad vorsehen
Status: belegt
ID: SyRS-35
Titel: Windows-Dienst-Lebenszyklus mit Startfehler-Stopp
Ebene: SyRS
Typ: Betrieb
Qualitätsmerkmal:
Akteur: System (CentronService, M105)
Vorbedingung: Dienst als Windows-Dienst installiert
Fakt: CentronService.OnStart (M105): Startfehler → Logger.Error + this.Stop(); OnStop → CentronHost.Instance.Stop().
Aussage: Das System soll als Windows-Dienst Startfehler protokollieren und sich selbst stoppen sowie bei Dienststopp den Host sauber herunterfahren.
Ergebnis: Fehlgeschlagene Starts sind im Log nachvollziehbar und hinterlassen keinen halben Zustand.
Belege:
- [PRIMÄR] CentronService.OnStart / OnStop (M105), Bedingung Startfehler → Logger.Error + this.Stop() - Begründung: durchgesetzte Lebenszyklusregeln
Prüfidee: Simulierter Startfehler → Fehlerlogeintrag und Dienststatus „Stopped"; Dienststopp beendet CentronHost.Instance.
Tracelinks: StRS-27, StRS-28
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-36
Titel: Konsolen- und Prüfwerkzeuge des Hosts
Ebene: SyRS
Typ: Betrieb
Qualitätsmerkmal:
Akteur: Bediener ↔ System (Host.Console, M104)
Vorbedingung: Konsole im Dienst-/Konfigurationsverzeichnis gestartet
Fakt: Host.Console Program.cs (M104): args []/start → CentronHost.Instance.Start(); Beendigung nur Kommando close/stop bzw. STRG+C; configure <port> <publicUrl> <connectionString> schreibt WebServiceConfigHelper (WebServiceAddress/PublicWebServiceAddress/DatabaseConnectionString); #if ALLOW_HARDWARE_ID_FROM_ENV_VARS → HardwareId aus Umgebungsvariable; SQLServerCheckToolViewModel.CanCheckSqlConnection: vollständig ausgefüllte Instance/DatabaseName/Username/Password erforderlich; SqlHelper.GetConnectionString: MultipleActiveResultSets=true, MaxPoolSize=500.
Aussage: Das System soll eine Konsole mit Start (args []/start), Beendigung (close/stop, STRG+C) und configure-Befehl (schreibt WebServiceAddress/PublicWebServiceAddress/DatabaseConnectionString) bereitstellen; der SQL-Verbindungstest läuft nur bei vollständigen Zugangsdaten, und generierte Verbindungsstrings aktivieren MARS mit MaxPoolSize=500.
Ergebnis: Konfiguration ist ohne manuelle XML-Pflege möglich; Verbindungstests scheitern kontrolliert bei unvollständigen Angaben.
Belege:
- [PRIMÄR] Host.Console Program.cs (M104), Befehle start/close/stop/configure und WebServiceConfigHelper-Schreibung - Begründung: durchgesetzte Konsolenbefehle
- [PRIMÄR] SQLServerCheckToolViewModel.CanCheckSqlConnection (Pflichtfelder) + SqlHelper.GetConnectionString (MultipleActiveResultSets=true, MaxPoolSize=500) - Begründung: durchgesetzte Prüf- und Verbindungsregeln
Prüfidee: configure schreibt die drei Werte in WebServiceConfig.xml; Verbindungstest mit leerem Password → abgewiesen; generierter String enthält MARS und MaxPoolSize=500.
Tracelinks: StRS-27
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-37
Titel: Versionsauskunft und Versionsschranke
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Client ↔ System (VersionBL, M088)
Vorbedingung: Webservice erreichbar
Fakt: VersionBL.GetWebserviceVersion (M088): nur Assembly-Version als Auskunft; Versionsobergrenze durchgesetzt in LicenseManager.CheckLicenseVersion (in CheckLicense, LicenseManager.cs Z.258-302).
Aussage: Das System soll die Webservice-Version ausschließlich als Assembly-Version auskunftsfähig halten und Betrieb oberhalb des lizenzierten Produktstands über CheckLicenseVersion verweigern.
Ergebnis: Versionsabfrage liefert keine Zusatzdaten; Versionsüberschreitung blockiert den Betrieb.
Belege:
- [PRIMÄR] LicenseManager.CheckLicenseVersion (in CheckLicense, LicenseManager.cs Z.258-302), Bedingung Version > lizenzierter Stand → Fehler - Begründung: durchgesetzte Versionsschranke
- [SEKUNDÄR] VersionBL.GetWebserviceVersion (M088), nur Assembly-Version - Begründung: Auskunftsumfang im Code
Prüfidee: GetWebserviceVersion liefert exakt die Assembly-Version; Webservice über lizenziertem Stand → Start-/Betriebsfehler.
Tracelinks: StRS-25, StRS-29
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-38
Titel: Bereitstellungsarten MSI, Docker und signierter Build
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Übertragbarkeit (Installierbarkeit/Portierbarkeit)
Akteur: System (Installer/Build/Deployment)
Vorbedingung: Build-/Release-Prozess ausgeführt
Fakt: WixSharpInstaller Program.cs: ServiceInstaller Name=CentronNexus, Start auto (Z.42-55); MajorUpgrade AllowSameVersionUpgrades (Z.27-31, MSI prüft 3 Versionsstellen); docker/compose/compose.yaml: Stack db (1433, MSSQL_SA_PASSWORD), webservice (4321→1234, HARDWARE_ID, mountet WebServiceConfig.xml), smtp (mailcatcher 1025/1080), nexus (8050, appsettings.Production.json), depends_on, restart on-failure; Dockerfile Multi-Stage alpine, ARG dx_license, TZ=Europe/Berlin, ICU+msttcorefonts; ACR centron.azurecr.io, ACR-Token je Kunde via scope-map; Centron.Scripts/Program.cs: DeleteSubDirectoriesOtherThan(PublishDir, „de", „en") nach jedem Build (Z.105-226), Targets build/build-installer (Z.290-292), SignHelper (Code Signing).
Aussage: Das System soll per MSI als Autostart-Dienst „CentronNexus" mit gleichversionierten Major-Upgrades sowie per Docker-Stack (db/webservice/smtp/nexus mit Neustart-Policy on-failure) bereitstellbar sein; Builds bereinigen Sprachverzeichnisse auf de/en und signieren Artefakte.
Ergebnis: Zwei gepflegte Bereitstellungswege; nur signierte, sprachbereinigte Artefakte werden ausgeliefert.
Belege:
- [SEKUNDÄR] WixSharpInstaller Program.cs (Z.42-55, Z.27-31) - Begründung: Installer-Konfiguration
- [SEKUNDÄR] compose.yaml/Dockerfile; Centron.Scripts/Program.cs (Z.105-226, Z.290-292) + SignHelper - Begründung: Deployment- und Build-Konfiguration
Prüfidee: MSI-Installation richtet Dienst CentronNexus mit Autostart ein; docker compose up bringt alle vier Dienste hoch; Build entfernt alle Sprachordner außer de/en.
Tracelinks: StRS-27, StRS-29
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-39
Titel: QS-Pipelines für Build, Regression, Playwright und Security
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit (Analysebarkeit/Testbarkeit)
Akteur: System (CI)
Vorbedingung: Push/PR bzw. cron-Auslösung
Fakt: Azure build-pipeline.yml: trigger master, release/*; IsDevBuild=PR; DownloadSecureFile Code-Signing-Zertifikat; regression-tests-pipeline.yml: DB-Container centron_db/regression_tests, sa/SA!password; azure-blazor: nexus-unit-tests.yaml (dotnet test-only via Scripts), playwright-pipeline.yml Matrix default|version2|views mit DB-Container je Variante; security-pipeline.yaml: cron 0 0 * * *, CodeQL (csharp,javascript) + Dependency-Scanning; .github tests.yml (workflow_dispatch + PR/Push main/release/**, cancel-in-progress nur PR); build.yml mit sign-artifacts-Composite-Action.
Aussage: Das System soll seine Qualitätssicherung als Pipelines ausführen: Builds mit Zertifikatsdownload und Signierung, Regressionstests gegen DB-Container, Playwright-Matrix (default|version2|views), tägliche CodeQL-/Abhängigkeitsscans (cron 0 0 * * *) und GitHub-Workflows mit PR-abbruchendem cancel-in-progress.
Ergebnis: Jeder Push/PR durchläuft definierte Tests- und Sicherheitsgates; Scans laufen täglich.
Belege:
- [SEKUNDÄR] Azure build-pipeline.yml / regression-tests-pipeline.yml / security-pipeline.yaml / playwright-pipeline.yml - Begründung: Pipeline-Konfiguration
- [SEKUNDÄR] .github tests.yml / build.yml (sign-artifacts-Composite-Action) - Begründung: Workflow-Konfiguration
Prüfidee: PR löst tests.yml mit cancel-in-progress aus; security-pipeline.yaml läuft zum cron-Termin mit CodeQL csharp+javascript; Playwright-Varianten laufen je mit eigenem DB-Container.
Tracelinks: StRS-29
Konsolidierung: Kandidat: DB-Container-Bereitstellung in regression- und playwright-Pipelines doppelt definiert
Übernahmewürdigkeit: übernehmen
Status: belegt
ID: SyRS-40
Titel: Betriebsdokumentationsstruktur
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit (Dokumentation/Analysebarkeit)
Akteur: System (Dokumentation)
Vorbedingung: Repository mit docs/
Fakt: docs/README.md: Gliederung getting-started/guides/reference/operations.
Aussage: Das System soll seine Betriebsdokumentation mit den festen Bereichen getting-started, guides, reference und operations führen.
Ergebnis: Einstieg, Anleitungen, Referenz und Betrieb sind dokumentarisch getrennt auffindbar.
Belege:
- [SEKUNDÄR] docs/README.md (Gliederung getting-started/guides/reference/operations) - Begründung: Doku-Struktur im Repository
Prüfidee: docs/README.md enthält alle vier Abschnitte mit verlinkten Unterseiten.
Tracelinks: StRS-29
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/Traceability.md
+207
View File
@@ -0,0 +1,207 @@
# Traceability
Konsolidierte Trace-Tabelle. Spalten: SwRS-ID | SyRS-ID | StRS-ID | Hauptbeleg (Modul: Stelle). Tracelinks im Detail stehen in den Anforderungsdateien; hier die Zusammenführung.
## SwRS-Anforderungen (SwRS-1 - SwRS-146)
| SwRS | SyRS | StRS | Beleg (Kurzform) |
|---|---|---|---|
| SwRS-1 | SyRS-1 | StRS-2, StRS-9, StRS-19 | M001 BankAccountBL.Save/Delete/Get |
| SwRS-2 | SyRS-21 | StRS-11 | M019 BookKeepingExportBL/ImportBL |
| SwRS-3 | SyRS-23 | StRS-9 | M019 PaymentTransactionBL.RefreshBankInformation |
| SwRS-4 | SyRS-11, SyRS-22 | StRS-8 | M029 PaymentsBL.DeleteIncomingPayment |
| SwRS-5 | SyRS-22, SyRS-23 | StRS-8, StRS-12 | M029 OnlineBankingAccountTransactionsBL |
| SwRS-6 | SyRS-23 | StRS-3, StRS-8 | M029 OnlineBankingConfigurationBL |
| SwRS-7 | SyRS-22, SyRS-11 | StRS-7 | M060 ReceiptBL.UpdateReceiptIsPaid |
| SwRS-8 | SyRS-11, SyRS-21 | StRS-2, StRS-7, StRS-11 | M060 ReceiptInvoiceBL.CancelInvoice |
| SwRS-9 | SyRS-23 | StRS-7 | M060 FixInvoice; RechKopf.IsFixed |
| SwRS-10 | SyRS-23 | StRS-8 | M060 CashBookBookingBL |
| SwRS-11 | SyRS-23 | StRS-12 | M083 GetActivedVoucherBarcodes |
| SwRS-12 | SyRS-22 | StRS-10 | M110 DunningStopViewModel |
| SwRS-13 | SyRS-14 | StRS-11 | M114 ExportData |
| SwRS-14 | SyRS-22 | StRS-8 | M119 CheckNewAssignedAmount |
| SwRS-15 | SyRS-23 | StRS-16 | M013 CentronChecklistBL/UpdateChecklistBL |
| SwRS-16 | SyRS-25 | StRS-19 | M035 ChecklistVirtualObjectCategoryBL |
| SwRS-17 | SyRS-17, SyRS-18 | StRS-15, StRS-6 | M062 SelfCareBL |
| SwRS-18 | SyRS-2, SyRS-11 | StRS-17 | M071 TaskManagementHelpdeskActionHandler |
| SwRS-19 | SyRS-23 | StRS-20, StRS-16 | M074 TicketProjectBL |
| SwRS-20 | SyRS-18 | StRS-6 | M087 WebHDQuestionBL/WebSettingBL |
| SwRS-21 | SyRS-9 | StRS-16 | M113 CloseHelpdeskHelper |
| SwRS-22 | SyRS-11, SyRS-8 | StRS-2, StRS-16 | M113 TicketLogicHelper/TicketListViewModel |
| SwRS-23 | SyRS-23 | StRS-18 | M124 NewRma/CheckForthState |
| SwRS-24 | SyRS-1, SyRS-23 | StRS-2, StRS-19 | M002 AccountBL |
| SwRS-25 | SyRS-23 | StRS-21 | M006 SearchSupplierBL |
| SwRS-26 | SyRS-23 | StRS-22 | M015 CountryBL |
| SwRS-27 | SyRS-23 | StRS-18, StRS-19 | M017 RmaBL/InterestBL/ContactActivityBL |
| SwRS-28 | SyRS-23 | StRS-19 | M020 AccountDeviceBL |
| SwRS-29 | SyRS-23 | StRS-24 | M028 ExternalToolBL |
| SwRS-30 | SyRS-23 | StRS-20 | M048 ObjectExternalReferenceBL |
| SwRS-31 | SyRS-23 | StRS-15 | M064 SocialMediaBL |
| SwRS-32 | SyRS-23 | - | M069 TagsBL |
| SwRS-33 | SyRS-23 | StRS-20 | M073 TextModuleBL |
| SwRS-34 | SyRS-23 | StRS-6 | M081 SimpleUrlBL |
| SwRS-35 | SyRS-18, SyRS-23 | StRS-15, StRS-6 | M085 WebLinkBL |
| SwRS-36 | SyRS-23 | StRS-21 | M007 DistributorBL |
| SwRS-37 | SyRS-15 | StRS-21, StRS-24 | M023 EDIDispatcherBL/Alltron/Also |
| SwRS-38 | SyRS-23 | StRS-23 | M036 StockBL |
| SwRS-39 | SyRS-2 | StRS-25 | M053 ProductionBL |
| SwRS-40 | SyRS-23 | StRS-22 | M054 ProductMatrixBL |
| SwRS-41 | SyRS-23 | StRS-21 | M056 OrderSuggestionListBL |
| SwRS-42 | SyRS-35 | StRS-23 | M067 StorageBL (veraltet) |
| SwRS-43 | SyRS-23 | StRS-22 | M084 ArticleStockBL |
| SwRS-44 | SyRS-28 | StRS-23 | M084 ArticleLogBL.WriteAmountChangeLog |
| SwRS-45 | SyRS-14 | StRS-8, StRS-24 | M092 Libfintx |
| SwRS-46 | SyRS-9 | StRS-22 | M111 AddActionPriceViewModel/PositionViewModel |
| SwRS-47 | SyRS-23 | StRS-21 | M117 SuggestionQuantity/EDIInvoiceViewModel |
| SwRS-48 | SyRS-23 | StRS-13, StRS-22 | M123 SpecialArticleImportSettings |
| SwRS-49 | SyRS-1, SyRS-27 | StRS-2 | M003 AppRightsBL |
| SwRS-50 | SyRS-2, SyRS-3 | StRS-1, StRS-25 | M003 Authenticator/LicenseManager |
| SwRS-51 | SyRS-6 | StRS-1 | M003 UsersBL/BasicAuthenticator |
| SwRS-52 | SyRS-5 | StRS-1 | M003 TwoFactorAuthBL |
| SwRS-53 | SyRS-19 | StRS-4, StRS-3 | M005 AiApiLinkValidator |
| SwRS-54 | SyRS-23, SyRS-35 | - | M042 ModuleBL |
| SwRS-55 | SyRS-2, SyRS-11 | StRS-5, StRS-3 | M050/M051 Passwort-Management/Manager |
| SwRS-56 | SyRS-1 | StRS-14 | M061 PdfSigningBL |
| SwRS-57 | SyRS-5 | StRS-1 | M080 TwoFactorAuthenticationBL |
| SwRS-58 | SyRS-37 | StRS-27 | M088 VersionBL |
| SwRS-59 | SyRS-1, SyRS-2 | StRS-4 | M112 MandatorManagement/SqlManager [HYP] |
| SwRS-60 | SyRS-14, SyRS-11 | StRS-4 | M120 ArtificialIntelligenceChatCoordinator |
| SwRS-61 | SyRS-23 | StRS-3, StRS-5 | M024 EmployeeRfidTokenBL |
| SwRS-62 | SyRS-35 | - | M024 EmployeeHolidayBL (veraltet) |
| SwRS-63 | SyRS-23 | StRS-21, StRS-22 | M030 CustomGatewayBL |
| SwRS-64 | SyRS-1, SyRS-23 | StRS-2 | M031 UiProfileBL |
| SwRS-65 | SyRS-23 | StRS-19 | M034 EsCustomerGroupBL/EsRoleBL |
| SwRS-66 | SyRS-23 | StRS-13, StRS-22 | M040 MassUpdateBL |
| SwRS-67 | SyRS-23 | - | M043 QuickNoteBL |
| SwRS-68 | SyRS-32 | - | M044 MyDayBL/MyDayNotificationsBL |
| SwRS-69 | SyRS-6, SyRS-8 | StRS-24 | M059 RiverDivoBL/RiverConnectionBL |
| SwRS-70 | SyRS-24 | StRS-15 | M059 RiverConnectionBL (fremder Kunde) |
| SwRS-71 | SyRS-23 | - | M075 TimingSettings (Schema) |
| SwRS-72 | SyRS-11 | StRS-2 | M076 ToDoBL.UpdateTodoDiscardedFlag |
| SwRS-73 | SyRS-23 | StRS-7 | M076 HandleReceiptToDoEntries |
| SwRS-74 | SyRS-23 | - | M077 ToolBL.ChangeTextFormat |
| SwRS-75 | SyRS-23 | StRS-21 | M078 TradePoolXmlLogic |
| SwRS-76 | SyRS-6 | StRS-1 | M078 TradePoolBL.AuthenticateUser |
| SwRS-77 | SyRS-23 | - | M079 TransactionBL |
| SwRS-78 | SyRS-1, SyRS-2 | StRS-25 | M115 ModuleRegistration/TodoListViewModel |
| SwRS-79 | SyRS-1, SyRS-2 | StRS-25, StRS-2 | M116 ManagementInfoViewModel/Registrierung |
| SwRS-80 | SyRS-2 | StRS-25 | M118 MSPComparer/CustomPropertiesConnector |
| SwRS-81 | SyRS-1, SyRS-10 | StRS-1 | M086 AccessTokenWebServiceBL |
| SwRS-82 | SyRS-2 | StRS-25 | M086 TicketWebServiceBL |
| SwRS-83 | SyRS-15, SyRS-19 | - | M102 CentronWebService |
| SwRS-84 | SyRS-8, SyRS-9, SyRS-11 | - | M103 TicketAuthenticationHandler/Interceptors |
| SwRS-85 | SyRS-12, SyRS-13, SyRS-14, SyRS-16, SyRS-2 | - | M103 CentronHost.Start/SecretKeyHandler |
| SwRS-86 | SyRS-35, SyRS-38 | - | M104/M105 Host.Console/CentronService |
| SwRS-87 | SyRS-10, SyRS-1 | StRS-2 | M106 UserRightAuthorizationFilter |
| SwRS-88 | SyRS-19 | - | M107 SQLServerCheckTool/SqlHelper |
| SwRS-89 | SyRS-17, SyRS-15 | StRS-6 | M010/M041 CentronNexusBL/MobileBL |
| SwRS-90 | SyRS-32, SyRS-16 | StRS-17 | M045 NexusNotificationsBL |
| SwRS-91 | SyRS-18 | StRS-15 | M046 NexusTicketViewBL |
| SwRS-92 | SyRS-33 | StRS-17 | M047 CentronNotificationsBL/UserNotificationBL |
| SwRS-93 | SyRS-19 | - | M049 OutlookAssetKindSearchBL (Bug) |
| SwRS-94 | SyRS-18 | StRS-6 | M125 AuthController |
| SwRS-95 | SyRS-18 | StRS-15 | M125 DocumentSigningPage.razor |
| SwRS-96 | SyRS-18, SyRS-1 | StRS-15 | M125 PublicWebFormPage/CurrentCartService |
| SwRS-97 | SyRS-17, SyRS-18 | StRS-6 | M126 Program.cs/PortAuthorization |
| SwRS-98 | SyRS-19 | - | M127 DocumentsTab.razor |
| SwRS-99 | - | StRS-11 | M094 EbInterfaceLogic |
| SwRS-100 | - | StRS-24 | M095 CentronGlsLogic |
| SwRS-101 | - | StRS-24 | M096 CentronShipcloudLogic |
| SwRS-102 | - | StRS-24 | M097 CopApi |
| SwRS-103 | - | StRS-24 | M098 EgisApi |
| SwRS-104 | - | StRS-8, StRS-24 | M099 FinAPI-RestClient |
| SwRS-105 | - | StRS-24 | M100/M101 Icecat/ITscope |
| SwRS-106 | - | StRS-24, StRS-1 | M140 docuFORM-OAuthHelper |
| SwRS-107 | SyRS-1 | StRS-2 | M031 UiProfileBL (global/privat) |
| SwRS-108 | - | StRS-7 | M040 MassUpdateBL (Ausschlüsse) |
| SwRS-109 | SyRS-2, SyRS-1 | StRS-25 | M108 ModuleRegistration (Engine) |
| SwRS-110 | SyRS-19, SyRS-1 | - | M108 ModuleListContainer/FrontWindow |
| SwRS-111 | SyRS-2, SyRS-1 | StRS-25 | M115 Dashboard-Registrierung |
| SwRS-112 | SyRS-2, SyRS-1 | StRS-25 | M116/M118 Statistik-/MSP-Registrierung |
| SwRS-113 | SyRS-2, SyRS-1 | StRS-25 | M121/M122 Survey/MassUpdates |
| SwRS-114 | SyRS-15 | StRS-1, StRS-3 | M128 GoogleAuthenticatorViewModel |
| SwRS-115 | - | StRS-1 | M130 Totp/CentronBindableBase |
| SwRS-116 | SyRS-29, SyRS-23 | StRS-15 | M004 AppointmentRequestBL |
| SwRS-117 | SyRS-29 | StRS-28 | M008 CalendarBL (Defekt) |
| SwRS-118 | SyRS-23 | StRS-28 | M009 CentronIconsBL (Defekt) |
| SwRS-119 | SyRS-21 | - | M011 ImportHistoryBL/BaseBL |
| SwRS-120 | SyRS-1, SyRS-20 | StRS-2 | M012 ChatBL |
| SwRS-121 | SyRS-35 | StRS-3, StRS-5, StRS-15, StRS-24 | M016 CPraConfiguration/Connector |
| SwRS-122 | SyRS-23 | StRS-20 | M018 CustomTableBL + M014 ReplacementBL |
| SwRS-123 | SyRS-23 | StRS-19 | M021 AssetManagementArticleAssignmentBL |
| SwRS-124 | SyRS-1, SyRS-21 | StRS-2 | M022 DocumentationBL |
| SwRS-125 | SyRS-32 | StRS-16 | M025 TicketExpiredException |
| SwRS-126 | SyRS-21, SyRS-23 | - | M026 ExpectedEventsBL |
| SwRS-127 | SyRS-23 | StRS-15 | M027 ExternalHelpdeskConfigurationBL |
| SwRS-128 | SyRS-1 | StRS-2, StRS-6 | M027 Rechteprüfung [HYP] |
| SwRS-129 | SyRS-29 | StRS-24, StRS-28 | M032 GraphServiceClientHelper |
| SwRS-130 | SyRS-34 | StRS-6, StRS-28 | M033 IndexSearchBL |
| SwRS-131 | SyRS-29, SyRS-30 | - | M037 MailSignatureBL |
| SwRS-132 | SyRS-23 | StRS-28 | M038 MailingDataBL (Defekt) |
| SwRS-133 | SyRS-1, SyRS-29 | StRS-2, StRS-3, StRS-5 | M039 MailScannerBL |
| SwRS-134 | SyRS-23 | - | M052 ProcessBL |
| SwRS-135 | SyRS-23 | - | M055 ProjectBL |
| SwRS-136 | SyRS-23 | StRS-30 | M057 ReportDataQueryBL |
| SwRS-137 | SyRS-20 | StRS-30 | M057 ReportDataBL.ExecuteQuery |
| SwRS-138 | SyRS-20 | StRS-30 | M058 ReportsBL.GetRawSqlResult |
| SwRS-139 | SyRS-1, SyRS-23 | StRS-2 | M082 VideoPortalAssignmentBL |
| SwRS-140 | SyRS-23 | StRS-1, StRS-3, StRS-5 | M014 CryptoUtils |
| SwRS-141 | SyRS-29, SyRS-30 | StRS-24, StRS-28 | M089 DeveloperSecurity.Email |
| SwRS-142 | SyRS-1 | StRS-1, StRS-2 | M089 ModuleFeatures |
| SwRS-143 | SyRS-1 | StRS-2 | M066 EmployeeUtilizationBL |
| SwRS-144 | SyRS-35 | - | M065 StartBL (Stubs) |
| SwRS-145 | SyRS-24 | - | M068 SystemTableI3DBL |
| SwRS-146 | SyRS-23 | StRS-28 | M070 PhoneCallBL |
Anmerkungen zur Tabelle:
- Ebenensprung direkt auf StRS (keine eigene SyRS-Verankerung, fachlich projektlokal und über StRS-24 bzw. StRS-14 vermittelt): SwRS-99, SwRS-100, SwRS-101, SwRS-102, SwRS-103, SwRS-104, SwRS-105, SwRS-106, SwRS-108. Begründung und Abdeckungsbewertung: Analysebericht.md (bekannte Lücken).
- Belegnotiz in der SwRS-93-Zeile verweist auf den dokumentierten Alias-Befund (M049).
## SyRS-Anforderungen (SyRS-1 - SyRS-40) zu StRS
| SyRS | StRS |
|---|---|
| SyRS-1 | StRS-2 |
| SyRS-2 | StRS-1, StRS-25 |
| SyRS-3 | StRS-1, StRS-25 |
| SyRS-4 | StRS-1, StRS-2 |
| SyRS-5 | StRS-1 |
| SyRS-6 | StRS-1, StRS-3 |
| SyRS-7 | StRS-6, StRS-15 |
| SyRS-8 | StRS-1 |
| SyRS-9 | StRS-1, StRS-2 |
| SyRS-10 | StRS-2 |
| SyRS-11 | StRS-2, StRS-1 |
| SyRS-12 | StRS-6, StRS-25 |
| SyRS-13 | StRS-6 |
| SyRS-14 | StRS-24 |
| SyRS-15 | StRS-24, StRS-6 |
| SyRS-16 | StRS-24, StRS-17 |
| SyRS-17 | StRS-6 |
| SyRS-18 | StRS-6, StRS-15 |
| SyRS-19 | StRS-24, StRS-1 |
| SyRS-20 | StRS-28 |
| SyRS-21 | StRS-7 |
| SyRS-22 | StRS-7 |
| SyRS-23 | StRS-20, StRS-19 |
| SyRS-24 | StRS-20 |
| SyRS-25 | StRS-26, StRS-30 |
| SyRS-26 | StRS-24 |
| SyRS-27 | StRS-2 |
| SyRS-28 | StRS-29 |
| SyRS-29 | StRS-17, StRS-24 |
| SyRS-30 | StRS-17 |
| SyRS-31 | StRS-15 |
| SyRS-32 | StRS-17, StRS-16 |
| SyRS-33 | StRS-17 |
| SyRS-34 | StRS-30 (nur formaler Anker, fachliche Entsprechung fehlt - dokumentierte Lücke) |
| SyRS-35 | StRS-27, StRS-28 |
| SyRS-36 | StRS-27 |
| SyRS-37 | StRS-25, StRS-29 |
| SyRS-38 | StRS-27, StRS-29 |
| SyRS-39 | StRS-29 |
| SyRS-40 | StRS-29 |
## StRS-Ebene
StRS-1 bis StRS-30 sind die Wurzelebene; nachgelagerte Verlinkung siehe obige Tabellen.
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/OpenCode.log
View File
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/OpenCodeEvents.jsonl
+203
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Protokoll.md
+128
View File
@@ -0,0 +1,128 @@
# Messprotokoll – Iteration 9/z-ai/glm-5.3-flash/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-02T10:42:42.6471885+02:00
- **Endzeit:** 2026-09-02T12:51:54.2454720+02:00
- **Dauer gesamt:** 02:09:08 (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 9/z-ai/glm-5.3-flash/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` = 30, `completed` = 30, `failed` = 0
- **Rollen:** {"modulinventar": 1, "faktenermittler": 13, "strs-autor": 3, "syrs-autor": 2, "swrs-autor": 8, "belegpruefer": 1, "iso29148-orchestrator": 1, "konsistenzpruefer": 1}
## Validierungsstichprobe
- **Stand:** entfaellt
## Verbrauch
| Messgroesse | Wert |
|---|---|
| Input-Tokens | 7.648.623 |
| Output-Tokens | 203.967 |
| Reasoning-Tokens | 69.486 |
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
| Agent-Turns | 45 |
**Tokens gesamt: 11.467.996.** 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 | 30 | 13,9 % |
| SyRS | 40 | 18,5 % |
| SwRS | 146 | 67,6 % |
| **Gesamt** | **216** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 83 | 38,4 % |
| Sicherheit | 55 | 25,5 % |
| Daten | 43 | 19,9 % |
| Schnittstelle | 18 | 8,3 % |
| nicht-funktional | 11 | 5,1 % |
| Betrieb | 6 | 2,8 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 422 |
| davon `PRIMÄR` | 302 (71,6 %) |
| davon `SEKUNDÄR` | 98 (23,2 %) |
| davon `KONTEXT` | 22 (5,2 %) |
| Belege je Anforderung (Median) | 2,0 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 198 (91,7 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 159 | 73,6 % |
| workaround | 41 | 19,0 % |
| sonderfall | 14 | 6,5 % |
| veraltet | 2 | 0,9 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 212 | 98,1 % |
| als `HYPOTHESE` gekennzeichnet | 4 | 1,9 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 66 | 30,6 % |
| mit ISO-25010-Qualitätsmerkmal | 42 | 19,4 % |
### 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** – 2 von 80 ungedeckt: SwRS-127, SwRS-135 |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 216 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 216 von 216 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
- **Session-ID:** `ses_f9eb70d9bffeU6O643v8e3i1th`
- **Werkzeugaufrufe:** 81 – {"read": 4, "bash": 19, "task": 30, "write": 10, "grep": 2, "edit": 16}
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 30
- **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_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/RawResult.json
+1066
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Stderr.log
+5
View File
@@ -0,0 +1,5 @@
[2026-09-02T08:42:44.122853+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\Ergebnisse)
[2026-09-02T08:42:44.241827+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=custom; Effort=high (uebergeben=True); Stall-Timeout=0s
[2026-09-02T10:51:52.441929+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
[2026-09-02T10:51:54.138218+00:00] OpenCode export: Exporting session: ses_f9eb70d9bffeU6O643v8e3i1th
[2026-09-02T10:51:54.222501+00:00] Ende: Exitcode=0; Status=success; Turns=45; Tokens=11467996; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\RawResult.json
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/after.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/anforderungen.json
+4312
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/anforderungen.md
+66
View File
@@ -0,0 +1,66 @@
## Gefundene Anforderungen
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
### Verteilung über die Ebenen
| Ebene | Anzahl | Anteil |
|---|---:|---:|
| StRS | 30 | 13,9 % |
| SyRS | 40 | 18,5 % |
| SwRS | 146 | 67,6 % |
| **Gesamt** | **216** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 83 | 38,4 % |
| Sicherheit | 55 | 25,5 % |
| Daten | 43 | 19,9 % |
| Schnittstelle | 18 | 8,3 % |
| nicht-funktional | 11 | 5,1 % |
| Betrieb | 6 | 2,8 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 422 |
| davon `PRIMÄR` | 302 (71,6 %) |
| davon `SEKUNDÄR` | 98 (23,2 %) |
| davon `KONTEXT` | 22 (5,2 %) |
| Belege je Anforderung (Median) | 2,0 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 198 (91,7 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 159 | 73,6 % |
| workaround | 41 | 19,0 % |
| sonderfall | 14 | 6,5 % |
| veraltet | 2 | 0,9 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 212 | 98,1 % |
| als `HYPOTHESE` gekennzeichnet | 4 | 1,9 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 66 | 30,6 % |
| mit ISO-25010-Qualitätsmerkmal | 42 | 19,4 % |
### 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** – 2 von 80 ungedeckt: SwRS-127, SwRS-135 |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 216 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 216 von 216 mit Tracelinks (100,0 %) |
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/before.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/combined_prompt.md
+218
View File
@@ -0,0 +1,218 @@
# Versuch 02 - Agentengestuetzt - Prompt-Version 03-A
## Metadaten
- **Versuch:** V2 Agentengestützt (rollenspezialisierte Agentendateien)
- **Prompt-Version:** 03-A (Prompt-Version 03 aus Versuch 01, angepasst an verteilte Bearbeitung)
- **Basis:** `Versuche/Versuch_01/03_Prompt.md`, SHA-256 `B8C8764F…C030F07`
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-31
- **Vorgänger:** `01_Prompt.md` (Prompt-Version 02-A, SHA-256 `DCDC0E3F…B71BCF`), **kein Lauf durchgeführt**
- **Änderungsgrund gegenüber `01_Prompt.md`:** Version 02-A leitete sich von Prompt-Version **02** ab. Versuch 1 ist inzwischen auf Prompt-Version **03** weitergelaufen (Iteration 8 und 9). Ein V2-Lauf gegen 02-A würde sich von den Vergleichsläufen in **zwei** Größen unterscheiden — Agentenrollen *und* Prompt-Version — und wäre als Wirkungsnachweis der Rollen unbrauchbar. Version 03-A setzt deshalb auf Prompt-Version 03 auf.
| Änderung gegenüber `Versuch_01/03_Prompt.md` | Grund |
|---|---|
| Neuer Abschnitt „Arbeitsteilung" | Prompt-Version 03 unterstellt stillschweigend **einen** Bearbeiter: Sie ordnet die Schritte zeitlich, vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck über das Ergebnis. Bei verteilter Bearbeitung ist nichts davon von selbst erfüllt — IDs kollidieren, die Reihenfolge läuft rollenweise auseinander, und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen. |
| In der Arbeitsteilung: Ergebnisstruktur gilt unabhängig von der Aufteilung | Die 7-Datei-Regel aus Version 03 entstand an einem `solo`-Lauf (Kimi legte `SwRS-Ergaenzungen.md` an, 18 Anforderungen fielen aus der Auswertung). Bei verteilter Bearbeitung ist eine Datei je Bearbeiter der nächstliegende Fehler — die Regel wird dort ausdrücklich wiederholt. |
| In der Arbeitsteilung: **Zuständigkeitsbindung** — eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, wird von ihm ausgeführt | V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Der Smoke-Test vom 26.08. zeigte, dass von acht beigestellten Rollen nur zwei genutzt wurden — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist **statisch** deklariert und gehasht und damit eine reproduzierbare Bedingung; sie ist nicht mit den laufzeitabhängigen Adapterinjektionen aus Iteration 8 zu verwechseln, die Lauf 34 unpoolbar machten. |
| In der Arbeitsteilung: frei bleiben Zuschnitt, Anzahl, Reihenfolge und Tiefe | Gebunden wird **wer** eine Teilaufgabe ausführt, nicht **wie viel** davon getan wird. Zerlegungstiefe und Aufrufzahl bleiben Untersuchungsgegenstand wie in V1b. |
| In der Arbeitsteilung: Dokumentationspflicht zur tatsächlichen Beauftragung | Die Bindung wirkt auf Promptebene und ist damit nicht technisch erzwungen, sondern selbst eine Messgröße. Nur wenn im Lauf festgehalten ist, wer was ausgeführt hat, ist die Einhaltung gegen `subagent_stats` und die Subagenten-Prompts prüfbar. |
| Angehängte Tabellenzeilen und Schlussblockquote aus `03_Prompt.md` an ihren Platz gerückt | In `03_Prompt.md` stehen zwei Zeilen der Änderungstabelle **nach** dem Abschnitt „Abschluss" und die Tabelle im Metadatenblock ist leer. Da der Skill die **gesamte** Datei sendet (`_meta/combined_prompt.md`), gingen beide Fehlstellen in jeden Lauf der Iterationen 8 und 9 mit ein. |
**Der Prompt nennt keine Rolle namentlich.** Er formuliert die Bindung abstrakt; welche Rollen es gibt und wofür sie zuständig sind, stellt der Versuchsaufbau im Block Werkzeugkontext bei. Damit bleibt dieselbe Prompt-Datei auch für einen `solo`-Lauf ohne Rollen gültig — der fachliche Auftrag ist über V1, V2 und V3 identisch, und die Rollenbindung bleibt die einzige unabhängige Variable. Anzahl der Aufrufe, Zerlegungstiefe und Turn-Anzahl werden weiterhin **nicht** vorgegeben; sie bleiben Teil der Untersuchung.
Unverändert gegenüber Prompt-Version 03 bleiben: Auftrag, Scope, Vorgehensschritte 0 bis 6, Pflicht-Eigenschaften, Blockformat, Belegklassifikation, Prüfidee, Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur, Randbedingungen und Abschluss. Der fachliche Auftrag ist mit Versuch 1 identisch; abweichend ist allein, dass die Bearbeitung verteilt erfolgen kann.
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge und Agentenrollen im jeweiligen Lauf
> zur Verfügung stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau
> beim Start bei.
---
## Prompt
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
### Auftrag
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
### Vorgehen (statische Analyse, keine Ausführung)
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **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.
### Arbeitsteilung
Die Bearbeitung wird auf mehrere Bearbeiter verteilt. **Stellt der Versuchsaufbau für eine Teilaufgabe einen dafür vorgesehenen Bearbeiter bereit, ist diese Teilaufgabe von ihm auszuführen** — nicht von dir selbst und nicht von einem anderen. Welche Bearbeiter bereitstehen und wofür sie zuständig sind, nennt der Versuchsaufbau; diese Zuständigkeit ist Teil der Aufgabenstellung und keine Empfehlung. Stellt der Versuchsaufbau keine Bearbeiter bereit, bearbeitest du alles selbst und dieser Abschnitt ist ohne Wirkung.
- **Frei bleibt, wie du die Bearbeiter einsetzt.** Den Zuschnitt der Ausschnitte, die Anzahl der Aufträge je Bearbeiter, ihre Reihenfolge, die Tiefe und ob du nachfasst, entscheidest du. Gebunden ist allein, **wer** eine Teilaufgabe ausführt. Teilaufgaben, für die kein Bearbeiter vorgesehen ist — insbesondere der Zuschnitt, die Beauftragung, das Anlegen der Ergebnisdateien und die Übernahme der zurückgemeldeten Befunde —, führst du selbst aus.
- **Zuständigkeit vor Bearbeitung klären.** Lege fest, wer welchen Ausschnitt bearbeitet, bevor die erste Anforderung entsteht. Ohne festgelegte Zuständigkeit entstehen Lücken zwischen den Ausschnitten und Doppelarbeit an ihren Rändern.
- **ID-Bereiche vorab vergeben, überschneidungsfrei und lückenlos.** Jeder Bearbeiter erhält einen eigenen Nummernbereich je Ebene. Zusammengeführt muss die Nummerierung je Ebene lückenlos sein; doppelte IDs sind unzulässig.
- **Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Bearbeiter.** Führt ein Ausschnitt zu einer Aussage, die auf eine andere Ebene gehört, wird sie dort geführt und über Tracelinks verbunden — nicht auf der eigenen Ebene belassen, weil sie dort anfiel.
- **Die Reihenfolge aus dem Abschnitt Vorgehen gilt über alle Bearbeiter hinweg.** Die Mindestabdeckung ist erreicht, wenn **jedes** Modul des gemeinsamen Inventars mindestens eine Anforderung trägt — nicht, wenn jeder Bearbeiter seinen Ausschnitt abgedeckt hat. Erst danach beginnt die Vertiefung.
- **Der Konsistenzcheck gilt dem zusammengeführten Ergebnis.** Eine Prüfung des eigenen Beitrags ersetzt ihn nicht. Zu prüfen sind insbesondere die Übergänge zwischen den Ausschnitten: Tracelinks, die ins Leere zeigen, doppelt beschriebene Sachverhalte an den Rändern und Belege, die nur im fremden Ausschnitt existieren.
- **Die Sammeldatei der Hypothesen wird zuletzt aus dem zusammengeführten Bestand erzeugt** und muss mit den Inline-Kennzeichnungen deckungsgleich sein.
- **Die Ergebnisstruktur ist von der Arbeitsteilung unabhängig.** Es entstehen genau die sieben vorgegebenen Dateien — keine Datei und kein Abschnitt je Bearbeiter.
**Dokumentationspflicht.** Halte im `Analysebericht.md` fest, welchen Bearbeiter du für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt hast. Hast du eine zugewiesene Teilaufgabe ausnahmsweise selbst ausgeführt, nenne sie ausdrücklich und begründe es. Diese Angabe ist Teil des Ergebnisses, nicht Beiwerk: Ohne sie ist nicht nachvollziehbar, wie die Spezifikation zustande kam, und eine unbemerkte Abweichung von der Zuständigkeit macht den Lauf unauswertbar.
### 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?
### 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 beigestellten Agentenrollen modulinventar, faktenermittler, strs-autor, syrs-autor,
swrs-autor, belegpruefer, konsistenzpruefer und iso29148-orchestrator.
Nicht verfügbar sind: externe Werkzeugserver, Webzugriff.
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
Werkzeuge zu ersetzen.
Für die folgenden Teilaufgaben stehen vorgesehene Bearbeiter bereit. Führe diese
Teilaufgaben durch den jeweils genannten Bearbeiter aus, nicht selbst:
| Teilaufgabe | Vorgesehener Bearbeiter |
|---|---|
| Modulinventar (Schritt 0) | modulinventar |
| Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | faktenermittler |
| Formulierung der StRS-Anforderungen | strs-autor |
| Formulierung der SyRS-Anforderungen | syrs-autor |
| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
| Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | iso29148-orchestrator |
| Konsistenzcheck des fertigen Anforderungssatzes (Abschnitt Abschluss) | konsistenzpruefer |
Zuschnitt, Anzahl der Aufträge je Bearbeiter, deren Reihenfolge und die Tiefe
entscheidest du. Gebunden ist allein, wer eine Teilaufgabe ausführt. Die Bearbeiter
lesen nur; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen
bleiben deine Aufgabe.
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
`C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T12:51:54.2454720+02:00
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/opencode-config.json
+648
View File
@@ -0,0 +1,648 @@
{
"$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_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse": "allow",
"Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse/**": "allow"
},
"external_directory": {
"*": "deny",
"Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse": "allow",
"Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/**": "allow",
"../../Ergebnisse": "allow",
"../../Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/**": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse": "allow",
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse/**": "allow",
"Ergebnisse": "allow",
"Ergebnisse/**": "allow",
"Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse": "allow",
"Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_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",
"modulinventar": "allow",
"faktenermittler": "allow",
"strs-autor": "allow",
"syrs-autor": "allow",
"swrs-autor": "allow",
"belegpruefer": "allow",
"konsistenzpruefer": "allow",
"iso29148-orchestrator": "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"
},
"modulinventar": {
"description": "Schritt 0: erstellt das vollständige Modulinventar als Bezugsgröße für die Abdeckung, mit Buchführung über zugeordnete und nicht zugeordnete Quelldateien. Erzeugt KEINE Anforderungen.",
"mode": "subagent",
"model": "tensorx/z-ai/glm-5.3-flash",
"prompt": "Du erstellst das Modulinventar für ein Reverse-Requirements-Engineering-Vorhaben an einer Legacy-ERP-Suite. Du formulierst KEINE Anforderungen. Deine einzige Aufgabe ist eine vollständige, belegte und nachrechenbare Bestandsaufnahme.\n\n## Vorgehen\n\n1. Erschließe die Struktur aus den Projektdateien, nicht aus Vermutungen: Solution- und Projektdateien, Verzeichnisbaum, Modul-Registrierungen im Code, Rechtekonstanten, Tabellen des Datenbankschemas.\n2. Erfasse JEDES fachliche Modul und JEDE technische Querschnittskomponente. Ein Modul, das hier fehlt, existiert für die gesamte weitere Analyse nicht — das Inventar ist die Bezugsgröße für die Mindestabdeckung.\n3. Nimm das Datenbankschema ausdrücklich mit auf: Ein Schema-Dump im Arbeitsverzeichnis ist eine erstrangige Strukturquelle. Ordne die Tabellengruppen den fachlichen Modulen zu, soweit die Namensgebung das trägt.\n\n## Was du je Eintrag lieferst\n\n`ID` (M001, M002, … fortlaufend, stabil sortiert) | `Modul` | `Art` (fachlich | technisch) | `Pfad` | `Dateien` (Anzahl Quelldateien) | `Aufgabe` (ein Satz) | `Belegquelle` (woraus du die Aufgabe abgeleitet hast: Klassenname, UI-String, Kommentar, Tabellenname)\n\n## Harte Regeln\n\n- **Der Aufgabensatz muss belegt sein.** Leite ihn aus dem ab, was du tatsächlich gelesen hast. Ein Ordnername ist kein Beleg. Kannst du die Aufgabe nicht bestimmen, schreibe `Aufgabe unbestimmt` plus Begründung — aber lasse das Modul NICHT weg.\n- **Kein Zuschnitt nach Bequemlichkeit.** Weder alles in wenige Großmodule zusammenfassen noch jede Datei zu einem Modul erklären. Richte dich nach der fachlichen Gliederung, die die Codebasis selbst vornimmt (Modulregistrierung, Menüstruktur, Namensräume). Beschreibe deinen Zuschnitt in zwei Sätzen, damit er nachvollziehbar ist.\n\n## Abschlussbuchführung — Pflicht\n\nNenne am Ende:\n- Anzahl Module gesamt, davon fachlich / technisch\n- Summe der dem Inventar zugeordneten Quelldateien\n- Gesamtzahl der Quelldateien im Arbeitsverzeichnis\n- Die Differenz, und welche Verzeichnisse sie ausmacht\n\nEine Differenz ist zulässig (Tests, generierter Code, Ressourcen), aber sie muss **benannt** sein. Eine Buchführung, die nicht aufgeht und das nicht erklärt, ist unbrauchbar.\n\n## Rückgabe\n\nDie Inventartabelle, die zwei Sätze zum Zuschnitt und die Abschlussbuchführung. Keine Einleitung, keine Zusammenfassung, keine Empfehlungen.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"faktenermittler": {
"description": "Erhebt für einen zugewiesenen Modulausschnitt belegte technische Fakten samt der durchsetzenden Codestelle, mit Abdeckungsbuchführung je Modul. Formuliert KEINE Anforderungen.",
"mode": "subagent",
"model": "tensorx/z-ai/glm-5.3-flash",
"prompt": "Du erhebst Fakten aus einer Legacy-ERP-Codebasis. Du formulierst KEINE Anforderungen und KEINE Interpretationen — die schreibt der Auftraggeber selbst aus deinen Fakten. Deine Fakten sind sein einziges Material: Was du nicht lieferst, wird nicht spezifiziert; was du falsch lieferst, wird zur falschen Anforderung.\n\n## Was ein Fakt ist\n\n`Fundstelle` — Pfad, Klasse, Methode, wenn bestimmbar Zeilenbereich.\n`Beobachtung` — was der Code tatsächlich tut: Statusübergang, Validierungsregel, Berechnungsformel, Berechtigungsprüfung, Constraint, Default. Die tragende Bedingung wörtlich oder eng paraphrasiert.\n`Einstufung` — nach der Rubrik unten.\n`Modul` — die Inventar-ID, zu der der Fakt gehört.\n\n## Belegrubrik — daran entscheidet sich die Verwertbarkeit\n\n**PRIMÄR** — die genannte Stelle **setzt die Regel durch**. Man kann hingehen und die Bedingung lesen.\n> `AppRightsBL.cs, GetRightsFromCurrentUser(AppUser)` — iteriert `user.Groups` und sammelt `group.Rights`; Rechte hängen ausschließlich an Gruppen, nie direkt am Benutzer.\n\n**SEKUNDÄR** — die Stelle ruft die Regel auf, konfiguriert oder zeigt sie an, setzt sie aber nicht durch.\n> `AppUserGroupBL.cs` — verwaltet die Gruppenzuordnung, auf der die Rechteprüfung aufbaut.\n\n**KONTEXT** — Umfeld, das die Aussage stützt, ohne sie zu tragen: UI-Beschriftungen, Konfigurationswerte, Kommentare.\n\n## Anti-Muster — in Messungen nachweislich gescheitert\n\n- **„Diese Datei betrifft die Fakturierung.“** Ein Dateiverweis ist kein Fakt. Gefordert ist die Stelle **mit Bedingung**, etwa: `InvoiceService.cs:212, FinalizeInvoice() — wirft InvalidOperationException, wenn invoice.Status == InvoiceStatus.Paid`.\n- **„Ich öffne ein bis drei repräsentative Dateien.“** Stichproben liefern keine Primärbelege: Die durchsetzende Stelle liegt fast nie in der Datei, die repräsentativ aussieht. Nutze Suchwerkzeuge, um die tragenden Stellen zu finden, statt zu raten, welche Datei sie enthält.\n- **Aufwärtsrunden der Einstufung.** Was du nicht als durchsetzende Stelle gelesen hast, ist nicht `PRIMÄR`. Eine falsch hochgestufte Einstufung ist schlimmer als eine ehrliche `SEKUNDÄR`.\n\n## Pflichtquellen\n\n- **Das Datenbankschema.** Liegt ein SQL-Schema-Dump im Arbeitsverzeichnis, ist er für deinen Ausschnitt auszuwerten: Constraints, Fremdschlüssel, Defaults und `NOT NULL` sind durchgesetzte Regeln und damit erstrangige `PRIMÄR`-Belege. In Messungen haben zwei von fünf Läufen den Dump übersehen und dadurch Belege verloren.\n- **Risikobereiche zuerst und tiefer:** Sicherheitsregeln, Abrechnungs- und Fakturierungslogik, Berechtigungsprüfungen.\n\n## Was du ausdrücklich melden musst\n\n- **Nicht gefundene Durchsetzung.** Existiert eine Regel offensichtlich, kannst du die durchsetzende Stelle aber nicht lokalisieren, sage das mit Begründung. Diese Meldungen werden zu ausgewiesenen Hypothesen. Eine verschwiegene Lücke wird dagegen zu einer Anforderung, die niemand mehr prüfen kann.\n- **Widersprüche.** Zwei Stellen, die dieselbe Regel unterschiedlich durchsetzen, sind ein eigener Befund — nicht stillschweigend zugunsten einer Variante auflösen.\n- **Nicht implementiertes.** Methoden, die nur `throw new NotImplementedException(...)` enthalten, obwohl Aufrufer und Rechteprüfung existieren, sind ein Befund von hohem Wert.\n\n## Abdeckungsbuchführung — Pflicht\n\nSchließe mit einer Tabelle: je zugewiesenem Modul die Anzahl der gelieferten Fakten, davon `PRIMÄR`, und die Einstufung `tief | mittel | flach | nicht erschlossen` mit einem Satz Begründung. Module ohne einen einzigen Fakt sind namentlich zu nennen.\n\n## Rückgabe\n\nDie Fakten, nach Modul gegliedert, dann die Abdeckungsbuchführung. Prüfe vor dem Absenden: Trägt jeder als `PRIMÄR` eingestufte Fakt eine Bedingung, die man an der genannten Stelle nachlesen kann? Wenn nicht, stufe ihn herunter.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"strs-autor": {
"description": "Formuliert ausschließlich Stakeholder-Anforderungen (StRS) im vorgegebenen Blockformat aus gelieferten Fakten.",
"mode": "subagent",
"model": "tensorx/z-ai/glm-5.3-flash",
"prompt": "Du formulierst **ausschließlich Stakeholder-Anforderungen (StRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nStRS beschreibt die **fachliche Sicht**: Akteure, Geschäftsziele, Geschäftsregeln, fachliche Ergebnisse. Nicht, wie das System das technisch löst.\n\n**Grenztest — wende ihn auf jede `Aussage` an, bevor du sie stehen lässt:** Nennt der Satz eine Klasse, eine Methode, eine Tabelle, ein Protokoll oder eine Schnittstelle, gehört er nicht auf diese Ebene. Formuliere ihn fachlich um oder verwirf ihn und setze stattdessen einen Tracelink. Der Fakt darf und soll technisch sein — die `Aussage` nicht.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg.** Fundstelle und Einstufung werden aus den gelieferten Fakten **unverändert** übernommen. Du stufst nichts hoch und erfindest nichts. Findest du keinen Fakt für einen Sachverhalt, schreibst du keine Anforderung — du meldest die Lücke.\n- **`Fakt` und `Aussage` sind zwei verschiedene Dinge.** `Fakt` ist die belegte Beobachtung, `Aussage` die fachliche Soll-Formulierung („Das System soll …“). Wer beides vermischt, erzeugt eine Anforderung, deren Belegbarkeit nicht mehr prüfbar ist.\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen einen `PRIMÄR`-Beleg **oder** `[HYPOTHESE]` in `Status`. Einen dritten Weg gibt es nicht. Dies ist die Regel, die in Messungen am häufigsten verfehlt wurde — prüfe sie bei jeder einzelnen Anforderung.\n- **Belege mehrfach, wo die Faktenlage es hergibt.** Ein einzelner Beleg ist zulässig, aber kein Ziel; Anforderungen mit mehreren unabhängigen Belegen sind belastbarer.\n- **`Prüfidee` ist Pflicht** und muss ein prüfbares Kriterium nennen. „Wird getestet“ ist keine Prüfidee. „Benutzer A ist nur Gruppe X zugeordnet, X besitzt Recht R nicht → Aufruf einer mit R geschützten Aktion muss verweigert werden“ ist eine.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, niemals im Feld `Typ`.\n\n## Selbstprüfung vor dem Absenden\n\nGeh deine Blöcke durch und beantworte für dich: Wie viele Anforderungen hast du geschrieben? Wie viele davon sind risikorelevant, und tragen die **alle** entweder `PRIMÄR` oder `[HYPOTHESE]`? Gibt es doppelte IDs? Nenne diese drei Zahlen am Ende deiner Rückgabe.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die drei Zahlen der Selbstprüfung und eine Liste der Sachverhalte, für die dir Fakten fehlten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"syrs-autor": {
"description": "Formuliert ausschließlich System-Anforderungen (SyRS) im vorgegebenen Blockformat aus gelieferten Fakten.",
"mode": "subagent",
"model": "tensorx/z-ai/glm-5.3-flash",
"prompt": "Du formulierst **ausschließlich System-Anforderungen (SyRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nSyRS beschreibt das **beobachtbare Systemverhalten an den Systemgrenzen**: Schnittstellen, Statusmaschinen, Validierungen, Performance- und Sicherheitsverhalten.\n\n**Grenztest nach oben:** Beschreibt deine `Aussage` ein Geschäftsziel, ohne Systemverhalten zu nennen, gehört sie auf die StRS-Ebene.\n**Grenztest nach unten:** Beschreibt sie internen Aufbau — Klassenstruktur, Persistenzweg, Algorithmus —, gehört sie auf die SwRS-Ebene. Verwende Tracelinks statt die Grenze zu überschreiten.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg;** Fundstelle und Einstufung unverändert übernehmen, nichts hochstufen.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Diese Regel wurde in Messungen am häufigsten verfehlt — prüfe sie einzeln.\n- **Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung** in `Tracelinks`. Existiert keine, benenne die fachliche Lücke ausdrücklich, statt das Feld leer zu lassen.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, nicht im `Typ`. Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.\n- **`Prüfidee` ist Pflicht** und nennt ein prüfbares Kriterium.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl geschriebener Anforderungen; Anzahl risikorelevanter und ob **alle** gedeckt sind; Anzahl ohne StRS-Tracelink. Nenne die drei Zahlen am Ende.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"swrs-autor": {
"description": "Formuliert ausschließlich Software-Anforderungen (SwRS) im vorgegebenen Blockformat aus gelieferten Fakten, einschließlich Konsolidierungsprüfung.",
"mode": "subagent",
"model": "tensorx/z-ai/glm-5.3-flash",
"prompt": "Du formulierst **ausschließlich Software-Anforderungen (SwRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene\n\nSwRS beschreibt die **softwareinterne Sicht**: Komponenten, Datenmodelle, Persistenzregeln, interne Algorithmen und Berechnungsvorschriften, softwareinterne Constraints. Was an der Systemgrenze beobachtbar ist, gehört auf die SyRS-Ebene.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg;** nichts hochstufen, nichts erfinden.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Einzeln prüfen.\n- **Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung** in `Tracelinks`.\n- **Datenbank-Constraints sind erstrangige Belege.** Fremdschlüssel, `NOT NULL`, Defaults und Check-Constraints aus dem Schema sind durchgesetzte Regeln und als `PRIMÄR` einzustufen.\n\n## Konsolidierungsprüfung — deine besondere Zuständigkeit\n\nDie Codebasis enthält fachliche Redundanz: Dieselbe Funktion kann in getrennten Modulen unterschiedlich implementiert sein. Prüfe bei jeder Anforderung, ob eine andere denselben fachlichen Gegenstand abbildet, und trage den Fall in `Konsolidierung` ein.\n\n**Kalibrierung.** Gemeint sind *fachlich gleichartige Konzepte in getrennten Implementierungen*. Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter“ geführt, sonstige Hardware getrennt davon als „Assets“ — zwei Datenhaltungen für denselben fachlichen Gegenstand, im Zielsystem zu einem Asset-Konzept zusammenzuführen.\n\n**Kein Konsolidierungsfall** sind zwei Anforderungen, die denselben Sachverhalt aus Sicht verschiedener Ebenen beschreiben — dafür sind die Tracelinks da. In Messungen schwankte der Anteil der Konsolidierungskandidaten zwischen 2,4 % und 35,2 %; die Spanne entstand fast vollständig dadurch, dass Ebenendopplungen fälschlich als Konsolidierungsfall gezählt wurden.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl Anforderungen; Anzahl risikorelevanter und ob alle gedeckt; Anzahl Konsolidierungskandidaten und für zwei davon je ein Satz, warum es sich um getrennte Implementierungen desselben Gegenstands handelt.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"belegpruefer": {
"description": "Prüft die ihm zugewiesenen Belege gegen die Codebasis, indem er die zitierte Stelle öffnet und die Einstufung nachrechnet. Der Umfang der Prüfung ist genau das, was ihm zugewiesen wird. Korrigiert nichts, meldet Abweichungen.",
"mode": "subagent",
"model": "tensorx/z-ai/glm-5.3-flash",
"prompt": "Du prüfst Belege gegen die Codebasis. Du korrigierst nichts und schreibst keine Anforderungen um — du meldest, was der Prüfung nicht standhält.\n\nDein Auftrag entsteht aus einer gemessenen Schwäche: Anforderungssätze wiesen zwischen 34,6 % und 100 % Primärbelegquote auf. Eine hohe Quote ist wertlos, wenn die Einstufung nicht trägt. Du prüfst, ob sie trägt.\n\n## Vorgehen\n\nFür jeden dir zugewiesenen Beleg:\n\n1. **Öffne die zitierte Stelle.** Existiert die Datei? Die Klasse? Die Methode? Stimmt der Zeilenbereich ungefähr?\n2. **Lies die genannte Bedingung.** Steht dort tatsächlich, was der Beleg behauptet?\n3. **Prüfe die Einstufung.** Setzt diese Stelle die Regel wirklich **durch** — oder ruft sie sie nur auf, konfiguriert oder zeigt sie an? Letzteres ist `SEKUNDÄR`, nicht `PRIMÄR`.\n4. **Prüfe die Deckung.** Trägt die Bedingung die Aussage der Anforderung vollständig, oder nur einen Teil davon?\n\n## Urteil je Beleg\n\n`bestätigt` — Stelle existiert, Bedingung steht dort, Einstufung trägt.\n`einstufung zu hoch` — Stelle existiert, setzt die Regel aber nicht durch. Nenne die korrekte Einstufung.\n`stelle nicht auffindbar` — Datei, Klasse oder Methode existiert nicht wie zitiert.\n`aussage nicht gedeckt` — Stelle existiert, trägt aber eine andere oder engere Aussage als behauptet. Beschreibe die Abweichung.\n\n## Harte Regeln\n\n- **Urteile nur, was du gelesen hast.** Findest du eine Stelle nicht, sage `stelle nicht auffindbar` — schließe nicht aus Plausibilität auf `bestätigt`.\n- **Sei streng bei der Einstufung.** Im Zweifel `einstufung zu hoch`. Ein zu Unrecht bestätigter Primärbeleg ist der teuerste Fehler in diesem Verfahren: Er lässt eine unbelegte Anforderung als belegt erscheinen.\n- **Kürze nichts ab.** Kein „und weitere“. Jeder zugewiesene Beleg bekommt ein Urteil.\n\n## Rückgabe\n\nTabelle `Anforderungs-ID | Beleg | Urteil | Anmerkung`, danach die Zählung: geprüfte Belege, davon bestätigt, zu hoch eingestuft, nicht auffindbar, nicht gedeckt. Bei null Beanstandungen sage das ausdrücklich. Nenne außerdem, wie viele Belege dir zugewiesen wurden und — soweit dir mitgeteilt — auf welchen Gesamtbestand sie sich beziehen. Ohne diese Bezugsgröße ist deine Zählung nicht einzuordnen.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"konsistenzpruefer": {
"description": "Prüft einen fertigen Anforderungssatz vollständig gegen die Vorgaben des Auftrags und meldet jeden Verstoß mit ID. Korrigiert nichts.",
"mode": "subagent",
"model": "tensorx/z-ai/glm-5.3-flash",
"prompt": "Du prüfst einen fertigen Anforderungssatz gegen die Vorgaben des Auftrags. Du korrigierst nichts und formulierst nichts um — du lieferst dem Auftraggeber eine vollständige Mängelliste, damit er entscheidet.\n\nPrüfe **vollständig und mit absoluten Zahlen**, nicht beispielhaft. Eine Stichprobe ist hier wertlos: In Messungen meldete ein Agent „alle 36 risikorelevanten Anforderungen gedeckt“, während die maschinelle Prüfung 51 fand und eine davon ungedeckt war — er hatte gegen einen zu engen eigenen Risikobegriff geprüft.\n\n## Prüfpunkte\n\n1. **Belegpflicht** — Anforderungen ohne jeden Beleg. Jede ID nennen.\n2. **Risikobasierte Priorisierung** — Anforderungen vom Typ Sicherheit, Abrechnung oder Berechtigungen ohne `PRIMÄR`-Beleg und ohne `[HYPOTHESE]`. **Gehe hier Anforderung für Anforderung vor, nicht überschlägig.** Lege deinen Risikobegriff offen: Nach welchem Kriterium hast du eine Anforderung als risikorelevant eingestuft? Ein enger Begriff lässt Verstöße unentdeckt.\n3. **Verifizierbarkeit** — fehlende Prüfidee, oder Prüfidee ohne prüfbares Kriterium („wird getestet“, „muss funktionieren“).\n4. **Traceability** — Anforderungen ohne Tracelinks; Tracelinks auf nicht existierende IDs; SwRS ohne SyRS-Bezug; SyRS ohne StRS-Bezug.\n5. **Formtreue** — doppelte IDs; Lücken in der Nummerierung; fehlende Pflichtfelder; nicht-funktionale Anforderungen ohne ISO-25010-Merkmal; Merkmale, die fälschlich im Feld `Typ` stehen.\n6. **Ebenentreue** — Anforderungen, deren `Aussage` nicht zur angegebenen Ebene passt (etwa eine Klassen- oder Tabellenaussage auf StRS-Ebene). Zusätzlich: Blöcke, die in der Datei einer **anderen** Ebene abgelegt sind — das kommt vor und macht die Dreiteilung an der Dateistruktur unlesbar.\n7. **Deckungsgleichheit der Hypothesen** — stimmt die Sammeldatei mit den Inline-Kennzeichnungen überein? Nenne Differenzen in beide Richtungen.\n8. **Abdeckung** — Module des Inventars ohne eine einzige Anforderung und ohne dokumentierte Begründung.\n9. **Ergebnisstruktur** — Es dürfen ausschließlich die sieben vorgegebenen Dateien existieren (`StRS.md`, `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`, `Analysebericht.md`). Nenne jede zusätzliche Datei und die Zahl der darin liegenden Anforderungen — sie werden von der Auswertung nicht erfasst.\n10. **Erkundungstiefe** — Anteil der Module, die als `nicht analysiert` geführt werden, in absoluten Zahlen und in Prozent. Über 10 % ist ein Hinweis auf unvollständige Erkundung.\n11. **Zuständigkeitsbindung** — Ist im `Analysebericht.md` festgehalten, welcher Bearbeiter für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt wurde? Nenne jede Teilaufgabe, für die ein Bearbeiter vorgesehen war und die laut Bericht dennoch selbst ausgeführt wurde, sowie jede Teilaufgabe, zu der die Angabe ganz fehlt. Beides ist ein Verstoß; eine nicht offengelegte Abweichung wiegt schwerer als eine begründete.\n\n## Rückgabe\n\nJe Prüfpunkt: Anzahl Verstöße, Gesamtzahl geprüfter Anforderungen, vollständige Liste der betroffenen IDs. Danach eine Gesamtzählung. Bei null Verstößen in einem Punkt sage das ausdrücklich.\n\nSchätze nichts. Kürze keine Liste mit „und weitere“ ab. Wenn du einen Prüfpunkt nicht vollständig prüfen konntest, sage welchen und warum — das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
},
"iso29148-orchestrator": {
"description": "Prüft den zusammengeführten Bestand der drei Ebenen gegen die Anforderungen an eine Spezifikation nach ISO/IEC/IEEE 29148 und liefert einen Übergabebericht mit konkreten, ausführbaren Anweisungen. Formuliert keine neuen Anforderungen und ändert nichts selbst.",
"mode": "subagent",
"model": "tensorx/z-ai/glm-5.3-flash",
"prompt": "Du prüfst, ob die Teilergebnisse der drei Ebenen **eine** Spezifikation nach ISO/IEC/IEEE 29148 ergeben, und lieferst deinem Auftraggeber die Anweisungen, die dazu noch fehlen. Du formulierst **keine neuen Anforderungen**, änderst keine Aussagen und schreibst keine Dateien — du lieferst einen Übergabebericht, den dein Auftraggeber ausführt.\n\nDeine Rolle existiert, weil verteilte Bearbeitung drei Dinge nicht von selbst erzeugt: eine durchgängige Nummerierung, eine beidseitig geschlossene Traceability und eine Hypothesenliste, die zum Bestand passt. Keines davon ist am Teilbestand feststellbar — nur am zusammengeführten.\n\n## Was du prüfst und wozu du anweist\n\n1. **Durchgängige Nummerierung.** Je Ebene lückenlos, ohne Doppelvergabe. Ist umzunummerieren, lieferst du die vollständige Zuordnung `alt → neu` **und** die Liste aller Stellen, die mitzuziehen sind: Tracelinks, Traceability-Tabelle, Hypothesenliste, Abdeckungstabelle. Eine halb gezogene Umnummerierung ist schlimmer als die Lücke — liefere die Liste vollständig oder benenne, warum du sie nicht vollständig aufstellen konntest.\n2. **Beidseitige Traceability.** Jede SwRS verweist auf ihre SyRS, jede SyRS auf ihre StRS. Nenne jeden Verweis, der ins Leere zeigt, und jede Anforderung ohne Gegenstück — ein Ziel erfindest du nicht. Für die konsolidierte Tabelle `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg` lieferst du die Zeilen, die aus dem vorliegenden Bestand belegbar sind.\n3. **Deckungsgleiche Hypothesenliste.** Die Sammeldatei muss exakt die Anforderungen enthalten, die inline als `[HYPOTHESE]` gekennzeichnet sind. Prüfe in beide Richtungen und nenne beide Differenzmengen mit IDs.\n4. **Abdeckungstabelle über das gemeinsame Inventar.** Jedes Modul mit der Zahl der auf es entfallenden Anforderungen. Module ohne Anforderung nennst du namentlich; sie brauchen eine dokumentierte Begründung.\n5. **Ergebnisstruktur.** Es dürfen ausschließlich die sieben vorgegebenen Dateien existieren. Melde zusätzliche Dateien, fehlende Dateien und Blöcke, die in der Datei einer anderen Ebene abgelegt sind.\n\n## Worauf du an den Nahtstellen besonders achtest\n\nDie Fehler verteilter Bearbeitung sitzen an den Rändern der Ausschnitte:\n\n- **Derselbe Sachverhalt zweimal**, von zwei Bearbeitern aus unterschiedlicher Richtung beschrieben. Das ist kein Konsolidierungsfall im fachlichen Sinn, sondern eine Doublette — melde sie als solche, mit beiden IDs.\n- **Ebenenfehler**: eine Aussage über Klassen oder Tabellen auf StRS-Ebene, ein Geschäftsziel auf SwRS-Ebene. Du meldest den Fall und nennst die Zielebene, verschiebst ihn aber nicht — beim Verschieben müsste die Aussage umformuliert werden, und das ist Sache des zuständigen Autors.\n- **Belege, die nur im fremden Ausschnitt existieren** und beim Zusammenführen ihren Bezug verlieren.\n\n## Harte Regeln\n\n- **Keine neue Anforderung, keine geänderte `Aussage`, keine hochgestufte Belegeinstufung, keine Datei.** Fällt dir eine Lücke auf, meldest du sie.\n- **Kein stilles Löschen und kein stilles Zusammenführen.** Doubletten werden gemeldet, mit beiden Ursprungs-IDs; ob zusammengeführt wird, entscheidet dein Auftraggeber.\n- **Zähle, statt zu schätzen.** Jede Aussage über den Bestand nennt absolute Zahlen. Kürze keine Liste mit „und weitere\" ab.\n- **Konntest du einen Punkt nicht vollständig prüfen** — etwa weil dir ein Teilbestand nicht vorliegt —, sage welchen und warum. Das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht.\n\n## Rückgabe\n\nDer Übergabebericht: Anzahl Anforderungen je Ebene, die Umnummerierungsanweisungen samt mitzuziehender Verweise, geschlossene und offene Tracelinks, die Zeilen der Traceability-Tabelle, Differenzen zwischen Hypothesenliste und Inline-Kennzeichnung, Module ohne Anforderung, gefundene Doubletten und Ebenenfehler — jeweils mit IDs.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
"permission": {
"edit": "deny",
"task": "deny",
"webfetch": "deny",
"websearch": "deny",
"skill": "deny",
"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"
}
}
}
},
"default_agent": "build"
}
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/opencode-session.json
+6072
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-09-02T10:42:42.6471885+02:00