Nicht funktionale Anforderungen

Was ist eigentlich eine nicht funktionale Anforderung? Und was ist der wesentliche Unterschied zu einer funktionalen Anforderung? Und was bedeutet das für einen nicht funktionalen Test im Vergleich zu einem funktionalen Test?
Diese 3 Fragen möchte ich in diesem Artikel beleuchten.
Ich komme also zuerst zu der Frage, was eine nicht funktionale Anforderung überhaupt ist. Nun wie der etwas sperrige Name schon sagt, ist es eine Anforderung, gewünschte Eigenschaften beschreibt, die keine Funktion sind. Das können Eigenschaften sein, wie Sicherheit, Bedienbarkeit, Performanz und so weiter. Die DIN 66272 (https://de.wikipedia.org/wiki/DIN_66272) beschreibt die Qualitätsmerkmale von Software übereinstimmend mit den in der ISO/IEC 9126 definierten Hauptmerkmalen der Softwarequalität. Diese sind Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit.
Dementsprechend sind alle Anforderungen, die nicht das Qualitätsmerkmal „Funktionalität“ betreffen nicht-funktionale Anforderungen.
Soweit, so gut. Aber welcher Unterschied ergibt sich nun bei der definition von funktionalen und nicht-funktionalen Anforderungen?
Der erste Unterschied, den ich hervorheben möchte ist, dass uns dann wenn wir uns ein neues oder verbessertes Produkt ausdenken  dieses fast immer vor allem durch seine Funktionen beschreiben. „Mein neuer Fernseher soll Ultra-HD können und DVBT-x empfangen können“. Dass das Gerät zuverlässig ist und keine 20 Minuten zum umschalten benötigt, das wollen wir zwar auch haben, aber davon gehen wir aus. Dass uns diese Eigenschaft wichtig ist, merken wir aber oftmals erst dann, wenn sie nicht (ausreichend) gegeben ist.
Auf der anderen Seite würde wohl niemand, fast egal bei welchem Produkt die Frage: „Soll es Sicher sein?“, „Soll es schnell sein?“ oder soll es Robust sein?“ verneinen. Nur wie viel davon brauchen wir und sind wir im Zweifel bereit dafür zu zu bezahlen? Anders gesagt: Mehr Sicherheit ist nie schlecht, aber will ich auch den Preis für die Sicherheit bezahlen, die ich gar nicht brauche? Stellen wir uns vor ich lasse ein Haus bauen, dann habe ich natürlich die Anforderung, dass es „Robust“ ist. Es muss nicht nur gutem Wetter wiederstehen, auch den jährlichen Herbststurm soll es möglicht unbeschadet überstehen. Aber wäre es nötig, dass das Haus auch im Falle eines Flugzeugabsturzes auf dieses Haus noch unbeschädigt bleibt? Dies zu realisieren hätte vermutlich ganz massgebliche bauliche Auswirkungen, die zum einen anderen Anforderungen wie zum Beispiel Aussehen oder Fensteranzahl/Grösse zuwiederlaufen könnten und höchstwarscheinlich auch sehr viel höhere Kosten verursachen würden. Für mein Einfamilienhaus könnte ich wohl damit leben, dass mein Haus weniger Robust ist.
Der zweite wesentliche Unterschied ist, dass duch die Definition einer Funktion i.d.R. bereits detailliert geregelt ist, wann diese Funktion gegeben ist und wann nicht. Daher wird sich ein darauf basierender Testfall auch immer eindeutig auf gegeben oder nicht gegeben selbst erklären. Es bedarf bei der Testdurchführung keiner Interpretation mehr.
Bei nicht funktionalen Eigenschaften ist dies oft anders, was aber schon damit anfängt wie genau diese Beschrieben sind. Nicht selten hört man Sätze wie „Es soll so schnell wie möglich sein“ oder „Sicher muss es aber auch sein“. Das Problem ist, dass dieses nicht nur nicht umsetzbar ist (s. auch „Kaufe Zeit für Zeit“ (https://performanceblog.org/?p=88), es ist vor allem nicht überprüfbar. Eine solche Anforderung käme in etwas der Anforderung „Das System soll so viele Funktionen wie möglich haben“. Dass aber jemals irgendwo eine Software oder ein Produkt erfolgreich entwickelt wurde, deren einzige funktionale Anforderung „so viel wie möglich“ gewesen wäre ist mir nicht bekannt.
Es ist nicht möglich ein System zu entwickeln, dass (vollkommen) „Sicher“, „Schnell“ oder „Benutzerfreundlich“ ist. Und vor allem kann man dieses nicht prüfen, wenn es so grob spezifiziert wurde. Daher ist es für jeden nicht-funktionalen Test und so auch für den Last-und Performancetest unabdingbar, dass solche testbaren bzw. testbar formulierten Anforderungen vorliegen.
Wie könnten also zum Beispiel Anforderungen für einen Last- und Performancetest aussehen?
Wichtig ist, dass eine dedizierte Zuordnung möglich ist zu bestimmten Aktionen aber auch zu den Rahmenbedingungen.
Fangen wir mit der Geschwindigkeit (Performanz) an un nehmen wir einen Webshop als Beispiel.
Wenn es sich um ein Endnutzersystem handelt, orientiert sich eine sinnvolle Geschwindigkeitsvorgabe nicht am technisch machbaren, sondern am Bedarf des Nutzers. Wenn ich mich bei meiner Pizzabestellung durch den Katalog clicke erwarte ich unmittelbare Ergebnisse, wenn meine Zahlungsdaten überprüft werden habe ich als Benutzer Verständnis, dass dies einige Sekunden dauern kann.
Daher müsste man streng genommen für jede mögliche Aktion auch festlegen, wie schnell das System das jeweilige Ergebnis präsentieren muss. Dies ist in der Praxis allerdings kaum machbar. Ein guter Ausweg ist die Kategorisierung und/oder Festlegung von Standardzeiten und Ausnahmen:
Die Antwortzeit für alle Seiten soll auch in Stosszeiten 1 Sekunde im durchschnitt nicht überschreiten und darf 3 Sekunden im 95% Percentil nicht überschreiten.

  • Suchanfragen sollen jederzeit im 95% Percentil in weniger als 5 Sekunden erldigt werden.
  • Die Prüfung der Zahlungsdaten und andere Seiten, bei denen das System auf externe Dienste angewiesen ist sollen nicht länger als 5 Sekunden dauern, den Benutzer aber in jedem Fall über den Status der externen Abfragen informieren.
  • Tritt im Sinne der Anforderungen eine Überlastung von mehr als 100% zur angenommenen Spitzenlast auf, so dürfen die Antwortzeiten die o.g. Anforderungen überschreiten, dass System darf Anfragen/Prozesse in diesem Fall abbrechen muss jedoch in einem definierten Zustand verbleiben.

In diesem Beispiel wurde eine Gruppierung von Aktionen vorgenommen und es ist eine Querverbindung zur Lastsituation vorgenommen worden. Auch andere Randbedingungen wie die Menge des Datenbestandes etc. könnten hier genannt werden.
Für die obigen Anforderungen wären jetzt noch die Mengen/Last Anforderungen notwendug. Die könnten beispielsweise so lauten:

  • Das System muss in einer Stunde das Volumen von 10.000 Besuchern und 500 Käufen verarbeiten können ohne, dass es zu beeinträchtigungen kommt. (Spitzenlast)

Am Ende steht und fällt die Nützlichkeit eines nicht-funktionalen Tests mit den Anforderungen. Sind diese nicht genau forumliert, so kann auch die Aussage des Tests nur ungenau werden.

Sind diese Anforderungen im Sinne des Endbenutzers zu lasch, so entsteht ein schlechte Performanceerfahrung. Sind sie unnötig streng, so verursachen sie unnötige Kosten durch unnötige Optimierungen.
Auf der anderen Seite ist eine wissenschaftlich genaue Auswertung der Benutzerbedürfnisse natürlich auch sehr aufwendig und dieser Aufwand ist natürlich nicht für jede Anwendung gerechtfertigt. Studien, wie sie von Google (z.B. https://research.googleblog.com/2009/06/speed-matters.html) oder Amazon, Akamai oder anderen immer mal wieder veröffentlicht werden, können eine Hilfe sein. Nicht vergessen sollte man dabei jedoch, dass all diese Erhebungen immer eine bestimmte Zielgruppe in einem bestimmten Umfeld haben. Dieser ist nicht immer 1 zu 1 auf jede Anwendung übertragbar.

1 Gedanke zu “Nicht funktionale Anforderungen”

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.