DiveLogix360 — Produkt-Roadmap & Versions-Backlog¶
Stand: 16.10.2026 11:11 Branch: main Status: Vertraulich | Internes Arbeitsdokument
Märkte: DE | CH | AT
Inhaltsverzeichnis¶
- Projektübersicht
- Version 1 — MVP
- Version 2 — Erweiterungen
- Version 3 — Vision
- Version 4 — Optionen
- Offene Entscheide & Designprinzipien
- Meilensteine und Prioritäten
- Rechtsgrundlagen & Datenschutz-Compliance
- Quellenverzeichnis
1. Projektübersicht¶
DiveLogix360 ist eine mandantenfähige SaaS-Plattform für Tauchschulen im DACH-Raum. Sie digitalisiert die Verwaltung von TÜV-Inspektionen (Druckluftflaschen nach EN 1802/EN 1968), Inhouse-Services (Regler, Jacket) und bietet Endkunden ein Tracking-Portal für ihre eigene Ausrüstung.
1.1 Geschäftsmodell¶
Direkte SaaS-Kunden (Tenants) sind Tauchschulen. Endkunden (Taucher) erhalten über Modell B ein read-only Kundenportal als Mehrwertleistung der Tauchschule.
1.2 Akteurs-Modell (Modell B)¶
Das Akteurs-Modell definiert vier Rollen auf drei Ebenen. Die Tabellenbeschriftung folgt dem Schema Kapitel-Nr. + laufende Tabellennummer.
| Ebene | Rolle | Technisch | Beschreibung |
|---|---|---|---|
| Plattform | Betreiber | superadmin |
Plattform-Administration — verwaltet alle Tenants, System-Logs |
| Tenant | Schulinhaber | tenant_admin |
Verwaltet Mitarbeiter, Kunden, Berichte, DSGVO |
| Tenant | Mitarbeiter | mitarbeiter |
Erfasst Equipment, Workflows, Prüfergebnisse |
| Portal | Taucher | kunde |
Sieht eigene Flaschen/Regler, TÜV-Termine (read-only) |
1.3 Architektur-Prinzipien¶
DiveLogix360 ist nach folgenden Kernprinzipien gebaut, die alle technischen Entscheide leiten:
| Prinzip | Beschreibung |
|---|---|
| Offline-First | Alle Kernfunktionen funktionieren ohne Internetverbindung (Lageräume, Keller). Eine abstrakte SyncEngine synchronisiert Änderungen beim nächsten Online-Gang: Phase 1 via Timestamp-Strategie, Phase 2 via CRDT (Electric SQL, einhängbar ohne Schema-Änderung). |
| Mobile First / PWA | Die App ist als Progressive Web App (PWA) konzipiert — kein App-Store-Install nötig. Touch-optimiert, min. 44×44px Tap-Targets. Nutzung direkt am Equipment und in Lageräumen. |
| Multi-Tenancy via RLS | Row-Level Security (RLS, zeilenbasierte Zugriffskontrolle) in PostgreSQL soll sicherstellen, dass jeder Tenant ausschliesslich seine eigenen Daten sieht. Tenant-übergreifender Zugriff bleibt technisch dem Superadmin vorbehalten. |
| Modularität | Core (Tenant, Kunden, Equipment) + aktivierbare UseCase-Module. Jedes Modul ist einzeln lizenzierbar. Ein neues Modul verändert den Core nie. |
| URL-Sicherheit | Keine sequenziellen IDs in URLs. Alle Ressourcen werden über nicht erratbare UUIDs angesprochen (z.B. /equipment/a3f9b2c1 statt /equipment?id=17). |
| DSGVO by Design | Pseudonymisierung, Aufbewahrungsfristen und Auditierung werden im freigegebenen Zielmodell und in der Implementierung von Anfang an verankert. |
1.4 Use-Case-Landkarte V1–V4¶
Die Landkarte zeigt alle Use Cases der Versionen 1 bis 3 sowie die Optionen der Version 4 nach Zielgruppe. Ein Pfeil bedeutet, dass ein Use Case fachlich auf einem anderen aufbaut; die Linienfarbe kennzeichnet den Ausgangs-Use-Case.
Zum Vergrössern auf die Grafik klicken.
Prozentwerte = Momentaufnahme vom 15.10.2026; führend ist der Projektstatus. Die Grafik wird mit tools/generate_uc_landkarte.py erzeugt.
2. Version 1 — MVP¶
Version 1 liefert die Kernfunktionalität für den Tauchschul-Alltag. Das formal validierte Prisma-v4-Zielschema berücksichtigt erforderliche Erweiterbarkeit für V2 und V3; Migration und Implementierung sind noch nicht abgeschlossen. Das UI bleibt auf den V1-Umfang fokussiert.
2.1 Use Cases Version 1¶
Die folgende Tabelle zeigt alle Use Cases der ersten Version. Die Spalte Zielgruppe beschreibt wer den UC nutzt (Tauchschule, Taucher-Portal, Tauchschule + Taucher oder Plattform-Administration). Die Spalte Reifegrad V1 zeigt ob die Funktionalität vollständig implementiert wird oder in V1 vereinfacht bleibt und erst in V2 vollständig konfigurierbar ist.
| UC | Name | Akteur(e) | Zielgruppe | Reifegrad V1 | Status |
|---|---|---|---|---|---|
| UC00 | Tenant-Onboarding & Schulverwaltung | Superadmin, Tenant-Admin | Plattform-Administration | Vollständig | 🟡 In Bearbeitung |
| UC01 | Equipment erfassen | Mitarbeiter | Tauchschule | Vollständig | ⛹ Offen |
| UC02 | TÜV-Inspektion einreichen (ext.) | Mitarbeiter | Tauchschule | Vollständig | ⛹ Offen |
| UC03 | Füll-Abo & Füllkarten-Verwaltung | Tenant-Admin, Mitarbeiter | Tauchschule | Vollständig | ⛹ Offen |
| UC04 | Inhouse-Service erfassen | Mitarbeiter | Tauchschule | Vollständig | ⛹ Offen |
| UC05 | Fristen-Dashboard | Tenant-Admin, Mitarbeiter | Tauchschule | Vollständig | ⛹ Offen |
| UC06 | Kunden einladen & Portal | Tenant-Admin, Taucher | Taucher-Portal | Vollständig | ⛹ Offen |
| UC07 | Benachrichtigungen (Fristen) | System, Taucher | Tauchschule + Taucher | Vereinfacht | ⛹ Offen |
| UC08 | Benutzerverwaltung | Tenant-Admin | Tauchschule | Vollständig | ⛹ Offen |
| UC09 | Berichte & Export | Tenant-Admin | Tauchschule | Vereinfacht | ⛹ Offen |
| UC-SA | Superadmin-Panel | Superadmin | Plattform-Administration | Vollständig | ⛹ Offen |
2.2 Schema-Tabellen Version 1¶
Die Tabelle beschreibt den vorgesehenen V1-Produktscope des Prisma-v4-Zielschemas. GREEN bezeichnet für V1 benötigte Fachobjekte und ist kein Implementierungs-, Migrations- oder Testnachweis. AMBER kennzeichnet Fachobjekte, deren Oberfläche erst in Version 2 vollständig konfigurierbar wird. OFFEN kennzeichnet V1-Fachobjekte, die im Prisma-v4-Zielschema noch fehlen oder deren Aufnahme noch entschieden werden muss. Die vollständige technische Feldstruktur steht im Prisma-Schema; zusammengehörige UC00-Tabellen sind hier platzsparend gruppiert.
| Tabelle | Version | Status | Beschreibung | Hinweis |
|---|---|---|---|---|
tenants |
V1 | GREEN | Mandanten-Stammdaten, Plan-Typ, Land, Adresse | |
users |
V1 | GREEN | Benutzer (tenant_admin, mitarbeiter, kunde), 2FA | |
tenant_profiles |
V1 | GREEN | Operatives Schulprofil getrennt von rechtlichen Vertragsdaten | |
tenant_onboardings, onboarding_steps |
V1 | GREEN | Persistentes Vier-Schritt-Onboarding mit Draft-Wiederaufnahme | |
tenant_contracts, contract_acceptance_tokens, contract_documents |
V1 | GREEN | Vertragsversionen, Abschlusswege, Token und PDF-Metadaten | PDF-Inhalt liegt im privaten Objektspeicher |
tenant_offboardings, tenant_exports |
V1 | GREEN | Sperrung, Exportphase und operative Löschung | |
legal_holds, retention_runs |
V1 | GREEN | Begründete Aufbewahrungssperren und kontrollierte Löschläufe | |
two_factor_sessions, recovery_codes, refresh_tokens |
V1 | GREEN | Kurzlebige 2FA-Sitzungen, Wiederherstellung und Sitzungsrotation | Geheimnisse nur gehasht beziehungsweise verschlüsselt |
support_access_grants |
V1 | GREEN | Zeitbegrenzte Support- und Notfallzugriffe | Produktiver Einsatz erst nach Nachweisen |
audit_seals |
V1 | GREEN | Tägliche kryptografische Sammelnachweise | Objekt im privaten Objektspeicher |
customers |
V1 | GREEN | Kunden der Tauchschule, DSGVO-Felder | |
equipment |
V1 | GREEN | Alle Gerätetypen (Flasche, Regler, BCD, ...) | |
cylinder_details |
V1 | GREEN | TÜV-Details: EN 1802/EN 1968, DGUV, SVTI | |
regulator_details |
V1 | GREEN | Regler-Service-Details, Intervall | |
usecase_workflows |
V1 | GREEN | TÜV-Workflow, Inspektion, Inhouse-Service | |
workflow_history |
V1 | GREEN | Statusverlauf je Workflow (append-only) | |
invitation_tokens |
V1 | GREEN | Tenant-Admin-, Mitarbeiter- und Kundenportal-Einladungen | |
notification_rules |
V1 | AMBER | Mehrstufige Benachrichtigungsregeln | UI erst in V2 vollständig konfigurierbar |
notification_log |
V1 | GREEN | Verhindert doppelte Benachrichtigungen | |
sync_queue |
V1 | AMBER | Offline-Sync, Konfliktmanagement (Vector Clock) | UI erst in V2 vollständig konfigurierbar |
audit_log |
V1 | GREEN | Vollständiges Änderungsprotokoll (DSGVO) | |
access_log |
V1 | GREEN | Zugriffsprotokoll auf Entitäten | |
auth_log |
V1 | GREEN | Login / 2FA-Ereignisse | |
customer_activity_log |
V1 | GREEN | Kundenportal-Aktivitäten | |
deletion_log |
V1 | GREEN | DSGVO-Löschprotokoll | |
system_log |
V1 | GREEN | Systemereignisse, Fehler, Warnungen | |
fill_subscriptions, fill_cards, fill_card_transactions |
V1 | OFFEN | Füll-Abos, Füllkarten und Buchungen (UC03) | Für UC03 (V1) erforderlich; im Prisma-v4-Zielschema noch nicht enthalten |
equipment_notes, equipment_identifiers |
V1 | OFFEN | Strukturierte Notizen sowie QR-, Barcode- und weitere Kennungen je Equipment (UC01) | Aufnahme offen gemäss UC01-Schema-Prüfung Schritt 8 |
2.3 Bewusste V1-Einschränkungen (UI)¶
notification_rules: Schema ist mehrstufig — UI zeigt nur 1 Standardregel pro Tenant (30 Tage, E-Mail)- Taucher kann Kontaktdaten lesen, aber nicht selbst ändern (Änderungsantrag kommt in V2)
- Kein Multi-Schule-Support für Endkunden (1 Taucher = 1 Schule in V1)
- Kein Multi-Tenant-Support für Benutzerkonten: Eine globale Benutzeridentität gehört in V1 höchstens einem Tenant an (ADR-011)
- Berichte: einfacher PDF-Export, kein konfigurierbarer Reportgenerator
- Benachrichtigungen: nur E-Mail-Kanal, kein Push
- Logo/Branding: noch nicht in V1 — kommt in V2 (ev. als separates Preismodell)
- Eigene Equipment-Typen: in V1 fixer Katalog — Erweiterung in V2
- Sprache: in V1 nur DE — Mehrsprachigkeit in V2
- Tenant-Onboarding: in V1 manuell durch Superadmin — Self-Service in V2
3. Version 2 — Erweiterungen¶
Version 2 öffnet die im V1-Schema bereits vorbereiteten Flexibilitätspunkte für das UI und fügt neue Verkaufsargumente hinzu. Die V1-Einschränkungen werden schrittweise aufgehoben.
3.1 Use Cases Version 2¶
| UC | Name | Akteur(e) | Zielgruppe | Reifegrad |
|---|---|---|---|---|
| UC00+ | Self-Service-Registrierung (Tenant) | Tauchschule (neu) | Plattform-Administration | V2 |
| UC07+ | Konfigurierbares Benachrichtigungssystem | Tenant-Admin | Tauchschule | V2 |
| UC10 | Kontaktdaten-Änderungsantrag (Taucher) | Taucher, Tenant-Admin | Taucher-Portal | V2 |
| UC11 | Erweiterter Bericht & Exportkonfigurator | Tenant-Admin | Tauchschule | V2 |
| UC12 | Push-Benachrichtigungen | System, Taucher | Tauchschule + Taucher | V2 |
| UC13 | Dokument-Upload (Prüfzertifikate) | Mitarbeiter | Tauchschule | V2 |
| UC14 | Taucher bei mehreren Schulen | Taucher | Taucher-Portal | V2 |
| UC15 | Logo & Branding je Tenant | Tenant-Admin | Tauchschule | V2 |
| UC16 | Eigene Equipment-Typen verwalten | Tenant-Admin | Tauchschule | V2 |
| UC17 | Mehrsprachigkeit (FR, EN) | System | Tauchschule + Taucher | V2 |
| UC18 | Equipment-Verleih | Tenant-Admin, Mitarbeiter | Tauchschule | V2 |
| UC19 | Kurs- und Brevetverwaltung | Tenant-Admin, Mitarbeiter | Tauchschule | V2 |
UC18 – Equipment-Verleih¶
UC18 ist als optionales V2-Zusatzmodul vorgesehen und setzt fachlich auf UC01 Equipment erfassen auf. Nur erfasstes, aktives, vollständiges und nicht gesperrtes Equipment darf verliehen werden. Das Modul umfasst Ausgabe, Rückgabe, Verfügbarkeit, Zustand bei Ausgabe und Rückgabe, QR-Code-Nutzung, Historie, überfällige Rückgaben und spätere Berichte.
UC19 – Kurs- und Brevetverwaltung¶
UC19 ist als optionales V2-Zusatzmodul vorgesehen und baut auf UC06 (Kunden als Kursteilnehmer) und UC08 (Personal) auf. Brevets werden nur erfasst, nicht ausgestellt; die Brevetierung erfolgt in den Systemen der Tauchverbände. Verbandsstandards werden nicht nachgebildet: Kursvorlagen, Module und Qualifikationen pflegt jede Tauchschule selbst.
| Stufe | Inhalt | Einordnung |
|---|---|---|
| 1 – Ausbildung | Brevets bei Kunden und Personal; Kursvorlagen mit Modulen (Theorie, Pool, Freiwasser, «extern absolviert»); Kurse mit Teilnehmern; Fortschritt je Modul; Hinweis bei fehlender Voraussetzung | V2 |
| 2 – Durchführung | Kurseinheiten mit Datum, Ort und eingeteiltem Personal; Hinweis bei Doppelbelegung von Person oder Ort; Kalenderexport (iCal) | V2 |
| 3 – Ausbau | Freie Tauchlehrer über Tenant-Mitgliedschaften (Erweiterung ADR-011, analog UC14); Leihausrüstung je Einheit (UC18); Betreuungsschlüssel; Erinnerungen an Teilnehmer (UC07+) | V2, später |
Qualifikationen (z. B. «SSI Instructor», «PADI Divemaster») führt die Tauchschule als eigene Liste. Pro Kursvorlage und Modultyp legt sie fest, welche Qualifikation leiten oder assistieren darf. Eine Einteilung ohne passende Qualifikation erzeugt einen Hinweis, keine Sperre; die Verantwortung für die Einhaltung der Verbandsstandards bleibt bei der Tauchschule. Die Kursausschreibung und -anmeldung bleibt zunächst auf der Website der Schule; Teilnehmer werden manuell erfasst.
3.2 Neue Schema-Objekte V2¶
| Feature / Tabelle | Version | Beschreibung |
|---|---|---|
customer_tenant_map |
V2 | Erlaubt 1 Taucher bei mehreren Schulen (heute: tenant_id auf users) |
user_tenant_memberships |
V2 | Ordnet eine globale Benutzeridentität mehreren Tenants mit tenantbezogener Rolle und tenantbezogenem Status zu (ADR-011) |
documents |
V2 | Prüfzertifikate, Fotos je Equipment oder Workflow |
change_requests |
V2 | 4-Augen-Prinzip: Taucher beantragt Änderung, Tenant-Admin bestätigt |
push_tokens |
V2 | Push-Notification-Tokens je Gerät (iOS, Android) |
registration_requests |
V2 | Self-Service-Onboarding: neue Tauchschulen beantragen Zugang |
organizations |
V2 | Firmen/Vereine als optionale Gruppierung von Kunden (siehe uc-kunden-vorentscheide.md) |
rental_transactions |
V2 | Verleihvorgänge mit Kunde, Ausgabe, geplanter Rückgabe und Status |
rental_items |
V2 | Einzelne verliehene Equipment-Datensätze je Verleihvorgang |
rental_condition_logs |
V2 | Zustand, Foto und Notiz bei Ausgabe und Rückgabe |
3.3 Schema-Entscheide die V2 bereits vorbereiten¶
users.tenant_idbleibt in V1 —customer_tenant_mapkommt in V2 dazu (keine Migration nötig)users.emailbleibt in V1 global eindeutig; eine spätere Mehrfachzugehörigkeit wird überuser_tenant_membershipsstatt über doppelte Benutzerkonten modelliert (ADR-011)notification_rulesist bereits mehrstufig modelliert — V2 öffnet nur das UIequipment.custom_data(JSONB) erlaubt neue Equipment-Typen ohne Schema-Migrationtenants.logo_pathist im Schema vorhanden, wird in V1 nicht befülltcustomers.organization_idwird in V1 nicht angelegt; das Feld und die Tabelleorganizationskommen mit V2 (Entscheid gemäss Roadmap-Synchronisierung vom 08.05.2026)- UC18 nutzt den Equipment-Core aus UC01 und ergänzt Verleih-, Zustands- und Historientabellen, ohne den Equipment-Core zu verändern
- Kompatibilitätsanforderung: Das V1-Datenmodell darf UC18 nicht blockieren; Verleihstatus wird nicht in den Equipment-Stammdaten modelliert (geprüft in der Schema-Detailprüfung UC18, Ergebnis: keine Blockade; Prüfung gegen v4 steht aus)
4. Version 3 — Vision¶
Version 3 realisiert das Modell C (aktiver Taucher) und öffnet die Plattform für tiefere Integrationen mit Prüfstellen und Zahlungsanbietern.
| UC | Name | Akteur(e) | Zielgruppe | Reifegrad |
|---|---|---|---|---|
| UC-C1 | Taucher reicht Inspektion selbst ein | Taucher | Taucher-Portal | V3 |
| UC-C2 | Taucher lädt Dokumente hoch | Taucher | Taucher-Portal | V3 |
| UC-C3 | Direktzahlung / Rechnungsstellung | Taucher, Tenant-Admin | Tauchschule + Taucher | V3 |
| UC-C4 | API für Prüfstellen-Integration (SVTI) | Extern | Plattform-Administration | V3 |
| UC-C5 | White-Label / eigene Domain je Schule | Tenant-Admin | Tauchschule | V3 |
5. Version 4 — Optionen¶
Version 4 sammelt mögliche Erweiterungen, die fachlich erkannt, aber weder priorisiert noch einer Version zugeordnet sind. Ein Eintrag hier ist keine Zusage; vor einer Übernahme in eine Version sind Nutzen, Aufwand und Abhängigkeiten zu prüfen.
| Option | Beschreibung | Abhängigkeiten / Hinweise |
|---|---|---|
| Import per Annahme-API | Fremdsysteme (Kasse, CRM) liefern Kundendaten aktiv an DiveLogix360 | Alternativ V3; setzt CSV-Import voraus |
| Import durch Abholen | DiveLogix360 holt Daten über die API eines Fremdsystems ab | Alternativ V3; Anbindung je Produkt |
| Kursanmeldungen von der Website übernehmen | Anmeldungen aus der Schul-Website (z. B. Joomla-Plugin) importieren | Setzt UC19 voraus |
| Brevetbasierte Werbeaktionen | Zielgerichtete Angebote anhand erfasster Brevets | Setzt UC19 voraus; Rechtsgrundlage (Einwilligung) juristisch prüfen |
| Eigene öffentliche Kursseite | Kursangebot und Anmeldung direkt aus DiveLogix360, eingebettet oder unter eigener Domain | Setzt UC19, UC15 und ggf. UC-C5 voraus |
| Verbands-Schnittstellen | Kurs- oder Brevetdaten von Tauchverbänden übernehmen | Zurückgestellt; Verfügbarkeit von APIs wird geprüft |
6. Offene Entscheide & Designprinzipien¶
6.1 Geklärt¶
- Tauchschule als externer Kunde: wird als normaler Kundendatensatz erfasst — kein Sonderfall im Schema
- Taucher-Registrierung V1: Einladung per E-Mail-Token durch die Schule (nicht Self-Registration)
- Kontaktdaten V1: read-only für Taucher — Schule pflegt Daten; Änderungsantrag kommt in V2
- Benachrichtigungszeitraum: flexibel und mehrstufig konfigurierbar pro Equipment-Typ
- Externe TÜV-Inspektion: Tauchschule reicht ein, externe Prüfstelle führt Prüfung durch
- Füll-Abo & Füllkarten-Verwaltung: V1-Use-Case für Abo pro Kunde, gasmix-abhängige Verbrauchserfassung und tenant-konfigurierbare Preise
- Inhouse-Service: Regler und Jacket werden von der Schule selbst gewartet und erfasst
- Prüfintervalle: Tenant-Admin kann eigene Intervalle je Equipment-Typ festlegen (V1)
- Standard-Währung: Tenant-Admin setzt CHF oder EUR pro Tenant (V1)
- Tenant-Onboarding V1: manuell durch Superadmin — Self-Service in V2
- Billing: komplett ausserhalb der App (Stripe oder manuelle Rechnung) — MwSt-Nr. im Schulprofil
- Mitarbeiter-Einladungsmodell: via Einladungslink (analog UC00 Modell C1) — Details in UC-Mitarbeiter
- Kunden V1: Kunde = Person (Szenario A) — Organisations-Zuordnung optional in V2 (Szenario C)
- Equipment-Verleih: wird als UC18 in V2 aufgenommen und als eigenes optionales Modul auf Basis von UC01 umgesetzt
6.2 Noch offen¶
- Preismodell: Starter / Professional / Enterprise — genaue Feature-Grenzen definieren
- Offline-Modus: welche Aktionen sind ohne Internet möglich? (
sync_queueist vorbereitet) - Sprachen: DE + CH-DE zum Start — wann kommt FR/EN?
- UC18: genauer V2-Umfang für Preislogik, Kaution, Unterschrift, Etikettendruck und Verleihberichte
6.3 Designprinzipien¶
- Schema-forward, UI-minimal: das DB-Design denkt 3 Versionen voraus, das UI liefert V1 fokussiert
- Keine Breaking Changes: neue Features erweitern das Schema (neue Tabellen/Spalten), nie umbauend
- DSGVO by Design: Pseudonymisierung, Löschfristen und Audit sind von Anfang an eingebaut
- Normenkonformität: EN 1802, EN 1968, DGUV, SVTI sind im Schema direkt referenzierbar
- Versionen als Verkaufsargument: Kunden kaufen V1, wissen dass V2 kommt — reduziert Churn
- Keine Gendersprache: klassische deutsche Rechtschreibung in der gesamten Applikation
7. Meilensteine und Prioritäten¶
Die Roadmap führt strategische Meilensteine und ihre Reihenfolge. Operative Aufgaben, Teilnachweise und tagesaktuelle Bearbeitungsstände stehen ausschliesslich im Projektstatus.
| Meilenstein | Ziel | Priorität | Einordnung |
|---|---|---|---|
| M1 – UC00-Grundlage vervollständigen | Tenant-Onboarding fachlich, technisch und sicherheitlich als tragfähige V1-Basis abschliessen | Hoch | In Bearbeitung |
| M2 – UC00 abnehmen | Frontend, Integrations- und Sicherheitstests, Infrastruktur sowie externe und formelle Freigaben nachweisen | Hoch | Offen |
| M3 – V1-Kernprozesse implementieren | Equipment, Prüfungen, Füll-Abos, Inhouse-Service und Fristen auf der freigegebenen Plattformbasis umsetzen | Hoch | Offen |
| M4 – V1-Portal und Administration implementieren | Kundenportal, Benachrichtigungen, Benutzerverwaltung, Berichte und Superadmin-Funktionen umsetzen | Hoch | Offen |
| M5 – V1 produktionsbereit machen | Gesamtintegration, Datenschutz, Betrieb, Monitoring, Wiederherstellung, Abnahme und Go-live-Vorbereitung abschliessen | Hoch | Offen |
| M6 – V2 vorbereiten | Erweiterungsfelder einschliesslich Equipment-Verleih nach V1-Prioritäten und Geschäftsmodell planen | Mittel | Backlog |
| M7 – Produkt- und Preismodell schärfen | Grenzen und Leistungen für Starter, Professional und Enterprise verbindlich definieren | Mittel | Backlog |
Ein Meilensteinstatus ist eine strategische Einordnung und ersetzt keinen technischen Fertigstellungs- oder Testnachweis. Die Detailkriterien werden im Projektstatus und in den Use-Case-Abschlusschecklisten geführt.
8. Rechtsgrundlagen & Datenschutz-Compliance¶
DiveLogix360 verarbeitet Personendaten von Tauchern und Mitarbeitenden der Tauchschulen. Damit unterliegt die Plattform einem komplexen Rechtsrahmen aus Schweizer und EU-Datenschutzrecht sowie branchenspezifischen Normen. Dieses Kapitel dokumentiert die relevanten Rechtsgrundlagen und leitet daraus konkrete Anforderungen für das Produkt ab.
8.1 Schweizer Datenschutzrecht (nDSG / DSV / VDSZ)¶
Das neue Schweizer Bundesgesetz über den Datenschutz (nDSG), die Datenschutzverordnung (DSV) sowie die Verordnung über Datenschutzzertifizierungen (VDSZ) sind am 1. September 2023 in Kraft getreten. Mit der Totalrevision wird das Datenschutzrecht den veränderten technologischen und gesellschaftlichen Verhältnissen angepasst. Es wurden keine gesetzlichen Übergangsfristen vorgesehen — alle Pflichten gelten sofort.
Das nDSG annähert die Schweizer Datenschutzgesetzgebung an die EU-Datenschutzgrundverordnung (EU-DSGVO 2016/679), ist aber kein 1:1-Abbild. Der pragmatischere Schweizer Ansatz bleibt erhalten: Datenbearbeitung ist grundsätzlich erlaubt, sofern die Grundprinzipien eingehalten werden (Art. 6 nDSG) — anders als in der EU, wo ein expliziter Erlaubnisgrund benötigt wird.
8.2 Kernpflichten für DiveLogix360¶
Als SaaS-Betreiber ist DiveLogix360 sowohl Verantwortlicher (für eigene Daten) als auch Auftragsbearbeiter (für Daten der Tauchschulen). Daraus ergeben sich folgende Pflichten:
| Pflicht | Rechtsgrundlage | Umsetzung in DiveLogix360 |
|---|---|---|
| Bearbeitungsverzeichnis führen | Art. 12 nDSG i.V.m. Art. 4–6 DSV | audit_log + deletion_log dokumentieren alle Datenbearbeitungen |
| Privacy by Design & Default | Art. 7 nDSG | DSGVO-Felder, Pseudonymisierung und Löschfristen sind von Anfang an im Schema eingebaut |
| Informationspflicht (Datenschutzerklärung) | Art. 19 nDSG, Art. 13 DSV | Datenschutzerklärung auf divelogix360.ch; je Tenant bei Kundenerfassung |
| Datensicherheit (TOM) | Art. 8 nDSG, Art. 1–3 DSV | RLS, 2FA, Audit-Log, verschlüsselte Übertragung (TLS), Supabase EU-Hosting |
| Meldepflicht bei Datenschutzverletzung | Art. 24 nDSG | system_log + Eskalationsprozess an EDÖB bei hohem Risiko |
| Betroffenenrechte (Auskunft, Löschung) | Art. 25–27 nDSG | deletion_log, customer.pseudonymized, gdpr_consent-Felder |
| Auftragsverarbeitungsvertrag beziehungsweise Auftragsbearbeitungsvereinbarung | Art. 9 nDSG / Art. 28 DSGVO | Abschluss mit jeder Tauchschule vor Tenant-Admin-Einladung; elektronisch oder als kontrolliert hochgeladenes, extern unterzeichnetes Dokument (ADR-015) |
| Bekanntgabe ins Ausland | Art. 16–17 nDSG | Supabase EU-Region (Frankfurt/Dublin) — keine Drittstaatenübermittlung |
8.3 Verhältnis nDSG – EU-DSGVO – BDSG¶
Da DiveLogix360 den DACH-Markt (DE, CH, AT) bedient, gilt ein dreifacher Rechtsrahmen je nach Standort des Tenants:
| Markt | Anwendbares Recht | Besonderheiten für DiveLogix360 |
|---|---|---|
| CH (Schweiz) | nDSG / DSV / VDSZ | Erlaubnis mit Verbotsvorbehalt; pragmatischer; AVV Pflicht; EDÖB als Aufsicht |
| DE (Deutschland) | EU-DSGVO + BDSG | Verbot mit Erlaubnisvorbehalt; strenger; Einwilligung oder Vertrag nötig; BfDI/LfDI |
| AT (Österreich) | EU-DSGVO + DSG AT | Wie DE; Datenschutzbehörde (Österreich) als Aufsicht |
Hinweis: Da die Schweiz von der EU als Drittstaat mit angemessenem Datenschutzniveau anerkannt ist (Angemessenheitsbeschluss), ist die grenzüberschreitende Datenübermittlung CH ↔ EU ohne zusätzliche Garantien zulässig. Diese Anerkennung basiert u.a. auf der Ratifizierung des modernisierten Datenschutzübereinkommens SEV 108+ des Europarats (2023).
8.4 Branchenspezifische Normen¶
Zusätzlich zum Datenschutzrecht unterliegt DiveLogix360 technischen Normen für die TÜV-Inspektion von Druckgeräten:
| Norm | Relevanz für DiveLogix360 |
|---|---|
| EN 1802:2002 | Wiederkehrende Inspektion nahtloser Druckluftflaschen aus Aluminium — Prüffristen und Dokumentationspflichten |
| EN 1968:2002 | Wiederkehrende Inspektion nahtloser Druckluftflaschen aus Stahl — Prüffristen und Dokumentationspflichten |
| DGUV (DE) | Deutsche Unfall-verhütungsvorschriften für Druckgeräte im Tauchbereich — gilt für DE-Tenants |
| SVTI (CH) | Schweizerischer Verein für technische Inspektionen — zugelassene Prüfstelle in der Schweiz |
8.5 Datenschutz-Roadmap¶
Folgende datenschutzrechtliche Massnahmen sind als Teil der Produktentwicklung umzusetzen:
| # | Massnahme | Version | Rechtsgrundlage |
|---|---|---|---|
| 1 | Datenschutzerklärung für divelogix360.ch erstellen | V1 | Art. 19 nDSG / Art. 13 DSGVO |
| 2 | Auftragsverarbeitungsvertrag je Tenant vor Tenant-Admin-Einladung; elektronischer oder externer Abschlussweg | V1 | Art. 9 nDSG / Art. 28 DSGVO; ADR-015 |
| 3 | Bearbeitungsverzeichnis aufsetzen (intern für DiveLogix360) | V1 | Art. 12 nDSG / Art. 30 DSGVO |
| 4 | RLS + 2FA + TLS — technische Schutzmassnahmen (TOM) | V1 | Art. 8 nDSG / Art. 25 DSGVO |
| 5 | GDPR-Consent-Flow für Kundenerfassung durch Tauchschule | V1 | Art. 19 nDSG |
| 6 | Schwellenprüfung für eine Datenschutz-Folgenabschätzung je Use Case; vollständige DSFA vor Hochrisiko-Bearbeitungen | V1 fortlaufend | Art. 22 DSG / Art. 35 DSGVO |
| 7 | ISO 27001-Zertifizierung anstreben (ab Enterprise-Tier) | V3 | VDSZ / Art. 7 nDSG |
9. Quellenverzeichnis¶
Die nachfolgenden Quellen bilden die Grundlage für die in diesem Dokument enthaltenen Aussagen zu Rechtsgrundlagen, technischen Normen und strategischen Entscheiden.
9.1 Schweizer Datenschutzrecht¶
| Nr. | Titel | Quelle |
|---|---|---|
| [1] | nDSG — Bundesgesetz über den Datenschutz (revidiert) | fedlex.admin.ch/eli/cc/2022/491/de — in Kraft seit 1. September 2023 |
| [2] | DSV — Datenschutzverordnung | fedlex.admin.ch/eli/cc/2022/568/de — Ausführungsbestimmungen zum nDSG |
| [3] | VDSZ — Verordnung über Datenschutzzertifizierungen | fedlex.admin.ch — Zertifizierungsrahmen für Datenbearbeitungen |
| [4] | Neues Datenschutzgesetz DSG (Strategie Digitale Schweiz) | digital.swiss/de/aktionsplan/massnahme/neues-datenschutzgesetz-ndsg |
| [5] | KMU-Portal Bund: Neues Datenschutzgesetz (revDSG) | kmu.admin.ch — Bundesamt für Justiz, Bern |
| [6] | Übersicht zum neuen Datenschutzgesetz | economiesuisse.ch/de/artikel/datenschutz-eine-uebersicht-zum-neuen-gesetz |
9.2 EU-Datenschutzrecht¶
| Nr. | Titel | Quelle |
|---|---|---|
| [7] | EU-DSGVO 2016/679 — Datenschutz-Grundverordnung | eur-lex.europa.eu — in Kraft seit 25. Mai 2018 |
| [8] | BDSG — Bundesdatenschutzgesetz (Deutschland) | gesetze-im-internet.de/bdsg_2018 — gilt für DE-Tenants |
| [9] | DSG AT — Datenschutzgesetz Österreich | ris.bka.gv.at — gilt für AT-Tenants |
9.3 Technische Normen (TÜV / Druckgeräte)¶
| Nr. | Titel | Quelle |
|---|---|---|
| [10] | EN 1802:2002 — Nahtlose Aluminiumflaschen, wiederkehrende Inspektion | CEN / Beuth Verlag — Norm für Druckluftflaschen Aluminium |
| [11] | EN 1968:2002 — Nahtlose Stahlflaschen, wiederkehrende Inspektion | CEN / Beuth Verlag — Norm für Druckluftflaschen Stahl |
| [12] | DGUV — Deutsche Gesetzliche Unfallversicherung | dguv.de — Vorschriften für Druckgeräte im Tauchbereich |
| [13] | SVTI — Schweizerischer Verein für technische Inspektionen | svti.ch — Zugelassene Prüfstelle CH für Druckbehälter |
9.4 Technische Grundlagen¶
| Nr. | Titel | Quelle |
|---|---|---|
| [14] | Supabase — PostgreSQL-Datenbankplattform | supabase.com |
| [15] | PostgreSQL Row Level Security (RLS) | postgresql.org/docs/current/ddl-rowsecurity.html |
| [16] | NestJS — Node.js Backend Framework | nestjs.com |
| [17] | Prisma — ORM für PostgreSQL / TypeScript | prisma.io |
| [18] | React — Frontend-Framework | react.dev |
Änderungshistorie¶
| Datum, Uhrzeit | Version | Änderung | Autor |
|---|---|---|---|
| 16.10.2026 11:11 | 3.0 | UC19 «Kurs- und Brevetverwaltung» als V2-Zusatzmodul mit drei Stufen aufgenommen (Tabelle 3.1 und Unterabschnitt); Use-Case-Landkarte um UC19 und «baut auf»-Pfeile (UC06, UC08 → UC19; UC19, UC15 → V4-Optionen) ergänzt | Claude |
| 16.10.2026 10:58 | 2.9 | Neuer Abschnitt 5 «Version 4 — Optionen» als Sammelstelle für nicht priorisierte Erweiterungen; bisherige Kapitel 5–8 zu 6–9 umnummeriert (Überschriften, Anker, Inhaltsverzeichnis); Use-Case-Landkarte in 1.4 um Spalte «Version 4 – Optionen» (ohne Pfeile) erweitert und Grafik in uc-landkarte-v1-v4.svg umbenannt |
Claude |
| 15.10.2026 19:02 | 2.8 | Abschnitt 1.4 «Use-Case-Landkarte V1–V3» mit anklickbarer Grafik (Version × Zielgruppe, «baut auf»-Beziehungen, Prozentwerte als Momentaufnahme) ergänzt | Claude |
| 15.10.2026 16:29 | 2.7 | V1-Tabellenliste um Status OFFEN und fünf noch fehlende V1-Tabellen (UC03, UC01) ergänzt; Aussage zu customers.organization_id korrigiert (nicht in V1); UC18 als V2-Kompatibilitätsanforderung markiert (Entscheid David Mittig vom 15.10.2026) |
Claude |
| 12.10.2026 11:01 | 2.6 | Versionsnummern der Änderungshistorie chronologisch durchgehend nummeriert (4 Einträge angepasst; Datum, Änderung und Autor unverändert) | Claude |
| 12.10.2026 10:19 | 2.5 | Datum und Uhrzeit von 7 älteren Historieneinträgen aus der Git-Historie ergänzt (Zeitpunkt des Commits, der den Eintrag eingeführt hat) | Claude |
| 12.10.2026 09:58 | 2.4 | Änderungshistorie ans Dokumentende verschoben und Sprunglink «Änderungshistorie anzeigen» unter dem Kopf ergänzt (einheitlicher Dokumentaufbau gemäss AGENTS.md) | Claude |
| 12.10.2026 09:08 | 2.3 | Explizite Sprungmarken für die Kapitel 1 bis 7 ergänzt, damit Inhaltsverzeichnis und externe Verweise auch in MkDocs funktionieren | Claude |
| 12.08.2026 16:55 | 2.2 | Operative Aufgabenliste durch strategische Meilensteine und Prioritäten ersetzt | Codex |
| 09.08.2026 14:41 | 2.1 | Prisma-v4-Zielschema und ergänzende UC00-Modellgruppen in V1-Scope und nächste Schritte übernommen | Codex |
| 09.08.2026 13:43 | 2.0 | Schemaangaben als Produktscope statt Fertigmeldung präzisiert und nächste UC00-Schritte auf Zielmodellkonsolidierung ausgerichtet | Codex |
| 08.08.2026 14:43 | 1.10 | DSFA-Schwellenprüfung je Use Case ab V1 und vollständige Folgenabschätzung bei erreichtem Hochrisiko-Schwellenwert festgelegt | Codex |
| 06.08.2026 19:08 | 1.9 | ADR-015 übernommen: Auftragsverarbeitungsvertrag vor Tenant-Admin-Einladung; elektronischer Abschluss und Upload externer Vereinbarungen vorgesehen | Codex |
| 06.08.2026 18:42 | 1.8 | ADR-011 als V1-Einschränkung und user_tenant_memberships als V2-Zielmodell ergänzt |
Codex |
| 01.08.2026 14:55 | 1.7 | Kopfbereich vereinheitlicht | David Mittig |
| 01.08.2026 12:59 | 1.6 | UC00 Schritt 4 Backend-Business-Logik implementiert und in main gepusht; NestJS-Backend-Grundstruktur auf Erledigt gesetzt; UC00 Schritt 4–7 auf In Bearbeitung gesetzt; Stand und Version aktualisiert |
David Mittig |
| 06.05.2026 08:07 | 1.5 | Kapitel 2.2 als echte Markdown-Tabelle korrigiert; Status- und Hinweis-Spalten ergänzt | David Mittig |
| 04.05.2026 15:58 | 1.4 | UC18 Equipment-Verleih als V2-Erweiterung ergänzt; Verleih-Schemaobjekte vorbereitet; Bezug zu UC01 Equipment-Core dokumentiert | David Mittig |
| 04.05.2026 10:57 | 1.3 | Füll-Abo & Füllkarten-Verwaltung als UC03 in Version 1 aufgenommen; nachfolgende UC in Version 1 und Version 2 neu nummeriert; UC06+ auf UC07+ angepasst | David Mittig |
| 23.04.2026 01:23 | 1.2 | Fehlende Einleitungstexte in 1.2, 1.3, 2.1, 2.2, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0 ergänzt; Hinweis-Satz 7.3 vervollständigt (SEV 108+); Quellenangaben 8.1–8.3 mit vollständigen Hinweistexten ergänzt | David Mittig |
| 23.04.2026 01:23 | 1.1 | Konvertierung zu Markdown; UC00 Status aktualisiert; Nächste Schritte aktualisiert; Kunden-Vorentscheide + Mitarbeiter-Einladungsmodell in 5.1 ergänzt; organizations in 3.2 ergänzt; V2-Vorbereitung customers.organization_id in 3.3 ergänzt; Designprinzip keine Gendersprache ergänzt |
David Mittig |
| 23.04.2026 01:23 | 1.0 | Initiale Version (aus DiveLogix360_Roadmap.docx konvertiert) | David Mittig |