Zum Inhalt

DiveLogix360 – Standard für Use-Case-Dossiers

Stand: 15.10.2026 15:38 Branch: main Status: Aktiv

Änderungshistorie anzeigen

Verbindlichkeit: Dieses Dokument definiert die einheitliche Einstiegs- und Navigationsstruktur für alle Use Cases (UCs).
Prinzip: Ein Dossier ist der zentrale Einstiegspunkt, nicht der alleinige physische Ablageort.

Ziel und Geltungsbereich

Jeder Use Case erhält in seinem Ordner eine README.md. Sie führt alle fachlichen und technischen Artefakte des Use Cases zusammen, ohne bestehende Inhalte zu kopieren oder ihre fachlich sinnvolle Ablage zu verändern. Der Standard gilt für UC00 bis UC09, UC-SA und UC18 sowie für künftig ergänzte Use Cases.

Schnellzugriff und Navigation

Jedes Dossier enthält direkt unter dem Einleitungsblock die Zeile **Schnellzugriff:** mit sprechenden Links auf Spezifikation, Abschlusscheckliste und Screen-Übersicht des Use Cases, getrennt durch ·. Ein Link wird erst aufgenommen, wenn die Zieldatei existiert.

Im Menü der Dokumentation (mkdocs.yml) erhält jeder Use Case unter «Use Cases» einen eigenen Abschnitt mit den Einträgen Dossier, Spezifikation, Abschlusscheckliste und Screens in dieser Reihenfolge. Auch hier wird ein Eintrag erst ergänzt, wenn die Datei existiert. Die Gruppe «Screen-Galerien» bleibt als Gesamtübersicht aller Screens bestehen; ihre Einträge heissen Screens UCxx und verweisen als Link auf die Screen-Übersicht des Use Cases, damit die Seite im Menü nur einmal, beim jeweiligen Use Case, geführt wird.

Verbindliche Kapitelstruktur

Alle Dossiers verwenden exakt diese Überschriften, diesen Wortlaut und diese Reihenfolge:

  1. Überblick
  2. Fachliche Dokumentation
  3. Benutzerabläufe und Oberflächen
  4. Datenmodell
  5. Programmierschnittstellen
  6. Architekturentscheidungen
  7. Datenschutz und Compliance
  8. Implementierung
  9. Tests und Abnahme
  10. Offene Punkte

Die Kapitel dürfen nicht entfernt, umbenannt oder umsortiert werden. Gibt es zu einem Kapitel noch kein Artefakt, wird dies mit dem Status Offen dokumentiert. Ist ein Kapitel fachlich nicht relevant, wird Nicht anwendbar verwendet und begründet.

Die Gates der Abschlusscheckliste folgen diesen Kapiteln; Gate 10 heisst abweichend «Abschluss und Konsistenz» (siehe Verbindliche Abschlusscheckliste).

Einheitliche Tabellenstruktur

Die Kapitel 2 bis 10 führen Artefakte mit denselben Spalten:

Artefakt Status Verbindlichkeit Ablageort Hinweis
Beispiel Vorhanden Verbindlich pfad/zum/dokument.md Kurze Einordnung

Unter Ablageort wird der kanonische Repository-Pfad angegeben. Existiert das Artefakt noch nicht, wird der geplante Pfad genannt und nicht verlinkt.

Einheitliche Statuswerte

Status Bedeutung
Vorhanden Das Artefakt existiert und ist für seinen beschriebenen Zweck verwendbar.
Teilweise vorhanden Das Artefakt existiert, enthält aber noch erkennbare Lücken.
Offen Das Artefakt fehlt oder wurde noch nicht begonnen.
Zur Prüfung Das Artefakt liegt vor, benötigt aber noch fachliche oder technische Freigabe.
Historisch Das Artefakt dokumentiert einen früheren Stand und ist nicht mehr führend.
Nicht anwendbar Das Kapitel oder Artefakt ist für diesen Use Case begründet nicht relevant.

Einheitliche Verbindlichkeitswerte

Verbindlichkeit Bedeutung
Verbindlich Freigegebene fachliche oder organisatorische Vorgabe.
Technische Wahrheit Massgebliche technische Definition des aktuellen Systems.
Abgeleitet Zusammenfassung oder Sicht auf eine führende Quelle.
Prüfnachweis Review, Abgleich oder Testergebnis mit Nachweischarakter.
Geplant Vorgesehene, aber noch nicht erstellte oder freigegebene Quelle.
Historisch Nicht mehr führende Quelle eines früheren Stands.

Kanonische Ablage und Verantwortlichkeit

Informationsart Führende Quelle
Fachliche Regeln und Akzeptanzkriterien Use-Case-Spezifikation im jeweiligen UC-Ordner
Datenbankschema backend/prisma/schema.prisma
Vertiefte Schema-Prüfung docs/developer/database/schema-abgleich/
Programmierschnittstellen OpenAPI-Dokumente unter docs/api/
Architekturentscheidung Einzeldatei und Register unter docs/developer/adr/
Umsetzungsfortschritt und Aufgaben docs/management/project-status.md
Review-Ergebnisse Jeweiliger Review-Ablageort als Prüfnachweis

Das Dossier verlinkt diese Quellen und ordnet sie ein. Es ersetzt sie nicht. Widersprüche werden im Kapitel Offene Punkte benannt und an der führenden Quelle behoben.

Kopfbereich und Änderungshistorie

Jedes Dossier und jede zentrale Dossier-Dokumentation enthält:

  • direkt nach dem Titel den Kopf mit Stand (Datum und Uhrzeit), Branch und Status;
  • unter dem Kopf den Sprunglink [Änderungshistorie anzeigen](#change-history) und eine Trennlinie;
  • am Dokumentende die Sprungmarke <a id="change-history"></a> und den Abschnitt ## Änderungshistorie mit einer chronologisch absteigenden Tabelle mit Datum, Version, Änderung und Autor.

Der verbindliche Aufbau ist in AGENTS.md im Abschnitt «Dokumentaufbau» festgelegt; Referenz ist docs/index.md.

Bei jeder inhaltlichen Änderung werden Stand, Version und Änderungshistorie in derselben Änderung nachgeführt. Abkürzungen werden bei der ersten Verwendung ausgeschrieben.

Verbindliche Abschlusscheckliste

Jeder Use Case erhält zusätzlich eine Datei <uc>-abschlusscheckliste.md. Sie bildet die zehn Dossier-Kapitel als Abnahme-Gates ab und verwendet stabile Kriterien-IDs nach dem Muster UCXX-01-01 bis UCXX-10-NN.

Die Gates tragen in allen Abschlusschecklisten diese verbindlichen Namen:

Gate Name Bezug zum Dossier
01 Überblick Kapitel 1
02 Fachliche Dokumentation Kapitel 2
03 Benutzerabläufe und Oberflächen Kapitel 3
04 Datenmodell Kapitel 4
05 Programmierschnittstellen Kapitel 5
06 Architekturentscheidungen Kapitel 6
07 Datenschutz und Compliance Kapitel 7
08 Implementierung Kapitel 8
09 Tests und Abnahme Kapitel 9
10 Abschluss und Konsistenz Kapitel 10 Offene Punkte: Das Gate prüft, dass die dort geführten Punkte und Widersprüche erledigt sind und Dossier, Spezifikation, Implementierung und Nachweise formal konsolidiert sind

Jede Abschlusscheckliste verwendet diesen Aufbau (Vorlage: UC-ABSCHLUSSCHECKLISTE-TEMPLATE.md):

  1. Kopfbereich gemäss Abschnitt «Kopfbereich und Änderungshistorie».
  2. Einleitung mit Zweck, Abgrenzung zum Projektstatus und Verweis auf das Dossier.
  3. ## Verbindliche Regeln mit Statuswerten, Nachweispflicht und Ableitung des Gate-Status.
  4. ## Gate-Übersicht mit den Spalten Gate | Bereich | Status und allen zehn Gates.
  5. Je Gate ein Abschnitt ## <Nummer>. <Gate-Name> mit den Spalten ID | Abschlusskriterium | Pflicht | Status | Nachweis | Projektstatus.
  6. ## Nächster Bearbeitungspunkt.
  7. Änderungshistorie am Dokumentende.

Der Status eines Gates ergibt sich aus seinen Kriterien: Erledigt, wenn alle Kriterien erledigt oder begründet nicht anwendbar sind; In Bearbeitung, sobald mindestens ein Kriterium begonnen ist; sonst Offen. Die Spalte Pflicht enthält Ja oder Nein; Prioritäten werden nicht in der Checkliste geführt. Die Spalte Projektstatus verweist auf den zugehörigen Abschnitt im Projektstatus.

Jedes Kriterium erhält am Anfang der Spalte Abschlusskriterium ein Sprungziel mit seiner Kriterien-ID in Kleinbuchstaben, zum Beispiel <a id="uc00-08-08"></a>. Verweise auf ein Kriterium aus anderen Dokumenten verlinken direkt auf dieses Sprungziel, zum Beispiel uc00-abschlusscheckliste.md#uc00-08-08.

Jedes Kriterium von Gate 08 beginnt – nach dem Sprungziel – mit Backend: oder Frontend:. Betrieb, Infrastruktur, Datenbank und Sicherheit zählen zu Backend. Betrifft ein Kriterium beide Bereiche, wird es in ein Backend- und ein Frontend-Kriterium mit eigener ID aufgeteilt. Jede Abschlusscheckliste enthält in Gate 08 mindestens ein Backend- und ein Frontend-Kriterium.

Aus der Abschlusscheckliste wird die Fortschrittsschätzung je Use Case berechnet (siehe Projektstatus, Legende).

Zulässige Kriterienstatus sind Offen, In Bearbeitung, Blockiert, Zur Prüfung, Erledigt und Nicht anwendbar. Ein Kriterium darf nur mit verlinktem oder eindeutig bezeichnetem Nachweis als Erledigt gelten. Nicht anwendbar erfordert ebenfalls eine dokumentierte Begründung.

Der Projektstatus bleibt die führende Quelle für Aufgaben, Prioritäten und Bearbeitungsfortschritt. Die Abschlusscheckliste ist die führende Quelle für die Abnahmereife. Das Dossier zeigt den zusammengefassten Stand und verlinkt beide Quellen.

Der fachliche Status Abgeschlossen setzt die Erledigung aller fachlichen Pflichtkriterien voraus. Der Status Produktionsbereit setzt die Erledigung aller Pflichtkriterien voraus. Begründet nicht anwendbare Kriterien gelten dabei als abgeschlossen.

Einführungs- und Pflegeprozess

  1. Bestehende Artefakte inventarisieren.
  2. Dossier aus der verbindlichen Vorlage erstellen.
  3. Kanonische Quellen verlinken und ihren Status einordnen.
  4. Abschlusscheckliste mit stabilen Kriterien-IDs erstellen.
  5. Lücken als offene Punkte erfassen.
  6. Umsetzungs- und Testaufgaben im Projektstatus ergänzen.
  7. Dossier und betroffene Quellen einschliesslich Änderungshistorien aktualisieren.
  8. Struktur- und Abschlusschecklistenprüfung ausführen.
  9. Änderungen gemeinsam veröffentlichen.

Die Einführung wurde mit UC00 als Pilot begonnen und für UC01 bis UC09, UC-SA und UC18 abgeschlossen. Alle Use Cases werden im Dokumentationsindex über ihr Dossier erschlossen. Inhaltliche Lücken und widersprüchliche Artefaktstatus bleiben in Dossier, Inventar und Abschlusscheckliste ausdrücklich offen.

Automatisierte Prüfung

Das Skript tools/validate-uc-dossiers.ps1 prüft Struktur, Kopfbereich, lokale Verweise sowie vorhandene Abschlusschecklisten auf eindeutige IDs, erlaubte Statuswerte und Nachweise für erledigte Kriterien. Fehlende Dossiers und Abschlusschecklisten sind nach Abschluss des Rollouts Fehler. Das Skript ist deshalb verbindlich mit -Strict auszuführen. Die Strukturprüfung bestätigt nicht die Fachlichkeit, Implementierung oder Produktionsreife.

Änderungshistorie

Datum, Uhrzeit Version Änderung Autor
15.10.2026 15:38 1.11 Sprungziel je Kriterium und direkte Verlinkung von Kriterienverweisen festgelegt (Entscheid David Mittig vom 15.10.2026) Claude
15.10.2026 11:17 1.10 Benennung der Einträge unter «Screen-Galerien» als «Screens UCxx» festgelegt Claude
15.10.2026 11:10 1.9 Schnellzugriffszeile im Dossier und Menüaufbau je Use Case verbindlich festgelegt (Entscheid David Mittig vom 15.10.2026) Claude
15.10.2026 09:32 1.8 Verweis auf die Fortschrittsschätzung je Use Case im Projektstatus ergänzt Claude
15.10.2026 08:44 1.7 Kennzeichnung der Gate-08-Kriterien mit «Backend:» / «Frontend:» und Aufteilung gemischter Kriterien festgelegt (Entscheid David Mittig vom 15.10.2026) Claude
15.10.2026 08:31 1.6 Verbindlichen Aufbau der Abschlusscheckliste festgelegt (Aufbau von UC00, einheitliche Spalten, Pflicht statt Priorität, Ableitung des Gate-Status), Vorlage verlinkt und Verweis von der Kapitelstruktur auf die Gate-Namen ergänzt (Entscheid David Mittig vom 15.10.2026) Claude
15.10.2026 08:03 1.5 Verbindliche Gate-Namen der Abschlusscheckliste festgelegt; Gate 10 «Abschluss und Konsistenz» mit Bezug zum Kapitel «Offene Punkte» (Entscheid David Mittig vom 15.10.2026) Claude
12.10.2026 09:58 1.4 Dossier-Aufbau an den einheitlichen Dokumentaufbau gemäss AGENTS.md angepasst: Sprunglink unter dem Kopf, Änderungshistorie am Dokumentende Claude
12.08.2026 16:55 1.3 Dossier-Rollout abgeschlossen und strikten Prüfmodus verbindlich gesetzt Codex
07.08.2026 18:38 1.2 Schweizer Schreibweise in verbindlichen Begriffen bereinigt Codex
07.08.2026 17:44 1.1 Verbindliche Abschlusscheckliste, Abnahmeregeln und automatisierte Nachweiskontrolle ergänzt Codex
07.08.2026 17:30 1.0 Verbindlichen Aufbau, Terminologie und Pflegeprozess für Use-Case-Dossiers eingeführt Codex