Inženjerstvo zahtjeva

dr.sc. Tihana Galinac

Ciljevi

Razumijevanje da je inženjerstvo zahtjeva cikličan proces koji uključuje sljedeće aktivnosti: pronalaženje i analiza zahtjeva, dokumentacija zahtjeva i validacijaRazumijevanje važnosti socijalnih i spoznajnih karakteristika u inženjerstvu zahtjevaRazlikovanje različitih tehnika pronalaženja i analize zahtjeva Svjesnost sadržaja specifikacije zahtjevaZnati tehnike i notacije specifikacije zahtjevaSvjesnost različitih perspektiva i aspekta modeliranja zahtjeva

Sadržaj

Uvod u inženjerstvo zahtjevaProcesi inženjerstva zahtjevaPronalaženje i analiza zahtjevaDokumentiranje zahtjevaTehnike dokumentacije zahtjevaProvjera zahtjeva

Sadržaj

Uvod u inženjerstvo zahtjevaProcesi inženjerstva zahtjevaPronalaženje i analiza zahtjevaDokumentiranje zahtjevaTehnike dokumentacije zahtjevaProvjera zahtjeva

The hardest single part of building a system is deciding what to build

F. P. Brooks: No Silver bullet: Essence and Accidents of Software Engineering, IEEE Computer, 2004.

Uvod u inženjerstvo zahtjeva

Prva faza u tehničkim procesima žcppOdgovara na pitanje ‘što ćemo razvijati’To je proces izrade dokumenta specifikacije zahtjeva za proizvod kojeg ćemo razvijati

Problem

Specifikacija zahtjeva

Inženjerstvo zahtjeva

Inženjerstvo zahtjeva

Zahtjev je stanje ili sposobnost koje je potrebno da programski sustav posjeduje kako bi pomogao njegovom korisniku u rješavanju problema i/ili dostizanju ciljeva.

Definicija prema IEEE standardnom riječniku pojmova

U inženjerstvu zahtjeva različiti korisnici mogu predlagati zahtjeve, iako se najčešće za funkcionalne zahtjeve konzultira krajnji korisnik

Inženjerstvo zahtjeva (nastavak)

Iterativan i kooperativan proces analize, dokumentiranja rezultata analize te kontinuirane provjere ispravnosti razumijevanja postignutog tim radnjama (Primjer)Osim tehničkih potrebna je velika socijalna i spoznajna vještina Rezultat inženjerstva zahtjeva se opisuje u dokumentu specifikacija zahtjeva (eng. Requirement specification)

Specifikacija zahtjeva (SZ)

Osnovna svrha je postizanje međusobnog dogovora oko zahtjeva s obzirom na koje će se programski sustav dalje razvijatiKoristi se

kao osnova pri sklapanju ugovora između naručitelja sustava i organizacije razvoja sustava,Kao ulaz u sljedeću fazu dizajna tehničke solucijeKao ulaz za specifikaciju testnih slučaja Korisnici SZ mogu biti i drugi kao što su primjerice inženjeri koji izvode validaciju sustava, menadžeri

Specifikacija zahtjeva (nastavak)

Obično se faze inženjerstva zahtjeva i dizajna preklapaju tako da se za vrijeme postavljanja SZ u preliminarnu reviziju započinje i s dizajn dokumentacijomDobar dio zahtjeva se iskristalizira tek početkom dizajna sustava koristeći te zahtjeve!

Requirements

Design

Primjer: e-knjižnice

Sustav pretraživanja u tradicionalnim knjižnicama uglavnom abecedni sustav pretraživanja po prvom autoru knjigeAko znamo samo naziv knjige teško bi našli i posudili knjigu koju tražimoImate li ideju kako bi izgledala solucija u programskom proizvodu?

Zahtjevi na e-knjižnicu

Koji su funkcionalni zahtjevi? – prioritizacijaKoja platforma i operacijski sustav će se koristiti? Koji DBMS, tipovi terminala i koliko njih?Koje su klase korisnika neohodne? knjižničari, članovi knjižnice; Postoje li zabrane funkcija po korisniku?Koja veličina baze i koja su očekivanja kako će potrebe za pohranom podataka rasti? Koje je razumno vrijeme očekivanja odgovora iz sustava? Koja je cijena ovakvog sustava, uključivši i prebacivanje podataka u sustav?

Zaključci iz primjera

Tek kad se krene razmišljati iz perspektive dizajna niz novih pitanja i zahtjeva se postavljaOsim funkcionalnih zahtjeva, treba se razmotriti okolina primjene te interakcija s okolinom primjenePosljedice uvođenja e-knjižnice mogu biti puno veće od same izrade programske solucije i često nepravovremena identifikacija vodi ka neuspjehu projekta

Studija izvedivosti (eng. Feasibility study)

Uglavnom se prije početka dizajna i implementacije provodi studija izvedivostiOsnovna svrha je provjera mogu li odabrani hardver i programski proizvod zadovoljiti traženim performansamaUključuje i analizu troškova i benefita

Zadatak

Treba napraviti (ne-formalnu) specifikaciju zahtjeva za programski proizvod.Najbolje bi bilo da radite u grupama 2-3Zadatak:

Treba napraviti program za upravljački sustav od n dizala/liftova u zgradi s m katova. Zadatak je osmisliti logiku kojom se liftovi kreću između katova u sljedećim uvjetima:

Zadatak (nastavak)

Svaki lift ima niz tipki, po jedna za svaki kat. Tipka zasvjetli kako lift prolazi po katovima zgrade. Tipka se ne osvjetljava na katu na kojem lift zastaje.Svaki kat ima dvije tipke (osim najgornjeg i najdonjeg), jedan za zahtjev za dizanje i jedan za spuštanje. Kada se pritisne neka od tih tipki, ona zasvjetli. Tipka prestaje svijetliti onoga trena kada dođe lift na taj kat, ili se kreće u tom smjeru ili nema zahtjeva za kretnjom.Kada nema zahtjeva, lift treba ostati na zadnjoj destinaciji sa zatvorenim vratima i čekati sljedeće zahtjeve. (Alternativa može biti da se odredi kat na kojem će lift čekati pod tim uvjetima)

Zadatak (nastavak)

Svi zahtjevi za liftovima moraju se poslužiti, tako da se svim katovima da jednaki prioritet. Svi zahtjevi za katove unutar lifta moraju se poslužiti, tako da lift staje po odabranim katovima slijedno u smjeru kretanja.Svaki lift ima tipku za nuždu koja ako se pritisne uzrokuje da se signal upozorenja šalje upravitelju zgrade. Lift se od tog trenutka smatra da je izvan funkcije. Svaki lift ima i mehanizam da se lift ponovno vrati u funkciju.

Zadatak (nastavak)

Sigurno ste se svi susretali s sustavom dizala sličnom ovom. Ono što se očekuje od vas je da na osnovu svog iskustva pokušate specificirati zahtjeve.Prvo se pokušajte fokusirati na zahtjeve koji su povezani s upravljanjem kretanja svakog lifta u odnosu na zahtjeve putnika i povezanih ostalih čimbenika.S obzirom da trebate napraviti ne-formalnu specifikaciju, zahtjevi trebaju biti uglavnom tekstualni, ali mogu se dodati tablice ili dijagrami po želji.Dodajte jedno poglavlje gdje opisujete probleme i/ili otvorena pitanja i nejasnoće.

Sadržaj

Uvod u inženjerstvo zahtjevaProcesi inženjerstva zahtjevaPronalaženje i analiza zahtjevaDokumentiranje zahtjevaTehnike dokumentacije zahtjevaProvjera zahtjeva

Procesi inženjerstva zahtjeva

U procesu inženjerstva zahtjeva možemo razlikovati tri osnovne faze:

Pronalaženje i analiza zahtjeva (eng. Req. Elicitation)Dokumentiranje zahtjeva (eng. Req. specification) Provjera zahtjeva (eng. Req. Validation and verification)

Okvir procesa inženjerstva zahtjeva

Pronala-ženje i analiza

zahtjeva

Dokume-ntiranjezahtjeva

Provjera zahtjeva

Korisnik

Domena primjene

Zahtjevi korisnika

Znanja iz domene primjene

Prikupljenaznanja

Potreba za novim znanjima

Modeli zahtjeva

Rezultatiprovjere

Modeli koje korisnik provjerava

Odaziv korisnika

Znanja iz domene primjene

Sadržaj

Uvod u inženjerstvo zahtjevaProcesi inženjerstva zahtjevaPronalaženje i analiza zahtjevaDokumentiranje zahtjevaTehnike dokumentacije zahtjevaProvjera zahtjeva

Pronalaženje i analiza zahtjeva

Cilj je pronaći točne i potpune zahtjeveProblemi

Obično znanja iz domene primjene se u toj domeni podrazumijevaju i neformalna su pa ih je teško dohvatiti (Primjer palestinska marama)

Dolazi do izražaja socijalna i spoznajna sposobnost analitičara

Zahtjevi su kompleksni i postoji velik broj mogućnosti koje se može izvesti programskim proizvodom

Teško da korisnik iz prvog pokušaja uspije sagledati sve aspekte svojih želja

Teško se nositi s razvojem okoline, tj. osigurati perspektivne zahtjeve koji će služiti i u budučnosti

Tehnike pronalaženja i analize zahtjeva

Izvor ModeliranjeDomena Korisnik Sadašnj. Budućn.

X

X

X

XXXX

Interview XDelphi technique XBrainstorming sessionTask analysis XScenario (use-case) analy. XEthnography X XForm analysis X X

Tehnika

Tehnike pronalaženja i analize zahtjeva (nastavak)

Izvor PrimjenjivostDomena Korisnik Sadašnj. Budućn.

XXX

Analy. Of natural language descriptions

X X

Synthesis of reqs from an existing system

X X

Domain analysis X XUse of reference models X XBusiness process redesign X XPrototyping

Tehnika

Tehnike ispitivanja

Interview, Brainstorm, questionarieeSvode se na ispitivanje uglavnom korisnika i njegovim očekivanjima od sustavaOsnovni problemi ovakvih tehnika su da korinici često predvide svoja ograničenja i predrasude

DelphiIterativna tehnika gdje korisnici izmjenjuju informacije u pisanoj formi dok god se ne postigne sporazum

Task analysis, scenario-based analysis

Task analysis - Korisnici u svom poslu izvode niz zadataka. Ideja ove tehnike je da se napravi dekompozicija zadatakaScenario based analysis – za razliku od prehodnih tehnika ne fokusira se na zadatke već na slijed zadatka. Svaki scenario objašnjava kako se slijed zadatka izveo.

Obično se koristi u objektno orijentiranim analizama i dizajn metodama (Use Case analysis)

Etnography, Form analysis, Natural languague description

Etnography – grupa ljudi se analizira kako u stvarnosti radi a ne kako je poslovni proces propisanForm analysis – informacija o domeni se dobiva iz raznih formulara koji se koriste u stvarnom procesuNatural language descriptions – slično kao i form analysis samo što se informacije prikupljaju iz raznih opisnih dokumentacija primjerice operacijskih instrukcija i priručnika

Derivation from an existing system, Business process redesign, Prototyping

Derivation from an existing system – zahtjevi se formuliraju tako da se analiza započne od nekog postojećeg sustavaBusiness process redesign – koristi se kad se želi potpuno izmjeniti i automatizirati poslovni model neke organizacije, koristi formalnu metodologiju, ne spada baš u skupinu tehnika pronalaženja i analize zahtjevaPrototyping – na osnovu inicijalnog skupa zahtjeva razvije se prototip na osnovu kojeg se dalje definiraju zahtjevi

Sadržaj

Uvod u inženjerstvo zahtjevaProcesi inženjerstva zahtjevaPronalaženje i analiza zahtjevaDokumentiranje zahtjevaTehnike dokumentacije zahtjevaProvjera zahtjeva

Specifikacija zahtjeva

Konačni proizvod faze inženjerstva zahtjevaOsnovna svrha je komunikacija rezultata između svih involviranih sudionika IEEE standardi propisuju

Karakteristike koje zahtjeve čine dobro specificiranim,Sadžaj dokumenta specifikacije zahtjeva

Zahtjevi na SZ:Što znači DOBRO specificirani zahtjevi?

TočniNe dvo- ili više-značniPotpuni – jesu li svi zahtjevi izraženiKonzistentni – usklađeni međusobnoPrioretizirani – definirani prema prioritetimaMogu se jednostavno provjeriti

Primjer kako ne: ‘It should provide the user a fast response’Modularni -jednostavno se mijenjaju i prilagođavajuMogu se jednostavno pratiti prema drugim dokmentima

Zahtjevi na SZ:Što SZ treba sadržavati?

Funkcionalnost – što treba prog. proizvod raditi?Vanjska sučelja – Kako programski proizvod međudjeluje s okolinom (ljudima, sistemskim hardverom, drugim hardverom i programskim proizvodima)?Performanse – Koja je brzina, dostupnost, vrijeme odaziva, vrijeme oporavka različitih funkcija programskog proizvoda?Atributi – Analiza svojstva atributa kvalitete (prenosivost, točnost, jednostavnost održavanja, sigurnost, pouzdanost, i drugi)Ograničenja zbog implementacije – Organičenja resursa, integritet baze podataka, operativni sustav, standardi

Sadržaj specifikacije zahtjeva

Sadržaj specifikacije zahtjeva predložen je IEEE normom [830].

Prikladan za većinu slijednih modela razvoja (Vodopadni i njegove varijante) dok za prototip model predloženi okvir više služi za opis izlaza procesa

Osnovna poglavlja suUvodOpći opis sustavaLista specificiranih zahtjeva sustavaDodaciIndeks

Primjer SZ, i primjer s liftomhttp://www.astrodigital.org/space/stshorse.html

Adobe obat Docum

Uvod SZ dokumenta

Opis svrhe (eng. purpose) dokumenta i kome je namijenjenOkvir ili opseg (eng. Scope) dokumenta koji sadrži sljedeće informacije:

Prijedlog općeg imena programskog proizvoda (npr. Elevator controller)Kratki opis osnovne funkcije programskog proizvodaOpis moguće primjene programskog proizvoda, opis benefita primjene, osnovnih zadaća i ciljeva primjene

Opis definicija, pojmova i kratica koje se koriste u dokumentuLista referenci Opis strukture SZ dokumenta

Opći opis sustava

Product perspective: Opis prog. proizv. iz perspektive njegova djelovanja i njegove interakcije s drugim proizvodima. Identificirati sve uvjete rada:

sučelja s sustavom, korisnikom, harverom, drugim programima, komunikacijska sučelja, korištenje memorije, načini/uvjeti izvođenja, zahtjevi uslijed određene primjene

Product functions: Kratki opis svih funkcija koje pp treba izvoditiUser characteristics: Opis nužnih karakteristika korisnika za rukovanje prog.proizv.

Opći opis sustava (nastavak)

Constraints: Opis ograničenja u razvoju prog. proizv. primjerice razne regulative, ograničenja hardvera, sučelja prema drugim funkcijama, mogućnost paralelnog rada, funkcije audita i kontrole, pouzdanost, sigurnost, i druga moguća ograničenja na dizajn funkcije.

Opći opis sustava (nastavak)

Assumptions and dependencies: Opis pretpostavki i zavisnosti izvođenja prog.proizv. o drugim elementima s kojima je u interakciji. Za razliku od ograničenja na dizajn ovjdje se navode moguća ograničenja na izvođenje prog. proizv.

Primjer: Prog. proizv. Se razvija s pretpostavkom da će raditina određenoj platformi. U slučaju da ta platforma ne bude dostupna, prog. proizv. će se trebati prilagoditi nekoj drugoj.

Apportioning of requirements: Lista mogućih zahtjeva u budućim revizijama SZ dokumenta

Lista specificiranih zahtjeva sustava

Osnova cijelog dokumenta SZ i najduže poglavljePravila koja se treba držati:

DOBRO specificiraniMeđusobno referenciraniJedinstveni identificiraniOrganizirani u smislene skupine

Neki primjeri organizacije su prema režimu (mod) rada, razredu (klasa) korisnika, objektu na koji se odnose, odazivu, funkcionalnoj hijerarhiji

Sadržaj

Uvod u inženjerstvo zahtjevaProcesi inženjerstva zahtjevaPronalaženje i analiza zahtjevaDokumentiranje zahtjevaTehnike dokumentacije zahtjevaProvjera zahtjeva

Tehnike dokumentacije zahtjeva

Dokumentirani zahtjevi se promatraju iz:Korisničke perspektive;

naručitelji i organizacija razvoja pri sklapanju ugovoraImplementacijske perspektive:

sudionici procesa razvoja kao osnovni ulazni dokument

Govorni jezik

Preferiran of strane naručitelja sustavaNedostaci govornog jezika:

Šum – nepotreban tekst Tišina – neizrečeni aspekti problemaPrespecificiranost – implementacijski detaljiKontradiktornost – ponavljanje različitim tekstomDvosmislenost – korištenje stručnim žargonomNestrukturiranost – korištenje nedefiniranih pojmovaMaglovitost - Neizvedivi zahtjevi

Moguće rješenje je korištenje formalnog jezika za specifikaciju i potom prebacivanje u govorni jezik

Entity-relationship modeling

Za modeliranje podataka kod razvoja informacijskih sustavaModeliranje logičke, sematičke struktureKoriste entity-relationship dijagrame

Pravokutnici – entiteti u procesu, objekti u procesu (knjige, članovi, org. jedinica,..)Elipse, kružnice – atributi entiteta (id, adresa)Tipovi entiteta ili atributa u opisnom obliku: {0...10}, posuđen/vračen, i drugo.Linije – veze između entiteta, usmjerene ili neusmjerene. Dijagram je osjetliv na pogreške u vezama

Zajedno se koristi s drugim formalnim jezicima

Primjer: Entity-relationship dijagram

Ime

Adresa Član posuđen Primjerak knjige

Identifikacija

{0...10} {0...1}

Identifikacija

Finite State machines

Konačni automati (eng. Finite state machines) koriste

konačni broj stanja i mogućih prijelaza Posebno definirano inicijalno/početno stanjedijagram prijelaza stanja koriste kružnice za prikaz stanja i usmjerene putanje za prikaz prijelaza stanja s labelom što je pokrenulo prijelaz (stimulans)

Ispisana iz sustava

Posuđena

Na popravku

Dostupna

posudba

povratak

sa popravka

na popravak

ispis

obnovi

Sadržaj

Uvod u inženjerstvo zahtjevaProcesi inženjerstva zahtjevaPronalaženje i analiza zahtjevaDokumentiranje zahtjevaTehnike dokumentacije zahtjevaProvjera zahtjeva

Provjera zahtjeva

Zahtjevi se provjeravaju koristeći Verifikacija

provjera semantike i sintakseSudionici razvoja, alati za formalnu verifikaciju

Validacija provjera svojstva točnost, potpunost, ne-višeznačnost, konzistentnostPotrebno prisustvo korisnika

Tehnike su uglavnom parafraziranje govornim jezikom, diskusije pomoću obrasca upotrebe (eng. usage scenario), prototipiranje i animacijaTest plan za test prihvatljivosti (eng. Acceptance test)