procesi inŽenjerstva zahtjeva (ili kako generirati specifikaciju)

1

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

2

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

3

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

4

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

5

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

KLASIČNI MODEL PROCESA INŽENJERSTVA ZAHTJEVA

Aktivnosti

Produkti

Studija izvedivosti

Izlučivanje i analiza

Specifikacija zahtjeva

Validacija zahtjeva

Dokument zahtjeva

Korisnički zahtjevi i zahtjevi sustava

Modeli sustava iteracije

iteracije

6

Requirementsspecification

Requirementsvalidation

Requirementselicitation

System requirementsspecification and

modeling

Systemrequirements

elicitation

User requirementsspecification

Userrequirements

elicitation

Business requirementsspecification

Prototyping

Feasibilitystudy

Reviews

System requirementsdocument

SPIRALNI MODEL PROCESA INŽENJERSTVA ZAHTJEVA

Izlučivanje Validacija

Specifikacija

Izrada prototipa

Revizije

Zahtjevi sustava i modeliranje.

Korisnički zahtjevi.

Poslovni zahtjevi.

Izlučivanje zahtjeva sustava

Izlučivanje korisničkih zahtjeva.

Studija izvedivosti

Konačan dokument zahtjeva

7

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.

8

DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAJTHEVA

• Studija izvedivosti

• Izlučivanje, analiza i specifikacija zahtjeva (ovo je najznačajniji dio)



9

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?

10

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?

11

DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAJTHEVA





12

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

13

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

14

Requirementsclassification and

organisation

Requirementsprioritization and

negotiation

Requirementsdocumentation

Requirementsdiscovery

SPIRALNI MODEL IZLUČIVANJA I ANALIZE ZAHTJEVA

Početak:

Izlučivanje (otkrivanje) zahtjeva

Klasifikacija i organizacija zahtjeva

Ustanovljavanje prioriteta i pregovaranje

Dokumentiranje zahtjeva

15

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.

16

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.

17

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

18

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

19

Articleproviders

FinanceLibrarymanager

Librarystaff

Users

InteractorIndirect

All VPs

Classificationsystem

UIstandards

Domain

ExternalStaffStudents CataloguersSystem

managers

POGLEDI U PRIMJERU SUSTAVA KNJIŽNICE

(ranije naveden hipotetski sustav LIBSYS)

Svi pogledi

Indirektni InterakcijaDomena primjene

20

METODE U IZLUČIVANJU I ANALIZI ZAHTJEVA

• Intervjuiranje

• Scenarij

• Obrasci uporabe (engl. use case)

• Dijagrami interakcija (sekvencijski dijagrami)

21

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

22

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.

23

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 ispis završen.

24

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.

25


• Intervjuiranje

• Scenarij


• Dijagrami interakcija (Sekvencijski dijagrami)

26

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 CasesCris KobrynCo-Chair UML Revision Task ForceNovember 2000

Š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

28

Konstrukt Opis Sintaksa

Obrazac uporabe (use case)

Akcija (uključujući varijante) koje sustav ili drugi entitet obavlja u interakciji s aktorima sustava.

Aktor (actor)

Koherentan skup uloga koje imaju korisnici u interakciji s obrascima uporabe.

Granica sustava (system boundary)

Predstavlja granicu između fizikalnog sustava i različitih aktora koji su u interakciji s fizikalnim sustavom.

UseCaseNam e

ActorNam e

Naziv akcije

Ime aktora

Modeliranje obrascima uporabe: jezgreni odnosi

29

Konstrukt Opis Sintaksa

Pridruživanje (association)

Sudjelovanje aktora u obrascu uporabe, tj. komunikacija instancije aktora i instancije obrasca uporabe.

Proširenje (opcionalno, specifično) (extend)

Odnos od proširene uporabe do osnovne uporabe (engl. base case). Specificira kako se ponašanje za proširen obrazac uporabe može umetnuti u ponašanje definirano osnovnim obrascem uporabe.

Generalizacija (generalization)

Oznaka za odnos između općeg i specifičnog (aktora ili obrasca uporabe).

<<extend>>

Modeliranje obrascima uporabe: jezgreni odnosi

30

Construct Description Syntax

Uključivanje u cjelosti (include)

Odnos (relacija) od osnovnog obrasca do uključenog obrasca. Specificira ponašanje uključenog obrasca u odnosu na osnovni obrazac uporabe. Osnovni obrazac sadrži ponašanje definirano u drugom obrascu.

<<include>>

(crtkana ili puna strelica često nisu u konzistentnoj uporabi, u kolegiju se neće inzistirati na razlici)

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)

32

Fig. 3-44, UML Notation Guide

Customer

Supervisor

SalespersonPlace

Establishcredit

Check

Telephone Catalog

F ill orde rs

Shipping Clerk

status

order

Granica sustava

Aktori

Obrazac uporabe

Odnosi

Relacije u obrascima uporabe (obratiti pažnju na smjer strelica)

33

Fig. 3-45, UML Notation Guide

additional requests :

OrderProduct

SupplyArrange

«include»«include»«include»

RequestCatalog

«extend»Extension points

PaymentCustomer Data

after creation of the order

Place Order

1 * the salesperson asks forthe catalog

Točke proširenja

Naruči

Naruči proizvod Uredi plaćanjeDobavi podatke o kupcu

Zahtijeva katalog

Place Order uključuje ova ponašanja u cijelosti

proširenje akcije

34

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

jedan

VIŠESTRUKOST (brojnost) u obrascima uporabe

isplata

Odnosi između aktora

35Fig. 3-46, UML Notation Guide

EstablishCredit

PlaceOrder

Salesperson

Supervisor

1 *

1 *

Generalizacija (dopušta se i između obrazaca uporabe)

višeProdavatelj

Nadzornik

Naruči

Odobri kredit

Tekstovni obrazac uporabe – Npr. promjena avio leta

36

Aktori: putnik, baza računa klijenta (s planom puta), rezervacijski sustav avio kompanije, sučelje prijave (engl. booking system)

Preduvjeti: 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..

Alternativni tijek transakcija Ako let nije moguć, tada …

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

38

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.

Primjer: Upravljanje ljudskim resursima - dijagram

39

Online HR System

LocateEm ployees

UpdateEm ployee

Profile

Update Benefits

Access TravelSystem

Access PayRecords

Em ployee

M anager

Healthcare Plan System

{if currentMonth = O ct.}

{readOnly}

Insurance P lan System

“on-line” sustav za upravljanje ljudskim resursima

Zaposlenik

Upravitelj

Zdravstveni plan

Plan osiguranja

Osvježi pogodnosti

Istaknuti obrazac je:

Primjer: Upravljanje ljudskim resursima Akcija - “osvježi pogodnosti”

40

Update M edicalP lan

Update DentalP lan

Update Benefits______________Extension pointsbenefit options:

after required enrollm ents

UpdateInsurance P lan

Em ployee

<<include>> <<include>> <<include>>

ElectReim bursem entfor Healthcare

Elect StockPurchase

<<extend>>em ployee requestsstock purchase option

<<extend>>em ployee requestsreim bursem ent option

extensioncondition

extension pointname andlocation

Točka proširenja

Uvjet proširenja

Osvježi pogodnosti

Zaposlenik

Opcija kupnje dionica

Nadoknada troškova

Osvježi plan osiguranja

Osvježi zubnu zaštituOsvježi plan zdravstvene zaštite

Tekstovni opis: “Osvježi pogodnosti” (engl. Update Benefits) obrazac uporabe

41

Aktori: zaposlenik, baza računa zaposlenika, sustav zdravstvene zaštite, sustav (zdravstvenog) osiguranja.

Preduvjeti: Zaposlenik se prijavio na sustav i odabrao opciju: ‘update benefits’.

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

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.

42

Medical clinic diagram

Točka proširenja

činovnik

Sustav za određivanje termina

Odgoda plaćanjaPlati račun

Zatraži lijek

Dogovori pregled

Otkaži pregled

Provjeri karton pacijenta

Uoči generalizaciju između obrazaca

43

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.

44


• Intervjuiranje

• Scenarij


• Dijagrami interakcija (Sekvencijski dijagrami)

45

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.

46

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

47

(nisu temeljni u inženjerstvu zahtjeva)

48

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.

49

(životna crta)

(tu je entitet aktivan)

(pobuda)

(povratna poruka)

(stvaranje)

(brisanje)

Temeljni dijelovi

Simboli entiteta sustava

50

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.

51

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

52


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 i elementi upravljanja mogu također imati životne crte.

53

Elementi sekvencijskog dijagramaPoruka (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)

54

Elementi sekvencijskog dijagramaPoruka 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).

55

Elementi sekvencijskog dijagramaIzgubljene 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.

56

Elementi sekvencijskog dijagramaPoč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.

57

Elementi sekvencijskog dijagramaTrajanje i vremenska ograničenjaTemeljno, poruka se prikazuje kao horizontalna linija. Padajuća linija prikazuje vremensko trajanje.

(>10ms od slanja do primanja,

npr. spora komunikacija).

58


Petlja u sekvencijskom dijagramu Zatvoreni pravokutnik predstavlja poruke koje se ponavljaju n puta.

59

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

60

prethodnik uvjet oznaka sekvence pov. vrijed. ime poruke lista arg.

Elementi sekvencijskog dijagrama: Oznake na strelicama

61

Raniji primjer: Tekstovni obrazac uporabe – promjena avio leta

Aktori: putnik, baza računa klijenta (s planom puta), rezervacijski sustav avio kompanije, sučelje prijave (engl. booking system)

Preduvjeti: 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..

Alternativni tijek transakcija Ako let nije moguć, tada …

63

Primjer: Rezervacija hotela. Entitet koji inicira sekvenciju poruka je Reservation window.

Sekv. dijag. može uključiti i dodatni tekstovni opis

64

Primjer: Medicinska sestra (engl. nurse) traži dijagnostički test

Dvije asinkrone poruke od Nurse: 1) Traži MedicalLab da rezervira dan za test i 2) traži InsuranceCompany da odobri test. Redoslijed slanja i primanja ovih poruka je nebitan. Ako InsuranceCompany odobri test, Nurse će planirati test na dan koji odredi MedicalLab.

65

User

item:Article

copyrightForm:Form

request

complete

myWorkspace:Workspace

myPrinter:Printer

request

return

copyright OK

deliver

article OK

print send

confirminform

delete

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

66

DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAHTJEVA





67

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

68

Š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?

69

DETALJAN PRIKAZ GENERIČKIH AKTIVNOSTI U PROCESU INŽENJERSTVA ZAHTJEVA





70

UPRAVLJANJE PROMJENAMA U ZAHTJEVIMA

Promjene nastupaju zbog promijenjenog modela poslovanja, boljeg razumijevanja procesa tijekom razvoja ili konfliktnih zahtjeva u različitim pogledima.

EVOLUCIJA ZAHTJEVA:

Time

Changedunderstanding

of problem

Initialunderstanding

of problem

Changedrequirements

Initialrequirements

Početno razumijevanje problema

Početni zahtjevi

Promijenjeno razumijevanje problema

Promijenjeni zahtjevi

VRIJEME

71

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

72

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.

73

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

Ethnographicanalysis

Debriefingmeetings

Focusedethnography

Prototypeevaluation

Generic systemdevelopment

Systemprotoyping

Fokusirana etnografija (etnografija + prototip):

kooperativni sastanciEtnografska analiza Saslušanja

Fokusirana etnografija

Evaluacija prototipa

Generički razvoj sustava Izrada prototipa

Cilj je da broj iteracija rafiniranja prototipa bude što manji!

74

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.

procesi inŽenjerstva zahtjeva (ili kako generirati specifikaciju)

Documents