SRS (specifikacija zahteva za softver): kompletan vodič i šabloni

SRD, ili Software Requirements Document (poznat i kao SRS — Software Requirements Specification), predstavlja inženjerski nacrt za izgradnju softvera. On definiše šta softver mora da radi, kako mora da funkcioniše, pod kojim ograničenjima radi i kako se njegove komponente uklapaju. Tamo gde PRD govori produktnom timu šta da gradi, a FRD specificira ponašanje sistema, SRD daje inženjerima kompletnu tehničku sliku koja im je potrebna da pišu kod, projektuju arhitekturu i planiraju testiranje.

SRD odgovara na jedno pitanje: ako neko preda ovaj dokument razvojnom timu bez ikakvog drugog konteksta, da li bi mogli da izgrade sistem?

Key insight

SRD je najobuhvatniji dokument zahteva u celom lancu. Kombinuje funkcionalno ponašanje (šta sistem radi), nefunkcionalna ograničenja (koliko dobro to radi), arhitekturu (kako je izgrađen) i modele podataka (šta skladišti). To je jedini izvor istine za inženjerski tim.

Ko piše i za koga

Vlasnik SRD-a je obično sistemski arhitekta, tehnički lider, viši inženjer ili sistemski analitičar — neko ko razume i poslovni domen i tehničku implementaciju.

Key insight

Za razliku od BRD-a (čitaju ga rukovodioci) ili PRD-a (čita ga produktni tim), SRD je pisan za inženjere. Njegov jezik je tehnički, zahtevi su dovoljno konkretni da se po njima može kodirati, a nefunkcionalne specifikacije su merljive.

Kada je SRD potreban — a kada nije

SRD je potreban kada:

• Projekat uključuje više inženjerskih timova ili eksterne izvođače kojima je potrebna zajednička tehnička specifikacija
• Regulatorni ili compliance zahtevi podrazumevaju reviziju i praćenje zahteva (zdravstvo, finansije, državne institucije)
• Sistem ima značajne nefunkcionalne zahteve — SLO performansi, bezbednosne standarde, politike čuvanja podataka
• Potreban je formalan ugovor između zainteresovanih strana i inženjerskog tima o tome šta će biti isporučeno
• Sistem se integriše sa više eksternih servisa i ugovori o podacima moraju biti definisani unapred

SRD nije potreban kada:

• Mali cross-functional tim radi u kratkim sprintovima sa kontinuiranom isporukom — user story-ji sa kriterijumima prihvatanja su dovoljni
• PRD i FRD već pokrivaju funkcionalne i nefunkcionalne zahteve dovoljno detaljno za tim
• Gradi se prototip ili proof of concept gde bi formalne specifikacije usporile učenje
• Projekat je jednoservisni, jednotimski sa direktnim pristupom zainteresovanim stranama

U praksi, regulisane industrije (bankarstvo, zdravstvo, odbrana, državni ugovori) gotovo uvek zahtevaju formalan SRD. Startapi i agilni produktni timovi često uključuju SRD-nivo detalja u svoj PRD ili FRD.

Šta SRD sadrži

Osnovne sekcije

Dobro strukturiran SRD prati IEEE 830 standard (ažuriran kao ISO/IEC/IEEE 29148) sa modernim prilagođavanjima. Obično uključuje osam sekcija:

1. Uvod — svrha dokumenta, opseg softvera, definicije i akronimi, reference na povezane dokumente (PRD, BRD, arhitekturna dokumentacija) i pregled organizacije dokumenta. Uvod postavlja jasne granice: šta ovaj SRD pokriva i šta eksplicitno isključuje.

2. Opšti opis — perspektiva proizvoda (kako se ovaj softver uklapa u veći sistem ili zamenjuje postojeći sistem), klase korisnika i njihove karakteristike, okruženje za rad (pregledači, uređaji, OS, cloud provajderi), ograničenja dizajna i implementacije (tehnološki stek, regulatorni zahtevi, budžet), pretpostavke i zavisnosti.

3. Funkcionalni zahtevi — detaljni opisi onoga što sistem radi. Svaki zahtev ima jedinstven ID, opis koristeći „shall” (obavezno) ili „should” (opciono), ulaze, izlaze, poslovna pravila i stanja greške. Ova sekcija može referisati FRD direktno ili uključiti njegov sadržaj.

4. Nefunkcionalni zahtevi — merljivi ciljevi performansi, bezbednosti, skalabilnosti, pouzdanosti, upotrebljivosti i održivosti. Svaki zahtev je kvantifikovan: „The system shall respond to 95% of API requests within 200ms” umesto „The system shall be fast.”

5. Zahtevi za eksternim interfejsima — kako sistem komunicira sa korisnicima (UI specifikacije), sa drugim internim sistemima (API, redovi poruka, event bus), sa eksternim servisima (integracije sa trećim stranama) i sa hardverom (ako je primenljivo). Protokoli, formati podataka, metode autentifikacije i obrada grešaka za svaki interfejs.

6. Zahtevi za podacima — modeli podataka (entiteti, odnosi, ograničenja), rečnik podataka (imena polja, tipovi, pravila validacije), politike čuvanja i arhiviranja podataka, planovi migracije podataka iz postojećih sistema i zahtevi za privatnost/compliance u rukovanju podacima.

7. Arhitektura sistema — dijagrami arhitekture visokog nivoa, opisi komponenti, odluke o tehnološkom steku, topologija deployovanja, zahtevi za observability (logovanje, monitoring, alerting) i API ugovori. Ova sekcija premošćuje jaz između zahteva i implementacije.

8. Dodaci — rečnik pojmova, dijagrami slučajeva korišćenja, dijagrami stanja, wireframe-ovi, dnevnik promena, otvorena pitanja (TBD stavke) i stranica za potpis.

Key insight

Vrednost SRD-a dolazi iz sekcija 4-7. Funkcionalni zahtevi (sekcija 3) se poklapaju sa FRD-om. Ono što SRD čini posebnim je to što dodaje nefunkcionalne specifikacije, ugovore o interfejsima, modele podataka i arhitekturu — tehnički kontekst koji je programerima potreban izvan samog opisa „kako se sistem ponaša”.

Pisanje nefunkcionalnih zahteva: pravilo merljivosti

Nefunkcionalni zahtevi su mesto gde većina SRD-ova pada. Nejasni NFR-ovi proizvode nemerljive rezultate.

Loši NFR-ovi:

• „The system shall be fast” — koliko brz?
• „The system shall be secure” — od čega?
• „The system shall scale” — do kog obima?

Dobri NFR-ovi:

Pravilo: ako ne možete da napišete test koji verifikuje da li zahtev prolazi ili pada, prepišite ga.

SRD i IEEE 830 / ISO 29148 standard

IEEE 830 standard (1998, sada zamenjen sa ISO/IEC/IEEE 29148:2018) uspostavio je kanonsku SRS strukturu. Većina modernih SRD-ova prati njegov duh uz prilagođavanje aktuelnim praksama:

Standard ostaje vredan kao kontrolna lista: da li ste pokrili funkcionalne zahteve? Nefunkcionalne? Interfejse? Podatke? Ograničenja? Format isporuke se promenio; intelektualna strogost nije.

Varijante SRD-a

Agile SRS je varijanta dizajnirana za timove koji rade u sprintovima i kojima je potreban lakši, živi dokument zahteva.

SRD i drugi dokumenti zahteva

SRD zauzima tehničku stranu u lancu dokumenata zahteva:

MRD → BRD → PRD → FRD → SRD

Odnos između FRD-a i SRD-a je najčešće zbunjujući:

• FRD se fokusira na vidljivo ponašanje — šta korisnici i sistemi vide kada interaguju sa softverom. Opisuje ulaze, izlaze, tokove rada i poslovna pravila.
• SRD uključuje ponašanje (često referišući ili ugrađujući FRD) plus nefunkcionalne, arhitekturne i specifikacije podataka koje su programerima potrebne da korektno izgrade sistem.

U nekim organizacijama FRD i SRD se kombinuju u jedan dokument. U drugim, FRD hrani SRD kao njegova komponenta.

Tipične greške

1. Kopiranje PRD-a. SRD nije PRD sa dodanim tehničkim žargonom. PRD definiše šta graditi iz produktne perspektive. SRD specificira kako to izgraditi iz inženjerske perspektive, uključujući ciljne performanse, bezbednosne kontrole i arhitekturne odluke koje PRD ne pokriva.

2. Izostavljanje nefunkcionalnih zahteva. Funkcionalni zahtevi dobijaju pažnju jer se mapiraju na funkcionalnosti. Nefunkcionalni zahtevi (performanse, bezbednost, skalabilnost) bivaju otkriveni u produkciji kada sistem padne pod opterećenjem ili bude kompromitovan. SRD ovo sprečava specificiranjem NFR-ova unapred.

3. Pisanje zahteva koji se ne mogu verifikovati. Svaki zahtev treba da ima odgovarajući test. „The system shall be reliable” nema test. „The system shall recover from a database failover within 30 seconds” ima jasan test.

4. Tretiranje SRD-a kao jednokratnog dokumenta. Zahtevi evoluiraju. SRD koji je napisan jednom i nikada ažuriran postaje teret — timovi prestaju da ga čitaju jer više ne odražava stvarnost. Čuvajte ga u sistemu za kontrolu verzija zajedno sa kodom.

5. Specificiranje implementacije umesto zahteva. „The system shall use PostgreSQL 16” je odluka o implementaciji, a ne zahtev. „The system shall persist data in a relational database with ACID guarantees and support for full-text search” je zahtev koji ostavlja prostor za izbor tehnologije.

6. Bez praćenja. Svaki funkcionalni zahtev treba da se može pratiti unazad do poslovne potrebe (BRD/PRD) i unapred do test slučaja. Bez praćenja ne možete da odgovorite: „Zašto ovaj zahtev postoji?” ili „Kako znamo da radi?”

Trend 2026: SRD kao kontekst za AI agente za razvoj

U 2026. godini SRD služi inženjerima i AI agentima za kodiranje istovremeno. AI agenti u alatima poput Cursor-a, Claude Code-a i GitHub Copilot Workspace-a koriste strukturirane dokumente zahteva za generisanje koda, testova i arhitekturnog scaffolding-a.

Ovo menja prakse vezane za SRD na tri načina:

• SRD se čuva u repozitorijumu kao markdown fajlovi, a ne u eksternim alatima, tako da AI agenti mogu da čitaju zahteve zajedno sa kodom.
• Nefunkcionalni zahtevi uključuju eksplicitne kriterijume prihvatanja koji se direktno prevode u automatizovane testove.
• Sekcije arhitekture uključuju API ugovore u mašinski čitljivim formatima (OpenAPI, AsyncAPI) koje AI agenti koriste za generisanje boilerplate koda i integracijskih testova.

Sadržaj SRD-a se ne menja — njegov format i lokacija se prilagođavaju da budu upotrebljivi i za ljude i za mašine.

Resursi

• SRD šabloni — standardni i agilni, spremni za korišćenje
• SRD generator prompt — napravite SRD koristeći AI
• Agile SRS — lagana varijanta za agilne timove
• FRD — kompletan vodič — specifikacija ponašanja koja hrani SRD
• PRD vs BRD vs FRD — poređenje dokumenata zahteva
• Navigator prompt — pronađite pravi tip dokumenta