# OMSORG Business Controls Pro — Requirements-Dokument (SRS)

Status: Entwurf 1.0
Basis: `omsorg.md` (Kurzvision) + `omsorgapp/docs/OMSORG-BLUEPRINT.md` (Vision/Architektur, verbindliche Arbeitsgrundlage)
Zweck: Aus der Vision konkrete, testbare Anforderungen ableiten — Grundlage für Entwicklung, Abnahme und Tests.

Dieses Dokument dupliziert den Blueprint nicht. Es referenziert ihn (`[Blueprint Kap. X]`) und übersetzt ihn in nummerierte Requirements mit Akzeptanzkriterium und Ist-Status.

Status-Legende: ✅ vorhanden · 🔶 teilweise vorhanden · ⬜ offen

---

## 1. Einleitung

### 1.1 Zweck
Dieses Dokument definiert die funktionalen und nicht-funktionalen Anforderungen an OMSORG Business Controls Pro — die Plattform, mit der Omsorg (Pflege-Zeitarbeit) ihren gesamten Arbeitsalltag abwickelt.

### 1.2 Geltungsbereich
Umfasst alle drei Plattform-Ebenen: OMSORG Desktop, OMSORG Connect, OMSORG Backend (Core + Engine) [Blueprint Kap. 4].

> **Architektur-Entscheidung:** Der Blueprint beschreibt Core und Engine als zwei separate Ebenen (Kap. 19/20). In diesem Requirements-Dokument werden sie als **eine Backend-Komponente** mit zwei internen Schichten geführt: Datenschicht (Core) und Event-Schicht (Engine), betrieben im selben Prozess/Service. Grund: Die Engine liest und schreibt permanent auf denselben Core-Objekten; eine Trennung in zwei Deployables würde nur Netzwerk-Roundtrips und Konsistenzrisiken erzeugen, ohne dass ein reales Skalierungsproblem das rechtfertigt. Die inhaltliche Beschreibung aus dem Blueprint bleibt unverändert — nur die Einordnung als eine statt zwei Plattform-Ebenen ändert sich.

### 1.3 Begriffe
| Begriff | Bedeutung |
|---|---|
| Mitarbeiter | Person im Personalbestand (Büro oder Außendienst) |
| Einrichtung | Kunde (Pflegeeinrichtung), CRM-Objekt |
| Vertrag | Verbindliche Vereinbarung (Arbeitsvertrag, Rahmenvertrag, Einsatzvertrag, ...) |
| Auftrag | Personalbedarf einer Einrichtung |
| Einsatz | Konkrete Zuweisung eines Mitarbeiters zu einem Auftrag/Zeitraum |
| Zeiterfassung | Dokumentierte, tatsächlich geleistete Arbeitszeit |
| Tätigkeitsnachweis | Nachweis-Dokument zu geleisteter Zeit (ggf. mit Unterschrift) |
| Rechnung | Aus freigegebener Zeiterfassung + Konditionen erzeugtes Abrechnungsdokument |
| Engine | Event-Schicht des OMSORG Backends: ereignisgesteuerte Automatisierung ohne eigene UI, im selben Prozess wie die Datenschicht (Core) [Blueprint Kap. 20] |

---

## 2. Systemüberblick & Ist-Stand

| Ebene | Beschreibung | Ist-Stand im Repo |
|---|---|---|
| **OMSORG Desktop** | Vollständige Unternehmensmodule für Büromitarbeiter | 🔶 `omsorgapp/` — Electron/React, Release 0.1.1. Vorhanden: `HomePage`, `HomeStats`, `ContractWidget`, `EmployeesPage` mit Tabs/Detailpanel. Lokale JSON-DB (`~/Documents/Omsorg Business Controls Pro/database/omsorg-local-db.json`), noch keine SQLite/Server-Anbindung. |
| **OMSORG Connect** | Mobile/Web-App für Außendienst | ✅ `omsorgWeb/mitarbeiter-app/` — PHP/MySQL, produktiv als PWA (Manifest + Service Worker). Deckt bereits Zeiterfassung/Stundennachweis, Urlaub, Abwesenheit, Fortbildung, Dokumente, News, Benefits, Werben, Einsatzanweisung, Dienstplan, Bewertungen ab. |
| **OMSORG Backend (Core + Engine)** | Eine Backend-Komponente, zwei interne Schichten: **Datenschicht (Core)** — gemeinsame Datenbasis, 6 Objekte; **Event-Schicht (Engine)** — Ereignis→Aktion-Automatisierung ohne eigene UI, arbeitet auf denselben Objekten der Datenschicht | 🔶 `omsorgCore/` — Grundgerüst steht (C#/.NET 8, ASP.NET Core Controller, EF Core/PostgreSQL, JWT-Auth, Rollen+Permission-Override-Rechtesystem, In-Process-Event-Dispatcher). Bisher nur `Employee` mit vollem Repository/Service/Controller; die anderen 5 Core-Objekte existieren als Domain-Entitäten, aber ohne Endpunkte. `omsorgapp` ist für Mitarbeiter jetzt **echt angebunden** (Login/Refresh sowie Employees-CRUD laufen über `omsorgCore`, keine lokale JSON-Datenhaltung mehr für dieses Modul). **Noch keine Anbindung** von `omsorgWeb` (MySQL) an dieses Backend, und die übrigen `omsorgapp`-Fachmodule (Kunden, Disposition, ...) nutzen weiterhin die lokale JSON-DB — die Insellösungen bestehen dort technisch weiter, bis diese Migration erfolgt. DB-Migration wurde noch nicht gegen eine echte PostgreSQL-Instanz verifiziert. Details: `omsorgCore/CLAUDE.md`. |

**Kernrisiko für die Roadmap:** Solange das Backend (Core + Engine) nicht existiert, sind Connect (MySQL) und Desktop (JSON) zwei Insellösungen — genau das, was Blueprint Kap. 19.9 ausschließt. Phase 1 der Roadmap muss dies zuerst auflösen (siehe Abschnitt 10).

---

## 3. Akteure & Rollen

| Rolle | Personen | Zugriffsniveau [Blueprint Kap. 6] |
|---|---|---|
| Geschäftsführung | Sabina, Malik | Vollzugriff: alle Module, Finanzdaten, Gewinn, Margen, Benutzerverwaltung |
| Disposition/Buchhaltung | Sabrina | Mitarbeiter, Einrichtungen, Aufträge/Einsätze, Zeiterfassung, Rechnungen, Zahlungen, Recruiting/CRM — **kein** vollständiger Gewinn/Gesamtmargen |
| Recruiting | Sascha | Recruiting, Bewerber, Mitarbeiterakten (soweit nötig), Einrichtungs-Leads, Akquise, Marketing — **kein** Zugriff auf Rechnungen, Zahlungen, Gewinn, Margen, Controlling |
| Außendienst | alle Pflegekräfte | Nur OMSORG Connect, nur eigene Daten |
| Zukünftige Büromitarbeiter | — | Rolle als Vorlage + individuell vergebene/entzogene Rechte (sehen/anlegen/bearbeiten/löschen/exportieren/freigeben je Modul) |

---

## 4. Funktionale Anforderungen (FR)

### 4.1 Dashboard / Morning Briefing / Tagesabschluss

| ID | Anforderung | Akteur | Akzeptanzkriterium | Status |
|---|---|---|---|---|
| FR-DASH-1 | Beim Öffnen zeigt das Dashboard neue Outlook-Mails, Krankmeldungen, fehlende Tätigkeitsnachweise, Vertragsverlängerungen, offene Rechnungen, Kaltaquise-Termine, neue Mitarbeiter, Auslastung [Blueprint 2.1] | alle Büro-Rollen | Jede Kategorie ist als eigene Kachel/Liste sichtbar und führt per Klick zur passenden Aktion | 🔶 (`HomePage`/`HomeStats`/`ContractWidget` in `omsorgapp` zeigen einen Teil; Outlook, Krankmeldungen, Kaltaquise fehlen) |
| FR-DASH-2 | Gewinn-Kachel ist ausschließlich für Sabina/Malik sichtbar [Blueprint 6.1] | Geschäftsführung | Anderer Rolle wird die Kachel serverseitig nicht ausgeliefert, nicht nur UI-verborgen | ⬜ |
| FR-DASH-3 | Tagesabschluss-Ansicht zeigt „Heute erledigt" vs. „Noch offen" [Blueprint 2.3] | alle Büro-Rollen | Am Ende des Tages ist eine konsolidierte Liste abrufbar | ⬜ |
| FR-DASH-4 | Jede Dashboard-Information führt direkt zur zugehörigen Aktion (z. B. Vertrag öffnen, Mitarbeiter zurückrufen) | alle Büro-Rollen | Klick navigiert ins jeweilige Modul mit vorausgewähltem Datensatz | ⬜ |

### 4.2 Mitarbeiter (Personalakte)

| ID | Anforderung | Akteur | Akzeptanzkriterium | Status |
|---|---|---|---|---|
| FR-MA-1 | Stammdaten erfassen (Name, Geburtsdatum, Adresse, Kontakt, Notfallkontakt, Beschäftigungsart, Qualifikation, Ein-/Austritt, Status) [Blueprint 19.1] | Sabina, Malik, Sabrina | Datensatz anlegen/bearbeiten mit Pflichtfeldern; Validierung verhindert unvollständige Sätze | ✅ (alle Felder in `Employee`-Entity + `EmployeeForm` in `omsorgapp` vorhanden; Validierung serverseitig in `EmployeesController` (Pflichtfelder, Längen, Ein-/Austrittslogik, Beschäftigungsart-Allowlist) und clientseitig verdrahtet; `omsorgapp` spricht für Mitarbeiter jetzt über `employeesClient.cjs` echt gegen `omsorgCore`, keine JSON-lokale Persistenz mehr für dieses Modul — Abgleich mit Connect/`omsorgWeb` weiterhin offen, siehe FR-CORE-1) |
| FR-MA-2 | Arbeitsvertragsdaten (Beginn/Ende, Arbeitszeit, Stundenlohn, Zuschläge, Überstunden, Urlaubsanspruch, Probezeit) [Blueprint 19.1] | Sabina, Malik, Sabrina | Vertragsfelder je Mitarbeiter editierbar, Historie bei Änderung nachvollziehbar | ⬜ |
| FR-MA-3 | Dokumente, Qualifikationen, Fortbildungen, Führerschein, Gesundheitsnachweise, Notizen, Historie je Mitarbeiter | Sabina, Malik, Sabrina | Upload/Anzeige je Kategorie, Zugriffsprotokoll | 🔶 (Dokumentenarchiv existiert bereits in Connect: `pages/dokumentenarchiv.php`, `actions/upload-dokument.php`; im Desktop-Modul fehlt es) |
| FR-MA-4 | Eintrittsdatum löst Dashboard-Hinweis auf bevorstehenden Mitarbeiterstart aus [Blueprint 7] | alle Büro-Rollen | X Tage vor Eintritt erscheint Engine-Hinweis im Dashboard | ⬜ (abhängig von Engine, siehe 4.10) |
| FR-MA-5 | Bei Büromitarbeitern kann der Mitarbeiterdatensatz mit einem Benutzerkonto + individuellen Rechten verknüpft werden [Blueprint 19.1] | Sabina, Malik | Rechteliste pro Modul (sehen/anlegen/bearbeiten/löschen/exportieren/freigeben) editierbar | 🔶 (`users`-Tabelle mit Rolle in `omsorgWeb/mitarbeiter-app` vorhanden, aber nur grobe Rolle, keine granularen Einzelrechte) |
| FR-MA-6 | Außendienstmitarbeiter sehen ausschließlich eigene Daten [Blueprint 4.2] | Außendienst | Query/Route liefert nur Datensätze mit `user_id = aktueller Nutzer` | ✅ (Session-basierter Zugriff in `omsorgWeb/mitarbeiter-app`, z. B. `pages/urlaubsantrag.php`) |

### 4.3 Einrichtungen & CRM

| ID | Anforderung | Akteur | Akzeptanzkriterium | Status |
|---|---|---|---|---|
| FR-EIN-1 | Stammdaten (Name, Art, Adresse, Rechnungsadresse, Telefon, E-Mail, Website, Status) [Blueprint 19.2] | Sabina, Malik, Sabrina, Sascha (Leads) | Datensatz anlegen/bearbeiten | ⬜ |
| FR-EIN-2 | Mehrere Ansprechpartner je Einrichtung mit Funktion, Abteilung, Kontaktwegen, Notizen | Sabina, Malik, Sabrina, Sascha | Liste von Ansprechpartnern editierbar, mind. 1:n-Beziehung | ⬜ |
| FR-EIN-3 | CRM-Status-Pipeline: Lead → kontaktiert → kein Bedarf → Wiedervorlage → Interesse → Angebot → Kunde → Bestandskunde [Blueprint, omsorg.md] | Sascha, Sabrina | Statuswechsel wird protokolliert; bei „kein Bedarf" wird automatisch Wiedervorlage in 14 Tagen erzeugt | ⬜ |
| FR-EIN-4 | Konditionen (Verrechnungssatz, Zuschläge, Fahrtkosten, Mindeststunden, Zahlungsziel etc.) je Einrichtung [Blueprint 19.2] | Sabina, Malik, Sabrina | Konditionssatz ist Grundlage für Rechnungserstellung (siehe FR-RE-1) | ⬜ |
| FR-EIN-5 | Verknüpfte Historie: Verträge, Aufträge, zugewiesene Mitarbeiter, Nachweise, Rechnungen, Zahlungen, Mahnungen, Kommunikation | alle Büro-Rollen (rechteabhängig) | Einrichtungsakte zeigt konsolidierte Historie ohne Datenduplizierung | ⬜ |

### 4.4 Einsatzmanagement (Auftrag → Einsatz → Zuweisung)

| ID | Anforderung | Akteur | Akzeptanzkriterium | Status |
|---|---|---|---|---|
| FR-EM-1 | Auftrag erfassen (Einrichtung, Ansprechpartner, Qualifikation, Zeitraum, Schichtart, Anzahl Mitarbeiter, Konditionen, Priorität) [Blueprint 19.4] | Sabrina | Auftragsdatensatz mit Pflichtfeldern anlegbar | ⬜ |
| FR-EM-2 | Auftragsstatus-Pipeline: Anfrage → Prüfung → offen → teilweise besetzt → vollständig besetzt → aktiv → abgeschlossen/storniert [Blueprint 19.4] | Sabrina | Statuswechsel nur in zulässiger Reihenfolge, sichtbar im Dashboard | ⬜ |
| FR-EM-3 | Mitarbeiterzuweisung prüft Qualifikation, Verfügbarkeit, Arbeitszeit, Abwesenheiten, Überschneidungen, Vertragsbedingungen [Blueprint 19.4] | Sabrina | System verhindert/warnt bei Konflikten vor Zuweisung | ⬜ |
| FR-EM-4 | Nach Zuweisung erhält Mitarbeiter automatisch Einsatzanweisung über OMSORG Connect [Blueprint 19.4] | System → Außendienst | Einsatzanweisung erscheint in Connect ohne manuellen Zusatzschritt | 🔶 (Connect hat bereits `pages/einsatzanweisung.php` inkl. Admin-Upload `actions/einsatzanweisung-action.php`; automatische Erzeugung aus Zuweisung fehlt, da Aufträge/Zuweisung noch nicht existieren) |
| FR-EM-5 | Krankmeldung löst Ersatzbesetzungs-Workflow aus [omsorg.md, Blueprint 20.2] | System, Sabrina | Bei Krankmeldung erscheint Einsatz als "muss neu besetzt werden" inkl. Vorschlägen | ⬜ |

### 4.5 Zeiterfassung & Tätigkeitsnachweise

| ID | Anforderung | Akteur | Akzeptanzkriterium | Status |
|---|---|---|---|---|
| FR-ZE-1 | Erfassung von Beginn, Pause, Ende, Einrichtung, Auftrag, Nacht-/Wochenend-/Feiertagsstunden [Blueprint 19.5] | Außendienst | Eintrag pro Schicht mit Pflichtfeldern | 🔶 (aktuell nur monatlicher Upload via `pages/stundennachweis.php`/`actions/submit-stundennachweis.php`, keine strukturierte Beginn/Pause/Ende-Erfassung pro Schicht) |
| FR-ZE-2 | Statuspipeline: Entwurf → eingereicht → Prüfung → Rückfrage → freigegeben → abgerechnet [Blueprint 19.5] | Außendienst, Sabrina | Statuswechsel sichtbar für beide Seiten, Rückfrage möglich | 🔶 (aktueller Status ist binär offen/geprüft über Admin-Anträge, kein granularer Workflow) |
| FR-ZE-3 | Nur freigegebene Zeiten dürfen in Rechnungsstellung einfließen [Blueprint 19.5, 19.8] | System | Rechnungslauf ignoriert nicht-freigegebene Datensätze; Verstoß ist technisch unmöglich, nicht nur UI-Regel | ⬜ |
| FR-ZE-4 | Optionale Unterschrift/Bestätigung der Einrichtung, Upload als Foto/PDF | Außendienst | Upload-Feld vorhanden, an Zeiterfassungssatz gekoppelt | 🔶 (Upload existiert für Monatsnachweis, nicht pro Einzel-Einsatz) |

### 4.6 Rechnungen & Zahlungsüberwachung

| ID | Anforderung | Akteur | Akzeptanzkriterium | Status |
|---|---|---|---|---|
| FR-RE-1 | Automatische Rechnungserstellung aus freigegebener Zeit + Konditionen + Zuschlägen [Blueprint 19.6] | System, Sabrina (Freigabe) | Rechnungsentwurf wird ohne manuelle Neuerfassung generiert | ⬜ |
| FR-RE-2 | Statuspipeline: Entwurf → Prüfung → freigegeben → versendet → offen → bezahlt (alternativ überfällig → Mahnung → bezahlt) [Blueprint 19.6] | Sabrina, Sabina/Malik (Freigabe) | Statuswechsel protokolliert, keine übersprungenen Zwischenschritte | ⬜ |
| FR-RE-3 | Zahlungsziel 14 Tage wird von der Engine überwacht; bei Überschreitung Dashboard-Warnung + Mahnentwurf [Blueprint 19.6, 20.2] | System → Sabrina | Nach 14 Tagen ohne Zahlungseingang erscheint automatisch Mahnentwurf | ⬜ |
| FR-RE-4 | Rechnungs-PDF-Erzeugung und Versand, Dokumentation in Mahnhistorie | Sabrina | PDF entspricht Rechnungsdaten; Versand/Historie nachvollziehbar | ⬜ |

### 4.7 Recruiting & Akquise

| ID | Anforderung | Akteur | Akzeptanzkriterium | Status |
|---|---|---|---|---|
| FR-REC-1 | Bewerberpipeline: Interessent → Bewerbung → Erstkontakt → Vorstellung → Unterlagen → Angebot → Einstellung → geplanter Eintritt [Blueprint 3.2] | Sascha | Bewerberdatensatz mit Statuswechsel | ⬜ |
| FR-REC-2 | Werbung/Empfehlung: Kanäle Indeed, Facebook, Instagram, Mitarbeiterempfehlung erfassbar [omsorg.md] | Sascha | Herkunft je Bewerber taggable, auswertbar | 🔶 (`pages/werben.php`/`actions/submit-werben.php` erfasst Mitarbeiterempfehlungen bereits; Kanaltracking für externe Werbung fehlt) |
| FR-REC-3 | Einrichtungsakquise: Lead anlegen → Ansprechpartner erfassen → Kontakt → Gesprächsnotiz → Ergebnis → automatische Wiedervorlage nach 14 Tagen [Blueprint 3.5] | Sascha | Wiedervorlage wird ohne manuellen Trigger vom System erzeugt | ⬜ |
| FR-REC-4 | Sascha hat keinen Zugriff auf Rechnungen, Zahlungen, Gewinn, Margen, Controlling [Blueprint 6.2] | System | Rollenprüfung blockiert Zugriff serverseitig | ⬜ |

### 4.8 Controlling

| ID | Anforderung | Akteur | Akzeptanzkriterium | Status |
|---|---|---|---|---|
| FR-CTL-1 | Auswertungen: Umsatz, Kosten, Gewinn, Deckungsbeitrag, Margen, Auslastung, Fehlzeiten, Einrichtungsrentabilität, offene Forderungen, Recruiting-/Marketing-Erfolg, Fahrzeugkosten [Blueprint 11] | Sabina, Malik (voll), Sabrina (eingeschränkt) | Jede Kennzahl aus Core-Daten berechnet, nicht manuell gepflegt | ⬜ |
| FR-CTL-2 | Drei-Monats-Durchschnitt und Trends/Prognosen [Blueprint 11] | Sabina, Malik | Rollierender Durchschnitt wird automatisch aktualisiert | ⬜ |
| FR-CTL-3 | Vollständige Gewinn-/Margendaten ausschließlich für Sabina/Malik [Blueprint 11] | System | Andere Rollen erhalten aggregierte/gekürzte Werte oder keinen Zugriff | ⬜ |

### 4.9 OMSORG Connect (Mobile)

| ID | Anforderung | Akteur | Akzeptanzkriterium | Status |
|---|---|---|---|---|
| FR-CON-1 | Zeiterfassung, digitaler Tätigkeitsnachweis, Fahrtenbuch, Einsatzanweisung, Krankmeldung, Urlaub, Dokumente, News, Benefits, Ansprechpartner [omsorg.md, Blueprint 4.2] | Außendienst | Jede Funktion als eigener Menüpunkt erreichbar | 🔶 (vorhanden: Stundennachweis-Upload, Urlaubs-/Abwesenheitsantrag, Dokumentenarchiv, News, Benefits, Einsatzanweisung, Fortbildung, Dienstplan, Werben, Bewertung — **Fahrtenbuch fehlt vollständig**, Zeiterfassung ist Upload statt Live-Erfassung) |
| FR-CON-2 | Automatische Synchronisation mit OMSORG Desktop [omsorg.md] | System | Änderung in Connect ist ohne manuellen Export in Desktop sichtbar | ⬜ (blockiert durch fehlendes OMSORG Backend, s. Abschnitt 2) |
| FR-CON-3 | PWA-Installierbarkeit ("Add to Home Screen") | Außendienst | Manifest + Service Worker vorhanden und funktionsfähig | ✅ (`manifest.webmanifest`, `service-worker.js`) |
| FR-CON-4 | Login-Rate-Limiting: 5 Fehlversuche → 10 Min. Sperre | Außendienst/alle | Nach 5 Fehlversuchen wird Login für 10 Minuten blockiert | ✅ (`index.php`, `login_attempts`-Tabelle, Migration 004) |

### 4.10 OMSORG Backend – Event-Schicht (Engine, Ereignis → Aktion)

Die Event-Schicht ist Teil des Backends (siehe Abschnitt 2) und läuft im selben Prozess/Service wie die Datenschicht (Core, Abschnitt 6) — nicht als separates Deployable.

| Trigger | Erwartete Aktionen [Blueprint 20.2] | Status |
|---|---|---|
| Krankmeldung eingereicht | Dashboard aktualisieren, Disposition informieren, Einsatz markieren, Ersatzvorschläge anzeigen, Einsatzanweisung vorbereiten, Historie ergänzen | ⬜ |
| Tätigkeitsnachweis fehlt (montags) | Dashboard aktualisieren, Mitarbeiter markieren, Erinnerung via Connect senden, Rechnungsfreigabe blockieren | ⬜ |
| Vertragsende nähert sich (30 Tage) | Dashboard-Warnung, zuständige Person informieren, Kontakt/Vertrag direkt öffnen | ⬜ |
| Neue Bewerbung | Recruiting informieren, Bewerber anlegen, Wiedervorlage erzeugen, Status "Neu" | ⬜ |
| Zahlung eingegangen | Zahlungsstatus ändern, Mahnungen stoppen, Dashboard/Controlling/Liquidität aktualisieren | ⬜ |
| Neuer Mitarbeiter beginnt | Dashboard-Hinweis, Personalakte/Dokumente prüfen, App-Zugang vorbereiten, Einsatzanweisung kontrollieren | ⬜ |
| Rechnung überfällig | Warnung, Mahnentwurf, Freigabe, Versand, Mahnhistorie | ⬜ |

**FR-ENG-1**: Die Event-Schicht besitzt keine eigene UI, arbeitet ereignisbasiert im Hintergrund und schreibt alle Aktionen protokolliert in die jeweiligen Objekte der Datenschicht [Blueprint 20.1, 20.6]. Status: ⬜ — bislang keinerlei Automatisierungsschicht im Repo vorhanden.

### 4.11 Outlook-Integration (spätere Phase)

| ID | Anforderung | Status |
|---|---|---|
| FR-OUT-1 | Neue E-Mails im Morning Briefing, E-Mail↔Einrichtung/Mitarbeiter-Zuordnung, Auftrag/Aufgabe aus E-Mail erzeugen, Rechnungsversand dokumentieren [Blueprint 12] | ⬜ — explizit als spätere Roadmap-Phase (Phase 7) markiert, kein Blocker für Phase 1–6 |

---

## 5. Nicht-funktionale Anforderungen (NFR)

| ID | Anforderung | Quelle | Status |
|---|---|---|---|
| NFR-1 | DSGVO-konforme Verarbeitung, minimale notwendige Berechtigungen | Blueprint 13 | 🔶 (rollenbasierte Sichten in Connect vorhanden, keine dokumentierte DSGVO-Prüfung) |
| NFR-2 | Getrennte Benutzerkonten, sichere Anmeldung, Sitzungssperre | Blueprint 13 | ✅ (Session-Auth, Rate-Limiting in `lib/auth.php`) |
| NFR-3 | Verschlüsselte Datenübertragung und -speicherung sensibler Daten | Blueprint 13 | 🔶 (HTTPS wird vorausgesetzt, aber nicht im Repo erzwungen; keine Feldverschlüsselung für besonders sensible Daten) |
| NFR-4 | CSRF-Schutz auf jedem POST-Formular | omsorgWeb CLAUDE.md | ✅ (`csrf_field()`/`verify_csrf()` durchgängig verwendet) |
| NFR-5 | Ausgabe-Escaping gegen XSS | omsorgWeb CLAUDE.md | ✅ (`e()`-Helper) |
| NFR-6 | Automatische Backups + regelmäßige Wiederherstellungsprüfung | Blueprint 13 | ⬜ |
| NFR-7 | Nachvollziehbare Änderungshistorie / Protokollierung sicherheitsrelevanter Vorgänge | Blueprint 13, 19.8 | 🔶 (Login-Versuche protokolliert; generisches Audit-Log für Datensatzänderungen fehlt) |
| NFR-8 | Aufbewahrungs- und Löschkonzept, Schutz vor unbefugtem Export | Blueprint 13 | ⬜ |
| NFR-9 | Berechtigungsprüfung auf Oberflächen- **und** Datenebene | Blueprint 13, 19.8 | 🔶 (in Connect vorhanden für Außendienst-Eigendaten; granulare Rechtematrix für Büromitarbeiter fehlt) |
| NFR-10 | White-Label-Fähigkeit: Branding (Name, Logo, Farben, Schrift, Vorlagen) von Geschäftslogik getrennt | Blueprint 14 | ⬜ (aktuell Branding fest im Code/CSS von `omsorgWeb`/`omsorgapp`) |
| NFR-11 | Vollständige Mandantentrennung für spätere Multi-Tenant-Nutzung | Blueprint 14 | ⬜ (nicht Teil der aktuellen Datenmodelle; explizit erst „bei Bedarf") |
| NFR-12 | Wiederverwendbare Komponenten, modulare Architektur, klare Verantwortlichkeiten | Blueprint 15 | 🔶 (`omsorgapp/src/components/ui` als Ansatz vorhanden) |

---

## 6. Datenmodell-Anforderungen (OMSORG Backend – Datenschicht/Core)

Die sechs Core-Objekte [Blueprint Kap. 19]: **Mitarbeiter, Einrichtung, Vertrag, Auftrag, Zeiterfassung, Rechnung**.

Verbindliche Regeln [Blueprint 19.8]:

1. Jeder Datensatz besitzt eine eindeutige interne ID.
2. Beziehungen werden über IDs hergestellt, nicht durch doppelte Texteingaben.
3. Stammdaten werden nur an einer zentralen Stelle gepflegt.
4. Änderungen werden nachvollziehbar protokolliert.
5. Löschungen sensibler/geschäftsrelevanter Daten erfolgen nicht unkontrolliert (Soft-Delete/Archivierung statt Hard-Delete).
6. Berechtigungen werden auf Daten- und Funktionsebene geprüft.
7. Automatisierungen (Event-Schicht) greifen ausschließlich auf verlässliche, freigegebene Daten zu — dadurch, dass Datenschicht und Event-Schicht im selben Backend-Prozess laufen, ist dies technisch einfacher garantierbar als bei getrennten Services (kein Risiko von veralteten/inkonsistenten Zwischenständen durch asynchrone Synchronisation).
8. Rechnungen entstehen ausschließlich aus freigegebenen Arbeitszeiten.
9. OMSORG Connect erhält nur die für den jeweiligen Mitarbeiter freigegebenen Daten.

**FR-CORE-1**: Es gibt genau eine Datenquelle für jedes Core-Objekt, die von Desktop, Connect, Event-Schicht (Engine) und Controlling gemeinsam genutzt wird — bereitgestellt durch die Datenschicht des Backends. Status: 🔶 — das Backend selbst existiert jetzt (`omsorgCore`, PostgreSQL/EF Core, alle 6 Core-Objekte als Entitäten angelegt). `omsorgapp` ist für das Mitarbeiter-Objekt bereits umgestellt (echtes CRUD über `omsorgCore`, keine JSON-Persistenz mehr für dieses Modul), die übrigen `omsorgapp`-Fachmodule und `omsorgWeb` (MySQL) sprechen noch nicht damit. Solange diese Anbindung für die restlichen Objekte/Projekte fehlt, bleiben es weiterhin getrennte Speicher parallel zum neuen Backend. **Anbindung der bestehenden Projekte an `omsorgCore` ist die zentrale technische Voraussetzung, bevor Phase 2 ff. sinnvoll umsetzbar sind.**

---

## 7. Rechtematrix (Auszug, aus Blueprint Kap. 6 abgeleitet)

| Modul | Sabina/Malik | Sabrina | Sascha | Außendienst |
|---|---|---|---|---|
| Mitarbeiter (Personalakte) | voll | voll | eingeschränkt (soweit erforderlich) | nur eigene Daten |
| Einrichtungen/CRM | voll | voll | Leads/Akquise | – |
| Aufträge/Disposition | voll | voll | – | nur eigene Einsätze |
| Zeiterfassung | voll | prüfen/freigeben | – | eigene erfassen |
| Rechnungen/Zahlungen | voll | erstellen/freigeben | **kein Zugriff** | – |
| Recruiting/CRM | voll | nutzen | voll | – |
| Controlling | voll (inkl. Gewinn/Margen) | eingeschränkt (kein Gewinn) | **kein Zugriff** | – |
| Benutzerverwaltung | voll | – | – | – |

Für zukünftige Büromitarbeiter: Rolle als Vorlage, zusätzlich granular je Modul einstellbar: sehen / lesen / anlegen / bearbeiten / löschen / exportieren / freigeben [Blueprint 6.5].

---

## 8. Abnahmekriterien (Definition of Done, je Gruppe)

- **Dashboard**: Alle in 4.1 gelisteten Kategorien sind sichtbar, rollenabhängig gefiltert, klickbar zur Zielaktion.
- **Mitarbeiter/Einrichtungen**: CRUD vollständig, keine Pflichtfeld-Lücken, Änderungen protokolliert.
- **Einsatzmanagement**: Zuweisung ohne Qualifikations-/Zeitkonflikt möglich; bei Konflikt blockiert oder mit Warnung.
- **Zeiterfassung/Rechnung**: Rechnung technisch nicht erzeugbar aus nicht freigegebener Zeit (FR-ZE-3) — verifizierbar per Testfall, nicht nur Review.
- **Rollen/Rechte**: Jeder Endpunkt/jede Route prüft Berechtigung serverseitig, nicht nur im UI.
- **Engine**: Jeder in 4.10 gelistete Trigger löst nachweisbar (Log-Eintrag) die zugehörigen Aktionen aus.

---

## 9. Offene Punkte / Annahmen

- Tiefe der Outlook-Integration (nur Anzeige vs. bidirektionale Synchronisation) ist noch nicht spezifiziert.
- Zeitpunkt und Umfang der Mandantentrennung (White-Label) ist bewusst auf „bei Bedarf" verschoben — keine Anforderung für aktuelle Phasen.
- Unklar, ob das OMSORG Backend (Core + Engine) als eigenständiger Service (eigene API, von Desktop und Connect angesprochen) oder als gemeinsame DB-/Logikschicht unter `omsorgWeb`/`omsorgapp` realisiert wird — technische Entscheidung noch offen, aber Voraussetzung für FR-CORE-1. Klar ist nur: Core (Datenschicht) und Engine (Event-Schicht) gehören in denselben Service, nicht in zwei getrennte.
- Fahrtenbuch (FR-CON-1) ist in keiner der bestehenden Codebasen auch nur ansatzweise vorhanden — vollständige Neuentwicklung nötig.
- Rechtsform granularer Einzelrechte (FR-MA-5) — Datenmodell für Berechtigungen (Modul × Recht) ist noch nicht definiert.

---

## 10. Rückverweis zur Roadmap [Blueprint Kap. 16]

| Roadmap-Phase | Betroffene FR-Gruppen | Voraussetzung erfüllt? |
|---|---|---|
| Phase 1 – Fundament | FR-CORE-1, NFR-6, NFR-7, NFR-9, NFR-10 | 🔶 Teilweise — Backend-Grundgerüst mit Rechtesystem/Auth/Datenmodell steht, Mitarbeiter-Objekt in `omsorgapp` bereits angebunden, aber Anbindung von `omsorgWeb` und der übrigen `omsorgapp`-Fachmodule fehlt noch, ebenso Backups (NFR-6) und vollständiger Audit-Trail (NFR-7) |
| Phase 2 – Stammdaten | FR-MA-1..5, FR-EIN-1..5 | Blockiert durch Phase 1 |
| Phase 3 – Operatives Geschäft | FR-EM-1..5 | Blockiert durch Phase 1/2 |
| Phase 4 – Zeit und Abrechnung | FR-ZE-1..4, FR-RE-1..4 | Teilbasis vorhanden (Connect-Upload), aber ohne Core nicht rechnungsfähig |
| Phase 5 – Recruiting und CRM | FR-REC-1..4 | Teilbasis vorhanden (Werben), CRM-Pipeline fehlt |
| Phase 6 – OMSORG Connect | FR-CON-1..4 | 🔶 größtenteils vorhanden, Fahrtenbuch + Sync offen |
| Phase 7 – Dashboard und Controlling | FR-DASH-1..4, FR-CTL-1..3, FR-OUT-1 | Teilbasis (`omsorgapp` Dashboard-Ansätze) vorhanden |

**Empfehlung für den nächsten Sprint:** Phase 1 zuerst — das OMSORG Backend (Core + Engine als eine Komponente) mit gemeinsamer Datenbasis definieren (Datenmodell für die 6 Core-Objekte, IDs, Beziehungen, plus die Event-Schicht als Aufsatz auf denselben Daten), bevor weitere Module in `omsorgapp` gebaut werden. Ohne diesen Schritt wächst die Diskrepanz zwischen Connect (MySQL, produktiv) und Desktop (JSON, lokal) weiter.