Die Krux mit der Erwartungshaltung

Der Nachfrage nach IT-Systemen ist nach wie vor ungebremst. Die allermeisten dieser Lösungen werden aufgrund eines geschäftlichen Bedarfs umgesetzt. Ob nun als konfektionierte Standardsoftware, als konfigurierbare Cloud-Lösung oder gar als massgeschneiderte Individualsoftware; Ausgangslage sind immer mehr oder weniger wohlformulierte Anforderungen. Anforderungen, die den Einsatzbereich, die Anwendungsfälle und die Spezialfälle – also die Funktion der Software – beschreiben. Diese Anforderungen beziehen sich normalerweise auf einen bestimmten Fachbereich und sind oftmals auch nur in diesem Kontext verständlich. Sie beschreiben, was die Lösung können soll.

Was sind nicht-funktionale Anforderungen?

Darüber hinaus erwarten wir von einem IT-System immer ein bestimmtes Verhalten, das dem Einsatzgebiet entspricht oder entsprechen sollte. Die Lösung soll schnell reagieren, rund um die Uhr verfügbar sein, sicher vor unbefugtem Zugriff sowie robust auf Fehler reagieren. Und sie soll einfach wartbar, gut in eine bestehende Systemlandschaft integrierbar, wiederverwendbar und skalierbar sein. Diese Anforderungen beschreiben, wie sich die Lösung verhalten soll. Sie werden im Gegensatz zu den funktionalen Anforderungen auch nicht-funktionale Anforderungen (NFA), allgemeine Systemeigenschaften, FURBS oder Qualitätsmerkmale genannt. Sie sind oftmals sehr viel verständlicher und allgemeiner formuliert als die funktionalen Anforderungen. Dafür ist der Umgang mit ihnen umso schwieriger. So sind etwa die Auswirkungen auf die Kosten erheblich und sie sind in vielen Fällen nur mit grossem Aufwand und erst spät im praktischen Einsatz zu messen.

Und warum tun wir uns damit schwer?

Renommierte Experten in Sachen Anforderungsmanagement haben über viele Jahre hinweg versucht, den Gründen für diese Schwierigkeiten auf die Spur zu kommen. So etwa der ehemalige Direktor des Instituts für Informatik der Universität Zürich, Martin Glinz, der die Ursache für unsere Schwierigkeiten in seinem vielzitierten Konferenzbeitrag "On Non-Functional Requirements" aus dem Jahr 2007 damit begründet, dass keine etablierte und eindeutige Definition für NFAs vorliegt. Er stiess in seiner Untersuchung auf elf verschiedene Definitionen. Selbst die ISO/IEC-9126-Normierung hat nicht geholfen, wie ein Team der Technischen Universität München 2016 im Rahmen seiner Recherche "Are 'Non-functional' Requirements really Non-functional?" nachgewiesen hat. Zu ungenau sind die Anforderungen formuliert und damit sind sie schwierig zu analysieren und zu testen. Und es wird nicht besser; gemäss einer im März dieses Jahres veröffentlichten Studie "A Qualitative Study on Non-Functional Requirements in Agile Software Development" der Technischen Universität Danzig erschwert die agile Vorgehensweise mit Fokus auf die schrittweise Umsetzung von funktionalen Anforderungen den Umgang mit NFAs, da sie oftmals zu Beginn eines Vorhabens erfasst und dann nicht mehr systematisch angegangen werden.

Was könnte helfen?

Das einfachste Mittel: sich auf präzise formulierte und messbare nicht-funktionale Anforderungen konzentrieren. Die umfangreichen Untersuchungen zeigen zudem auf, dass Antwortzeiten, Sicherheit, Usability und Wartbarkeit zu den wichtigsten Anforderungen gehören. Die angesagte Erwartungshaltung wäre so gesehen also "reduce to the max".