more runs before cline
This commit is contained in:
Christoph Schwörer
+615
@@ -0,0 +1,615 @@
|
||||
# Analysebericht
|
||||
|
||||
**Untersuchungsgegenstand:** c-entron ERP-Suite (Arbeitsverzeichnis `C:\DEV\MasterArbeit\QuellCode\CentronERP`)
|
||||
**Analyseart:** statische Analyse, keine Ausführung. Codebasis wurde ausschließlich gelesen.
|
||||
**Datum:** 2026-08-27
|
||||
|
||||
## Architekturüberblick (Befund aus Schritt 0)
|
||||
|
||||
Die Codebasis umfasst eine Mehrschicht-Anwendung:
|
||||
|
||||
| Schicht | Pfad | Umfang (Dateien) | Technik |
|
||||
|---|---|---|---|
|
||||
| Windows-Client (Fat Client) | `src\centron\Centron.WPF.UI` | ~4.726 .cs + XAML | WPF, DevExpress, Ribbon |
|
||||
| Web-Client „c-entron Nexus" | `src\nexus\CentronNexus` | ~756 (.cs/.razor, 460 .razor) | ASP.NET Core Blazor |
|
||||
| Geschäftslogik | `src\backend\Centron.BL` | ~85 Fachbereiche | C#/.NET |
|
||||
| Datenzugriff | `src\backend\Centron.DAO` | ~1.129 | ADO.NET/SQL |
|
||||
| Entitäten | `src\backend\Centron.Entities` | ~1.183 | POCO/DTO |
|
||||
| Webservice (REST + Legacy) | `src\webservice` | ~2.528 (Core) + Controller | ASP.NET Core, JWT |
|
||||
| Externe API-Adapter | `src\apis`, `Centron.Api.docuFORM` | 9 Projekte | REST-Clients |
|
||||
| Datenbankschema | `SSMS_DB_SCHEMA.sql` | 1.535 `CREATE TABLE` | MSSQL |
|
||||
| Deployment | `docker`, `azure`, `deployment`, `scripts` | — | Docker/Azure DevOps |
|
||||
|
||||
## Schritt 0 — Modulinventar
|
||||
|
||||
Das Inventar ist die Bezugsgröße für die Abdeckungstabelle. Es wurde vor der ersten Anforderung erstellt und wird später ergänzt, aber nicht gekürzt. Gruppierung: A1–A12 = Analyse-Cluster.
|
||||
|
||||
| Nr. | Modul / Komponente | Pfad (Hauptfundort) | Fachliche Aufgabe (ein Satz) | Cluster |
|
||||
|---|---|---|---|---|
|
||||
| M01 | Rechteverwaltung / UserRights | `src\backend\Centron.BL\Security`, `src\centron\...\Modules\Administration\RightsManagement`, `CentronRights.md` | Definition und Durchsetzung feingranularer Benutzerrechte inkl. einschränkender Rechte (nur eigene, nur eigene Filiale). | A1 |
|
||||
| M02 | Authentifizierung Webservice (JWT) | `src\webservice\Centron.Controllers\JwtAuthController.cs`, `Authorize*Attribute.cs` | Anmeldung und Autorisierung externer Zugriffe über JWT-Token und Rechte-Attribute. | A1 |
|
||||
| M03 | Zwei-Faktor-Authentifizierung | `src\backend\Centron.BL\TwoFactorAuthenticator`, `TwoFactorAuthController.cs` | Zweiter Faktor bei der Anmeldung. | A1 |
|
||||
| M04 | Passwortmanager | `src\centron\...\Modules\PasswordManager`, `Centron.BL\PasswordManagementArea` | Verwaltung von Zugangsdaten (z. B. Kundenpasswörter) im ERP. | A1 |
|
||||
| M05 | DSGVO-Funktionen | `src\centron\...\Modules\Administration\DSGVO` | Datenschutzfunktionen (Anonymisierung/Auskunft) für personenbezogene Daten. | A1 |
|
||||
| M06 | Verträge (Service/Leasing) | `Centron.BL\Finances`, `...\Modules\Finances\Contracts` | Verwaltung wiederkehrend abzurechnender Service-, Wartungs- und Leasingverträge. | A2 |
|
||||
| M07 | Automatisierte Abrechnung | `...\Modules\Finances\AutomatedBilling`, `FlatrateBilling`, `TimerBilling` | Periodische Erzeugung von Abrechnungsbelegen aus Verträgen, Flatrates und Zeitbuchungen. | A2 |
|
||||
| M08 | Mahnwesen | `...\Modules\Finances\Dunning` | Mahnläufe über offene Posten mit Mahnstufen. | A2 |
|
||||
| M09 | Offene Posten (OPOS) / Zahlungen | `...\Modules\Finances\Opos`, `Payments` | Verwaltung offener Posten und Zahlungszuordnung. | A2 |
|
||||
| M10 | Onlinebanking / FinAPI | `...\Modules\OnlineBanking`, `src\apis\Centron.APIs.FinAPI` | Abruf von Kontoumsätzen und Abgleich mit offenen Posten. | A2 |
|
||||
| M11 | Zahler & Kostenstellen | `...\Modules\PayersAndCostCenter` | Abweichende Rechnungsempfänger (Zahler) und Kostenstellenzuordnung. | A2 |
|
||||
| M12 | Buchhaltungsexport (DATEV u. a.) | `...\Modules\DataExchange\BookKeeping`, `DatevOnline2020`, `PaymentTransactions` | Übergabe von Buchungsdaten und Zahlungsverkehr an Finanzbuchhaltungssysteme. | A2 |
|
||||
| M13 | Gerätezähler (Click-Abrechnung) | `...\Modules\Finances\DeviceClickCounter` | Erfassung von Zählerständen (z. B. Druckerklicks) als Abrechnungsgrundlage. | A2 |
|
||||
| M14 | SEPA | `...\Modules\Administration\SepaContract` | SEPA-Mandate/Lastschrift-Grundlagen. | A2 |
|
||||
| M15 | Belegwesen Verkauf (Angebot→Rechnung) | `Centron.BL\Sales` (248 Dateien), `...\Modules\Sales` | Angebots-, Auftrags-, Lieferschein- und Rechnungserstellung mit Belegkette. | A3 |
|
||||
| M16 | Sonderpreise / Preisfindung | `Centron.BL\Sales`, Adressstamm-Sonderpreise | Kunden- bzw. vertragsspezifische Preisfindung. | A3 |
|
||||
| M17 | Produktmatrix | `Centron.BL\ProductMatrix`, `...\Modules\Sales\ProductMatrix` | Matrixbasierte Produkt-/Konditionszuordnung im Vertrieb. | A3 |
|
||||
| M18 | Mailing/Kampagnen Vertrieb | `...\Modules\Sales\Mailing`, `Centron.BL\Mailings` | Serienmails/Kampagnen an Kundenselektionen. | A3 |
|
||||
| M19 | E-Rechnung (XRechnung/ZUGFeRD/ebInterface) | `docs\guides\development\xrechnung.md`, `src\apis\Centron.Api.EbInterface`, `ZugferdImportController.cs` | Erzeugung und Import strukturierter elektronischer Rechnungen. | A3 |
|
||||
| M20 | Belegkonditionen | `...\Modules\Administration\ReceiptConditions` | Konfigurierbare Zu-/Abschlagskonditionen auf Belegen. | A3 |
|
||||
| M21 | Artikelstamm & Lager | `Centron.BL\Warehousing` (40), `...\Modules\Warehousing` | Artikelverwaltung, Einheiten, Materialgruppen, Lagerbestände, Inventur. | A4 |
|
||||
| M22 | Kommissionierung | `...\Modules\Warehousing\Commissioning`, `Commissions` | Zusammenstellung von Lieferungen aus Lagerbeständen. | A4 |
|
||||
| M23 | Barcode | `...\Modules\Warehousing\BarcodeManagement` | Barcodegestützte Lagerprozesse. | A4 |
|
||||
| M24 | Einkauf & Bestellvorschlag | `Centron.BL\Buying`, `Centron.BL\Purchasing`, `...\Modules\Purchasing` | Lieferantenbestellungen inkl. Bestellvorschlagsliste und Wareneingang. | A4 |
|
||||
| M25 | EDI (Lieferanten) | `Centron.BL\EDI` (27), `...\Modules\Purchasing\EDIManagement` | Elektronischer Belegaustausch mit Lieferanten/Distributoren. | A4 |
|
||||
| M26 | Versand / Logistik | `...\Modules\Logistic`, `src\apis\Centron.Api.Gls`, `Centron.Api.Shipcloud` | Versandarten, Paketlabel und Sendungsverfolgung über GLS/Shipcloud. | A4 |
|
||||
| M27 | RMA / Retouren | `...\Modules\Rma`, `Centron.BL` | Abwicklung von Rücksendungen an Kunden (SendBack) und Lieferanten (SendForth). | A4 |
|
||||
| M28 | Produktdaten-Anbindungen (Icecat, ITscope, COP, EGIS) | `src\apis\Centron.APIs.*DataAccess` | Import von Artikelstammdaten und Konditionen externer Kataloge/Distributoren. | A4 |
|
||||
| M29 | TradePool | `Centron.BL\TradePool` | Austausch/Handel von Artikeln über einen Händlerpool. | A4 |
|
||||
| M30 | Helpdesk / Ticketsystem | `Centron.BL\Helpers`, `...\Modules\Helpdesk`, `Centron.BL\ExternalHelpdesk` | Ticketverwaltung mit Kategorien, Status, Zuweisung, Eskalation. | A5 |
|
||||
| M31 | Zeiterfassung auf Tickets | `Centron.BL\Time`, `...\Modules\Helpdesk` (EDIT_TIME-Rechte) | Erfassung und Abrechnung von Arbeitszeiten auf Tickets. | A5 |
|
||||
| M32 | Checklisten | `Centron.BL\CheckListArea`, `...\Modules\Helpdesk\CentronChecklist` | Strukturierte Abarbeitungslisten an Tickets. | A5 |
|
||||
| M33 | Expected Events | `Centron.BL\ExpectedEvents`, `...\Modules\Helpdesk\ExpectedEvents` | Überwachung erwarteter Ereignisse (z. B. Backup-Meldungen) mit Alarmierung. | A5 |
|
||||
| M34 | SelfCare-Formulare | `Centron.BL\SelfCare`, `SelfCareFormsController.cs` | Endkunden-Formulare zur Selbstauskunft/Ticketanlage. | A5 |
|
||||
| M35 | Aufgabenverwaltung (TaskManager) | `Centron.BL\TaskManager`, `...\Modules\Helpdesk\TaskManagement` | Aufgaben mit Fälligkeit und Verantwortlichen, auch ticketbezogen. | A5 |
|
||||
| M36 | Umfragen (Survey) | `...\Modules\Survey` | Erstellung und Auswertung von Kundenumfragen. | A5 |
|
||||
| M37 | Ticket-Projekte | `Centron.BL\TicketProjects` | Bündelung von Tickets zu Projekten. | A5 |
|
||||
| M38 | Adress-/Kundenstamm | `Centron.BL\BusinessPartner`, `CustomerArea`, `Accounts` | Verwaltung von Kunden, Lieferanten, Ansprechpartnern und Web-Accounts. | A6 |
|
||||
| M39 | Mitarbeiterstamm | `Centron.BL\EmployeeArea`, `...\Administration\EmployeeManagement` | Mitarbeiterdaten, Abteilungen, Filialen. | A6 |
|
||||
| M40 | Geräte / Assets / Stammblätter | `Centron.BL\Devices`, `Centron.BL\ItPlanner` | Verwaltung von Kundengeräten (Drucker-Stammblätter, IT-Assets) inkl. Historie. | A6 |
|
||||
| M41 | Länder/Regionen | `Centron.BL\CountryArea` | Länderstammdaten inkl. steuerlicher Zuordnung. | A6 |
|
||||
| M42 | Tags & Custom Properties | `Centron.BL\Tags`, `Centron.BL\Customizations`, `...\Global\CustomProperties` | Freie Verschlagwortung und kundenindividuelle Zusatzfelder. | A6 |
|
||||
| M43 | Objekt-Externreferenzen | `Centron.BL\ObjectExternalReferences` | Verknüpfung von ERP-Objekten mit IDs externer Systeme. | A6 |
|
||||
| M44 | Mail (Versand/Empfang) | `Centron.BL\Mail` (20), `MailScanner` | Mailversand/-empfang, Vorlagen, automatische Zuordnung eingehender Mails. | A7 |
|
||||
| M45 | Mail-Vorlagen | `...\Administration\MailTemplates`, `docs\guides\development\create-mail-templates.md` | Platzhalterbasierte Mailvorlagen für Systemmails. | A7 |
|
||||
| M46 | Kalender / Termine | `Centron.BL\Calendar`, `AppointmentRequests`, `...\Modules\Calendar` | Terminverwaltung inkl. Terminanfragen, Exchange-Sync. | A7 |
|
||||
| M47 | Outlook-/Exchange-Integration | `Centron.BL\Outlook`, `src\nexus\CentronNexus.OutlookAddIn`, `docs\features\exchange-sync-bugprotokoll.md` | Synchronisation von Mails/Terminen mit Outlook/Exchange. | A7 |
|
||||
| M48 | Telefonie (TAPI) | `Centron.BL\Tapi`, `...\MyCentron\Telephony` | Anrufsignalisierung und Wahlhilfe am Arbeitsplatz. | A7 |
|
||||
| M49 | Chats | `Centron.BL\Chats` | Interner Chat. | A7 |
|
||||
| M50 | Benachrichtigungen | `Centron.BL\Notifications`, `NexusNotifications` | Systembenachrichtigungen an Benutzer (Client und Web). | A7 |
|
||||
| M51 | MyCentron / MyDay / ToDo | `Centron.BL\MyCentron`, `MyDay`, `ToDoArea`, `...\Modules\MyCentron` | Persönliche Startseite mit Tagesübersicht, Aufgaben, Wiedervorlagen. | A7 |
|
||||
| M52 | Social Media / VideoPortal | `Centron.BL\SocialMedia`, `VideoPortal` | Anbindung Social-Media-Kanäle und internes Videoportal. | A7 |
|
||||
| M53 | Nexus WebCart (Shop) | `src\nexus\CentronNexus\WebCart` | Webshop für Endkunden auf Basis der Sonderpreise. | A8 |
|
||||
| M54 | Nexus WebOffer | `src\nexus\CentronNexus\WebOffer` | Online-Angebotsansicht/-annahme durch Kunden. | A8 |
|
||||
| M55 | Nexus ServiceBoard | `src\nexus\CentronNexus\ServiceBoard` | Web-Ticketboard für Servicevorgänge. | A8 |
|
||||
| M56 | Nexus DocumentSigning | `src\nexus\CentronNexus\DocumentSigning` | Digitale Unterschrift von Dokumenten (Signaturpad) im Browser. | A8 |
|
||||
| M57 | Nexus Produktionsaufträge | `src\nexus\CentronNexus\ProductionOrderManagement` | Web-Sicht auf Fertigungsaufträge. | A8 |
|
||||
| M58 | REST-API (Centron.Controllers) | `src\webservice\Centron.Controllers` | REST-Endpunkte für Kunden, Aufträge, Tickets usw. mit Rechteprüfung. | A8 |
|
||||
| M59 | Legacy-Webservices | `src\webservice\Centron.WebServices.Core` (2.528 Dateien) | Umfangreiche Service-Schicht für Client-Server-Kommunikation. | A8 |
|
||||
| M60 | ConnectionManager / Hosts | `src\webservice\c-entron.misc.ConnectionManager`, `Centron.Host*` | Hosting der Dienste (Konsole, Windows-Dienst) und Verbindungsverwaltung. | A8 |
|
||||
| M61 | Mobile | `Centron.BL\Mobile` | Unterstützung mobiler Zugriffe. | A8 |
|
||||
| M62 | DocSync / docuFORM | `...\Modules\DataExchange\DocSync`, `DocuForm`, `Centron.Api.docuFORM` | Dokumenten-/Datenaustausch mit docuFORM (Geräte-/Zählerdaten). | A9 |
|
||||
| M63 | RMM-Connectors | `...\Modules\DataExchange\Rmm`, `RmmController.cs` | Anbindung von Remote-Monitoring-Systemen (Geräte-/Alarmdaten). | A9 |
|
||||
| M64 | TelekomDive | `Centron.BL`? `...\Modules\TelekomDive`, `DataExchange\TelekomDive` | Anbindung Telekom-DIVE-Portal (Aufträge/Provisionen). | A9 |
|
||||
| M65 | Datenimport/-export generisch | `...\Modules\DataExchange\DataImport`, `DataExport`, `Connectors` | Konfigurierbarer Im-/Export von Stammdaten und Belegen. | A9 |
|
||||
| M66 | Integrations / RiverDivo / CPra | `Centron.BL\Integrations`, `RiverDivo`, `CPra` | Weitere Drittsystem-Anbindungen. | A9 |
|
||||
| M67 | Gateway | `src\backend\Centron.Gateway` | Vermittlungsschicht zwischen Client und Diensten. | A9 |
|
||||
| M68 | Produktion / Fertigungsaufträge | `Centron.BL\Production`, `...\Modules\Production` | Fertigungsaufträge und Maschinenverwaltung. | A10 |
|
||||
| M69 | Projektmanagement | `Centron.BL\Projects`, `...\Modules\ProjectManagement` | Projekte mit Budgets/Auswertung. | A10 |
|
||||
| M70 | Projektpreisimport | `...\Modules\ProjectPriceImport` | Import projektspezifischer Preise mit Differenzprüfung. | A10 |
|
||||
| M71 | PLM (Product Lifecycle) | `...\Modules\PLM`, `...\Finances\ProductLifecycleManagement` | Lebenszyklusverwaltung von Produkten/Geräten. | A10 |
|
||||
| M72 | QM | `...\Modules\QM` | Qualitätsmanagement-Funktionen. | A10 |
|
||||
| M73 | Statistiken / Management-Info | `Centron.BL\Statistics` (16), `...\Modules\Statistics` | Vertriebs-, MSP- und Mitarbeiterauswertungen. | A10 |
|
||||
| M74 | Reporting / ReportEngine | `Centron.BL\ReportEngine` (26), `...\Modules\Reports`, `...\Administration\ReportServer` | Berichtserzeugung (Belegdruck, Listen) über Reportvorlagen. | A10 |
|
||||
| M75 | Massenupdates | `Centron.BL\MassUpdate`, `...\Modules\Massenupdates` | Massenänderungen an Stammdaten/Verträgen. | A10 |
|
||||
| M76 | Dashboard | `Centron.BL\DocuBoard`, `...\Modules\Dashboard`, `Statistics\Dashboard` | Konfigurierbare Kennzahlen-Dashboards. | A10 |
|
||||
| M77 | Persistenzschicht / DB-Schema | `Centron.DAO`, `Centron.Entities`, `SSMS_DB_SCHEMA.sql` (1.535 Tabellen) | Datenzugriff und relationales Schema. | A11 |
|
||||
| M78 | Volltextsuche (IndexSearch) | `Centron.BL\IndexSearch` | Indexgestützte übergreifende Suche. | A11 |
|
||||
| M79 | Änderungsverfolgung (ChangeTracking) | `Centron.BL\ChangeTracking` | Protokollierung von Datenänderungen. | A11 |
|
||||
| M80 | Dateiablage (Storage) | `Centron.BL\Storage`, `...\CentronFileSystem` | Ablage von Dokumenten/Dateien zu ERP-Objekten. | A11 |
|
||||
| M81 | Lokalisierung | `...\Centron.WPF.UI\Localization`, `ResXManager.config.xml` | Mehrsprachige Oberflächentexte (ResX). | A11 |
|
||||
| M82 | Logging / Telemetrie | `nlog.config`, `Centron.BL\Telemetry`, `...\Administration\LogViewer` | Technisches Logging und Telemetrie inkl. Log-Ansicht. | A11 |
|
||||
| M83 | KI-Funktionen | `Centron.BL\ArtificialIntelligence` (25), `...\Modules\ArtificialIntelligence` | OpenAI-gestützte Funktionen (Chat, Angebotstexte, Textbewertung). | A11 |
|
||||
| M84 | UI-Framework / Controls / GUI-Profile | `src\shared\Centron.Controls` (742), `...\Modules\Gui\Profiles` | Wiederverwendbare UI-Steuerelemente und benutzerspezifische Oberflächenprofile. | A11 |
|
||||
| M85 | Externe Tools | `Centron.BL\ExternalToolsBL`, `...\Modules\ExternalTool` | Einbindung externer Programme mit Variablenübergabe. | A11 |
|
||||
| M86 | Mandantenverwaltung | `...\Administration\MandatorManagement` | Verwaltung mehrerer Mandanten. | A12 |
|
||||
| M87 | Einstellungsverwaltung | `...\Administration\Settings`, `docs\guides\development\settings-management.md`, `CentronConfigDb` | Zentrale, hierarchische Systemeinstellungen. | A12 |
|
||||
| M88 | Textbausteine | `Centron.BL\TextModuleArea`, `...\Administration\TextBlockManagement` | Wiederverwendbare Textbausteine für Belege/Mails. | A12 |
|
||||
| M89 | Hintergrunddienste | `docs\Background Service\DataQualityService.md`, `Centron.BL\Services`, `...\Administration\Services` | Zeitgesteuerte Serverdienste (u. a. Datenqualität, Eskalation). | A12 |
|
||||
| M90 | Eskalationsregeln | `...\Administration\EscalationsSettings` | Konfigurierbare Eskalationen (z. B. Ticketfälligkeit). | A12 |
|
||||
| M91 | PDF-Export/-Signierung | `...\Administration\PdfExport`, `PdfSigning` | PDF-Erzeugung und qualifizierte Signatur von Belegen. | A12 |
|
||||
| M92 | Deployment / Betrieb | `docker`, `azure`, `deployment`, `scripts`, `Centron.Host.WindowsService` | Build-, Container- und Releaseprozesse; Betrieb als Windows-Dienst/Container. | A12 |
|
||||
| M93 | Stundenzuschlagssätze | `...\Administration\HourlySurchargeRates` | Zuschlagsregeln auf Arbeitszeiten. | A12 |
|
||||
| M94 | Update-Benachrichtigung | `...\Administration\UpdateAvailableNotificationSettings` | Hinweis auf verfügbare Programmversionen. | A12 |
|
||||
| M95 | Gutscheinverwaltung | `Centron.BL\VoucherManagement` | Verwaltung von Gutscheinen. | A2 |
|
||||
| M96 | Web-Links/URLs | `Centron.BL\Urls`, `WebLinks` | Verwaltung von Weblinks zu ERP-Objekten. | A8 |
|
||||
|
||||
*Das Inventar wurde vor der ersten Anforderung erstellt und im Laufe der Analyse ergänzt (nicht gekürzt); die Abdeckungstabelle unten führt jede Zeile mit Analysetiefe und Anforderungszahl.*
|
||||
|
||||
### Inventar-Korrekturen aus der Analyse
|
||||
|
||||
Die Detailanalyse hat die Ein-Satz-Beschreibungen bzw. Pfade folgender Module korrigiert oder präzisiert (das ursprüngliche Inventar bleibt oben unverändert stehen; maßgeblich sind die Korrekturen):
|
||||
|
||||
| Nr. | Korrektur (Kurzfassung) |
|
||||
|---|---|
|
||||
| M01 | `Centron.BL\Security` enthält nur `PdfSigningBL.cs`; die Rechte-BL liegt in `Centron.BL\Administration\Rights` (AppRightsBL), die Rechtekonstanten in `Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs`. |
|
||||
| M03 | `Centron.BL\TwoFactorAuthenticator` enthält nur die TOTP-PIN-Prüfung für den Passwortmanager; die Login-2FA (RADIUS/E-Mail-Link) liegt in `Centron.BL\Administration\Logins\TwoFactor`. |
|
||||
| M04 | Der Passwortmanager existiert doppelt: `PasswordManagementArea` (Alt) und `PasswordManager` (aktuell, AES-verschlüsselt, Siegel). |
|
||||
| M06 | Enthält zwei parallele Auswertungsmodule: `ContractEvaluation2` und `ContractEvaluationOld` (Altimplementierung). |
|
||||
| M11 | Verwaltet Kostenstellen (CostCenter) und Kostenträger (CostObject, UI „Payers") — nicht „Zahler" im Sinne abweichender Rechnungsempfänger. |
|
||||
| M15/M19/M20 | ZUGFeRD-Import liegt unter `Centron.Controllers\Controllers\v1\Receipts\`; E-Rechnungs-Generatoren in `Centron.BL\DataExchange\EDI\SaleInvoices\`; Konditions-Durchsetzung in `Centron.BL\Sales\Receipts\ReceiptBL.cs`. |
|
||||
| M27 | RMA-BL liegt in `Centron.BL\CustomerArea\RmaBL.cs`; umfasst Kundenretouren, Lieferantenrücksendungen (SendBack) und Vorab-/Ersatzlieferungen (SendForth). |
|
||||
| M31 | Ticket-Zeiterfassung liegt in `Centron.BL\Sales\Support` (HelpdeskTimerBL u. a.), nicht in `Centron.BL\Time` (dort nur TimingSettingsBL). |
|
||||
| M33 | Expected Events = kundenbezogene Überwachung erwarteter externer Ereignisse (z. B. Backup-Meldungen) mit Zeitfenstern und Textmustern; Auswertungskomponente liegt außerhalb der Codebasis. |
|
||||
| M36 | Umfrage-BL liegt in `Centron.BL\Accounts\Survey\SurveyProcessBL.cs`; Kopplung an Ticketabschluss über `HelpdeskCloseBL.AddSurvey()`. |
|
||||
| M39 | EmployeeManagement-UI liegt im WPF-Client und in `Centron.Controls`; BL in `Centron.BL\EmployeeArea`. |
|
||||
| M40 | „Stammblätter" = `MasterDataList` unter `Centron.BL\Sales\CustomerAssets\Contracts\ClickContracts`; `ItPlanner` enthält nur Checklisten-Kategorien. Kundengeräte liegen in **drei** Datenhaltungen (Stammblätter, `AccountDevices`, AssetManagement-/River-Sync). |
|
||||
| M42 | Custom-Property-Logik liegt in `Centron.BL\Administration\Customization`; `Centron.BL\Customizations\CustomTables` ist nur ein Report-Hilfsdienst. |
|
||||
| M47 | `Centron.BL\Outlook` enthält nur eine Asset-Suche für das Add-in; Exchange-Funktionalität liegt im Blazor-Add-in, `Centron.BL\Mail\Exchange` (EWS) und der Kalender-Synchronisation. |
|
||||
| M50 | Zwei getrennte Benachrichtigungssysteme: `Notifications` (System-/Adminprotokoll, externe Empfänger) und `NexusNotifications` (persönliche Mitarbeiter-Benachrichtigungen mit SignalR-Push). |
|
||||
| M52 | VideoPortal = rechtegeschützte Video-Zuweisung mit ToDo-Kopplung; SocialMedia = interner Aktivitäten-Stream auf Stored-Procedure-Basis. |
|
||||
| M53 | WebCart umfasst das gesamte Endkunden-Portal (Belege/Verträge, Tickets, Formulare, Dokumente, Zeitnachweise), nicht nur den Warenkorb. |
|
||||
| M56 | DocumentSigning (Route `/contractmanagement`) signiert beliebige PDF-Dokumente inkl. SEPA-Mandate über einmalige GUID-Links. |
|
||||
| M61 | „Mobile" ist ein 37-zeiliger Alt-Lesezugriff auf `NewMobileEmployee`/`NewMobileContactPerson`, kein Mobile-Backend. |
|
||||
| M62 | docuFORM = OAuth2-Import von Druckgeräte-Seitenzählern für die Click-Abrechnung; DocSync = davon unabhängige Dokumentbereitstellung je Objektart. |
|
||||
| M66 | „CPra" = Konnektor zum Dienst Nexoware Smartflow; EsCustomerGroups/EsRoles = lokale Caches von ElectronicSales-Webshop-Stammdaten. |
|
||||
| M69 | ProjectManagement = internes Projekt-/Auslastungsboard, hart codiert auf die Abteilung „Software-Entwicklung"; `Centron.BL\Projects` ist trivialer Altbestand. |
|
||||
| M71 | Keine Doppelimplementierung: `Modules\Finances\ProductLifecycleManagement` ist nur der Einstellungsdialog des PLM-Moduls. |
|
||||
| M76 | `Modules\Dashboard` = Modul-Startübersicht (Kacheln), kein Kennzahlen-Dashboard; `Centron.BL\DocuBoard` = Asset-Management-Stammlisten. |
|
||||
| M79 | Das eigentliche ChangeTracking liegt in `Centron.DAO\ChangeTracking` und `ChangeLogBL`; `Centron.BL\ChangeTracking` enthält nur Import-Historie. |
|
||||
| M80 | `Centron.BL\Storage` ist seit 2014 vollständig auskommentierte, obsolete Inventur-Altlogik; die Dateiablage liegt clientseitig in `CentronFileSystem` (Backend: FileManagement). |
|
||||
| M86 | Mandantenverwaltung = Firmenstammdaten/Filialen in EINER Datenbank; keine Mandantentrennung im SaaS-Sinn (kein getrennter Datenraum). |
|
||||
| M89 | Der Host betreibt ca. 35 über die Tabelle `BackgroundServices` einzeln aktivierbare Hintergrunddienste auf der Basisklasse `ManagedBackgroundService`. |
|
||||
| M95 | Gutscheinmodul = belegbasierte Statusauswertung (frei/ausgegeben/eingelöst) über `GutscheinZuRechnung`; Ausgabe/Einlösung erfolgt im Belegwesen. |
|
||||
|
||||
## Vorgehen im Lauf
|
||||
|
||||
Die Analyse folgte den Schritten 0–6 der RRE-Methodenkette: (0) Modulinventar vor der ersten Anforderung, (0b) Mindestabdeckung je Modul, (0c) Vertiefung nach Risiko (Sicherheit, Abrechnung/Fakturierung, Berechtigungen zuerst), (2) Artefakterhebung, (3) technische Analyse, (4) semantische Interpretation, (5) Formalisierung, (6) Traceability. Die 96 Inventarmodule wurden in 12 Analyse-Cluster (A1–A12) aufgeteilt und parallel durch Analyse-Subagenten bearbeitet; jeder Cluster erhielt einen eigenen ID-Nummernkreis (A1=1xx … A12=12xx). Alle PRIMÄR-Belege wurden im Quelltext bzw. im SQL-Schema tatsächlich gelesen; die Codebasis wurde ausschließlich lesend verarbeitet.
|
||||
|
||||
## Abdeckungstabelle
|
||||
|
||||
Jede Zeile des Modulinventars mit Analysetiefe und Anzahl der daraus erzeugten Anforderungen. Anforderungszahlen enthalten teilweise anteilige Zuordnungen (eine Anforderung kann mehrere Module eines Clusters tragen); Bezugsgröße ist die Abdeckungsangabe des jeweiligen Cluster-Agenten. **Kein Modul ist ohne Anforderung** (Mindestabdeckung erfüllt); kein Modul musste als `nicht analysiert` eingestuft werden.
|
||||
|
||||
| Nr. | Modul | Tiefe | Anzahl Anforderungen | Bemerkung |
|
||||
|---|---|---|---|---|
|
||||
| M01 | Rechteverwaltung/UserRights | tief | 9 | HasUserRight-Kern, Datenmodell, Gruppenverwaltung, Audit-Log |
|
||||
| M02 | Authentifizierung Webservice (JWT) | tief | 6 | JwtAuthController, Authorize-Attribute, AuthenticatorFactory |
|
||||
| M03 | Zwei-Faktor-Authentifizierung | tief | 4 | beide 2FA-Subsysteme analysiert |
|
||||
| M04 | Passwortmanager | tief | 7 | inkl. Alt-Implementierung (Hypothese SwRS-119) |
|
||||
| M05 | DSGVO-Funktionen | mittel | 5 | Kontaktlöschung/Cleanup/AVV belegt; Komplettlöschung nicht implementiert |
|
||||
| M06 | Verträge (Service/Leasing) | tief | 6 | ContractBL vollständig; Auswertungsmodule nur Controller-Ebene |
|
||||
| M07 | Automatisierte Abrechnung | tief | 7 | AutomaticFacturaBL (2.900 Zeilen) und TimerBillingBL gelesen |
|
||||
| M08 | Mahnwesen | tief | 6 | DunningBL/DunningRunBL vollständig |
|
||||
| M09 | OPOS/Zahlungen | tief | 4 | OposBL/PaymentsBL/IncomingPaymentBL vollständig |
|
||||
| M10 | Onlinebanking/FinAPI | tief | 7 | Matching-Heuristiken; Rechte-Durchsetzung als Hypothese (SwRS-248) |
|
||||
| M11 | Zahler & Kostenstellen | mittel | 1 | Belegzuordnungslogik nicht vertieft |
|
||||
| M12 | Buchhaltungsexport (DATEV u. a.) | mittel | 4 | Formatauswahl/Exportflags; Formatgeneratoren nicht im Detail |
|
||||
| M13 | Gerätezähler (Click-Abrechnung) | tief | 2 | DeviceClickCounterBL vollständig |
|
||||
| M14 | SEPA | tief | 3 | Online-Signaturprozess mit Statusmaschine |
|
||||
| M15 | Belegwesen Verkauf | tief | 24 | Belegkette, Storno, Festschreibung, Nummernkreise, MwSt; ReceiptBL (11.441 Zeilen) auszugsweise |
|
||||
| M16 | Sonderpreise/Preisfindung | tief | 5 | Preisfindungshierarchie, Mindestpreis-Override |
|
||||
| M17 | Produktmatrix | mittel | 3 | BL + Schema vollständig, UI überflogen |
|
||||
| M18 | Mailing/Kampagnen | mittel | 4 | Versandpfad nicht vertieft (Hypothese SwRS-350) |
|
||||
| M19 | E-Rechnung (XRechnung/ZUGFeRD/ebInterface) | mittel | 4 | Formatwahl/Leitweg-ID belegt; XML-Feldmapping nicht Feld für Feld |
|
||||
| M20 | Belegkonditionen | mittel | 2 | Durchsetzung am Beleg belegt |
|
||||
| M21 | Artikelstamm & Lager | tief | 14 | Rechte, Bestandsermittlung, gleitender EK, Inventur |
|
||||
| M22 | Kommissionierung | mittel | 3 | zwei parallele Implementierungen festgestellt |
|
||||
| M23 | Barcode/Seriennummern | tief | 4 | Statusmodell, Eindeutigkeit, Ausbuchung |
|
||||
| M24 | Einkauf & Bestellvorschlag | mittel | 3 | Bestellvorschlags-SQL tief; TravelExpense nur gesichtet |
|
||||
| M25 | EDI (Lieferanten) | mittel | 3 | Formatdispatcher belegt; Distributor-Parser nicht vertieft |
|
||||
| M26 | Versand/Logistik | mittel | 4 | GLS-Limits und Shipcloud-Broker belegt |
|
||||
| M27 | RMA/Retouren | mittel | 3 | Statusmaschine SaveRma tief |
|
||||
| M28 | Produktdaten-Anbindungen | flach | 2 | Icecat/ITscope/EGIS gelesen; CopDataAccess nicht analysiert |
|
||||
| M29 | TradePool | flach | 1 | fachlicher Zweck unklar (Hypothese SwRS-451) |
|
||||
| M30 | Helpdesk/Ticketsystem | tief | 12 | Statusmodell, Rechte, Fälligkeit, Eskalation, Abschluss |
|
||||
| M31 | Zeiterfassung auf Tickets | tief | 8 | serverseitige Rechte belegt; MOVE-Recht nur clientseitig |
|
||||
| M32 | Checklisten | mittel | 2 | kein hartes Abschluss-Gate gefunden |
|
||||
| M33 | Expected Events | mittel | 2 | Auswertungskomponente außerhalb der Codebasis (Hypothese SwRS-545) |
|
||||
| M34 | SelfCare | mittel | 3 | GUID-/Ablauflogik belegt |
|
||||
| M35 | TaskManager | mittel | 2 | Wiederholungsregeln, Handler, Lizenzprüfung |
|
||||
| M36 | Umfragen | mittel | 2 | Antwort-Erfassung (ServiceBoard) nicht analysiert |
|
||||
| M37 | Ticket-Projekte | flach | 1 | CRUD/Nummernkreis belegt |
|
||||
| M38 | Adress-/Kundenstamm | tief | 12 | AccountBL/WebAccountBL gelesen |
|
||||
| M39 | Mitarbeiterstamm | mittel | 5 | EmployeeBL/AppUserBL gelesen |
|
||||
| M40 | Geräte/Assets/Stammblätter | tief | 7 | Drei-Datenhaltungen-Befund dokumentiert |
|
||||
| M41 | Länder/Regionen | mittel | 2 | CountryBL/FederalStateBL vollständig |
|
||||
| M42 | Tags & Custom Properties | tief | 3 | Pflichtfeldprüfung nur clientseitig |
|
||||
| M43 | Objekt-Externreferenzen | tief | 1 | Detailregeln in SyRS-612; Tabelle fehlt im SQL-Dump |
|
||||
| M44 | Mail (Versand/Empfang), MailScanner | tief | 8 | Absender-Whitelist, VMA-Verschlüsselung |
|
||||
| M45 | Mail-Vorlagen | tief | 3 | Fallback-Hierarchie belegt |
|
||||
| M46 | Kalender/Termine | mittel | 4 | CalendarBL/AppointmentRequestBL vollständig |
|
||||
| M47 | Outlook/Exchange | mittel | 2 | Sync teils über Doku (KONTEXT) erfasst |
|
||||
| M48 | Telefonie (TAPI) | tief | 4 | PhoneCallBL/PhoneSettingsBL gelesen |
|
||||
| M49 | Chats | tief | 2 | Mitgliedschafts-Expressions belegt |
|
||||
| M50 | Benachrichtigungen | mittel | 3 | zwei Systeme (Konsolidierungskandidat) |
|
||||
| M51 | MyCentron/MyDay/ToDo | tief | 6 | Rechteprüfungen FREMDTODOLISTE belegt |
|
||||
| M52 | Social Media / VideoPortal | mittel | 3 | SocialMedia-Logik in Stored Procedures (Hypothese SwRS-748) |
|
||||
| M53 | Nexus WebCart | tief | 5 | Freigabewesen bis in die BL verfolgt |
|
||||
| M54 | Nexus WebOffer | mittel | 2 | Token-Flow und Zustandsmodell |
|
||||
| M55 | Nexus ServiceBoard | mittel | 3 | CloseTicket/Auth vertieft; Kanban/Scheduler strukturell |
|
||||
| M56 | Nexus DocumentSigning | mittel | 2 | Signaturseite und DsgvoBL vollständig |
|
||||
| M57 | Nexus Produktionsaufträge | mittel | 2 | Auth-Lücke als Hypothese (SwRS-848) |
|
||||
| M58 | REST-API (Centron.Controllers) | tief | 10 | alle Authorization-Klassen und Filter gelesen |
|
||||
| M59 | Legacy-Webservices | flach | 2 | 2.530 Dateien, vereinbarungsgemäß nur strukturell |
|
||||
| M60 | ConnectionManager/Hosts | mittel | 2 | beide Host-Einstiege gelesen |
|
||||
| M61 | Mobile | tief | 1 | Modul vollständig (37 Zeilen), Altbestand |
|
||||
| M62 | DocSync/docuFORM | mittel | 4 | Tokenfluss und Importablauf gelesen |
|
||||
| M63 | RMM-Connectors | tief | 8 | RmmController/RiverDivoBL/DocBee-BLs vollständig |
|
||||
| M64 | TelekomDive | mittel | 3 | Export-ViewModel und BL gelesen |
|
||||
| M65 | Datenimport/-export generisch | flach | 2 | Kontenimport belegt; InvoiceUpload ist leerer Stub |
|
||||
| M66 | Integrations/RiverDivo/CPra | mittel | 5 | EsRoleBL nur Kopf geprüft |
|
||||
| M67 | Gateway | flach | 2 | Struktur inventarisiert, Adapter nicht im Detail |
|
||||
| M68 | Produktion | tief | 4 | Statusmodell, Logkatalog, Schema |
|
||||
| M69 | Projektmanagement | mittel | 2 | interner Sonderfall (hart codierte Abteilung) |
|
||||
| M70 | Projektpreisimport | mittel | 1 | Import-/Differenzlogik gelesen |
|
||||
| M71 | PLM | tief | 3 | Konsolidierungsfrage geklärt (keine Doppelimplementierung) |
|
||||
| M72 | QM | mittel | 2 | Durchsetzung in ReceiptBL/CustomerAssetBL |
|
||||
| M73 | Statistiken | tief | 6 | Rechte-/Abrechnungslogik (MSP) im Fokus |
|
||||
| M74 | Reporting/ReportEngine | tief | 5 | doppelte Berichts-Datenhaltung belegt |
|
||||
| M75 | Massenupdates | tief | 3 | alle vier Start-Pfade gesichtet |
|
||||
| M76 | Dashboard/DocuBoard | mittel | 2 | drei DocuBoard-BLs vollständig |
|
||||
| M77 | Persistenzschicht/DB-Schema | tief | 6 | Transaktionen, Listener, Konventionen, Constraints |
|
||||
| M78 | Volltextsuche (IndexSearch) | tief | 4 | alle Kerndateien + Schema |
|
||||
| M79 | ChangeTracking | mittel | 4 | Attribut-Mechanismus ungenutzt (Befund) |
|
||||
| M80 | Dateiablage | mittel | 2 | BL\Storage als obsolet eingestuft; Server-BL als Hypothese (SyRS-1119) |
|
||||
| M81 | Lokalisierung | mittel | 2 | LocalizationHelper vollständig |
|
||||
| M82 | Logging/Telemetrie | tief | 4 | TelemetryBL vollständig; Schema-Drift festgestellt |
|
||||
| M83 | KI-Funktionen | mittel | 3 | SSRF-Schutz und Schlüssel-Verschlüsselung belegt |
|
||||
| M84 | UI-Framework/GUI-Profile | mittel | 2 | Controls strukturell; Profil-Rechtelogik tief |
|
||||
| M85 | Externe Tools | mittel | 2 | BL vollständig |
|
||||
| M86 | Mandantenverwaltung | tief | 6 | serverseitige Rechteprüfung offen (Hypothese SwRS-1233) |
|
||||
| M87 | Einstellungsverwaltung | tief | 5 | beide Settings-Tabellen (Stammdat/ApplicationSettings) |
|
||||
| M88 | Textbausteine | mittel | 3 | TextModuleBL vollständig |
|
||||
| M89 | Hintergrunddienste | tief | 4 | ~35 Dienste auf gemeinsamer Basisklasse |
|
||||
| M90 | Eskalationsregeln | mittel | 2 | Kernberechnung DoEscalation nicht gelesen |
|
||||
| M91 | PDF-Export/-Signierung | tief | 5 | PdfSigningBL vollständig |
|
||||
| M92 | Deployment/Betrieb | mittel | 2 | Docker/Compose/Windows-Dienst gelesen |
|
||||
| M93 | Stundenzuschlagssätze | mittel | 2 | serverseitige BL nicht gelesen |
|
||||
| M94 | Update-Benachrichtigung | mittel | 2 | Versions- und Zielgruppenlogik gelesen |
|
||||
| M95 | Gutscheinverwaltung | mittel | 1 | NamedQuery vollständig analysiert |
|
||||
| M96 | Web-Links/URLs | mittel | 1 | SimpleUrl vs. WebLink (Konsolidierungskandidat) |
|
||||
|
||||
**Zusammenfassung der Analysetiefe:** 42 Module tief, 48 Module mittel, 6 Module flach (M28, M29, M37, M59, M65, M67), 0 Module nicht analysiert. Zusätzlich wurden Querschnittsthemen ohne eigene Inventarzeile erfasst (Login/Sessions, Architektur-Schichtung, Heartbeat, Teststrategie, Profiling, SqlManagers).
|
||||
|
||||
## Konsistenzcheck über das gesamte Anforderungs-Set
|
||||
|
||||
Der Check wurde skriptgestützt über alle 413 Anforderungsblöcke (StRS.md, SyRS.md, SwRS.md) ausgeführt.
|
||||
|
||||
| Prüfung | Ergebnis |
|
||||
|---|---|
|
||||
| Anforderungen gesamt | **413** (50 StRS, 122 SyRS, 241 SwRS) |
|
||||
| Doppelte oder mehrfach vergebene IDs | **keine** (413 eindeutige IDs; Hinweis: SwRS-240 wurde nicht vergeben — dokumentierte Lücke im Nummernkreis A2, kein fehlender Inhalt) |
|
||||
| Anforderungen ohne Beleg | **keine** (jede Anforderung führt mindestens einen klassifizierten Beleg mit Begründung) |
|
||||
| Anforderungen ohne Prüfidee | **keine** |
|
||||
| Anforderungen ohne Angabe zur Übernahmewürdigkeit | **keine** |
|
||||
| Tracelinks auf nicht existierende IDs | **keine** (alle referenzierten IDs existieren) |
|
||||
| Anforderungen ohne Tracelinks | **keine** |
|
||||
| Nicht-funktionale Anforderungen ohne ISO-25010-`Qualitätsmerkmal` | **keine** (21 nicht-funktionale Anforderungen, alle mit Merkmal) |
|
||||
| Status-Verteilung | 397 `belegt`, 16 `HYPOTHESE` (3,9 %) |
|
||||
| Abgleich `Hypothesen.md` gegen Inline-Markierungen | **deckungsgleich**: beide Seiten nennen exakt dieselben 16 IDs (SyRS-110, SyRS-1119; SwRS-119, 248, 350, 354, 451, 545, 637, 740, 748, 848, 947, 1043, 1147, 1233); `Hypothesen.md` enthält keine zusätzlichen freien Fragen |
|
||||
| Konsolidierungskandidaten | 44 Anforderungen (10,7 %) mit `Konsolidierung: Kandidat` |
|
||||
| Risikoanforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) | **198**; jede trägt entweder mindestens einen `PRIMÄR`-Beleg mit durchsetzender Stelle oder ist als `HYPOTHESE` gekennzeichnet — **0 Verstöße** gegen die risikobasierte Priorisierung (skriptgeprüft) |
|
||||
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung | keine gefunden; die bekannten Doppelimplementierungen (siehe Konsolidierungsübersicht) sind in den betroffenen Anforderungen als Kandidat markiert. Restrisiko: clusterübergreifende Dubletten wurden über die Meta-Abgleiche geprüft, eine paarweise Volltextprüfung aller 413 Anforderungen fand nicht statt |
|
||||
|
||||
### Konsolidierungsübersicht (fachlich gleichartige Konzepte in getrennten Implementierungen)
|
||||
|
||||
Wichtigste clusterübergreifend bestätigte bzw. vermutete Konsolidierungsfälle für das Zielsystem:
|
||||
|
||||
1. **Kundengeräte in drei Datenhaltungen** (bestätigt): „Stammblätter" `MasterDataList` (Drucker mit Klickzählern), `AccountDevices` (sonstige Hardware), AssetManagement-/River-Sync-Geräte — der im Auftrag genannte Fall, um eine dritte Datenhaltung erweitert.
|
||||
2. **Zwei Berechtigungssysteme**: `Sichrech`/`Sichtrus`/`Sichmemb` (AppUser) vs. `WebRights`/`WebAccountsRights` (WebAccounts); dazu doppelter API-Zugriffsschutz (REST-Attributfilter vs. Legacy-`AuthenticateInterceptor`).
|
||||
3. **Zwei 2FA-Subsysteme** (Login-2FA RADIUS/E-Mail vs. TOTP-PIN des Passwortmanagers) und **zwei Passwortmanager-Implementierungen** (alt/neu).
|
||||
4. **Zahlungsausgleich doppelt**: IncomingPayments vs. OnlineBanking-Zuordnungen, beide über `UpdateReceiptIsPaid`; **Kostenstellen doppelt**: `Warehousing.CostCenter` vs. `Accounts.CustomerCostCenter`.
|
||||
5. **Vertragsauswertung doppelt** (ContractEvaluation2 vs. „_old"); **Berichts-Datenhaltung doppelt** (`dbo.Reports` vs. `dbo.ReportData`); **Einstellungs-Datenhaltung doppelt** (`Stammdat` vs. `ApplicationSettings`).
|
||||
6. **Drei E-Rechnungs-Generatoren** (ZUGFeRD/XInvoice, ebInterface, Gateway `ZUGFeRD21_Extended`); **Beleg-Summenlogik doppelt** (`ReceiptPriceHelper` vs. `CalculationUtils`).
|
||||
7. **Lager/Logistik intern**: Inventur alt/neu, Kommissionierung (`CommissioningBL` vs. `OrderCommissionBL`), `BarCode` vs. `BarCode2`, GLS-Direktanbindung vs. Shipcloud-Broker, RMA-Alt-Tabellen; **duale Bestandsermittlung** (Seriennummernzählung vs. Mengenfeld, Regel doppelt in SQL und C#).
|
||||
8. **Kommunikation**: zwei Benachrichtigungssysteme (`Notifications` vs. `NexusNotifications`), zwei Kalender-Sync-Pfade (EWS vs. Graph), zwei Anrufjournal-Befüllungen (TAPI vs. Teams-CallRecords), Mail-Body-Aufbau doppelt (`FillMailBodyOld`/`New`).
|
||||
9. **Externe Referenzen dreifach** (generische `ObjectExternalReference`, `RiverbirdCustomerReference`, `EsCustomerGroup.ExternalId`); **„externes Ereignis → Ticket" dreifach** (RiverDivo, DocBee-Timer, DocBee-Creation).
|
||||
10. **Weitere**: `SimpleUrl` vs. `WebLink`, `NewMobileEmployee` vs. Mitarbeiterstamm, zwei tokenbasierte Dokumentsignatur-Pfade (DocumentSigning vs. Office/SharedDocument), Adress-Doppelhaltung neu (`AccountAddresses`) vs. alt (`Anschrif`/`Address`), Entitäten `Mandator`/`Mandatory` auf derselben Tabelle `Mandant`, TicketProjects neben allgemeinem Projektmodul, Rechte-Doku doppelt (`CentronRights.md` vs. `Sichrech.Beschreibung`).
|
||||
|
||||
## Liste aller risikorelevanten Anforderungen
|
||||
|
||||
Alle 198 Anforderungen zu Sicherheit, Abrechnung/Fakturierung und Berechtigungen mit ihrer Belegsituation (skriptgeprüft: jede Zeile hat `PRIMÄR = ja` oder `Status = HYPOTHESE`). Vollständige Titel und Belege in StRS.md/SyRS.md/SwRS.md.
|
||||
|
||||
### A1 — Sicherheit, Identität, Berechtigungen (37)
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| StRS-101 | Rollenbasierte Zugriffskontrolle für alle Fachfunktionen | ja | belegt |
|
||||
| StRS-102 | Gesicherte Anmeldung für interne Benutzer und Kunden | ja | belegt |
|
||||
| StRS-103 | Schutz und Nachvollziehbarkeit von Kundenzugangsdaten | ja | belegt |
|
||||
| StRS-104 | DSGVO-konforme Löschung und Bereinigung personenbezogener Daten | ja | belegt |
|
||||
| SyRS-101 | Durchgängige Berechtigungsprüfung an allen Systemschnittstellen | ja | belegt |
|
||||
| SyRS-102 | Administrierbarkeit des Rechtesystems mit Protokollierung | ja | belegt |
|
||||
| SyRS-103 | Sitzungsverwaltung über Tickets mit begrenzter Lebensdauer | ja | belegt |
|
||||
| SyRS-104 | Konfigurierbare Authentifizierungsverfahren mit benutzerbezogenem Fallback | ja | belegt |
|
||||
| SyRS-105 | Zwei-Faktor-Authentifizierung systemweit zuschaltbar | ja | belegt |
|
||||
| SyRS-106 | Getrennte Identitäten AppUser/WebAccount | ja | belegt |
|
||||
| SyRS-107 | Kontodeaktivierung verhindert Anmeldung | ja | belegt |
|
||||
| SyRS-108 | Passwortmanager mit Lizenz-, Richtlinien- und Protokollpflicht | ja | belegt |
|
||||
| SyRS-109 | DSGVO-Funktionen nur mit dediziertem Recht | ja | belegt |
|
||||
| SyRS-110 | Serverseitige Durchsetzung aller UI-Rechte | nein | HYPOTHESE |
|
||||
| SwRS-101 | Benutzerrechtsprüfung über Gruppenmitgliedschaft | ja | belegt |
|
||||
| SwRS-102 | Rechte-Datenmodell und zentrale Rechtekonstanten | ja | belegt |
|
||||
| SwRS-103 | Rechtegruppenverwaltung mit Admin-Gruppen-Schutz | ja | belegt |
|
||||
| SwRS-104 | Protokollierung aller Rechteänderungen | ja | belegt |
|
||||
| SwRS-105 | REST-Autorisierung über Rechte-Attribute (401/403) | ja | belegt |
|
||||
| SwRS-106 | JWT-/OIDC-Login mit Subject-Zuordnung | ja | belegt |
|
||||
| SwRS-107 | Basic-Auth über SHA1-Passworthash | ja | belegt |
|
||||
| SwRS-108 | Abweisung deaktivierter Konten | ja | belegt |
|
||||
| SwRS-109 | Ticket-Lebensdauer und Verlängerung | ja | belegt |
|
||||
| SwRS-110 | Passwortänderung mit Ist-Passwort-Prüfung und Mindestlänge | ja | belegt |
|
||||
| SwRS-111 | Web-Account-Login mit Aktivitätskette | ja | belegt |
|
||||
| SwRS-112 | Entscheidungslogik Zwei-Faktor-Bestätigung | ja | belegt |
|
||||
| SwRS-113 | E-Mail-Link-Zweitfaktor mit Einmalcode | ja | belegt |
|
||||
| SwRS-114 | TOTP-PIN-Prüfung für Passwortmanager | ja | belegt |
|
||||
| SwRS-115 | Passwortmanager-Rechteprüfungen | ja | belegt |
|
||||
| SwRS-116 | Export von Zugangsdaten nur mit Exportrecht | ja | belegt |
|
||||
| SwRS-117 | AES-Verschlüsselung mit Masterkey und Fallback-Schlüssel | ja | belegt |
|
||||
| SwRS-118 | Siegelbruch mit Recht, Kommentar, Protokoll, Mail | ja | belegt |
|
||||
| SwRS-119 | Alt-Passwortverwaltung ohne wirksame Verschlüsselung | teilweise | HYPOTHESE |
|
||||
| SwRS-120 | DSGVO-Kontaktlöschung mit Löschprotokoll | ja | belegt |
|
||||
| SwRS-121 | DSGVO-Datenbereinigung und Modulzugang | ja | belegt |
|
||||
| SwRS-122 | AVV-Verwaltung mit eigenen Rechten | ja | belegt |
|
||||
| SwRS-1233 | Serverseitige Rechteprüfung beim Speichern von Mandantenstammdaten (A12) | nein | HYPOTHESE |
|
||||
|
||||
### A2 — Finanzen & Abrechnung (44)
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| StRS-201 | Wiederkehrende vertragsbasierte Abrechnung | ja | belegt |
|
||||
| StRS-202 | Forderungsmanagement und Zahlungsabgleich | ja | belegt |
|
||||
| StRS-203 | Ordnungsgemäße Übergabe an die Finanzbuchhaltung | ja | belegt |
|
||||
| StRS-204 | Digitale SEPA-Mandatsverwaltung | ja | belegt |
|
||||
| StRS-205 | Zugriffsschutz auf Finanzfunktionen | ja | belegt |
|
||||
| SyRS-206 | Abrechnungsintervalle und Zeitraumfortschreibung | ja | belegt |
|
||||
| SyRS-207 | Verknüpfung Rechnung–Vertrag und Kontingentbuchung | ja | belegt |
|
||||
| SyRS-208 | Vertragslebenszyklus | ja | belegt |
|
||||
| SyRS-209 | Click-/Zählerabrechnung | ja | belegt |
|
||||
| SyRS-210 | Abrechnung von Ticketzeiten | ja | belegt |
|
||||
| SyRS-211 | Mahn- und OPOS-Läufe mit Versand | ja | belegt |
|
||||
| SyRS-212 | OPOS-/Mahnübersicht mit Salden | ja | belegt |
|
||||
| SyRS-213 | Zahlungseingänge und Rechnungsausgleich | ja | belegt |
|
||||
| SyRS-214 | Bankauszugsimport und Zahlungsabgleich | ja | belegt |
|
||||
| SyRS-215 | Externe Schnittstelle finAPI | ja | belegt |
|
||||
| SyRS-216 | Multiformat-Buchhaltungsexport | ja | belegt |
|
||||
| SyRS-217 | SEPA-Mandat-Onlineprozess | ja | belegt |
|
||||
| SyRS-218 | Serverseitige Rechte-/Lizenzprüfung | ja | belegt |
|
||||
| SwRS-230 | Vertragsende-Berechnung | ja | belegt |
|
||||
| SwRS-231 | Automatischer Vertragsabschluss | ja | belegt |
|
||||
| SwRS-232 | Kontingentrest-Formel | ja | belegt |
|
||||
| SwRS-233 | Abrechnungstermin/Normierung | ja | belegt |
|
||||
| SwRS-234 | Kontingentbuchung abweichende Intervalle | ja | belegt |
|
||||
| SwRS-235 | Vertragsauswahl Abrechnungslauf | ja | belegt |
|
||||
| SwRS-236 | Folge-ToDo nach Abrechnung | ja | belegt |
|
||||
| SwRS-237 | Mahnstufen-Statusmaschine | ja | belegt |
|
||||
| SwRS-238 | Mahnlauf-Protokoll | ja | belegt |
|
||||
| SwRS-239 | Mahnreife (Sperre/Fälligkeit) | ja | belegt |
|
||||
| SwRS-241 | Versandvoraussetzungen Mahn-E-Mail | ja | belegt |
|
||||
| SwRS-242 | Zahlungseingang löschen (Rechte/Rückrechnung) | ja | belegt |
|
||||
| SwRS-243 | OPOS-Saldenformel | ja | belegt |
|
||||
| SwRS-244 | Duplikaterkennung Umsatzimport | ja | belegt |
|
||||
| SwRS-245 | Abschlussstatus mit Toleranz | ja | belegt |
|
||||
| SwRS-246 | Matching-Heuristiken | ja | belegt |
|
||||
| SwRS-247 | Buchung/Chargeback/Storno | ja | belegt |
|
||||
| SwRS-248 | Kontoauszugs-Rechte serverseitig | nein | HYPOTHESE |
|
||||
| SwRS-249 | Export-Doppelschutz | ja | belegt |
|
||||
| SwRS-250 | Steuer-Mapping Export | ja | belegt |
|
||||
| SwRS-251 | Zählerhistorie/Monotonie | ja | belegt |
|
||||
| SwRS-252 | SEPA-Mandatsdaten | ja | belegt |
|
||||
| SwRS-253 | Kostenstellen/Kostenträger Soft-Delete | ja | belegt |
|
||||
| SwRS-254 | Editierschutz Ticketzeiten | ja | belegt |
|
||||
| SwRS-255 | Gutschein-Lebenszyklus | ja | belegt |
|
||||
| SwRS-1246 | Validierung/Log der Stundenzuschlagssätze (A12) | ja | belegt |
|
||||
|
||||
### A3 — Vertrieb & Belegwesen (22)
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| StRS-302 | Korrekte und revisionssichere Fakturierung | ja | belegt |
|
||||
| SyRS-312 | Belegnummernvergabe aus konfigurierbaren Nummernkreisen | ja | belegt |
|
||||
| SyRS-313 | Mehrwertsteuerberechnung je Steuersatz mit definierter Rundung | ja | belegt |
|
||||
| SyRS-314 | Revisionssichere Rechnung: Storno und Festschreibung | ja | belegt |
|
||||
| SyRS-315 | Berechtigungsprüfung im Belegwesen | ja | belegt |
|
||||
| SyRS-316 | Forderungsüberwachung: Mahnwesen und Kreditlimit | ja | belegt |
|
||||
| SyRS-317 | Automatische Preisfindung mit Schutz des Mindestpreises | ja | belegt |
|
||||
| SyRS-318 | E-Rechnungs-Export und -Import | ja | belegt |
|
||||
| SwRS-334 | Nebenläufigkeitssichere Nummernvergabe | ja | belegt |
|
||||
| SwRS-336 | MwSt-Splitting und Rundungsregeln | ja | belegt |
|
||||
| SwRS-337 | MwSt-Pflichtprüfungen beim Belegspeichern | ja | belegt |
|
||||
| SwRS-338 | Stornoregeln für Rechnungen | ja | belegt |
|
||||
| SwRS-339 | Rechnungsfestschreibung mit Protokollierung | ja | belegt |
|
||||
| SwRS-340 | Belegart-spezifische Rechteprüfungen inkl. Filialbindung | ja | belegt |
|
||||
| SwRS-341 | Mahnstufen-Statusmaschine und Neuanlagesperre | ja | belegt |
|
||||
| SwRS-342 | Kreditlimitprüfung beim Speichern | ja | belegt |
|
||||
| SwRS-347 | Mindestpreis-Übersteuerung nur durch berechtigten Benutzer | ja | belegt |
|
||||
| SwRS-350 | Werbesperre beim Mailingversand | nein | HYPOTHESE |
|
||||
| SwRS-351 | E-Rechnungs-Formatauswahl und Dateierzeugung | ja | belegt |
|
||||
| SwRS-352 | Authentifizierter ZUGFeRD-Parse-Endpunkt | ja | belegt |
|
||||
| SwRS-353 | Konditionstexte am Beleg (Zahlungskonditionen) | ja | belegt |
|
||||
| SwRS-354 | Manueller Storno für Nicht-Rechnungsbelege | nein | HYPOTHESE |
|
||||
|
||||
### A4 — Artikel, Lager, Einkauf, Logistik (7)
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| SyRS-411 | Berechtigungsmodell für Artikelpflege und Lagerbuchungen | ja | belegt |
|
||||
| SyRS-412 | Lückenlose Protokollierung aller Bestandsänderungen | ja | belegt |
|
||||
| SyRS-419 | Berechtigungsgeschützte Kommissionierung mit Mengenrückmeldung | ja | belegt |
|
||||
| SwRS-430 | Feingranulare Rechteprüfung beim Artikelspeichern | ja | belegt |
|
||||
| SwRS-432 | Gleitender Einkaufspreis bei Wareneingang | ja | belegt |
|
||||
| SwRS-433 | Lagerumbuchung nur mit Recht TRANSFER_STOCK | ja | belegt |
|
||||
| SwRS-439 | Zugriffsschutz des Kommissioniermoduls | ja | belegt |
|
||||
|
||||
### A5 — Helpdesk & Service (15)
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| StRS-502 | Abrechnungsfähige und rechtssichere Zeiterfassung auf Tickets | ja | belegt |
|
||||
| SyRS-512 | Berechtigungsgeprüfte Ticketbearbeitung (intern und Web-Accounts) | ja | belegt |
|
||||
| SyRS-513 | Fälligkeitsberechnung aus Priorität, geschütztes Fälligkeitsdatum | ja | belegt |
|
||||
| SyRS-515 | Rechte- und Sperrkonzept der Ticket-Zeiterfassung | ja | belegt |
|
||||
| SyRS-516 | Kundenunterschrift auf erbrachten Zeiten | ja | belegt |
|
||||
| SyRS-517 | Automatische Ticketerzeugung durch den TaskManager | ja | belegt |
|
||||
| SyRS-518 | Zeitlich begrenzte SelfCare-Formularlinks | ja | belegt |
|
||||
| SwRS-533 | Serverseitige Rechteprüfung beim Ticket-Speichern | ja | belegt |
|
||||
| SwRS-534 | Rechteprüfung für Portal-Web-Accounts mit Eigentümerbindung | ja | belegt |
|
||||
| SwRS-538 | Zeiten speichern nur mit EDIT_TIME, Eigenzeiten-Beschränkung, Belegsperre | ja | belegt |
|
||||
| SwRS-539 | Zeiten löschen mit DELETE_HELPDESK_TIMER, Belegsperre, Historie | ja | belegt |
|
||||
| SwRS-541 | Unterschrift entfernen nur mit DELETE_HELPDESK_SIGNATURE | ja | belegt |
|
||||
| SwRS-542 | Zeiten verschieben mit mehrstufiger Prüfkette (MOVE-Recht nur clientseitig) | ja | belegt |
|
||||
| SwRS-546 | SelfCare-Webformulare: GUID, Ablauf, Formulardefinitionen | ja | belegt |
|
||||
| SwRS-547 | TaskManager: Wiederholungsregeln, Handler-Dispatch, automatische Tickets | ja | belegt |
|
||||
|
||||
### A6 — Stammdaten & Assets (10)
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| SyRS-605 | Berechtigungsprüfung aller Geschäftspartner-Operationen | ja | belegt |
|
||||
| SyRS-607 | Systemweit eindeutige Benutzer-Logins über Kontoarten hinweg | ja | belegt |
|
||||
| SyRS-608 | Geschützte Mitarbeiterverwaltung mit automatischer Personalakte | ja | belegt |
|
||||
| SwRS-620 | Operationsbezogene Rechteprüfung in AccountBL inkl. Betreuer-Einschränkung | ja | belegt |
|
||||
| SwRS-624 | Feldbezogene Rechte für Adresssprache/-währung mit Wertrücksetzung | ja | belegt |
|
||||
| SwRS-625 | Ansprechpartnerpflege mit rollenabhängigen Rechten | ja | belegt |
|
||||
| SwRS-627 | Dublettenprüfung von Logins und OpenID-Kennungen | ja | belegt |
|
||||
| SwRS-628 | Mitarbeiterspeicherung mit Rechteprüfung und Personalakten-Ordnern | ja | belegt |
|
||||
| SwRS-631 | Seriennummernwechsel am Stammblatt nur ohne aktive Klickzähler | ja | belegt |
|
||||
| SwRS-637 | Berechtigungsprüfung der Kundengeräteverwaltung (Negativbefund) | nein | HYPOTHESE |
|
||||
|
||||
### A7 — Kommunikation & Organisation (9)
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| SyRS-712 | Freischaltung von Absenderadressen beim Mailversand | ja | belegt |
|
||||
| SyRS-714 | Virtual Mail Assistant: Zugriffsschutz, verschlüsselte Zugangsdaten | ja | belegt |
|
||||
| SyRS-719 | Tagesabschluss- und Aufgabenverwaltung (Berechtigungslogik) | ja | belegt |
|
||||
| SwRS-738 | MailScanner-Profile: Rechteprüfung und Master-Key-Verschlüsselung | ja | belegt |
|
||||
| SwRS-742 | Teams-CallRecords-Sync (Lizenzprüfung) | ja | belegt |
|
||||
| SwRS-743 | Chat: mitgliedschaftsbasierte Zugriffskontrolle | ja | belegt |
|
||||
| SwRS-744 | NexusNotification-Massenoperationen nur auf eigene Einträge | ja | belegt |
|
||||
| SwRS-745 | ToDo-Fremdzugriffs-Rechte | ja | belegt |
|
||||
| SwRS-747 | VideoPortal-Zuweisung nur mit Recht | ja | belegt |
|
||||
|
||||
### A8 — Web-Client Nexus & Service-Schnittstellen (20)
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| StRS-803 | Abgesicherte Service-Schnittstellen für Clients und Integrationen | ja | belegt |
|
||||
| SyRS-811 | Policy-basierter Zugriffsschutz (LoginType, Rechte, Lizenz, Port) in Nexus | ja | belegt |
|
||||
| SyRS-812 | Mehrstufiges Freigabewesen für Warenkörbe im WebCart | ja | belegt |
|
||||
| SyRS-813 | Token-basierte Angebotsannahme (WebOffer) | ja | belegt |
|
||||
| SyRS-814 | Online-Signatur von Dokumenten über einmaligen GUID-Link | ja | belegt |
|
||||
| SyRS-815 | Sichtbarkeitsbeschränkung von Portal-Tickets auf den eigenen Kunden | ja | belegt |
|
||||
| SyRS-817 | REST-API: JWT-Authentifizierung, Benutzerrechte, 401/403-Semantik | ja | belegt |
|
||||
| SyRS-818 | Legacy-API: Pflicht-Authentifizierung per Ticket oder Access-Token | ja | belegt |
|
||||
| SwRS-831 | UserRight-Autorisierungsfilter (Einzel-, Any-, All-Semantik) | ja | belegt |
|
||||
| SwRS-832 | Hosted-only-Endpunkte über Lizenz CentronInternal | ja | belegt |
|
||||
| SwRS-833 | JwtAuthController: OpenID-Connect-Login und Kontoverknüpfung | ja | belegt |
|
||||
| SwRS-834 | 2FA-Code-Validierung über anonymen Bestätigungslink | ja | belegt |
|
||||
| SwRS-835 | Rechteprüfung WEBACCOUNT_MANAGEMENT in der WebAccount-BL | ja | belegt |
|
||||
| SwRS-836 | Interceptor-basierte Ticket-/Access-Token-Prüfung mit Sperren | ja | belegt |
|
||||
| SwRS-839 | ClaimsService: Rechte/Web-Rechte/Lizenzen als Rollen-Claims | ja | belegt |
|
||||
| SwRS-840 | PortHandler: getrennte Ports für Host- und Kundenportal-Bereich | ja | belegt |
|
||||
| SwRS-841 | ReceiptCart-Guards: Lizenz, Web-Account-Recht, Kartenzugriff | ja | belegt |
|
||||
| SwRS-842 | OrdererApproveCart: Pflichtfelder, Statuswechsel, Auftragserzeugung | ja | belegt |
|
||||
| SwRS-845 | HelpdeskSearchBL: Expression-Filter für Web-Account-Logins | ja | belegt |
|
||||
| SwRS-848 | Produktionsübersicht ohne deklarativen Autorisierungsschutz (Negativbefund) | nein | HYPOTHESE |
|
||||
|
||||
### A9 — Datenaustausch & Integrationen (10)
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| SyRS-911 | Zugriffsschutz der RMM-REST-Schnittstelle per Zugriffsschlüssel | ja | belegt |
|
||||
| SyRS-912 | Integrations-Zugangsdaten nur mit Admin-Recht, verschlüsselte Ablage | ja | belegt |
|
||||
| SyRS-918 | Kundenisolation beim Datenabruf über Web-Zugänge | ja | belegt |
|
||||
| SwRS-931 | Zeitkonstante Prüfung des RMM-Zugriffsschlüssels | ja | belegt |
|
||||
| SwRS-932 | RMM-Einstellungen: Rechteprüfung und AES-Verschlüsselung | ja | belegt |
|
||||
| SwRS-936 | Idempotente DocBee-Zeitbuchungsübernahme mit Abrechnungssteuerung | ja | belegt |
|
||||
| SwRS-937 | DocBee-Konnektor: Aktivierung über Lizenz/Recht | ja | belegt |
|
||||
| SwRS-938 | docuFORM-Zugangsdaten mit Masterkey-Verschlüsselung | ja | belegt |
|
||||
| SwRS-939 | Gerätezähler-Import von docuFORM (abrechnungsrelevant) | ja | belegt |
|
||||
| SwRS-947 | Berechtigungsschutz Pflege Integrationsstammdaten (Negativbefund) | nein | HYPOTHESE |
|
||||
|
||||
### A10 — Produktion, Projekte, Statistik, Reporting (11)
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| SyRS-1010 | Lizenzgate für alle Produktionsfunktionen | ja | belegt |
|
||||
| SyRS-1012 | Rechtebasierter Zugriff auf Statistiken und Kennzahlen | ja | belegt |
|
||||
| SyRS-1014 | Ad-hoc-SQL-Ausführung nur mit Administrationsrecht | ja | belegt |
|
||||
| SyRS-1017 | MSP-Nutzungsimport und Vertragsabgleich (Abrechnung) | ja | belegt |
|
||||
| SwRS-1037 | Verkaufsstatistik: Rechte, Filiallimitierung, Web-Account-Schutz | ja | belegt |
|
||||
| SwRS-1038 | Management-Info-Kennzahlen mit Filialbeschränkung | ja | belegt |
|
||||
| SwRS-1039 | MSP-Import: Schemata, Duplikatschutz, verschlüsselte Zugangsdaten | ja | belegt |
|
||||
| SwRS-1040 | MSP-Evaluation: Vertragsanpassung mit Historie | ja | belegt |
|
||||
| SwRS-1041 | ReportEngine-Abfrageausführung mit Variablenersetzung | ja | belegt |
|
||||
| SwRS-1044 | Beleg-Massenpreisupdate (Abrechnungsschutzregeln) | ja | belegt |
|
||||
| SwRS-1045 | Artikel-/Kontenmassenupdate mit Logs | ja | belegt |
|
||||
|
||||
### A11 — Plattform & Querschnitt (7)
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| SyRS-1113 | Verbindungs- und Lizenzüberwachung per Heartbeat | ja | belegt |
|
||||
| SyRS-1118 | Konfigurierbare KI-Provider-Anbindung mit abgesicherten Endpunkten | ja | belegt |
|
||||
| SyRS-1121 | Arbeitsplatz-Anpassung über GUI-Profile und externe Tools | ja | belegt |
|
||||
| SwRS-1134 | Protokollierung von Stundensatz-Zuschlagsänderungen | ja | belegt |
|
||||
| SwRS-1141 | Validierung der KI-Endpunkt-URLs (SSRF-Schutz) | ja | belegt |
|
||||
| SwRS-1142 | Verschlüsselte Ablage der KI-API-Schlüssel | ja | belegt |
|
||||
| SwRS-1145 | Rechteprüfung für globale GUI-Profile | ja | belegt |
|
||||
|
||||
### A12 — Administration & Betrieb (6)
|
||||
|
||||
*SwRS-1233 ist oben unter A1, SwRS-1246 unter A2 gelistet (thematische Zuordnung).*
|
||||
|
||||
| ID | Titel | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| SyRS-1216 | PDF-Signierung als Systemdienst | ja | belegt |
|
||||
| SyRS-1218 | Stundenzuschlagsmodelle für die Vertragsabrechnung | ja | belegt |
|
||||
| SwRS-1234 | Mandantenspezifischer KI-Systemprompt nur mit Recht und Lizenz | ja | belegt |
|
||||
| SwRS-1242 | Rechteprüfung/Verschlüsselung der PDF-Signierungseinstellungen | ja | belegt |
|
||||
| SwRS-1243 | PDF-Signaturvorgang PKCS#7/SHA256/TSA | ja | belegt |
|
||||
| SwRS-1245 | Serverseitige Rechteprüfung für Ad-hoc-SQL im SQL-Manager | ja | belegt |
|
||||
|
||||
## Selbstbewertung
|
||||
|
||||
### Mengengerüst und Abdeckung
|
||||
|
||||
- **Analysetiefe über das Inventar (96 Module):** 42 tief, 48 mittel, 6 flach (M28 Produktdaten-APIs, M29 TradePool, M37 Ticket-Projekte, M59 Legacy-Webservices, M65 generischer Datenim-/-export, M67 Gateway), **0 nicht analysiert**.
|
||||
- **Mindestabdeckung erreicht:** Ja — jedes der 96 Inventarmodule hat mindestens eine Anforderung; kein Modul benötigte die Ausweichkennzeichnung `nicht analysiert`.
|
||||
- **Anforderungen:** 413 gesamt (50 StRS, 122 SyRS, 241 SwRS), davon 16 Hypothesen (3,9 %), 21 nicht-funktionale mit ISO-25010-Merkmal, 198 risikorelevante (alle regelkonform belegt oder als Hypothese gekennzeichnet), 44 Konsolidierungskandidaten.
|
||||
- **Belegbasis:** Alle PRIMÄR-Belege wurden im Quelltext bzw. SQL-Schema gelesen; für risikorelevante Anforderungen benennt der PRIMÄR-Beleg durchgängig die durchsetzende Stelle (Datei, Klasse, Methode, konkrete Prüfung).
|
||||
|
||||
### Wo der Beleg dünn war
|
||||
|
||||
- **Negativbefunde als Hypothesen:** Mehrere sicherheitsrelevante Hypothesen beruhen auf der Abwesenheit einer Prüfung (SwRS-637 AccountDeviceBL ohne Rechteprüfung, SwRS-848 `/production/overview` ohne Authorize-Policy, SwRS-947 Integrationsstammdaten, SwRS-1233 Mandantenspeicherung, SwRS-248 Kontoauszugs-Rechte). Abwesenheit ist statisch schwer beweisbar (die Prüfung könnte an nicht gesichteter Stelle liegen) — Verifikation durch Fachexperten bzw. Laufzeittest nötig.
|
||||
- **Nur clientseitig belegte Regeln:** Pflichtfelder der Custom Properties (SwRS-636), MOVE_HELPDESK_TIMER (SwRS-542), Stundenzuschlags-Validierung (SwRS-1246), KI-Systemprompt-Recht (SwRS-1234) — die Regel existiert, ihre serverseitige Durchsetzung ist offen.
|
||||
- **Nicht einsehbare Logik:** SocialMedia (Stored Procedures, SwRS-748), Expected-Events-Auswertung (außerhalb der Codebasis, SwRS-545), Reportserver-Ausführungsdienst (SwRS-1043).
|
||||
- **Sehr große Einzeldateien nur auszugsweise:** `ReceiptBL.cs` (11.441 Zeilen), `InvoiceZugferdBL` (>2.000 Zeilen, kein Feld-für-Feld-Abgleich gegen EN 16931), `ContractEvaluationBL` (1.493 Zeilen), `OrderBalanceBL` (FlatrateBilling-Kern), DATEV-Formatgeneratoren.
|
||||
- **Nur strukturell erfasst:** M59 Legacy-Webservices (~2.500 Dateien, exemplarisch WebAccount/ReceiptCart/Helpdesk vertieft), `Centron.Controls` (742+ Dateien), Gateway-Adapter.
|
||||
|
||||
### Sicherheits- und Qualitätsbefunde für die Neuimplementierung (Auswahl)
|
||||
|
||||
1. Passworthashing als ungesalzenes SHA1 über Codepage-1252-Bytes (`BasicAuthenticator`, TODO im Code) — im Zielsystem durch moderne KDF ersetzen; identischer Pfad für AppUser und WebAccounts.
|
||||
2. Hartkodierte Geheimnisse: AES-Fallback-Schlüssel (`AESCryptoLogic`), finAPI-OAuth-Client-Credentials im Quellcode — Geheimnisverwaltung zwingend.
|
||||
3. SQL-String-Konkatenation in ReportEngine (`ReportDataBL.ExecuteQuery`) und NexusNotifications — parametrisieren.
|
||||
4. DSGVO-Komplettlöschung für Kunden/Lieferanten/Accounts wirft `NotImplementedException` (nur Kontaktpersonen-Löschung produktiv).
|
||||
5. Keine gesichtete zentrale Schreibsperre für festgeschriebene Rechnungen (`IsFixed`) im SaveReceipt-Pfad; `RechKopf` ohne Unique-Index auf der Belegnummer — im Zielsystem als harte Invarianten spezifizieren.
|
||||
6. `CanCloseHelpdesk()` liefert konstant `true` (kein Abschluss-Gate für offene Checklisten/RMA, nur TODO-Kommentar).
|
||||
7. Schema-Drift: Telemetrie-Tabellen sowie `MasterDataList`/`ObjectExternalReferences` fehlen im Dump `SSMS_DB_SCHEMA.sql` — Schemaquelle und Migrationsskripte abgleichen.
|
||||
8. Keine datenraumtrennende Mehrmandantenfähigkeit (eine DB, Mandant = Firmenstammsatz) — zentrale Architekturentscheidung für SaaS.
|
||||
|
||||
### Empfehlungen für Folge-Iterationen
|
||||
|
||||
1. **Verifikation der 16 Hypothesen**, vorrangig der fünf sicherheitsrelevanten Negativbefunde (Laufzeittest bzw. gezielte Suche nach der durchsetzenden Stelle).
|
||||
2. **Systematischer Abgleich clientseitig geprüfter Rechte gegen serverseitige Durchsetzung** (SyRS-110): CentronRights.md-Rechteliste gegen alle WebServiceBL-Speicherpfade.
|
||||
3. **Abrechnungskern vertiefen:** Positionsbildung des Abrechnungslaufs (VertragPos/VertragArtikel), OrderBalanceBL (Flatrate), Sammelrechnungen, DATEV-Formatdetails, Anzahlungsrechnungen, Provisionslogik.
|
||||
4. **Legacy-Webservices (M59) flächig erfassen** — dort liegen vermutlich weitere fachliche Regeln und Rechteprüfungen; ebenso ServiceBoard-Zeiterfassung (Abrechnungsrelevanz) und Office/SharedDocument-Signaturpfad.
|
||||
5. **E-Rechnung Feld-für-Feld** gegen EN 16931 prüfen (InvoiceZugferdBL, ebInterface, Gateway) — zugleich Konsolidierungsentscheidung für einen Generator.
|
||||
6. **EDI-Distributor-Parser, EscalationBL.DoEscalation, AccountSearchBL, Alt-Migrationen (Anschrif→AccountAddresses)** sowie die ScriptMethods-SQL-Migrationsskripte als Quelle zusätzlicher DB-Regeln.
|
||||
7. **Lizenzverwaltung (LicenseManager/LicenseGuids)** als eigenes Querschnittsthema erheben.
|
||||
|
||||
### Methodische Anmerkungen
|
||||
|
||||
- Die Anforderungszahlen je Modul in der Abdeckungstabelle enthalten anteilige Zuordnungen; die Summe über die Tabelle ist daher nicht identisch mit der Gesamtzahl 413.
|
||||
- SwRS-240 wurde nicht vergeben (dokumentierte Nummernkreislücke, kein Inhaltsverlust).
|
||||
- Die Hypothesenquote (3,9 %) liegt bewusst über null: Alle Aussagen ohne eindeutige Artefaktgrundlage wurden als Hypothese abgegrenzt statt behauptet; zusätzlich benennt die Selbstbewertung offene Punkte, die keiner Anforderung zugeordnet sind (nur hier, nicht in `Hypothesen.md`).
|
||||
- Änderungshistorie (Commits) wurde nicht als Belegquelle herangezogen; KONTEXT-Belege stammen aus `docs\`, `CentronRights.md` und Code-Kommentaren (inkl. Ticketnummern, z. B. 168245/164153 beim MSP-Abgleich).
|
||||
+211
@@ -0,0 +1,211 @@
|
||||
# Glossar
|
||||
|
||||
**System:** c-entron ERP-Suite | **Datum:** 2026-08-27
|
||||
|
||||
Domänenbegriffe, wie sie in StRS/SyRS/SwRS verwendet werden. Technische Bezeichner (Klassen, Tabellen, Spalten) stehen in Backticks.
|
||||
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| 2FA | Zwei-Faktor-Authentifizierung; beim Login per RADIUS-Server oder E-Mail-Bestätigungslink. |
|
||||
| Absender-Whitelist | Menge der zum Versand freigeschalteten Absenderadressen (Systemadressen + eigene Mitarbeiteradresse + `ApplicationSettingID.AllowedEmails`). |
|
||||
| Access-Key (RMM) | Statischer, AES-verschlüsselt gespeicherter Schlüssel im Header `X-RMM-Access-Key` zur Autorisierung der RMM-REST-Schnittstelle. |
|
||||
| Access-Token | Persistenter API-Schlüssel als Alternative zum Sitzungsticket (`AccessTokensController`, `AccessTokenWebServiceBL`), mit Zugriffsprotokoll (`AccessTokenLog`). |
|
||||
| Account | Zentraler Geschäftspartner-Datensatz (Tabelle `Accounts`), der über Rollen gleichzeitig Kunde, Lieferant, Kontakt u. a. sein kann. |
|
||||
| AccountDevice | Datenhaltung für sonstige Kundengeräte/Hardware (Tabelle `AccountDevices`) mit Soft-Delete, Log und Ticketverknüpfung. |
|
||||
| AccountType / `AccountTypeToAccount` | Rollenzuordnung eines Accounts; verknüpft Account mit Kunden- (`AccountCustomers`) bzw. Lieferantendaten (`AccountSuppliers`). |
|
||||
| `AESCryptoLogic` | c-entron-Hilfsklasse zur symmetrischen Verschlüsselung gespeicherter Geheimnisse (teils mit zentralem Masterkey aus der Konfigurations-DB). |
|
||||
| Anrede / Abrede | Einleitungstext (`AN_*`) bzw. Schlusstext (`AB_*`) eines Belegs. |
|
||||
| `ApplicationSettings` | Aktuelle Tabelle für typisierte Anwendungseinstellungen mit fester numerischer ID (Enum `ApplicationSettingID`). |
|
||||
| AppUser | Internes ERP-Benutzerkonto eines Mitarbeiters (Mitarbeiterkonto) für die Anwendung, persistiert in Tabelle `Sichbenu`. |
|
||||
| Artikel | Stammdatensatz eines Produkts/einer Dienstleistung (Tabelle `ARTIK`), identifiziert durch I3D und fachlich durch Artikelcode. |
|
||||
| AssetManagement-Gerät | Extern (DocuBoard/River, AD/SNMP-Monitoring) synchronisierte Gerätedaten mit eigener Objektart `AssetManagementDeviceClass` (5101330). |
|
||||
| AssetReason (QM-Grund) | Je Belegart gepflegter Rückgabe-/Reklamationsgrund mit Pflichtkennzeichen (`IsMandatory`). |
|
||||
| AuthentificationKind | Pro Benutzer gespeichertes Anmeldeverfahren (CentronLogin/WindowsAuth/OpenIdConnectAuth), Spalte in `Sichbenu`. |
|
||||
| AVV | Auftragsverarbeitungsvertrag (DSGVO Art. 28); im DSGVO-Modul als Vorlage und je Kunde als `OrderProcessingContract` verwaltet. |
|
||||
| Barbeleg / Barrechnung (`IsCashAsset`) | Bar abgewickelter Beleg mit bruttobasierter Steuerrundung und eigenem Nummernkreis; vom Storno ausgeschlossen. |
|
||||
| BatchId | Gruppenkennung mehrtägiger MyDay-Serieneinträge; 0 = Einzeltag. |
|
||||
| Beleg | Geschäftsdokument der Verkaufs-/Einkaufskette (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholschein u. a.), technisch `IReceiptBase` mit Kopf und Positionen. |
|
||||
| Belegart | Typ eines Belegs (`CentronObjectKindNumeric`, z. B. OrderClass, InvoiceClass); steuert Rechte, Nummernkreis und Weiterverarbeitungsziele über SpecificLogics. |
|
||||
| Belegkette / Weiterverarbeitung (Forwarding) | Erzeugen eines Folgebelegs aus einem oder mehreren Quellbelegen mit Datenübernahme; Herkunft wird beidseitig gespeichert. |
|
||||
| Belegkondition (`AssetCondition`) | Zahlungs-, Liefer- oder sonstige Kondition mit länderspezifischen Texten, Fälligkeitsart und Mindestbetrag. |
|
||||
| Belegstatus Aktiv (`ReceiptState.Active`) | Einziger Belegzustand, in dem Massenänderungen an Belegpreisen zulässig sind. |
|
||||
| Belegversion | Historisierte Ausprägung eines Belegs; Änderungen erzeugen Version+1, Vorversionen bleiben erhalten. |
|
||||
| Belegzuordnung (`IsAssignedToAsset`) | Verweis einer Zeit auf eine Auftrags-, Lieferschein- oder Rechnungsposition (`AufPosI3D`/`LiefPosI3D`/`RechPosI3D`); macht die Zeit unveränderlich. |
|
||||
| Bestellvorschlag | Automatisch berechnete Vorschlagsliste zu bestellender Mengen aus Auftragsbedarf, Mindestbestand, Bestand und Zulauf. |
|
||||
| Betreuer (Adviser) | Bis zu sechs am Account hinterlegte Mitarbeiter (`Adviser1I3D`..`Adviser6I3D`), die für den Kunden verantwortlich sind. |
|
||||
| BL / DAO / ILogic | Schichten: Business Logic (Entities/NHibernate), Data Access (Sessions/Mappings), clientseitige Logik-Schnittstelle mit BL- (Direkt-DB) und WS- (WebService) Implementierung. |
|
||||
| CentronHosted | Autorisierungs-Policy, die Endpunkte auf von c-entron gehostete Installationen (Lizenz CentronInternal) beschränkt. |
|
||||
| `CentronObjectKindNumeric` (ObjectKind) | Systemweite numerische Objektart-Enumeration/-Kennung (z. B. Account, HelpdeskClass, MasterDataListClass=25, AssetManagementDeviceClass=5101330) zur generischen Adressierung von Geschäftsobjekten. |
|
||||
| ChangeLog | Generische Änderungshistorientabelle, adressiert über ObjectKind (Objektart) + ObjectI3D. |
|
||||
| Chargeback | Rücklastschrift; negative Zuordnung, die auch geschlossene Rechnungen wieder öffnen darf. |
|
||||
| Checkliste (`CentronChecklist`) | Hierarchische Aufgabenliste mit Punktzuständen (u. a. Open), generisch über ObjectKind/ObjectI3D an Objekte wie Tickets gebunden. |
|
||||
| Check-out / Check-in | Exklusives Sperren eines Dokuments der Dateiablage zur Bearbeitung (mit Arbeitsstation) und Rückgabe als neue Version. |
|
||||
| Click-Vertrag | Vertrag, der Gerätezählerstände (z. B. Druckseiten) als Differenzmenge abrechnet (`ContractExtraKind.ClickDevice`). |
|
||||
| ConnectionManager | WPF-Werkzeug zur Pflege der `WebServiceConfig.xml` (DB-Verbindung, Proxy, AD, Zertifikate, Secret Key). |
|
||||
| DataQualityService | Hintergrunddienst, der Datenbereinigungs- und Reparaturaufgaben in isolierten Einzelschritten ausführt. |
|
||||
| DetachedFromOrigin | Kennzeichen einer Vertragsposition, dass die Verknüpfung zum erzeugenden Ursprungsauftrag gelöst wurde (verhindert Rückwirkungen bei Mengenänderungen). |
|
||||
| Direktlieferung | Lieferung vom Distributor direkt an den Endkunden ohne eigenen Lagerdurchlauf (`AufPos.Direktlieferung`). |
|
||||
| D!VE-Profil | Gespeicherte Exportvorgaben (Mandant, Rahmenvertrag, feste Zahlungs-/Rabatt-/USt-Werte) für den D!VE-Export (Entität `TelekomDiveProfile`). |
|
||||
| DocBee | Externes Service-Management-/Vorgangssystem; angebunden über Webhooks und die DocBee-Konnektor-BLs. |
|
||||
| DocSync | Mechanismus zur Bereitstellung von c-entron-Dokumenten/Verzeichnissen an eine externe Synchronisation, gefiltert nach Objektarten. |
|
||||
| docuFORM | Fleet-/Print-Management-Server; liefert Druckgeräte und Seitenzähler über eine OAuth2-geschützte REST-API. |
|
||||
| EAV | Entity-Attribute-Value: generisches Speichermuster mit typisierten Wertspalten je Attribut. |
|
||||
| ebInterface | Österreichisches E-Rechnungsformat (hier Version 4.3). |
|
||||
| EDI | Electronic Data Interchange — strukturierter elektronischer Belegaustausch mit Lieferanten/Distributoren (Bestellung, Bestellbestätigung, Lieferschein, Rechnung). |
|
||||
| ElectronicSales (ES) | Webshop-System; dessen Kundengruppen/Rollen werden als lokale Caches (`EsCustomerGroup`/`EsRole`) geführt. |
|
||||
| Empfänger-Bitmaske | Kodierung der Eskalationsempfänger einer Stufe als Summe von Empfänger-IDs in einer Integer-Spalte (`StageNReceivers`). |
|
||||
| Eskalation | Zeitgesteuerte, bis zu dreistufige E-Mail-Benachrichtigung bei überfälligen Vorgängen (Tabellen `eskalationen`/`eskalationTypen`); die erreichte Stufe wird in `hlpdsk_requests.EscalationLevel` geführt. |
|
||||
| Eskalationstyp | Konfigurierbares dreistufiges Regelwerk für die automatische Eskalation überfälliger Vorgänge, je Objektart bzw. Ticketpriorität: Wartestunden/Fristen je Stufe (`Hour1`-`3`), Geschäftszeitfenster, Sa/So-Flags und Empfängerkreise je Stufe. |
|
||||
| EWS | Exchange Web Services; klassische Microsoft-Exchange-API, im System für Kalender- und Mailzugriff genutzt. |
|
||||
| Expected Event | Definition eines je Wochentag erwarteten externen Ereignisses (z. B. Backup-Meldung) mit Textmustern zur Erfolgs-/Warn-/Fehlerklassifikation und Logeinträgen mit Ticketbezug. |
|
||||
| Externes Tool | Konfigurierbares Fremdprogramm (Pfad + Argumente) mit @@Platzhalter@@-Ersetzung aus dem Fachkontext. |
|
||||
| Externreferenz (`ObjectExternalReference`) | Generische Verknüpfung eines c-entron-Objekts (ObjectI3D + ObjectKind) mit einem Objekt eines Fremdsystems (ExternalReferenceType + ExternalReferenceID), z. B. DocBee. |
|
||||
| Fälligkeit (`DueDate`/`FaelligAm`) | Aus der Ticketpriorität (Reaktionszeit in Stunden, Bürozeiten, Sa/So-Regeln) berechneter Zieltermin für die Ticketbearbeitung. |
|
||||
| Festschreibung (`IsFixed`) | Unveränderlichkeits-Kennzeichen einer Rechnung (`RechKopf.IsFixed`=1), gesetzt mit Protokolleintrag. |
|
||||
| FiBu-Export | Übergabe von Buchungs-/Stammdaten an Finanzbuchhaltungssysteme (DATEV, Abacus, Sage u. a.). |
|
||||
| Filialbeschränkung | Rechtegesteuerte Einschränkung von Auswertungen auf die Filiale (Branch) des angemeldeten Mitarbeiters. |
|
||||
| Filiale (Branch) | Standort/Niederlassung (organisatorische Einheit) eines Mandanten (Tabelle `Filiale`, `BranchDTO`); genau eine Filiale je Mandant ist Standard. `BranchI3D` bindet Rechtegruppen und restriktive Rechte an Standorte; „nur eigene Filiale"-Rechte binden den Belegzugriff an die Filiale des Benutzers. |
|
||||
| finAPI | Externer Kontozugriffs-/PSD2-Dienst (live/sandbox.finapi.io), angebunden über REST v2 und WebForm. |
|
||||
| Firmengruppe (`CompanyGroup`) | Konzernklammer über Konten; kann Preisliste, Sonderpreise und Leitweg-ID für Belege vorgeben. |
|
||||
| Freigabewesen | Mehrstufiger Genehmigungsworkflow des Warenkorbs (Prüfer → Besteller) über die Zustandsmaschine `ReceiptCartState`. |
|
||||
| Fremd-Todoliste | Recht (RIGHT_FREMDTODOLISTE), die ToDo-Listen anderer Mitarbeiter einzusehen; RIGHT_FREMDTODOLISTEVERWERFEN erlaubt das Verwerfen fremder ToDos. |
|
||||
| Fremdware | Im RMA angenommener Artikel ohne eigenen Verkaufsbeleg; wird in ein RMA-Kundenlager (`StockKind.RmaCustomer`) eingebucht. |
|
||||
| Gateway | Projekt `Centron.Gateway`: Sammlung von Formatadaptern (EDI, FiBu, SEPA, OpenTrans, ZUGFeRD, FinTS). |
|
||||
| Gläubiger-ID (`SepaIdentificationNumber`) | SEPA-Gläubigeridentifikationsnummer des Mandanten (Mandator). |
|
||||
| Gleitender EK | Mengen-gewichteter Durchschnitts-Einkaufspreis, der bei jedem Wareneingang fortgeschrieben wird (Alternative: Fest-EK, letzter EK; `ARTIK`-Feld `NoMixedEk`). |
|
||||
| Globaler Zuschlag | Das per Einstellung `GlobalHourlySurchargeRateI3D` als systemweiter Standard markierte Zuschlagsmodell; nicht deaktivierbar. |
|
||||
| Gruppen-Settings-Klasse | Serverseitige Klasse, die fachlich zusammengehörige Einstellungen gebündelt lädt, typisiert bereitstellt und speichert (z. B. `PdfSigningSettings`). |
|
||||
| GUI-Profil | Gespeichertes Oberflächen-Layout (`CentronUiProfiles`), privat je Benutzer oder global (`IsGlobal`) für alle. |
|
||||
| Gutschein (Voucher) | Barcode eines Gutscheinartikels; Status frei/ausgegeben/eingelöst über `GutscheinZuRechnung` abgeleitet. |
|
||||
| Hauptlager | Implizites Basislager eines Artikels; im Code als Lager-I3D -1 geführt, Bestand in `ARTIK.Menge`. |
|
||||
| Hauptposition (`IsMainItem`) | Die genau eine Position eines Stammblatts, die das Hauptgerät (Menge 1) repräsentiert. |
|
||||
| Heartbeat | Zyklischer Client-Server-Ping (5 Minuten) zur Validierung von Sitzung und Lizenz. |
|
||||
| Helpdesk-Status (`HelpdeskState`) | Frei konfigurierbarer Datensatz in `hlpdsk_status`, der die Lebenszyklusphase eines Tickets angibt; ein per AppSetting bestimmter Status gilt als „Abgeschlossen". |
|
||||
| Helpdesk-Timer (Zeit) | Erfasste Arbeitszeit/Zeitbuchung eines Mitarbeiters auf einem Ticket (Tabelle `hlpdsk_timer`) mit Berechenbar-Flag (`Calculable`, steuert die Fakturierbarkeit) und optionaler Beleg-Zuordnung; Basis der Leistungsabrechnung. |
|
||||
| Herstellercode (`ManufactorCode`/`ManufacturerCode`) | Artikelnummer des Herstellers; Zuordnungsschlüssel beim Preislistenimport. |
|
||||
| Heuristik / MatchingRate | Herkunftskennzeichen und Güte einer automatischen Umsatz-Beleg-Zuordnung. |
|
||||
| Hintergrunddienst (`ManagedBackgroundService`) | Im Webservice-Host laufender periodischer Job, dessen Aktivierung und Laufzeiten über die Tabelle `BackgroundServices` gesteuert/protokolliert werden. |
|
||||
| I3D | „ID 3develop": systemweiter technischer Primärschlüssel (int IDENTITY) nahezu aller c-entron-Tabellen und -Entitäten; Fremdschlüsselspalten tragen das Suffix I3D. Wird auch als fester ID-Wert von Rechten verwendet. |
|
||||
| Interne Rechnung | Rechnung nur mit Dienstleistungspositionen zum Gesamtwert 0,00, nummeriert aus eigenem Nummernkreis (InternalInvoice). |
|
||||
| Inventur | Stichtagsbezogene Bestandszählung je Lager mit anschließender Buchbestandskorrektur; Voll- (Komplett-) oder Teilinventur. |
|
||||
| Kalkulationsfaktor | Mandantenweiter Faktor (AppSetting `ArticleCalculationFactor`), mit dem Einkaufspreise bei Bewertung/Anzeige multipliziert bzw. dividiert werden. |
|
||||
| Klickzähler / Seitenzähler (`DeviceClickCounter`) | Zähler eines Stammblatt-Geräts (z. B. Seitenzähler von Druckgeräten); Grundlage der verbrauchsbasierten Abrechnung von Click-/Managed-Print-Verträgen. |
|
||||
| Kommissionierung | Zusammenstellen der Auftragspositionen im Lager mit Rückmeldung gepickter Mengen (`QuantityPicked`). |
|
||||
| Kontenrahmen (`BookKeepingAccountSystems`) | Zuordnung Erlös-/Aufwandskonten zu Steuersätzen für den Export. |
|
||||
| Kontingentrest-Mitnahme (`KontingentRestMitnehmen`) | Option, nicht verbrauchte Kontingente in die Folgeperiode zu übertragen. |
|
||||
| Kontingentvertrag | Vertrag mit gebuchtem Leistungsvolumen (z. B. Stunden); Verbrauch wird gegen Buchungen (`VertragRechKopfZuordnung`) gerechnet. |
|
||||
| Kontoauszug (`OnlineBankingAccountTransaction`) | Importierter Bankumsatz einer Onlinebanking-Konfiguration (FinTS/finAPI/Spreadsheet). |
|
||||
| Kostenstelle / Kostenträger (`CostCenter`/`CostObject`) | Controlling-Stammdaten zur Belegzuordnung; Soft-Delete über State-Feld. |
|
||||
| Kreditlimit | Kundenindividuelle Obergrenze des offenen Belegvolumens (netto/brutto); Überschreitung erfordert Bestätigung. |
|
||||
| Kundensonderpreis (`KundenSonderpreise`) | Kunden-/warengruppenbezogene Preisregel mit Gültigkeitszeitraum und Preisbasis (`SpecialPriceKind`). |
|
||||
| `Laenkenn` | Ländertabelle (Legacy-Name) mit Währung (`KursZuEur`), Vorwahl, MwSt-Art, Erlöskonten, Standardland-Kennzeichen. |
|
||||
| Leitweg-ID | Adressierungskennung öffentlicher Auftraggeber in Deutschland; am Kunden bzw. dessen Firmengruppe gepflegt. |
|
||||
| Löschprotokoll | Bei DSGVO-Löschung erzeugtes Textprotokoll („c-entron Löschprotokoll") aller entfernten personenbezogenen Angaben. |
|
||||
| Mahnlauf | Ein Ausführungsvorgang des Mahnwesens; protokolliert je Rechnung in Tabelle `Mahnlauf` unter fortlaufender MahnLaufNr. |
|
||||
| Mahnsperre (DunningStop) | Kennzeichen/Zeitraum auf Kunde oder Rechnung, das die Aufnahme in Mahnvorschläge verhindert. |
|
||||
| Mahnstufe (DunningLevel) | Eskalationsstufe einer überfälligen Rechnung (je nach Sicht 0–3 bzw. 1–3), gespeichert in `RechKopf.Mahnstufe` mit Datum und Bearbeiter je Stufe. |
|
||||
| Mailing | Kampagnenbezogener Massenversand (E-Mail/SMS) mit personalisierten Empfängertexten und Versandkennzeichen. |
|
||||
| MailTemplateReference | Eindeutige Identifikation einer Mail-Vorlage über ObjectKind, SubObjectKind, ObjectI3D und TemplatePrio (Tabelle `MailVorlagen`). |
|
||||
| Mandant (Mandator) | Rechtlich/organisatorisch eigenständige Firma innerhalb einer c-entron-Installation mit eigenen Stammdaten (Anschrift, Bankverbindungen, USt-ID, Logos) und Belegnummernkreisen (Tabelle `Mandant`, Entität Mandator); zugleich die eigene Firma des Systemhauses als Absender-Stammdaten für Belege. Getrennte Datenhaltung je Firma (MandantID in `Sichbenu`), wobei alle Mandanten eine Datenbank teilen; nicht zu verwechseln mit SaaS-Mandantentrennung. |
|
||||
| Mandatsreferenz (`AuthorizationNumber`) | Eindeutige Kennung des SEPA-Mandats an der Bankverbindung. |
|
||||
| Maschinenart (`ProductionMachineKind`) | Klassifikation von Produktionsmaschinen; trägt wiederverwendbare Arbeitsschrittbeschreibungen (`ProductionMachineKindStepsDescription`). |
|
||||
| Massenupdate-Vorlage (`MassUpdateTemplate`) | Benannter Massenänderungslauf mit Einzelpositionen (Items) je Zielobjekt, Ausführungsstatus und Fehlergrund. |
|
||||
| Masterkey / Masterschlüssel | Zentraler mandantenweiter symmetrischer Schlüssel aus der Konfigurations-DB (`CentronConfigurationDbBL`; „Hotline-Masterkey") zur AES-Ver-/Entschlüsselung gespeicherter Geheimnisse, z. B. der Zugangsdaten des Passwortmanagers sowie der Postfach-Passwörter und Client-Secrets der VMA-Profile. |
|
||||
| MCP-Tool | Werkzeug des Model-Context-Protocol-KI-Assistenten, dessen Nutzung telemetrisch gezählt wird (`McpToolUsageTelemetry`). |
|
||||
| Microsoft Graph | Moderne Microsoft-365-API; alternativer Mail-Transport (GraphMail) und Quelle der Teams-Anrufdaten (CallRecords). |
|
||||
| Mindestpreis (`MinPrice`) | Artikeluntergrenze für den Netto-VK; Unterschreitung erfordert Recht ALLOW_IGNORE_MINIMUM_PRICE. |
|
||||
| Mitarbeiter (Employee) | Personalstammsatz (Tabelle `Personal`) mit Kürzel (`ShortSign`), Filiale (`BranchI3D`) und Personalakten-Ordnern. |
|
||||
| MSP | Managed-Service-Provider — Systemhaus, das IT-Betrieb für Kunden übernimmt; Zielgruppe von c-entron. |
|
||||
| MSP-Collector | Konfigurierte Importschnittstelle zu einem Managed-Service-Lieferanten (z. B. Veeam, Octopus, ArrowSphere), die Nutzungs-/Abrechnungsdaten abholt. |
|
||||
| MSP-Evaluation | Positionsweiser Abgleich importierter Lieferantenabrechnungen mit Kundenvertragspositionen inklusive Übernahmeentscheidung (Menge/Preis/ignorieren). |
|
||||
| Nebenlager | Zusätzliches, in `Warehouses` definiertes Lager; Artikelbestand je Nebenlager in `NebenlagerArtikel`. |
|
||||
| Nexoware Smartflow (CPra) | Externer Formular-/Workflow-Dienst; c-entron erzeugt vorbefüllte Webhook-Links. |
|
||||
| NexusNotification | Persönliche Benachrichtigung im Nexus-Web-Client mit getrennten Zuständen `IsSeen` (Badge) und `IsRead` (gelesen), gepusht über SignalR-Hub. |
|
||||
| Normierung (`RechnungNormieren`) | Tagesanteilige Berechnung angebrochener erster/letzter Abrechnungsperioden auf Kalendermonat/-quartal/-jahr. |
|
||||
| Nummernkreis (`NumberGroup`) | Zentraler konfigurierbarer Zähler für fortlaufende Nummern (Tabelle `Nummernkreis`), je Belegart/Mandant/Filiale zur Vergabe eindeutiger Belegnummern sowie für Account-, Kunden- und Lieferantennummern (via `NumberGroupBL.GetNextNumber`). |
|
||||
| OnlinePdfDocument | Per GUID adressiertes, einmalig signierbares PDF-Dokument (`DsgvoBL`); nach Bestätigung gelöscht. |
|
||||
| OpenTRANS 2.1 | XML-Standardformat für Geschäftsbelege; Standardformat des Bestellversands. |
|
||||
| OPOS | Offene-Posten-Liste: aktive Rechnungen abzüglich Zahlungen und verrechneter Gutschriften je Kunde; Versandform „Kontoauszug". |
|
||||
| Pauschalabrechnung (FlatRate) | Auftragbasierte Pauschalfaktura; zugehörige Zeiten sind von der Einzelzeitabrechnung ausgeschlossen (`IsFlatRateItem`). |
|
||||
| PDF/A | ISO-Normfamilie für Langzeitarchivierung von PDF; im System als Konformitätsstufen PDF/A-1a bis PDF/A-3b sowie PDF/X wählbar. |
|
||||
| Personalakte | Automatisch angelegte Dokumenten-Ordnerstruktur je Mitarbeiter (Zertifikate, Verträge, Gesprächsnotizen usw.). |
|
||||
| PLM (`ProductLifecycleInformation`) | Product Lifecycle Management — Lebenszyklusdatensatz einer verkauften Lizenz/eines Abos (Quelle meist Rechnungsposition) mit Laufzeit (`StartDate`/`EndDate`), Kunde und Angebotsstatus; das Verwerfen des zugehörigen ToDos deaktiviert die Lizenz und wird protokolliert. |
|
||||
| `PORTRECH` / `PORTWARE` | Flag-Tabellen für bereits an die FiBu exportierte Kunden- bzw. Lieferantenbelege. |
|
||||
| Preisliste (VK1–VK4) | Vier Verkaufspreisfelder je Artikel; `Customer.PriceList` wählt den anzuwendenden VK. |
|
||||
| Produktfamilie (`ProductFamily`/`-Group`) | Fachliche Gruppierung von Artikeln im PLM zur Zuordnung von Lebenszyklusdaten. |
|
||||
| Produktionsauftrag (`ProductionOrder`) | Fertigungsauftrag, der zwingend auf einen Verkaufsauftrag (`OrderI3D`/`OrderNumber`) verweist und Arbeitsschritte (`ProductionOrderItems`) bündelt. |
|
||||
| Produktionsschritt / Werkschritt (`ProductionOrderItem`) | Einzelner Arbeitsschritt eines Produktionsauftrags mit Maschinenart/Maschine, Soll-/Ist-Menge und Zustand (`ProductionOrderItemState`: Offen/OpenNotStarted, In Bearbeitung, Beendet/Finished). |
|
||||
| Produktmatrix | Bewertungsraster Kunde × Produkt mit 4 Potenzialstufen und Änderungshistorie. |
|
||||
| QmNotification | Dreistufiger Benachrichtigungsmodus je Belegart: keine / Nachfrage / immer. |
|
||||
| Recht | Einzelberechtigung mit fester I3D (Tabelle `Sichrech`), im Code über `UserRightsConst` referenziert. |
|
||||
| Rechtegruppe | Gruppe (Tabelle `Sichgrup`), der Rechte (`Sichtrus`) und Benutzer (`Sichmemb`) zugeordnet werden. |
|
||||
| ReportEngine / ReportData | Neuere Berichtsverwaltung auf FastReport-Basis (XML im DB-Feld `Report`) mit Gruppen (`ReportGroup`, GUID je Belegart) und Abfragen (`ReportDataQuery`). |
|
||||
| Reports (Alt-Tabelle) | Legacy-Berichtsspeicher (`dbo.Reports`, deutsche Spalten) mit eigener BL — Parallelbestand zur ReportEngine. |
|
||||
| Restriktives Recht | Recht, das Befugnisse einschränkt statt erweitert (z. B. MANAGE_RIGHTS_ONLY_OWN_BRANCH, „nur eigene"-Rechte). |
|
||||
| Result / `Result<T>` | Einheitliches Rückgabemuster der Logikschicht mit Status (Success/Error), Meldung und Nutzdaten statt Exceptions. |
|
||||
| Richtlinie (Guideline) | Passwortmanager-Regelwerk, das je Kunde und Mitarbeiter feingranulare Zugriffsrechte (Bitflags) auf Zugangsdaten definiert. |
|
||||
| Riverbird / RiverDivo | RMM-Produkt bzw. dessen c-entron-Anbindung (Namespace `RiverDivo`); Legacy-Zugang per Ticket, neuer Zugang per RMM-Access-Key. |
|
||||
| RMA | Return Merchandise Authorization — Retourenvorgang mit Statushistorie je reklamiertem Artikel. |
|
||||
| RMM | Remote Monitoring & Management — Fernüberwachungs-/Verwaltungssystem eines Managed-Service-Providers (hier v. a. Riverbird). |
|
||||
| SelfCare-Formular / WebForm | Konfigurierbares Kundenformular, das über einen GUID-Link mit Ablaufdatum extern (ServiceBoard-Web) ausgefüllt wird. |
|
||||
| SendBack | RMA-Rücksendung defekter Ware an den Lieferanten (`RmaSendBack`). |
|
||||
| SendForth | RMA-Vorab-/Ersatzlieferung an den Kunden (`RmaSendForth`). |
|
||||
| SEPA-Mandat (`SepaContract`) | Lastschriftmandat mit Status Draft/Accepted/Declined/LinkExpired und Online-Unterschriftsprozess; als Signaturdokument mit Pflicht-Bankdaten (Bankname, IBAN, BIC) über die DocumentSigning-Seite erteilt. |
|
||||
| Seriennummer / Barcode | Einzelstück-Identifikation eines Artikels (Tabelle `Barcode`, Entitäten `BarCode`/`BarCode2`) mit eigenem Statuslebenszyklus (`BarcodeState`). |
|
||||
| Seriennummernpflicht (`ScanBarcode`) | Artikelkennzeichen (`ARTIK.BarcodeScanen`), das die Bestandsführung auf Seriennummernzählung umstellt. |
|
||||
| ServiceBoard (SBO) | Web-Frontend der Suite; je nach Sicht browserbasierter Mitarbeiter-Arbeitsbereich für Tickets, Planung und Zeiterfassung (Lizenz ServiceBoardWebDev) sowie Zugangspunkt für Kunden-/Technikerzugriffe (Formulare, Umfragen, Tickets); Basis-URL in den Einstellungen. |
|
||||
| SETTINGS-Recht | Benutzerrecht `UserRightsConst.Administration.SETTINGS`; Voraussetzung für die Pflege von Integrations-/Systemeinstellungen. |
|
||||
| Siegel / Siegelbruch | Schutzmechanismus des Passwortmanagers: versiegelte Zugangsdaten dürfen nur mit SealBreak-Recht, Begründung, Protokoll und E-Mail-Meldung geöffnet werden. |
|
||||
| SimpleUrl / WebLink | Zwei getrennte Datenhaltungen für objektbezogene URLs; WebLinks besitzen zusätzlich Gruppen und ausführbare Aktionen (`WebLinkAction`). |
|
||||
| Skonto-Ausschluss (`NoEarlyPaymentDiscountAllowed`) | Positionskennzeichen, das die Position aus der Skontobasis herausnimmt (NotDiscountable-Summen). |
|
||||
| Soft-Delete | Logisches Löschen per Kennzeichen statt physischem Entfernen des Datensatzes; je nach Modul über Statusfeld (State=0) oder über `IsDeleted`/`DeletedByI3D`/`DeletedDate`. |
|
||||
| Sondervereinbarung (SpecialAgreement, Projektpreis) | Kunden-, projekt- oder auftragsbezogenes Preisabkommen: verkaufsseitig eine Preisliste mit eigenen EK/VK bzw. prozentualen Reduktionen, Artikelpositionen und zugeordneten Kunden; einkaufsseitig eine auftrags-/projektbezogene Einkaufspreisabsprache (`SondervereinbarungI3D`) mit Gültigkeitsdatum, die vom Standard-EK-Verfahren ausgenommen ist. |
|
||||
| Staffelpreis (`ArticleVolumePrices`) | Mengenabhängige EK/VK-Preise eines Artikels. |
|
||||
| Stammblatt (MasterDataList) | Gerätedatensatz des Kunden für abrechnungsrelevante Geräte (v. a. Drucker/Kopierer) mit Hauptposition, Seriennummer, Klickzählern und Click-Vertragszuordnung; Träger der Gerätezähler; UI-Bezeichnung der Objektart `MasterDataListClass` (25). |
|
||||
| `Stammdat` | Legacy-Einstellungstabelle (Zugriff über Enum `AppSettingsConst`); für neue Einstellungen gesperrt. |
|
||||
| Standardmandant | Der genau eine Mandant mit `Default`=true; er kann nicht gelöscht/deaktiviert werden und dient als Fallback (z. B. für Logos). |
|
||||
| Stemming | Rückführung von Wörtern auf ihre Stammform (`GermanAnalyzer`, angelehnt an Lucene.NET GermanStemmer). |
|
||||
| Storno | Aufhebung einer Rechnung als neue Belegversion mit Status „storniert" und genullten Mengen; nur mit Recht RIGHT_RECHNUNGSTORNIEREN. |
|
||||
| Stundenzuschlagsmodell (`HourlySurchargeRate`) | Satz von Zeitfenstern mit prozentualen Zuschlägen je Wochentag/Feiertag, der Verträgen zur Abrechnung von Arbeitszeiten zugeordnet wird. |
|
||||
| Sync-Mitglied | Mitarbeiter, dessen Teams-Anrufe beim Graph-CallRecords-Sync in das Anrufjournal übernommen werden. |
|
||||
| Tag | Normalisiertes (lowercase, getrimmt) freies Schlagwort (Tabelle `Tags`), Objekten z. B. Tickets über `TicketTags` zugeordnet. |
|
||||
| Tagesabschluss (`MyDayFinalizedDay`) | Verbindliche Bestätigung eines Mitarbeiters, dass sein Arbeitstag in MyDay vollständig erfasst ist; fehlende Abschlüsse lösen Erinnerungen und Teamleiter-Eskalation aus. |
|
||||
| TAPI | Telephony API; Windows-Telefonie-Schnittstelle, über die der Client Anrufe meldet, die als `PhoneCall` protokolliert werden. |
|
||||
| TaskManager-Aufgabe | Wiederkehrende Aufgabe (`TaskManagementTask`) mit Wiederholungsregel (Recurrence) und Aktion, z. B. automatischer Ticketanlage (`TaskManagementHelpdeskAction`). |
|
||||
| Teilkommission | Kommissionierung einer Teilmenge eines Auftrags (`PartialCommissionOrder`). |
|
||||
| Telekom D!VE | Telekom-Partnerportal/Marktplatz; c-entron exportiert Angebote als D!VE-XML. |
|
||||
| Telemetrie-Bucket | Zeitfenster (`BucketStartUtc`), auf das Nutzungsereignisse aggregiert werden; gespeichert wird nur ein Zähler je Schlüsselkombination. |
|
||||
| Terminanfrage (`AppointmentRequest`) | Vorgang, bei dem einem Kunden mehrere Terminvorschläge (`AppointmentProposal`) angeboten werden; Antwort erfolgt über eine Guid und schaltet den `RequestState` weiter. |
|
||||
| Textbaustein (TextModule) | Wiederverwendbarer Anrede- oder Schlusstext je Belegart/Helpdesk-Kontext mit @@-Platzhaltern; Auflösung kundenspezifisch vor benutzerspezifisch vor global. |
|
||||
| Ticket (Authentifizierung) | Serverseitig gespeichertes/verwaltetes Sitzungs-Token mit Ablaufdatum, ausgestellt nach erfolgreicher Anmeldung (`TicketBL`); wird bei jedem Legacy-Aufruf validiert und verlängert. Nicht zu verwechseln mit dem Helpdesk-Ticket. |
|
||||
| Ticket (Helpdesk-Fall) | Kundenbezogener Service-/Support-Vorgang in Tabelle `hlpdsk_requests` (Entität `Helpdesk`/`HelpdeskCompact`), auch im ServiceBoard/Kundenportal sichtbar; „Ticket" und „Helpdesk(-Fall)" werden in der Codebasis synonym verwendet. |
|
||||
| Ticket-Projekt | Bündelung von Tickets mit eigenem Nummernkreis, Aufgaben, Abhängigkeiten, Nachrichten und Logs (`TicketProject`; `hlpdsk_requests.ProjectHelpdeskI3D`). |
|
||||
| TimerBilling | Abrechnung erfasster Helpdesk-Zeiten (HelpdeskTimer) über Aufträge/Rechnungen. |
|
||||
| ToDo / Wiedervorlage | Aus Geschäftsobjekten (Belege, Verträge, Tickets, PLM-Lizenzen, Geburtstage, Videozuweisungen) erzeugter Aufgabeneintrag mit Read-/Discarded-Status. |
|
||||
| Toleranzfrist (`DaysToTolerate`) | Konfigurierte Anzahl Tage, innerhalb derer ablaufende Lizenzen Wiedervorlagen (ToDos) erzeugen. |
|
||||
| TOTP-PIN | Zeitbasiertes Einmalpasswort (Google-Authenticator-Verfahren) gegen den in `Sichbenu.TwoFactorAuthKey` hinterlegten Schlüssel. |
|
||||
| TradePool | Separater, per XML befüllter Katalog von Handelsartikeln (`TradeArticles`) mit Klassenhierarchie; Nutzung unklar. |
|
||||
| TSA | Time Stamping Authority; Zeitstempeldienst (RFC 3161), der Signaturen einen beglaubigten Zeitpunkt hinzufügt. |
|
||||
| Umfrage-Instanz | Antwortleere Kopie einer Umfragevorlage (`SurveyProcessTemplate`) mit Status Open, Objektbezug und verschlüsseltem Zugriffslink. |
|
||||
| UniqueId (`MyDayWorkItem`) | Fachlicher Eindeutigkeitsschlüssel (Type + ObjectI3D bzw. Type + I3D) zur Deduplizierung automatisch erzeugter Zeiteinträge. |
|
||||
| Update-Benachrichtigungsart (`UpdateAvailableNotificationKind`) | Einstellung, die die Zielgruppe von Update-Hinweisen festlegt (keine, Administratoren, ausgewählte Mitarbeiter, alle). |
|
||||
| Verknüpfungsnummer (`ConnectionNumber`) | Fortlaufende Nummer, die mehrere Tickets zu einer Gruppe (`HelpdeskConnections`) bündelt. |
|
||||
| Vertragssonderpreis (`ContractSpecialPrice`) | Preisregel aus einem Vertrag; hat Vorrang vor Kundensonderpreisen. |
|
||||
| VMA (Virtual Mail Assistant) | Mail-Eingangs-Scanner (MailScanner), der Postfächer über Profile abruft und eingehende Mails Workflows zuführt; lizenz- (MailScannerNET) und rechtegeschützt (ACCESS_VMA_MODULE). |
|
||||
| Volltextindex | Datenbanktabelle `ObjectFulltextIndex` mit gestemmten Termen je Objekt; Suche = UND-Verknüpfung von Präfixtreffern. |
|
||||
| Vorab-/Nachberechnung (Billingadvance/Billingarrear) | Abrechnung vor Beginn bzw. nach Ende des Leistungszeitraums. |
|
||||
| Vorgang (DocBee) | Ticket-Äquivalent in DocBee; referenziert über `ObjectExternalReference` mit Typ „DocBee". |
|
||||
| Vorlagen-Fallback | Auflösungsreihenfolge einer Mail-Vorlage: Kunde (Account) → Mitarbeiter → Filiale (Branch) → global → Systemstandard. |
|
||||
| Warenkorb (`ReceiptCart`) | Web-Warenkorb, technisch ein ReceiptOffer (`AngKopf`) mit `IsCart`=true und CartState (`ReceiptCartState`). |
|
||||
| Web-Account (WebAccount) | Externes Portal-Konto/Kundenlogin (Self-Service-/Webportal, ServiceBoard) eines Kunden-/Account-Ansprechpartners, persistiert in Tabelle `WebAccounts`; eigener Login-Typ „Webaccount" mit eigenem Rechtesystem (WEBRIGHT_*, Enum `WebAccountRightsConst`), abgegrenzt vom internen Mitarbeiter-Login (AppUser); besitzt keinen Mitarbeiterkontext und unterliegt Kundenisolation (darf nur Daten des eigenen Kunden sehen). |
|
||||
| Web-Receipt / Web-Angebot | Per Token im Browser bereitgestellter Beleg (Angebot) mit eigenem Zustandsmodell `WebReceiptState` (Annahme/Ablehnung/Änderungswünsche). |
|
||||
| Web-Recht | Berechtigung eines Web-Accounts (Enum `WebAccountRightsConst`, z. B. WEBRIGHT_WEBCART2_CHECK_CART); unabhängig von den Mitarbeiterrechten (`UserRightsConst`, int-I3Ds). |
|
||||
| Werbesperre (`AdvertisingNotAllowed`) | Kennzeichen am Konto, dass keine Werbung zugesendet werden darf. |
|
||||
| XRechnung / XInvoice | Deutsche EN-16931-konforme E-Rechnungs-XML-Ausprägung; erfordert BuyerReference (Leitweg-ID) für B2G. |
|
||||
| Zeit-Signatur | Grafische Kundenunterschrift zu genau einer Zeit (Tabelle `hlpdsk_timer_signature`); Flag `IsSigned` am Timer. |
|
||||
| Zugangsdaten (Access Data) | Im Passwortmanager verwaltete Benutzername/Passwort-Kombinationen für Kundensysteme (Hotline-Custom-Items mit Custom-Properties). |
|
||||
| ZUGFeRD | Hybrides E-Rechnungsformat: E-Rechnungs-XML eingebettet in PDF/A; Versionen 1.0 bis 3.0.1 (XInvoice) im System wählbar; im EDI-Rechnungsimport unterstützt. |
|
||||
| Zulauf | Bereits bestellte, noch nicht gelieferte Menge (Intake) je Artikel/Lager. |
|
||||
| Zuordnung (`TransactionAssignment`) | Verknüpfung Bankumsatz ↔ Beleg mit zugewiesenem Betrag, Heuristik und Buchungsflags. |
|
||||
| Zusatzfeld (`ModuleCustomProperty`) | Konfigurierbares kundenindividuelles Feld je Objektart mit Datentyp, Pflicht- (`IsMandatory`) und Versiegelungskennzeichen (`Sealable`); Werte in EAV-Tabelle `ModuleCustomPropertyValues`. |
|
||||
| Zwischenrechnung | Codierter Zuordnungstyp in `VertragRechKopfZuordnung` für abweichende Kontingentintervalle (`DifferContingentInterval`: none/headMinor/interimMinor/headMajor/interimMajor). |
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
# Hypothesen
|
||||
|
||||
**System:** c-entron ERP-Suite | **Datum:** 2026-08-27
|
||||
|
||||
Diese Datei enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung (`Status: HYPOTHESE`) aus StRS.md, SyRS.md und SwRS.md — deckungsgleich mit den Inline-Markierungen. Je Eintrag die offene Frage, deren Beantwortung die Hypothese bestätigen oder verwerfen würde.
|
||||
|
||||
| ID | Ebene | Titel | Offene Frage (fehlende Information) |
|
||||
|----|-------|-------|-------------------------------------|
|
||||
| SyRS-110 | SyRS | Serverseitige Durchsetzung aller im WPF-Client geprüften Rechte | Existiert für jedes clientseitig geprüfte Recht (insb. UI-Sichtbarkeitsrechte wie EDIT_GLOBAL_PROFILES) eine korrespondierende serverseitige Prüfung in BL oder Webservice? |
|
||||
| SyRS-1119 | SyRS | Zentrale Dateiablage mit Versionierung und Sperrmechanismus | Die serverseitige Durchsetzung (Ablehnung eines zweiten Check-outs, Versionszählung) in der Dokumenten-BL (FileManagement) wurde nicht gelesen; belegt ist nur der Client-Vertrag (ICentronFileSystemConnector). |
|
||||
| SwRS-119 | SwRS | Alt-Passwortverwaltung (PasswordManagementArea) mit Zugriffsprotokoll, aber ohne wirksame Verschlüsselung | Wird PasswordManagementKeyword.Password von einem anderen (Alt-)Client verschlüsselt befüllt, oder liegen die Werte im Klartext vor? Warum wird beim Lesezugriff der ActionType "Create" geloggt? |
|
||||
| SwRS-248 | SwRS | Serverseitige Durchsetzung der Kontoauszugs-Rechte (20800147–20800151) | Existiert eine hier nicht gefundene serverseitige Prüfung (z. B. in einer Webservice-Fassade/Modulfreischaltung), oder sind die Rechte 20800147–20800151 tatsächlich nur UI-wirksam? |
|
||||
| SwRS-350 | SwRS | Durchsetzung der Werbesperre beim Mailingversand | Gibt es im Versandpfad (Mail-Dispatcher/UI-Auswahl) eine erzwungene Filterung auf Werbesperre, oder verlässt sich das System allein auf die manuelle Filterwahl der Empfängerselektion? |
|
||||
| SwRS-354 | SwRS | Manueller Statuswechsel auf „storniert" für Nicht-Rechnungsbelege | Über welchen UI-/BL-Pfad werden Angebote/Aufträge/Lieferscheine storniert, und welche Prüfungen (Rechte, Bestandsrückbuchung, Folgebelege) werden dabei erzwungen? |
|
||||
| SwRS-451 | SwRS | TradePool-Artikelimport aus XML-Dateien | Wird der TradePool produktiv noch genutzt und was ist der fachliche Zweck (kundenübergreifende Handelsbörse vs. interner Katalog)? Kein aufrufendes UI-Modul im Cluster gefunden. |
|
||||
| SwRS-545 | SwRS | Automatische Auswertung eingehender Meldungen gegen Expected Events | Welche Komponente (vermutlich ein externer Dienst oder RiverDivo-Integration) wertet eingehende Meldungen gegen die MessageContains*-Muster aus und erzeugt ExpectedEventLogEntries bzw. Tickets? |
|
||||
| SwRS-637 | SwRS | Berechtigungsprüfung der Kundengeräteverwaltung | Wird der Zugriff auf die Geräteverwaltung an anderer Stelle (WPF-Client-Menürechte, API-Gateway, Lizenz) durchgesetzt, oder ist die Operation tatsächlich ungeschützt? |
|
||||
| SwRS-740 | SwRS | Getrennte Persistenz von Betreff-Schalter und Betreff-Text der Outlook-Termine | Ist die Nutzung von HolidayRequestedEmailSubject als Bool-Schalter beabsichtigte Wiederverwendung eines freien Schlüssels oder ein Copy-Paste-Fehler, und liest ein anderes Modul denselben Schlüssel mit Urlaubs-Semantik? |
|
||||
| SwRS-748 | SwRS | Social-Media-Interaktionen über Datenbankprozeduren | Welche Regeln (Berechtigung, Dubletten, Benachrichtigung) implementieren die Stored Procedures AddCommentToASocialMediaAction/LikeAStreamOrAction, und ist socialKind = 0 für Actions ein Fehler? |
|
||||
| SwRS-848 | SwRS | Fehlender Seitenschutz der Produktionsübersicht | Existiert an anderer Stelle (Middleware, Host-Konfiguration, Reverse Proxy) ein Schutz der Route /production/overview, oder ist die Seite tatsächlich anonym erreichbar? |
|
||||
| SwRS-947 | SwRS | Berechtigungsschutz für die Pflege von Integrationsstammdaten (D!VE-Profile, ES-Kundengruppen) | Greift für v1/telekom-dive und v1/integrations/es-* eine globale Autorisierung (z. B. Authentifizierungspflicht in Centron.Host/Middleware) oder genügt heute jede gültige Anmeldung für Schreibzugriffe? |
|
||||
| SwRS-1043 | SwRS | Reportserver: automatisierter Reportversand per E-Mail über Aufgaben | Wo (welcher Dienst/Serverprozess) führt die geplanten Aufgaben aus und mit welcher Render-/Mail-Logik — der ausführende Code wurde im Cluster nicht gefunden. |
|
||||
| SwRS-1147 | SwRS | Doppelte Entitätsklassen für den Firmenmandanten (Tabelle Mandant) | Ist „Mandant" ausschließlich Belegabsender (eigene Firma) ohne datenraumtrennende Mehrmandantenfähigkeit, und wird die Alt-Tabelle MandantenStammdat noch verwendet? |
|
||||
| SwRS-1233 | SwRS | Serverseitige Rechteprüfung beim Speichern von Mandantenstammdaten | Prüft die aufrufende REST-Schicht (CentronRestService) oder MandatorBL.SaveMandatory das Recht Administration.MANDATORY serverseitig, oder verlässt sich das System allein auf die Client-UI? |
|
||||
+1201
File diff suppressed because it is too large
Load Diff
+5552
File diff suppressed because it is too large
Load Diff
+2893
File diff suppressed because it is too large
Load Diff
+324
@@ -0,0 +1,324 @@
|
||||
# Traceability
|
||||
|
||||
**System:** c-entron ERP-Suite | **Datum:** 2026-08-27
|
||||
|
||||
Forward-/Backward-Traceability zwischen StRS ↔ SyRS ↔ SwRS. Jede SwRS-Anforderung referenziert ihre SyRS, jede SyRS ihre StRS. Eine Zeile pro Kette; der Artefaktbeleg ist der Hauptbeleg der jeweils spezifischsten Anforderung. Nummernkreise: A1=1xx, A2=2xx, A3=3xx, A4=4xx, A5=5xx, A6=6xx, A7=7xx, A8=8xx, A9=9xx, A10=10xx, A11=11xx, A12=12xx.
|
||||
|
||||
## A1 — Sicherheit, Identität, Berechtigungen
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-101 | SyRS-101 | SwRS-101 | Centron.BL\Administration\Rights\AppRightsBL.cs → HasUserRight (SQL Sichtrus⋈Sichmemb) |
|
||||
| StRS-101 | SyRS-101 | SwRS-105 | Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs → OnAuthorization (401/403) |
|
||||
| StRS-101 | SyRS-102 | SwRS-102 | SSMS_DB_SCHEMA.sql → CREATE TABLE dbo.Sichrech/Sichgrup/Sichmemb/Sichtrus |
|
||||
| StRS-101 | SyRS-102 | SwRS-103 | AppRightsBL.cs → SaveRightGroup/DeleteRightGroup (UserRightsManagement-Prüfungen, Admin-Gruppen-Schutz) |
|
||||
| StRS-101 | SyRS-102 | SwRS-104 | AppRightsBL.cs → WriteAddRightToGroupLog/WriteBaseLog (AppRightLog) |
|
||||
| StRS-101 | SyRS-110 | — | Centron.WPF.UI\Extensions\RibbonControlExtensions.cs → nur clientseitige Rechteprüfung |
|
||||
| StRS-102 | SyRS-103 | SwRS-109 | Centron.BL\Administration\Logins\TicketBL.cs → GetExpireDate/RefreshTicketExpireDate |
|
||||
| StRS-102 | SyRS-104 | SwRS-106 | OpenIdConnectAuthenticator.cs → AppUser-Lookup über OpenIdConnectSubjectIdentifier |
|
||||
| StRS-102 | SyRS-104 | SwRS-107 | BasicAuthenticator.cs → SHA1Decoder.GetDecodedSHA1String + Passwortvergleich |
|
||||
| StRS-102 | SyRS-104 | SwRS-110 | UsersBL.cs → ChangeOwnPassword/IsValidAppUserPassword |
|
||||
| StRS-102 | SyRS-105 | SwRS-112 | TwoFactorAuthBL.cs → HasToValidateTwoFactor |
|
||||
| StRS-102 | SyRS-105 | SwRS-113 | EmailTwoFactorValidator.cs + TwoFactorAuthController.cs → /2fa/validate |
|
||||
| StRS-102 | SyRS-105 | SwRS-114 | TwoFactorAuthenticationBL.cs → ValidateAuthenticationPin (GoogleAuthenticator) |
|
||||
| StRS-102 | SyRS-106 | SwRS-111 | WebAccountBL.cs → LoginWithWebAccount (Statuskette) |
|
||||
| StRS-102 | SyRS-107 | SwRS-108 | Authenticator.cs → ValidateAppUser (Deaktivierungsfenster) |
|
||||
| StRS-103 | SyRS-108 | SwRS-115 | PasswordManagerBL.cs → ValidateUserRights + Guideline-Rechteprüfungen |
|
||||
| StRS-103 | SyRS-108 | SwRS-116 | PasswordManagerBL.cs → EXPORT_ACCESS_AND_PASSWORD_DATA-Prüfung vor Export |
|
||||
| StRS-103 | SyRS-108 | SwRS-117 | AESCryptoLogic.cs → EncryptText/GetKeyAndIV (inkl. Fallback-Key) |
|
||||
| StRS-103 | SyRS-108 | SwRS-118 | Centron.Controls\PasswordManager\AccessManagementViewModel.cs → SealBreakPropertyValue |
|
||||
| StRS-103 | SyRS-108 | SwRS-119 | PasswordManagementKeywordBL.cs → GetDecryptedKeywordById (fehlende Entschlüsselung) |
|
||||
| StRS-104 | SyRS-109 | SwRS-120 | DataSecurityBL.cs → DoDeleteContactPerson + Löschprotokoll |
|
||||
| StRS-104 | SyRS-109 | SwRS-121 | DataSecurityBL.cs → ACCESS_CLEANUP_DATABASE-Prüfung |
|
||||
| StRS-104 | SyRS-109 | SwRS-122 | DsgvoBL.cs → ORDER_PROCESSING_CONTRACTS_MANAGEMENT-Prüfung |
|
||||
|
||||
## A2 — Finanzen & Abrechnung
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-201 | SyRS-206 | SwRS-233 | AutomaticFacturaBL.Contracts.cs: NextDate/SetInvoiceTo/NormalizeCoefficient (Z. 1375–1583) |
|
||||
| StRS-201 | SyRS-206 | SwRS-235 | AutomaticFacturaBL.Contracts.cs: SearchBillingContracts (Z. 847–970) |
|
||||
| StRS-201 | SyRS-206 | SwRS-236 | AutomaticFacturaBL.Contracts.cs: StoreInvoiceToContract ToDo-Teil (Z. 1310–1336) |
|
||||
| StRS-201 | SyRS-207 | SwRS-232 | ContractBL.cs: GetContingentRest (Z. 60–83) |
|
||||
| StRS-201 | SyRS-207 | SwRS-234 | AutomaticFacturaBL.Contracts.cs: StoreBookedContingent (Z. 1098–1245) |
|
||||
| StRS-201 | SyRS-208 | SwRS-230 | ContractBL.cs: RefreshContractEndeDate (Z. 1067–1177) |
|
||||
| StRS-201 | SyRS-208 | SwRS-231 | ContractBL.cs: CloseContract (Z. 1243–1316) |
|
||||
| StRS-201 | SyRS-209 | SwRS-251 | DeviceClickCounterBL.cs: GetAndUpdateDeviceClickCounter (Z. 234–270) |
|
||||
| StRS-201 | SyRS-210 | SwRS-254 | HelpdeskTimerWebServiceBL.cs: ThrowIfUserDoesntHaveRightToChangeHelpdeskTimers (Z. 348–376) |
|
||||
| StRS-202 | SyRS-211 | SwRS-237 | DunningRunBL.cs: UpdateInvoice (Z. 248–275) |
|
||||
| StRS-202 | SyRS-211 | SwRS-238 | DunningRunBL.cs: SaveDunningRun (Z. 277–315); Tabelle Mahnlauf |
|
||||
| StRS-202 | SyRS-211 | SwRS-241 | DunningRunBL.cs: GenerateMail (Z. 406–451) |
|
||||
| StRS-202 | SyRS-212 | SwRS-239 | DunningBL.cs: GetDunningStopActive (Z. 170–182); cvw_InvoiceDunning NextDueDate |
|
||||
| StRS-202 | SyRS-212 | SwRS-243 | DunningBL.cs: CalculateDunningStatistics (Z. 205–236) |
|
||||
| StRS-202 | SyRS-213 | SwRS-242 | PaymentsBL.cs: DeleteIncomingPayment (Z. 38–78) |
|
||||
| StRS-202 | SyRS-214 | SwRS-244 | OnlineBankingAccountTransactionsBL.cs: SaveOnlineBankingAccountTransactions (Z. 294–340) |
|
||||
| StRS-202 | SyRS-214 | SwRS-245 | OnlineBankingAccountTransactionsBL.cs: CheckForCompleted (Z. 342–360) |
|
||||
| StRS-202 | SyRS-214 | SwRS-246 | OnlineBankingAccountTransactionsBL.cs: AutoCompleteSingleAccountTransaciton (Z. 581–617) |
|
||||
| StRS-202 | SyRS-214 | SwRS-247 | OnlineBankingAccountTransactionsBL.cs: BookAmountToAssignedInvoice (Z. 1042–1086) |
|
||||
| StRS-202 | SyRS-214 | SwRS-248 | ScriptMethod11560.cs (Rechteanlage, TODO-Kommentar) |
|
||||
| StRS-202 | SyRS-215 | SwRS-244 | FinApiClient.cs: LoadAccountTransactions (Z. 266 ff.); OnlineBankingFinApiBL.cs Z. 29–50 |
|
||||
| StRS-203 | SyRS-216 | SwRS-249 | BookKeepingExportBL.cs: IsReceiptExported (Z. 209–226); PORTRECH/PORTWARE |
|
||||
| StRS-203 | SyRS-216 | SwRS-250 | BookKeepingExportBL.cs: GetReceiptsBookingdataExportFile (Z. 443–544) |
|
||||
| StRS-203 | SyRS-216 | SwRS-253 | CustomerCostCenterBL.cs: DeleteCustomerCostCenter (Z. 42–54) |
|
||||
| StRS-203 | SyRS-216 | SwRS-255 | NamedQueryPool.xml: VoucherManagementGetVoucherArticles (Z. 680–709) |
|
||||
| StRS-204 | SyRS-217 | SwRS-252 | SepaContractOnlinePdfDocumentHandler.cs: Confirm (Z. 78–178) |
|
||||
| StRS-205 | SyRS-218 | SwRS-242 | PaymentsBL.cs: Rechteprüfung 10980 (Z. 43–44) |
|
||||
| StRS-205 | SyRS-218 | SwRS-248 | CheckForUnknownIbanViewModel.cs: CheckUserRightsAsync (Z. 83–101) |
|
||||
| StRS-205 | SyRS-218 | SwRS-254 | HelpdeskTimerWebServiceBL.cs: EDIT_TIME/OWN_TIME_EDIT (Z. 348–376) |
|
||||
|
||||
## A3 — Vertrieb & Belegwesen
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-301 | SyRS-310 | SwRS-331 | OfferSpecificLogic.CanBeForwardedInto() (Zeile 314) |
|
||||
| StRS-301 | SyRS-310 | SwRS-332 | ReceiptBL.ValidateReceiptForwarding() (Zeile 2462) |
|
||||
| StRS-301 | SyRS-310 | SwRS-333 | ReceiptBL.ForwardReceipt() (Zeile 1548, UpdateReceiptNumber Zeile 1643) |
|
||||
| StRS-301 | SyRS-311 | SwRS-330 | Centron.Interfaces\Sales\Receipts\ReceiptState.cs |
|
||||
| StRS-301 | SyRS-311 | SwRS-343 | ReceiptBL.CreateNewVersion<T>() (Zeile 3068) |
|
||||
| StRS-301 | SyRS-311 | SwRS-344 | AutomaticallyCloseReceiptHelperBL.ItemIsFinished() |
|
||||
| StRS-302 | SyRS-312 | SwRS-334 | NumberGroupBL.GetNextNumber() (bedingtes UPDATE, Zeile 80) |
|
||||
| StRS-302 | SyRS-312 | SwRS-335 | InvoiceSpecificLogic.GetNumberGroup() (Zeile 104) |
|
||||
| StRS-302 | SyRS-313 | SwRS-336 | ReceiptPriceHelper.CalculateReceiptVatPrices() (Zeile 61) |
|
||||
| StRS-302 | SyRS-313 | SwRS-337 | ReceiptBL.CheckIfAllArticlePositionsHaveVatRate() |
|
||||
| StRS-302 | SyRS-314 | SwRS-338 | ReceiptInvoiceBL.CancelInvoice() (Zeile 143, Recht Zeile 154) |
|
||||
| StRS-302 | SyRS-314 | SwRS-339 | ReceiptInvoiceBL.FixInvoice() (UPDATE RechKopf SET IsFixed=1) |
|
||||
| StRS-302 | SyRS-314 | SwRS-354 | ReceiptItemBL.cs Zeile 2954 (Sperre stornierter Belege) |
|
||||
| StRS-302 | SyRS-315 | SwRS-340 | ReceiptBL.CanUserEditReceipt() (Zeile 10273) |
|
||||
| StRS-302 | SyRS-316 | SwRS-341 | DunningRunBL (Mahnstufen-Switch Zeilen 253–268) |
|
||||
| StRS-302 | SyRS-316 | SwRS-342 | ReceiptBL.CheckIfCustomerLimitIsReached() |
|
||||
| StRS-302 | SyRS-321 | SwRS-353 | ReceiptBL.GetReceiptConditionText() (Zeile 8500) |
|
||||
| StRS-303 | SyRS-317 | SwRS-345 | ReceiptItemPriceBL.GetBasePrice() (Zeile 154) |
|
||||
| StRS-303 | SyRS-317 | SwRS-346 | ReceiptItemPriceBL.GetSpecialPrice() (Zeile 588) + CustomerSpecialPriceMaps (KundenSonderpreise) |
|
||||
| StRS-303 | SyRS-317 | SwRS-347 | ReceiptBL.CheckArticleMinPrices() (Zeilen 9036–9130) |
|
||||
| StRS-304 | SyRS-318 | SwRS-351 | InvoiceZugferdBL.GenerateZugferdFile() (Zeile 124) |
|
||||
| StRS-304 | SyRS-318 | SwRS-352 | ZugferdImportController.cs ([Authorize], POST parse) |
|
||||
| StRS-305 | SyRS-319 | SwRS-349 | MailingDataBL.SaveMailingData() (Version=2, Zeile 78) |
|
||||
| StRS-305 | SyRS-319 | SwRS-350 | AccountSearchBL (AdvertisingNotAllowed-Filter, Zeilen 993–1011) |
|
||||
| StRS-305 | SyRS-320 | SwRS-348 | SSMS_DB_SCHEMA.sql, CustomerProductMatrixRating/ChangeLogs (Zeilen 36519/36535) |
|
||||
|
||||
## A4 — Artikel, Lager, Einkauf, Logistik, RMA
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-401 | SyRS-410 | SwRS-435 | SSMS_DB_SCHEMA.sql, cvw_BarcodeCount (Status in (1,2,8)) |
|
||||
| StRS-401 | SyRS-410 | SwRS-436 | SSMS_DB_SCHEMA.sql, Tabelle NebenlagerArtikel |
|
||||
| StRS-401 | SyRS-410 | SwRS-441 | BarcodeBL.ValidateNewBarcode |
|
||||
| StRS-401 | SyRS-410 | SwRS-443 | BarcodeBL.GetSystemSNID |
|
||||
| StRS-401 | SyRS-411 | SwRS-430 | ArticleBL.CheckUserRightBeforeSave |
|
||||
| StRS-401 | SyRS-411 | SwRS-431 | ArticleBL.SaveArticle (Duplikat-/Längenprüfung) |
|
||||
| StRS-401 | SyRS-411 | SwRS-432 | ArticleStockBL.UpdateArticlePurchasePrice |
|
||||
| StRS-401 | SyRS-411 | SwRS-433 | SecondStockArticleBL.RebookStockArticle (TRANSFER_STOCK) |
|
||||
| StRS-401 | SyRS-412 | SwRS-434 | SecondStockArticleBL.StockBookOrBookout (ARTIKlog) |
|
||||
| StRS-401 | SyRS-412 | SwRS-442 | BarcodeBL.CheckOutBarCodes |
|
||||
| StRS-401 | SyRS-413 | SwRS-437 | InventoryNewBL.CloseInventory |
|
||||
| StRS-401 | SyRS-413 | SwRS-438 | InventoryBL.CloseStorages |
|
||||
| StRS-402 | SyRS-414 | SwRS-444 | OrderSuggestionListBL, _sqlArticle |
|
||||
| StRS-402 | SyRS-415 | SwRS-445 | EDIDispatcherBL.CreateEDISuggestionOrderAsync |
|
||||
| StRS-402 | SyRS-415 | SwRS-446 | SupplierEdiBL.SaveReceiptItemAssignments |
|
||||
| StRS-402 | SyRS-418 | SwRS-450 | IceCatImportService.GetArticleAsync |
|
||||
| StRS-402 | SyRS-418 | SwRS-451 | TradePoolBL.StartTradeImport |
|
||||
| StRS-403 | SyRS-419 | SwRS-439 | OrderCommissionBL.HasUserRightsTooAccessCommissionModule |
|
||||
| StRS-403 | SyRS-419 | SwRS-440 | OrderCommissionBL.ExecuteCommissionForOrders |
|
||||
| StRS-403 | SyRS-416 | SwRS-447 | CentronGlsLogic.DoValidateShipment |
|
||||
| StRS-403 | SyRS-416 | SwRS-448 | CentronShipcloudLogic.CreateShipmentAsync |
|
||||
| StRS-404 | SyRS-417 | SwRS-449 | RmaBL.SaveRma |
|
||||
|
||||
## A5 — Helpdesk & Service
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-501 | SyRS-511 | SwRS-531 | HelpdeskStatusBL.DeleteHelpdeskStatus() |
|
||||
| StRS-501 | SyRS-511 | SwRS-532 | HelpdeskCloseBL.CloseHelpdeskForNotificationMethods() |
|
||||
| StRS-501 | SyRS-511 | SwRS-549 | TicketProjectBL.SaveOrUpdateTicketProject() |
|
||||
| StRS-501 | SyRS-511 | SwRS-550 | HelpdeskConnectionNumberBL.EnsureHelpdeskConnection() |
|
||||
| StRS-501 | SyRS-512 | SwRS-533 | HelpdeskBL.CheckUserRigths() |
|
||||
| StRS-501 | SyRS-512 | SwRS-534 | HelpdeskBL.CheckWebRights() |
|
||||
| StRS-501 | SyRS-512 | SwRS-535 | HelpdeskBL.DoValidateMandatoryFields() |
|
||||
| StRS-501 | SyRS-513 | SwRS-536 | HelpdeskBL.GetDueDateFromPriority() |
|
||||
| StRS-501 | SyRS-514 | SwRS-537 | EscalationBL.CheckEskalationStage()/UpdateTicket() |
|
||||
| StRS-501 | SyRS-520 | SwRS-543 | CentronChecklistBL.ObjectHasOpenChecklists() |
|
||||
| StRS-502 | SyRS-515 | SwRS-538 | HelpdeskTimerWebServiceBL.ThrowIfUserDoesntHaveRightToChangeHelpdeskTimers() |
|
||||
| StRS-502 | SyRS-515 | SwRS-539 | HelpdeskTimerBL.DeleteHelpdeskTimer() |
|
||||
| StRS-502 | SyRS-515 | SwRS-542 | HelpdeskTimerWebServiceBL.CheckTimerCanBeMoved() |
|
||||
| StRS-502 | SyRS-516 | SwRS-540 | HelpdeskTimerSignatureBL.SignMultipleTimers() |
|
||||
| StRS-502 | SyRS-516 | SwRS-541 | HelpdeskTimerSignatureBL.RemoveSignatureFromTime() |
|
||||
| StRS-503 | SyRS-517 | SwRS-544 | ExpectedEventsBL.SaveExpectedEvent() |
|
||||
| StRS-503 | SyRS-517 | SwRS-545 | ExpectedEventsMaps.cs (Mapping MessageContains*) |
|
||||
| StRS-503 | SyRS-517 | SwRS-547 | TaskManagementHelpdeskActionHandler.Execute() |
|
||||
| StRS-504 | SyRS-518 | SwRS-546 | SelfCareBL.GetWebFormByGuid() |
|
||||
| StRS-504 | SyRS-519 | SwRS-548 | SurveyProcessBL.GetSurveyfromTemplate() |
|
||||
|
||||
## A6 — Stammdaten & Assets
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-601 | SyRS-605 | SwRS-620 | Centron.BL\Accounts\AccountBL.cs, ValidateUserRights |
|
||||
| StRS-601 | SyRS-605 | SwRS-624 | Centron.BL\Accounts\AccountAddressBL.cs, CheckSpecialUserRightForAddressLanguageBeforeSave |
|
||||
| StRS-601 | SyRS-605 | SwRS-625 | Centron.BL\Accounts\AccountAddressContactBL.cs, AccountSaveAddressContact |
|
||||
| StRS-601 | SyRS-606 | SwRS-621 | Centron.BL\Accounts\AccountBL.cs, GetNewAccount |
|
||||
| StRS-601 | SyRS-606 | SwRS-622 | SSMS_DB_SCHEMA.sql, IX_Accounts_Number / IX_AccountCustomers_UniqueNumber |
|
||||
| StRS-601 | SyRS-606 | SwRS-623 | Centron.BL\Accounts\AccountBL.cs, DeleteAccount |
|
||||
| StRS-601 | SyRS-606 | SwRS-626 | Centron.BL\Accounts\AccountAddressBL.cs, GetNotImportedGeoInfoList |
|
||||
| StRS-602 | SyRS-607 | SwRS-627 | Centron.BL\EmployeeArea\AppUserBL.cs, SaveOrUpdateAppUser |
|
||||
| StRS-602 | SyRS-607 | SwRS-629 | Centron.BL\EmployeeArea\AppUserBL.cs, GetActiveAppUsers |
|
||||
| StRS-602 | SyRS-608 | SwRS-628 | Centron.BL\EmployeeArea\EmployeeBL.cs, SaveOrUpdateEmployee |
|
||||
| StRS-603 | SyRS-609 | SwRS-630 | Centron.BL\Sales\CustomerAssets\Contracts\ClickContracts\MasterDataListBL.cs, SaveMasterDataList |
|
||||
| StRS-603 | SyRS-609 | SwRS-631 | ebd., RemoveMainDeviceSerialNumber / SwapMainDeviceSerialNumber |
|
||||
| StRS-603 | SyRS-609 | SwRS-633 | Centron.Entities\Entities\Sales\Receipts\MasterDataLists\MasterDataList.cs vs. Entities\Devices\AccountDevice.cs |
|
||||
| StRS-603 | SyRS-610 | SwRS-632 | Centron.BL\Devices\AccountDeviceBL.cs, DeleteAccountDevice |
|
||||
| StRS-603 | SyRS-610 | SwRS-637 | Centron.BL\Devices\AccountDeviceBL.cs (Negativbefund Rechteprüfung) |
|
||||
| StRS-604 | SyRS-611 | SwRS-635 | Centron.BL\Tags\TagsBL.cs, AddTicketTag |
|
||||
| StRS-604 | SyRS-611 | SwRS-636 | Centron.BL\Administration\Customization\ModuleCustomPropertyBL.cs, SaveCustomPropertyStructure |
|
||||
| StRS-604 | SyRS-612 | — | Centron.BL\ObjectExternalReferences\ObjectExternalReferenceBL.cs, CreateReference |
|
||||
| StRS-604 | SyRS-613 | SwRS-634 | Centron.BL\CountryArea\CountryBL.cs, UpdateCurrencyRateByRateDictionary |
|
||||
|
||||
## A7 — Kommunikation & persönliche Organisation
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-701 | SyRS-711 | SwRS-731 | Centron.BL\Mail\Factory\CentronMailFactory.cs, GetMail() |
|
||||
| StRS-701 | SyRS-711 | SwRS-732 | Centron.BL\Mail\Protocols\SMTPMail.cs, CreateSmtpClient() |
|
||||
| StRS-701 | SyRS-711 | SwRS-733 | Centron.BL\Mail\Protocols\SMTPMail.cs, CreateMailMessage() |
|
||||
| StRS-701 | SyRS-711 | SwRS-734 | Centron.BL\Mail\Protocols\SMTPMail.cs, FillMailBodyOld() |
|
||||
| StRS-701 | SyRS-711 | SwRS-735 | Centron.BL\Mail\Blacklist\DomainBlacklistBL.cs, IsBlacklisted() |
|
||||
| StRS-701 | SyRS-712 | — | Centron.BL\WebServices\Mail\SendMailWebserviceBL.cs, CheckFromAdress() |
|
||||
| StRS-701 | SyRS-713 | SwRS-736 | Centron.BL\Mail\Templates\MailTemplateBL.cs, MailTemplate() (Fallback-Kommentar Z. 248–255) |
|
||||
| StRS-701 | SyRS-713 | SwRS-737 | Centron.BL\Mail\Templates\MailTemplateBL.cs, GenerateVariables() |
|
||||
| StRS-701 | SyRS-714 | SwRS-738 | Centron.BL\MailScanner\MailScannerBL.cs, GetProfiles() / EncryptProperties() |
|
||||
| StRS-702 | SyRS-715 | SwRS-739 | Centron.BL\AppointmentRequests\AppointmentRequestBL.cs, HandleAppointmentRequestReply() |
|
||||
| StRS-702 | SyRS-716 | SwRS-740 | Centron.BL\Calendar\CalendarBL.cs, GetCalendarSynchronizationSettings() |
|
||||
| StRS-704 | SyRS-717 | SwRS-741 | Centron.BL\Tapi\PhoneCallBL.cs, SearchContactPersonByPhoneNumberV2() |
|
||||
| StRS-704 | SyRS-717 | SwRS-742 | Centron.BL\Tapi\PhoneCallBL.cs, SyncPhoneCalls() (Lizenzprüfung) |
|
||||
| StRS-704 | SyRS-718 | SwRS-743 | Centron.BL\Chats\ChatBL.cs, GetFilterExpression() (OnlyOwn/Membership) |
|
||||
| StRS-703 | SyRS-718 | SwRS-744 | Centron.BL\NexusNotifications\NexusNotificationsBL.cs, MarkAllNexusNotificationsAsRead() |
|
||||
| StRS-703 | SyRS-718 | SwRS-748 | Centron.BL\SocialMedia\SocialMediaBL.cs, AddCommentToASocialMediaAction() |
|
||||
| StRS-703 | SyRS-719 | SwRS-745 | Centron.BL\ToDoArea\ToDoBL.cs, GetTodosThroughPaging() (RIGHT_FREMDTODOLISTE) |
|
||||
| StRS-703 | SyRS-719 | SwRS-746 | Centron.BL\MyDay\MyDayBL.cs, SaveOrUpdateWorkItem() (UniqueId-Dedup) |
|
||||
| StRS-703 | SyRS-719 | SwRS-747 | Centron.BL\VideoPortal\VideoPortalAssignmentBL.cs, SaveVideoPortalAssignment() |
|
||||
|
||||
## A8 — Web-Client Nexus & Service-Schnittstellen
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-801 | SyRS-811 | SwRS-839 | src\nexus\CentronNexus\Shared\Authorization\ClaimsService.cs (GetClaims) |
|
||||
| StRS-801 | SyRS-811 | SwRS-840 | src\nexus\CentronNexus\Shared\Authorization\PortAuthorization.cs (PortHandler) |
|
||||
| StRS-802 | SyRS-811 | SwRS-848 | src\nexus\CentronNexus\ProductionOrderManagement\Pages\ProductionOrderOverView.razor (fehlendes Authorize-Attribut) |
|
||||
| StRS-801 | SyRS-812 | SwRS-841 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs (ThrowIfCanNotAccessCart) |
|
||||
| StRS-801 | SyRS-812 | SwRS-842 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartReleaseSystemBL.cs (OrdererApproveCart) |
|
||||
| StRS-801 | SyRS-813 | SwRS-843 | src\nexus\CentronNexus\WebOffer\WebReceiptOverview.razor (ChangeWebReceiptState) |
|
||||
| StRS-801 | SyRS-814 | SwRS-844 | src\backend\Centron.BL\Administration\Documents\Dsgvo\DsgvoBL.cs (ConfirmOnlinePdfDocument) |
|
||||
| StRS-801 | SyRS-815 | SwRS-845 | src\backend\Centron.BL\Sales\Support\HelpdeskSearchBL.cs (IsWebAccountLogin-Filter) |
|
||||
| StRS-802 | SyRS-816 | SwRS-846 | src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs (CloseHelpdesk) |
|
||||
| StRS-802 | SyRS-816 | SwRS-847 | src\nexus\CentronNexus\ProductionOrderManagement\Components\WorkStepTemplateComponent.razor (FinishWorkstep) |
|
||||
| StRS-803 | SyRS-817 | SwRS-831 | src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs (OnAuthorization) |
|
||||
| StRS-803 | SyRS-817 | SwRS-832 | src\webservice\Centron.Controllers\Authorization\CentronHostedAuthorization.cs (HandleRequirementAsync) |
|
||||
| StRS-803 | SyRS-817 | SwRS-833 | src\webservice\Centron.Controllers\Controllers\Unversioned\JwtAuthController.cs (LoginWithBearer) |
|
||||
| StRS-803 | SyRS-817 | SwRS-834 | src\webservice\Centron.Controllers\Controllers\Unversioned\TwoFactorAuthController.cs (ValidateTwoFactorCode) |
|
||||
| StRS-803 | SyRS-817 | SwRS-835 | src\backend\Centron.BL\WebServices\Administration\Logins\WebAccountWebServiceBL.cs (HasUserRight WEBACCOUNT_MANAGEMENT) |
|
||||
| StRS-803 | SyRS-818 | SwRS-836 | src\webservice\Centron.Host\AspNetCore\WcfBridge\Interception\Interceptors\AuthenticateInterceptor.cs (InterceptExecution) |
|
||||
| StRS-803 | SyRS-818 | SwRS-849 | src\backend\Centron.BL\Mobile\MobileBL.cs (GetMobileEmployee) |
|
||||
| StRS-803 | SyRS-818 | SwRS-850 | src\backend\Centron.BL\WebLinks\WebLinkActionAccountActivityHandler.cs (Execute) |
|
||||
| StRS-803 | SyRS-819 | SwRS-837 | src\webservice\Centron.Controllers\Configuration\GlobalExceptionFilter.cs (OnException) |
|
||||
| StRS-803 | SyRS-819 | SwRS-838 | src\webservice\Centron.Controllers\Configuration\Routing\KebabCaseTransformer.cs (TransformOutbound) |
|
||||
| StRS-804 | SyRS-820 | — | src\webservice\Centron.Host.Console\Program.cs (CentronHost.Instance.Start) |
|
||||
|
||||
Hinweis: SwRS-848 hängt unter SyRS-811 (Zugriffsschutz) und zusätzlich fachlich unter StRS-802; SwRS-850 ist sekundär auch SyRS-816 zugeordnet (Tracelinks im Block).
|
||||
|
||||
## A9 — Datenaustausch & Integrationen
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-901 | SyRS-911 | SwRS-931 | src\backend\Centron.BL\RiverDivo\RiverDivoBL.cs → ValidateRmmAccessKey (FixedTimeEquals) |
|
||||
| StRS-901 | SyRS-911 | SwRS-933 | src\backend\Centron.BL\RiverDivo\RiverDivoBL.cs → CreateHelpdeskRequest (CreatedFrom = 7) |
|
||||
| StRS-901 | SyRS-911 | SwRS-935 | src\backend\Centron.BL\RiverDivo\RiverDivoBL.cs → GetAllCustomersForSync (ChangedAfterDate, LogoHash) |
|
||||
| StRS-901 | SyRS-912 | SwRS-932 | src\backend\Centron.BL\WebServices\Rmm\RmmConnectionSettingsWebServiceBL.cs → HasUserRight(SETTINGS) |
|
||||
| StRS-901 | SyRS-912 | SwRS-937 | src\backend\Centron.BL\DataExchange\Connectors\DocBeeTicketCreationBL.cs → IsDocBeeActive (Lizenzprüfung) |
|
||||
| StRS-901 | SyRS-912 | SwRS-947 | src\webservice\Centron.Controllers\Controllers\v1\DataExchange\TelekomDiveController.cs → SaveProfiles (ohne Rechteattribut) |
|
||||
| StRS-901 | SyRS-913 | SwRS-934 | src\backend\Centron.BL\RiverDivo\RiverDivoBL.cs → GetCentronCustomerI3D (RiverbirdCustomerReference) |
|
||||
| StRS-901 | SyRS-913 | SwRS-936 | src\backend\Centron.BL\DataExchange\Connectors\DocBeeTicketTimerBL.cs → SaveDocBeeTicketTimer |
|
||||
| StRS-904 | SyRS-913 | SwRS-942 | src\backend\Centron.BL\Integrations\EsCustomerGroupBL.cs → Create/Delete (Soft-Delete) |
|
||||
| StRS-901 | SyRS-913 | SwRS-945 | src\backend\Centron.BL\CPra\CPraConnectorBL.cs → GenerateLink (Base64-Parameter) |
|
||||
| StRS-903 | SyRS-914 | SwRS-938 | src\backend\Centron.BL\DataExchange\DocuForm\DocuFormApiSettingsBL.cs → AES + SETTINGS-Recht |
|
||||
| StRS-903 | SyRS-914 | SwRS-939 | src\centron\Centron.WPF.UI\Modules\Finances\DeviceClickCounter\DocuFormApiImport\DocuFormApiImportViewModel.cs → DownloadDeviceCounters |
|
||||
| StRS-902 | SyRS-915 | SwRS-940 | src\backend\Centron.Entities\Entities\DataExchange\TelekomDive\TelekomDiveProfile.cs |
|
||||
| StRS-902 | SyRS-915 | SwRS-941 | src\centron\Centron.WPF.UI\Modules\TelekomDive\TelekomDiveExportViewModel.cs → ExportToXml |
|
||||
| StRS-902 | SyRS-916 | SwRS-946 | src\backend\Centron.Gateway\DataExchange\BookKeeping\BookKeepingFileExport.cs → PrepareStoreFile |
|
||||
| StRS-904 | SyRS-917 | SwRS-943 | src\backend\Centron.BL\Administration\FileManagement\DirectoryBL.cs → IsDocSyncEnabledForObjectKind |
|
||||
| StRS-904 | SyRS-917 | SwRS-944 | src\centron\Centron.WPF.UI\Modules\DataExchange\DataImport\AccountImport\IbanValidation.cs → IbanChecksumCheck |
|
||||
| StRS-901 | SyRS-918 | — | src\backend\Centron.BL\RiverDivo\RiverConnectionBL.cs → GetActiveDirectoryUsers (WebAccount-Isolationsprüfung) |
|
||||
|
||||
## A10 — Produktion, Projekte, PLM, QM, Statistik, Reporting
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-1001 | SyRS-1010 | SwRS-1030 | ProductionOrderBL.cs: LicenseManager.HasLicense(LicenseGuids.ProductionManagement)-Gate |
|
||||
| StRS-1001 | SyRS-1010 | SwRS-1031 | ProductionBL.cs: Lizenzgate vor Maschinenstammdaten |
|
||||
| StRS-1001 | SyRS-1011 | SwRS-1030 | ProductionOrderItemState.cs / ProductionOrderLogKind.cs |
|
||||
| StRS-1001 | SyRS-1011 | SwRS-1031 | SSMS_DB_SCHEMA.sql: ProductionOrders/ProductionOrderLogs NOT-NULL-Constraints |
|
||||
| StRS-1002 | SyRS-1012 | SwRS-1037 | SaleStatisticBL.GetSalesArticleStatistic: SALES_STATISTIC-Prüfung |
|
||||
| StRS-1002 | SyRS-1012 | SwRS-1038 | ManagementInfoBL: MANAGEMENT_INFO_ONLY_OWN_BRANCH-Zwangsfilter |
|
||||
| StRS-1002 | SyRS-1012 | SwRS-1046 | ModulesSlideViewModel.cs: Gruppierung/Suche/Favoriten |
|
||||
| StRS-1002 | SyRS-1013 | SwRS-1041 | ReportDataBL.ExecuteQuery: Regex-Variablenersetzung |
|
||||
| StRS-1002 | SyRS-1013 | SwRS-1042 | SSMS_DB_SCHEMA.sql: Tabellen ReportData und Reports |
|
||||
| StRS-1002 | SyRS-1013 | SwRS-1043 | ReportServerAppModuleController.Description + ReportServerConnector |
|
||||
| StRS-1002 | SyRS-1014 | SwRS-1041 | ReportDataWebBL.ReportEngineExecuteQuery: SQL_MANAGER/REPORT_MANAGEMENT-Prüfung |
|
||||
| StRS-1002 | SyRS-1019 | SwRS-1032 | ProjectManagementViewModel.RefreshAsync/RefreshEmployeeWorkload |
|
||||
| StRS-1003 | SyRS-1015 | SwRS-1033 | ProjectPriceImportViewModel: Fehlerliste + SpecialAgreementDifferenceViewModel |
|
||||
| StRS-1003 | SyRS-1015 | SwRS-1044 | MassUpdateBL.StartReceiptPriceUpdate: ReceiptState.Active-Prüfung |
|
||||
| StRS-1003 | SyRS-1015 | SwRS-1045 | MassUpdateBL.StartArticlePriceUpdate: Bulkchanger-Log |
|
||||
| StRS-1003 | SyRS-1016 | SwRS-1036 | ReceiptBL.CheckIfAssetReasonIsNeeded: IsMandatory-Prüfung |
|
||||
| StRS-1004 | SyRS-1017 | SwRS-1039 | MspCollectorsBL.MspDowloadStart: Duplikatprüfung MspCollectorInvoiceHead |
|
||||
| StRS-1004 | SyRS-1017 | SwRS-1040 | MspCollectorsBL.UpdateMspContractItem: MspEvaluationDecision-Switch |
|
||||
| StRS-1004 | SyRS-1017 | SwRS-1047 | AssetManagementArticleAssignmentBL: Löschschutz bei Vertragsreferenz |
|
||||
| StRS-1004 | SyRS-1018 | SwRS-1034 | ProductFamilyBL.ImportProductLifecycleInformations: Dedup-Query |
|
||||
| StRS-1004 | SyRS-1018 | SwRS-1035 | ProductFamilyBL: DaysToTolerate-Fristlogik + UserForPLM |
|
||||
|
||||
## A11 — Plattform & Querschnitt
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-1101 | SyRS-1110 | SwRS-1130 | src\backend\Centron.DAO\DAOSession.cs (WithTransaction) |
|
||||
| StRS-1101 | SyRS-1110 | SwRS-1143 | src\centron\Centron.WPF.UI\CentronFileSystem\CentronFileSystemConnector.cs |
|
||||
| StRS-1101 | SyRS-1111 | SwRS-1131 | src\backend\Centron.Entities\PersistedEntity.cs (operator ==) |
|
||||
| StRS-1101 | SyRS-1111 | SwRS-1132 | src\backend\Centron.DAO\DAOFactory.cs:100-127 (AppendListeners) |
|
||||
| StRS-1101 | SyRS-1111 | SwRS-1147 | src\backend\Centron.DAO\Mappings\...\MandatorMaps.cs / MandatoryMaps.cs (Table("Mandant")) |
|
||||
| StRS-1101 | SyRS-1112 | — | tests\Centron.Tests.Integration\IntegrationTest.cs (TestGetHelpdesksThroughPaging) |
|
||||
| StRS-1102 | SyRS-1114 | — | src\centron\Centron.WPF.UI\nlog.config (csvTarget, WARN, 15 Archive) |
|
||||
| StRS-1102 | SyRS-1115 | SwRS-1133 | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
|
||||
| StRS-1102 | SyRS-1115 | SwRS-1134 | src\backend\Centron.DAO\ChangeTracking\LogHourlySurchargeRateChangesListener.cs |
|
||||
| StRS-1102 | SyRS-1115 | SwRS-1135 | SSMS_DB_SCHEMA.sql:34746 (ChangeLog + IX_ChangeLog) |
|
||||
| StRS-1102 | SyRS-1116 | SwRS-1136 | src\backend\Centron.BL\Telemetry\TelemetryBL.cs (MERGE WITH (HOLDLOCK)) |
|
||||
| StRS-1102 | SyRS-1116 | SwRS-1137 | src\backend\Centron.BL\Telemetry\TelemetryBL.cs (InsertMissingNames) |
|
||||
| StRS-1103 | SyRS-1117 | SwRS-1138 | src\backend\Centron.BL\IndexSearch\IndexBuilder.cs |
|
||||
| StRS-1103 | SyRS-1117 | SwRS-1139 | src\backend\Centron.BL\IndexSearch\IndexSearchBL.cs (UpdateIndexesInternal) |
|
||||
| StRS-1103 | SyRS-1117 | SwRS-1140 | SSMS_DB_SCHEMA.sql:45591 (ObjectFulltextIndex/Stats) |
|
||||
| StRS-1103 | SyRS-1118 | SwRS-1141 | src\backend\Centron.BL\ArtificialIntelligence\AiApiLinkValidator.cs |
|
||||
| StRS-1103 | SyRS-1118 | SwRS-1142 | src\backend\Centron.BL\Administration\ArtificialIntelligence\ArtificialIntelligenceBL.cs:184 |
|
||||
| StRS-1104 | SyRS-1113 | — | src\centron\Centron.WPF.UI\ConnectionHeartbeatTimer.cs (TimerTick) |
|
||||
| StRS-1104 | SyRS-1119 | SwRS-1143 | src\centron\Centron.WPF.UI\CentronFileSystem\CentronFileSystemConnector.cs (CheckOutDocument) |
|
||||
| StRS-1104 | SyRS-1120 | SwRS-1144 | src\centron\Centron.WPF.UI\Localization\LocalizationHelper.cs |
|
||||
| StRS-1104 | SyRS-1121 | SwRS-1145 | src\backend\Centron.BL\GUI\Profiles\UiProfileBL.cs:51 |
|
||||
| StRS-1104 | SyRS-1121 | SwRS-1146 | src\backend\Centron.BL\ExternalToolsBL\ExternalToolBL.cs (SaveExternalTool) |
|
||||
|
||||
## A12 — Administration, Konfiguration & Betrieb
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-1201 | SyRS-1211 | SwRS-1231 | MandatorManagementViewModel.DeleteMandatorAsync (State = 0) |
|
||||
| StRS-1201 | SyRS-1211 | SwRS-1232 | MandatorManagementViewModel.IsSetToDefault / EditBranchDetails |
|
||||
| StRS-1201 | SyRS-1211 | SwRS-1233 | MandatorWebServiceBL.SaveMandatoryExtended (fehlende Rechteprüfung) |
|
||||
| StRS-1201 | SyRS-1211 | SwRS-1234 | MandatorManagementViewModel.SaveMandatorInstructionPrompt (Rechteprüfung 10510) |
|
||||
| StRS-1202 | SyRS-1212 | SwRS-1235 | SSMS_DB_SCHEMA.sql [dbo].[ApplicationSettings] |
|
||||
| StRS-1202 | SyRS-1212 | SwRS-1236 | docs\guides\development\settings-management.md + Tabellen Stammdat/ApplicationSettings |
|
||||
| StRS-1202 | SyRS-1212 | SwRS-1245 | ReportDataWebBL.ReportEngineExecuteQuery (Rechteprüfung SQL_MANAGER) |
|
||||
| StRS-1202 | SyRS-1213 | SwRS-1237 | TextModuleBL.GetTextModule (dreistufige Kaskade) |
|
||||
| StRS-1202 | SyRS-1213 | SwRS-1238 | TextModuleBL.ReplaceCustomerTextBlockVariables ("@@") |
|
||||
| StRS-1203 | SyRS-1214 | SwRS-1239 | ManagedBackgroundService.GetIsEnabledCached/GetDelayWithBackoff |
|
||||
| StRS-1203 | SyRS-1214 | SwRS-1240 | DataQualityService.ExecuteService (Task-Isolation) |
|
||||
| StRS-1202, StRS-1203 | SyRS-1215 | SwRS-1241 | EscalationTypeSettingViewModel.EscTypeVM_To_DTO (Hour1-3, StageReceivers) |
|
||||
| StRS-1204 | SyRS-1216 | SwRS-1242 | PdfSigningBL.SavePdfSigningSettings (Rechteprüfung + AES) |
|
||||
| StRS-1204 | SyRS-1216 | SwRS-1243 | PdfSigningBL.SignPdfDocument (Pkcs7Signer/SHA256/TSA) |
|
||||
| StRS-1204 | SyRS-1216 | SwRS-1244 | PdfExportSettingsViewModel.InitializeDropdownLists (PDF/A-Stufen) |
|
||||
| StRS-1203 | SyRS-1217 | SwRS-1248 | docker\compose\compose.yaml + CentronService.cs |
|
||||
| StRS-1202 | SyRS-1218 | SwRS-1246 | HourlySurchargeRateItemViewModel.UpdateInvalidRatesReasons + HourlySurchargeRateLog |
|
||||
| StRS-1203 | SyRS-1219 | SwRS-1247 | UpdateAvailableNotificationBL.ShowUpdatesFor |
|
||||
+1
@@ -0,0 +1 @@
|
||||
{"is_error":false,"duration_api_ms":15462451,"num_turns":2,"stop_reason":"end_turn","session_id":"73f6a03e-8aed-4897-8d13-e9e10ba3a32b","total_cost_usd":205.92314750000008,"usage":{"input_tokens":4,"cache_creation_input_tokens":1791,"cache_read_input_tokens":453523,"output_tokens":2278,"output_tokens_details":{"thinking_tokens":253},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":1791,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":1575,"cache_read_input_tokens":227183,"cache_creation_input_tokens":948,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":948},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6962,"outputTokens":29,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.0071070000000000005,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-fable-5":{"inputTokens":1626,"outputTokens":1343904,"cacheReadInputTokens":92177958,"cacheCreationInputTokens":3603520,"webSearchRequests":0,"costUSD":205.91604050000007,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","origin":{"kind":"task-notification"},"subagent_stats":{"spawned":18,"requested":{"background":0,"foreground":0,"unset":18},"started_in_background":18,"max_depth":1,"spawned_by_subagents":0,"completed":16,"failed":2,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{"general-purpose":18}},"subtype":"success","api_error_status":null,"result":"Der Lauf ist abgeschlossen. Alle sieben Ergebnisdateien liegen im Verzeichnis `Ergebnisse\\` und sind konsistenzgeprüft.\n\n## Ergebnis\n\n**413 Anforderungen** aus der gesamten Codebasis der c-entron ERP-Suite, verteilt auf drei Ebenen nach ISO/IEC/IEEE 29148: **50 StRS**, **122 SyRS**, **241 SwRS** — dazu Traceability (269 Ketten StRS↔SyRS↔SwRS), 16 Hypothesen, 203 Glossarbegriffe und der Analysebericht mit Modulinventar, Abdeckungstabelle und Konsistenzcheck.\n\n**Vorgehen:** Vor der ersten Anforderung wurde ein Modulinventar mit 96 Modulen erstellt (Schritt 0), danach in 12 parallelen Analyse-Clustern (Sicherheit, Finanzen/Abrechnung, Vertrieb, Lager/Einkauf, Helpdesk, Stammdaten, Kommunikation, Web/Schnittstellen, Integrationen, Produktion/Reporting, Plattform, Administration) mit eigenen ID-Nummernkreisen gearbeitet — erst Mindestabdeckung, dann Vertiefung nach Risiko.\n\n**Kennzahlen aus dem skriptgestützten Konsistenzcheck:**\n- Mindestabdeckung erfüllt: alle 96 Module haben ≥1 Anforderung (42 tief, 48 mittel, 6 flach, 0 nicht analysiert)\n- Keine doppelten IDs, keine Anforderung ohne Beleg, Prüfidee oder Übernahmewürdigkeit, keine toten Tracelinks\n- **198 risikorelevante Anforderungen** (Sicherheit/Abrechnung/Berechtigungen): jede mit PRIMÄR-Beleg inkl. durchsetzender Stelle oder als Hypothese gekennzeichnet — 0 Verstöße; die Liste steht vollständig im Analysebericht\n- `Hypothesen.md` deckungsgleich mit den 16 Inline-Markierungen (3,9 % Hypothesenquote)\n- 44 Konsolidierungskandidaten, alle 21 nicht-funktionalen Anforderungen mit ISO-25010-`Qualitätsmerkmal`\n\n**Fachlich wichtigste Befunde:** Der im Prompt genannte Konsolidierungsfall (Stammblätter vs. Assets) wurde bestätigt und auf **drei** Gerätedatenhaltungen erweitert; daneben ~20 weitere Doppelimplementierungen (zwei Berechtigungssysteme, drei E-Rechnungs-Generatoren, Inventur/Kommissionierung alt/neu, zwei Settings-Datenhaltungen u. a.). Für die SaaS-Neuimplementierung kritisch: ungesalzene SHA1-Passworthashes, hartkodierte Secrets (AES-Fallback, finAPI), fehlende datenraumtrennende Mandantenfähigkeit, keine Schreibsperre für festgeschriebene Rechnungen, sowie fünf als Hypothese dokumentierte Verdachtsfälle nur clientseitiger Rechteprüfung.\n\nZwei Hinweise zur Durchführung: Zwei Analyse-Agenten brachen unterwegs an API-Fehlern ab und wurden mit erhaltenem Kontext erfolgreich fortgesetzt; da Shell-Schreibzugriffe auf das Ausgabeverzeichnis von der Rechtekonfiguration verweigert wurden, erfolgte die Zusammenführung der großen Dateien über Subagenten mit dem Write-Tool (jeweils byteidentisch gegen die Quellkonkatenation verifiziert). Die Codebasis selbst wurde ausschließlich gelesen.","ttft_ms":5456,"ttft_stream_ms":3850,"time_to_request_ms":10,"type":"result","duration_ms":36521,"uuid":"466ea4d1-f66d-4d0f-9eaf-aefc1a731d26","queued_turn_count":0}
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+178
@@ -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-27_095953_v7.0.0-6ce6\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-27T11:09:58.0288148+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-27T09:59:53.7439250+02:00
|
||||
+606
@@ -0,0 +1,606 @@
|
||||
# Analysebericht – Reverse Requirements Engineering c-entron ERP-Suite
|
||||
|
||||
**Lauf:** 02_Lauf_2026-08-27_081235_v7.0.0-3021
|
||||
**Codebasis:** `C:\DEV\MasterArbeit\QuellCode\CentronERP` (nur lesend analysiert)
|
||||
**Methode:** Statische Analyse (RRE-Schritte 0, 2–6), keine Ausführung
|
||||
**Datum:** 2026-08-27
|
||||
|
||||
---
|
||||
|
||||
## Kennzahlen der Codebasis (erhoben in Schritt 0)
|
||||
|
||||
| Kennzahl | Wert | Quelle |
|
||||
|---|---|---|
|
||||
| C#-Dateien (src, ohne bin/obj) | ~14.200 | Verzeichniszählung `src/**`.cs |
|
||||
| Projekte in `Centron.sln` | 46 Code-Projekte (+ Setup/Doku-Ordner) | `Centron.sln` |
|
||||
| DB-Tabellen | 1.558 `CREATE TABLE` | `SSMS_DB_SCHEMA.sql` |
|
||||
| DB-Views | 182 `CREATE VIEW` | `SSMS_DB_SCHEMA.sql` |
|
||||
| FK-Constraints | 134 | `SSMS_DB_SCHEMA.sql` |
|
||||
| CHECK-Constraints | 330 | `SSMS_DB_SCHEMA.sql` |
|
||||
| Benutzerrechte (Konstanten) | 750 `public const int` | `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs` |
|
||||
|
||||
Architektur-Grobbild (aus `docs/getting-started/general-structure.md` und Verzeichnisstruktur):
|
||||
WPF-Client (`src/centron`) und Blazor-Web-Client „Nexus" (`src/nexus`) greifen über ein
|
||||
`ILogic`-Muster wahlweise direkt (BLLogic → NHibernate → MSSQL) oder über den Webservice
|
||||
(WSLogic → `src/webservice`) auf die Geschäftslogik (`src/backend/Centron.BL`) zu.
|
||||
Belege werden dual gehalten: deutsche Legacy-Tabellen (`AngKopf`/`AngPos` …) mit englischen Views
|
||||
(`Offers`/`OfferItems` …) darüber.
|
||||
|
||||
---
|
||||
|
||||
## Schritt 0 – Modulinventar
|
||||
|
||||
Das Inventar wurde **vor** der ersten Anforderung erstellt. Bezugsgröße für Mindestabdeckung
|
||||
und Abdeckungstabelle. Granularität: fachliches Modul bzw. abgrenzbare Komponente.
|
||||
Pfade relativ zum Arbeitsverzeichnis; `BL/` steht für `src/backend/Centron.BL/`.
|
||||
|
||||
### A. Vertrieb / Belegwesen
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M01 | Angebote | `BL/Sales/Receipts/Offers`, Tabellen `AngKopf`/`AngPos` | Erstellen und Verwalten von Angeboten an Kunden. |
|
||||
| M02 | Aufträge | `BL/Sales/Receipts/Orders`, `AufKopf`/`AufPos` | Auftragsverwaltung inkl. Auftragsstatus und Folgebelegen. |
|
||||
| M03 | Lieferscheine | `BL/Sales/Receipts/DeliveryLists`, `LiefKopf`/`LiefPos` | Lieferscheinerstellung und Lieferabwicklung. |
|
||||
| M04 | Rechnungen | `BL/Sales/Receipts/Invoices`, `RechKopf`/`RechPos` | Fakturierung, Rechnungsstatus, Zahlungsreferenzen. |
|
||||
| M05 | Gutschriften | `BL/Sales/Receipts/CreditVouchers`, `GutKopf`/`GutPos` | Gutschriftenerstellung zu Rechnungen/Retouren. |
|
||||
| M06 | Abhollisten | `BL/Sales/Receipts/PickupLists`, `AbholKopf`/`AbholPos` | Abholaufträge für Geräte/Waren beim Kunden. |
|
||||
| M07 | Verträge (Beleg) | `BL/Sales/Receipts/ContractLists`, `VertragKopf`/`VertragPos` | Wiederkehrende Leistungsverträge als Belegart mit Abrechnungsintervallen. |
|
||||
| M08 | Automatische Fakturierung | `BL/Sales/CustomerAssets/AutomaticFactura` | Automatische Rechnungserzeugung aus Verträgen, Kontingent- und Klickabrechnung. |
|
||||
| M09 | Zeitenabrechnung | `BL/Sales/CustomerAssets/TimerBilling` | Abrechnung erfasster Helpdesk-/Servicezeiten in Belege. |
|
||||
| M10 | Anzahlungen | `BL/Sales/Receipts/DownPayment` | Anzahlungsrechnungen und deren Verrechnung. |
|
||||
| M11 | Projekte (Beleg/PM) | `BL/Sales/Receipts/Projects`, `BL/Projects` | Projektverwaltung mit Belegzuordnung. |
|
||||
| M12 | Leasing & Service | `BL/Sales/Receipts/LeasingAndService` | Leasing-/Serviceabwicklung zu Belegen. |
|
||||
| M13 | Aktionspreise | `docs/reference/receipts/actionprice-system.md`, ActionPrice-Klassen | Zeitlich begrenzte Aktionsverkaufspreise je Artikel/Kunde. |
|
||||
| M14 | Artikelsuche im Beleg | `BL/Sales/Receipts/ArticleSearch` | Artikel-/Preisfindung beim Belegerfassen. |
|
||||
| M15 | Kassenbuch | `BL/Sales/CashBooks` | Kassenbuchführung mit Belegen und Salden. |
|
||||
| M16 | Sonderpreise | `BL/Accounts/SpecialPrices` | Kundenindividuelle Preise (auch Quelle des WebCart-Sortiments). |
|
||||
| M17 | Stammblätter (Geräteabrechnung) | `Centron.Entities/Entities/Sales/Receipts/MasterDataLists` | Gerätestammblätter mit Seriennummer, Zählern, Vertrags- und Rechnungsbezug. |
|
||||
| M18 | Schweiz-Besonderheiten | `BL/Sales/Receipts/Switzerland` | Länderspezifische Beleglogik Schweiz (z. B. Rundung, MwSt). |
|
||||
| M19 | Belegversionierung | `*KopfVersions`/`*PosVersions`-Tabellen, `AssetHeadDAO` | Versionsstände aller Belegarten für Audit-Trail. |
|
||||
| M20 | Nummernkreise | `BL/Administration/Company/NumberGroupBL.cs` | Vergabe eindeutiger Beleg-/Stammdatennummern je Mandant/Filiale. |
|
||||
| M21 | Belegdruck/-versand (Mailvorlagen) | `BL/Sales/Receipts` (ReceiptBL Druck/Mail), `BL/Mail/Templates` | Erzeugen, Drucken und Mailen von Belegdokumenten. |
|
||||
|
||||
### B. Einkauf
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M22 | Lieferantenbestellungen | `BL/Sales/Receipts/SupplierOrders` | Bestellungen an Lieferanten/Distributoren. |
|
||||
| M23 | Lieferantenrechnungen | `BL/Sales/Receipts/SupplierInvoices` | Eingangsrechnungserfassung und -prüfung. |
|
||||
| M24 | Lieferantenlieferscheine | `BL/Sales/Receipts/SupplierDeliveryLists` | Wareneingang auf Basis Lieferantenlieferscheinen. |
|
||||
| M25 | Lieferantengutschriften | `BL/Sales/Receipts/SupplierCreditVouchers` | Gutschriften von Lieferanten. |
|
||||
| M26 | Lieferantenbelegdokumente | `BL/Sales/Receipts/SupplierReceiptDocuments` | Dokumente/Anhänge zu Einkaufsbelegen. |
|
||||
| M27 | Bestellvorschläge | `BL/Purchasing/OrderSuggestionList` | Bestellvorschlagsermittlung aus Bedarf/Beständen. |
|
||||
| M28 | Lieferanten-/Distributorenstamm | `BL/Purchasing/Suppliers`, `BL/Buying/DistributorBL.cs`, `BL/BusinessPartner` | Verwaltung von Lieferanten und Distributoren. |
|
||||
|
||||
### C. Kunden / CRM
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M29 | Adress-/Kundenstamm | `BL/Accounts/AccountBL.cs`, `BL/CustomerArea`, Tabellen `Accounts`/`AccountCustomers`/`Kunden` | Zentrale Verwaltung von Accounts (Kunden, Lieferanten, Interessenten) mit Adressen. |
|
||||
| M30 | Ansprechpartner & Adressen | `BL/Sales/Customers/Addresses` | Kontaktpersonen und Adressverwaltung zu Accounts. |
|
||||
| M31 | Aktivitäten | `BL/Accounts/Activities` | Protokollierung von Kundenaktivitäten (Anrufe, Mails, Belege). |
|
||||
| M32 | Kampagnen | `BL/Accounts/Campaigns` | Marketingkampagnen mit Zielgruppen. |
|
||||
| M33 | Marketing/Mailings | `BL/Sales/Marketing`, `BL/Mailings` | Serienmails/Mailings an Kundengruppen. |
|
||||
| M34 | Umfragen | `BL/Accounts/Survey` | Kundenumfragen inkl. Versand nach Ticketabschluss. |
|
||||
| M35 | CRM-Projekte | `BL/Sales/Customers/CrmProjects` | Vertriebschancen/CRM-Projekte. |
|
||||
| M36 | Hotline | `BL/Accounts/HotlineArea` | Hotline-Konditionen je Kunde. |
|
||||
| M37 | Kundenvereinbarungen | `BL/Accounts/AccountContracts` | Rahmenvereinbarungen je Account. |
|
||||
|
||||
### D. Service / Helpdesk
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M38 | Helpdesk/Tickets | `BL/Sales/Support/HelpdeskBL.cs` u. a. | Ticketverwaltung (Anlage, Bearbeitung, Status, Kategorien). |
|
||||
| M39 | Eskalationsmanagement | `BL/Sales/Support/EscalationBL.cs` | Eskalationsregeln und Fälligkeiten auf Tickets. |
|
||||
| M40 | Ticket-Zeiterfassung | `BL/Sales/Support/HelpdeskTimer*.cs` | Zeiterfassung auf Tickets inkl. Unterschrift und Artikelbuchung. |
|
||||
| M41 | Checklisten | `BL/CheckListArea` | Checklistenvorlagen und -abarbeitung (v. a. auf Tickets). |
|
||||
| M42 | Ticketvorlagen (C-FLOW) | `BL/Sales/Support/HelpdeskPatternBL.cs`, `HelpdeskCreationTemplateBL.cs` | Vorlagen zur automatischen Ticketerzeugung. |
|
||||
| M43 | Taskmanagement | `BL/TaskManager` | Aufgabensteuerung mit Aktionen auf Tickets. |
|
||||
| M44 | Ticketprojekte | `BL/TicketProjects` | Bündelung von Tickets zu Projekten. |
|
||||
| M45 | RMA | `BL/CustomerArea/RmaBL.cs`, Tabelle `Rma` | Retouren-/Reparaturabwicklung zu Tickets. |
|
||||
| M46 | Externes Helpdesk | `BL/ExternalHelpdesk` | Anbindung fremder Ticketsysteme. |
|
||||
| M47 | Terminanfragen | `BL/AppointmentRequests` | Terminanfragen an Kunden (z. B. aus Tickets). |
|
||||
| M48 | ToDos | `BL/ToDoArea` | Persönliche/ticketbezogene Aufgabenlisten. |
|
||||
|
||||
### E. Geräte / Assets / MSP
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M49 | Kundengeräte | `BL/Devices/AccountDeviceBL.cs`, `BL/Sales/CustomerAssets` | Verwaltung der beim Kunden stehenden Geräte. |
|
||||
| M50 | DocuBoard/Assetmanagement | `BL/DocuBoard`, Tabellen `AssetManagement*` | IT-Dokumentation/Inventarisierung (AD-Scans, SNMP, Partner). |
|
||||
| M51 | RMM-Datenimport | `BL/DataExchange/Rmm` | Import von Monitoring-/RMM-Daten für Abrechnung. |
|
||||
| M52 | MSP-Abrechnung | `BL/Statistics/MspCollectors` | Sammler und Auswertung nutzungsbasierter MSP-Leistungen. |
|
||||
|
||||
### F. Lager / Logistik / Produktion
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M53 | Artikelstamm | `BL/Warehousing/ArticleBL.cs`, `BL/Warehousing/ArticleManagement` | Artikelverwaltung inkl. Preisen, Herstellern, EAN. |
|
||||
| M54 | Lager/Bestände | `BL/Warehousing/StockManagement`, `BL/Storage` | Lagerorte, Bestandsführung, Umbuchungen. |
|
||||
| M55 | Inventur | `BL/Warehousing/InventoryManagement` | Inventurdurchführung und Bestandskorrektur. |
|
||||
| M56 | Kommissionierung | `BL/Warehousing/CommissioningManagement`, `Commissions` | Kommissionieren von Aufträgen. |
|
||||
| M57 | Seriennummern/Barcodes | `Centron.Entities/Entities/Warehousing/SerialNumber.cs`, `BarCode.cs` | Serialisierte Bestandsführung und Barcodestatus. |
|
||||
| M58 | Produktion | `BL/Production`, `BL/Warehousing/ArticleProduction` | Fertigungsaufträge und Stücklistenproduktion. |
|
||||
| M59 | Versand GLS | `src/apis/Centron.Api.Gls` | Paketversand über GLS-API. |
|
||||
| M60 | Versand Shipcloud | `src/apis/Centron.Api.Shipcloud` | Paketversand über Shipcloud-API. |
|
||||
|
||||
### G. Finanzen
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M61 | Zahlungseingänge | `BL/Finances/IncomingPayments` | Erfassung/Zuordnung von Zahlungseingängen zu Rechnungen. |
|
||||
| M62 | Onlinebanking | `BL/Finances/OnlineBanking`, `src/apis/Centron.APIs.FinAPI` | Kontoumsatzabruf über finAPI und Transaktionszuordnung. |
|
||||
| M63 | Zahlungsverkehr/SEPA | `BL/Finances/Payments`, Mandate (`MandatI3D`) | Lastschrift-/Zahlungsläufe mit SEPA-Mandaten. |
|
||||
| M64 | Mahnwesen | `BL/Sales/Receipts/Invoices/Dunning` | Mahnläufe mit Mahnstufen und Mahnsperren. |
|
||||
| M65 | OPOS | `BL/Sales/Receipts/Invoices/Opos` | Offene-Posten-Verwaltung. |
|
||||
| M66 | Buchhaltungsexport | `BL/DataExchange/BookKeeping`, `Centron.Gateway/DataExchange/BookKeeping` | Export an DATEV, Sage, Schilling u. a. |
|
||||
| M67 | Bankkonten | `BL/Accounting/BankAccountBL.cs` | Bankverbindungen von Accounts. |
|
||||
| M68 | Kreditlimit/Bonität | `ReceiptBL` (Kreditlimitprüfung) | Kreditlimitprüfung bei Belegerstellung. |
|
||||
|
||||
### H. Administration / System
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M69 | Benutzer & Login | `BL/Administration/Logins` | Benutzerkonten, Authentifizierung (Basic/AD/Entra ID), Sitzungstickets. |
|
||||
| M70 | Rechteverwaltung | `BL/Administration/Rights`, Tabellen `Sichbenu`/`Sichmemb`/`Sichtrus` | Gruppenbasierte Rechtevergabe mit 750 Einzelrechten. |
|
||||
| M71 | Zwei-Faktor-Authentifizierung | `BL/Administration/Logins/TwoFactor` | 2FA per E-Mail oder RADIUS. |
|
||||
| M72 | Lizenzierung | `BL/Administration/Licensing`, `docs/reference/security/licensing-system.md` | GUID-basierte Produkt-/Featurelizenzen mit Anzahl und Ablauf. |
|
||||
| M73 | Mandanten/Filialen | `BL/Administration/Company`, `BL/Administration/Mandatory` | Mandanten-, Firmen- und Filialverwaltung. |
|
||||
| M74 | Mitarbeiterverwaltung | `BL/Administration/Employees`, `BL/EmployeeArea` | Mitarbeiterstamm, Abteilungen, Teams. |
|
||||
| M75 | Einstellungen | `BL/Administration/Settings` | Zentrale Anwendungseinstellungen (`ApplicationSettingID`). |
|
||||
| M76 | Datensicherheit/DSGVO | `BL/Administration/DataSecurity` | Datenschutzfunktionen (Anonymisierung/Löschkonzept). |
|
||||
| M77 | DB-Skripte/Migration | `BL/Administration/Scripts`, `docs/guides/database` | Nummerierte SQL-Migrationsskripte mit Versionierung. |
|
||||
| M78 | Hintergrunddienste | `BL/Administration/BackgroundServices`, `docs/Background Service` | Zeitgesteuerte Dienste (z. B. DataQualityService). |
|
||||
| M79 | Telemetrie/Profiling | `BL/Telemetry`, `BL/Administration/Profiling` | Nutzungs-/Leistungsdaten. |
|
||||
| M80 | Access Tokens | `BL/Administration/AccessTokens` | API-Zugriffstoken für Fremdzugriffe. |
|
||||
| M81 | Passwortmanager | `BL/PasswordManagementArea`, `BL/PasswordManager` | Verwaltung von Kundenpasswörtern/Zugangsdaten. |
|
||||
| M82 | Anpassungen/CustomTables | `BL/Customizations/CustomTables` | Kundenindividuelle Zusatztabellen/-felder. |
|
||||
| M83 | Massenupdate | `BL/MassUpdate` | Massenänderung von Stammdaten. |
|
||||
| M84 | GUI-Profile | `BL/GUI/Profiles` | Benutzer-/Rollenprofile für Oberflächenlayouts. |
|
||||
|
||||
### I. Kommunikation
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M85 | E-Mail & Vorlagen | `BL/Mail` | Mailversand, Vorlagen mit Variablenersetzung, Blacklist. |
|
||||
| M86 | Exchange-Sync | `BL/Mail/Exchange`, `docs/features/exchange-sync-bugprotokoll.md` | Synchronisation von Mails/Terminen mit Exchange. |
|
||||
| M87 | MailScanner | `BL/MailScanner` | Automatische Ticketerzeugung/Zuordnung aus Postfächern. |
|
||||
| M88 | TAPI/Telefonie | `BL/Tapi/PhoneCallBL.cs`, `docs/reference/architecture/tapi.md` | Anrufsignalisierung und Anruferkennung. |
|
||||
| M89 | Kalender | `BL/Sales/Calendar`, `BL/Calendar` | Terminkalender der Mitarbeiter. |
|
||||
| M90 | Chats | `BL/Chats` | Interne Chatfunktion. |
|
||||
| M91 | Outlook-Add-In | `src/nexus/CentronNexus.OutlookAddIn` | Ticket-/Kundenbezug direkt aus Outlook. |
|
||||
| M92 | Benachrichtigungen | `BL/Notifications`, `BL/NexusNotifications` | Systembenachrichtigungen an Benutzer (Client und Web). |
|
||||
|
||||
### J. Datenaustausch / Schnittstellen
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M93 | EDI-Framework | `BL/EDI`, `docs/reference/edi` | Elektronischer Belegaustausch mit Distributoren (ALSO, Alltron, Komsa …). |
|
||||
| M94 | ZUGFeRD/XRechnung | `BL/EDI/Zugferd`, `docs/guides/development/xrechnung.md`, `docs/reference/zugferd-*.md` | Strukturierte E-Rechnung (Erzeugung/Einlesen). |
|
||||
| M95 | ebInterface | `src/apis/Centron.Api.EbInterface` | Österreichisches E-Rechnungsformat. |
|
||||
| M96 | docuFORM | `Centron.Api.docuFORM` | Zählerstands-/Gerätedaten von docuFORM. |
|
||||
| M97 | Icecat | `src/apis/Centron.APIs.IcecatDataAccess` | Artikelstammdaten-Anreicherung aus Icecat. |
|
||||
| M98 | ITscope | `src/apis/Centron.APIs.ITscopeDataAccess` | Produkt-/Preisdaten und Bestellungen über ITscope. |
|
||||
| M99 | COP | `src/apis/Centron.APIs.CopDataAccess` | COP-Datenzugriff (Herstellerdaten/Servicedaten). |
|
||||
| M100 | EGIS | `src/apis/Centron.APIs.EgisDataAccess`, `BL/EDI/EGIS` | EGIS-Warenkorb/Bestellübertragung. |
|
||||
| M101 | Telekom Dive | `BL/DataExchange/TelekomDive` | Telekom-Dive-Schnittstelle. |
|
||||
| M102 | TANSS | `BL/DataExchange/TanssInterfaces` | Übernahme aus TANSS-Ticketsystem. |
|
||||
| M103 | GFK-Export | `BL/DataExchange/GfkExport` | Absatzmeldung an GfK. |
|
||||
| M104 | Datenimport allgemein | `BL/DataExchange/Import` | Generischer Datenimport (CSV u. a.). |
|
||||
| M105 | Connectors | `BL/DataExchange/Connectors`, `BL/Services/CTimeConnectors` | Konnektoren zu Drittsystemen (u. a. c-time). |
|
||||
|
||||
### K. Auswertung / Suche
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M106 | ReportEngine | `BL/ReportEngine` | Reportvorlagen, PDF-Erzeugung, Belegdruckstrategien. |
|
||||
| M107 | Statistiken | `BL/Statistics` | Umsatz-, Auftrags-, Ticket- und Vertragsstatistiken. |
|
||||
| M108 | Indexsuche | `BL/IndexSearch` | Volltextsuche (Lucene) über Accounts und Tickets. |
|
||||
|
||||
### L. Web (c-entron Nexus) und Webservice
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M109 | Nexus-Rahmen | `src/nexus/CentronNexus`, `CentronNexus.Host` | Blazor-Webanwendung (Login, Navigation, Hosting). |
|
||||
| M110 | ServiceBoard | `src/nexus/CentronNexus/ServiceBoard` | Web-Ticketboard für Techniker/Kunden. |
|
||||
| M111 | WebCart | `src/nexus/CentronNexus/WebCart` | Webshop für Endkunden auf Basis Sonderpreisen. |
|
||||
| M112 | WebOffer | `src/nexus/CentronNexus/WebOffer` | Online-Angebotsansicht/-freigabe durch Kunden. |
|
||||
| M113 | Dokumentensignierung | `src/nexus/CentronNexus/DocumentSigning` | Digitale Unterschrift von Dokumenten im Web. |
|
||||
| M114 | Produktionsaufträge Web | `src/nexus/CentronNexus/ProductionOrderManagement` | Web-Sicht auf Fertigungsaufträge. |
|
||||
| M115 | SelfCare | `BL/SelfCare` | Selbstbedienungsseiten für Endkunden (Web-Anfragen). |
|
||||
| M116 | Web-Accounts/WebSuite | `BL/Administration/Logins/WebAccountBL.cs`, `BL/WebSuite` | Weblogins für Kunden mit eigenem Rechtesatz. |
|
||||
| M117 | Webservice | `src/webservice` (Host, Controllers, WebServices.Core) | REST-/Dienstschicht für Client-, Web- und Fremdzugriffe. |
|
||||
| M118 | ConnectionManager | `src/webservice/c-entron.misc.ConnectionManager` | Verwaltung der DB-/Dienstverbindungen. |
|
||||
|
||||
### M. Weitere Fachmodule
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M119 | MyCentron/Dashboard | `BL/MyCentron` | Persönliche Startseite mit Dashboards, Notizen, Planungen. |
|
||||
| M120 | MyDay | `BL/MyDay` | Tagesübersicht mit Importen aus Fremdtools (lizenzpflichtig je Import). |
|
||||
| M121 | KI-Funktionen | `BL/ArtificialIntelligence` | KI-Chat und Prompts (z. B. Textvorschläge). |
|
||||
| M122 | TradePool | `BL/TradePool` | Gebrauchtgeräte-/Handelsplattform-Anbindung. |
|
||||
| M123 | VoucherManagement | `BL/VoucherManagement` | Gutschein-/Voucherverwaltung. |
|
||||
| M124 | Textbausteine | `BL/TextModuleArea` | Wiederverwendbare Textmodule. |
|
||||
| M125 | Tags | `BL/Tags` | Freie Verschlagwortung von Objekten. |
|
||||
| M126 | Social Media | `BL/SocialMedia` | Social-Media-Profile zu Personen/Accounts. |
|
||||
| M127 | VideoPortal | `BL/VideoPortal` | Zuordnung von Schulungs-/Videos. |
|
||||
| M128 | WebLinks | `BL/WebLinks` | Aktionslinks (z. B. Terminbestätigung) mit Handlern. |
|
||||
| M129 | Mobile | `BL/Mobile` | Unterstützung mobiler Clients. |
|
||||
| M130 | ProductMatrix | `BL/ProductMatrix` | Produktmatrix (Artikelvergleich/-zuordnung). |
|
||||
| M131 | ItPlanner | `BL/ItPlanner` | Planungsobjekte/Checklisten für IT-Projekte. |
|
||||
| M132 | ExpectedEvents | `BL/ExpectedEvents` | Erwartete Ereignisse/Wiedervorlagen. |
|
||||
| M133 | CPra | `BL/CPra` | Anbindung „CPra"-Konnektor (Konfiguration + Übertragung). |
|
||||
| M134 | RiverDivo | `BL/RiverDivo` | Anbindung RiverSuite/Divo (Vertragsartikel-Referenzen). |
|
||||
| M135 | Länder/Regionen | `BL/CountryArea` | Länder- und Bundesländerstamm. |
|
||||
| M136 | Feiertage | `Centron.DAO/Holiday` | Feiertagsberechnung (z. B. für Fristen). |
|
||||
| M137 | Wechselkurse/Währungen | `ReceiptBase` (CurrencyI3D/Factor), Währungstabellen | Fremdwährungsbelege mit Kursfaktor. |
|
||||
| M138 | Objekt-Fremdreferenzen | `BL/ObjectExternalReferences` | Verknüpfung interner Objekte mit externen IDs. |
|
||||
| M139 | Prozesse/Workflows | `BL/Processes`, `BL/Services/Workflows` | Definierte Abläufe/Workflow-Unterstützung. |
|
||||
| M140 | Änderungsverfolgung | `BL/ChangeTracking`, `Centron.DAO/ChangeTracking` | Historisierung von Feldänderungen. |
|
||||
|
||||
### N. Infrastruktur / Querschnitt
|
||||
|
||||
| Nr. | Modul | Pfad | Fachliche Aufgabe |
|
||||
|---|---|---|---|
|
||||
| M141 | WPF-Client-Rahmen | `src/centron/Centron.WPF.UI` (Start, Modules, Views) | Windows-Client mit Modulnavigation und Anmeldung. |
|
||||
| M142 | Shared Controls | `src/shared/Centron.Controls`, `Centron.Core` | Wiederverwendbare UI-Komponenten und Basisfunktionen. |
|
||||
| M143 | Datenzugriff/DAO | `src/backend/Centron.DAO` | NHibernate-Mappings, Repositories, NamedQueries, RawSQL. |
|
||||
| M144 | Gateway | `src/backend/Centron.Gateway` | Externe Format-Gateways (u. a. Buchhaltungsexporte, EGIS-Suche). |
|
||||
| M145 | Deployment/Setup | `deployment/`, `docker/`, `azure/`, `azure-blazor/` | Installer (WiX), Container- und Cloud-Bereitstellung. |
|
||||
| M146 | Lokalisierung | `LocalizedStrings*.resx`, `docs/guides/ui/localization.md` | Deutsch als Erstsprache, Englisch als Zweitsprache. |
|
||||
|
||||
**Summe: 146 Module.** Das Inventar darf ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
---
|
||||
|
||||
## Erzeugtes Anforderungs-Set (Überblick)
|
||||
|
||||
| Ebene | Anzahl | davon HYPOTHESE |
|
||||
|---|---|---|
|
||||
| StRS | 32 | 0 |
|
||||
| SyRS | 156 | 11 |
|
||||
| SwRS | 71 | 2 |
|
||||
| **Gesamt** | **259** | **13 (5,0 %)** |
|
||||
|
||||
---
|
||||
|
||||
## Abdeckungstabelle (je Modul des Inventars)
|
||||
|
||||
Einstufung: **tief** = mehrere Anforderungen mit methodengenau gelesener Logik (inkl.
|
||||
SwRS-Vertiefung) · **mittel** = 1-2 Anforderungen mit konkret gelesener Logik ·
|
||||
**flach** = 1 Anforderung auf Basis von Dateibestand/Signaturen · **nicht analysiert** = 0
|
||||
Anforderungen. `[H]` = Anforderung mit Status HYPOTHESE. Jede Inventarzeile ist enthalten.
|
||||
|
||||
| Nr. | Modul | Abdeckung | Anforderungen (tragend) | Anzahl |
|
||||
|---|---|---|---|---|
|
||||
| M01 | Angebote | mittel | SyRS-001 (+SyRS-026/027 übergreifend) | 1 |
|
||||
| M02 | Aufträge | mittel | SyRS-002 | 1 |
|
||||
| M03 | Lieferscheine | mittel | SyRS-003 | 1 |
|
||||
| M04 | Rechnungen | tief | SyRS-004, SyRS-005, SyRS-006, SwRS-016, SwRS-017 | 5 |
|
||||
| M05 | Gutschriften | mittel | SyRS-007 | 1 |
|
||||
| M06 | Abhollisten | flach | SyRS-008 | 1 |
|
||||
| M07 | Verträge (Beleg) | mittel | SyRS-009, SwRS-023 | 2 |
|
||||
| M08 | Automatische Fakturierung | tief | SyRS-010, SyRS-011, SwRS-019, SwRS-020, SwRS-021, SwRS-022, SwRS-024, SwRS-064, SwRS-071 [H] | 9 |
|
||||
| M09 | Zeitenabrechnung | tief | SyRS-012, SwRS-063 | 2 |
|
||||
| M10 | Anzahlungen | mittel | SyRS-013, SwRS-018 | 2 |
|
||||
| M11 | Projekte (Beleg/PM) | flach | SyRS-014 | 1 |
|
||||
| M12 | Leasing & Service | flach | SyRS-015 | 1 |
|
||||
| M13 | Aktionspreise | mittel | SyRS-016 | 1 |
|
||||
| M14 | Artikelsuche im Beleg | tief | SyRS-017, SwRS-007, SwRS-009, SwRS-010, SwRS-013, SwRS-014 | 6 |
|
||||
| M15 | Kassenbuch | mittel | SyRS-018 | 1 |
|
||||
| M16 | Sonderpreise | tief | SyRS-019, SwRS-008 | 2 |
|
||||
| M17 | Stammblätter | mittel | SyRS-020 | 1 |
|
||||
| M18 | Schweiz-Besonderheiten | tief | SyRS-021, SwRS-012 | 2 |
|
||||
| M19 | Belegversionierung | mittel | SyRS-022, SwRS-002, SwRS-003 | 3 |
|
||||
| M20 | Nummernkreise | tief | SyRS-023, SwRS-025 | 2 |
|
||||
| M21 | Belegdruck/-versand | mittel | SyRS-024 | 1 |
|
||||
| M22 | Lieferantenbestellungen | flach | SyRS-029 | 1 |
|
||||
| M23 | Lieferantenrechnungen | mittel | SyRS-030 | 1 |
|
||||
| M24 | Lieferantenlieferscheine | mittel | SyRS-031 | 1 |
|
||||
| M25 | Lieferantengutschriften | flach | SyRS-032 | 1 |
|
||||
| M26 | Lieferantenbelegdokumente | flach | SyRS-033 | 1 |
|
||||
| M27 | Bestellvorschläge | flach | SyRS-034 | 1 |
|
||||
| M28 | Lieferanten-/Distributorenstamm | mittel | SyRS-035 | 1 |
|
||||
| M29 | Adress-/Kundenstamm | tief | SyRS-036, SyRS-037, SwRS-051 | 3 |
|
||||
| M30 | Ansprechpartner & Adressen | mittel | SyRS-037 | 1 |
|
||||
| M31 | Aktivitäten | mittel | SyRS-038 | 1 |
|
||||
| M32 | Kampagnen | flach | SyRS-039 | 1 |
|
||||
| M33 | Marketing/Mailings | flach | SyRS-040 | 1 |
|
||||
| M34 | Umfragen | mittel | SyRS-041 | 1 |
|
||||
| M35 | CRM-Projekte | flach | SyRS-042 | 1 |
|
||||
| M36 | Hotline | flach | SyRS-043 | 1 |
|
||||
| M37 | Kundenvereinbarungen | flach | SyRS-044 | 1 |
|
||||
| M38 | Helpdesk/Tickets | tief | SyRS-045, SyRS-046, SyRS-047, SyRS-058, SwRS-047, SwRS-048 | 6 |
|
||||
| M39 | Eskalationsmanagement | tief | SyRS-048, SwRS-049 | 2 |
|
||||
| M40 | Ticket-Zeiterfassung | mittel | SyRS-049 | 1 |
|
||||
| M41 | Checklisten | mittel | SyRS-050 | 1 |
|
||||
| M42 | Ticketvorlagen (C-FLOW) | mittel | SyRS-051 | 1 |
|
||||
| M43 | Taskmanagement | flach | SyRS-052 | 1 |
|
||||
| M44 | Ticketprojekte | mittel | SyRS-053 | 1 |
|
||||
| M45 | RMA | mittel | SyRS-054, SwRS-050 | 2 |
|
||||
| M46 | Externes Helpdesk | flach | SyRS-055 [H] | 1 |
|
||||
| M47 | Terminanfragen | mittel | SyRS-056 | 1 |
|
||||
| M48 | ToDos | mittel | SyRS-057 | 1 |
|
||||
| M49 | Kundengeräte | mittel | SyRS-059 | 1 |
|
||||
| M50 | DocuBoard/Assetmanagement | flach | SyRS-060 | 1 |
|
||||
| M51 | RMM-Datenimport | flach | SyRS-061 | 1 |
|
||||
| M52 | MSP-Abrechnung | mittel | SyRS-062, SwRS-064 | 2 |
|
||||
| M53 | Artikelstamm | mittel | SyRS-063 | 1 |
|
||||
| M54 | Lager/Bestände | tief | SyRS-064, SwRS-011, SwRS-046 | 3 |
|
||||
| M55 | Inventur | tief | SyRS-065, SwRS-069 | 2 |
|
||||
| M56 | Kommissionierung | mittel | SyRS-066 | 1 |
|
||||
| M57 | Seriennummern/Barcodes | tief | SyRS-067, SwRS-045 | 2 |
|
||||
| M58 | Produktion | mittel | SyRS-068 | 1 |
|
||||
| M59 | Versand GLS | flach | SyRS-069 | 1 |
|
||||
| M60 | Versand Shipcloud | flach | SyRS-070 | 1 |
|
||||
| M61 | Zahlungseingänge | tief | SyRS-071, SwRS-031 | 2 |
|
||||
| M62 | Onlinebanking | tief | SyRS-072, SwRS-028 | 2 |
|
||||
| M63 | Zahlungsverkehr/SEPA | tief | SyRS-073, SwRS-026, SwRS-027 | 3 |
|
||||
| M64 | Mahnwesen | tief | SyRS-074, SwRS-030 | 2 |
|
||||
| M65 | OPOS | flach | SyRS-075 | 1 |
|
||||
| M66 | Buchhaltungsexport | tief | SyRS-076, SwRS-029 | 2 |
|
||||
| M67 | Bankkonten | mittel | SyRS-077 | 1 |
|
||||
| M68 | Kreditlimit/Bonität | tief | SyRS-025, SwRS-015 | 2 |
|
||||
| M69 | Benutzer & Login | tief | SyRS-078, SyRS-079, SwRS-032, SwRS-033, SwRS-034, SwRS-041 | 6 |
|
||||
| M70 | Rechteverwaltung | tief | SyRS-080, SwRS-036, SwRS-038 | 3 |
|
||||
| M71 | Zwei-Faktor-Authentifizierung | tief | SyRS-081, SwRS-037 | 2 |
|
||||
| M72 | Lizenzierung | tief | SyRS-082, SwRS-035 | 2 |
|
||||
| M73 | Mandanten/Filialen | mittel | SyRS-083 (+SyRS-028) | 1 |
|
||||
| M74 | Mitarbeiterverwaltung | mittel | SyRS-084 | 1 |
|
||||
| M75 | Einstellungen | mittel | SyRS-085, SwRS-054 | 2 |
|
||||
| M76 | Datensicherheit/DSGVO | tief | SyRS-086, SwRS-052 | 2 |
|
||||
| M77 | DB-Skripte/Migration | mittel | SyRS-087, SwRS-053 | 2 |
|
||||
| M78 | Hintergrunddienste | mittel | SyRS-088, SwRS-057 | 2 |
|
||||
| M79 | Telemetrie/Profiling | flach | SyRS-089 [H] | 1 |
|
||||
| M80 | Access Tokens | tief | SyRS-090, SwRS-040 | 2 |
|
||||
| M81 | Passwortmanager | mittel | SyRS-091 | 1 |
|
||||
| M82 | Anpassungen/CustomTables | flach | SyRS-092 | 1 |
|
||||
| M83 | Massenupdate | mittel | SyRS-093 | 1 |
|
||||
| M84 | GUI-Profile | flach | SyRS-094 | 1 |
|
||||
| M85 | E-Mail & Vorlagen | tief | SyRS-095, SwRS-059, SwRS-060 | 3 |
|
||||
| M86 | Exchange-Sync | flach | SyRS-096 | 1 |
|
||||
| M87 | MailScanner | mittel | SyRS-097 | 1 |
|
||||
| M88 | TAPI/Telefonie | mittel | SyRS-098 | 1 |
|
||||
| M89 | Kalender | mittel | SyRS-099 | 1 |
|
||||
| M90 | Chats | mittel | SyRS-100 | 1 |
|
||||
| M91 | Outlook-Add-In | flach | SyRS-101 | 1 |
|
||||
| M92 | Benachrichtigungen | mittel | SyRS-102 | 1 |
|
||||
| M93 | EDI-Framework | mittel | SyRS-103, SwRS-062 | 2 |
|
||||
| M94 | ZUGFeRD/XRechnung | tief | SyRS-104, SwRS-061 | 2 |
|
||||
| M95 | ebInterface | flach | SyRS-105 | 1 |
|
||||
| M96 | docuFORM | flach | SyRS-106 [H] | 1 |
|
||||
| M97 | Icecat | flach | SyRS-107 | 1 |
|
||||
| M98 | ITscope | mittel | SyRS-108 | 1 |
|
||||
| M99 | COP | flach | SyRS-109 [H] | 1 |
|
||||
| M100 | EGIS | flach | SyRS-110 | 1 |
|
||||
| M101 | Telekom Dive | flach | SyRS-111 [H] | 1 |
|
||||
| M102 | TANSS | flach | SyRS-112 [H] | 1 |
|
||||
| M103 | GFK-Export | flach | SyRS-113 | 1 |
|
||||
| M104 | Datenimport allgemein | flach | SyRS-114 | 1 |
|
||||
| M105 | Connectors | flach | SyRS-115 | 1 |
|
||||
| M106 | ReportEngine | mittel | SyRS-116 | 1 |
|
||||
| M107 | Statistiken | mittel | SyRS-117 | 1 |
|
||||
| M108 | Indexsuche | mittel | SyRS-118 | 1 |
|
||||
| M109 | Nexus-Rahmen | tief | SyRS-119, SwRS-067 | 2 |
|
||||
| M110 | ServiceBoard | mittel | SyRS-120 | 1 |
|
||||
| M111 | WebCart | tief | SyRS-121, SwRS-043 | 2 |
|
||||
| M112 | WebOffer | tief | SyRS-122, SwRS-044 | 2 |
|
||||
| M113 | Dokumentensignierung | mittel | SyRS-123 | 1 |
|
||||
| M114 | Produktionsaufträge Web | flach | SyRS-124 | 1 |
|
||||
| M115 | SelfCare | mittel | SyRS-125 | 1 |
|
||||
| M116 | Web-Accounts/WebSuite | tief | SyRS-126, SwRS-039, SwRS-042, SwRS-066 | 4 |
|
||||
| M117 | Webservice | tief | SyRS-127, SwRS-055, SwRS-068 | 3 |
|
||||
| M118 | ConnectionManager | flach | SyRS-128 | 1 |
|
||||
| M119 | MyCentron/Dashboard | mittel | SyRS-129 | 1 |
|
||||
| M120 | MyDay | mittel | SyRS-130 | 1 |
|
||||
| M121 | KI-Funktionen | mittel | SyRS-131 | 1 |
|
||||
| M122 | TradePool | flach | SyRS-132 [H] | 1 |
|
||||
| M123 | VoucherManagement | mittel | SyRS-133 | 1 |
|
||||
| M124 | Textbausteine | mittel | SyRS-134 | 1 |
|
||||
| M125 | Tags | mittel | SyRS-135 | 1 |
|
||||
| M126 | Social Media | mittel | SyRS-136 | 1 |
|
||||
| M127 | VideoPortal | flach | SyRS-137 | 1 |
|
||||
| M128 | WebLinks | mittel | SyRS-138 | 1 |
|
||||
| M129 | Mobile | flach | SyRS-139 [H] | 1 |
|
||||
| M130 | ProductMatrix | mittel | SyRS-140 | 1 |
|
||||
| M131 | ItPlanner | flach | SyRS-141 [H] | 1 |
|
||||
| M132 | ExpectedEvents | mittel | SyRS-142 | 1 |
|
||||
| M133 | CPra | flach | SyRS-143 [H] | 1 |
|
||||
| M134 | RiverDivo | mittel | SyRS-144 | 1 |
|
||||
| M135 | Länder/Regionen | mittel | SyRS-145 | 1 |
|
||||
| M136 | Feiertage | flach | SyRS-146 | 1 |
|
||||
| M137 | Wechselkurse/Währungen | mittel | SyRS-147 | 1 |
|
||||
| M138 | Objekt-Fremdreferenzen | mittel | SyRS-148 | 1 |
|
||||
| M139 | Prozesse/Workflows | flach | SyRS-149 [H] | 1 |
|
||||
| M140 | Änderungsverfolgung | flach | SyRS-150 | 1 |
|
||||
| M141 | WPF-Client-Rahmen | tief | SyRS-151, SwRS-056 | 2 |
|
||||
| M142 | Shared Controls | flach | SyRS-152 | 1 |
|
||||
| M143 | Datenzugriff/DAO | mittel | SyRS-153, SwRS-001, SwRS-006 | 3 |
|
||||
| M144 | Gateway | flach | SyRS-154 | 1 |
|
||||
| M145 | Deployment/Setup | flach | SyRS-155 | 1 |
|
||||
| M146 | Lokalisierung | mittel | SyRS-156, SwRS-058 | 2 |
|
||||
|
||||
**Abdeckungssummen:** tief = 33 Module · mittel = 66 Module · flach = 47 Module ·
|
||||
nicht analysiert = 0 Module (Summe 146 = Inventar). **Mindestabdeckung erfüllt:** Jedes Modul
|
||||
besitzt mindestens eine Anforderung; kein Modul musste als `nicht analysiert` geführt werden.
|
||||
Hinweis: Übergreifende Anforderungen (z. B. SyRS-026-028, StRS-Ebene) sind der Übersicht halber
|
||||
nur bei ihrem Hauptmodul gezählt; die Anzahl-Spalte summiert deshalb konservativ (203 Zuordnungen
|
||||
bei 259 Anforderungen; StRS-Anforderungen sind bereichs-, nicht modulbezogen).
|
||||
|
||||
---
|
||||
|
||||
## Konsistenzcheck über das gesamte Anforderungs-Set
|
||||
|
||||
Die Prüfungen wurden skriptgestützt über die erzeugten Dateien ausgeführt (grep/awk über
|
||||
`StRS.md`, `SyRS.md`, `SwRS.md`).
|
||||
|
||||
| Prüfung | Ergebnis |
|
||||
|---|---|
|
||||
| Doppelte oder mehrfach vergebene IDs | **0** (32 StRS + 156 SyRS + 71 SwRS = 259 eindeutige IDs) |
|
||||
| Anforderungen ohne Beleg | **0** (259 `Belege:`-Abschnitte zu 259 IDs) |
|
||||
| Anforderungen ohne `Übernahmewürdigkeit` | **0** (259/259) |
|
||||
| Anforderungen ohne `Prüfidee` / `Status` / `Konsolidierung` / `Tracelinks` | **0** (jeweils 259/259) |
|
||||
| Tracelinks auf nicht existierende IDs | **0** (alle 188 referenzierten IDs existieren) |
|
||||
| SyRS ohne StRS-Rückverweis | **0** · SwRS ohne SyRS-Rückverweis: **0** |
|
||||
| Nicht rückverlinkte StRS | **0** (jede StRS wird von ≥1 SyRS referenziert) |
|
||||
| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung | **0 bekannte Fälle**; als Konsolidierungskandidaten markiert sind: Gerätedaten dreifach (StRS-19, SyRS-020/059/060), Verträge vs. Kundenvereinbarungen (SyRS-044↔SyRS-009), Versand GLS↔Shipcloud (SyRS-069↔070), Inventur alt/neu (SyRS-065), Einstellungen zweigleisig (SyRS-085, SwRS-054), Social-Media-Stream↔Chat/Benachrichtigungen (SyRS-136) |
|
||||
| Abgleich `Hypothesen.md` gegen Inline-Markierungen | **deckungsgleich**: 13 Status-HYPOTHESE-Blöcke (SyRS-055, 089, 106, 109, 111, 112, 132, 139, 141, 143, 149; SwRS-065, 071) = 13 Einträge in `Hypothesen.md`; keine zusätzlichen freien Fragen in der Sammeldatei |
|
||||
|
||||
### Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
|
||||
|
||||
Regel: risikorelevante Anforderungen benötigen mindestens einen `PRIMÄR`-Beleg mit benannter
|
||||
durchsetzender Stelle, andernfalls `[HYPOTHESE]`. Ergebnis: **81 risikorelevante Anforderungen,
|
||||
80 mit PRIMÄR-Beleg, 1 als HYPOTHESE gekennzeichnet (SwRS-071). Kein Verstoß.**
|
||||
|
||||
**Sicherheit/Berechtigungen (Typ Sicherheit; 35 Anforderungen, alle mit PRIMÄR, alle belegt):**
|
||||
|
||||
| ID | Titel (Kurz) | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| StRS-13 | Rollenbasierter Zugriffsschutz | 2 | belegt |
|
||||
| StRS-14 | Anmeldung (AD/Entra, 2FA) | 2 | belegt |
|
||||
| StRS-23 | DSGVO-Compliance | 1 | belegt |
|
||||
| SyRS-005 | Rechnungsstorno-Schutz | 1 | belegt |
|
||||
| SyRS-006 | Rechnungsfestschreibung | 1 | belegt |
|
||||
| SyRS-028 | Filialbezogene Belegrechte | 1 | belegt |
|
||||
| SyRS-036 | Account-Rechteprüfung | 2 | belegt |
|
||||
| SyRS-058 | Einschränkende Helpdesk-Rechte | 1 | belegt |
|
||||
| SyRS-078 | Login mit Sitzungstickets | 3 | belegt |
|
||||
| SyRS-079 | Kontodeaktivierung | 1 | belegt |
|
||||
| SyRS-080 | Gruppenbasierte Rechte | 1 | belegt |
|
||||
| SyRS-081 | Zwei-Faktor-Authentifizierung | 2 | belegt |
|
||||
| SyRS-086 | DSGVO-Bereinigung/Löschrecht | 1 | belegt |
|
||||
| SyRS-090 | API-Zugriffstoken | 2 | belegt |
|
||||
| SyRS-091 | Passwortmanager | 1 | belegt |
|
||||
| SyRS-119 | Nexus Cookie-Auth/HSTS | 1 | belegt |
|
||||
| SyRS-126 | Web-Accounts (getrennte Rechte) | 2 | belegt |
|
||||
| SyRS-151 | Modulfreischaltung Recht+Lizenz | 1 | belegt |
|
||||
| SwRS-016 | Stornoregeln im Detail | 1 | belegt |
|
||||
| SwRS-017 | Festschreibungsmechanik | 1 | belegt |
|
||||
| SwRS-032 | SHA1-Passworthash (Ist-Zustand) | 2 | belegt |
|
||||
| SwRS-033 | Dreifache Deaktivierungslogik | 1 | belegt |
|
||||
| SwRS-034 | Ticket-Lebensdauern | 1 | belegt |
|
||||
| SwRS-036 | Anwendungs-Pflicht-/Verbotsrechte | 1 | belegt |
|
||||
| SwRS-037 | 2FA-Parametrik | 1 | belegt |
|
||||
| SwRS-039 | Getrennte Web-Rechte | 1 | belegt |
|
||||
| SwRS-040 | Token-Kryptomechanik | 1 | belegt |
|
||||
| SwRS-041 | Passwortregeln | 1 | belegt |
|
||||
| SwRS-042 | Web-Login-Beziehungskette | 1 | belegt |
|
||||
| SwRS-043 | WebCart-Sortiments-Isolation | 1 | belegt |
|
||||
| SwRS-056 | Modul-Doppelbedingung | 1 | belegt |
|
||||
| SwRS-059 | Mailumleitung Dev-Builds | 1 | belegt |
|
||||
| SwRS-066 | Belegsperre für Web-Accounts | 1 | belegt |
|
||||
| SwRS-067 | Nexus-Transportsicherheit | 1 | belegt |
|
||||
| SwRS-068 | Webservice-Interceptor-Kette | 1 | belegt |
|
||||
|
||||
**Abrechnung/Fakturierung (46 Anforderungen; 45 mit PRIMÄR, 1 HYPOTHESE):**
|
||||
|
||||
| ID | Titel (Kurz) | PRIMÄR | Status |
|
||||
|---|---|---|---|
|
||||
| SyRS-004 | Rechnungen erstellen | 1 | belegt |
|
||||
| SyRS-005 | Rechnungsstorno (auch Sicherheit) | 1 | belegt |
|
||||
| SyRS-006 | Festschreibung (auch Sicherheit) | 1 | belegt |
|
||||
| SyRS-007 | Gutschriften | 1 | belegt |
|
||||
| SyRS-010 | Automatische Vertragsabrechnung | 1 | belegt |
|
||||
| SyRS-011 | Klickabrechnung | 1 | belegt |
|
||||
| SyRS-012 | Zeitenabrechnung | 1 | belegt |
|
||||
| SyRS-013 | Anzahlungen | 2 | belegt |
|
||||
| SyRS-018 | Kassenbuch | 1 | belegt |
|
||||
| SyRS-021 | Rappenrundung CH | 2 | belegt |
|
||||
| SyRS-023 | Nummernkreise | 1 | belegt |
|
||||
| SyRS-024 | Belegversand | 1 | belegt |
|
||||
| SyRS-025 | Kreditlimit | 1 | belegt |
|
||||
| SyRS-062 | MSP-Abrechnung | 1 | belegt |
|
||||
| SyRS-071 | Zahlungseingänge | 1 | belegt |
|
||||
| SyRS-072 | Onlinebanking-Zuordnung | 1 | belegt |
|
||||
| SyRS-073 | SEPA-Export | 1 | belegt |
|
||||
| SyRS-074 | Mahnläufe | 2 | belegt |
|
||||
| SyRS-075 | OPOS | 1 | belegt |
|
||||
| SyRS-076 | FiBu-Export | 2 | belegt |
|
||||
| SyRS-077 | Bankverbindungen | 2 | belegt |
|
||||
| SyRS-082 | Lizenzprüfung (Abrechnungsbezug Hersteller) | 1 | belegt |
|
||||
| SyRS-104 | E-Rechnung | 1 | belegt |
|
||||
| SwRS-012 | Rundung über Steuerkorrektur | 1 | belegt |
|
||||
| SwRS-015 | Kreditlimitberechnung | 1 | belegt |
|
||||
| SwRS-018 | Anzahlungsmechanik | 1 | belegt |
|
||||
| SwRS-019 | Intervallfortschreibung | 1 | belegt |
|
||||
| SwRS-020 | Pro-rata-Normalisierung | 1 | belegt |
|
||||
| SwRS-021 | Voraus-/Nachberechnung | 1 | belegt |
|
||||
| SwRS-022 | Kontingentbuchung | 1 | belegt |
|
||||
| SwRS-023 | Kontingent-Änderungslog | 1 | belegt |
|
||||
| SwRS-024 | Klickzähler-Historie | 1 | belegt |
|
||||
| SwRS-025 | Nummernvergabe CAS | 1 | belegt |
|
||||
| SwRS-026 | SEPA-Formate/Mandatssequenz | 1 | belegt |
|
||||
| SwRS-027 | SEPA-Folgen/Rücknahme | 1 | belegt |
|
||||
| SwRS-028 | Banking-Zuordnungsregex | 1 | belegt |
|
||||
| SwRS-029 | DATEV EXTF 700 | 1 | belegt |
|
||||
| SwRS-030 | Mahnstufen/Sperren | 1 | belegt |
|
||||
| SwRS-031 | Zahlungslöschung mit Rückrechnung | 1 | belegt |
|
||||
| SwRS-035 | Floating-Lizenzzählung | 1 | belegt |
|
||||
| SwRS-061 | E-Rechnungs-Erzeugungsregeln | 1 | belegt |
|
||||
| SwRS-062 | ZUGFeRD-Import | 1 | belegt |
|
||||
| SwRS-063 | Pauschalfilter/Zuschläge | 1 | belegt |
|
||||
| SwRS-064 | Sonderartikel-Import | 1 | belegt |
|
||||
| SwRS-070 | Batch-/Paging-Verarbeitung | 1 | belegt |
|
||||
| SwRS-071 | Sammelrechnung Konzern | 0 | **HYPOTHESE** (regelkonform gekennzeichnet) |
|
||||
|
||||
---
|
||||
|
||||
## Selbstbewertung
|
||||
|
||||
**1. Analysetiefe (absolute Zahlen):** Von 146 Inventarmodulen wurden **33 tief**, **66 mittel**
|
||||
und **47 flach** analysiert; **0 Module blieben unanalysiert**. Die Vertiefung folgte der
|
||||
vorgegebenen Risikopriorisierung: Sicherheits-/Anmelde-/Rechtelogik (M69-M72, M80, M116, M117),
|
||||
Abrechnung/Fakturierung (M04, M08, M09, M14, M16, M61-M64, M66, M68, M94) und Berechtigungen
|
||||
(M29, M38, M70, M141) sind tief abgedeckt; die flache Randabdeckung betrifft überwiegend kleine
|
||||
Zusatzmodule und Schnittstellen mit dünnem Codebestand.
|
||||
|
||||
**2. Mindestabdeckung:** Erreicht. Jedes der 146 Module trägt mindestens eine Anforderung; kein
|
||||
Modul musste mit Begründung als `nicht analysiert` geführt werden. 11 Module tragen ihre einzige
|
||||
Anforderung als `[HYPOTHESE]` (M46, M79, M96, M99, M101, M102, M122, M129, M131, M133, M139) –
|
||||
das ist bewusste Abgrenzung, keine Lücke im Sinne der Mindestabdeckung.
|
||||
|
||||
**3. Dünne Belegstellen (hoher SEKUNDÄR-/KONTEXT- oder Hypothesenanteil):**
|
||||
- Die 13 Hypothesen (siehe `Hypothesen.md`) stützen sich ausschließlich auf SEKUNDÄR-Belege
|
||||
(Dateiexistenz, Klassennamen) – v. a. kleine Schnittstellenmodule (docuFORM, COP, Telekom Dive,
|
||||
TANSS, CPra, TradePool, Mobile, ItPlanner, Workflows, Telemetrie, ExternesHelpdesk) sowie
|
||||
AutoLock und Sammelrechnung.
|
||||
- StRS-Belege sind konstruktionsbedingt häufig SEKUNDÄR/KONTEXT (Geschäftsziele sind nicht
|
||||
direkt im Code kodiert); die zugehörigen SyRS/SwRS tragen die PRIMÄR-Belege.
|
||||
- Flach eingestufte Module (47) stützen sich auf Dateibestand und Methodensignaturen ohne
|
||||
vollständige Methodenlektüre; die Aussagen sind bewusst auf das dadurch Belegbare begrenzt.
|
||||
- Beim Passwortmanager (SyRS-091) ist die Existenz der Ver-/Entschlüsselung belegt, das
|
||||
Kryptoverfahren selbst aber ungeprüft.
|
||||
|
||||
**4. Hypothesenführung:** 13 Hypothesen (5,0 % des Sets) wurden geführt – die Analyse kommt
|
||||
also nicht ohne offene Punkte aus; eine Begründung für „null Hypothesen" entfällt.
|
||||
|
||||
**5. Erkenntnisse für eine Folge-Iteration (Nachschlagsempfehlungen):**
|
||||
1. **Hypothesenauflösung:** Die 13 Hypothesen sind konkret adressierbar (Methodenanalyse von
|
||||
TanssBL, TelekomDiveBL, TradePoolBL, MobileBL, CPraConnectorBL, Workflow-Engine,
|
||||
docuFORM-Konsument, COP-Aufrufer, AutoLock-Mechanik, Sammelrechnungs-Bündelung,
|
||||
Telemetrie-Datenfluss) – geschätzt je Modul wenige Dateien.
|
||||
2. **ReceiptBL-Resttiefe:** Die 10.000+-Zeilen-Klasse ReceiptBL wurde gezielt (Limit, Rechte,
|
||||
Concurrency, Logs), aber nicht vollständig gelesen; SaveReceipt-Callbacks, Belegkopier- und
|
||||
Versandpfade bieten weitere Regeln (z. B. automatisches Schließen,
|
||||
AutomaticallyCloseReceiptHelperBL).
|
||||
3. **Steuerlogik:** TaxBL und die MwSt-Zuordnung (innergemeinschaftlich, Drittland,
|
||||
Reverse-Charge) wurden nicht vertieft – für ein Abrechnungssystem prüfenswert.
|
||||
4. **Provisionen:** ReceiptProvisionBL/Provision-Schemata (WPF-Modul Provision) sind nur am Rand
|
||||
erfasst.
|
||||
5. **Web-Rechtekatalog:** Die WebRights-Einzelrechte (Portalumfang) wurden nicht enumeriert –
|
||||
für den Zuschnitt des Zielportals nützlich.
|
||||
6. **UI-Pflichtfelder/Validierungen im Client:** Die WPF-Views enthalten weitere clientseitige
|
||||
Validierungen, die serverseitig nicht sichtbar sind; für Feature-Parität stichprobenhaft
|
||||
erheben.
|
||||
7. **Konsolidierungsentscheidungen vorbereiten:** Für die markierten Kandidaten (Gerätedaten
|
||||
dreifach, Inventur alt/neu, Einstellungen zweigleisig, Versandwege, Vereinbarungen vs.
|
||||
Verträge) je eine Feldabgleich-Matrix erstellen, damit Fachexperten in Schritt 7 entscheiden
|
||||
können.
|
||||
8. **Werkzeuggrenze:** Die Change-Historie (Git-Log) stand als Artefakt nicht im Fokus dieser
|
||||
Iteration; Commit-Messages könnten KONTEXT-Belege für Übernahmewürdigkeits-Einstufungen
|
||||
(veraltet/Workaround) liefern.
|
||||
|
||||
**Methodische Anmerkung:** Alle Zahlen dieses Berichts (IDs, Belegabdeckung, Tracelink-Ziele,
|
||||
Hypothesenabgleich) wurden skriptgestützt aus den abgegebenen Dateien selbst ermittelt, nicht
|
||||
manuell gezählt.
|
||||
+70
@@ -0,0 +1,70 @@
|
||||
# Glossar
|
||||
|
||||
Domänen- und Systembegriffe, wie sie in den Anforderungen (StRS/SyRS/SwRS) verwendet werden.
|
||||
Technische Bezeichner (Klassen, Tabellen, Spalten) bleiben in Originalsprache.
|
||||
|
||||
| Begriff | Definition |
|
||||
|---|---|
|
||||
| Abholliste | Belegart für die Abholung von Geräten/Waren beim Kunden (Tabellen `AbholKopf`/`AbholPos`). |
|
||||
| Account | Zentraler Geschäftspartner-Datensatz (Kunde, Lieferant, Interessent) im neuen Datenmodell (`Accounts`, `AccountCustomers`, `AccountSuppliers`); Alt-Tabellen: `Kunden`, `Kreditor`. |
|
||||
| AccountDevice | Zweite Datenhaltung für Kundengeräte (Seriennummer, Modell, Garantie); Konsolidierungskandidat mit Stammblatt und AssetManagement. |
|
||||
| Aktionspreis | Zeitlich begrenzter Einkaufs-/Verkaufspreis je Artikel (Tabelle `HerstellerArtikAktionspreis`). |
|
||||
| AnlageLog | Gemeinsame Log-Tabelle aller Belegarten; Belegart über `AnlageArt`-Code (1=Angebot … 4=Rechnung, 22=Vertrag). |
|
||||
| Anwendungs-GUID (ApplicationKind) | GUID, die eine anmeldeberechtigte Anwendung identifiziert und lizenziert (z. B. c-entron.NET, ServiceBoard, Outlook-Add-In). |
|
||||
| AppUser | Internes Benutzerkonto eines Mitarbeiters (Tabelle `Sichbenu`); Gegenstück: Web-Account für Endkunden. |
|
||||
| AssetManagement (DocuBoard) | Dritte Gerätedatenhaltung: automatisiert erhobene IT-Inventardaten (AD-Scans, SNMP) je Kunde. |
|
||||
| Barcode/Seriennummer | Serialisierte Bestandseinheit mit Zustandsautomat (`BarcodeState`, 20 Zustände) über Lager, Belege, RMA, Stammblatt. |
|
||||
| Barrechnung | Rechnung mit `IsCashAsset`; erzeugt Kassenbuchbuchungen und ist vom Storno ausgeschlossen. |
|
||||
| Belegkette / Weiterverarbeitung | Überführung eines Belegs in Folgebelege (Angebot→Auftrag→Lieferschein→Rechnung) mit gespeicherter Herkunftsbeziehung ("Forwarding"). |
|
||||
| Beleg (Receipt) | Oberbegriff für Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholliste, Vertrag sowie die Lieferanten-Gegenstücke; gemeinsame Basisklasse `ReceiptBase`. |
|
||||
| BillingKind (Voraus-/Nachberechnung) | Abrechnungsart eines Vertrags: Vorausberechnung (`Billingadvance`) vor Leistungsbeginn oder nachträgliche Berechnung nach Periodenende. |
|
||||
| C-FLOW | Produktname der Ticketvorlagen (automatische/manuelle Ticketerzeugung aus Vorlagen). |
|
||||
| ConcurrencyControlGuid | Beleg-Versionsstempel für optimistische Sperre; Abweichung ⇒ Fehler "ChangedByOtherInstance". |
|
||||
| DunningStop (Mahnsperre) | Kennzeichen auf Kunde oder Rechnung, das die Aufnahme in Mahnläufe verhindert. |
|
||||
| EDI | Elektronischer Belegaustausch mit Distributoren (ALSO, ALSO CH, Alltron, Herweck, Komsa, OpenTrans 2.1, EGIS). |
|
||||
| Eskalationsstufe | Eine von bis zu drei zeitgesteuerten Eskalationen eines Tickets (Wartezeiten `WaitHourEsc1-3`) innerhalb definierter Arbeitszeitfenster. |
|
||||
| ESR | Schweizer Einzahlungsschein mit Referenznummer; Felder am Rechnungsbeleg (`EsrReferenceNumber` u. a.). |
|
||||
| Festschreibung | Unveränderlichmachen einer Rechnung (`RechKopf.IsFixed=1`) mit Pflicht-Logeintrag; GoBD-relevant. |
|
||||
| Filiale (Branch) | Organisationseinheit unterhalb des Mandanten mit eigenen Nummernkreisen und Lagerzuordnung; einschränkende Rechte binden Benutzer an ihre Filiale. |
|
||||
| Floating-Lizenz | Lizenzzählung über gleichzeitig aktive Sitzungstickets je Anwendungs-GUID. |
|
||||
| Gutschrift | Belegart zur Minderung einer Forderung (`GutKopf`/`GutPos`). |
|
||||
| Helpdesk / Ticket | Servicevorgang mit Kunde, Status (konfigurierbar), Typ, Priorität, Kategorien, Bearbeitern, Zeiterfassungen. |
|
||||
| I3D | Systemweiter Primärschlüsselname (Identity-Spalte) aller Tabellen. |
|
||||
| Kontingent | Vertraglich vereinbartes Leistungsvolumen (Stunden oder Betrag) mit Regeln für Überbuchung, Restmitnahme und abweichende Kontingentintervalle. |
|
||||
| Klickabrechnung | Nutzungsabrechnung über Gerätezählerstände (Drucker/Kopierer) mit Freimengen und Staffelpreisen. |
|
||||
| Kreditlimit | Kundenlimit; Prüfart netto/brutto/keine (`CreditLimitCalculationKind`), Überschreitung erzeugt Bestätigungsdialog. |
|
||||
| Leitweg-ID | Empfänger-Routing-Kennung der XRechnung; am Kunden hinterlegt (`IAccountCustomer.LeitwegID`). |
|
||||
| Lizenz (GUID-Lizenz) | Produkt-/Funktionsfreischaltung als GUID mit Anzahl, Gültigkeitsdatum und Maximalversion; Quelle: Lizenzserver. |
|
||||
| Mandant (Mandator) | Rechtlich selbständige Firmeneinheit mit eigenen Bankdaten, SEPA-Gläubiger-ID und Nummernkreisen. |
|
||||
| Mandat (SEPA-Mandat) | Einzugsermächtigung an einer Bankverbindung mit Sequenz (First/Recurrent/Last/Single) und Gültigkeit. |
|
||||
| MasterDataList → siehe Stammblatt | |
|
||||
| MSP | Managed Services Provider; MSP-Sammler erfassen nutzungsbasierte Mengen (z. B. Lizenzen) zur Vertragsabrechnung. |
|
||||
| Nummernkreis (NumberGroup) | Konfigurierbarer Nummernbereich je Objektart, Mandant und Filiale mit Intervall und aktuellem Stand. |
|
||||
| Nexus | Blazor-Webanwendung der Suite (ServiceBoard, Kundenportal/WebCart, WebOffer, Verwaltung). |
|
||||
| OPOS | Offene-Posten-Verwaltung; Abgleich der Zahlungsstände mit der Finanzbuchhaltung. |
|
||||
| Pro-rata-Normalisierung | Anteilige Berechnung der ersten Vertragsperiode nach Kalendertagen (`IsNormalize`). |
|
||||
| Rappenrundung | Schweizer Rundung des Bruttobetrags auf 0,05 durch Anpassung des Steueranteils (Einstellung `CommercialRoundCH`). |
|
||||
| Recht (AppRight) | Einzelberechtigung (750 Konstanten in `UserRightsConst`); Vergabe ausschließlich über Gruppen (`Sichtrus`/`Sichmemb`). |
|
||||
| Einschränkendes Recht | Recht, das die Sichtbarkeit verengt statt erweitert (z. B. "Tickets anzeigen - nur eigene"). |
|
||||
| RMA | Retouren-/Reparaturvorgang; genau eine RMA je Ticket (Unique Index auf `Rma.HelpdeskI3D`). |
|
||||
| RMM | Remote Monitoring & Management; liefert Geräte-/Nutzungsdaten für die Vertragsabrechnung. |
|
||||
| Sammelrechnung | Konsolidierte Rechnung über mehrere Verträge eines Kunden/Konzerns (`CollectInvoice`); Bündelungsregel als Hypothese offen. |
|
||||
| SEPA-Export | Erzeugung von pain.008-Lastschriftdateien mit Folgewirkungen (Exportkennzeichen, optional Rechnungsabschluss, Mandatssequenz). |
|
||||
| ServiceBoard | Webbasierter Ticketarbeitsplatz der Techniker (Kanban, Zeiten, Mails, Planung). |
|
||||
| Sitzungsticket | Zeitlich begrenzte Sitzungskennung des Webservice (Standard 30 min, gleitend verlängert). |
|
||||
| Skontosperre | Artikelkennzeichen `NoEarlyPaymentDiscountAllowed`; nimmt Positionen aus der Skontobasis aus. |
|
||||
| Sonderabkommen (SpecialAgreement) | Einkaufsvereinbarung mit Lieferanten (eigener EK oder EK-Reduktion) je Artikel. |
|
||||
| Sonderpreis (Kundensonderpreis) | Kundenindividuelle Preisregel je Artikel in fünf Arten (Fixpreis, EK-Aufschlag, Abschläge auf UVP/VK/Listenpreis); definiert zugleich das WebCart-Sortiment. |
|
||||
| Stammblatt (MasterDataList) | Gerätestammsatz für die Abrechnung (Seriennummer, Zähler, Vertrag, Ursprungsrechnung); Konsolidierungskandidat mit AccountDevice/AssetManagement. |
|
||||
| Staffelpreis (VolumePrice) | Mengenabhängige Preisstufen mit vier Verkaufspreislisten (VK1-VK4) und Staffel-EK. |
|
||||
| Stundenzuschlagssatz | Zeitfensterbezogener Zuschlag auf Servicezeiten (z. B. Nacht/Wochenende), als Überlappung je Zeiterfassung berechnet. |
|
||||
| Ticket → siehe Helpdesk | |
|
||||
| TimerBilling (Zeitenabrechnung) | Überführung abrechenbarer Ticketzeiten in Auftrags-/Rechnungspositionen ohne Doppelabrechnung. |
|
||||
| Übernahmewürdigkeit | Bewertungsfeld dieser Spezifikation: übernehmen / Workaround / Sonderfall / veraltet. |
|
||||
| Vertrag (ReceiptContract) | Belegart für Dauerleistungen mit Abrechnungsintervall, Kontingenten, Verlängerung und automatischer Abrechnung (`VertragKopf`/`VertragPos`). |
|
||||
| VertragRechKopfZuordnung | Verknüpfungstabelle Vertrag↔Rechnung je Abrechnungslauf inkl. Kontingentbuchung und Zwischenrechnungskennzeichen. |
|
||||
| Web-Account | Endkunden-Login für das Portal (getrenntes Rechtesystem `WebRights`); Voraussetzung: durchgehend aktive Kette Kontakt→Adresse→Kunde. |
|
||||
| WebCart | Shop des Kundenportals; Sortiment = Artikel mit aktiven Sonderpreisen des Kunden. |
|
||||
| WebOffer | Online-Angebotsansicht mit Freigabe-Zustandsautomat (`WebReceiptState`, 9 Zustände inkl. Signatur). |
|
||||
| XRechnung / ZUGFeRD | Strukturierte E-Rechnungsformate; Erzeugung je Rechnung mit Leitweg-ID, Einlesen von ZUGFeRD 2.1-Eingangsrechnungen. |
|
||||
| Zwischenrechnung (Kontingent) | Kontingentbuchung bei abweichendem Kontingent- vs. Abrechnungsintervall (`DifferContingentInterval`). |
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
# Hypothesen
|
||||
|
||||
Diese Datei enthält **genau die Anforderungen mit `[HYPOTHESE]`-Markierung** aus StRS/SyRS/SwRS
|
||||
(Status `HYPOTHESE`) – deckungsgleich mit den Inline-Markierungen der Spezifikationen.
|
||||
Offene Punkte ohne zugehörige Anforderung stehen in der Selbstbewertung des Analyseberichts.
|
||||
|
||||
Gesamtzahl: **13 Hypothesen** (11 × SyRS, 2 × SwRS, 0 × StRS).
|
||||
|
||||
| Nr. | ID | Titel | Hypothese (Kurzfassung) | Fehlende Information zur Bestätigung |
|
||||
|---|---|---|---|---|
|
||||
| 1 | SyRS-055 | Anbindung externer Helpdesk-Systeme | Tickets werden mit externen Helpdesk-Systemen ausgetauscht. | Nur `ExternalHelpdeskConfigurationBL.cs` gefunden; Synchronisationslogik (Richtung, Umfang, Zielsysteme) fehlt im analysierten Code. |
|
||||
| 2 | SyRS-089 | Telemetrie und Profiling | Nutzungs-/Leistungsdaten werden zur Produktverbesserung erfasst. | Inhalt, Übertragungsweg und Empfänger der Telemetriedaten (TelemetryBL/ProfilerBL) nicht verifiziert; DSGVO-Einordnung offen. |
|
||||
| 3 | SyRS-106 | docuFORM-Anbindung | Gerätezähler-/Flottendaten werden von docuFORM abgerufen und der Klickabrechnung bereitgestellt. | Konsumierender Codepfad vom `DocuFormRestApiClient` zur Zählerübernahme nicht nachvollzogen. |
|
||||
| 4 | SyRS-109 | COP-Datenzugriff | Produkt-/Preisdaten aus COP dienen der Artikelanreicherung bzw. dem Einkauf. | Aufrufer und fachlicher Zweck des `CopApi`-Clients nicht identifiziert. |
|
||||
| 5 | SyRS-111 | Telekom-Dive-Schnittstelle | Austausch von Auftrags-/Bestandsdaten mit dem Telekom-Dive-Portal. | Methoden der `TelekomDiveBL` und zugehörige Views nicht analysiert; Richtung und Inhalt unklar. |
|
||||
| 6 | SyRS-112 | TANSS-Datenübernahme | Übernahme von Tickets/Kunden/Zeiten aus TANSS (vermutlich Migration). | Unklar, ob einmalige Migrations- oder laufende Austauschschnittstelle; Methodenanalyse `TanssBL` fehlt. |
|
||||
| 7 | SyRS-132 | TradePool-Anbindung | Import von Artikel-/Preisdaten einer Handelsplattform "TradePool". | Datenquelle, Aktualität und fachlicher Nutzungskontext der Plattform unbelegt. |
|
||||
| 8 | SyRS-139 | Mobile Unterstützung | Versorgung mobiler Clients mit Mitarbeiter-/Kontaktdaten. | Konsumierende Mobile App und tatsächlicher Funktionsumfang unbekannt (nur `MobileBL` mit 3 Methoden). |
|
||||
| 9 | SyRS-141 | ItPlanner | Strukturierung von IT-Planungsobjekten über kategorisierte Checklisten. | Nur `ChecklistVirtualObjectCategoryBL` gefunden; restlicher Modulzweck (UI, Prozesse) unklar. |
|
||||
| 10 | SyRS-143 | CPra-Webhook-Anbindung | Übergabe von Vorgängen mit Kunden-/Ticketbezug an ein Partnersystem "CPra" über Webhooks. | Identität des Zielsystems CPra und ausgelöste Prozesse unbekannt. |
|
||||
| 11 | SyRS-149 | Prozess-/Workflow-Definitionen | Grafisch definierte Workflows werden an Objekten ausgeführt. | Ausführungssemantik (Trigger, Engine, Schrittausführung) nicht nachvollzogen; nur Definitionsverwaltung belegt. |
|
||||
| 12 | SwRS-065 | Automatische Belegsperre (AutoLock) | Belege/Tickets werden beim Öffnen pessimistisch gesperrt. | Sperrmechanik (Sperrtabelle, Timeout, Entsperrung) nur über Parameternamen `autoLockIfNewReceipt`/`IgnoreLock` indiziert. |
|
||||
| 13 | SwRS-071 | Sammelrechnung für Konzerne | Mehrere Verträge werden in einer Sammelrechnung gebündelt und an Konzernempfänger versendet. | Bündelungskriterien (welche Verträge in eine Rechnung) nicht verifiziert; nur Empfänger-/Vorlagenlogik belegt. |
|
||||
|
||||
## Vollständige Anforderungsblöcke
|
||||
|
||||
Die vollständigen Blöcke stehen in den jeweiligen Spezifikationen:
|
||||
|
||||
- SyRS-055, SyRS-089, SyRS-106, SyRS-109, SyRS-111, SyRS-112, SyRS-132, SyRS-139, SyRS-141, SyRS-143, SyRS-149 → `SyRS.md`
|
||||
- SwRS-065, SwRS-071 → `SwRS.md`
|
||||
+778
@@ -0,0 +1,778 @@
|
||||
# StRS – Stakeholder Requirements Specification
|
||||
|
||||
**System:** c-entron ERP-Suite (Branchen-ERP für IT-Systemhäuser)
|
||||
**Quelle:** Reverse Requirements Engineering aus der Codebasis, statische Analyse
|
||||
**Norm:** ISO/IEC/IEEE 29148:2018, Ebene Stakeholder-Anforderungen
|
||||
**Hinweis:** Alle Aussagen sind aus Artefakten der Codebasis abgeleitet. `BL/` steht für
|
||||
`src/backend/Centron.BL/`. Die fachliche Sicht wurde aus Modulstruktur, durchgesetzten Regeln
|
||||
und Benutzertexten rekonstruiert; direkte Stakeholder-Aussagen (Interviews, Lastenhefte) lagen
|
||||
nicht vor, weshalb StRS-Belege überwiegend `SEKUNDÄR`/`KONTEXT` sind. Die zugehörigen
|
||||
Systemregeln sind auf SyRS-/SwRS-Ebene mit `PRIMÄR`-Belegen unterlegt (siehe Tracelinks).
|
||||
|
||||
**Identifizierte Akteure (aus Rechten, Modulen und UI-Texten):**
|
||||
Vertrieb/Innendienst, Servicetechniker, Lagermitarbeiter, Buchhaltung/Controlling,
|
||||
Administrator, Geschäftsleitung, Endkunde (Web-Account im Kundenportal),
|
||||
Lieferant/Distributor (EDI), Fremdsysteme (RMM, TANSS, RiverSuite, docuFORM).
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
ID: StRS-01
|
||||
Titel: Einheitliche Verwaltung von Geschäftspartnern (Accounts)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertrieb/Innendienst
|
||||
Vorbedingung: Benutzer ist angemeldet und besitzt die Account-Rechte.
|
||||
Fakt: Die Codebasis führt Kunden, Lieferanten und Interessenten in einem gemeinsamen
|
||||
Account-Modell (Tabellen Accounts/AccountCustomers/AccountSuppliers, Alt-Tabellen
|
||||
Kunden/Kreditor) mit Rechteprüfung für Anlegen/Bearbeiten/Löschen.
|
||||
Aussage: Das System soll alle Geschäftspartner (Kunden, Lieferanten, Interessenten) zentral
|
||||
mit Adressen und Ansprechpartnern verwalten.
|
||||
Ergebnis: Ein Geschäftspartner ist genau einmal erfasst und für alle Module referenzierbar.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Accounts/AccountBL.cs:1305-1366 (CheckRightsFromUser mit CREATE_CUSTOMER/EDIT/DELETE, Fehlermeldungen "Fehlende Rechte um Accounts zu erstellen") - Begründung: durchgesetzte Kernoperationen des Accountstamms.
|
||||
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql (Tabellen Accounts, AccountCustomers, AccountSuppliers, Kunden, Kreditor) - Begründung: Datenmodell der Partnerverwaltung.
|
||||
Prüfidee: Ein Benutzer ohne CREATE_CUSTOMER-Recht kann keinen Account anlegen; mit Recht wird der Account angelegt und ist in Verkaufs- und Servicebelegen auswählbar.
|
||||
Tracelinks: SyRS-036, SyRS-037, SwRS-051
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - zentrale Stammdatenbasis jedes ERP.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-02
|
||||
Titel: Durchgängige Vertriebsbelegkette
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertrieb/Innendienst
|
||||
Vorbedingung: Kunde ist angelegt.
|
||||
Fakt: Die Codebasis implementiert Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift
|
||||
und Abholliste als Belegarten mit gemeinsamer Basisklasse und Weiterverarbeitung
|
||||
(Forwarding) zwischen den Arten.
|
||||
Aussage: Das System soll den Vertriebsprozess als Belegkette von Angebot über Auftrag und
|
||||
Lieferschein bis Rechnung/Gutschrift abbilden, wobei Folgebelege aus Vorgängerbelegen
|
||||
entstehen.
|
||||
Ergebnis: Jeder Beleg kennt seine Ursprungsbelege; Mengen und Werte fließen in Folgebelege.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs (gemeinsame Basisklasse) und BL/Sales/Receipts/ReceiptBL.cs:1563/2462 (ValidateReceiptForwarding) - Begründung: Belegkette und geprüfte Weiterverarbeitung sind implementiert.
|
||||
- [KONTEXT] docs/reference/receipts/receipts-backend-architecture.md - Begründung: beschreibt die Belegarten und deren Tabellen.
|
||||
Prüfidee: Aus einem Angebot wird ein Auftrag erzeugt; der Auftrag referenziert das Angebot; aus dem Auftrag entstehen Lieferschein und Rechnung mit übernommenen Positionen.
|
||||
Tracelinks: SyRS-001, SyRS-002, SyRS-003, SyRS-004, SyRS-007, SyRS-008, SyRS-026
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernprozess des Vertriebs.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-03
|
||||
Titel: Wiederkehrende Abrechnung über Verträge
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung/Controlling
|
||||
Vorbedingung: Vertrag mit Abrechnungsintervall ist erfasst.
|
||||
Fakt: Verträge (VertragKopf/VertragPos) tragen Abrechnungsintervall, Abrechnungsart und
|
||||
das Kennzeichen automatische Abrechnung; AutomaticFacturaBL erzeugt daraus Rechnungen.
|
||||
Aussage: Das System soll Dauerschuldverhältnisse (Wartung, Miete, Managed Services) über
|
||||
Verträge mit definierten Abrechnungsintervallen automatisch fakturieren.
|
||||
Ergebnis: Zum Stichtag entstehen Rechnungen für alle fälligen Verträge ohne manuelle Einzelerfassung.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs:1474-1627 (NextDate/SetNextBillingDate/ContractForBilling) - Begründung: Intervallfortschreibung und Fälligkeitsermittlung sind implementiert.
|
||||
- [KONTEXT] docs/reference/receipts/contracts-backend.md - Begründung: beschreibt Abrechnungsintervalle und AutomaticFacturaBL.
|
||||
Prüfidee: Ein Monatsvertrag mit Beginn 01.01. erzeugt bei Abrechnung bis 31.03. drei Rechnungen mit korrekten Leistungszeiträumen.
|
||||
Tracelinks: SyRS-009, SyRS-010, SwRS-019, SwRS-020, SwRS-021
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - zentrales Geschäftsmodell der Zielbranche (Systemhäuser/MSP).
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-04
|
||||
Titel: Nutzungsbasierte Abrechnung (Zähler, Kontingente, MSP)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung/Controlling
|
||||
Vorbedingung: Vertrag mit Zähler- oder Kontingentbezug besteht.
|
||||
Fakt: Die Codebasis verwaltet Gerätezähler (Klickzähler) mit Historie, Freimengen und
|
||||
Staffelpreisen sowie Vertragskontingente mit Überbuchung/Restmitnahme; MSP-Kollektoren
|
||||
liefern nutzungsbasierte Mengen.
|
||||
Aussage: Das System soll verbrauchsabhängige Leistungen (Druckklicks, Stundenkontingente,
|
||||
MSP-Lizenzen) erfassen und periodengerecht abrechnen.
|
||||
Ergebnis: Nutzungsmengen werden je Periode bewertet, mit Freimengen/Kontingenten verrechnet und fakturiert.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs:1098-1245 (StoreBookedContingent inkl. Überbuchung/Restmitnahme) - Begründung: Kontingentverrechnung ist durchgesetzte Logik.
|
||||
- [PRIMÄR] ebd.:1248-1256 (UpdClickCounterHistory) - Begründung: Klickzähler werden je Rechnungsposition historisiert.
|
||||
- [SEKUNDÄR] BL/Statistics/MspCollectors/MspCollectorsBL.cs - Begründung: MSP-Mengenerfassung vorhanden.
|
||||
Prüfidee: Ein Klickvertrag mit Freimenge X und Zählerständen erzeugt eine Rechnung nur über die Menge oberhalb X.
|
||||
Tracelinks: SyRS-011, SyRS-062, SwRS-022, SwRS-024
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Differenzierungsmerkmal für MSP-Geschäft.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-05
|
||||
Titel: Servicegeschäft über Tickets mit abrechenbarer Zeiterfassung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Servicetechniker
|
||||
Vorbedingung: Kunde vorhanden; Techniker angemeldet.
|
||||
Fakt: Helpdesk-Tickets tragen Kunde, Status, Kategorien, Bearbeiter und Zeiterfassungen
|
||||
(HelpdeskTimer) mit Abrechnungsstatus; TimerBilling überführt Zeiten in Belege.
|
||||
Aussage: Das System soll Serviceleistungen als Tickets führen, darauf erfasste Arbeitszeiten
|
||||
dokumentieren und die abrechenbaren Zeiten in Rechnungen überführen.
|
||||
Ergebnis: Jede abrechenbare Minute ist einem Ticket zugeordnet und wird genau einmal fakturiert.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs:233-383 (SearchTimers mit OnlyCalculable, AlreadyBilledTime) - Begründung: Abrechnungsselektion der Zeiten ist implementiert.
|
||||
- [SEKUNDÄR] CentronRights.md Abschnitt Helpdesk - Begründung: dokumentiert die Ticket-/Zeitrechte fachlich.
|
||||
Prüfidee: Eine auf einem Ticket erfasste abrechenbare Zeit erscheint in der Zeitenabrechnung und nach Fakturierung nicht erneut.
|
||||
Tracelinks: SyRS-045, SyRS-049, SyRS-012, SwRS-063
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kern des Servicegeschäfts.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-06
|
||||
Titel: Fristen- und Eskalationsüberwachung im Service
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Serviceleitung
|
||||
Vorbedingung: Eskalationstypen sind konfiguriert.
|
||||
Fakt: EscalationBL prüft Tickets gegen bis zu drei Eskalationsstufen mit Wartezeiten,
|
||||
Arbeitszeitfenstern und Wochenendregeln und versendet Eskalationsmails.
|
||||
Aussage: Das System soll überfällige Tickets automatisch erkennen und mehrstufig eskalieren.
|
||||
Ergebnis: Verantwortliche werden zeitgestuft benachrichtigt; Eskalationen sind protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Sales/Support/Escalation/EscalationBL.cs:223-332 (DoEscalation, ShouldEscalated mit WaitHourEsc1-3, Sa/So-Flags) - Begründung: Eskalationsregeln sind durchgesetzte Logik.
|
||||
Prüfidee: Ein Ticket ohne Reaktion überschreitet die Stufe-1-Wartezeit innerhalb des Arbeitszeitfensters und löst genau eine Stufe-1-Mail aus.
|
||||
Tracelinks: SyRS-048, SwRS-049
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - SLA-Erfüllung ist vertragsrelevant.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-07
|
||||
Titel: Bestandsführung mit Seriennummernverfolgung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Lagermitarbeiter
|
||||
Vorbedingung: Artikel sind angelegt.
|
||||
Fakt: Bestände werden je Lager geführt; serialisierte Einheiten (Barcodes) durchlaufen
|
||||
einen Zustandsautomaten von "im Lager" über Belege bis Stammblatt/RMA.
|
||||
Aussage: Das System soll Lagerbestände artikel- und lagergenau führen und serialisierte
|
||||
Geräte über ihren gesamten Lebenszyklus (Einkauf, Lager, Verkauf, Service) verfolgen.
|
||||
Ergebnis: Zu jeder Seriennummer ist der aktuelle Verbleib feststellbar; Bestände stimmen mit Belegbewegungen überein.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Warehousing/BarcodeState.cs:5-30 (Zustände InStock…ManuallyBookedOut) - Begründung: Lebenszyklus ist als Enum-Zustandsautomat kodiert.
|
||||
- [PRIMÄR] BL/Warehousing/StockManagement/ArticleStockBL.cs:47-61 (UpdateArticleStock/IncreaseArticleStock) - Begründung: Bestandsfortschreibung ist implementiert.
|
||||
Prüfidee: Wareneingang einer Seriennummer setzt Zustand InStock; Lieferung an Kunden ändert ihn in InDeliveryList/InInvoice; der Lagerbestand sinkt entsprechend.
|
||||
Tracelinks: SyRS-063, SyRS-064, SyRS-067, SwRS-045, SwRS-046
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Voraussetzung für Gewährleistung und Service.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-08
|
||||
Titel: Einkauf über Distributoren mit elektronischem Belegaustausch
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Einkauf
|
||||
Vorbedingung: Distributor-EDI-Zugang ist konfiguriert.
|
||||
Fakt: Die Codebasis enthält Lieferantenbelegarten und EDI-Anbindungen (ALSO, ALSO CH,
|
||||
Alltron, Herweck, Komsa, OpenTrans 2.1, EGIS) für Bestellungen, Auftragsbestätigungen,
|
||||
Lieferavis und Rechnungen.
|
||||
Aussage: Das System soll Bestellungen an Distributoren elektronisch übertragen und deren
|
||||
Rückbelege (Bestätigung, Lieferschein, Rechnung) automatisch einlesen und zuordnen.
|
||||
Ergebnis: Einkaufsbelege entstehen ohne manuelle Doppelerfassung; Seriennummern und Preise werden übernommen.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/EDI/SupplierEdiBL.cs (+ Partial-Klassen je Lieferant) - Begründung: Verarbeitung der Distributor-Dateien ist implementiert.
|
||||
- [KONTEXT] docs/reference/edi/edi-architecture.md - Begründung: beschreibt Ablauf Download→Parsen→Zuordnung.
|
||||
Prüfidee: Eine per EDI empfangene Lieferantenrechnung wird der Bestellung zugeordnet und als Eingangsbeleg angelegt.
|
||||
Tracelinks: SyRS-029, SyRS-030, SyRS-031, SyRS-103, SyRS-110
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - hohes Belegvolumen im Distributionsgeschäft.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-09
|
||||
Titel: Zahlungsabwicklung inklusive SEPA-Lastschrift und Onlinebanking
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung
|
||||
Vorbedingung: Bankverbindungen und Mandate sind hinterlegt.
|
||||
Fakt: Die Codebasis erzeugt SEPA-Lastschriftdateien (pain.008-Varianten), verwaltet
|
||||
Mandatssequenzen, liest Kontoumsätze über finAPI und ordnet sie Rechnungen zu.
|
||||
Aussage: Das System soll offene Rechnungen per SEPA-Lastschrift einziehen und Zahlungseingänge
|
||||
aus Kontoumsätzen automatisch den Rechnungen zuordnen.
|
||||
Ergebnis: Zahlungsstatus der Rechnungen ist aktuell; Lastschriftläufe sind nachvollziehbar protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs:132-360 (ExportInvoices, InvoiceExportDone, RefreshBankInformation) - Begründung: SEPA-Export inkl. Folgebuchungen ist implementiert.
|
||||
- [PRIMÄR] BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs:524-643 (AutoCompleteAccountTransacitons, 3-stufige Zuordnung) - Begründung: automatische Zahlungszuordnung ist implementiert.
|
||||
Prüfidee: Ein Kontoumsatz mit Rechnungsnummer im Verwendungszweck wird der Rechnung zugeordnet und deren bezahlter Betrag erhöht.
|
||||
Tracelinks: SyRS-071, SyRS-072, SyRS-073, SwRS-026, SwRS-027, SwRS-028
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Liquiditätssicherung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-10
|
||||
Titel: Mahnwesen und Offene-Posten-Überwachung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung
|
||||
Vorbedingung: Rechnungen mit überschrittenem Zahlungsziel existieren.
|
||||
Fakt: DunningBL ermittelt mahnbare Kunden/Rechnungen mit drei Mahnstufen und beachtet
|
||||
Mahnsperren auf Kunden- und Rechnungsebene; OPOS-Läufe existieren.
|
||||
Aussage: Das System soll überfällige Forderungen mehrstufig anmahnen und offene Posten
|
||||
kundenbezogen ausweisen.
|
||||
Ergebnis: Mahnläufe erzeugen stufengerechte Mahnungen; gesperrte Kunden/Rechnungen werden übersprungen.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs:58-113 (GetDunningCustomers mit DunningStopActive) - Begründung: Mahnselektion inkl. Sperren ist implementiert.
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/Invoices/Dunning/DunningLevel.cs (None, Level1-3) - Begründung: Mahnstufen sind kodiert.
|
||||
Prüfidee: Eine überfällige Rechnung ohne Sperre erscheint im Mahnlauf; mit gesetzter Mahnsperre erscheint sie nicht.
|
||||
Tracelinks: SyRS-074, SyRS-075, SwRS-030
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Forderungsmanagement.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-11
|
||||
Titel: Übergabe an externe Finanzbuchhaltung
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung / Steuerberater
|
||||
Vorbedingung: Buchungsperiode ist abgeschlossen.
|
||||
Fakt: Es existieren Exportformate für DATEV (ASCII EXTF 700, XML Online 2012/2020), Sage,
|
||||
Lexware, Addison, Abacus, Navision, SAP, Schilling AS400, GDI, Europa3000 sowie
|
||||
OPOS-/Stammdaten-Importe zurück.
|
||||
Aussage: Das System soll Belege und Personenkonten in gängige FiBu-Systeme exportieren und
|
||||
Zahlungsinformationen aus der FiBu reimportieren.
|
||||
Ergebnis: Buchhaltungsrelevante Daten stehen dem FiBu-System periodengerecht zur Verfügung.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Gateway/DataExchange/BookKeeping/DatevAscii/BookKeepingExportDatevAscii.cs:991-1029 (EXTF-Header Format 700) - Begründung: DATEV-Format ist implementiert.
|
||||
- [SEKUNDÄR] src/backend/Centron.Gateway/DataExchange/BookKeeping/ (28 Export-/Importklassen) - Begründung: Formatbreite belegt.
|
||||
Prüfidee: Der DATEV-ASCII-Export erzeugt eine mit "EXTF";700 beginnende Datei, die die exportierten Rechnungen als Buchungsstapel enthält.
|
||||
Tracelinks: SyRS-076, SwRS-029
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - gesetzlich notwendige FiBu-Anbindung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-12
|
||||
Titel: Gesetzeskonforme elektronische Rechnung
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung / öffentliche Auftraggeber
|
||||
Vorbedingung: Rechnung ist erstellt; Kunde verlangt E-Rechnung.
|
||||
Fakt: Die Codebasis erzeugt ZUGFeRD-/XRechnung-Dateien zu Rechnungen (mit Leitweg-ID des
|
||||
Kunden), liest ZUGFeRD-2.1-Eingangsrechnungen und unterstützt das österreichische
|
||||
ebInterface-Format.
|
||||
Aussage: Das System soll Ausgangsrechnungen als strukturierte E-Rechnung (ZUGFeRD/XRechnung,
|
||||
ebInterface) bereitstellen und strukturierte Eingangsrechnungen verarbeiten.
|
||||
Ergebnis: Kunden mit E-Rechnungspflicht erhalten normkonforme Rechnungsdateien.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs:2151-2185 (CreateZugferdFile mit GetLeitwegID, nur InvoiceClass) - Begründung: E-Rechnungserzeugung ist implementiert.
|
||||
- [PRIMÄR] BL/EDI/Zugferd/ZUGFeRD_BL.cs:38 (ReadInvoice ZUGFeRD 2.1) - Begründung: Einlesen strukturierter Rechnungen ist implementiert.
|
||||
- [SEKUNDÄR] docs/reference/zugferd-field-mapping.md, src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs - Begründung: Feldzuordnung und AT-Format.
|
||||
Prüfidee: Zu einer Rechnung eines Kunden mit Leitweg-ID wird eine XRechnung-Datei mit dieser Leitweg-ID erzeugt.
|
||||
Tracelinks: SyRS-104, SyRS-105, SwRS-061, SwRS-062
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - gesetzliche Pflicht (E-Rechnung B2G/B2B).
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-13
|
||||
Titel: Feingranularer, rollenbasierter Zugriffsschutz
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Administrator
|
||||
Vorbedingung: Benutzer und Gruppen sind eingerichtet.
|
||||
Fakt: 750 Einzelrechte werden über Gruppen (Sichtrus→Sichmemb→Sichbenu) an Benutzer
|
||||
vergeben; Module und Operationen prüfen Rechte serverseitig; einschränkende Rechte
|
||||
("nur eigene", "nur eigene Filiale") verengen Sichtbarkeit.
|
||||
Aussage: Das System soll jede fachliche Funktion einzeln berechtigbar machen und Rechte
|
||||
ausschließlich über Gruppenzugehörigkeit vergeben.
|
||||
Ergebnis: Benutzer sehen und tun nur, was ihre Gruppenrechte erlauben; Verstöße werden mit Fehlermeldung abgewiesen.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Administration/Rights/AppRightsBL.cs:95-111 (CheckRightsFromUser: SQL über Sichtrus/Sichmemb) - Begründung: durchsetzende Rechteauflösung.
|
||||
- [PRIMÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs (750 `public const int`) - Begründung: Rechtekatalog.
|
||||
- [KONTEXT] CentronRights.md - Begründung: fachliche Beschreibung inkl. einschränkender Rechte.
|
||||
Prüfidee: Entzug eines Gruppenrechts entzieht allen Gruppenmitgliedern die Funktion; ein "nur eigene"-Recht blendet fremde Tickets aus.
|
||||
Tracelinks: SyRS-080, SyRS-058, SwRS-038
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Compliance- und Organisationsanforderung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-14
|
||||
Titel: Unternehmenskonforme Anmeldung (Verzeichnisdienst, 2FA)
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Alle Benutzer
|
||||
Vorbedingung: Benutzerkonto existiert.
|
||||
Fakt: Die Anmeldung unterstützt Benutzername/Passwort, Active Directory und
|
||||
OpenID Connect (Microsoft Entra ID); optional erzwingt das System eine
|
||||
Zwei-Faktor-Prüfung per E-Mail oder RADIUS.
|
||||
Aussage: Das System soll die Anmeldung wahlweise gegen das lokale Konto oder den
|
||||
Unternehmens-Verzeichnisdienst durchführen und eine Zwei-Faktor-Authentifizierung
|
||||
unterstützen.
|
||||
Ergebnis: Nur authentifizierte (und bei aktivierter 2FA zweifach bestätigte) Benutzer erhalten ein Sitzungsticket.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Administration/Logins/Auth/ (BasicAuthenticator, ActiveDirectoryAuthenticator, OpenIdConnectAuthenticator, AuthenticatorFactory) - Begründung: Authentifizierungswege sind implementiert.
|
||||
- [PRIMÄR] BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs:33-120 (ValidateTwoFactor) - Begründung: 2FA-Erzwingung ist implementiert.
|
||||
- [KONTEXT] docs/reference/security/anmelden-mit-microsoft-technische-anleitung.md - Begründung: dokumentierter Entra-ID-Login.
|
||||
Prüfidee: Ein Benutzer mit aktivierter 2FA und abgelaufener Gültigkeitsdauer muss den zweiten Faktor bestätigen, sonst schlägt der Login fehl.
|
||||
Tracelinks: SyRS-078, SyRS-081, SwRS-032, SwRS-037
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Sicherheitsstandard.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-15
|
||||
Titel: Lizenzbasierte Freischaltung von Produkten und Funktionen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Hersteller (nexoware) / Administrator
|
||||
Vorbedingung: Lizenzdatei/Lizenzserver ist erreichbar.
|
||||
Fakt: Lizenzen sind GUIDs mit Anzahl, Gültigkeitsdatum und Maximalversion; Anwendungen
|
||||
prüfen beim Login die Anzahl gleichzeitiger Nutzer über aktive Tickets; Module
|
||||
prüfen HasLicense.
|
||||
Aussage: Das System soll Produkte und Einzelfunktionen nur bei vorhandener Lizenz anbieten
|
||||
und die zulässige Anzahl gleichzeitiger Anmeldungen durchsetzen.
|
||||
Ergebnis: Nicht lizenzierte Funktionen sind unsichtbar/gesperrt; Überschreitungen der Nutzerzahl verhindern den Login.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Administration/Licensing/LicenseManager.cs:258-302 (CheckLicense: Versions- und Anzahl-Prüfung über GetTicketCount) - Begründung: durchsetzende Lizenzprüfung.
|
||||
- [KONTEXT] docs/reference/security/licensing-system.md - Begründung: beschreibt GUID-Lizenzmodell.
|
||||
Prüfidee: Bei erreichter Lizenzanzahl schlägt ein weiterer Login mit "Die maximale Anzahl an Lizenzen wurde erreicht." fehl.
|
||||
Tracelinks: SyRS-082, SwRS-035, SwRS-056
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Vermarktungsmodell des Herstellers; Umsetzung im SaaS-Modell neu zu bewerten.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-16
|
||||
Titel: Mandanten- und Filialfähigkeit
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Geschäftsleitung / Administrator
|
||||
Vorbedingung: Mandanten/Filialen sind eingerichtet.
|
||||
Fakt: Nummernkreise, Bankverbindungen und Belege sind mandanten-/filialbezogen; Rechte
|
||||
können auf die eigene Filiale einschränken; Belege tragen BranchI3D.
|
||||
Aussage: Das System soll mehrere Mandanten und Filialen mit getrennten Nummernkreisen,
|
||||
Bankdaten und filialbezogener Sichtbarkeit unterstützen.
|
||||
Ergebnis: Filialbenutzer arbeiten nur auf Belegen ihrer Filiale, sofern einschränkende Rechte gesetzt sind.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Sales/Receipts/ReceiptBL.cs:10251-10295 (CanUserCreateReceiptsInBranch/CanUserEditReceipt mit BranchI3D-Vergleich) - Begründung: Filialbindung wird durchgesetzt.
|
||||
- [PRIMÄR] BL/Administration/Company/NumberGroupBL.cs:136-152 (Nummernkreise je Mandant und Filiale) - Begründung: getrennte Nummernkreise.
|
||||
Prüfidee: Ein Benutzer mit Filiale A und "nur eigene Filiale"-Recht kann keinen Beleg der Filiale B bearbeiten.
|
||||
Tracelinks: SyRS-083, SyRS-028, SyRS-023
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Multi-Site-Betrieb der Kunden.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-17
|
||||
Titel: Kundenportal im Web
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Endkunde (Web-Account)
|
||||
Vorbedingung: Web-Account ist für den Kunden angelegt.
|
||||
Fakt: Das Nexus-Kundenportal bietet Shop (WebCart), Ticketanlage/-verfolgung inkl.
|
||||
Zeitnachweisen, Vertrags- und Belegübersichten, Dokumente und Formulare.
|
||||
Aussage: Das System soll Endkunden ein Webportal bereitstellen, in dem sie bestellen,
|
||||
Tickets erstellen und verfolgen sowie ihre Verträge, Belege und Dokumente einsehen können.
|
||||
Ergebnis: Endkunden erledigen Standardvorgänge ohne Anruf beim Systemhaus.
|
||||
Belege:
|
||||
- [PRIMÄR] src/nexus/CentronNexus/WebCart/ (WebCartShopPage.razor, WebCartTicketsPage.razor, ContractsOverview.razor, ReceiptsOverview.razor, CustomerDocumentsPage.razor) - Begründung: Portalfunktionen sind implementiert.
|
||||
- [KONTEXT] README.md Abschnitt WebCart - Begründung: beschreibt Zweck (Kunden der Kunden).
|
||||
Prüfidee: Ein Web-Account sieht nach Login den Shop, kann ein Ticket anlegen und seine Verträge einsehen.
|
||||
Tracelinks: SyRS-121, SyRS-126, SwRS-043
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Self-Service reduziert Servicekosten.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-18
|
||||
Titel: Online-Angebotsfreigabe mit Unterschrift
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Endkunde
|
||||
Vorbedingung: Angebot wurde dem Kunden online bereitgestellt.
|
||||
Fakt: Web-Belege durchlaufen Zustände von SendToCustomer über FirstLoaded bis
|
||||
Annahme/Ablehnung/Signatur (WebReceiptState inkl. WebOfferSign,
|
||||
WebOfferSignedWithoutSignature); eine Signaturkomponente existiert.
|
||||
Aussage: Das System soll Kunden Angebote online bereitstellen und deren Annahme, Ablehnung,
|
||||
Änderungswünsche oder digitale Unterschrift erfassen.
|
||||
Ergebnis: Die Kundenentscheidung ist mit Zeitpunkt und ggf. Unterschrift am Beleg dokumentiert.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/WebReceipt/WebReceiptState.cs:6-26 - Begründung: Freigabe-Zustandsautomat ist kodiert.
|
||||
- [SEKUNDÄR] src/nexus/CentronNexus/DocumentSigning/IsolatedSignaturePad.razor - Begründung: Unterschriftskomponente vorhanden.
|
||||
Prüfidee: Ein online angenommenes Angebot wechselt in AcceptFullWebReceipt und ist im Client als angenommen sichtbar.
|
||||
Tracelinks: SyRS-122, SyRS-123, SwRS-044
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - beschleunigt den Vertriebsabschluss.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-19
|
||||
Titel: Gerätestamm beim Kunden für Service und Abrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Servicetechniker / Vertrieb
|
||||
Vorbedingung: Geräte sind beim Kunden im Einsatz.
|
||||
Fakt: Kundengeräte werden in drei getrennten Datenhaltungen geführt: Stammblätter
|
||||
(MasterDataList mit Zähler-, Vertrags- und Rechnungsbezug), AccountDevices
|
||||
(Seriennummer, Modell, Garantie) und AssetManagement (DocuBoard-Inventarisierung).
|
||||
Aussage: Das System soll die beim Kunden befindlichen Geräte mit Seriennummer, Standort,
|
||||
Garantie und Vertragsbezug führen, damit Service und nutzungsbasierte Abrechnung
|
||||
darauf aufsetzen können.
|
||||
Ergebnis: Zu jedem Kundengerät sind Historie, Vertrag und Zähler auffindbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs (SerialNumber, CounterDevice, ContractI3D, InvoiceI3D) - Begründung: Stammblatt-Datenmodell.
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Devices/AccountDevice.cs (SerialNumber, Model, Manufacturer, WarrantyExpiryDate) - Begründung: zweite Gerätedatenhaltung.
|
||||
- [SEKUNDÄR] BL/DocuBoard/AssetManagement*BL.cs - Begründung: dritte Datenhaltung (Inventarisierung).
|
||||
Prüfidee: Ein Drucker mit Stammblatt ist über seine Seriennummer auffindbar und zeigt Vertrag und Zählerhistorie.
|
||||
Tracelinks: SyRS-020, SyRS-059, SyRS-060
|
||||
Konsolidierung: Kandidat: SyRS-020 (Stammblätter), SyRS-059 (AccountDevices), SyRS-060 (AssetManagement) - drei Datenhaltungen für denselben fachlichen Gegenstand "Kundengerät"; im Zielsystem zu einem Asset-Konzept zusammenführen.
|
||||
Übernahmewürdigkeit: übernehmen - fachlich erforderlich, aber konsolidiert statt dreifach.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-20
|
||||
Titel: CRM: Aktivitäten, Kampagnen, Umfragen, Verkaufschancen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertrieb / Marketing
|
||||
Vorbedingung: Accounts existieren.
|
||||
Fakt: Die Codebasis protokolliert Kundenaktivitäten, führt Kampagnen mit Phasen,
|
||||
Telemarketing-Aktionen, Umfragen (auch automatisch nach Ticketabschluss) und
|
||||
CRM-Projekte.
|
||||
Aussage: Das System soll Kundeninteraktionen lückenlos dokumentieren und Marketing-/
|
||||
Vertriebsvorgänge (Kampagnen, Umfragen, Verkaufschancen) unterstützen.
|
||||
Ergebnis: Die Kundenhistorie ist je Account vollständig einsehbar.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Accounts/Activities/AccountActivitiesBL.cs, BL/Accounts/Campaigns/CampaignBL.cs (+Phase/Action), BL/Accounts/Survey/SurveyProcessBL.cs, BL/Sales/Customers/CrmProjects/CrmProjectBL.cs - Begründung: implementierte CRM-Funktionen.
|
||||
- [PRIMÄR] BL/Sales/Support/HelpdeskCloseBL.cs:151 (CreateActivityForTicketClosed) - Begründung: automatische Aktivitätenerzeugung ist durchgesetzt.
|
||||
Prüfidee: Der Abschluss eines Tickets erzeugt eine Aktivität in der Kundenhistorie.
|
||||
Tracelinks: SyRS-038, SyRS-039, SyRS-040, SyRS-041, SyRS-042
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Vertriebssteuerung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-21
|
||||
Titel: Integrierte Kommunikation (E-Mail, Kalender, Telefonie, Outlook)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Alle Benutzer
|
||||
Vorbedingung: Mail-/Telefonie-Konfiguration vorhanden.
|
||||
Fakt: Mails werden über SMTP oder Microsoft Graph versendet, mit Vorlagen und
|
||||
Variablenersetzung; Exchange-Synchronisation (EWS), MailScanner-Postfachverarbeitung,
|
||||
TAPI-Anruferkennung und ein Outlook-Add-In existieren.
|
||||
Aussage: Das System soll die Kundenkommunikation (E-Mail, Termine, Telefonate) direkt aus dem
|
||||
ERP führen und eingehende Kommunikation den Kunden/Tickets zuordnen.
|
||||
Ergebnis: Kommunikationsvorgänge sind am Kunden/Ticket dokumentiert.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Mail/Protocols/ (SMTPMail.cs, GraphMail.cs), BL/Mail/Templates/MailTemplateBL.cs, BL/Tapi/PhoneCallBL.cs (SearchContactPersonByPhoneNumberV2), BL/MailScanner/MailScannerBL.cs - Begründung: Kommunikationswege implementiert.
|
||||
- [SEKUNDÄR] src/nexus/CentronNexus.OutlookAddIn/ - Begründung: Outlook-Integration vorhanden.
|
||||
Prüfidee: Ein eingehender Anruf zeigt den zugehörigen Ansprechpartner; eine per MailScanner empfangene Mail erzeugt/aktualisiert ein Ticket.
|
||||
Tracelinks: SyRS-095, SyRS-096, SyRS-097, SyRS-098, SyRS-099, SyRS-101
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Effizienz im Tagesgeschäft.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-22
|
||||
Titel: Auswertungen, Statistiken und Belegreports
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Geschäftsleitung / Controlling
|
||||
Vorbedingung: Bewegungsdaten vorhanden.
|
||||
Fakt: Es existieren Umsatz-, Auftrags-, Rechnungs-, Vertrags-, Ticket- und
|
||||
Mitarbeiterauslastungs-Statistiken sowie eine ReportEngine mit Vorlagen und
|
||||
PDF-Erzeugung für Belegdrucke.
|
||||
Aussage: Das System soll betriebswirtschaftliche Auswertungen und druckfähige Belegdokumente
|
||||
aus den operativen Daten erzeugen.
|
||||
Ergebnis: Kennzahlen und Belegdrucke stehen ohne Datenexport zur Verfügung.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Statistics/ (RevenueStatisticBL.cs, SaleStatisticBL.cs, InvoiceStatisticBL.cs, EmployeeUtilizationBL.cs u. a.), BL/ReportEngine/ (ReportDataBL.cs, PdfExport) - Begründung: Auswertungs- und Reportlogik implementiert.
|
||||
Prüfidee: Die Umsatzstatistik eines Jahres entspricht der Summe der fakturierten Rechnungen dieses Jahres.
|
||||
Tracelinks: SyRS-116, SyRS-117
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Steuerungsinformation.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-23
|
||||
Titel: Datenschutz-Compliance (DSGVO)
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Datenschutzbeauftragter / Administrator
|
||||
Vorbedingung: DSGVO-Modul lizenziert; Benutzer hat DSGVO-Rechte.
|
||||
Fakt: Das DSGVO-Modul ermittelt löschbare Altdaten (Kunden ohne Aktivität, Altbelege,
|
||||
CRM-Einträge) und setzt das Löschrecht für Kontakte um; Zugriff ist rechtegebunden.
|
||||
Aussage: Das System soll personenbezogene Altdaten identifizieren und auf Anforderung
|
||||
löschen können (Recht auf Löschung).
|
||||
Ergebnis: Löschläufe entfernen die ausgewählten personenbezogenen Daten nachvollziehbar.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Administration/DataSecurity/DataSecurityBL.cs:34-70, 377, 787 (Rechteprüfung ACCESS_CLEANUP_DATABASE, DsgvoDeleteRightGetContacts/DeleteContacts) - Begründung: durchgesetzte DSGVO-Funktionen.
|
||||
Prüfidee: Ein Benutzer ohne DSGVO-Recht erhält "Insufficient rights!"; mit Recht liefert die Statistik löschbare Kontakte.
|
||||
Tracelinks: SyRS-086, SwRS-052
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - gesetzliche Pflicht.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-24
|
||||
Titel: Revisionssichere Belegführung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung / Wirtschaftsprüfer
|
||||
Vorbedingung: Belege werden verändert oder storniert.
|
||||
Fakt: Jede Belegänderung erzeugt einen vollständigen Versionsstand in *Versions-Tabellen;
|
||||
Rechnungen können festgeschrieben werden (IsFixed) und sind dann unveränderlich;
|
||||
Stornos sind nur unter dokumentierten Bedingungen möglich; Beleglogs protokollieren
|
||||
Aktionen.
|
||||
Aussage: Das System soll Belegänderungen versionieren, Rechnungen festschreibbar machen und
|
||||
alle abrechnungsrelevanten Aktionen protokollieren.
|
||||
Ergebnis: Jeder frühere Belegstand ist rekonstruierbar; Festschreibung verhindert nachträgliche Änderung.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:86-141 (FixInvoice: UPDATE RechKopf SET IsFixed=1 + Logeintrag "festgeschrieben") - Begründung: Festschreibung ist durchgesetzt.
|
||||
- [PRIMÄR] ebd.:273-291 (CheckIfInvoiceIsFixed: "Die Rechnung ist festgeschrieben. Änderungen nicht möglich.") - Begründung: Änderungssperre.
|
||||
- [KONTEXT] docs/reference/receipts/receipts-backend-architecture.md (Version Tables 1:1) - Begründung: Versionierungskonzept.
|
||||
Prüfidee: Nach Festschreibung einer Rechnung wird jeder Änderungsversuch abgewiesen; die Versionstabellen enthalten den Stand vor jeder Änderung.
|
||||
Tracelinks: SyRS-006, SyRS-022, SwRS-002, SwRS-016, SwRS-017
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - GoBD-relevante Anforderung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-25
|
||||
Titel: Produkt- und Preisdaten von Drittanbietern
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Einkauf / Vertrieb
|
||||
Vorbedingung: API-Zugänge sind konfiguriert.
|
||||
Fakt: Es existieren Clients für Icecat (Produktbeschreibungen/Bilder), ITscope
|
||||
(Produkte/Preise/Bestellungen), COP und EGIS; die Artikelsuche bindet externe
|
||||
Artikelquellen ein.
|
||||
Aussage: Das System soll Artikelstammdaten und Tagespreise aus Drittquellen beziehen, um
|
||||
Angebote ohne manuelle Artikelanlage erstellen zu können.
|
||||
Ergebnis: Externe Artikel sind mit aktuellen Preisen direkt in Belege übernehmbar.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Sales/Receipts/ArticleSearch/ArticleSearchBL.cs:1107-1126 (ExecuteExternalArticleSearchAsync über ExternalArticleSearchProvider) - Begründung: Einbindung externer Quellen in die Belegartikelsuche.
|
||||
- [SEKUNDÄR] src/apis/Centron.APIs.IcecatDataAccess/IcecatApi.cs, src/apis/Centron.APIs.ITscopeDataAccess/ITscopeApi.cs - Begründung: API-Clients vorhanden.
|
||||
Prüfidee: Die Artikelsuche in einem Auftrag findet einen nur bei ITscope vorhandenen Artikel und übernimmt ihn mit Preis in die Position.
|
||||
Tracelinks: SyRS-107, SyRS-108, SyRS-109, SyRS-110, SyRS-017
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Sortimentsbreite ohne Stammdatenpflege.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-26
|
||||
Titel: Versandabwicklung mit Paketdiensten
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Lagermitarbeiter
|
||||
Vorbedingung: Lieferschein ist kommissioniert.
|
||||
Fakt: API-Clients für GLS und Shipcloud (Labels, Tracking) existieren; Rechnungen tragen
|
||||
TrackingNumber/TrackingNumberURL.
|
||||
Aussage: Das System soll Versandaufträge an Paketdienste übergeben und Sendungsnummern am
|
||||
Beleg speichern.
|
||||
Ergebnis: Pakete sind ohne Medienbruch etikettiert; Tracking ist am Beleg abrufbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/apis/Centron.Api.Gls/CentronGlsLogic.cs, src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs - Begründung: Versand-API-Clients implementiert.
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/Invoices/ReceiptInvoice.cs:101-102 (TrackingNumber, TrackingNumberURL) - Begründung: Tracking am Beleg.
|
||||
Prüfidee: Für einen Lieferschein wird ein GLS-Label erzeugt und die Sendungsnummer am Beleg gespeichert.
|
||||
Tracelinks: SyRS-069, SyRS-070
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Standard-Logistikprozess.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-27
|
||||
Titel: Produktion/Konfektionierung eigener Artikel
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Produktion / Lager
|
||||
Vorbedingung: Stücklistenartikel existieren.
|
||||
Fakt: ProductionOrderBL verwaltet Fertigungsaufträge mit Positionen und Status
|
||||
(ProductionOrderItemState); ArticleProductionBL produziert Artikel aus Teilelisten;
|
||||
eine Web-Sicht (Nexus ProductionOrderManagement) existiert.
|
||||
Aussage: Das System soll Fertigungsaufträge für zusammengesetzte Artikel (z. B. PC-Konfigurationen)
|
||||
führen und deren Fertigstellung bestandwirksam buchen.
|
||||
Ergebnis: Komponenten werden ausgebucht, das Erzeugnis eingebucht; der Auftragsstatus ist verfolgbar.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Production/ProductionOrderBL.cs (SaveProductionOrder, GetProductionOrdersByFilter), BL/Warehousing/ArticleProduction/ArticleProductionBL.cs - Begründung: Fertigungslogik implementiert.
|
||||
Prüfidee: Das Abschließen eines Fertigungsauftrags reduziert die Komponentenbestände und erhöht den Bestand des Erzeugnisses.
|
||||
Tracelinks: SyRS-068, SyRS-124
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Konfektionierung gehört zum Systemhausgeschäft.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-28
|
||||
Titel: Projektgeschäft mit Belegzuordnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Projektleiter
|
||||
Vorbedingung: Projekt ist angelegt.
|
||||
Fakt: Projekte existieren als eigene Objekte; Belege tragen ProjectNumber; Ticketprojekte
|
||||
bündeln Tickets mit Abhängigkeiten.
|
||||
Aussage: Das System soll Projekte führen und Belege sowie Tickets Projekten zuordnen, damit
|
||||
projektbezogene Auswertungen möglich sind.
|
||||
Ergebnis: Alle Belege/Tickets eines Projekts sind über die Projektnummer auffindbar.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Projects/ProjectBL.cs, BL/TicketProjects/TicketProjectBL.cs (Dependencies), src/backend/Centron.Entities/.../ReceiptInvoice.cs:34 (ProjectNumber) - Begründung: Projektbezug implementiert.
|
||||
Prüfidee: Ein Auftrag mit Projektnummer erscheint in der Belegliste des Projekts.
|
||||
Tracelinks: SyRS-014, SyRS-053
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Projektgeschäft der Systemhäuser.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-29
|
||||
Titel: Kassenführung für Bargeschäfte
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Verkauf/Theke
|
||||
Vorbedingung: Kassenbuch ist eingerichtet.
|
||||
Fakt: Barrechnungen (IsCashAsset) sind vom Storno ausgenommen; Kassenbuchbuchungen werden
|
||||
aus Belegen erzeugt und gelöscht.
|
||||
Aussage: Das System soll Barverkäufe über ein Kassenbuch mit belegbezogenen Buchungen abbilden.
|
||||
Ergebnis: Kassenbestand und Belege stimmen überein; Barbelege sind gegen Storno geschützt.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/Sales/CashBooks/CashBookBookingBL.cs (UpdateCashBookBookingFromAsset, DeleteCashBookBookingFromAsset) - Begründung: Kassenbuchbuchungen implementiert.
|
||||
- [PRIMÄR] BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:160-161 (Storno-Verbot für Barrechnung) - Begründung: durchgesetzte Kassenregel.
|
||||
Prüfidee: Eine Barrechnung erzeugt eine Kassenbuchbuchung; ihr Storno wird mit Hinweis auf die Barrechnung abgewiesen.
|
||||
Tracelinks: SyRS-018, SwRS-016
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Ladengeschäft.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-30
|
||||
Titel: Mitarbeiterverwaltung mit Auslastungssicht
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Personal / Serviceleitung
|
||||
Vorbedingung: Mitarbeiter sind erfasst.
|
||||
Fakt: Mitarbeiterstamm mit Abteilungen, Skills, Urlaub, RFID-Token und Teams existiert;
|
||||
Auslastung anderer Mitarbeiter ist rechtegebunden einsehbar; Ein-/Austrittsdatum
|
||||
deaktiviert Konten.
|
||||
Aussage: Das System soll Mitarbeiter mit Organisationszuordnung und Qualifikationen verwalten
|
||||
und deren Auslastung berechtigten Rollen anzeigen.
|
||||
Ergebnis: Einsatzplanung kann auf aktuelle Auslastungs- und Skilldaten zugreifen.
|
||||
Belege:
|
||||
- [PRIMÄR] BL/EmployeeArea/ (EmployeeBL.cs, EmployeeDepartmentBL.cs, EmployeeSkillsBL.cs, TeamManagementBL.cs), BL/Statistics/Administration/Employees/EmployeeUtilizationBL.cs - Begründung: implementierte Personalfunktionen.
|
||||
- [PRIMÄR] BL/Administration/Logins/Auth/Authenticator.cs:206-216 (IsActiveEmployeeCompact: Deaktivierung über Ein-/Austrittstermin) - Begründung: durchgesetzte Kopplung Mitarbeiterstatus→Login.
|
||||
- [KONTEXT] CentronRights.md Abschnitt Mitarbeiterauslastung - Begründung: fachliche Rechtebeschreibung.
|
||||
Prüfidee: Ein ausgetretener Mitarbeiter (Austrittstermin überschritten) kann sich nicht mehr anmelden.
|
||||
Tracelinks: SyRS-084, SyRS-079
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Basisstammdaten.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-31
|
||||
Titel: Zuverlässiger Systembetrieb mit automatischer Datenpflege
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: Administrator / Betrieb
|
||||
Vorbedingung: Webservice läuft.
|
||||
Fakt: Ein stündlicher DataQualityService bereinigt/repariert Daten; abgelaufene
|
||||
Sitzungstickets werden gelöscht; nummerierte Migrationsskripte aktualisieren das
|
||||
Schema versionsgebunden.
|
||||
Aussage: Das System soll wiederkehrende Wartungs- und Konsistenzaufgaben automatisch im
|
||||
Hintergrund ausführen und Schemaänderungen versioniert einspielen.
|
||||
Ergebnis: Datenbestand und Schema bleiben ohne manuelle Eingriffe konsistent.
|
||||
Belege:
|
||||
- [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/DataQualityService.cs - Begründung: Hintergrunddienst implementiert.
|
||||
- [PRIMÄR] BL/Administration/Scripts/ScriptMethods/Scripts/ (ScriptMethod<Nr>.cs) - Begründung: versionierte Migrationen.
|
||||
- [KONTEXT] docs/Background Service/DataQualityService.md, docs/guides/database/create-scripts.md - Begründung: dokumentierte Betriebskonzepte.
|
||||
Prüfidee: Nach einem Update führt der Dienst ausstehende Skriptnummern genau einmal aus; der DataQualityService läuft stündlich.
|
||||
Tracelinks: SyRS-087, SyRS-088, SwRS-053, SwRS-057
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Betriebsstabilität.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-32
|
||||
Titel: Deutschsprachiges System mit englischer Zweitsprache
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Benutzbarkeit (Usability)
|
||||
Akteur: Alle Benutzer
|
||||
Vorbedingung: keine
|
||||
Fakt: Alle Benutzertexte liegen deutsch in Basis-Resx (2.812 Einträge allein in
|
||||
Centron.WPF.UI LocalizedStrings.resx) mit englischen Übersetzungsdateien
|
||||
(LocalizedStrings.en.resx); die Doku schreibt Deutsch als Erstsprache vor.
|
||||
Aussage: Das System soll alle Benutzertexte deutsch als Erstsprache und englisch als
|
||||
Zweitsprache bereitstellen; Fachbegriffe folgen der deutschen Branchenterminologie.
|
||||
Ergebnis: Benutzer arbeiten vollständig in ihrer Sprache; Umschaltung auf Englisch ist möglich.
|
||||
Belege:
|
||||
- [PRIMÄR] src/centron/Centron.WPF.UI/Resources/LocalizedStrings.resx (2.812 data-Einträge) und LocalizedStrings.en.resx - Begründung: Sprachressourcen vorhanden.
|
||||
- [KONTEXT] docs/getting-started/general-structure.md (German-First Language Policy) - Begründung: dokumentierte Sprachpolitik.
|
||||
Prüfidee: Alle in der UI sichtbaren Meldungen erscheinen in der eingestellten Sprache; fehlende EN-Texte fallen auf DE zurück.
|
||||
Tracelinks: SyRS-156, SwRS-058
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Zielmarkt DACH; Mehrsprachigkeit im Web-Zielsystem von Beginn an einplanen.
|
||||
Status: belegt
|
||||
```
|
||||
+1784
File diff suppressed because it is too large
Load Diff
+3708
File diff suppressed because it is too large
Load Diff
+199
@@ -0,0 +1,199 @@
|
||||
# Traceability
|
||||
|
||||
Konsolidierte Traceability-Tabelle über die drei Ebenen. Eine Zeile je SyRS-Anforderung:
|
||||
Spalte 1 nennt die StRS-Elternanforderung(en) (Backward-Trace), Spalte 3 die zugeordneten
|
||||
SwRS-Kindanforderungen (Forward-Trace), Spalte 4 den zentralen Artefaktbeleg (Kurzform;
|
||||
vollständige Belege in den Spezifikationen). `BL/` = `src/backend/Centron.BL/`.
|
||||
|
||||
Alle 32 StRS-Anforderungen sind über mindestens eine SyRS-Zeile abgedeckt; alle 71
|
||||
SwRS-Anforderungen erscheinen in mindestens einer Zeile.
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---|---|---|---|
|
||||
| StRS-02 | SyRS-001 | SwRS-004 | Entities/Sales/Receipts/Offers/ReceiptOffer.cs; AngKopf/AngPos |
|
||||
| StRS-02 | SyRS-002 | – | AutomaticFacturaBL.cs:114 (GetOrdersForAutomatedBilling) |
|
||||
| StRS-02 | SyRS-003 | – | AutomaticFacturaBL.cs:102 (State==1) |
|
||||
| StRS-02, StRS-24 | SyRS-004 | SwRS-013 | Entities/.../ReceiptInvoice.cs:38-108 |
|
||||
| StRS-24, StRS-29 | SyRS-005 | SwRS-016, SwRS-004 | BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:143-206 |
|
||||
| StRS-24 | SyRS-006 | SwRS-017 | ReceiptInvoiceBL.cs:86-141 (FixInvoice) |
|
||||
| StRS-02, StRS-10 | SyRS-007 | – | DunningBL.cs:99-108 (CreditVouchers) |
|
||||
| StRS-02, StRS-07 | SyRS-008 | SwRS-045 | BarcodeState.cs:24 (AssignedToPickupList) |
|
||||
| StRS-03 | SyRS-009 | SwRS-023 | Entities/.../ReceiptContract.cs |
|
||||
| StRS-03 | SyRS-010 | SwRS-019, SwRS-020, SwRS-021, SwRS-022, SwRS-070, SwRS-071 | AutomaticFacturaBL.Contracts.cs:1596-1627 |
|
||||
| StRS-04 | SyRS-011 | SwRS-024 | AutomaticFacturaBL.Contracts.cs:1248 (UpdClickCounterHistory) |
|
||||
| StRS-05 | SyRS-012 | SwRS-063 | TimerBillingBL.cs:233-383 |
|
||||
| StRS-02 | SyRS-013 | SwRS-018 | DownPaymentBL.cs:82/198 |
|
||||
| StRS-28 | SyRS-014 | – | BL/Projects/ProjectBL.cs; ReceiptInvoice.ProjectNumber |
|
||||
| StRS-02, StRS-15 | SyRS-015 | – | LeasingAndService/; ModuleRegistration.cs:475 |
|
||||
| StRS-25 | SyRS-016 | – | BL/Warehousing/ActionPriceBL.cs |
|
||||
| StRS-02, StRS-25 | SyRS-017 | SwRS-007, SwRS-008, SwRS-009, SwRS-010, SwRS-013, SwRS-014 | ArticleSearchBL.cs:1080-1126 |
|
||||
| StRS-29 | SyRS-018 | – | CashBookBookingBL.cs |
|
||||
| StRS-17, StRS-25 | SyRS-019 | SwRS-008, SwRS-043 | ReceiptItemPriceBL.cs:232-257; ArticleSearchWebServiceBL.cs:71 |
|
||||
| StRS-19, StRS-04 | SyRS-020 | – | Entities/.../MasterDataList.cs |
|
||||
| StRS-02 | SyRS-021 | SwRS-012 | ReceiptPriceHelper.cs:37-41 (0.05-Rundung) |
|
||||
| StRS-24 | SyRS-022 | SwRS-002, SwRS-003 | ReceiptInvoiceBL.cs:174; *KopfVersions-Tabellen |
|
||||
| StRS-16 | SyRS-023 | SwRS-025, SwRS-051 | NumberGroupBL.cs:62-134 |
|
||||
| StRS-03, StRS-21, StRS-22 | SyRS-024 | – | AutomaticFacturaBL.Contracts.cs:263-443 (Mailvorlagen/Empfänger) |
|
||||
| StRS-01, StRS-02 | SyRS-025 | SwRS-015 | ReceiptBL.cs:8636-8705 (Kreditlimit) |
|
||||
| StRS-02 | SyRS-026 | – | ReceiptBL.cs:2462 (ValidateReceiptForwarding) |
|
||||
| StRS-02 | SyRS-027 | SwRS-005, SwRS-065 | ReceiptBL.cs:4808 (ConcurrencyControlGuid) |
|
||||
| StRS-13, StRS-16 | SyRS-028 | SwRS-066 | ReceiptBL.cs:10251-10311 (Branch-Checks) |
|
||||
| StRS-08 | SyRS-029 | – | SupplierOrderBL.cs; BL/EDI/AlsoOrderBL.cs |
|
||||
| StRS-08, StRS-12 | SyRS-030 | SwRS-062 | SupplierInvoicesBL.cs; PdfScanner.cs |
|
||||
| StRS-08, StRS-07 | SyRS-031 | – | SupplierDeliveryListBL.cs; ZUGFeRD_BL.cs:107 |
|
||||
| StRS-08 | SyRS-032 | – | SupplierCreditVoucherSpecificLogic.cs |
|
||||
| StRS-08, StRS-24 | SyRS-033 | – | SupplierReceiptDocumentBL.cs |
|
||||
| StRS-08, StRS-07 | SyRS-034 | – | OrderSuggestionListBL.cs |
|
||||
| StRS-01, StRS-08 | SyRS-035 | SwRS-051 | SSMS_DB_SCHEMA.sql:3854 (Unique Lieferantennummer) |
|
||||
| StRS-01, StRS-13 | SyRS-036 | SwRS-051 | AccountBL.cs:1305-1366 (Rechteprüfungen) |
|
||||
| StRS-01 | SyRS-037 | – | ReceiptInvoiceBL.cs:293 (AlternateInvoiceReceiver) |
|
||||
| StRS-20 | SyRS-038 | – | AccountActivitiesBL.cs; HelpdeskCloseBL.cs:151 |
|
||||
| StRS-20 | SyRS-039 | – | BL/Accounts/Campaigns/ |
|
||||
| StRS-20, StRS-21 | SyRS-040 | – | BL/Sales/Marketing/; BL/Mailings/ |
|
||||
| StRS-20, StRS-05 | SyRS-041 | – | HelpdeskCloseBL.cs:168-198 (AddSurvey) |
|
||||
| StRS-20 | SyRS-042 | – | CrmProjectBL.cs |
|
||||
| StRS-05 | SyRS-043 | – | BL/Accounts/HotlineArea/ |
|
||||
| StRS-20 | SyRS-044 | – | BL/Accounts/AccountContracts/ |
|
||||
| StRS-05 | SyRS-045 | SwRS-047 | HelpdeskBL.cs:298-307, 515-519 |
|
||||
| StRS-05 | SyRS-046 | SwRS-047 | HelpdeskBL.cs:658-702 (Pflichtfelder) |
|
||||
| StRS-05 | SyRS-047 | SwRS-048 | HelpdeskCloseBL.cs:120-157 |
|
||||
| StRS-06 | SyRS-048 | SwRS-049 | EscalationBL.cs:223-332 |
|
||||
| StRS-05 | SyRS-049 | – | HelpdeskTimerBL.cs; CentronRights.md Abschn. 7-9 |
|
||||
| StRS-05 | SyRS-050 | – | CentronChecklistBL.cs |
|
||||
| StRS-05 | SyRS-051 | – | HelpdeskPatternBL.cs; automatic-helpdesk-creation-templates.md |
|
||||
| StRS-05 | SyRS-052 | – | BL/TaskManager/ |
|
||||
| StRS-28, StRS-05 | SyRS-053 | – | TicketProjectBL.cs (Dependencies) |
|
||||
| StRS-05, StRS-07 | SyRS-054 | SwRS-050 | SSMS_DB_SCHEMA.sql:4176 (Unique RMA) |
|
||||
| StRS-05 | SyRS-055 [H] | – | ExternalHelpdeskConfigurationBL.cs (nur Konfiguration) |
|
||||
| StRS-05, StRS-21 | SyRS-056 | – | AppointmentRequestBL.cs |
|
||||
| StRS-05 | SyRS-057 | – | ToDoBL.cs; HelpdeskCloseBL.cs:134 |
|
||||
| StRS-13, StRS-05 | SyRS-058 | SwRS-038 | UserRightsConst.cs (SHOW_HELPDESK_ONLY_OWN…) |
|
||||
| StRS-19 | SyRS-059 | – | AccountDeviceBL.cs; Entities/Devices/AccountDevice.cs |
|
||||
| StRS-19 | SyRS-060 | – | BL/DocuBoard/; AssetManagement*-Tabellen |
|
||||
| StRS-04, StRS-19 | SyRS-061 | – | RmmConnectionSettingsBL.cs; RiverbirdImportValues |
|
||||
| StRS-04 | SyRS-062 | SwRS-064 | AutomaticFacturaBL.cs:129-147 (MSP→Vertragsposition) |
|
||||
| StRS-07, StRS-25 | SyRS-063 | – | ArticleBL.cs; ArticleImportBL.cs |
|
||||
| StRS-07 | SyRS-064 | SwRS-011, SwRS-046, SwRS-010 | ArticleStockBL.cs:47-149 |
|
||||
| StRS-07 | SyRS-065 | SwRS-069 | InventoryNewBL.cs:80-330 |
|
||||
| StRS-07, StRS-02 | SyRS-066 | – | CommissioningBL.cs; PartialCommissionOrderBL.cs |
|
||||
| StRS-07 | SyRS-067 | SwRS-045, SwRS-046 | BarcodeState.cs; BarcodeHistoryBL.cs |
|
||||
| StRS-27 | SyRS-068 | – | ProductionOrderBL.cs; ProductionOrderItemState.cs |
|
||||
| StRS-26 | SyRS-069 | – | Centron.Api.Gls/CentronGlsLogic.cs |
|
||||
| StRS-26 | SyRS-070 | – | Centron.Api.Shipcloud/CentronShipcloudLogic.cs |
|
||||
| StRS-09, StRS-13 | SyRS-071 | SwRS-031, SwRS-027 | PaymentsBL.cs:38-78 |
|
||||
| StRS-09 | SyRS-072 | SwRS-028, SwRS-070 | OnlineBankingAccountTransactionsBL.cs:524-643 |
|
||||
| StRS-09 | SyRS-073 | SwRS-026, SwRS-027 | PaymentTransactionBL.cs:132-345 |
|
||||
| StRS-10 | SyRS-074 | SwRS-030 | DunningBL.cs:58-113; DunningLevel.cs |
|
||||
| StRS-10, StRS-11 | SyRS-075 | – | OposRunBL.cs; OposImports-Settings |
|
||||
| StRS-11 | SyRS-076 | SwRS-029 | BookKeepingExportDatevAscii.cs:991; ReceiptInvoiceBL.cs:167 |
|
||||
| StRS-09 | SyRS-077 | SwRS-026 | BankAccountBL.cs; PaymentTransactionBL.cs:347 |
|
||||
| StRS-14 | SyRS-078 | SwRS-032, SwRS-034, SwRS-036, SwRS-041, SwRS-068 | CentronRestService.cs:363-397; TicketBL.cs:26 |
|
||||
| StRS-14, StRS-30 | SyRS-079 | SwRS-033 | Authenticator.cs:157-217 |
|
||||
| StRS-13 | SyRS-080 | SwRS-038, SwRS-036 | AppRightsBL.cs:95-111 (Sichtrus/Sichmemb) |
|
||||
| StRS-14 | SyRS-081 | SwRS-037 | TwoFactorAuthBL.cs:33-120 |
|
||||
| StRS-15 | SyRS-082 | SwRS-035 | LicenseManager.cs:258-302 |
|
||||
| StRS-16 | SyRS-083 | – | MandatorBL.cs; BranchBL.cs; NumberGroupBL.cs:136 |
|
||||
| StRS-30 | SyRS-084 | – | BL/EmployeeArea/ |
|
||||
| StRS-31 | SyRS-085 | SwRS-054 | ApplicationSettingID.cs (~500 IDs) |
|
||||
| StRS-23 | SyRS-086 | SwRS-052 | DataSecurityBL.cs:34-70, 377, 787 |
|
||||
| StRS-31 | SyRS-087 | SwRS-053 | ScriptMethods/Scripts/; create-scripts.md |
|
||||
| StRS-31 | SyRS-088 | SwRS-057 | DataQualityService.cs |
|
||||
| StRS-31 | SyRS-089 [H] | – | TelemetryBL.cs; ProfilerBL.cs (Zweck unbelegt) |
|
||||
| StRS-14 | SyRS-090 | SwRS-040 | AccessTokenBL.cs:125-194, 457-488 |
|
||||
| StRS-13 | SyRS-091 | – | PasswordManagementBL.cs:81 (GetDecryptedPassword) |
|
||||
| StRS-01 | SyRS-092 | – | CustomTableBL.cs |
|
||||
| StRS-01 | SyRS-093 | – | MassUpdateBL.cs |
|
||||
| StRS-32 | SyRS-094 | – | UiProfileBL.cs |
|
||||
| StRS-21 | SyRS-095 | SwRS-059, SwRS-060 | CentronMailFactory.cs; DeveloperSecurity.cs:30 |
|
||||
| StRS-21 | SyRS-096 | – | EwsHelper/ (EWSConnection, EwsCalendarAccess) |
|
||||
| StRS-21, StRS-05 | SyRS-097 | – | MailScannerBL.cs |
|
||||
| StRS-21 | SyRS-098 | – | PhoneCallBL.cs (SearchContactPersonByPhoneNumberV2) |
|
||||
| StRS-21, StRS-13 | SyRS-099 | – | CalendarBL.cs; CentronRights.md Kalender |
|
||||
| StRS-21 | SyRS-100 | – | ChatBL.cs (CreateChat mit objectKind) |
|
||||
| StRS-21 | SyRS-101 | – | CentronNexus.OutlookAddIn/ (CustomerTab u. a.) |
|
||||
| StRS-21, StRS-17 | SyRS-102 | – | NexusNotificationsBL.cs; Program.cs:349 (SignalR) |
|
||||
| StRS-08 | SyRS-103 | SwRS-062 | SupplierEdiBL.cs (+Partials); EDIDispatcherBL.cs |
|
||||
| StRS-12 | SyRS-104 | SwRS-061 | ReceiptWebServiceBL.cs:2151-2185 |
|
||||
| StRS-12 | SyRS-105 | – | EbInterfaceLogic.cs |
|
||||
| StRS-04 | SyRS-106 [H] | – | DocuFormRestApiClient.cs (Konsument unbelegt) |
|
||||
| StRS-25 | SyRS-107 | – | IcecatApi.cs |
|
||||
| StRS-25 | SyRS-108 | – | ITscopeApi.cs; ArticleSearchBL.cs:1107 |
|
||||
| StRS-25 | SyRS-109 [H] | – | CopApi.cs (Aufrufer unbelegt) |
|
||||
| StRS-08, StRS-25 | SyRS-110 | – | EgisWarenkorbBL.cs; EgisApi.cs |
|
||||
| StRS-25 | SyRS-111 [H] | – | TelekomDiveBL.cs (Inhalt unbelegt) |
|
||||
| StRS-05 | SyRS-112 [H] | – | TanssBL.cs (Nutzungsart unbelegt) |
|
||||
| StRS-11 | SyRS-113 | – | GfkExportBL.cs |
|
||||
| StRS-25 | SyRS-114 | – | HPQuoteImportBL.cs |
|
||||
| StRS-05, StRS-21 | SyRS-115 | – | DocBeeTicketConnectorBL.cs; CTimeConnectorBL.cs |
|
||||
| StRS-22 | SyRS-116 | – | BL/ReportEngine/ (ReportDataBL, PdfExport) |
|
||||
| StRS-22 | SyRS-117 | SwRS-070 | BL/Statistics/ (15 BLs) |
|
||||
| StRS-01, StRS-05 | SyRS-118 | – | IndexSearchBL.cs (Lucene, GermanAnalyzer) |
|
||||
| StRS-17 | SyRS-119 | SwRS-067 | CentronNexus.Host/Program.cs:264-276, 395 |
|
||||
| StRS-05, StRS-17 | SyRS-120 | – | ServiceBoard/ (341 Dateien) |
|
||||
| StRS-17 | SyRS-121 | SwRS-043 | ArticleSearchWebServiceBL.cs:71-99 |
|
||||
| StRS-18 | SyRS-122 | SwRS-044 | WebReceiptState.cs:6-26 |
|
||||
| StRS-18, StRS-05 | SyRS-123 | – | DocumentSigning/ (IsolatedSignaturePad) |
|
||||
| StRS-27, StRS-17 | SyRS-124 | – | ProductionOrderManagement/ |
|
||||
| StRS-17 | SyRS-125 | – | SelfCareBL.cs; CustomerPortalFormsPage.razor |
|
||||
| StRS-17, StRS-13 | SyRS-126 | SwRS-039, SwRS-042, SwRS-066, SwRS-032 | WebAccountBL.cs:54-105; AppRightsBL.cs:113 |
|
||||
| StRS-14, StRS-17 | SyRS-127 | SwRS-055, SwRS-068 | CentronRestServiceParts/ (32 Teile); AuthenticateInterceptor.cs |
|
||||
| StRS-31 | SyRS-128 | – | c-entron.misc.ConnectionManager/ |
|
||||
| StRS-22 | SyRS-129 | – | BL/MyCentron/ |
|
||||
| StRS-15, StRS-05 | SyRS-130 | – | MyDayBL.cs; licensing-system.md (Count) |
|
||||
| StRS-05 | SyRS-131 | – | OpenAiApiClient.cs; TicketAiSummary/ |
|
||||
| StRS-25 | SyRS-132 [H] | – | TradePoolBL.cs (Kontext unbelegt) |
|
||||
| StRS-02 | SyRS-133 | – | VoucherManagementBL.cs |
|
||||
| StRS-02, StRS-21 | SyRS-134 | – | TextModuleBL.cs (GetInvoiceTextModule) |
|
||||
| StRS-05 | SyRS-135 | – | TagsBL.cs (AddTicketTag) |
|
||||
| StRS-21 | SyRS-136 | – | SocialMediaBL.cs |
|
||||
| StRS-32 | SyRS-137 | – | VideoPortalAssignmentBL.cs |
|
||||
| StRS-21 | SyRS-138 | – | WebLinkBL.cs (+ActionHandler) |
|
||||
| StRS-05 | SyRS-139 [H] | – | MobileBL.cs (Konsument unbelegt) |
|
||||
| StRS-20 | SyRS-140 | – | ProductMatrixBL.cs |
|
||||
| StRS-05 | SyRS-141 [H] | – | ChecklistVirtualObjectCategoryBL.cs |
|
||||
| StRS-20 | SyRS-142 | – | ExpectedEventsBL.cs |
|
||||
| StRS-25 | SyRS-143 [H] | – | CPraConnectorBL.cs |
|
||||
| StRS-05, StRS-14 | SyRS-144 | – | RiverDivoBL.cs (CreateHelpdeskRequest) |
|
||||
| StRS-02 | SyRS-145 | – | CountryBL.cs |
|
||||
| StRS-06, StRS-21 | SyRS-146 | – | HolidayDAO.cs |
|
||||
| StRS-02 | SyRS-147 | – | ReceiptInvoice.CurrencyFactorIsFixed; ReceiptBL.cs:8369 |
|
||||
| StRS-25 | SyRS-148 | – | ObjectExternalReferenceBL.cs |
|
||||
| StRS-05 | SyRS-149 [H] | – | ProcessBL.cs; WorkflowShapeBL.cs |
|
||||
| StRS-24 | SyRS-150 | – | DAO/ChangeTracking/; ChangeLog-Tabelle |
|
||||
| StRS-13, StRS-15 | SyRS-151 | SwRS-056, SwRS-055 | ModuleRegistration.cs:441-498 (83 Module) |
|
||||
| StRS-32 | SyRS-152 | – | Centron.Controls/; Centron.Core/ |
|
||||
| StRS-02 | SyRS-153 | SwRS-001, SwRS-006 | Centron.DAO/ (Mappings, Repositories) |
|
||||
| StRS-08, StRS-11 | SyRS-154 | – | Centron.Gateway/ |
|
||||
| StRS-31 | SyRS-155 | – | deployment/; docker/ |
|
||||
| StRS-32 | SyRS-156 | SwRS-058 | LocalizedStrings*.resx (2.812 Einträge) |
|
||||
|
||||
**Legende:** `[H]` = Anforderung mit Status HYPOTHESE; `–` = keine vertiefende SwRS-Anforderung.
|
||||
|
||||
## Gegenrichtung: SwRS → SyRS (Backward-Trace der Softwareebene)
|
||||
|
||||
| SwRS | → SyRS | | SwRS | → SyRS | | SwRS | → SyRS |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| 001 | 153 | | 025 | 023 | | 049 | 048 |
|
||||
| 002 | 022 | | 026 | 073, 077 | | 050 | 054 |
|
||||
| 003 | 022, 006 | | 027 | 073, 071 | | 051 | 036, 035, 023 |
|
||||
| 004 | 001, 005 | | 028 | 072 | | 052 | 086 |
|
||||
| 005 | 027 | | 029 | 076 | | 053 | 087 |
|
||||
| 006 | 153 | | 030 | 074 | | 054 | 085 |
|
||||
| 007 | 017, 009 | | 031 | 071 | | 055 | 127, 151 |
|
||||
| 008 | 019, 017 | | 032 | 078, 126 | | 056 | 151 |
|
||||
| 009 | 017 | | 033 | 079 | | 057 | 088 |
|
||||
| 010 | 017, 064 | | 034 | 078 | | 058 | 156 |
|
||||
| 011 | 064 | | 035 | 082 | | 059 | 095 |
|
||||
| 012 | 021 | | 036 | 078, 080 | | 060 | 095 |
|
||||
| 013 | 017, 004 | | 037 | 081 | | 061 | 104 |
|
||||
| 014 | 017 | | 038 | 080 | | 062 | 103, 030 |
|
||||
| 015 | 025 | | 039 | 126 | | 063 | 012 |
|
||||
| 016 | 005, 010, 011, 012 | | 040 | 090 | | 064 | 062, 010 |
|
||||
| 017 | 006 | | 041 | 078 | | 065 [H] | 027 |
|
||||
| 018 | 013 | | 042 | 126 | | 066 | 126, 028 |
|
||||
| 019 | 010 | | 043 | 121 | | 067 | 119 |
|
||||
| 020 | 010 | | 044 | 122 | | 068 | 127, 078 |
|
||||
| 021 | 010 | | 045 | 067 | | 069 | 065 |
|
||||
| 022 | 010, 011 | | 046 | 064, 067 | | 070 | 010, 072, 117 |
|
||||
| 023 | 009, 022 | | 047 | 046 | | 071 [H] | 010, 024 |
|
||||
| 024 | 011 | | 048 | 047 | | | |
|
||||
+165
@@ -0,0 +1,165 @@
|
||||
# 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-27T08:12:35.5152425+02:00
|
||||
- **Endzeit:** 2026-08-27T09:12:14.8158828+02:00
|
||||
- **Dauer gesamt:** 0:59:39 (`duration_ms` 0:59:37; API: 0:57:54)
|
||||
— **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` 41.314.054 Tokens (99.98 %), `claude-haiku-4-5-20251001` 6.965 Tokens (0.02 %)
|
||||
- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
|
||||
- **Effort:** `max` (per `--effort max` gesetzt)
|
||||
- **Laufverzeichnis-ID:** `v7.0.0-3021`
|
||||
- **Ablage:** `Iteration 3/claude-fable-5/solo/max/`
|
||||
- **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 | 352 |
|
||||
| Output-Tokens | 296.436 (davon 48.784 Thinking-Tokens) |
|
||||
| Cache-Write-Tokens | 547.351 |
|
||||
| Cache-Read-Tokens | 40.469.915 |
|
||||
| Agent-Turns | 204 |
|
||||
|
||||
### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
|
||||
| Messgröße | `claude-fable-5` | `claude-haiku-4-5-20251001` | Summe |
|
||||
|---|---:|---:|---:|
|
||||
| Input-Tokens | 352 | 6.944 | 7.296 |
|
||||
| Output-Tokens | 296.436 | 21 | 296.457 |
|
||||
| Cache-Write-Tokens | 547.351 | 0 | 547.351 |
|
||||
| Cache-Read-Tokens | 40.469.915 | 0 | 40.469.915 |
|
||||
| **Tokens gesamt** | **41.314.054** | **6.965** | **41.321.019** |
|
||||
|
||||
**Tokens gesamt: 41.321.019** — 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 | 32 | 12,4 % |
|
||||
| SyRS | 156 | 60,2 % |
|
||||
| SwRS | 71 | 27,4 % |
|
||||
| **Gesamt** | **259** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 166 | 64,1 % |
|
||||
| Sicherheit | 35 | 13,5 % |
|
||||
| Schnittstelle | 34 | 13,1 % |
|
||||
| nicht-funktional | 13 | 5,0 % |
|
||||
| Daten | 11 | 4,2 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 370 |
|
||||
| davon `PRIMÄR` | 285 (77,0 %) |
|
||||
| davon `SEKUNDÄR` | 43 (11,6 %) |
|
||||
| davon `KONTEXT` | 42 (11,4 %) |
|
||||
| Belege je Anforderung (Median) | 1 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 245 (94,6 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 244 | 94,2 % |
|
||||
| workaround | 8 | 3,1 % |
|
||||
| sonderfall | 5 | 1,9 % |
|
||||
| veraltet | 2 | 0,8 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 246 | 95,0 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 13 | 5,0 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 9 | 3,5 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 13 | 5,0 % |
|
||||
|
||||
### 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** (60 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 259 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 259 von 259 mit Tracelinks (100,0 %) |
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
|
||||
- **Session-ID:** `2db865cc-0f0d-440b-867f-bd92dfa2b20d`
|
||||
- **Permission-Denials:** 1 (1 × `PowerShell`) – **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` | 39.480 B |
|
||||
| `Glossar.md` | 8.320 B |
|
||||
| `Hypothesen.md` | 3.632 B |
|
||||
| `StRS.md` | 46.076 B |
|
||||
| `SwRS.md` | 93.705 B |
|
||||
| `SyRS.md` | 191.384 B |
|
||||
| `Traceability.md` | 13.545 B |
|
||||
|
||||
- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
|
||||
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
|
||||
|
||||
## Anmerkungen/Auffälligkeiten
|
||||
|
||||
<!-- ANMERKUNGEN -->
|
||||
+1
@@ -0,0 +1 @@
|
||||
{"is_error":false,"duration_api_ms":3474396,"num_turns":204,"stop_reason":"end_turn","session_id":"2db865cc-0f0d-440b-867f-bd92dfa2b20d","total_cost_usd":66.24930400000002,"usage":{"input_tokens":352,"cache_creation_input_tokens":547351,"cache_read_input_tokens":40469915,"output_tokens":296436,"output_tokens_details":{"thinking_tokens":48784},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":547351,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":1542,"cache_read_input_tokens":546412,"cache_creation_input_tokens":939,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":939},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6944,"outputTokens":21,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007049,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-fable-5":{"inputTokens":352,"outputTokens":296436,"cacheReadInputTokens":40469915,"cacheCreationInputTokens":547351,"webSearchRequests":0,"costUSD":66.24225500000001,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"PowerShell","tool_use_id":"toolu_0114xsshBxZ2Y6sbJ7yuMx44","tool_input":{"command":"New-Item -ItemType Directory -Force \"c:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 3\\claude-fable-5\\solo\\max\\02_Lauf_2026-08-27_081235_v7.0.0-3021\\Ergebnisse\" | Out-Null; Write-Host \"Ausgabeverzeichnis angelegt\"","description":"Create output directory"}}],"terminal_reason":"completed","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":null,"result":"Der Lauf ist abgeschlossen. Alle sieben Ergebnisdateien liegen im vorgegebenen Ausgabeverzeichnis `…\\02_Lauf_2026-08-27_081235_v7.0.0-3021\\Ergebnisse\\`.\n\n## Ergebnis im Überblick\n\n**259 Anforderungen** über drei Ebenen: **StRS 32, SyRS 156, SwRS 71**, davon **13 Hypothesen** (5,0 %). Die Codebasis wurde ausschließlich lesend analysiert.\n\n**Vorgehen gemäß Schritt 0-0c:** Vor der ersten Anforderung wurde ein **Modulinventar mit 146 Modulen** erstellt (Kennzahlen: ~14.200 C#-Dateien, 1.558 DB-Tabellen, 182 Views, 750 Benutzerrechte, 83 registrierte Client-Module). Die **Mindestabdeckung ist vollständig erfüllt**: Jedes Modul trägt mindestens eine Anforderung, kein Modul blieb unanalysiert (33 tief, 66 mittel, 47 flach).\n\n**Risikovertiefung:** Alle 81 risikorelevanten Anforderungen (35 Sicherheit/Berechtigungen, 46 Abrechnung/Fakturierung) tragen einen PRIMÄR-Beleg mit benannter durchsetzender Stelle (Datei, Klasse, Methode, Prüfung) – die einzige Ausnahme (Sammelrechnungs-Bündelung) ist regelkonform als `[HYPOTHESE]` markiert. Fachlich besonders ergiebig waren u. a.: Rechnungsstorno mit fünf Vorbedingungen, GoBD-Festschreibung (`IsFixed`), Vertragsabrechnung mit Monatsend-/Schaltjahrlogik und Pro-rata-Normalisierung, Kontingentbuchung mit Überbuchung/Zwischenrechnung, SEPA-Mandatssequenzen, DATEV EXTF 700, die fünfstufige Preisfindungshierarchie, das Sichbenu/Sichmemb/Sichtrus-Rechtemodell sowie der Sicherheitsbefund **ungesalzenes SHA1-Passworthashing** (mit TODO-Kommentar im Code belegt, als abzulösender Ist-Zustand dokumentiert).\n\n**Konsistenzcheck (skriptgestützt über die Abgabedateien):** 0 doppelte IDs, 0 Anforderungen ohne Beleg/Übernahmewürdigkeit/Prüfidee, 0 tote Tracelinks, vollständige Rückverlinkung SwRS→SyRS→StRS, `Hypothesen.md` deckungsgleich mit den 13 Inline-Markierungen. Das Konsolidierungsbeispiel aus dem Prompt wurde im Code bestätigt und erweitert: Kundengeräte existieren **dreifach** (Stammblätter/`MasterDataList`, `AccountDevice`, DocuBoard-`AssetManagement`) und sind als Konsolidierungskandidaten markiert, ebenso Inventur alt/neu, das zweigleisige Einstellungssystem und die beiden Versandwege.","ttft_ms":8870,"ttft_stream_ms":1746,"time_to_request_ms":31,"type":"result","duration_ms":3577708,"uuid":"92217355-07c0-4f36-9301-6be091bcdeb5","queued_turn_count":0}
|
||||
+5034
File diff suppressed because it is too large
Load Diff
+65
@@ -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 | 32 | 12,4 % |
|
||||
| SyRS | 156 | 60,2 % |
|
||||
| SwRS | 71 | 27,4 % |
|
||||
| **Gesamt** | **259** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 166 | 64,1 % |
|
||||
| Sicherheit | 35 | 13,5 % |
|
||||
| Schnittstelle | 34 | 13,1 % |
|
||||
| nicht-funktional | 13 | 5,0 % |
|
||||
| Daten | 11 | 4,2 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 370 |
|
||||
| davon `PRIMÄR` | 285 (77,0 %) |
|
||||
| davon `SEKUNDÄR` | 43 (11,6 %) |
|
||||
| davon `KONTEXT` | 42 (11,4 %) |
|
||||
| Belege je Anforderung (Median) | 1 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 245 (94,6 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 244 | 94,2 % |
|
||||
| workaround | 8 | 3,1 % |
|
||||
| sonderfall | 5 | 1,9 % |
|
||||
| veraltet | 2 | 0,8 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 246 | 95,0 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 13 | 5,0 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 9 | 3,5 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 13 | 5,0 % |
|
||||
|
||||
### 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** (60 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 259 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 259 von 259 mit Tracelinks (100,0 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+177
@@ -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\max\02_Lauf_2026-08-27_081235_v7.0.0-3021\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-27T09:12:14.8158828+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-27T08:12:35.5152425+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
{"is_error":true,"duration_api_ms":6921934,"num_turns":39,"stop_reason":"stop_sequence","session_id":"8d493a0f-f069-46a0-93de-8427787b311e","total_cost_usd":19.8662592,"usage":{"input_tokens":28,"cache_creation_input_tokens":110625,"cache_read_input_tokens":960495,"output_tokens":65463,"output_tokens_details":{"thinking_tokens":37220},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":110625,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":31750,"cache_read_input_tokens":106780,"cache_creation_input_tokens":3845,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":3845},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6961,"outputTokens":24,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.0070810000000000005,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":548,"outputTokens":710526,"cacheReadInputTokens":40508211,"cacheCreationInputTokens":1794097,"webSearchRequests":0,"costUSD":19.8591782,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"Bash","tool_use_id":"toolu_01JBgsXfn416qWFSQG5hziEb","tool_input":{"command":"mkdir -p \"/c/Users/CHRIST~1/AppData/Local/Temp/claude/C--DEV-MasterArbeit-QuellCode-CentronERP/8d493a0f-f069-46a0-93de-8427787b311e/scratchpad/findings\"","description":"Ensure findings directory exists"}}],"terminal_reason":"api_error","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":8,"requested":{"background":0,"foreground":8,"unset":0},"started_in_background":0,"max_depth":1,"spawned_by_subagents":0,"completed":4,"failed":4,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{"general-purpose":8}},"subtype":"success","api_error_status":429,"result":"You've hit your weekly limit · resets Aug 31, 7am (Europe/Berlin)","type":"result","duration_ms":1716122,"uuid":"4b5fe352-1035-4d7b-a25a-af4850c43257","queued_turn_count":0}
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+178
@@ -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-sonnet-5\builtin\max\02_Lauf_2026-08-27_110958_v7.0.0-7499\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-27T11:38:36.1567144+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-27T11:09:58.2717910+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
{"is_error":true,"duration_api_ms":0,"num_turns":1,"stop_reason":"stop_sequence","session_id":"af9be153-a3b0-427c-954b-615d562631fa","total_cost_usd":0,"usage":{"output_tokens_details":{"thinking_tokens":0},"input_tokens":0,"cache_creation_input_tokens":0,"cache_read_input_tokens":0,"output_tokens":0,"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":0,"ephemeral_5m_input_tokens":0},"inference_geo":"","iterations":[],"speed":"standard"},"modelUsage":{},"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 weekly limit · resets Aug 31, 7am (Europe/Berlin)","type":"result","duration_ms":457,"uuid":"10894110-3434-4adc-b7f0-6a0ee842f78a","queued_turn_count":0}
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+178
@@ -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-sonnet-5\builtin\max\02_Lauf_2026-08-27_124836_v7.0.0-cf3c\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-27T12:48:38.8520809+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-27T12:48:36.4195736+02:00
|
||||
+327
@@ -0,0 +1,327 @@
|
||||
# Analysebericht – Reverse Requirements Engineering c-entron ERP-Suite
|
||||
|
||||
Untersuchungsgegenstand: gesamte Codebasis unter `C:\DEV\MasterArbeit\QuellCode\CentronERP` (Arbeitsverzeichnis, ausschließlich lesend analysiert). Pfadangaben in diesem Bericht sind relativ zu diesem Arbeitsverzeichnis.
|
||||
|
||||
## Schritt 0 – Modulinventar
|
||||
|
||||
Das Inventar wurde durch Auswertung der Projekt- und Verzeichnisstruktur (`Centron.sln`, `src/*`) erstellt, **bevor** eine Anforderung formuliert wurde. Es ist die Bezugsgröße für die Abdeckung (siehe Abdeckungstabelle am Ende dieses Berichts) und wird ergänzt, nicht gekürzt.
|
||||
|
||||
Abgrenzung: Rein technische Querschnittsbibliotheken ohne eigenständige fachliche Funktion (u. a. `shared/Centron.Controls`, `shared/Centron.Core`, WPF-interne Ordner `Behaviors/`, `Extensions/`, `Style/`, `VisualTree/`) sind nicht als eigene Inventarzeile geführt; sie werden als technische Grundlage in den Belegen einzelner Anforderungen mitgenutzt, wo relevant. Große, fachlich heterogene Verzeichnisse (`Finances`, `Warehousing`, `Administration`, `Helpdesk`, `DataExchange`, `MyCentron`, `Statistics`, `Purchasing`) wurden auf Ebene ihrer Unterordner aufgeschlüsselt, weil diese jeweils eigenständige fachliche Funktionen abbilden; kleine, thematisch zusammengehörige Unterordner wurden zu einer Zeile zusammengefasst (z. B. mehrere Administration-„Settings“-Ordner). Vier produktdatenliefernde Fremd-APIs (COP/EGIS/ITscope/Icecat) sind wegen identischer fachlicher Funktion (externe Produktkatalog-Anreicherung) in einer Zeile zusammengefasst – siehe hierzu auch den Konsolidierungshinweis in SyRS.
|
||||
|
||||
| Nr | Bereich | Modul/Komponente | Pfad (relativ zum Arbeitsverzeichnis) | Fachliche Aufgabe |
|
||||
|----|---------|-------------------|----------------------------------------|--------------------|
|
||||
| 1 | Vertrieb/CRM | Sales – Sonderpreise/Mailing | src/centron/Centron.WPF.UI/Modules/Sales | Verwaltung kundenspezifischer Sonderpreise, Serienmail- und Produktmatrix-Funktionen für den Vertrieb |
|
||||
| 2 | Vertrieb/CRM | CRM/Adressstamm | src/centron/Centron.WPF.UI/Modules/Finances/Crm | Zentrale Kunden-, Lieferanten- und Kontaktverwaltung (Adressstamm) inkl. Aktivitäten, Verträgen, Sonderpreisen, DSGVO-Tab |
|
||||
| 3 | Vertrieb/CRM | Kampagnenmanagement | src/centron/Centron.WPF.UI/Modules/Finances/Campaigns | Planung, Durchführung und Auswertung von Marketing-/Vertriebskampagnen |
|
||||
| 4 | Vertrieb/CRM | CRM-Stammdatenlisten | src/centron/Centron.WPF.UI/Modules/Finances/MasterDataLists | Listenbasierte Massenpflege von CRM-Stammdaten |
|
||||
| 5 | Vertrieb/CRM | Vertragsverwaltung & -auswertung | src/centron/Centron.WPF.UI/Modules/Finances/Contracts, ContractEvaluation2, ContractEvaluationOld | Verwaltung von Kundenverträgen und Auswertung von Vertragskennzahlen (zwei parallele Implementierungsstände) |
|
||||
| 6 | Vertrieb/CRM | Projektverwaltung (Finanzsicht) | src/centron/Centron.WPF.UI/Modules/Finances/Projects | Kaufmännische Projektverwaltung und -abrechnung |
|
||||
| 7 | Vertrieb/CRM | Zählerstandserfassung (MPS) | src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter | Erfassung von Zählerständen verwalteter Drucksysteme als Abrechnungsgrundlage (Managed Print Services) |
|
||||
| 8 | Vertrieb/CRM | Produktlebenszyklus-Management | src/centron/Centron.WPF.UI/Modules/PLM, Modules/Finances/ProductLifecycleManagement | Verwaltung von Produktfamilien und deren Lebenszyklusphasen |
|
||||
| 9 | Vertrieb/CRM | Zahler- und Kostenstellenverwaltung | src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter | Zuordnung abweichender Zahler sowie Kostenstellen/-objekte zu Belegen |
|
||||
| 10 | Vertrieb/CRM | Projektpreisimport | src/centron/Centron.WPF.UI/Modules/ProjectPriceImport | Import und Abgleich projektspezifischer Preislisten |
|
||||
| 11 | Vertrieb/CRM | Projektmanagement (allgemein) | src/centron/Centron.WPF.UI/Modules/ProjectManagement | Allgemeine Projektverwaltungsfunktionen außerhalb der Finanzsicht |
|
||||
| 12 | Belegwesen | Belegbearbeitung Kern | src/centron/Centron.WPF.UI/Modules/Finances/Receipts | Erstellung/Bearbeitung der Belegkette Angebot–Auftrag–Lieferschein–Rechnung–Gutschrift inkl. Kalkulation, Positionserfassung, Belegvorlagen |
|
||||
| 13 | Belegwesen | Anzahlungen | src/centron/Centron.WPF.UI/Modules/Finances/Receipts/DownPayment | Verwaltung von Anzahlungsrechnungen und deren Verrechnung |
|
||||
| 14 | Belegwesen | Steuersatzänderung im Beleg | src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ChangeTaxRate | Nachträgliches Ändern des Steuersatzes auf Belegpositionen |
|
||||
| 15 | Belegwesen | Provisionsermittlung | src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Provision | Ermittlung von Verkäuferprovisionen je Beleg/Position (Korrektur: „PartialCommission" gehört fachlich zur Kommissionsware, siehe Zeile 32, nicht zur Verkäuferprovision – ursprüngliche Zuordnung war irreführend) |
|
||||
| 16 | Belegwesen | Web-Angebote | src/centron/Centron.WPF.UI/Modules/Finances/Receipts/WebOffer, GenerateWebOffer | Bereitstellung von Angeboten über einen Weblink für Kunden |
|
||||
| 17 | Belegwesen | EDI-Auftragsverbuchung | src/centron/Centron.WPF.UI/Modules/Finances/Receipts/EdiOrderbooking | Automatisierte Verbuchung elektronisch eingehender Aufträge |
|
||||
| 18 | Abrechnung/Fakturierung | Automatisierte Rechnungserstellung | src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling | Automatisiertes, periodisches Erstellen von Rechnungen aus Verträgen |
|
||||
| 19 | Abrechnung/Fakturierung | Pauschalabrechnung (Flatrate) | src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling | Abrechnung pauschaler Vertragsleistungen |
|
||||
| 20 | Abrechnung/Fakturierung | Zeit-/Leistungsabrechnung (Timer) | src/centron/Centron.WPF.UI/Modules/Finances/TimerBilling | Abrechnung erfasster Zeiterfassungen/Leistungen |
|
||||
| 21 | Abrechnung/Fakturierung | Mahnwesen | src/centron/Centron.WPF.UI/Modules/Finances/Dunning | Automatisiertes Mahnverfahren für offene Forderungen |
|
||||
| 22 | Abrechnung/Fakturierung | Offene Posten | src/centron/Centron.WPF.UI/Modules/Finances/Opos | Verwaltung offener Forderungen/Verbindlichkeiten |
|
||||
| 23 | Abrechnung/Fakturierung | Zahlungsverkehr (Payments) | src/centron/Centron.WPF.UI/Modules/Finances/Payments | Erfassung und Zuordnung von Zahlungseingängen/-ausgängen |
|
||||
| 24 | Abrechnung/Fakturierung | Kontenverwaltung (Buchhaltung) | src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement | Verwaltung von Finanzkonten und zugehörigen Buchungen |
|
||||
| 25 | Abrechnung/Fakturierung | Warenausgangszahlungen | src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments | Erfassung von Zahlungen im Warenausgangsprozess (z. B. Nachnahme) |
|
||||
| 26 | Abrechnung/Fakturierung | Kassensystem-Anbindung | src/centron/Centron.WPF.UI/Modules/Warehousing/AccountSystems | Anbindung/Abgleich von Kassen-/Kontensystemen im Lager |
|
||||
| 27 | Lager/Artikel | Artikelstammdaten | src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement | Zentrale Pflege der Artikelstammdaten (Preise, Bestände, Merkmale) |
|
||||
| 28 | Lager/Artikel | Artikelimport | src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleImport | Importieren von Artikeldaten aus externen Quellen |
|
||||
| 29 | Lager/Artikel | Mengeneinheitenverwaltung | src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleUnitManagement | Pflege von Mengeneinheiten und Umrechnungsfaktoren |
|
||||
| 30 | Lager/Artikel | Barcode-Verwaltung | src/centron/Centron.WPF.UI/Modules/Warehousing/BarcodeManagement | Erzeugung/Zuordnung von Barcodes zu Artikeln |
|
||||
| 31 | Lager/Artikel | Kommissionierung | src/centron/Centron.WPF.UI/Modules/Warehousing/Commissioning | Steuerung der Warenkommissionierung im Lager |
|
||||
| 32 | Lager/Artikel | Kommissionsware/Konsignation | src/centron/Centron.WPF.UI/Modules/Warehousing/Commissions | Verwaltung von Kommissionsaufträgen (Konsignationslager) inkl. Teilkommissionen |
|
||||
| 33 | Lager/Artikel | Inventur | src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory | Durchführung und Bewertung von Lagerinventuren |
|
||||
| 34 | Lager/Artikel | Warengruppenverwaltung | src/centron/Centron.WPF.UI/Modules/Warehousing/MaterialGroupManagement | Pflege der Warengruppenhierarchie |
|
||||
| 35 | Lager/Artikel | Artikelsuche | src/centron/Centron.WPF.UI/Modules/Warehousing/SearchArticle | Übergreifende Artikelsuche als UI-Dienst |
|
||||
| 36 | Lager/Artikel | Lieferantensuche | src/centron/Centron.WPF.UI/Modules/Warehousing/SupplierSearch | Suche/Auswahl von Lieferanten im Beschaffungskontext |
|
||||
| 37 | Lager/Artikel | Logistikeinstellungen/Versandarten | src/centron/Centron.WPF.UI/Modules/Logistic | Konfiguration von Versandarten und logistischen Einstellungen |
|
||||
| 38 | Einkauf | EDI-Bestellwesen | src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement | Elektronischer Bestelldatenaustausch mit Lieferanten |
|
||||
| 39 | Einkauf | Bestellvorschlagsliste | src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList | Ermittlung von Nachbestellbedarf |
|
||||
| 40 | Einkauf | Einkaufseinstellungen | src/centron/Centron.WPF.UI/Modules/Purchasing/PurchaseSettings, Others | Grundeinstellungen des Einkaufsprozesses |
|
||||
| 41 | Einkauf | Reisekostenabrechnung | src/centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense | Erfassung/Abrechnung von Reisekosten |
|
||||
| 42 | Produktion | Fertigungsauftragsverwaltung | src/centron/Centron.WPF.UI/Modules/Production/ProductionOrder, Settings | Anlage und Steuerung von Fertigungsaufträgen |
|
||||
| 43 | Produktion | Maschinenverwaltung | src/centron/Centron.WPF.UI/Modules/Production/MachineManagement | Stammdatenverwaltung von Produktionsmaschinen |
|
||||
| 44 | Retouren | RMA-Abwicklung | src/centron/Centron.WPF.UI/Modules/Rma | Abwicklung von Rücksendungen/Reklamationen (Return Merchandise Authorization) |
|
||||
| 45 | Helpdesk | Ticketverwaltung | src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails, TicketList, TicketProcessTemplates | Erfassung und Bearbeitung von Support-Tickets |
|
||||
| 46 | Helpdesk | Helpdesk-Dashboard | src/centron/Centron.WPF.UI/Modules/Helpdesk/Dashboard | Übersichts-/Kennzahlendarstellung für den Helpdesk |
|
||||
| 47 | Helpdesk | Wartungsverträge/erwartete Ereignisse | src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEvents, ExpectedEventsReporting | Überwachung vertraglich erwarteter Wartungsereignisse (SLA-Fristen) |
|
||||
| 48 | Helpdesk | Helpdesk-Einstellungen | src/centron/Centron.WPF.UI/Modules/Helpdesk/Settings, TaskManagement | Konfiguration von Ticketprozessen und Aufgaben |
|
||||
| 49 | Helpdesk | Helpdesk Sonstiges | src/centron/Centron.WPF.UI/Modules/Helpdesk/Events, ConnectionNumber, CentronChecklist, SendSelfCareForm | Ereignisprotokoll, Checklisten, Self-Service-Formular |
|
||||
| 50 | MyCentron | CentronInspectors | src/centron/Centron.WPF.UI/Modules/MyCentron/CentronInspectors | Pluggable Datenqualitäts-/Selbstdiagnoseprüfungen (Inspectors), die Stammdatenverstöße per SQL aufspüren und Korrekturdialoge anbieten (Korrektur ggü. Erstinventar: keine Prüfmittelverwaltung, sondern Dateninspektion) |
|
||||
| 51 | MyCentron | Persönliche Einstellungen | src/centron/Centron.WPF.UI/Modules/MyCentron/PersonalSettings | Benutzerbezogene Einstellungen |
|
||||
| 52 | MyCentron | Mein Tag (MyDay) | src/centron/Centron.WPF.UI/Modules/MyCentron/MyDay | Tagesplanansicht für Mitarbeitende |
|
||||
| 53 | MyCentron | MyCentron-Dashboard | src/centron/Centron.WPF.UI/Modules/MyCentron/Dashboard | Persönliches Übersichts-Dashboard |
|
||||
| 54 | MyCentron | Aufgabenliste (ToDo) | src/centron/Centron.WPF.UI/Modules/MyCentron/TodoList, Calendar | Persönliche Aufgaben-/Terminliste |
|
||||
| 55 | MyCentron | Telefonie-Integration | src/centron/Centron.WPF.UI/Modules/MyCentron/Telephony | Anbindung an Telefonanlage (CTI) |
|
||||
| 56 | MyCentron | Fernwartungsintegration (Supremo) | src/centron/Centron.WPF.UI/Modules/MyCentron/Supremo | Anbindung des Fernwartungstools Supremo |
|
||||
| 57 | Statistik | Verkaufsstatistik | src/centron/Centron.WPF.UI/Modules/Statistics/SaleStatistics | Auswertung von Verkaufszahlen |
|
||||
| 58 | Statistik | Management-Informationen | src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo | Kennzahlen-Dashboards für das Management |
|
||||
| 59 | Statistik | MSP-Statistiken | src/centron/Centron.WPF.UI/Modules/Statistics/MspStatistics, MspCollectors | Auswertung von Managed-Service-Provider-Kennzahlen |
|
||||
| 60 | Statistik | Mitarbeiteranalyse | src/centron/Centron.WPF.UI/Modules/Statistics/EmployeeAnalytics | Auswertung mitarbeiterbezogener Kennzahlen |
|
||||
| 61 | Statistik | Reportverwaltung | src/centron/Centron.WPF.UI/Modules/Reports/ReportManagement | Verwaltung/Ausführung hinterlegter Reports |
|
||||
| 62 | Administration | Rechteverwaltung | src/centron/Centron.WPF.UI/Modules/Administration/RightsManagement | Verwaltung von Benutzerrechten und Rollen (Risikobereich) |
|
||||
| 63 | Administration | Mitarbeiterverwaltung | src/centron/Centron.WPF.UI/Modules/Administration/EmployeeManagement | Stammdatenverwaltung der Mitarbeitenden inkl. Rechtezuordnung |
|
||||
| 64 | Administration | Mandantenverwaltung | src/centron/Centron.WPF.UI/Modules/Administration/MandatorManagement | Verwaltung mehrerer Mandanten (Multi-Tenant-Fähigkeit) |
|
||||
| 65 | Administration | DSGVO-Funktionen | src/centron/Centron.WPF.UI/Modules/Administration/DSGVO | Werkzeuge zur Umsetzung datenschutzrechtlicher Pflichten (Risikobereich) |
|
||||
| 66 | Administration | Systemeinstellungen | src/centron/Centron.WPF.UI/Modules/Administration/Settings, Customization, Cache, Profiling | Allgemeine Systemkonfiguration |
|
||||
| 67 | Administration | Verbindungs-/Schnittstelleneinstellungen | src/centron/Centron.WPF.UI/Modules/Administration/Connections, WebServiceSettings, SqlManagers, CentronConfigDb | Konfiguration von DB-/Webservice-Verbindungen |
|
||||
| 68 | Administration | Kommunikationseinstellungen | src/centron/Centron.WPF.UI/Modules/Administration/MailAndCalender, MailTemplates, PhoneSettings | Konfiguration von E-Mail-/Kalender-/Telefonanbindung |
|
||||
| 69 | Administration | Belegwesen-Konfiguration | src/centron/Centron.WPF.UI/Modules/Administration/PdfExport, PdfSigning, ReceiptConditions, TextBlockManagement, ReportServer | Konfiguration von PDF-Erzeugung/-Signatur, Textbausteinen, Reportserver |
|
||||
| 70 | Administration | Stundensätze/Zuschläge | src/centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates | Pflege von Stundenverrechnungssätzen und Zuschlägen |
|
||||
| 71 | Administration | Eskalationseinstellungen | src/centron/Centron.WPF.UI/Modules/Administration/EscalationsSettings | Konfiguration von SLA-Eskalationsregeln |
|
||||
| 72 | Administration | Länderverwaltung | src/centron/Centron.WPF.UI/Modules/Administration/CountryManagement | Pflege von Länderstammdaten |
|
||||
| 73 | Administration | Service-/Leasing-/SEPA-Verträge | src/centron/Centron.WPF.UI/Modules/Administration/ServiceAndLeasing, SepaContract | Verwaltung von Service-/Leasingverträgen und SEPA-Lastschriftmandaten (Risikobereich) |
|
||||
| 74 | Administration | Externe Werkzeuge | src/centron/Centron.WPF.UI/Modules/Administration/ExternalTools, Modules/ExternalTool | Einbindung externer Zusatzwerkzeuge |
|
||||
| 75 | Administration | WebCart-Konfiguration | src/centron/Centron.WPF.UI/Modules/Administration/WebCart | Konfiguration des Web-Shops für Kunden |
|
||||
| 76 | Administration | Sonstige Prozesseinstellungen | src/centron/Centron.WPF.UI/Modules/Administration/TaskManagmentSettings, UpdateAvailableNotificationSettings, SendDeliveryListShippingConfirmationSettings | Verschiedene Prozess-Konfigurationsschalter |
|
||||
| 77 | Administration | Log-Betrachter | src/centron/Centron.WPF.UI/Modules/Administration/LogViewer | Einsicht in Anwendungs-Logdateien |
|
||||
| 78 | Administration | Dienste-Verwaltung | src/centron/Centron.WPF.UI/Modules/Administration/Services | Verwaltung von Hintergrunddiensten |
|
||||
| 79 | OnlineBanking | Kontoumsätze | src/centron/Centron.WPF.UI/Modules/OnlineBanking/AccountTransactions | Abruf und Zuordnung von Kontoumsätzen (Risikobereich) |
|
||||
| 80 | OnlineBanking | OnlineBanking-Konfiguration | src/centron/Centron.WPF.UI/Modules/OnlineBanking/ConfigurationSettings | Konfiguration der Bankverbindungen |
|
||||
| 81 | OnlineBanking | OnlineBanking-Verbindungsdialog | src/centron/Centron.WPF.UI/Modules/OnlineBanking/ConnectionDialog | Verbindungsaufbau zu Banken (FinTS/HBCI) |
|
||||
| 82 | Querschnitt | KI-Unterstützung | src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence | KI-gestützter Chat, Angebotspositions-Editor, Textbewertung (OpenAI-Anbindung) |
|
||||
| 83 | Querschnitt | Umfragen | src/centron/Centron.WPF.UI/Modules/Survey | Erstellung/Auswertung von Kundenumfragen |
|
||||
| 84 | Querschnitt | Massenänderungen | src/centron/Centron.WPF.UI/Modules/Massenupdates | Massenhaftes Aktualisieren von Datensätzen |
|
||||
| 85 | Querschnitt | Passwortverwaltung | src/centron/Centron.WPF.UI/Modules/PasswordManager | Sichere Ablage von Zugangsdaten (Risikobereich) |
|
||||
| 86 | Querschnitt | Kalender | src/centron/Centron.WPF.UI/Modules/Calendar | Terminverwaltung |
|
||||
| 87 | Querschnitt | Qualitätsmanagement | src/centron/Centron.WPF.UI/Modules/QM | QM-Prüfprozesse |
|
||||
| 88 | Querschnitt | Telekom-DIVE-Integration (UI) | src/centron/Centron.WPF.UI/Modules/TelekomDive | Anbindung an die Telekom-DIVE-Plattform |
|
||||
| 89 | Querschnitt | Startdashboard | src/centron/Centron.WPF.UI/Modules/Dashboard | Konfigurierbares Startbildschirm-Dashboard |
|
||||
| 90 | Querschnitt | Oberflächenprofile | src/centron/Centron.WPF.UI/Modules/Gui | Verwaltung von Layout-/Oberflächenprofilen je Benutzer |
|
||||
| 91 | Querschnitt | Cross-cutting Dialoge (Global) | src/centron/Centron.WPF.UI/Modules/Global | Wiederverwendbare Dialoge (Mitarbeiterauswahl, Videoportal, Netzwerkdiagnose, Lizenzabgleich) |
|
||||
| 92 | Backend-Kern | Geschäftslogik-/Datenzugriffsschicht | src/backend/Centron.BL, Centron.DAO, Centron.Entities, Centron.Interfaces, Centron.Common | Fachliche Kernlogik, Datenbankzugriff und Entitätsmodell, von allen UI-Modulen genutzt |
|
||||
| 93 | Backend-Kern | EDI-Lieferantenanbindungen | src/backend/Centron.Gateway/EDI_Also, EDI_AlsoCH, EDI_Alltron, EDI_Herweck, EDI_Komsa, EDI_EGIS | Elektronischer Datenaustausch (Bestellung/Lieferschein/Rechnung) mit Distributoren |
|
||||
| 94 | Backend-Kern | Banking-Gateway (Backend) | src/backend/Centron.Gateway/OnlineBanking | Technische Anbindung an Bankschnittstellen (FinTS) |
|
||||
| 95 | Backend-Kern | MSP-Collector-Gateway | src/backend/Centron.Gateway/MspCollector | Sammeln von Gerätedaten bei Managed-Service-Anbietern (Octopus, Wortmann) |
|
||||
| 96 | Backend-Kern | E-Rechnungsformate | src/backend/Centron.Gateway/OpenTrans, OpenTrans1_0, ZUGFeRD21_Extended | Erzeugen/Verarbeiten strukturierter Rechnungsformate |
|
||||
| 97 | Backend-Kern | Portal-Gateway | src/backend/Centron.Gateway/Portal | Anbindung an den c-entron Portal-Webservice |
|
||||
| 98 | Webservice | Zentrale Web-API | src/webservice/Centron.WebServices.Core, Centron.Controllers, Centron.Host, Host.Console, Host.WindowsService | Bereitstellung der c-entron-Funktionalität als Webservice/REST-Schnittstelle für externe/mobile Clients |
|
||||
| 99 | Webservice | Lizenz-/Verbindungsmanager | src/webservice/c-entron.misc.ConnectionManager | Verwaltung von Lizenzen/Hardware-IDs für Webservice-Verbindungen |
|
||||
| 100 | Nexus (Web) | ServiceBoard (Web-Ticketboard) | src/nexus/CentronNexus/ServiceBoard | Web-basierte Ticket-/Kanban-Oberfläche für den technischen Support |
|
||||
| 101 | Nexus (Web) | Nexus Office/Kundenportal (WebCart) | src/nexus/CentronNexus/Office | Web-Kundenportal inkl. Bestell-/Shopfunktion (WebCart) |
|
||||
| 102 | Nexus (Web) | Web-Fertigungsauftragsverwaltung | src/nexus/CentronNexus/ProductionOrderManagement | Weboberfläche zur Fertigungsauftragssteuerung |
|
||||
| 103 | Nexus (Web) | Nexus-Verwaltung | src/nexus/CentronNexus/Management | Verwaltung von Web-Benutzerkonten, Aufgaben und Ticketmustern |
|
||||
| 104 | Nexus (Web) | Dokumentensignatur (Web) | src/nexus/CentronNexus/DocumentSigning | Elektronische Signatur von Dokumenten im Web |
|
||||
| 105 | Nexus (Web) | Outlook-Add-in | src/nexus/CentronNexus.OutlookAddIn | Integration von c-entron-Funktionen in Microsoft Outlook |
|
||||
| 106 | Externe APIs | Produktdaten-Anreicherungs-APIs | src/apis/Centron.APIs.CopDataAccess, EgisDataAccess, ITscopeDataAccess, IcecatDataAccess | Abruf von Produktstamm-/Katalogdaten bei externen Datenlieferanten |
|
||||
| 107 | Externe APIs | Bankanbindung FinAPI | src/apis/Centron.APIs.FinAPI | Kontoinformationsabruf über den Drittanbieter FinAPI (Risikobereich) |
|
||||
| 108 | Externe APIs | E-Rechnung Österreich | src/apis/Centron.Api.EbInterface | Erstellung von ebInterface-E-Rechnungen (österreichischer Standard) |
|
||||
| 109 | Externe APIs | Versanddienstleister-Schnittstellen | src/apis/Centron.Api.Gls, Centron.Api.Shipcloud | Anbindung an Paketversanddienstleister (Label-/Sendungsdaten) |
|
||||
| 110 | Datenaustausch | PDF-Formulargenerierung (docuFORM) | Centron.Api.docuFORM, src/centron/.../Modules/DataExchange/DocuForm | Dynamische PDF-Formularerzeugung aus Belegdaten |
|
||||
| 111 | Datenaustausch | Datenimport (allgemein) | src/centron/Centron.WPF.UI/Modules/DataExchange/DataImport | Generischer Import von Fremddaten in c-entron |
|
||||
| 112 | Datenaustausch | Buchhaltungsexport | src/centron/Centron.WPF.UI/Modules/DataExchange/BookKeeping | Export von Buchungsdaten an Finanzbuchhaltungssysteme |
|
||||
| 113 | Datenaustausch | DATEV-Anbindung | src/centron/Centron.WPF.UI/Modules/DataExchange/DatevOnline2020 | Direkter Datenaustausch mit DATEV |
|
||||
| 114 | Datenaustausch | SEPA-Zahlungsverkehrsdatei | src/centron/Centron.WPF.UI/Modules/DataExchange/PaymentTransactions | Erzeugung von SEPA-Zahlungs-/Lastschriftdateien (Risikobereich) |
|
||||
| 115 | Datenaustausch | Telekom-DIVE-Datenaustausch | src/centron/Centron.WPF.UI/Modules/DataExchange/TelekomDive | Datenaustausch mit der Telekom-DIVE-Plattform |
|
||||
| 116 | Datenaustausch | Datenexport (allgemein) | src/centron/Centron.WPF.UI/Modules/DataExchange/DataExport | Genereller Export von c-entron-Daten |
|
||||
| 117 | Datenaustausch | Sonstige Schnittstellen | src/centron/Centron.WPF.UI/Modules/DataExchange/Connectors, DocSync, Rmm, SupplierOrderPerBranch | Weitere Konnektoren (Remote Monitoring, filialweise Lieferantenbestellung) |
|
||||
| 118 | Betrieb | Deployment & Betrieb | deployment/, docker/, azure/, azure-blazor/ | Build-, Container- und Pipeline-Konfiguration für Auslieferung und Betrieb |
|
||||
|
||||
**118 Inventarzeilen.** Datenbankschema (`SSMS_DB_SCHEMA.sql`) ist kein eigenständiges Modul, sondern durchgängig als Belegquelle für Datenmodell/Constraints in den obigen Zeilen herangezogen.
|
||||
|
||||
## Abdeckungstabelle
|
||||
|
||||
Einstufung je Inventarzeile: **tief** (Anforderung auf mehreren Ebenen mit StRS→SyRS/SwRS-Kette und mindestens einem PRIMÄR-Beleg vertieft), **mittel** (genau eine Anforderung, aber mit PRIMÄR-Beleg), **flach** (genau eine Anforderung, nur SEKUNDÄR/KONTEXT-Belege), **nicht analysiert** (kein Beleg möglich). „Anzahl Anforderungen" zählt alle StRS/SyRS/SwRS-Anforderungen, die diesem Modul unmittelbar zugeordnet sind (bei modulübergreifend geteilten SyRS/SwRS – z. B. SwRS-5 für Opos/Payments oder SwRS-7/SyRS-10 für RightsManagement/Nexus – bei jedem beteiligten Modul mitgezählt).
|
||||
|
||||
| Nr | Modul | Einstufung | Anzahl Anforderungen |
|
||||
|----|-------|------------|------------------------|
|
||||
| 1 | Sales – Sonderpreise/Mailing | tief | 3 (StRS-1, SyRS-2, SwRS-3) |
|
||||
| 2 | CRM/Adressstamm | tief | 3 (StRS-2, SyRS-1, SwRS-1) |
|
||||
| 3 | Kampagnenmanagement | tief | 2 (StRS-3, SwRS-2 [HYPOTHESE]) |
|
||||
| 4 | CRM-Stammdatenlisten | flach | 1 |
|
||||
| 5 | Vertragsverwaltung & -auswertung | flach | 1 |
|
||||
| 6 | Projektverwaltung (Finanzsicht) | flach | 1 |
|
||||
| 7 | Zählerstandserfassung (MPS) | mittel | 1 |
|
||||
| 8 | Produktlebenszyklus-Management | flach | 1 |
|
||||
| 9 | Zahler-/Kostenstellenverwaltung | mittel | 1 |
|
||||
| 10 | Projektpreisimport | flach | 1 |
|
||||
| 11 | Projektmanagement (allgemein) | flach | 1 |
|
||||
| 12 | Belegbearbeitung Kern | tief | 2 (StRS-12, SyRS-5 [HYPOTHESE]) |
|
||||
| 13 | Anzahlungen | tief | 2 (StRS-13, SyRS-3) |
|
||||
| 14 | Steuersatzänderung im Beleg | tief | 2 (StRS-14, SwRS-4) |
|
||||
| 15 | Provisionsermittlung | mittel | 1 |
|
||||
| 16 | Web-Angebote | flach | 1 |
|
||||
| 17 | EDI-Auftragsverbuchung | flach | 1 |
|
||||
| 18 | Automatisierte Rechnungserstellung | mittel | 1 |
|
||||
| 19 | Pauschalabrechnung (Flatrate) | flach | 1 [HYPOTHESE] |
|
||||
| 20 | Zeit-/Leistungsabrechnung (Timer) | flach | 1 [HYPOTHESE] |
|
||||
| 21 | Mahnwesen | tief | 2 (StRS-21, SyRS-4) |
|
||||
| 22 | Offene Posten | tief | 2 (StRS-22, SwRS-5) |
|
||||
| 23 | Zahlungsverkehr (Payments) | tief | 2 (StRS-23, SwRS-5 geteilt) |
|
||||
| 24 | Kontenverwaltung (Buchhaltung) | flach | 1 |
|
||||
| 25 | Warenausgangszahlungen | flach | 1 |
|
||||
| 26 | Kassensystem-Anbindung | mittel | 1 |
|
||||
| 27 | Artikelstammdaten | flach | 1 |
|
||||
| 28 | Artikelimport | flach | 1 |
|
||||
| 29 | Mengeneinheitenverwaltung | mittel | 1 |
|
||||
| 30 | Barcode-Verwaltung | flach | 1 |
|
||||
| 31 | Kommissionierung | flach | 1 |
|
||||
| 32 | Kommissionsware/Konsignation | flach | 1 |
|
||||
| 33 | Inventur | flach | 1 |
|
||||
| 34 | Warengruppenverwaltung | mittel | 1 |
|
||||
| 35 | Artikelsuche | flach | 1 |
|
||||
| 36 | Lieferantensuche | flach | 1 |
|
||||
| 37 | Logistikeinstellungen/Versandarten | flach | 1 |
|
||||
| 38 | EDI-Bestellwesen | flach | 1 |
|
||||
| 39 | Bestellvorschlagsliste | flach | 1 |
|
||||
| 40 | Einkaufseinstellungen | flach | 1 |
|
||||
| 41 | Reisekostenabrechnung | mittel | 1 |
|
||||
| 42 | Fertigungsauftragsverwaltung | flach | 1 |
|
||||
| 43 | Maschinenverwaltung | flach | 1 |
|
||||
| 44 | RMA-Abwicklung | mittel | 1 |
|
||||
| 45 | Ticketverwaltung | flach | 1 |
|
||||
| 46 | Helpdesk-Dashboard | flach | 1 |
|
||||
| 47 | Wartungsverträge/erwartete Ereignisse | mittel | 1 |
|
||||
| 48 | Helpdesk-Einstellungen | flach | 1 |
|
||||
| 49 | Helpdesk Sonstiges | flach | 1 |
|
||||
| 50 | CentronInspectors | mittel | 1 |
|
||||
| 51 | Persönliche Einstellungen (Access-Token) | tief | 3 (StRS-51, SyRS-6, SyRS-7) |
|
||||
| 52 | Mein Tag (MyDay) | flach | 1 |
|
||||
| 53 | MyCentron-Dashboard | flach | 1 |
|
||||
| 54 | Aufgabenliste (ToDo) | flach | 1 |
|
||||
| 55 | Telefonie-Integration | flach | 1 |
|
||||
| 56 | Fernwartungsintegration (Supremo) | flach | 1 |
|
||||
| 57 | Verkaufsstatistik | flach | 1 |
|
||||
| 58 | Management-Informationen | flach | 1 |
|
||||
| 59 | MSP-Statistiken | flach | 1 |
|
||||
| 60 | Mitarbeiteranalyse | flach | 1 |
|
||||
| 61 | Reportverwaltung | flach | 1 |
|
||||
| 62 | Rechteverwaltung | tief | 5 (StRS-62, SyRS-8 [HYPOTHESE-Anteil], SyRS-9, SyRS-10, SwRS-6, SwRS-7) |
|
||||
| 63 | Mitarbeiterverwaltung | flach | 1 |
|
||||
| 64 | Mandantenverwaltung | flach | 1 |
|
||||
| 65 | DSGVO-Funktionen | mittel | 1 |
|
||||
| 66 | Systemeinstellungen | flach | 1 |
|
||||
| 67 | Verbindungs-/Schnittstelleneinstellungen | flach | 1 |
|
||||
| 68 | Kommunikationseinstellungen | flach | 1 |
|
||||
| 69 | Belegwesen-Konfiguration | flach | 1 |
|
||||
| 70 | Stundensätze/Zuschläge | flach | 1 |
|
||||
| 71 | Eskalationseinstellungen | flach | 1 |
|
||||
| 72 | Länderverwaltung | flach | 1 |
|
||||
| 73 | Service-/Leasing-/SEPA-Verträge | mittel | 1 |
|
||||
| 74 | Externe Werkzeuge | flach | 1 |
|
||||
| 75 | WebCart-Konfiguration | flach | 1 |
|
||||
| 76 | Sonstige Prozesseinstellungen | flach | 1 |
|
||||
| 77 | Log-Betrachter | flach | 1 |
|
||||
| 78 | Dienste-Verwaltung | flach | 1 |
|
||||
| 79 | Kontoumsätze | flach | 1 |
|
||||
| 80 | OnlineBanking-Konfiguration | flach | 1 |
|
||||
| 81 | OnlineBanking-Verbindungsdialog | flach | 1 |
|
||||
| 82 | KI-Unterstützung | flach | 1 |
|
||||
| 83 | Umfragen | flach | 1 |
|
||||
| 84 | Massenänderungen | flach | 1 |
|
||||
| 85 | Passwortverwaltung | tief | 2 (StRS-85, SwRS-8) |
|
||||
| 86 | Kalender | flach | 1 |
|
||||
| 87 | Qualitätsmanagement | flach | 1 |
|
||||
| 88 | Telekom-DIVE-Integration (UI) | flach | 1 |
|
||||
| 89 | Startdashboard | flach | 1 |
|
||||
| 90 | Oberflächenprofile | flach | 1 |
|
||||
| 91 | Cross-cutting Dialoge (Global) | flach | 1 |
|
||||
| 92 | Geschäftslogik-/Datenzugriffsschicht | flach | 1 |
|
||||
| 93 | EDI-Lieferantenanbindungen | mittel | 1 |
|
||||
| 94 | Banking-Gateway (Backend) | flach | 1 |
|
||||
| 95 | MSP-Collector-Gateway | flach | 1 |
|
||||
| 96 | E-Rechnungsformate | mittel | 1 |
|
||||
| 97 | Portal-Gateway | flach | 1 |
|
||||
| 98 | Zentrale Web-API | tief | 2 (StRS-98, SyRS-10 geteilt) |
|
||||
| 99 | Lizenz-/Verbindungsmanager | flach | 1 |
|
||||
| 100 | ServiceBoard (Web-Ticketboard) | flach | 1 |
|
||||
| 101 | Nexus Office/Kundenportal (WebCart) | tief | 2 (StRS-101, SwRS-7 geteilt) |
|
||||
| 102 | Web-Fertigungsauftragsverwaltung | flach | 1 |
|
||||
| 103 | Nexus-Verwaltung | mittel | 1 |
|
||||
| 104 | Dokumentensignatur (Web) | flach | 1 [HYPOTHESE] |
|
||||
| 105 | Outlook-Add-in | flach | 1 |
|
||||
| 106 | Produktdaten-Anreicherungs-APIs | flach | 1 |
|
||||
| 107 | Bankanbindung FinAPI | flach | 1 |
|
||||
| 108 | E-Rechnung Österreich | flach | 1 |
|
||||
| 109 | Versanddienstleister-Schnittstellen | flach | 1 |
|
||||
| 110 | PDF-Formulargenerierung (docuFORM) | flach | 1 |
|
||||
| 111 | Datenimport (allgemein) | flach | 1 |
|
||||
| 112 | Buchhaltungsexport | flach | 1 |
|
||||
| 113 | DATEV-Anbindung | flach | 1 |
|
||||
| 114 | SEPA-Zahlungsverkehrsdatei | mittel | 1 |
|
||||
| 115 | Telekom-DIVE-Datenaustausch | flach | 1 |
|
||||
| 116 | Datenexport (allgemein) | flach | 1 |
|
||||
| 117 | Sonstige Schnittstellen | flach | 1 |
|
||||
| 118 | Deployment & Betrieb | mittel | 1 |
|
||||
|
||||
**Summe:** 118 Module, 0 „nicht analysiert" (Mindestabdeckung zu 100 % erreicht) · 14 tief · 18 mittel · 86 flach. Gesamtanzahl Anforderungen: **136** (118 StRS + 10 SyRS + 8 SwRS).
|
||||
|
||||
## Konsistenzcheck
|
||||
|
||||
- **Doppelte/mehrfach vergebene IDs:** Keine gefunden. StRS-1 bis StRS-118 sind lückenlos und eindeutig vergeben (verifiziert per Durchsuchung aller `ID:`-Zeilen in StRS.md). SyRS-1 bis SyRS-10 und SwRS-1 bis SwRS-8 sind ebenfalls eindeutig; SyRS-10 steht aus editortechnischen Gründen physisch vor SyRS-8/SyRS-9 in der Datei (Einfügereihenfolge), was die Eindeutigkeit der IDs nicht beeinträchtigt, aber beim manuellen Lesen auffällt.
|
||||
- **Anforderungen ohne Beleg:** Keine gefunden. Jede der 136 Anforderungen enthält mindestens einen Eintrag unter `Belege:` (automatisiert gegengeprüft: 118 `Belege:`-Vorkommen in StRS.md stehen exakt 118 `ID:`-Vorkommen gegenüber, keine leere Belege-Sektion).
|
||||
- **Anforderungen ohne Angabe zur Übernahmewürdigkeit:** Keine gefunden (automatisiert gegengeprüft, jede `Übernahmewürdigkeit:`-Zeile ist gefüllt).
|
||||
- **Tracelinks auf nicht existierende IDs:** Keine gefunden. Alle in `Tracelinks:`-Feldern referenzierten IDs (siehe `Traceability.md`) liegen innerhalb der belegten Bereiche StRS-1..118, SyRS-1..10, SwRS-1..8.
|
||||
- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk:** Bei der Erstellung wurden 23 Konsolidierungskandidaten aktiv identifiziert und im Feld `Konsolidierung` vermerkt (u. a. StRS-4/StRS-7 Zählerstandserfassung doppelt, StRS-32 Kommissionsware vs. Provision-Namensverwechslung, StRS-62/StRS-103 getrennte Rechtemodelle intern/Web, StRS-65/StRS-73 DSGVO-AVV/SEPA nahezu identischer Signatur-Workflow, StRS-93 sechsfache EDI-Implementierung, StRS-106 vierfache Produktdaten-API, StRS-96/StRS-108 dreifaches E-Rechnungsformat). Ein manueller Nachvergleich der übrigen 95 flach/mittel eingestuften Anforderungen auf **nicht erkannte** Deckungsgleichheit wurde aus Zeitgründen nicht durchgeführt; hierin liegt ein Restrisiko (siehe Selbstbewertung).
|
||||
- **Korrektur während der Erhebung:** Zwei Inventar-Fehleinschätzungen aus Schritt 0 wurden während der Erhebung selbst korrigiert, statt sie unkommentiert zu übernehmen: Zeile 15 (Provision) enthielt ursprünglich fälschlich den Pfad „PartialCommission", der tatsächlich zu Kommissionsware (Zeile 32) gehört; Zeile 50 (CentronInspectors) war ursprünglich fälschlich als Prüfmittelverwaltung statt als Dateninspektions-Framework beschrieben. Beide Korrekturen sind im Modulinventar oben nachvollziehbar vermerkt.
|
||||
- **Nachträglich behobene Regelverstöße (Belegpflicht bei Risikoanforderungen):** Bei der Selbstprüfung wurden drei Anforderungen mit Typ „Sicherheit" bzw. Fakturierungsbezug gefunden, die ursprünglich als `belegt` ohne PRIMÄR-Beleg geführt waren (StRS-19 Pauschalabrechnung, StRS-20 Zeitabrechnung, StRS-104 Web-Dokumentensignatur). Alle drei wurden korrigiert und tragen jetzt `Status: HYPOTHESE` mit expliziter Begründung; sie sind in `Hypothesen.md` nachgeführt.
|
||||
|
||||
### Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
|
||||
|
||||
| ID | Titel | PRIMÄR-Beleg vorhanden? | Status |
|
||||
|----|-------|--------------------------|--------|
|
||||
| StRS-62 | Gruppenbasierte Rechtevergabe | Ja | belegt |
|
||||
| SyRS-8 | Serverseitige Rechteprüfung mit Cache | Ja (für Prüfung selbst), Cache-Invalidierung unbelegt | HYPOTHESE |
|
||||
| SyRS-9 | Admin-Gruppen-Schutz | Ja | belegt |
|
||||
| SwRS-6 | Sichtrus/Sichmemb-Datenmodell | Ja | belegt |
|
||||
| SwRS-7 | Getrennte Web-Rechte | Ja | belegt |
|
||||
| StRS-98 | Web-API duale Authentifizierung | Ja | belegt |
|
||||
| SyRS-10 | Duale API-Authentifizierung | Ja | belegt |
|
||||
| StRS-51 | Personal-Access-Token | Ja | belegt |
|
||||
| SyRS-6 | Pflicht-Ablaufdatum Token | Ja | belegt |
|
||||
| SyRS-7 | Serverseitige Ablaufprüfung Token | Ja | belegt |
|
||||
| StRS-85 | Passwortverwaltung AES-Verschlüsselung | Ja | belegt |
|
||||
| SwRS-8 | AES-Verschlüsselung Master-Key | Ja | belegt |
|
||||
| StRS-65 | DSGVO/AVV/Löschrechte | Ja | belegt |
|
||||
| StRS-104 | Web-Dokumentensignatur | Nein (nur SEKUNDÄR) | **HYPOTHESE** |
|
||||
| SwRS-2 | Rechteabhängige Kampagnenfunktionen | Nein (nur SEKUNDÄR) | **HYPOTHESE** |
|
||||
| SyRS-5 | Nebenläufigkeitsschutz Belege | Nein (nur SEKUNDÄR/Feldexistenz) | **HYPOTHESE** |
|
||||
| StRS-13 | Anzahlung → Schlussrechnung | Ja | belegt |
|
||||
| StRS-14 | Steuersatzänderung | Ja | belegt |
|
||||
| StRS-15 | Provisionsermittlung (Überschreibschutz) | Ja | belegt |
|
||||
| StRS-18 | Automatisierte Rechnungserstellung | Ja | belegt |
|
||||
| StRS-19 | Pauschalabrechnung | Nein (nur SEKUNDÄR) | **HYPOTHESE** |
|
||||
| StRS-20 | Zeit-/Leistungsabrechnung | Nein (nur SEKUNDÄR) | **HYPOTHESE** |
|
||||
| StRS-21 | Mahnwesen (Mahnstopp) | Ja | belegt |
|
||||
| SyRS-4 | Mahnfähigkeit serverseitig | Ja | belegt |
|
||||
| StRS-22 | Offene Posten (OpenPrice-Formel) | Ja | belegt |
|
||||
| StRS-23 | Zahlungserfassung | Ja | belegt |
|
||||
| StRS-26 | Kassensystem-Steuerkonten | Ja | belegt |
|
||||
| StRS-73 | SEPA-Mandate (Signatur-Workflow) | Ja | belegt |
|
||||
| StRS-114 | SEPA-Zahlungsdatei (pain.008) | Ja | belegt |
|
||||
|
||||
**Ergebnis:** 29 risikorelevante Anforderungen identifiziert. Davon tragen 23 (79 %) einen PRIMÄR-Beleg und sind `belegt`; 6 (21 %) sind korrekt als `[HYPOTHESE]` gekennzeichnet (SyRS-8 mit Einschränkung: die Rechteprüfung selbst ist PRIMÄR belegt, die zusätzliche Aussage zur Cache-Invalidierung nicht, daher in Summe HYPOTHESE). Keine risikorelevante Anforderung ist ohne PRIMÄR-Beleg als `belegt` geführt (nach den oben dokumentierten Korrekturen).
|
||||
|
||||
### Abgleich Hypothesen.md gegen Inline-Markierungen
|
||||
|
||||
Automatisiert geprüft: `Hypothesen.md` führt genau die 6 Anforderungen, die in StRS.md/SyRS.md/SwRS.md mit `Status: HYPOTHESE` markiert sind (SyRS-5, SyRS-8, SwRS-2, StRS-19, StRS-20, StRS-104) – keine zusätzliche, keine fehlende. Offene Punkte ohne unmittelbaren Anforderungsbezug (z. B. generelle Unsicherheit über Cache-Ablaufzeiten) stehen ausschließlich in der Selbstbewertung unten, nicht in `Hypothesen.md`.
|
||||
|
||||
## Selbstbewertung
|
||||
|
||||
**Tiefenverteilung:** Von 118 Inventarmodulen wurden 14 **tief** (mehrstufige StRS→SyRS/SwRS-Kette, überwiegend mit PRIMÄR-Beleg), 18 **mittel** (eine Anforderung mit PRIMÄR-Beleg) und 86 **flach** (eine Anforderung mit SEKUNDÄR-/KONTEXT-Beleg) analysiert. **0 Module sind „nicht analysiert"** – die in Schritt 0b geforderte Mindestabdeckung (mindestens eine Anforderung je Modul) wurde für alle 118 Module erreicht.
|
||||
|
||||
**Mindestabdeckung erreicht:** Ja, vollständig. Jedes Modul aus dem Inventar (Schritt 0) trägt mindestens eine Anforderung mit mindestens einem Beleg.
|
||||
|
||||
**Wo war der Beleg dünn:** Die 86 „flach" eingestuften Module stützen sich überwiegend auf SEKUNDÄR-/KONTEXT-Belege (Klassenexistenz, Ordnerstruktur, Namensgebung) statt auf durchsetzende Stellen (PRIMÄR). Das ist in dieser Breitenphase eine bewusste, im Auftrag so vorgesehene Priorisierung („Breite geht vor Tiefe") und kein Zufallsergebnis: Für alle Module mit Bezug zu Sicherheit, Abrechnung/Fakturierung oder Berechtigungen wurde gezielt nach PRIMÄR-Belegen gesucht (siehe Risikoliste oben, 79 % PRIMÄR-Quote), während bei fachlich unkritischeren Modulen (z. B. Kalender, Umfragen, Log-Betrachter, Startdashboard) die Existenzbestätigung über Klassenstruktur als für die Mindestabdeckung ausreichend erachtet wurde. Am dünnsten belegt sind die rein technischen Querschnittsmodule (92 Geschäftslogikschicht, 97 Portal-Gateway, 99 Lizenzmanager) sowie mehrere Nexus-Teilbereiche (100, 102, 105), da hier aus Zeitgründen jeweils nur eine repräsentative Klasse gesichtet wurde, obwohl die zugrundeliegenden Projekte (z. B. Centron.BL mit 2.068 Dateien) erheblich umfangreicher sind.
|
||||
|
||||
**Warum die Hypothesenzahl (6 von 136, 4,4 %) vergleichsweise niedrig ausfällt:** In der Breitenphase (Schritt 0b) wurden Aussagen bewusst eng an das tatsächlich Beobachtete formuliert – „Klasse X belegt Funktion Y" statt „System garantiert Y" –, sodass für die meisten Anforderungen SEKUNDÄR-/KONTEXT-Belege ausreichten, ohne dass eine unbelegte, risikorelevante Aussage entstand, die zwingend `[HYPOTHESE]` erfordert hätte. Die vorhandenen 6 Hypothesen entstanden ausnahmslos dort, wo in der gezielten Risikovertiefung (Schritt 0c) oder bei der abschließenden Selbstprüfung eine serverseitige Durchsetzungsstelle gesucht, aber nicht gefunden wurde (Cache-Invalidierung bei Rechteänderung, Konfliktbehandlung bei Nebenläufigkeit, Kampagnen-Rechteprüfung, Pauschal-/Zeitabrechnungsformel, Web-Signatur-Versiegelung). Eine Vertiefung der 86 „flach" eingestuften Module würde nach bisherigem Muster voraussichtlich weitere Hypothesen zutage fördern, insbesondere überall dort, wo bislang nur eine ViewModel-Klasse, nicht aber die zugehörige BL-Methode gesichtet wurde.
|
||||
|
||||
**Erkenntnisse für eine Folge-Iteration:**
|
||||
1. **MandatorManagement/Mandantentrennung (Modul 64) vertiefen.** Bislang nur strukturell (Firmendaten, Filialen) belegt; die eigentliche Sicherheitsfrage – wie wird verhindert, dass ein Mandant Daten eines anderen Mandanten sieht (Datenbank-Filterung nach MandatorI3D, Zeilenebene vs. Anwendungsebene) – wurde nicht geprüft und ist für ein SaaS-Zielsystem mit gemeinsamer Infrastruktur mehrerer Mandanten sicherheitskritisch.
|
||||
2. **TimerBilling/FlatrateBilling-Berechnungslogik lokalisieren** (StRS-19/20, aktuell HYPOTHESE) – vermutlich in `Centron.BL/Sales/CustomerAssets/TimerBilling` oder einer noch nicht gesichteten Nachbarklasse.
|
||||
3. **Web-Dokumentensignatur-Versiegelung (StRS-104) und Rechte-Cache-Invalidierung (SyRS-8) klären** – beide sicherheitsrelevant und aktuell HYPOTHESE.
|
||||
4. **Konsolidierungskandidaten priorisieren und quantifizieren:** Die 23 gefundenen Fälle (siehe oben) sollten in einer Folge-Iteration mit Aufwandsschätzung für die Zusammenführung versehen werden, beginnend bei den am klarsten belegten Fällen (SEPA/DSGVO-Signatur-Workflow, sechsfache EDI-Anbindung, vierfache Produktdaten-API).
|
||||
5. **86 „flach" eingestufte Module gezielt auf SwRS-Ebene ergänzen**, insbesondere die datenintensiven Kernmodule Warehousing/ArticleManagement (320 Dateien, aber nur 1 Anforderung) und Finances/Receipts-Kern (794 Dateien, nur StRS-12), deren Umfang die aktuelle Abdeckungstiefe deutlich übersteigt.
|
||||
6. **Manueller Deckungsgleichheits-Check der 95 nicht aktiv auf Konsolidierung geprüften Anforderungen** (siehe Konsistenzcheck), da bei einer Codebasis dieser Größe weitere, bislang unentdeckte Dopplungen wahrscheinlich sind.
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
# Glossar
|
||||
|
||||
Domänenbegriffe, wie sie in den Anforderungen verwendet werden. Technische Bezeichner (Klassen/Methoden/Spalten) bleiben in Originalsprache.
|
||||
|
||||
| Begriff | Bedeutung im Kontext c-entron |
|
||||
|---------|-------------------------------|
|
||||
| Beleg / Belegkette | Sammelbegriff für Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Bestellung; technisch getrennte Kopftabellen (`AngKopf`, `AufKopf`, `LiefKopf`, `RechKopf`, `GutKopf`, `BestKopf`), fachlich eine zusammenhängende Verarbeitungskette (siehe StRS-12). |
|
||||
| Anzahlung / Anzahlungsrechnung | Vor der Schlussrechnung gestellte Teilrechnung zu einem Auftrag; wird bei Erstellung der Schlussrechnung vom Gesamtbetrag abgezogen (StRS-13). |
|
||||
| Sonderpreis (Special Price) | Kunden- bzw. kundenklassenspezifischer, vom Listenpreis abweichender Artikelpreis mit Gültigkeitszeitraum (`AccountSpecialPriceDTO`); Grundlage sowohl für die klassische Vertriebspreisfindung (StRS-1) als auch für den WebCart-Shop (StRS-75). |
|
||||
| Kontingent | Im Vertrag hinterlegte Mengenobergrenze für eine Leistung/einen Artikel, gegen die der tatsächliche Verbrauch aus Belegen gegengerechnet wird (StRS-5). |
|
||||
| Kommissionsware / Konsignation | Ware, die einem Kunden zur Ansicht/zum Verbrauch überlassen wird, ohne dass zum Übergabezeitpunkt bereits eine Rechnung gestellt wird; Abrechnung erfolgt erst bei tatsächlichem Verbrauch/Verkauf (Modul „Warehousing/Commissions", StRS-32). Nicht zu verwechseln mit „Provision" (siehe dort). |
|
||||
| Provision | Verkäuferbezogene Vergütung auf Basis abgeschlossener Belege, gesteuert über Provisionsschemata (Modul „Finances/Receipts/Provision", StRS-15). Im Quellcode weckt der Ordnername „PartialCommission" (Finances/Receipts) durch die englische Doppelbedeutung von „Commission" Verwechslungsgefahr mit „Kommissionsware" – „PartialCommission" gehört fachlich zu Letzterem (siehe Korrekturhinweis in Analysebericht.md, Zeile 15 des Inventars). |
|
||||
| Offene Posten (Opos) | Noch nicht vollständig ausgeglichene Rechnungsbeträge; `OpenPrice` wird zentral aus Bruttobetrag (bzw. Nettobetrag bei nicht ausweisbarer USt.), bereits gezahltem Betrag und Währungsfaktor berechnet (StRS-22). |
|
||||
| Mahnstopp / Mahnstufe | Am Rechnungskopf geführtes Flag (`MahnStop`) bzw. Zähler (`Mahnstufe`), das eine Rechnung zeitweise oder dauerhaft vom automatisierten Mahnlauf ausschließt bzw. deren Mahnfortschritt dokumentiert (StRS-21). |
|
||||
| Zahler / Kostenstelle / Kostenobjekt | Vom Rechnungsempfänger abweichende Instanz, die einen Beleg wirtschaftlich trägt (Zahler), bzw. interne Verrechnungseinheiten für Kosten (Kostenstelle/-objekt) (StRS-9). |
|
||||
| AVV (Auftragsverarbeitungsvertrag) | Datenschutzrechtlich (Art. 28 DSGVO) erforderlicher Vertrag mit Auftragsverarbeitern; im System als digitaler Signatur-Workflow mit Vorlagen abgebildet (StRS-65), strukturell nahezu identisch mit dem SEPA-Mandats-Workflow (StRS-73). |
|
||||
| Recht / Rechtegruppe (Sichtrus/Sichmemb) | Internes RBAC-Modell: Rechte (`AppRight`) werden ausschließlich Gruppen (`AppGroup`) zugewiesen (Tabelle `Sichtrus`), Benutzer werden Gruppen zugeordnet (Tabelle `Sichmemb`); ein Benutzer besitzt die Vereinigungsmenge der Rechte all seiner Gruppen (StRS-62). Getrennt davon existiert ein strukturell ähnliches, aber eigenständiges Rechtemodell für Web-Accounts (`WebRights`). |
|
||||
| Web-Account | Eigenständiges Login für externe Personen (Kunden, Web-Shop-Nutzer), technisch getrennt vom internen Mitarbeiter-Login (`AppUser`) samt eigenem Rechtemodell (siehe „Recht"). |
|
||||
| I3D | Durchgängige Namenskonvention für den Primärschlüssel/die eindeutige ID einer Entität in c-entron (z. B. `accountI3D`, `articleI3D`); technischer Bezeichner, bleibt in Originalform. |
|
||||
| Stammblatt | Im Altbestand verwendete Bezeichnung für ein verwaltetes Gerät (z. B. Drucker) mit Zählerstandshistorie; fachlich Teil des in dieser Analyse dokumentierten Gerätelebenszyklus (PLM, DeviceClickCounter). |
|
||||
| RMA | Return Merchandise Authorization – Rücksendeprozess für reklamierte/defekte Ware (StRS-44). |
|
||||
| PLM | Product Lifecycle Management – Verwaltung von Produktfamilien und deren Lebenszyklusphasen, hier zusätzlich auf einzelne ausgelieferte Geräte angewendet (StRS-8). |
|
||||
| MSP | Managed Service Provider – Geschäftsmodell, bei dem c-entron-Kunden IT-Dienstleistungen für ihre eigenen Endkunden erbringen; das System sammelt hierzu Gerätedaten externer MSP-Plattformen (StRS-59, StRS-95). |
|
||||
| EDI | Electronic Data Interchange – strukturierter elektronischer Geschäftsdatenaustausch (Bestellung, Lieferschein, Rechnung) mit Distributoren (StRS-38, StRS-93). |
|
||||
| ZUGFeRD / openTRANS / ebInterface | Strukturierte E-Rechnungsformate; ZUGFeRD (hybrides PDF+XML, Standard „CrossIndustryInvoice"), openTRANS (älterer XML-Standard), ebInterface (österreichischer E-Rechnungsstandard) – im System parallel implementiert (StRS-96, StRS-108). |
|
||||
| SEPA (pain.008) | Single Euro Payments Area – einheitlicher europäischer Zahlungsverkehrsraum; `pain.008` ist der ISO-20022-Nachrichtentyp für SEPA-Lastschriften (StRS-114). |
|
||||
| DATEV | Weit verbreitete deutsche Software/Datenaustauschformat für Steuerberater und Finanzbuchhaltung (StRS-113). |
|
||||
| FinTS/HBCI | Standardisiertes deutsches Online-Banking-Protokoll für den automatisierten Kontoabruf (StRS-79, StRS-94). |
|
||||
| Belegwesen / Fakturierung | Sammelbegriff für die Erstellung und Verwaltung kaufmännischer Belege (Angebot bis Rechnung) bzw. speziell den Rechnungsstellungsprozess. |
|
||||
| AccountType | Fachliche Rollenzuweisung eines Adressstamm-Datensatzes (`Account`), z. B. „Customer" (Kunde), „Supplier" (Lieferant); ein Account kann mehrere AccountTypes gleichzeitig besitzen (StRS-2). |
|
||||
| Mandant / Filiale | Mandant = rechtlich eigenständige Unternehmenseinheit im Mehrmandantenbetrieb; Filiale = organisatorische Untereinheit eines Mandanten mit eigenem Belegnummernkreis (StRS-64). |
|
||||
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
# Hypothesen
|
||||
|
||||
Sammlung aller mit `[HYPOTHESE]` markierten Anforderungen. Diese Liste ist deckungsgleich mit den Inline-Markierungen in StRS/SyRS/SwRS (keine zusätzlichen freien Fragen ohne zugehörige Anforderung – offene Punkte ohne Anforderungsbezug stehen in der Selbstbewertung in `Analysebericht.md`).
|
||||
|
||||
| ID | Titel | Offene Frage / fehlende Information zur Bestätigung |
|
||||
|----|-------|-------------------------------------------------------|
|
||||
| SyRS-5 | Nebenläufige Bearbeitung von Belegen durch Sperr- und Versionskennung absichern | `RechKopf` führt `LockUser` und die GUID-Spalte `GUI3D`; belegt ist damit nur die Existenz der Felder. Nicht lokalisiert wurde die Schreibstelle, die beim Speichern eines Belegs die aktuelle mit der beim Laden gelesenen GUID/dem LockUser vergleicht und bei Abweichung den Speichervorgang abweist. Zur Bestätigung fehlt: die konkrete Save-Methode in Centron.BL/Centron.DAO für Belegköpfe (z. B. `RechKopfBL.Save`) mit ihrer Konfliktprüfung. |
|
||||
| SyRS-8 | Serverseitige Rechteprüfung mit benutzerbezogenem Cache | `AppRightsBL.HasUserRight()` cacht Rechte je Benutzer unter dem Schlüssel `AllRightsFromAppUser{appUserI3D}`. Nicht lokalisiert wurde ein Aufruf, der diesen Cache-Eintrag gezielt invalidiert, wenn sich die Gruppenzuordnung eines Benutzers oder die Rechte einer Gruppe ändern (z. B. in `SaveAndAssignGroupToRight`/`RemoveAssignGroupToRight`). Zur Bestätigung fehlt: Einsicht in die Cache-Implementierung (`Session.Advanced.Cache`) und deren Ablaufzeit/Invalidierungsstrategie. |
|
||||
| SwRS-2 | Rechteabhängige Freigabe von Kampagnenfunktionen | `CampaignMainViewModel` führt die Felder `UserCanEditCampaign`/`UserCanOpenCampaign`, die vermutlich aus einer Rechteprüfung stammen. Nicht lokalisiert wurde die serverseitige Stelle, die diese Flags setzt bzw. die bei einem direkten Service-Aufruf (unter Umgehung der UI) das Bearbeiten/Öffnen einer Kampagne ohne Recht tatsächlich verhindert. Zur Bestätigung fehlt: die Backend-Methode, die beim Speichern/Öffnen einer Kampagne das zugehörige Recht prüft (analog zu `AppRightsBL.HasUserRight`). |
|
||||
| StRS-19 | Pauschale Projektleistungen abrechnen | Die Existenz eines eigenständigen Pauschalabrechnungs-Moduls (`FlatRateProjectAppModuleController`) ist belegt, nicht aber die BL-seitige Berechnungsstelle, die den Pauschalbetrag unabhängig von erfassten Stunden in die Rechnung übernimmt. Da es sich um Fakturierungslogik handelt, ist ohne PRIMÄR-Beleg zwingend `[HYPOTHESE]` zu setzen. Zur Bestätigung fehlt: die Business-Logic-Klasse, die die Rechnungsposition aus dem Pauschalpreis erzeugt. |
|
||||
| StRS-20 | Erfasste Zeiten/Leistungen verrechnen | `TimerBillingViewModel` und `TimerBillingBL.cs` existieren; die konkrete Formel (Stundensatz × erfasste Dauer, inkl. Zuschlägen aus StRS-70) wurde in `TimerBillingBL.cs` nicht lokalisiert. Zur Bestätigung fehlt: die Berechnungsmethode in `TimerBillingBL` bzw. der aufgerufenen Rechnungspositions-Erzeugung. |
|
||||
| StRS-104 | Elektronische Dokumentensignatur im Web mit Signaturstil-Auswahl | Belegt ist nur die Auswahl von Signaturstil/-farbe (`SignatureType` u. a.). Nicht lokalisiert wurde die Stelle, die die Signatur manipulationssicher/rechtsverbindlich in das Dokument einbettet. Zur Bestätigung fehlt: die serverseitige Signatur-Versiegelungslogik in `CentronNexus/DocumentSigning`, ggf. mit Bezug zu `PdfSigningBL` (StRS-69). |
|
||||
|
||||
**Hinweis zur Menge:** Bei einer Codebasis dieser Größe (>15.000 Dateien) mit vollständiger Modulabdeckung, aber notwendig selektiver Vertiefung (Schritt 0c), ist eine Hypothesenzahl von 6 (von 136 Anforderungen, 4,4 %) zunächst niedrig. Der Grund: In der Breitenphase (Schritt 0b) wurden Aussagen bewusst eng an das tatsächlich Beobachtete formuliert (z. B. „Klasse belegt X" statt „System garantiert X"), sodass für die meisten Anforderungen SEKUNDÄR-/KONTEXT-Belege ausreichten, ohne dass eine unbelegte, risikorelevante Aussage entstand, die eine `[HYPOTHESE]`-Kennzeichnung erzwungen hätte. Echte Hypothesen entstanden dort, wo in der Vertiefungsphase (Schritt 0c) eine serverseitige Durchsetzungsstelle gezielt gesucht, aber nicht gefunden wurde. Weitere, tiefer liegende Hypothesen sind bei einer Vertiefung der in der Selbstbewertung (`Analysebericht.md`) genannten Module wahrscheinlich (insbesondere MandatorManagement/Mandantentrennung, EmployeeManagement-Rechtezuordnung, ServiceAndLeasing).
|
||||
|
||||
+2398
File diff suppressed because it is too large
Load Diff
+166
@@ -0,0 +1,166 @@
|
||||
# Software Requirements Specification (SwRS) – c-entron ERP-Suite
|
||||
|
||||
Nach ISO/IEC/IEEE 29148:2018. Komponenten, Datenmodelle, software-interne Regeln. IDs: `SwRS-<n>`, laufend über alle Module.
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
ID: SwRS-1
|
||||
Titel: CanAccept()-Gate für den Kundenanlage-Dialog
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Komponente MakeCustomerViewModel
|
||||
Vorbedingung: Dialog "Kundendaten eingeben" ist geöffnet
|
||||
Fakt: CanAccept() (Z. 244-293) ist als Predicate von DelegateCommand AcceptCommand (Z. 210) verdrahtet; DevExpress.Mvvm.DelegateCommand ruft CanAccept() bei jeder Eigenschaftsänderung erneut auf und (de-)aktiviert den zugehörigen Button
|
||||
Aussage: Die Komponente MakeCustomerViewModel soll den Speicherbefehl des Kundenanlage-Dialogs an das Prädikat CanAccept() binden, sodass der Button automatisch reagiert, ohne dass der Anwender manuell eine Prüfung anstoßen muss.
|
||||
Ergebnis: Schaltfläche "Übernehmen" ist genau dann aktiv, wenn CanAccept() true liefert
|
||||
Belege:
|
||||
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Crm/MakeCustomerViewModel.cs, Zeile 210 (AcceptCommand = new DelegateCommand(this.Accept, this.CanAccept)) - Begründung: Verdrahtung von Commandausführung und Prüfprädikat an der durchsetzenden Stelle
|
||||
Prüfidee: Unit-Test, der CanAccept() mit einer Kombination gesetzter/nicht gesetzter Pflichtfelder aufruft und den erwarteten bool-Rückgabewert prüft
|
||||
Tracelinks: SyRS-1
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Command/CanExecute-Bindung ist Standardmuster und im Zielsystem als deklarative Validierung abzubilden
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SwRS-2
|
||||
Titel: Rechteabhängige Freigabe von Kampagnenfunktionen
|
||||
Ebene: SwRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Komponente CampaignMainViewModel
|
||||
Vorbedingung: Kampagnenübersicht ist geladen
|
||||
Fakt: Felder UserCanEditCampaign und UserCanOpenCampaign (Z. 37, 40) steuern laut Namensgebung und Verwendung im ViewModel die Aktivierung von Bearbeiten-/Öffnen-Funktionen; die Herkunft der Werte (Rechteservice) wurde im Rahmen dieser Analyse nicht bis zur prüfenden Stelle zurückverfolgt
|
||||
Aussage: Die Komponente CampaignMainViewModel soll Bearbeiten- und Öffnen-Funktionen für Kampagnen abhängig von vorab ermittelten Berechtigungsflags freigeben oder sperren.
|
||||
Ergebnis: UI-Funktionen sind entsprechend der Berechtigungsflags aktiv/inaktiv
|
||||
Belege:
|
||||
- [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Campaigns/CampaignMainViewModel.cs (Z. 37, 40) - Begründung: Feldnamen belegen die UI-seitige Rechteauswertung; die serverseitig prüfende Stelle ist damit nicht belegt, daher sekundär statt primär und keine Sicherheits-Risikoeinstufung ohne PRIMÄR-Beleg
|
||||
Prüfidee: Benutzer ohne Kampagnen-Bearbeitungsrecht anmelden und prüfen, dass die Bearbeiten-Funktion in der UI deaktiviert ist UND ein direkter Service-Aufruf serverseitig abgelehnt wird
|
||||
Tracelinks: StRS-3
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - rechteabhängige Funktionsfreigabe ist Standardanforderung; serverseitige Durchsetzung im Zielsystem verifizieren (siehe Hypothese)
|
||||
Status: HYPOTHESE
|
||||
```
|
||||
|
||||
```
|
||||
ID: SwRS-3
|
||||
Titel: Update statt Duplikat bei bestehendem Sonderpreis
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Komponente PositionToSpecialPriceViewModel
|
||||
Vorbedingung: Für Artikel/Kundenklasse existiert bereits ein AccountSpecialPriceDTO
|
||||
Fakt: Bei Fund eines existingSpecialPrice werden dessen Felder ArticleDescription, Comment, ValueKind, Value, ValidFrom, ValidTo mit den neuen Werten überschrieben und derselbe Datensatz (specialPriceToSave = existingSpecialPrice, Z. 121) gespeichert, statt einen neuen Datensatz anzulegen (Kommentar Z. 113: "Make sure to update the existing one, to not create duplicates")
|
||||
Aussage: Die Komponente PositionToSpecialPriceViewModel soll bei Bestätigung des Überschreibens den bestehenden Sonderpreis-Datensatz aktualisieren, statt einen weiteren Datensatz mit gleicher Artikel-/Kundenklassen-Zuordnung anzulegen.
|
||||
Ergebnis: Je Artikel/Kundenklasse existiert höchstens ein Sonderpreis-Datensatz
|
||||
Belege:
|
||||
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Receipts/PositionToSpecialPrice/PositionToSpecialPriceViewModel.cs, Z. 113-121 - Begründung: Code-Kommentar und Zuweisung belegen explizit die Duplikatvermeidung als bewusste Entwurfsentscheidung
|
||||
Prüfidee: Zwei Sonderpreise für denselben Artikel/dieselbe Kundenklasse anlegen und in der Datenbank prüfen, dass nur ein Datensatz existiert
|
||||
Tracelinks: SyRS-2
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Datenintegritätsregel ohne erkennbaren Workaround-Charakter
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SwRS-4
|
||||
Titel: Länderspezifische Steuersatzliste als einzige Quelle für ChangeTaxRateViewModel
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Komponente ChangeTaxRateViewModel
|
||||
Vorbedingung: Dialog "Mehrwertsteuer ändern" wird initialisiert
|
||||
Fakt: InitializeAsync(int? taxI3D) ruft IValueAddedTaxLogic.GetVATByCountry(CentronApplication.Instance.DefaultCountry.I3D) auf und befüllt TaxRates ausschließlich mit dem Ergebnis; SelectedTaxRate wird per I3D-Abgleich aus genau dieser Liste vorbelegt
|
||||
Aussage: Die Komponente ChangeTaxRateViewModel soll die auswählbaren Steuersätze ausschließlich aus dem länderspezifischen Ergebnis von IValueAddedTaxLogic.GetVATByCountry beziehen, ohne eigene oder erweiterte Werte zuzulassen.
|
||||
Ergebnis: TaxRates-Liste enthält genau die vom Backend für das Land gelieferten Sätze
|
||||
Belege:
|
||||
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ChangeTaxRate/ChangeTaxRateViewModel.cs, Methode InitializeAsync() (Z. 41-48) - Begründung: Durchsetzende Stelle, die die Datenquelle der Auswahlliste auf den Backend-Aufruf beschränkt
|
||||
Prüfidee: Backend-Antwort auf zwei Steuersätze begrenzen und prüfen, dass der Dialog exakt diese zwei Optionen anzeigt
|
||||
Tracelinks: StRS-14
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - zentrale, länderabhängige Steuersatzquelle vermeidet inkonsistente Sätze
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SwRS-5
|
||||
Titel: Berechnungsregel für OpenPrice/OpenPriceFC in der Belegsuche
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Komponente InvoiceReceiptSearchConfiguration (Centron.BL)
|
||||
Vorbedingung: Rechnungsdatensatz RechKopf (AK) wird für Opos/Zahlungserfassung gelesen
|
||||
Fakt: OpenPrice = IIF(ISNULL(AK.MwstNichtAusweisbar,0)=0, AK.Brutto, AK.Netto) − (ISNULL(AK.Bezahlt,0) / AK.CurrencyFactor); OpenPriceFC = ROUND((IIF(...)*AK.CurrencyFactor) − ISNULL(AK.Bezahlt,0), 2) (Z. 71-72)
|
||||
Aussage: Die Komponente InvoiceReceiptSearchConfiguration soll den offenen Rechnungsbetrag in Haus- und Fremdwährung einheitlich aus Brutto-/Netto-Betrag, Umsatzsteuerausweisbarkeit, bereits bezahltem Betrag und Währungsfaktor ableiten, damit alle lesenden Module (Opos, Zahlungserfassung, Mahnwesen) denselben Wert erhalten.
|
||||
Ergebnis: OpenPrice/OpenPriceFC sind für alle Verbraucher dieser zentralen Abfrage konsistent
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/InvoiceReceiptSearchConfiguration.cs, Z. 71-72 - Begründung: Einzige durchsetzende Berechnungsstelle, aus der Opos-Übersicht und Zahlungserfassung ihre Werte beziehen
|
||||
Prüfidee: Unit-/Integrationstest mit MwstNichtAusweisbar=1, Bezahlt>0 und CurrencyFactor≠1 gegen die erwartete Formel prüfen
|
||||
Tracelinks: SyRS-2, StRS-22, StRS-23
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - zentrale, einheitliche Berechnungsstelle vermeidet abweichende Parallelberechnungen in Opos/Zahlungserfassung/Mahnwesen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SwRS-6
|
||||
Titel: Datenmodell Sichtrus/Sichmemb für gruppenbasierte Rechte
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Komponente AppRightsBL
|
||||
Vorbedingung: Rechteprüfung für einen Benutzer wird angestoßen
|
||||
Fakt: GetAllAppRightsFromUser() (Z. 651-664) verknüpft dbo.Sichtrus (Spalten Gruppe, Recht) über die Gruppen-ID mit dbo.Sichmemb (Spalten Gruppe, Benutzer) und liefert alle Recht-IDs, die irgendeiner Gruppe des Benutzers zugeordnet sind
|
||||
Aussage: Die Komponente AppRightsBL soll das Rechtemodell als Zuordnung Gruppe→Recht (Sichtrus) getrennt von der Zuordnung Benutzer→Gruppe (Sichmemb) führen, sodass sich ein Recht nie direkt, sondern immer nur über eine Gruppe einem Benutzer zuordnen lässt.
|
||||
Ergebnis: Effektive Rechte eines Benutzers ergeben sich als Vereinigungsmenge der Rechte all seiner Gruppen
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Z. 653-656 (SQL-Text) - Begründung: Durchsetzende Datenbankabfrage, die das Rechtemodell exakt definiert
|
||||
Prüfidee: Benutzer zwei Gruppen mit je einem unterschiedlichen Recht zuordnen und prüfen, dass GetAllAppRightsFromUser() beide Rechte zurückliefert
|
||||
Tracelinks: StRS-62
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - reines Gruppenmodell ohne Benutzer-Einzelrechte vereinfacht Administration und Auditierbarkeit
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SwRS-7
|
||||
Titel: Getrennte Rechtemodelle für interne Benutzer und Web-Accounts
|
||||
Ebene: SwRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Komponente AppRightsBL
|
||||
Vorbedingung: Rechteprüfung für einen Web-Account (Kundenportal/Nexus) wird angestoßen
|
||||
Fakt: HasWebAccountRight() (Z. 666-677) nutzt eine vollständig getrennte Datenquelle (Tabelle WebAccountsRights, Spalte WebRightsI3D) gegenüber HasUserRight() für interne Benutzer (Sichtrus/Sichmemb); beide Methoden liegen zwar in derselben Klasse AppRightsBL, referenzieren aber getrennte Entitäten AppRight vs. WebRights
|
||||
Aussage: Die Komponente AppRightsBL soll interne Benutzerrechte und Web-Account-Rechte als zwei fachlich getrennte, aber strukturell gleichartige Modelle (Objekt→Recht-Zuordnung) führen.
|
||||
Ergebnis: Web-Accounts erhalten ausschließlich über WebAccountsRights geprüfte Rechte, unabhängig vom internen Rechtemodell
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Z. 666-691 - Begründung: Durchsetzende Stelle, die ein zur internen Rechteprüfung strukturell paralleles, aber datenseitig getrenntes Modell implementiert
|
||||
Prüfidee: Web-Account und internen Benutzer mit identischem Namen aber unterschiedlichen Rechten anlegen und prüfen, dass sich Web-Zugriff und interner Zugriff unabhängig voneinander verhalten
|
||||
Tracelinks: StRS-62, StRS-101 (Nexus)
|
||||
Konsolidierung: Kandidat: Zwei strukturell gleichartige, aber datenseitig getrennte Rechtemodelle (AppRight/Sichtrus für interne Benutzer, WebRights für Web-Accounts) - im Zielsystem als ein gemeinsames Rechtemodell mit Geltungsbereich zu konsolidieren
|
||||
Übernahmewürdigkeit: Workaround - historisch getrennt gewachsene Rechtemodelle für zwei Kanäle; im SaaS-Zielsystem mit einheitlichem Identitätsmodell zusammenzuführen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SwRS-8
|
||||
Titel: AES-Verschlüsselung von Zugangsdaten mit zentralem Master-Schlüssel
|
||||
Ebene: SwRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Komponente PasswordManagerBL
|
||||
Vorbedingung: Zugangsdatensatz wird gespeichert oder gelesen
|
||||
Fakt: Speichern: new AESCryptoLogic().EncryptText(customerHotline.Password, masterKeyResult.Data) (Z. 700); Lesen: new AESCryptoLogic().DecryptText(propertyValue?.ValueEncryptedString, masterKey) (Z. 1051-1052) bzw. (Z. 1179); der Master-Schlüssel selbst stammt aus CentronConfigurationDbBL.GetHotlineMasterKey() (Z. 551), also einer von der Fachdatenbank getrennten Konfigurationsdatenbank
|
||||
Aussage: Die Komponente PasswordManagerBL soll jedes Passwortfeld beim Schreiben mit AES und einem aus einer getrennten Konfigurationsdatenbank bezogenen Master-Schlüssel verschlüsseln und beim Lesen entsprechend entschlüsseln, sodass ein Zugriff auf die Fachdatenbank allein nicht zur Preisgabe der Zugangsdaten führt.
|
||||
Ergebnis: ValueEncryptedString enthält niemals Klartext; Klartext existiert nur transient nach Entschlüsselung mit korrektem Master-Schlüssel
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Z. 700, 1051-1052, 1179, 551 - Begründung: Durchsetzende Ver-/Entschlüsselungsstellen und Herkunft des Master-Schlüssels aus getrennter Konfigurationsdatenbank
|
||||
Prüfidee: Master-Schlüssel-Zugriff simulieren und prüfen, dass ohne ihn kein aus der Fachdatenbank gelesener ValueEncryptedString entschlüsselbar ist
|
||||
Tracelinks: StRS-85
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Trennung von Chiffrat und Schlüssel auf getrennte Datenbanken ist ein sinnvolles Sicherheitsmuster für das Zielsystem
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
+207
@@ -0,0 +1,207 @@
|
||||
# System Requirements Specification (SyRS) – c-entron ERP-Suite
|
||||
|
||||
Nach ISO/IEC/IEEE 29148:2018. Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen. IDs: `SyRS-<n>`, laufend über alle Module.
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
ID: SyRS-1
|
||||
Titel: Konfigurierbares Pflichtfeld-Set bei Objekterzeugung prüfen
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (CRM-Teilsystem)
|
||||
Vorbedingung: Anwender löst die Erzeugung eines neuen fachlichen Objekts (hier: AccountType "Customer") aus einem bestehenden Datensatz aus
|
||||
Fakt: MakeCustomerViewModel.CanAccept() liest 20 Boolean-Flags aus CrmSettings/CurrentAccount (z. B. IsAccountEmailRequired) und verknüpft sie jeweils mit einer Nullprüfung des zugehörigen Eingabefelds, bevor AcceptCommand ausführbar wird
|
||||
Aussage: Das System soll vor dem Anlegen eines Kunden aus einem Adressstamm-Datensatz alle als Pflichtfeld konfigurierten Angaben auf Vollständigkeit prüfen und die Speicherung erst danach zulassen.
|
||||
Ergebnis: Speicherbefehl ist genau dann ausführbar, wenn alle konfigurierten Pflichtfelder befüllt sind
|
||||
Belege:
|
||||
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Crm/MakeCustomerViewModel.cs, Methode CanAccept() (Z. 244-293) - Begründung: Durchsetzende Stelle der Pflichtfeldprüfung vor Freigabe des Speicherbefehls
|
||||
Prüfidee: Alle Pflichtfeld-Flags in CrmSettings deaktivieren und prüfen, dass der Dialog ohne Eingaben speicherbar ist; danach ein Flag aktivieren und Gegenprobe durchführen
|
||||
Tracelinks: StRS-2
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - konfigurierbare Pflichtfelder je Mandant sind ein wiederkehrendes Muster, das im Zielsystem als generischer Validierungsmechanismus vorgesehen werden sollte
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-2
|
||||
Titel: Duplikatprüfung beim Anlegen eines Sonderpreises aus der Belegposition
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (Belegerfassung)
|
||||
Vorbedingung: Anwender legt aus einer Belegposition heraus einen neuen Sonderpreis für Artikel/Kundenklasse an
|
||||
Fakt: PositionToSpecialPriceViewModel.CreateSpecialPrices() (Z. 80-131) lädt bestehende Sonderpreise über IAccountSpecialPriceLogic.GetAccountSpecialPricesAsync(), sucht je Artikel (ArticleI3D) einen bereits vorhandenen Sonderpreis und fragt bei Fund per Dialog "Sonderpreis existiert bereits" (Z. 100-108) nach, ob überschrieben werden soll; bei Ablehnung wird die Zeile übersprungen (continue, Z. 111), bei Zustimmung der bestehende Datensatz aktualisiert statt dupliziert (Z. 114-121)
|
||||
Aussage: Das System soll beim Anlegen eines Sonderpreises aus einer Belegposition heraus prüfen, ob für Artikel und Kundenklasse bereits ein Sonderpreis existiert, und eine explizite Anwenderentscheidung einholen, statt stillschweigend einen Duplikatsatz anzulegen.
|
||||
Ergebnis: Es existiert höchstens ein aktiver Sonderpreis je Artikel/Kundenklasse-Kombination, sofern der Anwender das Überschreiben bestätigt oder ablehnt
|
||||
Belege:
|
||||
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Receipts/PositionToSpecialPrice/PositionToSpecialPriceViewModel.cs, Methode CreateSpecialPrices() (Z. 80-131) - Begründung: Durchsetzende Stelle, die Duplikate durch Update des bestehenden Datensatzes statt Neuanlage verhindert und den Anwender aktiv einbindet
|
||||
Prüfidee: Für einen Artikel mit bereits bestehendem Sonderpreis einen zweiten Sonderpreis aus einer Belegposition anlegen und prüfen, dass der Bestätigungsdialog erscheint und bei "Nein" kein zweiter Datensatz entsteht
|
||||
Tracelinks: StRS-1
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Duplikatvermeidung bei Sonderpreisen ist eine sinnvolle Datenintegritätsregel
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-3
|
||||
Titel: Auftragsbezogene Anzahlungsrechnungen für die Schlussrechnung bereitstellen
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (Belegverwaltung)
|
||||
Vorbedingung: Schlussrechnungserstellung zu einem Auftrag wird angestoßen
|
||||
Fakt: LoadRelatedDownPaymentInvoices() filtert über ReceiptSearchFilter mit DownPaymentForOrderI3D=orderI3D und ReceiptKinds=InvoiceClass inkl. bereits abgeschlossener Belege (IncludeClosedReceipts=true), lädt zu jedem Treffer den vollständigen ReceiptInvoiceDTO nach
|
||||
Aussage: Das System soll beim Auslösen der Schlussrechnungserstellung alle zu einem Auftrag gehörenden Anzahlungsrechnungen – einschließlich bereits abgeschlossener – vollständig auflösen und für die Weiterverarbeitung bereitstellen.
|
||||
Ergebnis: Liste vollständiger Anzahlungsrechnungs-DTOs zum Auftrag liegt der Schlussrechnungserstellung vor
|
||||
Belege:
|
||||
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Receipts/DownPayment/FinalInvoice/OrderToFinalInvoiceHelper.cs, Methode LoadRelatedDownPaymentInvoices() (Z. 27-47) - Begründung: Durchsetzende Stelle des Suchfilters inkl. expliziten Einschlusses abgeschlossener Anzahlungsrechnungen
|
||||
Prüfidee: Auftrag mit einer bereits abgeschlossenen und einer offenen Anzahlungsrechnung versehen und prüfen, dass LoadRelatedDownPaymentInvoices() beide zurückliefert
|
||||
Tracelinks: StRS-13
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - vollständige Erfassung aller Anzahlungen unabhängig vom Abschlussstatus ist für eine korrekte Schlussrechnung zwingend
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-4
|
||||
Titel: Mahnfähigkeit eines Belegs serverseitig aus Persistenzdaten ableiten
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (Mahnwesen)
|
||||
Vorbedingung: Mahnlauf wird für eine Menge fälliger Rechnungen vorbereitet
|
||||
Fakt: Die Spalten AK.Mahnstufe und AK.MahnStop am Rechnungskopf (RechKopf) werden 1:1 in DunningLevel/DunningStop der Belegsuche übernommen (InvoiceReceiptSearchConfiguration.cs Z. 86-87) und von DunningItemViewModel.EvaluateSelectionValidity() zur Ausschlussprüfung herangezogen; das bereinigte DueDate (Z. 56) ist Grundlage der Prüfung "Rechnung hat kein Fälligkeitsdatum"
|
||||
Aussage: Das System soll Mahnstufe, Mahnstopp und Fälligkeitsdatum als persistente Belegattribute führen und der Mahnlaufvorbereitung als konsistente, serverseitig ermittelte Datenbasis bereitstellen.
|
||||
Ergebnis: Mahnlaufvorbereitung erhält für jede Rechnung konsistente Mahnstufe/-stopp/-fälligkeit ohne clientseitige Neuberechnung
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/InvoiceReceiptSearchConfiguration.cs, Z. 56, 86-87 - Begründung: Durchsetzende Stelle der Datenableitung auf Serverseite, die die UI-Prüfung in DunningItemViewModel erst ermöglicht
|
||||
Prüfidee: AK.FaelligAm auf einen Platzhalterwert ≤2 setzen und prüfen, dass DueDate in der Belegsuche NULL liefert und der Beleg im Mahnlauf als "ohne Fälligkeitsdatum" ausgeschlossen wird
|
||||
Tracelinks: StRS-21
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - serverseitige, konsistente Datenbasis für den Mahnlauf ist Voraussetzung für ein rechtssicheres Mahnwesen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-5
|
||||
Titel: Nebenläufige Bearbeitung von Belegen durch Sperr- und Versionskennung absichern
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: System (Belegverwaltung)
|
||||
Vorbedingung: Zwei Benutzer öffnen denselben Beleg gleichzeitig
|
||||
Fakt: RechKopf führt sowohl LockUser (AK.LockUser, ausgewertet als LockedBy) als auch eine GUID-Spalte GUI3D (ausgewertet als ConcurrencyControlGuid) gemäß InvoiceReceiptSearchConfiguration.cs Z. 55, 78; zusätzlich werden CreatedThroughApplicationVersion/ChangedThroughApplicationVersion (Z. 83-84) je Beleg geführt
|
||||
Aussage: Das System soll parallele Bearbeitung desselben Belegs durch eine kombinierte Sperrbenutzer- und Versions-/GUID-Kennung erkennen und einen erneuten Speichervorgang bei zwischenzeitlicher Änderung durch einen anderen Benutzer verhindern.
|
||||
Ergebnis: Konkurrierende Änderungen an einem Beleg führen zu einer erkennbaren Konfliktmeldung statt stillem Überschreiben
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/InvoiceReceiptSearchConfiguration.cs, Z. 55, 78, 83-84 - Begründung: Persistente Felder LockUser und GUI3D belegen einen Sperr-/Konfliktmechanismus auf Datenebene; die konkrete Konfliktbehandlung beim Speichern (Vergleich/Abweisung) wurde innerhalb dieser Analyse nicht bis zur Schreibstelle zurückverfolgt
|
||||
Prüfidee: Beleg in zwei Sitzungen gleichzeitig öffnen, in Sitzung A speichern, danach in Sitzung B speichern und prüfen, dass Sitzung B einen Konflikt anhand der abweichenden GUID/des LockUser erkennt statt die Änderung aus A stillschweigend zu verwerfen
|
||||
Tracelinks: StRS-12
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Konflikterkennung bei Mehrbenutzerzugriff ist für ein Mehrbenutzer-ERP zwingend; Umsetzungsdetail im Zielsystem zu verifizieren
|
||||
Status: HYPOTHESE
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-6
|
||||
Titel: Pflichtangabe eines Ablaufdatums bei Erzeugung persönlicher API-Token
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (Personal-Access-Token-Verwaltung)
|
||||
Vorbedingung: Mitarbeiter erzeugt ein neues persönliches API-Token
|
||||
Fakt: CreateToken() (Z. 157-169) übernimmt ExpiresAt aus dem Erzeugungsdialog in das gespeicherte Token; kein Codepfad innerhalb dieser Klasse erzeugt ein Token ohne ExpiresAt-Wert
|
||||
Aussage: Das System soll bei der Erzeugung eines persönlichen API-Tokens zwingend ein Ablaufdatum erfassen und mit dem Token persistieren.
|
||||
Ergebnis: Jedes erzeugte Token trägt ein Ablaufdatum
|
||||
Belege:
|
||||
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/MyCentron/PersonalSettings/AccessTokens/PersonalAccessTokenSettingsViewModel.cs, Methode CreateToken() (Z. 157-169) - Begründung: Durchsetzende Stelle der Token-Erzeugung, die ExpiresAt aus dem Dialog übernimmt
|
||||
Prüfidee: Token-Erzeugungsdialog ohne Auswahl eines Ablaufdatums abschließen und prüfen, ob ein Standardwert gesetzt oder die Erzeugung verweigert wird
|
||||
Tracelinks: StRS-51
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - verpflichtendes Ablaufdatum begrenzt das Risiko dauerhaft gültiger, kompromittierter Token
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-7
|
||||
Titel: Ablaufende persönliche API-Token beim API-Zugriff serverseitig zurückweisen
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (Webservice-Authentifizierung, AccessTokenBL)
|
||||
Vorbedingung: API-Aufruf mit persönlichem Zugriffstoken trifft am Webservice ein
|
||||
Fakt: AccessTokenBL.ValidateToken() (Z. 377-419) hasht das übergebene Token (HashToken) und vergleicht ausschließlich den Hash gegen TokenHash in der DB (Z. 387-389); bei !token.IsActive (Z. 394-399) oder token.IsExpired (Z. 401-406) wird der Zugriff mit protokollierter Begründung ("Token ist deaktiviert"/"Token ist abgelaufen", AccessTokenLogActionType.ValidationFailed) abgelehnt; jeder erfolgreiche Aufruf wird zusätzlich mit apiMethod und ipAddress protokolliert (Z. 413-416) und die Funktion selbst ist lizenzpflichtig (LicenseManager.HasLicense(AccessTokenModule), Z. 382-383)
|
||||
Aussage: Das System soll beim API-Zugriff mit einem persönlichen Token dessen Hash gegen die gespeicherten, gehashten Token prüfen, deaktivierte und abgelaufene Token zurückweisen und jeden Validierungsversuch (erfolgreich wie fehlgeschlagen) mit IP-Adresse und aufgerufener Methode protokollieren.
|
||||
Ergebnis: Abgelaufenes oder deaktiviertes Token wird von der Webservice-Schicht mit Audit-Log-Eintrag abgelehnt; Token liegt nie im Klartext in der Datenbank
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, Methode ValidateToken() (Z. 377-419) - Begründung: Durchsetzende Stelle mit Hash-Vergleich, Aktiv-/Ablaufprüfung und lückenloser Protokollierung
|
||||
- [PRIMÄR] src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Interceptors/AuthenticateInterceptor.cs, Z. 51-58 - Begründung: Ruft bei fehlgeschlagener Ticket-Validierung ValidateToken() als zweiten Authentifizierungsweg für jeden mit [Authenticate] markierten API-Aufruf auf
|
||||
Prüfidee: Token mit ExpiresAt in der Vergangenheit gegen einen Webservice-Endpunkt verwenden und prüfen, dass der Aufruf abgelehnt und ein ValidationFailed-Logeintrag mit Grund "Token ist abgelaufen" erzeugt wird
|
||||
Tracelinks: StRS-51, SyRS-6
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Hash-Speicherung, Ablaufprüfung und lückenlose Protokollierung sind vorbildliche Sicherheitspraxis für das Zielsystem
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-10
|
||||
Titel: Duale API-Authentifizierung über Sitzungsticket oder Access-Token mit anwendungsbezogener Einschränkung
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (Webservice-Authentifizierung)
|
||||
Vorbedingung: Beliebiger, mit [Authenticate] markierter API-Aufruf trifft ein
|
||||
Fakt: AuthenticateInterceptor.InterceptExecution() (Z. 22-61) validiert zunächst als Sitzungsticket (ValidateTicketAndSetReturnValue → AuthenticationTicketBL.GetAuthTicketInfo, Z. 25-48 in AuthenticationTicketBL.cs); bei gültigem Ticket wird zusätzlich geprüft, ob die aufrufende Anwendung (ApplicationKind) für die Methode zugelassen ist (Z. 38) und ob ein Web-Account-Ticket die Methode aufrufen darf (Z. 39, AllowWebAccountLogin); schlägt die Ticket-Prüfung fehl, wird als zweiter Weg ein Access-Token geprüft (Z. 52-57), wobei Access-Token laut Code ausdrücklich KEINE Anwendungseinschränkung unterliegen; ein Kommentar im Code (Z. 33-37) hält fest, dass das Modell nur "diese Anwendung darf aufrufen" abbildet, nicht aber "diese Anwendung darf nur diese Methoden aufrufen"
|
||||
Aussage: Das System soll jeden API-Aufruf entweder über ein anwendungsbezogen eingeschränktes Sitzungsticket oder über ein Access-Token ohne Anwendungseinschränkung authentifizieren und dabei Web-Account-Tickets standardmäßig von internen Methoden ausschließen.
|
||||
Ergebnis: Nicht authentifizierte oder unzulässige Aufrufe werden mit einheitlicher Fehlermeldung ohne Preisgabe des genauen Fehlgrundes abgewiesen
|
||||
Belege:
|
||||
- [PRIMÄR] src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Interceptors/AuthenticateInterceptor.cs, Z. 22-61 - Begründung: Durchsetzende Stelle der gesamten API-Authentifizierung inkl. der vom Entwickler selbst im Code dokumentierten Modellgrenze
|
||||
Prüfidee: Ticket einer für Methode X nicht zugelassenen Anwendung verwenden und prüfen, dass der Aufruf mit "You don't have the permission..." abgewiesen wird; anschließend mit einem Access-Token dieselbe Methode aufrufen und die fehlende Anwendungseinschränkung bestätigen
|
||||
Tracelinks: StRS-62, SyRS-7
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Zwei-Wege-Authentifizierung ist sinnvoll; die vom Entwickler selbst dokumentierte Lücke (keine methodenscharfe Einschränkung für Access-Token/bestimmte Anwendungen) ist im Zielsystem gezielt zu schließen (z. B. Scopes je Access-Token)
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-8
|
||||
Titel: Serverseitige Rechteprüfung mit benutzerbezogenem Cache
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (Rechtesystem, Centron.BL)
|
||||
Vorbedingung: Geschützte Funktion wird aufgerufen
|
||||
Fakt: HasUserRight() cacht das Ergebnis von GetAllAppRightsFromUser() unter dem Schlüssel "AllRightsFromAppUser{appUserI3D}" (Z. 646); ein Aufruf, der den Cache nach einer Rechteänderung gezielt invalidiert, wurde innerhalb dieser Analyse nicht lokalisiert
|
||||
Aussage: Das System soll die Rechte eines Benutzers serverseitig prüfen und dabei zur Performanceoptimierung cachen; Änderungen an der Gruppenzuordnung oder Gruppenrechten sollen sich zeitnah auf bereits angemeldete Sitzungen auswirken.
|
||||
Ergebnis: Rechteprüfung ist performant; Rechteänderungen wirken ohne unangemessene Verzögerung
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Z. 646 (Cache.GetOrAdd) - Begründung: Durchsetzende Stelle des Caching-Mechanismus
|
||||
Prüfidee: Benutzer ein Recht entziehen, während dessen Sitzung aktiv ist, und prüfen, wie lange die alte Berechtigung noch wirksam bleibt
|
||||
Tracelinks: StRS-62
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Caching ist sinnvoll, Invalidierungsstrategie bei Rechteänderung im Zielsystem explizit zu spezifizieren
|
||||
Status: HYPOTHESE
|
||||
```
|
||||
|
||||
```
|
||||
ID: SyRS-9
|
||||
Titel: Administrator-Gruppe vor Entzug systemkritischer Rechte schützen
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: System (Rechtesystem)
|
||||
Vorbedingung: Administrator ändert Rechte der Administrator-Gruppe selbst
|
||||
Fakt: SaveAndAssignGroupToRight()/RemoveAssignGroupToRight() (Z. 261-299) prüfen bei IsAdministratorGroup(group) zusätzlich GetAssignableAdminRightI3Ds() und verweigern die Änderung (return false), wenn das gewählte Recht nicht in dieser Freigabeliste enthalten ist
|
||||
Aussage: Das System soll verhindern, dass systemkritische Rechte von der Administrator-Gruppe entfernt oder ihr zusätzliche, nicht freigegebene Rechte zugewiesen werden, um ein versehentliches Aussperren aller Administratoren zu verhindern.
|
||||
Ergebnis: Änderungsversuch an nicht freigegebenen Rechten der Administrator-Gruppe wird abgewiesen
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Z. 266-271 und 284-289 - Begründung: Durchsetzende Stelle, die Änderungen an der Administrator-Gruppe auf eine Freigabeliste beschränkt
|
||||
Prüfidee: Versuch, ein nicht in GetAssignableAdminRightI3Ds() enthaltenes Recht von der Administrator-Gruppe zu entfernen, und prüfen, dass RemoveAssignGroupToRight() false liefert
|
||||
Tracelinks: StRS-62
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Schutz vor Selbstaussperrung der Administration ist eine bewährte Sicherheitsmaßnahme
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
+139
@@ -0,0 +1,139 @@
|
||||
# Traceability-Tabelle
|
||||
|
||||
Konsolidierte Forward-/Backward-Traceability zwischen StRS, SyRS und SwRS. Jede StRS-Zeile ist vorhanden (Mindestabdeckung, ein StRS je Inventarmodul aus `Analysebericht.md`). Wo eine Anforderung in dieser Iteration bis auf SyRS- und/oder SwRS-Ebene vertieft wurde (Schritt 0c, Risikomodule), sind die zugehörigen IDs eingetragen; die übrigen Zeilen sind auf StRS-Ebene belegt, aber in dieser Iteration nicht weiter auf SyRS/SwRS heruntergebrochen (siehe Selbstbewertung). Artefaktbeleg = jeweils der primäre Beleg der am weitesten unten liegenden Ebene der Zeile.
|
||||
|
||||
## A. Vertiefte Ketten (StRS ↔ SyRS ↔ SwRS)
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (primär) |
|
||||
|---------|---------|---------|--------------------------|
|
||||
| StRS-1 (Sonderpreise/Produktmatrix) | SyRS-2 (Duplikatprüfung Sonderpreis) | SwRS-3 (Update statt Duplikat) | Receipts/PositionToSpecialPrice/PositionToSpecialPriceViewModel.cs Z. 80-131 |
|
||||
| StRS-2 (Pflichtfelder Kundenanlage) | SyRS-1 (Pflichtfeld-Set prüfen) | SwRS-1 (CanAccept-Gate) | Finances/Crm/MakeCustomerViewModel.cs Z. 244-293 |
|
||||
| StRS-3 (Kampagnen-Status/Rechte) | – | SwRS-2 (Rechteabhängige Kampagnenfunktionen) [HYPOTHESE] | Finances/Campaigns/CampaignMainViewModel.cs Z. 31-40 |
|
||||
| StRS-12 (Belegkette Angebot–Rechnung) | SyRS-5 (Nebenläufigkeitsschutz) [HYPOTHESE] | – | InvoiceReceiptSearchConfiguration.cs Z. 55, 78, 83-84 |
|
||||
| StRS-13 (Anzahlung → Schlussrechnung) | SyRS-3 (Anzahlungsrechnungen bereitstellen) | – | DownPayment/FinalInvoice/OrderToFinalInvoiceHelper.cs Z. 27-47 |
|
||||
| StRS-14 (Steuersatzänderung) | – | SwRS-4 (Länderspezifische Steuersatzliste) | Receipts/ChangeTaxRate/ChangeTaxRateViewModel.cs Z. 41-53 |
|
||||
| StRS-21 (Mahnlauf/Mahnstopp) | SyRS-4 (Mahnfähigkeit serverseitig) | – | Dunning/Common/DunningItemViewModel.cs Z. 445-469 |
|
||||
| StRS-22 (Offene Posten) | – | SwRS-5 (OpenPrice-Formel) | InvoiceReceiptSearchConfiguration.cs Z. 71-72 |
|
||||
| StRS-23 (Zahlungserfassung) | – | SwRS-5 (OpenPrice-Formel, gemeinsam mit StRS-22) | Payments/PaymentsReceiptViewModel.cs Z. 39-46 |
|
||||
| StRS-51 (Personal-Access-Token) | SyRS-6 (Pflicht-Ablaufdatum), SyRS-7 (serverseitige Ablaufprüfung) | – | AccessTokenBL.ValidateToken() Z. 377-419 |
|
||||
| StRS-62 (Gruppenbasierte Rechte) | SyRS-8 (Rechteprüfung+Cache) [HYPOTHESE-Anteil], SyRS-9 (Admin-Gruppen-Schutz), SyRS-10 (duale API-Authentifizierung) | SwRS-6 (Sichtrus/Sichmemb-Modell), SwRS-7 (getrennte Web-Rechte) | AppRightsBL.cs Z. 644-691, 261-299 |
|
||||
| StRS-85 (Passwortverwaltung AES) | – | SwRS-8 (AES-Verschlüsselung Master-Key) | PasswordManagerBL.cs Z. 700, 1051-1052, 1179 |
|
||||
| StRS-98 (Web-API-Authentifizierung) | SyRS-10 (duale Authentifizierung, gemeinsam mit StRS-62), SyRS-7 | – | AuthenticateInterceptor.cs Z. 22-61 |
|
||||
| StRS-101 (Nexus Kundenportal/WebCart) | – | SwRS-7 (getrennte Web-Rechte, gemeinsam mit StRS-62) | Management/WebAccount/Model/WebRightNode.cs |
|
||||
|
||||
## B. StRS-Anforderungen ohne separate SyRS-/SwRS-Formalisierung in dieser Iteration
|
||||
|
||||
Diese Anforderungen sind auf StRS-Ebene mit eigenem Artefaktbeleg (siehe StRS.md) belegt; der Artefaktbeleg unten verweist auf den Modulpfad aus dem Inventar (`Analysebericht.md`, Schritt 0). Eine Vertiefung auf SyRS/SwRS ist gemäß Selbstbewertung für die dort genannten Module priorisiert nachzuholen.
|
||||
|
||||
| StRS-ID | Titel (Kurzform) | Artefaktbeleg (Modulpfad lt. Inventar) |
|
||||
|---------|-------------------|------------------------------------------|
|
||||
| StRS-4 | CRM-Stammdatenlisten (Counters) | Modules/Finances/MasterDataLists |
|
||||
| StRS-5 | Vertragsverwaltung | Modules/Finances/Contracts |
|
||||
| StRS-6 | Projektverwaltung (Finanzsicht) | Modules/Finances/Projects |
|
||||
| StRS-7 | Zählerstandserfassung MPS | Modules/Finances/DeviceClickCounter |
|
||||
| StRS-8 | PLM | Modules/PLM |
|
||||
| StRS-9 | Zahler-/Kostenstellenverwaltung | Modules/PayersAndCostCenter |
|
||||
| StRS-10 | Projektpreisimport | Modules/ProjectPriceImport |
|
||||
| StRS-11 | Projektmanagement (Workload) | Modules/ProjectManagement |
|
||||
| StRS-15 | Provisionsermittlung | Modules/Finances/Receipts/Provision |
|
||||
| StRS-16 | Web-Angebote | Modules/Finances/Receipts/WebOffer |
|
||||
| StRS-17 | EDI-Auftragsverbuchung | Modules/Finances/Receipts/EdiOrderbooking |
|
||||
| StRS-18 | Automatisierte Rechnungserstellung | Modules/Finances/AutomatedBilling |
|
||||
| StRS-19 | Pauschalabrechnung | Modules/Finances/FlatrateBilling |
|
||||
| StRS-20 | Zeit-/Leistungsabrechnung | Modules/Finances/TimerBilling |
|
||||
| StRS-24 | Kontenverwaltung | Modules/Finances/AccountManagement |
|
||||
| StRS-25 | Warenausgangszahlungen | Modules/Warehousing/OutcomingPayments |
|
||||
| StRS-26 | Kassensystem-Anbindung | Modules/Warehousing/AccountSystems |
|
||||
| StRS-27 | Artikelstammdaten/AutoEOL | Modules/Warehousing/ArticleManagement |
|
||||
| StRS-28 | Artikelimport | Modules/Warehousing/ArticleImport |
|
||||
| StRS-29 | Mengeneinheiten (UN/ECE) | Modules/Warehousing/ArticleUnitManagement |
|
||||
| StRS-30 | Barcode-Verwaltung | Modules/Warehousing/BarcodeManagement |
|
||||
| StRS-31 | Kommissionierung | Modules/Warehousing/Commissioning |
|
||||
| StRS-32 | Kommissionsware/Konsignation | Modules/Warehousing/Commissions |
|
||||
| StRS-33 | Inventur | Modules/Warehousing/Inventory |
|
||||
| StRS-34 | Warengruppenverwaltung | Modules/Warehousing/MaterialGroupManagement |
|
||||
| StRS-35 | Artikelsuche | Modules/Warehousing/SearchArticle |
|
||||
| StRS-36 | Lieferantensuche | Modules/Warehousing/SupplierSearch |
|
||||
| StRS-37 | Logistikeinstellungen | Modules/Logistic |
|
||||
| StRS-38 | EDI-Bestellwesen | Modules/Purchasing/EDIManagement |
|
||||
| StRS-39 | Bestellvorschlagsliste | Modules/Purchasing/OrderSuggestionList |
|
||||
| StRS-40 | Einkaufseinstellungen | Modules/Purchasing/PurchaseSettings |
|
||||
| StRS-41 | Reisekostenabrechnung | Modules/Purchasing/TravelExpense |
|
||||
| StRS-42 | Fertigungsauftragsverwaltung | Modules/Production/ProductionOrder |
|
||||
| StRS-43 | Maschinenverwaltung | Modules/Production/MachineManagement |
|
||||
| StRS-44 | RMA-Abwicklung | Modules/Rma |
|
||||
| StRS-45 | Ticketverwaltung | Modules/Helpdesk/TicketDetails |
|
||||
| StRS-46 | Helpdesk-Dashboard | Modules/Helpdesk/Dashboard |
|
||||
| StRS-47 | Erwartete Wartungsereignisse | Modules/Helpdesk/ExpectedEvents |
|
||||
| StRS-48 | Helpdesk-Einstellungen | Modules/Helpdesk/Settings |
|
||||
| StRS-49 | Helpdesk Selbstbedienung | Modules/Helpdesk/SendSelfCareForm |
|
||||
| StRS-50 | CentronInspectors (Dateninspektion) | Modules/MyCentron/CentronInspectors |
|
||||
| StRS-52 | MyDay | Modules/MyCentron/MyDay |
|
||||
| StRS-53 | MyCentron-Dashboard | Modules/MyCentron/Dashboard |
|
||||
| StRS-54 | ToDo-Liste | Modules/MyCentron/TodoList |
|
||||
| StRS-55 | Telefonie-Integration | Modules/MyCentron/Telephony |
|
||||
| StRS-56 | Supremo-Fernwartung | Modules/MyCentron/Supremo |
|
||||
| StRS-57 | Verkaufsstatistik | Modules/Statistics/SaleStatistics |
|
||||
| StRS-58 | Management-Informationen | Modules/Statistics/ManagementInfo |
|
||||
| StRS-59 | MSP-Statistiken | Modules/Statistics/MspStatistics |
|
||||
| StRS-60 | Mitarbeiteranalyse | Modules/Statistics/EmployeeAnalytics |
|
||||
| StRS-61 | Reportverwaltung | Modules/Reports/ReportManagement |
|
||||
| StRS-63 | Mitarbeiterverwaltung/AD-Import | Modules/Administration/EmployeeManagement |
|
||||
| StRS-64 | Mandantenverwaltung | Modules/Administration/MandatorManagement |
|
||||
| StRS-65 | DSGVO/AVV/Löschrechte | Modules/Administration/DSGVO |
|
||||
| StRS-66 | Systemweite Token-Richtlinie | Modules/Administration/Settings |
|
||||
| StRS-67 | Verbindungs-/Schnittstelleneinstellungen | Modules/Administration/WebServiceSettings |
|
||||
| StRS-68 | KI-Mailvorlagen | Modules/Administration/MailTemplates |
|
||||
| StRS-69 | PDF-Signatur/KI-Textbausteine | Modules/Administration/PdfSigning |
|
||||
| StRS-70 | Stundensätze/Zuschläge | Modules/Administration/HourlySurchargeRates |
|
||||
| StRS-71 | Eskalationseinstellungen | Modules/Administration/EscalationsSettings |
|
||||
| StRS-72 | Länderverwaltung | Modules/Administration/CountryManagement |
|
||||
| StRS-73 | SEPA-Mandate (Signatur-Workflow) | Modules/Administration/SepaContract |
|
||||
| StRS-74 | Externe Werkzeuge | Modules/Administration/ExternalTools |
|
||||
| StRS-75 | WebCart-Konfiguration | Modules/Administration/WebCart |
|
||||
| StRS-76 | Sonstige Prozesseinstellungen | Modules/Administration/SendDeliveryListShippingConfirmationSettings |
|
||||
| StRS-77 | Log-Betrachter | Modules/Administration/LogViewer |
|
||||
| StRS-78 | Dienste-Verwaltung | Modules/Administration/Services |
|
||||
| StRS-79 | Bankumsätze/IBAN-Klärung | Modules/OnlineBanking/AccountTransactions |
|
||||
| StRS-80 | OnlineBanking-Konfiguration | Modules/OnlineBanking/AccountTransactions/Converter |
|
||||
| StRS-81 | OnlineBanking-Verbindungsdialog | Modules/OnlineBanking/ConnectionDialog |
|
||||
| StRS-82 | KI-Chat-Assistent | Modules/ArtificialIntelligence |
|
||||
| StRS-83 | Kundenumfragen | Modules/Survey |
|
||||
| StRS-84 | Massenänderungen | Modules/Massenupdates |
|
||||
| StRS-86 | Kalendersynchronisation | Modules/Calendar |
|
||||
| StRS-87 | QM-Prüfgründe | Modules/QM |
|
||||
| StRS-88 | Telekom-DIVE-Export (UI) | Modules/TelekomDive |
|
||||
| StRS-89 | Startdashboard | Modules/Dashboard |
|
||||
| StRS-90 | UI-Layoutprofile | Modules/Gui |
|
||||
| StRS-91 | MSP-Lizenzabgleich | Modules/Global/MSPLicensesCompare |
|
||||
| StRS-92 | Backend-Kernschicht | backend/Centron.BL |
|
||||
| StRS-93 | EDI-Lieferantenanbindungen | backend/Centron.Gateway/EDI_Also |
|
||||
| StRS-94 | Banking-Gateway Backend | backend/Centron.Gateway/OnlineBanking |
|
||||
| StRS-95 | MSP-Collector-Gateway | backend/Centron.Gateway/MspCollector |
|
||||
| StRS-96 | E-Rechnungsformate (ZUGFeRD) | backend/Centron.Gateway/ZUGFeRD21_Extended |
|
||||
| StRS-97 | Portal-Gateway | backend/Centron.Gateway/Portal |
|
||||
| StRS-99 | Lizenz-/Verbindungsmanager | webservice/c-entron.misc.ConnectionManager |
|
||||
| StRS-100 | ServiceBoard (Web-Kanban) | nexus/CentronNexus/ServiceBoard |
|
||||
| StRS-102 | Web-Fertigungsauftragsverwaltung | nexus/CentronNexus/ProductionOrderManagement |
|
||||
| StRS-103 | Nexus-Verwaltung/WebRights | nexus/CentronNexus/Management |
|
||||
| StRS-104 | Web-Dokumentensignatur | nexus/CentronNexus/DocumentSigning |
|
||||
| StRS-105 | Outlook-Add-in | nexus/CentronNexus.OutlookAddIn |
|
||||
| StRS-106 | Produktdaten-APIs | apis/Centron.APIs.IcecatDataAccess |
|
||||
| StRS-107 | FinAPI-Bankanbindung | apis/Centron.APIs.FinAPI |
|
||||
| StRS-108 | ebInterface (Österreich) | apis/Centron.Api.EbInterface |
|
||||
| StRS-109 | Versanddienstleister-APIs | apis/Centron.Api.Gls |
|
||||
| StRS-110 | docuFORM PDF-Generierung | Modules/DataExchange/DocuForm |
|
||||
| StRS-111 | Adress-/Kontoimport-Validierung | Modules/DataExchange/DataImport |
|
||||
| StRS-112 | Buchhaltungsexport | Modules/DataExchange/BookKeeping |
|
||||
| StRS-113 | DATEV-Anbindung | Modules/DataExchange/DatevOnline2020 |
|
||||
| StRS-114 | SEPA-Zahlungsdatei (pain.008) | backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa |
|
||||
| StRS-115 | Telekom-DIVE (Austauschebene) | Modules/DataExchange/TelekomDive |
|
||||
| StRS-116 | Datenexport (allgemein) | Modules/DataExchange/DataExport |
|
||||
| StRS-117 | Sonstige Schnittstellen | Modules/DataExchange/SupplierOrderPerBranch |
|
||||
| StRS-118 | Deployment & Betrieb | docker/, azure/ |
|
||||
|
||||
## Hinweise zur Lesart
|
||||
|
||||
- Ein „–" in Spalte SyRS/SwRS bedeutet: kein zugehöriger Datensatz auf dieser Ebene in dieser Iteration.
|
||||
- `[HYPOTHESE]`-Kennzeichnungen in Abschnitt A sind identisch mit `Hypothesen.md` zu lesen.
|
||||
- Rückwärtsverknüpfung (SwRS→SyRS→StRS, SyRS→StRS) ist in jedem einzelnen Anforderungsblock über das Feld `Tracelinks:` zusätzlich dezentral hinterlegt (siehe StRS.md/SyRS.md/SwRS.md) und hier nur konsolidiert zusammengeführt.
|
||||
+165
@@ -0,0 +1,165 @@
|
||||
# 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-27T09:12:15.0639875+02:00
|
||||
- **Endzeit:** 2026-08-27T09:59:53.4377636+02:00
|
||||
- **Dauer gesamt:** 0:47:38 (`duration_ms` 0:47:35; API: 0:46:19)
|
||||
— **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-sonnet-5`
|
||||
- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 38.429.213 Tokens (99.98 %), `claude-haiku-4-5-20251001` 6.965 Tokens (0.02 %)
|
||||
- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
|
||||
- **Effort:** `max` (per `--effort max` gesetzt)
|
||||
- **Laufverzeichnis-ID:** `v7.0.0-da3c`
|
||||
- **Ablage:** `Iteration 3/claude-sonnet-5/solo/max/`
|
||||
- **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 | 290 |
|
||||
| Output-Tokens | 284.916 (davon 95.123 Thinking-Tokens) |
|
||||
| Cache-Write-Tokens | 457.428 |
|
||||
| Cache-Read-Tokens | 37.686.579 |
|
||||
| Agent-Turns | 217 |
|
||||
|
||||
### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
|
||||
| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
|
||||
|---|---:|---:|---:|
|
||||
| Input-Tokens | 290 | 6.945 | 7.235 |
|
||||
| Output-Tokens | 284.916 | 20 | 284.936 |
|
||||
| Cache-Write-Tokens | 457.428 | 0 | 457.428 |
|
||||
| Cache-Read-Tokens | 37.686.579 | 0 | 37.686.579 |
|
||||
| **Tokens gesamt** | **38.429.213** | **6.965** | **38.436.178** |
|
||||
|
||||
**Tokens gesamt: 38.436.178** — 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 | 118 | 86,8 % |
|
||||
| SyRS | 10 | 7,4 % |
|
||||
| SwRS | 8 | 5,9 % |
|
||||
| **Gesamt** | **136** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 100 | 73,5 % |
|
||||
| Schnittstelle | 19 | 14,0 % |
|
||||
| Sicherheit | 10 | 7,4 % |
|
||||
| Daten | 5 | 3,7 % |
|
||||
| nicht-funktional | 2 | 1,5 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 166 |
|
||||
| davon `PRIMÄR` | 51 (30,7 %) |
|
||||
| davon `SEKUNDÄR` | 60 (36,1 %) |
|
||||
| davon `KONTEXT` | 55 (33,1 %) |
|
||||
| Belege je Anforderung (Median) | 1,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 46 (33,8 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 129 | 94,9 % |
|
||||
| workaround | 2 | 1,5 % |
|
||||
| sonderfall | 4 | 2,9 % |
|
||||
| veraltet | 1 | 0,7 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 130 | 95,6 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 6 | 4,4 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 23 | 16,9 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 2 | 1,5 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 7 von 33 ungedeckt: StRS-25, StRS-31, StRS-72, StRS-91, StRS-92, StRS-99, StRS-102 |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 136 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 81 von 136 mit Tracelinks (59,6 %) |
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
|
||||
- **Session-ID:** `4a31e82c-b2b8-43a5-9a37-d3dc63f94b58`
|
||||
- **Permission-Denials:** 0 – **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` | 39.319 B |
|
||||
| `Glossar.md` | 5.940 B |
|
||||
| `Hypothesen.md` | 4.425 B |
|
||||
| `StRS.md` | 168.024 B |
|
||||
| `SwRS.md` | 13.076 B |
|
||||
| `SyRS.md` | 18.243 B |
|
||||
| `Traceability.md` | 11.369 B |
|
||||
|
||||
- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
|
||||
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
|
||||
|
||||
## Anmerkungen/Auffälligkeiten
|
||||
|
||||
<!-- ANMERKUNGEN -->
|
||||
+1
@@ -0,0 +1 @@
|
||||
{"is_error":false,"duration_api_ms":2779209,"num_turns":217,"stop_reason":"end_turn","session_id":"4a31e82c-b2b8-43a5-9a37-d3dc63f94b58","total_cost_usd":12.223812800000006,"usage":{"input_tokens":290,"cache_creation_input_tokens":457428,"cache_read_input_tokens":37686579,"output_tokens":284916,"output_tokens_details":{"thinking_tokens":95123},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":457428,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":910,"cache_read_input_tokens":456874,"cache_creation_input_tokens":554,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":554},"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-sonnet-5":{"inputTokens":290,"outputTokens":284916,"cacheReadInputTokens":37686579,"cacheCreationInputTokens":457428,"webSearchRequests":0,"costUSD":12.216767800000005,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"completed","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":null,"result":"The reverse requirements engineering specification for the c-entron ERP-Suite is complete. All seven deliverables are in `Ergebnisse/`:\n\n**Coverage achieved:**\n- **Modulinventar (Schritt 0):** 118 modules identified across the entire codebase (WPF desktop client, backend BL/DAO, webservice API, Nexus web frontend, external API integrations, data-exchange connectors, deployment) — 0 modules left unanalyzed\n- **136 requirements total:** 118 StRS + 10 SyRS + 8 SwRS, with full forward/backward traceability\n- **Risk-based deepening (Schritt 0c):** 14 modules fully deepened across all three levels — rights management (found the actual group-based RBAC enforcement in `AppRightsBL.HasUserRight`), password vault AES encryption, dual ticket/access-token API authentication, dunning-stop logic, open-items/payment formulas, SEPA/DSGVO signature workflows\n- **29 risk-relevant requirements** (security, billing, permissions) individually checked: 23 carry a PRIMÄR beleg, 6 are honestly marked `[HYPOTHESE]`\n- **23 consolidation candidates** found with concrete evidence (e.g., a literal copy-paste artifact: the SEPA-mandate settings class still carries internal field names like `_declinedOrderProcessingContractSubject` left over from the DSGVO-AVV class it was cloned from)\n- **Self-check caught and fixed 3 rule violations** during the consistency pass — three security/billing requirements had only SEKUNDÄR evidence but were marked `belegt`; corrected to `HYPOTHESE` before finalizing\n\nThe codebase itself was only read, never modified (verified via `git status`).\n\nOne thing worth flagging to you directly: 86 of the 118 modules are at \"flach\" depth (one requirement, existence-level evidence only) — that's the explicit breadth-first tradeoff the prompt asked for, but it means modules like the 794-file `Finances/Receipts` core or the 320-file `ArticleManagement` still have far more to extract in a follow-up pass. That's called out concretely in the self-assessment.","ttft_ms":7192,"ttft_stream_ms":1124,"time_to_request_ms":36,"type":"result","duration_ms":2855005,"uuid":"0912e717-c040-47a4-8d5e-381952f58a7d","queued_turn_count":0}
|
||||
+2616
File diff suppressed because it is too large
Load Diff
+65
@@ -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 | 118 | 86,8 % |
|
||||
| SyRS | 10 | 7,4 % |
|
||||
| SwRS | 8 | 5,9 % |
|
||||
| **Gesamt** | **136** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 100 | 73,5 % |
|
||||
| Schnittstelle | 19 | 14,0 % |
|
||||
| Sicherheit | 10 | 7,4 % |
|
||||
| Daten | 5 | 3,7 % |
|
||||
| nicht-funktional | 2 | 1,5 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 166 |
|
||||
| davon `PRIMÄR` | 51 (30,7 %) |
|
||||
| davon `SEKUNDÄR` | 60 (36,1 %) |
|
||||
| davon `KONTEXT` | 55 (33,1 %) |
|
||||
| Belege je Anforderung (Median) | 1,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 46 (33,8 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 129 | 94,9 % |
|
||||
| workaround | 2 | 1,5 % |
|
||||
| sonderfall | 4 | 2,9 % |
|
||||
| veraltet | 1 | 0,7 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 130 | 95,6 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 6 | 4,4 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 23 | 16,9 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 2 | 1,5 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 7 von 33 ungedeckt: StRS-25, StRS-31, StRS-72, StRS-91, StRS-92, StRS-99, StRS-102 |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 136 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 81 von 136 mit Tracelinks (59,6 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+177
@@ -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-sonnet-5\solo\max\02_Lauf_2026-08-27_091214_v7.0.0-da3c\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-27T09:59:53.4377636+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-27T09:12:15.0639875+02:00
|
||||
Reference in New Issue
Block a user