Compare commits
13 Commits
05d4e27483
...
d82ed4c7f6
Author | SHA1 | Date | |
---|---|---|---|
d82ed4c7f6 | |||
cb739d365f | |||
1391672cff | |||
4ebd9ea456 | |||
0aae5b89fe | |||
4f07fd8e18 | |||
1dae8b9a0b | |||
999d0f1b83 | |||
75f6308213 | |||
aeea676b4a | |||
1539bec6a5 | |||
e2b4814227 | |||
1cc0d133f3 |
285
pflichtenheft.md
285
pflichtenheft.md
|
@ -142,7 +142,7 @@ Redundanzeigenschaften Bespr. Mit Hr. Prof. Gürth
|
|||
| Anforderung | ID |
|
||||
| --- | --- |
|
||||
| SMTP (Email versand)<br><br>1. Zielsetzung<br>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.<br><br>2. Aufgabenbeschreibung<br>Konfiguration des Brevo SMTP-Servers: Festlegung von Host, Port, Authentifizierung und Verschlüsselung.<br>Erstellung von E-Mails: Gestaltung im Text- und HTML-Format.<br>Integration in die C#-Backend-Anwendung: Nutzung von SMTP-Befehlen.<br>Fehlerbehandlung und Logging: Protokollierung fehlerhafter E-Mails.<br>Sicherheit: Schutz der E-Mail-Kommunikation und Verhinderung von Missbrauch.<br>3. dynamischer Versand<br><br>Benachrichtigungs-E-Mails: Willkommens-E-Mails, Passwort-Zurücksetzen, Bestellbestätigungen mit dynamischen Platzhaltern.<br>Massen-E-Mails: Versand an mehrere Empfänger unter Beachtung des Limits von 300 E-Mails pro Tag.<br>3.1 Fehler- und Zustellungsmanagement<br>Protokollierung fehlgeschlagener E-Mails.<br>Rückmeldung bei erfolgreichem Versand.<br>Möglichkeit zur Wiederholung fehlgeschlagener E-Mails.<br><br>4. Nicht-funktionale Anforderungen<br>Performance: Versand innerhalb von 3 Sekunden pro Nachricht.<br>Skalierbarkeit: Planung für ein Upgrade bei höherem Bedarf.<br>Sicherheit: TLS/SSL-Verschlüsselung und Schutz durch Rate-Limiting.<br>Kompatibilität: Anzeige von HTML-E-Mails auf verschiedenen Geräten.<br><br>5. Technische Umsetzung<br>5.1. Backend<br>Framework: ASP.NET Core.<br>Architektur: Erstellung eines SMTP-Services mit Methoden für den Versand einfacher und komplexer E-Mails mit Anhängen und Templates.<br><br>5.2. Sicherheit<br>Schutz der Zugangsdaten: Nutzung eines Secret Managers oder Umgebungsvariablen.<br>Rate Limiting: Einhaltung des Tageslimits von 300 E-Mails.<br>Spam-Prävention: Konfiguration von SPF, DKIM und DMARC.<br><br>6. Erfolgskriterien<br>Alle E-Mails werden zuverlässig und sicher über Brevo versendet.<br>Personalisierte Nachrichten und Anhänge werden korrekt verarbeitet.<br>Robuster Versandprozess mit Fehlerhandling und Schutz vor Missbrauch.<br><br>| SnT-2 |
|
||||
| LinkedÌn OAuth (Phase 2, oder später)<br><br>Backend zu LinkedIn<br><br>1. Zielsetzung<br>Implementierung von LinkedIn OAuth 2.0 für die Authentifizierung und den Abruf von Profildaten in der C#-Backend-Anwendung.<br><br>2. Anforderungen<br>Registrierung der App im LinkedIn Developer Portal.<br>OAuth 2.0 Authentifizierungsablauf:<br>Weiterleitung zur LinkedIn-Login-Seite.<br>Empfang des Autorisierungscodes.<br>Austausch des Codes gegen ein Zugriffstoken.<br>Abruf von Benutzerinformationen (Vorname, Nachname, E-Mail).<br>Sicheres Token-Management (kein Speichern von Zugangsdaten in der Datenbank).<br><br>3. Technische Umsetzung<br>Backend: ASP.NET Core<br>API-Endpunkte:<br>/auth/linkedin (Weiterleitung zur LinkedIn-Login-Seite).<br>/auth/linkedin/callback (Empfang des Codes).<br>/api/user/profile (Abruf von LinkedIn-Daten mit Token).<br>Sicherheit:<br>Nutzung von HTTPS und PKCE.<br>Speicherung von Tokens nur im Cache (z. B. Redis).<br>Einschränkung der API-Berechtigungen (r_liteprofile, r_emailaddress).<br><br>4. Erfolgskriterien<br>Benutzer können sich sicher über LinkedIn anmelden.<br>Zugriffstoken werden sicher verarbeitet.<br>API-Datenabruf funktioniert zuverlässig.<br> | SnT -3 |
|
||||
| LinkedÌn OAuth (Phase 2, oder später)<br><br>Backend zu LinkedIn<br><br>1. Zielsetzung<br>Implementierung von LinkedIn OAuth 2.0 für die Authentifizierung und den Abruf von Profildaten in der C#-Backend-Anwendung.<br><br>2. Anforderungen<br>Registrierung der App im LinkedIn Developer Portal.<br>OAuth 2.0 Authentifizierungsablauf:<br>Weiterleitung zur LinkedIn-Login-Seite.<br>Empfang des Autorisierungscodes.<br>Austausch des Codes gegen ein Zugriffstoken.<br>Abruf von Benutzerinformationen (Vorname, Nachname, E-Mail).<br>Sicheres Token-Management (kein Speichern von Zugangsdaten in der Datenbank).<br><br>3. Technische Umsetzung<br>Backend: ASP.NET Core<br>API-Endpunkte:<br>/auth/linkedin (Weiterleitung zur LinkedIn-Login-Seite).<br>/auth/linkedin/callback (Empfang des Codes).<br>/api/user/profile (Abruf von LinkedIn-Daten mit Token).<br>Sicherheit:<br>Nutzung von HTTPS und PKCE.<br>Speicherung von Tokens nur im Cache (z. B. Redis).<br>Einschränkung der API-Berechtigungen (r_liteprofile, r_emailaddress).<br><br>4. Erfolgskriterien<br>Benutzer können sich sicher über LinkedIn anmelden.<br>Zugriffstoken werden sicher verarbeitet.<br>API-Datenabruf funktioniert zuverlässig.<br> | SnT-3 |
|
||||
|
||||
# Anforderungen an die Software
|
||||
|
||||
|
@ -150,275 +150,24 @@ Redundanzeigenschaften Bespr. Mit Hr. Prof. Gürth
|
|||
|
||||
| Anforderung | ID |
|
||||
| --- | --- |
|
||||
| Die Website oder Webanwendung wird so entwickelt, dass sie in den aktuellen und vorherigen Versionen der gängigsten Webbrowser einwandfrei funktioniert: </p><p> Google Chrome (Desktop und Mobile) <br>Mozilla Firefox (Desktop und Mobile)<br>Safari (macOS und iOS)<br>Microsoft Edge (Chromium-basiert)</p><p> 1. Programmiersprachen und Standards: <br> -Die Entwicklung erfolgt auf Basis moderner Technologien wie HTML5, CSS3 für eine plattformübergreifende Funktionalität.</p><p> 2. Frameworks und Bibliotheken: <br> -Frameworks wie React, Angular oder Vue.js (für die Frontend-Entwicklung) sowie CSS-Frameworks wie Bootstrap oder TailwindCSS können zum Einsatz kommen.</p><p> 3. Build-Tools: <br> -Tools wie Webpack, Vite oder Parcel werden zur Optimierung der Assets (z. B. Minifizierung und Bundling von Dateien) verwendet,um die Performance auf verschiedenen Browsern zu gewährleisten. <br><br> | SW-1 |
|
||||
| Barrierefreiheit (WAI-ARIA-Standard) ...</p><p> <b> 1. Verwendung von ARIA-Attributen: </b> <br> -Semantik und Bedienbarkeit durch role, aria-label, aria-expanded, aria-live etc. verbessern.<br>-Dynamische Inhalte und interaktive Elemente mit Attributen wie aria-controls oder aria-describedby ausstatten. </p><p> <b> 2. Technologien und Tools:</b> <br>-Unterstützung durch Frameworks (z. B. React, Angular) und CSS-Frameworks (z. B. Bootstrap). <br>-Einsatz von Tools wie Axe, Lighthouse oder eslint-plugin-jsx-a11y zur Validierung. </p><p> <b> 3. Tastaturbedienbarkeit und Kontraste:</b> <br>-Sicherstellen, dass alle Inhalte per Tastatur erreichbar sind.<br> -Einhalten der Kontrastvorgaben gemäß WCAG 2.1 Stufe AA. <br><br> | SW-2 |
|
||||
| **CMS**: <br>Das System soll einen redaktionellen Schülerzugagng bieten, damit die Diplomarbeiten von Schülern selbst eingepflegt werden können. | SW-3 |
|
||||
| Die Website oder Webanwendung wird so entwickelt, dass sie in den aktuellen und vorherigen Versionen der gängigsten Webbrowser einwandfrei funktioniert: </p><p> Google Chrome (Desktop und Mobile) <br>Mozilla Firefox (Desktop und Mobile)<br>Safari (macOS und iOS)<br>Microsoft Edge (Chromium-basiert)</p><p> 1. Programmiersprachen und Standards: <br> -Die Entwicklung erfolgt auf Basis moderner Technologien wie HTML5, CSS3 für eine plattformübergreifende Funktionalität.</p><p> 2. Frameworks und Bibliotheken: <br> -Blazor| SW-1 |
|
||||
| Barrierefreiheit (WAI-ARIA-Standard) ...</p><p> <b> 1. Verwendung von ARIA-Attributen: </b> <br> -Semantik und Bedienbarkeit durch role, aria-label, aria-expanded, aria-live etc. verbessern.<br>-Dynamische Inhalte und interaktive Elemente mit Attributen wie aria-controls oder aria-describedby ausstatten. </p><p> <b> 2. Technologien und Tools:</b> <br>-CSS: Oqtane </p><p> <b> 3. Tastaturbedienbarkeit und Kontraste:</b> <br>-Sicherstellen, dass alle Inhalte per Tastatur erreichbar sind.<br> -Einhalten der Kontrastvorgaben gemäß WCAG 2.1 Stufe AA. <br><br> | SW-2 |
|
||||
| **CMS**: <br>-Das System soll einen redaktionellen Schülerzugagng bieten, damit die Diplomarbeiten von Schülern selbst eingepflegt werden können.<br> -Entwicklung geschieht in Themes und Modules </p><p> <b> Technologien und Tools:</b> <br> -Oqtane| SW-3 |
|
||||
| **Sicherheit und administrativer Zugriff:** <br> 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. <br> Der Zugriff auf die Anwendung und die Infrastruktur muss jederzeit gegeben sein. Dies kann durch die Implementierung von:</p><ul><li>SSH-Zugriff für Administratoren</li><li>VPN-Verbindung (Virtual Private Network) für eine sichere und verschlüsselte Verbindung</li><li>Zugriffskontrolle und Authentifizierung, um den Zugriff auf autorisierte Personen zu beschränken</li></ul> erreicht werden. | SW-4 |
|
||||
|
||||
|
||||
## Zugriffsverwaltung
|
||||
|
||||
| Anforderung | ID |
|
||||
| --- | --- |
|
||||
| **Benutzername und Passwort Authentifizierung**: <br> **Im Frontend**: <br> 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. <br> **Vorraussetzungen**: <br><ol><li>Backend-Anforderungen <ul><li>Mechanismen zur Passwort-Validierung und Token-Generierung (z. B. JWT).</li><li>HTTPS für sichere Datenübertragung.</li></ul></li><li>Frontend-Anforderungen <ul><li>Möglichkeit zur Verarbeitung und sicheren Übertragung der Eingaben.</li><li>Mechanismus zur Speicherung von Authentifizierungsdaten (z. B. Tokens).</li></ul></li></ol> **Diese gelten für alle folgenden Punkte!** <br> **Benötigte Komponenten**: <ol><li>Login-Formular: <ul><li>Eingabefelder für Benutzername und Passwort.</li><li>Submit-Button.</li><li>Fehleranzeige bei ungültigen Eingaben oder falschen Daten.</li></ul></li><li>HTTP-Client: <ul><li>Zum Senden von Authentifizierungsanfragen an das Backend (RestAPI).</li></ul></li><li>Token-Management: <ul><li>Speicherung von JWTs (z. B. im localStorage oder Cookies).</li></ul></li><li>Routing: <ul><li>Weiterleitung zu geschützten Seiten nach erfolgreicher Anmeldung.</li><li>Zugangsbeschränkung zu sensiblen Bereichen der App.</li></ul></li></ol><br> **Technologien**: <ol><li>Framework: <ul><li>C#</li><li>HTML</li></ul></li><li>HTTP-Anfragen: <ul><li>RestAPI</li></ul></li><li>Sicherheitsmaßnahmen: <ul><li>HTTPS</li></ul></li><li>Styling: <ul><li>Eigenes CSS</li></ul></li><li>Token-Handling: <ul><li>JWT</li></ul></li><li>Datenbank: <ul><li>PostgreSQL</li></ul></li></ol> **Diese gelten für alle folgenden Punkte!**<br><br>**Backend:**<br>Überprüft die empfangenen Anmeldedaten, in dem er nach vorhandenen Benutzernamen sucht. Anschließend wird das eingegebene Passwort mit den Daten in der Datenbank überprüft. | ZUG-1 |
|
||||
|
||||
<table><tbody>
|
||||
<tr><td style="text-align: left"><p><strong><b>Passwort zurücksetzen</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
Die Passwort-Zurücksetzen-Funktion im Frontend ermöglicht es Benutzern, über eine Benutzeroberfläche einen Token-basierten Prozess zur Passwortänderung zu starten.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Eingabefeld für die E-Mail-Adresse.</p><p>
|
||||
2. Formular zur Eingabe des neuen Passworts nach Token-Bestätigung.</p><p>
|
||||
3. Fehler- und Erfolgsmeldungen zur Benutzerführung.
|
||||
</p><p>
|
||||
|
||||
</p>
|
||||
<p>Backend:</p>
|
||||
<p>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.</p></td>
|
||||
|
||||
<td><p>ZUG-2</p></td></tr>
|
||||
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>Rollen</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
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.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Rollenbasierte Navigation </p><p>
|
||||
2. Zugriffskontroll-Guard </p><p>
|
||||
3. UI-Elemente basierend auf Benutzerrolle
|
||||
</p><p>
|
||||
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>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.</p></td>
|
||||
|
||||
<td><p>ZUG-3</p></td></tr>
|
||||
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>Benutzerverwaltung (für Admins)</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
Die Benutzerverwaltung erlaubt Administratoren, Benutzerkonten zu verwalten, einschließlich Erstellung, Bearbeitung, Aktivierung/Deaktivierung und Löschung von Benutzern sowie Zuweisung von Rollen und Berechtigungen.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Liste der Benutzer mit Rollen und Status </p><p>
|
||||
2. Buttons zum Bearbeiten und Löschen von Benutzern </p><p>
|
||||
3. Such- und Filterfunktionen für Benutzer
|
||||
</p><p>
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>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.</p></td>
|
||||
<td><p>ZUG-4</p></td></tr>
|
||||
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>Einladung an die EDU-Adresse (Phase 2)</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
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.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Eingabefeld für die EDU-E-Mail-Adresse </p><p>
|
||||
2. Button zum Versenden der Einladung </p><p>
|
||||
3. Bestätigungs- und Fehlermeldungen für den Versand
|
||||
</p><p>
|
||||
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>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.</p></td>
|
||||
<td><p>ZUG-5</p></td></tr>
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>Magic Link Authentifizierung</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
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.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Eingabefeld für die E-Mail-Adresse</p><p>
|
||||
2. Button zum Anfordern des Magic Links</p><p>
|
||||
3. Weiterleitung zur Bestätigungsseite nach Klick auf den Magic Link
|
||||
</p><p>
|
||||
|
||||
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>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 und eine 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.</p></td>
|
||||
|
||||
<td><p>ZUG-6</p></td></tr>
|
||||
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>2FA Authentifizierung (Phase 2)</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
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.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Eingabefeld für den OTP (One-Time-Password)</p><p>
|
||||
2. Button zur Bestätigung des OTPs</p><p>
|
||||
3. Fehler- und Erfolgsmeldungen für die OTP-Verifizierung
|
||||
</p><p>
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>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.</p></td>
|
||||
|
||||
<td><p>ZUG-7</p></td></tr>
|
||||
|
||||
|
||||
|
||||
<tr><td style="text-align: left"><p><strong><b>OAuth (Phase 2)</b></strong>
|
||||
</p><p>
|
||||
<b>Im Frontend</b>
|
||||
</p><p>
|
||||
|
||||
<b>Beschreibung:</b>
|
||||
</p><p>
|
||||
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.
|
||||
</p><p>
|
||||
|
||||
<b>Benötigte Komponenten:</b>
|
||||
</p><p>
|
||||
1. Button für die Auswahl des OAuth-Anbieters (z. B. Google, Facebook)</p><p>
|
||||
2. Weiterleitung zur OAuth-Anmeldeseite des Anbieters</p><p>
|
||||
3. Empfang und Verarbeitung des Tokens nach erfolgreicher Anmeldung
|
||||
</p><p>
|
||||
|
||||
|
||||
<p>Backend:</p>
|
||||
<p>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 zur LinkedIn-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.</p></td>
|
||||
<td><p>ZUG-8</p></td></tr></tbody></table>
|
||||
| **Benutzername und Passwort Authentifizierung**: <br> **Im Frontend**: <br> **Beschreibung**: <br> 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. <br> **Benötigte Komponenten**: <li> Login-Formular sie enthält Eingabefelder für Benutzername und Passwort sowie einen Login-Button. </li><li> API-Service dieser sendet die Anmeldedaten sicher an das Backend und verarbeitet die Antwort. </li><li> Token-Speicherung & Weiterleitung sie speichert das Authentifizierungstoken und leitet den Nutzer nach erfolgreicher Anmeldung weiter. </li> <br><br><br>**Backend:**<br>Überprüfung der empfangenen Anmeldedaten: Zunächst wird nach vorhandenen Benutzernamen gesucht.<br> Passwortüberprüfung: Anschließend wird das eingegebene Passwort mit den Daten in der Datenbank verglichen. | ZUG-1 |
|
||||
| **Passwort zurücksetzen**: <br> **Im Frontend**: <br> **Beschreibung**: <br> Die Passwort-Zurücksetzen-Funktion im Frontend ermöglicht es Benutzern, über eine Benutzeroberfläche einen Token-basierten Prozess zur Passwortänderung zu starten. <br> **Benötigte Komponenten**: <li> Eingabefeld für die E-Mail-Adresse </li><li> Formular zur Eingabe des neuen Passworts nach Token-Bestätigung </li><li> Fehler- und Erfolgsmeldungen zur Benutzerführung </li> <br> Backend: <br> 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. <br> | ZUG-2 |
|
||||
| **Rollen**: <br> **Im Frontend**: <br> **Beschreibung**: <br> 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. <br> **Benötigte Komponenten**: <li> Rollenbasierte Navigation </li><li> Zugriffskontroll-Guard </li><li> UI-Elemente basierend auf Benutzerrolle </li> <br> Backend: <br> 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. <br> | ZUG-3 |
|
||||
| **Benutzerverwaltung (für Admins)**: <br> **Im Frontend**: <br> **Beschreibung**: <br> Die Benutzerverwaltung erlaubt Administratoren, Benutzerkonten zu verwalten, einschließlich Erstellung, Bearbeitung, Aktivierung/Deaktivierung und Löschung von Benutzern sowie Zuweisung von Rollen und Berechtigungen. <br> **Benötigte Komponenten**: <li> Liste der Benutzer mit Rollen und Status </li><li> Buttons zum Bearbeiten und Löschen von Benutzern </li><li> Such- und Filterfunktionen für Benutzer </li> <br> Backend: <br> 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. <br> | ZUG-4 |
|
||||
| **Einladung an die EDU-Adresse (Phase 2)**: <br> **Im Frontend**: <br> **Beschreibung**: <br> 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. <br> **Benötigte Komponenten**: <li> Eingabefeld für die EDU-E-Mail-Adresse </li><li> Button zum Versenden der Einladung </li><li> Bestätigungs- und Fehlermeldungen für den Versand </li> <br> Backend: <br> 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. <br> | ZUG-5 |
|
||||
| **Magic Link Authentifizierung**: <br> **Im Frontend**: <br> **Beschreibung**: <br> 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. <br> **Benötigte Komponenten**: <li> Eingabefeld für die EDU-E-Mail-Adresse </li><li> Button zum Anfordern des Magic Links </li><li> Weiterleitung zur Bestätigungsseite nach Klick auf den Magic Link </li> <br> Backend: <br> 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. <br> | ZUG-6|
|
||||
| **2FA Authentifizierung (Phase 2)**: <br> **Im Frontend**: <br> **Beschreibung**: <br> 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. <br> **Benötigte Komponenten**: <li> Eingabefeld für den OTP (One-Time-Password) </li><li> Button zur Bestätigung des OTPs </li><li> Fehler- und Erfolgsmeldungen für die OTP-Verifizierung </li> <br> Backend: <br>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)**: <br> **Im Frontend**: <br> **Beschreibung**: <br> 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. <br> **Benötigte Komponenten**: <li> Button für die Auswahl des OAuth-Anbieters (z. B. Google, Facebook) </li><li> Weiterleitung zur OAuth-Anmeldeseite des Anbieters </li><li> Empfang und Verarbeitung des Tokens nach erfolgreicher Anmeldung </li> <br> Backend: <br>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)
|
||||
|
||||
|
@ -443,9 +192,9 @@ Protokollierung aller Authentifizierungsversuche und der zugehörigen LinkedIn-D
|
|||
|
||||
| Anforderung | ID |
|
||||
| --- | --- |
|
||||
| <b>Verwaltung der Premiumkunden</b> </p><p> 1. Benutzerverwaltung:<br> - Identifikation und Segmentierung der Premiumkunden.<br> -Erstellung und Verwaltung individueller Kundenprofile.<b> <p/><p> 2. Serviceverwaltung: <br> -Bereitstellung maßgeschneiderter Dienstleistungen und Angebote. <br> -Exklusive Inhalte oder Angebote für Premiumkunden.<br> </p><p> 3. Kommunikationssystem:<b> -Regelmäßige und personalisierte Kommunikation über E-Mail, Push-Benachrichtigungen oder Messaging-Dienste.<b> 4. Feedback- und Zufriedenheitstools:<b> -Sammlung von Kundenfeedback <br> -Tools zur Überwachung und Analyse der Kundenzufriedenheit.</p><p> Technologien: <br> -Datenbank: MySQL, PostgreSQL oder MongoDB zur Speicherung von Kundeninformationen und Präferenzen.<br> -CRM-System: Salesforce, HubSpot oder eine Eigenentwicklung zur Kundenverwaltung.<br> -Kommunikation: SMTP (z. B. SendGrid) für E-Mails,Websockets für Echtzeitkommunikation.<br> -Datenanalyse: Tools wie Power BI oder Google Analytics zur Zufriedenheitsüberwachung.</p><p> | PRE-1 |
|
||||
| <b>Ingenieurantrag <b> </p><p> -Ein Ingenieurantrag umfasst die Vorbereitung der Unterlagen, das Ausfüllen des Antragsformulars, die Einreichung bei der Behörde, die Prüfung und Genehmigung des Antrags sowie die Dokumentation für zukünftige Referenzen.</p><p> Technologien und Komponenten:<br> -Dokumentenmanagementsystem (DMS): Für die Verwaltung und Archivierung der erforderlichen Unterlagen.<br> -Online-Formularsystem: Zur Eingabe und Übermittlung der Antragdaten.<br> -Behördenportale: Nutzung digitaler Plattformen für die Einreichung.<br> -Projektmanagement-Tool: Zur Nachverfolgung der Bearbeitungsschritte und Fristen.<br> -Kommunikationsplattformen: Für Rückfragen mit Behörden. | PRE-2 |
|
||||
| <b>Matura & Klassentreffen organisieren</b></p><p> -Die Organisation eines Matura- und Klassentreffens umfasst die Festlegung von Datum und Ort, die Erstellung einer Gästeliste, das Versenden von Einladungen, die Planung des Programms und die Koordination von Verpflegung und Dekoration.</p><p> <b>Technologien und Komponenten:</b><br> -Doodle oder ähnliche Umfragetools: Zur Abstimmung von Datum und Ort.<br>-Excel/Google Sheets: Für die Erstellung und Verwaltung der Gästeliste.<br> -E-Mail-Marketing-Tools: Zum Versenden von Einladungen.<br> -Eventmanagement-Plattformen: Für Programmentwurf und Aufgabenverteilung.<br> -Cloud-basierte Kalender und Tools: Für die Koordination von Verpflegung und Dekoration. | PRE-3 |
|
||||
| <b>Verwaltung der Premiumkunden</b> </p><p> 1. Benutzerverwaltung:<br> - Identifikation der Premiumkunden.<br> -Erstellung und Verwaltung individueller Kundenprofile.<b> <p/><p> 2. Serviceverwaltung: <br> -Bereitstellung maßgeschneiderter Dienstleistungen und Angebote| PRE-1 |
|
||||
| <b>Ingenieurantrag <b> </p><p> -Der Ingenieurantrag umfasst ledeglich die Einsicht in andere Ingenieuranträge, welche in der Vergangenheit durch gegangen sind.| PRE-2 |
|
||||
| <b>Matura & Klassentreffen organisieren</b></p><p> -Umfasst das Versenden von Einladungen per Email </p><p> <b>Technologien und Komponenten:</b><br> -Brevo: Zum Versenden von Einladungen. | PRE-3 |
|
||||
|
||||
## Auswertungen
|
||||
|
||||
|
@ -481,7 +230,7 @@ Mehr Prosa (Unterscheidung Phase 1 & 2)
|
|||
| Event erstellen<br><br>Frontend: <br>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. <br><br>Backend:<br><br> 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<br><br>Frontend: <br>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.<br><br>Backend:<br><br>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)<br><br>Frontend: <br>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.<br><br>Backend:<br><br>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. <br> Zugriffsrechte: Sicherstellung, dass nur eingeladene und berechtigte Teilnehmer ihre Rückmeldung abgeben können. <br> 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)<br><br>Frontend: <br>Das System muss eine Kategorisierung der Anmeldetools 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.<br><br>Backend:<br><br>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 |
|
||||
| Kategorisierung (Phase 2)<br><br>Frontend: <br>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.<br><br>Backend:<br><br>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)<br><br>Frontend: <br>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.<br><br>Backend:<br><br>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
|
||||
|
|
Loading…
Reference in New Issue
Block a user