Qualität aus Architektursicht

Qualitätsanforderungen in der Softwarearchitektur sind keine eigenständige Kategorie neben funktionalen Anforderungen, sondern Teil desselben Anforderungsraums. Die ISO 25010 trennt beides, doch diese Grenze ist unscharf: Viele Qualitätseigenschaften wie Usability oder Security werden am Ende durch Funktionalität umgesetzt. Architekturen sollten so gebaut sein, dass beide Arten von Änderungen möglich bleiben.

Das Wichtigste in Kürze

• Die Unterscheidung zwischen funktionalen und Qualitätsanforderungen führt in der Praxis zu einer falschen Hierarchie: Funktionale Anforderungen treiben Architekturen genauso stark wie alle anderen Eigenschaften.
• Qualitätsanforderungen wie Usability oder Security werden letztlich durch Funktionalität umgesetzt, etwa durch einen Passwortdialog oder einen Screenreader, was die Trennlinie zwischen beiden Kategorien auflöst.
• Quantitative Anforderungen wie Antwortzeiten werden häufig ohne Business-Case-Grundlage festgelegt, was später zu unlösbaren Konflikten mit anderen Randbedingungen führt.
• Eine Architektur, die früh auf Änderbarkeit ausgelegt ist, ermöglicht es, Qualitätseigenschaften dann zu adressieren, wenn sie tatsächlich in den Fokus rücken, statt alle Entscheidungen vorab richtig treffen zu müssen.
• Der ISAQB-Grundlagenlehrplan behandelt Qualität gemeinsam mit Architekturbewertung in einem einzigen Kapitel am Ende, obwohl das Thema als Anforderungsgrundlage an den Anfang gehört.

Funktionale Anforderungen und Qualitätsanforderungen lassen sich architektonisch schwer trennen

Aus Architektursicht gibt es keinen fundamentalen Unterschied in der Behandlung von funktionalen Anforderungen und anderen Anforderungen. Beide treiben den Entwurf, beide werden geschlampt, beide ziehen in schlechten Architekturen große Folgeänderungen nach sich.

Michael Sperber, ISAQB-Trainer für die Softwarearchitektur-Grundausbildung, sieht diese pauschale Trennung kritisch. In manchen Teilen der Community gelten funktionale Anforderungen als kaum architekturrelevant, etwa in einem viel zitierten Architekturbuch. Diese Sicht passt für ihn weder dazu, wie die meisten Leute Architektur machen, noch zu seiner eigenen Erfahrung.

Die Abgrenzung selbst ist unscharf. Ein Server soll Dollar in Euro umrechnen: das ist eine Funktion. Er soll das in zehn Millisekunden tun: das ist eine Qualitätseigenschaft. Was aber, wenn das System nach Ablauf der zehn Millisekunden etwas Bestimmtes tut? Dahinter steht wieder eine Funktion. Ob das jetzt funktional oder qualitativ heißt, lässt sich oft nicht sauber sagen.

Dass solche Zuordnungsfragen immer wieder auftauchen, ist selbst ein Hinweis: die Taxonomie hat ein Problem.

Was die Functional Suitability in der ISO 25010 wirklich meint

Die ISO 25010 ist ein Qualitätsmodell, das den Qualitätsbegriff in Kategorien aufteilt, in die sich Eigenschaften einsortieren lassen. Genau über die Kategorie Functional Suitability gehen die Meinungen auseinander.

Alexander Lorz liest die Spalte so: dort steht, wie gut die funktionalen Anforderungen zu dem passen, was Stakeholder brauchen. Die funktionalen Anforderungen selbst stehen für ihn nicht darunter. Sonst würde dieser Kasten zu einem Riesenfach, in dem gefühlt die Hälfte aller Anforderungen landet, und das Modell geriete in Schieflage.

Michael sieht das anders. Funktionalität gehört für ihn selbstverständlich zu den Eigenschaften eines Systems. Wer Qualität als Synonym für Eigenschaft versteht, nimmt die Funktionalität nicht aus. Der Vorgängerstandard nannte die Spalte schlicht Functionality. Ein Mitglied des Normungsgremiums, mit dem er sprach, bestätigte: die funktionalen Anforderungen seien darunter angesiedelt, das Wording sei nur so verquast, dass jeder etwas anderes hineininterpretiere.

Beide einigten sich an dieser Stelle auf “we agree to disagree”. Praktisch wichtiger ist die Erkenntnis dahinter: über eine kleine Frage lässt sich endlos streiten, ohne dass die Antwort die Umsetzung verändert.

Qualitätsanforderungen fliegen bei vielen Stakeholdern unter dem Radar

Wer Informationssysteme baut, redet mit Kunden über Funktionen: über Prozesse, die das System unterstützen soll. Zu selten geht es darum, wie gut das System diese Dinge tun soll, wie gut Entwicklungs- oder Deployment-Prozesse sein sollen oder wie es um Recoverability steht.

Genau hier liegt der praktische Wert der Unterscheidung. Sie hilft, Anforderungen zu sortieren in solche, die ein Team ohnehin gut auf dem Schirm hat, und solche, die unter dem Radar fliegen, aber später Risiken und Schmerzen verursachen. Änderungen an Qualitätsanforderungen haben oft einen großen Impact und betreffen viele Komponenten.

Die Industrie prägt dabei den Blick. Teams aus Automotive und Automatisierungstechnik sind mit ihren funktionalen Anforderungen meist zufrieden und haben oft auch gute Qualitätsanforderungen, weil sie safetyrelevante Systeme bauen und der Kunde hart vorgibt. Bei Informationssystemen ist diese Balance seltener gegeben.

In der späteren Umsetzung verliert das Etikett seine Bedeutung. Ob “funktional” oder “Qualität” draufsteht, ist dann egal: es sind Anforderungen wie jede andere auch.

Eine Zahl an eine Anforderung zu kleben hilft nur, wenn ein Business Case dahintersteht

Quantifizierte Qualitätsanforderungen sind nur dann nützlich, wenn die Zahl begründet ist. Eine willkürliche Zahl schadet mehr, als sie nützt.

Ein verbreiteter Fehler: Teams gehen die gesamte Taxonomie durch und kleben an jede Eigenschaft irgendeine Zahl. Mal ist sie aus dem Hut gezogen, mal lässt sich nicht vorhersagen, wie sie sich einpendelt, weil noch unklar ist, wie viele Benutzer das System gleichzeitig haben wird. Solche Zahlen geraten später in Konflikt mit anderen Anforderungen oder Randbedingungen. Es gab Projekte, in denen mehrere quantitative Anforderungen gleichzeitig schlicht nicht erfüllbar waren.

Auch die Richtung des Fehlers variiert. Ein Kunde hat keine Vorstellung und klebt eine Zahl dran. Oder ein Ingenieur will sportlich sein und nennt eine Zahl, die im vorhandenen Budget nicht erreichbar ist, nur damit überhaupt etwas dasteht. Warum reichen nicht 200 Millisekunden, warum müssen es 20 sein? Ohne Business Case ist die Frage nicht zu beantworten.

Für viele Eigenschaften ist die Richtung wichtiger als der Zielwert. Schneller ist besser, manchmal ist auch langsamer besser. In der Praxis wendet man Maßnahmen so lange an, bis das Ziel erreicht ist oder man zufrieden ist. Für diesen Prozess muss am Anfang gar nicht feststehen, bei welcher Zahl man hinten herauskommt.

Manche Qualitäten lassen sich kaum messen, und das ist trotzdem eine wichtige Information

Nicht jede Qualität lässt sich mit einer Zahl belegen. Response-Zeit oder Requests pro Sekunde sind einfach zu messen. Bei Security oder Usability wird es hart. Was bedeutet schon “Usability 5”?

Die ISO mauschelt sich an dieser Stelle mit der Formulierung “degree of which” durch, also wie weit eine Qualität messbar ist oder sein soll. Doch auch eine nicht quantifizierte Anforderung trägt Information. Wenn klar ist, dass einem Stakeholder Usability sehr wichtig ist, ist das für den Architekturentwurf wertvoll.

Fehlt die Definition of Done, entsteht ein Risiko. Es gibt keinen klaren Punkt, an dem man fertig ist. Stattdessen muss man immer wieder beim Kunden nachfragen, ob es gut genug ist. Das kostet Geld, und das muss dem Kunden wie dem Management klar sein. Genau das macht die fehlende Quantifizierung zu einem Indikator, nicht zu einem Mangel an Steuerung.

In der Praxis scheuen Kunden oft den Aufwand. Eine Usability-Studie wird nicht bezahlt, obwohl Usability einer der wichtigsten Treiber des Business Case ist.

Trends ersetzen Zielwerte: besser werden statt eine Zahl treffen

Zunehmend reicht es zu sehen, dass sich Dinge in die richtige Richtung bewegen. Das Quantifizieren ist oft schlicht zu teuer.

In der evolutionären Softwarearchitektur testet man auf Eigenschaften der Architektur, ohne einen festen Zielwert wie “5” vorzugeben. Das Ziel lautet stattdessen: nicht schlechter werden, idealerweise besser. Dieser Trend nimmt zu. Vieles, was früher zwingend eine Zahl gewesen wäre, lässt sich heute als überwachter Verlauf abbilden.

Ein wiederkehrendes Modell-Problem verschärft die Lage zusätzlich. Bei manchen Qualitätsattributen entstehen endlose Diskussionen darüber, in welches Kapitel sie gehören. Antwortzeiten etwa lassen sich als Usability- oder als Performance-Thema lesen. Eine halbe Stunde Debatte über die Einsortierung bringt nichts, wenn die Einordnung für die Entscheidung keine Rolle spielt.

Gute Architektur versteckt Entscheidungen, statt sie für immer richtig zu treffen

Es gibt zwei Lager unter Softwarearchitekten. Das eine sagt, Architektur bedeute, die wichtigen Entscheidungen richtig zu treffen. Dahinter steckt die Annahme, dass man sie später nicht mehr ändern kann.

Das andere Lager geht auf David Parnas zurück. Seine Idee: Jedes Modul versteckt eine Entscheidung und versetzt dich so in die Lage, diese Entscheidung später zu ändern. Die Position “wir müssen die wichtigen Entscheidungen richtig treffen” ist aus dieser Sicht eine kollektive Kapitulation vor dem Problem.

Du solltest wenn möglich überhaupt keine wichtige Entscheidung unverrückbar treffen, sondern deine Software so machen, dass du sie später ändern kannst. Michael Sperber

Dieses Prinzip sollte für alle Qualitäten gelten, nicht nur für funktionale. Auch bei nicht-funktionalen Eigenschaften gilt es, architektonische Konzepte zu finden, die es erlauben, auf geänderte Anforderungen mit möglichst kleinen, schnellen und billigen Änderungen zu reagieren.

Ein Risiko der pauschalen Trennung liegt genau hier. Wer glaubt, Funktionalität sei einfach und alles andere zu schwierig, baut Architekturen, die auf Änderungen im nicht-funktionalen Bereich gar nicht mehr reagieren können.

Funktionalität zuerst, aber flexibel genug für später

Im Isaqb-Modell gilt es als unsauber, mit der Funktionalität zu beginnen. In der Praxis ist sie aber fast immer zuerst im Fokus, und fast jede Architektur entsteht im ersten Wurf von der Funktionalität her.

Der Trick liegt darin, die Software danach flexibel zu halten. Viele Taktiken, gerade für quantitative Eigenschaften, haben die Form: nimm ein bestehendes System und ändere es, um die gewünschte Eigenschaft zu verbessern. Wer früh entkoppelt, kann solche Anforderungen später noch erfüllen, wenn sie in den Fokus rücken.

Der unterschiedliche Hintergrund prägt diese Sicht. Michael kommt aus der funktionalen Architektur, Alexander aus der hardwarenahen und objektorientierten Welt. Funktionale Architektur sorgt im Standardmodus für deutlich weniger Kopplung, nach Michaels Erfahrung ungefähr eine Größenordnung weniger als typische objektorientierte Architektur. Das macht die Architekturen tendenziell flexibler gegenüber Änderungen.

Die offene Frage bleibt, wie man diese Flexibilität ohne Overengineering am Anfang erreicht. Zu Beginn weiß niemand, welche die wichtigen Entscheidungen sein werden.

Performance und Wartbarkeit sind nicht zwangsläufig ein Trade-off

Höhere Performance bedeutet oft engere Kopplung an bestimmte Hardware. Für manche Teams spielt Wartbarkeit deshalb kaum eine Rolle: Im Safety-Umfeld will man ein System einmal deployen und dann zehn Jahre laufen lassen, ohne es je wieder zu ändern.

Doch dieser Befund ist teilweise ein Henne-Ei-Problem. Viele Systeme werden nicht geändert, weil sie schwer zu ändern sind, nicht weil keine Änderung nötig wäre. Und die Treiber für Änderungen verschieben sich. Geräte im Embedded- und Safety-Umfeld bekommen zunehmend Internetverbindungen und sind neuen Angriffsvektoren ausgesetzt. Das verschiebt die Prioritäten, ohne sie umzukehren.

Der angenommene Zielkonflikt zwischen Performance und Wartbarkeit kehrt sich in vielen Fällen sogar um. Klassische Enterprise-Software ist oft eng an die Datenbank gekoppelt, das Schema ist für die Anfragen von heute entworfen. Ändern sich die funktionalen Anforderungen, kann das Schema die neuen Anfragen nicht mehr befriedigend erfüllen.

Theoretisch ließe sich ein eng gekoppeltes System bauen, das die neuen Anfragen effizient beantwortet. Das Problem ist das bestehende System, das es nicht kann und das sich nicht mehr ändern lässt. Da Software in der Regel länger lebt als gewünscht, lohnt die Wette auf Änderbarkeit, auch gegen den Ruf nach einer “good enough architecture”.