ADR vs. NFR: Architekturentscheidungen und Systemqualität sind nicht dasselbe

ADR vs. NFR erklärt: Erfahren Sie, wie Systemqualitätsanforderungen Architekturentscheidungen beeinflussen, wie ADRs Abwägungen dokumentieren und warum die Validierung getrennt bleibt.

Veröffentlicht:8. Oktober 2026 um 14:11

Aleksandar Stajić

Aktualisiert: 8. Oktober 2026 um 19:31

ADR vs. NFR: Architekturentscheidungen und Systemqualität sind nicht dasselbe

Eine nicht-funktionale Anforderung (NFR) beschreibt eine Qualität, eine Einschränkung oder eine Betriebsbedingung, die das System erfüllen soll. Ein Architecture Decision Record (ADR) dokumentiert eine architektonisch bedeutsame Entscheidung, die als Reaktion auf Anforderungen, Einschränkungen, Risiken und Abwägungen getroffen wurde. Sie sind miteinander verbunden, aber nicht austauschbar: Eine NFR gibt an, was gelten muss; ein ADR erklärt, was entschieden wurde, warum und mit welchen Konsequenzen.

Was ist der Unterschied zwischen einer NFR und einem ADR?

Die einfachste Unterscheidung ist grammatikalischer Natur. Eine Anforderung beschreibt eine Bedingung, die das System erfüllen muss. Ein Entscheidungsprotokoll beschreibt eine Wahl, die das Team getroffen hat.

Zum Beispiel ist „Die API muss 95 % der Leseanfragen innerhalb von 300 ms unter der vereinbarten Referenzlast zurückgeben“ eine Qualitätsanforderung. „Verwenden Sie einen Read-Through-Cache für diese Arbeitslast, weil der gemessene reine Datenbankpfad das Latenzziel nicht ohne unakzeptable Kosten erreichen kann“ ist eine Architekturentscheidung.

Die erste Aussage bleibt gültig, auch wenn sich die Implementierung ändert. Die zweite Aussage kann später durch eine andere Entscheidung ersetzt werden, wenn sich Arbeitslast, Technologie, Kostenmodell oder Evidenz ändern.

NFR und ADR beantworten unterschiedliche Fragen

	NFR / Qualitätsanforderung	ADR / Architekturentscheidung
Primäre Frage	What quality, constraint, or operating condition must the system satisfy?	What architecturally significant choice did we make, and why?
Typischer Inhalt	Measurable target, scope, condition, constraint, acceptance or validation rule	Context, decision, rationale, alternatives, trade-offs, status and consequences
Rolle im Lebenszyklus	A requirement to design for and validate	A historical record of a significant decision
Was beweist sie?	Measurement, test, analysis, inspection, audit or other validation evidence	The record proves what was decided, not that the resulting system meets the requirement
Wann ändert sie sich	When stakeholder need, operating conditions, policy or quality target changes	When the decision is replaced, rejected, deprecated, or superseded

Was ist eine NFR in präzisen architektonischen Begriffen?

„Nicht-funktionale Anforderung“ ist eine praktische Branchenbezeichnung, kann aber mehrere verschiedene Arten von Aussagen verbergen. In der Architekturarbeit ist die nützliche Unterscheidung die zwischen funktionalem Verhalten, Qualitätsanforderungen und Einschränkungen.

ISO/IEC 25010:2023 bietet ein Produktqualitätsmodell mit neun Merkmalen und Untermerkmalen, das bei der Spezifikation und Bewertung der Qualität von IKT- und Softwareprodukten verwendet werden kann. Die Architekturarbeit des SEI behandelt Qualitätsattributanforderungen in ähnlicher Weise als wesentliche Treiber der Softwarearchitektur.

Eine nützliche NFR ist daher nicht „das System sollte schnell sein“ oder „die Plattform muss sicher sein“. Diese Aussagen benennen Ziele. Eine architekturtreibende Anforderung sollte die erwartete Eigenschaft ausreichend testbar machen, damit Designalternativen und spätere Evidenz dagegen bewertet werden können.

Schwache Aussage	Nützlichere Anforderungsform	Warum der Unterschied wichtig ist
Die API muss schnell sein	Für Arbeitslast W schließt 95 % von Operation X innerhalb von T Millisekunden ab	Definiert Arbeitslast, Operation, Metrik und Schwellenwert
Der Dienst muss verfügbar sein	Dienst S erfüllt ein vereinbartes Verfügbarkeitsziel über das Messfenster M, unter Ausschluss explizit definierter Wartungsbedingungen	Macht Verfügbarkeit messbar und definiert den Umfang
Mandantendaten müssen sicher sein	Eine für Mandant A authentifizierte Anfrage darf niemals Daten von Mandant B über unterstützte Anwendungspfade abrufen oder verändern	Verwandelt ein vages Sicherheitsziel in eine Isolationsanforderung
Das System sollte skalieren	Das System unterstützt Arbeitslast W bei Nebenläufigkeit C und erfüllt dabei Latenz- und Fehlerratenschwellenwerte	Verbindet Skalierung mit messbarem Dienstverhalten
Wir brauchen PostgreSQL	Keine NFR an sich; geben Sie zuerst die erforderlichen Persistenzqualitäten oder externen Einschränkungen an	Eine Technologieentscheidung ist normalerweise eine Lösung, nicht die Anforderung, die sie erfüllen soll

Was ist ein Architecture Decision Record?

Ein Architecture Decision Record ist eine kompakte Aufzeichnung einer wichtigen Architekturentscheidung. Michael Nygards ursprüngliche ADR-Formulierung betont den Kontext, die Entscheidung, ihren Status und die daraus resultierenden Konsequenzen.

Das wichtige Objekt ist die Entscheidung, nicht die Vorlage. Verschiedene Teams verwenden unterschiedliche ADR-Formate. Ein umfangreicheres Protokoll kann auch Alternativen, Entscheidungskriterien, Abwägungen, Evidenz, Links zu Anforderungen und das Datum oder die Version, ab der die Entscheidung gilt, bewahren.

ISO/IEC/IEEE 42010:2022 ist umfassender als die ADR-Praxis: Es spezifiziert Anforderungen an Architekturbeschreibungen und deren Konzepte, ohne dabei ausdrücklich einen Prozess, eine Notation, ein Werkzeug, ein Format oder ein Medium für die Aufzeichnung einer Architekturbeschreibung vorzuschreiben. Ein ADR ist daher eine praktische Technik zur Entscheidungsdokumentation, kein von ISO 42010 vorgeschriebenes Format.

ADR-Feld	Was es bewahrt	Warum es wichtig ist
Kontext	Das Problem, die Kräfte, Anforderungen, Annahmen und das Umfeld der Entscheidung	Zukünftige Leser können rekonstruieren, warum eine Entscheidung notwendig war
Entscheidung	Die Entscheidung, die verbindlich wurde	Trennt die gewählte Option von der Diskussion
Status	Vorgeschlagen, akzeptiert, abgelehnt, veraltet, ersetzt oder ein anderer kontrollierter Zustand	Verhindert, dass alte Entscheidungen stillschweigend aktiv bleiben
Alternativen	Andere in Betracht gezogene gangbare Optionen	Zeigt, dass die gewählte Lösung nicht die einzig denkbare war
Begründung / Abwägungen	Warum die Option gewählt wurde und was sie aufgibt	Macht die Architekturbegründung nachprüfbar
Konsequenzen	Erwartete positive und negative Auswirkungen, Folgearbeiten, Risiken	Verbindet eine lokale Entscheidung mit der Systemwirkung
Datum / Version	Wann die Entscheidung gültig wurde	Unterstützt die historische Nachverfolgbarkeit und spätere Ersetzung

Das einfachste Beispiel: Latenzanforderung → Architekturentscheidung

Angenommen, ein Product Owner und ein Engineering-Team vereinbaren, dass ein Such-Endpunkt die erste Ergebnisseite innerhalb von 400 ms beim 95. Perzentil unter einer definierten Referenzlast zurückgeben muss.

Dieses Ziel ist kein ADR. Es ist eine Qualitätsanforderung. Architekturarbeit beginnt mit der Frage, welches Design es unter den anderen Randbedingungen des Systems erfüllen kann.

Von der Anforderung zum Nachweis

1

1. Anforderung formulieren

Definieren Sie das Qualitätsziel, die Last, den Geltungsbereich, den Schwellenwert und die Validierungsmethode.

2

2. Architektonische Bedeutung erkennen

Stellen Sie fest, ob die Anforderung Struktur, Technologie, Bereitstellung, Datenfluss oder Betriebsmodell wesentlich beeinflusst.

3

3. Optionen bewerten

Vergleichen Sie Alternativen wie Indexierung, Caching, Denormalisierung, asynchrone Verarbeitung, Partitionierung oder eine andere Abfragearchitektur.

4

4. Entscheidung dokumentieren

Erfassen Sie die gewählte Architekturentscheidung, Begründung, Alternativen, Abwägungen, den Status und die Konsequenzen in einem ADR.

5

5. Umsetzen

Überführen Sie die Entscheidung in Code, Infrastruktur, Konfiguration und Betriebsverhalten.

6

6. Validieren

Messen Sie das reale System an der ursprünglichen Anforderung. Das Testergebnis validiert die NFR; das ADR allein tut dies nicht.

NFRs und ADRs haben üblicherweise eine Viele-zu-viele-Beziehung

Eine Qualitätsanforderung kann mehrere Architekturentscheidungen vorantreiben. Eine Anforderung zur Mandantentrennung kann beispielsweise Identitätsweitergabe, Datenbankabgrenzung, Design von Hintergrundjobs, Cache-Schlüssel, Audit-Protokollierung und administrative Werkzeuge beeinflussen.

Eine Architekturentscheidung kann auch gleichzeitig auf mehrere Anforderungen reagieren. Die Wahl einer asynchronen Verarbeitungsgrenze kann die Reaktionsfähigkeit und Fehlerisolierung verbessern, während sie Konsistenz-, Komplexitäts-, Beobachtbarkeits- und betriebliche Abwägungen mit sich bringt.

Warum die Beziehung nicht eins zu eins ist

	Anforderungsseite	Entscheidungsseite	Validierungsseite
Eine NFR → viele ADRs	A broad quality target can constrain several architectural boundaries	Several coordinated decisions may be required	Evidence may need multiple tests or measurements
Viele NFRs → ein ADR	Several quality and constraint drivers can point at the same design problem	One decision may balance several drivers	Each requirement still needs its own acceptance evidence
ADR ohne klassische NFR	The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition	The choice can still be architecturally significant	Validate against the actual driver, not an invented NFR
Anforderung stabil, ADR ändert sich	The target can remain unchanged	A better or necessary implementation choice can supersede the old decision	The new architecture must still be checked against the same target

Eine Technologieentscheidung ist nicht automatisch eine Anforderung

Ein wiederkehrender Architekturfehler besteht darin, eine bevorzugte Technologie in die Anforderungsebene zu schreiben und das daraus resultierende Design dann als unvermeidlich zu behandeln.

„Das System muss PostgreSQL verwenden“ kann eine legitime Randbedingung sein, wenn ein Vertrag, eine Plattformrichtlinie, eine Kompatibilitätsanforderung, eine Lizenzregel, ein Organisationsstandard oder eine bestehende Betriebsgrenze PostgreSQL tatsächlich vorschreibt. Wenn der tatsächliche Bedarf jedoch transaktionale Konsistenz, strukturierte Abfragen, betriebliche Vertrautheit oder ein bestimmtes Wiederherstellungsziel ist, sollte die Anforderung diesen Bedarf formulieren und die Technologieauswahl als Entscheidung dokumentiert werden.

Aussage	Klassifikation	Grund
Alle mandantenbezogenen Lesezugriffe müssen die Mandantentrennung durchsetzen	Anforderung / Sicherheitseigenschaft	Beschreibt eine Eigenschaft, die gelten muss
Row Level Security von PostgreSQL für ausgewählte mandantenbezogene Tabellen verwenden	Architekturentscheidung	Wählt einen Mechanismus, der dazu beitragen soll, die Isolationsanforderung zu erfüllen
Das Bereitstellungsziel muss in einer genehmigten, in der EU betriebenen Umgebung laufen	Randbedingung / NFR-ähnliche Betriebsbedingung	Schränkt ein, wo das System betrieben werden darf
Anbieter X in Region Y verwenden	Architektur- / Bereitstellungsentscheidung, sofern nicht extern vorgeschrieben	Wählt eine bestimmte Lösung innerhalb der zulässigen Grenze
95. Perzentil der API-Latenz ≤ 300 ms unter Last W	Qualitätsanforderung	Definiert messbares Leistungsverhalten
Einen Cache für Endpunkt X einführen	Architekturentscheidung	Wählt eine Taktik, die das gemessene Verhalten verbessern soll

Ein ADR ist kein Nachweis, dass eine NFR erfüllt wurde

Entscheidungsdokumentation und Systemvalidierung beantworten unterschiedliche Fragen. Ein ADR kann zeigen, dass Leistung, Sicherheit, Resilienz oder Wartbarkeit berücksichtigt wurden. Es kann für sich genommen nicht belegen, dass das gelieferte System diese Eigenschaften tatsächlich erreicht.

Der Nachweis muss aus der für die Anforderung geeigneten Validierungsmethode stammen: Benchmark, Lasttest, Fehlertest, Sicherheitstest, Architekturanalyse, Audit, Inspektion, Betriebstelemetrie, Wiederherstellungsübung, Nutzerstudie oder eine andere Form von Evidenz.

Wann wird eine NFR architektonisch bedeutsam?

Nicht jede nicht-funktionale Anforderung verdient eine Architekturentscheidung. Die wichtige Teilmenge sind die Anforderungen, die die Architektur wesentlich prägen oder systemweite Trade-offs erzwingen.

Die SEI-Literatur verwendet das Konzept der architektonisch bedeutsamen Anforderungen für Anforderungen mit weitreichender architektonischer Wirkung. Qualitätsmerkmale wie Leistung, Zuverlässigkeit, Sicherheit und Änderbarkeit sind häufige Quellen solcher Treiber, insbesondere wenn sie einen hohen Geschäfts- oder Missionswert haben.

Test auf architektonische Bedeutsamkeit

1

1. Fragen, ob die Anforderung die Struktur verändert

Würden unterschiedliche Werte unterschiedliche Komponenten, Grenzen, Datenpfade oder Bereitstellungstopologien erzwingen?

2

2. Fragen, ob sie wesentliche Technologieentscheidungen einschränkt

Schließt sie ansonsten tragfähige Implementierungsoptionen aus?

3

3. Fragen, ob sie querschnittliches Verhalten erzeugt

Betrifft sie viele Komponenten, Teams, Schnittstellen oder Lebenszyklusphasen?

4

4. Fragen, ob sie einen schwierigen Trade-off erzeugt

Beeinflusst die Verbesserung dieser Eigenschaft wesentlich eine andere Qualität, Kosten, Zeitplan, Komplexität oder Risiko?

5

5. Fragen, ob ein Fehlschlag teuer ist

Würde das Verfehlen der Anforderung wesentliche betriebliche, sicherheitsbezogene, regulatorische, finanzielle oder produktbezogene Auswirkungen haben?

6

6. Entscheidungen nur dort festhalten, wo die Begründung es wert ist, bewahrt zu werden

Erstellen Sie nicht für jede lokale Codierungsentscheidung ADRs; bewahren Sie architektonisch bedeutsame Entscheidungen und ihre Begründung.

Ein stärkeres Architekturmodell: Anforderung → Entscheidung → Implementierung → Validierung

Die nützlichste Verbindung zwischen NFRs und ADRs ist die Rückverfolgbarkeit. Eine Anforderung sollte auf die Architekturentscheidungen verweisen können, die sie adressieren; ein ADR sollte die Treiber identifizieren, auf die es reagiert; die Implementierungsarbeit sollte die Entscheidung realisieren; die Validierung sollte zur ursprünglichen Anforderung zurückführen.

Architektur-Rückverfolgbarkeitskette

1

Bedarf / Geschäftsziel

Warum die Qualität oder Einschränkung wichtig ist.

2

Anforderung / NFR

Was das System erreichen oder respektieren muss.

3

Architekturtreiber

Welche Anforderungen bedeutsam genug sind, um das Design zu prägen.

4

Optionen

Plausible Wege, den Treiber zu adressieren.

5

ADR

Die gewählte Option, Begründung, Alternativen, Trade-offs und Konsequenzen.

6

Implementierung

Code, Datenmodell, Infrastruktur, Schnittstellen und operative Mechanismen, die die Entscheidung realisieren.

7

Validierungsnachweis

Tests, Messungen, Analysen oder Audits, die zeigen, ob die ursprüngliche Anforderung tatsächlich erfüllt ist.

8

Änderung / Ablösung

Neue Evidenz oder geänderte Anforderungen können ein neues ADR auslösen, während die historische Begründung erhalten bleibt.

Implementierungsnachweis: Wie ich Anforderungen und Entscheidungen in SenseFlow trenne

In SenseFlow platziert die projektweite Source of Truth nicht-funktionale Anforderungen ausdrücklich innerhalb der Anforderungsstruktur zusammen mit Abhängigkeiten, Risiken, Annahmen, Abnahmekriterien und einer Validierungsmethode. Das Dokumentationsmodell definiert separat die Entscheidungsintegrität für bedeutsame Entscheidungen.

Für bedeutsame SenseFlow-Entscheidungen sind die erfassten Felder Entscheidung, Grund, Alternativen, Trade-offs, Status und Datum / Version. Wesentliche Architektur- und Produktentscheidungen sollen historisch nachvollziehbar bleiben, anstatt überschrieben zu werden, wenn sich das Projekt weiterentwickelt.

SenseFlow weist Confluence und Jira außerdem unterschiedliche operative Rollen zu. Confluence ist die strukturierte Wissens- und Entscheidungsumgebung; Jira verwaltet umsetzbare Lieferarbeit. Wichtige Jira-Epics sollten auf die relevante Produkt- oder Anforderungsdokumentation zurückverweisen. Dies bewahrt die Kette von der Produktabsicht über Anforderungen und Entscheidungen bis zur Implementierung, anstatt das Backlog zur architektonischen Source of Truth zu machen.

SenseFlow-Ebene	Was sie enthält	Rolle bei der ADR/NFR-Trennung
Produkt- / Anforderungsstruktur	Produktziel, Fähigkeit, Epic, User Story, Abnahmekriterien, technische Aufgaben; Anforderungen können NFRs und Validierungsmethode enthalten	Bewahrt, was erreicht werden muss und wie der Erfolg geprüft wird
Entscheidungsintegrität	Entscheidung, Grund, Alternativen, Trade-offs, Status, Datum/Version	Bewahrt, warum eine architektonisch bedeutsame Wahl maßgeblich wurde
Confluence	Anforderungen, Architektur, Forschung, Entscheidungsaufzeichnungen, Risiken, Roadmap und unterstützende Quellen	Pflegt die konzeptionelle und historische Source of Truth
Jira	Initiativen/Ziele, Epics, Stories, Aufgaben und Lieferstatus	Führt genehmigte Arbeit aus, ohne zur konzeptionellen Source of Truth zu werden
Änderungsmanagement	Aktueller Zustand → neue Evidenz → vorgeschlagene Änderung → Auswirkung → Entscheidung	Ermöglicht Entscheidungen sich weiterzuentwickeln, ohne die Begründungsspur zu löschen
End-to-End-Rückverfolgbarkeit	Problem → Bedarf → Wert → Produktziel → Anforderung → Implementierung → Validierung	Hält die Entscheidungsdokumentation mit dem tatsächlichen Produkt- und Evidenzlebenszyklus verbunden

Unternehmensprojektkontext: Anforderungen sollten Architekturentscheidungen vorausgehen

Dieselbe Trennung ist in unternehmensorientierter Projektarbeit nützlich. Architekturentscheidungen, die getroffen werden, bevor Anforderungen, Risiken, Einschränkungen und Abnahmebedingungen ausreichend verstanden sind, können Präferenzen in falsche Notwendigkeiten verwandeln.

Für Enterprise Aaasaasa 0.1 ist die relevante Lektion methodisch und keine Aussage über ein bestimmtes ADR: Anforderungen, Architektur, Validierung, Meilensteine, Risikomanagement und Abnahme gehören zu einem verbundenen Liefersystem. Eine Architekturwahl sollte auf die Anforderung oder Einschränkung zurückverfolgbar bleiben, die sie adressieren soll.

Häufige Fehlermuster, wenn ADRs und NFRs vermischt werden

Fehlermuster	Was passiert	Konsequenz
Technologie als Anforderung getarnt	Eine bevorzugte Lösung wird als „muss X verwenden“ geschrieben, ohne den zugrunde liegenden Bedarf festzustellen	Alternativen werden nie bewertet und die Architektur wird vorzeitig fixiert
NFR nur in einem ADR versteckt	Die Entscheidung erwähnt ein Leistungs-/Sicherheitsziel, das in der Anforderungsbasis fehlt	Das Ziel ist schwer unabhängig zu validieren, zu priorisieren oder zu verwalten
ADR als Beweis behandelt	Es wird angenommen, dass eine dokumentierte Wahl bedeutet, dass die Anforderung erfüllt ist	Architektur-Absicht ersetzt Messung oder Verifikation
Vage NFR	Wörter wie schnell, skalierbar, sicher oder wartbar haben keinen messbaren Umfang	Verschiedene Stakeholder können glauben, dass dieselbe Anforderung unterschiedliche Dinge bedeutet
Keine Alternativen dokumentiert	Das Team dokumentiert nur die ausgewählte Technologie	Zukünftige Maintainer können nicht rekonstruieren, warum eine andere Option abgelehnt wurde
Kein Ablösemodell	Alte ADRs werden bearbeitet oder gelöscht, wenn sich die Architektur ändert	Historische Begründung verschwindet und veraltete Entscheidungen können mehrdeutig bleiben
Jedes Implementierungsdetail wird ein ADR	Das Repository füllt sich mit Einträgen von geringem Wert	Wichtige Architekturentscheidungen werden schwer auffindbar
Backlog wird zur Architektur-SoT	Jira-Aufgaben werden als einzige Erklärung des Systems behandelt	Der Lieferstatus bleibt erhalten, aber architektonische Begründung und Qualitätstreiber gehen verloren

Das ADR–NFR-Entscheidungsframework

Wenn ein Team auf ein neues Architekturanliegen stößt, hilft die folgende Reihenfolge dabei zu bestimmen, was zu den Anforderungen gehört, was zu einem ADR gehört und was zu den Nachweisen gehört.

ADR–NFR-Klassifizierungstest

1

1. Ist dies eine erforderliche Eigenschaft oder externe Einschränkung?

Wenn ja, schreiben oder referenzieren Sie die Anforderung, bevor Sie einen Mechanismus wählen.

2

2. Kann es validiert werden?

Definieren Sie den Umfang, die Bedingung, die Metrik, die Akzeptanzregel, die Analysemethode oder andere erforderliche Nachweise.

3

3. Ist es architektonisch signifikant?

Stellen Sie fest, ob die Anforderung Struktur, Technologie, Daten, Bereitstellung oder querschnittliche Kompromisse wesentlich prägt.

4

4. Gibt es sinnvolle Alternativen?

Vergleichen Sie praktikable Taktiken oder Architekturoptionen, anstatt direkt zu einer bevorzugten Technologie zu springen.

5

5. Ist eine Wahl maßgeblich geworden?

Erstellen oder aktualisieren Sie das ADR mit Kontext, Entscheidung, Begründung, Alternativen, Kompromissen, Status und Konsequenzen.

6

6. Ist die Entscheidung umgesetzt?

Verfolgen Sie das ADR in Design, Aufgaben, Code, Konfiguration und Betrieb.

7

7. Ist die Anforderung erfüllt?

Sammeln Sie Validierungsnachweise gegen die Anforderung selbst.

8

8. Haben sich die Bedingungen geändert?

Bewerten Sie die Anforderung neu und lösen Sie bei Bedarf das ADR ab, ohne die Historie zu löschen.

Was ADR und NFR nicht sind

Häufige Kategorienfehler

	Konzept	Es ist nicht	Grund
NFR / Qualitätsanforderung	A required quality, constraint or operating condition	A technology shopping list	Requirements should preserve the need independently from one implementation when possible
ADR	A record of an architecturally significant decision	The complete architecture description	Architecture also needs views, interfaces, models, responsibilities and other documentation
Validierungsnachweis	Evidence that checks whether a requirement is satisfied	The ADR itself	Documented intent is different from measured or analyzed system behavior
Backlog-Eintrag	Actionable delivery work	A durable substitute for architecture rationale	Task state answers what is being delivered, not necessarily why the architecture exists
Einschränkung	A condition that restricts the solution space	Always an internally chosen architecture decision	Some constraints come from regulation, contracts, existing platforms or organizational boundaries

Was würde diese Antwort ändern?

Die Terminologie kann sich weiterentwickeln. ISO/IEC/IEEE 29148:2018 bleibt der aktuelle veröffentlichte Standard für Requirements Engineering mit Stand 8. Oktober 2026, aber ISO listet einen Draft International Standard auf, der ihn ersetzen soll. Wenn die neue Ausgabe relevante Terminologie oder Anforderungsleitlinien ändert, sollten die versionsspezifischen Referenzen in diesem Artikel aktualisiert werden.

ADR-Vorlagen können sich ebenfalls weiterentwickeln, ohne die zentrale Unterscheidung zu ändern. Michael Nygards minimale Vorlage, MADR, organisationsspezifische Vorlagen, Architekturwissenswerkzeuge oder strukturierte Entscheidungsdatenbanken können alle Entscheidungen aufzeichnen. Die dauerhafte Frage ist, ob die Aufzeichnung genügend Kontext und Begründung bewahrt, um eine architektonisch signifikante Wahl zu verstehen.

Die Unterscheidung würde nur zusammenbrechen, wenn eine Organisation bewusst ein kombiniertes Artefakt wählt, das sowohl Anforderungs- als auch Entscheidungsdaten in einem Dokument speichert. Selbst dann bleiben die semantischen Rollen unterschiedlich: Ein Feld gibt das erforderliche Ergebnis oder die Einschränkung an; ein anderes zeichnet die gewählte Antwort auf.

Einschränkungen

Dieser Artikel verwendet NFR als praktische Kurzform. Einige Engineering-Methoden bevorzugen Begriffe wie Qualitätsattributanforderung, Qualitätsanforderung, Systemqualität, Einschränkung, Service-Level-Ziel oder architektonisch signifikante Anforderung. Diese Begriffe sind nicht perfekt austauschbar, und die Projektterminologie sollte explizit sein.

Nicht jede Anforderung kann auf einen einzelnen numerischen Schwellenwert reduziert werden. Sicherheit, Schutz, Wartbarkeit, Interoperabilität, Benutzerfreundlichkeit, Erklärbarkeit, Portabilität und Governance können Kombinationen aus Szenarien, strukturellen Regeln, Analysen, Prozesskontrollen und qualitativen Nachweisen erfordern. „Messbar“ sollte ausreichend verifizierbar für die Entscheidung bedeuten, nicht künstlich numerisch.

Nicht jede Architekturentscheidung benötigt ein formales ADR. Die Dokumentationskosten sollten proportional zur architektonischen Bedeutung, Langlebigkeit, Unsicherheit, Komplexität der Kompromisse und den Kosten des Verlusts der Begründung sein.

Fazit

ADR und NFR gehören zu unterschiedlichen Schichten der Architekturarbeit. Die NFR definiert ein Qualitätsziel, eine Einschränkung oder eine Betriebsbedingung. Das ADR zeichnet eine signifikante architektonische Antwort auf einen oder mehrere Treiber auf.

Diese Schichten getrennt zu halten, macht die Architektur leichter nachvollziehbar. Anforderungen können unabhängig von der Technologie validiert werden. Entscheidungen können abgelöst werden, ohne die Historie neu zu schreiben. Alternativen und Kompromisse bleiben sichtbar. Lieferarbeit kann auf die architektonische Absicht zurückverfolgt werden. Nachweise können zeigen, ob das resultierende System die Anforderung tatsächlich erfüllt.

Die stärkste Kette ist daher nicht „NFR → ADR → fertig“. Sie ist Bedürfnis → Anforderung → architektonische Treiber → Optionen → Entscheidung → Umsetzung → Validierung → Änderung. Diese Kette verwandelt Architekturdokumentation von statischem Papierkram in eine überprüfbare Aufzeichnung darüber, warum das System die Form hat, die es hat.

FAQ

ADR vs. NFR

Ist ein ADR eine nicht-funktionale Anforderung?

Nein. Eine NFR beschreibt eine geforderte Qualität, Einschränkung oder Betriebsbedingung. Ein ADR dokumentiert eine architektonisch bedeutsame Entscheidung, die als Reaktion auf Anforderungen, Einschränkungen, Risiken und Abwägungen getroffen wurde.

Sollte jede NFR ein ADR haben?

Nein. Nur Anforderungen, die die Architektur wesentlich beeinflussen, benötigen Entscheidungen auf Architekturebene, die es wert sind, bewahrt zu werden. Eine NFR kann auch mehrere ADRs vorantreiben, und ein ADR kann auf mehrere Anforderungen reagieren.

Kann „PostgreSQL verwenden“ eine NFR sein?

Nur wenn PostgreSQL tatsächlich als externe Einschränkung vorgegeben ist. Andernfalls sollte zuerst das zugrunde liegende Bedürfnis ausgedrückt werden, und die Auswahl von PostgreSQL sollte normalerweise als Architekturentscheidung behandelt werden.

Beweist ein ADR, dass eine Leistungs- oder Sicherheitsanforderung erfüllt ist?

Nein. Ein ADR dokumentiert Absicht und Begründung. Die Anforderung wird durch geeignete Nachweise wie Tests, Messungen, Analysen, Audits oder betriebliche Telemetrie validiert.

Was sollte ein ADR enthalten?

Mindestens sollte ein ADR den Kontext und die Entscheidung klar machen. Übliche Strukturen umfassen auch Status und Konsequenzen. Teams können Alternativen, Begründungen, Abwägungen, Anforderungsverknüpfungen, Nachweise, Verantwortliche, Daten und Ablösungsbeziehungen hinzufügen.

Was macht eine NFR architektonisch bedeutsam?

Eine Anforderung ist architektonisch bedeutsam, wenn sie die Systemstruktur, Technologie, Datenflüsse, Bereitstellung, querschnittliches Verhalten oder schwierige Qualitätsabwägungen wesentlich prägt, insbesondere wenn ein Scheitern hohe geschäftliche oder missionelle Auswirkungen hat.

Sollte ein altes ADR gelöscht werden, wenn sich die Architektur ändert?

Normalerweise nein. Eine Ersatzentscheidung sollte den alten Datensatz in der Regel ablösen, damit die historische Begründung nachvollziehbar bleibt.

Glossar

Zentrale Architekturbegriffe

NFR: Nicht-funktionale Anforderung: praktische Kurzbezeichnung für eine geforderte Systemqualität, Einschränkung oder Betriebsbedingung; die genaue Terminologie variiert je nach Methode und Standard.
Qualitätsattributanforderung: Eine Anforderung, die eine Qualitätseigenschaft beschreibt, die das System unter definierten Bedingungen aufweisen soll, wie Leistung, Verfügbarkeit, Sicherheit, Zuverlässigkeit oder Änderbarkeit.
Architecture Decision Record (ADR): Eine dauerhafte Aufzeichnung einer architektonisch bedeutsamen Entscheidung und genügend Kontext, um zu verstehen, warum die Wahl getroffen wurde und welche Konsequenzen daraus folgen.
Architektonisch bedeutsame Anforderung (ASR): Eine Anforderung mit ausreichend weitreichender architektonischer Wirkung, dass sie das Systemdesign wesentlich beeinflusst.
Einschränkung: Eine Bedingung, die den Lösungsraum einschränkt, einschließlich externer Richtlinien, Vorschriften, Plattform-, Kompatibilitäts-, vertraglicher oder organisatorischer Grenzen.
Abwägung: Eine Designbeziehung, bei der die Verbesserung eines Ziels, einer Eigenschaft oder einer Kostendimension eine andere verschlechtern kann.
Validierung: Nachweise erzeugende Arbeit, mit der festgestellt wird, ob das implementierte System die angegebene Anforderung unter den relevanten Bedingungen erfüllt.
Abgelöstes ADR: Ein historischer Entscheidungsdatensatz, der durch eine neuere maßgebliche Entscheidung ersetzt wurde, aber für die Nachvollziehbarkeit verfügbar bleibt.

Primärquellen und Umsetzungsnachweise

Dieser Artikel trennt aktuelle Standards von Projektumsetzungsnachweisen. ISO/IEC/IEEE 29148:2018 ist mit Stand vom 8. Oktober 2026 weiterhin aktuell, aber zur Überarbeitung vorgesehen; ISO/IEC 25010:2023 und ISO/IEC/IEEE 42010:2022 sind aktuelle veröffentlichte Ausgaben. SenseFlow ist ein originärer Projektnachweis für das oben beschriebene Modell der Nachvollziehbarkeit und Entscheidungsintegrität.

ISO/IEC/IEEE 29148:2018 — Requirements Engineering

Aktueller veröffentlichter Standard für Requirements Engineering. ISO gibt an, dass die Ausgabe von 2018 im Jahr 2024 überprüft und bestätigt wurde und voraussichtlich durch den derzeit in Entwicklung befindlichen DIS ersetzt wird.

ISO/IEC/IEEE DIS 29148 — Requirements Engineering

Draft International Standard, der sich derzeit in Entwicklung befindet und ISO/IEC/IEEE 29148:2018 ersetzen soll.

ISO/IEC 25010:2023 — Produktqualitätsmodell

Aktuelles Produktqualitätsmodell mit neun Qualitätsmerkmalen, das zur Spezifikation, Messung und Bewertung der Qualität von IKT- und Softwareprodukten verwendet wird.

ISO/IEC/IEEE 42010:2022 — Architekturbeschreibung

Aktueller Standard für Architekturbeschreibung. Er legt Konzepte und Konformitätsanforderungen für Architekturbeschreibungen fest, ohne ein bestimmtes Aufzeichnungsformat, eine Notation, einen Prozess oder ein Werkzeug vorzuschreiben.

Michael Nygard — Documenting Architecture Decisions

Ursprünglicher einflussreicher ADR-Artikel, der leichtgewichtige Aufzeichnungen beschreibt, die auf Kontext, Entscheidung, Status und Konsequenzen ausgerichtet sind, wobei abgelöste Entscheidungen für das historische Verständnis erhalten bleiben.

SEI — Relating Business Goals to Architecturally Significant Requirements

SEI-Bericht, der erklärt, wie Qualitätsattributanforderungen und Geschäftsziele die Softwarearchitektur prägen und warum architektonisch bedeutsame Anforderungen explizit erhoben werden müssen.

SEI — Defining Non-Functional System Qualities

SEI-Überblick, der nicht-funktionale/Qualitätsattribute mit Architektur, Szenarien, Abwägungen und objektiver Systembewertung verbindet.

SEI — Attribute-Driven Design Method Collection

Architekturdesignmethode auf Basis funktionaler Anforderungen, Qualitätsattributanforderungen und Einschränkungen, bei der architektonische Taktiken und Muster ausgewählt werden, um Qualitätsszenarien zu erfüllen.

SEI — Views and Beyond Collection

Leitfaden zur Architekturdokumentation, der relevante Sichten und die Aufzeichnung notwendiger Designentscheidungen als Teil der Architekturarbeit betont.

Auf X teilen Auf Xing teilen Auf Facebook teilen Auf LinkedIn teilen Auf Telegram teilen Per E-Mail teilen