Einleitung

Während funktionale Anforderungen die Sprint-Backlogs dominieren, entscheiden nichtfunktionale Anforderungen (NFA) über die Lebensdauer und Wartungskosten einer Anwendung. Ein Plädoyer für das „Wie“ statt nur das „Was“.

In der agilen Praxis erleben Entwicklungsteams häufig ein Paradoxon: Das Product Backlog ist gefüllt mit User Stories, die funktionale Wünsche der Stakeholder abbilden. Dennoch gilt das Projekt am Ende als gescheitert, wenn die Anwendung zwar tut, was sie soll, aber zu langsam, instabil oder schlecht wartbar ist. Schuldzuweisungen treffen meist die Entwickler. Die Ursache liegt jedoch früher: in der systematischen Vernachlässigung nichtfunktionaler Anforderungen.

Das Dilemma: Funktion vs. Qualität

Die Anforderungsanalyse unterscheidet zwei Kategorien:

1. Funktionale Anforderungen (FA): Sie beschreiben das WAS.
   • Beispiel: „Admin kann Shop sperren“ oder „Vollbildanzeige für Produkte“.
   • Charakteristik: Offensichtlich, direkt vom Stakeholder geäußert, umsatzrelevant und einfach abzurechnen.
2. Nichtfunktionale Anforderungen (NFA): Sie beschreiben das WIE.
   • Beispiel: Antwortzeit unter 100ms, 99,9% Verfügbarkeit, Testbarkeit des Codes.
   • Charakteristik: Abstrakt („soll schnell sein“), schwer zu erheben, wird oft als selbstverständlich vorausgesetzt.

Das Problem: In vielen Projekten machen NFAs weniger als 10 % der definierten Anforderungen aus. Das ISO 9126 Modell (und dessen Nachfolger) zeigt jedoch, dass die „Funktionalität“ nur eine von sechs Hauptkategorien der Softwarequalität ist. Die restlichen fünf – Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit – werden ausschließlich durch NFAs gesteuert.

Die Kostenfalle: Das Ampel-Modell der Fehlerbehebung

Ignorierte Anforderungen führen zu Fehlern. Die Art der Anforderung bestimmt dabei den Zeitpunkt des Auftretens und die Kosten der Behebung:

• GRÜN (Funktionale Fehler):
  • Symptom: Ein Button funktioniert nicht.
  • Erkennung: Sofort.
  • Kosten: Gering. Meist ist nur eine lokale Code-Stelle betroffen.
• GELB (Benutzbarkeit/Effizienz):
  • Symptom: Der Workflow ist umständlich oder die Anwendung reagiert träge.
  • Erkennung: Mittelfristig durch User-Feedback.
  • Kosten: Mittel bis Hoch. Konzepte müssen überarbeitet werden, Änderungen betreffen mehrere Module.
• ROT (Wartbarkeit/Architektur):
  • Symptom: Die Entwicklungsgeschwindigkeit sinkt massiv, Seiteneffekte bei Änderungen häufen sich (Regressions-Bugs).
  • Erkennung: Spät (oft erst nach Jahren).
  • Kosten: Katastrophal. Dies betrifft die interne Qualität. Da der Kunde dies nicht direkt sieht („Code-Qualität ist mir egal“), wird hier oft gespart. Die Behebung erfordert oft Refactorings der gesamten Architektur oder einen Rewrite.

Ursache und Lösung: Technische Kompetenz im Requirement Engineering

Der Hauptgrund für das Fehlen von NFAs liegt in der Rolle des Product Owners (PO). POs stammen oft aus der Fachdomäne. Sie können fachliche Wünsche priorisieren, verfügen aber selten über das technische Tiefenwissen, um Fragen nach Eventual Consistency, Skalierbarkeit von Microservices oder Testabdeckung zu stellen.

Die Lösung:
Die Erhebung von Anforderungen darf kein Monolog zwischen PO und Stakeholder sein. Ein Softwarearchitekt oder erfahrener technischer Lead muss zwingend an den Requirements Engineering Workshops teilnehmen.

Seine Aufgabe ist es, die vagen Wünsche der Stakeholder („soll gut bedienbar sein“) in messbare technische Kriterien zu übersetzen (Qualitätsattribute nach ISO) und die unternehmensinternen Anforderungen an die Wartbarkeit (interne Sicht) gegen die Kundenwünsche (externe Sicht) abzusichern. Nur so lässt sich die Kostenexplosion im „roten Bereich“ verhindern.