Agile SRS: lagana specifikacija zahteva za iterativne timove

Agile SRS prilagođava tradicionalnu Software Requirements Specification iterativnom razvoju. Umesto monolitnog dokumenta napisanog pre početka razvoja, to je živi, modularni artefakt koji evoluira sa svakim sprintom. Osnovna intelektualna strogost ostaje — funkcionalni zahtevi, nefunkcionalni ciljevi, ugovori o interfejsima — ali format je lakši, kadenca ažuriranja je brža i dokument živi u repozitorijumu zajedno sa kodom.

Key insight

Agile SRS nije „manje rigorozan” od tradicionalnog SRD-a. Pokriva isti teren — funkcionalne, nefunkcionalne zahteve, podatke, interfejse — ali ih organizuje po funkcionalnosti ili modulu i ažurira kontinuirano umesto da ga tretira kao završeni artefakt.

Kada koristiti Agile SRS

Koristite Agile SRS kada:

• Vaš tim radi u sprintovima ili kontinuiranoj isporuci i potrebni su mu zahtevi koji evoluiraju sa proizvodom
• Proizvod se gradi iterativno — ne znate sve zahteve unapred
• Potrebno vam je dovoljno strukture da uskladite više inženjera bez opterećenja punog IEEE 830 dokumenta
• Dokument mora biti čitljiv za AI agente za kodiranje zajedno sa kodom
• Startap ste ili kompanija u fazi rasta gde je brzina bitna, ali tehnički dug od nedostajućih specifikacija predstavlja realan rizik

Tradicionalni SRD je bolji kada:

• Regulatorni compliance zahteva formalan, verzionisan, potpisan dokument
• Projekat je ugovor fiksnog opsega sa eksternim izvođačem
• Više organizacija treba zajedničku, stabilnu specifikaciju pre početka rada

Struktura Agile SRS-a

Agile SRS je organizovan po funkcionalnosti ili modulu, a ne po tipu sekcije. Svaki modul funkcionalnosti sadrži sopstvene zahteve, kriterijume prihvatanja i tehničke specifikacije.

Dokument na nivou projekta

Jedan pregled pokriva cross-cutting aspekte:

docs/srs/
├── overview.md          ← nivo projekta: opseg, NFR-ovi, arhitektura
├── auth/
│   ├── requirements.md  ← funkcionalni zahtevi za autentifikaciju
│   └── api.md           ← API ugovor za auth endpoint-e
├── payments/
│   ├── requirements.md
│   └── api.md
└── notifications/
    ├── requirements.md
    └── api.md

Overview fajl

Overview fajl pokriva:

1. Opseg proizvoda — jedan pasus, šta softver radi i šta ne radi
2. Klase korisnika — uloge i njihovi nivoi pristupa
3. Nefunkcionalni zahtevi — ciljevi performansi, bezbednosti, dostupnosti (primenjuju se globalno)
4. Pregled arhitekture — dijagram visokog nivoa, tehnološki stek, model deployovanja
5. Ograničenja — regulatorna, budžetska, vremenska, tehnološka ograničenja
6. Otvorena pitanja — stavke označene kao TBD sa vlasnicima i ciljnim datumima

Modul funkcionalnosti

Svaki modul funkcionalnosti pokriva:

1. Kontekst — koji korisnički problem rešava, link na relevantnu sekciju PRD-a ili user story
2. Funkcionalni zahtevi — sa ID-jevima, koristeći „shall/should”, povezani sa kriterijumima prihvatanja
3. Model podataka — entiteti i polja specifični za ovu funkcionalnost
4. API ugovor — endpoint-i, šeme zahteva/odgovora, kodovi grešaka (ako je primenljivo)
5. Granični slučajevi i obrada grešaka — šta se dešava kada stvari krenu naopako

Kako održavati Agile SRS

Tok rada u sprintu

1. Planiranje sprinta: identifikujte koje SRS module planirani rad utiče. Ako funkcionalnost nema modul, kreirajte ga sa barem funkcionalnim zahtevima i kriterijumima prihvatanja.
2. Tokom sprinta: inženjeri ažuriraju SRS modul kako otkrivaju granične slučajeve, usavršavaju modele podataka ili prilagođavaju API ugovore. Promene u SRS-u su deo istog pull request-a kao i kod.
3. Pregled sprinta: potvrdite da SRS modul odgovara onome što je izgrađeno. Ako se opseg promenio tokom sprinta, ažurirajte zahteve i kriterijume prihvatanja da odražavaju stvarnost.

Kontrola verzija

Agile SRS živi u Git-u. Promene se pregledaju u pull request-ovima zajedno sa kodom. To obezbeđuje:

• Istoriju — ko je promenio koji zahtev i kada
• Pregled — tehnički lideri odobravaju promene zahteva kao i promene koda
• Praćenje — commit-ovi povezuju ažuriranja zahteva sa kodom koji ih implementira

Kada deliti a kada spajati

• Podelite kada modul naraste preko 200 linija ili pokriva više od jednog bounded konteksta
• Spojite kada dva modula imaju toliko preklapanja da njihovo odvojeno održavanje stvara duplikaciju

Agile SRS naspram user story-ja

Agile SRS ne zamenjuje user story-je. Oni služe različitim svrhama:

User story kaže „šta graditi sledeće”. Agile SRS modul kaže „kako to radi, šta skladišti i šta se dešava kada stvari krenu naopako”.

Tipične greške

1. Pisanje Agile SRS-a koji je zapravo tradicionalni SRD u Git folderu. Ako dokument ima 300 stranica i niko ga ne ažurira posle prvog sprinta, to nije agile — to je waterfall dokument sa novom etiketom.

2. Preskakanje nefunkcionalnih zahteva. Agilni timovi ponekad odlažu NFR-ove jer imaju osećaj da „ćemo optimizovati kasnije”. Zahtevi za performanse, bezbednost i skalabilnost pripadaju overview fajlu od prvog dana.

3. Nema vlasnika. Ako niko nije odgovoran za održavanje SRS-a aktuelnim, on zastari u roku od nekoliko nedelja. Dodelite vlasnika modula — obično inženjera koji najbolje poznaje domen.

4. Dupliranje informacija. Ako je API ugovor već definisan u OpenAPI specifikaciji, referišite ga umesto da ga kopirate u SRS. SRS treba da bude mapa, a ne druga kopija teritorije.

Resursi

• SRD — kompletan vodič — tradicionalni SRD punog formata
• SRD šabloni — standardni i agilni šabloni
• SRD generator prompt — napravite SRD koristeći AI
• FRD — kompletan vodič — specifikacija funkcionalnog ponašanja
• Navigator prompt — pronađite pravi tip dokumenta