Was macht Software gut? Qualitätsanforderungen messbar machen

„Läuft doch." Zwei Wochen nach dem Go-live bricht die Nachtverarbeitung zusammen, weil zehntausend Geräte gleichzeitig ihre Daten abholen. Funktional war alles korrekt. Nur hatte niemand festgehalten, wie viel Last das System aushalten muss. Genau hier entscheidet sich, ob Software gut ist: nicht nur daran, was sie tut, sondern wie gut sie es tut, unter realen Bedingungen.

Über diese „wie gut"-Frage habe ich in mehreren Vorträgen gesprochen. Dieser Beitrag fasst die Kernideen zusammen: Was Qualitätsanforderungen sind, wie du sie mit Qualitätsszenarien messbar machst, wie du priorisierst, dokumentierst, und was generative KI daran ändert.

Was Qualitätsanforderungen wirklich sind

Funktionale Anforderungen beschreiben, was eine Software können soll: „Der Einkauf löst eine Nachbestellung aus." Qualitätsanforderungen beschreiben, wie gut sie das tut: schnell genug, sicher genug, wartbar genug. Sie definieren messbare Kriterien und sorgen dafür, dass ein System nicht nur die Nutzer, sondern auch Entwicklung und Stakeholder zufriedenstellt. Kurz gesagt: Sie sind eine Checkliste gegen teure Nacharbeit und vermeidbare Risiken.

Ein guter Rahmen dafür ist die ISO/IEC 25010. Sie ordnet Softwarequalität in acht übergeordnete Merkmale mit vielen Untermerkmalen. Du musst die Norm nicht auswendig kennen. Nutze sie als Landkarte, damit im Projekt keine ganze Qualitätsdimension vergessen wird:

Der wichtigste Satz dazu: Qualitätsanforderungen sind mehr als funktionale Anforderungen, und sie werden trotzdem am häufigsten vergessen. Denn niemand fordert im Refinement spontan „übrigens, das UI soll unter Last in unter 200 Millisekunden antworten". Genau das musst du aktiv einfordern.

Vom vagen Wunsch zum messbaren Kriterium: Qualitätsszenarien

„Das System soll schnell und sicher sein" ist keine Anforderung, sondern ein Wunsch. Er ist nicht prüfbar, und was nicht prüfbar ist, wird nicht gebaut. Das Werkzeug, um daraus etwas Messbares zu machen, ist das Qualitätsszenario (aus der ATAM-Methode). Es beschreibt eine konkrete, überprüfbare Situation entlang von sechs Bausteinen:

• Quelle (Source): Wer oder was löst etwas aus?
• Ursache (Stimulus): Was genau wird ausgelöst?
• Umgebung (Environment): Unter welchen Bedingungen?
• Beteiligte (Artifacts): Welche Systemteile sind betroffen?
• Antwort (Response): Was soll passieren?
• Bewertung (Measure): Woran misst du den Erfolg?

Ein Beispiel aus einem ERP-Kontext:

Eine Mitarbeiterin aus dem Einkauf (Quelle) löst über das UI eine Nachbestellung beim Lieferanten aus (Ursache). Es ist Montag, 11 Uhr, und alle Mitarbeitenden nutzen das System (Umgebung). Beteiligt sind UI, Datenbank, Bestell-Service und Lager-Service (Beteiligte). Das System löst die Bestellung aus und meldet Erfolg (Antwort).

Erst die Bewertung macht das Szenario prüfbar, und zwar für mehrere Qualitätsmerkmale gleichzeitig:

• Internationalisierung: Das UI ist auf Deutsch und Englisch verfügbar.
• Performance: Die UI-Rückmeldung erfolgt zeitnah (z. B. < 300 ms).
• Durchsatz: Die Verarbeitung der Bestellung erfolgt zeitnah, auch unter Montagslast.
• Sicherheit: Mitarbeitende ohne die Rolle „Einkauf" können keine Bestellung auslösen.

Aus jedem dieser messbaren Kriterien lässt sich direkt eine Testmethode ableiten: ein Integrationstest für den Bestellablauf, ein Lasttest für den Durchsatz, ein Autorisierungstest für die Rolle. So wird aus einem Wunsch eine Testkriterien-Kette.

Priorisieren mit dem Quality Tree

Du kannst nicht jede Anforderung mit gleicher Härte absichern, und du solltest es auch nicht. Ein Quality (Attribute Utility) Tree hilft beim Sortieren: Du bewertest jedes Szenario nach zwei Achsen, geschäftlicher Wichtigkeit und technischem Risiko bzw. Schwierigkeit. Was oben und schwierig ist, verdient Aufwand. Was unten und einfach ist, läuft nebenbei mit.

Diese Priorisierung ist keine Fleißaufgabe, sondern der eigentliche Hebel: Sie verhindert, dass du Testinfrastruktur für Randfälle baust, während der geschäftskritische Kernprozess ungetestet bleibt.

Ein Beispiel aus der Praxis

In einem Projekt aus der Konsumgüter-Industrie war die zentrale Qualitätsanforderung glasklar formulierbar, sobald man die richtige Frage stellte: Durchsatz von 10.000 Geräten in einer Stunde zum Schichtbeginn. Das ist kein vages „muss performant sein", sondern eine Zahl, gegen die man testen kann.

Die abgeleitete Aktion folgte unmittelbar: gezielt in Performance-Tests mit Optimierung auf Durchsatz investieren, statt breit und ungerichtet zu testen. Ein einziges gut formuliertes Qualitätsszenario hat hier die komplette Teststrategie fokussiert.

Qualitätsanforderungen dokumentieren

Ein Szenario, das nur im Kopf eines Entwicklers existiert, ist keine Anforderung. Es muss auffindbar und idealerweise maschinenlesbar abgelegt sein. Drei bewährte, leichtgewichtige Formate:

• arc42: freies, standardisiertes Architektur-Template. Qualitätsanforderungen haben dort ihren festen Platz in Kapitel 10.
• Architecture Communication Canvas (ACC): eine leichtgewichtige, visuelle Struktur als Baseline der Architekturdokumentation. Faustregel: Alles kann, ACC muss.
• Architecture Decision Records (ADRs): ein schlankes Textformat, das konkrete Entscheidungen und ihre Auswirkungen auf Qualitätsanforderungen festhält.

Wichtig ist nicht das Werkzeug, sondern die Gewohnheit. Ob mehr oder weniger formal, spielt eine untergeordnete Rolle. Entscheidend ist, dass die Anforderung dokumentiert, versioniert und im Team sichtbar ist.

Qualität in Zeiten von generativer KI

Generative KI verändert das Thema in zwei Richtungen, und du solltest beide getrennt betrachten.

KI als Werkzeug. Modelle unterstützen bei der Ermittlung und Dokumentation von Anforderungen, generieren maschinenlesbare Artefakte, erzeugen Diagramme und Modelle und beschleunigen Iterationen. Der eigentliche Gewinn ist eine Verschiebung des Fokus: weg von der Schreibarbeit, hin zur Bewertung. Ein Prompt wie „Erstelle mir aus dieser Codebasis einen arc42 Architecture Communication Canvas mit Mermaid-Diagramm und halte zentrale Entscheidungen und Risiken fest" liefert in Minuten einen Entwurf, den du dann fachlich prüfst und schärfst.

KI als Systemkomponente. Sobald ein KI-Modell Teil deiner Software ist, entstehen neue Qualitätsanforderungen: Bias, Transparenz, Erklärbarkeit und Robustheit. Gleichzeitig bekommen bestehende Merkmale wie Sicherheit und Performance eine neue Dimension. Deine Qualitätsszenarien müssen KI-spezifische Risiken deshalb explizit abdecken, sonst prüfst du ein System, das sich anders verhält als klassische Software.

Do's and Don'ts

Hier einige Empfehlungen aus knapp 20 Jahren Projektalltag:

Do

• Fordere Qualität aktiv ein. Stelle bei jeder fachlichen Anforderung im Refinement die Zusatzfrage: „Wie schnell, welche Datenmengen, wie sicher, etc.?"
• Mach es messbar. Nutze Qualitätsszenarien oder einen Quality Tree. Eine Zahl schlägt ein Adjektiv.
• Hinterfrage die Fachlichkeit kritisch. „Wie oft kommt dieser Prozess vor?", „Wer nutzt diese Funktion?", „Sind wirklich alle diese Daten nötig?" Antworten darauf priorisieren von selbst.
• Fokussiere auf Kernprozesse und Schnittstellen. Gerade an Schnittstellen entscheiden sich Performance und Sicherheit.
• Setze Unit- und Integrationstests als Standard. Sie sind fast immer eine gute Idee und billiger als jeder Produktionsvorfall.
• Wähle gezielte Qualitätsanforderungen je Szenario aus Nicht alle sind für jedes Szenario relevant oder bringen einen Mehrwert. Nutze die Liste als Leitfaden, nicht als must-have Liste.

Don't

• Verlasse dich nicht auf Code-Coverage-Gates als Qualitätsmaß. Sobald eine Kennzahl zum Ziel wird, hört sie auf, ein gutes Maß zu sein (siehe Goodhart's Law). Hohe Coverage kann trotzdem schlechte Tests bedeuten.
• Baue nicht zu früh schwere, systemübergreifende Tests. Sie sind teuer und träge. Setze sie sparsam und gezielt ein, nicht auf Vorrat.
• Kopiere keine fremde Teststrategie 1:1. Die richtige Strategie ist projektabhängig und ergibt sich aus deinen priorisierten Qualitätsszenarien.
• Lass Tests nicht im Weg stehen. Wenn die Testsuite jede Änderung blockiert oder ausbremst, wird sie umgangen. Dann hast du das Ziel verfehlt.
• Vergiss KI-spezifische Risiken nicht, sobald ein Modell Teil des Systems ist.

Qualität ist eine gemeinsame Verantwortung

Gute Softwarequalität entsteht nicht durch ein Dokument oder ein Tool, sondern durch eine geteilte Haltung, die von zwei Seiten getragen wird:

• Bottom-up, aus der Entwicklung: Qualitätsanforderungen aktiv einfordern, konkretisieren und maschinenlesbar dokumentieren.
• Top-down, aus Architektur und Management: den Rahmen, die Tools und den Rückhalt bereitstellen, damit Qualität sichtbar, prüfbar und priorisiert wird.

Fang klein an. Nimm deinen wichtigsten Prozess, schreib ein einziges Qualitätsszenario mit einer messbaren Zahl auf und leite daraus einen Test ab. Das ist mehr wert als jede Norm im Regal. Denn am Ende gilt: Was du nicht misst, kannst du auch nicht versprechen.