Lokale Matrix liefert Ergebnisse: 119 Anforderungen aus Gemma und Qwen
Skill 13.0.0/13.1.0, Adapter 2.5.2. Spiegel-Arbeitsverzeichnis: OpenCode laeuft nicht mehr direkt im Codebasis-Root, sondern in einem Verzeichnis aus Junctions auf die Top-Level-Eintraege, mit einem echten Ergebnisverzeichnis, dessen Inhalt nach dem Lauf uebernommen wird. Damit landen relative wie absolute Ausgabepfade am richtigen Ort, ohne dass der Prompt vom Wortlaut der Claude-Laeufe abweichen muss. Der Spiegel liegt in _meta des Laufs; die Codebasis bleibt unberuehrt. Der Spiegel allein genuegte nicht. Sechs Laeufe schrieben mit korrektem absolutem Pfad und wurden dennoch abgewiesen, weil OpenCode Ziele im Repository gegen den worktree-relativen Pfad abgleicht - ein Befund, der seit Skill 10.0.2 dokumentiert war und erst sichtbar wurde, als der Spiegel vom Temp-Verzeichnis ins Projekt wanderte. analyse-anforderungen.py erkennt Kennungen als Markdown-Ueberschrift, auch ohne Feldnamen, sofern die Pflichtfelder folgen. Regressionsprobe an fuenf Claude-Laeufen unveraendert. Ergebnisse der gueltigen Laeufe: Qwen 3.5-9B liefert 107 der 119 Anforderungen, davon 75 im Modus custom mit nur drei Subagenten. Gemma kommt auf 12. Der Modus builtin fiel bei beiden Modellen aus - drei von drei Laeufen endeten nach einem Turn ohne einen Werkzeugaufruf. Die 13 Laeufe mit Adapter 2.3.0 bis 2.5.1 sind Artefakte der Fehlersuche und als adapterbedingte Fehlmessungen gekennzeichnet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Christoph Schwörer
co-authored by
Claude Opus 5
Claude Opus 5
parent
28e927013b
commit
6c5c26a2e4
+7
@@ -0,0 +1,7 @@
|
||||
[2026-09-01T19:29:05.668394+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\builtin\high\03_Lauf_2026-09-01_212903_v13.0.0-8418\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\builtin\high\03_Lauf_2026-09-01_212903_v13.0.0-8418\Ergebnisse)
|
||||
[2026-09-01T19:29:08.968111+00:00] LM-Studio-Preflight bestanden: qwen/qwen3.5-9b; Quantisierung=Q8_0; Kontext=131072/262144; Runtime=gguf
|
||||
[2026-09-01T19:29:09.211166+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'qwen/qwen3.5-9b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-09-01T19:29:09.212221+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/qwen/qwen3.5-9b; Modus=builtin; Effort=high (uebergeben=False); Stall-Timeout=0s
|
||||
[2026-09-01T19:29:43.501805+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-01T19:29:47.566910+00:00] OpenCode export: Exporting session: ses_fa18d8f91ffe1E8BOURMTnCzd9
|
||||
[2026-09-01T19:29:47.592969+00:00] Ende: Exitcode=0; Status=error; Turns=1; Tokens=10573; Dateien=0; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\builtin\high\03_Lauf_2026-09-01_212903_v13.0.0-8418\RawResult.json
|
||||
+3
@@ -0,0 +1,3 @@
|
||||
{"type":"step_start","timestamp":1788290977687,"sessionID":"ses_fa18d8f91ffe1E8BOURMTnCzd9","part":{"id":"prt_05e72cf86001q0kFkBU8CYwZ6d","messageID":"msg_05e72759d0010Igf3vNyv3rd4T","sessionID":"ses_fa18d8f91ffe1E8BOURMTnCzd9","snapshot":"d3e28a96be089f091c4ae1f9a4622d79a237cf07","type":"step-start"}}
|
||||
{"type":"text","timestamp":1788290980336,"sessionID":"ses_fa18d8f91ffe1E8BOURMTnCzd9","part":{"id":"prt_05e72d3f6001Yqr7wrAqY7DkAj","messageID":"msg_05e72759d0010Igf3vNyv3rd4T","sessionID":"ses_fa18d8f91ffe1E8BOURMTnCzd9","type":"text","text":"Ich erstelle das Modulinventar für den Analysebericht - dazu lese ich zunächst die gesamte Codebasis im Arbeitsverzeichnis um, welche Module, Dateien und Komponenten vorhanden sind.","time":{"start":1788290978806,"end":1788290980312}}}
|
||||
{"type":"step_finish","timestamp":1788290981391,"sessionID":"ses_fa18d8f91ffe1E8BOURMTnCzd9","part":{"id":"prt_05e72ddee001xvo6pkwQOdS7mK","reason":"stop","snapshot":"d3e28a96be089f091c4ae1f9a4622d79a237cf07","messageID":"msg_05e72759d0010Igf3vNyv3rd4T","sessionID":"ses_fa18d8f91ffe1E8BOURMTnCzd9","type":"step-finish","tokens":{"total":10573,"input":10508,"output":38,"reasoning":27,"cache":{"write":0,"read":0}},"cost":0}}
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
# Messprotokoll – Iteration 15/qwen/qwen3.5-9b/builtin/high
|
||||
|
||||
> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
|
||||
> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `03_Prompt.md`
|
||||
- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
|
||||
- **Startzeit:** 2026-09-01T21:29:03.6129803+02:00
|
||||
- **Endzeit:** 2026-09-01T21:29:47.6208404+02:00
|
||||
- **Dauer gesamt:** 00:00:34 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
|
||||
- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
|
||||
- **Codebasis-Commit:** `28e927013b4088f648e1cc9def7c19742e2b9330` (vor dem Lauf dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Skill-Version:** 13.0.0
|
||||
- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider lmstudio` (Adapter-Version 2.5.2)
|
||||
- **CLI-Version:** OpenCode 1.18.25
|
||||
- **Modell (angefordert):** `qwen/qwen3.5-9b`
|
||||
- **Modell (tatsaechlich):** `qwen/qwen3.5-9b`
|
||||
- **Kontrolle Modell:** bestanden
|
||||
- **Effort:** `high` angefordert, **nicht wirksam** (`effort_applied: false`)
|
||||
- **Ablage:** `Iteration 15/qwen/qwen3.5-9b/builtin/high/`
|
||||
- **Agentenmodus:** `builtin`
|
||||
- **Kontextfenster:** 131.072 Tokens geladen (Modellmaximum 262.144)
|
||||
- **Sampling-Parameter:** nicht steuerbar
|
||||
- **Lokaler Modellbetrieb:** Runtime `gguf`, `lms` CLI commit: 71bd99c, Architektur `qwen35`, **Quantisierung `Q8_0`**, 4 Slots, GPU-Offload `max`, alleiniges Modell: true
|
||||
- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
|
||||
- **Subagenten:** `spawned` = 0, `completed` = 0, `failed` = 0
|
||||
- **Rollen:** {}
|
||||
|
||||
## Validierungsstichprobe
|
||||
- **Stand:** entfaellt
|
||||
|
||||
## Verbrauch
|
||||
|
||||
| Messgroesse | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 10.508 |
|
||||
| Output-Tokens | 38 |
|
||||
| Reasoning-Tokens | 27 |
|
||||
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Agent-Turns | 1 |
|
||||
|
||||
**Tokens gesamt: 10.573.** Kosten `0` – lokaler Betrieb (nicht erfasst (lokaler Betrieb)).
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Keine Anforderungen im vorgegebenen Format gefunden.
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** `is_error: true`, `subtype: error`, `exit_code: 0`, `timed_out: false`
|
||||
- **Session-ID:** `ses_fa18d8f91ffe1E8BOURMTnCzd9`
|
||||
- **Werkzeugaufrufe:** 0 – {}
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0
|
||||
- **Gueltigkeit:** *(pruefen)* **Fehlmessung** – Ergebnisverzeichnis leer.
|
||||
- **Erzeugte Dateien:** keine
|
||||
- **Root unveraendert:** ja
|
||||
- **Fehlermeldungen:** ["Ergebnisse-Verzeichnis ist leer"]
|
||||
|
||||
## Anmerkungen/Auffaelligkeiten
|
||||
|
||||
*(von Hand zu ergaenzen)*
|
||||
+93
@@ -0,0 +1,93 @@
|
||||
{
|
||||
"is_error": true,
|
||||
"subtype": "error",
|
||||
"duration_ms": 34288,
|
||||
"duration_api_ms": 0,
|
||||
"num_turns": 1,
|
||||
"model": "qwen/qwen3.5-9b",
|
||||
"model_requested": "qwen/qwen3.5-9b",
|
||||
"provider": "lmstudio",
|
||||
"effort": "high",
|
||||
"effort_applied": false,
|
||||
"usage": {
|
||||
"prompt_tokens": 10508,
|
||||
"completion_tokens": 38,
|
||||
"total_tokens": 10573,
|
||||
"cached_tokens": 0,
|
||||
"cache_read_tokens": 0,
|
||||
"cache_creation_tokens": 0,
|
||||
"reasoning_tokens": 27,
|
||||
"output_tokens_details": {
|
||||
"thinking_tokens": 27
|
||||
}
|
||||
},
|
||||
"modelUsage": {
|
||||
"qwen/qwen3.5-9b": {
|
||||
"input_tokens": 10508,
|
||||
"output_tokens": 38,
|
||||
"cache_read_input_tokens": 0,
|
||||
"cache_creation_input_tokens": 0,
|
||||
"reasoning_tokens": 27
|
||||
}
|
||||
},
|
||||
"cost": 0,
|
||||
"tool_calls": [],
|
||||
"tool_call_count": 0,
|
||||
"tool_call_types": {},
|
||||
"event_counts": {
|
||||
"step_start": 1,
|
||||
"text": 1,
|
||||
"step_finish": 1
|
||||
},
|
||||
"written_files": [],
|
||||
"result": "Ich erstelle das Modulinventar für den Analysebericht - dazu lese ich zunächst die gesamte Codebasis im Arbeitsverzeichnis um, welche Module, Dateien und Komponenten vorhanden sind.",
|
||||
"finish_reason": "stop",
|
||||
"errors": [
|
||||
"Ergebnisse-Verzeichnis ist leer"
|
||||
],
|
||||
"session_id": "ses_fa18d8f91ffe1E8BOURMTnCzd9",
|
||||
"adapter": "opencode-lmstudio",
|
||||
"adapter_version": "2.5.2",
|
||||
"opencode_version": "1.18.25",
|
||||
"mode": "builtin",
|
||||
"subagent_stats": {
|
||||
"spawned": 0,
|
||||
"completed": 0,
|
||||
"failed": 0,
|
||||
"by_type": {}
|
||||
},
|
||||
"subagent_details": [],
|
||||
"timed_out": false,
|
||||
"interrupted": false,
|
||||
"exit_code": 0,
|
||||
"usage_captured": true,
|
||||
"local_runtime": {
|
||||
"provider": "lmstudio",
|
||||
"base_url": "http://localhost:1234",
|
||||
"lms_path": "C:\\Users\\ChristophSchwoerer\\.lmstudio\\bin\\lms.exe",
|
||||
"lms_version": "CLI commit: 71bd99c",
|
||||
"model_id": "qwen/qwen3.5-9b",
|
||||
"instance_id": "qwen/qwen3.5-9b",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"quantization": "Q8_0",
|
||||
"compatibility_type": "gguf",
|
||||
"state": "loaded",
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
],
|
||||
"max_context_length": 262144,
|
||||
"loaded_context_length": 131072,
|
||||
"parallel_slots": 4,
|
||||
"gpu_offload": "max",
|
||||
"alleiniges_modell": true
|
||||
},
|
||||
"context_window": 131072,
|
||||
"cost_source": "nicht erfasst (lokaler Betrieb)",
|
||||
"arbeitsverzeichnis": "spiegel",
|
||||
"arbeitswurzel": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 15\\qwen\\qwen3.5-9b\\builtin\\high\\03_Lauf_2026-09-01_212903_v13.0.0-8418\\_meta\\spiegel",
|
||||
"start_time": "2026-09-01T19:29:09.212189+00:00",
|
||||
"end_time": "2026-09-01T19:29:47.572524+00:00",
|
||||
"opencode_path": "C:\\Users\\ChristophSchwoerer\\AppData\\Roaming\\npm\\node_modules\\opencode-ai\\bin\\opencode.exe",
|
||||
"config_path": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 15\\qwen\\qwen3.5-9b\\builtin\\high\\03_Lauf_2026-09-01_212903_v13.0.0-8418\\_meta\\opencode-config.json"
|
||||
}
|
||||
+7
@@ -0,0 +1,7 @@
|
||||
[2026-09-01T19:29:05.668394+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\builtin\high\03_Lauf_2026-09-01_212903_v13.0.0-8418\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\builtin\high\03_Lauf_2026-09-01_212903_v13.0.0-8418\Ergebnisse)
|
||||
[2026-09-01T19:29:08.968111+00:00] LM-Studio-Preflight bestanden: qwen/qwen3.5-9b; Quantisierung=Q8_0; Kontext=131072/262144; Runtime=gguf
|
||||
[2026-09-01T19:29:09.211166+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'qwen/qwen3.5-9b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-09-01T19:29:09.212221+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/qwen/qwen3.5-9b; Modus=builtin; Effort=high (uebergeben=False); Stall-Timeout=0s
|
||||
[2026-09-01T19:29:43.501805+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-01T19:29:47.566910+00:00] OpenCode export: Exporting session: ses_fa18d8f91ffe1E8BOURMTnCzd9
|
||||
[2026-09-01T19:29:47.592969+00:00] Ende: Exitcode=0; Status=error; Turns=1; Tokens=10573; Dateien=0; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\builtin\high\03_Lauf_2026-09-01_212903_v13.0.0-8418\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
[]
|
||||
+4
@@ -0,0 +1,4 @@
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Keine Anforderungen im vorgegebenen Format gefunden.
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+175
@@ -0,0 +1,175 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
### 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?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen, das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis sowie
|
||||
die werkzeugeigenen Subagenten.
|
||||
Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
|
||||
Werkzeugserver, Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\builtin\high\03_Lauf_2026-09-01_212903_v13.0.0-8418\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-09-01T21:29:47.6208404+02:00
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
[
|
||||
{
|
||||
"id": "qwen/qwen3.5-9b",
|
||||
"object": "model",
|
||||
"type": "llm",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q8_0",
|
||||
"state": "loaded",
|
||||
"max_context_length": 262144,
|
||||
"loaded_context_length": 131072,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "qwen/qwen3.8-27b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 262144,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "google/gemma-4-e4b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 131072,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "text-embedding-nomic-embed-text-v1.5",
|
||||
"object": "model",
|
||||
"type": "embeddings",
|
||||
"publisher": "nomic-ai",
|
||||
"arch": "nomic-bert",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 2048
|
||||
}
|
||||
]
|
||||
+129
@@ -0,0 +1,129 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"lmstudio": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "LM Studio (lokal)",
|
||||
"options": {
|
||||
"baseURL": "http://localhost:1234/v1",
|
||||
"apiKey": "lm-studio"
|
||||
},
|
||||
"models": {
|
||||
"google/gemma-4-e4b": {
|
||||
"name": "Gemma 4 E4B (lokal)",
|
||||
"limit": {
|
||||
"context": 131072,
|
||||
"output": 32768
|
||||
}
|
||||
},
|
||||
"qwen/qwen3.5-9b": {
|
||||
"name": "Qwen 3.5 9B (lokal)",
|
||||
"limit": {
|
||||
"context": 131072,
|
||||
"output": 32768
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "lmstudio/qwen/qwen3.5-9b",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/builtin/high/03_Lauf_2026-09-01_212903_v13.0.0-8418/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
},
|
||||
"task": {
|
||||
"*": "deny",
|
||||
"general": "allow",
|
||||
"explore": "allow"
|
||||
},
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "lmstudio/qwen/qwen3.5-9b",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "lmstudio/qwen/qwen3.5-9b",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "lmstudio/qwen/qwen3.5-9b",
|
||||
"mode": "subagent"
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+164
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
2026-09-01T21:29:03.6129803+02:00
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
[2026-09-01T19:01:15.103803+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\solo\high\03_Lauf_2026-09-01_210112_v13.0.0-0b06\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\solo\high\03_Lauf_2026-09-01_210112_v13.0.0-0b06\Ergebnisse)
|
||||
[2026-09-01T19:01:17.226936+00:00] LM Studio: C:\Users\ChristophSchwoerer\.lmstudio\bin\lms.exe unload --all
|
||||
[2026-09-01T19:01:21.691824+00:00] LM Studio: C:\Users\ChristophSchwoerer\.lmstudio\bin\lms.exe load qwen/qwen3.5-9b --context-length 131072 --parallel 4 --gpu max --yes
|
||||
[2026-09-01T19:01:54.816198+00:00] LM-Studio-Preflight bestanden: qwen/qwen3.5-9b; Quantisierung=Q8_0; Kontext=131072/262144; Runtime=gguf
|
||||
[2026-09-01T19:01:55.048673+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'qwen/qwen3.5-9b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-09-01T19:01:55.049759+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/qwen/qwen3.5-9b; Modus=solo; Effort=high (uebergeben=False); Stall-Timeout=0s
|
||||
[2026-09-01T19:29:01.254706+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-01T19:29:02.968211+00:00] OpenCode export: Exporting session: ses_fa1a68033ffelEYy37VWtxZWBX
|
||||
[2026-09-01T19:29:02.994264+00:00] Ende: Exitcode=0; Status=success; Turns=35; Tokens=1398994; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\solo\high\03_Lauf_2026-09-01_210112_v13.0.0-0b06\RawResult.json
|
||||
+92
@@ -0,0 +1,92 @@
|
||||
# Analysebericht - c-entron ERP Legacy System
|
||||
|
||||
## Modulinventar (Schritt 0)
|
||||
|
||||
| Fachliches Modul / Komponente | Pfad im Arbeitsverzeichnis | Beschreibung |
|
||||
|-------------------------------|----------------------------|--------------|
|
||||
| Datenbank Schema | `_meta/spiegel/SSMS_DB_SCHEMA.sql` | SQL Server Database mit Views, Functions, Tabellen für ERP-Logik |
|
||||
| Rechtekonzept | `_meta/spiegel/CentronRights.md` | Benutzerrights-Konzept für Helpdesk und Kalender |
|
||||
| Build-Konfiguration | `_meta/spiegel/Directory.Build.props` | MSBuild-Eigenschaften für c-entron ERP |
|
||||
| NuGet Konfiguration | `_meta/spiegel/nuget.config` | Paketquellen-Konfiguration |
|
||||
| DevExpress Version | `_meta/spiegel/DevExpress.Version.props` | UI-Framework Versionierung |
|
||||
| Projektdatei | `_meta/spiegel/Centron.sln` | .NET Solution Datei |
|
||||
| Web-Cart Dokumentation | `_meta/spiegel/README.md` | Shop/WebCart Featurebeschreibung |
|
||||
|
||||
## Abdeckungstabelle
|
||||
|
||||
| Modul | Einstufung | Anzahl Anforderungen | Begründung |
|
||||
|-------|------------|---------------------|-----------|
|
||||
| Datenbank Schema (Schema) | tief | 0 | Vollständig analysiert, aber keine funktionellen Artefakte im Verzeichnis vorfindlich. SQL-Schema enthält viele Views/Functions ohne zugehörigen C#-Code. |
|
||||
| Rechtekonzept (Rights) | tief | 40+ | CentronRights.md enthält detaillierte Rechtsdefinitionen |
|
||||
| Build-Konfiguration (.props) | flach | 1 | Basis-Properties analysiert |
|
||||
| NuGet Konfiguration (.config) | flach | 1 | Paketquellen dokumentiert |
|
||||
| DevExpress Framework | flach | 0 | Nur Version referenziert, kein UI-Code verfügbar |
|
||||
| WebCart/Shop | flach | 1 | README.md mit Featurebeschreibung |
|
||||
| **Nicht analysiert** | **nicht analysiert** | **0** | **>27.5% (8 von 29 Einträgen)** - Quellcode (.cs, .xaml) nicht im Verzeichnis vorhanden |
|
||||
|
||||
## Konsistenzcheck
|
||||
|
||||
- Keine doppelten IDs
|
||||
- Alle Anforderungen enthalten Belege
|
||||
- Alle Anforderungen haben Übernahmewürdigkeit
|
||||
- Tracelinks existieren (internes Dokument)
|
||||
|
||||
## Selbstbewertung
|
||||
|
||||
### Analyse-Tiefe pro Modul
|
||||
|
||||
| Kategorie | Anzahl Module | Prozent |
|
||||
|-----------|---------------|--------|
|
||||
| Tief analysiert | 2 | 6.9% |
|
||||
| Mittel analysiert | 0 | 0% |
|
||||
| Flach analysiert | 4 | 13.8% |
|
||||
| Nicht analysiert | 8 | 27.6% |
|
||||
|
||||
### Kritische Lücken
|
||||
|
||||
**Hauptproblem: Fehlender Quellcode**
|
||||
- Keine `.cs` Dateien (.NET C# Source Code) im Verzeichnis
|
||||
- Keine `.xaml` Dateien (UI-Definitionen) im Verzeichnis
|
||||
- Keine Assembly-DLLs oder Binaries verfügbar
|
||||
|
||||
**Folgen:**
|
||||
- FUNKTIONALE Anforderungen können nur aus SQL-Views und Functions abgeleitet werden - ohne Implementierungsdetails unvollständig
|
||||
- SICHERHEITSANFORDERUNGEN (Rechtekonzept) sind teilweise belegbar, aber Durchsetzungslogik im Code fehlt
|
||||
- NACHFUFGESCHRIFTEN (Validierungen, Fehlerbehandlung) nicht erfassbar
|
||||
|
||||
### Hypothesen-Situation
|
||||
|
||||
**Keine formellen [HYPOTHESE]-Markierungen notwendig**, da:
|
||||
- Alle verfügbaren Artefakte direkt analysiert wurden
|
||||
- Das Fehlen des Quellcodes macht keine Hypothese überprüfbar
|
||||
- Offene Punkte werden in der Selbstbewertung transparent gemacht, nicht als Hypothesen geführt
|
||||
|
||||
### Erkenntnisse für Folge-Iterationen
|
||||
|
||||
1. **Quellcode-Repositorium anfordern**: Die vollständige Codebasis (.cs, .xaml, .config) ist erforderlich, um:
|
||||
- Validierungslogik zu erfassen
|
||||
- Berechtigungsprüfungen nachzuweisen
|
||||
- Fehlerbehandlungen und Edge Cases zu identifizieren
|
||||
|
||||
2. **SQL-Views als Artefakte nutzen**: Die existierenden Views (`cvw_` Prefix) enthalten Business-Logik, die in einer Folge-Iteration vertieft analysiert werden soll
|
||||
|
||||
3. **Rechtekonzept erweitern**: CentronRights.md ist unvollständig - weitere Module (Vertragsmanagement, Lagerwirtschaft, etc.) fehlen
|
||||
|
||||
---
|
||||
|
||||
## Risikorelevante Anforderungen
|
||||
|
||||
| ID | Titel | PRIMÄR-Beleg | Status |
|
||||
|----|-------|--------------|--------|
|
||||
| StRS-001 | Benutzerrights müssen definiert und zugeordnet werden können | CentronRights.md (alle Rights) | HYPOTHESE - Durchsetzungslogik nicht im Quellcode vorhanden |
|
||||
| SyRS-001 | Zugriffskontrolle muss Rechte aus CentronRights.md durchsetzen | CentronRights.md + SQL Schema (kein Prüfcod) | HYPOTHESE |
|
||||
|
||||
**Kritischer Befund:** Alle risikorelevanten Anforderungen sind als HYPOTHESE markiert, da:
|
||||
- Rechte in CentronRights.md deklariert werden
|
||||
- Die **Durchsetzungslogik** (wo im Code geprüft wird) fehlt
|
||||
- Ohne Quellcode kann keine `PRIMÄR`-Belegstelle benannt werden
|
||||
|
||||
---
|
||||
|
||||
*Analysezeitpunkt: 2026-09-01*
|
||||
*Codebasis-Arbeitsverzeichnis: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\solo\high\03_Lauf_2026-09-01_210112_v13.0.0-0b06\_meta\spiegel*
|
||||
+211
@@ -0,0 +1,211 @@
|
||||
# Glossar - c-entron ERP Requirements
|
||||
|
||||
## ISO/IEC/IEEE 29148:2018 - Domänenbegriffe und Fachterminologie
|
||||
|
||||
---
|
||||
|
||||
### A
|
||||
|
||||
**Artikel**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Artikel | Produkt-/Dienstleistungseinheit im ERP-System mit VK_1 bis VK_4 Preisdefinitionen (Line 649 in SQL Schema), Einheit und Lagerzuordnung |
|
||||
|
||||
**Asset**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Asset | IT-Hardware-Ressource (AssetManagementDevices) mit Kunden-Zuordnung, SNMP-Monitoring-Checks und CheckConfigurations |
|
||||
|
||||
---
|
||||
|
||||
### B
|
||||
|
||||
**Branch / Filiale**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Branch | Zweigniederlassung im ERP-System; branch-restricting Rights limitieren Sichtbarkeit/Bearbeitbarkeit nach Benutzer-Zugehörigkeit (CentronRights.md:150-153) |
|
||||
|
||||
---
|
||||
|
||||
### C
|
||||
|
||||
**Claim**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Claim | Authorization-Token mit UserRight-Wert (z.B. `Sales.Customer.Helpdesk.SHOW_HELPDESK`); wird nach Authentifizierung an Benutzer zugewiesen (SwRS-010) |
|
||||
|
||||
**C-FLOW**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| C-FLOW | Helpdesk-Tickettemplate-System mit Kategorienstruktur; Rights: CREATE, EDIT, DELETE für Templates und Categories (CentronRights.md:110-126) |
|
||||
|
||||
**Contingent / Zeitkontingent**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Contingent | Zeit- oder Wertkontingent für Verträge; besteht aus Perioden mit dtFrom/dtTo, BookValue, RestValue, UseValue, ReservedValue; wird durch ContractItems und hlpdsk_timer verbraucht (SQL Schema: cfn_ContingentState) |
|
||||
|
||||
**ContractItem / Vertragseintrag**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| ContractItem | Eintrag im Vertrag mit Contingent-Buchung; berechnet UsedValue basierend auf BalanceQuantity, AssetKind, Preisfaktor (SQL Schema: ContractItemsContingent) |
|
||||
|
||||
---
|
||||
|
||||
### D
|
||||
|
||||
**Department / Abteilung**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Department | Organisationseinheit im ERP-System; ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS Right limitiert Ticket-Zuweisung auf eigene Abteilungen (CentronRights.md:33-35) |
|
||||
|
||||
---
|
||||
|
||||
### E
|
||||
|
||||
**Entity Framework**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Entity Framework | Object-Relational-Mapper (ORM) für C#-Datenzugriff auf SQL Server; verwaltet Entity-Klassen wie Ticket, ContractItem, TimeRecord (SwRS-001 bis SwRS-013) |
|
||||
|
||||
---
|
||||
|
||||
### H
|
||||
|
||||
**Helpdesk / Support-Ticket**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Helpdesk | Support-Ticket-Funktionalität mit Statusmaschine, TimeRecords, Bearbeiter-Zuweisung und Verknüpfung zu Aufträgen/Lieferungen/Rechnungen (SQL Schema: hlpdsk_requests, hlpdsk_timer) |
|
||||
|
||||
**hlpdsk_request_bearbeiter**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| RequestBearbeiter | Tabelle für Ticket-Bearbeiter-Zuordnung; mehrere Bearbeiter möglich mit PersonalI3D-Verknüpfung (SQL Schema: Line 1073+) |
|
||||
|
||||
---
|
||||
|
||||
### I
|
||||
|
||||
**Identity Provider / Identity Service**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Identity Provider | System zur Authentifizierung von Benutzern; Claims/Rights nach Login basierend auf UserRightsConst (SwRS-001, SwRS-010) |
|
||||
|
||||
---
|
||||
|
||||
### K
|
||||
|
||||
**Kalender**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Kalender | Zeitplanungsfunktionalität mit branch-restricting Rights; UserRightsConst.RIGHT_KALENDERANZEIGENEIGENE limitiert auf eigene Einträge (CentronRights.md:132-154) |
|
||||
|
||||
**Checklist**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Checklist | Checklisten-Funktionalität mit Templates und Items; Rights: CREATE, EDIT für Templates und Items (CentronRights.md:92-108) |
|
||||
|
||||
---
|
||||
|
||||
### M
|
||||
|
||||
**Mitarbeiterauslastung**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Mitarbeiterauslastung | Aggregation von TimeRecords pro Mitarbeiter in Stunden/Wochen; branch-restricting Right für eigene Filiale (CentronRights.md:144-154) |
|
||||
|
||||
---
|
||||
|
||||
### P
|
||||
|
||||
**Policy / Authorization Policy**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Policy | Autorisierungspolicy definiert durch Claims und UserRightsConst-Werte; enforced in Controllers oder Middleware für Access Control (SyRS-001, SwRS-010) |
|
||||
|
||||
---
|
||||
|
||||
### R
|
||||
|
||||
**Restricting Right / Einschränzendes Recht**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Restricting Right | Spezialart von UserRight mit branch/departments-based Einschränkung; sichtbar nur in eigenen Filialen/Abteilungen (CentronRights.md:10, 15, 24, 33) |
|
||||
|
||||
**Receipt / Transaktionstabelle**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Receipt | ERP-Transaktionsarten: Auftragskopf (AufKopf), Lieferschein (LiefKopf), Abholliste (AbholKopf), Rechnung (RechKopf), Gutschrift (GutKopf) (SQL Schema) |
|
||||
|
||||
---
|
||||
|
||||
### S
|
||||
|
||||
**SNMP-Monitoring / Simple Network Management Protocol**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| SNMP-Monitoring | Netzwerkmonitoring für IT-Assets via AssetManagementDevices; SNMP-Mib-Checks mit ProviderName-Zählung pro Kunde (SQL Schema: cfn_GetSnmpCountByCustomer) |
|
||||
|
||||
**Shop / WebCart**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Shop/WebCart | E-Commerce-Funktionalität im Nexus Webportal für WebAccounts mit Sonderpreis-Artikelansicht (README.md:31-36) |
|
||||
|
||||
**Stückliste / Partlist**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Stückliste | Hierarchische Positionsstruktur für Konfigurationsartikel; ValueKind=1 in cfn_CalculateReceiptSpecialPosition (SQL Schema: Line 354-379) |
|
||||
|
||||
---
|
||||
|
||||
### T
|
||||
|
||||
**Template / Vorlage**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| Template | C-FLOW Tickettemplate mit Kategorienstruktur; Rights für CREATE, EDIT, DELETE existieren (CentronRights.md:120-126) |
|
||||
|
||||
**TimeRecord / Zeitprotokoll**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| TimeRecord | Zeiterfassungseintrag im Helpdesk mit Timer-Dauer, LunchTime und Berechenbar-Flag; verknüpft mit Ticket und Artikel (SQL Schema: hlpdsk_timer) |
|
||||
|
||||
**UserRightsConst / Benutzerrightskonstanten**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| UserRightsConst | C#-Konstantenraum für Rechte-Definitionen im ERP; Syntax: `Sales.Customer.Helpdesk.SHOW_HELPDESK` (159 Rights in CentronRights.md) |
|
||||
|
||||
---
|
||||
|
||||
### V
|
||||
|
||||
**View / Sicht**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| View | SQL View mit Business-Logik für Abfragen; Präfix "cvw_" für Common Views, z.B. cvw_ArticleCount, cvw_OfferPos (SQL Schema) |
|
||||
|
||||
---
|
||||
|
||||
### W
|
||||
|
||||
**WebAccount**
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| WebAccount | Benutzerrolle für den WebShop (c-entron Nexus); erstellt in c-entron.NET Adressstamm; Zugriff auf Sonderpreis-Artikel im Shop (README.md:35) |
|
||||
|
||||
---
|
||||
|
||||
## Referenznummern und SQL-Tabellen
|
||||
|
||||
| Kürzel | Bedeutung | Tabelle/View |
|
||||
|--------|-----------|--------------|
|
||||
| I3D | Internal ID (primäres Schlüsselfeld) | Alle Tabellen |
|
||||
| AufKopf | Auftragkopf | dbo.AufKopf |
|
||||
| AufPos | Auftragsposition | dbo.AufPos |
|
||||
| hlpdsk_request_bearbeiter | Ticket-Bearbeiter-Zuordnung | dbo.hlpdsk_request_bearbeiter |
|
||||
| hlpdsk_timer | Zeitprotokoll-Tabelle | dbo.hlpdsk_timer |
|
||||
| ContractItemsContingent | Vertragseintrag-Contingent-Buchung | dbo.ContractItemsContingent |
|
||||
| ContractContingentBooked | Contingent-Buchungen für Verträge | dbo.ContractContingentBooked |
|
||||
|
||||
---
|
||||
|
||||
*Generiert: 2026-09-01 | Quellen: SSMS_DB_SCHEMA.sql, CentronRights.md, README.md, Directory.Build.props*
|
||||
+159
@@ -0,0 +1,159 @@
|
||||
# Hypothesensammlung - c-entron ERP Requirements
|
||||
|
||||
## ISO/IEC/IEEE 29148:2018 - Offene Fragen zur Anforderungserfüllung
|
||||
|
||||
---
|
||||
|
||||
### Überblick
|
||||
|
||||
| ID | Titel | Status | Open Question | Quelle der Hypothese |
|
||||
|----|-------|--------|---------------|---------------------|
|
||||
| StRS-001 | Benutzerrights definieren und zuordnen | HYPOTHESE | Wo findet die Durchsetzungslogik statt? | CentronRights.md + SQL Schema (kein C# Code) |
|
||||
| SyRS-001 | Zugriffskontrolle durchsetzen | HYPOTHESE | Wie werden Rights in Claims/Roles mapped? | UserRightsConst-Konstanten unbekannt |
|
||||
| SwRS-001 | Benutzerauthentifizierung mit Rights-Erweiterung | HYPOTHESE | Welches Auth-Framework wird verwendet? | CentronRights.md + Directory.Build.props |
|
||||
| SwRS-010 | Rights-Mapping von UserRightsConst zu Claims | HYPOTHESE | Policy-Enforcement Point (MVC Filter/Middleware) nicht bekannt | CentronRights.md: UserRightsConst-Syntax |
|
||||
|
||||
**Gesamt:** 4 Hypothesen, alle mit identischem Grund: **Fehlender C#/XAML-Quellcode im Arbeitsverzeichnis**
|
||||
|
||||
---
|
||||
|
||||
### Detailierte Hypothesen
|
||||
|
||||
---
|
||||
|
||||
#### StRS-001: Benutzerrights definieren und zuordnen
|
||||
|
||||
**Offene Frage:** Wo findet die Durchsetzungslogik statt? Welches Framework (IdentityServer, OWIN, .NET Core Identity)? Wie wird Policy Enforcement realisiert (MVC Filter, Middleware, Repository Pattern)?
|
||||
|
||||
**Begründung:**
|
||||
- CentronRights.md definiert 159 Rights mit `*UserRightsConst.Sales.Customer.Helpdesk.SHOW_HELPDESK`-Syntax
|
||||
- SQL Schema enthält keine expliziten Access-Control-Code-Stellen (nur Views/Functions)
|
||||
- Directory.Build.props identifiziert System als "NEXOWARE c-entron ERP" aber gibt keine Framework-Hinweise
|
||||
- Ohne .cs-Dateien kann nicht nachgewiesen werden, wie Rights in der Anwendung durchgesetzt werden
|
||||
|
||||
**Verifizierung erforderlich:**
|
||||
1. C#-Source für Authorization Layer (Controller/Middleware/Policy)
|
||||
2. UserRightsConst-Klassenstruktur im Code
|
||||
3. Claims-Mapping-Logik (wie wird aus CentronRights.md Wert zu Claim?)
|
||||
|
||||
---
|
||||
|
||||
#### SyRS-001: Zugriffskontrolle durchsetzen
|
||||
|
||||
**Offene Frage:** Wie werden UserRightsConst-Werte in Claims/Roles übersetzt? Welches Authorization-Framework (ClaimsPrincipal, Policy-based Authorization, RBAC)?
|
||||
|
||||
**Begründung:**
|
||||
- CentronRights.md listet Rights mit `UserRightsConst`-Syntax
|
||||
- SQL Schema hat keine Prüfmethode sichtbar
|
||||
- Directory.Build.props: "A protected assembly of NEXOWARE Systems GmbH" → Security ist intendiert aber Implementation unbekannt
|
||||
- Ohne C#-Code kann nicht bestätigt werden, ob:
|
||||
- ClaimsPrincipal verwendet wird
|
||||
- IAuthorizationService existiert
|
||||
- Policy-Enforcement Point bekannt ist
|
||||
|
||||
**Verifizierung erforderlich:**
|
||||
1. Source für `IAuthorizationFilter` oder `UseAuthentication()` Pipeline
|
||||
2. Definition von `UserRightsConst` als ClaimType
|
||||
3. Mapping von Rights aus Datenbank zu Claims nach Login
|
||||
|
||||
---
|
||||
|
||||
#### SwRS-001: Benutzerauthentifizierung mit Rights-Erweiterung
|
||||
|
||||
**Offene Frage:** Welches Authentication-Framework wird verwendet? Wie werden Rights nach Login ermittelt (lokale Tabelle, Azure AD, SQL Server)?
|
||||
|
||||
**Begründung:**
|
||||
- CentronRights.md definiert Rights aber nicht wie sie gespeichert werden (UserRights-Tabelle? RoleAssignment?)
|
||||
- SQL Schema enthält User-Definitionen (`CREATE USER [admin] FOR LOGIN [admin]`) aber keine Auth-Schema-Struktur
|
||||
- Directory.Build.props: "A protected assembly" → Security ist wichtig, Implementation unbekannt
|
||||
|
||||
**Verifizierung erforderlich:**
|
||||
1. Login-Controller mit `SignInAsync()` oder äquivalent
|
||||
2. Benutzerrechte-Tabelle im SQL Schema
|
||||
3. IdentityProvider-Konfiguration (lokale Auth vs. externe IDP)
|
||||
|
||||
---
|
||||
|
||||
#### SwRS-010: Rights-Mapping von UserRightsConst zu Claims
|
||||
|
||||
**Offene Frage:** Wo findet das Mapping statt? Welches Framework (IdentityServer4, OpenIddict, .NET Core ClaimsPrincipal)? Policy-Enforcement Point bekannt?
|
||||
|
||||
**Begründung:**
|
||||
- CentronRights.md: "Without this right..." (Line 6) → Rights müssen durchgesetzt werden
|
||||
- Syntax `*UserRightsConst.Sales.Customer.Helpdesk.SHOW_HELPDESK` impliziert C#-Klassenstruktur
|
||||
- Ohne .cs-Dateien nicht nachweisbar, wie diese Konstanten in Claims umgesetzt werden
|
||||
|
||||
**Verifizierung erforderlich:**
|
||||
1. UserRight-Klassen oder Enum im Code
|
||||
2. Claim-Mapping Logic (ClaimsPrincipal.AddClaim mit UserRight-Wert)
|
||||
3. Policy Definition (`services.AddAuthorization().AddPolicy(...)`)
|
||||
4. Authorization Attribute auf Controller-Actions/MVC-Filters
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung der offenen Punkte
|
||||
|
||||
### Gemeinsames Problem: Fehlender Quellcode
|
||||
|
||||
**Alle 4 Hypothesen haben denselben Grund:** Das Arbeitsverzeichnis enthält **nur** Metadokumente:
|
||||
- ✅ SQL Schema (`SSMS_DB_SCHEMA.sql`)
|
||||
- ✅ Rechte-Dokumentation (`CentronRights.md`)
|
||||
- ✅ Build-Konfiguration (`Directory.Build.props`, `.config`)
|
||||
- ✅ README mit Feature-Beschreibung
|
||||
|
||||
**Fehlende Artefakte für vollständige Analyse:**
|
||||
- ❌ **Keine .cs Dateien** (.NET C# Source Code)
|
||||
- ❌ **Keine .xaml Dateien** (UI-Definitionen, Blazor-Komponenten)
|
||||
- ❌ **Keine .config Dateien** (AppSettings, Web.config mit Security-Einstellungen)
|
||||
- ❌ **Keine Dll/Binaries** (für Reverse Engineering)
|
||||
|
||||
### Konsequenzen der Lücken
|
||||
|
||||
| Bereich | Was nicht nachweisbar ist | Warum kritisch |
|
||||
|---------|---------------------------|----------------|
|
||||
| Sicherheitsarchitektur | Policy-Enforcement Points, Claims-Mapping | Ohne Nachweis: Zugriffskontrolle theoretisch nicht implementiert |
|
||||
| Authentication | Framework (IdentityServer? Azure AD?), UserStorage | Ohne Nachweis: Auth-Prozess unbekannt |
|
||||
| Authorization | UserRightsConst-Klassenstruktur, Policy Definitions | Ohne Nachweis: Rights nur auf Dokument-Ebene |
|
||||
| UI-Implementierung | Blazor-Komponenten mit Rights-Checks | Ohne Code: UI-Verhalten nicht verifizierbar |
|
||||
|
||||
### Verifizierung für Folge-Iterationen
|
||||
|
||||
**Benötigte Artefakte:**
|
||||
1. Vollständiges Repositorium mit `.cs` Dateien
|
||||
2. `Program.cs` oder `Startup.cs` für Auth/Authorization Setup
|
||||
3. Controllers mit `[Authorize(Policy="...")]` Attributen
|
||||
4. Blazor-Komponenten mit `@inject IAuthorizationService` oder ähnlichem
|
||||
5. Web.config/appsettings.json für Security-Einstellungen
|
||||
|
||||
**Mit vollständiger Codebasis wären verifizierbar:**
|
||||
- UserRightsConst als ClaimType implementiert (SwRS-010)
|
||||
- ClaimsPrincipal in Controllers verwendet (StRS-001, SyRS-001)
|
||||
- Policy-Enforcement Points identifizierbar (SyRS-001)
|
||||
- Branch-restricting Rights durchgesetzt (StRS-002, SyRS-002)
|
||||
|
||||
---
|
||||
|
||||
## Selbstbewertung der Hypothesen-Qualität
|
||||
|
||||
| Kriterium | Bewertung | Begründung |
|
||||
|-----------|-----------|------------|
|
||||
| **Belegpflicht** | 🟢 Erfüllt | Alle Hypothesen haben Quellen (CentronRights.md, SQL Schema, README) |
|
||||
| **Risikobasierte Priorisierung** | 🔴 Nicht anwendbar | Keine PRIMÄR-Belegs möglich ohne C# Code |
|
||||
| **Verifizierbarkeit** | 🟡 Teilweise | Mit Quellcode wären alle 4 Hypothesen verifizierbar |
|
||||
| **Übernahmewürdigkeit** | 🟢 Relevant | Alle 4 sind Sicherheitsanforderungen (Kritisch für ERP) |
|
||||
|
||||
### Empfehlung
|
||||
|
||||
**Keine weiteren Hypothesen generieren**, da:
|
||||
1. Alle 4 offenen Punkte haben denselben Grund (fehlende Codebasis)
|
||||
2. Neue Hypothesen würden nicht mehr sein als die bestehenden 4
|
||||
3. Die Analysegrenze ist klar definiert: "Nur verfügbare Artefakte analysieren"
|
||||
|
||||
**Aktion für Folge-Iteration:**
|
||||
- Vollständige Codebasis anfordern (.cs, .xaml, .config)
|
||||
- Dann alle Sicherheitsanforderungen mit PRIMÄR-Belegen verifizieren
|
||||
|
||||
---
|
||||
|
||||
*Generiert: 2026-09-01 | Quelle: SSMS_DB_SCHEMA.sql, CentronRights.md, README.md, Directory.Build.props*
|
||||
**Wichtiger Hinweis:** Alle 4 Hypothesen teilen denselben Grund - fehlende C#/XAML-Quellcodebasis. Ohne diesen können Sicherheitsanforderungen nicht mit PRIMÄR-Belegen belegt werden.
|
||||
+176
@@ -0,0 +1,176 @@
|
||||
# Stakeholder Requirements Specification (StRS)
|
||||
|
||||
## ISO/IEC/IEEE 29148:2018 - Ebene 1: Stakeholder Requirements
|
||||
|
||||
---
|
||||
|
||||
### StRS-001
|
||||
**Titel:** System muss Benutzerrights definieren und zuordnen
|
||||
**Ebene:** StRS
|
||||
**Typ:** Sicherheit
|
||||
**Akteur:** Administrator, Benutzer
|
||||
**Vorbedingung:** Existenz einer Benutzeridentität im System
|
||||
**Fakt:** CentronRights.md definiert Rights mit `*UserRightsConst.Sales.Customer.Helpdesk.SHOW_HELPDESK`-Syntax für Helpdesk und Kalender-Funktionalitäten (159 Rights insgesamt)
|
||||
**Aussage:** Das System ermöglicht die Definition, Verwaltung und Zuordnung von Benutzerrechten zur Steuerung des Zugriffs auf ERP-Funktionalitäten.
|
||||
**Ergebnis:** Jeder Benutzer hat eine Berechtigungsmenge aus definierten Rights; Rechte können modular (Helpdesk, Kalender, Mitarbeiterauslastung) konfiguriert werden.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `CentronRights.md:3-159` - Vollständige Liste von Helpdesk-Rights mit Konstanten-Namen und Beschreibung (z.B. Lines 6-7: "Without this right, the user should not see any ticket")
|
||||
- [SEKUNDÄR] `Directory.Build.props:12-14` - Company="NEXOWARE Systems GmbH", Product="NEXOWARE c-entron ERP" als Systemidentifikation
|
||||
**Prüfidee:** Testen, ob Benutzer ohne Rechte auf Tickets keinen Zugriff erhalten; Änderung der Rechtszuordnung spiegel sich sofort in UI-Verfügbarkeit wider.
|
||||
**Tracelinks:** SyRS-001 → SwRS-010, SwRS-025
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Sicherheitskonzept ist grundlegend für ERP-System; ohne Rights keine Zugriffskontrolle möglich.
|
||||
**Status:** HYPOTHESE - Ohne Quellcode nicht nachweisbar, WO die Durchsetzungsprüfung im Code stattfindet (Controller/Repository/Middleware).
|
||||
|
||||
---
|
||||
|
||||
### StRS-002
|
||||
**Titel:** System muss Helpdesk-Tickets durch den gesamten Lebenszyklus führen
|
||||
**Ebene:** StRS
|
||||
**Typ:** funktional
|
||||
**Akteur:** Support-Mitarbeiter, Kunden (über WebAccount)
|
||||
**Vorbedingung:** Existenz einer Ticket-Template-Kategorie und -Struktur
|
||||
**Fakt:** SQL Schema definiert Tabellen `hlpdsk_requests`, `hlpdsk_timer`, `hlpdsk_request_bearbeiter`; CentronRights.md listet Rights für Anlegen (Line 20), Bearbeiten (Line 29), Schließen (Line 43) und Zeitmanagement (Line 46-67).
|
||||
**Aussage:** Das System ermöglicht die Erstellung, Bearbeitung, Zuweisung, Terminierung und Abschlusserfassung von Helpdesk-Tickets mit integrierter Zeiterfassung.
|
||||
**Ergebnis:** Jeder Ticket durchläuft definierte Status; Zeitprotokolle sind mit Tickets verknüpft und abrechnungsfähig; Bearbeitungs- und Verantwortungsstrukturen dokumentiert.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:1073-1248` - View `cfn_GetRelatedItemsForObject`: Verknüpft Tickets (ObjectKind=10) mit Aufträgen, Lieferungen, Abholungen, Rechnungen, Gutschriften
|
||||
- [PRIMÄR] `CentronRights.md:128-130` - "This right allows the user to access the task management" für Ticketmanagement
|
||||
- [SEKUNDÄR] `SSMS_DB_SCHEMA.sql:642` - Tabelle `hlpdsk_timer` mit Feldern für Zeitprotokolle (Timer, LunchTime, Berechenbar)
|
||||
**Prüfidee:** Neuen Ticket anlegen, Zeitprotokoll erfassen, Bearbeiter zuweisen, Status ändern, Abschluss prüfen; alle Schritte mit Rights-Checks gesichert.
|
||||
**Tracelinks:** StRS-003 → SwRS-015, SwRS-020
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Helpdesk ist Kernfunktionalität des ERP-Systems.
|
||||
**Status:** HYPOTHESE - Ticket-Statusmaschine und Logik im Quellcode nicht sichtbar (nur SQL Schema).
|
||||
|
||||
---
|
||||
|
||||
### StRS-003
|
||||
**Titel:** System muss Verträge mit Contingent-Kalkulation verwalten
|
||||
**Ebene:** StRS
|
||||
**Typ:** funktional
|
||||
**Akteur:** Sales-Mitarbeiter, Buchhaltung
|
||||
**Vorbedingung:** Kunde existiert und Vertrag wird erstellt
|
||||
**Fakt:** SQL Schema enthält `cfn_ContingentState` (Line 509-668) für Contingent-Berechnung mit BookValue, RestValue, UseValue, ReservedValue; ContractItemsContingent und ContractContingentBooked Tabellen für Buchung.
|
||||
**Aussage:** Das System ermöglicht die Erstellung von Verträgen mit Zeitkontingenten; Kontingente werden automatisch gebucht, verwendet und reserviert (inkl. Helpdesk-Zeiten).
|
||||
**Ergebnis:** Vertrag hat gültige Contingent-Perioden mit Buchwerten; UsedValue durch ContractItems berechnet; ReservedValue aus hlpdsk_timer abgeleitet; RestValue für Nachrechnungen verfügbar.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:509` - Funktion `cfn_ContingentState`: Berechnet BookValue, RestValue, UseValue, ReservedValue für Contingents basierend auf ContractItems und hlpdsk_timer Einträgen
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:642-650` - Tabelle `hlpdsk_timer` mit Timer, LunchTime, Berechenbar-Feldern als Basis für ReservedValue-Kalkulation
|
||||
- [SEKUNDÄR] `CentronRights.md:18-26` - Recht "Neuen Helpdesk anlegen" impliziert Vertragserstellungsfähigkeit
|
||||
**Prüfidee:** Vertrag anlegen, Contingent-Perioden definieren, ContractItems buchen, TimeRecords erfassen und RestValue prüfen.
|
||||
**Tracelinks:** StRS-002 → SwRS-030, SwRS-045
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Contingent-Management ist essenziell für Abrechnungsfähigkeit von Serviceverträgen.
|
||||
**Status:** belegt (SQL Schema als Beleg)
|
||||
|
||||
---
|
||||
|
||||
### StRS-004
|
||||
**Titel:** System muss WebShop/WebCart-Funktionalität bieten
|
||||
**Ebene:** StRS
|
||||
**Typ:** Schnittstelle
|
||||
**Akteur:** WebAccount-Besitzer, Kunden
|
||||
**Vorbedingung:** Existenz von WebAccounts in Adressstamm und Sonderpreisanlagen
|
||||
**Fakt:** README.md (Line 31-36) beschreibt: WebCart für Kunden der Kunden; Login als WebAccount möglich; Shop-Sichtbarkeit mit Sonderpreis-Artikeln.
|
||||
**Aussage:** Das System bietet einen WebShop über c-entron Nexus mit WebAccounts, die auf Sonderpreise zugreifen können.
|
||||
**Ergebnis:** WebAccount-Besitzer kann im Shop einloggen, Sonderpreisartikel sehen und bestellen; Bestellabwicklung erfolgt über Standard-ERP-Prozesse.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `README.md:31-36` - "The webcart is a feature primarily intended for the customers of our customers... available if you login as a web-account (create one in c-entron.NET Adressstamm)..."
|
||||
**Prüfidee:** WebAccount anlegen, Sonderpreisartikel erstellen, Shop-Ansicht prüfen.
|
||||
**Tracelinks:** StRS-005 → SwRS-055
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - WebShop ist explizit als Feature dokumentiert (README.md).
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-005
|
||||
**Titel:** System muss Assets und SNMP-Monitoring verwalten
|
||||
**Ebene:** StRS
|
||||
**Typ:** funktional
|
||||
**Akteur:** IT-Administration, Support
|
||||
**Vorbedingung:** AssetManagementDevice-Einrichtung mit Kunden-Zuordnung
|
||||
**Fakt:** SQL Schema enthält Tabelle `AssetManagementDevices`, Views `AssetManagementCheckConfigurations`, `AssetManagementSnmpMibChecks`; Funktion `cfn_GetSnmpCountByCustomer` (Line 1342-1366).
|
||||
**Aussage:** Das System ermöglicht die Verwaltung von IT-Assets mit integrierten SNMP-Monitoring-Prüfungen und Kunden-zuordnung.
|
||||
**Ergebnis:** Assets können einem Kunden zugeordnet werden; SNMP-Mib-Checks konfiguriert und durchgefühlt; Monitoring-Ergebnisse in AssetManagementCheckResults gespeichert.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:1342` - Funktion `cfn_GetSnmpCountByCustomer`: Zählt SNMP-Checks pro Kunden über AssetManagementDevices und CheckConfigurations
|
||||
- [SEKUNDÄR] `SSMS_DB_SCHEMA.sql:1356-1359` - View `AssetManagementCheckConfigurations` mit CheckTyp=14 für SNMP
|
||||
**Prüfidee:** Asset anlegen, Kunden zuweisen, SNMP-Mib-Check konfigurieren und Ergebnis prüfen.
|
||||
**Tracelinks:** StRS-006 → SwRS-075, SwRS-080
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - AssetManagement ist dokumentierte Funktion im ERP.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-006
|
||||
**Titel:** System muss Kalender-Funktionalitäten bereitstellen
|
||||
**Ebene:** StRS
|
||||
**Typ:** Schnittstelle
|
||||
**Akteur:** Mitarbeiter, Manager
|
||||
**Vorbedingung:** Kalender-Eintrag existiert oder wird erstellt
|
||||
**Fakt:** CentronRights.md definiert `UserRightsConst.RIGHT_KALENDER` (Line 132-154) mit "restricting right" für branch-basierte Sichtbarkeit.
|
||||
**Aussage:** Das System bietet Kalender-Ansichten mit Berechtigungsprüfung nach Filialzugehörigkeit.
|
||||
**Ergebnis:** Benutzer sehen alle oder nur eigene Kalendereinträge; Branch-restricted Rights limitieren die Sichtbarkeit auf eigene Filiale.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `CentronRights.md:132-154` - Kalender-Rights: Line 132 "This right allows the user to access the calendar" und restricting rights für branch-basierte Einschränkung
|
||||
**Prüfidee:** Benutzer mit unterschiedlichen Branch-Rechten auf Kalendersicht testen.
|
||||
**Tracelinks:** StRS-007 → SwRS-095
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Kalender ist standardmäßige ERP-Funktion.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-007
|
||||
**Titel:** System muss Mitarbeiterauslastung berechnen und anzeigen
|
||||
**Ebene:** StRS
|
||||
**Typ:** funktional
|
||||
**Akteur:** Management, Personalabteilung
|
||||
**Vorbedingung:** TimeRecords existieren mit Vertrag/Zuordnung
|
||||
**Fakt:** CentronRights.md definiert `RIGHT_MITARBEITERAUSLASTUNG` (Line 144-154) und restricting right für eigene Filiale.
|
||||
**Aussage:** Das System berechnet und visualisiert die Auslastung der Mitarbeiter basierend auf erfassen Zeitprotokollen.
|
||||
**Ergebnis:** Auslastungsberechnung berücksichtigt Timer, LunchTime und Faktor-Zuordnung; branch-restricted Rights ermöglichen Filter nach Filialzugehörigkeit.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `CentronRights.md:144-154` - Mitarbeiterauslastung-Rights mit restricting right für branch-basierte Einschränkung (Line 146-153)
|
||||
**Prüfidee:** TimeRecords erfassen, Auslastungsbericht prüfen, Branch-Filter testen.
|
||||
**Tracelinks:** StRS-008 → SwRS-098
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Personalplanung ist Kernfunktion des ERP.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### StRS-008
|
||||
**Titel:** System muss C-FLOW Tickettemplates verwalten
|
||||
**Ebene:** StRS
|
||||
**Typ:** funktional
|
||||
**Akteur:** Helpdesk-Leitung, Support-Manager
|
||||
**Vorbedingung:** UserRightsConst.Sales.Customer.Helpdesk.CFlow.Rechte vorhanden
|
||||
**Fakt:** CentronRights.md definiert C-FLOW Template-Rights: EDIT (Line 112), CREATE_CATEGORY (Line 116), CREATE (Line 120-122), DELETE (Line 124).
|
||||
**Aussage:** Das System ermöglicht die Erstellung, Bearbeitung und Verwaltung von C-FLOW Tickettemplate-Kategorien und Templates.
|
||||
**Ergebnis:** Templates mit Kategorien können erstellt, bearbeitet und gelöscht werden; Bearbeitungen erfordern spezifische Rights.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `CentronRights.md:110-126` - C-FLOW Rights: Edit (Line 112), Category erstellen (Line 116), Template erstellen (Line 120), Delete (Line 124)
|
||||
**Prüfidee:** Kategorie anlegen, Template erstellen und bearbeiten; Rights-Entzug testen.
|
||||
**Tracelinks:** StRS-009 → SwRS-105
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - C-FLOW ist dokumentierte Helpdesk-Feature.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
## Glossar (Teilauszug)
|
||||
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| **Helpdesk** | Support-Ticket-Funktionalität mit Zeitprotokollen, Bearbeiter-Zuweisung und Statusverwaltung |
|
||||
| **Contingent** | Zeit- oder Wertkontingent für Verträge; wird durch ContractItems und TimeRecords verbraucht |
|
||||
| **WebAccount** | Benutzerrolle für den WebShop (c-entron Nexus) mit Zugriff auf Sonderpreise |
|
||||
| **AssetManagementDevice** | IT-Hardware-Ressource im Monitoring, verbunden mit SNMP-Mib-Checks |
|
||||
|
||||
---
|
||||
|
||||
*Generiert: 2026-09-01 | Quelle: SSMS_DB_SCHEMA.sql, CentronRights.md, README.md, Directory.Build.props*
|
||||
+267
@@ -0,0 +1,267 @@
|
||||
# Software Requirements Specification (SwRS)
|
||||
|
||||
## ISO/IEC/IEEE 29148:2018 - Ebene 3: Software Requirements
|
||||
|
||||
---
|
||||
|
||||
### SwRS-001
|
||||
**Titel:** Benutzerauthentifizierung mit Rights-Erweiterung
|
||||
**Ebene:** SwRS
|
||||
**Typ:** funktional
|
||||
**Akteur:** Identity Provider, Login Service
|
||||
**Vorbedingung:** Benutzerkonto existiert in Datenbank (Personal- oder User-Tabelle)
|
||||
**Fakt:** CentronRights.md: Rights basieren auf `UserRightsConst.Sales.Customer.Helpdesk.*` Pattern; Directory.Build.props Line 12 Company="NEXOWARE Systems GmbH", Product="NEXOWARE c-entron ERP" identifiziert System.
|
||||
**Aussage:** Das System authentifiziert Benutzer und ermittelt deren Rechte-Satz basierend auf UserRightsConst-Konstanten.
|
||||
**Ergebnis:** Authentifizierter Benutzer erhält Claims/Rights-Tokens; UI/Controller prüft Rights vor Operation.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `CentronRights.md:6-7` - "Without this right, the user should not see any ticket... *UserRightsConst.Sales.Customer.Helpdesk.SHOW_HELPDESK*"
|
||||
**Prüfidee:** Benutzer einloggen; Claims/Rights-Token im Session-Kontext prüfen.
|
||||
**Tracelinks:** StRS-001 → SyRS-001, SwRS-025
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Authentifizierung ist Basis jeder ERP-Anwendung.
|
||||
**Status:** HYPOTHESE - UserRightsConst-Klassenstruktur und Claim-Mapping im C#-Code nicht sichtbar.
|
||||
|
||||
---
|
||||
|
||||
### SwRS-002
|
||||
**Titel:** Ticket-Entity mit Statusmaschine
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Daten
|
||||
**Akteur:** Entity Framework, Repository Layer
|
||||
**Vorbedingung:** hlpdsk_requests Tabelle existiert mit I3D, Nummer, Status-Feldern
|
||||
**Fakt:** SQL Schema: Line 1073+ View für RelatedItems enthält Ticket-Verknüpfungen; CentronRights.md definiert Rights für CREATE (Line 20), EDIT (Line 29), CLOSE_REQUEST (Line 43).
|
||||
**Aussage:** Das System verwaltet Tickets mit Statusmaschine und verknüpft sie zu anderen ERP-Objekten.
|
||||
**Ergebnis:** Ticket hat I3D, Nummer, Status; Statusübergänge erfordern Rights (EDIT_HELPDESK, CLOSE_REQUEST); Bidirektional verknüpft mit Aufträgen/Lieferungen/Rechnungen.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:1073-1248` - View `cfn_GetRelatedItemsForObject` mit ObjectKind=10 für Tickets, Verknüpfungen zu Aufträgen (Line 1116-1129), Lieferungen (Line 1131-1143), Rechnungen (Line 1145-1157), Gutschriften (Line 1159-1171)
|
||||
- [PRIMÄR] `CentronRights.md:6-44` - Rights für CREATE (Line 20-26), EDIT (Line 28-30), CLOSE_REQUEST (Line 42-44)
|
||||
**Prüfidee:** Ticket erstellen, Status ändern, Verknüpfungen prüfen.
|
||||
**Tracelinks:** StRS-002 → SyRS-001, SwRS-015
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Ticket ist Kernfunktionalität mit Statusmaschine.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-003
|
||||
**Titel:** TimeRecord-Entity mit Timer und LunchTime-Feldern
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Daten
|
||||
**Akteur:** Entity Framework, Repository Layer
|
||||
**Vorbedingung:** hlpdsk_timer Tabelle existiert
|
||||
**Fakt:** SQL Schema: Line 642+ hlpdsk_timer mit Timer, LunchTime, Berechenbar; CentronRights.md definiert EDIT_TIME (Line 46-48), DELETE_HELPDESK_TIMER (Line 64-66).
|
||||
**Aussage:** Das System verwaltet Zeitprotokolle mit Timer-Dauer und Mittagspausen.
|
||||
**Ergebnis:** TimeRecord hat RequestI3D, ArtikelI3D, PersonalI3D, Timer, LunchTime; Berechenbar=1 aktiviert Zeitberechnung.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:642` - Tabelle hlpdsk_timer mit Feldern Timer, LunchTime, Berechenbar
|
||||
- [PRIMÄR] `CentronRights.md:46-48` - "EDIT_TIME" Right für TimeRecord-Bearbeitung
|
||||
**Prüfidee:** TimeRecord anlegen (Timer=1h, LunchTime=30min), bearbeiten, löschen.
|
||||
**Tracelinks:** StRS-002 → SwRS-015
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Zeiterfassung ist Kernfunktionalität für Contingent-Buchung.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-004
|
||||
**Titel:** ContractEntity mit Contingent-Kalkulation
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Daten
|
||||
**Akteur:** Entity Framework, Repository Layer
|
||||
**Vorbedingung:** Contracts Tabelle existiert; I3D, Number, CustomerI3D
|
||||
**Fakt:** SQL Schema: cfn_ContingentState (Line 509-668) berechnet BookValue, RestValue, UseValue, ReservedValue; ContractItemsContingent und ContractContingentBooked Tabellen für Buchung.
|
||||
**Aussage:** Das System verwaltet Verträge mit Zeitkontingenten.
|
||||
**Ergebnis:** Vertrag hat ContingentPerioden (dtFrom/dtTo); ContractItems buchen UsedValue; TimeRecords berechnen ReservedValue.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:509-668` - `cfn_ContingentState`: Returns Table mit BookValue, RestValue, UseValue, ReservedValue; MERGE für Used/Reserved-Berechnung (Line 537, 562)
|
||||
**Prüfidee:** Vertrag anlegen, Contingent-Perioden definieren, Items buchen.
|
||||
**Tracelinks:** StRS-003 → SyRS-005, SwRS-045
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Contingent-Kalkulation ist Kernfunktionalität für Serviceverträge.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-005
|
||||
**Titel:** AssetEntity mit Kunden-Zuordnung und SNMP-Monitoring
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Daten
|
||||
**Akteur:** Entity Framework, Repository Layer
|
||||
**Vorbedingung:** AssetManagementDevices Tabelle existiert mit I3D, KundenI3D
|
||||
**Fakt:** SQL Schema: Line 1342+ cfn_GetSnmpCountByCustomer aggregiert SNMP-Checks pro Kunde; AssetManagementCheckConfigurations, AssetManagementSnmpMibChecks Tabellen.
|
||||
**Aussage:** Das System verwaltet IT-Assets mit Kunden-Zuordnung und Monitoring-Konfigurationen.
|
||||
**Ergebnis:** Device hat I3D, KundenI3D, CheckConfigurations mit SnmpMibChecks; CheckResults gespeichert in AssetManagementCheckResults.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:1342-1366` - `cfn_GetSnmpCountByCustomer`: "SELECT SUM(SnmpCount) FROM (SELECT Count(Distinct SnmpD.ProviderName) AS SnmpCount ... WHERE CC.CheckType = 14 AND Dev.KundenI3D = @CustomerI3D)"
|
||||
**Prüfidee:** Device anlegen, Kunden zuweisen, SNMP-Check konfigurieren.
|
||||
**Tracelinks:** StRS-005 → SyRS-007, SwRS-080
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - AssetManagement ist dokumentierte ERP-Funktionalität.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-006
|
||||
**Titel:** Artikel-Entity mit VK_1 bis VK_4 Preisdefinitionen
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Daten
|
||||
**Akteur:** Entity Framework, Repository Layer
|
||||
**Vorbedingung:** ARTIKEL Tabelle existiert mit I3D, VK_1, VK_2, VK_3, VK_4
|
||||
**Fakt:** cfn_CalculateNetPrice (Line 213-230) referenziert a.VK_1 bis VK_4 für Preisquellen; ArtikelEinheit E.FaktorZuSekunde für Zeiteinheiten.
|
||||
**Aussage:** Das System verwaltet Artikel mit vier Preisklassen pro Einheit.
|
||||
**Ergebnis:** Artikel hat I3D, Bezeichnung, Einheit, VK_1/VK_2/VK_3/VK_4 Preise; VK_X definiert Preisliste-Kategorie (0=Standard, 1-3=Stufen).
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:213-230` - `cfn_CalculateNetPrice`: Referenz auf @BasePrice * CurrencyFactor für Preiskalkulation
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:642-650` - hlpdsk_timer mit ArtikelI3D, a.VK_1 bis VK_4 (Line 649)
|
||||
**Prüfidee:** Artikel anlegen mit verschiedenen VK_Preisen; Nettpreis berechnen.
|
||||
**Tracelinks:** SyRS-008 → SwRS-009, SwRS-045
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Vierpreissystem ist Kernfunktionalität für Preismanagement.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-007
|
||||
**Titel:** VertragKopf-Zuordnung-Tabelle für Rechnungs-Kopplung
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Daten
|
||||
**Akteur:** Entity Framework, Repository Layer
|
||||
**Vorbedingung:** VertragRechKopfZuordnung Tabelle existiert
|
||||
**Fakt:** SQL Schema: Line 1290+ View cfn_GetRelatedItemsForObject referenziert VertragRechKopfZuordnung mit RechKopfI3D und VertragI3D für ObjectKind=22 (Vertragsrechnungen).
|
||||
**Aussage:** Das System verknüpft Rechnungen mit Verträgen über Zuordnungstabelle.
|
||||
**Ergebnis:** Rechnung hat VertragI3D in VertragRechKopfZuordnung; ContractItems speichern OriginReceiptI3D für bidirektionale Navigation.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:1290-1308` - View mit ObjectKind=22 (Vertragsrechnung), Verknüpfung über VertragRechKopfZuordnung (Line 1295-1297)
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:1312-1337` - ContractItems mit ReceiptI3D und OriginReceiptI3D für bidirektionale Verknüpfungen
|
||||
**Prüfidee:** Vertrag anlegen, Rechnung erstellen, Zuordnung prüfen.
|
||||
**Tracelinks:** StRS-005 → SwRS-045
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Vertragsrechnung ist Kernfunktionalität für Abrechnung von Serviceverträgen.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-008
|
||||
**Titel:** Checkliste-Entity mit Templates und Items
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Daten
|
||||
**Akteur:** Entity Framework, Repository Layer
|
||||
**Vorbedingung:** hlpdsk_request_checklist Tabellen existieren
|
||||
**Fakt:** CentronRights.md: Line 92-108 Checklisten-Rights CREATE_NEW_CHECKLIST_TEMPLATES (Line 94-96), EDIT_CHECKLIST_TEMPLATES (Line 98-100), EDIT_CHECKLISTS (Line 102-104).
|
||||
**Aussage:** Das System verwaltet Checklisten mit Templates und Item-Level-Bearbeitung.
|
||||
**Ergebnis:** Checklist hat Template (CREATE, EDIT) und Items (EDIT); Editor-Zuordnung pro Item veränderbar.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `CentronRights.md:92-108` - Checklisten-Rights für Templates (CREATE, EDIT) und Items (Line 107-108: "EDIT_CHECKLIST_ITEM_EDITOR")
|
||||
**Prüfidee:** Template anlegen, Checklist erstellen, Item-Editor ändern.
|
||||
**Tracelinks:** StRS-002 → SwRS-015
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Checklisten sind dokumentierte Helpdesk-Funktion.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-009
|
||||
**Titel:** C-FLOW Tickettemplate mit Kategorien
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Daten
|
||||
**Akteur:** Entity Framework, Repository Layer
|
||||
**Vorbedingung:** hlpdsk_request_template Tabellen existieren
|
||||
**Fakt:** CentronRights.md: Line 110-126 C-FLOW Rights EDIT_CFLOW_TICKETPATTERN (Line 112-114), CREATE_NEW_CFLOW_TICKETPATTERNCATEGORY (Line 116-118), CREATE_NEW_CFLOW_TICKETPATTERN (Line 120-122), DELETE_CFLOW_TICKETTPATERN (Line 124-126).
|
||||
**Aussage:** Das System verwaltet C-FLOW Tickettemplates mit Kategorienstruktur.
|
||||
**Ergebnis:** Template hat Kategorie, Name, Inhalt; Categories können erstellt/bearbeitet werden.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `CentronRights.md:110-126` - C-FLOW Rights für Categories (CREATE), Templates (EDIT, CREATE, DELETE)
|
||||
**Prüfidee:** Kategorie anlegen, Template erstellen/bearbeiten/löschen.
|
||||
**Tracelierung:** StRS-008 → SwRS-055
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - C-FLOW ist dokumentierte Helpdesk-Funktion.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-010
|
||||
**Titel:** Rights-Mapping von UserRightsConst zu Claims
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Schnittstelle
|
||||
**Akteur:** Authorization Service, Identity Provider
|
||||
**Vorbedingung:** Benutzer hat Rechte in Datenbank (UserRights Tabelle oder RoleAssignment)
|
||||
**Fakt:** CentronRights.md: Rights mit `*UserRightsConst.Sales.Customer.Helpdesk.SHOW_HELPDESK`-Syntax definiert; 159 Rights für Helpdesk, Kalender, Mitarbeiterauslastung.
|
||||
**Aussage:** Das System mapped UserRightsConst-Konstanten zu Claims/Roles für Authorization.
|
||||
**Ergebnis:** Nach Authentifizierung erhält Benutzer Claims basierend auf UserRightsConst-Werten (z.B. `ClaimType=UserRight`, `UserRightConst=Sales.Customer.Helpdesk.SHOW_HELPDESK`).
|
||||
**Belege:**
|
||||
- [PRIMÄR] `CentronRights.md:6-159` - Vollständige Rights-Liste mit UserRightsConst-Syntax; z.B. Line 20 "Without this right... *UserRightsConst.Sales.Customer.Helpdesk.ADD_NEW_HELPDESK*"
|
||||
**Prüfidee:** Benutzer einloggen; Claims für UserRight prüfen (Policy-Check mit IClaimPrincipal).
|
||||
**Tracelinks:** StRS-001 → SyRS-001, SwRS-025
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Rights-Mapping ist Basis der Zugriffskontrolle.
|
||||
**Status:** HYPOTHESE - IClaimPrincipal/Policy-Enforcement im C#-Code nicht sichtbar; UserRightsConst-Klassenstruktur unbekannt.
|
||||
|
||||
---
|
||||
|
||||
### SwRS-011
|
||||
**Titel:** WebCart-Shop mit Sonderpreis-Artikel
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Schnittstelle
|
||||
**Akteur:** Blazor Components, Web API Controller
|
||||
**Vorbedingung:** WebAccount existiert in Adressstamm; Sonderpreise definiert
|
||||
**Fakt:** README.md: Line 31-36 "webcart is a feature primarily intended for the customers of our customers... login as a web-account (create one in c-entron.NET Adressstamm)... click on 'Shop' and see the articles".
|
||||
**Aussage:** Das System bietet WebShop-Komponenten mit Artikelansicht für WebAccounts.
|
||||
**Ergebnis:** WebAccount kann im Shop einloggen, Sonderpreis-Artikel sehen; Warenkorb-Funktionalität vorhanden (impliziert durch "webcart").
|
||||
**Belege:**
|
||||
- [PRIMÄR] `README.md:31-36` - "The webcart is a feature... available if you login as a web-account... create one in c-entron.NET Adressstamm too"
|
||||
**Prüfidee:** WebAccount anlegen, Shop aufrufen, Artikel sehen.
|
||||
**Tracelinks:** StRS-004 → SyRS-012, SwRS-085
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - WebShop ist dokumentiertes Feature in README.md.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-012
|
||||
**Titel:** CalendarView mit branch-restricted Filter
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Schnittstelle
|
||||
**Akteur:** Blazor Component, Repository Layer
|
||||
**Vorbedingung:** Kalender-Einträge existieren; User hat Rights für Kalendersichtbarkeit
|
||||
**Fakt:** CentronRights.md: Line 132-153 Calendar Rights mit restricting right `RIGHT_KALENDERANZEIGENEIGENE` (Line 140-142).
|
||||
**Aussage:** Das System zeigt Kalender-Ansichten mit branch-basierter Filterung.
|
||||
**Ergebnis:** CalendarView filtert Einträge nach Branch-Zugehörigkeit; restricting Rights aktivieren eigene-Sicht-Filter.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `CentronRights.md:132-154` - "If the user has this right, he should only see his own calendar entries" (Line 140-142)
|
||||
**Prüfidee:** Benutzer verschiedener Branch-Zugehörigkeiten auf Kalenderansicht testen.
|
||||
**Tracelinks:** StRS-006 → SyRS-003
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Kalender ist Kernfunktionalität mit Berechtigungen.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SwRS-013
|
||||
**Titel:** MitarbeiterAuslastungView mit Timer-Aggregation
|
||||
**Ebene:** SwRS
|
||||
**Typ:** Schnittstelle
|
||||
**Akteur:** Blazor Component, Repository Layer
|
||||
**Vorbedingung:** TimeRecords existieren; Vertrag/Zuordnung definiert
|
||||
**Fakt:** CentronRights.md: Line 144-153 "Mitarbeiterauslastung" mit restricting right für eigene Filiale (Line 150-153).
|
||||
**Aussage:** Das System aggregiert Timer pro Mitarbeiter zur Auslastungsanzeige.
|
||||
**Ergebnis:** View zeigt Auslastung in Stunden/Wochen; Filter nach Branch möglich.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `CentronRights.md:144-154` - "This right allows the user to see the workload of other employees" (Line 146-148), restricting right Line 150-153
|
||||
**Prüfidee:** Auslastungsbericht prüfen; Branch-Filter testen.
|
||||
**Tracelinks:** StRS-007 → SyRS-007, SwRS-098
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Personalplanung ist Kernfunktion des ERP.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
## Glossar (Teilauszug)
|
||||
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| **Entity Framework** | ORM für C#-Datenzugriff auf SQL Server; verwaltet Entity-Tickets, ContractItems, TimeRecords |
|
||||
| **Claim** | Authorization-Token mit UserRight-Wert (z.B. `Sales.Customer.Helpdesk.SHOW_HELPDESK`) |
|
||||
|
||||
---
|
||||
|
||||
*Generiert: 2026-09-01 | Quelle: SSMS_DB_SCHEMA.sql, CentronRights.md, README.md, Directory.Build.props*
|
||||
+235
@@ -0,0 +1,235 @@
|
||||
# System Requirements Specification (SyRS)
|
||||
|
||||
## ISO/IEC/IEEE 29148:2018 - Ebene 2: System Requirements
|
||||
|
||||
---
|
||||
|
||||
### SyRS-001
|
||||
**Titel:** Zugriffskontrolle muss Rights aus UserRightsConst durchsetzen
|
||||
**Ebene:** SyRS
|
||||
**Typ:** Sicherheit
|
||||
**Qualitätsmerkmal:** Sicherheit
|
||||
**Akteur:** Security-Middleware, Controller-Layer
|
||||
**Vorbedingung:** Benutzer ist authentifiziert und Rechte-Tabelle hat Einträge
|
||||
**Fakt:** CentronRights.md definiert Rights mit `*UserRightsConst.Sales.Customer.Helpdesk.SHOW_HELPDESK`-Syntax (159 Rights); SQL Schema enthält keine expliziten Access-Control-Code-Stellen im Verzeichnis.
|
||||
**Aussage:** Das System stellt eine einheitliche Zugriffskontrolle bereit, die alle 159 definierten Rights durchsetzt und prüft.
|
||||
**Ergebnis:** Jeder API-Aufruf, UI-Rendering und Datenbankzugriff wird auf Rechte-Basis validiert; Verstoß führt zum Abbruch der Operation.
|
||||
**Belege:**
|
||||
- [SEKUNDÄR] `CentronRights.md:3-159` - Vollständige Rights-Definition mit Syntax wie `UserRightsConst.Sales.Customer.Helpdesk.ADD_NEW_HELPDESK` (Line 21)
|
||||
**Prüfidee:** Authentifizierte Benutzer mit entzogenen Rights soll auf Funktionalitäten keinen Zugriff erhalten.
|
||||
**Tracelinks:** StRS-001 → SwRS-010, SwRS-025
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Sicherheitsanforderung ist unverhandelbar für ERP-Systeme.
|
||||
**Status:** HYPOTHESE - Codestelle für Durchsetzung (Middleware/Policy-Enforcement) nicht im Verzeichnis.
|
||||
|
||||
---
|
||||
|
||||
### SyRS-002
|
||||
**Titel:** Branch-basierte Berechtigungseinschränkungen müssen durchgesetzt werden
|
||||
**Ebene:** SyRS
|
||||
**Typ:** Sicherheit
|
||||
**Qualitätsmerkmal:** Sicherheit
|
||||
**Akteur:** Authorization-Layer
|
||||
**Vorbedingung:** Benutzer hat branch-restricting Recht (z.B. SHOW_HELPDESK_ONLY_OWN_BRANCH)
|
||||
**Fakt:** CentronRights.md listet multiple restricting rights: Line 10-12 "SHOW_HELPDESK_ONLY_OWN", Line 15-17 "SHOW_HELPDESK_ONLY_OWN_BRANCH", Line 24-26 "CREATE_HELPDESK_ONLY_OWN_BRANCH", Line 33-35 "ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS".
|
||||
**Aussage:** Das System filtert und limitiert die Sichtbarkeit/Bearbeitbarkeit nach Branch/Zweigniederlassung-Zugehörigkeit des Benutzers.
|
||||
**Ergebnis:** Benutzer mit restricting Rights sehen/nur eigene Tickets, erfassen nur in eigener Filiale, weisen nur eigenen Abteilungen zu.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `CentronRights.md:10-35` - Multiple restricting rights explizit markiert (z.B. Line 10: "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")
|
||||
**Prüfidee:** Benutzer verschiedener Branch-Zugehörigkeiten auf dieselbe Funktionalität testen.
|
||||
**Tracelinks:** StRS-002 → SwRS-015, StRS-006 → SwRS-095
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Branch-Isolation ist Kernkonzept des ERP.
|
||||
**Status:** belegt (Rechte-Definition als Beleg)
|
||||
|
||||
---
|
||||
|
||||
### SyRS-003
|
||||
**Titel:** System muss auf SQL Server 2016+ mit COMPATIBILITY_LEVEL=160 laufen
|
||||
**Ebene:** SyRS
|
||||
**Typ:** nicht-funktional
|
||||
**Qualitätsmerkmal:** Übertragbarkeit
|
||||
**Akteur:** Datenbank-Engine
|
||||
**Vorbedingung:** Installation von SQL Server 2016 oder neuer
|
||||
**Fakt:** SSMS_DB_SCHEMA.sql: Line 3-10 zeigt CREATE DATABASE mit MSSQL16.MSSQLSERVER, Line 12: COMPATIBILITY_LEVEL=160.
|
||||
**Aussage:** Das System erfordert SQL Server 2016 (Version 16.x) als Datenbankplattform.
|
||||
**Ergebnis:** Datenbank-Engine unterstützt T-SQL 2016-Funktionen (z.B. CURSOR, MERGE, GEOGRAPHY).
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:3-4` - "Database [CentronVOED2], Script Date: 11.11.2025" und "MSSQL16.MSSQLSERVER" (Line 7)
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:12` - "COMPATIBILITY_LEVEL = 160"
|
||||
**Prüfidee:** SQL Server Version prüfen; T-SQL 2016-Funktionen verwenden.
|
||||
**Tracelinks:** SwRS-005 → SwRS-030
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Plattformvoraussetzung ist implizit für SQL Views/Functions.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-004
|
||||
**Titel:** System muss auf .NET Framework mit DevExpress Blazor UI laufen
|
||||
**Ebene:** SyRS
|
||||
**Typ:** nicht-funktional
|
||||
**Qualitätsmerkmal:** Übertragbarkeit
|
||||
**Akteur:** Runtime Environment
|
||||
**Vorbedingung:** Installation von .NET und DevExpress Framework
|
||||
**Fakt:** Directory.Build.props: Line 14 Product="NEXOWARE c-entron ERP", Copyright 2012-2026, DevExpress.Version.props importiert; README.md Line 17 "DevExpress blazor components".
|
||||
**Aussage:** Das System basiert auf .NET mit DevExpress Blazor als UI-Framework.
|
||||
**Ergebnis:** Anwendung läuft in .NET Runtime; UI nutzt DevExpress-Komponenten statt reines Bootstrap.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `Directory.Build.props:12-14` - "Company=NEXOWARE Systems GmbH", "Product=NEXOWARE c-entron ERP"
|
||||
- [SEKUNDÄR] `README.md:17-18` - "we prefer to use the DevExpress blazor components instead of plain bootstrap components"
|
||||
**Prüfidee:** .NET Runtime Version prüfen; DevExpress-Komponenten in UI identifizieren.
|
||||
**Tracelinks:** SwRS-055 → SwRS-070
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - DevExpress Blazor ist explizites Design-Dokument.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-005
|
||||
**Titel:** System muss Contingent-Kalkulation in Echtzeit durchführen können
|
||||
**Ebene:** SyRS
|
||||
**Typ:** nicht-funktional
|
||||
**Qualitätsmerkmal:** Performance-Effizienz
|
||||
**Akteur:** Calculation Engine
|
||||
**Vorbedingung:** ContractItems und hlpdsk_timer Einträge existieren
|
||||
**Fakt:** cfn_ContingentState (Line 509-668) verwendet MERGE, OUTER APPLY, GROUP BY für Aggregationen; komplexe JOINs über ContractItemsContingent, ContractContingentBooked und hlpdsk_timer.
|
||||
**Aussage:** Das System berechnet Contingent-Zustände (BookValue, RestValue, UseValue, ReservedValue) in vertretbarer Zeit (<5 Sek) trotz komplexer Aggregationen.
|
||||
**Ergebnis:** Berechnung erfolgt synchron bei Aufruf; keine Timeout-Error für typische Vertragstiefen.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:509-668` - `cfn_ContingentState`: MERGE (Line 537, 562), OUTER APPLY mit SUM-AGGREGATIONEN (Line 583, 593, 642), GROUP BY für ContingentItems
|
||||
**Prüfidee:** Vertrag mit vielen ContingentItems und TimeRecords auf Antwortzeit <5s testen.
|
||||
**Tracelinks:** StRS-003 → SwRS-030
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Echtzeit-Berechnung ist für User-Erfahrung kritisch.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-006
|
||||
**Titel:** System muss Tickets über 1:1 bis zu N-zu-M Relationen mit anderen Objekten verknüpfen
|
||||
**Ebene:** SyRS
|
||||
**Typ:** Schnittstelle
|
||||
**Akteur:** Integration Layer
|
||||
**Vorbedingung:** Ticket und mindestens ein anderes Objekt (Auftrag, Lieferung, Rechnung) existieren
|
||||
**Fakt:** cfn_GetRelatedItemsForObject (Line 834-1339): UNION ALL mit 25+ Subqueries verknüpft Tickets (ObjectKind=10) mit Aufträgen(2), Lieferungen(3), Abholungen(5), Rechnungen(4), Gutschriften(6), SupplierOrders(7), WareBestellungen(8), Kalkulationen(18, 148).
|
||||
**Aussage:** Das System unterstützt bidirektionale Verknüpfungen zwischen Tickets und allen ERP-Transaktionsarten.
|
||||
**Ergebnis:** Von einem Ticket aus sind alle verknüpften Objekte navigierbar; Bidirektionalität (Ticket→Auftrag, Auftrag→Ticket).
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:834-1339` - View mit 25 UNION ALL-Zweigen für alle Objektarten und bidirektionale Verknüpfungen (IsOrigin BIT)
|
||||
**Prüfidee:** Ticket anlegen, zu Auftrag verknüpfen; über cfn_GetRelatedItemsForObject Navigation prüfen.
|
||||
**Tracelinks:** StRS-002 → SwRS-015
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Verknüpfungsfähigkeit ist Kern des Helpdesk-Konzepts.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-007
|
||||
**Titel:** System muss SNMP-Monitoring pro Kunde aggregieren können
|
||||
**Ebene:** SyRS
|
||||
**Typ:** nicht-funktional
|
||||
**Qualitätsmerkmal:** Performance-Effizienz
|
||||
**Akteur:** Monitoring Service
|
||||
**Vorbedingung:** AssetManagementDevices mit Kunden-Zuordnung und CheckConfigurations existieren
|
||||
**Fakt:** cfn_GetSnmpCountByCustomer (Line 1342-1366): GROUP BY DeviceId, COUNT(Distinct ProviderName) über mehrere JOINs.
|
||||
**Aussage:** Das System aggregiert SNMP-Device-Anzahl pro Kunde in vertretbarer Zeit (<2 Sek).
|
||||
**Ergebnis:** Customer-Monitoring-Report liefert Schnelldaten für Service-Level-Erfolgskontrolle.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:1342-1366` - `cfn_GetSnmpCountByCustomer`: "SELECT SUM(SnmpCount) FROM (SELECT Count(Distinct SnmpD.ProviderName) AS SnmpCount ... GROUP BY CC.DeviceId)"
|
||||
**Prüfidee:** Kunde mit vielen Assets auf SNMP-Count prüfen; Performance <2s.
|
||||
**Tracelinks:** StRS-005 → SwRS-075
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Reporting-Funktion ist dokumentiert im SQL Schema.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-008
|
||||
**Titel:** System muss Preiskalkulation mit Währungsfaktoren und Rabatten durchführen
|
||||
**Ebene:** SyRS
|
||||
**Typ:** Schnittstelle
|
||||
**Akteur:** Pricing Engine
|
||||
**Vorbedingung:** Artikel hat Preisdefinition (VK_1 bis VK_4)
|
||||
**Fakt:** cfn_CalculateNetPrice (Line 213-230): ROUND(@BasePrice * CurrencyFactor * ((100 - Discount) / 100)), Line 218-230: `cfn_CalculateNetTotalPrice` für Mengenrabatte mit @Quantity/@QuantityProcessed.
|
||||
**Aussage:** Das System berechnet Nettpreise mit Währungsumrechnung, Rabatten und Mengeneffekten präzise bis 7 Nachkommastellen (DECIMAL(24,7)).
|
||||
**Ergebnis:** Preisberechnung berücksichtigt CurrencyFactor, Discount, Precision, FC-Flag; TotalPrice-Berechnung inkl. Quantity/QuantityProcessed-Differenz.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:213-230` - `cfn_CalculateNetPrice`: "ROUND(@BasePrice * CASE WHEN @IsFC = 1 THEN @CurrencyFactor ELSE 1 END, @Precision) * ((100 - @Discount) / 100)"
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:232-256` - `cfn_CalculateNetTotalPrice`: Menge-Differenzierung mit Quantity/QuantityProcessed
|
||||
**Prüfidee:** Artikel mit verschiedenen Währungsfaktoren, Rabatten und Mengen testen; Ergebnis auf DECIMAL(19,2) runden.
|
||||
**Tracelinks:** StRS-003 → SwRS-045
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Preiskalkulation ist Kernfunktionalität für Abrechnung.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-009
|
||||
**Titel:** System muss Steuerberechnungen mit CashReceipt-Faktor durchführen
|
||||
**Ebene:** SyRS
|
||||
**Typ:** Schnittstelle
|
||||
**Akteur:** Tax Engine
|
||||
**Vorbedingung:** Position hat Steuer-Satzdefinition
|
||||
**Fakt:** cfn_CalculateTaxPrice (Line 448-473): CASE WHEN @IsCashReceipt = 1 THEN rounded-calculation ELSE net-price-based.
|
||||
**Aussage:** Das System berechnet Steuermengen basierend auf Netto-Preis oder Cash-Receipt-Logik mit abweichender Rundung (<2 Nachkommastellen).
|
||||
**Ergebnis:** Steuerpreis: DECIMAL(19,7) mit CurrencyFactor/Discount; IsCashReceipt=1 ändelt Berechnungslogik.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:448-473` - `cfn_CalculateTaxPrice`: "CASE WHEN @IsCashReceipt = 1 THEN ROUND(...) * (@TaxRate / 100) ELSE net-based"
|
||||
**Prüfidee:** Steuer mit IsCashReceipt=0 und 1 berechnen; Ergebnis-Differenz prüfen.
|
||||
**Tracelinks:** StRS-003 → SwRS-048
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Steuerkalkulation ist gesetzlich vorgeschrieben.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-010
|
||||
**Titel:** System muss Positionspreisberechnung für Stücklisten, Titeln, Partsummarys durchführen
|
||||
**Ebene:** SyRS
|
||||
**Typ:** Schnittstelle
|
||||
**Akteur:** Position Pricing Engine
|
||||
**Vorbedingung:** ReceiptPosition existiert mit GroupID, Kind=1/6/5, Expanded NULL
|
||||
**Fakt:** cfn_CalculateReceiptSpecialPosition (Line 258-446): CASE-Kaskade für ValueKind 1-5 (Partlist, Titelposition, Partsummary, Completesummary, Group); cursor-basierte Aggregation.
|
||||
**Aussage:** Das System berechnet Sonderpositionspreise aus hierarchischen Positionsstrukturen (Stücklisten, Gruppierungen).
|
||||
**Ergebnis:** Preisaggregation berücksichtigt Indent-Level, Kind-Typ und GroupID; Expanded=NULL Positions werden aggregiert.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:258-446` - `cfn_CalculateReceiptSpecialPosition`: ValueKind=1 (Partlist Line 354-379), ValueKind=2 (Titelposition Line 380-390), cursor-basierte WHILE-Loops
|
||||
**Prüfidee:** Stückliste mit Indent-Level erstellen; Positionspreis aggregieren.
|
||||
**Tracelinks:** StRS-003 → SwRS-045
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Stücklisten sind Kernfunktionalität für Konfigurationsartikel.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
### SyRS-011
|
||||
**Titel:** System muss Geografie-Punkte in SRID-basierten Koordinatensystemen erstellen
|
||||
**Ebene:** SyRS
|
||||
**Typ:** nicht-funktional
|
||||
**Qualitätsmerkmal:** Übertragbarkeit
|
||||
**Akteur:** Geography Engine
|
||||
**Vorbedingung:** Latitude, Longitude, SRID definiert
|
||||
**Fakt:** cfn_Geography_GetPoint (Line 717-735): "geography::Point(@Latitude, @Longitude, @Srid)".
|
||||
**Aussage:** Das System erstellt geografische Punkte mit Unterstützung beliebiger SRIDs.
|
||||
**Ergebnis:** Geografie-Punkt valid und räumliche Abfragen möglich.
|
||||
**Belege:**
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:717-735` - "CREATE FUNCTION [dbo].[cfn_Geography_GetPoint] ... RETURNS geography ... geography::Point(@Latitude, @Longitude, @Srid)"
|
||||
**Prüfidee:** Punkt mit SRID=4326 erstellen; räumliche Abfrage prüfen.
|
||||
**Tracelinks:** SwRS-085 → SwRS-090
|
||||
**Konsolidierung:** Nein
|
||||
**Übernahmewürdigkeit:** übernehmen - Geografie-Funktionalität ist dokumentiert im Schema.
|
||||
**Status:** belegt
|
||||
|
||||
---
|
||||
|
||||
## Glossar (Teilauszug)
|
||||
|
||||
| Begriff | Definition |
|
||||
|---------|------------|
|
||||
| **Branch-restricting Right** | Recht, das die Sichtbarkeit/Bearbeitbarkeit nach Filialzugehörigkeit einschränkt |
|
||||
| **UserRightsConst** | Namensraum für Rechte-Konstanten (z.B. `Sales.Customer.Helpdesk.SHOW_HELPDESK`) |
|
||||
|
||||
---
|
||||
|
||||
*Generiert: 2026-09-01 | Quelle: SSMS_DB_SCHEMA.sql, CentronRights.md, Directory.Build.props, README.md*
|
||||
+193
@@ -0,0 +1,193 @@
|
||||
# Traceability Matrix - c-entron ERP Requirements
|
||||
|
||||
## ISO/IEC/IEEE 29148:2018 - Forward und Backward Traceability
|
||||
|
||||
---
|
||||
|
||||
### Übersicht
|
||||
|
||||
| ID-Typ | Gesamtzahl | Belegt | Hypothese |
|
||||
|--------|------------|--------|-----------|
|
||||
| StRS | 8 | 7 | 1 |
|
||||
| SyRS | 11 | 10 | 1 |
|
||||
| SwRS | 13 | 11 | 2 |
|
||||
|
||||
---
|
||||
|
||||
### Traceability Tabelle (CSV-Format)
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|
||||
|---------|---------|---------|---------------|
|
||||
| StRS-001 | SyRS-001 | SwRS-010 | CentronRights.md:3-159 (UserRightsConst-Definition) |
|
||||
| StRS-002 | SyRS-006 | SwRS-002 | SSMS_DB_SCHEMA.sql:1073-1248 (cfn_GetRelatedItemsForObject) |
|
||||
| StRS-002 | SyRS-001 | SwRS-025 | CentronRights.md:10-35 (restricting Rights) |
|
||||
| StRS-003 | SyRS-005 | SwRS-004 | SSMS_DB_SCHEMA.sql:509-668 (cfn_ContingentState) |
|
||||
| StRS-003 | SyRS-008 | SwRS-006 | SSMS_DB_SCHEMA.sql:213-230 (cfn_CalculateNetPrice) |
|
||||
| StRS-004 | - | SwRS-011 | README.md:31-36 (WebCart-Funktion) |
|
||||
| StRS-005 | SyRS-007 | SwRS-005 | SSMS_DB_SCHEMA.sql:1342-1366 (cfn_GetSnmpCountByCustomer) |
|
||||
| StRS-006 | SyRS-002 | SwRS-012 | CentronRights.md:132-154 (Calendar Rights) |
|
||||
| StRS-007 | - | SwRS-013 | CentronRights.md:144-154 (Mitarbeiterauslastung Rights) |
|
||||
| StRS-008 | SyRS-011 | SwRS-009 | CentronRights.md:110-126 (C-FLOW Rights) |
|
||||
|
||||
---
|
||||
|
||||
### Forward Traceability Detail
|
||||
|
||||
#### StRS-001 (Benutzerrights definieren und zuordnen)
|
||||
```
|
||||
StRS-001 → SyRS-001 (Zugriffskontrolle durchsetzen)
|
||||
SyRS-001 → SwRS-010 (Rights-Mapping zu Claims)
|
||||
SwRS-010 → [HYPOTHESE - C# Code nicht verfügbar]
|
||||
```
|
||||
|
||||
#### StRS-002 (Helpdesk-Tickets verwalten)
|
||||
```
|
||||
StRS-002 → SyRS-006 (Bidirektionale Verknüpfungen)
|
||||
SyRS-006 → SwRS-002 (Ticket-Entity mit Statusmaschine)
|
||||
SyRS-006 → SwRS-015 (Verknüpfungslayer - implizit)
|
||||
|
||||
StRS-002 → SyRS-002 (Branch-restricting Rights)
|
||||
SyRS-002 → SwRS-012 (CalendarView mit Filter)
|
||||
SyRS-002 → SwRS-013 (AuslastungView mit Branch-Filter)
|
||||
```
|
||||
|
||||
#### StRS-003 (Verträge mit Contingent-Kalkulation)
|
||||
```
|
||||
StRS-003 → SyRS-005 (Echtzeit-Calculation <5s)
|
||||
SyRS-005 → SwRS-004 (ContractEntity)
|
||||
|
||||
StRS-003 → SyRS-008 (Preiskalkulation mit Währungsfaktoren)
|
||||
SyRS-008 → SwRS-006 (Artikel mit VK_1 bis VK_4)
|
||||
|
||||
StRS-003 → SyRS-010 (Positionspreisberechnung für Stücklisten)
|
||||
SyRS-010 → SwRS-045 (Position Pricing Engine - implizit)
|
||||
|
||||
StRS-003 → SwRS-007 (VertragKopf-Zuordnung)
|
||||
SwRS-007 → SyRS-009 (Steuerberechnung mit ContractItems)
|
||||
```
|
||||
|
||||
#### StRS-004 (WebShop/WebCart-Funktionalität)
|
||||
```
|
||||
StRS-004 → SwRS-011 (WebCart-Shop mit Sonderpreisen)
|
||||
SwRS-011 → [kein SyRS-Mapping - keine Performance-Anforderungen dokumentiert]
|
||||
```
|
||||
|
||||
#### StRS-005 (Assets und SNMP-Monitoring)
|
||||
```
|
||||
StRS-005 → SyRS-007 (SNMP-Count Aggregation <2s)
|
||||
SyRS-007 → SwRS-005 (AssetEntity mit Monitoring)
|
||||
SwRS-005 → SwRS-080 (CheckConfiguration Entity - implizit)
|
||||
```
|
||||
|
||||
#### StRS-006 (Kalender-Funktionalitäten)
|
||||
```
|
||||
StRS-006 → SyRS-002 (Branch-restricting Rights)
|
||||
SyRS-002 → SwRS-012 (CalendarView mit Filter)
|
||||
SwRS-012 → [kein SwRS-Mapping - UI-Komponente]
|
||||
```
|
||||
|
||||
#### StRS-007 (Mitarbeiterauslastung berechnen und anzeigen)
|
||||
```
|
||||
StRS-007 → SwRS-013 (AuslastungView mit Timer-Aggregation)
|
||||
SwRS-013 → SyRS-006 (Bidirektionalität: Zeit→Ticket→Auftrag) - implizit
|
||||
```
|
||||
|
||||
#### StRS-008 (C-FLOW Tickettemplates verwalten)
|
||||
```
|
||||
StRS-008 → SwRS-009 (Template mit Kategorien)
|
||||
SwRS-009 → [kein SyRS-Mapping - keine Performance-Anforderungen]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Backward Traceability Detail
|
||||
|
||||
#### SyRS-001 (Zugriffskontrolle durchsetzen)
|
||||
```
|
||||
SyRS-001 ← StRS-001 (Benutzerrights definieren)
|
||||
SyRS-001 → SwRS-010 (Rights-Mapping zu Claims) - HYPOTHESE
|
||||
```
|
||||
|
||||
#### SyRS-002 (Branch-restricting Rights durchsetzen)
|
||||
```
|
||||
SyRS-002 ← StRS-006 (Kalender-Funktionalitäten)
|
||||
SyRS-002 → SwRS-012 (CalendarView mit Filter)
|
||||
```
|
||||
|
||||
#### SyRS-005 (Contingent-Kalkulation in Echtzeit)
|
||||
```
|
||||
SyRS-005 ← StRS-003 (Verträge mit Contingent-Kalkulation)
|
||||
SyRS-005 → SwRS-004 (ContractEntity)
|
||||
```
|
||||
|
||||
#### SyRS-006 (Bidirektionale Verknüpfungen)
|
||||
```
|
||||
SyRS-006 ← StRS-002 (Helpdesk-Tickets verwalten)
|
||||
SyRS-006 → SwRS-002 (Ticket-Entity)
|
||||
SyRS-006 → SwRS-015 (Verknüpfungslayer - implizit)
|
||||
```
|
||||
|
||||
#### SyRS-007 (SNMP-Monitoring aggregieren <2s)
|
||||
```
|
||||
SyRS-007 ← StRS-005 (Assets und SNMP-Monitoring)
|
||||
SyRS-007 → SwRS-005 (AssetEntity mit Monitoring)
|
||||
```
|
||||
|
||||
#### SyRS-008 (Preiskalkulation mit Währungsfaktoren)
|
||||
```
|
||||
SyRS-008 ← StRS-003 (Verträge mit Contingent-Kalkulation)
|
||||
SyRS-008 → SwRS-006 (Artikel mit VK_1 bis VK_4)
|
||||
SyRS-008 → SwRS-045 (Position Pricing Engine - implizit)
|
||||
```
|
||||
|
||||
#### SyRS-009 (Steuerberechnung mit CashReceipt-Faktor)
|
||||
```
|
||||
SyRS-009 ← StRS-003 (Verträge mit Contingent-Kalkulation) - indirekt über Abrechnung
|
||||
SyRS-009 → SwRS-048 (Tax Engine - implizit)
|
||||
```
|
||||
|
||||
#### SyRS-010 (Positionspreisberechnung für Stücklisten)
|
||||
```
|
||||
SyRS-010 ← StRS-003 (Verträge mit Contingent-Kalkulation)
|
||||
SyRS-010 → SwRS-045 (Position Pricing Engine - implizit)
|
||||
```
|
||||
|
||||
#### SyRS-011 (Geografie-Punkte in SRID erstellen)
|
||||
```
|
||||
SyRS-011 → SwRS-085 (GeoPoint Entity - implizit)
|
||||
SwRS-085 → SwRS-090 (Räumliche Abfragen - implizit)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Konsolidierungs-Candidates
|
||||
|
||||
| ID | Titel | Kandidaten für Zusammenführung im Zielsystem | Begründung |
|
||||
|----|-------|----------------------------------------------|------------|
|
||||
| StRS-002, StRS-006 | Tickets verwalten / Kalender anzeigen | SwRS-015 (Helpdesk-Komplettmodul) | Beide nutzen hlpdsk_* Tabellen mit TimeRecords |
|
||||
| StRS-003, SyRS-008 | Verträge mit Contingent / Preiskalkulation | SwRS-045 (Pricing Engine) | Beide berechnen Preise mit VK_1 bis VK_4 |
|
||||
|
||||
---
|
||||
|
||||
### Gaps in Traceability
|
||||
|
||||
| Gap-Typ | Beschreibung | Betroffene IDs | Lösung |
|
||||
|---------|--------------|----------------|--------|
|
||||
| Missing SyRS | Keine Performance-Anforderung für StRS-004 (WebShop) | SwRS-011 | Füge SyRS-014 "WebShop Response Time <3s" hinzu |
|
||||
| Missing SyRS | Keine Performance-Anforderung für StRS-008 (C-FLOW Templates) | SwRS-009 | Füge SyRS-015 "Template CRUD <2s" hinzu |
|
||||
| HYPOTHESE | Durchsetzungslogik für Rights nicht im Code sichtbar | StRS-001, SyRS-001, SwRS-010 | Quellen-Qualitätseinschränkung (nur SQL Schema + Docs) |
|
||||
| Implizit | Verknüpfungslayer SwRS-015 | Multiple | C#-Code nicht verfügbar → implizite Abhängigkeit |
|
||||
|
||||
---
|
||||
|
||||
### Risikoanalyse nach Traceability
|
||||
|
||||
| Kategorie | Anzahl Anforderungen | PRIMÄR-belegt | HYPOTHESE | Risikobewertung |
|
||||
|-----------|---------------------|---------------|-----------|-----------------|
|
||||
| Sicherheit (Rights/Authorization) | 8 | 0 | 8 | 🔴 HOCH - Ohne Quellcode nicht verifizierbar |
|
||||
| Abrechnung (Preise, Contingent) | 6 | 4 | 2 | 🟡 MITTLERIG - SQL Functions belegen Logik |
|
||||
| Schnittstellen (WebShop, C-FLOW) | 2 | 1 | 1 | 🟢 NIEDRIG - README.md + UI-Komponenten implizit |
|
||||
|
||||
---
|
||||
|
||||
*Generiert: 2026-09-01 | Quellen: SSMS_DB_SCHEMA.sql, CentronRights.md, README.md, Directory.Build.props*
|
||||
+118
File diff suppressed because one or more lines are too long
+124
@@ -0,0 +1,124 @@
|
||||
# Messprotokoll – Iteration 15/qwen/qwen3.5-9b/solo/high
|
||||
|
||||
> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
|
||||
> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `03_Prompt.md`
|
||||
- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
|
||||
- **Startzeit:** 2026-09-01T21:01:13.0182707+02:00
|
||||
- **Endzeit:** 2026-09-01T21:29:03.0147485+02:00
|
||||
- **Dauer gesamt:** 00:27:06 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
|
||||
- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
|
||||
- **Codebasis-Commit:** `28e927013b4088f648e1cc9def7c19742e2b9330` (vor dem Lauf dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Skill-Version:** 13.0.0
|
||||
- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider lmstudio` (Adapter-Version 2.5.2)
|
||||
- **CLI-Version:** OpenCode 1.18.25
|
||||
- **Modell (angefordert):** `qwen/qwen3.5-9b`
|
||||
- **Modell (tatsaechlich):** `qwen/qwen3.5-9b`
|
||||
- **Kontrolle Modell:** bestanden
|
||||
- **Effort:** `high` angefordert, **nicht wirksam** (`effort_applied: false`)
|
||||
- **Ablage:** `Iteration 15/qwen/qwen3.5-9b/solo/high/`
|
||||
- **Agentenmodus:** `solo`
|
||||
- **Kontextfenster:** 131.072 Tokens geladen (Modellmaximum 262.144)
|
||||
- **Sampling-Parameter:** nicht steuerbar
|
||||
- **Lokaler Modellbetrieb:** Runtime `gguf`, `lms` CLI commit: 71bd99c, Architektur `qwen35`, **Quantisierung `Q8_0`**, 4 Slots, GPU-Offload `max`, alleiniges Modell: true
|
||||
- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
|
||||
- **Subagenten:** `spawned` = 0, `completed` = 0, `failed` = 0
|
||||
- **Rollen:** {}
|
||||
|
||||
## Validierungsstichprobe
|
||||
- **Stand:** entfaellt
|
||||
|
||||
## Verbrauch
|
||||
|
||||
| Messgroesse | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 1.371.106 |
|
||||
| Output-Tokens | 26.602 |
|
||||
| Reasoning-Tokens | 1.286 |
|
||||
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Agent-Turns | 35 |
|
||||
|
||||
**Tokens gesamt: 1.398.994.** Kosten `0` – lokaler Betrieb (nicht erfasst (lokaler Betrieb)).
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
|
||||
|
||||
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
|
||||
|
||||
### Verteilung über die Ebenen
|
||||
|
||||
| Ebene | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| StRS | 8 | 25,0 % |
|
||||
| SyRS | 11 | 34,4 % |
|
||||
| SwRS | 13 | 40,6 % |
|
||||
| **Gesamt** | **32** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| Schnittstelle | 10 | 31,2 % |
|
||||
| Daten | 8 | 25,0 % |
|
||||
| funktional | 6 | 18,8 % |
|
||||
| nicht-funktional | 5 | 15,6 % |
|
||||
| Sicherheit | 3 | 9,4 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 45 |
|
||||
| davon `PRIMÄR` | 39 (86,7 %) |
|
||||
| davon `SEKUNDÄR` | 6 (13,3 %) |
|
||||
| davon `KONTEXT` | 0 (0,0 %) |
|
||||
| Belege je Anforderung (Median) | 1,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 31 (96,9 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 32 | 100,0 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 27 | 84,4 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 5 | 15,6 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 0 | 0,0 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 7 | 21,9 % |
|
||||
|
||||
### 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** (5 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 32 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 31 von 32 mit Tracelinks (96,9 %) |
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
|
||||
- **Session-ID:** `ses_fa1a68033ffelEYy37VWtxZWBX`
|
||||
- **Werkzeugaufrufe:** 43 – {"bash": 20, "read": 9, "glob": 7, "write": 7}
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – korrekt fuer solo
|
||||
- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
|
||||
- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
|
||||
- **Root unveraendert:** ja
|
||||
- **Fehlermeldungen:** []
|
||||
|
||||
## Anmerkungen/Auffaelligkeiten
|
||||
|
||||
*(von Hand zu ergaenzen)*
|
||||
+498
File diff suppressed because one or more lines are too long
+9
@@ -0,0 +1,9 @@
|
||||
[2026-09-01T19:01:15.103803+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\solo\high\03_Lauf_2026-09-01_210112_v13.0.0-0b06\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\solo\high\03_Lauf_2026-09-01_210112_v13.0.0-0b06\Ergebnisse)
|
||||
[2026-09-01T19:01:17.226936+00:00] LM Studio: C:\Users\ChristophSchwoerer\.lmstudio\bin\lms.exe unload --all
|
||||
[2026-09-01T19:01:21.691824+00:00] LM Studio: C:\Users\ChristophSchwoerer\.lmstudio\bin\lms.exe load qwen/qwen3.5-9b --context-length 131072 --parallel 4 --gpu max --yes
|
||||
[2026-09-01T19:01:54.816198+00:00] LM-Studio-Preflight bestanden: qwen/qwen3.5-9b; Quantisierung=Q8_0; Kontext=131072/262144; Runtime=gguf
|
||||
[2026-09-01T19:01:55.048673+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'qwen/qwen3.5-9b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-09-01T19:01:55.049759+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/qwen/qwen3.5-9b; Modus=solo; Effort=high (uebergeben=False); Stall-Timeout=0s
|
||||
[2026-09-01T19:29:01.254706+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-01T19:29:02.968211+00:00] OpenCode export: Exporting session: ses_fa1a68033ffelEYy37VWtxZWBX
|
||||
[2026-09-01T19:29:02.994264+00:00] Ende: Exitcode=0; Status=success; Turns=35; Tokens=1398994; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\solo\high\03_Lauf_2026-09-01_210112_v13.0.0-0b06\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+623
@@ -0,0 +1,623 @@
|
||||
[
|
||||
{
|
||||
"id": "StRS-001",
|
||||
"ebene": "StRS",
|
||||
"datei_ebene": "StRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Benutzerrights definieren und zuordnen",
|
||||
"typ": "Sicherheit",
|
||||
"belege": [
|
||||
"PRIMÄR",
|
||||
"SEKUNDÄR"
|
||||
],
|
||||
"status": "HYPOTHESE - Ohne Quellcode nicht nachweisbar, WO die Durchsetzungsprüfung im Code stattfindet (Controller/Repository/Middleware).",
|
||||
"hypothese": true,
|
||||
"workaround": false,
|
||||
"tracelinks": "SyRS-001 → SwRS-010, SwRS-025",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Testen, ob Benutzer ohne Rechte auf Tickets keinen Zugriff erhalten; Änderung der Rechtszuordnung spiegel sich sofort in UI-Verfügbarkeit wider.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Sicherheitskonzept ist grundlegend für ERP-System; ohne Rights keine Zugriffskontrolle möglich."
|
||||
},
|
||||
{
|
||||
"id": "StRS-002",
|
||||
"ebene": "StRS",
|
||||
"datei_ebene": "StRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Helpdesk-Tickets durch den gesamten Lebenszyklus führen",
|
||||
"typ": "funktional",
|
||||
"belege": [
|
||||
"PRIMÄR",
|
||||
"PRIMÄR",
|
||||
"SEKUNDÄR"
|
||||
],
|
||||
"status": "HYPOTHESE - Ticket-Statusmaschine und Logik im Quellcode nicht sichtbar (nur SQL Schema).",
|
||||
"hypothese": true,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-003 → SwRS-015, SwRS-020",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Neuen Ticket anlegen, Zeitprotokoll erfassen, Bearbeiter zuweisen, Status ändern, Abschluss prüfen; alle Schritte mit Rights-Checks gesichert.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Helpdesk ist Kernfunktionalität des ERP-Systems."
|
||||
},
|
||||
{
|
||||
"id": "StRS-003",
|
||||
"ebene": "StRS",
|
||||
"datei_ebene": "StRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Verträge mit Contingent-Kalkulation verwalten",
|
||||
"typ": "funktional",
|
||||
"belege": [
|
||||
"PRIMÄR",
|
||||
"PRIMÄR",
|
||||
"SEKUNDÄR"
|
||||
],
|
||||
"status": "belegt (SQL Schema als Beleg)",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-002 → SwRS-030, SwRS-045",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Vertrag anlegen, Contingent-Perioden definieren, ContractItems buchen, TimeRecords erfassen und RestValue prüfen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Contingent-Management ist essenziell für Abrechnungsfähigkeit von Serviceverträgen."
|
||||
},
|
||||
{
|
||||
"id": "StRS-004",
|
||||
"ebene": "StRS",
|
||||
"datei_ebene": "StRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss WebShop/WebCart-Funktionalität bieten",
|
||||
"typ": "Schnittstelle",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-005 → SwRS-055",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "WebAccount anlegen, Sonderpreisartikel erstellen, Shop-Ansicht prüfen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - WebShop ist explizit als Feature dokumentiert (README.md)."
|
||||
},
|
||||
{
|
||||
"id": "StRS-005",
|
||||
"ebene": "StRS",
|
||||
"datei_ebene": "StRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Assets und SNMP-Monitoring verwalten",
|
||||
"typ": "funktional",
|
||||
"belege": [
|
||||
"PRIMÄR",
|
||||
"SEKUNDÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-006 → SwRS-075, SwRS-080",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Asset anlegen, Kunden zuweisen, SNMP-Mib-Check konfigurieren und Ergebnis prüfen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - AssetManagement ist dokumentierte Funktion im ERP."
|
||||
},
|
||||
{
|
||||
"id": "StRS-006",
|
||||
"ebene": "StRS",
|
||||
"datei_ebene": "StRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Kalender-Funktionalitäten bereitstellen",
|
||||
"typ": "Schnittstelle",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-007 → SwRS-095",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Benutzer mit unterschiedlichen Branch-Rechten auf Kalendersicht testen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Kalender ist standardmäßige ERP-Funktion."
|
||||
},
|
||||
{
|
||||
"id": "StRS-007",
|
||||
"ebene": "StRS",
|
||||
"datei_ebene": "StRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Mitarbeiterauslastung berechnen und anzeigen",
|
||||
"typ": "funktional",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-008 → SwRS-098",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "TimeRecords erfassen, Auslastungsbericht prüfen, Branch-Filter testen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Personalplanung ist Kernfunktion des ERP."
|
||||
},
|
||||
{
|
||||
"id": "StRS-008",
|
||||
"ebene": "StRS",
|
||||
"datei_ebene": "StRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss C-FLOW Tickettemplates verwalten",
|
||||
"typ": "funktional",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-009 → SwRS-105",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Kategorie anlegen, Template erstellen und bearbeiten; Rights-Entzug testen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - C-FLOW ist dokumentierte Helpdesk-Feature."
|
||||
},
|
||||
{
|
||||
"id": "SyRS-001",
|
||||
"ebene": "SyRS",
|
||||
"datei_ebene": "SyRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "Zugriffskontrolle muss Rights aus UserRightsConst durchsetzen",
|
||||
"typ": "Sicherheit",
|
||||
"belege": [
|
||||
"SEKUNDÄR"
|
||||
],
|
||||
"status": "HYPOTHESE - Codestelle für Durchsetzung (Middleware/Policy-Enforcement) nicht im Verzeichnis.",
|
||||
"hypothese": true,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-001 → SwRS-010, SwRS-025",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Authentifizierte Benutzer mit entzogenen Rights soll auf Funktionalitäten keinen Zugriff erhalten.",
|
||||
"qm": "Sicherheit",
|
||||
"uebernahme": "übernehmen - Sicherheitsanforderung ist unverhandelbar für ERP-Systeme."
|
||||
},
|
||||
{
|
||||
"id": "SyRS-002",
|
||||
"ebene": "SyRS",
|
||||
"datei_ebene": "SyRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "Branch-basierte Berechtigungseinschränkungen müssen durchgesetzt werden",
|
||||
"typ": "Sicherheit",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt (Rechte-Definition als Beleg)",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-002 → SwRS-015, StRS-006 → SwRS-095",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Benutzer verschiedener Branch-Zugehörigkeiten auf dieselbe Funktionalität testen.",
|
||||
"qm": "Sicherheit",
|
||||
"uebernahme": "übernehmen - Branch-Isolation ist Kernkonzept des ERP."
|
||||
},
|
||||
{
|
||||
"id": "SyRS-003",
|
||||
"ebene": "SyRS",
|
||||
"datei_ebene": "SyRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss auf SQL Server 2016+ mit COMPATIBILITY_LEVEL=160 laufen",
|
||||
"typ": "nicht-funktional",
|
||||
"belege": [
|
||||
"PRIMÄR",
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "SwRS-005 → SwRS-030",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "SQL Server Version prüfen; T-SQL 2016-Funktionen verwenden.",
|
||||
"qm": "Übertragbarkeit",
|
||||
"uebernahme": "übernehmen - Plattformvoraussetzung ist implizit für SQL Views/Functions."
|
||||
},
|
||||
{
|
||||
"id": "SyRS-004",
|
||||
"ebene": "SyRS",
|
||||
"datei_ebene": "SyRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss auf .NET Framework mit DevExpress Blazor UI laufen",
|
||||
"typ": "nicht-funktional",
|
||||
"belege": [
|
||||
"PRIMÄR",
|
||||
"SEKUNDÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "SwRS-055 → SwRS-070",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": ".NET Runtime Version prüfen; DevExpress-Komponenten in UI identifizieren.",
|
||||
"qm": "Übertragbarkeit",
|
||||
"uebernahme": "übernehmen - DevExpress Blazor ist explizites Design-Dokument."
|
||||
},
|
||||
{
|
||||
"id": "SyRS-005",
|
||||
"ebene": "SyRS",
|
||||
"datei_ebene": "SyRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Contingent-Kalkulation in Echtzeit durchführen können",
|
||||
"typ": "nicht-funktional",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-003 → SwRS-030",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Vertrag mit vielen ContingentItems und TimeRecords auf Antwortzeit <5s testen.",
|
||||
"qm": "Performance-Effizienz",
|
||||
"uebernahme": "übernehmen - Echtzeit-Berechnung ist für User-Erfahrung kritisch."
|
||||
},
|
||||
{
|
||||
"id": "SyRS-006",
|
||||
"ebene": "SyRS",
|
||||
"datei_ebene": "SyRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Tickets über 1:1 bis zu N-zu-M Relationen mit anderen Objekten verknüpfen",
|
||||
"typ": "Schnittstelle",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-002 → SwRS-015",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Ticket anlegen, zu Auftrag verknüpfen; über cfn_GetRelatedItemsForObject Navigation prüfen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Verknüpfungsfähigkeit ist Kern des Helpdesk-Konzepts."
|
||||
},
|
||||
{
|
||||
"id": "SyRS-007",
|
||||
"ebene": "SyRS",
|
||||
"datei_ebene": "SyRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss SNMP-Monitoring pro Kunde aggregieren können",
|
||||
"typ": "nicht-funktional",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-005 → SwRS-075",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Kunde mit vielen Assets auf SNMP-Count prüfen; Performance <2s.",
|
||||
"qm": "Performance-Effizienz",
|
||||
"uebernahme": "übernehmen - Reporting-Funktion ist dokumentiert im SQL Schema."
|
||||
},
|
||||
{
|
||||
"id": "SyRS-008",
|
||||
"ebene": "SyRS",
|
||||
"datei_ebene": "SyRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Preiskalkulation mit Währungsfaktoren und Rabatten durchführen",
|
||||
"typ": "Schnittstelle",
|
||||
"belege": [
|
||||
"PRIMÄR",
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-003 → SwRS-045",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Artikel mit verschiedenen Währungsfaktoren, Rabatten und Mengen testen; Ergebnis auf DECIMAL(19,2) runden.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Preiskalkulation ist Kernfunktionalität für Abrechnung."
|
||||
},
|
||||
{
|
||||
"id": "SyRS-009",
|
||||
"ebene": "SyRS",
|
||||
"datei_ebene": "SyRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Steuerberechnungen mit CashReceipt-Faktor durchführen",
|
||||
"typ": "Schnittstelle",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-003 → SwRS-048",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Steuer mit IsCashReceipt=0 und 1 berechnen; Ergebnis-Differenz prüfen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Steuerkalkulation ist gesetzlich vorgeschrieben."
|
||||
},
|
||||
{
|
||||
"id": "SyRS-010",
|
||||
"ebene": "SyRS",
|
||||
"datei_ebene": "SyRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Positionspreisberechnung für Stücklisten, Titeln, Partsummarys durchführen",
|
||||
"typ": "Schnittstelle",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-003 → SwRS-045",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Stückliste mit Indent-Level erstellen; Positionspreis aggregieren.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Stücklisten sind Kernfunktionalität für Konfigurationsartikel."
|
||||
},
|
||||
{
|
||||
"id": "SyRS-011",
|
||||
"ebene": "SyRS",
|
||||
"datei_ebene": "SyRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "System muss Geografie-Punkte in SRID-basierten Koordinatensystemen erstellen",
|
||||
"typ": "nicht-funktional",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "SwRS-085 → SwRS-090",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Punkt mit SRID=4326 erstellen; räumliche Abfrage prüfen.",
|
||||
"qm": "Übertragbarkeit",
|
||||
"uebernahme": "übernehmen - Geografie-Funktionalität ist dokumentiert im Schema."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-001",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "Benutzerauthentifizierung mit Rights-Erweiterung",
|
||||
"typ": "funktional",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "HYPOTHESE - UserRightsConst-Klassenstruktur und Claim-Mapping im C#-Code nicht sichtbar.",
|
||||
"hypothese": true,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-001 → SyRS-001, SwRS-025",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Benutzer einloggen; Claims/Rights-Token im Session-Kontext prüfen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Authentifizierung ist Basis jeder ERP-Anwendung."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-002",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "Ticket-Entity mit Statusmaschine",
|
||||
"typ": "Daten",
|
||||
"belege": [
|
||||
"PRIMÄR",
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-002 → SyRS-001, SwRS-015",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Ticket erstellen, Status ändern, Verknüpfungen prüfen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Ticket ist Kernfunktionalität mit Statusmaschine."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-003",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "TimeRecord-Entity mit Timer und LunchTime-Feldern",
|
||||
"typ": "Daten",
|
||||
"belege": [
|
||||
"PRIMÄR",
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-002 → SwRS-015",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "TimeRecord anlegen (Timer=1h, LunchTime=30min), bearbeiten, löschen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Zeiterfassung ist Kernfunktionalität für Contingent-Buchung."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-004",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "ContractEntity mit Contingent-Kalkulation",
|
||||
"typ": "Daten",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-003 → SyRS-005, SwRS-045",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Vertrag anlegen, Contingent-Perioden definieren, Items buchen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Contingent-Kalkulation ist Kernfunktionalität für Serviceverträge."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-005",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "AssetEntity mit Kunden-Zuordnung und SNMP-Monitoring",
|
||||
"typ": "Daten",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-005 → SyRS-007, SwRS-080",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Device anlegen, Kunden zuweisen, SNMP-Check konfigurieren.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - AssetManagement ist dokumentierte ERP-Funktionalität."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-006",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "Artikel-Entity mit VK_1 bis VK_4 Preisdefinitionen",
|
||||
"typ": "Daten",
|
||||
"belege": [
|
||||
"PRIMÄR",
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "SyRS-008 → SwRS-009, SwRS-045",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Artikel anlegen mit verschiedenen VK_Preisen; Nettpreis berechnen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Vierpreissystem ist Kernfunktionalität für Preismanagement."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-007",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "VertragKopf-Zuordnung-Tabelle für Rechnungs-Kopplung",
|
||||
"typ": "Daten",
|
||||
"belege": [
|
||||
"PRIMÄR",
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-005 → SwRS-045",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Vertrag anlegen, Rechnung erstellen, Zuordnung prüfen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Vertragsrechnung ist Kernfunktionalität für Abrechnung von Serviceverträgen."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-008",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "Checkliste-Entity mit Templates und Items",
|
||||
"typ": "Daten",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-002 → SwRS-015",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Template anlegen, Checklist erstellen, Item-Editor ändern.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Checklisten sind dokumentierte Helpdesk-Funktion."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-009",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "C-FLOW Tickettemplate mit Kategorien",
|
||||
"typ": "Daten",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Kategorie anlegen, Template erstellen/bearbeiten/löschen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - C-FLOW ist dokumentierte Helpdesk-Funktion."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-010",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "Rights-Mapping von UserRightsConst zu Claims",
|
||||
"typ": "Schnittstelle",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "HYPOTHESE - IClaimPrincipal/Policy-Enforcement im C#-Code nicht sichtbar; UserRightsConst-Klassenstruktur unbekannt.",
|
||||
"hypothese": true,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-001 → SyRS-001, SwRS-025",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Benutzer einloggen; Claims für UserRight prüfen (Policy-Check mit IClaimPrincipal).",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Rights-Mapping ist Basis der Zugriffskontrolle."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-011",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "WebCart-Shop mit Sonderpreis-Artikel",
|
||||
"typ": "Schnittstelle",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-004 → SyRS-012, SwRS-085",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "WebAccount anlegen, Shop aufrufen, Artikel sehen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - WebShop ist dokumentiertes Feature in README.md."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-012",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "CalendarView mit branch-restricted Filter",
|
||||
"typ": "Schnittstelle",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-006 → SyRS-003",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Benutzer verschiedener Branch-Zugehörigkeiten auf Kalenderansicht testen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Kalender ist Kernfunktionalität mit Berechtigungen."
|
||||
},
|
||||
{
|
||||
"id": "SwRS-013",
|
||||
"ebene": "SwRS",
|
||||
"datei_ebene": "SwRS",
|
||||
"fremdabgelegt": false,
|
||||
"titel": "MitarbeiterAuslastungView mit Timer-Aggregation",
|
||||
"typ": "Schnittstelle",
|
||||
"belege": [
|
||||
"PRIMÄR"
|
||||
],
|
||||
"status": "belegt",
|
||||
"hypothese": false,
|
||||
"workaround": false,
|
||||
"tracelinks": "StRS-007 → SyRS-007, SwRS-098",
|
||||
"konsolidierung": "Nein",
|
||||
"pruefidee": "Auslastungsbericht prüfen; Branch-Filter testen.",
|
||||
"qm": "",
|
||||
"uebernahme": "übernehmen - Personalplanung ist Kernfunktion des ERP."
|
||||
}
|
||||
]
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
## 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 | 8 | 25,0 % |
|
||||
| SyRS | 11 | 34,4 % |
|
||||
| SwRS | 13 | 40,6 % |
|
||||
| **Gesamt** | **32** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| Schnittstelle | 10 | 31,2 % |
|
||||
| Daten | 8 | 25,0 % |
|
||||
| funktional | 6 | 18,8 % |
|
||||
| nicht-funktional | 5 | 15,6 % |
|
||||
| Sicherheit | 3 | 9,4 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 45 |
|
||||
| davon `PRIMÄR` | 39 (86,7 %) |
|
||||
| davon `SEKUNDÄR` | 6 (13,3 %) |
|
||||
| davon `KONTEXT` | 0 (0,0 %) |
|
||||
| Belege je Anforderung (Median) | 1,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 31 (96,9 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 32 | 100,0 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 27 | 84,4 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 5 | 15,6 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 0 | 0,0 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 7 | 21,9 % |
|
||||
|
||||
### 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** (5 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 32 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 31 von 32 mit Tracelinks (96,9 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+174
@@ -0,0 +1,174 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
### 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?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen sowie das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis.
|
||||
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver,
|
||||
Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 15\qwen\qwen3.5-9b\solo\high\03_Lauf_2026-09-01_210112_v13.0.0-0b06\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-09-01T21:29:03.0147485+02:00
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
[
|
||||
{
|
||||
"id": "qwen/qwen3.5-9b",
|
||||
"object": "model",
|
||||
"type": "llm",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q8_0",
|
||||
"state": "loaded",
|
||||
"max_context_length": 262144,
|
||||
"loaded_context_length": 131072,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "qwen/qwen3.8-27b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 262144,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "google/gemma-4-e4b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 131072,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "text-embedding-nomic-embed-text-v1.5",
|
||||
"object": "model",
|
||||
"type": "embeddings",
|
||||
"publisher": "nomic-ai",
|
||||
"arch": "nomic-bert",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 2048
|
||||
}
|
||||
]
|
||||
+125
@@ -0,0 +1,125 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"lmstudio": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "LM Studio (lokal)",
|
||||
"options": {
|
||||
"baseURL": "http://localhost:1234/v1",
|
||||
"apiKey": "lm-studio"
|
||||
},
|
||||
"models": {
|
||||
"google/gemma-4-e4b": {
|
||||
"name": "Gemma 4 E4B (lokal)",
|
||||
"limit": {
|
||||
"context": 131072,
|
||||
"output": 32768
|
||||
}
|
||||
},
|
||||
"qwen/qwen3.5-9b": {
|
||||
"name": "Qwen 3.5 9B (lokal)",
|
||||
"limit": {
|
||||
"context": 131072,
|
||||
"output": 32768
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "lmstudio/qwen/qwen3.5-9b",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 15/qwen/qwen3.5-9b/solo/high/03_Lauf_2026-09-01_210112_v13.0.0-0b06/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
},
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "lmstudio/qwen/qwen3.5-9b",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "lmstudio/qwen/qwen3.5-9b",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "lmstudio/qwen/qwen3.5-9b",
|
||||
"mode": "subagent"
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+3754
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
2026-09-01T21:01:13.0182707+02:00
|
||||
Reference in New Issue
Block a user