[Requirements] Was „nicht funktionale Anforderungen“ wirklich sind!

Schon der Begriff „nicht funktional“ macht stutzig. Er beschreibt in sich nichts Konkretes, sondern etwas, was nicht ist. Aus einfachster Küchenpsychologie wissen wir, dass wir uns „Nichts“ nicht vorstellen können. Die Sache mit funktionalen Anforderungen hingegen ist klar: das sind Anforderungen die konkrete Funktionen zu einem bestimmten vorstellbaren Zeitpunkt (z.B. zu heute) umsetzen. Aber was genau verbirgt sich hinter dem Begriff der nicht funktionalen Anforderungen? Manche definieren nicht funktionale Anforderungen als „Constraints„, also als Begrenzungen, die dem Entwicklungs- ode Designteam auferlegt werden. Wobei jede solche Begrenzung die Designmöglichkeiten weiter einschränkt. Doch auch bei dieser Definition fällt es mir schwer vorzustellen, dass z.B. Erweiterbarkeit der Software eine Begrenzung sein soll!

Wenn man sich Definitionen nichtfunktionaler Anforderungen anschaut, findet man abstrakte Begriffe die auf „-keit“ enden: Analysierbarkeit, Wiederverwendbarkeit, Erweiterbarkeit, Prüfbarkeit etc. (ISO/IEC 9126) In diesen Begriffen sah ich schon immer Schwierigkeiten, weil sie verdinglichte Tätigkeiten\Prozesse darstellen und somit schwierig oder nur Umwege mit Zahlen greifbar sind. Denkt man genauer über diese Bezeichnungen nach, stellt man fest, dass sich hinter solchen Begriffen meist zwei Ursprünge verbergen. Zum Einen temporaler Ursprung: Prozesse, die zum späteren Zeitpunkt ausgeführt werden: der Prozess der weiteren Analyse, der Prozess der späeteren Erweitertung, der Prozess der Wiederverwendung. Zum Anderen attributiver Ursprung: Prozesse die gleichzeitig mit funktionalen Anforderungen ausgeführt werden: Perofrmance, Sicherheit.

Man merkt schnell, der Begriff „nicht funktionale Anforderungen“ ist nicht homogen. Und darin liegt die Krux dieser Bezeichnung. Die Betrachtung dieses Begriffs bedarf einer ganz anderen Denk- und Herangehensweise, die sich nicht nur an System-, sondern auch an Prozessbegebenheiten ausrichtet, in denen funktionale Anforderungen eingebettet sind oder die sich auf funktionale Anforderungen auswirken können. In Grenzfällen können sie sogar als Enabler für zukünfitge Prozesse (einfacher Ausbau) gesehen werden.

Funktionale und nicht funktionale Anforderungen haben somit zwar beide etwas mit Anforderungen zu tun, beziehen sich aber meist auf unterschiedliche Zeitreferenzen oder Abstraktionsebenen, was viel Verwirrung stiften und zu blinden Frecken im Anforderungsprozess führt. Besser ist, man stellt sie sich als gänzlich getrennte Abstraktionsbereiche vor.

Kurzinfo: This article descusses a process driven definition for „non funtional“ requirements.

Anton

Anton

Anton ist freiberuflicher Software-Ingenieur und Projektleiter mit den Schwerpunkten: Prozessdesign, strukturierte Business Analyse / Fachkonzeption sowie fachliche Entscheidungsunterstützung.

More Posts - Website