Effortvergleich high gegen max: Effort wirkt ueber Delegation
Dieselbe TensorX-Matrix ein zweites Mal bei hoechstem Effort. Zwoelf gueltige Laeufe, 2.116 Anforderungen, 127,6 Mio. Tokens, hochgerechnet $10,53 aus der Preisliste vom 02.09.2026. Befund: In den nicht-delegierenden Zellen bewegt sich der Ertrag zwischen minus 18 und plus 44 Prozent ohne erkennbare Richtung - in der Groessenordnung der Streuung. Der eine deutliche Ausschlag ist GLM in custom mit plus 122 Prozent, erreicht mit 78 statt 30 Subagenten. Der hoehere Denkaufwand schlaegt sich in mehr Zerlegung nieder, und die traegt den Ertrag, nicht der Denkaufwand als solcher. Qwens custom-Zelle hat sich qualitativ erholt: bei high 61 Prozent ohne Beleg und 40 Prozent Hypothesen, bei max 3 Prozent ohne Beleg und 96 Prozent Primaerbeleg. Der Einbruch war ein Laufmerkmal, kein Modellmerkmal - ein weiterer Beleg, dass n gleich 1 je Zelle nicht traegt. Skill 13.2.0: analyse-anforderungen.py toleriert jetzt vier Markdown-Fassungen der Feldvorgabe. Jedes der vier eingesetzten Modelle formatierte sie anders, und jede Fassung wurde zunaechst mit null Anforderungen gezaehlt, obwohl Belege und Pruefideen vollstaendig vorlagen. Das ist ein Befund ueber den Versuchsaufbau: Die Formatvorgabe ist fuer Menschen eindeutig, fuer maschinelle Auswertung nicht. Regressionsprobe an sieben Laeufen unveraendert. _matrix.ps1 nimmt zusaetzlich -Effort und -Modi fuer einzelne Zellen. Ein Lauf fiel durch Standby des Rechners aus und wurde wiederholt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Christoph Schwörer
co-authored by
Claude Opus 5
Claude Opus 5
parent
e2c3a0e8f8
commit
08d90f1ccb
+1
-1
@@ -10,7 +10,7 @@
|
||||
- **Endzeit:** 2026-09-02T15:56:15.4515645+02:00
|
||||
- **Dauer gesamt:** 01:52:32 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
|
||||
- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
|
||||
- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
|
||||
- **Codebasis-Commit:** `e2c3a0e8f81d005161dde733f7e4b08f581e3468` (vor dem Lauf dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
[2026-09-03T14:35:27.113722+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-03_163525_v13.0.0-927d\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-03_163525_v13.0.0-927d\Ergebnisse)
|
||||
[2026-09-03T14:35:27.261573+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=custom; Effort=max (uebergeben=True); Stall-Timeout=0s
|
||||
[2026-09-04T06:01:35.519836+00:00] Maximale Laufzeit von 28800 Sekunden ueberschritten; Prozessbaum wird beendet
|
||||
[2026-09-04T06:01:41.053481+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-04T06:01:56.599161+00:00] OpenCode export: Exporting session: ses_f984dc374ffe9HG3m7zYKN0Crs
|
||||
[2026-09-04T06:01:56.634770+00:00] Ende: Exitcode=1; Status=aborted; Turns=8; Tokens=119694; Dateien=1; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-03_163525_v13.0.0-927d\RawResult.json
|
||||
+116
@@ -0,0 +1,116 @@
|
||||
# Analysebericht
|
||||
|
||||
Reverse Requirements Engineering – c-entron ERP-Suite – Spezifikation nach ISO/IEC/IEEE 29148:2018.
|
||||
|
||||
Dieser Bericht entsteht im Lauf. Er enthält: Modulinventar (Schritt 0), Abdeckungstabelle, Arbeitsteilung/Dokumentation der Beauftragung, Konsistenzcheck, Selbstbewertung und bekannte Lücken.
|
||||
|
||||
## Arbeitsteilung und Zuständigkeiten (vorgegeben)
|
||||
|
||||
| Teilaufgabe | Vorgesehener Bearbeiter |
|
||||
|---|---|
|
||||
| Modulinventar (Schritt 0) | modulinventar |
|
||||
| Faktenerhebung zu einem Modulausschnitt (Schritte 2–4) | faktenermittler |
|
||||
| Formulierung der StRS-Anforderungen | strs-autor |
|
||||
| Formulierung der SyRS-Anforderungen | syrs-autor |
|
||||
| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
|
||||
| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
|
||||
| Prüfung des Gesamtbestands an den Nahtstellen | iso29148-orchestrator |
|
||||
| Konsistenzcheck des fertigen Anforderungssatzes | konsistenzpruefer |
|
||||
|
||||
Zuschnitt, Anzahl der Aufträge, Reihenfolge und Tiefe sind frei und werden in diesem Abschnitt am Laufende dokumentiert.
|
||||
|
||||
## ID-Bereiche (vorab vergeben, überschneidungsfrei und lückenlos)
|
||||
|
||||
- StRS-Bereich: `StRS-1` … `StRS-200` (Reservierung; tatsächlich genutzt bis `StRS-<N>`).
|
||||
- SyRS-Bereich: `SyRS-1` … `SyRS-250`.
|
||||
- SwRS-Bereich: `SwRS-1` … `SwRS-350`.
|
||||
|
||||
Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Ausschnitt.
|
||||
|
||||
## Schritt 0 – Modulinventar
|
||||
|
||||
Erstellt vom vorgesehenen Bearbeiter `modulinventar`. Bezugsgröße für die Abdeckung; darf ergänzt, aber nicht gekürzt werden. 79 Module (52 fachlich, 27 technisch); zugeordnete Quelldateien 16.176 von 16.554; Rest = Testprojekte (bewusst kein Fachmodul, 378 Dateien).
|
||||
|
||||
| ID | Modul | Art | Pfad | Aufgabe |
|
||||
|---|---|---|---|---|
|
||||
| M001 | WPF-Anwendungsshell & Modulframework | technisch | src/centron/Centron.WPF.UI (Shell, ohne Modules/Services) | Startet den WPF-Client, registriert/steuert alle Fachmodule, stellt Shell-Dienste. |
|
||||
| M002 | Datenzugriffs-Logicschicht (ILogic/BL/WS) | technisch | src/centron/Centron.WPF.UI/Services | Kapselt Moduldoppelpfad Datenzugriff je Fachgebiet (BL-/WS-Implementierung). |
|
||||
| M003 | WPF-Erweiterungsbibliothek | technisch | src/centron/Centron.WPF.UI.Extension | Basis-Framework für externe WPF-Erweitermodule. |
|
||||
| M004 | Administration (UI) | fachlich | src/centron/Centron.WPF.UI/Modules/Administration | Mandanten, Mitarbeiter, Rechte, Lizenzen, Mailvorlagen, Einstellungen. |
|
||||
| M005 | Adressen/CRM (UI) | fachlich | .../Modules/Finances/{Crm,AccountManagement,Projects} | Kunden-/Lieferantenadressen, CRM-Aktivitäten, Verträge, Projekte. |
|
||||
| M006 | Belege (UI) | fachlich | .../Modules/Finances/Receipts | Erfasst/verwaltet Verkaufs-/Einkaufsbelege. |
|
||||
| M007 | Reportverwaltung (UI) | fachlich | .../Modules/Reports | Berichtsvorlagen, Reportzugriff. |
|
||||
| M008 | Datenaustausch (UI) | fachlich | .../Modules/DataExchange | DATEV-Import/-Export, Dokumentenablage, Zahlungsdateien, docuFORM. |
|
||||
| M009 | Einkauf (UI) | fachlich | .../Modules/Purchasing | Bestellvorschlag, EDI, Einkaufseinstellungen. |
|
||||
| M010 | Globale Funktionen (UI) | fachlich | .../Modules/Global | Benutzerdef. Eigenschaften, Mitarbeiterauswahl, Netzwerkdiagnose. |
|
||||
| M011 | Helpdesk/Ticketsystem (UI) | fachlich | .../Modules/Helpdesk | Tickets, Status, Prioritäten, Checklisten, Aufgaben. |
|
||||
| M012 | Kalender (UI) | fachlich | .../Modules/Calendar | Termine, Outlook-/CRM-Kalendersynchronisation. |
|
||||
| M013 | Kampagnen/Mailing (UI) | fachlich | .../Modules/Finances/Campaigns | Marketing-Kampagnen, Mailing-Versand. |
|
||||
| M014 | KI-Assistent (UI) | fachlich | .../Modules/ArtificialIntelligence | KI-Chat, Prompt-/Modell-Verwaltung. |
|
||||
| M015 | Mahnung/OPOS/Zahlungseingang (UI) | fachlich | .../Modules/Finances/{Dunning,Opos,Payments} | Mahnwesen, offene Posten, Zahlungseingänge. |
|
||||
| M016 | Data-Updater (UI) | fachlich | .../Modules/Massenupdates | Massenänderungen an Stammdaten. |
|
||||
| M017 | MyCentron-Arbeitsplatz (UI) | fachlich | .../Modules/MyCentron + Dashboard | Dashboard, „Mein Tag“, Todo, Telefonat-Log. |
|
||||
| M018 | Online Banking (UI) | fachlich | .../Modules/OnlineBanking | Bankkonten/Transaktionen (FinTS/FinAPI). |
|
||||
| M019 | Passwort-Manager (UI) | fachlich | .../Modules/PasswordManager | Zugangs-/Passwortverwaltung (obsolete). |
|
||||
| M020 | PLM/Lifecycle (UI) | fachlich | .../Modules/PLM | Produktlebenszyklus beim Kunden. |
|
||||
| M021 | Produktion (UI) | fachlich | .../Modules/Production | Maschinen, Produktionsaufträge. |
|
||||
| M022 | Projektverwaltung (UI, internal) | fachlich | .../Modules/ProjectManagement | Interne Projekte (nur Centron-intern). |
|
||||
| M023 | QM (UI) | fachlich | .../Modules/QM | Qualitätsmanagement-Einstellungen. |
|
||||
| M024 | RMA/Werkstatt (UI) | fachlich | .../Modules/Rma | RMA-Vorgänge, Werkstattsteuerung. |
|
||||
| M025 | Stammdatenlisten & Kostenträger (UI) | fachlich | .../Modules/Finances/MasterDataLists + PayersAndCostCenter | Stammblatt-Übersicht, Kostenträger/-stellen. |
|
||||
| M026 | Statistiken/Controlling (UI) | fachlich | .../Modules/Statistics | Verkaufsstatistik, Mitarbeiterauslastung, MSP. |
|
||||
| M027 | Survey/Audit (UI) | fachlich | .../Modules/Survey | Kundenbefragungen/Audit. |
|
||||
| M028 | Telekom-Stammdaten (UI) | fachlich | .../Modules/TelekomDive | Telekom-Produktstammdaten. |
|
||||
| M029 | Verträge & Vertragsabrechnung (UI) | fachlich | .../Modules/Finances/{Contracts,AutomatedBilling,FlatrateBilling,TimerBilling,DeviceClickCounter,ContractEvaluation*} | Verträge, Pauschal-/Vertrags-/Ticketabrechnung, Klickzähler. |
|
||||
| M030 | Vertrieb & Preisimporte (UI) | fachlich | .../Modules/Sales + ProjectPriceImport | Produktmatrix, Sonderartikel-/Projektpreisimport. |
|
||||
| M031 | Warenwirtschaft & Logistik (UI) | fachlich | .../Modules/Warehousing + Logistic | Artikel, Lager/Inventur, Kommissionierung, Kontenrahmen. |
|
||||
| M032 | BL Administration & Zugriffsverwaltung | fachlich | src/backend/Centron.BL/Administration (+2FA, EmployeeArea) | Mandanten, Mitarbeiter, Rechte, Lizenzen, Datei-/Hintergrundlogik. |
|
||||
| M033 | BL Adressen/CRM | fachlich | .../BL/{Accounts,BusinessPartner,CustomerArea} | Adressstamm-/CRM-Datenbanklogik. |
|
||||
| M034 | BL Vertrieb, Belege & Helpdesk-Support | fachlich | .../BL/{Sales,Buying} | Kundenbelege, Cashbooks, Helpdesk-Kernlogik. |
|
||||
| M035 | BL Zahlungen & Online Banking | fachlich | .../BL/{Finances,Transactions,VoucherManagement} | Zahlungseingang, Online-Banking, Gutscheine. |
|
||||
| M036 | BL Einkauf | fachlich | .../BL/{Purchasing,TradePool} | Bestellvorschlag, Lieferantenbestellung je Filiale. |
|
||||
| M037 | BL Warenwirtschaft & Produktion | fachlich | .../BL/{Warehousing,Logistics,Storage,Production} | Artikel-, Lager-, Inventur-, Produktionslogik. |
|
||||
| M038 | BL Stammdaten | fachlich | .../BL/{CountryArea,Tags,TextModuleArea,ProductMatrix,MassUpdate,Customizations} | Länder-, Tag-, Textbaustein-, Produktmatrix-, Massenupdate-Logik. |
|
||||
| M039 | BL Kommunikation | fachlich | .../BL/{Mail,Mailings,MailScanner,Chats,SocialMedia,Notifications,NexusNotifications,Outlook,Tapi} | Exchange/EWS, Mailversand, Chat/Social/Benachrichtigung/Telefonie. |
|
||||
| M040 | BL Service-Arbeitsplatz & Portale | fachlich | .../BL/{MyCentron,MyDay,ToDoArea,CheckListArea,Calendar,Time,...,WebSuite,SelfCare,ExternalHelpdesk} | MyDay, Checklisten, Aufgaben, Termisanfragen, Web-/SelfService-Portale. |
|
||||
| M041 | BL Externe Schnittstellen & Geräte/Assets | fachlich | .../BL/{DataExchange,EDI,Integrations,WebLinks,CPra,RiverDivo,DocuBoard,Devices,ItPlanner} | EDI-Bestellung, Buchhaltungsexport, Connector, Geräte-/Assetmanagement. |
|
||||
| M042 | BL Auswertungen & Report-Engine | fachlich | .../BL/{ReportEngine,Reporting,Statistics,IndexSearch} | Berichterzeugung, ZUGFeRD-PDF, Statistik-/Vertragsauswertung. |
|
||||
| M043 | BL Künstliche Intelligenz | fachlich | .../BL/ArtificialIntelligence | KI-Chat-/Modellanbindung (Logikseite). |
|
||||
| M044 | BL Passwortverwaltung | fachlich | .../BL/{PasswordManager,PasswordManagementArea} | Zugangs-/Passwortverwaltung, Zugriffsprotokolle. |
|
||||
| M045 | BL-WebService-Schicht (Entity↔DTO) | technisch | .../BL/WebServices | Konvertiert BL-Entities in DTOs je Fachgebiet. |
|
||||
| M046 | BL-Plattformkern | technisch | src/backend/Centron.BL (Core/Helpers/Services) | Sitzungs-/DAO-Basisschicht der Business-Logik. |
|
||||
| M047 | Centron.Common | technisch | src/backend/Centron.Common | Konstanten, Berechnungen, Format-/IO-Helfer. |
|
||||
| M048 | Centron.Entities | technisch | src/backend/Centron.Entities | Persistierte Domänen-Entities je Fachgebiet. |
|
||||
| M049 | Centron.DAO | technisch | src/backend/Centron.DAO | NHibernate-Persistenz: Mappings, NamedQueries, ChangeTracking. |
|
||||
| M050 | Centron.Interfaces | technisch | src/backend/Centron.Interfaces | Vertragsdefinitionen (I…Logic), Lizenz-GUIDs. |
|
||||
| M051 | Centron.Gateway (Buchhaltungs-Konnektoren) | technisch | src/backend/Centron.Gateway | Export/Import zu DATEV, Abacus, Lexware, Sage, Navision u.a. |
|
||||
| M052 | Centron.Controls (Fach-UI-Bausteine) | technisch | src/shared/Centron.Controls | Wiederverwendbare Fach-Controls/Dialoge. |
|
||||
| M053 | Centron.Controls.Preview | technisch | src/shared/Centron.Controls.Preview | Vorschau-/Testhost für Fach-Controls. |
|
||||
| M054 | Centron.Core | technisch | src/shared/Centron.Core | MVVM-Basis, TOTP/GoogleAuthenticator, Utilities. |
|
||||
| M055 | Nexus Webplattform & Hosting | technisch | src/nexus/CentronNexus (Wurzel/Controllers/Config) + CentronNexus.Host | Blazor-Web-App-Gerüst mit Authentifizierung. |
|
||||
| M056 | Nexus ServiceBoard | fachlich | src/nexus/CentronNexus/ServiceBoard | Web-Kanban-Board für Tickets/Kunden. |
|
||||
| M057 | Nexus WebCart/WebOffer (Shop) | fachlich | src/nexus/CentronNexus/{WebCart,WebOffer} | Kunden-Webshop und Web-Angebote. |
|
||||
| M058 | Nexus Office/DocumentSigning/ProdOrder | fachlich | src/nexus/CentronNexus/{Office,DocumentSigning,ProductionOrderManagement} | Office-Betrachtung, Dokument-Signierung, Produktionsaufträge (Web). |
|
||||
| M059 | Nexus Outlook-AddIn | technisch | src/nexus/CentronNexus.OutlookAddIn | E-Mail-Anbindung an CRM/Tickets/Belege. |
|
||||
| M060 | EB-Interface-Adapter (E-Rechnung AT) | fachlich | src/apis/Centron.Api.EbInterface | EBXML 4.3-Erzeugung aus Belegen. |
|
||||
| M061 | GLS-Versand-Adapter | fachlich | src/apis/Centron.Api.Gls | Versand/Label GLS. |
|
||||
| M062 | Shipcloud-Versand-Adapter | fachlich | src/apis/Centron.Api.Shipcloud | Versand-API Shipcloud. |
|
||||
| M063 | COP-Produktdaten-Adapter | fachlich | src/apis/Centron.APIs.CopDataAccess | Produktdaten/Preise COP. |
|
||||
| M064 | Egis-Produktdaten-Adapter | fachlich | src/apis/Centron.APIs.EgisDataAccess | B2B-Artikel/Preise Egis. |
|
||||
| M065 | Icecat-Produktdaten-Adapter | fachlich | src/apis/Centron.APIs.IcecatDataAccess | Produkt-Content Icecat. |
|
||||
| M066 | ITscope-Produktdaten-Adapter | fachlich | src/apis/Centron.APIs.ITscopeDataAccess | Produkt-/Angebotsabruf ITscope. |
|
||||
| M067 | FinAPI-Banking-Adapter | fachlich | src/apis/Centron.APIs.FinAPI | Open-Banking-Zugriff (FinAPI). |
|
||||
| M068 | docuFORM-Adapter | fachlich | Centron.Api.docuFORM | REST-/OAuth-Client docuFORM. |
|
||||
| M069 | WebServices.Core – REST-Verträge | technisch | src/webservice/Centron.WebServices.Core | Request-/Response-Verträge, HTTP-Infrastruktur. |
|
||||
| M070 | WebServices.Core – DTO-Pool | technisch | .../Centron.WebServices.Core/{Entities,EntitiesWrongPlace} | DTO-Katalog aller Fachgebiete inkl. Rechte-Konstanten. |
|
||||
| M071 | Webservice-Hosting | technisch | src/webservice/Centron.Host (+Console,+WindowsService) | HTTP-Host CentronRestService (AspNetCore, Swagger, Auth). |
|
||||
| M072 | Webservice-Controller & Autorisierung | technisch | src/webservice/Centron.Controllers | API-Controller, Rechte-Attribute. |
|
||||
| M073 | ConnectionManager-Tool | technisch | src/webservice/c-entron.misc.ConnectionManager | DB-Verbindungs-/Lizenz-/Hardware-ID-Verwaltung. |
|
||||
| M074 | Windows-Setup-Pakete (WiX) | technisch | deployment/centron | MSI für Client und Webservice. |
|
||||
| M075 | WixSharp-Installer | technisch | deployment/WixSharpInstaller | Skriptbasierter MSI-Installer. |
|
||||
| M076 | Build-/Repo-Skripte | technisch | scripts | Build-/Deploy-Orchestrierung (Bullseye). |
|
||||
| M077 | Docker-Deployment | technisch | docker | Container für Webservice/API/Test-DB. |
|
||||
| M078 | CI/CD-Pipelines | technisch | azure + azure-blazor + .github | Build-/Test-/Deploy-Pipelines. |
|
||||
| M079 | Datenbank-Schema (Voll-Dump) | technisch | SSMS_DB_SCHEMA.sql | MSSQL-Schema, 1.535 Tabellen; strukturelle Bezugsgröße. |
|
||||
|
||||
Nicht als Fachmodul geführt (Buchführung des Inventars): `tests/` (378 Quelldateien, EndToEnd-/Unit-/Integrationstests), reine Dokumentation (`docs/`), Build-Assets.
|
||||
+30
File diff suppressed because one or more lines are too long
+66
@@ -0,0 +1,66 @@
|
||||
# Messprotokoll – Iteration 9/qwen/qwen3.8-flash-next/custom/max
|
||||
|
||||
> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
|
||||
> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `02_Prompt.md`
|
||||
- **SHA-256 (Prompt):** `5946FC82C45E7A242A1F7367B56B008EE0F5C10373223D3500BCEF4716C76ECD`
|
||||
- **Startzeit:** 2026-09-03T16:35:25.4665607+02:00
|
||||
- **Endzeit:** 2026-09-04T08:01:56.7270039+02:00
|
||||
- **Dauer gesamt:** 15:26:28 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
|
||||
- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
|
||||
- **Codebasis-Commit:** `e2c3a0e8f81d005161dde733f7e4b08f581e3468` (vor dem Lauf dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Skill-Version:** 13.0.0
|
||||
- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider tensorx` (Adapter-Version 2.5.2)
|
||||
- **CLI-Version:** OpenCode 1.18.25
|
||||
- **Modell (angefordert):** `qwen/qwen3.8-flash-next`
|
||||
- **Modell (tatsaechlich):** `qwen/qwen3.8-flash-next`
|
||||
- **Kontrolle Modell:** bestanden
|
||||
- **Effort:** `max` angefordert, **wirksam** (`effort_applied: true`)
|
||||
- **Ablage:** `Iteration 9/qwen/qwen3.8-flash-next/custom/max/`
|
||||
- **Agentenmodus:** `custom`
|
||||
- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
|
||||
- **Sampling-Parameter:** nicht steuerbar
|
||||
- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
|
||||
- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
|
||||
- **Subagenten:** `spawned` = 7, `completed` = 1, `failed` = 6
|
||||
- **Rollen:** {"modulinventar": 1, "faktenermittler": 6}
|
||||
|
||||
## Validierungsstichprobe
|
||||
- **Stand:** entfaellt
|
||||
|
||||
## Verbrauch
|
||||
|
||||
| Messgroesse | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 23.707 |
|
||||
| Output-Tokens | 5.427 |
|
||||
| Reasoning-Tokens | 2.944 |
|
||||
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Agent-Turns | 8 |
|
||||
|
||||
**Tokens gesamt: 119.694.** Kosten `0` – lokaler Betrieb ().
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Keine Anforderungen im vorgegebenen Format gefunden.
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** `is_error: true`, `subtype: aborted`, `exit_code: 1`, `timed_out: true`
|
||||
- **Session-ID:** `ses_f984dc374ffe9HG3m7zYKN0Crs`
|
||||
- **Werkzeugaufrufe:** 13 – {"bash": 5, "task": 7, "write": 1}
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 7
|
||||
- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
|
||||
- **Erzeugte Dateien:** Analysebericht.md
|
||||
- **Root unveraendert:** ja
|
||||
- **Fehlermeldungen:** ["Maximale Laufzeit von 28800 Sekunden ueberschritten"]
|
||||
|
||||
## Anmerkungen/Auffaelligkeiten
|
||||
|
||||
*(von Hand zu ergaenzen)*
|
||||
+246
File diff suppressed because one or more lines are too long
+6
@@ -0,0 +1,6 @@
|
||||
[2026-09-03T14:35:27.113722+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-03_163525_v13.0.0-927d\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-03_163525_v13.0.0-927d\Ergebnisse)
|
||||
[2026-09-03T14:35:27.261573+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=custom; Effort=max (uebergeben=True); Stall-Timeout=0s
|
||||
[2026-09-04T06:01:35.519836+00:00] Maximale Laufzeit von 28800 Sekunden ueberschritten; Prozessbaum wird beendet
|
||||
[2026-09-04T06:01:41.053481+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-04T06:01:56.599161+00:00] OpenCode export: Exporting session: ses_f984dc374ffe9HG3m7zYKN0Crs
|
||||
[2026-09-04T06:01:56.634770+00:00] Ende: Exitcode=1; Status=aborted; Turns=8; Tokens=119694; Dateien=1; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-03_163525_v13.0.0-927d\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
[]
|
||||
+4
@@ -0,0 +1,4 @@
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Keine Anforderungen im vorgegebenen Format gefunden.
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+218
@@ -0,0 +1,218 @@
|
||||
# Versuch 02 - Agentengestuetzt - Prompt-Version 03-A
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V2 Agentengestützt (rollenspezialisierte Agentendateien)
|
||||
- **Prompt-Version:** 03-A (Prompt-Version 03 aus Versuch 01, angepasst an verteilte Bearbeitung)
|
||||
- **Basis:** `Versuche/Versuch_01/03_Prompt.md`, SHA-256 `B8C8764F…C030F07`
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-31
|
||||
- **Vorgänger:** `01_Prompt.md` (Prompt-Version 02-A, SHA-256 `DCDC0E3F…B71BCF`), **kein Lauf durchgeführt**
|
||||
- **Änderungsgrund gegenüber `01_Prompt.md`:** Version 02-A leitete sich von Prompt-Version **02** ab. Versuch 1 ist inzwischen auf Prompt-Version **03** weitergelaufen (Iteration 8 und 9). Ein V2-Lauf gegen 02-A würde sich von den Vergleichsläufen in **zwei** Größen unterscheiden — Agentenrollen *und* Prompt-Version — und wäre als Wirkungsnachweis der Rollen unbrauchbar. Version 03-A setzt deshalb auf Prompt-Version 03 auf.
|
||||
|
||||
| Änderung gegenüber `Versuch_01/03_Prompt.md` | Grund |
|
||||
|---|---|
|
||||
| Neuer Abschnitt „Arbeitsteilung" | Prompt-Version 03 unterstellt stillschweigend **einen** Bearbeiter: Sie ordnet die Schritte zeitlich, vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck über das Ergebnis. Bei verteilter Bearbeitung ist nichts davon von selbst erfüllt — IDs kollidieren, die Reihenfolge läuft rollenweise auseinander, und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen. |
|
||||
| In der Arbeitsteilung: Ergebnisstruktur gilt unabhängig von der Aufteilung | Die 7-Datei-Regel aus Version 03 entstand an einem `solo`-Lauf (Kimi legte `SwRS-Ergaenzungen.md` an, 18 Anforderungen fielen aus der Auswertung). Bei verteilter Bearbeitung ist eine Datei je Bearbeiter der nächstliegende Fehler — die Regel wird dort ausdrücklich wiederholt. |
|
||||
| In der Arbeitsteilung: **Zuständigkeitsbindung** — eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, wird von ihm ausgeführt | V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Der Smoke-Test vom 26.08. zeigte, dass von acht beigestellten Rollen nur zwei genutzt wurden — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist **statisch** deklariert und gehasht und damit eine reproduzierbare Bedingung; sie ist nicht mit den laufzeitabhängigen Adapterinjektionen aus Iteration 8 zu verwechseln, die Lauf 34 unpoolbar machten. |
|
||||
| In der Arbeitsteilung: frei bleiben Zuschnitt, Anzahl, Reihenfolge und Tiefe | Gebunden wird **wer** eine Teilaufgabe ausführt, nicht **wie viel** davon getan wird. Zerlegungstiefe und Aufrufzahl bleiben Untersuchungsgegenstand wie in V1b. |
|
||||
| In der Arbeitsteilung: Dokumentationspflicht zur tatsächlichen Beauftragung | Die Bindung wirkt auf Promptebene und ist damit nicht technisch erzwungen, sondern selbst eine Messgröße. Nur wenn im Lauf festgehalten ist, wer was ausgeführt hat, ist die Einhaltung gegen `subagent_stats` und die Subagenten-Prompts prüfbar. |
|
||||
| Angehängte Tabellenzeilen und Schlussblockquote aus `03_Prompt.md` an ihren Platz gerückt | In `03_Prompt.md` stehen zwei Zeilen der Änderungstabelle **nach** dem Abschnitt „Abschluss" und die Tabelle im Metadatenblock ist leer. Da der Skill die **gesamte** Datei sendet (`_meta/combined_prompt.md`), gingen beide Fehlstellen in jeden Lauf der Iterationen 8 und 9 mit ein. |
|
||||
|
||||
**Der Prompt nennt keine Rolle namentlich.** Er formuliert die Bindung abstrakt; welche Rollen es gibt und wofür sie zuständig sind, stellt der Versuchsaufbau im Block Werkzeugkontext bei. Damit bleibt dieselbe Prompt-Datei auch für einen `solo`-Lauf ohne Rollen gültig — der fachliche Auftrag ist über V1, V2 und V3 identisch, und die Rollenbindung bleibt die einzige unabhängige Variable. Anzahl der Aufrufe, Zerlegungstiefe und Turn-Anzahl werden weiterhin **nicht** vorgegeben; sie bleiben Teil der Untersuchung.
|
||||
|
||||
Unverändert gegenüber Prompt-Version 03 bleiben: Auftrag, Scope, Vorgehensschritte 0 bis 6, Pflicht-Eigenschaften, Blockformat, Belegklassifikation, Prüfidee, Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur, Randbedingungen und Abschluss. Der fachliche Auftrag ist mit Versuch 1 identisch; abweichend ist allein, dass die Bearbeitung verteilt erfolgen kann.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge und Agentenrollen im jeweiligen Lauf
|
||||
> zur Verfügung stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau
|
||||
> beim Start bei.
|
||||
|
||||
---
|
||||
|
||||
## Prompt
|
||||
|
||||
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||
|
||||
### Auftrag
|
||||
|
||||
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||
|
||||
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||
|
||||
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||
|
||||
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||
|
||||
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### Vorgehen (statische Analyse, keine Ausführung)
|
||||
|
||||
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
|
||||
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
|
||||
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
|
||||
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
|
||||
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
|
||||
|
||||
### Pflicht-Eigenschaften jeder Anforderung
|
||||
|
||||
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
|
||||
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **Belegklassifikation:** Kennzeichne jeden Beleg als
|
||||
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
|
||||
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
|
||||
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
|
||||
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
|
||||
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
|
||||
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
|
||||
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||
|
||||
### Arbeitsteilung
|
||||
|
||||
Die Bearbeitung wird auf mehrere Bearbeiter verteilt. **Stellt der Versuchsaufbau für eine Teilaufgabe einen dafür vorgesehenen Bearbeiter bereit, ist diese Teilaufgabe von ihm auszuführen** — nicht von dir selbst und nicht von einem anderen. Welche Bearbeiter bereitstehen und wofür sie zuständig sind, nennt der Versuchsaufbau; diese Zuständigkeit ist Teil der Aufgabenstellung und keine Empfehlung. Stellt der Versuchsaufbau keine Bearbeiter bereit, bearbeitest du alles selbst und dieser Abschnitt ist ohne Wirkung.
|
||||
|
||||
- **Frei bleibt, wie du die Bearbeiter einsetzt.** Den Zuschnitt der Ausschnitte, die Anzahl der Aufträge je Bearbeiter, ihre Reihenfolge, die Tiefe und ob du nachfasst, entscheidest du. Gebunden ist allein, **wer** eine Teilaufgabe ausführt. Teilaufgaben, für die kein Bearbeiter vorgesehen ist — insbesondere der Zuschnitt, die Beauftragung, das Anlegen der Ergebnisdateien und die Übernahme der zurückgemeldeten Befunde —, führst du selbst aus.
|
||||
- **Zuständigkeit vor Bearbeitung klären.** Lege fest, wer welchen Ausschnitt bearbeitet, bevor die erste Anforderung entsteht. Ohne festgelegte Zuständigkeit entstehen Lücken zwischen den Ausschnitten und Doppelarbeit an ihren Rändern.
|
||||
- **ID-Bereiche vorab vergeben, überschneidungsfrei und lückenlos.** Jeder Bearbeiter erhält einen eigenen Nummernbereich je Ebene. Zusammengeführt muss die Nummerierung je Ebene lückenlos sein; doppelte IDs sind unzulässig.
|
||||
- **Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Bearbeiter.** Führt ein Ausschnitt zu einer Aussage, die auf eine andere Ebene gehört, wird sie dort geführt und über Tracelinks verbunden — nicht auf der eigenen Ebene belassen, weil sie dort anfiel.
|
||||
- **Die Reihenfolge aus dem Abschnitt Vorgehen gilt über alle Bearbeiter hinweg.** Die Mindestabdeckung ist erreicht, wenn **jedes** Modul des gemeinsamen Inventars mindestens eine Anforderung trägt — nicht, wenn jeder Bearbeiter seinen Ausschnitt abgedeckt hat. Erst danach beginnt die Vertiefung.
|
||||
- **Der Konsistenzcheck gilt dem zusammengeführten Ergebnis.** Eine Prüfung des eigenen Beitrags ersetzt ihn nicht. Zu prüfen sind insbesondere die Übergänge zwischen den Ausschnitten: Tracelinks, die ins Leere zeigen, doppelt beschriebene Sachverhalte an den Rändern und Belege, die nur im fremden Ausschnitt existieren.
|
||||
- **Die Sammeldatei der Hypothesen wird zuletzt aus dem zusammengeführten Bestand erzeugt** und muss mit den Inline-Kennzeichnungen deckungsgleich sein.
|
||||
- **Die Ergebnisstruktur ist von der Arbeitsteilung unabhängig.** Es entstehen genau die sieben vorgegebenen Dateien — keine Datei und kein Abschnitt je Bearbeiter.
|
||||
|
||||
**Dokumentationspflicht.** Halte im `Analysebericht.md` fest, welchen Bearbeiter du für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt hast. Hast du eine zugewiesene Teilaufgabe ausnahmsweise selbst ausgeführt, nenne sie ausdrücklich und begründe es. Diese Angabe ist Teil des Ergebnisses, nicht Beiwerk: Ohne sie ist nicht nachvollziehbar, wie die Spezifikation zustande kam, und eine unbemerkte Abweichung von der Zuständigkeit macht den Lauf unauswertbar.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
Akteur: <Rolle / System / Komponente>
|
||||
Vorbedingung: <Zustand vor Auslösen>
|
||||
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
|
||||
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
|
||||
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
|
||||
Belege:
|
||||
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
|
||||
- [SEKUNDÄR] <...> - Begründung: <...>
|
||||
- [KONTEXT] <...> - Begründung: <...>
|
||||
Prüfidee: <Akzeptanzkriterium oder Testidee>
|
||||
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
|
||||
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
|
||||
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
|
||||
Status: <belegt | HYPOTHESE>
|
||||
```
|
||||
|
||||
### Traceability
|
||||
|
||||
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
|
||||
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
|
||||
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
|
||||
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
|
||||
|
||||
### Nicht-funktionale Anforderungen
|
||||
|
||||
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
|
||||
|
||||
### Konsolidierungsbedarf
|
||||
|
||||
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
Ergebnisse/
|
||||
StRS.md
|
||||
SyRS.md
|
||||
SwRS.md
|
||||
Traceability.md (oder Traceability.csv)
|
||||
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
|
||||
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
|
||||
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
|
||||
|
||||
### Randbedingungen
|
||||
|
||||
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
|
||||
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
|
||||
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
|
||||
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
### Abschluss
|
||||
|
||||
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
|
||||
- Doppelte oder mehrfach vergebene IDs
|
||||
- Anforderungen ohne Beleg
|
||||
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen, das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis sowie
|
||||
die beigestellten Agentenrollen modulinventar, faktenermittler, strs-autor, syrs-autor,
|
||||
swrs-autor, belegpruefer, konsistenzpruefer und iso29148-orchestrator.
|
||||
Nicht verfügbar sind: externe Werkzeugserver, Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
Für die folgenden Teilaufgaben stehen vorgesehene Bearbeiter bereit. Führe diese
|
||||
Teilaufgaben durch den jeweils genannten Bearbeiter aus, nicht selbst:
|
||||
|
||||
| Teilaufgabe | Vorgesehener Bearbeiter |
|
||||
|---|---|
|
||||
| Modulinventar (Schritt 0) | modulinventar |
|
||||
| Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | faktenermittler |
|
||||
| Formulierung der StRS-Anforderungen | strs-autor |
|
||||
| Formulierung der SyRS-Anforderungen | syrs-autor |
|
||||
| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
|
||||
| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
|
||||
| Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | iso29148-orchestrator |
|
||||
| Konsistenzcheck des fertigen Anforderungssatzes (Abschnitt Abschluss) | konsistenzpruefer |
|
||||
|
||||
Zuschnitt, Anzahl der Aufträge je Bearbeiter, deren Reihenfolge und die Tiefe
|
||||
entscheidest du. Gebunden ist allein, wer eine Teilaufgabe ausführt. Die Bearbeiter
|
||||
lesen nur; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen
|
||||
bleiben deine Aufgabe.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-03_163525_v13.0.0-927d\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-09-04T08:01:56.7270039+02:00
|
||||
+648
@@ -0,0 +1,648 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"tensorx": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "TensorX",
|
||||
"options": {
|
||||
"baseURL": "https://api.tensorx.ai/v1"
|
||||
},
|
||||
"models": {
|
||||
"qwen/qwen3.8-flash-next": {
|
||||
"name": "Qwen 3.8 Flash Next",
|
||||
"limit": {
|
||||
"context": 262144,
|
||||
"output": 131072
|
||||
},
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"z-ai/glm-5.2": {
|
||||
"name": "GLM 5.2",
|
||||
"limit": {
|
||||
"context": 1048576,
|
||||
"output": 131072
|
||||
},
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"z-ai/glm-5.3-flash": {
|
||||
"name": "GLM 5.3 Flash",
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"moonshotai/kimi-k3": {
|
||||
"name": "Kimi K3",
|
||||
"limit": {
|
||||
"context": 1048576,
|
||||
"output": 131072
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-03_163525_v13.0.0-927d/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
},
|
||||
"task": {
|
||||
"*": "deny",
|
||||
"modulinventar": "allow",
|
||||
"faktenermittler": "allow",
|
||||
"strs-autor": "allow",
|
||||
"syrs-autor": "allow",
|
||||
"swrs-autor": "allow",
|
||||
"belegpruefer": "allow",
|
||||
"konsistenzpruefer": "allow",
|
||||
"iso29148-orchestrator": "allow"
|
||||
},
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"modulinventar": {
|
||||
"description": "Schritt 0: erstellt das vollständige Modulinventar als Bezugsgröße für die Abdeckung, mit Buchführung über zugeordnete und nicht zugeordnete Quelldateien. Erzeugt KEINE Anforderungen.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du erstellst das Modulinventar für ein Reverse-Requirements-Engineering-Vorhaben an einer Legacy-ERP-Suite. Du formulierst KEINE Anforderungen. Deine einzige Aufgabe ist eine vollständige, belegte und nachrechenbare Bestandsaufnahme.\n\n## Vorgehen\n\n1. Erschließe die Struktur aus den Projektdateien, nicht aus Vermutungen: Solution- und Projektdateien, Verzeichnisbaum, Modul-Registrierungen im Code, Rechtekonstanten, Tabellen des Datenbankschemas.\n2. Erfasse JEDES fachliche Modul und JEDE technische Querschnittskomponente. Ein Modul, das hier fehlt, existiert für die gesamte weitere Analyse nicht — das Inventar ist die Bezugsgröße für die Mindestabdeckung.\n3. Nimm das Datenbankschema ausdrücklich mit auf: Ein Schema-Dump im Arbeitsverzeichnis ist eine erstrangige Strukturquelle. Ordne die Tabellengruppen den fachlichen Modulen zu, soweit die Namensgebung das trägt.\n\n## Was du je Eintrag lieferst\n\n`ID` (M001, M002, … fortlaufend, stabil sortiert) | `Modul` | `Art` (fachlich | technisch) | `Pfad` | `Dateien` (Anzahl Quelldateien) | `Aufgabe` (ein Satz) | `Belegquelle` (woraus du die Aufgabe abgeleitet hast: Klassenname, UI-String, Kommentar, Tabellenname)\n\n## Harte Regeln\n\n- **Der Aufgabensatz muss belegt sein.** Leite ihn aus dem ab, was du tatsächlich gelesen hast. Ein Ordnername ist kein Beleg. Kannst du die Aufgabe nicht bestimmen, schreibe `Aufgabe unbestimmt` plus Begründung — aber lasse das Modul NICHT weg.\n- **Kein Zuschnitt nach Bequemlichkeit.** Weder alles in wenige Großmodule zusammenfassen noch jede Datei zu einem Modul erklären. Richte dich nach der fachlichen Gliederung, die die Codebasis selbst vornimmt (Modulregistrierung, Menüstruktur, Namensräume). Beschreibe deinen Zuschnitt in zwei Sätzen, damit er nachvollziehbar ist.\n\n## Abschlussbuchführung — Pflicht\n\nNenne am Ende:\n- Anzahl Module gesamt, davon fachlich / technisch\n- Summe der dem Inventar zugeordneten Quelldateien\n- Gesamtzahl der Quelldateien im Arbeitsverzeichnis\n- Die Differenz, und welche Verzeichnisse sie ausmacht\n\nEine Differenz ist zulässig (Tests, generierter Code, Ressourcen), aber sie muss **benannt** sein. Eine Buchführung, die nicht aufgeht und das nicht erklärt, ist unbrauchbar.\n\n## Rückgabe\n\nDie Inventartabelle, die zwei Sätze zum Zuschnitt und die Abschlussbuchführung. Keine Einleitung, keine Zusammenfassung, keine Empfehlungen.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"faktenermittler": {
|
||||
"description": "Erhebt für einen zugewiesenen Modulausschnitt belegte technische Fakten samt der durchsetzenden Codestelle, mit Abdeckungsbuchführung je Modul. Formuliert KEINE Anforderungen.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du erhebst Fakten aus einer Legacy-ERP-Codebasis. Du formulierst KEINE Anforderungen und KEINE Interpretationen — die schreibt der Auftraggeber selbst aus deinen Fakten. Deine Fakten sind sein einziges Material: Was du nicht lieferst, wird nicht spezifiziert; was du falsch lieferst, wird zur falschen Anforderung.\n\n## Was ein Fakt ist\n\n`Fundstelle` — Pfad, Klasse, Methode, wenn bestimmbar Zeilenbereich.\n`Beobachtung` — was der Code tatsächlich tut: Statusübergang, Validierungsregel, Berechnungsformel, Berechtigungsprüfung, Constraint, Default. Die tragende Bedingung wörtlich oder eng paraphrasiert.\n`Einstufung` — nach der Rubrik unten.\n`Modul` — die Inventar-ID, zu der der Fakt gehört.\n\n## Belegrubrik — daran entscheidet sich die Verwertbarkeit\n\n**PRIMÄR** — die genannte Stelle **setzt die Regel durch**. Man kann hingehen und die Bedingung lesen.\n> `AppRightsBL.cs, GetRightsFromCurrentUser(AppUser)` — iteriert `user.Groups` und sammelt `group.Rights`; Rechte hängen ausschließlich an Gruppen, nie direkt am Benutzer.\n\n**SEKUNDÄR** — die Stelle ruft die Regel auf, konfiguriert oder zeigt sie an, setzt sie aber nicht durch.\n> `AppUserGroupBL.cs` — verwaltet die Gruppenzuordnung, auf der die Rechteprüfung aufbaut.\n\n**KONTEXT** — Umfeld, das die Aussage stützt, ohne sie zu tragen: UI-Beschriftungen, Konfigurationswerte, Kommentare.\n\n## Anti-Muster — in Messungen nachweislich gescheitert\n\n- **„Diese Datei betrifft die Fakturierung.“** Ein Dateiverweis ist kein Fakt. Gefordert ist die Stelle **mit Bedingung**, etwa: `InvoiceService.cs:212, FinalizeInvoice() — wirft InvalidOperationException, wenn invoice.Status == InvoiceStatus.Paid`.\n- **„Ich öffne ein bis drei repräsentative Dateien.“** Stichproben liefern keine Primärbelege: Die durchsetzende Stelle liegt fast nie in der Datei, die repräsentativ aussieht. Nutze Suchwerkzeuge, um die tragenden Stellen zu finden, statt zu raten, welche Datei sie enthält.\n- **Aufwärtsrunden der Einstufung.** Was du nicht als durchsetzende Stelle gelesen hast, ist nicht `PRIMÄR`. Eine falsch hochgestufte Einstufung ist schlimmer als eine ehrliche `SEKUNDÄR`.\n\n## Pflichtquellen\n\n- **Das Datenbankschema.** Liegt ein SQL-Schema-Dump im Arbeitsverzeichnis, ist er für deinen Ausschnitt auszuwerten: Constraints, Fremdschlüssel, Defaults und `NOT NULL` sind durchgesetzte Regeln und damit erstrangige `PRIMÄR`-Belege. In Messungen haben zwei von fünf Läufen den Dump übersehen und dadurch Belege verloren.\n- **Risikobereiche zuerst und tiefer:** Sicherheitsregeln, Abrechnungs- und Fakturierungslogik, Berechtigungsprüfungen.\n\n## Was du ausdrücklich melden musst\n\n- **Nicht gefundene Durchsetzung.** Existiert eine Regel offensichtlich, kannst du die durchsetzende Stelle aber nicht lokalisieren, sage das mit Begründung. Diese Meldungen werden zu ausgewiesenen Hypothesen. Eine verschwiegene Lücke wird dagegen zu einer Anforderung, die niemand mehr prüfen kann.\n- **Widersprüche.** Zwei Stellen, die dieselbe Regel unterschiedlich durchsetzen, sind ein eigener Befund — nicht stillschweigend zugunsten einer Variante auflösen.\n- **Nicht implementiertes.** Methoden, die nur `throw new NotImplementedException(...)` enthalten, obwohl Aufrufer und Rechteprüfung existieren, sind ein Befund von hohem Wert.\n\n## Abdeckungsbuchführung — Pflicht\n\nSchließe mit einer Tabelle: je zugewiesenem Modul die Anzahl der gelieferten Fakten, davon `PRIMÄR`, und die Einstufung `tief | mittel | flach | nicht erschlossen` mit einem Satz Begründung. Module ohne einen einzigen Fakt sind namentlich zu nennen.\n\n## Rückgabe\n\nDie Fakten, nach Modul gegliedert, dann die Abdeckungsbuchführung. Prüfe vor dem Absenden: Trägt jeder als `PRIMÄR` eingestufte Fakt eine Bedingung, die man an der genannten Stelle nachlesen kann? Wenn nicht, stufe ihn herunter.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"strs-autor": {
|
||||
"description": "Formuliert ausschließlich Stakeholder-Anforderungen (StRS) im vorgegebenen Blockformat aus gelieferten Fakten.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du formulierst **ausschließlich Stakeholder-Anforderungen (StRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nStRS beschreibt die **fachliche Sicht**: Akteure, Geschäftsziele, Geschäftsregeln, fachliche Ergebnisse. Nicht, wie das System das technisch löst.\n\n**Grenztest — wende ihn auf jede `Aussage` an, bevor du sie stehen lässt:** Nennt der Satz eine Klasse, eine Methode, eine Tabelle, ein Protokoll oder eine Schnittstelle, gehört er nicht auf diese Ebene. Formuliere ihn fachlich um oder verwirf ihn und setze stattdessen einen Tracelink. Der Fakt darf und soll technisch sein — die `Aussage` nicht.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg.** Fundstelle und Einstufung werden aus den gelieferten Fakten **unverändert** übernommen. Du stufst nichts hoch und erfindest nichts. Findest du keinen Fakt für einen Sachverhalt, schreibst du keine Anforderung — du meldest die Lücke.\n- **`Fakt` und `Aussage` sind zwei verschiedene Dinge.** `Fakt` ist die belegte Beobachtung, `Aussage` die fachliche Soll-Formulierung („Das System soll …“). Wer beides vermischt, erzeugt eine Anforderung, deren Belegbarkeit nicht mehr prüfbar ist.\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen einen `PRIMÄR`-Beleg **oder** `[HYPOTHESE]` in `Status`. Einen dritten Weg gibt es nicht. Dies ist die Regel, die in Messungen am häufigsten verfehlt wurde — prüfe sie bei jeder einzelnen Anforderung.\n- **Belege mehrfach, wo die Faktenlage es hergibt.** Ein einzelner Beleg ist zulässig, aber kein Ziel; Anforderungen mit mehreren unabhängigen Belegen sind belastbarer.\n- **`Prüfidee` ist Pflicht** und muss ein prüfbares Kriterium nennen. „Wird getestet“ ist keine Prüfidee. „Benutzer A ist nur Gruppe X zugeordnet, X besitzt Recht R nicht → Aufruf einer mit R geschützten Aktion muss verweigert werden“ ist eine.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, niemals im Feld `Typ`.\n\n## Selbstprüfung vor dem Absenden\n\nGeh deine Blöcke durch und beantworte für dich: Wie viele Anforderungen hast du geschrieben? Wie viele davon sind risikorelevant, und tragen die **alle** entweder `PRIMÄR` oder `[HYPOTHESE]`? Gibt es doppelte IDs? Nenne diese drei Zahlen am Ende deiner Rückgabe.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die drei Zahlen der Selbstprüfung und eine Liste der Sachverhalte, für die dir Fakten fehlten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"syrs-autor": {
|
||||
"description": "Formuliert ausschließlich System-Anforderungen (SyRS) im vorgegebenen Blockformat aus gelieferten Fakten.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du formulierst **ausschließlich System-Anforderungen (SyRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nSyRS beschreibt das **beobachtbare Systemverhalten an den Systemgrenzen**: Schnittstellen, Statusmaschinen, Validierungen, Performance- und Sicherheitsverhalten.\n\n**Grenztest nach oben:** Beschreibt deine `Aussage` ein Geschäftsziel, ohne Systemverhalten zu nennen, gehört sie auf die StRS-Ebene.\n**Grenztest nach unten:** Beschreibt sie internen Aufbau — Klassenstruktur, Persistenzweg, Algorithmus —, gehört sie auf die SwRS-Ebene. Verwende Tracelinks statt die Grenze zu überschreiten.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg;** Fundstelle und Einstufung unverändert übernehmen, nichts hochstufen.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Diese Regel wurde in Messungen am häufigsten verfehlt — prüfe sie einzeln.\n- **Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung** in `Tracelinks`. Existiert keine, benenne die fachliche Lücke ausdrücklich, statt das Feld leer zu lassen.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, nicht im `Typ`. Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.\n- **`Prüfidee` ist Pflicht** und nennt ein prüfbares Kriterium.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl geschriebener Anforderungen; Anzahl risikorelevanter und ob **alle** gedeckt sind; Anzahl ohne StRS-Tracelink. Nenne die drei Zahlen am Ende.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"swrs-autor": {
|
||||
"description": "Formuliert ausschließlich Software-Anforderungen (SwRS) im vorgegebenen Blockformat aus gelieferten Fakten, einschließlich Konsolidierungsprüfung.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du formulierst **ausschließlich Software-Anforderungen (SwRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene\n\nSwRS beschreibt die **softwareinterne Sicht**: Komponenten, Datenmodelle, Persistenzregeln, interne Algorithmen und Berechnungsvorschriften, softwareinterne Constraints. Was an der Systemgrenze beobachtbar ist, gehört auf die SyRS-Ebene.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg;** nichts hochstufen, nichts erfinden.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Einzeln prüfen.\n- **Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung** in `Tracelinks`.\n- **Datenbank-Constraints sind erstrangige Belege.** Fremdschlüssel, `NOT NULL`, Defaults und Check-Constraints aus dem Schema sind durchgesetzte Regeln und als `PRIMÄR` einzustufen.\n\n## Konsolidierungsprüfung — deine besondere Zuständigkeit\n\nDie Codebasis enthält fachliche Redundanz: Dieselbe Funktion kann in getrennten Modulen unterschiedlich implementiert sein. Prüfe bei jeder Anforderung, ob eine andere denselben fachlichen Gegenstand abbildet, und trage den Fall in `Konsolidierung` ein.\n\n**Kalibrierung.** Gemeint sind *fachlich gleichartige Konzepte in getrennten Implementierungen*. Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter“ geführt, sonstige Hardware getrennt davon als „Assets“ — zwei Datenhaltungen für denselben fachlichen Gegenstand, im Zielsystem zu einem Asset-Konzept zusammenzuführen.\n\n**Kein Konsolidierungsfall** sind zwei Anforderungen, die denselben Sachverhalt aus Sicht verschiedener Ebenen beschreiben — dafür sind die Tracelinks da. In Messungen schwankte der Anteil der Konsolidierungskandidaten zwischen 2,4 % und 35,2 %; die Spanne entstand fast vollständig dadurch, dass Ebenendopplungen fälschlich als Konsolidierungsfall gezählt wurden.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl Anforderungen; Anzahl risikorelevanter und ob alle gedeckt; Anzahl Konsolidierungskandidaten und für zwei davon je ein Satz, warum es sich um getrennte Implementierungen desselben Gegenstands handelt.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"belegpruefer": {
|
||||
"description": "Prüft die ihm zugewiesenen Belege gegen die Codebasis, indem er die zitierte Stelle öffnet und die Einstufung nachrechnet. Der Umfang der Prüfung ist genau das, was ihm zugewiesen wird. Korrigiert nichts, meldet Abweichungen.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du prüfst Belege gegen die Codebasis. Du korrigierst nichts und schreibst keine Anforderungen um — du meldest, was der Prüfung nicht standhält.\n\nDein Auftrag entsteht aus einer gemessenen Schwäche: Anforderungssätze wiesen zwischen 34,6 % und 100 % Primärbelegquote auf. Eine hohe Quote ist wertlos, wenn die Einstufung nicht trägt. Du prüfst, ob sie trägt.\n\n## Vorgehen\n\nFür jeden dir zugewiesenen Beleg:\n\n1. **Öffne die zitierte Stelle.** Existiert die Datei? Die Klasse? Die Methode? Stimmt der Zeilenbereich ungefähr?\n2. **Lies die genannte Bedingung.** Steht dort tatsächlich, was der Beleg behauptet?\n3. **Prüfe die Einstufung.** Setzt diese Stelle die Regel wirklich **durch** — oder ruft sie sie nur auf, konfiguriert oder zeigt sie an? Letzteres ist `SEKUNDÄR`, nicht `PRIMÄR`.\n4. **Prüfe die Deckung.** Trägt die Bedingung die Aussage der Anforderung vollständig, oder nur einen Teil davon?\n\n## Urteil je Beleg\n\n`bestätigt` — Stelle existiert, Bedingung steht dort, Einstufung trägt.\n`einstufung zu hoch` — Stelle existiert, setzt die Regel aber nicht durch. Nenne die korrekte Einstufung.\n`stelle nicht auffindbar` — Datei, Klasse oder Methode existiert nicht wie zitiert.\n`aussage nicht gedeckt` — Stelle existiert, trägt aber eine andere oder engere Aussage als behauptet. Beschreibe die Abweichung.\n\n## Harte Regeln\n\n- **Urteile nur, was du gelesen hast.** Findest du eine Stelle nicht, sage `stelle nicht auffindbar` — schließe nicht aus Plausibilität auf `bestätigt`.\n- **Sei streng bei der Einstufung.** Im Zweifel `einstufung zu hoch`. Ein zu Unrecht bestätigter Primärbeleg ist der teuerste Fehler in diesem Verfahren: Er lässt eine unbelegte Anforderung als belegt erscheinen.\n- **Kürze nichts ab.** Kein „und weitere“. Jeder zugewiesene Beleg bekommt ein Urteil.\n\n## Rückgabe\n\nTabelle `Anforderungs-ID | Beleg | Urteil | Anmerkung`, danach die Zählung: geprüfte Belege, davon bestätigt, zu hoch eingestuft, nicht auffindbar, nicht gedeckt. Bei null Beanstandungen sage das ausdrücklich. Nenne außerdem, wie viele Belege dir zugewiesen wurden und — soweit dir mitgeteilt — auf welchen Gesamtbestand sie sich beziehen. Ohne diese Bezugsgröße ist deine Zählung nicht einzuordnen.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"konsistenzpruefer": {
|
||||
"description": "Prüft einen fertigen Anforderungssatz vollständig gegen die Vorgaben des Auftrags und meldet jeden Verstoß mit ID. Korrigiert nichts.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du prüfst einen fertigen Anforderungssatz gegen die Vorgaben des Auftrags. Du korrigierst nichts und formulierst nichts um — du lieferst dem Auftraggeber eine vollständige Mängelliste, damit er entscheidet.\n\nPrüfe **vollständig und mit absoluten Zahlen**, nicht beispielhaft. Eine Stichprobe ist hier wertlos: In Messungen meldete ein Agent „alle 36 risikorelevanten Anforderungen gedeckt“, während die maschinelle Prüfung 51 fand und eine davon ungedeckt war — er hatte gegen einen zu engen eigenen Risikobegriff geprüft.\n\n## Prüfpunkte\n\n1. **Belegpflicht** — Anforderungen ohne jeden Beleg. Jede ID nennen.\n2. **Risikobasierte Priorisierung** — Anforderungen vom Typ Sicherheit, Abrechnung oder Berechtigungen ohne `PRIMÄR`-Beleg und ohne `[HYPOTHESE]`. **Gehe hier Anforderung für Anforderung vor, nicht überschlägig.** Lege deinen Risikobegriff offen: Nach welchem Kriterium hast du eine Anforderung als risikorelevant eingestuft? Ein enger Begriff lässt Verstöße unentdeckt.\n3. **Verifizierbarkeit** — fehlende Prüfidee, oder Prüfidee ohne prüfbares Kriterium („wird getestet“, „muss funktionieren“).\n4. **Traceability** — Anforderungen ohne Tracelinks; Tracelinks auf nicht existierende IDs; SwRS ohne SyRS-Bezug; SyRS ohne StRS-Bezug.\n5. **Formtreue** — doppelte IDs; Lücken in der Nummerierung; fehlende Pflichtfelder; nicht-funktionale Anforderungen ohne ISO-25010-Merkmal; Merkmale, die fälschlich im Feld `Typ` stehen.\n6. **Ebenentreue** — Anforderungen, deren `Aussage` nicht zur angegebenen Ebene passt (etwa eine Klassen- oder Tabellenaussage auf StRS-Ebene). Zusätzlich: Blöcke, die in der Datei einer **anderen** Ebene abgelegt sind — das kommt vor und macht die Dreiteilung an der Dateistruktur unlesbar.\n7. **Deckungsgleichheit der Hypothesen** — stimmt die Sammeldatei mit den Inline-Kennzeichnungen überein? Nenne Differenzen in beide Richtungen.\n8. **Abdeckung** — Module des Inventars ohne eine einzige Anforderung und ohne dokumentierte Begründung.\n9. **Ergebnisstruktur** — Es dürfen ausschließlich die sieben vorgegebenen Dateien existieren (`StRS.md`, `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`, `Analysebericht.md`). Nenne jede zusätzliche Datei und die Zahl der darin liegenden Anforderungen — sie werden von der Auswertung nicht erfasst.\n10. **Erkundungstiefe** — Anteil der Module, die als `nicht analysiert` geführt werden, in absoluten Zahlen und in Prozent. Über 10 % ist ein Hinweis auf unvollständige Erkundung.\n11. **Zuständigkeitsbindung** — Ist im `Analysebericht.md` festgehalten, welcher Bearbeiter für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt wurde? Nenne jede Teilaufgabe, für die ein Bearbeiter vorgesehen war und die laut Bericht dennoch selbst ausgeführt wurde, sowie jede Teilaufgabe, zu der die Angabe ganz fehlt. Beides ist ein Verstoß; eine nicht offengelegte Abweichung wiegt schwerer als eine begründete.\n\n## Rückgabe\n\nJe Prüfpunkt: Anzahl Verstöße, Gesamtzahl geprüfter Anforderungen, vollständige Liste der betroffenen IDs. Danach eine Gesamtzählung. Bei null Verstößen in einem Punkt sage das ausdrücklich.\n\nSchätze nichts. Kürze keine Liste mit „und weitere“ ab. Wenn du einen Prüfpunkt nicht vollständig prüfen konntest, sage welchen und warum — das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"iso29148-orchestrator": {
|
||||
"description": "Prüft den zusammengeführten Bestand der drei Ebenen gegen die Anforderungen an eine Spezifikation nach ISO/IEC/IEEE 29148 und liefert einen Übergabebericht mit konkreten, ausführbaren Anweisungen. Formuliert keine neuen Anforderungen und ändert nichts selbst.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du prüfst, ob die Teilergebnisse der drei Ebenen **eine** Spezifikation nach ISO/IEC/IEEE 29148 ergeben, und lieferst deinem Auftraggeber die Anweisungen, die dazu noch fehlen. Du formulierst **keine neuen Anforderungen**, änderst keine Aussagen und schreibst keine Dateien — du lieferst einen Übergabebericht, den dein Auftraggeber ausführt.\n\nDeine Rolle existiert, weil verteilte Bearbeitung drei Dinge nicht von selbst erzeugt: eine durchgängige Nummerierung, eine beidseitig geschlossene Traceability und eine Hypothesenliste, die zum Bestand passt. Keines davon ist am Teilbestand feststellbar — nur am zusammengeführten.\n\n## Was du prüfst und wozu du anweist\n\n1. **Durchgängige Nummerierung.** Je Ebene lückenlos, ohne Doppelvergabe. Ist umzunummerieren, lieferst du die vollständige Zuordnung `alt → neu` **und** die Liste aller Stellen, die mitzuziehen sind: Tracelinks, Traceability-Tabelle, Hypothesenliste, Abdeckungstabelle. Eine halb gezogene Umnummerierung ist schlimmer als die Lücke — liefere die Liste vollständig oder benenne, warum du sie nicht vollständig aufstellen konntest.\n2. **Beidseitige Traceability.** Jede SwRS verweist auf ihre SyRS, jede SyRS auf ihre StRS. Nenne jeden Verweis, der ins Leere zeigt, und jede Anforderung ohne Gegenstück — ein Ziel erfindest du nicht. Für die konsolidierte Tabelle `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg` lieferst du die Zeilen, die aus dem vorliegenden Bestand belegbar sind.\n3. **Deckungsgleiche Hypothesenliste.** Die Sammeldatei muss exakt die Anforderungen enthalten, die inline als `[HYPOTHESE]` gekennzeichnet sind. Prüfe in beide Richtungen und nenne beide Differenzmengen mit IDs.\n4. **Abdeckungstabelle über das gemeinsame Inventar.** Jedes Modul mit der Zahl der auf es entfallenden Anforderungen. Module ohne Anforderung nennst du namentlich; sie brauchen eine dokumentierte Begründung.\n5. **Ergebnisstruktur.** Es dürfen ausschließlich die sieben vorgegebenen Dateien existieren. Melde zusätzliche Dateien, fehlende Dateien und Blöcke, die in der Datei einer anderen Ebene abgelegt sind.\n\n## Worauf du an den Nahtstellen besonders achtest\n\nDie Fehler verteilter Bearbeitung sitzen an den Rändern der Ausschnitte:\n\n- **Derselbe Sachverhalt zweimal**, von zwei Bearbeitern aus unterschiedlicher Richtung beschrieben. Das ist kein Konsolidierungsfall im fachlichen Sinn, sondern eine Doublette — melde sie als solche, mit beiden IDs.\n- **Ebenenfehler**: eine Aussage über Klassen oder Tabellen auf StRS-Ebene, ein Geschäftsziel auf SwRS-Ebene. Du meldest den Fall und nennst die Zielebene, verschiebst ihn aber nicht — beim Verschieben müsste die Aussage umformuliert werden, und das ist Sache des zuständigen Autors.\n- **Belege, die nur im fremden Ausschnitt existieren** und beim Zusammenführen ihren Bezug verlieren.\n\n## Harte Regeln\n\n- **Keine neue Anforderung, keine geänderte `Aussage`, keine hochgestufte Belegeinstufung, keine Datei.** Fällt dir eine Lücke auf, meldest du sie.\n- **Kein stilles Löschen und kein stilles Zusammenführen.** Doubletten werden gemeldet, mit beiden Ursprungs-IDs; ob zusammengeführt wird, entscheidet dein Auftraggeber.\n- **Zähle, statt zu schätzen.** Jede Aussage über den Bestand nennt absolute Zahlen. Kürze keine Liste mit „und weitere\" ab.\n- **Konntest du einen Punkt nicht vollständig prüfen** — etwa weil dir ein Teilbestand nicht vorliegt —, sage welchen und warum. Das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht.\n\n## Rückgabe\n\nDer Übergabebericht: Anzahl Anforderungen je Ebene, die Umnummerierungsanweisungen samt mitzuziehender Verweise, geschlossene und offene Tracelinks, die Zeilen der Traceability-Tabelle, Differenzen zwischen Hypothesenliste und Inline-Kennzeichnung, Module ohne Anforderung, gefundene Doubletten und Ebenenfehler — jeweils mit IDs.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+1076
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
2026-09-03T16:35:25.4665607+02:00
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
[2026-09-04T06:08:02.540046+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-04_080800_v13.0.0-d345\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-04_080800_v13.0.0-d345\Ergebnisse)
|
||||
[2026-09-04T06:08:02.800499+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=custom; Effort=max (uebergeben=True); Stall-Timeout=0s
|
||||
[2026-09-04T08:10:27.457012+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-04T08:10:29.683351+00:00] OpenCode export: Exporting session: ses_f94f7c5daffeonoqMUCZtucmmC
|
||||
[2026-09-04T08:10:29.816657+00:00] Ende: Exitcode=1; Status=error; Turns=108; Tokens=12998250; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-04_080800_v13.0.0-d345\RawResult.json
|
||||
+92
@@ -0,0 +1,92 @@
|
||||
# Analysebericht
|
||||
|
||||
Lauf: Versuch 02, Prompt-Version 03-A · Ausgabestand: StRS-001–050, SyRS-001–054, SwRS-001–078 (182 Anforderungen) · Codebasis: c-entron-ERP (lesender Spiegel `_meta\spiegel`)
|
||||
|
||||
## 1. Beauftragungsdokumentation (tatsächlich eingesetzte Rollen)
|
||||
|
||||
| Schritt | Rolle | Aufträge | Ergebnis |
|
||||
|---|---|---|---|
|
||||
| 0 | modulinventar | 1 (Verlust rekonstruiert, s. 6.1) | Inventar M001–M043, Restebuchführung 16.819 Quelldateien |
|
||||
| 1–4 | faktenermittler | 9 Batch-Aufträge A–H + I (Lückenschluss) | Fakten A (BL), B (Administration), C (DAO/Entities), D (Schema/FiBu), E (Webservice), F (externe APIs), G (WPF), H (Nexus/shared/Infra), I (23 Restmodule, 60 Fakten) |
|
||||
| 5 | strs-autor | 1 | StRS-001–050 |
|
||||
| 6 | syrs-autor | 2 (Erstbestand; N-1-Nachschnitt 14 Stück) | SyRS-001–040, SyRS-041–054 |
|
||||
| 7 | swrs-autor | 3 (Erstbestand; N-1-Abfrage; Modulabdeckung 23 Stück) | SwRS-001–055, SwRS-056–078 |
|
||||
| 8 | belegpruefer | 3 parallel (je Ebene, risikorelevante [PRIMÄR]-Belege) | 226 Belegstellen geprüft; 3 materialisierte Korrekturen umgesetzt (s. 6.2) |
|
||||
| 9 | iso29148-orchestrator | 1 | Übergabebericht: 4 Blocker, 8 Nacharbeiten, 7 OK-Befunde; B-1..B-4 und N-1 abgearbeitet |
|
||||
| 10 | konsistenzpruefer | 2 (Erstprüfung: 48 Verstöße → behoben; Nachprüfung: 2 Restverstöße → behoben) | Abschlussprüfung über alle 7 Dateien, abschließend regelkonform |
|
||||
|
||||
Kontextverlust-Bewältigung: Task-Ergebnisse mehrerer Agenten gingen durch Kontextverdichtung verloren und wurden aus den persistierten Tool-Outputs (`tool-output\tool_06b146fd…`, `tool_06b3168…`, `tool_06b1e541…`, `tool_06b41236…` u. a.) verlustarm rekonstruiert; Erstanwort des swrs-autor war leer und wurde per Session-Fortsetzung nachgeliefert.
|
||||
|
||||
## 2. Modulinventar (Schritt 0)
|
||||
|
||||
43 Module: M001 Centron.BL · M002 Common · M003 DAO · M004 Entities · M005 Gateway · M006 Interfaces · M007 WPF-UI (Shell+Cluster) · M008 WPF-UI.Extension · M009 Calendar · M010 Dashboard · M011 ExternalTool · M012 PayersAndCostCenter · M013 ProjectPriceImport · M014 QM · M015 Logistic · M016 Commissioning/Commissions/AccountSystems · M017 DeviceClickCounter · M018 ContractEvaluation2 · M019 Host · M020 Host.Console · M021 Host.WindowsService · M022 Controllers · M023 WebServices.Core · M024 ConnectionManager · M025 EbInterface · M026 GLS · M027 Shipcloud · M028 CopDataAccess · M029 EgisDataAccess · M030 IcecatDataAccess · M031 ITscopeDataAccess · M032 FinAPI · M033 Controls · M034 Controls.Preview · M035 Core · M036 CentronNexus · M037 Nexus.Host · M038 OutlookAddIn · M039 docuFORM · M040 Telemetrie · M041 Scripts · M042 Deployment/Installer · M043 Datenbank-Schema.
|
||||
Reste: 378 Dateien = Testcode (bewusst nicht zugeordnet); docs/, Konfiguration, Binares, Pipelines außerhalb der Modulzählung (belegt durch modulinventar).
|
||||
|
||||
## 3. Abdeckungstabelle (Modul → Anforderungen, repräsentativ)
|
||||
|
||||
| Modul | Anforderungen (repräsentativ) | Modul | Anforderungen |
|
||||
|---|---|---|---|
|
||||
| M001 | SwRS-001…023, SyRS-041…053 | M023 | SwRS-043, 049; SyRS-023 |
|
||||
| M002 | SwRS-056 | M024 | SwRS-072 |
|
||||
| M003 | SwRS-045…049, SyRS-024 | M025 | SwRS-032 |
|
||||
| M004 | SwRS-057 | M026 | SyRS-033 |
|
||||
| M005 | SwRS-024…031, SyRS-028 | M027 | SyRS-030, 033 |
|
||||
| M006 | SwRS-058 | M028 | SyRS-037 (Fremddaten Beschaffung) |
|
||||
| M007 | SwRS-017, 022, 036, 039, 041, 054, 059…069 | M029 | SyRS-030 |
|
||||
| M008 | SwRS-059 | M030 | SyRS-037 |
|
||||
| M009 | SwRS-060 | M031 | SyRS-030 (ITscope) |
|
||||
| M010 | SwRS-061 | M032 | SyRS-034 |
|
||||
| M011 | SwRS-062 | M033 | SwRS-073 |
|
||||
| M012 | SwRS-063 | M034 | SwRS-074 |
|
||||
| M013 | SwRS-064 | M035 | SwRS-041 (Totp) |
|
||||
| M014 | SwRS-065 | M036 | SyRS-007, 038 |
|
||||
| M015 | SwRS-066 | M037 | SwRS-075 |
|
||||
| M016 | SwRS-067 | M038 | SwRS-076 |
|
||||
| M017 | SwRS-068 | M039 | SyRS-035 |
|
||||
| M018 | SwRS-069 | M040 | StRS-048, SyRS-031, SwRS-055 |
|
||||
| M019 | SwRS-051, 052, 054; SyRS-001…008 | M041 | SwRS-077 |
|
||||
| M020 | SwRS-070 | M042 | SwRS-078 |
|
||||
| M021 | SwRS-071 | M043 | SyRS-026/027, SwRS-013, 029, 030 |
|
||||
|
||||
**Ergebnis: 43/43 Module ≥ 1 Anforderung; Module ohne Anforderung: 0; Anteil „nicht analysiert" 0 %.** (Die zehn WPF-Cluster M009–M018 und die Infra-Module M020/021/024/033/034/037/038/041/042 wurden im Batch I nachermittelt, nachdem der Erstbestand sie nicht reachte.)
|
||||
|
||||
## 4. ID-Bestände und Lückenprüfung
|
||||
|
||||
- StRS 001–050: lückenlos, keine Doppelvergabe (ISO-Befund O-1, nachprüfung 50/50).
|
||||
- SyRS 001–054: lückenlos (041–054 = N-1-Ergänzung).
|
||||
- SwRS 001–078: lückenlos (056–078 = Modulabdeckung).
|
||||
- Alle Tracelinks referenzieren existierende IDs; Traceability.md führt alle 182 Anforderungen mit Eltern/Kindern.
|
||||
|
||||
## 5. Belegprüfung und Nahtstellen — Ergebnisse
|
||||
|
||||
**belegpruefer (226 geprüfte [PRIMÄR]-Stellen der risikorelevanten Anforderungen):**
|
||||
- SwRS-Ebene: 121/122 TRAGT. Abweichung SwRS-048 „GenericDAO 225-226" → korrigiert auf SaveReceiptInvoiceRepository 225-226.
|
||||
- SyRS-Ebene: 95/103 TRAGT; 2 nicht gedeckte Stellen korrigiert (SyRS-005 CentronRestService-Zeilen; SyRS-016 MandatorBL-Anteil); 6 reine Fakten-ID-Belege als [Faktenkatalog]-Label nachkennisiert bzw. zu Indizes abgestuft (SyRS-019 G-F01, SyRS-022 G-F09, SyRS-025 C-F10).
|
||||
- StRS-Ebene: 0 Treffer für „risikorelevant" — die StRS-Ebene trägt diese Markierung per Definition nicht; die risikorelevanten StRS-Gegenstände wurden über ihre SyRS/SwRS-Kinder geprüft. Keine StRS-Korrektur nötig.
|
||||
- Nebenbefunde (nicht korrigiert, dokumentiert): „ExecuteValidateTicket" existiert nicht (SwRS-040 präzisiert), kleine Zeilenfenster-Ränder (SwRS-012/019/040), SwRS-044 Label „Wurfstellen" für Rechtsprüfstellen.
|
||||
|
||||
**iso29148-orchestrator:** B-1 (4 Pflichtdateien fehlten → jetzt vorhanden), B-2 (SyRS-021/030 falsch als Lücke verbucht → relinkt auf StRS-050/049), B-3 (Hypothese-Tagging deckungsgleich gemacht → Hypothesen.md), B-4 (SwRS-055 Lückenfelder → aus Aussage/Eltern ergänzt, als Vermerk gekennzeichnet), N-1 (14 StRS ohne SyRS-Kind → SyRS-041–054). Alle Blocker abgearbeitet.
|
||||
|
||||
**konsistenzpruefer (Erstlauf):** 48 Verstöße — 1 Pflichtfeldlücke (SwRS-043 ohne Prüfidee, aus der Quell-Ausgabe rekonstruiert eingesetzt) und 47 in Traceability.md, dessen Tabellen nie auf den SwRS-Nachschnitt 056–078 nachgezogen waren (Bestandsangabe, 23 fehlende Elternzeilen, 18 fehlende/1 falsche §2-Kanten, veraltete §4-Aussagen). **Nachprüfung:** alle Nachzüge bestätigt; 2 Restverstöße (elternlose Zahl 5 statt 6 — SwRS-074; Phantomkante StRS-009→SwRS-073) wurden unmittelbar behoben. Die drei Anforderungsdokumente waren bereits im Erstlauf unter sich konsistent (0 Verstöße bei ID-Integrität, Tracelink-Validität über 600 Referenzen, Hypothesen-Deckung bidirektional, Status-Wörterbuch). Beobachtung ohne Befundwert: 44 funktionale StRS-Blöcke führen das Qualitätsmerkmal-Feld leer (uneinheitliche Konvention StRS ↔ SyRS/SwRS).
|
||||
|
||||
## 6. Offene Punkte und Selbstbewertung
|
||||
|
||||
### 6.1 Modulinventar-Drift
|
||||
Der Erstlauf erzeugte ein Inventar mit 38 Modulen; dessen Output ging durch Kontextverdichtung verloren und wurde neu erstellt (jetzt 43 Module, andere Nummerierung, vollständig mit Restebuchführung). Alle Abdeckungsangaben dieses Berichts beziehen sich auf die Version M001–M043.
|
||||
|
||||
### 6.2 Bekannte, nicht behebbare Lücken (Stand des Laufs)
|
||||
- **StRS-Vollwaisen (7):** StRS-025, 031, 039, 041, 042, 045, 046 haben kein Kind — fachliche Klärung (Soll überhaupt gefordert?) steht beim Auftraggeber; Neuentwurf gegen Faktenbasis wäre ohne neuen Fakt erfinderisch.
|
||||
- **SyRS ohne StRS-Eltern (4+1):** SyRS-007 (Transportabschottung), -032 (DSGVO-Löschung; SwRS-044 existiert), -039 (Build/Testbarkeit), -040 (Webserver-Bindung) sowie SyRS-037 (nur Kontext-Bezug).
|
||||
- **SyRS ohne SwRS-Kind (10):** s. Traceability.md §4; Sicherheits-/Abrechnungsrelevante nachziehen, wenn gefordert.
|
||||
- **Fakt-ID-Kollisionen (ISO N-4):** B-F004/B-F010/B-F011/B-F021/B-F022/B-F023/B-F031 und A-F35 bezeichnen in verschiedenen Ebenen-Auszügen verschiedene Stellen, weil Faktenkataloge verlustbedingt aus verschiedenen Erhebungsständen zitiert wurden. Belegstellen sind stets mit Code-Zeilenangaben dublettenfrei; die Kurz-IDs sind bis zu einer Bereinigung nicht ebenenübergreifend eindeutig.
|
||||
- **Doubletten (N-5):** Ticket-Gültigkeit dreifach (SyRS-002/003 + SwRS-040, verlinkt); CH-Rundung jetzt fünf Implementierungen (SwRS-005 + MathUtils SwRS-056); Skonto-Familie StRS-016/SyRS-044/SwRS-008/009. Bewusst nicht eigenmächtig zusammengeführt.
|
||||
- **Ebenenfehler (N-6):** SyRS-032 enthält Implementierungsdetail (SwRS-044 trägt es bereits korrekt); SyRS-026/027 mit Constraint-Sprache (SwRS-013/045 tragen die Umsetzung).
|
||||
- **Offene Fachfragen:** gesammelt in Hypothesen.md (13 volle Hypothesen, 12 Teil-Hypothesen), u. a. Skonto-Abzugsmechanik, Zählerpreisgrenze, EDI-Summentoleranz, SEPA-Mandatslücke, Telemetrie-Opt-out.
|
||||
|
||||
### 6.3 Selbstbewertung
|
||||
- **Stärken:** 182 Anforderungen durchgängig im Blockformat; jede Anforderung mit Akteur, Vorbedingung, Fakt/Beleg, Prüfidee, Status; Belegqualität risikorelevanter Stellen durch unabhängige Prüfung verifiziert (96 % TRAGT Quote, Korrekturen eingearbeitet); Modulabdeckung vollständig; Widersprüche und Parallelimplementierungen (Konsolidierungsfelder) sind systematisch ausgewiesen, nicht eingeebnet; Hypothesen von belegten Fakten sauber getrennt.
|
||||
- **Schwächen:** die sieben StRS-Vollwaisen und vier Eltern-Lücken-SyRS sind unübersehbare Restlücken der RÜCKWÄRTS-Kette; Fakt-ID-Kurzbelege nicht global eindeutig; einzelne Zeilenfenster der Belege um wenige Zeilen ungenau; Modulinventar-Nummerierung liefbedingt neu aufgebaut.
|
||||
- **Restrisiko für die Übernahme:** Die konsolidierten Regeltexte (Aussagen) sind überprüfbar; vor Implementierungsbeginn sind die 25 offenen Fachfragen zu klären, da sie andernfalls als undefinierte Verhaltenszustände (stille Rückfälle, tolerierte 0-Beträge, durchlässige Prüfungen) zementiert würden.
|
||||
|
||||
### 6.4 Dateiübersicht dieses Laufs
|
||||
StRS.md (50) · SyRS.md (54) · SwRS.md (78) · Traceability.md · Hypothesen.md (13+12) · Glossar.md (ca. 30 Leitbegriffe, 4 Drift-Gruppen) · Analysebericht.md (diese Datei). Zusatz-/Aufteilungsdateien wurden bewusst nicht angelegt.
|
||||
+44
@@ -0,0 +1,44 @@
|
||||
# Glossar
|
||||
|
||||
Quelle: Orchestrator (Versuch 02, Prompt 03-A). Leitbegriffe für den Bestand StRS/SyRS/SwRS; bei Terminologie-Drift (ISO-Nahtstellenprüfung N-7) ist der Leitbegriff fett, die vorkommenden Synonyme sind mit den betroffenen Anforderungs-IDs belegt.
|
||||
|
||||
## Kernbegriffe des Mandanten-/Zugriffsmodells
|
||||
|
||||
- **Mandant** (Leitbegriff; Synonyme: *Mandator*, *Tenant*): rechtlich-getrennter Kundenkreis eines ERP-Systems. Belegte Drift: „Mandant" (StRS-010, SyRS-016), „Mandator" als Code-Begriff (MandatorMaps, MandatorBL; SyRS-016/027, SwRS-048). **Abzugrenzen:** `MandatorBankNumber` ist eine SEPA-Mandatsreferenz, KEIN Mandantenbezug (SyRS-029) — drei Bedeutungen desselben Wortstamms.
|
||||
- **Filiale** (Synonym im Code: *Branch*, *Filialgeber*): organisatorische Einheit innerhalb eines Mandanten; Filialgrenze = MANAGE_RIGHTS_ONLY_OWN_BRANCH (SyRS-016, SwRS-020/034).
|
||||
- **Benutzer** (Leitbegriff für interne Nutzer; Synonyme: *AppUser*, *currentUser*, „Mitarbeiter"): angemeldeter Mitarbeiter der WPF-/Webservice-Clients (StRS-001/006, SwRS-021).
|
||||
- **Portal-Konto** (Leitbegriff; Synonyme: *WebAccount*, „Kunde (Web-Account)"): externer Kunde mit Portalzugang; rechtlich an einen Ansprechpartner gekoppelt (StRS-009/041, SyRS-013/017, SwRS-033/039).
|
||||
- **Recht** (Synonyme: *Einzelrecht*, *Gruppenrecht*, Rechts-ID wie 10530): Befugnis; Regel ist das Gruppenmodell, Direktrechte sind der zu beseitigende Seiteneingang (SyRS-013, SwRS-021/033).
|
||||
|
||||
## Belegwelt
|
||||
|
||||
- **Beleg** (Überbegriff): Angebots-/Auftrags-/Lieferschein-/Rechnungs-/Gutschein-/Vertragsdokument mit Versionierung (SyRS-027, SwRS-016).
|
||||
- **Rechnungsnummer** (Leitbegriff; Synonyme im Code: *RechKopf.Nummer*, *invoiceId* im DATEV-Export, *ExternalInvoiceNumber*): fortlaufendes Ordnungsmerkmal je Nummerkreis (Bar/Normal/Intern) und Filiale (StRS-024, SwRS-013/029).
|
||||
- **Nummernkreis** (Code: *NummernkreisTabelle*, Schlüssel NummerArt+MandantI3D+BranchI3D+FilialI3D): Zählwerk pro Gruppe/Mandant/Filiale (SyRS-026, SwRS-013).
|
||||
- **Vorversion / Datenbankfassung**: vorige gespeicherte Belegversion, Bezugspunkt für Differenzbuchung und Mengenrest (SyRS-047/050, SwRS-016/018).
|
||||
- **Storno**: Ausschluss einer Rechnung als neue Version mit Menge 0 unter Erhalt des Originals; kein Löschen, kein Ent-Storno (StRS-023, SyRS-048, SwRS-014).
|
||||
- **Mahnstopp**: zeitlich befristete Ruhigstellung eines Kontos im Mahnwesen, rechtspflichtig pflegbar (SyRS-045, SwRS-012).
|
||||
- **Kunst-Kostenstelle**: leerer Platzhalter für positionslose Kopfanteile im FiBu-Export; wird bei der finalen Satzberechnung zurückgebaut (SwRS-028).
|
||||
|
||||
## Preis- und Betragswelt
|
||||
|
||||
- **Grundpreis-Kaskade** (auch VK-Kaskade): feste Rangfolge Vertrags-Sonderpreis > Kunden-Sonderpreis > Staffelpreis > Preislistenstufe (SyRS-041, SwRS-001).
|
||||
- **EK-Kaskade / Bezugspreis**: Einkaufsseiten-Kaskade Sondervereinbarung > Lager-EK > Staffelpreis-EK (SyRS-043, SwRS-006).
|
||||
- **Skontostufe** (1./2. mit Prozent, 3. nur Tage — offenzulegende Regel): zweistufige Prozent-Regel BR-DE-18 (SyRS-044, SwRS-008/009).
|
||||
- **5-Rappen-Rundung** (Synonyme: *CommercialRoundCH*, Stammdat 1113): Schweizer Endrundung auf die Steuer; Soll: genau eine Implementierung (SwRS-005, SyRS-028).
|
||||
- **Precision / precision=-1**: Artikel-Rundungspräzision; -1 bedeutet „keine Zwischenrundung" (SwRS-003).
|
||||
- **Zahlkondition** (Code: *Zahkond*): Zahlungsbedingung mit Skonto-, Fälligkeits- und SEPA-Lastschrift-Kennzeichen (SyRS-054, SwRS-007/030).
|
||||
|
||||
## Technikbegriffe mit Fachbedeutung
|
||||
|
||||
- **IgnoreCallbacks**: interner Hebel, der Beleg-Nebenwirkungen (u. a. Limitprüfung) abschaltet; missbrauchskritisch, für Negativbuchungen ausdrücklich wirkungslos (SyRS-046/051, SwRS-011/014/019).
|
||||
- **Fremd-Login (BasicAuthObject)**: Vier-Augen-Bestätigung durch einen zweiten Berechtigten bei Negativbuchungen (SyRS-051, SwRS-019).
|
||||
- **Ticket** (Synonym: *ConnectionTicket*): Sitzungsmerkmal 30 min mit Refresh ab 5 min, Gültigkeit 24 h; Validierung incl. Ablaufprüfung gefordert (SyRS-002/003, SwRS-040).
|
||||
- **Merk-2FA**: Fristverlängerung des zweiten Faktors je (Benutzer, App, Maschine, IP) (SyRS-012, SwRS-041).
|
||||
- **Fail-closed**: Rechtsprüfung entscheidet Fehler und leere Rights immer gegen Zugriff (SyRS-017, SwRS-037).
|
||||
- **GUI3D / ConcurrencyControlGuid**: rotierendes Sperr-Token im Belegkopf für die optimistische Sperre; NULL ist Konfliktfall (SwRS-045).
|
||||
- **EXTF / DATEV-Format 700**: Buchungsimport-Format (Header 700, Feldlängen 36, Kodierung 1252) (SwRS-029).
|
||||
- **Telemetrie**: 15-min-Upload der Installation an den Hersteller (DatabaseGuid, HardwareIds, UserID, LicenseGuids); Soll: Offenlegung, Minimum, Opt-out (StRS-048, SyRS-031, SwRS-055).
|
||||
- **Datenbank-GUID** (service_broker_guid): maschinenbezogene Kennung in der Telemetrie, kein Personenbezug ersten Grades (SyRS-031, SwRS-055).
|
||||
- **Belegstatus-Mengenrest**: Abschlussregel Rest ≤ 0 auf 7 Stellen; Rabatt-/Fracht-/Ausgleichspositionen zählen als erledigt (SyRS-047, SwRS-016).
|
||||
- **Kontingent** (Stunden-/Geldkontingent): Vertragsfreimenge mit 9-Stellen-Verzehr und gedecktem Anteil (SyRS-052, SwRS-022).
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
# Hypothesen
|
||||
|
||||
Quelle: Orchestrator-Sammeldatei (Versuch 02, Prompt 03-A). Deckungsgleich mit allen Hypothese-Markierungen in StRS.md, SyRS.md und SwRS.md. Stand nach der ISO-29148-Nahtstellenbereinigung: Jede Anforderung mit Status „HYPOTHESE" trägt zusätzlich den Inline-Tag [HYPOTHESE] im Belege-Feld; Teil-Hypothesen (Status „belegt" mit ausgewiesenem HYPOTHESE-Anteil) sind in Abschnitt B gesondert geführt.
|
||||
|
||||
## A. Anforderungen mit Status „HYPOTHESE" (13)
|
||||
|
||||
| ID | Ebene | Gegenstand | Begründung | Offene Frage |
|
||||
|---|---|---|---|---|
|
||||
| StRS-007 | StRS | Schutz vor wiederholten Anmeldeversuchen (Brute-Force) | Kein Fakt über vorhandene oder gewollte Schutzmechanik | Existiert ein Anmeldeversuchszähler oder ist er fachlich gefordert? |
|
||||
| StRS-016 | StRS | Skonto mindert den Zahlungsbetrag | Skontobetragsminderung nirgends als durchsetzend gefunden, nur Format | Wird Skonto nur informativ auf der Rechnung ausgewiesen oder im Zahlungsausgleich berechnet? |
|
||||
| StRS-024 | StRS | Manipulationssichere Fortschreibung der Rechnungsnummernkreise | Fortschreibung und Vergabe des Nummernkreises nicht durchgehend belegt, D-F02 trägt HYP | Wird der Kreis manipulationssicher und lückenlos fortgeschrieben? |
|
||||
| StRS-038 | StRS | Zollangaben bei Ausfuhren | Beleg nur für fehlende Umsetzung, nicht für gewollten Soll-Zustand | Werden Ausfuhren im Haus verzollt oder durch Spediteure? |
|
||||
| StRS-048 | StRS | Offenlegung und Begrenzung der Telemetrie | Kein Beleg, ob Telemetrie vertraglich gewollt/begrenzt ist | Ist ein Opt-out fachlich/vertraglich gefordert? |
|
||||
| StRS-050 | StRS | Rollenprüfung für Wartungs-/Migrierungsskripte | Kein Beleg dafür, dass eine Rollenprüfung für Wartungsskripte fachlich gewollt ist | Wer im Betrieb darf Strukturänderungen anstoßen? |
|
||||
| SyRS-010 | SyRS | Brute-Force-Schutz (Schwellwert/Sperrung) | Nicht-Auffindbarkeit als einziger Anhalt | Sind Schwellwert, Sperrdauer und Zählerquelle fachlich festgelegt? |
|
||||
| SyRS-011 | SyRS | Durchsetzung der Passwort-Ablauffrist | Durchsetzung der Ablaufprüfung nicht belegt, nur die Pflege der Frist | Soll die Ablaufregel global, je Mandant oder je Kontotyp gelten? |
|
||||
| SyRS-040 | SyRS | Webserver-Bindung und Request-Body-Grenze | Befund nur [K], kein Beleg für gewolltes Soll | Existiert ein Reverse-Proxy, der Bindung und Body-Größe steuert? |
|
||||
| SyRS-044 | SyRS | Regelgebundene Skonto-Betragsminderung im Zahlungsausgleich | Betragsminderung nirgends als durchsetzend belegt; Belege tragen nur Format, Modell und Separierung | Wird Skonto nur auf dem Beleg ausgewiesen oder im Zahlungsausgleich berechnet? |
|
||||
| SwRS-009 | SwRS | Skontoabzug und Skonto-Ausschlussrechnung | Kein PRIMÄR-Beleg für eine Abzugsstelle, aber auch nicht für bewusste Abwesenheit | Wird Skonto nur auf der Rechnung ausgewiesen oder im Zahlungsausgleich berechnet? |
|
||||
| SwRS-057 | SwRS | DSGVO-Markierung per IsDsgvoSetNullAttribute als Löschmechanismus | Attribut vorhanden, 0× angewendet; aus dem Negativbefund folgt kein belegtes Soll | Ist attributgesteuertes Freischalten als DSGVO-Mechanismus vorgesehen oder Altbestand? |
|
||||
| SwRS-074 | SwRS | Konnektoren der Preview-Shell funktionsfähig implementieren | Wurfstellen PRIMÄR belegt, Produktbezug wegen Testzweck der Shell offen | Gehören die drei Konnektoren zum Zielumfang oder nur zur Preview-Shell? |
|
||||
|
||||
## B. Teil-Hypothesen (Status „belegt" mit ausgewiesenem [HYPOTHESE]-Anteil) (12)
|
||||
|
||||
| ID | Ebene | Hypothetischer Anteil | Offene Frage |
|
||||
|---|---|---|---|
|
||||
| SyRS-014 | SyRS | Aufruferseite der Zuweisungs-APIs (B-F007 P+HYP) | Wird die ungeprüfte API tatsächlich ohne vorgelagerte Prüfung erreicht? |
|
||||
| SyRS-016 | SyRS | DeleteWithI3DReturn-Defektverdacht (C-F24 P+HYPOTHESE) | Nutzen die Aufrufe TEntity-Vererbung, sodass die Typabweichung schädlich wirkt? |
|
||||
| SyRS-041 | SyRS | Soll-Verhalten bei unbekannter Preislistenstufe (A-F01-Lücke) | Fehler oder definierter Rückfall? |
|
||||
| SyRS-043 | SyRS | Gegenwertbehandlung bei 100-%-Rabatt in der EK/VK-Kopplung (A-F30-Lücke) | Wie ist der Gegenwert bei 100 % Rabatt fachlich zu bestimmen? |
|
||||
| SyRS-046 | SyRS | Protokollierung der Kreditlimit-Fortsetzungsentscheidung (A-F18) | Ist eine Protokollpflicht für Fortsetzungsentscheidungen fachlich gewollt? |
|
||||
| SyRS-048 | SyRS | Limitprüfungs-Umgehung im Storno (A-F14-Lücke) | Gilt die Limitgrenze auch für Stornovorgänge? |
|
||||
| SyRS-052 | SyRS | Höhe der Zählerpreis-Obergrenze (G-F20-Lücke) | Welcher Betragswert begrenzt den Zählerpreis fachlich? |
|
||||
| SyRS-053 | SyRS | Höhe der EDI-Summentoleranz (A-F27-Lücke) | Welche Abweichung ist zwischen Auftrag und EDI-Beleg fachlich zulässig? |
|
||||
| SyRS-054 | SyRS | Sperrwirkung bei SEPA-Mandatslücke (D-F85) | Ist der Fallback auf die Standardverbindung mandatiert oder zu blockieren? |
|
||||
| SwRS-034 | SwRS | Aufruferseite der Rechte-Zuweisungs-APIs | Gleiche Frage wie SyRS-014 (Ebene SwRS). |
|
||||
| SwRS-048 | SwRS | DeleteWithI3DReturn: schädliche Wirkung des Typverstoßes | Gleiche Frage wie SyRS-016 (Ebene SwRS). |
|
||||
| SwRS-076 | SwRS | Upload-Fehlerwirkung (Alert vs. Abbruch) — abweichendes Soll unbelegt | Soll der Upload bei Warnung abbrechen oder ausdrücklich übernommen werden? |
|
||||
|
||||
Hinweis: SwRS-057 und SwRS-074 führen den [HYPOTHESE]-Tag im Belege-Feld und zugleich Status „HYPOTHESE"; sie sind daher nur in Abschnitt A geführt.
|
||||
|
||||
## C. Abgrenzung
|
||||
|
||||
- Die 16 dokumentierten Code-Widersprüche ([Widerspruch]-Markierungen, z. B. doppelte Fälligkeitsregel, divergierende Saldoformel, vier CH-Rundungsimplementierungen) sind **keine** Hypothesen, sondern belegte Ist-Befunde und werden im Analysebericht unter Konsolidierung geführt.
|
||||
- Der Transkriptionsvermerk zu SwRS-055 in SwRS.md betrifft eine Überlieferungslücke, keine fachliche Hypothese; die vervollständigten Folgefelder sind aus Aussage und Elternanforderungen (StRS-048, SyRS-031) abgeleitet und als Vermerk gekennzeichnet.
|
||||
+903
@@ -0,0 +1,903 @@
|
||||
# StRS – Stakeholder-Anforderungen
|
||||
|
||||
Quelle: strs-autor (formuliert aus den Fakten-Batches A–H); übernommen unverändert bis auf offensichtliche Tippfehler.
|
||||
|
||||
- **StRS-001 — Fachliche Berechtigungen werden ausschließlich über Gruppen verliehen**
|
||||
- ID: StRS-001
|
||||
- Titel: Fachliche Berechtigungen werden ausschließlich über Gruppen verliehen
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Administrator, Mitarbeiter
|
||||
- Vorbedingung: Ein Mitarbeiter soll auf eine Fachfunktion zugreifen
|
||||
- Fakt: AppRightsBL Zt.63-87[P]: Rechte nur über Gruppen; G-F01[P]: Modul erscheint nur bei Recht+Lizenz, Rechtefehler→keine Module
|
||||
- Aussage: Das System soll fachliche Zugriffs- und Bearbeitungsrechte ausschließlich über Gruppen zuweisen, denen Mitarbeiter zugeordnet sind, und einem Mitarbeiter ohne zugeordnetes Recht die betreffende Fachfunktion weder anzeigen noch ausführen lassen.
|
||||
- Ergebnis: Nachvollziehbare, personenunabhängige Rechtevergabe; kein Mitarbeiter sieht Funktionen, für die er nicht freigegeben ist.
|
||||
- Belege: [PRIMÄR] AppRightsBL Zt.63-87 — durchsetzende Stelle der Rechtevergabe; [PRIMÄR] G-F01 — clientseitige Durchsetzung beim Modulaufruf.
|
||||
- Prüfidee: Mitarbeiter ohne Recht „Rechnung anlegen“ aufrufen → Modul/ Schaltfläche nicht sichtbar, Aufruf der Funktion wird verweigert; nach Gruppenzuweisung mit Recht ist derselbe Aufruf erfolgreich.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (Sammelkandidat für G-F01, G-F33-Statistikrechte)
|
||||
- Übernahmewürdigkeit: hoch — Kern des Berechtigungsmodells, mehrfach PRIMÄR belegt.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-002 — Filialgrenze begrenzt Datenzugriff und Rechteverwaltung**
|
||||
- ID: StRS-002
|
||||
- Titel: Filialgrenze begrenzt Datenzugriff und Rechteverwaltung
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Filialverantwortlicher Mitarbeiter, Administrator
|
||||
- Vorbedingung: Mandant mit mehreren Filialen; Mitarbeiter ist einer Filiale zugeordnet
|
||||
- Fakt: A-F25 ReceiptBL Zt.10272-10311[P]: Recht je Belegart, Filialgrenze; B-F004 Zt.39-48[P]: MANAGE_RIGHTS_ONLY_OWN_BRANCH; B-F011 Zt.148-291[P]: Helpdesk nur-eigene/nur-Filiale-Rechte durchgesetzt; G-F28[P]: Filialrechte Zeiten
|
||||
- Aussage: Das System soll den Zugriff auf Belege, Tickets und Kundenzeiten sowie die Rechteverwaltung auf die Filialen beschränken, für die ein Mitarbeiter freigegeben ist.
|
||||
- Ergebnis: Filialverantwortliche sehen und verwalten nur ihre eigenen Geschäftsdaten.
|
||||
- Belege: [PRIMÄR] ReceiptBL Zt.10272-10311, Authenticator-Stelle B-F004 Zt.39-48, B-F011 Zt.148-291 — jeweils durchsetzende Prüfstellen.
|
||||
- Prüfidee: Mitarbeiter der Filiale A ist Recht „Kundenbelege ansehen“ globally zugeordnet → Beleg eines Kunden mit Bezug nur zu Filiale B muss bei Anzeige und Bearbeitung verweigert werden; in der Filiale A darf er keine Rechte für Filiale B vergeben.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (konsolidiert A-F25, B-F004, B-F011, G-F28)
|
||||
- Übernahmewürdigkeit: hoch — zentrales Geschäftsorganisationsprinzip, vier unabhängige PRIMÄR-Belege.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-003 — Zugriffsentscheidung ist im Fehlerfall ablehnend (Fail-Closed)**
|
||||
- ID: StRS-003
|
||||
- Titel: Zugriffsentscheidung ist im Fehlerfall ablehnend (Fail-Closed)
|
||||
- Ebene: StRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Zuverlässigkeit der Zugriffskontrolle)
|
||||
- Akteur: System, Mitarbeiter, externe Aufrufer (API)
|
||||
- Vorbedingung: Eine Zugriffskontrolle kann nicht eindeutig entschieden werden (Fehler, fehlende Konfiguration)
|
||||
- Fakt: B-F010 UserRightsExt Zt.18-32[P]: Fail-Closed bei Fehler; E-F01[P]: API-Autorisierung Recht/401/403
|
||||
- Aussage: Das System soll jede Zugriffs- oder Berechtigungsanfrage ablehnen, die es nicht eindeutig als berechtigt bestätigen kann; weder interne Fehler noch fehlende Konfiguration dürfen den Zugriff gewähren.
|
||||
- Ergebnis: Kein unberechtigter Zugriff durch Ausfallsituationen der Prüfung.
|
||||
- Belege: [PRIMÄR] UserRightsExt Zt.18-32 — durchsetzende Fehlerbehandlung; [PRIMÄR] E-F01 — API-Seite mit 401/403-Abgrenzung.
|
||||
- Prüfidee: Rechtetable/Rechteprüfung fehlerhaft konfigurieren (Rechtsinformation nicht ermittelbar) → geschützte Aktion und API-Aufruf müssen scheitern (403), nicht durchgewinkt werden.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — sicherheitskritische Grundregel, zwei PRIMÄR-Stellen.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-004 — Admin-Gruppe und Admin-Rechte sind gegen Änderung und Entzug geschützt**
|
||||
- ID: StRS-004
|
||||
- Titel: Admin-Gruppe und Admin-Rechte sind gegen Änderung und Entzug geschützt
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: System, Administrator
|
||||
- Vorbedingung: Es existieren administrative Gruppe und administrative Rechte
|
||||
- Fakt: B-F005/6 Zt.348-404[P,HYP]: Admin-Gruppe I3D 6/Name geschützt; B-F007 Zt.261-299/714-759[P]: Admin-Rechte nur per Whitelist; G-F29[P]: Adminschutz Gruppen
|
||||
- Aussage: Das System soll die vordefinierte administrative Gruppe vor Löschung und Umbenennung schützen und administrative Rechte nur über eine festgelegte Whitelist verleihbar machen.
|
||||
- Ergebnis: Der Mandant bleibt administrativ handlungsfähig; niemand kann sich selbst oder anderen die Systemverwaltung entziehen.
|
||||
- Belege: [PRIMÄR] B-F007 Zt.261-299/714-759 — durchgesetzte Whitelist; [PRIMÄR] B-F005/6 Zt.348-404 — Gruppenschutz. Teilaspekt „asynchrones Anlegen vs. Löschen“ bleibt offen (HYP im Fakt).
|
||||
- Prüfidee: Löschen/Umbenennen der Admin-Gruppe I3D 6 versuchen → Aktion muss abgewiesen werden; Versuch, ein Admin-Recht außerhalb der Whitelist einer Gruppe zu geben → Vergabe scheitert.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (B-F005/6, B-F007, G-F29)
|
||||
- Übernahmewürdigkeit: hoch — Selbstschutz des Systems; HYP-Teilpunkt betrifft nur Nebenverhalten.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-005 — Änderungen an Berechtigungen werden protokolliert**
|
||||
- ID: StRS-005
|
||||
- Titel: Änderungen an Berechtigungen werden protokolliert
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Prüfer / Revision, System
|
||||
- Vorbedingung: Ein Berechtigungsstatus wird geändert
|
||||
- Fakt: B-F029 Zt.762-781[P]: SichProtokoll Audit bei Rechteänderung; C-F23[P/S]: drei uneinheitliche Audit-Konventionen
|
||||
- Aussage: Das System soll jede Änderung an Rechten, Gruppen und Zuordnungen mit Verursacher und Zeitpunkt so protokollieren, dass sie für eine spätere Prüfung rekonstruierbar ist, und dabei eine einheitliche Protokollierungssystematik verwenden.
|
||||
- Ergebnis: Berechtigungsänderungen sind lückenlos nachvollziehbar.
|
||||
- Belege: [PRIMÄR] B-F029 Zt.762-781 — Schreibstelle des Auditprotokolls; [SEKUNDÄR] C-F23 — Uneinheitlichkeit nur beobachtet, keine durchsetzende Stelle.
|
||||
- Prüfidee: Recht einer Gruppe hinzufügen und wieder entfernen → Protokoll muss beide Änderungen mit Benutzer, Zeitstempel und Objekt enthalten; Konvention (Feldaufbau) ist über alle erfassten Änderungen identisch.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein; Kandidat zur Zusammenführung mit StRS-003-Prüfpfad
|
||||
- Übernahmewürdigkeit: hoch — Auditierbarkeit ist Prüfvoraussetzung.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-006 — Anmelde- und Passwortregeln schützen die Konten**
|
||||
- ID: StRS-006
|
||||
- Titel: Anmelde- und Passwortregeln schützen die Konten
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Mitarbeiter, Kunde (Web-Account), System
|
||||
- Vorbedingung: Ein Benutzer meldet sich an oder ändert sein Passwort
|
||||
- Fakt: B-F014 WebAccountBL Zt.54-105[P]: Login-Prüfung+Status+Sperre; B-F015 Authenticator Zt.157-218[P]: Sperrfenster KontoDeaktiviert; B-F018 UsersBL Zt.56-129[P]: aktuelles PW nötig, externe Auth gesperrt, Mindestlänge, WebAccount min 8
|
||||
- Aussage: Das System soll die Anmeldung nur bei korrekten Nachweisen und aktivem Kontostand gewähren, gesperrte Konten für die Sperrdauer ablehnen, beim Passwortwechsel den Nachweis des bisherigen Passworts verlangen und eine Mindestlänge erzwingen, sofern eine solche gepflegt ist.
|
||||
- Ergebnis: Konten sind gegen Übernahme durch Unbefugte gesichert.
|
||||
- Belege: [PRIMÄR] WebAccountBL Zt.54-105, Authenticator Zt.157-218, UsersBL Zt.56-129 — jeweils durchsetzende Prüfstellen.
|
||||
- Prüfidee: Konto mit Sperrvermerk innerhalb des Sperrfensters anmelden → Anweisung ablehnen; Passwortwechsel ohne korrektes aktuelles Passwort → Vorgang fehlschlagen; WebAccount-Passwort mit 7 Zeichen → Annahme verweigern.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (B-F014, B-F015, B-F018)
|
||||
- Übernahmewürdigkeit: hoch — drei PRIMÄR-Stellen, Basisidentitätsschutz.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-007 — Wiederholte fehlgeschlagene Anmeldeversuche sind zu begrenzen**
|
||||
- ID: StRS-007
|
||||
- Titel: Wiederholte fehlgeschlagene Anmeldeversuche sind zu begrenzen
|
||||
- Ebene: StRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Schutzbedarf)
|
||||
- Akteur: System, Angreifer (extern)
|
||||
- Vorbedingung: Ein Anmeldekanal wird wiederholt mit falschen Nachweisen belegt
|
||||
- Fakt: B-F031 HYP: kein Brute-Force-Schutz auffindbar
|
||||
- Aussage: Das System soll wiederholte fehlgeschlagene Anmeldeversuche identifizieren und den weiteren Anmeldeversuch zeitweise unterbinden oder zusätzlich absichern.
|
||||
- Ergebnis: Konten sind gegen Ausspähung durch systematisches Ausprobieren geschützt.
|
||||
- Belege: [HYPOTHESE] — einziger Anhalt ist die Nicht-Auffindbarkeit (B-F031 HYP); kein PRIMÄR-Beleg für eine durchsetzende Stelle vorhanden und auch kein Beleg, dass der Schutz fachlich bewusst nicht gewollt ist.
|
||||
- Prüfidee: 20 aufeinanderfolgende Fehlanmeldungen eines Kontos → der 21. Versuch muss vorübergehend blockiert oder zusätzlich bestätigt werden.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: mittel — fachlich zu fordern, aber Zielwert (Versuchszahl, Sperrdauer) fehlt.
|
||||
- Status: HYPOTHESE (Begründung: kein Fakt über vorhandene oder gewollte Schutzmechanik; offene Frage: Existiert ein Anmeldeversuchszähler oder ist er fachlich gefordert?)
|
||||
|
||||
- **StRS-008 — Zwei-Faktor-Authentisierung ist global und je Benutzer steuerbar**
|
||||
- ID: StRS-008
|
||||
- Titel: Zwei-Faktor-Authentisierung ist global und je Benutzer steuerbar
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Administrator, Mitarbeiter
|
||||
- Vorbedingung: Zwei-Faktor-Authentisierung ist eingeführt
|
||||
- Fakt: B-F019 TwoFactorAuthBL Zt.33-179[P]: global+benutzerbezogen, Merk-Login Gültigkeitstage je App/Maschine/IP; H-F31[P]: TOTP-Wizard; E-F06[P]: 2FA-E-Mail-Code validiert; G-F07[P]: 2FA-Nutzer kein AutoReconnect
|
||||
- Aussage: Das System soll die Zwei-Faktor-Authentisierung weltweit und auf Benutzerebene steuerbar machen, das zeitlich befristete Merken eines angemeldeten Arbeitsplatzes je Anwendung/Maschine/Netzquelle erlauben und angemeldete Sitzungen von Zwei-Faktor-Benutzern nicht ohne erneute Bestätigung verlängern.
|
||||
- Ergebnis: Der zweite Faktor kann nicht durch automatische Wiederverbindung umgangen werden.
|
||||
- Belege: [PRIMÄR] TwoFactorAuthBL Zt.33-179, E-F06-Codevalidierung, G-F07 — durchsetzende Stellen.
|
||||
- Prüfidee: 2FA-Pflicht aktivieren → Anmeldung nur nach Code; „merken“ für 3 Tage setzen und Maschine/IP wechseln → erneute Bestätigung erforderlich; AutoReconnect eines 2FA-Nutzers → Verbindung ohne gültige frische Authentisierung ablehnen.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (B-F019, H-F31, E-F06, G-F07)
|
||||
- Übernahmewürdigkeit: hoch — sicherheitsrelevante Kernregel, primär belegt.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-009 — Ein Portal-Konto sieht ausschließlich die Daten seines eigenen Kunden**
|
||||
- ID: StRS-009
|
||||
- Titel: Ein Portal-Konto sieht ausschließlich die Daten seines eigenen Kunden
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Kunde (Web-Account), System
|
||||
- Vorbedingung: Ein Kunde nutzt ein Portal-/Web-Konto
|
||||
- Fakt: B-F012 Zt.202-227[P]: Mandantentrennung über WebAccount.CustomerI3D; A-F36 ReceiptCartBL Zt.346-371[P]: Web-Account an eigenen Kunden gebunden; A-F25[P]: Web-Account sieht keine Belege; B-F017[P-Widerspruch]: WebAccount-Login umgeht Rechteprüfung
|
||||
- Aussage: Das System soll jedes Portal-Konto fest an genau einen Kunden binden und ihm nur dessen eigene Daten (Warenkorb, Angebote, Tickets) zugänglich machen; interne Mitarbeiterbelege bleiben ihm versperrt.
|
||||
- Ergebnis: Kein Kunde kann fremde Kundendaten einsehen.
|
||||
- Belege: [PRIMÄR] B-F012 Zt.202-227 und ReceiptCartBL Zt.346-371 — Kundenzuordnung und Datenfilterung erzwungen; [PRIMÄR] A-F25 — Verweigerung interner Belege; [PRIMÄR] B-F017 dokumentiert widersprüchlich die Umgehung der internen Rechteprüfung beim Portal-Login (Gegenbefund).
|
||||
- Prüfidee: Web-Account K1 öffnet Beleg/Angebot des Kunden K2 direkt über die Kennung → Zugriff muss verweigert werden; Web-Account ruft interne Mitarbeiterbelegliste → keine Belege.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (B-F012, A-F36, A-F25)
|
||||
- Übernahmewürdigkeit: hoch — Grundregel der Kundentrennung; Widerspruch B-F017 als Prüfziel dokumentieren.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-010 — Mandanten sind strikt voneinander getrennt**
|
||||
- ID: StRS-010
|
||||
- Titel: Mandanten sind strikt voneinander getrennt
|
||||
- Ebene: StRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Vertraulichkeit)
|
||||
- Akteur: System, Mandantenbetreuer
|
||||
- Vorbedingung: Ein Betrieb bedient mehrere Mandanten
|
||||
- Fakt: D-F06[P]: Mandantentrennung über I3D/Filial, nur 20 Tabellen Mandantenfeld; B-F012 Zt.202-227[P]; D-F05[P]: Debitoren-/Kreditorennummer unique
|
||||
- Aussage: Das System soll alle Geschäftsvorfälle eindeutig einem Mandanten zuordnen und Datenzugriffe ausschließlich innerhalb des angemeldeten Mandanten zulassen.
|
||||
- Ergebnis: Mandanten können dieselbe Installation nutzen, ohne einander zu sehen.
|
||||
- Belege: [PRIMÄR] D-F06 — Trennung über I3D/Filiale durchgesetzt; [PRIMÄR] B-F012 Zt.202-227 — Portalzugang mandantengebunden; Beobachtung „nur 20 Tabellen mit Mandantenfeld“ ist als Vollständigkeitsrisiko festgehalten.
|
||||
- Prüfidee: Im Mandanten A ein Objekt (Artikel/Kunde) anlegen und dieselbe Kennung im Mandanten B anfragen → keine Datenlieferung; Zähler der mandantenspezifischen Tabellen mit Fremdmandanten-Kennung → keine Sichten.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — Pflichtanforderung für Mehrmandantenbetrieb.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-011 — Lizenzumfang begrenzt Funktion und Inbetriebnahme**
|
||||
- ID: StRS-011
|
||||
- Titel: Lizenzumfang begrenzt Funktion und Inbetriebnahme
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Hersteller, System, Administrator
|
||||
- Vorbedingung: Installation bzw. Funktionsaufruf in einer lizenzpflichtigen Umgebung
|
||||
- Fakt: B-F021 LicenseManager Zt.258-302[P]: Version+Anzahl; B-F022 Zt.219-236[P]: Lizenz-Gate vor Start/Migration; E-F02[P]: CentronHosted nur mit Lizenz; E-F13[P]: Lizenz vor DB-Verbindung; G-F35[P]: Massenupdates nur mit Lizenz DataUpdaterV2; G-F39[P]: ein Angebot pro PLM-Lizenz
|
||||
- Aussage: Das System soll fachliche Funktionen nur in dem durch die hinterlegte Lizenz gedeckten Umfang freigeben und Start, Migration sowie lizenzpflichtige Massenfunktionen ohne gültige Lizenz unterbinden.
|
||||
- Ergebnis: Der Hersteller kann Nutzungsumfang vertraglich absichern; der Betrieb weiß vor Inbetriebnahme, ob er darf.
|
||||
- Belege: [PRIMÄR] LicenseManager Zt.258-302, B-F022 Zt.219-236, E-F13 — wirksame Gate-Stellen vor Funktionsausführung.
|
||||
- Prüfidee: Lizenz mit Anzahl kleiner als gleichzeitige Nutzer setzen → weiterer Nutzer wird abgewiesen; Migration ohne Lizenz starten → Abbruch vor Datenzugriff; Massenupdate ohne DataUpdaterV2-Lizenz → Aktion verweigert.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (B-F021, B-F022, E-F02, E-F13, G-F35, G-F39)
|
||||
- Übernahmewürdigkeit: hoch — Geschäftsbedingung des Lizenzmodells.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-012 — Kundenpreis wird nach festgelegter Vorrangfolge ermittelt**
|
||||
- ID: StRS-012
|
||||
- Titel: Kundenpreis wird nach festgelegter Vorrangfolge ermittelt
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Vertriebsmitarbeiter, System
|
||||
- Vorbedingung: Kunde fragt einen Artikel in einem Beleg nach
|
||||
- Fakt: A-F02 GetBasePrice Zt.154-286[P]: Vertrags-Sonderpreis > Kunden-Sonderpreis > Staffelpreis > Preisliste; A-F03 GetSpecialPrice Zt.588-629[P]: nur interne Artikel, Gültigkeitsfenster, Spezifität Artikel>Warengruppen; A-F01 GetSellPriceForCustomer Zt.482-497[P]: 4 Preislistenstufen, Konzerngruppenkunde
|
||||
- Aussage: Das System soll den Kundenpreis in der Vorrangfolge Vertrags-Sonderpreis vor Kunden-Sonderpreis vor Staffelpreis vor Preisliste ermitteln, Sonderpreise nur innerhalb ihres Gültigkeitsfensters und bei mehrdeutiger Pflege nach dem spezifischeren Merkmal (Artikel vor Warengruppe) anwenden und dabei die Preislistenstufe des Kunden einschließlich Konzerngruppenzugehörigkeit berücksichtigen.
|
||||
- Ergebnis: Jeder Beleg weist den fachlich einzig richtigen Preis aus.
|
||||
- Belege: [PRIMÄR] GetBasePrice Zt.154-286 — Kaskade selbst; [PRIMÄR] GetSpecialPrice Zt.588-629, GetSellPriceForCustomer Zt.482-497 — Teilregeln direkt belegt.
|
||||
- Prüfidee: Für denselben Artikel Kunden-Sonderpreis und Vertrags-Sonderpreis mit überlappenden Fenstern pflegen → Rechnungspreis = Vertrags-Sonderpreis; Sonderpreis außerhalb des Gültigkeitsfensters → darf nicht erscheinen.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (A-F01, A-F02, A-F03)
|
||||
- Übernahmewürdigkeit: hoch — Abrechnungsrelevant, Kaskade lückenlos primär belegt.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-013 — Rabatte werden getrennt ausgewiesen und einheitlich umgerechnet**
|
||||
- ID: StRS-013
|
||||
- Titel: Rabatte werden getrennt ausgewiesen und einheitlich umgerechnet
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Vertriebsmitarbeiter, Kunde
|
||||
- Vorbedingung: Auf einen Belegpreis wird ein Rabatt angewendet
|
||||
- Fakt: A-F05 ReceiptItemBL.UpdateCustomerDiscount Zt.557-583[P]: Kundenrabatt als eigene Rabattposition, Rundung 2 AwayFromZero, Text-Template; A-F02[P]: Kontraktwerte invertiert (10=+10 %), fester Rabatt→% via /basePrice*100
|
||||
- Aussage: Das System soll gewährte Rabatte als eigenständige, für den Kunden nachvollziehbare Position im Beleg ausweisen und feste Beträge sowie invertierte Vertragswerte in einheitlich prozentuale Rabatte umrechnen.
|
||||
- Ergebnis: Der Kunde sieht, welcher Rabatt auf welche Basis gewährt wurde; Preise sind vergleichbar.
|
||||
- Belege: [PRIMÄR] ReceiptItemBL Zt.557-583 — Anlage und Rundung der Rabattposition; [PRIMÄR] GetBasePrice Zt.154-286 — Umrechnungsregeln.
|
||||
- Prüfidee: Festen Rabatt 5 EUR auf Basispreis 100 EUR buchen → Position mit 5 % ausgewiesen, Rundung auf 2 Nachkommastellen kaufmännisch von Null weg; Kontrollrechnung Summe rabattierter Position = ausgewiesener Rabattpreis.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (A-F05, Teilaspekt A-F02)
|
||||
- Übernahmewürdigkeit: hoch — Rechnungslegung und Kundenkommunikation.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-014 — Nettobeträge werden währungs- und länderspezifisch korrekt berechnet**
|
||||
- ID: StRS-014
|
||||
- Titel: Nettobeträge werden währungs- und länderspezifisch korrekt berechnet
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: System, Kunde
|
||||
- Vorbedingung: Ein Beleg wird berechnet
|
||||
- Fakt: A-F06 ReceiptPriceHelper.CalculateNetPrice Zt.202-213[P]: Währung vor Rabatt, Precision je Artikel; A-F07 Zt.215-230[P]: precision=-1 keine Zwischenrundung; A-F09 Zt.37-41[P]: CH-5-Rappen-Rundung Setting CommercialRoundCH; A-F08 CalculateTaxPrice Zt.232-242[P]: Barverkauf Preis ist Brutto, Steuer herausgerechnet
|
||||
- Aussage: Das System soll Belegpreise in der Reihenfolge Währungsumrechnung vor Rabatt mit der je Artikel vereinbarten Genauigkeit berechnen, auf Wunsch Zwischenrundungen vermeiden, die länderspezifische Rundung (Schweiz: 5-Rappen) beachten und bei Barverkäufen den ausgewiesenen Preis als Bruttobetrag mit herausgerechneter Steuer behandeln.
|
||||
- Ergebnis: Belegsummen sind in jeder Währung und jedem Abrechnungsland prüfbar richtig.
|
||||
- Belege: [PRIMÄR] ReceiptPriceHelper Zt.202-213/215-230/37-41 und CalculateTaxPrice Zt.232-242 — alle vier Berechnungsregeln direkt belegt; [SEKUNDÄR] BL-Delegation ReceiptPriceHelperBL:117-120.
|
||||
- Prüfidee: Artikel mit CH-Land und CommercialRoundCH → gerundete Beträge sind Vielfache von 0,05; Barverkaufspreis 119 EUR bei 19 % → Steuer 19 EUR, Netto 100 EUR; identische Positionsmenge mit/ohne precision=-1 → unterschiedliche, dokumentierte Zwischensummen.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (A-F06, A-F07, A-F08, A-F09)
|
||||
- Übernahmewürdigkeit: hoch — Abrechnungsgrundlage, vier PRIMÄR-Belege.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-015 — Einkaufspreise folgen einer definierten Kaskade**
|
||||
- ID: StRS-015
|
||||
- Titel: Einkaufspreise folgen einer definierten Kaskade
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Einkaufssachbearbeiter, System
|
||||
- Vorbedingung: Ein Artikel wird im Einkauf bewertet
|
||||
- Fakt: A-F04 GetPurchaseBasePrice Zt.313-387[P]: EK-Kaskade Sondervereinbarung/Lager-EK (nur mit AppSetting SelfSecondstockPurchasePrice)/Staffelpreis × (1−EKRed %) × Währungsfaktor
|
||||
- Aussage: Das System soll den Bezugspreis in der Vorrangfolge Sondervereinbarung, Lager-EK (nur wenn diese Bewertung freigegeben ist) und Staffelpreis ermitteln sowie EK-Reduktionsprozente und den Währungsfaktor anwenden.
|
||||
- Ergebnis: Einkaufskalkulationen und Warenbewertungen verwenden einen nachvollziehbaren Bezugspreis.
|
||||
- Belege: [PRIMÄR] GetPurchaseBasePrice Zt.313-387 — Kaskade vollständig durchsetzend belegt.
|
||||
- Prüfidee: Artikel mit Sondervereinbarung und Staffelpreis → Sondervereinbarung gewinnt; Freigabe SelfSecondstockPurchasePrice aus → Lager-EK darf nicht ziehen; EKRed 10 % und Währungsfaktor 1,10 → Probeberechnung stimmt auf zwei Nachkommastellen.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — kalkulationsrelevant, primär belegt.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-016 — Skonto wird aus den Zahlungsbedingungen abgeleitet**
|
||||
- ID: StRS-016
|
||||
- Titel: Skonto wird aus den Zahlungsbedingungen abgeleitet
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Buchhaltung, Kunde
|
||||
- Vorbedingung: Ein Kunde zahlt innerhalb einer Skontofrist
|
||||
- Fakt: A-F10 Skonto 3-stufig Zahkond Schema Zt.6846-6902[P-Format]; HYP: kein durchgesetzter Skonto-Abzug im System auffindbar; A-F11 NoEarlyPaymentDiscountAllowed Zt.87-88[P]: nicht-skontofähige Beträge separat
|
||||
- Aussage: Das System soll aus der Zahlungsbedingung gestaffelte Skontosätze mit Fristen ableiten, nicht skontofähige Beträge ausnehmen und den Zahlbetrag entsprechend vermindern.
|
||||
- Ergebnis: Zahlungen werden ohne manuelle Nacharbeit korrekt bewertet.
|
||||
- Belege: [PRIMÄR] Schema Zt.6846-6902 — Formatvorgabe 3-stufig; [PRIMÄR] A-F11 Zt.87-88 — Ausweis nicht skontofähiger Beträge; jedoch kein PRIMÄR-Beleg für die durchgesetzte Betragsminderung [HYPOTHESE] (HYP in A-F10).
|
||||
- Prüfidee: Rechnung 1.000 EUR, Zahkond 2 %/10 Tage, Kunde zahlt am 9. Tag 980 EUR → Zahlung muss ohne Restoffenbetrag abschließbar sein; Posten mit NoEarlyPaymentDiscountAllowed → darf nicht in Skontoberechnung einfließen.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (A-F10, A-F11)
|
||||
- Übernahmewürdigkeit: mittel — Ziel fachlich klar, Ist-Durchsetzung des Abzugs offen.
|
||||
- Status: HYPOTHESE (Begründung: Skontobetragsminderung nirgends als durchsetzend gefunden, nur Format; offene Frage: Wird Skonto nur informativ auf der Rechnung ausgewiesen oder im Zahlungsausgleich berechnet?)
|
||||
|
||||
- **StRS-017 — Zahlungsziel und Fälligkeit werden einheitlich bestimmt**
|
||||
- ID: StRS-017
|
||||
- Titel: Zahlungsziel und Fälligkeit werden einheitlich bestimmt
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Buchhaltung, Kunde
|
||||
- Vorbedingung: Eine Rechnung mit Zahlungsbedingung entsteht
|
||||
- Fakt: A-F12 Zt.8189-8256 (Anker Belegdatum) vs. AssetConditionBL Zt.350-387 (Anker heute)[P, WIDERSPRUCH] — zwei Fälligkeitsformeln
|
||||
- Aussage: Das System soll die Fälligkeit eines Betrags in allen Entstehungspfaden nach derselben, definierten Regel aus der Zahlungsbedingung ableiten.
|
||||
- Ergebnis: Fällige Posten sind für Kunde und Mahnwesen eindeutig und widerspruchsfrei.
|
||||
- Belege: [PRIMÄR] ReceiptBL Zt.8189-8256 und AssetConditionBL Zt.350-387 — beide Formeln durchsetzend implementiert, Widerspruch selbst ist primär belegt.
|
||||
- Prüfidee: Dieselbe Zahlungsbedingung (z. B. „30 Tage netto“) einmal über Rechnung und einmal über Vertragsabrechnung mit unterschiedlichem Anlagezeitpunkt laufen lassen → Fälligkeitsdatum muss in beiden Pfaden identischen Regeln folgen; die dokumentierte Ankerregel ist die einzige.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — Fälligkeit steuert Mahnwesen und Skonto; Widerspruchsbehebung ist Klärungsbedarf.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-018 — Der Bezahlt-Status einer Rechnung folgt dem Zahlungseingang**
|
||||
- ID: StRS-018
|
||||
- Titel: Der Bezahlt-Status einer Rechnung folgt dem Zahlungseingang
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Buchhaltung, System
|
||||
- Vorbedingung: Ein Zahlungseingang wird erfasst
|
||||
- Fakt: A-F15 UpdateReceiptIsPaid Zt.4902-4971[P]: bezahlt-Status ohne Betragsprüfung; PaymentsBL:33-36[P]: SaveIncomingPayment ohne Rechteprüfung
|
||||
- Aussage: Das System soll eine Rechnung nur dann als bezahlt führen, wenn ein tatsächlicher, die Forderung deckender Zahlungseingang zugeordnet ist, und die Erfassung von Zahlungseingängen nur berechtigten Mitarbeitenden erlauben.
|
||||
- Ergebnis: Forderungsbestand und Zahlungseingänge stimmen überein; unbebuchte „bezahlte“ Rechnungen scheiden aus.
|
||||
- Belege: [PRIMÄR] UpdateReceiptIsPaid Zt.4902-4971 und PaymentsBL:33-36 — beide Stellen zeigen die Soll-Wirkung (Statussetzung/Erfassung) und die dort fehlende Bedingung primär auf.
|
||||
- Prüfidee: Rechnung über 500 EUR, Zahlungseingang 100 EUR erfassen → Status „bezahlt“ darf nicht gesetzt werden; Benutzer ohne Zahlungsrecht ruft Zahlungserfassung auf → Vorgang muss abgewiesen werden.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — mittelbare Außenwirkung (Mahnwesen entfällt zu Unrecht).
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-019 — Das Mahnwesen folgt Stufen mit Protokoll, Sperre und Rechteschutz**
|
||||
- ID: StRS-019
|
||||
- Titel: Das Mahnwesen folgt Stufen mit Protokoll, Sperre und Rechteschutz
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Buchhaltung/Mahnwesen, Kunde
|
||||
- Vorbedingung: Ein Kunde hat fällige, unbezahlte Posten
|
||||
- Fakt: A-F24 DunningRunBL Zt.248-315, DunningBL Zt.267-317[P]: Stufen None→1→2→3 Ende, Protokoll je Lauf, Fälligkeitstür, Mahnstopp, Rechte; Saldoformel uneinheitlich Zt.215-235[P-Widerspruch]; HYP Mahngebühren nirgends berechnet
|
||||
- Aussage: Das System soll überfällige Forderungen in festen Mahnstufen bis zum Abschluss bearbeiten, jeden Lauf protokollieren, nur fällige Posten einbeziehen, einzelne Kunden auf Mahnstopp setzen dürfen und die Mahnbearbeitung Rechten unterstellen.
|
||||
- Ergebnis: Kunden werden fristgerecht und nachweisbar gemahnt, ruhende Vereinbarungen nicht gestört.
|
||||
- Belege: [PRIMÄR] DunningRunBL Zt.248-315 und DunningBL Zt.267-317 — Stufen, Pforte und Rechte dort durchgesetzt; Saldo-Widerspruch Zt.215-235 ebenfalls [PRIMÄR] belegt; Mahngebühren ohne Beleg (HYP).
|
||||
- Prüfidee: Fälligen Posten anlegen, Mahnstopp setzen, Lauf starten → Kunde nicht gemahnt; Stopp aufheben → Mahnstufe 1, Protokollzeile je Lauf vorhanden; Stufe 3 erreicht → keine weitere Stufe.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — Kernprozess Forderungsmanagement; Saldo-Widerspruch als Klärungspunkt.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-020 — Das Kreditlimit warnt, bevor Aufträge ausgeführt werden**
|
||||
- ID: StRS-020
|
||||
- Titel: Das Kreditlimit warnt, bevor Aufträge ausgeführt werden
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Vertriebsmitarbeiter, Buchhaltung
|
||||
- Vorbedingung: Ein Beleg überschreitet das vereinbarte Kreditlimit des Kunden
|
||||
- Fakt: A-F18 CheckIfCustomerLimitIsReached Zt.8636-8690[P]: Warnung nicht Sperre, Fortsetzen-Dialog
|
||||
- Aussage: Das System soll bei Erreichen des Kreditlimits den Bearbeiter vor der Belegfortführung warnen und die bewusste, protokollierbare Entscheidung zum Fortsetzen verlangen, den Beleg aber nicht zwangsweise sperren.
|
||||
- Ergebnis: Kreditrisiko bleibt sichtbar und verantwortet; berechtigte Ausnahmen bleiben möglich.
|
||||
- Belege: [PRIMÄR] CheckIfCustomerLimitIsReached Zt.8636-8690 — Prüfung und Dialogstelle direkt belegt.
|
||||
- Prüfidee: Offenen Saldo des Kunden nahe dem Limit, neuen Auftrag über Limit anlegen → Warnung mit Fortsetzwahl erscheint ohne Fortsetzung kein gespeicherter Auftrag; nach Bestätigung ist Fortsetzung nachvollziehbar.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — klar dokumentiertes Geschäftsregelverhalten.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-021 — Belege folgen einem definierten Fluss mit Vor- und Folbelegen**
|
||||
- ID: StRS-021
|
||||
- Titel: Belege folgen einem definierten Fluss mit Vor- und Folbelegen
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Vertriebsmitarbeiter, System
|
||||
- Vorbedingung: Ein Kunde durchläuft Angebot bis Rechnung
|
||||
- Fakt: A-F17 Zt.221-296/551/673-675[P]: Vorbelege Lieferschein/Auftrag/Angebot/Vertrag, Folge Gutschrift, Bestand senkend; A-F21 ReceiptState.cs + AutomaticallyCloseReceiptHelperBL Zt.36-83[P]: Status Active/Completed/Canceled automatisch aus Mengen; A-F22 OfferSpecificLogic Zt.245-281[P]: Angebots-Abschluss 3-stufig; A-F23[P]: Belegfluss-Graph
|
||||
- Aussage: Das System soll Belege nur entlang der definierten Flussfolge (Angebot/Auftrag/Vertrag → Lieferschein → Rechnung → Gutschrift) führen, den Belegstatus automatisch aus den erfassten Mengen steuern und den Angebotsabschluss nach der dreistufigen Vereinbarung behandeln.
|
||||
- Ergebnis: Der Bearbeiter sieht jederzeit den echten Sachstand eines Vorgangs.
|
||||
- Belege: [PRIMÄR] ReceiptState/AutomaticallyCloseReceiptHelperBL Zt.36-83, Receipt-Regeln Zt.221-296, OfferSpecificLogic Zt.245-281 — Steuerungslogik durchsetzend belegt.
|
||||
- Prüfidee: Lieferschein über Bestellmenge hinaus buchen → Statuswechsel muss unterbleiben bzw. Regel greifen; vollständig gelieferter Auftrag → automatischer Abschluss; Gutschrift ohne Rechnung als Vorbeleg → nicht zulässig.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (A-F17, A-F21, A-F22, A-F23)
|
||||
- Übernahmewürdigkeit: hoch — Prozessgerüst der Auftragsabwicklung.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-022 — Rechnungsangaben sind vollständig zu erfassen**
|
||||
- ID: StRS-022
|
||||
- Titel: Rechnungsangaben sind vollständig zu erfassen
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Rechnungssteller (Sachbearbeiter), System
|
||||
- Vorbedingung: Eine Rechnung wird angelegt
|
||||
- Fakt: A-F17[P]: Kostenstelle+Kostenträger Pflicht, Zahl-/Lieferbedingung Pflicht, Bestellnummer Pflicht ohne Duplikatprüfung; A-F31 Schema Zt.3231ff/67259ff/6411[P]: Beträge Pflicht, Status/Fälligkeit nullbar, dritte Berechnungsinstanz in SQL-Funktionen
|
||||
- Aussage: Das System soll das Anlegen einer Rechnung nur zulassen, wenn alle rechnungslegungs- und kostenrechnungsrelevanten Angaben (Beträge, Kostenstelle, Kostenträger, Zahlungs- und Lieferbedingung, Bestellnummer) erfasst sind.
|
||||
- Ergebnis: Rechnungsdaten sind abgangsfähig vollständig; Rückfragen und Nacharbeit entfallen.
|
||||
- Belege: [PRIMÄR] Belegregeln Zt.221-296/551/673-675 und Schema Zt.3231ff/67259ff — Pflichtfeld- und Feldgrenzregelungen dort durchgesetzt.
|
||||
- Prüfidee: Rechnung ohne Kostenstelle bzw. ohne Zahlungsbedingung speichern → Speichern verweigert; Rechnung mit Bestellnummer identisch zu vorhandener Rechnung → Duplikatwarnung ist fachlich zu fordern (ist derzeit nicht vorhanden → Prüfpunkt).
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (A-F17, A-F31)
|
||||
- Übernahmewürdigkeit: hoch; Lücke „Duplikatprüfung“ als Prüfpunkt gekennzeichnet.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-023 — Eine Rechnungsstorno ist nur unter Schutzbedingungen möglich**
|
||||
- ID: StRS-023
|
||||
- Titel: Eine Rechnungsstorno ist nur unter Schutzbedingungen möglich
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Buchhaltung, System
|
||||
- Vorbedingung: Eine erteilte Rechnung soll storniert werden
|
||||
- Fakt: A-F14 ReceiptInvoiceBL.CancelInvoice Zt.143-206[P]: 6 Bedingungen (Recht, nicht storniert, nicht Bar, nicht weiterverarbeitet, nicht FiBu-exportiert, letzte Vertragsrechnung); Storno = neue Version Menge 0
|
||||
- Aussage: Das System soll das Stornieren einer Rechnung nur zulassen, wenn der Handelnde berechtigt ist, die Rechnung weder bereits storniert, im Barverkauf entstanden, weiterverarbeitet noch buchhalterisch übergeben wurde und keine nachfolgende Vertragsabrechnung entgegensteht; die Stornierung hat den Ursprungsbeleg zu erhalten.
|
||||
- Ergebnis: Korrekturen bleiben prüfbar; abgeschlossene Buchungskreise werden nicht entwertet.
|
||||
- Belege: [PRIMÄR] CancelInvoice Zt.143-206 — alle Bedingungen an einer durchsetzenden Stelle.
|
||||
- Prüfidee: FiBu-exportierte Rechnung stornieren → Abweisung; berechtigte Stornierung ansonsten → neuer Stornobeleg mit Menge 0, Original unverändert; Benutzer ohne Stornorecht → Abweisung.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — abrechnungs- und revisionskritisch.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-024 — Rechnungsnummern sind je Mandant und Filiale eindeutig und lückenlos**
|
||||
- ID: StRS-024
|
||||
- Titel: Rechnungsnummern sind je Mandant und Filiale eindeutig und lückenlos
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Buchhaltung, Prüfer
|
||||
- Vorbedingung: Rechnungen verschiedener Arten und Filialen werden erstellt
|
||||
- Fakt: A-F13 InvoiceSpecificLogic Zt.104-141[P]: eigene Nummerngruppen Bar/Normal/Intern; D-F02[P,HYP]: Nummernkreise je Mandant/Filiale ohne DB-Eindeutigkeit, Fortschreibung offen; D-F07[P]: Rechnungsnummer nicht eindeutig gesichert; C-F01[P]: Kontonummer unique nur DB
|
||||
- Aussage: Das System soll jede Rechnung eindeutig und unveränderlich nummerieren, je Mandant und Filiale getrennte, fortlaufende Nummernkreise nach Belegart führen und Doppelvergaben ausschließen.
|
||||
- Ergebnis: Die Rechnungsnummer ist als Ordnungs- und Nachweismerkmal verlässlich.
|
||||
- Belege: [PRIMÄR] A-F13 Zt.104-141 — Nummerngruppenbildung durchsetzend; [PRIMÄR] D-F07 — dokumentiert das Fehlen der Eindeutigkeitssicherung; Fortschreibung des Kreises laut D-F02 nur [HYPOTHESE].
|
||||
- Prüfidee: Zwei gleichzeitige Rechnungserfassungen in derselben Filiale → keine Duplikatnummer; Nummernkreis Bar getrennt von Normal beobachten; nach Löschung eines Belegwurfs: Nummer bleibt verbraucht.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (A-F13, D-F02, D-F07, C-F01 analog)
|
||||
- Übernahmewürdigkeit: hoch — GoBD-nahe Anforderung.
|
||||
- Status: HYPOTHESE (Begründung: Fortschreibung und Vergabe des Nummernkreises nicht durchgehend belegt, D-F02 trägt HYP; offene Frage: Wird der Kreis manipulationssicher und lückenlos fortgeschrieben?)
|
||||
|
||||
- **StRS-025 — Der Belegabschluss ist eine berechtigte Handlung**
|
||||
- ID: StRS-025
|
||||
- Titel: Der Belegabschluss ist eine berechtigte Handlung
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Sachbearbeiter, System
|
||||
- Vorbedingung: Ein Beleg soll in den Endzustand überführt werden
|
||||
- Fakt: G-F15/16[P]: Abschluss manuell, Whitelist, Recht nur Auftrag/Lieferschein (Angebote/Gutscheine/Lieferanten ohne Rechtsprüfung); A-F22 OfferSpecificLogic Zt.245-281[P]
|
||||
- Aussage: Das System soll den Abschluss jedes Belegtyps nur einem fachlich berechtigten Bearbeiter erlauben und dabei alle Belegarten gleichmäßig absichern.
|
||||
- Ergebnis: Abgeschlossene Vorgänge gehen auf eine klar verantwortete Entscheidung zurück.
|
||||
- Belege: [PRIMÄR] G-F15/16 — Rechtprüfung für Auftrag/Lieferschein durchsetzend nachgewiesen; die fehlende Prüfung bei Angebot/Gutschein/Lieferant ist derselbe Befund und begründet die Anforderung.
|
||||
- Prüfidee: Benutzer ohne Abschlussrecht versucht, ein Angebot bzw. eine Lieferantenrechnung abzuschließen → Abschluss muss verweigert werden, analog Lieferschein (dort bereits korrekt).
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — Rechtegleichbehandlung über alle Belegarten.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-026 — Abgeschlossene oder übergebene Belege sind vor Änderung geschützt**
|
||||
- ID: StRS-026
|
||||
- Titel: Abgeschlossene oder übergebene Belege sind vor Änderung geschützt
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Sachbearbeiter, Prüfer, System
|
||||
- Vorbedingung: Ein Beleg ist abgeschlossen, exportiert oder zwei Nutzern gleichzeitig geöffnet
|
||||
- Fakt: G-F17[P]: Lieferantenrechnung nach Abschluss/Export nur lesen ohne Sonderrecht; A-F14[P]: Storno nur wenn nicht weiterverarbeitet/exportiert; C-F08 SaveReceiptRepository Zt.200-215[P]: gleichzeitige Änderung wird abgewiesen
|
||||
- Aussage: Das System soll abgeschlossene und buchhalterisch übergebene Belege im Regelfall nur noch lesbar halten, Änderungen nur über dokumentierte Korrekturbelege oder eine ausdrückliche Sonderberechtigung zulassen und gleichzeitige Bearbeitung desselben Belegs durch zwei Nutzer ausschließen.
|
||||
- Ergebnis: Nachweiswerte Belege können nicht unbemerkt verändert werden.
|
||||
- Belege: [PRIMÄR] G-F17-Leseumschaltung, CancelInvoice-Bedingungen A-F14, SaveReceiptRepository Zt.200-215 — drei durchsetzende Stellen.
|
||||
- Prüfidee: Abgeschlossene Lieferantenrechnung zu ändern versuchen → Lesezugriff ohne Sonderrecht; zweiter Bearbeiter öffnet Beleg, während erster speichert, und speichert erneut → Konfliktmeldung, keine Überschreibung.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (G-F17, A-F14, C-F08)
|
||||
- Übernahmewürdigkeit: hoch — Unverletzlichkeit abgeschlossener Vorgänge.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-027 — Seriennummern sind über den ganzen Warenweg vollständig und berechtigt änderbar**
|
||||
- ID: StRS-027
|
||||
- Titel: Seriennummern sind über den ganzen Warenweg vollständig und berechtigt änderbar
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Sachbearbeiter, Service-Mitarbeiter
|
||||
- Vorbedingung: Ein seriennummerngeführter Artikel wird geliefert, berechnet oder zurückgenommen
|
||||
- Fakt: A-F16 InvoiceSpecificLogic.CanCreateReport Zt.652-664[P]: Rechnung nur mit vollständigen Seriennummern druckbar; G-F10/11[P]: Reportdruck-Regeln/Seriennummernpflicht; G-F18[P]: Seriennummern-Rücknahme aus Lieferschein/Rechnung nur mit Recht; G-F27[P]: SN-Reset mit Grund
|
||||
- Aussage: Das System soll die Ausgabe von Rechnungen seriennummerngeführter Artikel von vollständigen Seriennummern abhängig machen und Rücknahme oder Zurücksetzen von Seriennummern nur mit Recht und Angabe eines Grundes erlauben.
|
||||
- Ergebnis: Gerätezuordnung pro Kunde ist lückenlos nachweisbar.
|
||||
- Belege: [PRIMÄR] CanCreateReport Zt.652-664 und G-F18 — Druckpforte und Rücknahme jeweils durchsetzend.
|
||||
- Prüfidee: Rechnung mit fehlender Seriennummer drucken → verweigert; Seriennummernrücknahme ohne Recht → verweigert; Reset ohne Grundangabe → verweigert.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (A-F16, G-F10/11, G-F18, G-F27)
|
||||
- Übernahmewürdigkeit: hoch — Garantie- und Gewährleistungsnachweis.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-028 — Lagerbestände werden nur entsprechend der tatsächlichen Bewegung geändert**
|
||||
- ID: StRS-028
|
||||
- Titel: Lagerbestände werden nur entsprechend der tatsächlichen Bewegung geändert
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Lagerist, System
|
||||
- Vorbedingung: Ein Beleg mit Artikelpositionen wird gebucht
|
||||
- Fakt: A-F26 ReceiptArticleBookingBL Zt.328-429[P]: differenzbasierte Buchung, Herkunft gespiegelt, fehlende Lager-Artikel-Kombi ohne Buchung; A-F17[P]: bestandsSenkende Belegregeln
|
||||
- Aussage: Das System soll Lagerbewegungen nur in Höhe der tatsächlichen Positionsänderung erfassen, die Bestandsquelle beibehalten und eine Bewegung nur ausführen, wenn die Lager-Artikel-Kombi geführt wird.
|
||||
- Ergebnis: Systembestand und physischer Bestand bleiben deckungsgleich.
|
||||
- Belege: [PRIMÄR] ReceiptArticleBookingBL Zt.328-429 — Buchungsmechanik an einer Stelle durchsetzend belegt.
|
||||
- Prüfidee: Positionsanzahl von 5 auf 3 ändern → Buchung nur −2, keine −5/+5; Artikel ohne Lagerführungseintrag → Buchung unterbleibt und ist meldbar.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — Bestandszuverlässigkeit.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-029 — Bestandsmindernde Korrekturbuchungen sind abgesichert**
|
||||
- ID: StRS-029
|
||||
- Titel: Bestandsmindernde Korrekturbuchungen sind abgesichert
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Lagerverantwortlicher, Kontrollberechtigter
|
||||
- Vorbedingung: Ein Bestand soll unter den bislang geführten Wert korrigiert werden
|
||||
- Fakt: A-F25 ReceiptArticleBookingBL Zt.346-427[P]: Negativbuchung nur mit Recht oder Vier-Augen-Fremdlogin
|
||||
- Aussage: Das System soll Negativbuchungen nur mit ausdrücklichem Recht oder nach Vier-Augen-Bestätigung durch einen anderen Benutzer zulassen.
|
||||
- Ergebnis: Bestandsverringerungen können nicht im Alleingang verschleiert werden.
|
||||
- Belege: [PRIMÄR] ReceiptArticleBookingBL Zt.346-427 — beide Schutzwege dort durchgesetzt.
|
||||
- Prüfidee: Benutzer ohne Negativbuchungsrecht bucht negativ und loggt nicht fremd → Abweisung; mit Fremdlogin-Bestätigung eines Berechtigten → Buchung möglich und beiden nachvollziehbar.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — Missbrauchsschutz im Lager.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-030 — Vertragsabrechnungen erfüllen die Vertragspflichtangaben**
|
||||
- ID: StRS-030
|
||||
- Titel: Vertragsabrechnungen erfüllen die Vertragspflichtangaben
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Servicetechniker, Abrechnungsmitarbeiter
|
||||
- Vorbedingung: Ein Wartungsvertrag wird abgerechnet
|
||||
- Fakt: G-F20[P]: Vertragspflichtfelder, Zählerpreis, Datum ≥ letzte Buchung; A-F28 ReceiptContractHelperBL Zt.179-196[P]: Vertragskontingent 9-stellig; A-F14[P]: Storno nur als letzte Vertragsrechnung
|
||||
- Aussage: Das System soll Vertragsabrechnungen nur mit vollständigen Pflichtangaben, korrektem Zählerstand/Faktor und einem Abrechnungsdatum nach der letzten Buchung zulassen und nachträgliche Korrekturen nur an der letzten Abrechnung erlauben.
|
||||
- Ergebnis: Dauerschuldabrechnungen sind konsistent, zählerbasiert und revisionssicher.
|
||||
- Belege: [PRIMÄR] G-F20, ReceiptContractHelperBL Zt.179-196, CancelInvoice-Bedingung A-F14 — jeweils durchsetzende Prüfung.
|
||||
- Prüfidee: Abrechnungsdatum vor letzter Zählerbuchung → verweigert; Kontingentwert > 9 Stellen → abgewiesen; mittlere von drei Vertragsrechnungen stornieren → verweigert, die letzte → erlaubt.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (G-F20, A-F28, A-F14)
|
||||
- Übernahmewürdigkeit: hoch — Kern der wiederkehrenden Erlöserfassung.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-031 — Pauschal- und Zeitabrechnungen sind vollständig und gesperrt verwaltbar**
|
||||
- ID: StRS-031
|
||||
- Titel: Pauschal- und Zeitabrechnungen sind vollständig und gesperrt verwaltbar
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Servicemitarbeiter, Abrechnungsmitarbeiter
|
||||
- Vorbedingung: Dienstleistungen werden über Pauschalen oder erfasste Zeiten abgerechnet
|
||||
- Fakt: G-F22/23[P]: TimerBilling/Flatrate/Pauschal-Regeln, Mahnstopp-Recht; G-F28[P]: Ticketabschluss — nicht abgerechnete/laufende Zeiten blockieren, Zeiten nur eigene mit Recht
|
||||
- Aussage: Das System soll Pauschal- und Zeitabrechnungen nur abschließen, wenn alle Zeiten erfasst und abgerechnet sind, Zeiteinsicht auf die eigenen Zeiten (erweiterbar per Recht) beschränken und die Vergabe eines Mahnstopps an ein Recht binden.
|
||||
- Ergebnis: Keine abrechenbare Leistung geht verloren; Leistungserfassung bleibt personenbezogen geschützt.
|
||||
- Belege: [PRIMÄR] G-F28 Serverfreigabe und Sperrlogik, G-F22/23 Rechtsprüfung Mahnstopp — durchsetzende Stellen.
|
||||
- Prüfidee: Laufende Zeit im Ticket → Abschluss verweigert; Benutzer ohne Recht sieht fremde Zeiten nicht; Mahnstopp ohne Recht setzen → verweigert.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — Erlösselbstkontrolle.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-032 — EDI-Bestellungen sind gegen fehlerhafte Kundendaten abgesichert**
|
||||
- ID: StRS-032
|
||||
- Titel: EDI-Bestellungen sind gegen fehlerhafte Kundendaten abgesichert
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Geschäftspartner (EDI), Auftragssachbearbeiter
|
||||
- Vorbedingung: Eine Bestellung trifft auf elektronischem Weg ein
|
||||
- Fakt: A-F27 Opentrans21OrderBL Zt.224-236[P]: Summen nur aus Positionen ohne Gegenprüfung, Kreditorcode/Verfügbarkeit hart geprüft
|
||||
- Aussage: Das System soll eingegangene elektronische Bestellungen nur für bekannte, lieferfähige Geschäftspartner annehmen und die erklärte Auftragssumme gegen die Summe der Positionen prüfen, bevor ein Auftrag entsteht.
|
||||
- Ergebnis: Falsche oder schädliche Fremddaten erzeugen keine stillen Fehlaufträge.
|
||||
- Belege: [PRIMÄR] Opentrans21OrderBL Zt.224-236 — Annahmepforte; dort ist die Partnerprüfung durchgesetzt, die Summengegenprüfung fehlt (Befund).
|
||||
- Prüfidee: EDI-Nachricht mit Positionssumme 900 EUR und deklariertem Total 1.000 EUR → Annahme muss scheitern oder beanstandet werden; unbekannter Kreditorcode → harte Ablehnung (bereits belegt).
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — Abrechnungsrisiko aus Fremddaten.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-033 — Elektronische Rechnungen sind formal prüfbar auszuliefern**
|
||||
- ID: StRS-033
|
||||
- Titel: Elektronische Rechnungen sind formal prüfbar auszuliefern
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Buchhaltung, Empfänger (öffentliche Auftraggeber)
|
||||
- Vorbedingung: Eine Rechnung wird als ZUGFeRD/XRechnung ausgegeben
|
||||
- Fakt: A-F19 InvoiceZugferdBL Zt.64/1023-1059[P]: Summenkontrolle Toleranz 3,00 EUR, unter Toleranz stille Korrektur, sonst Exportstopp; A-F20[P]: Umsatzsteuerbefreit-Umschaltung; H-F44[K]: ZUGFeRD 2.1/XRechnung 3.0.1, Typcode 380/381
|
||||
- Aussage: Das System soll elektronische Rechnungen im vereinbarten Format erzeugen, ihre Summen intern prüfen, Abweichungen innerhalb der vereinbarten Toleranz automatisch ausgleichen, darüber den Export sperren und Steuerbefreiungen korrekt ausweisen.
|
||||
- Ergebnis: Elektronische Rechnungen werden vom Empfänger nicht formell zurückgewiesen.
|
||||
- Belege: [PRIMÄR] InvoiceZugferdBL Zt.64/1023-1059 — Kontroll- und Sperrstelle; [PRIMÄR] A-F20 — Umsatzsteuer-Umschaltung; [KONTEXT] H-F44 — Formatstand nur dokumentiert.
|
||||
- Prüfidee: Rechnung mit 2,50 EUR Rundungsdifferenz → Export mit Korrektur; 3,50 EUR Differenz → Export verweigert mit Meldung; steuerbefreite Rechnung → Typausweis und USt-Feld stimmen.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (A-F19, A-F20, H-F44)
|
||||
- Übernahmewürdigkeit: hoch — gesetzliche Pflichtformate.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-034 — Die Buchhaltungsergabe folgt den vereinbarten Exportregeln**
|
||||
- ID: StRS-034
|
||||
- Titel: Die Buchhaltungsergabe folgt den vereinbarten Exportregeln
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Buchhaltung, Steuerberater
|
||||
- Vorbedingung: Belege eines Zeitraums werden an die Finanzbuchhaltung übergeben
|
||||
- Fakt: D-F08[P]: FiBu-Export-Defaults (SEPA an, 0-Rechnungen aus, 0952); D-F10..D-F25[P]: 4 Belegarten, Nummer 36 Zeichen, Kostenstelle→eigene Sätze, Buchungstext 60 mit Nummernschutz, Rundungsdifferenzausgleich max ±2,00, 0-Rechnungen abgelehnt, Erlöskonto-Pflicht, EXTF 700; G-F30[P]: Eingabepflichten, Zeitraumprüfung
|
||||
- Aussage: Das System soll die Buchhaltungsergabe nur nach den vereinbarten Regeln des Zielsystems leisten: vollständige Pflichtangaben (u. a. Erlöskonto), Längen- und Feldgrenzen, eigene Sätze je Kostenstelle, Ausgleich von Rundungsdifferenzen nur innerhalb der vereinbarten Grenze und Ablehnung von Rechnungen ohne Betrag.
|
||||
- Ergebnis: Übergaben sind beim Steuerberater verarbeitbar, ohne manuelle Nacharbeit.
|
||||
- Belege: [PRIMÄR] Exportregeln D-F10..D-F25 und G-F30 — Export- und Prüfstellen durchsetzend; [PRIMÄR] D-F08 Defaults.
|
||||
- Prüfidee: Rechnung ohne Erlöskonto → Export verweigert; 0-Betrag-Rechnung bei aktiver Sperre → abgelehnt; Kostenstelle mit zwei Werten → zwei Sätze im Export; Buchungstext > 60 → Verkürzung ohne Nummerverlust.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (bündelt D-F08, D-F10..D-F25, G-F30)
|
||||
- Übernahmewürdigkeit: hoch — Abrechnungs-/Steuerprozesse direkt betroffen.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-035 — Bankdaten werden beauftragt erhoben und Zahlungen fest zugeordnet**
|
||||
- ID: StRS-035
|
||||
- Titel: Bankdaten werden beauftragt erhoben und Zahlungen fest zugeordnet
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Buchhaltung, Bank (extern), Kunde
|
||||
- Vorbedingung: Zahlungseingänge werden aus dem Bankkonto übernommen
|
||||
- Fakt: F-F14..17 FinAPI PSD2[P/Schema S]: OAuth2, Credentials lizenzgeprüft, Consent nicht ausgewertet, zwei Datumslogiken; G-F32[P]: Zuordnung Zahlungseingang ≤ und Rechnungsbetrag ≤ (clientseitig)
|
||||
- Aussage: Das System soll Kontenumsätze nur nach ausdrücklicher, widerrufbarer Kundenzustimmung (Zahlungsdienstegrundlage) abrufen und Zahlungseingänge nur dann automatisch einer Rechnung zuordnen, wenn deren Beträge zueinander passen.
|
||||
- Ergebnis: Zahlungszuordnung ist Betrags- und Zustimmungs-gedeckt; Falschzuordnungen bleiben sichtbar.
|
||||
- Belege: [PRIMÄR] F-F14..17 — Anbindung und Lizenzprüfung durchgesetzt; Consent-Auswertung fehlt dort (Befund); [PRIMÄR] G-F32 — Zuordnungsregel nachgewiesen.
|
||||
- Prüfidee: Zustimmung widerrufen und Abruf versuchen → Abruf muss scheitern; Eingang 500 EUR gegen Rechnung 600 EUR → keine automatische vollständig-zugeordnet-Setzung.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (F-F14..17, G-F32)
|
||||
- Übernahmewürdigkeit: hoch — PSD2-rechtlich und abrechnungsrelevant.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-036 — SEPA-Lastschriftangaben sind auf Gültigkeit zu prüfen**
|
||||
- ID: StRS-036
|
||||
- Titel: SEPA-Lastschriftangaben sind auf Gültigkeit zu prüfen
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Buchhaltung, Kunde
|
||||
- Vorbedingung: SEPA-Verbindungsdaten werden erfasst oder per Unterschrift bestätigt
|
||||
- Fakt: H-F10/11[P]: IBAN-Modulo-97, Länge 15-34, BIC+BLZ-Prüfung, 20 MB Dokument; D-F08[P]: SEPA als Standard-Exportweg; G-F29[P]: SEPA-Vorlagenpflichten
|
||||
- Aussage: Das System soll SEPA-Angaben (Kontonummer/IBAN, Prüfmerkmal, Bankleitzahl) vor Speicherung auf formale Gültigkeit prüfen und die Lastschrift-Ermächtigung nur zusammen mit einer gültigen Kundenerklärung übernehmen.
|
||||
- Ergebnis: Rücklastschriften wegen Tippfehlern und Ermächtigungslücken werden vermieden.
|
||||
- Belege: [PRIMÄR] H-F10/11 — formale Prüfungen durchgesetzt; [PRIMÄR] G-F29 — Vorlagenpflicht; [PRIMÄR] D-F08 — SEPA-Auslieferungsweg.
|
||||
- Prüfidee: IBAN mit falscher Prüfsumme sowie Länge 14 → Erfassung verweigert; Unterschriftsprozess ohne SEPA-Vorlage → Abschluss verweigert.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — Lastschriftprozess.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-037 — Versandabwicklung liefert gültige Belege der Dienstleister**
|
||||
- ID: StRS-037
|
||||
- Titel: Versandabwicklung liefert gültige Belege der Dienstleister
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Versandmitarbeiter, Logistikdienstleister (extern)
|
||||
- Vorbedingung: Ein Liefervorgang wird über einen Versanddienstleister abgewickelt
|
||||
- Fakt: F-F04..6 GLS[P]: zweistufige Validierung, Labels→PDF; F-F07..9 Shipcloud[P]: Pflichtfelder, Schlüssel verschlüsselt
|
||||
- Aussage: Das System soll Versandaufträge erst nach Prüfung aller Pflichtangaben des gewählten Dienstleisters übermitteln und das daraus erhaltene Versandetikett dem Bearbeiter als druckbares Dokument bereitstellen.
|
||||
- Ergebnis: Sendungen erhalten rechtsgültige Labels, ohne dass unvollständige Aufträge beim Dienstleister scheitern.
|
||||
- Belege: [PRIMÄR] F-F04..06 GLS-Validierungsstelle; [PRIMÄR] F-F07..09 Shipcloud-Pflichtfeldprüfung.
|
||||
- Prüfidee: Sendung ohne Pflichtfeld (z. B. Gewicht) → Versandanlage bricht mit Meldung ab, Label wird nicht erzeugt; vollständige Sendung → PDF-Label im Dokumentenbestand.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (F-F04..06, F-F07..09)
|
||||
- Übernahmewürdigkeit: hoch — ausgehender Warenfluss.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-038 — Ausfuhren sind mit vollständigen Zollangaben vorzubereiten**
|
||||
- ID: StRS-038
|
||||
- Titel: Ausfuhren sind mit vollständigen Zollangaben vorzubereiten
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Versandmitarbeiter, Zollbehörde (extern)
|
||||
- Vorbedingung: Eine Sendung geht in ein Nicht-EU-Ziel
|
||||
- Fakt: F-F07..9 Shipcloud[P]: Zolldaten werden im Versandpfad niemals gefüllt
|
||||
- Aussage: Das System soll bei Ausfuhren die zollrechtlich erforderlichen Angaben erheben und dem Dienstleister vollständig übermitteln.
|
||||
- Ergebnis: Ausfuhren können ohne nachträgliche manuelle Zollanlagen versandt werden.
|
||||
- Belege: [PRIMÄR] F-F07..09 — durchsetzende Stelle zeigt das dauerhafte Nicht-Befüllen; für den gegenteiligen Soll-Zustand existiert kein Beleg [HYPOTHESE].
|
||||
- Prüfidee: Sendung in die Schweiz mit Zollpflichtartikel → Zollfelder müssen gepflegt und übermittelt sein; derzeit zu erwarten: keine Füllung (Prüfpunkt).
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: mittel — fachlich plausibel, aber Anforderungsgrund (Zollprozess wirklich im Haus?) unbelegt.
|
||||
- Status: HYPOTHESE (Begründung: Beleg nur für fehlende Umsetzung, nicht für gewollten Soll-Zustand; offene Frage: Werden Ausfuhren im Haus verzollt oder durch Spediteure?)
|
||||
|
||||
- **StRS-039 — Helpdesk-Vorgänge sind berechtigt, nachvollziehbar und erst nach Leistungserfüllung schließbar**
|
||||
- ID: StRS-039
|
||||
- Titel: Helpdesk-Vorgänge sind berechtigt, nachvollziehbar und erst nach Leistungserfüllung schließbar
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Supportmitarbeiter, Supportleiter
|
||||
- Vorbedingung: Ein Kundenticket wird bearbeitet oder geschlossen
|
||||
- Fakt: A-F35[P/K]: Helpdesk-Rechte, keine Statusübergangsregeln; B-F011 Zt.148-291[P]: nur-eigene/nur-Filiale durchgesetzt; G-F28[P]: Serverfreigabe + nicht abgerechnete/laufende Zeiten blockieren Abschluss; H-F12[P]: Checklistenblockade im Massenpfad, Einzelpfad ohne (Widerspruch); H-F13/14[P/S]: Zeiten nur vor Weiterverarbeitung signierbar
|
||||
- Aussage: Das System soll Ticketzugriff auf eigene bzw. freigegebene Filialtickets beschränken, den Abschluss von Serverfreigabe, erledigten Checklisten und vollständig abgerechneten Zeiten abhängig machen und dabei Einzel- und Massenpfad gleich behandeln.
|
||||
- Ergebnis: Kein Vorgang schließt mit unerledigten Pflichten oder abrechenbaren Zeiten.
|
||||
- Belege: [PRIMÄR] B-F011 Zt.148-291, G-F28, H-F12 — Zugriffs-, Abschluss- und Checklistenprüfung; Widerspruch Massen-/Einzelpfad selbst [PRIMÄR]; [KONTEXT] A-F35 für Statistikteil.
|
||||
- Prüfidee: Ticket mit offener Checkliste im Massenpfad schließen → verweigert; im Einzelpfad muss dieselbe Sperre gelten; Benutzer B sieht Ticket von A (andere Filiale) nicht; Abschluss trotz laufender Zeit → verweigert.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (A-F35, B-F011, G-F28, H-F12, H-F13/14)
|
||||
- Übernahmewürdigkeit: hoch — Serviceprozess und Abrechnungsherkunft.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-040 — Kundeneingangs-E-Mails werden Belegen und Tickets zugeordnet**
|
||||
- ID: StRS-040
|
||||
- Titel: Kundeneingangs-E-Mails werden Belegen und Tickets zugeordnet
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Supportmitarbeiter, Sachbearbeiter
|
||||
- Vorbedingung: Eine E-Mail eines Kunden trifft ein
|
||||
- Fakt: H-F20..23[P]: Beleg-/Ticketbezug aus Betreff-Heuristik, Anhänge→Dokument 25 MB an Ticket, Blacklist-Ordner unsichtbar; A-F35[P/K]: Mail-Versandvalidierung
|
||||
- Aussage: Das System soll eingehende Kundennachrichten automatisch dem fachlich passenden Beleg oder Ticket zuordnen, Anhänge bis zur vereinbarten Größe dem Vorgang als Dokument beifügen und als unverfänglich eingestufte Bereiche für die Bearbeitung ausblenden.
|
||||
- Ergebnis: Kommunikation hängt am Vorgang statt im Postfach des Einzelnen.
|
||||
- Belege: [PRIMÄR] H-F20..23 — Zuordnung, Anhangübernahme und Blacklist dort durchgesetzt; [PRIMÄR]/[KONTEXT] A-F35 Mailversandprüfung.
|
||||
- Prüfidee: E-Mail mit Betreff „Rechnung 4711“ → Bezug zur Rechnung 4711 gesetzt; Anhang 20 MB an Ticket → Dokument vorhanden; Anhang 30 MB → abgewiesen; Blacklist-Ordner → in Liste nicht sichtbar.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (H-F20..23, A-F35)
|
||||
- Übernahmewürdigkeit: hoch — dokumentiert und geprüft umsetzbar.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-041 — Portalbestellungen laufen über Warenkorb und werden fachlich geprüft freigegeben**
|
||||
- ID: StRS-041
|
||||
- Titel: Portalbestellungen laufen über Warenkorb und werden fachlich geprüft freigegeben
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Kunde (Web-Account), Vertriebsmitarbeiter
|
||||
- Vorbedingung: Ein Kunde bestellt im Portal
|
||||
- Fakt: H-F05..07[P]: WebCart Admin-Recht, Clearance zweistufig (prüfen vs. bestellen), Mindestmenge 1, Ticketanlage Recht; A-F36[P]: Warenkorb-„Löschen“ = Abschließen, Web-Account an eigenen Kunden gebunden; B-F012 Zt.202-227[P]
|
||||
- Aussage: Das System soll Portalbestellungen über den kundeneigenen Warenkorb führen, Bestellungen nur nach der vorgeschalteten fachlichen Prüfung durch Berechtigte freigeben und dabei Mindestmengen beachten.
|
||||
- Ergebnis: Kundenbestellungen sind vor Fehlkäufen geschützt und durchlaufen die gleiche Freigabe wie innere Bestellungen.
|
||||
- Belege: [PRIMÄR] H-F05..07 — Clearance- und Mindestmengenprüfung durchsetzend; [PRIMÄR] A-F36, B-F012 — Kundenbindung und Warenkorbbehandlung.
|
||||
- Prüfidee: Bestellung mit Menge 0 → abgewiesen; Kunde mit Clearance-Stufe „prüfen“ bestellt nicht; Warenkorb „löschen“ → Abschluss, kein Verlust der historischen Belege.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (H-F05..07, A-F36, B-F012)
|
||||
- Übernahmewürdigkeit: hoch — Selbstbedienungsschiene.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-042 — Angebotsannahme und Mengenänderung bedürfen ausdrücklicher Kundenerlaubnis**
|
||||
- ID: StRS-042
|
||||
- Titel: Angebotsannahme und Mengenänderung bedürfen ausdrücklicher Kundenerlaubnis
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Kunde (Web-Account), Vertriebsmitarbeiter
|
||||
- Vorbedingung: Ein Angebot liegt dem Kunden im Portal vor
|
||||
- Fakt: H-F08/09[P]: Annehmen/Ablehnen/Mengenänderung nur mit Erlaubnis-Bits, sonst Unterschrift, Mengenänderung als Genehmigungsanfrage, Stückliste Faktor; H-F24[P]: Erlaubnis-Bits Default 0
|
||||
- Aussage: Das System soll dem Kunden das Annehmen, Ablehnen und Ändern von Angebotsmengen nur gewähren, wenn ihm diese Befugnisse ausdrücklich eingeräumt wurden, Mengenänderungen als neuen Genehmigungsschritt auslösen und andernfalls die Unterschrift verlangen.
|
||||
- Ergebnis: Vertragserklärungen entstehen nur mit nachweisbarer Kundenzustimmung.
|
||||
- Belege: [PRIMÄR] H-F08/09 und H-F24 — Erlaubnis-Bits, Default-Ablehnung und Genehmigungsanfrage sind an der Prüfstelle belegt.
|
||||
- Prüfidee: Kunde ohne Annehmen-Bit versucht Angebotsannahme im Portal → abgelehnt, Unterschriftsprozess erscheint; Mengenänderung mit Bit → Angebot wird zur Genehmigung zurückgeführt, Faktor-Berechnung korrekt.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (H-F08/09, H-F24)
|
||||
- Übernahmewürdigkeit: hoch — rechtssichere Vertragserklärung.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-043 — Kundenerklärungen sind elektronisch unterzeichnungsfähig**
|
||||
- ID: StRS-043
|
||||
- Titel: Kundenerklärungen sind elektronisch unterzeichnungsfähig
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Kunde (Web-Account), Vertriebsmitarbeiter
|
||||
- Vorbedingung: Ein Dokument erfordert die Unterschrift des Kunden
|
||||
- Fakt: H-F10/11[P]: Dokumentunterschrift, SEPA-Feldprüfungen bei Lastschrift-Ermächtigung, 20 MB Grenze
|
||||
- Aussage: Das System soll die Unterschrift des Kunden an einem Dokument ermöglichen, dabei die Größe des Dokuments begrenzen und bei Lastschrift-Ermächtigungen die Bankangaben des Kunden formal prüfen.
|
||||
- Ergebnis: Unterschriftenprozesse sind medienbruchfrei und tragfähig archivierbar.
|
||||
- Belege: [PRIMÄR] H-F10/11 — Signier- und Prüfstelle.
|
||||
- Prüfidee: Dokument 21 MB zur Signatur → Abweisung mit Größenmeldung; signierte Urkunde enthält Anzeiger von Unterzeichner und Zeitpunkt; IBAN-Fehler während Signatur → Abbruch der Erklärung.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-044 — Stammblatt-, Kampagnen- und Provisionsregeln sind vollständig zu führen**
|
||||
- ID: StRS-044
|
||||
- Titel: Stammblatt-, Kampagnen- und Provisionsregeln sind vollständig zu führen
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Marketingleitung, Vertriebsmitarbeiter
|
||||
- Vorbedingung: Kundendaten, Kampagnen oder Provisionen werden gepflegt
|
||||
- Fakt: G-F24-26[S/P]: Stammblatt-/CRM-/Kampagnen-Regeln; A-F33[P]: Pflichtfeldeinstellungen (Erinnerungstage, WEEE, Provision Auto); A-F34[P]: Provision DB-Constraints (Empfänger-/Quellen-/Wertemenü); C-F28[P/K]: Sprache nur an Adresse
|
||||
- Aussage: Das System soll Kampagnen- und Provisionsangaben nur nach vollständiger, vorgabekonformer Pflege übernehmen (Empfänger, Quelle und Wert aus zulässigen Ausprägungen, automatische Provision an gepflegte Voraussetzung gebunden) und sprachliche Kundenangaben an der Adressbeziehung führen.
|
||||
- Ergebnis: Marketing- und Provisionsauswertungen beruhen auf konsistenten, vergleichbaren Daten.
|
||||
- Belege: [PRIMÄR] A-F33, A-F34 — Pflichtfeld- und Menüzwang durchgesetzt; [SEKUNDÄR] G-F24-26; [KONTEXT] C-F28.
|
||||
- Prüfidee: Provisionsempfänger außerhalb des Wertemenüs speichern → Datenbank/Dataentry weist ab; automatische Provision ohne gepflegte Quelle → keine Ableitung; Sprache an der Kundenadresse, nicht am Kundenkopf gepflegt.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (A-F33, A-F34, G-F24-26, C-F28)
|
||||
- Übernahmewürdigkeit: mittel-hoch — Provisionsanteil primär, Kampagnenteil nur sekundär belegt.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-045 — Warenrückgaben sind geregelt und nachweisbar**
|
||||
- ID: StRS-045
|
||||
- Titel: Warenrückgaben sind geregelt und nachweisbar
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Servicemitarbeiter, Kunde
|
||||
- Vorbedingung: Ein Kunde gibt gelieferte Ware zurück
|
||||
- Fakt: G-F36[P]: RMA-Regeln im Client
|
||||
- Aussage: Das System soll Warenrückgaben über einen geregelten Rückgabeprozess mit zugeordneter Rückgabeabwicklung erfassen, sodass Rückgabe, Wareneingang und Folgebuchung einem ursprünglichen Vorgang zuordenbar bleiben.
|
||||
- Ergebnis: Rückläufe sind steuerbar und rechnerisch dem Ursprungskunden zuordenbar.
|
||||
- Belege: [PRIMÄR] G-F36 — RMA-Regelstelle im Client.
|
||||
- Prüfidee: Rückgabe ohne RMA-Zuordnung zum Originalbeleg → Vorgang nicht abschließbar; abgeschlossene Rückgabe → Gutschriftsfähigkeit vorhanden.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: mittel — Beleg benennt Regeln, nicht den vollständigen Soll-Ablauf.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-046 — Produktionsschritte sind gesperrt und mit Ist-Werten abzuschließen**
|
||||
- ID: StRS-046
|
||||
- Titel: Produktionsschritte sind gesperrt und mit Ist-Werten abzuschließen
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Produktionsmitarbeiter, Fertigungsleitung
|
||||
- Vorbedingung: Ein Arbeitsschritt der Fertigung wird gestartet und beendet
|
||||
- Fakt: H-F15[P]: Sperre bei Arbeit, Fertig setzt Soll = Ist, ohne Berechtigungsprüfung
|
||||
- Aussage: Das System soll einen Produktionsschritt für die Dauer der Arbeit gegen Parallelbearbeitung sperren und beim Abschluss die Vorgabe- durch die Ist-Menge ersetzen lassen; der Schrittabschluss soll fachlich berechtigten Personen vorbehalten sein.
|
||||
- Ergebnis: Fertigungsmeldungen sind eindeutig verantwortet und Mengen laufen korrekt auf.
|
||||
- Belege: [PRIMÄR] H-F15 — Sperre und Soll=Ist-Setzung dort durchgesetzt; das Fehlen der Berechtigungsprüfung ist derselbe Befund (Soll-Formulierung daraus abgeleitet).
|
||||
- Prüfidee: Zwei Nutzer starten denselben Schritt → zweiter wird gesperrt; Abschluss durch Benutzer ohne Fertigungsberechtigung → derzeit möglich, Anforderung verlangt Abweisung (Prüfpunkt); Abschluss setzt Ist auf Vorgabe.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: mittel-hoch — Mengengerüst primär, Berechtigungsteil abgeleitet.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-047 — Der Arbeitsplatz behält gültige Sitzungen und weist auf Versionsstand hin**
|
||||
- ID: StRS-047
|
||||
- Titel: Der Arbeitsplatz behält gültige Sitzungen und weist auf Versionsstand hin
|
||||
- Ebene: StRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Gebrauchstauglichkeit, Kompatibilität
|
||||
- Akteur: Mitarbeiter, Administrator, Hersteller
|
||||
- Vorbedingung: Ein Mitarbeiter arbeitet an den Fachclients
|
||||
- Fakt: G-F05/6[P]: Ticket-Erneuerung/Heartbeat 5 min, Ablaufmeldung, kein Offline; G-F08[P]: Client-/Webservice-Version Major.Minor.Build muss übereinstimmen; G-F09[P]: Update nur Hinweis, kein Selbstupdate, Windows only
|
||||
- Aussage: Das System soll dem Mitarbeiter abgelaufene oder versionsinkonsistente Arbeitsplätze eindeutig anzeigen, die weitere Arbeit erst nach gültiger Anmeldung bzw. passendender Version gestatten und den Nutzer nicht stillschweigend in einen unbedienbaren Zustand versetzen.
|
||||
- Ergebnis: Kein Mitarbeiter arbeitet unwissentlich mit veralteten Funktionen oder verliert eine gültige Sitzung unbemerkt.
|
||||
- Belege: [PRIMÄR] G-F05/6, G-F08, G-F09 — Verhaltensweisen an den geprüften Stellen real.
|
||||
- Prüfidee: Client einer abweichenden Minor-Version verbindet → Hinweis/Blockade statt Mischbetrieb; Sitzung nach Trennung > Heartbeat-Fenster → meldet Abmeldung; Hinweis auf verfügbares Update erscheint, ohne dass der Client sich selbst überschreibt.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein (G-F05/6, G-F08, G-F09)
|
||||
- Übernahmewürdigkeit: mittel — Betriebsanforderung, für Kunden nachvollziehbar zu formulieren.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-048 — Nutzungsdaten an den Hersteller sind offenzulegen und zu begrenzen**
|
||||
- ID: StRS-048
|
||||
- Titel: Nutzungsdaten an den Hersteller sind offenzulegen und zu begrenzen
|
||||
- Ebene: StRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Vertraulichkeit)
|
||||
- Akteur: Hersteller, Betreiberverantwortlicher
|
||||
- Vorbedingung: Die Installation übermittelt Nutzungs- und Umgebungsdaten
|
||||
- Fakt: E-F18[P,HYP]: Telemetrie alle 15 min an Hersteller (Kunde/DB-Guid/Hardware-IDs), kein Opt-out; E-F19[P]: Hardware-ID per ENV austauschbar
|
||||
- Aussage: Das System soll an den Hersteller übermittelte Nutzungs- und Umgebungsdaten auf den vereinbarten Zweck begrenzen, dem Betreibenden offenlegen und — soweit vertraglich vereinbart — abschaltbar machen.
|
||||
- Ergebnis: Der Betrieb kann datenschutzrechtlich begründen, was die Installation verlässt.
|
||||
- Belege: [PRIMÄR] E-F18 — Übermittlung mit Inhalt/Intervall nachgewiesen, Opt-out-Fehlen dokumentiert; [HYPOTHESE] für die Soll-Frage (HYP-Kennzeichnung des Faktens bleibt maßgeblich).
|
||||
- Prüfidee: Netzwerkbeobachtung über 30 Minuten → genau die offengelegten Datenarten und Intervalle; Schalter „Telemetrie aus“ vorhanden → keine Übertragung mehr.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: mittel — Soll-Umfang (Abschaltbarkeit) nicht belegt.
|
||||
- Status: HYPOTHESE (Begründung: kein Beleg, ob Telemetrie vertraglich gewollt/begrenzt ist; offene Frage: Ist ein Opt-out fachlich/vertraglich gefordert?)
|
||||
|
||||
- **StRS-049 — Zugangskennungen zu externen Diensten sind unlesbar aufzubewahren**
|
||||
- ID: StRS-049
|
||||
- Titel: Zugangskennungen zu externen Diensten sind unlesbar aufzubewahren
|
||||
- Ebene: StRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Schutzbedarf)
|
||||
- Akteur: Administrator, Dienstleister (extern), System
|
||||
- Vorbedingung: Die Installation bindet externe Dienste an
|
||||
- Fakt: F-F07..9[P]: Shipcloud-Schlüssel verschlüsselt; F-F19..21[P]: ITscope AccountId hart, Key 2 Stellen; F-F22/23[P]: docuFORM OAuth2+PKCE+AES mit Hotline-MasterKey und Recht SETTINGS; E-F21[P,HYP]: SecretKey+SQL-Klartext Konfiguration
|
||||
- Aussage: Das System soll Zugangskennungen zu externen Dienstleistern so aufbewahren, dass sie aus Konfiguration und Sicherungen nicht im Klartext lesbar sind, und ihr Einsatz an eine Fachberechtigung binden.
|
||||
- Ergebnis: Externe Konten (Versand, Bank, Produktportale) sind bei Konfigurationsabfluss nicht unmittelbar übernehmbar.
|
||||
- Belege: [PRIMÄR] F-F07..09 Shipcloud-Verschlüsselung als durchgesetzter Mechanismus; [PRIMÄR] F-F22/23 — Recht SETTINGS als durchgesetzte Nutzungsbinde; gegenteilige Befunde (ITscope, E-F21) dokumentiert.
|
||||
- Prüfidee: Konfigurationsdatei/Datenbanksicherung öffnen → kein Dienstleistungsschlüssel im Klartext; Aufruf der docuFORM-Funktion ohne SETTINGS-Recht → verweigert.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch — ein Schutzziel, mehrere Befunde konsolidiert.
|
||||
- Status: belegt
|
||||
|
||||
- **StRS-050 — Wartungs- und Migrierungsmaßnahmen sind nur Berechtigten vorbehalten**
|
||||
- ID: StRS-050
|
||||
- Titel: Wartungs- und Migrierungsmaßnahmen sind nur Berechtigten vorbehalten
|
||||
- Ebene: StRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal:
|
||||
- Akteur: Administrator, System
|
||||
- Vorbedingung: Das System führt Änderungen an Struktur oder Daten durch
|
||||
- Fakt: B-F023[P]: Script-Engine ohne Berechtigungsprüfung, Idempotenz DBUpdate; B-F022[P]: Lizenz-Gate vor Start/Migration; H-F38..42[P/K]: Deployments/Pipelines, Integrationstests deaktiviert
|
||||
- Aussage: Das System soll das Ausführen von Wartungs- und Migrierungsmaßnahmen nur durch berechtigte Verwaltungsrollen gestatten und Wiederholungen derselben Maßnahme ohne Schaden erlauben.
|
||||
- Ergebnis: Niemand kann ohne Verwaltungsrolle Bestandsdaten oder Strukturen verändern.
|
||||
- Belege: [PRIMÄR] B-F022 Zt.219-236 — Lizenz-/Migrationspforte als existierende Schutzinstanz; [PRIMÄR] B-F023 — Befund der fehlenden Rechteprüfung an der Scriptstelle; Soll daraus abgeleitet [HYPOTHESE].
|
||||
- Prüfidee: Benutzer ohne Administrationsrecht startet Wartungsskript → Ausführung muss abgewiesen werden; zweimaliges Ausführen desselben Updates → gleicher Endzustand, keine Duplikatschäden.
|
||||
- Tracelinks: —
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: mittel — Schutzziel plausibel, fachliche Tragweite der Script-Engine unbelegt.
|
||||
- Status: HYPOTHESE (Begründung: kein Beleg dafür, dass eine Rollenprüfung für Wartungsskripte fachlich gewollt ist; offene Frage: Wer im Betrieb darf Strukturänderungen anstoßen?)
|
||||
+1415
File diff suppressed because it is too large
Load Diff
+983
@@ -0,0 +1,983 @@
|
||||
# SyRS – System-Anforderungen
|
||||
|
||||
Quelle: syrs-autor (Versuch 02, Prompt 03-A), übernommen unverändert. Faktenbasis: Batch A (Centron.BL), B (Administration/Sicherheit), C (DAO/Entities/Common), D (Schema/FiBu-Export), E (Webservice), F (externe APIs), G (WPF-Client), H (Nexus/shared/Infra). Tracelinks verweisen auf StRS-001–048; wo kein fachlicher StRS-Bezug existiert, ist die Lücke ausdrücklich benannt.
|
||||
|
||||
- **SyRS-001 — Systemauthenticatoren werden zentral geschaltet und einheitlich durchgesetzt**
|
||||
- ID: SyRS-001
|
||||
- Titel: Systemauthenticatoren werden zentral geschaltet und einheitlich durchgesetzt
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Integrität der Authentifizierung), Konfigurierbarkeit
|
||||
- Akteur: Administrator, System
|
||||
- Vorbedingung: Der Webservice ist gestartet; die Authentifizierungsmethode wird konfiguriert oder gewechselt
|
||||
- Fakt: B-F016, E-F33, E-F18, E-F19, E-F20
|
||||
- Aussage: Das System soll die zentral konfigurierte Systemauthentifizierungsmethode (Basic/AD/OIDC/None) auf allen Anmeldekanälen gleichmäßig wirksam machen, die bidirektionale Synchronisation zwischen XML-Konfiguration und AppSettings mit klarer, dokumentierter Priorität betreiben und den automatischen Rückfall auf Basic als Zustand sichtbar protokollieren, statt die tatsächlich geltende Methode im Undeutlichen zu lassen.
|
||||
- Ergebnis: Für jeden Anmeldeversuch ist eindeutig bestimmbar, welcher Authenticator entschieden hat; Konfigurationsdrift zwischen XML und AppSettings ist ausgeschlossen.
|
||||
- Belege: [PRIMÄR] AuthenticatorFactory 54-146 (Fabrik inkl. Fallback Basic); [PRIMÄR] CentronHost 419-439 (XML gewinnt); [PRIMÄR] AuthConfigurationController 40-111,113-154,168-247 (PATCH nur OIDC-Lizenz+HTTPS+Recht SETTINGS; Umschalter nur als angemeldeter Benutzer mit SETTINGS); [KONTEXT] E-F20 („Passport" existiert nicht, Default Basic).
|
||||
- Prüfidee: Methode auf AD umschalten → Basic-Pfad entscheidet nicht mehr; XML und AppSettings nach Sync vergleichen → identischer Stand; erzwungener Fallback auf Basic → protokolliert.
|
||||
- Tracelinks: StRS-006, StRS-011
|
||||
- Konsolidierung: ja (B-F016, E-F18, E-F19, E-F20, E-F33)
|
||||
- Übernahmewürdigkeit: hoch — mehrere durchsetzende Stellen
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-002 — Ticketlebensdauer folgt festen Gültigkeits- und Refresh-Regeln**
|
||||
- ID: SyRS-002
|
||||
- Titel: Ticketlebensdauer folgt festen Gültigkeits- und Refresh-Regeln
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Sitzungsschutz)
|
||||
- Akteur: System, Mitarbeiter
|
||||
- Vorbedingung: Ein Benutzer hält ein Login-Ticket
|
||||
- Fakt: B-F024, B-F025, E-F30
|
||||
- Aussage: Das System soll Login-Tickets mit definierten Laufzeiten verwalten (Login 30 min, Refresh-Schwelle 5 min, maximale Lebensdauer 1440 min), eine Erneuerung nur oberhalb der Refresh-Schwelle vornehmen, Ticket-IDs saliert erzeugen und die vollständige Ticketliste ausschließlich dem Recht Administration.SETTINGS zugänglich machen.
|
||||
- Ergebnis: Sitzungen sind zeitlich begrenzt und erneuern sich kontrolliert; fremde Tickets sind nicht ausspähbar.
|
||||
- Belege: [PRIMÄR] TicketBL 26-28,113-164 (Laufzeiten, Refresh-Bedingung, Salt); [PRIMÄR] TicketBL 183-186 (Recht auf GetAllTickets); [PRIMÄR] Schema 35892-35905 (ConnectionTickets: TicketID/ExpireDate/LicenseGUID/ApplicationID NOT NULL, Benutzerbezug optional).
|
||||
- Prüfidee: Ticket-Alter 4 min → Refresh ohne Verlängerung; Alter 6 min → Verlängerung; GetAllTickets ohne SETTINGS-Recht → Ablehnung.
|
||||
- Tracelinks: StRS-047, StRS-006
|
||||
- Konsolidierung: ja (B-F024, B-F025, E-F30)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-003 — Ticketvalidierung prüft den Ablaufzeitpunkt (Ist-Widerspruch als Prüfpunkt)**
|
||||
- ID: SyRS-003
|
||||
- Titel: Ticketvalidierung prüft den Ablaufzeitpunkt
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Sitzungsschutz)
|
||||
- Akteur: System, externer Aufrufer
|
||||
- Vorbedingung: Eine Anfrage wird mit Ticket validiert
|
||||
- Fakt: E-F12, E-F30
|
||||
- Aussage: Das System soll bei jeder Ticketvalidierung das Ablaufdatum prüfen und ein abgelaufenes Ticket ablehnen; der minütliche Löschjob DeleteExpiredTickets darf die Prüfpflicht nicht ersetzen, da ein abgelaufenes Ticket sonst bis zu einer Minute weiter gültig bleibt.
|
||||
- Ergebnis: Kein Zugriff mit abgelaufener Sitzung über den Löschjob-Takt hinaus.
|
||||
- Belege: [PRIMÄR] TicketRepository 70-76,121-135 und ConnectionTicketService 12-23 — belegt ist, dass die Ablaufprüfung beim Validieren unterbleibt und nur der Löschjob wirkt; [PRIMÄR, Widerspruch] TicketBL 26-28; der Befund begründet die Soll-Forderung.
|
||||
- Prüfidee: Ticket auf ExpireDate − 30 s setzen und Anfrage vor dem nächsten Löschlauf senden → Authentifizierung muss scheitern (401).
|
||||
- Tracelinks: StRS-003, StRS-047
|
||||
- Konsolidierung: ja (E-F12, E-F30)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-004 — Jeder Endpunkt verlangt persönliche Authentifizierung vor Ausführung**
|
||||
- ID: SyRS-004
|
||||
- Titel: Jeder Endpunkt verlangt persönliche Authentifizierung vor Ausführung
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Zugriffskontrolle)
|
||||
- Akteur: System, externer Aufrufer, Integrationspartner
|
||||
- Vorbedingung: Ein Aufruf läuft über MVC, WCF-Bridge oder Integrations-Controller ein
|
||||
- Fakt: E-F04, E-F05, E-F06, E-F07, E-F08
|
||||
- Aussage: Das System soll vor der Ausführung jedes Webservice-Endpunkts einen Authentifizierungsnachweis (Ticket oder AccessToken) verlangen und das Fehlen eines Authentifizierungsattributs als Ablehnung statt als ungeprüfte Durchführung behandeln; Integrationsrichtlinien, die nur eine Lizenz prüfen (CentronHosted), sind um eine personenbezogene Prüfung zu ergänzen.
|
||||
- Ergebnis: Keine der 1334 WebInvoke-Methoden ist ohne Prüfung erreichbar; 401/403 werden trennscharf geliefert.
|
||||
- Belege: [PRIMÄR] CentronWcfBridge 35-81 und AttributeBasedInterceptor 10-20 — attributlos ⇒ Proceed ohne Prüfung; Befund 174 von 1334 Methoden ohne Ticketprüfung; [PRIMÄR] CentronHost 186,274-282 (MVC global RequireAuthorization); [PRIMÄR] AuthenticateInterceptor 22-101 (Kommentar „deckt nicht alle Fälle ab"; AccessTokens umgehen Anwendungssperre); [PRIMÄR] CentronHostedAuthorization 12-24 (nur Lizenz CentronInternal, keine Person); [SEKUNDÄR] E-F05.
|
||||
- Prüfidee: Stichprobe aller WebInvoke-Methoden ohne Ticket → ausnahmslos 401; [AuthorizeCentronHosted]-Endpunkt mit gültiger Lizenz ohne Personennachweis → heute durchlässig, Soll: Ablehnung (Prüfpunkt).
|
||||
- Tracelinks: StRS-003, StRS-011
|
||||
- Konsolidierung: ja (E-F04–E-F08)
|
||||
- Übernahmewürdigkeit: hoch — sicherheitskritisch, primär belegt
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-005 — Angemeldete Identität wird ausschließlich aus dem validierten Ticket abgeleitet**
|
||||
- ID: SyRS-005
|
||||
- Titel: Angemeldete Identität wird ausschließlich aus dem validierten Ticket abgeleitet
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Verantwortlichkeit)
|
||||
- Akteur: System, externer Aufrufer, Client
|
||||
- Vorbedingung: Eine Anfrage enthält Ticket und zusätzlich übertragene Benutzerparameter oder Forwarding-Header
|
||||
- Fakt: E-F09, E-F10, E-F11, G-F04
|
||||
- Aussage: Das System soll den handelnden Benutzer ausschließlich aus dem validierten Ticket bzw. AccessToken ableiten und mitgeführte AppUserI3D-Parameter nur nach nachgewiesener Übereinstimmung mit der Ticketidentität auswerten; die Quell-IP soll nur aus vertrauenswürdigen Forwarding-Headern (X-Forwarded-For hinter definiertem Proxy) übernommen werden.
|
||||
- Ergebnis: Identität und herkunftsbezogene Regeln (u. a. 2FA-Merkfrist) sind gegen clientseitige Manipulation geschützt.
|
||||
- Belege: [PRIMÄR] TicketAuthenticationHandler 44-74,104-172 (Ticket aus Query/Header; IP aus clientkontrollierbarem X-Forwarded-For); [PRIMÄR] AuthenticationTicketBL 25-48,69-71 (Reihenfolge Ticket→AccessToken→nichts); [PRIMÄR] CentronRestService 319,326,2262 (AppUserI3D-Weiterreichung; die Stelle 200-215 leitet nur das Ticket ab — nach Belegprüfung korrigiert; Übereinstimmungspflicht unbelegt → HYP-Anteil); [PRIMÄR] G-F04 SetLoggedInUserInterceptor 11-27 (ohne ConnectionInfo läuft der Aufruf mit Benutzer 0).
|
||||
- Prüfidee: Anfrage mit Ticket Benutzer A und Parameter AppUserI3D=B → alle Schreib-/Auditvorgänge bleiben A zuordenbar; gefälschtes X-Forwarded-For → IP-Regeln entscheiden nicht aus der falschen Quelle.
|
||||
- Tracelinks: StRS-003, StRS-008
|
||||
- Konsolidierung: ja (E-F09, E-F10, E-F11, G-F04)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-006 — JWT-Validierung ist vollständig, Authentifizierungskonfiguration ist zugriffscontrolled**
|
||||
- ID: SyRS-006
|
||||
- Titel: JWT-Validierung ist vollständig, Authentifizierungskonfiguration ist zugriffscontrolled
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit
|
||||
- Akteur: System, Administrator
|
||||
- Vorbedingung: JWT ist über AppSettings (Authority+Audience) aktiviert oder soll konfiguriert werden
|
||||
- Fakt: E-F17, E-F18, E-F19, E-F20
|
||||
- Aussage: Das System soll nach Aktivierung (Authority und Audience gesetzt) bei jedem JWT-Request Issuer, Audience, Lifetime und Signatur prüfen; die Lese-Endpunkte der Authentifizierungskonfiguration dürfen anonym nur die minimal nötigen Angaben liefern, jede Änderung soll OIDC-Lizenz, HTTPS und das Recht SETTINGS voraussetzen.
|
||||
- Ergebnis: Token werden kryptografisch und inhaltlich verifiziert; die Authentifizierungskonfiguration ist gegen unbefugte Änderung geschützt.
|
||||
- Belege: [PRIMÄR] CentronHost 155-156,188-205 und JwtConfiguration 10-18 (Validierungsparameter, Aktivierungsbedingung); [PRIMÄR] AuthConfigurationController 40-111 (GET anonym; PATCH nur OIDC+HTTPS+SETTINGS), 113-154,168-247 (Umschalter nur als angemeldeter Benutzer mit SETTINGS).
|
||||
- Prüfidee: JWT fremder Audience bzw. abgelaufen → 401; PATCH /config/jwt über HTTP oder ohne SETTINGS → abgelehnt; anonymes GET → liefert keine Geheimwerte.
|
||||
- Tracelinks: StRS-006, StRS-011
|
||||
- Konsolidierung: ja (E-F17–E-F20)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-007 — Cross-Origin-Zugriffe sind auf registrierte Herkunfte begrenzt**
|
||||
- ID: SyRS-007
|
||||
- Titel: Cross-Origin-Zugriffe sind auf registrierte Herkunfte begrenzt
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Vertraulichkeit)
|
||||
- Akteur: System, Browser-Client (fremde Origin)
|
||||
- Vorbedingung: Der Webservice beantwortet Browser-Anfragen
|
||||
- Fakt: E-F16
|
||||
- Aussage: Das System soll CORS-Anfragen nur für konfigurierte, registrierte Herkunfte zulassen und die Vollöffnung AllowAnyOrigin durch eine restriktive Richtlinie ersetzen, damit fremde Webseiten im Sitzungszustand angemeldeter Benutzer keine Daten abrufen können.
|
||||
- Ergebnis: Kein fremder Origin kann die Schnittstelle in einer Benutzersitzung missbrauchen.
|
||||
- Belege: [PRIMÄR] CentronHost 266 — durchgesetzte Einstellung AllowAnyOrigin; der Befund begründet die Soll-Forderung.
|
||||
- Prüfidee: Preflight/Request von unbekannter Origin → vom Server abgelehnt; registrierte Nexus-/Portal-Origin → Erfolg.
|
||||
- Tracelinks: — Fachliche Lücke: Die StRS enthält keine Anforderung zur Herkunfts-/Transportabschottung; der nächste Bezug StRS-009 (Kundentrennung im Portal) deckt dies nicht ab.
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-008 — Hub-Zugänge vergleichen Geheimnisse zeitkonstant und sind gleichwertig abgesichert**
|
||||
- ID: SyRS-008
|
||||
- Titel: Hub-Zugänge vergleichen Geheimnisse zeitkonstant und sind gleichwertig abgesichert
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit
|
||||
- Akteur: System, Client (SignalR)
|
||||
- Vorbedingung: Ein Client verbindet einen Notification- oder Fach-Hub
|
||||
- Fakt: E-F15
|
||||
- Aussage: Das System soll den SecretKey-Zugriff auf Hubs durch hashbasierten, zeitkonstanten Vergleich prüfen (statt Stringgleichheit) und jede Hub-Richtlinie mit denselben Authentisierungs- und Berechtigungspflichten wie Ticket-Zugriffe belegen.
|
||||
- Ergebnis: SecretKey-Zugänge sind gegen Timing-Angriffe und gegen Umgehung der Personenberechtigung geschützt.
|
||||
- Belege: [PRIMÄR] SecretKeyHandler 11-31 (Bearer-Vergleich per Stringgleichheit, kein Hash/keine Zeitkonstanz); [PRIMÄR] Hubs [Authorize], NotificationsHub nur SecretKey-Policy.
|
||||
- Prüfidee: Timing-Messung bei SecretKey-Vergleichen mit variierenden Präfixen → keine Laufzeitunterschiede; NotificationsHub-Abo nur mit Secret → Berechtigungswirkung dokumentiert und prüfbar.
|
||||
- Tracelinks: StRS-047
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-009 — Passwörter werden gesalzen gespeichert und niemals im Klartext übergeben**
|
||||
- ID: SyRS-009
|
||||
- Titel: Passwörter werden gesalzen gespeichert und niemals im Klartext übergeben
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Vertraulichkeit)
|
||||
- Akteur: System, Mitarbeiter, Kunde (Web-Account)
|
||||
- Vorbedingung: Ein Passwort wird gespeichert, versendet, gemappt oder geändert
|
||||
- Fakt: B-F013, B-F018, B-F020, B-F040, G-F34
|
||||
- Aussage: Das System soll Passwörter ausschließlich mit einem salzgeführten, aktuellen Hashverfahren speichern (ungesalzenes SHA-1 in ANSI-1252-Kodierung ersetzen), die fehlerhafte Zuordnung der Datenbankspalte Kennwort auf das Feld BenutzerInfo2 beheben, WebAccount-Passwörter nicht per Klartext-E-Mail versenden, sondern den Benutzer über einen einmaligen Link zur eigenen Setzung führen, und die Mindestlängenprüfung ohne stillen Prüfungswegfall in jedem Änderungspfad anwenden.
|
||||
- Ergebnis: Datenbankdiebstahl und E-Mail-Abfangen liefern keine verwertbaren Passwörter; Entitäts-/Spaltenzuordnung ist widerspruchsfrei.
|
||||
- Belege: [PRIMÄR] SHA1Decoder 9-16 und BasicAuthenticator 46-50 (ungesalzenes SHA-1(ANSI1252), TODO „should be salted!!!"); [PRIMÄR] WebAccountBL 561-567 (Klartext-Passwort per E-Mail); [PRIMÄR, Widerspruch] Schema 18507 vs. AppUserMaps 24 (Kennwort-Spalte vorhanden, auf BenutzerInfo2 gemappt); [PRIMÄR, Widerspruch] UsersBL 124-130, WebAccountBL 185-188,243-246,479-480 (WebAccount min 8, Update ohne Prüfung, AppUser nur bei gepflegter Mindestlänge); [PRIMÄR] G-F34 PersonalPasswordChangeViewModel 103-118 (Client prüft nur Übereinstimmung).
|
||||
- Prüfidee: Reaktivierung eines WebAccounts → kein E-Mail-Text mit Passwort; Register mit 7 Zeichen → abgelehnt; UpdateWebAccount-Pfad mit 7 Zeichen → ebenfalls abgelehnt (Prüfpunkt, heute ohne Prüfung).
|
||||
- Tracelinks: StRS-006
|
||||
- Konsolidierung: ja (B-F013, B-F018, B-F020, B-F040, G-F34)
|
||||
- Übernahmewürdigkeit: hoch — sicherheitskritisch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-010 — Fehlgeschlagene Anmeldeversuche werden begrenzt und gezählt**
|
||||
- ID: SyRS-010
|
||||
- Titel: Fehlgeschlagene Anmeldeversuche werden begrenzt und gezählt
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Schutz vor Ausspähung)
|
||||
- Akteur: System, Angreifer (extern)
|
||||
- Vorbedingung: Ein Konto oder eine Quell-IP wird wiederholt mit falschen Nachweisen belegt
|
||||
- Fakt: B-F021
|
||||
- Aussage: Das System soll fehlgeschlagene Anmeldeversuche je Konto und Quelle zählen (Nutzung der vorhandenen Spalte AnmeldungFehlgeschlagen) und nach einer zu definierenden Schwelle die weitere Anmeldung vorübergehend sperren oder zusätzlich absichern, ohne dass ein LDAP-Fehlschlag (Code 49) den Zählerpfad vorzeitig verlässt.
|
||||
- Ergebnis: Systematisches Ausprobieren von Passwörtern wird ausgebremst und ist nachvollziehbar.
|
||||
- Belege: [HYPOTHESE] B-F021 — kein Brute-Force-Schutz auffindbar; Spalte vorhanden aber ungenutzt; AD-Authenticator bricht bei LDAP-49 sofort ab; kein Beleg, dass der Schutz bewusst nicht gewollt ist.
|
||||
- Prüfidee: 20 Fehlanmeldungen eines Kontos → der 21. Versuch wird blockiert oder zusätzlich bestätigt; Zählerstand in AnmeldungFehlgeschlagen nachvollziehbar.
|
||||
- Tracelinks: StRS-007
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: mittel — Schwellwerte fehlen
|
||||
- Status: HYPOTHESE (Begründung: Nicht-Auffindbarkeit als einziger Anhalt; offene Frage: Sind Schwellwert, Sperrdauer und Zählerquelle fachlich festgelegt?)
|
||||
|
||||
- **SyRS-011 — Passwortablauf und externe Authentifizierung werden erzwungen**
|
||||
- ID: SyRS-011
|
||||
- Titel: Passwortablauf und externe Authentifizierung werden erzwungen
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit
|
||||
- Akteur: System, Mitarbeiter
|
||||
- Vorbedingung: Ein Passwort überschreitet die gepflegte Ablauffrist; das Konto wird extern (AD/Entra) authentisiert
|
||||
- Fakt: B-F022, B-F023
|
||||
- Aussage: Das System soll die gepflegte Ablauffrist (KennAendNachTagen) bei der Anmeldung durchsetzen (Pflichtwechsel bei Überschreitung) und bei extern authentisierten Konten die lokale Passwortänderung gesperrt lassen, wobei der Nachweis des aktuellen Passworts in gespeicherter Hashform verlangt wird.
|
||||
- Ergebnis: Veraltete Passwörter werden zwangsweise erneuert; die Zuständigkeit Passwort/Identität bleibt je Kontotyp eindeutig.
|
||||
- Belege: [PRIMÄR] UsersBL 56-99 — Sperrung der Passwortänderung bei externer Auth und Pflicht zum aktuellen Passwort (SHA-1) durchgesetzt; [HYPOTHESE] B-F022 (UsersBL 101-122) — Frist gepflegt, keine durchsetzende Stelle gefunden.
|
||||
- Prüfidee: Konto mit abgelaufener Frist anmelden → erzwungener Passwortwechsel, danach normale Anmeldung; externes Konto ruft lokale Passwortänderung auf → abgelehnt (bereits belegt).
|
||||
- Tracelinks: StRS-006
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: mittel
|
||||
- Status: HYPOTHESE (Begründung: Durchsetzung der Ablaufprüfung nicht belegt, nur die Pflege der Frist; offene Frage: Soll die Ablaufregel global, je Mandant oder je Kontotyp gelten?)
|
||||
|
||||
- **SyRS-012 — Zwei-Faktor-Mechanik ist kanalübergreifend konsistent und nachvollziehbar**
|
||||
- ID: SyRS-012
|
||||
- Titel: Zwei-Faktor-Mechanik ist kanalübergreifend konsistent und nachvollziehbar
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Sicherheit
|
||||
- Akteur: System, Mitarbeiter, Kunde (Web-Account)
|
||||
- Vorbedingung: 2FA ist global oder je Benutzer aktiviert; ein Login oder Code-Lauf läuft an
|
||||
- Fakt: B-F027, B-F028, B-F029, B-F030, E-F21, E-F22, H-F19, H-F20, G-F07
|
||||
- Aussage: Das System soll die Zwei-Faktor-Authentisierung nach globalem Schalter und Benutzerflag auf allen Kanälen gleich anwenden, die Merk-Gültigkeit in Kalendertagen je (Benutzer, Anwendung, Maschine, IP) in TwoFactorAuthLastLogins führen, übersprungene Fälle (Radius-Validator bei WebAccounts) und stets HTTP 200 antwortende Code-Endpunkte protokollierbar sichtbar machen, E-Mail-Codes als GUID, befristet und einmalig behandeln, die TOTP-Parameter (SHA1, 30 s, 6 Stellen) durch ein gleichwertig dokumentiert sicheres Verfahren ersetzen und das Fehlen eines TOTP-Einrichtungswizards im Nexus als Lücke führen.
|
||||
- Ergebnis: Der zweite Faktor ist auf keinem Kanal auslassbar, und seine Gültigkeit ist überprüfbar protokolliert.
|
||||
- Belege: [PRIMÄR] TwoFactorAuthBL 33-94,82-179 inkl. Schema 53538-53550; [PRIMÄR, Widerspruch] RadiusTwoFactorValidator 48-49 (überspringt WebAccounts kommentarlos); [PRIMÄR] EmailTwoFactorValidator 31-98 und TwoFactorAuthController 15-27 (anonymer Code-Endpunkt, immer HTTP 200, Wirkung nur im Login-Task, kein Rate-Limit); [PRIMÄR] Totp.cs 14,34-42,71-75; [PRIMÄR] G-F07 LoginDialogViewModel 565-583; [K+HYP] H-F20 (kein TOTP-Wizard im Nexus; SetupWizard-Schritt ist der SignalR-Geheimschlüssel).
|
||||
- Prüfidee: 2FA-Benutzer mit gültigem Merk-Eintrag verbindet sich von anderer IP → erneute Challenge; E-Mail-Code zweimal verwendet → zweiter Versuch abgelehnt; Radius-Login eines WebAccounts → dokumentiertes, protokolliertes Verhalten statt stiller Überschreitung.
|
||||
- Tracelinks: StRS-008
|
||||
- Konsolidierung: ja (B-F027–B-F030, E-F21, E-F22, H-F19, H-F20, G-F07)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-013 — Rechtevergabe verläuft ohne Seiteneingang außerhalb der Gruppen**
|
||||
- ID: SyRS-013
|
||||
- Titel: Rechtevergabe verläuft ohne Seiteneingang außerhalb der Gruppen
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Verantwortlichkeit)
|
||||
- Akteur: Administrator, System
|
||||
- Vorbedingung: Rechte sollen einem Benutzer oder WebAccount erteilt werden
|
||||
- Fakt: B-F001, B-F002, B-F042
|
||||
- Aussage: Das System soll die Rechtevergabe ausschließlich über Gruppen modellieren; die direkte Rechtszuweisung an WebAccount-Konten (WebAccountsRights) ist entweder abzuschaffen oder denselben Beschränkungen, Prüfungen und der Protokollierung der Gruppenrechte zu unterwerfen, damit der Geltungsbereich beider Systeme widerspruchsfrei ist.
|
||||
- Ergebnis: Jede Rechtsposition ist über Gruppen und deren Pflege historisch erklärbar.
|
||||
- Belege: [PRIMÄR] AppRightsBL 63-111,644-664 (Gruppenmodell); [PRIMÄR, Widerspruch] AppRightsBL 113-130,670-691 und Schema 54877-54885 (direkte WebAccount-Rechte, Geltungsbereich ungeklärt); [KONTEXT] B-F042 (CentronRights.md).
|
||||
- Prüfidee: Recht direkt an einen WebAccount ohne Revisionseintrag setzen → Vorgang scheitert oder ist vollständig protokolliert; Rechtsauflösung liefert über Gruppen- und Direktrechte in derselben Prüffunktion konsistente Ergebnisse.
|
||||
- Tracelinks: StRS-001, StRS-009
|
||||
- Konsolidierung: ja (B-F001, B-F002, B-F042)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-014 — Änderungen an Rechten, Gruppen und Zuordnungen sind selbst pflichtgeprüft und konsistent**
|
||||
- ID: SyRS-014
|
||||
- Titel: Änderungen an Rechten, Gruppen und Zuordnungen sind selbst pflichtgeprüft und konsistent
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Integrität der Zugriffskontrolle)
|
||||
- Akteur: Administrator, System
|
||||
- Vorbedingung: Ein Aufruf ändert Rechte, Gruppen oder Zuordnungen
|
||||
- Fakt: B-F004, B-F007, B-F010
|
||||
- Aussage: Das System soll jede Änderung an Rechten, Gruppen und Zuordnungen (AddRightToRightGroup, AddUserToRightGroup, AssignGroupToRight, AssignAppUserToGroup u. a.) einer Berechtigungsprüfung unterwerfen, die Gruppenstammdaten-Pflege einschließlich DeleteRightGroup einheitlich an das Recht 10530 binden, Zuordnungen nicht-existenter Objekte ablehnen statt zu speichern und bei CopyRightGroup die Namenseindeutigkeit gegen die richtige (Ziel-)Gruppe prüfen.
|
||||
- Ergebnis: Rechte können nicht über ungeprüfte APIs beliebig ausgeweitet werden; Datenzugriff bleibt widerspruchsfrei.
|
||||
- Belege: [PRIMÄR] AppRightsBL 168-259,314-346 (Zuweisungs-APIs ohne Prüfung, speichert nicht-existente Zuordnungen — „We dont care"); [PRIMÄR] AppUserGroupBL 26-45,108-112; [PRIMÄR] AppRightsBL 348-374,388-389 (Recht 10530 für Stammdaten, Delete prüft es nicht); [PRIMÄR, Widerspruch] AppRightsBL 395-396,417-428,441-442 (Gruppenname eindeutig, Copy prüft falsche Gruppe); Aufrufseite [HYPOTHESE] (B-F007-Kennzeichnung).
|
||||
- Prüfidee: Benutzer ohne Administrationsrecht ruft AddUserToRightGroup auf → abgelehnt; Zuordnung auf gelöschte Gruppen-I3D → abgelehnt; CopyRightGroup mit bereits vergebener Kopie in der Zielgruppe → abgelehnt.
|
||||
- Tracelinks: StRS-001, StRS-004, StRS-005
|
||||
- Konsolidierung: ja (B-F004, B-F007, B-F010)
|
||||
- Übernahmewürdigkeit: hoch — sicherheitskritisch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-015 — Rechtvererbung und Rechtentzug behandeln Eltern-/Kindstrukturen symmetrisch**
|
||||
- ID: SyRS-015
|
||||
- Titel: Rechtvererbung und Rechtentzug behandeln Eltern-/Kindstrukturen symmetrisch
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Vollständigkeit der Rechteentziehung)
|
||||
- Akteur: Administrator, System, Prüfer
|
||||
- Vorbedingung: Ein Recht mit Eltern-/Kindstruktur wird einer Gruppe gegeben oder entzogen
|
||||
- Fakt: B-F009
|
||||
- Aussage: Das System soll beim Entzug eines Rechts dieselbe Eltern-/Kindstruktur anwenden, die bei der Zuweisung automatisch mitgegeben wurde — implizit mitvergebene Kindrechte sind beim Entzug des Elternrechts ausdrücklich zu widerrufen oder als bewusst restlos gekennzeichnet auszuweisen.
|
||||
- Ergebnis: Nach einem Entzug besitzt niemand implizit verbliebene Zugriffe; die Rechtsmatrix ist rückstandsfrei.
|
||||
- Belege: [PRIMÄR, Widerspruch] AppRightsBL 261-299 — Elternrecht wird bei Zuweisung rekursiv mitgegeben, bei Entzug nicht; der Widerspruch ist im Fakt benannt und begründet die Anforderung.
|
||||
- Prüfidee: Kindrecht implizit über Elternrecht erhalten, Elternrecht entziehen → Rechtsauflösung darf das Kindrecht nicht mehr liefern (heute zu erwarten: doch → Prüfpunkt).
|
||||
- Tracelinks: StRS-001
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-016 — Filial- und Mandantentrennung ist ein Querschnittsfilter der Datenhaltung und Rechteverwaltung**
|
||||
- ID: SyRS-016
|
||||
- Titel: Filial- und Mandantentrennung ist ein Querschnittsfilter der Datenhaltung und Rechteverwaltung
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Vertraulichkeit)
|
||||
- Akteur: System, Filialverantwortlicher, Mandantenbetreuer
|
||||
- Vorbedingung: Mehrmandanten-/Mehrfilialbetrieb; Aufrufe laufen über GenericDAO oder Rechte-APIs
|
||||
- Fakt: B-F003, B-F037, C-F18, C-F19, C-F20, D-F13, D-F14, D-F15, D-F16, D-F17, D-F18, D-F86
|
||||
- Aussage: Das System soll die Filialgrenze (MANAGE_RIGHTS_ONLY_OWN_BRANCH) in allen Rechte-Gruppen-APIs (GetAllRightGroups, DeleteRightGroup, SaveRightGroup, CopyRightGroup) erzwingen und die Mandanten-/Filialtrennung systematisch in der Datenschicht verankern, statt sie dem einzelnen Aufrufer zu überlassen (GenericDAO ohne automatischen Filter, NHibernate-Filter nicht aktiv, Filialfilter nur auskommentiert); Mandanten-/Filial-Schlüssel (FilialI3D, FilialgeberI3D) sind beim Speichern verpflichtend zu setzen, Sonderfälle (Hauptsitz-ID 0, IsBranchEqual bei null/≤0, Mandator-Default==1) sind zu definieren und die Filialdatenpflege (BranchBL.SaveBranchDetails) ist pflichtzuprüfen.
|
||||
- Ergebnis: Kein Aufrufer kann mandanten- oder filialfremde Daten lesen/schreiben, nur weil ein Einzelmodul den Filter vergisst.
|
||||
- Belege: [PRIMÄR] AppRightsBL 39-48,355-357,391-393,444-446 (Filialfilter der Rechte-APIs); [PRIMÄR] GenericDAO 33-64,346-353 (kein Mandanten-/Filialfilter); [PRIMÄR/Negativ] MandatorMaps 39-44 (kein aktiver NHibernate-Filter, Filialfilter auskommentiert); [PRIMÄR] SaveReceiptInvoiceRepository 225-226 (FilialI3D/FilialgeberI3D beim Speichern; nach Belegprüfung datiert); [PRIMÄR/K] BranchBL 61-64,214-223 (SaveBranchDetails ungeprüft, Hauptsitz=0, IsBranchEqual-Defekt) und MandatorBL 19-33 (Default==1; nach Belegprüfung separate Stelle); [PRIMÄR/Faktenkatalog D] D-F13–D-F19 (nur 20 Mandantentabellen, Trennung über I3D/Filiale; Quelle SSMS_DB_SCHEMA.sql); [HYPOTHESE] D-F86 (Mandantentrennung des FiBu-Exports nicht auffindbar).
|
||||
- Prüfidee: Mandanten-A-Token auf Objekt des Mandanten B → datenseitig keine Treffer (nicht nur gefilterte Sicht); Rechte-API-Aufruf mit MANAGE_RIGHTS_ONLY_OWN_BRANCH liefert nur eigene Filialgruppen; SaveBranchDetails ohne Recht → abgelehnt.
|
||||
- Tracelinks: StRS-002, StRS-010
|
||||
- Konsolidierung: ja (B-F003, B-F037, C-F18, C-F19, C-F20, D-F13–D-F19, D-F86)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-017 — Zugriffsentscheidungen bleiben auf allen Kanälen fail-closed; Authenticator-Übersteuerung ist verboten**
|
||||
- ID: SyRS-017
|
||||
- Titel: Zugriffsentscheidungen bleiben auf allen Kanälen fail-closed; Authenticator-Übersteuerung ist verboten
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Zuverlässigkeit der Zugriffskontrolle)
|
||||
- Akteur: System, externer Aufrufer, Kunde (Web-Account)
|
||||
- Vorbedingung: Eine Rechteprüfung läuft über WebAccountAuthenticator, MVC-Attribute oder Benutzerrechtserweiterung
|
||||
- Fakt: B-F008, B-F015, B-F017, E-F13, E-F14
|
||||
- Aussage: Das System soll die anwendungsbezogene Rechteprüfung (ValidateRights) auf allen Authentifizierungspfaden gleich anwenden; der WebAccountAuthenticator darf das Prüfungsergebnis nicht pauschal auf Erfolg (AsSuccess) setzen, HasUserRight/IsAdmin müssen bei jedem Fehler ablehnend bleiben, und ein leeres Rechte-Array muss zu 403 (Forbid) führen, nicht zu Zugriff.
|
||||
- Ergebnis: Kein Anmeldeweg — insbesondere kein Portal-Login — umgeht die Rechteprüfung; Fehlerzustände gewähren niemals Zugriff.
|
||||
- Belege: [PRIMÄR] UserRightsExt 18-66 (fail-closed); [PRIMÄR, Widerspruch] Authenticator 68-86 vs. WebAccountAuthenticator 37-40 (AsSuccess überschreibt Rechteprüfung); [PRIMÄR] WebAccountBL 54-105 (Login nur Status==1+Beziehung, schreibt LastLoginIP/Date); [PRIMÄR] AuthorizeUserRightAttribute 38-55 (401/403, leeres Array ⇒ Forbid); [PRIMÄR/Faktenkatalog E] E-F14 (laut Belegprüfung inhaltlich durch die beiden vorigen Stellen gedeckt).
|
||||
- Prüfidee: WebAccount ruft nach Login eine interne Funktion ohne zugeordnetes Recht auf → abgelehnt (heute: durchgewinkt → Prüfpunkt); Rechtsermittlung fehlerhaft → 403; Endpunkt mit leerem Rechte-Array → Forbid.
|
||||
- Tracelinks: StRS-003, StRS-009
|
||||
- Konsolidierung: ja (B-F008, B-F015, B-F017, E-F13, E-F14)
|
||||
- Übernahmewürdigkeit: hoch — sicherheitskritisch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-018 — Berechtigungs-Auditprotokoll ist lückenlos, konsistent und zugriffscontrolled**
|
||||
- ID: SyRS-018
|
||||
- Titel: Berechtigungs-Auditprotokoll ist lückenlos, konsistent und zugriffscontrolled
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Rechenschaft), Überwachbarkeit
|
||||
- Akteur: Prüfer / Revision, System, Administrator
|
||||
- Vorbedingung: Eine Rechte-, Gruppen- oder Zuordnungsänderung wird ausgeführt; ein Protokoll wird abgefragt
|
||||
- Fakt: B-F038
|
||||
- Aussage: Das System soll jede Änderung an Rechten, Gruppen und Zuordnungen mit Verursacher und Zeitpunkt im SichProtokoll erfassen (WriteBaseLog auf allen Änderungspfaden), den Schema-/Mapping-Widerspruch (NULL-erlaubte Protokollspalten vs. NOT-NULL-Mapping) auflösen und die Protokollauskunft GetAllAppRightLogs nur mit Berechtigung gewähren.
|
||||
- Ergebnis: Berechtigungsänderungen sind revisionsfest nachvollziehbar, und das Protokoll ist selbst geschützt.
|
||||
- Belege: [PRIMÄR] WriteBaseLog 762-781, Caller 783-858 (Audit aller Rechte-/Gruppenänderungen); [PRIMÄR] GetAllAppRightLogs 558-561 (ohne Prüfung); [PRIMÄR, Widerspruch] Schema 51226-51239 (NULL-allowed) vs. Mapping (NOT NULL).
|
||||
- Prüfidee: Recht hinzufügen und entfernen → zwei Protokollsätze mit Benutzer/Zeit; Schema-Integritätsprüfung gegen Mapping → keine NULL-Verstöße; GetAllAppRightLogs ohne Recht → abgelehnt.
|
||||
- Tracelinks: StRS-005
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-019 — Lizenzgate liegt vor jedem Datenbank- und Sitzungszugriff**
|
||||
- ID: SyRS-019
|
||||
- Titel: Lizenzgate liegt vor jedem Datenbank- und Sitzungszugriff
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Zuverlässigkeit, Sicherheit (Zugangskontrolle)
|
||||
- Akteur: Hersteller, System, Administrator
|
||||
- Vorbedingung: Der Host startet; ein Login soll eine Lizenz belegen
|
||||
- Fakt: E-F01, E-F02, B-F031, B-F033, G-F01
|
||||
- Aussage: Das System soll beim Start die Lizenz (Gültigkeit, Version) prüfen, bevor eine Datenbankverbindung aufgebaut und bevor eine Migration ausgeführt wird, und beim Login die gleichzeitige Ticketanzahl gegen die lizenzierte Platzanzahl unter einem Prozesslock prüfen.
|
||||
- Ergebnis: Eine un- oder überlizenzierte Installation nimmt keinen Datenzugriff auf; Concurrent Logins überschreiten die Lizenz nicht.
|
||||
- Belege: [PRIMÄR] CentronHost 102-108,361-365 (Lizenzprüfung vor DB-Verbindung); [PRIMÄR] LicenseManager 219-236 (LoadLicenses wirft bei ungültiger/überlizenzierter Version), 258-302 (Version+maximale gleichzeitige Tickets, Prozesslock); [PRIMÄR] Authenticator 109-155 (Login-Lizenzprüfung); [PRIMÄR] LicenseManager 219-236 + CentronHost 364,407 (Gate vor DB-Migration); [Faktenkatalog G] G-F01 (Modul nur bei Recht+Lizenz, Rechtefehler ⇒ keine Module; nach Belegprüfung keine eigene Code-Zeile zitierbar — Status: Indiz aus Faktenbasis).
|
||||
- Prüfidee: Start ohne/überlizenzierter Version → Abbruch, DB-Verbindung und Migration nachweislich nicht ausgeführt; Login Nr. N+1 bei N Plätzen → abgelehnt; gleichzeitige Logins um den letzten Platz → nur einer erhält ihn.
|
||||
- Tracelinks: StRS-011
|
||||
- Konsolidierung: ja (E-F01, E-F02, B-F031, B-F033, G-F01)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-020 — Versionsprüfung ohne hartcodierte Ausnahmen**
|
||||
- ID: SyRS-020
|
||||
- Titel: Versionsprüfung ohne hartcodierte Ausnahmen
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Wartbarkeit, Sicherheit (Integrität des Lizenzmodells)
|
||||
- Akteur: Hersteller, System
|
||||
- Vorbedingung: Eine Lizenz-/Versionsprüfung läuft, die Clientversion liegt im Bereich 9.3x (Delphi)
|
||||
- Fakt: E-F03, B-F032
|
||||
- Aussage: Das System soll die Lizenz-Versionsregeln ohne stillen Versionsaustausch anwenden; das Ersetzen der Delphi-9.3er Versionsnummer im Prüfpfad ist zu entfernen und jede gewollte Kompatibilitätsausnahme ist als konfigurierte, protokollierte Regel zu führen.
|
||||
- Ergebnis: Die Versionsprüfung entscheidet über die tatsächlich laufende Version; Ausnahmen sind auditiert.
|
||||
- Belege: [PRIMÄR] LicenseManager 304-330 (Versionsnummer wird vor der Prüfung ersetzt — Versionsprüfung ausgehebelt); deckungsgleich E-F03 (304-329).
|
||||
- Prüfidee: Anmeldung mit bewusst überlizenzierter Versionsnummer → Prüfergebnis basiert auf der echten Version; jede Ausnahmeentscheidung wirft einen Protokolleintrag.
|
||||
- Tracelinks: StRS-011
|
||||
- Konsolidierung: ja (B-F032, E-F03)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-021 — Migrations-/DB-Update-Skripte laufen unter Ausführungskontrolle und melden Fehler wahrheitsgemäß**
|
||||
- ID: SyRS-021
|
||||
- Titel: Migrations-/DB-Update-Skripte laufen unter Ausführungskontrolle und melden Fehler wahrheitsgemäß
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Zuverlässigkeit, Wartbarkeit
|
||||
- Akteur: System, Administrator, Wartungspersonal
|
||||
- Vorbedingung: Ein DB-Update oder Skriptlauf wird gestartet (auch vor einer Anmeldung)
|
||||
- Fakt: B-F011, B-F034, B-F035, B-F036
|
||||
- Aussage: Das System soll die Skriptausführung (ScriptEngineBL.ExecuteScripts, ResetDefaultRightGroups inkl. Raw-SQL-Bereinigung, reflexionsbasierte IScriptMethod-Registrierung) an einen definierten Systemkontext und eine Idempotenz der DBUpdate-Sätze (Status=2) binden und Skriptfehler der ignorierten Codes {10178,10210,10211,50000} als Fehler sichtbar lassen, statt sie als erledigt zu protokollieren; der Skriptbestand ist gegen unregistrierte Typen abzuriegeln.
|
||||
- Ergebnis: Migrationen sind wiederholbar, nachvollziehbar und verschweigen keine fehlgeschlagenen Schritte.
|
||||
- Belege: [PRIMÄR] ScriptEngineBL 40-127,204-227 (keine Rechteprüfung, läuft vor Login und mit null; DBUpdate-Idempotenz Status=2); [PRIMÄR] ScriptEngineBL 27,141-164 (Ignorieren der Codes {10178,10210,10211,50000} und Protokollierung als erledigt); [SEKUNDÄR] ScriptMethodPool 23-47 (Reflection-Registrierung); [PRIMÄR/K] AppRightsBL 563-640 (ResetDefaultRightGroups, Raw-SQL).
|
||||
- Prüfidee: Skript mit Fehlercode 10178 ausführen → Eintrag bleibt als Fehler sichtbar, DBUpdate nicht auf erledigt gesetzt; zweiter identischer Lauf → keine Doppelwirkung; Ausführung ohne Systemkontext → abgelehnt.
|
||||
- Tracelinks: StRS-050 (Vorgabe zu Wartungs-/Migrierungsmaßnahmen; nach ISO-Nahtstellenprüfung relinkt, zuvor als fachliche Lücke verbucht — die Eltern existierten bereits als StRS-049/050); ergänzender Kontext: StRS-011 (Lizenz-Gate vor Migration).
|
||||
- Konsolidierung: ja (B-F011, B-F034, B-F035, B-F036)
|
||||
- Übernahmewürdigkeit: hoch — Betriebs-/Integritätsrisiko
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-022 — Der Client weist abgelaufene Sitzungen und Versionsinkonsistenz vor der Arbeit aus**
|
||||
- ID: SyRS-022
|
||||
- Titel: Der Client weist abgelaufene Sitzungen und Versionsinkonsistenz vor der Arbeit aus
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Gebrauchstauglichkeit, Kompatibilität, Sicherheit
|
||||
- Akteur: Mitarbeiter, Administrator, Hersteller
|
||||
- Vorbedingung: Ein Client verbindet den Webservice; die Sitzung läuft
|
||||
- Fakt: G-F05, G-F06, G-F07, G-F08, G-F09
|
||||
- Aussage: Das System soll die Sitzung im Client über einen Heartbeat (5 min) überwachen und den Arbeitsplatz bei Fehler blockieren statt weiterarbeiten zu lassen, die Anmeldung nur bei übereinstimmender Client-/Webservice-Version (Major.Minor.Build) zulassen und die Zwei-Faktor-Einschränkung des AutoReconnect in jedem Build — nicht nur im Release — durchsetzen.
|
||||
- Ergebnis: Kein Mitarbeiter arbeitet unwissentlich mit abgelaufener Sitzung oder passfremder Version; 2FA gilt auch im Debug-Betrieb.
|
||||
- Belege: [PRIMÄR] ConnectionHeartbeatTimer 27-96 (5-min-Intervall, Blockade, Endlosschleife mit Dialog); [PRIMÄR] CentronWebServiceConnection 47,432-437,465-520 (AutoReconnect, Ticket-Refresh, rekursiver Aufruf); [PRIMÄR] LoginDialogViewModel 384-419 (Version Major.Minor.Build) und 521-523,565-583 [PRIMÄR, Widerspruch] (LoadAllowAutoReconnect nur #if !DEBUG; Fail-open bei Logikausfall); [Faktenkatalog G] G-F09 (Update nur Hinweis; WinExe/net10.0-windows nach Belegprüfung im Code bestätigt, „Update nur Hinweis" ohne zitierbare Stelle — Indiz).
|
||||
- Prüfidee: Heartbeat-Fehler simulieren → Arbeitsplatz blockiert in ≤ 5 min; Client mit abweichender Minor-Version → Login verweigert; 2FA-Benutzer im Debug-Build → AutoReconnect ebenfalls aus.
|
||||
- Tracelinks: StRS-047
|
||||
- Konsolidierung: ja (G-F05–G-F09)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-023 — Direkter Datenbankpfad und Webservicepfad erzwingen gleiche Absicherung**
|
||||
- ID: SyRS-023
|
||||
- Titel: Direkter Datenbankpfad und Webservicepfad erzwingen gleiche Absicherung
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit, Wartbarkeit
|
||||
- Akteur: Client, System
|
||||
- Vorbedingung: Der Client wählt den Verbindungstyp (SQL direkt oder Web-Service); ein Aufruf ohne ConnectionInfo läuft ein
|
||||
- Fakt: G-F03, G-F04, C-F18, C-F24
|
||||
- Aussage: Das System soll auf dem Direkt-Datenbankpfad (konventionsbasierte BL-Instanziierung) dieselben Authentifizierungs-, Berechtigungs- und Integritätsprüfungen durchsetzen wie auf dem REST-Pfad; Aufrufe ohne ConnectionInfo dürfen nicht unter Benutzer 0 mit leerem Ticket ausgeführt werden, und jede I*Logic muss in beiden Verbindungsvarianten existieren (Startprüfung statt Laufzeitfehler); der Selektions-/Löschpfad DeleteWithI3DReturn ist typkonsistent auszuführen.
|
||||
- Ergebnis: Ein Verbindungswechsel schwächt die Sicherheitskette nicht; Konventionslücken fallen beim Start auf.
|
||||
- Belege: [PRIMÄR] ClassContainer 49-90 + DataAccessOverBLInstaller 30-35 (Konvention „BL*Logic"/„WS*Logic"); [PRIMÄR] SetLoggedInUserInterceptor 11-27 (ohne ConnectionInfo: AppUserI3D=0, Ticket leer, Aufruf läuft durch); [PRIMÄR] GenericDAO 33-64 (kein automatischer Filter); [PRIMÄR+HYPOTHESE] GenericDAO 145-159 (DeleteWithI3DReturn selektiert I3Ds aus TEntity, DELETE gegen typeof(T) — Defektverdacht).
|
||||
- Prüfidee: Logikaufruf ohne ConnectionInfo → abgelehnt, nicht als Benutzer 0 ausgeführt; Start mit fehlender WS*Logic → Startfehler mit Namen; DeleteWithI3DReturn an Vererbungsfall → Löschung nur der selektierten Typ-Objekte.
|
||||
- Tracelinks: StRS-003, StRS-047
|
||||
- Konsolidierung: ja (G-F03, G-F04, C-F18, C-F24)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-024 — Alle Belegköpfe sind durch optimistische Sperre gegen silentes Überschreiben geschützt**
|
||||
- ID: SyRS-024
|
||||
- Titel: Alle Belegköpfe sind durch optimistische Sperre gegen silentes Überschreiben geschützt
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Datenintegrität (Zuverlässigkeit)
|
||||
- Akteur: System, zwei gleichzeitige Sachbearbeiter
|
||||
- Vorbedingung: Ein Belegkopf wird von zwei Sitzungen bearbeitet
|
||||
- Fakt: C-F01, C-F02, C-F03, C-F04, C-F05, C-F06
|
||||
- Aussage: Das System soll jeden Belegkopf-Speichervorgang über das bei jedem Speichern rotierende Versionstoken (ConcurrencyControlGuid in Spalte GUI3D aller Belegköpfe) prüfen; die Prüfung darf weder bei gespeichertem Token null übersprungen werden noch an der Typ/DB-Nullbarkeitsdiskrepanz (Interface Guid nicht-nullbar vs. Spalte NULL) scheitern, und die ungenutzten Sperrspalten (LockUserI3D/LockUniqueID) sind abzuschaffen oder zu aktivieren; ein Konflikt führt zu Warn-Log, Rollback und Fehlercode 10017.
|
||||
- Ergebnis: Gleichzeitige Bearbeitung desselben Belegs wird ausnahmslos erkannt; kein Belegkopf wird still überschrieben.
|
||||
- Belege: [PRIMÄR] SaveReceiptRepository 200-210,37-39 (Guid-Vergleich, ReceiptConcurrencyConflictException; bei gespeichertem null wird Prüfung übersprungen); [PRIMÄR] 212-216,41 (Token-Rotation); [PRIMÄR] SaveReceiptInvoiceRepository 387-395, RechKopfMaps 16, Schema 3349 (Token in GUI3D, kein NHibernate-Versioning); [PRIMÄR] SaveReceipt 135-155 + DefaultMessageCodes 38 (Warn-Log+Rollback+Fehlercode 10017); [SEKUNDÄR, Widerspruch] IReceiptBase 51 vs. Schema 3349 (Nullbarkeit); [SEKUNDÄR/K+HYPOTHESE] LockUserI3D/LockUniqueID nie genutzt.
|
||||
- Prüfidee: Zwei Sitzungen laden Beleg, Sitzung 2 speichert zuletzt → Konflikt 10017, Rollback, kein Datenverlust von Sitzung 1; Belegkopf mit GUI3D=NULL in zwei Sitzungen → zweiter Speichervorgang scheitert trotzdem.
|
||||
- Tracelinks: StRS-026, StRS-018
|
||||
- Konsolidierung: ja (C-F01–C-F06)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-025 — Änderungshistorie entsteht nur unter verifizierbarer Verursachung**
|
||||
- ID: SyRS-025
|
||||
- Titel: Änderungshistorie entsteht nur unter verifizierbarer Verursachung
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Rechenschaft), Datenintegrität
|
||||
- Akteur: System, Prüfer, Synchronisation
|
||||
- Vorbedingung: Ein Speichervorgang ändert überwachte Attribute; ein Angemeldeter ist oder ist nicht bekannt
|
||||
- Fakt: C-F07, C-F08, C-F09, C-F10
|
||||
- Aussage: Das System soll bei überwachten Eigenschaften das ChangeLog nur mit eindeutigem Verursacher schreiben; fehlt der angemeldete Benutzer (AsyncLocal-Default 0), ist der Update-Vorgang abzulehnen oder als expliziter, gekennzeichneter Systemvorgang zu protokollieren — nicht als lautlos verworfene Historie bei durchlaufendem Update; die Auditfelder (ErstelltDatum/Durch/Geaendert*) sind konsistent zu setzen, und der Sonderfall Synchronimporte (ErstelltDurch=null) ist als gekennzeichneter Systemverursacher zu führen.
|
||||
- Ergebnis: Jede Datenänderung ist einem Benutzer oder einem eindeutig markierten Systemvorgang zuordenbar.
|
||||
- Belege: [PRIMÄR] ChangeTrackingEventListener 52-99,127-141 (Schreibpfad) und 121-125 (ohne angemeldeten Benutzer wird ChangeLog verworfen, Update läuft durch); [PRIMÄR] LoggedInUserManager 9-14 (AsyncLocal, Default 0); [Faktenkatalog C] C-F10 (Auditfelder; CentronDelphi→ErstelltDurch=null — die im Faktenkatalog zitierte Stelle „Synchron 249-255" war in der Belegprüfung nicht auffindbar; Inhalt bleibt Indiz).
|
||||
- Prüfidee: Update ohne angemeldeten Benutzer → entweder abgelehnt oder ChangeLog mit Systemkennzeichen (heute: still verworfen → Prüfpunkt); Synchronimport → Satz mit erkennbarem Systemverursacher statt NULL.
|
||||
- Tracelinks: StRS-005
|
||||
- Konsolidierung: ja (C-F07, C-F08, C-F09, C-F10)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-026 — Identitätsbildende Felder sind datenbankseitig eindeutig gesichert**
|
||||
- ID: SyRS-026
|
||||
- Titel: Identitätsbildende Felder sind datenbankseitig eindeutig gesichert
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Datenintegrität
|
||||
- Akteur: System, Prüfer
|
||||
- Vorbedingung: Datensätze mit eindeutigen Ordnungsmerkmalen werden geschrieben
|
||||
- Fakt: C-F13, C-F14, C-F15, B-F019, B-F039, E-F30, E-F31
|
||||
- Aussage: Das System soll eindeutige Merkmale (Kontonummern und Artikelcode sind bereits unique) auf die noch ungesicherten Felder ausdehnen: Rechnungsnummer (RechKopf.Nummer), Benutzername (WebAccount und AppUser bislang nur anwendungsseitig), WebRights (ohne Primärschlüssel), ConnectionTicket-Technik, 2FA-Kombinationen (User,App,Machine,IP), WebAccounts/WebAccountsRights und PermanentLoginToken — jeweils durch Unique-/PK-Constraints, damit Parallel- und Direktzugriffe die Eindeutigkeit nicht umgehen.
|
||||
- Ergebnis: Doppelvergaben sind auch bei Nebenläufigkeit und Rohzugriff ausgeschlossen; Nummerierungspflichten (GoBD) werden datenbankgestützt.
|
||||
- Belege: [PRIMÄR] C-F13 (Accounts.Number, AccountCustomers/Suppliers.Number UNIQUE, Schema 56200,3784,3854); [PRIMÄR] C-F14 (ARTIK.Artikelcode UNIQUE, 57146-57148); [PRIMÄR/K-Negativ] C-F15 (RechKopf.Nummer NICHT unique, 3388-3391); [PRIMÄR] B-F019 (Benutzername nur BL-seitig eindeutig, Schema 54847 ohne Unique); [PRIMÄR] B-F039 (Sichtrus ohne PK, Sichmemb ohne FK, 51189-51278); [PRIMÄR] E-F30 (ConnectionTickets NOT NULL, Benutzerbezug optional); [PRIMÄR] E-F31 (WebAccounts/2FA ohne Unique auf (User,App,Machine,IP), WebRights ohne PK, PermanentLoginToken ohne Unique, 54842-54885, 53538-53550, 46526-46538).
|
||||
- Prüfidee: Zwei gleichzeitige Rechnungsspeicherläufe → keine Duplikatnummer (DB weist ab); parallel identischer Benutzername → eine Insert scheitert in der DB; 2FA-Tabelle: zweite Zeile gleicher (User,App,Machine,IP) → Constraint greift.
|
||||
- Tracelinks: StRS-024, StRS-010, StRS-006
|
||||
- Konsolidierung: ja (C-F13, C-F14, C-F15, B-F019, B-F039, E-F30, E-F31)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-027 — Zustands- und Betragsfelder der Belege sind datenbankseitig abgesichert**
|
||||
- ID: SyRS-027
|
||||
- Titel: Zustands- und Betragsfelder der Belege sind datenbankseitig abgesichert
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Datenintegrität
|
||||
- Akteur: System, Prüfer, Buchhaltung
|
||||
- Vorbedingung: Ein Belegkopf oder Zahlungseingang wird geschrieben (auch direkt in die DB)
|
||||
- Fakt: A-F31, D-F25, D-F26, D-F30, D-F72
|
||||
- Aussage: Das System soll die Integrität der Belegdaten nicht allein an die Anwendung binden: Zustands-, Fälligkeits-, Zahlungs- und Skontofelder sowie die Zahlungseingangssätze sollen Datendomainen (NOT NULL wo fachlich zwingend, CHECK-Bereiche, DEFAULT-Werte) tragen, sodass undefinierte Köpfe (Status/Fälligkeit NULLBAR ohne Constraint, Calculated*-Felder nur DEFAULT 0, RundungsDiff NULL ohne Durchsetzung, Zahlungseingang komplett NULLBAR, kein FK zwischen Zahlungseingang und RechKopf) datenbankseitig auffallen.
|
||||
- Ergebnis: Direkte oder fehlerhafte Schreibzugriffe erzeugen keine stillschweigend unvollständigen Belegdaten.
|
||||
- Belege: [PRIMÄR] A-F31 (RechKopf: Status/FaelligAm/ZahlKondID/Mahnstufe/Bezahlt NULLBAR ohne CHECK; Calculated* nur DEFAULT 0; Zahlungseingang alle NULLBAR, kein FK; Mahnlauf fast alles NULLBAR); [PRIMÄR] D-F25/D-F26 (Kopf-/Positionstabellen NOT NULL/NULLBAR gegeneinander); [PRIMÄR] D-F30 (nur wenige CHECK-Constraints, relevant nur Provisionsmenüs); [PRIMÄR] D-F72 (RundungsDiff NULL ohne Constraint).
|
||||
- Prüfidee: Direkter INSERT eines Belegkopfs ohne Status/Fälligkeit → DB oder Anwendungsdoppelprüfung weist nach definierter Regel ab; Zahlungseingang ohne RechKopfI3D-Bezug → FK-Verletzung sichtbar.
|
||||
- Tracelinks: StRS-022, StRS-017, StRS-018
|
||||
- Konsolidierung: ja (A-F31, D-F25, D-F26, D-F30, D-F72)
|
||||
- Übernahmewürdigkeit: mittel-hoch — Feldkatalog je Fachprozess noch abzustimmen
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-028 — Betragsberechnung folgt einer einzigen maßgeblichen Implementierung**
|
||||
- ID: SyRS-028
|
||||
- Titel: Betragsberechnung folgt einer einzigen maßgeblichen Implementierung
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Datenintegrität, Wartbarkeit
|
||||
- Akteur: System, Buchhaltung, Prüfer
|
||||
- Vorbedingung: Belegbeträge werden in Anwendung, Sichten oder Exporten berechnet
|
||||
- Fakt: A-F31, D-F31, D-F32, D-F33, D-F34, A-F09, D-F71
|
||||
- Aussage: Das System soll Positions- und Kopfsummen aus einer kanonischen Implementierung ableiten und die C#-Preislogik (ReceiptPriceHelper), die SQL-Funktionen (cfn_CalculateNetPrice/-TaxPrice/cfn_CalculateReceiptAmounts) und die Sichtneuberechnung (cvw_InvoiceHead statt der Calculated*-Felder) auf identische Regeln bringen — insbesondere Precision=-1, Schweizer 5-Rappen-Endrundung (dritte Implementierung in cvw_InvoiceHead/Stammdat 1113 und vierte im Gateway/Abacus-Pfad) und NoEarlyPaymentDiscountAllowed — oder die Zweitimplementierungen abschaffen; skalierte SQL-Rückgabetypen (impliziter Rundungsabriss) sind zu normieren.
|
||||
- Ergebnis: Dieselbe Position liefert in UI, Sicht und Export denselben Betrag; Rundungsdifferenzen werden nicht durch Berechnungsimbalanzen erzeugt.
|
||||
- Belege: [PRIMÄR] A-F31 (drei Berechnungsimplementierungen; SQL kennt weder precision=-1 noch CH-0.05-Rundung; skalierte DECIMAL-Typen); [PRIMÄR] D-F31–D-F33 (5 SQL-Funktionen, 12 CROSS-APPLY-Aufrufer); [PRIMÄR] D-F34 (cvw_InvoiceHead summiert neu, ignoriert Calculated*, 5-Cent-Korrektur über Stammdat 1113; Gateway GetRoundedAmount separat); [PRIMÄR] A-F09 (zweite CH-Rundung in ReceiptEsrBL, Parameterabweichung unbelegt); [PRIMÄR] D-F71 (±2,00-Ausgleich gilt nur für 10 von 16+ Interfaces).
|
||||
- Prüfidee: Identische Position (precision=-1, CH-Setting) durch C#-Pfad, cvw-Sicht und Export rechnen lassen → identische Beträge; Roundtrip-Test über 10.000 Zufallsposten ohne Abweichung > 0,005.
|
||||
- Tracelinks: StRS-014, StRS-034, StRS-033
|
||||
- Konsolidierung: ja (A-F31, A-F09, D-F31–D-F34, D-F71)
|
||||
- Übernahmewürdigkeit: hoch — abrechnungsrelevant, Widerspruch primär belegt
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-029 — Empfängeradresse bleibt gefrorener Belegsnapshot; Sprache wird über die Adresse geführt**
|
||||
- ID: SyRS-029
|
||||
- Titel: Empfängeradresse bleibt gefrorener Belegsnapshot; Sprache wird über die Adresse geführt
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität
|
||||
- Akteur: System, Buchhaltung
|
||||
- Vorbedingung: Ein Beleg wird angelegt; die Stammadresse ändert sich später
|
||||
- Fakt: C-F22, C-F11, C-F12, C-F21
|
||||
- Aussage: Das System soll die Empfängeradresse beim Beleganlegen als unveränderlichen Snapshot anlegen und anschließend nur die Kommunikationsattribute E-Mail/Telefon/Fax aktualisieren; die Korrespondenzsprache soll über die Adressbeziehung (Anschrif.Sprache) geführt und von dort auf Land und Währung abgebildet werden, statt Sprachattribute an Kunden-/Kreditoren-/Account-Köpfen zu duplizieren; die SEPA-Referenz (MandatorBankNumber) ist fachlich von einem Mandantenbegriff getrennt zu halten.
|
||||
- Ergebnis: Ausgelieferte Belege bleiben reproduzierbar; die Anrede-/Sprachenlogik hat genau eine Wahrheit.
|
||||
- Belege: [PRIMÄR] C-F22 (RecipientAddress „frozen snapshot create-once", SaveReceiptRepository 166-184: nur Email/Phone/Fax aktualisiert); [PRIMÄR] C-F11 (Schema 7439: Sprache nur an Adresse); [PRIMÄR] C-F12 (AddressMaps 56-57: Language→Country, Währung analog über Anschrif.Sprache); [KONTEXT] C-F21 (MandatorBankNumber = SEPA-Referenz, kein Mandant).
|
||||
- Prüfidee: Stammadresse nach Rechnungserstellung ändern → alter Beleg zeigt alte Anschrift, aber aktualisierte E-Mail; Sprache nur an Kunde (nicht Adresse) gepflegt → Sprachfindung läuft auf definierte Default-Regel.
|
||||
- Tracelinks: StRS-022, StRS-044
|
||||
- Konsolidierung: ja (C-F11, C-F12, C-F21, C-F22)
|
||||
- Übernahmewürdigkeit: mittel-hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-030 — Schlüssel und Fremdzugangsdaten sind zentral geschützt, nicht hartcodiert**
|
||||
- ID: SyRS-030
|
||||
- Titel: Schlüssel und Fremdzugangsdaten sind zentral geschützt, nicht hartcodiert
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Vertraulichkeit)
|
||||
- Akteur: System, Administrator, Angreifer (intern/extern)
|
||||
- Vorbedingung: Das System verwendet Verschlüsselungsschlüssel oder Zugangsdaten Dritter
|
||||
- Fakt: E-F23, E-F24, E-F25, F-F07, F-F08, F-F10, F-F17, F-F22, F-F29
|
||||
- Aussage: Das System soll Schlüssel und Dritt-Zugangsdaten in einem zentralen, zugriffs kontrollierten Geheimnisspeicher mit austauschbarem Master-Key verwalten; der hartcodierte AES-Schlüssel („lugE!35Djn", SHA512 mit statischem IV), der SecretKey-Klartext in der WebServiceConfig.xml ohne Verschlüsselungszweck, der akzeptierte Klartext-Fallback DatabaseConnectionStringPlain, hartcodierte Basic-Header und Testcredentials (GLS webapi/webapi, harte Test/Live-Umschaltung), SOAP-Template-Credentials (Egis ebc_testuser/test), die hartcodierte ITscope-AccountId und die GUID-Credentials von FinAPI (nur mit Lizenz OnlineBanking_FinApi) sind daraus zu ersetzen; die SQL-Verbindung soll ohne Fallback auf unverschlüsselte Zeichenketten auskommen.
|
||||
- Ergebnis: Schlüsselrotation ist möglich; Assembly-Dekompilierung und Konfigurationsdiebstahl liefern keine einsatzfähigen Zugänge.
|
||||
- Belege: [PRIMÄR] AESCryptoLogic 11-35,77-92 (hartcodierter Schlüssel, statisches IV für Proxy/Radius/SQL); [PRIMÄR] Serializer 95,215 (SecretKey Klartext, kein Encryption-Zweck); [PRIMÄR] Serializer 41-45,163 (verschlüsselte SQL-Verbindung mit Klartext-Fallback); [PRIMÄR] CentronGlsConsts 6,13-14 (Basic-Auth-Header hart, webapi/webapi); [PRIMÄR] CentronGlsLogic 98-130 (Test/Live-Umschaltung mit harten Testcredentials); [PRIMÄR] EgisApi 39-45 (harte Testzugänge); [PRIMÄR] ITscope 23-34,344-347 (AccountId fjku6Zi0l8Dq hart, Auth „AccountId§UserMail"); [PRIMÄR] OnlineBankingFinApiBL 33-49 (GUIDs hart im Code); [PRIMÄR] CentronShipcloudLogic 14-27 (API-Key nur Base64-Basic).
|
||||
- Prüfidee: Assembly/Konfiguration nach bekannten Konstanten absuchen → keine einsatzfähigen Credentials; MasterKey-Rotation → alle Geheimnisse ohne Codeeingriff erneuerbar; Klartext-Fallback deaktiviert → Verbindung mit unverschlüsseltem String scheitert.
|
||||
- Tracelinks: StRS-049 (Zugangskennungen unlesbar aufbewahren; nach ISO-Nahtstellenprüfung relinkt, zuvor als fachliche Lücke verbucht); ergänzender Kontext: StRS-011 (Lizenzbindung von Fremdsystemzugängen).
|
||||
- Konsolidierung: ja (E-F23, E-F24, E-F25, F-F07, F-F08, F-F10, F-F17, F-F22, F-F29)
|
||||
- Übernahmewürdigkeit: hoch — sicherheitskritisch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-031 — Telemetrie ist minimiert, offengelegt und abschaltbar**
|
||||
- ID: SyRS-031
|
||||
- Titel: Telemetrie ist minimiert, offengelegt und abschaltbar
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Vertraulichkeit), Datenschutzeignung
|
||||
- Akteur: Hersteller, Betreiberverantwortlicher, System
|
||||
- Vorbedingung: Die Installation sendet Nutzungsdaten an den Hersteller
|
||||
- Fakt: E-F26, E-F27, E-F28, E-F29
|
||||
- Aussage: Das System soll die Telemetrie (alle 15 min: CustomerNumber, DatabaseGuid, DatabaseName, UserID, UserKind, LicenseKind, Methodenname, HardwareID) auf den offengelegten Zweck begrenzen, dem Betreibenden einen wirksamen Opt-out bereitstellen, den HardwareIDAustausch nur über eine ausdrücklich aktivierte, dokumentierte Freigabe zulassen (Compile-Symbol ALLOW_HARDWARE_ID_FROM_ENV_VARS ist im Build aus) und die DatabaseGuid an den service_broker_guid binden; die ApiCall-Telemetrie (Interceptor Priority 35) ist im Offenlegungsverzeichnis zu führen.
|
||||
- Ergebnis: Der Betrieb kann datenschutzrechtlich begründen und technisch verhindern, was die Installation verlässt.
|
||||
- Belege: [PRIMÄR] TelemetryUploadService 33-43 und HttpTelemetryUploadClient 43-68,232-257 (Intervall, Datenarten, kein Opt-out bei 0 Suchtreffern); [PRIMÄR] DatabaseGuidProvider 17-49; [PRIMÄR] TelemetryHardwareIdProvider 9-28 (WindowsV1, „SQL-Mode" wird ersetzt); [PRIMÄR] Program.cs 21-23 (ENV-Austausch nur mit Compile-Symbol, nirgends definiert).
|
||||
- Prüfidee: Netzwerkbeobachtung über 30 min → genau die offengelegten Datenarten/Intervalle; Opt-out gesetzt → keine Sendungen; ENV-Variable ohne Build-Freigabe → HardwareID bleibt unverändert.
|
||||
- Tracelinks: StRS-048
|
||||
- Konsolidierung: ja (E-F26–E-F29)
|
||||
- Übernahmewürdigkeit: hoch (Abschaltbarkeit als Soll wie in StRS-048 offen gekennzeichnet)
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-032 — DSGVO-Löschfunktionen sind implementiert und berechtigtungs-/protokollgeprüft**
|
||||
- ID: SyRS-032
|
||||
- Titel: DSGVO-Löschfunktionen sind implementiert und berechtigtungs-/protokollgeprüft
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenschutzeignung, Sicherheit
|
||||
- Akteur: Beauftragter Kunde/Datenschutz, System, Prüfer
|
||||
- Vorbedingung: Ein Löschanspruch für Kunde, Lieferant oder Konto wird gestellt
|
||||
- Fakt: B-F041
|
||||
- Aussage: Das System soll die rechtspflichtigen Löschzugriffe des DSGVO-Moduls (DoDeleteCustomer, DoDeleteSupplier, DoDeleteAccount) funktionsfähig implementieren — die heutigen Stellen werfen NotImplementedException —, die Ausführung nur mit dem vorgesehenen Löschrecht gestatten und jeden Löschlauf mit Umfang und Verursacher protokollieren.
|
||||
- Ergebnis: Löschansprüche sind im System erfüllbar, nachweisbar und gegen Unbefugte geschützt.
|
||||
- Belege: [PRIMÄR] DataSecurityBL 34-37,379,789,856-858,937,998,1079 (rechtepflichtige Löschzugriffe; drei Kernmethoden NotImplementedException); der Befund begründet die Anforderung.
|
||||
- Prüfidee: Löschlauf auf Testdaten → Datensätze fachgerecht entfernt/gelöscht markiert, Protokollsatz vorhanden; Ausführung ohne Löschrecht → abgelehnt (kein Laufzeitfehler).
|
||||
- Tracelinks: — Fachliche Lücke: Die StRS enthält keine Lösch-/Aufbewahrungsanforderung; der nächste Bezug StRS-048 (Datenweitergabe offenlegen) berührt nur die Übermittlungsseite.
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-033 — Versanddienstleister: Produktiv/Test getrennt, Pflichtfelder laufzeitgeprüft, Zollmodell gefüllt**
|
||||
- ID: SyRS-033
|
||||
- Titel: Versanddienstleister: Produktiv/Test getrennt, Pflichtfelder laufzeitgeprüft, Zollmodell gefüllt
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Zuverlässigkeit der Integration, Sicherheit
|
||||
- Akteur: Versandmitarbeiter, Logistikdienstleister (GLS, Shipcloud — extern)
|
||||
- Vorbedingung: Eine Sendung wird über einen Dienstleister vorbereitet
|
||||
- Fakt: F-F06, F-F07, F-F08, F-F10, F-F11, F-F12, F-F13, F-F15
|
||||
- Aussage: Das System soll die Umstellung der Versanddienste auf Test- oder Produktivsystem über geschützte Konfiguration (nicht hartcodierte Testcredentials) steuern, die vom Dienstleister geforderten Pflichtfelder (u. a. To/Packages/Carrier bei Shipcloud, ShipperId/ShipmentDate/≤50 References/≤30 Parcels bei GLS) zur Laufzeit vor dem Versand prüfen, LabelUrl/Tracking aus dem UploadResult dem Bearbeiter bereitstellen und das vorgesehene Zolldeklarationsmodell in Ausfuhrfällen tatsächlich befüllen.
|
||||
- Ergebnis: Unvollständige Sendungen scheitern im Haus, nicht beim Dienstleister; Ausfuhren tragen vollständige Zolldaten.
|
||||
- Belege: [PRIMÄR] CentronGlsLogic 19-21,60-91,152-179 (lokale Validierung + API-Fehlerauswertung); [PRIMÄR] 98-130 (Test/Live mit harten Testcredentials); [PRIMÄR] CentronGlsConsts 6,13-14 (hartcodierter Basic-Header); [PRIMÄR] CentronShipcloudLogic 14-27 (Schlüssel nur Base64-Basic); [PRIMÄR] ShipmentRequest 14,34,40 (Compiletime-required, keine Laufzeitvalidierung) und 114-116 + ShipmentViewModel 234-293 [PRIMÄR, Widerspruch] (CustomsDeclaration wird nie gefüllt); [S] F-F13 (Shipcloud-Schlüssel clientseitig AES, BL speichert nur); [K] F-F15 (LabelUrl/Tracking im UploadResult).
|
||||
- Prüfidee: Shipcloud-Sendung ohne Carrier → Laufzeitvalidierung bricht ab (nicht erst der API-Aufruf); GLS-Umstellung auf Live ohne Konfigurationsrecht → abgelehnt; CH-Sendung mit Zollpflichtartikel → übermittelte CustomsDeclaration gefüllt (Prüfpunkt).
|
||||
- Tracelinks: StRS-037, StRS-038
|
||||
- Konsolidierung: ja (F-F06–F-F13, F-F15)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-034 — FinAPI-Zugriff: OAuth-Fluss, Token-Gate und PSD2-Consent-Durchsetzung**
|
||||
- ID: SyRS-034
|
||||
- Titel: FinAPI-Zugriff: OAuth-Fluss, Token-Gate und PSD2-Consent-Durchsetzung
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Sicherheit, rechtliche Konformität (PSD2)
|
||||
- Akteur: Buchhaltung, Bank/FinAPI (extern), System
|
||||
- Vorbedingung: Kontenumsätze werden über FinAPI abgerufen
|
||||
- Fakt: F-F26, F-F27, F-F28, F-F29, F-F30, F-F31
|
||||
- Aussage: Das System soll den FinAPI-Zugriff über die OAuth2-Flows (client_credentials und password → Bearer) mit Token-Ablaufprüfung als Gate vor jeder Kontomethode betreiben, die PSD2-Zustimmung (AisConsent/BankConsentStatus) vor dem Abruf auswerten und einen fehlenden oder widerrufenen Consent hart ablehnen, die widersprüchlichen Datumslogiken (rollierend 12 Monate vs. Filterdatum) auf eine Regel reduzieren und den gesetzten, aber ungenutzten DataDecryptionKey entweder verwenden oder entfernen.
|
||||
- Ergebnis: Kontozugriffe sind tokensicher, zustimmungsgedeckt und zeitlich eindeutig.
|
||||
- Belege: [PRIMÄR] RestClientBase 137-170 (client_credentials/password→Bearer); [PRIMÄR] JsonWebToken 15-18 + FinApiClient-Guards (Ablaufprüfung als Gate); [PRIMÄR, Widerspruch] 275-284 vs. 373-381 (zwei Datumslogiken); [PRIMÄR] F-F29 (Credentials nur mit Lizenz OnlineBanking_FinApi, GUIDs hart — siehe auch SyRS-030); [KONTEXT/Lücke] F-F30 (Consent wird nie ausgewertet), F-F31 (DataDecryptionKey ungenutzt).
|
||||
- Prüfidee: Consent widerrufen → Abruf scheitert vor dem Bankaufruf; Token abgelaufen → kein Methodenaufruf; identischer Filterzeitraum in beiden Pfaden → identischer Umsatzsatz.
|
||||
- Tracelinks: StRS-035
|
||||
- Konsolidierung: ja (F-F26–F-F31)
|
||||
- Übernahmewürdigkeit: hoch — PSD2-relevant
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-035 — docuFORM: OAuth2+PKCE, Konfiguration nur mit SETTINGS-Recht, Geheimnisse masterkey-pflichtig**
|
||||
- ID: SyRS-035
|
||||
- Titel: docuFORM: OAuth2+PKCE, Konfiguration nur mit SETTINGS-Recht, Geheimnisse masterkey-pflichtig
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Sicherheit
|
||||
- Akteur: Administrator, docuFORM (extern), System
|
||||
- Vorbedingung: docuFORM-Gerätezugriff wird konfiguriert oder genutzt
|
||||
- Fakt: F-F32, F-F33, F-F34, F-F35, F-F36, F-F37, F-F38
|
||||
- Aussage: Das System soll den docuFORM-Zugriff ausschließlich über den dokumentierten Funktionsumfang (RequestAuthorization/Token/GetAllDevices/GetDeviceCounters) im OAuth2+PKCE-Fluss (SHA256, Redirect 127.0.0.1, Refresh mit Scope server_read) betreiben, Lesen und Ändern der Einstellungen nur mit Recht SETTINGS gestatten, ClientId/Secret/RefreshToken AES-verschlüsselt und ohne Hotline-MasterKey nicht verarbeitbar halten und die Zählernummer DocuFormCounter datenbankseitig eindeutig sichern.
|
||||
- Ergebnis: Scangerätesteuerung ist gegen Konfigurationsmissbrauch und Geheimnisdiebstahl abgesichert; Zählwerte sind duplikatsicher.
|
||||
- Belege: [PRIMÄR] IDocuFormApiClient 11-20 (nur vier Operationen implementiert, Rest Swagger-Modelle); [PRIMÄR] OAuthHelper 11-39 (PKCE SHA256, Redirect); [PRIMÄR] DocuFormApiSettingsBL 31-32,58-59 (SETTINGS-Recht Lese/Schreib); [PRIMÄR] 48-51,82-94 (AES mit Hotline-MasterKey, Abbruch ohne Key); [K] F-F36 (Refresh-Flow, Scope server_read); [PRIMÄR] Schema 37235-37244 (DocuFormCounter NOT NULL ohne UNIQUE); [K] F-F38 (Zugänge in ApplicationSettings ValueText/ValueLargeText).
|
||||
- Prüfidee: PATCH der docuFORM-Einstellung ohne SETTINGS → abgelehnt; Settings ohne MasterKey laden → kontrollierter Abbruch; DocuFormCounter doppelt insertieren → DB-Constraint weist ab (Prüfpunkt).
|
||||
- Tracelinks: StRS-043
|
||||
- Konsolidierung: ja (F-F32–F-F38)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-036 — Elektronische Rechnungen im gültigen Formatprofil mit Vorab-Härtprüfungen**
|
||||
- ID: SyRS-036
|
||||
- Titel: Elektronische Rechnungen im gültigen Formatprofil mit Vorab-Härtprüfungen
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität, rechtliche Konformität
|
||||
- Akteur: Buchhaltung, öffentliche Auftraggeber (extern)
|
||||
- Vorbedingung: Eine Rechnung wird elektronisch (EbInterface) erzeugt
|
||||
- Fakt: F-F01, F-F02, F-F03, F-F04, F-F05, A-F19, H-F34, H-F35, H-F36
|
||||
- Aussage: Das System soll elektronische Rechnungen im dokumentierten Formatprofil erzeugen (ZUGFeRD 2.1 / XRechnung 3.0.1, Guideline-ID urn:...xrechnung_3.0, Typcodes 380 Rechnung/381 Gutschrift), vor der XML-Erzeugung die USt-IDs von Verkäufer, Käufer und Lieferanschrift hart verlangen, TotalGross=PayableAmount=NettoFC+SteuerFC abbilden (Rabattpositionen Article+CustomerDiscount), ExcludeTax zu „MwSt nicht ausweisbar"/ReverseCharge führen, Daten ab Jahr >1920 zulassen und die Summenkonsistenz mit Toleranz ±3,00 EUR sowie Titelpositionen mit Menge 1 anwenden.
|
||||
- Ergebnis: Elektronische Rechnungen werden wegen fehlender Pflichtangaben erst gar nicht erzeugt und beim Empfänger nicht formell zurückgewiesen.
|
||||
- Belege: [PRIMÄR] EbInterfaceLogic 24-28,303-341 (UStID-Zwang), 68-71 (TotalGross-Formel), 141-147 (Positionstypen), 165-179,207-221 (ExcludeTax/ReverseCharge/VATRate), 84-88,123-127 (Jahr>1920); [PRIMÄR] A-F19/InvoiceZugferdBL 64,1023-1059 (Toleranz 3,00, stille Korrektur darunter, Exportstopp darüber); [KONTEXT] H-F34–H-F36 (docs: Formatstand, Typcodes, Toleranzen/Vorzeichentausch/Titelpositionen).
|
||||
- Prüfidee: Erzeugung ohne Käufer-UStID → Abbruch vor XML; Bruttodifferenz 2,99 → Korrektur+Export, 3,01 → Exportstopp; Gutschrift trägt Typcode 381; Guideline-ID liest 3.0.
|
||||
- Tracelinks: StRS-033
|
||||
- Konsolidierung: ja (F-F01–F-F05, A-F19, H-F34–H-F36)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-037 — Drittsystem-Schnittstellen haben deterministische Fehler- und Mengengrenzen**
|
||||
- ID: SyRS-037
|
||||
- Titel: Drittsystem-Schnittstellen haben deterministische Fehler- und Mengengrenzen
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Zuverlässigkeit der externen Integration
|
||||
- Akteur: System, ITscope/Egis/CopApi/Icecat (extern), Sachbearbeiter
|
||||
- Vorbedingung: Artikel-/Partnerabfragen laufen über externe Schnittstellen
|
||||
- Fakt: F-F16, F-F19, F-F20, F-F21, F-F22, F-F23, F-F24, F-F25
|
||||
- Aussage: Das System soll externe Artikelabfragen mit festen, dokumentierten Grenzen betreiben (ITscope 50er-Batches, >50 Hersteller als definierter Fehler), Fehlerstatus deterministisch abbilden (ITscope 401 → Abbruch mit Fehler, 404 → leere Ergebnisliste), SOAP-Schnittstellen (Egis, CopApi) nur mit ausgefüllten, nicht-Platzhalter-Credentials ansprechen und SOAP-Fehler aus dem Transaktionskopf in eine Fachmeldung überführen; eine Codierungsvorgabe („Key 2 Stellen") ist als unbelegt zu klären.
|
||||
- Ergebnis: Fremdsystemausfälle erzeugen definierte, unterscheidbare Meldungen statt stiller Leerergebnisse oder ungeprüfter Requests.
|
||||
- Belege: [PRIMÄR] ITscope 161-186,226-227 (50er-Batches, ArgumentException), 316-341 (401→Exception, 404→leere Liste), 23-34 (AuthSchema); [PRIMÄR] EgisApi 23-30 (Suche nur mit echten Credentials), 185-200 (Transaktionskopfprüfung); [K] F-F20 (CopApi Credential-Einsetzung ohne Validierung), F-F21 (Icecat ISO-8859-1, URL hart); [K+HYPOTHESE] F-F25 („Key 2 Stellen" nicht gefunden).
|
||||
- Prüfidee: 51 Hersteller → klarer Fehler; ITscope-Test 401/404 → unterschiedliche, protokollierte Ergebnisse; Egis-Suche mit Platzhalter-Credentials → keine Netzanfrage.
|
||||
- Tracelinks: StRS-032 (Kontext: Qualität von Fremddaten in Beschaffungsprozessen) — Fachliche Lücke: keine StRS-Anforderung zur Artikel-/Produktdatenabfrage bei Dritten.
|
||||
- Konsolidierung: ja (F-F16, F-F19–F-F25)
|
||||
- Übernahmewürdigkeit: mittel-hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-038 — Uploadgrenzen werden an der Systemgrenze durchgesetzt**
|
||||
- ID: SyRS-038
|
||||
- Titel: Uploadgrenzen werden an der Systemgrenze durchgesetzt
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Zuverlässigkeit, Sicherheit (Missbrauchsschutz)
|
||||
- Akteur: Kunde (Signierlink), Supportmitarbeiter, System
|
||||
- Vorbedingung: Ein Dokument oder eine Unterschrift wird hochgeladen
|
||||
- Fakt: H-F05, H-F29, E-F34
|
||||
- Aussage: Das System soll Signatur-Uploads auf 20 MB und Ticket-/Dokumentanlagen auf 25 MB begrenzen und die Begrenzung zusätzlich zur Clientprüfung an der Servergrenze durchsetzen, da der Webserver aktuell Requests ohne Body-Limit akzeptiert.
|
||||
- Ergebnis: Speicher- und Überlastungsschutz greift auch gegen direktes Ansprechen der Endpunkte.
|
||||
- Belege: [PRIMÄR] DocumentSigningPage 763-775 (20 MB Signatur), DocumentsTab 372-388 (25 MB Anlage); [KONTEXT] E-F34 (HttpSys Request-Body-Limit null = unbegrenzt) — serverseitige Durchsetzung ist nicht belegt (HYP-Anteil), der Befund begründet die Forderung.
|
||||
- Prüfidee: Direkter POST 21 MB Signatur / 26 MB Anhang unter Umgehung des Clients → serverseitige Ablehnung mit Fachmeldung.
|
||||
- Tracelinks: StRS-043, StRS-040
|
||||
- Konsolidierung: ja (H-F05, H-F29, E-F34)
|
||||
- Übernahmewürdigkeit: hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-039 — Die Build-Pipeline hält Integrationstests aktiv und senkt Sicherheitsfunktionen nicht ab**
|
||||
- ID: SyRS-039
|
||||
- Titel: Die Build-Pipeline hält Integrationstests aktiv und senkt Sicherheitsfunktionen nicht ab
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Wartbarkeit, Zuverlässigkeit der Auslieferung
|
||||
- Akteur: Entwicklung, Betrieb (CI/CD)
|
||||
- Vorbedingung: Ein Pipeline-Lauf baut und prüft die Lösung
|
||||
- Fakt: H-F31, H-F32, H-F33
|
||||
- Aussage: Das System soll Integrationstests wieder als Bestandteil der Build-Pipeline ausführen (derzeit in azure/tests-pipeline.yml auskommentiert „temporarily disabled") und Regressionstests gegen eine Instanz fahren, deren Sicherheitsfunktionen (TwoFactorAuthEnabled, Ausführung von Services) eingeschaltet sind oder deren Abschaltung ausdrücklich als Testausnahme gekennzeichnet und getrennt berichtet ist; Nexus-/Regressionstests bleiben mit failTaskOnFailedTests als Gate.
|
||||
- Ergebnis: Auslieferungen werden gegen reale Sicherheitskonfigurationen geprüft; deaktivierte Prüfungen sind sichtbar.
|
||||
- Belege: [PRIMÄR] tests-pipeline.yml 130-146 (Integrationstests auskommentiert); [PRIMÄR/K] nexus-unit-tests.yaml 8-10 (separat, failTaskOnFailedTests); [KONTEXT] playwright-pipeline.yml 57-62 (Webservice mit ExecuteServices=false, TwoFactorAuthEnabled=false).
|
||||
- Prüfidee: Pipeline-Definition prüfen → Integrationstests aktiv; Playwright-Lauf gegen Instanz mit aktivem 2FA → Loginflow prüfbar; deaktivierte Funktionen nur mit Kennzeichnung.
|
||||
- Tracelinks: — Fachliche Lücke: Die StRS enthält keine Anforderung an Testbarkeit/Pipeline; nächster Bezug StRS-047 betrifft nur den laufenden Betrieb.
|
||||
- Konsolidierung: ja (H-F31–H-F33)
|
||||
- Übernahmewürdigkeit: mittel-hoch
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-040 — Webserver-Bindung und Anforderungsgröße sind explizit begrenzt**
|
||||
- ID: SyRS-040
|
||||
- Titel: Webserver-Bindung und Anforderungsgröße sind explizit begrenzt
|
||||
- Ebene: SyRS
|
||||
- Typ: Nicht-funktional
|
||||
- Qualitätsmerkmal: Sicherheit, Zuverlässigkeit
|
||||
- Akteur: Betrieb (Hosting), System
|
||||
- Vorbedingung: HttpSys als Host des Webservice
|
||||
- Fakt: E-F34
|
||||
- Aussage: Das System soll den Webserver nur auf konfigurierten Adressen/Interfaces binden (statt Wildcard *) und eine obere Grenze der Request-Body-Größe setzen, die zu den Fachgrenzen der Uploads (20/25 MB) passt.
|
||||
- Ergebnis: Angriffsfläche und Speicherbindung sind deploymentseitig begrenzt.
|
||||
- Belege: [HYPOTHESE] E-F34 (Klassifikation [K]: HttpSys bindet *, Body-Limit null) — keine durchsetzende Konfigurationsstelle mit Soll-Charakter gefunden; offene Frage: Ist die Wildcard-Bindung deploymentsseitig gewollt (Reverse-Proxy davor)?
|
||||
- Prüfidee: Deployment-Konfiguration → kein Binding * ohne dokumentierte Begründung; Request nahe Fachgrenze + Puffer → abgewiesen; Wildcard bewusst gesetzt → im Deployment-Handbuch vermerkt.
|
||||
- Tracelinks: — Fachliche Lücke: Die StRS führt keine Deployment-/Bindungsanforderung; StRS-010 (Mandatentrennung) berührt nur die Datenfolge.
|
||||
- Konsolidierung: nein
|
||||
- Übernahmewürdigkeit: mittel
|
||||
- Status: HYPOTHESE (Begründung: Befund nur [K], kein Beleg für gewolltes Soll; offene Frage: existiert ein Reverse-Proxy, der Bindung und Body-Größe steuert?)
|
||||
|
||||
---
|
||||
|
||||
## Ergänzung nach ISO-Nahtstellenprüfung (N-1)
|
||||
|
||||
Die folgenden 14 Anforderungen schließen die von der ISO-Nahtstellenprüfung gemeldeten Typ-A-Lücken (StRS ohne SyRS-Kind, Kette übersprang die Systemebene).
|
||||
|
||||
- **SyRS-041 — Kundenpreis folgt einer festen Vorrangfolge mit definiertem Gültigkeitsfenster**
|
||||
- ID: SyRS-041
|
||||
- Titel: Kundenpreis folgt einer festen Vorrangfolge mit definiertem Gültigkeitsfenster
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität (Abrechnungsrichtigkeit)
|
||||
- Akteur: Vertriebsmitarbeiter, System
|
||||
- Vorbedingung: Ein Kunde fragt einen Artikel in einem Beleg nach; der Verkaufspreis wird ermittelt
|
||||
- Fakt: A-F01, A-F02, A-F03
|
||||
- Aussage: Das System soll den Kundenpreis in der starren Vorrangfolge Vertrags-Sonderpreis vor Kunden-Sonderpreis vor Staffelpreis vor Kundenpreisliste ermitteln; ein Vertragssonderpreis schließt die Prüfung der nachrangigen Stufen aus. Sonderpreise sollen nur innerhalb ihres Gültigkeitsfensters (von/bis) ziehen, und innerhalb einer Stufe soll das spezifischere Merkmal (exakte Artikelreferenz vor Warengruppenkombination vor Primär-Warengruppe) entscheiden. Die Preislistenstufe des Kunden — bei Konzerngruppenzugehörigkeit die des Konzerngruppen-Kunden — soll auf genau eine von vier Preislistenstufen des Artikels abgebildet werden; invertiert gepflegte Vertragswerte (positiv = Aufschlag, negativ = Nachlass) sind mit dieser Semantik anzuwenden.
|
||||
- Ergebnis: Jeder Beleg weist den fachlich einzig bestimmbaren Preis aus; Mehrdeutigkeiten in der Preisfindung sind ausgeschlossen.
|
||||
- Belege: [PRIMÄR] A-F02 ReceiptItemPriceBL.cs 154-286 (Centron.BL) — Kaskade, Inversionskonvention, Ausnahme bei unbekannter Kombination; [PRIMÄR] A-F03 ReceiptItemPriceBL.cs 588-629 (Centron.BL) — Gültigkeitsfenster und Drei-Stufen-Spezifität; [PRIMÄR] A-F01 ReceiptItemPriceBL.cs 482-497 (Centron.BL) — vier Preislistenstufen, Konzerngruppenkunde; [HYPOTHESE] A-F01 (Lücke) — unbekannte Stufe > 3 fällt still auf Stufe 1 zurück; ob das Soll-Verhalten (Rückfall oder Fehler) definiert ist, ist nicht belegt.
|
||||
- Prüfidee: Artikel mit überlappenden Kunden- und Vertrags-Sonderpreisen pflegen → Vertrags-Sonderpreis gewinnt; Sonderpreis außerhalb des Fensters → findet keine Anwendung; Preislistenstufe 5 simulieren → definiertes, dokumentiertes Verhalten statt stiller Rückstufung (Prüfpunkt).
|
||||
- Tracelinks: StRS-012; Schwester: SyRS-028 (maßgebliche Betragsimplementierung)
|
||||
- Konsolidierung: ja (A-F01, A-F02, A-F03)
|
||||
- Übernahmewürdigkeit: hoch — abrechnungsrelevant, Kaskade lückenlos primär belegt
|
||||
- Status: belegt (HYPOTHESE-Anteil: Verhalten bei unbekannter Preislistenstufe; offene Frage: Fehler oder definierter Rückfall?)
|
||||
|
||||
- **SyRS-042 — Kundenrabatt wird als eigene, eindeutig gehaltene Belegposition geführt**
|
||||
- ID: SyRS-042
|
||||
- Titel: Kundenrabatt wird als eigene, eindeutig gehaltene Belegposition geführt
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität (Abrechnungsrichtigkeit), Nachvollziehbarkeit
|
||||
- Akteur: Vertriebsmitarbeiter, Kunde, System
|
||||
- Vorbedingung: Auf einen Beleg wird ein prozentualer Kundenrabatt angewendet
|
||||
- Fakt: A-F05
|
||||
- Aussage: Das System soll den Kundenrabatt als eigenständige, negative Belegposition mit Menge 1 ausweisen, nicht als Kopfvermerk; Berechnungsbasis soll das Belegnetto ohne den Rabattposten selbst sein, der Betrag auf zwei Nachkommastellen von null weg gerundet; der Positionstext soll aus der zentralen Vorlage mit Prozent- und Betragsplatzhaltern gebildet werden. Je Beleg soll höchstens ein Rabattposten bestehen bleiben, und bei Rabatt 0 soll kein Posten erzeugt bzw. ein bestehender entfernt werden.
|
||||
- Ergebnis: Der Kunde sieht auf der Rechnung, welcher Rabatt auf welcher Basis gewährt wurde; Doppel-Rabattposten sind ausgeschlossen.
|
||||
- Belege: [PRIMÄR] A-F05 ReceiptItemBL.cs 557-583, 484-505, 507-530 (Centron.BL) — Rundung 2 AwayFromZero, Basis ohne Rabattposten, Maximal-Ein-Posten-Regel, Null-Rabatt-Entfall; [PRIMÄR] A-F02 ReceiptItemPriceBL.cs 280-283 (Centron.BL) — Umrechnung fester Beträge in Prozent als Grundlage der Ausweislogik.
|
||||
- Prüfidee: Rabatt 5 % auf Beleg → eine negative Position mit auf 2 Stellen gerundetem Betrag, Basis ohne den Posten selbst; zwei Rabattposten erzwingen → nur einer bleibt; Rabatt auf 0 setzen → Posten verschwindet.
|
||||
- Tracelinks: StRS-013; Schwester: SyRS-028 (maßgebliche Betragsimplementierung)
|
||||
- Konsolidierung: ja (A-F05, Teilaspekt A-F02)
|
||||
- Übernahmewürdigkeit: hoch — Rechnungslegung und Kundenkommunikation
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-043 — Bezugspreis folgt der EK-Kaskade; EK/VK-Kopplung wird symmetrisch nachgeführt**
|
||||
- ID: SyRS-043
|
||||
- Titel: Bezugspreis folgt der EK-Kaskade; EK/VK-Kopplung wird symmetrisch nachgeführt
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität (Kalkulations- und Warenwertigkeit)
|
||||
- Akteur: Einkaufssachbearbeiter, System
|
||||
- Vorbedingung: Ein Artikel wird im Einkauf bewertet oder ein gekoppelter Artikelpreis geändert
|
||||
- Fakt: A-F04, A-F30
|
||||
- Aussage: Das System soll den Bezugspreis in der Vorrangfolge Sondervereinbarung (nur in aktiviertem Zustand), Lager-EK (nur wenn der das Lager führende Benutzer eigene EK-Führung nutzt und die Systemfreigabe gesetzt ist), Staffelpreis-EK (nur bei bekannter Menge) und sonst artikelgefahrener Bezugskostenpreis ermitteln und danach den EK-Reduktionsprozente-Faktor sowie den Währungsfaktor (1,0 bei Standardland oder fehlender Umrechnung) anwenden. Bei Artikeln mit EK/VK-Kopplung soll jede Änderung einer Seite die andere Seite invers nachführen, wobei ein Rabatt von 100 % nicht zum Verlust oder Fehler des Gegenwerts führen darf.
|
||||
- Ergebnis: Einkaufskalkulation und Warenbewertung verwenden einen nachvollziehbaren Bezugspreis; gekoppelte Artikelpreise bleiben widerspruchsfrei.
|
||||
- Belege: [PRIMÄR] A-F04 ReceiptItemPriceBL.cs 313-387, 739-756 (Centron.BL) — Kaskade, Freigabebedingungen, Multiplikationsreihenfolge; [PRIMÄR] A-F30 ReceiptItemPriceBL.cs 509-564 (Centron.BL) — wechselseitige Umrechnung bei Kopplung; [HYPOTHESE] A-F30 (Lücke) — Vollrabattfall divisorisch nicht abgesichert; das Soll-Verhalten ist nicht durchsetzend belegt.
|
||||
- Prüfidee: Artikel mit Sondervereinbarung und Staffelpreis → Sondervereinbarung gewinnt; Freigabe für Lager-EK aus → Lager-EK zieht nicht; gekoppelter Artikel, VK-Änderung → EK folgt der Inversformel; Rabatt 100 % → definierter Zustand statt Absturz (Prüfpunkt).
|
||||
- Tracelinks: StRS-015; Schwester: SyRS-028 (maßgebliche Betragsimplementierung)
|
||||
- Konsolidierung: ja (A-F04, A-F30)
|
||||
- Übernahmewürdigkeit: hoch — kalkulationsrelevant
|
||||
- Status: belegt (HYPOTHESE-Anteil: Vollrabattfall; offene Frage: wie ist der Gegenwert bei 100 % Rabatt fachlich zu bestimmen?)
|
||||
|
||||
- **SyRS-044 — Skontostufen werden aus der Zahlungsbedingung abgeleitet und offenlegungspflichtig korrekt abgebildet**
|
||||
- ID: SyRS-044
|
||||
- Titel: Skontostufen werden aus der Zahlungsbedingung abgeleitet und offenlegungspflichtig korrekt abgebildet
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität, rechtliche Konformität (E-Rechnungs-Formatvorgaben)
|
||||
- Akteur: Buchhaltung, Kunde, System
|
||||
- Vorbedingung: Ein Kunde zahlt innerhalb einer Skontofrist; ein Beleg wird exportiert
|
||||
- Fakt: A-F10, A-F11, D-F20, D-F21, D-F22, D-F23
|
||||
- Aussage: Das System soll aus der Zahlungsbedingung des Belegs maximal zwei prozentuale Skontostufen mit Tagen und Sätzen führen und eine allfällig dritte, nur tageweise gepflegte Stufe in den normierten Ausgaben (E-Rechnungs-Format und Buchungsimporte) als solche offenlegen, ohne ihr je einen Prozentsatz zu erfinden; artikelseitig als skontoausgeschlossen gekennzeichnete Beträge sollen je Steuersatz getrennt ausgewiesen und aus jeder Skontobemessung herausgehalten werden. Die Verminderung des Zahlbetrags bei Zahlung innerhalb der Skontofrist soll regelgebunden berechnet werden.
|
||||
- Ergebnis: Skontoangaben sind auf Rechnung, E-Rechnung und FiBu-Satz identisch und vollständig; skontoausgeschlossene Beträge werden nie mindernd behandelt.
|
||||
- Belege: [PRIMÄR] D-F20 Zahkond-Tabelldefinition 6846-6907 (SSMS_DB_SCHEMA.sql) — drei Stufen, Prozente nur zweistufig; [PRIMÄR] D-F21 cvw_BookKeepingReceipts 21772-21777 (Schema) — Stufe 3 nur Tage; [PRIMÄR] D-F22 BookKeepingExportSchillingAS400.cs 290-295 (Centron.Gateway) — drittes Prozent bewusst leer; [PRIMÄR] D-F23 BookKeepingExportAddison/DatevXmlOnline_2020/Europa3000 — nur zwei Stufen; [PRIMÄR] A-F10 AssetConditionBL.cs 101-136 (Centron.Administration, Format BR-DE-18) — zweistufiges Skontoformat; [PRIMÄR] A-F11 ReceiptPriceHelper 87-88 (Webservice.Core) — Separierung der nicht skontofähigen Beträge; [HYPOTHESE] A-F10 — keine durchsetzende Stelle für Skonto-Abzug, Fristprüfung oder Buchung gefunden.
|
||||
- Prüfidee: Zahlungsbedingung mit drei Stufen pflegen → E-Rechnung trägt genau die zwei Prozentsätze und die dritte Tagesangabe, kein erfundenes Prozent; Positionsmarke „nicht skontofähig“ → Betrag in separater Summe, nicht in Skontobemessung; Zahlung am Skontofälligkeitstag → Verhaltensnachweis der Betragsminderung (Prüfpunkt, heute unbelegt).
|
||||
- Tracelinks: StRS-016; Schwester: SyRS-036 (elektronische Rechnungen, Skontoformat)
|
||||
- Konsolidierung: ja (A-F10, A-F11, D-F20–D-F23)
|
||||
- Übernahmewürdigkeit: mittel-hoch — Modell und Offenlegung primär belegt, Betragswirkung offen
|
||||
- Status: HYPOTHESE (Begründung: die Betragsminderung des Zahlungsausgleichs ist nirgends als durchsetzend belegt, Belege tragen nur Format, Modell und Separierung; offene Frage: Wird Skonto nur auf dem Beleg ausgewiesen oder im Zahlungsausgleich berechnet?)
|
||||
|
||||
- **SyRS-045 — Mahnwesen eskaliert stufenweise, protokolliert jeden Lauf und respektiert Rechteschutz und Mahnstopp**
|
||||
- ID: SyRS-045
|
||||
- Titel: Mahnwesen eskaliert stufenweise, protokolliert jeden Lauf und respektiert Rechteschutz und Mahnstopp
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Rechenschaft), Datenintegrität (Forderungsbestand)
|
||||
- Akteur: Buchhaltung/Mahnwesen, Kunde, System
|
||||
- Vorbedingung: Ein Kunde hat fällige, unbezahlte Posten; ein Mahnlauf wird gestartet
|
||||
- Fakt: A-F24, G-F23
|
||||
- Aussage: Das System soll überfällige, aktive Forderungen je Mahnlauf genau eine Stufe eskalieren (None→1→2→3) und die dritte Stufe als Endzustand behandeln, wobei ein weiterer Lauf über die Endstufe hinaus eine definierte, verständliche Ablehnung liefern muss statt eines unkontrollierten Abbruchs. Jeder Lauf soll je Rechnung Alt-/Neustufe, Bearbeiter, Datum und eine fortlaufende, lückenlose Laufnummer protokollieren und die Stufenschreibung mit dem Protokollsatz in einer gemeinsamen, bei Fehler rückrollbaren Einheit durchführen. In die Auswahl sollen nur aktive Posten eintreten, deren Fälligkeit (mit konfigurierbarer Toleranz) erreicht ist und für die kein aktiver, im Zeitfenster liegender Mahnstopp besteht; die Bearbeitung, die Mahnstopp-Pflege und der Start im Client sollen an die jeweiligen Rechte gebunden sein, und ein Lauf ohne einzig gültiges Ziel soll verweigert werden.
|
||||
- Ergebnis: Mahnungen sind nachvollziehbar, wiederholbar und rechtlich gedeckt; ruhende Vereinbarungen bleiben unangetastet.
|
||||
- Belege: [PRIMÄR] A-F24 DunningRunBL 248-315 (Centron.BL) — Stufenautomatik, Endzustand-Wurfverhalten, Protokollsätze, Laufnummernvergabe, Transaktion; [PRIMÄR] A-F24 DunningBL 267-317, 170-182 (Centron.BL) — Fälligkeitstür, Toleranz, Mahnstopp-Fenster, Rechtsprüfung in jedem öffentlichen Pfad; [PRIMÄR] G-F23 DunningStopViewModel.cs 123 und DunningSummaryViewModel.cs 98-127 (Centron.WPF.UI) — Mahnstopp-Recht, Startverweigerung ohne gültigen Lauf; [PRIMÄR] A-F24 (Widerspruch, Zt. 215-235) — uneinheitliche Saldodefinition in denselben Auskünften (Klärungspunkt).
|
||||
- Prüfidee: Fälliger Posten mit Mahnstopp → kein Stufenfortschritt, Protokoll bleibt leer; Stopp entfernt → Stufe 1 mit Zeit-/Bearbeiterstempel und Laufnummer; ab Stufe 3 erneut starten → definierte Ablehnung (Prüfpunkt, heute Ausnahmewurf); Benutzer ohne Mahnstopp-Recht → Pflege verweigert.
|
||||
- Tracelinks: StRS-019; Schwester: SyRS-027 (Absicherung der Zustands-/Fälligkeitsfelder)
|
||||
- Konsolidierung: ja (A-F24, G-F23)
|
||||
- Übernahmewürdigkeit: hoch — Kernprozess Forderungsmanagement
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-046 — Kreditlimitüberschreitung verlangt die ausdrückliche, nachvollziehbare Entscheidung des Bearbeiters**
|
||||
- ID: SyRS-046
|
||||
- Titel: Kreditlimitüberschreitung verlangt die ausdrückliche, nachvollziehbare Entscheidung des Bearbeiters
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Entscheidungsrechenschaft), Zuverlässigkeit
|
||||
- Akteur: Vertriebsmitarbeiter, Buchhaltung, System
|
||||
- Vorbedingung: Ein kundengerichteter Beleg wird gespeichert; das Kundenlimit wird überschritten
|
||||
- Fakt: A-F18
|
||||
- Aussage: Das System soll vor dem Speichern kundengerichteter Belege den Limitverbrauch über alle limitrelevanten Belegarten hinweg gegen das gepflegte Kreditlimit prüfen — im vereinbarten Modus netto oder brutto, unter Herausrechnung des Werts der Vorversion desselben Belegs — und bei Überschreitung die Speicherung mit einer Warnung verknüpfen, die eine ausdrückliche Fortsetzungsentscheidung des Bearbeiters verlangt; eine zwangsweise Sperre soll nicht erfolgen. Interne Fortsetzungsschalter und Systemumgehungen dürfen die Warnung nur im definierten, dokumentierten Umfang stumm schalten, und die getroffene Fortsetzungsentscheidung soll nachvollziehbar werden.
|
||||
- Ergebnis: Kreditrisiko bleibt sichtbar und verantwortet; Ausnahmen bleiben möglich, sind aber entscheidungsgebunden.
|
||||
- Belege: [PRIMÄR] A-F18 ReceiptBL.cs 8636-8690 (Centron.BL) — Prüfbedingungen, Net/Gross-Modus, Vorversion-Herausrechnung, Fortsetzungsdialog und die beiden Übersteuer-Hebel; [PRIMÄR] A-F18 (Zusatzbefund, InvoiceSpecificLogic 355-365) — bereits bezahlte Rechnungen werden weiter gezählt (dokumentierter Soll-Verstoß, Klärungspunkt); [HYPOTHESE] A-F18 — eine Protokollierung der Fortsetzungsentscheidung ist nicht belegt.
|
||||
- Prüfidee: Kundenopen-Saldo knapp unter Limit, neuen Auftrag darüber anlegen → Warnung erscheint, ohne Bestätigung kein Speichern; mit Bestätigung gespeichert und die Entscheidung zuordenbar (Prüfpunkt); Limitberechnung gegen bezahlte Belege prüfen → Regelkonsistenz.
|
||||
- Tracelinks: StRS-020
|
||||
- Konsolidierung: ja (A-F18)
|
||||
- Übernahmewürdigkeit: hoch — klar dokumentiertes Regelverhalten, Rechnungsbezug
|
||||
- Status: belegt (HYPOTHESE-Anteil: Nachvollziehbarkeit der Fortsetzung; offene Frage: Ist eine Protokollpflicht für Fortsetzungsentscheidungen fachlich gewollt?)
|
||||
|
||||
- **SyRS-047 — Belegstatus wird aus dem Mengenrest gesteuert; der Angebotsabschluss folgt der dreistufigen Vereinbarung**
|
||||
- ID: SyRS-047
|
||||
- Titel: Belegstatus wird aus dem Mengenrest gesteuert; der Angebotsabschluss folgt der dreistufigen Vereinbarung
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität (Sachstandszuverlässigkeit)
|
||||
- Akteur: Sachbearbeiter, System
|
||||
- Vorbedingung: Positions-Mengen eines aktiven oder abgeschlossenen Belegs ändern sich
|
||||
- Fakt: A-F21, A-F22
|
||||
- Aussage: Das System soll den Belegstatus ausschließlich aus abschließenden drei Zuständen (offen, abgeschlossen, storniert) führen und ihn automatisch aus den Mengen ableiten: Abschluss, wenn jede Position einen Mengenrest von höchstens null (nach definierter Rundungsgenauigkeit) aufweist — wobei Rabatt-, Fracht-/Versicherungs- und definierte Ausgleichspositionen stets als erledigt gelten —, Rückfall auf offen, sobald ein Positivrest entsteht. Für Angebote soll die dreistufige Vereinbarung gelten (nie abschließen, Abschluss ab erster Teilübernahme, Abschluss erst bei voller Mengenabdeckung), und Rücköffnungen sollen für die Belegarten ausgeschlossen bleiben, für die sie per Regel deaktiviert ist; ein ungültiger Settingwert soll sichtbar behandelt statt nur im Debug-Kanal vermerkt werden.
|
||||
- Ergebnis: Der Bearbeiter sieht jederzeit den durch die Mengen gedeckten echten Sachstand; Status und Realität driften nicht auseinander.
|
||||
- Belege: [PRIMÄR] A-F21 ReceiptState.cs und AutomaticallyCloseReceiptHelperBL 36-101 (Centron.BL) — Zustandsmenge, automatische Steuerung, Sonderpositionen; [PRIMÄR] A-F22 OfferSpecificLogic 243-297 (Centron.BL) — dreistufiges Angebots-Setting, Rücköff-Ausnahmen, ungültiger Wert nur Debug-Log.
|
||||
- Prüfidee: Alle Positionen auf Rest 0 → Abschluss automatisch; Menge zurücknehmen → Rückfall auf offen; Angebot mit Setting 2 und Teilübernahme → abgeschlossen, mit Setting 1 → offen; Belegart mit Rücköff-Ausschluss prüfen → kein automatischer Rückfall.
|
||||
- Tracelinks: StRS-021; Schwester: SyRS-027 (Absicherung der Zustandsfelder)
|
||||
- Konsolidierung: ja (A-F21, A-F22)
|
||||
- Übernahmewürdigkeit: hoch — Prozessgerüst der Auftragsabwicklung
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-048 — Rechnungsstorno ist nur unter sechs Schutzbedingungen möglich und erhält den Ursprungsbeleg als neue Version**
|
||||
- ID: SyRS-048
|
||||
- Titel: Rechnungsstorno ist nur unter sechs Schutzbedingungen möglich und erhält den Ursprungsbeleg als neue Version
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität (Revisionssicherheit), Sicherheit (Berechtigung)
|
||||
- Akteur: Buchhaltung, Prüfer, System
|
||||
- Vorbedingung: Eine erteilte Rechnung soll storniert werden
|
||||
- Fakt: A-F14
|
||||
- Aussage: Das System soll die Stornierung einer Rechnung nur zulassen, wenn alle sechs Bedingungen gleichzeitig erfüllt sind: der Handelnde besitzt das Stornorecht, die Rechnung ist nicht bereits storniert, sie ist keine Barrechnung, sie wurde in keinen Folgebeleg weiterverarbeitet, sie ist nicht in die Buchhaltung exportiert, und als Vertragsrechnung ist sie die letzte Abrechnung des Vertrags. Die Ausführung soll den Ursprungsbeleg unverändert erhalten und stattdessen eine neue Belegversion mit Status „storniert“, Menge 0 an allen artikel- und rabattbeeinflussten Positionen und geräumten Seriennummern erzeugen, protokollieren und in einer eigenen, vom Hauptvorgang gelösten Einheit speichern; ein Ent-Storno darf nicht über einen unkontrollierten Pfad möglich sein.
|
||||
- Ergebnis: Korrekturen bleiben prüfbar; abgeschlossene Buchungskreise und Seriennummernnachweise werden nicht entwertet.
|
||||
- Belege: [PRIMÄR] A-F14 ReceiptInvoiceBL.cs 143-206 (Centron.BL) — alle sechs Abweisungsgründe, Versionsbildung mit Menge 0 und Barcode-Leerung, Logeintrag, eigene Transaktion; [HYPOTHESE] A-F14 (Lücke) — die Stornoausführung umgeht die Limitprüfung; ob das gewollt ist, ist nicht belegt.
|
||||
- Prüfidee: FiBu-exportierte Rechnung stornieren → Abweisung; berechtigte Stornierung → neue Version Menge 0, Original unverändert, Protokollsatz vorhanden; Benutzer ohne Stornorecht, Barrechnung, nicht-letzte Vertragsrechnung → jeweils Abweisung.
|
||||
- Tracelinks: StRS-023
|
||||
- Konsolidierung: ja (A-F14)
|
||||
- Übernahmewürdigkeit: hoch — abrechnungs- und revisionskritisch
|
||||
- Status: belegt (HYPOTHESE-Anteil: Limitprüfungs-Umgehung im Storno; offene Frage: gilt die Limitgrenze auch für Stornovorgänge?)
|
||||
|
||||
- **SyRS-049 — Seriennummern sind Druckvoraussetzung; Rücknahme und Reset sind rechts- und grundpflichtig**
|
||||
- ID: SyRS-049
|
||||
- Titel: Seriennummern sind Druckvoraussetzung; Rücknahme und Reset sind rechts- und grundpflichtig
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität (Gerätezuordnung), Sicherheit (Berechtigung)
|
||||
- Akteur: Sachbearbeiter, Service-Mitarbeiter, System
|
||||
- Vorbedingung: Ein seriennummerngeführter Artikel wird berechnet, zurückgenommen oder zurückgesetzt
|
||||
- Fakt: A-F16, G-F18, G-F27
|
||||
- Aussage: Das System soll die Erzeugung des Rechnungsreports seriennummerngeführter Artikel von vollständigen Seriennummern je Menge abhängig machen, wobei die Vorschau ausgenommen bleibt und eine Freigabe, die Seriennummern beim Speichern erlaubt, die Druckpflicht nicht berühren darf. Eine Rücknahme soll nur aus den Zuständen Lieferschein und Rechnung möglich sein und jeweils das Recht zum zugehörigen Folgebeleg (Abholschein bzw. Gutschrift) voraussetzen; ein Zurücksetzen des Seriennummernbestands soll nur mit dem besonderen Reset-Recht, einem Warnhinweis und einer zwingend anzugebenden Begründung ausführbar sein.
|
||||
- Ergebnis: Die Gerätezuordnung pro Kunde ist lückenlos nachweisbar; jede Änderung an Seriennummern ist berechtigt und begründet.
|
||||
- Belege: [PRIMÄR] A-F16 InvoiceSpecificLogic.cs 652-664, 242 (Centron.BL) — exakte Mengen-/Barcode-Prüfung vor Report außer Vorschau, Speichern-Freigabe per Setting; [PRIMÄR] G-F18 SerialNumberReclaimViewModel.cs 134-154 (Centron.WPF.UI) — Zustands- und Folgebeleg-Rechtspflicht der Rücknahme; [PRIMÄR] G-F27 ArticleSerialNumbersViewModel.cs 478-494 (Centron.WPF.UI) — Reset-Recht, Warnung, Pflichtgrund.
|
||||
- Prüfidee: Rechnung mit fehlender Seriennummer drucken → verweigert, Vorschau erlaubt; Rücknahme aus anderem Zustand bzw. ohne Folgebeleg-Recht → verweigert; Reset ohne Recht oder ohne Grundtext → verweigert.
|
||||
- Tracelinks: StRS-027
|
||||
- Konsolidierung: ja (A-F16, G-F18, G-F27)
|
||||
- Übernahmewürdigkeit: hoch — Garantie- und Gewährleistungsnachweis
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-050 — Lagerbewegungen werden nur als Differenz zur geführten Bestandfassung gebucht**
|
||||
- ID: SyRS-050
|
||||
- Titel: Lagerbewegungen werden nur als Differenz zur geführten Bestandfassung gebucht
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität (Bestandstreue)
|
||||
- Akteur: Lagerist, System
|
||||
- Vorbedingung: Ein Beleg mit Artikelpositionen wird gespeichert oder geändert
|
||||
- Fakt: A-F26
|
||||
- Aussage: Das System soll Lagerbestände nicht absolut, sondern nur in Höhe der Differenz zwischen der neu erfassten Positionsmenge und der in der Vorgängerfassung geführten Menge ändern, mit richtungsbestimmender Wirkung je Belegart (bestandsmindernde Belegarten senken, bestandsmehrende heben) und mit Spiegelung des Verbrauchs auf den Herkunftsbeleg. Eine Bewegung soll nur erfolgen, wenn die Lager-Artikel-Kombi geführt ist; fehlt sie, ist der Vorgang mit einer bestimmbaren Meldung zu quittieren, ohne dass ein Bestand unfreiwillig verändert wird, und jede ausgeführte Bewegung soll im Änderungsjournal erscheinen.
|
||||
- Ergebnis: Systembestand und physischer Bestand bleiben deckungsgleich; Mengenkorrekturen erzeugen keine Doppelbuchungen.
|
||||
- Belege: [PRIMÄR] A-F26 ReceiptArticleBookingBL.cs 328-429, 191-193, 698, 730-731 (Centron.BL) — Differenzbildung gegen Vorversion, Richtung, Herkunftsspiegelung, Verhalten bei fehlender Lager-Artikel-Kombi, Journalpflicht.
|
||||
- Prüfidee: Positionsanzahl 5→3 → Buchung nur −2; Artikel ohne Lagerführungseintrag → keine Buchung, Meldung vorhanden, Journal-/Protokolleintrag prüfbar; Herkunftsbeleg-Menge nach Spiegelung kontrollieren.
|
||||
- Tracelinks: StRS-028
|
||||
- Konsolidierung: ja (A-F26)
|
||||
- Übernahmewürdigkeit: hoch — Bestandszuverlässigkeit
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-051 — Negativbuchungen erfordern Sonderrecht oder Vier-Augen-Fremdanmeldung**
|
||||
- ID: SyRS-051
|
||||
- Titel: Negativbuchungen erfordern Sonderrecht oder Vier-Augen-Fremdanmeldung
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Sicherheit (Missbrauchsschutz, Vier-Augen-Prinzip)
|
||||
- Akteur: Lagerverantwortlicher, Kontrollberechtigter, System
|
||||
- Vorbedingung: Eine bestandsmindernde Buchung würde den geführten Bestand unterschreiten
|
||||
- Fakt: A-F25
|
||||
- Aussage: Das System soll eine Buchung, die den Bestand unter den geführten Wert oder unter die bisherige Buchungsmenge drückt, nur durchführen, wenn der Handelnde das Negativbuchungsrecht besitzt oder sich ein zweiter, im Besitz dieses Rechts befindlicher Benutzer zur Bestätigung anmeldet; der Speichervorgang ist anderenfalls abzubrechen, bevor ein Bestandsschreibzugriff erfolgt. Interne Umgehungs- und Rückrufsperren-Schalter dürfen diese Prüfung nicht aufheben, und die Rechtspflicht ist je Belegart nach einer definierten, dokumentierten Liste an- oder abschaltbar zu halten.
|
||||
- Ergebnis: Bestandsverringerungen unter den geführten Wert können nicht im Alleingang und nicht über Umgehungsschalter verschleiert werden.
|
||||
- Belege: [PRIMÄR] A-F25 ReceiptArticleBookingBL.cs 346-427 (Centron.BL) — Negativbuchungserkennung, Rechtsprüfung, Fremdlogin via Basis-Authentifizierungsobjekt, Abbruch vor dem Bestandsschreibzugriff, ausdrückliche Undurchlässigkeit des Umgehungsschalters, Belegarten-Flag; [PRIMÄR] A-F25 (Kontext derselben Stelle) — Rechtekette Bearbeiten/Filiale/Preis am selben Mechanismus.
|
||||
- Prüfidee: Benutzer ohne Recht bucht negativ ohne Fremdlogin → Abbruch, Bestand unverändert; mit gültiger Zweit-Anmeldung eines Berechtigten → Buchung möglich und beiden nachvollziehbar; Umgehungsschalter gesetzt → Prüfung bleibt wirksam.
|
||||
- Tracelinks: StRS-029; Schwester: SyRS-017 (fail-closed Zugriffsentscheidungen)
|
||||
- Konsolidierung: ja (A-F25)
|
||||
- Übernahmewürdigkeit: hoch — Missbrauchsschutz im Lager
|
||||
- Status: belegt
|
||||
|
||||
- **SyRS-052 — Vertragskontingente werden nach definierter Zählerregel verzehrt; Vertrags- und Zählerdaten sind speicherpflichtgeprüft**
|
||||
- ID: SyRS-052
|
||||
- Titel: Vertragskontingente werden nach definierter Zählerregel verzehrt; Vertrags- und Zählerdaten sind speicherpflichtgeprüft
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität (Abrechnungskonsistenz)
|
||||
- Akteur: Servicetechniker, Abrechnungsmitarbeiter, System
|
||||
- Vorbedingung: Eine Vertragsabrechnung oder Zählerbuchung wird erstellt; Kontingente werden verbraucht
|
||||
- Fakt: A-F28, G-F20
|
||||
- Aussage: Das System soll den Kontingentverzehr eines Vertrags in Stunden- oder Geldkontingenten nach einer einzigen, auf neun Nachkommastellen definiert gerundeten Regel mit dokumentierter Vergleichstoleranz berechnen, wobei bei unzureichendem Freikontingent nur der gedeckte Anteil als verzehrt gilt, und die Kontingentwerte selbst mit derselben Genauigkeit führen. Die Speicherung von Vertragsstammdaten soll vollständige Pflichtangaben (Vertragsart, Bericht, Abschluss, Laufzeit, Liefer-/Zahlungsbedingung, Intervalle, Abrechnungsbeginn, mindestens eine Position) verlangen, einen Zählerpreis über der definierten Obergrenze ablehnen und Buchungs- sowie Abrechnungsdaten, die vor dem letzten Buchungsdatum liegen, in allen Eingabewegen einheitlich verweigern.
|
||||
- Ergebnis: Dauerschuldabrechnungen verbrauchen Kontingente nachvollziehbar und werden nur mit konsistenten, zeitlich geordneten Daten ausgelöst.
|
||||
- Belege: [PRIMÄR] A-F28 ReceiptContractHelperBL.cs 179-196, 287, 774, 807 (Centron.BL) — 9-stellige Kontingentberechnung und Toleranzaufschlag; [PRIMÄR] G-F20 ContractsManagementViewModel.cs 1676-1737 und drei Datumsregelstellen (Centron.WPF.UI) — Pflichtfeldkatalog, Zählerpreisgrenze, Datum-nicht-vor-letzter-Buchung; [HYPOTHESE] G-F20 (Lücke) — die Zählerpreis-Obergrenze ist nirgends beziffert; derselbe Fakt (A-F28) benennt einen Präzedenz-Ausdruck, dessen Randfall (leere Menge) fachlich falsch rechnen kann.
|
||||
- Prüfidee: Freikontingent kleiner als Abrechnungsmenge → nur gedeckter Anteil verzehrt, Rest 0 mit 9-stelliger Nachkommastellenkontrolle; unvollständiger Vertrag speichern → verweigert; Buchungsdatum vor letztem Buchungsdatum in jedem der drei Erfassungspfade → einheitliche Verweigerung; Zählerpreis über Grenzwert → Ablehnung (Grenze zuvor zu klären).
|
||||
- Tracelinks: StRS-030
|
||||
- Konsolidierung: ja (A-F28, G-F20)
|
||||
- Übernahmewürdigkeit: hoch — Kern der wiederkehrenden Erlöserfassung
|
||||
- Status: belegt (HYPOTHESE-Anteil: Höhe der Zählerpreisgrenze; offene Frage: welcher Betragswert begrenzt den Zählerpreis fachlich?)
|
||||
|
||||
- **SyRS-053 — EDI-Bestellungen werden nur nach Partner-, Verfügbarkeits- und Summenkontrolle ausgelöst**
|
||||
- ID: SyRS-053
|
||||
- Titel: EDI-Bestellungen werden nur nach Partner-, Verfügbarkeits- und Summenkontrolle ausgelöst
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Zuverlässigkeit der Integration, Datenintegrität (Abrechnungsrisiko aus Fremddaten)
|
||||
- Akteur: Auftragssachbearbeiter, Geschäftspartner/Lieferant (EDI, extern), System
|
||||
- Vorbedingung: Eine Bestellung wird auf elektronischem Weg erzeugt bzw. übernommen
|
||||
- Fakt: A-F27
|
||||
- Aussage: Das System soll elektronische Bestellungen nur auslösen, wenn die Artikelverfügbarkeit geprüft ist, jeder Position ein Kreditorcode zugeordnet ist (fehlender Code harter Abbruch je Artikel) und ein bekannter Datentyp vorliegt (unbekannter Typ definierte Ablehnung); die übermittelte Auftragssumme soll nicht allein aus den selbst erzeugten Positionssummen gebildet, sondern vor dem Versand gegen die Summe des zugrunde liegenden Auftrags geprüft und bei Abweichung oberhalb einer zu definierenden Toleranz blockiert werden, damit Rundungs- und Übernahmefehler nicht unentdeckt in Fremdsysteme gelangen.
|
||||
- Ergebnis: Fremdsystembestellungen sind betragsmäßig gegen den Hauftrag verifiziert; fehlerhafte Daten erzeugen keine stillen Fehlaufträge.
|
||||
- Belege: [PRIMÄR] A-F27 Opentrans21OrderBL.cs 224-236 (Centron.BL) — Summen nur aus generierten Positionen, keine Gegenprüfung (Befund begründet das Soll); [PRIMÄR] A-F27 Opentrans21OrderBL.cs 199-222, AlltronOrderBL.cs 140/342, ConcertoOrderBL.cs 151, EDIDispatcherBL.cs 98/177 (Centron.BL) — Verfügbarkeits-, Kreditorcode- und Typ-Abbrüche durchsetzend; [HYPOTHESE] A-F27 (Lücke) — eine Toleranz für die Summengegenprüfung ist fachlich nicht festgelegt.
|
||||
- Prüfidee: Beleg mit absichtlicher Rundungsdifferenz zwischen Auftrags- und Positionssumme senden → Übermittlung blockiert bzw. beanstandet (Prüfpunkt, heute durchlässig); Artikel ohne Kreditorcode → kein EDI-Dokument; unbekannter Datentyp → dokumentierte Ablehnung.
|
||||
- Tracelinks: StRS-032; Schwester: SyRS-036 (Summenkontrolle im Ausgangsweg E-Rechnung)
|
||||
- Konsolidierung: ja (A-F27)
|
||||
- Übernahmewürdigkeit: hoch — Abrechnungsrisiko aus Fremddaten
|
||||
- Status: belegt (HYPOTHESE-Anteil: Höhe der Summentoleranz; offene Frage: welche Abweichung ist zwischen Auftrag und EDI-Beleg fachlich zulässig?)
|
||||
|
||||
- **SyRS-054 — SEPA-Kennzeichen und Mandatsreferenz werden aus Zahlkondition und Mandatsbestand abgeleitet und konsistent übergeben**
|
||||
- ID: SyRS-054
|
||||
- Titel: SEPA-Kennzeichen und Mandatsreferenz werden aus Zahlkondition und Mandatsbestand abgeleitet und konsistent übergeben
|
||||
- Ebene: SyRS
|
||||
- Typ: Funktional
|
||||
- Qualitätsmerkmal: Datenintegrität (Lastschriftprozess), rechtliche Konformität (SEPA-Mandat)
|
||||
- Akteur: Buchhaltung, Kunde, Zielsystem der Buchhaltung (extern), System
|
||||
- Vorbedingung: Ein Beleg mit Lastschrift-Verbindung wird in die Buchhaltung übergeben
|
||||
- Fakt: D-F44, D-F45, D-F46, D-F85
|
||||
- Aussage: Das System soll das SEPA-Kennzeichen eines Belegs ausschließlich aus der Zahlungsbedingung des Belegs ableiten und die Mandatsreferenz nur aus dem am Beleg hinterlegten, gültigen Zahlungsmittel des Kunden beziehen; für Belege ohne zugeordnetes Mandat soll eine eindeutig definierte Fallback-Regel (Standardverbindung oder bewusste Nicht-SEPA-Behandlung) gelten, statt offen zu bleiben. In den Buchhaltungsübergaben soll das Lastschrift-Zahlweisekennzeichen nur gesetzt werden, wenn Kennzeichen und Mandatsreferenz übereinstimmen, die Mandatsreferenz selbst nur in festgelegter Länge (35) und nur bei aktivierter Offenlegungseinstellung geschrieben werden, und eine Referenz auf ein nicht existentes Zahlungsmittel soll ausgeschlossen sein.
|
||||
- Ergebnis: Lastschriftdaten erreichen das Zielsystem nur mandatgedeckt; Rücklastschriften aus Mandatslücken werden vermieden.
|
||||
- Belege: [PRIMÄR] D-F44 cvw_BookKeepingReceipts 21808, 21810, 21851, 21857 (SSMS_DB_SCHEMA.sql) — SEPA-Aktivität aus Zahlkondition, Referenz aus Bankverbindung; [PRIMÄR] D-F45 BookKeepingExportDatevAscii.cs 781-792 (Centron.Gateway) — Zahlweise nur bei aktivem SEPA mit Mandat bzw. Lieferantenbezug; [PRIMÄR] D-F46 BookKeepingExportDatevAscii.cs 798-803 und Schema-Default 66859 (Centron.Gateway/Schema) — Länge 35, Einstellungsschalter; [PRIMÄR] D-F85 Schema 3361, 21857-21859 — Mandatsfeld NULLBAR, Referenz ohne Fremdschlüssel, Fallback auf Standardverbindung; [HYPOTHESE] D-F85 — ob fehlende Mandate die SEPA-Wirksamkeit hart sperren müssen, ist nirgends durchsetzend belegt.
|
||||
- Prüfidee: Kunde mit SEPA-Zahlkondition ohne Mandatsdatensatz → definiertes Verhalten (Fallback oder Blockade) statt Leerwert-Durchstich; Beleg mit gültigem Mandat → Zahlweise-Lastschrift und 35-stellige Referenz im Exportdatensatz, mit deaktivierter Offenlegungseinstellung ohne Referenz; Mandatsverweis auf gelöschte Bankverbindung → abgewiesen (Prüfpunkt).
|
||||
- Tracelinks: StRS-036; Schwester: SyRS-029 (Trennung des SEPA-Referenzbegriffs)
|
||||
- Konsolidierung: ja (D-F44–D-F46, D-F85)
|
||||
- Übernahmewürdigkeit: hoch — Lastschriftprozess, abrechnungsrelevant
|
||||
- Status: belegt (HYPOTHESE-Anteil: Sperrwirkung bei Mandatslücke; offene Frage: Ist der Fallback auf die Standardverbindung eine mandatierte oder eine zu blockierende Konstellation?)
|
||||
|
||||
*Orchestrator-Vermerk zur Selbstprüfung des syrs-autor (N-1-Nacharbeit): 14 Anforderungen SyRS-041–054 lückenlos; risikorelevant 11; Anforderungen ohne StRS-Tracelink 0. Offene Fakten (nicht erfunden): Skonto-Betragsminderung (A-F10), Fortsetzungsprotokoll Kreditlimit (A-F18), Soll bei unbekannter Preislistenstufe (A-F01), Gegenwert bei 100-%-Rabatt EK/VK (A-F30), Zählerpreis-Obergrenze (G-F20), EDI-Summentoleranz (A-F27), SEPA-Sperrwirkung bei Mandatslücke (D-F85), Storno-Limitprüfung (A-F14).*
|
||||
+130
@@ -0,0 +1,130 @@
|
||||
# Traceability
|
||||
|
||||
Quelle: Orchestrator (Versuch 02, Prompt 03-A). Bestand: StRS-001–050, SyRS-001–054, SwRS-001–078 (182 Anforderungen). Alle Tracelinks verweisen auf existierende IDs (0 Broken Links; bestätigt durch ISO-Nahtstellenprüfung O-2 und Abschluss-Konsistenzprüfung). Sechs Modulabdeckungs-Anforderungen (SwRS-060, 062, 065, 069, 071, 074) tragen bewusst keine Elternreferenz — dokumentiert in §5.
|
||||
|
||||
## 1. Rückwärtstrace SyRS → StRS (Eltern je SyRS)
|
||||
|
||||
| SyRS | StRS-Eltern | SyRS | StRS-Eltern | SyRS | StRS-Eltern |
|
||||
|---|---|---|---|---|---|
|
||||
| 001 | 006, 011 | 019 | 011 | 037 | 032 (nur Kontext) |
|
||||
| 002 | 006, 047 | 020 | 011 | 038 | 040, 043 |
|
||||
| 003 | 003, 047 | 021 | 050 (relinkt, B-2) | 039 | — (echte Lücke) |
|
||||
| 004 | 003, 011 | 022 | 047 | 040 | — (echte Lücke) |
|
||||
| 005 | 003, 008 | 023 | 003, 047 | 041 | 012 |
|
||||
| 006 | 006, 011 | 024 | 018, 026 | 042 | 013 |
|
||||
| 007 | — (echte Lücke) | 025 | 005 | 043 | 015 |
|
||||
| 008 | 047 | 026 | 006, 010, 024 | 044 | 016 |
|
||||
| 009 | 006 | 027 | 017, 018, 022 | 045 | 019 |
|
||||
| 010 | 007 | 028 | 014, 033, 034 | 046 | 020 |
|
||||
| 011 | 006 | 029 | 022, 044 | 047 | 021 |
|
||||
| 012 | 008 | 030 | 049 (relinkt, B-2) | 048 | 023 |
|
||||
| 013 | 001, 009 | 031 | 048 | 049 | 027 |
|
||||
| 014 | 001, 004, 005 | 032 | — (echte Lücke) | 050 | 028 |
|
||||
| 015 | 001 | 033 | 037, 038 | 051 | 029 |
|
||||
| 016 | 002, 010 | 034 | 035 | 052 | 030 |
|
||||
| 017 | 003, 009 | 035 | 043 | 053 | 032 |
|
||||
| 018 | 005 | 036 | 033 | 054 | 036 |
|
||||
|
||||
## 2. Vorwärtstrace StRS → Kinder (tragende SyRS / SwRS)
|
||||
|
||||
| StRS | SyRS-Kinder | SwRS-Kinder |
|
||||
|---|---|---|
|
||||
| 001 | 013, 014, 015 | 021, 033, 034, 035 |
|
||||
| 002 | 016 | 020 |
|
||||
| 003 | 003, 004, 005, 017, 023 | 037, 059 |
|
||||
| 004 | 014 | 036 |
|
||||
| 005 | 014, 018, 025 | 043, 046 |
|
||||
| 006 | 001, 002, 006, 009, 011, 026 | 038, 039, 073 |
|
||||
| 007 | 010 | — |
|
||||
| 008 | 005, 012 | 041 |
|
||||
| 009 | 013, 017 | 033, 037, 039, 076 |
|
||||
| 010 | 016, 026 | 048, 061 |
|
||||
| 011 | 001, 004, 006, 019, 020 | 054 |
|
||||
| 012 | 041 | 001 |
|
||||
| 013 | 042 | 002 |
|
||||
| 014 | 028 | 003, 004, 005 |
|
||||
| 015 | 043 | 006 |
|
||||
| 016 | 044 | 008, 009 |
|
||||
| 017 | 027 | 007 |
|
||||
| 018 | 024, 027 | 010 |
|
||||
| 019 | 045 | 012 |
|
||||
| 020 | 046 | 011 |
|
||||
| 021 | 047 | 016, 058 |
|
||||
| 022 | 027, 029 | 015, 049 |
|
||||
| 023 | 048 | 014 |
|
||||
| 024 | 026 | 013 |
|
||||
| 025 | — | — |
|
||||
| 026 | 024 | 045, 047 |
|
||||
| 027 | 049 | 017 |
|
||||
| 028 | 050 | 018, 066, 067 |
|
||||
| 029 | 051 | 019, 067 |
|
||||
| 030 | 052 | 022, 068 |
|
||||
| 031 | — | — |
|
||||
| 032 | 053 | 023, 064 |
|
||||
| 033 | 028, 036 | 031, 032 |
|
||||
| 034 | 028 | 024, 025, 026, 027, 028, 029, 057, 063 |
|
||||
| 035 | 034 | — |
|
||||
| 036 | 054 | 030 |
|
||||
| 037 | 033 | — |
|
||||
| 038 | 033 | — |
|
||||
| 039 | — | — |
|
||||
| 040 | 038 | — |
|
||||
| 041 | — | — |
|
||||
| 042 | — | — |
|
||||
| 043 | 035, 038 | — |
|
||||
| 044 | 029 | 049 |
|
||||
| 045 | — | — |
|
||||
| 046 | — | — |
|
||||
| 047 | 002, 003, 008, 022, 023 | — |
|
||||
| 048 | 031 | 055 |
|
||||
| 049 | 030 | 053 |
|
||||
| 050 | 021 | 042 |
|
||||
|
||||
**Vollwaisen (kein Kind irgendeiner Ebene, 7):** StRS-025, StRS-031, StRS-039, StRS-041, StRS-042, StRS-045, StRS-046 — im Analysebericht §6.2 als offene Rückwärtslücken geführt.
|
||||
|
||||
## 3. SwRS → Eltern (StRS und/oder SyRS)
|
||||
|
||||
| SwRS | Eltern | SwRS | Eltern | SwRS | Eltern |
|
||||
|---|---|---|---|---|---|
|
||||
| 001 | StRS-012 | 028 | StRS-034 | 055 | StRS-048, SyRS-031 |
|
||||
| 002 | StRS-013 | 029 | StRS-034 | 056 | SyRS-028 |
|
||||
| 003 | StRS-014, SyRS-028 | 030 | StRS-036 | 057 | StRS-034, SyRS-032 |
|
||||
| 004 | StRS-014 | 031 | StRS-033, SyRS-036 | 058 | StRS-021 |
|
||||
| 005 | StRS-014, SyRS-028 | 032 | StRS-033, SyRS-036 | 059 | StRS-003, SyRS-017 |
|
||||
| 006 | StRS-015 | 033 | StRS-001, StRS-009, SyRS-013 | 060 | — (§5) |
|
||||
| 007 | StRS-017 | 034 | StRS-001, SyRS-014, SyRS-016 | 061 | StRS-010 |
|
||||
| 008 | StRS-016 | 035 | StRS-001, SyRS-015 | 062 | — (§5) |
|
||||
| 009 | StRS-016 | 036 | StRS-004, SyRS-014 | 063 | StRS-034 |
|
||||
| 010 | StRS-018 | 037 | StRS-003, StRS-009, SyRS-017 | 064 | StRS-032 |
|
||||
| 011 | StRS-020 | 038 | StRS-006, SyRS-009, SyRS-011 | 065 | — (§5) |
|
||||
| 012 | StRS-019 | 039 | StRS-006, StRS-009 | 066 | StRS-028 |
|
||||
| 013 | StRS-024, SyRS-026 | 040 | SyRS-002, SyRS-003 | 067 | StRS-028, StRS-029, SyRS-017 |
|
||||
| 014 | StRS-023 | 041 | StRS-008, SyRS-012 | 068 | StRS-030, SyRS-052 |
|
||||
| 015 | StRS-022 | 042 | StRS-050, SyRS-021 | 069 | — (§5) |
|
||||
| 016 | StRS-021 | 043 | StRS-005, SyRS-018 | 070 | SyRS-030, SyRS-031 |
|
||||
| 017 | StRS-027 | 044 | SyRS-032 | 071 | — (§5) |
|
||||
| 018 | StRS-028 | 045 | StRS-026, SyRS-024 | 072 | SyRS-030 |
|
||||
| 019 | StRS-029 | 046 | StRS-005, SyRS-025 | 073 | StRS-006, SyRS-009 |
|
||||
| 020 | StRS-002, SyRS-016 | 047 | StRS-026, SyRS-024 | 074 | — (§5) |
|
||||
| 021 | StRS-001, SyRS-013 | 048 | StRS-010, SyRS-016, SyRS-023 | 075 | SyRS-004, SyRS-040 |
|
||||
| 022 | StRS-030 | 049 | StRS-022, StRS-044, SyRS-029 | 076 | StRS-009 |
|
||||
| 023 | StRS-032 | 050 | SyRS-004, SyRS-005 | 077 | SyRS-039 |
|
||||
| 024 | StRS-034 | 051 | SyRS-001, SyRS-006 | 078 | SyRS-039 |
|
||||
| 025 | StRS-034 | 052 | SyRS-007 | | |
|
||||
| 026 | StRS-034 | 053 | StRS-049, SyRS-008, SyRS-030 | | |
|
||||
| 027 | StRS-034 | 054 | StRS-011, SyRS-019, SyRS-020 | | |
|
||||
|
||||
72 von 78 SwRS tragen Elternreferenzen; die 6 ohne tragen den Vermerk „Modulabdeckungs-Anforderung“ (§5).
|
||||
|
||||
## 4. SyRS ohne SwRS-Kind
|
||||
|
||||
Ohne Software-Kind: SyRS-010, 022, 027, 033, 034, 035, 037, 038 (8). Von den N-1-Ergänzungen tragen SyRS-052 (→ SwRS-068) ein Kind; SyRS-041–051, 053, 054 haben formal kein eigenes SwRS-Kind, weil ihr Gegenstand auf der SwRS-Ebene bereits über die direkte StRS-Referenz abgedeckt ist (z. B. StRS-012 → SwRS-001 und → SyRS-041). SyRS-039 → SwRS-077/078 und SyRS-040 → SwRS-075 sind seit dem Batch-I-Nachschnitt gedeckt.
|
||||
|
||||
## 5. Anforderungen ohne Elternreferenz (bewusst, 6)
|
||||
|
||||
SwRS-060 (Calendar), SwRS-062 (ExternalTool), SwRS-065 (QM), SwRS-069 (ContractEvaluation2), SwRS-071 (WindowsService), SwRS-074 (Controls.Preview) — Modulabdeckungs-Anforderungen ohne tragenden Stakeholder-/System-Eltern; kein Elternbezug erfunden. Für SwRS-060 ist der fehlende Rechte-Guard bewusst nicht zum Soll erhoben (Fakten-Negativbefund), SwRS-069/062 betreffen Modulgrenzen ohne übergeordnete Forderung, SwRS-074 betrifft die Preview-Shell.
|
||||
|
||||
## 6. Offene Rückwärtstraces (kein erfundenes Ziel)
|
||||
|
||||
- SyRS-007, SyRS-032, SyRS-039, SyRS-040: keine tragende StRS (genuine Stakeholder-Lücke; Analysebericht §6.2).
|
||||
- SyRS-037: Verweis auf StRS-032 ausdrücklich nur als Kontext (Deckung verneint).
|
||||
+472
File diff suppressed because one or more lines are too long
+121
@@ -0,0 +1,121 @@
|
||||
# Messprotokoll – Iteration 9/qwen/qwen3.8-flash-next/custom/max
|
||||
|
||||
> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
|
||||
> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `02_Prompt.md`
|
||||
- **SHA-256 (Prompt):** `5946FC82C45E7A242A1F7367B56B008EE0F5C10373223D3500BCEF4716C76ECD`
|
||||
- **Startzeit:** 2026-09-04T08:08:00.9605253+02:00
|
||||
- **Endzeit:** 2026-09-04T10:10:29.8575054+02:00
|
||||
- **Dauer gesamt:** 02:02:24 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
|
||||
- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
|
||||
- **Codebasis-Commit:** `e2c3a0e8f81d005161dde733f7e4b08f581e3468` (vor dem Lauf dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Skill-Version:** 13.0.0
|
||||
- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider tensorx` (Adapter-Version 2.5.2)
|
||||
- **CLI-Version:** OpenCode 1.18.25
|
||||
- **Modell (angefordert):** `qwen/qwen3.8-flash-next`
|
||||
- **Modell (tatsaechlich):** `qwen/qwen3.8-flash-next`
|
||||
- **Kontrolle Modell:** bestanden
|
||||
- **Effort:** `max` angefordert, **wirksam** (`effort_applied: true`)
|
||||
- **Ablage:** `Iteration 9/qwen/qwen3.8-flash-next/custom/max/`
|
||||
- **Agentenmodus:** `custom`
|
||||
- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
|
||||
- **Sampling-Parameter:** nicht steuerbar
|
||||
- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
|
||||
- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
|
||||
- **Subagenten:** `spawned` = 30, `completed` = 30, `failed` = 0
|
||||
- **Rollen:** {"modulinventar": 2, "faktenermittler": 15, "strs-autor": 1, "syrs-autor": 2, "swrs-autor": 4, "belegpruefer": 3, "iso29148-orchestrator": 1, "konsistenzpruefer": 2}
|
||||
|
||||
## Validierungsstichprobe
|
||||
- **Stand:** entfaellt
|
||||
|
||||
## Verbrauch
|
||||
|
||||
| Messgroesse | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 894.458 |
|
||||
| Output-Tokens | 273.644 |
|
||||
| Reasoning-Tokens | 45.444 |
|
||||
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Agent-Turns | 108 |
|
||||
|
||||
**Tokens gesamt: 12.998.250.** Kosten `0` – lokaler Betrieb ().
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
|
||||
|
||||
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
|
||||
|
||||
### Verteilung über die Ebenen
|
||||
|
||||
| Ebene | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| StRS | 50 | 27,5 % |
|
||||
| SyRS | 54 | 29,7 % |
|
||||
| SwRS | 78 | 42,9 % |
|
||||
| **Gesamt** | **182** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| Funktional | 125 | 68,7 % |
|
||||
| Nicht-funktional | 57 | 31,3 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 388 |
|
||||
| davon `PRIMÄR` | 372 (95,9 %) |
|
||||
| davon `SEKUNDÄR` | 6 (1,5 %) |
|
||||
| davon `KONTEXT` | 10 (2,6 %) |
|
||||
| Belege je Anforderung (Median) | 2,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 176 (96,7 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| (sonstige Angabe) | 182 | 100,0 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 156 | 85,7 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 26 | 14,3 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 119 | 65,4 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 138 | 75,8 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **verletzt** – 6 ohne Beleg: StRS-007, SyRS-010, SyRS-015, SyRS-040, SwRS-007, SwRS-035 |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 2 von 69 ungedeckt: SyRS-015, SwRS-035 |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 182 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 182 von 182 mit Tracelinks (100,0 %) |
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** `is_error: true`, `subtype: error`, `exit_code: 1`, `timed_out: false`
|
||||
- **Session-ID:** `ses_f94f7c5daffeonoqMUCZtucmmC`
|
||||
- **Werkzeugaufrufe:** 149 – {"bash": 42, "task": 30, "write": 12, "read": 26, "edit": 39}
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 30
|
||||
- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
|
||||
- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
|
||||
- **Root unveraendert:** ja
|
||||
- **Fehlermeldungen:** ["OpenCode beendete sich mit Exitcode 1"]
|
||||
|
||||
## Anmerkungen/Auffaelligkeiten
|
||||
|
||||
*(von Hand zu ergaenzen)*
|
||||
+1689
File diff suppressed because one or more lines are too long
+5
@@ -0,0 +1,5 @@
|
||||
[2026-09-04T06:08:02.540046+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-04_080800_v13.0.0-d345\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-04_080800_v13.0.0-d345\Ergebnisse)
|
||||
[2026-09-04T06:08:02.800499+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=custom; Effort=max (uebergeben=True); Stall-Timeout=0s
|
||||
[2026-09-04T08:10:27.457012+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-04T08:10:29.683351+00:00] OpenCode export: Exporting session: ses_f94f7c5daffeonoqMUCZtucmmC
|
||||
[2026-09-04T08:10:29.816657+00:00] Ende: Exitcode=1; Status=error; Turns=108; Tokens=12998250; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-04_080800_v13.0.0-d345\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+3660
File diff suppressed because it is too large
Load Diff
+59
@@ -0,0 +1,59 @@
|
||||
## 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 | 50 | 27,5 % |
|
||||
| SyRS | 54 | 29,7 % |
|
||||
| SwRS | 78 | 42,9 % |
|
||||
| **Gesamt** | **182** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| Funktional | 125 | 68,7 % |
|
||||
| Nicht-funktional | 57 | 31,3 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 388 |
|
||||
| davon `PRIMÄR` | 372 (95,9 %) |
|
||||
| davon `SEKUNDÄR` | 6 (1,5 %) |
|
||||
| davon `KONTEXT` | 10 (2,6 %) |
|
||||
| Belege je Anforderung (Median) | 2,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 176 (96,7 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| (sonstige Angabe) | 182 | 100,0 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 156 | 85,7 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 26 | 14,3 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 119 | 65,4 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 138 | 75,8 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **verletzt** – 6 ohne Beleg: StRS-007, SyRS-010, SyRS-015, SyRS-040, SwRS-007, SwRS-035 |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 2 von 69 ungedeckt: SyRS-015, SwRS-035 |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 182 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 182 von 182 mit Tracelinks (100,0 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+218
@@ -0,0 +1,218 @@
|
||||
# Versuch 02 - Agentengestuetzt - Prompt-Version 03-A
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V2 Agentengestützt (rollenspezialisierte Agentendateien)
|
||||
- **Prompt-Version:** 03-A (Prompt-Version 03 aus Versuch 01, angepasst an verteilte Bearbeitung)
|
||||
- **Basis:** `Versuche/Versuch_01/03_Prompt.md`, SHA-256 `B8C8764F…C030F07`
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-31
|
||||
- **Vorgänger:** `01_Prompt.md` (Prompt-Version 02-A, SHA-256 `DCDC0E3F…B71BCF`), **kein Lauf durchgeführt**
|
||||
- **Änderungsgrund gegenüber `01_Prompt.md`:** Version 02-A leitete sich von Prompt-Version **02** ab. Versuch 1 ist inzwischen auf Prompt-Version **03** weitergelaufen (Iteration 8 und 9). Ein V2-Lauf gegen 02-A würde sich von den Vergleichsläufen in **zwei** Größen unterscheiden — Agentenrollen *und* Prompt-Version — und wäre als Wirkungsnachweis der Rollen unbrauchbar. Version 03-A setzt deshalb auf Prompt-Version 03 auf.
|
||||
|
||||
| Änderung gegenüber `Versuch_01/03_Prompt.md` | Grund |
|
||||
|---|---|
|
||||
| Neuer Abschnitt „Arbeitsteilung" | Prompt-Version 03 unterstellt stillschweigend **einen** Bearbeiter: Sie ordnet die Schritte zeitlich, vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck über das Ergebnis. Bei verteilter Bearbeitung ist nichts davon von selbst erfüllt — IDs kollidieren, die Reihenfolge läuft rollenweise auseinander, und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen. |
|
||||
| In der Arbeitsteilung: Ergebnisstruktur gilt unabhängig von der Aufteilung | Die 7-Datei-Regel aus Version 03 entstand an einem `solo`-Lauf (Kimi legte `SwRS-Ergaenzungen.md` an, 18 Anforderungen fielen aus der Auswertung). Bei verteilter Bearbeitung ist eine Datei je Bearbeiter der nächstliegende Fehler — die Regel wird dort ausdrücklich wiederholt. |
|
||||
| In der Arbeitsteilung: **Zuständigkeitsbindung** — eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, wird von ihm ausgeführt | V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Der Smoke-Test vom 26.08. zeigte, dass von acht beigestellten Rollen nur zwei genutzt wurden — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist **statisch** deklariert und gehasht und damit eine reproduzierbare Bedingung; sie ist nicht mit den laufzeitabhängigen Adapterinjektionen aus Iteration 8 zu verwechseln, die Lauf 34 unpoolbar machten. |
|
||||
| In der Arbeitsteilung: frei bleiben Zuschnitt, Anzahl, Reihenfolge und Tiefe | Gebunden wird **wer** eine Teilaufgabe ausführt, nicht **wie viel** davon getan wird. Zerlegungstiefe und Aufrufzahl bleiben Untersuchungsgegenstand wie in V1b. |
|
||||
| In der Arbeitsteilung: Dokumentationspflicht zur tatsächlichen Beauftragung | Die Bindung wirkt auf Promptebene und ist damit nicht technisch erzwungen, sondern selbst eine Messgröße. Nur wenn im Lauf festgehalten ist, wer was ausgeführt hat, ist die Einhaltung gegen `subagent_stats` und die Subagenten-Prompts prüfbar. |
|
||||
| Angehängte Tabellenzeilen und Schlussblockquote aus `03_Prompt.md` an ihren Platz gerückt | In `03_Prompt.md` stehen zwei Zeilen der Änderungstabelle **nach** dem Abschnitt „Abschluss" und die Tabelle im Metadatenblock ist leer. Da der Skill die **gesamte** Datei sendet (`_meta/combined_prompt.md`), gingen beide Fehlstellen in jeden Lauf der Iterationen 8 und 9 mit ein. |
|
||||
|
||||
**Der Prompt nennt keine Rolle namentlich.** Er formuliert die Bindung abstrakt; welche Rollen es gibt und wofür sie zuständig sind, stellt der Versuchsaufbau im Block Werkzeugkontext bei. Damit bleibt dieselbe Prompt-Datei auch für einen `solo`-Lauf ohne Rollen gültig — der fachliche Auftrag ist über V1, V2 und V3 identisch, und die Rollenbindung bleibt die einzige unabhängige Variable. Anzahl der Aufrufe, Zerlegungstiefe und Turn-Anzahl werden weiterhin **nicht** vorgegeben; sie bleiben Teil der Untersuchung.
|
||||
|
||||
Unverändert gegenüber Prompt-Version 03 bleiben: Auftrag, Scope, Vorgehensschritte 0 bis 6, Pflicht-Eigenschaften, Blockformat, Belegklassifikation, Prüfidee, Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur, Randbedingungen und Abschluss. Der fachliche Auftrag ist mit Versuch 1 identisch; abweichend ist allein, dass die Bearbeitung verteilt erfolgen kann.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge und Agentenrollen im jeweiligen Lauf
|
||||
> zur Verfügung stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau
|
||||
> beim Start bei.
|
||||
|
||||
---
|
||||
|
||||
## Prompt
|
||||
|
||||
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||
|
||||
### Auftrag
|
||||
|
||||
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||
|
||||
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||
|
||||
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||
|
||||
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||
|
||||
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### Vorgehen (statische Analyse, keine Ausführung)
|
||||
|
||||
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
|
||||
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
|
||||
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
|
||||
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
|
||||
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
|
||||
|
||||
### Pflicht-Eigenschaften jeder Anforderung
|
||||
|
||||
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
|
||||
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **Belegklassifikation:** Kennzeichne jeden Beleg als
|
||||
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
|
||||
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
|
||||
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
|
||||
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
|
||||
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
|
||||
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
|
||||
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||
|
||||
### Arbeitsteilung
|
||||
|
||||
Die Bearbeitung wird auf mehrere Bearbeiter verteilt. **Stellt der Versuchsaufbau für eine Teilaufgabe einen dafür vorgesehenen Bearbeiter bereit, ist diese Teilaufgabe von ihm auszuführen** — nicht von dir selbst und nicht von einem anderen. Welche Bearbeiter bereitstehen und wofür sie zuständig sind, nennt der Versuchsaufbau; diese Zuständigkeit ist Teil der Aufgabenstellung und keine Empfehlung. Stellt der Versuchsaufbau keine Bearbeiter bereit, bearbeitest du alles selbst und dieser Abschnitt ist ohne Wirkung.
|
||||
|
||||
- **Frei bleibt, wie du die Bearbeiter einsetzt.** Den Zuschnitt der Ausschnitte, die Anzahl der Aufträge je Bearbeiter, ihre Reihenfolge, die Tiefe und ob du nachfasst, entscheidest du. Gebunden ist allein, **wer** eine Teilaufgabe ausführt. Teilaufgaben, für die kein Bearbeiter vorgesehen ist — insbesondere der Zuschnitt, die Beauftragung, das Anlegen der Ergebnisdateien und die Übernahme der zurückgemeldeten Befunde —, führst du selbst aus.
|
||||
- **Zuständigkeit vor Bearbeitung klären.** Lege fest, wer welchen Ausschnitt bearbeitet, bevor die erste Anforderung entsteht. Ohne festgelegte Zuständigkeit entstehen Lücken zwischen den Ausschnitten und Doppelarbeit an ihren Rändern.
|
||||
- **ID-Bereiche vorab vergeben, überschneidungsfrei und lückenlos.** Jeder Bearbeiter erhält einen eigenen Nummernbereich je Ebene. Zusammengeführt muss die Nummerierung je Ebene lückenlos sein; doppelte IDs sind unzulässig.
|
||||
- **Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Bearbeiter.** Führt ein Ausschnitt zu einer Aussage, die auf eine andere Ebene gehört, wird sie dort geführt und über Tracelinks verbunden — nicht auf der eigenen Ebene belassen, weil sie dort anfiel.
|
||||
- **Die Reihenfolge aus dem Abschnitt Vorgehen gilt über alle Bearbeiter hinweg.** Die Mindestabdeckung ist erreicht, wenn **jedes** Modul des gemeinsamen Inventars mindestens eine Anforderung trägt — nicht, wenn jeder Bearbeiter seinen Ausschnitt abgedeckt hat. Erst danach beginnt die Vertiefung.
|
||||
- **Der Konsistenzcheck gilt dem zusammengeführten Ergebnis.** Eine Prüfung des eigenen Beitrags ersetzt ihn nicht. Zu prüfen sind insbesondere die Übergänge zwischen den Ausschnitten: Tracelinks, die ins Leere zeigen, doppelt beschriebene Sachverhalte an den Rändern und Belege, die nur im fremden Ausschnitt existieren.
|
||||
- **Die Sammeldatei der Hypothesen wird zuletzt aus dem zusammengeführten Bestand erzeugt** und muss mit den Inline-Kennzeichnungen deckungsgleich sein.
|
||||
- **Die Ergebnisstruktur ist von der Arbeitsteilung unabhängig.** Es entstehen genau die sieben vorgegebenen Dateien — keine Datei und kein Abschnitt je Bearbeiter.
|
||||
|
||||
**Dokumentationspflicht.** Halte im `Analysebericht.md` fest, welchen Bearbeiter du für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt hast. Hast du eine zugewiesene Teilaufgabe ausnahmsweise selbst ausgeführt, nenne sie ausdrücklich und begründe es. Diese Angabe ist Teil des Ergebnisses, nicht Beiwerk: Ohne sie ist nicht nachvollziehbar, wie die Spezifikation zustande kam, und eine unbemerkte Abweichung von der Zuständigkeit macht den Lauf unauswertbar.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
Akteur: <Rolle / System / Komponente>
|
||||
Vorbedingung: <Zustand vor Auslösen>
|
||||
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
|
||||
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
|
||||
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
|
||||
Belege:
|
||||
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
|
||||
- [SEKUNDÄR] <...> - Begründung: <...>
|
||||
- [KONTEXT] <...> - Begründung: <...>
|
||||
Prüfidee: <Akzeptanzkriterium oder Testidee>
|
||||
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
|
||||
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
|
||||
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
|
||||
Status: <belegt | HYPOTHESE>
|
||||
```
|
||||
|
||||
### Traceability
|
||||
|
||||
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
|
||||
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
|
||||
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
|
||||
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
|
||||
|
||||
### Nicht-funktionale Anforderungen
|
||||
|
||||
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
|
||||
|
||||
### Konsolidierungsbedarf
|
||||
|
||||
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
Ergebnisse/
|
||||
StRS.md
|
||||
SyRS.md
|
||||
SwRS.md
|
||||
Traceability.md (oder Traceability.csv)
|
||||
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
|
||||
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
|
||||
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
|
||||
|
||||
### Randbedingungen
|
||||
|
||||
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
|
||||
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
|
||||
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
|
||||
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
### Abschluss
|
||||
|
||||
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
|
||||
- Doppelte oder mehrfach vergebene IDs
|
||||
- Anforderungen ohne Beleg
|
||||
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen, das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis sowie
|
||||
die beigestellten Agentenrollen modulinventar, faktenermittler, strs-autor, syrs-autor,
|
||||
swrs-autor, belegpruefer, konsistenzpruefer und iso29148-orchestrator.
|
||||
Nicht verfügbar sind: externe Werkzeugserver, Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
Für die folgenden Teilaufgaben stehen vorgesehene Bearbeiter bereit. Führe diese
|
||||
Teilaufgaben durch den jeweils genannten Bearbeiter aus, nicht selbst:
|
||||
|
||||
| Teilaufgabe | Vorgesehener Bearbeiter |
|
||||
|---|---|
|
||||
| Modulinventar (Schritt 0) | modulinventar |
|
||||
| Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | faktenermittler |
|
||||
| Formulierung der StRS-Anforderungen | strs-autor |
|
||||
| Formulierung der SyRS-Anforderungen | syrs-autor |
|
||||
| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
|
||||
| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
|
||||
| Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | iso29148-orchestrator |
|
||||
| Konsistenzcheck des fertigen Anforderungssatzes (Abschnitt Abschluss) | konsistenzpruefer |
|
||||
|
||||
Zuschnitt, Anzahl der Aufträge je Bearbeiter, deren Reihenfolge und die Tiefe
|
||||
entscheidest du. Gebunden ist allein, wer eine Teilaufgabe ausführt. Die Bearbeiter
|
||||
lesen nur; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen
|
||||
bleiben deine Aufgabe.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\max\02_Lauf_2026-09-04_080800_v13.0.0-d345\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-09-04T10:10:29.8575054+02:00
|
||||
+648
@@ -0,0 +1,648 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"tensorx": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "TensorX",
|
||||
"options": {
|
||||
"baseURL": "https://api.tensorx.ai/v1"
|
||||
},
|
||||
"models": {
|
||||
"qwen/qwen3.8-flash-next": {
|
||||
"name": "Qwen 3.8 Flash Next",
|
||||
"limit": {
|
||||
"context": 262144,
|
||||
"output": 131072
|
||||
},
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"z-ai/glm-5.2": {
|
||||
"name": "GLM 5.2",
|
||||
"limit": {
|
||||
"context": 1048576,
|
||||
"output": 131072
|
||||
},
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"z-ai/glm-5.3-flash": {
|
||||
"name": "GLM 5.3 Flash",
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"moonshotai/kimi-k3": {
|
||||
"name": "Kimi K3",
|
||||
"limit": {
|
||||
"context": 1048576,
|
||||
"output": 131072
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/max/02_Lauf_2026-09-04_080800_v13.0.0-d345/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
},
|
||||
"task": {
|
||||
"*": "deny",
|
||||
"modulinventar": "allow",
|
||||
"faktenermittler": "allow",
|
||||
"strs-autor": "allow",
|
||||
"syrs-autor": "allow",
|
||||
"swrs-autor": "allow",
|
||||
"belegpruefer": "allow",
|
||||
"konsistenzpruefer": "allow",
|
||||
"iso29148-orchestrator": "allow"
|
||||
},
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"modulinventar": {
|
||||
"description": "Schritt 0: erstellt das vollständige Modulinventar als Bezugsgröße für die Abdeckung, mit Buchführung über zugeordnete und nicht zugeordnete Quelldateien. Erzeugt KEINE Anforderungen.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du erstellst das Modulinventar für ein Reverse-Requirements-Engineering-Vorhaben an einer Legacy-ERP-Suite. Du formulierst KEINE Anforderungen. Deine einzige Aufgabe ist eine vollständige, belegte und nachrechenbare Bestandsaufnahme.\n\n## Vorgehen\n\n1. Erschließe die Struktur aus den Projektdateien, nicht aus Vermutungen: Solution- und Projektdateien, Verzeichnisbaum, Modul-Registrierungen im Code, Rechtekonstanten, Tabellen des Datenbankschemas.\n2. Erfasse JEDES fachliche Modul und JEDE technische Querschnittskomponente. Ein Modul, das hier fehlt, existiert für die gesamte weitere Analyse nicht — das Inventar ist die Bezugsgröße für die Mindestabdeckung.\n3. Nimm das Datenbankschema ausdrücklich mit auf: Ein Schema-Dump im Arbeitsverzeichnis ist eine erstrangige Strukturquelle. Ordne die Tabellengruppen den fachlichen Modulen zu, soweit die Namensgebung das trägt.\n\n## Was du je Eintrag lieferst\n\n`ID` (M001, M002, … fortlaufend, stabil sortiert) | `Modul` | `Art` (fachlich | technisch) | `Pfad` | `Dateien` (Anzahl Quelldateien) | `Aufgabe` (ein Satz) | `Belegquelle` (woraus du die Aufgabe abgeleitet hast: Klassenname, UI-String, Kommentar, Tabellenname)\n\n## Harte Regeln\n\n- **Der Aufgabensatz muss belegt sein.** Leite ihn aus dem ab, was du tatsächlich gelesen hast. Ein Ordnername ist kein Beleg. Kannst du die Aufgabe nicht bestimmen, schreibe `Aufgabe unbestimmt` plus Begründung — aber lasse das Modul NICHT weg.\n- **Kein Zuschnitt nach Bequemlichkeit.** Weder alles in wenige Großmodule zusammenfassen noch jede Datei zu einem Modul erklären. Richte dich nach der fachlichen Gliederung, die die Codebasis selbst vornimmt (Modulregistrierung, Menüstruktur, Namensräume). Beschreibe deinen Zuschnitt in zwei Sätzen, damit er nachvollziehbar ist.\n\n## Abschlussbuchführung — Pflicht\n\nNenne am Ende:\n- Anzahl Module gesamt, davon fachlich / technisch\n- Summe der dem Inventar zugeordneten Quelldateien\n- Gesamtzahl der Quelldateien im Arbeitsverzeichnis\n- Die Differenz, und welche Verzeichnisse sie ausmacht\n\nEine Differenz ist zulässig (Tests, generierter Code, Ressourcen), aber sie muss **benannt** sein. Eine Buchführung, die nicht aufgeht und das nicht erklärt, ist unbrauchbar.\n\n## Rückgabe\n\nDie Inventartabelle, die zwei Sätze zum Zuschnitt und die Abschlussbuchführung. Keine Einleitung, keine Zusammenfassung, keine Empfehlungen.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"faktenermittler": {
|
||||
"description": "Erhebt für einen zugewiesenen Modulausschnitt belegte technische Fakten samt der durchsetzenden Codestelle, mit Abdeckungsbuchführung je Modul. Formuliert KEINE Anforderungen.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du erhebst Fakten aus einer Legacy-ERP-Codebasis. Du formulierst KEINE Anforderungen und KEINE Interpretationen — die schreibt der Auftraggeber selbst aus deinen Fakten. Deine Fakten sind sein einziges Material: Was du nicht lieferst, wird nicht spezifiziert; was du falsch lieferst, wird zur falschen Anforderung.\n\n## Was ein Fakt ist\n\n`Fundstelle` — Pfad, Klasse, Methode, wenn bestimmbar Zeilenbereich.\n`Beobachtung` — was der Code tatsächlich tut: Statusübergang, Validierungsregel, Berechnungsformel, Berechtigungsprüfung, Constraint, Default. Die tragende Bedingung wörtlich oder eng paraphrasiert.\n`Einstufung` — nach der Rubrik unten.\n`Modul` — die Inventar-ID, zu der der Fakt gehört.\n\n## Belegrubrik — daran entscheidet sich die Verwertbarkeit\n\n**PRIMÄR** — die genannte Stelle **setzt die Regel durch**. Man kann hingehen und die Bedingung lesen.\n> `AppRightsBL.cs, GetRightsFromCurrentUser(AppUser)` — iteriert `user.Groups` und sammelt `group.Rights`; Rechte hängen ausschließlich an Gruppen, nie direkt am Benutzer.\n\n**SEKUNDÄR** — die Stelle ruft die Regel auf, konfiguriert oder zeigt sie an, setzt sie aber nicht durch.\n> `AppUserGroupBL.cs` — verwaltet die Gruppenzuordnung, auf der die Rechteprüfung aufbaut.\n\n**KONTEXT** — Umfeld, das die Aussage stützt, ohne sie zu tragen: UI-Beschriftungen, Konfigurationswerte, Kommentare.\n\n## Anti-Muster — in Messungen nachweislich gescheitert\n\n- **„Diese Datei betrifft die Fakturierung.“** Ein Dateiverweis ist kein Fakt. Gefordert ist die Stelle **mit Bedingung**, etwa: `InvoiceService.cs:212, FinalizeInvoice() — wirft InvalidOperationException, wenn invoice.Status == InvoiceStatus.Paid`.\n- **„Ich öffne ein bis drei repräsentative Dateien.“** Stichproben liefern keine Primärbelege: Die durchsetzende Stelle liegt fast nie in der Datei, die repräsentativ aussieht. Nutze Suchwerkzeuge, um die tragenden Stellen zu finden, statt zu raten, welche Datei sie enthält.\n- **Aufwärtsrunden der Einstufung.** Was du nicht als durchsetzende Stelle gelesen hast, ist nicht `PRIMÄR`. Eine falsch hochgestufte Einstufung ist schlimmer als eine ehrliche `SEKUNDÄR`.\n\n## Pflichtquellen\n\n- **Das Datenbankschema.** Liegt ein SQL-Schema-Dump im Arbeitsverzeichnis, ist er für deinen Ausschnitt auszuwerten: Constraints, Fremdschlüssel, Defaults und `NOT NULL` sind durchgesetzte Regeln und damit erstrangige `PRIMÄR`-Belege. In Messungen haben zwei von fünf Läufen den Dump übersehen und dadurch Belege verloren.\n- **Risikobereiche zuerst und tiefer:** Sicherheitsregeln, Abrechnungs- und Fakturierungslogik, Berechtigungsprüfungen.\n\n## Was du ausdrücklich melden musst\n\n- **Nicht gefundene Durchsetzung.** Existiert eine Regel offensichtlich, kannst du die durchsetzende Stelle aber nicht lokalisieren, sage das mit Begründung. Diese Meldungen werden zu ausgewiesenen Hypothesen. Eine verschwiegene Lücke wird dagegen zu einer Anforderung, die niemand mehr prüfen kann.\n- **Widersprüche.** Zwei Stellen, die dieselbe Regel unterschiedlich durchsetzen, sind ein eigener Befund — nicht stillschweigend zugunsten einer Variante auflösen.\n- **Nicht implementiertes.** Methoden, die nur `throw new NotImplementedException(...)` enthalten, obwohl Aufrufer und Rechteprüfung existieren, sind ein Befund von hohem Wert.\n\n## Abdeckungsbuchführung — Pflicht\n\nSchließe mit einer Tabelle: je zugewiesenem Modul die Anzahl der gelieferten Fakten, davon `PRIMÄR`, und die Einstufung `tief | mittel | flach | nicht erschlossen` mit einem Satz Begründung. Module ohne einen einzigen Fakt sind namentlich zu nennen.\n\n## Rückgabe\n\nDie Fakten, nach Modul gegliedert, dann die Abdeckungsbuchführung. Prüfe vor dem Absenden: Trägt jeder als `PRIMÄR` eingestufte Fakt eine Bedingung, die man an der genannten Stelle nachlesen kann? Wenn nicht, stufe ihn herunter.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"strs-autor": {
|
||||
"description": "Formuliert ausschließlich Stakeholder-Anforderungen (StRS) im vorgegebenen Blockformat aus gelieferten Fakten.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du formulierst **ausschließlich Stakeholder-Anforderungen (StRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nStRS beschreibt die **fachliche Sicht**: Akteure, Geschäftsziele, Geschäftsregeln, fachliche Ergebnisse. Nicht, wie das System das technisch löst.\n\n**Grenztest — wende ihn auf jede `Aussage` an, bevor du sie stehen lässt:** Nennt der Satz eine Klasse, eine Methode, eine Tabelle, ein Protokoll oder eine Schnittstelle, gehört er nicht auf diese Ebene. Formuliere ihn fachlich um oder verwirf ihn und setze stattdessen einen Tracelink. Der Fakt darf und soll technisch sein — die `Aussage` nicht.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg.** Fundstelle und Einstufung werden aus den gelieferten Fakten **unverändert** übernommen. Du stufst nichts hoch und erfindest nichts. Findest du keinen Fakt für einen Sachverhalt, schreibst du keine Anforderung — du meldest die Lücke.\n- **`Fakt` und `Aussage` sind zwei verschiedene Dinge.** `Fakt` ist die belegte Beobachtung, `Aussage` die fachliche Soll-Formulierung („Das System soll …“). Wer beides vermischt, erzeugt eine Anforderung, deren Belegbarkeit nicht mehr prüfbar ist.\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen einen `PRIMÄR`-Beleg **oder** `[HYPOTHESE]` in `Status`. Einen dritten Weg gibt es nicht. Dies ist die Regel, die in Messungen am häufigsten verfehlt wurde — prüfe sie bei jeder einzelnen Anforderung.\n- **Belege mehrfach, wo die Faktenlage es hergibt.** Ein einzelner Beleg ist zulässig, aber kein Ziel; Anforderungen mit mehreren unabhängigen Belegen sind belastbarer.\n- **`Prüfidee` ist Pflicht** und muss ein prüfbares Kriterium nennen. „Wird getestet“ ist keine Prüfidee. „Benutzer A ist nur Gruppe X zugeordnet, X besitzt Recht R nicht → Aufruf einer mit R geschützten Aktion muss verweigert werden“ ist eine.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, niemals im Feld `Typ`.\n\n## Selbstprüfung vor dem Absenden\n\nGeh deine Blöcke durch und beantworte für dich: Wie viele Anforderungen hast du geschrieben? Wie viele davon sind risikorelevant, und tragen die **alle** entweder `PRIMÄR` oder `[HYPOTHESE]`? Gibt es doppelte IDs? Nenne diese drei Zahlen am Ende deiner Rückgabe.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die drei Zahlen der Selbstprüfung und eine Liste der Sachverhalte, für die dir Fakten fehlten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"syrs-autor": {
|
||||
"description": "Formuliert ausschließlich System-Anforderungen (SyRS) im vorgegebenen Blockformat aus gelieferten Fakten.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du formulierst **ausschließlich System-Anforderungen (SyRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nSyRS beschreibt das **beobachtbare Systemverhalten an den Systemgrenzen**: Schnittstellen, Statusmaschinen, Validierungen, Performance- und Sicherheitsverhalten.\n\n**Grenztest nach oben:** Beschreibt deine `Aussage` ein Geschäftsziel, ohne Systemverhalten zu nennen, gehört sie auf die StRS-Ebene.\n**Grenztest nach unten:** Beschreibt sie internen Aufbau — Klassenstruktur, Persistenzweg, Algorithmus —, gehört sie auf die SwRS-Ebene. Verwende Tracelinks statt die Grenze zu überschreiten.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg;** Fundstelle und Einstufung unverändert übernehmen, nichts hochstufen.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Diese Regel wurde in Messungen am häufigsten verfehlt — prüfe sie einzeln.\n- **Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung** in `Tracelinks`. Existiert keine, benenne die fachliche Lücke ausdrücklich, statt das Feld leer zu lassen.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, nicht im `Typ`. Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.\n- **`Prüfidee` ist Pflicht** und nennt ein prüfbares Kriterium.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl geschriebener Anforderungen; Anzahl risikorelevanter und ob **alle** gedeckt sind; Anzahl ohne StRS-Tracelink. Nenne die drei Zahlen am Ende.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"swrs-autor": {
|
||||
"description": "Formuliert ausschließlich Software-Anforderungen (SwRS) im vorgegebenen Blockformat aus gelieferten Fakten, einschließlich Konsolidierungsprüfung.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du formulierst **ausschließlich Software-Anforderungen (SwRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene\n\nSwRS beschreibt die **softwareinterne Sicht**: Komponenten, Datenmodelle, Persistenzregeln, interne Algorithmen und Berechnungsvorschriften, softwareinterne Constraints. Was an der Systemgrenze beobachtbar ist, gehört auf die SyRS-Ebene.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg;** nichts hochstufen, nichts erfinden.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Einzeln prüfen.\n- **Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung** in `Tracelinks`.\n- **Datenbank-Constraints sind erstrangige Belege.** Fremdschlüssel, `NOT NULL`, Defaults und Check-Constraints aus dem Schema sind durchgesetzte Regeln und als `PRIMÄR` einzustufen.\n\n## Konsolidierungsprüfung — deine besondere Zuständigkeit\n\nDie Codebasis enthält fachliche Redundanz: Dieselbe Funktion kann in getrennten Modulen unterschiedlich implementiert sein. Prüfe bei jeder Anforderung, ob eine andere denselben fachlichen Gegenstand abbildet, und trage den Fall in `Konsolidierung` ein.\n\n**Kalibrierung.** Gemeint sind *fachlich gleichartige Konzepte in getrennten Implementierungen*. Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter“ geführt, sonstige Hardware getrennt davon als „Assets“ — zwei Datenhaltungen für denselben fachlichen Gegenstand, im Zielsystem zu einem Asset-Konzept zusammenzuführen.\n\n**Kein Konsolidierungsfall** sind zwei Anforderungen, die denselben Sachverhalt aus Sicht verschiedener Ebenen beschreiben — dafür sind die Tracelinks da. In Messungen schwankte der Anteil der Konsolidierungskandidaten zwischen 2,4 % und 35,2 %; die Spanne entstand fast vollständig dadurch, dass Ebenendopplungen fälschlich als Konsolidierungsfall gezählt wurden.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl Anforderungen; Anzahl risikorelevanter und ob alle gedeckt; Anzahl Konsolidierungskandidaten und für zwei davon je ein Satz, warum es sich um getrennte Implementierungen desselben Gegenstands handelt.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"belegpruefer": {
|
||||
"description": "Prüft die ihm zugewiesenen Belege gegen die Codebasis, indem er die zitierte Stelle öffnet und die Einstufung nachrechnet. Der Umfang der Prüfung ist genau das, was ihm zugewiesen wird. Korrigiert nichts, meldet Abweichungen.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du prüfst Belege gegen die Codebasis. Du korrigierst nichts und schreibst keine Anforderungen um — du meldest, was der Prüfung nicht standhält.\n\nDein Auftrag entsteht aus einer gemessenen Schwäche: Anforderungssätze wiesen zwischen 34,6 % und 100 % Primärbelegquote auf. Eine hohe Quote ist wertlos, wenn die Einstufung nicht trägt. Du prüfst, ob sie trägt.\n\n## Vorgehen\n\nFür jeden dir zugewiesenen Beleg:\n\n1. **Öffne die zitierte Stelle.** Existiert die Datei? Die Klasse? Die Methode? Stimmt der Zeilenbereich ungefähr?\n2. **Lies die genannte Bedingung.** Steht dort tatsächlich, was der Beleg behauptet?\n3. **Prüfe die Einstufung.** Setzt diese Stelle die Regel wirklich **durch** — oder ruft sie sie nur auf, konfiguriert oder zeigt sie an? Letzteres ist `SEKUNDÄR`, nicht `PRIMÄR`.\n4. **Prüfe die Deckung.** Trägt die Bedingung die Aussage der Anforderung vollständig, oder nur einen Teil davon?\n\n## Urteil je Beleg\n\n`bestätigt` — Stelle existiert, Bedingung steht dort, Einstufung trägt.\n`einstufung zu hoch` — Stelle existiert, setzt die Regel aber nicht durch. Nenne die korrekte Einstufung.\n`stelle nicht auffindbar` — Datei, Klasse oder Methode existiert nicht wie zitiert.\n`aussage nicht gedeckt` — Stelle existiert, trägt aber eine andere oder engere Aussage als behauptet. Beschreibe die Abweichung.\n\n## Harte Regeln\n\n- **Urteile nur, was du gelesen hast.** Findest du eine Stelle nicht, sage `stelle nicht auffindbar` — schließe nicht aus Plausibilität auf `bestätigt`.\n- **Sei streng bei der Einstufung.** Im Zweifel `einstufung zu hoch`. Ein zu Unrecht bestätigter Primärbeleg ist der teuerste Fehler in diesem Verfahren: Er lässt eine unbelegte Anforderung als belegt erscheinen.\n- **Kürze nichts ab.** Kein „und weitere“. Jeder zugewiesene Beleg bekommt ein Urteil.\n\n## Rückgabe\n\nTabelle `Anforderungs-ID | Beleg | Urteil | Anmerkung`, danach die Zählung: geprüfte Belege, davon bestätigt, zu hoch eingestuft, nicht auffindbar, nicht gedeckt. Bei null Beanstandungen sage das ausdrücklich. Nenne außerdem, wie viele Belege dir zugewiesen wurden und — soweit dir mitgeteilt — auf welchen Gesamtbestand sie sich beziehen. Ohne diese Bezugsgröße ist deine Zählung nicht einzuordnen.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"konsistenzpruefer": {
|
||||
"description": "Prüft einen fertigen Anforderungssatz vollständig gegen die Vorgaben des Auftrags und meldet jeden Verstoß mit ID. Korrigiert nichts.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du prüfst einen fertigen Anforderungssatz gegen die Vorgaben des Auftrags. Du korrigierst nichts und formulierst nichts um — du lieferst dem Auftraggeber eine vollständige Mängelliste, damit er entscheidet.\n\nPrüfe **vollständig und mit absoluten Zahlen**, nicht beispielhaft. Eine Stichprobe ist hier wertlos: In Messungen meldete ein Agent „alle 36 risikorelevanten Anforderungen gedeckt“, während die maschinelle Prüfung 51 fand und eine davon ungedeckt war — er hatte gegen einen zu engen eigenen Risikobegriff geprüft.\n\n## Prüfpunkte\n\n1. **Belegpflicht** — Anforderungen ohne jeden Beleg. Jede ID nennen.\n2. **Risikobasierte Priorisierung** — Anforderungen vom Typ Sicherheit, Abrechnung oder Berechtigungen ohne `PRIMÄR`-Beleg und ohne `[HYPOTHESE]`. **Gehe hier Anforderung für Anforderung vor, nicht überschlägig.** Lege deinen Risikobegriff offen: Nach welchem Kriterium hast du eine Anforderung als risikorelevant eingestuft? Ein enger Begriff lässt Verstöße unentdeckt.\n3. **Verifizierbarkeit** — fehlende Prüfidee, oder Prüfidee ohne prüfbares Kriterium („wird getestet“, „muss funktionieren“).\n4. **Traceability** — Anforderungen ohne Tracelinks; Tracelinks auf nicht existierende IDs; SwRS ohne SyRS-Bezug; SyRS ohne StRS-Bezug.\n5. **Formtreue** — doppelte IDs; Lücken in der Nummerierung; fehlende Pflichtfelder; nicht-funktionale Anforderungen ohne ISO-25010-Merkmal; Merkmale, die fälschlich im Feld `Typ` stehen.\n6. **Ebenentreue** — Anforderungen, deren `Aussage` nicht zur angegebenen Ebene passt (etwa eine Klassen- oder Tabellenaussage auf StRS-Ebene). Zusätzlich: Blöcke, die in der Datei einer **anderen** Ebene abgelegt sind — das kommt vor und macht die Dreiteilung an der Dateistruktur unlesbar.\n7. **Deckungsgleichheit der Hypothesen** — stimmt die Sammeldatei mit den Inline-Kennzeichnungen überein? Nenne Differenzen in beide Richtungen.\n8. **Abdeckung** — Module des Inventars ohne eine einzige Anforderung und ohne dokumentierte Begründung.\n9. **Ergebnisstruktur** — Es dürfen ausschließlich die sieben vorgegebenen Dateien existieren (`StRS.md`, `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`, `Analysebericht.md`). Nenne jede zusätzliche Datei und die Zahl der darin liegenden Anforderungen — sie werden von der Auswertung nicht erfasst.\n10. **Erkundungstiefe** — Anteil der Module, die als `nicht analysiert` geführt werden, in absoluten Zahlen und in Prozent. Über 10 % ist ein Hinweis auf unvollständige Erkundung.\n11. **Zuständigkeitsbindung** — Ist im `Analysebericht.md` festgehalten, welcher Bearbeiter für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt wurde? Nenne jede Teilaufgabe, für die ein Bearbeiter vorgesehen war und die laut Bericht dennoch selbst ausgeführt wurde, sowie jede Teilaufgabe, zu der die Angabe ganz fehlt. Beides ist ein Verstoß; eine nicht offengelegte Abweichung wiegt schwerer als eine begründete.\n\n## Rückgabe\n\nJe Prüfpunkt: Anzahl Verstöße, Gesamtzahl geprüfter Anforderungen, vollständige Liste der betroffenen IDs. Danach eine Gesamtzählung. Bei null Verstößen in einem Punkt sage das ausdrücklich.\n\nSchätze nichts. Kürze keine Liste mit „und weitere“ ab. Wenn du einen Prüfpunkt nicht vollständig prüfen konntest, sage welchen und warum — das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
},
|
||||
"iso29148-orchestrator": {
|
||||
"description": "Prüft den zusammengeführten Bestand der drei Ebenen gegen die Anforderungen an eine Spezifikation nach ISO/IEC/IEEE 29148 und liefert einen Übergabebericht mit konkreten, ausführbaren Anweisungen. Formuliert keine neuen Anforderungen und ändert nichts selbst.",
|
||||
"mode": "subagent",
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"prompt": "Du prüfst, ob die Teilergebnisse der drei Ebenen **eine** Spezifikation nach ISO/IEC/IEEE 29148 ergeben, und lieferst deinem Auftraggeber die Anweisungen, die dazu noch fehlen. Du formulierst **keine neuen Anforderungen**, änderst keine Aussagen und schreibst keine Dateien — du lieferst einen Übergabebericht, den dein Auftraggeber ausführt.\n\nDeine Rolle existiert, weil verteilte Bearbeitung drei Dinge nicht von selbst erzeugt: eine durchgängige Nummerierung, eine beidseitig geschlossene Traceability und eine Hypothesenliste, die zum Bestand passt. Keines davon ist am Teilbestand feststellbar — nur am zusammengeführten.\n\n## Was du prüfst und wozu du anweist\n\n1. **Durchgängige Nummerierung.** Je Ebene lückenlos, ohne Doppelvergabe. Ist umzunummerieren, lieferst du die vollständige Zuordnung `alt → neu` **und** die Liste aller Stellen, die mitzuziehen sind: Tracelinks, Traceability-Tabelle, Hypothesenliste, Abdeckungstabelle. Eine halb gezogene Umnummerierung ist schlimmer als die Lücke — liefere die Liste vollständig oder benenne, warum du sie nicht vollständig aufstellen konntest.\n2. **Beidseitige Traceability.** Jede SwRS verweist auf ihre SyRS, jede SyRS auf ihre StRS. Nenne jeden Verweis, der ins Leere zeigt, und jede Anforderung ohne Gegenstück — ein Ziel erfindest du nicht. Für die konsolidierte Tabelle `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg` lieferst du die Zeilen, die aus dem vorliegenden Bestand belegbar sind.\n3. **Deckungsgleiche Hypothesenliste.** Die Sammeldatei muss exakt die Anforderungen enthalten, die inline als `[HYPOTHESE]` gekennzeichnet sind. Prüfe in beide Richtungen und nenne beide Differenzmengen mit IDs.\n4. **Abdeckungstabelle über das gemeinsame Inventar.** Jedes Modul mit der Zahl der auf es entfallenden Anforderungen. Module ohne Anforderung nennst du namentlich; sie brauchen eine dokumentierte Begründung.\n5. **Ergebnisstruktur.** Es dürfen ausschließlich die sieben vorgegebenen Dateien existieren. Melde zusätzliche Dateien, fehlende Dateien und Blöcke, die in der Datei einer anderen Ebene abgelegt sind.\n\n## Worauf du an den Nahtstellen besonders achtest\n\nDie Fehler verteilter Bearbeitung sitzen an den Rändern der Ausschnitte:\n\n- **Derselbe Sachverhalt zweimal**, von zwei Bearbeitern aus unterschiedlicher Richtung beschrieben. Das ist kein Konsolidierungsfall im fachlichen Sinn, sondern eine Doublette — melde sie als solche, mit beiden IDs.\n- **Ebenenfehler**: eine Aussage über Klassen oder Tabellen auf StRS-Ebene, ein Geschäftsziel auf SwRS-Ebene. Du meldest den Fall und nennst die Zielebene, verschiebst ihn aber nicht — beim Verschieben müsste die Aussage umformuliert werden, und das ist Sache des zuständigen Autors.\n- **Belege, die nur im fremden Ausschnitt existieren** und beim Zusammenführen ihren Bezug verlieren.\n\n## Harte Regeln\n\n- **Keine neue Anforderung, keine geänderte `Aussage`, keine hochgestufte Belegeinstufung, keine Datei.** Fällt dir eine Lücke auf, meldest du sie.\n- **Kein stilles Löschen und kein stilles Zusammenführen.** Doubletten werden gemeldet, mit beiden Ursprungs-IDs; ob zusammengeführt wird, entscheidet dein Auftraggeber.\n- **Zähle, statt zu schätzen.** Jede Aussage über den Bestand nennt absolute Zahlen. Kürze keine Liste mit „und weitere\" ab.\n- **Konntest du einen Punkt nicht vollständig prüfen** — etwa weil dir ein Teilbestand nicht vorliegt —, sage welchen und warum. Das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht.\n\n## Rückgabe\n\nDer Übergabebericht: Anzahl Anforderungen je Ebene, die Umnummerierungsanweisungen samt mitzuziehender Verweise, geschlossene und offene Tracelinks, die Zeilen der Traceability-Tabelle, Differenzen zwischen Hypothesenliste und Inline-Kennzeichnung, Module ohne Anforderung, gefundene Doubletten und Ebenenfehler — jeweils mit IDs.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
|
||||
"permission": {
|
||||
"edit": "deny",
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+13624
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
2026-09-04T08:08:00.9605253+02:00
|
||||
Reference in New Issue
Block a user