Nicht-funktionale Anforderungen (NFAs) werden in Projekten oft vergessen oder nur nebenbei behandelt. Dabei spielen sie eine zentrale Rolle und haben einen grossen Einfluss auf Erfolg oder Misserfolg eines Projekts.
In diesem Artikel erkläre ich, was nicht-funktionale Anforderungen sind, welchen Impact sie auf ein Projekt haben und zu welchem Zeitpunkt sie in einem Projekt erarbeitet werden sollten.
Weiter stelle ich ein Template für nicht-funktionale Anforderungen zur Verfügung, das Du im Alltag anwenden kannst. Am Schluss illustriere ich die NFAs anhand eines konkreten Beispiels.
Was sind nicht-funktionale Anforderungen?
Neben den funktionalen Anforderungen, welche die Funktionen eines Systems beschreiben, definieren die nicht-funktionalen Anforderungen die restlichen relevanten Anforderungen an ein System:
Quelle: IREB Handbuch RE@Agile
Die nicht-funktionalen Anforderungen bestehen aus folgenden Kategorien:
Produktrandbedingungen (technisch)
Haben Einfluss auf die Lösung.
Beispiele:
– Make or Buy
– Zu verwendende Technologien
– Physische Randbedingungen der Benutzer
Prozessrandbedingungen (organisatorisch)
Haben Einfluss auf die Organisation des Projekts.
Beispiele:
– Compliance
– Verfügbare Personalressourcen
– Beschränkungen im Zeitplan oder Budget.
Qualitätsanforderungen
Haben Einfluss auf die meisten funktionalen Anforderungen.
Beispiele:
– Benutzerfreundlichkeit
– Zuverlässigkeit
– Performanz
Impact
Nicht-funktionale Anforderungen haben Impact auf folgende Aspekte eines Projekts:
- Projektplanung
- Architektur
- Testing
- Betrieb
- Compliance und Dokumentation
- und weitere…
Wann erarbeiten?
Weil sie eine so zentrale Rolle für so viele Aspekte spielen, ist es wichtig, die nicht-funktionalen Anforderungen früh im Projektsetup zu definieren.
Der ideale Zeitpunkt ist hier:
Sobald Ausgangslage und Projektziele definiert sind, werden die nicht-funktionalen Anforderungen erarbeitet.
Erst danach sollte mit der Erarbeitung des Produkt Backlogs mit den funktionalen Anforderungen begonnen werden.
Fazit
Nicht-funktionale Anforderungen sind ein zentraler Aspekt des Requirements Engineering. Es ist wichtig, dass sie zum richtigen Zeitpunkt erarbeitet werden.
Werden sie zu spät angegangen, müssen im schlimmsten Fall viele Aspekte des Projekts umgestaltet werden. Werden sie frühzeitig adressiert, lassen sich viele Aufgaben – wie Architekturdefinition, Technologieauswahl, Teamzusammenstellung und Projektsetup – deutlich einfacher erarbeiten.
Ressourcen
In diesem Kapitel stelle ich ein Template zur Verfügung und präsentiere ein Beispiel für nicht-funktionale Anforderungen anhand eines konkreten Projekts.
Template für nicht-funktionale Anforderungen
In folgendem ZIP-File habe ich ein Template für die nicht-funktionalen Anforderungen bereitgestellt:
Die Templates stehen in folgenden Formaten zur Verfügung:
- Word
- Markdown
Weiter habe ich eine Anleitung für den Import des Templates in Confluence (On-Prem und Cloud) hinzugefügt. Diese erklärt, wie man das Word-Template in Confluence importiert.
Konkretes Beispiel für NFAs
Folgendes Beispiel illustriert den Setup eines Projekts zur Entwicklungs einer Besucherverwaltung. Der Vollständigkeit halber werden hier Ausgangslage und Projektziele auch aufgezeigt.
Darauf folgend werden alle nicht-funktionalen Anforderungen mit den Prozessrandbedingungen, Produktrandbedingungen und Qualitätsanforderungen definiert.
Ausgangslage
| Teilaspekt | Erläuterung |
|---|---|
| Aktuelle Situation | Die Besucherverwaltung erfolgt derzeit manuell und uneinheitlich. Dies führt zu hohem administrativem Aufwand, Sicherheitslücken und Unzufriedenheit. |
| Probleme, Bedürfnisse oder Chancen | Es bestehen erhebliche Sicherheitsrisiken und Ineffizienzen. Ein modernes, digitales System könnte Abläufe verbessern und den Service optimieren. |
| Vorgeschichte | Frühere Versuche mit Excel-Listen und E-Mail-Anmeldungen waren nicht erfolgreich und haben die Probleme nicht gelöst. |
| Betroffene Stakeholder | Empfangsmitarbeitende, Sicherheitsdienst, interne Mitarbeitende sowie externe Besucher sind direkt betroffen. |
| Notwendigkeit des Projekts | Ein digitales System ist notwendig, um Standardisierung, Nachvollziehbarkeit und Sicherheit in der Besucherverwaltung zu gewährleisten. |
Projektziele
| Teilaspekt | Erläuterung |
|---|---|
| Ziel des Projekts | Einführung eines digitalen Systems für Vorabregistrierung, Check-in/out, Ausweiserstellung, Gastgeber-Benachrichtigung und Protokollierung. |
| Haupt- und Nebenziele | Hauptziel ist die Erhöhung von Sicherheit und Effizienz. Nebenziele sind ein besserer Besucherservice und weniger administrativer Aufwand. |
| Bedeutung der Ziele | Die Ziele sind entscheidend zur Risikominimierung, Prozessoptimierung und Verbesserung des Gesamtauftritts gegenüber Besuchern. |
| Nutznießer der Zielerreichung | Empfang, Sicherheitsdienst, Mitarbeitende und Gäste profitieren durch klarere Abläufe, mehr Sicherheit und ein angenehmeres Besuchererlebnis. |
Randbedingungen
Prozessrandbedingungen
| Bereich | Prozessrandbedingung |
|---|---|
| Compliance-Bestimmungen | DSGVO-Konformität und Einhaltung interner IT- und Sicherheitsrichtlinien |
| Randbedingungen bezüglich Bereitstellung und Migration | Einführung in einer Pilotphase innerhalb von 2 Wochen. Keine Migration nötig. |
| Randbedingungen bezüglich des Supports | 1st-Level-Support durch internen IT-Helpdesk, 2nd-Level durch Projektteam |
| Fähigkeitsbeschränkungen | Projektteam mit begrenzter Erfahrung in Frontend-UX, externe Unterstützung möglich |
| Randbedingungen zum Zeitplan | Projektbeginn am 01.07., Abschluss bis 30.09. mit definierten Meilensteinen |
| Budgetbeschränkungen | Maximales Projektbudget: CHF 120’000 |
| Vorgeschriebene Prozessmodelle (Rollen, Aktivitäten, Artefakte) | Anwendung eines agilen Vorgehensmodells nach Scrum mit 4-Wochen-Sprints |
Produktrandbedingungen
| Bereich | Produktrandbedingung |
|---|---|
| Randbedingung bezüglich des technologischen Umfelds | Integration in bestehende Microsoft 365 Umgebung inkl. Azure AD |
| Standard-Software (Make or Buy) | Priorisierung einer Eigenentwicklung auf Basis interner Web-Plattform |
| Wiederverwendung von Bauteilen | Nutzung vorhandener Module für Benutzerverwaltung, Mailversand, Kalenderanbindung |
| Vorgeschriebene Technologie | Verwendung von Angular (Frontend), .NET Core (Backend), MS SQL Server (Datenbank) |
| Voraussichtliche Arbeitsumgebung | Zugriff über Browser (Chrome, Edge) auf Desktop-PCs an Empfang und Sicherheit |
| Physische Randbedingungen | System muss mit QR-Scannern und Besucherausweisdruckern kompatibel sein |
| Randbedingungen zur Umwelt (Umgebung) | Keine besonderen Umweltanforderungen |
Qualitätsanforderungen
Diese Raster basiert auf ISO 25010.
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 |
Performanz / Effizienz
| 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 |