IST-Stand und erstes Bedarfsgespräch hinzugefügt

docs/Bedarfsanalyse/Bedarfsanalyse-Gespräch-27.08.2026.md

@@ -0,0 +1,44 @@
+Bedarfanalyse Gespräche 27.08.2026 mit Sarah (Perspektivwerk) und Corinna (Produktionsschule)
+
+1) Das technische Umfeld in dem der Kalender genau stattfinden wird, ist noch nicht genau definiert. Es könnte als Komponente in Contao integriert werden, oder als unabhängiges eigenständiges tool mit eigener Runtime, Datenbank(Model) und Backend implementiert werden
+
+2) Damit Besucher ser Seiten Perspektivwerk (PW) und Produktionsschule (PS) nicht verwirrt sind, sollte nur dessen dezidierte Kalenderinstanz angezeigt werden. Kein Umschalten zwischen beiden möglich. Aber technisch sollten beide Kalender von der gleichen technischen Basis ausgeliefert werden.
+
+3) Im Backend soll wärend der Konfiguration des Kalenders eine Demo dessen live angezeigt werden, damit Änderungen ander Konfiguration sofort sichtbar sind.
+
+4) PS: einer der Termintypen heißt Probearbeiten, dieser
+    - 4.1) setzt vorraus das bereits die Einführungsveranstaltung absolviert wurde. Das wird geprüft durch eine entsprechende Checkbox und ein Eingabefeld in dem der Termin der Einführungsveranstaltung eingegeben werden muss.
+    - 4.2) Mehrfachanmeldungen sollen erkannt werden. Dazu wird, wenn Anmeldung bestätigt, der Anmeldename und die Email in einer History gespeichert. In der History kann geschaut werden, ob die Person bereits früher angemeldet war.
+    - 4.3) Das eine Person sich für mehrere Termine angemeldet hat wird in der Bestätigungsmail für einen zu buchenden Termin erwähnt und diese genannt.
+
+5) Alle Prozesse und Funktionen des Kalenders sollen durch technische Tests abgedeckt sein. Zb. Unit-Tests und Integration-tests.
+
+6) Jeder Termin hat eine definierte Auslastung/Kapazität (1-100). Wenn die angegebene Anzahl erreicht ist, wird der Termin als nicht weiter buchbar geführt.
+
+7) Im Kalender ist die Dauer eines Termins klar visuell erkennbar. Termine die nur bis max 4h dauern werden nicht weiter visuell hervorgehoben, aber ist ein Termin länger ist ein sichtbarer Balken für den Termin über den ganzen Tag zu sehen. Und Termine die über mehrere Tage gehen, haben einen sichtbaren Balken der sich über alle Tage ersteckt.
+
+8) Es ist zu prüfen, ob Bestätigungen nicht nur via E-Mail versendet werden können sondern auch via Signal Messanger.
+
+9) In der Terminbuchung soll keine freitext Nachricht ausfüllbar sein, kein entsprechendes Feld existieren.
+
+10) Es soll jeweils für PS und PW einen eigenen abonnierbaren ical Kalender geben, der immer aktuell alle bestätigten Termine enthält. Sobalt ein neuer Termin bestätigt ist, wird der ical Kalender entsprechend aktualisiert.
+
+11) Aktuell ist keine Benutzerverwaltung angedacht. Jeder der den Backend-Link hat, kann Termine eintragen/bearbeiten/löschen.
+
+12) Stornierung von Terminen durch Klienten soll aktuell einfach nur dadurch funktionieren, das diese sich bei der durchführenden Person melden können (Kontakt in Bestätigungsmail enthalten). Diese kann die angemeldete Person dann aus der Veranstaltung löschen.
+
+13) Klienten erhalten zwei Tage vor Beginn der Veranstaltung eine Errinerungsmail
+
+14) Für Klienten soll es einfach möglich sein mehrere Termine nacheinander zu buchen, dazu sollen die eingegebenen Anmeldedaten im Browser gespeicehrt bleiben, und angewendet werden, wenn ein weitere Termin gebucht wird.
+
+15) Ein Termin kann ein vor Ort oder ein Telefonischer Termin sein.
+
+16) BEi der Anmeldung für einen Termin ist die Angabe einer Telefonnummer verbindlich
+
+17) Exportfunktion im Backend: je für PS und PW sollen alle bestätigten Teilnehmer aller Termine eines definierbaren Zeitraums als Liste ausgegeben werden können.
+
+Bekannte Kalender Parameter welche durch Datenbank, Fontend und Backend abgedeckt sein müssen:
+
+- Wird der Kalender des PS oder PW angezeigt
+- historische Teilnehmer an Terminen (name, email, Veranstaltungs-ID)
+- Termindaten: ID, Name, Start, Ende, PS oder PW, Kapazität, Anmeldebedingungen (Einführungsveranstaltung besucht), durchführende Person (Benutzerliste mit Name + Email), Format (vor Ort oder Telefonisch)