Protokoll 12.07.22
Anwesend: Marius, Yannic, Benedikt, Tim, Dennis Dubbert, Uwe Müsse, Dietlind Zühlke, Christian Noss, Simon Porten
Abwesend: Chris
Protokollant: Bene & Tim
Feedback
- Security Aspekte beachten
- Welche Services sollen öffentlcih erreichbar sein
- Welche sind nur intern erreichbar
- wie werden sie geschützt
- Anmerkungen zu vergangenen Buchungen speichern, Bspw. war der Raum für die Veranstaltung geeignet? (Personenbezogen, nicht öffentlich)
- Wie motiviert man die Nutzenden zum einchecken in die Räume?
- Müssen sich alle einchecken? nur studenten? Lehrende die eine Vorlesung halten brauchen das ja eigentlich nicht
- Wie kommuniziert das System, wie mit anderen Services (->Schnittstellen spezifizieren)
- Mit Use-Case! aka: welche infos werden wie und wo verschickt
- Routen definition
- Fokus mehr auf Architektur, als auf Prototypische Umsetzung
- Sequenzdiagramm für einzelen Usecases/Userstorys (wie kommunizieren die Services)
- Schnittstellen der Services spezifizieren (auch mögliche Endpunkte)
- Aussagen aus Interviews zu UseCases/Userstorys hinzufügen, als “Begründung” warum features notwendig
- Interviewer abfragen ob es veröffentlicht werden darf
- Datenhaltung in den einzelnen Services ausmodellieren
- Gouvernance - Wem gehört das Ding, wer ist verantwortlich?
- Sinnvolle Rolleneinteilung / Rollentypen notwendig für ID-Management, als auch Condition-Service
- Brauchen wir den Split von Identity und Condition-Service?
- Welche Conditions sollte es geben
- Kontingente bspw. für Studierende
- Überschreiben bspw. Professoren Studierende
- Darf der Nutzende den Raum überhaupt buchen
- etc.
- Welches ID-Management sollte genutzt werden (GM-ID, Campus-ID, Key-Cloack)
- Ausbaustufen aufstellen, was wird wann in welchem Reifegrad benötigt?
- Entwicklungs-Roadmap
- Alles was aus dem Scope geflogen ist dokumentieren!
- Tasks die nach Projekt 1 noch notwendig sind als Future-Work-List aufstellen