Qualitätsziele: Szenarien statt Adjektive

Veröffentlicht am 5. Juli 2026 · Aktualisiert am 15. Juli 2026

Eine Person zieht an einer Wandtafel einen breiten amberfarbenen Strich durch eine lange Liste abgehakter Einträge; rechts bleiben drei Einträge mit Messskalen und Zielmarken übrig

Abbildung 1. Die eigentliche Arbeit: die lange Liste streichen, drei messbare Ziele behalten

Fast jedes Projekt hat irgendwo eine Liste nichtfunktionaler Anforderungen, und fast immer steht dasselbe darin: performant, sicher, wartbar, skalierbar, benutzerfreundlich. Diese Liste hat eine auffällige Eigenschaft: Niemand widerspricht ihr. Kein Auftraggeber sagt „nein, langsam und unsicher bitte".

Genau daran erkennt man, dass sie leer ist. Ein Ziel, dessen Gegenteil niemand ernsthaft vertreten würde, trifft keine Entscheidung. Es tut nur so. Und Aussagen ohne Entscheidungsgehalt kann man aus jedem Dokument streichen, ohne dass etwas fehlt.

Wozu die ISO 25010 gut ist, und wozu nicht

Die ISO 25010 ordnet Softwarequalität in Merkmale wie Performance-Effizienz, Zuverlässigkeit, Sicherheit, Benutzbarkeit und Wartbarkeit, jeweils mit Untermerkmalen. Als Landkarte ist das wertvoll: Sie gibt allen Beteiligten dasselbe Vokabular und verhindert, dass ein ganzes Qualitätsfeld schlicht vergessen wird. Bei mir hängt sie in jedem Qualitätsworkshop an der Wand.

Eine Priorisierung musst du trotzdem selbst treffen, der Standard liefert sie nicht mit. Wer alle Merkmale ankreuzt, hat keine Ziele, sondern einen Katalog. Qualitätsmerkmale stehen in Konflikt: Das letzte Quäntchen Performanz kostet Lesbarkeit, maximale Flexibilität kostet Einfachheit, strenge Sicherheit kostet Komfort. Die eigentliche Architekturarbeit beginnt bei der Frage, welche drei bis fünf Merkmale für dieses System wichtiger sind als alle anderen. Wer mehr als fünf nennt, hat sich nicht entschieden. Diese Rangfolge beantwortet hunderte kleiner Alltagsfragen im Code, bevor sie gestellt werden.

Von der Eigenschaft zum Szenario

Ein priorisiertes Merkmal ist immer noch ein Adjektiv. Tragfähig wird es erst als Qualitätsszenario: Ein Auslöser trifft das System unter benannten Bedingungen, und die erwartete Reaktion steht daneben, mit einer Maßzahl.

Drei Beispiele aus realen Projekten:

Besucher rufen eine inhaltsgetriebene Seite zur Hauptlastzeit auf. Die Antwortzeiten liegen im 95. Perzentil unter 200 Millisekunden, gemessen mit dem Lastprofil, das im nächtlichen Lasttest hinterlegt ist.
Eine Anfrage kommt mit einem abgelaufenen oder manipulierten Token. Sie wird am Gateway abgewiesen, bevor Fachlogik läuft, in unter 50 Millisekunden, mit Testfällen für Ablauf, falsche Signatur und veränderte Claims.
Ein Release verschlechtert die Barrierefreiheit. Fällt der Lighthouse-Accessibility-Wert im automatisierten Audit unter 95, bricht die Pipeline ab, bevor etwas live geht.

Der Unterschied zur Adjektivliste: Über jedes dieser Szenarien kann man streiten. Warum 200 Millisekunden und nicht 500? Wieso ausgerechnet das 95. Perzentil? Und warum am Gateway abweisen statt erst im Service? Gut so. Dieser Streit ist der Zweck der Übung: Er zwingt Auftraggeber und Team, sich festzulegen, was das System wirklich können muss und was es kosten darf.

Für die Formulierung braucht es keinen schweren Prozess. Drei Fragen an die richtigen Leute liefern das Rohmaterial: Was wäre für dieses Produkt geschäftlich eine Katastrophe? Was muss das System in zwei Jahren können, was es heute nicht kann? Und worüber beschweren sich Nutzer oder Entwickler heute schon? Aus den Antworten kommen die Kandidaten. Die Rangfolge ist dann die eigentliche Arbeit.

Eine Metrik ohne Prüfstelle ist ein Wunsch

Der zweite Schritt, an dem Qualitätsziele sterben: Sie werden beschlossen, dokumentiert und nie wieder angesehen. Deshalb gehört zu jedem Szenario die Angabe, wo es geprüft wird, namentlich: der Lasttest, der nachts gegen die Staging-Umgebung läuft; die Audit-Stufe in der Pipeline; der Architekturtest, der bei jedem Build die Modulgrenzen prüft. In meiner arc42-Vorlage hat die Tabelle in Kapitel 10 dafür eine eigene Spalte, und sie darf nicht leer sein.

Flussdiagramm in vier Stufen: Adjektive wie performant und wartbar werden zu einer Rangfolge von drei bis fünf ISO-25010-Merkmalen, daraus entstehen Qualitätsszenarien mit Auslöser, Bedingung und Maßzahl, die an einer Prüfstelle wie Lasttest oder Pipeline-Audit geprüft werden; reißt ein Szenario dauerhaft, führt ein Rückpfeil zur Neuverhandlung des Grenzwerts

Abbildung 2. Vom Adjektiv zum geprüften Ziel — und zurück, wenn ein Grenzwert dauerhaft reißt

Zwei Warnungen aus Erfahrung. Erstens: Maße so wählen, dass sie das Ziel messen, nicht das Ausweichverhalten. Eine globale Testabdeckung von 80 Prozent lässt sich mit wertlosen Tests auf trivialen Code erfüllen; die Abdeckung der jeweils geänderten Zeilen ist schwerer zu umgehen und sagt mehr. Jede Kennzahl, die zum Selbstzweck wird, wird gespielt. Zweitens: Grenzwerte sind Verhandlungsergebnisse, keine Naturkonstanten. Wenn ein Szenario dauerhaft reißt, ist auch das ein Befund. Manchmal ist der Code zu langsam, manchmal war die Zahl zu ehrgeizig, und beides darf man nur entscheiden, wenn man es sieht.

Was das mit Architektur zu tun hat

Alles. Qualitätsziele sind der Maßstab, an dem sich jede Architekturentscheidung messen lassen muss, und ohne sie ist auch das beste Architektur-Review nur eine Bauchentscheidung. Ob ein Modulschnitt gut ist, ob ein Framework passt, ob ein Umbau lohnt: Die Antwort lautet immer „kommt darauf an", und die Qualitätsziele sind das, worauf es ankommt.

Mein Lieblingsmoment dazu ist ein Code-Review, in dem jemand schreibt „das verletzt unser Latenz-Szenario", und die Diskussion damit beendet ist. Die Entscheidung fällt im Team, ohne dass ein Architekt vermitteln muss. Nur ein Team, das seinen Maßstab kennt.

Klingt nach deinem Thema? Schreib mir. Im Erstgespräch klären wir unverbindlich, ob und wie ich helfen kann.