SOLL Planung nach erster Bedarfsanalyse fertig

2026-08-28 08:53:06 +02:00
1 parent 7a735915d1
commit 39b891cd63
@@ -0,0 +1,34 @@
 # Produktbeschreibung – Terminbuchungskalender (SOLL)
 ## Stand und Geltung
 Dieses Zielbild verarbeitet die Ergebnisse des ersten Bedarfsgesprächs vom 27.08.2026. Es beschreibt ausschließlich das geplante Produkt **Terminbuchungskalender**. Technische Einbettung und konkrete Betriebsumgebung sind noch nicht entschieden und nicht Gegenstand dieser Produktbeschreibung.
 ## Produktziel
 Der Terminbuchungskalender ermöglicht Klientinnen und Klienten, verfügbare Termine für Perspektivwerk (PW) oder Produktionsschule (PS) zu finden, verbindlich anzufragen und nach Bestätigung wahrzunehmen. Er bildet den gesamten Ablauf vom Sichtbarwerden eines Termins bis zur Bestätigung, Erinnerung, gegebenenfalls Stornierung durch die durchführende Person und Auswertung bestätigter Teilnahmen ab.
 ## Zwei getrennte Kalenderinstanzen
 Für PW und PS wird jeweils eine eigene Kalenderinstanz angezeigt. Besuchende sehen nur den Kalender des jeweiligen Angebots; ein Umschalten zwischen PW und PS innerhalb der Kalenderoberfläche ist nicht vorgesehen. Beide Instanzen werden aus derselben fachlichen und technischen Basis erzeugt, besitzen aber eigene Termine, eigene bestätigte Teilnahmen und je einen eigenen abonnierbaren iCalendar-Kalender.
 ## Nutzen für Besuchende
 Besuchende können Terminart, Zeitpunkt, Dauer, Format und Verfügbarkeit erkennen. Sie können mehrere Termine nacheinander anfragen, ohne erforderliche Anmeldedaten jeweils erneut einzugeben. Eine bestätigte Anfrage wird per E-Mail bestätigt; die Nachricht weist gegebenenfalls auf weitere bereits bestätigte Termine hin, nennt eine Kontaktperson für Durchführung und Stornierungen des Termins und wird zwei Tage vor Beginn durch eine Erinnerung ergänzt.
 ## Nutzen für die Durchführung
 Personen mit Zugriff auf die Verwaltungsoberfläche können Termine und ihre Konfiguration pflegen, Teilnahmen verwalten und bestätigte Teilnehmende eines frei wählbaren Zeitraums exportieren. Änderungen an der Konfiguration sollen in einer Live-Vorschau des Kalenders unmittelbar sichtbar sein.
 ## Abgrenzung und offene Grundentscheidung
 Eine eigenständige Benutzerverwaltung ist nach aktuellem Bedarf nicht vorgesehen. Der Zugriff auf die Verwaltungsoberfläche erfolgt über einen Backend-Link. Diese Vorgabe ist wegen der darin verarbeiteten personenbezogenen Daten sicherheits- und datenschutzrechtlich vor Produktivsetzung verbindlich zu bewerten.
 Noch offen ist, ob der Kalender innerhalb eines bestehenden Systems oder als eigenständiges Tool mit eigener Laufzeit, Datenhaltung und Verwaltungsoberfläche betrieben wird.
 ## Checkpoints
 - [ ] Das Zielbild ist mit PW und PS fachlich abgestimmt.
 - [ ] Die Entscheidung über die Betriebsarchitektur ist getroffen.
 - [ ] Das Zugriffsmodell für die Verwaltungsoberfläche ist trotz fehlender Benutzerverwaltung freigegeben.
 - [ ] Die fachliche Bedeutung von „bestätigt“ und „verbindlich“ ist eindeutig festgelegt.
@@ -0,0 +1,47 @@
 # Geplanter Funktionsumfang – Terminbuchungskalender (SOLL)
 ## Kalender und Terminanzeige
 Der Kalender zeigt nur Termine der zugeordneten Instanz PW oder PS. Jeder Termin besitzt eine einstellbare Kapazität von 1 bis 100 Teilnahmen. Solange freie Kapazität vorhanden ist, ist er buchbar; nach Erreichen der Kapazität wird er als nicht weiter buchbar geführt.
 Die Dauer eines Termins muss sichtbar sein. Termine bis einschließlich vier Stunden benötigen keine besondere Verlaufsdarstellung. Längere Termine erhalten einen sichtbaren Balken über den gesamten betroffenen Tag. Mehrtägige Termine erhalten einen zusammenhängenden Balken über alle betroffenen Kalendertage.
 Für jeden Termin wird sichtbar, ob er vor Ort oder telefonisch stattfindet. Beginn, Ende, Name und Verfügbarkeit sind aus der Kalender- und Detailansicht nachvollziehbar.
 ## Anmeldung und Bestätigung
 Eine Anmeldung erfordert mindestens Name, E-Mail-Adresse und Telefonnummer, ein weiteres Pflichtfeld kann ausserdem aktiviert werden. Die Zustimmung zu den Datenschutzhinweisen bleibt vor dem Absenden erforderlich.
 Nach der Anfrage erfolgt die vorgesehene Bestätigung per E-Mail. Nach Bestätigung zählt die Teilnahme zur Kapazität und erscheint im iCalendar-Kalender der jeweiligen Instanz.
 Bei einer neuen Bestätigung prüft das System historische und bereits bestätigte Anmeldungen derselben Person anhand von Name und E-Mail-Adresse. Bestehen weitere bestätigte Termine, nennt die Bestätigungsmail diese Termine.
 ## Besonderheit PS: Probearbeiten
 Für die PS-Terminart „Probearbeiten“ ist die vorherige Teilnahme an einer Einführungsveranstaltung Voraussetzung. Die Anmeldung verlangt dafür eine Bestätigung per Checkbox und die Angabe des Datums der Einführungsveranstaltung. Die fachliche und technische Prüfung dieser Angabe ist noch zu konkretisieren.
 ## Mehrfachbuchung und Stornierung
 Besuchende sollen mehrere Termine unmittelbar nacheinander buchen können. Die bereits eingegebenen Anmeldedaten bleiben dafür im Browser verfügbar und werden für die nächste Anmeldung vorausgefüllt. Art und Dauer dieser lokalen Speicherung sind noch festzulegen.
 Eine Selbststornierung durch Besuchende ist aktuell nicht vorgesehen. Die Bestätigungsmail enthält die Kontaktangabe der durchführenden Person. Diese entfernt die angemeldete Person bei Bedarf aus dem Termin; die frei werdende Kapazität wird wieder verfügbar.
 ## Erinnerungen, Kalender und Export
 Zwei Tage vor Beginn einer bestätigten Teilnahme wird eine Erinnerungsmail versendet. Für PW und PS existiert jeweils ein abonnierbarer iCalendar-Kalender mit allen bestätigten Terminen; dieser wird bei jeder neuen Bestätigung oder Stornierung aktualisiert.
 Die Verwaltungsoberfläche bietet je Instanz einen Export aller bestätigten Teilnahmen für einen frei definierbaren Zeitraum.
 ## Qualitätssicherung
 Alle Prozesse und Funktionen des Kalenders werden durch technische Tests abgedeckt. Dazu gehören mindestens Unit-Tests für Geschäftsregeln sowie Integrations- und End-to-End-Tests für die zentralen Buchungsabläufe.
 ## Checkpoints
 - [ ] Der genaue Bestätigungsablauf einschließlich möglichem Double-Opt-in ist festgelegt.
 - [ ] Die Nutzung von Signal Messenger ist fachlich, rechtlich und technisch entschieden.
 - [ ] Die Kriterien zur Erkennung einer Mehrfachanmeldung sind bestätigt.
 - [ ] Die Prüfung der Einführungsveranstaltung für Probearbeiten ist definiert.
 - [ ] Die Darstellung mehrtägiger und langer Termine ist fachlich abgenommen.
 - [ ] Die Regeln für frei werdende Kapazitäten nach Löschung einer Teilnahme sind festgelegt.
 - [ ] Die Inhalte von Bestätigungs- und Erinnerungsmail sind abgestimmt.
@@ -0,0 +1,41 @@
 # Technisches Zielbild – Terminbuchungskalender (SOLL)
 ## Architekturprinzip
 Der Kalender wird als wiederverwendbare technische Basis für zwei getrennte Instanzen PW und PS umgesetzt. Die Oberfläche darf keine fachlichen Daten, Geheimnisse oder Buchungsentscheidungen dauerhaft im Browser halten. Termine, Kapazitäten, Anmeldungen, Bestätigungen, Erinnerungen, Exporte und Kalenderfeeds benötigen eine serverseitige Geschäftslogik und persistente Datenhaltung.
 Die konkrete Betriebsform bleibt offen: Integration in ein bestehendes System oder eigenständiges Tool mit eigener Laufzeit, Datenbankmodell und Verwaltungsoberfläche. Unabhängig davon müssen Oberfläche, Geschäftslogik, Datenzugriff, Benachrichtigung und Kalenderfeed voneinander getrennt bleiben.
 ## Konfiguration und Vorschau
 Die Verwaltungsoberfläche erlaubt das Anlegen, Bearbeiten und Löschen von Terminen sowie die Pflege ihrer Parameter. Während einer Konfigurationsänderung wird eine Live-Vorschau der jeweiligen Kalenderinstanz angezeigt, damit sich die sichtbare Wirkung ohne Zwischenschritt prüfen lässt.
 ## Buchungslogik und Konsistenz
 Eine Buchung muss die Kapazität atomar prüfen und nach Bestätigung erhöhen. Gleichzeitige Anfragen dürfen nicht zu mehr bestätigten Teilnahmen als der definierten Kapazität führen. Entfernt eine durchführende Person eine Teilnahme, wird die Kapazität korrekt neu berechnet oder freigegeben.
 Bestätigung, Erinnerungen und iCalendar-Aktualisierung sind aus bestätigten Buchungszuständen abzuleiten. Wiederholte technische Ausführung derselben Aufgabe darf nicht zu mehrfachen Erinnerungen oder doppelten Bestätigungen führen.
 ## Schnittstellen
 Erforderlich sind mindestens Schnittstellen oder Dienste für:
 - Termin- und Konfigurationsdaten,
 - Anfragen, Bestätigungen und Kapazitätsprüfung,
 - Versand von Bestätigungs- und Erinnerungsnachrichten,
 - abonnierbare iCalendar-Feeds je Instanz,
 - Export bestätigter Teilnahmen nach Zeitraum,
 - Prüfung bzw. Anzeige historischer Teilnahmen bei Mehrfachanmeldungen.
 ## Teststrategie
 Geschäftsregeln erhalten Unit-Tests. Integrations-Tests prüfen Datenzugriff, Kapazitätsgrenzen, Bestätigung, Kalenderfeed, Export und Benachrichtigungsplanung. End-to-End-Tests prüfen den sichtbaren Ablauf von Kalender, Anmeldung, Bedingungen für Probearbeiten und Rückmeldungen.
 ## Checkpoints
 - [ ] Betriebsform, Datenbank und Verwaltungsoberfläche sind entschieden.
 - [ ] Die Schnittstellen zwischen Oberfläche und Geschäftslogik sind spezifiziert.
 - [ ] Die Atomarität der Kapazitätsprüfung ist technisch nachweisbar getestet.
 - [ ] Versand, Erinnerung und iCalendar-Aktualisierung sind idempotent umgesetzt.
 - [ ] Die Live-Vorschau ist Teil der Konfigurationsoberfläche getestet.
 - [ ] Für jede fachliche Regel existiert ein automatisierter Test.
@@ -0,0 +1,38 @@
 # Datenmodell – Terminbuchungskalender (SOLL)
 ## Termin
 Ein Termin ist die zentrale fachliche Einheit. Er enthält mindestens:
 - eindeutige Termin-ID,
 - Name bzw. Terminart,
 - Beginn und Ende,
 - Zuordnung zu PW oder PS,
 - Kapazität von 1 bis 100,
 - Anmeldebedingung „Einführungsveranstaltung besucht“,
 - durchführende Person mit Name und E-Mail-Adresse,
 - Format `vor Ort` oder `telefonisch`.
 Aus Beginn und Ende wird die visuelle Dauer im Kalender abgeleitet. Die durchführende Person dient auch als Kontakt für die Stornierung durch Klientinnen und Klienten.
 ## Anmeldung und bestätigte Teilnahme
 Eine Anmeldung benötigt mindestens Name, E-Mail-Adresse, Telefonnummer sowie die Zuordnung zum Termin. Für Probearbeiten kommt die Bestätigung der Einführungsveranstaltung mit dem angegebenen Datum hinzu.
 Das Datenmodell benötigt unterscheidbare Zustände mindestens für Anfrage, ausstehende Bestätigung, bestätigt, entfernt bzw. storniert und abgelaufen.
 ## Historie und Mehrfachanmeldungen
 Aus den gespeicherten Anmeldungen können an Hand des Status frühere oder paralleler Anmeldungen erkannt werden um diese gegebenenfalls zu verhindern, um als Information in der Bestätigungsmail oder beim Export als Liste verwendet zu werden.
 ## Ableitbare Daten
 Die freie Kapazität eines Termins ergibt sich aus Kapazität und Anzahl bestätigter, nicht entfernter Teilnahmen. Die iCalendar-Feeds und Exporte enthalten ausschließlich bestätigte Termine beziehungsweise Teilnahmen im ausgewählten Zeitraum.
 ## Checkpoints
 - [ ] Terminarten, Dauerregeln und mögliche Mehrtagestermine sind vollständig modelliert.
 - [ ] Zustände und Übergänge einer Anmeldung sind fachlich bestätigt.
 - [ ] Die Definition einer „gleichen Person“ für Mehrfacherkennung ist abgestimmt.
 - [ ] Die Historie hat einen dokumentierten Zweck, Zugriffskreis und Löschzeitpunkt.
 - [ ] Der Exportinhalt und die iCalendar-Felddaten sind verbindlich festgelegt.
@@ -0,0 +1,27 @@
 # Benutzerrollen – Terminbuchungskalender (SOLL)
 ## Besuchende
 Besuchende sehen ausschließlich die ihnen zugeordnete Kalenderinstanz. Sie können Terminangebote einsehen, freie Kapazitäten erkennen, eine Anmeldung abgeben und bei mehreren aufeinanderfolgenden Anmeldungen ihre zuvor eingegebenen Daten erneut verwenden. Sie erhalten Bestätigungs- und Erinnerungsnachrichten.
 Besuchende verwalten keine Termine selbst. Für eine Stornierung kontaktieren sie die in der Bestätigung genannte durchführende Person.
 ## Durchführende Person
 Die durchführende Person ist einem Termin mit Name und E-Mail-Adresse zugeordnet. Sie wird als Kontakt für Stornierungen genannt und kann eine angemeldete Person aus einem Termin entfernen. Die genaue Abgrenzung gegenüber der allgemeinen Verwaltungsrolle ist noch zu entscheiden.
 ## Verwaltungszugriff
 Aktuell ist keine Benutzerverwaltung vorgesehen. Personen, die den Backend-Link erhalten, können Termine anlegen, bearbeiten und löschen sowie Teilnahmen verwalten und Exporte erzeugen. Diese Rolle ist deshalb organisatorisch als besonders schutzbedürftig zu behandeln.
 ## Nicht als Rollen zu verstehen
 PW und PS sind getrennte Kalenderinstanzen, keine Benutzerrollen. Es ist noch festzulegen, ob ein Verwaltungszugriff nur eine Instanz oder beide Instanzen bearbeiten darf.
 ## Checkpoints
 - [ ] Die Befugnisse der durchführenden Person sind eindeutig abgegrenzt.
 - [ ] Es ist entschieden, ob Verwaltungszugriffe für PW und PS getrennt werden.
 - [ ] Der Umgang mit verloren gegangenen oder weitergegebenen Backend-Links ist festgelegt.
 - [ ] Die Berechtigung zum Export personenbezogener Daten ist geregelt.
 - [ ] Das Rollen- und Zugriffskonzept ist vor Produktivsetzung freigegeben.
@@ -0,0 +1,35 @@
 # Datenschutz und Sicherheit – Terminbuchungskalender (SOLL)
 ## Personenbezogene Daten und Zweckbindung
 Das Endprodukt verarbeitet mindestens Name, E-Mail-Adresse, Telefonnummer, Terminbezug, Zustimmungsstatus und bei bestätigten Teilnahmen historische Zuordnungen zu Veranstaltungs-IDs. Bei Probearbeiten kommt die Angabe zur Einführungsveranstaltung hinzu. Diese Daten dürfen ausschließlich für Terminplanung, Bestätigung, Erinnerung, Durchführung, Stornierungsbearbeitung und die vereinbarte Auswertung verwendet werden.
 ## Transparenz und Einwilligung
 Vor dem Absenden werden Datenschutzhinweise nach Art. 13 DSGVO bereitgestellt und die bestätigte Kenntnisnahme dokumentiert. Rechtsgrundlage, genaue Formulierung, Nachweisform und Speicherfrist müssen vor Produktivsetzung abgestimmt werden.
 ## Lokale Wiederverwendung von Anmeldedaten
 Für mehrere aufeinanderfolgende Buchungen dürfen Anmeldedaten im Browser vorgehalten werden. Es ist zu entscheiden, ob dies nur während der Sitzung oder darüber hinaus erfolgt, wie Besuchende informiert werden und wie sie die lokalen Daten entfernen können. Eine dauerhafte Speicherung im Browser darf nicht ohne dokumentierte Rechts- und Sicherheitsabwägung erfolgen.
 ## Schutz der Buchungsprozesse
 Alle Eingaben werden serverseitig validiert. Buchungs- und Bestätigungsvorgänge benötigen Schutz gegen CSRF, automatisierte Anfragen und Kapazitätsüberbuchung. Bestätigungstoken, E-Mail-Adressen, Kalenderfeed-Adressen und Exporte sind vertraulich zu behandeln. Fehlermeldungen dürfen keine personenbezogenen Daten oder interne Zustände preisgeben.
 ## Verwaltungszugriff und Export
 Der geplante Zugriff allein über einen Backend-Link ist ein Risiko, weil damit Termine und personenbezogene Teilnahmedaten verändert oder exportiert werden können. Vor Produktivsetzung ist mindestens festzulegen, wie der Link geschützt, weitergegeben, widerrufen und protokolliert wird. Die fehlende Benutzerverwaltung ist eine bewusste fachliche Vorgabe, kein Ersatz für Zugriffsschutz.
 ## Nachrichten und iCalendar
 E-Mail-Bestätigungen und Erinnerungen enthalten nur die für den Termin erforderlichen Daten. Die zusätzliche oder alternative Nutzung von Signal Messenger erfordert eine eigene Prüfung von Einwilligung, Empfängerzuordnung, Auftragsverarbeitung, Datenübermittlung und betrieblichen Zuständigkeiten. iCalendar-Feeds dürfen keine nicht erforderlichen personenbezogenen Informationen offenlegen und benötigen nicht erratbare, widerrufbare Adressen.
 ## Checkpoints
 - [ ] Art.-13-Information, Rechtsgrundlage und Einwilligungsnachweis sind abgestimmt.
 - [ ] Datenminimierung und Pflicht-/freiwillige Felder sind bestätigt.
 - [ ] Löschfristen für Anmeldungen, Historie, Exporte und Protokolle sind definiert.
 - [ ] Der Schutz des Backend-Links ist organisatorisch und technisch geregelt.
 - [ ] Der Signal-Messenger-Einsatz ist entschieden und gegebenenfalls datenschutzrechtlich geprüft.
 - [ ] Schutzmaßnahmen gegen Missbrauch und Überbuchung sind getestet.
 - [ ] Vor Produktivsetzung ist eine gesonderte Sicherheitsanalyse durchgeführt.