[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:fr":3,"public-menus:all":38,"post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:fr":205,"related:post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:fr:1":2040},{"statusCode":4,"data":5,"message":37},200,{"tenantId":6,"lang":7,"defaultLang":8,"siteUrl":9,"contactEmail":10,"brandName":11,"logoUrl":12,"siteName":11,"siteDescription":13,"ogImage":10,"robotsIndex":14,"socialLinks":10,"reservedSlugs":10,"seoPolicy":15},"stajic","fr","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":16,"relatedContent":17,"crossDomainLinks":18},{"logoUrl":12},{"enabled":14},[19,22,25,28,31,34],{"url":20,"label":21,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":23,"label":24,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":26,"label":27,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.com","bazify.com",{"url":29,"label":30,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.de","bazify.de",{"url":32,"label":33,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.at","bazify.at",{"url":35,"label":36,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[39,45],{"id":40,"name":41,"location":42,"isActive":14,"isDefault":43,"items":44},1,"main-navigation","header",false,[],{"id":46,"name":47,"location":48,"isActive":14,"isDefault":14,"items":49},4,"main-menu","sidebar",[50,66,79,93,103,118,133],{"id":51,"title":52,"url":60,"target":61,"icon":62,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":64,"portfolioId":10,"children":65},"item-18",{"de":53,"en":54,"es":55,"fr":56,"it":54,"ru":57,"sr":58,"zh":59},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":67,"title":68,"url":75,"target":61,"icon":76,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":77,"portfolioId":10,"children":78},"item-22",{"de":69,"en":69,"es":70,"fr":69,"it":71,"ru":72,"sr":73,"zh":74},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":80,"title":81,"url":89,"target":61,"icon":90,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":91,"portfolioId":10,"children":92},"item-19",{"de":82,"en":83,"es":84,"fr":83,"it":85,"ru":86,"sr":87,"zh":88},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":94,"title":95,"url":99,"target":61,"icon":100,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":101,"portfolioId":10,"children":102},"item-23",{"de":96,"en":96,"es":96,"fr":96,"it":96,"ru":97,"sr":97,"zh":98},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":104,"title":105,"url":114,"target":61,"icon":115,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":116,"portfolioId":10,"children":117},"item-32",{"de":106,"en":107,"es":108,"fr":109,"it":110,"ru":111,"sr":112,"zh":113},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":119,"title":120,"url":129,"target":61,"icon":130,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":131,"portfolioId":10,"children":132},"item-20",{"de":121,"en":122,"es":123,"fr":124,"it":125,"ru":126,"sr":127,"zh":128},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":134,"title":135,"url":144,"target":61,"icon":145,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":147},"item-21",{"de":136,"en":137,"es":138,"fr":139,"it":140,"ru":141,"sr":142,"zh":143},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[148,161,175,181,193],{"id":149,"title":150,"url":144,"target":61,"icon":159,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":160},"item-24",{"de":151,"en":152,"es":153,"fr":154,"it":155,"ru":156,"sr":157,"zh":158},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":162,"title":163,"url":171,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":174},"item-29",{"de":164,"en":165,"es":166,"fr":167,"it":168,"ru":169,"sr":170,"zh":143},"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":176,"title":177,"url":179,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":180},"item-28",{"de":178,"en":178,"es":178,"fr":178,"it":178,"ru":178,"sr":178,"zh":178},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":182,"title":183,"url":191,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":192},"item-27",{"de":184,"en":185,"es":186,"fr":187,"it":188,"ru":189,"sr":190,"zh":185},"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":194,"title":195,"url":203,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":204},"item-31",{"de":196,"en":197,"es":198,"fr":199,"it":200,"ru":201,"sr":202,"zh":197},"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":206,"message":2039},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":1033,"featuredImage":1034,"featuredImageAlt":1035,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1036,"publishedAt":1037,"createdAt":1038,"updatedAt":1039,"seoLocalePaths":1040,"categories":1049,"author":1070,"translations":1075},"482","ADR vs NFR : les décisions d'architecture et la qualité du système ne sont pas la même chose","adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u003Cp>Une \u003Cstrong>exigence non fonctionnelle (ENF)\u003C\u002Fstrong> décrit une qualité, une contrainte ou une condition d'exploitation que le système est censé satisfaire. Un \u003Cstrong>enregistrement de décision d'architecture (EDA)\u003C\u002Fstrong> consigne un choix architecturalement significatif effectué en réponse à des exigences, des contraintes, des risques et des compromis. Ils sont liés, mais ils ne sont pas interchangeables : une ENF énonce ce qui doit être vrai ; un EDA explique ce qui a été décidé, pourquoi, et avec quelles conséquences.\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\">Réponse directe\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>ENF = qualité ou contrainte système requise. EDA = décision d'architecture consignée.\u003C\u002Fstrong> Un objectif de latence, un objectif de disponibilité, une règle d'isolation, une restriction de déploiement ou une exigence de maintenabilité peuvent influencer l'architecture. Un EDA consigne ensuite un choix significatif effectué pour répondre à un ou plusieurs de ces moteurs. L'EDA ne remplace pas l'exigence, et l'existence d'un EDA ne prouve pas que l'exigence a été satisfaite.\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\">Note sur la terminologie et les normes\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Le terme \u003Cstrong>ENF\u003C\u002Fstrong> est largement utilisé mais n'est pas parfaitement normalisé. Cet article l'utilise comme raccourci pratique pour les exigences de qualité et les contraintes pertinentes. Les normes actuelles ont été revérifiées le \u003Cstrong>8 octobre 2026\u003C\u002Fstrong> : l'ISO\u002FIEC\u002FIEEE 29148:2018 reste en vigueur mais est en cours de révision ; l'ISO\u002FIEC 25010:2023 et l'ISO\u002FIEC\u002FIEEE 42010:2022 sont les éditions publiées actuelles citées ici.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Sommaire\">\u003Cstrong class=\"editorjs-toc__title\">Sommaire\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\">Quelle est la différence entre une ENF et un EDA ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">Qu'est-ce qu'une ENF en termes architecturaux précis ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-16\" class=\"editorjs-toc__link\">Qu'est-ce qu'un enregistrement de décision d'architecture ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-21\" class=\"editorjs-toc__link\">L'exemple le plus simple : exigence de latence → décision d'architecture\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-26\" class=\"editorjs-toc__link\">Les ENF et les ADR ont généralement une relation plusieurs-à-plusieurs\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-30\" class=\"editorjs-toc__link\">Un choix technologique n'est pas automatiquement une exigence\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-34\" class=\"editorjs-toc__link\">Un ADR n'est pas la preuve qu'une ENF a été satisfaite\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-38\" class=\"editorjs-toc__link\">Quand une exigence non fonctionnelle devient-elle architecturally significant ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-42\" class=\"editorjs-toc__link\">Un modèle d'architecture plus robuste : exigence → décision → implémentation → validation\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-45\" class=\"editorjs-toc__link\">Preuve d'implémentation : comment je sépare les exigences et les décisions dans SenseFlow\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-52\" class=\"editorjs-toc__link\">Contexte de projet d'entreprise : les exigences devraient précéder les choix d'architecture\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-55\" class=\"editorjs-toc__link\">Modes de défaillance courants lorsque les ADR et les NFR sont mélangés\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-57\" class=\"editorjs-toc__link\">Le cadre de décision ADR–NFR\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-60\" class=\"editorjs-toc__link\">Ce que l'ADR et la NFR ne sont pas\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-62\" class=\"editorjs-toc__link\">Qu'est-ce qui changerait cette réponse ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-66\" class=\"editorjs-toc__link\">Limites\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-70\" class=\"editorjs-toc__link\">Conclusion\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\">Glossaire\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Sources primaires et preuves de mise en œuvre\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-5\">Quelle est la différence entre une ENF et un EDA ?\u003C\u002Fh2>\n\u003Cp>La distinction la plus simple est grammaticale. Une exigence décrit une condition que le système doit satisfaire. Un enregistrement de décision décrit un choix effectué par l'équipe.\u003C\u002Fp>\n\u003Cp>Par exemple, \u003Cstrong>« L'API doit renvoyer 95 % des requêtes de lecture en moins de 300 ms sous la charge de référence convenue »\u003C\u002Fstrong> est une exigence de qualité. \u003Cstrong>« Utiliser un cache read-through pour cette charge de travail car le chemin mesuré en base de données seule ne peut pas atteindre l'objectif de latence sans coût inacceptable »\u003C\u002Fstrong> est une décision d'architecture.\u003C\u002Fp>\n\u003Cp>La première affirmation reste valide même si l'implémentation change. La seconde peut ensuite être remplacée par une autre décision si la charge de travail, la technologie, le modèle de coût ou les preuves changent.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">ENF et EDA répondent à des questions différentes\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\">ENF \u002F exigence de qualité\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\">EDA \u002F décision d'architecture\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\">Question principale\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\">Contenu typique\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\">Rôle dans le cycle de vie\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\">Qu'est-ce qui le prouve ?\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\">Quand cela change\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\">Qu'est-ce qu'une ENF en termes architecturaux précis ?\u003C\u002Fh2>\n\u003Cp>« Exigence non fonctionnelle » est une étiquette pratique du secteur, mais elle peut masquer plusieurs types d'énoncés différents. Dans le travail d'architecture, la distinction utile est entre \u003Cstrong>comportement fonctionnel\u003C\u002Fstrong>, \u003Cstrong>exigences de qualité\u003C\u002Fstrong> et \u003Cstrong>contraintes\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>L'ISO\u002FIEC 25010:2023 fournit un modèle de qualité de produit avec neuf caractéristiques et sous-caractéristiques qui peuvent être utilisées pour spécifier et évaluer la qualité des produits TIC et logiciels. Le travail d'architecture du SEI traite de même les exigences d'attributs de qualité comme des moteurs majeurs de l'architecture logicielle.\u003C\u002Fp>\n\u003Cp>Une ENF utile n'est donc pas « le système devrait être rapide » ou « la plateforme doit être sécurisée ». Ces énoncés nomment des aspirations. Une exigence motrice d'architecture devrait rendre la propriété attendue suffisamment testable pour que les alternatives de conception et les preuves ultérieures puissent être évaluées par rapport à elle.\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\">Énoncé faible\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Forme d'exigence plus utile\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Pourquoi la différence compte\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'API doit être rapide\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Pour la charge de travail W, 95 % de l'opération X se termine en T millisecondes\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Définit la charge de travail, l'opération, la métrique et le seuil\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le service doit être disponible\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le service S atteint un objectif de disponibilité convenu sur la fenêtre de mesure M, en excluant les conditions de maintenance explicitement définies\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Rend la disponibilité mesurable et définit le périmètre\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les données des locataires doivent être sécurisées\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Une requête authentifiée pour le locataire A ne doit jamais récupérer ou modifier les données du locataire B via les chemins applicatifs pris en charge\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Transforme un objectif de sécurité vague en propriété d'isolation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le système devrait évoluer\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le système prend en charge la charge de travail W à la concurrence C tout en respectant les seuils de latence et de taux d'erreur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Relie l'échelle à un comportement de service mesurable\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nous avons besoin de PostgreSQL\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Pas une ENF en soi ; énoncer d'abord les qualités de persistance requises ou la contrainte externe\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un choix technologique est normalement une solution, pas l'exigence qu'il est censé satisfaire\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\">Une exigence devrait décrire le besoin avant le mécanisme\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Si « utiliser Kubernetes », « utiliser PostgreSQL », « utiliser des microservices » ou « utiliser la recherche vectorielle » apparaît comme l'exigence, demandez s'il s'agit vraiment d'une contrainte externe ou si la solution a été écrite avant que le besoin de qualité sous-jacent ne soit explicité.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-16\">Qu'est-ce qu'un enregistrement de décision d'architecture ?\u003C\u002Fh2>\n\u003Cp>Un enregistrement de décision d'architecture est un compte rendu compact d'une décision d'architecture importante. La formulation originale d'ADR de Michael Nygard met l'accent sur le \u003Cstrong>contexte\u003C\u002Fstrong>, la \u003Cstrong>décision\u003C\u002Fstrong>, son \u003Cstrong>statut\u003C\u002Fstrong> et les \u003Cstrong>conséquences\u003C\u002Fstrong> qui en résultent.\u003C\u002Fp>\n\u003Cp>L'objet important est la décision, pas le modèle. Différentes équipes utilisent différents formats d'ADR. Un enregistrement plus riche peut également conserver les alternatives, les critères de décision, les compromis, les preuves, les liens vers les exigences et la date ou la version à partir de laquelle la décision s'applique.\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC\u002FIEEE 42010:2022 est plus large que la pratique des ADR : il spécifie des exigences pour les descriptions d'architecture et leurs concepts, tout en ne prescrivant explicitement aucun processus, notation, outil, format ou support pour consigner une description d'architecture. Un ADR est donc une technique pratique de consignation des décisions, et non un format imposé par l'ISO 42010.\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\">Champ de l'ADR\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ce qu'il préserve\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Pourquoi c'est important\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contexte\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le problème, les forces, les exigences, les hypothèses et l'environnement entourant le choix\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les lecteurs futurs peuvent reconstituer pourquoi un choix était nécessaire\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Décision\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le choix devenu faisant autorité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sépare l'option retenue de la discussion\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Statut\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Proposé, accepté, rejeté, obsolète, remplacé ou un autre état contrôlé\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Empêche les anciennes décisions de rester silencieusement actives\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alternatives\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les autres options viables envisagées\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Montre que la solution retenue n'était pas la seule imaginable\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Justification \u002F compromis\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Pourquoi l'option a été retenue et ce à quoi elle renonce\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Rend le raisonnement architectural inspectable\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Conséquences\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Effets positifs et négatifs attendus, travaux de suivi, risques\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Relie un choix local à l'impact sur le système\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Date \u002F version\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quand la décision est devenue valide\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Soutient la traçabilité historique et le remplacement ultérieur\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-21\">L'exemple le plus simple : exigence de latence → décision d'architecture\u003C\u002Fh2>\n\u003Cp>Supposons qu'un product owner et une équipe d'ingénierie conviennent qu'un point de terminaison de recherche doit renvoyer la première page de résultats en moins de 400 ms au 95e centile sous une charge de référence définie.\u003C\u002Fp>\n\u003Cp>Cette cible n'est pas un ADR. C'est une exigence de qualité. Le travail d'architecture commence en demandant quelle conception peut la satisfaire compte tenu des autres contraintes du système.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">De l'exigence à la preuve\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. Énoncer l'exigence\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Définir la cible de qualité, la charge, la portée, le seuil et la méthode de validation.\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. Identifier la signification architecturale\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Déterminer si l'exigence influence matériellement la structure, la technologie, le déploiement, le flux de données ou le modèle opérationnel.\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. Évaluer les options\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Comparer des alternatives telles que l'indexation, la mise en cache, la dénormalisation, le travail asynchrone, le partitionnement ou une architecture de requête différente.\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. Consigner la décision\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Capturer le choix d'architecture retenu, la justification, les alternatives, les compromis, le statut et les conséquences dans un 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. Mettre en œuvre\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Transformer la décision en code, infrastructure, configuration et comportement opérationnel.\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. Valider\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Mesurer le système réel par rapport à l'exigence initiale. Le résultat du test valide l'ENF ; l'ADR seul ne le fait pas.\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\">Où s'arrête l'exemple simple\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Les systèmes réels ont rarement une seule exigence et une seule décision. La performance peut se négocier contre le coût, la cohérence, l'exploitabilité, la sécurité, la maintenabilité, la consommation d'énergie ou le risque de livraison. Le modèle utile est donc un graphe de traçabilité, et non une correspondance biunivoque.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-26\">Les ENF et les ADR ont généralement une relation plusieurs-à-plusieurs\u003C\u002Fh2>\n\u003Cp>Une exigence de qualité peut entraîner plusieurs décisions d'architecture. Une exigence d'isolation des locataires, par exemple, peut influencer la propagation de l'identité, le périmètre de la base de données, la conception des tâches en arrière-plan, les clés de cache, la journalisation d'audit et l'outillage administratif.\u003C\u002Fp>\n\u003Cp>Une décision d'architecture peut aussi répondre à plusieurs exigences à la fois. Choisir une frontière de traitement asynchrone peut améliorer la réactivité et l'isolation des défaillances tout en introduisant des compromis de cohérence, de complexité, d'observabilité et d'exploitation.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Pourquoi la relation n'est pas biunivoque\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\">Côté exigence\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\">Côté décision\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\">Côté validation\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\">Une ENF → plusieurs ADR\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\">Plusieurs ENF → un 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 sans ENF classique\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\">Exigence stable, ADR qui change\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\">Un choix technologique n'est pas automatiquement une exigence\u003C\u002Fh2>\n\u003Cp>Une erreur d'architecture récurrente consiste à inscrire une technologie préférée dans la couche des exigences, puis à traiter la conception qui en résulte comme inévitable.\u003C\u002Fp>\n\u003Cp>« Le système doit utiliser PostgreSQL » peut être une contrainte légitime si un contrat, une politique de plateforme, une exigence de compatibilité, une règle de licence, une norme organisationnelle ou une frontière opérationnelle existante impose réellement PostgreSQL. Mais si le besoin réel est la cohérence transactionnelle, l'interrogation structurée, la familiarité opérationnelle ou un objectif de reprise spécifique, l'exigence devrait énoncer ce besoin et la sélection technologique devrait être consignée comme une décision.\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\">Énoncé\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Classification\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Raison\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Toutes les lectures limitées à un locataire doivent appliquer l'isolation des locataires\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Exigence \u002F propriété de sécurité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Décrit une propriété qui doit être respectée\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Utiliser la sécurité au niveau des lignes de PostgreSQL pour certaines tables limitées à un locataire\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Décision d'architecture\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Choisit un mécanisme destiné à aider à satisfaire la propriété d'isolation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La cible de déploiement doit s'exécuter dans un environnement approuvé exploité dans l'UE\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contrainte \u002F condition d'exploitation de type ENF\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Restreint le lieu où le système peut fonctionner\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Utiliser le fournisseur X dans la région Y\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Décision d'architecture \u002F de déploiement, sauf si imposée de l'extérieur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sélectionne une solution particulière à l'intérieur de la frontière autorisée\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Latence de l'API au 95e centile ≤ 300 ms sous la charge W\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Exigence de qualité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Définit un comportement de performance mesurable\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Introduire un cache pour le point de terminaison X\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Décision d'architecture\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sélectionne une tactique destinée à améliorer le comportement mesuré\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-34\">Un ADR n'est pas la preuve qu'une ENF a été satisfaite\u003C\u002Fh2>\n\u003Cp>La documentation des décisions et la validation du système répondent à des questions différentes. Un ADR peut montrer que la performance, la sécurité, la résilience ou la maintenabilité ont été prises en compte. Il ne peut pas, à lui seul, démontrer que le système livré atteint réellement ces propriétés.\u003C\u002Fp>\n\u003Cp>La preuve doit provenir de la méthode de validation appropriée à l'exigence : benchmark, test de charge, test de défaillance, test de sécurité, analyse d'architecture, audit, inspection, télémétrie opérationnelle, exercice de reprise, étude utilisateur ou une autre forme de preuve.\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\">Ne pas confondre intention et preuve\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>ADR :\u003C\u002Fstrong> « Nous avons choisi la conception X parce qu'elle est censée satisfaire l'exigence R sous les hypothèses A. »\u003Cbr>\u003Cstrong>Validation :\u003C\u002Fstrong> « La preuve mesurée ou analysée E montre si le système implémenté satisfait réellement R. »\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-38\">Quand une exigence non fonctionnelle devient-elle architecturally significant ?\u003C\u002Fh2>\n\u003Cp>Toutes les exigences non fonctionnelles ne méritent pas une décision d'architecture. Le sous-ensemble important est constitué des exigences qui façonnent matériellement l'architecture ou qui imposent des compromis à l'échelle du système.\u003C\u002Fp>\n\u003Cp>La littérature du SEI utilise le concept d'\u003Cstrong>architecturally significant requirements\u003C\u002Fstrong> pour les exigences ayant un effet architectural de grande portée. Les attributs de qualité tels que la performance, la fiabilité, la sécurité et la modifiabilité sont des sources fréquentes de tels moteurs, en particulier lorsqu'ils portent une valeur métier ou de mission élevée.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Test de signification architecturale\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. Demander si l'exigence modifie la structure\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Des valeurs différentes imposeraient-elles des composants, des frontières, des chemins de données ou une topologie de déploiement différents ?\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. Demander si elle contraint des choix technologiques majeurs\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Élimine-t-elle des options d'implémentation autrement viables ?\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. Demander si elle crée un comportement transversal\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Affecte-t-elle de nombreux composants, équipes, interfaces ou étapes du cycle de vie ?\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. Demander si elle crée un compromis difficile\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Améliorer cette propriété affecte-t-il matériellement une autre qualité, le coût, le calendrier, la complexité ou le risque ?\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. Demander si l'échec est coûteux\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Manquer l'exigence créerait-il un impact opérationnel, de sécurité, réglementaire, financier ou produit matériel ?\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. Enregistrer les décisions uniquement là où le raisonnement mérite d'être conservé\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Ne créez pas d'ADR pour chaque choix de codage local ; conservez les décisions architecturalement significatives et leur justification.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-42\">Un modèle d'architecture plus robuste : exigence → décision → implémentation → validation\u003C\u002Fh2>\n\u003Cp>Le lien le plus utile entre les NFR et les ADR est la traçabilité. Une exigence devrait pouvoir pointer vers les décisions d'architecture qui la traitent ; un ADR devrait identifier les moteurs auxquels il répond ; le travail d'implémentation devrait réaliser la décision ; la validation devrait revenir à l'exigence d'origine.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Chaîne de traçabilité architecturale\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\">Besoin \u002F objectif métier\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Pourquoi la qualité ou la contrainte importe.\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\">Exigence \u002F NFR\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Ce que le système doit atteindre ou respecter.\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\">Moteurs d'architecture\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Quelles exigences sont suffisamment significatives pour façonner la conception.\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\">Options\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Façons plausibles de traiter le moteur.\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\">Le choix sélectionné, la justification, les alternatives, les compromis et les conséquences.\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\">Implémentation\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Code, modèle de données, infrastructure, interfaces et mécanismes opérationnels qui réalisent la décision.\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\">Preuve de validation\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Tests, mesures, analyses ou audits démontrant si l'exigence d'origine est réellement satisfaite.\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\">Changement \u002F remplacement\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">De nouvelles preuves ou des exigences modifiées peuvent déclencher un nouvel ADR tout en préservant le raisonnement historique.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-45\">Preuve d'implémentation : comment je sépare les exigences et les décisions dans SenseFlow\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\">Preuve d'implémentation \u002F de projet originale\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">La section suivante décrit la structure de mon propre projet SenseFlow. Il s'agit d'une preuve d'implémentation pour la séparation présentée dans cet article, et non d'une affirmation que chaque équipe doit utiliser le même modèle de documentation.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>Dans SenseFlow, la Source de Vérité du projet place explicitement les exigences non fonctionnelles à l'intérieur de la structure des exigences, aux côtés des dépendances, des risques, des hypothèses, des critères d'acceptation et d'une méthode de validation. Le modèle de documentation définit séparément l'intégrité des décisions pour les décisions significatives.\u003C\u002Fp>\n\u003Cp>Pour les décisions significatives de SenseFlow, les champs enregistrés sont \u003Cstrong>Décision, Raison, Alternatives, Compromis, Statut et Date \u002F Version\u003C\u002Fstrong>. Les décisions majeures d'architecture et de produit sont destinées à rester historiquement traçables plutôt que d'être écrasées lorsque le projet évolue.\u003C\u002Fp>\n\u003Cp>SenseFlow attribue également des rôles opérationnels différents à Confluence et Jira. Confluence est l'environnement structuré de connaissances et de décisions ; Jira gère le travail de livraison actionnable. Les Épopées Jira majeures devraient renvoyer à la documentation produit ou d'exigences pertinente. Cela préserve la chaîne allant de l'intention produit à travers les exigences et les décisions jusqu'à l'implémentation, plutôt que de transformer le backlog en Source de Vérité de l'architecture.\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\">Couche SenseFlow\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ce qu'elle contient\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Rôle dans la séparation ADR\u002FNFR\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Structure produit \u002F exigences\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Objectif produit, capacité, épopée, récit utilisateur, critères d'acceptation, tâches techniques ; les exigences peuvent inclure des NFR et une méthode de validation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Préserve ce qui doit être atteint et comment le succès sera vérifié\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Intégrité des décisions\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Décision, raison, alternatives, compromis, statut, date\u002Fversion\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Préserve pourquoi un choix architecturalement significatif est devenu faisant autorité\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\">Exigences, architecture, recherche, enregistrements de décisions, risques, feuille de route et sources de support\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Maintient la Source de Vérité conceptuelle et historique\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\">Initiatives\u002Fobjectifs, épopées, récits, tâches et état de livraison\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Exécute le travail approuvé sans devenir la Source de Vérité conceptuelle\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Gestion du changement\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">État actuel → nouvelle preuve → changement proposé → impact → décision\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Permet aux décisions d'évoluer sans effacer la trace du raisonnement\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Traçabilité de bout en bout\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Problème → besoin → valeur → objectif produit → exigence → implémentation → validation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Maintient la documentation des décisions connectée au produit réel et au cycle de vie des preuves\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\">Ce que cette implémentation démontre\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Une exigence et une décision peuvent vivre proches l'une de l'autre sans être fusionnées en un seul enregistrement. L'exigence reste la cible ; la décision reste l'historique du raisonnement ; le travail de livraison implémente la décision ; la validation revient à la cible.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-52\">Contexte de projet d'entreprise : les exigences devraient précéder les choix d'architecture\u003C\u002Fh2>\n\u003Cp>La même séparation est utile dans le travail de projet orienté entreprise. Les décisions d'architecture prises avant que les exigences, les risques, les contraintes et les conditions d'acceptation soient suffisamment compris peuvent transformer des préférences en fausses nécessités.\u003C\u002Fp>\n\u003Cp>Pour Enterprise Aaasaasa 0.1, la leçon pertinente est méthodologique plutôt qu'une affirmation sur un ADR particulier : les exigences, l'architecture, la validation, les jalons, la gestion des risques et l'acceptation appartiennent à un système de livraison connecté. Un choix d'architecture devrait rester traçable jusqu'à l'exigence ou la contrainte qu'il est censé traiter.\u003C\u002Fp>\n\u003Ch2 id=\"section-55\">Modes de défaillance courants lorsque les ADR et les NFR sont mélangés\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\">Mode de défaillance\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ce qui se passe\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Conséquence\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Technologie déguisée en exigence\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Une solution préférée est écrite comme « doit utiliser X » sans établir le besoin sous-jacent\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les alternatives ne sont jamais évaluées et l'architecture est figée prématurément\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NFR caché uniquement dans un ADR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La décision mentionne une cible de performance\u002Fsécurité absente de la base de référence des exigences\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La cible est difficile à valider, prioriser ou gérer indépendamment\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ADR traité comme preuve\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un choix documenté est supposé signifier que l'exigence est satisfaite\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'intention architecturale remplace la mesure ou la vérification\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NFR vague\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Des mots tels que rapide, évolutif, sécurisé ou maintenable n'ont pas de portée mesurable\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Différentes parties prenantes peuvent croire que la même exigence signifie des choses différentes\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Aucune alternative enregistrée\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'équipe n'enregistre que la technologie sélectionnée\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les futurs mainteneurs ne peuvent pas reconstituer pourquoi une autre option a été rejetée\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Aucun modèle de remplacement\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les anciens ADR sont modifiés ou supprimés lorsque l'architecture change\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le raisonnement historique disparaît et les décisions obsolètes peuvent rester ambiguës\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Chaque détail d'implémentation devient un ADR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le référentiel se remplit d'enregistrements de faible valeur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les choix d'architecture importants deviennent difficiles à trouver\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le backlog devient la source de vérité de l'architecture\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les tâches Jira sont traitées comme la seule explication du système\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'état de livraison survit, mais la justification architecturale et les moteurs de qualité sont perdus\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-57\">Le cadre de décision ADR–NFR\u003C\u002Fh2>\n\u003Cp>Lorsqu'une équipe rencontre une nouvelle préoccupation architecturale, la séquence suivante aide à déterminer ce qui appartient aux exigences, ce qui appartient à un ADR et ce qui appartient aux preuves.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Test de classification ADR–NFR\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. S'agit-il d'une propriété requise ou d'une contrainte externe ?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Si oui, écrivez ou référencez l'exigence avant de choisir un mécanisme.\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. Peut-il être validé ?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Définissez la portée, la condition, la métrique, la règle d'acceptation, la méthode d'analyse ou toute autre preuve nécessaire.\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. Est-ce architecturalement significatif ?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Identifiez si l'exigence façonne matériellement la structure, la technologie, les données, le déploiement ou les compromis transversaux.\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. Existe-t-il des alternatives significatives ?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Comparez les tactiques ou options d'architecture viables plutôt que de passer directement à une technologie préférée.\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. Un choix est-il devenu faisant autorité ?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Créez ou mettez à jour l'ADR avec le contexte, la décision, la justification, les alternatives, les compromis, le statut et les conséquences.\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. La décision est-elle mise en œuvre ?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Tracez l'ADR dans la conception, les tâches, le code, la configuration et les opérations.\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. L'exigence est-elle satisfaite ?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Recueillez des preuves de validation par rapport à l'exigence elle-même.\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. Les conditions ont-elles changé ?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Réévaluez l'exigence et, si nécessaire, remplacez l'ADR sans effacer l'historique.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-60\">Ce que l'ADR et la NFR ne sont pas\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Erreurs de catégorie courantes\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\">Concept\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\">Ce n'est pas\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\">Raison\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 exigence de qualité\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\">Preuve de validation\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\">Élément de backlog\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\">Contrainte\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\">Qu'est-ce qui changerait cette réponse ?\u003C\u002Fh2>\n\u003Cp>La terminologie peut évoluer. L'ISO\u002FIEC\u002FIEEE 29148:2018 reste la norme d'ingénierie des exigences publiée en vigueur au 8 octobre 2026, mais l'ISO répertorie un projet de norme internationale destiné à la remplacer. Si la nouvelle édition modifie la terminologie ou les directives relatives aux exigences, les références spécifiques à la version dans cet article devraient être mises à jour.\u003C\u002Fp>\n\u003Cp>Les modèles d'ADR peuvent également évoluer sans changer la distinction centrale. Le modèle minimal de Michael Nygard, MADR, les modèles spécifiques à l'organisation, les outils de connaissance architecturale ou les bases de données de décisions structurées peuvent tous enregistrer des décisions. La question durable est de savoir si l'enregistrement préserve suffisamment de contexte et de justification pour comprendre un choix architecturalement significatif.\u003C\u002Fp>\n\u003Cp>La distinction ne s'effondrerait que si une organisation choisissait délibérément un artefact combiné qui stocke à la fois les données d'exigence et de décision dans un seul document. Même dans ce cas, les rôles sémantiques restent différents : un champ énonce le résultat ou la contrainte requis ; un autre enregistre la réponse choisie.\u003C\u002Fp>\n\u003Ch2 id=\"section-66\">Limites\u003C\u002Fh2>\n\u003Cp>Cet article utilise \u003Cstrong>NFR\u003C\u002Fstrong> comme abréviation pratique. Certaines méthodes d'ingénierie préfèrent des termes tels qu'exigence d'attribut de qualité, exigence de qualité, qualité système, contrainte, objectif de niveau de service ou exigence architecturalement significative. Ces termes ne sont pas parfaitement interchangeables, et la terminologie du projet doit être explicite.\u003C\u002Fp>\n\u003Cp>Toutes les exigences ne peuvent pas être réduites à un seul seuil numérique. La sécurité, la sûreté, la maintenabilité, l'interopérabilité, l'utilisabilité, l'explicabilité, la portabilité et la gouvernance peuvent nécessiter des combinaisons de scénarios, de règles structurelles, d'analyses, de contrôles de processus et de preuves qualitatives. « Mesurable » devrait signifier suffisamment vérifiable pour la décision, et non artificiellement numérique.\u003C\u002Fp>\n\u003Cp>Toutes les décisions d'architecture n'ont pas besoin d'un ADR formel. Le coût de documentation doit être proportionnel à l'importance architecturale, à la longévité, à l'incertitude, à la complexité des compromis et au coût de la perte de la justification.\u003C\u002Fp>\n\u003Ch2 id=\"section-70\">Conclusion\u003C\u002Fh2>\n\u003Cp>L'ADR et la NFR appartiennent à des couches différentes du travail d'architecture. \u003Cstrong>La NFR définit une cible de qualité, une contrainte ou une condition d'exploitation. L'ADR enregistre une réponse architecturale significative à un ou plusieurs moteurs.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Garder ces couches séparées rend l'architecture plus facile à raisonner. Les exigences peuvent être validées indépendamment de la technologie. Les décisions peuvent être remplacées sans réécrire l'historique. Les alternatives et les compromis restent visibles. Le travail de livraison peut être retracé jusqu'à l'intention architecturale. Les preuves peuvent montrer si le système résultant satisfait réellement l'exigence.\u003C\u002Fp>\n\u003Cp>La chaîne la plus solide n'est donc pas « NFR → ADR → terminé ». C'est \u003Cstrong>besoin → exigence → moteurs architecturaux → options → décision → mise en œuvre → validation → changement\u003C\u002Fstrong>. Cette chaîne transforme la documentation d'architecture d'une paperasse statique en un registre testable des raisons pour lesquelles le système a la forme qu'il a.\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\">Un ADR est-il une exigence non fonctionnelle ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. Une NFR énonce une qualité, une contrainte ou une condition d'exploitation requise. Un ADR consigne un choix architecturalement significatif effectué en réponse à des exigences, des contraintes, des risques et des compromis.\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\">Chaque NFR doit-elle avoir un ADR ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. Seules les exigences qui influencent matériellement l'architecture nécessitent des décisions au niveau de l'architecture qui méritent d'être conservées. Une NFR peut aussi motiver plusieurs ADR, et un ADR peut répondre à plusieurs exigences.\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\">« Utiliser PostgreSQL » peut-il être une NFR ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Uniquement lorsque PostgreSQL est véritablement imposé comme contrainte externe. Sinon, le besoin sous-jacent doit d'abord être exprimé, et le choix de PostgreSQL doit normalement être traité comme une décision d'architecture.\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\">Un ADR prouve-t-il qu'une exigence de performance ou de sécurité est satisfaite ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. Un ADR consigne l'intention et le raisonnement. L'exigence est validée par des preuves appropriées telles que des tests, des mesures, des analyses, des audits ou de la télémétrie opérationnelle.\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\">Que doit contenir un ADR ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Au minimum, un ADR doit rendre le contexte et la décision clairs. Les structures courantes incluent aussi le statut et les conséquences. Les équipes peuvent ajouter des alternatives, la justification, les compromis, les liens vers les exigences, les preuves, les responsables, les dates et les relations de remplacement.\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\">Qu'est-ce qui rend une NFR architecturalement significative ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Une exigence est architecturalement significative lorsqu'elle façonne matériellement la structure du système, la technologie, les flux de données, le déploiement, le comportement transversal ou des compromis de qualité difficiles, en particulier lorsque l'échec entraîne un impact métier ou de mission élevé.\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\">Un ancien ADR doit-il être supprimé lorsque l'architecture change ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Généralement non. Une décision de remplacement doit normalement remplacer l'ancien enregistrement afin que le raisonnement historique reste traçable.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-76\">Glossaire\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\">Termes d'architecture fondamentaux\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\">Exigence non fonctionnelle : abréviation pratique pour une qualité, une contrainte ou une condition d'exploitation requise du système ; la terminologie exacte varie selon la méthode et la norme.\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\">Exigence d'attribut de qualité\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Exigence décrivant une propriété de qualité que le système est censé présenter dans des conditions définies, telles que la performance, la disponibilité, la sécurité, la fiabilité ou la modifiabilité.\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\">Enregistrement durable d'une décision architecturalement significative et d'un contexte suffisant pour comprendre pourquoi le choix a été fait et quelles conséquences en découlent.\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\">Architecturally Significant Requirement (ASR)\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Exigence ayant un impact architectural suffisamment étendu pour influencer matériellement la conception du système.\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\">Contrainte\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Condition qui restreint l'espace des solutions, y compris les politiques externes, la réglementation, la plateforme, la compatibilité, les limites contractuelles ou organisationnelles.\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\">Compromis\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Relation de conception dans laquelle l'amélioration d'un objectif, d'une propriété ou d'une dimension de coût peut en dégrader un autre.\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\">Validation\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Travail produisant des preuves utilisé pour déterminer si le système mis en œuvre satisfait l'exigence énoncée dans les conditions pertinentes.\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\">ADR remplacé\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Enregistrement de décision historique qui a été remplacé par une décision faisant autorité plus récente tout en restant disponible pour la traçabilité.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-78\">Sources primaires et preuves de mise en œuvre\u003C\u002Fh2>\n\u003Cp>Cet article distingue les normes en vigueur des preuves de mise en œuvre de projet. L'ISO\u002FIEC\u002FIEEE 29148:2018 reste en vigueur au 8 octobre 2026 mais est marquée pour révision ; l'ISO\u002FIEC 25010:2023 et l'ISO\u002FIEC\u002FIEEE 42010:2022 sont les éditions publiées en vigueur. SenseFlow est une preuve de projet originale pour le modèle de traçabilité et d'intégrité décisionnelle décrit ci-dessus.\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 — Ingénierie des exigences\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Norme d'ingénierie des exigences publiée en vigueur. L'ISO indique que l'édition 2018 a été examinée et confirmée en 2024 et devrait être remplacée par le DIS actuellement en cours d'élaboration.\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 — Ingénierie des exigences\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Projet de norme internationale actuellement en cours d'élaboration et destiné à remplacer l'ISO\u002FIEC\u002FIEEE 29148:2018.\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 — Modèle de qualité du produit\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Modèle de qualité du produit en vigueur avec neuf caractéristiques de qualité utilisées pour spécifier, mesurer et évaluer la qualité des produits TIC et logiciels.\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 — Description de l'architecture\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Norme de description de l'architecture en vigueur. Elle spécifie les concepts de description de l'architecture et les exigences de conformité sans prescrire un format d'enregistrement, une notation, un processus ou un outil unique.\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 — Documenter les décisions d'architecture\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Article original influent sur les ADR décrivant des enregistrements légers centrés sur le contexte, la décision, le statut et les conséquences, avec les décisions remplacées conservées pour la compréhension historique.\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 — Relier les objectifs métier aux exigences architecturalement significatives\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Rapport du SEI expliquant comment les exigences d'attributs de qualité et les objectifs métier orientent l'architecture logicielle et pourquoi les exigences architecturalement significatives nécessitent une élicitation explicite.\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 — Définir les qualités système non fonctionnelles\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Aperçu du SEI reliant les attributs non fonctionnels\u002Fde qualité à l'architecture, aux scénarios, aux compromis et à l'évaluation objective du système.\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 — Collection de méthodes Attribute-Driven Design\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Méthode de conception d'architecture basée sur les exigences fonctionnelles, les exigences d'attributs de qualité et les contraintes, avec des tactiques et des patrons architecturaux sélectionnés pour satisfaire les scénarios de qualité.\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 — Collection Views and Beyond\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Guide de documentation d'architecture mettant l'accent sur les vues pertinentes et l'enregistrement des décisions de conception nécessaires dans le cadre du travail d'architecture.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1032},1791476161281,[214,219,226,232,239,243,247,251,255,299,303,307,311,315,343,349,353,357,361,365,401,405,409,413,438,444,448,452,456,497,501,505,509,540,544,548,552,557,561,565,569,592,596,600,629,633,638,642,646,650,682,687,691,695,699,703,743,747,751,780,784,829,833,837,841,845,849,853,857,861,865,869,873,877,881,914,918,950,954,958,968,976,984,992,1000,1008,1016,1024],{"id":215,"data":216,"type":218},"intro",{"text":217},"Une \u003Cstrong>exigence non fonctionnelle (ENF)\u003C\u002Fstrong> décrit une qualité, une contrainte ou une condition d'exploitation que le système est censé satisfaire. Un \u003Cstrong>enregistrement de décision d'architecture (EDA)\u003C\u002Fstrong> consigne un choix architecturalement significatif effectué en réponse à des exigences, des contraintes, des risques et des compromis. Ils sont liés, mais ils ne sont pas interchangeables : une ENF énonce ce qui doit être vrai ; un EDA explique ce qui a été décidé, pourquoi, et avec quelles conséquences.","paragraph",{"id":220,"data":221,"type":225},"direct",{"body":222,"title":223,"variant":224},"\u003Cstrong>ENF = qualité ou contrainte système requise. EDA = décision d'architecture consignée.\u003C\u002Fstrong> Un objectif de latence, un objectif de disponibilité, une règle d'isolation, une restriction de déploiement ou une exigence de maintenabilité peuvent influencer l'architecture. Un EDA consigne ensuite un choix significatif effectué pour répondre à un ou plusieurs de ces moteurs. L'EDA ne remplace pas l'exigence, et l'existence d'un EDA ne prouve pas que l'exigence a été satisfaite.","Réponse directe","info","callout",{"id":227,"data":228,"type":225},"version-note",{"body":229,"title":230,"variant":231},"Le terme \u003Cstrong>ENF\u003C\u002Fstrong> est largement utilisé mais n'est pas parfaitement normalisé. Cet article l'utilise comme raccourci pratique pour les exigences de qualité et les contraintes pertinentes. Les normes actuelles ont été revérifiées le \u003Cstrong>8 octobre 2026\u003C\u002Fstrong> : l'ISO\u002FIEC\u002FIEEE 29148:2018 reste en vigueur mais est en cours de révision ; l'ISO\u002FIEC 25010:2023 et l'ISO\u002FIEC\u002FIEEE 42010:2022 sont les éditions publiées actuelles citées ici.","Note sur la terminologie et les normes","note",{"id":233,"data":234,"type":238},"toc",{"title":235,"maxLevel":236,"minLevel":237},"Sommaire",3,2,"tableOfContents",{"id":240,"data":241,"type":42},"h-meaning",{"text":242,"level":237},"Quelle est la différence entre une ENF et un EDA ?",{"id":244,"data":245,"type":218},"p-meaning-1",{"text":246},"La distinction la plus simple est grammaticale. Une exigence décrit une condition que le système doit satisfaire. Un enregistrement de décision décrit un choix effectué par l'équipe.",{"id":248,"data":249,"type":218},"p-meaning-2",{"text":250},"Par exemple, \u003Cstrong>« L'API doit renvoyer 95 % des requêtes de lecture en moins de 300 ms sous la charge de référence convenue »\u003C\u002Fstrong> est une exigence de qualité. \u003Cstrong>« Utiliser un cache read-through pour cette charge de travail car le chemin mesuré en base de données seule ne peut pas atteindre l'objectif de latence sans coût inacceptable »\u003C\u002Fstrong> est une décision d'architecture.",{"id":252,"data":253,"type":218},"p-meaning-3",{"text":254},"La première affirmation reste valide même si l'implémentation change. La seconde peut ensuite être remplacée par une autre décision si la charge de travail, la technologie, le modèle de coût ou les preuves changent.",{"id":256,"data":257,"type":298},"basic-difference",{"rows":258,"title":289,"layout":290,"columns":291},[259,265,271,277,283],{"id":260,"label":261,"values":262},"question","Question principale",{"adr":263,"nfr":264},"What architecturally significant choice did we make, and why?","What quality, constraint, or operating condition must the system satisfy?",{"id":266,"label":267,"values":268},"content","Contenu typique",{"adr":269,"nfr":270},"Context, decision, rationale, alternatives, trade-offs, status and consequences","Measurable target, scope, condition, constraint, acceptance or validation rule",{"id":272,"label":273,"values":274},"lifecycle","Rôle dans le cycle de vie",{"adr":275,"nfr":276},"A historical record of a significant decision","A requirement to design for and validate",{"id":278,"label":279,"values":280},"evidence","Qu'est-ce qui le prouve ?",{"adr":281,"nfr":282},"The record proves what was decided, not that the resulting system meets the requirement","Measurement, test, analysis, inspection, audit or other validation evidence",{"id":284,"label":285,"values":286},"change","Quand cela change",{"adr":287,"nfr":288},"When the decision is replaced, rejected, deprecated, or superseded","When stakeholder need, operating conditions, policy or quality target changes","ENF et EDA répondent à des questions différentes","table",[292,295],{"id":293,"label":294},"nfr","ENF \u002F exigence de qualité",{"id":296,"label":297},"adr","EDA \u002F décision d'architecture","comparison",{"id":300,"data":301,"type":42},"h-nfr",{"text":302,"level":237},"Qu'est-ce qu'une ENF en termes architecturaux précis ?",{"id":304,"data":305,"type":218},"p-nfr-1",{"text":306},"« Exigence non fonctionnelle » est une étiquette pratique du secteur, mais elle peut masquer plusieurs types d'énoncés différents. Dans le travail d'architecture, la distinction utile est entre \u003Cstrong>comportement fonctionnel\u003C\u002Fstrong>, \u003Cstrong>exigences de qualité\u003C\u002Fstrong> et \u003Cstrong>contraintes\u003C\u002Fstrong>.",{"id":308,"data":309,"type":218},"p-nfr-2",{"text":310},"L'ISO\u002FIEC 25010:2023 fournit un modèle de qualité de produit avec neuf caractéristiques et sous-caractéristiques qui peuvent être utilisées pour spécifier et évaluer la qualité des produits TIC et logiciels. Le travail d'architecture du SEI traite de même les exigences d'attributs de qualité comme des moteurs majeurs de l'architecture logicielle.",{"id":312,"data":313,"type":218},"p-nfr-3",{"text":314},"Une ENF utile n'est donc pas « le système devrait être rapide » ou « la plateforme doit être sécurisée ». Ces énoncés nomment des aspirations. Une exigence motrice d'architecture devrait rendre la propriété attendue suffisamment testable pour que les alternatives de conception et les preuves ultérieures puissent être évaluées par rapport à elle.",{"id":316,"data":317,"type":290},"nfr-examples",{"content":318,"stretched":43,"withHeadings":14},[319,323,327,331,335,339],[320,321,322],"Énoncé faible","Forme d'exigence plus utile","Pourquoi la différence compte",[324,325,326],"L'API doit être rapide","Pour la charge de travail W, 95 % de l'opération X se termine en T millisecondes","Définit la charge de travail, l'opération, la métrique et le seuil",[328,329,330],"Le service doit être disponible","Le service S atteint un objectif de disponibilité convenu sur la fenêtre de mesure M, en excluant les conditions de maintenance explicitement définies","Rend la disponibilité mesurable et définit le périmètre",[332,333,334],"Les données des locataires doivent être sécurisées","Une requête authentifiée pour le locataire A ne doit jamais récupérer ou modifier les données du locataire B via les chemins applicatifs pris en charge","Transforme un objectif de sécurité vague en propriété d'isolation",[336,337,338],"Le système devrait évoluer","Le système prend en charge la charge de travail W à la concurrence C tout en respectant les seuils de latence et de taux d'erreur","Relie l'échelle à un comportement de service mesurable",[340,341,342],"Nous avons besoin de PostgreSQL","Pas une ENF en soi ; énoncer d'abord les qualités de persistance requises ou la contrainte externe","Un choix technologique est normalement une solution, pas l'exigence qu'il est censé satisfaire",{"id":344,"data":345,"type":225},"nfr-rule",{"body":346,"title":347,"variant":348},"Si « utiliser Kubernetes », « utiliser PostgreSQL », « utiliser des microservices » ou « utiliser la recherche vectorielle » apparaît comme l'exigence, demandez s'il s'agit vraiment d'une contrainte externe ou si la solution a été écrite avant que le besoin de qualité sous-jacent ne soit explicité.","Une exigence devrait décrire le besoin avant le mécanisme","success",{"id":350,"data":351,"type":42},"h-adr",{"text":352,"level":237},"Qu'est-ce qu'un enregistrement de décision d'architecture ?",{"id":354,"data":355,"type":218},"p-adr-1",{"text":356},"Un enregistrement de décision d'architecture est un compte rendu compact d'une décision d'architecture importante. La formulation originale d'ADR de Michael Nygard met l'accent sur le \u003Cstrong>contexte\u003C\u002Fstrong>, la \u003Cstrong>décision\u003C\u002Fstrong>, son \u003Cstrong>statut\u003C\u002Fstrong> et les \u003Cstrong>conséquences\u003C\u002Fstrong> qui en résultent.",{"id":358,"data":359,"type":218},"p-adr-2",{"text":360},"L'objet important est la décision, pas le modèle. Différentes équipes utilisent différents formats d'ADR. Un enregistrement plus riche peut également conserver les alternatives, les critères de décision, les compromis, les preuves, les liens vers les exigences et la date ou la version à partir de laquelle la décision s'applique.",{"id":362,"data":363,"type":218},"p-adr-3",{"text":364},"ISO\u002FIEC\u002FIEEE 42010:2022 est plus large que la pratique des ADR : il spécifie des exigences pour les descriptions d'architecture et leurs concepts, tout en ne prescrivant explicitement aucun processus, notation, outil, format ou support pour consigner une description d'architecture. Un ADR est donc une technique pratique de consignation des décisions, et non un format imposé par l'ISO 42010.",{"id":366,"data":367,"type":290},"adr-anatomy",{"content":368,"stretched":43,"withHeadings":14},[369,373,377,381,385,389,393,397],[370,371,372],"Champ de l'ADR","Ce qu'il préserve","Pourquoi c'est important",[374,375,376],"Contexte","Le problème, les forces, les exigences, les hypothèses et l'environnement entourant le choix","Les lecteurs futurs peuvent reconstituer pourquoi un choix était nécessaire",[378,379,380],"Décision","Le choix devenu faisant autorité","Sépare l'option retenue de la discussion",[382,383,384],"Statut","Proposé, accepté, rejeté, obsolète, remplacé ou un autre état contrôlé","Empêche les anciennes décisions de rester silencieusement actives",[386,387,388],"Alternatives","Les autres options viables envisagées","Montre que la solution retenue n'était pas la seule imaginable",[390,391,392],"Justification \u002F compromis","Pourquoi l'option a été retenue et ce à quoi elle renonce","Rend le raisonnement architectural inspectable",[394,395,396],"Conséquences","Effets positifs et négatifs attendus, travaux de suivi, risques","Relie un choix local à l'impact sur le système",[398,399,400],"Date \u002F version","Quand la décision est devenue valide","Soutient la traçabilité historique et le remplacement ultérieur",{"id":402,"data":403,"type":42},"h-simple-example",{"text":404,"level":237},"L'exemple le plus simple : exigence de latence → décision d'architecture",{"id":406,"data":407,"type":218},"p-simple-1",{"text":408},"Supposons qu'un product owner et une équipe d'ingénierie conviennent qu'un point de terminaison de recherche doit renvoyer la première page de résultats en moins de 400 ms au 95e centile sous une charge de référence définie.",{"id":410,"data":411,"type":218},"p-simple-2",{"text":412},"Cette cible n'est pas un ADR. C'est une exigence de qualité. Le travail d'architecture commence en demandant quelle conception peut la satisfaire compte tenu des autres contraintes du système.",{"id":414,"data":415,"type":437},"simple-flow",{"steps":416,"title":435,"orientation":436},[417,420,423,426,429,432],{"label":418,"description":419},"1. Énoncer l'exigence","Définir la cible de qualité, la charge, la portée, le seuil et la méthode de validation.",{"label":421,"description":422},"2. Identifier la signification architecturale","Déterminer si l'exigence influence matériellement la structure, la technologie, le déploiement, le flux de données ou le modèle opérationnel.",{"label":424,"description":425},"3. Évaluer les options","Comparer des alternatives telles que l'indexation, la mise en cache, la dénormalisation, le travail asynchrone, le partitionnement ou une architecture de requête différente.",{"label":427,"description":428},"4. Consigner la décision","Capturer le choix d'architecture retenu, la justification, les alternatives, les compromis, le statut et les conséquences dans un ADR.",{"label":430,"description":431},"5. Mettre en œuvre","Transformer la décision en code, infrastructure, configuration et comportement opérationnel.",{"label":433,"description":434},"6. Valider","Mesurer le système réel par rapport à l'exigence initiale. Le résultat du test valide l'ENF ; l'ADR seul ne le fait pas.","De l'exigence à la preuve","auto","processFlow",{"id":439,"data":440,"type":225},"simple-stop",{"body":441,"title":442,"variant":443},"Les systèmes réels ont rarement une seule exigence et une seule décision. La performance peut se négocier contre le coût, la cohérence, l'exploitabilité, la sécurité, la maintenabilité, la consommation d'énergie ou le risque de livraison. Le modèle utile est donc un graphe de traçabilité, et non une correspondance biunivoque.","Où s'arrête l'exemple simple","warning",{"id":445,"data":446,"type":42},"h-many-many",{"text":447,"level":237},"Les ENF et les ADR ont généralement une relation plusieurs-à-plusieurs",{"id":449,"data":450,"type":218},"p-many-1",{"text":451},"Une exigence de qualité peut entraîner plusieurs décisions d'architecture. Une exigence d'isolation des locataires, par exemple, peut influencer la propagation de l'identité, le périmètre de la base de données, la conception des tâches en arrière-plan, les clés de cache, la journalisation d'audit et l'outillage administratif.",{"id":453,"data":454,"type":218},"p-many-2",{"text":455},"Une décision d'architecture peut aussi répondre à plusieurs exigences à la fois. Choisir une frontière de traitement asynchrone peut améliorer la réactivité et l'isolation des défaillances tout en introduisant des compromis de cohérence, de complexité, d'observabilité et d'exploitation.",{"id":457,"data":458,"type":298},"relationship-map",{"rows":459,"title":488,"layout":290,"columns":489},[460,467,474,481],{"id":461,"label":462,"values":463},"one-many","Une ENF → plusieurs ADR",{"adr":464,"nfr":465,"validation":466},"Several coordinated decisions may be required","A broad quality target can constrain several architectural boundaries","Evidence may need multiple tests or measurements",{"id":468,"label":469,"values":470},"many-one","Plusieurs ENF → un ADR",{"adr":471,"nfr":472,"validation":473},"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":475,"label":476,"values":477},"non-nfr","ADR sans ENF classique",{"adr":478,"nfr":479,"validation":480},"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":482,"label":483,"values":484},"supersession","Exigence stable, ADR qui change",{"adr":485,"nfr":486,"validation":487},"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","Pourquoi la relation n'est pas biunivoque",[490,492,494],{"id":293,"label":491},"Côté exigence",{"id":296,"label":493},"Côté décision",{"id":495,"label":496},"validation","Côté validation",{"id":498,"data":499,"type":42},"h-technology",{"text":500,"level":237},"Un choix technologique n'est pas automatiquement une exigence",{"id":502,"data":503,"type":218},"p-tech-1",{"text":504},"Une erreur d'architecture récurrente consiste à inscrire une technologie préférée dans la couche des exigences, puis à traiter la conception qui en résulte comme inévitable.",{"id":506,"data":507,"type":218},"p-tech-2",{"text":508},"« Le système doit utiliser PostgreSQL » peut être une contrainte légitime si un contrat, une politique de plateforme, une exigence de compatibilité, une règle de licence, une norme organisationnelle ou une frontière opérationnelle existante impose réellement PostgreSQL. Mais si le besoin réel est la cohérence transactionnelle, l'interrogation structurée, la familiarité opérationnelle ou un objectif de reprise spécifique, l'exigence devrait énoncer ce besoin et la sélection technologique devrait être consignée comme une décision.",{"id":510,"data":511,"type":290},"tech-table",{"content":512,"stretched":43,"withHeadings":14},[513,517,521,525,529,533,537],[514,515,516],"Énoncé","Classification","Raison",[518,519,520],"Toutes les lectures limitées à un locataire doivent appliquer l'isolation des locataires","Exigence \u002F propriété de sécurité","Décrit une propriété qui doit être respectée",[522,523,524],"Utiliser la sécurité au niveau des lignes de PostgreSQL pour certaines tables limitées à un locataire","Décision d'architecture","Choisit un mécanisme destiné à aider à satisfaire la propriété d'isolation",[526,527,528],"La cible de déploiement doit s'exécuter dans un environnement approuvé exploité dans l'UE","Contrainte \u002F condition d'exploitation de type ENF","Restreint le lieu où le système peut fonctionner",[530,531,532],"Utiliser le fournisseur X dans la région Y","Décision d'architecture \u002F de déploiement, sauf si imposée de l'extérieur","Sélectionne une solution particulière à l'intérieur de la frontière autorisée",[534,535,536],"Latence de l'API au 95e centile ≤ 300 ms sous la charge W","Exigence de qualité","Définit un comportement de performance mesurable",[538,523,539],"Introduire un cache pour le point de terminaison X","Sélectionne une tactique destinée à améliorer le comportement mesuré",{"id":541,"data":542,"type":42},"h-adr-proof",{"text":543,"level":237},"Un ADR n'est pas la preuve qu'une ENF a été satisfaite",{"id":545,"data":546,"type":218},"p-proof-1",{"text":547},"La documentation des décisions et la validation du système répondent à des questions différentes. Un ADR peut montrer que la performance, la sécurité, la résilience ou la maintenabilité ont été prises en compte. Il ne peut pas, à lui seul, démontrer que le système livré atteint réellement ces propriétés.",{"id":549,"data":550,"type":218},"p-proof-2",{"text":551},"La preuve doit provenir de la méthode de validation appropriée à l'exigence : benchmark, test de charge, test de défaillance, test de sécurité, analyse d'architecture, audit, inspection, télémétrie opérationnelle, exercice de reprise, étude utilisateur ou une autre forme de preuve.",{"id":553,"data":554,"type":225},"proof-rule",{"body":555,"title":556,"variant":443},"\u003Cstrong>ADR :\u003C\u002Fstrong> « Nous avons choisi la conception X parce qu'elle est censée satisfaire l'exigence R sous les hypothèses A. »\u003Cbr>\u003Cstrong>Validation :\u003C\u002Fstrong> « La preuve mesurée ou analysée E montre si le système implémenté satisfait réellement R. »","Ne pas confondre intention et preuve",{"id":558,"data":559,"type":42},"h-asr",{"text":560,"level":237},"Quand une exigence non fonctionnelle devient-elle architecturally significant ?",{"id":562,"data":563,"type":218},"p-asr-1",{"text":564},"Toutes les exigences non fonctionnelles ne méritent pas une décision d'architecture. Le sous-ensemble important est constitué des exigences qui façonnent matériellement l'architecture ou qui imposent des compromis à l'échelle du système.",{"id":566,"data":567,"type":218},"p-asr-2",{"text":568},"La littérature du SEI utilise le concept d'\u003Cstrong>architecturally significant requirements\u003C\u002Fstrong> pour les exigences ayant un effet architectural de grande portée. Les attributs de qualité tels que la performance, la fiabilité, la sécurité et la modifiabilité sont des sources fréquentes de tels moteurs, en particulier lorsqu'ils portent une valeur métier ou de mission élevée.",{"id":570,"data":571,"type":437},"asr-test",{"steps":572,"title":591,"orientation":436},[573,576,579,582,585,588],{"label":574,"description":575},"1. Demander si l'exigence modifie la structure","Des valeurs différentes imposeraient-elles des composants, des frontières, des chemins de données ou une topologie de déploiement différents ?",{"label":577,"description":578},"2. Demander si elle contraint des choix technologiques majeurs","Élimine-t-elle des options d'implémentation autrement viables ?",{"label":580,"description":581},"3. Demander si elle crée un comportement transversal","Affecte-t-elle de nombreux composants, équipes, interfaces ou étapes du cycle de vie ?",{"label":583,"description":584},"4. Demander si elle crée un compromis difficile","Améliorer cette propriété affecte-t-il matériellement une autre qualité, le coût, le calendrier, la complexité ou le risque ?",{"label":586,"description":587},"5. Demander si l'échec est coûteux","Manquer l'exigence créerait-il un impact opérationnel, de sécurité, réglementaire, financier ou produit matériel ?",{"label":589,"description":590},"6. Enregistrer les décisions uniquement là où le raisonnement mérite d'être conservé","Ne créez pas d'ADR pour chaque choix de codage local ; conservez les décisions architecturalement significatives et leur justification.","Test de signification architecturale",{"id":593,"data":594,"type":42},"h-traceability",{"text":595,"level":237},"Un modèle d'architecture plus robuste : exigence → décision → implémentation → validation",{"id":597,"data":598,"type":218},"p-trace-1",{"text":599},"Le lien le plus utile entre les NFR et les ADR est la traçabilité. Une exigence devrait pouvoir pointer vers les décisions d'architecture qui la traitent ; un ADR devrait identifier les moteurs auxquels il répond ; le travail d'implémentation devrait réaliser la décision ; la validation devrait revenir à l'exigence d'origine.",{"id":601,"data":602,"type":437},"trace-flow",{"steps":603,"title":628,"orientation":436},[604,607,610,613,616,619,622,625],{"label":605,"description":606},"Besoin \u002F objectif métier","Pourquoi la qualité ou la contrainte importe.",{"label":608,"description":609},"Exigence \u002F NFR","Ce que le système doit atteindre ou respecter.",{"label":611,"description":612},"Moteurs d'architecture","Quelles exigences sont suffisamment significatives pour façonner la conception.",{"label":614,"description":615},"Options","Façons plausibles de traiter le moteur.",{"label":617,"description":618},"ADR","Le choix sélectionné, la justification, les alternatives, les compromis et les conséquences.",{"label":620,"description":621},"Implémentation","Code, modèle de données, infrastructure, interfaces et mécanismes opérationnels qui réalisent la décision.",{"label":623,"description":624},"Preuve de validation","Tests, mesures, analyses ou audits démontrant si l'exigence d'origine est réellement satisfaite.",{"label":626,"description":627},"Changement \u002F remplacement","De nouvelles preuves ou des exigences modifiées peuvent déclencher un nouvel ADR tout en préservant le raisonnement historique.","Chaîne de traçabilité architecturale",{"id":630,"data":631,"type":42},"h-senseflow",{"text":632,"level":237},"Preuve d'implémentation : comment je sépare les exigences et les décisions dans SenseFlow",{"id":634,"data":635,"type":225},"senseflow-evidence",{"body":636,"title":637,"variant":231},"La section suivante décrit la structure de mon propre projet SenseFlow. Il s'agit d'une preuve d'implémentation pour la séparation présentée dans cet article, et non d'une affirmation que chaque équipe doit utiliser le même modèle de documentation.","Preuve d'implémentation \u002F de projet originale",{"id":639,"data":640,"type":218},"p-sense-1",{"text":641},"Dans SenseFlow, la Source de Vérité du projet place explicitement les exigences non fonctionnelles à l'intérieur de la structure des exigences, aux côtés des dépendances, des risques, des hypothèses, des critères d'acceptation et d'une méthode de validation. Le modèle de documentation définit séparément l'intégrité des décisions pour les décisions significatives.",{"id":643,"data":644,"type":218},"p-sense-2",{"text":645},"Pour les décisions significatives de SenseFlow, les champs enregistrés sont \u003Cstrong>Décision, Raison, Alternatives, Compromis, Statut et Date \u002F Version\u003C\u002Fstrong>. Les décisions majeures d'architecture et de produit sont destinées à rester historiquement traçables plutôt que d'être écrasées lorsque le projet évolue.",{"id":647,"data":648,"type":218},"p-sense-3",{"text":649},"SenseFlow attribue également des rôles opérationnels différents à Confluence et Jira. Confluence est l'environnement structuré de connaissances et de décisions ; Jira gère le travail de livraison actionnable. Les Épopées Jira majeures devraient renvoyer à la documentation produit ou d'exigences pertinente. Cela préserve la chaîne allant de l'intention produit à travers les exigences et les décisions jusqu'à l'implémentation, plutôt que de transformer le backlog en Source de Vérité de l'architecture.",{"id":651,"data":652,"type":290},"senseflow-table",{"content":653,"stretched":43,"withHeadings":14},[654,658,662,666,670,674,678],[655,656,657],"Couche SenseFlow","Ce qu'elle contient","Rôle dans la séparation ADR\u002FNFR",[659,660,661],"Structure produit \u002F exigences","Objectif produit, capacité, épopée, récit utilisateur, critères d'acceptation, tâches techniques ; les exigences peuvent inclure des NFR et une méthode de validation","Préserve ce qui doit être atteint et comment le succès sera vérifié",[663,664,665],"Intégrité des décisions","Décision, raison, alternatives, compromis, statut, date\u002Fversion","Préserve pourquoi un choix architecturalement significatif est devenu faisant autorité",[667,668,669],"Confluence","Exigences, architecture, recherche, enregistrements de décisions, risques, feuille de route et sources de support","Maintient la Source de Vérité conceptuelle et historique",[671,672,673],"Jira","Initiatives\u002Fobjectifs, épopées, récits, tâches et état de livraison","Exécute le travail approuvé sans devenir la Source de Vérité conceptuelle",[675,676,677],"Gestion du changement","État actuel → nouvelle preuve → changement proposé → impact → décision","Permet aux décisions d'évoluer sans effacer la trace du raisonnement",[679,680,681],"Traçabilité de bout en bout","Problème → besoin → valeur → objectif produit → exigence → implémentation → validation","Maintient la documentation des décisions connectée au produit réel et au cycle de vie des preuves",{"id":683,"data":684,"type":225},"senseflow-lesson",{"body":685,"title":686,"variant":348},"Une exigence et une décision peuvent vivre proches l'une de l'autre sans être fusionnées en un seul enregistrement. L'exigence reste la cible ; la décision reste l'historique du raisonnement ; le travail de livraison implémente la décision ; la validation revient à la cible.","Ce que cette implémentation démontre",{"id":688,"data":689,"type":42},"h-enterprise",{"text":690,"level":237},"Contexte de projet d'entreprise : les exigences devraient précéder les choix d'architecture",{"id":692,"data":693,"type":218},"p-enterprise-1",{"text":694},"La même séparation est utile dans le travail de projet orienté entreprise. Les décisions d'architecture prises avant que les exigences, les risques, les contraintes et les conditions d'acceptation soient suffisamment compris peuvent transformer des préférences en fausses nécessités.",{"id":696,"data":697,"type":218},"p-enterprise-2",{"text":698},"Pour Enterprise Aaasaasa 0.1, la leçon pertinente est méthodologique plutôt qu'une affirmation sur un ADR particulier : les exigences, l'architecture, la validation, les jalons, la gestion des risques et l'acceptation appartiennent à un système de livraison connecté. Un choix d'architecture devrait rester traçable jusqu'à l'exigence ou la contrainte qu'il est censé traiter.",{"id":700,"data":701,"type":42},"h-failures",{"text":702,"level":237},"Modes de défaillance courants lorsque les ADR et les NFR sont mélangés",{"id":704,"data":705,"type":290},"failure-table",{"content":706,"stretched":43,"withHeadings":14},[707,711,715,719,723,727,731,735,739],[708,709,710],"Mode de défaillance","Ce qui se passe","Conséquence",[712,713,714],"Technologie déguisée en exigence","Une solution préférée est écrite comme « doit utiliser X » sans établir le besoin sous-jacent","Les alternatives ne sont jamais évaluées et l'architecture est figée prématurément",[716,717,718],"NFR caché uniquement dans un ADR","La décision mentionne une cible de performance\u002Fsécurité absente de la base de référence des exigences","La cible est difficile à valider, prioriser ou gérer indépendamment",[720,721,722],"ADR traité comme preuve","Un choix documenté est supposé signifier que l'exigence est satisfaite","L'intention architecturale remplace la mesure ou la vérification",[724,725,726],"NFR vague","Des mots tels que rapide, évolutif, sécurisé ou maintenable n'ont pas de portée mesurable","Différentes parties prenantes peuvent croire que la même exigence signifie des choses différentes",[728,729,730],"Aucune alternative enregistrée","L'équipe n'enregistre que la technologie sélectionnée","Les futurs mainteneurs ne peuvent pas reconstituer pourquoi une autre option a été rejetée",[732,733,734],"Aucun modèle de remplacement","Les anciens ADR sont modifiés ou supprimés lorsque l'architecture change","Le raisonnement historique disparaît et les décisions obsolètes peuvent rester ambiguës",[736,737,738],"Chaque détail d'implémentation devient un ADR","Le référentiel se remplit d'enregistrements de faible valeur","Les choix d'architecture importants deviennent difficiles à trouver",[740,741,742],"Le backlog devient la source de vérité de l'architecture","Les tâches Jira sont traitées comme la seule explication du système","L'état de livraison survit, mais la justification architecturale et les moteurs de qualité sont perdus",{"id":744,"data":745,"type":42},"h-decision-framework",{"text":746,"level":237},"Le cadre de décision ADR–NFR",{"id":748,"data":749,"type":218},"p-framework-1",{"text":750},"Lorsqu'une équipe rencontre une nouvelle préoccupation architecturale, la séquence suivante aide à déterminer ce qui appartient aux exigences, ce qui appartient à un ADR et ce qui appartient aux preuves.",{"id":752,"data":753,"type":437},"decision-flow",{"steps":754,"title":779,"orientation":436},[755,758,761,764,767,770,773,776],{"label":756,"description":757},"1. S'agit-il d'une propriété requise ou d'une contrainte externe ?","Si oui, écrivez ou référencez l'exigence avant de choisir un mécanisme.",{"label":759,"description":760},"2. Peut-il être validé ?","Définissez la portée, la condition, la métrique, la règle d'acceptation, la méthode d'analyse ou toute autre preuve nécessaire.",{"label":762,"description":763},"3. Est-ce architecturalement significatif ?","Identifiez si l'exigence façonne matériellement la structure, la technologie, les données, le déploiement ou les compromis transversaux.",{"label":765,"description":766},"4. Existe-t-il des alternatives significatives ?","Comparez les tactiques ou options d'architecture viables plutôt que de passer directement à une technologie préférée.",{"label":768,"description":769},"5. Un choix est-il devenu faisant autorité ?","Créez ou mettez à jour l'ADR avec le contexte, la décision, la justification, les alternatives, les compromis, le statut et les conséquences.",{"label":771,"description":772},"6. La décision est-elle mise en œuvre ?","Tracez l'ADR dans la conception, les tâches, le code, la configuration et les opérations.",{"label":774,"description":775},"7. L'exigence est-elle satisfaite ?","Recueillez des preuves de validation par rapport à l'exigence elle-même.",{"label":777,"description":778},"8. Les conditions ont-elles changé ?","Réévaluez l'exigence et, si nécessaire, remplacez l'ADR sans effacer l'historique.","Test de classification ADR–NFR",{"id":781,"data":782,"type":42},"h-what-not",{"text":783,"level":237},"Ce que l'ADR et la NFR ne sont pas",{"id":785,"data":786,"type":298},"not-comparison",{"rows":787,"title":819,"layout":290,"columns":820},[788,794,799,805,812],{"id":293,"label":789,"values":790},"NFR \u002F exigence de qualité",{"not":791,"why":792,"term":793},"A technology shopping list","Requirements should preserve the need independently from one implementation when possible","A required quality, constraint or operating condition",{"id":296,"label":617,"values":795},{"not":796,"why":797,"term":798},"The complete architecture description","Architecture also needs views, interfaces, models, responsibilities and other documentation","A record of an architecturally significant decision",{"id":800,"label":623,"values":801},"test",{"not":802,"why":803,"term":804},"The ADR itself","Documented intent is different from measured or analyzed system behavior","Evidence that checks whether a requirement is satisfied",{"id":806,"label":807,"values":808},"backlog","Élément de backlog",{"not":809,"why":810,"term":811},"A durable substitute for architecture rationale","Task state answers what is being delivered, not necessarily why the architecture exists","Actionable delivery work",{"id":813,"label":814,"values":815},"constraint","Contrainte",{"not":816,"why":817,"term":818},"Always an internally chosen architecture decision","Some constraints come from regulation, contracts, existing platforms or organizational boundaries","A condition that restricts the solution space","Erreurs de catégorie courantes",[821,824,827],{"id":822,"label":823},"term","Concept",{"id":825,"label":826},"not","Ce n'est pas",{"id":828,"label":516},"why",{"id":830,"data":831,"type":42},"h-change",{"text":832,"level":237},"Qu'est-ce qui changerait cette réponse ?",{"id":834,"data":835,"type":218},"p-change-1",{"text":836},"La terminologie peut évoluer. L'ISO\u002FIEC\u002FIEEE 29148:2018 reste la norme d'ingénierie des exigences publiée en vigueur au 8 octobre 2026, mais l'ISO répertorie un projet de norme internationale destiné à la remplacer. Si la nouvelle édition modifie la terminologie ou les directives relatives aux exigences, les références spécifiques à la version dans cet article devraient être mises à jour.",{"id":838,"data":839,"type":218},"p-change-2",{"text":840},"Les modèles d'ADR peuvent également évoluer sans changer la distinction centrale. Le modèle minimal de Michael Nygard, MADR, les modèles spécifiques à l'organisation, les outils de connaissance architecturale ou les bases de données de décisions structurées peuvent tous enregistrer des décisions. La question durable est de savoir si l'enregistrement préserve suffisamment de contexte et de justification pour comprendre un choix architecturalement significatif.",{"id":842,"data":843,"type":218},"p-change-3",{"text":844},"La distinction ne s'effondrerait que si une organisation choisissait délibérément un artefact combiné qui stocke à la fois les données d'exigence et de décision dans un seul document. Même dans ce cas, les rôles sémantiques restent différents : un champ énonce le résultat ou la contrainte requis ; un autre enregistre la réponse choisie.",{"id":846,"data":847,"type":42},"h-limitations",{"text":848,"level":237},"Limites",{"id":850,"data":851,"type":218},"p-limit-1",{"text":852},"Cet article utilise \u003Cstrong>NFR\u003C\u002Fstrong> comme abréviation pratique. Certaines méthodes d'ingénierie préfèrent des termes tels qu'exigence d'attribut de qualité, exigence de qualité, qualité système, contrainte, objectif de niveau de service ou exigence architecturalement significative. Ces termes ne sont pas parfaitement interchangeables, et la terminologie du projet doit être explicite.",{"id":854,"data":855,"type":218},"p-limit-2",{"text":856},"Toutes les exigences ne peuvent pas être réduites à un seul seuil numérique. La sécurité, la sûreté, la maintenabilité, l'interopérabilité, l'utilisabilité, l'explicabilité, la portabilité et la gouvernance peuvent nécessiter des combinaisons de scénarios, de règles structurelles, d'analyses, de contrôles de processus et de preuves qualitatives. « Mesurable » devrait signifier suffisamment vérifiable pour la décision, et non artificiellement numérique.",{"id":858,"data":859,"type":218},"p-limit-3",{"text":860},"Toutes les décisions d'architecture n'ont pas besoin d'un ADR formel. Le coût de documentation doit être proportionnel à l'importance architecturale, à la longévité, à l'incertitude, à la complexité des compromis et au coût de la perte de la justification.",{"id":862,"data":863,"type":42},"h-conclusion",{"text":864,"level":237},"Conclusion",{"id":866,"data":867,"type":218},"p-conclusion-1",{"text":868},"L'ADR et la NFR appartiennent à des couches différentes du travail d'architecture. \u003Cstrong>La NFR définit une cible de qualité, une contrainte ou une condition d'exploitation. L'ADR enregistre une réponse architecturale significative à un ou plusieurs moteurs.\u003C\u002Fstrong>",{"id":870,"data":871,"type":218},"p-conclusion-2",{"text":872},"Garder ces couches séparées rend l'architecture plus facile à raisonner. Les exigences peuvent être validées indépendamment de la technologie. Les décisions peuvent être remplacées sans réécrire l'historique. Les alternatives et les compromis restent visibles. Le travail de livraison peut être retracé jusqu'à l'intention architecturale. Les preuves peuvent montrer si le système résultant satisfait réellement l'exigence.",{"id":874,"data":875,"type":218},"p-conclusion-3",{"text":876},"La chaîne la plus solide n'est donc pas « NFR → ADR → terminé ». C'est \u003Cstrong>besoin → exigence → moteurs architecturaux → options → décision → mise en œuvre → validation → changement\u003C\u002Fstrong>. Cette chaîne transforme la documentation d'architecture d'une paperasse statique en un registre testable des raisons pour lesquelles le système a la forme qu'il a.",{"id":878,"data":879,"type":42},"h-faq",{"text":880,"level":237},"FAQ",{"id":882,"data":883,"type":882},"faq",{"items":884,"title":913},[885,889,893,897,901,905,909],{"id":886,"answer":887,"question":888},"faq1","Non. Une NFR énonce une qualité, une contrainte ou une condition d'exploitation requise. Un ADR consigne un choix architecturalement significatif effectué en réponse à des exigences, des contraintes, des risques et des compromis.","Un ADR est-il une exigence non fonctionnelle ?",{"id":890,"answer":891,"question":892},"faq2","Non. Seules les exigences qui influencent matériellement l'architecture nécessitent des décisions au niveau de l'architecture qui méritent d'être conservées. Une NFR peut aussi motiver plusieurs ADR, et un ADR peut répondre à plusieurs exigences.","Chaque NFR doit-elle avoir un ADR ?",{"id":894,"answer":895,"question":896},"faq3","Uniquement lorsque PostgreSQL est véritablement imposé comme contrainte externe. Sinon, le besoin sous-jacent doit d'abord être exprimé, et le choix de PostgreSQL doit normalement être traité comme une décision d'architecture.","« Utiliser PostgreSQL » peut-il être une NFR ?",{"id":898,"answer":899,"question":900},"faq4","Non. Un ADR consigne l'intention et le raisonnement. L'exigence est validée par des preuves appropriées telles que des tests, des mesures, des analyses, des audits ou de la télémétrie opérationnelle.","Un ADR prouve-t-il qu'une exigence de performance ou de sécurité est satisfaite ?",{"id":902,"answer":903,"question":904},"faq5","Au minimum, un ADR doit rendre le contexte et la décision clairs. Les structures courantes incluent aussi le statut et les conséquences. Les équipes peuvent ajouter des alternatives, la justification, les compromis, les liens vers les exigences, les preuves, les responsables, les dates et les relations de remplacement.","Que doit contenir un ADR ?",{"id":906,"answer":907,"question":908},"faq6","Une exigence est architecturalement significative lorsqu'elle façonne matériellement la structure du système, la technologie, les flux de données, le déploiement, le comportement transversal ou des compromis de qualité difficiles, en particulier lorsque l'échec entraîne un impact métier ou de mission élevé.","Qu'est-ce qui rend une NFR architecturalement significative ?",{"id":910,"answer":911,"question":912},"faq7","Généralement non. Une décision de remplacement doit normalement remplacer l'ancien enregistrement afin que le raisonnement historique reste traçable.","Un ancien ADR doit-il être supprimé lorsque l'architecture change ?","ADR vs NFR",{"id":915,"data":916,"type":42},"h-glossary",{"text":917,"level":237},"Glossaire",{"id":919,"data":920,"type":919},"glossary",{"title":921,"entries":922},"Termes d'architecture fondamentaux",[923,926,930,933,937,939,943,946],{"term":924,"anchor":293,"definition":925},"NFR","Exigence non fonctionnelle : abréviation pratique pour une qualité, une contrainte ou une condition d'exploitation requise du système ; la terminologie exacte varie selon la méthode et la norme.",{"term":927,"anchor":928,"definition":929},"Exigence d'attribut de qualité","quality-attribute-requirement","Exigence décrivant une propriété de qualité que le système est censé présenter dans des conditions définies, telles que la performance, la disponibilité, la sécurité, la fiabilité ou la modifiabilité.",{"term":931,"anchor":296,"definition":932},"Architecture Decision Record (ADR)","Enregistrement durable d'une décision architecturalement significative et d'un contexte suffisant pour comprendre pourquoi le choix a été fait et quelles conséquences en découlent.",{"term":934,"anchor":935,"definition":936},"Architecturally Significant Requirement (ASR)","asr","Exigence ayant un impact architectural suffisamment étendu pour influencer matériellement la conception du système.",{"term":814,"anchor":813,"definition":938},"Condition qui restreint l'espace des solutions, y compris les politiques externes, la réglementation, la plateforme, la compatibilité, les limites contractuelles ou organisationnelles.",{"term":940,"anchor":941,"definition":942},"Compromis","trade-off","Relation de conception dans laquelle l'amélioration d'un objectif, d'une propriété ou d'une dimension de coût peut en dégrader un autre.",{"term":944,"anchor":495,"definition":945},"Validation","Travail produisant des preuves utilisé pour déterminer si le système mis en œuvre satisfait l'exigence énoncée dans les conditions pertinentes.",{"term":947,"anchor":948,"definition":949},"ADR remplacé","superseded-adr","Enregistrement de décision historique qui a été remplacé par une décision faisant autorité plus récente tout en restant disponible pour la traçabilité.",{"id":951,"data":952,"type":42},"h-sources",{"text":953,"level":237},"Sources primaires et preuves de mise en œuvre",{"id":955,"data":956,"type":218},"p-sources-note",{"text":957},"Cet article distingue les normes en vigueur des preuves de mise en œuvre de projet. L'ISO\u002FIEC\u002FIEEE 29148:2018 reste en vigueur au 8 octobre 2026 mais est marquée pour révision ; l'ISO\u002FIEC 25010:2023 et l'ISO\u002FIEC\u002FIEEE 42010:2022 sont les éditions publiées en vigueur. SenseFlow est une preuve de projet originale pour le modèle de traçabilité et d'intégrité décisionnelle décrit ci-dessus.",{"id":959,"data":960,"type":967},"src-iso-29148",{"link":961,"meta":962},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html",{"image":963,"title":965,"description":966},{"url":964},"","ISO\u002FIEC\u002FIEEE 29148:2018 — Ingénierie des exigences","Norme d'ingénierie des exigences publiée en vigueur. L'ISO indique que l'édition 2018 a été examinée et confirmée en 2024 et devrait être remplacée par le DIS actuellement en cours d'élaboration.","linkTool",{"id":969,"data":970,"type":967},"src-iso-29148-dis",{"link":971,"meta":972},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html",{"image":973,"title":974,"description":975},{"url":964},"ISO\u002FIEC\u002FIEEE DIS 29148 — Ingénierie des exigences","Projet de norme internationale actuellement en cours d'élaboration et destiné à remplacer l'ISO\u002FIEC\u002FIEEE 29148:2018.",{"id":977,"data":978,"type":967},"src-iso-25010",{"link":979,"meta":980},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html",{"image":981,"title":982,"description":983},{"url":964},"ISO\u002FIEC 25010:2023 — Modèle de qualité du produit","Modèle de qualité du produit en vigueur avec neuf caractéristiques de qualité utilisées pour spécifier, mesurer et évaluer la qualité des produits TIC et logiciels.",{"id":985,"data":986,"type":967},"src-iso-42010",{"link":987,"meta":988},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":989,"title":990,"description":991},{"url":964},"ISO\u002FIEC\u002FIEEE 42010:2022 — Description de l'architecture","Norme de description de l'architecture en vigueur. Elle spécifie les concepts de description de l'architecture et les exigences de conformité sans prescrire un format d'enregistrement, une notation, un processus ou un outil unique.",{"id":993,"data":994,"type":967},"src-nygard",{"link":995,"meta":996},"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions",{"image":997,"title":998,"description":999},{"url":964},"Michael Nygard — Documenter les décisions d'architecture","Article original influent sur les ADR décrivant des enregistrements légers centrés sur le contexte, la décision, le statut et les conséquences, avec les décisions remplacées conservées pour la compréhension historique.",{"id":1001,"data":1002,"type":967},"src-sei-asr",{"link":1003,"meta":1004},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F",{"image":1005,"title":1006,"description":1007},{"url":964},"SEI — Relier les objectifs métier aux exigences architecturalement significatives","Rapport du SEI expliquant comment les exigences d'attributs de qualité et les objectifs métier orientent l'architecture logicielle et pourquoi les exigences architecturalement significatives nécessitent une élicitation explicite.",{"id":1009,"data":1010,"type":967},"src-sei-nfr",{"link":1011,"meta":1012},"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F",{"image":1013,"title":1014,"description":1015},{"url":964},"SEI — Définir les qualités système non fonctionnelles","Aperçu du SEI reliant les attributs non fonctionnels\u002Fde qualité à l'architecture, aux scénarios, aux compromis et à l'évaluation objective du système.",{"id":1017,"data":1018,"type":967},"src-sei-add",{"link":1019,"meta":1020},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F",{"image":1021,"title":1022,"description":1023},{"url":964},"SEI — Collection de méthodes Attribute-Driven Design","Méthode de conception d'architecture basée sur les exigences fonctionnelles, les exigences d'attributs de qualité et les contraintes, avec des tactiques et des patrons architecturaux sélectionnés pour satisfaire les scénarios de qualité.",{"id":1025,"data":1026,"type":967},"src-sei-doc",{"link":1027,"meta":1028},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F",{"image":1029,"title":1030,"description":1031},{"url":964},"SEI — Collection Views and Beyond","Guide de documentation d'architecture mettant l'accent sur les vues pertinentes et l'enregistrement des décisions de conception nécessaires dans le cadre du travail d'architecture.","2.31","ADR vs NFR expliqués : découvrez comment les exigences de qualité système orientent les décisions d'architecture, comment les ADR consignent les compromis et pourquoi la validation reste distincte.","\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":1041,"de":1042,"sr":1043,"es":1044,"fr":1045,"it":1046,"ru":1047,"zh":1048},"\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",[1050,1054,1058,1062,1066],{"id":1051,"name":1052,"slug":1053},72,"Critères d’acceptation","acceptance-criteria",{"id":1055,"name":1056,"slug":1057},67,"KPI et critères d’acceptation","kpis",{"id":1059,"name":1060,"slug":1061},77,"Mesure et monitoring","measurement",{"id":1063,"name":1064,"slug":1065},76,"Budgets de performance","budgets",{"id":1067,"name":1068,"slug":1069},68,"Risques, contrôles et preuves","risks-and-controls",{"id":1071,"login":1072,"email":1073,"displayName":1074},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1076,1709],{"lang":1077,"title":1078,"content":1079,"contentJson":1080,"excerpt":1708},"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":1081,"blocks":1082,"version":1707},1791475659420,[1083,1086,1090,1094,1097,1100,1103,1106,1109,1133,1136,1139,1142,1145,1172,1176,1179,1182,1185,1188,1221,1224,1227,1230,1252,1256,1259,1262,1265,1288,1291,1294,1297,1326,1329,1332,1335,1339,1342,1345,1348,1370,1373,1376,1402,1405,1409,1412,1415,1418,1447,1451,1454,1457,1460,1463,1502,1505,1508,1536,1539,1560,1563,1566,1569,1572,1575,1578,1581,1584,1586,1589,1592,1595,1597,1621,1624,1647,1650,1653,1659,1665,1671,1677,1683,1689,1695,1701],{"id":215,"data":1084,"type":218},{"text":1085},"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":220,"data":1087,"type":225},{"body":1088,"title":1089,"variant":224},"\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":227,"data":1091,"type":225},{"body":1092,"title":1093,"variant":231},"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":233,"data":1095,"type":238},{"title":1096,"maxLevel":236,"minLevel":237},"Contents",{"id":240,"data":1098,"type":42},{"text":1099,"level":237},"What is the difference between an NFR and an ADR?",{"id":244,"data":1101,"type":218},{"text":1102},"The simplest distinction is grammatical. A requirement describes a condition the system must satisfy. A decision record describes a choice the team made.",{"id":248,"data":1104,"type":218},{"text":1105},"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":252,"data":1107,"type":218},{"text":1108},"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":256,"data":1110,"type":298},{"rows":1111,"title":1127,"layout":290,"columns":1128},[1112,1115,1118,1121,1124],{"id":260,"label":1113,"values":1114},"Primary question",{"adr":263,"nfr":264},{"id":266,"label":1116,"values":1117},"Typical content",{"adr":269,"nfr":270},{"id":272,"label":1119,"values":1120},"Lifecycle role",{"adr":275,"nfr":276},{"id":278,"label":1122,"values":1123},"What proves it?",{"adr":281,"nfr":282},{"id":284,"label":1125,"values":1126},"When it changes",{"adr":287,"nfr":288},"NFR and ADR answer different questions",[1129,1131],{"id":293,"label":1130},"NFR \u002F quality requirement",{"id":296,"label":1132},"ADR \u002F architecture decision",{"id":300,"data":1134,"type":42},{"text":1135,"level":237},"What is an NFR in precise architectural terms?",{"id":304,"data":1137,"type":218},{"text":1138},"“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":308,"data":1140,"type":218},{"text":1141},"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":312,"data":1143,"type":218},{"text":1144},"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":316,"data":1146,"type":290},{"content":1147,"stretched":43,"withHeadings":14},[1148,1152,1156,1160,1164,1168],[1149,1150,1151],"Weak statement","More useful requirement shape","Why the difference matters",[1153,1154,1155],"The API must be fast","For workload W, 95% of operation X completes within T milliseconds","Defines workload, operation, metric and threshold",[1157,1158,1159],"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",[1161,1162,1163],"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",[1165,1166,1167],"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",[1169,1170,1171],"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":344,"data":1173,"type":225},{"body":1174,"title":1175,"variant":348},"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":350,"data":1177,"type":42},{"text":1178,"level":237},"What is an Architecture Decision Record?",{"id":354,"data":1180,"type":218},{"text":1181},"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":358,"data":1183,"type":218},{"text":1184},"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":362,"data":1186,"type":218},{"text":1187},"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":366,"data":1189,"type":290},{"content":1190,"stretched":43,"withHeadings":14},[1191,1195,1199,1203,1207,1210,1214,1218],[1192,1193,1194],"ADR field","What it preserves","Why it matters",[1196,1197,1198],"Context","The problem, forces, requirements, assumptions and environment surrounding the choice","Future readers can reconstruct why a choice was necessary",[1200,1201,1202],"Decision","The choice that became authoritative","Separates the selected option from discussion",[1204,1205,1206],"Status","Proposed, accepted, rejected, deprecated, superseded, or another controlled state","Prevents old decisions from silently remaining active",[386,1208,1209],"Other viable options considered","Shows that the selected solution was not the only imaginable one",[1211,1212,1213],"Rationale \u002F trade-offs","Why the option was selected and what it gives up","Makes architecture reasoning inspectable",[1215,1216,1217],"Consequences","Expected positive and negative effects, follow-up work, risks","Connects a local choice to system impact",[398,1219,1220],"When the decision became valid","Supports historical traceability and later supersession",{"id":402,"data":1222,"type":42},{"text":1223,"level":237},"The simplest example: latency requirement → architecture decision",{"id":406,"data":1225,"type":218},{"text":1226},"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":410,"data":1228,"type":218},{"text":1229},"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":414,"data":1231,"type":437},{"steps":1232,"title":1251,"orientation":436},[1233,1236,1239,1242,1245,1248],{"label":1234,"description":1235},"1. State the requirement","Define the quality target, workload, scope, threshold and validation method.",{"label":1237,"description":1238},"2. Identify architectural significance","Determine whether the requirement materially influences structure, technology, deployment, data flow or operating model.",{"label":1240,"description":1241},"3. Evaluate options","Compare alternatives such as indexing, caching, denormalization, asynchronous work, partitioning, or a different query architecture.",{"label":1243,"description":1244},"4. Record the decision","Capture the selected architecture choice, rationale, alternatives, trade-offs, status and consequences in an ADR.",{"label":1246,"description":1247},"5. Implement","Turn the decision into code, infrastructure, configuration and operational behavior.",{"label":1249,"description":1250},"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":439,"data":1253,"type":225},{"body":1254,"title":1255,"variant":443},"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":445,"data":1257,"type":42},{"text":1258,"level":237},"NFRs and ADRs usually have a many-to-many relationship",{"id":449,"data":1260,"type":218},{"text":1261},"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":453,"data":1263,"type":218},{"text":1264},"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":457,"data":1266,"type":298},{"rows":1267,"title":1280,"layout":290,"columns":1281},[1268,1271,1274,1277],{"id":461,"label":1269,"values":1270},"One NFR → many ADRs",{"adr":464,"nfr":465,"validation":466},{"id":468,"label":1272,"values":1273},"Many NFRs → one ADR",{"adr":471,"nfr":472,"validation":473},{"id":475,"label":1275,"values":1276},"ADR without a classic NFR",{"adr":478,"nfr":479,"validation":480},{"id":482,"label":1278,"values":1279},"Requirement stable, ADR changes",{"adr":485,"nfr":486,"validation":487},"Why the relationship is not one-to-one",[1282,1284,1286],{"id":293,"label":1283},"Requirement side",{"id":296,"label":1285},"Decision side",{"id":495,"label":1287},"Validation side",{"id":498,"data":1289,"type":42},{"text":1290,"level":237},"A technology choice is not automatically a requirement",{"id":502,"data":1292,"type":218},{"text":1293},"A recurring architecture error is to write a preferred technology into the requirements layer and then treat the resulting design as inevitable.",{"id":506,"data":1295,"type":218},{"text":1296},"“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":510,"data":1298,"type":290},{"content":1299,"stretched":43,"withHeadings":14},[1300,1303,1307,1311,1315,1319,1323],[1301,515,1302],"Statement","Reason",[1304,1305,1306],"All tenant-scoped reads must enforce tenant isolation","Requirement \u002F security property","Describes a property that must hold",[1308,1309,1310],"Use PostgreSQL Row Level Security for selected tenant-scoped tables","Architecture decision","Chooses a mechanism intended to help satisfy the isolation property",[1312,1313,1314],"The deployment target must run in an approved EU-operated environment","Constraint \u002F NFR-like operating condition","Restricts where the system may operate",[1316,1317,1318],"Use provider X in region Y","Architecture \u002F deployment decision unless externally mandated","Selects a particular solution inside the allowed boundary",[1320,1321,1322],"95th-percentile API latency ≤ 300 ms under workload W","Quality requirement","Defines measurable performance behavior",[1324,1309,1325],"Introduce a cache for endpoint X","Selects a tactic intended to improve the measured behavior",{"id":541,"data":1327,"type":42},{"text":1328,"level":237},"An ADR is not proof that an NFR has been satisfied",{"id":545,"data":1330,"type":218},{"text":1331},"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":549,"data":1333,"type":218},{"text":1334},"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":553,"data":1336,"type":225},{"body":1337,"title":1338,"variant":443},"\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":558,"data":1340,"type":42},{"text":1341,"level":237},"When does an NFR become architecturally significant?",{"id":562,"data":1343,"type":218},{"text":1344},"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":566,"data":1346,"type":218},{"text":1347},"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":570,"data":1349,"type":437},{"steps":1350,"title":1369,"orientation":436},[1351,1354,1357,1360,1363,1366],{"label":1352,"description":1353},"1. Ask whether the requirement changes structure","Would different values force different components, boundaries, data paths or deployment topology?",{"label":1355,"description":1356},"2. Ask whether it constrains major technology choices","Does it eliminate otherwise viable implementation options?",{"label":1358,"description":1359},"3. Ask whether it creates cross-cutting behavior","Does it affect many components, teams, interfaces or lifecycle stages?",{"label":1361,"description":1362},"4. Ask whether it creates a difficult trade-off","Does improving this property materially affect another quality, cost, schedule, complexity or risk?",{"label":1364,"description":1365},"5. Ask whether failure is expensive","Would missing the requirement create material operational, security, regulatory, financial or product impact?",{"label":1367,"description":1368},"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":593,"data":1371,"type":42},{"text":1372,"level":237},"A stronger architecture model: requirement → decision → implementation → validation",{"id":597,"data":1374,"type":218},{"text":1375},"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":601,"data":1377,"type":437},{"steps":1378,"title":1401,"orientation":436},[1379,1382,1385,1388,1390,1392,1395,1398],{"label":1380,"description":1381},"Need \u002F business goal","Why the quality or constraint matters.",{"label":1383,"description":1384},"Requirement \u002F NFR","What the system must achieve or respect.",{"label":1386,"description":1387},"Architecture drivers","Which requirements are significant enough to shape the design.",{"label":614,"description":1389},"Plausible ways to address the driver.",{"label":617,"description":1391},"The selected choice, rationale, alternatives, trade-offs and consequences.",{"label":1393,"description":1394},"Implementation","Code, data model, infrastructure, interfaces and operational mechanisms that realize the decision.",{"label":1396,"description":1397},"Validation evidence","Tests, measurements, analysis or audits demonstrating whether the original requirement is actually satisfied.",{"label":1399,"description":1400},"Change \u002F supersession","New evidence or changed requirements can trigger a new ADR while preserving historical reasoning.","Architecture traceability chain",{"id":630,"data":1403,"type":42},{"text":1404,"level":237},"Implementation evidence: how I separate requirements and decisions in SenseFlow",{"id":634,"data":1406,"type":225},{"body":1407,"title":1408,"variant":231},"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":639,"data":1410,"type":218},{"text":1411},"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":643,"data":1413,"type":218},{"text":1414},"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":647,"data":1416,"type":218},{"text":1417},"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":651,"data":1419,"type":290},{"content":1420,"stretched":43,"withHeadings":14},[1421,1425,1429,1433,1436,1439,1443],[1422,1423,1424],"SenseFlow layer","What it contains","Role in ADR\u002FNFR separation",[1426,1427,1428],"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",[1430,1431,1432],"Decision integrity","Decision, reason, alternatives, trade-offs, status, date\u002Fversion","Preserves why an architecturally significant choice became authoritative",[667,1434,1435],"Requirements, architecture, research, decision records, risks, roadmap and supporting sources","Maintains conceptual and historical Source of Truth",[671,1437,1438],"Initiatives\u002Fgoals, epics, stories, tasks and delivery state","Executes approved work without becoming the conceptual Source of Truth",[1440,1441,1442],"Change management","Current state → new evidence → proposed change → impact → decision","Allows decisions to evolve without erasing the reasoning trail",[1444,1445,1446],"End-to-end traceability","Problem → need → value → product goal → requirement → implementation → validation","Keeps decision documentation connected to the actual product and evidence lifecycle",{"id":683,"data":1448,"type":225},{"body":1449,"title":1450,"variant":348},"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":688,"data":1452,"type":42},{"text":1453,"level":237},"Enterprise project context: requirements should precede architecture choices",{"id":692,"data":1455,"type":218},{"text":1456},"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":696,"data":1458,"type":218},{"text":1459},"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":700,"data":1461,"type":42},{"text":1462,"level":237},"Common failure modes when ADRs and NFRs are mixed",{"id":704,"data":1464,"type":290},{"content":1465,"stretched":43,"withHeadings":14},[1466,1470,1474,1478,1482,1486,1490,1494,1498],[1467,1468,1469],"Failure mode","What happens","Consequence",[1471,1472,1473],"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",[1475,1476,1477],"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",[1479,1480,1481],"ADR treated as proof","A documented choice is assumed to mean the requirement is satisfied","Architecture intent replaces measurement or verification",[1483,1484,1485],"Vague NFR","Words such as fast, scalable, secure or maintainable have no measurable scope","Different stakeholders can believe the same requirement means different things",[1487,1488,1489],"No alternatives recorded","The team records only the selected technology","Future maintainers cannot reconstruct why another option was rejected",[1491,1492,1493],"No supersession model","Old ADRs are edited or deleted when the architecture changes","Historical reasoning disappears and stale decisions can remain ambiguous",[1495,1496,1497],"Every implementation detail becomes an ADR","The repository fills with low-value records","Important architecture choices become difficult to find",[1499,1500,1501],"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":744,"data":1503,"type":42},{"text":1504,"level":237},"The ADR–NFR decision framework",{"id":748,"data":1506,"type":218},{"text":1507},"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":752,"data":1509,"type":437},{"steps":1510,"title":1535,"orientation":436},[1511,1514,1517,1520,1523,1526,1529,1532],{"label":1512,"description":1513},"1. Is this a required property or external constraint?","If yes, write or reference the requirement before choosing a mechanism.",{"label":1515,"description":1516},"2. Can it be validated?","Define the scope, condition, metric, acceptance rule, analysis method or other evidence needed.",{"label":1518,"description":1519},"3. Is it architecturally significant?","Identify whether the requirement materially shapes structure, technology, data, deployment or cross-cutting trade-offs.",{"label":1521,"description":1522},"4. Are there meaningful alternatives?","Compare viable tactics or architecture options rather than jumping directly to a preferred technology.",{"label":1524,"description":1525},"5. Has a choice become authoritative?","Create or update the ADR with context, decision, rationale, alternatives, trade-offs, status and consequences.",{"label":1527,"description":1528},"6. Is the decision implemented?","Trace the ADR into design, tasks, code, configuration and operations.",{"label":1530,"description":1531},"7. Is the requirement satisfied?","Collect validation evidence against the requirement itself.",{"label":1533,"description":1534},"8. Did conditions change?","Re-evaluate the requirement and, when necessary, supersede the ADR without erasing history.","ADR–NFR classification test",{"id":781,"data":1537,"type":42},{"text":1538,"level":237},"What ADR and NFR are not",{"id":785,"data":1540,"type":298},{"rows":1541,"title":1554,"layout":290,"columns":1555},[1542,1544,1546,1548,1551],{"id":293,"label":1130,"values":1543},{"not":791,"why":792,"term":793},{"id":296,"label":617,"values":1545},{"not":796,"why":797,"term":798},{"id":800,"label":1396,"values":1547},{"not":802,"why":803,"term":804},{"id":806,"label":1549,"values":1550},"Backlog item",{"not":809,"why":810,"term":811},{"id":813,"label":1552,"values":1553},"Constraint",{"not":816,"why":817,"term":818},"Common category errors",[1556,1557,1559],{"id":822,"label":823},{"id":825,"label":1558},"It is not",{"id":828,"label":1302},{"id":830,"data":1561,"type":42},{"text":1562,"level":237},"What would change this answer?",{"id":834,"data":1564,"type":218},{"text":1565},"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":838,"data":1567,"type":218},{"text":1568},"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":842,"data":1570,"type":218},{"text":1571},"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":846,"data":1573,"type":42},{"text":1574,"level":237},"Limitations",{"id":850,"data":1576,"type":218},{"text":1577},"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":854,"data":1579,"type":218},{"text":1580},"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":858,"data":1582,"type":218},{"text":1583},"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":862,"data":1585,"type":42},{"text":864,"level":237},{"id":866,"data":1587,"type":218},{"text":1588},"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":870,"data":1590,"type":218},{"text":1591},"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":874,"data":1593,"type":218},{"text":1594},"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":878,"data":1596,"type":42},{"text":880,"level":237},{"id":882,"data":1598,"type":882},{"items":1599,"title":913},[1600,1603,1606,1609,1612,1615,1618],{"id":886,"answer":1601,"question":1602},"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":890,"answer":1604,"question":1605},"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":894,"answer":1607,"question":1608},"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":898,"answer":1610,"question":1611},"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":902,"answer":1613,"question":1614},"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":906,"answer":1616,"question":1617},"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":910,"answer":1619,"question":1620},"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?",{"id":915,"data":1622,"type":42},{"text":1623,"level":237},"Glossary",{"id":919,"data":1625,"type":919},{"title":1626,"entries":1627},"Core architecture terms",[1628,1630,1633,1635,1637,1639,1642,1644],{"term":924,"anchor":293,"definition":1629},"Non-functional requirement: practical shorthand for a required system quality, constraint, or operating condition; exact terminology varies by method and standard.",{"term":1631,"anchor":928,"definition":1632},"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":931,"anchor":296,"definition":1634},"A durable record of an architecturally significant decision and enough context to understand why the choice was made and what consequences follow.",{"term":934,"anchor":935,"definition":1636},"A requirement with sufficiently far-reaching architectural impact that it materially influences the system design.",{"term":1552,"anchor":813,"definition":1638},"A condition that restricts the solution space, including external policy, regulation, platform, compatibility, contractual or organizational boundaries.",{"term":1640,"anchor":941,"definition":1641},"Trade-off","A design relationship in which improving one objective, property or cost dimension can worsen another.",{"term":944,"anchor":495,"definition":1643},"Evidence-producing work used to determine whether the implemented system satisfies the stated requirement under the relevant conditions.",{"term":1645,"anchor":948,"definition":1646},"Superseded ADR","A historical decision record that has been replaced by a newer authoritative decision while remaining available for traceability.",{"id":951,"data":1648,"type":42},{"text":1649,"level":237},"Primary sources and implementation evidence",{"id":955,"data":1651,"type":218},{"text":1652},"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":959,"data":1654,"type":967},{"link":961,"meta":1655},{"image":1656,"title":1657,"description":1658},{"url":964},"ISO\u002FIEC\u002FIEEE 29148:2018 — Requirements Engineering","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":969,"data":1660,"type":967},{"link":971,"meta":1661},{"image":1662,"title":1663,"description":1664},{"url":964},"ISO\u002FIEC\u002FIEEE DIS 29148 — Requirements Engineering","Draft International Standard currently under development and intended to replace ISO\u002FIEC\u002FIEEE 29148:2018.",{"id":977,"data":1666,"type":967},{"link":979,"meta":1667},{"image":1668,"title":1669,"description":1670},{"url":964},"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":985,"data":1672,"type":967},{"link":987,"meta":1673},{"image":1674,"title":1675,"description":1676},{"url":964},"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":993,"data":1678,"type":967},{"link":995,"meta":1679},{"image":1680,"title":1681,"description":1682},{"url":964},"Michael Nygard — Documenting Architecture Decisions","Original influential ADR article describing lightweight records centered on context, decision, status and consequences, with superseded decisions retained for historical understanding.",{"id":1001,"data":1684,"type":967},{"link":1003,"meta":1685},{"image":1686,"title":1687,"description":1688},{"url":964},"SEI — Relating Business Goals to Architecturally Significant Requirements","SEI report explaining how quality attribute requirements and business goals drive software architecture and why architecturally significant requirements need explicit elicitation.",{"id":1009,"data":1690,"type":967},{"link":1011,"meta":1691},{"image":1692,"title":1693,"description":1694},{"url":964},"SEI — Defining Non-Functional System Qualities","SEI overview connecting non-functional\u002Fquality attributes with architecture, scenarios, trade-offs and objective system evaluation.",{"id":1017,"data":1696,"type":967},{"link":1019,"meta":1697},{"image":1698,"title":1699,"description":1700},{"url":964},"SEI — Attribute-Driven Design Method Collection","Architecture design method based on functional requirements, quality attribute requirements and constraints, with architectural tactics and patterns selected to satisfy quality scenarios.",{"id":1025,"data":1702,"type":967},{"link":1027,"meta":1703},{"image":1704,"title":1705,"description":1706},{"url":964},"SEI — Views and Beyond Collection","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.",{"lang":7,"title":208,"content":210,"contentJson":1710,"excerpt":1033},{"time":212,"blocks":1711,"version":1032},[1712,1714,1716,1718,1720,1722,1724,1726,1728,1744,1746,1748,1750,1752,1761,1763,1765,1767,1769,1771,1782,1784,1786,1788,1797,1799,1801,1803,1805,1820,1822,1824,1826,1836,1838,1840,1842,1844,1846,1848,1850,1859,1861,1863,1874,1876,1878,1880,1882,1884,1894,1896,1898,1900,1902,1904,1916,1918,1920,1931,1933,1950,1952,1954,1956,1958,1960,1962,1964,1966,1968,1970,1972,1974,1976,1986,1988,1999,2001,2003,2007,2011,2015,2019,2023,2027,2031,2035],{"id":215,"data":1713,"type":218},{"text":217},{"id":220,"data":1715,"type":225},{"body":222,"title":223,"variant":224},{"id":227,"data":1717,"type":225},{"body":229,"title":230,"variant":231},{"id":233,"data":1719,"type":238},{"title":235,"maxLevel":236,"minLevel":237},{"id":240,"data":1721,"type":42},{"text":242,"level":237},{"id":244,"data":1723,"type":218},{"text":246},{"id":248,"data":1725,"type":218},{"text":250},{"id":252,"data":1727,"type":218},{"text":254},{"id":256,"data":1729,"type":298},{"rows":1730,"title":289,"layout":290,"columns":1741},[1731,1733,1735,1737,1739],{"id":260,"label":261,"values":1732},{"adr":263,"nfr":264},{"id":266,"label":267,"values":1734},{"adr":269,"nfr":270},{"id":272,"label":273,"values":1736},{"adr":275,"nfr":276},{"id":278,"label":279,"values":1738},{"adr":281,"nfr":282},{"id":284,"label":285,"values":1740},{"adr":287,"nfr":288},[1742,1743],{"id":293,"label":294},{"id":296,"label":297},{"id":300,"data":1745,"type":42},{"text":302,"level":237},{"id":304,"data":1747,"type":218},{"text":306},{"id":308,"data":1749,"type":218},{"text":310},{"id":312,"data":1751,"type":218},{"text":314},{"id":316,"data":1753,"type":290},{"content":1754,"stretched":43,"withHeadings":14},[1755,1756,1757,1758,1759,1760],[320,321,322],[324,325,326],[328,329,330],[332,333,334],[336,337,338],[340,341,342],{"id":344,"data":1762,"type":225},{"body":346,"title":347,"variant":348},{"id":350,"data":1764,"type":42},{"text":352,"level":237},{"id":354,"data":1766,"type":218},{"text":356},{"id":358,"data":1768,"type":218},{"text":360},{"id":362,"data":1770,"type":218},{"text":364},{"id":366,"data":1772,"type":290},{"content":1773,"stretched":43,"withHeadings":14},[1774,1775,1776,1777,1778,1779,1780,1781],[370,371,372],[374,375,376],[378,379,380],[382,383,384],[386,387,388],[390,391,392],[394,395,396],[398,399,400],{"id":402,"data":1783,"type":42},{"text":404,"level":237},{"id":406,"data":1785,"type":218},{"text":408},{"id":410,"data":1787,"type":218},{"text":412},{"id":414,"data":1789,"type":437},{"steps":1790,"title":435,"orientation":436},[1791,1792,1793,1794,1795,1796],{"label":418,"description":419},{"label":421,"description":422},{"label":424,"description":425},{"label":427,"description":428},{"label":430,"description":431},{"label":433,"description":434},{"id":439,"data":1798,"type":225},{"body":441,"title":442,"variant":443},{"id":445,"data":1800,"type":42},{"text":447,"level":237},{"id":449,"data":1802,"type":218},{"text":451},{"id":453,"data":1804,"type":218},{"text":455},{"id":457,"data":1806,"type":298},{"rows":1807,"title":488,"layout":290,"columns":1816},[1808,1810,1812,1814],{"id":461,"label":462,"values":1809},{"adr":464,"nfr":465,"validation":466},{"id":468,"label":469,"values":1811},{"adr":471,"nfr":472,"validation":473},{"id":475,"label":476,"values":1813},{"adr":478,"nfr":479,"validation":480},{"id":482,"label":483,"values":1815},{"adr":485,"nfr":486,"validation":487},[1817,1818,1819],{"id":293,"label":491},{"id":296,"label":493},{"id":495,"label":496},{"id":498,"data":1821,"type":42},{"text":500,"level":237},{"id":502,"data":1823,"type":218},{"text":504},{"id":506,"data":1825,"type":218},{"text":508},{"id":510,"data":1827,"type":290},{"content":1828,"stretched":43,"withHeadings":14},[1829,1830,1831,1832,1833,1834,1835],[514,515,516],[518,519,520],[522,523,524],[526,527,528],[530,531,532],[534,535,536],[538,523,539],{"id":541,"data":1837,"type":42},{"text":543,"level":237},{"id":545,"data":1839,"type":218},{"text":547},{"id":549,"data":1841,"type":218},{"text":551},{"id":553,"data":1843,"type":225},{"body":555,"title":556,"variant":443},{"id":558,"data":1845,"type":42},{"text":560,"level":237},{"id":562,"data":1847,"type":218},{"text":564},{"id":566,"data":1849,"type":218},{"text":568},{"id":570,"data":1851,"type":437},{"steps":1852,"title":591,"orientation":436},[1853,1854,1855,1856,1857,1858],{"label":574,"description":575},{"label":577,"description":578},{"label":580,"description":581},{"label":583,"description":584},{"label":586,"description":587},{"label":589,"description":590},{"id":593,"data":1860,"type":42},{"text":595,"level":237},{"id":597,"data":1862,"type":218},{"text":599},{"id":601,"data":1864,"type":437},{"steps":1865,"title":628,"orientation":436},[1866,1867,1868,1869,1870,1871,1872,1873],{"label":605,"description":606},{"label":608,"description":609},{"label":611,"description":612},{"label":614,"description":615},{"label":617,"description":618},{"label":620,"description":621},{"label":623,"description":624},{"label":626,"description":627},{"id":630,"data":1875,"type":42},{"text":632,"level":237},{"id":634,"data":1877,"type":225},{"body":636,"title":637,"variant":231},{"id":639,"data":1879,"type":218},{"text":641},{"id":643,"data":1881,"type":218},{"text":645},{"id":647,"data":1883,"type":218},{"text":649},{"id":651,"data":1885,"type":290},{"content":1886,"stretched":43,"withHeadings":14},[1887,1888,1889,1890,1891,1892,1893],[655,656,657],[659,660,661],[663,664,665],[667,668,669],[671,672,673],[675,676,677],[679,680,681],{"id":683,"data":1895,"type":225},{"body":685,"title":686,"variant":348},{"id":688,"data":1897,"type":42},{"text":690,"level":237},{"id":692,"data":1899,"type":218},{"text":694},{"id":696,"data":1901,"type":218},{"text":698},{"id":700,"data":1903,"type":42},{"text":702,"level":237},{"id":704,"data":1905,"type":290},{"content":1906,"stretched":43,"withHeadings":14},[1907,1908,1909,1910,1911,1912,1913,1914,1915],[708,709,710],[712,713,714],[716,717,718],[720,721,722],[724,725,726],[728,729,730],[732,733,734],[736,737,738],[740,741,742],{"id":744,"data":1917,"type":42},{"text":746,"level":237},{"id":748,"data":1919,"type":218},{"text":750},{"id":752,"data":1921,"type":437},{"steps":1922,"title":779,"orientation":436},[1923,1924,1925,1926,1927,1928,1929,1930],{"label":756,"description":757},{"label":759,"description":760},{"label":762,"description":763},{"label":765,"description":766},{"label":768,"description":769},{"label":771,"description":772},{"label":774,"description":775},{"label":777,"description":778},{"id":781,"data":1932,"type":42},{"text":783,"level":237},{"id":785,"data":1934,"type":298},{"rows":1935,"title":819,"layout":290,"columns":1946},[1936,1938,1940,1942,1944],{"id":293,"label":789,"values":1937},{"not":791,"why":792,"term":793},{"id":296,"label":617,"values":1939},{"not":796,"why":797,"term":798},{"id":800,"label":623,"values":1941},{"not":802,"why":803,"term":804},{"id":806,"label":807,"values":1943},{"not":809,"why":810,"term":811},{"id":813,"label":814,"values":1945},{"not":816,"why":817,"term":818},[1947,1948,1949],{"id":822,"label":823},{"id":825,"label":826},{"id":828,"label":516},{"id":830,"data":1951,"type":42},{"text":832,"level":237},{"id":834,"data":1953,"type":218},{"text":836},{"id":838,"data":1955,"type":218},{"text":840},{"id":842,"data":1957,"type":218},{"text":844},{"id":846,"data":1959,"type":42},{"text":848,"level":237},{"id":850,"data":1961,"type":218},{"text":852},{"id":854,"data":1963,"type":218},{"text":856},{"id":858,"data":1965,"type":218},{"text":860},{"id":862,"data":1967,"type":42},{"text":864,"level":237},{"id":866,"data":1969,"type":218},{"text":868},{"id":870,"data":1971,"type":218},{"text":872},{"id":874,"data":1973,"type":218},{"text":876},{"id":878,"data":1975,"type":42},{"text":880,"level":237},{"id":882,"data":1977,"type":882},{"items":1978,"title":913},[1979,1980,1981,1982,1983,1984,1985],{"id":886,"answer":887,"question":888},{"id":890,"answer":891,"question":892},{"id":894,"answer":895,"question":896},{"id":898,"answer":899,"question":900},{"id":902,"answer":903,"question":904},{"id":906,"answer":907,"question":908},{"id":910,"answer":911,"question":912},{"id":915,"data":1987,"type":42},{"text":917,"level":237},{"id":919,"data":1989,"type":919},{"title":921,"entries":1990},[1991,1992,1993,1994,1995,1996,1997,1998],{"term":924,"anchor":293,"definition":925},{"term":927,"anchor":928,"definition":929},{"term":931,"anchor":296,"definition":932},{"term":934,"anchor":935,"definition":936},{"term":814,"anchor":813,"definition":938},{"term":940,"anchor":941,"definition":942},{"term":944,"anchor":495,"definition":945},{"term":947,"anchor":948,"definition":949},{"id":951,"data":2000,"type":42},{"text":953,"level":237},{"id":955,"data":2002,"type":218},{"text":957},{"id":959,"data":2004,"type":967},{"link":961,"meta":2005},{"image":2006,"title":965,"description":966},{"url":964},{"id":969,"data":2008,"type":967},{"link":971,"meta":2009},{"image":2010,"title":974,"description":975},{"url":964},{"id":977,"data":2012,"type":967},{"link":979,"meta":2013},{"image":2014,"title":982,"description":983},{"url":964},{"id":985,"data":2016,"type":967},{"link":987,"meta":2017},{"image":2018,"title":990,"description":991},{"url":964},{"id":993,"data":2020,"type":967},{"link":995,"meta":2021},{"image":2022,"title":998,"description":999},{"url":964},{"id":1001,"data":2024,"type":967},{"link":1003,"meta":2025},{"image":2026,"title":1006,"description":1007},{"url":964},{"id":1009,"data":2028,"type":967},{"link":1011,"meta":2029},{"image":2030,"title":1014,"description":1015},{"url":964},{"id":1017,"data":2032,"type":967},{"link":1019,"meta":2033},{"image":2034,"title":1022,"description":1023},{"url":964},{"id":1025,"data":2036,"type":967},{"link":1027,"meta":2037},{"image":2038,"title":1030,"description":1031},{"url":964},"Post erfolgreich abgerufen",{"items":2041,"source":2070,"manualIds":2071,"manualMatchedIds":2072},[2042,2049,2056,2063],{"id":2043,"slug":2044,"title":2045,"excerpt":2046,"featuredImage":2047,"publishedAt":2048},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Maîtriser le flux de travail SEO : Stratégies d'optimisation essentielles pour la croissance organique","Un flux de travail SEO structuré est crucial pour une croissance organique durable. Découvrez les dix stratégies fondamentales, de la recherche de mots-clés et l'optimisation technique à la qualité du contenu et l'analyse des performances.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z",{"id":2050,"slug":2051,"title":2052,"excerpt":2053,"featuredImage":2054,"publishedAt":2055},"455","zbt-z8102ax-dual-sim-failover-test","Basculement double SIM du ZBT Z8102AX : ce qui fonctionne, ce qui manque et ce qui nécessite un meilleur firmware","Le ZBT Z8102AX est un routeur OpenWrt 5G double SIM, mais le matériel double SIM à lui seul n'est pas la même chose qu'un basculement intelligent. Le routeur reconnaît la carte SIM et se connecte avec succès, mais la commutation automatique, la récupération du modem, les décisions basées sur le signal et une logique de basculement propre nécessitent encore des tests plus approfondis.","\u002Fuploads\u002F2026\u002F06\u002Fopenwrt-router-review-dual-sim-03-1781620592829-7t77j7.webp","2026-06-16T10:40:00.000Z",{"id":2057,"slug":2058,"title":2059,"excerpt":2060,"featuredImage":2061,"publishedAt":2062},"435","ultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks","Guide ultime des critères d'acceptation pour l'adoption des LLM dans les playbooks d'entreprise","Maîtrisez l'art de définir des critères d'acceptation précis pour garantir une intégration réussie des LLM dans votre environnement d'entreprise. Ce guide complet fournit des cadres d'action, des exemples et des bonnes pratiques adaptés à une adoption pilotée par des playbooks.","\u002Fuploads\u002F2026\u002F09\u002Fultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks-1788540267775-zgr6mm.webp","2026-09-06T11:50:00.000Z",{"id":2064,"slug":2065,"title":2066,"excerpt":2067,"featuredImage":2068,"publishedAt":2069},"481","generative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing","L'IA générative expliquée : modèles, recherche, outils et applications ne sont pas la même chose","L'IA générative est plus qu'un modèle. Découvrez comment les modèles, la récupération, les outils, le contexte, les environnements d'exécution et les applications s'articulent dans les systèmes d'IA en production.","\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","fallback",[],[]]