[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:sr":3,"public-menus:all":38,"post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:sr":205,"related:post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:sr: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","sr","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":1032,"featuredImage":1033,"featuredImageAlt":1034,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1035,"publishedAt":1036,"createdAt":1037,"updatedAt":1038,"seoLocalePaths":1039,"categories":1048,"author":1069,"translations":1074},"482","ADR vs NFR: Arhitektonske odluke i kvalitet sistema nisu ista stvar","adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u003Cp>\u003Cstrong>Nefunkcionalni zahtev (NFR)\u003C\u002Fstrong> opisuje kvalitet, ograničenje ili uslov rada koji sistem treba da zadovolji. \u003Cstrong>Zapis arhitektonske odluke (ADR)\u003C\u002Fstrong> beleži arhitektonski značajan izbor donet kao odgovor na zahteve, ograničenja, rizike i kompromise. Oni su povezani, ali nisu zamenljivi: NFR navodi šta mora biti istinito; ADR objašnjava šta je odlučeno, zašto i sa kakvim posledicama.\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\">Direktan odgovor\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>NFR = zahtevani kvalitet ili ograničenje sistema. ADR = zabeležena arhitektonska odluka.\u003C\u002Fstrong> Ciljna latencija, cilj dostupnosti, pravilo izolacije, ograničenje implementacije ili zahtev za održivost mogu uticati na arhitekturu. ADR zatim beleži značajan izbor donet da se reši jedan ili više takvih pokretača. ADR ne zamenjuje zahtev, a postojanje ADR-a ne dokazuje da je zahtev zadovoljen.\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\">Napomena o terminologiji i standardima\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Termin \u003Cstrong>NFR\u003C\u002Fstrong> je široko korišćen, ali nije savršeno standardizovan. Ovaj članak ga koristi kao praktičnu skraćenicu za zahteve kvaliteta i relevantna ograničenja. Aktuelni standardi su ponovo provereni \u003Cstrong>8. oktobra 2026.\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 je i dalje aktuelan, ali je u reviziji; ISO\u002FIEC 25010:2023 i ISO\u002FIEC\u002FIEEE 42010:2022 su aktuelna objavljena izdanja citirana ovde.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Sadržaj\">\u003Cstrong class=\"editorjs-toc__title\">Sadržaj\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\">Koja je razlika između NFR-a i ADR-a?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">Šta je NFR u preciznim arhitektonskim terminima?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-16\" class=\"editorjs-toc__link\">Šta je zapis arhitektonske odluke?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-21\" class=\"editorjs-toc__link\">Najjednostavniji primer: zahtev za latenciju → arhitektonska odluka\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-26\" class=\"editorjs-toc__link\">NFR-ovi i ADR-ovi obično imaju odnos više-na-više\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-30\" class=\"editorjs-toc__link\">Izbor tehnologije nije automatski zahtev\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-34\" class=\"editorjs-toc__link\">ADR nije dokaz da je NFR zadovoljen\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-38\" class=\"editorjs-toc__link\">Kada nefunkcionalni zahtev postaje arhitektonski značajan?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-42\" class=\"editorjs-toc__link\">Jači arhitektonski model: zahtev → odluka → implementacija → validacija\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-45\" class=\"editorjs-toc__link\">Implementacioni dokaz: kako razdvajam zahteve i odluke u SenseFlow-u\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-52\" class=\"editorjs-toc__link\">Kontekst enterprise projekta: zahtevi treba da prethode arhitektonskim izborima\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-55\" class=\"editorjs-toc__link\">Uobičajeni obrasci neuspeha kada se ADR i NFR mešaju\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-57\" class=\"editorjs-toc__link\">ADR–NFR okvir za odlučivanje\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-60\" class=\"editorjs-toc__link\">Šta ADR i NFR nisu\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-62\" class=\"editorjs-toc__link\">Šta bi promenilo ovaj odgovor?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-66\" class=\"editorjs-toc__link\">Ograničenja\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-70\" class=\"editorjs-toc__link\">Zaključak\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-74\" class=\"editorjs-toc__link\">Često postavljana pitanja\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-76\" class=\"editorjs-toc__link\">Pojmovnik\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Primarni izvori i dokazi o implementaciji\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-5\">Koja je razlika između NFR-a i ADR-a?\u003C\u002Fh2>\n\u003Cp>Najjednostavnija razlika je gramatička. Zahtev opisuje uslov koji sistem mora da zadovolji. Zapis odluke opisuje izbor koji je tim napravio.\u003C\u002Fp>\n\u003Cp>Na primer, \u003Cstrong>„API mora da vrati 95% zahteva za čitanje u roku od 300 ms pod dogovorenim referentnim opterećenjem“\u003C\u002Fstrong> je zahtev kvaliteta. \u003Cstrong>„Koristiti keš za čitanje za ovo opterećenje jer izmerena putanja samo preko baze podataka ne može da ispuni ciljnu latenciju bez neprihvatljivih troškova“\u003C\u002Fstrong> je arhitektonska odluka.\u003C\u002Fp>\n\u003Cp>Prva izjava ostaje važeća čak i ako se implementacija promeni. Druga izjava može kasnije biti zamenjena drugom odlukom ako se opterećenje, tehnologija, model troškova ili dokazi promene.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">NFR i ADR odgovaraju na različita pitanja\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 zahtev kvaliteta\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 arhitektonska odluka\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\">Primarno pitanje\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\">Tipičan sadržaj\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\">Uloga u životnom ciklusu\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\">Šta ga dokazuje?\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\">Kada se menja\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\">Šta je NFR u preciznim arhitektonskim terminima?\u003C\u002Fh2>\n\u003Cp>„Nefunkcionalni zahtev“ je zgodna industrijska oznaka, ali može da sakrije nekoliko različitih vrsta izjava. U arhitektonskom radu, korisna razlika je između \u003Cstrong>funkcionalnog ponašanja\u003C\u002Fstrong>, \u003Cstrong>zahteva kvaliteta\u003C\u002Fstrong> i \u003Cstrong>ograničenja\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC 25010:2023 pruža model kvaliteta proizvoda sa devet karakteristika i potkategorija koje se mogu koristiti pri specifikaciji i evaluaciji kvaliteta IKT i softverskih proizvoda. SEI arhitektonski rad na sličan način tretira zahteve atributa kvaliteta kao glavne pokretače softverske arhitekture.\u003C\u002Fp>\n\u003Cp>Koristan NFR stoga nije „sistem treba da bude brz“ ili „platforma mora da bude bezbedna.“ Te izjave imenuju aspiracije. Zahtev koji pokreće arhitekturu treba da učini očekivano svojstvo dovoljno proverljivim da se projektne alternative i kasniji dokazi mogu evaluirati u odnosu na njega.\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\">Slaba izjava\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Korisniji oblik zahteva\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Zašto je razlika važna\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">API mora da bude brz\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Za opterećenje W, 95% operacije X završava se u roku od T milisekundi\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Definiše opterećenje, operaciju, metriku i prag\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Servis mora da bude dostupan\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Servis S ispunjava dogovoreni cilj dostupnosti tokom perioda merenja M, isključujući eksplicitno definisane uslove održavanja\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Čini dostupnost merljivom i definiše obim\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Podaci zakupaca moraju da budu bezbedni\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Zahtev autentifikovan za zakupca A nikada ne sme da preuzme ili izmeni podatke zakupca B kroz podržane aplikativne putanje\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Pretvara nejasan bezbednosni cilj u svojstvo izolacije\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sistem treba da se skalira\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sistem podržava opterećenje W pri konkurentnosti C dok ispunjava pragove latencije i stope grešaka\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Povezuje skaliranje sa merljivim ponašanjem servisa\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Potreban nam je PostgreSQL\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nije sam po sebi NFR; prvo navedite zahtevane kvalitete perzistencije ili spoljno ograničenje\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Izbor tehnologije je obično rešenje, a ne zahtev koji treba da zadovolji\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\">Zahtev treba da opiše potrebu pre mehanizma\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Ako se „koristi Kubernetes“, „koristi PostgreSQL“, „koristi mikroservise“ ili „koristi vektorsku pretragu“ pojavljuje kao zahtev, pitajte da li je to zaista spoljno ograničenje ili je rešenje zapisano pre nego što je osnovna potreba za kvalitetom eksplicitno izražena.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-16\">Šta je zapis arhitektonske odluke?\u003C\u002Fh2>\n\u003Cp>Zapis arhitektonske odluke je sažet zapis važne arhitektonske odluke. Originalna ADR formulacija Michaela Nygarda naglašava \u003Cstrong>kontekst\u003C\u002Fstrong>, \u003Cstrong>odluku\u003C\u002Fstrong>, njen \u003Cstrong>status\u003C\u002Fstrong> i rezultujuće \u003Cstrong>posledice\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Važan objekat je odluka, a ne šablon. Različiti timovi koriste različite ADR formate. Bogatiji zapis može takođe da sačuva alternative, kriterijume odlučivanja, kompromise, dokaze, veze ka zahtevima i datum ili verziju od koje se odluka primenjuje.\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC\u002FIEEE 42010:2022 je širi od prakse ADR-a: specificira zahteve za opise arhitekture i njihove koncepte, dok eksplicitno ne propisuje jedan proces, notaciju, alat, format ili medijum za beleženje opisa arhitekture. ADR je stoga praktična tehnika beleženja odluka, a ne format koji zahteva 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\">ADR polje\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Šta čuva\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Zašto je važno\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Kontekst\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Problem, sile, zahtevi, pretpostavke i okruženje koje okružuje izbor\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Budući čitaoci mogu da rekonstruišu zašto je izbor bio neophodan\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Odluka\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Izbor koji je postao merodavan\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Razdvaja izabranu opciju od diskusije\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Status\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Predloženo, prihvaćeno, odbijeno, zastarelo, zamenjeno ili drugo kontrolisano stanje\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sprječava da stare odluke tiho ostanu aktivne\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\">Druge održive opcije koje su razmatrane\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Pokazuje da izabrano rešenje nije bilo jedino zamislivo\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Obrazloženje \u002F kompromisi\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Zašto je opcija izabrana i čega se odriče\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Čini arhitektonsko rezonovanje proverljivim\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Posledice\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Očekivani pozitivni i negativni efekti, naknadni rad, rizici\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Povezuje lokalni izbor sa uticajem na sistem\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Datum \u002F verzija\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Kada je odluka postala važeća\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Podržava istorijsku sledljivost i kasnije zamene\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-21\">Najjednostavniji primer: zahtev za latenciju → arhitektonska odluka\u003C\u002Fh2>\n\u003Cp>Pretpostavimo da se vlasnik proizvoda i inženjerski tim slažu da krajnja tačka za pretragu mora da vrati prvu stranicu rezultata u roku od 400 ms na 95. percentilu pod definisanim referentnim opterećenjem.\u003C\u002Fp>\n\u003Cp>Taj cilj nije ADR. To je zahtev za kvalitet. Arhitektonski rad počinje pitanjem koji dizajn može da ga zadovolji pod ostalim ograničenjima sistema.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Od zahteva do dokaza\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. Navedite zahtev\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Definišite cilj kvaliteta, opterećenje, obim, prag i metod validacije.\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. Identifikujte arhitektonski značaj\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Utvrdite da li zahtev materijalno utiče na strukturu, tehnologiju, raspoređivanje, tok podataka ili operativni model.\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. Procenite opcije\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Uporedite alternative kao što su indeksiranje, keširanje, denormalizacija, asinhroni rad, particionisanje ili druga arhitektura upita.\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. Zabeležite odluku\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Zabeležite izabrani arhitektonski izbor, obrazloženje, alternative, kompromise, status i posledice u ADR-u.\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. Implementirajte\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Pretvorite odluku u kod, infrastrukturu, konfiguraciju i operativno ponašanje.\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. Validirajte\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Izmerite stvarni sistem u odnosu na prvobitni zahtev. Rezultat testa validira NFR; sam ADR to ne čini.\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\">Gde se jednostavan primer zaustavlja\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Stvarni sistemi retko imaju jedan zahtev i jednu odluku. Performanse se mogu menjati u odnosu na troškove, konzistentnost, operabilnost, bezbednost, održivost, potrošnju energije ili rizik isporuke. Koristan model je stoga graf sledljivosti, a ne jedan-na-jedan mapiranje.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-26\">NFR-ovi i ADR-ovi obično imaju odnos više-na-više\u003C\u002Fh2>\n\u003Cp>Jedan zahtev za kvalitet može da pokrene nekoliko arhitektonskih odluka. Zahtev za izolaciju zakupaca, na primer, može da utiče na propagaciju identiteta, opseg baze podataka, dizajn pozadinskih poslova, ključeve keša, evidentiranje revizije i administrativne alate.\u003C\u002Fp>\n\u003Cp>Jedna arhitektonska odluka takođe može da odgovori na nekoliko zahteva istovremeno. Izbor asinhrone granice obrade može da poboljša responzivnost i izolaciju otkaza, dok uvodi kompromise u konzistentnosti, složenosti, nadzirljivosti i operativnosti.\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Zašto odnos nije jedan-na-jedan\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\">Strana zahteva\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\">Strana odluke\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\">Strana validacije\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\">Jedan NFR → mnogo ADR-ova\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\">Mnogo NFR-ova → jedan 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 bez klasičnog NFR-a\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\">Zahtev stabilan, ADR se menja\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\">Izbor tehnologije nije automatski zahtev\u003C\u002Fh2>\n\u003Cp>Česta arhitektonska greška je da se preferirana tehnologija upiše u sloj zahteva i da se onda rezultujući dizajn tretira kao neizbežan.\u003C\u002Fp>\n\u003Cp>„Sistem mora da koristi PostgreSQL“ može biti legitimno ograničenje ako ugovor, politika platforme, zahtev kompatibilnosti, pravilo licenciranja, organizacioni standard ili postojeća operativna granica zaista nalažu PostgreSQL. Ali ako je stvarna potreba transakciona konzistentnost, strukturisano upitavanje, operativna upoznatost ili specifičan cilj oporavka, zahtev treba da navede tu potrebu, a izbor tehnologije treba zabeležiti kao odluku.\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\">Izjava\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Klasifikacija\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Razlog\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sva čitanja u opsegu zakupca moraju da sprovedu izolaciju zakupaca\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Zahtev \u002F bezbednosno svojstvo\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Opisuje svojstvo koje mora da važi\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Koristite PostgreSQL Row Level Security za izabrane tabele u opsegu zakupca\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Arhitektonska odluka\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Bira mehanizam namenjen da pomogne u zadovoljavanju svojstva izolacije\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ciljno okruženje za raspoređivanje mora da radi u odobrenom okruženju kojim upravlja EU\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ograničenje \u002F operativni uslov sličan NFR-u\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ograničava gde sistem može da radi\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Koristite provajdera X u regionu Y\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Arhitektonska \u002F odluka o raspoređivanju osim ako nije spolja propisana\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Bira određeno rešenje unutar dozvoljene granice\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Latencija API-ja na 95. percentilu ≤ 300 ms pod opterećenjem W\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Zahtev za kvalitet\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Definiše merljivo ponašanje performansi\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Uvedite keš za krajnju tačku X\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Arhitektonska odluka\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Bira taktiku namenjenu da poboljša merljivo ponašanje\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-34\">ADR nije dokaz da je NFR zadovoljen\u003C\u002Fh2>\n\u003Cp>Dokumentacija odluka i validacija sistema odgovaraju na različita pitanja. ADR može da pokaže da su performanse, bezbednost, otpornost ili održivost razmatrani. Ne može sam po sebi da dokaže da isporučeni sistem zaista postiže ta svojstva.\u003C\u002Fp>\n\u003Cp>Dokaz mora da dođe iz metoda validacije koji odgovara zahtevu: benchmark, test opterećenja, test otkaza, bezbednosni test, arhitektonska analiza, revizija, inspekcija, operativna telemetrija, vežba oporavka, studija korisnika ili drugi oblik dokaza.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Ne mešajte nameru sa dokazom\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>ADR:\u003C\u002Fstrong> „Izabrali smo dizajn X jer se očekuje da zadovolji zahtev R pod pretpostavkama A.“\u003Cbr>\u003Cstrong>Validacija:\u003C\u002Fstrong> „Izmereni ili analizirani dokaz E pokazuje da li implementirani sistem zaista zadovoljava R.“\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-38\">Kada nefunkcionalni zahtev postaje arhitektonski značajan?\u003C\u002Fh2>\n\u003Cp>Nije svaki nefunkcionalni zahtev vredan arhitektonske odluke. Važan podskup čine zahtevi koji suštinski oblikuju arhitekturu ili nameću kompromise kroz sistem.\u003C\u002Fp>\n\u003Cp>SEI literatura koristi koncept \u003Cstrong>arhitektonski značajnih zahteva\u003C\u002Fstrong> za zahteve sa dalekosežnim arhitektonskim efektom. Atributi kvaliteta kao što su performanse, pouzdanost, bezbednost i modifikabilnost česti su izvori takvih pokretača, naročito kada nose visoku poslovnu ili misijsku vrednost.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Test arhitektonske značajnosti\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. Pitajte da li zahtev menja strukturu\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Da li bi različite vrednosti nametnule različite komponente, granice, tokove podataka ili topologiju postavljanja?\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. Pitajte da li ograničava glavne tehnološke izbore\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Da li eliminiše inače održive opcije implementacije?\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. Pitajte da li stvara ponašanje koje seče kroz slojeve\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Da li utiče na mnoge komponente, timove, interfejse ili faze životnog ciklusa?\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. Pitajte da li stvara težak kompromis\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Da li poboljšanje ovog svojstva materijalno utiče na drugi kvalitet, trošak, raspored, složenost ili rizik?\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. Pitajte da li je neuspeh skup\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Da li bi propuštanje zahteva stvorilo materijalni operativni, bezbednosni, regulatorni, finansijski ili produktni uticaj?\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. Beležite odluke samo tamo gde je obrazloženje vredno čuvanja\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Ne pravite ADR za svaki lokalni izbor kodiranja; čuvajte arhitektonski značajne odluke i njihovo obrazloženje.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-42\">Jači arhitektonski model: zahtev → odluka → implementacija → validacija\u003C\u002Fh2>\n\u003Cp>Najkorisnija veza između NFR-ova i ADR-ova je sledljivost. Zahtev treba da može da ukaže na arhitektonske odluke koje ga rešavaju; ADR treba da identifikuje pokretače na koje odgovara; implementacioni rad treba da realizuje odluku; validacija treba da se vrati na originalni zahtev.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Lanac arhitektonske sledljivosti\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\">Potreba \u002F poslovni cilj\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Zašto su kvalitet ili ograničenje važni.\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\">Zahtev \u002F NFR\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Šta sistem mora da postigne ili poštuje.\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\">Arhitektonski pokretači\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Koji su zahtevi dovoljno značajni da oblikuju dizajn.\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\">Opcije\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Verodostojni načini da se adresira pokretač.\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\">Izabrani izbor, obrazloženje, alternative, kompromisi i posledice.\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\">Implementacija\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Kod, model podataka, infrastruktura, interfejsi i operativni mehanizmi koji realizuju odluku.\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\">Dokaz validacije\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Testovi, merenja, analize ili revizije koje pokazuju da li je originalni zahtev zaista zadovoljen.\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\">Promena \u002F zamena\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Novi dokazi ili promenjeni zahtevi mogu pokrenuti novi ADR uz očuvanje istorijskog obrazloženja.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-45\">Implementacioni dokaz: kako razdvajam zahteve i odluke u SenseFlow-u\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\">Originalna implementacija \u002F dokaz projekta\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Sledeći odeljak opisuje strukturu mog sopstvenog SenseFlow projekta. To je implementacioni dokaz za razdvajanje u ovom članku, a ne tvrdnja da svaki tim mora da koristi isti model dokumentacije.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>U SenseFlow-u, projektni Izvor istine eksplicitno smešta nefunkcionalne zahteve unutar strukture zahteva zajedno sa zavisnostima, rizicima, pretpostavkama, kriterijumima prihvatanja i metodom validacije. Model dokumentacije odvojeno definiše integritet odluka za značajne odluke.\u003C\u002Fp>\n\u003Cp>Za značajne SenseFlow odluke, evidentirana polja su \u003Cstrong>Odluka, Razlog, Alternative, Kompromisi, Status i Datum \u002F Verzija\u003C\u002Fstrong>. Glavne arhitektonske i produktne odluke treba da ostanu istorijski sledljive umesto da budu prepisane kada projekat evoluira.\u003C\u002Fp>\n\u003Cp>SenseFlow takođe dodeljuje različite operativne uloge Confluence-u i Jira-i. Confluence je strukturisano okruženje znanja i odluka; Jira upravlja izvršnim radom na isporuci. Glavni Jira Epics treba da se povezuju nazad na relevantnu produktnu ili zahtevnu dokumentaciju. To čuva lanac od produktne namere kroz zahteve i odluke do implementacije, umesto da backlog pretvara u arhitektonski Izvor istine.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">SenseFlow sloj\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Šta sadrži\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Uloga u razdvajanju ADR\u002FNFR\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Produktna \u002F zahtevna struktura\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Produktni cilj, sposobnost, epic, korisnička priča, kriterijumi prihvatanja, tehnički zadaci; zahtevi mogu uključivati NFR-ove i metod validacije\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Čuva šta treba postići i kako će se uspeh proveravati\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Integritet odluka\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Odluka, razlog, alternative, kompromisi, status, datum\u002Fverzija\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Čuva zašto je arhitektonski značajan izbor postao autoritativan\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\">Zahtevi, arhitektura, istraživanje, zapisi odluka, rizici, mapa puta i prateći izvori\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Održava konceptualni i istorijski Izvor istine\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\">Inicijative\u002Fciljevi, epici, priče, zadaci i stanje isporuke\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Izvršava odobreni rad bez postajanja konceptualnog Izvora istine\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Upravljanje promenama\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Trenutno stanje → novi dokaz → predložena promena → uticaj → odluka\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Omogućava odlukama da evoluiraju bez brisanja traga obrazloženja\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sledljivost od početka do kraja\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Problem → potreba → vrednost → produktni cilj → zahtev → implementacija → validacija\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Održava dokumentaciju odluka povezanom sa stvarnim produktom i životnim ciklusom dokaza\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\">Šta ova implementacija pokazuje\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Zahtev i odluka mogu živeti blizu jedno drugom, a da ne budu spojeni u jedan zapis. Zahtev ostaje cilj; odluka ostaje istorija obrazloženja; rad na isporuci implementira odluku; validacija se vraća na cilj.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-52\">Kontekst enterprise projekta: zahtevi treba da prethode arhitektonskim izborima\u003C\u002Fh2>\n\u003Cp>Isto razdvajanje je korisno u projektnom radu orijentisanom na enterprise. Arhitektonske odluke donete pre nego što su zahtevi, rizici, ograničenja i uslovi prihvatanja dovoljno razumljeni mogu pretvoriti preferencije u lažne neophodnosti.\u003C\u002Fp>\n\u003Cp>Za Enterprise Aaasaasa 0.1, relevantna lekcija je metodološka, a ne tvrdnja o jednom konkretnom ADR-u: zahtevi, arhitektura, validacija, prekretnice, upravljanje rizicima i prihvatanje pripadaju povezanom sistemu isporuke. Arhitektonski izbor treba da ostane sledljiv do zahteva ili ograničenja koje treba da adresira.\u003C\u002Fp>\n\u003Ch2 id=\"section-55\">Uobičajeni obrasci neuspeha kada se ADR i NFR mešaju\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\">Obrazac neuspeha\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Šta se dešava\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Posledica\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tehnologija prerušena u zahtev\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Preferirano rešenje je napisano kao „mora se koristiti X“ bez utvrđivanja osnovne potrebe\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alternative se nikada ne evaluiraju i arhitektura postaje prerano fiksirana\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NFR skriven samo unutar ADR-a\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Odluka pominje cilj performansi\u002Fbezbednosti koji nije prisutan u osnovi zahteva\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cilj je teško validirati, prioritizovati ili upravljati njime nezavisno\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ADR tretiran kao dokaz\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Pretpostavlja se da dokumentovani izbor znači da je zahtev zadovoljen\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Arhitektonska namera zamenjuje merenje ili verifikaciju\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nejasan NFR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Reči poput brz, skalabilan, bezbedan ili održiv nemaju merljiv obim\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Različiti akteri mogu verovati da isti zahtev znači različite stvari\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nema evidentiranih alternativa\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tim evidentira samo izabranu tehnologiju\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Budući održavaoci ne mogu rekonstruisati zašto je druga opcija odbijena\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nema modela zamene\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Stari ADR-ovi se menjaju ili brišu kada se arhitektura promeni\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Istorijsko rezonovanje nestaje i zastarele odluke mogu ostati dvosmislene\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Svaki detalj implementacije postaje ADR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Repozitorijum se puni zapisima male vrednosti\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Važne arhitektonske odluke postaju teške za pronalaženje\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Backlog postaje izvor istine arhitekture\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jira zadaci se tretiraju kao jedino objašnjenje sistema\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Stanje isporuke preživljava, ali arhitektonsko obrazloženje i pokretači kvaliteta se gube\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-57\">ADR–NFR okvir za odlučivanje\u003C\u002Fh2>\n\u003Cp>Kada tim naiđe na novu arhitektonsku brigu, sledeći redosled pomaže da se utvrdi šta pripada zahtevima, šta pripada ADR-u, a šta pripada dokazima.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">ADR–NFR test klasifikacije\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. Da li je ovo obavezno svojstvo ili spoljno ograničenje?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Ako jeste, napišite ili navedite zahtev pre izbora mehanizma.\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. Može li se validirati?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Definišite obim, uslov, metriku, pravilo prihvatanja, metod analize ili druge potrebne dokaze.\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. Da li je arhitektonski značajno?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Utvrdite da li zahtev materijalno oblikuje strukturu, tehnologiju, podatke, raspoređivanje ili unakrsne kompromise.\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. Postoje li smislene alternative?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Uporedite održive taktike ili arhitektonske opcije umesto direktnog prelaska na preferiranu tehnologiju.\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. Da li je izbor postao autoritativan?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Kreirajte ili ažurirajte ADR sa kontekstom, odlukom, obrazloženjem, alternativama, kompromisima, statusom i posledicama.\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. Da li je odluka implementirana?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Pratite ADR kroz dizajn, zadatke, kod, konfiguraciju i operacije.\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. Da li je zahtev zadovoljen?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Prikupite dokaze validacije u odnosu na sam zahtev.\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. Da li su se uslovi promenili?\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Ponovo procenite zahtev i, kada je potrebno, zamenite ADR bez brisanja istorije.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-60\">Šta ADR i NFR nisu\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Uobičajene greške u kategorizaciji\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\">Koncept\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\">Nije\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\">Razlog\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 zahtev kvaliteta\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\">Dokaz validacije\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\">Stavka backlog-a\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\">Ograničenje\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\">Šta bi promenilo ovaj odgovor?\u003C\u002Fh2>\n\u003Cp>Terminologija može evoluirati. ISO\u002FIEC\u002FIEEE 29148:2018 ostaje trenutni objavljeni standard za inženjering zahteva od 8. oktobra 2026, ali ISO navodi nacrt međunarodnog standarda koji ga namerava zameniti. Ako novo izdanje promeni relevantnu terminologiju ili smernice za zahteve, reference specifične za verziju u ovom članku treba ažurirati.\u003C\u002Fp>\n\u003Cp>ADR šabloni takođe mogu evoluirati bez promene centralne razlike. Minimalni šablon Michaela Nygarda, MADR, šabloni specifični za organizaciju, alati za arhitektonsko znanje ili strukturisane baze odluka mogu svi evidentirati odluke. Trajno pitanje je da li zapis čuva dovoljno konteksta i obrazloženja da bi se razumeo arhitektonski značajan izbor.\u003C\u002Fp>\n\u003Cp>Razlika bi se srušila samo ako bi organizacija namerno izabrala kombinovani artefakt koji čuva i podatke o zahtevu i podatke o odluci u jednom dokumentu. Čak i tada, semantičke uloge ostaju različite: jedno polje navodi potreban ishod ili ograničenje; drugo evidentira izabrani odgovor.\u003C\u002Fp>\n\u003Ch2 id=\"section-66\">Ograničenja\u003C\u002Fh2>\n\u003Cp>Ovaj članak koristi \u003Cstrong>NFR\u003C\u002Fstrong> kao praktičnu skraćenicu. Neke inženjerske metode preferiraju termine kao što su zahtev za atributom kvaliteta, zahtev kvaliteta, kvalitet sistema, ograničenje, cilj na nivou usluge ili arhitektonski značajan zahtev. Ti termini nisu savršeno zamenljivi, i terminologija projekta treba da bude eksplicitna.\u003C\u002Fp>\n\u003Cp>Nije svaki zahtev moguće svesti na jedan numerički prag. Bezbednost, sigurnost, održivost, interoperabilnost, upotrebljivost, objašnjivost, prenosivost i upravljanje mogu zahtevati kombinacije scenarija, strukturnih pravila, analiza, procesnih kontrola i kvalitativnih dokaza. „Merljivo“ treba da znači dovoljno proverljivo za odluku, a ne veštački numeričko.\u003C\u002Fp>\n\u003Cp>Nije svaka arhitektonska odluka potreban formalni ADR. Trošak dokumentovanja treba da bude proporcionalan arhitektonskom značaju, dugovečnosti, neizvesnosti, složenosti kompromisa i trošku gubitka obrazloženja.\u003C\u002Fp>\n\u003Ch2 id=\"section-70\">Zaključak\u003C\u002Fh2>\n\u003Cp>ADR i NFR pripadaju različitim slojevima arhitektonskog rada. \u003Cstrong>NFR definiše cilj kvaliteta, ograničenje ili uslov rada. ADR evidentira značajan arhitektonski odgovor na jedan ili više pokretača.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Održavanje tih slojeva odvojenim čini arhitekturu lakšom za razmišljanje. Zahtevi se mogu validirati nezavisno od tehnologije. Odluke se mogu zameniti bez prepisivanja istorije. Alternative i kompromisi ostaju vidljivi. Rad na isporuci može se pratiti nazad do arhitektonske namere. Dokazi mogu pokazati da li rezultujući sistem zaista zadovoljava zahtev.\u003C\u002Fp>\n\u003Cp>Najjači lanac stoga nije „NFR → ADR → gotovo“. On je \u003Cstrong>potreba → zahtev → arhitektonski pokretači → opcije → odluka → implementacija → validacija → promena\u003C\u002Fstrong>. Taj lanac pretvara arhitektonsku dokumentaciju od statičke papirologije u proverljiv zapis o tome zašto sistem ima oblik koji ima.\u003C\u002Fp>\n\u003Ch2 id=\"section-74\">Često postavljana pitanja\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\">Da li je ADR nefunkcionalni zahtev?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Ne. NFR navodi zahtevani kvalitet, ograničenje ili uslov rada. ADR beleži arhitektonski značajan izbor donet kao odgovor na zahteve, ograničenja, rizike i kompromise.\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\">Da li svaki NFR treba da ima ADR?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Ne. Samo zahtevi koji materijalno utiču na arhitekturu zahtevaju odluke na nivou arhitekture koje vredi sačuvati. Jedan NFR može takođe da pokrene nekoliko ADR-ova, a jedan ADR može da odgovori na nekoliko zahteva.\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\">Može li „koristiti PostgreSQL“ biti NFR?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Samo kada je PostgreSQL zaista nametnut kao spoljno ograničenje. U suprotnom, osnovna potreba treba prvo da bude izražena, a izbor PostgreSQL-a treba normalno tretirati kao arhitektonsku odluku.\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\">Da li ADR dokazuje da je zahtev za performansama ili bezbednošću ispunjen?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Ne. ADR beleži nameru i obrazloženje. Zahtev se validira kroz odgovarajuće dokaze kao što su testiranje, merenje, analiza, revizija ili operativna telemetrija.\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\">Šta treba da sadrži ADR?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">U najmanju ruku, ADR treba da jasno prikaže kontekst i odluku. Uobičajene strukture takođe uključuju status i posledice. Timovi mogu dodati alternative, obrazloženje, kompromise, veze sa zahtevima, dokaze, vlasnike, datume i odnose zamene.\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\">Šta čini NFR arhitektonski značajnim?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Zahtev je arhitektonski značajan kada materijalno oblikuje strukturu sistema, tehnologiju, tokove podataka, raspoređivanje, sveobuhvatno ponašanje ili teške kompromise kvaliteta, posebno kada neuspeh nosi visok poslovni ili misijski uticaj.\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\">Treba li obrisati stari ADR kada se arhitektura promeni?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Obično ne. Odluka o zameni treba normalno da zameni stari zapis kako bi istorijsko obrazloženje ostalo sledljivo.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-76\">Pojmovnik\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\">Osnovni arhitektonski pojmovi\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\">Nefunkcionalni zahtev: praktična skraćenica za zahtevani kvalitet sistema, ograničenje ili uslov rada; tačna terminologija varira u zavisnosti od metode i standarda.\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\">Zahtev za atributom kvaliteta\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Zahtev koji opisuje svojstvo kvaliteta koje se očekuje da sistem ispolji pod definisanim uslovima, kao što su performanse, dostupnost, bezbednost, pouzdanost ili mogućnost izmene.\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\">Zapis arhitektonske odluke (ADR)\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Trajni zapis arhitektonski značajne odluke i dovoljno konteksta da se razume zašto je izbor napravljen i koje posledice slede.\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\">Arhitektonski značajan zahtev (ASR)\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Zahtev sa dovoljno dalekosežnim arhitektonskim uticajem da materijalno utiče na dizajn 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\">Ograničenje\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Uslov koji ograničava prostor rešenja, uključujući spoljnu politiku, regulativu, platformu, kompatibilnost, ugovorne ili organizacione granice.\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\">Kompromis\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Dizajnerski odnos u kojem poboljšanje jednog cilja, svojstva ili dimenzije troška može pogoršati drugi.\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\">Validacija\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Rad koji proizvodi dokaze i koristi se za utvrđivanje da li implementirani sistem zadovoljava navedeni zahtev pod relevantnim uslovima.\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\">Zamenjeni ADR\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Istorijski zapis odluke koji je zamenjen novijom autoritativnom odlukom, ali ostaje dostupan radi sledljivosti.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-78\">Primarni izvori i dokazi o implementaciji\u003C\u002Fh2>\n\u003Cp>Ovaj članak razdvaja aktuelne standarde od dokaza o implementaciji projekta. ISO\u002FIEC\u002FIEEE 29148:2018 je aktuelan zaključno sa 8. oktobrom 2026, ali je označen za reviziju; ISO\u002FIEC 25010:2023 i ISO\u002FIEC\u002FIEEE 42010:2022 su aktuelna objavljena izdanja. SenseFlow je originalni dokaz projekta za model sledljivosti i integriteta odluka opisan gore.\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 — Inženjering zahteva\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Aktuelni objavljeni standard za inženjering zahteva. ISO navodi da je izdanje iz 2018. pregledano i potvrđeno 2024. i da se očekuje da će biti zamenjeno DIS-om koji je trenutno u razvoju.\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 — Inženjering zahteva\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Nacrt međunarodnog standarda koji je trenutno u razvoju i namenjen da zameni 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 — Model kvaliteta proizvoda\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Aktuelni model kvaliteta proizvoda sa devet karakteristika kvaliteta koji se koristi za specifikaciju, merenje i evaluaciju kvaliteta IKT i softverskih proizvoda.\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 — Opis arhitekture\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Aktuelni standard za opis arhitekture. On specificira koncepte opisa arhitekture i zahteve usaglašenosti bez propisivanja jednog formata za beleženje, notacije, procesa ili alata.\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 — Dokumentovanje arhitektonskih odluka\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Originalni uticajni članak o ADR-u koji opisuje lagane zapise usredsređene na kontekst, odluku, status i posledice, sa zamenjenim odlukama koje se čuvaju radi istorijskog razumevanja.\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 — Povezivanje poslovnih ciljeva sa arhitektonski značajnim zahtevima\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">SEI izveštaj koji objašnjava kako zahtevi za atributima kvaliteta i poslovni ciljevi pokreću softversku arhitekturu i zašto arhitektonski značajni zahtevi zahtevaju eksplicitno izvođenje.\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 — Definisanje nefunkcionalnih kvaliteta sistema\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">SEI pregled koji povezuje nefunkcionalne atribute kvaliteta sa arhitekturom, scenarijima, kompromisima i objektivnom evaluacijom 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 — Kolekcija metoda dizajna vođenog atributima\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Metod dizajna arhitekture zasnovan na funkcionalnim zahtevima, zahtevima za atributima kvaliteta i ograničenjima, sa arhitektonskim taktikama i obrascima izabranim da zadovolje scenarije kvaliteta.\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 — Kolekcija pogleda i šire\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Smernice za arhitektonsku dokumentaciju koje naglašavaju relevantne poglede i beleženje neophodnih dizajnerskih odluka kao deo arhitektonskog rada.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1031},1791476079847,[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,828,832,836,840,844,848,852,856,860,864,868,872,876,880,913,917,949,953,957,967,975,983,991,999,1007,1015,1023],{"id":215,"data":216,"type":218},"intro",{"text":217},"\u003Cstrong>Nefunkcionalni zahtev (NFR)\u003C\u002Fstrong> opisuje kvalitet, ograničenje ili uslov rada koji sistem treba da zadovolji. \u003Cstrong>Zapis arhitektonske odluke (ADR)\u003C\u002Fstrong> beleži arhitektonski značajan izbor donet kao odgovor na zahteve, ograničenja, rizike i kompromise. Oni su povezani, ali nisu zamenljivi: NFR navodi šta mora biti istinito; ADR objašnjava šta je odlučeno, zašto i sa kakvim posledicama.","paragraph",{"id":220,"data":221,"type":225},"direct",{"body":222,"title":223,"variant":224},"\u003Cstrong>NFR = zahtevani kvalitet ili ograničenje sistema. ADR = zabeležena arhitektonska odluka.\u003C\u002Fstrong> Ciljna latencija, cilj dostupnosti, pravilo izolacije, ograničenje implementacije ili zahtev za održivost mogu uticati na arhitekturu. ADR zatim beleži značajan izbor donet da se reši jedan ili više takvih pokretača. ADR ne zamenjuje zahtev, a postojanje ADR-a ne dokazuje da je zahtev zadovoljen.","Direktan odgovor","info","callout",{"id":227,"data":228,"type":225},"version-note",{"body":229,"title":230,"variant":231},"Termin \u003Cstrong>NFR\u003C\u002Fstrong> je široko korišćen, ali nije savršeno standardizovan. Ovaj članak ga koristi kao praktičnu skraćenicu za zahteve kvaliteta i relevantna ograničenja. Aktuelni standardi su ponovo provereni \u003Cstrong>8. oktobra 2026.\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 je i dalje aktuelan, ali je u reviziji; ISO\u002FIEC 25010:2023 i ISO\u002FIEC\u002FIEEE 42010:2022 su aktuelna objavljena izdanja citirana ovde.","Napomena o terminologiji i standardima","note",{"id":233,"data":234,"type":238},"toc",{"title":235,"maxLevel":236,"minLevel":237},"Sadržaj",3,2,"tableOfContents",{"id":240,"data":241,"type":42},"h-meaning",{"text":242,"level":237},"Koja je razlika između NFR-a i ADR-a?",{"id":244,"data":245,"type":218},"p-meaning-1",{"text":246},"Najjednostavnija razlika je gramatička. Zahtev opisuje uslov koji sistem mora da zadovolji. Zapis odluke opisuje izbor koji je tim napravio.",{"id":248,"data":249,"type":218},"p-meaning-2",{"text":250},"Na primer, \u003Cstrong>„API mora da vrati 95% zahteva za čitanje u roku od 300 ms pod dogovorenim referentnim opterećenjem“\u003C\u002Fstrong> je zahtev kvaliteta. \u003Cstrong>„Koristiti keš za čitanje za ovo opterećenje jer izmerena putanja samo preko baze podataka ne može da ispuni ciljnu latenciju bez neprihvatljivih troškova“\u003C\u002Fstrong> je arhitektonska odluka.",{"id":252,"data":253,"type":218},"p-meaning-3",{"text":254},"Prva izjava ostaje važeća čak i ako se implementacija promeni. Druga izjava može kasnije biti zamenjena drugom odlukom ako se opterećenje, tehnologija, model troškova ili dokazi promene.",{"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","Primarno pitanje",{"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","Tipičan sadržaj",{"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","Uloga u životnom ciklusu",{"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","Šta ga dokazuje?",{"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","Kada se menja",{"adr":287,"nfr":288},"When the decision is replaced, rejected, deprecated, or superseded","When stakeholder need, operating conditions, policy or quality target changes","NFR i ADR odgovaraju na različita pitanja","table",[292,295],{"id":293,"label":294},"nfr","NFR \u002F zahtev kvaliteta",{"id":296,"label":297},"adr","ADR \u002F arhitektonska odluka","comparison",{"id":300,"data":301,"type":42},"h-nfr",{"text":302,"level":237},"Šta je NFR u preciznim arhitektonskim terminima?",{"id":304,"data":305,"type":218},"p-nfr-1",{"text":306},"„Nefunkcionalni zahtev“ je zgodna industrijska oznaka, ali može da sakrije nekoliko različitih vrsta izjava. U arhitektonskom radu, korisna razlika je između \u003Cstrong>funkcionalnog ponašanja\u003C\u002Fstrong>, \u003Cstrong>zahteva kvaliteta\u003C\u002Fstrong> i \u003Cstrong>ograničenja\u003C\u002Fstrong>.",{"id":308,"data":309,"type":218},"p-nfr-2",{"text":310},"ISO\u002FIEC 25010:2023 pruža model kvaliteta proizvoda sa devet karakteristika i potkategorija koje se mogu koristiti pri specifikaciji i evaluaciji kvaliteta IKT i softverskih proizvoda. SEI arhitektonski rad na sličan način tretira zahteve atributa kvaliteta kao glavne pokretače softverske arhitekture.",{"id":312,"data":313,"type":218},"p-nfr-3",{"text":314},"Koristan NFR stoga nije „sistem treba da bude brz“ ili „platforma mora da bude bezbedna.“ Te izjave imenuju aspiracije. Zahtev koji pokreće arhitekturu treba da učini očekivano svojstvo dovoljno proverljivim da se projektne alternative i kasniji dokazi mogu evaluirati u odnosu na njega.",{"id":316,"data":317,"type":290},"nfr-examples",{"content":318,"stretched":43,"withHeadings":14},[319,323,327,331,335,339],[320,321,322],"Slaba izjava","Korisniji oblik zahteva","Zašto je razlika važna",[324,325,326],"API mora da bude brz","Za opterećenje W, 95% operacije X završava se u roku od T milisekundi","Definiše opterećenje, operaciju, metriku i prag",[328,329,330],"Servis mora da bude dostupan","Servis S ispunjava dogovoreni cilj dostupnosti tokom perioda merenja M, isključujući eksplicitno definisane uslove održavanja","Čini dostupnost merljivom i definiše obim",[332,333,334],"Podaci zakupaca moraju da budu bezbedni","Zahtev autentifikovan za zakupca A nikada ne sme da preuzme ili izmeni podatke zakupca B kroz podržane aplikativne putanje","Pretvara nejasan bezbednosni cilj u svojstvo izolacije",[336,337,338],"Sistem treba da se skalira","Sistem podržava opterećenje W pri konkurentnosti C dok ispunjava pragove latencije i stope grešaka","Povezuje skaliranje sa merljivim ponašanjem servisa",[340,341,342],"Potreban nam je PostgreSQL","Nije sam po sebi NFR; prvo navedite zahtevane kvalitete perzistencije ili spoljno ograničenje","Izbor tehnologije je obično rešenje, a ne zahtev koji treba da zadovolji",{"id":344,"data":345,"type":225},"nfr-rule",{"body":346,"title":347,"variant":348},"Ako se „koristi Kubernetes“, „koristi PostgreSQL“, „koristi mikroservise“ ili „koristi vektorsku pretragu“ pojavljuje kao zahtev, pitajte da li je to zaista spoljno ograničenje ili je rešenje zapisano pre nego što je osnovna potreba za kvalitetom eksplicitno izražena.","Zahtev treba da opiše potrebu pre mehanizma","success",{"id":350,"data":351,"type":42},"h-adr",{"text":352,"level":237},"Šta je zapis arhitektonske odluke?",{"id":354,"data":355,"type":218},"p-adr-1",{"text":356},"Zapis arhitektonske odluke je sažet zapis važne arhitektonske odluke. Originalna ADR formulacija Michaela Nygarda naglašava \u003Cstrong>kontekst\u003C\u002Fstrong>, \u003Cstrong>odluku\u003C\u002Fstrong>, njen \u003Cstrong>status\u003C\u002Fstrong> i rezultujuće \u003Cstrong>posledice\u003C\u002Fstrong>.",{"id":358,"data":359,"type":218},"p-adr-2",{"text":360},"Važan objekat je odluka, a ne šablon. Različiti timovi koriste različite ADR formate. Bogatiji zapis može takođe da sačuva alternative, kriterijume odlučivanja, kompromise, dokaze, veze ka zahtevima i datum ili verziju od koje se odluka primenjuje.",{"id":362,"data":363,"type":218},"p-adr-3",{"text":364},"ISO\u002FIEC\u002FIEEE 42010:2022 je širi od prakse ADR-a: specificira zahteve za opise arhitekture i njihove koncepte, dok eksplicitno ne propisuje jedan proces, notaciju, alat, format ili medijum za beleženje opisa arhitekture. ADR je stoga praktična tehnika beleženja odluka, a ne format koji zahteva 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],"ADR polje","Šta čuva","Zašto je važno",[374,375,376],"Kontekst","Problem, sile, zahtevi, pretpostavke i okruženje koje okružuje izbor","Budući čitaoci mogu da rekonstruišu zašto je izbor bio neophodan",[378,379,380],"Odluka","Izbor koji je postao merodavan","Razdvaja izabranu opciju od diskusije",[382,383,384],"Status","Predloženo, prihvaćeno, odbijeno, zastarelo, zamenjeno ili drugo kontrolisano stanje","Sprječava da stare odluke tiho ostanu aktivne",[386,387,388],"Alternative","Druge održive opcije koje su razmatrane","Pokazuje da izabrano rešenje nije bilo jedino zamislivo",[390,391,392],"Obrazloženje \u002F kompromisi","Zašto je opcija izabrana i čega se odriče","Čini arhitektonsko rezonovanje proverljivim",[394,395,396],"Posledice","Očekivani pozitivni i negativni efekti, naknadni rad, rizici","Povezuje lokalni izbor sa uticajem na sistem",[398,399,400],"Datum \u002F verzija","Kada je odluka postala važeća","Podržava istorijsku sledljivost i kasnije zamene",{"id":402,"data":403,"type":42},"h-simple-example",{"text":404,"level":237},"Najjednostavniji primer: zahtev za latenciju → arhitektonska odluka",{"id":406,"data":407,"type":218},"p-simple-1",{"text":408},"Pretpostavimo da se vlasnik proizvoda i inženjerski tim slažu da krajnja tačka za pretragu mora da vrati prvu stranicu rezultata u roku od 400 ms na 95. percentilu pod definisanim referentnim opterećenjem.",{"id":410,"data":411,"type":218},"p-simple-2",{"text":412},"Taj cilj nije ADR. To je zahtev za kvalitet. Arhitektonski rad počinje pitanjem koji dizajn može da ga zadovolji pod ostalim ograničenjima 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. Navedite zahtev","Definišite cilj kvaliteta, opterećenje, obim, prag i metod validacije.",{"label":421,"description":422},"2. Identifikujte arhitektonski značaj","Utvrdite da li zahtev materijalno utiče na strukturu, tehnologiju, raspoređivanje, tok podataka ili operativni model.",{"label":424,"description":425},"3. Procenite opcije","Uporedite alternative kao što su indeksiranje, keširanje, denormalizacija, asinhroni rad, particionisanje ili druga arhitektura upita.",{"label":427,"description":428},"4. Zabeležite odluku","Zabeležite izabrani arhitektonski izbor, obrazloženje, alternative, kompromise, status i posledice u ADR-u.",{"label":430,"description":431},"5. Implementirajte","Pretvorite odluku u kod, infrastrukturu, konfiguraciju i operativno ponašanje.",{"label":433,"description":434},"6. Validirajte","Izmerite stvarni sistem u odnosu na prvobitni zahtev. Rezultat testa validira NFR; sam ADR to ne čini.","Od zahteva do dokaza","auto","processFlow",{"id":439,"data":440,"type":225},"simple-stop",{"body":441,"title":442,"variant":443},"Stvarni sistemi retko imaju jedan zahtev i jednu odluku. Performanse se mogu menjati u odnosu na troškove, konzistentnost, operabilnost, bezbednost, održivost, potrošnju energije ili rizik isporuke. Koristan model je stoga graf sledljivosti, a ne jedan-na-jedan mapiranje.","Gde se jednostavan primer zaustavlja","warning",{"id":445,"data":446,"type":42},"h-many-many",{"text":447,"level":237},"NFR-ovi i ADR-ovi obično imaju odnos više-na-više",{"id":449,"data":450,"type":218},"p-many-1",{"text":451},"Jedan zahtev za kvalitet može da pokrene nekoliko arhitektonskih odluka. Zahtev za izolaciju zakupaca, na primer, može da utiče na propagaciju identiteta, opseg baze podataka, dizajn pozadinskih poslova, ključeve keša, evidentiranje revizije i administrativne alate.",{"id":453,"data":454,"type":218},"p-many-2",{"text":455},"Jedna arhitektonska odluka takođe može da odgovori na nekoliko zahteva istovremeno. Izbor asinhrone granice obrade može da poboljša responzivnost i izolaciju otkaza, dok uvodi kompromise u konzistentnosti, složenosti, nadzirljivosti i operativnosti.",{"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","Jedan NFR → mnogo ADR-ova",{"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","Mnogo NFR-ova → jedan 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 bez klasičnog NFR-a",{"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","Zahtev stabilan, ADR se menja",{"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","Zašto odnos nije jedan-na-jedan",[490,492,494],{"id":293,"label":491},"Strana zahteva",{"id":296,"label":493},"Strana odluke",{"id":495,"label":496},"validation","Strana validacije",{"id":498,"data":499,"type":42},"h-technology",{"text":500,"level":237},"Izbor tehnologije nije automatski zahtev",{"id":502,"data":503,"type":218},"p-tech-1",{"text":504},"Česta arhitektonska greška je da se preferirana tehnologija upiše u sloj zahteva i da se onda rezultujući dizajn tretira kao neizbežan.",{"id":506,"data":507,"type":218},"p-tech-2",{"text":508},"„Sistem mora da koristi PostgreSQL“ može biti legitimno ograničenje ako ugovor, politika platforme, zahtev kompatibilnosti, pravilo licenciranja, organizacioni standard ili postojeća operativna granica zaista nalažu PostgreSQL. Ali ako je stvarna potreba transakciona konzistentnost, strukturisano upitavanje, operativna upoznatost ili specifičan cilj oporavka, zahtev treba da navede tu potrebu, a izbor tehnologije treba zabeležiti kao odluku.",{"id":510,"data":511,"type":290},"tech-table",{"content":512,"stretched":43,"withHeadings":14},[513,517,521,525,529,533,537],[514,515,516],"Izjava","Klasifikacija","Razlog",[518,519,520],"Sva čitanja u opsegu zakupca moraju da sprovedu izolaciju zakupaca","Zahtev \u002F bezbednosno svojstvo","Opisuje svojstvo koje mora da važi",[522,523,524],"Koristite PostgreSQL Row Level Security za izabrane tabele u opsegu zakupca","Arhitektonska odluka","Bira mehanizam namenjen da pomogne u zadovoljavanju svojstva izolacije",[526,527,528],"Ciljno okruženje za raspoređivanje mora da radi u odobrenom okruženju kojim upravlja EU","Ograničenje \u002F operativni uslov sličan NFR-u","Ograničava gde sistem može da radi",[530,531,532],"Koristite provajdera X u regionu Y","Arhitektonska \u002F odluka o raspoređivanju osim ako nije spolja propisana","Bira određeno rešenje unutar dozvoljene granice",[534,535,536],"Latencija API-ja na 95. percentilu ≤ 300 ms pod opterećenjem W","Zahtev za kvalitet","Definiše merljivo ponašanje performansi",[538,523,539],"Uvedite keš za krajnju tačku X","Bira taktiku namenjenu da poboljša merljivo ponašanje",{"id":541,"data":542,"type":42},"h-adr-proof",{"text":543,"level":237},"ADR nije dokaz da je NFR zadovoljen",{"id":545,"data":546,"type":218},"p-proof-1",{"text":547},"Dokumentacija odluka i validacija sistema odgovaraju na različita pitanja. ADR može da pokaže da su performanse, bezbednost, otpornost ili održivost razmatrani. Ne može sam po sebi da dokaže da isporučeni sistem zaista postiže ta svojstva.",{"id":549,"data":550,"type":218},"p-proof-2",{"text":551},"Dokaz mora da dođe iz metoda validacije koji odgovara zahtevu: benchmark, test opterećenja, test otkaza, bezbednosni test, arhitektonska analiza, revizija, inspekcija, operativna telemetrija, vežba oporavka, studija korisnika ili drugi oblik dokaza.",{"id":553,"data":554,"type":225},"proof-rule",{"body":555,"title":556,"variant":443},"\u003Cstrong>ADR:\u003C\u002Fstrong> „Izabrali smo dizajn X jer se očekuje da zadovolji zahtev R pod pretpostavkama A.“\u003Cbr>\u003Cstrong>Validacija:\u003C\u002Fstrong> „Izmereni ili analizirani dokaz E pokazuje da li implementirani sistem zaista zadovoljava R.“","Ne mešajte nameru sa dokazom",{"id":558,"data":559,"type":42},"h-asr",{"text":560,"level":237},"Kada nefunkcionalni zahtev postaje arhitektonski značajan?",{"id":562,"data":563,"type":218},"p-asr-1",{"text":564},"Nije svaki nefunkcionalni zahtev vredan arhitektonske odluke. Važan podskup čine zahtevi koji suštinski oblikuju arhitekturu ili nameću kompromise kroz sistem.",{"id":566,"data":567,"type":218},"p-asr-2",{"text":568},"SEI literatura koristi koncept \u003Cstrong>arhitektonski značajnih zahteva\u003C\u002Fstrong> za zahteve sa dalekosežnim arhitektonskim efektom. Atributi kvaliteta kao što su performanse, pouzdanost, bezbednost i modifikabilnost česti su izvori takvih pokretača, naročito kada nose visoku poslovnu ili misijsku vrednost.",{"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. Pitajte da li zahtev menja strukturu","Da li bi različite vrednosti nametnule različite komponente, granice, tokove podataka ili topologiju postavljanja?",{"label":577,"description":578},"2. Pitajte da li ograničava glavne tehnološke izbore","Da li eliminiše inače održive opcije implementacije?",{"label":580,"description":581},"3. Pitajte da li stvara ponašanje koje seče kroz slojeve","Da li utiče na mnoge komponente, timove, interfejse ili faze životnog ciklusa?",{"label":583,"description":584},"4. Pitajte da li stvara težak kompromis","Da li poboljšanje ovog svojstva materijalno utiče na drugi kvalitet, trošak, raspored, složenost ili rizik?",{"label":586,"description":587},"5. Pitajte da li je neuspeh skup","Da li bi propuštanje zahteva stvorilo materijalni operativni, bezbednosni, regulatorni, finansijski ili produktni uticaj?",{"label":589,"description":590},"6. Beležite odluke samo tamo gde je obrazloženje vredno čuvanja","Ne pravite ADR za svaki lokalni izbor kodiranja; čuvajte arhitektonski značajne odluke i njihovo obrazloženje.","Test arhitektonske značajnosti",{"id":593,"data":594,"type":42},"h-traceability",{"text":595,"level":237},"Jači arhitektonski model: zahtev → odluka → implementacija → validacija",{"id":597,"data":598,"type":218},"p-trace-1",{"text":599},"Najkorisnija veza između NFR-ova i ADR-ova je sledljivost. Zahtev treba da može da ukaže na arhitektonske odluke koje ga rešavaju; ADR treba da identifikuje pokretače na koje odgovara; implementacioni rad treba da realizuje odluku; validacija treba da se vrati na originalni zahtev.",{"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},"Potreba \u002F poslovni cilj","Zašto su kvalitet ili ograničenje važni.",{"label":608,"description":609},"Zahtev \u002F NFR","Šta sistem mora da postigne ili poštuje.",{"label":611,"description":612},"Arhitektonski pokretači","Koji su zahtevi dovoljno značajni da oblikuju dizajn.",{"label":614,"description":615},"Opcije","Verodostojni načini da se adresira pokretač.",{"label":617,"description":618},"ADR","Izabrani izbor, obrazloženje, alternative, kompromisi i posledice.",{"label":620,"description":621},"Implementacija","Kod, model podataka, infrastruktura, interfejsi i operativni mehanizmi koji realizuju odluku.",{"label":623,"description":624},"Dokaz validacije","Testovi, merenja, analize ili revizije koje pokazuju da li je originalni zahtev zaista zadovoljen.",{"label":626,"description":627},"Promena \u002F zamena","Novi dokazi ili promenjeni zahtevi mogu pokrenuti novi ADR uz očuvanje istorijskog obrazloženja.","Lanac arhitektonske sledljivosti",{"id":630,"data":631,"type":42},"h-senseflow",{"text":632,"level":237},"Implementacioni dokaz: kako razdvajam zahteve i odluke u SenseFlow-u",{"id":634,"data":635,"type":225},"senseflow-evidence",{"body":636,"title":637,"variant":231},"Sledeći odeljak opisuje strukturu mog sopstvenog SenseFlow projekta. To je implementacioni dokaz za razdvajanje u ovom članku, a ne tvrdnja da svaki tim mora da koristi isti model dokumentacije.","Originalna implementacija \u002F dokaz projekta",{"id":639,"data":640,"type":218},"p-sense-1",{"text":641},"U SenseFlow-u, projektni Izvor istine eksplicitno smešta nefunkcionalne zahteve unutar strukture zahteva zajedno sa zavisnostima, rizicima, pretpostavkama, kriterijumima prihvatanja i metodom validacije. Model dokumentacije odvojeno definiše integritet odluka za značajne odluke.",{"id":643,"data":644,"type":218},"p-sense-2",{"text":645},"Za značajne SenseFlow odluke, evidentirana polja su \u003Cstrong>Odluka, Razlog, Alternative, Kompromisi, Status i Datum \u002F Verzija\u003C\u002Fstrong>. Glavne arhitektonske i produktne odluke treba da ostanu istorijski sledljive umesto da budu prepisane kada projekat evoluira.",{"id":647,"data":648,"type":218},"p-sense-3",{"text":649},"SenseFlow takođe dodeljuje različite operativne uloge Confluence-u i Jira-i. Confluence je strukturisano okruženje znanja i odluka; Jira upravlja izvršnim radom na isporuci. Glavni Jira Epics treba da se povezuju nazad na relevantnu produktnu ili zahtevnu dokumentaciju. To čuva lanac od produktne namere kroz zahteve i odluke do implementacije, umesto da backlog pretvara u arhitektonski Izvor istine.",{"id":651,"data":652,"type":290},"senseflow-table",{"content":653,"stretched":43,"withHeadings":14},[654,658,662,666,670,674,678],[655,656,657],"SenseFlow sloj","Šta sadrži","Uloga u razdvajanju ADR\u002FNFR",[659,660,661],"Produktna \u002F zahtevna struktura","Produktni cilj, sposobnost, epic, korisnička priča, kriterijumi prihvatanja, tehnički zadaci; zahtevi mogu uključivati NFR-ove i metod validacije","Čuva šta treba postići i kako će se uspeh proveravati",[663,664,665],"Integritet odluka","Odluka, razlog, alternative, kompromisi, status, datum\u002Fverzija","Čuva zašto je arhitektonski značajan izbor postao autoritativan",[667,668,669],"Confluence","Zahtevi, arhitektura, istraživanje, zapisi odluka, rizici, mapa puta i prateći izvori","Održava konceptualni i istorijski Izvor istine",[671,672,673],"Jira","Inicijative\u002Fciljevi, epici, priče, zadaci i stanje isporuke","Izvršava odobreni rad bez postajanja konceptualnog Izvora istine",[675,676,677],"Upravljanje promenama","Trenutno stanje → novi dokaz → predložena promena → uticaj → odluka","Omogućava odlukama da evoluiraju bez brisanja traga obrazloženja",[679,680,681],"Sledljivost od početka do kraja","Problem → potreba → vrednost → produktni cilj → zahtev → implementacija → validacija","Održava dokumentaciju odluka povezanom sa stvarnim produktom i životnim ciklusom dokaza",{"id":683,"data":684,"type":225},"senseflow-lesson",{"body":685,"title":686,"variant":348},"Zahtev i odluka mogu živeti blizu jedno drugom, a da ne budu spojeni u jedan zapis. Zahtev ostaje cilj; odluka ostaje istorija obrazloženja; rad na isporuci implementira odluku; validacija se vraća na cilj.","Šta ova implementacija pokazuje",{"id":688,"data":689,"type":42},"h-enterprise",{"text":690,"level":237},"Kontekst enterprise projekta: zahtevi treba da prethode arhitektonskim izborima",{"id":692,"data":693,"type":218},"p-enterprise-1",{"text":694},"Isto razdvajanje je korisno u projektnom radu orijentisanom na enterprise. Arhitektonske odluke donete pre nego što su zahtevi, rizici, ograničenja i uslovi prihvatanja dovoljno razumljeni mogu pretvoriti preferencije u lažne neophodnosti.",{"id":696,"data":697,"type":218},"p-enterprise-2",{"text":698},"Za Enterprise Aaasaasa 0.1, relevantna lekcija je metodološka, a ne tvrdnja o jednom konkretnom ADR-u: zahtevi, arhitektura, validacija, prekretnice, upravljanje rizicima i prihvatanje pripadaju povezanom sistemu isporuke. Arhitektonski izbor treba da ostane sledljiv do zahteva ili ograničenja koje treba da adresira.",{"id":700,"data":701,"type":42},"h-failures",{"text":702,"level":237},"Uobičajeni obrasci neuspeha kada se ADR i NFR mešaju",{"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],"Obrazac neuspeha","Šta se dešava","Posledica",[712,713,714],"Tehnologija prerušena u zahtev","Preferirano rešenje je napisano kao „mora se koristiti X“ bez utvrđivanja osnovne potrebe","Alternative se nikada ne evaluiraju i arhitektura postaje prerano fiksirana",[716,717,718],"NFR skriven samo unutar ADR-a","Odluka pominje cilj performansi\u002Fbezbednosti koji nije prisutan u osnovi zahteva","Cilj je teško validirati, prioritizovati ili upravljati njime nezavisno",[720,721,722],"ADR tretiran kao dokaz","Pretpostavlja se da dokumentovani izbor znači da je zahtev zadovoljen","Arhitektonska namera zamenjuje merenje ili verifikaciju",[724,725,726],"Nejasan NFR","Reči poput brz, skalabilan, bezbedan ili održiv nemaju merljiv obim","Različiti akteri mogu verovati da isti zahtev znači različite stvari",[728,729,730],"Nema evidentiranih alternativa","Tim evidentira samo izabranu tehnologiju","Budući održavaoci ne mogu rekonstruisati zašto je druga opcija odbijena",[732,733,734],"Nema modela zamene","Stari ADR-ovi se menjaju ili brišu kada se arhitektura promeni","Istorijsko rezonovanje nestaje i zastarele odluke mogu ostati dvosmislene",[736,737,738],"Svaki detalj implementacije postaje ADR","Repozitorijum se puni zapisima male vrednosti","Važne arhitektonske odluke postaju teške za pronalaženje",[740,741,742],"Backlog postaje izvor istine arhitekture","Jira zadaci se tretiraju kao jedino objašnjenje sistema","Stanje isporuke preživljava, ali arhitektonsko obrazloženje i pokretači kvaliteta se gube",{"id":744,"data":745,"type":42},"h-decision-framework",{"text":746,"level":237},"ADR–NFR okvir za odlučivanje",{"id":748,"data":749,"type":218},"p-framework-1",{"text":750},"Kada tim naiđe na novu arhitektonsku brigu, sledeći redosled pomaže da se utvrdi šta pripada zahtevima, šta pripada ADR-u, a šta pripada dokazima.",{"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. Da li je ovo obavezno svojstvo ili spoljno ograničenje?","Ako jeste, napišite ili navedite zahtev pre izbora mehanizma.",{"label":759,"description":760},"2. Može li se validirati?","Definišite obim, uslov, metriku, pravilo prihvatanja, metod analize ili druge potrebne dokaze.",{"label":762,"description":763},"3. Da li je arhitektonski značajno?","Utvrdite da li zahtev materijalno oblikuje strukturu, tehnologiju, podatke, raspoređivanje ili unakrsne kompromise.",{"label":765,"description":766},"4. Postoje li smislene alternative?","Uporedite održive taktike ili arhitektonske opcije umesto direktnog prelaska na preferiranu tehnologiju.",{"label":768,"description":769},"5. Da li je izbor postao autoritativan?","Kreirajte ili ažurirajte ADR sa kontekstom, odlukom, obrazloženjem, alternativama, kompromisima, statusom i posledicama.",{"label":771,"description":772},"6. Da li je odluka implementirana?","Pratite ADR kroz dizajn, zadatke, kod, konfiguraciju i operacije.",{"label":774,"description":775},"7. Da li je zahtev zadovoljen?","Prikupite dokaze validacije u odnosu na sam zahtev.",{"label":777,"description":778},"8. Da li su se uslovi promenili?","Ponovo procenite zahtev i, kada je potrebno, zamenite ADR bez brisanja istorije.","ADR–NFR test klasifikacije",{"id":781,"data":782,"type":42},"h-what-not",{"text":783,"level":237},"Šta ADR i NFR nisu",{"id":785,"data":786,"type":298},"not-comparison",{"rows":787,"title":818,"layout":290,"columns":819},[788,793,798,804,811],{"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":623,"values":800},"test",{"not":801,"why":802,"term":803},"The ADR itself","Documented intent is different from measured or analyzed system behavior","Evidence that checks whether a requirement is satisfied",{"id":805,"label":806,"values":807},"backlog","Stavka backlog-a",{"not":808,"why":809,"term":810},"A durable substitute for architecture rationale","Task state answers what is being delivered, not necessarily why the architecture exists","Actionable delivery work",{"id":812,"label":813,"values":814},"constraint","Ograničenje",{"not":815,"why":816,"term":817},"Always an internally chosen architecture decision","Some constraints come from regulation, contracts, existing platforms or organizational boundaries","A condition that restricts the solution space","Uobičajene greške u kategorizaciji",[820,823,826],{"id":821,"label":822},"term","Koncept",{"id":824,"label":825},"not","Nije",{"id":827,"label":516},"why",{"id":829,"data":830,"type":42},"h-change",{"text":831,"level":237},"Šta bi promenilo ovaj odgovor?",{"id":833,"data":834,"type":218},"p-change-1",{"text":835},"Terminologija može evoluirati. ISO\u002FIEC\u002FIEEE 29148:2018 ostaje trenutni objavljeni standard za inženjering zahteva od 8. oktobra 2026, ali ISO navodi nacrt međunarodnog standarda koji ga namerava zameniti. Ako novo izdanje promeni relevantnu terminologiju ili smernice za zahteve, reference specifične za verziju u ovom članku treba ažurirati.",{"id":837,"data":838,"type":218},"p-change-2",{"text":839},"ADR šabloni takođe mogu evoluirati bez promene centralne razlike. Minimalni šablon Michaela Nygarda, MADR, šabloni specifični za organizaciju, alati za arhitektonsko znanje ili strukturisane baze odluka mogu svi evidentirati odluke. Trajno pitanje je da li zapis čuva dovoljno konteksta i obrazloženja da bi se razumeo arhitektonski značajan izbor.",{"id":841,"data":842,"type":218},"p-change-3",{"text":843},"Razlika bi se srušila samo ako bi organizacija namerno izabrala kombinovani artefakt koji čuva i podatke o zahtevu i podatke o odluci u jednom dokumentu. Čak i tada, semantičke uloge ostaju različite: jedno polje navodi potreban ishod ili ograničenje; drugo evidentira izabrani odgovor.",{"id":845,"data":846,"type":42},"h-limitations",{"text":847,"level":237},"Ograničenja",{"id":849,"data":850,"type":218},"p-limit-1",{"text":851},"Ovaj članak koristi \u003Cstrong>NFR\u003C\u002Fstrong> kao praktičnu skraćenicu. Neke inženjerske metode preferiraju termine kao što su zahtev za atributom kvaliteta, zahtev kvaliteta, kvalitet sistema, ograničenje, cilj na nivou usluge ili arhitektonski značajan zahtev. Ti termini nisu savršeno zamenljivi, i terminologija projekta treba da bude eksplicitna.",{"id":853,"data":854,"type":218},"p-limit-2",{"text":855},"Nije svaki zahtev moguće svesti na jedan numerički prag. Bezbednost, sigurnost, održivost, interoperabilnost, upotrebljivost, objašnjivost, prenosivost i upravljanje mogu zahtevati kombinacije scenarija, strukturnih pravila, analiza, procesnih kontrola i kvalitativnih dokaza. „Merljivo“ treba da znači dovoljno proverljivo za odluku, a ne veštački numeričko.",{"id":857,"data":858,"type":218},"p-limit-3",{"text":859},"Nije svaka arhitektonska odluka potreban formalni ADR. Trošak dokumentovanja treba da bude proporcionalan arhitektonskom značaju, dugovečnosti, neizvesnosti, složenosti kompromisa i trošku gubitka obrazloženja.",{"id":861,"data":862,"type":42},"h-conclusion",{"text":863,"level":237},"Zaključak",{"id":865,"data":866,"type":218},"p-conclusion-1",{"text":867},"ADR i NFR pripadaju različitim slojevima arhitektonskog rada. \u003Cstrong>NFR definiše cilj kvaliteta, ograničenje ili uslov rada. ADR evidentira značajan arhitektonski odgovor na jedan ili više pokretača.\u003C\u002Fstrong>",{"id":869,"data":870,"type":218},"p-conclusion-2",{"text":871},"Održavanje tih slojeva odvojenim čini arhitekturu lakšom za razmišljanje. Zahtevi se mogu validirati nezavisno od tehnologije. Odluke se mogu zameniti bez prepisivanja istorije. Alternative i kompromisi ostaju vidljivi. Rad na isporuci može se pratiti nazad do arhitektonske namere. Dokazi mogu pokazati da li rezultujući sistem zaista zadovoljava zahtev.",{"id":873,"data":874,"type":218},"p-conclusion-3",{"text":875},"Najjači lanac stoga nije „NFR → ADR → gotovo“. On je \u003Cstrong>potreba → zahtev → arhitektonski pokretači → opcije → odluka → implementacija → validacija → promena\u003C\u002Fstrong>. Taj lanac pretvara arhitektonsku dokumentaciju od statičke papirologije u proverljiv zapis o tome zašto sistem ima oblik koji ima.",{"id":877,"data":878,"type":42},"h-faq",{"text":879,"level":237},"Često postavljana pitanja",{"id":881,"data":882,"type":881},"faq",{"items":883,"title":912},[884,888,892,896,900,904,908],{"id":885,"answer":886,"question":887},"faq1","Ne. NFR navodi zahtevani kvalitet, ograničenje ili uslov rada. ADR beleži arhitektonski značajan izbor donet kao odgovor na zahteve, ograničenja, rizike i kompromise.","Da li je ADR nefunkcionalni zahtev?",{"id":889,"answer":890,"question":891},"faq2","Ne. Samo zahtevi koji materijalno utiču na arhitekturu zahtevaju odluke na nivou arhitekture koje vredi sačuvati. Jedan NFR može takođe da pokrene nekoliko ADR-ova, a jedan ADR može da odgovori na nekoliko zahteva.","Da li svaki NFR treba da ima ADR?",{"id":893,"answer":894,"question":895},"faq3","Samo kada je PostgreSQL zaista nametnut kao spoljno ograničenje. U suprotnom, osnovna potreba treba prvo da bude izražena, a izbor PostgreSQL-a treba normalno tretirati kao arhitektonsku odluku.","Može li „koristiti PostgreSQL“ biti NFR?",{"id":897,"answer":898,"question":899},"faq4","Ne. ADR beleži nameru i obrazloženje. Zahtev se validira kroz odgovarajuće dokaze kao što su testiranje, merenje, analiza, revizija ili operativna telemetrija.","Da li ADR dokazuje da je zahtev za performansama ili bezbednošću ispunjen?",{"id":901,"answer":902,"question":903},"faq5","U najmanju ruku, ADR treba da jasno prikaže kontekst i odluku. Uobičajene strukture takođe uključuju status i posledice. Timovi mogu dodati alternative, obrazloženje, kompromise, veze sa zahtevima, dokaze, vlasnike, datume i odnose zamene.","Šta treba da sadrži ADR?",{"id":905,"answer":906,"question":907},"faq6","Zahtev je arhitektonski značajan kada materijalno oblikuje strukturu sistema, tehnologiju, tokove podataka, raspoređivanje, sveobuhvatno ponašanje ili teške kompromise kvaliteta, posebno kada neuspeh nosi visok poslovni ili misijski uticaj.","Šta čini NFR arhitektonski značajnim?",{"id":909,"answer":910,"question":911},"faq7","Obično ne. Odluka o zameni treba normalno da zameni stari zapis kako bi istorijsko obrazloženje ostalo sledljivo.","Treba li obrisati stari ADR kada se arhitektura promeni?","ADR vs NFR",{"id":914,"data":915,"type":42},"h-glossary",{"text":916,"level":237},"Pojmovnik",{"id":918,"data":919,"type":918},"glossary",{"title":920,"entries":921},"Osnovni arhitektonski pojmovi",[922,925,929,932,936,938,942,945],{"term":923,"anchor":293,"definition":924},"NFR","Nefunkcionalni zahtev: praktična skraćenica za zahtevani kvalitet sistema, ograničenje ili uslov rada; tačna terminologija varira u zavisnosti od metode i standarda.",{"term":926,"anchor":927,"definition":928},"Zahtev za atributom kvaliteta","quality-attribute-requirement","Zahtev koji opisuje svojstvo kvaliteta koje se očekuje da sistem ispolji pod definisanim uslovima, kao što su performanse, dostupnost, bezbednost, pouzdanost ili mogućnost izmene.",{"term":930,"anchor":296,"definition":931},"Zapis arhitektonske odluke (ADR)","Trajni zapis arhitektonski značajne odluke i dovoljno konteksta da se razume zašto je izbor napravljen i koje posledice slede.",{"term":933,"anchor":934,"definition":935},"Arhitektonski značajan zahtev (ASR)","asr","Zahtev sa dovoljno dalekosežnim arhitektonskim uticajem da materijalno utiče na dizajn sistema.",{"term":813,"anchor":812,"definition":937},"Uslov koji ograničava prostor rešenja, uključujući spoljnu politiku, regulativu, platformu, kompatibilnost, ugovorne ili organizacione granice.",{"term":939,"anchor":940,"definition":941},"Kompromis","trade-off","Dizajnerski odnos u kojem poboljšanje jednog cilja, svojstva ili dimenzije troška može pogoršati drugi.",{"term":943,"anchor":495,"definition":944},"Validacija","Rad koji proizvodi dokaze i koristi se za utvrđivanje da li implementirani sistem zadovoljava navedeni zahtev pod relevantnim uslovima.",{"term":946,"anchor":947,"definition":948},"Zamenjeni ADR","superseded-adr","Istorijski zapis odluke koji je zamenjen novijom autoritativnom odlukom, ali ostaje dostupan radi sledljivosti.",{"id":950,"data":951,"type":42},"h-sources",{"text":952,"level":237},"Primarni izvori i dokazi o implementaciji",{"id":954,"data":955,"type":218},"p-sources-note",{"text":956},"Ovaj članak razdvaja aktuelne standarde od dokaza o implementaciji projekta. ISO\u002FIEC\u002FIEEE 29148:2018 je aktuelan zaključno sa 8. oktobrom 2026, ali je označen za reviziju; ISO\u002FIEC 25010:2023 i ISO\u002FIEC\u002FIEEE 42010:2022 su aktuelna objavljena izdanja. SenseFlow je originalni dokaz projekta za model sledljivosti i integriteta odluka opisan gore.",{"id":958,"data":959,"type":966},"src-iso-29148",{"link":960,"meta":961},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html",{"image":962,"title":964,"description":965},{"url":963},"","ISO\u002FIEC\u002FIEEE 29148:2018 — Inženjering zahteva","Aktuelni objavljeni standard za inženjering zahteva. ISO navodi da je izdanje iz 2018. pregledano i potvrđeno 2024. i da se očekuje da će biti zamenjeno DIS-om koji je trenutno u razvoju.","linkTool",{"id":968,"data":969,"type":966},"src-iso-29148-dis",{"link":970,"meta":971},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html",{"image":972,"title":973,"description":974},{"url":963},"ISO\u002FIEC\u002FIEEE DIS 29148 — Inženjering zahteva","Nacrt međunarodnog standarda koji je trenutno u razvoju i namenjen da zameni ISO\u002FIEC\u002FIEEE 29148:2018.",{"id":976,"data":977,"type":966},"src-iso-25010",{"link":978,"meta":979},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html",{"image":980,"title":981,"description":982},{"url":963},"ISO\u002FIEC 25010:2023 — Model kvaliteta proizvoda","Aktuelni model kvaliteta proizvoda sa devet karakteristika kvaliteta koji se koristi za specifikaciju, merenje i evaluaciju kvaliteta IKT i softverskih proizvoda.",{"id":984,"data":985,"type":966},"src-iso-42010",{"link":986,"meta":987},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":988,"title":989,"description":990},{"url":963},"ISO\u002FIEC\u002FIEEE 42010:2022 — Opis arhitekture","Aktuelni standard za opis arhitekture. On specificira koncepte opisa arhitekture i zahteve usaglašenosti bez propisivanja jednog formata za beleženje, notacije, procesa ili alata.",{"id":992,"data":993,"type":966},"src-nygard",{"link":994,"meta":995},"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions",{"image":996,"title":997,"description":998},{"url":963},"Michael Nygard — Dokumentovanje arhitektonskih odluka","Originalni uticajni članak o ADR-u koji opisuje lagane zapise usredsređene na kontekst, odluku, status i posledice, sa zamenjenim odlukama koje se čuvaju radi istorijskog razumevanja.",{"id":1000,"data":1001,"type":966},"src-sei-asr",{"link":1002,"meta":1003},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F",{"image":1004,"title":1005,"description":1006},{"url":963},"SEI — Povezivanje poslovnih ciljeva sa arhitektonski značajnim zahtevima","SEI izveštaj koji objašnjava kako zahtevi za atributima kvaliteta i poslovni ciljevi pokreću softversku arhitekturu i zašto arhitektonski značajni zahtevi zahtevaju eksplicitno izvođenje.",{"id":1008,"data":1009,"type":966},"src-sei-nfr",{"link":1010,"meta":1011},"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F",{"image":1012,"title":1013,"description":1014},{"url":963},"SEI — Definisanje nefunkcionalnih kvaliteta sistema","SEI pregled koji povezuje nefunkcionalne atribute kvaliteta sa arhitekturom, scenarijima, kompromisima i objektivnom evaluacijom sistema.",{"id":1016,"data":1017,"type":966},"src-sei-add",{"link":1018,"meta":1019},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F",{"image":1020,"title":1021,"description":1022},{"url":963},"SEI — Kolekcija metoda dizajna vođenog atributima","Metod dizajna arhitekture zasnovan na funkcionalnim zahtevima, zahtevima za atributima kvaliteta i ograničenjima, sa arhitektonskim taktikama i obrascima izabranim da zadovolje scenarije kvaliteta.",{"id":1024,"data":1025,"type":966},"src-sei-doc",{"link":1026,"meta":1027},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F",{"image":1028,"title":1029,"description":1030},{"url":963},"SEI — Kolekcija pogleda i šire","Smernice za arhitektonsku dokumentaciju koje naglašavaju relevantne poglede i beleženje neophodnih dizajnerskih odluka kao deo arhitektonskog rada.","2.31","ADR vs NFR objašnjeno: naučite kako zahtevi za kvalitet sistema pokreću arhitekturne odluke, kako ADR-ovi beleže kompromise i zašto validacija ostaje odvojena.","\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":1040,"de":1041,"sr":1042,"es":1043,"fr":1044,"it":1045,"ru":1046,"zh":1047},"\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",[1049,1053,1057,1061,1065],{"id":1050,"name":1051,"slug":1052},72,"Kriteriji prihvata","acceptance-criteria",{"id":1054,"name":1055,"slug":1056},67,"KPI i kriteriji prihvata","kpis",{"id":1058,"name":1059,"slug":1060},77,"Mjerenje i monitoring","measurement",{"id":1062,"name":1063,"slug":1064},76,"Budžeti performansi","budgets",{"id":1066,"name":1067,"slug":1068},68,"Rizici, kontrole i dokazi","risks-and-controls",{"id":1070,"login":1071,"email":1072,"displayName":1073},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1075,1717],{"lang":1076,"title":1077,"content":1078,"contentJson":1079,"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":1080,"blocks":1081,"version":1715},1791475659420,[1082,1085,1089,1093,1096,1099,1102,1105,1108,1132,1135,1138,1141,1144,1171,1175,1178,1181,1184,1187,1221,1224,1227,1230,1252,1256,1259,1262,1265,1288,1291,1294,1297,1327,1330,1333,1336,1340,1343,1346,1349,1371,1374,1377,1404,1407,1411,1414,1417,1420,1449,1453,1456,1459,1462,1465,1504,1507,1510,1538,1541,1563,1566,1569,1572,1575,1578,1581,1584,1587,1590,1593,1596,1599,1602,1626,1629,1655,1658,1661,1667,1673,1679,1685,1691,1697,1703,1709],{"id":215,"data":1083,"type":218},{"text":1084},"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":1086,"type":225},{"body":1087,"title":1088,"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":1090,"type":225},{"body":1091,"title":1092,"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":1094,"type":238},{"title":1095,"maxLevel":236,"minLevel":237},"Contents",{"id":240,"data":1097,"type":42},{"text":1098,"level":237},"What is the difference between an NFR and an ADR?",{"id":244,"data":1100,"type":218},{"text":1101},"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":1103,"type":218},{"text":1104},"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":1106,"type":218},{"text":1107},"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":1109,"type":298},{"rows":1110,"title":1126,"layout":290,"columns":1127},[1111,1114,1117,1120,1123],{"id":260,"label":1112,"values":1113},"Primary question",{"adr":263,"nfr":264},{"id":266,"label":1115,"values":1116},"Typical content",{"adr":269,"nfr":270},{"id":272,"label":1118,"values":1119},"Lifecycle role",{"adr":275,"nfr":276},{"id":278,"label":1121,"values":1122},"What proves it?",{"adr":281,"nfr":282},{"id":284,"label":1124,"values":1125},"When it changes",{"adr":287,"nfr":288},"NFR and ADR answer different questions",[1128,1130],{"id":293,"label":1129},"NFR \u002F quality requirement",{"id":296,"label":1131},"ADR \u002F architecture decision",{"id":300,"data":1133,"type":42},{"text":1134,"level":237},"What is an NFR in precise architectural terms?",{"id":304,"data":1136,"type":218},{"text":1137},"“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":1139,"type":218},{"text":1140},"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":1142,"type":218},{"text":1143},"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":1145,"type":290},{"content":1146,"stretched":43,"withHeadings":14},[1147,1151,1155,1159,1163,1167],[1148,1149,1150],"Weak statement","More useful requirement shape","Why the difference matters",[1152,1153,1154],"The API must be fast","For workload W, 95% of operation X completes within T milliseconds","Defines workload, operation, metric and threshold",[1156,1157,1158],"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",[1160,1161,1162],"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",[1164,1165,1166],"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",[1168,1169,1170],"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":1172,"type":225},{"body":1173,"title":1174,"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":1176,"type":42},{"text":1177,"level":237},"What is an Architecture Decision Record?",{"id":354,"data":1179,"type":218},{"text":1180},"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":1182,"type":218},{"text":1183},"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":1185,"type":218},{"text":1186},"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":1188,"type":290},{"content":1189,"stretched":43,"withHeadings":14},[1190,1194,1198,1202,1205,1209,1213,1217],[1191,1192,1193],"ADR field","What it preserves","Why it matters",[1195,1196,1197],"Context","The problem, forces, requirements, assumptions and environment surrounding the choice","Future readers can reconstruct why a choice was necessary",[1199,1200,1201],"Decision","The choice that became authoritative","Separates the selected option from discussion",[382,1203,1204],"Proposed, accepted, rejected, deprecated, superseded, or another controlled state","Prevents old decisions from silently remaining active",[1206,1207,1208],"Alternatives","Other viable options considered","Shows that the selected solution was not the only imaginable one",[1210,1211,1212],"Rationale \u002F trade-offs","Why the option was selected and what it gives up","Makes architecture reasoning inspectable",[1214,1215,1216],"Consequences","Expected positive and negative effects, follow-up work, risks","Connects a local choice to system impact",[1218,1219,1220],"Date \u002F version","When the decision became valid","Supports historical traceability and later supersession",{"id":402,"data":1222,"type":42},{"text":1223,"level":237},"The simplest example: latency requirement → architecture decision",{"id":406,"data":1225,"type":218},{"text":1226},"Suppose a product owner and engineering team agree that a search endpoint must return the first page of results within 400 ms at the 95th percentile under a defined reference workload.",{"id":410,"data":1228,"type":218},{"text":1229},"That target is not an ADR. It is a quality requirement. Architecture work begins by asking what design can satisfy it under the system’s other constraints.",{"id":414,"data":1231,"type":437},{"steps":1232,"title":1251,"orientation":436},[1233,1236,1239,1242,1245,1248],{"label":1234,"description":1235},"1. State the requirement","Define the quality target, workload, scope, threshold and validation method.",{"label":1237,"description":1238},"2. Identify architectural significance","Determine whether the requirement materially influences structure, technology, deployment, data flow or operating model.",{"label":1240,"description":1241},"3. Evaluate options","Compare alternatives such as indexing, caching, denormalization, asynchronous work, partitioning, or a different query architecture.",{"label":1243,"description":1244},"4. Record the decision","Capture the selected architecture choice, rationale, alternatives, trade-offs, status and consequences in an ADR.",{"label":1246,"description":1247},"5. Implement","Turn the decision into code, infrastructure, configuration and operational behavior.",{"label":1249,"description":1250},"6. Validate","Measure the real system against the original requirement. The test result validates the NFR; the ADR alone does not.","From requirement to evidence",{"id":439,"data":1253,"type":225},{"body":1254,"title":1255,"variant":443},"Real systems rarely have one requirement and one decision. Performance may trade against cost, consistency, operability, security, maintainability, energy use or delivery risk. The useful model is therefore a traceability graph, not a one-to-one mapping.","Where the simple example stops",{"id":445,"data":1257,"type":42},{"text":1258,"level":237},"NFRs and ADRs usually have a many-to-many relationship",{"id":449,"data":1260,"type":218},{"text":1261},"One quality requirement can drive several architecture decisions. A tenant-isolation requirement, for example, can influence identity propagation, database scoping, background-job design, cache keys, audit logging, and administrative tooling.",{"id":453,"data":1263,"type":218},{"text":1264},"One architecture decision can also respond to several requirements at once. Choosing an asynchronous processing boundary might improve responsiveness and failure isolation while introducing consistency, complexity, observability, and operational trade-offs.",{"id":457,"data":1266,"type":298},{"rows":1267,"title":1280,"layout":290,"columns":1281},[1268,1271,1274,1277],{"id":461,"label":1269,"values":1270},"One NFR → many ADRs",{"adr":464,"nfr":465,"validation":466},{"id":468,"label":1272,"values":1273},"Many NFRs → one ADR",{"adr":471,"nfr":472,"validation":473},{"id":475,"label":1275,"values":1276},"ADR without a classic NFR",{"adr":478,"nfr":479,"validation":480},{"id":482,"label":1278,"values":1279},"Requirement stable, ADR changes",{"adr":485,"nfr":486,"validation":487},"Why the relationship is not one-to-one",[1282,1284,1286],{"id":293,"label":1283},"Requirement side",{"id":296,"label":1285},"Decision side",{"id":495,"label":1287},"Validation side",{"id":498,"data":1289,"type":42},{"text":1290,"level":237},"A technology choice is not automatically a requirement",{"id":502,"data":1292,"type":218},{"text":1293},"A recurring architecture error is to write a preferred technology into the requirements layer and then treat the resulting design as inevitable.",{"id":506,"data":1295,"type":218},{"text":1296},"“The system must use PostgreSQL” can be a legitimate constraint if a contract, platform policy, compatibility requirement, licensing rule, organizational standard, or existing operational boundary actually mandates PostgreSQL. But if the real need is transactional consistency, structured querying, operational familiarity, or a specific recovery objective, the requirement should state that need and the technology selection should be recorded as a decision.",{"id":510,"data":1298,"type":290},{"content":1299,"stretched":43,"withHeadings":14},[1300,1304,1308,1312,1316,1320,1324],[1301,1302,1303],"Statement","Classification","Reason",[1305,1306,1307],"All tenant-scoped reads must enforce tenant isolation","Requirement \u002F security property","Describes a property that must hold",[1309,1310,1311],"Use PostgreSQL Row Level Security for selected tenant-scoped tables","Architecture decision","Chooses a mechanism intended to help satisfy the isolation property",[1313,1314,1315],"The deployment target must run in an approved EU-operated environment","Constraint \u002F NFR-like operating condition","Restricts where the system may operate",[1317,1318,1319],"Use provider X in region Y","Architecture \u002F deployment decision unless externally mandated","Selects a particular solution inside the allowed boundary",[1321,1322,1323],"95th-percentile API latency ≤ 300 ms under workload W","Quality requirement","Defines measurable performance behavior",[1325,1310,1326],"Introduce a cache for endpoint X","Selects a tactic intended to improve the measured behavior",{"id":541,"data":1328,"type":42},{"text":1329,"level":237},"An ADR is not proof that an NFR has been satisfied",{"id":545,"data":1331,"type":218},{"text":1332},"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":1334,"type":218},{"text":1335},"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":1337,"type":225},{"body":1338,"title":1339,"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":1341,"type":42},{"text":1342,"level":237},"When does an NFR become architecturally significant?",{"id":562,"data":1344,"type":218},{"text":1345},"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":1347,"type":218},{"text":1348},"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":1350,"type":437},{"steps":1351,"title":1370,"orientation":436},[1352,1355,1358,1361,1364,1367],{"label":1353,"description":1354},"1. Ask whether the requirement changes structure","Would different values force different components, boundaries, data paths or deployment topology?",{"label":1356,"description":1357},"2. Ask whether it constrains major technology choices","Does it eliminate otherwise viable implementation options?",{"label":1359,"description":1360},"3. Ask whether it creates cross-cutting behavior","Does it affect many components, teams, interfaces or lifecycle stages?",{"label":1362,"description":1363},"4. Ask whether it creates a difficult trade-off","Does improving this property materially affect another quality, cost, schedule, complexity or risk?",{"label":1365,"description":1366},"5. Ask whether failure is expensive","Would missing the requirement create material operational, security, regulatory, financial or product impact?",{"label":1368,"description":1369},"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":1372,"type":42},{"text":1373,"level":237},"A stronger architecture model: requirement → decision → implementation → validation",{"id":597,"data":1375,"type":218},{"text":1376},"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":1378,"type":437},{"steps":1379,"title":1403,"orientation":436},[1380,1383,1386,1389,1392,1394,1397,1400],{"label":1381,"description":1382},"Need \u002F business goal","Why the quality or constraint matters.",{"label":1384,"description":1385},"Requirement \u002F NFR","What the system must achieve or respect.",{"label":1387,"description":1388},"Architecture drivers","Which requirements are significant enough to shape the design.",{"label":1390,"description":1391},"Options","Plausible ways to address the driver.",{"label":617,"description":1393},"The selected choice, rationale, alternatives, trade-offs and consequences.",{"label":1395,"description":1396},"Implementation","Code, data model, infrastructure, interfaces and operational mechanisms that realize the decision.",{"label":1398,"description":1399},"Validation evidence","Tests, measurements, analysis or audits demonstrating whether the original requirement is actually satisfied.",{"label":1401,"description":1402},"Change \u002F supersession","New evidence or changed requirements can trigger a new ADR while preserving historical reasoning.","Architecture traceability chain",{"id":630,"data":1405,"type":42},{"text":1406,"level":237},"Implementation evidence: how I separate requirements and decisions in SenseFlow",{"id":634,"data":1408,"type":225},{"body":1409,"title":1410,"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":1412,"type":218},{"text":1413},"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":1415,"type":218},{"text":1416},"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":1418,"type":218},{"text":1419},"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":1421,"type":290},{"content":1422,"stretched":43,"withHeadings":14},[1423,1427,1431,1435,1438,1441,1445],[1424,1425,1426],"SenseFlow layer","What it contains","Role in ADR\u002FNFR separation",[1428,1429,1430],"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",[1432,1433,1434],"Decision integrity","Decision, reason, alternatives, trade-offs, status, date\u002Fversion","Preserves why an architecturally significant choice became authoritative",[667,1436,1437],"Requirements, architecture, research, decision records, risks, roadmap and supporting sources","Maintains conceptual and historical Source of Truth",[671,1439,1440],"Initiatives\u002Fgoals, epics, stories, tasks and delivery state","Executes approved work without becoming the conceptual Source of Truth",[1442,1443,1444],"Change management","Current state → new evidence → proposed change → impact → decision","Allows decisions to evolve without erasing the reasoning trail",[1446,1447,1448],"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":1450,"type":225},{"body":1451,"title":1452,"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":1454,"type":42},{"text":1455,"level":237},"Enterprise project context: requirements should precede architecture choices",{"id":692,"data":1457,"type":218},{"text":1458},"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":1460,"type":218},{"text":1461},"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":1463,"type":42},{"text":1464,"level":237},"Common failure modes when ADRs and NFRs are mixed",{"id":704,"data":1466,"type":290},{"content":1467,"stretched":43,"withHeadings":14},[1468,1472,1476,1480,1484,1488,1492,1496,1500],[1469,1470,1471],"Failure mode","What happens","Consequence",[1473,1474,1475],"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",[1477,1478,1479],"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",[1481,1482,1483],"ADR treated as proof","A documented choice is assumed to mean the requirement is satisfied","Architecture intent replaces measurement or verification",[1485,1486,1487],"Vague NFR","Words such as fast, scalable, secure or maintainable have no measurable scope","Different stakeholders can believe the same requirement means different things",[1489,1490,1491],"No alternatives recorded","The team records only the selected technology","Future maintainers cannot reconstruct why another option was rejected",[1493,1494,1495],"No supersession model","Old ADRs are edited or deleted when the architecture changes","Historical reasoning disappears and stale decisions can remain ambiguous",[1497,1498,1499],"Every implementation detail becomes an ADR","The repository fills with low-value records","Important architecture choices become difficult to find",[1501,1502,1503],"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":1505,"type":42},{"text":1506,"level":237},"The ADR–NFR decision framework",{"id":748,"data":1508,"type":218},{"text":1509},"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":1511,"type":437},{"steps":1512,"title":1537,"orientation":436},[1513,1516,1519,1522,1525,1528,1531,1534],{"label":1514,"description":1515},"1. Is this a required property or external constraint?","If yes, write or reference the requirement before choosing a mechanism.",{"label":1517,"description":1518},"2. Can it be validated?","Define the scope, condition, metric, acceptance rule, analysis method or other evidence needed.",{"label":1520,"description":1521},"3. Is it architecturally significant?","Identify whether the requirement materially shapes structure, technology, data, deployment or cross-cutting trade-offs.",{"label":1523,"description":1524},"4. Are there meaningful alternatives?","Compare viable tactics or architecture options rather than jumping directly to a preferred technology.",{"label":1526,"description":1527},"5. Has a choice become authoritative?","Create or update the ADR with context, decision, rationale, alternatives, trade-offs, status and consequences.",{"label":1529,"description":1530},"6. Is the decision implemented?","Trace the ADR into design, tasks, code, configuration and operations.",{"label":1532,"description":1533},"7. Is the requirement satisfied?","Collect validation evidence against the requirement itself.",{"label":1535,"description":1536},"8. Did conditions change?","Re-evaluate the requirement and, when necessary, supersede the ADR without erasing history.","ADR–NFR classification test",{"id":781,"data":1539,"type":42},{"text":1540,"level":237},"What ADR and NFR are not",{"id":785,"data":1542,"type":298},{"rows":1543,"title":1556,"layout":290,"columns":1557},[1544,1546,1548,1550,1553],{"id":293,"label":1129,"values":1545},{"not":790,"why":791,"term":792},{"id":296,"label":617,"values":1547},{"not":795,"why":796,"term":797},{"id":799,"label":1398,"values":1549},{"not":801,"why":802,"term":803},{"id":805,"label":1551,"values":1552},"Backlog item",{"not":808,"why":809,"term":810},{"id":812,"label":1554,"values":1555},"Constraint",{"not":815,"why":816,"term":817},"Common category errors",[1558,1560,1562],{"id":821,"label":1559},"Concept",{"id":824,"label":1561},"It is not",{"id":827,"label":1303},{"id":829,"data":1564,"type":42},{"text":1565,"level":237},"What would change this answer?",{"id":833,"data":1567,"type":218},{"text":1568},"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":837,"data":1570,"type":218},{"text":1571},"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":841,"data":1573,"type":218},{"text":1574},"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":845,"data":1576,"type":42},{"text":1577,"level":237},"Limitations",{"id":849,"data":1579,"type":218},{"text":1580},"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":853,"data":1582,"type":218},{"text":1583},"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":857,"data":1585,"type":218},{"text":1586},"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":861,"data":1588,"type":42},{"text":1589,"level":237},"Conclusion",{"id":865,"data":1591,"type":218},{"text":1592},"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":869,"data":1594,"type":218},{"text":1595},"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":873,"data":1597,"type":218},{"text":1598},"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":877,"data":1600,"type":42},{"text":1601,"level":237},"FAQ",{"id":881,"data":1603,"type":881},{"items":1604,"title":912},[1605,1608,1611,1614,1617,1620,1623],{"id":885,"answer":1606,"question":1607},"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":889,"answer":1609,"question":1610},"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":893,"answer":1612,"question":1613},"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":897,"answer":1615,"question":1616},"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":901,"answer":1618,"question":1619},"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":905,"answer":1621,"question":1622},"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":909,"answer":1624,"question":1625},"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":914,"data":1627,"type":42},{"text":1628,"level":237},"Glossary",{"id":918,"data":1630,"type":918},{"title":1631,"entries":1632},"Core architecture terms",[1633,1635,1638,1641,1644,1646,1649,1652],{"term":923,"anchor":293,"definition":1634},"Non-functional requirement: practical shorthand for a required system quality, constraint, or operating condition; exact terminology varies by method and standard.",{"term":1636,"anchor":927,"definition":1637},"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":1639,"anchor":296,"definition":1640},"Architecture Decision Record (ADR)","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":934,"definition":1643},"Architecturally Significant Requirement (ASR)","A requirement with sufficiently far-reaching architectural impact that it materially influences the system design.",{"term":1554,"anchor":812,"definition":1645},"A condition that restricts the solution space, including external policy, regulation, platform, compatibility, contractual or organizational boundaries.",{"term":1647,"anchor":940,"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":947,"definition":1654},"Superseded ADR","A historical decision record that has been replaced by a newer authoritative decision while remaining available for traceability.",{"id":950,"data":1656,"type":42},{"text":1657,"level":237},"Primary sources and implementation evidence",{"id":954,"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":958,"data":1662,"type":966},{"link":960,"meta":1663},{"image":1664,"title":1665,"description":1666},{"url":963},"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":968,"data":1668,"type":966},{"link":970,"meta":1669},{"image":1670,"title":1671,"description":1672},{"url":963},"ISO\u002FIEC\u002FIEEE DIS 29148 — Requirements Engineering","Draft International Standard currently under development and intended to replace ISO\u002FIEC\u002FIEEE 29148:2018.",{"id":976,"data":1674,"type":966},{"link":978,"meta":1675},{"image":1676,"title":1677,"description":1678},{"url":963},"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":984,"data":1680,"type":966},{"link":986,"meta":1681},{"image":1682,"title":1683,"description":1684},{"url":963},"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":992,"data":1686,"type":966},{"link":994,"meta":1687},{"image":1688,"title":1689,"description":1690},{"url":963},"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":1000,"data":1692,"type":966},{"link":1002,"meta":1693},{"image":1694,"title":1695,"description":1696},{"url":963},"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":1008,"data":1698,"type":966},{"link":1010,"meta":1699},{"image":1700,"title":1701,"description":1702},{"url":963},"SEI — Defining Non-Functional System Qualities","SEI overview connecting non-functional\u002Fquality attributes with architecture, scenarios, trade-offs and objective system evaluation.",{"id":1016,"data":1704,"type":966},{"link":1018,"meta":1705},{"image":1706,"title":1707,"description":1708},{"url":963},"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":1024,"data":1710,"type":966},{"link":1026,"meta":1711},{"image":1712,"title":1713,"description":1714},{"url":963},"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":1032},{"time":212,"blocks":1719,"version":1031},[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":818,"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":623,"values":1949},{"not":801,"why":802,"term":803},{"id":805,"label":806,"values":1951},{"not":808,"why":809,"term":810},{"id":812,"label":813,"values":1953},{"not":815,"why":816,"term":817},[1955,1956,1957],{"id":821,"label":822},{"id":824,"label":825},{"id":827,"label":516},{"id":829,"data":1959,"type":42},{"text":831,"level":237},{"id":833,"data":1961,"type":218},{"text":835},{"id":837,"data":1963,"type":218},{"text":839},{"id":841,"data":1965,"type":218},{"text":843},{"id":845,"data":1967,"type":42},{"text":847,"level":237},{"id":849,"data":1969,"type":218},{"text":851},{"id":853,"data":1971,"type":218},{"text":855},{"id":857,"data":1973,"type":218},{"text":859},{"id":861,"data":1975,"type":42},{"text":863,"level":237},{"id":865,"data":1977,"type":218},{"text":867},{"id":869,"data":1979,"type":218},{"text":871},{"id":873,"data":1981,"type":218},{"text":875},{"id":877,"data":1983,"type":42},{"text":879,"level":237},{"id":881,"data":1985,"type":881},{"items":1986,"title":912},[1987,1988,1989,1990,1991,1992,1993],{"id":885,"answer":886,"question":887},{"id":889,"answer":890,"question":891},{"id":893,"answer":894,"question":895},{"id":897,"answer":898,"question":899},{"id":901,"answer":902,"question":903},{"id":905,"answer":906,"question":907},{"id":909,"answer":910,"question":911},{"id":914,"data":1995,"type":42},{"text":916,"level":237},{"id":918,"data":1997,"type":918},{"title":920,"entries":1998},[1999,2000,2001,2002,2003,2004,2005,2006],{"term":923,"anchor":293,"definition":924},{"term":926,"anchor":927,"definition":928},{"term":930,"anchor":296,"definition":931},{"term":933,"anchor":934,"definition":935},{"term":813,"anchor":812,"definition":937},{"term":939,"anchor":940,"definition":941},{"term":943,"anchor":495,"definition":944},{"term":946,"anchor":947,"definition":948},{"id":950,"data":2008,"type":42},{"text":952,"level":237},{"id":954,"data":2010,"type":218},{"text":956},{"id":958,"data":2012,"type":966},{"link":960,"meta":2013},{"image":2014,"title":964,"description":965},{"url":963},{"id":968,"data":2016,"type":966},{"link":970,"meta":2017},{"image":2018,"title":973,"description":974},{"url":963},{"id":976,"data":2020,"type":966},{"link":978,"meta":2021},{"image":2022,"title":981,"description":982},{"url":963},{"id":984,"data":2024,"type":966},{"link":986,"meta":2025},{"image":2026,"title":989,"description":990},{"url":963},{"id":992,"data":2028,"type":966},{"link":994,"meta":2029},{"image":2030,"title":997,"description":998},{"url":963},{"id":1000,"data":2032,"type":966},{"link":1002,"meta":2033},{"image":2034,"title":1005,"description":1006},{"url":963},{"id":1008,"data":2036,"type":966},{"link":1010,"meta":2037},{"image":2038,"title":1013,"description":1014},{"url":963},{"id":1016,"data":2040,"type":966},{"link":1018,"meta":2041},{"image":2042,"title":1021,"description":1022},{"url":963},{"id":1024,"data":2044,"type":966},{"link":1026,"meta":2045},{"image":2046,"title":1029,"description":1030},{"url":963},"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","Generativna veštačka inteligencija objašnjena: modeli, pretraga, alati i aplikacije nisu ista stvar","Generativna AI je više od modela. Saznajte kako se modeli, pretraga, alati, kontekst, okruženja i aplikacije uklapaju u produkcione AI sisteme.","\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},"455","zbt-z8102ax-dual-sim-failover-test","ZBT Z8102AX Dual-SIM failover: Šta radi, šta nedostaje i šta zahteva bolji firmver","ZBT Z8102AX je dual-SIM 5G OpenWrt ruter, ali sam dual-SIM hardver nije isto što i inteligentni failover. Ruter prepoznaje SIM karticu i uspešno se povezuje, ali automatsko prebacivanje, oporavak modema, odluke zasnovane na signalu i čista failover logika i dalje zahtevaju dublje testiranje.","\u002Fuploads\u002F2026\u002F06\u002Fopenwrt-router-review-dual-sim-03-1781620592829-7t77j7.webp","2026-06-16T10:40:00.000Z",{"id":2065,"slug":2066,"title":2067,"excerpt":2068,"featuredImage":2069,"publishedAt":2070},"435","ultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks","Konačni vodič za kriterijume prihvatanja za usvajanje LLM u poslovnim priručnicima","Savladajte veštinu definisanja preciznih kriterijuma prihvatanja kako biste obezbedili uspešnu integraciju LLM-ova u vašem poslovnom okruženju. Ovaj sveobuhvatni vodič pruža praktične okvire, primere i najbolje prakse prilagođene usvajanju vođenom plejbucom.","\u002Fuploads\u002F2026\u002F09\u002Fultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks-1788540267775-zgr6mm.webp","2026-09-06T11:50:00.000Z",{"id":2072,"slug":2073,"title":2074,"excerpt":2075,"featuredImage":2076,"publishedAt":2077},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Ovladavanje SEO radnim tokom: Ključne strategije optimizacije za organski rast","Strukturiran SEO tok posla je ključan za održiv organski rast. Naučite deset osnovnih strategija, od istraživanja ključnih reči i tehničke optimizacije do kvaliteta sadržaja i analize performansi.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z","fallback",[],[]]