Nefunkcionalni zahtjevi

Šta učimo ovog semestra (1–5)

Deset predavanja: dva časa teorije i jedan čas dopunske prakse. Danas je poglavlje 6. Isti primjer kroz knjigu: DeliveryApp 2.0.

Šta učimo ovog semestra (6–10)

Deset predavanja: dva časa teorije i jedan čas dopunske prakse. Danas: poglavlje 6 (označeno). Isti primjer kroz knjigu: DeliveryApp 2.0.

Priča za početak

Priča za početak

Literatura

1. I. Sommerville: Software Engineering, 10th ed., Pearson, 2016 (poglavlje 4 i dio o pouzdanosti).
2. L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, 4th ed., Addison-Wesley, 2021 (scenariji i taktike kvaliteta).
3. ISO/IEC 25010: Systems and software Quality Requirements and Evaluation (SQuaRE) – Product quality model.

Zašto ovo poglavlje

U poglavlju 5 naučili smo kako izmjena brzo i bez straha stiže do korisnika. Ali korisnik ne ocjenjuje samo šta proizvod radi, nego i kako: da li je brz, da li je stalno dostupan, da li čuva podatke, da li ga je lako koristiti. To su nefunkcionalni zahtjevi. Prvi dio govori šta su, kako se klasifikuju i kako se zapisuju tako da se mogu izmjeriti. Drugi dio govori kako se implementiraju: keš, skaliranje, redovi poruka, otpornost na kvarove, i kako se DeliveryApp 2.0 redizajnira da izdrži ručak u tri grada.

Riječi ovog poglavlja (1/2)

• Nefunkcionalni zahtjev (NFR) – zahtjev koji opisuje kako sistem radi (brzina, dostupnost, sigurnost…), a ne šta radi.
• ISO/IEC 25010 – međunarodni standard koji dijeli kvalitet softverskog proizvoda u karakteristike.
• Scenarij kvaliteta – mjerljiv opis NFR-a: šta se desi, u kojim uslovima, i kako sistem mora odgovoriti.
• Vrijeme odziva – vrijeme od zahtjeva do odgovora.
• Percentil p95 – vrijednost ispod koje je 95 % mjerenja.
• Dostupnost – procenat vremena u kojem sistem radi; „devetke”: 99 %, 99,9 %…

Riječi ovog poglavlja (2/2)

• Keš – brza memorija za podatke koji se često čitaju, da se ne traže svaki put iz spore baze.
• Skaliranje – povećanje kapaciteta: vertikalno (jača mašina) ili horizontalno (više mašina).
• Red poruka – „poštansko sanduče” između dijelova sistema, da posao ne čeka da drugi završi.
• Taktika – provjeren način da se postigne neki kvalitet (npr. keš za performanse).
• Prekidač kola (circuit breaker) – zaštita koja prestaje zvati servis koji ne radi, dok se ne oporavi.
• Test opterećenja – provjera kako se sistem ponaša pod velikim brojem istovremenih korisnika.

Ciljevi poglavlja

Nakon poglavlja možete:

objasniti razliku između funkcionalnih i nefunkcionalnih zahtjeva i zašto NFR mogu „oboriti” funkcionalnost; nabrojati karakteristike kvaliteta po ISO/IEC 25010; klasifikovati NFR prema tome gdje se implementiraju; zapisati NFR kao mjerljiv scenarij; izračunati dozvoljeni zastoj iz procenta dostupnosti; objasniti taktike za performanse, skalabilnost, dostupnost i otpornost; izmjeriti efekat keša; predložiti redizajn proizvoda za novi NFR.

Plan poglavlja – Predavanje 6: dva časa teorije i jedan čas dopunske prakse

6.1 Šta su nefunkcionalni zahtjevi i zašto su važni

Funkcionalni zahtjev kaže šta sistem radi: „Kupac može ponoviti prošlu narudžbu.” Nefunkcionalni zahtjev kaže kako to radi: „Ponovljena narudžba se prikaže za najviše 2 sekunde, i u vrijeme ručka.”

Analogija s automobilom: funkcionalno, automobil vozi, koči i skreće. Nefunkcionalno, troši 5 litara na sto kilometara, ima pet zvjezdica za sigurnost, pali se i na −20 °C i servisira se svakih 15.000 km. Automobil koji vozi, ali ne pali po hladnoći, za vlasnika na sjeveru jednostavno ne radi.

Zato kažemo da NFR mogu oboriti funkcionalnost. Pokémon GO je imao sve funkcije, ali bez skalabilnosti igrači nisu mogli ništa. DeliveryApp s tačnim obračunom dostave, ali sa stranicom koja se učitava deset sekundi u podne, gubi kupce koji odu telefonom naručiti direktno od restorana.

NFR su teži od funkcionalnih zahtjeva iz tri razloga:

6.1 Šta su nefunkcionalni zahtjevi i zašto su važni

1. Često se ne kažu. Kupac ne kaže „hoću da bude brzo”, nego to podrazumijeva.
2. Pogađaju cijeli sistem. Funkcija „Ponovi narudžbu” je u jednom dijelu koda; brzina zavisi od baze, mreže, servera, keša i koda zajedno.
3. Skupo se dodaju naknadno. Dostupnost od 99,9 % traži arhitekturu s više servera. Ako je sistem napravljen za jedan server, „dodati dostupnost” znači prepraviti pola sistema.

Ukratko – 6.1 Šta su nefunkcionalni zahtjevi i zašto su važni

• Funkcionalni zahtjev kaže šta sistem radi, a nefunkcionalni kako to radi.
• NFR mogu oboriti funkcionalnost: sistem koji se ne može otvoriti ne radi.
• NFR se često ne izgovore, pogađaju cijeli sistem i skupo se dodaju naknadno.

6.2 Klasifikacija po ISO/IEC 25010

Da bi se o kvalitetu razgovaralo istim riječima, međunarodni standard ISO/IEC 25010 dijeli kvalitet softverskog proizvoda u karakteristike. Izdanje iz 2011. ima osam karakteristika; revizija iz 2023. dodala je sigurnost u smislu bezbjednosti (safety, da softver ne ugrozi ljude i okolinu) i preimenovala dvije postojeće.

6.2 Klasifikacija po ISO/IEC 25010

6.2 Klasifikacija po ISO/IEC 25010

Ukratko – 6.2 Klasifikacija po ISO/IEC 25010

• ISO/IEC 25010 dijeli kvalitet proizvoda u karakteristike: funkcionalna prikladnost, performanse, kompatibilnost, upotrebljivost, pouzdanost, sigurnost, održivost, prenosivost, a od 2023. i bezbjednost.
• Standard daje zajednički rječnik za razgovor o kvalitetu.
• Svaki NFR DeliveryApp pripada jednoj karakteristici.

6.3 Klasifikacija prema implementaciji

Programeru je važno i drugo pitanje: gdje se NFR implementira? Odgovor određuje ko ga radi i koliko košta.

6.3 Klasifikacija prema implementaciji

Sommerville predlaže i podjelu po porijeklu: proizvodni NFR (ponašanje proizvoda: brzina, pouzdanost), organizacioni (pravila firme: jezik, alati, proces) i vanjski (zakoni, etika, regulatori).

Praktična posljedica: arhitekturalni NFR moraju biti poznati rano, prije nego što se arhitektura izabere (poglavlje 7). Lokalni se mogu dodati u bilo kojem sprintu. Zato Lana i Amar prvo pitaju za broj korisnika i dostupnost, a tek poslije za boju dugmeta.

Ukratko – 6.3 Klasifikacija prema implementaciji

• Prema implementaciji NFR su arhitekturalni, lokalni, procesni, operativni i ograničenja.
• Po porijeklu su proizvodni, organizacioni i vanjski.
• Arhitekturalni NFR moraju biti poznati rano, jer se kasnije teško mijenjaju.

6.4 Mjerljivi NFR: scenariji kvaliteta

„Sistem mora biti brz” nije zahtjev, nego želja: niko ne može provjeriti da li je ispunjena. NFR mora biti mjerljiv. Bass, Clements i Kazman predlažu scenarij kvaliteta sa šest dijelova:

6.4 Mjerljivi NFR: scenariji kvaliteta

Zašto p95, a ne prosjek? Prosjek sakriva loše slučajeve. Ako 90 zahtjeva traje 0,5 s, a 10 zahtjeva 15 s, prosjek je 1,95 s, „ispod 2 sekunde”, ali svaki deseti kupac čeka petnaest sekundi i odlazi. Percentil p95 kaže: 95 % zahtjeva je brže od ove vrijednosti.

Devetke dostupnosti. Dostupnost se piše u procentima, a lakše se razumije kao dozvoljeni zastoj. Za mjesec od 30 dana (720 sati):

6.4 Mjerljivi NFR: scenariji kvaliteta

Svaka nova devetka obično znači više servera, više automatizacije i više novca. Zato se pita: koliko košta sat zastoja DeliveryApp u podne? Ako je odgovor „mnogo manje nego treći server”, 99,5 % je pravi izbor.

Ukratko – 6.4 Mjerljivi NFR: scenariji kvaliteta

• NFR mora biti mjerljiv; scenarij kvaliteta ima izvor, podsticaj, okruženje, artefakt, odgovor i mjeru.
• Za vrijeme odziva koristi se percentil (p95), jer prosjek sakriva loše slučajeve.
• Dostupnost se prevodi u dozvoljeni zastoj: 99,5 % je 3,6 sati mjesečno.

Provjeri se

1. Da li je „lozinke se čuvaju kao heš” funkcionalni ili nefunkcionalni zahtjev? Nefunkcionalni (sigurnost), lokalni u kodu.
2. Koliko zastoja mjesečno dozvoljava 99,9 %? 43,2 minute u 30 dana.
3. Zašto p95, a ne prosjek? Prosjek sakriva spore zahtjeve; p95 kaže koliko čeka 95 % korisnika.

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

6.5 Performanse i skalabilnost

Performanse govore koliko je sistem brz za jednog korisnika; skalabilnost govori da li ostaje brz kad korisnika bude deset puta više. Za DeliveryApp 2.0 važno je oboje: verzija 1.x zadovoljava NZ-1 (200 korisnika), a 2.0 mora izdržati 600.

Taktike za performanse i skalabilnost:

• Keš. Jelovnik restorana mijenja se možda jednom sedmično, a čita hiljadu puta dnevno. Umjesto da se svaki put čita iz baze, prvi put se pročita i čuva u brzoj memoriji. Analogija: konobar zna napamet današnju ponudu, ne ide u kuhinju za svako pitanje. Opasnost keša: zastarjeli podaci. Ako restoran promijeni cijenu, keš se mora poništiti.
• Vertikalno skaliranje – jača mašina (više procesora i memorije). Jednostavno, ali ima granicu i jednu tačku kvara.
• Horizontalno skaliranje – više istih mašina iza raspoređivača opterećenja (load balancer), koji svaki zahtjev šalje slobodnoj mašini. Analogija: više otvorenih kasa u prodavnici umjesto jedne brže kasirke. Uslov je da servisi ne pamte ništa „kod sebe” (stateless), nego u bazi ili kešu.
• Red poruka i asinhroni rad. Kad kupac naruči, sistem ne mora čekati da se pošalje SMS restoranu i e-pošta kupcu. Narudžba se sačuva, poruka ide u red, a poseban servis je obradi malo kasnije. Kupac dobija odgovor odmah.
• Repliciranje baze za čitanje. Većina zahtjeva samo čita (jelovnik, status narudžbe); čitanje se može raspodijeliti na kopije baze.

6.5 Performanse i skalabilnost

Mjeri, ne nagađaj. Prije bilo koje taktike, izmjeri gdje se vrijeme troši. U dopunskoj praksi mjerimo jelovnik koji se čita iz simulirane baze (50 ms po čitanju). Na računaru autora rezultat je:

bez keša : prosjek  50.457 ms, p95  50.859 ms, 200 zahtjeva za 10.09 s
s kešom  : prosjek   0.252 ms, p95   0.000 ms, 200 zahtjeva za  0.05 s

S kešom samo prvi zahtjev ide u bazu (50 ms), a ostalih 199 traje manje od hiljaditog dijela milisekunde. Zato je prosjek 0,25 ms (50 ms podijeljeno na 200 zahtjeva), a p95 praktično nula. Brojevi se razlikuju od računara do računara, ali odnos ostaje: oko dvjesto puta brže.

Ukratko – 6.5 Performanse i skalabilnost

• Performanse su brzina za jednog korisnika, a skalabilnost brzina kad ih je mnogo.
• Taktike: keš, vertikalno i horizontalno skaliranje, red poruka, replike baze za čitanje.
• Keš donosi rizik zastarjelih podataka, pa se mora poništiti kad se podatak promijeni.
• Prvo se mjeri, pa se bira taktika.

6.6 Dostupnost i otpornost

Dostupnost je procenat vremena u kojem sistem radi; otpornost je sposobnost da radi i kad nešto pukne. U sistemu s mnogo dijelova, nešto uvijek puca: server se restartuje, mreža zakašnjava, servis mapa ne odgovara. Pitanje nije „hoće li”, nego „šta onda”.

Taktike:

• Redundancija – svaki važan dio ima bar dvije kopije (dva servera, baza s rezervnom kopijom u drugom data centru). Ako jedna padne, druga preuzima. Analogija: rezervna guma u autu.
• Vremensko ograničenje (timeout) – ako servis mapa ne odgovori za 2 sekunde, ne čekamo zauvijek.
• Ponovni pokušaj s pauzom (retry with backoff) – pokušaj ponovo nakon 0,5 s, pa nakon 1 s, pa nakon 2 s; ne „bombarduj” servis koji se već muči.
• Prekidač kola (circuit breaker) – kao osigurač u kući: ako servis mapa pet puta zaredom ne odgovori, prestajemo ga zvati na minut i odmah koristimo rezervni plan. Michael Nygard ga je popularizovao u knjizi Release It! (2007).
• Gracilna degradacija – kad nešto ne radi, sistem radi „slabije”, ali radi. Ako servis mapa ne radi, DeliveryApp koristi posljednju poznatu udaljenost za tu adresu ili pita kupca da potvrdi adresu ručno, umjesto da odbije narudžbu.
• Nadzor i upozorenja – tim mora saznati za kvar prije kupaca: grafikon grešaka, vrijeme odziva, upozorenje na mobitel dežurnog.

6.6 Dostupnost i otpornost

Ukratko – 6.6 Dostupnost i otpornost

• Dostupnost je procenat vremena rada, a otpornost sposobnost da se radi i kad nešto pukne.
• Taktike: redundancija, vremensko ograničenje, ponovni pokušaj s pauzom, prekidač kola, gracilna degradacija, nadzor.
• Sistem se projektuje s pretpostavkom da će dijelovi otkazivati.

6.7 Sigurnost, upotrebljivost i održivost u praksi

Ostali NFR DeliveryApp 2.0 i kako se implementiraju:

6.7 Sigurnost, upotrebljivost i održivost u praksi

Princip najmanjih prava važi za sigurnost: dostavljač vidi samo adresu narudžbe koju vozi, a ne istoriju kupca; servis obavještenja može čitati telefon, ali ne i plaćanja. Privatnost se ugrađuje u dizajn od početka (privacy by design), a ne dodaje na kraju.

Ukratko – 6.7 Sigurnost, upotrebljivost i održivost u praksi

• Svaki NFR dobija konkretnu implementaciju i provjeru: biblioteku, test, noćni posao, pravilo u CI-ju.
• Izolacija gradova (NZ-6) i novi grad bez koda (NZ-7) su arhitekturalni NFR.
• Najmanja prava i privatnost po dizajnu su osnovni sigurnosni principi.

6.8 Redizajn proizvoda zbog NFR

Kad se NFR promijene, nekad nije dovoljno „podesiti” sistem; treba ga redizajnirati. DeliveryApp 1.x je napravljen za jedan grad i 200 korisnika: jedna aplikacija na jednom serveru, jedna baza, SMS se šalje odmah dok kupac čeka. Za DeliveryApp 2.0 važi NZ-1a (600 korisnika), NZ-6 i NZ-7.

Tim radi redizajn u četiri koraka:

1. Izmjeri postojeće stanje. Test opterećenja (alati kao k6, Locust ili JMeter) na kopiji sistema: pri 200 korisnika p95 je 1,4 s; pri 400 korisnika 3,8 s; pri 600 korisnika dio zahtjeva ističe. Uska grla su čitanje jelovnika iz baze i slanje SMS-a dok kupac čeka.
2. Izaberi taktike za uska grla. Keš za jelovnike; red poruka za obavještenja; dvije instance aplikacije iza raspoređivača opterećenja; replika baze za čitanje.
3. Ugradi arhitekturalne NFR. Oznaka grada u svakoj tabeli (NZ-6), tarife kao podaci (NZ-7).
4. Ponovi mjerenje. Isti test opterećenja nakon izmjena; cilj je p95 ≤ 2 s pri 600 korisnika, uz rezervu.

6.8 Redizajn proizvoda zbog NFR

6.8 Redizajn proizvoda zbog NFR

Primijetite da se funkcionalni zahtjevi u ovoj tabeli skoro nisu promijenili: kupac i dalje naručuje, plaća i prati narudžbu. Promijenili su se NFR, i to je bilo dovoljno da se promijeni pola arhitekture. O tome kako se takve odluke zapisuju govori poglavlje 7.

Ukratko – 6.8 Redizajn proizvoda zbog NFR

• Novi NFR mogu tražiti redizajn, a ne samo podešavanje.
• Redizajn: izmjeri, izaberi taktike za uska grla, ugradi arhitekturalne NFR, izmjeri ponovo.
• DeliveryApp 2.0 dobija keš, red poruka, više instanci, repliku baze i oznaku grada u podacima.

Provjeri se

1. Koja je razlika između vertikalnog i horizontalnog skaliranja? Vertikalno: jača mašina; horizontalno: više mašina iza raspoređivača opterećenja.
2. Šta radi prekidač kola? Nakon niza neuspjelih poziva prestaje zvati servis na neko vrijeme i odmah koristi rezervni plan.
3. Koji je prvi korak redizajna zbog NFR? Izmjeriti postojeće stanje testom opterećenja.

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

Dopunska praksa – mjerenje odziva i keš

Cilj je izmjeriti efekat keša i napisati jedan mjerljiv scenarij. Trajanje: jedan čas.

Korak 1 – Mjerenje

Pokrenite primjeri/python/kes.py. Program 200 puta čita jelovnik iz simulirane baze (50 ms po čitanju), pa isto to s kešom (functools.lru_cache), i ispisuje prosjek, p95 i ukupno vrijeme.

python primjeri/python/kes.py

Zapišite svoje rezultate. Zašto je prosjek s kešom oko 0,25 ms, a ne nula?

Korak 2 – Zastarjeli keš

Dodajte u program promjenu jelovnika (npr. novo jelo) poslije prvog čitanja. Šta vraća verzija s kešom? Pozovite jelovnik_s_kesom.cache_clear() nakon promjene i provjerite ponovo. Zapišite jednom rečenicom kada DeliveryApp mora poništiti keš.

Korak 3 – Promijenite kašnjenje

Postavite KASNJENJE_BAZE = 0.005 (5 ms) i ponovite mjerenje. Da li se keš i dalje isplati? Šta to govori o pravilu „prvo izmjeri”?

Korak 4 – Scenarij kvaliteta

U repozitoriju deliveryapp-2 napravite docs/nfr.md i upišite dva scenarija u tabeli sa šest dijelova (izvor, podsticaj, okruženje, artefakt, odgovor, mjera): jedan za performanse (NZ-1a), jedan za izolaciju gradova (NZ-6).

Rezultat: izmjereni rezultati za 50 ms i 5 ms, odgovor o poništavanju keša i docs/nfr.md s dva scenarija.

Vježba za studenta 1 – funkcionalno ili nefunkcionalno.

Vježba za studenta 1 – funkcionalno ili nefunkcionalno. – rješenje

Vježba za studenta 2 – devetke.

Vježba za studenta 2 – devetke. – rješenje

Vježba za studenta 3 – scenarij.

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

Vježba za studenta 4 – taktike.

Vježba za studenta 4 – taktike. – rješenje

Sažetak u pet rečenica

1. Pokémon GO je 2016. imao sve funkcije, ali je dobio oko pedeset puta više prometa od procjene, i igrači nisu mogli ući: nefunkcionalni zahtjevi mogu oboriti funkcionalnost.
2. ISO/IEC 25010 daje zajednički rječnik kvaliteta (performanse, pouzdanost, sigurnost, upotrebljivost, održivost i druge), a prema implementaciji NFR su arhitekturalni, lokalni, procesni, operativni i ograničenja.
3. NFR mora biti mjerljiv scenarij s izvorom, podsticajem, okruženjem, artefaktom, odgovorom i mjerom, uz percentile umjesto prosjeka i devetke dostupnosti prevedene u dozvoljeni zastoj.
4. Performanse i skalabilnost postižu se kešom, skaliranjem, redovima poruka i replikama baze, a dostupnost i otpornost redundancijom, vremenskim ograničenjima, ponovnim pokušajima, prekidačem kola i gracilnom degradacijom, i uvijek se prvo mjeri.
5. DeliveryApp 2.0 je zbog novih NFR (600 korisnika, izolacija gradova, novi grad bez koda) redizajniran, iako su funkcije ostale skoro iste.

Pitanja za ponavljanje

1. Šta se desilo s igrom Pokémon GO 2016. i koja je pouka?
2. Koja je razlika između funkcionalnih i nefunkcionalnih zahtjeva? Zašto su NFR teži?
3. Nabrojte karakteristike kvaliteta po ISO/IEC 25010. Šta je dodano 2023?
4. Kako se NFR klasifikuju prema implementaciji? Zašto arhitekturalni NFR moraju biti poznati rano?
5. Navedite šest dijelova scenarija kvaliteta i napišite scenarij za NZ-1a.
6. Zašto se za vrijeme odziva koristi p95, a ne prosjek? Navedite primjer.
7. Koliko zastoja mjesečno dozvoljavaju 99 %, 99,5 % i 99,9 % dostupnosti?
8. Šta je keš i koja je njegova opasnost?
9. Objasnite vertikalno i horizontalno skaliranje i ulogu reda poruka.
10. Nabrojte taktike za dostupnost i otpornost. Šta je prekidač kola?
11. Kako se implementiraju NZ-5 i NZ-6?
12. Opišite četiri koraka redizajna DeliveryApp zbog NFR i šta se promijenilo.