Qualitätsanforderungen spielen eine ganz zentrale Rolle in der Entwicklung eines Systems, gerade für das Architekturdesign. Wie man so schön sagt: Funktionalitäten können mit jeder Architektur umgesetzt werden, aber die Qualitätsattribute sind die prägenden Aspekte für die Architektur eines Systems. Ob das genau so stimmt, sei mal dahingestellt, klar ist aber, dass Faktoren wie Verfügbarkeit, Performance, Skalierbarkeit, Wartbarkeit, Flexibilität oder Betreibbarkeit ganz wesentlich auf die Gestaltung der Architektur eines Softwaresystems einwirken.

Obwohl eigentlich größtenteils Einigkeit über die Wichtigkeit von Qualitätszielen herrscht, werden diese doch häufig ziemlich stiefmütterlich behandelt. Klar, wir machen uns ein paar Gedanken über Modularisierung und auch über Sicherheit, aber dass Qualitätsanforderungen strukturiert aufgeschrieben und bearbeitet werden, ist eher eine Seltenheit. Das ist besonders ungünstig, weil gerade Qualitätsanforderungen meist „crosscutting“ sind, das heißt, sie wirken sich an den unterschiedlichsten Stellen über das gesamte System hinweg aus.

Das bedeutet, dass es beispielsweise nicht gut funktionieren wird, erstmal die Funktionalität des Systems zu bauen und sich später um die Performance zu kümmern. Ich kann nicht einfach eine Performance-Komponente an einer Stelle einbauen, sondern ich muss mich umfassend, ganzheitlich und vor allem früh um das Thema kümmern und es beim Systementwurf gleich mitdenken. Da heißt nicht, dass ich gleich bis ins Letzte optimieren muss, ich darf mir aber auch nichts verbauen, weil ich die wichtigsten Qualitätsanforderungen nicht im Blick behalte. Ansonsten werde ich später gezwungen sein, das System großflächig und tiefgreifend umzubauen. Für das Vorankommen im Projekt und den späteren Projekterfolg ist das nicht zuträglich.

Wie arbeiten wir nun aber sinnvoll mit Qualitätsanforderungen? Die grundlegenden Aktivitäten sind eigentlich ziemlich naheliegend: Qualitätsanforderungen müssen von Stakeholdern erhoben werden, sie müssen möglichst konkret und messbar erfasst (aufgeschrieben!) und dafür Lösungen entwickelt werden. Wir könnten nun für jede der genannten Aktivitäten sehr in die Tiefe gehen, ich möchte aber folgend nur auf einige wenige Aspekte bei der Bearbeitung von Qualitätsattributen eingehen, die nach meiner Erfahrung in den unterschiedlichsten Unternehmen immer wieder unzureichend oder ungeschickt angegangen werden.

Qualitätsanforderungen müssen verhandelt und priorisiert werden

Die Quelle für Qualitätsanforderungen sind Stakeholder. Stakeholder haben Bedarfe (Concerns), das heißt, bestimmte Dinge sind ihnen wichtig für das System. Aus diesen Bedarfen lassen sich Qualitätsanforderungen für das System ableiten. Allerdings gibt es sehr unterschiedliche Stakeholder, die sehr unterschiedliche Concerns haben. Während beispielsweise den Sales-Leuten eine schnelle Time to Market besonders wichtig ist, priorisieren Entwickler:innen typischerweise Wartbarkeit höher, Anwender:innen finden häufig eine gute Benutzbarkeit besonders wichtig, während das Operations-Team eine hohe Zuverlässigkeit priorisiert. Es gibt also typischerweise keine Einigkeit zwischen den beteiligten Personen und dass Qualitätsanforderungen sich gegenseitig negativ beeinflussen können, macht diese Situation noch schlimmer.

Diesen (potentiellen) Konflikt müssen wir aber unbedingt auflösen, weil wir ansonsten keine Zielstellung haben, für die wir eine Lösung entwickeln können. Das heißt, wir brauchen eine einheitliche Sicht im Projekt darauf, was genau die Qualitätsanforderungen sind (mit den konkreten zugehörigen Werten), wie die Priorisierung zwischen ihnen aussieht und auch was explizit als Qualitätsziel ausgeschlossen ist. Die folgenden Tipps können dabei helfen:

• Sprecht mit vielen, unterschiedlichen Stakeholdern im Projekt, um deren Bedarfe und Sichtweisen einzufangen. Einerseits ergeben sich dabei häufig neue und ungeahnte Aspekte, die man vorher überhaupt nicht auf dem Radar hatte. Andererseits bekommt man dadurch ein höheres Commitment und Zustimmung für das Projekt, wenn die Leute das Gefühl haben, dass ihre Bedarfe auch gehört werden. Zur Erhebung der Stakeholder-Bedarfe gibt es viele unterschiedliche Formate, sowohl kollaborative, wie beispielsweise Quality Storming, aber auch einfache Interviews mit ein oder zwei Personen haben wir in der Vergangenheit sehr erfolgreich eingesetzt.
• Aus Bedarfen müssen Qualitätsanforderungen erarbeitet und dann auch aufgeschrieben werden. Wenn also beispielsweise Erweiterbarkeit als Qualität für Stakeholder besonders wichtig ist, müssen wir konkretisieren, was Erweiterbarkeit für unser System bedeutet, das heißt, für was das System gut erweiterbar sein soll und was eine messbare Zielgröße sein soll (bspw. in PT Aufwand für die Realisierung einer Erweiterung). Um Qualitätsanforderungen möglichst präzise und messbar zu erfassen, sind Quality Attribute Scenarios.
• Nicht jeder Stakeholderbedarf ist auch gleich eine Qualitätsanforderung. Bedarfe können sehr unterschiedlich sein und sich auch häufig widersprechen. Gleichzeitig werden die Bedarfe gerne mit viel Inbrunst und in Absolutheit vorgetragen („Wenn es das nicht kann, dann bringt uns das ganze System eigentlich nix.“). Hier braucht es einen Digital Designer oder Product Owner (der Name der Rolle ist irrelevant), der eine ganzheitliche Vision für das Produkt erarbeiten kann und damit auch entscheidet, was tatsächlich zu einer Anforderung wird und was nicht, und auch wie Qualitätsanforderungen zueinander priorisiert sind. Muss diese Entscheidung von einer Gruppe von Personen getroffen werden (Steuerkreis), dann muss der Product Owner eine solche Vision ausarbeiten und einen konkreten Vorschlag als Entscheidungsvorlage erarbeiten. Und dazu gehört dann auch das Erwartungsmanagement gegenüber den Stakeholdern im Projekt.

Qualitätsanforderungen können nicht einfach umgesetzt werden

„Wir brauchen jetzt mal die Qualitätsanforderungen konkret, damit wir Tasks / User Stories erstellen und sie umsetzen können.“ So oder so einen ähnlichen Satz habe ich schon öfter gehört. Er zeigt aber ein fundamentales Missverständnis im Umgang mit Qualitätsanforderungen. Qualitätsanforderungen können nicht einfach umgesetzt werden.

In den allermeisten Fällen ist es nicht möglich, eine Qualitätsanforderung einfach umzusetzen. Stattdessen muss ein Architekturkonzept entwickelt werden, das aufzeigt, wie das System der Anforderung in unterschiedlichen Situationen in seiner Gesamtheit gerecht werden kann. Dazu braucht es zahlreiche Entscheidungen, Komponenten und Mechanismen, die in geeigneter Weise ineinander greifen, um die Anforderung zu erfüllen.

Ein gutes Architekturkonzept zu entwickeln, das einen passenden Lösungsansatz definiert, der gut zu verstehen ist und zu Konsistenz und Einheitlichkeit im System beiträgt, ist keine einfache Aufgabe. Es ist durchaus statthaft, dafür einen eigenen Task einzuplanen, auch wenn dabei kein Code, sondern „nur“ Ideen herauskommen. Dieser Zwischenschritt zahlt sich im Projektverlauf vielfach aus.

Qualitätsanforderungen müssen verfeinert und konkretisiert werden

Häufig herrscht Einigkeit darüber, dass Qualitätsanforderungen konkret und messbar sein müssen, bevor wir dafür Lösungen entwickeln können. Was aus meiner Sicht häufig vergessen wird, ist, dass Qualitätsanforderungen auch verfeinert, aufgeteilt, heruntergebrochen und konkretisiert werden müssen, damit man dafür auch tatsächlich Lösungen entwickeln kann. Dafür einige Beispiele:

Für ein Versicherungssystem könnten wir beispielsweise die folgende Qualitätsanforderung aufstellen:

Änderbarkeit (Top Level): Es wird ein neues Gesetz verabschiedet, dessen Regelungen eine Änderung von Versicherungsbedingungen von Neuverträgen notwendig machen. Die dafür notwendigen Änderungen am Versicherungssystem können immer innerhalb der gesetzlich vorgegebenen Fristen umgesetzt werden.

Das wäre durchaus konkret und ob wir das erfüllen, lässt sich auch problemlos messen. Also, alles gut, oder?

Das Problem ist, dass es einerseits sehr unterschiedliche gesetzliche Änderung mit sehr unterschiedlichen Auswirkungen geben kann und andererseits können die Fristen sehr unterschiedlich sein. So können wir kein Lösungskonzept entwickeln. Wir können das System nicht für alle Arten von Änderungen in der gleichen Weise vorbereiten.

Um uns eine Lösung zu überlegen, um das System in geeigneter Weise auf Änderungen vorzubereiten, müssen wir die unterschiedlichen möglichen Fälle auseinanderziehen. Wir könnten also beispielsweise unterscheiden, ob eine Änderung mit wenigen Wochen oder mit einigen Monaten Vorlauf umzusetzen ist. Außerdem können wir unterscheiden ob für die Änderung nur gewisse Werte anzupassen sind oder ob dafür Änderungen am Code des Basissystems nötig sind. Weiter könnten wir bei notwendigen Änderungen des Basissystems nach der Tiefe der Auswirkungen unterscheiden: ist beispielsweise nur ein Attribut hinzuzufügen oder müssen grundlegende Annahmen verändert werden, und wenn ja, welcher Art? Für unterschiedliche Kombinationen kann ich nun konkrete Szenarien definieren.

Für die folgende Qualitätsanforderung kann ich mir sehr viel besser eine Lösung überlegen:

Änderbarkeit (Verfeinerung 1): Es wird ein neues Gesetz verabschiedet, dessen Regelungen eine Änderung von Versicherungsbedingungen von Neuverträgen notwendig machen. Zwischen Bekanntwerden des neuen Gesetzes und Inkrafttreten der Änderungen liegen zwei Monate, innerhalb derer die dafür notwendigen Änderungen am Versicherungssystem umgesetzt werden müssen. Für die Änderung müssen zwei zusätzliche persönliche Informationen des Versicherungsnehmers erfasst werden und in der Angebotserstellung einbezogen werden. Die Änderungen müssen sowohl im UI, als auch in der Berechnungslogik und in der Persistenz (inklusive Datenbankstruktur) umgesetzt werden. Das für die betreffende Vertragssparte zuständige Entwicklungsteam kann die Änderung innerhalb der gegebenen Frist in jedem Fall umsetzen.

In dieser Weise kann die ursprüngliche, durchaus valide, aber zu grobgranulare Qualitätsanforderung in spezifischere Qualitätsanforderung verfeinert werden. Dies kann ich nun für die genannten anderen Situationen wiederholen und dafür jeweils eigene spezifischere Qualitätsanforderungen definieren, so dass ich eine gute Abdeckung der Änderbarkeitsanforderungen erreichen kann. Wir hacken die Qualitätsanforderung also klein.

Das bedeutet explizit nicht, dass die grobgranulare Anforderung durch die Verfeinerungen ersetzt werden muss. Sie ist ja korrekt und spannt den grundsätzlichen Rahmen auf. Das heißt, ich lasse die Top Level-Anforderung als Basis bestehen und verknüpfe weitere, detailliertere Anforderungen als Verfeinerungen mit ihr.

Hier ein weiteres Beispiel, das wir dann als weitere Verfeinerung unter die Top Level-Anforderung hängen können:

Änderbarkeit (Verfeinerung 2): Es wird ein neues Gesetz verabschiedet, dessen Regelungen eine Änderung von Versicherungsbedingungen von Neuverträgen notwendig machen. Die Änderung erfordert nur die Anpassung von Basiswerten und muss innerhalb von drei Wochen umgesetzt werden. Ein:e Fachanwender:in ist in der Lage die Änderungen selbstständig innerhalb eines Tages umzusetzen. Kein Code muss dafür geändert und keine neue Systemversion dafür deployt werden.

Für solche spezifischeren Anforderung bin ich dann sehr viel besser in der Lage, eine gut passende Lösung zu gestalten. Die Beispiele verdeutlichen auch, dass eine solche Lösung nicht nur technische, sondern durchaus auch prozessuale und organisatorische Anteile haben kann.

Hier sind noch ein paar mehr Beispiele mit einigen weiteren, möglichen Verfeinerungsrichtungen:

• Verfügbarkeit: Das System ist in einem Monat nicht mehr als fünf Stunden für Nutzer:innen unerreichbar.
  Wir können (und sollten) zwischen geplanter Downtime (beispielsweise für Wartungsaufgaben) und ungeplanter Downtime (im Falle von technischen Fehlern) unterscheiden. Bei technischen Fehlern, können wir weiter zwischen Fehlererkennung und Fehlerbehebung differenzieren. Dabei können wir auch unterschiedliche Arten von Fehlern und zwischen Fehlern in unterschiedlichen Systemteilen unterscheiden.
• Performance: Das System soll Nutzereingaben innerhalb von maximal einer Sekunde verarbeiten und der Nutzer:in ein visuelles Feedback geben.
  Hier können wir zwischen unterschiedlichen Arten von Funktionalitäten (bspw. längerlaufende Suchfunktionen) und Systemteilen unterscheiden. Außerdem sollten wir zwischen unterschiedlichen Lastsituationen differenzieren, bspw. zwischen normaler Last und Hochlastszenarien.
• Nutzbarkeit: Ein:e Nutzer:in gibt Daten in das System ein. Das System akzeptiert valide Daten, und weist inkonsistente oder falsche Daten ab. Bei Abweisung von Daten, zeigt das System eine entsprechende Fehlermeldung an, die die zugrundeliegende Ursache erklärt.
  Auch wenn es sich grundsätzlich um eine sinnvolle Anforderung für das System in seiner Gesamtheit handelt, gibt es doch sehr viele unterschiedliche Fälle von „inkonsistenten oder falschen Daten“. Dabei stellt sich die Frage, wie weit wir validieren wollen (und wie viel das dementsprechend kosten soll). Validieren wir beispielsweise Postleitzahlen nur syntaktisch oder stellen wir auch sicher, dass es die Postleitzahl gibt und dass sie zur angegebenen Stadt passt? Validieren wir nur den einzelnen Datensatz oder stellen wir auch die Integrität in Referenzen und Invarianten über verschiedene Datensätze hinweg sicher?

An diesem Beispielen lässt sich gut erkennen, wie viele Möglichkeiten es gibt, Qualitätsanforderungen präziser, detaillierter und spezifischer machen. Schaut doch auch mal die Qualitätsanforderungen in euren Projekten kritisch an und prüft, was ihr da noch herausholen könnt.

Fazit

Zusammenfassend muss man sagen, es reicht nicht, Qualitätsanforderungen messbar als Qualitätsszenarien aufzuschreiben. Wir müssen ganz aktiv an und mit Qualitätsanforderungen arbeiten.

Wir brauchen eine gemeinsame Sicht darauf, was die tatsächlichen Qualitätsanforderungen sind (und welche auch nicht). Die Verantwortung dafür hat die Person, die definiert, was das Produkt ist; ganz alleine entscheiden kann sie das aber häufig nicht. Dazu gehören viele Diskussionen und Verhandlungen mit unterschiedlichen Stakeholdern im Projekt.

Qualitätsanforderungen müssen verfeinert und konkretisiert werden, damit man dafür Lösungen entwickeln kann. Das ist Arbeit, die aktiv vorangetrieben werden muss. Erst wenn diese detailliert und präzise die Anforderungen beschreiben, können Lösungen entwickelt werden. Und „Lösungen“ heißt hier explizit nicht gleich Code zu schreiben, sondern die Gestaltung von durchdachten und gut passenden Architekturkonzepten, denn nur so kommen wir zu einem durchdachten, gut funktionierenden und gut zu wartenden System.