Antwort.

Historisch gesehen lag der Fokus in IT-Projekten auf funktionalen Anforderungen: was das System tun soll. Dabei blieben Fragen der Leistung, Zuverlässigkeit, Skalierbarkeit, Verfügbarkeit, Sicherheit und Wartbarkeit (diese Merkmale werden unter dem Begriff „nicht-funktionale Anforderungen“, NFA, zusammengefasst) lange Zeit nebensächlich und wurden oft gar nicht formalisiert.

Problem

Die Ignorierung oder formale Beschreibung von NFA führt zu erheblichen Problemen im Betrieb: das System ist nicht auf die erwarteten Lasten vorbereitet, hält Cyberangriffe nicht stand, ist schwierig zu warten und zu skalieren oder ist für die benötigte Anzahl von Nutzern nicht zugänglich.

Lösung

Ein moderner Systemanalytiker muss NFA initiieren, formalisieren, analysieren und dokumentieren. Dazu gehört:

die Zusammenarbeit mit Architekten, DevOps- und Betriebsteams, um technologische und infrastrukturelle Einschränkungen zu bestimmen;
das Sammeln von Anforderungen aus dem Unternehmen (z. B. zu SLA);
die Erstellung einer umfassenden Liste von NFA mit konkreten Schwellenwerten;
die Implementierung von Maßnahmen zu deren Überwachung in der Implementierungs- und Unterstützungsphase;
die Festlegung von Anforderungen in separaten Abschnitten der Spezifikation.

Wichtige Merkmale:

NFA sind für alle großen Projekte erforderlich.
Sie werden gemeinsam mit technischen und geschäftlichen Stakeholdern definiert.
Sie müssen eindeutig, testbar und an den Geschäftszielen ausgerichtet sein.

Fangfragen.

Was ist der Unterschied zwischen "Produktqualität" und "nicht-funktionalen Anforderungen"?

Produktqualität ist ein weiter gefasster Begriff, der nicht nur formal erfassbare Parameter, sondern auch subjektive Bewertungen (z. B. UX/UI-Bedienbarkeit) umfasst. NFA sind klar messbare Merkmale (Leistung, Zuverlässigkeit usw.), die einer automatischen Validierung unterliegen.

Kann der Analyst die Definition aller nicht-funktionalen Anforderungen dem Architekten übertragen?

Nein, der Analyst muss gemeinsam mit dem Architekten und dem Unternehmen diese Anforderungen in der Analysephase ermitteln, da sonst die Anforderungen unvollständig oder nur aus technischer Sicht beschrieben werden, ohne die geschäftlichen Bedürfnisse zu berücksichtigen.

Kann man nicht-funktionale Anforderungen nur in Form allgemeiner Phrasen formulieren ("das System muss zuverlässig sein")?

Nein, solche Formulierungen sind nicht für die Kontrolle und Tests geeignet. Eine Konkretisierung ist erforderlich: zum Beispiel, "die Wiederherstellungszeit des Dienstes nach einem Ausfall darf 10 Minuten nicht überschreiten".

Typische Fehler und Anti-Patterns

Formulierung von Anforderungen ohne testbare Kriterien (z. B. "schnell", "cool", "zuverlässig").
Auslassen ganzer Klassen von NFA (z. B. Sicherheit für interne Systeme).
Inkonsistenz der Anforderungen zwischen Kunde und Support.

Beispiel aus der Praxis

Negativer Fall: Das Projekt des nationalen Portals für staatliche Dienstleistungen hat die Anforderungen an Spitzenlasten nicht formalisiert. Das System „fiel“ an den Tagen, an denen beliebte Dienste gestartet wurden, und es kam zu Sicherheitsvorfällen.

Vorteile:

Schnelles MVP

Nachteile:

Hohe Kosten für Nachbesserungen
Vertrauensverlust der Nutzer
Schwierigkeiten bei der Wartung

Positiver Fall: Der Analyst stellte zu Beginn des Projekts eines industriellen Automatisierungswerks gemeinsam mit dem Betrieb fest, dass die Ausfallzeiten des Systems wichtiger sind als neue Funktionen. Er arbeitete an SLA, Notfallszenarien und spezifizierte konkrete Kennzahlen.