PROCESI INENJERSTVA ZAHTJEVA ili kako generirati specifikaciju Generike

PROCESI INŽENJERSTVA ZAHTJEVA (ili kako generirati specifikaciju) Generičke aktivnosti u programskom inženjerstvu: • Specifikacija (temeljem analize zahtjeva) • Razvoj i oblikovanje • Validacija i verifikacija • Evolucija 1

PROCESI INŽENJERSTVA ZAHTJEVA Proces u općem smislu je strukturiran (organiziran) skup aktivnosti koji vodi nekom cilju. Proces inženjerstva zahtjeva je skup aktivnosti koje generiraju i dokumentiraju zahtjeve. U ovoj prezentaciji naglasak je na: • Opisu temeljnih aktivnosti u procesima zahtjeva i njihovih odnosa. • Upoznavanje s tehnikama za izlučivanje i analizu zahtjeva. • Opisu validacije zahtjeva i uloge recenzenta. • Analizi upravljanja zahtjevima (engl. requirements management). 2

PROCESI I MODELI INŽENJERSTVA ZAHTJEVA Procesi koji su u uporabi u inženjerstvu zahtjeva razlikuju se ovisno o domeni primjene, ljudskim resursima i organizaciji koja oblikuje zahtjeve. Nema jedinstvenog procesa inženjerstva zahtjeva! U okviru svakog procesa postoje: generičke aktivnosti inženjerstva zahtjeva (različito od generičkih aktivnosti programskog inženjerstva) • Studija izvedivosti (engl. feasibility study) • Izlučivanje (otkrivanje) zahtjeva (engl. requirements elicitation), analiza i specifikacija. • Validacija zahtjeva • Upravljanje promjenama u zahtjevima 3

PROCESI I MODELI INŽENJERSTVA ZAHTJEVA Procesi inženjerstva zahtjeva mogu se predstaviti modelima koji opisuju kako se ti procesi provode. Dva su uobičajena modela procesa inženjerstva zahtjeva: • klasični • spiralni 4

KLASIČNI MODEL PROCESA INŽENJERSTVA ZAHTJEVA Studija izvedivosti Izlučivanje i analiza Aktivnosti Specifikacija zahtjeva Validacija zahtjeva iteracije Modeli sustava iteracije Produkti Korisnički zahtjevi sustava Dokument zahtjeva 5

SPIRALNI MODEL PROCESA INŽENJERSTVA ZAHTJEVA Zahtjevi sustava i modeliranje. Korisnički zahtjevi. Specifikacija Poslovni zahtjevi. Izlučivanje zahtjeva sustava Studija izvedivosti Izlučivanje korisničkih zahtjeva. Izrada prototipa Revizije Izlučivanje Validacija Konačan dokument zahtjeva 6

Spiralni model inženjerstva zahtjeva • Tro-stupanjska aktivnost (specifikacija, validacija, izlučivanje). • Promatra proces inženjerstva zahtjeva kroz iteracije ciklusa svih njegovih generičkih aktivnosti • To je razlika u odnosu prema klasičnom modelu, gdje se ne ponavlja cijeli ciklus! • U svakoj iteraciji je različit intenzitet aktivnosti. U ranim iteracijama fokus na razumijevanju poslovnog modela, u kasnijima modeliranje sustava. • Zahtjevi se u pojedinim iteracijama specificiraju s različitom razinom detalja. 7

DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAJTHEVA • Studija izvedivosti • Izlučivanje, analiza i specifikacija zahtjeva (ovo je najznačajniji dio) • Validacija zahtjeva • Upravljanje promjenama u zahtjevima 8

STUDIJA IZVEDIVOSTI (engl. feasibility study) Studija izvedivosti na početku procesa inženjerstva zahtjeva određuje da li se predloženi sustav isplati (tj. da li je vrijedan uloženih sredstava). Ulazna informacija je preliminaran skup zahtjeva poslovnog procesa. To je kratka fokusirana studija koja u pisanom dokumentu provjerava i odgovara na pitanja: • Da li sustav doprinosi ciljevima organizacije u koju se uvodi? • Da li se sustav može izvesti postojećom tehnologijom i predviđenim sredstvima? • Da li se predloženi sustav može integrirati s postojećim sustavima organizacije u koju se uvodi? 9

PROVEDBA STUDIJE IZVEDIVOSTI Temelji se na određivanju koje informacije su potrebne za studiju, prikupljanje informacija i pisanju izvješća. Pitanja za ljude u organizaciji: • Što ako se sustav ne implementira? • Koji su trenutni problemi procesa organizacije? • Kako bi predloženi sustav pomogao u poboljšanju procesa? • Koji se problemi mogu očekivati pri integraciji novoga sustava? • Da li je potrebna nova tehnologija ili nove vještine? • Koje dodatne resurse organizacije traži implementacija novoga sustava? 10

DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAJTHEVA • Studija izvedivosti • Izlučivanje, analiza i specifikacija zahtjeva (ovo je najznačajniji dio) • Validacija zahtjeva • Upravljanje promjenama u zahtjevima 11

IZLUČIVANJE I ANALIZA ZAHTJEVA (najznačajnija aktivnost u procesu inženjerstva zahtjeva) • Općenito (dionici, problemi, modeli, aktivnosti, pogledi). • Metode u izlučivanju i analizi zahtjeva: • Intervjuiranje kao metoda izlučivanja. • Scenarij kao metoda izlučivanja. • Izlučivanje i specificiranje zahtjeva obrascima uporabe (UML “use_cases”). • Specificiranje dinamičkih interakcija u sustavu (UML sekvencijski dijagrami). 12

OPĆENITO O IZLUČIVANJU I ANALIZI ZAHTJEVA Poznato i kao izlučivanje (engl. elicitation) zahtjeva ili otkrivanje (engl. discovery) zahtjeva. • Uključuje stručno tehnički obrazovano osoblje koje u zajedničkom radu s kupcima razjašnjava domenu primjene, definira usluge koje sustav treba pružiti, te određuje ograničenja u radu sustava. • Može uključivati: krajnje korisnike sustava, rukovoditelje, inženjere uključene u održavanje sustava, eksperte domene primjene, predstavnike sindikata i sl. • Svi se oni nazivaju dionici (engl. stakeholders). 13

SPIRALNI MODEL IZLUČIVANJA I ANALIZE ZAHTJEVA Klasifikacija i organizacija zahtjeva Ustanovljavanje prioriteta i pregovaranje Početak: Izlučivanje (otkrivanje) zahtjeva Dokumentiranje zahtjeva 14

AKTIVNOSTI U SPIRALI IZLUČIVANJA I ANALIZE ZAHTJEVA Izlučivanje (otkrivanje) zahtjeva Interakcija s dionicima s ciljem otkrivanja njihovih zahtjeva. Zahtjevi domene primjene se također definiraju na ovom stupnju. Izvori informacija su dokumenti, dionici, slični sustavi. Klasifikacija i organizacija zahtjeva Grupiraju se srodni zahtjevi i organiziraju u koherentne grozdove (klastere). Ustanovljavanje prioriteta i pregovaranje Zahtjevi se razvrstavaju po prioritetima i razrješavaju se konflikti. Dokumentiranje zahtjeva Zahtjevi se dokumentiraju (formalnim i neformalnim dokumentima) i ubacuju u sljedeći ciklus spirale. 15

PROBLEMI U IZLUČIVANJU I ANALIZI ZAHTJEVA • Dionici ne znaju što stvarno žele (teško artikuliraju zahtjeve, ili su zahtjevi nerealni s obzirom na cijenu). • Dionici izražavaju zahtjeve na različite, njima specifične načine (posjeduju implicitno znanje o svojem radu - domeni). • Različiti dionici mogu imati konfliktne zahtjeve i izražene na različite načine. • Organizacijski i politički faktori mogu utjecati na zahtjeve (npr. rukovoditelj traži da uvedeni sustav ima značajke koje povećavaju njegov utjecaj u organizaciji). • Zbog dinamike ekonomskog i poslovnog okruženja zahtjevi se mijenjaju za vrijeme procesa analize. • Uz promjenu poslovnog okruženja pojavljuju se novi dionici s novim, specifičnim zahtjevima. 16

PRIMJER različitih dionika za npr. Sustav bankomata: • Bankovni klijenti • Predstavnici drugih banaka • Bankovni rukovoditelji (engl. manager) • Šalterski službenici • Administratori baza podataka • Rukovoditelji sigurnosti • Marketing odjel • Inženjeri održavanja sustava (sklopovlja i programske potpore) • Regulatorna tijela za bankarstvo 17

POGLEDI (engl. viewpoints) Različiti dionici imaju različitu perspektivu i fokus na zahtjeve. Pogledi su način strukturiranja zahtjeva tako da oslikavaju perspektivu i fokus različitih dionika. Ova više-perspektivna analiza omogućuje razrješavanje konflikata. Tipovi pogleda Pogledi interakcije (Ljudi i drugi sustavi koji izravno komuniciraju sa sustavom. Primjer bankomata: klijenti i korisnička baza podataka). Indirektni pogledi (Dionici koji ne koriste sustav izravno, ali utječu na zahtjeve. Primjer bankomata: rukovoditelji i osoblje zaduženo za sigurnost). Pogledi domene primjene (Karakteristike domene i ograničenja koja utječu na zahtjeve. Primjer bankomata: standardi u komunikaciji između banaka). 18

POGLEDI U PRIMJERU SUSTAVA KNJIŽNICE (ranije naveden hipotetski sustav LIBSYS) Svi pogledi Indirektni Interakcija Domena primjene 19

METODE U IZLUČIVANJU I ANALIZI ZAHTJEVA • Intervjuiranje • Scenarij • Obrasci uporabe (engl. use case) • Dijagrami interakcija (sekvencijski dijagrami) 20

INTERVJUIRANJE kao metoda izlučivanja zahtjeva U formalnom i neformalnom intervjuiranju tim zadužen za inženjerstvo zahtjeva ispituje dionike o sustavu koji trenutno koriste te o novo predloženom sustavu. TIPOVI INTERVJUA: Zatvoreni intervju u kojem se odgovara na skup prije definiranih pitanja. Otvoreni intervju u kojem ne postoje definirana pitanja, već se niz pitanja otvara i raspravlja s dionicima. U praksi intervjui ne daju dobre rezultate za zahtjeve domene primjene jer inženjeri zahtjeva ne razumiju specifičnu terminologiju domene, a eksperti domene toliko poznaju te zahtjeve da ih ne artikuliraju (misle da su svima razumljivi sami po sebi). 21

SCENARIJI kao metoda izlučivanja zahtjeva Scenariji su primjeri iz stvarnog života o načinu korištenja sustava. Tijekom izlučivanja zahtjeva dionici diskutiraju i kritiziraju scenarij. Scenariji trebaju sadržavati: • Opis početne situacije. • Opis normalnog (standardnog) tijeka događaja. • Opis što se eventualno može dogoditi krivo. • Informaciju o paralelnim aktivnostima. • Opis stanja gdje scenarij završava. 22

Primjer scenarija za sustav LIBSYS (1): Početno stanje • Korisnik se prijavio ("logirao") u LIBSYS sustav, i locirao časopis u kojem se nalazi željeni članak. Normalan rad • Korisnik selektira članak za kopiranje. Sustav traži od korisnika informaciju o njegovim pravima (tip pretplate) ili načinu plaćanja. Opcije plaćanja su kreditna kartica ili račun organizacije koja ima pretplatu. • Sustav traži da korisnik potpiše formular o pravima na kopiranje i ostalim detaljima transakcije. To se upisuje u LIBSYS. • Formular o pravima na kopiranje se provjerava, i ako je OK članak u PDF formatu se prosljeđuje do korisničkog računala u sklopu LIBSYS sustava. Korisnik treba odabrati pisač i kopija članka se ispisuje. Ukoliko je članak tipa “samo za ispis”, članak se briše s korisničkog računala nakon što korisnik potvrdi da je 23 ispis završen.

Primjer scenarija za sustav LIBSYS (2): Što može poći po krivu • Korisnik nije ispravno popunio formular o pravima na kopiranje. Formular se mora ponovo dati korisniku na ispravak. Ako je ponovljeni formular krivo ispunjen, zahtjev korisnika se odbacuje. • Sustav može odbaciti način plaćanja i zahtjev se odbacuje. • Prijenos članka na korisnikovo računalo nije ispravno izveden. Prijenos se ponavlja ili dok korisnik ne prekine transakciju. • Članak nije moguće ispisati. Ako članak nije tipa “za ispis” drži ga se u radnom prostoru LIBSYS sustava, a u suprotnom članak se izbriše i korisniku se naplaćuje cijena članka. Paralelne aktivnosti • Prijenos i obrada zahtjeva drugih korisnika LIBSYS sustava. Završno stanje • Korisnik i dalje na sustavu. Ako je članak “za ispis”, briše se. 24

METODE U IZLUČIVANJU I ANALIZI ZAHTJEVA • Intervjuiranje • Scenarij • Obrasci uporabe (engl. use case) • Dijagrami interakcija (Sekvencijski dijagrami) 25

METODA IZLUČIVANJA ZAHTJEVA OBRASCIMA UPORABE (engl. use cases) Obrasci uporabe predstavljaju metodu preuzetu iz UML standarda. Temeljeni su na ideji scenarija. Skup obrazaca uporabe opisuje sve moguće interakcije sustava. Uz obrasce uporabe, dodatno se mogu koristiti i drugi dijagrami iz UML sustava (npr. sekvencijski dijagrami kako bi se detaljno opisao dinamički tijek događaja. U nastavku, koristit će se prezentacija: Introduction to UML: Use Cases Cris Kobryn Co-Chair UML Revision Task Force November 2000 26

Što je modeliranje obrascima uporabe? • Model obrazaca uporabe je pogled koji ističe ponašanje sustava kako ga vide vanjski korisnici. • Model obrazaca uporabe razdjeljuje funkcionalnost sustava u transakcije (“obrasce uporabe”) razumljive korisnicima (“aktorima”). • Tri temeljna elementa u modelima obrazaca uporabe su: obrasci uporabe (engl. use cases), aktori i odnosi (relacije, engl. relations) među njima. 27

Modeliranje obrascima uporabe: jezgreni elementi Naziv akcije Ime aktora 28

Modeliranje obrascima uporabe: jezgreni odnosi <<extend>> 29

Modeliranje obrascima uporabe: jezgreni odnosi <<include>> (crtkana ili puna strelica često nisu u konzistentnoj uporabi, u kolegiju se neće inzistirati na razlici) 30

Dijagram obrazaca uporabe (engl. use case) • Pokazuje obrasce uporabe, aktore i njihove odnose. • Detalji unutar dijagrama obrazaca uporabe mogu se predstaviti tekstom ili dodatnim dijagramima interakcije između elemenata sustava. • Vrste obrazaca uporabe: – Dijagram – temeljni i najznačajniji – Tekstovni opis – često kao dodatak uz dijagram 31

Dijagram obrazaca uporabe (samo koncepti) Aktori Granica sustava Odnosi Obrazac uporabe Fig. 3 -44, UML Notation Guide 32

Relacije u obrascima uporabe (obratiti pažnju na smjer strelica) Dobavi podatke o kupcu Naruči proizvod Naruči Uredi plaćanje Place Order uključuje ova ponašanja u cijelosti Točke proširenja Fig. 3 -45, UML Notation Guide Zahtijeva katalog proširenje akcije 33

VIŠESTRUKOST (brojnost) u obrascima uporabe Spojnica u obrascima uporabe može opcijski imati višestrukost (engl. multiplicity values) na svakom kraju. Na slici klijent može imati najviše jednu isplatu u jednom času, ali banka može imati po volji brojnost transakcija (klijenata koji istovremeno obavljaju isplatu). nula ili jedan nula ili više isplata 34

Odnosi između aktora više Prodavatelj Naruči Generalizacija (dopušta se i između obrazaca uporabe) Odobri kredit Nadzornik Fig. 3 -46, UML Notation Guide 35

Tekstovni obrazac uporabe – Npr. promjena avio leta n Aktori: putnik, baza računa klijenta (s planom puta), rezervacijski sustav avio kompanije, sučelje prijave (engl. booking system) n n Preduvjeti: · n Putnik se prijavio na sustav i odabrao opciju “promjena leta”. Temeljni tijek transakcija Sustav dohvaća putnikov bankovni račun i plan puta iz baze. · Sustav pita putnika da odabere dio plana puta koji želi mijenjati; putnik odabire segment puta. · Sustav pita putnika za novu odlaznu i dolaznu destinaciju; putnik daje traženu informaciju. · Ako je let moguć, tada … · Sustav prikazuje sažetak transakcije. . · n Alternativni tijek transakcija · Ako let nije moguć, tada … 36

Kada modelirati obrascima uporabe • Obrascima uporabe modelirati korisničke zahtjeve. • Obrascima uporabe modelirati scenarije ispitivanja sustava (engl. test scenarios). • Ako se koristi metoda oblikovanja programske potpore zasnovana na obrascima uporabe – Započne se s obrascima uporabe i iz njih se izvedu strukturni i ponašajni (engl. behavioral) modeli sustava. • Ako se ne koristi metoda oblikovanja programske potpore zasnovana na obrascima uporabe – Mora se osigurati da su obrasci uporabe sustava konzistentni sa strukturnim i ponašajnim modelima. 37

Preporuke u oblikovanju obrazaca uporabe • Svaki obrazac uporabe mora sadržavati značajan dio uporabe sustava i biti razumljiv ekspertima domene i programerima. • Ako se obrasci uporabe definiraju tekstom, sve imenice i glagole trebaju se koristiti razumljivo i konzistentno kako bi se kasnije mogli definirati ostali (UML) dijagrami. • Ako su obrasci uporabe uključeni u bazni obrazac, koristi <include>. Važno je napomenuti da se uključeni obrazac ne mora nužno izvesti. • Ako su obrasci uporabe kompletirani a postoje opcije u obliku dodatnih obrazaca koji se izvode pod točno određenim uvjetima, koristi <extend>. • Dijagram obrazaca uporabe treba sadržavati obrasce uporabe jednake apstraktne razine. • Uključiti samo zaista potrebne aktore. • Veliki broj obrazaca uporabe treba organizirati u posebne odvojene dijagrame i pakete. 38

Primjer: Upravljanje ljudskim resursima - dijagram Istaknuti obrazac je: Osvježi pogodnosti Upravitelj Zdravstveni plan Zaposlenik Plan osiguranja “on-line” sustav za upravljanje ljudskim resursima 39

Primjer: Upravljanje ljudskim resursima Akcija - “osvježi pogodnosti” Osvježi zubnu zaštitu Osvježi plan zdravstvene zaštite Osvježi pogodnosti Osvježi plan osiguranja Točka proširenja Zaposlenik Nadoknada troškova Opcija kupnje dionica Uvjet proširenja 40

Tekstovni opis: “Osvježi pogodnosti” (engl. Update Benefits) obrazac uporabe n. Aktori : zaposlenik, baza računa zaposlenika, sustav zdravstvene zaštite, sustav (zdravstvenog) osiguranja. Preduvjeti: · Zaposlenik se prijavio na sustav i odabrao opciju: ‘update benefits’. n. Temeljni · slijed: Sustav dohvaća zaposlenikov račun iz baze. Sustav traži da zaposlenik odabere tip plana zdravstvene zaštite; include Update Medical Plan. · Sustav traži da zaposlenik odabere tip plana zubne zaštite; include Update Dental Plan. · … · n. Alternativni slijed: Ako tip plana zdravstvene zaštite kojeg je zaposlenik odabrao nije ponuđen u njegom mjestu stanovanja, sustav traži odabir drugog plana zaštite. · 41

Medical clinic diagram Otkaži pregled Dogovori pregled Zatraži lijek Plati račun Sustav za određivanje termina Provjeri karton pacijenta Odgoda plaćanja činovnik Točka proširenja 42 Uoči generalizaciju između obrazaca

ZAKLJUČCI o UML obrascima uporabe kao metodi izlučivanja i analize zahtjeva • UML dijagrami i tekstualni opisi obrazaca uporabe modeliraju funkcionalne zahtjeve sustava s aspekta korisnika. • Temeljeni su na ideji scenarija. • Služe za izlučivanje zahtjeva prema pogledu interakcije. • Pogodni su za modeliranje velikih i složenih programskih produkata. • Jednostavni su za razumijevanje ali posjeduju i napredne značajke za ekspertne analitičare, arhitekte i programere. • Specificiraju sustave neovisno o načinu implementacije. • Mali skup konstrukcija obrazaca uporabe (10% do 20%) koristi se u 80% do 90% mjesta u sustavu. 43

METODE U IZLUČIVANJU I ANALIZI ZAHTJEVA • Intervjuiranje • Scenarij • Obrasci uporabe (engl. use case) • Dijagrami interakcija (Sekvencijski dijagrami) 44

METODA IZLUČIVANJA ZAHTJEVA MODELIRANJEM DINAMIČKIH INTERAKCIJA U SUSTAVU (modeliranje ponašanja, engl. behavioral modeling) • Obrasci uporabe specificiraju individualne interakcije u sustavu. • Dodatne informacije u inženjerstvu zahtjeva slijede iz UML dinamičkih dijagrama interakcije koji pokazuju aktore involvirane u interakciji, entitete (objekte, instancije) s kojima su u interakciji i operacije pridružene tim objektima. • Dijagrami interakcija: sekvencijski i kolaboracijski. Izvor: G. Overgaard, B. Selic, C. Bock, OMG, 2000. 45

Što su interakcije? • To je skup komunikacija između instancija elemenata sustava. Kada modelirati interakcije? • Želimo specificirati kakvo je međudjelovanje između elemenata sustava. • Želimo identificirati sučelja. • Postoji potreba za raspodjelom zahtjeva. 46

(nisu temeljni u inženjerstvu zahtjeva) 47

Preporuke za modeliranje interakcija: • Postavi kontekst interakcija (instancije elemenata). • Uključi samo relevantna obilježja elemenata. • Slijed događaja izrazi s lijeva na desno i odozgo prema dolje. • Postavi aktivne instancije u gornji lijevi ugao dijagrama. • Postavi pasivne instancije u donji desni ugao. • Uporabi sekvencijske dijagrame da bi se pokazao eksplicitan redoslijed pobuda. • Obvezno uporabi sekvencijske dijagrame u modeliranju sustava za rad u stvarnom vremenu. 48

Temeljni dijelovi Simboli entiteta sustava (životna crta) (tu je entitet aktivan) (pobuda) (povratna poruka) (brisanje) (stvaranje) 49

Sekvencijski dijagram • To je oblik interakcijskog dijagrama koji prikazuje entitete (objekte, elemente) s pridruženim životnim crtama u smjeru odozgo prema dolje. • Interakcije u vremenu su prikazane kao poruke predstavljene strelicama od izvorne do ciljne životne crte. • Sekvencijski dijagrami su pogodni za prikaz koji entiteti komuniciraju s drugim entitetima i koje poruke izazivaju tu komunikaciju. • Sekvencijski dijagrami nisu pogodni za prikaz složene proceduralne logike. 50

Elementi sekvencijskog dijagrama Životna crta (engl. lifeline) Životna crta predstavlja individualnog sudionika u sekvencijskom dijagramu. Životna crta uobičajeno ima pridruženi pravokutnik s imenom entiteta (elementa). 51

Elementi sekvencijskog dijagrama Ponekad će sekvencijski dijagram sadržavati životnu crtu s aktorom kao simbolom entiteta/elementa. To je čest slučaj kada obrazac uporabe posjeduje pridruženi sekvencijski dijagram. Granični elementi upravljanja mogu također imati životne crte. 52

Elementi sekvencijskog dijagrama Poruka (engl. message): Poruke se prikazuju kao strelice. Poruke mogu biti cjelovite, izgubljene ili nađene, zatim sinkrone ili asinkrone, te pozivi ili signali. Na slici je prva poruka sinkrona s implicitnom povratnom porukom (puna strelica). Druga poruka je asinkrona (crtana strelica). Treća poruka je asinkrona povratna (crtkana linija). (Kod sinkrone poruke pošiljatelj čeka na rezultat) 53

Elementi sekvencijskog dijagrama Poruka samom sebi (engl. self-message): Poruka prema samome sebi može predstavljati rekurzivan poziv operacije, ili poziv jedne procedure drugoj, gdje obje procedure pripadaju istom entitetu. Poruka samom sebi : (različite procedure, funkcije, metode u objektu). Rekurzija: (ista procedura, funkcija, metoda poziva se više puta). 54

Elementi sekvencijskog dijagrama Izgubljene i nađene poruke (engl. lost and found messages): Izgubljene poruke su one koje su poslane ali nisu stigle do primatelja ili one koje idu do primatelja koji nije prikazan na tom dijagramu. Nađene poruke su one koje dolaze od nepoznatog pošiljatelja ili od pošiljatelja koji nije prikazan na tom dijagramu. Označuju se grafičkim simbolom krajnjeg elementa. 55

Elementi sekvencijskog dijagrama Početak i kraj životne crte (engl. lifeline start and end): Životna crta može se stvoriti i uništiti tijekom predstavljenog vremenskog perioda. Slika prikazuje entitet Child koji se stvori i uništi od strane entiteta Parent nakon nekog vremena. 56

Elementi sekvencijskog dijagrama Trajanje i vremenska ograničenja Temeljno, poruka se prikazuje kao horizontalna linija. Padajuća linija prikazuje vremensko trajanje. (>10 ms od slanja do primanja, npr. spora komunikacija). 57

Elementi sekvencijskog dijagrama Petlja u sekvencijskom dijagramu Zatvoreni pravokutnik predstavlja poruke koje se ponavljaju n puta. 58

Elementi sekvencijskog dijagrama Invarijante stanja Invarijanta stanja je ograničenje koje mora biti istinito za vrijeme izvođenja. Pokazuje se kao pravokutnik sa polukružnim krajevima. 59

Elementi sekvencijskog dijagrama: Oznake na strelicama prethodnik uvjet oznaka sekvence pov. vrijed. ime poruke lista arg. 60

Raniji primjer: Tekstovni obrazac uporabe – promjena avio leta n Aktori: putnik, baza računa klijenta (s planom puta), rezervacijski sustav avio kompanije, sučelje prijave (engl. booking system) n Preduvjeti: · n Putnik se prijavio na sustav i odabrao opciju “promjena leta”. Temeljni tijek transakcija Sustav dohvaća putnikov bankovni račun i plan puta iz baze. · Sustav pita putnika da odabere dio plana puta koji želi mijenjati; putnik odabire segment puta. · Sustav pita putnika za novi odlaznu i dolaznu destinaciju; putnik daje traženu informaciju. · Ako je let moguć, tada … · Sustav prikazuje sažetak transakcije. . · n Alternativni tijek transakcija · Ako let nije moguć, tada … 61

62

Primjer: Rezervacija hotela. Entitet koji inicira sekvenciju poruka je Reservation window. Sekv. dijag. može uključiti i dodatni tekstovni opis 63

Primjer: Medicinska sestra (engl. nurse) traži dijagnostički test Dvije asinkrone poruke od Nurse: 1) Traži Medical. Lab da rezervira dan za test i 2) traži Insurance. Company da odobri test. Redoslijed slanja i primanja ovih poruka je nebitan. Ako Insurance. Company odobri test, Nurse će planirati test na dan koji odredi Medical. Lab. 64

LIBSYS - dodatni dijagram sekvenci za ispis članka (Asinkrone povratne poruke nisu označene sukladno ranijim razmatranjima. To je dokaz da ni UML dijagrami nisu do kraja shvaćeni (Sommerville? ) kao obvezujući standard. ) 65

DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAHTJEVA • Studija izvedivosti • Izlučivanje, analiza i specifikacija zahtjeva (ovo je najznačajniji dio) • Validacija zahtjeva • Upravljanje promjenama u zahtjevima 66

VALIDACIJA ZAHTJEVA • Cilj validacije je pokazati da zahtjevi odgovaraju željama naručitelja. • Naknadno ispravljanje pogreške u zahtjevima može biti 100 puta skuplje od ispravljanje pogreške u implementaciji. TEHNIKE VALIDACIJE: • Recenzija zahtjeva (sistematska ručna analiza zahtjeva). • Izrada prototipa (provjera zahtjeva na izvedenom sustavu). • Generiranje ispitnih slučaja (razvoj ispitnih sekvenci za provjeru zahtjeva). 67

ŠTO SE U ZAHTJEVIMA PROVJERAVA? • VALJANOST - da li sustav osigurava funkcije koje podupiru potrebe korisnika? • KONZISTENCIJA - da li postoji konflikt u zahtjevima? • KOMPLETNOST - da li sustav uključuje sve funkcije koje je korisnik tražio? • REALNOST - da li se sve funkcije mogu implementirati uz danu tehnologiju i proračun? • PROVJERLJIVOST - da li se svi zahtjevi mogu provjeriti? • RAZUMLJIVOST - da li je dokument jasno napisan? • SLIJEDIVOST - da li je naveden izvor dokumenta? • PRILAGODLJIVOST - mogu li se zahtjevi mijenjati bez velikog utjecaja na druge zahtjeve? 68

DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAHTJEVA • Studija izvedivosti • Izlučivanje, analiza i specifikacija zahtjeva (ovo je najznačajniji dio) • Validacija zahtjeva • Upravljanje promjenama u zahtjevima 69

UPRAVLJANJE PROMJENAMA U ZAHTJEVIMA Promjene nastupaju zbog promijenjenog modela poslovanja, boljeg razumijevanja procesa tijekom razvoja ili konfliktnih zahtjeva u različitim pogledima. EVOLUCIJA ZAHTJEVA: Početno razumijevanje problema Promijenjeno razumijevanje problema Početni zahtjevi Promijenjeni zahtjevi VRIJEME 70

KLASIFIKACIJA PROMJENA ZAHTJEVA • Okolinom promijenjeni zahtjevi - promjena zbog promjene okoline u kojoj organizacija posluje (npr. bolnica mijenja financijski model pokrivanja usluga). • Novonastali zahtjevi - zahtjevi koji se pojavljuju kako kupac sve bolje razumije sustav koji se oblikuje • Posljedični zahtjevi - zahtjevi koji nastaju nakon uvođenja sustava u eksploataciju, a rezultat su promjena procesa rada u organizaciji nastalih upravo uvođenjem novoga sustava • Zahtjevi kompatibilnosti - zahtjevi koji ovise o procesima drugih sustava u organizaciji; ako se ti sustavi mijenjaju to traži promjenu zahtjeva i novo uvedeni sustav 71

UTJECAJ SOCIJALNIH I ORGANIZACIJSKIH ČIMBENIKA U INŽENJERSTVU ZAHTJEVA • Programski produkti se uvijek koriste u socijalnom i organizacijskom kontekstu. To može uvelike utjecati i čak dominirati nad zahtjevima sustava. • Socijalni i organizacijski čimbenici nisu jedinstven pogled, već utjecaj na sve poglede. • Oblikovanje programske potpore mora to uvažiti, ali trenutno ne postoji sistematski postupak kako se to može uključiti u analizu zahtjeva. • Ne postoje jednostavni modeli za opis obavljanja nekog posla. Ako i postoje, to su modeli zasnovani na prošlim a ne obrascima ponašanja na novom poslu. Potrebna je znanost o tome kako se poslovi stvarno obavljaju. • Djelomično se tome može doskočiti izradom prototipa, te praćenjem rada na njemu. 72

ETNOGRAFIJA • To je znanost koja istražuje kako ljudi stvarno rade, a ne kako bi definicija poslovnog procesa to propisivala. • Koristi se za izlučivanje zahtjeva uzimajući u obzir aktivnosti drugih sustavom involviranih ljudi. • Ne može otkriti sve domenske zahtjeve Fokusirana etnografija (etnografija + prototip): Etnografska analiza Generički razvoj sustava kooperativni sastanci Saslušanja Fokusirana etnografija Cilj je da broj iteracija rafiniranja prototipa bude što manji! Evaluacija prototipa Izrada prototipa 73

ZAKLJUČCI • Proces inženjerstva zahtjeva uključuje studiju izvedivosti, izlučivanje zahtjeva, analizu i specifikaciju, validaciju zahtjeva i rukovanje (upravljanje promjenama) zahtjevima. • Izlučivanje, analiza i specifikacija zahtjeva je iterativan proces koji uključuje razumijevanje domene primjene, prikupljanje, klasifikaciju, strukturiranje, sastavljanje prioriteta i dokumentiranje zahtjeva. • Validacija zahtjeva bavi se valjanošću, konzistentnošću, kompletnošću, realizmom u izvedbi i provjerljivošću. • Sustavi imaju više dionika s različitim zahtjevima. • Rukovanje zahtjevima uključuje planiranje i upravljanje promjenama u zahtjevima. • Promjene načina poslovanja nužno mijenjaju zahtjeve. • Socijalni i organizacijski čimbenici utječu na zahtjeve sustava. 74