Poglavlje 3: Zahtjevi – šta sistem treba da radi
Priča za početak. U ponedjeljak, 26. oktobra 1992. godine, Hitna pomoć grada Londona pustila je u rad novi računarski sistem za upućivanje vozila. Do tada su dispečeri primali poziv, zapisivali adresu na papir, a papir je putovao do kolege koji je na velikoj karti tražio najbliže slobodno vozilo. Novi sistem trebao je to raditi sam: primiti adresu, izračunati koje je vozilo najbliže i poslati ga. Već prvog dana sistem se zagušio. Sistem je pretpostavljao da uvijek tačno zna gdje je koje vozilo i šta posada radi, a posade nisu uvijek pritiskale dugmad onim redom koji je sistem očekivao. Vozila su slata pogrešno, pozivi su se gubili, a ljudi su na hitnu pomoć čekali i satima. Istražna komisija u izvještaju iz februara 1993. zaključila je da sistem nije bio spreman: softver je bio nedovršen i nedovoljno testiran, a dispečeri i posade nisu imali povjerenja u njega. Direktor službe je podnio ostavku. Najdublji uzrok nije bio u kodu, nego u zahtjevima: sistem je projektovan za svijet kakav je trebao biti, a ne za svijet kakav jeste.
U poglavlju 2 odabrali smo za DeliveryApp Scrum i napravili backlog od dvanaestak stavki. Stavke su za sada samo naslovi, kao „izračunati dostavu”. Ovo poglavlje uči kako se od naslova dođe do zahtjeva: rečenice koja tačno kaže šta sistem mora raditi i kako ćemo provjeriti da to radi. Prvo vidimo ko sve ima pravo da traži nešto od sistema i kako ih pitamo. Zatim razlikujemo vrste zahtjeva i učimo šta čini zahtjev dobrim. Na kraju pišemo korisničke priče s kriterijima prihvatanja i slažemo ih po važnosti. Na praktičnoj nastavi vodimo intervju s „vlasnikom restorana” i pišemo dvanaest korisničkih priča za DeliveryApp.
Literatura. Osnovna literatura predmeta:
- B. Popović, K. Kuk: Informacioni sistemi, Kriminalističko-policijski univerzitet, Beograd, 2017.
- J. S. Valacich, J. F. George: Modern Systems Analysis and Design, 9th ed., Pearson, 2020.
- L. Jelenković: Sustavi za rad u stvarnom vremenu – skripta, FER, Zagreb, 2015.
- D. Milićev: Programiranje u realnom vremenu – skripta, Beograd, 2002.
- V. Kovačević, M. Popović: Sistemska programska podrška u realnom vremenu 1, FTN, Novi Sad, 2013.
Riječi ovog poglavlja.
- Zahtjev – rečenica koja kaže šta sistem mora raditi ili kakav mora biti.
- Zainteresovana strana (stakeholder) – svako koga se sistem tiče: ko ga plaća, koristi, održava ili trpi njegove posljedice.
- Prikupljanje zahtjeva – posao otkrivanja šta zainteresovanim stranama zaista treba.
- Funkcionalni zahtjev – šta sistem radi (npr. računa dostavu).
- Nefunkcionalni zahtjev – kakav sistem mora biti dok to radi (brz, siguran, dostupan, lak za upotrebu).
- Ograničenje – uslov koji tim ne bira, nego mora poštovati (zakon, budžet, rok, postojeći sistem).
- Korisnička priča – kratak zahtjev iz ugla korisnika: „Kao …, želim …, da bih …”.
- Kriterij prihvatanja – provjerljiv uslov koji kaže kada je priča ispunjena.
- Dato–Kada–Tada (Given–When–Then) – oblik kriterija: početno stanje, radnja, očekivani rezultat.
- MoSCoW – podjela zahtjeva po važnosti: mora, trebalo bi, moglo bi, neće ovaj put.
- Sljedivost – mogućnost da se za svaki zahtjev vidi odakle je došao i koji ga test provjerava.
- Specifikacija zahtjeva (SRS, software requirements specification) – dokument sa svim zahtjevima sistema.
Ciljevi poglavlja. Nakon poglavlja možete: nabrojati zainteresovane strane DeliveryApp i smjestiti ih u matricu uticaja i interesa; izabrati tehniku prikupljanja zahtjeva i voditi kratak intervju s otvorenim pitanjima; razlikovati šta korisnik traži od onoga što mu treba; razlikovati poslovne, korisničke i sistemske, te funkcionalne i nefunkcionalne zahtjeve; prepoznati loš zahtjev i prepraviti ga u provjerljiv; izračunati koliko zastoja dozvoljava dostupnost od 99,5 %; napisati korisničku priču koja zadovoljava INVEST; napisati kriterije prihvatanja u obliku Dato–Kada–Tada; složiti zahtjeve po MoSCoW i napraviti matricu sljedivosti; opisati kako se upravlja promjenom zahtjeva.
Plan poglavlja – Sedmica 3: tri časa teorije i tri časa praktične nastave
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 3.1–3.3 Zainteresovane strane, tehnike, šta treba | Matrica uticaja i interesa; „pet puta zašto” |
| Teorija 2 | 3.4–3.6 Vrste zahtjeva i dobar zahtjev | „Sistem mora biti brz” → NZ-1; 99,5 % = 3,6 h |
| Teorija 3 | 3.7–3.10 Korisničke priče, kriteriji, MoSCoW, promjene | Priča za dostavu s tri kriterija |
| Praksa 1–3 | Intervju u paru; 12 priča na GitHubu; matrica sljedivosti | Priče s oznakama MoSCoW |
Dio 1 – Ko traži i kako pitamo
3.1 Zainteresovane strane
Prvo pitanje nije „šta sistem treba raditi”, nego „koga treba pitati”. Zainteresovana strana (engleski stakeholder) je svako koga se sistem tiče: ko ga plaća, ko ga koristi, ko ga održava, ko mora odobriti da radi, pa i ko samo trpi njegove posljedice. Ako neku stranu zaboravimo, njen zahtjev otkrićemo tek kad sistem radi, a tada je skupo.
Za DeliveryApp spisak izgleda ovako:
| Zainteresovana strana | Šta joj je najvažnije |
|---|---|
| Udruženje ugostitelja (naručilac) | da se uloženi novac vrati; da svi restorani budu zadovoljni |
| Vlasnik restorana | manje izgubljenih narudžbi; izvještaj na kraju mjeseca |
| Konobar i kuhar | da narudžbu vide jasno, bez prepisivanja |
| Kupac | brzo naručivanje, tačna cijena, da zna kada stiže hrana |
| Dostavljač | tačna adresa, pametan redoslijed vožnje, da zna koliko je zaradio |
| Administrator DeliveryApp | da lako doda restoran i riješi žalbu |
| Firma za plaćanje karticom | da se poštuju njena pravila sigurnosti |
| Poreska uprava | ispravni fiskalni računi |
| Agencija za zaštitu ličnih podataka | da se adrese i telefoni kupaca čuvaju po zakonu |
| Komšije restorana | da dostavljači ne parkiraju skutere na trotoaru |
Posljednji red nije šala. Zainteresovana strana može biti i neko ko sistem nikad neće koristiti, a ipak može zaustaviti projekat (npr. opština koja zabrani parkiranje).
Matrica uticaja i interesa
Nemaju sve strane jednaku težinu. Korisna je podjela po dvije osobine: koliki uticaj strana ima na projekat (može li ga zaustaviti, promijeniti, finansirati) i koliki je njen interes (koliko je se sistem tiče u svakodnevici).
| Mali interes | Veliki interes | |
|---|---|---|
| Veliki uticaj | držati zadovoljnim (poreska uprava, agencija za podatke) | blisko sarađivati (udruženje, vlasnici restorana) |
| Mali uticaj | pratiti (komšije) | redovno informisati (kupci, dostavljači, kuhari) |
Strane u gornjem desnom polju pitamo često i detaljno. Strane u gornjem lijevom ne zovemo na svaki sastanak, ali njihove propise moramo znati od prvog dana.
Na času. Ko je u priči o Hitnoj pomoći Londona bio zainteresovana strana, a možda nije dovoljno pitan? (Dispečeri i posade vozila, koji su znali kako se posao zaista radi na terenu.)
Ukratko.
- Zainteresovana strana je svako koga se sistem tiče: ko ga plaća, koristi, održava, odobrava ili trpi posljedice.
- Zaboravljena strana donosi zahtjev tek kad sistem radi, kad je skupo.
- Matrica uticaja i interesa pokazuje koga pitati često, koga držati zadovoljnim, a koga samo informisati.
3.2 Tehnike prikupljanja zahtjeva
Zahtjevi ne leže negdje gotovi da ih pokupimo. Ljudi često ne znaju reći šta im treba, ili kažu rješenje umjesto problema. Zato analitičar koristi više tehnika, a svaka otkriva nešto drugo.
| Tehnika | Kako izgleda | Dobra za | Pazi na |
|---|---|---|---|
| Intervju | razgovor jedan na jedan, 30–60 minuta | detalje, razloge, osjetljive teme | ljudi kažu ono što misle da želite čuti |
| Upitnik | ista pitanja za mnogo ljudi | brojke („koliko često naručujete?”) | ne otkriva „zašto” |
| Posmatranje | analitičar provede smjenu uz konobara | stvarni posao, prečice, probleme koje niko ne pominje | ljudi rade drugačije kad ih neko gleda |
| Radionica | svi važni ljudi u jednoj sobi, sa slikama i papirićima | dogovor, sukobe između strana | glasni ljudi preglasaju tihe |
| Analiza dokumenata | čitanje jelovnika, računa, zakona, starih papirića narudžbi | pravila, polja koja moraju postojati | dokument može biti zastario |
| Prototip | grubi crtež ili klikabilan ekran koji ljudi probaju | reakciju na „ovako bi izgledalo” | ljudi misle da je sistem gotov |
Za DeliveryApp bi dobar plan bio: intervju s vlasnikom svakog restorana, jedno podne posmatranja u kuhinji Picerije R-1, kratak upitnik za 50 stalnih kupaca, i radionica s vlasnicima kad imamo prve crteže ekrana.
Kako voditi intervju
Intervju je najčešća tehnika i najlakše se pokvari. Nekoliko pravila:
- Pripremite se. Znajte ko je sagovornik i šta radi; imajte 8–10 pitanja, ali ne čitajte ih kao anketu.
- Otvorena pitanja prije zatvorenih. Otvoreno pitanje traži priču: „Opišite mi jedno obično podne u kuhinji.” Zatvoreno traži da ili ne, ili broj: „Koliko narudžbi primite između 12 i 14 sati?” Otvorena otkrivaju probleme, zatvorena ih mjere.
- Pitajte za primjer. „Sjetite se posljednje narudžbe koja je pošla naopako. Šta se desilo?” Konkretan primjer je vredniji od opšteg mišljenja.
- Ne predlažite rješenje. Pitanje „Biste li htjeli da vam aplikacija štampa narudžbu?” navodi na odgovor „da”. Bolje: „Kako kuhar sada saznaje šta treba spremiti?”
- Zapišite i provjerite. Na kraju ponovite glavne tačke svojim riječima („Ako sam dobro razumio, najveći problem je…”) i pošaljite kratak zapis sagovorniku.
Ukratko.
- Zahtjevi se otkrivaju intervjuom, upitnikom, posmatranjem, radionicom, analizom dokumenata i prototipom.
- Svaka tehnika otkriva nešto drugo, pa se kombinuju.
- Intervju počinje otvorenim pitanjima, traži konkretne primjere i ne predlaže rješenje.
3.3 Šta korisnik traži, a šta mu treba
Vlasnik Picerije R-1 na intervjuu kaže: „Hoću da mi aplikacija štampa svaku narudžbu na papir, kao fiskalna kasa.” To je zahtjev? Ne baš. To je rješenje koje je vlasnik smislio za problem koji nije rekao. Analitičar zato pita dalje, tehnikom koja se zove pet puta zašto (svaki odgovor dobije novo „zašto”, dok se ne dođe do uzroka):
- Zašto papir? – Da kuhar ima narudžbu pred sobom.
- Zašto mu treba pred sobom? – Jer ne može otvarati računar masnim rukama.
- Zašto bi otvarao računar? – Da vidi šta je sljedeće na redu.
- Zašto mu je to teško sada? – Jer narudžbe stižu na telefon konobara, pa ih konobar prepisuje.
- Zašto prepisuje? – Jer niko drugi ne vidi narudžbu.
Prava potreba je: kuhar mora vidjeti narudžbe redom, jasno, bez dodirivanja uređaja masnim rukama i bez prepisivanja. Slika 3.2 pokazuje taj put od traženog rješenja do potrebe. Štampač je jedno rješenje. Drugo je veliki ekran na zidu kuhinje na kojem se narudžbe redaju same, a kuhar ih označava gotovim laktom ili pedalom. Oba rješenja ispunjavaju potrebu; izbor je stvar cijene i navike. Da je analitičar samo zapisao „štampati narudžbu”, drugo rješenje se nikad ne bi razmotrilo.
Česta zabluda. „Korisnik zna šta želi, mi samo zapišemo.” Korisnik zna svoj problem bolje od bilo koga. Ali rješenje koje predloži ograničeno je onim što je već vidio. Posao analitičara je da razumije problem i da zajedno s korisnikom izabere rješenje.
Ukratko.
- Ljudi često kažu rješenje umjesto problema („štampaj narudžbu”).
- Tehnika „pet puta zašto” vodi od traženog rješenja do stvarne potrebe.
- Kad je potreba jasna, može se izabrati između više rješenja (štampač ili ekran u kuhinji).
Provjeri se.
- Ko je zainteresovana strana? – Svako koga se sistem tiče: ko ga plaća, koristi, održava, odobrava ili trpi posljedice.
- Zašto se otvorena pitanja postavljaju prije zatvorenih? – Otvorena otkrivaju probleme i priče, a zatvorena ih kasnije mjere.
- Šta je prava potreba iza zahtjeva „štampaj narudžbu”? – Kuhar mora vidjeti narudžbe redom, jasno i bez prepisivanja.
Dio 2 – Vrste zahtjeva i dobar zahtjev
3.4 Vrste zahtjeva
Zahtjeve dijelimo na dva načina: po nivou (ko ih postavlja) i po vrsti (šta opisuju).
Po nivou:
- Poslovni zahtjev – cilj organizacije: „Smanjiti broj izgubljenih narudžbi za 90 % u prvih šest mjeseci.”
- Korisnički zahtjev – šta korisnik treba moći uraditi: „Kupac vidi ukupnu cijenu s dostavom prije plaćanja.”
- Sistemski zahtjev – šta sistem tačno radi, dovoljno precizno za programera: „Sistem računa dostavu po pravilima PP-2 do PP-4 i prikazuje je u eurima s dvije decimale.”
Po vrsti:
- Funkcionalni zahtjev kaže šta sistem radi: računa, prikazuje, šalje, čuva. „Restoran može prihvatiti ili odbiti novu narudžbu.”
- Nefunkcionalni zahtjev kaže kakav sistem mora biti dok to radi: koliko brz, siguran, dostupan, jednostavan. „95 % zahtjeva dobija odgovor za najviše 2 sekunde.”
Razlika se lako pamti na automobilu. Funkcionalni zahtjevi su: vozi, koči, skreće. Nefunkcionalni: od 0 do 100 km/h za 9 sekundi, troši 5 litara na 100 km, ima pet zvjezdica na testu sigurnosti. Auto koji vozi, ali koči za 200 metara, ispunjava funkcionalni, a pada na nefunkcionalnom zahtjevu.
Karakteristike kvaliteta
Nefunkcionalne zahtjeve je lako zaboraviti, jer ih korisnik rijetko izgovori: niko ne kaže „hoću da sistem ne pada”, jer to podrazumijeva. Zato postoji međunarodni standard ISO/IEC 25010, koji navodi karakteristike kvaliteta softvera kao podsjetnik. Najvažnije za DeliveryApp:
| Karakteristika | Pitanje | Zahtjev DeliveryApp |
|---|---|---|
| Performanse | Koliko brzo i za koliko korisnika? | NZ-1: 95 % odgovora ≤ 2 s pri 200 korisnika |
| Pouzdanost (dostupnost) | Koliko vremena sistem radi? | NZ-2: 99,5 % mjesečno |
| Sigurnost | Ko smije šta? Šta ako neko napadne? | NZ-3: lozinka samo kao heš; restoran dvofaktorski |
| Upotrebljivost | Može li ga koristiti novi korisnik? | NZ-4: prva narudžba za ≤ 3 min; kontrast ≥ 4,5 : 1 |
| Održivost | Koliko je lako mijenjati ga? | kod ima automatske testove; dokumentovan API |
| Prenosivost | Radi li na različitim uređajima? | Android, iOS i preglednik |
Uz to idu i zakonski zahtjevi, kao NZ-5 o privatnosti: adresa i telefon kupca brišu se 12 mjeseci nakon posljednje narudžbe.
Dostupnost u satima
Dostupnost od 99,5 % zvuči skoro savršeno. Koliko je to u satima? Mjesec od 30 dana ima 30 × 24 = 720 sati. Dozvoljeno je da sistem ne radi 0,5 % tog vremena:
\[ t_{\text{zastoj}} = (1 - 0{,}995) \times 720 \text{ h} = 0{,}005 \times 720 \text{ h} = 3{,}6 \text{ h}. \]
Čemu služi. Ovaj račun pretvara procenat u nešto što svako razumije: DeliveryApp smije mjesečno biti nedostupan najviše 3,6 sati, odnosno 3 sata i 36 minuta. Ako se to desi baš u petak u 13 sati, restorani gube ručak. Zato zahtjev često dodaje i kada je dostupnost najvažnija („između 11 i 15 sati najviše 15 minuta zastoja mjesečno”).
Broj za pamćenje. Svaka „devetka” više smanjuje dozvoljeni zastoj deset puta: 99 % je 7,2 sata mjesečno, 99,9 % je oko 43 minute, a 99,99 % oko 4 minute. Svaka devetka košta mnogo više od prethodne.
Ukratko.
- Po nivou zahtjevi su poslovni, korisnički i sistemski.
- Funkcionalni zahtjev kaže šta sistem radi, a nefunkcionalni kakav mora biti dok to radi.
- Standard ISO/IEC 25010 služi kao podsjetnik za karakteristike kvaliteta: performanse, pouzdanost, sigurnost, upotrebljivost, održivost, prenosivost.
- Dostupnost od 99,5 % dozvoljava 3,6 sati zastoja u mjesecu od 30 dana.
3.5 Šta čini zahtjev dobrim
Uporedimo dva zahtjeva:
- Loše: „Sistem mora biti brz.”
- Dobro: „Za 95 % zahtjeva sistem vraća odgovor za najviše 2 sekunde, kada ga istovremeno koristi do 200 korisnika.”
Prvi je nemoguće provjeriti: brz za koga, koliko, kada? Drugi se može izmjeriti testom opterećenja i reći „prošao” ili „pao”. Dobar zahtjev ima ove osobine:
| Osobina | Pitanje | Loš primjer | Popravljeno |
|---|---|---|---|
| Jasan | Razumiju li ga svi isto? | „Dostava se plaća po kilometru.” | „0,50 € za svaki započeti kilometar preko 3 km.” |
| Provjerljiv | Može li se napisati test? | „Aplikacija je jednostavna.” | „Novi kupac završi prvu narudžbu za najviše 3 minute.” |
| Jedan | Govori li o jednoj stvari? | „Kupac plaća karticom i dobija račun mailom i SMS-om.” | tri odvojena zahtjeva |
| Izvodiv | Može li se napraviti u roku i budžetu? | „Dostava za 5 minuta na svaku adresu.” | „Kupac vidi procijenjeno vrijeme dostave.” |
| Potreban | Postoji li neko kome treba? | „Tamna tema za restorane.” | (ako niko nije tražio, ide u „možda kasnije”) |
| Bez rješenja | Kaže li šta, a ne kako? | „Narudžbe se čuvaju u MySQL bazi.” | „Narudžbe se čuvaju najmanje 5 godina.” |
Posebno pazite na riječi koje zvuče jasno, a nisu: brzo, jednostavno, korisnički orijentisano, moderno, sigurno, po potrebi, itd., i/ili. Svaka od njih je znak da zahtjev treba prepraviti.
Ustalio se i dogovor o glagolima: „mora” znači obavezno, „trebalo bi” znači poželjno, „može” znači dozvoljeno. Ako se u istom dokumentu miješaju „treba”, „mora” i „bilo bi dobro”, niko ne zna šta je obavezno.
Na času. Prepravite u provjerljiv zahtjev: „Restoran mora brzo saznati za novu narudžbu.” (Jedan dobar odgovor: „Restoran vidi novu narudžbu na ekranu i čuje zvučni signal najkasnije 10 sekundi nakon što je kupac plati.”)
Ukratko.
- Dobar zahtjev je jasan, provjerljiv, govori o jednoj stvari, izvodiv je, potreban i ne propisuje rješenje.
- Riječi kao „brzo”, „jednostavno” i „sigurno” znak su da zahtjev treba prepraviti u broj.
- „Mora” znači obavezno, „trebalo bi” poželjno, „može” dozvoljeno.
3.6 Ograničenja i pretpostavke
Pored zahtjeva, specifikacija bilježi još dvije stvari koje se lako zaborave.
Ograničenje je uslov koji tim ne bira, nego ga mora poštovati: zakon o zaštiti ličnih podataka, pravila firme za kartice, budžet od X eura, rok „prije turističke sezone”, obaveza da radi s postojećom fiskalnom kasom restorana. Ograničenja sužavaju izbor rješenja.
Pretpostavka je nešto što tim smatra tačnim, a nije provjerio: „svaki dostavljač ima pametni telefon s GPS-om”, „restorani imaju stabilan internet”, „kupci znaju svoju tačnu adresu”. Pretpostavke se zapisuju da bi se mogle provjeriti, jer neprovjerena pretpostavka je skriveni rizik.
Upravo je pretpostavka srušila sistem Hitne pomoći Londona iz priče: sistem je pretpostavljao da uvijek tačno zna gdje je vozilo i šta posada radi. Da je ta pretpostavka bila zapisana, neko bi pitao: „A šta ako posada zaboravi pritisnuti dugme?”
| Oznaka | Pretpostavka DeliveryApp | Kako je provjeravamo |
|---|---|---|
| P-1 | Svaki dostavljač ima telefon s GPS-om | pitati sva četiri dostavljača |
| P-2 | Restorani imaju internet i u podne | posmatranje u podne, test brzine |
| P-3 | Servis mapa računa udaljenost tačno na 0,1 km | probati 20 poznatih adresa |
Ukratko.
- Ograničenje je uslov koji tim mora poštovati: zakon, budžet, rok, postojeći sistem.
- Pretpostavka je nešto što smatramo tačnim, a nismo provjerili; zapisuje se da bi se provjerila.
- Neprovjerena pretpostavka o lokaciji vozila srušila je sistem Hitne pomoći Londona 1992.
Provjeri se.
- Koja je razlika između funkcionalnog i nefunkcionalnog zahtjeva? – Funkcionalni kaže šta sistem radi, a nefunkcionalni kakav mora biti dok to radi.
- Koliko sati zastoja mjesečno dozvoljava dostupnost od 99,5 %? – 3,6 sati (0,005 × 720 h).
- Zašto je „sistem mora biti brz” loš zahtjev? – Ne može se provjeriti: ne kaže koliko, za koga ni kada.
Dio 3 – Korisničke priče
3.7 Korisnička priča
U agilnim timovima zahtjevi se najčešće pišu kao korisničke priče (user stories). Korisnička priča je kratka rečenica iz ugla korisnika, u obliku:
Kao 〈uloga〉, želim 〈nešto uraditi〉, da bih 〈korist〉.
Primjeri za DeliveryApp:
- Kao kupac, želim vidjeti cijenu dostave prije nego što platim, da bih znao koliko ukupno plaćam.
- Kao kuhar, želim vidjeti nove narudžbe redom na ekranu u kuhinji, da ne bih morao čekati da mi ih konobar prepiše.
- Kao dostavljač, želim vidjeti adresu na mapi, da ne bih morao zvati kupca s puta.
- Kao vlasnik restorana, želim na kraju mjeseca vidjeti koliko je prodato kojeg jela, da bih znao šta da nabavim.
Svaki dio priče ima svrhu. Uloga podsjeća za koga radimo. Želja kaže šta. Korist kaže zašto, i to je najvažniji dio, jer omogućava drugačije rješenje ako se prvo pokaže skupim.
Priča nije cijeli zahtjev. To je podsjetnik na razgovor: kartica koja kaže „o ovome treba razgovarati”, a detalji se dogovore kad priča dođe na red. Ali kad priča uđe u sprint, mora imati kriterije prihvatanja (3.8).
INVEST: provjera dobre priče
Dobra priča zadovoljava šest osobina, čija početna slova daju englesku riječ INVEST:
| Slovo | Osobina | Pitanje |
|---|---|---|
| I | Nezavisna (Independent) | Može li se napraviti bez čekanja druge priče? |
| N | Pregovaračka (Negotiable) | Ostavlja li prostor za razgovor o rješenju? |
| V | Vrijedna (Valuable) | Donosi li nekome korist? |
| E | Procjenjiva (Estimable) | Može li tim procijeniti njenu veličinu? |
| S | Mala (Small) | Može li stati u jedan sprint? |
| T | Provjerljiva (Testable) | Možemo li napisati test? |
Priča „Kao kupac, želim koristiti DeliveryApp” pada na skoro svim slovima: prevelika je, nije procjenjiva ni provjerljiva. Takva velika priča zove se epika i dijeli se na manje priče.
Ukratko.
- Korisnička priča ima oblik „Kao 〈uloga〉, želim 〈nešto〉, da bih 〈korist〉”.
- Korist je najvažniji dio, jer omogućava i drugačije rješenje.
- Priča je podsjetnik na razgovor; prije sprinta dobija kriterije prihvatanja.
- Dobra priča zadovoljava INVEST, a prevelika priča (epika) dijeli se na manje.
3.8 Kriteriji prihvatanja
Kriterij prihvatanja je provjerljiv uslov koji kaže kada je priča ispunjena. Najjasniji oblik je Dato–Kada–Tada (engleski Given–When–Then):
- Dato – početno stanje (šta je već istina);
- Kada – radnja koju neko uradi;
- Tada – očekivani rezultat, koji se može provjeriti.
Za priču „Kao kupac, želim vidjeti cijenu dostave prije nego što platim” kriteriji su:
Kriterij 1 – plaćena dostava
Dato: u korpi su 2 × Pizza Margarita i 1 × Sok (21,50 €), adresa je 4,2 km od R-1
Kada: kupac otvori pregled narudžbe
Tada: vidi dostavu 3,00 € i ukupno 24,50 €
Kriterij 2 – besplatna dostava
Dato: u korpi su artikli za tačno 30,00 €, adresa je 5 km od restorana
Kada: kupac otvori pregled narudžbe
Tada: vidi dostavu 0,00 € i poruku „Dostava je besplatna”
Kriterij 3 – izvan zone
Dato: adresa je 11 km od restorana
Kada: kupac pokuša otvoriti pregled narudžbe
Tada: vidi poruku „Ova adresa je izvan zone dostave (najviše 10 km)” i ne može platiti
Primijetite tri stvari. Prvo, svaki kriterij ima konkretne brojeve, ne „neka cijena”. Drugo, kriteriji pokrivaju i granice (tačno 30,00 €) i neuspjeh (11 km), ne samo srećan put. Treće, ovakav tekst tester može direktno pretvoriti u automatski test; u predmetu Testiranje softvera isti oblik se zove BDD i piše u jeziku Gherkin.
Iz stvarnog svijeta. Kriteriji prihvatanja su najjeftiniji test koji postoji. Pišu se za nekoliko minuta, a otkrivaju nejasnoće dok ih ispravka košta samo jednu rečenicu. Upravo pitanje „a šta je s tačno 30,00 €?” natjeralo je vlasnike da u PP-4 napišu „od 30,00 € i više”.
Ukratko.
- Kriterij prihvatanja kaže kada je priča ispunjena, u obliku Dato–Kada–Tada.
- Dobri kriteriji imaju konkretne brojeve i pokrivaju granice i neuspjeh, ne samo srećan put.
- Iz kriterija prihvatanja tester direktno pravi automatske testove.
3.9 Prioritet i sljedivost
Backlog DeliveryApp ubrzo će imati pedeset priča, a novca i vremena ima za dvadeset. Vlasnik proizvoda mora odlučiti šta je važnije. Jednostavna i popularna metoda je MoSCoW (velika slova su početna slova četiri grupe na engleskom):
| Grupa | Značenje | Primjer u DeliveryApp |
|---|---|---|
| M – mora (Must have) | bez ovoga sistem nema smisla | jelovnik, korpa, obračun dostave, prijem narudžbe u restoranu |
| S – trebalo bi (Should have) | važno, ali može sačekati drugo izdanje | plaćanje karticom, otkazivanje |
| C – moglo bi (Could have) | lijepo je imati | praćenje dostavljača na mapi, ocjene restorana |
| W – neće ovaj put (Won’t have this time) | dogovoreno da nije u ovoj verziji | program vjernosti, narudžba za sutra |
Grupa W je jednako važna kao M: zapisano „neće” sprečava da se ista želja vraća na svaki sastanak, kao kod FBI-ja.
Matrica sljedivosti
Sljedivost znači da se za svaki zahtjev vidi odakle je došao i šta ga provjerava. Najjednostavniji alat je tabela:
| Poslovni cilj | Pravilo / zahtjev | Korisnička priča | Kriterij / test |
|---|---|---|---|
| Ista cijena za istu adresu | PP-2, PP-3, PP-4 | Kao kupac, želim vidjeti cijenu dostave… | Kriteriji 1–3 iz 3.8 |
| Manje izgubljenih narudžbi | „Restoran vidi narudžbu za ≤ 10 s” | Kao kuhar, želim vidjeti nove narudžbe… | narudžba plaćena u 12:00:00 vidi se do 12:00:10 |
| Zakonita obrada podataka | NZ-5 | – (sistemski zadatak) | adresa kupca bez narudžbe 12 mjeseci je obrisana |
Kad se jedno pravilo promijeni (npr. dostava poskupi na 2,50 €), tabela odmah pokazuje koje priče i testovi se moraju mijenjati.
Ukratko.
- MoSCoW dijeli zahtjeve na mora, trebalo bi, moglo bi i neće ovaj put.
- Grupa „neće ovaj put” je jednako važna jer zaustavlja ponavljanje istih želja.
- Matrica sljedivosti povezuje cilj, zahtjev, priču i test, pa pokazuje šta se mijenja kad se promijeni pravilo.
3.10 Promjena zahtjeva
Zahtjevi će se mijenjati. To nije greška tima, nego znak da korisnici uče šta im treba. Greška je kad se mijenjaju bez reda. Zato tim dogovori jednostavan put za svaku promjenu:
- Zahtjev za promjenu se zapiše (ko traži, šta i zašto), npr. kao novi GitHub Issue s oznakom
promjena. - Procjena uticaja: koje priče, modele, kod i testove dira (matrica sljedivosti iz 3.9), i koliko košta.
- Odluka: vlasnik proizvoda odlučuje da li i kada; kod velikih promjena i naručilac.
- Izvršenje i trag: promjena ulazi u backlog, a Git čuva staru i novu verziju zahtjeva.
U Scrumu je pravilo jednostavno: unutar sprinta se ne mijenja cilj sprinta, a između sprintova backlog se slobodno preslaguje. Tako tim ima dvije mirne sedmice za rad, a korisnik ne čeka godinu na promjenu.
Na času. Vlasnik Roštilja R-2 sredinom sprinta traži da DeliveryApp prima i narudžbe „za poslije 18 sati”. Šta radi tim? (Zapiše zahtjev za promjenu, vlasnik proizvoda ga procijeni i stavi u backlog za neki od sljedećih sprintova; tekući sprint se ne mijenja.)
Ukratko.
- Zahtjevi se mijenjaju jer korisnici uče; problem je promjena bez reda.
- Svaka promjena se zapiše, procijeni, odobri i izvrši uz trag u Gitu.
- U Scrumu se cilj sprinta ne mijenja usred sprinta, a backlog se preslaguje između sprintova.
Provjeri se.
- Napišite korisničku priču za dostavljača. – Npr. „Kao dostavljač, želim vidjeti adresu na mapi, da ne bih morao zvati kupca s puta.”
- Koja tri dijela ima kriterij Dato–Kada–Tada? – Početno stanje, radnju i očekivani rezultat koji se može provjeriti.
- Šta znači W u MoSCoW? – „Neće ovaj put”: dogovoreno je da to nije u ovoj verziji.
Praktična nastava – intervju i korisničke priče
Cilj je da svaki student vodi pravi intervju, iz njega izvuče potrebe i napiše dvanaest korisničkih priča za DeliveryApp s kriterijima prihvatanja i prioritetom. Radi se u parovima i u repozitoriju deliveryapp-projekat.
Korak 1 – Intervju u paru (40 minuta)
- Studenti se podijele u parove. Jedan je analitičar, drugi glumi vlasnika restorana (izabere R-1, R-2 ili R-3).
- „Vlasnik” dobije karticu sa skrivenim potrebama, koje ne smije reći dok ga analitičar ne navede pravim pitanjem. Primjer kartice za R-2: nedjeljom radi samo do 16 h; ćevapi se pripremaju 12 minuta, pa narudžbu treba prihvatiti odmah; dostavljač D-2 ne vozi po kiši; najviše ga nervira kad kupac ne javi da je odustao.
- Analitičar ima 20 minuta. Počinje otvorenim pitanjem („Opišite mi jedno obično podne”), traži konkretne primjere i ne predlaže rješenja.
- Na kraju analitičar ponovi glavne potrebe svojim riječima. „Vlasnik” otkrije karticu: koliko je skrivenih potreba otkriveno?
- Uloge se zamijene, s drugim restoranom.
Korak 2 – Zainteresovane strane
U fajl zahtjevi.md upišite tabelu zainteresovanih strana DeliveryApp (najmanje osam) i matricu uticaja i interesa. Matricu možete nacrtati i kao Mermaid dijagram tipa quadrantChart:
quadrantChart
title Zainteresovane strane DeliveryApp
x-axis "Mali interes" --> "Veliki interes"
y-axis "Mali uticaj" --> "Veliki uticaj"
quadrant-1 "Blisko sarađivati"
quadrant-2 "Držati zadovoljnim"
quadrant-3 "Pratiti"
quadrant-4 "Informisati"
"Udruženje": [0.85, 0.9]
"Vlasnik restorana": [0.9, 0.75]
"Poreska uprava": [0.2, 0.8]
"Kupac": [0.8, 0.3]
"Komšije": [0.15, 0.15]Korak 3 – Dvanaest korisničkih priča
- Za svaku od četiri uloge (kupac, restoran, dostavljač, administrator) napišite tri priče u obliku „Kao …, želim …, da bih …”. Iskoristite i potrebe otkrivene u intervjuu.
- Svaku priču unesite kao GitHub Issue. U opis upišite najmanje dva kriterija prihvatanja u obliku Dato–Kada–Tada, s konkretnim brojevima iz DeliveryApp.
- Dodajte oznake MoSCoW:
M,S,C,W. Najmanje jedna priča mora bitiW. - Provjerite svaku priču po INVEST-u. Ako je prevelika, podijelite je.
Korak 4 – Nefunkcionalni zahtjevi i pretpostavke
U zahtjevi.md dodajte:
- tabelu nefunkcionalnih zahtjeva NZ-1 do NZ-5 iz udžbenika i bar jedan svoj (npr. „aplikacija radi i na telefonu s ekranom širine 360 piksela”), svaki provjerljiv;
- tabelu od najmanje tri pretpostavke, s načinom provjere.
Korak 5 – Matrica sljedivosti
Napravite tabelu sa četiri kolone (poslovni cilj, zahtjev, priča, kriterij) za najmanje pet redova. Svaka priča iz koraka 3 s oznakom M mora biti u tabeli.
Korak 6 – AI kao recenzent (opcionalno)
Zalijepite svoje priče u AI asistenta i zatražite: „Za svaku priču reci koje slovo INVEST-a ne zadovoljava i predloži bolju verziju.” Prihvatite samo prijedloge s kojima se slažete i zapišite u commit poruci šta ste promijenili. AI ne zna pravila DeliveryApp ako mu ih ne date; provjerite da nije izmislio nijedan broj.
Rezultat koji se predaje: zahtjevi.md (zainteresovane strane, nefunkcionalni zahtjevi, pretpostavke, matrica sljedivosti) i dvanaest GitHub Issues s kriterijima prihvatanja i oznakama MoSCoW.
Vježbe
Vježba za studenta 1 – funkcionalni ili nefunkcionalni.
Razvrstajte: a) „Kupac može otkazati narudžbu dok je u stanju PRIHVAĆENA.” b) „Aplikacija radi na Androidu od verzije 10.” c) „Lozinka se čuva samo kao heš.” d) „Restoran može označiti jelo kao privremeno nedostupno.” e) „Stranica s jelovnikom učitava se za najviše 1,5 s na 4G mreži.”
Rješenje. a) funkcionalni; b) nefunkcionalni (prenosivost); c) nefunkcionalni (sigurnost); d) funkcionalni; e) nefunkcionalni (performanse).
Vježba za studenta 2 – popravi zahtjev.
Prepravite u provjerljive zahtjeve: a) „Aplikacija mora biti dostupna skoro uvijek.” b) „Dostavljač treba brzo dobiti obavještenje.” c) „Sistem je siguran.”
Rješenje. Primjeri: a) „DeliveryApp je dostupan najmanje 99,5 % vremena u svakom kalendarskom mjesecu (najviše 3,6 h zastoja u 30 dana).” b) „Dostavljač dobija obavještenje na telefon najkasnije 15 sekundi nakon što restoran označi narudžbu spremnom.” c) Rastaviti na više provjerljivih: „Lozinke se čuvaju samo kao heš”, „Nakon 5 pogrešnih prijava nalog se zaključava na 15 minuta”, „Restoran se prijavljuje dvofaktorski.”
Vježba za studenta 3 – dostupnost.
Koliko je minuta zastoja mjesečno (30 dana) dozvoljeno za dostupnost od 99,9 %? A godišnje (365 dana) za 99,5 %?
Rješenje. Mjesečno: 0,001 × 720 h = 0,72 h = 0,72 × 60 = 43,2 minute. Godišnje: 0,005 × 365 × 24 h = 0,005 × 8760 h = 43,8 sati.
Vježba za studenta 4 – kriteriji prihvatanja.
Napišite dva kriterija Dato–Kada–Tada za priču „Kao kupac, želim koristiti kod STUDENT10, da bih platio manje.” Jedan neka bude za N-1001, a drugi za granicu popusta.
Rješenje. Kriterij 1: Dato su artikli 21,50 € i adresa 4,2 km; Kada kupac upiše STUDENT10; Tada vidi popust 2,15 € i ukupno 22,35 €. Kriterij 2: Dato su artikli 80,00 € (dostava besplatna); Kada kupac upiše STUDENT10; Tada vidi popust 5,00 € (ne 8,00 €, jer je to gornja granica) i ukupno 75,00 €.
Vježba za studenta 5 – INVEST.
Ocijenite priču po INVEST-u i popravite je: „Kao korisnik, želim da aplikacija bude dobra, da bih bio zadovoljan.”
Rješenje. Uloga je preopšta (koji korisnik?), želja nije provjerljiva ni procjenjiva, a priča je prevelika (nije mala); pada na E, S i T, a vrijednost je nejasna. Treba je rastaviti na konkretne priče, npr. „Kao kupac, želim sačuvati adresu, da je ne bih kucao pri svakoj narudžbi”, s kriterijem: Dato je sačuvana adresa; Kada kupac pravi novu narudžbu; Tada je adresa već upisana.
Sažetak u pet rečenica
- Zahtjevi počinju pitanjem koga pitati: zainteresovane strane su svi koje se sistem tiče, a matrica uticaja i interesa pokazuje koliko često koga uključiti.
- Zahtjevi se otkrivaju intervjuom, upitnikom, posmatranjem, radionicom, dokumentima i prototipom, a tehnika „pet puta zašto” vodi od traženog rješenja do stvarne potrebe.
- Funkcionalni zahtjevi kažu šta sistem radi, nefunkcionalni kakav mora biti, a dobar zahtjev je jasan, provjerljiv i izražen brojem, kao dostupnost od 99,5 %, odnosno najviše 3,6 sati zastoja mjesečno.
- Korisnička priča „Kao …, želim …, da bih …” dobija kriterije prihvatanja u obliku Dato–Kada–Tada s konkretnim brojevima, granicama i neuspjehom.
- MoSCoW slaže zahtjeve po važnosti, matrica sljedivosti povezuje cilj, zahtjev, priču i test, a svaka promjena zahtjeva ide dogovorenim putem, jer su nejasni i neprovjereni zahtjevi srušili sistem Hitne pomoći Londona 1992.