Zahtjevi – šta sistem treba da radi

Šta učimo ovog semestra

Petnaest sedmica, svaka s tri časa teorije i tri časa prakse. Danas: poglavlje 3 (Sedmica 3, označeno). Isti primjer kroz knjigu: DeliveryApp, narudžba N-1001 (24,50 €).

Literatura

1. B. Popović, K. Kuk: Informacioni sistemi, Kriminalističko-policijski univerzitet, Beograd, 2017.
2. J. S. Valacich, J. F. George: Modern Systems Analysis and Design, 9th ed., Pearson, 2020.
3. L. Jelenković: Sustavi za rad u stvarnom vremenu – skripta, FER, Zagreb, 2015.
4. D. Milićev: Programiranje u realnom vremenu – skripta, Beograd, 2002.
5. V. Kovačević, M. Popović: Sistemska programska podrška u realnom vremenu 1, FTN, Novi Sad, 2013.

Priča za početak

Zašto ovo poglavlje

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.

Riječi ovog poglavlja (1/2)

• 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).

Riječi ovog poglavlja (2/2)

• 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

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:

3.1 Zainteresovane strane

3.1 Zainteresovane strane

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).

3.1 Zainteresovane strane

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).

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.

3.1 Zainteresovane strane

Ukratko – 3.1 Zainteresovane strane

• 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.

3.2 Tehnike prikupljanja zahtjeva

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.

3.2 Tehnike prikupljanja zahtjeva

Kako voditi intervju

Intervju je najčešća tehnika i najlakše se pokvari. Nekoliko pravila:

1. Pripremite se. Znajte ko je sagovornik i šta radi; imajte 8–10 pitanja, ali ne čitajte ih kao anketu.
2. 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.
3. 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.
4. 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?”
5. 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 – 3.2 Tehnike prikupljanja zahtjeva

• 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):

1. Zašto papir? – Da kuhar ima narudžbu pred sobom.
2. Zašto mu treba pred sobom? – Jer ne može otvarati računar masnim rukama.
3. Zašto bi otvarao računar? – Da vidi šta je sljedeće na redu.
4. Zašto mu je to teško sada? – Jer narudžbe stižu na telefon konobara, pa ih konobar prepisuje.
5. 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.

3.3 Šta korisnik traži, a šta mu treba

Ukratko – 3.3 Šta korisnik traži, a šta mu treba

• 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

1. Ko je zainteresovana strana? Svako koga se sistem tiče: ko ga plaća, koristi, održava, odobrava ili trpi posljedice.
2. Zašto se otvorena pitanja postavljaju prije zatvorenih? Otvorena otkrivaju probleme i priče, a zatvorena ih kasnije mjere.
3. Šta je prava potreba iza zahtjeva „štampaj narudžbu”? Kuhar mora vidjeti narudžbe redom, jasno i bez prepisivanja.

Odgovori: tipka R ili klik na zamućeno polje.

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.”

3.4 Vrste zahtjeva

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:

3.4 Vrste zahtjeva

Uz to idu i zakonski zahtjevi, kao NZ-5 o privatnosti: adresa i telefon kupca brišu se 12 mjeseci nakon posljednje narudžbe.

3.4 Vrste zahtjeva

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:

Č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”).

Ukratko – 3.4 Vrste zahtjeva

• 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:

3.5 Šta čini zahtjev dobrim

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.

3.5 Šta čini zahtjev dobrim

Ukratko – 3.5 Šta čini zahtjev dobrim

• 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?”

3.6 Ograničenja i pretpostavke

Ukratko – 3.6 Ograničenja i pretpostavke

• 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

1. Koja je razlika između funkcionalnog i nefunkcionalnog zahtjeva? Funkcionalni kaže šta sistem radi, a nefunkcionalni kakav mora biti dok to radi.
2. Koliko sati zastoja mjesečno dozvoljava dostupnost od 99,5 %? 3,6 sati (0,005 × 720 h).
3. Zašto je „sistem mora biti brz” loš zahtjev? Ne može se provjeriti: ne kaže koliko, za koga ni kada.

Odgovori: tipka R ili klik na zamućeno polje.

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:

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.

3.7 Korisnička priča

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:

3.7 Korisnička priča

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 – 3.7 Korisnička priča

• 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

3.8 Kriteriji prihvatanja

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.

Ukratko – 3.8 Kriteriji prihvatanja

• 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):

3.9 Prioritet i sljedivost

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.

3.9 Prioritet i sljedivost

Matrica sljedivosti

Sljedivost znači da se za svaki zahtjev vidi odakle je došao i šta ga provjerava. Najjednostavniji alat je tabela:

Kad se jedno pravilo promijeni (npr. dostava poskupi na 2,50 €), tabela odmah pokazuje koje priče i testovi se moraju mijenjati.

Ukratko – 3.9 Prioritet i sljedivost

• 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:

1. Zahtjev za promjenu se zapiše (ko traži, šta i zašto), npr. kao novi GitHub Issue s oznakom promjena.
2. Procjena uticaja: koje priče, modele, kod i testove dira (matrica sljedivosti iz 3.9), i koliko košta.
3. Odluka: vlasnik proizvoda odlučuje da li i kada; kod velikih promjena i naručilac.
4. 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.

Ukratko – 3.10 Promjena zahtjeva

• 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

1. 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.”
2. Koja tri dijela ima kriterij Dato–Kada–Tada? Početno stanje, radnju i očekivani rezultat koji se može provjeriti.
3. Šta znači W u MoSCoW? „Neće ovaj put”: dogovoreno je da to nije u ovoj verziji.

Odgovori: tipka R ili klik na zamućeno polje.

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)

1. Studenti se podijele u parove. Jedan je analitičar, drugi glumi vlasnika restorana (izabere R-1, R-2 ili R-3).
2. „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.
3. 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.
4. Na kraju analitičar ponovi glavne potrebe svojim riječima. „Vlasnik” otkrije karticu: koliko je skrivenih potreba otkriveno?
5. 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

1. 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.
2. 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.
3. Dodajte oznake MoSCoW: M, S, C, W. Najmanje jedna priča mora biti W.
4. 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žba za studenta 1 – funkcionalni ili nefunkcionalni.

Vježba za studenta 1 – funkcionalni ili nefunkcionalni. – rješenje

Vježba za studenta 2 – popravi zahtjev.

Vježba za studenta 2 – popravi zahtjev. – rješenje

Vježba za studenta 3 – dostupnost.

Vježba za studenta 3 – dostupnost. – rješenje

Vježba za studenta 4 – kriteriji prihvatanja.

Vježba za studenta 4 – kriteriji prihvatanja. – rješenje

Vježba za studenta 5 – INVEST.

Vježba za studenta 5 – INVEST. – rješenje

Sažetak u pet rečenica

1. 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.
2. 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.
3. 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.
4. Korisnička priča „Kao …, želim …, da bih …” dobija kriterije prihvatanja u obliku Dato–Kada–Tada s konkretnim brojevima, granicama i neuspjehom.
5. 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.

Pitanja za ponavljanje

1. Šta se desilo sa sistemom Hitne pomoći Londona 1992. i šta je bio najdublji uzrok?
2. Ko je zainteresovana strana? Nabrojte šest zainteresovanih strana DeliveryApp.
3. Kako se koristi matrica uticaja i interesa?
4. Nabrojte pet tehnika prikupljanja zahtjeva i za svaku jednu prednost.
5. Navedite tri pravila dobrog intervjua.
6. Objasnite tehniku „pet puta zašto” na primjeru štampanja narudžbe.
7. Koja je razlika između poslovnog, korisničkog i sistemskog zahtjeva?
8. Koja je razlika između funkcionalnog i nefunkcionalnog zahtjeva? Dajte po dva primjera.
9. Izračunajte dozvoljeni mjesečni zastoj za dostupnost od 99,5 % i objasnite račun.
10. Navedite šest osobina dobrog zahtjeva.
11. Šta je korisnička priča i šta znači INVEST?
12. Napišite kriterij prihvatanja u obliku Dato–Kada–Tada za narudžbu N-1001.
13. Šta je MoSCoW i zašto je grupa W važna?
14. Šta je matrica sljedivosti i čemu služi?