[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:it":3,"public-menus:all":38,"post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:it":205,"related:post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:it:1":2048},{"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","it","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":2047},{"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: decisioni architetturali e qualità del sistema non sono la stessa cosa","adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u003Cp>Un \u003Cstrong>requisito non funzionale (NFR)\u003C\u002Fstrong> descrive una qualità, un vincolo o una condizione operativa che il sistema deve soddisfare. Un \u003Cstrong>record di decisione architetturale (ADR)\u003C\u002Fstrong> registra una scelta architetturalmente significativa effettuata in risposta a requisiti, vincoli, rischi e compromessi. Sono collegati, ma non intercambiabili: un NFR afferma ciò che deve essere vero; un ADR spiega cosa è stato deciso, perché e con quali conseguenze.\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\">Risposta diretta\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>NFR = qualità o vincolo richiesto del sistema. ADR = decisione architetturale registrata.\u003C\u002Fstrong> Un obiettivo di latenza, un obiettivo di disponibilità, una regola di isolamento, una restrizione di deployment o un requisito di manutenibilità possono influenzare l'architettura. Un ADR registra quindi una scelta significativa effettuata per affrontare uno o più di tali fattori. L'ADR non sostituisce il requisito, e l'esistenza di un ADR non prova che il requisito sia stato soddisfatto.\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\">Nota su terminologia e standard\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Il termine \u003Cstrong>NFR\u003C\u002Fstrong> è ampiamente utilizzato ma non perfettamente standardizzato. Questo articolo lo usa come abbreviazione pratica per requisiti di qualità e vincoli rilevanti. Gli standard attuali sono stati ricontrollati l'\u003Cstrong>8 ottobre 2026\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 rimane attuale ma è in revisione; ISO\u002FIEC 25010:2023 e ISO\u002FIEC\u002FIEEE 42010:2022 sono le edizioni pubblicate attuali citate qui.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Contenuti\">\u003Cstrong class=\"editorjs-toc__title\">Contenuti\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\">Qual è la differenza tra un NFR e un ADR?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">Cos'è un NFR in termini architetturali precisi?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-16\" class=\"editorjs-toc__link\">Cos'è un Architecture Decision Record?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-21\" class=\"editorjs-toc__link\">L'esempio più semplice: requisito di latenza → decisione architetturale\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-26\" class=\"editorjs-toc__link\">Gli NFR e gli ADR di solito hanno una relazione molti-a-molti\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-30\" class=\"editorjs-toc__link\">Una scelta tecnologica non è automaticamente un requisito\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-34\" class=\"editorjs-toc__link\">Un ADR non è prova che un NFR sia stato soddisfatto\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-38\" class=\"editorjs-toc__link\">Quando un NFR diventa architetturalmente significativo?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-42\" class=\"editorjs-toc__link\">Un modello architetturale più forte: requisito → decisione → implementazione → validazione\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-45\" class=\"editorjs-toc__link\">Evidenza di implementazione: come separo requisiti e decisioni in SenseFlow\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-52\" class=\"editorjs-toc__link\">Contesto di progetto enterprise: i requisiti dovrebbero precedere le scelte architetturali\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-55\" class=\"editorjs-toc__link\">Modalità di fallimento comuni quando ADR e NFR vengono mescolati\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-57\" class=\"editorjs-toc__link\">Il framework decisionale ADR–NFR\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-60\" class=\"editorjs-toc__link\">Cosa non sono ADR e NFR\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-62\" class=\"editorjs-toc__link\">Cosa cambierebbe questa risposta?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-66\" class=\"editorjs-toc__link\">Limitazioni\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-70\" class=\"editorjs-toc__link\">Conclusione\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\">Glossario\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Fonti primarie ed evidenze di implementazione\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-5\">Qual è la differenza tra un NFR e un ADR?\u003C\u002Fh2>\n\u003Cp>La distinzione più semplice è grammaticale. Un requisito descrive una condizione che il sistema deve soddisfare. Un record di decisione descrive una scelta fatta dal team.\u003C\u002Fp>\n\u003Cp>Ad esempio, \u003Cstrong>\"L'API deve restituire il 95% delle richieste di lettura entro 300 ms sotto il carico di riferimento concordato\"\u003C\u002Fstrong> è un requisito di qualità. \u003Cstrong>\"Usare una cache read-through per questo carico di lavoro perché il percorso misurato solo database non può soddisfare l'obiettivo di latenza senza un costo inaccettabile\"\u003C\u002Fstrong> è una decisione architetturale.\u003C\u002Fp>\n\u003Cp>La prima affermazione rimane valida anche se l'implementazione cambia. La seconda affermazione può essere successivamente sostituita da un'altra decisione se il carico di lavoro, la tecnologia, il modello di costo o le evidenze cambiano.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">NFR e ADR rispondono a domande diverse\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">NFR \u002F requisito di 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\">ADR \u002F decisione architetturale\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\">Domanda 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\">Contenuto tipico\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\">Ruolo nel ciclo di vita\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\">Cosa lo prova?\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\">Quando cambia\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\">Cos'è un NFR in termini architetturali precisi?\u003C\u002Fh2>\n\u003Cp>\"Requisito non funzionale\" è un'etichetta industriale conveniente, ma può nascondere diversi tipi di affermazioni. Nel lavoro architetturale, la distinzione utile è tra \u003Cstrong>comportamento funzionale\u003C\u002Fstrong>, \u003Cstrong>requisiti di qualità\u003C\u002Fstrong> e \u003Cstrong>vincoli\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC 25010:2023 fornisce un modello di qualità del prodotto con nove caratteristiche e sottocaratteristiche che possono essere utilizzate per specificare e valutare la qualità dei prodotti ICT e software. Il lavoro architetturale del SEI tratta similmente i requisiti degli attributi di qualità come principali fattori trainanti dell'architettura software.\u003C\u002Fp>\n\u003Cp>Un NFR utile non è quindi \"il sistema dovrebbe essere veloce\" o \"la piattaforma deve essere sicura\". Queste affermazioni nominano aspirazioni. Un requisito che guida l'architettura dovrebbe rendere la proprietà attesa sufficientemente testabile affinché le alternative di progettazione e le evidenze successive possano essere valutate rispetto ad esso.\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\">Affermazione debole\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Forma del requisito più utile\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Perché la differenza conta\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'API deve essere veloce\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Per il carico di lavoro W, il 95% dell'operazione X si completa entro T millisecondi\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Definisce carico di lavoro, operazione, metrica e soglia\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il servizio deve essere disponibile\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il servizio S soddisfa un obiettivo di disponibilità concordato nella finestra di misurazione M, escludendo condizioni di manutenzione esplicitamente definite\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Rende la disponibilità misurabile e definisce l'ambito\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">I dati dei tenant devono essere sicuri\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Una richiesta autenticata per il tenant A non deve mai recuperare o modificare i dati del tenant B attraverso i percorsi applicativi supportati\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Trasforma un obiettivo di sicurezza vago in una proprietà di isolamento\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il sistema dovrebbe scalare\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il sistema supporta il carico di lavoro W con concorrenza C rispettando le soglie di latenza e tasso di errore\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Collega la scalabilità a un comportamento del servizio misurabile\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Abbiamo bisogno di PostgreSQL\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Non è un NFR di per sé; indicare prima le qualità di persistenza richieste o il vincolo esterno\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Una scelta tecnologica è normalmente una soluzione, non il requisito che deve soddisfare\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\">Un requisito dovrebbe descrivere il bisogno prima del meccanismo\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Se "usa Kubernetes", "usa PostgreSQL", "usa microservizi" o "usa la ricerca vettoriale" appare come requisito, chiediti se è davvero un vincolo esterno o se la soluzione è stata scritta prima che il bisogno di qualità sottostante fosse reso esplicito.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-16\">Cos'è un Architecture Decision Record?\u003C\u002Fh2>\n\u003Cp>Un Architecture Decision Record è una registrazione compatta di una decisione architetturale importante. La formulazione originale dell'ADR di Michael Nygard enfatizza il \u003Cstrong>contesto\u003C\u002Fstrong>, la \u003Cstrong>decisione\u003C\u002Fstrong>, il suo \u003Cstrong>stato\u003C\u002Fstrong> e le \u003Cstrong>conseguenze\u003C\u002Fstrong> risultanti.\u003C\u002Fp>\n\u003Cp>L'oggetto importante è la decisione, non il modello. Team diversi usano formati ADR diversi. Un record più ricco può anche preservare alternative, criteri di decisione, compromessi, evidenze, collegamenti ai requisiti e la data o versione da cui la decisione si applica.\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC\u002FIEEE 42010:2022 è più ampio della pratica ADR: specifica i requisiti per le descrizioni architetturali e i loro concetti, mentre esplicitamente non prescrive un processo, una notazione, uno strumento, un formato o un mezzo per registrare una descrizione architetturale. Un ADR è quindi una tecnica pratica di registrazione delle decisioni, non un formato imposto da 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\">Campo ADR\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Cosa preserva\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Perché è importante\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contesto\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il problema, le forze, i requisiti, le assunzioni e l'ambiente che circondano la scelta\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">I lettori futuri possono ricostruire perché una scelta era necessaria\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisione\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La scelta che è diventata autorevole\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Separa l'opzione selezionata dalla discussione\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Stato\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Proposto, accettato, rifiutato, deprecato, sostituito o un altro stato controllato\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Impedisce che le vecchie decisioni rimangano attive silenziosamente\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alternative\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Altre opzioni valide considerate\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mostra che la soluzione selezionata non era l'unica immaginabile\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Motivazione \u002F compromessi\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Perché l'opzione è stata selezionata e cosa si rinuncia\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Rende il ragionamento architetturale ispezionabile\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Conseguenze\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Effetti positivi e negativi attesi, lavoro successivo, rischi\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Collega una scelta locale all'impatto sul sistema\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Data \u002F versione\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quando la decisione è diventata valida\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Supporta la tracciabilità storica e la successiva sostituzione\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-21\">L'esempio più semplice: requisito di latenza → decisione architetturale\u003C\u002Fh2>\n\u003Cp>Supponiamo che un product owner e un team di ingegneria concordino che un endpoint di ricerca debba restituire la prima pagina di risultati entro 400 ms al 95° percentile sotto un carico di riferimento definito.\u003C\u002Fp>\n\u003Cp>Quel target non è un ADR. È un requisito di qualità. Il lavoro architetturale inizia chiedendosi quale design possa soddisfarlo sotto gli altri vincoli del sistema.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Dal requisito all'evidenza\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. Enunciare il requisito\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Definire il target di qualità, il carico, l'ambito, la soglia e il metodo di validazione.\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. Identificare la rilevanza architetturale\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Determinare se il requisito influenza materialmente la struttura, la tecnologia, il deployment, il flusso di dati o il modello operativo.\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. Valutare le opzioni\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Confrontare alternative come indicizzazione, caching, denormalizzazione, lavoro asincrono, partizionamento o una diversa architettura di query.\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. Registrare la decisione\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Catturare la scelta architetturale selezionata, la motivazione, le alternative, i compromessi, lo stato e le conseguenze in 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. Implementare\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Trasformare la decisione in codice, infrastruttura, configurazione e comportamento operativo.\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. Validare\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Misurare il sistema reale rispetto al requisito originale. Il risultato del test valida l'NFR; il solo ADR no.\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\">Dove si ferma l'esempio semplice\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">I sistemi reali raramente hanno un solo requisito e una sola decisione. Le prestazioni possono entrare in conflitto con costo, consistenza, operabilità, sicurezza, manutenibilità, consumo energetico o rischio di consegna. Il modello utile è quindi un grafo di tracciabilità, non una mappatura uno-a-uno.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-26\">Gli NFR e gli ADR di solito hanno una relazione molti-a-molti\u003C\u002Fh2>\n\u003Cp>Un requisito di qualità può guidare diverse decisioni architetturali. Un requisito di isolamento dei tenant, ad esempio, può influenzare la propagazione dell'identità, lo scoping del database, il design dei job in background, le chiavi di cache, il logging di audit e gli strumenti amministrativi.\u003C\u002Fp>\n\u003Cp>Una decisione architetturale può anche rispondere a diversi requisiti contemporaneamente. Scegliere un confine di elaborazione asincrona potrebbe migliorare la reattività e l'isolamento dei guasti, introducendo al contempo compromessi di consistenza, complessità, osservabilità e operatività.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Perché la relazione non è uno-a-uno\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\">Lato requisito\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\">Lato decisione\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\">Lato validazione\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\">Un NFR → molti 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\">Molti NFR → 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 senza un NFR classico\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\">Requisito stabile, ADR cambia\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\">Una scelta tecnologica non è automaticamente un requisito\u003C\u002Fh2>\n\u003Cp>Un errore architetturale ricorrente è scrivere una tecnologia preferita nel livello dei requisiti e poi trattare il design risultante come inevitabile.\u003C\u002Fp>\n\u003Cp>\"Il sistema deve usare PostgreSQL\" può essere un vincolo legittimo se un contratto, una politica di piattaforma, un requisito di compatibilità, una regola di licenza, uno standard organizzativo o un confine operativo esistente impongono effettivamente PostgreSQL. Ma se la necessità reale è la consistenza transazionale, l'interrogazione strutturata, la familiarità operativa o un obiettivo di ripristino specifico, il requisito dovrebbe enunciare quella necessità e la selezione tecnologica dovrebbe essere registrata come decisione.\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\">Affermazione\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Classificazione\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Motivo\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tutte le letture con ambito tenant devono applicare l'isolamento dei tenant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Requisito \u002F proprietà di sicurezza\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Descrive una proprietà che deve valere\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Usare PostgreSQL Row Level Security per tabelle selezionate con ambito tenant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisione architetturale\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sceglie un meccanismo inteso ad aiutare a soddisfare la proprietà di isolamento\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il target di deployment deve essere eseguito in un ambiente approvato operato nell'UE\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Vincolo \u002F condizione operativa simile a un NFR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Limita dove il sistema può operare\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Usare il provider X nella regione Y\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisione architetturale \u002F di deployment se non imposta esternamente\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Seleziona una soluzione particolare all'interno del confine consentito\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Latenza API al 95° percentile ≤ 300 ms sotto il carico W\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Requisito di qualità\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Definisce un comportamento prestazionale misurabile\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Introdurre una cache per l'endpoint X\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisione architetturale\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Seleziona una tattica intesa a migliorare il comportamento misurato\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-34\">Un ADR non è prova che un NFR sia stato soddisfatto\u003C\u002Fh2>\n\u003Cp>La documentazione delle decisioni e la validazione del sistema rispondono a domande diverse. Un ADR può mostrare che prestazioni, sicurezza, resilienza o manutenibilità sono state considerate. Non può da solo dimostrare che il sistema consegnato raggiunga effettivamente quelle proprietà.\u003C\u002Fp>\n\u003Cp>La prova deve provenire dal metodo di validazione appropriato al requisito: benchmark, test di carico, test di guasto, test di sicurezza, analisi architetturale, audit, ispezione, telemetria operativa, esercizio di ripristino, studio utente o un'altra forma di evidenza.\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\">Non confondere l'intento con l'evidenza\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>ADR:\u003C\u002Fstrong> "Abbiamo selezionato il design X perché si prevede che soddisfi il requisito R sotto le assunzioni A."\u003Cbr>\u003Cstrong>Validazione:\u003C\u002Fstrong> "L'evidenza misurata o analizzata E mostra se il sistema implementato soddisfa effettivamente R."\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-38\">Quando un NFR diventa architetturalmente significativo?\u003C\u002Fh2>\n\u003Cp>Non ogni requisito non funzionale merita una decisione architetturale. Il sottoinsieme importante è costituito dai requisiti che plasmano materialmente l'architettura o forzano compromessi attraverso il sistema.\u003C\u002Fp>\n\u003Cp>La letteratura SEI utilizza il concetto di \u003Cstrong>requisiti architetturalmente significativi\u003C\u002Fstrong> per i requisiti con effetto architetturale di vasta portata. Attributi di qualità come prestazioni, affidabilità, sicurezza e modificabilità sono frequenti fonti di tali driver, specialmente quando comportano un elevato valore aziendale o di missione.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Test di significatività architetturale\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. Chiedersi se il requisito cambia la struttura\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Valori diversi forzerebbero componenti, confini, percorsi dati o topologie di deployment differenti?\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. Chiedersi se vincola scelte tecnologiche importanti\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Elimina opzioni di implementazione altrimenti praticabili?\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. Chiedersi se crea comportamento trasversale\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Influenza molti componenti, team, interfacce o fasi del ciclo di vita?\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. Chiedersi se crea un compromesso difficile\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Migliorare questa proprietà influisce materialmente su un'altra qualità, costo, pianificazione, complessità o rischio?\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. Chiedersi se il fallimento è costoso\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Mancare il requisito creerebbe un impatto materiale operativo, di sicurezza, normativo, finanziario o di prodotto?\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. Registrare le decisioni solo dove il ragionamento vale la pena di essere preservato\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Non creare ADR per ogni scelta di codifica locale; preservare le decisioni architetturalmente significative e la loro motivazione.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-42\">Un modello architetturale più forte: requisito → decisione → implementazione → validazione\u003C\u002Fh2>\n\u003Cp>La connessione più utile tra NFR e ADR è la tracciabilità. Un requisito dovrebbe poter puntare alle decisioni architetturali che lo affrontano; un ADR dovrebbe identificare i driver a cui risponde; il lavoro di implementazione dovrebbe realizzare la decisione; la validazione dovrebbe ritornare al requisito originale.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Catena di tracciabilità architetturale\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\">Bisogno \u002F obiettivo aziendale\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Perché la qualità o il vincolo è importante.\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\">Requisito \u002F NFR\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Cosa il sistema deve raggiungere o rispettare.\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\">Driver architetturali\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Quali requisiti sono abbastanza significativi da plasmare il design.\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\">Opzioni\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Modi plausibili per affrontare il driver.\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\">La scelta selezionata, la motivazione, le alternative, i compromessi e le conseguenze.\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\">Implementazione\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Codice, modello dati, infrastruttura, interfacce e meccanismi operativi che realizzano la decisione.\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\">Evidenza di validazione\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Test, misurazioni, analisi o audit che dimostrano se il requisito originale è effettivamente soddisfatto.\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\">Cambiamento \u002F sostituzione\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Nuove evidenze o requisiti modificati possono attivare un nuovo ADR preservando il ragionamento storico.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-45\">Evidenza di implementazione: come separo requisiti e decisioni in 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\">Implementazione originale \u002F evidenza di progetto\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">La sezione seguente descrive la struttura del mio progetto SenseFlow. È evidenza di implementazione per la separazione in questo articolo, non un'affermazione che ogni team debba usare lo stesso modello di documentazione.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>In SenseFlow, la Source of Truth del progetto colloca esplicitamente i requisiti non funzionali all'interno della struttura dei requisiti insieme a dipendenze, rischi, assunzioni, criteri di accettazione e un metodo di validazione. Il modello di documentazione definisce separatamente l'integrità delle decisioni per le decisioni significative.\u003C\u002Fp>\n\u003Cp>Per le decisioni significative di SenseFlow, i campi registrati sono \u003Cstrong>Decisione, Motivo, Alternative, Compromessi, Stato e Data \u002F Versione\u003C\u002Fstrong>. Le principali decisioni architetturali e di prodotto sono destinate a rimanere storicamente tracciabili anziché essere sovrascritte quando il progetto evolve.\u003C\u002Fp>\n\u003Cp>SenseFlow assegna anche ruoli operativi diversi a Confluence e Jira. Confluence è l'ambiente strutturato di conoscenza e decisione; Jira gestisce il lavoro di delivery azionabile. Le Epic principali di Jira dovrebbero collegarsi alla documentazione di prodotto o dei requisiti pertinente. Questo preserva la catena dall'intento di prodotto attraverso requisiti e decisioni fino all'implementazione, invece di trasformare il backlog nella Source of Truth architetturale.\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\">Livello SenseFlow\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Cosa contiene\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ruolo nella separazione ADR\u002FNFR\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Struttura di prodotto \u002F requisiti\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Obiettivo di prodotto, capacità, epic, user story, criteri di accettazione, attività tecniche; i requisiti possono includere NFR e metodo di validazione\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Preserva cosa deve essere raggiunto e come verrà verificato il successo\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Integrità delle decisioni\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisione, motivo, alternative, compromessi, stato, data\u002Fversione\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Preserva perché una scelta architetturalmente significativa è diventata autorevole\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\">Requisiti, architettura, ricerca, record delle decisioni, rischi, roadmap e fonti di supporto\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mantiene la Source of Truth concettuale e storica\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\">Iniziative\u002Fobiettivi, epic, storie, attività e stato di delivery\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Esegue il lavoro approvato senza diventare la Source of Truth concettuale\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Gestione del cambiamento\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Stato attuale → nuova evidenza → cambiamento proposto → impatto → decisione\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Consente alle decisioni di evolversi senza cancellare la traccia del ragionamento\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tracciabilità end-to-end\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Problema → bisogno → valore → obiettivo di prodotto → requisito → implementazione → validazione\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mantiene la documentazione delle decisioni connessa al prodotto reale e al ciclo di vita dell'evidenza\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\">Cosa dimostra questa implementazione\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Un requisito e una decisione possono vivere vicini senza essere collassati in un unico record. Il requisito rimane l'obiettivo; la decisione rimane la storia del ragionamento; il lavoro di delivery implementa la decisione; la validazione ritorna all'obiettivo.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-52\">Contesto di progetto enterprise: i requisiti dovrebbero precedere le scelte architetturali\u003C\u002Fh2>\n\u003Cp>La stessa separazione è utile nel lavoro di progetto orientato all'enterprise. Le decisioni architetturali prese prima che requisiti, rischi, vincoli e condizioni di accettazione siano sufficientemente compresi possono trasformare le preferenze in false necessità.\u003C\u002Fp>\n\u003Cp>Per Enterprise Aaasaasa 0.1, la lezione pertinente è metodologica piuttosto che un'affermazione su un particolare ADR: requisiti, architettura, validazione, milestone, gestione del rischio e accettazione appartengono a un sistema di delivery connesso. Una scelta architetturale dovrebbe rimanere tracciabile rispetto al requisito o vincolo che intende affrontare.\u003C\u002Fp>\n\u003Ch2 id=\"section-55\">Modalità di fallimento comuni quando ADR e NFR vengono mescolati\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\">Modalità di fallimento\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Cosa succede\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Conseguenza\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tecnologia mascherata da requisito\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Una soluzione preferita viene scritta come \"deve usare X\" senza stabilire il bisogno sottostante\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le alternative non vengono mai valutate e l'architettura diventa prematuramente fissa\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NFR nascosto solo all'interno di un ADR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La decisione menziona un obiettivo di prestazioni\u002Fsicurezza assente dalla baseline dei requisiti\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'obiettivo è difficile da validare, prioritizzare o gestire in modo indipendente\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ADR trattato come prova\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Si presume che una scelta documentata significhi che il requisito è soddisfatto\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'intento architetturale sostituisce la misurazione o la verifica\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NFR vago\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Parole come veloce, scalabile, sicuro o manutenibile non hanno ambito misurabile\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Stakeholder diversi possono credere che lo stesso requisito significhi cose diverse\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nessuna alternativa registrata\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il team registra solo la tecnologia selezionata\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">I futuri manutentori non possono ricostruire perché un'altra opzione è stata rifiutata\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nessun modello di sostituzione\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">I vecchi ADR vengono modificati o eliminati quando l'architettura cambia\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il ragionamento storico scompare e le decisioni obsolete possono rimanere ambigue\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ogni dettaglio implementativo diventa un ADR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il repository si riempie di record di scarso valore\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le scelte architetturali importanti diventano difficili da trovare\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il backlog diventa la fonte di verità dell'architettura\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le attività Jira vengono trattate come l'unica spiegazione del sistema\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Lo stato di consegna sopravvive, ma la motivazione architetturale e i driver di qualità vanno persi\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-57\">Il framework decisionale ADR–NFR\u003C\u002Fh2>\n\u003Cp>Quando un team incontra una nuova preoccupazione architetturale, la seguente sequenza aiuta a determinare cosa appartiene ai requisiti, cosa appartiene a un ADR e cosa appartiene alle prove.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Test di classificazione 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. Si tratta di una proprietà richiesta o di un vincolo esterno?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Se sì, scrivi o fai riferimento al requisito prima di scegliere un meccanismo.\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. Può essere validato?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Definisci l'ambito, la condizione, la metrica, la regola di accettazione, il metodo di analisi o altre prove necessarie.\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. È architetturalmente significativo?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Identifica se il requisito modella materialmente struttura, tecnologia, dati, distribuzione o compromessi trasversali.\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. Esistono alternative significative?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Confronta tattiche o opzioni architetturali valide invece di saltare direttamente a una tecnologia preferita.\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. Una scelta è diventata autorevole?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Crea o aggiorna l'ADR con contesto, decisione, motivazione, alternative, compromessi, stato e conseguenze.\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 decisione è implementata?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Traccia l'ADR in progettazione, attività, codice, configurazione e operazioni.\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. Il requisito è soddisfatto?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Raccogli prove di validazione rispetto al requisito stesso.\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. Le condizioni sono cambiate?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Rivaluta il requisito e, quando necessario, sostituisci l'ADR senza cancellare la storia.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-60\">Cosa non sono ADR e NFR\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Errori di categoria comuni\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\">Concetto\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\">Non è\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\">Motivo\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 requisito di 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\">Prova di validazione\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\">Elemento del 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\">Vincolo\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\">Cosa cambierebbe questa risposta?\u003C\u002Fh2>\n\u003Cp>La terminologia può evolvere. ISO\u002FIEC\u002FIEEE 29148:2018 rimane lo standard pubblicato corrente di ingegneria dei requisiti all'8 ottobre 2026, ma ISO elenca un Draft International Standard destinato a sostituirlo. Se la nuova edizione cambia la terminologia o le linee guida sui requisiti pertinenti, i riferimenti specifici per versione in questo articolo dovrebbero essere aggiornati.\u003C\u002Fp>\n\u003Cp>Anche i template ADR possono evolvere senza cambiare la distinzione centrale. Il template minimale di Michael Nygard, MADR, template specifici dell'organizzazione, strumenti di conoscenza architetturale o database decisionali strutturati possono tutti registrare decisioni. La domanda duratura è se il record preserva abbastanza contesto e motivazione per comprendere una scelta architetturalmente significativa.\u003C\u002Fp>\n\u003Cp>La distinzione collasserebbe solo se un'organizzazione scegliesse deliberatamente un artefatto combinato che memorizza sia i dati del requisito che quelli della decisione in un unico documento. Anche in quel caso, i ruoli semantici rimangono diversi: un campo enuncia il risultato o il vincolo richiesto; un altro registra la risposta scelta.\u003C\u002Fp>\n\u003Ch2 id=\"section-66\">Limitazioni\u003C\u002Fh2>\n\u003Cp>Questo articolo usa \u003Cstrong>NFR\u003C\u002Fstrong> come abbreviazione pratica. Alcuni metodi di ingegneria preferiscono termini come requisito di attributo di qualità, requisito di qualità, qualità del sistema, vincolo, obiettivo di livello di servizio o requisito architetturalmente significativo. Questi termini non sono perfettamente intercambiabili e la terminologia del progetto dovrebbe essere esplicita.\u003C\u002Fp>\n\u003Cp>Non ogni requisito può essere ridotto a una singola soglia numerica. Sicurezza, safety, manutenibilità, interoperabilità, usabilità, spiegabilità, portabilità e governance possono richiedere combinazioni di scenari, regole strutturali, analisi, controlli di processo e prove qualitative. \"Misurabile\" dovrebbe significare verificabile abbastanza per la decisione, non artificialmente numerico.\u003C\u002Fp>\n\u003Cp>Non ogni decisione architetturale necessita di un ADR formale. Il costo di documentazione dovrebbe essere proporzionale alla significatività architetturale, longevità, incertezza, complessità dei compromessi e al costo di perdere la motivazione.\u003C\u002Fp>\n\u003Ch2 id=\"section-70\">Conclusione\u003C\u002Fh2>\n\u003Cp>ADR e NFR appartengono a livelli diversi del lavoro architetturale. \u003Cstrong>L'NFR definisce un obiettivo di qualità, un vincolo o una condizione operativa. L'ADR registra una risposta architetturale significativa a uno o più driver.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Mantenere separati questi livelli rende l'architettura più facile da ragionare. I requisiti possono essere validati indipendentemente dalla tecnologia. Le decisioni possono essere sostituite senza riscrivere la storia. Le alternative e i compromessi rimangono visibili. Il lavoro di consegna può essere tracciato fino all'intento architetturale. Le prove possono mostrare se il sistema risultante soddisfa effettivamente il requisito.\u003C\u002Fp>\n\u003Cp>La catena più forte quindi non è “NFR → ADR → fatto.” È \u003Cstrong>bisogno → requisito → driver architetturali → opzioni → decisione → implementazione → validazione → cambiamento\u003C\u002Fstrong>. Quella catena trasforma la documentazione architetturale da scartoffie statiche in un registro verificabile del perché il sistema ha la forma che ha.\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 è un requisito non funzionale?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">No. Un NFR enuncia una qualità, un vincolo o una condizione operativa richiesti. Un ADR registra una scelta architetturalmente significativa fatta in risposta a requisiti, vincoli, rischi e compromessi.\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\">Ogni NFR dovrebbe avere un ADR?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">No. Solo i requisiti che influenzano materialmente l'architettura necessitano di decisioni a livello architetturale che valga la pena preservare. Un NFR può anche guidare diversi ADR, e un ADR può rispondere a diversi requisiti.\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\">“Usare PostgreSQL” può essere un NFR?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Solo quando PostgreSQL è genuinamente imposto come vincolo esterno. Altrimenti il bisogno sottostante dovrebbe essere espresso prima, e selezionare PostgreSQL dovrebbe normalmente essere trattato come una decisione architetturale.\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 dimostra che un requisito di prestazioni o sicurezza è soddisfatto?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">No. Un ADR registra intento e ragionamento. Il requisito è validato attraverso evidenze appropriate come test, misurazione, analisi, audit o telemetria operativa.\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\">Cosa dovrebbe contenere un ADR?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Come minimo, un ADR dovrebbe rendere chiari il contesto e la decisione. Le strutture comuni includono anche stato e conseguenze. I team possono aggiungere alternative, motivazioni, compromessi, collegamenti ai requisiti, evidenze, responsabili, date e relazioni di sostituzione.\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\">Cosa rende un NFR architetturalmente significativo?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Un requisito è architetturalmente significativo quando plasma materialmente la struttura del sistema, la tecnologia, i flussi di dati, il deployment, il comportamento trasversale o compromessi di qualità difficili, specialmente quando il fallimento comporta un elevato impatto aziendale o mission-critical.\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 vecchio ADR dovrebbe essere eliminato quando l'architettura cambia?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Di solito no. Una decisione sostitutiva dovrebbe normalmente sostituire il vecchio record in modo che il ragionamento storico rimanga tracciabile.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-76\">Glossario\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\">Termini architetturali fondamentali\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\">Requisito non funzionale: abbreviazione pratica per una qualità, un vincolo o una condizione operativa richiesti del sistema; la terminologia esatta varia a seconda del metodo e dello standard.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"quality-attribute-requirement\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Requisito di attributo di qualità\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un requisito che descrive una proprietà di qualità che il sistema dovrebbe mostrare in condizioni definite, come prestazioni, disponibilità, sicurezza, affidabilità o modificabilità.\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\">Un registro durevole di una decisione architetturalmente significativa e del contesto sufficiente per comprendere perché la scelta è stata fatta e quali conseguenze ne derivano.\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\">Requisito architetturalmente significativo (ASR)\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un requisito con un impatto architetturale sufficientemente ampio da influenzare materialmente il design del sistema.\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\">Vincolo\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Una condizione che restringe lo spazio delle soluzioni, inclusi policy esterne, regolamentazioni, piattaforme, compatibilità, confini contrattuali o organizzativi.\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\">Compromesso\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Una relazione di design in cui migliorare un obiettivo, una proprietà o una dimensione di costo può peggiorarne un'altra.\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\">Validazione\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Lavoro che produce evidenze utilizzato per determinare se il sistema implementato soddisfa il requisito dichiarato nelle condizioni rilevanti.\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 sostituito\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un registro decisionale storico che è stato sostituito da una decisione autorevole più recente pur rimanendo disponibile per la tracciabilità.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-78\">Fonti primarie ed evidenze di implementazione\u003C\u002Fh2>\n\u003Cp>Questo articolo separa gli standard attuali dalle evidenze di implementazione del progetto. ISO\u002FIEC\u002FIEEE 29148:2018 rimane attuale all'8 ottobre 2026 ma è contrassegnato per revisione; ISO\u002FIEC 25010:2023 e ISO\u002FIEC\u002FIEEE 42010:2022 sono edizioni pubblicate attuali. SenseFlow è evidenza originale del progetto per il modello di tracciabilità e integrità decisionale descritto sopra.\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 — Ingegneria dei requisiti\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Standard attuale pubblicato di ingegneria dei requisiti. ISO afferma che l'edizione 2018 è stata riesaminata e confermata nel 2024 e si prevede che sarà sostituita dal DIS attualmente in sviluppo.\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 — Ingegneria dei requisiti\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Draft International Standard attualmente in sviluppo e destinato a sostituire 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 — Modello di qualità del prodotto\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Modello attuale di qualità del prodotto con nove caratteristiche di qualità utilizzate per specificare, misurare e valutare la qualità dei prodotti ICT e software.\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 — Descrizione dell'architettura\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Standard attuale di descrizione dell'architettura. Specifica i concetti di descrizione dell'architettura e i requisiti di conformità senza prescrivere un formato di registrazione, una notazione, un processo o uno strumento.\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 — Documentare le decisioni architetturali\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Articolo originale influente sugli ADR che descrive registri leggeri incentrati su contesto, decisione, stato e conseguenze, con le decisioni sostituite conservate per la comprensione storica.\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 — Collegare gli obiettivi di business ai requisiti architetturalmente significativi\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Rapporto SEI che spiega come i requisiti di attributi di qualità e gli obiettivi di business guidano l'architettura software e perché i requisiti architetturalmente significativi necessitano di elicitazione esplicita.\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 — Definire le qualità non funzionali del sistema\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Panoramica SEI che collega attributi non funzionali\u002Fdi qualità con architettura, scenari, compromessi e valutazione oggettiva del sistema.\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 — Raccolta del metodo Attribute-Driven Design\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Metodo di progettazione architetturale basato su requisiti funzionali, requisiti di attributi di qualità e vincoli, con tattiche e pattern architetturali selezionati per soddisfare scenari di 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 — Raccolta Views and Beyond\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Guida alla documentazione architetturale che enfatizza le viste rilevanti e la registrazione delle decisioni di design necessarie come parte del lavoro architetturale.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1032},1791476202767,[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},"Un \u003Cstrong>requisito non funzionale (NFR)\u003C\u002Fstrong> descrive una qualità, un vincolo o una condizione operativa che il sistema deve soddisfare. Un \u003Cstrong>record di decisione architetturale (ADR)\u003C\u002Fstrong> registra una scelta architetturalmente significativa effettuata in risposta a requisiti, vincoli, rischi e compromessi. Sono collegati, ma non intercambiabili: un NFR afferma ciò che deve essere vero; un ADR spiega cosa è stato deciso, perché e con quali conseguenze.","paragraph",{"id":220,"data":221,"type":225},"direct",{"body":222,"title":223,"variant":224},"\u003Cstrong>NFR = qualità o vincolo richiesto del sistema. ADR = decisione architetturale registrata.\u003C\u002Fstrong> Un obiettivo di latenza, un obiettivo di disponibilità, una regola di isolamento, una restrizione di deployment o un requisito di manutenibilità possono influenzare l'architettura. Un ADR registra quindi una scelta significativa effettuata per affrontare uno o più di tali fattori. L'ADR non sostituisce il requisito, e l'esistenza di un ADR non prova che il requisito sia stato soddisfatto.","Risposta diretta","info","callout",{"id":227,"data":228,"type":225},"version-note",{"body":229,"title":230,"variant":231},"Il termine \u003Cstrong>NFR\u003C\u002Fstrong> è ampiamente utilizzato ma non perfettamente standardizzato. Questo articolo lo usa come abbreviazione pratica per requisiti di qualità e vincoli rilevanti. Gli standard attuali sono stati ricontrollati l'\u003Cstrong>8 ottobre 2026\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 rimane attuale ma è in revisione; ISO\u002FIEC 25010:2023 e ISO\u002FIEC\u002FIEEE 42010:2022 sono le edizioni pubblicate attuali citate qui.","Nota su terminologia e standard","note",{"id":233,"data":234,"type":238},"toc",{"title":235,"maxLevel":236,"minLevel":237},"Contenuti",3,2,"tableOfContents",{"id":240,"data":241,"type":42},"h-meaning",{"text":242,"level":237},"Qual è la differenza tra un NFR e un ADR?",{"id":244,"data":245,"type":218},"p-meaning-1",{"text":246},"La distinzione più semplice è grammaticale. Un requisito descrive una condizione che il sistema deve soddisfare. Un record di decisione descrive una scelta fatta dal team.",{"id":248,"data":249,"type":218},"p-meaning-2",{"text":250},"Ad esempio, \u003Cstrong>\"L'API deve restituire il 95% delle richieste di lettura entro 300 ms sotto il carico di riferimento concordato\"\u003C\u002Fstrong> è un requisito di qualità. \u003Cstrong>\"Usare una cache read-through per questo carico di lavoro perché il percorso misurato solo database non può soddisfare l'obiettivo di latenza senza un costo inaccettabile\"\u003C\u002Fstrong> è una decisione architetturale.",{"id":252,"data":253,"type":218},"p-meaning-3",{"text":254},"La prima affermazione rimane valida anche se l'implementazione cambia. La seconda affermazione può essere successivamente sostituita da un'altra decisione se il carico di lavoro, la tecnologia, il modello di costo o le evidenze cambiano.",{"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","Domanda 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","Contenuto tipico",{"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","Ruolo nel ciclo di vita",{"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","Cosa lo prova?",{"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","Quando cambia",{"adr":287,"nfr":288},"When the decision is replaced, rejected, deprecated, or superseded","When stakeholder need, operating conditions, policy or quality target changes","NFR e ADR rispondono a domande diverse","table",[292,295],{"id":293,"label":294},"nfr","NFR \u002F requisito di qualità",{"id":296,"label":297},"adr","ADR \u002F decisione architetturale","comparison",{"id":300,"data":301,"type":42},"h-nfr",{"text":302,"level":237},"Cos'è un NFR in termini architetturali precisi?",{"id":304,"data":305,"type":218},"p-nfr-1",{"text":306},"\"Requisito non funzionale\" è un'etichetta industriale conveniente, ma può nascondere diversi tipi di affermazioni. Nel lavoro architetturale, la distinzione utile è tra \u003Cstrong>comportamento funzionale\u003C\u002Fstrong>, \u003Cstrong>requisiti di qualità\u003C\u002Fstrong> e \u003Cstrong>vincoli\u003C\u002Fstrong>.",{"id":308,"data":309,"type":218},"p-nfr-2",{"text":310},"ISO\u002FIEC 25010:2023 fornisce un modello di qualità del prodotto con nove caratteristiche e sottocaratteristiche che possono essere utilizzate per specificare e valutare la qualità dei prodotti ICT e software. Il lavoro architetturale del SEI tratta similmente i requisiti degli attributi di qualità come principali fattori trainanti dell'architettura software.",{"id":312,"data":313,"type":218},"p-nfr-3",{"text":314},"Un NFR utile non è quindi \"il sistema dovrebbe essere veloce\" o \"la piattaforma deve essere sicura\". Queste affermazioni nominano aspirazioni. Un requisito che guida l'architettura dovrebbe rendere la proprietà attesa sufficientemente testabile affinché le alternative di progettazione e le evidenze successive possano essere valutate rispetto ad esso.",{"id":316,"data":317,"type":290},"nfr-examples",{"content":318,"stretched":43,"withHeadings":14},[319,323,327,331,335,339],[320,321,322],"Affermazione debole","Forma del requisito più utile","Perché la differenza conta",[324,325,326],"L'API deve essere veloce","Per il carico di lavoro W, il 95% dell'operazione X si completa entro T millisecondi","Definisce carico di lavoro, operazione, metrica e soglia",[328,329,330],"Il servizio deve essere disponibile","Il servizio S soddisfa un obiettivo di disponibilità concordato nella finestra di misurazione M, escludendo condizioni di manutenzione esplicitamente definite","Rende la disponibilità misurabile e definisce l'ambito",[332,333,334],"I dati dei tenant devono essere sicuri","Una richiesta autenticata per il tenant A non deve mai recuperare o modificare i dati del tenant B attraverso i percorsi applicativi supportati","Trasforma un obiettivo di sicurezza vago in una proprietà di isolamento",[336,337,338],"Il sistema dovrebbe scalare","Il sistema supporta il carico di lavoro W con concorrenza C rispettando le soglie di latenza e tasso di errore","Collega la scalabilità a un comportamento del servizio misurabile",[340,341,342],"Abbiamo bisogno di PostgreSQL","Non è un NFR di per sé; indicare prima le qualità di persistenza richieste o il vincolo esterno","Una scelta tecnologica è normalmente una soluzione, non il requisito che deve soddisfare",{"id":344,"data":345,"type":225},"nfr-rule",{"body":346,"title":347,"variant":348},"Se \"usa Kubernetes\", \"usa PostgreSQL\", \"usa microservizi\" o \"usa la ricerca vettoriale\" appare come requisito, chiediti se è davvero un vincolo esterno o se la soluzione è stata scritta prima che il bisogno di qualità sottostante fosse reso esplicito.","Un requisito dovrebbe descrivere il bisogno prima del meccanismo","success",{"id":350,"data":351,"type":42},"h-adr",{"text":352,"level":237},"Cos'è un Architecture Decision Record?",{"id":354,"data":355,"type":218},"p-adr-1",{"text":356},"Un Architecture Decision Record è una registrazione compatta di una decisione architetturale importante. La formulazione originale dell'ADR di Michael Nygard enfatizza il \u003Cstrong>contesto\u003C\u002Fstrong>, la \u003Cstrong>decisione\u003C\u002Fstrong>, il suo \u003Cstrong>stato\u003C\u002Fstrong> e le \u003Cstrong>conseguenze\u003C\u002Fstrong> risultanti.",{"id":358,"data":359,"type":218},"p-adr-2",{"text":360},"L'oggetto importante è la decisione, non il modello. Team diversi usano formati ADR diversi. Un record più ricco può anche preservare alternative, criteri di decisione, compromessi, evidenze, collegamenti ai requisiti e la data o versione da cui la decisione si applica.",{"id":362,"data":363,"type":218},"p-adr-3",{"text":364},"ISO\u002FIEC\u002FIEEE 42010:2022 è più ampio della pratica ADR: specifica i requisiti per le descrizioni architetturali e i loro concetti, mentre esplicitamente non prescrive un processo, una notazione, uno strumento, un formato o un mezzo per registrare una descrizione architetturale. Un ADR è quindi una tecnica pratica di registrazione delle decisioni, non un formato imposto da 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],"Campo ADR","Cosa preserva","Perché è importante",[374,375,376],"Contesto","Il problema, le forze, i requisiti, le assunzioni e l'ambiente che circondano la scelta","I lettori futuri possono ricostruire perché una scelta era necessaria",[378,379,380],"Decisione","La scelta che è diventata autorevole","Separa l'opzione selezionata dalla discussione",[382,383,384],"Stato","Proposto, accettato, rifiutato, deprecato, sostituito o un altro stato controllato","Impedisce che le vecchie decisioni rimangano attive silenziosamente",[386,387,388],"Alternative","Altre opzioni valide considerate","Mostra che la soluzione selezionata non era l'unica immaginabile",[390,391,392],"Motivazione \u002F compromessi","Perché l'opzione è stata selezionata e cosa si rinuncia","Rende il ragionamento architetturale ispezionabile",[394,395,396],"Conseguenze","Effetti positivi e negativi attesi, lavoro successivo, rischi","Collega una scelta locale all'impatto sul sistema",[398,399,400],"Data \u002F versione","Quando la decisione è diventata valida","Supporta la tracciabilità storica e la successiva sostituzione",{"id":402,"data":403,"type":42},"h-simple-example",{"text":404,"level":237},"L'esempio più semplice: requisito di latenza → decisione architetturale",{"id":406,"data":407,"type":218},"p-simple-1",{"text":408},"Supponiamo che un product owner e un team di ingegneria concordino che un endpoint di ricerca debba restituire la prima pagina di risultati entro 400 ms al 95° percentile sotto un carico di riferimento definito.",{"id":410,"data":411,"type":218},"p-simple-2",{"text":412},"Quel target non è un ADR. È un requisito di qualità. Il lavoro architetturale inizia chiedendosi quale design possa soddisfarlo sotto gli altri vincoli del sistema.",{"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. Enunciare il requisito","Definire il target di qualità, il carico, l'ambito, la soglia e il metodo di validazione.",{"label":421,"description":422},"2. Identificare la rilevanza architetturale","Determinare se il requisito influenza materialmente la struttura, la tecnologia, il deployment, il flusso di dati o il modello operativo.",{"label":424,"description":425},"3. Valutare le opzioni","Confrontare alternative come indicizzazione, caching, denormalizzazione, lavoro asincrono, partizionamento o una diversa architettura di query.",{"label":427,"description":428},"4. Registrare la decisione","Catturare la scelta architetturale selezionata, la motivazione, le alternative, i compromessi, lo stato e le conseguenze in un ADR.",{"label":430,"description":431},"5. Implementare","Trasformare la decisione in codice, infrastruttura, configurazione e comportamento operativo.",{"label":433,"description":434},"6. Validare","Misurare il sistema reale rispetto al requisito originale. Il risultato del test valida l'NFR; il solo ADR no.","Dal requisito all'evidenza","auto","processFlow",{"id":439,"data":440,"type":225},"simple-stop",{"body":441,"title":442,"variant":443},"I sistemi reali raramente hanno un solo requisito e una sola decisione. Le prestazioni possono entrare in conflitto con costo, consistenza, operabilità, sicurezza, manutenibilità, consumo energetico o rischio di consegna. Il modello utile è quindi un grafo di tracciabilità, non una mappatura uno-a-uno.","Dove si ferma l'esempio semplice","warning",{"id":445,"data":446,"type":42},"h-many-many",{"text":447,"level":237},"Gli NFR e gli ADR di solito hanno una relazione molti-a-molti",{"id":449,"data":450,"type":218},"p-many-1",{"text":451},"Un requisito di qualità può guidare diverse decisioni architetturali. Un requisito di isolamento dei tenant, ad esempio, può influenzare la propagazione dell'identità, lo scoping del database, il design dei job in background, le chiavi di cache, il logging di audit e gli strumenti amministrativi.",{"id":453,"data":454,"type":218},"p-many-2",{"text":455},"Una decisione architetturale può anche rispondere a diversi requisiti contemporaneamente. Scegliere un confine di elaborazione asincrona potrebbe migliorare la reattività e l'isolamento dei guasti, introducendo al contempo compromessi di consistenza, complessità, osservabilità e operatività.",{"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","Un NFR → molti 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","Molti NFR → 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 senza un NFR classico",{"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","Requisito stabile, ADR cambia",{"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","Perché la relazione non è uno-a-uno",[490,492,494],{"id":293,"label":491},"Lato requisito",{"id":296,"label":493},"Lato decisione",{"id":495,"label":496},"validation","Lato validazione",{"id":498,"data":499,"type":42},"h-technology",{"text":500,"level":237},"Una scelta tecnologica non è automaticamente un requisito",{"id":502,"data":503,"type":218},"p-tech-1",{"text":504},"Un errore architetturale ricorrente è scrivere una tecnologia preferita nel livello dei requisiti e poi trattare il design risultante come inevitabile.",{"id":506,"data":507,"type":218},"p-tech-2",{"text":508},"\"Il sistema deve usare PostgreSQL\" può essere un vincolo legittimo se un contratto, una politica di piattaforma, un requisito di compatibilità, una regola di licenza, uno standard organizzativo o un confine operativo esistente impongono effettivamente PostgreSQL. Ma se la necessità reale è la consistenza transazionale, l'interrogazione strutturata, la familiarità operativa o un obiettivo di ripristino specifico, il requisito dovrebbe enunciare quella necessità e la selezione tecnologica dovrebbe essere registrata come decisione.",{"id":510,"data":511,"type":290},"tech-table",{"content":512,"stretched":43,"withHeadings":14},[513,517,521,525,529,533,537],[514,515,516],"Affermazione","Classificazione","Motivo",[518,519,520],"Tutte le letture con ambito tenant devono applicare l'isolamento dei tenant","Requisito \u002F proprietà di sicurezza","Descrive una proprietà che deve valere",[522,523,524],"Usare PostgreSQL Row Level Security per tabelle selezionate con ambito tenant","Decisione architetturale","Sceglie un meccanismo inteso ad aiutare a soddisfare la proprietà di isolamento",[526,527,528],"Il target di deployment deve essere eseguito in un ambiente approvato operato nell'UE","Vincolo \u002F condizione operativa simile a un NFR","Limita dove il sistema può operare",[530,531,532],"Usare il provider X nella regione Y","Decisione architetturale \u002F di deployment se non imposta esternamente","Seleziona una soluzione particolare all'interno del confine consentito",[534,535,536],"Latenza API al 95° percentile ≤ 300 ms sotto il carico W","Requisito di qualità","Definisce un comportamento prestazionale misurabile",[538,523,539],"Introdurre una cache per l'endpoint X","Seleziona una tattica intesa a migliorare il comportamento misurato",{"id":541,"data":542,"type":42},"h-adr-proof",{"text":543,"level":237},"Un ADR non è prova che un NFR sia stato soddisfatto",{"id":545,"data":546,"type":218},"p-proof-1",{"text":547},"La documentazione delle decisioni e la validazione del sistema rispondono a domande diverse. Un ADR può mostrare che prestazioni, sicurezza, resilienza o manutenibilità sono state considerate. Non può da solo dimostrare che il sistema consegnato raggiunga effettivamente quelle proprietà.",{"id":549,"data":550,"type":218},"p-proof-2",{"text":551},"La prova deve provenire dal metodo di validazione appropriato al requisito: benchmark, test di carico, test di guasto, test di sicurezza, analisi architetturale, audit, ispezione, telemetria operativa, esercizio di ripristino, studio utente o un'altra forma di evidenza.",{"id":553,"data":554,"type":225},"proof-rule",{"body":555,"title":556,"variant":443},"\u003Cstrong>ADR:\u003C\u002Fstrong> \"Abbiamo selezionato il design X perché si prevede che soddisfi il requisito R sotto le assunzioni A.\"\u003Cbr>\u003Cstrong>Validazione:\u003C\u002Fstrong> \"L'evidenza misurata o analizzata E mostra se il sistema implementato soddisfa effettivamente R.\"","Non confondere l'intento con l'evidenza",{"id":558,"data":559,"type":42},"h-asr",{"text":560,"level":237},"Quando un NFR diventa architetturalmente significativo?",{"id":562,"data":563,"type":218},"p-asr-1",{"text":564},"Non ogni requisito non funzionale merita una decisione architetturale. Il sottoinsieme importante è costituito dai requisiti che plasmano materialmente l'architettura o forzano compromessi attraverso il sistema.",{"id":566,"data":567,"type":218},"p-asr-2",{"text":568},"La letteratura SEI utilizza il concetto di \u003Cstrong>requisiti architetturalmente significativi\u003C\u002Fstrong> per i requisiti con effetto architetturale di vasta portata. Attributi di qualità come prestazioni, affidabilità, sicurezza e modificabilità sono frequenti fonti di tali driver, specialmente quando comportano un elevato valore aziendale o di missione.",{"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. Chiedersi se il requisito cambia la struttura","Valori diversi forzerebbero componenti, confini, percorsi dati o topologie di deployment differenti?",{"label":577,"description":578},"2. Chiedersi se vincola scelte tecnologiche importanti","Elimina opzioni di implementazione altrimenti praticabili?",{"label":580,"description":581},"3. Chiedersi se crea comportamento trasversale","Influenza molti componenti, team, interfacce o fasi del ciclo di vita?",{"label":583,"description":584},"4. Chiedersi se crea un compromesso difficile","Migliorare questa proprietà influisce materialmente su un'altra qualità, costo, pianificazione, complessità o rischio?",{"label":586,"description":587},"5. Chiedersi se il fallimento è costoso","Mancare il requisito creerebbe un impatto materiale operativo, di sicurezza, normativo, finanziario o di prodotto?",{"label":589,"description":590},"6. Registrare le decisioni solo dove il ragionamento vale la pena di essere preservato","Non creare ADR per ogni scelta di codifica locale; preservare le decisioni architetturalmente significative e la loro motivazione.","Test di significatività architetturale",{"id":593,"data":594,"type":42},"h-traceability",{"text":595,"level":237},"Un modello architetturale più forte: requisito → decisione → implementazione → validazione",{"id":597,"data":598,"type":218},"p-trace-1",{"text":599},"La connessione più utile tra NFR e ADR è la tracciabilità. Un requisito dovrebbe poter puntare alle decisioni architetturali che lo affrontano; un ADR dovrebbe identificare i driver a cui risponde; il lavoro di implementazione dovrebbe realizzare la decisione; la validazione dovrebbe ritornare al requisito originale.",{"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},"Bisogno \u002F obiettivo aziendale","Perché la qualità o il vincolo è importante.",{"label":608,"description":609},"Requisito \u002F NFR","Cosa il sistema deve raggiungere o rispettare.",{"label":611,"description":612},"Driver architetturali","Quali requisiti sono abbastanza significativi da plasmare il design.",{"label":614,"description":615},"Opzioni","Modi plausibili per affrontare il driver.",{"label":617,"description":618},"ADR","La scelta selezionata, la motivazione, le alternative, i compromessi e le conseguenze.",{"label":620,"description":621},"Implementazione","Codice, modello dati, infrastruttura, interfacce e meccanismi operativi che realizzano la decisione.",{"label":623,"description":624},"Evidenza di validazione","Test, misurazioni, analisi o audit che dimostrano se il requisito originale è effettivamente soddisfatto.",{"label":626,"description":627},"Cambiamento \u002F sostituzione","Nuove evidenze o requisiti modificati possono attivare un nuovo ADR preservando il ragionamento storico.","Catena di tracciabilità architetturale",{"id":630,"data":631,"type":42},"h-senseflow",{"text":632,"level":237},"Evidenza di implementazione: come separo requisiti e decisioni in SenseFlow",{"id":634,"data":635,"type":225},"senseflow-evidence",{"body":636,"title":637,"variant":231},"La sezione seguente descrive la struttura del mio progetto SenseFlow. È evidenza di implementazione per la separazione in questo articolo, non un'affermazione che ogni team debba usare lo stesso modello di documentazione.","Implementazione originale \u002F evidenza di progetto",{"id":639,"data":640,"type":218},"p-sense-1",{"text":641},"In SenseFlow, la Source of Truth del progetto colloca esplicitamente i requisiti non funzionali all'interno della struttura dei requisiti insieme a dipendenze, rischi, assunzioni, criteri di accettazione e un metodo di validazione. Il modello di documentazione definisce separatamente l'integrità delle decisioni per le decisioni significative.",{"id":643,"data":644,"type":218},"p-sense-2",{"text":645},"Per le decisioni significative di SenseFlow, i campi registrati sono \u003Cstrong>Decisione, Motivo, Alternative, Compromessi, Stato e Data \u002F Versione\u003C\u002Fstrong>. Le principali decisioni architetturali e di prodotto sono destinate a rimanere storicamente tracciabili anziché essere sovrascritte quando il progetto evolve.",{"id":647,"data":648,"type":218},"p-sense-3",{"text":649},"SenseFlow assegna anche ruoli operativi diversi a Confluence e Jira. Confluence è l'ambiente strutturato di conoscenza e decisione; Jira gestisce il lavoro di delivery azionabile. Le Epic principali di Jira dovrebbero collegarsi alla documentazione di prodotto o dei requisiti pertinente. Questo preserva la catena dall'intento di prodotto attraverso requisiti e decisioni fino all'implementazione, invece di trasformare il backlog nella Source of Truth architetturale.",{"id":651,"data":652,"type":290},"senseflow-table",{"content":653,"stretched":43,"withHeadings":14},[654,658,662,666,670,674,678],[655,656,657],"Livello SenseFlow","Cosa contiene","Ruolo nella separazione ADR\u002FNFR",[659,660,661],"Struttura di prodotto \u002F requisiti","Obiettivo di prodotto, capacità, epic, user story, criteri di accettazione, attività tecniche; i requisiti possono includere NFR e metodo di validazione","Preserva cosa deve essere raggiunto e come verrà verificato il successo",[663,664,665],"Integrità delle decisioni","Decisione, motivo, alternative, compromessi, stato, data\u002Fversione","Preserva perché una scelta architetturalmente significativa è diventata autorevole",[667,668,669],"Confluence","Requisiti, architettura, ricerca, record delle decisioni, rischi, roadmap e fonti di supporto","Mantiene la Source of Truth concettuale e storica",[671,672,673],"Jira","Iniziative\u002Fobiettivi, epic, storie, attività e stato di delivery","Esegue il lavoro approvato senza diventare la Source of Truth concettuale",[675,676,677],"Gestione del cambiamento","Stato attuale → nuova evidenza → cambiamento proposto → impatto → decisione","Consente alle decisioni di evolversi senza cancellare la traccia del ragionamento",[679,680,681],"Tracciabilità end-to-end","Problema → bisogno → valore → obiettivo di prodotto → requisito → implementazione → validazione","Mantiene la documentazione delle decisioni connessa al prodotto reale e al ciclo di vita dell'evidenza",{"id":683,"data":684,"type":225},"senseflow-lesson",{"body":685,"title":686,"variant":348},"Un requisito e una decisione possono vivere vicini senza essere collassati in un unico record. Il requisito rimane l'obiettivo; la decisione rimane la storia del ragionamento; il lavoro di delivery implementa la decisione; la validazione ritorna all'obiettivo.","Cosa dimostra questa implementazione",{"id":688,"data":689,"type":42},"h-enterprise",{"text":690,"level":237},"Contesto di progetto enterprise: i requisiti dovrebbero precedere le scelte architetturali",{"id":692,"data":693,"type":218},"p-enterprise-1",{"text":694},"La stessa separazione è utile nel lavoro di progetto orientato all'enterprise. Le decisioni architetturali prese prima che requisiti, rischi, vincoli e condizioni di accettazione siano sufficientemente compresi possono trasformare le preferenze in false necessità.",{"id":696,"data":697,"type":218},"p-enterprise-2",{"text":698},"Per Enterprise Aaasaasa 0.1, la lezione pertinente è metodologica piuttosto che un'affermazione su un particolare ADR: requisiti, architettura, validazione, milestone, gestione del rischio e accettazione appartengono a un sistema di delivery connesso. Una scelta architetturale dovrebbe rimanere tracciabile rispetto al requisito o vincolo che intende affrontare.",{"id":700,"data":701,"type":42},"h-failures",{"text":702,"level":237},"Modalità di fallimento comuni quando ADR e NFR vengono mescolati",{"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],"Modalità di fallimento","Cosa succede","Conseguenza",[712,713,714],"Tecnologia mascherata da requisito","Una soluzione preferita viene scritta come \"deve usare X\" senza stabilire il bisogno sottostante","Le alternative non vengono mai valutate e l'architettura diventa prematuramente fissa",[716,717,718],"NFR nascosto solo all'interno di un ADR","La decisione menziona un obiettivo di prestazioni\u002Fsicurezza assente dalla baseline dei requisiti","L'obiettivo è difficile da validare, prioritizzare o gestire in modo indipendente",[720,721,722],"ADR trattato come prova","Si presume che una scelta documentata significhi che il requisito è soddisfatto","L'intento architetturale sostituisce la misurazione o la verifica",[724,725,726],"NFR vago","Parole come veloce, scalabile, sicuro o manutenibile non hanno ambito misurabile","Stakeholder diversi possono credere che lo stesso requisito significhi cose diverse",[728,729,730],"Nessuna alternativa registrata","Il team registra solo la tecnologia selezionata","I futuri manutentori non possono ricostruire perché un'altra opzione è stata rifiutata",[732,733,734],"Nessun modello di sostituzione","I vecchi ADR vengono modificati o eliminati quando l'architettura cambia","Il ragionamento storico scompare e le decisioni obsolete possono rimanere ambigue",[736,737,738],"Ogni dettaglio implementativo diventa un ADR","Il repository si riempie di record di scarso valore","Le scelte architetturali importanti diventano difficili da trovare",[740,741,742],"Il backlog diventa la fonte di verità dell'architettura","Le attività Jira vengono trattate come l'unica spiegazione del sistema","Lo stato di consegna sopravvive, ma la motivazione architetturale e i driver di qualità vanno persi",{"id":744,"data":745,"type":42},"h-decision-framework",{"text":746,"level":237},"Il framework decisionale ADR–NFR",{"id":748,"data":749,"type":218},"p-framework-1",{"text":750},"Quando un team incontra una nuova preoccupazione architetturale, la seguente sequenza aiuta a determinare cosa appartiene ai requisiti, cosa appartiene a un ADR e cosa appartiene alle prove.",{"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. Si tratta di una proprietà richiesta o di un vincolo esterno?","Se sì, scrivi o fai riferimento al requisito prima di scegliere un meccanismo.",{"label":759,"description":760},"2. Può essere validato?","Definisci l'ambito, la condizione, la metrica, la regola di accettazione, il metodo di analisi o altre prove necessarie.",{"label":762,"description":763},"3. È architetturalmente significativo?","Identifica se il requisito modella materialmente struttura, tecnologia, dati, distribuzione o compromessi trasversali.",{"label":765,"description":766},"4. Esistono alternative significative?","Confronta tattiche o opzioni architetturali valide invece di saltare direttamente a una tecnologia preferita.",{"label":768,"description":769},"5. Una scelta è diventata autorevole?","Crea o aggiorna l'ADR con contesto, decisione, motivazione, alternative, compromessi, stato e conseguenze.",{"label":771,"description":772},"6. La decisione è implementata?","Traccia l'ADR in progettazione, attività, codice, configurazione e operazioni.",{"label":774,"description":775},"7. Il requisito è soddisfatto?","Raccogli prove di validazione rispetto al requisito stesso.",{"label":777,"description":778},"8. Le condizioni sono cambiate?","Rivaluta il requisito e, quando necessario, sostituisci l'ADR senza cancellare la storia.","Test di classificazione ADR–NFR",{"id":781,"data":782,"type":42},"h-what-not",{"text":783,"level":237},"Cosa non sono ADR e NFR",{"id":785,"data":786,"type":298},"not-comparison",{"rows":787,"title":819,"layout":290,"columns":820},[788,793,798,805,812],{"id":293,"label":294,"values":789},{"not":790,"why":791,"term":792},"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":794},{"not":795,"why":796,"term":797},"The complete architecture description","Architecture also needs views, interfaces, models, responsibilities and other documentation","A record of an architecturally significant decision",{"id":799,"label":800,"values":801},"test","Prova di validazione",{"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","Elemento del 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","Vincolo",{"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","Errori di categoria comuni",[821,824,827],{"id":822,"label":823},"term","Concetto",{"id":825,"label":826},"not","Non è",{"id":828,"label":516},"why",{"id":830,"data":831,"type":42},"h-change",{"text":832,"level":237},"Cosa cambierebbe questa risposta?",{"id":834,"data":835,"type":218},"p-change-1",{"text":836},"La terminologia può evolvere. ISO\u002FIEC\u002FIEEE 29148:2018 rimane lo standard pubblicato corrente di ingegneria dei requisiti all'8 ottobre 2026, ma ISO elenca un Draft International Standard destinato a sostituirlo. Se la nuova edizione cambia la terminologia o le linee guida sui requisiti pertinenti, i riferimenti specifici per versione in questo articolo dovrebbero essere aggiornati.",{"id":838,"data":839,"type":218},"p-change-2",{"text":840},"Anche i template ADR possono evolvere senza cambiare la distinzione centrale. Il template minimale di Michael Nygard, MADR, template specifici dell'organizzazione, strumenti di conoscenza architetturale o database decisionali strutturati possono tutti registrare decisioni. La domanda duratura è se il record preserva abbastanza contesto e motivazione per comprendere una scelta architetturalmente significativa.",{"id":842,"data":843,"type":218},"p-change-3",{"text":844},"La distinzione collasserebbe solo se un'organizzazione scegliesse deliberatamente un artefatto combinato che memorizza sia i dati del requisito che quelli della decisione in un unico documento. Anche in quel caso, i ruoli semantici rimangono diversi: un campo enuncia il risultato o il vincolo richiesto; un altro registra la risposta scelta.",{"id":846,"data":847,"type":42},"h-limitations",{"text":848,"level":237},"Limitazioni",{"id":850,"data":851,"type":218},"p-limit-1",{"text":852},"Questo articolo usa \u003Cstrong>NFR\u003C\u002Fstrong> come abbreviazione pratica. Alcuni metodi di ingegneria preferiscono termini come requisito di attributo di qualità, requisito di qualità, qualità del sistema, vincolo, obiettivo di livello di servizio o requisito architetturalmente significativo. Questi termini non sono perfettamente intercambiabili e la terminologia del progetto dovrebbe essere esplicita.",{"id":854,"data":855,"type":218},"p-limit-2",{"text":856},"Non ogni requisito può essere ridotto a una singola soglia numerica. Sicurezza, safety, manutenibilità, interoperabilità, usabilità, spiegabilità, portabilità e governance possono richiedere combinazioni di scenari, regole strutturali, analisi, controlli di processo e prove qualitative. \"Misurabile\" dovrebbe significare verificabile abbastanza per la decisione, non artificialmente numerico.",{"id":858,"data":859,"type":218},"p-limit-3",{"text":860},"Non ogni decisione architetturale necessita di un ADR formale. Il costo di documentazione dovrebbe essere proporzionale alla significatività architetturale, longevità, incertezza, complessità dei compromessi e al costo di perdere la motivazione.",{"id":862,"data":863,"type":42},"h-conclusion",{"text":864,"level":237},"Conclusione",{"id":866,"data":867,"type":218},"p-conclusion-1",{"text":868},"ADR e NFR appartengono a livelli diversi del lavoro architetturale. \u003Cstrong>L'NFR definisce un obiettivo di qualità, un vincolo o una condizione operativa. L'ADR registra una risposta architetturale significativa a uno o più driver.\u003C\u002Fstrong>",{"id":870,"data":871,"type":218},"p-conclusion-2",{"text":872},"Mantenere separati questi livelli rende l'architettura più facile da ragionare. I requisiti possono essere validati indipendentemente dalla tecnologia. Le decisioni possono essere sostituite senza riscrivere la storia. Le alternative e i compromessi rimangono visibili. Il lavoro di consegna può essere tracciato fino all'intento architetturale. Le prove possono mostrare se il sistema risultante soddisfa effettivamente il requisito.",{"id":874,"data":875,"type":218},"p-conclusion-3",{"text":876},"La catena più forte quindi non è “NFR → ADR → fatto.” È \u003Cstrong>bisogno → requisito → driver architetturali → opzioni → decisione → implementazione → validazione → cambiamento\u003C\u002Fstrong>. Quella catena trasforma la documentazione architetturale da scartoffie statiche in un registro verificabile del perché il sistema ha la forma che ha.",{"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","No. Un NFR enuncia una qualità, un vincolo o una condizione operativa richiesti. Un ADR registra una scelta architetturalmente significativa fatta in risposta a requisiti, vincoli, rischi e compromessi.","Un ADR è un requisito non funzionale?",{"id":890,"answer":891,"question":892},"faq2","No. Solo i requisiti che influenzano materialmente l'architettura necessitano di decisioni a livello architetturale che valga la pena preservare. Un NFR può anche guidare diversi ADR, e un ADR può rispondere a diversi requisiti.","Ogni NFR dovrebbe avere un ADR?",{"id":894,"answer":895,"question":896},"faq3","Solo quando PostgreSQL è genuinamente imposto come vincolo esterno. Altrimenti il bisogno sottostante dovrebbe essere espresso prima, e selezionare PostgreSQL dovrebbe normalmente essere trattato come una decisione architetturale.","“Usare PostgreSQL” può essere un NFR?",{"id":898,"answer":899,"question":900},"faq4","No. Un ADR registra intento e ragionamento. Il requisito è validato attraverso evidenze appropriate come test, misurazione, analisi, audit o telemetria operativa.","Un ADR dimostra che un requisito di prestazioni o sicurezza è soddisfatto?",{"id":902,"answer":903,"question":904},"faq5","Come minimo, un ADR dovrebbe rendere chiari il contesto e la decisione. Le strutture comuni includono anche stato e conseguenze. I team possono aggiungere alternative, motivazioni, compromessi, collegamenti ai requisiti, evidenze, responsabili, date e relazioni di sostituzione.","Cosa dovrebbe contenere un ADR?",{"id":906,"answer":907,"question":908},"faq6","Un requisito è architetturalmente significativo quando plasma materialmente la struttura del sistema, la tecnologia, i flussi di dati, il deployment, il comportamento trasversale o compromessi di qualità difficili, specialmente quando il fallimento comporta un elevato impatto aziendale o mission-critical.","Cosa rende un NFR architetturalmente significativo?",{"id":910,"answer":911,"question":912},"faq7","Di solito no. Una decisione sostitutiva dovrebbe normalmente sostituire il vecchio record in modo che il ragionamento storico rimanga tracciabile.","Un vecchio ADR dovrebbe essere eliminato quando l'architettura cambia?","ADR vs NFR",{"id":915,"data":916,"type":42},"h-glossary",{"text":917,"level":237},"Glossario",{"id":919,"data":920,"type":919},"glossary",{"title":921,"entries":922},"Termini architetturali fondamentali",[923,926,930,933,937,939,943,946],{"term":924,"anchor":293,"definition":925},"NFR","Requisito non funzionale: abbreviazione pratica per una qualità, un vincolo o una condizione operativa richiesti del sistema; la terminologia esatta varia a seconda del metodo e dello standard.",{"term":927,"anchor":928,"definition":929},"Requisito di attributo di qualità","quality-attribute-requirement","Un requisito che descrive una proprietà di qualità che il sistema dovrebbe mostrare in condizioni definite, come prestazioni, disponibilità, sicurezza, affidabilità o modificabilità.",{"term":931,"anchor":296,"definition":932},"Architecture Decision Record (ADR)","Un registro durevole di una decisione architetturalmente significativa e del contesto sufficiente per comprendere perché la scelta è stata fatta e quali conseguenze ne derivano.",{"term":934,"anchor":935,"definition":936},"Requisito architetturalmente significativo (ASR)","asr","Un requisito con un impatto architetturale sufficientemente ampio da influenzare materialmente il design del sistema.",{"term":814,"anchor":813,"definition":938},"Una condizione che restringe lo spazio delle soluzioni, inclusi policy esterne, regolamentazioni, piattaforme, compatibilità, confini contrattuali o organizzativi.",{"term":940,"anchor":941,"definition":942},"Compromesso","trade-off","Una relazione di design in cui migliorare un obiettivo, una proprietà o una dimensione di costo può peggiorarne un'altra.",{"term":944,"anchor":495,"definition":945},"Validazione","Lavoro che produce evidenze utilizzato per determinare se il sistema implementato soddisfa il requisito dichiarato nelle condizioni rilevanti.",{"term":947,"anchor":948,"definition":949},"ADR sostituito","superseded-adr","Un registro decisionale storico che è stato sostituito da una decisione autorevole più recente pur rimanendo disponibile per la tracciabilità.",{"id":951,"data":952,"type":42},"h-sources",{"text":953,"level":237},"Fonti primarie ed evidenze di implementazione",{"id":955,"data":956,"type":218},"p-sources-note",{"text":957},"Questo articolo separa gli standard attuali dalle evidenze di implementazione del progetto. ISO\u002FIEC\u002FIEEE 29148:2018 rimane attuale all'8 ottobre 2026 ma è contrassegnato per revisione; ISO\u002FIEC 25010:2023 e ISO\u002FIEC\u002FIEEE 42010:2022 sono edizioni pubblicate attuali. SenseFlow è evidenza originale del progetto per il modello di tracciabilità e integrità decisionale descritto sopra.",{"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 — Ingegneria dei requisiti","Standard attuale pubblicato di ingegneria dei requisiti. ISO afferma che l'edizione 2018 è stata riesaminata e confermata nel 2024 e si prevede che sarà sostituita dal DIS attualmente in sviluppo.","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 — Ingegneria dei requisiti","Draft International Standard attualmente in sviluppo e destinato a sostituire 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 — Modello di qualità del prodotto","Modello attuale di qualità del prodotto con nove caratteristiche di qualità utilizzate per specificare, misurare e valutare la qualità dei prodotti ICT e software.",{"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 — Descrizione dell'architettura","Standard attuale di descrizione dell'architettura. Specifica i concetti di descrizione dell'architettura e i requisiti di conformità senza prescrivere un formato di registrazione, una notazione, un processo o uno strumento.",{"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 — Documentare le decisioni architetturali","Articolo originale influente sugli ADR che descrive registri leggeri incentrati su contesto, decisione, stato e conseguenze, con le decisioni sostituite conservate per la comprensione storica.",{"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 — Collegare gli obiettivi di business ai requisiti architetturalmente significativi","Rapporto SEI che spiega come i requisiti di attributi di qualità e gli obiettivi di business guidano l'architettura software e perché i requisiti architetturalmente significativi necessitano di elicitazione esplicita.",{"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 — Definire le qualità non funzionali del sistema","Panoramica SEI che collega attributi non funzionali\u002Fdi qualità con architettura, scenari, compromessi e valutazione oggettiva del sistema.",{"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 — Raccolta del metodo Attribute-Driven Design","Metodo di progettazione architetturale basato su requisiti funzionali, requisiti di attributi di qualità e vincoli, con tattiche e pattern architetturali selezionati per soddisfare scenari di 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 — Raccolta Views and Beyond","Guida alla documentazione architetturale che enfatizza le viste rilevanti e la registrazione delle decisioni di design necessarie come parte del lavoro architetturale.","2.31","ADR vs NFR spiegati: scopri come i requisiti di qualità del sistema guidano le decisioni architetturali, come gli ADR registrano i compromessi e perché la validazione rimane separata.","\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,"Criteri di accettazione","acceptance-criteria",{"id":1055,"name":1056,"slug":1057},67,"KPI e criteri di accettazione","kpis",{"id":1059,"name":1060,"slug":1061},77,"Misurazione e monitoraggio","measurement",{"id":1063,"name":1064,"slug":1065},76,"Budget prestazionali","budgets",{"id":1067,"name":1068,"slug":1069},68,"Rischi, controlli e prove","risks-and-controls",{"id":1071,"login":1072,"email":1073,"displayName":1074},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1076,1717],{"lang":1077,"title":1078,"content":1079,"contentJson":1080,"excerpt":1716},"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":1715},1791475659420,[1083,1086,1090,1094,1097,1100,1103,1106,1109,1133,1136,1139,1142,1145,1172,1176,1179,1182,1185,1188,1223,1226,1229,1232,1254,1258,1261,1264,1267,1290,1293,1296,1299,1329,1332,1335,1338,1342,1345,1348,1351,1373,1376,1379,1406,1409,1413,1416,1419,1422,1451,1455,1458,1461,1464,1467,1506,1509,1512,1540,1543,1565,1568,1571,1574,1577,1580,1583,1586,1589,1592,1595,1598,1601,1603,1627,1630,1655,1658,1661,1667,1673,1679,1685,1691,1697,1703,1709],{"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,1211,1215,1219],[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",[1208,1209,1210],"Alternatives","Other viable options considered","Shows that the selected solution was not the only imaginable one",[1212,1213,1214],"Rationale \u002F trade-offs","Why the option was selected and what it gives up","Makes architecture reasoning inspectable",[1216,1217,1218],"Consequences","Expected positive and negative effects, follow-up work, risks","Connects a local choice to system impact",[1220,1221,1222],"Date \u002F version","When the decision became valid","Supports historical traceability and later supersession",{"id":402,"data":1224,"type":42},{"text":1225,"level":237},"The simplest example: latency requirement → architecture decision",{"id":406,"data":1227,"type":218},{"text":1228},"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":1230,"type":218},{"text":1231},"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":1233,"type":437},{"steps":1234,"title":1253,"orientation":436},[1235,1238,1241,1244,1247,1250],{"label":1236,"description":1237},"1. State the requirement","Define the quality target, workload, scope, threshold and validation method.",{"label":1239,"description":1240},"2. Identify architectural significance","Determine whether the requirement materially influences structure, technology, deployment, data flow or operating model.",{"label":1242,"description":1243},"3. Evaluate options","Compare alternatives such as indexing, caching, denormalization, asynchronous work, partitioning, or a different query architecture.",{"label":1245,"description":1246},"4. Record the decision","Capture the selected architecture choice, rationale, alternatives, trade-offs, status and consequences in an ADR.",{"label":1248,"description":1249},"5. Implement","Turn the decision into code, infrastructure, configuration and operational behavior.",{"label":1251,"description":1252},"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":1255,"type":225},{"body":1256,"title":1257,"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":1259,"type":42},{"text":1260,"level":237},"NFRs and ADRs usually have a many-to-many relationship",{"id":449,"data":1262,"type":218},{"text":1263},"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":1265,"type":218},{"text":1266},"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":1268,"type":298},{"rows":1269,"title":1282,"layout":290,"columns":1283},[1270,1273,1276,1279],{"id":461,"label":1271,"values":1272},"One NFR → many ADRs",{"adr":464,"nfr":465,"validation":466},{"id":468,"label":1274,"values":1275},"Many NFRs → one ADR",{"adr":471,"nfr":472,"validation":473},{"id":475,"label":1277,"values":1278},"ADR without a classic NFR",{"adr":478,"nfr":479,"validation":480},{"id":482,"label":1280,"values":1281},"Requirement stable, ADR changes",{"adr":485,"nfr":486,"validation":487},"Why the relationship is not one-to-one",[1284,1286,1288],{"id":293,"label":1285},"Requirement side",{"id":296,"label":1287},"Decision side",{"id":495,"label":1289},"Validation side",{"id":498,"data":1291,"type":42},{"text":1292,"level":237},"A technology choice is not automatically a requirement",{"id":502,"data":1294,"type":218},{"text":1295},"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":1297,"type":218},{"text":1298},"“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":1300,"type":290},{"content":1301,"stretched":43,"withHeadings":14},[1302,1306,1310,1314,1318,1322,1326],[1303,1304,1305],"Statement","Classification","Reason",[1307,1308,1309],"All tenant-scoped reads must enforce tenant isolation","Requirement \u002F security property","Describes a property that must hold",[1311,1312,1313],"Use PostgreSQL Row Level Security for selected tenant-scoped tables","Architecture decision","Chooses a mechanism intended to help satisfy the isolation property",[1315,1316,1317],"The deployment target must run in an approved EU-operated environment","Constraint \u002F NFR-like operating condition","Restricts where the system may operate",[1319,1320,1321],"Use provider X in region Y","Architecture \u002F deployment decision unless externally mandated","Selects a particular solution inside the allowed boundary",[1323,1324,1325],"95th-percentile API latency ≤ 300 ms under workload W","Quality requirement","Defines measurable performance behavior",[1327,1312,1328],"Introduce a cache for endpoint X","Selects a tactic intended to improve the measured behavior",{"id":541,"data":1330,"type":42},{"text":1331,"level":237},"An ADR is not proof that an NFR has been satisfied",{"id":545,"data":1333,"type":218},{"text":1334},"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":1336,"type":218},{"text":1337},"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":1339,"type":225},{"body":1340,"title":1341,"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":1343,"type":42},{"text":1344,"level":237},"When does an NFR become architecturally significant?",{"id":562,"data":1346,"type":218},{"text":1347},"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":1349,"type":218},{"text":1350},"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":1352,"type":437},{"steps":1353,"title":1372,"orientation":436},[1354,1357,1360,1363,1366,1369],{"label":1355,"description":1356},"1. Ask whether the requirement changes structure","Would different values force different components, boundaries, data paths or deployment topology?",{"label":1358,"description":1359},"2. Ask whether it constrains major technology choices","Does it eliminate otherwise viable implementation options?",{"label":1361,"description":1362},"3. Ask whether it creates cross-cutting behavior","Does it affect many components, teams, interfaces or lifecycle stages?",{"label":1364,"description":1365},"4. Ask whether it creates a difficult trade-off","Does improving this property materially affect another quality, cost, schedule, complexity or risk?",{"label":1367,"description":1368},"5. Ask whether failure is expensive","Would missing the requirement create material operational, security, regulatory, financial or product impact?",{"label":1370,"description":1371},"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":1374,"type":42},{"text":1375,"level":237},"A stronger architecture model: requirement → decision → implementation → validation",{"id":597,"data":1377,"type":218},{"text":1378},"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":1380,"type":437},{"steps":1381,"title":1405,"orientation":436},[1382,1385,1388,1391,1394,1396,1399,1402],{"label":1383,"description":1384},"Need \u002F business goal","Why the quality or constraint matters.",{"label":1386,"description":1387},"Requirement \u002F NFR","What the system must achieve or respect.",{"label":1389,"description":1390},"Architecture drivers","Which requirements are significant enough to shape the design.",{"label":1392,"description":1393},"Options","Plausible ways to address the driver.",{"label":617,"description":1395},"The selected choice, rationale, alternatives, trade-offs and consequences.",{"label":1397,"description":1398},"Implementation","Code, data model, infrastructure, interfaces and operational mechanisms that realize the decision.",{"label":1400,"description":1401},"Validation evidence","Tests, measurements, analysis or audits demonstrating whether the original requirement is actually satisfied.",{"label":1403,"description":1404},"Change \u002F supersession","New evidence or changed requirements can trigger a new ADR while preserving historical reasoning.","Architecture traceability chain",{"id":630,"data":1407,"type":42},{"text":1408,"level":237},"Implementation evidence: how I separate requirements and decisions in SenseFlow",{"id":634,"data":1410,"type":225},{"body":1411,"title":1412,"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":1414,"type":218},{"text":1415},"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":1417,"type":218},{"text":1418},"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":1420,"type":218},{"text":1421},"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":1423,"type":290},{"content":1424,"stretched":43,"withHeadings":14},[1425,1429,1433,1437,1440,1443,1447],[1426,1427,1428],"SenseFlow layer","What it contains","Role in ADR\u002FNFR separation",[1430,1431,1432],"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",[1434,1435,1436],"Decision integrity","Decision, reason, alternatives, trade-offs, status, date\u002Fversion","Preserves why an architecturally significant choice became authoritative",[667,1438,1439],"Requirements, architecture, research, decision records, risks, roadmap and supporting sources","Maintains conceptual and historical Source of Truth",[671,1441,1442],"Initiatives\u002Fgoals, epics, stories, tasks and delivery state","Executes approved work without becoming the conceptual Source of Truth",[1444,1445,1446],"Change management","Current state → new evidence → proposed change → impact → decision","Allows decisions to evolve without erasing the reasoning trail",[1448,1449,1450],"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":1452,"type":225},{"body":1453,"title":1454,"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":1456,"type":42},{"text":1457,"level":237},"Enterprise project context: requirements should precede architecture choices",{"id":692,"data":1459,"type":218},{"text":1460},"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":1462,"type":218},{"text":1463},"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":1465,"type":42},{"text":1466,"level":237},"Common failure modes when ADRs and NFRs are mixed",{"id":704,"data":1468,"type":290},{"content":1469,"stretched":43,"withHeadings":14},[1470,1474,1478,1482,1486,1490,1494,1498,1502],[1471,1472,1473],"Failure mode","What happens","Consequence",[1475,1476,1477],"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",[1479,1480,1481],"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",[1483,1484,1485],"ADR treated as proof","A documented choice is assumed to mean the requirement is satisfied","Architecture intent replaces measurement or verification",[1487,1488,1489],"Vague NFR","Words such as fast, scalable, secure or maintainable have no measurable scope","Different stakeholders can believe the same requirement means different things",[1491,1492,1493],"No alternatives recorded","The team records only the selected technology","Future maintainers cannot reconstruct why another option was rejected",[1495,1496,1497],"No supersession model","Old ADRs are edited or deleted when the architecture changes","Historical reasoning disappears and stale decisions can remain ambiguous",[1499,1500,1501],"Every implementation detail becomes an ADR","The repository fills with low-value records","Important architecture choices become difficult to find",[1503,1504,1505],"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":1507,"type":42},{"text":1508,"level":237},"The ADR–NFR decision framework",{"id":748,"data":1510,"type":218},{"text":1511},"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":1513,"type":437},{"steps":1514,"title":1539,"orientation":436},[1515,1518,1521,1524,1527,1530,1533,1536],{"label":1516,"description":1517},"1. Is this a required property or external constraint?","If yes, write or reference the requirement before choosing a mechanism.",{"label":1519,"description":1520},"2. Can it be validated?","Define the scope, condition, metric, acceptance rule, analysis method or other evidence needed.",{"label":1522,"description":1523},"3. Is it architecturally significant?","Identify whether the requirement materially shapes structure, technology, data, deployment or cross-cutting trade-offs.",{"label":1525,"description":1526},"4. Are there meaningful alternatives?","Compare viable tactics or architecture options rather than jumping directly to a preferred technology.",{"label":1528,"description":1529},"5. Has a choice become authoritative?","Create or update the ADR with context, decision, rationale, alternatives, trade-offs, status and consequences.",{"label":1531,"description":1532},"6. Is the decision implemented?","Trace the ADR into design, tasks, code, configuration and operations.",{"label":1534,"description":1535},"7. Is the requirement satisfied?","Collect validation evidence against the requirement itself.",{"label":1537,"description":1538},"8. Did conditions change?","Re-evaluate the requirement and, when necessary, supersede the ADR without erasing history.","ADR–NFR classification test",{"id":781,"data":1541,"type":42},{"text":1542,"level":237},"What ADR and NFR are not",{"id":785,"data":1544,"type":298},{"rows":1545,"title":1558,"layout":290,"columns":1559},[1546,1548,1550,1552,1555],{"id":293,"label":1130,"values":1547},{"not":790,"why":791,"term":792},{"id":296,"label":617,"values":1549},{"not":795,"why":796,"term":797},{"id":799,"label":1400,"values":1551},{"not":802,"why":803,"term":804},{"id":806,"label":1553,"values":1554},"Backlog item",{"not":809,"why":810,"term":811},{"id":813,"label":1556,"values":1557},"Constraint",{"not":816,"why":817,"term":818},"Common category errors",[1560,1562,1564],{"id":822,"label":1561},"Concept",{"id":825,"label":1563},"It is not",{"id":828,"label":1305},{"id":830,"data":1566,"type":42},{"text":1567,"level":237},"What would change this answer?",{"id":834,"data":1569,"type":218},{"text":1570},"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":1572,"type":218},{"text":1573},"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":1575,"type":218},{"text":1576},"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":1578,"type":42},{"text":1579,"level":237},"Limitations",{"id":850,"data":1581,"type":218},{"text":1582},"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":1584,"type":218},{"text":1585},"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":1587,"type":218},{"text":1588},"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":1590,"type":42},{"text":1591,"level":237},"Conclusion",{"id":866,"data":1593,"type":218},{"text":1594},"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":1596,"type":218},{"text":1597},"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":1599,"type":218},{"text":1600},"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":1602,"type":42},{"text":880,"level":237},{"id":882,"data":1604,"type":882},{"items":1605,"title":913},[1606,1609,1612,1615,1618,1621,1624],{"id":886,"answer":1607,"question":1608},"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":1610,"question":1611},"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":1613,"question":1614},"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":1616,"question":1617},"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":1619,"question":1620},"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":1622,"question":1623},"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":1625,"question":1626},"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":1628,"type":42},{"text":1629,"level":237},"Glossary",{"id":919,"data":1631,"type":919},{"title":1632,"entries":1633},"Core architecture terms",[1634,1636,1639,1641,1644,1646,1649,1652],{"term":924,"anchor":293,"definition":1635},"Non-functional requirement: practical shorthand for a required system quality, constraint, or operating condition; exact terminology varies by method and standard.",{"term":1637,"anchor":928,"definition":1638},"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":1640},"A durable record of an architecturally significant decision and enough context to understand why the choice was made and what consequences follow.",{"term":1642,"anchor":935,"definition":1643},"Architecturally Significant Requirement (ASR)","A requirement with sufficiently far-reaching architectural impact that it materially influences the system design.",{"term":1556,"anchor":813,"definition":1645},"A condition that restricts the solution space, including external policy, regulation, platform, compatibility, contractual or organizational boundaries.",{"term":1647,"anchor":941,"definition":1648},"Trade-off","A design relationship in which improving one objective, property or cost dimension can worsen another.",{"term":1650,"anchor":495,"definition":1651},"Validation","Evidence-producing work used to determine whether the implemented system satisfies the stated requirement under the relevant conditions.",{"term":1653,"anchor":948,"definition":1654},"Superseded ADR","A historical decision record that has been replaced by a newer authoritative decision while remaining available for traceability.",{"id":951,"data":1656,"type":42},{"text":1657,"level":237},"Primary sources and implementation evidence",{"id":955,"data":1659,"type":218},{"text":1660},"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":1662,"type":967},{"link":961,"meta":1663},{"image":1664,"title":1665,"description":1666},{"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":1668,"type":967},{"link":971,"meta":1669},{"image":1670,"title":1671,"description":1672},{"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":1674,"type":967},{"link":979,"meta":1675},{"image":1676,"title":1677,"description":1678},{"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":1680,"type":967},{"link":987,"meta":1681},{"image":1682,"title":1683,"description":1684},{"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":1686,"type":967},{"link":995,"meta":1687},{"image":1688,"title":1689,"description":1690},{"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":1692,"type":967},{"link":1003,"meta":1693},{"image":1694,"title":1695,"description":1696},{"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":1698,"type":967},{"link":1011,"meta":1699},{"image":1700,"title":1701,"description":1702},{"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":1704,"type":967},{"link":1019,"meta":1705},{"image":1706,"title":1707,"description":1708},{"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":1710,"type":967},{"link":1027,"meta":1711},{"image":1712,"title":1713,"description":1714},{"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":1718,"excerpt":1033},{"time":212,"blocks":1719,"version":1032},[1720,1722,1724,1726,1728,1730,1732,1734,1736,1752,1754,1756,1758,1760,1769,1771,1773,1775,1777,1779,1790,1792,1794,1796,1805,1807,1809,1811,1813,1828,1830,1832,1834,1844,1846,1848,1850,1852,1854,1856,1858,1867,1869,1871,1882,1884,1886,1888,1890,1892,1902,1904,1906,1908,1910,1912,1924,1926,1928,1939,1941,1958,1960,1962,1964,1966,1968,1970,1972,1974,1976,1978,1980,1982,1984,1994,1996,2007,2009,2011,2015,2019,2023,2027,2031,2035,2039,2043],{"id":215,"data":1721,"type":218},{"text":217},{"id":220,"data":1723,"type":225},{"body":222,"title":223,"variant":224},{"id":227,"data":1725,"type":225},{"body":229,"title":230,"variant":231},{"id":233,"data":1727,"type":238},{"title":235,"maxLevel":236,"minLevel":237},{"id":240,"data":1729,"type":42},{"text":242,"level":237},{"id":244,"data":1731,"type":218},{"text":246},{"id":248,"data":1733,"type":218},{"text":250},{"id":252,"data":1735,"type":218},{"text":254},{"id":256,"data":1737,"type":298},{"rows":1738,"title":289,"layout":290,"columns":1749},[1739,1741,1743,1745,1747],{"id":260,"label":261,"values":1740},{"adr":263,"nfr":264},{"id":266,"label":267,"values":1742},{"adr":269,"nfr":270},{"id":272,"label":273,"values":1744},{"adr":275,"nfr":276},{"id":278,"label":279,"values":1746},{"adr":281,"nfr":282},{"id":284,"label":285,"values":1748},{"adr":287,"nfr":288},[1750,1751],{"id":293,"label":294},{"id":296,"label":297},{"id":300,"data":1753,"type":42},{"text":302,"level":237},{"id":304,"data":1755,"type":218},{"text":306},{"id":308,"data":1757,"type":218},{"text":310},{"id":312,"data":1759,"type":218},{"text":314},{"id":316,"data":1761,"type":290},{"content":1762,"stretched":43,"withHeadings":14},[1763,1764,1765,1766,1767,1768],[320,321,322],[324,325,326],[328,329,330],[332,333,334],[336,337,338],[340,341,342],{"id":344,"data":1770,"type":225},{"body":346,"title":347,"variant":348},{"id":350,"data":1772,"type":42},{"text":352,"level":237},{"id":354,"data":1774,"type":218},{"text":356},{"id":358,"data":1776,"type":218},{"text":360},{"id":362,"data":1778,"type":218},{"text":364},{"id":366,"data":1780,"type":290},{"content":1781,"stretched":43,"withHeadings":14},[1782,1783,1784,1785,1786,1787,1788,1789],[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":1791,"type":42},{"text":404,"level":237},{"id":406,"data":1793,"type":218},{"text":408},{"id":410,"data":1795,"type":218},{"text":412},{"id":414,"data":1797,"type":437},{"steps":1798,"title":435,"orientation":436},[1799,1800,1801,1802,1803,1804],{"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":1806,"type":225},{"body":441,"title":442,"variant":443},{"id":445,"data":1808,"type":42},{"text":447,"level":237},{"id":449,"data":1810,"type":218},{"text":451},{"id":453,"data":1812,"type":218},{"text":455},{"id":457,"data":1814,"type":298},{"rows":1815,"title":488,"layout":290,"columns":1824},[1816,1818,1820,1822],{"id":461,"label":462,"values":1817},{"adr":464,"nfr":465,"validation":466},{"id":468,"label":469,"values":1819},{"adr":471,"nfr":472,"validation":473},{"id":475,"label":476,"values":1821},{"adr":478,"nfr":479,"validation":480},{"id":482,"label":483,"values":1823},{"adr":485,"nfr":486,"validation":487},[1825,1826,1827],{"id":293,"label":491},{"id":296,"label":493},{"id":495,"label":496},{"id":498,"data":1829,"type":42},{"text":500,"level":237},{"id":502,"data":1831,"type":218},{"text":504},{"id":506,"data":1833,"type":218},{"text":508},{"id":510,"data":1835,"type":290},{"content":1836,"stretched":43,"withHeadings":14},[1837,1838,1839,1840,1841,1842,1843],[514,515,516],[518,519,520],[522,523,524],[526,527,528],[530,531,532],[534,535,536],[538,523,539],{"id":541,"data":1845,"type":42},{"text":543,"level":237},{"id":545,"data":1847,"type":218},{"text":547},{"id":549,"data":1849,"type":218},{"text":551},{"id":553,"data":1851,"type":225},{"body":555,"title":556,"variant":443},{"id":558,"data":1853,"type":42},{"text":560,"level":237},{"id":562,"data":1855,"type":218},{"text":564},{"id":566,"data":1857,"type":218},{"text":568},{"id":570,"data":1859,"type":437},{"steps":1860,"title":591,"orientation":436},[1861,1862,1863,1864,1865,1866],{"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":1868,"type":42},{"text":595,"level":237},{"id":597,"data":1870,"type":218},{"text":599},{"id":601,"data":1872,"type":437},{"steps":1873,"title":628,"orientation":436},[1874,1875,1876,1877,1878,1879,1880,1881],{"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":1883,"type":42},{"text":632,"level":237},{"id":634,"data":1885,"type":225},{"body":636,"title":637,"variant":231},{"id":639,"data":1887,"type":218},{"text":641},{"id":643,"data":1889,"type":218},{"text":645},{"id":647,"data":1891,"type":218},{"text":649},{"id":651,"data":1893,"type":290},{"content":1894,"stretched":43,"withHeadings":14},[1895,1896,1897,1898,1899,1900,1901],[655,656,657],[659,660,661],[663,664,665],[667,668,669],[671,672,673],[675,676,677],[679,680,681],{"id":683,"data":1903,"type":225},{"body":685,"title":686,"variant":348},{"id":688,"data":1905,"type":42},{"text":690,"level":237},{"id":692,"data":1907,"type":218},{"text":694},{"id":696,"data":1909,"type":218},{"text":698},{"id":700,"data":1911,"type":42},{"text":702,"level":237},{"id":704,"data":1913,"type":290},{"content":1914,"stretched":43,"withHeadings":14},[1915,1916,1917,1918,1919,1920,1921,1922,1923],[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":1925,"type":42},{"text":746,"level":237},{"id":748,"data":1927,"type":218},{"text":750},{"id":752,"data":1929,"type":437},{"steps":1930,"title":779,"orientation":436},[1931,1932,1933,1934,1935,1936,1937,1938],{"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":1940,"type":42},{"text":783,"level":237},{"id":785,"data":1942,"type":298},{"rows":1943,"title":819,"layout":290,"columns":1954},[1944,1946,1948,1950,1952],{"id":293,"label":294,"values":1945},{"not":790,"why":791,"term":792},{"id":296,"label":617,"values":1947},{"not":795,"why":796,"term":797},{"id":799,"label":800,"values":1949},{"not":802,"why":803,"term":804},{"id":806,"label":807,"values":1951},{"not":809,"why":810,"term":811},{"id":813,"label":814,"values":1953},{"not":816,"why":817,"term":818},[1955,1956,1957],{"id":822,"label":823},{"id":825,"label":826},{"id":828,"label":516},{"id":830,"data":1959,"type":42},{"text":832,"level":237},{"id":834,"data":1961,"type":218},{"text":836},{"id":838,"data":1963,"type":218},{"text":840},{"id":842,"data":1965,"type":218},{"text":844},{"id":846,"data":1967,"type":42},{"text":848,"level":237},{"id":850,"data":1969,"type":218},{"text":852},{"id":854,"data":1971,"type":218},{"text":856},{"id":858,"data":1973,"type":218},{"text":860},{"id":862,"data":1975,"type":42},{"text":864,"level":237},{"id":866,"data":1977,"type":218},{"text":868},{"id":870,"data":1979,"type":218},{"text":872},{"id":874,"data":1981,"type":218},{"text":876},{"id":878,"data":1983,"type":42},{"text":880,"level":237},{"id":882,"data":1985,"type":882},{"items":1986,"title":913},[1987,1988,1989,1990,1991,1992,1993],{"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":1995,"type":42},{"text":917,"level":237},{"id":919,"data":1997,"type":919},{"title":921,"entries":1998},[1999,2000,2001,2002,2003,2004,2005,2006],{"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":2008,"type":42},{"text":953,"level":237},{"id":955,"data":2010,"type":218},{"text":957},{"id":959,"data":2012,"type":967},{"link":961,"meta":2013},{"image":2014,"title":965,"description":966},{"url":964},{"id":969,"data":2016,"type":967},{"link":971,"meta":2017},{"image":2018,"title":974,"description":975},{"url":964},{"id":977,"data":2020,"type":967},{"link":979,"meta":2021},{"image":2022,"title":982,"description":983},{"url":964},{"id":985,"data":2024,"type":967},{"link":987,"meta":2025},{"image":2026,"title":990,"description":991},{"url":964},{"id":993,"data":2028,"type":967},{"link":995,"meta":2029},{"image":2030,"title":998,"description":999},{"url":964},{"id":1001,"data":2032,"type":967},{"link":1003,"meta":2033},{"image":2034,"title":1006,"description":1007},{"url":964},{"id":1009,"data":2036,"type":967},{"link":1011,"meta":2037},{"image":2038,"title":1014,"description":1015},{"url":964},{"id":1017,"data":2040,"type":967},{"link":1019,"meta":2041},{"image":2042,"title":1022,"description":1023},{"url":964},{"id":1025,"data":2044,"type":967},{"link":1027,"meta":2045},{"image":2046,"title":1030,"description":1031},{"url":964},"Post erfolgreich abgerufen",{"items":2049,"source":2078,"manualIds":2079,"manualMatchedIds":2080},[2050,2057,2064,2071],{"id":2051,"slug":2052,"title":2053,"excerpt":2054,"featuredImage":2055,"publishedAt":2056},"481","generative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing","L'IA generativa spiegata: modelli, recupero, strumenti e applicazioni non sono la stessa cosa","L'IA generativa è più di un modello. Scopri come modelli, recupero, strumenti, contesto, runtime e applicazioni si integrano nei sistemi di IA in produzione.","\u002Fuploads\u002F2026\u002F10\u002Fgenerative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing-1791475411822-pp0dvz.webp","2026-10-08T12:00:00.000Z",{"id":2058,"slug":2059,"title":2060,"excerpt":2061,"featuredImage":2062,"publishedAt":2063},"435","ultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks","Guida Definitiva ai Criteri di Accettazione per l'Adozione di LLM nei Playbook Aziendali","Padroneggia l'arte di definire criteri di accettazione precisi per garantire un'integrazione LLM di successo nel tuo ambiente aziendale. Questa guida completa fornisce framework attuabili, esempi e best practice su misura per l'adozione guidata da playbook.","\u002Fuploads\u002F2026\u002F09\u002Fultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks-1788540267775-zgr6mm.webp","2026-09-06T11:50:00.000Z",{"id":2065,"slug":2066,"title":2067,"excerpt":2068,"featuredImage":2069,"publishedAt":2070},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Padroneggiare il Flusso di Lavoro SEO: Strategie di Ottimizzazione Essenziali per la Crescita Organica","Un flusso di lavoro SEO strutturato è fondamentale per una crescita organica sostenibile. Scopri le dieci strategie fondamentali, dalla ricerca di parole chiave e dall'ottimizzazione tecnica alla qualità dei contenuti e all'analisi delle prestazioni.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z",{"id":2072,"slug":2073,"title":2074,"excerpt":2075,"featuredImage":2076,"publishedAt":2077},"455","zbt-z8102ax-dual-sim-failover-test","ZBT Z8102AX Failover Dual-SIM: cosa funziona, cosa manca e cosa necessita di un firmware migliore","Lo ZBT Z8102AX è un router OpenWrt 5G dual-SIM, ma l'hardware dual-SIM da solo non è la stessa cosa di un failover intelligente. Il router riconosce la SIM e si connette con successo, ma la commutazione automatica, il ripristino del modem, le decisioni basate sul segnale e una logica di failover pulita richiedono ancora test più approfonditi.","\u002Fuploads\u002F2026\u002F06\u002Fopenwrt-router-review-dual-sim-03-1781620592829-7t77j7.webp","2026-06-16T10:40:00.000Z","fallback",[],[]]