Qualitaetsanforderungen beispiel
Theorie --- Beispiel --- Template
Qualitätsanforderungen
Funktionalität
| Bereich |
Anforderungen |
| Funktional vollständig |
Alle im Konzept definierten Funktionen (Check-in/out, Ausweise, Benachrichtigung) müssen implementiert sein |
| Korrektheit |
Alle Aktionen (z. B. Ausweisdruck, Logs) müssen exakt und nach Spezifikation ausgeführt werden |
| Funktionale Angemessenheit |
System bietet nur relevante Funktionen ohne unnötige Komplexität |
| Bereich |
Anforderungen |
| Zeitverhalten |
Seitenaufbau und Aktionen < 2 Sekunden bei Standardlast |
| Ressourcenverwendung |
Serverlast durch Webzugriffe soll minimal gehalten werden, keine Überdimensionierung |
| Kapazität |
System muss mindestens 50 gleichzeitige Nutzer und 500 Besucher pro Tag verarbeiten können |
Kompatibilität
| Bereich |
Anforderungen |
| Ko-Existenz |
Keine Beeinträchtigung anderer Systeme im Netzwerk (z. B. Zutrittskontrolle, Mailserver) |
| Interoperabilität |
Muss mit E-Mail-System (Outlook), Kalender und Badge-System zusammenarbeiten |
Benutzbarkeit (Usability)
| Bereich |
Anforderungen |
| Angemessene Erkennbarkeit |
Besuchsprozesse müssen für Mitarbeitende und Gäste intuitiv erkennbar sein |
| Erlernbarkeit |
Schulung von max. 30 Minuten für interne Nutzer, Gäste ohne Schulung nutzbar |
| Bedienbarkeit |
Klare Benutzeroberfläche mit einfachen Eingabemasken |
| Schutz vor Fehlern des Benutzers |
Eingabevalidierung, Warnungen und Hilfetexte verhindern Fehlbedienung |
| Barrierefreiheit |
Konformität mit WCAG 2.1 AA für barrierearmen Zugang über Web |
Zuverlässigkeit
| Bereich |
Anforderungen |
| Reife / Fehlerfreiheit |
<1% Fehlerrate im Betrieb; keine kritischen Systemabstürze |
| Verfügbarkeit |
Verfügbarkeit von mindestens 99,5% während Betriebszeiten (Mo-Fr, 07:00–18:00) |
| Fehlertoleranz |
System bleibt bei Ausfall einzelner Module (z. B. Benachrichtigungen) funktionsfähig |
| Wiederherstellbarkeit |
Wiederherstellung innerhalb 2 Stunden inkl. vollständiger Datenintegrität nach Ausfall |
Sicherheit
| Bereich |
Anforderungen |
| Vertraulichkeit |
Zugriff auf Besucherdaten nur durch berechtigte Nutzergruppen über Rollen-/Rechtemodell |
| Integrität |
Daten werden durch Transaktionsmechanismen und Checks konsistent gehalten |
| Nachweisbarkeit |
Jede Benutzeraktion wird protokolliert (Audit-Trail) und ist nachvollziehbar |
| Ordnungsmäßigkeit |
Erfüllung aller regulatorischen Datenschutzanforderungen (z. B. Löschfristen) |
| Authentizität |
Anmeldung über Single-Sign-On (SSO) mit starker Authentifizierung |
Wartbarkeit
| Bereich |
Anforderungen |
| Modularität |
Klare Trennung von Frontend, Backend und Datenhaltung |
| Wiederverwendbarkeit |
Allgemeine Komponenten wie Logik für Benachrichtigungen sollen wiederverwendbar sein |
| Analysierbarkeit |
Logging und Monitoring ermöglichen schnelle Fehleridentifikation |
| Änderbarkeit |
Systemstruktur erlaubt Erweiterungen ohne grundlegende Umbauten |
| Testbarkeit |
Unit- und Integrationstests möglich mit Mock-Daten und Testumgebung |
Portabilität
| Bereich |
Anforderungen |
| Anpassbarkeit |
System kann bei Bedarf auf mobile Geräte erweitert werden |
| Skalierbarkeit |
Architektur erlaubt Skalierung bei wachsender Benutzerzahl |
| Installierbarkeit |
Installation via automatisierter Bereitstellung auf Windows-Server |
| Austauschbarkeit |
Module wie Druckkomponente können bei Bedarf durch andere Systeme ersetzt werden |