more runs before cline
This commit is contained in:
Christoph Schwörer
+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
|
||||
Reference in New Issue
Block a user