DiveLogix360 – Einstieg für Projektbeteiligte

Stand: 12.08.2026 16:55 Branch: main Status: Aktiv

Datum, Uhrzeit	Version	Änderung	Autor
12.08.2026 16:55	1.0	Rollenbezogene Leserführung und Arbeitsweise für Projektbeteiligte erstellt	Codex

---

Zweck: Neue Projektbeteiligte sollen schnell erkennen, welche Dokumente sie benötigen und welche Quelle bei Detailfragen verbindlich ist.

Einstieg in 30 Minuten

Reihenfolge	Dokument	Leitfrage
1	Produktübersicht	Was ist DiveLogix360 und welchen Nutzen soll es bieten?
2	Funktionsübersicht	Welche Funktionen und Use Cases gehören zum Produkt?
3	Aktueller Projektstand	Was ist spezifiziert, implementiert und noch offen?
4	Architekturüberblick	Wie ist die Anwendung technisch grundsätzlich aufgebaut?
5	Produkt-Roadmap	Was gehört verbindlich zu V1, V2 und V3?

Danach sollte nur noch der für die eigene Aufgabe relevante Detailbereich gelesen werden.

Fachliche Mitarbeit

Empfohlene Reihenfolge:

1. Funktionsübersicht
2. Dossier des betroffenen Use Cases
3. zugehörige Use-Case-Spezifikation
4. Screen- und Ablaufdokumente
5. Akzeptanzkriterien und Abschlusscheckliste
6. betroffener Abschnitt im Projektstatus

Fachliche Anforderungen werden in der Use-Case-Spezifikation geklärt. Der Projektstatus beschreibt den Bearbeitungsstand, nicht die fachliche Wahrheit.

Technische Mitarbeit

Empfohlene Reihenfolge:

1. Architekturüberblick
2. ADR-Register
3. Dossier und Spezifikation des betroffenen Use Cases
4. API-Dokumentation
5. backend/prisma/schema.prisma als technische Wahrheit des Datenmodells
6. relevante Implementierung und Tests
7. betroffener Abschnitt im Projektstatus

Eine technische Umsetzung darf fachliche Lücken nicht durch Annahmen schliessen.

Projektsteuerung

Fragestellung	Führendes Dokument
Was ist aktuell in Arbeit oder offen?	Projektstatus
Was gehört zu welcher Produktversion?	Produkt-Roadmap
Was wurde wann projektweit erreicht oder entschieden?	Projekt-Historie
Welche fachliche Regel gilt?	jeweilige Use-Case-Spezifikation
Welche Architekturentscheidung gilt?	jeweiliges Architecture Decision Record

Datenschutz, Recht und Sicherheit

Für eine Prüfung sind mindestens relevant:

1. Dossier und Spezifikation des betroffenen Use Cases;
2. zugehörige Compliance-Dokumente;
3. betroffene Architecture Decision Records;
4. Provider- und Unterauftragnehmerregister;
5. technische und organisatorische Massnahmen;
6. Abnahmekriterien, Tests und externe Freigaben.

Interne Dokumentation ersetzt keine ausdrücklich erforderliche unabhängige juristische, Datenschutz- oder Sicherheitsprüfung.

Dokumenttypen richtig einordnen

Dokumenttyp	Bedeutung
Führende Quelle	Verbindlicher aktueller Stand für eine klar benannte Informationsart
Abgeleitete Übersicht	Verständliche Zusammenfassung mit Verweis auf führende Quellen
Dossier	Zentraler Einstieg und Wegweiser für einen Use Case
Architecture Decision Record	Dokumentierte technische Grundsatzentscheidung
Prüfnachweis	Ergebnis eines Reviews, Tests oder Abgleichs
Arbeitsdokument	Noch nicht verbindlich abgeschlossener Bearbeitungsstand
Historisch	Frühere, nicht mehr führende Fassung oder Vorgehensweise
Vorlage	Wiederverwendbare Struktur ohne projektspezifische Aussage

Umgang mit Widersprüchen

1. Nicht selbst entscheiden, welche beliebige Aussage plausibler erscheint.
2. Informationsart bestimmen.
3. Die dafür führende Quelle ermitteln.
4. Widerspruch offen dokumentieren.
5. Korrektur an der führenden Quelle klären.
6. Betroffene Übersichten und Verweise in derselben Änderung nachführen.

Abkürzungen

Begriff	Bedeutung
ADR	Architecture Decision Record, dokumentierte Architekturentscheidung
API	Programmierschnittstelle
AVV	Auftragsverarbeitungsvertrag
PWA	Progressive Web App
RLS	Row-Level Security, zeilenbasierte Zugriffskontrolle
Tenant	technisch und fachlich getrennte Kundenorganisation, hier eine Tauchschule
UC	Use Case, fachlich abgegrenzter Anwendungsfall

Vor einer Weitergabe

• Stand der kompakten Statusübersicht mit dem detaillierten Projektstatus vergleichen.
• Nur die für den Empfänger relevanten Detailbereiche zusätzlich verlinken.
• Arbeits- und Prüfdokumente nicht als verbindliche Produktaussage darstellen.
• Bei sensiblen Inhalten die interne Vertraulichkeit beachten.
• Offene Fragen und erwartete Mitarbeit konkret benennen.