Kako napisati QRD: vodič za zahteve kvaliteta

QRD, ili Quality Requirements Document, definiše standarde kvaliteta koje gotov proizvod mora da ispuni. Dok funkcionalni zahtevi opisuju šta sistem radi, a nefunkcionalni zahtevi opisuju koliko dobro funkcioniše, QRD postavlja granicu prihvatanja — merljive kriterijume koji određuju da li je proizvod spreman za release.

QRD odgovara na pitanje: kako znamo da je ovaj proizvod dovoljno dobar da se isporuči?

Key insight

QRD nije plan testiranja. Plan testiranja opisuje kako testirati sistem. QRD opisuje šta „kvalitet” znači za ovaj konkretni projekat — benčmarkove, standarde i kriterijume prihvatanja koje testiranje mora da verifikuje.

Ko piše i za koga

Vlasnik QRD-a je obično QA lider, menadžer kvaliteta, test arhitekta ili tehnički projektni menadžer — neko ko može da prevede poslovna očekivanja u merljive ciljeve kvaliteta.

Kada je QRD potreban — a kada nije

QRD je potreban kada:

• Projekat ima eksterne standarde kvaliteta koje mora da ispuni (ISO 9001, IEC 62304 za medicinske uređaje, DO-178C za avijacijski softver)
• Više timova ili vendora doprinosi proizvodu i potrebni su im zajednički benčmarkovi kvaliteta
• Organizacija ima formalan proces release-a sa kapijama kvaliteta
• Prethodni projekti su imali probleme sa kvalitetom jer kriterijumi prihvatanja nisu bili definisani ili su bili neformalni
• Klijent ima specifična očekivanja kvaliteta dokumentovana u ugovoru

QRD nije potreban kada:

• Tim ima uspostavljenu definiciju završenog i kulturu kvaliteta koja funkcioniše bez formalne dokumentacije
• Zahtevi za kvalitet su već pokriveni u sekciji nefunkcionalnih zahteva SRD-a
• Projekat je prototip, MVP ili proof of concept gde se kvalitet eksplicitno žrtvuje zarad brzine
• Tim je dovoljno mali da se standardi kvaliteta komuniciraju usmeno i dosljedno primenjuju

Šta QRD sadrži

Osnovne sekcije

QRD obično uključuje pet sekcija:

1. Uvod — svrha, opseg, odnos sa drugim dokumentima (SRD, PRD, plan testiranja) i definicije pojmova kvaliteta korišćenih u dokumentu.

2. Atributi kvaliteta — specifične karakteristike kvaliteta koje proizvod mora da pokaže, svaka sa merljivim ciljem.

   Atribut	Definicija	Cilj	Metod merenja
   Pouzdanost	Uptime sistema i stopa grešaka	99,95% uptime, ispod 0,1% stopa grešaka	Produkcijski monitoring, mesečno
   Performanse	Vreme odziva pod opterećenjem	P95 < 300ms pri 5K istovremenih korisnika	Load testiranje sa k6/Locust
   Bezbednost	Otpornost na poznate ranjivosti	Nula kritičnih/visokih CVE pri release-u	SAST + DAST skeniranje, penetration test
   Upotrebljivost	Završenost zadataka od strane ciljnih korisnika	90% stopa završetka zadatka u testiranju upotrebljivosti	Moderisani test upotrebljivosti, N=10
   Održivost	Složenost koda i pokrivenost testovima	Ciklomatska složenost ispod 15, pokrivenost testovima iznad 80%	SonarQube analiza
   Pristupačnost	Usaglašenost sa standardima pristupačnosti	WCAG 2.2 AA	Automatizovana + ručna revizija
   Kompatibilnost	Podrška za pregledače i uređaje	Chrome, Firefox, Safari, Edge (poslednje 2 verzije); iOS 16+, Android 13+	Matrica cross-browser testiranja

3. Kriterijumi prihvatanja — specifični, testabilni uslovi koji moraju biti ispunjeni pre nego što proizvod može da se release-uje. Svaki kriterijum je povezan sa atributom kvaliteta i ima prag prolaz/pad.

   ID	Kriterijum	Prag	Blokira?
   QA-001	Svi P0 funkcionalni zahtevi prolaze automatizovane testove	100% prolaz	Da
   QA-002	Nema otvorenih kritičnih ili visoko ozbiljnih bagova	0 otvorenih P0/P1 bagova	Da
   QA-003	Testovi performansi prolaze pri ciljnom opterećenju	P95 < 300ms pri 5K korisnika	Da
   QA-004	Bezbednosno skeniranje ne pokazuje kritične ranjivosti	0 kritičnih CVE	Da
   QA-005	Revizija pristupačnosti prolazi WCAG 2.2 AA	Svi AA kriterijumi ispunjeni	Da
   QA-006	Pokrivenost koda prelazi cilj	>80% pokrivenost linija	Ne (savetodavno)
   QA-007	Sav tekst vidljiv korisniku pregledan za gramatiku i lokalizaciju	100% pregledano	Ne (savetodavno)

   „Blokira” znači da se release ne može nastaviti ako ovaj kriterijum padne. „Savetodavno” znači da tim pregleda rezultat, ali može da isporuči sa poznatim nedostatkom i planom za naknadno rešavanje.

4. Proces kvaliteta — kako se kvalitet održava tokom celog životnog ciklusa projekta, ne samo pri release-u. Ovo uključuje:

   • Standardi za pregled koda — šta recenzenti proveravaju, minimalan broj odobrenja
   • Strategija testiranja — unit, integracijsko, end-to-end, testiranje performansi, bezbednosti, pristupačnosti i kada se svako pokreće
   • Kapije kvaliteta — kontrolne tačke u procesu razvoja gde se kvalitet formalno procenjuje (npr. posle svakog sprinta, pre staging deploy-a, pre production release-a)
   • Upravljanje defektima — kako se bagovi klasifikuju (P0-P3), triažiraju i rešavaju, sa ciljnim vremenima odgovora po nivou ozbiljnosti

5. Dodaci — specifikacije dashboarda za metrike kvaliteta, kontrolne liste usaglašenosti, definicije ozbiljnosti defekata, rečnik pojmova i dnevnik promena.

Key insight

Najvredniji deo QRD-a je tabela kriterijuma prihvatanja (sekcija 3). To je ugovor između razvojnog tima i zainteresovanih strana: ako ovi kriterijumi prođu, proizvod se isporučuje. Ako bilo koji blokirajući kriterijum padne, ne isporučuje se. Ovo uklanja subjektivne debate o kvalitetu u vreme release-a.

QRD i drugi dokumenti zahteva

QRD radi uz SRD, a ne u sekvenci:

MRD → BRD → PRD → FRD → SRD
                           ↑
                          TRD (infrastruktura)
                          QRD (standardi kvaliteta)

Nefunkcionalni zahtevi SRD-a definišu ciljeve. QRD definiše kako se ti ciljevi verifikuju, koji su pragovi prolaz/pad i šta se dešava kada nisu ispunjeni.

Tipične greške

1. Definisanje kvaliteta bez merenja. „Proizvod mora biti visokog kvaliteta” je besmisleno. Kvalitet se mora razložiti na specifične, merljive atribute (performanse, pouzdanost, bezbednost, upotrebljivost) sa numeričkim ciljevima.

2. Proglašavanje svega blokirajućim kriterijumom. Ako svaki kriterijum kvaliteta blokira release, ništa se ne isporučuje. Rezervišite „blokirajući” status za kriterijume koji direktno utiču na korisnike, integritet podataka ili bezbednost. Koristite „savetodavno” za standarde koji poboljšavaju kvalitet, ali nisu zaustavljači isporuke.

3. Pisanje QRD-a na kraju projekta. Zahtevi za kvalitet treba da budu definisani pre početka razvoja, ne tokom pripreme za release. Kasno napisani QRD-ovi postaju retrospektivna opravdanja umesto prospektivnih standarda.

4. Bez povezanosti sa testiranjem. QRD bez odgovarajuće strategije testiranja je lista želja. Svaki atribut kvaliteta mora imati definisan metod merenja: koji alat pokreće test, kada se pokreće i ko pregleda rezultate.

5. Ignorisanje praćenja duga kvaliteta. Kada savetodavni kriterijumi padnu pri release-u, QRD treba da dokumentuje nedostatak i plan za njegovo rešavanje. Bez ovoga, dug kvaliteta se neprimetno akumulira.

Resursi

• QRD šabloni — spremni za korišćenje
• QRD generator prompt — napravite QRD koristeći AI
• SRD — kompletan vodič — specifikacija softverskih zahteva
• FRD — kompletan vodič — specifikacija funkcionalnog ponašanja
• Navigator prompt — pronađite pravi tip dokumenta