[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:de":3,"public-menus:all":37,"post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:de":204,"related:post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:de:1":2039},{"statusCode":4,"data":5,"message":36},200,{"tenantId":6,"lang":7,"defaultLang":7,"siteUrl":8,"contactEmail":9,"brandName":10,"logoUrl":11,"siteName":10,"siteDescription":12,"ogImage":9,"robotsIndex":13,"socialLinks":9,"reservedSlugs":9,"seoPolicy":14},"stajic","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":15,"relatedContent":16,"crossDomainLinks":17},{"logoUrl":11},{"enabled":13},[18,21,24,27,30,33],{"url":19,"label":20,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":22,"label":23,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":25,"label":26,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Fbazify.com","bazify.com",{"url":28,"label":29,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Fbazify.de","bazify.de",{"url":31,"label":32,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Fbazify.at","bazify.at",{"url":34,"label":35,"isActive":13,"showInFooter":13,"includeInSameAs":13},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[38,44],{"id":39,"name":40,"location":41,"isActive":13,"isDefault":42,"items":43},1,"main-navigation","header",false,[],{"id":45,"name":46,"location":47,"isActive":13,"isDefault":13,"items":48},4,"main-menu","sidebar",[49,65,78,92,102,117,132],{"id":50,"title":51,"url":59,"target":60,"icon":61,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":63,"portfolioId":9,"children":64},"item-18",{"de":52,"en":53,"es":54,"fr":55,"it":53,"ru":56,"sr":57,"zh":58},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":66,"title":67,"url":74,"target":60,"icon":75,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":76,"portfolioId":9,"children":77},"item-22",{"de":68,"en":68,"es":69,"fr":68,"it":70,"ru":71,"sr":72,"zh":73},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":79,"title":80,"url":88,"target":60,"icon":89,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":90,"portfolioId":9,"children":91},"item-19",{"de":81,"en":82,"es":83,"fr":82,"it":84,"ru":85,"sr":86,"zh":87},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":93,"title":94,"url":98,"target":60,"icon":99,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":100,"portfolioId":9,"children":101},"item-23",{"de":95,"en":95,"es":95,"fr":95,"it":95,"ru":96,"sr":96,"zh":97},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":103,"title":104,"url":113,"target":60,"icon":114,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":115,"portfolioId":9,"children":116},"item-32",{"de":105,"en":106,"es":107,"fr":108,"it":109,"ru":110,"sr":111,"zh":112},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":118,"title":119,"url":128,"target":60,"icon":129,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":130,"portfolioId":9,"children":131},"item-20",{"de":120,"en":121,"es":122,"fr":123,"it":124,"ru":125,"sr":126,"zh":127},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":133,"title":134,"url":143,"target":60,"icon":144,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":145,"portfolioId":9,"children":146},"item-21",{"de":135,"en":136,"es":137,"fr":138,"it":139,"ru":140,"sr":141,"zh":142},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[147,160,174,180,192],{"id":148,"title":149,"url":143,"target":60,"icon":158,"isActive":13,"type":62,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":145,"portfolioId":9,"children":159},"item-24",{"de":150,"en":151,"es":152,"fr":153,"it":154,"ru":155,"sr":156,"zh":157},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":161,"title":162,"url":170,"target":60,"icon":171,"isActive":13,"type":172,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":9,"portfolioId":9,"children":173},"item-29",{"de":163,"en":164,"es":165,"fr":166,"it":167,"ru":168,"sr":169,"zh":142},"Local Roots, Global Reach","Local Roots - Global Reach","Empresa local ","Entreprise locale","Azienda locale","Местная компания","Локално предузеће глобално тржиште","\u002Fportfolio\u002Flocal-roots-global-reach-communication-media-systems-for-modern-business","i-lucide-folder","custom",[],{"id":175,"title":176,"url":178,"target":60,"icon":171,"isActive":13,"type":172,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":9,"portfolioId":9,"children":179},"item-28",{"de":177,"en":177,"es":177,"fr":177,"it":177,"ru":177,"sr":177,"zh":177},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":181,"title":182,"url":190,"target":60,"icon":171,"isActive":13,"type":172,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":9,"portfolioId":9,"children":191},"item-27",{"de":183,"en":184,"es":185,"fr":186,"it":187,"ru":188,"sr":189,"zh":184},"Firmenwebseite SEO","Company Website SEO","Sitio web corporativo SEO","Site web d’entreprise SEO","Sito web aziendale SEO","Корпоративный сайт SEO","Пословна веб-страница SEO","\u002Fportfolio\u002Fseo-sem-branding-mobile-webseite-muenchen",[],{"id":193,"title":194,"url":202,"target":60,"icon":171,"isActive":13,"type":172,"productId":9,"categoryId":9,"shopCategoryId":9,"articleId":9,"pageId":9,"portfolioId":9,"children":203},"item-31",{"de":195,"en":196,"es":197,"fr":198,"it":199,"ru":200,"sr":201,"zh":196},"Digitalisierungsportal","Digitalization Portal","Portal de digitalización","Portail de numérisation","Portale di digitalizzazione","Портал цифровизации","Портал за дигитализацију","\u002Fportfolio\u002Fdigitalisierungsportal-archiv-museum-bibliothek-ead-lido-mets-mods",[],{"statusCode":4,"data":205,"message":2038},{"id":206,"title":207,"slug":208,"content":209,"contentJson":210,"excerpt":1031,"featuredImage":1032,"featuredImageAlt":1033,"featuredImageCaption":9,"featuredImageTitle":9,"featuredImageCopyright":9,"featuredImageAuthor":9,"featuredImageSourceUrl":9,"featuredImageLicense":9,"featuredImageIsAiGenerated":42,"status":1034,"publishedAt":1035,"createdAt":1036,"updatedAt":1037,"seoLocalePaths":1038,"categories":1047,"author":1068,"translations":1073},"482","ADR vs. NFR: Architekturentscheidungen und Systemqualität sind nicht dasselbe","adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u003Cp>Eine \u003Cstrong>nicht-funktionale Anforderung (NFR)\u003C\u002Fstrong> beschreibt eine Qualität, eine Einschränkung oder eine Betriebsbedingung, die das System erfüllen soll. Ein \u003Cstrong>Architecture Decision Record (ADR)\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--info my-6 rounded-xl border p-5 border-blue-300 bg-blue-50 dark:border-blue-900 dark:bg-blue-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Direkte Antwort\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>NFR = erforderliche Systemqualität oder Einschränkung. ADR = dokumentierte Architekturentscheidung.\u003C\u002Fstrong> Ein Latenzziel, ein Verfügbarkeitsziel, eine Isolationsregel, eine Bereitstellungseinschränkung oder eine Wartbarkeitsanforderung kann die Architektur beeinflussen. Ein ADR dokumentiert dann eine bedeutsame Entscheidung, die getroffen wurde, um einen oder mehrere solcher Treiber zu adressieren. Der ADR ersetzt nicht die Anforderung, und die Existenz eines ADR beweist nicht, dass die Anforderung erfüllt wurde.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Hinweis zu Terminologie und Standards\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Der Begriff \u003Cstrong>NFR\u003C\u002Fstrong> ist weit verbreitet, aber nicht vollständig standardisiert. Dieser Artikel verwendet ihn als praktische Kurzform für Qualitätsanforderungen und relevante Einschränkungen. Aktuelle Standards wurden am \u003Cstrong>8. Oktober 2026\u003C\u002Fstrong> erneut geprüft: ISO\u002FIEC\u002FIEEE 29148:2018 ist weiterhin aktuell, wird jedoch überarbeitet; ISO\u002FIEC 25010:2023 und ISO\u002FIEC\u002FIEEE 42010:2022 sind die hier zitierten aktuellen veröffentlichten Ausgaben.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Inhalt\">\u003Cstrong class=\"editorjs-toc__title\">Inhalt\u003C\u002Fstrong>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-0\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-5\" class=\"editorjs-toc__link\">Was ist der Unterschied zwischen einer NFR und einem ADR?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">Was ist eine NFR in präzisen architektonischen Begriffen?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-16\" class=\"editorjs-toc__link\">Was ist ein Architecture Decision Record?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-21\" class=\"editorjs-toc__link\">Das einfachste Beispiel: Latenzanforderung → Architekturentscheidung\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-26\" class=\"editorjs-toc__link\">NFRs und ADRs haben üblicherweise eine Viele-zu-viele-Beziehung\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-30\" class=\"editorjs-toc__link\">Eine Technologieentscheidung ist nicht automatisch eine Anforderung\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-34\" class=\"editorjs-toc__link\">Ein ADR ist kein Nachweis, dass eine NFR erfüllt wurde\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-38\" class=\"editorjs-toc__link\">Wann wird eine NFR architektonisch bedeutsam?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-42\" class=\"editorjs-toc__link\">Ein stärkeres Architekturmodell: Anforderung → Entscheidung → Implementierung → Validierung\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-45\" class=\"editorjs-toc__link\">Implementierungsnachweis: Wie ich Anforderungen und Entscheidungen in SenseFlow trenne\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-52\" class=\"editorjs-toc__link\">Unternehmensprojektkontext: Anforderungen sollten Architekturentscheidungen vorausgehen\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-55\" class=\"editorjs-toc__link\">Häufige Fehlermuster, wenn ADRs und NFRs vermischt werden\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-57\" class=\"editorjs-toc__link\">Das ADR–NFR-Entscheidungsframework\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-60\" class=\"editorjs-toc__link\">Was ADR und NFR nicht sind\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-62\" class=\"editorjs-toc__link\">Was würde diese Antwort ändern?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-66\" class=\"editorjs-toc__link\">Einschränkungen\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-70\" class=\"editorjs-toc__link\">Fazit\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-74\" class=\"editorjs-toc__link\">FAQ\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-76\" class=\"editorjs-toc__link\">Glossar\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Primärquellen und Umsetzungsnachweise\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-5\">Was ist der Unterschied zwischen einer NFR und einem ADR?\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>Zum Beispiel ist \u003Cstrong>„Die API muss 95 % der Leseanfragen innerhalb von 300 ms unter der vereinbarten Referenzlast zurückgeben“\u003C\u002Fstrong> eine Qualitätsanforderung. \u003Cstrong>„Verwenden Sie einen Read-Through-Cache für diese Arbeitslast, weil der gemessene reine Datenbankpfad das Latenzziel nicht ohne unakzeptable Kosten erreichen kann“\u003C\u002Fstrong> ist eine Architekturentscheidung.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">NFR und ADR beantworten unterschiedliche Fragen\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">NFR \u002F Qualitätsanforderung\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">ADR \u002F Architekturentscheidung\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Primäre Frage\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What quality, constraint, or operating condition must the system satisfy?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What architecturally significant choice did we make, and why?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Typischer Inhalt\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Measurable target, scope, condition, constraint, acceptance or validation rule\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Context, decision, rationale, alternatives, trade-offs, status and consequences\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Rolle im Lebenszyklus\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A requirement to design for and validate\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A historical record of a significant decision\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Was beweist sie?\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Measurement, test, analysis, inspection, audit or other validation evidence\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The record proves what was decided, not that the resulting system meets the requirement\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Wann ändert sie sich\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">When stakeholder need, operating conditions, policy or quality target changes\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">When the decision is replaced, rejected, deprecated, or superseded\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-10\">Was ist eine NFR in präzisen architektonischen Begriffen?\u003C\u002Fh2>\n\u003Cp>„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 \u003Cstrong>funktionalem Verhalten\u003C\u002Fstrong>, \u003Cstrong>Qualitätsanforderungen\u003C\u002Fstrong> und \u003Cstrong>Einschränkungen\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Schwache Aussage\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Nützlichere Anforderungsform\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Warum der Unterschied wichtig ist\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Die API muss schnell sein\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Für Arbeitslast W schließt 95 % von Operation X innerhalb von T Millisekunden ab\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Definiert Arbeitslast, Operation, Metrik und Schwellenwert\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Der Dienst muss verfügbar sein\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Dienst S erfüllt ein vereinbartes Verfügbarkeitsziel über das Messfenster M, unter Ausschluss explizit definierter Wartungsbedingungen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Macht Verfügbarkeit messbar und definiert den Umfang\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mandantendaten müssen sicher sein\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Eine für Mandant A authentifizierte Anfrage darf niemals Daten von Mandant B über unterstützte Anwendungspfade abrufen oder verändern\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Verwandelt ein vages Sicherheitsziel in eine Isolationsanforderung\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Das System sollte skalieren\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Das System unterstützt Arbeitslast W bei Nebenläufigkeit C und erfüllt dabei Latenz- und Fehlerratenschwellenwerte\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Verbindet Skalierung mit messbarem Dienstverhalten\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wir brauchen PostgreSQL\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Keine NFR an sich; geben Sie zuerst die erforderlichen Persistenzqualitäten oder externen Einschränkungen an\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Eine Technologieentscheidung ist normalerweise eine Lösung, nicht die Anforderung, die sie erfüllen soll\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Eine Anforderung sollte den Bedarf vor dem Mechanismus beschreiben\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Wenn „Kubernetes verwenden“, „PostgreSQL verwenden“, „Microservices verwenden“ oder „Vektorsuche verwenden“ als Anforderung erscheint, fragen Sie, ob es sich wirklich um eine externe Einschränkung handelt oder ob die Lösung aufgeschrieben wurde, bevor der zugrunde liegende Qualitätsbedarf explizit gemacht wurde.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-16\">Was ist ein Architecture Decision Record?\u003C\u002Fh2>\n\u003Cp>Ein Architecture Decision Record ist eine kompakte Aufzeichnung einer wichtigen Architekturentscheidung. Michael Nygards ursprüngliche ADR-Formulierung betont den \u003Cstrong>Kontext\u003C\u002Fstrong>, die \u003Cstrong>Entscheidung\u003C\u002Fstrong>, ihren \u003Cstrong>Status\u003C\u002Fstrong> und die daraus resultierenden \u003Cstrong>Konsequenzen\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC\u002FIEEE 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.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">ADR-Feld\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Was es bewahrt\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Warum es wichtig ist\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Kontext\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Das Problem, die Kräfte, Anforderungen, Annahmen und das Umfeld der Entscheidung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Zukünftige Leser können rekonstruieren, warum eine Entscheidung notwendig war\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Entscheidung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Die Entscheidung, die verbindlich wurde\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Trennt die gewählte Option von der Diskussion\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Status\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Vorgeschlagen, akzeptiert, abgelehnt, veraltet, ersetzt oder ein anderer kontrollierter Zustand\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Verhindert, dass alte Entscheidungen stillschweigend aktiv bleiben\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alternativen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Andere in Betracht gezogene gangbare Optionen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Zeigt, dass die gewählte Lösung nicht die einzig denkbare war\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Begründung \u002F Abwägungen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Warum die Option gewählt wurde und was sie aufgibt\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Macht die Architekturbegründung nachprüfbar\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Konsequenzen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Erwartete positive und negative Auswirkungen, Folgearbeiten, Risiken\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Verbindet eine lokale Entscheidung mit der Systemwirkung\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Datum \u002F Version\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wann die Entscheidung gültig wurde\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Unterstützt die historische Nachverfolgbarkeit und spätere Ersetzung\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-21\">Das einfachste Beispiel: Latenzanforderung → Architekturentscheidung\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Von der Anforderung zum Nachweis\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Anforderung formulieren\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Definieren Sie das Qualitätsziel, die Last, den Geltungsbereich, den Schwellenwert und die Validierungsmethode.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Architektonische Bedeutung erkennen\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Stellen Sie fest, ob die Anforderung Struktur, Technologie, Bereitstellung, Datenfluss oder Betriebsmodell wesentlich beeinflusst.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Optionen bewerten\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Vergleichen Sie Alternativen wie Indexierung, Caching, Denormalisierung, asynchrone Verarbeitung, Partitionierung oder eine andere Abfragearchitektur.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Entscheidung dokumentieren\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Erfassen Sie die gewählte Architekturentscheidung, Begründung, Alternativen, Abwägungen, den Status und die Konsequenzen in einem ADR.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Umsetzen\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Überführen Sie die Entscheidung in Code, Infrastruktur, Konfiguration und Betriebsverhalten.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Validieren\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Messen Sie das reale System an der ursprünglichen Anforderung. Das Testergebnis validiert die NFR; das ADR allein tut dies nicht.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Wo das einfache Beispiel endet\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Reale Systeme haben selten nur eine Anforderung und eine Entscheidung. Leistung kann gegen Kosten, Konsistenz, Operabilität, Sicherheit, Wartbarkeit, Energieverbrauch oder Lieferrisiko abgewogen werden. Das nützliche Modell ist daher ein Rückverfolgbarkeitsgraph, keine Eins-zu-eins-Zuordnung.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-26\">NFRs und ADRs haben üblicherweise eine Viele-zu-viele-Beziehung\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Warum die Beziehung nicht eins zu eins ist\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Anforderungsseite\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Entscheidungsseite\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Validierungsseite\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Eine NFR → viele ADRs\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A broad quality target can constrain several architectural boundaries\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Several coordinated decisions may be required\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Evidence may need multiple tests or measurements\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Viele NFRs → ein ADR\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Several quality and constraint drivers can point at the same design problem\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">One decision may balance several drivers\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Each requirement still needs its own acceptance evidence\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">ADR ohne klassische NFR\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The choice can still be architecturally significant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Validate against the actual driver, not an invented NFR\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Anforderung stabil, ADR ändert sich\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The target can remain unchanged\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A better or necessary implementation choice can supersede the old decision\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The new architecture must still be checked against the same target\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-30\">Eine Technologieentscheidung ist nicht automatisch eine Anforderung\u003C\u002Fh2>\n\u003Cp>Ein wiederkehrender Architekturfehler besteht darin, eine bevorzugte Technologie in die Anforderungsebene zu schreiben und das daraus resultierende Design dann als unvermeidlich zu behandeln.\u003C\u002Fp>\n\u003Cp>„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.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Aussage\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Klassifikation\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Grund\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alle mandantenbezogenen Lesezugriffe müssen die Mandantentrennung durchsetzen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Anforderung \u002F Sicherheitseigenschaft\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Beschreibt eine Eigenschaft, die gelten muss\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Row Level Security von PostgreSQL für ausgewählte mandantenbezogene Tabellen verwenden\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Architekturentscheidung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wählt einen Mechanismus, der dazu beitragen soll, die Isolationsanforderung zu erfüllen\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Das Bereitstellungsziel muss in einer genehmigten, in der EU betriebenen Umgebung laufen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Randbedingung \u002F NFR-ähnliche Betriebsbedingung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Schränkt ein, wo das System betrieben werden darf\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Anbieter X in Region Y verwenden\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Architektur- \u002F Bereitstellungsentscheidung, sofern nicht extern vorgeschrieben\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wählt eine bestimmte Lösung innerhalb der zulässigen Grenze\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">95. Perzentil der API-Latenz ≤ 300 ms unter Last W\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qualitätsanforderung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Definiert messbares Leistungsverhalten\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Einen Cache für Endpunkt X einführen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Architekturentscheidung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wählt eine Taktik, die das gemessene Verhalten verbessern soll\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-34\">Ein ADR ist kein Nachweis, dass eine NFR erfüllt wurde\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Absicht nicht mit Nachweis verwechseln\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>ADR:\u003C\u002Fstrong> „Wir haben Design X gewählt, weil erwartet wird, dass es Anforderung R unter Annahmen A erfüllt.“\u003Cbr>\u003Cstrong>Validierung:\u003C\u002Fstrong> „Gemessene oder analysierte Evidenz E zeigt, ob das implementierte System R tatsächlich erfüllt.“\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-38\">Wann wird eine NFR architektonisch bedeutsam?\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>Die SEI-Literatur verwendet das Konzept der \u003Cstrong>architektonisch bedeutsamen Anforderungen\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Test auf architektonische Bedeutsamkeit\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Fragen, ob die Anforderung die Struktur verändert\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Würden unterschiedliche Werte unterschiedliche Komponenten, Grenzen, Datenpfade oder Bereitstellungstopologien erzwingen?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Fragen, ob sie wesentliche Technologieentscheidungen einschränkt\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Schließt sie ansonsten tragfähige Implementierungsoptionen aus?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Fragen, ob sie querschnittliches Verhalten erzeugt\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Betrifft sie viele Komponenten, Teams, Schnittstellen oder Lebenszyklusphasen?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Fragen, ob sie einen schwierigen Trade-off erzeugt\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Beeinflusst die Verbesserung dieser Eigenschaft wesentlich eine andere Qualität, Kosten, Zeitplan, Komplexität oder Risiko?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Fragen, ob ein Fehlschlag teuer ist\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Würde das Verfehlen der Anforderung wesentliche betriebliche, sicherheitsbezogene, regulatorische, finanzielle oder produktbezogene Auswirkungen haben?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Entscheidungen nur dort festhalten, wo die Begründung es wert ist, bewahrt zu werden\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Erstellen Sie nicht für jede lokale Codierungsentscheidung ADRs; bewahren Sie architektonisch bedeutsame Entscheidungen und ihre Begründung.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-42\">Ein stärkeres Architekturmodell: Anforderung → Entscheidung → Implementierung → Validierung\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Architektur-Rückverfolgbarkeitskette\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Bedarf \u002F Geschäftsziel\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Warum die Qualität oder Einschränkung wichtig ist.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Anforderung \u002F NFR\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Was das System erreichen oder respektieren muss.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Architekturtreiber\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Welche Anforderungen bedeutsam genug sind, um das Design zu prägen.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Optionen\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Plausible Wege, den Treiber zu adressieren.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">ADR\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Die gewählte Option, Begründung, Alternativen, Trade-offs und Konsequenzen.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Implementierung\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Code, Datenmodell, Infrastruktur, Schnittstellen und operative Mechanismen, die die Entscheidung realisieren.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Validierungsnachweis\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Tests, Messungen, Analysen oder Audits, die zeigen, ob die ursprüngliche Anforderung tatsächlich erfüllt ist.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">Änderung \u002F Ablösung\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Neue Evidenz oder geänderte Anforderungen können ein neues ADR auslösen, während die historische Begründung erhalten bleibt.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-45\">Implementierungsnachweis: Wie ich Anforderungen und Entscheidungen in SenseFlow trenne\u003C\u002Fh2>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Ursprünglicher Implementierungs- \u002F Projektnachweis\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Der folgende Abschnitt beschreibt meine eigene SenseFlow-Projektstruktur. Er ist ein Implementierungsnachweis für die Trennung in diesem Artikel, keine Behauptung, dass jedes Team dasselbe Dokumentationsmodell verwenden muss.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>Für bedeutsame SenseFlow-Entscheidungen sind die erfassten Felder \u003Cstrong>Entscheidung, Grund, Alternativen, Trade-offs, Status und Datum \u002F Version\u003C\u002Fstrong>. Wesentliche Architektur- und Produktentscheidungen sollen historisch nachvollziehbar bleiben, anstatt überschrieben zu werden, wenn sich das Projekt weiterentwickelt.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">SenseFlow-Ebene\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Was sie enthält\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Rolle bei der ADR\u002FNFR-Trennung\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Produkt- \u002F Anforderungsstruktur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Produktziel, Fähigkeit, Epic, User Story, Abnahmekriterien, technische Aufgaben; Anforderungen können NFRs und Validierungsmethode enthalten\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Bewahrt, was erreicht werden muss und wie der Erfolg geprüft wird\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Entscheidungsintegrität\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Entscheidung, Grund, Alternativen, Trade-offs, Status, Datum\u002FVersion\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Bewahrt, warum eine architektonisch bedeutsame Wahl maßgeblich wurde\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Confluence\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Anforderungen, Architektur, Forschung, Entscheidungsaufzeichnungen, Risiken, Roadmap und unterstützende Quellen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Pflegt die konzeptionelle und historische Source of Truth\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jira\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Initiativen\u002FZiele, Epics, Stories, Aufgaben und Lieferstatus\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Führt genehmigte Arbeit aus, ohne zur konzeptionellen Source of Truth zu werden\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Änderungsmanagement\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Aktueller Zustand → neue Evidenz → vorgeschlagene Änderung → Auswirkung → Entscheidung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ermöglicht Entscheidungen sich weiterzuentwickeln, ohne die Begründungsspur zu löschen\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">End-to-End-Rückverfolgbarkeit\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Problem → Bedarf → Wert → Produktziel → Anforderung → Implementierung → Validierung\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Hält die Entscheidungsdokumentation mit dem tatsächlichen Produkt- und Evidenzlebenszyklus verbunden\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Was diese Implementierung zeigt\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Eine Anforderung und eine Entscheidung können eng zusammenleben, ohne in einem Datensatz zusammengefasst zu werden. Die Anforderung bleibt das Ziel; die Entscheidung bleibt die Begründungshistorie; die Lieferarbeit implementiert die Entscheidung; die Validierung führt zum Ziel zurück.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-52\">Unternehmensprojektkontext: Anforderungen sollten Architekturentscheidungen vorausgehen\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-55\">Häufige Fehlermuster, wenn ADRs und NFRs vermischt werden\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Fehlermuster\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Was passiert\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Konsequenz\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Technologie als Anforderung getarnt\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Eine bevorzugte Lösung wird als „muss X verwenden“ geschrieben, ohne den zugrunde liegenden Bedarf festzustellen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alternativen werden nie bewertet und die Architektur wird vorzeitig fixiert\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NFR nur in einem ADR versteckt\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Die Entscheidung erwähnt ein Leistungs-\u002FSicherheitsziel, das in der Anforderungsbasis fehlt\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Das Ziel ist schwer unabhängig zu validieren, zu priorisieren oder zu verwalten\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ADR als Beweis behandelt\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Es wird angenommen, dass eine dokumentierte Wahl bedeutet, dass die Anforderung erfüllt ist\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Architektur-Absicht ersetzt Messung oder Verifikation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Vage NFR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wörter wie schnell, skalierbar, sicher oder wartbar haben keinen messbaren Umfang\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Verschiedene Stakeholder können glauben, dass dieselbe Anforderung unterschiedliche Dinge bedeutet\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Keine Alternativen dokumentiert\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Das Team dokumentiert nur die ausgewählte Technologie\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Zukünftige Maintainer können nicht rekonstruieren, warum eine andere Option abgelehnt wurde\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Kein Ablösemodell\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alte ADRs werden bearbeitet oder gelöscht, wenn sich die Architektur ändert\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Historische Begründung verschwindet und veraltete Entscheidungen können mehrdeutig bleiben\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jedes Implementierungsdetail wird ein ADR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Das Repository füllt sich mit Einträgen von geringem Wert\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Wichtige Architekturentscheidungen werden schwer auffindbar\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Backlog wird zur Architektur-SoT\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jira-Aufgaben werden als einzige Erklärung des Systems behandelt\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Der Lieferstatus bleibt erhalten, aber architektonische Begründung und Qualitätstreiber gehen verloren\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-57\">Das ADR–NFR-Entscheidungsframework\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">ADR–NFR-Klassifizierungstest\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Ist dies eine erforderliche Eigenschaft oder externe Einschränkung?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Wenn ja, schreiben oder referenzieren Sie die Anforderung, bevor Sie einen Mechanismus wählen.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Kann es validiert werden?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Definieren Sie den Umfang, die Bedingung, die Metrik, die Akzeptanzregel, die Analysemethode oder andere erforderliche Nachweise.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Ist es architektonisch signifikant?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Stellen Sie fest, ob die Anforderung Struktur, Technologie, Daten, Bereitstellung oder querschnittliche Kompromisse wesentlich prägt.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Gibt es sinnvolle Alternativen?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Vergleichen Sie praktikable Taktiken oder Architekturoptionen, anstatt direkt zu einer bevorzugten Technologie zu springen.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Ist eine Wahl maßgeblich geworden?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Erstellen oder aktualisieren Sie das ADR mit Kontext, Entscheidung, Begründung, Alternativen, Kompromissen, Status und Konsequenzen.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Ist die Entscheidung umgesetzt?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Verfolgen Sie das ADR in Design, Aufgaben, Code, Konfiguration und Betrieb.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. Ist die Anforderung erfüllt?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Sammeln Sie Validierungsnachweise gegen die Anforderung selbst.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">8. Haben sich die Bedingungen geändert?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Bewerten Sie die Anforderung neu und lösen Sie bei Bedarf das ADR ab, ohne die Historie zu löschen.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-60\">Was ADR und NFR nicht sind\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Häufige Kategorienfehler\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Konzept\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Es ist nicht\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Grund\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">NFR \u002F Qualitätsanforderung\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A required quality, constraint or operating condition\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A technology shopping list\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Requirements should preserve the need independently from one implementation when possible\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">ADR\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A record of an architecturally significant decision\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The complete architecture description\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Architecture also needs views, interfaces, models, responsibilities and other documentation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Validierungsnachweis\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Evidence that checks whether a requirement is satisfied\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The ADR itself\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Documented intent is different from measured or analyzed system behavior\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Backlog-Eintrag\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Actionable delivery work\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A durable substitute for architecture rationale\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Task state answers what is being delivered, not necessarily why the architecture exists\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Einschränkung\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A condition that restricts the solution space\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Always an internally chosen architecture decision\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Some constraints come from regulation, contracts, existing platforms or organizational boundaries\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-62\">Was würde diese Antwort ändern?\u003C\u002Fh2>\n\u003Cp>Die Terminologie kann sich weiterentwickeln. ISO\u002FIEC\u002FIEEE 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-66\">Einschränkungen\u003C\u002Fh2>\n\u003Cp>Dieser Artikel verwendet \u003Cstrong>NFR\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-70\">Fazit\u003C\u002Fh2>\n\u003Cp>ADR und NFR gehören zu unterschiedlichen Schichten der Architekturarbeit. \u003Cstrong>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.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>Die stärkste Kette ist daher nicht „NFR → ADR → fertig“. Sie ist \u003Cstrong>Bedürfnis → Anforderung → architektonische Treiber → Optionen → Entscheidung → Umsetzung → Validierung → Änderung\u003C\u002Fstrong>. Diese Kette verwandelt Architekturdokumentation von statischem Papierkram in eine überprüfbare Aufzeichnung darüber, warum das System die Form hat, die es hat.\u003C\u002Fp>\n\u003Ch2 id=\"section-74\">FAQ\u003C\u002Fh2>\n\u003Csection class=\"editorjs-faq my-6 rounded-xl border border-gray-200 p-5 dark:border-gray-700\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">ADR vs. NFR\u003C\u002Fh3>\u003Cdiv id=\"faq1\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Ist ein ADR eine nicht-funktionale Anforderung?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">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.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq2\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Sollte jede NFR ein ADR haben?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">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.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq3\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Kann „PostgreSQL verwenden“ eine NFR sein?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">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.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq4\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Beweist ein ADR, dass eine Leistungs- oder Sicherheitsanforderung erfüllt ist?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Nein. Ein ADR dokumentiert Absicht und Begründung. Die Anforderung wird durch geeignete Nachweise wie Tests, Messungen, Analysen, Audits oder betriebliche Telemetrie validiert.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq5\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Was sollte ein ADR enthalten?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">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.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq6\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Was macht eine NFR architektonisch bedeutsam?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">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.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq7\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Sollte ein altes ADR gelöscht werden, wenn sich die Architektur ändert?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Normalerweise nein. Eine Ersatzentscheidung sollte den alten Datensatz in der Regel ablösen, damit die historische Begründung nachvollziehbar bleibt.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-76\">Glossar\u003C\u002Fh2>\n\u003Csection class=\"editorjs-glossary my-6 rounded-xl border border-gray-200 dark:border-gray-700 p-5\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Zentrale Architekturbegriffe\u003C\u002Fh3>\u003Cdl>\u003Cdiv id=\"nfr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">NFR\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Nicht-funktionale Anforderung: praktische Kurzbezeichnung für eine geforderte Systemqualität, Einschränkung oder Betriebsbedingung; die genaue Terminologie variiert je nach Methode und Standard.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"quality-attribute-requirement\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Qualitätsattributanforderung\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Eine Anforderung, die eine Qualitätseigenschaft beschreibt, die das System unter definierten Bedingungen aufweisen soll, wie Leistung, Verfügbarkeit, Sicherheit, Zuverlässigkeit oder Änderbarkeit.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"adr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Architecture Decision Record (ADR)\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Eine dauerhafte Aufzeichnung einer architektonisch bedeutsamen Entscheidung und genügend Kontext, um zu verstehen, warum die Wahl getroffen wurde und welche Konsequenzen daraus folgen.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"asr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Architektonisch bedeutsame Anforderung (ASR)\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Eine Anforderung mit ausreichend weitreichender architektonischer Wirkung, dass sie das Systemdesign wesentlich beeinflusst.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"constraint\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Einschränkung\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Eine Bedingung, die den Lösungsraum einschränkt, einschließlich externer Richtlinien, Vorschriften, Plattform-, Kompatibilitäts-, vertraglicher oder organisatorischer Grenzen.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"trade-off\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Abwägung\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Eine Designbeziehung, bei der die Verbesserung eines Ziels, einer Eigenschaft oder einer Kostendimension eine andere verschlechtern kann.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"validation\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Validierung\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Nachweise erzeugende Arbeit, mit der festgestellt wird, ob das implementierte System die angegebene Anforderung unter den relevanten Bedingungen erfüllt.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"superseded-adr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Abgelöstes ADR\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Ein historischer Entscheidungsdatensatz, der durch eine neuere maßgebliche Entscheidung ersetzt wurde, aber für die Nachvollziehbarkeit verfügbar bleibt.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-78\">Primärquellen und Umsetzungsnachweise\u003C\u002Fh2>\n\u003Cp>Dieser Artikel trennt aktuelle Standards von Projektumsetzungsnachweisen. ISO\u002FIEC\u002FIEEE 29148:2018 ist mit Stand vom 8. Oktober 2026 weiterhin aktuell, aber zur Überarbeitung vorgesehen; ISO\u002FIEC 25010:2023 und ISO\u002FIEC\u002FIEEE 42010:2022 sind aktuelle veröffentlichte Ausgaben. SenseFlow ist ein originärer Projektnachweis für das oben beschriebene Modell der Nachvollziehbarkeit und Entscheidungsintegrität.\u003C\u002Fp>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC\u002FIEEE 29148:2018 — Requirements Engineering\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">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.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC\u002FIEEE DIS 29148 — Requirements Engineering\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Draft International Standard, der sich derzeit in Entwicklung befindet und ISO\u002FIEC\u002FIEEE 29148:2018 ersetzen soll.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC 25010:2023 — Produktqualitätsmodell\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Aktuelles Produktqualitätsmodell mit neun Qualitätsmerkmalen, das zur Spezifikation, Messung und Bewertung der Qualität von IKT- und Softwareprodukten verwendet wird.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC\u002FIEEE 42010:2022 — Architekturbeschreibung\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">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.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Michael Nygard — Documenting Architecture Decisions\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">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.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — Relating Business Goals to Architecturally Significant Requirements\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">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.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — Defining Non-Functional System Qualities\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">SEI-Überblick, der nicht-funktionale\u002FQualitätsattribute mit Architektur, Szenarien, Abwägungen und objektiver Systembewertung verbindet.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — Attribute-Driven Design Method Collection\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">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.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — Views and Beyond Collection\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Leitfaden zur Architekturdokumentation, der relevante Sichten und die Aufzeichnung notwendiger Designentscheidungen als Teil der Architekturarbeit betont.\u003C\u002Fp>\u003C\u002Fa>",{"time":211,"blocks":212,"version":1030},1791476020976,[213,218,225,231,238,242,246,250,254,298,302,306,310,314,342,348,352,356,360,364,400,404,408,412,437,443,447,451,455,496,500,504,508,539,543,547,551,556,560,564,568,591,595,599,628,632,637,641,645,649,681,686,690,694,698,702,742,746,750,779,783,827,831,835,839,843,847,851,855,859,863,867,871,875,879,912,916,948,952,956,966,974,982,990,998,1006,1014,1022],{"id":214,"data":215,"type":217},"intro",{"text":216},"Eine \u003Cstrong>nicht-funktionale Anforderung (NFR)\u003C\u002Fstrong> beschreibt eine Qualität, eine Einschränkung oder eine Betriebsbedingung, die das System erfüllen soll. Ein \u003Cstrong>Architecture Decision Record (ADR)\u003C\u002Fstrong> 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.","paragraph",{"id":219,"data":220,"type":224},"direct",{"body":221,"title":222,"variant":223},"\u003Cstrong>NFR = erforderliche Systemqualität oder Einschränkung. ADR = dokumentierte Architekturentscheidung.\u003C\u002Fstrong> Ein Latenzziel, ein Verfügbarkeitsziel, eine Isolationsregel, eine Bereitstellungseinschränkung oder eine Wartbarkeitsanforderung kann die Architektur beeinflussen. Ein ADR dokumentiert dann eine bedeutsame Entscheidung, die getroffen wurde, um einen oder mehrere solcher Treiber zu adressieren. Der ADR ersetzt nicht die Anforderung, und die Existenz eines ADR beweist nicht, dass die Anforderung erfüllt wurde.","Direkte Antwort","info","callout",{"id":226,"data":227,"type":224},"version-note",{"body":228,"title":229,"variant":230},"Der Begriff \u003Cstrong>NFR\u003C\u002Fstrong> ist weit verbreitet, aber nicht vollständig standardisiert. Dieser Artikel verwendet ihn als praktische Kurzform für Qualitätsanforderungen und relevante Einschränkungen. Aktuelle Standards wurden am \u003Cstrong>8. Oktober 2026\u003C\u002Fstrong> erneut geprüft: ISO\u002FIEC\u002FIEEE 29148:2018 ist weiterhin aktuell, wird jedoch überarbeitet; ISO\u002FIEC 25010:2023 und ISO\u002FIEC\u002FIEEE 42010:2022 sind die hier zitierten aktuellen veröffentlichten Ausgaben.","Hinweis zu Terminologie und Standards","note",{"id":232,"data":233,"type":237},"toc",{"title":234,"maxLevel":235,"minLevel":236},"Inhalt",3,2,"tableOfContents",{"id":239,"data":240,"type":41},"h-meaning",{"text":241,"level":236},"Was ist der Unterschied zwischen einer NFR und einem ADR?",{"id":243,"data":244,"type":217},"p-meaning-1",{"text":245},"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.",{"id":247,"data":248,"type":217},"p-meaning-2",{"text":249},"Zum Beispiel ist \u003Cstrong>„Die API muss 95 % der Leseanfragen innerhalb von 300 ms unter der vereinbarten Referenzlast zurückgeben“\u003C\u002Fstrong> eine Qualitätsanforderung. \u003Cstrong>„Verwenden Sie einen Read-Through-Cache für diese Arbeitslast, weil der gemessene reine Datenbankpfad das Latenzziel nicht ohne unakzeptable Kosten erreichen kann“\u003C\u002Fstrong> ist eine Architekturentscheidung.",{"id":251,"data":252,"type":217},"p-meaning-3",{"text":253},"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.",{"id":255,"data":256,"type":297},"basic-difference",{"rows":257,"title":288,"layout":289,"columns":290},[258,264,270,276,282],{"id":259,"label":260,"values":261},"question","Primäre Frage",{"adr":262,"nfr":263},"What architecturally significant choice did we make, and why?","What quality, constraint, or operating condition must the system satisfy?",{"id":265,"label":266,"values":267},"content","Typischer Inhalt",{"adr":268,"nfr":269},"Context, decision, rationale, alternatives, trade-offs, status and consequences","Measurable target, scope, condition, constraint, acceptance or validation rule",{"id":271,"label":272,"values":273},"lifecycle","Rolle im Lebenszyklus",{"adr":274,"nfr":275},"A historical record of a significant decision","A requirement to design for and validate",{"id":277,"label":278,"values":279},"evidence","Was beweist sie?",{"adr":280,"nfr":281},"The record proves what was decided, not that the resulting system meets the requirement","Measurement, test, analysis, inspection, audit or other validation evidence",{"id":283,"label":284,"values":285},"change","Wann ändert sie sich",{"adr":286,"nfr":287},"When the decision is replaced, rejected, deprecated, or superseded","When stakeholder need, operating conditions, policy or quality target changes","NFR und ADR beantworten unterschiedliche Fragen","table",[291,294],{"id":292,"label":293},"nfr","NFR \u002F Qualitätsanforderung",{"id":295,"label":296},"adr","ADR \u002F Architekturentscheidung","comparison",{"id":299,"data":300,"type":41},"h-nfr",{"text":301,"level":236},"Was ist eine NFR in präzisen architektonischen Begriffen?",{"id":303,"data":304,"type":217},"p-nfr-1",{"text":305},"„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 \u003Cstrong>funktionalem Verhalten\u003C\u002Fstrong>, \u003Cstrong>Qualitätsanforderungen\u003C\u002Fstrong> und \u003Cstrong>Einschränkungen\u003C\u002Fstrong>.",{"id":307,"data":308,"type":217},"p-nfr-2",{"text":309},"ISO\u002FIEC 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.",{"id":311,"data":312,"type":217},"p-nfr-3",{"text":313},"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.",{"id":315,"data":316,"type":289},"nfr-examples",{"content":317,"stretched":42,"withHeadings":13},[318,322,326,330,334,338],[319,320,321],"Schwache Aussage","Nützlichere Anforderungsform","Warum der Unterschied wichtig ist",[323,324,325],"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",[327,328,329],"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",[331,332,333],"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",[335,336,337],"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",[339,340,341],"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",{"id":343,"data":344,"type":224},"nfr-rule",{"body":345,"title":346,"variant":347},"Wenn „Kubernetes verwenden“, „PostgreSQL verwenden“, „Microservices verwenden“ oder „Vektorsuche verwenden“ als Anforderung erscheint, fragen Sie, ob es sich wirklich um eine externe Einschränkung handelt oder ob die Lösung aufgeschrieben wurde, bevor der zugrunde liegende Qualitätsbedarf explizit gemacht wurde.","Eine Anforderung sollte den Bedarf vor dem Mechanismus beschreiben","success",{"id":349,"data":350,"type":41},"h-adr",{"text":351,"level":236},"Was ist ein Architecture Decision Record?",{"id":353,"data":354,"type":217},"p-adr-1",{"text":355},"Ein Architecture Decision Record ist eine kompakte Aufzeichnung einer wichtigen Architekturentscheidung. Michael Nygards ursprüngliche ADR-Formulierung betont den \u003Cstrong>Kontext\u003C\u002Fstrong>, die \u003Cstrong>Entscheidung\u003C\u002Fstrong>, ihren \u003Cstrong>Status\u003C\u002Fstrong> und die daraus resultierenden \u003Cstrong>Konsequenzen\u003C\u002Fstrong>.",{"id":357,"data":358,"type":217},"p-adr-2",{"text":359},"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.",{"id":361,"data":362,"type":217},"p-adr-3",{"text":363},"ISO\u002FIEC\u002FIEEE 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.",{"id":365,"data":366,"type":289},"adr-anatomy",{"content":367,"stretched":42,"withHeadings":13},[368,372,376,380,384,388,392,396],[369,370,371],"ADR-Feld","Was es bewahrt","Warum es wichtig ist",[373,374,375],"Kontext","Das Problem, die Kräfte, Anforderungen, Annahmen und das Umfeld der Entscheidung","Zukünftige Leser können rekonstruieren, warum eine Entscheidung notwendig war",[377,378,379],"Entscheidung","Die Entscheidung, die verbindlich wurde","Trennt die gewählte Option von der Diskussion",[381,382,383],"Status","Vorgeschlagen, akzeptiert, abgelehnt, veraltet, ersetzt oder ein anderer kontrollierter Zustand","Verhindert, dass alte Entscheidungen stillschweigend aktiv bleiben",[385,386,387],"Alternativen","Andere in Betracht gezogene gangbare Optionen","Zeigt, dass die gewählte Lösung nicht die einzig denkbare war",[389,390,391],"Begründung \u002F Abwägungen","Warum die Option gewählt wurde und was sie aufgibt","Macht die Architekturbegründung nachprüfbar",[393,394,395],"Konsequenzen","Erwartete positive und negative Auswirkungen, Folgearbeiten, Risiken","Verbindet eine lokale Entscheidung mit der Systemwirkung",[397,398,399],"Datum \u002F Version","Wann die Entscheidung gültig wurde","Unterstützt die historische Nachverfolgbarkeit und spätere Ersetzung",{"id":401,"data":402,"type":41},"h-simple-example",{"text":403,"level":236},"Das einfachste Beispiel: Latenzanforderung → Architekturentscheidung",{"id":405,"data":406,"type":217},"p-simple-1",{"text":407},"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.",{"id":409,"data":410,"type":217},"p-simple-2",{"text":411},"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.",{"id":413,"data":414,"type":436},"simple-flow",{"steps":415,"title":434,"orientation":435},[416,419,422,425,428,431],{"label":417,"description":418},"1. Anforderung formulieren","Definieren Sie das Qualitätsziel, die Last, den Geltungsbereich, den Schwellenwert und die Validierungsmethode.",{"label":420,"description":421},"2. Architektonische Bedeutung erkennen","Stellen Sie fest, ob die Anforderung Struktur, Technologie, Bereitstellung, Datenfluss oder Betriebsmodell wesentlich beeinflusst.",{"label":423,"description":424},"3. Optionen bewerten","Vergleichen Sie Alternativen wie Indexierung, Caching, Denormalisierung, asynchrone Verarbeitung, Partitionierung oder eine andere Abfragearchitektur.",{"label":426,"description":427},"4. Entscheidung dokumentieren","Erfassen Sie die gewählte Architekturentscheidung, Begründung, Alternativen, Abwägungen, den Status und die Konsequenzen in einem ADR.",{"label":429,"description":430},"5. Umsetzen","Überführen Sie die Entscheidung in Code, Infrastruktur, Konfiguration und Betriebsverhalten.",{"label":432,"description":433},"6. Validieren","Messen Sie das reale System an der ursprünglichen Anforderung. Das Testergebnis validiert die NFR; das ADR allein tut dies nicht.","Von der Anforderung zum Nachweis","auto","processFlow",{"id":438,"data":439,"type":224},"simple-stop",{"body":440,"title":441,"variant":442},"Reale Systeme haben selten nur eine Anforderung und eine Entscheidung. Leistung kann gegen Kosten, Konsistenz, Operabilität, Sicherheit, Wartbarkeit, Energieverbrauch oder Lieferrisiko abgewogen werden. Das nützliche Modell ist daher ein Rückverfolgbarkeitsgraph, keine Eins-zu-eins-Zuordnung.","Wo das einfache Beispiel endet","warning",{"id":444,"data":445,"type":41},"h-many-many",{"text":446,"level":236},"NFRs und ADRs haben üblicherweise eine Viele-zu-viele-Beziehung",{"id":448,"data":449,"type":217},"p-many-1",{"text":450},"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.",{"id":452,"data":453,"type":217},"p-many-2",{"text":454},"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.",{"id":456,"data":457,"type":297},"relationship-map",{"rows":458,"title":487,"layout":289,"columns":488},[459,466,473,480],{"id":460,"label":461,"values":462},"one-many","Eine NFR → viele ADRs",{"adr":463,"nfr":464,"validation":465},"Several coordinated decisions may be required","A broad quality target can constrain several architectural boundaries","Evidence may need multiple tests or measurements",{"id":467,"label":468,"values":469},"many-one","Viele NFRs → ein ADR",{"adr":470,"nfr":471,"validation":472},"One decision may balance several drivers","Several quality and constraint drivers can point at the same design problem","Each requirement still needs its own acceptance evidence",{"id":474,"label":475,"values":476},"non-nfr","ADR ohne klassische NFR",{"adr":477,"nfr":478,"validation":479},"The choice can still be architecturally significant","The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition","Validate against the actual driver, not an invented NFR",{"id":481,"label":482,"values":483},"supersession","Anforderung stabil, ADR ändert sich",{"adr":484,"nfr":485,"validation":486},"A better or necessary implementation choice can supersede the old decision","The target can remain unchanged","The new architecture must still be checked against the same target","Warum die Beziehung nicht eins zu eins ist",[489,491,493],{"id":292,"label":490},"Anforderungsseite",{"id":295,"label":492},"Entscheidungsseite",{"id":494,"label":495},"validation","Validierungsseite",{"id":497,"data":498,"type":41},"h-technology",{"text":499,"level":236},"Eine Technologieentscheidung ist nicht automatisch eine Anforderung",{"id":501,"data":502,"type":217},"p-tech-1",{"text":503},"Ein wiederkehrender Architekturfehler besteht darin, eine bevorzugte Technologie in die Anforderungsebene zu schreiben und das daraus resultierende Design dann als unvermeidlich zu behandeln.",{"id":505,"data":506,"type":217},"p-tech-2",{"text":507},"„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.",{"id":509,"data":510,"type":289},"tech-table",{"content":511,"stretched":42,"withHeadings":13},[512,516,520,524,528,532,536],[513,514,515],"Aussage","Klassifikation","Grund",[517,518,519],"Alle mandantenbezogenen Lesezugriffe müssen die Mandantentrennung durchsetzen","Anforderung \u002F Sicherheitseigenschaft","Beschreibt eine Eigenschaft, die gelten muss",[521,522,523],"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",[525,526,527],"Das Bereitstellungsziel muss in einer genehmigten, in der EU betriebenen Umgebung laufen","Randbedingung \u002F NFR-ähnliche Betriebsbedingung","Schränkt ein, wo das System betrieben werden darf",[529,530,531],"Anbieter X in Region Y verwenden","Architektur- \u002F Bereitstellungsentscheidung, sofern nicht extern vorgeschrieben","Wählt eine bestimmte Lösung innerhalb der zulässigen Grenze",[533,534,535],"95. Perzentil der API-Latenz ≤ 300 ms unter Last W","Qualitätsanforderung","Definiert messbares Leistungsverhalten",[537,522,538],"Einen Cache für Endpunkt X einführen","Wählt eine Taktik, die das gemessene Verhalten verbessern soll",{"id":540,"data":541,"type":41},"h-adr-proof",{"text":542,"level":236},"Ein ADR ist kein Nachweis, dass eine NFR erfüllt wurde",{"id":544,"data":545,"type":217},"p-proof-1",{"text":546},"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.",{"id":548,"data":549,"type":217},"p-proof-2",{"text":550},"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.",{"id":552,"data":553,"type":224},"proof-rule",{"body":554,"title":555,"variant":442},"\u003Cstrong>ADR:\u003C\u002Fstrong> „Wir haben Design X gewählt, weil erwartet wird, dass es Anforderung R unter Annahmen A erfüllt.“\u003Cbr>\u003Cstrong>Validierung:\u003C\u002Fstrong> „Gemessene oder analysierte Evidenz E zeigt, ob das implementierte System R tatsächlich erfüllt.“","Absicht nicht mit Nachweis verwechseln",{"id":557,"data":558,"type":41},"h-asr",{"text":559,"level":236},"Wann wird eine NFR architektonisch bedeutsam?",{"id":561,"data":562,"type":217},"p-asr-1",{"text":563},"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.",{"id":565,"data":566,"type":217},"p-asr-2",{"text":567},"Die SEI-Literatur verwendet das Konzept der \u003Cstrong>architektonisch bedeutsamen Anforderungen\u003C\u002Fstrong> 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.",{"id":569,"data":570,"type":436},"asr-test",{"steps":571,"title":590,"orientation":435},[572,575,578,581,584,587],{"label":573,"description":574},"1. Fragen, ob die Anforderung die Struktur verändert","Würden unterschiedliche Werte unterschiedliche Komponenten, Grenzen, Datenpfade oder Bereitstellungstopologien erzwingen?",{"label":576,"description":577},"2. Fragen, ob sie wesentliche Technologieentscheidungen einschränkt","Schließt sie ansonsten tragfähige Implementierungsoptionen aus?",{"label":579,"description":580},"3. Fragen, ob sie querschnittliches Verhalten erzeugt","Betrifft sie viele Komponenten, Teams, Schnittstellen oder Lebenszyklusphasen?",{"label":582,"description":583},"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?",{"label":585,"description":586},"5. Fragen, ob ein Fehlschlag teuer ist","Würde das Verfehlen der Anforderung wesentliche betriebliche, sicherheitsbezogene, regulatorische, finanzielle oder produktbezogene Auswirkungen haben?",{"label":588,"description":589},"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.","Test auf architektonische Bedeutsamkeit",{"id":592,"data":593,"type":41},"h-traceability",{"text":594,"level":236},"Ein stärkeres Architekturmodell: Anforderung → Entscheidung → Implementierung → Validierung",{"id":596,"data":597,"type":217},"p-trace-1",{"text":598},"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.",{"id":600,"data":601,"type":436},"trace-flow",{"steps":602,"title":627,"orientation":435},[603,606,609,612,615,618,621,624],{"label":604,"description":605},"Bedarf \u002F Geschäftsziel","Warum die Qualität oder Einschränkung wichtig ist.",{"label":607,"description":608},"Anforderung \u002F NFR","Was das System erreichen oder respektieren muss.",{"label":610,"description":611},"Architekturtreiber","Welche Anforderungen bedeutsam genug sind, um das Design zu prägen.",{"label":613,"description":614},"Optionen","Plausible Wege, den Treiber zu adressieren.",{"label":616,"description":617},"ADR","Die gewählte Option, Begründung, Alternativen, Trade-offs und Konsequenzen.",{"label":619,"description":620},"Implementierung","Code, Datenmodell, Infrastruktur, Schnittstellen und operative Mechanismen, die die Entscheidung realisieren.",{"label":622,"description":623},"Validierungsnachweis","Tests, Messungen, Analysen oder Audits, die zeigen, ob die ursprüngliche Anforderung tatsächlich erfüllt ist.",{"label":625,"description":626},"Änderung \u002F Ablösung","Neue Evidenz oder geänderte Anforderungen können ein neues ADR auslösen, während die historische Begründung erhalten bleibt.","Architektur-Rückverfolgbarkeitskette",{"id":629,"data":630,"type":41},"h-senseflow",{"text":631,"level":236},"Implementierungsnachweis: Wie ich Anforderungen und Entscheidungen in SenseFlow trenne",{"id":633,"data":634,"type":224},"senseflow-evidence",{"body":635,"title":636,"variant":230},"Der folgende Abschnitt beschreibt meine eigene SenseFlow-Projektstruktur. Er ist ein Implementierungsnachweis für die Trennung in diesem Artikel, keine Behauptung, dass jedes Team dasselbe Dokumentationsmodell verwenden muss.","Ursprünglicher Implementierungs- \u002F Projektnachweis",{"id":638,"data":639,"type":217},"p-sense-1",{"text":640},"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.",{"id":642,"data":643,"type":217},"p-sense-2",{"text":644},"Für bedeutsame SenseFlow-Entscheidungen sind die erfassten Felder \u003Cstrong>Entscheidung, Grund, Alternativen, Trade-offs, Status und Datum \u002F Version\u003C\u002Fstrong>. Wesentliche Architektur- und Produktentscheidungen sollen historisch nachvollziehbar bleiben, anstatt überschrieben zu werden, wenn sich das Projekt weiterentwickelt.",{"id":646,"data":647,"type":217},"p-sense-3",{"text":648},"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.",{"id":650,"data":651,"type":289},"senseflow-table",{"content":652,"stretched":42,"withHeadings":13},[653,657,661,665,669,673,677],[654,655,656],"SenseFlow-Ebene","Was sie enthält","Rolle bei der ADR\u002FNFR-Trennung",[658,659,660],"Produkt- \u002F 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",[662,663,664],"Entscheidungsintegrität","Entscheidung, Grund, Alternativen, Trade-offs, Status, Datum\u002FVersion","Bewahrt, warum eine architektonisch bedeutsame Wahl maßgeblich wurde",[666,667,668],"Confluence","Anforderungen, Architektur, Forschung, Entscheidungsaufzeichnungen, Risiken, Roadmap und unterstützende Quellen","Pflegt die konzeptionelle und historische Source of Truth",[670,671,672],"Jira","Initiativen\u002FZiele, Epics, Stories, Aufgaben und Lieferstatus","Führt genehmigte Arbeit aus, ohne zur konzeptionellen Source of Truth zu werden",[674,675,676],"Änderungsmanagement","Aktueller Zustand → neue Evidenz → vorgeschlagene Änderung → Auswirkung → Entscheidung","Ermöglicht Entscheidungen sich weiterzuentwickeln, ohne die Begründungsspur zu löschen",[678,679,680],"End-to-End-Rückverfolgbarkeit","Problem → Bedarf → Wert → Produktziel → Anforderung → Implementierung → Validierung","Hält die Entscheidungsdokumentation mit dem tatsächlichen Produkt- und Evidenzlebenszyklus verbunden",{"id":682,"data":683,"type":224},"senseflow-lesson",{"body":684,"title":685,"variant":347},"Eine Anforderung und eine Entscheidung können eng zusammenleben, ohne in einem Datensatz zusammengefasst zu werden. Die Anforderung bleibt das Ziel; die Entscheidung bleibt die Begründungshistorie; die Lieferarbeit implementiert die Entscheidung; die Validierung führt zum Ziel zurück.","Was diese Implementierung zeigt",{"id":687,"data":688,"type":41},"h-enterprise",{"text":689,"level":236},"Unternehmensprojektkontext: Anforderungen sollten Architekturentscheidungen vorausgehen",{"id":691,"data":692,"type":217},"p-enterprise-1",{"text":693},"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.",{"id":695,"data":696,"type":217},"p-enterprise-2",{"text":697},"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.",{"id":699,"data":700,"type":41},"h-failures",{"text":701,"level":236},"Häufige Fehlermuster, wenn ADRs und NFRs vermischt werden",{"id":703,"data":704,"type":289},"failure-table",{"content":705,"stretched":42,"withHeadings":13},[706,710,714,718,722,726,730,734,738],[707,708,709],"Fehlermuster","Was passiert","Konsequenz",[711,712,713],"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",[715,716,717],"NFR nur in einem ADR versteckt","Die Entscheidung erwähnt ein Leistungs-\u002FSicherheitsziel, das in der Anforderungsbasis fehlt","Das Ziel ist schwer unabhängig zu validieren, zu priorisieren oder zu verwalten",[719,720,721],"ADR als Beweis behandelt","Es wird angenommen, dass eine dokumentierte Wahl bedeutet, dass die Anforderung erfüllt ist","Architektur-Absicht ersetzt Messung oder Verifikation",[723,724,725],"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",[727,728,729],"Keine Alternativen dokumentiert","Das Team dokumentiert nur die ausgewählte Technologie","Zukünftige Maintainer können nicht rekonstruieren, warum eine andere Option abgelehnt wurde",[731,732,733],"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",[735,736,737],"Jedes Implementierungsdetail wird ein ADR","Das Repository füllt sich mit Einträgen von geringem Wert","Wichtige Architekturentscheidungen werden schwer auffindbar",[739,740,741],"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",{"id":743,"data":744,"type":41},"h-decision-framework",{"text":745,"level":236},"Das ADR–NFR-Entscheidungsframework",{"id":747,"data":748,"type":217},"p-framework-1",{"text":749},"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.",{"id":751,"data":752,"type":436},"decision-flow",{"steps":753,"title":778,"orientation":435},[754,757,760,763,766,769,772,775],{"label":755,"description":756},"1. Ist dies eine erforderliche Eigenschaft oder externe Einschränkung?","Wenn ja, schreiben oder referenzieren Sie die Anforderung, bevor Sie einen Mechanismus wählen.",{"label":758,"description":759},"2. Kann es validiert werden?","Definieren Sie den Umfang, die Bedingung, die Metrik, die Akzeptanzregel, die Analysemethode oder andere erforderliche Nachweise.",{"label":761,"description":762},"3. Ist es architektonisch signifikant?","Stellen Sie fest, ob die Anforderung Struktur, Technologie, Daten, Bereitstellung oder querschnittliche Kompromisse wesentlich prägt.",{"label":764,"description":765},"4. Gibt es sinnvolle Alternativen?","Vergleichen Sie praktikable Taktiken oder Architekturoptionen, anstatt direkt zu einer bevorzugten Technologie zu springen.",{"label":767,"description":768},"5. Ist eine Wahl maßgeblich geworden?","Erstellen oder aktualisieren Sie das ADR mit Kontext, Entscheidung, Begründung, Alternativen, Kompromissen, Status und Konsequenzen.",{"label":770,"description":771},"6. Ist die Entscheidung umgesetzt?","Verfolgen Sie das ADR in Design, Aufgaben, Code, Konfiguration und Betrieb.",{"label":773,"description":774},"7. Ist die Anforderung erfüllt?","Sammeln Sie Validierungsnachweise gegen die Anforderung selbst.",{"label":776,"description":777},"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.","ADR–NFR-Klassifizierungstest",{"id":780,"data":781,"type":41},"h-what-not",{"text":782,"level":236},"Was ADR und NFR nicht sind",{"id":784,"data":785,"type":297},"not-comparison",{"rows":786,"title":817,"layout":289,"columns":818},[787,792,797,803,810],{"id":292,"label":293,"values":788},{"not":789,"why":790,"term":791},"A technology shopping list","Requirements should preserve the need independently from one implementation when possible","A required quality, constraint or operating condition",{"id":295,"label":616,"values":793},{"not":794,"why":795,"term":796},"The complete architecture description","Architecture also needs views, interfaces, models, responsibilities and other documentation","A record of an architecturally significant decision",{"id":798,"label":622,"values":799},"test",{"not":800,"why":801,"term":802},"The ADR itself","Documented intent is different from measured or analyzed system behavior","Evidence that checks whether a requirement is satisfied",{"id":804,"label":805,"values":806},"backlog","Backlog-Eintrag",{"not":807,"why":808,"term":809},"A durable substitute for architecture rationale","Task state answers what is being delivered, not necessarily why the architecture exists","Actionable delivery work",{"id":811,"label":812,"values":813},"constraint","Einschränkung",{"not":814,"why":815,"term":816},"Always an internally chosen architecture decision","Some constraints come from regulation, contracts, existing platforms or organizational boundaries","A condition that restricts the solution space","Häufige Kategorienfehler",[819,822,825],{"id":820,"label":821},"term","Konzept",{"id":823,"label":824},"not","Es ist nicht",{"id":826,"label":515},"why",{"id":828,"data":829,"type":41},"h-change",{"text":830,"level":236},"Was würde diese Antwort ändern?",{"id":832,"data":833,"type":217},"p-change-1",{"text":834},"Die Terminologie kann sich weiterentwickeln. ISO\u002FIEC\u002FIEEE 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.",{"id":836,"data":837,"type":217},"p-change-2",{"text":838},"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.",{"id":840,"data":841,"type":217},"p-change-3",{"text":842},"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.",{"id":844,"data":845,"type":41},"h-limitations",{"text":846,"level":236},"Einschränkungen",{"id":848,"data":849,"type":217},"p-limit-1",{"text":850},"Dieser Artikel verwendet \u003Cstrong>NFR\u003C\u002Fstrong> 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.",{"id":852,"data":853,"type":217},"p-limit-2",{"text":854},"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.",{"id":856,"data":857,"type":217},"p-limit-3",{"text":858},"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.",{"id":860,"data":861,"type":41},"h-conclusion",{"text":862,"level":236},"Fazit",{"id":864,"data":865,"type":217},"p-conclusion-1",{"text":866},"ADR und NFR gehören zu unterschiedlichen Schichten der Architekturarbeit. \u003Cstrong>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.\u003C\u002Fstrong>",{"id":868,"data":869,"type":217},"p-conclusion-2",{"text":870},"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.",{"id":872,"data":873,"type":217},"p-conclusion-3",{"text":874},"Die stärkste Kette ist daher nicht „NFR → ADR → fertig“. Sie ist \u003Cstrong>Bedürfnis → Anforderung → architektonische Treiber → Optionen → Entscheidung → Umsetzung → Validierung → Änderung\u003C\u002Fstrong>. Diese Kette verwandelt Architekturdokumentation von statischem Papierkram in eine überprüfbare Aufzeichnung darüber, warum das System die Form hat, die es hat.",{"id":876,"data":877,"type":41},"h-faq",{"text":878,"level":236},"FAQ",{"id":880,"data":881,"type":880},"faq",{"items":882,"title":911},[883,887,891,895,899,903,907],{"id":884,"answer":885,"question":886},"faq1","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.","Ist ein ADR eine nicht-funktionale Anforderung?",{"id":888,"answer":889,"question":890},"faq2","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.","Sollte jede NFR ein ADR haben?",{"id":892,"answer":893,"question":894},"faq3","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.","Kann „PostgreSQL verwenden“ eine NFR sein?",{"id":896,"answer":897,"question":898},"faq4","Nein. Ein ADR dokumentiert Absicht und Begründung. Die Anforderung wird durch geeignete Nachweise wie Tests, Messungen, Analysen, Audits oder betriebliche Telemetrie validiert.","Beweist ein ADR, dass eine Leistungs- oder Sicherheitsanforderung erfüllt ist?",{"id":900,"answer":901,"question":902},"faq5","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 sollte ein ADR enthalten?",{"id":904,"answer":905,"question":906},"faq6","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.","Was macht eine NFR architektonisch bedeutsam?",{"id":908,"answer":909,"question":910},"faq7","Normalerweise nein. Eine Ersatzentscheidung sollte den alten Datensatz in der Regel ablösen, damit die historische Begründung nachvollziehbar bleibt.","Sollte ein altes ADR gelöscht werden, wenn sich die Architektur ändert?","ADR vs. NFR",{"id":913,"data":914,"type":41},"h-glossary",{"text":915,"level":236},"Glossar",{"id":917,"data":918,"type":917},"glossary",{"title":919,"entries":920},"Zentrale Architekturbegriffe",[921,924,928,931,935,937,941,944],{"term":922,"anchor":292,"definition":923},"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.",{"term":925,"anchor":926,"definition":927},"Qualitätsattributanforderung","quality-attribute-requirement","Eine Anforderung, die eine Qualitätseigenschaft beschreibt, die das System unter definierten Bedingungen aufweisen soll, wie Leistung, Verfügbarkeit, Sicherheit, Zuverlässigkeit oder Änderbarkeit.",{"term":929,"anchor":295,"definition":930},"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.",{"term":932,"anchor":933,"definition":934},"Architektonisch bedeutsame Anforderung (ASR)","asr","Eine Anforderung mit ausreichend weitreichender architektonischer Wirkung, dass sie das Systemdesign wesentlich beeinflusst.",{"term":812,"anchor":811,"definition":936},"Eine Bedingung, die den Lösungsraum einschränkt, einschließlich externer Richtlinien, Vorschriften, Plattform-, Kompatibilitäts-, vertraglicher oder organisatorischer Grenzen.",{"term":938,"anchor":939,"definition":940},"Abwägung","trade-off","Eine Designbeziehung, bei der die Verbesserung eines Ziels, einer Eigenschaft oder einer Kostendimension eine andere verschlechtern kann.",{"term":942,"anchor":494,"definition":943},"Validierung","Nachweise erzeugende Arbeit, mit der festgestellt wird, ob das implementierte System die angegebene Anforderung unter den relevanten Bedingungen erfüllt.",{"term":945,"anchor":946,"definition":947},"Abgelöstes ADR","superseded-adr","Ein historischer Entscheidungsdatensatz, der durch eine neuere maßgebliche Entscheidung ersetzt wurde, aber für die Nachvollziehbarkeit verfügbar bleibt.",{"id":949,"data":950,"type":41},"h-sources",{"text":951,"level":236},"Primärquellen und Umsetzungsnachweise",{"id":953,"data":954,"type":217},"p-sources-note",{"text":955},"Dieser Artikel trennt aktuelle Standards von Projektumsetzungsnachweisen. ISO\u002FIEC\u002FIEEE 29148:2018 ist mit Stand vom 8. Oktober 2026 weiterhin aktuell, aber zur Überarbeitung vorgesehen; ISO\u002FIEC 25010:2023 und ISO\u002FIEC\u002FIEEE 42010:2022 sind aktuelle veröffentlichte Ausgaben. SenseFlow ist ein originärer Projektnachweis für das oben beschriebene Modell der Nachvollziehbarkeit und Entscheidungsintegrität.",{"id":957,"data":958,"type":965},"src-iso-29148",{"link":959,"meta":960},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html",{"image":961,"title":963,"description":964},{"url":962},"","ISO\u002FIEC\u002FIEEE 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.","linkTool",{"id":967,"data":968,"type":965},"src-iso-29148-dis",{"link":969,"meta":970},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html",{"image":971,"title":972,"description":973},{"url":962},"ISO\u002FIEC\u002FIEEE DIS 29148 — Requirements Engineering","Draft International Standard, der sich derzeit in Entwicklung befindet und ISO\u002FIEC\u002FIEEE 29148:2018 ersetzen soll.",{"id":975,"data":976,"type":965},"src-iso-25010",{"link":977,"meta":978},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html",{"image":979,"title":980,"description":981},{"url":962},"ISO\u002FIEC 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.",{"id":983,"data":984,"type":965},"src-iso-42010",{"link":985,"meta":986},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":987,"title":988,"description":989},{"url":962},"ISO\u002FIEC\u002FIEEE 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.",{"id":991,"data":992,"type":965},"src-nygard",{"link":993,"meta":994},"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions",{"image":995,"title":996,"description":997},{"url":962},"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.",{"id":999,"data":1000,"type":965},"src-sei-asr",{"link":1001,"meta":1002},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F",{"image":1003,"title":1004,"description":1005},{"url":962},"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.",{"id":1007,"data":1008,"type":965},"src-sei-nfr",{"link":1009,"meta":1010},"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F",{"image":1011,"title":1012,"description":1013},{"url":962},"SEI — Defining Non-Functional System Qualities","SEI-Überblick, der nicht-funktionale\u002FQualitätsattribute mit Architektur, Szenarien, Abwägungen und objektiver Systembewertung verbindet.",{"id":1015,"data":1016,"type":965},"src-sei-add",{"link":1017,"meta":1018},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F",{"image":1019,"title":1020,"description":1021},{"url":962},"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.",{"id":1023,"data":1024,"type":965},"src-sei-doc",{"link":1025,"meta":1026},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F",{"image":1027,"title":1028,"description":1029},{"url":962},"SEI — Views and Beyond Collection","Leitfaden zur Architekturdokumentation, der relevante Sichten und die Aufzeichnung notwendiger Designentscheidungen als Teil der Architekturarbeit betont.","2.31","ADR vs. NFR erklärt: Erfahren Sie, wie Systemqualitätsanforderungen Architekturentscheidungen beeinflussen, wie ADRs Abwägungen dokumentieren und warum die Validierung getrennt bleibt.","\u002Fuploads\u002F2026\u002F10\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing-1791475921511-6zgen1.webp","adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing-1791475921511-6zgen1","PUBLISHED","2026-10-08T12:11:00.000Z","2026-10-08T16:11:31.560Z","2026-10-08T17:31:47.443Z",{"en":1039,"de":1040,"sr":1041,"es":1042,"fr":1043,"it":1044,"ru":1045,"zh":1046},"\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fde\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fsr\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fes\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Ffr\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fit\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fru\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fzh\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing",[1048,1052,1056,1060,1064],{"id":1049,"name":1050,"slug":1051},72,"Abnahmekriterien","acceptance-criteria",{"id":1053,"name":1054,"slug":1055},67,"KPIs & Abnahmekriterien","kpis",{"id":1057,"name":1058,"slug":1059},77,"Messung & Monitoring","measurement",{"id":1061,"name":1062,"slug":1063},76,"Performance-Budgets","budgets",{"id":1065,"name":1066,"slug":1067},68,"Risiken, Kontrollen & Nachweise","risks-and-controls",{"id":1069,"login":1070,"email":1071,"displayName":1072},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1074,1404],{"lang":7,"title":207,"content":209,"contentJson":1075,"excerpt":1031},{"time":211,"blocks":1076,"version":1030},[1077,1079,1081,1083,1085,1087,1089,1091,1093,1109,1111,1113,1115,1117,1126,1128,1130,1132,1134,1136,1147,1149,1151,1153,1162,1164,1166,1168,1170,1185,1187,1189,1191,1201,1203,1205,1207,1209,1211,1213,1215,1224,1226,1228,1239,1241,1243,1245,1247,1249,1259,1261,1263,1265,1267,1269,1281,1283,1285,1296,1298,1315,1317,1319,1321,1323,1325,1327,1329,1331,1333,1335,1337,1339,1341,1351,1353,1364,1366,1368,1372,1376,1380,1384,1388,1392,1396,1400],{"id":214,"data":1078,"type":217},{"text":216},{"id":219,"data":1080,"type":224},{"body":221,"title":222,"variant":223},{"id":226,"data":1082,"type":224},{"body":228,"title":229,"variant":230},{"id":232,"data":1084,"type":237},{"title":234,"maxLevel":235,"minLevel":236},{"id":239,"data":1086,"type":41},{"text":241,"level":236},{"id":243,"data":1088,"type":217},{"text":245},{"id":247,"data":1090,"type":217},{"text":249},{"id":251,"data":1092,"type":217},{"text":253},{"id":255,"data":1094,"type":297},{"rows":1095,"title":288,"layout":289,"columns":1106},[1096,1098,1100,1102,1104],{"id":259,"label":260,"values":1097},{"adr":262,"nfr":263},{"id":265,"label":266,"values":1099},{"adr":268,"nfr":269},{"id":271,"label":272,"values":1101},{"adr":274,"nfr":275},{"id":277,"label":278,"values":1103},{"adr":280,"nfr":281},{"id":283,"label":284,"values":1105},{"adr":286,"nfr":287},[1107,1108],{"id":292,"label":293},{"id":295,"label":296},{"id":299,"data":1110,"type":41},{"text":301,"level":236},{"id":303,"data":1112,"type":217},{"text":305},{"id":307,"data":1114,"type":217},{"text":309},{"id":311,"data":1116,"type":217},{"text":313},{"id":315,"data":1118,"type":289},{"content":1119,"stretched":42,"withHeadings":13},[1120,1121,1122,1123,1124,1125],[319,320,321],[323,324,325],[327,328,329],[331,332,333],[335,336,337],[339,340,341],{"id":343,"data":1127,"type":224},{"body":345,"title":346,"variant":347},{"id":349,"data":1129,"type":41},{"text":351,"level":236},{"id":353,"data":1131,"type":217},{"text":355},{"id":357,"data":1133,"type":217},{"text":359},{"id":361,"data":1135,"type":217},{"text":363},{"id":365,"data":1137,"type":289},{"content":1138,"stretched":42,"withHeadings":13},[1139,1140,1141,1142,1143,1144,1145,1146],[369,370,371],[373,374,375],[377,378,379],[381,382,383],[385,386,387],[389,390,391],[393,394,395],[397,398,399],{"id":401,"data":1148,"type":41},{"text":403,"level":236},{"id":405,"data":1150,"type":217},{"text":407},{"id":409,"data":1152,"type":217},{"text":411},{"id":413,"data":1154,"type":436},{"steps":1155,"title":434,"orientation":435},[1156,1157,1158,1159,1160,1161],{"label":417,"description":418},{"label":420,"description":421},{"label":423,"description":424},{"label":426,"description":427},{"label":429,"description":430},{"label":432,"description":433},{"id":438,"data":1163,"type":224},{"body":440,"title":441,"variant":442},{"id":444,"data":1165,"type":41},{"text":446,"level":236},{"id":448,"data":1167,"type":217},{"text":450},{"id":452,"data":1169,"type":217},{"text":454},{"id":456,"data":1171,"type":297},{"rows":1172,"title":487,"layout":289,"columns":1181},[1173,1175,1177,1179],{"id":460,"label":461,"values":1174},{"adr":463,"nfr":464,"validation":465},{"id":467,"label":468,"values":1176},{"adr":470,"nfr":471,"validation":472},{"id":474,"label":475,"values":1178},{"adr":477,"nfr":478,"validation":479},{"id":481,"label":482,"values":1180},{"adr":484,"nfr":485,"validation":486},[1182,1183,1184],{"id":292,"label":490},{"id":295,"label":492},{"id":494,"label":495},{"id":497,"data":1186,"type":41},{"text":499,"level":236},{"id":501,"data":1188,"type":217},{"text":503},{"id":505,"data":1190,"type":217},{"text":507},{"id":509,"data":1192,"type":289},{"content":1193,"stretched":42,"withHeadings":13},[1194,1195,1196,1197,1198,1199,1200],[513,514,515],[517,518,519],[521,522,523],[525,526,527],[529,530,531],[533,534,535],[537,522,538],{"id":540,"data":1202,"type":41},{"text":542,"level":236},{"id":544,"data":1204,"type":217},{"text":546},{"id":548,"data":1206,"type":217},{"text":550},{"id":552,"data":1208,"type":224},{"body":554,"title":555,"variant":442},{"id":557,"data":1210,"type":41},{"text":559,"level":236},{"id":561,"data":1212,"type":217},{"text":563},{"id":565,"data":1214,"type":217},{"text":567},{"id":569,"data":1216,"type":436},{"steps":1217,"title":590,"orientation":435},[1218,1219,1220,1221,1222,1223],{"label":573,"description":574},{"label":576,"description":577},{"label":579,"description":580},{"label":582,"description":583},{"label":585,"description":586},{"label":588,"description":589},{"id":592,"data":1225,"type":41},{"text":594,"level":236},{"id":596,"data":1227,"type":217},{"text":598},{"id":600,"data":1229,"type":436},{"steps":1230,"title":627,"orientation":435},[1231,1232,1233,1234,1235,1236,1237,1238],{"label":604,"description":605},{"label":607,"description":608},{"label":610,"description":611},{"label":613,"description":614},{"label":616,"description":617},{"label":619,"description":620},{"label":622,"description":623},{"label":625,"description":626},{"id":629,"data":1240,"type":41},{"text":631,"level":236},{"id":633,"data":1242,"type":224},{"body":635,"title":636,"variant":230},{"id":638,"data":1244,"type":217},{"text":640},{"id":642,"data":1246,"type":217},{"text":644},{"id":646,"data":1248,"type":217},{"text":648},{"id":650,"data":1250,"type":289},{"content":1251,"stretched":42,"withHeadings":13},[1252,1253,1254,1255,1256,1257,1258],[654,655,656],[658,659,660],[662,663,664],[666,667,668],[670,671,672],[674,675,676],[678,679,680],{"id":682,"data":1260,"type":224},{"body":684,"title":685,"variant":347},{"id":687,"data":1262,"type":41},{"text":689,"level":236},{"id":691,"data":1264,"type":217},{"text":693},{"id":695,"data":1266,"type":217},{"text":697},{"id":699,"data":1268,"type":41},{"text":701,"level":236},{"id":703,"data":1270,"type":289},{"content":1271,"stretched":42,"withHeadings":13},[1272,1273,1274,1275,1276,1277,1278,1279,1280],[707,708,709],[711,712,713],[715,716,717],[719,720,721],[723,724,725],[727,728,729],[731,732,733],[735,736,737],[739,740,741],{"id":743,"data":1282,"type":41},{"text":745,"level":236},{"id":747,"data":1284,"type":217},{"text":749},{"id":751,"data":1286,"type":436},{"steps":1287,"title":778,"orientation":435},[1288,1289,1290,1291,1292,1293,1294,1295],{"label":755,"description":756},{"label":758,"description":759},{"label":761,"description":762},{"label":764,"description":765},{"label":767,"description":768},{"label":770,"description":771},{"label":773,"description":774},{"label":776,"description":777},{"id":780,"data":1297,"type":41},{"text":782,"level":236},{"id":784,"data":1299,"type":297},{"rows":1300,"title":817,"layout":289,"columns":1311},[1301,1303,1305,1307,1309],{"id":292,"label":293,"values":1302},{"not":789,"why":790,"term":791},{"id":295,"label":616,"values":1304},{"not":794,"why":795,"term":796},{"id":798,"label":622,"values":1306},{"not":800,"why":801,"term":802},{"id":804,"label":805,"values":1308},{"not":807,"why":808,"term":809},{"id":811,"label":812,"values":1310},{"not":814,"why":815,"term":816},[1312,1313,1314],{"id":820,"label":821},{"id":823,"label":824},{"id":826,"label":515},{"id":828,"data":1316,"type":41},{"text":830,"level":236},{"id":832,"data":1318,"type":217},{"text":834},{"id":836,"data":1320,"type":217},{"text":838},{"id":840,"data":1322,"type":217},{"text":842},{"id":844,"data":1324,"type":41},{"text":846,"level":236},{"id":848,"data":1326,"type":217},{"text":850},{"id":852,"data":1328,"type":217},{"text":854},{"id":856,"data":1330,"type":217},{"text":858},{"id":860,"data":1332,"type":41},{"text":862,"level":236},{"id":864,"data":1334,"type":217},{"text":866},{"id":868,"data":1336,"type":217},{"text":870},{"id":872,"data":1338,"type":217},{"text":874},{"id":876,"data":1340,"type":41},{"text":878,"level":236},{"id":880,"data":1342,"type":880},{"items":1343,"title":911},[1344,1345,1346,1347,1348,1349,1350],{"id":884,"answer":885,"question":886},{"id":888,"answer":889,"question":890},{"id":892,"answer":893,"question":894},{"id":896,"answer":897,"question":898},{"id":900,"answer":901,"question":902},{"id":904,"answer":905,"question":906},{"id":908,"answer":909,"question":910},{"id":913,"data":1352,"type":41},{"text":915,"level":236},{"id":917,"data":1354,"type":917},{"title":919,"entries":1355},[1356,1357,1358,1359,1360,1361,1362,1363],{"term":922,"anchor":292,"definition":923},{"term":925,"anchor":926,"definition":927},{"term":929,"anchor":295,"definition":930},{"term":932,"anchor":933,"definition":934},{"term":812,"anchor":811,"definition":936},{"term":938,"anchor":939,"definition":940},{"term":942,"anchor":494,"definition":943},{"term":945,"anchor":946,"definition":947},{"id":949,"data":1365,"type":41},{"text":951,"level":236},{"id":953,"data":1367,"type":217},{"text":955},{"id":957,"data":1369,"type":965},{"link":959,"meta":1370},{"image":1371,"title":963,"description":964},{"url":962},{"id":967,"data":1373,"type":965},{"link":969,"meta":1374},{"image":1375,"title":972,"description":973},{"url":962},{"id":975,"data":1377,"type":965},{"link":977,"meta":1378},{"image":1379,"title":980,"description":981},{"url":962},{"id":983,"data":1381,"type":965},{"link":985,"meta":1382},{"image":1383,"title":988,"description":989},{"url":962},{"id":991,"data":1385,"type":965},{"link":993,"meta":1386},{"image":1387,"title":996,"description":997},{"url":962},{"id":999,"data":1389,"type":965},{"link":1001,"meta":1390},{"image":1391,"title":1004,"description":1005},{"url":962},{"id":1007,"data":1393,"type":965},{"link":1009,"meta":1394},{"image":1395,"title":1012,"description":1013},{"url":962},{"id":1015,"data":1397,"type":965},{"link":1017,"meta":1398},{"image":1399,"title":1020,"description":1021},{"url":962},{"id":1023,"data":1401,"type":965},{"link":1025,"meta":1402},{"image":1403,"title":1028,"description":1029},{"url":962},{"lang":1405,"title":1406,"content":1407,"contentJson":1408,"excerpt":2037},"en","ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing","{\"time\":1791475659420,\"blocks\":[{\"id\":\"intro\",\"data\":{\"text\":\"An \u003Cstrong>non-functional requirement (NFR)\u003C\u002Fstrong> describes a quality, constraint, or operating condition the system is expected to satisfy. An \u003Cstrong>architecture decision record (ADR)\u003C\u002Fstrong> records an architecturally significant choice made in response to requirements, constraints, risks, and trade-offs. They are connected, but they are not interchangeable: an NFR states what must be true; an ADR explains what was decided, why, and with what consequences.\"},\"type\":\"paragraph\"},{\"id\":\"direct\",\"data\":{\"body\":\"\u003Cstrong>NFR = required system quality or constraint. ADR = recorded architecture decision.\u003C\u002Fstrong> A latency target, availability objective, isolation rule, deployment restriction, or maintainability requirement can influence architecture. An ADR then records a significant choice made to address one or more such drivers. The ADR does not replace the requirement, and the existence of an ADR does not prove that the requirement has been satisfied.\",\"title\":\"Direct answer\",\"variant\":\"info\"},\"type\":\"callout\"},{\"id\":\"version-note\",\"data\":{\"body\":\"The term \u003Cstrong>NFR\u003C\u002Fstrong> is widely used but not perfectly standardized. This article uses it as practical shorthand for quality requirements and relevant constraints. Current standards were re-checked on \u003Cstrong>8 October 2026\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 remains current but is under revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are the current published editions cited here.\",\"title\":\"Terminology and standards note\",\"variant\":\"note\"},\"type\":\"callout\"},{\"id\":\"toc\",\"data\":{\"title\":\"Contents\",\"maxLevel\":3,\"minLevel\":2},\"type\":\"tableOfContents\"},{\"id\":\"h-meaning\",\"data\":{\"text\":\"What is the difference between an NFR and an ADR?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-meaning-1\",\"data\":{\"text\":\"The simplest distinction is grammatical. A requirement describes a condition the system must satisfy. A decision record describes a choice the team made.\"},\"type\":\"paragraph\"},{\"id\":\"p-meaning-2\",\"data\":{\"text\":\"For example, \u003Cstrong>“The API must return 95% of read requests within 300 ms under the agreed reference load”\u003C\u002Fstrong> is a quality requirement. \u003Cstrong>“Use a read-through cache for this workload because the measured database-only path cannot meet the latency target without unacceptable cost”\u003C\u002Fstrong> is an architecture decision.\"},\"type\":\"paragraph\"},{\"id\":\"p-meaning-3\",\"data\":{\"text\":\"The first statement remains valid even if the implementation changes. The second statement can later be superseded by another decision if the workload, technology, cost model, or evidence changes.\"},\"type\":\"paragraph\"},{\"id\":\"basic-difference\",\"data\":{\"rows\":[{\"id\":\"question\",\"label\":\"Primary question\",\"values\":{\"adr\":\"What architecturally significant choice did we make, and why?\",\"nfr\":\"What quality, constraint, or operating condition must the system satisfy?\"}},{\"id\":\"content\",\"label\":\"Typical content\",\"values\":{\"adr\":\"Context, decision, rationale, alternatives, trade-offs, status and consequences\",\"nfr\":\"Measurable target, scope, condition, constraint, acceptance or validation rule\"}},{\"id\":\"lifecycle\",\"label\":\"Lifecycle role\",\"values\":{\"adr\":\"A historical record of a significant decision\",\"nfr\":\"A requirement to design for and validate\"}},{\"id\":\"evidence\",\"label\":\"What proves it?\",\"values\":{\"adr\":\"The record proves what was decided, not that the resulting system meets the requirement\",\"nfr\":\"Measurement, test, analysis, inspection, audit or other validation evidence\"}},{\"id\":\"change\",\"label\":\"When it changes\",\"values\":{\"adr\":\"When the decision is replaced, rejected, deprecated, or superseded\",\"nfr\":\"When stakeholder need, operating conditions, policy or quality target changes\"}}],\"title\":\"NFR and ADR answer different questions\",\"layout\":\"table\",\"columns\":[{\"id\":\"nfr\",\"label\":\"NFR \u002F quality requirement\"},{\"id\":\"adr\",\"label\":\"ADR \u002F architecture decision\"}]},\"type\":\"comparison\"},{\"id\":\"h-nfr\",\"data\":{\"text\":\"What is an NFR in precise architectural terms?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-nfr-1\",\"data\":{\"text\":\"“Non-functional requirement” is a convenient industry label, but it can hide several different kinds of statements. In architecture work, the useful distinction is between \u003Cstrong>functional behavior\u003C\u002Fstrong>, \u003Cstrong>quality requirements\u003C\u002Fstrong>, and \u003Cstrong>constraints\u003C\u002Fstrong>.\"},\"type\":\"paragraph\"},{\"id\":\"p-nfr-2\",\"data\":{\"text\":\"ISO\u002FIEC 25010:2023 provides a product-quality model with nine characteristics and subcharacteristics that can be used when specifying and evaluating ICT and software product quality. SEI architecture work similarly treats quality attribute requirements as major drivers of software architecture.\"},\"type\":\"paragraph\"},{\"id\":\"p-nfr-3\",\"data\":{\"text\":\"A useful NFR is therefore not “the system should be fast” or “the platform must be secure.” Those statements name aspirations. An architecture-driving requirement should make the expected property testable enough that design alternatives and later evidence can be evaluated against it.\"},\"type\":\"paragraph\"},{\"id\":\"nfr-examples\",\"data\":{\"content\":[[\"Weak statement\",\"More useful requirement shape\",\"Why the difference matters\"],[\"The API must be fast\",\"For workload W, 95% of operation X completes within T milliseconds\",\"Defines workload, operation, metric and threshold\"],[\"The service must be available\",\"Service S meets an agreed availability objective over measurement window M, excluding explicitly defined maintenance conditions\",\"Makes availability measurable and defines scope\"],[\"Tenant data must be secure\",\"A request authenticated for tenant A must never retrieve or mutate tenant B data through supported application paths\",\"Turns a vague security goal into an isolation property\"],[\"The system should scale\",\"The system supports workload W at concurrency C while meeting latency and error-rate thresholds\",\"Connects scale to measurable service behavior\"],[\"We need PostgreSQL\",\"Not an NFR by itself; state the required persistence qualities or external constraint first\",\"A technology choice is normally a solution, not the requirement it is meant to satisfy\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"nfr-rule\",\"data\":{\"body\":\"If “use Kubernetes,” “use PostgreSQL,” “use microservices,” or “use vector search” appears as the requirement, ask whether it is truly an external constraint or whether the solution has been written down before the underlying quality need was made explicit.\",\"title\":\"A requirement should describe the need before the mechanism\",\"variant\":\"success\"},\"type\":\"callout\"},{\"id\":\"h-adr\",\"data\":{\"text\":\"What is an Architecture Decision Record?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-adr-1\",\"data\":{\"text\":\"An Architecture Decision Record is a compact record of an important architecture decision. Michael Nygard’s original ADR formulation emphasizes the \u003Cstrong>context\u003C\u002Fstrong>, the \u003Cstrong>decision\u003C\u002Fstrong>, its \u003Cstrong>status\u003C\u002Fstrong>, and the resulting \u003Cstrong>consequences\u003C\u002Fstrong>.\"},\"type\":\"paragraph\"},{\"id\":\"p-adr-2\",\"data\":{\"text\":\"The important object is the decision, not the template. Different teams use different ADR formats. A richer record can also preserve alternatives, decision criteria, trade-offs, evidence, links to requirements, and the date or version from which the decision applies.\"},\"type\":\"paragraph\"},{\"id\":\"p-adr-3\",\"data\":{\"text\":\"ISO\u002FIEC\u002FIEEE 42010:2022 is broader than ADR practice: it specifies requirements for architecture descriptions and their concepts, while explicitly not prescribing one process, notation, tool, format, or medium for recording an architecture description. An ADR is therefore a practical decision-recording technique, not a format mandated by ISO 42010.\"},\"type\":\"paragraph\"},{\"id\":\"adr-anatomy\",\"data\":{\"content\":[[\"ADR field\",\"What it preserves\",\"Why it matters\"],[\"Context\",\"The problem, forces, requirements, assumptions and environment surrounding the choice\",\"Future readers can reconstruct why a choice was necessary\"],[\"Decision\",\"The choice that became authoritative\",\"Separates the selected option from discussion\"],[\"Status\",\"Proposed, accepted, rejected, deprecated, superseded, or another controlled state\",\"Prevents old decisions from silently remaining active\"],[\"Alternatives\",\"Other viable options considered\",\"Shows that the selected solution was not the only imaginable one\"],[\"Rationale \u002F trade-offs\",\"Why the option was selected and what it gives up\",\"Makes architecture reasoning inspectable\"],[\"Consequences\",\"Expected positive and negative effects, follow-up work, risks\",\"Connects a local choice to system impact\"],[\"Date \u002F version\",\"When the decision became valid\",\"Supports historical traceability and later supersession\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-simple-example\",\"data\":{\"text\":\"The simplest example: latency requirement → architecture decision\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-simple-1\",\"data\":{\"text\":\"Suppose a product owner and engineering team agree that a search endpoint must return the first page of results within 400 ms at the 95th percentile under a defined reference workload.\"},\"type\":\"paragraph\"},{\"id\":\"p-simple-2\",\"data\":{\"text\":\"That target is not an ADR. It is a quality requirement. Architecture work begins by asking what design can satisfy it under the system’s other constraints.\"},\"type\":\"paragraph\"},{\"id\":\"simple-flow\",\"data\":{\"steps\":[{\"label\":\"1. State the requirement\",\"description\":\"Define the quality target, workload, scope, threshold and validation method.\"},{\"label\":\"2. Identify architectural significance\",\"description\":\"Determine whether the requirement materially influences structure, technology, deployment, data flow or operating model.\"},{\"label\":\"3. Evaluate options\",\"description\":\"Compare alternatives such as indexing, caching, denormalization, asynchronous work, partitioning, or a different query architecture.\"},{\"label\":\"4. Record the decision\",\"description\":\"Capture the selected architecture choice, rationale, alternatives, trade-offs, status and consequences in an ADR.\"},{\"label\":\"5. Implement\",\"description\":\"Turn the decision into code, infrastructure, configuration and operational behavior.\"},{\"label\":\"6. Validate\",\"description\":\"Measure the real system against the original requirement. The test result validates the NFR; the ADR alone does not.\"}],\"title\":\"From requirement to evidence\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"simple-stop\",\"data\":{\"body\":\"Real systems rarely have one requirement and one decision. Performance may trade against cost, consistency, operability, security, maintainability, energy use or delivery risk. The useful model is therefore a traceability graph, not a one-to-one mapping.\",\"title\":\"Where the simple example stops\",\"variant\":\"warning\"},\"type\":\"callout\"},{\"id\":\"h-many-many\",\"data\":{\"text\":\"NFRs and ADRs usually have a many-to-many relationship\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-many-1\",\"data\":{\"text\":\"One quality requirement can drive several architecture decisions. A tenant-isolation requirement, for example, can influence identity propagation, database scoping, background-job design, cache keys, audit logging, and administrative tooling.\"},\"type\":\"paragraph\"},{\"id\":\"p-many-2\",\"data\":{\"text\":\"One architecture decision can also respond to several requirements at once. Choosing an asynchronous processing boundary might improve responsiveness and failure isolation while introducing consistency, complexity, observability, and operational trade-offs.\"},\"type\":\"paragraph\"},{\"id\":\"relationship-map\",\"data\":{\"rows\":[{\"id\":\"one-many\",\"label\":\"One NFR → many ADRs\",\"values\":{\"adr\":\"Several coordinated decisions may be required\",\"nfr\":\"A broad quality target can constrain several architectural boundaries\",\"validation\":\"Evidence may need multiple tests or measurements\"}},{\"id\":\"many-one\",\"label\":\"Many NFRs → one ADR\",\"values\":{\"adr\":\"One decision may balance several drivers\",\"nfr\":\"Several quality and constraint drivers can point at the same design problem\",\"validation\":\"Each requirement still needs its own acceptance evidence\"}},{\"id\":\"non-nfr\",\"label\":\"ADR without a classic NFR\",\"values\":{\"adr\":\"The choice can still be architecturally significant\",\"nfr\":\"The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition\",\"validation\":\"Validate against the actual driver, not an invented NFR\"}},{\"id\":\"supersession\",\"label\":\"Requirement stable, ADR changes\",\"values\":{\"adr\":\"A better or necessary implementation choice can supersede the old decision\",\"nfr\":\"The target can remain unchanged\",\"validation\":\"The new architecture must still be checked against the same target\"}}],\"title\":\"Why the relationship is not one-to-one\",\"layout\":\"table\",\"columns\":[{\"id\":\"nfr\",\"label\":\"Requirement side\"},{\"id\":\"adr\",\"label\":\"Decision side\"},{\"id\":\"validation\",\"label\":\"Validation side\"}]},\"type\":\"comparison\"},{\"id\":\"h-technology\",\"data\":{\"text\":\"A technology choice is not automatically a requirement\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-tech-1\",\"data\":{\"text\":\"A recurring architecture error is to write a preferred technology into the requirements layer and then treat the resulting design as inevitable.\"},\"type\":\"paragraph\"},{\"id\":\"p-tech-2\",\"data\":{\"text\":\"“The system must use PostgreSQL” can be a legitimate constraint if a contract, platform policy, compatibility requirement, licensing rule, organizational standard, or existing operational boundary actually mandates PostgreSQL. But if the real need is transactional consistency, structured querying, operational familiarity, or a specific recovery objective, the requirement should state that need and the technology selection should be recorded as a decision.\"},\"type\":\"paragraph\"},{\"id\":\"tech-table\",\"data\":{\"content\":[[\"Statement\",\"Classification\",\"Reason\"],[\"All tenant-scoped reads must enforce tenant isolation\",\"Requirement \u002F security property\",\"Describes a property that must hold\"],[\"Use PostgreSQL Row Level Security for selected tenant-scoped tables\",\"Architecture decision\",\"Chooses a mechanism intended to help satisfy the isolation property\"],[\"The deployment target must run in an approved EU-operated environment\",\"Constraint \u002F NFR-like operating condition\",\"Restricts where the system may operate\"],[\"Use provider X in region Y\",\"Architecture \u002F deployment decision unless externally mandated\",\"Selects a particular solution inside the allowed boundary\"],[\"95th-percentile API latency ≤ 300 ms under workload W\",\"Quality requirement\",\"Defines measurable performance behavior\"],[\"Introduce a cache for endpoint X\",\"Architecture decision\",\"Selects a tactic intended to improve the measured behavior\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-adr-proof\",\"data\":{\"text\":\"An ADR is not proof that an NFR has been satisfied\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-proof-1\",\"data\":{\"text\":\"Decision documentation and system validation answer different questions. An ADR can show that performance, security, resilience, or maintainability were considered. It cannot by itself demonstrate that the delivered system actually achieves those properties.\"},\"type\":\"paragraph\"},{\"id\":\"p-proof-2\",\"data\":{\"text\":\"The proof must come from the validation method appropriate to the requirement: benchmark, load test, failure test, security test, architecture analysis, audit, inspection, operational telemetry, recovery exercise, user study, or another form of evidence.\"},\"type\":\"paragraph\"},{\"id\":\"proof-rule\",\"data\":{\"body\":\"\u003Cstrong>ADR:\u003C\u002Fstrong> “We selected design X because it is expected to satisfy requirement R under assumptions A.”\u003Cbr>\u003Cstrong>Validation:\u003C\u002Fstrong> “Measured or analyzed evidence E shows whether the implemented system actually satisfies R.”\",\"title\":\"Do not confuse intent with evidence\",\"variant\":\"warning\"},\"type\":\"callout\"},{\"id\":\"h-asr\",\"data\":{\"text\":\"When does an NFR become architecturally significant?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-asr-1\",\"data\":{\"text\":\"Not every non-functional requirement deserves an architecture decision. The important subset is the requirements that materially shape the architecture or force trade-offs across the system.\"},\"type\":\"paragraph\"},{\"id\":\"p-asr-2\",\"data\":{\"text\":\"SEI literature uses the concept of \u003Cstrong>architecturally significant requirements\u003C\u002Fstrong> for requirements with far-reaching architectural effect. Quality attributes such as performance, reliability, security, and modifiability are frequent sources of such drivers, especially when they carry high business or mission value.\"},\"type\":\"paragraph\"},{\"id\":\"asr-test\",\"data\":{\"steps\":[{\"label\":\"1. Ask whether the requirement changes structure\",\"description\":\"Would different values force different components, boundaries, data paths or deployment topology?\"},{\"label\":\"2. Ask whether it constrains major technology choices\",\"description\":\"Does it eliminate otherwise viable implementation options?\"},{\"label\":\"3. Ask whether it creates cross-cutting behavior\",\"description\":\"Does it affect many components, teams, interfaces or lifecycle stages?\"},{\"label\":\"4. Ask whether it creates a difficult trade-off\",\"description\":\"Does improving this property materially affect another quality, cost, schedule, complexity or risk?\"},{\"label\":\"5. Ask whether failure is expensive\",\"description\":\"Would missing the requirement create material operational, security, regulatory, financial or product impact?\"},{\"label\":\"6. Record decisions only where the reasoning is worth preserving\",\"description\":\"Do not create ADRs for every local coding choice; preserve architecturally significant decisions and their rationale.\"}],\"title\":\"Architectural-significance test\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"h-traceability\",\"data\":{\"text\":\"A stronger architecture model: requirement → decision → implementation → validation\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-trace-1\",\"data\":{\"text\":\"The most useful connection between NFRs and ADRs is traceability. A requirement should be able to point to the architecture decisions that address it; an ADR should identify the drivers it responds to; implementation work should realize the decision; validation should return to the original requirement.\"},\"type\":\"paragraph\"},{\"id\":\"trace-flow\",\"data\":{\"steps\":[{\"label\":\"Need \u002F business goal\",\"description\":\"Why the quality or constraint matters.\"},{\"label\":\"Requirement \u002F NFR\",\"description\":\"What the system must achieve or respect.\"},{\"label\":\"Architecture drivers\",\"description\":\"Which requirements are significant enough to shape the design.\"},{\"label\":\"Options\",\"description\":\"Plausible ways to address the driver.\"},{\"label\":\"ADR\",\"description\":\"The selected choice, rationale, alternatives, trade-offs and consequences.\"},{\"label\":\"Implementation\",\"description\":\"Code, data model, infrastructure, interfaces and operational mechanisms that realize the decision.\"},{\"label\":\"Validation evidence\",\"description\":\"Tests, measurements, analysis or audits demonstrating whether the original requirement is actually satisfied.\"},{\"label\":\"Change \u002F supersession\",\"description\":\"New evidence or changed requirements can trigger a new ADR while preserving historical reasoning.\"}],\"title\":\"Architecture traceability chain\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"h-senseflow\",\"data\":{\"text\":\"Implementation evidence: how I separate requirements and decisions in SenseFlow\",\"level\":2},\"type\":\"header\"},{\"id\":\"senseflow-evidence\",\"data\":{\"body\":\"The following section describes my own SenseFlow project structure. It is implementation evidence for the separation in this article, not a claim that every team must use the same documentation model.\",\"title\":\"Original implementation \u002F project evidence\",\"variant\":\"note\"},\"type\":\"callout\"},{\"id\":\"p-sense-1\",\"data\":{\"text\":\"In SenseFlow, the project Source of Truth explicitly places non-functional requirements inside the requirements structure together with dependencies, risks, assumptions, acceptance criteria, and a validation method. The documentation model separately defines decision integrity for significant decisions.\"},\"type\":\"paragraph\"},{\"id\":\"p-sense-2\",\"data\":{\"text\":\"For significant SenseFlow decisions, the recorded fields are \u003Cstrong>Decision, Reason, Alternatives, Trade-offs, Status, and Date \u002F Version\u003C\u002Fstrong>. Major architecture and product decisions are intended to remain historically traceable rather than being overwritten when the project evolves.\"},\"type\":\"paragraph\"},{\"id\":\"p-sense-3\",\"data\":{\"text\":\"SenseFlow also assigns different operational roles to Confluence and Jira. Confluence is the structured knowledge and decision environment; Jira manages actionable delivery work. Major Jira Epics should link back to the relevant product or requirements documentation. This preserves the chain from product intent through requirements and decisions into implementation rather than turning the backlog into the architecture Source of Truth.\"},\"type\":\"paragraph\"},{\"id\":\"senseflow-table\",\"data\":{\"content\":[[\"SenseFlow layer\",\"What it contains\",\"Role in ADR\u002FNFR separation\"],[\"Product \u002F requirement structure\",\"Product goal, capability, epic, user story, acceptance criteria, technical tasks; requirements can include NFRs and validation method\",\"Preserves what must be achieved and how success will be checked\"],[\"Decision integrity\",\"Decision, reason, alternatives, trade-offs, status, date\u002Fversion\",\"Preserves why an architecturally significant choice became authoritative\"],[\"Confluence\",\"Requirements, architecture, research, decision records, risks, roadmap and supporting sources\",\"Maintains conceptual and historical Source of Truth\"],[\"Jira\",\"Initiatives\u002Fgoals, epics, stories, tasks and delivery state\",\"Executes approved work without becoming the conceptual Source of Truth\"],[\"Change management\",\"Current state → new evidence → proposed change → impact → decision\",\"Allows decisions to evolve without erasing the reasoning trail\"],[\"End-to-end traceability\",\"Problem → need → value → product goal → requirement → implementation → validation\",\"Keeps decision documentation connected to the actual product and evidence lifecycle\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"senseflow-lesson\",\"data\":{\"body\":\"A requirement and a decision can live close together without being collapsed into one record. The requirement remains the target; the decision remains the reasoning history; delivery work implements the decision; validation returns to the target.\",\"title\":\"What this implementation demonstrates\",\"variant\":\"success\"},\"type\":\"callout\"},{\"id\":\"h-enterprise\",\"data\":{\"text\":\"Enterprise project context: requirements should precede architecture choices\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-enterprise-1\",\"data\":{\"text\":\"The same separation is useful in enterprise-oriented project work. Architecture decisions made before requirements, risks, constraints, and acceptance conditions are sufficiently understood can turn preferences into false necessities.\"},\"type\":\"paragraph\"},{\"id\":\"p-enterprise-2\",\"data\":{\"text\":\"For Enterprise Aaasaasa 0.1, the relevant lesson is methodological rather than a claim about one particular ADR: requirements, architecture, validation, milestones, risk management, and acceptance belong to a connected delivery system. An architecture choice should remain traceable to the requirement or constraint it is intended to address.\"},\"type\":\"paragraph\"},{\"id\":\"h-failures\",\"data\":{\"text\":\"Common failure modes when ADRs and NFRs are mixed\",\"level\":2},\"type\":\"header\"},{\"id\":\"failure-table\",\"data\":{\"content\":[[\"Failure mode\",\"What happens\",\"Consequence\"],[\"Technology disguised as requirement\",\"A preferred solution is written as “must use X” without establishing the underlying need\",\"Alternatives are never evaluated and architecture becomes prematurely fixed\"],[\"NFR hidden only inside an ADR\",\"The decision mentions a performance\u002Fsecurity target that is absent from the requirements baseline\",\"The target is hard to validate, prioritize or manage independently\"],[\"ADR treated as proof\",\"A documented choice is assumed to mean the requirement is satisfied\",\"Architecture intent replaces measurement or verification\"],[\"Vague NFR\",\"Words such as fast, scalable, secure or maintainable have no measurable scope\",\"Different stakeholders can believe the same requirement means different things\"],[\"No alternatives recorded\",\"The team records only the selected technology\",\"Future maintainers cannot reconstruct why another option was rejected\"],[\"No supersession model\",\"Old ADRs are edited or deleted when the architecture changes\",\"Historical reasoning disappears and stale decisions can remain ambiguous\"],[\"Every implementation detail becomes an ADR\",\"The repository fills with low-value records\",\"Important architecture choices become difficult to find\"],[\"Backlog becomes architecture SoT\",\"Jira tasks are treated as the only explanation of the system\",\"Delivery state survives, but architectural rationale and quality drivers are lost\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-decision-framework\",\"data\":{\"text\":\"The ADR–NFR decision framework\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-framework-1\",\"data\":{\"text\":\"When a team encounters a new architecture concern, the following sequence helps determine what belongs in requirements, what belongs in an ADR, and what belongs in evidence.\"},\"type\":\"paragraph\"},{\"id\":\"decision-flow\",\"data\":{\"steps\":[{\"label\":\"1. Is this a required property or external constraint?\",\"description\":\"If yes, write or reference the requirement before choosing a mechanism.\"},{\"label\":\"2. Can it be validated?\",\"description\":\"Define the scope, condition, metric, acceptance rule, analysis method or other evidence needed.\"},{\"label\":\"3. Is it architecturally significant?\",\"description\":\"Identify whether the requirement materially shapes structure, technology, data, deployment or cross-cutting trade-offs.\"},{\"label\":\"4. Are there meaningful alternatives?\",\"description\":\"Compare viable tactics or architecture options rather than jumping directly to a preferred technology.\"},{\"label\":\"5. Has a choice become authoritative?\",\"description\":\"Create or update the ADR with context, decision, rationale, alternatives, trade-offs, status and consequences.\"},{\"label\":\"6. Is the decision implemented?\",\"description\":\"Trace the ADR into design, tasks, code, configuration and operations.\"},{\"label\":\"7. Is the requirement satisfied?\",\"description\":\"Collect validation evidence against the requirement itself.\"},{\"label\":\"8. Did conditions change?\",\"description\":\"Re-evaluate the requirement and, when necessary, supersede the ADR without erasing history.\"}],\"title\":\"ADR–NFR classification test\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"h-what-not\",\"data\":{\"text\":\"What ADR and NFR are not\",\"level\":2},\"type\":\"header\"},{\"id\":\"not-comparison\",\"data\":{\"rows\":[{\"id\":\"nfr\",\"label\":\"NFR \u002F quality requirement\",\"values\":{\"not\":\"A technology shopping list\",\"why\":\"Requirements should preserve the need independently from one implementation when possible\",\"term\":\"A required quality, constraint or operating condition\"}},{\"id\":\"adr\",\"label\":\"ADR\",\"values\":{\"not\":\"The complete architecture description\",\"why\":\"Architecture also needs views, interfaces, models, responsibilities and other documentation\",\"term\":\"A record of an architecturally significant decision\"}},{\"id\":\"test\",\"label\":\"Validation evidence\",\"values\":{\"not\":\"The ADR itself\",\"why\":\"Documented intent is different from measured or analyzed system behavior\",\"term\":\"Evidence that checks whether a requirement is satisfied\"}},{\"id\":\"backlog\",\"label\":\"Backlog item\",\"values\":{\"not\":\"A durable substitute for architecture rationale\",\"why\":\"Task state answers what is being delivered, not necessarily why the architecture exists\",\"term\":\"Actionable delivery work\"}},{\"id\":\"constraint\",\"label\":\"Constraint\",\"values\":{\"not\":\"Always an internally chosen architecture decision\",\"why\":\"Some constraints come from regulation, contracts, existing platforms or organizational boundaries\",\"term\":\"A condition that restricts the solution space\"}}],\"title\":\"Common category errors\",\"layout\":\"table\",\"columns\":[{\"id\":\"term\",\"label\":\"Concept\"},{\"id\":\"not\",\"label\":\"It is not\"},{\"id\":\"why\",\"label\":\"Reason\"}]},\"type\":\"comparison\"},{\"id\":\"h-change\",\"data\":{\"text\":\"What would change this answer?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-change-1\",\"data\":{\"text\":\"The terminology can evolve. ISO\u002FIEC\u002FIEEE 29148:2018 remains the current published requirements-engineering standard as of 8 October 2026, but ISO lists a Draft International Standard intended to replace it. If the new edition changes relevant terminology or requirements guidance, the version-specific references in this article should be updated.\"},\"type\":\"paragraph\"},{\"id\":\"p-change-2\",\"data\":{\"text\":\"ADR templates can also evolve without changing the central distinction. Michael Nygard’s minimal template, MADR, organization-specific templates, architecture knowledge tools, or structured decision databases can all record decisions. The durable question is whether the record preserves enough context and rationale to understand an architecturally significant choice.\"},\"type\":\"paragraph\"},{\"id\":\"p-change-3\",\"data\":{\"text\":\"The distinction would only collapse if an organization deliberately chose a combined artifact that stores both requirement and decision data in one document. Even then, the semantic roles remain different: one field states the required outcome or constraint; another records the chosen response.\"},\"type\":\"paragraph\"},{\"id\":\"h-limitations\",\"data\":{\"text\":\"Limitations\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-limit-1\",\"data\":{\"text\":\"This article uses \u003Cstrong>NFR\u003C\u002Fstrong> as practical shorthand. Some engineering methods prefer terms such as quality attribute requirement, quality requirement, system quality, constraint, service-level objective, or architecturally significant requirement. Those terms are not perfectly interchangeable, and project terminology should be explicit.\"},\"type\":\"paragraph\"},{\"id\":\"p-limit-2\",\"data\":{\"text\":\"Not every requirement can be reduced to a single numeric threshold. Security, safety, maintainability, interoperability, usability, explainability, portability, and governance can require combinations of scenarios, structural rules, analyses, process controls, and qualitative evidence. “Measurable” should mean verifiable enough for the decision, not artificially numeric.\"},\"type\":\"paragraph\"},{\"id\":\"p-limit-3\",\"data\":{\"text\":\"Not every architecture decision needs a formal ADR. The documentation cost should be proportional to architectural significance, longevity, uncertainty, trade-off complexity, and the cost of losing the rationale.\"},\"type\":\"paragraph\"},{\"id\":\"h-conclusion\",\"data\":{\"text\":\"Conclusion\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-conclusion-1\",\"data\":{\"text\":\"ADR and NFR belong to different layers of architecture work. \u003Cstrong>The NFR defines a quality target, constraint, or operating condition. The ADR records a significant architectural response to one or more drivers.\u003C\u002Fstrong>\"},\"type\":\"paragraph\"},{\"id\":\"p-conclusion-2\",\"data\":{\"text\":\"Keeping those layers separate makes architecture easier to reason about. Requirements can be validated independently of technology. Decisions can be superseded without rewriting history. Alternatives and trade-offs remain visible. Delivery work can be traced back to architectural intent. Evidence can show whether the resulting system actually satisfies the requirement.\"},\"type\":\"paragraph\"},{\"id\":\"p-conclusion-3\",\"data\":{\"text\":\"The strongest chain is therefore not “NFR → ADR → done.” It is \u003Cstrong>need → requirement → architectural drivers → options → decision → implementation → validation → change\u003C\u002Fstrong>. That chain turns architecture documentation from static paperwork into a testable record of why the system has the shape it has.\"},\"type\":\"paragraph\"},{\"id\":\"h-faq\",\"data\":{\"text\":\"FAQ\",\"level\":2},\"type\":\"header\"},{\"id\":\"faq\",\"data\":{\"items\":[{\"id\":\"faq1\",\"answer\":\"No. An NFR states a required quality, constraint, or operating condition. An ADR records an architecturally significant choice made in response to requirements, constraints, risks and trade-offs.\",\"question\":\"Is an ADR a non-functional requirement?\"},{\"id\":\"faq2\",\"answer\":\"No. Only requirements that materially influence architecture need architecture-level decisions worth preserving. One NFR can also drive several ADRs, and one ADR can respond to several requirements.\",\"question\":\"Should every NFR have an ADR?\"},{\"id\":\"faq3\",\"answer\":\"Only when PostgreSQL is genuinely imposed as an external constraint. Otherwise the underlying need should be expressed first, and selecting PostgreSQL should normally be treated as an architecture decision.\",\"question\":\"Can “use PostgreSQL” be an NFR?\"},{\"id\":\"faq4\",\"answer\":\"No. An ADR records intent and reasoning. The requirement is validated through appropriate evidence such as testing, measurement, analysis, audit or operational telemetry.\",\"question\":\"Does an ADR prove that a performance or security requirement is met?\"},{\"id\":\"faq5\",\"answer\":\"At minimum, an ADR should make the context and decision clear. Common structures also include status and consequences. Teams can add alternatives, rationale, trade-offs, requirement links, evidence, owners, dates and supersession relationships.\",\"question\":\"What should an ADR contain?\"},{\"id\":\"faq6\",\"answer\":\"A requirement is architecturally significant when it materially shapes system structure, technology, data flows, deployment, cross-cutting behavior or difficult quality trade-offs, especially when failure carries high business or mission impact.\",\"question\":\"What makes an NFR architecturally significant?\"},{\"id\":\"faq7\",\"answer\":\"Usually no. A replacement decision should normally supersede the old record so the historical reasoning remains traceable.\",\"question\":\"Should an old ADR be deleted when the architecture changes?\"}],\"title\":\"ADR vs NFR\"},\"type\":\"faq\"},{\"id\":\"h-glossary\",\"data\":{\"text\":\"Glossary\",\"level\":2},\"type\":\"header\"},{\"id\":\"glossary\",\"data\":{\"title\":\"Core architecture terms\",\"entries\":[{\"term\":\"NFR\",\"anchor\":\"nfr\",\"definition\":\"Non-functional requirement: practical shorthand for a required system quality, constraint, or operating condition; exact terminology varies by method and standard.\"},{\"term\":\"Quality attribute requirement\",\"anchor\":\"quality-attribute-requirement\",\"definition\":\"A requirement describing a quality property the system is expected to exhibit under defined conditions, such as performance, availability, security, reliability or modifiability.\"},{\"term\":\"Architecture Decision Record (ADR)\",\"anchor\":\"adr\",\"definition\":\"A durable record of an architecturally significant decision and enough context to understand why the choice was made and what consequences follow.\"},{\"term\":\"Architecturally Significant Requirement (ASR)\",\"anchor\":\"asr\",\"definition\":\"A requirement with sufficiently far-reaching architectural impact that it materially influences the system design.\"},{\"term\":\"Constraint\",\"anchor\":\"constraint\",\"definition\":\"A condition that restricts the solution space, including external policy, regulation, platform, compatibility, contractual or organizational boundaries.\"},{\"term\":\"Trade-off\",\"anchor\":\"trade-off\",\"definition\":\"A design relationship in which improving one objective, property or cost dimension can worsen another.\"},{\"term\":\"Validation\",\"anchor\":\"validation\",\"definition\":\"Evidence-producing work used to determine whether the implemented system satisfies the stated requirement under the relevant conditions.\"},{\"term\":\"Superseded ADR\",\"anchor\":\"superseded-adr\",\"definition\":\"A historical decision record that has been replaced by a newer authoritative decision while remaining available for traceability.\"}]},\"type\":\"glossary\"},{\"id\":\"h-sources\",\"data\":{\"text\":\"Primary sources and implementation evidence\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-sources-note\",\"data\":{\"text\":\"This article separates current standards from project implementation evidence. ISO\u002FIEC\u002FIEEE 29148:2018 remains current as of 8 October 2026 but is marked for revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are current published editions. SenseFlow is original project evidence for the traceability and decision-integrity model described above.\"},\"type\":\"paragraph\"},{\"id\":\"src-iso-29148\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC\u002FIEEE 29148:2018 — Requirements Engineering\",\"description\":\"Current published requirements-engineering standard. ISO states that the 2018 edition was reviewed and confirmed in 2024 and is expected to be replaced by the DIS now under development.\"}},\"type\":\"linkTool\"},{\"id\":\"src-iso-29148-dis\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC\u002FIEEE DIS 29148 — Requirements Engineering\",\"description\":\"Draft International Standard currently under development and intended to replace ISO\u002FIEC\u002FIEEE 29148:2018.\"}},\"type\":\"linkTool\"},{\"id\":\"src-iso-25010\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC 25010:2023 — Product Quality Model\",\"description\":\"Current product-quality model with nine quality characteristics used to specify, measure and evaluate ICT and software product quality.\"}},\"type\":\"linkTool\"},{\"id\":\"src-iso-42010\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description\",\"description\":\"Current architecture-description standard. It specifies architecture-description concepts and conformance requirements without prescribing one recording format, notation, process or tool.\"}},\"type\":\"linkTool\"},{\"id\":\"src-nygard\",\"data\":{\"link\":\"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Michael Nygard — Documenting Architecture Decisions\",\"description\":\"Original influential ADR article describing lightweight records centered on context, decision, status and consequences, with superseded decisions retained for historical understanding.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-asr\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Relating Business Goals to Architecturally Significant Requirements\",\"description\":\"SEI report explaining how quality attribute requirements and business goals drive software architecture and why architecturally significant requirements need explicit elicitation.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-nfr\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Defining Non-Functional System Qualities\",\"description\":\"SEI overview connecting non-functional\u002Fquality attributes with architecture, scenarios, trade-offs and objective system evaluation.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-add\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Attribute-Driven Design Method Collection\",\"description\":\"Architecture design method based on functional requirements, quality attribute requirements and constraints, with architectural tactics and patterns selected to satisfy quality scenarios.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-doc\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Views and Beyond Collection\",\"description\":\"Architecture-documentation guidance emphasizing relevant views and the recording of necessary design decisions as part of architecture work.\"}},\"type\":\"linkTool\"}],\"version\":\"2.31.0\"}",{"time":1409,"blocks":1410,"version":2036},1791475659420,[1411,1414,1418,1422,1425,1428,1431,1434,1437,1461,1464,1467,1470,1473,1500,1504,1507,1510,1513,1516,1550,1553,1556,1559,1581,1585,1588,1591,1594,1617,1620,1623,1626,1656,1659,1662,1665,1669,1672,1675,1678,1700,1703,1706,1733,1736,1740,1743,1746,1749,1778,1782,1785,1788,1791,1794,1833,1836,1839,1867,1870,1892,1895,1898,1901,1904,1907,1910,1913,1916,1919,1922,1925,1928,1930,1955,1958,1983,1986,1989,1994,1999,2005,2011,2016,2021,2026,2031],{"id":214,"data":1412,"type":217},{"text":1413},"An \u003Cstrong>non-functional requirement (NFR)\u003C\u002Fstrong> describes a quality, constraint, or operating condition the system is expected to satisfy. An \u003Cstrong>architecture decision record (ADR)\u003C\u002Fstrong> records an architecturally significant choice made in response to requirements, constraints, risks, and trade-offs. They are connected, but they are not interchangeable: an NFR states what must be true; an ADR explains what was decided, why, and with what consequences.",{"id":219,"data":1415,"type":224},{"body":1416,"title":1417,"variant":223},"\u003Cstrong>NFR = required system quality or constraint. ADR = recorded architecture decision.\u003C\u002Fstrong> A latency target, availability objective, isolation rule, deployment restriction, or maintainability requirement can influence architecture. An ADR then records a significant choice made to address one or more such drivers. The ADR does not replace the requirement, and the existence of an ADR does not prove that the requirement has been satisfied.","Direct answer",{"id":226,"data":1419,"type":224},{"body":1420,"title":1421,"variant":230},"The term \u003Cstrong>NFR\u003C\u002Fstrong> is widely used but not perfectly standardized. This article uses it as practical shorthand for quality requirements and relevant constraints. Current standards were re-checked on \u003Cstrong>8 October 2026\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 remains current but is under revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are the current published editions cited here.","Terminology and standards note",{"id":232,"data":1423,"type":237},{"title":1424,"maxLevel":235,"minLevel":236},"Contents",{"id":239,"data":1426,"type":41},{"text":1427,"level":236},"What is the difference between an NFR and an ADR?",{"id":243,"data":1429,"type":217},{"text":1430},"The simplest distinction is grammatical. A requirement describes a condition the system must satisfy. A decision record describes a choice the team made.",{"id":247,"data":1432,"type":217},{"text":1433},"For example, \u003Cstrong>“The API must return 95% of read requests within 300 ms under the agreed reference load”\u003C\u002Fstrong> is a quality requirement. \u003Cstrong>“Use a read-through cache for this workload because the measured database-only path cannot meet the latency target without unacceptable cost”\u003C\u002Fstrong> is an architecture decision.",{"id":251,"data":1435,"type":217},{"text":1436},"The first statement remains valid even if the implementation changes. The second statement can later be superseded by another decision if the workload, technology, cost model, or evidence changes.",{"id":255,"data":1438,"type":297},{"rows":1439,"title":1455,"layout":289,"columns":1456},[1440,1443,1446,1449,1452],{"id":259,"label":1441,"values":1442},"Primary question",{"adr":262,"nfr":263},{"id":265,"label":1444,"values":1445},"Typical content",{"adr":268,"nfr":269},{"id":271,"label":1447,"values":1448},"Lifecycle role",{"adr":274,"nfr":275},{"id":277,"label":1450,"values":1451},"What proves it?",{"adr":280,"nfr":281},{"id":283,"label":1453,"values":1454},"When it changes",{"adr":286,"nfr":287},"NFR and ADR answer different questions",[1457,1459],{"id":292,"label":1458},"NFR \u002F quality requirement",{"id":295,"label":1460},"ADR \u002F architecture decision",{"id":299,"data":1462,"type":41},{"text":1463,"level":236},"What is an NFR in precise architectural terms?",{"id":303,"data":1465,"type":217},{"text":1466},"“Non-functional requirement” is a convenient industry label, but it can hide several different kinds of statements. In architecture work, the useful distinction is between \u003Cstrong>functional behavior\u003C\u002Fstrong>, \u003Cstrong>quality requirements\u003C\u002Fstrong>, and \u003Cstrong>constraints\u003C\u002Fstrong>.",{"id":307,"data":1468,"type":217},{"text":1469},"ISO\u002FIEC 25010:2023 provides a product-quality model with nine characteristics and subcharacteristics that can be used when specifying and evaluating ICT and software product quality. SEI architecture work similarly treats quality attribute requirements as major drivers of software architecture.",{"id":311,"data":1471,"type":217},{"text":1472},"A useful NFR is therefore not “the system should be fast” or “the platform must be secure.” Those statements name aspirations. An architecture-driving requirement should make the expected property testable enough that design alternatives and later evidence can be evaluated against it.",{"id":315,"data":1474,"type":289},{"content":1475,"stretched":42,"withHeadings":13},[1476,1480,1484,1488,1492,1496],[1477,1478,1479],"Weak statement","More useful requirement shape","Why the difference matters",[1481,1482,1483],"The API must be fast","For workload W, 95% of operation X completes within T milliseconds","Defines workload, operation, metric and threshold",[1485,1486,1487],"The service must be available","Service S meets an agreed availability objective over measurement window M, excluding explicitly defined maintenance conditions","Makes availability measurable and defines scope",[1489,1490,1491],"Tenant data must be secure","A request authenticated for tenant A must never retrieve or mutate tenant B data through supported application paths","Turns a vague security goal into an isolation property",[1493,1494,1495],"The system should scale","The system supports workload W at concurrency C while meeting latency and error-rate thresholds","Connects scale to measurable service behavior",[1497,1498,1499],"We need PostgreSQL","Not an NFR by itself; state the required persistence qualities or external constraint first","A technology choice is normally a solution, not the requirement it is meant to satisfy",{"id":343,"data":1501,"type":224},{"body":1502,"title":1503,"variant":347},"If “use Kubernetes,” “use PostgreSQL,” “use microservices,” or “use vector search” appears as the requirement, ask whether it is truly an external constraint or whether the solution has been written down before the underlying quality need was made explicit.","A requirement should describe the need before the mechanism",{"id":349,"data":1505,"type":41},{"text":1506,"level":236},"What is an Architecture Decision Record?",{"id":353,"data":1508,"type":217},{"text":1509},"An Architecture Decision Record is a compact record of an important architecture decision. Michael Nygard’s original ADR formulation emphasizes the \u003Cstrong>context\u003C\u002Fstrong>, the \u003Cstrong>decision\u003C\u002Fstrong>, its \u003Cstrong>status\u003C\u002Fstrong>, and the resulting \u003Cstrong>consequences\u003C\u002Fstrong>.",{"id":357,"data":1511,"type":217},{"text":1512},"The important object is the decision, not the template. Different teams use different ADR formats. A richer record can also preserve alternatives, decision criteria, trade-offs, evidence, links to requirements, and the date or version from which the decision applies.",{"id":361,"data":1514,"type":217},{"text":1515},"ISO\u002FIEC\u002FIEEE 42010:2022 is broader than ADR practice: it specifies requirements for architecture descriptions and their concepts, while explicitly not prescribing one process, notation, tool, format, or medium for recording an architecture description. An ADR is therefore a practical decision-recording technique, not a format mandated by ISO 42010.",{"id":365,"data":1517,"type":289},{"content":1518,"stretched":42,"withHeadings":13},[1519,1523,1527,1531,1534,1538,1542,1546],[1520,1521,1522],"ADR field","What it preserves","Why it matters",[1524,1525,1526],"Context","The problem, forces, requirements, assumptions and environment surrounding the choice","Future readers can reconstruct why a choice was necessary",[1528,1529,1530],"Decision","The choice that became authoritative","Separates the selected option from discussion",[381,1532,1533],"Proposed, accepted, rejected, deprecated, superseded, or another controlled state","Prevents old decisions from silently remaining active",[1535,1536,1537],"Alternatives","Other viable options considered","Shows that the selected solution was not the only imaginable one",[1539,1540,1541],"Rationale \u002F trade-offs","Why the option was selected and what it gives up","Makes architecture reasoning inspectable",[1543,1544,1545],"Consequences","Expected positive and negative effects, follow-up work, risks","Connects a local choice to system impact",[1547,1548,1549],"Date \u002F version","When the decision became valid","Supports historical traceability and later supersession",{"id":401,"data":1551,"type":41},{"text":1552,"level":236},"The simplest example: latency requirement → architecture decision",{"id":405,"data":1554,"type":217},{"text":1555},"Suppose a product owner and engineering team agree that a search endpoint must return the first page of results within 400 ms at the 95th percentile under a defined reference workload.",{"id":409,"data":1557,"type":217},{"text":1558},"That target is not an ADR. It is a quality requirement. Architecture work begins by asking what design can satisfy it under the system’s other constraints.",{"id":413,"data":1560,"type":436},{"steps":1561,"title":1580,"orientation":435},[1562,1565,1568,1571,1574,1577],{"label":1563,"description":1564},"1. State the requirement","Define the quality target, workload, scope, threshold and validation method.",{"label":1566,"description":1567},"2. Identify architectural significance","Determine whether the requirement materially influences structure, technology, deployment, data flow or operating model.",{"label":1569,"description":1570},"3. Evaluate options","Compare alternatives such as indexing, caching, denormalization, asynchronous work, partitioning, or a different query architecture.",{"label":1572,"description":1573},"4. Record the decision","Capture the selected architecture choice, rationale, alternatives, trade-offs, status and consequences in an ADR.",{"label":1575,"description":1576},"5. Implement","Turn the decision into code, infrastructure, configuration and operational behavior.",{"label":1578,"description":1579},"6. Validate","Measure the real system against the original requirement. The test result validates the NFR; the ADR alone does not.","From requirement to evidence",{"id":438,"data":1582,"type":224},{"body":1583,"title":1584,"variant":442},"Real systems rarely have one requirement and one decision. Performance may trade against cost, consistency, operability, security, maintainability, energy use or delivery risk. The useful model is therefore a traceability graph, not a one-to-one mapping.","Where the simple example stops",{"id":444,"data":1586,"type":41},{"text":1587,"level":236},"NFRs and ADRs usually have a many-to-many relationship",{"id":448,"data":1589,"type":217},{"text":1590},"One quality requirement can drive several architecture decisions. A tenant-isolation requirement, for example, can influence identity propagation, database scoping, background-job design, cache keys, audit logging, and administrative tooling.",{"id":452,"data":1592,"type":217},{"text":1593},"One architecture decision can also respond to several requirements at once. Choosing an asynchronous processing boundary might improve responsiveness and failure isolation while introducing consistency, complexity, observability, and operational trade-offs.",{"id":456,"data":1595,"type":297},{"rows":1596,"title":1609,"layout":289,"columns":1610},[1597,1600,1603,1606],{"id":460,"label":1598,"values":1599},"One NFR → many ADRs",{"adr":463,"nfr":464,"validation":465},{"id":467,"label":1601,"values":1602},"Many NFRs → one ADR",{"adr":470,"nfr":471,"validation":472},{"id":474,"label":1604,"values":1605},"ADR without a classic NFR",{"adr":477,"nfr":478,"validation":479},{"id":481,"label":1607,"values":1608},"Requirement stable, ADR changes",{"adr":484,"nfr":485,"validation":486},"Why the relationship is not one-to-one",[1611,1613,1615],{"id":292,"label":1612},"Requirement side",{"id":295,"label":1614},"Decision side",{"id":494,"label":1616},"Validation side",{"id":497,"data":1618,"type":41},{"text":1619,"level":236},"A technology choice is not automatically a requirement",{"id":501,"data":1621,"type":217},{"text":1622},"A recurring architecture error is to write a preferred technology into the requirements layer and then treat the resulting design as inevitable.",{"id":505,"data":1624,"type":217},{"text":1625},"“The system must use PostgreSQL” can be a legitimate constraint if a contract, platform policy, compatibility requirement, licensing rule, organizational standard, or existing operational boundary actually mandates PostgreSQL. But if the real need is transactional consistency, structured querying, operational familiarity, or a specific recovery objective, the requirement should state that need and the technology selection should be recorded as a decision.",{"id":509,"data":1627,"type":289},{"content":1628,"stretched":42,"withHeadings":13},[1629,1633,1637,1641,1645,1649,1653],[1630,1631,1632],"Statement","Classification","Reason",[1634,1635,1636],"All tenant-scoped reads must enforce tenant isolation","Requirement \u002F security property","Describes a property that must hold",[1638,1639,1640],"Use PostgreSQL Row Level Security for selected tenant-scoped tables","Architecture decision","Chooses a mechanism intended to help satisfy the isolation property",[1642,1643,1644],"The deployment target must run in an approved EU-operated environment","Constraint \u002F NFR-like operating condition","Restricts where the system may operate",[1646,1647,1648],"Use provider X in region Y","Architecture \u002F deployment decision unless externally mandated","Selects a particular solution inside the allowed boundary",[1650,1651,1652],"95th-percentile API latency ≤ 300 ms under workload W","Quality requirement","Defines measurable performance behavior",[1654,1639,1655],"Introduce a cache for endpoint X","Selects a tactic intended to improve the measured behavior",{"id":540,"data":1657,"type":41},{"text":1658,"level":236},"An ADR is not proof that an NFR has been satisfied",{"id":544,"data":1660,"type":217},{"text":1661},"Decision documentation and system validation answer different questions. An ADR can show that performance, security, resilience, or maintainability were considered. It cannot by itself demonstrate that the delivered system actually achieves those properties.",{"id":548,"data":1663,"type":217},{"text":1664},"The proof must come from the validation method appropriate to the requirement: benchmark, load test, failure test, security test, architecture analysis, audit, inspection, operational telemetry, recovery exercise, user study, or another form of evidence.",{"id":552,"data":1666,"type":224},{"body":1667,"title":1668,"variant":442},"\u003Cstrong>ADR:\u003C\u002Fstrong> “We selected design X because it is expected to satisfy requirement R under assumptions A.”\u003Cbr>\u003Cstrong>Validation:\u003C\u002Fstrong> “Measured or analyzed evidence E shows whether the implemented system actually satisfies R.”","Do not confuse intent with evidence",{"id":557,"data":1670,"type":41},{"text":1671,"level":236},"When does an NFR become architecturally significant?",{"id":561,"data":1673,"type":217},{"text":1674},"Not every non-functional requirement deserves an architecture decision. The important subset is the requirements that materially shape the architecture or force trade-offs across the system.",{"id":565,"data":1676,"type":217},{"text":1677},"SEI literature uses the concept of \u003Cstrong>architecturally significant requirements\u003C\u002Fstrong> for requirements with far-reaching architectural effect. Quality attributes such as performance, reliability, security, and modifiability are frequent sources of such drivers, especially when they carry high business or mission value.",{"id":569,"data":1679,"type":436},{"steps":1680,"title":1699,"orientation":435},[1681,1684,1687,1690,1693,1696],{"label":1682,"description":1683},"1. Ask whether the requirement changes structure","Would different values force different components, boundaries, data paths or deployment topology?",{"label":1685,"description":1686},"2. Ask whether it constrains major technology choices","Does it eliminate otherwise viable implementation options?",{"label":1688,"description":1689},"3. Ask whether it creates cross-cutting behavior","Does it affect many components, teams, interfaces or lifecycle stages?",{"label":1691,"description":1692},"4. Ask whether it creates a difficult trade-off","Does improving this property materially affect another quality, cost, schedule, complexity or risk?",{"label":1694,"description":1695},"5. Ask whether failure is expensive","Would missing the requirement create material operational, security, regulatory, financial or product impact?",{"label":1697,"description":1698},"6. Record decisions only where the reasoning is worth preserving","Do not create ADRs for every local coding choice; preserve architecturally significant decisions and their rationale.","Architectural-significance test",{"id":592,"data":1701,"type":41},{"text":1702,"level":236},"A stronger architecture model: requirement → decision → implementation → validation",{"id":596,"data":1704,"type":217},{"text":1705},"The most useful connection between NFRs and ADRs is traceability. A requirement should be able to point to the architecture decisions that address it; an ADR should identify the drivers it responds to; implementation work should realize the decision; validation should return to the original requirement.",{"id":600,"data":1707,"type":436},{"steps":1708,"title":1732,"orientation":435},[1709,1712,1715,1718,1721,1723,1726,1729],{"label":1710,"description":1711},"Need \u002F business goal","Why the quality or constraint matters.",{"label":1713,"description":1714},"Requirement \u002F NFR","What the system must achieve or respect.",{"label":1716,"description":1717},"Architecture drivers","Which requirements are significant enough to shape the design.",{"label":1719,"description":1720},"Options","Plausible ways to address the driver.",{"label":616,"description":1722},"The selected choice, rationale, alternatives, trade-offs and consequences.",{"label":1724,"description":1725},"Implementation","Code, data model, infrastructure, interfaces and operational mechanisms that realize the decision.",{"label":1727,"description":1728},"Validation evidence","Tests, measurements, analysis or audits demonstrating whether the original requirement is actually satisfied.",{"label":1730,"description":1731},"Change \u002F supersession","New evidence or changed requirements can trigger a new ADR while preserving historical reasoning.","Architecture traceability chain",{"id":629,"data":1734,"type":41},{"text":1735,"level":236},"Implementation evidence: how I separate requirements and decisions in SenseFlow",{"id":633,"data":1737,"type":224},{"body":1738,"title":1739,"variant":230},"The following section describes my own SenseFlow project structure. It is implementation evidence for the separation in this article, not a claim that every team must use the same documentation model.","Original implementation \u002F project evidence",{"id":638,"data":1741,"type":217},{"text":1742},"In SenseFlow, the project Source of Truth explicitly places non-functional requirements inside the requirements structure together with dependencies, risks, assumptions, acceptance criteria, and a validation method. The documentation model separately defines decision integrity for significant decisions.",{"id":642,"data":1744,"type":217},{"text":1745},"For significant SenseFlow decisions, the recorded fields are \u003Cstrong>Decision, Reason, Alternatives, Trade-offs, Status, and Date \u002F Version\u003C\u002Fstrong>. Major architecture and product decisions are intended to remain historically traceable rather than being overwritten when the project evolves.",{"id":646,"data":1747,"type":217},{"text":1748},"SenseFlow also assigns different operational roles to Confluence and Jira. Confluence is the structured knowledge and decision environment; Jira manages actionable delivery work. Major Jira Epics should link back to the relevant product or requirements documentation. This preserves the chain from product intent through requirements and decisions into implementation rather than turning the backlog into the architecture Source of Truth.",{"id":650,"data":1750,"type":289},{"content":1751,"stretched":42,"withHeadings":13},[1752,1756,1760,1764,1767,1770,1774],[1753,1754,1755],"SenseFlow layer","What it contains","Role in ADR\u002FNFR separation",[1757,1758,1759],"Product \u002F requirement structure","Product goal, capability, epic, user story, acceptance criteria, technical tasks; requirements can include NFRs and validation method","Preserves what must be achieved and how success will be checked",[1761,1762,1763],"Decision integrity","Decision, reason, alternatives, trade-offs, status, date\u002Fversion","Preserves why an architecturally significant choice became authoritative",[666,1765,1766],"Requirements, architecture, research, decision records, risks, roadmap and supporting sources","Maintains conceptual and historical Source of Truth",[670,1768,1769],"Initiatives\u002Fgoals, epics, stories, tasks and delivery state","Executes approved work without becoming the conceptual Source of Truth",[1771,1772,1773],"Change management","Current state → new evidence → proposed change → impact → decision","Allows decisions to evolve without erasing the reasoning trail",[1775,1776,1777],"End-to-end traceability","Problem → need → value → product goal → requirement → implementation → validation","Keeps decision documentation connected to the actual product and evidence lifecycle",{"id":682,"data":1779,"type":224},{"body":1780,"title":1781,"variant":347},"A requirement and a decision can live close together without being collapsed into one record. The requirement remains the target; the decision remains the reasoning history; delivery work implements the decision; validation returns to the target.","What this implementation demonstrates",{"id":687,"data":1783,"type":41},{"text":1784,"level":236},"Enterprise project context: requirements should precede architecture choices",{"id":691,"data":1786,"type":217},{"text":1787},"The same separation is useful in enterprise-oriented project work. Architecture decisions made before requirements, risks, constraints, and acceptance conditions are sufficiently understood can turn preferences into false necessities.",{"id":695,"data":1789,"type":217},{"text":1790},"For Enterprise Aaasaasa 0.1, the relevant lesson is methodological rather than a claim about one particular ADR: requirements, architecture, validation, milestones, risk management, and acceptance belong to a connected delivery system. An architecture choice should remain traceable to the requirement or constraint it is intended to address.",{"id":699,"data":1792,"type":41},{"text":1793,"level":236},"Common failure modes when ADRs and NFRs are mixed",{"id":703,"data":1795,"type":289},{"content":1796,"stretched":42,"withHeadings":13},[1797,1801,1805,1809,1813,1817,1821,1825,1829],[1798,1799,1800],"Failure mode","What happens","Consequence",[1802,1803,1804],"Technology disguised as requirement","A preferred solution is written as “must use X” without establishing the underlying need","Alternatives are never evaluated and architecture becomes prematurely fixed",[1806,1807,1808],"NFR hidden only inside an ADR","The decision mentions a performance\u002Fsecurity target that is absent from the requirements baseline","The target is hard to validate, prioritize or manage independently",[1810,1811,1812],"ADR treated as proof","A documented choice is assumed to mean the requirement is satisfied","Architecture intent replaces measurement or verification",[1814,1815,1816],"Vague NFR","Words such as fast, scalable, secure or maintainable have no measurable scope","Different stakeholders can believe the same requirement means different things",[1818,1819,1820],"No alternatives recorded","The team records only the selected technology","Future maintainers cannot reconstruct why another option was rejected",[1822,1823,1824],"No supersession model","Old ADRs are edited or deleted when the architecture changes","Historical reasoning disappears and stale decisions can remain ambiguous",[1826,1827,1828],"Every implementation detail becomes an ADR","The repository fills with low-value records","Important architecture choices become difficult to find",[1830,1831,1832],"Backlog becomes architecture SoT","Jira tasks are treated as the only explanation of the system","Delivery state survives, but architectural rationale and quality drivers are lost",{"id":743,"data":1834,"type":41},{"text":1835,"level":236},"The ADR–NFR decision framework",{"id":747,"data":1837,"type":217},{"text":1838},"When a team encounters a new architecture concern, the following sequence helps determine what belongs in requirements, what belongs in an ADR, and what belongs in evidence.",{"id":751,"data":1840,"type":436},{"steps":1841,"title":1866,"orientation":435},[1842,1845,1848,1851,1854,1857,1860,1863],{"label":1843,"description":1844},"1. Is this a required property or external constraint?","If yes, write or reference the requirement before choosing a mechanism.",{"label":1846,"description":1847},"2. Can it be validated?","Define the scope, condition, metric, acceptance rule, analysis method or other evidence needed.",{"label":1849,"description":1850},"3. Is it architecturally significant?","Identify whether the requirement materially shapes structure, technology, data, deployment or cross-cutting trade-offs.",{"label":1852,"description":1853},"4. Are there meaningful alternatives?","Compare viable tactics or architecture options rather than jumping directly to a preferred technology.",{"label":1855,"description":1856},"5. Has a choice become authoritative?","Create or update the ADR with context, decision, rationale, alternatives, trade-offs, status and consequences.",{"label":1858,"description":1859},"6. Is the decision implemented?","Trace the ADR into design, tasks, code, configuration and operations.",{"label":1861,"description":1862},"7. Is the requirement satisfied?","Collect validation evidence against the requirement itself.",{"label":1864,"description":1865},"8. Did conditions change?","Re-evaluate the requirement and, when necessary, supersede the ADR without erasing history.","ADR–NFR classification test",{"id":780,"data":1868,"type":41},{"text":1869,"level":236},"What ADR and NFR are not",{"id":784,"data":1871,"type":297},{"rows":1872,"title":1885,"layout":289,"columns":1886},[1873,1875,1877,1879,1882],{"id":292,"label":1458,"values":1874},{"not":789,"why":790,"term":791},{"id":295,"label":616,"values":1876},{"not":794,"why":795,"term":796},{"id":798,"label":1727,"values":1878},{"not":800,"why":801,"term":802},{"id":804,"label":1880,"values":1881},"Backlog item",{"not":807,"why":808,"term":809},{"id":811,"label":1883,"values":1884},"Constraint",{"not":814,"why":815,"term":816},"Common category errors",[1887,1889,1891],{"id":820,"label":1888},"Concept",{"id":823,"label":1890},"It is not",{"id":826,"label":1632},{"id":828,"data":1893,"type":41},{"text":1894,"level":236},"What would change this answer?",{"id":832,"data":1896,"type":217},{"text":1897},"The terminology can evolve. ISO\u002FIEC\u002FIEEE 29148:2018 remains the current published requirements-engineering standard as of 8 October 2026, but ISO lists a Draft International Standard intended to replace it. If the new edition changes relevant terminology or requirements guidance, the version-specific references in this article should be updated.",{"id":836,"data":1899,"type":217},{"text":1900},"ADR templates can also evolve without changing the central distinction. Michael Nygard’s minimal template, MADR, organization-specific templates, architecture knowledge tools, or structured decision databases can all record decisions. The durable question is whether the record preserves enough context and rationale to understand an architecturally significant choice.",{"id":840,"data":1902,"type":217},{"text":1903},"The distinction would only collapse if an organization deliberately chose a combined artifact that stores both requirement and decision data in one document. Even then, the semantic roles remain different: one field states the required outcome or constraint; another records the chosen response.",{"id":844,"data":1905,"type":41},{"text":1906,"level":236},"Limitations",{"id":848,"data":1908,"type":217},{"text":1909},"This article uses \u003Cstrong>NFR\u003C\u002Fstrong> as practical shorthand. Some engineering methods prefer terms such as quality attribute requirement, quality requirement, system quality, constraint, service-level objective, or architecturally significant requirement. Those terms are not perfectly interchangeable, and project terminology should be explicit.",{"id":852,"data":1911,"type":217},{"text":1912},"Not every requirement can be reduced to a single numeric threshold. Security, safety, maintainability, interoperability, usability, explainability, portability, and governance can require combinations of scenarios, structural rules, analyses, process controls, and qualitative evidence. “Measurable” should mean verifiable enough for the decision, not artificially numeric.",{"id":856,"data":1914,"type":217},{"text":1915},"Not every architecture decision needs a formal ADR. The documentation cost should be proportional to architectural significance, longevity, uncertainty, trade-off complexity, and the cost of losing the rationale.",{"id":860,"data":1917,"type":41},{"text":1918,"level":236},"Conclusion",{"id":864,"data":1920,"type":217},{"text":1921},"ADR and NFR belong to different layers of architecture work. \u003Cstrong>The NFR defines a quality target, constraint, or operating condition. The ADR records a significant architectural response to one or more drivers.\u003C\u002Fstrong>",{"id":868,"data":1923,"type":217},{"text":1924},"Keeping those layers separate makes architecture easier to reason about. Requirements can be validated independently of technology. Decisions can be superseded without rewriting history. Alternatives and trade-offs remain visible. Delivery work can be traced back to architectural intent. Evidence can show whether the resulting system actually satisfies the requirement.",{"id":872,"data":1926,"type":217},{"text":1927},"The strongest chain is therefore not “NFR → ADR → done.” It is \u003Cstrong>need → requirement → architectural drivers → options → decision → implementation → validation → change\u003C\u002Fstrong>. That chain turns architecture documentation from static paperwork into a testable record of why the system has the shape it has.",{"id":876,"data":1929,"type":41},{"text":878,"level":236},{"id":880,"data":1931,"type":880},{"items":1932,"title":1954},[1933,1936,1939,1942,1945,1948,1951],{"id":884,"answer":1934,"question":1935},"No. An NFR states a required quality, constraint, or operating condition. An ADR records an architecturally significant choice made in response to requirements, constraints, risks and trade-offs.","Is an ADR a non-functional requirement?",{"id":888,"answer":1937,"question":1938},"No. Only requirements that materially influence architecture need architecture-level decisions worth preserving. One NFR can also drive several ADRs, and one ADR can respond to several requirements.","Should every NFR have an ADR?",{"id":892,"answer":1940,"question":1941},"Only when PostgreSQL is genuinely imposed as an external constraint. Otherwise the underlying need should be expressed first, and selecting PostgreSQL should normally be treated as an architecture decision.","Can “use PostgreSQL” be an NFR?",{"id":896,"answer":1943,"question":1944},"No. An ADR records intent and reasoning. The requirement is validated through appropriate evidence such as testing, measurement, analysis, audit or operational telemetry.","Does an ADR prove that a performance or security requirement is met?",{"id":900,"answer":1946,"question":1947},"At minimum, an ADR should make the context and decision clear. Common structures also include status and consequences. Teams can add alternatives, rationale, trade-offs, requirement links, evidence, owners, dates and supersession relationships.","What should an ADR contain?",{"id":904,"answer":1949,"question":1950},"A requirement is architecturally significant when it materially shapes system structure, technology, data flows, deployment, cross-cutting behavior or difficult quality trade-offs, especially when failure carries high business or mission impact.","What makes an NFR architecturally significant?",{"id":908,"answer":1952,"question":1953},"Usually no. A replacement decision should normally supersede the old record so the historical reasoning remains traceable.","Should an old ADR be deleted when the architecture changes?","ADR vs NFR",{"id":913,"data":1956,"type":41},{"text":1957,"level":236},"Glossary",{"id":917,"data":1959,"type":917},{"title":1960,"entries":1961},"Core architecture terms",[1962,1964,1967,1969,1972,1974,1977,1980],{"term":922,"anchor":292,"definition":1963},"Non-functional requirement: practical shorthand for a required system quality, constraint, or operating condition; exact terminology varies by method and standard.",{"term":1965,"anchor":926,"definition":1966},"Quality attribute requirement","A requirement describing a quality property the system is expected to exhibit under defined conditions, such as performance, availability, security, reliability or modifiability.",{"term":929,"anchor":295,"definition":1968},"A durable record of an architecturally significant decision and enough context to understand why the choice was made and what consequences follow.",{"term":1970,"anchor":933,"definition":1971},"Architecturally Significant Requirement (ASR)","A requirement with sufficiently far-reaching architectural impact that it materially influences the system design.",{"term":1883,"anchor":811,"definition":1973},"A condition that restricts the solution space, including external policy, regulation, platform, compatibility, contractual or organizational boundaries.",{"term":1975,"anchor":939,"definition":1976},"Trade-off","A design relationship in which improving one objective, property or cost dimension can worsen another.",{"term":1978,"anchor":494,"definition":1979},"Validation","Evidence-producing work used to determine whether the implemented system satisfies the stated requirement under the relevant conditions.",{"term":1981,"anchor":946,"definition":1982},"Superseded ADR","A historical decision record that has been replaced by a newer authoritative decision while remaining available for traceability.",{"id":949,"data":1984,"type":41},{"text":1985,"level":236},"Primary sources and implementation evidence",{"id":953,"data":1987,"type":217},{"text":1988},"This article separates current standards from project implementation evidence. ISO\u002FIEC\u002FIEEE 29148:2018 remains current as of 8 October 2026 but is marked for revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are current published editions. SenseFlow is original project evidence for the traceability and decision-integrity model described above.",{"id":957,"data":1990,"type":965},{"link":959,"meta":1991},{"image":1992,"title":963,"description":1993},{"url":962},"Current published requirements-engineering standard. ISO states that the 2018 edition was reviewed and confirmed in 2024 and is expected to be replaced by the DIS now under development.",{"id":967,"data":1995,"type":965},{"link":969,"meta":1996},{"image":1997,"title":972,"description":1998},{"url":962},"Draft International Standard currently under development and intended to replace ISO\u002FIEC\u002FIEEE 29148:2018.",{"id":975,"data":2000,"type":965},{"link":977,"meta":2001},{"image":2002,"title":2003,"description":2004},{"url":962},"ISO\u002FIEC 25010:2023 — Product Quality Model","Current product-quality model with nine quality characteristics used to specify, measure and evaluate ICT and software product quality.",{"id":983,"data":2006,"type":965},{"link":985,"meta":2007},{"image":2008,"title":2009,"description":2010},{"url":962},"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description","Current architecture-description standard. It specifies architecture-description concepts and conformance requirements without prescribing one recording format, notation, process or tool.",{"id":991,"data":2012,"type":965},{"link":993,"meta":2013},{"image":2014,"title":996,"description":2015},{"url":962},"Original influential ADR article describing lightweight records centered on context, decision, status and consequences, with superseded decisions retained for historical understanding.",{"id":999,"data":2017,"type":965},{"link":1001,"meta":2018},{"image":2019,"title":1004,"description":2020},{"url":962},"SEI report explaining how quality attribute requirements and business goals drive software architecture and why architecturally significant requirements need explicit elicitation.",{"id":1007,"data":2022,"type":965},{"link":1009,"meta":2023},{"image":2024,"title":1012,"description":2025},{"url":962},"SEI overview connecting non-functional\u002Fquality attributes with architecture, scenarios, trade-offs and objective system evaluation.",{"id":1015,"data":2027,"type":965},{"link":1017,"meta":2028},{"image":2029,"title":1020,"description":2030},{"url":962},"Architecture design method based on functional requirements, quality attribute requirements and constraints, with architectural tactics and patterns selected to satisfy quality scenarios.",{"id":1023,"data":2032,"type":965},{"link":1025,"meta":2033},{"image":2034,"title":1028,"description":2035},{"url":962},"Architecture-documentation guidance emphasizing relevant views and the recording of necessary design decisions as part of architecture work.","2.31.0","ADR vs NFR explained: learn how system quality requirements drive architecture decisions, how ADRs record trade-offs, and why validation stays separate.","Post erfolgreich abgerufen",{"items":2040,"source":2069,"manualIds":2070,"manualMatchedIds":2071},[2041,2048,2055,2062],{"id":2042,"slug":2043,"title":2044,"excerpt":2045,"featuredImage":2046,"publishedAt":2047},"435","ultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks","Ultimativer Leitfaden zu Akzeptanzkriterien für die LLM-Einführung in Enterprise-Playbooks","Meistere die Kunst, präzise Akzeptanzkriterien zu definieren, um eine erfolgreiche LLM-Integration in Ihrer Unternehmensumgebung sicherzustellen. Dieser umfassende Leitfaden bietet umsetzbare Frameworks, Beispiele und Best Practices, die auf playbook-gesteuerte Adoption zugeschnitten sind.","\u002Fuploads\u002F2026\u002F09\u002Fultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks-1788540267775-zgr6mm.webp","2026-09-06T11:50:00.000Z",{"id":2049,"slug":2050,"title":2051,"excerpt":2052,"featuredImage":2053,"publishedAt":2054},"455","zbt-z8102ax-dual-sim-failover-test","ZBT Z8102AX Dual-SIM-Failover: Was funktioniert, was fehlt und was eine bessere Firmware benötigt","Der ZBT Z8102AX ist ein Dual-SIM-5G-OpenWrt-Router, aber Dual-SIM-Hardware allein ist nicht dasselbe wie ein intelligentes Failover. Der Router erkennt die SIM und verbindet sich erfolgreich, aber die automatische Umschaltung, die Modem-Wiederherstellung, signalbasierte Entscheidungen und eine saubere Failover-Logik erfordern noch eingehendere Tests.","\u002Fuploads\u002F2026\u002F06\u002Fopenwrt-router-review-dual-sim-03-1781620592829-7t77j7.webp","2026-06-16T10:40:00.000Z",{"id":2056,"slug":2057,"title":2058,"excerpt":2059,"featuredImage":2060,"publishedAt":2061},"481","generative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing","Generative KI erklärt: Modelle, Retrieval, Tools und Anwendungen sind nicht dasselbe","Generative KI ist mehr als ein Modell. Erfahren Sie, wie Modelle, Retrieval, Tools, Kontext, Runtimes und Anwendungen in Produktions-KI-Systemen zusammenwirken.","\u002Fuploads\u002F2026\u002F10\u002Fgenerative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing-1791475411822-pp0dvz.webp","2026-10-08T12:00:00.000Z",{"id":2063,"slug":2064,"title":2065,"excerpt":2066,"featuredImage":2067,"publishedAt":2068},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Meistern des SEO-Workflows: Essenzielle Optimierungsstrategien für organisches Wachstum","Ein strukturierter SEO-Workflow ist entscheidend für nachhaltiges organisches Wachstum. Lerne die zehn grundlegenden Strategien, von der Keyword-Recherche und technischen Optimierung bis hin zur Content-Qualität und Performance-Analyse.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z","fallback",[],[]]