Iteration 3: Modell- und Modusraster erweitert, Skill 7.0.0, V2/V3 vorbereitet

Neue gueltige Zellen in Iteration 3
- claude-opus-5/solo/high: 363 Anforderungen, 99,7 % mit Primaerbeleg,
  Belege je Anforderung Median 2,0, 38,1 Mio. Tokens
- claude-fable-5/solo/high: 241 Anforderungen, 98,3 % mit Primaerbeleg,
  89,0 % PRIMAER-Anteil, vollstaendig regelkonform, 30,6 Mio. Tokens

Damit sind 6 von 12 Zellen des Rasters belegt. Zwei Befunde daraus:

Die Belegdichte folgt dem Modell, nicht dem Effort. Opus erreicht Median 2,0
auch auf high; alle 44 Sonnet-Laeufe lagen bei 1,0. max hebt Opus auf 3,0.
Die frueher dem Effort zugeschriebene Verdopplung ist damit eingegrenzt.

Die Fable-Modellverletzung ist reproduziert und abgegrenzt. Bei builtin laufen
die Subagenten auf claude-opus-5[1m] statt Fable (zweiter Fall nach Iteration 1),
bei solo dagegen sauber. Nicht das Modell ist die Ursache, sondern Fable in
Kombination mit Delegation.

Fehlmessungen, vollstaendig protokolliert
- vier 429-Abbrueche (Session-Kontingent) aus dem Parallelblock 19:59;
  drei davon mit Teilbestand, einer ohne Ergebnis
- opus-5/builtin/high zum dritten Mal gescheitert: 790,7 Mio. Tokens ueber drei
  Anlaeufe ohne Artefakt. Zelle mit dieser Prompt-Version nicht messbar.

Skill 7.0.0 (MAJOR)
- Isolationsmechanismus modusabhaengig: --safe-mode schaltet MCP-Server und
  Custom-Agenten ab und ist mit V2/V3 unvereinbar. Smoke-Test verifiziert:
  mit Flag spawned=0, ohne Flag spawned=2. Ersatz fuer custom/MCP:
  --strict-mcp-config plus --disallowedTools Skill WebSearch WebFetch SlashCommand.
- 6.1.0: Pflichtpruefung leeres Ergebnisverzeichnis = Fehlmessung unabhaengig von
  is_error; CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0; Protokollfeld Gueltigkeit
- extract-subagenten.py: Start-Quittung wird nicht mehr als Ertragsmass ausgewiesen

Versuch 2 und 3 vorbereitet
- Prompt-Kette V1 -> V2 (02-A, angepasst an Agentendateien) -> V3 (02-B, MCP)
- V2: acht Rollen inkl. nicht delegierendem ISO-29148-Orchestrator
- V3: elf Rollen, fuenf Werkzeugserver, neue Belegklasse LAUFZEIT

Ablaufprotokoll um Phase 6 und 7 sowie die Vorbereitung von V2/V3 ergaenzt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Christoph Schwörer
2026-08-27 08:03:00 +02:00
co-authored by Claude Opus 5
parent affde3a45f
commit 3d5b691bfa
89 changed files with 39498 additions and 104 deletions
@@ -0,0 +1,252 @@
# Analysebericht — Reverse Requirements Engineering c-entron ERP-Suite
**Lauf:** V1 Baseline (Prompt-only), Iteration 02 — 2026-08-26
**Untersuchungsgegenstand:** Gesamte Codebasis unter `C:\DEV\MasterArbeit\QuellCode\CentronERP` (nur lesend analysiert)
**Methode:** Statische Analyse entlang der RRE-Methodenkette (Schritte 0, 0b, 0c, 2–6); keine Ausführung des Systems.
## Überblick über den Untersuchungsgegenstand
Die c-entron ERP-Suite ist ein ERP-/Servicemanagement-System für IT-Systemhäuser (deutschsprachiger Markt) mit:
- **WPF-Desktop-Client** (`src\centron\Centron.WPF.UI`, ~29 Fachmodule) — „c-entron.NET"
- **Backend-Geschäftslogik** (`src\backend\Centron.BL`, >80 Fachbereiche) mit NHibernate-Datenzugriff (`Centron.DAO`, `Centron.Entities`)
- **REST-Webservice** (`src\webservice\Centron.Host`, `Centron.Controllers`, `Centron.WebServices.Core`) — der WPF-Client arbeitet wahlweise direkt gegen SQL Server oder über den Webservice (Dual-Architektur `BLLogic`/`WSLogic`, siehe `docs\getting-started\general-structure.md`)
- **Blazor-Web-App „c-entron Nexus"** (`src\nexus\CentronNexus`) mit ServiceBoard (Ticket-Arbeitsplatz), WebCart-Kundenportal, WebOffer, Office, DocumentSigning, ProductionOrderManagement sowie ein **Outlook-Add-In**
- **Externe API-Integrationen** (`src\apis`, `Centron.Api.docuFORM`): ITscope, COP, EGIS, Icecat, finAPI, GLS, Shipcloud, ebInterface, docuFORM
- **MSSQL-Datenbank**: Schema-Dump `SSMS_DB_SCHEMA.sql` mit 1.535 `CREATE TABLE`-Anweisungen (Legacy-Tabellen mit deutschen Namen, z. B. `AngKopf`/`AufKopf`/`RechKopf`, plus englischsprachige Views)
- **Entwicklerdokumentation** (`docs\`) — dient als KONTEXT-Beleg (u. a. `CentronRights.md`, `docs\reference\receipts\*`, `docs\reference\security\*`)
- **Deployment**: WiX-Installer (`deployment\`), Docker/Linux-Betrieb des Webservice (`docker\`), Azure-Pipelines (`azure\`)
- **Tests**: `tests\` (End-to-End, Integration, Playwright, Unit)
Umfang: ca. 15.554 C#-Dateien. Eine Original-Commit-Historie des ERP-Produkts liegt nicht vor (die Codebasis wurde als Snapshot in das Arbeitsrepository übernommen); Change-Historie stand daher als Artefaktquelle nicht zur Verfügung.
## Schritt 0 — Modulinventar
Bezugsgröße für Abdeckung und Mindestabdeckung. Pfade relativ zu `C:\DEV\MasterArbeit\QuellCode\CentronERP`. Kürzel: `UI` = `src\centron\Centron.WPF.UI\Modules`, `BL` = `src\backend\Centron.BL`. Spalte AP = Arbeitspaket der Analyse.
### A — Vertrieb & Belegwesen
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M01 | Belegwesen Verkauf (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholliste) | `BL\Sales\Receipts` (Offers, Orders, DeliveryLists, Invoices, CreditVouchers, PickupLists, DownPayment), `UI\Sales` | Kern-Belegkette des Verkaufs von Angebot bis Gutschrift inkl. Versionierung und Statusführung. | AP1 |
| M02 | Sonderpreise / Aktionspreise | `docs\reference\receipts\actionprice-system.md`, BL `Accounts` (Sonderpreise), `UI\Sales\SpecialArticleImport` | Kunden-/aktionsbezogene Preisfindung und Import von Sonderpreisen. | AP1 |
| M03 | Belegkonditionen | `UI\Administration\ReceiptConditions` | Verwaltung von Zahlungs-/Lieferkonditionen für Belege. | AP1 |
| M04 | Kassenbuch | `BL\Sales\CashBooks` | Führen von Kassenbüchern mit Ein-/Auszahlungen. | AP1 |
| M05 | Schweiz-Sonderlogik Belege | `BL\Sales\Receipts\Switzerland` | Länderspezifische Sonderbehandlung von Belegen für die Schweiz. | AP1 |
| M06 | Stundenzuschlagssätze | `BL\Sales\HourlySurchargeRatesBL`, `UI\Administration\HourlySurchargeRates` | Zuschlagssätze auf Stundenleistungen. | AP1 |
| M07 | Serienmails/Mailing-Aktionen | `UI\Sales\Mailing`, `BL\Mailings` | Serienmail-Kampagnen mit Vorlagen und Empfängerlisten. | AP9 |
### B — Verträge & wiederkehrende Abrechnung
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M08 | Vertragsverwaltung | `UI\Finances\Contracts`, `BL\Sales\Receipts\ContractLists`, `docs\reference\receipts\contracts-backend.md` | Verwaltung von Service-/Wartungsverträgen als Belegart (VertragKopf/VertragPos). | AP2 |
| M09 | Automatische Vertragsabrechnung | `UI\Finances\AutomatedBilling`, `docs\reference\receipts\Contract-Billing-RMM-Article-Logic.md` | Periodische Fakturierung von Verträgen inkl. RMM-Mengenlogik. | AP2 |
| M10 | Flatrate-Abrechnung | `UI\Finances\FlatrateBilling` | Pauschal-Abrechnung von Leistungen. | AP2 |
| M11 | Timer-/Zeitabrechnung | `UI\Finances\TimerBilling`, `UI\Helpdesk` (HelpdeskTimers) | Abrechnung erfasster Arbeitszeiten aus Tickets. | AP2 |
| M12 | Geräte-Klickabrechnung | `UI\Finances\DeviceClickCounter` | Abrechnung von Druck-/Kopierklicks je Gerät (Zählerstände). | AP2 |
| M13 | Vertragsauswertung | `UI\Finances\ContractEvaluation2`, `UI\Finances\ContractEvaluationOld` | Wirtschaftlichkeitsauswertung von Verträgen (neue und alte Implementierung). | AP2 |
| M14 | SEPA-Vertragsdaten | `UI\Administration\SepaContract` | Verwaltung von SEPA-Mandaten/Bankdaten für Vertragsabrechnung. | AP2 |
| M15 | Telekom-DIVE-Export | `UI\Modules\TelekomDive` | Export von Vertrags-/Abrechnungsdaten im Telekom-DIVE-Format. | AP2 |
### C — Finanzen & Buchhaltung
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M16 | Offene Posten (OPOS) | `UI\Finances\Opos` | Überwachung offener Forderungen/Verbindlichkeiten. | AP3 |
| M17 | Zahlungsverkehr (Ein-/Ausgangszahlungen) | `UI\Finances\Payments`, `BL\Finances\IncomingPayments`, `BL\Finances\Payments`, `UI\Warehousing\OutcomingPayments` | Erfassen und Zuordnen von Zahlungen zu Belegen. | AP3 |
| M18 | Mahnwesen | `UI\Finances\Dunning` | Mahnläufe über fällige offene Posten. | AP3 |
| M19 | Online-Banking | `UI\Modules\OnlineBanking`, `BL\Finances\OnlineBanking`, `src\apis\Centron.APIs.FinAPI` | Bankkonten-Anbindung, Umsatzabruf und Zahlungen über finAPI. | AP3 |
| M20 | Buchhaltungsexport / DATEV | `UI\DataExchange\BookKeeping`, `UI\DataExchange\DatevOnline2020` | Export von Buchungsdaten an Finanzbuchhaltung/DATEV. | AP3 |
| M21 | E-Rechnung (ZUGFeRD/XRechnung/ebInterface) | `docs\guides\development\xrechnung.md`, `docs\reference\zugferd-field-mapping.md`, `src\apis\Centron.Api.EbInterface`, Controller `ZugferdImportController.cs`, `BL\ReportEngine` (ZUGFeRD-PDF) | Erzeugung und Import elektronischer Rechnungen. | AP3 |
| M22 | Bankverbindungen (Stammdaten) | `BL\Accounting` | Verwaltung der Bankkonten von Kunden und eigener Firma. | AP3 |
| M23 | Zahler & Kostenstellen | `UI\Modules\PayersAndCostCenter` | Verwaltung abweichender Zahler und Kostenstellen. | AP3 |
| M24 | Gutschein-Verwaltung | `BL\VoucherManagement` | Gutscheine mit Barcode und Einlösestatus. | AP3 |
### D — Einkauf & Beschaffung
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M25 | Einkaufsbelege (Bestellung, Wareneingang, Eingangsrechnung, Lieferanten-Gutschrift) | `BL\Sales\Receipts\SupplierOrders`, `...\SupplierDeliveryLists`, `...\SupplierInvoices`, `...\SupplierCreditVouchers`, `UI\Purchasing` | Einkaufsseitige Belegkette gegenüber Lieferanten. | AP4 |
| M26 | EDI-Anbindung Distributoren | `BL\EDI`, `UI\Purchasing\EDIManagement`, `docs\reference\edi\*` | Elektronischer Belegaustausch mit Distributoren (ALSO, Alltron, Komsa, EGIS, Concerto, OpenTrans). | AP4 |
| M27 | Bestellvorschläge | `UI\Purchasing\OrderSuggestionList` | Ermittlung von Bestellvorschlägen aus Bedarf/Beständen. | AP4 |
| M28 | Reisekosten | `UI\Purchasing\TravelExpense` | Erfassung und Abrechnung von Reisekosten. | AP4 |
| M29 | Distributoren-Stammdaten | `BL\Buying` | Stammdaten der Großhändler/Distributoren. | AP4 |
| M30 | ITscope-Marktplatz | `src\apis\Centron.APIs.ITscopeDataAccess` | Produkt-/Preis-/Bestellzugriff auf den ITscope-Marktplatz. | AP4 |
| M31 | COP-Produktdatendienst | `src\apis\Centron.APIs.CopDataAccess` | SOAP-Zugriff auf Produkt-, Preis- und Lieferantendaten (COP). | AP4 |
| M32 | EGIS-Distributionsdienst | `src\apis\Centron.APIs.EgisDataAccess` | Artikelsuche, Preise/Verfügbarkeiten, Produktspezifikationen (EGIS). | AP4 |
| M33 | Icecat-Produktkatalog | `src\apis\Centron.APIs.IcecatDataAccess` | Anreicherung von Artikeln mit Icecat-Katalogdaten. | AP4 |
| M34 | TradePool-Import | `BL\TradePool` | XML-Import von Handels-/Marktplatzdaten. | AP4 |
### E — Artikel, Lager & Logistik
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M35 | Artikelstamm | `UI\Warehousing\ArticleManagement`, `UI\Warehousing\SearchArticle` | Verwaltung des Artikelstamms inkl. Suche. | AP5 |
| M36 | Artikelimport | `UI\Warehousing\ArticleImport` | Dateibasierter Import von Artikeldaten. | AP5 |
| M37 | Artikel-Nebenstammdaten (Einheiten, Warengruppen, Kontenrahmen) | `UI\Warehousing\ArticleUnitManagement`, `...\MaterialGroupManagement`, `...\AccountSystems` | Pflege von Einheiten, Warengruppen und Kontenzuordnungen. | AP5 |
| M38 | Lager & Inventur | `BL\Storage`, `UI\Warehousing\Inventory` | Lagerverwaltung und Inventurdurchführung. | AP5 |
| M39 | Kommissionierung | `UI\Warehousing\Commissioning`, `UI\Warehousing\Commissions` | Kommissionieren von Aufträgen. | AP5 |
| M40 | Barcode-Verwaltung | `UI\Warehousing\BarcodeManagement` | Barcodes für Artikel/Lagerprozesse. | AP5 |
| M41 | Versand/Logistik | `UI\Modules\Logistic`, `BL\Logistics` | Versandabwicklung und Versandarten-Konfiguration. | AP5 |
| M42 | GLS-Versand | `src\apis\Centron.Api.Gls` | Paketerstellung und Labeldruck über GLS. | AP5 |
| M43 | Shipcloud-Versand | `src\apis\Centron.Api.Shipcloud` | Multi-Carrier-Versand über Shipcloud inkl. Zolldaten. | AP5 |
| M44 | Lieferantensuche | `UI\Warehousing\SupplierSearch`, `BL\BusinessPartner` | Suche von Lieferanten zu Artikeln. | AP5 |
### F — Helpdesk & Service
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M45 | Helpdesk/Ticketsystem (Kern) | `UI\Helpdesk` (TicketList, TicketDetails, Dashboard), `BL\Modules`-übergreifende Helpdesk-BLs, `CentronRights.md` | Zentrales Ticketsystem für Servicefälle inkl. Rechten, Timern, Dashboard. | AP6 |
| M46 | Checklisten | `BL\CheckListArea`, `UI\Helpdesk\CentronChecklist` | Checklisten mit Positionen und Änderungsprotokoll. | AP6 |
| M47 | Erwartete Ereignisse | `BL\ExpectedEvents`, `UI\Helpdesk\ExpectedEvents`, `...\ExpectedEventsReporting` | Überwachung erwarteter Ereignisse/Fälligkeiten mit Auswertung. | AP6 |
| M48 | Aufgabenverwaltung (TaskManager) | `BL\TaskManager`, `UI\Helpdesk\TaskManagement`, `UI\Administration\TaskManagmentSettings` | Aufgaben mit konfigurierbaren Aktions-Handlern. | AP6 |
| M49 | Ticket-Projekte | `BL\TicketProjects` | Bündelung von Tickets zu Projekten inkl. Abhängigkeiten. | AP6 |
| M50 | Ticket-Prozessvorlagen / Ticket-Muster | `UI\Helpdesk\TicketProcessTemplates`, Controller `TicketPatternsController.cs` | Vorlagen für wiederkehrende Ticketprozesse. | AP6 |
| M51 | SelfCare-Formulare | `BL\SelfCare`, `UI\Helpdesk\SendSelfCareForm`, Controller `SelfCareFormsController.cs` | Self-Service-Formulare für Endkunden. | AP6 |
| M52 | Externes Helpdesk | `BL\ExternalHelpdesk` | Anbindung externer Ticketsysteme. | AP6 |
| M53 | Zeitregeln/Fristen | `BL\Time` | Konfigurierbare Zeitregeln (z. B. für Fristen und Jobs). | AP6 |
| M54 | Eskalationen | `UI\Administration\EscalationsSettings`, `src\webservice\Centron.Host` (Eskalationsdienst) | Eskalationsregeln für Tickets/Fristen. | AP6 |
| M55 | Umfragen | `UI\Modules\Survey` | Erstellen, Ausführen und Auswerten von Umfragen. | AP6 |
| M56 | RMA-Abwicklung | `UI\Modules\Rma`, `BL\CustomerArea\RmaBL.cs` | Rücksendeabwicklung an Lieferanten und Rückgabe an Kunden. | AP6 |
| M57 | IT-Planner | `BL\ItPlanner` | Kategorien virtueller Objekte für IT-Planungs-/Checklistenstruktur. | AP6 |
| M58 | DocuBoard / Asset-Management-Board | `BL\DocuBoard` | Board mit Partner-, Artikelzuordnungs- und AD-Benutzerausschlussverwaltung. | AP6 |
### G — CRM & Stammdaten
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M59 | Adress-/Kundenstamm | `BL\Accounts`, `BL\CustomerArea`, `BL\Sales\Customers` | Zentraler Kunden-/Adressstamm mit Ansprechpartnern, Branchen, Interessen. | AP8 |
| M60 | Kontaktaktivitäten / CRM | `UI\Finances\Crm`, `BL\CustomerArea` (Aktivitäten) | Dokumentation von Kundenkontakten und Aktivitäten. | AP8 |
| M61 | Kampagnen | `UI\Finances\Campaigns`, `BL\Accounts\Campaigns`, `BL\Sales\Marketing` | Marketing-Kampagnen mit Kundenzuordnung. | AP8 |
| M62 | Geräte/Assets beim Kunden | `BL\Devices`, `BL\Sales\CustomerAssets`, `BL\BusinessPartner\SupplierAssetBL.cs` | Verwaltung von Kundengeräten/Assets (inkl. getrennter Druckerstammblätter — Konsolidierungskandidat). | AP8 |
| M63 | Projekte | `BL\Projects`, `UI\Modules\ProjectManagement`, `UI\Finances\Projects` | Projektstammdaten und Projektsichten. | AP8 |
| M64 | Projektpreis-/Sonderpreisimport & Custom Gateways | `UI\Modules\ProjectPriceImport`, `BL\Gateway`, `UI\Sales\SpecialArticleToContractImport` | Import kundenspezifischer Preis-/Vertragsdaten über konfigurierbare Gateways. | AP11 |
| M65 | Länder & Bundesländer | `BL\CountryArea`, `UI\Administration\CountryManagement` | Stammdaten Länder/Bundesländer. | AP8 |
| M66 | Tags/Schlagwörter | `BL\Tags` | Schlagwortverwaltung und Zuordnung zu Objekten. | AP8 |
| M67 | Textbausteine | `BL\TextModuleArea`, `UI\Administration\TextBlockManagement` | Textbausteine inkl. Anrede-/Grußformel-Ersetzung. | AP8 |
| M68 | Mitarbeiterverwaltung | `BL\EmployeeArea`, `UI\Administration\EmployeeManagement` | Mitarbeiterstamm, App-Benutzer, Abteilungen, Urlaub, RFID, Teams. | AP8 |
| M69 | Stammdatenlisten | `UI\Finances\MasterDataLists`, Controller `MasterDataListsController.cs` | Pflege einfacher Auswahl-/Stammdatenlisten. | AP8 |
| M70 | Massenupdates | `BL\MassUpdate`, `UI\Modules\Massenupdates` | Massenänderungen über konfigurierbare Update-Jobs. | AP8 |
| M71 | Kundenindividuelle Zusatztabellen | `BL\Customizations` | Custom Tables mit Variablenersetzung. | AP8 |
| M72 | Externe Objektreferenzen | `BL\ObjectExternalReferences`, Controller `ObjectExternalReferencesController.cs` | Verknüpfung von c-entron-Objekten mit Fremdsystem-IDs. | AP8 |
| M73 | Produktmatrix | `BL\ProductMatrix`, `UI\Sales\ProductMatrix` | Produktkategorien-Matrix je Kunde. | AP8 |
| M74 | DSGVO | `UI\Administration\DSGVO` | Datenschutzfunktionen (Auskunft/Löschung). | AP7 |
### H — Kommunikation & Zusammenarbeit
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M75 | E-Mail-Versand/-Zugriff | `BL\Mail` (SMTP, Exchange/EWS, MS Graph), `UI\Administration\MailTemplates`, `docs\guides\development\create-mail-templates.md` | Mailversand über mehrere Protokolle inkl. Vorlagen und Signaturen. | AP9 |
| M76 | MailScanner | `BL\MailScanner` | Automatisches Auslesen von Postfächern zur Weiterverarbeitung (Ticket-/Belegerzeugung). | AP9 |
| M77 | Kalender & Exchange-Sync | `UI\Modules\Calendar`, `BL\Calendar`, `UI\Administration\MailAndCalender`, `docs\features\exchange-sync-bugprotokoll.md` | Terminverwaltung und Synchronisation mit Exchange. | AP9 |
| M78 | Terminanfragen | `BL\AppointmentRequests` | Terminanfragen mit Zu-/Absagen. | AP9 |
| M79 | Outlook-Add-In | `src\nexus\CentronNexus.OutlookAddIn`, `BL\Outlook` | Kontextanzeige von Kunde/Belegen/Aktivitäten zur aktuellen Mail. | AP9 |
| M80 | Telefonie (TAPI) | `BL\Tapi`, `docs\reference\architecture\tapi.md`, `UI\Administration\PhoneSettings` | Anruferfassung und -auswertung über TAPI. | AP9 |
| M81 | Interner Chat | `BL\Chats` | Interner Chat mit Objektbezug. | AP9 |
| M82 | Benachrichtigungen | `BL\Notifications`, `BL\NexusNotifications` | Systemweite und Realtime-Benachrichtigungen (SignalR). | AP9 |
| M83 | Soziale Netzwerke | `BL\SocialMedia` | Zuordnung sozialer Netzwerke zu Personen. | AP9 |
| M84 | Videoportal | `BL\VideoPortal` | Zuordnung von Videoinhalten zu Objekten. | AP9 |
| M85 | Signierte Web-Links | `BL\WebLinks` | Signierte Links mit hinterlegten Aktionen. | AP9 |
| M86 | Kurz-URLs | `BL\Urls` | Einfache Objekt-/Kurz-URLs. | AP9 |
### I — Auswertung & persönlicher Arbeitsbereich
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M87 | Statistiken | `UI\Modules\Statistics`, `BL\Statistics` | Umsatz-/Kennzahlenauswertungen. | AP12 |
| M88 | Reports/Formulardruck | `BL\ReportEngine` (FastReport), `BL\Reporting`, `UI\Modules\Reports`, `UI\Administration\ReportServer` | Formular-/Reporterzeugung inkl. PDF und ReportServer. | AP11 |
| M89 | Dashboard | `UI\Modules\Dashboard` | Übergreifendes Kennzahlen-Dashboard. | AP12 |
| M90 | Volltextsuche | `BL\IndexSearch` (Lucene) | Volltextindizierung und -suche über Geschäftsobjekte. | AP11 |
| M91 | KI-Funktionen | `UI\Modules\ArtificialIntelligence`, `BL\ArtificialIntelligence`, Controller `ArtificialIntelligenceChatsController.cs` | KI-gestützte Chats/Assistenz. | AP12 |
| M92 | MyCentron/MyDay/ToDo/QuickNotes | `BL\MyCentron`, `BL\MyDay`, `BL\ToDoArea`, `UI\Modules\MyCentron` | Persönlicher Arbeitsbereich: Dashboard, Tagesübersicht, To-dos, Notizen. | AP12 |
### J — Sicherheit & Administration
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M93 | Benutzerrechte | `CentronRights.md`, `docs\guides\development\check-userrights.md`, `UI\Administration\RightsManagement`, UserRightsConst | Feingranulare Rechteverwaltung inkl. einschränkender Rechte (nur eigene / eigene Filiale). | AP7 |
| M94 | Authentifizierung & Login | `docs\reference\security\anmelden-mit-microsoft-technische-anleitung.md`, `src\webservice\Centron.Controllers\Controllers\...\JwtAuthController.cs`, `AuthConfigurationController.cs`, AccessTokens | Anmeldung am Client/Webservice inkl. „Anmelden mit Microsoft", JWT, Access-Tokens. | AP7 |
| M95 | Zwei-Faktor-Authentifizierung | `BL\TwoFactorAuthenticator`, Controller `TwoFactorAuthController.cs` | TOTP-Registrierung und -Prüfung. | AP7 |
| M96 | Passwortmanager | `BL\PasswordManagementArea`, `BL\PasswordManager`, `UI\Modules\PasswordManager` | Verwaltung von Kundenpasswörtern inkl. Zugriffs-/Änderungsprotokoll. | AP7 |
| M97 | Lizenzierung | `docs\reference\security\licensing-system.md`, `LicenseGuids.cs`, `ApplicationKind.cs`, Controller `LicenseController.cs` | GUID-basierte Lizenzen mit Anzahl/Gültigkeit je Feature und Applikation. | AP7 |
| M98 | Mandanten & Filialen | `UI\Administration\MandatorManagement`, Branch-Logik | Mandanten- und Filialverwaltung. | AP7 |
| M99 | PDF-Signatur | `BL\Security\PdfSigningBL.cs`, `UI\Administration\PdfSigning` | Digitale Signatur von PDF-Dokumenten mit Zertifikaten. | AP7 |
| M100 | Einstellungsverwaltung | `docs\guides\development\settings-management.md`, `UI\Administration\Settings` | Zentrale, hierarchische Verwaltung von System-/Benutzereinstellungen. | AP7 |
| M101 | Änderungsverfolgung/Audit | `BL\ChangeTracking` | Historisierung von Importen und Datenänderungen. | AP7 |
| M102 | Telemetrie | `BL\Telemetry` | Erfassung von Nutzungsdaten. | AP7 |
| M103 | Log-Viewer/Protokollierung | `UI\Administration\LogViewer` | Einsehen von Anwendungsprotokollen. | AP7 |
| M104 | Admin-Werkzeuge (Cache, Profiling, SqlManagers, CentronConfigDb, Connections) | `UI\Administration\Cache`, `...\Profiling`, `...\SqlManagers`, `...\CentronConfigDb`, `...\Connections` | Technische Administrationswerkzeuge des Clients. | AP7 |
| M105 | Modul-Registry & Favoriten | `BL\Modules` | Registrierung der Anwendungsmodule, Kategorien, Favoriten. | AP7 |
| M106 | Systemtabelle/ID-Vergabe | `BL\SystemArea\SystemTableI3DBL.cs` | Zentrale Systemtabelle mit ID-Vergabe (I3D). | AP11 |
### K — Web-Plattform & Schnittstellen
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M107 | Webservice-Server | `src\webservice\Centron.Host`, `src\webservice\Centron.Controllers`, `BL\WebServices` (Fassade, 464 Dateien), `docs\guides\services\add-webservice-methods.md` | REST-/Webservice-Schicht über der Geschäftslogik inkl. Hintergrunddienste. | AP10 |
| M108 | Webservice-Client-Kern | `src\webservice\Centron.WebServices.Core` | Transport, Serialisierung, JWT-Auth, HTTP-Clients für Client-Zugriffe. | AP10 |
| M109 | ConnectionManager | `src\webservice\c-entron.misc.ConnectionManager` | Admin-Tool für Verbindungen, Lizenzen, Hardware-ID, 2FA-Test. | AP10 |
| M110 | Nexus ServiceBoard | `src\nexus\CentronNexus\ServiceBoard`, `BL\NexusTicketViews`, `BL\CentronNexus` | Web-Ticket-Arbeitsplatz (Kanban, Scheduler, MyDay, Statistiken). | AP10 |
| M111 | Nexus WebCart/Kundenportal | `src\nexus\CentronNexus\WebCart`, `README.md` (WebCart), `UI\Administration\WebCart` | Webshop für Endkunden auf Basis von Web-Accounts und Sonderpreisen. | AP10 |
| M112 | Nexus WebOffer/Belegansicht | `src\nexus\CentronNexus\WebOffer` | Web-Ansicht von Belegen mit PDF-Vorschau. | AP10 |
| M113 | Nexus Office & DocumentSigning | `src\nexus\CentronNexus\Office`, `...\DocumentSigning` | Geteilte Dokumente, Freigaben und digitale Unterschrift. | AP10 |
| M114 | Nexus ProductionOrderManagement | `src\nexus\CentronNexus\ProductionOrderManagement` | Web-Verwaltung von Fertigungsaufträgen. | AP10 |
| M115 | Nexus Management/Settings/Shared | `src\nexus\CentronNexus\Management`, `...\Settings`, `...\Shared` | Web-Administration (TaskManagement, TicketPatterns, WebAccounts), Auth, Layout. | AP10 |
| M116 | Mobile-App-Backend | `BL\Mobile` | Datenversorgung der mobilen App. | AP10 |
| M117 | WebSuite (Alt-Web) | `BL\WebSuite` | Konfiguration der älteren Web-Suite. | AP10 |
| M118 | Webservice-Versionsabgleich | `BL\WebVersion` | Versionsermittlung/-abgleich zwischen Client und Webservice. | AP10 |
| M119 | RMM-/DocBee-Integrationen | `BL\Integrations`, Controller `RmmController.cs`, `DocBeeConnectorConfigurationController.cs`, `RmmConnectionSettingsController.cs`, `UI\DataExchange` (RMM) | Anbindung von RMM-Systemen und DocBee. | AP12 |
| M120 | RiverDivo-Schnittstelle | `BL\RiverDivo` | Webservice-Schnittstelle zum Riverbird/Divo-System. | AP12 |
| M121 | cPra-Anbindung | `BL\CPra` | Login/Konfiguration für das externe System „cPra". | AP12 |
| M122 | docuFORM-Anbindung | `Centron.Api.docuFORM`, Controller `DocuFormApiSettingsController.cs`, `UI\DataExchange` (DocSync) | REST-Anbindung docuFORM (OAuth, Kundenanlage, Deployments). | AP12 |
| M123 | Externe Tools | `BL\ExternalToolsBL`, `UI\Modules\ExternalTool`, `UI\Administration\ExternalTools` | Konfigurierbarer Aufruf externer Programme mit Variablenersetzung. | AP12 |
| M124 | Import-/Export-Framework (DataExchange) | `UI\Modules\DataExchange` (Assistenten, Konnektoren) | Generische Import-/Export-Assistenten und Konnektoren. | AP11 |
| M125 | Prozesse (generisch) | `BL\Processes` | Generische Vorgangs-/Prozessobjekte an beliebigen Objekten. | AP11 |
| M126 | Transaktionen | `BL\Transactions` | Verwaltung/Abfrage von Transaktionen. | AP11 |
### L — Produktion & Sonstige Fachmodule
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M127 | Produktion/Fertigungsaufträge | `UI\Modules\Production` (ProductionOrder, MachineManagement, Settings), `BL\Production` | Fertigungsaufträge und Maschinenverwaltung. | AP12 |
| M128 | Produkt-Lifecycle-Management | `UI\Modules\PLM`, `UI\Finances\ProductLifecycleManagement` | Produktfamilien/-gruppen mit Lebenszyklusinformationen. | AP12 |
| M129 | Qualitätsmanagement | `UI\Modules\QM` | QM-Einstellungen (Beleg-/Asset-Gründe). | AP12 |
| M130 | Dokumentation an Objekten | `BL\DocumentationArea`, `BL\Sales\DocumentationWizardArea` | Dokumentationseinträge zu Objekten inkl. Rechteprüfung. | AP12 |
### M — Plattform, Infrastruktur & Betrieb
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M131 | WPF-Client-Rahmen | `src\centron\Centron.WPF.UI` (Start, Layout, Dialogs, Wizards), `src\centron\Centron.WPF.UI.Extension`, `src\shared\Centron.Controls` | Anwendungsrahmen: Start/Login, Modul-Hosting, MVVM, Steuerelemente. | AP11 |
| M132 | Lokalisierung | `docs\guides\ui\localization.md`, `LocalizedStrings.resx`/`.en.resx` | Zweisprachigkeit Deutsch (Standard)/Englisch. | AP11 |
| M133 | Datenzugriff & O/R-Mapping | `src\backend\Centron.DAO`, `src\backend\Centron.Entities`, `BL\Start` | NHibernate-basierter Datenzugriff, Entities, Mapping. | AP11 |
| M134 | Datenbankschema & Skript-System | `SSMS_DB_SCHEMA.sql`, `docs\guides\database\create-scripts.md`, `docs\reference\database\script-rules.md`, `scripts\` | 1.535 Tabellen, Views, Constraints; versionierte Migrationsskripte. | AP11 |
| M135 | Hintergrunddienste | `src\webservice\Centron.Host` (HostedServices), `docs\Background Service\DataQualityService.md` | Geplante Dienste: EDI-Download, Exchange-Sync, Indexierung, Eskalation, Preisupdates, Datenqualität. | AP10 |
| M136 | Deployment/Installer | `deployment\` (WiX), `azure\`, `version.json` | MSI-Installer für Client und Webservice, Build-Pipelines. | AP11 |
| M137 | Docker-/Linux-Betrieb | `docker\`, `docs\guides\services\web-service-on-linux.md` | Containerisierter Betrieb des Webservice. | AP11 |
| M138 | Teststrategie | `tests\` (EndToEnd, Integration, Playwright), `docs\guides\development\end-to-end-testing.md` | Automatisierte Regressions-/E2E-Tests. | AP11 |
| M139 | Gemeinsame Basisbibliothek | `src\shared\Centron.Core`, `src\backend\Centron.Common`, `src\backend\Centron.Interfaces`, `src\backend\Centron.Gateway` | Technische Querschnittsfunktionen (Guard, TOTP, Result-Pattern, DTOs). | AP11 |
**Inventarstand:** 139 Module/Komponenten. Das Inventar darf ergänzt, aber nicht gekürzt werden.
## Arbeitspakete der Analyse (Schritt 0b/0c)
| AP | Themenfeld | ID-Bereich (je Ebene) | Risikofokus |
|---|---|---|---|
| AP1 | Belegwesen Verkauf | 100–299 | Fakturierung ✔ |
| AP2 | Verträge & wiederkehrende Abrechnung | 300–499 | Fakturierung ✔ |
| AP3 | Finanzen & Buchhaltung | 500–699 | Abrechnung/Zahlung ✔ |
| AP4 | Einkauf & Beschaffung | 700–899 | — |
| AP5 | Artikel/Lager/Logistik | 900–1099 | — |
| AP6 | Helpdesk & Service | 1100–1299 | Berechtigungen (Ticketrechte) ✔ |
| AP7 | Sicherheit & Administration | 1300–1499 | Sicherheit/Berechtigungen ✔ |
| AP8 | CRM & Stammdaten | 1500–1699 | — |
| AP9 | Kommunikation | 1700–1899 | — |
| AP10 | Web-Plattform & Webservice | 1900–2099 | Auth am Webservice ✔ |
| AP11 | Plattform & Infrastruktur | 2100–2299 | — |
| AP12 | Übrige Fachmodule & Integrationen | 2300–2499 | — |
Mindestabdeckung (Schritt 0b): Jedes der 139 Module erhält mindestens eine Anforderung oder wird mit Begründung als `nicht analysiert` geführt. Vertiefung (Schritt 0c) erfolgt in AP1–AP3, AP6, AP7 und AP10 (Sicherheits-, Abrechnungs- und Berechtigungslogik).
*Die Abschnitte Abdeckungstabelle, Konsistenzcheck und Selbstbewertung werden nach Abschluss der Analyse ergänzt (siehe unten).*
@@ -0,0 +1,89 @@
# Messprotokoll – Versuch 01 (V1b Baseline mit werkzeugeigenen Agenten) – Prompt-Version 02
> ## ⚠ FEHLMESSUNG – nicht für Auswertungen verwenden
>
> Der Lauf brach mit `is_error: true` und HTTP 429 ab: „You've hit your session limit ·
> resets 10:50pm (Europe/Berlin)". Erzeugt wurden **1 von sieben** geforderten Ergebnisdateien; der Lauf brach mitten in der Bearbeitung ab. Verbraucht wurden
> bis zum Abbruch **77.815.316 Tokens**.
## Lauf
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
- **Prompt-Version:** 02
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
- **Startzeit:** 2026-08-26T20:00:11.2795634+02:00
- **Endzeit:** 2026-08-26T20:30:04.2067421+02:00
- **Dauer gesamt:** 00:07:4x — bis zum Kontingentabbruch
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
- **Codebasis-Commit:** `f349d189c735a87f5829bc93f67991320061a2c0` (dirty: nein)
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; enthält `SSMS_DB_SCHEMA.sql`
## Werkzeugkonfiguration
- **Skill-Version:** 7.0.0
- **Claude-Code-Version:** 2.1.246
- **Modell (angefordert):** `claude-fable-5`
- **Modelle (tatsächlich eingesetzt):** `claude-fable-5` 77.433.773 (99.51 %), `claude-opus-5[1m]` 374.562 (0.48 %), `claude-haiku-4-5-20251001` 6.981 (0.01 %)
- **Kontrolle Modell:** **verletzt** – nicht angefordertes Modell `claude-opus-5[1m]` mit 374.562 Tokens (0.48 %)
- **Effort:** `high`
- **Agentenmodus:** `builtin` (V1b)
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
- **Hintergrund-Wartezeit:** `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`
- **Parallele Läufe:** **ja** – alle vier Läufe der Welle liefen gleichzeitig
- **Subagenten:** 13 gestartet (1 × `Explore`, 12 × `general-purpose`), `max_depth` = 1
## Verbrauch
| Messgröße | `claude-fable-5` | `claude-opus-5[1m]` | `claude-haiku-4-5-20251001` | Summe |
|---|---:|---:|---:|---:|
| Input-Tokens | 1.426 | 20 | 6.961 | 8.407 |
| Output-Tokens | 1.037.386 | 15.803 | 20 | 1.053.209 |
| Cache-Write-Tokens | 4.150.505 | 52.132 | 0 | 4.202.637 |
| Cache-Read-Tokens | 72.244.456 | 306.607 | 0 | 72.551.063 |
| **Tokens gesamt** | **77.433.773** | **374.562** | **6.981** | **77.815.316** |
**Tokens gesamt: 77.815.316** — real angefallen und deshalb ausgewiesen, obwohl der Lauf ungültig ist.
## Gefundene Anforderungen
Der Lauf brach vor Abschluss ab. Die vorhandenen Dateien sind ein **Teilbestand** und mit vollständigen Läufen nicht vergleichbar; eine Auswertung unterbleibt deshalb.
## Ergebnis
- **Gültigkeit:** **Fehlmessung** – API-Abbruch (HTTP 429, Session-Kontingent); nur 1 von sieben Artefakten erzeugt
- **Status:** `is_error` = true, `terminal_reason` = `api_error`, `api_error_status` = 429
- **Session-ID:** `d77bf9b3-7a4d-4620-861f-28861a420996`
- **Turns:** 44
- **Permission-Denials:** 14
- **Erzeugte Dateien:** 1 von sieben geforderten Artefakten:
| Datei | Größe |
|---|---:|
| `Analysebericht.md` | 26.963 B |
Es fehlen: `StRS.md`, `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`
- **Root unverändert:** ja
- **Abschlusstext des Agenten:** „You've hit your session limit · resets 10:50pm (Europe/Berlin)"
## Anmerkungen/Auffälligkeiten
**1. Kontingentabbruch, nicht Laufversagen.** Vier Läufe wurden am 26.08. um 19:59 gleichzeitig
gestartet; alle vier liefen in dieselbe Grenze. Zusammen hatten sie zu diesem Zeitpunkt
297,4 Mio. Tokens verbraucht, davon allein 204,4 Mio. im Lauf `45dd`. Die Parallelität von vier
Läufen – darunter einer mit extremer Delegation – hat das Kontingent gerissen.
**2. Konsequenz für den Versuchsaufbau:** Die verbleibenden Zellen werden **seriell** gefahren.
Der erste serielle Lauf danach (`opus-5/solo/high`, `2269`) lief mit 38,1 Mio. Tokens sauber durch.
**3. Die Modellverletzung aus Iteration 1 ist reproduziert.** `modelUsage` weist neben
`claude-fable-5` auch **`claude-opus-5[1m]`** aus. Derselbe Befund war in Iteration 1 unter
Prompt-Version 01 und ohne DB-Schema aufgetreten; damit ist aus einem Einzelfall ein belegtes
Muster geworden: **Fable wird bei Delegation nicht an die Subagenten durchgereicht**, Sonnet und
Opus dagegen schon. Ursache ist die Sitzungsvorgabe `model: opus[1m]` in
`~/.claude/settings.json`; `--safe-mode` verhindert das nicht.
Die Gegenprobe im selben Block bestätigt die Abgrenzung: Der Lauf `77a1` mit Fable im Modus
`solo` weist ausschließlich `claude-fable-5` plus Haiku aus. **Nicht das Modell ist das Problem,
sondern Fable in Kombination mit Delegation.**
**4. Die Zelle bleibt unbelegt.** Ein gültiger Lauf für `fable-5/builtin/high` steht aus. Er wäre
allerdings von vornherein als bedingungsverletzt zu führen, solange die Subagenten auf einem
nicht angeforderten Modell laufen.
@@ -0,0 +1,178 @@
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
## Metadaten
- **Versuch:** V1 Baseline (Prompt-only)
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-26
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
| Änderung | Auslösender Befund |
|---|---|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
> 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.
---
## 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.
**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. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
- **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)
```
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)
```
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
---
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien, das Ausführen von
Kommandozeilenbefehlen im Arbeitsverzeichnis sowie die werkzeugeigenen Subagenten.
Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
Werkzeugserver.
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 3\claude-fable-5\builtin\high\02_Lauf_2026-08-26_195958_v7.0.0-d694\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1,195 @@
# Analysebericht – Reverse Requirements Engineering c-entron ERP-Suite
Lauf: 02_Lauf_2026-08-26_195958_v7.0.0-77a1 (Baseline Prompt-only, Iteration 02)
Untersuchungsgegenstand: gesamte Codebasis `C:\DEV\MasterArbeit\QuellCode\CentronERP` (nur lesend).
Dieser Bericht enthält:
1. Modulinventar (Schritt 0 – erstellt **vor** der ersten Anforderung)
2. Abdeckungstabelle (wird nach Abschluss der Anforderungserhebung gefüllt)
3. Konsistenzcheck
4. Liste der risikorelevanten Anforderungen mit Belegsituation
5. Selbstbewertung
---
## 1. Modulinventar (Schritt 0)
Grundlage: Verzeichnisstruktur `src/` (backend/centron/nexus/shared/webservice/apis), `docs/`,
`deployment/`, `docker/`, `scripts/`, `tests/` sowie Wurzeldateien (`SSMS_DB_SCHEMA.sql`,
`CentronRights.md`). Die fachlichen Module wurden primär aus den Fachordnern von
`src/backend/Centron.BL` (Geschäftslogik), den UI-Modulen `src/centron/Centron.WPF.UI/Modules`
und den Web-Bereichen `src/nexus/CentronNexus` abgeleitet. Pfade sind relativ zum
Arbeitsverzeichnis. Das Inventar darf ergänzt, aber nicht gekürzt werden.
| Nr. | Modul / Komponente | Pfad | Fachliche Aufgabe (1 Satz) |
|---|---|---|---|
| M001 | Belegwesen-Kern | src/backend/Centron.BL/Sales/Receipts (ReceiptBL.cs, SpecificLogics.cs) | Gemeinsame Logik aller Belegarten: Laden, Speichern, Statusführung, Nummernvergabe, Preisberechnung, Versionierung. |
| M002 | Angebote | src/backend/Centron.BL/Sales/Receipts/Offers | Erstellung und Verwaltung von Kundenangeboten (AngKopf/AngPos). |
| M003 | Aufträge | src/backend/Centron.BL/Sales/Receipts/Orders | Verwaltung von Kundenaufträgen (AufKopf/AufPos) inkl. Überführung in Folgebelege. |
| M004 | Lieferscheine | src/backend/Centron.BL/Sales/Receipts/DeliveryLists | Verwaltung von Lieferscheinen (LiefKopf/LiefPos). |
| M005 | Rechnungen | src/backend/Centron.BL/Sales/Receipts/Invoices | Verwaltung von Ausgangsrechnungen (RechKopf/RechPos). |
| M006 | Gutschriften | src/backend/Centron.BL/Sales/Receipts/CreditVouchers | Verwaltung von Gutschriften (GutKopf/GutPos). |
| M007 | Abholscheine | src/backend/Centron.BL/Sales/Receipts/PickupLists, .../PickUps | Verwaltung von Abholscheinen (AbholKopf/AbholPos). |
| M008 | Verträge | src/backend/Centron.BL/Sales/Receipts/ContractLists, .../LeasingAndService | Verwaltung von Service-/Wartungsverträgen (VertragKopf/VertragPos) mit Laufzeiten, Kontingenten und Gerätelisten. |
| M009 | Vertragsabrechnung | src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura | Automatische Fakturierung von Verträgen, Aufträgen, Lieferscheinen und Tickets (Intervalle, Kontingente, Klickzähler). |
| M010 | Mahnwesen | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning | Mahnläufe über offene Rechnungen mit Mahnstufen, Mahnstopp und Mahnreports. |
| M011 | Offene Posten (OPOS) | src/backend/Centron.BL/Sales/Receipts/Invoices/Opos | Verwaltung und Auswertung offener Posten. |
| M012 | Anzahlungen | src/backend/Centron.BL/Sales/Receipts/DownPayment | Abbildung von Anzahlungen im Belegfluss. |
| M013 | Warenkorb & Freigabewesen | src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs, ReceiptCartReleaseSystemBL.cs | Warenkörbe von Web-Accounts mit mehrstufigem Prüf-/Freigabe-/Bestellprozess. |
| M014 | Lieferantenbelege | src/backend/Centron.BL/Sales/Receipts/Supplier* | Bestellungen, Wareneingänge, Eingangsrechnungen und Lieferantengutschriften. |
| M015 | Provisionen | src/backend/Centron.BL/Sales/Receipts/ReceiptProvision*.cs | Provisionsschemata, -ziele und -stufen für Vertriebsmitarbeiter. |
| M016 | Kassenbuch | src/backend/Centron.BL/Sales/CashBooks | Kassenbücher mit Buchungen und Belegen je Filiale. |
| M017 | Preisfindung & Kalkulation | src/backend/Centron.BL/Sales/Receipts/ReceiptPriceHelperBL.cs; Centron.BL/Warehousing/ActionPriceBL.cs, ArticleVolumePricesBL.cs; Sales/Support/CustomerSpecialArticleBL.cs | Berechnung von Positions-/Belegpreisen, MwSt., Rabatten, Aktions-, Staffel- und Sonderpreisen. |
| M018 | Schweiz-Sonderlogik | src/backend/Centron.BL/Sales/Receipts/Switzerland | Landesspezifische Sonderbehandlung für Schweizer Belege. |
| M019 | Belegvorlagen | src/backend/Centron.BL/Sales/Receipts/ReceiptTemplateBL.cs | Belegvorlagen über einen definierten Vorlagen-Kunden. |
| M020 | Marketing | src/backend/Centron.BL/Sales/Marketing | Marketingaktionen/-kampagnen im Vertriebsumfeld. |
| M021 | CRM-Projekte | src/backend/Centron.BL/Sales/Customers/CrmProjects | Vertriebschancen/CRM-Projekte zu Kunden. |
| M022 | Kundenstamm (Alt-Struktur) | src/backend/Centron.BL/Sales/Customers | Verwaltung der Kunden (Tabelle Kunden) mit Kreditlimit, Sperren und Zuordnungen. |
| M023 | Stundensatz-Zuschläge | src/backend/Centron.BL/Sales/HourlySurchargeRatesBL | Zuschlagsätze auf Stundensätze (z. B. nach Zeit/Art). |
| M024 | Dokumentations-Assistent | src/backend/Centron.BL/Sales/DocumentationWizardArea | Geführte Erstellung von Dokumentationen. |
| M025 | Helpdesk/Ticketsystem | src/backend/Centron.BL/Sales/Support (HelpdeskBL.cs u. a.) | Störungs-/Serviceticketverwaltung mit Status, Typen, Kategorien, Prioritäten, Historie und Mailversand. |
| M026 | Ticket-Zeiterfassung | src/backend/Centron.BL/Sales/Support/HelpdeskTimer*.cs | Erfassung, Signatur, Verschiebung und Abrechnung von Arbeitszeiten auf Tickets. |
| M027 | Ticket-Eskalation | src/backend/Centron.BL/Sales/Support/Escalation | Eskalationsregeln und -überwachung für Tickets. |
| M028 | Ticketvorlagen/Prozesse (C-FLOW) | src/backend/Centron.BL/Sales/Support/TicketProcess, HelpdeskPatternBL.cs, HelpdeskCreationTemplateBL.cs | Ticketvorlagen und automatische Tickerzeugung nach Vorlagen/Prozessen. |
| M029 | Ticketprojekte | src/backend/Centron.BL/TicketProjects; Sales/Support/TicketProject*.cs | Bündelung von Tickets zu Projekten mit Aufgaben und Abhängigkeiten. |
| M030 | Externe Helpdesks | src/backend/Centron.BL/ExternalHelpdesk | Konfiguration der Kopplung zu Fremd-Ticketsystemen. |
| M031 | Support-Level | src/backend/Centron.BL/Sales/Support/SupportLevelBL.cs | Verwaltung von Support-Leveln (z. B. SLA-Stufen) für Kunden/Tickets. |
| M032 | Kundengeräte/Assets | src/backend/Centron.BL/Sales/CustomerAssets; Centron.BL/Devices | Verwaltung der beim Kunden befindlichen Geräte/Assets inkl. Stammdatenlisten und Historie. |
| M033 | RMA | src/backend/Centron.BL/CustomerArea/RmaBL.cs; UI: Modules/Rma | Reklamations-/Rücksendeabwicklung mit Artikeln und Historie. |
| M034 | Checklisten | src/backend/Centron.BL/CheckListArea | Checklistenvorlagen und Checklisten an Objekten (v. a. Tickets). |
| M035 | Umfragen | src/centron/Centron.WPF.UI/Modules/Survey; BL: HelpdeskSurveyProcess (Sales/Support) | Erstellung und Versand von Kundenumfragen, u. a. beim Ticketabschluss. |
| M036 | TaskManager | src/backend/Centron.BL/TaskManager | Zeit-/ereignisgesteuerte Aufgaben (Tasks) mit Aktionen und Ausführungsprotokoll. |
| M037 | Nexus-Ticketansichten | src/backend/Centron.BL/NexusTicketViews | Konfigurierbare Ticket-Listenansichten für den Webclient. |
| M038 | Einkauf/Bestellwesen | src/backend/Centron.BL/Purchasing, Centron.BL/Buying | Lieferantenbestellungen je Filiale und Einkaufsunterstützung. |
| M039 | Lager/Bestandsführung | src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs; Logistics/LogisticSettings | Verwaltung von Lagern, Lagerorten, Umbuchungen und Bestandslogik. |
| M040 | Inventur | src/backend/Centron.BL/Storage (StorageBL.cs, InventoryArticlePool.cs) | Inventurdurchführung mit Zähllisten und Bestandsabgleich. |
| M041 | Artikelstamm | src/backend/Centron.BL/Warehousing (ArticleBL.cs u. a.) | Verwaltung der Artikel (ARTIK) mit Einheiten, Varianten, Logs und Sonderartikeln. |
| M042 | Barcode | src/backend/Centron.BL/Warehousing/Barcode*.cs | Barcodeverwaltung inkl. Historie und Bedingungen. |
| M043 | Produktion | src/backend/Centron.BL/Production | Fertigungsaufträge mit Positionen und Protokoll. |
| M044 | TradePool | src/backend/Centron.BL/TradePool | Import/Verwaltung von Handelsware-Pools (Distributorenartikel) und Kundenzuordnung. |
| M045 | Produktmatrix | src/backend/Centron.BL/ProductMatrix | Bewertungsmatrix Kunde × Produktkategorie (IT-Portfolio-Beratung). |
| M046 | Produktlebenszyklus | src/backend/Centron.BL/Finances/ProductLifecycleBL.cs | Lebenszyklusdaten zu Produkten (z. B. EOL) für Beratung/Planung. |
| M047 | Konten-/Adressstamm (Accounts) | src/backend/Centron.BL/Accounts | Neuer vereinheitlichter Konten-/Adress-/Kontaktstamm (Accounts) mit Kunden-/Lieferantenrollen. |
| M048 | Lieferantenstamm | src/backend/Centron.BL/BusinessPartner | Suche/Verwaltung von Lieferanten und Lieferanten-Assets. |
| M049 | Mitarbeiter/Personal | src/backend/Centron.BL/EmployeeArea | Mitarbeiterstamm mit Abteilungen, Urlaub, RFID-Token, Benutzerzuordnung. |
| M050 | Länder/Bundesländer | src/backend/Centron.BL/CountryArea | Länder- und Bundeslandstamm inkl. Währungsangaben. |
| M051 | Kostenstellen/Kostenträger | src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter; DB: Kostenstellen, Kostentraeger | Verwaltung von Kostenstellen und Kostenträgern. |
| M052 | CRM-Kataloge | src/backend/Centron.BL/CustomerArea (BusinessLineBL, InterestBL, ProductBL, ContactActivityBL, ContactDepartmentBL) | Katalogdaten für CRM: Branchen, Interessen, Produkte, Kontaktaktivitäten. |
| M053 | Textmodule/Anreden | src/backend/Centron.BL/TextModuleArea | Textbausteine sowie Anrede-/Grußformel-Ersetzung. |
| M054 | Tags | src/backend/Centron.BL/Tags | Freie Verschlagwortung (v. a. Tickets). |
| M055 | FiBu-Export/-Import | src/backend/Centron.BL/DataExchange/BookKeeping; Administration/BookKeepingAccountSystems | Übergabe von Stammdaten, Belegen und Kassenbuch an Finanzbuchhaltungen (u. a. DATEV, Abacus) und Rückimport. |
| M056 | Zahlungsverkehr (SEPA) | src/backend/Centron.BL/DataExchange/PaymentTransactions | Export von Lastschriften/Zahlungen als SEPA-XML (pain.008-Varianten). |
| M057 | Zahlungseingänge | src/backend/Centron.BL/Finances/IncomingPayments | Erfassung/Protokollierung von Zahlungseingängen auf Rechnungen. |
| M058 | OnlineBanking (finAPI) | src/backend/Centron.BL/Finances/OnlineBanking; src/apis/Centron.APIs.FinAPI | Abruf von Kontoumsätzen über finAPI und Zuordnung zu Belegen. |
| M059 | Bankkonten | src/backend/Centron.BL/Accounting/BankAccountBL.cs | Verwaltung von Bankverbindungen von Kunden/Firmen. |
| M060 | E-Rechnung | docs/reference/zugferd-field-mapping.md; docs/guides/development/xrechnung.md; src/apis/Centron.Api.EbInterface | Erzeugung elektronischer Rechnungen (ZUGFeRD/XRechnung, ebInterface AT). |
| M061 | Gutschein-/Voucherverwaltung | src/backend/Centron.BL/VoucherManagement | Verwaltung von Gutschein-Barcodes. |
| M062 | Finanzen Sonstiges | src/backend/Centron.BL/Finances/Payments, Finances/ActivitySettings | Zahlungsarten/Aktivitätseinstellungen im Finanzumfeld. |
| M063 | Authentifizierung | src/backend/Centron.BL/Administration/Logins/Auth | Anmeldung per Benutzername/Passwort, Active Directory, OpenID Connect (Entra ID) und Web-Account. |
| M064 | Zwei-Faktor-Authentifizierung | src/backend/Centron.BL/Administration/Logins/TwoFactor; Centron.BL/TwoFactorAuthenticator | Zweiter Faktor per RADIUS oder E-Mail-Link mit Gültigkeitsdauer je Gerät. |
| M065 | Benutzerverwaltung | src/backend/Centron.BL/Administration/Logins/UsersBL.cs; EmployeeArea/AppUserBL.cs | Verwaltung der Anwendungsbenutzer (Sichbenu) inkl. Deaktivierungszeiträumen. |
| M066 | Web-Accounts | src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs | Logins für Endkunden-Kontakte (Portal/Shop) mit Statusprüfung. |
| M067 | Rechteverwaltung | src/backend/Centron.BL/Administration/Rights; CentronRights.md; webservice/.../UserRightsConst.cs | Rechte/Gruppen (Sichtrus/Sichmemb/Sichbenu) inkl. einschränkender Rechte (nur eigene / eigene Filiale). |
| M068 | Lizenzierung | src/backend/Centron.BL/Administration/Licensing | Prüfung von Produktlizenzen, Versionsbeschränkung und paralleler Nutzeranzahl. |
| M069 | Sitzungs-/Ticketverwaltung | src/backend/Centron.BL/Administration/Logins/TicketBL.cs, AuthenticationTicketBL.cs | Vergabe/Wiederverwendung von Anmelde-Tickets je Anwendung/Maschine. |
| M070 | Anwendungseinstellungen | src/backend/Centron.BL/Administration/Settings; Centron.Interfaces/Administration/Settings | Zentrale, typisierte Konfiguration (ApplicationSettings) mit Definitionen und Gruppen. |
| M071 | Mandanten | src/backend/Centron.BL/Administration/Company/MandatorBL.cs | Mandantenverwaltung. |
| M072 | Filialen | src/backend/Centron.BL/Administration/Company/BranchBL.cs | Filialverwaltung inkl. filialbezogener Konten und Läger. |
| M073 | Nummernkreise | src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs; Administration/Mandatory | Vergabe fortlaufender Nummern je Objektart (und Filiale) mit Kollisionsschutz. |
| M074 | DB-Migrationsskripte | src/backend/Centron.BL/Administration/Scripts (ScriptMethods) | Versionierte Datenbank-Migrations-/Wartungsskripte. |
| M075 | DSGVO/Datensicherheit | src/backend/Centron.BL/Administration/DataSecurity; WebServices/Administration/Documents/Dsgvo | Datenschutzfunktionen (DSGVO-Dokumente, Datensicherheit). |
| M076 | Dokumente/Dateiverwaltung | src/backend/Centron.BL/Administration/Documents, FileManagement; WPF: CentronFileSystem | Ablage und Verwaltung von Dokumenten/Dateien zu Objekten. |
| M077 | Hintergrunddienste | src/backend/Centron.BL/Administration/BackgroundServices; docs/Background Service | Serverseitige Hintergrundverarbeitung (z. B. Datenqualitätsdienst). |
| M078 | AccessTokens | src/backend/Centron.BL/Administration/AccessTokens | Verwaltung von API-/Zugriffstokens. |
| M079 | Telemetrie | src/backend/Centron.BL/Telemetry | Erfassung von Nutzungsdaten (API-Aufrufe, KI-/MCP-Toolnutzung). |
| M080 | Themes/Customizing | src/backend/Centron.BL/Administration/Themes, Customization; Centron.BL/Customizations/CustomTables | Oberflächen-Themes und kundenspezifische Erweiterungen/Zusatztabellen. |
| M081 | SQL-/Systemdiagnose | src/backend/Centron.BL/Administration/SQLManagement, NetworkDiagnostics, Profiling, PerformanceTests | Administrative Diagnose- und Wartungswerkzeuge. |
| M082 | Passwortverwaltung (Kundenzugänge) | src/backend/Centron.BL/PasswordManagementArea, PasswordManager | Verschlüsselte Ablage von Zugangsdaten mit Zugriffs-/Änderungsprotokoll. |
| M083 | Mail | src/backend/Centron.BL/Mail | Mailkonten, -einstellungen, -signaturen und Mailversand. |
| M084 | MailScanner | src/backend/Centron.BL/MailScanner | Überwachung von Postfächern und regelbasierte Verarbeitung (z. B. Ticketerzeugung). |
| M085 | Mailings/Newsletter | src/backend/Centron.BL/Mailings | Serienmails/Newsletter mit Vorlagen. |
| M086 | Kalender/Termine | src/backend/Centron.BL/Calendar, AppointmentRequests; Sales/Calendar | Terminkalender inkl. Terminwünschen und Synchronisationseinstellungen. |
| M087 | Chats | src/backend/Centron.BL/Chats | Interner Chat mit Gruppen, Nachrichten, Bearbeiten/Löschen. |
| M088 | SocialMedia-Feed | src/backend/Centron.BL/SocialMedia | Interner Aktivitäten-Feed mit Kommentaren, Likes und Abos auf Objekte. |
| M089 | TAPI-Telefonie | src/backend/Centron.BL/Tapi; assemblies/tapi | Telefonie-Integration: Anruferkennung, Anrufprotokolle, Kontaktsuche per Rufnummer. |
| M090 | ToDo | src/backend/Centron.BL/ToDoArea | Aufgaben-/Wiedervorlagenverwaltung an Objekten. |
| M091 | MyDay/MyCentron | src/backend/Centron.BL/MyDay, MyCentron | Persönliche Tagesübersicht (Arbeitsvorrat) und zuletzt verwendete Objekte. |
| M092 | Benachrichtigungen | src/backend/Centron.BL/Notifications, NexusNotifications | Benutzerbenachrichtigungen im Client und Web (SignalR-Hub). |
| M093 | Outlook-Integration | src/nexus/CentronNexus.OutlookAddIn; Centron.BL/Outlook; assemblies/outlook | Outlook-AddIn zur Verbindung von E-Mails mit c-entron-Objekten. |
| M094 | WebLinks/Kurz-URLs | src/backend/Centron.BL/WebLinks, Urls | Verwaltete Weblinks mit Aktionen und Klick-Protokoll sowie einfache URL-Verwaltung. |
| M095 | Mobile | src/backend/Centron.BL/Mobile | Datenbereitstellung für die mobile Nutzung (mobile Mitarbeiter). |
| M096 | ReportEngine (FastReport) | src/backend/Centron.BL/ReportEngine | Berichtsdefinitionen, -gruppen, -abfragen und Standardberichte je Ausgabekanal. |
| M097 | Berichte (Alt) | src/backend/Centron.BL/Reporting; UI: Modules/Reports | Verwaltung/Rendern klassischer Berichte. |
| M098 | Statistiken | src/backend/Centron.BL/Statistics | Umsatz-, Auftrags-, Ticket-, Vertrags- und MSP-Statistiken. |
| M099 | Volltextsuche | src/backend/Centron.BL/IndexSearch | Lucene-basierter Volltextindex mit deutschem Analyzer über Fachobjekte. |
| M100 | Massenupdates | src/backend/Centron.BL/MassUpdate; UI: Modules/Massenupdates | Massenänderungen an Belegen, Artikeln und Kontodaten über Vorlagen. |
| M101 | Änderungsverfolgung | src/backend/Centron.DAO/ChangeTracking; Centron.BL/ChangeTracking | Feldgenaue Änderungsprotokolle (ChangeLog) über NHibernate-Events. |
| M102 | Import-Historie | src/backend/Centron.BL/ChangeTracking/History (ImportHistoryBL.cs) | Protokollierung durchgeführter Datenimporte. |
| M103 | Erwartete Ereignisse | src/backend/Centron.BL/ExpectedEvents | Überwachung erwarteter Ereignisse (Log je Konto) mit Fehlverhaltensanzeige. |
| M104 | Prozesse (Langläufer) | src/backend/Centron.BL/Processes | Verwaltung langlaufender Verarbeitungsprozesse. |
| M105 | Fachliche Transaktionen | src/backend/Centron.BL/Transactions | Protokollierung fachlicher Transaktionen mit Details je Benutzer. |
| M106 | KI-Funktionen | src/backend/Centron.BL/ArtificialIntelligence; Administration/ArtificialIntelligence | Anbindung von KI-Modellen (u. a. OpenAI-kompatibel) für Ticket-Kategorisierung, Textbewertung, Zusammenfassungen. |
| M107 | EDI | src/backend/Centron.BL/EDI; DataExchange/EDI; src/backend/Centron.Gateway | Elektronischer Belegaustausch mit Distributoren (ALSO, Alltron, Herweck, Komsa, OpenTrans 2.1 u. a.). |
| M108 | docuFORM | Centron.Api.docuFORM; Centron.BL/DataExchange/DocuForm | Anbindung docuFORM (Druckerzähler/Verbrauchsdaten). |
| M109 | RMM-/AssetManagement-Connector | src/backend/Centron.BL/DataExchange/Rmm; Centron.BL/DocuBoard (AssetManagement*) | Anbindung von Remote-Monitoring-Systemen und Übernahme erkannter Geräte. |
| M110 | TANSS-Schnittstelle | src/backend/Centron.BL/DataExchange/TanssInterfaces | Datenaustausch mit TANSS. |
| M111 | Telekom DIVE | src/backend/Centron.BL/DataExchange/TelekomDive; UI: Modules/TelekomDive | Export von Artikel-/Kategoriedaten an Telekom DIVE. |
| M112 | GfK-Export | src/backend/Centron.BL/DataExchange/GfkExport | Meldung von Abverkaufsdaten an GfK. |
| M113 | Datenimport | src/backend/Centron.BL/DataExchange/Import, Connectors | Generische Importe und Konnektoren. |
| M114 | ITscope | src/apis/Centron.APIs.ITscopeDataAccess | Anbindung ITscope (Distributorenkatalog/Bestellung). |
| M115 | Icecat | src/apis/Centron.APIs.IcecatDataAccess | Übernahme von Artikelstammdaten aus Icecat. |
| M116 | COP | src/apis/Centron.APIs.CopDataAccess | SOAP-Anbindung COP (Distributor). |
| M117 | EGIS | src/apis/Centron.APIs.EgisDataAccess; Centron.BL/EDI/EGIS | Anbindung EGIS (Warenkorb/Bestellungen). |
| M118 | GLS-Versand | src/apis/Centron.Api.Gls | Erzeugung von GLS-Versandaufträgen/Labels. |
| M119 | Shipcloud-Versand | src/apis/Centron.Api.Shipcloud; Sales/Receipts/ShipcloudPackageTemplateBL.cs | Versandabwicklung über Shipcloud inkl. Pakettemplates. |
| M120 | RiverDivo/Riverbird | src/backend/Centron.BL/RiverDivo; deployment/riverbird | Kopplung an Riverbird/RiverDivo (Remote-Zugriff/Servicedaten). |
| M121 | C-Pra | src/backend/Centron.BL/CPra | Anbindung C-Pra (WebHooks). |
| M122 | ES-Integrationen | src/backend/Centron.BL/Integrations (EsCustomerGroupBL, EsRoleBL) | Rollen-/Kundengruppenabgleich mit einem externen System (ES). |
| M123 | Custom Gateway | src/backend/Centron.BL/Gateway; WebServices/Gateway | Konfigurierbares Gateway für kundenspezifische externe Aufrufe. |
| M124 | Objekt-Fremdreferenzen | src/backend/Centron.BL/ObjectExternalReferences | Zuordnung externer IDs zu c-entron-Objekten. |
| M125 | SelfCare-Formulare | src/backend/Centron.BL/SelfCare | Konfigurierbare Web-Formulare (Self-Service) mit Status. |
| M126 | Externe Tools | src/backend/Centron.BL/ExternalToolsBL, Tools; UI: Modules/ExternalTool | Einbindung externer Programme mit Variablenübergabe. |
| M127 | VideoPortal | src/backend/Centron.BL/VideoPortal | Zuordnung von Schulungs-/Videoinhalten. |
| M128 | IT-Planner | src/backend/Centron.BL/ItPlanner | Checklisten-/Planungsobjekte für IT-Planungen. |
| M129 | DocuBoard | src/backend/Centron.BL/DocuBoard | Verwaltung AssetManagement-Partner/Artikelzuordnungen (Dokumentationsboard). |
| M130 | WPF-Client (Shell) | src/centron/Centron.WPF.UI | Windows-Desktop-Client: Modulrahmen, Navigation, Layouts, Dialoge, Lokalisierung. |
| M131 | Webservice/Backend-Host | src/webservice (Centron.Host, Centron.WebServices.Core, Centron.Host.WindowsService, Centron.Host.Console) | Zentraler Anwendungsserver (SOAP/REST) als Windows-Dienst, Konsole oder Container. |
| M132 | REST-API v1 | src/webservice/Centron.Controllers | Versionierte REST-Schnittstelle mit JWT-Authentifizierung und Rechte-Attributen. |
| M133 | Nexus-Webclient | src/nexus/CentronNexus, CentronNexus.Host | Blazor-Webclient (ServiceBoard, Management, Office, WebCart, WebOffer, Produktionsaufträge, Dokumentensignatur). |
| M134 | DAO/Persistenz | src/backend/Centron.DAO | NHibernate-Datenzugriff mit Repositories, Named Queries, RawSQL und Mappings. |
| M135 | Entities/Datenmodell | src/backend/Centron.Entities; SSMS_DB_SCHEMA.sql | Entitätsmodell und MSSQL-Schema (1.558 Tabellen, Legacy-Tabellen + englische Views). |
| M136 | Basisbibliotheken | src/backend/Centron.Common, Centron.Interfaces; src/shared/Centron.Core, Centron.Controls | Querschnittsfunktionen, Interfaces/DTO-Verträge, WPF-Controls. |
| M137 | ConnectionManager | src/webservice/c-entron.misc.ConnectionManager | Werkzeug zur Verwaltung von Verbindungsprofilen. |
| M138 | Deployment/Installer | deployment (centron, WixSharpInstaller, riverbird) | Erstellung der Installationspakete. |
| M139 | Docker/Linux-Betrieb | docker/; docs/guides/services/web-service-on-linux.md | Containerisierter Betrieb von Webservice, Demo, Mailcatcher, Regressionstest-DB. |
| M140 | CI/CD | azure/, .github/workflows | Automatisierte Builds/Pipelines. |
| M141 | Tests | tests/ (Integration, EndToEnd, Playwright, Unit) | Automatisierte Test-Suiten. |
| M142 | Modulverwaltung | src/backend/Centron.BL/Modules; WPF: Modules/ModuleRegistration.cs | Registrierung/Kategorisierung der Anwendungsmodule inkl. Rechtebindung. |
| M143 | Start/Versionsprüfung | src/backend/Centron.BL/Start, WebVersion, WebSuite | Startlogik des Clients inkl. Versionsabgleich mit dem Webservice. |
| M144 | GUI-Personalisierung | src/backend/Centron.BL/GUI (UserGridBL.cs); Administration/Themes | Speicherung benutzerspezifischer Grid-/Oberflächeneinstellungen. |
| M145 | Caching-Dienste | src/backend/Centron.BL/Services (CachedTableBL.cs) | Serverseitiges Tabellen-Caching. |
| M146 | Icons | src/backend/Centron.BL/CentronIcons | Verwaltung der Anwendungs-Icons. |
| M147 | Zeitsteuerung | src/backend/Centron.BL/Time (TimingSettingsBL.cs) | Timing-/Zeiterfassungseinstellungen. |
| M148 | SystemArea | src/backend/Centron.BL/SystemArea (SystemTableI3DBL.cs) | Systemtabellen-/ID-Verwaltung. |
| M149 | Helpers | src/backend/Centron.BL/Helpers | Hilfsfunktionen (PDF, Word-Bilder, Graph-Client, Logging). |
| M150 | Kern-Krypto | src/backend/Centron.BL/Core (CryptoUtils.cs, ReplacementBL.cs) | Salz-/Hash-Erzeugung und Platzhalter-Ersetzung. |
Nachträgliche Ergänzungen des Inventars sind unter „1a. Inventar-Ergänzungen" zu führen (keine vorhanden).
---
## 2. Abdeckungstabelle
*(wird nach Abschluss der Anforderungserhebung gefüllt – siehe Abschnitt am Ende dieses Dokuments)*
## 3. Konsistenzcheck
*(wird nach Abschluss der Anforderungserhebung gefüllt)*
## 4. Risikorelevante Anforderungen
*(wird nach Abschluss der Anforderungserhebung gefüllt)*
## 5. Selbstbewertung
*(wird nach Abschluss der Anforderungserhebung gefüllt)*
@@ -0,0 +1,600 @@
# StRS – Stakeholder Requirements Specification
c-entron ERP-Suite (Reverse Requirements Engineering, statische Analyse).
Referenzrahmen: ISO/IEC/IEEE 29148:2018. Sprache: Deutsch; technische Bezeichner original.
**Identifizierte Akteure (aus Code, Rechte-Doku und UI-Ressourcen abgeleitet):**
Innendienst/Vertrieb, Servicetechniker, Helpdesk-Mitarbeiter, Buchhaltung, Einkäufer,
Lagermitarbeiter, Administrator, Geschäftsführung/Controlling, Endkunde (Web-Account),
Mandant/Filiale als Organisationseinheiten, externe Systeme (Distributoren, FiBu, Banken).
---
```
ID: StRS-001
Titel: Durchgängige Auftragsabwicklung über Belegkette
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Innendienst/Vertrieb
Vorbedingung: Kunde und Artikel sind als Stammdaten angelegt.
Fakt: Die Codebasis führt die Belegarten Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholschein und Vertrag als eigenständige, gemeinsam verankerte Belegtypen (ReceiptBase-Hierarchie, Tabellen AngKopf/AufKopf/LiefKopf/RechKopf/GutKopf/AbholKopf/VertragKopf).
Aussage: Das System soll den Vertriebsprozess vom Angebot über Auftrag und Lieferung bis zur Rechnung/Gutschrift als zusammenhängende Belegkette unterstützen.
Ergebnis: Ein Geschäftsvorfall ist über alle Belegstufen dokumentiert und nachvollziehbar.
Belege:
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs (abstrakte Basisklasse, abstrakte Methode ReceiptKind) – Begründung: gemeinsame Belegbasis aller Belegarten ist im Code verankert.
- [SEKUNDÄR] docs/reference/receipts/receipts-backend-architecture.md (Tabelle „Receipt Types Hierarchy") – Begründung: Entwicklerdokumentation benennt alle Belegarten und ihre DB-Tabellen.
Prüfidee: Für einen Testkunden Angebot→Auftrag→Lieferschein→Rechnung erzeugen; jede Stufe referenziert die Vorstufe.
Tracelinks: SyRS-010, SyRS-011, SyRS-012
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Kernprozess jedes ERP-Systems.
Status: belegt
```
```
ID: StRS-002
Titel: Automatisierte wiederkehrende Vertragsabrechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung
Vorbedingung: Verträge mit Abrechnungsintervall und Positionen existieren.
Fakt: AutomaticFacturaBL/AutomaticFacturaBL.Contracts.cs implementieren Suche abrechenbarer Verträge (SearchBillingContracts), Intervallfortschreibung (SetNextBillingDate, NextDate) und Rechnungszuordnung (StoreInvoiceToContract) inkl. Normalisierungskoeffizienten (MonthNormalizeCoefficient u. a.).
Aussage: Das System soll wiederkehrende Leistungen (Wartung, Miete, Kontingente, Klickzähler) aus Verträgen automatisiert und periodengerecht in Rechnungen überführen.
Ergebnis: Zum Stichtag fällige Verträge sind fakturiert; das nächste Abrechnungsdatum ist fortgeschrieben.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Methoden SearchBillingContracts / SetNextBillingDate / StoreInvoiceToContract – Begründung: durchsetzende Abrechnungslogik (Auswahl fälliger Verträge, Fortschreibung, Rechnungszuordnung).
- [SEKUNDÄR] docs/reference/receipts/contracts-backend.md (Billing Configuration: BillingIntervalKind, AutomatedBilling) – Begründung: dokumentiert die fachlichen Abrechnungsparameter am Vertrag.
Prüfidee: Vertrag mit Monatsintervall anlegen, Abrechnungslauf zum Stichtag ausführen; genau eine Rechnung entsteht, LastInvoiceDate/nächstes Datum korrekt fortgeschrieben.
Tracelinks: SyRS-020
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – zentrales Umsatzmodell (MSP/Servicevertrieb) der Zielgruppe.
Status: belegt
```
```
ID: StRS-003
Titel: Forderungsmanagement mit Mahnwesen und offenen Posten
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung
Vorbedingung: Rechnungen mit Fälligkeit sind gebucht.
Fakt: DunningRunBL führt Mahnläufe mit drei Mahnstufen (DunningLevel.Level1–Level3) und fortlaufender Mahnlaufnummer aus; DunningBL kennt Mahnstopp (DunningStop, DunningStopBegin/End); OposBL/OposRunBL verwalten offene Posten.
Aussage: Das System soll überfällige Forderungen erkennen, in bis zu drei Mahnstufen anmahnen (Druck oder E-Mail) und offene Posten auswerten; einzelne Kunden/Rechnungen sollen vom Mahnlauf ausgenommen werden können (Mahnstopp).
Ergebnis: Mahnungen sind erzeugt und dokumentiert; Mahnstufen der Rechnungen sind fortgeschrieben.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methode UpdateInvoice (switch über DunningLevel None→1→2→3) – Begründung: durchgesetzte Mahnstufenlogik.
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Methode SetDunningStop (setzt DunningStop/Begin/End am AccountCustomer) – Begründung: durchgesetzter Mahnstopp.
Prüfidee: Überfällige Rechnung dreimal anmahnen; vierte Mahnung wird abgelehnt (ArgumentOutOfRangeException-Pfad), Mahnstopp verhindert Aufnahme in den Lauf.
Tracelinks: SyRS-021, SyRS-022
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – gesetzlich/kaufmännisch erforderliches Forderungsmanagement.
Status: belegt
```
```
ID: StRS-004
Titel: SEPA-Zahlungsverkehr für Lastschriften
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung
Vorbedingung: Rechnungen mit Lastschrift-Zahlungsart und Bankverbindung/Mandat liegen vor.
Fakt: PaymentTransactionBL exportiert Rechnungen als SEPA-Lastschriftdateien in den Formatvarianten Sepa0080101/0080302/0080102/00800102GBIC3/00800108GBIC4 (enum PaymentTransactionInterface) und markiert exportierte Rechnungen (SetInvoicesAsExported).
Aussage: Das System soll fällige Lastschriften als bankfähige SEPA-XML-Dateien exportieren und den Exportstatus je Rechnung nachhalten.
Ergebnis: Eine SEPA-Datei je Lauf; exportierte Rechnungen sind gekennzeichnet und können zurückgesetzt werden.
Belege:
- [PRIMÄR] src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, Methoden ExportInvoices / SetInvoicesAsExported / ResetInvoiceExportedFlag – Begründung: durchsetzende Exportlogik inkl. Statusführung.
- [PRIMÄR] src/backend/Centron.Interfaces/DataExchange/PaymentTransactions/PaymentTransactionInterface.cs (enum mit pain.008-Varianten) – Begründung: implementierte Formatvarianten.
Prüfidee: Export mit zwei Testrechnungen ausführen; XML validiert gegen pain.008-Schema, erneuter Lauf enthält die Rechnungen nicht mehr.
Tracelinks: SyRS-023
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Zahlungsabwicklung ist Pflicht; Formatversionen im Zielsystem aktualisieren.
Status: belegt
```
```
ID: StRS-005
Titel: Übergabe an die Finanzbuchhaltung
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Buchhaltung; externes FiBu-System (u. a. DATEV, Abacus)
Vorbedingung: Belege bzw. Stammdaten sind freigegeben/abgeschlossen.
Fakt: BookKeepingExportBL exportiert Kunden-/Lieferantenstammdaten, Kunden-/Lieferantenbelege und Kassenbuch (enum BookKeepingExportKind) mit Übergabehistorie (GetBookKeepingExport*History) und Doppel-Export-Schutz (IsReceiptExported); zahlreiche DATEV-Einstellungen existieren (ApplicationSettingID.Datev*).
Aussage: Das System soll Debitoren/Kreditoren, Buchungsdaten der Belege und Kassenbuchdaten an Finanzbuchhaltungssysteme übergeben, Übergaben protokollieren und Doppelübergaben verhindern.
Ergebnis: Exportdateien im Zielformat; Historie der Übergaben ist einsehbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs, Methoden IsReceiptExported / GetReceiptsBookingdataExportFile / GetCustomerDataExportFile – Begründung: durchsetzende Export- und Schutzlogik.
- [SEKUNDÄR] src/backend/Centron.Interfaces/Administration/Settings/ApplicationSettingID.cs (DatevOnlineSavePath, DatevFolderForInvoice u. a.) – Begründung: Konfigurationsschalter belegen DATEV-Integration.
Prüfidee: Abgeschlossene Rechnung exportieren; zweiter Exportversuch wird als bereits exportiert erkannt.
Tracelinks: SyRS-024
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Kernanforderung im deutschen Markt (DATEV-Anbindung).
Status: belegt
```
```
ID: StRS-006
Titel: Kassenführung in Filialen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Filialmitarbeiter, Buchhaltung
Vorbedingung: Kassenbuch je Filiale eingerichtet.
Fakt: Sales/CashBooks enthält CashBookBL, CashBookBookingBL, CashBookRecordBL mit Buchungen, Löschregeln und Verknüpfung zu Belegen; Kassenbuchdaten sind Teil des FiBu-Exports (BookKeepingExportKind.Cashbook).
Aussage: Das System soll Barbewegungen je Kasse als Kassenbuch führen und in die Buchhaltung überleiten.
Ergebnis: Kassenbuchungen sind erfasst, mit Belegen verknüpft und exportierbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/CashBooks/CashBookBookingBL.cs, Methoden DeleteCashBookBooking / GetCashBookBookingsFromAsset – Begründung: implementierte Kassenbuchlogik mit Belegbezug.
Prüfidee: Kassenbuchung zu einem Beleg anlegen und im FiBu-Export „Cashbook" wiederfinden.
Tracelinks: SyRS-024
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – für Filialbetriebe mit Barverkauf erforderlich.
Status: belegt
```
```
ID: StRS-007
Titel: Serviceticket-Management mit abrechenbarer Zeiterfassung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Helpdesk-Mitarbeiter, Servicetechniker, Serviceleitung
Vorbedingung: Kunde existiert; Ticketstammdaten (Typen, Status, Prioritäten, Kategorien) sind gepflegt.
Fakt: Sales/Support enthält >50 BL-Klassen für Tickets (HelpdeskBL, HelpdeskStatusBL, HelpdeskCloseBL, HelpdeskHistoryBL, Escalation, HelpdeskTimer*); Zeiten können signiert (HelpdeskTimerSignatureBL) und Artikeln/Belegen zugeordnet werden (HelpdeskTimerArticleBookingBL); Rechte-Doku CentronRights.md beschreibt Zeiten-Verschiebung nur, solange das Ticket nicht Teil eines Belegs ist.
Aussage: Das System soll Kundenanfragen als Tickets mit Status, Kategorien, Prioritäten, Historie und Eskalation verwalten; erfasste Arbeitszeiten sollen vom Kunden signierbar und in die Fakturierung überführbar sein.
Ergebnis: Tickets sind lückenlos dokumentiert; geleistete Zeiten fließen in Belege ein.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskCloseBL.cs, Methode CloseHelpdesk (setzt HelpdeskState=closed, ClosedAt, erzeugt Historie/Aktivität) – Begründung: durchgesetzter Ticket-Abschlussprozess.
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs, Methoden AddSignature / SignMultipleTimers / RemoveSignatureFromTime – Begründung: implementierte Signaturfunktion auf Zeiteinträgen.
- [KONTEXT] CentronRights.md Abschnitt 8/9 („nur wenn das Ticket nicht Teil eines Belegs ist") – Begründung: bestätigt die Kopplung Zeiterfassung↔Beleg.
Prüfidee: Ticket mit Zeiteintrag anlegen, signieren, abrechnen; danach ist Verschieben/Löschen des Zeiteintrags gesperrt.
Tracelinks: SyRS-030, SyRS-031, SyRS-032
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Kern des Servicegeschäfts (Systemhaus/MSP).
Status: belegt
```
```
ID: StRS-008
Titel: Zentrale Kunden- und Kontaktverwaltung (CRM)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Innendienst, Service
Vorbedingung: –
Fakt: Parallel existieren der Alt-Kundenstamm (Tabellen Kunden/Anschrif/Personen, Sales/Customers) und der neue Konten-/Adressstamm (Accounts, AccountAddress, AccountAddressContact in Centron.BL/Accounts) mit Kunden-/Lieferantenrollen (AccountCustomers/AccountSuppliers).
Aussage: Das System soll Geschäftspartner mit Adressen, Ansprechpartnern, Rollen (Kunde/Lieferant), Branchen, Interessen und Aktivitäten zentral verwalten.
Ergebnis: Ein Geschäftspartner ist einheitlich auffindbar und in allen Prozessen referenzierbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs, Methoden GetAccount / CreateNewAccountTypeForAccount – Begründung: implementierter vereinheitlichter Kontenstamm.
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Accounts / AccountCustomers / AccountSuppliers / Kunden – Begründung: beide Datenhaltungen existieren im Schema.
Prüfidee: Konto mit Kunden- und Lieferantenrolle anlegen; beide Rollen in Verkauf und Einkauf nutzbar.
Tracelinks: SyRS-040
Konsolidierung: Kandidat: Alt-Kundenstamm (Kunden/Anschrif/Personen) und Accounts-Stamm bilden denselben fachlichen Gegenstand ab und sollen im Zielsystem zu einem Partnerstamm zusammengeführt werden.
Übernahmewürdigkeit: übernehmen – Stammdatenbasis aller Prozesse; Zusammenführung der Doppelstruktur nötig.
Status: belegt
```
```
ID: StRS-009
Titel: Einkauf mit elektronischer Distributorenanbindung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Einkäufer; Distributoren (ALSO, Alltron, Herweck, Komsa, ITscope, EGIS u. a.)
Vorbedingung: Lieferant mit EDI-Konfiguration vorhanden.
Fakt: EDIDispatcherBL erzeugt/überträgt Bestellungen elektronisch (CreateEDISuggestionOrderAsync, EdiEgisOrderUploadAsync, EdiItScopeOrderUploadAsync, EdiConcertoOrderUploadAsync); docs/reference/edi beschreibt Verarbeitung von Bestellantworten, Lieferavisen und Rechnungen je Lieferant.
Aussage: Das System soll Bestellungen elektronisch an Distributoren übertragen und deren Rückmeldungen (Auftragsbestätigung, Lieferavis, Rechnung) automatisiert verarbeiten.
Ergebnis: Bestellprozesse laufen ohne manuelle Doppelerfassung; EDI-Vorgänge sind protokolliert (EDILogBL).
Belege:
- [PRIMÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs, Methoden EdiEgisOrderUploadAsync / EdiItScopeOrderUploadAsync – Begründung: durchsetzende Übertragungslogik.
- [SEKUNDÄR] docs/reference/edi/edi-architecture.md (SupplierEdiBL-Partialklassen je Distributor) – Begründung: dokumentiert die unterstützten Distributoren und Belegflüsse.
Prüfidee: Testbestellung im OpenTrans-2.1-Format erzeugen und gegen Schema prüfen.
Tracelinks: SyRS-050
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – zentrale Effizienzfunktion für IT-Handel.
Status: belegt
```
```
ID: StRS-010
Titel: Lager- und Bestandsführung mit Inventur
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Lagermitarbeiter
Vorbedingung: Läger und Artikel sind angelegt.
Fakt: StockBL verwaltet Läger inkl. Filialzuordnung und Umbuchungsprotokoll (WriteStockRebookLog); StorageBL/InventoryArticlePool implementieren Inventur (AddInventory, RefreshInv) mit Transaktionssteuerung.
Aussage: Das System soll Bestände je Lager führen, Umbuchungen protokollieren und Inventuren mit Bestandsabgleich unterstützen.
Ergebnis: Bestände sind je Lager korrekt; Umbuchungen und Inventuren sind nachvollziehbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs, Methode WriteStockRebookLog – Begründung: durchgesetzte Protokollierung von Lagerumbuchungen.
- [PRIMÄR] src/backend/Centron.BL/Storage/StorageBL.cs, Methoden AddInventory / StartTransaction / CommitTransaction – Begründung: implementierte Inventurlogik.
Prüfidee: Umbuchung zwischen zwei Lägern erzeugen; RebookLog-Eintrag vorhanden; Inventur ändert Bestand nachvollziehbar.
Tracelinks: SyRS-051, SyRS-052
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Grundfunktion Warenwirtschaft.
Status: belegt
```
```
ID: StRS-011
Titel: Artikelstamm mit differenzierter Preisfindung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Produktmanagement, Vertrieb
Vorbedingung: –
Fakt: Warehousing enthält ArticleBL mit Spezialartikeln (Fracht-, Kundenrabatt-, Kontingentausgleichsartikel), ActionPriceBL (Aktionspreise), ArticleVolumePricesBL (Staffelpreise), CustomerSpecialArticleBL (kundenspezifische Sonderpreise); ReceiptPriceHelperBL berechnet Positions- und Belegpreise inkl. MwSt., Rabatt und Währungsfaktor.
Aussage: Das System soll Artikel mit Einkaufs-/Verkaufspreisen führen und bei der Belegerstellung die Preisfindung aus Listenpreis, Aktionspreis, Staffelpreis und kundenindividuellem Sonderpreis anwenden.
Ergebnis: Belegpositionen erhalten nachvollziehbar den korrekten Preis inkl. Steuer.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptPriceHelperBL.cs, Methoden CalculateReceiptItemPrices / CalculateReceiptVatPrices – Begründung: durchsetzende Preis-/Steuerberechnung.
- [PRIMÄR] src/backend/Centron.BL/Warehousing/ActionPriceBL.cs, ArticleVolumePricesBL.cs – Begründung: implementierte Preisarten.
Prüfidee: Artikel mit Listen-, Aktions- und Sonderpreis anlegen; Belegposition zieht die dokumentierte Priorität.
Tracelinks: SyRS-014, SyRS-053
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Kern der Warenwirtschaft.
Status: belegt
```
```
ID: StRS-012
Titel: Rollen- und rechtebasierter Zugriffsschutz
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Administrator, Geschäftsführung/Compliance
Vorbedingung: Benutzer, Gruppen und Rechte sind gepflegt.
Fakt: Rechte werden über Gruppen zugewiesen (SQL-Join Sichtrus→Sichmemb in AppRightsBL.CheckRightsFromUser); es existieren einschränkende Rechte („nur eigene", „nur eigene Filiale") laut CentronRights.md und deren Durchsetzung z. B. in HelpdeskBL (ShowHelpdeskRight.OnlyOwn/OnlyOwnBranch).
Aussage: Das System soll jede fachliche Funktion über ein feingranulares Rechtesystem (Benutzer→Gruppen→Rechte) schützen, einschließlich einschränkender Rechte auf eigene Datensätze bzw. die eigene Filiale.
Ergebnis: Benutzer sehen und bearbeiten nur Daten, für die ihnen Rechte zugewiesen sind.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode CheckRightsFromUser (SQL über dbo.Sichtrus/dbo.Sichmemb) – Begründung: durchsetzende Rechteprüfung.
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Zeilen 269–291 (Auswertung SHOW_HELPDESK_ONLY_OWN / _ONLY_OWN_BRANCH) – Begründung: durchgesetzte einschränkende Rechte.
- [SEKUNDÄR] CentronRights.md – Begründung: fachliche Beschreibung der Rechte inkl. Restriktionssemantik.
Prüfidee: Benutzer nur mit SHOW_HELPDESK_ONLY_OWN sieht ausschließlich Tickets, bei denen er Bearbeiter/Verantwortlicher ist.
Tracelinks: SyRS-001, SyRS-004, SyRS-005
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Compliance-Grundanforderung.
Status: belegt
```
```
ID: StRS-013
Titel: Kontrollierte Benutzeranmeldung mit Mehrfaktor-Option
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Alle Benutzer; Administrator
Vorbedingung: Benutzerkonto existiert und ist aktiv.
Fakt: Authentifizierung erfolgt wahlweise per Benutzername/Passwort (BasicAuthenticator), Active Directory, OpenID Connect/Entra ID oder Web-Account (AuthenticatorFactory-Varianten); deaktivierte Konten und Austrittsdaten verhindern die Anmeldung (Authenticator.ValidateAppUser); optional wird ein zweiter Faktor per RADIUS oder E-Mail-Link verlangt (TwoFactorAuthBL).
Aussage: Das System soll Benutzer sicher authentifizieren, deaktivierte oder ausgeschiedene Mitarbeiter abweisen und optional eine Zwei-Faktor-Authentifizierung mit konfigurierbarer Gültigkeitsdauer je Gerät erzwingen.
Ergebnis: Nur berechtigte, aktive Benutzer erhalten eine Sitzung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, Methode ValidateAppUser (Prüfung IsAccountDisabled, AccountDisabledFrom/ToDate, IsActiveEmployeeCompact) – Begründung: durchsetzende Kontoprüfung.
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs, Methode HasToValidateTwoFactor – Begründung: durchgesetzte 2FA-Pflichtlogik.
Prüfidee: Anmeldeversuch mit deaktiviertem Konto → Fehlermeldung „Mitarbeiterkonto wurde deaktiviert"; 2FA-Pflicht nach Ablauf der Gültigkeitsdauer.
Tracelinks: SyRS-001, SyRS-002, SyRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Sicherheitsgrundanforderung; Passwort-Hashing im Zielsystem modernisieren (siehe SwRS-Sicherheit).
Status: belegt
```
```
ID: StRS-014
Titel: Lizenzbasierte Nutzungssteuerung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Hersteller (c-entron Software), Administrator
Vorbedingung: Lizenzdatei/Lizenzserver verfügbar.
Fakt: LicenseManager.CheckLicense prüft je Anwendung Lizenz-GUID, Versionsbeschränkung und maximale gleichzeitige Nutzung (Ticketanzahl >= Lizenzanzahl → „Die maximale Anzahl an Lizenzen wurde erreicht.").
Aussage: Das System soll den Zugang je Anwendung/Modul an Lizenzen binden und die Anzahl gleichzeitiger Anmeldungen auf die lizenzierte Menge begrenzen.
Ergebnis: Anmeldung über Lizenzgrenze hinaus wird abgewiesen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, Methode CheckLicense (Vergleich currentlyUsedLicenses >= maxNumberOfLicenses) – Begründung: durchsetzende Lizenzprüfung.
Prüfidee: Bei Lizenzanzahl n meldet sich Benutzer n+1 an → Fehlermeldung Lizenzmaximum.
Tracelinks: SyRS-006
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall – herstellerseitiges Geschäftsmodell; im SaaS-Zielsystem durch Abo-/Mandantenmodell zu ersetzen.
Status: belegt
```
```
ID: StRS-015
Titel: Kundenselbstbedienung über Webportal
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Endkunde (Web-Account)
Vorbedingung: Web-Account für Kundenkontakt existiert und ist aktiv.
Fakt: CentronNexus enthält WebCart (Shop auf Basis Kunden-Sonderpreisen laut README), WebOffer, SelfCare-Formulare und Ticketfunktionen; Warenkörbe durchlaufen ein Freigabewesen (ReceiptCartReleaseSystemBL, nur Web-Account-Logins: Guard „Only web-account logins ready carts for check").
Aussage: Das System soll Endkunden ein Webportal bieten, in dem sie Artikel zu vereinbarten Preisen bestellen, Angebote einsehen, Formulare ausfüllen und Tickets verfolgen können; Bestellungen sollen kundenseitig einem Prüf-/Freigabeprozess unterliegen können.
Ergebnis: Kundenbestellungen erreichen den Innendienst strukturiert und freigegeben.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs, Methode ReadyCartForCheck – Begründung: durchgesetzter Freigabeprozess für Web-Warenkörbe.
- [KONTEXT] README.md Abschnitt „WebCart" – Begründung: beschreibt Zweck (Kunden der Kunden) und Preisquelle Sonderpreise.
Prüfidee: Web-Account legt Warenkorb an, Prüfer lehnt ab → Status DeclinedByChecker; nach Freigabe entsteht Bestellung.
Tracelinks: SyRS-060, SyRS-061
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – strategisch für SaaS-Ziel (Self-Service).
Status: belegt
```
```
ID: StRS-016
Titel: Auswertungen, Statistiken und Berichte
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsführung/Controlling, Vertrieb, Serviceleitung
Vorbedingung: Bewegungsdaten vorhanden.
Fakt: Statistics enthält Umsatz-/Auftrags-/Ticket-/Vertrags-/MSP-Statistiken; ReportEngine verwaltet FastReport-Berichte in Gruppen mit Standardberichten je Ausgabeart (ReportGroupBL, ReportDataDefault Type Mail/Print, z. B. Gruppe MAHNUNG).
Aussage: Das System soll betriebliche Kennzahlen (Umsätze, Aufträge, Tickets, Verträge) auswerten und Druck-/Mailberichte über konfigurierbare Berichtsvorlagen erzeugen.
Ergebnis: Auswertungen und Belegdrucke stehen rollengerecht zur Verfügung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methode GenerateReport (ReportGroupConstants.MAHNUNG, Defaults je SendType) – Begründung: durchgesetzte Berichtsauswahl je Ausgabekanal.
- [PRIMÄR] src/backend/Centron.BL/Statistics (Ordnerstruktur mit SaleStatistics, TicketStatistics, ContractStatistics, MspStatistics) – Begründung: implementierte Statistikbereiche.
Prüfidee: Mahnlauf mit SendType Mail nutzt den Mail-Standardbericht der Gruppe „Mahnung".
Tracelinks: SyRS-070, SyRS-071
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Steuerungsrelevanz; Berichtstechnologie im Ziel neu wählbar.
Status: belegt
```
```
ID: StRS-017
Titel: Interne Zusammenarbeit und Selbstorganisation
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Alle Mitarbeiter
Vorbedingung: –
Fakt: Es existieren Kalender (CalendarBL, AppointmentRequests), ToDo (ToDoBL), Chat (ChatBL mit Gruppen/Nachrichten), MyDay-Arbeitsvorrat (MyDayBL), Benachrichtigungen (UserNotificationBL, NotificationsHubHelper) und ein interner SocialMedia-Feed (SocialMediaBL mit Kommentaren/Likes/Abos).
Aussage: Das System soll Mitarbeitern Kalender, Aufgaben, Chat, persönliche Tagesübersicht und Benachrichtigungen als integrierte Werkzeuge der Zusammenarbeit bereitstellen.
Ergebnis: Termine, Aufgaben und Informationen sind ohne Systemwechsel verfügbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Chats/ChatBL.cs (CreateChat, SendChatMessage, EditChatMessage) – Begründung: implementierte Chat-Funktionen.
- [PRIMÄR] src/backend/Centron.BL/MyDay/MyDayBL.cs (SaveOrUpdateWorkItem, GetEmployeeSelection) – Begründung: implementierter Arbeitsvorrat.
Prüfidee: Chatnachricht senden/ändern/löschen; MyDay-Eintrag anlegen und in der Tagesansicht sehen.
Tracelinks: SyRS-080
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Kollaborationsfunktionen; Chat ggf. durch Standardtools ersetzbar (Bewertung im Ziel).
Status: belegt
```
```
ID: StRS-018
Titel: Integrierte E-Mail-Verarbeitung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Innendienst, Helpdesk; E-Mail-Infrastruktur
Vorbedingung: Mailkonten sind konfiguriert.
Fakt: Mail-BL verwaltet Konten/Signaturen/Vorlagen; MailScannerBL verarbeitet Postfächer über Workflows/Profile mit Protokoll (MailScannerLog); Outlook-AddIn (CentronNexus.OutlookAddIn) koppelt Outlook an c-entron; Ticket-Mailversand über HelpdeskSendMailBL.
Aussage: Das System soll E-Mails senden (mit Vorlagen/Signaturen), eingehende Postfächer regelbasiert verarbeiten (u. a. automatische Ticketerzeugung) und sich in Outlook integrieren.
Ergebnis: Kundenkommunikation ist am Vorgang dokumentiert; eingehende Mails erzeugen Vorgänge.
Belege:
- [PRIMÄR] src/backend/Centron.BL/MailScanner/MailScannerBL.cs (GetWorkflows, SaveProfile, SaveMailScannerLog) – Begründung: implementierte regelbasierte Mailverarbeitung.
- [SEKUNDÄR] docs/features/automatic-helpdesk-creation-templates.md – Begründung: dokumentiert automatische Ticketerzeugung aus Mails.
Prüfidee: Eingehende Mail auf überwachtem Postfach erzeugt gemäß Workflow ein Ticket mit Protokolleintrag.
Tracelinks: SyRS-081, SyRS-082
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – zentraler Kommunikationskanal.
Status: belegt
```
```
ID: StRS-019
Titel: Verwaltung von Kundengeräten und Managed Services
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Servicetechniker, MSP-Betrieb; RMM-Systeme, docuFORM
Vorbedingung: Kundengeräte sind erfasst oder werden automatisch erkannt.
Fakt: AccountDeviceBL verwaltet Kundengeräte mit Log; AssetManagement*-Tabellen (u. a. AssetManagementDevices, AssetManagementSnmp*) und RMM-/docuFORM-Anbindungen liefern Gerätedaten; Verträge führen Gerätelisten (MasterDataLists) mit Klickzählern (AutomaticFacturaBL.Contracts: Counter-Funktionen), MspCollectorsBL sammelt MSP-Mengen.
Aussage: Das System soll die beim Kunden betriebenen Geräte inkl. automatisch erhobener Daten (RMM, Zählerstände) verwalten und als Abrechnungsgrundlage für Serviceverträge nutzen.
Ergebnis: Gerätebestand aktuell; verbrauchsabhängige Abrechnung möglich.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Devices/AccountDeviceBL.cs (SaveAccountDevice, WriteAccountDeviceLog) – Begründung: implementierte Geräteverwaltung mit Protokoll.
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs (StoreCounterState, GetCurrentCounterState, UpdClickCounterHistory) – Begründung: durchgesetzte Zähler-Abrechnungslogik.
Prüfidee: Zählerstand importieren; Vertragsabrechnung berechnet Klicks über Freimenge korrekt.
Tracelinks: SyRS-020, SyRS-090
Konsolidierung: Kandidat: Gerätedaten liegen mehrfach vor (AccountDevices, AssetManagementDevices, Vertrags-Stammdatenlisten) – im Zielsystem zu einem Gerätekonzept zusammenführen.
Übernahmewürdigkeit: übernehmen – MSP-Geschäftsmodell.
Status: belegt
```
```
ID: StRS-020
Titel: Projekte und Produktionsaufträge
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Projektleiter, Fertigung/Technik
Vorbedingung: –
Fakt: ProjectBL liefert Projektlisten; TicketProjects bündelt Tickets mit Aufgaben/Abhängigkeiten; ProductionOrderBL verwaltet Fertigungsaufträge mit Positionen und Log; CrmProjects bilden Vertriebsprojekte ab; Nexus enthält ProductionOrderManagement.
Aussage: Das System soll projektbezogenes Arbeiten (Vertriebs-, Ticket- und Fertigungsprojekte) mit Aufgaben, Abhängigkeiten und Protokollen unterstützen.
Ergebnis: Projektfortschritt und Fertigungsstatus sind nachvollziehbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs (SaveProductionOrder, SaveProductionOrderLog) – Begründung: implementierte Fertigungsauftragsverwaltung.
- [PRIMÄR] src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs (SaveOrUpdateTicketProject, SaveOrUpdateTicketProjectDependency) – Begründung: implementierte Ticketprojekte mit Abhängigkeiten.
Prüfidee: Fertigungsauftrag mit zwei Positionen anlegen; Statuswechsel wird im Log protokolliert.
Tracelinks: SyRS-091, SyRS-092
Konsolidierung: Kandidat: Projektbegriffe (Project, CrmProject, TicketProject, ProjectNumber am Beleg) sind getrennt implementiert – im Zielsystem vereinheitlichen.
Übernahmewürdigkeit: übernehmen – verbreitetes Arbeitsmodell der Zielkunden.
Status: belegt
```
```
ID: StRS-021
Titel: Reklamations-/RMA-Abwicklung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Service, Lager; Lieferant
Vorbedingung: Gerät/Artikel mit Kaufbezug vorhanden.
Fakt: RmaBL verwaltet RMA-Vorgänge mit Artikeln, Historie und Versandarten (RmaSendKindBL); RMA kann aus einem Ticket entstehen (GetRmaByHelpdeskI3D); UI-Modul Rma existiert.
Aussage: Das System soll Rücksendungen/Reklamationen als RMA-Vorgänge mit Artikeln, Historie und Bezug zu Tickets abwickeln.
Ergebnis: RMA-Vorgänge sind durchgängig dokumentiert.
Belege:
- [PRIMÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs (SaveRma, GetRmaByHelpdeskI3D, CreateNewRmaArticle) – Begründung: implementierte RMA-Verwaltung mit Ticketbezug.
Prüfidee: RMA aus Ticket erzeugen; Artikelhistorie zeigt den Vorgang.
Tracelinks: SyRS-093
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Standardprozess im Hardwaregeschäft.
Status: belegt
```
```
ID: StRS-022
Titel: Datenschutz und Datensicherheit (DSGVO)
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Datenschutzbeauftragter, Administrator
Vorbedingung: –
Fakt: Es existieren DsgvoWebServiceBL (Administration/Documents/Dsgvo), der Ordner Administration/DataSecurity sowie ein Zugriffs-/Änderungsprotokoll für gespeicherte Kundenpasswörter (PasswordManagementAccessLogBL, PasswordManagementLogBL).
Aussage: Das System soll Datenschutzprozesse unterstützen (DSGVO-Dokumente) und Zugriffe auf besonders schützenswerte Daten protokollieren.
Ergebnis: Nachweisbare Datenschutz-Dokumentation und Zugriffsprotokolle.
Belege:
- [PRIMÄR] src/backend/Centron.BL/PasswordManagementArea/PasswordManagementAccessLogBL.cs – Begründung: implementiertes Zugriffsprotokoll auf Passwörter.
- [SEKUNDÄR] src/backend/Centron.BL/WebServices/Administration/Documents/Dsgvo/DsgvoWebServiceBL.cs (Dateiname/Klasse) – Begründung: DSGVO-Funktionsbereich existiert.
Prüfidee: Abruf eines gespeicherten Passworts erzeugt einen AccessLog-Eintrag mit Benutzer und Zeit.
Tracelinks: SyRS-100, SyRS-101
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – gesetzliche Anforderung.
Status: belegt
```
```
ID: StRS-023
Titel: Revisionsfähigkeit durch Historien und Belegversionen
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit (Nachvollziehbarkeit/Auditierbarkeit)
Akteur: Geschäftsführung, Wirtschaftsprüfer
Vorbedingung: –
Fakt: Jede Belegänderung wird als vollständige Kopie in *KopfVersions/*PosVersions-Tabellen versioniert (docs receipts-backend-architecture, AssetHeadDAO.SaveAssetVersion); ChangeTrackingEventListener schreibt feldgenaue ChangeLog-Einträge; Belege tragen Audit-Felder (CreatedBy/ChangedBy/At); Tickets führen Historie (HelpdeskHistoryBL).
Aussage: Das System soll Änderungen an Belegen und wesentlichen Objekten versioniert bzw. feldgenau protokollieren, sodass frühere Zustände nachvollziehbar sind.
Ergebnis: Zu jedem Beleg sind alle historischen Versionen einsehbar.
Belege:
- [PRIMÄR] src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs, Methode OnPreUpdate (erzeugt ChangeLog bei Feldänderung) – Begründung: durchgesetztes feldgenaues Änderungsprotokoll.
- [PRIMÄR] SSMS_DB_SCHEMA.sql, Tabellen RechKopfVersions/RechPosVersions u. a. – Begründung: Versionstabellen existieren im Schema.
- [SEKUNDÄR] docs/reference/receipts/receipts-backend-architecture.md (Version Tables 1:1) – Begründung: dokumentierter Versionierungsmechanismus.
Prüfidee: Rechnung zweimal ändern; zwei Versionssätze in RechKopfVersions, ChangeLog enthält Feldänderungen.
Tracelinks: SyRS-015, SyRS-102
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – GoBD-/Audit-Anforderung.
Status: belegt
```
```
ID: StRS-024
Titel: Mandanten- und Filialfähigkeit
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsführung, Administrator
Vorbedingung: –
Fakt: MandatorBL und BranchBL existieren; Belege tragen BranchI3D mit Herkunftslogik (ReceiptBL.GetBranchForNewReceipt nach BranchOrigin Creator/Adviser2); Nummernkreise, Läger, Rechte („nur eigene Filiale") und Erlöskonten (BranchRevenueAndExpenseAccountBL) sind filialbezogen.
Aussage: Das System soll mehrere Mandanten und Filialen abbilden; Belege, Nummernkreise, Läger und Berechtigungen sollen filialbezogen steuerbar sein.
Ergebnis: Filialen arbeiten getrennt mit eigenen Nummern/Lägern; übergreifende Auswertung bleibt möglich.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methoden GetBranchForNewReceipt / UpdateReceiptNumber (Nummernkreis je Branch) – Begründung: durchgesetzte Filialzuordnung.
- [PRIMÄR] src/backend/Centron.BL/Administration/Company/BranchBL.cs, MandatorBL.cs – Begründung: implementierte Organisationsstämme.
Prüfidee: Zwei Filialen mit eigenen Nummernkreisen; Belege erhalten filialspezifische Nummern.
Tracelinks: SyRS-013, SyRS-110
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – im SaaS-Ziel als Mandanten-/Standortmodell.
Status: belegt
```
```
ID: StRS-025
Titel: Sichere Verwaltung von Kundenzugangsdaten
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Servicetechniker, Administrator
Vorbedingung: Berechtigung auf den Passwortbereich.
Fakt: PasswordManagementBL speichert Zugangsdaten mit Entschlüsselungsfunktion (GetDecryptedPassword) und getrennten Protokollen für Zugriffe (AccessLog) und Änderungen (Log); Typen/Schlagworte strukturieren die Einträge.
Aussage: Das System soll Zugangsdaten zu Kundensystemen verschlüsselt speichern, den Zugriff berechtigungsabhängig gewähren und jeden Abruf protokollieren.
Ergebnis: Zugangsdaten sind zentral, geschützt und auditierbar verfügbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/PasswordManagementArea/PasswordManagementBL.cs, Methode GetDecryptedPassword – Begründung: implementierte ver-/entschlüsselte Ablage.
- [PRIMÄR] src/backend/Centron.BL/PasswordManagementArea/PasswordManagementAccessLogBL.cs – Begründung: durchgesetztes Zugriffsprotokoll.
Prüfidee: Passwortabruf erzeugt AccessLog; Datenbankfeld enthält keinen Klartext.
Tracelinks: SyRS-101
Konsolidierung: Kandidat: PasswordManager (BL/PasswordManager) und PasswordManagementArea adressieren denselben Gegenstand – im Ziel ein Konzept.
Übernahmewürdigkeit: übernehmen – sicherheitskritische Kernfunktion für Systemhäuser.
Status: belegt
```
```
ID: StRS-026
Titel: Telefonie-Integration am Arbeitsplatz
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Innendienst, Helpdesk; TK-Anlage (TAPI)
Vorbedingung: TAPI-Treiber verfügbar und konfiguriert.
Fakt: PhoneCallBL erzeugt/synchronisiert Anrufdatensätze und sucht Kontakte per Rufnummer (SearchContactPersonByPhoneNumberV2); assemblies/tapi und docs/reference/architecture/tapi.md existieren.
Aussage: Das System soll ein- und ausgehende Telefonate erkennen, dem Anrufer Kunden/Kontakte zuordnen und Anrufe protokollieren.
Ergebnis: Anrufbezogene Vorgangsbearbeitung ohne manuelle Suche.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Tapi/PhoneCallBL.cs (CreatePhoneCall, SearchContactPersonByPhoneNumberV2, SyncPhoneCalls) – Begründung: implementierte Telefonie-Logik.
- [KONTEXT] docs/reference/architecture/tapi.md – Begründung: Architekturdokumentation der TAPI-Anbindung.
Prüfidee: Simulierter Anruf mit bekannter Nummer öffnet den passenden Kontakt.
Tracelinks: SyRS-083
Konsolidierung: nein
Übernahmewürdigkeit: Workaround – TAPI ist Windows-/Desktop-gebunden; im Web-Ziel durch CTI-/WebRTC-Ansatz zu ersetzen, fachliche Funktion bleibt.
Status: belegt
```
```
ID: StRS-027
Titel: Elektronische Rechnungsstellung (XRechnung/ZUGFeRD)
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Buchhaltung; öffentliche/gewerbliche Rechnungsempfänger
Vorbedingung: Rechnung ist fakturiert; Empfänger verlangt E-Rechnung.
Fakt: Es existieren eine eigene ZUGFeRD-Implementierung (docs/guides/development/xrechnung.md: „instead of creating our own implementation"), Feldzuordnungsdokumente (docs/reference/zugferd-field-mapping.md, zugferd-feldzuordnung-anwender.md) und die österreichische ebInterface-API (src/apis/Centron.Api.EbInterface).
Aussage: Das System soll Ausgangsrechnungen als strukturierte E-Rechnungen (ZUGFeRD/XRechnung, ebInterface für AT) erzeugen können.
Ergebnis: Normkonforme E-Rechnungsdatei zur Rechnung.
Belege:
- [PRIMÄR] src/apis/Centron.Api.EbInterface (Projekt) – Begründung: implementierte E-Rechnungs-Schnittstelle ebInterface.
- [SEKUNDÄR] docs/reference/zugferd-field-mapping.md – Begründung: dokumentierte Feldzuordnung der eigenen ZUGFeRD-Erzeugung.
- [KONTEXT] docs/guides/development/xrechnung.md – Begründung: bestätigt eigene ZUGFeRD/XRechnung-Implementierung.
Prüfidee: Erzeugte XRechnung mit KOSIT-Validator prüfen.
Tracelinks: SyRS-025
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – gesetzliche Pflicht (B2G, ab 2025ff B2B-Empfangspflicht in DE).
Status: belegt
```
```
ID: StRS-028
Titel: KI-gestützte Assistenzfunktionen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Helpdesk-Mitarbeiter; KI-Dienste (OpenAI-kompatibel)
Vorbedingung: KI-Anbindung konfiguriert und lizenziert.
Fakt: ArtificialIntelligence enthält OpenAiApiClient, TicketCategoryApiClient, TextRatingApiClient, ChatModelApiClient; Nexus-ServiceBoard enthält TicketAiSummary; TelemetryBL erfasst KI-Toolnutzung.
Aussage: Das System soll KI-Dienste für Ticket-Kategorisierung, Textbewertung und Ticket-Zusammenfassungen anbinden und deren Nutzung erfassen.
Ergebnis: KI-Vorschläge in der Ticketbearbeitung; Nutzung ist ausgewertet.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ArtificialIntelligence/TicketCategoryApiClient.cs, OpenAiApiClient.cs – Begründung: implementierte KI-Clients.
- [PRIMÄR] src/nexus/CentronNexus/ServiceBoard/TicketAiSummary (Ordner) – Begründung: KI-Zusammenfassung im Webclient.
Prüfidee: Ticket-Zusammenfassung im ServiceBoard abrufen; Telemetrie-Eintrag entsteht.
Tracelinks: SyRS-120
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Differenzierungsmerkmal; Anbieterwahl im Ziel offen.
Status: belegt
```
@@ -0,0 +1,80 @@
# Messprotokoll – Versuch 01 (V1 Baseline) – Prompt-Version 02
> ## ⚠ FEHLMESSUNG – nicht für Auswertungen verwenden
>
> Der Lauf brach mit `is_error: true` und HTTP 429 ab: „You've hit your session limit ·
> resets 10:50pm (Europe/Berlin)". Erzeugt wurden **3 von sieben** geforderten Ergebnisdateien; der Lauf brach mitten in der Bearbeitung ab. Verbraucht wurden
> bis zum Abbruch **7.997.215 Tokens**.
## Lauf
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
- **Prompt-Version:** 02
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
- **Startzeit:** 2026-08-26T20:00:08.8552900+02:00
- **Endzeit:** 2026-08-26T20:28:31.6394457+02:00
- **Dauer gesamt:** 00:07:4x — bis zum Kontingentabbruch
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
- **Codebasis-Commit:** `f349d189c735a87f5829bc93f67991320061a2c0` (dirty: nein)
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; enthält `SSMS_DB_SCHEMA.sql`
## Werkzeugkonfiguration
- **Skill-Version:** 7.0.0
- **Claude-Code-Version:** 2.1.246
- **Modell (angefordert):** `claude-fable-5`
- **Modelle (tatsächlich eingesetzt):** `claude-fable-5` 7.990.250 (99.91 %), `claude-haiku-4-5-20251001` 6.965 (0.09 %)
- **Kontrolle Modell:** bestanden
- **Effort:** `high`
- **Agentenmodus:** `solo` (V1)
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
- **Hintergrund-Wartezeit:** `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`
- **Parallele Läufe:** **ja** – alle vier Läufe der Welle liefen gleichzeitig
- **Subagenten:** keine (`spawned` = 0)
## Verbrauch
| Messgröße | `claude-fable-5` | `claude-haiku-4-5-20251001` | Summe |
|---|---:|---:|---:|
| Input-Tokens | 128 | 6.945 | 7.073 |
| Output-Tokens | 127.802 | 20 | 127.822 |
| Cache-Write-Tokens | 279.983 | 0 | 279.983 |
| Cache-Read-Tokens | 7.582.337 | 0 | 7.582.337 |
| **Tokens gesamt** | **7.990.250** | **6.965** | **7.997.215** |
**Tokens gesamt: 7.997.215** — real angefallen und deshalb ausgewiesen, obwohl der Lauf ungültig ist.
## Gefundene Anforderungen
Der Lauf brach vor Abschluss ab. Im vorhandenen **Teilbestand** stehen **109 Anforderungen**. Die Zahl ist **nicht** mit vollständigen Läufen vergleichbar – es fehlen `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`. Die maschinelle Auswertung liegt zur Vollständigkeit unter `_meta/anforderungen.md`, geht aber nicht in Vergleiche ein.
## Ergebnis
- **Gültigkeit:** **Fehlmessung** – API-Abbruch (HTTP 429, Session-Kontingent); nur 3 von sieben Artefakten erzeugt
- **Status:** `is_error` = true, `terminal_reason` = `api_error`, `api_error_status` = 429
- **Session-ID:** `1d368e93-cb25-434c-9365-b76eace2ee17`
- **Turns:** 94
- **Permission-Denials:** 0
- **Erzeugte Dateien:** 3 von sieben geforderten Artefakten:
| Datei | Größe |
|---|---:|
| `Analysebericht.md` | 24.343 B |
| `StRS.md` | 42.134 B |
| `SyRS.md` | 105.262 B |
Es fehlen: `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`
- **Root unverändert:** ja
- **Abschlusstext des Agenten:** „You've hit your session limit · resets 10:50pm (Europe/Berlin)"
## Anmerkungen/Auffälligkeiten
**1. Kontingentabbruch, nicht Laufversagen.** Vier Läufe wurden am 26.08. um 19:59 gleichzeitig
gestartet; alle vier liefen in dieselbe Grenze. Zusammen hatten sie zu diesem Zeitpunkt
297,4 Mio. Tokens verbraucht, davon allein 204,4 Mio. im Lauf `45dd`. Die Parallelität von vier
Läufen – darunter einer mit extremer Delegation – hat das Kontingent gerissen.
**2. Konsequenz für den Versuchsaufbau:** Die verbleibenden Zellen werden **seriell** gefahren.
Der erste serielle Lauf danach (`opus-5/solo/high`, `2269`) lief mit 38,1 Mio. Tokens sauber durch.
**3. Zelle inzwischen gültig belegt.** Der Wiederholungslauf `02_Lauf_2026-08-27_002430_v7.0.0-35a4`
war erfolgreich: 241 Anforderungen, 98,3 % mit Primärbeleg, 30,6 Mio. Tokens – allerdings mit
7:03 h Wanduhrzeit, weil er mehrfach stundenweise auf Kontingent-Reset-Fenster wartete.
@@ -0,0 +1 @@
{"is_error":true,"duration_api_ms":1549743,"num_turns":94,"stop_reason":"stop_sequence","session_id":"1d368e93-cb25-434c-9365-b76eace2ee17","total_cost_usd":19.580422,"usage":{"input_tokens":128,"cache_creation_input_tokens":279983,"cache_read_input_tokens":7582337,"output_tokens":127802,"output_tokens_details":{"thinking_tokens":21913},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":279983,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":374,"cache_read_input_tokens":247654,"cache_creation_input_tokens":32329,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":32329},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6945,"outputTokens":20,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007045,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-fable-5":{"inputTokens":128,"outputTokens":127802,"cacheReadInputTokens":7582337,"cacheCreationInputTokens":279983,"webSearchRequests":0,"costUSD":19.573377,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"api_error","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":429,"result":"You've hit your session limit · resets 10:50pm (Europe/Berlin)","type":"result","duration_ms":1701146,"uuid":"910fddce-feda-4375-862c-350dbb92f47b","queued_turn_count":0}
@@ -0,0 +1,65 @@
## 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 | 28 | 25,7 % |
| SyRS | 81 | 74,3 % |
| SwRS | 0 | 0,0 % |
| **Gesamt** | **109** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 60 | 55,0 % |
| Schnittstelle | 15 | 13,8 % |
| Sicherheit | 15 | 13,8 % |
| nicht-funktional | 10 | 9,2 % |
| Daten | 9 | 8,3 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 180 |
| davon `PRIMÄR` | 145 (80,6 %) |
| davon `SEKUNDÄR` | 28 (15,6 %) |
| davon `KONTEXT` | 7 (3,9 %) |
| Belege je Anforderung (Median) | 2 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 108 (99,1 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 102 | 93,6 % |
| workaround | 4 | 3,7 % |
| sonderfall | 1 | 0,9 % |
| veraltet | 2 | 1,8 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 101 | 92,7 % |
| als `HYPOTHESE` gekennzeichnet | 8 | 7,3 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 11 | 10,1 % |
| mit ISO-25010-Qualitätsmerkmal | 10 | 9,2 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 1 von 28 ungedeckt: SyRS-008 |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 109 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 109 von 109 mit Tracelinks (100,0 %) |
@@ -0,0 +1,177 @@
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
## Metadaten
- **Versuch:** V1 Baseline (Prompt-only)
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-26
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
| Änderung | Auslösender Befund |
|---|---|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
> 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.
---
## 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.
**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. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
- **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)
```
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)
```
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
---
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
Kommandozeilenbefehlen im Arbeitsverzeichnis.
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
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 3\claude-fable-5\solo\high\02_Lauf_2026-08-26_195958_v7.0.0-77a1\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
2026-08-26T20:28:31.6394457+02:00
@@ -0,0 +1,492 @@
# Analysebericht – Reverse Requirements Engineering c-entron ERP-Suite
**Lauf:** V1 Baseline (Prompt-only), Iteration 02, 2026-08-27
**Untersuchungsgegenstand:** Gesamte Codebasis unter `C:\DEV\MasterArbeit\QuellCode\CentronERP` (statische Analyse, keine Ausführung)
---
## Schritt 0 – Modulinventar
Das Inventar wurde vor der ersten Anforderung erstellt. Es basiert auf der Verzeichnisstruktur der
Solution (`Centron.sln`), insbesondere der fachlichen Modulordner in `src/backend/Centron.BL`
(Geschäftslogikschicht), sowie den weiteren Schichten (DAO, Entities, Gateway, WPF-Client,
Blazor-Web „Nexus", Webservice, API-Integrationsprojekte) und Begleitartefakten (DB-Schema,
Deployment, Doku). Pfade sind relativ zum Arbeitsverzeichnis.
Legende Spalte „Modul": M-Nummer = Bezugsgröße für Abdeckungstabelle und Mindestabdeckung.
### A. Geschäftslogik (src/backend/Centron.BL)
| Nr. | Modul / Komponente | Pfad | Fachliche Aufgabe (1 Satz) |
|---|---|---|---|
| M-001 | Accounting (Bankkonten) | src/backend/Centron.BL/Accounting | Verwaltung der Bankkonten des Unternehmens (BankAccountBL). |
| M-002 | Accounts (Konten-/Adressstamm) | src/backend/Centron.BL/Accounts | Verwaltung von Konten (Kunden/Adressen), Kontakten, Kontenverträgen, Kampagnen, Kontenmigration und Aktivitäten. |
| M-003 | Administration: AccessTokens | src/backend/Centron.BL/Administration/AccessTokens | Verwaltung von API-/Zugriffstokens für externe Zugriffe. |
| M-004 | Administration: Applications | src/backend/Centron.BL/Administration/Applications | Verwaltung registrierter (Client-)Anwendungen. |
| M-005 | Administration: ArtificialIntelligence | src/backend/Centron.BL/Administration/ArtificialIntelligence | Administrative Konfiguration der KI-Funktionen (Modelle, API-Anbindung). |
| M-006 | Administration: BackgroundServices | src/backend/Centron.BL/Administration/BackgroundServices | Konfiguration und Überwachung von Hintergrunddiensten (Jobs). |
| M-007 | Administration: BookKeepingAccountSystems | src/backend/Centron.BL/Administration/BookKeepingAccountSystems | Verwaltung der Buchhaltungs-Kontenrahmen (z. B. SKR) für die FiBu-Übergabe. |
| M-008 | Administration: CentronConfigDb | src/backend/Centron.BL/Administration/CentronConfigDb | Zugriff auf die zentrale Konfigurationsdatenbank (mandantenübergreifende Konfiguration). |
| M-009 | Administration: Company/CompanyInformations | src/backend/Centron.BL/Administration/Company, .../CompanyInformations | Verwaltung der eigenen Firmenstammdaten (Firmen, Filialen, Firmeninformationen). |
| M-010 | Administration: Connections | src/backend/Centron.BL/Administration/Connections | Verwaltung technischer Verbindungen (DB-/Dienstverbindungen). |
| M-011 | Administration: Customization | src/backend/Centron.BL/Administration/Customization | Kundenspezifische Anpassungen der Anwendung (Custom-Verhalten). |
| M-012 | Administration: DataSecurity | src/backend/Centron.BL/Administration/DataSecurity | Datensicherheits-/Datenschutzfunktionen (DataSecurityBL). |
| M-013 | Administration: Documents/FileManagement | src/backend/Centron.BL/Administration/Documents, .../FileManagement | Dokumentenablage und Dateiverwaltung (Speicherorte, Dateioperationen). |
| M-014 | Administration: Employees | src/backend/Centron.BL/Administration/Employees | Administrative Mitarbeiterverwaltung (Anlage, Einstellungen). |
| M-015 | Administration: Environments | src/backend/Centron.BL/Administration/Environments | Verwaltung von Umgebungen (z. B. Test-/Produktivumgebung). |
| M-016 | Administration: Licensing | src/backend/Centron.BL/Administration/Licensing | Lizenzverwaltung und Lizenzprüfung der ERP-Installation (LicenseManager). |
| M-017 | Administration: Logins/Auth | src/backend/Centron.BL/Administration/Logins | Benutzer-Authentifizierung: Logins, Auth-Tickets, Zwei-Faktor, Web-Accounts, EntraID-Anbindung. |
| M-018 | Administration: Mandatory | src/backend/Centron.BL/Administration/Mandatory | Verwaltung der Mandanten (Mandatoren) der Installation. |
| M-019 | Administration: Masterdata | src/backend/Centron.BL/Administration/Masterdata | Zentrale Stammdaten der Administration (Basistabellen). |
| M-020 | Administration: NetworkDiagnostics | src/backend/Centron.BL/Administration/NetworkDiagnostics | Netzwerk-Diagnosefunktionen für den Support. |
| M-021 | Administration: PerformanceTests/Profiling | src/backend/Centron.BL/Administration/PerformanceTests, .../Profiling | Performancemessung und Profiling der Anwendung. |
| M-022 | Administration: PhoneSettings | src/backend/Centron.BL/Administration/PhoneSettings | Telefonie-Einstellungen (TAPI-Konfiguration). |
| M-023 | Administration: Portal | src/backend/Centron.BL/Administration/Portal | Anbindung/Verwaltung eines (Kunden-)Portals. |
| M-024 | Administration: Rights | src/backend/Centron.BL/Administration/Rights | Benutzerrechte- und Benutzergruppenverwaltung (AppRights, Rechtebaum). |
| M-025 | Administration: Scripts/SQLManagement | src/backend/Centron.BL/Administration/Scripts, .../SQLManagement | Verwaltung und Ausführung administrativer SQL-Skripte. |
| M-026 | Administration: Settings | src/backend/Centron.BL/Administration/Settings | Systemweite und benutzerbezogene Einstellungen. |
| M-027 | Administration: Themes | src/backend/Centron.BL/Administration/Themes | Verwaltung der UI-Themes. |
| M-028 | Administration: WebServiceConfiguration | src/backend/Centron.BL/Administration/WebServiceConfiguration | Konfiguration des c-entron Webservice. |
| M-029 | AppointmentRequests | src/backend/Centron.BL/AppointmentRequests | Terminanfragen (Vereinbarung von Terminen mit Externen). |
| M-030 | ArtificialIntelligence | src/backend/Centron.BL/ArtificialIntelligence | KI-Funktionen: Chat-Anbindung an LLM-Anbieter, Modellkatalog, Tool-Aufrufe. |
| M-031 | BusinessPartner | src/backend/Centron.BL/BusinessPartner | Lieferanten-Suche und Lieferanten-Assets (Geschäftspartnersicht). |
| M-032 | Buying | src/backend/Centron.BL/Buying | Einkaufssicht auf Distributoren (externe Bezugsquellen). |
| M-033 | Calendar | src/backend/Centron.BL/Calendar | Kalenderfunktionen (Termine der Mitarbeiter). |
| M-034 | CentronIcons | src/backend/Centron.BL/CentronIcons | Verwaltung der in der Anwendung verwendeten Icons. |
| M-035 | CentronNexus (BL) | src/backend/Centron.BL/CentronNexus | Geschäftslogik-Anteil für den Webclient „c-entron Nexus". |
| M-036 | ChangeTracking | src/backend/Centron.BL/ChangeTracking | Import-Historie und Änderungsverfolgung. |
| M-037 | Chats | src/backend/Centron.BL/Chats | Interne Chat-Funktion. |
| M-038 | CheckListArea | src/backend/Centron.BL/CheckListArea | Checklisten inkl. Änderungsprotokoll. |
| M-039 | Core (BL-Kern) | src/backend/Centron.BL/Core | Kernfunktionen der BL: Kryptographie-Hilfsfunktionen, Platzhalter-Ersetzung. |
| M-040 | CountryArea | src/backend/Centron.BL/CountryArea | Länder- und Bundesland-Stammdaten. |
| M-041 | CPra | src/backend/Centron.BL/CPra | Konnektor „CPra" (Konfiguration und Anbindung eines Externsystems). |
| M-042 | CustomerArea | src/backend/Centron.BL/CustomerArea | Kundenbezogene Nebenstammdaten: Branchen, Interessen, Produkte, RMA-Abwicklung. |
| M-043 | Customizations (CustomTables) | src/backend/Centron.BL/Customizations | Kundenindividuelle Zusatztabellen (Custom Tables). |
| M-044 | DataExchange | src/backend/Centron.BL/DataExchange | Datenaustausch: FiBu-Export/-Import, DocBee-/DocuForm-Konnektoren, E-Rechnungs-Upload, WebHooks. |
| M-045 | Devices | src/backend/Centron.BL/Devices | Geräteverwaltung je Konto (AccountDevice). |
| M-046 | DocuBoard | src/backend/Centron.BL/DocuBoard | Asset-Management-Anbindung (AD-Systembenutzer, Artikelzuordnung, Partner). |
| M-047 | DocumentationArea | src/backend/Centron.BL/DocumentationArea | Dokumentationen zu Objekten (Systemdokumentation). |
| M-048 | EDI | src/backend/Centron.BL/EDI | Elektronischer Datenaustausch mit Distributoren (Alltron, ALSO, Concerto, EGIS, Komsa u. a.): Bestellungen, Auftragsbestätigungen. |
| M-049 | EmployeeArea | src/backend/Centron.BL/EmployeeArea | Mitarbeiterstamm: App-Benutzer, Abteilungen, Urlaub, RFID-Token, Team-Management. |
| M-050 | ExpectedEvents | src/backend/Centron.BL/ExpectedEvents | Erwartete Ereignisse (Überwachung ausbleibender Ereignisse). |
| M-051 | ExternalHelpdesk | src/backend/Centron.BL/ExternalHelpdesk | Konfiguration externer Helpdesk-Anbindungen. |
| M-052 | ExternalToolsBL | src/backend/Centron.BL/ExternalToolsBL | Einbindung externer Tools in die Anwendung. |
| M-053 | Finances | src/backend/Centron.BL/Finances | Finanzen: Zahlungseingänge, Onlinebanking (FinAPI), Zahlungen, Produkt-Lebenszyklus. |
| M-054 | Gateway (BL) | src/backend/Centron.BL/Gateway | Kundenspezifische Gateway-Logik (CustomGateway). |
| M-055 | GUI (BL-Anteil) | src/backend/Centron.BL/GUI | UI-nahe BL: Bestellimport (EDI), UI-Profile, Benutzer-Grid-Layouts. |
| M-056 | IndexSearch | src/backend/Centron.BL/IndexSearch | Volltextsuche über Konten und Tickets (Lucene-Index, GermanAnalyzer). |
| M-057 | Integrations | src/backend/Centron.BL/Integrations | Integrationen (EsCustomerGroup, EsRole – externes Shopsystem). |
| M-058 | ItPlanner | src/backend/Centron.BL/ItPlanner | IT-Planner (Checklisten-basierte Planung virtueller Objekte). |
| M-059 | Logistics | src/backend/Centron.BL/Logistics | Logistikeinstellungen und Bestandsführung (StockBL). |
| M-060 | Mail | src/backend/Centron.BL/Mail | E-Mail-Verarbeitung: Exchange/EWS-Anbindung, Mail-Erzeugung, Signaturen, Domain-Blacklist. |
| M-061 | MailScanner | src/backend/Centron.BL/MailScanner | Automatisches Scannen von Mailpostfächern (z. B. zur Ticketerzeugung). |
| M-062 | Mailings | src/backend/Centron.BL/Mailings | Serien-Mailings auf Basis von Vorlagen. |
| M-063 | MassUpdate | src/backend/Centron.BL/MassUpdate | Massenänderungen an Datenobjekten. |
| M-064 | Mobile | src/backend/Centron.BL/Mobile | Unterstützung mobiler Clients. |
| M-065 | Modules | src/backend/Centron.BL/Modules | Verwaltung der freigeschalteten Programm-Module (Modul-/Kategorieverwaltung). |
| M-066 | MyCentron | src/backend/Centron.BL/MyCentron | Persönlicher Bereich: Dashboards, Quick Notes, zuletzt verwendete Objekte, Schedulings. |
| M-067 | MyDay | src/backend/Centron.BL/MyDay | „Mein Tag"-Übersicht (Tagesnotifications, Reports, Supremo-Fernwartung). |
| M-068 | NexusNotifications | src/backend/Centron.BL/NexusNotifications | Benachrichtigungen im Webclient (SignalR-Hub). |
| M-069 | NexusTicketViews | src/backend/Centron.BL/NexusTicketViews | Konfigurierbare Ticket-Ansichten im Webclient. |
| M-070 | Notifications | src/backend/Centron.BL/Notifications | Benutzerbenachrichtigungen im Client. |
| M-071 | ObjectExternalReferences | src/backend/Centron.BL/ObjectExternalReferences | Externe Referenzen auf c-entron-Objekte (Fremdschlüssel zu Drittsystemen). |
| M-072 | Outlook | src/backend/Centron.BL/Outlook | Outlook-Integration (Asset-Suche aus Outlook). |
| M-073 | PasswordManagementArea | src/backend/Centron.BL/PasswordManagementArea | Passwortverwaltung für Kunden-Zugangsdaten inkl. Zugriffs- und Änderungsprotokoll. |
| M-074 | PasswordManager | src/backend/Centron.BL/PasswordManager | Anbindung externer Passwortmanager. |
| M-075 | Processes | src/backend/Centron.BL/Processes | Prozessverwaltung (Geschäftsprozess-Objekte). |
| M-076 | ProductMatrix | src/backend/Centron.BL/ProductMatrix | Produktmatrix (Zuordnung Produkte zu Konten). |
| M-077 | Production | src/backend/Centron.BL/Production | Produktion/Fertigungsaufträge (ProductionOrder). |
| M-078 | Projects | src/backend/Centron.BL/Projects | Projektverwaltung. |
| M-079 | Purchasing | src/backend/Centron.BL/Purchasing | Einkauf: Bestellvorschläge, Lieferanten, Einkaufseinstellungen, filialbezogene Lieferantenbestellungen. |
| M-080 | ReportEngine | src/backend/Centron.BL/ReportEngine | Reporterzeugung (FastReport), PDF-Export inkl. ZUGFeRD-PDF-Generierung. |
| M-081 | Reporting | src/backend/Centron.BL/Reporting | Verwaltung der Reports (ReportsBL). |
| M-082 | RiverDivo | src/backend/Centron.BL/RiverDivo | Anbindung „Riverbird/RiverDivo" (Vertragsartikel-Referenzen, River-Client). |
| M-083 | Sales: Receipts (Belegwesen) | src/backend/Centron.BL/Sales/Receipts | Belegwesen: Angebote, Aufträge, Rechnungen, Lieferscheine, Gutschriften, Anzahlungen, Abhollisten sowie Lieferantenbelege (Bestellungen, Lieferanten-Rechnungen/-Gutschriften). |
| M-084 | Sales: CustomerAssets (Verträge) | src/backend/Centron.BL/Sales/CustomerAssets | Kundenverträge und Vertragsabrechnung: Verträge, automatische Fakturierung, Timer-Billing, vertragsbezogene Belege. |
| M-085 | Sales: Customers (CRM) | src/backend/Centron.BL/Sales/Customers | Kundenverwaltung/CRM: Adressen, Kontakte, CRM-Projekte, Kundendetails, Textbausteine. |
| M-086 | Sales: Support (Helpdesk) | src/backend/Centron.BL/Sales/Support | Helpdesk/Ticketsystem inkl. Eskalationslogik und Ticketprozessen. |
| M-087 | Sales: CashBooks | src/backend/Centron.BL/Sales/CashBooks | Kassenbuchführung. |
| M-088 | Sales: Marketing | src/backend/Centron.BL/Sales/Marketing | Marketingfunktionen im Vertrieb. |
| M-089 | Sales: Calendar | src/backend/Centron.BL/Sales/Calendar | Vertriebsbezogene Kalenderfunktionen. |
| M-090 | Sales: DocumentationWizardArea | src/backend/Centron.BL/Sales/DocumentationWizardArea | Assistent zur Dokumentationserstellung im Vertriebskontext. |
| M-091 | Sales: HourlySurchargeRatesBL | src/backend/Centron.BL/Sales/HourlySurchargeRatesBL | Stundenzuschlagssätze (z. B. für Servicezeiten). |
| M-092 | Security (PdfSigning) | src/backend/Centron.BL/Security | Digitale Signatur von PDF-Dokumenten. |
| M-093 | SelfCare | src/backend/Centron.BL/SelfCare | SelfCare-Portalfunktionen (Web-Anfrageseiten für Endkunden). |
| M-094 | Services | src/backend/Centron.BL/Services | Dienste: Workflows (Prozess-Engine), CTime-Zeiterfassungs-Konnektor, Datenqualität, Tabellen-Cache. |
| M-095 | SocialMedia | src/backend/Centron.BL/SocialMedia | Social-Media-Profile von Personen/Konten. |
| M-096 | Start | src/backend/Centron.BL/Start | Anwendungsstart-Logik (StartBL). |
| M-097 | Statistics | src/backend/Centron.BL/Statistics | Statistiken: Umsatz, Mitarbeiterauslastung, Vertragsauswertung, MSP-Auswertungen. |
| M-098 | Storage | src/backend/Centron.BL/Storage | Inventur (InventoryArticlePool) und Lagerort-Logik. |
| M-099 | SystemArea | src/backend/Centron.BL/SystemArea | Systemtabellen (I3D-Systemtabelle). |
| M-100 | Tags | src/backend/Centron.BL/Tags | Verschlagwortung von Objekten (Tags). |
| M-101 | Tapi | src/backend/Centron.BL/Tapi | Telefonie-Integration (Anrufe, PhoneCallBL). |
| M-102 | TaskManager | src/backend/Centron.BL/TaskManager | Aufgabenverwaltung mit Aktions-Handlern (Helpdesk-/Report-Aktionen). |
| M-103 | Telemetry | src/backend/Centron.BL/Telemetry | Telemetrie-Erfassung der Anwendungsnutzung. |
| M-104 | TextModuleArea | src/backend/Centron.BL/TextModuleArea | Textbausteine und Anrede-/Grußformel-Ersetzung. |
| M-105 | TicketProjects | src/backend/Centron.BL/TicketProjects | Ticket-Projekte (Bündelung von Tickets). |
| M-106 | Time | src/backend/Centron.BL/Time | Zeitsteuerungs-Einstellungen (TimingSettings). |
| M-107 | ToDoArea | src/backend/Centron.BL/ToDoArea | ToDo-Verwaltung über Objektarten hinweg. |
| M-108 | Tools | src/backend/Centron.BL/Tools | Werkzeugverwaltung (ToolBL). |
| M-109 | TradePool | src/backend/Centron.BL/TradePool | „TradePool"-Handelsbörse (XML-basierter Austausch von Handelsdaten). |
| M-110 | Transactions | src/backend/Centron.BL/Transactions | Transaktionsobjekte (TransactionBL). |
| M-111 | TwoFactorAuthenticator | src/backend/Centron.BL/TwoFactorAuthenticator | Zwei-Faktor-Authentifizierung (TOTP). |
| M-112 | Urls | src/backend/Centron.BL/Urls | Verwaltung einfacher URL-Objekte (Weblinks je Objekt). |
| M-113 | VideoPortal | src/backend/Centron.BL/VideoPortal | Zuordnung von Schulungsvideos (Videoportal). |
| M-114 | VoucherManagement | src/backend/Centron.BL/VoucherManagement | Gutscheinverwaltung: Barcodes mit Status frei/ausgegeben/eingelöst. *(Beschreibung nach Detailanalyse präzisiert)* |
| M-115 | Warehousing | src/backend/Centron.BL/Warehousing | Artikelstamm und Lager: Artikel, EAN-Codes, Preise/Aktionspreise, Artikelhistorie, Umweltschutz-Angaben, Artikelimport. |
| M-116 | WebLinks | src/backend/Centron.BL/WebLinks | Aktions-Weblinks (z. B. Erinnerungen, Kontoaktivitäten per Link). |
| M-117 | WebServices (BL) | src/backend/Centron.BL/WebServices | Geschäftslogik der Webservice-Endpunkte (Datenbereitstellung für Web/Mobile/Nexus). |
| M-118 | WebSuite | src/backend/Centron.BL/WebSuite | Konfiguration der Web-Suite (Webmenü, Web-Einstellungen, Web-HD-Fragen). |
| M-119 | WebVersion | src/backend/Centron.BL/WebVersion | Versionsverwaltung der Webanwendung. |
| M-120 | Helpers (BL) | src/backend/Centron.BL/Helpers | Technische Hilfsklassen (Graph-Client, PDF-Interaktion, String-/Bild-Helfer). |
| M-121 | Exceptions (BL) | src/backend/Centron.BL/Exceptions | Fachliche Ausnahmen (z. B. TicketExpiredException). |
### B. Weitere Schichten, Anwendungen und Artefakte
| Nr. | Modul / Komponente | Pfad | Fachliche Aufgabe (1 Satz) |
|---|---|---|---|
| M-122 | Centron.DAO (Persistenz) | src/backend/Centron.DAO | Datenzugriffsschicht auf NHibernate-Basis: Mappings, Sessions, Change-Tracking, Repositories, benannte Abfragen. |
| M-123 | Centron.Entities | src/backend/Centron.Entities | Entitätsmodell (persistierte Geschäftsobjekte). |
| M-124 | Centron.Common | src/backend/Centron.Common | Querschnittsbibliothek: Logging, Einstellungen, Berechnungen, Konstanten, Benutzerkontext. |
| M-125 | Centron.Interfaces | src/backend/Centron.Interfaces | Schnittstellen- und Konstantendefinitionen (u. a. Rechte-Konstanten UserRightsConst). |
| M-126 | Centron.Gateway | src/backend/Centron.Gateway | Import-/Export-Gateway: EDI-Formate (Alltron, ALSO, EGIS, Herweck, Komsa), OpenTrans, ZUGFeRD 2.1, Onlinebanking, MSP-Collector, Portal. |
| M-127 | Centron.WPF.UI (+ Extension) | src/centron/Centron.WPF.UI, .../Centron.WPF.UI.Extension | Windows-Desktop-Client (WPF/XAML): Masken, Module, Wizards, Lokalisierung. |
| M-128 | Centron.Controls (+ Preview) | src/shared/Centron.Controls, .../Centron.Controls.Preview | Wiederverwendbare UI-Controls (DevExpress-basiert) inkl. Dokumentvorschau. |
| M-129 | Centron.Core (shared) | src/shared/Centron.Core | Gemeinsame Kernbibliothek von Client und Server. |
| M-130 | CentronNexus (Blazor-Web) | src/nexus/CentronNexus | Webclient „c-entron Nexus" (Blazor): WebCart/Shop, WebOffer, ServiceBoard, Dokument-Signierung, Produktionsauftrags-Management. |
| M-131 | CentronNexus.Host | src/nexus/CentronNexus.Host | Hosting-Anwendung des Nexus-Webclients. |
| M-132 | CentronNexus.OutlookAddIn | src/nexus/CentronNexus.OutlookAddIn | Outlook-Add-In des Nexus-Webclients. |
| M-133 | Centron.Controllers (REST-API) | src/webservice/Centron.Controllers | REST-Controller des c-entron Webservice (versionierte API, Autorisierung). |
| M-134 | Centron.WebServices.Core | src/webservice/Centron.WebServices.Core | Kern des Webservice (Infrastruktur der Dienstschicht). |
| M-135 | Centron.Host (+ Console/WindowsService) | src/webservice/Centron.Host, .../Centron.Host.Console, .../Centron.Host.WindowsService | Hosting des Webservice als Konsole oder Windows-Dienst. |
| M-136 | ConnectionManager | src/webservice/c-entron.misc.ConnectionManager | Verwaltung der Verbindungskonfiguration (Werkzeug). |
| M-137 | Centron.Api.EbInterface | src/apis/Centron.Api.EbInterface | Erzeugung österreichischer E-Rechnungen (ebInterface). |
| M-138 | Centron.Api.Gls | src/apis/Centron.Api.Gls | Versandanbindung GLS (Paketlabel). |
| M-139 | Centron.Api.Shipcloud | src/apis/Centron.Api.Shipcloud | Versandanbindung Shipcloud (Multi-Carrier-Versand). |
| M-140 | Centron.APIs.CopDataAccess | src/apis/Centron.APIs.CopDataAccess | Anbindung „COP" (SOAP-Datenzugriff auf Distributor). |
| M-141 | Centron.APIs.EgisDataAccess | src/apis/Centron.APIs.EgisDataAccess | Anbindung EGIS (Distributor-Datenzugriff). |
| M-142 | Centron.APIs.FinAPI | src/apis/Centron.APIs.FinAPI | Anbindung finAPI (Onlinebanking-REST-Dienst). |
| M-143 | Centron.APIs.IcecatDataAccess | src/apis/Centron.APIs.IcecatDataAccess | Anbindung Icecat (Produktdatenkatalog). |
| M-144 | Centron.APIs.ITscopeDataAccess | src/apis/Centron.APIs.ITscopeDataAccess | Anbindung ITscope (Handelsplattform). |
| M-145 | Centron.Api.docuFORM | Centron.Api.docuFORM | Anbindung docuFORM (Druckerdaten/Managed Print). |
| M-146 | Datenbankschema | SSMS_DB_SCHEMA.sql | SQL-Schema-Dump der c-entron-Datenbank (1558 CREATE TABLE, Constraints, Indizes). |
| M-147 | Deployment/Installer | deployment | Installer (WixSharp) und Deployment-Konfiguration für c-entron und Riverbird. |
| M-148 | Docker/Betrieb | docker | Container-Definitionen für API, Webservice, Demo, Mailcatcher, Regressionstest-DB. |
| M-149 | Scripts | scripts | Hilfs- und Wartungsskripte. |
| M-150 | Dokumentation | docs | Entwickler-/Betriebsdokumentation (Features, Architektur, Security, EDI, Belege). |
| M-151 | Tests | tests | Test-Suiten (Unit, Integration, EndToEnd, Playwright). |
**Hinweis:** Das Inventar wird bei Bedarf ergänzt, aber nicht gekürzt.
---
## Abdeckungstabelle (je Modul des Inventars)
Einstufung: `tief` = mehrere Anforderungen inkl. gelesener Kernlogik der risikorelevanten Pfade; `mittel` = 2-3 Anforderungen auf Basis gelesener Kernmethoden; `flach` = 1-2 Anforderungen auf Basis von Methodensignaturen/ausgewählten Codeausschnitten; `nicht analysiert` = keine Anforderung (mit Begründung).
| Modul | Bezeichnung | Einstufung | Anzahl Anforderungen | Anforderungen |
|---|---|---|---|---|
| M-001 | Accounting (Bankkonten) | mittel | 2 | SwRS-019, SwRS-155 |
| M-002 | Accounts (Konten-/Adressstamm) | mittel | 3 | SwRS-020, SyRS-020, StRS-001 |
| M-003 | Administration: AccessTokens | mittel | 3 | SyRS-017, SwRS-021, StRS-013 |
| M-004 | Administration: Applications | flach | 1 | SwRS-022 |
| M-005 | Administration: ArtificialIntelligence | mittel | 3 | SyRS-019, SwRS-023, StRS-029 |
| M-006 | Administration: BackgroundServices | mittel | 3 | SyRS-018, SwRS-024, StRS-031 |
| M-007 | Administration: BookKeepingAccountSystems | flach | 1 | SwRS-025 |
| M-008 | Administration: CentronConfigDb | flach | 1 | SwRS-026 |
| M-009 | Administration: Company/CompanyInformations | mittel | 3 | SyRS-024, SwRS-027, StRS-033 |
| M-010 | Administration: Connections | flach | 1 | SwRS-028 |
| M-011 | Administration: Customization | mittel | 2 | SwRS-029, StRS-032 |
| M-012 | Administration: DataSecurity | mittel | 3 | SyRS-022, SwRS-030, StRS-030 |
| M-013 | Administration: Documents/FileManagement | mittel | 3 | SwRS-031, SyRS-026, StRS-020 |
| M-014 | Administration: Employees | flach | 1 | SwRS-032 |
| M-015 | Administration: Environments | flach | 1 | SwRS-033 |
| M-016 | Administration: Licensing | tief | 3 | SyRS-003, SwRS-009, StRS-014 |
| M-017 | Administration: Logins/Auth | tief | 9 | SyRS-003, SyRS-004, SyRS-005, SyRS-006, SyRS-007, SwRS-002, SwRS-003, SwRS-005, StRS-013 |
| M-018 | Administration: Mandatory | mittel | 4 | SyRS-012, SwRS-012, SyRS-024, StRS-033 |
| M-019 | Administration: Masterdata | flach | 1 | SwRS-034 |
| M-020 | Administration: NetworkDiagnostics | flach | 1 | SwRS-035 |
| M-021 | Administration: PerformanceTests/Profiling | flach | 1 | SwRS-036 |
| M-022 | Administration: PhoneSettings | mittel | 2 | SwRS-037, SyRS-030 |
| M-023 | Administration: Portal | flach | 1 | SwRS-038 |
| M-024 | Administration: Rights | tief | 7 | SyRS-001, SyRS-002, SyRS-008, SwRS-001, SwRS-004, SwRS-008, StRS-012 |
| M-025 | Administration: Scripts/SQLManagement | flach | 1 | SwRS-039 |
| M-026 | Administration: Settings | mittel | 4 | SyRS-023, SwRS-040, SyRS-050, StRS-032 |
| M-027 | Administration: Themes | flach | 1 | SwRS-041 |
| M-028 | Administration: WebServiceConfiguration | flach | 1 | SwRS-042 |
| M-029 | AppointmentRequests | flach | 1 | SwRS-043 |
| M-030 | ArtificialIntelligence | mittel | 2 | SyRS-019, StRS-029 |
| M-031 | BusinessPartner | flach | 1 | SwRS-044 |
| M-032 | Buying | flach | 1 | SwRS-045 |
| M-033 | Calendar | mittel | 3 | SwRS-046, SyRS-029, SwRS-157 |
| M-034 | CentronIcons | flach | 1 | SwRS-047 |
| M-035 | CentronNexus (BL) | flach | 1 | SwRS-048 |
| M-036 | ChangeTracking | mittel | 3 | SyRS-009, SwRS-007, StRS-030 |
| M-037 | Chats | mittel | 2 | SwRS-049, StRS-017 |
| M-038 | CheckListArea | flach | 1 | SwRS-050 |
| M-039 | Core (BL-Kern) | mittel | 4 | SyRS-009, SyRS-010, SwRS-006, SwRS-007 |
| M-040 | CountryArea | flach | 1 | SwRS-051 |
| M-041 | CPra | flach | 1 | SwRS-052 |
| M-042 | CustomerArea | mittel | 2 | SwRS-059, StRS-023 |
| M-043 | Customizations (CustomTables) | mittel | 2 | SwRS-053, StRS-032 |
| M-044 | DataExchange | tief | 7 | SyRS-021, SwRS-057, SwRS-058, SyRS-043, StRS-009, StRS-010, StRS-021 |
| M-045 | Devices | mittel | 3 | SwRS-054, SyRS-028, StRS-022 |
| M-046 | DocuBoard | mittel | 3 | SwRS-055, SyRS-028, StRS-022 |
| M-047 | DocumentationArea | flach | 1 | SwRS-056 |
| M-048 | EDI | mittel | 4 | SyRS-027, SwRS-060, StRS-007, StRS-010 |
| M-049 | EmployeeArea | flach | 1 | SwRS-061 |
| M-050 | ExpectedEvents | flach | 1 | SwRS-062 |
| M-051 | ExternalHelpdesk | flach | 1 | SwRS-063 |
| M-052 | ExternalToolsBL | flach | 1 | SwRS-064 |
| M-053 | Finances | tief | 6 | SyRS-032, SwRS-065, SwRS-066, SyRS-050, SwRS-155, StRS-009 |
| M-054 | Gateway (BL) | flach | 1 | SwRS-067 |
| M-055 | GUI (BL-Anteil) | flach | 1 | SwRS-134 |
| M-056 | IndexSearch | mittel | 3 | SyRS-033, SwRS-068, StRS-027 |
| M-057 | Integrations | flach | 1 | SwRS-069 |
| M-058 | ItPlanner | flach | 1 | SwRS-070 |
| M-059 | Logistics | mittel | 2 | SwRS-071, StRS-008 |
| M-060 | Mail | mittel | 4 | SyRS-035, SwRS-072, SwRS-157, StRS-017 |
| M-061 | MailScanner | mittel | 2 | SyRS-036, SwRS-073 |
| M-062 | Mailings | mittel | 2 | SwRS-074, StRS-026 |
| M-063 | MassUpdate | mittel | 2 | SyRS-034, SwRS-075 |
| M-064 | Mobile | flach | 1 | SwRS-076 |
| M-065 | Modules | mittel | 2 | SwRS-077, StRS-014 |
| M-066 | MyCentron | mittel | 3 | SyRS-029, SwRS-078, StRS-018 |
| M-067 | MyDay | mittel | 4 | SyRS-029, SwRS-079, SwRS-158, StRS-018 |
| M-068 | NexusNotifications | flach | 1 | SwRS-080 |
| M-069 | NexusTicketViews | flach | 1 | SwRS-081 |
| M-070 | Notifications | flach | 1 | SwRS-082 |
| M-071 | ObjectExternalReferences | mittel | 2 | SwRS-083, StRS-021 |
| M-072 | Outlook | flach | 1 | SwRS-084 |
| M-073 | PasswordManagementArea | mittel | 2 | SwRS-085, StRS-028 |
| M-074 | PasswordManager | mittel | 2 | SwRS-086, StRS-028 |
| M-075 | Processes | flach | 1 | SwRS-087 |
| M-076 | ProductMatrix | mittel | 2 | SwRS-088, StRS-025 |
| M-077 | Production | mittel | 2 | SwRS-089, StRS-024 |
| M-078 | Projects | mittel | 2 | SwRS-090, StRS-025 |
| M-079 | Purchasing | mittel | 2 | SwRS-091, StRS-007 |
| M-080 | ReportEngine | mittel | 3 | SyRS-025, SyRS-043, StRS-015 |
| M-081 | Reporting | flach | 1 | SyRS-025 |
| M-082 | RiverDivo | flach | 1 | SwRS-101 |
| M-083 | Sales: Receipts (Belegwesen) | tief | 16 | SyRS-011, SyRS-012, SyRS-013, SyRS-014, SyRS-015, SyRS-016, SwRS-010, SwRS-013, SwRS-014, SwRS-015, SwRS-016, SwRS-017, SwRS-018, SwRS-154, StRS-002, StRS-003 |
| M-084 | Sales: CustomerAssets (Verträge) | tief | 11 | SyRS-028, SyRS-037, SyRS-038, SyRS-039, SwRS-092, SwRS-093, SwRS-094, SwRS-095, StRS-004, StRS-006, StRS-022 |
| M-085 | Sales: Customers (CRM) | flach | 1 | SwRS-102 |
| M-086 | Sales: Support (Helpdesk) | tief | 11 | SyRS-039, SyRS-040, SyRS-041, SwRS-095, SwRS-096, SwRS-097, SwRS-098, SwRS-099, SwRS-156, StRS-005, StRS-006 |
| M-087 | Sales: CashBooks | tief | 4 | SyRS-042, SwRS-100, StRS-003, StRS-009 |
| M-088 | Sales: Marketing | mittel | 2 | SwRS-103, StRS-026 |
| M-089 | Sales: Calendar | flach | 1 | SwRS-104 |
| M-090 | Sales: DocumentationWizardArea | flach | 1 | SwRS-105 |
| M-091 | Sales: HourlySurchargeRatesBL | flach | 1 | SwRS-106 |
| M-092 | Security (PdfSigning) | mittel | 2 | SwRS-107, StRS-020 |
| M-093 | SelfCare | mittel | 2 | SwRS-108, StRS-019 |
| M-094 | Services | flach | 1 | SwRS-109 |
| M-095 | SocialMedia | flach | 1 | SwRS-110 |
| M-096 | Start | flach | 1 | SwRS-111 |
| M-097 | Statistics | mittel | 2 | SwRS-135, StRS-016 |
| M-098 | Storage | mittel | 2 | SwRS-112, StRS-008 |
| M-099 | SystemArea | flach | 1 | SwRS-113 |
| M-100 | Tags | flach | 1 | SwRS-114 |
| M-101 | Tapi | mittel | 3 | SyRS-030, SwRS-115, StRS-017 |
| M-102 | TaskManager | flach | 1 | SwRS-116 |
| M-103 | Telemetry | flach | 1 | SwRS-117 |
| M-104 | TextModuleArea | flach | 1 | SwRS-118 |
| M-105 | TicketProjects | mittel | 2 | SwRS-119, StRS-025 |
| M-106 | Time | flach | 1 | SwRS-120 |
| M-107 | ToDoArea | mittel | 2 | SyRS-029, SwRS-121 |
| M-108 | Tools | flach | 1 | SwRS-122 |
| M-109 | TradePool | flach | 1 | SwRS-123 |
| M-110 | Transactions | flach | 1 | SwRS-124 |
| M-111 | TwoFactorAuthenticator | flach | 1 | SwRS-011 |
| M-112 | Urls | flach | 1 | SwRS-125 |
| M-113 | VideoPortal | flach | 1 | SwRS-126 |
| M-114 | VoucherManagement | flach | 1 | SwRS-127 |
| M-115 | Warehousing | mittel | 4 | SyRS-013, SwRS-014, SwRS-128, StRS-008 |
| M-116 | WebLinks | flach | 1 | SwRS-129 |
| M-117 | WebServices (BL) | flach | 1 | SwRS-136 |
| M-118 | WebSuite | flach | 1 | SwRS-130 |
| M-119 | WebVersion | flach | 1 | SwRS-131 |
| M-120 | Helpers (BL) | flach | 1 | SwRS-132 |
| M-121 | Exceptions (BL) | flach | 1 | SwRS-133 |
| M-122 | Centron.DAO (Persistenz) | flach | 1 | SwRS-137 |
| M-123 | Centron.Entities | flach | 1 | SwRS-138 |
| M-124 | Centron.Common | flach | 1 | SwRS-139 |
| M-125 | Centron.Interfaces | flach | 1 | SwRS-140 |
| M-126 | Centron.Gateway | mittel | 2 | SyRS-043, SwRS-141 |
| M-127 | Centron.WPF.UI (+ Extension) | mittel | 2 | SyRS-031, SwRS-142 |
| M-128 | Centron.Controls (+ Preview) | flach | 1 | SwRS-143 |
| M-129 | Centron.Core (shared) | flach | 1 | SwRS-144 |
| M-130 | CentronNexus (Blazor-Web) | mittel | 5 | SyRS-031, SyRS-045, SwRS-145, SwRS-156, StRS-019 |
| M-131 | CentronNexus.Host | flach | 1 | SwRS-145 |
| M-132 | CentronNexus.OutlookAddIn | flach | 1 | SwRS-145 |
| M-133 | Centron.Controllers (REST-API) | mittel | 3 | SyRS-031, SyRS-046, SwRS-147 |
| M-134 | Centron.WebServices.Core | flach | 1 | SwRS-146 |
| M-135 | Centron.Host (+ Console/WindowsService) | flach | 1 | SwRS-146 |
| M-136 | ConnectionManager | flach | 1 | SwRS-146 |
| M-137 | Centron.Api.EbInterface | flach | 1 | SyRS-043 |
| M-138 | Centron.Api.Gls | mittel | 3 | SyRS-044, SwRS-151, StRS-011 |
| M-139 | Centron.Api.Shipcloud | mittel | 3 | SyRS-044, SwRS-151, StRS-011 |
| M-140 | Centron.APIs.CopDataAccess | flach | 1 | SwRS-148 |
| M-141 | Centron.APIs.EgisDataAccess | flach | 1 | SwRS-148 |
| M-142 | Centron.APIs.FinAPI | flach | 1 | SwRS-149 |
| M-143 | Centron.APIs.IcecatDataAccess | flach | 1 | SwRS-148 |
| M-144 | Centron.APIs.ITscopeDataAccess | flach | 1 | SwRS-148 |
| M-145 | Centron.Api.docuFORM | flach | 1 | SwRS-150 |
| M-146 | Datenbankschema | flach | 1 | SwRS-152 |
| M-147 | Deployment/Installer | mittel | 3 | SyRS-048, SwRS-153, StRS-031 |
| M-148 | Docker/Betrieb | mittel | 4 | SyRS-047, SyRS-049, SwRS-153, StRS-031 |
| M-149 | Scripts | mittel | 2 | SyRS-048, SwRS-153 |
| M-150 | Dokumentation | nicht analysiert | 0 | – (reine Entwickler-/Betriebsdokumentation ohne eigene Systemfunktion; als KONTEXT-Belegquelle genutzt, z. B. für SyRS-043, SwRS-157) |
| M-151 | Tests | mittel | 2 | SyRS-049, StRS-031 |
**Summen:** tief: 9 Module, mittel: 58, flach: 83, nicht analysiert: 1 (gesamt 151 Module).
## Konsistenzcheck
Automatisiert über alle drei Spezifikationsdateien ausgeführt (241 Anforderungsblöcke):
| Prüfung | Ergebnis |
|---|---|
| Doppelte oder mehrfach vergebene IDs | keine (241 eindeutige IDs: 33 StRS, 50 SyRS, 158 SwRS) |
| Anforderungen ohne Beleg | keine (jeder Block enthält mind. einen klassifizierten Beleg) |
| Anforderungen ohne Übernahmewürdigkeit | keine |
| Anforderungen ohne Prüfidee | keine |
| Tracelinks auf nicht existierende IDs | keine |
| SwRS ohne SyRS-Referenz / SyRS ohne StRS-Referenz | keine (siehe Traceability.md) |
| Abgleich Hypothesen.md ↔ Inline-Markierungen | deckungsgleich: SyRS-050, SwRS-154, SwRS-155, SwRS-156, SwRS-157, SwRS-158 (6 Stück) |
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk | keine gefundenen; erkannte fachliche Doppelimplementierungen sind als Konsolidierungskandidaten markiert (siehe Liste unten) |
**Wesentliche Konsolidierungskandidaten (fachlich gleiche Konzepte in getrennten Implementierungen):**
1. Gerätedatenhaltungen: AccountDevices (M-045) vs. CustomerAssets/„Stammblätter" (M-084) vs. DocuBoard-Assetmanagement (M-046) → ein Asset-Konzept (SyRS-028, StRS-022).
2. Zwei Belegmodelle: Sales/Receipts (neu) vs. Sales/CustomerAssets (alt) für dieselben Belegarten (SyRS-011).
3. Zwei Rechtemodelle: interne Rechte (Sichtrus/Sichmemb) vs. WebAccountsRights (SyRS-001/SyRS-002).
4. Drei 2FA-Wege: RADIUS, E-Mail-Link, TOTP (SyRS-005, SwRS-011).
5. Zwei Passwortverwaltungen: PasswordManagementArea vs. PasswordManager (SwRS-085/SwRS-086).
6. Zwei Workflow-/Prozess-Engines: Processes vs. Services/Workflows (SwRS-087/SwRS-109); zusätzlich MailScanner-Workflows (SyRS-036).
7. Zwei Customizing-Mechanismen: Custom Properties vs. Custom Tables (SwRS-029/SwRS-053).
8. Drei Projektbegriffe: Projects, CrmProjects, TicketProjects (SwRS-090/SwRS-119, StRS-025).
9. Zwei Aufgabenkonzepte: ToDoArea vs. TaskManager (SwRS-116/SwRS-121).
10. Zwei Benachrichtigungssysteme: Notifications vs. NexusNotifications (SwRS-080/SwRS-082).
11. EDI-Logik doppelt: Centron.BL/EDI vs. Centron.Gateway/EDI_* (SyRS-027/SwRS-141).
12. Bankverbindungen doppelt: Felder in Tabelle Kunden vs. BankAccount-Objekte (SwRS-152/SwRS-019).
13. Zwei Endkunden-Formularwege: SelfCare vs. Nexus-Kundenportal-Formulare (SwRS-108/SyRS-045).
14. Versandwege GLS-direkt vs. Shipcloud (SyRS-044).
15. Desktop-Client (WPF) vs. Nexus-Web-UI für dieselben Prozesse (SyRS-031, SwRS-142/SwRS-145).
## Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
75 Anforderungen sind risikorelevant. Belegsituation:
| ID | Titel | PRIMÄR-Beleg vorhanden | Status |
|---|---|---|---|
| SyRS-001 | Gruppenbasierte Benutzerrechtepruefung | ja | belegt |
| SyRS-002 | Getrenntes Rechtemodell fuer Web-Accounts | ja | belegt |
| SyRS-003 | Ticketbasierte Sitzungen mit Lizenzpruefung | ja | belegt |
| SyRS-004 | Mehrere Authentifizierungsverfahren | ja | belegt |
| SyRS-005 | Zwei-Faktor-Authentifizierung | ja | belegt |
| SyRS-006 | Zeitgesteuerte Kontodeaktivierung | ja | belegt |
| SyRS-007 | Anwendungsbezogene Anmelderechte | ja | belegt |
| SyRS-008 | Standard-Rechtegruppen | ja | belegt |
| SwRS-001 | Rechteermittlung SQL+Cache | ja | belegt |
| SwRS-002 | Passwort SHA1 ungesalzen | ja | belegt |
| SwRS-003 | 2FA-Validatorwahl | ja | belegt |
| SwRS-004 | Rechtegruppenverwaltung | ja | belegt |
| SwRS-005 | Ticket-Wiederverwendung+LoginIP | ja | belegt |
| SwRS-008 | Standardrechtegruppen aus Ressource | ja | belegt |
| SwRS-009 | Signaturvalidierte Lizenzdatei | ja | belegt |
| SyRS-011 | Belegkette Weiterfuehrungswege | ja | belegt |
| SyRS-012 | Nummernkreise je Mandant/Filiale | ja | belegt |
| SyRS-013 | Bestandswirkung der Belege | ja | belegt |
| SyRS-014 | Mindestpreisschutz | ja | belegt |
| SwRS-010 | Belegnummernvergabe+Templatekunde | ja | belegt |
| SwRS-011 | TOTP-Zweitfaktor | ja | belegt |
| SwRS-012 | Nummernkreis-Kaskade | ja | belegt |
| SwRS-014 | Negativbuchung nur mit Recht | ja | belegt |
| SwRS-015 | Mindestpreis-Reauth | ja | belegt |
| SyRS-017 | API-Zugriffstokens | ja | belegt |
| SwRS-019 | Bankverbindungen Rechte+Default | ja | belegt |
| SwRS-020 | Kontenstamm Rechte+FiBu-Nummer | ja | belegt |
| SwRS-021 | API-Token Hash+Ablauf+Log | ja | belegt |
| SwRS-026 | Konfig-DB Masterkey | ja | belegt |
| SyRS-022 | DSGVO Loeschkonzept | ja | belegt |
| SwRS-027 | Kollisionssichere Nummernvergabe | ja | belegt |
| SwRS-030 | DSGVO-Kontaktloeschung | ja | belegt |
| SyRS-021 | FiBu-Uebergabe DATEV | ja | belegt |
| SwRS-057 | FiBu-Exportkonfigurationen | ja | belegt |
| SwRS-058 | Doppeluebergabeschutz FiBu | ja | belegt |
| SyRS-032 | Onlinebanking-Zahlungsabgleich | ja | belegt |
| SwRS-065 | Zahlungseingangsprotokoll | ja | belegt |
| SwRS-066 | Bankumsatz-Zuordnung/Buchung | ja | belegt |
| SwRS-085 | Kundenzugangsdaten+Logs | ja | belegt |
| SwRS-086 | Passwortmanager Siegel | ja | belegt |
| SyRS-037 | Vertragsverwaltung Laufzeit/Intervalle | ja | belegt |
| SyRS-038 | Automatische Vertragsfakturierung | ja | belegt |
| SyRS-039 | Timer-Billing | ja | belegt |
| SyRS-040 | Helpdesk Rechte+Status | ja | belegt |
| SyRS-042 | Kassenbuch | ja | belegt |
| SwRS-092 | Vertrags-Datumsarithmetik | ja | belegt |
| SwRS-093 | Auto-Vertragsschliessen | ja | belegt |
| SwRS-094 | Abrechnungsfaellige Kunden+Zaehler | ja | belegt |
| SwRS-095 | Timer-Belegerzeugung | ja | belegt |
| SwRS-096 | Ticket-Rechtepruefung Save | ja | belegt |
| SwRS-097 | Ticket-Sichtbarkeit restriktiv | ja | belegt |
| SwRS-100 | Kassenbuchbuchung | ja | belegt |
| SwRS-101 | Riverbird-Ticketvalidierung | ja | belegt |
| SwRS-106 | Stundenzuschlagssaetze | ja | belegt |
| SwRS-107 | PDF-Signatur | ja | belegt |
| SwRS-112 | Inventur | ja | belegt |
| SwRS-127 | Gutscheinverwaltung | ja | belegt |
| SyRS-043 | E-Rechnungsformate | ja | belegt |
| SyRS-046 | REST-API Rechteautorisierung | ja | belegt |
| SwRS-144 | Core-Bibliothek TOTP | ja | belegt |
| SwRS-147 | Versionierte Controller | ja | belegt |
| SwRS-149 | finAPI-Client | ja | belegt |
| SyRS-050 | [HYPOTHESE] Mahnwesen | nein | HYPOTHESE |
| SwRS-154 | [HYPOTHESE] Anzahlungsverrechnung | ja | HYPOTHESE |
| SwRS-155 | [HYPOTHESE] SEPA-Lastschrift | ja | HYPOTHESE |
| StRS-003 | Geschuetzte Fakturierung | ja | belegt |
| StRS-004 | Vertragsgeschaeft | ja | belegt |
| StRS-006 | Leistungserfassung | ja | belegt |
| StRS-009 | Finanzprozesse | ja | belegt |
| StRS-010 | E-Belegaustausch | ja | belegt |
| StRS-012 | Berechtigungssteuerung | ja | belegt |
| StRS-013 | Sichere Anmeldung/API | ja | belegt |
| StRS-014 | Lizenz-/Modulsteuerung | ja | belegt |
| StRS-028 | Kundenzugangsdaten | ja | belegt |
| StRS-030 | DSGVO+Audit | ja | belegt |
**Regelprüfung:** Alle risikorelevanten Anforderungen besitzen entweder einen PRIMÄR-Beleg mit benannter durchsetzender Stelle oder sind als `[HYPOTHESE]` gekennzeichnet (betrifft SyRS-050 Mahnwesen). Kein Verstoß gegen die risikobasierte Priorisierung.
## Selbstbewertung
**Umfang des Laufs:** 241 Anforderungen (33 StRS, 50 SyRS, 158 SwRS) über 151 Inventarmodule; 6 Hypothesen (2,5 %); 75 risikorelevante Anforderungen.
**Analysetiefe (absolute Zahlen):**
- tief: 9 Module (M-016 Licensing, M-017 Logins/Auth, M-024 Rights, M-044 DataExchange/FiBu, M-053 Finances/Onlinebanking, M-083 Receipts/Belegwesen, M-084 CustomerAssets/Verträge, M-086 Support/Helpdesk, M-087 CashBooks) - Kernlogik der risikorelevanten Pfade wurde im Quelltext gelesen.
- mittel: 58 Module (2-3 Anforderungen, Kernmethoden gelesen).
- flach: 83 Module (1 Anforderung auf Basis von Klassen-/Methodensignaturen und gezielten Codeausschnitten).
- nicht analysiert: 1 Modul (M-150 docs - reine Dokumentation, als KONTEXT-Belegquelle genutzt).
**Mindestabdeckung:** erreicht. Jedes der 151 Module hat mindestens eine Anforderung; einzige Ausnahme ist M-150 mit dokumentierter Begründung (zulässig laut Vorgabe: `nicht analysiert` mit Begründung).
**Dünne Belegstellen (ehrliche Abgrenzung):**
- Bei flach eingestuften Modulen stützen sich die PRIMÄR-Belege auf gelesene Methodensignaturen und kurze Codeausschnitte, nicht auf vollständige Methodenrümpfe (z. B. SwRS-047 Icons, SwRS-070 ItPlanner, SwRS-090 Projekte, SwRS-124 Transactions, SwRS-143 Controls). Die Aussagen sind bewusst eng an den gesicherten Befund formuliert.
- Rein strukturbasierte Belege (Ordner-/Projektexistenz statt Prüf logik) tragen SwRS-142 (WPF-Client), SwRS-143 (Controls), SwRS-145 (Nexus), SwRS-146 (Hosting), SyRS-031 (Mehrkanal), SyRS-049 (Tests) - hier ist die Existenz der Struktur selbst der Fakt.
- Hypothesen betreffen v. a. Abrechnungsdetails (Mahnwesen, SEPA-Datei, Anzahlungsverrechnung) und Web-/Sync-Verhalten (WebCart-Sortiment, Exchange-Sync, Supremo).
- SEKUNDÄR/KONTEXT-lastig sind SyRS-050 (nur Konfigurationsschalter) und SwRS-156 (nur README + Klassenexistenz) - beide korrekt als HYPOTHESE geführt.
**Hypothesenquote:** 6 von 241 (2,5 %). Der Wert liegt bewusst über null: Bei einer Codebasis dieser Größe (u. a. 11.441 Zeilen allein in ReceiptBL.cs, 1558 DB-Tabellen) bleiben nach einem Lauf zwangsläufig offene Kernfragen; die sechs Hypothesen benennen sie explizit.
**Erkenntnisse für eine Folge-Iteration (Nachschlag empfohlen):**
1. Mahnwesen lokalisieren und als belegte Anforderungen ausarbeiten (SyRS-050) - abrechnungskritisch.
2. DownPaymentBL, SEPA-Erzeugung und ReceiptItemPriceBL/ReceiptPriceHelperBL (Preisberechnung inkl. Rabatt-/Staffellogik) vertiefen - die Preisermittlungsformeln selbst wurden nicht spezifiziert.
3. Das alte Belegmodell Sales/CustomerAssets systematisch gegen Sales/Receipts differenzieren (welche Masken nutzen noch das Altmodell?).
4. WebServices-BL (464 Dateien) und Centron.Controllers-Endpunkte vollständig katalogisieren (API-Oberfläche als eigenes Spezifikationskapitel).
5. DB-Schema systematisch auswerten (Constraints/Trigger je Kerntabelle); in diesem Lauf nur punktuell genutzt (Tabelle Kunden).
6. WPF-Masken (Views/Wizards) und Nexus-Seiten fachlich durchgehen, um UI-nahe Regeln (Pflichtfelder, Sichtbarkeiten) zu heben - bisher überwiegend BL-getrieben analysiert.
7. Statistiken/Reports einzeln inventarisieren (Reportvorlagenbestand ist Migrationsaufwandstreiber).
**Methodische Anmerkungen:**
- Alle Anforderungen wurden aus statischer Analyse gewonnen; keine Ausführung, keine externen Werkzeuge.
- Die Change-Historie (Git) wurde nicht ausgewertet, da im Arbeitsverzeichnis keine Commit-Metadaten als Dateien vorlagen (nur der Code-Snapshot); Schritt 2 der Methodenkette ist insoweit teilweise erfüllt (Projektartefakte docs/, README, CentronRights.md wurden genutzt).
@@ -0,0 +1,47 @@
# Glossar – c-entron ERP-Suite
Domänenbegriffe, wie sie in den Anforderungen verwendet werden. Technische Bezeichner (Klassen,
Tabellen) in Originalschreibweise.
| Begriff | Bedeutung |
|---|---|
| Abholliste / Abholschein (PickupList) | Beleg über die Rücknahme von Ware vom Kunden; bucht Bestand zu. |
| AppUser | Internes Benutzerkonto (Tabelle `Sichbenu`); mit Mitarbeiter (Employee) verknüpft. |
| Asset (CustomerAsset) | Historischer Oberbegriff des alten Belegmodells („Vorgang") unter Sales/CustomerAssets; zugleich Begriff für beim Kunden befindliche Geräte („Stammblätter"). |
| AssetCondition | Stammdatensatz für Zahlungs-/Lieferkonditionen; steuert u. a. Kassenbuchwirkung (`ChangesCashBook`) und automatisches Schließen von Belegen. |
| AutomaticFactura | Automatische Vertragsfakturierung inkl. Zählerstands- und Sammelrechnungslogik. |
| Barbeleg / IsCashAsset | Beleg mit Barzahlung; eigener Nummernkreis (CashInvoice/CashOffer) und Kassenbuchbindung. |
| Belegkette | Zulässige Weiterführungspfade zwischen Belegarten (Angebot → Auftrag → Lieferschein → Rechnung → Gutschrift; Vertrag → Rechnung). |
| BranchOrigin | Regel, aus welcher Person (Ersteller oder Vertriebsmitarbeiter) die Filiale eines neuen Belegs abgeleitet wird. |
| c-entron Nexus | Blazor-basierter Webclient (interne Web-Oberfläche und Kundenportal). |
| CashBookRecord | Kassen-Belegart je Steuersatz/Filiale mit Sachkonto und Steuerschlüssel; Voraussetzung jeder Kassenbuchbuchung. |
| CentronObjectKindNumeric | Systemweiter numerischer Katalog der Objektarten (Belegarten, Tickets, Konten …). |
| Concurrency-Control-Guid | Token je Beleg zur Erkennung konkurrierender Änderungen bei Einzelfeld-Updates. |
| Dispatcher | Ausgezeichneter Mitarbeiter für die Einsatz-/Ticketverteilung (genau einer). |
| Distributor | Großhändler/Lieferant der IT-Branche (ALSO, Alltron, EGIS, Komsa, Herweck, ITscope …). |
| EDI | Elektronischer Datenaustausch mit Distributoren (Bestellungen, Auftragsbestätigungen) in herstellerspezifischen Formaten. |
| Eskalation | Dreistufige Fristenüberwachung überfälliger Vorgänge mit Zeitstempeln `Eskalation1Am`–`Eskalation3Am`. |
| Firmengruppe (CompanyGroup) | Konzernverbund von Kundenkonten; kann Belegeinstellungen der Gruppe vererben (`UseSettingsFromCompanyGroupForReceipts`). |
| Helpdesk / Ticket | Supportvorgang mit Status, Verantwortlichem, Fälligkeit, Timern und Eskalation. |
| Helpdesk-Timer | Am Ticket erfasste Arbeitszeit; Grundlage der Leistungsabrechnung (Timer-Billing). |
| I3D | Systemweiter Primärschlüssel der Geschäftsobjekte (zentral vergeben, keine Identity-Spalten). |
| Lieferschein (DeliveryList) | Bestandswirksamer Auslieferungsbeleg; bucht Bestand ab. |
| Mandant (Mandator) | Rechtlich eigenständige Firma innerhalb einer Installation; Filialen (Branch) sind Mandanten zugeordnet. |
| Mindestpreis (MinPrice) | Artikeluntergrenze; Unterschreitung nur per Recht bzw. Zweitanmeldung (Vier-Augen-Prinzip). |
| MSP / MSP-Collector | Managed-Service-Provider-Funktionen; Collector sammelt Verbrauchs-/Gerätedaten für Auswertung und Abrechnung. |
| Nummernkreis (NumberGroup) | Fortlaufender Nummernvorrat je Belegart, Mandant und Filiale mit Fallback-Kaskade. |
| Receipt | Beleg im neueren Belegmodell (Sales/Receipts); ersetzt schrittweise das CustomerAssets-Modell. |
| Rechtegruppe (AppGroup) | Bündel von Rechten (Tabelle `Sichtrus`), Benutzern über `Sichmemb` zugeordnet. |
| Restriktives Recht | Recht, das die Sicht einschränkt statt erweitert (z. B. „Tickets anzeigen – nur eigene"). |
| RMA | Reklamationsvorgang: Rücknahme vom Kunden (SendBack) und Weiterleitung an den Lieferanten (SendForth). |
| Sammelrechnung (Collective Invoice) | Eine Rechnung über mehrere Verträge/Leistungen eines Kunden oder Konzerns. |
| SelfCare | Web-Formulare, über die Endkunden Anfragen einreichen. |
| Sonderpreis | Kundenindividueller Artikelpreis; laut Doku Basis des WebCart-Sortiments. |
| Stammblatt | Historische Bezeichnung für Gerätedatensätze beim Kunden (v. a. Drucker); Konsolidierungskandidat zum Asset-Konzept. |
| Ticket (Anmeldung) | Sitzungsnachweis nach erfolgreicher Authentifizierung (nicht zu verwechseln mit Helpdesk-Ticket). |
| Timer-Billing | Überführung erfasster Ticketzeiten in Abrechnungsbelege unter Vertrags-/Kontingentbeachtung. |
| Vertrag (ReceiptContract) | Wiederkehrend abzurechnender Beleg mit Laufzeit, Kündigung, Verlängerung und Abrechnungsintervall. |
| Web-Account | Externer Kundenzugang (Portal/Shop) mit eigenem Rechtemodell (`WebAccountsRights`). |
| WebCart | Shop-Bereich des Kundenportals im Nexus. |
| Zählerstand (Counter) | Nutzungswert je Gerät/Vertrag (z. B. Druckseiten) als Abrechnungsgrundlage. |
| ZUGFeRD / Factur-X | Hybrides E-Rechnungsformat (PDF mit eingebettetem XML), hier in Version 2.1 Extended. |
@@ -0,0 +1,23 @@
# Hypothesen – c-entron ERP-Suite
Diese Datei enthält **genau die Anforderungen mit `[HYPOTHESE]`-Markierung** aus StRS/SyRS/SwRS
(deckungsgleich mit den Inline-Markierungen, keine zusätzlichen freien Fragen). Offene Punkte ohne
zugehörige Anforderung stehen in der Selbstbewertung des Analyseberichts.
Stand: 6 Hypothesen bei 241 Anforderungen (2,5 %).
| ID | Titel | Offene Frage (fehlende Information zur Bestätigung) |
|---|---|---|
| SyRS-050 | Mahnwesen mit drei Mahnstufen und Belegsperre | Wo liegt die durchsetzende Mahnlauf-Logik (Stufenermittlung, Mahnschreiben, Sperrprüfung)? Nur Konfigurationsschalter (DunningLevel1-3Text, CustomerAssetsLockedAfterDunningLevel) wurden gefunden. |
| SwRS-154 | Verrechnung von Anzahlungen in der Schlussrechnung | Wie verrechnet DownPaymentBL geleistete Anzahlungen konkret in der Schlussrechnung (Positionslogik, Steuerbehandlung)? |
| SwRS-155 | SEPA-Lastschrifteinzug aus Rechnungen | Wo wird die SEPA-XML-Einzugsdatei erzeugt (vermutlich Gateway/OnlineBanking)? Mandatsbindung und Statusfeld `directDebitCreated` sind belegt, die Dateierzeugung nicht. |
| SwRS-156 | Webshop-Sortiment aus Kunden-Sonderpreisen | Welche Codestelle im Nexus-WebCart schränkt das Sortiment auf die Sonderpreise des Kunden ein? Bisher nur README-Aussage und Existenz von CustomerSpecialArticleBL. |
| SwRS-157 | Bidirektionale Exchange-Terminsynchronisation | Synchronisationsrichtung, Konfliktauflösung und Auslöser der Kalendersynchronisation (EWS vs. Graph) sind nicht aus dem Code verifiziert. |
| SwRS-158 | Fernwartungsstart (Supremo) aus dem Arbeitsplatz | Wie wird die Supremo-Sitzung aufgebaut (Parameter, Zielgerätezuordnung)? Nur Komponenten (MyDay/Supremo.cs, assemblies/remote-desktop) belegt. |
## Hinweis zur risikobasierten Priorisierung
SyRS-050, SwRS-154 und SwRS-155 betreffen Abrechnung/Fakturierung. SwRS-154/155 besitzen je einen
`PRIMÄR`-Beleg für den belegten Teilaspekt; die dennoch offene Kernregel ist der Grund für die
Hypothesen-Kennzeichnung. SyRS-050 besitzt keinen `PRIMÄR`-Beleg und ist deshalb zwingend als
`[HYPOTHESE]` geführt (regelkonform).
@@ -0,0 +1,669 @@
# StRS – Stakeholder Requirements Specification
**System:** c-entron ERP-Suite | **Quelle:** Statische Codeanalyse | **Lauf:** 2026-08-27
Fachliche Anforderungen aus Stakeholdersicht (Akteure, Geschäftsziele). Grundlage: aus der Codebasis rekonstruierte Fachfunktionen.
---
**Zielgruppe des Systems (aus der Codebasis rekonstruiert):** IT-Systemhäuser und Managed-Service-Provider im DACH-Raum (deutschsprachige Fachbegriffe, DATEV-/SEPA-/ZUGFeRD-Bezüge, Distributoren-EDI ALSO/Alltron/EGIS/Komsa/Herweck, Schweiz-Spezifika in Receipts/Switzerland).
```
ID: StRS-001
Titel: Zentrale Geschäftspartnerverwaltung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Einkauf, Verwaltung
Vorbedingung: -
Fakt: Die Codebasis führt Konten mit Rollen Kunde/Lieferant, Adressen, Ansprechpartnern, Klassifikationen, Firmengruppen, Bankverbindungen und Länder-/Währungsbezug (Accounts, Sales/Customers, CountryArea, Accounting).
Aussage: Das Unternehmen soll alle Geschäftspartner (Kunden, Lieferanten, Interessenten) einheitlich mit Adressen, Ansprechpartnern, Konditionen und Bankdaten verwalten können.
Ergebnis: Ein Partnerstamm als Basis aller Prozesse.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs (SaveAccount, Kontotypen) - Begründung: implementiert die Partnerverwaltung.
Prüfidee: Partner als Kunde und Lieferant führen; alle Belegprozesse referenzieren denselben Stamm.
Tracelinks: SyRS-020, SyRS-024
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Fundament.
Status: belegt
```
```
ID: StRS-002
Titel: Durchgängige Angebots- und Auftragsabwicklung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb
Vorbedingung: Kunde existiert.
Fakt: Belegkette Angebot → Auftrag → Lieferschein → Rechnung (→ Gutschrift) mit Weiterführung, Versionierung, Sperren und Vorlagen ist implementiert (Sales/Receipts).
Aussage: Der Vertrieb soll Verkaufsvorgänge vom Angebot bis zur Rechnung ohne Doppelerfassung abwickeln können; jeder Schritt bleibt nachvollziehbar.
Ergebnis: Lückenlose, versionierte Belegkette.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (ForwardReceipt, CreateNewVersion) - Begründung: implementiert die Kette.
Prüfidee: Kompletten Durchlauf Angebot→Rechnung ohne Neuerfassung der Positionen durchführen.
Tracelinks: SyRS-011, SyRS-015, SyRS-016
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess.
Status: belegt
```
```
ID: StRS-003
Titel: Korrekte und geschützte Fakturierung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Buchhaltung, Geschäftsführung
Vorbedingung: Leistungen/Lieferungen sind erbracht.
Fakt: Rechnungen, Barrechnungen, interne Rechnungen und Gutschriften haben eigene Nummernkreise; Mindestpreise sind geschützt (Vier-Augen-Prinzip); Kassenbuchbuchungen entstehen automatisch (Receipts/Invoices, CashBooks, NumberGroups).
Aussage: Das Unternehmen soll Rechnungen und Gutschriften mit eindeutigen Nummern, geschützten Preisuntergrenzen und automatischer Kassenanbindung erstellen können.
Ergebnis: Revisionssichere Fakturierung ohne Margenverlust.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs (Nummernkreise), ReceiptBL.CheckArticleMinPrices - Begründung: implementieren die Schutzregeln.
Prüfidee: Rechnung unter Mindestpreis ohne Freigabe; erwartet: verhindert.
Tracelinks: SyRS-012, SyRS-014, SyRS-042, SyRS-050
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Umsatz- und Compliance-Kern.
Status: belegt
```
```
ID: StRS-004
Titel: Vertragsgeschäft mit wiederkehrender Abrechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsführung, Vertragsverwaltung, Buchhaltung
Vorbedingung: Serviceverträge sind abgeschlossen.
Fakt: Verträge mit Laufzeiten, Verlängerung, Intervallen, Zählerständen und automatischer Fakturierung inkl. Sammelrechnung sind implementiert (CustomerAssets/Contracts, AutomaticFactura).
Aussage: Das Unternehmen soll wiederkehrende Umsätze (Wartung, Miete, Managed Services, Seitenpreise) automatisch, vollständig und periodengerecht abrechnen können.
Ergebnis: Planbare, automatisierte Vertragsumsätze.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, AutomaticFactura/AutomaticFacturaBL.cs - Begründung: implementieren das Vertragsgeschäft.
Prüfidee: Jahresvertrag mit Zähler; erwartet: 12 korrekte Perioden, keine Lücke/Doppel.
Tracelinks: SyRS-037, SyRS-038, SyRS-039
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - strategischer Umsatzträger.
Status: belegt
```
```
ID: StRS-005
Titel: Professioneller Kundensupport (Helpdesk)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Support, Support-Leitung, Endkunde
Vorbedingung: Kunde meldet Anliegen.
Fakt: Ticketsystem mit Status, Kategorien, Prioritäten, Zeiterfassung, Eskalation, Abschlussbenachrichtigung, Ticket-Projekten und Web-Zugriff ist implementiert (Sales/Support, NexusTicketViews).
Aussage: Der Support soll Kundenanliegen als Tickets mit Verantwortlichen, Fälligkeiten und Eskalationen bearbeiten; Kunden sollen ihre Tickets online verfolgen können.
Ergebnis: Nachvollziehbarer, SLA-fähiger Supportprozess.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Escalation/EscalationBL.cs - Begründung: implementieren den Prozess.
Prüfidee: Ticket mit SLA-Verletzung; erwartet: dreistufige Eskalation.
Tracelinks: SyRS-040, SyRS-041, SyRS-036
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess des Systemhauses.
Status: belegt
```
```
ID: StRS-006
Titel: Lückenlose Leistungserfassung und -verrechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Techniker, Buchhaltung
Vorbedingung: Leistungen werden erbracht.
Fakt: Ticket-Timer mit Abrechnungsstatus, Stundenzuschlagssätzen und Belegerzeugung sind implementiert (HelpdeskTimer*, TimerBilling, HourlySurchargeRates).
Aussage: Erbrachte Arbeitszeiten sollen vollständig erfasst und - unter Berücksichtigung von Verträgen und Zuschlägen - genau einmal verrechnet werden.
Ergebnis: Kein Leistungsverlust zwischen Erbringung und Rechnung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs - Begründung: implementiert die Verrechnung.
Prüfidee: Erfasste Zeit doppelt abrechnen; erwartet: verhindert.
Tracelinks: SyRS-039
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - direkter Umsatzhebel.
Status: belegt
```
```
ID: StRS-007
Titel: Effizienter Einkauf mit Distributorenanbindung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Einkauf
Vorbedingung: Bedarf besteht.
Fakt: Bestellvorschläge, Lieferantenbestellungen, EDI-Übertragung an Distributoren und externe Artikel-/Preissuche (ITscope, EGIS, COP, Icecat) sind implementiert.
Aussage: Der Einkauf soll Bedarfe automatisch erkennen, Preise/Verfügbarkeiten der Distributoren direkt einsehen und Bestellungen elektronisch übertragen können.
Ergebnis: Schneller, fehlerarmer Einkaufsprozess.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs, EDI/EDIDispatcherBL.cs - Begründung: implementieren den Prozess.
Prüfidee: Unterschreitung Mindestbestand bis EDI-Bestellung durchspielen.
Tracelinks: SyRS-027; SwRS-091, SwRS-148
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess des IT-Handels.
Status: belegt
```
```
ID: StRS-008
Titel: Verlässliche Artikel- und Lagerführung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Lager, Einkauf, Vertrieb
Vorbedingung: Artikelstamm existiert.
Fakt: Artikelstamm mit EAN, Preisen, Seriennummern-/Barcodeverfolgung, Mehrlager, Umbuchungslog, Inventur und belegbasierter Bestandsführung ist implementiert (Warehousing, Logistics, Storage).
Aussage: Bestände sollen jederzeit korrekt, seriennummerngenau und je Lagerort nachvollziehbar sein; jede Veränderung hat einen Belegbezug.
Ergebnis: Inventurfähige Bestandsführung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs, Warehousing/ArticleBL.cs - Begründung: implementieren die Bestandsführung.
Prüfidee: Bestandsdifferenz erzeugen; erwartet: über Belege/Umbuchungslog aufklärbar.
Tracelinks: SyRS-013, SyRS-034; SwRS-112
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kernprozess.
Status: belegt
```
```
ID: StRS-009
Titel: Nahtlose Finanzprozesse (Zahlungen, FiBu, Mahnwesen)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung, Steuerberater
Vorbedingung: Belege sind fakturiert.
Fakt: Onlinebanking-Zahlungsabgleich, Zahlungsprotokolle, DATEV-Export mit Doppelübergabeschutz und Kassenbuch sind implementiert; Mahnwesen ist konfigurierbar angelegt.
Aussage: Zahlungseingänge sollen automatisch zugeordnet, offene Posten gemahnt und alle Buchungsdaten ohne Doppelerfassung an die Finanzbuchhaltung (DATEV) übergeben werden.
Ergebnis: Geschlossener Order-to-Cash-Kreislauf.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs, DataExchange/BookKeeping/BookKeepingExportBL.cs - Begründung: implementieren die Finanzprozesse.
Prüfidee: Zahlungseingang bis DATEV-Export durchspielen; keine manuelle Doppelerfassung nötig.
Tracelinks: SyRS-021, SyRS-032, SyRS-042, SyRS-050
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Pflichtprozess.
Status: belegt
```
```
ID: StRS-010
Titel: Elektronischer Belegaustausch und E-Rechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung, Kunden, Behörden, Distributoren
Vorbedingung: Belege werden ausgetauscht.
Fakt: ZUGFeRD/Factur-X, XRechnung-Schnittstellen, ebInterface (AT) und Distributoren-EDI sind implementiert.
Aussage: Das Unternehmen soll Belege elektronisch in den gesetzlich bzw. vom Partner geforderten Formaten senden und empfangen können.
Ergebnis: E-Rechnungs- und EDI-Konformität.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ReportEngine/CustomPdfGenerators/CustomZugferdPdfGenerator.cs; Centron.Gateway/ZUGFeRD21_Extended - Begründung: implementieren die Formate.
Prüfidee: ZUGFeRD-Rechnung gegen Validator prüfen.
Tracelinks: SyRS-043, SyRS-027
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - gesetzlich getrieben.
Status: belegt
```
```
ID: StRS-011
Titel: Integrierte Versandabwicklung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Lager/Versand
Vorbedingung: Lieferung ist kommissioniert.
Fakt: GLS- und Shipcloud-Anbindungen erzeugen Sendungen aus dem System (src/apis).
Aussage: Versandlabel und Tracking sollen direkt aus dem Lieferbeleg erzeugt werden.
Ergebnis: Kein Medienbruch im Versand.
Belege:
- [PRIMÄR] src/apis/Centron.Api.Gls/CentronGlsLogic.cs - Begründung: implementiert den Versand.
Prüfidee: Label aus Lieferschein erzeugen.
Tracelinks: SyRS-044
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Logistikstandard.
Status: belegt
```
```
ID: StRS-012
Titel: Feingranulare Berechtigungssteuerung
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Geschäftsführung, Administrator, alle Benutzer
Vorbedingung: -
Fakt: Gruppenbasiertes Rechtesystem mit hunderten Einzelrechten, restriktiven Rechten (nur eigene/Filiale), Rollenvorlagen und Rechteprotokoll ist implementiert.
Aussage: Jede Funktion und jede Datensicht soll einzeln berechtigt werden können; Standardrollen erleichtern die Einführung; Rechteänderungen sind nachvollziehbar.
Ergebnis: Need-to-know-Prinzip im gesamten System.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs - Begründung: implementiert das Rechtesystem.
Prüfidee: Stichprobe: Funktion ohne Recht aufrufen; erwartet: verweigert.
Tracelinks: SyRS-001, SyRS-002, SyRS-006, SyRS-007, SyRS-008
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Sicherheitsfundament.
Status: belegt
```
```
ID: StRS-013
Titel: Sichere Anmeldung und API-Zugänge
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Alle Benutzer, externe Systeme
Vorbedingung: -
Fakt: Mehrere Authentifizierungsverfahren, Zwei-Faktor-Optionen, Sitzungstickets, gehashte API-Tokens und deklarativ geschützte REST-Endpunkte sind implementiert.
Aussage: Zugriffe von Menschen und Systemen sollen stark authentifiziert, zeitlich begrenzt und protokolliert sein.
Ergebnis: Kontrollierter Zugang über alle Kanäle.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, AccessTokens/AccessTokenBL.cs - Begründung: implementieren die Zugriffssicherung.
Prüfidee: Penetrationstest der Anmeldewege.
Tracelinks: SyRS-003, SyRS-004, SyRS-005, SyRS-017, SyRS-046
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - im Zielsystem modernisieren (Passworthashing!).
Status: belegt
```
```
ID: StRS-014
Titel: Lizenz- und Modulsteuerung des Produkts
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Hersteller, Kunde (Systemhaus)
Vorbedingung: -
Fakt: Signierte Lizenzdateien, Seat-Prüfung bei Anmeldung, Feature-Gates (ModuleFeatures) und Modulkatalog sind implementiert.
Aussage: Der Funktionsumfang je Installation soll sich aus der erworbenen Lizenz ergeben; Überbelegung von Arbeitsplätzen wird verhindert.
Ergebnis: Durchgesetztes Lizenzmodell.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs - Begründung: implementiert die Lizenzsteuerung.
Prüfidee: Anmeldung über Seat-Limit; erwartet: abgelehnt.
Tracelinks: SyRS-003; SwRS-009, SwRS-139
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - als SaaS-Abomodell neu umsetzen.
Status: belegt
```
```
ID: StRS-015
Titel: Professioneller Belegdruck und Berichte
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Alle Fachbereiche, Kunden (Empfänger)
Vorbedingung: Daten vorhanden.
Fakt: FastReport-basierte Report-Engine mit Vorlagen, PDF-Export, Belegarchivierung und zentraler Reportverteilung ist implementiert.
Aussage: Alle Belege und Berichte sollen in anpassbarem Firmenlayout gedruckt, als PDF archiviert und zentral aktualisiert werden können.
Ergebnis: Einheitliches Schriftbild, archivierte Belege.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ReportEngine/FastReportHelper.cs; ReceiptBL.CreateFullReportForReceipt - Begründung: implementieren den Druck.
Prüfidee: Vorlage ändern; alle Folgedrucke nutzen neue Vorlage.
Tracelinks: SyRS-025
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Pflicht.
Status: belegt
```
```
ID: StRS-016
Titel: Betriebswirtschaftliche Transparenz
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsführung, Controlling
Vorbedingung: Bewegungsdaten vorhanden.
Fakt: Statistiken zu Umsatz, offenen Posten, Verträgen, Auslastung und MSP-Verbräuchen sind implementiert (Statistics).
Aussage: Die Geschäftsführung soll Umsätze, offene Posten, Vertragsbestand und Auslastung ohne Zusatzwerkzeuge auswerten können.
Ergebnis: Steuerungsfähige Kennzahlen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Statistics/Accounts/RevenueStatisticBL.cs - Begründung: implementiert Auswertungen.
Prüfidee: Umsatzstatistik gegen Belegsumme abstimmen.
Tracelinks: SyRS-021; SwRS-135
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Führungsinstrument.
Status: belegt
```
```
ID: StRS-017
Titel: Integrierte Kommunikation (E-Mail, Telefon, Chat)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Alle Mitarbeiter
Vorbedingung: Kommunikationskanäle konfiguriert.
Fakt: Exchange-Mail, Signaturen, Mail-Scanner, TAPI-Telefonie mit Anruferkennung und interner Chat sind implementiert.
Aussage: Kundenkommunikation soll im Vorgangskontext stattfinden: Mails und Anrufe werden automatisch Kunden/Tickets zugeordnet.
Ergebnis: Vollständige Kommunikationshistorie je Vorgang.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Mail/*, Tapi/PhoneCallBL.cs - Begründung: implementieren die Kanäle.
Prüfidee: Eingehende Mail/Anruf; erwartet: Kontextzuordnung.
Tracelinks: SyRS-035, SyRS-036, SyRS-030
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Effizienzkern.
Status: belegt
```
```
ID: StRS-018
Titel: Persönliche Arbeitsorganisation
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Alle Mitarbeiter
Vorbedingung: -
Fakt: Kalender, ToDos, MyDay, Dashboards, Benachrichtigungen und Terminanfragen sind implementiert.
Aussage: Jeder Mitarbeiter soll seinen Arbeitsvorrat (Termine, Aufgaben, Benachrichtigungen) an einem Ort sehen und steuern können.
Ergebnis: Weniger Übersehen von Fälligkeiten.
Belege:
- [PRIMÄR] src/backend/Centron.BL/MyDay/MyDayBL.cs - Begründung: implementiert die Tagesübersicht.
Prüfidee: Fällige Objekte erscheinen in MyDay.
Tracelinks: SyRS-029
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Produktivität.
Status: belegt
```
```
ID: StRS-019
Titel: Online-Self-Service für Endkunden
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Endkunde des Systemhauses
Vorbedingung: Web-Account existiert.
Fakt: Kundenportal mit Shop (Sonderpreise), Ticketeinsicht, Verträgen, Formularen, Dokumenten und Aktionslinks ist implementiert (Nexus WebCart, SelfCare, WebLinks).
Aussage: Endkunden sollen Bestellungen, Tickets, Verträge und Dokumente online einsehen und auslösen können - beschränkt auf die eigenen Daten.
Ergebnis: Entlastung des Supports, moderner Kundenzugang.
Belege:
- [PRIMÄR] src/nexus/CentronNexus/WebCart/*.razor - Begründung: implementiert das Portal.
Prüfidee: Web-Account sieht nur eigene Tickets/Verträge.
Tracelinks: SyRS-045, SyRS-002
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Zielbild SaaS.
Status: belegt
```
```
ID: StRS-020
Titel: Dokumentenverwaltung mit digitaler Unterschrift
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Alle Fachbereiche, Kunden
Vorbedingung: -
Fakt: Objektbezogene Verzeichnisse, PDF-Signatur, Online-Bestätigung von AVV/SEPA und Beleg-Signierprozess sind implementiert.
Aussage: Dokumente sollen objektbezogen abgelegt und Verträge/Belege digital unterschrieben werden können.
Ergebnis: Papierlose, nachweisbare Dokumentprozesse.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/FileManagement/DirectoryReferenceBL.cs, Security/PdfSigningBL.cs - Begründung: implementieren Ablage und Signatur.
Prüfidee: AVV online bestätigen; erwartet: signiertes Dokument am Kunden.
Tracelinks: SyRS-026, SyRS-022; SwRS-031, SwRS-107
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Digitalisierungskern.
Status: belegt
```
```
ID: StRS-021
Titel: Offenheit für Drittsysteme (Konnektoren)
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Systemhaus, Drittsysteme
Vorbedingung: Drittsystem im Einsatz.
Fakt: Konnektoren zu DocBee, docuFORM, Riverbird, CPra, Shopsystemen, TradePool sowie generische WebHooks und externe Objektreferenzen sind implementiert.
Aussage: Das System soll gängige Branchenwerkzeuge anbinden und Objekte beidseitig referenzieren können.
Ergebnis: Integrierbare Systemlandschaft.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs, DataExchange/Connectors/* - Begründung: implementieren die Offenheit.
Prüfidee: Fremd-ID an Objekt koppeln und rückwärts auflösen.
Tracelinks: SyRS-027; SwRS-083
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Ökosystem entscheidend.
Status: belegt
```
```
ID: StRS-022
Titel: Überblick über Kundengeräte und -infrastruktur
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Service, Vertrieb
Vorbedingung: Geräte beim Kunden im Einsatz.
Fakt: Kundengeräte werden in mehreren Modulen geführt (AccountDevices, CustomerAssets/Stammblätter, DocuBoard-Assets) inkl. Logs, Vertragsbezug und Outlook-Suche.
Aussage: Der Servicebetrieb soll jederzeit wissen, welche Geräte mit welchen Verträgen beim Kunden stehen.
Ergebnis: Asset-Transparenz für Service und Abrechnung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Devices/AccountDeviceBL.cs - Begründung: implementiert Geräteverwaltung.
Prüfidee: Gerät über alle Sichten konsistent auffinden.
Tracelinks: SyRS-028
Konsolidierung: Kandidat: drei Gerätedatenhaltungen (siehe SyRS-028) - im Zielsystem ein Asset-Konzept
Übernahmewürdigkeit: übernehmen - mit Konsolidierungsauflage.
Status: belegt
```
```
ID: StRS-023
Titel: Geordnete Reklamationsabwicklung (RMA)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Service, Kunde, Lieferant
Vorbedingung: Defektes Gerät wird gemeldet.
Fakt: RMA-Prozess mit Kundenrücknahme, Lieferantenweiterleitung, Versandarten und Artikelhistorie ist implementiert.
Aussage: Reklamationen sollen vom Kundeneingang bis zur Lieferantenabwicklung verfolgt werden.
Ergebnis: Kein Reklamationsverlust; Garantienachweis.
Belege:
- [PRIMÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs - Begründung: implementiert den Prozess.
Prüfidee: RMA-Kette Kunde→Lieferant→Rückläufer verfolgen.
Tracelinks: SyRS-028; SwRS-059
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Handelskern.
Status: belegt
```
```
ID: StRS-024
Titel: Auftragsbezogene Fertigung (Assemblierung)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Produktion/Technik
Vorbedingung: Fertigungsauftrag liegt vor.
Fakt: Fertigungsaufträge mit Positionen und Protokoll sowie ein Web-Produktionsmanagement sind implementiert (Production, Nexus/ProductionOrderManagement); Rechte für Stücklisten/Arbeitspläne existieren.
Aussage: Das Unternehmen soll kundenbezogene Fertigung (z. B. PC-/Server-Assemblierung) mit dokumentierten Arbeitsschritten abwickeln können.
Ergebnis: Nachvollziehbare Fertigung mit Seriennummernbezug.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs - Begründung: implementiert die Fertigung.
Prüfidee: Fertigungsauftrag mit Protokollschritten abschließen.
Tracelinks: SyRS-013; SwRS-089
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - sofern Geschäftsfeld bestätigt.
Status: belegt
```
```
ID: StRS-025
Titel: Projekt- und Chancenverfolgung (CRM)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Projektleitung
Vorbedingung: -
Fakt: Projekte, CRM-Projekte, Ticket-Projekte, Produktmatrix, Angebotsklassifikationen (Wahrscheinlichkeit/Produktgruppe) und Aktivitäten sind implementiert.
Aussage: Der Vertrieb soll Verkaufschancen und Projekte mit Wahrscheinlichkeiten und Produktpotenzialen je Kunde verfolgen können.
Ergebnis: Gefüllte, bewertbare Pipeline.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Offers/ClassificationProbabilityBL.cs, ProductMatrix/ProductMatrixBL.cs - Begründung: implementieren die Bewertung.
Prüfidee: Angebot mit Wahrscheinlichkeit klassifizieren; erscheint in Pipeline-Auswertung.
Tracelinks: SyRS-020; SwRS-088, SwRS-090, SwRS-119
Konsolidierung: Kandidat: drei Projektbegriffe (Projects, CrmProjects, TicketProjects) zusammenführen
Übernahmewürdigkeit: übernehmen - Vertriebssteuerung.
Status: belegt
```
```
ID: StRS-026
Titel: Zielgerichtetes Marketing (Kampagnen, Mailings, Telemarketing)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Marketing, Vertrieb
Vorbedingung: Zielgruppen definierbar.
Fakt: Kampagnen (Accounts/Campaigns), Serien-Mailings und Telemarketing-Aktionen sind implementiert.
Aussage: Das Unternehmen soll Zielgruppen ansprechen können (Mailing, Telefonaktion, Kampagne) und Reaktionen am Kunden dokumentieren.
Ergebnis: Messbare Marketingaktionen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Mailings/MailingDataBL.cs, Sales/Marketing/TelemarketingBL.cs - Begründung: implementieren die Aktionen.
Prüfidee: Mailing an Zielgruppe mit Antwortdokumentation.
Tracelinks: SyRS-035; SwRS-074, SwRS-103
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Basisumfang genügt ggf.
Status: belegt
```
```
ID: StRS-027
Titel: Schnelles Auffinden aller Informationen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Alle Benutzer
Vorbedingung: -
Fakt: Volltextsuche (Lucene) über Konten und Tickets sowie Suche über Zusatzfelder sind implementiert.
Aussage: Benutzer sollen Kunden und Vorgänge über eine zentrale Suche in Sekunden finden.
Ergebnis: Kurze Suchwege im Tagesgeschäft.
Belege:
- [PRIMÄR] src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs - Begründung: implementiert die Suche.
Prüfidee: Suche nach Ticketinhalt liefert Treffer < definierte Zeit.
Tracelinks: SyRS-033
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Nutzererwartung.
Status: belegt
```
```
ID: StRS-028
Titel: Sicherer Umgang mit Kundenzugangsdaten
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Techniker, Datenschutz
Vorbedingung: Zugangsdaten von Kundensystemen werden benötigt.
Fakt: Zwei Passwortverwaltungen mit Zugriffslogs, Siegeln, kundenbezogenen Rechten und Richtlinien sind implementiert.
Aussage: Zugangsdaten der Kundensysteme sollen verschlüsselt, feingranular berechtigt und mit lückenlosem Zugriffsnachweis verwaltet werden.
Ergebnis: Auditierbarer Passwortzugriff.
Belege:
- [PRIMÄR] src/backend/Centron.BL/PasswordManagementArea/PasswordManagementBL.cs, PasswordManager/PasswordManagerBL.cs - Begründung: implementieren die Verwaltung.
Prüfidee: Passwortzugriff hinterlässt Logeintrag; Siegelbruch sichtbar.
Tracelinks: SyRS-017; SwRS-085, SwRS-086, SwRS-026
Konsolidierung: Kandidat: zwei Passwortmodule vereinigen
Übernahmewürdigkeit: übernehmen - MSP-Vertrauensbasis.
Status: belegt
```
```
ID: StRS-029
Titel: KI-Unterstützung im Tagesgeschäft
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Support, Administration
Vorbedingung: KI-Dienst konfiguriert.
Fakt: Ticket-Zusammenfassungen, Lösungsvorschläge, Prompt-Verwaltung und Modellanbindung sind implementiert.
Aussage: Mitarbeiter sollen KI-Unterstützung (Zusammenfassungen, Vorschläge) direkt im Vorgang erhalten; das Unternehmen kontrolliert Modelle und Prompts.
Ergebnis: Zeitersparnis im Support.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/ArtificialIntelligence/ArtificialIntelligenceBL.cs - Begründung: implementiert die KI-Funktionen.
Prüfidee: Ticketzusammenfassung erzeugen und fachlich bewerten.
Tracelinks: SyRS-019
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Differenzierungsmerkmal.
Status: belegt
```
```
ID: StRS-030
Titel: Datenschutz und Nachvollziehbarkeit (DSGVO, Audit)
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Datenschutzbeauftragter, Geschäftsführung
Vorbedingung: -
Fakt: DSGVO-Löschung mit Protokoll, Änderungsmetadaten an allen Objekten, Rechte-/Zugriffs-/Beleglogs und transaktionale Speicherung sind implementiert.
Aussage: Das Unternehmen soll Betroffenenrechte (Löschung) erfüllen und jede relevante Änderung einem Verursacher zuordnen können.
Ergebnis: DSGVO-Konformität und Auditierbarkeit.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs; DBBaseBL.cs (Änderungsmetadaten) - Begründung: implementieren die Pflichten.
Prüfidee: Löschantrag ausführen; Protokoll weist Durchführung nach.
Tracelinks: SyRS-022, SyRS-009, SyRS-010
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - gesetzlich.
Status: belegt
```
```
ID: StRS-031
Titel: Automatisierter, wartbarer Systembetrieb
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit, Übertragbarkeit
Akteur: IT-Betrieb (Systemhaus), Hersteller
Vorbedingung: -
Fakt: Steuerbare Hintergrunddienste, Wartungsskripte, Container-Deployment, Installer, Testsuiten und Diagnosefunktionen sind implementiert.
Aussage: Das System soll automatisiert betrieben, aktualisiert und überwacht werden können, mit reproduzierbaren Deployments.
Ergebnis: Geringer Betriebsaufwand, sichere Updates.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/BackgroundServices/BackgroundServiceBL.cs; docker/compose/compose.yaml - Begründung: implementieren den Betrieb.
Prüfidee: Update-Durchlauf mit Skriptausführung und Regressionstests.
Tracelinks: SyRS-018, SyRS-047, SyRS-048, SyRS-049
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Basis der SaaS-Fähigkeit.
Status: belegt
```
```
ID: StRS-032
Titel: Anpassbarkeit ohne Programmierung
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit (Modifizierbarkeit)
Akteur: Administrator, Customizing
Vorbedingung: -
Fakt: Tausende Einstellungen (AppSettingsConst), Custom-Properties, Custom-Tables, konfigurierbare Menüs, Reportvorlagen und Rechtestrukturen sind implementiert.
Aussage: Das Systemhaus soll das System an eigene Prozesse anpassen können (Felder, Einstellungen, Menüs, Vorlagen), ohne Individualprogrammierung.
Ergebnis: Hohe Passgenauigkeit je Installation.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsBL.cs, Customization/ModuleCustomPropertyBL.cs - Begründung: implementieren die Anpassbarkeit.
Prüfidee: Prozessvariante rein per Konfiguration abbilden.
Tracelinks: SyRS-023
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Produkt-DNA; Wildwuchs im Zielsystem eindämmen.
Status: belegt
```
```
ID: StRS-033
Titel: Mehrfirmen- und Filialbetrieb
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Unternehmensgruppe, Filialen
Vorbedingung: Mehrere Firmen/Standorte.
Fakt: Mandanten, Filialen mit eigenen Nummernkreisen, Erlöskonten, filialbezogene Rechte und Belege sind implementiert.
Aussage: Unternehmensgruppen sollen mehrere Firmen und Standorte mit getrennten Nummernkreisen und Konten in einer Installation führen können.
Ergebnis: Konzernfähigkeit.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Company/MandatorBL.cs, BranchBL.cs - Begründung: implementieren die Struktur.
Prüfidee: Zwei Mandanten mit getrennten Rechnungskreisen betreiben.
Tracelinks: SyRS-024, SyRS-012
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - im SaaS als Mandantenmodell.
Status: belegt
```
@@ -0,0 +1,60 @@
# Traceability – c-entron ERP-Suite
Konsolidierte Traceability-Tabelle über die drei Ebenen (Forward: StRS → SyRS → SwRS; Backward über dieselben Spalten). Der Artefaktbeleg nennt den führenden Modulpfad; die vollständigen Belege stehen in den Einzelanforderungen.
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|---|---|---|---|
| StRS-012 | SyRS-001 | SwRS-001, SwRS-004, SwRS-014, SwRS-019, SwRS-020, SwRS-096 | src/backend/Centron.BL/Administration/Rights |
| StRS-019, StRS-012 | SyRS-002 | SwRS-001 | src/backend/Centron.BL/Administration/Rights |
| StRS-013, StRS-014 | SyRS-003 | SwRS-005, SwRS-009, SwRS-022, SwRS-028, SwRS-133, SwRS-139 | src/backend/Centron.BL/Administration/Logins; src/backend/Centron.BL/Administration/Licensing |
| StRS-013 | SyRS-004 | SwRS-002 | src/backend/Centron.BL/Administration/Logins |
| StRS-013 | SyRS-005 | SwRS-003, SwRS-011, SwRS-042, SwRS-144 | src/backend/Centron.BL/Administration/Logins |
| StRS-012, StRS-013 | SyRS-006 | - | src/backend/Centron.BL/Administration/Logins |
| StRS-012, StRS-013 | SyRS-007 | - | src/backend/Centron.BL/Administration/Logins |
| StRS-012 | SyRS-008 | SwRS-004, SwRS-008 | src/backend/Centron.BL/Administration/Rights |
| StRS-030 | SyRS-009 | SwRS-007, SwRS-137, SwRS-138 | src/backend/Centron.BL/ChangeTracking; src/backend/Centron.BL/Core |
| StRS-030 | SyRS-010 | SwRS-006, SwRS-111, SwRS-113, SwRS-137, SwRS-138 | src/backend/Centron.BL/Core |
| StRS-002, StRS-003 | SyRS-011 | SwRS-013, SwRS-018, SwRS-034, SwRS-051, SwRS-118, SwRS-140, SwRS-152, SwRS-154 | src/backend/Centron.BL/Sales/Receipts |
| StRS-003, StRS-012 | SyRS-012 | SwRS-010, SwRS-012, SwRS-016, SwRS-027 | src/backend/Centron.BL/Sales/Receipts; src/backend/Centron.BL/Administration/Mandatory |
| StRS-002, StRS-008, StRS-024 | SyRS-013 | SwRS-013, SwRS-014, SwRS-017, SwRS-071, SwRS-089, SwRS-112, SwRS-128 | src/backend/Centron.BL/Sales/Receipts; src/backend/Centron.BL/Warehousing |
| StRS-003 | SyRS-014 | SwRS-015, SwRS-154 | src/backend/Centron.BL/Sales/Receipts |
| StRS-002 | SyRS-015 | - | src/backend/Centron.BL/Sales/Receipts |
| StRS-002, StRS-030 | SyRS-016 | - | src/backend/Centron.BL/Sales/Receipts |
| StRS-013, StRS-028 | SyRS-017 | SwRS-021, SwRS-026, SwRS-085, SwRS-086, SwRS-101 | src/backend/Centron.BL/Administration/AccessTokens |
| StRS-031 | SyRS-018 | SwRS-024, SwRS-039, SwRS-062, SwRS-120 | src/backend/Centron.BL/Administration/BackgroundServices |
| StRS-029 | SyRS-019 | SwRS-023 | src/backend/Centron.BL/Administration/ArtificialIntelligence; src/backend/Centron.BL/ArtificialIntelligence |
| StRS-001, StRS-025 | SyRS-020 | SwRS-019, SwRS-020, SwRS-032, SwRS-061, SwRS-088, SwRS-090, SwRS-102, SwRS-103, SwRS-124, SwRS-152 | src/backend/Centron.BL/Accounts |
| StRS-030 | SyRS-022 | SwRS-030, SwRS-031 | src/backend/Centron.BL/Administration/DataSecurity |
| StRS-032 | SyRS-023 | SwRS-029, SwRS-033, SwRS-035, SwRS-036, SwRS-039, SwRS-040, SwRS-041, SwRS-042, SwRS-053, SwRS-064, SwRS-117, SwRS-122, SwRS-126 | src/backend/Centron.BL/Administration/Settings |
| StRS-033 | SyRS-024 | SwRS-027 | src/backend/Centron.BL/Administration/Company, .../CompanyInformations; src/backend/Centron.BL/Administration/Mandatory |
| StRS-009, StRS-016 | SyRS-021 | SwRS-025, SwRS-057, SwRS-058, SwRS-135, SwRS-141, SwRS-155 | src/backend/Centron.BL/DataExchange |
| StRS-015 | SyRS-025 | SwRS-038, SwRS-099, SwRS-107, SwRS-118, SwRS-132 | src/backend/Centron.BL/ReportEngine; src/backend/Centron.BL/Reporting |
| StRS-020 | SyRS-026 | SwRS-044, SwRS-056, SwRS-105, SwRS-125 | src/backend/Centron.BL/Administration/Documents, .../FileManagement |
| StRS-010, StRS-007, StRS-021 | SyRS-027 | SwRS-045, SwRS-052, SwRS-060, SwRS-063, SwRS-067, SwRS-069, SwRS-083, SwRS-091, SwRS-101, SwRS-123, SwRS-141, SwRS-148, SwRS-150 | src/backend/Centron.BL/EDI |
| StRS-022, StRS-023 | SyRS-028 | SwRS-054, SwRS-055, SwRS-059 | src/backend/Centron.BL/Devices; src/backend/Centron.BL/DocuBoard; src/backend/Centron.BL/Sales/CustomerAssets |
| StRS-018 | SyRS-029 | SwRS-043, SwRS-046, SwRS-049, SwRS-050, SwRS-070, SwRS-078, SwRS-079, SwRS-082, SwRS-104, SwRS-110, SwRS-116, SwRS-121, SwRS-157, SwRS-158 | src/backend/Centron.BL/Calendar; src/backend/Centron.BL/MyCentron; src/backend/Centron.BL/MyDay; src/backend/Centron.BL/ToDoArea |
| StRS-017 | SyRS-030 | SwRS-037, SwRS-115, SwRS-158 | src/backend/Centron.BL/Tapi; src/backend/Centron.BL/Administration/PhoneSettings |
| StRS-019 | SyRS-031 | SwRS-047, SwRS-048, SwRS-076, SwRS-077, SwRS-080, SwRS-081, SwRS-084, SwRS-108, SwRS-129, SwRS-130, SwRS-131, SwRS-134, SwRS-136, SwRS-142, SwRS-143, SwRS-145, SwRS-146, SwRS-147 | src/centron/Centron.WPF.UI, .../Centron.WPF.UI.Extension; src/nexus/CentronNexus; src/webservice/Centron.Controllers |
| StRS-009 | SyRS-032 | SwRS-065, SwRS-066, SwRS-135, SwRS-149, SwRS-155 | src/backend/Centron.BL/Finances |
| StRS-027 | SyRS-033 | SwRS-068 | src/backend/Centron.BL/IndexSearch |
| StRS-008 | SyRS-034 | SwRS-075 | src/backend/Centron.BL/MassUpdate |
| StRS-017, StRS-026 | SyRS-035 | SwRS-072, SwRS-074, SwRS-157 | src/backend/Centron.BL/Mail |
| StRS-017, StRS-005 | SyRS-036 | SwRS-073, SwRS-087, SwRS-109 | src/backend/Centron.BL/MailScanner |
| StRS-004 | SyRS-037 | SwRS-092, SwRS-093 | src/backend/Centron.BL/Sales/CustomerAssets |
| StRS-004, StRS-003 | SyRS-038 | SwRS-093, SwRS-094, SwRS-150 | src/backend/Centron.BL/Sales/CustomerAssets |
| StRS-006, StRS-005 | SyRS-039 | SwRS-095, SwRS-106 | src/backend/Centron.BL/Sales/CustomerAssets; src/backend/Centron.BL/Sales/Support |
| StRS-005, StRS-012 | SyRS-040 | SwRS-096, SwRS-097, SwRS-099, SwRS-114, SwRS-119 | src/backend/Centron.BL/Sales/Support |
| StRS-005 | SyRS-041 | SwRS-098 | src/backend/Centron.BL/Sales/Support |
| StRS-003, StRS-009 | SyRS-042 | SwRS-100, SwRS-127 | src/backend/Centron.BL/Sales/CashBooks |
| StRS-010, StRS-003 | SyRS-043 | SwRS-141 | src/backend/Centron.BL/DataExchange; src/backend/Centron.BL/ReportEngine; src/backend/Centron.Gateway; src/apis/Centron.Api.EbInterface |
| StRS-011 | SyRS-044 | SwRS-151 | src/apis/Centron.Api.Gls; src/apis/Centron.Api.Shipcloud |
| StRS-019 | SyRS-045 | SwRS-145, SwRS-156 | src/nexus/CentronNexus |
| StRS-013, StRS-012 | SyRS-046 | SwRS-136, SwRS-147 | src/webservice/Centron.Controllers |
| StRS-031 | SyRS-047 | SwRS-146, SwRS-153 | docker |
| StRS-031 | SyRS-048 | SwRS-153 | deployment; scripts |
| StRS-031 | SyRS-049 | SwRS-153 | tests; docker |
| StRS-009, StRS-003 | SyRS-050 | - | src/backend/Centron.BL/Administration/Settings; src/backend/Centron.BL/Finances |
**SwRS ohne SyRS-Referenz:** keine – jede SwRS-Anforderung referenziert mindestens eine SyRS-Anforderung.
**StRS ohne referenzierende SyRS-Anforderung:** keine – jede StRS-Anforderung wird von mindestens einer SyRS-Anforderung referenziert.
@@ -0,0 +1,197 @@
# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
## Lauf
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
- **Startzeit:** 2026-08-27T00:24:41.6237308+02:00
- **Endzeit:** 2026-08-27T07:28:28.0825221+02:00
- **Dauer gesamt:** 7:03:46 (`duration_ms` 7:03:44; API: 7:01:25)
— **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
## Werkzeugkonfiguration
- **Skill-Version:** 7.0.0
- **Claude-Code-Version:** 2.1.246
- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
- **Modell (angefordert):** `claude-fable-5`
- **Modelle (tatsächlich eingesetzt):** `claude-fable-5` 30.635.548 Tokens (99.98 %), `claude-haiku-4-5-20251001` 6.969 Tokens (0.02 %)
- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
- **Effort:** `high` (per `--effort high` gesetzt)
- **Laufverzeichnis-ID:** `v7.0.0-35a4`
- **Ablage:** `Iteration 3/claude-fable-5/solo/high/`
- **Parallele Läufe:** nein – die Zeitangaben sind für Laufzeitvergleiche verwendbar
- **Agentenmodus:** `solo` (V1)
- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
- **Permission-Mode:** `acceptEdits`
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
`--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos) **zuzüglich** `Task`, `Agent`, `Workflow` aus dem Modus `solo`
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
- **Subagenten:** keine (`spawned` = 0, `by_type` leer)
- **Verschachtelung:** `spawned` = 0, davon `spawned_by_subagents` = 0, `max_depth` = 0. Keine tieferen Ebenen, `_meta\subagenten.md` entfällt.
## Validierungsstichprobe
- **Größe:** noch nicht festgelegt
- **Ziehungsverfahren:** noch nicht festgelegt
- **Validatoren:** noch nicht festgelegt
- **Stand:** noch nicht gezogen
## Verbrauch
### Hauptagent (`usage`)
| Messgröße | Wert |
|---|---:|
| Input-Tokens | 246 |
| Output-Tokens | 280.683 (davon 40.204 Thinking-Tokens) |
| Cache-Write-Tokens | 816.487 |
| Cache-Read-Tokens | 28.808.092 |
| Agent-Turns | 139 |
### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
| Messgröße | `claude-fable-5` | `claude-haiku-4-5-20251001` | Summe |
|---|---:|---:|---:|
| Input-Tokens | 250 | 6.945 | 7.195 |
| Output-Tokens | 281.133 | 24 | 281.157 |
| Cache-Write-Tokens | 1.178.596 | 0 | 1.178.596 |
| Cache-Read-Tokens | 29.175.569 | 0 | 29.175.569 |
| **Tokens gesamt** | **30.635.548** | **6.969** | **30.642.517** |
**Tokens gesamt: 30.642.517** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
Da im Modus `solo` keine Subagenten laufen, sind `usage` und `modelUsage` für das Hauptmodell
deckungsgleich; die Differenz zur Summe stammt allein aus den Haiku-Hilfsaufrufen.
## 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 | 33 | 13,7 % |
| SyRS | 50 | 20,7 % |
| SwRS | 158 | 65,6 % |
| **Gesamt** | **241** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 133 | 55,2 % |
| Sicherheit | 32 | 13,3 % |
| Schnittstelle | 25 | 10,4 % |
| funktional (Abrechnung) | 19 | 7,9 % |
| nicht-funktional | 16 | 6,6 % |
| Daten | 12 | 5,0 % |
| Schnittstelle (Abrechnung) | 2 | 0,8 % |
| funktional (Abrechnung/Fakturierung) | 1 | 0,4 % |
| Sicherheit (Abrechnung) | 1 | 0,4 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 283 |
| davon `PRIMÄR` | 252 (89,0 %) |
| davon `SEKUNDÄR` | 18 (6,4 %) |
| davon `KONTEXT` | 13 (4,6 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 237 (98,3 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 218 | 90,5 % |
| workaround | 9 | 3,7 % |
| sonderfall | 7 | 2,9 % |
| veraltet | 7 | 2,9 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 235 | 97,5 % |
| als `HYPOTHESE` gekennzeichnet | 6 | 2,5 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 41 | 17,0 % |
| mit ISO-25010-Qualitätsmerkmal | 16 | 6,6 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (74 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 241 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 241 von 241 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
- **Session-ID:** `03603a98-feb4-43f9-8f8c-1621115f6c38`
- **Permission-Denials:** 2 (2 × `Bash`) – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – Bedingung `solo` eingehalten
- **Subagenten-Prompts:** entfällt (Modus `solo`)
- **Erzeugte Dateien:** 7 Dateien in `Ergebnisse\`:
| Datei | Größe |
|---|---:|
| `Analysebericht.md` | 43.009 B |
| `Glossar.md` | 4.881 B |
| `Hypothesen.md` | 2.131 B |
| `StRS.md` | 33.169 B |
| `SwRS.md` | 201.104 B |
| `SyRS.md` | 83.391 B |
| `Traceability.md` | 6.885 B |
- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
## Anmerkungen/Auffälligkeiten
**1. Neue Zelle: `claude-fable-5` / `solo` / `high`.** Erster gültiger Lauf dieser Kombination;
der vorausgegangene Versuch `195958_v7.0.0-77a1` scheiterte am Session-Kontingent.
**2. Die Modellkontrolle ist sauber – und grenzt den Fable-Befund ein.** `modelUsage` weist
ausschließlich `claude-fable-5` plus Haiku-Hilfsaufrufe aus. Im Modus `builtin` war bei Fable
zweimal `claude-opus-5[1m]` aufgetreten, zuletzt im Lauf `d694` desselben Blocks. Damit steht
fest: **Nicht Fable ist das Problem, sondern Fable in Kombination mit Delegation.** Ohne
Subagenten wird das angeforderte Modell eingehalten.
**3. Zweithöchster `PRIMÄR`-Anteil der Reihe: 89,0 %** von 283 Belegen, 98,3 % der Anforderungen
mit mindestens einem Primärbeleg – bei nur 30,6 Mio. Tokens. Das günstigste Modell liefert hier
die sauberste Belegarbeit.
**4. Vollständig regelkonform:** alle fünf Prüfkriterien erfüllt, einschließlich der
risikobasierten Priorisierung (74 risikorelevante Anforderungen, alle gedeckt) und Tracelinks bei
100 %. Das gelang sonst nur `f631`, `2316`, `b652` und den drei `max`-Läufen.
**5. Belegdichte Median 1,0** – Fable schreibt einen Beleg je Anforderung. Zusammen mit Opus
(2,0 auf `high`) und Sonnet (1,0) stützt das den Befund aus Punkt 2 des Laufs `2269`: Die
Belegdichte folgt dem Modell.
**6. Die Wanduhrzeit von 7:03:44 ist unbrauchbar – aus einem neuen Grund.** Nicht Parallelbetrieb,
sondern **Kontingent-Wartezeiten**: Zwischen den Werkzeugaufrufen lagen Lücken von 4:00 h
(23:08 → 03:08) und zweimal rund 2 h. Die CLI bricht bei erschöpftem Kontingent nicht ab, sondern
wartet auf das nächste Reset-Fenster. `duration_ms` bildet diese Wartezeit mit ab. Damit ist ein
dritter Verzerrungsmechanismus der Zeitmessung dokumentiert, neben Parallelbetrieb und Abbruch.
Tokenverbrauch, Anforderungszahl und Belegkennzahlen sind davon **nicht** betroffen.
**7. Zwei Permission-Denials**, keiner auf `Task`/`Agent`/`Workflow`. `spawned` = 0.
@@ -0,0 +1,242 @@
ReqID Titel Ebene Module Trace Risiko PRIMAER Status Konsolidierung
SyRS-001 Gruppenbasierte Benutzerrechtepruefung SyRS M-024 StRS-012 J J belegt Kandidat:SyRS-002
SyRS-002 Getrenntes Rechtemodell fuer Web-Accounts SyRS M-024 StRS-019,StRS-012 J J belegt Kandidat:SyRS-001
SyRS-003 Ticketbasierte Sitzungen mit Lizenzpruefung SyRS M-017,M-016 StRS-013,StRS-014 J J belegt nein
SyRS-004 Mehrere Authentifizierungsverfahren SyRS M-017 StRS-013 J J belegt nein
SyRS-005 Zwei-Faktor-Authentifizierung SyRS M-017 StRS-013 J J belegt Kandidat:SwRS-011
SyRS-006 Zeitgesteuerte Kontodeaktivierung SyRS M-017 StRS-012,StRS-013 J J belegt nein
SyRS-007 Anwendungsbezogene Anmelderechte SyRS M-017 StRS-012,StRS-013 J J belegt nein
SyRS-008 Standard-Rechtegruppen SyRS M-024 StRS-012 J J belegt nein
SyRS-009 Aenderungsnachverfolgung SyRS M-036,M-039 StRS-030 N J belegt nein
SyRS-010 Transaktionale Speicherung SyRS M-039 StRS-030 N J belegt nein
SwRS-001 Rechteermittlung SQL+Cache SwRS M-024 SyRS-001,SyRS-002 J J belegt nein
SwRS-002 Passwort SHA1 ungesalzen SwRS M-017 SyRS-004 J J belegt nein
SwRS-003 2FA-Validatorwahl SwRS M-017 SyRS-005 J J belegt nein
SwRS-004 Rechtegruppenverwaltung SwRS M-024 SyRS-001,SyRS-008 J J belegt nein
SwRS-005 Ticket-Wiederverwendung+LoginIP SwRS M-017 SyRS-003 J J belegt nein
SwRS-006 Speicher-Template Hooks SwRS M-039 SyRS-010 N J belegt nein
SwRS-007 Erstellungs-/Aenderungsmetadaten SwRS M-036,M-039 SyRS-009 N J belegt nein
SwRS-008 Standardrechtegruppen aus Ressource SwRS M-024 SyRS-008 J J belegt nein
SwRS-009 Signaturvalidierte Lizenzdatei SwRS M-016 SyRS-003 J J belegt nein
SyRS-011 Belegkette Weiterfuehrungswege SyRS M-083 StRS-002,StRS-003 J J belegt Kandidat:CustomerAssets-Modell
SyRS-012 Nummernkreise je Mandant/Filiale SyRS M-083,M-018 StRS-003,StRS-012 J J belegt nein
SyRS-013 Bestandswirkung der Belege SyRS M-083,M-115 StRS-002,StRS-008,StRS-024 J J belegt nein
SyRS-014 Mindestpreisschutz SyRS M-083 StRS-003 J J belegt nein
SyRS-015 Belegsperren+Concurrency SyRS M-083 StRS-002 N J belegt nein
SyRS-016 Belegversionierung SyRS M-083 StRS-002,StRS-030 N J belegt nein
SwRS-010 Belegnummernvergabe+Templatekunde SwRS M-083 SyRS-012 J J belegt nein
SwRS-011 TOTP-Zweitfaktor SwRS M-111 SyRS-005 J J belegt Kandidat:SyRS-005
SwRS-012 Nummernkreis-Kaskade SwRS M-018 SyRS-012 J J belegt nein
SwRS-013 IReceiptSpecificLogic-Strategie SwRS M-083 SyRS-011,SyRS-013 N J belegt nein
SwRS-014 Negativbuchung nur mit Recht SwRS M-083,M-115 SyRS-013,SyRS-001 J J belegt nein
SwRS-015 Mindestpreis-Reauth SwRS M-083 SyRS-014 J J belegt nein
SwRS-016 Filialzuordnung BranchOrigin SwRS M-083 SyRS-012 N J belegt nein
SwRS-017 Seriennummern-Vollstaendigkeit SwRS M-083 SyRS-013 N J belegt nein
SwRS-018 Firmengruppen-Belegeinstellungen SwRS M-083 SyRS-011 N J belegt nein
SyRS-017 API-Zugriffstokens SyRS M-003 StRS-013,StRS-028 J J belegt nein
SyRS-018 Steuerbare Hintergrunddienste SyRS M-006 StRS-031 N J belegt nein
SyRS-019 KI-Assistenz konfigurierbar SyRS M-005,M-030 StRS-029 N J belegt nein
SwRS-019 Bankverbindungen Rechte+Default SwRS M-001 SyRS-001,SyRS-020 J J belegt nein
SwRS-020 Kontenstamm Rechte+FiBu-Nummer SwRS M-002 SyRS-001,SyRS-020 J J belegt nein
SwRS-021 API-Token Hash+Ablauf+Log SwRS M-003 SyRS-017 J J belegt nein
SwRS-022 Client-Version je Anmeldung SwRS M-004 SyRS-003 N J belegt nein
SwRS-023 KI-Prompts+verschluesselte Keys SwRS M-005 SyRS-019 N J belegt nein
SwRS-024 Hintergrunddienst-Zustand SwRS M-006 SyRS-018 N J belegt nein
SwRS-025 Kontenrahmenverwaltung SwRS M-007 SyRS-021 N J belegt nein
SwRS-026 Konfig-DB Masterkey SwRS M-008 SyRS-017,StRS-028 J J belegt Kandidat:SwRS-023
SyRS-020 Konten-/Adressstamm SyRS M-002 StRS-001,StRS-025 N J belegt nein
SyRS-022 DSGVO Loeschkonzept SyRS M-012 StRS-030 J J belegt nein
SyRS-023 Zentrale Konfiguration SyRS M-026 StRS-032 N J belegt nein
SyRS-024 Mandanten-/Filialstruktur SyRS M-009,M-018 StRS-033 N J belegt nein
SwRS-027 Kollisionssichere Nummernvergabe SwRS M-009 SyRS-012,SyRS-024 J J belegt nein
SwRS-028 Verbindungsverwaltung SwRS M-010 SyRS-003 N J belegt nein
SwRS-029 Custom Properties je Modul SwRS M-011 SyRS-023 N J belegt Kandidat:M-043
SwRS-030 DSGVO-Kontaktloeschung SwRS M-012 SyRS-022 J J belegt nein
SwRS-031 Online-AVV/SEPA-Dokumente SwRS M-013 SyRS-022,StRS-020 N J belegt Kandidat:Nexus-Signierung
SwRS-032 Mitarbeiter Abteilungen/Skills SwRS M-014 SyRS-020,StRS-012 N J belegt nein
SwRS-033 DB-Umgebungspruefungen SwRS M-015 SyRS-023 N J belegt nein
SwRS-034 Konditionen-Stammdaten SwRS M-019 SyRS-011 N J belegt nein
SwRS-035 Netzwerkdiagnose SwRS M-020 SyRS-023 N J belegt nein
SwRS-036 Performance-Messungen SwRS M-021 SyRS-023 N J belegt nein
SwRS-037 Telefonie-Einstellungen SwRS M-022 SyRS-030 N J belegt nein
SwRS-038 Portal Statuspruefung/Reportupload SwRS M-023 SyRS-025 N J belegt nein
SwRS-039 Wartungsskripte+SQL-Management SwRS M-025 SyRS-023,SyRS-018 N J belegt nein
SwRS-040 Typisierter Einstellungszugriff SwRS M-026 SyRS-023 N J belegt nein
SwRS-041 UI-Themes SwRS M-027 SyRS-023 N J belegt nein
SwRS-042 Webservice-Konfigurationsdatei SwRS M-028 SyRS-023,SyRS-005 N J belegt nein
SyRS-021 FiBu-Uebergabe DATEV SyRS M-044 StRS-009,StRS-016 J J belegt nein
SwRS-043 Terminanfragen SwRS M-029 SyRS-029,StRS-018 N J belegt nein
SwRS-044 Lieferantenbeleg-Ablage SwRS M-031 SyRS-026 N J belegt nein
SwRS-045 Distributoren auto-anlegen SwRS M-032 SyRS-027 N J belegt nein
SwRS-046 Kalender-Einstellungen SwRS M-033 SyRS-029,StRS-018 N J belegt nein
SwRS-047 Icon-Verwaltung SwRS M-034 SyRS-031 N J belegt nein
SwRS-048 Nexus-Einstellungen SwRS M-035 SyRS-031 N J belegt nein
SwRS-049 Chat SwRS M-037 SyRS-029,StRS-017 N J belegt nein
SwRS-050 Checklisten SwRS M-038 SyRS-029 N J belegt nein
SwRS-051 Laender/Waehrungen SwRS M-040 SyRS-011,StRS-001 N J belegt nein
SwRS-052 CPra-Konnektor SwRS M-041 SyRS-027 N J belegt nein
SwRS-053 Custom Tables SwRS M-043 SyRS-023 N J belegt Kandidat:SwRS-029
SwRS-054 AccountDevices SwRS M-045 SyRS-028,StRS-022 N J belegt Kandidat:Assets
SwRS-055 AssetManagement DocuBoard SwRS M-046 SyRS-028,StRS-022 N J belegt Kandidat:SwRS-054
SwRS-056 Dokumentationen SwRS M-047 SyRS-026,StRS-020 N J belegt nein
SwRS-057 FiBu-Exportkonfigurationen SwRS M-044 SyRS-021 J J belegt nein
SwRS-058 Doppeluebergabeschutz FiBu SwRS M-044 SyRS-021 J J belegt nein
SyRS-025 Report-Engine Belegdruck SyRS M-080,M-081 StRS-015 N J belegt nein
SyRS-026 Dokumenten-/Verzeichnisverwaltung SyRS M-013 StRS-020 N J belegt nein
SyRS-027 EDI-Bestelluebertragung SyRS M-048 StRS-010,StRS-007,StRS-021 N J belegt Kandidat:Gateway-EDI
SyRS-028 Kundengeraete/Assets SyRS M-045,M-046,M-084 StRS-022,StRS-023 N J belegt Kandidat:3 Datenhaltungen
SyRS-029 Organisation+Zusammenarbeit SyRS M-033,M-066,M-067,M-107 StRS-018 N J belegt nein
SyRS-030 TAPI-Telefonie SyRS M-101,M-022 StRS-017 N J belegt nein
SyRS-031 Mehrkanal-Clients SyRS M-127,M-130,M-133 StRS-019 N J belegt Kandidat:Doppel-UI
SyRS-032 Onlinebanking-Zahlungsabgleich SyRS M-053 StRS-009 J J belegt nein
SyRS-033 Volltextsuche SyRS M-056 StRS-027 N J belegt nein
SyRS-034 Massenaenderungen SyRS M-063 StRS-008 N J belegt nein
SyRS-035 E-Mail/Exchange SyRS M-060 StRS-017,StRS-026 N J belegt nein
SyRS-036 Mail-Scanner SyRS M-061 StRS-017,StRS-005 N J belegt Kandidat:Workflows
SwRS-059 RMA-Abwicklung SwRS M-042 SyRS-028,StRS-023 N J belegt nein
SwRS-060 EDI-Bestellerzeugung SwRS M-048 SyRS-027 N J belegt nein
SwRS-061 Mitarbeiterstatus/Dispatcher SwRS M-049 SyRS-020,StRS-012 N J belegt nein
SwRS-062 ExpectedEvents SwRS M-050 SyRS-018,StRS-031 N J belegt nein
SwRS-063 Externe Helpdesk-Konfiguration SwRS M-051 SyRS-027,StRS-005 N J belegt Kandidat:DocBee
SwRS-064 Externe Tools SwRS M-052 SyRS-023 N J belegt nein
SwRS-065 Zahlungseingangsprotokoll SwRS M-053 SyRS-032 J J belegt nein
SwRS-066 Bankumsatz-Zuordnung/Buchung SwRS M-053 SyRS-032 J J belegt nein
SwRS-067 CustomGateway Sonderartikel SwRS M-054 SyRS-027,StRS-004 N J belegt nein
SwRS-068 Lucene-Index inkrementell SwRS M-056 SyRS-033 N J belegt nein
SwRS-069 Shop-Integration ExternalId SwRS M-057 SyRS-027,StRS-019 N J belegt nein
SwRS-070 ItPlanner Kategorien SwRS M-058 SyRS-029 N J belegt nein
SwRS-071 Lagerorte+Umbuchungslog SwRS M-059 SyRS-013,StRS-008 N J belegt nein
SwRS-072 Signaturen+Blacklist SwRS M-060 SyRS-035 N J belegt nein
SwRS-073 MailScanner-Konfiguration SwRS M-061 SyRS-036 N J belegt nein
SwRS-074 Serien-Mailings SwRS M-062 SyRS-035,StRS-026 N J belegt nein
SwRS-075 Massenpreisaenderungen SwRS M-063 SyRS-034 N J belegt nein
SwRS-076 Mobile Mitarbeiterliste SwRS M-064 SyRS-031 N J belegt nein
SwRS-077 Modulkatalog+Favoriten SwRS M-065 SyRS-031,StRS-014 N J belegt nein
SwRS-078 Dashboards SwRS M-066 SyRS-029 N J belegt nein
SwRS-079 MyDay Arbeitsvorrat SwRS M-067 SyRS-029 N J belegt nein
SwRS-080 Nexus-Benachrichtigungen SwRS M-068 SyRS-031,StRS-018 N J belegt Kandidat:M-070
SwRS-081 Ticket-Ansichten Nexus SwRS M-069 SyRS-031,StRS-005 N J belegt nein
SwRS-082 Objekt-Benachrichtigungsempfaenger SwRS M-070 SyRS-029 N J belegt Kandidat:SwRS-080
SwRS-083 Externe Objektreferenzen SwRS M-071 SyRS-027 N J belegt nein
SwRS-084 Outlook-Assetsuche SwRS M-072 SyRS-031,StRS-022 N J belegt nein
SwRS-085 Kundenzugangsdaten+Logs SwRS M-073 SyRS-017,StRS-028 J J belegt Kandidat:M-074
SwRS-086 Passwortmanager Siegel SwRS M-074 SyRS-017,StRS-028 J J belegt Kandidat:SwRS-085
SwRS-087 Prozesse Schritte/Bindungen SwRS M-075 SyRS-036,StRS-031 N J belegt Kandidat:Workflows
SwRS-088 Produktmatrix SwRS M-076 SyRS-020,StRS-025 N J belegt nein
SwRS-089 Fertigungsauftraege SwRS M-077 SyRS-013,StRS-024 N J belegt nein
SwRS-090 Projektliste SwRS M-078 SyRS-020,StRS-025 N J belegt Kandidat:Projektbegriffe
SwRS-091 Bestellvorschlaege SwRS M-079 SyRS-027,StRS-007 N J belegt nein
SyRS-037 Vertragsverwaltung Laufzeit/Intervalle SyRS M-084 StRS-004 J J belegt nein
SyRS-038 Automatische Vertragsfakturierung SyRS M-084 StRS-004,StRS-003 J J belegt nein
SyRS-039 Timer-Billing SyRS M-084,M-086 StRS-006,StRS-005 J J belegt nein
SyRS-040 Helpdesk Rechte+Status SyRS M-086 StRS-005,StRS-012 J J belegt nein
SyRS-041 Ticket-Eskalation SyRS M-086 StRS-005 N J belegt nein
SyRS-042 Kassenbuch SyRS M-087 StRS-003,StRS-009 J J belegt nein
SwRS-092 Vertrags-Datumsarithmetik SwRS M-084 SyRS-037 J J belegt nein
SwRS-093 Auto-Vertragsschliessen SwRS M-084 SyRS-037,SyRS-038 J J belegt nein
SwRS-094 Abrechnungsfaellige Kunden+Zaehler SwRS M-084 SyRS-038 J J belegt nein
SwRS-095 Timer-Belegerzeugung SwRS M-084,M-086 SyRS-039 J J belegt nein
SwRS-096 Ticket-Rechtepruefung Save SwRS M-086 SyRS-040,SyRS-001 J J belegt nein
SwRS-097 Ticket-Sichtbarkeit restriktiv SwRS M-086 SyRS-040 J J belegt nein
SwRS-098 Eskalationslauf SwRS M-086 SyRS-041 N J belegt nein
SwRS-099 Ticketabschluss+Benachrichtigung SwRS M-086 SyRS-040,SyRS-025 N J belegt nein
SwRS-100 Kassenbuchbuchung SwRS M-087 SyRS-042 J J belegt nein
SwRS-101 Riverbird-Ticketvalidierung SwRS M-082 SyRS-017,SyRS-027 J J belegt nein
SwRS-102 Kundensuche Kompakt SwRS M-085 SyRS-020 N J belegt nein
SwRS-103 Telemarketing SwRS M-088 SyRS-020,StRS-026 N J belegt nein
SwRS-104 Terminverwaltung Schedule SwRS M-089 SyRS-029 N J belegt Kandidat:M-033
SwRS-105 Dokuwizard Infrastruktur SwRS M-090 SyRS-026,StRS-020 N J belegt Kandidat:M-047
SwRS-106 Stundenzuschlagssaetze SwRS M-091 SyRS-039 J J belegt nein
SwRS-107 PDF-Signatur SwRS M-092 SyRS-025,StRS-020 J J belegt nein
SwRS-108 SelfCare-Formulare SwRS M-093 SyRS-031,StRS-019 N J belegt Kandidat:WebHDQuestion
SwRS-109 Workflow-Prozesse SwRS M-094 SyRS-036,StRS-031 N J belegt Kandidat:SwRS-087
SwRS-110 Social-Media-Feed SwRS M-095 SyRS-029 N J belegt nein
SwRS-111 Start Mapping/Verbindung SwRS M-096 SyRS-010 N J belegt nein
SwRS-112 Inventur SwRS M-098 SyRS-013,StRS-008 J J belegt nein
SwRS-113 I3D-Systemtabelle SwRS M-099 SyRS-010 N J belegt nein
SwRS-114 Tags SwRS M-100 SyRS-040 N J belegt nein
SwRS-115 Anruferkennung SwRS M-101 SyRS-030 N J belegt nein
SwRS-116 TaskManager Handler SwRS M-102 SyRS-029,StRS-031 N J belegt Kandidat:M-107
SwRS-117 Telemetrie SwRS M-103 SyRS-023 N J belegt nein
SwRS-118 Textbausteine SwRS M-104 SyRS-025,SyRS-011 N J belegt nein
SwRS-119 Ticket-Projekte SwRS M-105 SyRS-040,StRS-025 N J belegt Kandidat:SwRS-090
SwRS-120 TimingSettings SwRS M-106 SyRS-018 N J belegt nein
SwRS-121 Objekt-ToDos SwRS M-107 SyRS-029 N J belegt Kandidat:SwRS-116
SwRS-122 Textformat-Konvertierung SwRS M-108 SyRS-023 N J belegt nein
SwRS-123 TradePool-Import SwRS M-109 SyRS-027 N J belegt nein
SwRS-124 Transaktionsobjekte SwRS M-110 SyRS-020 N J belegt nein
SwRS-125 SimpleUrls SwRS M-112 SyRS-026 N J belegt nein
SwRS-126 Videoportal-Zuordnung SwRS M-113 SyRS-023 N J belegt nein
SwRS-127 Gutscheinverwaltung SwRS M-114 SyRS-042 J J belegt nein
SwRS-128 Artikelstamm Systemartikel SwRS M-115 SyRS-013,StRS-008 N J belegt nein
SwRS-129 Aktions-Weblinks SwRS M-116 SyRS-031,StRS-019 N J belegt nein
SwRS-130 Webmenue-Konfiguration SwRS M-118 SyRS-031 N J belegt nein
SwRS-131 Webservice-Version SwRS M-119 SyRS-031 N J belegt nein
SwRS-132 PDF-Merge SwRS M-120 SyRS-025 N J belegt nein
SwRS-133 Typisierte Exceptions SwRS M-121 SyRS-003 N J belegt nein
SyRS-043 E-Rechnungsformate SyRS M-044,M-080,M-126,M-137 StRS-010,StRS-003 J J belegt nein
SyRS-044 Versanddienstleister SyRS M-138,M-139 StRS-011 N J belegt Kandidat:GLS-vs-Shipcloud
SyRS-045 Kundenportal Nexus SyRS M-130 StRS-019 N J belegt Kandidat:SelfCare
SyRS-046 REST-API Rechteautorisierung SyRS M-133 StRS-013,StRS-012 J J belegt nein
SyRS-047 Container-Betrieb SyRS M-148 StRS-031 N J belegt nein
SyRS-048 Windows-Installer SyRS M-147,M-149 StRS-031 N J belegt nein
SyRS-049 Testabdeckung SyRS M-151,M-148 StRS-031 N J belegt nein
SwRS-134 Grid-/UI-Profile SwRS M-055 SyRS-031 N J belegt nein
SwRS-135 Statistiken SwRS M-097 SyRS-021,SyRS-032,StRS-016 N J belegt nein
SwRS-136 Webservice-Fassaden SwRS M-117 SyRS-031,SyRS-046 N J belegt Kandidat:Doppel-BL
SwRS-137 DAO Event-Listener SwRS M-122 SyRS-010,SyRS-009 N J belegt nein
SwRS-138 Entitaetsmodell I3D SwRS M-123 SyRS-009,SyRS-010 N J belegt nein
SwRS-139 ModuleFeatures SwRS M-124 SyRS-003 N J belegt nein
SwRS-140 Objektartenkatalog SwRS M-125 SyRS-011 N J belegt nein
SwRS-141 Gateway-Formatadapter SwRS M-126 SyRS-027,SyRS-021,SyRS-043 N J belegt Kandidat:EDI-Doppel
SwRS-142 WPF-Client SwRS M-127 SyRS-031 N J belegt Kandidat:Nexus
SwRS-143 Controls-Bibliothek SwRS M-128 SyRS-031 N J belegt nein
SwRS-144 Core-Bibliothek TOTP SwRS M-129 SyRS-005 J J belegt nein
SwRS-145 Nexus-Webclient SwRS M-130,M-131,M-132 SyRS-031,SyRS-045 N J belegt Kandidat:SwRS-142
SwRS-146 Webservice-Hosting SwRS M-134,M-135,M-136 SyRS-047,SyRS-031 N J belegt nein
SwRS-147 Versionierte Controller SwRS M-133 SyRS-046,SyRS-031 J J belegt nein
SwRS-148 Distributor-Produktdaten SwRS M-140,M-141,M-143,M-144 SyRS-027,StRS-007 N J belegt nein
SwRS-149 finAPI-Client SwRS M-142 SyRS-032 J J belegt nein
SwRS-150 docuFORM-Anbindung SwRS M-145 SyRS-038,SyRS-027 N J belegt Kandidat:Assets
SwRS-151 GLS/Shipcloud Logik SwRS M-138,M-139 SyRS-044 N J belegt nein
SwRS-152 Legacy-DB-Schema Kunden SwRS M-146 SyRS-011,SyRS-020 N J belegt Kandidat:Bankdaten
SwRS-153 Release-Artefakte SwRS M-147,M-148,M-149 SyRS-047,SyRS-048,SyRS-049 N J belegt nein
SyRS-050 [HYPOTHESE] Mahnwesen SyRS M-026,M-053 StRS-009,StRS-003 J N HYPOTHESE nein
SwRS-154 [HYPOTHESE] Anzahlungsverrechnung SwRS M-083 SyRS-011,SyRS-014 J J HYPOTHESE nein
SwRS-155 [HYPOTHESE] SEPA-Lastschrift SwRS M-053,M-001 SyRS-032,SyRS-021 J J HYPOTHESE nein
SwRS-156 [HYPOTHESE] WebCart-Sonderpreise SwRS M-130,M-086 SyRS-045 N N HYPOTHESE nein
SwRS-157 [HYPOTHESE] Exchange-Sync SwRS M-060,M-033 SyRS-035,SyRS-029 N N HYPOTHESE Kandidat:SwRS-104
SwRS-158 [HYPOTHESE] Fernwartung Supremo SwRS M-067 SyRS-029,SyRS-030 N N HYPOTHESE nein
StRS-001 Geschaeftspartnerverwaltung StRS M-002 SyRS-020,SyRS-024 N J belegt nein
StRS-002 Angebots-/Auftragsabwicklung StRS M-083 SyRS-011,SyRS-015,SyRS-016 N J belegt nein
StRS-003 Geschuetzte Fakturierung StRS M-083,M-087 SyRS-012,SyRS-014,SyRS-042 J J belegt nein
StRS-004 Vertragsgeschaeft StRS M-084 SyRS-037,SyRS-038,SyRS-039 J J belegt nein
StRS-005 Helpdesk StRS M-086 SyRS-040,SyRS-041,SyRS-036 N J belegt nein
StRS-006 Leistungserfassung StRS M-084,M-086 SyRS-039 J J belegt nein
StRS-007 Einkauf+Distribution StRS M-079,M-048 SyRS-027 N J belegt nein
StRS-008 Artikel-/Lagerfuehrung StRS M-115,M-059,M-098 SyRS-013,SyRS-034 N J belegt nein
StRS-009 Finanzprozesse StRS M-053,M-044,M-087 SyRS-021,SyRS-032,SyRS-042,SyRS-050 J J belegt nein
StRS-010 E-Belegaustausch StRS M-044,M-048 SyRS-043,SyRS-027 J J belegt nein
StRS-011 Versandabwicklung StRS M-138,M-139 SyRS-044 N J belegt nein
StRS-012 Berechtigungssteuerung StRS M-024 SyRS-001,SyRS-002,SyRS-008 J J belegt nein
StRS-013 Sichere Anmeldung/API StRS M-017,M-003 SyRS-003,SyRS-004,SyRS-005,SyRS-017,SyRS-046 J J belegt nein
StRS-014 Lizenz-/Modulsteuerung StRS M-016,M-065 SyRS-003 J J belegt nein
StRS-015 Belegdruck/Berichte StRS M-080 SyRS-025 N J belegt nein
StRS-016 BW-Transparenz StRS M-097 SyRS-021 N J belegt nein
StRS-017 Integrierte Kommunikation StRS M-060,M-101,M-037 SyRS-035,SyRS-036,SyRS-030 N J belegt nein
StRS-018 Arbeitsorganisation StRS M-067,M-066 SyRS-029 N J belegt nein
StRS-019 Endkunden-Self-Service StRS M-130,M-093 SyRS-045,SyRS-002 N J belegt nein
StRS-020 Dokumente+Signatur StRS M-013,M-092 SyRS-026,SyRS-022 N J belegt nein
StRS-021 Konnektoren-Offenheit StRS M-071,M-044 SyRS-027 N J belegt nein
StRS-022 Kundengeraete-Ueberblick StRS M-045,M-046,M-084 SyRS-028 N J belegt Kandidat:Asset-Konzept
StRS-023 RMA StRS M-042 SyRS-028 N J belegt nein
StRS-024 Fertigung StRS M-077 SyRS-013 N J belegt nein
StRS-025 CRM/Projekte StRS M-078,M-076,M-105 SyRS-020 N J belegt Kandidat:Projektbegriffe
StRS-026 Marketing StRS M-062,M-088 SyRS-035 N J belegt nein
StRS-027 Zentrale Suche StRS M-056 SyRS-033 N J belegt nein
StRS-028 Kundenzugangsdaten StRS M-073,M-074 SyRS-017 J J belegt Kandidat:2 Passwortmodule
StRS-029 KI-Unterstuetzung StRS M-030,M-005 SyRS-019 N J belegt nein
StRS-030 DSGVO+Audit StRS M-012,M-036 SyRS-022,SyRS-009,SyRS-010 J J belegt nein
StRS-031 Automatisierter Betrieb StRS M-006,M-148,M-147,M-151 SyRS-018,SyRS-047,SyRS-048,SyRS-049 N J belegt nein
StRS-032 Anpassbarkeit StRS M-026,M-011,M-043 SyRS-023 N J belegt nein
StRS-033 Mehrfirmen-/Filialbetrieb StRS M-009,M-018 SyRS-024,SyRS-012 N J belegt nein
1 ReqID Titel Ebene Module Trace Risiko PRIMAER Status Konsolidierung
2 SyRS-001 Gruppenbasierte Benutzerrechtepruefung SyRS M-024 StRS-012 J J belegt Kandidat:SyRS-002
3 SyRS-002 Getrenntes Rechtemodell fuer Web-Accounts SyRS M-024 StRS-019,StRS-012 J J belegt Kandidat:SyRS-001
4 SyRS-003 Ticketbasierte Sitzungen mit Lizenzpruefung SyRS M-017,M-016 StRS-013,StRS-014 J J belegt nein
5 SyRS-004 Mehrere Authentifizierungsverfahren SyRS M-017 StRS-013 J J belegt nein
6 SyRS-005 Zwei-Faktor-Authentifizierung SyRS M-017 StRS-013 J J belegt Kandidat:SwRS-011
7 SyRS-006 Zeitgesteuerte Kontodeaktivierung SyRS M-017 StRS-012,StRS-013 J J belegt nein
8 SyRS-007 Anwendungsbezogene Anmelderechte SyRS M-017 StRS-012,StRS-013 J J belegt nein
9 SyRS-008 Standard-Rechtegruppen SyRS M-024 StRS-012 J J belegt nein
10 SyRS-009 Aenderungsnachverfolgung SyRS M-036,M-039 StRS-030 N J belegt nein
11 SyRS-010 Transaktionale Speicherung SyRS M-039 StRS-030 N J belegt nein
12 SwRS-001 Rechteermittlung SQL+Cache SwRS M-024 SyRS-001,SyRS-002 J J belegt nein
13 SwRS-002 Passwort SHA1 ungesalzen SwRS M-017 SyRS-004 J J belegt nein
14 SwRS-003 2FA-Validatorwahl SwRS M-017 SyRS-005 J J belegt nein
15 SwRS-004 Rechtegruppenverwaltung SwRS M-024 SyRS-001,SyRS-008 J J belegt nein
16 SwRS-005 Ticket-Wiederverwendung+LoginIP SwRS M-017 SyRS-003 J J belegt nein
17 SwRS-006 Speicher-Template Hooks SwRS M-039 SyRS-010 N J belegt nein
18 SwRS-007 Erstellungs-/Aenderungsmetadaten SwRS M-036,M-039 SyRS-009 N J belegt nein
19 SwRS-008 Standardrechtegruppen aus Ressource SwRS M-024 SyRS-008 J J belegt nein
20 SwRS-009 Signaturvalidierte Lizenzdatei SwRS M-016 SyRS-003 J J belegt nein
21 SyRS-011 Belegkette Weiterfuehrungswege SyRS M-083 StRS-002,StRS-003 J J belegt Kandidat:CustomerAssets-Modell
22 SyRS-012 Nummernkreise je Mandant/Filiale SyRS M-083,M-018 StRS-003,StRS-012 J J belegt nein
23 SyRS-013 Bestandswirkung der Belege SyRS M-083,M-115 StRS-002,StRS-008,StRS-024 J J belegt nein
24 SyRS-014 Mindestpreisschutz SyRS M-083 StRS-003 J J belegt nein
25 SyRS-015 Belegsperren+Concurrency SyRS M-083 StRS-002 N J belegt nein
26 SyRS-016 Belegversionierung SyRS M-083 StRS-002,StRS-030 N J belegt nein
27 SwRS-010 Belegnummernvergabe+Templatekunde SwRS M-083 SyRS-012 J J belegt nein
28 SwRS-011 TOTP-Zweitfaktor SwRS M-111 SyRS-005 J J belegt Kandidat:SyRS-005
29 SwRS-012 Nummernkreis-Kaskade SwRS M-018 SyRS-012 J J belegt nein
30 SwRS-013 IReceiptSpecificLogic-Strategie SwRS M-083 SyRS-011,SyRS-013 N J belegt nein
31 SwRS-014 Negativbuchung nur mit Recht SwRS M-083,M-115 SyRS-013,SyRS-001 J J belegt nein
32 SwRS-015 Mindestpreis-Reauth SwRS M-083 SyRS-014 J J belegt nein
33 SwRS-016 Filialzuordnung BranchOrigin SwRS M-083 SyRS-012 N J belegt nein
34 SwRS-017 Seriennummern-Vollstaendigkeit SwRS M-083 SyRS-013 N J belegt nein
35 SwRS-018 Firmengruppen-Belegeinstellungen SwRS M-083 SyRS-011 N J belegt nein
36 SyRS-017 API-Zugriffstokens SyRS M-003 StRS-013,StRS-028 J J belegt nein
37 SyRS-018 Steuerbare Hintergrunddienste SyRS M-006 StRS-031 N J belegt nein
38 SyRS-019 KI-Assistenz konfigurierbar SyRS M-005,M-030 StRS-029 N J belegt nein
39 SwRS-019 Bankverbindungen Rechte+Default SwRS M-001 SyRS-001,SyRS-020 J J belegt nein
40 SwRS-020 Kontenstamm Rechte+FiBu-Nummer SwRS M-002 SyRS-001,SyRS-020 J J belegt nein
41 SwRS-021 API-Token Hash+Ablauf+Log SwRS M-003 SyRS-017 J J belegt nein
42 SwRS-022 Client-Version je Anmeldung SwRS M-004 SyRS-003 N J belegt nein
43 SwRS-023 KI-Prompts+verschluesselte Keys SwRS M-005 SyRS-019 N J belegt nein
44 SwRS-024 Hintergrunddienst-Zustand SwRS M-006 SyRS-018 N J belegt nein
45 SwRS-025 Kontenrahmenverwaltung SwRS M-007 SyRS-021 N J belegt nein
46 SwRS-026 Konfig-DB Masterkey SwRS M-008 SyRS-017,StRS-028 J J belegt Kandidat:SwRS-023
47 SyRS-020 Konten-/Adressstamm SyRS M-002 StRS-001,StRS-025 N J belegt nein
48 SyRS-022 DSGVO Loeschkonzept SyRS M-012 StRS-030 J J belegt nein
49 SyRS-023 Zentrale Konfiguration SyRS M-026 StRS-032 N J belegt nein
50 SyRS-024 Mandanten-/Filialstruktur SyRS M-009,M-018 StRS-033 N J belegt nein
51 SwRS-027 Kollisionssichere Nummernvergabe SwRS M-009 SyRS-012,SyRS-024 J J belegt nein
52 SwRS-028 Verbindungsverwaltung SwRS M-010 SyRS-003 N J belegt nein
53 SwRS-029 Custom Properties je Modul SwRS M-011 SyRS-023 N J belegt Kandidat:M-043
54 SwRS-030 DSGVO-Kontaktloeschung SwRS M-012 SyRS-022 J J belegt nein
55 SwRS-031 Online-AVV/SEPA-Dokumente SwRS M-013 SyRS-022,StRS-020 N J belegt Kandidat:Nexus-Signierung
56 SwRS-032 Mitarbeiter Abteilungen/Skills SwRS M-014 SyRS-020,StRS-012 N J belegt nein
57 SwRS-033 DB-Umgebungspruefungen SwRS M-015 SyRS-023 N J belegt nein
58 SwRS-034 Konditionen-Stammdaten SwRS M-019 SyRS-011 N J belegt nein
59 SwRS-035 Netzwerkdiagnose SwRS M-020 SyRS-023 N J belegt nein
60 SwRS-036 Performance-Messungen SwRS M-021 SyRS-023 N J belegt nein
61 SwRS-037 Telefonie-Einstellungen SwRS M-022 SyRS-030 N J belegt nein
62 SwRS-038 Portal Statuspruefung/Reportupload SwRS M-023 SyRS-025 N J belegt nein
63 SwRS-039 Wartungsskripte+SQL-Management SwRS M-025 SyRS-023,SyRS-018 N J belegt nein
64 SwRS-040 Typisierter Einstellungszugriff SwRS M-026 SyRS-023 N J belegt nein
65 SwRS-041 UI-Themes SwRS M-027 SyRS-023 N J belegt nein
66 SwRS-042 Webservice-Konfigurationsdatei SwRS M-028 SyRS-023,SyRS-005 N J belegt nein
67 SyRS-021 FiBu-Uebergabe DATEV SyRS M-044 StRS-009,StRS-016 J J belegt nein
68 SwRS-043 Terminanfragen SwRS M-029 SyRS-029,StRS-018 N J belegt nein
69 SwRS-044 Lieferantenbeleg-Ablage SwRS M-031 SyRS-026 N J belegt nein
70 SwRS-045 Distributoren auto-anlegen SwRS M-032 SyRS-027 N J belegt nein
71 SwRS-046 Kalender-Einstellungen SwRS M-033 SyRS-029,StRS-018 N J belegt nein
72 SwRS-047 Icon-Verwaltung SwRS M-034 SyRS-031 N J belegt nein
73 SwRS-048 Nexus-Einstellungen SwRS M-035 SyRS-031 N J belegt nein
74 SwRS-049 Chat SwRS M-037 SyRS-029,StRS-017 N J belegt nein
75 SwRS-050 Checklisten SwRS M-038 SyRS-029 N J belegt nein
76 SwRS-051 Laender/Waehrungen SwRS M-040 SyRS-011,StRS-001 N J belegt nein
77 SwRS-052 CPra-Konnektor SwRS M-041 SyRS-027 N J belegt nein
78 SwRS-053 Custom Tables SwRS M-043 SyRS-023 N J belegt Kandidat:SwRS-029
79 SwRS-054 AccountDevices SwRS M-045 SyRS-028,StRS-022 N J belegt Kandidat:Assets
80 SwRS-055 AssetManagement DocuBoard SwRS M-046 SyRS-028,StRS-022 N J belegt Kandidat:SwRS-054
81 SwRS-056 Dokumentationen SwRS M-047 SyRS-026,StRS-020 N J belegt nein
82 SwRS-057 FiBu-Exportkonfigurationen SwRS M-044 SyRS-021 J J belegt nein
83 SwRS-058 Doppeluebergabeschutz FiBu SwRS M-044 SyRS-021 J J belegt nein
84 SyRS-025 Report-Engine Belegdruck SyRS M-080,M-081 StRS-015 N J belegt nein
85 SyRS-026 Dokumenten-/Verzeichnisverwaltung SyRS M-013 StRS-020 N J belegt nein
86 SyRS-027 EDI-Bestelluebertragung SyRS M-048 StRS-010,StRS-007,StRS-021 N J belegt Kandidat:Gateway-EDI
87 SyRS-028 Kundengeraete/Assets SyRS M-045,M-046,M-084 StRS-022,StRS-023 N J belegt Kandidat:3 Datenhaltungen
88 SyRS-029 Organisation+Zusammenarbeit SyRS M-033,M-066,M-067,M-107 StRS-018 N J belegt nein
89 SyRS-030 TAPI-Telefonie SyRS M-101,M-022 StRS-017 N J belegt nein
90 SyRS-031 Mehrkanal-Clients SyRS M-127,M-130,M-133 StRS-019 N J belegt Kandidat:Doppel-UI
91 SyRS-032 Onlinebanking-Zahlungsabgleich SyRS M-053 StRS-009 J J belegt nein
92 SyRS-033 Volltextsuche SyRS M-056 StRS-027 N J belegt nein
93 SyRS-034 Massenaenderungen SyRS M-063 StRS-008 N J belegt nein
94 SyRS-035 E-Mail/Exchange SyRS M-060 StRS-017,StRS-026 N J belegt nein
95 SyRS-036 Mail-Scanner SyRS M-061 StRS-017,StRS-005 N J belegt Kandidat:Workflows
96 SwRS-059 RMA-Abwicklung SwRS M-042 SyRS-028,StRS-023 N J belegt nein
97 SwRS-060 EDI-Bestellerzeugung SwRS M-048 SyRS-027 N J belegt nein
98 SwRS-061 Mitarbeiterstatus/Dispatcher SwRS M-049 SyRS-020,StRS-012 N J belegt nein
99 SwRS-062 ExpectedEvents SwRS M-050 SyRS-018,StRS-031 N J belegt nein
100 SwRS-063 Externe Helpdesk-Konfiguration SwRS M-051 SyRS-027,StRS-005 N J belegt Kandidat:DocBee
101 SwRS-064 Externe Tools SwRS M-052 SyRS-023 N J belegt nein
102 SwRS-065 Zahlungseingangsprotokoll SwRS M-053 SyRS-032 J J belegt nein
103 SwRS-066 Bankumsatz-Zuordnung/Buchung SwRS M-053 SyRS-032 J J belegt nein
104 SwRS-067 CustomGateway Sonderartikel SwRS M-054 SyRS-027,StRS-004 N J belegt nein
105 SwRS-068 Lucene-Index inkrementell SwRS M-056 SyRS-033 N J belegt nein
106 SwRS-069 Shop-Integration ExternalId SwRS M-057 SyRS-027,StRS-019 N J belegt nein
107 SwRS-070 ItPlanner Kategorien SwRS M-058 SyRS-029 N J belegt nein
108 SwRS-071 Lagerorte+Umbuchungslog SwRS M-059 SyRS-013,StRS-008 N J belegt nein
109 SwRS-072 Signaturen+Blacklist SwRS M-060 SyRS-035 N J belegt nein
110 SwRS-073 MailScanner-Konfiguration SwRS M-061 SyRS-036 N J belegt nein
111 SwRS-074 Serien-Mailings SwRS M-062 SyRS-035,StRS-026 N J belegt nein
112 SwRS-075 Massenpreisaenderungen SwRS M-063 SyRS-034 N J belegt nein
113 SwRS-076 Mobile Mitarbeiterliste SwRS M-064 SyRS-031 N J belegt nein
114 SwRS-077 Modulkatalog+Favoriten SwRS M-065 SyRS-031,StRS-014 N J belegt nein
115 SwRS-078 Dashboards SwRS M-066 SyRS-029 N J belegt nein
116 SwRS-079 MyDay Arbeitsvorrat SwRS M-067 SyRS-029 N J belegt nein
117 SwRS-080 Nexus-Benachrichtigungen SwRS M-068 SyRS-031,StRS-018 N J belegt Kandidat:M-070
118 SwRS-081 Ticket-Ansichten Nexus SwRS M-069 SyRS-031,StRS-005 N J belegt nein
119 SwRS-082 Objekt-Benachrichtigungsempfaenger SwRS M-070 SyRS-029 N J belegt Kandidat:SwRS-080
120 SwRS-083 Externe Objektreferenzen SwRS M-071 SyRS-027 N J belegt nein
121 SwRS-084 Outlook-Assetsuche SwRS M-072 SyRS-031,StRS-022 N J belegt nein
122 SwRS-085 Kundenzugangsdaten+Logs SwRS M-073 SyRS-017,StRS-028 J J belegt Kandidat:M-074
123 SwRS-086 Passwortmanager Siegel SwRS M-074 SyRS-017,StRS-028 J J belegt Kandidat:SwRS-085
124 SwRS-087 Prozesse Schritte/Bindungen SwRS M-075 SyRS-036,StRS-031 N J belegt Kandidat:Workflows
125 SwRS-088 Produktmatrix SwRS M-076 SyRS-020,StRS-025 N J belegt nein
126 SwRS-089 Fertigungsauftraege SwRS M-077 SyRS-013,StRS-024 N J belegt nein
127 SwRS-090 Projektliste SwRS M-078 SyRS-020,StRS-025 N J belegt Kandidat:Projektbegriffe
128 SwRS-091 Bestellvorschlaege SwRS M-079 SyRS-027,StRS-007 N J belegt nein
129 SyRS-037 Vertragsverwaltung Laufzeit/Intervalle SyRS M-084 StRS-004 J J belegt nein
130 SyRS-038 Automatische Vertragsfakturierung SyRS M-084 StRS-004,StRS-003 J J belegt nein
131 SyRS-039 Timer-Billing SyRS M-084,M-086 StRS-006,StRS-005 J J belegt nein
132 SyRS-040 Helpdesk Rechte+Status SyRS M-086 StRS-005,StRS-012 J J belegt nein
133 SyRS-041 Ticket-Eskalation SyRS M-086 StRS-005 N J belegt nein
134 SyRS-042 Kassenbuch SyRS M-087 StRS-003,StRS-009 J J belegt nein
135 SwRS-092 Vertrags-Datumsarithmetik SwRS M-084 SyRS-037 J J belegt nein
136 SwRS-093 Auto-Vertragsschliessen SwRS M-084 SyRS-037,SyRS-038 J J belegt nein
137 SwRS-094 Abrechnungsfaellige Kunden+Zaehler SwRS M-084 SyRS-038 J J belegt nein
138 SwRS-095 Timer-Belegerzeugung SwRS M-084,M-086 SyRS-039 J J belegt nein
139 SwRS-096 Ticket-Rechtepruefung Save SwRS M-086 SyRS-040,SyRS-001 J J belegt nein
140 SwRS-097 Ticket-Sichtbarkeit restriktiv SwRS M-086 SyRS-040 J J belegt nein
141 SwRS-098 Eskalationslauf SwRS M-086 SyRS-041 N J belegt nein
142 SwRS-099 Ticketabschluss+Benachrichtigung SwRS M-086 SyRS-040,SyRS-025 N J belegt nein
143 SwRS-100 Kassenbuchbuchung SwRS M-087 SyRS-042 J J belegt nein
144 SwRS-101 Riverbird-Ticketvalidierung SwRS M-082 SyRS-017,SyRS-027 J J belegt nein
145 SwRS-102 Kundensuche Kompakt SwRS M-085 SyRS-020 N J belegt nein
146 SwRS-103 Telemarketing SwRS M-088 SyRS-020,StRS-026 N J belegt nein
147 SwRS-104 Terminverwaltung Schedule SwRS M-089 SyRS-029 N J belegt Kandidat:M-033
148 SwRS-105 Dokuwizard Infrastruktur SwRS M-090 SyRS-026,StRS-020 N J belegt Kandidat:M-047
149 SwRS-106 Stundenzuschlagssaetze SwRS M-091 SyRS-039 J J belegt nein
150 SwRS-107 PDF-Signatur SwRS M-092 SyRS-025,StRS-020 J J belegt nein
151 SwRS-108 SelfCare-Formulare SwRS M-093 SyRS-031,StRS-019 N J belegt Kandidat:WebHDQuestion
152 SwRS-109 Workflow-Prozesse SwRS M-094 SyRS-036,StRS-031 N J belegt Kandidat:SwRS-087
153 SwRS-110 Social-Media-Feed SwRS M-095 SyRS-029 N J belegt nein
154 SwRS-111 Start Mapping/Verbindung SwRS M-096 SyRS-010 N J belegt nein
155 SwRS-112 Inventur SwRS M-098 SyRS-013,StRS-008 J J belegt nein
156 SwRS-113 I3D-Systemtabelle SwRS M-099 SyRS-010 N J belegt nein
157 SwRS-114 Tags SwRS M-100 SyRS-040 N J belegt nein
158 SwRS-115 Anruferkennung SwRS M-101 SyRS-030 N J belegt nein
159 SwRS-116 TaskManager Handler SwRS M-102 SyRS-029,StRS-031 N J belegt Kandidat:M-107
160 SwRS-117 Telemetrie SwRS M-103 SyRS-023 N J belegt nein
161 SwRS-118 Textbausteine SwRS M-104 SyRS-025,SyRS-011 N J belegt nein
162 SwRS-119 Ticket-Projekte SwRS M-105 SyRS-040,StRS-025 N J belegt Kandidat:SwRS-090
163 SwRS-120 TimingSettings SwRS M-106 SyRS-018 N J belegt nein
164 SwRS-121 Objekt-ToDos SwRS M-107 SyRS-029 N J belegt Kandidat:SwRS-116
165 SwRS-122 Textformat-Konvertierung SwRS M-108 SyRS-023 N J belegt nein
166 SwRS-123 TradePool-Import SwRS M-109 SyRS-027 N J belegt nein
167 SwRS-124 Transaktionsobjekte SwRS M-110 SyRS-020 N J belegt nein
168 SwRS-125 SimpleUrls SwRS M-112 SyRS-026 N J belegt nein
169 SwRS-126 Videoportal-Zuordnung SwRS M-113 SyRS-023 N J belegt nein
170 SwRS-127 Gutscheinverwaltung SwRS M-114 SyRS-042 J J belegt nein
171 SwRS-128 Artikelstamm Systemartikel SwRS M-115 SyRS-013,StRS-008 N J belegt nein
172 SwRS-129 Aktions-Weblinks SwRS M-116 SyRS-031,StRS-019 N J belegt nein
173 SwRS-130 Webmenue-Konfiguration SwRS M-118 SyRS-031 N J belegt nein
174 SwRS-131 Webservice-Version SwRS M-119 SyRS-031 N J belegt nein
175 SwRS-132 PDF-Merge SwRS M-120 SyRS-025 N J belegt nein
176 SwRS-133 Typisierte Exceptions SwRS M-121 SyRS-003 N J belegt nein
177 SyRS-043 E-Rechnungsformate SyRS M-044,M-080,M-126,M-137 StRS-010,StRS-003 J J belegt nein
178 SyRS-044 Versanddienstleister SyRS M-138,M-139 StRS-011 N J belegt Kandidat:GLS-vs-Shipcloud
179 SyRS-045 Kundenportal Nexus SyRS M-130 StRS-019 N J belegt Kandidat:SelfCare
180 SyRS-046 REST-API Rechteautorisierung SyRS M-133 StRS-013,StRS-012 J J belegt nein
181 SyRS-047 Container-Betrieb SyRS M-148 StRS-031 N J belegt nein
182 SyRS-048 Windows-Installer SyRS M-147,M-149 StRS-031 N J belegt nein
183 SyRS-049 Testabdeckung SyRS M-151,M-148 StRS-031 N J belegt nein
184 SwRS-134 Grid-/UI-Profile SwRS M-055 SyRS-031 N J belegt nein
185 SwRS-135 Statistiken SwRS M-097 SyRS-021,SyRS-032,StRS-016 N J belegt nein
186 SwRS-136 Webservice-Fassaden SwRS M-117 SyRS-031,SyRS-046 N J belegt Kandidat:Doppel-BL
187 SwRS-137 DAO Event-Listener SwRS M-122 SyRS-010,SyRS-009 N J belegt nein
188 SwRS-138 Entitaetsmodell I3D SwRS M-123 SyRS-009,SyRS-010 N J belegt nein
189 SwRS-139 ModuleFeatures SwRS M-124 SyRS-003 N J belegt nein
190 SwRS-140 Objektartenkatalog SwRS M-125 SyRS-011 N J belegt nein
191 SwRS-141 Gateway-Formatadapter SwRS M-126 SyRS-027,SyRS-021,SyRS-043 N J belegt Kandidat:EDI-Doppel
192 SwRS-142 WPF-Client SwRS M-127 SyRS-031 N J belegt Kandidat:Nexus
193 SwRS-143 Controls-Bibliothek SwRS M-128 SyRS-031 N J belegt nein
194 SwRS-144 Core-Bibliothek TOTP SwRS M-129 SyRS-005 J J belegt nein
195 SwRS-145 Nexus-Webclient SwRS M-130,M-131,M-132 SyRS-031,SyRS-045 N J belegt Kandidat:SwRS-142
196 SwRS-146 Webservice-Hosting SwRS M-134,M-135,M-136 SyRS-047,SyRS-031 N J belegt nein
197 SwRS-147 Versionierte Controller SwRS M-133 SyRS-046,SyRS-031 J J belegt nein
198 SwRS-148 Distributor-Produktdaten SwRS M-140,M-141,M-143,M-144 SyRS-027,StRS-007 N J belegt nein
199 SwRS-149 finAPI-Client SwRS M-142 SyRS-032 J J belegt nein
200 SwRS-150 docuFORM-Anbindung SwRS M-145 SyRS-038,SyRS-027 N J belegt Kandidat:Assets
201 SwRS-151 GLS/Shipcloud Logik SwRS M-138,M-139 SyRS-044 N J belegt nein
202 SwRS-152 Legacy-DB-Schema Kunden SwRS M-146 SyRS-011,SyRS-020 N J belegt Kandidat:Bankdaten
203 SwRS-153 Release-Artefakte SwRS M-147,M-148,M-149 SyRS-047,SyRS-048,SyRS-049 N J belegt nein
204 SyRS-050 [HYPOTHESE] Mahnwesen SyRS M-026,M-053 StRS-009,StRS-003 J N HYPOTHESE nein
205 SwRS-154 [HYPOTHESE] Anzahlungsverrechnung SwRS M-083 SyRS-011,SyRS-014 J J HYPOTHESE nein
206 SwRS-155 [HYPOTHESE] SEPA-Lastschrift SwRS M-053,M-001 SyRS-032,SyRS-021 J J HYPOTHESE nein
207 SwRS-156 [HYPOTHESE] WebCart-Sonderpreise SwRS M-130,M-086 SyRS-045 N N HYPOTHESE nein
208 SwRS-157 [HYPOTHESE] Exchange-Sync SwRS M-060,M-033 SyRS-035,SyRS-029 N N HYPOTHESE Kandidat:SwRS-104
209 SwRS-158 [HYPOTHESE] Fernwartung Supremo SwRS M-067 SyRS-029,SyRS-030 N N HYPOTHESE nein
210 StRS-001 Geschaeftspartnerverwaltung StRS M-002 SyRS-020,SyRS-024 N J belegt nein
211 StRS-002 Angebots-/Auftragsabwicklung StRS M-083 SyRS-011,SyRS-015,SyRS-016 N J belegt nein
212 StRS-003 Geschuetzte Fakturierung StRS M-083,M-087 SyRS-012,SyRS-014,SyRS-042 J J belegt nein
213 StRS-004 Vertragsgeschaeft StRS M-084 SyRS-037,SyRS-038,SyRS-039 J J belegt nein
214 StRS-005 Helpdesk StRS M-086 SyRS-040,SyRS-041,SyRS-036 N J belegt nein
215 StRS-006 Leistungserfassung StRS M-084,M-086 SyRS-039 J J belegt nein
216 StRS-007 Einkauf+Distribution StRS M-079,M-048 SyRS-027 N J belegt nein
217 StRS-008 Artikel-/Lagerfuehrung StRS M-115,M-059,M-098 SyRS-013,SyRS-034 N J belegt nein
218 StRS-009 Finanzprozesse StRS M-053,M-044,M-087 SyRS-021,SyRS-032,SyRS-042,SyRS-050 J J belegt nein
219 StRS-010 E-Belegaustausch StRS M-044,M-048 SyRS-043,SyRS-027 J J belegt nein
220 StRS-011 Versandabwicklung StRS M-138,M-139 SyRS-044 N J belegt nein
221 StRS-012 Berechtigungssteuerung StRS M-024 SyRS-001,SyRS-002,SyRS-008 J J belegt nein
222 StRS-013 Sichere Anmeldung/API StRS M-017,M-003 SyRS-003,SyRS-004,SyRS-005,SyRS-017,SyRS-046 J J belegt nein
223 StRS-014 Lizenz-/Modulsteuerung StRS M-016,M-065 SyRS-003 J J belegt nein
224 StRS-015 Belegdruck/Berichte StRS M-080 SyRS-025 N J belegt nein
225 StRS-016 BW-Transparenz StRS M-097 SyRS-021 N J belegt nein
226 StRS-017 Integrierte Kommunikation StRS M-060,M-101,M-037 SyRS-035,SyRS-036,SyRS-030 N J belegt nein
227 StRS-018 Arbeitsorganisation StRS M-067,M-066 SyRS-029 N J belegt nein
228 StRS-019 Endkunden-Self-Service StRS M-130,M-093 SyRS-045,SyRS-002 N J belegt nein
229 StRS-020 Dokumente+Signatur StRS M-013,M-092 SyRS-026,SyRS-022 N J belegt nein
230 StRS-021 Konnektoren-Offenheit StRS M-071,M-044 SyRS-027 N J belegt nein
231 StRS-022 Kundengeraete-Ueberblick StRS M-045,M-046,M-084 SyRS-028 N J belegt Kandidat:Asset-Konzept
232 StRS-023 RMA StRS M-042 SyRS-028 N J belegt nein
233 StRS-024 Fertigung StRS M-077 SyRS-013 N J belegt nein
234 StRS-025 CRM/Projekte StRS M-078,M-076,M-105 SyRS-020 N J belegt Kandidat:Projektbegriffe
235 StRS-026 Marketing StRS M-062,M-088 SyRS-035 N J belegt nein
236 StRS-027 Zentrale Suche StRS M-056 SyRS-033 N J belegt nein
237 StRS-028 Kundenzugangsdaten StRS M-073,M-074 SyRS-017 J J belegt Kandidat:2 Passwortmodule
238 StRS-029 KI-Unterstuetzung StRS M-030,M-005 SyRS-019 N J belegt nein
239 StRS-030 DSGVO+Audit StRS M-012,M-036 SyRS-022,SyRS-009,SyRS-010 J J belegt nein
240 StRS-031 Automatisierter Betrieb StRS M-006,M-148,M-147,M-151 SyRS-018,SyRS-047,SyRS-048,SyRS-049 N J belegt nein
241 StRS-032 Anpassbarkeit StRS M-026,M-011,M-043 SyRS-023 N J belegt nein
242 StRS-033 Mehrfirmen-/Filialbetrieb StRS M-009,M-018 SyRS-024,SyRS-012 N J belegt nein
@@ -0,0 +1,69 @@
## 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 | 33 | 13,7 % |
| SyRS | 50 | 20,7 % |
| SwRS | 158 | 65,6 % |
| **Gesamt** | **241** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 133 | 55,2 % |
| Sicherheit | 32 | 13,3 % |
| Schnittstelle | 25 | 10,4 % |
| funktional (Abrechnung) | 19 | 7,9 % |
| nicht-funktional | 16 | 6,6 % |
| Daten | 12 | 5,0 % |
| Schnittstelle (Abrechnung) | 2 | 0,8 % |
| funktional (Abrechnung/Fakturierung) | 1 | 0,4 % |
| Sicherheit (Abrechnung) | 1 | 0,4 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 283 |
| davon `PRIMÄR` | 252 (89,0 %) |
| davon `SEKUNDÄR` | 18 (6,4 %) |
| davon `KONTEXT` | 13 (4,6 %) |
| Belege je Anforderung (Median) | 1 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 237 (98,3 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 218 | 90,5 % |
| workaround | 9 | 3,7 % |
| sonderfall | 7 | 2,9 % |
| veraltet | 7 | 2,9 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 235 | 97,5 % |
| als `HYPOTHESE` gekennzeichnet | 6 | 2,5 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 41 | 17,0 % |
| mit ISO-25010-Qualitätsmerkmal | 16 | 6,6 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (74 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 241 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 241 von 241 mit Tracelinks (100,0 %) |
@@ -0,0 +1,177 @@
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
## Metadaten
- **Versuch:** V1 Baseline (Prompt-only)
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-26
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
| Änderung | Auslösender Befund |
|---|---|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
> 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.
---
## 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.
**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. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
- **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)
```
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)
```
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
---
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
Kommandozeilenbefehlen im Arbeitsverzeichnis.
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
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 3\claude-fable-5\solo\high\02_Lauf_2026-08-27_002430_v7.0.0-35a4\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
2026-08-27T07:28:28.0825221+02:00
@@ -0,0 +1,150 @@
M-001 2
M-002 3
M-003 3
M-004 1
M-005 3
M-006 3
M-007 1
M-008 1
M-009 3
M-010 1
M-011 2
M-012 3
M-013 3
M-014 1
M-015 1
M-016 3
M-017 9
M-018 4
M-019 1
M-020 1
M-021 1
M-022 2
M-023 1
M-024 7
M-025 1
M-026 4
M-027 1
M-028 1
M-029 1
M-030 2
M-031 1
M-032 1
M-033 3
M-034 1
M-035 1
M-036 3
M-037 2
M-038 1
M-039 4
M-040 1
M-041 1
M-042 2
M-043 2
M-044 7
M-045 3
M-046 3
M-047 1
M-048 4
M-049 1
M-050 1
M-051 1
M-052 1
M-053 6
M-054 1
M-055 1
M-056 3
M-057 1
M-058 1
M-059 2
M-060 4
M-061 2
M-062 2
M-063 2
M-064 1
M-065 2
M-066 3
M-067 4
M-068 1
M-069 1
M-070 1
M-071 2
M-072 1
M-073 2
M-074 2
M-075 1
M-076 2
M-077 2
M-078 2
M-079 2
M-080 3
M-081 1
M-082 1
M-083 16
M-084 11
M-085 1
M-086 11
M-087 4
M-088 2
M-089 1
M-090 1
M-091 1
M-092 2
M-093 2
M-094 1
M-095 1
M-096 1
M-097 2
M-098 2
M-099 1
M-100 1
M-101 3
M-102 1
M-103 1
M-104 1
M-105 2
M-106 1
M-107 2
M-108 1
M-109 1
M-110 1
M-111 1
M-112 1
M-113 1
M-114 1
M-115 4
M-116 1
M-117 1
M-118 1
M-119 1
M-120 1
M-121 1
M-122 1
M-123 1
M-124 1
M-125 1
M-126 2
M-127 2
M-128 1
M-129 1
M-130 5
M-131 1
M-132 1
M-133 3
M-134 1
M-135 1
M-136 1
M-137 1
M-138 3
M-139 3
M-140 1
M-141 1
M-142 1
M-143 1
M-144 1
M-145 1
M-146 1
M-147 3
M-148 4
M-149 2
M-151 2
@@ -0,0 +1,192 @@
## Abdeckungstabelle (je Modul des Inventars)
Einstufung: `tief` = mehrere Anforderungen inkl. gelesener Kernlogik der risikorelevanten Pfade; `mittel` = 2-3 Anforderungen auf Basis gelesener Kernmethoden; `flach` = 1-2 Anforderungen auf Basis von Methodensignaturen/ausgewählten Codeausschnitten; `nicht analysiert` = keine Anforderung (mit Begründung).
| Modul | Bezeichnung | Einstufung | Anzahl Anforderungen | Anforderungen |
|---|---|---|---|---|
| M-001 | Accounting (Bankkonten) | mittel | 2 | SwRS-019, SwRS-155 |
| M-002 | Accounts (Konten-/Adressstamm) | mittel | 3 | SwRS-020, SyRS-020, StRS-001 |
| M-003 | Administration: AccessTokens | mittel | 3 | SyRS-017, SwRS-021, StRS-013 |
| M-004 | Administration: Applications | flach | 1 | SwRS-022 |
| M-005 | Administration: ArtificialIntelligence | mittel | 3 | SyRS-019, SwRS-023, StRS-029 |
| M-006 | Administration: BackgroundServices | mittel | 3 | SyRS-018, SwRS-024, StRS-031 |
| M-007 | Administration: BookKeepingAccountSystems | flach | 1 | SwRS-025 |
| M-008 | Administration: CentronConfigDb | flach | 1 | SwRS-026 |
| M-009 | Administration: Company/CompanyInformations | mittel | 3 | SyRS-024, SwRS-027, StRS-033 |
| M-010 | Administration: Connections | flach | 1 | SwRS-028 |
| M-011 | Administration: Customization | mittel | 2 | SwRS-029, StRS-032 |
| M-012 | Administration: DataSecurity | mittel | 3 | SyRS-022, SwRS-030, StRS-030 |
| M-013 | Administration: Documents/FileManagement | mittel | 3 | SwRS-031, SyRS-026, StRS-020 |
| M-014 | Administration: Employees | flach | 1 | SwRS-032 |
| M-015 | Administration: Environments | flach | 1 | SwRS-033 |
| M-016 | Administration: Licensing | tief | 3 | SyRS-003, SwRS-009, StRS-014 |
| M-017 | Administration: Logins/Auth | tief | 9 | SyRS-003, SyRS-004, SyRS-005, SyRS-006, SyRS-007, SwRS-002, SwRS-003, SwRS-005, StRS-013 |
| M-018 | Administration: Mandatory | mittel | 4 | SyRS-012, SwRS-012, SyRS-024, StRS-033 |
| M-019 | Administration: Masterdata | flach | 1 | SwRS-034 |
| M-020 | Administration: NetworkDiagnostics | flach | 1 | SwRS-035 |
| M-021 | Administration: PerformanceTests/Profiling | flach | 1 | SwRS-036 |
| M-022 | Administration: PhoneSettings | mittel | 2 | SwRS-037, SyRS-030 |
| M-023 | Administration: Portal | flach | 1 | SwRS-038 |
| M-024 | Administration: Rights | tief | 7 | SyRS-001, SyRS-002, SyRS-008, SwRS-001, SwRS-004, SwRS-008, StRS-012 |
| M-025 | Administration: Scripts/SQLManagement | flach | 1 | SwRS-039 |
| M-026 | Administration: Settings | mittel | 4 | SyRS-023, SwRS-040, SyRS-050, StRS-032 |
| M-027 | Administration: Themes | flach | 1 | SwRS-041 |
| M-028 | Administration: WebServiceConfiguration | flach | 1 | SwRS-042 |
| M-029 | AppointmentRequests | flach | 1 | SwRS-043 |
| M-030 | ArtificialIntelligence | mittel | 2 | SyRS-019, StRS-029 |
| M-031 | BusinessPartner | flach | 1 | SwRS-044 |
| M-032 | Buying | flach | 1 | SwRS-045 |
| M-033 | Calendar | mittel | 3 | SwRS-046, SyRS-029, SwRS-157 |
| M-034 | CentronIcons | flach | 1 | SwRS-047 |
| M-035 | CentronNexus (BL) | flach | 1 | SwRS-048 |
| M-036 | ChangeTracking | mittel | 3 | SyRS-009, SwRS-007, StRS-030 |
| M-037 | Chats | mittel | 2 | SwRS-049, StRS-017 |
| M-038 | CheckListArea | flach | 1 | SwRS-050 |
| M-039 | Core (BL-Kern) | mittel | 4 | SyRS-009, SyRS-010, SwRS-006, SwRS-007 |
| M-040 | CountryArea | flach | 1 | SwRS-051 |
| M-041 | CPra | flach | 1 | SwRS-052 |
| M-042 | CustomerArea | mittel | 2 | SwRS-059, StRS-023 |
| M-043 | Customizations (CustomTables) | mittel | 2 | SwRS-053, StRS-032 |
| M-044 | DataExchange | tief | 7 | SyRS-021, SwRS-057, SwRS-058, SyRS-043, StRS-009, StRS-010, StRS-021 |
| M-045 | Devices | mittel | 3 | SwRS-054, SyRS-028, StRS-022 |
| M-046 | DocuBoard | mittel | 3 | SwRS-055, SyRS-028, StRS-022 |
| M-047 | DocumentationArea | flach | 1 | SwRS-056 |
| M-048 | EDI | mittel | 4 | SyRS-027, SwRS-060, StRS-007, StRS-010 |
| M-049 | EmployeeArea | flach | 1 | SwRS-061 |
| M-050 | ExpectedEvents | flach | 1 | SwRS-062 |
| M-051 | ExternalHelpdesk | flach | 1 | SwRS-063 |
| M-052 | ExternalToolsBL | flach | 1 | SwRS-064 |
| M-053 | Finances | tief | 6 | SyRS-032, SwRS-065, SwRS-066, SyRS-050, SwRS-155, StRS-009 |
| M-054 | Gateway (BL) | flach | 1 | SwRS-067 |
| M-055 | GUI (BL-Anteil) | flach | 1 | SwRS-134 |
| M-056 | IndexSearch | mittel | 3 | SyRS-033, SwRS-068, StRS-027 |
| M-057 | Integrations | flach | 1 | SwRS-069 |
| M-058 | ItPlanner | flach | 1 | SwRS-070 |
| M-059 | Logistics | mittel | 2 | SwRS-071, StRS-008 |
| M-060 | Mail | mittel | 4 | SyRS-035, SwRS-072, SwRS-157, StRS-017 |
| M-061 | MailScanner | mittel | 2 | SyRS-036, SwRS-073 |
| M-062 | Mailings | mittel | 2 | SwRS-074, StRS-026 |
| M-063 | MassUpdate | mittel | 2 | SyRS-034, SwRS-075 |
| M-064 | Mobile | flach | 1 | SwRS-076 |
| M-065 | Modules | mittel | 2 | SwRS-077, StRS-014 |
| M-066 | MyCentron | mittel | 3 | SyRS-029, SwRS-078, StRS-018 |
| M-067 | MyDay | mittel | 4 | SyRS-029, SwRS-079, SwRS-158, StRS-018 |
| M-068 | NexusNotifications | flach | 1 | SwRS-080 |
| M-069 | NexusTicketViews | flach | 1 | SwRS-081 |
| M-070 | Notifications | flach | 1 | SwRS-082 |
| M-071 | ObjectExternalReferences | mittel | 2 | SwRS-083, StRS-021 |
| M-072 | Outlook | flach | 1 | SwRS-084 |
| M-073 | PasswordManagementArea | mittel | 2 | SwRS-085, StRS-028 |
| M-074 | PasswordManager | mittel | 2 | SwRS-086, StRS-028 |
| M-075 | Processes | flach | 1 | SwRS-087 |
| M-076 | ProductMatrix | mittel | 2 | SwRS-088, StRS-025 |
| M-077 | Production | mittel | 2 | SwRS-089, StRS-024 |
| M-078 | Projects | mittel | 2 | SwRS-090, StRS-025 |
| M-079 | Purchasing | mittel | 2 | SwRS-091, StRS-007 |
| M-080 | ReportEngine | mittel | 3 | SyRS-025, SyRS-043, StRS-015 |
| M-081 | Reporting | flach | 1 | SyRS-025 |
| M-082 | RiverDivo | flach | 1 | SwRS-101 |
| M-083 | Sales: Receipts (Belegwesen) | tief | 16 | SyRS-011, SyRS-012, SyRS-013, SyRS-014, SyRS-015, SyRS-016, SwRS-010, SwRS-013, SwRS-014, SwRS-015, SwRS-016, SwRS-017, SwRS-018, SwRS-154, StRS-002, StRS-003 |
| M-084 | Sales: CustomerAssets (Verträge) | tief | 11 | SyRS-028, SyRS-037, SyRS-038, SyRS-039, SwRS-092, SwRS-093, SwRS-094, SwRS-095, StRS-004, StRS-006, StRS-022 |
| M-085 | Sales: Customers (CRM) | flach | 1 | SwRS-102 |
| M-086 | Sales: Support (Helpdesk) | tief | 11 | SyRS-039, SyRS-040, SyRS-041, SwRS-095, SwRS-096, SwRS-097, SwRS-098, SwRS-099, SwRS-156, StRS-005, StRS-006 |
| M-087 | Sales: CashBooks | tief | 4 | SyRS-042, SwRS-100, StRS-003, StRS-009 |
| M-088 | Sales: Marketing | mittel | 2 | SwRS-103, StRS-026 |
| M-089 | Sales: Calendar | flach | 1 | SwRS-104 |
| M-090 | Sales: DocumentationWizardArea | flach | 1 | SwRS-105 |
| M-091 | Sales: HourlySurchargeRatesBL | flach | 1 | SwRS-106 |
| M-092 | Security (PdfSigning) | mittel | 2 | SwRS-107, StRS-020 |
| M-093 | SelfCare | mittel | 2 | SwRS-108, StRS-019 |
| M-094 | Services | flach | 1 | SwRS-109 |
| M-095 | SocialMedia | flach | 1 | SwRS-110 |
| M-096 | Start | flach | 1 | SwRS-111 |
| M-097 | Statistics | mittel | 2 | SwRS-135, StRS-016 |
| M-098 | Storage | mittel | 2 | SwRS-112, StRS-008 |
| M-099 | SystemArea | flach | 1 | SwRS-113 |
| M-100 | Tags | flach | 1 | SwRS-114 |
| M-101 | Tapi | mittel | 3 | SyRS-030, SwRS-115, StRS-017 |
| M-102 | TaskManager | flach | 1 | SwRS-116 |
| M-103 | Telemetry | flach | 1 | SwRS-117 |
| M-104 | TextModuleArea | flach | 1 | SwRS-118 |
| M-105 | TicketProjects | mittel | 2 | SwRS-119, StRS-025 |
| M-106 | Time | flach | 1 | SwRS-120 |
| M-107 | ToDoArea | mittel | 2 | SyRS-029, SwRS-121 |
| M-108 | Tools | flach | 1 | SwRS-122 |
| M-109 | TradePool | flach | 1 | SwRS-123 |
| M-110 | Transactions | flach | 1 | SwRS-124 |
| M-111 | TwoFactorAuthenticator | flach | 1 | SwRS-011 |
| M-112 | Urls | flach | 1 | SwRS-125 |
| M-113 | VideoPortal | flach | 1 | SwRS-126 |
| M-114 | VoucherManagement | flach | 1 | SwRS-127 |
| M-115 | Warehousing | mittel | 4 | SyRS-013, SwRS-014, SwRS-128, StRS-008 |
| M-116 | WebLinks | flach | 1 | SwRS-129 |
| M-117 | WebServices (BL) | flach | 1 | SwRS-136 |
| M-118 | WebSuite | flach | 1 | SwRS-130 |
| M-119 | WebVersion | flach | 1 | SwRS-131 |
| M-120 | Helpers (BL) | flach | 1 | SwRS-132 |
| M-121 | Exceptions (BL) | flach | 1 | SwRS-133 |
| M-122 | Centron.DAO (Persistenz) | flach | 1 | SwRS-137 |
| M-123 | Centron.Entities | flach | 1 | SwRS-138 |
| M-124 | Centron.Common | flach | 1 | SwRS-139 |
| M-125 | Centron.Interfaces | flach | 1 | SwRS-140 |
| M-126 | Centron.Gateway | mittel | 2 | SyRS-043, SwRS-141 |
| M-127 | Centron.WPF.UI (+ Extension) | mittel | 2 | SyRS-031, SwRS-142 |
| M-128 | Centron.Controls (+ Preview) | flach | 1 | SwRS-143 |
| M-129 | Centron.Core (shared) | flach | 1 | SwRS-144 |
| M-130 | CentronNexus (Blazor-Web) | mittel | 5 | SyRS-031, SyRS-045, SwRS-145, SwRS-156, StRS-019 |
| M-131 | CentronNexus.Host | flach | 1 | SwRS-145 |
| M-132 | CentronNexus.OutlookAddIn | flach | 1 | SwRS-145 |
| M-133 | Centron.Controllers (REST-API) | mittel | 3 | SyRS-031, SyRS-046, SwRS-147 |
| M-134 | Centron.WebServices.Core | flach | 1 | SwRS-146 |
| M-135 | Centron.Host (+ Console/WindowsService) | flach | 1 | SwRS-146 |
| M-136 | ConnectionManager | flach | 1 | SwRS-146 |
| M-137 | Centron.Api.EbInterface | flach | 1 | SyRS-043 |
| M-138 | Centron.Api.Gls | mittel | 3 | SyRS-044, SwRS-151, StRS-011 |
| M-139 | Centron.Api.Shipcloud | mittel | 3 | SyRS-044, SwRS-151, StRS-011 |
| M-140 | Centron.APIs.CopDataAccess | flach | 1 | SwRS-148 |
| M-141 | Centron.APIs.EgisDataAccess | flach | 1 | SwRS-148 |
| M-142 | Centron.APIs.FinAPI | flach | 1 | SwRS-149 |
| M-143 | Centron.APIs.IcecatDataAccess | flach | 1 | SwRS-148 |
| M-144 | Centron.APIs.ITscopeDataAccess | flach | 1 | SwRS-148 |
| M-145 | Centron.Api.docuFORM | flach | 1 | SwRS-150 |
| M-146 | Datenbankschema | flach | 1 | SwRS-152 |
| M-147 | Deployment/Installer | mittel | 3 | SyRS-048, SwRS-153, StRS-031 |
| M-148 | Docker/Betrieb | mittel | 4 | SyRS-047, SyRS-049, SwRS-153, StRS-031 |
| M-149 | Scripts | mittel | 2 | SyRS-048, SwRS-153 |
| M-150 | Dokumentation | nicht analysiert | 0 | – (reine Entwickler-/Betriebsdokumentation ohne eigene Systemfunktion; als KONTEXT-Belegquelle genutzt, z. B. für SyRS-043, SwRS-157) |
| M-151 | Tests | mittel | 2 | SyRS-049, StRS-031 |
**Summen:** tief: 9 Module, mittel: 58, flach: 83, nicht analysiert: 1 (gesamt 151 Module).
## Konsistenzcheck
Automatisiert über alle drei Spezifikationsdateien ausgeführt (241 Anforderungsblöcke):
| Prüfung | Ergebnis |
|---|---|
| Doppelte oder mehrfach vergebene IDs | keine (241 eindeutige IDs: 33 StRS, 50 SyRS, 158 SwRS) |
| Anforderungen ohne Beleg | keine (jeder Block enthält mind. einen klassifizierten Beleg) |
| Anforderungen ohne Übernahmewürdigkeit | keine |
| Anforderungen ohne Prüfidee | keine |
| Tracelinks auf nicht existierende IDs | keine |
| SwRS ohne SyRS-Referenz / SyRS ohne StRS-Referenz | keine (siehe Traceability.md) |
| Abgleich Hypothesen.md ↔ Inline-Markierungen | deckungsgleich: SyRS-050, SwRS-154, SwRS-155, SwRS-156, SwRS-157, SwRS-158 (6 Stück) |
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk | keine gefundenen; erkannte fachliche Doppelimplementierungen sind als Konsolidierungskandidaten markiert (siehe Liste unten) |
**Wesentliche Konsolidierungskandidaten (fachlich gleiche Konzepte in getrennten Implementierungen):**
1. Gerätedatenhaltungen: AccountDevices (M-045) vs. CustomerAssets/„Stammblätter" (M-084) vs. DocuBoard-Assetmanagement (M-046) → ein Asset-Konzept (SyRS-028, StRS-022).
2. Zwei Belegmodelle: Sales/Receipts (neu) vs. Sales/CustomerAssets (alt) für dieselben Belegarten (SyRS-011).
3. Zwei Rechtemodelle: interne Rechte (Sichtrus/Sichmemb) vs. WebAccountsRights (SyRS-001/SyRS-002).
4. Drei 2FA-Wege: RADIUS, E-Mail-Link, TOTP (SyRS-005, SwRS-011).
5. Zwei Passwortverwaltungen: PasswordManagementArea vs. PasswordManager (SwRS-085/SwRS-086).
6. Zwei Workflow-/Prozess-Engines: Processes vs. Services/Workflows (SwRS-087/SwRS-109); zusätzlich MailScanner-Workflows (SyRS-036).
7. Zwei Customizing-Mechanismen: Custom Properties vs. Custom Tables (SwRS-029/SwRS-053).
8. Drei Projektbegriffe: Projects, CrmProjects, TicketProjects (SwRS-090/SwRS-119, StRS-025).
9. Zwei Aufgabenkonzepte: ToDoArea vs. TaskManager (SwRS-116/SwRS-121).
10. Zwei Benachrichtigungssysteme: Notifications vs. NexusNotifications (SwRS-080/SwRS-082).
11. EDI-Logik doppelt: Centron.BL/EDI vs. Centron.Gateway/EDI_* (SyRS-027/SwRS-141).
12. Bankverbindungen doppelt: Felder in Tabelle Kunden vs. BankAccount-Objekte (SwRS-152/SwRS-019).
13. Zwei Endkunden-Formularwege: SelfCare vs. Nexus-Kundenportal-Formulare (SwRS-108/SyRS-045).
14. Versandwege GLS-direkt vs. Shipcloud (SyRS-044).
15. Desktop-Client (WPF) vs. Nexus-Web-UI für dieselben Prozesse (SyRS-031, SwRS-142/SwRS-145).
@@ -0,0 +1,83 @@
## Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
75 Anforderungen sind risikorelevant. Belegsituation:
| ID | Titel | PRIMÄR-Beleg vorhanden | Status |
|---|---|---|---|
| SyRS-001 | Gruppenbasierte Benutzerrechtepruefung | ja | belegt |
| SyRS-002 | Getrenntes Rechtemodell fuer Web-Accounts | ja | belegt |
| SyRS-003 | Ticketbasierte Sitzungen mit Lizenzpruefung | ja | belegt |
| SyRS-004 | Mehrere Authentifizierungsverfahren | ja | belegt |
| SyRS-005 | Zwei-Faktor-Authentifizierung | ja | belegt |
| SyRS-006 | Zeitgesteuerte Kontodeaktivierung | ja | belegt |
| SyRS-007 | Anwendungsbezogene Anmelderechte | ja | belegt |
| SyRS-008 | Standard-Rechtegruppen | ja | belegt |
| SwRS-001 | Rechteermittlung SQL+Cache | ja | belegt |
| SwRS-002 | Passwort SHA1 ungesalzen | ja | belegt |
| SwRS-003 | 2FA-Validatorwahl | ja | belegt |
| SwRS-004 | Rechtegruppenverwaltung | ja | belegt |
| SwRS-005 | Ticket-Wiederverwendung+LoginIP | ja | belegt |
| SwRS-008 | Standardrechtegruppen aus Ressource | ja | belegt |
| SwRS-009 | Signaturvalidierte Lizenzdatei | ja | belegt |
| SyRS-011 | Belegkette Weiterfuehrungswege | ja | belegt |
| SyRS-012 | Nummernkreise je Mandant/Filiale | ja | belegt |
| SyRS-013 | Bestandswirkung der Belege | ja | belegt |
| SyRS-014 | Mindestpreisschutz | ja | belegt |
| SwRS-010 | Belegnummernvergabe+Templatekunde | ja | belegt |
| SwRS-011 | TOTP-Zweitfaktor | ja | belegt |
| SwRS-012 | Nummernkreis-Kaskade | ja | belegt |
| SwRS-014 | Negativbuchung nur mit Recht | ja | belegt |
| SwRS-015 | Mindestpreis-Reauth | ja | belegt |
| SyRS-017 | API-Zugriffstokens | ja | belegt |
| SwRS-019 | Bankverbindungen Rechte+Default | ja | belegt |
| SwRS-020 | Kontenstamm Rechte+FiBu-Nummer | ja | belegt |
| SwRS-021 | API-Token Hash+Ablauf+Log | ja | belegt |
| SwRS-026 | Konfig-DB Masterkey | ja | belegt |
| SyRS-022 | DSGVO Loeschkonzept | ja | belegt |
| SwRS-027 | Kollisionssichere Nummernvergabe | ja | belegt |
| SwRS-030 | DSGVO-Kontaktloeschung | ja | belegt |
| SyRS-021 | FiBu-Uebergabe DATEV | ja | belegt |
| SwRS-057 | FiBu-Exportkonfigurationen | ja | belegt |
| SwRS-058 | Doppeluebergabeschutz FiBu | ja | belegt |
| SyRS-032 | Onlinebanking-Zahlungsabgleich | ja | belegt |
| SwRS-065 | Zahlungseingangsprotokoll | ja | belegt |
| SwRS-066 | Bankumsatz-Zuordnung/Buchung | ja | belegt |
| SwRS-085 | Kundenzugangsdaten+Logs | ja | belegt |
| SwRS-086 | Passwortmanager Siegel | ja | belegt |
| SyRS-037 | Vertragsverwaltung Laufzeit/Intervalle | ja | belegt |
| SyRS-038 | Automatische Vertragsfakturierung | ja | belegt |
| SyRS-039 | Timer-Billing | ja | belegt |
| SyRS-040 | Helpdesk Rechte+Status | ja | belegt |
| SyRS-042 | Kassenbuch | ja | belegt |
| SwRS-092 | Vertrags-Datumsarithmetik | ja | belegt |
| SwRS-093 | Auto-Vertragsschliessen | ja | belegt |
| SwRS-094 | Abrechnungsfaellige Kunden+Zaehler | ja | belegt |
| SwRS-095 | Timer-Belegerzeugung | ja | belegt |
| SwRS-096 | Ticket-Rechtepruefung Save | ja | belegt |
| SwRS-097 | Ticket-Sichtbarkeit restriktiv | ja | belegt |
| SwRS-100 | Kassenbuchbuchung | ja | belegt |
| SwRS-101 | Riverbird-Ticketvalidierung | ja | belegt |
| SwRS-106 | Stundenzuschlagssaetze | ja | belegt |
| SwRS-107 | PDF-Signatur | ja | belegt |
| SwRS-112 | Inventur | ja | belegt |
| SwRS-127 | Gutscheinverwaltung | ja | belegt |
| SyRS-043 | E-Rechnungsformate | ja | belegt |
| SyRS-046 | REST-API Rechteautorisierung | ja | belegt |
| SwRS-144 | Core-Bibliothek TOTP | ja | belegt |
| SwRS-147 | Versionierte Controller | ja | belegt |
| SwRS-149 | finAPI-Client | ja | belegt |
| SyRS-050 | [HYPOTHESE] Mahnwesen | nein | HYPOTHESE |
| SwRS-154 | [HYPOTHESE] Anzahlungsverrechnung | ja | HYPOTHESE |
| SwRS-155 | [HYPOTHESE] SEPA-Lastschrift | ja | HYPOTHESE |
| StRS-003 | Geschuetzte Fakturierung | ja | belegt |
| StRS-004 | Vertragsgeschaeft | ja | belegt |
| StRS-006 | Leistungserfassung | ja | belegt |
| StRS-009 | Finanzprozesse | ja | belegt |
| StRS-010 | E-Belegaustausch | ja | belegt |
| StRS-012 | Berechtigungssteuerung | ja | belegt |
| StRS-013 | Sichere Anmeldung/API | ja | belegt |
| StRS-014 | Lizenz-/Modulsteuerung | ja | belegt |
| StRS-028 | Kundenzugangsdaten | ja | belegt |
| StRS-030 | DSGVO+Audit | ja | belegt |
**Regelprüfung:** Alle risikorelevanten Anforderungen besitzen entweder einen PRIMÄR-Beleg mit benannter durchsetzender Stelle oder sind als `[HYPOTHESE]` gekennzeichnet (betrifft SyRS-050 Mahnwesen). Kein Verstoß gegen die risikobasierte Priorisierung.