Was ist der Unterschied zwischen funktionalen und nicht funktionalen Anforderungen, und warum sind die nicht funktionalen so wichtig?

Funktionale Anforderungen sagen, was das System tut; nicht funktionale sagen, wie gut es das tun muss. Performance, Verfügbarkeit, Sicherheit, Barrierefreiheit und Aufbewahrungsfristen sind typisch. Sie sind wichtig, weil sie architektonisch sind: du kannst ein Antwortzeitziel oder einen siebenjährigen Audit Trail nicht spät noch anflanschen, ohne alles umzubauen. Hol dafür früh Zahlen, denn akzeptabel ist keine testbare Anforderung.

Funktional ist, was es tut, nicht funktional ist, wie gut es das tun muss. In der Praxis bringt mich die zweite Gruppe in Schwierigkeiten, wenn ich schludrig bin, weil sie die Architektur prägt. Wenn ein Report in unter zwei Sekunden zurückkommen muss, oder das System einen Audit Trail sieben Jahre lang halten muss, oder es mit einem Screenreader funktionieren muss, dann fallen diese Entscheidungen in den ersten Wochen, sonst kosten sie später ein Vermögen. Ich jage also Zahlen statt Adjektiven. Schnell ist keine Anforderung; 95. Perzentil unter zwei Sekunden bei tausend gleichzeitigen Nutzern schon. Diese Zahlen muss ich mir meistens selbst besorgen, denn wenn ich einen Business-Stakeholder frage, wie schnell es sein muss, lautet die Antwort schnell, und wenn ich frage, was das aktuelle System schafft, weiß es niemand. Also messe ich das bestehende und nutze das als Einstieg in ein echtes Gespräch.