**Projekt Alumnihub**
**Pflichtenheft**
**Inhaltsverzeichnis**
- [Zweck des Dokumentes und Scope](#zweck-des-dokumentes-und-scope)
- [Zweck des Dokumentes](#zweck-des-dokumentes)
- [Scope und Abgrenzung](#scope-und-abgrenzung)
- [Grundlagen](#grundlagen)
- [Verwendete Normen und mitgeltende Dokumente](#verwendete-normen-und-mitgeltende-dokumente)
- [Hardwareanforderungen](#hardwareanforderungen)
- [Allgemeine Anforderunge](#allgemeine-anforderunge)
- [Anforderungen an Server](#anforderungen-an-server)
- [Anforderungen an den Bedienrechner / das mobile Endgerät](#anforderungen-an-den-bedienrechner--das-mobile-endgerät)
- [Anforderungen an das Backup, Recovery und Desaster-Recovery](#anforderungen-an-das-backup-recovery-und-desaster-recovery)
- [Anforderungen an Redundanz und Verfügbarkeit](#anforderungen-an-redundanz-und-verfügbarkeit)
- [Redundanzeigenschaften](#redundanzeigenschaften)
- [Verfügbarkeitsanforderungen](#verfügbarkeitsanforderungen)
- [Schnittstellen](#schnittstellen)
- [Schnittstellen zu eigenen Systemen](#schnittstellen-zu-eigenen-systemen)
- [Schnittstellen zu anderen Systemen](#schnittstellen-zu-anderen-systemen)
- [Anforderungen an die Software](#anforderungen-an-die-software)
- [Allgemeine Anforderungen](#allgemeine-anforderungen)
- [Zugriffsverwaltung](#zugriffsverwaltung)
- [Hall of Fame (Phase 2)](#hall-of-fame-phase-2)
- [Firmen und Jobstellenmarkt (Phase 2)](#firmen-und-jobstellenmarkt-phase-2)
- [Premiumbereich (Phase 2)](#premiumbereich-phase-2)
- [Auswertungen](#auswertungen)
- [Datenschutz \& Informationssicherheit](#datenschutz--informationssicherheit)
- [Schwarzes Brett (Phase 2)](#schwarzes-brett-phase-2)
- [Anmeldetool für Treffen](#anmeldetool-für-treffen)
- [Profilverwaltung](#profilverwaltung)
- [Datenbank](#datenbank)
- [Dokumentation](#dokumentation)
- [Projektdokumentation](#projektdokumentation)
# Zweck des Dokumentes und Scope
## Zweck des Dokumentes
Das Pflichtenheftes umfasst sämtliche Anforderungen und Erwartungen, welche in diesem Projekt umgesetzt werden. Die Aufgaben und Verantwortlichkeiten aller Beteiligten wurden definiert und dies dient als Grundlage für die Projektplanung und -umsetzung. Es stellt sicher, dass alle relevanten Aspekte berücksichtigt werden und dass das Projekt den gewünschten Erfolg bringt.
## Scope und Abgrenzung
Das Pflichtenheft beschreibt, wie die Anforderungen aus dem Lastenheft umgesetzt werden. Ein klar definiertes Pflichtenheft sorgt für Transparenz und klare Erwartungen unter allen Beteiligten. Es minimiert das Risiko von Missverständnissen und hilft, den Projektverlauf reibungslos zu gestalten. Sollten Anforderungen im Lastenheft nicht richtig dokumentiert sein, werden diese im Pflichtenheft in dieser Form weiter bearbeitet.
Dieses Projekt umfasst die Entwicklung der Applikation mit folgenden Funktionen:
- Die Verwaltung von Absolventenprofilen
- Die Organisation von Veranstaltungen
- Die Darstellung der Hall of Fame
- Die Integration eines Firmen- und Jobstellenmarkts
- Die Zugriffsverwaltung
- Die Sicherheit der Daten (DSGVO-konform) sind wesentliche Bestandteile
- Ein Schülerzugang
- Die Integration eines CMS für redaktionelle Beiträge.
Nicht in den Scope fallen die Zahlungsprozesse für den Premiumbereich und externe Lösungen für den Eventkalender (V-Calendar, V-Event).
# Grundlagen
## Verwendete Normen und mitgeltende Dokumente
*Die bestehenden Gesetze und technischen Regelwerke sind zu beachten. Insbesondere sind im Kontext des gegenständlichen Dokumentes die folgenden Normen zu berücksichtigen:*
*Die Applikation muss unter Beachtung der folgenden Normen und rechtlichen Vorgaben entwickelt werden:*
*- DSGVO (Datenschutz-Grundverordnung): Es dürfen nur notwendige personenbezogene Daten gespeichert werden, wie E-Mail, Telefonnummer und Land/Bundesland. Ein Opt-In-Verfahren wird für die Speicherung von Nutzerdaten angewendet, und es muss die Möglichkeit zur Löschung von Einträgen geben (Rückwirkend möglich)*
*- NIS 2 Richtlinie (Netz- und Informationssicherheit); Als digitaler Dienstanbieter müssen Sicherheitsanforderungen eingehalten werden. Besonders die sichere Aufbewahrung und Verwaltung von Nutzerdaten, sowie der Schutz vor Datenverlust sind hier entscheidend.*
*Weitere Bestimmungen, wie die Handhabung der Benutzerrechte und Datenschutzrichtlinien im Zusammenhang mit Drittanbieter-APIs (z. B. LinkedIn-OAuth), müssen ebenfalls geprüft und eingehalten werden.*
# Hardwareanforderungen
## Allgemeine Anforderunge
*Phase 2: Schülerzugang braucht mehr Nutzer…. Zugriffe / Tag steigen auch.*
Um den nachfolgenden Anforderungen gerecht zu werden, nutzen wir:
| Produkt | Preis |
| --- | --- |
| 2* Hetzner CX22 | 3.79€ / Montat / Server |
| Domain (easyname.at) | 35€ / Jahr |
| Mailservice (Brevo) | 0€ / Jahr |
|Anforderung|ID|
| --- | --- |
| **300 aktuellen Nutzern**
Das System muss mindestens 300 aktuelle Benutzer unterstützen, die das System administrieren, bearbeiten und nutzen können. Nicht jeder Benutzer benötigt ein eigenes Profil. | HW-1 |
| **ca. 50 Zugriffe / Tag**
Das System muss in der Lage sein, ca. 50 aktive Benutzer pro Tag (tendenziell steigend) zu unterstützen, ohne dass die Systemleistung beeinträchtigt wird. Die Systemressourcen sollten ausreichend dimensioniert sein, um eine reibungslose und effiziente Nutzung durch die Benutzer zu gewährleisten. | HW-2 |
| **Einfach skalierbar**
Das System muss einfach skaliert werden können, um aufsteigende Anforderungen und Benutzerzahlen reagieren zu können. Dies sollte ohne wesentliche Änderungen an der Systemarchitektur oder -Infrastruktur möglich sein, um eine flexible und kosteneffiziente Anpassung an zukünftige Bedürfnisse zu ermöglichen. | HW-3 |
## Anforderungen an Server
Phase 2: Schülerzugang braucht mehr Nutzer…. Zugriffe / Tag steigen auch.
|Anforderung|ID|
| --- | --- |
| **Die Anwendung wird auf einem Cloud-Server betrieben, der skalierbar ist, um den Anforderungen eines wachsenden Benutzerstamms gerecht zu werden.** | HW-4 |
| **Hochverfügbar: 99.5%**
Damit diese Anforderung auch im Falle eines gröberen Ausfalls eingehalten werden kann, muss es diverse Dokumentation und Anleitungen zum Wiederherstellungsprozesses geben. Es wird ein eigenes Desaster Recovery Handbuch geben. Damit diverse Probleme schnell erkannt werden, wird es ein rudimentäres Logging geben. (Wie viele Requests? Ressourcenverbrauch? Durchschnittliche antwortzeit des Servers...) Sollte einer dieser Werte auffällig weit aus der Norm fallen, wird der Absolventenverein, sowie diese Diplomarbeitsgruppe automatisch benachrichtigt, damit mit untersuchungen / gegenmaßnahmen in angriff genommen.
*Das System muss eine Verfügbarkeit von mindestens 99,5% aufweisen. Dies bedeutet, dass das System innerhalb eines Jahres höchstens 43,8 Stunden (0,5% von 8760 Stunden) nicht verfügbar sein darf.* | HW-5 |
| **.Net Runtime muss unterstützt werden**
Die Anwendung muss die .NET Runtime unterstützen, um eine reibungslose Ausführung von .NET-basierten Anwendungen zu ermöglichen. | HW-6 |
| **Wiederherstellungszeitraum**
Die Wiederherstellung des Servers im Falle eines Ausfalls (des Rechenzentrums) muss innerhalb von **einem Tag** gewährleistet sein. Also nach 24 Stunden muss das System wieder in einen benutzbaren Zustand gebracht werden | HW-7 |
## Anforderungen an den Bedienrechner / das mobile Endgerät
| **Moderner Browser (Chrome, Firefox, Safari und Edge)** | HW-9 |
| --- | --- |
| **JavaScript muss aktiv sein.** | HW-10 |
| **Internetverbindung (5 MBit/s)** | HW-11 |
## Anforderungen an das Backup, Recovery und Desaster-Recovery
| Anforderung | ID |
| --- | --- |
| **Automatisierte Datensicherung**
Zur Erhöhung der Datensicherheit soll über das Komplettsystem eine automatisierte Datensicherung erfolgen. Versionen / Binaries der Anwendungen, Konfigurationsdateien und Nutzerdaten, die Datenbank... Diese Dateien werdenauf einem unbhängigen File Server gelagert. Die Binaries sollen nur bei Updates unserer Software ausgetauscht werden, Konfigurationen bei Änderung erneuert gesichert und die Datenbank mit Nutzerdaten in einem regelmäßigen Zeitfenster. (Vielleicht misbrauchen wir einfach ein Git Repository, das ist vorallem für die Versionierung und Automatisierung dieser Backups sehr gut geeignet) | HW-12 |
| **Dokumentation zum Wiederherstellungsverfahren muss vorhanden sein.**
Schritt für Schritt Anweisungen zum Wiederherstellen des Systems. Skriptgestützte Automatische Wiederherstellung mit einer Dokumentation/Tutorial, um dieses Disaster-Recovery auch ohne Skript durchführen zu können. | HW-13 |
## Anforderungen an Redundanz und Verfügbarkeit
### Redundanzeigenschaften
Redundanzeigenschaften Bespr. Mit Hr. Prof. Gürth
| Anforderung | ID |
| --- | --- |
| **Datenbank und Anwendung muss redundant und gegen Ausfall eines Servers gesichert sein.**
Die Datenbank wird auf beiden Servern repliziert vorhanden sein. Ob das ein warm-standby, hot-standby, oder gar eine Multi-Master Replizierung wird, muss noch entschieden werden. Im Falle eines Ausfalls einer der beiden DBs, soll die andere automatisch zum neuen Master "promoted" werden, wodurch die Anwendung ohne einen groß Merkbaren ausfall direkt weiter ausgeführt werden kann.
Außerdem soll regelmäßig ein Backup von der gesamten Datenbank gemacht werden, welches auf einem unabhängigen File Server/Provider gelagert wird, um im Falle eines Datenverlustes die DB wiederher zu stellen. *
Die Datenbank und die Anwendung müssen redundant und gegen Ausfälle gesichert sein, um Datenverluste und Systemausfälle zu vermeiden. Dies umfasst die Implementierung von:- Datenbankreplikation
- Regelmäßige Backups und Datenwiederherstellung
* | RED-1 |
### Verfügbarkeitsanforderungen
| **99% / Jahr (87.6h)**
Durch eine schnelle Wiederherstellungszeit und klar vorgegebene Disaster Recovery Dokumentation und resilienz in der Architektur des Systems, sowie ein Monitoring und Logging zur frühen Erkennung etwaiger Probleme werden die 99% / Jahr eingehalten werden.
Das System soll weniger als 90 Stunden im Jahr ausfallen. | RED-4 |
| --- | --- |
| **Wiederherstellungszeit: the next business day**
Durch weitgehende automatisierte Skripte soll der Wiederherstellungsprozess vereinfacht werden. Ein Desaster-Recovery Handbuch liegt bei, um den Benutzer schritt für Schritt durch den Wiederherstellungsprozess zu begleiten.
Das System soll bis zum übernächsten Werktag wieder in einen Nutzbaren zustand bringbar sein. | RED-5 |
| | |
## Schnittstellen
### Schnittstellen zu eigenen Systemen
| Anforderung | ID |
| --- | --- |
| RestAPI (Frontend / Backend)
1. Zielsetzung
Die geplante REST API soll in die Oqtane-CMS-Umgebung integriert werden, um eine dynamische Kommunikation zwischen dem CMS und einer Website zu ermöglichen. Sie dient dazu, Inhalte und Funktionen des CMS über die API für die Website verfügbar zu machen und ermöglicht dynamische CRUD-Operationen (Create, Read, Update, Delete) direkt aus dem CMS heraus.
2. Aufgabenbeschreibung
Die Aufgabe umfasst:
Integration in Oqtane: Erweiterung des Oqtane-CMS mit zusätzlichen Modulen und APIs.
Entwicklung der REST API: Bereitstellung von Endpunkten zur Interaktion zwischen CMS-Daten und Website.
Frontend-Integration: Anbindung der Website an die API, um CMS-Inhalte dynamisch darzustellen.
Sicherheitsimplementierung: Absicherung der API und des Datenflusses zwischen CMS und Website.
3. Sicherheitsanforderungen
Authentifizierung:
Verwendung von Oqtane's integriertem Benutzermanagement und JWT für Authentifizierung.
Sicherstellung, dass Benutzerrollen (z. B. Admin, Editor, User) berücksichtigt werden.
Autorisierung:
Zugriff auf Endpunkte wird basierend auf Benutzerrollen gesteuert.
Sensible Aktionen (z. B. Inhalte löschen) nur für berechtigte Benutzer möglich.
Eingabedatenvalidierung:
Eingaben im Frontend und Backend validieren.
API-Schutz:
Schutz gegen CSRF, XSS, und andere Angriffe.
Nutzung von HTTPS.
4. Nicht-funktionale Anforderungen
Performance: Antwortzeiten der API < 300ms für häufige Anfragen.
Kompatibilität: Vollständig kompatibel mit Oqtane-Modulen und Standard-Datenstrukturen.
Skalierbarkeit: Möglichkeit, neue Module und API-Endpunkte ohne größere Umbauten zu integrieren.
Internationalisierung: Unterstützung mehrsprachiger Inhalte.
5. Technische Umsetzung
5.1. Backend (Oqtane CMS)
Framework: ASP.NET Core, integriert in Oqtane.
Architektur:
Erweiterung des Oqtane-CMS durch Module.
Nutzung der Oqtane-Service-API und Datenzugriff über die vorhandene Architektur.
Erstellung benutzerdefinierter APIs mit .Controllers und Abbildung auf Oqtane-Tabellen.
5.2. Frontend
Technologien:
Frontend basiert auf Blazor und HTML
Um die Implementierung kümmert sich weitgehende Oqtane
Darstellung der Inhalte aus Oqtane in dynamischen Komponenten (z. B. Listen, Detailansichten).
API-Integration:
Frontend ruft Inhalte direkt von der REST API ab.
Dynamische Aktualisierung der Inhalte durch Benutzeraktionen (z. B. Formularübermittlung).
5.3. Sicherheit
Authentifizierung:
Authentifizierung über JWT-Token (Login-Endpunkte in Oqtane).
Speicherung von Token im sicheren Speicher (z. B. HttpOnly Cookies).
Eingabeverarbeitung:
Validierung von Daten im Frontend und Backend.
Schutz vor schädlichen Nutzereingaben (z. B. SQL-Injection).
6. Erfolgskriterien
Die Website kann nahtlos mit der Oqtane-REST API interagieren.
Die API erfüllt alle funktionalen Anforderungen und ist in die Oqtane-Datenstruktur integriert.
Sichere und performante Bereitstellung der API.
Modularer Aufbau, der zukünftige Erweiterungen unterstützt.
| SnT-1 |
### Schnittstellen zu anderen Systemen
| Anforderung | ID |
| --- | --- |
| SMTP (Email versand)
1. Zielsetzung
Die Implementierung eines E-Mail-Versands mit der Brevo Gratis-Version in einer C#-Backend-Anwendung ermöglicht das Versenden von E-Mails über den Brevo SMTP-Server. Ziel ist eine zuverlässige, sichere und skalierbare Lösung unter Berücksichtigung des Limits von 300 E-Mails pro Tag.
2. Aufgabenbeschreibung
Konfiguration des Brevo SMTP-Servers: Festlegung von Host, Port, Authentifizierung und Verschlüsselung.
Erstellung von E-Mails: Gestaltung im Text- und HTML-Format.
Integration in die C#-Backend-Anwendung: Nutzung von SMTP-Befehlen.
Fehlerbehandlung und Logging: Protokollierung fehlerhafter E-Mails.
Sicherheit: Schutz der E-Mail-Kommunikation und Verhinderung von Missbrauch.
3. dynamischer Versand
Benachrichtigungs-E-Mails: Willkommens-E-Mails, Passwort-Zurücksetzen, Bestellbestätigungen mit dynamischen Platzhaltern.
Massen-E-Mails: Versand an mehrere Empfänger unter Beachtung des Limits von 300 E-Mails pro Tag.
3.1 Fehler- und Zustellungsmanagement
Protokollierung fehlgeschlagener E-Mails.
Rückmeldung bei erfolgreichem Versand.
Möglichkeit zur Wiederholung fehlgeschlagener E-Mails.
4. Nicht-funktionale Anforderungen
Performance: Versand innerhalb von 3 Sekunden pro Nachricht.
Skalierbarkeit: Planung für ein Upgrade bei höherem Bedarf.
Sicherheit: TLS/SSL-Verschlüsselung und Schutz durch Rate-Limiting.
Kompatibilität: Anzeige von HTML-E-Mails auf verschiedenen Geräten.
5. Technische Umsetzung
5.1. Backend
Framework: ASP.NET Core.
Architektur: Erstellung eines SMTP-Services mit Methoden für den Versand einfacher und komplexer E-Mails mit Anhängen und Templates.
5.2. Sicherheit
Schutz der Zugangsdaten: Nutzung eines Secret Managers oder Umgebungsvariablen.
Rate Limiting: Einhaltung des Tageslimits von 300 E-Mails.
Spam-Prävention: Konfiguration von SPF, DKIM und DMARC.
6. Erfolgskriterien
Alle E-Mails werden zuverlässig und sicher über Brevo versendet.
Personalisierte Nachrichten und Anhänge werden korrekt verarbeitet.
Robuster Versandprozess mit Fehlerhandling und Schutz vor Missbrauch.
| SnT-2 |
| LinkedÌn OAuth (Phase 2, oder später)
Backend zu LinkedIn
1. Zielsetzung
Implementierung von LinkedIn OAuth 2.0 für die Authentifizierung und den Abruf von Profildaten in der C#-Backend-Anwendung.
2. Anforderungen
Registrierung der App im LinkedIn Developer Portal.
OAuth 2.0 Authentifizierungsablauf:
Weiterleitung zur LinkedIn-Login-Seite.
Empfang des Autorisierungscodes.
Austausch des Codes gegen ein Zugriffstoken.
Abruf von Benutzerinformationen (Vorname, Nachname, E-Mail).
Sicheres Token-Management (kein Speichern von Zugangsdaten in der Datenbank).
3. Technische Umsetzung
Backend: ASP.NET Core
API-Endpunkte:
/auth/linkedin (Weiterleitung zur LinkedIn-Login-Seite).
/auth/linkedin/callback (Empfang des Codes).
/api/user/profile (Abruf von LinkedIn-Daten mit Token).
Sicherheit:
Nutzung von HTTPS und PKCE.
Speicherung von Tokens nur im Cache (z. B. Redis).
Einschränkung der API-Berechtigungen (r_liteprofile, r_emailaddress).
4. Erfolgskriterien
Benutzer können sich sicher über LinkedIn anmelden.
Zugriffstoken werden sicher verarbeitet.
API-Datenabruf funktioniert zuverlässig.
| SnT-3 |
# Anforderungen an die Software
## Allgemeine Anforderungen
| Anforderung | ID |
| --- | --- |
| Die Website oder Webanwendung wird so entwickelt, dass sie in den aktuellen und vorherigen Versionen der gängigsten Webbrowser einwandfrei funktioniert: Google Chrome (Desktop und Mobile)
Mozilla Firefox (Desktop und Mobile)
Safari (macOS und iOS)
Microsoft Edge (Chromium-basiert)
1. Programmiersprachen und Standards:
-Die Entwicklung erfolgt auf Basis moderner Technologien wie HTML5, CSS3 für eine plattformübergreifende Funktionalität.
2. Frameworks und Bibliotheken:
-Blazor| SW-1 |
| Barrierefreiheit (WAI-ARIA-Standard) ...
1. Verwendung von ARIA-Attributen:
-Semantik und Bedienbarkeit durch role, aria-label, aria-expanded, aria-live etc. verbessern.
-Dynamische Inhalte und interaktive Elemente mit Attributen wie aria-controls oder aria-describedby ausstatten.
2. Technologien und Tools:
-CSS: Oqtane
3. Tastaturbedienbarkeit und Kontraste:
-Sicherstellen, dass alle Inhalte per Tastatur erreichbar sind.
-Einhalten der Kontrastvorgaben gemäß WCAG 2.1 Stufe AA.
| SW-2 |
| **CMS**:
-Das System soll einen redaktionellen Schülerzugagng bieten, damit die Diplomarbeiten von Schülern selbst eingepflegt werden können.
-Entwicklung geschieht in Themes und Modules
Technologien und Tools:
-Oqtane| SW-3 |
| **Sicherheit und administrativer Zugriff:**
Der Administrative zugriff auf das System geschieht über eine SSH Verbindung, welche nur duch eine VPN (Wireguard) aufgebaut werden kann. Die Authentifizierung (der VPN und SSH) wird über Schlüsselpaare gemacht, um sicherer gegenüber bruteforce Angriffe zu sein.
Der Zugriff auf die Anwendung und die Infrastruktur muss jederzeit gegeben sein. Dies kann durch die Implementierung von:
- SSH-Zugriff für Administratoren
- VPN-Verbindung (Virtual Private Network) für eine sichere und verschlüsselte Verbindung
- Zugriffskontrolle und Authentifizierung, um den Zugriff auf autorisierte Personen zu beschränken
erreicht werden. | SW-4 |
## Zugriffsverwaltung
| Anforderung | ID |
| --- | --- |
| **Benutzername und Passwort Authentifizierung**:
**Im Frontend**:
**Beschreibung**:
Die Benutzername- und Passwort-Authentifizierung ermöglicht es Nutzern, sich in einer Anwendung zu identifizieren, indem sie ihre Anmeldedaten über ein Formular eingeben. Das Frontend sendet die Daten sicher an das Backend, das die Authentifizierung übernimmt. Bei erfolgreicher Anmeldung erhält der Nutzer Zugriff auf geschützte Bereiche der Anwendung.
**Benötigte Komponenten**: Login-Formular sie enthält Eingabefelder für Benutzername und Passwort sowie einen Login-Button. API-Service dieser sendet die Anmeldedaten sicher an das Backend und verarbeitet die Antwort. Token-Speicherung & Weiterleitung sie speichert das Authentifizierungstoken und leitet den Nutzer nach erfolgreicher Anmeldung weiter.
**Backend:**
Überprüfung der empfangenen Anmeldedaten: Zunächst wird nach vorhandenen Benutzernamen gesucht.
Passwortüberprüfung: Anschließend wird das eingegebene Passwort mit den Daten in der Datenbank verglichen. | ZUG-1 |
| **Passwort zurücksetzen**:
**Im Frontend**:
**Beschreibung**:
Die Passwort-Zurücksetzen-Funktion im Frontend ermöglicht es Benutzern, über eine Benutzeroberfläche einen Token-basierten Prozess zur Passwortänderung zu starten.
**Benötigte Komponenten**: Eingabefeld für die E-Mail-Adresse Formular zur Eingabe des neuen Passworts nach Token-Bestätigung Fehler- und Erfolgsmeldungen zur Benutzerführung
Backend:
Passwortreset-Funktion: Benutzer können ihre E-Mail-Adresse eingeben, um einen Passwortreset anzufordern.E-Mail-Versand: Die Anwendung sendet einen Link mit einem einmaligen, zeitlich begrenzten Token an die angegebene E-Mail-Adresse.Sicherheitsanforderungen: Der Token muss sicher generiert werden, und der Link darf keine sensiblen Informationen enthalten.Benutzeroberfläche: Die Oberfläche für den Passwortreset muss benutzerfreundlich sein und eine Bestätigung anzeigen.Datenbankoperationen: Der neue Passwort-Hash wird in der Datenbank gespeichert und überschreibt den alten Eintrag.Fehlerbehandlung: Geeignete Fehlermeldungen müssen angezeigt werden, wenn die E-Mail nicht registriert ist oder der Token abgelaufen ist.Protokollierung: Alle Passwortreset-Anfragen müssen protokolliert werden.
| ZUG-2 |
| **Rollen**:
**Im Frontend**:
**Beschreibung**:
Die Implementierung von Rollen im Frontend dient der Steuerung von Benutzerzugriffen und Funktionen basierend auf deren Berechtigungen. Rollen legen fest, welche Inhalte und Aktionen für bestimmte Benutzergruppen sichtbar oder ausführbar sind.
**Benötigte Komponenten**: Rollenbasierte Navigation Zugriffskontroll-Guard UI-Elemente basierend auf Benutzerrolle
Backend:
Rollendefinition:Definieren von Rollen (z.B. Administrator, Benutzer, Gast) mit spezifischen Berechtigungen.Datenbankstruktur:Entwurf einer Datenbanktabelle zur Speicherung von Rollen und deren Berechtigungen.Rollenvergabe:Implementierung von Funktionen zur Zuweisung und Entziehung von Rollen an Benutzer im Backend.Berechtigungsprüfung:Entwicklung einer Middleware oder Funktion, die bei jeder Anfrage überprüft, ob der Benutzer die erforderlichen Berechtigungen für die angeforderte Aktion hat.Sicherheitsanforderungen:Sicherstellen, dass nur autorisierte Benutzer (z.B. Administratoren) Rollen ändern oder zuweisen können.Protokollierung:Implementierung von Protokollierungsmechanismen für Änderungen an Rollen und Berechtigungen zur Nachverfolgbarkeit.
| ZUG-3 |
| **Benutzerverwaltung (für Admins)**:
**Im Frontend**:
**Beschreibung**:
Die Benutzerverwaltung erlaubt Administratoren, Benutzerkonten zu verwalten, einschließlich Erstellung, Bearbeitung, Aktivierung/Deaktivierung und Löschung von Benutzern sowie Zuweisung von Rollen und Berechtigungen.
**Benötigte Komponenten**: Liste der Benutzer mit Rollen und Status Buttons zum Bearbeiten und Löschen von Benutzern Such- und Filterfunktionen für Benutzer
Backend:
Datenbankoperationen:Alle Änderungen, die über die Weboberfläche im Admin-Bereich vorgenommen werden, müssen über definierte Backend-API-Endpunkte in der Datenbank gespeichert werden.Zugriffssteuerung:Implementierung einer strengen Zugriffssteuerung, die sicherstellt, dass nur autorisierte Benutzer (z.B. Administratoren) Änderungen vornehmen können.Berechtigungsprüfung:Vor jeder Datenbankoperation muss eine Überprüfung der Benutzerrollen und -berechtigungen erfolgen, um sicherzustellen, dass der Benutzer die erforderlichen Rechte hat.Validierung der Eingaben:Alle Eingaben, die über die Weboberfläche an das Backend gesendet werden, müssen validiert werden, um sicherzustellen, dass sie den erwarteten Formaten und Werten entsprechen.Protokollierung von Änderungen:Alle Änderungen, die im Admin-Bereich vorgenommen werden, müssen protokolliert werden, um eine Nachverfolgbarkeit und Auditierung zu ermöglichen.Sicherheitsmaßnahmen:Implementierung von Sicherheitsmaßnahmen wie Rate Limiting und IP-Whitelisting, um unbefugte Zugriffe zu verhindern.Fehlerbehandlung:Bereitstellung von klaren Fehlermeldungen und Handhabung von unerwarteten Situationen, um die Integrität der Daten zu gewährleisten.
| ZUG-4 |
| **Einladung an die EDU-Adresse (Phase 2)**:
**Im Frontend**:
**Beschreibung**:
In Phase 2 wird die Möglichkeit geschaffen, Benutzern eine Einladung zur Registrierung oder Teilnahme über eine EDU-E-Mail-Adresse zu senden. Diese Einladung erfolgt in Form einer E-Mail, die den Benutzer zur Anmeldung auf der Plattform einlädt.
**Benötigte Komponenten**: Eingabefeld für die EDU-E-Mail-Adresse Button zum Versenden der Einladung Bestätigungs- und Fehlermeldungen für den Versand
Backend:
Einladungserstellung:Implementierung einer Funktion zur Erstellung einer Einladung, die alle erforderlichen Informationen (z.B. Empfänger, Betreff, Nachricht, Datum, Uhrzeit) erfasst.Datenbankintegration: Speichern der Einladung in der Datenbank, einschließlich aller relevanten Details und des Status (z.B. erstellt, versendet).E-Mail-Vorlage:Erstellung einer E-Mail-Vorlage, die die Einladung in einem ansprechenden Format darstellt.E-Mail-Versand:Implementierung einer Funktion, die die Einladung per E-Mail an den vorgesehenen Empfänger sendet, einschließlich der Verwendung eines E-Mail-Dienstes (z.B. SMTP-Server)Berechtigungsprüfung:Sicherstellen, dass nur autorisierte Benutzer (z.B. Administratoren) Einladungen erstellen und versenden können.Fehlerbehandlung:Implementierung von Mechanismen zur Fehlerbehandlung, um sicherzustellen, dass der Benutzer über den Erfolg oder das Scheitern des E-Mail-Versands informiert wird Protokollierung:Protokollierung aller Einladungen, die erstellt und versendet wurden, um eine Nachverfolgbarkeit zu gewährleisten.Eingabever validation:Validierung der Eingaben (z.B. E-Mail-Adresse, Datum) vor der Erstellung und dem Versand der Einladung, um sicherzustellen, dass sie korrekt sind.
| ZUG-5 |
| **Magic Link Authentifizierung**:
**Im Frontend**:
**Beschreibung**:
Die Magic Link Authentifizierung ermöglicht es Benutzern, sich ohne Passwort anzumelden, indem sie auf einen Link klicken, der ihnen per E-Mail zugeschickt wird. Dieser Link ist temporär und führt den Benutzer direkt zur Anwendung, wenn er gültig ist.
**Benötigte Komponenten**: Eingabefeld für die EDU-E-Mail-Adresse Button zum Anfordern des Magic Links Weiterleitung zur Bestätigungsseite nach Klick auf den Magic Link
Backend:
Benutzerregistrierung:Implementierung einer Funktion zur Registrierung potenzieller Benutzer, die ihre E-Mail-Adresse und andere erforderliche Informationen erfasst.E-Mail-Versand:Nach der Registrierung muss eine E-Mail an die angegebene Adresse gesendet werden, die einen Authentifizierungslink enthält.Link-Generierung:Der Authentifizierungslink muss einen einmaligen, kryptografisch sicheren Token enthalten, der mit dem Benutzerkonto verknüpft ist undeine begrenzte Gültigkeitsdauer hat (z.B. 24 Stunden).Datenbankeintrag:Der Token und der Status der Authentifizierung müssen in der Datenbank gespeichert werden, um die Gültigkeit des Links zu überprüfen.Link-Verifizierung:Implementierung einer Funktion, die den Token überprüft, wenn der Benutzer auf den Link klickt, um sicherzustellen, dass er gültig und nicht abgelaufen ist.Benutzeraktivierung:Nach erfolgreicher Verifizierung des Tokens muss das Benutzerkonto aktiviert werden, und der Benutzer sollte auf eine Bestätigungsseite weitergeleitet werden.Fehlerbehandlung:Bereitstellung von klaren Fehlermeldungen, wenn der Token ungültig oder abgelaufen ist, und gegebenenfalls die Möglichkeit zur erneuten Anforderung des Authentifizierungslinks.Protokollierung:Protokollierung aller Authentifizierungsanfragen und -versuche, um eine Nachverfolgbarkeit zu gewährleisten.
| ZUG-6|
| **2FA Authentifizierung (Phase 2)**:
**Im Frontend**:
**Beschreibung**:
In Phase 2 wird die Zwei-Faktor-Authentifizierung (2FA) implementiert, um die Sicherheit des Benutzerkontos zu erhöhen. Nach der Eingabe des Benutzernamens und Passworts wird ein zweiter Authentifizierungsfaktor benötigt, wie ein einmaliger Code, der an das Handy des Benutzers gesendet wird.
**Benötigte Komponenten**: Eingabefeld für den OTP (One-Time-Password) Button zur Bestätigung des OTPs Fehler- und Erfolgsmeldungen für die OTP-Verifizierung
Backend:
Anmeldedatenüberprüfung:Nach der Eingabe der Anmeldedaten (Benutzername und Passwort) muss das System die Anmeldedaten validieren und überprüfen.Code-Generierung:Implementierung einer Funktion zur Generierung eines zeitlich begrenzten Codes (z.B. TOTP - Time-based One-Time Password), der auf einem anderen Gerät (z.B. Smartphone) generiert wird.Code-Übermittlung:Der generierte Code muss über eine sichere Kommunikationsoberfläche (z.B. Push-Benachrichtigung, SMS oder E-Mail) an den Benutzer gesendet werden.Benutzereingabe:Der Benutzer muss die Möglichkeit haben, den erhaltenen Code in die Anmeldemaske einzugeben, um seine Identität zu bestätigen.Code-Überprüfung:Implementierung einer Funktion zur Überprüfung des eingegebenen Codes gegen den generierten Code, um sicherzustellen, dass er korrekt und innerhalb der Gültigkeitsdauer ist.Fehlerbehandlung:Bereitstellung von klaren Fehlermeldungen, wenn der eingegebene Code ungültig oder abgelaufen ist, sowie die Möglichkeit, einen neuen Code anzufordern.Sicherheitsanforderungen:Sicherstellen, dass die Kommunikation zwischen dem Server und dem Gerät des Benutzers sicher ist (z.B. durch Verschlüsselung).Protokollierung:Protokollierung aller Anmeldeversuche und der Verwendung von Codes zur Nachverfolgbarkeit und zur Erkennung von potenziellen Sicherheitsvorfällen. | ZUG-7|
| **OAuth (Phase 2)**:
**Im Frontend**:
**Beschreibung**:
In Phase 2 wird die OAuth-Authentifizierung implementiert, die es Benutzern ermöglicht, sich über Drittanbieter wie Google, Facebook oder andere Plattformen anzumelden. Dabei wird der Benutzer direkt zu einer externen OAuth-Plattform weitergeleitet, um sich zu authentifizieren, und anschließend wieder zurück zur Anwendung.
**Benötigte Komponenten**: Button für die Auswahl des OAuth-Anbieters (z. B. Google, Facebook) Weiterleitung zur OAuth-Anmeldeseite des Anbieters Empfang und Verarbeitung des Tokens nach erfolgreicher Anmeldung
Backend:
OAuth 2.0 Integration:Implementierung des OAuth 2.0-Protokolls zur Authentifizierung über LinkedIn. Dies umfasst die Registrierung der Anwendung bei LinkedIn und den Erhalt der erforderlichen Client-ID und Client-Secret.Benutzeranmeldung:Bereitstellung eines Endpunkts, über den Benutzer sich mit ihrem LinkedIn-Account anmelden können. Dies sollte einen Redirect zurLinkedIn-Login-Seite und die anschließende Rückleitung zur eigenen Anwendung nach erfolgreicher Authentifizierung umfassen.Token-Verwaltung:Nach erfolgreicher Authentifizierung muss das Backend den von LinkedIn erhaltenen Access-Token speichern, um zukünftige Anfragen an die LinkedIn-API zu ermöglichen.Mapping von LinkedIn-Accounts:Implementierung einer Datenbanktabelle, die das Mapping zwischen LinkedIn-Accounts (z.B. LinkedIn-ID) und den internen Benutzerkonten in der eigenen Anwendung speichert.Profilabgleich (Zukünftige Ausbaustufe):In einer späteren Phase sollte eine Funktion implementiert werden, die es ermöglicht, das LinkedIn-Profil des Benutzers abzurufen und mit dem eigenen Benutzerprofil abzugleichen. Dies könnte Informationen wie Name, E-Mail-Adresse, Berufserfahrung und Fähigkeiten umfassen.Sicherheitsanforderungen:Sicherstellen, dass alle Daten, die von LinkedIn abgerufen werden, sicher gespeichert und verarbeitet werden, um die Privatsphäre der Benutzer zu schützen.Fehlerbehandlung:Implementierung von Mechanismen zur Fehlerbehandlung, um mit möglichen Problemen bei der Authentifizierung oder beim Abrufen von Daten von LinkedIn umzugehen.Protokollierung:Protokollierung aller Authentifizierungsversuche und der zugehörigen LinkedIn-Daten, um eine Nachverfolgbarkeit und Analyse von Anmeldeaktivitäten zu ermöglichen. | ZUG-8 |
## Hall of Fame (Phase 2)
| Anforderung | ID |
| --- | --- |
| **PDF-Generierung**
Das System muss eine PDF-Generierung im Frontend der Hall of Fame für Treffen ermöglichen. Nutzer sollen ihre persönlichen Erfolge in einem ansprechenden Dokument festhalten können. Jedes PDF soll ein Bild der Person sowie eine Übersicht über ihre Schullaufbahn, berufliche Stationen und besondere Leistungen enthalten. Diese Dokumente sollen anschließend ausgedruckt und zur Präsentation verwendet werden können. | HoF-1 |
| **Online Hall of Fame**
Das System muss eine Online Hall of Fame im Frontend bereitstellen, die es Nutzern ermöglicht, ihre Erfolge und besonderen Leistungen zu präsentieren. Diese Plattform soll eine ansprechende und motivierende Darstellung von Nutzerbeiträgen bieten, sodass herausragende Leistungen sichtbar gemacht und gewürdigt werden können. | HoF-2 |
| **OptIn Modell für Benutzer**
Das System muss ein Opt-In-Modell im Frontend der Hall of Fame für Treffen bereitstellen, das es Nutzern ermöglicht, aktiv zu entscheiden, ob sie in die Ruhmeshalle aufgenommen werden möchten. Durch eine einfache Zustimmung können Nutzer ihre Erfolge und Beiträge sichtbar machen, während sie gleichzeitig die Kontrolle über ihre Daten behalten und sicherstellen, dass nur die gewünschten Informationen geteilt werden. | HoF-3 |
| **Löschantrag**
Das Frontend stellt eine intuitive Oberfläche bereit, über die Nutzer Löschanträge für ihre Einträge oder bestimmte Informationen stellen können. Die Funktion ist leicht zugänglich, responsiv und informiert den Nutzer über den Status des Antrags.| HoF-4 |
## Firmen und Jobstellenmarkt (Phase 2)
**Präzisierung im laufe des Projektes**
| Anforderung | ID |
| --- | --- |
| **Agenturschnittstellen (API & GUI)**
-Bereitstellung von APIs (JSON)
-GUI mit Dashboard Benutzerrollen und Statistiken (responsive Design) | JOB-1 |
| **Job / Mitarbeiterbörse / Praktikabörse**
-Plattform für Stellenangebote, Bewerberprofile und Praktika mit Such- und Filterfunktionen
-Benutzerrollen (Arbeitgeber, Arbeitnehmer, Administratoren) und Bewerbungsmanagement | JOB-2 |
| **Privatsphäreeinstellungen (Opt-In)**
-DSGVO-konformes Opt-In-System für Datenverarbeitung, Protokollierung und Widerruf
-Sichtbarkeitsoptionen für Profile und Einbindung von Datenschutzeinstellungen | JOB-3 |
## Premiumbereich (Phase 2)
| Anforderung | ID |
| --- | --- |
| Verwaltung der Premiumkunden 1. Benutzerverwaltung:
- Identifikation der Premiumkunden.
-Erstellung und Verwaltung individueller Kundenprofile.
2. Serviceverwaltung:
-Bereitstellung maßgeschneiderter Dienstleistungen und Angebote| PRE-1 |
| Ingenieurantrag
-Der Ingenieurantrag umfasst ledeglich die Einsicht in andere Ingenieuranträge, welche in der Vergangenheit durch gegangen sind.| PRE-2 |
| Matura & Klassentreffen organisieren
-Umfasst das Versenden von Einladungen per Email
Technologien und Komponenten:
-Brevo: Zum Versenden von Einladungen. | PRE-3 |
## Auswertungen
Mehr Prosa (Unterscheidung Phase 1 & 2)
| Anforderung | ID |
| --- | --- |
| **Dashboard**
Frontend:
Anforderung:
Das Frontend der Webanwendung stellt ein Dashboard bereit, das sicherheitsrelevante Informationen übersichtlich darstellt. Es ermöglicht dem Benutzer, Anmeldeaktivitäten einzusehen, Sicherheitsfunktionen zu verwalten und Benachrichtigungen zu neuen Login-Versuchen zu erhalten. Die Benutzerfreundlichkeit, Transparenz und Barrierefreiheit stehen hierbei im Fokus.
Funktionale Anforderungen
Das Dashboard zeigt eine Liste der letzten Anmeldeaktivitäten mit folgenden Details:
Datum und Uhrzeit
Verwendetes Gerät/Browser
Das Dashboard bietet direkte Zugriffsmöglichkeiten auf sicherheitsrelevante Funktionen:
Änderung des Passworts
Aktivierung/Deaktivierung der Zwei-Faktor-Authentifizierung (2FA) (Phase 2)
Verwaltung aktiver Sitzungen mit der Möglichkeit, einzelne Sitzungen zu beenden
Anzeige und Verwaltung vertrauenswürdiger Geräte
Die Darstellung erfolgt in einer übersichtlichen und leicht verständlichen Struktur:
Sicherheitsoptionen sind intuitiv erreichbar und mit kurzen Erklärungen versehen.
Das Design ist responsive und für Desktop, Tablet und mobile Endgeräte optimiert.
Das Dashboard erfüllt Barrierefreiheitsstandards und unterstützt Screenreader sowie Tastatur-Navigation:
Visuelle Warnhinweise zu sicherheitsrelevanten Ereignissen werden durch alternative Texte und Symbole ergänzt.
Akzeptanzkriterien
Die letzten Anmeldeaktivitäten werden vollständig und korrekt angezeigt.
Sicherheitsfunktionen wie Passwortänderung, 2FA-Verwaltung (Phase 2) sind direkt zugänglich und funktional.
Das Dashboard ist auf verschiedenen Geräten benutzerfreundlich und barrierefrei bedienbar.
Backend:
Datenintegration: Abruf und Aggregation von Systemdaten wie Nutzeraktivität, Serverstatus und Verkaufszahlen in Echtzeit. Datenvisualisierung: Darstellung der KPIs in klaren und verständlichen Diagrammen und Tabellen zur schnellen Analyse und Entscheidungsfindung. Benutzeroberfläche: Entwicklung einer übersichtlichen und interaktiven Dashboard-Oberfläche, die eine einfache Navigation und detaillierte Auswertungen ermöglicht. Zugriffsrechte: Implementierung von Berechtigungen, um sicherzustellen, dass nur autorisierte Benutzer auf spezifische Dashboard-Daten zugreifen können. Leistung und Skalierbarkeit: Verwendung von performanten Datenbanken und effizienten Algorithmen zur schnellen Verarbeitung und Darstellung großer Datenmengen. Echtzeit-Daten: Sicherstellung der kontinuierlichen Aktualisierung und Anzeige von Echtzeit-Daten für aktuelle Systemauswertungen. Sicherheit: Gewährleistung der Sicherheit durch Verschlüsselung der Datenübertragung und Schutz vor unbefugtem Zugriff. | AUS-1 |
| Auswertungen erstellen
Frontend:
Das System muss präzise Analysen der Anmeldedaten ermöglichen. Dazu gehören die Erfassung und Auswertung der Login-Häufigkeit, die Identifikation verdächtiger Aktivitäten sowie die Bereitstellung von Einblicken in das Nutzerverhalten. Die Ergebnisse sollen in einer übersichtlichen und interaktiven Darstellung visualisiert werden, um eine optimierte Sicherheitsstrategie zu unterstützen.
Backend:
Datenstrukturierung: Erfassung und Strukturierung der Rohdaten, um die Grundlage für präzise Auswertungen zu bilden. Filter und Algorithmen: Entwicklung und Implementierung von Filtern und Algorithmen zur Berechnung der relevanten KPIs. Datenvisualisierung: Darstellung der Auswertungsergebnisse in klaren Diagrammen und Tabellen zur einfachen Analyse. Zugriffsrechte: Sicherstellung, dass nur berechtigte Benutzer auf die Auswertungsdaten zugreifen können. Datenbankleistung: Nutzung einer performanten Datenbank, die schnelle Datenabfragen und Analysen ermöglicht. Echtzeit-Verarbeitung: Implementierung von Mechanismen zur schnellen Verarbeitung und Analyse von Daten in Echtzeit. Sicherheit: Sicherstellung der Datensicherheit durch Verschlüsselung und Schutz vor unbefugtem Zugriff. | AUS-2 |
| Auswertugnen erstellen 2 (Phase 2)
Frontend:
Das System muss detaillierte Analysen zu Login-Standorten und verwendeten Geräten bereitstellen. Es soll ermöglichen, Zeiträume mit der höchsten Anmeldeaktivität zu identifizieren und potenzielle Sicherheitslücken durch den Vergleich von Nutzeraktivitäten aufzudecken. Zusätzlich müssen detaillierte Statistiken zu fehlgeschlagenen Login-Versuchen sowie häufig genutzten Wiederherstellungsfunktionen erfasst und visualisiert werden, um gezielte Sicherheitsmaßnahmen abzuleiten.
Backend:
Datenquellen: Sicherstellung zuverlässiger und aktueller Datenquellen zur Grundlage der Auswertungen. Filter und Algorithmen: Entwicklung und Anwendung von Filtern sowie Algorithmen zur Berechnung relevanter Metriken und KPIs. Datenbank: Nutzung einer performanten und skalierbaren Datenbank für schnelle Datenverarbeitung und -abfragen. Visualisierung: Integration von Visualisierungstools, die die berechneten Metriken in übersichtliche Diagramme und Tabellen umwandeln. Zugriffsrechte: Implementierung von Zugriffssteuerungen, die den Datenzugriff nur für autorisierte Benutzer ermöglichen. Analysebasis: Gewährleistung einer präzisen, schnellen und sicheren Analyse durch effiziente Datenverarbeitung und -visualisierung. Sicherheit: Sicherstellung der Datenintegrität und des Schutzes vor unbefugtem Zugriff oder Manipulation. | AUS-3 |
| Chart generierung (Phase 2)
Frontend:
Das System muss eine visuelle Aufbereitung der Anmeldedaten in Form von Charts ermöglichen. Dies umfasst die Darstellung von Login-Zeiten, regionalen Verteilungen sowie der Anzahl erfolgreicher und fehlgeschlagener Anmeldeversuche. Die Visualisierungen sollen eine schnelle Analyse der Nutzeraktivitäten ermöglichen und Trends auf einen Blick erkennbar machen.
Backend:
Datenquelle und Filter: Kontinuierliches Laden und Filtern von Rohdaten aus zuverlässigen Quellen zur Vorbereitung der Chart-Generierung. Datenaggregation: Entwicklung von Algorithmen, die die gefilterten Rohdaten aggregieren und für die Visualisierung aufbereiten.Charting-Bibliothek: Integration einer Charting-Bibliothek zur Erstellung von Diagrammen (Balken-, Linien- oder Kreisdiagramme) aus den aggregierten Daten.
Caching: Implementierung von Caching-Mechanismen, um die Geschwindigkeit der Datenverarbeitung und Chart-Darstellung zu optimieren.
Zugriffsrechte: Sicherstellung, dass nur autorisierte Benutzer auf die generierten Charts zugreifen können. Datenvisualisierung: Bereitstellung von klaren, leicht verständlichen Diagrammen zur Unterstützung schneller Entscheidungen. Sicherheit: Schutz der Daten durch Verschlüsselung und Zugriffskontrollen, um die Integrität und Vertraulichkeit zu gewährleisten. | AUS-4 |
## Datenschutz & Informationssicherheit
| Anforderung | ID |
| --- | --- |
| **DSGVO-Konform**
Dass man die Anforderungen der Datenschutz-Grundverordnung (DSGVO) der Europäischen Union erfüllt. Die DSGVO ist eine Verordnung, die darauf abzielt, den Schutz personenbezogener Daten zu stärken und die Kontrolle über die Verwendung und Verarbeitung solcher Daten zurück in die Hände der betroffenen Personen zu legen. | DSc-1 |
| **Informationssicherheit**
Bezeichnet den Schutz von Informationen vor verschiedenen Bedrohungen, um deren Vertraulichkeit, Integrität und Verfügbarkeit zu gewährleisten. Ziel ist es, dass Daten vor unbefugtem Zugriff, Verlust, Missbrauch oder Zerstörung geschützt sind. Alle Daten müssen im Backend geschützt werden. (Serverseitige validierung jedes Requests...) | DSc-2 |
## Schwarzes Brett (Phase 2)
| Anforderung | ID |
| --- | --- |
| **Feed**
Es muss ein Interface / eine Schnittstelle für alle Elemente, welche am Schwarzen Brett auftauchen geschaffen werden. Dann muss eine API Route für das Abrufen der einzelnen Einträge geschaffen werden. Die gesammte Entwicklung wird in einem Oqtane Modul geschehen. Der Feed priorisiert die Posts vom Absolventenverein und muss die Sichtbarkeitsstufe des Posts berücksichtigen.
Eine Seite auf den Mitteilungen und Ankündigungen gemacht werden. Hier kann man Events anzeigen lassen, Posts anderer Mitglieder usw. | ScB-1 |
| **Posten**
Es wird eine neue API Route in dem Modul implementiert, die es ermöglicht eigene Einträge auf dem schwarzen Brett zu posten. Hierfür braucht man nichts wirklich ausgefallenes.
Jeder darf posten, solange ihm in der Vergangenheit dieses Privileg nicht weggenommen wurde. Diese Posts werden dann in dem Feed angezeigt. Ein Post kann eine Sichbarkeitsstufe haben (standardmäßig: öffentlich = jeder angemeldete Benutzer) | ScB-2 |
| **Werbung**
Um Werbung auf dem schwarzen Brett anbieten zu können, muss mitgezählt werden, welche Posts geladen / gesehen worden sind. Es wird auch eine "Abrechnungsseite" geben, auf der die Kosten Vorgerechnet werden. Um die Abrechnung muss sich der Absolventen Verein selber kümmern.
Firmen können Job Inserate schalten, Diplomarbeitskooperationen anbieten usw. Wir stellen die Schnittstelle für diese Firmen bereit, aber um die Abrechnung muss sich gesondert jemand anderer kümmern | ScB-3 |
| **Meldungsvorgang**
Es werden neue Knöpfe bei den Posts hinzugefügt, mit denen man einen Post melden kann. Optional mit Angabe eines Grundes. Dieser Post wird sofort offline genommen und dann zur Durchsicht von Seiten des Absolventenvereins markiert. Je nach dem, was der AV dann Beschließt, wird dem Benutzer dann das Recht auf Posten entzogen.
Man kann unangemessene Inhalte melden, diese Meldungen werden dann von Hand durchgeschaut, ob diese den Regeln widersprechen, und kann dem Benutzer über eine Rollenänderung das Privileg des Postens / Interagieren mit anderen Nutzern auf der Seite entfernt werden. | ScB-4 |
## Anmeldetool für Treffen
| Anforderung | ID |
| --- | --- |
| Event erstellen
Frontend:
Das Frontend ermöglicht Absolventen die Erstellung und Verwaltung von Treffen durch ein Eingabeformular für Event-Details, eine Teilnehmerverwaltung mit Einladungsfunktion sowie eine übersichtliche Event-Liste mit Bearbeitungsoptionen. Benachrichtigungen über Änderungen und ein responsives Design sorgen für eine nutzerfreundliche Bedienung.
Backend:
Eingabemaske: Entwicklung einer benutzerfreundlichen Maske zur Erstellung und Bearbeitung von Eventdaten, einschließlich relevanter Felder wie Titel, Datum, Zeit und Beschreibung. Datenbank: Einrichtung einer Datenbank zur sicheren Speicherung aller Eventdaten und ihrer zugehörigen Informationen. Verwaltung von Anmeldungen: Implementierung von Algorithmen zur Erfassung, Verwaltung und Nachverfolgung von Teilnehmeranmeldungen. Zugriffsrechte: Sicherstellung, dass nur autorisierte Benutzer Events erstellen oder bearbeiten können. Automatische Bestätigungen: Einrichtung eines Systems zur automatischen Versendung von Bestätigungen an Teilnehmer nach erfolgreicher Anmeldung.Benutzerfreundlichkeit: Gestaltung der Oberfläche und Funktionen so, dass Benutzer Events effizient und fehlerfrei erstellen und verwalten können. | AfT-1 |
| Einladungen verschicken
Frontend:
Das System ermöglicht die Erstellung und Verwaltung von Events. Administratoren können Events anlegen, Teilnehmer sich anmelden und Benachrichtigungen erhalten. Alle Events und Anmeldungen werden protokolliert.
Backend:
Datenabruf: Entwicklung einer Funktion zum Abrufen der relevanten Eventdaten aus der Datenbank. Personalisierung: Erstellung von personalisierten Einladungstexten basierend auf Event- und Teilnehmerdaten. Nachrichtentransport: Integration einer API für den Versand der Einladungen per E-Mail und SMS. Zugriffsrechte: Sicherstellung, dass nur autorisierte Benutzer den Versand von Einladungen initiieren können. Automatisierung: Implementierung eines Systems zur automatischen Verarbeitung und Versendung der Einladungen nach definierten Kriterien. Protokollierung: Speicherung von Versandstatus und Fehlerprotokollen, um die Nachvollziehbarkeit und Fehlersuche zu gewährleisten. Sicherheit: Gewährleistung einer verschlüsselten Übertragung der Daten und Schutz vor unbefugtem Zugriff. | AfT-2 |
| Einladung beantworten (zu/absagen)
Frontend:
Das System muss Nutzern ermöglichen, Einladungen direkt anzunehmen oder abzulehnen. Offene Einladungen sollen zentral verwaltet und der Status jederzeit einsehbar sein. Dies gewährleistet eine sichere und unkomplizierte Verwaltung der Zugangsberechtigungen.
Backend:
Datenbankintegration: Speicherung der Teilnahmeantworten (Zusage/Absage) in der Datenbank, verknüpft mit dem jeweiligen Event und Teilnehmer. Rückmeldungsverarbeitung: Entwicklung eines Algorithmus, der eingehende Antworten verarbeitet und den Eventstatus entsprechend aktualisiert (z. B. verfügbare Plätze).Benachrichtigungssystem: Automatische Benachrichtigung des Organisators über eingehende Zu- oder Absagen.
Zugriffsrechte: Sicherstellung, dass nur eingeladene und berechtigte Teilnehmer ihre Rückmeldung abgeben können.
Benutzerfreundlichkeit: Bereitstellung einer klaren und einfachen Schnittstelle, die Teilnehmern die Abgabe ihrer Rückmeldung ermöglicht. Sicherheit: Verschlüsselte Übertragung der Teilnahmeantworten und Schutz vor unbefugtem Zugriff oder Manipulation. Protokollierung: Erfassung und Speicherung der Antworten, inklusive Zeitstempel, zur Nachverfolgbarkeit und Fehleranalyse. | AfT-3 |
| Kategorisierung (Phase 2)
Frontend:
Das System muss eine Kategorisierung der Events für Treffen ermöglichen, um eine intuitive und effiziente Nutzung zu gewährleisten. Nutzer sollen zwischen den Optionen „Neue Veranstaltung erstellen“, „An Treffen teilnehmen“ und „Veranstaltungen verwalten“ wählen können. Zudem soll eine übersichtliche Filterung von Veranstaltungen möglich sein, sodass schnell erkennbar ist, wer das Event erstellt hat.
Backend:
Datenbankstruktur: Einrichtung einer Datenbanktabelle zur Definition und Verwaltung von Kategorien sowie zur Verknüpfung dieser Kategorien mit den Events. Automatische Zuordnung: Entwicklung eines Algorithmus, der Events basierend auf vordefinierten Kriterien automatisch der passenden Kategorie zuordnet. Benutzeroberfläche: Bereitstellung einer intuitiven Oberfläche für das Hinzufügen, Bearbeiten und Löschen von Kategorien.Zugriffsrechte: Implementierung eines Berechtigungssystems, das sicherstellt, dass nur autorisierte Benutzer Kategorien verwalten können. Flexibilität: Unterstützung dynamischer Änderungen an Kategorien und deren Kriterien ohne Beeinträchtigung bestehender Zuordnungen. Sicherheit: Verschlüsselte Übertragung und Speicherung der Kategoriedaten sowie Schutz vor unbefugtem Zugriff. Protokollierung: Dokumentation aller Änderungen an den Kategorien zur Nachvollziehbarkeit und Fehleranalyse. | AfT-4 |
| Zielgruppenfilter (Phase 2)
Frontend:
Das System muss einen Zielgruppenfilter für Anmeldetools bereitstellen, der es Nutzern ermöglicht, gezielt Veranstaltungen zu finden, die ihren Interessen entsprechen. Durch intuitive Auswahlmöglichkeiten soll der Zugang zu relevanten Treffen erleichtert werden, sodass passende Optionen schnell entdeckt werden können.
Backend:
Datenbankintegration: Erfassung und Speicherung der Teilnehmerdaten in der Datenbank, einschließlich Interessen, Demografie und Eventpräferenzen. Datenanalyse und Filter: Entwicklung eines Algorithmus, der Teilnehmerdaten basierend auf vordefinierten Kriterien (z. B. Interessen, Alter, Eventpräferenzen) analysiert und filtert. Benutzeroberfläche: Bereitstellung einer benutzerfreundlichen Oberfläche, die es ermöglicht, Zielgruppenfilter zu erstellen, anzupassen und anzuwenden. Zugriffsrechte: Sicherstellung, dass nur autorisierte Benutzer die Filter erstellen, anpassen oder anwenden können. Flexibilität: Unterstützung der Anpassung der Filterkriterien, um dynamische Zielgruppenselektionen basierend auf unterschiedlichen Anforderungen zu ermöglichen. Sicherheit: Verschlüsselte Speicherung und Übertragung der Teilnehmerdaten sowie Schutz vor unbefugtem Zugriff. Protokollierung: Dokumentation der Anwendung von Zielgruppenfiltern zur Nachverfolgbarkeit und Analyse von Änderungen. | AfT-5 |
## Profilverwaltung
| Anforderung | ID |
| --- | --- |
| Profil erstellen
Frontend:
Das System muss eine Profilverwaltung im Frontend bieten, die es Nutzern ermöglicht, ein individuelles Profil zu erstellen. Nutzer sollen ihre Interessen, Präferenzen sowie persönliche Informationen einfach eingeben können. Zudem sollen sie vergangene Veranstaltungen hinzufügen können, um passende Treffen basierend auf ihren Präferenzen schnell zu finden.
Backend:
Bereitstellung von Eingabefeldern für persönliche Daten (z. B. Name, E-Mail, Geburtsdatum). Validierung der Eingaben auf Vollständigkeit und Korrektheit (Pflichtfelder, Formatprüfung). Zugriff nur für autorisierte Nutzer mit entsprechender Berechtigung.API-Schnittstelle zum Erstellen und Bearbeiten von Profilen mit Validierung und Fehlerhandling. | Pro-1 |
| Profil bearbeiten
Frontend:
Das System muss eine einfache und benutzerfreundliche Profilbearbeitung im Frontend ermöglichen. Nutzer sollen ihre Informationen schnell und unkompliziert aktualisieren können, einschließlich Interessen, persönlicher Daten und vergangener Veranstaltungen. Die Eingabefelder müssen intuitiv gestaltet sein, sodass Nutzer ihr Profil stets aktuell und relevant halten können.
Backend:
Editierfunktionen: Benutzer können ihre Profilinformationen über ein Formular bearbeiten. Validierung: Eingaben werden geprüft; nur gültige Daten werden gespeichert.Datenbank: Änderungen werden direkt und sicher in der Datenbank gespeichert. Zugriffsrechte: Nur autorisierte Benutzer dürfen ihre eigenen Profile bearbeiten. Benutzeroberfläche: Intuitive und leicht bedienbare Oberfläche zur Profilbearbeitung. Sicherheit: Verschlüsselte Datenübertragung und Schutz vor Sicherheitsrisiken. | Pro-2 |
| Profil mit LinkedIn automatisch abgleichen lassen
Frontend:
Das System muss eine Funktion zum automatischen Abgleich des Profils mit LinkedIn bieten. Durch einen einfachen Klick sollen relevante Daten, wie berufliche Erfahrungen und Interessen, nahtlos übernommen werden. Diese Funktion erleichtert die Erstellung und Aktualisierung des Profils, sodass es stets aktuell und ansprechend bleibt.
Backend:
API-Integration: Die LinkedIn-API wird eingebunden, um Profilinformationen der Benutzer abzurufen. Datenabgleich: Ein Algorithmus überprüft und synchronisiert die abgerufenen LinkedIn-Daten mit den bestehenden Profildaten. Änderungen werden automatisiert in der Datenbank gespeichert. Zugriffsrechte: Nur autorisierte Benutzer dürfen den Abgleich starten. Zugriffsversuche ohne Berechtigung werden verhindert. Benutzeroberfläche: Eine intuitive Oberfläche ermöglicht es den Nutzern, den Abgleich mit LinkedIn einfach auszuführen. Sicherheit: Die Kommunikation mit der LinkedIn-API erfolgt verschlüsselt, und die Daten werden gemäß Sicherheitsstandards verarbeitet und gespeichert. Protokollierung: Alle Abgleichvorgänge werden protokolliert, um Nachvollziehbarkeit und Fehleranalyse zu gewährleisten. | Pro-3 |
| Profil verwaltung
Frontend:
Das System muss eine benutzerfreundliche Profilverwaltung im Frontend bieten, die es Nutzern ermöglicht, ihre Informationen mühelos zu verwalten. Nutzer sollen persönliche Daten, Interessen und vergangene Veranstaltungen anpassen können, um ein ansprechendes und relevantes Profil zu erstellen. Dieses Profil soll die Teilnahme an zukünftigen Treffen optimieren und eine gezielte Auswahl von relevanten Veranstaltungen erleichtern.
Backend:
Datenbank: Einrichtung einer Datenbank zur Speicherung und Verwaltung aller Profildaten. APIs: Implementierung von APIs zur Abfrage, Aktualisierung und Verwaltung der Profildaten. Validierung: Entwicklung von Algorithmen zur Prüfung und Sicherstellung gültiger Eingaben bei Änderungen oder Neuanlagen von Profilen. Benutzeroberfläche: Bereitstellung einer intuitiven Oberfläche für das Anzeigen und Bearbeiten von Profilen. Zugriffsrechte: Implementierung eines Berechtigungssystems, das sicherstellt, dass nur autorisierte Benutzer auf ihre eigenen Profildaten zugreifen und Änderungen vornehmen können. Sicherheit: Verschlüsselte Übertragung und Speicherung aller Profildaten sowie Schutz vor unbefugtem Zugriff und Manipulation. | Pro-4 |
# Datenbank
| Anforderung | ID |
| --- | --- |
| Datenbank
1. Zielsetzung
Entwicklung einer relationalen Datenbank mit PostgreSQL zur Speicherung und Verwaltung von Anwendungsdaten.
2. Datenbankdesign
Datenmodellierung: Erstellung eines konzeptionellen Modells (z.B. ER-Diagramm) zur Definition der Entitäten, Attribute und Beziehungen. Tabellenstruktur: Definition der Tabellen, einschließlich: Primärschlüssel Fremdschlüssel Datentypen für jedes Attribute
3. Implementierung der Datenbank
Erstellung der Datenbank: Anlegen der PostgreSQL-Datenbank und der erforderlichen Tabellen. Indizes: Implementierung von Indizes zur Optimierung der Abfragegeschwindigkeit.Constraints: Festlegung von Constraints (z.B. NOT NULL, UNIQUE) zur Gewährleistung der Datenintegrität.
4. Datenbankanbindung
Zugriffsmethoden: Definition der Methoden zur Anbindung der Anwendung an die PostgreSQL-Datenbank (z.B. über JDBC, Entity Framework). CRUD-Operationen: Implementierung der grundlegenden CRUD-Operationen (Create, Read, Update, Delete) für die Datenmanipulation.
5. Sicherheit
Benutzerverwaltung: Einrichtung von Benutzerrollen und Berechtigungen zur Kontrolle des Zugriffs auf die Datenbank.Datenverschlüsselung: Implementierung von Maßnahmen zur Sicherstellung der Datensicherheit (z.B. SSL-Verbindungen). | DB-1 |
# Dokumentation
## Projektdokumentation
| Pflichtenheft | DOK-1 |
| --- | --- |
| Systembeschreibung | DOK-2 |
| Disasterrecovery Handbuch | DOK-3 |
| Benutzer Handbuch | DOK-4 |
| Admin Handbuch | DOK-5 |
| Git Handbuch | Dok-6 |