ADR vs NFR: Arhitektonske odluke i kvalitet sistema nisu ista stvar

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.

Objavljeno:8. октобар 2026. 14:11

Aleksandar Stajić

Ажурирано: 8. октобар 2026. 19:31

ADR vs NFR: Arhitektonske odluke i kvalitet sistema nisu ista stvar

Nefunkcionalni zahtev (NFR) opisuje kvalitet, ograničenje ili uslov rada koji sistem treba da zadovolji. Zapis arhitektonske odluke (ADR) 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.

Koja je razlika između NFR-a i ADR-a?

Najjednostavnija razlika je gramatička. Zahtev opisuje uslov koji sistem mora da zadovolji. Zapis odluke opisuje izbor koji je tim napravio.

Na primer, „API mora da vrati 95% zahteva za čitanje u roku od 300 ms pod dogovorenim referentnim opterećenjem“ je zahtev kvaliteta. „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“ je arhitektonska odluka.

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.

NFR i ADR odgovaraju na različita pitanja

	NFR / zahtev kvaliteta	ADR / arhitektonska odluka
Primarno pitanje	What quality, constraint, or operating condition must the system satisfy?	What architecturally significant choice did we make, and why?
Tipičan sadržaj	Measurable target, scope, condition, constraint, acceptance or validation rule	Context, decision, rationale, alternatives, trade-offs, status and consequences
Uloga u životnom ciklusu	A requirement to design for and validate	A historical record of a significant decision
Šta ga dokazuje?	Measurement, test, analysis, inspection, audit or other validation evidence	The record proves what was decided, not that the resulting system meets the requirement
Kada se menja	When stakeholder need, operating conditions, policy or quality target changes	When the decision is replaced, rejected, deprecated, or superseded

Šta je NFR u preciznim arhitektonskim terminima?

„Nefunkcionalni zahtev“ je zgodna industrijska oznaka, ali može da sakrije nekoliko različitih vrsta izjava. U arhitektonskom radu, korisna razlika je između funkcionalnog ponašanja, zahteva kvaliteta i ograničenja.

ISO/IEC 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.

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.

Slaba izjava	Korisniji oblik zahteva	Zašto je razlika važna
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
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
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
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
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

Šta je zapis arhitektonske odluke?

Zapis arhitektonske odluke je sažet zapis važne arhitektonske odluke. Originalna ADR formulacija Michaela Nygarda naglašava kontekst, odluku, njen status i rezultujuće posledice.

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.

ISO/IEC/IEEE 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.

ADR polje	Šta čuva	Zašto je važno
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
Odluka	Izbor koji je postao merodavan	Razdvaja izabranu opciju od diskusije
Status	Predloženo, prihvaćeno, odbijeno, zastarelo, zamenjeno ili drugo kontrolisano stanje	Sprječava da stare odluke tiho ostanu aktivne
Alternative	Druge održive opcije koje su razmatrane	Pokazuje da izabrano rešenje nije bilo jedino zamislivo
Obrazloženje / kompromisi	Zašto je opcija izabrana i čega se odriče	Čini arhitektonsko rezonovanje proverljivim
Posledice	Očekivani pozitivni i negativni efekti, naknadni rad, rizici	Povezuje lokalni izbor sa uticajem na sistem
Datum / verzija	Kada je odluka postala važeća	Podržava istorijsku sledljivost i kasnije zamene

Najjednostavniji primer: zahtev za latenciju → arhitektonska odluka

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.

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.

Od zahteva do dokaza

1

1. Navedite zahtev

Definišite cilj kvaliteta, opterećenje, obim, prag i metod validacije.

2

2. Identifikujte arhitektonski značaj

Utvrdite da li zahtev materijalno utiče na strukturu, tehnologiju, raspoređivanje, tok podataka ili operativni model.

3

3. Procenite opcije

Uporedite alternative kao što su indeksiranje, keširanje, denormalizacija, asinhroni rad, particionisanje ili druga arhitektura upita.

4

4. Zabeležite odluku

Zabeležite izabrani arhitektonski izbor, obrazloženje, alternative, kompromise, status i posledice u ADR-u.

5

5. Implementirajte

Pretvorite odluku u kod, infrastrukturu, konfiguraciju i operativno ponašanje.

6

6. Validirajte

Izmerite stvarni sistem u odnosu na prvobitni zahtev. Rezultat testa validira NFR; sam ADR to ne čini.

NFR-ovi i ADR-ovi obično imaju odnos više-na-više

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.

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.

Zašto odnos nije jedan-na-jedan

	Strana zahteva	Strana odluke	Strana validacije
Jedan NFR → mnogo ADR-ova	A broad quality target can constrain several architectural boundaries	Several coordinated decisions may be required	Evidence may need multiple tests or measurements
Mnogo NFR-ova → jedan ADR	Several quality and constraint drivers can point at the same design problem	One decision may balance several drivers	Each requirement still needs its own acceptance evidence
ADR bez klasičnog NFR-a	The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition	The choice can still be architecturally significant	Validate against the actual driver, not an invented NFR
Zahtev stabilan, ADR se menja	The target can remain unchanged	A better or necessary implementation choice can supersede the old decision	The new architecture must still be checked against the same target

Izbor tehnologije nije automatski zahtev

Č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.

„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.

Izjava	Klasifikacija	Razlog
Sva čitanja u opsegu zakupca moraju da sprovedu izolaciju zakupaca	Zahtev / bezbednosno svojstvo	Opisuje svojstvo koje mora da važi
Koristite PostgreSQL Row Level Security za izabrane tabele u opsegu zakupca	Arhitektonska odluka	Bira mehanizam namenjen da pomogne u zadovoljavanju svojstva izolacije
Ciljno okruženje za raspoređivanje mora da radi u odobrenom okruženju kojim upravlja EU	Ograničenje / operativni uslov sličan NFR-u	Ograničava gde sistem može da radi
Koristite provajdera X u regionu Y	Arhitektonska / odluka o raspoređivanju osim ako nije spolja propisana	Bira određeno rešenje unutar dozvoljene granice
Latencija API-ja na 95. percentilu ≤ 300 ms pod opterećenjem W	Zahtev za kvalitet	Definiše merljivo ponašanje performansi
Uvedite keš za krajnju tačku X	Arhitektonska odluka	Bira taktiku namenjenu da poboljša merljivo ponašanje

ADR nije dokaz da je NFR zadovoljen

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.

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.

Kada nefunkcionalni zahtev postaje arhitektonski značajan?

Nije svaki nefunkcionalni zahtev vredan arhitektonske odluke. Važan podskup čine zahtevi koji suštinski oblikuju arhitekturu ili nameću kompromise kroz sistem.

SEI literatura koristi koncept arhitektonski značajnih zahteva 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.

Test arhitektonske značajnosti

1

1. Pitajte da li zahtev menja strukturu

Da li bi različite vrednosti nametnule različite komponente, granice, tokove podataka ili topologiju postavljanja?

2

2. Pitajte da li ograničava glavne tehnološke izbore

Da li eliminiše inače održive opcije implementacije?

3

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?

4

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?

5

5. Pitajte da li je neuspeh skup

Da li bi propuštanje zahteva stvorilo materijalni operativni, bezbednosni, regulatorni, finansijski ili produktni uticaj?

6

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.

Jači arhitektonski model: zahtev → odluka → implementacija → validacija

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.

Lanac arhitektonske sledljivosti

1

Potreba / poslovni cilj

Zašto su kvalitet ili ograničenje važni.

2

Zahtev / NFR

Šta sistem mora da postigne ili poštuje.

3

Arhitektonski pokretači

Koji su zahtevi dovoljno značajni da oblikuju dizajn.

4

Opcije

Verodostojni načini da se adresira pokretač.

5

ADR

Izabrani izbor, obrazloženje, alternative, kompromisi i posledice.

6

Implementacija

Kod, model podataka, infrastruktura, interfejsi i operativni mehanizmi koji realizuju odluku.

7

Dokaz validacije

Testovi, merenja, analize ili revizije koje pokazuju da li je originalni zahtev zaista zadovoljen.

8

Promena / zamena

Novi dokazi ili promenjeni zahtevi mogu pokrenuti novi ADR uz očuvanje istorijskog obrazloženja.

Implementacioni dokaz: kako razdvajam zahteve i odluke u SenseFlow-u

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.

Za značajne SenseFlow odluke, evidentirana polja su Odluka, Razlog, Alternative, Kompromisi, Status i Datum / Verzija. Glavne arhitektonske i produktne odluke treba da ostanu istorijski sledljive umesto da budu prepisane kada projekat evoluira.

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.

SenseFlow sloj	Šta sadrži	Uloga u razdvajanju ADR/NFR
Produktna / 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
Integritet odluka	Odluka, razlog, alternative, kompromisi, status, datum/verzija	Čuva zašto je arhitektonski značajan izbor postao autoritativan
Confluence	Zahtevi, arhitektura, istraživanje, zapisi odluka, rizici, mapa puta i prateći izvori	Održava konceptualni i istorijski Izvor istine
Jira	Inicijative/ciljevi, epici, priče, zadaci i stanje isporuke	Izvršava odobreni rad bez postajanja konceptualnog Izvora istine
Upravljanje promenama	Trenutno stanje → novi dokaz → predložena promena → uticaj → odluka	Omogućava odlukama da evoluiraju bez brisanja traga obrazloženja
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

Kontekst enterprise projekta: zahtevi treba da prethode arhitektonskim izborima

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.

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.

Uobičajeni obrasci neuspeha kada se ADR i NFR mešaju

Obrazac neuspeha	Šta se dešava	Posledica
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
NFR skriven samo unutar ADR-a	Odluka pominje cilj performansi/bezbednosti koji nije prisutan u osnovi zahteva	Cilj je teško validirati, prioritizovati ili upravljati njime nezavisno
ADR tretiran kao dokaz	Pretpostavlja se da dokumentovani izbor znači da je zahtev zadovoljen	Arhitektonska namera zamenjuje merenje ili verifikaciju
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
Nema evidentiranih alternativa	Tim evidentira samo izabranu tehnologiju	Budući održavaoci ne mogu rekonstruisati zašto je druga opcija odbijena
Nema modela zamene	Stari ADR-ovi se menjaju ili brišu kada se arhitektura promeni	Istorijsko rezonovanje nestaje i zastarele odluke mogu ostati dvosmislene
Svaki detalj implementacije postaje ADR	Repozitorijum se puni zapisima male vrednosti	Važne arhitektonske odluke postaju teške za pronalaženje
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

ADR–NFR okvir za odlučivanje

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.

ADR–NFR test klasifikacije

1

1. Da li je ovo obavezno svojstvo ili spoljno ograničenje?

Ako jeste, napišite ili navedite zahtev pre izbora mehanizma.

2

2. Može li se validirati?

Definišite obim, uslov, metriku, pravilo prihvatanja, metod analize ili druge potrebne dokaze.

3

3. Da li je arhitektonski značajno?

Utvrdite da li zahtev materijalno oblikuje strukturu, tehnologiju, podatke, raspoređivanje ili unakrsne kompromise.

4

4. Postoje li smislene alternative?

Uporedite održive taktike ili arhitektonske opcije umesto direktnog prelaska na preferiranu tehnologiju.

5

5. Da li je izbor postao autoritativan?

Kreirajte ili ažurirajte ADR sa kontekstom, odlukom, obrazloženjem, alternativama, kompromisima, statusom i posledicama.

6

6. Da li je odluka implementirana?

Pratite ADR kroz dizajn, zadatke, kod, konfiguraciju i operacije.

7

7. Da li je zahtev zadovoljen?

Prikupite dokaze validacije u odnosu na sam zahtev.

8

8. Da li su se uslovi promenili?

Ponovo procenite zahtev i, kada je potrebno, zamenite ADR bez brisanja istorije.

Šta ADR i NFR nisu

Uobičajene greške u kategorizaciji

	Koncept	Nije	Razlog
NFR / zahtev kvaliteta	A required quality, constraint or operating condition	A technology shopping list	Requirements should preserve the need independently from one implementation when possible
ADR	A record of an architecturally significant decision	The complete architecture description	Architecture also needs views, interfaces, models, responsibilities and other documentation
Dokaz validacije	Evidence that checks whether a requirement is satisfied	The ADR itself	Documented intent is different from measured or analyzed system behavior
Stavka backlog-a	Actionable delivery work	A durable substitute for architecture rationale	Task state answers what is being delivered, not necessarily why the architecture exists
Ograničenje	A condition that restricts the solution space	Always an internally chosen architecture decision	Some constraints come from regulation, contracts, existing platforms or organizational boundaries

Šta bi promenilo ovaj odgovor?

Terminologija može evoluirati. ISO/IEC/IEEE 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.

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.

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.

Ograničenja

Ovaj članak koristi NFR 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.

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.

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.

Zaključak

ADR i NFR pripadaju različitim slojevima arhitektonskog rada. NFR definiše cilj kvaliteta, ograničenje ili uslov rada. ADR evidentira značajan arhitektonski odgovor na jedan ili više pokretača.

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.

Najjači lanac stoga nije „NFR → ADR → gotovo“. On je potreba → zahtev → arhitektonski pokretači → opcije → odluka → implementacija → validacija → promena. Taj lanac pretvara arhitektonsku dokumentaciju od statičke papirologije u proverljiv zapis o tome zašto sistem ima oblik koji ima.

Često postavljana pitanja

ADR vs NFR

Da li je ADR nefunkcionalni zahtev?

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 svaki NFR treba da ima ADR?

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.

Može li „koristiti PostgreSQL“ biti NFR?

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.

Da li ADR dokazuje da je zahtev za performansama ili bezbednošću ispunjen?

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.

Šta treba da sadrži ADR?

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 čini NFR arhitektonski značajnim?

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.

Treba li obrisati stari ADR kada se arhitektura promeni?

Obično ne. Odluka o zameni treba normalno da zameni stari zapis kako bi istorijsko obrazloženje ostalo sledljivo.

Pojmovnik

Osnovni arhitektonski pojmovi

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.
Zahtev za atributom kvaliteta: 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.
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.
Arhitektonski značajan zahtev (ASR): Zahtev sa dovoljno dalekosežnim arhitektonskim uticajem da materijalno utiče na dizajn sistema.
Ograničenje: Uslov koji ograničava prostor rešenja, uključujući spoljnu politiku, regulativu, platformu, kompatibilnost, ugovorne ili organizacione granice.
Kompromis: Dizajnerski odnos u kojem poboljšanje jednog cilja, svojstva ili dimenzije troška može pogoršati drugi.
Validacija: Rad koji proizvodi dokaze i koristi se za utvrđivanje da li implementirani sistem zadovoljava navedeni zahtev pod relevantnim uslovima.
Zamenjeni ADR: Istorijski zapis odluke koji je zamenjen novijom autoritativnom odlukom, ali ostaje dostupan radi sledljivosti.

Primarni izvori i dokazi o implementaciji

Ovaj članak razdvaja aktuelne standarde od dokaza o implementaciji projekta. ISO/IEC/IEEE 29148:2018 je aktuelan zaključno sa 8. oktobrom 2026, ali je označen za reviziju; ISO/IEC 25010:2023 i ISO/IEC/IEEE 42010:2022 su aktuelna objavljena izdanja. SenseFlow je originalni dokaz projekta za model sledljivosti i integriteta odluka opisan gore.

ISO/IEC/IEEE 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.

ISO/IEC/IEEE DIS 29148 — Inženjering zahteva

Nacrt međunarodnog standarda koji je trenutno u razvoju i namenjen da zameni ISO/IEC/IEEE 29148:2018.

ISO/IEC 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.

ISO/IEC/IEEE 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.

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.

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.

SEI — Definisanje nefunkcionalnih kvaliteta sistema

SEI pregled koji povezuje nefunkcionalne atribute kvaliteta sa arhitekturom, scenarijima, kompromisima i objektivnom evaluacijom sistema.

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.

SEI — Kolekcija pogleda i šire

Smernice za arhitektonsku dokumentaciju koje naglašavaju relevantne poglede i beleženje neophodnih dizajnerskih odluka kao deo arhitektonskog rada.

Подели

Подели на X Подели на Xing Подели на Facebook Подели на LinkedIn Подели на Telegram Подели путем е-поште