INŽENJERSTVO ZAHTJEVA U OBLIKOVANJU PROGRAMSKE POTPORE ( engl. R equirements engineering - RE)

1. INŽENJERSTVO ZAHTJEVA U OBLIKOVANJU PROGRAMSKE POTPORE (engl. Requirements engineering - RE) Općenito: Inženjerstvo zahtjeva je proces izrade specifikacije programskog produkta. To je prva generička aktivnost tijekom svakog procesa programskog inženjerstva.

2. INŽENJERSTVO ZAHTJEVA (RE) • Ciljevi ove prezentacije: • Uvesti koncepte zahtjeva. • Objasniti višedimenzijsku klasifikaciju zahtjeva. • Navesti različite mogućnosti izražavanja zahtjeva. • Opisati dokumentiranje zahtjeva sukladno IEEE standardu. • Izvor: Sommerville, I., Software engineering, 8th ed., Addison • Wesley, 2007.

3. INŽENJERSTVO ZAHTJEVA (RE) • U procesu izrade specifikacije postoje postupci pronalaženja, analiziranja, dokumentiranja i provjere zahtijevanih usluga sustava, te ograničenja u uporabi. • Zahtjevi sami za sebe su dokumenti koji specificiraju usluge sustava i ograničenja u uporabi. • Višedimenzijska klasifikacija zahtjeva: • Prema razini detalja razlikujemo: • Korisnički zahtjevi • Zahtjevi sustava • Specifikacija programske potpore • Korisnički i zahtjevi sustava razlikuju se prema sadržaju: • Funkcionalni zahtjevi • Nefunkcionalni zahtjevi (program, organizacija, vanjski) • Zahtjevi domene primjene

4. Klasifikacija zahtjeva s obzirom na razinu detalja • Korisnički zahtjevi su specifikacija visoke razine apstrakcije (obično u okviru ponude za izradu programskog produkta). Pišu se u prirodnom jeziku i grafičkim dijagramima. Moraju biti razumljivi ne-tehničkom osoblju. • Zahtjevi sustavasu vrlo detaljna specifikacija (uobičajeno nakon prihvaćanja ponude, a prije sklapanja ugovora). Pišu se strukturiranim prirodnim jezikom, posebnim jezicima za oblikovanje sustava, dijagramima i matematičkom notacijom. • Specifikacija programske potporeje najdetaljniji opis i objedinjuje korisničke i zahtjeve sustava.

5. TKO ČITA ZAHTJEVE (prema razini detalja) • Korisnički zahtjevi • Klijenti (rukovoditelji – manageri) • Krajnji korisnici sustava • Klijenti (inženjeri) • Rukovoditelji za pisanje ugovora • Specijalisti za oblikovanje sustava (arhitekti) • Zahtjevi sustava • Krajnji korisnici sustava • Klijenti (inženjeri) • Specijalisti za oblikovanje sustava (arhitekti) • Specijalisti za razvoj programske potpore • Specifikacija programske potpore • Klijenti (inženjeri) – možda ? • Specijalisti za oblikovanje sustava (arhitekti) • Specijalisti za razvoj programske potpore

6. Klasifikacija zahtjeva obzirom na sadržaj • (odnose se kako na korisničke tako i na zahtjeve sustava) • Funkcionalni zahtjevi • Izjave o uslugama koje sustav mora pružati, kako će sustav reagirati na određeni ulazni poticaj, te kako bi se sustav trebao ponašati u određenim situacijama. • Nefunkcionalni zahtjevi • Ograničenja u uslugama i funkcijama, kao što su vremenska ograničenja, (ne)usvojeni standardi, zahtjevi kvalitete, platformski zahtjevi, ograničenja u procesu razvoja i oblikovanja itd. • Zahtjevi domene primjene • Zahtjevi koji proizlaze iz domene primjene sustava kao i oni koji karakteriziraju tu domenu.

7. ZAHTJEVI • Prema razini detalja razlikujemo: • Korisnički zahtjevi • Zahtjevi sustava • Specifikacija programske potpore • Korisnički i zahtjevi sustava razlikuju se prema sadržaju: • Funkcionalni zahtjevi • Nefunkcionalni zahtjevi (program, organizacija, vanjski) • Zahtjevi domene primjene

8. FUNKCIONALNI ZAHTJEVI • Primjer: Hipotetski sustav LIBSYS • Knjižničarski sustav koji pruža jedinstveno sučelje prema bazama članaka u različitim knjižnicama. Korisnik može pretraživati, spremati, ispisivati članke za osobne potrebe. • Zahtjevi: • Korisnik mora moći pretraživati početni skup baza članaka ili njihov podskup. • Sustav mora sadržavati odgovarajuće preglednike koji omogućuju čitanje članaka u knjižnici. • Svakoj narudžbi mora se alocirati jedinstveni identifikator (ORDER_ID) koji korisnik mora moći kopirati u svoj korisnički prostor.

9. Poteškoće u navedenom primjeru: prirodni jezik • Nedostatak jasnoće (preciznost nije lako postići bez detaljiziranog ali naporno čitljivog dokumenta). • Miješaju se funkcionalni i nefunkcionalni zahtjevi. • Nenamjerno objedinjavanje više zahtjeva u jednom. • Nejasno postavljeni zahtjevi mogu biti različito interpretirani od korisnika i razvojnih timova što dovodi do problema u procesu razvoja i kršenju ugovora! • Npr. u LIBSYS sustavu nejasno je : “odgovarajući preglednik”: • Namjera korisnika – više preglednika posebne namjene za svaki tip dokumenta. • Namjera razvojnog tima – samo preglednik teksta kao bitnog sadržaja dokumenta.

10. Još jedan primjer korisničkih funkcionalnih zahtjeva: • Potporna rešetka u grafičkom uređivaču (engl. editor) • Kako bi se olakšalo postavljanje entiteta na crtež, korisnik može preko upravljačkog panelauključiti rešetkuucentimetrima ili inčima. Inicijalno je rešetka isključena. Rešetka se može uključiti i isključitikao i izmijeniti centimetre i inčeu svako vrijeme rada s editorom. Bit će osigurana opcija smanjivanja slike kako bi stala na zaslon, ali broj prikazanih crta rešetke će biti reduciran kako te crte ne bi popunile manje slike. • Miješaju se različiti tipovi zahtjeva: • Nefunkcionalni (mjerne jedinice rešetke). • Nefunkcionalni ulazno-izlazni zahtjevi (prebacivanje između tipova rešetki). • Zaključak: Prirodni jezik u specifikaciji korisničkih zahtjeva mora se koristiti vrlo pažljivo i treba biti nadopunjen grafičkim prikazima.

11. Kompletnost i konzistencija funkcionalnih zahtjeva • Kompletni zahtjevi: • Sadrže opise svih zahtijevanih mogućnosti. • Konzistentni zahtjevi: • Ne smiju sadržavati konflikte ili kontradikcije u opisima zahtijevanih mogućnosti. • U praksi je nemoguće postići kompletan i konzistentan dokument o zahtjevima.

12. ZAHTJEVI • Prema razini detalja razlikujemo: • Korisnički zahtjevi • Zahtjevi sustava • Specifikacija programske potpore • Korisnički i zahtjevi sustava razlikuju se prema sadržaju: • Funkcionalni zahtjevi • Nefunkcionalni zahtjevi (program, organizacija, vanjski) • Zahtjevi domene primjene

13. NEFUNKCIONALNI ZAHTJEVI • Zahtjevi programskog produkta: • Zahtjevi koji specificiraju da se isporučeni produkt mora ponašati na osobit način (npr. vrijeme odziva). • Organizacijski zahtjevi: • Zahtjevi koji su rezultat organizacijskih pravila i procedura (npr. uporaba propisanog standardnog procesa razvoja, DoD ADA). • Vanjski zahtjevi: • Zahtjevi koji proizlaze izvan sustava i razvojnog procesa (međusobna operabilnost s drugim sustavima, legislativni zahtjevi i sl.).

14. Nefunkcionalni zahtjevi– primjer LIBSYS Zahtjevi programskog produkta: Npr.: Korisničko sučelje LIBSYS sustava bit će implementirano kao jednostavni HTML bez uporabe okvira ili Java “appleta”. Organizacijski zahtjevi: Npr.: Proces razvoja sustava i isporučeni dokumenti moraju slijediti standard XYZCo-SP-STAN-95. Vanjski zahtjevi: Npr.: Sustav neće operatorima otkriti osobne informacije o klijentima (osim njihovog imena i referentnog broja).

15. ZAHTJEVI • Prema razini detalja razlikujemo: • Korisnički zahtjevi • Zahtjevi sustava • Specifikacija programske potpore • Korisnički i zahtjevi sustava razlikuju se prema sadržaju: • Funkcionalni zahtjevi • Nefunkcionalni zahtjevi (program, organizacija, vanjski) • Zahtjevi domene primjene

16. ZAHTJEVI DOMENE PRIMJENE Zahtjevi domene primjene mogu biti novi funkcionalnizahtjevi ili ograničenjana postojeće zahtjeve. Npr. LIBSYS zahtjevi domene primjene: Zbog restrikcija u pravima kopiranja neki dokumenti se po dolasku moraju odmah izbrisati. Ovisno o zahtjevu korisnika dokumenti se mogu ispisati lokalno kako bi se ručno dostavili korisniku. Posebni problemi zahtjeva domene primjene: Razumljivost:programeri ne razumiju domenu primjene i traže detaljan opis zahtjeva. Implicitnost: specijalisti domene poznaju primjenu tako dobro da podrazumijevaju zahtjeve (koje tada eksplicitno ne određuju).

17. ZAHTJEVI • Prema razini detalja razlikujemo: • Korisnički zahtjevi • Zahtjevi sustava • Specifikacija programske potpore • Korisnički i zahtjevi sustava razlikuju se prema sadržaju: • Funkcionalni zahtjevi • Nefunkcionalni zahtjevi (program, organizacija, vanjski) • Zahtjevi domene primjene

18. ZAHTJEVI SUSTAVA • Detaljnija specifikacija funkcija sustava, njegovih usluga i ograničenja nego zahtjevi korisnika. • Uloga tih specifikacija je definiranje oblikovanja sustava. • Mogu se uključiti u ugovor o isporuci sustava. • Zahtjevi sustava mogu se definirati ili ilustrirati nekim od modelasustava. • U principu zahtjevi određuju ŠTO sustav mora raditi, a oblikovanje (dizajn) određuje KAKO će se to ostvariti. • U praksi su zahtjevi i oblikovanje neodvojivi. • Arhitektura sustava strukturira zahtjeve. • Sustav često mora raditi u sinergiji s drugim sustavima koji generiraju zahtjeve na oblikovanje.

19. IZRAŽAVANJE ZAHTJEVA SUSTAVA • Strukturirani prirodni jezik • Definiranje standardnih formulara i obrazaca u kojima se izražavaju zahtjevi (definicije, ulazni podaci i izvori, prethodni i posljedični uvjeti, popratni efekti, …). Prednost ovakve specifikacije je u zadržavanju izražajnosti prirodnog jezika, ali uz nametnutu izvjesnu uniformnost. Nedostatak je ograničena terminologija. U praksi nema usvojene globalne standardizacije. • Jezik za opis oblikovanja (npr. SDL) • Poput programskog jezika, ali s više apstraktnih obilježja, definira se operacijski model sustava. • Grafička notacija (npr. UML) • Grafički jezik proširen tekstom. • Matematička specifikacija (FSM, logika i sl.) • Notacija zasnovana na matematičkom konceptu. Najstrože definirana specifikacija. Kupci ju ne vole jer ju ne razumiju.

20. Primjer zahtjeva sustava strukturiranim prirodnim jezikom (otkuda ulazi) (kamo izlazi)

21. Izražavanje korisničkih zahtjeva i zahtjeva sustava u predmetu Oblikovanje programske podrške “Strukturirani” prirodni jezik Koristit će se u početnom zadavanju projekata. Posebni jezici za opis oblikovanja (npr. SDL) Neće se razmatrati u ovom kolegiju. Grafička notacija (UML) Bit će detaljno prikazana u nastavku predavanja. Matematička specifikacija U okviru kolegija razmatrat će se FSM, propozicijska i predikatna logika, vremenska logika.

22. ZAHTJEVI SUSTAVA: SPECIFIKACIJA SUČELJA • Specifikacija sučelja prema korisniku i prema drugim sustavima je poseban problem. Postoje tri tipa sučelja: • Proceduralno sučelje (skup usluga kroz sučelje – API: “Application Programming Interface” = primjensko programsko sučelje). • Strukture podataka koje se izmjenjuju (najčešće opisane grafičkom notacijom, npr. Entity-Relation-Attribute, ERA model). • Predstavljanje podataka (što znače pojedini bitovi u riječi). • Uvođenje formalne notacije jednoznačno opisuje sučelje, ali traži specijalističko znanje. Nema preporučenog standarda. Npr.:

23. IEEE STANDARD (NORMA): • ŠTO DOKUMENT ZAHTJEVA MORA SADRŽAVATI • Predgovor • Uvod • Rječnik pojmova • Definicije korisničkih zahtjeva • Specifikacija zahtjeva sustava • Arhitektura sustava • Modeli sustava • Evolucija sustava • Dodaci • Indeks

24. ZAKLJUČCI: • Zahtjevi jednoznačno postavljaju što sustav treba raditi i definiraju ograničenja u implementaciji i radu sustava. Ne postoji usvojeni jedinstveni standard za izražavanje zahtjeva. • Korisnički zahtjevi su izjave na višoj apstraktnoj razini što bi sustav trebao raditi. Pišu se u prirodnom jeziku, tablicama ili dijagramima. • Zahtjevi sustava su detaljne specifikacije o funkcijama sustava. Izražavaju se strukturiranim prirodnim jezikom, specifičnim jezikom za oblikovanje (npr. SDL), grafičkom notacijom (npr. ERA, UML), i matematičkom specifikacijom (npr. vremenska logika). • Funkcionalni zahtjevi (korisnički i zahtjevi sustava) definiraju usluge koje sustav osigurava. • Nefunkcionalni zahtjevi (korisnički i zahtjevi sustava) postavljaju ograničenja na sustav ili na proces oblikovanja sustava. • Dokument zahtjeva programskog produkta je usklađen skup izjava o svim zahtjevima na sustav. • IEEE standard (norma) je korisna početna točka za definiranje detaljiziranog specifičnog načina pisanja dokumenta zahtjeva.