Lokaler LM-Studio-Adapter fuer Gemma und Qwen (Skill 10.1.0)
Der TensorX-Wrapper wird providerneutral: opencode-tensorx-adapter.py heisst
jetzt opencode-adapter.py und waehlt ueber --provider {tensorx,lmstudio}
Gateway und Modellvorlage. Der TensorX-Pfad bleibt unveraendert; die vier
bestehenden Regressionstests laufen durch.
Neu fuer den lokalen Betrieb:
- opencode-lmstudio.json fuer google/gemma-4-e4b und qwen/qwen3.8-27b
- Preflight ueber /api/v0/models: Servererreichbarkeit, Modellverfuegbarkeit,
tool_use-Faehigkeit, geladenes Kontextfenster (--min-context, Standard 32768)
und genau eine geladene Instanz; --lmstudio-autoload stellt das selbst her
- local_runtime in RawResult.json (Quantisierung, Architektur, Runtime,
lms-Version, Instanzbezeichner, Kontextfenster) fuer Kap. 4.3
- effort_applied, da der lokale Endpunkt keinen Thinking-Level annimmt
Drei Befunde aus der Inbetriebnahme, alle im Adapter abgefangen: LM Studio
laedt standardmaessig nur 8192 Kontexttokens; ein erneutes lms load erzeugt
eine zweite Instanz und macht das Routing mehrdeutig; Effort ist lokal
wirkungslos. Dazu zwei Korrekturen am gemeinsamen Pfad (Abbruchgrund nur
einmal in errors, saubere lms-Versionskennung).
Enthaelt ausserdem die bislang nicht committeten Laeufe der Iterationen 8
und 9 sowie Versuch 2 (Iterationen 1 bis 3). Der laufende Lauf unter
Iteration 10 ist bewusst nicht enthalten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
b369e6115e
commit
611fd0a80c
+1293
File diff suppressed because it is too large
Load Diff
+189
@@ -0,0 +1,189 @@
|
||||
# Glossar
|
||||
|
||||
c-entron ERP-Suite — Begriffsbestimmungen zur Spezifikation nach ISO/IEC/IEEE 29148:2018.
|
||||
|
||||
Das Glossar bestimmt die Begriffe, die in `StRS.md`, `SyRS.md` und `SwRS.md` verwendet werden. Fachbegriffe sind so bestimmt, wie die Codebasis sie tatsächlich verwendet — nicht wie sie in einem Lehrbuch stehen; wo der Sprachgebrauch der Codebasis vom üblichen abweicht, ist das vermerkt. Technische Bezeichner (Klassen, Methoden, Spalten) stehen in ihrer Originalsprache.
|
||||
|
||||
Die Angabe in Klammern nennt den technischen Bezeichner oder die Fundstelle, an der der Begriff im Bestand verankert ist. Verweise der Form `StRS-004` benennen die Anforderung, die den Begriff tragend verwendet.
|
||||
|
||||
---
|
||||
|
||||
## 1 Aufbau der Spezifikation
|
||||
|
||||
**StRS — Stakeholder Requirements Specification.** Ebene 1 nach ISO/IEC/IEEE 29148. Beschreibt den fachlichen Bedarf einer Rolle im Unternehmen, ohne Aussage darüber, wie das System ihn erfüllt. Enthält keine Klassen-, Methoden- oder Spaltennamen im Feld `Aussage`; die Belege sind gleichwohl technisch.
|
||||
|
||||
**SyRS — System Requirements Specification.** Ebene 2. Beschreibt beobachtbares Verhalten an der Systemgrenze: Schnittstellen, Zustandsmodelle, Prüfungen, Leistungs- und Sicherheitseigenschaften. Der Bezugspunkt ist, was ein Beobachter von außen feststellen kann.
|
||||
|
||||
**SwRS — Software Requirements Specification.** Ebene 3. Beschreibt Komponenten, Datenmodelle und softwareinterne Regeln: konkrete Formeln, Bedingungen, Constraints, Schreibpfade. Jeder Block trägt den Modulmarker des Inventars (`[BE-17]`, `[UI-95]`, `[SV-49]`, `[OP-15]`).
|
||||
|
||||
**Beleg (Evidence) und Belegklassifikation.** `PRIMÄR` bezeichnet eine im Code durchgesetzte Regel oder einen Datenbank-Constraint — die Stelle, die das beschriebene Verhalten erzwingt. `SEKUNDÄR` bezeichnet UI-Beschriftungen, Fehlermeldungen, Berichtslayouts, Zuordnungstabellen und Konfigurationsschalter. `KONTEXT` bezeichnet Kommentare, Commit-Nachrichten und Ticketverweise. Nicht zu verwechseln mit dem kaufmännischen *Beleg* (siehe dort).
|
||||
|
||||
**Durchsetzende Stelle.** Die Datei, Klasse und Methode samt der konkreten Prüfung, Bedingung oder Zuweisung, die eine Regel wirksam macht. Ein bloßer Dateiverweis ist keine durchsetzende Stelle.
|
||||
|
||||
**Fakt gegenüber Aussage.** `Fakt` gibt die belegte technische Beobachtung wieder (Statusübergang, Constraint, Prüfung). `Aussage` gibt die fachliche Auslegung als Soll-Satz wieder. Beide Felder sind bewusst getrennt.
|
||||
|
||||
**Status gegenüber Übernahmewürdigkeit.** `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`). `Übernahmewürdigkeit` beschreibt die fachliche Zukunft bei einer Neuimplementierung (`übernehmen`, `Workaround`, `Sonderfall`, `veraltet`). Beide Angaben sind voneinander unabhängig: eine gut belegte Regel kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
|
||||
|
||||
**Konsolidierungskandidat.** Zwei oder mehr getrennte Implementierungen desselben fachlichen Gegenstands — etwa zwei Datenhaltungen für dasselbe Geschäftsobjekt. Zwei Anforderungen, die dieselbe Sache auf verschiedenen Ebenen beschreiben, sind *kein* Konsolidierungsfall; dafür bestehen Tracelinks.
|
||||
|
||||
---
|
||||
|
||||
## 2 Kaufmännische Grundbegriffe
|
||||
|
||||
**Beleg.** Kaufmännisches Dokument eines Geschäftsvorfalls mit Kopf- und Positionsdaten. Der Bestand kennt sieben Kundenbelegarten (Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag) und die entsprechenden Lieferantenbelegarten. Technisch als `RechKopf`/`RechPos` und Ableitungen geführt; die Belegart als `CentronObjectKindNumeric`. Siehe StRS-006, SyRS-001.
|
||||
|
||||
**Belegart.** Fachliche Gattung eines Belegs. Jede Belegart trägt eine eigene Strategieklasse (`…SpecificLogic`), die ihre Regeln festlegt: zulässige Weiterverarbeitung, Teilnahme an der Limitrechnung, Nummernkreis, Änderbarkeit von Mengen. Siehe SwRS-002.
|
||||
|
||||
**Belegkette.** Die Folge zulässiger Übergänge von einer Belegart in die nächste — Angebot in Auftrag, Auftrag in Lieferschein, Lieferschein in Rechnung, Rechnung in Gutschrift. Abholschein und Gutschrift sind Endpunkte. Das Mischen von Kunden- und Lieferantenbelegen in einem Vorgang ist verboten. Siehe StRS-006, SyRS-002, SyRS-004.
|
||||
|
||||
**Weiterverarbeitung.** Das Erzeugen eines Folgebelegs aus einem oder mehreren Ursprungsbelegen unter Übernahme der Positionen und der Kopfdaten. Bei der Sammelweiterverarbeitung stammen die Kopfdaten aus dem ersten Ursprungsbeleg. Siehe SwRS-010.
|
||||
|
||||
**Belegversion.** Eine neue Fassung desselben Belegs. Der Bestand löscht Belege nicht, sondern versioniert sie; das Storno erzeugt eine eigene Version. Siehe SyRS-006.
|
||||
|
||||
**Nummernkreis** (`Nummernkreis`, `NumberGroupBL`). Ein je Belegart und optional je Filiale geführter fortlaufender Zähler, aus dem die Belegnummer vergeben wird. Die Nummer wird erst beim verbindlichen Speichern vergeben, nicht bei einer Vorschau. Die gepflegten Bereichsgrenzen `BereichVon`/`BereichBis` werden bei der Ermittlung nicht ausgewertet. Siehe StRS-007, SwRS-004.
|
||||
|
||||
**Festschreibung** (`IsFixed`). Kennzeichen an einer Rechnung, das sie gegen inhaltliche Änderung sperrt. Wird in eigener Transaktion gesetzt und protokolliert; eine festgeschriebene Rechnung kann nicht erneut festgeschrieben werden. Die Sperrwirkung ist im Bestand nur im Windows-Client durchgesetzt. Siehe StRS-009, SyRS-011.
|
||||
|
||||
**Storno.** Aufhebung einer Rechnung durch Erzeugung einer neuen Belegversion mit Menge 0 auf allen Artikel- und Rabattpositionen und Belegstatus „storniert". Kein Löschen. Unzulässig unter anderem, wenn die Rechnung bereits an die Buchhaltung exportiert wurde. Siehe StRS-009, SwRS-012.
|
||||
|
||||
**Anzahlungsrechnung.** Eigenständige Rechnung mit Auftragsbezug über genau eine Position mit dem konfigurierten Anzahlungsartikel. In der Schlussrechnung werden die geleisteten Anzahlungen als zusätzliche Positionen mit negiertem Basispreis abgezogen — eine Positionsnegation, keine Zahlungsverbuchung. Siehe StRS-010, SwRS-017.
|
||||
|
||||
**Kreditlimit.** Der für einen Kunden vereinbarte Höchstbetrag ausstehender Forderungen. Bei Überschreitung erfolgt kein Abbruch, sondern eine überstimmbare Rückfrage; über rückfragefreie Aufrufpfade entfällt die Prüfung. Angebot, Abholschein, Gutschrift und Vertrag nehmen an der Limitrechnung nicht teil. Siehe StRS-004, SyRS-013.
|
||||
|
||||
**Mahnstufe.** Der erreichte Grad des Mahnverfahrens zu einer Rechnung: keine, Stufe 1, Stufe 2, Stufe 3. Ein Mahnlauf erhöht sie um genau eine Stufe; Stufe 3 ist die Obergrenze. Siehe StRS-016, SyRS-022.
|
||||
|
||||
**Mahnstopp** (`MahnStop`). Belegbezogenes Kennzeichen, das eine Rechnung vom Mahnverfahren ausnimmt. Nur für Rechnungen setzbar.
|
||||
|
||||
**Sperrstufe / Belegsperre.** Die je Belegart am Kundenstamm gepflegte Mahnstufe, ab der für diesen Kunden keine neuen Belege dieser Art mehr angelegt werden dürfen. Lieferantenbelege sind strukturell ausgenommen. Siehe StRS-003, SyRS-014.
|
||||
|
||||
**Offener Posten (OP, OPOS).** Eine noch nicht ausgeglichene Forderung. Der offene Mahnbetrag ergibt sich als Bruttobetrag abzüglich gezahltem Betrag und abzüglich Gutschriftbetrag. Siehe SwRS-018.
|
||||
|
||||
**Skonto.** Preisnachlass bei Zahlung innerhalb einer vereinbarten Frist. Im Bestand ist keine serverseitige Ermittlungsstelle auffindbar; die einzige belegte Anwendung liegt im Windows-Client und greift nur, wenn noch nichts bezahlt wurde. Als Hypothese geführt: StRS-018, SyRS-027.
|
||||
|
||||
**SEPA-Mandat.** Die vom Kunden erteilte Einzugsermächtigung. Durchläuft die Zustände erstellt, versendet, angenommen, abgelehnt und „Link abgelaufen". Voraussetzung des Lastschrifteinzugs. Siehe StRS-019.
|
||||
|
||||
**Kassenbuch** (`Kassenbuch`). Die je Filiale geführte Aufzeichnung der Barbewegungen. Buchungen aus Belegen entstehen nur bei kassenwirksamer Zahlungsbedingung und werden je Steuersatz gruppiert. Ein Eintrag mit gesetztem Abschlussdatum ist unveränderlich. Siehe StRS-015, SwRS-043.
|
||||
|
||||
**Provisionsschema.** Die Regelmenge, aus der die Vertriebsprovision eines Belegs ermittelt wird. Wird dreistufig aufgelöst: Zuordnung Kunde und Filiale, Schema am Kundenstamm, globales Schema. Siehe StRS-014, SwRS-007.
|
||||
|
||||
**Reverse Charge.** Umkehr der Steuerschuldnerschaft auf den Leistungsempfänger. Für die Bagatellgrenze zählt nur die Nettosumme der reverse-charge-pflichtigen Positionen der Positionsarten Default und Cargo. Siehe SwRS-200.
|
||||
|
||||
**Einstandspreis.** Der fortgeschriebene Beschaffungspreis eines Artikels, Grundlage der Ertragsrechnung. Siehe StRS-024, SwRS-035.
|
||||
|
||||
---
|
||||
|
||||
## 3 Preis- und Konditionsbegriffe
|
||||
|
||||
**Preisliste.** Eine von vier am Artikel geführten Verkaufspreisstufen (VK1 bis VK4). Welche gilt, entscheidet die am Kunden hinterlegte Preisliste; jeder unbekannte Wert fällt auf VK1 zurück. Siehe SwRS-005.
|
||||
|
||||
**Sonderpreis.** Ein für einen bestimmten Kunden vereinbarter Preis, wirksam nur im Gültigkeitszeitraum. Greift dreistufig: artikelgenau, dann Warengruppe mit Untergruppe, dann Warengruppe. Verdrängt die Mengenstaffel vollständig.
|
||||
|
||||
**Staffelpreis (Mengenstaffel).** Ein mengenabhängiger Preis. Wird nur herangezogen, wenn kein Kunden-Sonderpreis besteht, eine Menge übergeben wurde und der Vertrag Staffelpreise zulässt.
|
||||
|
||||
**Sondervereinbarung / Projektpreis.** Eine befristete, zustandsgebundene Konditionsvereinbarung. Die kundenbezogene Vereinbarung geht der belegartweiten globalen Vereinbarung vor. Ein Projektpreis ist zusätzlich an Kundenzugehörigkeit, Filialfreigabe und Projektlaufzeit gebunden — alle drei müssen gleichzeitig erfüllt sein. Siehe SwRS-188.
|
||||
|
||||
**Preisfindungskaskade.** Die feste Rangfolge, in der der Basispreis einer Position ermittelt wird: Vertrags-Sonderpreis, Kunden-Sonderpreis, Staffelpreis, Standard-Verkaufspreis. Ein Aktionspreis ist in der Kette nicht enthalten. Siehe StRS-005, SyRS-038, SwRS-005.
|
||||
|
||||
**Kundenrabatt.** Ein belegweiter prozentualer Nachlass, der als eigene negative Position mit Menge 1 eingesetzt wird. Auf zwei Nachkommastellen kaufmännisch von null weg gerundet. Siehe SwRS-200.
|
||||
|
||||
---
|
||||
|
||||
## 4 Vertrags-, Service- und Anlagenbegriffe
|
||||
|
||||
**Vertrag.** Eine wiederkehrend abzurechnende Vereinbarung mit Abrechnungsintervall (täglich, monatlich, quartalsweise, jährlich), Berechnungsart (automatisch, bedarfsabhängig, manuell — kombinierbar) und Abrechnungszeitpunkt (vor- oder nachschüssig). Siehe StRS-011, SyRS-020.
|
||||
|
||||
**Kontingent.** Die vertraglich vereinbarte Leistungsmenge eines Abrechnungszeitraums. Das gebuchte Kontingent ergibt sich aus Kontingentwert mal Intervallanzahl; Intervallbeginne sind kalenderfest. Eine prozentuale oder absolute Schwelle löst Abrechnungsbedarf aus. Siehe SyRS-021, SwRS-023.
|
||||
|
||||
**Automatikverlängerung** (`AutomatedProlongation`). Kennzeichen, dass sich ein Vertrag ohne Zutun verlängert. Ein solcher Vertrag läuft nicht ab und erzeugt daher keine Ablauf-Wiedervorlage. Siehe StRS-012.
|
||||
|
||||
**Stammblatt** (`GeraeteKopf`/`GeraetePos`, Sicht `MasterDataList`). Die Geräteakte einer beim Kunden betriebenen technischen Anlage: genau ein Hauptgerät mit Positionen, Kunde, Anschrift, Seriennummer und Vertragsbezug; genau eine Hauptposition mit Menge 1. Nicht deaktivierbar, solange einer Position eines aktiven Vertrags zugeordnet. Siehe StRS-013, SwRS-026.
|
||||
|
||||
**Zählerstand / Klick.** Der von einer technischen Anlage gemeldete Nutzungszähler, Grundlage der nutzungsabhängigen Abrechnung. Ein importierter Stand kleiner als der gespeicherte wird abgewiesen; der Vorwert wandert in die Historie. Siehe SwRS-027.
|
||||
|
||||
**Asset / Anlage.** Fachlich dasselbe Geschäftsobjekt, im Bestand aber in drei getrennten Datenhaltungen geführt: als Belegposition beim Kunden, als Stammblatt und als überwachtes Gerät (`AssetManagementDevices`). Die Trennung ist nirgends durchgesetzt; das naheliegende Kennzeichen `ClickGeraet` ist gemappt, wird aber nicht ausgewertet. Der wichtigste Konsolidierungskandidat des Bestands. Siehe StRS-013.
|
||||
|
||||
**Ticket / Helpdesk.** Ein Servicevorgang mit datengetriebenem Statusmodell und genau einem Abschlussstatus. Siehe StRS-026, SyRS-033.
|
||||
|
||||
**Eskalation.** Die dreistufige Fristüberwachung eines Tickets, gerechnet in Arbeitsstunden. Siehe SwRS-030.
|
||||
|
||||
**RMA.** Reklamations- und Rücksendevorgang, je Ticket genau einmal anlegbar, mit zwei getrennten Zustandsachsen je Position. Siehe StRS-028, SyRS-035, SwRS-134.
|
||||
|
||||
**Massenupdate.** Eine Vorlage, die eine gleichartige Änderung auf viele Datensätze anwendet. Positionsweise und idempotent: bereits erfolgreich verarbeitete Positionen werden bei einem Wiederholungslauf übersprungen. Siehe SwRS-186.
|
||||
|
||||
---
|
||||
|
||||
## 5 Organisations- und Berechtigungsbegriffe
|
||||
|
||||
**Mandant.** Eine rechtlich eigenständige Einheit innerhalb einer Installation. Daten, Nummernkreise und Auswertungen sind zu trennen. Siehe SyRS-069.
|
||||
|
||||
**Filiale** (`BranchI3D`). Eine organisatorische Untereinheit eines Mandanten. Wirkt auf Nummernkreise, Kassenbuch, Statistiksichtbarkeit und Provisionsschema-Auflösung. Siehe SyRS-070.
|
||||
|
||||
**Vertriebsgebiet.** Regionale Zuständigkeitszuordnung eines Mitarbeiters. Ein Mitarbeiter ohne jede Zuordnung gilt als für *alle* Gebiete zuständig — eine implizite Semantik, die in den Daten nicht gekennzeichnet ist. Siehe SwRS-195.
|
||||
|
||||
**Anmeldetyp.** Das Merkmal, das Mitarbeiter-, Kunden- und Add-In-Zugang unterscheidet. Trägt im Bestand die Trennung von Mitarbeiter- und Kundenzugang. Siehe StRS-034, SyRS-060.
|
||||
|
||||
**Rechtegruppe.** Der einzige vorgesehene Weg der Berechtigungsvergabe; Einzelrechte werden über die Gruppenmitgliedschaft aufgelöst. Siehe SyRS-055, SwRS-047.
|
||||
|
||||
**Einschränkendes Recht.** Ein Recht, dessen Besitz nicht erweitert, sondern begrenzt — etwa die Beschränkung der Provisionsanzeige auf die eigenen Provisionen. Eigene Kategorie im Rechtemodell. Siehe SyRS-056.
|
||||
|
||||
**Portalkonto / Web-Recht** (`WebRights`, `WebAccountsRights`). Das vom Mitarbeiter-Rechtemodell getrennte Berechtigungsmodell der Kunden- und Partnerzugänge. Zweites, nicht deckungsgleiches Modell neben dem Rechtebaum. Siehe SyRS-057.
|
||||
|
||||
**Fail-closed / fail-open.** Verhalten einer Prüfung, wenn die Entscheidungsgrundlage fehlt. *Fail-closed* verweigert im Zweifel (Zielzustand), *fail-open* gewährt im Zweifel. Der Bestand enthält beides nebeneinander, teils innerhalb derselben Komponente. Siehe SyRS-077, SyRS-078, SwRS-197.
|
||||
|
||||
**Lizenz.** Die vertraglich freigeschaltete Funktions- und Benutzermenge einer Installation, hardwaregebunden geprüft. Siehe SyRS-071, SyRS-072.
|
||||
|
||||
---
|
||||
|
||||
## 6 Technische Begriffe der Codebasis
|
||||
|
||||
**I3D.** Der durchgängig verwendete technische Primärschlüssel der Datensätze; Fremdschlüsselspalten tragen das Suffix `…I3D`. Kein fachlicher Identifikator — die fachliche Identität ist etwa die Kundennummer oder die Belegnummer.
|
||||
|
||||
**BL — Business Logic** (`Centron.BL`). Die serverseitige Geschäftslogikschicht. Regeln, die hier durchgesetzt werden, gelten für alle Zugangswege; Regeln nur im Windows-Client gelten nur dort.
|
||||
|
||||
**DAO / Mapping** (`Centron.DAO`). Die Persistenzschicht auf Basis von NHibernate und Fluent-NHibernate; bildet Entitäten auf Tabellen und Sichten ab.
|
||||
|
||||
**DTO.** Datentransferobjekt der Außenschnittstellen. Der Bestand kennt Fälle, in denen ein DTO Geheimnisse im Klartext an den Client zurückgibt. Siehe SwRS-400.
|
||||
|
||||
**SpecificLogic.** Die je Belegart implementierte Strategieklasse, die belegartabhängige Regeln festlegt (Weiterverarbeitungsziele, Mengenänderbarkeit, Limitteilnahme, Nummernkreis). Siehe SwRS-002.
|
||||
|
||||
**WCF-Brücke.** Der Weiterbetrieb der Legacy-WCF-Schnittstelle über ASP.NET Core. Standardverhalten fail-open: geschützt nur dort, wo `[Authenticate]` ausdrücklich gesetzt ist. Siehe SyRS-078.
|
||||
|
||||
**REST v1.** Die neuere HTTP-Schnittstelle des Web Service mit globaler Autorisierungsvorgabe (fail-closed). Siehe SyRS-077, SwRS-226.
|
||||
|
||||
**Nexus.** Die Blazor-basierte Weboberfläche der Suite, betrieben als Windows-Dienst oder Containerimage. Enthält Mitarbeiter- und Kundenbereich; die Trennung erfolgt über getrennte Lauschports und den Anmeldetyp. Siehe SyRS-085.
|
||||
|
||||
**ServiceBoard.** Der Arbeitsbereich des Servicebetriebs innerhalb von Nexus. Vier registrierte Routen sind Platzhalter ohne Funktion, darunter der Kennwortmanager.
|
||||
|
||||
**WebCart.** Der Web-Warenkorb mit eigener Freigabekette als Zustandsautomat. Siehe SyRS-019, SwRS-317.
|
||||
|
||||
**Zugriffstoken / Sitzungsticket.** Die beiden Ausweismittel der Zugangskanäle. Sitzungstickets tragen eine anwendungsabhängige Ablauffrist, Zugriffstoken einen erzwungenen Ablauf und einen begrenzten Geltungsbereich. Siehe SyRS-050, SyRS-051.
|
||||
|
||||
**Anonymer Token-Zugang.** Ein ohne Anmeldung nutzbarer, tokengebundener Außenzugang für Angebote, Dokumente und Webformulare. Siehe SyRS-063, SyRS-087.
|
||||
|
||||
**Zusatzfeld (Custom Property).** Ein je Objektart frei definierbares Feld mit Sichtbarkeits-, Versiegelungs- und Pflichtkennzeichen. Ein leeres Pflicht-Zusatzfeld sperrt den Speichern-Befehl. Siehe SwRS-194.
|
||||
|
||||
**Positionsart.** Die Rolle einer Belegposition in der Summenbildung: Default und Cargo zählen, informative, alternative und optionale Positionen sowie aufgeklappte Stücklistenköpfe zählen nicht. Siehe SwRS-199.
|
||||
|
||||
**Rundungsdifferenz-Position.** Eine automatisch eingefügte Ausgleichsposition bei Stücklistenköpfen mit mehr als zwei Nachkommastellen im Einzelpreis. Idempotent berechnet. Siehe SwRS-200.
|
||||
|
||||
---
|
||||
|
||||
## 7 Angebundene Fremdsysteme und Formate
|
||||
|
||||
**finAPI.** Bankdatendienst für den Abruf von Kontoumsätzen; Test- und Produktivbetrieb umschaltbar, lizenzgebunden. Siehe SyRS-091, SwRS-266.
|
||||
|
||||
**GLS, Shipcloud.** Die beiden parallel betriebenen Versanddienstleisteranbindungen mit unterschiedlichen Mengengrenzen. Siehe SyRS-093.
|
||||
|
||||
**ITscope, Icecat, EGIS, COP.** Externe Produkt-, Distributions- und Lieferantendatenquellen, im Bestand als austauschbare Suchanbieter geführt. Siehe SyRS-094.
|
||||
|
||||
**docuFORM.** Managed-Print-Anbindung für den unbeaufsichtigten Abruf von Gerätezählerständen. Im Bestand das positive Gegenbeispiel der Geheimnisverwaltung: PKCE, verschlüsseltes Geheimnis und Refresh-Token, an ein Recht gebunden. Siehe SyRS-096, SwRS-275, SwRS-399.
|
||||
|
||||
**EDI.** Der elektronische Austausch von Geschäftsnachrichten mit Lieferanten. Siehe SyRS-090, SwRS-360.
|
||||
|
||||
**DATEV.** Das Ausgabeformat der Buchhaltungsübergabe an die Steuerberatung. Siehe SwRS-044.
|
||||
|
||||
**ZUGFeRD, XRechnung, ebInterface.** Formate der elektronischen Rechnungsstellung; ebInterface ist ein reines Exportformat ohne Netzwerkanbindung. Siehe StRS-022, SyRS-092.
|
||||
|
||||
**FastReport.** Die eingesetzte Berichtsmaschine.
|
||||
|
||||
**WiX / WixSharp, Bullseye.** Die beiden Installertechnologien mit gegenläufigen Upgrade-Regeln beziehungsweise die Zielbeschreibung der Build-Skripte. Siehe SyRS-099, SyRS-102.
|
||||
+265
@@ -0,0 +1,265 @@
|
||||
# Hypothesen
|
||||
|
||||
c-entron ERP-Suite — Anforderungen, deren Aussage sich aus den vorliegenden Artefakten nicht abschließend belegen ließ.
|
||||
|
||||
Diese Datei ist aus dem zusammengeführten Bestand erzeugt und mit den Inline-Markierungen in `StRS.md`, `SyRS.md` und `SwRS.md` abgeglichen. Sie enthält genau die dort als `Status: HYPOTHESE` geführten Anforderungen — keine weiteren offenen Fragen. Offene Punkte ohne zugehörige Anforderung stehen in der Selbstbewertung des Analyseberichts.
|
||||
|
||||
Eine Hypothese ist keine Vermutung ins Blaue: Der Sachverhalt ist jeweils bis zu dem Punkt belegt, an dem die Artefakte nicht weiter tragen. Das Feld *Fehlende Information* benennt, was zur Auflösung erhoben werden müsste. Die `Übernahmewürdigkeit` ist davon unabhängig und bleibt gültig.
|
||||
|
||||
| Ebene | Anforderungen gesamt | davon Hypothese | Anteil |
|
||||
|---|---|---|---|
|
||||
| StRS | 53 | 3 | 5.7 % |
|
||||
| SyRS | 149 | 6 | 4.0 % |
|
||||
| SwRS | 404 | 20 | 5.0 % |
|
||||
| **gesamt** | **606** | **29** | **4.8 %** |
|
||||
|
||||
---
|
||||
|
||||
## StRS (Stakeholder-Ebene) — 3 Hypothesen
|
||||
|
||||
### StRS-002 — Dublettenfreiheit im Geschäftspartnerstamm
|
||||
|
||||
**Vermutete Anforderung:** Das System soll bei der Neuanlage eines Geschäftspartners auf bereits vorhandene, gleichartige Geschäftspartner hinweisen, damit derselbe Kunde oder Lieferant nicht mehrfach geführt wird.
|
||||
|
||||
**Fehlende Information:** Eine Dublettenprüfung für Kunden, Accounts oder Ansprechpartner ist im erhobenen Ausschnitt nicht auffindbar;
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - fachlich erforderlich, im Bestand aber nicht realisiert; bei der Migration als Neuanforderung zu behandeln.
|
||||
|
||||
### StRS-018 — Skontogewährung beim Ausgleich offener Forderungen
|
||||
|
||||
**Vermutete Anforderung:** Das System soll beim Ausgleich einer Forderung innerhalb der vereinbarten Skontofrist den zulässigen Skontobetrag ermitteln, ihn der Buchhaltung zur Bestätigung vorlegen und die Forderung nach Anrechnung von Zahlung und Skonto als vollständig ausgeglichen führen.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: die Stelle, an der der Skontoabzug fachlich ermittelt und auf die Forderung angerechnet wird - vermutet werden Webservice- oder Frontendpfade außerhalb des erhobenen Ausschnitts.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - kaufmännisch unverzichtbar; die Regel ist im Bestand nur clientseitig und unvollständig vorhanden und bei der Migration serverseitig zu verankern.
|
||||
|
||||
### StRS-052 — Getrennte Datenhaltung mehrerer Mandanten
|
||||
|
||||
**Vermutete Anforderung:** Das System soll mehrere rechtlich getrennte Einheiten in einer Installation so führen, dass ein Benutzer Stammdaten, Belege, Nummernkreise und Auswertungen ausschließlich derjenigen Einheit sieht und verändert, der er zugeordnet ist, und dass eine Auswertung oder eine Nummernvergabe niemals Daten mehrerer Einheiten vermischt.
|
||||
|
||||
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - Der Bedarf mehrerer rechtlich getrennter Einheiten besteht fachlich; die vorhandene Umsetzung trägt ihn nicht und ist beim Nachbau als durchgängige Systemeigenschaft neu zu entwerfen.
|
||||
|
||||
---
|
||||
|
||||
## SyRS (System-Ebene) — 6 Hypothesen
|
||||
|
||||
### SyRS-027 — Skontoabzug beim Abgleich einer Zahlung mit einem offenen Posten
|
||||
|
||||
**Vermutete Anforderung:** Das System soll bei einem Zahlungseingang innerhalb der vereinbarten Skontofrist den zulässigen Skontobetrag ermitteln, den Restbetrag der Rechnung entsprechend ausgleichen und den gewährten Skonto getrennt ausweisen.
|
||||
|
||||
**Fehlende Information:** Eine durchsetzende Stelle für einen Skontoabzug beim Zahlungsabgleich ist nicht auffindbar: Eine Volltextsuche nach `Skonto|CashDiscount` über `Centron.BL/Finances`, `Centron.BL/Accounting` und `Centron.Gateway/OnlineBanking` liefert keine Stelle, die einen Skontoabzug beim Abgleich einer Zahlung mit einem offenen Posten berechnet oder prüft;
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - Die Regel ist fachlich erforderlich, im erhobenen Ausschnitt aber nicht durchgesetzt; sie ist beim Umbau serverseitig zu verankern.
|
||||
|
||||
### SyRS-040 — Rechteprüfung beim Erzeugen und Verwalten von Berichten
|
||||
|
||||
**Vermutete Anforderung:** Das System soll den Abruf, die Erzeugung und die Verwaltung von Berichten an ein Benutzerrecht binden und dabei sicherstellen, dass ein Bericht keine Daten ausgibt, die der abrufende Benutzer nach dem Rechtemodell nicht sehen darf.
|
||||
|
||||
**Fehlende Information:** **Fehlende Information:** ob eine serverseitige Rechteprüfung in der Aufruferkette vor der Berichtsmaschine liegt (Webservice-Fassade, Nexus, Hostdienst);
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - Die Anforderung ist fachlich erforderlich; ob sie derzeit an der Systemgrenze erfüllt wird, ist ohne die Aufruferkette nicht entscheidbar.
|
||||
|
||||
### SyRS-067 — Rechteprüfung und Parametersicherheit der Berichtserzeugung
|
||||
|
||||
**Vermutete Anforderung:** Das System soll jeden Bericht mit einer Berechtigungsprüfung des ausführenden Benutzers erzeugen, ändern, löschen und verschieben, dabei sämtliche Parameterwerte ausschließlich als gebundene Datenbankparameter übergeben und die freie Abfrageausführung an ein eigenes, protokolliertes administratives Recht binden.
|
||||
|
||||
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - Rechteprüfung und gebundene Parameter sind für das Zielsystem verbindlich zu erbringen.
|
||||
|
||||
### SyRS-110 — Einschränkung des Mehrinstanzbetriebs durch prozesslokale Zustände
|
||||
|
||||
**Vermutete Anforderung:** Das System soll in einem Mehrinstanzbetrieb hinter einem Lastverteiler betreibbar sein; alle Zustände, die über einen einzelnen Aufruf hinaus gelten — Echtzeitverbindungszuordnung, gemeinsame Zwischenspeicher, Dienstsperren —, sollen instanzübergreifend geteilt werden, damit ein Anwender unabhängig von der bedienenden Instanz dasselbe Verhalten erfährt.
|
||||
|
||||
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - Sofern der Mehrinstanzbetrieb Ziel ist, sind Backplane, geteilter Zwischenspeicher und eine datenbankgestützte Dienstsperre bei einer Migration einzuführen.
|
||||
|
||||
### SyRS-119 — Versandkostenermittlung über die Gewichtsstaffel
|
||||
|
||||
**Vermutete Anforderung:** Das System soll die Versandkosten eines Belegs aus dem Gesamtgewicht der versandrelevanten Positionen und der zur gewählten Versandart hinterlegten Gewichtsstaffel eindeutig ermitteln und eine Staffel, die für das ermittelte Gewicht keinen oder mehr als einen Treffer liefert, als Konfigurationsfehler melden statt einen beliebigen Satz zu verwenden.
|
||||
|
||||
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - gewichtsabhängige Versandkosten sind fachlich erforderlich; die Umsetzung ist vor der Migration erst zu belegen.
|
||||
|
||||
### SyRS-139 — Antwortzeitverhalten der Stammdatensuche
|
||||
|
||||
**Vermutete Anforderung:** Das System soll eine Stammdatensuche über Kunden-, Artikel- und Mitarbeiterbestände so beantworten, dass die erste Ergebnisseite innerhalb einer festgelegten, messbaren Höchstdauer beim Anwender sichtbar ist, und diese Höchstdauer als konfigurierten Sollwert führen sowie Überschreitungen protokollieren.
|
||||
|
||||
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - eine messbare Antwortzeitvorgabe fehlt heute und ist für die Zielarchitektur festzulegen.
|
||||
|
||||
---
|
||||
|
||||
## SwRS (Software-Ebene) — 20 Hypothesen
|
||||
|
||||
### SwRS-073 — Filterbedingung für gesperrte Konten in der erweiterten Adresssuche
|
||||
|
||||
**Vermutete Anforderung:** Das System soll bei aktivem Filterknoten „gesperrte Konten" die Ergebnismenge der erweiterten Adresssuche auf Konten mit gesetztem Sperrkennzeichen einschränken.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: die Stelle, an der der Filterknoten in ein Suchprädikat umgesetzt wird.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - Filterung nach Sperrstatus ist fachlich erforderlich, die Umsetzung ist noch zu belegen.
|
||||
|
||||
### SwRS-079 — Rechteprüfung beim Löschen eines SEPA-Mandats
|
||||
|
||||
**Vermutete Anforderung:** Das System soll das Löschen eines produktiven SEPA-Mandats an ein ausdrückliches Löschrecht binden, analog zum Löschen eines Auftragsverarbeitungsvertrags.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: eine durchsetzende Stelle, die das Löschen eines Mandats an ein Recht bindet - weder im Client noch als serverseitige Prüfung ist eine solche Stelle in dieser Faktenbasis nachgewiesen.
|
||||
|
||||
**Übernahmewürdigkeit:** Workaround - der heutige Zustand ist eine ungewollte Rechtelücke und darf nicht unverändert übernommen werden.
|
||||
|
||||
### SwRS-080 — Formatprüfung der IBAN am SEPA-Mandat
|
||||
|
||||
**Vermutete Anforderung:** Das System soll die IBAN der einem SEPA-Mandat zugeordneten Bankverbindung vor dem Speichern auf gültiges Format und gültige Prüfziffer prüfen und das Speichern bei Verstoß abweisen.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: ob die IBAN serverseitig geprüft wird - die zugehörige Backend-Logik ist in dieser Faktenbasis nicht enthalten.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - eine IBAN-Prüfung ist für den Lastschrifteinzug erforderlich und im Zielsystem vorzusehen.
|
||||
|
||||
### SwRS-083 — Serverseitige Nachprüfung der im Client durchgesetzten Schreibschutz-, Rechte- und Preisregeln
|
||||
|
||||
**Vermutete Anforderung:** Das System soll jede im Client durchgesetzte Schreibschutz-, Rechte- und Preisregel der Belegerfassung beim Speichern serverseitig erneut prüfen und eine Anforderung abweisen, die gegen sie verstößt.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: ob die zugehörige serverseitige Logik dieselben Bedingungen erneut prüft - aus diesem Ausschnitt ist das nicht belegbar;
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - die serverseitige Nachprüfung ist im Zielsystem verbindlich vorzusehen; der heutige Nachweis fehlt.
|
||||
|
||||
### SwRS-085 — Rechteprüfung der Container des Beleg-Dashboards
|
||||
|
||||
**Vermutete Anforderung:** Das System soll jede Dashboard-Kachel, die Vertrags-, Umsatz- oder Projektzahlen anzeigt, nur Benutzern zugänglich machen, die das Recht auf die zugrunde liegenden Daten besitzen.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: ob die Sichtbarkeit der Kacheln zentral über die Kachel- bzw.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - eine rechteabhängige Kachelanzeige ist im Zielsystem vorzusehen; der heutige Durchsetzungsort ist offen.
|
||||
|
||||
### SwRS-090 — Eindeutigkeit von Barcode- und Seriennummernwerten
|
||||
|
||||
**Vermutete Anforderung:** Das System soll die Eindeutigkeit eines Barcode- bzw. Seriennummernwerts im vorgesehenen Gültigkeitsbereich durchsetzen und die Anlage eines bereits vergebenen Werts abweisen.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: ob eine Eindeutigkeitsprüfung in der Geschäftslogik (`IBarcodeLogic`) besteht - diese liegt außerhalb dieses Ausschnitts.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - Seriennummern-Eindeutigkeit ist im Zielsystem datenbankseitig zu verankern.
|
||||
|
||||
### SwRS-102 — Ausschluss werbegesperrter Adressen aus Kampagnen- und Mailingläufen
|
||||
|
||||
**Vermutete Anforderung:** Das System soll jede Adresse mit gesetztem Kennzeichen `AdvertisingNotAllowed` aus der Empfängermenge jedes Kampagnen- und Mailinglaufs ausschließen.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: eine durchsetzende Stelle, die werbegesperrte Adressen aus der Empfängermenge entfernt - weder im Client noch als belegte serverseitige Selektion.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - eine gepflegte Werbesperre ohne durchsetzende Stelle ist im Zielsystem zwingend zu schließen.
|
||||
|
||||
### SwRS-118 — Eindeutigkeit der Belegnummer von Lieferantenbelegen
|
||||
|
||||
**Vermutete Anforderung:** Das System soll die Eindeutigkeit einer Belegnummer je Lieferant und Belegart persistenzseitig sicherstellen und eine bewusst zugelassene Dublette als ausdrücklich bestätigten Sonderfall kennzeichnen.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: ein eindeutiger Datenbankindex auf die Belegnummer ist in dieser Faktenbasis nicht nachgewiesen;
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - die Prüfung ist zu erhalten und um eine persistenzseitige Absicherung zu ergänzen.
|
||||
|
||||
### SwRS-149 — Serverseitige Rechteprüfung der über den SQL-Manager abgesetzten Abfragen
|
||||
|
||||
**Vermutete Anforderung:** Das System soll jede über den SQL-Manager abgesetzte Abfrage serverseitig erneut gegen das Recht `Administration.SQL_MANAGER` prüfen und auf lesende Anweisungen beschränken.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: die serverseitige Implementierung selbst.
|
||||
|
||||
**Übernahmewürdigkeit:** Sonderfall - freier Abfragezugang ist im Zielsystem auf eine geprüfte, lesende Schnittstelle zu begrenzen.
|
||||
|
||||
### SwRS-163 — Rechteprüfung des Rechnungs-PDF-Exports
|
||||
|
||||
**Vermutete Anforderung:** Das System soll den Export von Rechnungen als PDF an ein eigenes, an der Aufrufstelle geprüftes Benutzerrecht binden.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: die Aufrufstelle von `DataExportViewModel`.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - das Recht ist im Zielsystem ausdrücklich zu definieren.
|
||||
|
||||
### SwRS-172 — Serverseitige Kennwortregeln bei der Kennwortänderung
|
||||
|
||||
**Vermutete Anforderung:** Das System soll Mindestlänge, Zeichenkomplexität und eine Wiederverwendungssperre für Kennwörter serverseitig durchsetzen und dem Client nur die Rückmeldung überlassen.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: die serverseitige Implementierung der Kennwortänderung.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - Kennwortregeln gehören verbindlich auf die Serverseite.
|
||||
|
||||
### SwRS-256 — Clientseitiger Pfad zur Abschaltung der Systemauthentifizierung
|
||||
|
||||
**Vermutete Anforderung:** Das System soll die Umstellung des systemweiten Anmeldeverfahrens, insbesondere die Abschaltung der Authentifizierung, serverseitig an ein benanntes Administrationsrecht binden, den Vorgang mit Benutzer und Zeitpunkt protokollieren und im Fehlerfall keine unveränderten Antwortinhalte des Gegenübers an den Aufrufer weitergeben.
|
||||
|
||||
**Fehlende Information:** fehlende Information: die durchsetzende Stelle am Endpunkt `config/authentication` für den Zweig „keine Authentifizierung".
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - die Funktion wird benötigt, die Absicherung ist zu belegen und gegebenenfalls nachzurüsten.
|
||||
|
||||
### SwRS-355 — Kebab-Case-Pflicht für Dokumentationsdateien ohne maschinelle Durchsetzung
|
||||
|
||||
**Vermutete Anforderung:** Das System soll die Einhaltung von Verzeichnisstruktur und Kebab-Case-Namensregel für Dokumentationsdateien in einem Pipelineschritt prüfen und Verstöße als Fehler melden.
|
||||
|
||||
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - die Regel ist sinnvoll, aber erst mit einer Prüfung wirksam.
|
||||
|
||||
### SwRS-359 — Gestaffelte Auditspalten und logische Löschung für neue Domänentabellen
|
||||
|
||||
**Vermutete Anforderung:** Das System soll jede neue Domänentabelle mit den Anlage- und Löschauditspalten ausstatten, Änderungsauditspalten nur bei änderbaren Zeilen führen, Datensätze ausschließlich logisch über `IsDeleted` löschen und auf SQL-Defaults verzichten.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: eine durchsetzende Stelle (Analyzer, Schematest oder generierende Hilfsmethode), die das Vorhandensein der fünf Pflichtspalten und das Fehlen von SQL-Defaults auf neuen Domänentabellen tatsächlich erzwingt;
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - logische Löschung und Auditspalten sind Grundlage der Nachvollziehbarkeit.
|
||||
|
||||
### SwRS-361 — Zeitlich befristete Aktionspreise in HerstellerArtikAktionspreis
|
||||
|
||||
**Vermutete Anforderung:** Das System soll für einen Artikel innerhalb des hinterlegten Gültigkeitszeitraums den Aktionspreis anstelle des regulären Preises verwenden.
|
||||
|
||||
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
|
||||
|
||||
**Übernahmewürdigkeit:** Sonderfall - Datenhaltung vorhanden, Wirksamkeit in der Preisfindung ungeklärt.
|
||||
|
||||
### SwRS-362 — Umleitung externer E-Mail-Adressen in DEBUG-Builds
|
||||
|
||||
**Vermutete Anforderung:** Das System soll den Versand an Empfängeradressen außerhalb der Domäne `nexoware.com` in Entwicklungs- und Testständen unterbinden und stattdessen an eine feste Sammeladresse zustellen; die Steuerung soll an der Betriebsumgebung und nicht an der Buildkonfiguration hängen.
|
||||
|
||||
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - Schutzmechanismus notwendig, Kopplung an die Umgebung statt an die Buildkonfiguration zu ändern.
|
||||
|
||||
### SwRS-363 — Unterstützte ZUGFeRD- und XRechnung-Fassungen mit fester Business-Process-ID
|
||||
|
||||
**Vermutete Anforderung:** Das System soll elektronische Rechnungen in genau diesen vier Fassungen erzeugen und bei der Fassung XRechnung 3.0.1 die genannte Business-Process-ID unverändert eintragen.
|
||||
|
||||
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - abrechnungsrelevantes Ausgabeformat, gesetzlich gefordert.
|
||||
|
||||
### SwRS-364 — Skriptnummernvergabe außerhalb des Repositories ohne Kollisionsschutz
|
||||
|
||||
**Vermutete Anforderung:** Das System soll die Vergabe der Skriptnummer im Repository nachvollziehbar führen und kollidierende Nummern beim Bau erkennen, statt sie einer Datei außerhalb der Versionsverwaltung zu überlassen.
|
||||
|
||||
**Fehlende Information:** Fehlende Information: Die maßgebliche Nummernliste liegt außerhalb des Repositories und ist im Rahmen dieser Erhebung nicht einsehbar;
|
||||
|
||||
**Übernahmewürdigkeit:** Workaround - Verfahren außerhalb der Versionsverwaltung, im Zielsystem zu ersetzen.
|
||||
|
||||
### SwRS-380 — Frontend-Abhängigkeiten nur über LibMan oder CDN mit Integrity-Hash
|
||||
|
||||
**Vermutete Anforderung:** Das System soll externe Skript- und Stilressourcen nur mit hinterlegtem Integrity-Hash laden oder im Repository vorhalten und die Einhaltung dieser Regel maschinell prüfen.
|
||||
|
||||
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - Subresource Integrity ist sinnvoll, aber erst mit Prüfung wirksam.
|
||||
|
||||
### SwRS-385 — Einschränkende Rechte verringern die Sichtbarkeit
|
||||
|
||||
**Vermutete Anforderung:** Das System soll die Rechtelogik so auswerten, dass der Besitz eines als einschränkend gekennzeichneten Rechts den Sichtbarkeitsumfang verringert, und abgerechnete Helpdeskzeiten unabhängig vom Rechtebesitz gegen Verschieben und Löschen sperren.
|
||||
|
||||
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
|
||||
|
||||
**Übernahmewürdigkeit:** übernehmen - der Katalog ist unvollständig, die beschriebene Logik jedoch tragend.
|
||||
|
||||
---
|
||||
|
||||
## Abgleich mit den Inline-Markierungen
|
||||
|
||||
Deckungsgleich: jede hier aufgeführte Anforderung trägt im jeweiligen Ebenendokument sowohl `Status: HYPOTHESE` als auch das Titelpräfix `[HYPOTHESE]`; umgekehrt ist keine so gekennzeichnete Anforderung hier ausgelassen.
|
||||
|
||||
+1170
File diff suppressed because it is too large
Load Diff
+7972
File diff suppressed because it is too large
Load Diff
+3108
File diff suppressed because it is too large
Load Diff
+652
@@ -0,0 +1,652 @@
|
||||
# Traceability
|
||||
|
||||
c-entron ERP-Suite — Verfolgbarkeit zwischen den drei Ebenen der Spezifikation nach ISO/IEC/IEEE 29148:2018.
|
||||
|
||||
Die Verknüpfungen stammen aus dem Feld `Tracelinks` der Anforderungen und sind beidseitig ausgewertet: eine Verknüpfung, die eine SwRS auf ihre SyRS setzt, erscheint auch in der Rückwärtssicht der SyRS. Die Spalte `Artefaktbeleg` nennt den ersten `PRIMÄR`-Beleg der jeweils tiefsten Anforderung der Zeile; die vollständige Belegliste steht am Anforderungsblock selbst.
|
||||
|
||||
| Ebene | Anforderungen | mit Verknüpfung nach oben | mit Verknüpfung nach unten |
|
||||
|---|---|---|---|
|
||||
| StRS | 53 | 0 | 53 |
|
||||
| SyRS | 149 | 140 | 129 |
|
||||
| SwRS | 404 | 403 | 0 |
|
||||
|
||||
---
|
||||
|
||||
## 1 Konsolidierte Tabelle StRS — SyRS — SwRS
|
||||
|
||||
Eine Zeile je SwRS-Anforderung. `StRS-ID` ist über die SyRS-Kette aufgelöst; wo eine SwRS unmittelbar auf eine StRS verweist, steht diese ebenfalls. Ein Strich bedeutet, dass auf dieser Ebene keine Verknüpfung besteht — diese Fälle sind in Abschnitt 4 aufgeführt.
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---|---|---|---|
|
||||
| StRS-006 | SyRS-001, SyRS-002 | SwRS-001 | `src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs:273-301` — `IsCustomerReceipt`/`IsSupplierRecei... |
|
||||
| StRS-006 | SyRS-001, SyRS-002, SyRS-004, SyRS-005 | SwRS-002 | `Centron.BL/Sales/Receipts/SpecificLogics.cs:46-59` (Registrierung) und `:123-139` (`Execute<T>`), Zitat `I... |
|
||||
| StRS-006, StRS-007, StRS-052 | SyRS-007, SyRS-114 | SwRS-003 | `ReceiptBL.cs:8573-8576` (`ShouldUpdateNumberOnSave`), Zitat `return isNewReceipt && data.IsOnlyForReportPr... |
|
||||
| StRS-007, StRS-052 | SyRS-007, SyRS-008 | SwRS-004 | `Centron.BL/Administration/Company/NumberGroupBL.cs:62-92`, Zitat `.Where(f => f.I3D == numberGroupObject.I... |
|
||||
| StRS-005 | SyRS-038 | SwRS-005 | `Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs:154-286` (`GetBasePrice`, Verzweigungen `:169`, `... |
|
||||
| StRS-005 | SyRS-038 | SwRS-006 | `ReceiptItemPriceBL.cs:235-257`, Zitat `case SpecialPriceKind.SurchargePurchasePrice: basePrice = purchaseB... |
|
||||
| StRS-014 | SyRS-116 | SwRS-007 | `Centron.BL/Sales/Receipts/Internal/ReceiptProvisionBL.cs:579-582` (`CalculateProvisionAmount`), Zitat `var... |
|
||||
| StRS-007, StRS-052 | SyRS-007 | SwRS-008 | `Centron.BL/Sales/Receipts/Offers/OfferSpecificLogic.cs:113`, Zitat `public NumberGroupEnum GetNumberGroup(... |
|
||||
| StRS-049 | SyRS-019 | SwRS-009 | `Centron.BL/Sales/Receipts/ReceiptCartBL.cs:903-916` (`SetCartDefaultProperties`), Zitat `newCart.IsCart = ... |
|
||||
| StRS-006 | SyRS-004 | SwRS-010 | `ReceiptBL.cs:1578-1638`, Zitat `createReceiptResult.Data.Receipt.BranchI3D = receiptsToForward.Count == 1 ... |
|
||||
| StRS-007, StRS-052 | SyRS-007 | SwRS-011 | `Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs:104-141`, Zitat `if (receiptNetPrice == 0) { … ... |
|
||||
| StRS-006, StRS-009 | SyRS-005, SyRS-009 | SwRS-012 | `Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:143-187` (`CancelInvoice`), Zitat `if (this._bookKe... |
|
||||
| StRS-006, StRS-009 | SyRS-005, SyRS-009 | SwRS-013 | `ReceiptInvoiceBL.cs:86-141` (`FixInvoice`) und `:273-291` (`CheckIfInvoiceIsFixed`) |
|
||||
| StRS-008 | SyRS-112 | SwRS-014 | `src/webservice/Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs:202-213` und `:215-230`, Zitat `var r... |
|
||||
| StRS-008 | SyRS-112 | SwRS-015 | `ReceiptPriceHelper.cs:232-242`, Zitat `return CalculateNetPrice(basePrice, precision, discount, currencyFa... |
|
||||
| StRS-008 | SyRS-112 | SwRS-016 | `ReceiptPriceHelper.cs:37-41`, Zitat `TaxPrice = taxPriceSum - (switzerlandRounding == false ? 0m : netPric... |
|
||||
| StRS-010 | SyRS-016 | SwRS-017 | `Centron.BL/Sales/Receipts/DownPayment/DownPaymentBL.cs:82-165`, Bedingung `:124-125`, Zitat `?? throw new ... |
|
||||
| StRS-016 | SyRS-022, SyRS-023 | SwRS-018 | `Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs:248-275` und `:277-303`, Zitat `case DunningLev... |
|
||||
| StRS-011, StRS-027 | SyRS-021 | SwRS-019 | `Centron.BL/Sales/Receipts/Internal/ReceiptContractHelperBL.cs:162-168` (`UsedContingent`), Zitat `this.Ses... |
|
||||
| StRS-025 | SyRS-017 | SwRS-020 | `DeliveryListSpecificLogic.cs:185, 188, 326` und `PickupListSpecificLogic.cs:195, 198, 312` |
|
||||
| StRS-024 | SyRS-032 | SwRS-021 | `SupplierOrderSpecificLogic.cs:683-686`, `SupplierDeliveryListSpecificLogic.cs:625-628`, `SupplierInvoiceSp... |
|
||||
| StRS-011, StRS-012, StRS-027 | SyRS-020, SyRS-021 | SwRS-022 | `src/backend/Centron.Interfaces/Sales/BillingCenter/Contracts/ContractCalculationKind.cs:7-18`, Typ `Contra... |
|
||||
| StRS-011, StRS-027 | SyRS-021 | SwRS-023 | `Centron.BL/Sales/Receipts/Internal/ReceiptContractHelperBL.cs:88-104` (`ThresholdContingent.ToBilling`), Z... |
|
||||
| StRS-011, StRS-012 | SyRS-020 | SwRS-024 | `Centron.BL/Sales/Receipts/ContractLists/ReceiptContractBL.cs:579-620` (`GetContractTodoDate`), Zitat `case... |
|
||||
| StRS-011, StRS-012 | SyRS-020 | SwRS-025 | `Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs:829-830`, Zitat `(filter.Calculation... |
|
||||
| StRS-013 | SyRS-037 | SwRS-026 | `Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs:94-101` (`SaveMasterDataList`), Zitat `i... |
|
||||
| StRS-013 | SyRS-037 | SwRS-027 | `Sales/CustomerAssets/Contracts/ClickContracts/DeviceClickCounterBL.cs:250-257` (`GetAndUpdateDeviceClickCo... |
|
||||
| StRS-007 | SyRS-070 | SwRS-028 | `Sales/Support/HelpdeskBL.cs:269-291` (`GetLoggedInUserShowHelpdeskRight`), Durchsetzung `:148-231`, Zitat ... |
|
||||
| StRS-007 | SyRS-070 | SwRS-029 | `Sales/Support/HelpdeskBL.cs:122-133` (`GetHelpdeskRequest`), Zitat `if (salesAreaI3Ds.Any() && salesAreaI3... |
|
||||
| StRS-026 | SyRS-033 | SwRS-030 | `Sales/Support/Escalation/EscalationBL.cs:393-398` (`CheckEskalationStage`), `:313-388` (`ShouldEscalated`)... |
|
||||
| StRS-005 | SyRS-038 | SwRS-031 | `Warehousing/ArticleVolumePricesBL.cs:88-97` (`GetVolumePrice`), Zitat `return volumePrices.OrderByDescendi... |
|
||||
| StRS-005 | SyRS-038 | SwRS-032 | `ReceiptItemPriceBL.cs:482-496` (`GetSellPriceForCustomer`), Zitat `switch (priceList ?? 0) { case 0: retur... |
|
||||
| StRS-008 | SyRS-111 | SwRS-033 | `Warehousing/TaxBL.cs:206-238` (`GetTaxRateForReceiptItem`), Zitat `bool previousTaxRateWasActiveForReceipt... |
|
||||
| StRS-025 | SyRS-017 | SwRS-034 | `Centron.DAO/Repositories/Warehousing/StockManagement/ArticleStockRepository.cs:122-145` und `:147-161`, Zi... |
|
||||
| StRS-024, StRS-025 | SyRS-120 | SwRS-035 | `Warehousing/StockManagement/ArticleStockBL.cs:74-148` (`UpdateArticlePurchasePrice`), Zitat `newPurchasePr... |
|
||||
| StRS-023 | SyRS-031 | SwRS-036 | `Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs:86-160` (Feld `_sqlArticle`), Zitat `INNER JOIN cv... |
|
||||
| — | SyRS-126 | SwRS-037 | `Centron.Interfaces/Production/ProductionOrderItemState.cs:7-22` und Mapping `Centron.DAO/Mappings/Producti... |
|
||||
| StRS-001, StRS-002 | SyRS-036 | SwRS-038 | `Accounts/AccountBL.cs:137-145` (`GetNewAccount`), Zitat `defaultAddress.Data.IsDefault = true;` / `default... |
|
||||
| — | SyRS-127 | SwRS-039 | `Accounts/Campaigns/CampaignBL.cs:421-452` (`CanEditCampaign`/`CanOpenCampaign`), Zitat `if (user == null \|... |
|
||||
| StRS-017 | SyRS-024, SyRS-025 | SwRS-040 | `Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs:342-360` (`CheckForCompleted`, Auf... |
|
||||
| StRS-017 | SyRS-024 | SwRS-041 | `OnlineBankingAccountTransactionsBL.cs:581-617` (`AutoCompleteSingleAccountTransaciton`), Bedingungen `:599... |
|
||||
| StRS-017 | SyRS-024 | SwRS-042 | `OnlineBankingAccountTransactionsBL.cs:1042-1086` (`BookAmountToAssignedInvoice`), `:1048-1050`, `:1058-106... |
|
||||
| StRS-015 | SyRS-115 | SwRS-043 | `Centron.BL/Sales/CashBooks/CashBookBL.cs:34-58` (`GetCurrentSequenceNumber`), Zuweisung `:22`, Zitat `if (... |
|
||||
| StRS-021 | SyRS-018 | SwRS-044 | `Centron.Gateway/DataExchange/BookKeeping/DatevAscii/BookKeepingExportDatevAscii.cs:936-978` (`ValidateDate... |
|
||||
| StRS-030 | SyRS-040 | SwRS-045 | `src/backend/Centron.BL/Statistics/SaleStatistics/CacheSalesStatisticsBL.cs:22-34`, Zitat `if (!loggedInUse... |
|
||||
| StRS-031 | SyRS-041 | SwRS-046 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs:46-50` (`AuthenticateInternal`) un... |
|
||||
| StRS-034, StRS-037 | SyRS-055 | SwRS-047 | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:644-664`, Zitat `var rights = this.Session.Adv... |
|
||||
| StRS-034 | SyRS-055 | SwRS-048 | `SSMS_DB_SCHEMA.sql:51267-51275`, Zitat `CREATE TABLE [dbo].[Sichtrus]( [I3D] [int] IDENTITY(1,1) NOT NULL,... |
|
||||
| StRS-031, StRS-036, StRS-051 | SyRS-041, SyRS-087 | SwRS-049 | `Administration/AccessTokens/AccessTokenBL.cs:457-488` (`GenerateSecureToken`, `HashToken`) |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-050 | `src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs:77-92` (`GetKeyAndIV`), Zitat `private const strin... |
|
||||
| StRS-033 | SyRS-073 | SwRS-051 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs:849-887` (`GetAvailableGuidelinesForEmployee`)... |
|
||||
| StRS-007, StRS-052 | SyRS-007, SyRS-069 | SwRS-052 | `Administration/Mandatory/MandatoryBL.cs:85-111`, Altvariante `:114-157`, Umschaltung `:57-80`, Zitat `WHER... |
|
||||
| StRS-051 | SyRS-131 | SwRS-053 | `SSMS_DB_SCHEMA.sql`, Tabelle `[dbo].[Personal]` ab Z. 4319, berechnete Spalte `IsActive`, Zitat `[IsActive... |
|
||||
| StRS-029 | SyRS-143 | SwRS-054 | `src/backend/Centron.Entities/Entities/ScheduleArea/Schedule.cs` (`ScheduleOld.HalfDay`/`HalfDayAM`/`HalfDa... |
|
||||
| StRS-011, StRS-029 | SyRS-109 | SwRS-055 | `src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs:43-47` und `:210-213`, Zitat `var handler = thi... |
|
||||
| StRS-029 | SyRS-125 | SwRS-056 | `SSMS_DB_SCHEMA.sql:47084-47112`, Tabelle `[dbo].[Projekt]`, Zitat `[Name] [varchar](50) NULL, [Beschreibun... |
|
||||
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-057 | `Centron.BL/EDI/SupplierEDI/SupplierEdiBL.cs:1364-1415` (`ApplyDistriToCentron`), `:1389-1395`, Zitat `case... |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-058 | `Centron.BL/WebServices/EDI/SupplierEDI/SupplierEdiConfigurationsWebServiceBL.cs:74` und `SupplierEdiBL.cs:... |
|
||||
| StRS-022, StRS-047 | SyRS-092 | SwRS-059 | `Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs:1033-1060`, Konstante `:64`, Zitat `private c... |
|
||||
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-060 | `Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs:174-185` (`CreateReference`), Typkonstant... |
|
||||
| StRS-050 | SyRS-140, SyRS-141 | SwRS-061 | `Centron.Common/DeveloperSecurity.cs:14,18,22,30-44` (`DeveloperSecurity.Email.ValidateAddress`), Zitat `pu... |
|
||||
| StRS-051 | SyRS-066, SyRS-131 | SwRS-062 | `Centron.BL/Administration/FileManagement/DirectoryBL.cs:300-308` (`CheckUserHasDirectoryRight`), Aufrufer ... |
|
||||
| StRS-036, StRS-051 | SyRS-066, SyRS-129 | SwRS-063 | `Centron.BL/Administration/FileManagement/SharedDocumentBL.cs:115-155` (`GenerateTokenForDocument`), Doppel... |
|
||||
| StRS-026 | SyRS-034 | SwRS-064 | `Centron.BL/CheckListArea/UpdateChecklistBL.cs:72-107` (`UpdateItemState`), `:109-125` (`UpdateParentItems`... |
|
||||
| StRS-006, StRS-030 | SyRS-040, SyRS-114 | SwRS-065 | `Centron.BL/ReportEngine/ReportDataBL.cs:194-236` und `:1633-1667` sowie `Centron.DAO/Reporting/NativeSqlDA... |
|
||||
| StRS-042 | SyRS-099 | SwRS-066 | `Centron.BL/Administration/Scripts/ScriptEngineBL.cs:118-123` (`DoExecuteScriptMethodSet`) und `:222-225` (... |
|
||||
| StRS-034, StRS-049 | SyRS-061 | SwRS-067 | `Centron.BL/Administration/Rights/UserRightsExt.cs:34-47`, Aufrufer `Sales/Support/HelpdeskBL.cs:472,478,48... |
|
||||
| StRS-037 | SyRS-075 | SwRS-068 | `Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs:19`, `:63-83` (`OnPreUpdate`), `:183-195` und `C... |
|
||||
| StRS-011, StRS-029 | SyRS-109 | SwRS-069 | `src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs:32-92`, `:23`, `:98-133`... |
|
||||
| — | SyRS-137 | SwRS-070 | `Centron.BL/GUI/Profiles/UiProfileBL.cs:46-61` (`SaveProfile`), Zitat `if (profile.IsGlobal && currentUser.... |
|
||||
| StRS-001, StRS-002 | SyRS-036 | SwRS-071 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/CrmMainViewModel.cs:2751-2873` (`CheckMandadatory`) - „if ... |
|
||||
| StRS-034 | SyRS-068 | SwRS-072 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:522-530` - „() => !CentronCache.Instance.CrmSetti... |
|
||||
| StRS-001, StRS-002 | SyRS-036 | SwRS-073 | — |
|
||||
| StRS-001, StRS-002 | SyRS-036 | SwRS-074 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/Settings/Requirements and preassignments/RequirementsAndPr... |
|
||||
| StRS-001 | SyRS-132 | SwRS-075 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/Hotline/HotlineManagementViewModel.cs:104-107` (`CanSave`)... |
|
||||
| StRS-034 | SyRS-055 | SwRS-076 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/Dsgvo/ManageOrderProcessingContractsViewModel.cs:124-131` ... |
|
||||
| StRS-005 | SyRS-038 | SwRS-077 | `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs:235-257`, Zitat `switch (specialPrice... |
|
||||
| StRS-019 | SyRS-117 | SwRS-078 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/SepaContracts/AddSepaContract/AddSepaContractViewModel.cs:... |
|
||||
| StRS-034 | SyRS-055 | SwRS-079 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/SepaContracts/ManageSepaContractsViewModel.cs:122-125` (`C... |
|
||||
| StRS-017 | SyRS-024 | SwRS-080 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/SepaContracts/AddSepaContract/AddSepaContractViewModel.cs:... |
|
||||
| — | — | SwRS-081 | `src/shared/Centron.Controls/AccountContracts/AccountContractDetailsViewModel.cs:328-357` - „this.CanSaveAc... |
|
||||
| StRS-009 | SyRS-011 | SwRS-082 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ReceiptViewModel.cs:2519-2540` - „if (this.IsReadOnly... |
|
||||
| StRS-034 | SyRS-077 | SwRS-083 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Suppliers/SupplierReceiptViewModel.cs:2721-2737` - „i... |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-084 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Settings/GLS/GlsSettingViewModel.cs:83,88-94` - „this... |
|
||||
| StRS-034 | SyRS-055 | SwRS-085 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Dashboard/**/*.cs` (20 Dateien, Volltextsuche ohne Tr... |
|
||||
| StRS-046 | SyRS-094 | SwRS-086 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ArticleSearch/SearchArticlesHelper.cs:109` |
|
||||
| StRS-007 | SyRS-070 | SwRS-087 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Provision/SchemaReceivers/ProvisionReceiverGridViewMo... |
|
||||
| StRS-021 | SyRS-018 | SwRS-088 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Suppliers/SupplierReceiptViewModel.cs:2721-2737` - „i... |
|
||||
| StRS-036, StRS-051 | SyRS-087 | SwRS-089 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/EditSharedDocumentLink/EditSharedDocumentLinkViewMode... |
|
||||
| StRS-025 | SyRS-030 | SwRS-090 | `SSMS_DB_SCHEMA.sql:10077-10116,58653-58720` - „[Barcode] [varchar](200) NULL," und „CREATE NONCLUSTERED IN... |
|
||||
| StRS-025 | SyRS-030 | SwRS-091 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ScanBarcodes/ScanBarcodesViewModel.cs:604-621` (`Show... |
|
||||
| StRS-046 | SyRS-094 | SwRS-092 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ContentImport/ContentImportViewModel.cs:83-89` (`Load... |
|
||||
| StRS-011, StRS-027 | SyRS-021 | SwRS-093 | `src/centron/Centron.WPF.UI/Modules/Finances/Contracts/ContractsManagementViewModel.cs:1669-1759` (`CheckCa... |
|
||||
| StRS-011, StRS-012 | SyRS-020 | SwRS-094 | `src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling/Pages/OverviewWizardPageViewModel.cs:1607-164... |
|
||||
| StRS-011, StRS-027 | SyRS-021 | SwRS-095 | `src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/ViewModel/FlatRateProjectViewModel.cs:952-966`... |
|
||||
| StRS-034 | SyRS-055 | SwRS-096 | `src/centron/Centron.WPF.UI/Modules/Finances/TimerBilling/Pages/TimerBillingTimerSelectionPageViewModel.cs:... |
|
||||
| StRS-003, StRS-016 | SyRS-022 | SwRS-097 | `src/centron/Centron.WPF.UI/Modules/Finances/Dunning/DunningOverviewViewModel.cs:145-160` (`Validate`) - „i... |
|
||||
| StRS-016 | SyRS-023 | SwRS-098 | `src/centron/Centron.WPF.UI/Modules/Finances/Opos/Pages/OposRunPreviewViewModel.cs:261-264` (`CanExecuteOpo... |
|
||||
| StRS-017 | SyRS-026 | SwRS-099 | `src/centron/Centron.WPF.UI/Modules/Finances/Payments/IncomingPayments/IncomingPaymentsViewModel.cs:545-556... |
|
||||
| StRS-013 | SyRS-037 | SwRS-100 | `src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter/DeviceClickCounterView.xaml.cs:31-46` (`New... |
|
||||
| StRS-030 | SyRS-040 | SwRS-101 | `src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluationOld/ContractEvaluationOldAppModuleController... |
|
||||
| — | SyRS-127 | SwRS-102 | `SSMS_DB_SCHEMA.sql:3441` (`CREATE TABLE [dbo].[Accounts]`) - „[AdvertisingNotAllowed] [bit] NOT NULL," |
|
||||
| StRS-007 | SyRS-070 | SwRS-103 | `src/centron/Centron.WPF.UI/Modules/Finances/Projects/ProjectsAppModuleControllerViewModel.cs:198-200`, Kon... |
|
||||
| StRS-013 | SyRS-037 | SwRS-104 | `src/centron/Centron.WPF.UI/Modules/Finances/MasterDataLists/MasterDataListViewModel.cs:771-776` (`CanChang... |
|
||||
| StRS-034 | SyRS-068 | SwRS-105 | `src/centron/Centron.WPF.UI/Modules/PLM/PlmAppModuleController.cs:13` - „public class PlmAppModuleControlle... |
|
||||
| StRS-025, StRS-030 | SyRS-133, SyRS-134 | SwRS-106 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/ViewModel/EditArticle/EditArticleView.Art... |
|
||||
| StRS-005 | SyRS-038 | SwRS-107 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/ViewModel/EditArticle/Article/ArticleVolu... |
|
||||
| StRS-025 | SyRS-029 | SwRS-108 | `src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory/ViewModels/WizardViewModels/ResultViewModel.cs:10... |
|
||||
| StRS-021 | SyRS-039 | SwRS-109 | `src/centron/Centron.WPF.UI/Modules/Warehousing/MaterialGroupManagement/Class/BranchRevenueAndExpenseAccoun... |
|
||||
| StRS-005 | SyRS-038 | SwRS-110 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/ViewModel/EditArticle/EditArticleViewMode... |
|
||||
| StRS-046 | SyRS-094, SyRS-128 | SwRS-111 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/ArticleImport/ArticleImportViewModel.cs:2... |
|
||||
| StRS-025 | SyRS-017 | SwRS-112 | `src/centron/Centron.WPF.UI/Modules/Warehousing/Commissions/CommissionOrders/CommissionOrderItemViewModel.c... |
|
||||
| — | SyRS-139 | SwRS-113 | `src/centron/Centron.WPF.UI/Modules/Warehousing/SearchArticle/ViewModel/SearchArticleViewModel.cs:130-144` |
|
||||
| StRS-025 | SyRS-030 | SwRS-114 | `src/centron/Centron.WPF.UI/Modules/Warehousing/BarcodeManagement/GenerateBarcode/ViewModel/GenerateBarcode... |
|
||||
| StRS-021 | SyRS-039 | SwRS-115 | `src/centron/Centron.WPF.UI/Modules/Warehousing/AccountSystems/BookKeepingAccountSystemViewModel.cs:112-125` |
|
||||
| StRS-001 | SyRS-132 | SwRS-116 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleUnitManagement/ViewModel/ArticleUnitManagementViewMo... |
|
||||
| StRS-024 | SyRS-003 | SwRS-117 | `src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments/OutgoingPaymentsViewModel.cs:750-795`, Me... |
|
||||
| StRS-007 | SyRS-008 | SwRS-118 | `src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments/OutgoingPaymentsViewModel.cs:799-827` |
|
||||
| StRS-023 | SyRS-031 | SwRS-119 | `src/centron/Centron.WPF.UI/Modules/Purchasing/Others/SuggestionQuantity.cs:117,125-131,165-169` - „var new... |
|
||||
| StRS-023 | SyRS-031 | SwRS-120 | `src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList/OrderSuggestionListViewModel.cs:956-959`... |
|
||||
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-121 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/SupplierEDI/SupplierEdiConfigurationViewModel.cs:340-346,4... |
|
||||
| StRS-034 | SyRS-068 | SwRS-122 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/Controller/ArticleManagementAppModuleCont... |
|
||||
| StRS-020 | SyRS-121 | SwRS-123 | `src/centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense/ViewModels/TransactionDetailViewModel.cs:157-1... |
|
||||
| StRS-026, StRS-027 | SyRS-034 | SwRS-124 | `src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/CloseHelpdesk/CloseHelpdeskHelper.cs:58` und `..... |
|
||||
| StRS-034 | SyRS-055 | SwRS-125 | `src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketList/TicketListViewModel.cs:897-908` |
|
||||
| StRS-026 | SyRS-124 | SwRS-126 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:786-815` (`GetDueDateFromPriority`) |
|
||||
| StRS-030 | SyRS-040 | SwRS-127 | `src/centron/Centron.WPF.UI/Modules/Helpdesk/Dashboard/RecordedTimes/TicketRecordedTimeContainerViewModel.c... |
|
||||
| StRS-011, StRS-029 | SyRS-109 | SwRS-128 | `src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEvents/ViewModels/ExpectedEventsMainViewModel.cs:111-1... |
|
||||
| StRS-026 | SyRS-033 | SwRS-129 | `src/centron/Centron.WPF.UI/Processes/Ticket/TicketProcessExecutor.cs:22-28` |
|
||||
| StRS-011, StRS-029 | SyRS-109 | SwRS-130 | `src/shared/Centron.Controls/TaskManagement/TaskManagmentViewModel.cs:240-298` |
|
||||
| StRS-026 | SyRS-034 | SwRS-131 | `src/backend/Centron.BL/WebServices/CheckListArea/CentronChecklistWebserviceBL.cs:155-190` - „if (checklist... |
|
||||
| StRS-026 | SyRS-034 | SwRS-132 | `src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskWebServiceBL.cs:283-308` - „var checklistsToCheck... |
|
||||
| StRS-036, StRS-051 | SyRS-087 | SwRS-133 | `src/centron/Centron.WPF.UI/Modules/Helpdesk/SendSelfCareForm/SendSelfCareViewModel.cs:167-221` |
|
||||
| StRS-028 | SyRS-035 | SwRS-134 | `SSMS_DB_SCHEMA.sql:4145-4179` - „CREATE UNIQUE CLUSTERED INDEX [CI_RMA_HelpdeskI3D] ON [dbo].[Rma]([Helpde... |
|
||||
| StRS-026, StRS-029 | SyRS-125, SyRS-144 | SwRS-135 | `src/centron/Centron.WPF.UI/Modules/ProjectManagement/EmployeeProjectWorkloadInfoViewModel.cs:242-252`, Met... |
|
||||
| StRS-034 | SyRS-055 | SwRS-136 | `src/centron/Centron.WPF.UI/Modules/Administration/RightsManagement/RightsManagmentViewModel.cs:867-871` (`... |
|
||||
| StRS-031 | SyRS-047 | SwRS-137 | `src/shared/Centron.Controls/EmployeeManagement/EmployeeManagementViewModel.cs:230`: `new DelegateCommand(t... |
|
||||
| StRS-052 | SyRS-069 | SwRS-138 | `src/centron/Centron.WPF.UI/Modules/Administration/MandatorManagement/MandatorManagementViewModel.cs:479-48... |
|
||||
| StRS-034 | SyRS-055 | SwRS-139 | `src/centron/Centron.WPF.UI/Modules/Administration/Settings/SettingsContainerViewModel.cs:209-215` (`LoadAl... |
|
||||
| StRS-032 | SyRS-051 | SwRS-140 | `src/centron/Centron.WPF.UI/Modules/Administration/Settings/AccessTokens/AccessTokenSettingsViewModel.cs:92... |
|
||||
| — | SyRS-147 | SwRS-141 | `src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityViewModel.cs:158-159`: `private... |
|
||||
| StRS-034 | SyRS-145 | SwRS-142 | `src/centron/Centron.WPF.UI/Modules/Administration/TextBlockManagement/TextBlockManagementView.ArtificialIn... |
|
||||
| StRS-034 | SyRS-068 | SwRS-143 | `src/centron/Centron.WPF.UI/Modules/Administration/MailTemplates/MailTemplatesAppModuleController.cs:46-52`... |
|
||||
| StRS-026 | SyRS-033 | SwRS-144 | `src/centron/Centron.WPF.UI/Modules/Administration/EscalationsSettings/EscalationType/EscalationTypeViewMod... |
|
||||
| StRS-027 | SyRS-122 | SwRS-145 | `src/centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates/ViewModels/HourlySurchargeRateViewM... |
|
||||
| StRS-018 | SyRS-027 | SwRS-146 | `src/centron/Centron.WPF.UI/Modules/Administration/ReceiptConditions/ReceiptConditionViewModel.cs:241-277`,... |
|
||||
| StRS-005 | SyRS-123 | SwRS-147 | `src/centron/Centron.WPF.UI/Modules/Administration/ServiceAndLeasing/ServiceLeasingViewModel.cs:176-231`, `... |
|
||||
| StRS-032 | SyRS-107 | SwRS-148 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:272` - bedingungslose Aufnahme des Controllers in... |
|
||||
| StRS-032 | SyRS-107 | SwRS-149 | `src/centron/Centron.WPF.UI/Modules/Administration/SqlManagers/SqlManagerViewModel.cs:76-100` (`DoExecuteQu... |
|
||||
| StRS-043 | SyRS-106 | SwRS-150 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:737-739` - Registrierung des Log-Moduls mit `Help... |
|
||||
| StRS-036 | SyRS-129 | SwRS-151 | `src/centron/Centron.WPF.UI/Modules/Administration/PdfSigning/PdfSigningSettingsViewModel.cs:109-167` (`DoA... |
|
||||
| StRS-001 | SyRS-132 | SwRS-152 | `src/centron/Centron.WPF.UI/Modules/Administration/CountryManagement/CountryViewModel.cs:67-79`: `if (previ... |
|
||||
| StRS-046 | SyRS-095 | SwRS-153 | `src/centron/Centron.WPF.UI/Modules/ExternalTool/ExternalToolPreviewViewModel.cs:113-135` (`StartExternalPr... |
|
||||
| StRS-033 | SyRS-043 | SwRS-154 | `src/centron/Centron.WPF.UI/Modules/ExternalTool/ExternalToolPreviewViewModel.cs:90-101`: `variableData.Web... |
|
||||
| StRS-046 | SyRS-095 | SwRS-155 | `SSMS_DB_SCHEMA.sql:39695 ff.`: `[Path] [varchar](400) NULL,` / `[CommandLineArguments] [varchar](400) NOT ... |
|
||||
| StRS-029 | SyRS-084 | SwRS-156 | `src/centron/Centron.WPF.UI/Modules/MyCentron/Telephony/TelephonyConnector.cs:85-89`: `var hasRights = Cent... |
|
||||
| StRS-029 | SyRS-084 | SwRS-157 | `src/centron/Centron.WPF.UI/Modules/Administration/Services/CentronNotifications/CentronNotificationsSettin... |
|
||||
| StRS-030 | SyRS-040 | SwRS-158 | `src/shared/Centron.Controls/Reports/ReportManagement/ViewModels/ReportEngine/MainReportWindowViewModel.cs:... |
|
||||
| StRS-021 | SyRS-018 | SwRS-159 | `src/centron/Centron.WPF.UI/Modules/DataExchange/BookKeeping/ExportKinds/BookKeepingExportDataCustomerRecei... |
|
||||
| StRS-021 | SyRS-018 | SwRS-160 | `src/centron/Centron.WPF.UI/Modules/DataExchange/DatevOnline2020/DatevOnlineViewModel.cs:706-722`: `if (str... |
|
||||
| StRS-019 | SyRS-118 | SwRS-161 | `src/centron/Centron.WPF.UI/Modules/DataExchange/PaymentTransactions/PaymentTransactionViewModel.cs:434-465... |
|
||||
| StRS-046 | SyRS-128 | SwRS-162 | `src/centron/Centron.WPF.UI/Modules/DataExchange/DataImport/AccountImport/IbanValidation.cs:18-32`: `return... |
|
||||
| StRS-021 | SyRS-018 | SwRS-163 | `src/centron/Centron.WPF.UI/Modules/DataExchange/DataExport/InvoiceExport/Exports/DataExportInvoiceAppModul... |
|
||||
| StRS-007 | SyRS-070 | SwRS-164 | `src/centron/Centron.WPF.UI/Modules/DataExchange/SupplierOrderPerBranch/SupplierOrderPerBranchViewModel.cs:... |
|
||||
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-165 | `src/centron/Centron.WPF.UI/Modules/DataExchange/DocuForm/Authorization/DocuFormTokenHelper.cs:36-68`: `ret... |
|
||||
| StRS-017 | SyRS-024 | SwRS-166 | `src/centron/Centron.WPF.UI/Modules/OnlineBanking/AccountTransactions/OnlineBankingAccountTransactionsViewM... |
|
||||
| StRS-030 | SyRS-040 | SwRS-167 | `src/centron/Centron.WPF.UI/Modules/Statistics/SaleStatistics/DataSources/StatisticDataSourceFactory.cs:27-... |
|
||||
| StRS-007 | SyRS-070 | SwRS-168 | `src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo/ManagementInfoViewModel.cs:186-192`: `activeB... |
|
||||
| StRS-011, StRS-027 | SyRS-021 | SwRS-169 | `src/centron/Centron.WPF.UI/Modules/Global/MSPLicensesCompare/Wizard/MSPComparerViewModel.cs:987-997`: `if ... |
|
||||
| StRS-007 | SyRS-070 | SwRS-170 | `src/shared/Centron.Controls/EmployeeAnalytics/EmployeeAnalyticsViewModel.cs:292`, `:337-341`: `if (this._o... |
|
||||
| StRS-011, StRS-027 | SyRS-021 | SwRS-171 | `src/shared/Centron.Controls/MyDay/Controls/MyDayWorkItemConflictHelper.cs:21-22` (`CalculateConflicts`): `... |
|
||||
| StRS-033 | SyRS-043 | SwRS-172 | `src/centron/Centron.WPF.UI/Modules/MyCentron/PersonalSettings/PasswordChange/PersonalPasswordChangeViewMod... |
|
||||
| StRS-030 | SyRS-040 | SwRS-173 | `src/shared/Centron.Controls/AutomateDashboard/AutomateDashboardViewModel.cs:63-101`: `Task.Run(() => SaveS... |
|
||||
| StRS-007 | SyRS-070 | SwRS-174 | `src/centron/Centron.WPF.UI/Modules/MyCentron/TodoList/TodoListViewModel.cs:234-235`, Filter `:319-321`: `t... |
|
||||
| StRS-031 | SyRS-146 | SwRS-175 | `src/centron/Centron.WPF.UI/Modules/MyCentron/Supremo/SupremoSettingsViewModel.cs:25`, `:30-33`: `this.Supr... |
|
||||
| StRS-033 | SyRS-073 | SwRS-176 | `src/shared/Centron.Controls/PasswordManager/PasswordGenerator.cs:58` (NET6+) bzw. `:60-63` (Legacy), `:68-... |
|
||||
| StRS-033 | SyRS-073 | SwRS-177 | `src/shared/Centron.Controls/PasswordManager/AutoType.cs:123-142` (`LoseFocus`): `if (IsWindowVisible(nextH... |
|
||||
| StRS-031, StRS-037 | SyRS-075, SyRS-146 | SwRS-178 | `src/shared/Centron.Controls/PasswordManager/AccessManagementViewModel.cs:588-596`, `:671-682`, `:686-693`,... |
|
||||
| StRS-033 | SyRS-073 | SwRS-179 | `src/backend/Centron.Interfaces/PasswordManager/PasswordManagerGuidelineRights.cs:5-16` |
|
||||
| StRS-031 | SyRS-047 | SwRS-180 | `src/shared/Centron.Core/GoogleAuthenticator/TwoFactorAuthenticator.cs:14`: `private const int _allowedTime... |
|
||||
| StRS-031 | SyRS-047 | SwRS-181 | `src/shared/Centron.Core/GoogleAuthenticator/TwoFactorAuthenticator.cs:61`, `:68-77`, `:23-24`: `var hmacsh... |
|
||||
| StRS-031 | SyRS-047 | SwRS-182 | `src/shared/Centron.Core/TotpAuth/Totp.cs:14`, `:34-42`; `src/shared/Centron.Core/TotpAuth/VerificationWind... |
|
||||
| StRS-037 | SyRS-075 | SwRS-183 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:533-535` - Modulgate `Sales.Customer.CustomerComm... |
|
||||
| StRS-034, StRS-044, StRS-045, StRS-046 | SyRS-090, SyRS-145 | SwRS-184 | `src/backend/Centron.BL/Administration/ArtificialIntelligence/ArtificialIntelligenceBL.cs:145-161` (`CheckA... |
|
||||
| StRS-011, StRS-029 | SyRS-109 | SwRS-185 | `src/webservice/Centron.Host/AspNetCore/HostedServices/MassUpdateService.cs:44-65`: `default: throw new Arg... |
|
||||
| StRS-011, StRS-029 | SyRS-109 | SwRS-186 | `src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs:250`, `:387-388`, `:403-407`, `:411-418` (analog `:446-4... |
|
||||
| — | SyRS-126 | SwRS-187 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:824-831` |
|
||||
| StRS-005 | SyRS-038 | SwRS-188 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ProjectPriceMatrix/ProjectPriceModel.cs:86-105` (`Upd... |
|
||||
| StRS-050 | SyRS-142 | SwRS-189 | `src/centron/Centron.WPF.UI/Modules/Calendar/Settings/Synchronization/CalendarSynchronizationSettingsViewMo... |
|
||||
| StRS-030 | SyRS-133 | SwRS-190 | `SSMS_DB_SCHEMA.sql:5673-5678`, `:5905-5915`: `[KostentraegerI3D] [int] NULL, [Nummer] [varchar](50) NULL, ... |
|
||||
| — | SyRS-119 | SwRS-191 | `src/centron/Centron.WPF.UI/Modules/Logistic/ShippingMethodSettings/ShippingMethodSettingsViewModel.cs:19`,... |
|
||||
| StRS-024 | SyRS-149 | SwRS-192 | `src/centron/Centron.WPF.UI/Modules/QM/Settings/QmSettingsViewModel.cs:69-80`, `:83-94`: `this.SupplierInvo... |
|
||||
| StRS-053 | SyRS-071 | SwRS-193 | `src/centron/Centron.WPF.UI/Modules/Global/VideoPortal/LicenseInfo.cs:23-31`, `:34-45`: `var iSeminarDirect... |
|
||||
| — | SyRS-135 | SwRS-194 | `src/shared/Centron.Controls/CustomProperties/CustomPropertiesGrid/CustomPropertiesGridViewModel.cs:219-239... |
|
||||
| StRS-007 | SyRS-070 | SwRS-195 | `src/shared/Centron.Controls/SalesAreaManagement/SalesAreasManagementViewModel.cs:106-124`, `:147-152`: `if... |
|
||||
| StRS-043 | SyRS-106 | SwRS-196 | `src/centron/Centron.WPF.UI/Modules/Global/NetworkDiagnostics/NetworkDiagnosticsViewModel.cs:778-794` (`Che... |
|
||||
| StRS-051 | SyRS-066 | SwRS-197 | `src/shared/Centron.Controls/CentronFileSystem/CentronFileSystemViewModel.cs:376-386` (`GetUserRights`), `:... |
|
||||
| StRS-024 | SyRS-130 | SwRS-198 | `src/shared/Centron.Controls/PdfScanning/PdfScanner.cs:61-99` (`TryFindValue`): `var normalizedNumber = Num... |
|
||||
| StRS-008 | SyRS-112 | SwRS-199 | `src/shared/Centron.Controls/PositionGrid/ViewModels/ReceiptArticleGridViewModel.cs:1392-1397` (`Recalculat... |
|
||||
| StRS-008 | SyRS-112, SyRS-113 | SwRS-200 | `src/shared/Centron.Controls/PositionGrid/ViewModels/ReceiptArticleGridViewModel.cs:1460-1478`: `var accoun... |
|
||||
| StRS-005 | SyRS-038 | SwRS-201 | `Modules/Finances/Receipts/PriceMatrix/PriceMatrixViewModel.cs:242-245`, `:259-265`, `:282-285`: `.Where(f ... |
|
||||
| StRS-046 | SyRS-128 | SwRS-202 | `Modules/Sales/SpecialArticleToContractImport/SpecialArticleToContractImportViewModel.cs:1073-1083`: `if (r... |
|
||||
| — | SyRS-137 | SwRS-203 | `Modules/Gui/Profiles/ManageUiProfileViewModel.cs:24-27`; `Modules/Gui/Profiles/ManageUiProfileView.xaml:37... |
|
||||
| StRS-006 | SyRS-114 | SwRS-204 | `Modules/Finances/Receipts/AutoPreview/LivePreviewViewModel.cs:25`, `:111-153`: `public const int RefreshIn... |
|
||||
| StRS-051 | SyRS-066 | SwRS-205 | `src/centron/Centron.WPF.UI/Start/CommandPalette/Provider/DocumentSearchCommandProvider.cs:81-96`, auskomme... |
|
||||
| StRS-034, StRS-053 | SyRS-068 | SwRS-206 | `Modules/ModuleRegistration.cs:916-951`: `this._parsedRightsCheck = ModuleRightsExpressionParser.Parse(righ... |
|
||||
| StRS-042 | SyRS-099 | SwRS-207 | `Services/Container/ClassContainerExtensions.cs:7-19`: `try { return action(instance); } finally { ClassCon... |
|
||||
| StRS-011, StRS-029 | SyRS-109 | SwRS-208 | `Processes/ProcessExecutor.cs:30-33`, `:59-68`: `return this._handlers[step.Kind].Invoke(this.Process, step... |
|
||||
| StRS-034 | SyRS-068 | SwRS-209 | `src/centron/Centron.WPF.UI.Extension/Modules/ICentronAppModuleController.cs:11-71` |
|
||||
| StRS-033, StRS-042 | SyRS-043, SyRS-148 | SwRS-210 | `src/shared/Centron.Controls.Preview/DataProviders/WebServiceConnectionProvider.cs:5-18`: `// this class is... |
|
||||
| StRS-031 | SyRS-041 | SwRS-211 | `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs:57-59` (`JwtAuthController... |
|
||||
| StRS-031 | SyRS-047 | SwRS-212 | `src/webservice/Centron.Controllers/Controllers/Unversioned/TwoFactorAuthController.cs:15-21` (`TwoFactorAu... |
|
||||
| StRS-034 | SyRS-055 | SwRS-213 | `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs:38-55` (`UserRightAuthoriz... |
|
||||
| StRS-034 | SyRS-055 | SwRS-214 | `src/webservice/Centron.Controllers/Authorization/AuthorizeAnyUserRightAttribute.cs:49-53` - „if (_required... |
|
||||
| StRS-043 | SyRS-080 | SwRS-215 | `src/webservice/Centron.Controllers/Configuration/GlobalExceptionFilter.cs:10-23` (`GlobalExceptionFilter.O... |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-216 | `src/webservice/Centron.Controllers/Utils/ApplicationGuidHelper.cs:38-46` (`ApplicationGuidHelper.DecryptTe... |
|
||||
| StRS-024 | SyRS-032 | SwRS-217 | `src/webservice/Centron.Controllers/Controllers/v1/Orders/OrdersController.cs:17-23` - „[Authorize] public ... |
|
||||
| StRS-007 | SyRS-070 | SwRS-218 | `src/webservice/Centron.Controllers/Controllers/v1/Customers/CustomersController.cs:14-139` - kein Authoriz... |
|
||||
| — | SyRS-137 | SwRS-219 | `src/webservice/Centron.Controllers/Controllers/v1/Administration/ThemesController.cs:14-128` - „[Authorize... |
|
||||
| StRS-032 | SyRS-051 | SwRS-220 | `src/backend/Centron.BL/WebServices/Administration/AccessTokens/AccessTokenWebServiceBL.cs:49` - „if (!isOw... |
|
||||
| StRS-034 | SyRS-055 | SwRS-221 | `src/webservice/Centron.Controllers/Controllers/v1/Tickets/HelpdeskTimersController.cs:15-16` - „[Authorize... |
|
||||
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-222 | `src/webservice/Centron.Controllers/Controllers/v1/Integrations/RmmController.cs:23-399` - kein Authorize-/... |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-223 | `src/webservice/Centron.Controllers/Controllers/v1/DataExchange/RmmConnectionSettingsController.cs:26-48` -... |
|
||||
| StRS-030 | SyRS-040 | SwRS-224 | `src/webservice/Centron.Controllers/Controllers/v1/Nexoware/NexowareController.cs:9-13`, `.../Nexoware/Stat... |
|
||||
| StRS-036, StRS-051 | SyRS-087 | SwRS-225 | `src/webservice/Centron.Controllers/Controllers/v1/WebAccount/WebAccountController.cs:11-165` - kein Author... |
|
||||
| StRS-034 | SyRS-062 | SwRS-226 | `src/webservice/Centron.Host/CentronHost.cs:280-281` - „routes.MapControllers().RequireAuthorization();" |
|
||||
| StRS-035 | SyRS-064 | SwRS-227 | `src/webservice/Centron.Host/CentronHost.cs:266` - „b.UseCors(d => d.AllowAnyOrigin().AllowAnyHeader().Allo... |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-228 | `src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs:104-121` (`TicketAuthenticationHandl... |
|
||||
| StRS-035 | SyRS-083 | SwRS-229 | `src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs:147-165` (`GetClientIpAddress`) - „v... |
|
||||
| StRS-034 | SyRS-062 | SwRS-230 | `src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Interceptors/AttributeBasedInterceptor.cs:10... |
|
||||
| StRS-043 | SyRS-080 | SwRS-231 | `src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Interceptors/TryCatchInterceptor.cs:19-39` (... |
|
||||
| StRS-034 | SyRS-062 | SwRS-232 | `src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Setup/ServiceInstanceProvider.cs:39` - „this... |
|
||||
| StRS-011, StRS-029 | SyRS-109 | SwRS-233 | `src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs:59-79` - „bool isEnabled... |
|
||||
| StRS-011, StRS-029 | SyRS-109 | SwRS-234 | `src/webservice/Centron.Host/AspNetCore/HostedServices/UpdateArticleAndMaterialGroupTaxRatesService.cs:38-6... |
|
||||
| StRS-048 | SyRS-096 | SwRS-235 | `src/webservice/Centron.Host/AspNetCore/HostedServices/TelemetryUploadService.cs:82-99,183-190` - „if (!too... |
|
||||
| StRS-036 | SyRS-065 | SwRS-236 | `src/webservice/Centron.Host/RealTimeServices/SecretKeyHandler.cs:11-30` - „var secretKey = authHeader[bear... |
|
||||
| StRS-036 | SyRS-065 | SwRS-237 | `src/webservice/Centron.Host/RealTimeServices/NotificationsHub.cs:14` - „[Authorize(Policy = \"SecretKey\")]" |
|
||||
| StRS-043 | SyRS-106 | SwRS-238 | `src/webservice/Centron.Host/AspNetCore/Logging/LoggingJwtBearerEvents.cs:11-46` - „logger.Warn(\"JWT token... |
|
||||
| StRS-046 | SyRS-088 | SwRS-239 | `src/webservice/Centron.Host/HelpPage/CentronHelpPage.cs:14-30` - „if (WebServiceConfigHelper.Current.Activ... |
|
||||
| StRS-042 | SyRS-081 | SwRS-240 | `src/webservice/Centron.Host/AspNetCore/WcfBridge/CentronWcfBridge.cs:35-81` - „var duplicateUris = methods... |
|
||||
| StRS-009 | SyRS-006 | SwRS-241 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Transactions.cs:41-49` - „... |
|
||||
| StRS-034 | SyRS-077 | SwRS-242 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.ArticleManagement.cs:88` -... |
|
||||
| StRS-017 | SyRS-026 | SwRS-243 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Finances.cs:38-47` - „var ... |
|
||||
| StRS-034 | SyRS-055 | SwRS-244 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Accounts.cs:595-618` - Auf... |
|
||||
| StRS-034 | SyRS-062 | SwRS-245 | `src/webservice/Centron.Host/Services/ICentronRestService.cs:289-296,340-343` - „[WebInvoke(Method = \"POST... |
|
||||
| StRS-026 | SyRS-034 | SwRS-246 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Helpdesk.cs:415-436` - „ig... |
|
||||
| StRS-029 | SyRS-084 | SwRS-247 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Chat.cs:31-32` - „if (this... |
|
||||
| StRS-031 | SyRS-079 | SwRS-248 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.RMM.cs:22-38` - „RiverDivo... |
|
||||
| StRS-052 | SyRS-069 | SwRS-249 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Statistics.cs:31-45` - Auf... |
|
||||
| StRS-034, StRS-043 | SyRS-080, SyRS-145 | SwRS-250 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.ArtificialIntelligence.cs:... |
|
||||
| StRS-053 | SyRS-072 | SwRS-251 | `src/webservice/Centron.Host/CentronHost.cs:99-110` - „this.TryLoadLicense();" / „// Progress only after th... |
|
||||
| StRS-042 | SyRS-099 | SwRS-252 | `src/webservice/Centron.Host.Console/Program.cs:19-60` - „HardwareIdGenerator.GetReplaceableHardwareId = ()... |
|
||||
| StRS-034, StRS-046 | SyRS-077, SyRS-082 | SwRS-253 | `src/webservice/Centron.WebServices.Core/Entities/BaseDTO.cs:5-10`; Beispiel `Entities/Accounts/AccountAddr... |
|
||||
| StRS-034 | SyRS-077 | SwRS-254 | `src/webservice/Centron.WebServices.Core/RestRequests/AccessTokens/AccessTokenLogsRequest.cs:8-22` - Aufbau... |
|
||||
| StRS-042 | SyRS-081 | SwRS-255 | `src/webservice/Centron.WebServices.Core/Connections/Serializer/ContentType.cs:53-64` - Auswahl der vier Au... |
|
||||
| StRS-031 | SyRS-041 | SwRS-256 | `src/webservice/Centron.WebServices.Core/HttpClients/ConfigurationClient.cs:10-18,28-50` - „Task<Authentica... |
|
||||
| StRS-046 | SyRS-082 | SwRS-257 | `src/webservice/Centron.WebServices.Core/Messages/StatusCode.cs:11-16` - genau drei Statuswerte |
|
||||
| StRS-032 | SyRS-052 | SwRS-258 | `src/webservice/Centron.WebServices.Core/Interception/Interceptors/AuthenticateAttribute.cs:8-27` - drei Ko... |
|
||||
| StRS-008 | SyRS-112 | SwRS-259 | `src/webservice/Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs:200-231` - „var withDiscount = rounde... |
|
||||
| StRS-042 | SyRS-081 | SwRS-260 | `src/webservice/Centron.WebServices.Core/MultiTargetingWorkaround/WebInvokeAttribute.cs:1-12` - eigener Typ... |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-261 | `src/webservice/c-entron.misc.ConnectionManager/Helpers/SqlHelper.cs:25-47`; `ConnectionManagerViewModel.cs... |
|
||||
| StRS-053 | SyRS-072 | SwRS-262 | `src/webservice/c-entron.misc.ConnectionManager/Dialogs/LicenseViewModel.cs:20-37` - Anzeige nur bei `HasLi... |
|
||||
| StRS-031 | SyRS-048 | SwRS-263 | `src/webservice/c-entron.misc.ConnectionManager/ConnectionManagerViewModel.cs:641-647` gegen `:637-641` - „... |
|
||||
| StRS-042 | SyRS-110 | SwRS-264 | `src/webservice/c-entron.misc.ConnectionManager/Dialogs/AdditionalServiceViewModel.cs:443-462` - Anlage ein... |
|
||||
| StRS-043 | SyRS-106 | SwRS-265 | `src/webservice/c-entron.misc.ConnectionManager/SQLServerCheckTool/SQLServerCheckToolViewModel.cs:100-155` ... |
|
||||
| StRS-017, StRS-044 | SyRS-091 | SwRS-266 | `src/apis/Centron.APIs.FinAPI/RestClient/RestClientBase.cs:137-156` (`GetJsonWebToken`) - „{ "client_id", t... |
|
||||
| StRS-022, StRS-047 | SyRS-092 | SwRS-267 | `src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs:303-341` (`ValidateValues`) - „if (String.IsNullOrWhi... |
|
||||
| StRS-045 | SyRS-093 | SwRS-268 | `src/apis/Centron.Api.Gls/CentronGlsLogic.cs:123-130` (`GetResponse`) - „if (isTest) { request.Credentials ... |
|
||||
| StRS-045 | SyRS-093 | SwRS-269 | `src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs:14-27` (Konstruktor) - „var tokenBytes = Encoding.... |
|
||||
| StRS-046 | SyRS-094 | SwRS-270 | `src/apis/Centron.APIs.ITscopeDataAccess/ITscopeApi.cs:23-27` (Konstruktor `ITscopeApi(string userMail, str... |
|
||||
| StRS-046 | SyRS-094 | SwRS-271 | `src/apis/Centron.APIs.IcecatDataAccess/IcecatApi.cs:17-21,57-68` (Konstruktor, `SendRequestAsync`) - „stri... |
|
||||
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-272 | `src/apis/Centron.APIs.CopDataAccess/SoapTemplates/SoapRequestFactory.cs:22-39` (`CreateGetArticlesRequest`... |
|
||||
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-273 | `src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs:1033-1039` - „result.CopPassword ... |
|
||||
| StRS-046 | SyRS-094 | SwRS-274 | `src/apis/Centron.APIs.EgisDataAccess/EgisApi.cs:23-37` (`CanSearchArticles`, `Create`) - „string.Equals(th... |
|
||||
| StRS-048 | SyRS-096 | SwRS-275 | `src/backend/Centron.BL/DataExchange/DocuForm/DocuFormApiSettingsBL.cs:29-33`, `:56-60`, Zitat `if (this._a... |
|
||||
| StRS-042 | SyRS-097 | SwRS-276 | `src/apis/Centron.APIs.FinAPI/RestClient/RestClientBase.cs:42-51` (Konstruktor, kein `Timeout`-Property ges... |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-277 | `src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs:41-46`; `src/apis/Centron.Api.Gls/C... |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-278 | `src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs:1026` - „result.ItScopeApiKey = s... |
|
||||
| — | SyRS-136 | SwRS-279 | `src/nexus/CentronNexus.Host/Program.cs:242` (Aktivierung der Lokalisierung) |
|
||||
| StRS-032 | SyRS-107 | SwRS-280 | `src/nexus/CentronNexus.Host/Program.cs:170-182` - „services.ConfigureWritable<CentronWebServiceConfig>(con... |
|
||||
| StRS-051 | SyRS-066 | SwRS-281 | `src/nexus/CentronNexus/Controllers/FilesController.cs:10-41` - „[Authorize]" / „_cachedDataService.AddTemp... |
|
||||
| StRS-034 | SyRS-060 | SwRS-282 | `src/nexus/CentronNexus/Shared/Auth/AuthService.cs:49-71` - „// We don't care about the web-service error i... |
|
||||
| StRS-007 | SyRS-070 | SwRS-283 | `src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs:33-63`; `src/nexus/CentronNexus/Shared/Auth/Tick... |
|
||||
| StRS-050 | SyRS-086 | SwRS-284 | `src/nexus/CentronNexus/Shared/CustomMiddleware/UseOutlookCookiePolicyMiddleware.cs:17-25`, Klasse `Outlook... |
|
||||
| StRS-034, StRS-053 | SyRS-062, SyRS-071 | SwRS-285 | `src/nexus/CentronNexus/Shared/Authorization/CentronAuthorization.cs:21`, `:34`, `:39`, `:100-108`, `:23-32` |
|
||||
| StRS-034, StRS-049 | SyRS-060, SyRS-061 | SwRS-286 | `src/nexus/CentronNexus/Shared/Authorization/PortAuthorization.cs:22-45`, `:50-71` - „if (http?.Connection.... |
|
||||
| StRS-026 | SyRS-033 | SwRS-287 | `src/nexus/CentronNexus/Shared/Services/TicketCacheService.cs:45`, `:59` |
|
||||
| StRS-034 | SyRS-076 | SwRS-288 | `src/nexus/CentronNexus/Shared/Layouts/` (sieben Layouts); Zuordnung `src/nexus/CentronNexus/Shared/Auth/Au... |
|
||||
| StRS-001 | SyRS-138, SyRS-139 | SwRS-289 | `src/nexus/CentronNexus/Shared/GlobalSearches/GlobalSearch.razor:100-124`, `:96`, `:107-111` - „this._searc... |
|
||||
| StRS-034 | SyRS-076 | SwRS-290 | `src/nexus/CentronNexus/Shared/Receipt/CalculatedPrices.razor:8`, `:26` - „var grossPrice = this.PricesByTa... |
|
||||
| StRS-032 | SyRS-107 | SwRS-291 | `src/nexus/CentronNexus/Shared/SetupWizard/{SetupWizard,SetupWizardWebService,SetupWizardSecretKey,SetupWiz... |
|
||||
| StRS-043 | SyRS-106 | SwRS-292 | `src/nexus/CentronNexus/Shared/Diagnostics/_Imports.razor:5-6` (zwei Attribute: `AuthorizeLoginUser` und `A... |
|
||||
| StRS-036, StRS-051 | SyRS-087 | SwRS-293 | `src/nexus/CentronNexus/DocumentSigning/DocumentSigningPage.razor:365-380`, `:521-527` - „private bool CanA... |
|
||||
| StRS-036, StRS-051 | SyRS-087 | SwRS-294 | `src/nexus/CentronNexus/DocumentSigning/DocumentSigningPage.razor:1-3`; `Office/SharedDocumentPage.razor:1-... |
|
||||
| StRS-053 | SyRS-071 | SwRS-295 | `src/nexus/CentronNexus/Management/TaskManagement/_imports.razor:5` (Lizenzattribut `ServiceBoardWebDev`) |
|
||||
| StRS-035 | SyRS-064 | SwRS-296 | `src/nexus/CentronNexus/Management/TicketPatterns/Components/SelfCareFormFieldEditPopup.razor:206-226` |
|
||||
| StRS-034 | SyRS-057 | SwRS-297 | `src/nexus/CentronNexus/Management/WebAccount/Dialog/WebAccountEditDialog.razor:326-342`, `:353-366` - „if ... |
|
||||
| StRS-034 | SyRS-068 | SwRS-298 | `src/nexus/CentronNexus/Management/Management.razor:13-35`, Methode `protected override async Task OnInitia... |
|
||||
| StRS-034 | SyRS-068 | SwRS-299 | `src/nexus/CentronNexus/ProductionOrderManagement/Pages/ProductionOrderOverView.razor:1`, `:138` - „private... |
|
||||
| StRS-026 | SyRS-034 | SwRS-300 | `src/nexus/CentronNexus/ServiceBoard/Shared/Common/TicketHeader.razor:289-305` - „<AuthorizeRightView Right... |
|
||||
| StRS-007 | SyRS-070 | SwRS-301 | `src/nexus/CentronNexus/ServiceBoard/CachedTicketList/CachedTicketListPage.razor:1-2`, `:2135-2139` - „_onl... |
|
||||
| StRS-050 | SyRS-086 | SwRS-302 | `src/nexus/CentronNexus/ServiceBoard/_Imports.razor:3-5`, Zitat `@attribute [AuthorizeLoginUser] @attribute... |
|
||||
| StRS-051 | SyRS-066 | SwRS-303 | `src/nexus/CentronNexus/ServiceBoard/TicketDocuments/TicketDocumentsPage.razor:22-26`, Zitat `<DocumentsLis... |
|
||||
| StRS-011, StRS-027 | SyRS-021 | SwRS-304 | `src/nexus/CentronNexus/ServiceBoard/Timerecords/Components/TimerDetails.razor:1327-1344` - „if (_helpdeskS... |
|
||||
| StRS-026 | SyRS-144 | SwRS-305 | `src/nexus/CentronNexus/ServiceBoard/Scheduler/SchedulerPage.razor:1-4` - „[AuthorizeRightId(UserRightsCons... |
|
||||
| StRS-035 | SyRS-064 | SwRS-306 | `src/nexus/CentronNexus/ServiceBoard/TicketWebForms/PublicWebFormPage.razor` (`LoadWebForm`) - „var isAvail... |
|
||||
| StRS-035 | SyRS-064 | SwRS-307 | `src/nexus/CentronNexus/ServiceBoard/TicketWebForms/PublicWebFormPage.razor` (`GenerateNewCaptcha`/`SubmitF... |
|
||||
| StRS-034 | SyRS-076 | SwRS-308 | je `@page` in `src/nexus/CentronNexus/ServiceBoard/Customers/**/*.razor:1` |
|
||||
| StRS-027, StRS-034 | SyRS-076, SyRS-122 | SwRS-309 | `src/nexus/CentronNexus/ServiceBoard/MyDay/MyDayService.cs:41-69` |
|
||||
| StRS-029 | SyRS-084 | SwRS-310 | `src/nexus/CentronNexus/ServiceBoard/PhoneCalls/CallsPage.razor:1-7` (gesamte Datei, gesamtes Modul) |
|
||||
| StRS-033 | SyRS-073 | SwRS-311 | `src/nexus/CentronNexus/ServiceBoard/PasswordManager/PasswordManager.razor:1-7` (gesamte Datei, gesamtes Mo... |
|
||||
| StRS-034, StRS-049 | SyRS-060, SyRS-061 | SwRS-312 | `src/nexus/CentronNexus/ServiceBoard/_Imports.razor:3-7` (drei Autorisierungsattribute und Layout) |
|
||||
| StRS-032 | SyRS-107 | SwRS-313 | `src/nexus/CentronNexus/Settings/ServiceBoard/RequiredFields/RequiredFields.razor:159-184`, `:198-217` |
|
||||
| StRS-050 | SyRS-140 | SwRS-314 | `src/nexus/CentronNexus/Settings/MailTemplates/MailTemplates.razor:114`, `:510`, `:540`, `:549`, `:557` |
|
||||
| StRS-031 | SyRS-041 | SwRS-315 | `src/nexus/CentronNexus/Settings/_Imports.razor:3`, Zitat `@attribute [AuthorizeRightId(UserRightsConst.Adm... |
|
||||
| StRS-043 | SyRS-080 | SwRS-316 | `src/nexus/CentronNexus/Utils/AsyncDisposableAction.cs:11-21` (`Guard.NotNull`, ungekapselte Ausführung der... |
|
||||
| StRS-049 | SyRS-019 | SwRS-317 | `src/nexus/CentronNexus/WebCart/Components/WebCartClearance.razor:33`, `:42`, `:67`, `:92`, `:101`, `:107`,... |
|
||||
| StRS-034, StRS-049 | SyRS-061 | SwRS-318 | `src/nexus/CentronNexus/WebCart/_Imports.razor:3-4` – Begründung: durchsetzende Anmeldetyp- und Portbindung... |
|
||||
| StRS-036, StRS-051 | SyRS-087 | SwRS-319 | `src/nexus/CentronNexus/WebOffer/WebReceiptOverview.razor` (`LoadReceipt`) – Prüfung auf `WebReceiptState` ... |
|
||||
| StRS-036 | SyRS-063 | SwRS-320 | `src/nexus/CentronNexus/WebOffer/WebReceiptOverview.razor:582`, `:836`, `:874`, `:939`, `:959`, `:1095`, `:... |
|
||||
| StRS-032 | SyRS-107 | SwRS-321 | `src/nexus/CentronNexus.Host/Program.cs:383-430` – Begründung: durchsetzende Stelle der Middleware-Reihenfo... |
|
||||
| StRS-050 | SyRS-086 | SwRS-322 | `src/nexus/CentronNexus.OutlookAddIn/_Imports.razor:8`, `:23` – Lizenzattribut und Layout, kein Login-Typ-A... |
|
||||
| StRS-051 | SyRS-066 | SwRS-323 | `src/nexus/CentronNexus.OutlookAddIn/Model/BlacklistedDirectories.cs` – acht deutschsprachige Namenskonstan... |
|
||||
| StRS-050 | SyRS-086 | SwRS-324 | `src/nexus/CentronNexus.OutlookAddIn/Customer/CustomerTab.razor:113`, `:295`, `:298` – Begründung: durchset... |
|
||||
| StRS-050 | SyRS-086 | SwRS-325 | `src/nexus/CentronNexus.OutlookAddIn/Belege/ReceiptSearchTab.razor:189`, `:294-297` – „GetReceiptByI3D(rece... |
|
||||
| StRS-050 | SyRS-086 | SwRS-326 | `src/nexus/CentronNexus.OutlookAddIn/Ticket/ManageTicketTab.razor:28`, `:50`, `:218`, `:244`, `:809` – Über... |
|
||||
| StRS-051 | SyRS-066 | SwRS-327 | `src/nexus/CentronNexus.OutlookAddIn/Document/DocumentsTab.razor:239-245` – „directory.ChildrenDirectories.... |
|
||||
| StRS-050 | SyRS-086 | SwRS-328 | `src/nexus/CentronNexus.OutlookAddIn/CRM/CrmActivityPage.razor:1`, `:8-10`, `:26-31` – Rendern von `CrmActi... |
|
||||
| StRS-050 | SyRS-086 | SwRS-329 | `src/nexus/CentronNexus.OutlookAddIn/Model/OfficeDialogUrl.cs` (`WithAddInContext`) – Begründung: durchsetz... |
|
||||
| StRS-038, StRS-041 | SyRS-102, SyRS-103 | SwRS-330 | `azure-blazor/security-pipeline.yaml:1-9` – „trigger: please_dont_get_triggered" mit Zeitplan 00:00 auf `ma... |
|
||||
| StRS-038 | SyRS-102 | SwRS-331 | `scripts/Centron.Scripts/Program.cs:18-325` - `Target("default", ["create-nuget-packages", "build-installer... |
|
||||
| StRS-039 | SyRS-100 | SwRS-332 | `scripts/Centron.Scripts/Program.cs:58-73` |
|
||||
| StRS-038 | SyRS-102 | SwRS-333 | `scripts/Scripts/Program.cs:30-56` |
|
||||
| StRS-039 | SyRS-100 | SwRS-334 | `scripts/Centron.Scripts/SignHelper.cs:8-24` - `RunSignTool(/*certificateFilePath, certificatePassword, */t... |
|
||||
| StRS-042 | SyRS-099 | SwRS-335 | `deployment/WixSharpInstaller/Program.cs:19-58` - `AllowSameVersionUpgrades = true` mit Begründungskommentar |
|
||||
| StRS-042 | SyRS-099 | SwRS-336 | `deployment/centron/CentronSetupProject/Product.wxs:5-11` - `REINSTALLMODE = amus`, `bind.FileVersion`, Upg... |
|
||||
| StRS-042 | SyRS-099 | SwRS-337 | `deployment/centron/CentronSetupProject/Product.wxs:25-26` - `<WixVariable Id="WixUIBannerBmp" Value="Image... |
|
||||
| StRS-042 | SyRS-099 | SwRS-338 | `deployment/centron/WebServiceSetupProject/Product.wxs:13` - per-Machine-Installationsumfang |
|
||||
| StRS-042 | SyRS-099 | SwRS-339 | `deployment/centron/WebServiceSetupProject/Product.wxs:19-20` - Banner- und Hintergrundbindung |
|
||||
| StRS-038 | SyRS-102 | SwRS-340 | `deployment/riverbird/version.txt` (gesamter Inhalt `11.1.2211`) |
|
||||
| StRS-042 | SyRS-101 | SwRS-341 | `docker/Dockerfile:1-31` - `ARG dx_license` und `echo "$dx_license" > $HOME/.config/DevExpress/DevExpress_L... |
|
||||
| StRS-042 | SyRS-101 | SwRS-342 | `docker/c-entron-api/Dockerfile:2-11` - `USER root` und `#ENTRYPOINT [ "/app/Centron.Host.Console" ]` |
|
||||
| StRS-042 | SyRS-101 | SwRS-343 | `docker/c-entron-webservice/Dockerfile:8-19` - `sed`-Ersetzung mit Warnkommentar |
|
||||
| StRS-040 | SyRS-105 | SwRS-344 | `docker/c-entron-regression-tests-db/Dockerfile` (gesamte Datei) |
|
||||
| StRS-042 | SyRS-101 | SwRS-345 | `docker/compose/compose.yaml:2-54` - Dienstdefinitionen, Startabhängigkeiten, Netzwerkzuordnung |
|
||||
| StRS-032 | SyRS-107 | SwRS-346 | `docker/compose/compose.yaml:7` - `MSSQL_SA_PASSWORD: SA!password` |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038, StRS-043 | SyRS-074, SyRS-080 | SwRS-347 | `docker/compose/appsettings.Production.json:24-41` - `"Notifications": { "SecretKey": "J+ImFI4YsgTyIpOk/ixa... |
|
||||
| StRS-042 | SyRS-101 | SwRS-348 | `docker/deploy/compose.yaml:3-47` gegen `docker/compose/compose.yaml:3-50` - abweichende Images, leere `HAR... |
|
||||
| StRS-038 | SyRS-102 | SwRS-349 | `azure/build-pipeline.yml:32-44` - `failTaskOnFailedTests: true` |
|
||||
| StRS-038 | SyRS-102 | SwRS-350 | `azure/build-pipeline2.yml:22-55` - Template-Einbindungen |
|
||||
| StRS-040 | SyRS-104 | SwRS-351 | `azure/tests-pipeline.yml:63-75` - gepinntes Datenbankimage und Bereitschaftsprüfung mit 30-Sekunden-Grenze |
|
||||
| StRS-042 | SyRS-101 | SwRS-352 | `azure/docker-pipeline.yml:30-70` - Tag- und Build-Arg-Definition der Push-Schritte |
|
||||
| StRS-041 | SyRS-103 | SwRS-353 | `azure-blazor/security-pipeline.yaml:1-8` - `trigger: - please_dont_get_triggered` und `cron: '0 0 * * *'` |
|
||||
| StRS-046 | SyRS-088 | SwRS-354 | `docs/README.md:50` - `- [Contract Billing RMM Article Logic](reference/receipts/contract-billing-rmm-artic... |
|
||||
| StRS-046 | SyRS-088 | SwRS-355 | — |
|
||||
| StRS-038 | — | SwRS-356 | `version.json` |
|
||||
| StRS-042 | SyRS-099 | SwRS-357 | `src/backend/Centron.Entities/Entities/BaseEntity.cs:6-14`, Zitat `public class BaseEntity : PersistedEntit... |
|
||||
| StRS-042 | SyRS-099 | SwRS-358 | `tests/Centron.Tests.EndToEnd/Infrastructure/Database.cs:68-151` (Skript-Engine mit `currentVersionOverride... |
|
||||
| StRS-037 | SyRS-075 | SwRS-359 | `src/backend/Centron.BL/Administration/Scripts/ScriptMethods/ScriptHelpers.cs:212-241` (`AddTableIfNotExists`) |
|
||||
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-360 | `src/webservice/Centron.Host/AspNetCore/HostedServices/EdiDownloadService.cs:21-23` und `:35-37`, Zitat `aw... |
|
||||
| StRS-005 | SyRS-038 | SwRS-361 | — |
|
||||
| — | SyRS-141 | SwRS-362 | — |
|
||||
| StRS-022, StRS-047 | SyRS-092 | SwRS-363 | — |
|
||||
| StRS-042 | SyRS-099 | SwRS-364 | — |
|
||||
| StRS-034 | SyRS-055 | SwRS-365 | `src/backend/Centron.BL/Administration/Scripts/ScriptMethods/ScriptHelpers.cs:93-125` (`AddRightIfNotExists... |
|
||||
| StRS-042 | SyRS-108 | SwRS-366 | `scripts/Centron.Scripts/Program.cs:277` - Target `build-web-service-linux` |
|
||||
| — | SyRS-136 | SwRS-367 | — |
|
||||
| StRS-011, StRS-029 | SyRS-109 | SwRS-368 | `src/webservice/Centron.Host/AspNetCore/HostedServices/DataQualityService.cs:181-184`, Zitat `return TimeSp... |
|
||||
| StRS-040 | SyRS-105 | SwRS-369 | `tests/Centron.Tests.EndToEnd/Infrastructure/EndToEndTest.cs:21-27`, `:67-73` - Snapshot-Rücksetzung im Kon... |
|
||||
| StRS-040 | SyRS-105 | SwRS-370 | `tests/Centron.Tests.EndToEnd/Infrastructure/Verifier/CentronVerifier.cs:33`, `:98-104` - Vergleich gegen E... |
|
||||
| StRS-040 | SyRS-105 | SwRS-371 | `tests/Centron.Tests.EndToEnd/TicketTests/Ticket103420/Ticket103420Test.cs` |
|
||||
| StRS-032 | SyRS-051 | SwRS-372 | `tests/backend/Centron.Tests.BL/Administration/AccessTokens/AccessTokenWebServiceBLTest.cs:47-72`, `:194-21... |
|
||||
| StRS-046 | SyRS-094 | SwRS-373 | `tests/apis/Centron.APIs.EgisDataAccess.Tests/EgisApiSearchRequirementsTests.cs:30-36` - Prüfung von `CanSe... |
|
||||
| StRS-008 | SyRS-113 | SwRS-374 | `tests/shared/Centron.Tests.Controls/PositionGrid/ReverseChargeThresholdCalculatorTests.cs:14-73` - Ein- un... |
|
||||
| StRS-034 | SyRS-077 | SwRS-375 | `tests/Centron.Tests.Integration/IntegrationTest.cs:13-37` - Login und Paging-Prüfung über `ICentronRestSer... |
|
||||
| StRS-034 | SyRS-062 | SwRS-376 | `tests/PlaywrightTests/Utilities/Auth.cs:9-37` - Anmeldung mit `admin` / `1` gegen `http://localhost:8050/a... |
|
||||
| StRS-038 | SyRS-102 | SwRS-377 | `Centron.sln:6-26` - Lösungsordner und WiX-Projekttyp-GUID |
|
||||
| StRS-041 | SyRS-103 | SwRS-378 | `Directory.Build.props:6-24` - `TreatWarningsAsErrors=true` und `<WarningsNotAsErrors>...;NU1901;NU1902;NU1... |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-379 | `nuget.config:6` - `<add key="DevExpress Online NuGet Server" value="https://nuget.devexpress.com/iani6kju4... |
|
||||
| StRS-035 | SyRS-054 | SwRS-380 | — |
|
||||
| StRS-039 | SyRS-100 | SwRS-381 | `version.json` - Basisversion, `assemblyVersion` bis zur Revision, Cloud-Build-Buildnummer, Releasemuster |
|
||||
| StRS-038 | SyRS-102 | SwRS-382 | `nuget.config:8` - `<add key="Nugets Directory" value="./nugets" />` |
|
||||
| StRS-041 | SyRS-103 | SwRS-383 | `src/centron/Centron.WPF.UI/Centron.WPF.UI.csproj:15-23` - `<Reference ... HintPath>` auf `assemblies/` |
|
||||
| StRS-042 | SyRS-099 | SwRS-384 | `SSMS_DB_SCHEMA.sql:1-12` - `CREATE DATABASE [CentronVOED2]` mit absoluten Dateipfaden und `Script Date: 11... |
|
||||
| StRS-034 | SyRS-055 | SwRS-385 | — |
|
||||
| StRS-039 | SyRS-100 | SwRS-386 | `.github/workflows/build.yml:313-334` - Prüfung `Get-AuthenticodeSignature(...).Status` ungleich `Valid` mi... |
|
||||
| StRS-038 | SyRS-102 | SwRS-387 | `.github/workflows/build.yml:367-431` - Zweigbedingung, Umgebung `SoftwareBuilds`, `id-token: write` |
|
||||
| StRS-038 | SyRS-102 | SwRS-388 | `.github/workflows/build.yml:367-431` - Zweigbedingung und Aufruf des wiederverwendbaren Workflows mit `id-... |
|
||||
| StRS-038 | SyRS-102 | SwRS-389 | `.github/workflows/build.yml:367-431` - Zweigbedingung, Umgebung und OIDC-Berechtigung des Nexus-Upload-Jobs |
|
||||
| StRS-040 | SyRS-104 | SwRS-390 | `.github/workflows/tests.yml:34-52` - Matrixdefinition mit `fail-fast: false` |
|
||||
| StRS-040 | SyRS-105 | SwRS-391 | `.github/workflows/regression-tests.yml:51-87` - Suchmuster und `throw` bei Treffer |
|
||||
| StRS-038 | SyRS-102 | SwRS-392 | `.github/workflows/cleanup-pr-artifacts.yml:3-6`, `:8-10` - Auslöser `pull_request_target`, `types: closed` |
|
||||
| StRS-040 | SyRS-105 | SwRS-393 | `.vscode/launch.json` - Pfad `bin/Debug/net8.0-windows/c-entron 2.0.dll` |
|
||||
| StRS-042 | SyRS-148 | SwRS-394 | `.editorconfig:16-31` - Schweregrad `warning` nur für die Feldbenennungsregel, `suggestion` für die übrigen |
|
||||
| StRS-033 | SyRS-073 | SwRS-395 | `Centron.sln:19` - Listung von `StrongNamingKeyFile.snk` als Solution Item |
|
||||
| StRS-038 | SyRS-102 | SwRS-396 | `.gitattributes:4` - `* text=auto eol=lf` |
|
||||
| StRS-042 | SyRS-148 | SwRS-397 | `Centron.sln.DotSettings` (einziger Eintrag: Registrierung von `Centron.Controls.Annotations`) |
|
||||
| StRS-042 | SyRS-101 | SwRS-398 | `.dockerignore` (gesamte Datei, 14 Zeilen mit `./src/centron/` und `**/app.config`) |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-399 | `Centron.Api.docuFORM/Helper/OAuthHelper.cs:11-39` (`GenerateRandomBase64String`, `GenerateCodeChallenge`) |
|
||||
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-400 | `src/webservice/Centron.Controllers/Controllers/v1/DataExchange/DocuFormApiSettingsController.cs:26-39` (`G... |
|
||||
| StRS-004 | SyRS-013 | SwRS-401 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Klasse ReceiptBL, Methode CheckIfCustomerLimitIsReached... |
|
||||
| StRS-004 | SyRS-013 | SwRS-402 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Klasse ReceiptBL, Methode CheckIfCustomerLimitIsReached... |
|
||||
| StRS-004 | SyRS-013 | SwRS-403 | src/backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs, Zeilen 315-316: `bool TakesPlaceInLimitCalc... |
|
||||
| StRS-016 | SyRS-022 | SwRS-404 | `src/centron/Centron.WPF.UI/Modules/Finances/Dunning/Pages/DunningCustomerSelectionViewModel.cs:466-469` (`... |
|
||||
|
||||
## 2 Vorwärtssicht: StRS nach unten
|
||||
|
||||
| StRS-ID | Titel | abgeleitete SyRS | abgeleitete SwRS (unmittelbar) |
|
||||
|---|---|---|---|
|
||||
| StRS-001 | Geschäftspartner als führende Kunden- und Lieferantenakte | SyRS-036, SyRS-132, SyRS-138 | SwRS-038 |
|
||||
| StRS-002 | [HYPOTHESE] Dublettenfreiheit im Geschäftspartnerstamm | SyRS-036 | — |
|
||||
| StRS-003 | Kundensperre und mahnstufenabhängige Belegsperre | SyRS-014, SyRS-059 | SwRS-097 |
|
||||
| StRS-004 | Kreditlimitüberwachung im Kundengeschäft | SyRS-013 | SwRS-401, SwRS-402, SwRS-403 |
|
||||
| StRS-005 | Nachvollziehbare Preis- und Konditionsfindung im Verkauf | SyRS-015, SyRS-038, SyRS-123 | SwRS-005 |
|
||||
| StRS-006 | Durchgängige Belegkette vom Angebot bis zur Gutschrift mit Mengenbindung | SyRS-001, SyRS-002, SyRS-004, SyRS-005, SyRS-114 | SwRS-002 |
|
||||
| StRS-007 | Eindeutige Belegnummern je Geschäftsvorfall und Filiale | SyRS-007, SyRS-008, SyRS-070 | SwRS-004 |
|
||||
| StRS-008 | Rechnungsstellung mit zum Belegdatum gültigem Steuersatz | SyRS-111, SyRS-112, SyRS-113 | SwRS-033 |
|
||||
| StRS-009 | Revisionssichere Rechnungsstornierung und Festschreibung | SyRS-006, SyRS-009, SyRS-010, SyRS-011 | SwRS-012 |
|
||||
| StRS-010 | Anzahlungsrechnung und Verrechnung in der Schlussrechnung | SyRS-016 | SwRS-017 |
|
||||
| StRS-011 | Abrechnung wiederkehrender Vertragsleistungen mit Kontingentbewirtschaftung | SyRS-020, SyRS-021, SyRS-109 | SwRS-022, SwRS-023 |
|
||||
| StRS-012 | Vertragslaufzeit, Verlängerung, Kündigung und Wiedervorlage | SyRS-020 | SwRS-024, SwRS-025 |
|
||||
| StRS-013 | Zählerbasierte Abrechnung technischer Anlagen auf einheitlichem Anlagenbestand | SyRS-037 | SwRS-026, SwRS-027 |
|
||||
| StRS-014 | Vertriebsprovision aus Beleggeschäft | SyRS-116 | SwRS-007 |
|
||||
| StRS-015 | Kassenbuchführung für Bargeschäfte | SyRS-012, SyRS-115 | SwRS-043 |
|
||||
| StRS-016 | Forderungsmanagement mit gestuftem Mahnverfahren | SyRS-022, SyRS-023 | SwRS-018 |
|
||||
| StRS-017 | Ausgleich offener Forderungen aus elektronischen Kontoauszügen | SyRS-024, SyRS-025, SyRS-026, SyRS-091 | SwRS-041 |
|
||||
| StRS-018 | [HYPOTHESE] Skontogewährung beim Ausgleich offener Forderungen | SyRS-027 | — |
|
||||
| StRS-019 | Forderungseinzug per SEPA-Lastschrift auf Grundlage erteilter Mandate | SyRS-117, SyRS-118 | SwRS-161 |
|
||||
| StRS-020 | Erstattung von Reisekosten und verauslagten Beträgen an Mitarbeiter | SyRS-121 | SwRS-123 |
|
||||
| StRS-021 | Übergabe der Geschäftsvorfälle an die Finanzbuchhaltung mit Exportnachweis | SyRS-018, SyRS-039 | SwRS-044 |
|
||||
| StRS-022 | Elektronische Rechnungsstellung im geforderten Rechnungsformat | SyRS-092 | SwRS-059 |
|
||||
| StRS-023 | Bedarfsgerechte Beschaffung über Bestellvorschläge | SyRS-031 | SwRS-119 |
|
||||
| StRS-024 | Lieferantenbelegkette und Fortschreibung des Einstandspreises | SyRS-003, SyRS-032, SyRS-130, SyRS-149 | SwRS-035 |
|
||||
| StRS-025 | Lagerbestandsführung, Seriennummernverfolgung, Kommissionierung und Inventur | SyRS-017, SyRS-028, SyRS-029, SyRS-030, SyRS-120, SyRS-134 | SwRS-034, SwRS-108 |
|
||||
| StRS-026 | Servicegeschäft: Ticketbearbeitung mit vereinbarter Reaktionszeit und Eskalation | SyRS-033, SyRS-034, SyRS-124, SyRS-144 | SwRS-030 |
|
||||
| StRS-027 | Erfassung erbrachter Serviceleistungen und deren Abrechnung | SyRS-021, SyRS-122 | SwRS-124 |
|
||||
| StRS-028 | Reklamations- und Werkstattabwicklung zum Servicevorgang | SyRS-035 | SwRS-134 |
|
||||
| StRS-029 | Projekt- und Aufgabensteuerung mit Wiedervorlagen und Vertretungsregelung | SyRS-084, SyRS-109, SyRS-125, SyRS-143 | SwRS-055 |
|
||||
| StRS-030 | Betriebswirtschaftliche Auswertung für Geschäftsleitung und Führungskräfte | SyRS-040, SyRS-067, SyRS-133 | SwRS-045 |
|
||||
| StRS-031 | Einheitliche, nachvollziehbare Verwaltung von Zugangsdaten und Geheimnissen | SyRS-041, SyRS-042, SyRS-046, SyRS-047, SyRS-048, SyRS-074, SyRS-079, SyRS-089, SyRS-146 | SwRS-216 |
|
||||
| StRS-032 | Geschützte Ablage der Zugangsdaten zu angebundenen Fremddiensten | SyRS-051, SyRS-052, SyRS-074, SyRS-107 | SwRS-084 |
|
||||
| StRS-033 | Keine Herausgabe hinterlegter Zugangsdaten an Bedienoberflächen | SyRS-043, SyRS-045, SyRS-073, SyRS-074 | SwRS-400 |
|
||||
| StRS-034 | Wirksame Trennung von Mitarbeiter- und Kundenzugang im Auslieferungszustand | SyRS-049, SyRS-053, SyRS-055, SyRS-056, SyRS-057, SyRS-060, SyRS-061, SyRS-062, SyRS-068, SyRS-076, SyRS-077, SyRS-078, SyRS-085, SyRS-145 | SwRS-226 |
|
||||
| StRS-035 | Missbrauchsschutz für anmeldefrei erreichbare Zugänge | SyRS-044, SyRS-054, SyRS-064, SyRS-083 | SwRS-307 |
|
||||
| StRS-036 | Befristete und nachvollziehbare Verweislinks für Dokumente und Angebote | SyRS-058, SyRS-063, SyRS-065, SyRS-087, SyRS-129 | SwRS-049 |
|
||||
| StRS-037 | Nachvollziehbarkeit sicherheitsrelevanter Vorgänge | SyRS-050, SyRS-075 | SwRS-047 |
|
||||
| StRS-038 | Eine verbindliche Kette für Erstellung und Auslieferung der Software | SyRS-074, SyRS-102 | SwRS-356 |
|
||||
| StRS-039 | Nachweisbare Signatur der ausgelieferten Programmdateien | SyRS-100 | — |
|
||||
| StRS-040 | Ausführung aller vorhandenen Testbestände in der verbindlichen Kette | SyRS-104, SyRS-105 | — |
|
||||
| StRS-041 | Sicherheitsanalyse als Voraussetzung der Freigabe | SyRS-103 | — |
|
||||
| StRS-042 | Betreibbare und aktualisierbare Installation | SyRS-081, SyRS-097, SyRS-099, SyRS-101, SyRS-108, SyRS-110, SyRS-148 | — |
|
||||
| StRS-043 | Betriebsdiagnose ohne Preisgabe von Sitzungs- und Zugangsdaten | SyRS-080, SyRS-106 | SwRS-238 |
|
||||
| StRS-044 | Anbindung des Zahlungsverkehrs an das Bankkonto | SyRS-090, SyRS-091 | SwRS-266 |
|
||||
| StRS-045 | Anbindung von Versanddienstleistern für die Sendungsabwicklung | SyRS-090, SyRS-093 | SwRS-268 |
|
||||
| StRS-046 | Anbindung von Lieferanten- und Produktdatenquellen für die Beschaffung | SyRS-082, SyRS-088, SyRS-090, SyRS-094, SyRS-095, SyRS-098, SyRS-128 | SwRS-373 |
|
||||
| StRS-047 | Elektronischer Austausch von Rechnungs- und Buchhaltungsdaten | SyRS-092 | SwRS-059, SwRS-363 |
|
||||
| StRS-048 | Übernahme von Gerätezählerständen für die nutzungsabhängige Abrechnung | SyRS-096 | SwRS-275 |
|
||||
| StRS-049 | Eigener Zugang für Kunden und Servicepartner | SyRS-019, SyRS-061 | SwRS-317 |
|
||||
| StRS-050 | Zusammenarbeit mit der Büroanwendung für Vorgänge aus der E-Mail heraus | SyRS-086, SyRS-140, SyRS-142 | SwRS-324 |
|
||||
| StRS-051 | Geschützte Ablage von Kunden- und Personaldokumenten | SyRS-066, SyRS-087, SyRS-131 | SwRS-062, SwRS-197 |
|
||||
| StRS-052 | [HYPOTHESE] Getrennte Datenhaltung mehrerer Mandanten | SyRS-007, SyRS-069 | SwRS-052, SwRS-249 |
|
||||
| StRS-053 | Abrechnung des Systems nach lizenzierten Benutzern und Funktionsbausteinen | SyRS-071, SyRS-072 | SwRS-206 |
|
||||
|
||||
## 3 Rückwärts- und Vorwärtssicht: SyRS
|
||||
|
||||
| SyRS-ID | Titel | begründende StRS | umsetzende SwRS |
|
||||
|---|---|---|---|
|
||||
| SyRS-001 | Belegartenkatalog und Trennung von Kunden- und Lieferantenbelegen | StRS-006 | SwRS-001, SwRS-002 |
|
||||
| SyRS-002 | Belegkette der Kundenseite vom Angebot bis zur Gutschrift | StRS-006 | SwRS-001, SwRS-002 |
|
||||
| SyRS-003 | Belegkette der Lieferantenseite als lineare Folge | StRS-024 | SwRS-117 |
|
||||
| SyRS-004 | Prüfung der Weiterverarbeitung und Verbot des Mischens von Kunden- und Lieferantenbelegen | StRS-006 | SwRS-002, SwRS-010 |
|
||||
| SyRS-005 | Belegzustandsmodell mit drei Zuständen ohne zentrale Zustandsmaschine | StRS-006 | SwRS-002, SwRS-012, SwRS-013 |
|
||||
| SyRS-006 | Belegversionierung statt Löschung | StRS-009 | SwRS-241 |
|
||||
| SyRS-007 | Vergabe der Belegnummer aus einem belegart- und filialbezogenen Nummernkreis | StRS-007, StRS-052 | SwRS-003, SwRS-004, SwRS-008, SwRS-011, SwRS-052 |
|
||||
| SyRS-008 | Eindeutigkeit der Belegnummer — derzeit nur durch optimistische Wiederholschleife hergestellt | StRS-007 | SwRS-004, SwRS-118 |
|
||||
| SyRS-009 | Vorbedingungen für das Stornieren einer Rechnung | StRS-009 | SwRS-012, SwRS-013 |
|
||||
| SyRS-010 | Festschreibung einer Rechnung als unumkehrbarer Zustand | StRS-009 | — |
|
||||
| SyRS-011 | Änderungssperre für festgeschriebene Rechnungen — derzeit nur im Windows-Client wirksam | StRS-009 | SwRS-082 |
|
||||
| SyRS-012 | Barrechnungen sind von der Weiterverarbeitung ausgenommen — Ausnahme wirkt nur in der Auswahl | StRS-015 | — |
|
||||
| SyRS-013 | Kreditlimitprüfung beim Speichern eines Kundenbelegs | StRS-004 | SwRS-401, SwRS-402, SwRS-403 |
|
||||
| SyRS-014 | Mahnstufenabhängige Sperre für neue Kundenbelege | StRS-003 | — |
|
||||
| SyRS-015 | Mindestpreisprüfung mit Überstimmung durch Zweitanmeldung | StRS-005 | — |
|
||||
| SyRS-016 | Anzahlungsrechnung und Verrechnung in der Schlussrechnung | StRS-010 | SwRS-017 |
|
||||
| SyRS-017 | Bestandswirkung ist an Lieferschein, Abholschein und Gutschrift gebunden | StRS-025 | SwRS-020, SwRS-034, SwRS-112 |
|
||||
| SyRS-018 | Buchhaltungsexport und dauerhafte Exportmarkierung des Belegs | StRS-021 | SwRS-044, SwRS-088, SwRS-159, SwRS-160, SwRS-163 |
|
||||
| SyRS-019 | Freigabekette des Web-Warenkorbs als Zustandsmaschine | StRS-049 | SwRS-009, SwRS-317 |
|
||||
| SyRS-020 | Vertragsrechnungen entstehen ausschließlich über das Abrechnungszentrum | StRS-011, StRS-012 | SwRS-022, SwRS-024, SwRS-025, SwRS-094 |
|
||||
| SyRS-021 | Vertragskontingente, Abrechnungsintervalle und Abrechnungsbedarf | StRS-011, StRS-027 | SwRS-019, SwRS-022, SwRS-023, SwRS-093, SwRS-095, SwRS-169, SwRS-171, SwRS-304 |
|
||||
| SyRS-022 | Mahnstufenmodell und schrittweise Fortschreibung im Mahnlauf | StRS-016 | SwRS-018, SwRS-097, SwRS-404 |
|
||||
| SyRS-023 | Offener Mahnbetrag, Zahlungstoleranz in Tagen und Mahnstopp | StRS-016 | SwRS-018, SwRS-098 |
|
||||
| SyRS-024 | Dreistufige Zuordnung einer Kontobewegung zu offenen Rechnungen | StRS-017 | SwRS-040, SwRS-041, SwRS-042, SwRS-080, SwRS-166 |
|
||||
| SyRS-025 | Zahlungstoleranz — dieselbe Regel mit zwei verschiedenen Vergleichsoperatoren | StRS-017 | SwRS-040 |
|
||||
| SyRS-026 | Buchung eines Zahlungsbetrags, Rücklastschrift und Schutz vor Doppelbuchung | StRS-017 | SwRS-099, SwRS-243 |
|
||||
| SyRS-027 | [HYPOTHESE] Skontoabzug beim Abgleich einer Zahlung mit einem offenen Posten | StRS-018 | SwRS-146 |
|
||||
| SyRS-028 | Zustandsmodell der Inventur mit zwei getrennten Zustandssträngen | StRS-025 | — |
|
||||
| SyRS-029 | Lagerabschluss der Inventur — abgeschlossenes Lager nimmt keine weitere Zählung auf | StRS-025 | SwRS-108 |
|
||||
| SyRS-030 | Seriennummernzustand als Träger der Stückverfolgung und der Inventurdifferenz | StRS-025 | SwRS-090, SwRS-091, SwRS-114 |
|
||||
| SyRS-031 | Ermittlung des Nachbestellbedarfs im Bestellvorschlag | StRS-023 | SwRS-036, SwRS-119, SwRS-120 |
|
||||
| SyRS-032 | Lieferantenbelege sind ohne Rechteprüfung änderbar | StRS-024 | SwRS-021, SwRS-217 |
|
||||
| SyRS-033 | Ticketstatus als datengetriebenes Modell mit genau einem Abschlussstatus | StRS-026 | SwRS-030, SwRS-129, SwRS-144, SwRS-287 |
|
||||
| SyRS-034 | Vorbedingungen für den Abschluss eines Tickets | StRS-026 | SwRS-064, SwRS-124, SwRS-131, SwRS-132, SwRS-246, SwRS-300 |
|
||||
| SyRS-035 | RMA-Vorgang je Ticket genau einmal, mit zwei getrennten Zustandsachsen je Position | StRS-028 | SwRS-134 |
|
||||
| SyRS-036 | Kunden- und Adressstamm: Pflichtanschrift, Sperrmerkmale und Löschschutz | StRS-001, StRS-002 | SwRS-038, SwRS-071, SwRS-073, SwRS-074 |
|
||||
| SyRS-037 | Stammblatt als Geräteakte mit monoton steigendem Zählerstand | StRS-013 | SwRS-026, SwRS-027, SwRS-100, SwRS-104 |
|
||||
| SyRS-038 | Preisfindung als Kaskade mit fester Rangfolge | StRS-005 | SwRS-005, SwRS-006, SwRS-031, SwRS-032, SwRS-077, SwRS-107, SwRS-110, SwRS-188, SwRS-201, SwRS-361 |
|
||||
| SyRS-039 | Kontenrahmen und Kontenfindung — Eindeutigkeitsregeln nur clientseitig durchgesetzt | StRS-021 | SwRS-109, SwRS-115 |
|
||||
| SyRS-040 | [HYPOTHESE] Rechteprüfung beim Erzeugen und Verwalten von Berichten | StRS-030 | SwRS-045, SwRS-065, SwRS-101, SwRS-127, SwRS-158, SwRS-167, SwRS-173, SwRS-224 |
|
||||
| SyRS-041 | Systemweite Wahl des Anmeldeverfahrens | StRS-031 | SwRS-046, SwRS-049, SwRS-211, SwRS-256, SwRS-315 |
|
||||
| SyRS-042 | Kein unbeabsichtigter lokaler Kennwortpfad bei aktivem Verzeichnisdienst | StRS-031 | — |
|
||||
| SyRS-043 | Speicherung von Anmeldekennwörtern mit Salz und Schlüsselstreckung | StRS-033 | SwRS-154, SwRS-172, SwRS-210 |
|
||||
| SyRS-044 | Begrenzung fehlgeschlagener Anmeldeversuche | StRS-035 | — |
|
||||
| SyRS-045 | Gesicherte Verbindung zum Verzeichnisdienst | StRS-033 | — |
|
||||
| SyRS-046 | Kontodeaktivierung und Beschäftigungsfenster als Anmeldeschranke | StRS-031 | — |
|
||||
| SyRS-047 | Zweiter Faktor auf allen Anmeldewegen | StRS-031 | SwRS-137, SwRS-180, SwRS-181, SwRS-182, SwRS-212 |
|
||||
| SyRS-048 | Gültigkeitsdauer und Bindungskontext des zweiten Faktors | StRS-031 | SwRS-263 |
|
||||
| SyRS-049 | Anwendungsbezogene Zugangsbeschränkung vor Sitzungsvergabe | StRS-034 | — |
|
||||
| SyRS-050 | Sitzungstickets mit anwendungsabhängiger Ablauffrist | StRS-037 | — |
|
||||
| SyRS-051 | Zugriffstoken mit erzwungenem Ablauf und begrenztem Geltungsbereich | StRS-032 | SwRS-140, SwRS-220, SwRS-372 |
|
||||
| SyRS-052 | Geltung der Anwendungsbeschränkung auch für Zugriffstoken | StRS-032 | SwRS-258 |
|
||||
| SyRS-053 | Vollständige Kennzeichnung unauthentifizierter Endpunkte | StRS-034 | — |
|
||||
| SyRS-054 | Transport- und Cookie-Sicherheit der Weboberflächen | StRS-035 | SwRS-380 |
|
||||
| SyRS-055 | Berechtigungsvergabe ausschließlich über Rechtegruppen | StRS-034 | SwRS-047, SwRS-048, SwRS-076, SwRS-079, SwRS-085, SwRS-096, SwRS-125, SwRS-136, SwRS-139, SwRS-213, SwRS-214, SwRS-221, SwRS-244, SwRS-365, SwRS-385 |
|
||||
| SyRS-056 | Einschränkende Rechte als eigene Kategorie im Rechtemodell | StRS-034 | — |
|
||||
| SyRS-057 | Einheitliches Berechtigungsmodell für Mitarbeiter- und Portalkonten | StRS-034 | SwRS-297 |
|
||||
| SyRS-058 | Vorrang zentraler Freigabeeinstellungen vor individueller Rechtevergabe | StRS-036 | — |
|
||||
| SyRS-059 | Wirksamkeitsfrist von Rechteänderungen | StRS-003 | — |
|
||||
| SyRS-060 | Trennung von Mitarbeiter- und Kundenzugang über den Anmeldetyp | StRS-034 | SwRS-282, SwRS-286, SwRS-312 |
|
||||
| SyRS-061 | Wirksame Netztrennung von Mitarbeiter- und Kundenportal | StRS-034, StRS-049 | SwRS-067, SwRS-286, SwRS-312, SwRS-318 |
|
||||
| SyRS-062 | Autorisierungspflicht als Vorgabe für alle Weboberflächenrouten | StRS-034 | SwRS-226, SwRS-230, SwRS-232, SwRS-245, SwRS-285, SwRS-376 |
|
||||
| SyRS-063 | Anonyme tokenbasierte Zugänge mit Ablauf, Einmaligkeit und Ratenbegrenzung | StRS-036 | SwRS-320 |
|
||||
| SyRS-064 | Serverseitiger Missbrauchsschutz öffentlicher Formulare | StRS-035 | SwRS-227, SwRS-296, SwRS-306, SwRS-307 |
|
||||
| SyRS-065 | Benutzerbezogene Authentifizierung der Echtzeitkanäle | StRS-036 | SwRS-236, SwRS-237 |
|
||||
| SyRS-066 | Durchgängige Zugriffsprüfung auf Dokumentverzeichnisse | StRS-051 | SwRS-062, SwRS-063, SwRS-197, SwRS-205, SwRS-281, SwRS-303, SwRS-323, SwRS-327 |
|
||||
| SyRS-067 | [HYPOTHESE] Rechteprüfung und Parametersicherheit der Berichtserzeugung | StRS-030 | — |
|
||||
| SyRS-068 | Modul- und Funktionsschranken des Clients als geschlossene Vorgabe | StRS-034 | SwRS-072, SwRS-105, SwRS-122, SwRS-143, SwRS-206, SwRS-209, SwRS-298, SwRS-299 |
|
||||
| SyRS-069 | Durchgängige Mandantentrennung als Systemeigenschaft | StRS-052 | SwRS-052, SwRS-138, SwRS-249 |
|
||||
| SyRS-070 | Filialbezogene Einschränkung von Sicht und Verwaltungsumfang | StRS-007 | SwRS-028, SwRS-029, SwRS-087, SwRS-103, SwRS-164, SwRS-168, SwRS-170, SwRS-174, SwRS-195, SwRS-218, SwRS-283, SwRS-301 |
|
||||
| SyRS-071 | Lizenzdurchsetzung bei Systemstart und bei jeder Anmeldung | StRS-053 | SwRS-193, SwRS-285, SwRS-295 |
|
||||
| SyRS-072 | Hardwaregebundene Lizenzprüfung ohne clientseitige Umgehung | StRS-053 | SwRS-251, SwRS-262 |
|
||||
| SyRS-073 | Geschützte Ablage des Masterschlüssels der Kennwortverwaltung | StRS-033 | SwRS-051, SwRS-176, SwRS-177, SwRS-179, SwRS-311, SwRS-395 |
|
||||
| SyRS-074 | Geheimnisverwaltung in Konfiguration, Auslieferung und Quellverwaltung | StRS-031, StRS-032, StRS-033, StRS-038 | SwRS-050, SwRS-058, SwRS-084, SwRS-216, SwRS-223, SwRS-228, SwRS-261, SwRS-277, SwRS-278, SwRS-347, SwRS-379, SwRS-399, SwRS-400 |
|
||||
| SyRS-075 | Vollständige Protokollierung sicherheitsrelevanter Vorgänge | StRS-037 | SwRS-068, SwRS-178, SwRS-183, SwRS-359 |
|
||||
| SyRS-076 | Mehrkanaliger Zugang zum Gesamtsystem | StRS-034 | SwRS-288, SwRS-290, SwRS-308, SwRS-309 |
|
||||
| SyRS-077 | Fail-closed-Vorgabe der REST-v1-Schnittstelle | StRS-034 | SwRS-083, SwRS-242, SwRS-253, SwRS-254, SwRS-375 |
|
||||
| SyRS-078 | Abweichendes, fail-open ausgelegtes Standardverhalten der Legacy-WCF-Brücke | StRS-034 | — |
|
||||
| SyRS-079 | Zwei gleichrangige Authentifizierungsschemata an der HTTP-Systemgrenze | StRS-031 | SwRS-248 |
|
||||
| SyRS-080 | Einheitliches Fehlerverhalten der Zugangskanäle nach außen | StRS-043 | SwRS-215, SwRS-231, SwRS-250, SwRS-316, SwRS-347 |
|
||||
| SyRS-081 | Transport- und Serialisierungsvarianten der Legacy-Schnittstelle | StRS-042 | SwRS-240, SwRS-255, SwRS-260 |
|
||||
| SyRS-082 | Nachrichtenrahmen und Statusausdruck der Legacy-Schnittstelle | StRS-046 | SwRS-253, SwRS-257 |
|
||||
| SyRS-083 | Herkunftsbeschränkung des Browserzugriffs (CORS) | StRS-035 | SwRS-229 |
|
||||
| SyRS-084 | Echtzeitkanal für Benachrichtigungen, Chat, Verfügbarkeit und Telefonie | StRS-029 | SwRS-156, SwRS-157, SwRS-247, SwRS-310 |
|
||||
| SyRS-085 | Trennung von Mitarbeiter- und Kundenzugang über getrennte Lauschports | StRS-034 | — |
|
||||
| SyRS-086 | Outlook-Anbindung als mitgehosteter Zugangskanal | StRS-050 | SwRS-284, SwRS-302, SwRS-322, SwRS-324, SwRS-325, SwRS-326, SwRS-328, SwRS-329 |
|
||||
| SyRS-087 | Anonyme, tokenbasierte Außenzugänge für Angebote, Dokumente und Webformulare | StRS-036, StRS-051 | SwRS-049, SwRS-089, SwRS-133, SwRS-225, SwRS-293, SwRS-294, SwRS-319 |
|
||||
| SyRS-088 | Bedingt aktivierbare Schnittstellendokumentation | StRS-046 | SwRS-239, SwRS-354, SwRS-355 |
|
||||
| SyRS-089 | Anonyme Auskunftsendpunkte vor der Anmeldung | StRS-031 | — |
|
||||
| SyRS-090 | Angebundene externe Systeme und ihre fachliche Leistung | StRS-044, StRS-045, StRS-046 | SwRS-057, SwRS-060, SwRS-121, SwRS-165, SwRS-184, SwRS-222, SwRS-272, SwRS-273, SwRS-360 |
|
||||
| SyRS-091 | Online-Banking-Anbindung finAPI mit Test-/Produktivumschaltung und Lizenzbindung | StRS-017, StRS-044 | SwRS-266 |
|
||||
| SyRS-092 | ebInterface als Exportformat ohne Netzwerkanbindung | StRS-022, StRS-047 | SwRS-059, SwRS-267, SwRS-363 |
|
||||
| SyRS-093 | Zwei parallele Versanddienstleisteranbindungen mit unterschiedlichen Mengengrenzen | StRS-045 | SwRS-268, SwRS-269 |
|
||||
| SyRS-094 | Externe Artikel- und Lieferantendatenquellen als austauschbare Suchanbieter | StRS-046 | SwRS-086, SwRS-092, SwRS-111, SwRS-270, SwRS-271, SwRS-274, SwRS-373 |
|
||||
| SyRS-095 | Serverseitige Ausführung der externen Datenbeschaffung | StRS-046 | SwRS-153, SwRS-155 |
|
||||
| SyRS-096 | Managed-Print-Anbindung docuFORM für unbeaufsichtigten Betrieb | StRS-048 | SwRS-235, SwRS-275 |
|
||||
| SyRS-097 | Zeitgrenzen und Wiederholungsverhalten gegenüber externen Systemen | StRS-042 | SwRS-276 |
|
||||
| SyRS-098 | Losgrößen und Drosselung bei Massenabfragen an Fremdsysteme | StRS-046 | — |
|
||||
| SyRS-099 | Auslieferung als Windows-Installationspakete und Windows-Dienst | StRS-042 | SwRS-066, SwRS-207, SwRS-252, SwRS-335, SwRS-336, SwRS-337, SwRS-338, SwRS-339, SwRS-357, SwRS-358, SwRS-364, SwRS-384 |
|
||||
| SyRS-100 | Nachgewiesene Codesignatur der ausgelieferten Artefakte | StRS-039 | SwRS-332, SwRS-334, SwRS-381, SwRS-386 |
|
||||
| SyRS-101 | Containerbetrieb als alternative Betriebsform | StRS-042 | SwRS-341, SwRS-342, SwRS-343, SwRS-345, SwRS-348, SwRS-352, SwRS-398 |
|
||||
| SyRS-102 | Zwei parallel betriebene Auslieferungsketten | StRS-038 | SwRS-330, SwRS-331, SwRS-333, SwRS-340, SwRS-349, SwRS-350, SwRS-377, SwRS-382, SwRS-387, SwRS-388, SwRS-389, SwRS-392, SwRS-396 |
|
||||
| SyRS-103 | Statische Sicherheits- und Abhängigkeitsanalyse als eigenständiger Prüflauf | StRS-041 | SwRS-330, SwRS-353, SwRS-378, SwRS-383 |
|
||||
| SyRS-104 | Umfang und Einbindung der automatisierten Prüfungen | StRS-040 | SwRS-351, SwRS-390 |
|
||||
| SyRS-105 | Reproduzierbare Testumgebung und Wirksamkeitssicherung der Vergleichstests | StRS-040 | SwRS-344, SwRS-369, SwRS-370, SwRS-371, SwRS-391, SwRS-393 |
|
||||
| SyRS-106 | Protokollierung und Diagnosezugang im Betrieb | StRS-043 | SwRS-150, SwRS-196, SwRS-238, SwRS-265, SwRS-292 |
|
||||
| SyRS-107 | Konfigurationsquellen und deren Schutzbedarf | StRS-032 | SwRS-148, SwRS-149, SwRS-280, SwRS-291, SwRS-313, SwRS-321, SwRS-346 |
|
||||
| SyRS-108 | Betriebsumgebung und Plattformbindung | StRS-042 | SwRS-366 |
|
||||
| SyRS-109 | Zeitgesteuerte Hintergrundverarbeitung als Betriebseigenschaft | StRS-011, StRS-029 | SwRS-055, SwRS-069, SwRS-128, SwRS-130, SwRS-185, SwRS-186, SwRS-208, SwRS-233, SwRS-234, SwRS-368 |
|
||||
| SyRS-110 | [HYPOTHESE] Einschränkung des Mehrinstanzbetriebs durch prozesslokale Zustände | StRS-042 | SwRS-264 |
|
||||
| SyRS-111 | Ermittlung des gültigen Steuersatzes am Beleg | StRS-008 | SwRS-033 |
|
||||
| SyRS-112 | Positions- und Belegsummenbildung mit festgelegter Rundungsreihenfolge | StRS-008 | SwRS-014, SwRS-015, SwRS-016, SwRS-199, SwRS-200, SwRS-259 |
|
||||
| SyRS-113 | Reverse-Charge-Behandlung am Beleg | StRS-008 | SwRS-200, SwRS-374 |
|
||||
| SyRS-114 | Belegvorschau ohne Nummernverbrauch und Belegausgabewege | StRS-006 | SwRS-003, SwRS-065, SwRS-204 |
|
||||
| SyRS-115 | Kassenbuchführung für Bargeschäfte | StRS-015 | SwRS-043 |
|
||||
| SyRS-116 | Provisionsermittlung am Beleg | StRS-014 | SwRS-007 |
|
||||
| SyRS-117 | SEPA-Mandatsverwaltung und Mandatslebenszyklus | StRS-019 | SwRS-078 |
|
||||
| SyRS-118 | SEPA-Lastschriftlauf mit Prüfung der Einzugsdaten und Rücknahme | StRS-019 | SwRS-161 |
|
||||
| SyRS-119 | [HYPOTHESE] Versandkostenermittlung über die Gewichtsstaffel | — | SwRS-191 |
|
||||
| SyRS-120 | Lagerbewertung und Fortschreibung des Einstandspreises | StRS-025 | SwRS-035 |
|
||||
| SyRS-121 | Reisekostenabwicklung und deren Genehmigung | StRS-020 | SwRS-123 |
|
||||
| SyRS-122 | Erfassung von Arbeitszeiten mit Zuschlagsermittlung | StRS-027 | SwRS-145, SwRS-309 |
|
||||
| SyRS-123 | Leasing- und Servicekonditionen | StRS-005 | SwRS-147 |
|
||||
| SyRS-124 | Servicezeiten und Reaktionsfristen (SLA) | StRS-026 | SwRS-126 |
|
||||
| SyRS-125 | Projektverwaltung sowie Projekt- und Kapazitätsübersicht | StRS-029 | SwRS-056, SwRS-135 |
|
||||
| SyRS-126 | Produktionsauftragsverwaltung | — | SwRS-037, SwRS-187 |
|
||||
| SyRS-127 | Kampagnenverwaltung und Werbesperre als Systemeigenschaft | — | SwRS-039, SwRS-102 |
|
||||
| SyRS-128 | Import von Vertragsartikeln und von Stammdaten | StRS-046 | SwRS-111, SwRS-162, SwRS-202 |
|
||||
| SyRS-129 | Elektronische Signatur von Belegen und Freigabedokumenten | StRS-036 | SwRS-063, SwRS-151 |
|
||||
| SyRS-130 | Automatische Belegerfassung durch Beleg-Scan und Zuordnung erkannter Werte | StRS-024 | SwRS-198 |
|
||||
| SyRS-131 | Mitarbeiterstamm als eigenständiger Stammdatenbestand | StRS-051 | SwRS-053, SwRS-062 |
|
||||
| SyRS-132 | Länder-, Mengeneinheiten- und Hotline-Stammdaten als eigenständige Referenzbestände | StRS-001 | SwRS-075, SwRS-116, SwRS-152 |
|
||||
| SyRS-133 | Kostenrechnungsstammdaten (Kostenträger und Kostenstellen) | StRS-030 | SwRS-106, SwRS-190 |
|
||||
| SyRS-134 | Qualität der Artikelstammdaten — Pflichtangaben und Eindeutigkeit | StRS-025 | SwRS-106 |
|
||||
| SyRS-135 | Kundenspezifische Zusatzfelder je Objektart mit Pflichtfeldsteuerung | — | SwRS-194 |
|
||||
| SyRS-136 | Mehrsprachigkeit der Bedienoberflächen | — | SwRS-279, SwRS-367 |
|
||||
| SyRS-137 | Erscheinungsbild und persönliche sowie globale Oberflächenprofile | — | SwRS-070, SwRS-203, SwRS-219 |
|
||||
| SyRS-138 | Übergreifende Suche in der Weboberfläche | StRS-001 | SwRS-289 |
|
||||
| SyRS-139 | [HYPOTHESE] Antwortzeitverhalten der Stammdatensuche | — | SwRS-113, SwRS-289 |
|
||||
| SyRS-140 | E-Mail-Versand und Verwaltung von Mailvorlagen | StRS-050 | SwRS-061, SwRS-314 |
|
||||
| SyRS-141 | Schutz vor unbeabsichtigtem E-Mail-Versand an Kunden aus Nicht-Produktivständen | — | SwRS-061, SwRS-362 |
|
||||
| SyRS-142 | Synchronisation mit externen Kalendern | StRS-050 | SwRS-189 |
|
||||
| SyRS-143 | Abwesenheits- und Urlaubsverwaltung | StRS-029 | SwRS-054 |
|
||||
| SyRS-144 | Einsatzplanung im Servicebetrieb | StRS-026 | SwRS-135, SwRS-305 |
|
||||
| SyRS-145 | KI-gestützte Datenänderung und Nutzung externer KI-Dienste | StRS-034 | SwRS-142, SwRS-184, SwRS-250 |
|
||||
| SyRS-146 | Fernwartungszugang | StRS-031 | SwRS-175, SwRS-178 |
|
||||
| SyRS-147 | Löschung personenbezogener Daten | — | SwRS-141 |
|
||||
| SyRS-148 | Einheitliche Codebasis über die Bedienoberflächen hinweg | StRS-042 | SwRS-210, SwRS-394, SwRS-397 |
|
||||
| SyRS-149 | Qualitätsmanagement-Meldegründe je Belegart | StRS-024 | SwRS-192 |
|
||||
|
||||
## 4 Anforderungen ohne durchgängige Verknüpfung
|
||||
|
||||
| ID | Befund | Titel |
|
||||
|---|---|---|
|
||||
| SwRS-081 | keine SyRS- und keine StRS-Verknüpfung | Versionierung und Schreibschutz von Lieferantenverträgen |
|
||||
| SyRS-119 | keine StRS-Verknüpfung | [HYPOTHESE] Versandkostenermittlung über die Gewichtsstaffel |
|
||||
| SyRS-126 | keine StRS-Verknüpfung | Produktionsauftragsverwaltung |
|
||||
| SyRS-127 | keine StRS-Verknüpfung | Kampagnenverwaltung und Werbesperre als Systemeigenschaft |
|
||||
| SyRS-135 | keine StRS-Verknüpfung | Kundenspezifische Zusatzfelder je Objektart mit Pflichtfeldsteuerung |
|
||||
| SyRS-136 | keine StRS-Verknüpfung | Mehrsprachigkeit der Bedienoberflächen |
|
||||
| SyRS-137 | keine StRS-Verknüpfung | Erscheinungsbild und persönliche sowie globale Oberflächenprofile |
|
||||
| SyRS-139 | keine StRS-Verknüpfung | [HYPOTHESE] Antwortzeitverhalten der Stammdatensuche |
|
||||
| SyRS-141 | keine StRS-Verknüpfung | Schutz vor unbeabsichtigtem E-Mail-Versand an Kunden aus Nicht-Produktivständen |
|
||||
| SyRS-147 | keine StRS-Verknüpfung | Löschung personenbezogener Daten |
|
||||
|
||||
+290
@@ -0,0 +1,290 @@
|
||||
# Messprotokoll – Versuch 02 (Agentengestützt) – Prompt-Version 03-A
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `Versuche/Versuch_02/02_Prompt.md`
|
||||
- **Prompt-Version:** 03-A (unverändert gegenüber dem ersten V2-Lauf)
|
||||
- **SHA-256 (Prompt):** `5946FC82C45E7A242A1F7367B56B008EE0F5C10373223D3500BCEF4716C76ECD`
|
||||
- **Startzeit:** 2026-08-31T13:09:18.6547798+02:00
|
||||
- **Endzeit:** 2026-08-31T16:56:35.8276426+02:00
|
||||
- **Dauer gesamt:** 03:47:17 Wanduhr (API: 17:20:30 – Summe nebenläufiger Anfragen;
|
||||
`duration_ms` = 316.873 ms erfasst den Gesamtlauf erkennbar nicht und wird nicht berichtet)
|
||||
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.663 versionierte Dateien)
|
||||
- **Codebasis-Commit:** `8a22d586` (dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfung vor dem Lauf ohne Treffer);
|
||||
Remote entkoppelt: ja
|
||||
- **Prompt-Repo-Commit:** `8a22d586`
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Skill-Version:** 9.2.0
|
||||
- **Werkzeugadapter:** Claude Code
|
||||
- **CLI-Version:** 2.1.251
|
||||
- **Modell (angefordert):** `claude-opus-5`
|
||||
- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 365.032.582 (91,9 %),
|
||||
**`claude-sonnet-5` 32.157.585 (8,1 %)**, `claude-haiku-4-5-20251001` 9.491 (0,002 %)
|
||||
- **Kontrolle Modell:** **VERLETZT** – siehe Abschnitt *Modellbedingung* unten
|
||||
- **Effort:** `medium` (per `--effort` gesetzt; abweichend vom ersten V2-Lauf, der auf `high` lief)
|
||||
- **Laufverzeichnis-ID:** `v9.2.0-da6a`
|
||||
- **Ablage:** `Iteration 2/claude-opus-5/custom/medium/`
|
||||
- **Parallele Läufe:** nein
|
||||
- **Agentenmodus:** `custom` (V2). Agentendefinitionen: `Versuche/Versuch_02/03_Agents.json`,
|
||||
SHA-256 `424DDD8398D8A6521D9B34AF5B221867C5643572B3821005C7E5E87954644170`, acht Rollen
|
||||
- **Delegationstiefe:** **`unverschachtelt`** – Kontrolle **bestanden**:
|
||||
`spawned_by_subagents` = 0, `max_depth` = 1
|
||||
- **Permission-/Sandbox-Modus:** `acceptEdits`
|
||||
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` plus 33er-Denylist
|
||||
- **Isolationsmechanismus:** kein `--safe-mode` (deaktiviert die Agentenrollen), stattdessen
|
||||
`--strict-mcp-config` plus `--disallowedTools Skill WebSearch WebFetch SlashCommand`
|
||||
- **Umgebungsprüfung (`custom`):** keine Hooks, Plugins, Output-Styles, Skills oder Agents im
|
||||
User-Profil vorgefunden
|
||||
- **Subagenten:** 56 gestartet, 56 abgeschlossen, 0 fehlgeschlagen, **0 abgewiesen**
|
||||
(`refused.concurrency_limit` = 0 – das Nebenläufigkeitslimit wurde nie erreicht)
|
||||
|
||||
## Iterationszuordnung
|
||||
|
||||
Der Lauf eröffnet **Iteration 2** in Versuch 02. Gegenüber dem ersten V2-Lauf
|
||||
(`Iteration 1/…/v9.1.0-0c39`) unterscheidet er sich in drei benannten Größen:
|
||||
|
||||
| Größe | Iteration 1 | Iteration 2 |
|
||||
|---|---|---|
|
||||
| Modell | `claude-sonnet-5` | `claude-opus-5` |
|
||||
| Effort | `high` | `medium` |
|
||||
| Delegationstiefe | `verschachtelt` (`02_Agents.json`) | `unverschachtelt` (`03_Agents.json`) |
|
||||
|
||||
Modell und Effort sind Ordnerebenen; die geänderte `--agents`-Datei ist eine geänderte
|
||||
Werkzeugkonfiguration und begründet die neue Iteration. **Ein Modellvergleich zwischen beiden
|
||||
Läufen ist wegen der drei gleichzeitig gewechselten Größen nicht zulässig.** Der Wechsel war
|
||||
durch das Modellkontingent erzwungen (siehe *Kontingent*).
|
||||
|
||||
## Modellbedingung – verletzt
|
||||
|
||||
`modelUsage` weist neben `claude-opus-5` das nicht angeforderte Modell `claude-sonnet-5` mit
|
||||
32.157.585 Tokens (8,1 % des Gesamtverbrauchs) aus. Die Auswertung der 56 persistierten
|
||||
Subagenten-Transkripte lokalisiert den Fall genau:
|
||||
|
||||
| Rolle | Subagenten auf `claude-sonnet-5` | Auftrag |
|
||||
|---|---:|---|
|
||||
| `faktenermittler` | 6 | sämtlich „Fakten OP-63 docuFORM" |
|
||||
| `swrs-autor` | 1 | „SwRS-399..400 docuFORM-Client" |
|
||||
| `modulinventar` | 1 | „OP-Inventar §2.4 rekonstruieren" |
|
||||
|
||||
49 der 56 Subagenten liefen auf `claude-opus-5`, 8 auf `claude-sonnet-5`. Auffällig ist die
|
||||
inhaltliche Konzentration: Sieben der acht Fälle betreffen denselben Gegenstand (docuFORM,
|
||||
offener Punkt 63), und der `faktenermittler` wurde dafür sechsmal beauftragt. Ob der
|
||||
Modellwechsel eine Folge wiederholter Beauftragung derselben Teilaufgabe ist oder eine davon
|
||||
unabhängige Zuweisung der CLI, ist aus den vorliegenden Daten **nicht** zu entscheiden.
|
||||
|
||||
Damit reiht sich der Fall in die zwei bereits dokumentierten Modellabweichungen aus Versuch 1
|
||||
ein (Fable-Subagenten auf `claude-opus-5[1m]`; 18,5 Mio. Opus-Tokens auf `claude-sonnet-5`).
|
||||
Der Befund bestätigt die Regel des Skills: `--model` bindet den Hauptagenten, nicht zuverlässig
|
||||
die Subagenten. **Für Modellvergleiche ist dieser Lauf nur mit ausdrücklichem Hinweis auf den
|
||||
8,1-Prozent-Anteil verwendbar.**
|
||||
|
||||
Der neue Umstand gegenüber Versuch 1: Weil CLI 2.1.251 die Subagenten-Transkripte einzeln
|
||||
persistiert, ist die Abweichung erstmals **rollen- und auftragsscharf** lokalisierbar statt nur
|
||||
als Summe in `modelUsage` sichtbar.
|
||||
|
||||
## Zuständigkeitsbindung
|
||||
|
||||
| Rolle | Aufrufe |
|
||||
|---|---:|
|
||||
| `faktenermittler` | 27 |
|
||||
| `swrs-autor` | 11 |
|
||||
| `syrs-autor` | 6 |
|
||||
| `modulinventar` | 5 |
|
||||
| `strs-autor` | 3 |
|
||||
| `belegpruefer` | 2 |
|
||||
| `konsistenzpruefer` | 1 |
|
||||
| `iso29148-orchestrator` | 1 |
|
||||
| **Summe** | **56** |
|
||||
|
||||
**Alle acht gebundenen Rollen eingesetzt, und kein einziger Aufruf an einen eingebauten Typ.**
|
||||
Das ist der deutlichste Unterschied zum ersten V2-Lauf, in dem 16 von 86 Starts (18,6 %) an
|
||||
`general-purpose` und `Explore` gingen – davon 12 an der Traceability-Anreicherung (Schritt 6),
|
||||
für die die Bindungstabelle keinen Bearbeiter vorsieht.
|
||||
|
||||
**Die Bindungslücke bei Schritt 6 wurde bewusst nicht geschlossen**, um die Zahl der geänderten
|
||||
Größen klein zu halten. Sie ist damit eine Wiederholungsmessung – und das Ergebnis fällt anders
|
||||
aus: Dasselbe Loch führte hier nicht zum eingebauten Typ. Die `Traceability.md` (86 KB) entstand
|
||||
ohne einen einzigen ungebundenen Agenten. Ein Modelleffekt ist naheliegend, aber bei drei
|
||||
gleichzeitig gewechselten Größen **nicht belegt**.
|
||||
|
||||
**Delegationstiefe `unverschachtelt` hat gegriffen:** `spawned_by_subagents` = 0, `max_depth` = 1,
|
||||
56 Aufrufe gegen 56 Subagenten-Transkripte. Die Vorgabe wirkt allein über den Rollenprompt und
|
||||
war nicht technisch erzwungen.
|
||||
|
||||
**Nebenbefund:** `refused.concurrency_limit` = 0. Der erste V2-Lauf hatte 72 Absagen bei 86
|
||||
Starts – der Agent wollte dort weit stärker parallelisieren, als das Werkzeug zuließ. Ohne
|
||||
Weiterdelegation und mit gröberem Zuschnitt tritt das Limit nicht mehr auf.
|
||||
|
||||
## Verbrauch
|
||||
|
||||
### Hauptagent (`usage`)
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Input-Tokens | 20 |
|
||||
| Output-Tokens | 20.168 (davon 1.033 Thinking-Tokens) |
|
||||
| Cache-Write-Tokens | 35.850 |
|
||||
| Cache-Read-Tokens | 7.384.969 |
|
||||
| Agent-Turns | 10 |
|
||||
|
||||
### Gesamtlauf inkl. Subagenten (`modelUsage`)
|
||||
| Messgröße | `claude-opus-5` | `claude-sonnet-5` | `claude-haiku-4-5` | Summe |
|
||||
|---|---:|---:|---:|---:|
|
||||
| Input-Tokens | 287.449 | 722 | 9.465 | 297.636 |
|
||||
| Output-Tokens | 5.515.994 | 253.366 | 26 | 5.769.386 |
|
||||
| Cache-Write-Tokens | 18.031.138 | 811.833 | 0 | 18.842.971 |
|
||||
| Cache-Read-Tokens | 341.198.001 | 31.091.664 | 0 | 372.289.665 |
|
||||
| **Tokens gesamt** | **365.032.582** | **32.157.585** | **9.491** | **397.199.658** |
|
||||
|
||||
**Tokens gesamt: 397.199.658.** 93,7 % davon sind Cache-Reads.
|
||||
|
||||
## Kontingent
|
||||
|
||||
Der Lauf wurde gestartet, um zu prüfen, ob die Zelle `claude-opus-5 / custom` innerhalb der
|
||||
43 % des Modellkontingents machbar ist, die der Sonnet-Lauf verbraucht hatte. **Sie ist es
|
||||
nicht.**
|
||||
|
||||
Zu Listenpreisen (Opus 5: $5/$25 je Mio. Input/Output; Cache-Write 1,25×, Cache-Read 0,1×;
|
||||
Sonnet 5: $2/$10) kostet dieser Lauf rund **$433** gegenüber **$146** des Sonnet-Laufs – das
|
||||
**2,97-fache**. Mit dem Sonnet-Lauf als Eichpunkt (43 % des Kontingents) entspricht das
|
||||
rund **128 % des Kontingents**. Das Kontingent ist damit überschritten.
|
||||
|
||||
Die Ursache ist nicht das Preisverhältnis allein (2,5×), sondern zusätzlich ein um 12,6 %
|
||||
höherer Tokenverbrauch – **trotz** `medium` statt `high`, **trotz** unterbundener
|
||||
Weiterdelegation und **trotz** deutlich weniger Agenten (56 statt 86). Der Verbrauch je Subagent
|
||||
lag bei rund 13,6 Mio. Transkript-Tokens gegenüber 7,0 Mio. beim Sonnet-Lauf. Opus zerlegt
|
||||
gröber und arbeitet jeden Ausschnitt tiefer aus; die beiden strukturellen Sparmaßnahmen wurden
|
||||
davon vollständig aufgezehrt.
|
||||
|
||||
**Für die Arbeit heißt das:** Die Zelle `claude-opus-5 / custom` ist unter dem verfügbaren
|
||||
Kontingent nicht wiederholbar messbar. Sie steht neben `claude-opus-5 / builtin / high` aus
|
||||
Versuch 1 als zweite Zelle, deren Grenze das Kontingent ist und nicht das Verfahren.
|
||||
|
||||
**Güte der Live-Schätzung.** Während des Laufs wurde der Verbrauch aus den Transkripten
|
||||
geschätzt und mit einem am Sonnet-Lauf gewonnenen Faktor korrigiert (Transkriptsumme ÷ 2,45).
|
||||
Die letzte Schätzung vor Laufende lautete 316 Mio. Tokens beziehungsweise 96 % des Kontingents;
|
||||
tatsächlich waren es 397 Mio. und 128 %. Der Faktor beträgt für diesen Lauf 1,95 statt 2,45 – er
|
||||
ist **nicht laufübergreifend stabil** und hängt vom Verhältnis Haupt- zu Subagenten-Nachrichten
|
||||
ab. Eine Live-Schätzung taugt damit zur Richtungsanzeige, nicht zur Budgetsteuerung.
|
||||
|
||||
## 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 | 53 | 8,7 % |
|
||||
| SyRS | 149 | 24,6 % |
|
||||
| SwRS | 404 | 66,7 % |
|
||||
| **Gesamt** | **606** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 222 | 36,6 % |
|
||||
| Sicherheit | 220 | 36,3 % |
|
||||
| Daten | 75 | 12,4 % |
|
||||
| nicht-funktional | 51 | 8,4 % |
|
||||
| Schnittstelle | 38 | 6,3 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 1.927 |
|
||||
| davon `PRIMÄR` | 1.674 (86,9 %) |
|
||||
| davon `SEKUNDÄR` | 180 (9,3 %) |
|
||||
| davon `KONTEXT` | 73 (3,8 %) |
|
||||
| Belege je Anforderung (Median) | 3,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 597 (98,5 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 442 | 72,9 % |
|
||||
| workaround | 104 | 17,2 % |
|
||||
| sonderfall | 35 | 5,8 % |
|
||||
| veraltet | 25 | 4,1 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 577 | 95,2 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 29 | 4,8 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 232 | 38,3 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 81 | 13,4 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (280 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 606 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 606 von 606 mit Tracelinks (100,0 %) |
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** erfolgreich (`is_error` = false, `subtype` = success, `stop_reason` = end_turn,
|
||||
`terminal_reason` = completed, Exitcode 0)
|
||||
- **Session-ID:** `8ada72a9-901a-4be3-915b-8ff0dfc21046`
|
||||
- **Permission-Denials:** **0**
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 56
|
||||
- **Subagenten-Prompts:** `_meta\subagenten.md`, 56 Aufrufe erfasst; Abgleich mit
|
||||
`spawned` − `spawned_by_subagents` = 56 **stimmt exakt**, 0 Absagen
|
||||
- **Gültigkeit:** **gültig mit Einschränkung** – alle sieben geforderten Dateien vorhanden,
|
||||
`Stderr.log` 0 Byte, Root unverändert; **die Modellbedingung ist jedoch verletzt** (8,1 %
|
||||
`claude-sonnet-5`)
|
||||
- **Erzeugte Dateien:** `SwRS.md` (1.045 KB), `SyRS.md` (510 KB), `StRS.md` (240 KB),
|
||||
`Analysebericht.md` (153 KB), `Traceability.md` (86 KB), `Hypothesen.md` (20 KB),
|
||||
`Glossar.md` (19 KB) – genau die sieben vorgegebenen, keine Ergänzungsdateien
|
||||
- **Root unverändert:** ja (`before.txt` und `after.txt` identisch, beide leer)
|
||||
|
||||
## Anmerkungen/Auffälligkeiten
|
||||
|
||||
**Vergleich mit dem ersten V2-Lauf** – wegen der drei gleichzeitig gewechselten Größen
|
||||
ausdrücklich **kein** Modellvergleich, sondern eine Gegenüberstellung zweier Bedingungen:
|
||||
|
||||
| Kenngröße | Iteration 1 (Sonnet/high/verschachtelt) | Iteration 2 (Opus/medium/unverschachtelt) |
|
||||
|---|---:|---:|
|
||||
| Anforderungen | 845 | **606** |
|
||||
| Verteilung StRS/SyRS/SwRS | 185 / 180 / 480 | 53 / 149 / 404 |
|
||||
| Belege gesamt | 1.086 | **1.927** |
|
||||
| Belege je Anforderung (Median) | 1,0 | **3,0** |
|
||||
| Anforderungen mit `PRIMÄR`-Beleg | 95,6 % | **98,5 %** |
|
||||
| Anforderungen ohne jeden Beleg | 9 | **0** |
|
||||
| Hypothesenanteil | 8,9 % | 4,8 % |
|
||||
| Konsolidierungskandidaten | 22,1 % | 38,3 % |
|
||||
| mit ISO-25010-Merkmal | 65,9 % | **13,4 %** |
|
||||
| Subagenten | 86 | 56 |
|
||||
| Tokens gesamt | 352.828.287 | 397.199.658 |
|
||||
| Wanduhrdauer | 03:07:16 | 03:47:17 |
|
||||
|
||||
Weniger Anforderungen, aber erheblich dichter belegt: 1.927 Belege auf 606 Anforderungen
|
||||
gegenüber 1.086 auf 845, Median 3 statt 1, und **kein einziger Regelverstoß** in der
|
||||
maschinellen Prüfung (der Sonnet-Lauf hatte 9 Anforderungen ohne Beleg).
|
||||
|
||||
**Deutliche Verschlechterung an einer Stelle:** Nur 13,4 % der Anforderungen tragen ein
|
||||
ISO-25010-Qualitätsmerkmal gegenüber 65,9 %. Der Anteil nicht-funktionaler Anforderungen ist
|
||||
zugleich von 14,6 % auf 8,4 % gefallen. Ob das an Modell, Effort oder Zerlegung liegt, ist mit
|
||||
einem Lauf nicht zu trennen.
|
||||
|
||||
**Die StRS-Ebene ist auffällig dünn:** 53 Anforderungen (8,7 %) gegenüber 185 (21,9 %). Der
|
||||
`strs-autor` wurde nur dreimal beauftragt, der `swrs-autor` elfmal. Die Ebenenverteilung bleibt
|
||||
damit auch mit getrennten Autorenrollen die instabilste Größe der Reihe – sie schwankte über
|
||||
alle Läufe von 92,7 % StRS bis 66,7 % SwRS.
|
||||
|
||||
**`num_turns` = 10** gegenüber 20 im ersten V2-Lauf, bei fast doppelter Wanduhrzeit je Turn. Der
|
||||
Hauptagent hat gröber orchestriert und je Turn mehr Subagenten gebündelt.
|
||||
|
||||
**Offen für den nächsten Lauf:** Die Bindungstabelle braucht die Zeile
|
||||
`Traceability-Anreicherung (Schritt 6) → iso29148-orchestrator`. Sie blieb in diesem Lauf
|
||||
absichtlich offen, um die Zahl der Änderungen zu begrenzen.
|
||||
+1
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
|
||||
+12837
File diff suppressed because it is too large
Load Diff
+65
@@ -0,0 +1,65 @@
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
|
||||
|
||||
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
|
||||
|
||||
### Verteilung über die Ebenen
|
||||
|
||||
| Ebene | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| StRS | 53 | 8,7 % |
|
||||
| SyRS | 149 | 24,6 % |
|
||||
| SwRS | 404 | 66,7 % |
|
||||
| **Gesamt** | **606** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 222 | 36,6 % |
|
||||
| Sicherheit | 220 | 36,3 % |
|
||||
| Daten | 75 | 12,4 % |
|
||||
| nicht-funktional | 51 | 8,4 % |
|
||||
| Schnittstelle | 38 | 6,3 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 1.927 |
|
||||
| davon `PRIMÄR` | 1.674 (86,9 %) |
|
||||
| davon `SEKUNDÄR` | 180 (9,3 %) |
|
||||
| davon `KONTEXT` | 73 (3,8 %) |
|
||||
| Belege je Anforderung (Median) | 3,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 597 (98,5 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 442 | 72,9 % |
|
||||
| workaround | 104 | 17,2 % |
|
||||
| sonderfall | 35 | 5,8 % |
|
||||
| veraltet | 25 | 4,1 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 577 | 95,2 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 29 | 4,8 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 232 | 38,3 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 81 | 13,4 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (280 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 606 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 606 von 606 mit Tracelinks (100,0 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+219
@@ -0,0 +1,219 @@
|
||||
# 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 und Suchen im Arbeitsverzeichnis, schreibgeschützte
|
||||
Kommandozeilenbefehle, das Schreiben von Ergebnisdateien im unten genannten Ausgabeverzeichnis
|
||||
sowie acht beigestellte Agentenrollen.
|
||||
Nicht verfügbar sind: externe Werkzeugserver, Webzugriff, Skills und Slash-Kommandos.
|
||||
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 und legen keine
|
||||
Ergebnisdateien an; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen bleiben
|
||||
deine Aufgabe. Die Bearbeiter delegieren nicht weiter — nur du beauftragst.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`c:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 2\claude-opus-5\custom\medium\02_Lauf_2026-08-31_130834_v9.2.0-da6a\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T16:56:35.8276426+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
0
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
$ErrorActionPreference = 'Continue'
|
||||
$root = 'c:\DEV\MasterArbeit\QuellCode\CentronERP'
|
||||
$lauf = (Get-Content 'c:\DEV\MasterArbeit\Versuche\Versuch_02\_aktueller_lauf.txt' -Raw).Trim()
|
||||
$agents = (Get-Content 'c:\DEV\MasterArbeit\Versuche\Versuch_02\03_Agents.json' -Raw)
|
||||
$claude = Get-ChildItem "$env:USERPROFILE\.vscode\extensions\anthropic.claude-code-*-win32-x64\resources\native-binary\claude.exe" |
|
||||
Sort-Object FullName | Select-Object -Last 1 -ExpandProperty FullName
|
||||
|
||||
$denyBash = @(
|
||||
'Bash(rm:*)','Bash(rmdir:*)','Bash(mv:*)','Bash(cp:*)','Bash(dd:*)',
|
||||
'Bash(truncate:*)','Bash(chmod:*)','Bash(chown:*)','Bash(ln:*)','Bash(tee:*)',
|
||||
'Bash(sed -i:*)','Bash(git checkout:*)','Bash(git restore:*)','Bash(git clean:*)',
|
||||
'Bash(git reset:*)','Bash(git add:*)','Bash(git commit:*)','Bash(git push:*)',
|
||||
'Bash(dotnet:*)','Bash(msbuild:*)','Bash(npm install:*)','Bash(nuget:*)'
|
||||
)
|
||||
$denyPs = @(
|
||||
'PowerShell(Remove-Item:*)','PowerShell(Move-Item:*)','PowerShell(Copy-Item:*)',
|
||||
'PowerShell(New-Item:*)','PowerShell(Set-Content:*)','PowerShell(Add-Content:*)',
|
||||
'PowerShell(Clear-Content:*)','PowerShell(Out-File:*)','PowerShell(Set-ItemProperty:*)',
|
||||
'PowerShell(dotnet:*)','PowerShell(msbuild:*)'
|
||||
)
|
||||
# Modus custom: KEIN --safe-mode (es deaktiviert die Agentenrollen). Ersatz nach Skill 7.0.0:
|
||||
$denyCustom = @('Skill','WebSearch','WebFetch','SlashCommand')
|
||||
|
||||
$env:CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS = '0'
|
||||
Set-Content -Path "$lauf\_meta\startzeit.txt" -Value (Get-Date -Format o)
|
||||
Set-Location $root
|
||||
|
||||
Get-Content "$lauf\_meta\combined_prompt.md" -Raw |
|
||||
& $claude -p `
|
||||
--output-format json `
|
||||
--strict-mcp-config `
|
||||
--permission-mode acceptEdits `
|
||||
--allowedTools "Bash" "PowerShell" `
|
||||
--disallowedTools @($denyBash + $denyPs + $denyCustom) `
|
||||
--model claude-opus-5 `
|
||||
--effort medium `
|
||||
--agents $agents `
|
||||
--add-dir "$lauf" `
|
||||
2> "$lauf\Stderr.log" | Set-Content "$lauf\RawResult.json"
|
||||
|
||||
Set-Content -Path "$lauf\_meta\endzeit.txt" -Value (Get-Date -Format o)
|
||||
Set-Content -Path "$lauf\_meta\exitcode.txt" -Value $LASTEXITCODE
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T13:09:18.6547798+02:00
|
||||
+674
File diff suppressed because one or more lines are too long
+2847
File diff suppressed because it is too large
Load Diff
+917
@@ -0,0 +1,917 @@
|
||||
# StRS – Stakeholder Requirements Specification
|
||||
|
||||
c-entron ERP-Suite · Reverse Requirements Engineering · ISO/IEC/IEEE 29148:2018
|
||||
Ebene: fachliche Sicht (Akteure, Geschäftsziele). Belegklassifikation: PRIMÄR / SEKUNDÄR / KONTEXT.
|
||||
|
||||
**ID-Bereich dieser Datei:** StRS-001 bis StRS-026.
|
||||
Die Zuordnung „welcher Bearbeiter welche IDs formuliert" ist in `Analysebericht.md` (Abschnitt Arbeitsteilung) dokumentiert.
|
||||
|
||||
**Identifizierte Stakeholder / Akteure aus den Artefakten**
|
||||
| Akteur | Herleitung (Artefakt) |
|
||||
|---|---|
|
||||
| Innendienst / Sachbearbeiter (OfficeStaff) | `ReceiptBL.CreateNewReceipt`: `customerReceipt.OfficeStaffI3D = customerDetail.Adviser1I3D` |
|
||||
| Außendienst / Vertreter (SalesRepresentative) | ebd.: `SalesRepresentativeI3D = customerDetail.Adviser2I3D`; `VertreterPLZ`, `EmployeeToSalesArea` (Schema) |
|
||||
| Disponent / Lagerist | `Warehousing/Commissions/CommissioningBL`, `Lagerorte`, `Nebenlager` (Schema) |
|
||||
| Support-Mitarbeiter / Helpdesk-Bearbeiter | `hlpdsk_request_bearbeiter`, `CentronRights.md` §1–§9 |
|
||||
| Servicetechniker (mit Signatur) | `hlpdsk_timer_signature`, `HelpdeskTimerSignatureBL` |
|
||||
| Geschäftsführung / Controlling | `ControllingAuswertung`, `StatisticRolesToEmployee`, `RIGHT_MITARBEITERAUSLASTUNG` |
|
||||
| Buchhaltung | `BookKeepingExport*`, `Kassenbuch*`, `Mahnlauf` |
|
||||
| Systemadministrator / Mandantenbetreuer | `Administration/Licensing`, `Administration/Scripts`, `Mandant`, `MandantenStammdat` |
|
||||
| Endkunde des Kunden (Webshop-Nutzer) | `README.md` („webcart is … intended for the customers of our customers"), `WebAccounts`, `WebAccountAuthenticator` |
|
||||
| Externe Systeme (Handelsstufe, FiBu, Paketdienst, Bank) | `src/apis/*`, `DataExchange/EDI`, `DataExchange/BookKeeping` |
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
ID: StRS-001
|
||||
Titel: Durchgängiger Vertriebsprozess von Angebot bis Rechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Innendienst, Außendienst
|
||||
Vorbedingung: Kunde ist im Adressstamm geführt; Angebot oder Auftrag existiert in offenen Status.
|
||||
Fakt: ReceiptBL.CanForwardReceiptsInto liefert die zulässigen Ziel-Belegarten; die Kette umfasst
|
||||
OrderClass, DeliveryListClass, InvoiceClass, PickupListClass, CreditVoucherClass, ContractClass.
|
||||
ValidateReceiptForwarding prüft je Quellbeleg: "Diese(s/r) {Belegart} kann nicht in eine(n)
|
||||
{Belegart} weiterverarbeitet werden."
|
||||
Aussage: Das System soll den Vertrieb entlang einer definierten Belegkette (Angebot → Auftrag →
|
||||
Lieferschein → Rechnung, ergänzend Abhol-liste, Gutschrift, Vertrag) führen und den
|
||||
Übergang nur entlang dieser Kette erlauben.
|
||||
Ergebnis: Der Folgebeleg wird aus dem Vorgänger erzeugt; positionsbezogene Herkunftsbeziehungen
|
||||
werden erhalten; ein nicht erlaubter Übergang wird mit Meldung abgewiesen.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, ReceiptBL.CanForwardReceiptsInto (Zeilen 1019 ff.),
|
||||
ReceiptBL.ValidateReceiptForwarding (Zeile ~995) - Begründung: die Methode definiert die zulässige
|
||||
Kette und erzwingt sie bei jeder Weiterverarbeitung.
|
||||
- [SEKUNDÄR] UI-Ordner src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ForwardReceipt - Begründung: eigene
|
||||
Maske für den Vorgang „Weiterverarbeitung" belegt die fachliche Funktion im Zielsystem.
|
||||
- [KONTEXT] Tabellen AngKopf/AngPos, BestKopf/BestPos, LiefKopf/LiefPos, RechKopf/RechPos (SSMS_DB_SCHEMA.sql)
|
||||
- Begründung: je Kettenglied eigene Kopf-/Positionspaare, also vier Belegstufen mit eigener Historie.
|
||||
Prüfidee: Versuch, ein Angebot direkt in eine Rechnung weiterzuverarbeiten; erwartetes Verhalten:
|
||||
Abweisung mit Meldung, kein Datensatz angelegt.
|
||||
Tracelinks: SyRS-001, SyRS-003, SwRS-001, SwRS-005
|
||||
Konsolidierung: Kandidat: StRS-002, SwRS-015 – beide beschreiben dieselbe Belegkopf-/Positionsmaschine für
|
||||
die andere Durchlaufrichtung bzw. datenmodelseitig.
|
||||
Übernahmewürdigkeit: übernehmen - Kerngeschäftsfunktion, ohne die kein Handelssystem auskommt.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-002
|
||||
Titel: Beschaffungsprozess vom Bedarf bis zur Lieferantenrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Einkauf, Disposition
|
||||
Vorbedingung: Lieferant (Kreditor) ist gepflegt; Bedarf liegt als Kundenposition oder manuelle Eingabe vor.
|
||||
Fakt: Eigene Businesslogik für Lieferantenbelege: SupplierOrderBL, SupplierDeliveryListBL,
|
||||
SupplierInvoicesBL, SupplierCreditVoucherBL, SupplierReceiptDocumentBL je mit eigenem
|
||||
*SpecificLogic; Tabellen WareKopf/WarePos, WareneingangPos, KreditorRMAKopf/-Pos.
|
||||
Aussage: Das System soll den Beschaffungsprozess (Lieferantenauftrag → Wareneingang/Lieferschein →
|
||||
Lieferantenrechnung → Lieferanten-Gutschrift) abbilden und die Wareneingangsdaten auf den
|
||||
zugehörigen Kundenbeleg zurückspiegeln (Direktlieferung).
|
||||
Ergebnis: Lieferantenauftrag und Kundenbeleg sind positionsweise verknüpft; Bestellungen gelten als
|
||||
vollständig oder teilweise fakturiert (SupplierOrderState.InvoiceComplet/InvoicePart).
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetReceiptForwardedInto (SupplierOrderState.
|
||||
InvoiceComplet / InvoicePart je Position) - Begründung: setzt den Fakturierungsgrad der
|
||||
Beschaffungsposition technisch um.
|
||||
- [SEKUNDÄR] BL-Klassen SupplierOrderBL.cs, SupplierInvoiceSpecificLogic.cs, SupplierDeliveryListBL.cs -
|
||||
Begründung: eigene Strategieimplementierung je Lieferantenbelegart.
|
||||
- [KONTEXT] src/centron/Centron.WPF.UI/Modules/Purchasing (136 Dateien) - Begründung: eigene UI-Gruppe Einkauf.
|
||||
Prüfidee: Lieferantenrechnung auf teillieferten Auftrag fakturieren; der Kundenbeleg zeigt „teilweise
|
||||
fakturiert", erst nach letzter Position „vollständig fakturiert".
|
||||
Tracelinks: StRS-001, SyRS-002, SyRS-016, SwRS-001
|
||||
Konsolidierung: Kandidat: StRS-001 (identische Belegmaschine, andere Richtung – Zusammenführung auf ein
|
||||
Belegmodell mit Rollenattribut Kunde/Lieferant prüfen).
|
||||
Übernahmewürdigkeit: übernehmen - unverzichtbarer Gegenzug zum Vertrieb.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-003
|
||||
Titel: Mandanten- und Filialfähigkeit einer Installation
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Mandantenbetreuer, Geschäftsführung
|
||||
Vorbedingung: Mandant und Filialen sind als Stammdaten gepflegt.
|
||||
Fakt: Tabellen Mandant, MandantenStammdat, Filiale, FilialeLeiter, FilialeToLager, Branch,
|
||||
BranchToStock, CustomerToBranches; Nummernkreisanlage CreateNumberGroups(int mandantI3D,
|
||||
int? branchI3D); Belegattribut BranchOrigin (Enum BranchOrigin.Creator) mit Einstellungs-
|
||||
schlüssel AppSettingsConst.LoadAssetBranchDataFrom („Filialdaten laden von dem").
|
||||
Aussage: Das System soll mehrere rechtliche Einheiten (Mandanten) und mehrere Niederlassungen
|
||||
(Filialen) in einer Installation führen; Belege, Nummernkreise, Lager und Erlöskonten
|
||||
sind der jeweiligen Einheit zuzuordnen.
|
||||
Ergebnis: Jeder Beleg trägt seine Filiale; Nummernkreise werden je Mandant/Filiale geführt;
|
||||
Auswertungen sind je Filiale trennbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs, CreateNumberGroups(mandantI3D,
|
||||
branchI3D) (Zeile 154) - Begründung: Nummernkreise werden mandanten- und filialabhängig erzeugt.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, UpdateReceiptBranch + BranchOrigin-Zuweisung -
|
||||
Begründung: die Filialzugehörigkeit jedes neuen Belegs wird aus einer Konfiguration abgeleitet.
|
||||
- [SEKUNDÄR] Tabellen Mandant, MandantenStammdat, Filiale, BranchToStock, WarenFilialeErloeskonto - Begründung:
|
||||
datenseitige Trennung nach Mandant/Filiale inkl. filialabhängiger Erlöskonten.
|
||||
Prüfidee: Zwei Filialen mit eigenen Nummernkreisen anlegen; in beiden je eine Rechnung erzeugen →
|
||||
beide Nummern laufen getrennt, Filiale des Belegs stimmt mit Anlagefiliale überein.
|
||||
Tracelinks: SyRS-011, SwRS-007, SwRS-023, SwRS-026
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - tragender Grund, warum Mandant und Filiale in praktisch jeder Tabelle auftauchen.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-004
|
||||
Titel: Einheitlicher Geschäftspartnerstamm für Kunden, Interessenten und Lieferanten
|
||||
Ebene: StRS
|
||||
Typ: Daten / funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Innendienst, Buchhaltung
|
||||
Vorbedingung: –
|
||||
Fakt: Zentrale Tabelle Accounts mit Typisierung über AccountTypes / AccountTypeToAccounts,
|
||||
Spezialisierungen AccountCustomers, AccountSuppliers, AccountContracts, AccountProduct,
|
||||
AccountRelationships; darunter Adressen (AccountAddresses, AbweichendeAnschrift) und
|
||||
Ansprechpartner (AccountAddressContacts, KontaktePersonen); Altbestand Kunden, Kreditor,
|
||||
Interessent, OneWayContact, Personen bleibt parallel bestehen.
|
||||
Aussage: Das System soll jeden Geschäftspartner genau einmal in einem einheitlichen Stamm führen und
|
||||
die Eigenschaften Kunde, Lieferant, Interessent, Konzernzugehörigkeit als Rollen desselben
|
||||
Partners abbilden; Anschrift und Ansprechpartner sind wiederverwendbar zuzuordnen.
|
||||
Ergebnis: Belege, Verträge, Helpdesk-Tickets und Assets referenzieren denselben Partner; eine
|
||||
geaenderte Schreibweise eines Namens wirkt auf alle Bezugnahmen.
|
||||
Belege:
|
||||
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Accounts / AccountTypes / AccountTypeToAccounts /
|
||||
AccountCustomers / AccountSuppliers / AccountRelationships - Begründung: Rollenmodell des
|
||||
Partnerstamms ist als Tabellenstruktur umgesetzt.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetExclusiveOfVat liest Kunden-
|
||||
(CustomerFinanceInformation) und Lieferantenseite (Kreditor.MwStNichtAusweisen) unterschiedlich -
|
||||
Begründung: belegt, dass beide Rollen heute noch getrennt gelesen werden.
|
||||
- [SEKUNDÄR] UI src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement (77 Dateien) - Begründung:
|
||||
gemeinsame Pflegeoberfläche.
|
||||
Prüfidee: Partner als Kunde und Lieferant gleichzeitig anlegen; Namensänderung im Stamm muss auf
|
||||
Kunden- und Lieferantensicht gleichziehen.
|
||||
Tracelinks: StRS-005, SyRS-011, SwRS-016
|
||||
Konsolidierung: Kandidat: SwRS-016 – Tabellen Altbestand (Kunden, Kreditor, Interessent) vs. neuer
|
||||
Account-Stamm bilden denselben Gegenstand doppelt ab.
|
||||
Übernahmewürdigkeit: übernehmen (Zielmodell: nur noch der Account-Stamm) - Altbestands Tabellen sind
|
||||
Migrationsbestandteile.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-005
|
||||
Titel: Kundenindividuelle Preise und Konditionen im Beleg
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Innendienst, Außendienst
|
||||
Vorbedingung: Artikel ist gepflegt; für Kunde/Vertrag können Sonderpreise hinterlegt sein.
|
||||
Fakt: ReceiptItemPriceBL.GetBasePrice berechnet (basePrice, discount) in fester Reihenfolge aus
|
||||
Verkaufspreis, Sondervereinbarung (EKVKReduction/VKReductionProcent), Vertrags-Sonderpreis
|
||||
(ContractSpecialPrice) und Kunden-Sonderpreis (CustomerSpecialPrice); Tabellen
|
||||
KundenSonderpreise, Sondervereinbarung/-Artikel, ArtikStaffelpreise, ArtikelVolumePrices.
|
||||
Aussage: Das System soll den im Beleg angesetzten Preis automatisch aus den kundenspezifischen
|
||||
Vereinbarungen ableiten und dem Bearbeiter nur die Kontrolle bzw. die ausdrückliche
|
||||
Abweichung erlauben.
|
||||
Ergebnis: Position erhält Basispreis und Rabatt aus der höchstrangigen gültigen Vereinbarung;
|
||||
die Herkunft ist im Beleg nachvollziehbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs, GetBasePrice
|
||||
(Zeilen 144 ff.), GetContractSpecialPrice (Zeile 169), GetSpecialPrice (Zeile 588) -
|
||||
Begründung: deterministische Preiskette ist dort als Code implementiert und erzwungen.
|
||||
- [SEKUNDÄR] UI src/centron/Centron.WPF.UI/Modules/Finances/Receipts/PriceMatrix, PositionToSpecialPrice -
|
||||
Begründung: Bearbeitungsoberflächen der Preisherkunft.
|
||||
Prüfidee: Für Artikel A Kunden-Sonderpreis und Vertrags-Sonderpreis gleichzeitig hinterlegen;
|
||||
Belegposition anlegen → es greift die dokumentierte Vorrangfolge, kein manueller Eingriff nötig.
|
||||
Tracelinks: SyRS-004, SwRS-004, SwRS-031
|
||||
Konsolidierung: Kandidat: StRS-006 – Vertragspreislogik ist zweimal implementiert (KundenSonderpreise und
|
||||
ContractSpecialPrice) und sollte in einem Preismodell aufgehen.
|
||||
Übernahmewürdigkeit: übernehmen - Kern der Kalkulation und damit Kern des Geschäftsmodells.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-006
|
||||
Titel: Vertragsgeschäft mit Kontingenten, Zählern und wiederkehrender Abrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Innendienst, Servicetechniker, Buchhaltung
|
||||
Vorbedingung: Vertrag (Wartung/Service/Full-Service) mit Laufzeit und Bepreisung ist geschlossen.
|
||||
Fakt: Vertragstabelle ContractClass ist eigene Belegart in CanForwardReceiptsInto; Tabellen
|
||||
VertragKopf/VertragPos, VertragKontingent*, VertragPosZaehler*, ZaehlerArt,
|
||||
VertragBepreisung*/VertragsArtBepreisung*, VertragRechKopfZuordnung; Beleglog-Felder
|
||||
ContingentKind/ContingentValue/ContingentUsedHours/ContingentResidualValueStart.
|
||||
Aussage: Das System soll Dauerschuldverhältnisse als eigenständiges Objekt mit Leistungskontingent
|
||||
(Betrag oder Stunden), Zählerstand und Preisregel führen und die Abrechnung aus dem
|
||||
Verbrauch des Kontingents ableiten.
|
||||
Ergebnis: Verbrauchsänderungen am Kontingent werden protokolliert; die Abrechnung referenziert
|
||||
Vertrag und Verbrauch.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, WriteReceiptLogs – bedingte Log-Einträge
|
||||
für ContingentKind/-Value/-UsedHours/-UsedAmount/-ResidualValueStart - Begründung: erzwingt
|
||||
lückenlose Protokollierung jeder Kontingentbewegung.
|
||||
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE VertragKontingent, VertragPosZaehler, ZaehlerArt,
|
||||
VertragRechKopfZuordnung - Begründung: Kontingent-, Zähler- und Abrechnungsbeziehung sind
|
||||
datenmodellseitig angelegt.
|
||||
- [SEKUNDÄR] UI Modules/Finances/Contracts (156 Dateien), ContractEvaluation2 (4 Dateien) - Begründung:
|
||||
eigene Vertragsbearbeitung und -auswertung.
|
||||
Prüfidee: Stundenkontingent 10 h; Helpdeskzeit 3 h verbuchen → Restkontingent 7 h, Logeintrag mit
|
||||
Alt-/Neuwert und Bearbeiter vorhanden.
|
||||
Tracelinks: StRS-007, SyRS-001, SwRS-002, SwRS-032
|
||||
Konsolidierung: Kandidat: StRS-005 (Preisregeln für Vertrag und Kunde getrennt), StRS-010 (Pauschalabrechnung)
|
||||
Übernahmewürdigkeit: übernehmen - wiederkehrende Erlöse sind wirtschaftliche Basis des Unternehmens.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-007
|
||||
Titel: servicezeiterfassung mit Kundensignatur und Übergabe in die Abrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Servicetechniker, Support-Mitarbeiter, Abrechnung
|
||||
Vorbedingung: Helpdesk-Ticket existiert; Mitarbeiter-Artikel ist gepflegt.
|
||||
Fakt: Tabellen hlpdsk_timer, hlpdsk_timer_signature, hlpdsk_timer_typen, hlpdsk_timer_log,
|
||||
HelpdeskTimerBillingStates, HelpdeskTimerSpecialArticles, Reisekosten*/ServiceArbeiten;
|
||||
HelpdeskTimerBL erstellt Belegpositionen aus Zeiten; Rechte EDIT_TIME, OWN_TIME_EDIT,
|
||||
MOVE_HELPDESK_TIMER, DELETE_HELPDESK_TIMER, DELETE_HELPDESK_SIGNATURE (CentronRights.md §7–§9).
|
||||
Aussage: Das System soll erbrachte Servicezeiten pro Ticket erfassen, gegen Zeichner- und
|
||||
Berechtigungsregeln schützen, per Kunde signierbar machen und unverändert in die
|
||||
Rechnungsposition überführen.
|
||||
Ergebnis: Zeit ist einem Bearbeiter zugeordnet, optional signiert, und entweder offen (verschieb-/
|
||||
löschbar) oder einem Beleg zugewiesen (gesperrt).
|
||||
Ergebnis-Nachtrag: Zeichenberechtigung und Löschrecht sind getrennt zu betrachten; das Löschen ist nach
|
||||
Belegzuordnung ausgeschlossen.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs, Zeile 556 ff. –
|
||||
HasUserRight(UserRightsConst.Sales.Customer.Helpdesk.DELETE_HELPDESK_TIMER) und
|
||||
„Die Helpdesk Zeit wurde einem Beleg zugewiesen. Löschen ist nicht möglich." - Begründung:
|
||||
beide Schutzwirkungen werden an dieser Stelle durchgesetzt.
|
||||
- [SEKUNDÄR] CentronRights.md §7.1 „This is a restricting right … the employee article of the time record
|
||||
must belong to the user" - Begründung: dokumentiert die fachliche Absicht der Einschränkung.
|
||||
- [KONTEXT] Tabelle hlpdsk_timer_signature - Begründung: Signatur ist als eigenständige Speicherung angelegt.
|
||||
Prüfidee: Zeit an Beleg überführen, danach DELETE versuchen → Fehlermeldung, Satz bleibt erhalten;
|
||||
Bearbeiter B ohne OWN_TIME_EDIT darf Zeit von A nicht ändern.
|
||||
Tracelinks: StRS-006, SyRS-022, SwRS-012, StRS-019
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - direkte Erlösquelle des Servicebereichs.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-008
|
||||
Titel: Forderungsausfallrisiken的 Steuerung über Mahnwesen mit Belegsperre
|
||||
Ebene: StRS
|
||||
Typ: funktional / Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung, Kreditorenbuchhaltung, Innendienst
|
||||
Vorbedingung: Rechnung ist offen und überfällig.
|
||||
Fakt: MahnlaufBL/DunningBL mit Mahnstufen 1–3 (GetCustomerOrSupplierDunningLevel liefert
|
||||
0/1/2/3); ReceiptBL.CanUserCreateNewReceiptsAtCustomerOrSupplier vergleicht Mahnstufe mit
|
||||
BlockNewReceiptsDunningLevel und meldet „Aufgrund der Mahnstufe darf kein neuer Beleg …
|
||||
angelegt werden"; Mahnbrichte über Reportgruppe ReportGroupConstants.MAHNUNG; Tabellen
|
||||
Mahnlauf, Eskalationen, EskalationTypen, EskalationsLog.
|
||||
Aussage: Das System soll den Zahlungskredit eines Kunden in Stufen abbilden und ab einer
|
||||
konfigurierbaren Stufe die automatische Sperre weiterer Beleganlage auslösen.
|
||||
Ergebnis: Bei Mahnstufe >= Sperrstufe wird jede Neubeleganlage für den betroffenen Partner
|
||||
abgewiesen; der Mahnbricht wird im Report definiert.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CanUserCreateNewReceiptsAtCustomerOrSupplier
|
||||
(Zeile 10194 ff.) inkl. Aufruf BlockNewReceiptsDunningLevel - Begründung: die Sperre wird beim
|
||||
Anlegen jedes Belegs geprüft.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Zeile 150 –
|
||||
ReportGroupConstants.MAHNUNG als Pflicht-Reportgruppe, sonst Exception - Begründung: erzwingt
|
||||
eine definierte Mahnbruchvorlage je Mandant.
|
||||
- [SEKUNDÄR] Tabellen Mahnlauf, Eskalationen, EskalationStatistik - Begründung: Ablage der Läufe und Stufen.
|
||||
Prüfidee: Mahnstufe 2 setzen, Sperrstufe 2 → Anlage eines Angebots wird abgewiesen; Stufe zurücksetzen
|
||||
→ Anlage wieder möglich.
|
||||
Tracelinks: SyRS-005, SyRS-023, SwRS-014, StRS-018
|
||||
Konsolidierung: Kandidat: StRS-013 – Eskalationslogik für Tickets und für Forderungen verwenden dieselben
|
||||
Eskalationstypen-Tabellen für unterschiedliche Fachdomänen.
|
||||
Übernahmewürdigkeit: übernehmen - existenzielle Risikosteuerung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-009
|
||||
Titel: Übergabe aller relevanten Vorgänge an die Finanzbuchhaltung
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung, Fremtbuchhaltungssystem
|
||||
Vorbedingung: Buchhaltungssystem ist als Exportziel konfiguriert (BookKeepingAccountSystems).
|
||||
Fakt: BookKeepingExportBL mit LoadExportSettings, GetExportCustomerBookingData,
|
||||
GetBookKeepingExportCustomer/SupplierDataHistory, GetBookKeepingExportCashBookDataHistory,
|
||||
GetBookKeepingExportFileInfo; unknown Typ → Exception „Unknown BookKeepingType"; Tabellen
|
||||
BookKeepingExport*, BookKeepingImportInterfaces*, BuchhaltungsExportDeb/Kred/Kasse/SageKHK,
|
||||
BuchhaltungsExpDebPerson/KredPerson, FibuExportBuchungstextEinstellungen.
|
||||
Aussage: Das System soll Kundensachverhalte, Lieferantensachverhalte, Stammdatenänderungen und
|
||||
Kassenbewegungen in einem konfigurierbaren Format an eine externe Finanzbuchhaltung übergeben
|
||||
und den Exportzeitpunkt je Datensatz nachvollziehbar marcaieren.
|
||||
Ergebnis: Exportdatei wird je Konfiguration erzeugt; exportierte Datensätze sind als exportiert
|
||||
gekennzeichnet und werden nicht erneut übergeben.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs, Zeilen 441–449 und 789 –
|
||||
throw new ArgumentOutOfRangeException("Unknown BookKeepingType") - Begründung: erzwingt die
|
||||
Anmeldung jeder Buchhaltungsart im Code, unbekannte Typen scheitern laut.
|
||||
- [SEKUNDÄR] Tabellen BookKeepingExportCustomInterfaceColumns/-Settings, FibuExportBuchungstextEinstellungen -
|
||||
Begründung: Format und Texte sind konfigurierbar gehalten.
|
||||
- [SEKUNDÄR] Beleg-Flag „IsAlreadyExported" (ReceiptBL.HandleIsAlreadyExported) - Begründung: Exportstatus
|
||||
ist am Beleg geführt.
|
||||
Prüfidee: Rechnung erzeugen, Export laufen lassen, Export erneut starten → Rechnung wird nicht
|
||||
erneut ausgegeben.
|
||||
Tracelinks: SyRS-015, SwRS-028, StRS-011
|
||||
Konsolidierung: Kandidat: SwRS-028 – mehrere, teils parallele Exportformate (SageKHK, Kasse, Deb/Kred) für
|
||||
denselben Vorgang.
|
||||
Übernahmewürdigkeit: übernehmen (Funktionsumfang), die konkrete Formatvielfalt ist übernahmefähig zu bündeln.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-010
|
||||
Titel: Automatisierte und pauschale Abrechnung wiederkehrender Vorgänge
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Abrechnung, Buchhaltung
|
||||
Vorbedingung: Pauschalvertrag, Flatrate oder abrechenbare Sammelvorgänge liegen vor.
|
||||
Fakt: UI-Module Modules/Finances/AutomatedBilling (58), FlatrateBilling (37), TimerBilling (75),
|
||||
ContractEvaluation2; BL-Seitig ReceiptInvoiceBL, DownPaymentBL, OposBL/OposRunBL,
|
||||
LeasingRateBL, ServiceRateBL, HourlySurchargeRatesBL, Tabellen LeasingSaetze/LeasingFaktor,
|
||||
ServiceSaetze, HourlySurchargeRates/-Items.
|
||||
Aussage: Das System soll wiederkehrende Forderungen (Pauschalen, Leasing- und Service-Raten,
|
||||
Zeitkontingente, Anzahlungen und Schlussrechnungen) automatisch erzeugen, ohne dass je
|
||||
Vorgang ein Beleg manuell angelegt werden muss.
|
||||
Ergebnis: Sammelläufe erzeugen Belege mit Referenz auf die zugrunde liegenden Einzelvorgänge;
|
||||
Anzahlungen werden bei der Schlussrechnung gegengerechnet.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/DownPayment/DownPaymentBL.cs sowie ReceiptBL.Validate-
|
||||
ReceiptForwarding, Anzahlungs-Hinweistext „… für den es Anzahlungsrechnungen gibt … sollte
|
||||
daher nicht manuell in eine Rechnung weiterverarbeitet werden" - Begründung: erzwingt die
|
||||
Anzahlungs-/Schlussrechnungs-Logik beim Weiterverarbeiten.
|
||||
- [SEKUNDÄR] UI-Module AutomatedBilling, FlatrateBilling, TimerBilling - Begründung: eigene Bedienbereiche.
|
||||
Prüfidee: Auftrag mit Anzahlung anlegen, Lieferschein weiterverarbeiten → Warnung zur Anzahlung;
|
||||
Schlussrechnung gleicht Anzahlungssaldo aus.
|
||||
Tracelinks: StRS-006, SyRS-001, SwRS-006
|
||||
Konsolidierung: Kandidat: StRS-006 – Vertragsabrechnung und Pauschalabrechnung bilden dieselbe
|
||||
wiederkehrende Forderung zweifach ab.
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-011
|
||||
Titel: Revisionssichere Belegfassung: Version, Storno und Wiederverwendung
|
||||
Ebene: StRS
|
||||
Typ: funktional / Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Innendienst, Buchhaltung, Wirtschaftsprüfer
|
||||
Vorbedingung: Beleg existiert in einer Fassung.
|
||||
Fakt: Belegstatus enum ReceiptState { Active=1 „offen", Completed=2 „abgeschlossen",
|
||||
Canceled=3 „storniert" }; je Belegart Versions-Tabellen (AngKopfVersions, BestKopf… nicht,
|
||||
LiefKopfVersions, RechKopfVersions, GutKopfVersions, VertragKopfVersions, AufKopfVersions);
|
||||
ReceiptBL.CreateNewVersion erhöht Version und prüft aktive Seriennummern sowie
|
||||
„Die aktuelle Version dieses Belegs wurde bereits weiterverarbeitet."
|
||||
Aussage: Das System soll jede Änderung an einem erfassten Beleg als neue Fassung erhalten, die
|
||||
frühere Fassung unverändert aufbewahren und Storno als Status, nicht als Löschung abbilden.
|
||||
Ergebnis: Alle Fassungen sind numeriert und aufrufbar; eine bereits weiterverarbeitete Fassung kann
|
||||
nicht erneut geändert werden.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs – Enumeration mit
|
||||
Description-Attributen offen/abgeschlossen/storniert - Begründung: abschliessender
|
||||
Statuskorpus eines Belegs.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateNewVersion<T> (receipt.Version =
|
||||
currentReceiptVersion.Version + 1) inkl. Prüfung GetReceiptForwardedInto - Begründung:
|
||||
Versionsbildung und Sperre weiterverarbeiteter Fassungen werden dort erzwungen.
|
||||
- [SEKUNDÄR] Versions-Tabellen je Belegart in SSMS_DB_SCHEMA.sql - Begründung: Fassungen sind
|
||||
datenmodelseitig getrennt gehalten.
|
||||
Prüfidee: Version 1 weiterverarbeiten, dann neue Version aus Version 1 erzeugen → Meldung
|
||||
„bereits weiterverarbeitet", keine neue Fassung.
|
||||
Tracelinks: SyRS-002, SwRS-002, SwRS-015, StRS-025
|
||||
Konsolidierung: Kandidat: SwRS-015 – Versionshaltung ist je Belegart einzeln implementiert.
|
||||
Übernahmewürdigkeit: übernehmen - GoBD-relevante Anforderung.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-012
|
||||
Titel: Abgabekonforme elektronische Rechnung (ZUGFeRD) und Signatur beim Versand
|
||||
Ebene: StRS
|
||||
Typ: funktional / nicht-funktional
|
||||
Qualitätsmerkmal: Compliance (Rechtssicherheit); primäres ISO-25010-Merkmal: Wartbarkeit
|
||||
Akteur: Buchhaltung, Finanzverwaltung, Kunde
|
||||
Vorbedingung: ZUGFeRD ist global oder je Kunde aktiviert; Rechnung oder Gutschrift liegt vor.
|
||||
Fakt: ReceiptBL.CreateFullReportForReceipt: für InvoiceClass und CreditVoucherClass bei
|
||||
InvoiceZugferdBL.IsZugferdEnabled() oder GetLocalZUGFeRDSetting(receipt) wird
|
||||
CreateZugferdConformPdfDocument mit Leitweg-ID erzeugt; Fallback ohne Positionen-Layout-Item:
|
||||
„Für ZUGFeRD muss ein PDF Dokument über die Rechnung erzeugt werden.";Zustand Canceled
|
||||
ausgenommen. Beim ReportAction Mail/Export greift PdfSigningBL.SignPdfDocument.
|
||||
Leitweg-ID wird vorrangig aus der Konzernobergesellschaft geholt.
|
||||
Aussage: Das System soll Ausgangsrechnungen und Gutschriften als syntaktisch korrektes hybrides
|
||||
PDF mit eingebettetem strukturiertem Rechnungsdatensatz erzeugen, die Leitweg-ID des
|
||||
Empfängers befüllen und auf Wunsch digital signieren.
|
||||
Ergebnis: PDF enthält den ZUGFeRD-Anhang; Leitweg-ID stammt aus Konzern- oder Kundendatensatz;
|
||||
signierter Versand ist von der Verfügbarkeit der Signaturkomponente abhängig.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateFullReportForReceipt –
|
||||
Bedingungsblock (InvoiceClass || CreditVoucherClass) && IsZugferdEnabled() && State != Canceled,
|
||||
Aufruf InvoiceZugferdBL.CreateZugferdConformPdfDocument(... GetLeitwegID(...)) - Begründung:
|
||||
die Erzeugung wird im Ausgabepfad hart erzwungen.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs (SignPdfDocument, IsPdfSigningAvailable) -
|
||||
Begründung: Signatur ist an dieselbe Bedingung gekoppelt.
|
||||
- [SEKUNDÄR] Tabellen EDIInvoiceHead/-Items, EDIInvoiceBarcodes, DocuFormSettings, ZugferdImport - Begründung:
|
||||
Strukturdaten und Importpfad sind vorhanden.
|
||||
Prüfidee: Rechnung mit aktivem ZUGFeRD drucken → PDF enthält XML-Anhang; Storno-Rechnung ohne Anhang.
|
||||
Tracelinks: StRS-009, SyRS-013, SyRS-014, SwRS-021
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - gesetzliche Pflicht.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-013
|
||||
Titel: Helpdesk- und Ticketbearbeitung mit Zuständigkeit, Fälligkeit und Eskalation
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Support-Mitarbeiter, Helpdesk-Leiter, Kunde (Sichtbarkeit)
|
||||
Vorbedingung: Ticket ist angelegt oder aus Beleg automatisch erzeugt (AppSettingsConst.AutomHelpdesk).
|
||||
Fakt: Rechte SHOW_HELPDESK, SHOW_HELPDESK_ONLY_OWN, SHOW_HELPDESK_ONLY_OWN_BRANCH,
|
||||
ADD_NEW_HELPDESK, EDIT_HELPDESK, ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS, MATURITY_CHANGE,
|
||||
CLOSE_REQUEST (CentronRights.md §1–§6); BL HelpdeskStatusBL, HelpdeskPrioritiesBL,
|
||||
EscalationBL, HelpdeskForwardBL, HelpdeskCloseBL, HelpdeskSchedulerBL; Tabellen
|
||||
hlpdsk_requests, hlpdsk_status, hlpdsk_prioritaeten, hlpdsk_history, Eskalationen,
|
||||
EscalationsLog, EstimatedProgressForHelpdesks.
|
||||
Aussage: Das System soll Support-Vorgänge mit Status, Priorität, Fälligkeit, Verantwortlichem und
|
||||
Historie führen, die Sicht- und Bearbeitbarkeit nach Person, Abteilung und Filiale
|
||||
einschränken und Überschreitungen automatisch eskalieren.
|
||||
Ergebnis: Ein nicht berechtigter Nutzer sieht das Ticket weder in Liste noch im Zugriff;
|
||||
Eskalationen werden mit Zeitstempel protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] CentronRights.md §1.1/§1.2 – „This is a restricting right. If the user has this right, he
|
||||
should only see and access tickets where he is either editor or responsible person." -
|
||||
Begründung: benennt die durchzusetzende Sichtbarkeitsregel inkl. Konstantennamen.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/UserRightsExt.cs / AppRightsBL.HasUserRight -
|
||||
Begründung: zentrale Prüfstelle aller Rechte.
|
||||
- [SEKUNDÄR] Tabellen hlpdsk_status, hlpdsk_history, EscalationsLog - Begründung: Status- und
|
||||
Eskalationshaltung ist datenmodelseitig vorhanden.
|
||||
Prüfidee: Nutzer mit SHOW_HELPDESK_ONLY_OWN ruft Ticketliste auf → nur eigene Tickets; direkter
|
||||
Aufruf fremder Ticket-I3D wird abgewiesen.
|
||||
Tracelinks: StRS-007, StRS-019, SyRS-006, SyRS-022
|
||||
Konsolidierung: Kandidat: SwRS-024 – zwei Helpdesk-Datenhaltungen (hlpdsk_* und Helpdesk*) im selben System.
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-014
|
||||
Titel: IT-Assetlebenszyklus beim Kunden als Grundlage von Service und Abrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional / Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Servicetechniker, IT-Betreuer, Helpdesk
|
||||
Vorbedingung: Kunde hat Geräte, Lizenzen und Verträge betreut.
|
||||
Fakt: Über 240 Tabellen mit Präfix AssetManagement* (Device-, AD-, DHCP-, DNS-, IIS-, SQL-,
|
||||
HyperV-, VMWare-, Backup-, Patch-, License-, Documentation-Bereiche) plus CMan*-Tabellen
|
||||
(CManMachine, CManSoftware, CManPhysicalMemory …) plus separate Tabellen Printer, Equipment,
|
||||
EquipmentTyp, GeraeteKopf/GeraetePos, GeraeteWartung, hlpdsk_geraete, HlpDsk_Geraete;
|
||||
LicenseKopf/LizenzPos, VertragGeraete, AnlageFreigaben*.
|
||||
Aussage: Das System soll die beim Kunden betreute IT-Infrastruktur (Geräte, Software, Lizenzen,
|
||||
Verträge, Netzwerkkomponenten) inventarisieren, mit Hilfedesk-Tickets verbinden und die
|
||||
Datenbasis für Wartungsverträge und Prüfnachweise liefern.
|
||||
Ergebnis: Ein Gerät ist einem Kunden zugeordnet, mit Ticket-Historie, Lizenz und Vertrag verknüpft;
|
||||
Erkannte Eigenschaften (CPU, RAM, Volumen, OS) werden gepflegt oder eingelesen.
|
||||
Belege:
|
||||
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AssetManagementDevices, AssetManagementLicenseSoftware,
|
||||
AddressToAsset, hlpdsk_geraete - Begründung: Geräte sind eigene Entität mit Kunden- und
|
||||
Ticketbeziehung.
|
||||
- [SEKUNDÄR] UI src/centron/Centron.WPF.UI/Modules/Finances/Crm (532 Dateien) und Helpdesk (316 Dateien) -
|
||||
Begründung: Asset-Pflege ist über Vertrieb und Helpdesk verteilt.
|
||||
- [KONTEXT] Tabelle hlpdsk_nable_link, NableServices - Begründung: Anbindung eines externen Monitorings.
|
||||
Prüfidee: Gerät einem Kunden zuordnen, Ticket auf Gerät anlegen → Gerät, Kunde, Ticket sind
|
||||
gegenseitig referenziert.
|
||||
Tracelinks: StRS-013, StRS-006, SwRS-017
|
||||
Konsolidierung: Kandidat: StRS-017, SwRS-017 – „Stamtblatt" (Drucker) und „Asset" sind zwei Datenhaltungen
|
||||
für denselben Gegenstand; zusätzlich CMan* vs. AssetManagement*.
|
||||
Übernahmewürdigkeit: übernehmen (Funktionsumfang) – die parallele Zweitablage ist als Workaround zu werten.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-015
|
||||
Titel: Erfassung und Auswertung von IT-Stammdaten aus Fremdsystemen
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Servicetechniker, CMan-Client, Überwachungsdienst
|
||||
Vorbedingung: Client-Agent oder Abfragedienst ist beim Kunden installiert bzw. konfiguriert.
|
||||
Fakt: Tabellen GeraeteCMan*, CManMachine, CManEventLog, CManIntegrityFile/-Server, CManThreshold,
|
||||
CManLANResources, Monitoring* (MonitoringTemplates, MonitoringDataChecks, MonitoringDataFailures,
|
||||
MonitoringServiceSettings), MonScripts, AssetManagement*Checks/-SnmpDetails,
|
||||
ExpectedEvents/ExpectedEventLogEntries, StopwatchNotifications;
|
||||
RemoteConnections/-RDP/VNC/Web/Putty-Metadaten, RemoteCredentials.
|
||||
Aussage: Das System soll Zustands- und Konfigurationsdaten von Kunden-IT aus Agenten, SNMP- und
|
||||
Protokollabfragen übernehmen, gegen Schwellwerte prüfen, Abweichungen melden und
|
||||
Supportzugänge strukturiert ablegen.
|
||||
Ergebnis: Prüfergebnisse mit Zeitstempel und Fehlerhistorie; meldepflichtige Abweichung erzeugt
|
||||
Benachrichtigung bzw. Ticket.
|
||||
Belege:
|
||||
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE CManThreshold, MonitoringDataFailures,
|
||||
AssetManagementCheckErrorLogs - Begründung: Schwellwert und Fehlerspeicher sind datenmodelseitig
|
||||
erzwungen.
|
||||
- [SEKUNDÄR] Tabelle RemoteCredentials, RemoteRDPMetadatas - Begründung: Ablagestruktur für Supportzugänge.
|
||||
- [KONTEXT] src/apis/Centron.APIs.FinAPI, NableServices - Begründung: Hinweise auf externe Dienste.
|
||||
Prüfidee: Festgelegter Schwellwert unterschreiten → MonitoringDataFailure-Eintrag und Benachrichtigung.
|
||||
Tracelinks: StRS-014, StRS-013, StRS-022
|
||||
Konsolidierung: Kandidat: StRS-014 – Überwachungsdaten liegen in zwei Systemwelten (CMan* und
|
||||
AssetManagement*/Monitoring*).
|
||||
Übernahmewürdigkeit: übernehmen (Funktionsumfang); die doppelte Erfassung ist Migrationskandidat.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-016
|
||||
Titel: Eindeutige Warennachverfolgbarkeit über Seriennummer und Barcode
|
||||
Ebene: StRS
|
||||
Typ: funktional / Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Lagerist, Einkauf, Service
|
||||
Vorbedingung: Artikel ist seriennummerngeführt; Bestand ist angelegt.
|
||||
Fakt: BarcodeBL erzwingt Eindeutigkeit: „SN existiert bereits" (CreateNewBarcode), „SN ist bereits
|
||||
vorhanden" (RenameBarcode), „The barcode … is already assigned to an order";
|
||||
Seriennummernbereichsvergabe GetNextAvailableSerialNumberArea; Zustandswechsel
|
||||
UpdateSerialNumberState, Ausbuchung CheckOutBarCodes, Historie BarcodeHistory;
|
||||
Tabellen Barcode, BarCode2, AufBarcodes, RMAPosSN, InventurSeriennummern,
|
||||
SeriennummerToPosition, XMLLockList.
|
||||
Aussage: Das System soll jede seriennummergeführte Einheit eindeutig und systemweit unverwechselbar
|
||||
identifizieren, ihren Bestand, Zustand und Lagerort führen und jeden Zustands- und
|
||||
Standortwechsel über den gesamten Lebenszyklus nachvollziehbar speichern.
|
||||
Ergebnis: Zweite Anlage derselben Seriennummer wird abgewiesen; Umbuchung auf ein Stammblatt nur bei
|
||||
passendem Bestand möglich.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Warehousing/BarcodeBL.cs, CreateNewBarcode (Zeile 634 ff., „SN existiert
|
||||
bereits"), RenameBarcode (Zeile 740 ff.), UpdateBarcodeSetInOrderState (Zeile 80 ff.) -
|
||||
Begründung: Eindeutigkeit und Auftragsbindung werden dort geprüft.
|
||||
- [PRIMÄR] ReceiptBL.ValidateReceiptForwarding – Prüfungen barcodesStillInReceiptResult,
|
||||
enoughBarcodesResult - Begründung: Weiterverarbeitung scheitert bei fehlender/gebundener Seriennummer.
|
||||
- [SEKUNDÄR] Tabellen Barcode, BarCode2, BarcodeHistory, XMLLockList - Begründung: Zwei Barcode-Tabellen
|
||||
plus Sperrliste belegen die Nachverfolgungs- und Konkurrenzabsicht.
|
||||
Prüfidee: Seriennummer „SN1" zwei Artikeln zu geben → zweite Anlage schlägt fehl; Lieferschein ohne
|
||||
ausreichende aktive Seriennummern wird abgewiesen.
|
||||
Tracelinks: StRS-018, SyRS-020, SwRS-013, SwRS-005
|
||||
Konsolidierung: Kandidat: SwRS-013 – Barcode/BarCode2 Doppelhaltung.
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-017
|
||||
Titel: Warenwirtschaft: Artikelstamm, Bestand, Lagerorte und Kommissionierung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Einkauf, Lager, Vertrieb
|
||||
Vorbedingung: Artikel, Lager und Filialen sind gepflegt.
|
||||
Fakt: ArtikelBL, GeneralArticleBL, ArticleStockBL, StockBL, StorageAreaBL, StoragePlaceBL,
|
||||
SecondStockArticleBL (Nebenlager), CommissioningBL, OrderCommissionBL,
|
||||
PartialCommissionOrderBL, InventoryBL/InventoryNewBL; Tabellen Artikel, ArtikelBestand,
|
||||
ArtikelStueckliste, Lagerort, LagerorteQM, Lagerplatz, Nebenlager/NebenlagerArtikel,
|
||||
LagerUmbuchungsliste, Warehouse, Warehouses, Teilkommissionierung
|
||||
(PartialCommissionOrders/-ItemToBarcodeRelations).
|
||||
Aussage: Das System soll Artikel mit Bestand je Lager und Lagerort führen, Reservierungen und
|
||||
Teilkommissionierungen unterstützen und Bestandsbewegungen als Buchung abbilden.
|
||||
Ergebnis: Bestand je Artikel/Lager ist ausbuchbar; eine Teilkommissionierung erzeugt eigene
|
||||
Liefervorschläge mit abweichender Lieferadresse.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, ValidateReceiptForwarding (ArtikelLager-
|
||||
Prüfung articleWarehousesAreValidResult) und Teilkommissionierungs-Zweige - Begründung:
|
||||
Lagerbezug jeder Position wird beim Weiterverarbeiten geprüft.
|
||||
- [SEKUNDÄR] UI Modules/Warehousing (529 Dateien), Subfolder Inventory, Commissioning, Commissions -
|
||||
Begründung: eigene Masken für die Lagervorgänge.
|
||||
- [KONTEXT] README.md Abschnitt „WebCart" - Begründung: bestätigt Warenwirtschaft als Datengrundlage
|
||||
des Kunden-Shops.
|
||||
Prüfidee: Artikel an zwei Lagerorten; Auslieferung aus einem Ort mindert nur dort den Bestand.
|
||||
Tracelinks: StRS-016, StRS-001, SwRS-016, SwRS-029
|
||||
Konsolidierung: Kandidat: StRS-014 – „Anlage/Stamtblatt" und „Artikel" werden an mehreren Stellen zusammen
|
||||
geführt (AnlageFreigabenWarengruppen, KundeToArtikel).
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-018
|
||||
Titel: Rücksendung, Reparatur und gesetzliche Geräteprüfung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Service, Kunde, Prüfer
|
||||
Vorbedingung: Gerät mit Seriennummer ist einem Kunden zugeordnet.
|
||||
Fakt: RMA-Tabellefamilie RMAAnfKopf/-Pos, RMAKopf/-Pos/-PosSN/-PosStatus, RMARepKopf/-Pos,
|
||||
RMARueckKopf/-Pos, RmaSendForth/SendBack, KundenRMA/KundenRMASN; Reparaturfamilie
|
||||
RepaKopf/-Artikel/-Pruefling/-Pruefmittel/-Arbeitssicherheit/-Umweltschutz je mit
|
||||
*History, RepEingangKopf/-Pos; Prüf-/Arbeitsschutzfamilie Wartung*, Prufmittel, Pruflinge,
|
||||
Prufvorschrift/-Messwert, Arbeitsschutz, Arbeitssicherheit, Umweltschutz, Unterweisungen,
|
||||
PersonUnterweisung; eigene UI-Module Rma (33), QM (8), Production (28).
|
||||
Aussage: Das System soll Rücksende- und Reparaturvorgänge als eigene Belegkette abbilden und
|
||||
wiederkehrende Prüfungen von Arbeitsmitteln und ortsveränderlichen Geräten inklusive
|
||||
Prüfvorschrift, Messwert und Nachweisführung unterstützen.
|
||||
Ergebnis: RMA-Status je Position wird geführt; Prüflinge haben Fristen, Prüfergebnisse werden
|
||||
revisionssicher mit Historie gespeichert.
|
||||
Belege:
|
||||
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE RMAPosStatus, PrufvorschriftMesswert, WartungHistoryMesswert,
|
||||
WartungHistoryPruflinge - Begründung: Status je RMA-Position und Messwert-Historie sind als
|
||||
Tabellen umgesetzt.
|
||||
- [SEKUNDÄR] UI-Ordner Modules/Rma, Modules/QM; Tabelle RepaKopfHistory - Begründung: eigene Bearbeitung
|
||||
und versionierte Prüfnachweise.
|
||||
Prüfidee: RMA-Position auf Status „zurückgesandt" setzen; Prüffrist eines Prüflings ablaufen lassen →
|
||||
Wiedervorlage/Erinnerung wird erzeugt.
|
||||
Tracelinks: StRS-016, StRS-014, StRS-002
|
||||
Konsolidierung: Kandidat: StRS-014 – Wartungs-/Prüfdatenhaltung existiert mehrfach (Wartung*, Repa*,
|
||||
GeraeteWartung).
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-019
|
||||
Titel: Wer darf was sehen: Rollen-, Filial- und Bereichsbezogene Zugriffssteuerung
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Systemadministrator, Vorgesetzter, Sachbearbeiter
|
||||
Vorbedingung: Benutzer ist Mitarbeiter einer Filiale und hat Rollen.
|
||||
Fakt: Berechtigungskatalog als benannte Konstanten (UserRightsConst.*) mit eigenen
|
||||
„restricting rights"; ReceiptBL.CanUserEditReceipt prüft Bearbeitungsrecht und optional
|
||||
„nur eigene Filiale" (BranchBL.IsBranchEqual); CanUserViewReceipt verweigert Web-Benutzern
|
||||
das Belegsehen vollständig; Kalender und Mitarbeiterauslastung haben eigene
|
||||
Filialeinschränkungen (RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE).
|
||||
Aussage: Das System soll jede fachliche Funktion an ein Berechtigungsrecht binden und
|
||||
einschränkende Rechte zusätzlich nach Person, Abteilung und Filiale differenzieren;
|
||||
Berechtigungsprüfungen gehören in die Geschäftslogik, nicht in die Oberfläche.
|
||||
Ergebnis: Fehlendes Recht führt zu fachlicher Fehlermeldung mit eigenem MessageCode
|
||||
(RightCheckFailed), nicht zu einer ausgeblendeten Schaltfläche allein.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CanUserEditReceipt (Zeile 10272 ff.) mit
|
||||
HasRightToEditReceipt / HasRightToEditReceiptOnlyOwnBranch / BranchBL.IsBranchEqual, Fehler-
|
||||
code DefaultMessageCodes.RightCheckFailed - Begründung: doppelte Prüfung (Funktion + Filiale)
|
||||
mit eigenem Fehlercode.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs, Zeile 556 – HasUserRight vor Löschen -
|
||||
Begründung: gleiche Prüfidomäne in einer zweiten Domäne.
|
||||
- [SEKUNDÄR] CentronRights.md (kompletter Rechtekatalog mit Konstantennamen) - Begründung: dokumentiert
|
||||
die fachliche Semantik jedes Rechts.
|
||||
- [KONTEXT] UserRightsConst.cs in src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/
|
||||
Rights/ - Begründung: Verzeichnisname „EntitiesWrongPlace" zeigt Schichtverletzung an.
|
||||
Prüfidee: Benutzer Filiale A will Beleg Filiale B bearbeiten → Abweisung mit RightCheckFailed;
|
||||
Web-Account darf keinen Beleg sehen.
|
||||
Tracelinks: StRS-008, StRS-013, StRS-020, SyRS-006, SyRS-007, SwRS-003, SwRS-024, SwRS-025
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - unverzichtbar, das Muster „einschränkendes Recht" ist ausdrücklich übernahmefähig.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-020
|
||||
Titel: Wahrnehmung von Lösch- und Sperrverlangen personenbezogener Daten (DSGVO)
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Datenschutzbeauftragter, Kunde, Administrator
|
||||
Vorbedingung: Anfrage einer Person liegt vor.
|
||||
Fakt: DataSecurityBL stellt personenbezogene Kontakte über SQL-Abfragen fest und ersetzt sie;
|
||||
Konstanten DsgvoDeletedContactMessage = „DSGVO: Auf Anfrage gelöscht." und
|
||||
DsgvoDeletedContactMessageWithEmployeeInfo „… (Durchgeführt von {0} am {1:…})"; Rechte
|
||||
UserRightsConst.DsgvoModule.DSGVO_DELETE_CONTACT; Aufräumläufe mit
|
||||
DataSecurityCleanUpStatsKind, FilterForDeletedCustomers; Vorprüfungen „Insufficient rights!".
|
||||
Aussage: Das System soll auf Löschverlangen betroffene Ansprechpartner und Kunden auffindbar machen,
|
||||
die Löschung nachvollziehbar unter Angabe von Durchführendem und Zeitpunkt durchführen und
|
||||
anschliessend aufräumbare Datenbestände getrennt nach Datenart ausweisen.
|
||||
Ergebnis: Betroffene Person ist nicht mehr rekonstruierbar, der Löschvermerk mit Bearbeiter und Datum
|
||||
bleibt erhalten; Aufräumen ohne Recht wird abgewiesen.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Zeilen 26–27, 37, 67,
|
||||
379–380 (Rechteprüfung DSGVO_DELETE_CONTACT, „Insufficient rights!") - Begründung:
|
||||
Rechteprüfung und Löschvermerk sind dort hart umgesetzt.
|
||||
- [SEKUNDÄR] Tabellen SichProtokoll, SichFields/SichFieldsAssociated, Sichbenu - Begründung: benanntes
|
||||
Modell für sensible Felder und Protokoll.
|
||||
Prüfidee: Nutzer ohne DSGVO_DELETE_CONTACT ruft die Maske auf → „Insufficient rights!"; nach Löschung
|
||||
enthält der Ansprechpartner den Vermerk mit Bearbeiter und Datum.
|
||||
Tracelinks: StRS-019, StRS-025, SyRS-026, SwRS-025
|
||||
Konsolidierung: Kandidat: SwRS-025 – Berechtigungs-, Sperr- und Protokollmodelle sind mehrfach angelegt
|
||||
(Sich*, ChangeLog, CentronLog, ObjectHeritage).
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-021
|
||||
Titel: Sichere Verwahrung von Kunden-Zugangsdaten mit Richtliniendurchgriff
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Servicetechniker, Administratoren, Compliance
|
||||
Vorbedingung: Kunde und Richtlinie sind gepflegt.
|
||||
Fakt: Tabellen PasswordManagement, PasswordManagementAccessLog, PasswordManagementLog,
|
||||
PasswordManagementType/Keyword, PasswordManagerGuidelines mit Zuordnungen zu Kunden,
|
||||
Abteilungen, Mitarbeitern und ausgeschlossen Kunden, PasswordManagerLogs;
|
||||
BL PasswordManagementBL/-UpdateBL/-AccessLogBL; zusätzlich RemoteCredentials, CometCredentials,
|
||||
CometBackupSecretKeys, WasabiCredentials, AccountVPNAccesses.
|
||||
Aussage: Das System soll Zugangsdaten der Kunden zentral verwahren, den Abruf protokollieren und
|
||||
über Richtlinienvorgaben steuern, welche Abteilungen oder Mitarbeiter welche Datenarten sehen.
|
||||
Ergebnis: Jeder Abruf ist protokolliert; Richtlinie und Ausschlussliste steuern die Sichtbarkeit.
|
||||
Belege:
|
||||
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE PasswordManagementAccessLog, PasswordManagementLog,
|
||||
PasswordManagerGuidelineCustomers/-ExcludedCustomers - Begründung: Zugriffsprotokoll und
|
||||
Richtliniendurchgriff sind datenmodelseitig erzwungen.
|
||||
- [SEKUNDÄR] UI-Module Modules/PasswordManager (29 Dateien), PasswordManagementArea (6 BL-Klassen) -
|
||||
Begründung: eigene Bedienoberfläche und BL-Schicht.
|
||||
- [KONTEXT] Tabellen CometBackupSecretKeys, WasabiCredentials - Begründung: Belegt Mehrfachablage von
|
||||
Zugangsdaten je Dienst.
|
||||
Prüfidee: Abruf eines Eintrags durch nicht freigegebenes Profil → kein Klartext, Eintrag im
|
||||
AccessLog; freigegebenes Profil → Abruf wird protokolliert.
|
||||
Tracelinks: StRS-019, SyRS-009, SwRS-025
|
||||
Konsolidierung: Kandidat: StRS-021/SwRS-025 – vier getrennte Zugangsdaten-Haltungen (PasswordManagement,
|
||||
RemoteCredentials, CometCredentials, WasabiCredentials) für dieselbe Funktion.
|
||||
Übernahmewürdigkeit: übernehmen (Funktion) / Workaround (parallele Ablagen)
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-022
|
||||
Titel: Steuerung des Unternehmens über Statistiken, Auslastung und Controlling
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Geschäftsführung, Abteilungsleitung, Disponent
|
||||
Vorbedingung: Vorgangsdaten sind erfasst; Auswertungsrollen sind zugeordnet.
|
||||
Fakt: Statistiktabellen StatisticHelpdesk(-Details), StatisticStock, StatisticAssetDay/Year/
|
||||
YearMonth, StatisticManagement*, StatisticRolesToEmployee/ToStatistics, CacheOrderStatistic,
|
||||
CacheSalesStatistic, CacheTicketStatistic, CacheMspArticleStatistics, ControllingAuswertung,
|
||||
ConsultingUmsatz, EmployeeStatistic, Consultant-Umsatz; Rechte RIGHT_MITARBEITERAUSLASTUNG
|
||||
und RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE; UI Module/Statistics (141), MyDay (211).
|
||||
Aussage: Das System soll Vertriebs-, Service-, Bestands- und Personal-Kennzahlen zeitlich
|
||||
aufbereitet bereitstellen, die Mitarbeiterauslastung sichtbar machen und die Sicht nach
|
||||
Rolle und Filiale begrenzen.
|
||||
Ergebnis: Kennzahlen sind je Rolle wählbar und je Filiale eingeschränkt; vorberechnete Kennzahlen
|
||||
sind als Cache hinterlegt.
|
||||
Belege:
|
||||
- [PRIMÄR] CentronRights.md „Mitarbeiterauslastung" – RIGHT_MITARBEITERAUSLASTUNG und
|
||||
RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE als restriktives Recht - Begründung:
|
||||
Zugriffssteuerung der Auswertung ist dokumentiert und über Konstanten erzwungen.
|
||||
- [SEKUNDÄR] Tabellen Statistic* und Cache*Statistic - Begründung: zwei Bereitstellungswege
|
||||
(Vorberechnung und Caching).
|
||||
Prüfidee: Nutzer ohne RIGHT_MITARBEITERAUSLASTUNG sieht keine Kollegen-Auslastung; Nutzer mit
|
||||
Filialrecht sieht nur eigene Filiale.
|
||||
Tracelinks: StRS-013, StRS-019, SyRS-024
|
||||
Konsolidierung: Kandidat: StRS-015 – Kennzahlen liegen in Statistiktabellen und Cache-Tabellen doppelt.
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-023
|
||||
Titel: Selbstbedienung der Kunden: Shop, Angebotseinsicht, Auftragsfreigabe, Portal
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Endkunde des Kunden, Web-Account-Inhaber, Innendienst
|
||||
Vorbedingung: Web-Account mit Kunde und Sonderpreisliste ist angelegt.
|
||||
Fakt: README.md: „The webcart is a feature primarily intended for the customers of our customers …
|
||||
available if you login as a web-account … The available articles come from the customers
|
||||
'Sonderpreise'"; WebShopEinstellungen/WebShopKopf/WebShopPos/WebShopZuordnung,
|
||||
WebKunden, WebAccounts/WebAccountsRights/WebRights/WebRightsCategories;
|
||||
Zustandsmaschine WebReceiptState { InProcess, SendToCustomer, AcceptFullWebReceipt,
|
||||
AcceptWebReceiptWithChangeRequests, Rejected, WebOfferSign, WebOfferSignedWithoutSignature,
|
||||
WebReceiptShutDown }; WebRecepItemChangeRequests, ReceiptBL-Zeile 5932
|
||||
„Web Receipt State is not accepted."; SelfCareForms* Tabellen, Nexus WebCart (74 Dateien)
|
||||
und WebOffer (10 Dateien).
|
||||
Aussage: Das System soll Kunden im Web eigene Artikel- und Preiskonditionen anbieten, Angebote zur
|
||||
Annahme bereitstellen, Änderungen als Änderungswunsch entgegennehmen und die Freigabe
|
||||
statusgeführt protokollieren; Kundenportal-Formulare sind konfigurierbar.
|
||||
Ergebnis: Kunde sieht ausschliesslich Artikel und Preise seiner Konditionen; eine Annahme erzeugt
|
||||
den Folgevorgang im Innendienst; abgelehnte oder geänderte Angebote werden dem Sachbearbeiter
|
||||
zurückgespielt.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetReceiptByI3D: bei
|
||||
IsWebAccountLogin und abweichender CustomerI3D wird null zurückgegeben; CreateNewReceipt:
|
||||
„Keine Berechtigung"; Zeile 5932 InvalidEnumArgumentException „Web Receipt State is not accepted." -
|
||||
Begründung: Mandantentrennung und Freigabemaschine werden im Code erzwungen.
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/WebReceipt/WebReceiptState.cs - Begründung:
|
||||
abschliessende Zustandsmenge des Freigabeprozesses.
|
||||
- [SEKUNDÄR] README.md Abschnitt „WebCart" - Begründung: nennt Zweck und Datenquelle (Sonderpreise).
|
||||
- [SEKUNDÄR] Tabellen SelfCareForms, SelfCareFormFields, SelfCareFormStates, SelfCareFormTicketPattern -
|
||||
Begründung: Konfigurierbarkeit des Portals.
|
||||
Prüfidee: Web-Account Kunde A fragt Beleg von Kunde B ab → null/„Keine Berechtigung"; Annahme eines
|
||||
Web-Angebots erzeugt Auftrag und Status WebReceiptShutDown für den Link.
|
||||
Tracelinks: StRS-005, StRS-011, StRS-019, SyRS-008, SyRS-028, SyRS-032, SwRS-033
|
||||
Konsolidierung: Kandidat: StRS-012 – Angebotsfreigabe im Web und Angebot als Beleg sind zwei Sichten
|
||||
desselben Vorgangs.
|
||||
Übernahmewürdigkeit: übernehmen - zentraler Differenzierer des Produkts.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-024
|
||||
Titel: Abbildung von Organisation, Prozessen und Projekten im System
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Projektleiter, Abteilungsleitung, Mitarbeiter
|
||||
Vorbedingung: Abteilungen, Teams, Projekte und Aufgaben sind gepflegt.
|
||||
Fakt: Tabellen Projekt* (Projekt, ProjektPhasen, ProjektPhasenAufgaben inkl.
|
||||
ProjektPhasenAufgabenAbhaengigkeit, ProjektBeteiligte, ProjektMa*), CRMProjekt*,
|
||||
TicketProjects/-Tasks/-Dependencies, TaskManagementTask mit Actions (Checklist, Customer,
|
||||
Department, Device, Report, Substitute), Checklists*/RBChecklist*, Termine/Terminplanung*,
|
||||
PersonalTeams (EmployeeTeam), ToDoListe*, MyDayWorkItems; UI Module/ProjectManagement.
|
||||
Aussage: Das System soll interne und kundenbezogene Vorhaben mit Phasen, Aufgaben, Abhängigkeiten,
|
||||
Beteiligten und Wiedervorlagen führen und die Tagesarbeit eines Mitarbeiters bündeln.
|
||||
Ergebnis: Aufgaben sind Rollen und Objekten (Kunde, Gerät, Abteilung) zugeordnet; Phasenabhängigkeiten
|
||||
steuern Fälligkeiten.
|
||||
Belege:
|
||||
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ProjektPhasenAufgabenAbhaengigkeit,
|
||||
TaskManagementActionChecklist, TaskManagementActionSubstitute - Begründung: Abhängigkeits- und
|
||||
Vertretungslogik ist datenmodelseitig erzwungen.
|
||||
- [SEKUNDÄR] UI Module/ProjectManagement, MyDay (211 Dateien), TaskManager BL (4 Klassen) - Begründung:
|
||||
eigene Oberflächen für Projekt- und Tagesgeschäft.
|
||||
Prüfidee: Aufgabe B von Aufgabe A abhängig machen; Verschieben von A verschiebt Fälligkeit von B.
|
||||
Tracelinks: StRS-013, StRS-007, StRS-022
|
||||
Konsolidierung: Kandidat: StRS-013 – Vorgangssteuerung existiert dreifach (Ticket, TaskManagement,
|
||||
Projektverwaltung).
|
||||
Übernahmewürdigkeit: übernehmen (Funktionsumfang); die Dreifachanlage ist Konsolidierungskandidat.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-025
|
||||
Titel: Lückenlose Nachvollziehbarkeit fachlicher Änderungen
|
||||
Ebene: StRS
|
||||
Typ: funktional / Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Sachbearbeiter, Revision, Geschäftsführung
|
||||
Vorbedingung: Ein Vorgangsobjekt wird geändert.
|
||||
Fakt: ReceiptBL.WriteReceiptLogs erzeugt je geändertem Attribut einen eigenen Logeintrag
|
||||
(CreateContingentKindEntry, CreateContingentValueEntry, …); ReceiptLogBL.CreateReportEntry
|
||||
protokolliert jeden Druckversand; Tabellen ChangeLog, CentronLog, CentronWebLog, WebLog,
|
||||
ObjectHeritage, GlobalLog, ExceptionLog, *History-Tabellen (WartungHistory*, RepaKopfHistory,
|
||||
GeraeteWartungHistory), XMLLockList, CachedTableStatistics; UI Ordner Logs.
|
||||
Aussage: Das System soll jede fachlich relevante Änderung an Belegen, Verträgen, Wartungsobjekten
|
||||
und Dokumenten mit Alt-/Neuwert, Bearbeiter und Zeitpunkt protokollieren und die Protokolle
|
||||
bedienbar halten.
|
||||
Ergebnis: Änderungen sind je Attribut rekonstruierbar; Druck- und Versandvorgänge sind je Beleg
|
||||
abrufbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, WriteReceiptLogs – Attribut-für-Attribut-
|
||||
Vergleich mit vorheriger Fassung und Logschreibung - Begründung: erzwungene Protokollierung.
|
||||
- [SEKUNDÄR] Tabellen ChangeLog, CentronLog, ObjectHeritage, *History - Begründung: mehrere, getrennte
|
||||
Protokollspeicher.
|
||||
Prüfidee: Kontingentwert eines Vertrags ändern → genau ein Logeintrag mit altem/neuem Wert,
|
||||
Bearbeiter, Zeitstempel.
|
||||
Tracelinks: StRS-011, StRS-019, StRS-020, SyRS-025, SwRS-025
|
||||
Konsolidierung: Kandidat: SwRS-025, StRS-020
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-026
|
||||
Titel: Kundenspezifische Erweiterbarkeit ohne Eingriff in den Quellcode
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Anpassbarkeit / Wartbarkeit (ISO/IEC 25010)
|
||||
Akteur: Mandantenbetreuer, Administrator
|
||||
Vorbedingung: Mandant benötigt zusätzliche Felder, Masken, Berichte oder Regeln.
|
||||
Fakt: Module/Customizations (CustomTableBL), Tabellen ModuleCustomProperties/
|
||||
ModuleCustomPropertyPossibleValues/ModuleCustomPropertyValues, ObjectFields, ObjectMappings,
|
||||
Stammdatfelder, SharedData, ApplicationSettings/AppSettingsConst-Schlüssel,
|
||||
Administration/Scripts mit 790 Skriptdateien (ScriptMethod*), CentronConstant/
|
||||
CentronConstantTypen, MassUpdateTemplate, ReportDataQueries/ReportGroups konfigurierbar.
|
||||
Aussage: Das System soll zusätzliche Felder, Auswahlwerte, Berichtedefinitionen, Masken und
|
||||
Regellogik je Mandant konfigurativ oder per Skript ermöglichen, ohne dass der Kern geändert
|
||||
werden muss.
|
||||
Ergebnis: Neue Felder erscheinen in Maske, Suche, Bericht und Übergabe an die Buchhaltung; sie sind
|
||||
beim Weiterverarbeiten von Belegen übertragbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Aufruf
|
||||
ModuleCustomPropertyValueBL.GetTransferableCustomPropertyValues(...) in CopyReceipt und
|
||||
ForwardReceipt - Begründung: erzwingt die Mitnahme kundeneigener Felder über Belegketten.
|
||||
- [SEKUNDÄR] src/backend/Centron.BL/Administration/Scripts (790 Dateien) - Begründung: Skriptlaufzeit-
|
||||
umgebung als Erweiterungspunkt.
|
||||
- [KONTEXT] .editorconfig, Directory.Build.props, Customizations-Modul - Begründung: belegen
|
||||
Mehrmandantenfähigkeit als Konstruktionsziel.
|
||||
Prüfidee: Custom-Feld an Auftrag anlegen, Auftrag zu Lieferschein weiterverarbeiten → Wert ist im
|
||||
Folgebeleg vorhanden.
|
||||
Tracelinks: StRS-003, SyRS-031, SwRS-019, SwRS-020
|
||||
Konsolidierung: Kandidat: SwRS-020 – benutzerdefinierte Felder existieren als Custom-Properties, Custom
|
||||
Tables und Stammdatfelder in drei Mechanismen.
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
## Abgrenzung zu SyRS/SwRS
|
||||
|
||||
Die obenstehenden Anforderungen beschreiben **was** das System fachlich leisten muss und **warum**.
|
||||
Die technische Ausgestaltung – Schnittstellenverhalten, Berechtigungsdurchsetzung an konkreten Stellen,
|
||||
Performance, Protokolliermenge – ist auf den Ebenen SyRS (`SyRS.md`) und SwRS (`SwRS.md`) spezifiziert.
|
||||
Doppelbeschreibungen desselben Sachverhalts aus verschiedener Ebenensicht sind bewusst keine
|
||||
Konsolidierungsfälle; sie sind über `Tracelinks` verbunden.
|
||||
|
||||
|
||||
+1164
File diff suppressed because it is too large
Load Diff
+1135
File diff suppressed because it is too large
Load Diff
+148
@@ -0,0 +1,148 @@
|
||||
# Traceability – Forward- und Rückwärtsverfolgung
|
||||
|
||||
c-entron ERP-Suite · Reverse Requirements Engineering · ISO/IEC/IEEE 29148:2018
|
||||
|
||||
Regeln dieses Laufs:
|
||||
- Jede SwRS-Anforderung referenziert genau eine tragende SyRS-Anforderung.
|
||||
- Jede SyRS-Anforderung referenziert genau eine tragende StRS-Anforderung.
|
||||
- Die Spalte „Artefaktbeleg" nennt den **primären** Beleg (durchsetzende Stelle), nicht die Vollständigkeit.
|
||||
|
||||
## 1. Konsolidierte Traceability-Tabelle
|
||||
|
||||
| StRS-ID | StRS-Kurztitel | SyRS-ID | SyRS-Kurztitel | SwRS-ID | SwRS-Kurztitel | Primärer Artefaktbeleg |
|
||||
|---|---|---|---|---|---|---|
|
||||
| StRS-001 | Vertriebsprozess Angebot→Rechnung | SyRS-001 | Weiterverarbeitung mit Kettenprüfung | SwRS-001 | Generischer Belegkern + Strategien | `ReceiptBL.cs` · CanForwardReceiptsInto, ValidateReceiptForwarding |
|
||||
| StRS-001 | – | SyRS-003 | Nummernkreise je Mandant/Filiale | SwRS-007 | Read-Modify-Write-Zählertabelle | `NumberGroupBL.cs` · GetNextNumber (Z. 50–89) |
|
||||
| StRS-001 | – | SyRS-018 | Versandsteuerung/Fracht | – | – | `FreightArticleSettingBL.cs`, `ShipcloudPackageTemplateBL.cs` |
|
||||
| StRS-002 | Beschaffung Einkauf→Rechnung | SyRS-002 | Bearbeitungslock/Parallelität | SwRS-008 | Zwei Parallelitätsmechanismen | `ReceiptBL.cs` · CreateLock/RemoveLock, ConcurrencyControlGuid |
|
||||
| StRS-002 | – | SyRS-016 | EDI zu Distributoren | – | – | `SupplierEdiBL.*.cs` (6 Partial-Klassen) |
|
||||
| StRS-002 | – | SyRS-017 | Fremdartikelsuche/Kataloge | – | – | `IExternalArticleSearchProvider.cs` + 3 Anbieter |
|
||||
| StRS-003 | Mandanten- und Filialfähigkeit | SyRS-003 | Nummernkreise | SwRS-007 | Nummernkreisvergabe | `NumberGroupBL.cs` · CreateNumberGroups(mandantI3D, branchI3D) |
|
||||
| StRS-003 | – | SyRS-011 | Filialzugehörigkeit in Datenzugriffen | SwRS-023 | Filialgleichheit mit Default-Semantik | `ReceiptBL.cs` · CanUserCreateReceiptsInBranch (Z. 10251) |
|
||||
| StRS-003 | – | SyRS-027 | Lizenzprüfung beim Start | – | – | `LicenseManager.cs` · SettingsForCentronNet, Public-Key-Prüfung |
|
||||
| StRS-003 | – | – | – | SwRS-026 | Mandantenstammdaten als Ausgabekopf | `ReceiptBL.cs` · ExportReceiptToExcel (MandatorBL) |
|
||||
| StRS-004 | Einheitlicher Geschäftspartnerstamm | SyRS-011 | Filial/Mandantenzugehörigkeit | SwRS-016 | 14fache Datenhaltung Artikel/Lager | `SSMS_DB_SCHEMA.sql` · Accounts/AccountTypes/Kunden/Kreditor |
|
||||
| StRS-005 | Kundenindividuelle Preise | SyRS-004 | Vorrangfolge der Preisermittlung | SwRS-004 | Preiskomponente mit Cache | `ReceiptItemPriceBL.cs` · GetBasePrice (Z. 144 ff.) |
|
||||
| StRS-005 | – | SyRS-004 | – | SwRS-031 | Invertierte Vorzeichenkonvention | `ReceiptItemPriceBL.cs` Z. 181–223 („values are inverted") |
|
||||
| StRS-006 | Vertrags-/Kontingentgeschäft | SyRS-001 | Weiterverarbeitung (ContractClass) | SwRS-002 | Status- und Versionsmodell | `ReceiptBL.cs` · WriteReceiptLogs (Contingent-*) |
|
||||
| StRS-006 | – | SyRS-001 | – | SwRS-032 | Dreistufige Konditionsauflösung | `ReceiptBL.cs` · GetDefaultPaymentCondition (Priority 1–3) |
|
||||
| StRS-007 | Servicezeiterfassung mit Signatur | SyRS-022 | Schutz gebuchter Servicezeiten | SwRS-012 | Löschschutz über Belegzuordnung | `HelpdeskTimerBL.cs` Z. 550–570 |
|
||||
| StRS-008 | Mahnwesen mit Belegsperre | SyRS-005 | Beleganlag sperre ab Mahnstufe | SwRS-014 | Mahnstufenherkunft + Lieferanten-Ausnahme | `ReceiptBL.cs` · CanUserCreateNewReceiptsAtCustomerOrSupplier (Z. 10194) |
|
||||
| StRS-008 | – | SyRS-023 | Mahnlauf mit Berichtspflicht | SwRS-014 | – | `DunningRunBL.cs` Z. 150–153 (ReportGroupConstants.MAHNUNG) |
|
||||
| StRS-009 | Übergabe an die FiBu | SyRS-015 | Konfigurierbarer Buchungsexport | SwRS-028 | Je Format Tabelle + Codezweig | `BookKeepingExportBL.cs` Z. 441–449, 789 |
|
||||
| StRS-009 | – | SyRS-019 | Onlinebanking/Zahlungszuordnung | SwRS-027 | Kassenbuch mit Zählhilfe | `SSMS_DB_SCHEMA.sql` · OnlineBankingTransactionAssignments |
|
||||
| StRS-010 | Automatisierte/Pauschalabrechnung | SyRS-001 | Weiterverarbeitung | SwRS-006 | Anzahlung/Schlussrechnung im Pfad | `ReceiptBL.cs` · DownPayment-Region in ValidateReceiptForwarding |
|
||||
| StRS-011 | Revisionssichere Belegfassung | SyRS-002 | Lock und Parallelität | SwRS-002 | Drei Zustände + Versions-Tabellen | `ReceiptState.cs`, `ReceiptBL.cs` · CreateNewVersion |
|
||||
| StRS-011 | – | SyRS-012 | Reportgruppen/Vorschau per Rollback | SwRS-022 | Berichtsystem Gruppen/Abfragen/Parameter | `ReceiptBL.cs` · CreateReportPreviewForReceipt (Rollback) |
|
||||
| StRS-012 | ZUGFeRD und Signatur | SyRS-013 | ZUGFeRD mit Leitweg-ID | SwRS-021 | ZUGFeRD-/Signaturzweig im Ausgabepfad | `ReceiptBL.cs` · CreateFullReportForReceipt (ZUGFeRD-Zweig) |
|
||||
| StRS-012 | – | SyRS-014 | Signatur beim Versand | SwRS-021 | – | `PdfSigningBL.cs` · SignPdfDocument, IsPdfSigningAvailable |
|
||||
| StRS-013 | Helpdesk/Ticket mit Eskalation | SyRS-006 | Prüfung in der Geschäftslogik | SwRS-018 | Doppelte Helpdesk-Datenhaltung | `CentronRights.md` §1.1/§1.2, `AppRightsBL.HasUserRight` |
|
||||
| StRS-013 | – | SyRS-022 | Schutz gebuchter Zeiten | SwRS-012 | – | `HelpdeskTimerBL.cs` Z. 556 |
|
||||
| StRS-013 | – | SyRS-029 | Outlook/Telefonie/Mobil | – | – | `SSMS_DB_SCHEMA.sql` · GroupwareEntryIDs, CTRCalls |
|
||||
| StRS-014 | IT-Assetlebenszyklus | SyRS-020 | Seriennummern-Eindeutigkeit | SwRS-017 | Drucker-Stamtblatt vs. Asset | `SSMS_DB_SCHEMA.sql` · Printer (Z. 46837) vs. AssetManagementDevices (Z. 6050) |
|
||||
| StRS-014 | – | SyRS-021 | Bestands-/Nebenlager/Inventur | – | – | `InventoryBL.cs`, `SecondStockArticleBL.cs` |
|
||||
| StRS-015 | IT-Stammdaten aus Fremdsystemen | SyRS-029 | Outlook/Telefonie/Mobil | – | – | `SSMS_DB_SCHEMA.sql` · CManThreshold, MonitoringDataFailures |
|
||||
| StRS-016 | Seriennummern-Nachverfolgbarkeit | SyRS-020 | Eindeutigkeit/Buchung/Zustand | SwRS-013 | Doppelhaltung Barcode/BarCode2 | `BarcodeBL.cs` Z. 634, 740, 73–90, 575, 788, 1078 |
|
||||
| StRS-016 | – | SyRS-020 | – | SwRS-030 | Integrität im Code statt DB | `SSMS_DB_SCHEMA.sql` · 1535 Tabellen / 21 UNIQUE |
|
||||
| StRS-017 | Warenwirtschaft | SyRS-017 | Fremdartikel/Kataloge | SwRS-016 | Mehrfache Artikel-/Lagerwelten | `SSMS_DB_SCHEMA.sql` · Artikel/ARTIK/ARTIKALT/WareN |
|
||||
| StRS-017 | – | SyRS-021 | Bestandsführung | SwRS-029 | Zwei Inventurimplementierungen | `InventoryBL.cs` + `InventoryNewBL.cs` |
|
||||
| StRS-018 | RMA/Reparatur/Geräteprüfung | SyRS-020 | Seriennummern | – | – | `SSMS_DB_SCHEMA.sql` · RMAPosStatus, PrufvorschriftMesswert |
|
||||
| StRS-019 | Rollen-, Filial-, Bereichssteuerung | SyRS-006 | Prüfung in der BL mit RightCheckFailed | SwRS-003 | Private Berechtigungsmethoden im Belegkern | `ReceiptBL.cs` · CanUserEditReceipt (Z. 10272) |
|
||||
| StRS-019 | – | SyRS-007 | REST 401/403-Filter | SwRS-024 | Rechtekatalog als Konstanten, falsche Schicht | `AuthorizeUserRightAttribute.cs` Z. 38–52 |
|
||||
| StRS-019 | – | SyRS-008 | Web-Account-Isolation | SwRS-033 | Web-Freigabezustände | `ReceiptBL.cs` · GetReceiptByI3D (WebAccount-Zweig) |
|
||||
| StRS-019 | – | SyRS-009 | Mehrwege-Authentifizierung + 2FA | SwRS-009 | SHA-1-Passwortableitung | `AuthenticatorFactory.cs`, `ITwoFactorValidator.cs` |
|
||||
| StRS-019 | – | SyRS-010 | Kennworthärte | SwRS-010 | Benutzerindividuelle Mindestlänge | `UsersBL.cs` · IsValidAppUserPassword (Z. 124–128) |
|
||||
| StRS-019 | – | SyRS-010 | – | SwRS-011 | Separate 8-Zeichen-Grenze Web-Konten | `WebAccountBL.cs` · UpdatePassword (Z. 183–193) |
|
||||
| StRS-019 | – | SyRS-011 | Filialzugehörigkeit | SwRS-023 | Filialgleichheit | `ReceiptBL.cs` · CanUserEditReceipt (IsBranchEqual) |
|
||||
| StRS-019 | – | SyRS-028 | Nexus als zweiter Zugang | SwRS-034 | Schichtaufbau/Hostvarianten | `SSMS_DB_SCHEMA.sql` · WebRights, WebMenuConfig |
|
||||
| StRS-020 | DSGVO-Löschrecht | SyRS-026 | Lösch- und Aufräumfunktionen | SwRS-025 | Zersplitterte Protokoll-/Schutzmodelle | `DataSecurityBL.cs` Z. 26–27, 37, 67, 379 |
|
||||
| StRS-021 | Passworttresor | SyRS-009 | Authentifizierung | SwRS-025 | Schutzmodelle | `SSMS_DB_SCHEMA.sql` · PasswordManagementAccessLog |
|
||||
| StRS-022 | Statistiken/Auslastung/Controlling | SyRS-024 | Leistungsfähigkeit bei Massen reads | SwRS-004 | Cache-Modus Preiskomponente | `CentronRights.md` (RIGHT_MITARBEITERAUSLASTUNG), `ReceiptItemPriceBL.cs` |
|
||||
| StRS-023 | Kunden-Selbstbedienung | SyRS-008 | Datensatzebene Isolation | SwRS-033 | Zustandsmaschine Freigabe | `WebReceiptState.cs`, `ReceiptBL.cs` Z. 5932, 6198 |
|
||||
| StRS-023 | – | SyRS-028 | Nexus/Webshop | SwRS-034 | – | `src/nexus/CentronNexus/WebCart` (74 Dateien) |
|
||||
| StRS-023 | – | SyRS-032 | Angebotsfreigabe-Workflow | SwRS-033 | – | `ReceiptBL.cs` · ShutdownEventuallyWebOfferLinks |
|
||||
| StRS-024 | Organisation/Prozesse/Projekte | SyRS-029 | Outlook/Telefonie/Mobil | – | – | `SSMS_DB_SCHEMA.sql` · ProjektPhasenAufgabenAbhaengigkeit |
|
||||
| StRS-025 | Lückenlose Nachvollziehbarkeit | SyRS-012 | Reporting/Vorschau | SwRS-022 | Berichtsystem | `ReceiptBL.cs` · CreateReportPreviewForReceipt |
|
||||
| StRS-025 | – | SyRS-025 | Protokollierung Fach/System/Ausnahme | SwRS-025 | Protokollmodelle | `ReceiptBL.cs` · _logger.Error + Fortsetzung des Pfads |
|
||||
| StRS-026 | Mandantenerweiterbarkeit ohne Code | SyRS-030 | Schema-/Versionsanpassung | SwRS-034 | Host-/Deploymentvarianten | `SSMS_DB_SCHEMA.sql` · DBUpdate, ApplicationVersions |
|
||||
| StRS-026 | – | SyRS-031 | Laufzeit-Felderweiterung | SwRS-019 | Skriptlaufzeit ScriptMethods | `ReceiptBL.cs` · GetTransferableCustomPropertyValues |
|
||||
| StRS-026 | – | SyRS-031 | – | SwRS-020 | Drei Feldmechanismen | `SSMS_DB_SCHEMA.sql` · ModuleCustomProperties, Stammdatfelder |
|
||||
|
||||
## 2. Rückwärtssicht: SyRS → SwRS
|
||||
|
||||
| SyRS-ID | SwRS-Anforderungen, die sie umsetzen |
|
||||
|---|---|
|
||||
| SyRS-001 | SwRS-001, SwRS-005, SwRS-006, SwRS-032 |
|
||||
| SyRS-002 | SwRS-002, SwRS-008 |
|
||||
| SyRS-003 | SwRS-007, SwRS-030 |
|
||||
| SyRS-004 | SwRS-004, SwRS-031 |
|
||||
| SyRS-005 | SwRS-014 |
|
||||
| SyRS-006 | SwRS-003, SwRS-012, SwRS-024 |
|
||||
| SyRS-007 | SwRS-024, SwRS-034 |
|
||||
| SyRS-008 | SwRS-033 |
|
||||
| SyRS-009 | SwRS-009, SwRS-010 |
|
||||
| SyRS-010 | SwRS-009, SwRS-010, SwRS-011 |
|
||||
| SyRS-011 | SwRS-023 |
|
||||
| SyRS-012 | SwRS-021, SwRS-022 |
|
||||
| SyRS-013 | SwRS-021 |
|
||||
| SyRS-014 | SwRS-021 |
|
||||
| SyRS-015 | SwRS-027, SwRS-028 |
|
||||
| SyRS-016 | SwRS-001 |
|
||||
| SyRS-017 | SwRS-016 |
|
||||
| SyRS-018 | – (nur SyRS-Ebene, kein SwRS-Kandidat identifiziert) |
|
||||
| SyRS-019 | SwRS-027, SwRS-028 |
|
||||
| SyRS-020 | SwRS-013, SwRS-030 |
|
||||
| SyRS-021 | SwRS-029 |
|
||||
| SyRS-022 | SwRS-012 |
|
||||
| SyRS-023 | SwRS-014 |
|
||||
| SyRS-024 | SwRS-004 |
|
||||
| SyRS-025 | SwRS-025 |
|
||||
| SyRS-026 | SwRS-025 |
|
||||
| SyRS-027 | – (Lizenzkomponente ist externe Bibliothek, keine eigene SwRS-Anforderung gebildet) |
|
||||
| SyRS-028 | SwRS-034 |
|
||||
| SyRS-029 | – (Schnittstellenbereich, nur SyRS) |
|
||||
| SyRS-030 | SwRS-034 |
|
||||
| SyRS-031 | SwRS-019, SwRS-020 |
|
||||
| SyRS-032 | SwRS-033 |
|
||||
|
||||
SyRS-018, SyRS-027 und SyRS-029 haben bewusst keine SwRS-Entsprechung: Sie beschreiben
|
||||
Schnittstellenverhalten beziehungsweise Verhalten einer eingekauften Komponente, zu dem die
|
||||
Codebasis keine eigenständige, belegbare Implementierungsregel enthält.
|
||||
|
||||
## 3. Rückwärtssicht: StRS → SyRS
|
||||
|
||||
| StRS-ID | SyRS-Anforderungen |
|
||||
|---|---|
|
||||
| StRS-001 | SyRS-001, SyRS-003, SyRS-018 |
|
||||
| StRS-002 | SyRS-002, SyRS-016, SyRS-017 |
|
||||
| StRS-003 | SyRS-003, SyRS-011, SyRS-027 |
|
||||
| StRS-004 | SyRS-011 |
|
||||
| StRS-005 | SyRS-004 |
|
||||
| StRS-006 | SyRS-001 |
|
||||
| StRS-007 | SyRS-022 |
|
||||
| StRS-008 | SyRS-005, SyRS-023 |
|
||||
| StRS-009 | SyRS-015, SyRS-019 |
|
||||
| StRS-010 | SyRS-001 |
|
||||
| StRS-011 | SyRS-002, SyRS-012 |
|
||||
| StRS-012 | SyRS-013, SyRS-014 |
|
||||
| StRS-013 | SyRS-006, SyRS-022, SyRS-029 |
|
||||
| StRS-014 | SyRS-020, SyRS-021 |
|
||||
| StRS-015 | SyRS-029 |
|
||||
| StRS-016 | SyRS-020 |
|
||||
| StRS-017 | SyRS-017, SyRS-021 |
|
||||
| StRS-018 | SyRS-020 |
|
||||
| StRS-019 | SyRS-006, SyRS-007, SyRS-008, SyRS-009, SyRS-010, SyRS-011, SyRS-028 |
|
||||
| StRS-020 | SyRS-026 |
|
||||
| StRS-021 | SyRS-009 |
|
||||
| StRS-022 | SyRS-024 |
|
||||
| StRS-023 | SyRS-008, SyRS-028, SyRS-032 |
|
||||
| StRS-024 | SyRS-029 |
|
||||
| StRS-025 | SyRS-012, SyRS-025 |
|
||||
| StRS-026 | SyRS-030, SyRS-031 |
|
||||
|
||||
## 4. Anforderungen mit ausschliesslich indirekter Beleglage
|
||||
|
||||
Keine Anforderung dieses Sets ist ausschliesslich mit `SEKUNDÄR` oder `KONTEXT` belegt; jede führt
|
||||
mindestens einen `PRIMÄR`-Beleg. Der Anteil schwacher Belege konzentriert sich auf die
|
||||
Schnittstellenmodule (SyRS-016, SyRS-017, SyRS-019, SyRS-029) und auf StRS-014/StRS-015 – Details
|
||||
im Abschnitt „Belegqualität" von `Analysebericht.md`.
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
# Abbruchanalyse
|
||||
|
||||
- **Status:** manuell abgebrochen; ungültige Fehlmessung
|
||||
- **Abbruchzeit:** 2026-08-31T17:46:24.3204372+02:00
|
||||
- **Grund:** TensorX meldete nach Angabe des Betreibers seit rund 30 Minuten keine Inferenz; lokal war seit 17:15:42 kein Artefaktfortschritt erkennbar.
|
||||
- **Beendete Prozesse:** Python-Adapter PID 53764 sowie die danach hängenden PowerShell-Wrapper PID 57932 und PID 26076.
|
||||
- **Codebasis:** unverändert; der pfadskopierte Git-Status für `QuellCode/CentronERP` war nach dem Abbruch sauber.
|
||||
|
||||
## Vorhandene Teilergebnisse
|
||||
|
||||
Vier von sieben Pflichtdateien wurden vollständig wirkend geschrieben:
|
||||
|
||||
| Datei | Bytes | Letzte Änderung |
|
||||
|---|---:|---|
|
||||
| `StRS.md` | 62.799 | 17:10:56 |
|
||||
| `SyRS.md` | 75.072 | 17:12:31 |
|
||||
| `SwRS.md` | 74.193 | 17:14:53 |
|
||||
| `Traceability.md` | 12.542 | 17:15:42 |
|
||||
|
||||
Es fehlen `Hypothesen.md`, `Glossar.md` und `Analysebericht.md`. Damit sind insbesondere Konsistenzcheck, Selbstbewertung, Abdeckungsnachweis und die geschlossene Hypothesenliste nicht erbracht.
|
||||
|
||||
## Fehlende Messdaten
|
||||
|
||||
`RawResult.json` wurde nicht geschrieben, weil der Adapter die normalisierten Messdaten erst nach dem Ende des Agent-Loops persistiert. Tokenverbrauch, Turn-Zahl, Tool-Calls, Subagentenstatistik und der genaue letzte API-/Subagentenzustand sind deshalb nicht rekonstruierbar und werden nicht geschätzt.
|
||||
|
||||
`Stderr.log` blieb leer. Der über Windows PowerShell 5.1 umgeleitete native Fehlerstrom wurde trotz Flushes im Python-Prozess nicht sichtbar fortgeschrieben. Nach dem erzwungenen Beenden der hängenden Wrapper ging der gepufferte Inhalt verloren.
|
||||
|
||||
## Ursachenanalyse
|
||||
|
||||
Die unmittelbare Ursache war ein nicht selbst terminierender Adapterzustand. Der Lauf wurde mit `--timeout 0` gestartet; der Adapter übersetzt dies für `requests.post` in `timeout=None`. Dadurch existiert weder für den Hauptagenten noch für Subagenten eine obere Wartezeit auf eine TensorX-Antwort. Der Hauptagent wartet außerdem auf alle Futures einer parallel gestarteten Subagentengruppe. Ein einzelner hängender HTTP-Aufruf kann daher den gesamten Lauf unbegrenzt blockieren.
|
||||
|
||||
Ob konkret der Hauptagent oder ein Subagent in einem HTTP-Aufruf hing, lässt sich wegen der fehlenden inkrementellen Messdaten und des leeren Logs nicht beweisen. Belastbar sind nur: vier abgeschlossene Datei-Schreibvorgänge, danach mehr als 30 Minuten ohne Artefaktfortschritt, kein Abschlussobjekt und die externe Meldung fehlender Inferenz.
|
||||
|
||||
## Empfohlene technische Korrekturen vor einer Wiederholung
|
||||
|
||||
1. Endlichen Connect-/Read-Timeout für jeden TensorX-Aufruf setzen und Timeoutfehler in ein partielles Ergebnis überführen.
|
||||
2. Nach jedem API-Turn und jedem Subagentenabschluss ein flushendes JSONL-Checkpoint schreiben, statt sämtliche Metriken nur im Speicher zu halten.
|
||||
3. Den Adapter selbst in eine Logdatei schreiben lassen; native stderr nicht über Windows PowerShell 5.1 puffern.
|
||||
4. `KeyboardInterrupt` beziehungsweise ein Abbruchsignal abfangen und dabei `RawResult.json` mit Status `aborted` und den bis dahin akkumulierten Metriken persistieren.
|
||||
5. Für parallele Subagenten einen Watchdog vorsehen, der den betroffenen Future identifiziert und beendet, ohne den gesamten Lauf unbegrenzt warten zu lassen.
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+219
@@ -0,0 +1,219 @@
|
||||
# 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 und Suchen im Arbeitsverzeichnis, schreibgeschützte
|
||||
Kommandozeilenbefehle, das Schreiben von Ergebnisdateien im unten genannten Ausgabeverzeichnis
|
||||
sowie acht beigestellte Agentenrollen.
|
||||
Nicht verfügbar sind: externe Werkzeugserver, Webzugriff, Skills und Slash-Kommandos.
|
||||
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 und legen keine
|
||||
Ergebnisdateien an; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen bleiben
|
||||
deine Aufgabe. Die Bearbeiter delegieren nicht weiter — nur du beauftragst.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 2\qwen\qwen3.8-flash-next\custom\low\01_Lauf_2026-08-31_165317_v9.3.0-6242\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T17:46:24.3204372+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
-1
|
||||
+17
@@ -0,0 +1,17 @@
|
||||
{
|
||||
"experiment": "Versuch 2",
|
||||
"iteration": 2,
|
||||
"model": "qwen/qwen3.8-flash-next",
|
||||
"mode": "custom",
|
||||
"effort": "low",
|
||||
"delegation_depth": "unverschachtelt",
|
||||
"prompt": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_02\\02_Prompt.md",
|
||||
"prompt_sha256": "5946FC82C45E7A242A1F7367B56B008EE0F5C10373223D3500BCEF4716C76ECD",
|
||||
"agents": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_02\\03_Agents.json",
|
||||
"agents_sha256": "424DDD8398D8A6521D9B34AF5B221867C5643572B3821005C7E5E87954644170",
|
||||
"adapter": "C:\\DEV\\MasterArbeit\\.claude\\skills\\run-experiment\\glm-kimi-adapter.py",
|
||||
"adapter_version": "2.1.0",
|
||||
"skill_version": "9.3.0",
|
||||
"repository_commit": "ca52aa4701693528c097f3377edb2c2b07ec5149",
|
||||
"root_commit": "ca52aa4701693528c097f3377edb2c2b07ec5149"
|
||||
}
|
||||
+101
@@ -0,0 +1,101 @@
|
||||
$ErrorActionPreference = 'Stop'
|
||||
|
||||
$repo = 'C:\DEV\MasterArbeit'
|
||||
$root = 'C:\DEV\MasterArbeit\QuellCode\CentronERP'
|
||||
$lauf = 'C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 2\qwen\qwen3.8-flash-next\custom\low\01_Lauf_2026-08-31_165317_v9.3.0-6242'
|
||||
$prompt = 'C:\DEV\MasterArbeit\Versuche\Versuch_02\02_Prompt.md'
|
||||
$agents = 'C:\DEV\MasterArbeit\Versuche\Versuch_02\03_Agents.json'
|
||||
$adapter = 'C:\DEV\MasterArbeit\.claude\skills\run-experiment\glm-kimi-adapter.py'
|
||||
$model = 'qwen/qwen3.8-flash-next'
|
||||
$effort = 'low'
|
||||
$mode = 'custom'
|
||||
|
||||
$toolContext = @'
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen im Arbeitsverzeichnis, schreibgeschützte
|
||||
Kommandozeilenbefehle, das Schreiben von Ergebnisdateien im unten genannten Ausgabeverzeichnis
|
||||
sowie acht beigestellte Agentenrollen.
|
||||
Nicht verfügbar sind: externe Werkzeugserver, Webzugriff, Skills und Slash-Kommandos.
|
||||
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 und legen keine
|
||||
Ergebnisdateien an; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen bleiben
|
||||
deine Aufgabe. Die Bearbeiter delegieren nicht weiter — nur du beauftragst.
|
||||
'@
|
||||
|
||||
$outputContext = @"
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
``$lauf\Ergebnisse\``.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
"@
|
||||
|
||||
$combinedPrompt = (Get-Content -LiteralPath $prompt -Raw) +
|
||||
"`r`n`r`n" + $toolContext +
|
||||
"`r`n`r`n" + $outputContext
|
||||
Set-Content -LiteralPath "$lauf\_meta\combined_prompt.md" -Value $combinedPrompt -Encoding utf8
|
||||
|
||||
$before = git -C $repo status --porcelain -- 'QuellCode/CentronERP' | Out-String
|
||||
Set-Content -LiteralPath "$lauf\_meta\before.txt" -Value $before -Encoding utf8
|
||||
|
||||
$config = [ordered]@{
|
||||
experiment = 'Versuch 2'
|
||||
iteration = 2
|
||||
model = $model
|
||||
mode = $mode
|
||||
effort = $effort
|
||||
delegation_depth = 'unverschachtelt'
|
||||
prompt = $prompt
|
||||
prompt_sha256 = (Get-FileHash -LiteralPath $prompt -Algorithm SHA256).Hash
|
||||
agents = $agents
|
||||
agents_sha256 = (Get-FileHash -LiteralPath $agents -Algorithm SHA256).Hash
|
||||
adapter = $adapter
|
||||
adapter_version = '2.1.0'
|
||||
skill_version = '9.3.0'
|
||||
repository_commit = (git -C $repo rev-parse HEAD)
|
||||
root_commit = (git -C $root rev-parse HEAD)
|
||||
}
|
||||
$config | ConvertTo-Json | Set-Content -LiteralPath "$lauf\_meta\konfiguration.json" -Encoding utf8
|
||||
|
||||
Set-Content -LiteralPath "$lauf\_meta\startzeit.txt" -Value (Get-Date -Format o) -Encoding utf8
|
||||
Set-Location -LiteralPath $root
|
||||
|
||||
& python $adapter `
|
||||
--prompt "$lauf\_meta\combined_prompt.md" `
|
||||
--root $root `
|
||||
--output "$lauf\Ergebnisse" `
|
||||
--model $model `
|
||||
--effort $effort `
|
||||
--mode $mode `
|
||||
--agents $agents `
|
||||
--max-turns 0 `
|
||||
--subagent-max-turns 0 `
|
||||
--timeout 0 `
|
||||
--heartbeat-interval 60 `
|
||||
--result-dir $lauf `
|
||||
2> "$lauf\Stderr.log"
|
||||
$adapterExitCode = $LASTEXITCODE
|
||||
|
||||
Set-Content -LiteralPath "$lauf\_meta\endzeit.txt" -Value (Get-Date -Format o) -Encoding utf8
|
||||
Set-Content -LiteralPath "$lauf\_meta\exitcode.txt" -Value $adapterExitCode -Encoding utf8
|
||||
$after = git -C $repo status --porcelain -- 'QuellCode/CentronERP' | Out-String
|
||||
Set-Content -LiteralPath "$lauf\_meta\after.txt" -Value $after -Encoding utf8
|
||||
exit $adapterExitCode
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T16:56:43.8217597+02:00
|
||||
Reference in New Issue
Block a user