Software ArchitectureAtlas

Software Architecture Atlas

Überblick gewinnen. Zusammenhänge verstehen.

QualitätsmerkmalKapitel I · Anforderungen · Baustein 2 von 6

Qualitätsattribute

Eine Qualitätsanforderung legt fest, wie gut eine Funktion arbeiten muss, etwa wie schnell, wie zuverlässig oder wie änderbar. Oft heißen sie nicht-funktionale Anforderungen (NFR); ISO und arc42 sagen Qualitätsanforderungen, weil der Begriff benennt, was sie beschreiben, statt was sie nicht sind.

Von Michael Meierhoff · Meierhoff Systems

  1. QualitätsmodellEin Katalog von Kategorien als Checkliste.
  2. SzenarioEine konkrete Situation mit erwarteter Reaktion.
  3. MessgrößeWoran man das Erreichen prüft.

Einordnung

Warum das wichtig ist

Wer Qualität nur mit Wörtern wie „schnell“ oder „stabil“ beschreibt, kann sie nicht prüfen. Ein Qualitätsmodell hilft, nichts zu vergessen. Messbare Szenarien machen daraus abnehmbare Ziele, die du im Test oder Betrieb nachweisen kannst.

Dieser Baustein erklärt die Form messbarer Qualitätsszenarien. Für konkrete Zeit- und Lastmaße siehe Performance.

Auf einen Blick · Qualität als Szenario messbar machen

Ein Qualitätsmodell liefert Kategorien; ein Szenario beschreibt Reiz und Reaktion, eine Messgröße macht es prüfbar.
Shop-Beispiel · Qualitätsbaum

Ein Qualitätsbaum, fünf Szenarien des Shops

Für den Shop wird die Reaktion auf eine Zahlungsanfrage unter normaler Last konkret beschrieben. Die Zahlen sind ein illustratives Lernbeispiel.

So liest du das Bild

  1. Qualitätsmodell Der Modell-Schalter ordnet dieselben fünf Szenarien in andere Kategorien ein.
  2. Szenario Beim Anklicken zeigt ein Szenario Quelle, Auslöser, Umgebung, Betroffenen Teil, Reaktion und Messgröße.
  3. Messgröße Der Teil „Messgröße“ jedes Szenarios, z. B. 95 Prozent innerhalb illustrativer 800 ms.

Der Blickwinkel einer internationalen Norm: Qualität als Katalog von Produktmerkmalen, neun Merkmale, hier fünf genutzt.

Qualität des Shops

  • Performance Efficiency (Leistungseffizienz)
  • Reliability (Zuverlässigkeit)
  • Maintainability (Wartbarkeit)
  • Security (Sicherheit)
  • Flexibility (Flexibilität)

Qualitätsszenario

Zahlungsanfrage wird schnell beantwortet

Quelle
Kunde
Auslöser
bestätigt die Zahlung für Bestellung B-1042
Umgebung
Normalbetrieb mit illustrativ 20 Zahlungsanfragen pro Sekunde
Betroffener Teil
Zahlungsfunktion des Shops
Reaktion
liefert autorisiert, abgelehnt oder Klärung läuft
Messgröße
95 Prozent der Antworten innerhalb illustrativer 800 ms
Vertiefen: Performance
Wähle ein Qualitätsmodell und klicke ein Szenario an. Die Szenarien bleiben gleich, nur die Kategorien wechseln. Zahlenangaben sind illustrativ.

Das Szenario „Zahlungsanfrage wird schnell beantwortet“ lässt sich nachprüfen: Bei 20 Anfragen/s liegt das 95. Perzentil bei 780 ms, das Ziel von 800 ms ist erfüllt. Bei 30 Anfragen/s kippt es (alle Zahlen illustrativ).Ziel im Performance-Regler prüfen

Wo es weitergeht

Wo der Atlas jedes Merkmal vertieft

Die neun Merkmale der ISO/IEC 25010:2023 zeigen, welche Qualitäten der Atlas ausführlich behandelt und wo er bewusst Lücken lässt.

Nutzen & Grenzen

Hilft, wenn

  • Eine technische Wahl soll anhand geschäftlich relevanter Qualität verglichen werden.
  • Produktversprechen und Betriebsbeobachtung brauchen gemeinsame messbare Kriterien.

Grenzen

  • Ein allgemeiner Begriff wie „schnell“ hat keinen eindeutigen Messpunkt. Formuliere ein konkretes Szenario und verknüpfe es mit dem passenden Architekturtreiber.
  • Ein einheitlicher Zielwert für alle Funktionen kann Aufwand fehlleiten. Werte Eigenschaften pro Ablauf aus und ziehe bei Bedarf spezialisierte Ziele wie Performance hinzu.

In der Praxis

  1. Beteiligte mit einem Qualitätsmodell befragen. Nimm ein Modell wie ISO 25010 oder Q42 als Checkliste und frage Fachbereich, Betrieb und Entwicklung, welche Kategorien für sie zählen. So vergisst du keine Perspektive.
  2. Top 3–5 Qualitätsziele priorisieren. Wähle die wenigen Ziele, die den Entwurf prägen, und halte sie fest (arc42 Kapitel 1.2). Sie speisen die Architekturtreiber.
  3. Qualitätsbaum mit messbaren Szenarien aufbauen. Ordne jedem Ziel konkrete Szenarien mit Messgröße zu (arc42 Kapitel 10). iSAQB und ATAM nennen das Utility Tree. Typische Beispiele sind Performance und Verfügbarkeit.
  4. Szenarien in Reviews und Tests prüfen. Übernimm die Szenarien in Architektur-Reviews und automatisierte Tests, damit Abweichungen früh auffallen. Im Betrieb helfen SLIs, SLOs & Error Budgets.
Ausführliche Erklärung lesen

Bezeichnungen wie Verfügbarkeit, Performance und Änderbarkeit benennen Qualitätsbereiche, sind allein aber noch nicht prüfbar. Ein Szenario ergänzt Auslöser, Betriebszustand, betroffene Funktion und messbare Reaktion. Architekturtreiber priorisieren solche Ziele; spezialisierte Einträge wie Verfügbarkeit konkretisieren einzelne Eigenschaften.

Messpunkt, Zeitraum und Zielwert verbinden ein Qualitätsziel mit Test oder Betrieb. Qualitätsziele können miteinander konkurrieren: Eine sofortige gemeinsame Bestätigung kann Konsistenz fördern und Antwortzeit erhöhen. Eine klare Priorität zeigt, welche Eigenschaft in einem bestimmten Ablauf Vorrang erhält und welche Folge der Entwurf dafür akzeptiert.

Selbst prüfen

Teste dich in drei Stufen

  1. AblesenIm Bild nachsehen

    Welche Szenarien kann das SRE-Modell (Golden Signals) nicht einsortieren?

    Lösung mit Begründung ansehen

    Abholung einführen, Versandpartner ändert nur eigene Bestellungen und Zweiter Zahlungsanbieter. Sie stehen unter „ohne Entsprechung“, weil das Modell das laufende System misst.

  2. AnwendenAuf eine neue Lage übertragen

    Ein Fachbereich fordert, dass Kunden Bestellungen auch bei Anbieterausfall aufgeben können. Welche Kategorie und welches Szenario passen im ISO-Modell?

    Lösung mit Begründung ansehen

    Reliability (Zuverlässigkeit) mit dem Szenario „Bestellannahme trotz Anbieterausfall“. Auslöser, Umgebung, Reaktion und Messgröße schärfen die Forderung.

  3. BewertenEine Alternative abwägen

    Reicht ein einzelnes Modell als Checkliste, oder sollte das Team besser SRE-Signale statt ISO verwenden?

    Lösung mit Begründung ansehen

    Ein Modell reicht als Gedächtnisstütze, aber nicht als Ersatz für Szenarien. ISO deckt alle fünf ab, SRE nur Betriebssignale. Für Entwicklungsziele wie Änderbarkeit braucht es ein breiteres Modell oder zusätzliche Szenarien.

Vertiefen

Diese Bausteine führen die Gedanken dieser Seite weiter.

AnforderungenPerformancePerformance macht Antwortzeit, Durchsatz und Ressourcenverbrauch unter Last vergleichbar.Öffnen AnforderungenVerfügbarkeitDu bestimmst, wann eine Funktion für Nutzer erreichbar ist und wie zuverlässig sie bereitsteht.Öffnen AnforderungenFunktionale AnforderungenFunktionale Anforderungen beschreiben die fachlichen Leistungen, die ein System bereitstellt.Öffnen BetriebSLIs, SLOs & Error BudgetsSLIs, SLOs und Error Budgets verbinden messbare Betriebsqualität mit Zielen und vereinbarten Abweichungen.Öffnen

Quellen

Weiter im Lernpfad

Als Nächstes in Anforderungen & Qualität: Constraints.

6 Bausteine

Weiter mitConstraints