Effortvergleich high gegen max: Effort wirkt ueber Delegation
Dieselbe TensorX-Matrix ein zweites Mal bei hoechstem Effort. Zwoelf gueltige Laeufe, 2.116 Anforderungen, 127,6 Mio. Tokens, hochgerechnet $10,53 aus der Preisliste vom 02.09.2026. Befund: In den nicht-delegierenden Zellen bewegt sich der Ertrag zwischen minus 18 und plus 44 Prozent ohne erkennbare Richtung - in der Groessenordnung der Streuung. Der eine deutliche Ausschlag ist GLM in custom mit plus 122 Prozent, erreicht mit 78 statt 30 Subagenten. Der hoehere Denkaufwand schlaegt sich in mehr Zerlegung nieder, und die traegt den Ertrag, nicht der Denkaufwand als solcher. Qwens custom-Zelle hat sich qualitativ erholt: bei high 61 Prozent ohne Beleg und 40 Prozent Hypothesen, bei max 3 Prozent ohne Beleg und 96 Prozent Primaerbeleg. Der Einbruch war ein Laufmerkmal, kein Modellmerkmal - ein weiterer Beleg, dass n gleich 1 je Zelle nicht traegt. Skill 13.2.0: analyse-anforderungen.py toleriert jetzt vier Markdown-Fassungen der Feldvorgabe. Jedes der vier eingesetzten Modelle formatierte sie anders, und jede Fassung wurde zunaechst mit null Anforderungen gezaehlt, obwohl Belege und Pruefideen vollstaendig vorlagen. Das ist ein Befund ueber den Versuchsaufbau: Die Formatvorgabe ist fuer Menschen eindeutig, fuer maschinelle Auswertung nicht. Regressionsprobe an sieben Laeufen unveraendert. _matrix.ps1 nimmt zusaetzlich -Effort und -Modi fuer einzelne Zellen. Ein Lauf fiel durch Standby des Rechners aus und wurde wiederholt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
e2c3a0e8f8
commit
08d90f1ccb
+1
-1
@@ -10,7 +10,7 @@
|
||||
- **Endzeit:** 2026-09-02T09:56:48.1729325+02:00
|
||||
- **Dauer gesamt:** 00:22:43 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
|
||||
- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
|
||||
- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
|
||||
- **Codebasis-Commit:** `e2c3a0e8f81d005161dde733f7e4b08f581e3468` (vor dem Lauf dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
[2026-09-03T07:01:23.272704+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\Ergebnisse)
|
||||
[2026-09-03T07:01:23.411046+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=solo; Effort=max (uebergeben=True); Stall-Timeout=0s
|
||||
[2026-09-03T07:29:52.324136+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-03T07:29:54.422734+00:00] OpenCode export: Exporting session: ses_f99ed7003ffeeUQm86XBQsMt1H
|
||||
[2026-09-03T07:29:54.453699+00:00] Ende: Exitcode=0; Status=success; Turns=108; Tokens=10220040; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\RawResult.json
|
||||
+283
@@ -0,0 +1,283 @@
|
||||
# Analysebericht
|
||||
|
||||
Reverse Requirements Engineering der c-entron ERP-Suite (CentronERP, C#/XAML/WPF + Blazor-Web, MSSQL).
|
||||
Untersuchungsgegenstand: gesamtes Arbeitsverzeichnis, keine Modulbeschränkung. Statische Analyse, keine Ausführung.
|
||||
|
||||
**Ergebnisumfang:** 24 StRS-, 47 SyRS- und 59 SwRS-Anforderungen (130 gesamt) in den 7 vorgegebenen Ergebnisdateien.
|
||||
|
||||
---
|
||||
|
||||
## Schritt 0 – Modulinventar
|
||||
|
||||
Vollständiger Überblick vor der ersten Anforderung. Das Inventar ist die Bezugsgröße der Abdeckungstabelle und wurde während der Analyse nur ergänzt (u. a. um „Periphere Datendienste“), nicht gekürzt.
|
||||
|
||||
| Nr | Modul / Komponente | Pfad (relativ) | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| 1 | Anwendungskern & Verbindungsverwaltung | src\centron\Centron.WPF.UI (App.xaml.cs, CentronApplication.cs, ConnectionHeartbeatTimer.cs, FrontWindow, StartupArgs) | Startet die WPF-Suite, wählt Verbindungsart, hält die Sitzung per Herzschlag und den Hauptrahmenfenster-Workflow |
|
||||
| 2 | Modul Finanzen | src\centron\Centron.WPF.UI\Modules\Finances | Arbeitsflächen für Belege, Verträge, Mahnwesen, OPOS, Zahlungen sowie automatisierte, Timer- und Flatrate-Abrechnung |
|
||||
| 3 | Modul Helpdesk | src\centron\Centron.WPF.UI\Modules\Helpdesk | Ticketlisten/-details, Checklisten, TaskManagement, Ereignisse, SelfCare-Formularversand |
|
||||
| 4 | Modul Warenwirtschaft | src\centron\Centron.WPF.UI\Modules\Warehousing | Artikelverwaltung, Inventur, Barcodeverwaltung, Kommissionierung, Materialgruppen |
|
||||
| 5 | Modul Einkauf | src\centron\Centron.WPF.UI\Modules\Purchasing | Bestellungen und Bestellvorschlagslisten je Filiale |
|
||||
| 6 | Modul Datenaustausch | src\centron\Centron.WPF.UI\Modules\DataExchange | Export-/Importarbeitsflächen: FiBu-Übergabe, E-Rechnung, Datenabgleiche |
|
||||
| 7 | Modul MyCentron (inkl. Dashboard) | src\centron\Centron.WPF.UI\Modules\MyCentron | Persönlicher Arbeitsplatz: Kalender, MyDay, ToDos, Notizen, Dashboard-Container, Telefonie, persönliche Einstellungen |
|
||||
| 8 | Modul Statistiken | src\centron\Centron.WPF.UI\Modules\Statistics | Umsatz-, Auslastungs-, Vertrags- und MSP-Auswertungen |
|
||||
| 9 | Modul Verwaltung | src\centron\Centron.WPF.UI\Modules\Administration | Zentrale Verwaltung: Mandanten, Länder, Rechtegruppen, DSGVO, SQL-Werkzeuge, Eskalationen, PDF-Signatur, Mail-/Textvorlagen |
|
||||
| 10 | Modul Massenupdates | src\centron\Centron.WPF.UI\Modules\Massenupdates | Template-basierte Sammeländerungen (u. a. Belegpreisupdates) |
|
||||
| 11 | Modul OnlineBanking | src\centron\Centron.WPF.UI\Modules\OnlineBanking | Bankkonten-Verknüpfung und Umsatzverarbeitung |
|
||||
| 12 | Modul Passwortmanager | src\centron\Centron.WPF.UI\Modules\PasswordManager | Verwaltete Passwortablage mit Zugriffsprotokoll |
|
||||
| 13 | Modul Zahler & Kostenträger | src\centron\Centron.WPF.UI\Modules\PayersAndCostCenter | Verwaltung der verrechnungstechnischen Merkmale |
|
||||
| 14 | Modul PLM | src\centron\Centron.WPF.UI\Modules\PLM | Produktlebenszyklus-Import und -pflege |
|
||||
| 15 | Modul Produktion | src\centron\Centron.WPF.UI\Modules\Production | Fertigungsauftrags-Arbeitsflächen |
|
||||
| 16 | Modul Projektverwaltung | src\centron\Centron.WPF.UI\Modules\ProjectManagement | Projekte/Projektdaten im Belegkontext (ProjNr, CRM-Projekte) |
|
||||
| 17 | Modul Projektpreisimport | src\centron\Centron.WPF.UI\Modules\ProjectPriceImport | Import projektspezifischer Preise an Belege |
|
||||
| 18 | Modul QM | src\centron\Centron.WPF.UI\Modules\QM | QM-Einstellungen und Beleggründe mit QM-Bezug |
|
||||
| 19 | Modul Berichte | src\centron\Centron.WPF.UI\Modules\Reports | Berichtsgruppen, Druck- und PDF-Einstellungen |
|
||||
| 20 | Modul RMA | src\centron\Centron.WPF.UI\Modules\Rma | Rücksendeübersichten und RMA-Erfassung |
|
||||
| 21 | Modul Vertrieb | src\centron\Centron.WPF.UI\Modules\Sales | Belegarbeitsflächen, Sonderartikel-/Vorlagenimporte, Mailing, Produktmatrix |
|
||||
| 22 | Modul Befragungen | src\centron\Centron.WPF.UI\Modules\Survey | Kundenzufriedenheits-Befragungen (Auslösung am Ticketabschluss) |
|
||||
| 23 | Modul TelekomDive | src\centron\Centron.WPF.UI\Modules\TelekomDive | Abgleich von Telekom-Anschlussdaten |
|
||||
| 24 | Modul Kalender | src\centron\Centron.WPF.UI\Modules\Calendar | Terminverwaltung und Darstellungsoptionen |
|
||||
| 25 | Modul Externe Tools | src\centron\Centron.WPF.UI\Modules\ExternalTool | Start externer Programme mit Parameterersetzung |
|
||||
| 26 | Modul Logistik | src\centron\Centron.WPF.UI\Modules\Logistic | Versand- und Versandarteneinstellungen |
|
||||
| 27 | Modul Global | src\centron\Centron.WPF.UI\Modules\Global | Gemeinsame Werkzeuge: PDF-Anzeige/-Druck, benutzerdefinierte Eigenschaften, Info-Seite |
|
||||
| 28 | Modul KI | src\centron\Centron.WPF.UI\Modules\ArtificialIntelligence | KI-Chat-Arbeitsflächen |
|
||||
| 29 | C-FLOW-Prozesse | src\centron\Centron.WPF.UI\Processes | Prozessautomatisierung an Tickets und Belegen |
|
||||
| 30 | Wizards | src\centron\Centron.WPF.UI\Wizards | Mehrstufige Assistenten (u. a. Abrechnungsdatums-Wizard) |
|
||||
| 31 | Client-Dienste & Ressourcen | src\centron\Centron.WPF.UI\Services, Resources, Style, Layout | Clientseitige Dienstinfrastruktur, Lokalisierung (resx DE/EN), Styles |
|
||||
| 32 | Adressstamm (Accounts-BL) | src\backend\Centron.BL\Accounts | Kunden/Lieferanten/Kontakte/Bankverbindungen, rechtegefilterte Suche, Aktivitäten |
|
||||
| 33 | Belegpipeline (Receipts-BL) | src\backend\Centron.BL\Sales\Receipts | Belegerzeugung/-speicherung, Sperren, Versionen, Übergaben, Provisions-Schemata, Beleg-PDFs |
|
||||
| 34 | Rechnung & Mahnwesen (Invoices/Dunning/Opos) | src\backend\Centron.BL\Sales\Receipts\Invoices | Rechnungs-Verhaltensregeln, Mahnläufe, Offene-Posten-Verarbeitung |
|
||||
| 35 | Verträge & Stammblätter (CustomerAssets\Contracts) | src\backend\Centron.BL\Sales\CustomerAssets\Contracts | Verträge, ClickContracts, Stammblätter, Zählerimport und -abrechnung |
|
||||
| 36 | Helpdesk-BL (Sales\Support) | src\backend\Centron.BL\Sales\Support | Tickets, Zeiten, Status, Vorlagen, Eskalation, Checklisten, Signaturen |
|
||||
| 37 | Artikel & Lager (Warehousing-BL) | src\backend\Centron.BL\Warehousing | Artikel, Bestände, Inventur, Barcodes, Bewegungen, Kommissionierung |
|
||||
| 38 | Steuerlogik (Warehousing\TaxBL) | src\backend\Centron.BL\Warehousing\TaxBL.cs | Datumsgültige Steuerketten, Default-Kaskade, Umstellungen |
|
||||
| 39 | Einkauf-BL (Purchasing) | src\backend\Centron.BL\Purchasing | Lieferanten, Bestellvorschläge, Bestellungen je Filiale |
|
||||
| 40 | Kalender-BL | src\backend\Centron.BL\Calendar | Termin- und Anzeigeeinstellungen |
|
||||
| 41 | E-Mail (Mail, MailScanner) | src\backend\Centron.BL\Mail, MailScanner | Transporte (SMTP/EWS/Graph), Vorlagen, Signaturen, Blacklist, Mail-Scanner |
|
||||
| 42 | Rechteverwaltung (Administration\Rights) | src\backend\Centron.BL\Administration\Rights | Rechteprüfung (Sichtrus/Sichmemb) und Rechteverwaltung |
|
||||
| 43 | Authentifizierung & Sitzungen | src\backend\Centron.BL\Administration\Logins (Auth, TwoFactor), TwoFactorAuthenticator, Administration\AccessTokens | Login-Verfahren (Basic/AD/OIDC/Web), Tickets, 2FA, Access-Token |
|
||||
| 44 | Lizenzierung | src\backend\Centron.BL\Administration\Licensing | Lizenz- und Anwendungsprüfung bei der Anmeldung |
|
||||
| 45 | Nummernkreise | src\backend\Centron.BL\Administration\Mandatory, Administration\Company | Kollisionsfreie Nummernvergabe mit Bereichen/Intervallen je Mandant/Filiale |
|
||||
| 46 | Einstellungen | src\backend\Centron.BL\Administration\Settings | Zentrale Konfiguration über ApplicationSettings/AppSettingsConst |
|
||||
| 47 | DSGVO/Datensicherheit | src\backend\Centron.BL\Administration\DataSecurity | Rechtegeschützte Bereinigung und Kontaktlöschung |
|
||||
| 48 | Mitarbeiter | src\backend\Centron.BL\EmployeeArea, Administration\Employees | Mitarbeiterstamm, Aktivitätsstatus, Auslastungsbezug |
|
||||
| 49 | Passwortmanager-BL | src\backend\Centron.BL\PasswordManagementArea | Verschlüsselte Schlüssel, Zugriffs-/Änderungsprotokolle |
|
||||
| 50 | Datenübernahme & E-Rechnung | src\backend\Centron.BL\DataExchange, EDI | ZUGFeRD/XRechnung, Lieferanten-EDI, DocBee, GfK, Zahlungs- und Fremdimporte |
|
||||
| 51 | FiBu-Schnittstellen | src\backend\Centron.Gateway | Formatklassen für Buchhaltungssysteme (DATEV, Abacus, Sage, …) |
|
||||
| 52 | Zahlungen & OnlineBanking-BL | src\backend\Centron.BL\Finances | Zahlungen, Zahlungseingänge, FinAPI-Abgleich |
|
||||
| 53 | Statistiken-BL | src\backend\Centron.BL\Statistics | Umsatz-, Auslastungs-, MSP- und Cache-Statistiken |
|
||||
| 54 | Berichtsengine | src\backend\Centron.BL\ReportEngine, Reporting | Vorlagen, Datenabfragen, PDF-Strategien, Filename-Regeln |
|
||||
| 55 | Produktion-BL | src\backend\Centron.BL\Production | Fertigungsaufträge/-positionen |
|
||||
| 56 | Aufgaben & ToDos | src\backend\Centron.BL\TaskManager, ToDoArea, MyDay | Aufgaben-, Erinnerungs- und Tageslogik |
|
||||
| 57 | Änderungsverfolgung | src\backend\Centron.BL\ChangeTracking | Import-Historie und Änderungsnachweise |
|
||||
| 58 | Benachrichtigungen | src\backend\Centron.BL\Notifications, NexusNotifications | Ereignis- und E-Mail-Benachrichtigungen |
|
||||
| 59 | KI-Chat | src\backend\Centron.BL\Administration\ArtificialIntelligence | Chat-Instruktionen und -Konfiguration |
|
||||
| 60 | RMA-BL | src\backend\Centron.BL\CustomerArea | RMA-Scheine, Sendarten, Artikelhistorie |
|
||||
| 61 | Entitäten & Schnittstellen | src\backend\Centron.Entities, Centron.Interfaces, Centron.Common | Domänenobjekte, Enums (u. a. BarcodeState), gemeinsame Kontrakte |
|
||||
| 62 | REST-Host & Authentifizierung | src\webservice\Centron.Host | API-Host, Ticket-/Token-Handler, Swagger, Versionierung, SignalR |
|
||||
| 63 | Hintergrunddienste | src\webservice\Centron.Host\AspNetCore\HostedServices | Über 40 periodische Dienste (Verträge, Caches, Sync, Massenupdates, …) |
|
||||
| 64 | Webservice-Kern | src\webservice\Centron.WebServices.Core | DTOs/Entities, RestRequests, Rechtekonstanten |
|
||||
| 65 | Verbindungs- & Controller-Schicht | src\webservice\Centron.Controllers, c-entron.misc.ConnectionManager | Verbindungsvermittlung für Clients |
|
||||
| 66 | Kundencenter & WebCart | src\nexus\CentronNexus\WebCart, WebOffer, CustomerPortal-* | Kundenportal: Shop, Belege, Tickets, Formulare |
|
||||
| 67 | ServiceBoard | src\nexus\CentronNexus\ServiceBoard | Cache-basierte Ticket-Kanban-/Listenansichten mit Filtern |
|
||||
| 68 | Dokumentunterschrift | src\nexus\CentronNexus\DocumentSigning | Browser-Signaturerfassung per Signature-Pad |
|
||||
| 69 | Management & Office (Web) | src\nexus\CentronNexus\Management, Office, ProductionOrderManagement | Web-Verwaltungsansichten (Tasks, Personal, Fertigung) |
|
||||
| 70 | Nexus-Host | src\nexus\CentronNexus.Host | Blazor-Infrastruktur, Datei-, Branding- und Culture-Controller |
|
||||
| 71 | Outlook-AddIn | src\nexus\CentronNexus.OutlookAddIn | Outlook-Integration |
|
||||
| 72 | FinAPI-Client | src\apis\Centron.APIs.FinAPI | Bank-API-Client |
|
||||
| 73 | Versandclients | src\apis\Centron.Api.Gls, Centron.Api.Shipcloud | Paketdienst-Clients |
|
||||
| 74 | E-Rechnung Österreich | src\apis\Centron.Api.EbInterface | ebInterface-Erzeugung |
|
||||
| 75 | Produktdaten | src\apis\Centron.APIs.ITscopeDataAccess, Centron.APIs.IcecatDataAccess | Produktdaten-Import-Clients |
|
||||
| 76 | Cop/Egis Data Access | src\apis\Centron.APIs.CopDataAccess, Centron.APIs.EgisDataAccess | Fremddaten-Zugriffsklassen |
|
||||
| 77 | Steuerelemente | src\shared\Centron.Controls, Centron.Controls.Preview | Wiederverwendbare UI-Bausteine (Task-, Ticket-, Kalender-Views) |
|
||||
| 78 | Basisbibliothek | src\shared\Centron.Core | Result<T>, Google-Authenticator-Implementierung, Netz-/Text-Utils |
|
||||
| 79 | Datenbankschema | SSMS_DB_SCHEMA.sql | Vollständiges MSSQL-DDL (1.558 Tabellen, 134 FK-, 101 UNIQUE-Constraints) |
|
||||
| 80 | Skript-Infrastruktur | scripts | DB-Upgrade-Tooling (Skriptnummern, Signatur, Umgebungen) |
|
||||
| 81 | Paketierung & Deployment | deployment, docker, azure, azure-blazor, .github | WiX-Installer, Container, CI/CD-Definitionen |
|
||||
| 82 | Tests | tests | E2E-, Integrations- und Playwright-Tests |
|
||||
| 83 | Dokumentation | docs | Entwickler-/Feature-Dokumentation, Richtlinien |
|
||||
| 84 | Periphere Datendienste | src\backend\Centron.BL\VoucherManagement, SocialMedia, ProductMatrix, WebLinks, Tapi, RiverDivo, CPra, SelfCare, VideoPortal, TradePool, ItPlanner, Storage, ExternalHelpdesk; RestService-Parts RMM/RiverDivo/CPra | Kleine Zusatz- und Anbindungsbereiche (Gutscheine, Social-Media-Streams, Telefonie, Fernwartung, Selbstservice) |
|
||||
|
||||
---
|
||||
|
||||
## Abdeckungstabelle
|
||||
|
||||
Einstufung je Inventarzeile: `tief` (Kernklassen gelesen, mehrere Anforderungen), `mittel` (mehrere Anforderungen bzw. BL-Klassen gelesen), `flach` (Mindestabdeckung über Datei-/UI-/Schema-Ebene), `nicht analysiert`. „Anz. Anf." zählt die Anforderungen, die das Modul maßgeblich abbilden (eine Anforderung kann mehrere Module streifen; sie wird nur beim Hauptmodul gezählt).
|
||||
|
||||
| Nr | Modul | Abdeckung | Anz. Anf. |
|
||||
|---|---|---|---|
|
||||
| 1 | Anwendungskern & Verbindungsverwaltung | flach | 1 (SyRS-001) |
|
||||
| 2 | Modul Finanzen | mittel | 4 (SyRS-015, SyRS-016, SwRS-009, SwRS-010) |
|
||||
| 3 | Modul Helpdesk | mittel | 3 (SyRS-019, SyRS-020, SwRS-013) |
|
||||
| 4 | Modul Warenwirtschaft | mittel | 3 (SwRS-018, SwRS-021, SwRS-022) |
|
||||
| 5 | Modul Einkauf | flach | 1 (SwRS-023) |
|
||||
| 6 | Modul Datenaustausch | mittel | 2 (SwRS-024, SwRS-025) |
|
||||
| 7 | Modul MyCentron (inkl. Dashboard) | mittel | 3 (SyRS-044, SwRS-044, SwRS-045) |
|
||||
| 8 | Modul Statistiken | mittel | 2 (SyRS-035, SwRS-041) |
|
||||
| 9 | Modul Verwaltung | tief | 5 (SwRS-032, SwRS-033, SwRS-037, SyRS-040, SyRS-004) |
|
||||
| 10 | Modul Massenupdates | flach | 1 (SyRS-036) |
|
||||
| 11 | Modul OnlineBanking | mittel | 2 (SyRS-030, SwRS-027) |
|
||||
| 12 | Modul Passwortmanager | flach | 1 (SwRS-031) |
|
||||
| 13 | Modul Zahler & Kostenträger | flach | 1 (SyRS-014) |
|
||||
| 14 | Modul PLM | flach | 1 (SwRS-052) |
|
||||
| 15 | Modul Produktion | flach | 2 (SyRS-046, SwRS-043) |
|
||||
| 16 | Modul Projektverwaltung | flach | 1 (SwRS-004) |
|
||||
| 17 | Modul Projektpreisimport | flach | 1 (SwRS-006) |
|
||||
| 18 | Modul QM | flach | 1 (SyRS-046) |
|
||||
| 19 | Modul Berichte | mittel | 2 (SyRS-034, SwRS-042) |
|
||||
| 20 | Modul RMA | mittel | 2 (SyRS-047, SwRS-047) |
|
||||
| 21 | Modul Vertrieb | flach | 1 (SwRS-008) |
|
||||
| 22 | Modul Befragungen | flach | 1 (SyRS-020) |
|
||||
| 23 | Modul TelekomDive | flach | 1 (SwRS-052) |
|
||||
| 24 | Modul Kalender | mittel | 2 (SyRS-032, SwRS-030) |
|
||||
| 25 | Modul Externe Tools | flach | 1 (SwRS-052) |
|
||||
| 26 | Modul Logistik | flach | 1 (SwRS-026) |
|
||||
| 27 | Modul Global | flach | 1 (SwRS-058) |
|
||||
| 28 | Modul KI | flach | 2 (SyRS-045, SwRS-046) |
|
||||
| 29 | C-FLOW-Prozesse | flach | 1 (SwRS-017) |
|
||||
| 30 | Wizards | flach | 1 (SyRS-017) |
|
||||
| 31 | Client-Dienste & Ressourcen | mittel | 2 (SyRS-038, SwRS-057) |
|
||||
| 32 | Adressstamm (Accounts-BL) | tief | 3 (SwRS-001, SwRS-002, SwRS-003) |
|
||||
| 33 | Belegpipeline (Receipts-BL) | tief | 5 (SyRS-011, SyRS-012, SyRS-013, SwRS-004, SwRS-007) |
|
||||
| 34 | Rechnung & Mahnwesen | tief | 5 (SwRS-005, SwRS-006, SwRS-009, SwRS-010, SyRS-015) |
|
||||
| 35 | Verträge & Stammblätter | tief | 4 (SwRS-011, SwRS-012, SyRS-017, SyRS-018) |
|
||||
| 36 | Helpdesk-BL | tief | 6 (SwRS-013–017, SyRS-021) |
|
||||
| 37 | Artikel & Lager (BL) | tief | 3 (SwRS-018, SwRS-021, SwRS-022) |
|
||||
| 38 | Steuerlogik | tief | 3 (SwRS-019, SwRS-020, SyRS-023) |
|
||||
| 39 | Einkauf-BL | flach | 1 (SwRS-023) |
|
||||
| 40 | Kalender-BL | flach | 1 (SwRS-030) |
|
||||
| 41 | E-Mail (BL) | tief | 3 (SwRS-028, SwRS-029, SyRS-031) |
|
||||
| 42 | Rechteverwaltung (BL) | tief | 4 (SyRS-005, SyRS-006, SwRS-032, SwRS-033) |
|
||||
| 43 | Authentifizierung & Sitzungen | tief | 5 (SwRS-034, SwRS-035, SwRS-036, SyRS-003, SyRS-008) |
|
||||
| 44 | Lizenzierung | mittel | 1 (SyRS-004) |
|
||||
| 45 | Nummernkreise | tief | 3 (SyRS-010, SwRS-005, SwRS-038) |
|
||||
| 46 | Einstellungen | mittel | 1 (SwRS-037) |
|
||||
| 47 | DSGVO/Datensicherheit | mittel | 2 (SyRS-040, SwRS-039) |
|
||||
| 48 | Mitarbeiter | flach | 1 (SwRS-034) |
|
||||
| 49 | Passwortmanager-BL | flach | 1 (SwRS-031) |
|
||||
| 50 | Datenübernahme & E-Rechnung | tief | 4 (SwRS-023, SwRS-024, SwRS-052, SyRS-026) |
|
||||
| 51 | FiBu-Schnittstellen | mittel | 2 (SwRS-025, SyRS-027) |
|
||||
| 52 | Zahlungen & OnlineBanking-BL | mittel | 2 (SwRS-027, SyRS-030) |
|
||||
| 53 | Statistiken-BL | mittel | 2 (SwRS-041, SyRS-035) |
|
||||
| 54 | Berichtsengine | mittel | 2 (SwRS-042, SyRS-034) |
|
||||
| 55 | Produktion-BL | flach | 1 (SwRS-043) |
|
||||
| 56 | Aufgaben & ToDos | flach | 1 (SwRS-044) |
|
||||
| 57 | Änderungsverfolgung | flach | 1 (SwRS-040) |
|
||||
| 58 | Benachrichtigungen | flach | 2 (SwRS-045, SyRS-037) |
|
||||
| 59 | KI-Chat (BL) | flach | 1 (SwRS-046) |
|
||||
| 60 | RMA-BL | flach | 1 (SwRS-047) |
|
||||
| 61 | Entitäten & Schnittstellen | mittel | 2 (SwRS-022, SwRS-032) |
|
||||
| 62 | REST-Host & Authentifizierung | tief | 4 (SyRS-002, SwRS-036, SyRS-037, SyRS-042) |
|
||||
| 63 | Hintergrunddienste | tief | 3 (SyRS-036, SyRS-017, SyRS-044) |
|
||||
| 64 | Webservice-Kern | mittel | 2 (SwRS-032, SwRS-037) |
|
||||
| 65 | Verbindungs- & Controller-Schicht | flach | 1 (SyRS-001) |
|
||||
| 66 | Kundencenter & WebCart | mittel | 2 (SwRS-048 [HYPOTHESE], SyRS-009) |
|
||||
| 67 | ServiceBoard | flach | 1 (SwRS-050) |
|
||||
| 68 | Dokumentunterschrift | flach | 1 (SwRS-049) |
|
||||
| 69 | Management & Office (Web) | flach | 1 (SwRS-050) |
|
||||
| 70 | Nexus-Host | flach | 1 (SyRS-042) |
|
||||
| 71 | Outlook-AddIn | flach | 1 (SwRS-051) |
|
||||
| 72 | FinAPI-Client | flach | 1 (SwRS-027) |
|
||||
| 73 | Versandclients | flach | 1 (SwRS-026) |
|
||||
| 74 | E-Rechnung Österreich | flach | 1 (SwRS-024) |
|
||||
| 75 | Produktdaten | flach | 1 (SwRS-052) |
|
||||
| 76 | Cop/Egis Data Access | flach | 1 (SwRS-023) |
|
||||
| 77 | Steuerelemente | flach | 1 (SyRS-038) |
|
||||
| 78 | Basisbibliothek | flach | 1 (SwRS-034) |
|
||||
| 79 | Datenbankschema | tief | 4 (SwRS-001, SwRS-004, SwRS-013, SyRS-039) |
|
||||
| 80 | Skript-Infrastruktur | flach | 1 (SwRS-054) |
|
||||
| 81 | Paketierung & Deployment | flach | 1 (SwRS-055) |
|
||||
| 82 | Tests | flach | 1 (SwRS-053) |
|
||||
| 83 | Dokumentation | flach | 1 (SwRS-053) |
|
||||
| 84 | Periphere Datendienste | flach | 1 (SwRS-059) |
|
||||
|
||||
**Summen:** 84 Module: tief 16, mittel 22, flach 46, nicht analysiert 0. Anteil „nicht analysiert": 0 % (Schwelle 10 % deutlich unterschritten).
|
||||
Anforderungen gesamt: 24 StRS + 47 SyRS + 59 SwRS = 130.
|
||||
|
||||
---
|
||||
|
||||
## Konsistenzcheck (über das gesamte Anforderungs-Set)
|
||||
|
||||
| Prüfpunkt | Ergebnis |
|
||||
|---|---|
|
||||
| Doppelte oder mehrfach vergebene IDs | **Keine.** StRS-001…024, SyRS-001…047, SwRS-001…059 je fortlaufend und eindeutig. |
|
||||
| Anforderungen ohne Beleg | **Keine.** Alle 130 Anforderungen führen ≥ 1 Beleg mit Begründung; Klassifikation PRIMÄR/SEKUNDÄR/KONTEXT je Beleg vorhanden. |
|
||||
| Anforderungen ohne Übernahmewürdigkeit | **Keine.** Feld in allen 130 Blöcken gefüllt (übernehmen / Workaround / Sonderfall) mit Begründung. |
|
||||
| Tracelinks auf nicht existierende IDs | **Keine.** Alle referenzierten StRS-/SyRS-/SwRS-IDs existieren; Trace-Matrix in `Traceability.md` deckt jede SwRS-Anforderung und jede StRS-Anforderung ab (jede StRS hat ≥ 1 SyRS-Kind). |
|
||||
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung | **Keine gefunden.** Abgrenzungen dokumentiert: SwRS-005 (Sonderfälle Kunden-/Kreditornummern) vs. SwRS-038 (Nummernkreis-Entitäten je Mandant/Filiale) sind komplementär, nicht deckungsgleich; SwRS-018/019/020 (Artikel-Steuermodell / Kettenermittlung / Umstellung) behandeln getrennte Aspekte. Echte Konsolidierungsfälle (Gerätedaten-Streuhaltung, FiBu-Formate, ExtraKind, Auth-Varianten) sind in `Traceability.md` Abschnitt „Konsolidierungskandidaten" und in den Feldern `Konsolidierung` markiert. Ebenschilderung: SyRS-005/SyRS-006 (Rechte) und SyRS-040/SyRS-041 (DSGVO/Audit) sind bewusst getrennte Aspekte (Prüfung vs. Bereinigung vs. Protokollierung). |
|
||||
| Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) | Siehe Tabelle unten: 39 Anforderungen, davon 38 mit PRIMÄR-Beleg (durchsetzende Stelle benannt), 1 korrekt als HYPOTHESE gekennzeichnet (SwRS-048). |
|
||||
| Abgleich `Hypothesen.md` ↔ Inline-Markierungen | **Deckungsgleich.** Genau eine Inline-[HYPOTHESE]-Markierung (SwRS-048, `Status: HYPOTHESE` in SwRS.md) und genau dieser Eintrag in `Hypothesen.md`; keine zusätzlichen freien Fragen in `Hypothesen.md` (offene Punkte stehen in der Selbstbewertung). |
|
||||
|
||||
### Risikorelevante Anforderungen mit Belegsituation
|
||||
|
||||
| ID | Titel | PRIMÄR-Beleg (durchsetzende Stelle) | Status |
|
||||
|---|---|---|---|
|
||||
| SyRS-002 | REST-API mit Ticket-/Token-Authentifizierung | TicketAuthenticationHandler.cs:44-95; AccessTokenBL.cs:377-486 | belegt |
|
||||
| SyRS-003 | Sitzungsverwaltung über Tickets | TicketBL.cs:113-129; Authenticator.cs:124-129 | belegt |
|
||||
| SyRS-004 | Lizenzprüfung bei der Anmeldung | Authenticator.cs:100-155 (LicenseManager.CheckLicense) | belegt |
|
||||
| SyRS-005 | Serverseitige Rechteprüfung | AppRightsBL.cs:95-111 (SQL Sichtrus/Sichmemb); AccountBL.cs:1299-1370 | belegt |
|
||||
| SyRS-006 | Datenbeschränkende Rechte | AppRightsBL.cs:42-47; AccountSearchBL.cs:331 | belegt |
|
||||
| SyRS-007 | Kontosperrung/Mitarbeiterstatus | Authenticator.cs:157-218 (ValidateAppUser) | belegt |
|
||||
| SyRS-008 | Zwei-Faktor-Authentifizierung | TwoFactorAuthenticationBL.cs:43-54; TwoFactorAuthBL.cs:103-189 | belegt |
|
||||
| SyRS-009 | Web-Konto-Anmeldung | WebAccountAuthenticator.cs:42-83; DB WebAccounts | belegt |
|
||||
| SyRS-040 | DSGVO-Bereinigung mit Rechteabsicherung | DataSecurityBL.cs:36-66, 379 | belegt |
|
||||
| SyRS-041 | Protokollierung Rechte/Passwörter/Änderungen | DB SichProtokoll; PasswordManagementAccessLogBL.cs:22-33; AccessTokenBL.cs:186-280 | belegt |
|
||||
| SyRS-010 | Kollisionsfreie Nummernvergabe | NumberGroupBL.cs:62-91 (konditionelles Update) | belegt |
|
||||
| SyRS-014 | Rechnungsbehandlung (Pflichtfelder/Lager) | InvoiceSpecificLogic.cs:216-304 | belegt |
|
||||
| SyRS-015 | Mahnlauf mit Sperrwirkung | DunningBL.cs:341-456; DB RechKopf Mahnfelder | belegt |
|
||||
| SyRS-016 | Offene Posten/Zahlungszuordnung | OposBL.cs:28; DB RechKopf.Bezahlt | belegt |
|
||||
| SyRS-017 | Vertragsabrechnung als Hintergrunddienst | ContractEndeService.cs:8-16 | belegt |
|
||||
| SyRS-018 | Zählerstände erfassen/zurordnen | DeviceClickCounterBL.cs:30-128 | belegt |
|
||||
| SwRS-002 | Kundensuche mit Rechtefilter | AccountSearchBL.cs:76-79, 331-336 | belegt |
|
||||
| SwRS-003 | Bankverbindungen mit Rechten | BankAccountBL.cs:72-81 | belegt |
|
||||
| SwRS-005 | Nummernkreis-Sonderfälle Kunden/Kreditor | NumberGroupBL.cs:114-131 | belegt |
|
||||
| SwRS-006 | Rechnungs-Verhaltensregeln | InvoiceSpecificLogic.cs:216-368 | belegt |
|
||||
| SwRS-007 | Negative Artikelbuchungen nur mit Recht | InvoiceSpecificLogic.cs:239-240 | belegt |
|
||||
| SwRS-008 | Rechtevalidierung bei Beleg-/Stammdatenaktionen | AccountBL.cs:1299-1370; AccountAddressContactBL.cs:375-413 | belegt |
|
||||
| SwRS-009 | Mahnlauf-Verarbeitung | DunningBL.cs:341-456, 1059 | belegt |
|
||||
| SwRS-010 | OPOS-Verarbeitung | OposBL.cs:28; DB RechKopf.Bezahlt | belegt |
|
||||
| SwRS-011 | Vertrag-Stammblatt-Verknüpfung | SaveReceiptContractRepository.cs:364-365 | belegt |
|
||||
| SwRS-012 | Zählerzuordnung zu Stammblättern | DeviceClickCounterBL.cs:87-128 | belegt |
|
||||
| SwRS-015 | Helpdesk-Rechtekatalog | HelpdeskTimerWebServiceBL.cs:359-374; HelpdeskPatternWebserviceBL.cs:351-395 | belegt |
|
||||
| SwRS-019 | Steuerketten-Auflösung pro Position | TaxBL.cs:207-237, 286-320 | belegt |
|
||||
| SwRS-020 | Steuersatz-Umstellung mit Preisübernahme | TaxBL.cs:84-156 | belegt |
|
||||
| SwRS-025 | FiBu-Format-Registry | Gateway: IBookKeepingExport + Formatklassen | belegt |
|
||||
| SwRS-027 | FinAPI-Umsatzabgleich | OnlineBankingFinApiBL.cs; src\apis\Centron.APIs.FinAPI | belegt |
|
||||
| SwRS-031 | Passwortmanager mit Zugriffsprotokoll | PasswordManagementKeywordBL.cs:21-27; PasswordManagementAccessLogBL.cs:22-33 | belegt |
|
||||
| SwRS-032 | Rechtekonstanten-Katalog | UserRightsConst.cs (2301 Zeilen, z. B. SHOW_HELPDESK=20400295) | belegt |
|
||||
| SwRS-033 | Rechtegruppen-Zuordnung/-Reset | AppRightsBL.cs:63-87; CentronRestService.cs:344-356 | belegt |
|
||||
| SwRS-034 | Login-Prüfsequenz | BasicAuthenticator.cs:46-50 (SHA1, Salting-TODO); Authenticator.cs:169-217 | belegt |
|
||||
| SwRS-035 | Ticket-Ablage mit IP-Hinterlegung | TicketBL.cs:32-49, 113-129, 183-186 | belegt |
|
||||
| SwRS-036 | Access-Token-Verwaltung (Hash) | AccessTokenBL.cs:377-389, 478-486 | belegt |
|
||||
| SwRS-039 | DSGVO-Kontaktlöschung | DataSecurityBL.cs:379 | belegt |
|
||||
| SwRS-046 | KI-Chat mit Verwaltungsrecht | ArtificialIntelligenceChatInstructionPromptBL.cs:314 | belegt |
|
||||
| SwRS-048 | WebCart-Preisfindung aus Sonderpreisen | **kein PRIMÄR-Beleg** (nur README [KONTEXT] + UI [SEKUNDÄR]) | **HYPOTHESE** (regelkonform gekennzeichnet) |
|
||||
|
||||
---
|
||||
|
||||
## Selbstbewertung
|
||||
|
||||
**Module tief/mittel/flach/nicht analysiert (absolute Zahlen):**
|
||||
- tief: 16 von 84 (u. a. Belegpipeline, Rechnung/Mahnwesen, Verträge/Stammblätter, Helpdesk-BL, Steuerlogik, Rechteverwaltung, Authentifizierung, Nummernkreise, Datenübernahme/E-Rechnung, REST-Host, Hintergrunddienste, Datenbankschema)
|
||||
- mittel: 22 von 84
|
||||
- flach: 46 von 84
|
||||
- nicht analysiert: 0 von 84 (0 %, Schwelle 10 % unterschritten)
|
||||
|
||||
**Mindestabdeckung:** Ja — jedes der 84 Inventarmodule hat mindestens eine Anforderung (siehe Abdeckungstabelle, letzte Spalte). Kein Modul ist ohne Anforderung oder ohne `nicht analysiert`-Begründung.
|
||||
|
||||
**Belegqualität / dünne Belegstellen:**
|
||||
- Dünn (hoher SEKUNDÄR-/KONTEXT-Anteil, UI- oder Datei-listenbasiert): Modul Logistik (26), Externe Tools (25), TelekomDive (23), Befragungen (22), Projektverwaltung (16), QM (18), Global/Custom Properties (27), Outlook-AddIn (71), Cop/Egis (76) sowie Teile der „Peripheren Datendienste" (84, insbesondere CPra: nur Connector-Präsenz).
|
||||
- SyRS-045 (Mobile): Umfang der Mobile-Endpunkte nur als Präsenz geprüft (`src\backend\Centron.BL\Mobile`, DAO\Mobile) — bewusst nicht tief analysiert und im Prüfidee-Text als eingeschränkt ausgewiesen.
|
||||
- SwRS-021 (Inventur) wurde nachträglich anhand konkreter Methoden (CheckInventory, SaveInventory) verifiziert; SwRS-049 (Signaturen) ebenfalls (AddSignature/GetSignature).
|
||||
|
||||
**Hypothesen:** Genau eine Hypothese (SwRS-048, WebCart-Preisfindung). Begründung: Die Analyse hat die meisten Kernpfade direkt anhand durchsetzender Stellen gelesen (Rechte-SQL, Login-Sequenz, Nummernvergabe, Steuerketten, Belegregeln, Ticketabschluss); die WebCart-Preislogik lag außerhalb des gelesenen Pfadumfangs (nur README + Razor-Seiten). Eine Analyse ohne jeden offenen Punkt wäre bei ~21.700 Quelldateien nicht glaubhaft; die kleine Zahl reflektiert den Fokus auf belegbare Kernregeln statt auf Vollständigkeit jeder UI-Unterseite.
|
||||
|
||||
**Erkenntnisse, die einen Nachschlag in einer Folge-Iteration nahelegen:**
|
||||
1. **WebCart-Preisfindung** (SwRS-048): Datenpfad Sonderpreise → WebCart-Sortiment im Code verifizieren (Kandidat: `CustomerSpecialArticleBL`).
|
||||
2. **Provisionslogik**: `ReceiptProvisionSchemaBL/EmployeeLevel/EmployeeGoal` (Belegpipeline) wurden im Inventar erfasst, aber nicht als eigene Anforderung vertieft — Abrechnungsrelevant, PRIMÄR-Analyse offen.
|
||||
3. **Mobile-Umfang** (SyRS-045): Endpunkte und Fachfunktionen der Mobile-Schicht konkret erfassen.
|
||||
4. **CPra / SelfCare / TradePool / RiverDivo/RMM**: fachliche Einordnung und Wirkungsbereich klären (aktuell nur Präsenz, SwRS-059).
|
||||
5. **Rechte-Abdeckung**: `UserRightsConst` (2.301 Zeilen) gegen die tatsächlich prüfenden Webservice-Methoden abgleichen, um unbeaufsichtigte Aktionen (Rechte ohne Prüfstelle) zu finden.
|
||||
6. **ExtraKind-Semantik** (SwRS-011): Bedeutung der Werte 1/3 über Delphi-Legacy/DB-Daten bestätigen.
|
||||
7. **Massenupdates**: Regelwerk der `StartReceiptPriceUpdate`-Ausführung (Stornierung, Historie) vertiefen.
|
||||
8. **Alte FiBu-/EDI-Formate**: fachliche Entscheidung `veraltet` vs. `übernehmen` je Zielsystem (LexwarePro2011, DATEV-XmlOnline 2012, Sage OfficeLine).
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
# Glossar
|
||||
|
||||
Domänenbegriffe, wie sie in StRS/SyRS/SwRS verwendet werden. Technische Bezeichner (Klassen, Tabellen, Spalten) bleiben in Originalsprache.
|
||||
|
||||
| Begriff | Definition | Belegherkunft |
|
||||
|---|---|---|
|
||||
| **Adressstamm** | Zentrale Verwaltung von Geschäftspartnern: Kunden (`Kunden`), Lieferanten (`Kreditor`), Anschriften (`Anschrif`), Kontaktpersonen (`Personen`); gemeinsame Account-Basis mit Typzuordnung (`AccountCustomers`, `AccountSuppliers`). | DB-Schema; AccountBL |
|
||||
| **Account** | Internes Objektmodell eines Geschäftspartners im Adressstamm (Kunde und/oder Lieferant). | src\backend\Centron.BL\Accounts |
|
||||
| **Beleg (Receipt)** | Oberbegriff für Handelsdokumente: Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag, Stammblatt; im Code `IReceiptBase` / `CentronObjectKindNumeric`. | InvoiceSpecificLogic; AssetKindEnum |
|
||||
| **Belegkette / Übergabe** | Weiterführung von Positionen entlang Angebot → Auftrag → Lieferschein → Rechnung (→ Gutschrift); erlaubte Richtungen je Belegart (`CanBeForwardedFrom/Into`). | InvoiceSpecificLogic.cs:279-311 |
|
||||
| **Belegversion** | Änderungsstufe eines Belegs (`RechKopf.Version`); wesentliche Änderungen erzeugen eine neue Version. | SSMS_DB_SCHEMA.sql; ReceiptBL |
|
||||
| **Begrenzung („restricting right")** | Rechte, die den Datenbereich einschränken: nur eigene Datensätze, nur eigene Filiale, nur eigene Abteilung (z. B. SHOW_HELPDESK_ONLY_OWN_BRANCH). | CentronRights.md |
|
||||
| **Filiale (Branch)** | Organisatorische Untereinheit eines Mandanten; beeinflusst Nummernkreise, Rechtegruppen und Datenbereiche. | SSMS_DB_SCHEMA.sql `Filiale`; NumberGroupBL |
|
||||
| **Mandant** | Rechtlich selbstständiger Datenbereich (Mandantenfähigkeit); Nummernkreise hängen am Standardmandant mit BranchI3D je Filiale. | NumberGroupBL.cs:136-152 |
|
||||
| **Mahnstufe** | Zeit-/prozessbezogene Eskalationsstufe einer offenen Forderung (1-3) mit Stufentexten und optionaler Gerätesperre (`CustomerAssetsLockedAfterDunningLevel`). | AppSettingsConst.cs:100-104; DunningBL |
|
||||
| **OPOS (Offene Posten)** | Unbeglichene Rechnungen bzw. Restbeträge; Zahlungsstand in `RechKopf.Bezahlt`. | OposBL; DB-Schema |
|
||||
| **Stammblatt** | Kundenbezogene Geräteliste (im Code `MasterDataList`, `CentronObjectKindNumeric.MasterDataListClass`), vor allem für Mess-/Druckgeräte mit Zählern; vertragsbezogen verknüpfbar (`Stammblattbezogen`). | AssetKindEnum.cs:77; SaveReceiptContractRepository.cs:364 |
|
||||
| **Zähler / ClickCounter** | Verbrauchswerte eines Stammblattgeräts (z. B. Druckvolumen); Import via SNMP, Zuordnung per Zählerart-Mapping; Basis der Click-Abrechnung. | DeviceClickCounterBL |
|
||||
| **ClickContract** | Vertrag, der mengenbasiert (per Zählerstand) abgerechnet wird. | ClickContracts-Ordner |
|
||||
| **Ticket / Helpdesk** | Serviceanfrage im Helpdesk-Modul (`hlpdsk_requests`) mit Typen, Kategorien, Prioritäten, Status, Zeiten, Checklisten, Vorlagen. | DB-Schema; Helpdesk-BL |
|
||||
| **C-FLOW** | Ticketprozess-/Mustervorlagen (C-FLOW-Ticketpatterns) mit eigenen Verwaltungsrechten. | CentronRights.md 17.x; HelpdeskPatternBL |
|
||||
| **Zeit / Timer** | Abrechenbare Arbeitszeit am Ticket (`HelpdeskTimer`), mit Artikelbuchung, Anfahrtsartikeln und Kundensignatur. | HelpdeskTimer*-BL |
|
||||
| **Web-Konto (WebAccount)** | Externes Kundenkonto für das Web-Kundencenter (`WebAccounts`), zugeordnet zu Kunde/Anschrift/Person, mit eigener 2FA-Konfiguration. | DB-Schema WebAccounts; WebAccountAuthenticator |
|
||||
| **WebCart** | Web-Shop im c-entron Nexus für Kunden der Kunden; Sortiment/Preise aus Sonderpreisen des Kunden. | README.md |
|
||||
| **Nexus** | Web-Frontend (Blazor) mit Kundencenter, ServiceBoard, Dokumentunterschrift, WebCart. | src\nexus |
|
||||
| **ServiceBoard** | Cache-basierte Ticket-Kanban-/Listenansicht im Nexus mit Filter- und Formatierungsregeln. | ServiceBoard-Ordner |
|
||||
| **Nummernkreis (NumberGroup)** | Konfigurierbarer Zähler pro Belegart/Objektart je Mandant/Filiale mit Bereich und Intervall; vergibt Beleg- und Objektnummern kollisionsfrei. | NumberGroupBL |
|
||||
| **Recht / Sichtrus** | Numerisches Feinrecht (`UserRightsConst`), Gruppenzuweisung über `Sichtrus` (Gruppe↔Recht) und `Sichmemb` (Gruppe↔Benutzer). | AppRightsBL.cs:95-111 |
|
||||
| **Sitzung / Ticket (Auth)** | Anmeldungsnachweis als `Ticket` (Ablaufdatum, IP, Maschine) bzw. Personal Access Token (SHA-256-Hash). | TicketBL; AccessTokenBL |
|
||||
| **Zwei-Faktor-Authentifizierung (2FA)** | Zweiter Nachweisfaktor: TOTP (Google Authenticator), RADIUS oder E-Mail-Link; Web-Konten mit Gültigkeitsdauer in Tagen. | TwoFactorAuthenticationBL; TwoFactorAuthBL |
|
||||
| **MwSt-Kette (TaxRate chain)** | Verketteung von Steuersätzen über `NextTaxRate`/`ExpirationDate`, um zum Belegdatum gültige Sätze zu ermitteln. | TaxBL.cs:207-237 |
|
||||
| **WEEE** | Elektrogerätegesetz-Pflichtkennzeichnung (`IsWeeeRequired` je Belegart konfigurierbar). | InvoiceSpecificLogic.cs:304 |
|
||||
| **EDV/EDI** | Elektronischer Datenaustausch mit Lieferanten (Alltron, Also, Komsa, Opentrans, Egis, …) über den EDI-Gateway. | src\backend\Centron.BL\EDI |
|
||||
| **ZUGFeRD / XRechnung** | Deutsche E-Rechnungsformate/Versionen (2.x, 3.x) für Rechnungsexport. | InvoiceZugferdBL; XInvoiceVersion3 |
|
||||
| **ebInterface** | Österreichisches E-Rechnungsformat (eigenes API-Projekt). | src\apis\Centron.Api.EbInterface |
|
||||
| **FinAPI** | Bankenschnittstelle für Online-Banking-Umsatzabruf und Zahlungszuordnung. | OnlineBankingFinApiBL; src\apis\Centron.APIs.FinAPI |
|
||||
| **FiBu-Export** | Übertragung abgeschlossener Belege in Finanzbuchhaltungssysteme (DATEV, Abacus, Sage, SAP, …). | src\backend\Centron.Gateway |
|
||||
| **RMA** | Rücksendeschein mit Artikelpositionen, Sendart und Historie. | RmaBL |
|
||||
| **DSGVO-Modul** | Rechtegeschützte Bereinigung: Kontaktlöschung (DSGVO_DELETE_CONTACT) und Datenbank-Cleanup (ACCESS_CLEANUP_DATABASE). | DataSecurityBL |
|
||||
| **Sonderpreise** | Kundenspezifische Artikelpreise im Adressstamm; Quelle für WebCart (Hypothese SwRS-048). | README.md |
|
||||
| **Workaround (Übernahmewürdigkeit)** | Historisch gewachsene Behelfslösung, die im Zielsystem bewusst anders (sauberer) umgesetzt werden soll. | Prompt-Definition |
|
||||
| **Kostenstelle / Kostenträger** | Interne verrechnungstechnische Merkmale; bei Rechnungen verpflichtend (`IsCostCenterNeeded/IsCostCarrierNeeded`). | InvoiceSpecificLogic.cs:221-222 |
|
||||
| **Massenupdate** | Template-basierte Sammeländerung (u. a. Belegpreise), ausgeführt als Hintergrunddienst. | MassUpdateBL; MassUpdateService |
|
||||
| **MyDay** | Persönliche Tagesübersicht eines Benutzers (Termine, ToDos, Notizen) mit Benachrichtigungsdienst. | MyDay-BL; SendMyDayNotificationsService |
|
||||
| **Stammblatt der Zeit** | Konfigurierbare Kalenderanzeige: Anzeige des Stammblatts an einer erfassten Zeit (Einstellungs-ID 1630). | CalendarBL; AppSettingsConst 1630 |
|
||||
+17
@@ -0,0 +1,17 @@
|
||||
# Hypothesen
|
||||
|
||||
Sammlung aller Anforderungen, deren `Status` auf `HYPOTHESE` steht. Diese Datei deckungsgleich mit den Inline-`[HYPOTHESE]`-Markierungen in den Spezifikationsdateien.
|
||||
|
||||
---
|
||||
|
||||
## SwRS-048 – WebCart-Preisfindung aus Kunden-Sonderpreisen
|
||||
|
||||
| Feld | Inhalt |
|
||||
|---|---|
|
||||
| Ebene / ID | SwRS-048 |
|
||||
| Titel | WebCart-Preisfindung aus Kunden-Sonderpreisen |
|
||||
| Tracelinks | SyRS-009 (Web-Konto-Anmeldung) → StRS-021 (Selbstservice-Kundencenter) |
|
||||
| Belegsituation | [KONTEXT] README.md, Abschnitt „Contributing/WebCart" (beschreibt Zielgruppe und Preisquelle „Sonderpreise"); [SEKUNDÄR] WebCart-Razor-Seiten (`src\nexus\CentronNexus\WebCart\WebCartShopPage.razor` u. a.) belegen das Feature, nicht die Preislogik |
|
||||
| Offene Frage | Über welche Codepfade werden die „Sonderpreise" des Kunden (Adressstamm) in das WebCart-Sortiment/-Preismodell übernommen (Webservice-Methode, Filter, Mengen-/Rabattlogik)? |
|
||||
| Fehlende Information zur Bestätigung | Die durchsetzende Stelle (BL-/Controller-Methode, die Sonderpreise lädt) wurde im verfügbaren Analyseumfang nicht identifiziert; der WebCart-Datenzugriff wurde nur bis zur UI-/Konfigurationsebene (WebCartConfig.cs) verfolgt |
|
||||
| Auswirkung auf Migration | Preisfindung des Kundencenters vor Neuimplementierung konkret nachziehen (vermutlich `CustomerSpecialArticleBL`, vgl. `src\backend\Centron.BL\Sales\Support\CustomerSpecialArticleBL.cs` – dort nicht verifiziert) |
|
||||
+533
@@ -0,0 +1,533 @@
|
||||
# StRS – Stakeholder Requirements Specification
|
||||
|
||||
Reverse Requirements Engineering der c-entron ERP-Suite (CentronERP). Ebene 1 von 3 nach ISO/IEC/IEEE 29148:2018.
|
||||
Quellenbasis: Arbeitsverzeichnis (Quellcode, DB-Schema `SSMS_DB_SCHEMA.sql`, Dokumentation `docs/`, Rechtekatalog `CentronRights.md`). Alle Belegpfade sind relativ zum Arbeitsverzeichnis.
|
||||
|
||||
Traceability: Jede StRS-Anforderung wird von SyRS-Anforderungen referenziert (siehe `Traceability.md`).
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-001
|
||||
Titel: Zentrale Pflege des Adressstamms
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertriebsmitarbeiter, Backoffice, Lieferantenstammpfleger
|
||||
Vorbedingung: Benutzer besitzt Rechte am Adressstamm
|
||||
Fakt: Die Codebasis führt Kunden (`Kunden`, `AccountCustomers`), Lieferanten (`Kreditor`, `AccountSuppliers`) und Ansprechpartner (`Anschrif`, `Personen`) als eigene Tabellen; `AccountBL.ValidateUserRights` (src\backend\Centron.BL\Accounts\AccountBL.cs:1290-1370) prüft getrennte Rechte für Anlegen/Ändern/Löschen/Suchen/Entsperren.
|
||||
Aussage: Das System soll einen zentralen Adressstamm bereitstellen, in dem Kunden, Lieferanten, Anschriften und Kontaktpersonen einheitlich gepflegt werden, und jede Stammdatenänderung gegen rollenbasierte Rechte absichern.
|
||||
Ergebnis: Konsistenter Adressstamm als Bezugsobjekt für Belege, Tickets und Verträge.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Accounts\AccountBL.cs, Methode `ValidateUserRights` (Zeile 1299) – prüft CREATE_CUSTOMER, EDIT_CUSTOMER, DELETE_CUSTOMER, SEARCH_CUSTOMER, UNLOCK_CUSTOMER, RIGHT_LIEFERANTANLEGEN/-AENDERN und verweigert die Aktion bei fehlendem Recht
|
||||
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabellen `Kunden`, `Kreditor`, `Anschrif`, `Personen` – Datenmodell des Adressstamms
|
||||
- [KONTEXT] src\backend\Centron.BL\Accounts\AccountSearchBL.cs:331 – Einschränkungsrecht SHOW_ONLY_OWN_CUSTOMER verfeinert die Suche
|
||||
Prüfidee: Anlegen eines Kunden ohne Rechte CREATE_CUSTOMER wird mit Fehlermeldung abgewiesen; Anlegen mit Recht erzeugt Datensatz in `Kunden` mit I3D aus Nummernkreis.
|
||||
Tracelinks: StRS-012, StRS-003
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - zentrale Stammdatenhaltung ist Kernbestandteil eines ERP
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-002
|
||||
Titel: Vertriebsbelege über die gesamte Belegkette führen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertrieb, Innendienst
|
||||
Vorbedingung: Kunde im Adressstamm angelegt
|
||||
Fakt: `CentronObjectKindNumeric` (src\backend\Centron.Interfaces\CentronObjectKindNumeric.cs) und `AssetKindEnum` (src\backend\Centron.Entities\Entities\Sales\CustomerAssets\AssetKindEnum.cs:52-78) definieren die Belegarten Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag, Stammblatt; `InvoiceSpecificLogic.CanBeForwardedFrom/Into` (src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:279-281) regelt erlaubte Übergaben.
|
||||
Aussage: Das System soll die Belegkette von Angebot über Auftrag und Lieferschein bis Rechnung/Gutschrift abbilden und Belege untereinander weiterleiten können.
|
||||
Ergebnis: Nachvollziehbare Beleghistorie über alle Vertriebsstufen (ForwardedFrom/ForwardedInto).
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:279-281 – legt fest, aus welchen Belegarten Rechnungen entstehen und in welche Belegarten sie weitergeführt werden dürfen
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs, Methoden `CreateNewVersion`, `GetForwardedFrom` (Zeile 3505-3520, 3470) – Versionierung und Übergabehistorie
|
||||
- [SEKUNDÄR] src\backend\Centron.Entities\Entities\Sales\CustomerAssets\AssetKindEnum.cs:52-78 – Belegart-Namen („Angebot", „Auftrag", …)
|
||||
Prüfidee: Aus einem Auftrag wird eine Rechnung erstellt; die Rechnung verweist auf den Auftrag, Änderungen der Menge nach Übergabe sind gesperrt.
|
||||
Tracelinks: StRS-003, StRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Belegkette ist Kern des Vertriebsprozesses
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-003
|
||||
Titel: Rechnungsstellung mit lückenloser Belegnummerierung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung, Vertrieb
|
||||
Vorbedingung: Belegart Rechnung konfiguriert, Nummernkreis existiert
|
||||
Fakt: `NumberGroupBL.GetNextNumber` (src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:62-133) vergibt Nummern mit Intervall über optimistisches Update (`rowCountChanged == 1`) und prüft Kollisionen gegen Zieltabelle sowie Sonderfall `Kunden`/`Kreditor`; `RechKopf.Nummer` (SSMS_DB_SCHEMA.sql) ist Pflichtfeld.
|
||||
Aussage: Das System soll für jeden Beleg lückenlose, kollisionsfreie Nummern aus mandanten-/filialspezifischen Nummernkreisen vergeben, auch bei gleichzeitiger Nutzung durch mehrere Benutzer.
|
||||
Ergebnis: Keine doppelten Belegnummern; Nummernkreise lückenlos fortlaufend (Option Intervall).
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:80-91 – bedingtes Update (SET Current WHERE Current=alt) verhindert Doppelvergabe bei Parallelität
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:114-131 – Sonderprüfung gegen `Kunden`/`Kreditor`-I3D
|
||||
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabelle `RechKopf`, Spalte `Nummer NOT NULL`
|
||||
Prüfidee: Zwei gleichzeitige Rechnungserstellungen erzeugen zwei verschiedene Nummern; künstlich belegte Nummer wird übersprungen.
|
||||
Tracelinks: StRS-002, StRS-011
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - GoBD-relevante Kernfunktion
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-004
|
||||
Titel: Forderungsmanagement: Mahnwesen und Zahlungseingänge
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung, Debitorenbuchhaltung
|
||||
Vorbedingung: Rechnung gestellt, Zahlungsziel verstrichen
|
||||
Fakt: `RechKopf` enthält Mahnstufe, Mahnung1-3-Datum/Bearbeiter, MahnStop, Bezahlt (SSMS_DB_SCHEMA.sql); `DunningBL` (src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningBL.cs:58-1059) bildet Mahnkunden, Mahnstatistik, Mahnstopp und Rechteprüfung ab; AppSettingsConst 100-104 (src\backend\Centron.BL\Administration\Settings\AppSettingsConst.cs) definiert Mahntexte je Stufe und Gerätesperre nach Mahnstufe.
|
||||
Aussage: Das System soll überfällige Forderungen in drei Mahnstufen verfolgen, Mahntexte/E-Mails mit Platzhaltern erzeugen, Mahnstopp je Kunde erlauben und Zahlungseingänge den Rechnungen zuordnen.
|
||||
Ergebnis: Mahnlauf liefert je Kunde Mahnstatus; gesperrte Kundengeräte werden beim Ablauf der Stufe gesperrt (StRS-005).
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningBL.cs:341-456 – UpdateDunningSettingsForCustomer/UpdateDunningStopAndInfo/Get- und UpdateSettings
|
||||
- [PRIMÄR] SSMS_DB_SCHEMA.sql, `RechKopf`-Spalten Mahnstufe, Mahn1-3Datum, MahnStop, Bezahlt
|
||||
- [SEKUNDÄR] src\backend\Centron.BL\Administration\Settings\AppSettingsConst.cs:100-104 – Mahntexte je Stufe, CustomerAssetsLockedAfterDunningLevel
|
||||
Prüfidee: Rechnung 35 Tage überfällig erscheint im Mahnlauf Stufe 1 mit konfiguriertem Text; Mahnstopp-Kunde wird übersprungen; Teilzahlung reduziert offen markierten Betrag.
|
||||
Tracelinks: StRS-003, StRS-005
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Standard-Forderungsprozess
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-005
|
||||
Titel: Vertrags- und Zählerabrechnung (Verträge, ClickContracts, Stammblätter)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertrieb (Vertragsmanagement), Service
|
||||
Vorbedingung: Vertrag mit vertragsbezogenem Stammblatt (Geräteliste) beim Kunden
|
||||
Fakt: `SaveReceiptContractRepository` (src\backend\Centron.DAO\Repositories\Sales\Receipts\ContractList\SaveReceiptContractRepository.cs:364-365) setzt `Stammblattbezogen` aus `ExtraKind`; `DeviceClickCounterBL` (src\backend\Centron.BL\Sales\CustomerAssets\Contracts\ClickContracts\DeviceClickCounterBL.cs:30-128) liest importierte Zählerstände (SNMP), ordnet sie Geräten/Stammblättern zu; `ContractEndeService` (src\webservice\Centron.Host\AspNetCore\HostedServices\ContractEndeService.cs:8-16) aktualisiert Vertragsenddaten periodisch; NamedQueryPool.xml:5523 beschreibt Übernahme des Startwerts bei Vertragswechsel.
|
||||
Aussage: Das System soll Wartungs-/Mietverträge inkl. vertragsbezogener Gerätelisten („Stammblätter") verwalten, Zählerstände der Geräte erfassen und daraus mengenbasierte (Click-)Abrechnungen erzeugen, wobei Vertragsübergänge Zählerstände korrekt fortschreiben.
|
||||
Ergebnis: Mengenbasierte Abrechnung pro Gerät und Zeitraum ohne Doppelabrechnung über Vertragsgrenzen.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\CustomerAssets\Contracts\ClickContracts\DeviceClickCounterBL.cs:87-128 – Zähler je Stammblatt, Zuordnung importierter Zähler
|
||||
- [PRIMÄR] src\backend\Centron.DAO\Repositories\Sales\Receipts\ContractList\SaveReceiptContractRepository.cs:364-365 – Kennzeichnung `Stammblattbezogen`
|
||||
- [KONTEXT] src\backend\Centron.DAO\NamedQueries\NamedQueryPool.xml:5523 – Kommentar zur Startwert-Übernahme bei Vertragswechsel
|
||||
Prüfidee: Zählerstand 12.000 bei Endwert 10.000 erzeugt Abrechnung über 2.000 Einheiten; Vertrag wechselt mitten im Jahr, Startwert übernimmt letzten Stand des Vorgängervertrags.
|
||||
Tracelinks: StRS-002, StRS-004
|
||||
Konsolidierung: Kandidat: Stammblatt- (MasterDataList) und Zähler-Datenhaltung (DeviceClickCounter/SNMP-Import) im Zielsystem mit dem allgemeinen Gerätebestand (AccountDevices, AssetManagementDevices) zusammenführen - siehe SwRS-012.
|
||||
Übernahmewürdigkeit: übernehmen - Kerngeschäft der Branche; Doppelhaltung der Gerätedaten ist Workaround
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-006
|
||||
Titel: Serviceprozesse über Helpdesk-Tickets steuern
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Servicetechniker, Dispatcher, Kunden
|
||||
Vorbedingung: Rechte am Helpdesk-Modul
|
||||
Fakt: Rechtekatalog `CentronRights.md` beschreibt Ticket-Lebenszyklusrechte (anzeigen/anlegen/bearbeiten/abschließen); `HelpdeskCloseBL.CloseHelpdesk` (src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:120-157) setzt Abschlussstatus aus den Einstellungen, löscht ToDos, schreibt Historie und Kundenaktivität; `HelpdeskStatusBL` (src\backend\Centron.BL\Sales\Support\HelpdeskStatusBL.cs:27-56) liefert Status aus freier Statustabelle.
|
||||
Aussage: Das System soll Serviceanfragen als Tickets mit Typen, Kategorien, Prioritäten, Status, Fälligkeit, Zuweisung und Prüf-Checklisten verwalten und ihren Lebenszyklus von Annahme bis Abschluss mit Historie abbilden.
|
||||
Ergebnis: Vollständige Ticketnachverfolgung; abgeschlossene Tickets erzeugen Historien- und Aktivitätseinträge.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:120-157 – Abschluss: Status aus Einstellungen, ClosedAt, ToDos löschen, Historie, Aktivität
|
||||
- [PRIMÄR] SSMS_DB_SCHEMA.sql, Tabellen hlpdsk_requests, hlpdsk_status, hlpdsk_typen, hlpdsk_kategorien, hlpdsk_prioritaeten
|
||||
- [KONTEXT] CentronRights.md, Abschnitt Helpdesk – beabsichtigte Rechtewirkung je Aktion
|
||||
Prüfidee: Ticket anlegen → Statusfolge bearbeiten → Abschluss erzeugt ClosedAt, Historieneintrag „Close", Kundenaktivität und entfernt offene ToDos.
|
||||
Tracelinks: StRS-007, StRS-021
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernprozess Service
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-007
|
||||
Titel: Zeiterfassung und abrechenbare Leistungen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Techniker, Serviceleitung, Buchhaltung
|
||||
Vorbedingung: Ticket geöffnet bzw. Beleg vorhanden
|
||||
Fakt: `HelpdeskTimerWebServiceBL` (src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskTimerWebServiceBL.cs:359-374) prüft EDIT_TIME und OWN_TIME_EDIT; `HelpdeskTimerArticleBookingBL` und `HelpdeskTimerAddressSpecialArticlesBL` (src\backend\Centron.BL\Sales\Support\) buchen Leistungen und Anfahrtsartikel; CentronRights.md Abschnitte 7-9 regeln Zeitbearbeitung, Verschieben und Löschen (nur wenn Ticket nicht Teil eines Belegs ist).
|
||||
Aussage: Das System soll Leistungen (Zeiten) am Ticket und am Kunden erfassen, mit Artikeln verrechnen, auf Belege übertragen und dabei Nutzerrechte und Belegbindung berücksichtigen.
|
||||
Ergebnis: Zeiten sind revisionsnachvollziehbar und fließen in Belege/Rechnungen ein.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskTimerWebServiceBL.cs:359-374 – Rechteprüfung EDIT_TIME/OWN_TIME_EDIT vor Zeitänderung
|
||||
- [KONTEXT] CentronRights.md, Abschnitte 7-9 – Verschieben/Löschen nur wenn „Ticket nicht Teil eines Belegs"
|
||||
- [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Helpdesk\TicketDetails\TimeRecording\TimeRecordingView.xaml:541 – UI-Feld „Stammblatt" an Zeit
|
||||
Prüfidee: Techniker ohne OWN_TIME_EDIT kann fremde Zeit nicht ändern; Zeit eines in Rechnung gestellten Tickets lässt sich nicht löschen.
|
||||
Tracelinks: StRS-006, StRS-012
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernprozess
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-008
|
||||
Titel: Artikelstamm und Lagerbestände verwalten
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Lagerleitung, Einkaufs-/Vertriebsmitarbeiter
|
||||
Vorbedingung: Lagerstandorte angelegt
|
||||
Fakt: Warehousing-BL (src\backend\Centron.BL\Warehousing\) enthält ArticleBL, ArticleStockBL, InventoryNewBL (src\backend\Centron.BL\Warehousing\InventoryManagement\InventoryNewBL.cs), BarcodeBL, MaterialGroupBL; UI-Modul Warehousing (src\centron\Centron.WPF.UI\Modules\Warehousing\) bietet Artikelverwaltung, Inventur, Barcodes, Kommissionierung.
|
||||
Aussage: Das System soll Artikel mit Einheiten, Preisen, Materialgruppen, Ersatzteilen und Lagerbeständen verwalten und Inventuren sowie Barcode-Verfolgung unterstützen.
|
||||
Ergebnis: Korrekte Bestände je Lager/Standort; Artikel als Basis für Belege.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Warehousing\ArticleStockBL.cs – Bestandsführung (Klasse vorhanden und von Beleglogik referenziert)
|
||||
- [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Warehousing – Modulaufteilung (Artikelverwaltung, Inventur, Barcode, Kommissionierung)
|
||||
- [KONTEXT] SSMS_DB_SCHEMA.sql, Tabellen ARTIK, WareKopf/WarePos (Wareneingänge)
|
||||
Prüfidee: Wareneingang erhöht Bestand, Rechnung mit UpdatesStock=true vermindert Bestand; Inventurdifferenz korrigiert Bestand protokolliert.
|
||||
Tracelinks: StRS-002, StRS-009
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-009
|
||||
Titel: Beschaffung mit Lieferanten-Integrationen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Einkäufer, Lieferanten-EDI-Gateways
|
||||
Vorbedingung: Lieferantenstamm konfiguriert
|
||||
Fakt: EDI-Ordner (src\backend\Centron.BL\EDI\) implementiert Lieferantenformatklassen (AlltronOrderBL, AlsoOrderBL, AlsoOrderCH_BL, ConcertoOrderBL, EgisOrderBL, KomsaOrderBL, Opentrans21OrderBL, EgisWarenkorbBL, EgisOrderConfirmBL) und EDIDispatcherBL; Einkauf-BL (src\backend\Centron.BL\Purchasing\SupplierBL.cs, OrderSuggestionListBL.cs) bildet Bestellvorschläge.
|
||||
Aussage: Das System soll Bestellungen je Filiale erzeugen, aus Bestellvorschlägen befüllen und mit Lieferanten über EDI-Formate austauschen (Bestellung, Bestellbestätigung, Warenkorb).
|
||||
Ergebnis: Elektronische Bestellkette mit Protokoll (EDILog).
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\EDI\EDIDispatcherBL.cs – zentrale Weiterverarbeitung der EDI-Vorgänge
|
||||
- [PRIMÄR] src\backend\Centron.BL\Purchasing\SupplierOrderPerBranchBL.cs – Bestellungen je Filiale
|
||||
- [SEKUNDÄR] src\backend\Centron.BL\EDI\KomsaOrderBL.cs u. a. – Lieferantenspezifische Formatklassen
|
||||
Prüfidee: Bestellvorschlag → Bestellung → EDI-Export erzeugt lieferantenspezifische Datei; Bestellbestätigung aktualisiert Positionen.
|
||||
Tracelinks: StRS-008, StRS-010
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen; einzelne Lieferantenformate ggf. Sonderfall (Kundenindividuell)
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-010
|
||||
Titel: FiBu-konforme Belegweitergabe
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung, externe FiBu-Systeme
|
||||
Vorbedingung: Belege abgeschlossen
|
||||
Fakt: Der Gateway (src\backend\Centron.Gateway) implementiert Export-/Importklassen für DATEV (Ascii, XmlOnline 2012/2020, AccountingPro), Abacus, Addison, Lexware, Navision, Sage 50/OfficeLine, SAP, Schilling AS400, Stotax, Europa3000, GDI, BBG und nutzerdefinierte Schnittstellen.
|
||||
Aussage: Das System soll abgerechnete Belege in Formate gängiger Finanzbuchhaltungssysteme exportieren und Buchungsdaten importieren können.
|
||||
Ergebnis: FiBu-Exportdatei pro Zielsystem mit korrekten Konten/Perioden.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.Gateway\BookKeepingExportDatevAscii.cs u. a. – konkrete Formatimplementierungen
|
||||
- [PRIMÄR] src\backend\Centron.BL\DataExchange\BookKeepingExportBL.cs, BookKeepingImportBL.cs – Aufruf- und Regellogik
|
||||
- [SEKUNDÄR] src\backend\Centron.Gateway\BookKeepingExportCustomInterface.cs – kundenspezifische Schnittstellen
|
||||
Prüfidee: Monatsabschluss-Export erzeugt DATEV-Ascii-Datei, die im Zielsystem importiert werden kann; fehlerhafte Gegenkonten erzeugen Exportwarnung.
|
||||
Tracelinks: StRS-003
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen; veraltete Formate (z. B. LexwarePro2011, XmlOnline_Maerz2012) als `veraltet` prüfen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-011
|
||||
Titel: Mandanten- und Filialstruktur abbilden
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Gruppenleitung, Systemadministration
|
||||
Vorbedingung: Mehrere Mandanten/Filialen im Einsatz
|
||||
Fakt: `NumberGroupBL.RefreshAllNumberGroups` (src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:136-152) erzeugt Nummernkreise je Standardmandant und Filiale; `AppRightsBL.GetAllRightGroups` (src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:39-48) filtert Rechtegruppen nach Filiale; Tabelle `Filiale` im DB-Schema.
|
||||
Aussage: Das System soll mehrere Mandanten und Filialen mit eigenen Nummernkreisen, Stammdaten und Rechtebereichen unterstützen und filialbezogene Datenbegrenzung ermöglichen.
|
||||
Ergebnis: Benutzer sieht nur Daten seiner Filiale, wenn einschränkendes Recht gesetzt ist.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:39-48 – Rechtegruppenfilter `BranchI3D == currentUser.Employee.BranchI3D` bei MANAGE_RIGHTS_ONLY_OWN_BRANCH
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:136-152 – Nummernkreise je Mandant+Filiale
|
||||
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabelle `Filiale`
|
||||
Prüfidee: Benutzer der Filiale B erhält bei MANAGE_RIGHTS_ONLY_OWN_BRANCH nur Rechtegruppen der Filiale B; Belegnummerierung der Filiale A ist von B unabhängig.
|
||||
Tracelinks: StRS-012, StRS-003
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-012
|
||||
Titel: Zugriff nur nach Rollen- und Gruppenrechten
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Administrator, alle Benutzer
|
||||
Vorbedingung: Benutzer ist Gruppen zugeordnet
|
||||
Fakt: Rechte werden über Gruppen zugewiesen: `Sichtrus` (Gruppe↔Recht) und `Sichmemb` (Gruppe↔Benutzer); `AppRightsBL.CheckRightsFromUser` (src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:95-111) führt die Prüfung per SQL durch; Geschäftslogik ruft diese Prüfung in schreibenden Operationen auf (z. B. AccountBL.ValidateUserRights, BankAccountBL.cs:72-81).
|
||||
Aussage: Das System soll jede privilegierte Aktion gegen Rechte prüfen, die dem Benutzer über Gruppen zugeteilt sind, und die Aktion bei fehlendem Recht verweigern.
|
||||
Ergebnis: Kein unautorisierter Zugriff auf Funktionen/Daten; Rechteprüfung serverseitig.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:95-111 – SQL gegen Sichtrus/Sichmemb, Rückgabe der Rechte-IDs
|
||||
- [PRIMÄR] src\backend\Centron.BL\Accounts\BankAccountBL.cs:72-81 – Prüfung CREATE/EDIT_Bank_Account vor Speichern
|
||||
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabellen `Sichtrus`, `Sichmemb`
|
||||
Prüfidee: Benutzer ohne Recht erhält bei direktem Webservice-Aufruf eine Verweigerungsantwort; mit Recht gelingt die Aktion.
|
||||
Tracelinks: StRS-013, StRS-011
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-013
|
||||
Titel: Gesicherte Anmeldung für interne und externe Nutzer
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Interne Benutzer, Kunden (Web-Konto), Administratoren
|
||||
Vorbedingung: Benutzerkonto existiert
|
||||
Fakt: Authenticator-Familie (src\backend\Centron.BL\Administration\Logins\Auth\): BasicAuthenticator (SHA1-Passwortvergleich, Zeile 46-50), ActiveDirectoryAuthenticator, OpenIdConnectAuthenticator, WebAccountAuthenticator; TwoFactorAuthenticationBL (TOTP, Zeile 43-54), TwoFactorAuthBL (RADIUS, E-Mail-Link, Zeile 183-189); TicketAuthenticationHandler (src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs) schützt jede API-Anfrage.
|
||||
Aussage: Das System soll Benutzer über mehrere Verfahren (lokal, AD, OpenID Connect, Web-Konto) authentifizieren, optional mit Zwei-Faktor-Authentifizierung, und API-Zugriffe nur mit gültigem Ticket/Token zulassen.
|
||||
Ergebnis: Kein API-Zugriff ohne gültige Authentisierung; gesperrte Konten werden abgewiesen.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Logins\Auth\BasicAuthenticator.cs:46-50 – Passwortvergleich gegen SHA1-Hash (enthält ausdrücklichen TODO-Kommentar „password should be salted")
|
||||
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs:44-95 – Ticket/AccessToken-Prüfung vor jedem Aufruf
|
||||
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, `WebAccounts.UseTwoFactorAuthentication`, `LastTwoFactorValidatedAt`
|
||||
Prüfidee: Anmeldung mit falschem Kennwort schlägt fehl; 2FA-Pflichtkonto ohne PIN wird abgewiesen; API-Aufruf ohne Bearer-Ticket liefert 401.
|
||||
Tracelinks: StRS-012, StRS-021
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen; Passwort-Hash-Verfahren ist Workaround (SHA1 ohne Salt) → im Zielsystem durch Argon2/bcrypt ersetzen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-014
|
||||
Titel: Lizenzgerechte Systemnutzung
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Functional Suitability / Compliance
|
||||
Akteur: Betreiber, Lizenzverwalter
|
||||
Vorbedingung: Lizenz mit Anwendungskind und maximaler Nutzerzahl
|
||||
Fakt: `Authenticator.AuthenticateUser` (src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs:109-155) ruft `LicenseManager.CheckLicense(applicationKind, appVersion, userResult)` vor Ticketerstellung; `ApplicationKind.DisallowingRight/RequiredRight` schränken Anwendungen zusätzlich per Rechte ein.
|
||||
Aussage: Das System soll beim Login prüfen, ob für die Anwendung und Version eine Lizenz mit freiem Platz verfügbar ist, und sonst die Anmeldung verweigern.
|
||||
Ergebnis: Nutzerzahl pro Lizenz wird eingehalten; unbekannte Anwendungskennungen werden abgelehnt.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs:124-155 – Lizenzprüfung und Ticketerstellung inkl. Anwendungskind-Prüfung (Zeile 100-104)
|
||||
- [SEKUNDÄR] src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs:68-86 – Required/DisallowingRight je Anwendung
|
||||
Prüfidee: Bei erschöpfter Lizenz schlägt die Anmeldung des zusätzlichen Benutzers mit Lizenzfehler fehl; unbekannte ApplicationGuid wird abgelehnt.
|
||||
Tracelinks: StRS-013
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen (Lizenzmodell ggf. für SaaS anpassen)
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-015
|
||||
Titel: Termine, Aufgaben und persönlicher Arbeitsplatz
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Alle internen Benutzer
|
||||
Vorbedingung: Benutzer angemeldet
|
||||
Fakt: Kalenderrechte (CentronRights.md, Kalender: alle/eigene), MyCentron-Modul (src\centron\Centron.WPF.UI\Modules\MyCentron: Kalender, MyDay, TodoList, PersonalSettings, Telephony, Dashboard), `SchedulingBL`/`QuickNoteBL`/`DashboardContainerBL` (src\backend\Centron.BL\MyCentron\).
|
||||
Aussage: Das System soll jedem Benutzer einen persönlichen Arbeitsplatz mit Kalender, Tagesübersicht (MyDay), ToDos, Notizen, Telefonie-Integration und anpassbarem Dashboard bereitstellen, wobei Kalenderdaten personenbezogen begrenzt werden können.
|
||||
Ergebnis: Benutzer plant Termine und Aufgaben zentral und erhält Benachrichtigungen (→ SyRS-044).
|
||||
Belege:
|
||||
- [KONTEXT] CentronRights.md, Kalender-Abschnitt (RIGHT_KALENDERANZEIGENEIGENE) – geplante Sichtbarkeit
|
||||
- [PRIMÄR] src\backend\Centron.BL\MyCentron\DashboardContainerBL.cs – Dashboard-Container-Speicherung
|
||||
- [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\MyCentron – Modulaufbau
|
||||
Prüfidee: Benutzer mit „nur eigene Kalender" sieht fremde Termine nicht; MyDay listet Termine + offene ToDos des Tages.
|
||||
Tracelinks: StRS-016, StRS-006
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-016
|
||||
Titel: E-Mail-Kommunikation mit Vorlagen und Signaturen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Alle internen Benutzer, System (automatische Mails)
|
||||
Vorbedingung: Mailversand konfiguriert (SMTP/Exchange/Graph)
|
||||
Fakt: Mail-BL enthält SMTPMail.cs, ExchangeMail.cs, GraphMail.cs, MailTemplateBL (src\backend\Centron.BL\Mail\Templates\MailTemplateBL.cs), SignatureReplacementBL, DomainBlacklistBL, MailScanner (src\backend\Centron.BL\MailScanner\MailScannerBL.cs).
|
||||
Aussage: Das System soll E-Mails über mehrere Transportwege versenden, Text-/Mailvorlagen mit Platzhaltern nutzen, Signaturen automatisiert einsetzen und eingehende Mails erfassen/scannen können.
|
||||
Ergebnis: Konsistente, vorlagenbasierte Kommunikation aus Belegen, Tickets und Mahnwesen.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Mail\SMTPMail.cs, ExchangeMail.cs, GraphMail.cs – drei konkrete Transportimplementierungen
|
||||
- [PRIMÄR] src\backend\Centron.BL\Mail\DomainBlacklistBL.cs – Absender-/Domain-Blacklist
|
||||
- [SEKUNDÄR] src\backend\Centron.BL\Mail\Templates\MailTemplateBL.cs – Vorlagenverwaltung
|
||||
Prüfidee: Versand einer Ticketmail nutzt Vorlage + Signaturersatz; Adressen auf Blacklist werden abgewiesen; Exchange-Postfach scannt eingehende Mails.
|
||||
Tracelinks: StRS-006, StRS-004
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-017
|
||||
Titel: Dokumente revisionssicher ablegen und auffinden
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Alle internen Benutzer
|
||||
Vorbedingung: Dokumentenablage konfiguriert
|
||||
Fakt: Hintergrunddienste `DocumentFulltextIndexUpdateService`, `DocumentsCleanupService` (src\webservice\Centron.Host\AspNetCore\HostedServices\); CentronFileSystem (src\centron\Centron.WPF.UI\CentronFileSystem); Dokumentanhang an alle Belegarten (DocDirI3D in RechKopf).
|
||||
Aussage: Das System soll Dokumente versioniert an Belegen, Kunden und anderen Objekten ablegen, einen Volltextindex pflegen und veraltete Dokumente bereinigen.
|
||||
Ergebnis: Dokumente sind über Volltextsuche auffindbar; Ablage bleibt wartbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\HostedServices\DocumentFulltextIndexUpdateService.cs – periodische Indexpflege
|
||||
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\HostedServices\DocumentsCleanupService.cs – Bereinigungsdienst
|
||||
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, `RechKopf.DocDirI3D` – Dokumentenverzeichnis am Beleg
|
||||
Prüfidee: Nach Upload eines PDFs am Beleg ist dessen Text über die Volltextsuche auffindbar; Bereinigungsdienst entfernt testweise markierte Alt-Dokumente.
|
||||
Tracelinks: StRS-002, StRS-020
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-018
|
||||
Titel: Auswertungen für Steuerung und Abrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Leitung, Controlling, Serviceleitung
|
||||
Vorbedingung: Daten in Statistik-Caches aktualisiert
|
||||
Fakt: Statistics-BL (src\backend\Centron.BL\Statistics\): RevenueStatisticBL, EmployeeUtilizationBL, ContractEvaluationBL, MspStatisticBL, InvoiceStatisticBL, CacheSalesStatisticsBL, CacheOrderStatisticsBL; Cache-Tabelle `CacheTicketStatistic`; Arbeitnehmerauslastungsrechte (CentronRights.md, Mitarbeiterauslastung).
|
||||
Aussage: Das System soll Umsatz-, Auslastungs-, Vertrags- und Ticketstatistiken bereitstellen und Mitarbeiterauslastung nur nach Rechte sichtbar machen.
|
||||
Ergebnis: Managementauswertungen ohne manuelle Aufbereitung.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Statistics\EmployeeUtilizationBL.cs – Auslastungsberechnung
|
||||
- [PRIMÄR] SSMS_DB_SCHEMA.sql, Tabelle `CacheTicketStatistic`
|
||||
- [KONTEXT] CentronRights.md, Mitarbeiterauslastung – „nur eigene Filiale" als einschränkendes Recht
|
||||
Prüfidee: Monatsauswertung Umsatz deckt sich mit Rechnungssummen; Auslastung eines Mitarbeiters ohne Recht für andere wird nicht angezeigt.
|
||||
Tracelinks: StRS-003, StRS-006
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-019
|
||||
Titel: Beleg- und Listenberichte erzeugen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Alle internen Benutzer, Druckserver
|
||||
Vorbedingung: Berichtsvorlagen definiert (ReportGroup)
|
||||
Fakt: ReportEngine (src\backend\Centron.BL\ReportEngine\): FastReportHelper, PdfStrategies (FastReport, PdfCreator, SevenPdf), ReceiptToReportObjectMap, ReportGroupBL; ReceiptBL erzeugt Beleg-PDFs inkl. Signatur (ReceiptBL.cs:3199-3361).
|
||||
Aussage: Das System soll Belege (Rechnungen, Lieferscheine, Tickets) und Listen als PDF mit konfigurierbaren Vorlagen erzeugen, zusammenführen, digital signieren und drucken können.
|
||||
Ergebnis: Vorlagengetreue Belegausgabe; Signaturpfad optional.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:3199-3361 – PDF-Erzeugung, Merge, Signatur am Beleg
|
||||
- [PRIMÄR] src\backend\Centron.BL\ReportEngine\PdfStrategies.cs – Strategieauswahl (FastReport/PdfCreator/SevenPdf)
|
||||
- [SEKUNDÄR] src\backend\Centron.BL\ReportEngine\ReceiptToReportObjectMap.cs – Datenabbildung Beleg→Bericht
|
||||
Prüfidee: Rechnung mit Vorlage X erzeugt PDF mit Berichtsgruppe und Pflichtfeldern; Signaturdienst erzeugt signiertes PDF.
|
||||
Tracelinks: StRS-002, StRS-026
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-020
|
||||
Titel: Datenschutzkonforme Datenhaltung (DSGVO)
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Security
|
||||
Akteur: Datenschutzbeauftragter, Administrator
|
||||
Vorbedingung: DSGVO-Modul verfügbar und Rechte gesetzt
|
||||
Fakt: `DataSecurityBL` (src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs:36-66, 379, 789) prüft ACCESS_CLEANUP_DATABASE bzw. DSGVO_DELETE_CONTACT vor Bereinigung/Kontaktlöschung; Modul „DSGVO" in Verwaltung (src\centron\Centron.WPF.UI\Modules\Administration\DSGVO).
|
||||
Aussage: Das System soll personenbezogene Daten auf Antrag bereinigen oder anonymisieren können (Kontaktlöschung, Datenbank-Cleanup), wobei die Funktionen rechtegesichert sind.
|
||||
Ergebnis: Lösch-/Bereinigungsvorgänge nur durch berechtigte Rollen; gelöschte Kontakte sind in Adressbelegen nicht mehr identifizierbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs:36-66 – Zugriffsrechte ACCESS_CLEANUP_DATABASE + Featureflag `ModuleFeatures.IsDsgvoDatabaseCleanupAvailable`
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs:379 – Prüfung DSGVO_DELETE_CONTACT vor Kontaktlöschung
|
||||
- [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Administration\DSGVO – Verwaltungs-UI
|
||||
Prüfidee: Kontaktlöschung ohne Recht schlägt fehl; mit Recht werden Bezugsdatensätze (Belege, Mails) anonymisiert und Protokoll geschrieben.
|
||||
Tracelinks: StRS-012, StRS-041→SyRS-041
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-021
|
||||
Titel: Selbstservice-Kundencenter im Web
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Endkunden (Web-Konto), Vertrieb
|
||||
Vorbedingung: Web-Konto im Adressstamm angelegt
|
||||
Fakt: Nexus-WebApp (src\nexus\CentronNexus): WebCart (Shop, Warenkorb, Tickets), ReceiptsOverview/ReceiptDetailsOverview, CustomerTicketDetailsPage, DocumentSigningPage (SignaturePad), WebOffer; README.md (WebCart für Kunden der Kunden, Artikel aus „Sonderpreise"); WebAccountAuthenticator ordnet Web-Konto einem gemeinsamen AppUser zu.
|
||||
Aussage: Das System soll Kunden über ein Web-Portal Zugriff auf eigene Belege, Tickets, Angebote und einen Artikel-Shop (WebCart) geben, inklusive digitaler Dokumentenunterschrift.
|
||||
Ergebnis: Kunden beziehen Artikel und Informationen selbstständig; Rückläufer (Unterschriften) laufen digital zurück.
|
||||
Belege:
|
||||
- [KONTEXT] README.md, Abschnitt Contributing/WebCart – Zielgruppe und Preisquelle „Sonderpreise"
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Logins\Auth\WebAccountAuthenticator.cs:42-83 – Web-Konto-Anmeldung mit 2FA und Zuordnung zum AppUser
|
||||
- [PRIMÄR] src\nexus\CentronNexus\DocumentSigning\DocumentSigningPage.razor – Unterschriftenfunktion
|
||||
Prüfidee: Web-Konto-Login zeigt nur Belege des zugeordneten Kunden; Warenkorb mit Sonderpreisen erzeugt Ticket/Bestellung; unterschriebenes Dokument ist am Beleg abgelegt.
|
||||
Tracelinks: StRS-013, StRS-006
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-022
|
||||
Titel: Produktion und Qualitätssicherung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Fertigungsleitung, QM-Verantwortliche
|
||||
Vorbedingung: Stücklisten/Artikel angelegt
|
||||
Fakt: ProductionOrderBL (src\backend\Centron.BL\Production\ProductionOrderBL.cs:17-122) verwaltet Fertigungsaufträge und -positionen; QM-Einstellungen (src\centron\Centron.WPF.UI\Modules\QM: QmSettingsView, AssetReasonSettingsView); InvoiceSpecificLogic.GetReceiptReasonQmMessageSetting (src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:317-322) koppelt QM-Hinweise an Beleggründe.
|
||||
Aussage: Das System soll Fertigungsaufträge mit Positionen verwalten und Qualitätsmerkmale (Prüfgründe, QM-Hinweise an Belegen) konfigurierbar abbilden.
|
||||
Ergebnis: Fertigungs-/Prüfprozesse sind im ERP nachvollziehbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Production\ProductionOrderBL.cs:35-122 – Laden/Speichern von Fertigungsaufträgen und -positionen
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:317-322 – QM-Grundeinstellung je Belegart
|
||||
- [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\QM\QmSettingsView.xaml – Einstellungs-UI
|
||||
Prüfidee: Fertigungsauftrag mit Positionen anlegen und abschließen; Beleggrund mit QM-Bezug erzeugt QM-Hinweis.
|
||||
Tracelinks: StRS-008
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-023
|
||||
Titel: Rücksendungen (RMA) verfolgen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Service, Lager, Kunde
|
||||
Vorbedingung: Artikel/Ticket vorhanden
|
||||
Fakt: RmaBL (src\backend\Centron.BL\CustomerArea\RmaBL.cs:81-603): GetNewRma, SaveRma, GetRmaByHelpdeskI3D, CreateNewRmaArticle, ArticleRmaHistory; RMA-UI (src\centron\Centron.WPF.UI\Modules\Rma) mit SendOverview und Artikel-Selbstauswahl; Tabelle `Rma`.
|
||||
Aussage: Das System soll Rücksendungen als RMA-Scheine mit Artikelpositionen, Sendart und Historie verwalten und mit Tickets und Artikeln verknüpfen.
|
||||
Ergebnis: Rückläufer sind je Artikel/Ticket historisiert.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\CustomerArea\RmaBL.cs:347-603 – Speichern, Suche nach Ticket, Artikelhistorie
|
||||
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabelle `Rma`
|
||||
- [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Rma\RmaSendOverviewView.xaml – Sendart-Übersicht
|
||||
Prüfidee: RMA vom Ticket anlegen; Artikelposition mit Seriennummer historisiert; Sendart veränderbar.
|
||||
Tracelinks: StRS-006, StRS-008
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-024
|
||||
Titel: Integrationen, Automatisierung und Verwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Administrator, Integrationspartner
|
||||
Vorbedingung: System installiert
|
||||
Fakt: Zentrale Verwaltung (src\centron\Centron.WPF.UI\Modules\Administration: MandatorManagement, CountryManagement, RightsManagement, SqlManagers, PdfSigning, EscalationsSettings, …); Hintergrunddienste-Katalog (src\webservice\Centron.Host\AspNetCore\HostedServices, u. a. CTimeConnectorService, ExchangeSyncService, PlmImportService, GfkExportService); externe Datenquellen (src\apis: ITscope, Icecat, Cop, Egis), KI-Chat (src\backend\Centron.BL\Administration\ArtificialIntelligence), TelekomDive.
|
||||
Aussage: Das System soll zentrale Verwaltung (Mandanten, Länder, Rechte, SQL-Werkzeuge, PDF-Signatur, Eskalationen) sowie automatisierte Synchronisationen und Imports aus externen Datenquellen bereitstellen und einen KI-Chat auf Systemdaten anbieten.
|
||||
Ergebnis: Betriebs- und Integrationsaufgaben sind ohne Datenbankzugriff über die Anwendung ausführbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\HostedServices – Katalog automatisierter Dienste (ExchangeSyncService, PlmImportService, CTimeConnectorService, …)
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\ArtificialIntelligence\Chat\ArtificialIntelligenceChatInstructionPromptBL.cs:314 – KI-Chat nur mit Recht Administration.SETTINGS
|
||||
- [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Administration – Verwaltungsmodule
|
||||
Prüfidee: Exchangesync und PLM-Import laufen nach Zeitplan; KI-Chat für Benutzer ohne Administration.SETTINGS gesperrt.
|
||||
Tracelinks: StRS-012, StRS-013
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen; einzelne Alt-Integrationen als `veraltet` prüfen
|
||||
Status: belegt
|
||||
+1265
File diff suppressed because it is too large
Load Diff
+1030
File diff suppressed because it is too large
Load Diff
+88
@@ -0,0 +1,88 @@
|
||||
# Traceability
|
||||
|
||||
Konsolidierte Trace-Matrix: StRS → SyRS → SwRS → Haupt-Artefaktbeleg.
|
||||
Jede Zeile entspricht einer SwRS-Anforderung (oder einer SyRS-Anforderung ohne SwRS-Kind, dort `—`).
|
||||
Alle referenzierten IDs existieren in StRS.md / SyRS.md / SwRS.md.
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Haupt-Artefaktbeleg |
|
||||
|---|---|---|---|
|
||||
| StRS-024, StRS-001 | SyRS-001 | SwRS-051 | src\nexus\CentronNexus.OutlookAddIn |
|
||||
| StRS-024, StRS-001 | SyRS-001 | SwRS-053 | tests\Centron.Tests.EndToEnd |
|
||||
| StRS-013 | SyRS-002 | SwRS-036 | src\backend\Centron.BL\Administration\AccessTokens\AccessTokenBL.cs:377-486 |
|
||||
| StRS-013, StRS-014 | SyRS-003 | SwRS-035 | src\backend\Centron.BL\Administration\Logins\TicketBL.cs:32-129 |
|
||||
| StRS-014 | SyRS-004 | — | src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs:100-155 |
|
||||
| StRS-012 | SyRS-005 | SwRS-032 | src\webservice\...\Rights\UserRightsConst.cs |
|
||||
| StRS-012 | SyRS-005 | SwRS-033 | src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:63-87 |
|
||||
| StRS-012 | SyRS-005 | SwRS-008 | src\backend\Centron.BL\Accounts\AccountBL.cs:1299-1370 |
|
||||
| StRS-012 | SyRS-005 | SwRS-003 | src\backend\Centron.BL\Accounting\BankAccountBL.cs:72-81 |
|
||||
| StRS-012 | SyRS-005 | SwRS-003 | src\backend\Centron.BL\Accounting\BankAccountBL.cs:72-81 |
|
||||
| StRS-012, StRS-011 | SyRS-006 | SwRS-002 | src\backend\Centron.BL\Accounts\AccountSearchBL.cs:76, 331 |
|
||||
| StRS-012 | SyRS-005 | SwRS-015 | src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskTimerWebServiceBL.cs:359-374 |
|
||||
| StRS-013 | SyRS-007 | SwRS-034 | src\backend\Centron.BL\Administration\Logins\Auth\BasicAuthenticator.cs:35-71 |
|
||||
| StRS-013, StRS-021 | SyRS-008 | SwRS-034 | src\backend\Centron.BL\TwoFactorAuthenticator\TwoFactorAuthenticationBL.cs:43-54 |
|
||||
| StRS-021, StRS-013 | SyRS-009 | SwRS-048 | README.md (WebCart/Sonderpreise) – HYPOTHESE |
|
||||
| StRS-021, StRS-013 | SyRS-009 | SwRS-049 | src\nexus\CentronNexus\DocumentSigning\IsolatedSignaturePad.razor |
|
||||
| StRS-003 | SyRS-010 | SwRS-005 | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:114-131 |
|
||||
| StRS-003, StRS-011 | SyRS-010 | SwRS-038 | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:154-197 |
|
||||
| StRS-002 | SyRS-011 | — | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:3082-3096 (Lock) |
|
||||
| StRS-002 | SyRS-012 | — | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:6216 (CreateNewVersion) |
|
||||
| StRS-002 | SyRS-013 | SwRS-011 | src\backend\Centron.DAO\Repositories\Sales\Receipts\ContractList\SaveReceiptContractRepository.cs:364-365 |
|
||||
| StRS-003, StRS-008 | SyRS-014 | SwRS-006 | src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:216-368 |
|
||||
| StRS-003, StRS-012 | SyRS-014 | SwRS-007 | src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:239-240 |
|
||||
| StRS-008 | SyRS-014 | SwRS-021 | src\backend\Centron.BL\Warehousing\InventoryManagement\InventoryNewBL.cs:30-207 |
|
||||
| StRS-004 | SyRS-015 | SwRS-009 | src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningBL.cs:341-456, 1059 |
|
||||
| StRS-004 | SyRS-016 | SwRS-010 | src\backend\Centron.BL\Sales\Receipts\Invoices\Opos\OposBL.cs:28; SSMS_DB_SCHEMA.sql RechKopf.Bezahlt |
|
||||
| StRS-005 | SyRS-017 | SwRS-011 | src\webservice\Centron.Host\AspNetCore\HostedServices\ContractEndeService.cs:8-16 |
|
||||
| StRS-005 | SyRS-018 | SwRS-012 | src\backend\Centron.BL\Sales\CustomerAssets\Contracts\ClickContracts\DeviceClickCounterBL.cs:30-128 |
|
||||
| StRS-006 | SyRS-019 | SwRS-013 | SSMS_DB_SCHEMA.sql (hlpdsk_*), AccountDevicesToTickets |
|
||||
| StRS-006 | SyRS-019 | SwRS-016 | src\backend\Centron.BL\CheckListArea |
|
||||
| StRS-006 | SyRS-019 | SwRS-017 | src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskPatternWebserviceBL.cs:351-395 |
|
||||
| StRS-006, StRS-021 | SyRS-020 | — | src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:120-200 |
|
||||
| StRS-006 | SyRS-021 | — | src\webservice\Centron.Host\AspNetCore\HostedServices\EscalationsService.cs |
|
||||
| StRS-007, StRS-012 | SyRS-022 | SwRS-014 | src\backend\Centron.BL\Sales\Support\HelpdeskTimerArticleBookingBL.cs |
|
||||
| StRS-003 | SyRS-023 | SwRS-018 | src\backend\Centron.BL\Warehousing\TaxBL.cs:239-284 |
|
||||
| StRS-003 | SyRS-023 | SwRS-019 | src\backend\Centron.BL\Warehousing\TaxBL.cs:207-237, 286-320 |
|
||||
| StRS-003 | SyRS-023 | SwRS-020 | src\backend\Centron.BL\Warehousing\TaxBL.cs:84-156 |
|
||||
| StRS-008, StRS-005 | SyRS-024 | SwRS-022 | src\backend\Centron.Entities\Entities\Warehousing\BarCode.cs:100; BarcodeState.cs:19 |
|
||||
| StRS-009 | SyRS-025 | SwRS-023 | src\backend\Centron.BL\EDI\EDIDispatcherBL.cs; EDIGatewayLogBL.cs |
|
||||
| StRS-003, StRS-010 | SyRS-026 | SwRS-024 | src\backend\Centron.BL\DataExchange\InvoiceZugferdBL.cs; XInvoiceVersion3.cs |
|
||||
| StRS-010 | SyRS-027 | SwRS-025 | src\backend\Centron.Gateway\IBookKeepingExport.cs; BookKeepingExportDatevAscii.cs |
|
||||
| StRS-002 | SyRS-028 | SwRS-026 | src\apis\Centron.Api.Shipcloud; src\apis\Centron.Api.Gls |
|
||||
| StRS-008, StRS-024 | SyRS-029 | SwRS-052 | src\backend\Centron.BL\DataExchange\HPQuoteImportBL.cs; src\apis\Centron.APIs.ITscopeDataAccess |
|
||||
| StRS-008, StRS-024 | SyRS-029 | SwRS-059 | SSMS_DB_SCHEMA.sql (SocialMedia*); VoucherManagementBL.cs:17 |
|
||||
| StRS-004 | SyRS-030 | SwRS-027 | src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingFinApiBL.cs; src\apis\Centron.APIs.FinAPI |
|
||||
| StRS-016 | SyRS-031 | SwRS-028 | src\backend\Centron.BL\Mail\CentronMailFactory.cs; DomainBlacklistBL.cs |
|
||||
| StRS-016 | SyRS-031 | SwRS-029 | src\backend\Centron.BL\Mail\SignatureReplacementBL.cs |
|
||||
| StRS-015 | SyRS-032 | SwRS-030 | src\backend\Centron.BL\Calendar\CalendarBL.cs:31-132 |
|
||||
| StRS-017 | SyRS-033 | SwRS-056 | src\centron\Centron.WPF.UI\CentronFileSystem; AddDocumentToDirectoryRequest.cs |
|
||||
| StRS-019 | SyRS-034 | SwRS-042 | src\backend\Centron.BL\ReportEngine\PdfStrategies.cs; ReceiptToReportObjectMap.cs |
|
||||
| StRS-018 | SyRS-035 | SwRS-041 | SSMS_DB_SCHEMA.sql (CacheTicketStatistic); CacheUpdateService.cs |
|
||||
| StRS-024, StRS-005 | SyRS-036 | — | src\webservice\Centron.Host\AspNetCore\HostedServices (Dienstekatalog) |
|
||||
| StRS-015, StRS-021 | SyRS-037 | SwRS-050 | src\nexus\CentronNexus\ServiceBoard\CachedKanbanBoard.razor |
|
||||
| StRS-024 | SyRS-038 | SwRS-057 | src\centron\Centron.WPF.UI\Resources\LocalizedStrings.en.resx |
|
||||
| StRS-001, StRS-003 | SyRS-039 | SwRS-001 | SSMS_DB_SCHEMA.sql (Kunden/Kreditor/Anschrif/Personen) |
|
||||
| StRS-001, StRS-003 | SyRS-039 | SwRS-004 | SSMS_DB_SCHEMA.sql (RechKopf) |
|
||||
| StRS-001, StRS-003 | SyRS-039 | SwRS-037 | SSMS_DB_SCHEMA.sql (ApplicationSettings); AppSettingsConst.cs |
|
||||
| StRS-001, StRS-003 | SyRS-039 | SwRS-058 | src\centron\Centron.WPF.UI\Modules\Global\CustomPropertiesConnector.cs |
|
||||
| StRS-020 | SyRS-040 | SwRS-039 | src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs:36-66, 379 |
|
||||
| StRS-020, StRS-012 | SyRS-041 | SwRS-031 | src\backend\Centron.BL\PasswordManagementArea\PasswordManagementKeywordBL.cs:21-27 |
|
||||
| StRS-020, StRS-012 | SyRS-041 | SwRS-040 | src\backend\Centron.BL\Devices\AccountDeviceBL.cs:33-53; SSMS_DB_SCHEMA.sql (WebAccounts) |
|
||||
| StRS-024 | SyRS-042 | SwRS-054 | scripts\RunHelper.cs; docs\guides\database\create-scripts.md |
|
||||
| StRS-024 | SyRS-042 | SwRS-055 | deployment\CentronSetupProject.wixproj; docker\compose.yaml |
|
||||
| StRS-011 | SyRS-043 | SwRS-005 | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:136-152 |
|
||||
| StRS-011 | SyRS-043 | SwRS-038 | src\backend\Centron.DAO\Mappings\Administration\Company\NumberGroupMaps.cs |
|
||||
| StRS-015 | SyRS-044 | SwRS-044 | src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:134; TodoService.cs |
|
||||
| StRS-015 | SyRS-044 | SwRS-045 | src\webservice\Centron.Host\AspNetCore\HostedServices\SendEmailForUnreadMessagesService.cs |
|
||||
| StRS-024 | SyRS-045 | SwRS-046 | src\backend\Centron.BL\Administration\ArtificialIntelligence\Chat\ArtificialIntelligenceChatInstructionPromptBL.cs:314 |
|
||||
| StRS-022 | SyRS-046 | SwRS-043 | src\backend\Centron.BL\Production\ProductionOrderBL.cs:25-122 |
|
||||
| StRS-023 | SyRS-047 | SwRS-047 | src\backend\Centron.BL\CustomerArea\RmaBL.cs:347-603 |
|
||||
|
||||
## Konsolidierungskandidaten (fachlich gleichartige Konzepte in getrennten Implementierungen)
|
||||
|
||||
| Kandidat | Beteiligte IDs | Befund |
|
||||
|---|---|---|
|
||||
| Gerätedaten-Streuhaltung („Stammblätter" vs. Geräte-/Zählerdaten) | SwRS-012, SwRS-022, SyRS-018, SyRS-024 | Drucker/Messgeräte werden als Stammblatt (MasterDataList) mit Zählern (DeviceClickCounter/DeviceClickCounterImported/SNMP) geführt, andere Geräte als AccountDevices/AssetManagementDevices; Barcode kennt eigenen Zustand „in Stammblatt". Im Zielsystem zu einem Asset-Konzept mit Zähler-/Statusdimension zusammenführen. |
|
||||
| FiBu-Exportformate | SwRS-025, SyRS-027 | ~20 Einzelklassen mit gleicher Aufgabe (Belege→Zielsystem-Datei); im Zielsystem auf einheitliches Mapping-Modell reduzieren. |
|
||||
| Nummernvergabe mit ID-Sonderfällen | SwRS-005, SwRS-038 | Nummernkreise prüfen gegen Zieltabellen inkl. Kunden/Kreditor-I3D; im Zielsystem durch DB-Sequenz/Constraint ersetzen. |
|
||||
| Vertragskennzeichnung über ExtraKind-Magic-Values | SwRS-011 | `ExtraKind == 1/3` → Stammblattbezogen; im Zielsystem durch explizite Vertragsart ersetzen. |
|
||||
| Authentifizierungsvarianten | SwRS-034, SwRS-036, SyRS-008 | Basic (SHA1), AD, OIDC, WebAccount + 2FA-Varianten; im Zielsystem auf OIDC/OAuth2 plus standardisierten MFA-Dienst konsolidieren. |
|
||||
+381
File diff suppressed because one or more lines are too long
+126
@@ -0,0 +1,126 @@
|
||||
# Messprotokoll – Iteration 16/z-ai/glm-5.3-flash/solo/max
|
||||
|
||||
> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
|
||||
> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `03_Prompt.md`
|
||||
- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
|
||||
- **Startzeit:** 2026-09-03T09:01:21.5727980+02:00
|
||||
- **Endzeit:** 2026-09-03T09:29:54.4711449+02:00
|
||||
- **Dauer gesamt:** 00:28:28 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
|
||||
- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
|
||||
- **Codebasis-Commit:** `e2c3a0e8f81d005161dde733f7e4b08f581e3468` (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:** `max` angefordert, **wirksam** (`effort_applied: true`)
|
||||
- **Ablage:** `Iteration 16/z-ai/glm-5.3-flash/solo/max/`
|
||||
- **Agentenmodus:** `solo`
|
||||
- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
|
||||
- **Sampling-Parameter:** nicht steuerbar
|
||||
- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
|
||||
- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
|
||||
- **Subagenten:** `spawned` = 0, `completed` = 0, `failed` = 0
|
||||
- **Rollen:** {}
|
||||
|
||||
## Validierungsstichprobe
|
||||
- **Stand:** entfaellt
|
||||
|
||||
## Verbrauch
|
||||
|
||||
| Messgroesse | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 2.930.859 |
|
||||
| Output-Tokens | 96.752 |
|
||||
| Reasoning-Tokens | 45.229 |
|
||||
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Agent-Turns | 108 |
|
||||
|
||||
**Tokens gesamt: 10.220.040.** 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 | 24 | 18,5 % |
|
||||
| SyRS | 47 | 36,2 % |
|
||||
| SwRS | 59 | 45,4 % |
|
||||
| **Gesamt** | **130** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 60 | 46,2 % |
|
||||
| Sicherheit | 23 | 17,7 % |
|
||||
| Daten | 19 | 14,6 % |
|
||||
| Schnittstelle | 17 | 13,1 % |
|
||||
| nicht-funktional | 11 | 8,5 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 346 |
|
||||
| davon `PRIMÄR` | 233 (67,3 %) |
|
||||
| davon `SEKUNDÄR` | 84 (24,3 %) |
|
||||
| davon `KONTEXT` | 29 (8,4 %) |
|
||||
| Belege je Anforderung (Median) | 3,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 129 (99,2 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 124 | 95,4 % |
|
||||
| workaround | 5 | 3,8 % |
|
||||
| sonderfall | 1 | 0,8 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 129 | 99,2 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 1 | 0,8 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 8 | 6,2 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 37 | 28,5 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (41 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 130 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 130 von 130 mit Tracelinks (100,0 %) |
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
|
||||
- **Session-ID:** `ses_f99ed7003ffeeUQm86XBQsMt1H`
|
||||
- **Werkzeugaufrufe:** 156 – {"bash": 111, "read": 17, "grep": 6, "glob": 1, "write": 7, "edit": 14}
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – korrekt fuer solo
|
||||
- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
|
||||
- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
|
||||
- **Root unveraendert:** ja
|
||||
- **Fehlermeldungen:** []
|
||||
|
||||
## Anmerkungen/Auffaelligkeiten
|
||||
|
||||
*(von Hand zu ergaenzen)*
|
||||
+1512
File diff suppressed because one or more lines are too long
+5
@@ -0,0 +1,5 @@
|
||||
[2026-09-03T07:01:23.272704+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\Ergebnisse)
|
||||
[2026-09-03T07:01:23.411046+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=solo; Effort=max (uebergeben=True); Stall-Timeout=0s
|
||||
[2026-09-03T07:29:52.324136+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-03T07:29:54.422734+00:00] OpenCode export: Exporting session: ses_f99ed7003ffeeUQm86XBQsMt1H
|
||||
[2026-09-03T07:29:54.453699+00:00] Ende: Exitcode=0; Status=success; Turns=108; Tokens=10220040; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+2688
File diff suppressed because it is too large
Load Diff
+64
@@ -0,0 +1,64 @@
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
|
||||
|
||||
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
|
||||
|
||||
### Verteilung über die Ebenen
|
||||
|
||||
| Ebene | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| StRS | 24 | 18,5 % |
|
||||
| SyRS | 47 | 36,2 % |
|
||||
| SwRS | 59 | 45,4 % |
|
||||
| **Gesamt** | **130** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 60 | 46,2 % |
|
||||
| Sicherheit | 23 | 17,7 % |
|
||||
| Daten | 19 | 14,6 % |
|
||||
| Schnittstelle | 17 | 13,1 % |
|
||||
| nicht-funktional | 11 | 8,5 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 346 |
|
||||
| davon `PRIMÄR` | 233 (67,3 %) |
|
||||
| davon `SEKUNDÄR` | 84 (24,3 %) |
|
||||
| davon `KONTEXT` | 29 (8,4 %) |
|
||||
| Belege je Anforderung (Median) | 3,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 129 (99,2 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 124 | 95,4 % |
|
||||
| workaround | 5 | 3,8 % |
|
||||
| sonderfall | 1 | 0,8 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 129 | 99,2 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 1 | 0,8 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 8 | 6,2 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 37 | 28,5 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (41 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 130 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 130 von 130 mit Tracelinks (100,0 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+174
@@ -0,0 +1,174 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## Prompt
|
||||
|
||||
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||
|
||||
### Auftrag
|
||||
|
||||
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||
|
||||
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||
|
||||
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||
|
||||
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||
|
||||
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### Vorgehen (statische Analyse, keine Ausführung)
|
||||
|
||||
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
|
||||
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
|
||||
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
|
||||
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
|
||||
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
|
||||
|
||||
### Pflicht-Eigenschaften jeder Anforderung
|
||||
|
||||
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
|
||||
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **Belegklassifikation:** Kennzeichne jeden Beleg als
|
||||
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
|
||||
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
|
||||
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
|
||||
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
|
||||
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
|
||||
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
|
||||
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
Akteur: <Rolle / System / Komponente>
|
||||
Vorbedingung: <Zustand vor Auslösen>
|
||||
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
|
||||
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
|
||||
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
|
||||
Belege:
|
||||
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
|
||||
- [SEKUNDÄR] <...> - Begründung: <...>
|
||||
- [KONTEXT] <...> - Begründung: <...>
|
||||
Prüfidee: <Akzeptanzkriterium oder Testidee>
|
||||
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
|
||||
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
|
||||
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
|
||||
Status: <belegt | HYPOTHESE>
|
||||
```
|
||||
|
||||
### Traceability
|
||||
|
||||
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
|
||||
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
|
||||
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
|
||||
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
|
||||
|
||||
### Nicht-funktionale Anforderungen
|
||||
|
||||
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
|
||||
|
||||
### Konsolidierungsbedarf
|
||||
|
||||
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
Ergebnisse/
|
||||
StRS.md
|
||||
SyRS.md
|
||||
SwRS.md
|
||||
Traceability.md (oder Traceability.csv)
|
||||
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
|
||||
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
|
||||
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
|
||||
|
||||
### Randbedingungen
|
||||
|
||||
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
|
||||
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
|
||||
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
|
||||
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
### Abschluss
|
||||
|
||||
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
|
||||
- Doppelte oder mehrfach vergebene IDs
|
||||
- Anforderungen ohne Beleg
|
||||
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen sowie das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis.
|
||||
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver,
|
||||
Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-09-03T09:29:54.4711449+02:00
|
||||
+230
@@ -0,0 +1,230 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"tensorx": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "TensorX",
|
||||
"options": {
|
||||
"baseURL": "https://api.tensorx.ai/v1"
|
||||
},
|
||||
"models": {
|
||||
"qwen/qwen3.8-flash-next": {
|
||||
"name": "Qwen 3.8 Flash Next",
|
||||
"limit": {
|
||||
"context": 262144,
|
||||
"output": 131072
|
||||
},
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"z-ai/glm-5.2": {
|
||||
"name": "GLM 5.2",
|
||||
"limit": {
|
||||
"context": 1048576,
|
||||
"output": 131072
|
||||
},
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"z-ai/glm-5.3-flash": {
|
||||
"name": "GLM 5.3 Flash",
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"moonshotai/kimi-k3": {
|
||||
"name": "Kimi K3",
|
||||
"limit": {
|
||||
"context": 1048576,
|
||||
"output": 131072
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "tensorx/z-ai/glm-5.3-flash",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
},
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "tensorx/z-ai/glm-5.3-flash",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "tensorx/z-ai/glm-5.3-flash",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "tensorx/z-ai/glm-5.3-flash",
|
||||
"mode": "subagent"
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+11984
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
2026-09-03T09:01:21.5727980+02:00
|
||||
Reference in New Issue
Block a user