PROCESI KARAKTERISTIČNI ZA INŽENJERSTVO

ZAHTJEVA

Softverski zahtjevi

Softverski zahtjevi se definiraju se na razini sustava. Njima se ustanovljavaju aktivnosti koje

korisnici zahtijevaju (očekuju) od sustava te uvjeti pod kojima će sustav razvijati kako bi
udovoljio postavljenim zahtjevima. Sami zahtjevi predstavljaju opis aktivnosti sustava kao i
opis pripadajućih ograničenja koja se generiraju tijekom procesa definiranja zahtjeva. Zahtjevi
se mogu definirati na najvišoj razini apstrakcije sustava ili detaljnim, matematički izraženim
opisom funkcija sustava.

Evolucija zahtjeva

Razvija se kroz tri koraka:

• Prepoznavanje potreba (želja) korisnika
• Otkrivanje ključnih karakteristika identificiranih potreba
• Preoblikovanje identificiranih karakteristika u zahtjeve i njihovo dokumentiranje

Prepoznavanje potreba

Naručitelj (korisnik) ima viziju što bi sustav (softver) trebao raditi. Primjerice naručitelj želi
automatizirati poslove koji se obavljaju ručno, želi poboljšati ili proširiti postojeći sustav
(ručni ili već automatizirani), želi softver koji će obavljati obrade koje se do sada nisu
obavljale, ili će ih obavljati bolje i sl.

Otkrivanje ključnih karakteristika identificiranih potreba

Projektant ili osoba koja razvija aplikaciju treba uz pomoć budućeg korisnika iz
identificiranih potreba prepoznati ključne karakteristike koje u slijedećem koraku treba
iskazati kao zahtjeve koji se postavljaju pred buduću aplikaciju.

Zahtjev predstavlja izraz željenog ponašanja. Bavi se objektima ili entitetima, njihovim
stanjima, funkcijama … koje se izvode radi promjene stanja ili osobina objekta. Zahtjev
označava KAKVO ponašanje naručilac želi, bez izražavanja KAKO će se to ponašanje
ostvariti.

Proces evidentiranja zahtjeva obavlja se kroz četiri faze:

• Prepoznavanje (identificiranje) zahtjeva moguće je realizirati kroz pitanja, ispitivanje
ponašanja, demonstriranje sličnih sustava.
• Analiza zahtjeva uključuje evidentiranje zahtjeva kroz modeliranje ponašanja sustava
(dijagrami, prototipiranje i sl.). moguć je povrat fazu prepoznavanja zahtjeva.
• Specifikacija je faza u kojoj se određuje koji će se dijelovi zahtijevanog ponašanja
implementirati u sustav te se dokumentira ponašanje predloženog softvera
• Validacija se odnosi na provjeru da li specifikacija zahtjeva odgovara onom što korisnik
zaista želi u finalnom proizvodu. Moguć je povrat u fazu prepoznavanja.

Softverski zahtjevi se mogu razvijati na najvišoj razini apstrakcije aktivnosti sustava, ili mogu
biti prikazani detaljnim, matematički izraženim opisom funkcija sustava.

1
Korisnički zahtjevi se mogu razvijati do različitih razina detaljnosti opisa. Tako primjerice
korisnički zahtjevi imaju visoku razinu apstrakcije zahtjeva. Pisani su od strane informatičara
ne temelju iskazanih potreba (zahtjeva) krajnjih korisnika odnosno klijenata, iskazani su kao
prikazi u prirodnom jeziku plus dijagrami, opisuju koje se aktivnosti očekuju od sustava i uz
koje uvjete funkcioniranja sustava.

Zahtjevi sustava pružaju detaljni opis što bi sustav trebao činiti (što se od sustava očekuje) a
prikazani su u obliku strukturiranog dokumenta sa detaljnim opisom svih aktivnosti sustava,
pisani su za iskusnije tehničko osoblje i management, mogu poslužiti kao ugovor između
klijenta i projektanta.

Specifikacija oblikovanja softvera zahtjeva još detaljniji opis te povezuje inženjerstvo

zahtjeva i aktivnosti oblikovanja. Daje sažeti opis oblikovanja softvera koji može poslužiti
kao osnova pri detaljnijem oblikovanju i implementaciji. Dokument je orijentiran na
implementaciju softvera i
pisan je za softverskog inženjera koji će razvijati sustav (aplikaciju).

Zahtjevi mogu biti: funkcionalni i nefunkcionalni.

Funkcionalni zahtjevi (ŠTO) odnose se na:

• prikaze aktivnosti koje sustav treba izvršiti
• kako sustav treba reagirati na određene ulaze
• kako će se sustav ponašati u određenim situacijama …

Nefunkcionalni zahtjevi (KAKO) se odnose na:

• karakteristike (ograničenja) koje softver mora imati.
• karakteristike koje sustav postavlja u odnosu na aktivnosti i funkcije koje sustav obavlja
(vremenska ograničenja, ograničenja u razvojnom procesu, standardi ...).

Prema izvorištu zahtjeva razlikuju se:

• Zahtjevi korisnika
• Zahtjevi sustava
• Zahtjevi domene (okruženja)

Zahtjevi korisnika – detaljno opisuju funkcionalne i nefunkcionalne zahtjeve na razumljiv, ne

tehnički način. Problemi: pomanjkanje jasnoće, zbrka zahtjeva, stapanje zahtjeva.

Zahtjevi sustava – pružaju detaljniju specifikaciju od korisničkih zahtjeva. Mogu poslužiti kao
dio ugovora. Sadržavaju ŠTO sustav treba raditi (dizajn će pokazati kako će sustav raditi).
Problemi: moguća dvosmislenost.

Zahtjevi domene – dolaze od sredine u kojoj će budući softverski proizvod funkcionirati.

Iskazuju specifičnosti sredine. Mogu biti funkcionalni i nefunkcionalni. Problemi:
razumljivost, implicitnost.

2
Inženjerstvo zahtjeva

Proces utvrđivanja aktivnosti (zahtjeva) koje bi sustav trebao obavljati (ŠTO) kao i pod
kojima uvjetima bi se te aktivnosti trebale obaviti naziva se inženjerstvo zahtjeva (primjena
inženjerskih metoda u utvrđivanju zahtjeva sustava).

Generičke aktivnosti uobičajene u svim procesima ovog tipa su:

¾ Otkrivanje zahtjeva
¾ Analiza zahtjeva
¾ Validacija zahtjeva
¾ Upravljanje zahtjevima

Proces inženjerstva zahtjeva polazi od Studije ostvarivosti.

Studija ostvarivosti se temelji na prikupljenim informacijama, informacijama koje se odnose

na procjenu mogućnosti u odnosu na zahtjeve, te na Izvještaju o ostvarivosti razvijanja novog
sustava. Na temelju studije ostvarivosti odlučuje se da li je predloženi sustav isplativ ili nije.

Utvrđivanje (otkrivanje) i analiza zahtjeva:

Informatičko osoblje uz pomoć korisnika upoznaje: aplikacijsku domenu,
aktivnosti koje se od sustava očekuju te ograničenja u radu sustava.

U proces utvrđivanja zahtjeva mogu se uključiti: krajnji korisnici, rukovoditelji, inženjeri koji
rade na održavanju sustava, eksperti za pojedina područja, ponuđači opreme …(zajednički
naziv: eng. stakeholders).

U otkrivanju mogućih zahtjeva ali i u razumijevanju postavljenih zahtjeva primjenjuju se

različite metode.

VORD Viewpoint Oriented Requirement Discovery

VORD Viewpoint Oriented Requirement Discovery (Description ili Definition – slovi D se u

različitim situacijama koristi u više značenja). Razvili Sommerville i Kotonya 1992. godine.

Metoda se razvija kroz četiri koraka:

• Identifikacija točki gledišta – korisnici promatraju sustav sa svog aspekta uloge u sustavu
odnosno s aspekta što očekuju od sustava. Točke se identificiraju tehnikom
«brainstorminga».

• Strukturiranje točki gledišta – točke gledišta se grupiraju prema srodnosti i hijerarhiji.

Identificirane aktivnosti prepoznate kao zajedničke za više točki gledišta postavljaju se na
hijerarhijski višu razinu.

• Dokumentiranje točki gledišta – identificirane točke gledišta i pripadajuće aktivnosti

pojašnjavaju se detaljnijim opisom.

• Prikazivanje sustava (stvaranje scenarija) temeljenog na točkama gledišta – analizom

uočeno, transformira se nekom metodom dijagrama u odgovarajući scenarij danas
najčešće primjenom UML-a («use case» dijagrami).

3
Rezultat primjene metode je odgovarajući scenarij. On daje prikaz kako se sustav koristi
(funkcionira) u praksi. On opisuje stanje sustava na početku scenarija, tok događanja u
scenariju, ukazuje na moguće neodgovarajuće situacije u sustavu i što u takvim situacijama
treba poduzeti, te prikazuje stanje sustava nakon završetka odvijanja aktivnosti prikazanih u
scenariju.

Problemi u analizi zahtjeva:

• Osobe (stakeholders) često ne znaju što točno žele, izražavaju se svojom terminologijom
• Različite osobe – mogući konfliktni zahtjevi
• Uplitanje organizacijskih i političkih faktora u sustav zahtjeva
• Zahtjevi se mijenjaju tijekom analize (nova osoba, poslovna okolina se mijenja)

Validacija zahtjeva

Validacija zahtjeva se odnosi na potvrđivanje da zahtjevi kojima se definira sustav su zaista

oni koji odgovaraju sustavu kakvog korisnik (kupac) želi. Iznimno važan korak u inženjerstvu
zahtjeva jer pogrešno specificirani zahtjevi mogu uzrokovati visoke troškove.

Upravljanje zahtjevima
Proces upravljanja zahtjevima iznimno je važan proces jer do promjene zahtjeva može doći
tijekom cijelog razvojnog procesa.