Antwort.

Geschichte der Frage:

Ursprünglich lag der Fokus bei der Formalisierung von Anforderungen auf den funktionalen Möglichkeiten. Im Laufe der Zeit wurde jedoch klar, dass Kriterien, die auf den ersten Blick „unsichtbar“ sind (Leistungsfähigkeit, Sicherheit, Ausfallsicherheit usw.), entscheidend für die erfolgreiche Implementierung und Lebensfähigkeit von Produkten sind. Ihre Vernachlässigung führte zu Ausfällen und unvorhersehbarem Verhalten der Software nach der Einführung.

Problem:

Nicht-funktionale Anforderungen werden oft standardmäßig erfasst, ohne den Kontext zu berücksichtigen. Sie werden aus Gründen der „Abhakung“ angegeben oder zu abstrakt formuliert, wie z.B.: „Das System soll benutzerfreundlich sein“ oder „Das System soll schnell sein“. Das gibt Entwicklern, Architekten und Testern keinen klaren KPI.

Lösung:

Der Systemanalytiker führt Sitzungen mit dem Geschäft, IT und Betriebsspezialisten durch, um die tatsächlichen Einschränkungen zu identifizieren, dokumentiert numerische Metriken (z.B. SLA, TPS, Latency-Werte), beschreibt nicht-funktionale Anforderungen explizit in den Spezifikationen und stellt deren Testbarkeit durch Verknüpfung mit Testfällen und architektonischen Artefakten des Projekts sicher.

Hauptmerkmale:

Verwendung quantitativer (messbarer!) Merkmale.
Einbeziehung eines Formalisierungs- und Begründungsprozesses durch Abstimmung mit wichtigen IT-Experten.
Verknüpfung von Anforderungen mit Testmethoden.

Fallenfragen.

Kann man Anforderungsgruppen einfach so belassen wie „Das System muss 24/7 verfügbar sein“ ohne Details?

Nein, man muss die Verfügbarkeitsparameter (z.B. 99,95%) und Wiederherstellungsbedingungen unbedingt präzisieren.

Reicht es aus zu sagen „Die Reaktionszeit sollte schnell sein“?

Nein, solche Formulierungen sind nicht brauchbar. Man sollte angeben: Antwortzeit < 3 Sekunden bei 95% der Anfragen mit Last X.

Sind nicht-funktionale Anforderungen formalisiert, wenn sie nur im allgemeinen Lastenheft ohne weitere Detaillierung festgehalten sind?

Nein, sie müssen dekonstruiert und mit architektonischen Lösungen und Testplänen verknüpft werden, sonst bleiben sie unerfüllbar oder nicht validierbar.

Typische Fehler und Antipatterns

Verwendung vager Formulierungen, die Testungen nicht erlauben.
Abschreiben von geforderten Werten aus anderen Projekten ohne Analyse der Spezifika.
Ignorieren von Konsultationen mit IT/SRE und Betrieb.

Beispiel aus dem Leben

Negativer Fall: Das E-Banking-Projekt wurde mit der Anforderung „Verfügbarkeit 24/7, schnelle Funktion“ ohne SLA-Klarstellung gestartet.

Vorteile:

Schnelle Vorbereitung der Anforderungen

Nachteile:

Häufige Ausfälle, unlösbare Streitigkeiten mit dem Dienstleister
Kundenbeschwerden

Positiver Fall: Der Analyst arbeitete mit der Betriebsabteilung zusammen, dokumentierte 99,9% Uptime, maximale Antwortzeit 2 sek, beschrieb Degenerationsszenarien.