Lekcija 5 Flashcards
5.1 Šta su zahtevi za softver? Čime se bavi inženjerstvo zahteva? Kakvih vrsta zahteva ima? Objasnite ih detaljnije. Šta su funkcionalni zahtevi? Dajte primere. Šta su nefunkcionalni zahtevi. Dajte primere. Kako se pišu zahtevi? Šta je kompletnost, a šta konzistentnost zahteva?
Zahtevi za razvoj softverskog sistema su opisi onoga što treba sistem da radi.
Inženjerstvo zahteva se bavi nalaženjem, analizom, dokumentovanjem i proverom servisa i ograničenja sistema.
Vrste zahteva:
1. Zahtevi korisnika - iskazi u običnom jeziku i sa dijagramima, o servisima sistema koje očekuju korisnici sistema i ograničenja pod kojima mora da sistem radi.
2. Zahtevi sistema - detaljniji opisi funkcija softverskog sistema, servisa i operacionih ograničenja.
Funkcionalni zahtevi opisuju šta bi sistem trebalo da radi. Korisnici ih definišu na apstraktan način, a inženjeri razvoja ih pretvaraju u detaljne zahteve (ulaz, izlaz, izuzeci…).
Nefunkcionalni zahtevi su zahtevi koji nisu direktno povezani sa servisima koje sistem treba da obezbedi svojim korisnicima, već definišu ograničenja implementacije sistema.
5.2 Šta su nefunkcionalni zahtevi? Zašto su oni važni? Navedite osnovne grupe nefunkcionalnih zahteva i opišite svaki. Koji se problemi javljaju kod utvrđivanjanefunkcionalnih zahteva? Koja je metrika nefunkcionalnih zahteva? Koje su teškoće u njenoj primeni?
Nefunkcionalni zahtevi su zahtevi koji nisu direktno povezani sa servisima, već sa svojstvim tih servisa, kao što su pouzdanost, brzina odgovora, i korišćenje memorije.
Važni su zato što određuju i ograničavaju karakteristike čitavog sistema.
Osnovne grupe:
1. Zahtevi proizvoda - opisuju ili ograničavaju ponašanje softvera (npr, performanse).
2. Organizacioni zahtevi - sistemski zahtevi koji su rezultat
organizacionog ustrojstva kupca sistema (npr. poslovni procesi i standardi).
3. Spoljni zahtevi - odražavaju zahteve koji dolaze iz spoljnjeg okruženja sistema (npr., propisi).
Problemi:
Nefunkcionalni zahtevi mogu da budi kontradiktorni, tj. u sukobu sa drugim funkcionalnim ili nefunkcionalnim zahtevima.
Metrike:
Brzina - broj transakcija, vreme odziva, osvežavanje monitora
Veličina - MB
Lakoća upotrebe - vreme obuke, broj frejmova sa pomoćnim informacijama
Pouzdanost - raspoloživost, verovatnoća otkaza rada sistema
Robusnost - procenat događaja koji dovode do prekida rada, verovatnoća oštećenja podataka prilikom prekida rada
Prenosivost - procenat iskaza zavisnih od cilja
Teškoće:
1. Nije uvek lako koristiti merljiva svojstva prilikom definisanja nefunkcionalnih zahteva.
2. Korisnici možda ne mogu da odrede poželjne vrednosti. 3. Cena ispunjenje nekog zahteva može biti isuviše velika za korisnika
5.3 Šta je dokument sa zahtevima? Kako se ovaj dokument koristi kod različitih pristupa razvoju softvera? Ko su korisnici tog dokumenta i zašto? Kako se određuje stepen detaljnosti dokumenta sa specifikacijom zahteva? Koja je
struktura dokumenta sa specifikacijom zahteva.
Dokument sa zahtevima za softver je zvanični dokument koji razvojni tim treba da primeni. On uključuje i zahteve korisnika i detaljnu specifikaciju zahteva za sistem.
Kod primene metoda agilnog razvoja ovaj dokument se najčešće i ne koristi. Kod ekstremnog programiranja zahtevi se definišu inkrementalno i zapisuju na karticama kao korisničke priče ili scenariji. Kod poslovnih
aplikacija, koje nemaju stabilne zahteve, to je i dobra praksa. (definicija s LAMS-a nema veze s mozgom)
Korisnici tog dokumenta:
1. Korisnici sistema
2. Menadžeri
3. Sistem inženjeri
4. Inženjeri testiranja sistema
5. Inženeri održavanja sistema
Stepen detaljnosti se određuje na osnovu toga kom korisniku treba pokazati koji stepen.
Struktura dokumenta sa specifikacijom zahteva:
1. Predgovor
2. Uvod
3. Rečnik
4. Definicija zahteva korisnika
5. Arhitektura sistema
6. Specifikacija zahteva
7. Modeli
8. Evolucija
9. Dodaci
10. Indeks
5.4 Kako se specificiraju zahtevi? Kako treba da budu napisani? Da li postoji veza između arhitekture softverskog sistema i sistemskih zahteva? Koje su mogući načini izražavanja sistemskih zahteva (notacija)? Koje su preporuke za specificiranje zahteva običnim, govornim jezikom?
Specifikacija zahteva je proces pisanja korisničkih i sistemskih zahteva u dokument sa zahtevima.
Ovi zahtevi bi trebalo da budu: jasni, nedvosmisleni, lako razumljivi, kompletni, i konsistentni.
Nefunkcionalni zahtevi mogu da utiču na celu arhitekturu sistema, što znači da postoji veza između sistemskih zahteva i arhitekture sistema.
Zahtevi sistema, pored korišćenja običnog jezika, mogu da koriste i druge načine pisanja, kao što su grafički modeli ili matematički sistemi.
Zahtevi se pišu numerisanim rečenicama običnim, govornim jezikom, svaka rečenica se odnosi na jedan zahtev.
5.5 Koje osnovne aktivnosti proces inženjeringa zahteva? Dajte spiralni pogled na proces inženjerstva zahteva i objasnite ga. Opišite metod slučajeva upotrebe u UML za definisanje zahteva.
Procesi inženjerstva zahteva čine četiri osnovne aktivnosti:
1. Studija izvodljivosti - ocena da li je proces koristan za
poslovanje.
2. Prikupljanje i analiza zahteva - otkrivanje zahteva.
3. Specifikacija zahteva - konverzija zahteva u standardni oblik.
4. Validacija - provera da zahtevi odražavaju sistem koji
kupac/korisnik želi.
Kod spiralnog pogleda u svakoj vremnskoj fazi se troši određena količina vremena za rad. U početku se najviše vremena troši na razumevanje glavnih poslovnih i nefunkcionalnih zahteva, kao i zahteve korisnika sistema.
Spiralni model inženjerstva zahteva da se uzime u obzir različit nivo detaljnosti zahteva. Sa povećanjem broja iteracija oko spirale detaljnost zahteva se povećava.
Slučaj korišćenja utvrđuje učesnike (koji se u terminologiji UML nazivaju akterima) koji učestvuju u interakciji sa softverskim sistemom i ima svoj naziv. Model slučajeva korišćenja obično se sastoji od više dijagrama slučajeva korišćenja.
5.6 Zašto softverski inženjeri treba da razgovaraju sa korisnicima ili kupcima softvera. Šta su akteri softverskog sistema? Koji su ostali akteri sistema, sa kojima treba razgovarati u procesu prikupljanja zahteva? Nacrtajte model prikupljanja i analize sistema, i objasnite ga, tj. njegove aktivnosti. Koje se poteškoće javljaju pri radu sa akterima sistema? Kako olakšati prikupljanje zahteva? Pored razgovora sa akterima, koji su drugi izvori informacija značajnih za definisanje zahteva?
Svi koji imaju neki direktni ili indirektni interes na zahteve sistema se nazivaju akterima sistema. To mogu biti korisnici od krajnjih koji u interakciji sa sistemom obavljaju svoj posao, pa do menadžera spoljnih aktera, kao što su
regulacione institucije, koje daju potvrde za prihvatljivost sistema.
«opis crteža»
Četiri polja povezana strelicom u smeru kazaljke na satu.
> otkriće zahteva > klasifikacija i organizacija > prioriteti > specifikacija
Prikupljanje zahteva je otežano iz sledećih razloga:
1. Sistemski akteri često ne znaju da definišu zahteve dovoljno detaljno i jasno.
2. Akteri sistema definišu zahteve koristeći svoje termine i svoje implicitno znanje.
3. Različiti akteri imaju različite zahteve i izražavaju ih na različite načine. Inženjer koji prikuplja zahteve mora da otkrije konfliktne zahteve.
4. Politički faktori mogu da imaju uticaje na zahteve sistema.
5. Ekonomsko i poslovno okruženje u kome se prikupljaju zahtevi je dinamično i menja se.
Kako bismo razjasnili zahteve, organizujemo sastanke sa akterima sistema na kojima se usaglašavaju stavovi oko zahteva.
Pored razgovora, za definisanje zahteva koristimo i scenarije, prototipe, kako bismo pomogli akterima da razumeu kakav bi sistem trebalo da bude.
5.7 Za šta služe intervjui u procesu prikupljanja zahteva, i koje dve vrste intervjua postoje? Za šta su intervjui dobri, a za šta nisu? Koje karakteristike treba da ima lice koje obavlja intervju (intrevjuer)?
U intervjuima, tim inženjera postavlja pitanja akterima o sistemu koji oni trenutno koriste i o sistemu koji treba da se razvije.
Postoje dve vrste:
1. Zatvoreni intervjui - kada akteri odgovaraju na unapred
pripremljena pitanja.
2. Otvoreni intervjui - kada ne postoje unapred definisana pitanja.
Intervjui su dobri za razumevanje čime se akteri bave, kako bi mogli da komuniciraju sa sistemom, kao i za utvrđivanje poteškoća koje oni imaju sa sadašnjim sistemom.
Međutim, intervjui nisu tako korisni za
razumevanje zahteva iz domena aplikacije.
Intervjuer treba da razume specifičnu terminologiju i žargon, kao i da pita specijalistu o svim zahtevima.
5.8 Šta su scenariji i čemu služe u procesu prikupljanja i specificiranja zahteva? Koji su osnovni elementi jednog scenarija? U kojim formama se može opisati
scenario? Šta je UML slučaj korišćenja? Kako se on opisuje? Dajte jedan primer. Kako se scenariji koriste u vezi sa UML slučajevima upotrebe? Da li se sekvencijalni dijagram može koristiti za grafičko predstavljanje scenarija slučaja upotrebe? Dajte jedan primer.
Scenariji su opisi interakcije aktera i sistema, tj. interaktivnih sesija. Ako osoba koja vodi intervju, prikaže intervjuisanoj osobi scenarijo u kome opisuje očekivanu interakciju aktera sa sistemom, intervjuisana osoba će mnogo lakše izneti svoje sugestije i zahteve, nego ako se razgovor vodi apstraktno, bez početne skice scenarija.
Osnovni elementi:
1. Opis šta sistem, i korisnici očekuju kada počne scenario.
2. Primarni scenario - opis normalnog toka događaja u scenariju.
3. Sekundarni scenario - opis šta može da ide pogrešnim tokom i kako taj problem razrešiti.
4. Informacija o drugim aktivnostima koje mogu da se istovremeno izvršavaju.
5. Opis stanja sistema kada se scenario završi.
Postoje različite forme scenarija i one obezbeđuju različite tipove informacija na različitim nivoima detalja opisa sistema. Postoji primarni (normalni) scenario i više sekundarnih scenarija koji opisuju situacije do
kojih može da dođe zbog nekih grešaka.
Slučaj korišćenja utvrđuje učesnike (koji se u terminologiji UML nazivaju akterima) koji učestvuju u interakciji sa softverskim sistemom i ima svoj naziv.
Za svaki slučaj korišćenja neophodno je definisati osnovni (primarni) scenario i pomoćne (sekundarne ) scenarije koji u tekstualnoj formi opisuju interakciju aktera i sistema. Osnovni scenario opisuje osnovnu funkcionalnost sistema koju slučaj korišćenja opisuje.
Sekvencijalni dijagram prikazuje redosled interakcija aktera sa osnovnim objektima sistema, ali prikazuje i interakciju između ovih objekata.
5.9 . Šta je etnografija? Kako se ona koristi za otkrivanje zahteva? Kako se etnografija može povezati sa korišćenjem prototipova softverskih sistema? Kada je posebno preporučljivo koristiti etnografiju?
Etnografija je tehnika osmatranja koja se koristi radi razumevanja operacionih procesa.
Analitičar svakodnevno osmatra i beleži stvarne zadatke koji učesnici rade. Na taj način se mogu otkriti i implicitni zahtevi koji odražavaju stvarni način rada, a ne formalni proces koje definiše organizacija.
Etnografija se može kombinovati sa izradom prototipa (slika), jer ukazuje na vrstu prototipa koji su potrebni, te time i smanjuje njihov neophodan broj.
Etnografija je naročito korisna u otkrivanju dve vrste zahteva:
1. Zahtevi koji proističu iz načina kako ljudi stvarno rade (često i kršeći neke propise).
2. Zahtevi koji proističu iz kooperacije i aktivnosti drugih ljudi.
5.10 Šta je validacija zahteva? Kako validacija utiče na troškove razvoja sistema? Kako se vrši validacija (provera zahteva) dokumenta koji specificira zahteve? Koje se tehnike validacije zahteva primenjuju?
Validacija zahteva je provera da li zahtevi stvarno definišu sistem koji kupac želi.
Trošak realizovanja promene sistema koji je uzrokovan problemom zahteva je mnogo veći od popravke projekta ili grešaka kodiranja. Razlog za ovo je da promena zahteva obično znači da projektovanje i implementacija sistema moraju da budu promenjeni i da sistem mora biti testiran ponovo.
Validacija se vrši pomoću ovih pet koraka:
1. Provera validacije
2. Provera konzistencije
3. Provera kompletnosti
4. Provera realizma
5. Verifikacija
Tehnike:
1. Pregledi zahteva
2. Prototip
3. Stvaranje test slučaja
5.11 . Čime se bavi upravljanje zahtevima? Koji je glavni izazov? Zašto dolazi do promena zahteva? Šta je evolucija zahteva? Zašto se javljaju novi zahtevi i posle puštanja sistema? Koje odluke treba doneti da bi se planski upravljalo zahtevima? Kakva se automatizovana podrška može dati aktivnostima upravljanja zahtevima? Kako upravljati promenama zahteva? U čemu je prednost primene formalizovanog procesa upravljanja zahtevima? Koje su faze procesa upravljanja promenama zahteva? Do kakvog se problema može doći ubacivanjem stalno novih zahteva? Koja je specifičnost promene zahteva kod agilnog razvoja softvera?
Upravljanje zahtevima je proces razumevanja i kontrole promene u zahtevima sistema.
Glavni izazov je što se zahtevi stalno menjaju, kao i softver, zbog čega dolazi do nemogućnosti sagledavanja svih zahteva kod ovih sistema.
Kada se novi sistem pusti u upotrebu, neminovno se jave novi zahtevi. Teško krajnji korisnici i akteri sistema mogu da sagledaju efekte novog sistema na njihove poslovne procese i na način obavljanja posla. Posle sticanja prvih iskustava sa novim sistemom, krajnji korisnici sistema počinju da otkrivaju nove potrebe i prioritete.
Evolucija zahteva:
1. Početno razumevanje problema
2. Početni zahtevi
- Promenjeno razumevanje problema
- Promenjeni zahtevi
Novi zahtevi se javljaju iz nekoliko razloga:
1. Poslovno i tehničko okruženje sistema se uvek menja posle instalacije sistema (novi hardver, novi interfejsi, novi poslovni prioriteti, novi propisi).
2. Ljudi koji naručuju ili biraju sistem i ljudi koji koriste sistem, najčešće nisu isti. Kupci sistema postavljaju zahteve zbog organizacijskih i finansijskih ograničenja. To može da bude u sukobu sa zahtevima korisnika sistema.
3. Veliki sistemi obično imaju šaroliku zajednicu korisnika, sa različitim zahtevima i prioritetima, koji mogu biti i međusobno suprotstavljeni.
