Kolumne: Qualität fällt nicht vom Himmel

Req4Arcs: Qualitätsstandards mit ISO-25010

Peter Hruschka, Gernot Starke

© S&S Media

In den vergangenen drei Folgen haben Sie erfahren, wie Sie systematisch mit funktionalen Anforderungen umgehen können. Sie wissen jetzt, wie Sie die richtigen fachlichen Prozesse mitsamt den dafür notwendigen fachlichen Daten ermitteln und kommunizieren, Sie kennen User Stories, Abläufe und Features. Ihre Anwendung kann jetzt (beispielsweise) Kinokarten verkaufen. Aber da war doch noch was: Die Zahlungen der Kinokarten sollen gegen unbefugte Zugriffe geschützt und vor allen Dingen nicht-abstreitbar erfolgen (Stichwort: IT-Sicherheit). Außerdem muss der gesamte Bezahlvorgang in weniger als dreißig Sekunden abgeschlossen sein (Stichworte: Performance) und natürlich niemals ausfallen (Stichwort: Zuverlässigkeit). Diesen schwierigen Themen wenden wir uns in den nächsten Folgen zu – den Qualitätsanforderungen.

Mehr als „gut“ oder „schlecht“

Kleine Vorbemerkung: Wir sprechen hier von „Produktqualität“ und meinen damit die Qualität unserer (Software-)Systeme. Das Thema „Prozessqualität“ lassen wir an dieser Stelle außen vor.

Qualität ist ein vielschichtiges Biest – wählen wir ein Beispiel aus dem realen Leben. Sie trinken gerne Tee und laden ein paar Leute zu einer Teeverkostung ein. Sie möchten gerne „hohe Qualität“ ausschenken – aber was ist das genau? Die einen mögen Grüntee aus Japan, blassgrün in der Tasse, bevorzugt den zweiten (mit 75 Grad Celsius Wassertemperatur) oder gar dritten Aufguss (über 80 Grad) – natürlich ungesüßt. Andere bevorzugen die chinesische Variante mit Jasmin, natürlich im ersten Aufguss. Die nächsten hätten gerne Schwarztee in der arabisch/türkischen Variante, schön lange gekocht mit viel Zucker serviert. Unsere britischen Kollegen haben ihre eigene Meinung und trinken nordindischen Assam-Schwarztee mit etwas Milch. Und dann waren noch diejenigen, die den Spätabend-geeigneten Kräutertee bevorzugen. Ach ja, eine Kollegin hätte gerne Bio und schadstoffarm.

Sie sehen: schon in einem einfachen Beispiel spielen, neben der (funktionalen) Anforderung „wir wollen Tee trinken“, noch weitere Eigenschaften des betroffenen Produkts eine große Rolle: Geschmack (subjektiv), Farbe, Temperatur, Zubereitungsdauer, Zusatzstoffe (Zucker, Aromen), Herkunftsland und so weiter. Manche dieser Eigenschaften nehmen wir implizit an (und hoffen, dass in der EU käufliche Teesorten geltende Schadstoffobergrenzen einhalten).

Wie soll das erst mit dem viel komplexeren Thema Software sein, bei der es eine Vielzahl möglicher weiterer Eigenschaften außer der reinen Funktionalität geben kann? Wo aber ebenfalls eine größere Zahl möglicher Stakeholder explizite und implizite Wünsche an die (Qualitäts-)Eigenschaften von Systemen haben?

Trauerspiel Praxis

In unserer Praxis realer Entwicklungsprojekte – in verschiedenen Branchen – gibt es einen gemeinsamen Nenner, nämlich den traurigen Stand (fehlender) expliziter Qualitätsanforderungen. Wir haben recht selten erlebt, dass es eine konsistente, mit Stakeholdern abgestimmte Übersicht solcher Qualitätsanforderungen gibt, auf die sich Entwicklungsteams dann bei der Entscheidungsfindung in Architektur und Entwicklung stützen und verlassen könn(t)en. Nada. Nichts. Gähnende Leere. Verschämte Blicke aus dem Fenster – das erleben wir bei der Nachfrage nach Qualitätsanforderungen ständig.

Aber zwei gute Nachrichten gibt es. Erstens: Sie können leicht Abhilfe schaffen (d. h. so schwer ist das Thema in Wirklichkeit gar nicht), und zweitens haben eine Menge schlauer Leute vor Ihnen dieses Thema ziemlich gründlich aufgearbeitet (sprich: Es gibt mit ISO-25010 einen nützlichen Standard, siehe [1] und Abb. 1).

Abb. 1: ISO 25010 im Überblick

Abb. 1: ISO 25010 im Überblick

Qualitätsanforderungen sind Architekturtreiber

Qualitätsanforderungen kommt häufig eine fundamentale Bedeutung für Architektur und Entwicklung zu – sie gehören damit oft zu den Architekturtreibern, neudeutsch „architecturally significant requirements“. Solche Anforderungen nicht oder nicht rechtzeitig zu kennen, kann zu falschen Architekturentscheidungen führen, die sich teils gar nicht und teils nur mit erheblichem Aufwand korrigieren lassen. Eigenschaften wie Sicherheit, Skalierbarkeit, höchste Robustheit können nämlich nicht einfach additiv zugefügt werden. Einen Bungalow können Sie auch nicht einfach auf achtzehn Etagen aufstocken, wenn Ihrem Stakeholder aufgefallen ist, dass es nicht vier, sondern hundert Personen sind, die darin leben sollen.

An dieser Stelle hören wir schon Ihren inneren Protest: „Ja, aber das kann ich doch im Vorfeld noch gar nicht wissen“. Wir möchten auf keinen Fall zurück zu Wasserfall und Vorabspezifikation, sondern zu einem intelligenten, angemessenen und vor allem expliziten Umgang mit Qualitätsanforderungen. Das bedeutet insbesondere, Qualitätsanforderungen bereits zusammen mit funktionalen Anforderungen zu bearbeiten, und nicht auf „irgendwann später“ zu verschieben. Wir behaupten, dass in vielen Fällen die wesentlichen (d. h. kritischen und architekturrelevanten) Qualitätsanforderungen zumindest im Groben schon recht frühzeitig bekannt sind.

Qualität bezieht sich auf Funktionalität

Qualitätsanforderungen beziehen sich entweder direkt auf Funktionen des Systems oder des Produkts (z. B. „Zu dem selektierten Produkt aus der Kategorie XY soll der Nettoverkaufspreis innerhalb von maximal 400 Millisekunden ermittelt und angezeigt werden) oder aber auf begleitende Prozesse (z. B. „Eine zusätzliche Instanz des Pricing Service fährt innerhalb von 15 Sekunden hoch.). Manchmal liegt der Geltungsbereich bei einzelnen Funktionen und manchmal bezieht sich eine Qualitätsanforderung auf eine Menge von Funktionen (z. B. „Alle Suchoperationen nach Artikeln liefern nach spätestens 400 Millisekunden die ersten bis zu 10 Treffer“). In seltenen Fällen bezieht er sich auch auf alle Funktionen eines Systems (z. B. „Alle Funktionen der grafischen Oberfläche können mit maximal zwei Tastendrucken oder Klicks abgebrochen werden“).

Durch diesen engen (und inhärenten!) Bezug zu Funktionen wundert es uns, dass sich der Begriff „nichtfunktionale Anforderungen“ so lange gehalten hat – wir halten ihn für inhaltlich irreführend (siehe Textkasten).

Vermeiden Sie den Begriff „Nichtfunktional“!

Immer noch verwenden viele Teams und Unternehmen den Begriff „Nichtfunktionale Anforderungen“ als (schlechten) Ersatz für das, was sie darunter wirklich verstehen – nämlich Qualitätsanforderungen.
Lassen Sie uns das kurz an einem Beispiel aus dem Maschinenbau oder der Produktionstechnik erklären: Wenn Sie zu einem Ingenieur sagen: „Diese Maschine ist nicht funktional“, so bedeutet das: „Die Maschine verfehlt den Einsatzzweck, ist z. B. falsch konstruiert oder wird nicht ihrem Zweck entsprechend eingesetzt.“

Das wollen wir jedoch in der IT mit dem Begriff „nichtfunktional“ überhaupt nicht ausdrücken, sondern möchten zusätzlich zu einer funktionalen Anforderung noch ein paar weitere (Qualitäts-)Anforderungen erklären – also die betroffene Funktion noch detaillierter erläutern.

Vorsicht, der folgende Satz enthält eine doppelte Verneinung: Sie möchten nicht das Nichtfunktionieren Ihres Systems spezifizieren (das wäre völliger Humbug), sondern dessen Qualität konkreter beschreiben. Der ISO-Standard zum Thema Softwarequalität [1])

Aber Sie wissen ja: „Naming things is hard“. In unserem Fall ist die Lösung sehr einfach: Nennen Sie das Kind beim Namen und sagen Sie „Qualitätsanforderungen“ dazu. Das ist sachlich korrekt – und ein paar Buchstaben haben Sie obendrein auch noch gespart!

Damit haben wir in der Praxis oft eine m:n-Beziehung zwischen funktionalen Anforderungen und den für diese Funktionen geltenden Qualitätsanforderungen. Das erschwert oft Erfassung und Management von Qualitätsanforderungen: Man kann sie (im agilen Umfeld) nicht immer einfach auf ein Story-Kärtchen schreiben, da sie sich möglicherweise auf mehrere Stories beziehen. Doch wo die Möglichkeit besteht, werden wir die Stories einfach mit Qualitätsanforderungen anreichern. Sollte man dann merken, dass es mehrere Funktionen (Stories) mit identischen oder sehr ähnlichen Qualitätsanforderungen gibt, sollten diese Anforderungen extrahiert und getrennt gehalten werden – und verlinkt werden.

Qualitätsmodelle als Checklisten

Die ISO-Standardisierungsorganisation hat mit dem ISO-25010 ein umfassendes Modell für Softwarequalität geschaffen (Abb. 1). Alle darin genannten Begriffe hat ISO ziemlich genau definiert. Das im Requirements Engineering bekannte VOLERE schlägt ein alternatives Kategorisierungsschema vor, und für eingebettete oder sicherheitskritische Systeme gibt es eigene Standards, die Qualitätseigenschaften wie Safety und Security in den Mittelpunkt stellen (z. B. [2] und [3]).

Alle diese Standards beschreiben die einzelnen Qualitätseigenschaften abstrakt oder generisch. Beispielsweise spricht ISO-25010 von „Time Behavior“, in Abbildung 1 im Zweig „Performance Efficiency“ zu finden. Für das eigene System wünscht man sich jedoch ein konkretes Zeitverhalten, d. h. man muss die abstrakten oder generischen Begriffe des Standards für das eigene System konkretisieren.

Auch Qualitätsanforderungen brauchen Kriterien

Jetzt wird es „metamäßig“, denn wir haben eine Anforderung an die Anforderungen. Ebenso wie für funktionale Anforderungen fordern wir, dass auch Qualitätsanforderungen ganz explizit Abnahme- oder Erfüllungskriterien haben sollten. Man sollte also bezüglich der eigenen Qualitätsanforderungen objektiv entscheiden können, ob und wann diese Anforderung erfüllt oder nicht erfüllt ist. Bitte verwechseln Sie diese klaren Kriterien nicht mit automatisierten Tests: Uns geht es bei den Kriterien erst einmal um die klare Entscheidbarkeit. Als Architekt sollte man genau wissen, wann und ob das eigene System die wichtigen Qualitätseigenschaften ausreichend erfüllt.

Wie das genau geht (beispielsweise mit Qualitätsszenarien), erklären wir in der nächsten Folge – doch die konkrete Entscheidbarkeit, ob eine Qualitätsanforderung erfüllt ist, war uns bereits an dieser Stelle ein Anliegen.

Fazit

Lassen Sie sich nicht von den vielen agilen Büchern in die Irre führen, die hauptsächlich predigen, Epics, Features und Storys im Product Backlog zu sammeln. Diese Funktionalität ist zwar wichtig, allerdings nur die halbe Miete. Viele Funktionen brauchen explizite Qualitätsanforderungen. Machen Sie einfach einen der oben genannten Qualitätsstandards zu Ihrer Checkliste und fragen Sie Stakeholder gezielt nach deren Qualitätswünschen. Bleiben Sie nicht auf der abstrakten Schlagwortebene hängen, sondern präzisieren Sie diese Qualitäten bis hin zu prüfbaren Abnahmekriterien.

Stay tuned: Wie das konkret aussehen kann, zeigen wir Ihnen in den nächsten Folgen.

Verwandte Themen:

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: