IST-Stand und erstes Bedarfsgespräch hinzugefügt

2026-08-27 21:11:17 +02:00
1 parent 037ea11de5
commit 7a735915d1
@@ -0,0 +1,26 @@
+# Produktbeschreibung – Terminbuchungskalender (Mockup)
+
+## Zweck dieses Dokuments
+
+Dieses Dokument beschreibt den gegenwärtigen Stand des Terminbuchungskalenders. Es ist die fachliche Ausgangsbasis. Technische Einbettung und Auslieferung sind ausdrücklich nicht Teil des beschriebenen Produkts.
+
+## Produktgegenstand
+
+Der Produktgegenstand ist ein eigenständiger, im Browser laufender Kalender für Terminangebote. Er soll Besuchenden ermöglichen, verfügbare Termine eines Projekts zu finden, einen passenden Slot auszuwählen und eine Terminanfrage vorzubereiten.
+
+Das Mockup kennt die Projekte `perspektivwerk` und `produktionsschule`. Eine Instanz des Kalenders ist jeweils genau einem Projekt zugeordnet. Eine Auswahl zwischen Projekten innerhalb derselben Kalenderansicht ist gegenwärtig nicht vorhanden.
+
+## Aktueller Nutzen
+
+Das Mockup macht die geplante Nutzerführung erfahrbar:
+
+- freie und belegte Tage sind im Monatskalender unterscheidbar,
+- die Auswahl eines Tages zeigt dessen Slots,
+- freie Slots führen zu einem Eingabedialog für eine Terminanfrage,
+- der Dialog veranschaulicht die für eine spätere Anfrage denkbaren Angaben und die Datenschutzbestätigung.
+
+## Abgrenzung des aktuellen Mockups
+
+Das Mockup ist kein produktives Buchungssystem. Es reserviert keine Termine, speichert keine Eingaben und versendet keine E-Mails. Eine angezeigte Bestätigung ist ausschließlich eine lokale Erfolgsmeldung im Browser.
+
+Nicht Teil dieses Produktstands sind insbesondere Mitarbeitendenverwaltung, Terminpflege, Kalenderabonnements, ICS-Dateien, E-Mail-Bestätigungen, Stornierungen und eine serverseitige Schnittstelle.
@@ -0,0 +1,39 @@
+# Funktionsstand – Terminbuchungskalender (Mockup)
+
+## Kalenderansicht
+
+Der Kalender zeigt einen Monat als Raster von Montag bis Sonntag. Die Monatsansicht lässt sich mit Schaltflächen vor- und zurückblättern. Der anfänglich gezeigte Monat richtet sich nach dem ersten vorhandenen Beispiel-Slot des konfigurierten Projekts.
+
+Tage mit mindestens einem freien Slot werden grün hervorgehoben und mit „frei“ beschriftet. Tage, an denen ausschließlich belegte Beispiel-Slots liegen, werden grau markiert und mit „belegt“ beschriftet. Tage ohne Slots bleiben neutral. Eine Legende erläutert die beiden Zustände.
+
+Jeder Tag ist über die Tastatur erreichbar. Für Screenreader enthält die Tagesauswahl ein Datum und – soweit vorhanden – den Verfügbarkeitszustand.
+
+## Slot-Auswahl
+
+Nach Auswahl eines Tages mit potentiell buchbaren Slots erscheint darunter eine Liste der Slots. Jeder Eintrag enthält Startzeit, Titel und Status. Belegte Slots sind als deaktivierte Schaltflächen dargestellt und können nicht ausgewählt werden. Freie Slots öffnen den Dialog zur Terminanfrage.
+
+## Dialog zur Terminanfrage
+
+Für einen freien Slot öffnet sich ein Dialog. Er zeigt Projekt, Datum, Uhrzeit und Terminart. Der Dialog enthält derzeit folgende Eingabefelder:
+
+- Vor- und Nachname – Pflichtfeld,
+- E-Mail-Adresse – Pflichtfeld,
+- Telefonnummer – freiwillig,
+- Alter – freiwillig,
+- Nachricht – freiwillig,
+- Ansprechperson bei Agentur für Arbeit oder Jobcenter – freiwillig,
+- Bestätigung des dargestellten Datenschutzhinweises – Pflichtfeld.
+
+Die Eingaben werden lokal validiert. Der Absende-Button wird erst nach Zustimmung zum Datenschutzhinweis aktiv. Beim Absenden prüft das Mockup die Felder, schließt den Eingabedialog und zeigt eine lokale Bestätigung an.
+
+## Nicht vorhandene Funktionalität
+
+Ein Absenden löst keine reale Aktion aus. Es gibt keine Speicherung, keine Slot-Reservierung, keine Double-Opt-in-E-Mail, keine Frist, keine Benachrichtigung und keine Sperrung gegen parallele Buchungen.
+
+## Checkpoints
+
+- [ ] Es ist entschieden, welche Terminstatus Besuchende sehen dürfen.
+- [ ] Es ist bestätigt, welche Daten tatsächlich erhoben werden dürfen und müssen.
+- [ ] Es ist entschieden, ob die dargestellte Zustimmung vor der Anfrage erforderlich ist und wie sie formuliert wird.
+- [ ] Der künftige Ablauf nach dem Absenden ist fachlich festgelegt.
+- [ ] Die Anforderungen für Stornierung, Umbuchung und Fehlerfälle sind dokumentiert.
@@ -0,0 +1,40 @@
+# Technischer Stand – Terminbuchungskalender (Mockup)
+
+## Komponentenform
+
+Der Kalender ist eine browsernative JavaScript-Komponente als ES-Modul. Sie wird an einem Element mit dem Attribut `data-sufw-booking` initialisiert. Das Attribut `data-project` legt das Projekt fest; ein anderer oder fehlender Wert wird derzeit als `perspektivwerk` behandelt.
+
+Die Darstellung ist mit eigenem CSS umgesetzt. Die Klassen beginnen mit `sufw-booking`, damit die Stile möglichst wenig mit ihrer Umgebung kollidieren.
+
+## Zustandsverwaltung
+
+Der Zustand existiert ausschließlich im Arbeitsspeicher des Browsers:
+
+- ausgewähltes Projekt,
+- aktuell dargestellter Monat,
+- ausgewählter Tag,
+- lokal geöffneter Dialog und dessen Formulareingaben.
+
+Eine erneute Initialisierung oder ein Neuladen der Seite setzt diesen Zustand zurück.
+
+## Datenquelle
+
+Slots sind als statisches JavaScript-Array im Mockup hinterlegt. Jeder Slot enthält eine Kennung, ein Projekt, ein Datum, eine Startzeit, einen Titel und einen Status. Die Komponente filtert diese Daten nach Projekt und Datum.
+
+Es gibt keine Netzwerkanfrage, keine Datenbankverbindung und keine serverseitige Geschäftslogik.
+
+## Eingabeverarbeitung
+
+Die Formularvalidierung findet vollständig im Browser statt. Sie prüft insbesondere Pflichtangaben, ein einfaches E-Mail-Format, optionale Telefon- und Altersangaben sowie Längenbegrenzungen. Die Slotdaten werden bei der HTML-Ausgabe maskiert. Die Formulareingaben werden nicht gespeichert oder weitergegeben.
+
+## Zugänglichkeit und Browserverhalten
+
+Die Komponente verwendet semantische Schaltflächen, Beschriftungen, `aria-live`-Bereiche, Statusinformationen und einen Dialog. Browser ohne Unterstützung für `dialog.showModal()` erhalten eine einfache offene Dialogvariante. Eine vollständige Prüfung mit Hilfstechnologien ist noch nicht erfolgt.
+
+## Checkpoints
+
+- [ ] Die künftige Datenquelle für Slots ist entschieden.
+- [ ] Die serverseitigen Zustände und Regeln für Reservierung und Buchung sind definiert.
+- [ ] Die Schnittstelle zwischen Oberfläche und Backend ist dokumentiert.
+- [ ] Die Barrierefreiheit ist mit Tastatur, Screenreader und mobilen Geräten geprüft.
+- [ ] Die Browserunterstützung des Endprodukts ist festgelegt.
@@ -0,0 +1,30 @@
+# Datenmodell – Terminbuchungskalender (Mockup)
+
+## Gegenwärtiges Mockup-Datenmodell
+
+Das Mockup besitzt kein persistentes Datenmodell. Es verwendet nur flüchtige Beispielobjekte für Slots. Ein Beispiel-Slot enthält:
+
+- `id`: technisch eindeutige Beispielkennung,
+- `project`: `perspektivwerk` oder `produktionsschule`,
+- `date`: Datum im Format `YYYY-MM-DD`,
+- `start`: Startzeit im Format `HH:MM`,
+- `title`: sichtbare Bezeichnung der Terminart,
+- `status`: `available` oder `booked`.
+
+Die Slots sind die einzige dauerhafte Information im Quellcode. Sie sind Testdaten und keine tatsächlichen Verfügbarkeiten.
+
+## Flüchtige Anfragedaten
+
+Der Anfrage-Dialog verarbeitet Name, E-Mail-Adresse, Telefonnummer, Alter, Nachricht, Ansprechperson und Zustimmungsstatus nur im Browser. Diese Werte werden weder als Buchung noch als Anfrageobjekt angelegt und nach dem Schließen des Dialogs verworfen.
+
+## Fachlich noch nicht modelliert
+
+Das Mockup enthält keine Entitäten für Buchung, Reservierung, Bestätigung, Stornierung, Terminraum, Mitarbeitende, Kalenderfeed, E-Mail oder Löschfristen. Auch Beziehungen zwischen Terminarten, Dauer, Ressourcen und Verfügbarkeitsregeln sind nicht modelliert.
+
+## Checkpoints
+
+- [ ] Es ist definiert, was einen buchbaren Slot fachlich eindeutig identifiziert.
+- [ ] Es ist entschieden, welche Buchungszustände benötigt werden.
+- [ ] Es ist festgelegt, welche Daten zu einer Anfrage gespeichert werden dürfen.
+- [ ] Es ist geklärt, ob Räume, Mitarbeitende oder weitere Ressourcen modelliert werden müssen.
+- [ ] Es existiert ein fachlich bestätigtes Datenmodell einschließlich Aufbewahrungs- und Löschregeln.
@@ -0,0 +1,23 @@
+# Benutzerrollen – Terminbuchungskalender (Mockup)
+
+## Aktive Rolle im Mockup: Besuchende
+
+Das Mockup bildet ausschließlich die Rolle einer besuchenden Person ab. Diese Person kann einen Kalender ansehen, einen Tag wählen, freie und belegte Slots unterscheiden und für einen freien Slot eine lokale Terminanfrage simulieren.
+
+Die Rolle ist nicht authentifiziert. Es gibt keine Kontoerstellung, keine Anmeldung und keine Rechteprüfung.
+
+## Konfiguration statt Rolle: Projektzuordnung
+
+Die Projektwerte `perspektivwerk` und `produktionsschule` sind keine Benutzerrollen. Sie bestimmen nur, welche Beispiel-Slots eine Kalenderinstanz anzeigt.
+
+## Nicht vorhandene Rollen
+
+Das Mockup enthält keine Funktionen für Mitarbeitende, Koordination, Terminverwaltung, Datenschutzbearbeitung oder Administration. Es zeigt daher auch keine internen Buchungsdaten und erlaubt keine Änderung von Slots.
+
+## Checkpoints
+
+- [ ] Die tatsächlichen Benutzergruppen des Endprodukts sind benannt.
+- [ ] Für jede Benutzergruppe sind erlaubte Aktionen und sichtbare Daten festgelegt.
+- [ ] Es ist entschieden, ob Mitarbeitende ausschließlich lesend oder auch verwaltend arbeiten.
+- [ ] Es ist geregelt, wer Datenschutzanfragen bearbeiten darf.
+- [ ] Das Berechtigungsmodell ist vor einer produktiven Buchungsfunktion fachlich und technisch bestätigt.
@@ -0,0 +1,28 @@
+# Datenschutz und Sicherheit – Terminbuchungskalender (Mockup)
+
+## Datenschutzstatus des Mockups
+
+Das Mockup speichert und überträgt keine personenbezogenen Daten. Formularangaben werden nur für die unmittelbare Browservalidierung verarbeitet. Nach dem Schließen des Dialogs besteht im Mockup keine Buchung und keine dauerhafte Aufzeichnung der Eingaben.
+
+Der sichtbare Hinweis auf Art. 13 DSGVO ist gegenwärtig ein Platzhalter für die geplante Nutzerführung. Er stellt weder eine geprüfte Datenschutzerklärung noch eine dokumentierte Rechtsgrundlage dar.
+
+## Sicherheitsstatus des Mockups
+
+Es gibt keine API und damit keine serverseitige Eingabeverarbeitung, Authentifizierung, Autorisierung oder Datenbankabfrage. Das Mockup kann daher weder produktive Zugriffskontrollen noch Schutzmaßnahmen gegen Mehrfachbuchung, Bot-Anfragen oder E-Mail-Missbrauch demonstrieren.
+
+Die Ausgabe der statischen Slotdaten in dynamisch erzeugtes HTML erfolgt maskiert. Dies ist eine lokale Schutzmaßnahme, ersetzt aber keine vollständige Eingabevalidierung und Ausgabekodierung im Endprodukt.
+
+## Anforderungen vor produktivem Einsatz
+
+Sobald personenbezogene Daten verarbeitet werden, müssen Zweck, Rechtsgrundlage, Datenminimierung, Speicherfrist, Löschprozess, Betroffenenrechte, Berechtigungskonzept und technische Schutzmaßnahmen fachlich und rechtlich abgestimmt sein.
+
+Die endgültige Lösung benötigt außerdem serverseitige Validierung, CSRF-Schutz, Rate Limits, einen datenschutzgerechten Bot-Schutz, geschützte Protokollierung und kontrollierte Fehlermeldungen. E-Mail-Bestätigungen, Tokens und Kalenderdaten dürfen nicht allein im Browser umgesetzt werden.
+
+## Checkpoints
+
+- [ ] Die Datenschutzinformation nach Art. 13 DSGVO ist fachlich und rechtlich abgestimmt.
+- [ ] Rechtsgrundlage, Zweck und minimal erforderliche Eingabedaten sind bestätigt.
+- [ ] Speicherfristen und Löschkonzept sind definiert.
+- [ ] Zugriffs- und Berechtigungskonzept für Buchungsdaten ist bestätigt.
+- [ ] Sicherheitsanforderungen für API, E-Mail und Missbrauchsschutz sind definiert.
+- [ ] Vor Produktivsetzung ist eine gesonderte Sicherheitsanalyse durchgeführt.