Kako napisati FRD: vodič za funkcionalne zahteve i primeri

FRD, ili Functional Requirements Document, odgovara na pitanje koje sledi nakon definisanja proizvoda: kako sistem treba da se ponaša. On prevodi produktne zahteve u konkretne, testabilne opise ponašanja sistema — ulaze, izlaze, poslovna pravila, obradu grešaka i tokove podataka.

Tamo gde PRD kaže „korisnici moraju moći da resetuju lozinku”, FRD opisuje tačan scenario: korisnik klikne „Zaboravljena lozinka”, unese email, dobije token važeći 30 minuta, postavi novu lozinku koja zadovoljava pravila složenosti i vidi ekran potvrde. FRD takođe opisuje šta se dešava kada email nije pronađen, kada token istekne i kada nova lozinka ne prođe validaciju.

Key insight

FRD je ugovor između proizvoda i inženjeringa. Proizvod definiše šta graditi (PRD); FRD definiše kako sistem treba da se ponaša da bi inženjeri mogli da ga izgrade, a QA da ga verifikuje.

Ko piše i za koga

Vlasnik FRD-a je obično poslovni analitičar, tehnički produkt menadžer ili sistemski analitičar — neko ko može da prevede poslovne potrebe u precizne opise ponašanja sistema.

Key insight

Za razliku od BRD-a (čitaju ga rukovodioci) ili PRD-a (čita ga produktni tim), FRD je tehnički dokument. Njegovi primarni čitaoci su oni koji će graditi i testirati sistem.

Kada je FRD potreban — a kada nije

FRD je potreban kada:

• Sistem ima složena poslovna pravila koja moraju biti specificirana pre početka razvoja
• Više timova ili eksternih izvođača treba nedvosmislen opis ponašanja sistema
• Regulatorni ili compliance zahtevi podrazumevaju praćenje i reviziju zahteva
• Projekat uključuje integraciju sa eksternim sistemima gde ugovori o podacima moraju biti definisani unapred
• QA-u je potrebna formalna osnova za razvoj test slučajeva

FRD nije potreban kada:

• Mali agilni tim poseduje ceo proizvod i radi na osnovu user story-ja sa kriterijumima prihvatanja
• PRD je dovoljno detaljan da inženjeri mogu direktno izvesti funkcionalno ponašanje
• Koristi se AI-Optimized PRD sa fazama i testabilnim rezultatima — PRD već obavlja ulogu lakog FRD-a
• Projekat je prototip ili proof of concept gde bi formalne specifikacije usporile učenje

U praksi, odluka zavisi od veličine tima i organizacione složenosti. Startap od pet ljudi retko piše FRD. Banka koja gradi sistem za obradu plaćanja piše ga uvek.

Šta FRD sadrži

Osnovne sekcije

Dobro strukturiran FRD obično uključuje sedam sekcija:

1. Uvod — svrha dokumenta, opseg sistema, definicije pojmova i reference na povezane dokumente (PRD, BRD, arhitekturni dokumenti). Uvod postavlja granice: šta ovaj FRD pokriva i šta eksplicitno isključuje.

2. Funkcionalni zahtevi — srce dokumenta. Svaki zahtev opisuje konkretno ponašanje sistema sa jedinstvenim identifikatorom, opisom, ulazima, izlazima, poslovnim pravilima i prioritetom.

   Dobar funkcionalni zahtev zadovoljava pet kriterijuma:

   • Konkretan — nema prostora za tumačenje
   • Merljiv — može se testirati da li je ispunjen
   • Atomičan — jedno ponašanje po zahtevu
   • Praćen — povezan sa poslovnim zahtevom ili user story-jem preko identifikatora
   • Prioritizovan — must-have, should-have ili nice-to-have

   Konvencija: „shall” za obavezne zahteve, „should” za opcione. „The system shall validate the email format before sending the reset link” — nedvosmisleno. „The system should support SSO” — ostavlja prostor za pregovore o opsegu.

3. Nefunkcionalni zahtevi — ciljne performanse, bezbednosni standardi, SLA dostupnosti, očekivanja skalabilnosti i zahtevi pristupačnosti. Ova sekcija opisuje koliko dobro sistem mora da radi, a ne šta radi.

4. Zahtevi za podacima — modeli podataka, odnosi između entiteta, rečnik podataka (imena polja, tipovi, ograničenja, pravila validacije) i politike čuvanja podataka. Ova sekcija sprečava situaciju kada programeri usred sprinta otkriju da kritično polje nikada nije definisano.

5. Zahtevi za interfejsima — kako sistem komunicira sa korisnicima (UI specifikacije), sa drugim internim sistemima (API, redovi poruka) i sa eksternim servisima (integracije sa trećim stranama, tokovi podataka). Za projekte sa mnogo API-ja, ova sekcija može narasti do zasebnog API FRD-a.

6. Kriterijumi prihvatanja — testabilni uslovi koji definišu kada je svaki funkcionalni zahtev ispunjen. Kriterijumi prihvatanja povezuju FRD sa planom testiranja: ako kriterijum prođe, zahtev je ispunjen.

7. Dodaci — wireframe-ovi, UI mockup-ovi, dijagrami tokova, dijagrami stanja, rečnik pojmova i dnevnik promena. Vizuelni materijali se smeštaju ovde umesto inline — oni podržavaju zahteve ali ne treba da zamene precizne tekstualne opise.

Key insight

Razlika između dobrog i osrednjeg FRD-a je u sekciji 2: samim funkcionalnim zahtevima. Nejasni zahtevi („sistem treba elegantno da obrađuje greške”) proizvode nejasne implementacije. Konkretni zahtevi („sistem treba da prikaže kod greške E-401 sa porukom ‘Sesija istekla’ i preusmeri na stranicu za prijavu u roku od 3 sekunde”) proizvode testabilan kod.

Pisanje funkcionalnih zahteva: konvencija identifikatora

Svaki zahtev u FRD-u dobija jedinstveni identifikator. To obezbeđuje praćenje — od poslovnog zahteva do funkcionalnog zahteva i dalje do test slučaja.

Uobičajeni format:

Kolona „Izvor” povezuje svaki zahtev sa PRD-om, BRD-om ili bezbednosnom politikom. Ovo praćenje je važno u regulisanim industrijama gde revizori moraju da potvrde da je svaka poslovna potreba pokrivena funkcionalnim zahtevom, a svaki funkcionalni zahtev — test slučajem.

Varijante FRD-a

API FRD je varijanta za sisteme gde je primarni interfejs API a ne korisnički interfejs.

FRD i drugi dokumenti zahteva

FRD zauzima tehničku stranu u lancu dokumenata zahteva:

MRD → BRD → PRD → FRD → SRD

FRD prima ulazne podatke od PRD-a (ili direktno od BRD-a u scenarijima outsourcing-a) i generiše izlazne podatke koje programeri koriste za pisanje koda, a QA za pisanje testova. U nekim organizacijama FRD i SRS se kombinuju u jedan dokument.

• PRD → FRD: PRD kaže „korisnici mogu resetovati lozinku”. FRD definiše svaki korak, validaciju, stanje greške i granični slučaj tog scenarija.
• BRD → FRD (outsourcing): Kada eksterni izvođač gradi sistem, klijent daje BRD + FRD. FRD zamenjuje PRD jer izvođaču nije potrebna produktna strategija — potrebne su mu tačne specifikacije ponašanja.

Tipične greške

1. Mešanje zahteva sa dizajnom. „Dugme za reset mora biti plavo, visine 44px, pozicionirano u gornjem desnom uglu” — to je dizajn specifikacija, a ne funkcionalni zahtev. FRD opisuje ponašanje; dizajn sistem opisuje izgled.

2. Netestabilni zahtevi. „Sistem treba da bude user-friendly” ne može se testirati. „Sistem treba da dozvoli novom korisniku da završi registraciju za manje od 3 minuta” — može se testirati.

3. Propuštena stanja greške. Osnovni scenario (happy path) je lako specificirati. FRD dokazuje svoju vrednost pokrivanjem onoga što se dešava kada stvari krenu naopako: nevažeći unos, istekle sesije, mrežni kvarovi, konkurentne izmene i ograničenja brzine zahteva.

4. Bez identifikatora zahteva. Bez identifikatora zahteve nije moguće povezati sa test slučajevima, zahtevi za promene ne mogu referisati konkretne stavke, a analiza uticaja promena postaje nagađanje.

5. FRD napisan prerano. FRD napisan pre odobravanja PRD-a rizikuje specificiranje ponašanja za funkcionalnosti koje će biti izbačene. FRD sledi PRD — ne obrnuto.

Trend 2026: FRD kao ulazni podaci za AI agente za razvoj

U 2026. godini FRD služi dvostrukoj svrsi. Inženjeri ga i dalje čitaju, ali AI agenti za razvoj (Cursor, Claude Code, GitHub Copilot Workspace) ga takođe koriste kao strukturisane instrukcije.

To menja način pisanja FRD-a:

• Zahtevi se čuvaju u markdown fajlovima u repozitorijumu, a ne u Confluence-u ili Google Docs-u, tako da AI agenti mogu da ih čitaju zajedno sa kodom.
• Svaki zahtev uključuje kriterijume prihvatanja kao testabilne uslove koje AI agenti mogu direktno pretvoriti u test slučajeve.
• FRD i tehnička specifikacija se sve više spajaju u jedan dokument po funkcionalnosti, smanjujući prebacivanje konteksta kako za ljude tako i za AI agente.

Trend ne menja sadržaj FRD-a — menja gde se čuva i kako je formatiran.

Resursi

• FRD šabloni — standardni i API, spremni za korišćenje
• FRD generator prompt — napravite FRD koristeći AI
• API FRD — FRD varijanta za API proizvode
• PRD vs BRD vs FRD — trostruko poređenje
• PRD — kompletan vodič — dokument koji hrani FRD
• Navigator prompt — pronađite pravi tip dokumenta