SVEUILITE/UNIVERZITET VITEZ U TRAVNIKU

FAKULTET POSLOVNE INFORMATIKE U TRAVNIKU

ROBERT VRBI

INENJERSTVO ZAHTJEVA KAO JEDNA OD NAJKRITINIJIH FAZA

RAZVOJA SOFTVERSKOG PROIZVODA
(seminarski rad)

TRAVNIK, 2012.
 SVEUILITE/UNIVERZITET VITEZ U TRAVNIKU
FAKULTET POSLOVNE INFORMATIKE U TRAVNIKU

Predmet: Prikupljanje softverskih zahtjeva

INENJERSTVO ZAHTJEVA KAO JEDNA OD NAJKRITINIJIH FAZA

RAZVOJA SOFTVERSKOG PROIZVODA
(seminarski rad)

Mentor

Akademik prof. dr. Zoran . Avramovi, dipl. in. elek.

Student

Robert Vrbi, B. Sc. inf.

Indeks br.: 0114-11/VIT

Travnik, veljaa 2012.

SPISAK SKRAENICA I AKRONIMA

Skraenica Originalni naziv Naziv na naem jeziku

ili akronim
RE Reqirement Engineering Inenjerstvo zahtjeva

UC Use Case Sluaj koritenja (SK)

ERA Entity Ralation Attribute model Model Entitet Veza - Atribut

CASE Computer-Aided Software Engineering Raunalno podrano programsko

inenjerstvo
SRS Software Requirement Specification Specifikacija programskog zahtjeva

IEEE Institute of Electrical and Electronics Institut inenjera elektrotehnike i

Engineers elektronike
ANSI American National Standards Institute Ameriki nacionalni institut za
standarde
SADRAJ

1. UVOD ......................................................................................................................................... 5
2. SOFTVERSKI ZAHTJEV I NJEGOVI ELEMENTI................................................................. 7
2.1. Funkcionalni elementi zahtjeva ......................................................................................................... 7
2.2. Nefunkcionalni elementi zahtjeva ...................................................................................................... 8
2.3. Korisniki zahtjevi (zahtjevi krajnjeg korisnika) ............................................................................... 8
2.4. Sistemski zahtjevi .............................................................................................................................. 9
2.5. Zahtjevi usmjereni ka suelju (interfejsu) sustava ........................................................................... 10
3. INENJERSTVO ZAHTJEVA ................................................................................................ 11
3.1. Studija izvedivosti ............................................................................................................................ 12
3.2. Izluivanje i analiza zahtjeva ........................................................................................................... 15
3.2.1. Intervjuiranje ............................................................................................................................. 17
3.2.2. Radni sastanci ........................................................................................................................... 19
3.2.3. Izrada prototipa (prototyping) ................................................................................................... 20
3.2.4. Storyboarding ............................................................................................................................ 20
3.2.5. Scenariji .................................................................................................................................... 21
3.2.6. Sluajevi koritenja ................................................................................................................... 22
3.2.7. Etnografija u inenjerstvu zahtjeva ........................................................................................... 26
3.3. Validacija zahtjeva ........................................................................................................................... 27
3.4. Upravljanje zahtjevima ili upravljanje promjenama ........................................................................ 28
3.4.1. Planiranje upravljanja zahtjevima ............................................................................................. 29
3.4.2. Upravljanje promjenama zahtjeva............................................................................................. 30
3.5. Dokumentiranje zahtjeva ................................................................................................................. 30
4. RIZICI LOEG PLANIRANJA .............................................................................................. 34
5. ZAKLJUAK ........................................................................................................................... 37
LITERATURA ............................................................................................................................. 39
 1. UVOD

Poetkom ezdesetih godina prolog stoljea dolazi do izraenog nesklada u razvoju

hardverskih komponenti i programske podrke (softvera). Dok hardverske komponente postaju
sve snanije, bre i raznovrsnije u svojim mogunostima, razvoj softvera ne moe zadovoljiti
narasle zahtjeve za izgradnjom novih, kompleksnijih programskih rjeenja. Javlja se tzv.
softverska kriza, koja rezultira previsokim trokovima razvoja, prekoraenjima rokova
predvienih za razvoj i, ne rijetko, odustajanjem od daljnjeg razvoja.
U takvoj situaciji, koja je postajala neodriva, pojavljuje se nova disciplina softversko
(programsko) inenjerstvo (engl. software engineering) iji je osnovni cilj rjeavanje krize
programske podrke. Samu kovanicu software engineering popularizirao je, tokom
Konferencije o programskom inenjerstvu u Garmischu, Njemaka (1968.) njezin predsjednik
F.L. Bauer [10]. Softversko inenjerstvo je disciplina koja se bavi svim aspektima proizvodnje
programske podrke, od specifikacije sustava do njegove implementacije i odravanja [1].
Softversko inenjerstvo se ne bavi samo tehnikim aspektima izgradnje softverskog sustava, ve
i prateim problemima upravljanja i organizira projekta razvoja softverskog proizvoda.
Podrazumijeva primjenu novih znanja, alata i metoda u inenjerstvu zahtjeva, modeliranju,
projektiranju, razvoju, testiranju, implementaciji i odravanju programskih rjeenja. Softversko
inenjerstvo se, dakle, bavi modelima, metodama i alatima koji su nam potrebni da bi na to
jeftiniji nain mogli proizvoditi to kvalitetnije softverske produkte [4].
Iako je prolo neto vie od 40 godina od (zvaninog) nastanka i definiranja programskog
inenjerstva kao posebne discipline, i znaajnog razvoja ovog podruja u zadnjih 20 godina,
situacija u oblasti razvoja i primjene softverskih rjeenja jo uvijek nije zadovoljavajua,
naprotiv. Za ilustraciju posluit e pregled rezultata iz izvjetaja (CHAOS Reports) za period od
1994. 2009. godine koje ve dugi niz godina izrauje Standish Group [15]:

2009. 2006. 2004. 2002. 2000. 1998. 1996. 1994.

Uspjeni projekti 32% 35% 29% 34% 28% 26% 27% 16%
Djelomino uspjeni 44% 19% 53% 15% 23% 28% 40% 31%
Propali projekti 24% 46% 18% 51% 49% 46% 33% 53%
Tabela 1: Pregled (ne)uspjenosti IT projekata

5
 Iako kontraverzni [16] ti izvjetaji ipak nude pokazatelje koji daju jednu opu sliku stanja
u oblasti razvoja softverskih projekata. Iz tabele je vidljivo da se stanje u ovoj oblasti, generalno
gledajui, popravlja. 1994. godine je vie od polovine projekata (53%) zavravalo potpunim
neuspjehom, a svega 16% je bilo uspjenih projekata (zavrili u planiranom roku, u okviru
planiranog budeta i na zadovoljstvo korisnika). 2009. godine, pak, svega je etvrtina propalih
projekata, skoro treina projekata je u potpunosti uspjeno realizirana (32%) i gotovo polovina
(44%) je projekata koji su privedeni kraju ali uz probijanje planiranih rokova, viestruko vee
trokove od planiranih i smanjen opseg funkcionalnosti softvera. Daleko od idealnog!
Razloga za ovakvo stanje je mnogo, a veina njih je vezana za poetne aktivnosti razvoja
softvera, tj. za proces inenjerstva zahtjeva. Inenjerstvo zahtjeva, kao poetna faza procesa
softverskog inenjerstva, ima kljunu ulogu u definiranju temeljnih pretpostavki razvoja
softverskog sustava. Greke nainjene u ovoj fazi reflektiraju se na cjelokupan proces razvoja i u
pravilu dovode do neeljenih posljedica (izgradnja neadekvatnog proizvoda, probijanje rokova,
ogromni trokovi razvoja koji viestruko premauju planirane, stalne promjene (redizajn),
nezadovoljstvo i frustracija korisnika ) .
U prvom dijelu ovog rada definiran je pojam softverskog zahtjeva i njegovi elementi,
odnosno vrste zahtjeva koje se postavljaju pred budui sustav, a zajedniki ih definiramo kao
softverski Zahtjev.
U drugom, glavnom, dijelu se govori o procesu inenjerstva zahtjeva, detaljno se (koliko
to opseg ovog rada doputa) opisuju aktivnosti koje ine ovu prvu (i najznaajniju) fazu ireg
proces, procesa programskog inenjerstva. Prezentirane su razliite metode i tehnike koje
inenjerima stoje na raspolaganju prilikom provoenja aktivnosti prikupljanja, analize,
specificiranja, validacije, dokumentiranja i upravljanja zahtjevima.
Trei dio rada je posveen mnogobrojnim rizicima koji se javljaju tokom izvoenja
aktivnosti inenjerstava zahtjeva. Navedeni su neki od rizika, kojih trebaju biti svjesni, u manjoj
ili veoj mjeri, svi zainteresirani akteri tako sloenog projekta kakav je projekt razvoja
softverskog proizvoda.

6
 2. SOFTVERSKI ZAHTJEV I NJEGOVI ELEMENTI

Pod pojmom softverski zahtjev podrazumijeva se opis usluga (servisa), manje i/ili vie
detaljan, koje sustav treba pruiti, kao i opis definiranih operativnih ogranienja. Softverski
zahtjev reflektira potrebe kupca za sustavom koji e rijeiti neki njegov problem, zbog kojeg se
razvija novi sustav ili modificira postojei.
IEEE standard definira zahtjev kao:
1. Uvjet ili sposobnost koju korisnik treba da bi rijeio problem ili ostvario cilj.
2. Uvjet ili sposobnost koju mora posjedovati sustav ili komponenta sustava da bi
zadovoljila ugovor, standard, specifikacije ili neki drugi ugovoreni element.
3. Dokumentiranu reprezentaciju uvjeta ili mogunosti definiranih pod (1) i (2) [7].
Softverski zahtjev nije jednostavno definirati, naprotiv. Svaki softverski zahtjev ima vie
elemenata, odnosno sainjavaju ga razliite vrste zahtjeva iz razliitih izvora (stakeholders
interesne strane). Najea podjela je na funkcionalne i nefunkcionalne elemente softverskog
zahtjeva. Takoer razlikujemo korisnike elemente zahtjeva, sistemske elemente (zahtjeve), i
elemente softverskog zahtjeva usmjerene ka suelju (interfejsu) sustava.

2.1. Funkcionalni elementi zahtjeva

Funkcionalni elementi softverskog zahtjeva definiraju softversku funkcionalnost

(operacije koje e sustav moi izvravati i oekivano ponaanje) koju treba ugraditi u softverski
proizvod kako bi korisnicima omoguio obavljanje njihovih zadataka. Funkcionalni elementi
zahtjeva odnose se na opisivanje funkcija sustava, usluga koje bi on trebao pruati, izlaza koje
sustav treba generirati za zadane ulaze (inpute) i ponaanja sustava u pojedinim situacijama.
Ovdje se definira TO e sustav raditi i vrlo je znaajno da funkcionalni elementi zahtjeva budu
to preciznije odreeni na samom poetku razvoja softverskog proizvoda. U principu,
funkcionalni zahtjevi trebaju biti kompletni i konzistentni, a to nije uvijek mogue ostvariti,
naprotiv. Naime, u definiranju zahtjeva se javljaju razliiti izvori (stakeholderi zainteresirane
strane) koji imaju razliite i, nerijetko, nekonzistentne zahtjeve, koji nisu, u pravilu, odmah
oigledni. Takoer, u sluajevima kada se razvija veliki i sloen sustav praktino je nemogue
odmah definirati sve funkcionalnosti. Razvojem samog sustava otkrivaju se i razvijaju novi, ili
modificiraju postojei, funkcionalni zahtjevi.

7
 2.2. Nefunkcionalni elementi zahtjeva

Kako im sam naziv govori, to su elementi softverskog zahtjeva koji se ne odnose

direktno na funkcije koje e sustav pruati korisniku u obavljanju njegovih poslova. Prvenstveno
se misli na odreena svojstva sustava (npr. pouzdanost, zahtjevi za resursima, zahtjevi za
odreenim performansama, zahtjevi za kvalitetom ). Takoer, ovdje ubrajamo i odreene
standarde razvoja, postavljena ogranienja u svezi dizajna i/ili implementacije, ugovore i pravila
koje softverski proizvod mora podravati, zakonsku regulativu
Nefunkcionalni elementi zahtjeva se u pravilu ne odnose na odreenu, pojedinanu,
znaajku sustava ve na sustav u cijelosti i mogu proistei iz odreenih, zahtijevanih,
karakteristika samog softverskog proizvoda (zahtjevi na proizvod), organizacije razvoja softvera
(organizacijski zahtjevi) i iz eksternih izvora koji utjeu na odreene aspekte samog softverskog
proizvoda i njegovog razvoja (eksterni zahtjevi).
Standardni problem sa nefunkcionalnim elementima zahtjeva je u tome to ih je vrlo
teko, a ponekad i nemogue, adekvatno verificirati. Razlog tome je to se ovi zahtjevi najee
postavljaju naelno, uopeno i neprecizno i kao takve ih je teko implementirati na
zadovoljavajui nain.
Bitno je istai i tzv. zahtjeve domene (domain requirements). To su zahtjevi koji
proizlaze iz domene iz koje sustav dolazi, a mogu biti funkcionalni i nefunkcionalni. To su
specijalizirani zahtjevi koji izlaze iz poslovnog okruenja u kojem sustav funkcionira.

2.3. Korisniki zahtjevi (zahtjevi krajnjeg korisnika)

Korisniki zahtjevi trebaju pruiti opise zadataka koje krajnji korisnik softverskog
proizvoda mora moi obaviti sluei se njime. Oni trebaju sadravati funkcionalne i
nefunkcionalne elemente zahtjeva na softver i to u takvom obliku da su razumljivi i korisnicima
koji nemaju tehnika znanja. Korisniki zahtjevi trebaju specificirati vanjsko ponaanje
sustava, bez opisivanja detaljnih karakteristika dizajna i naina implementacije softverskog
proizvoda. Korisniki zahtjevi ne trebaju sadravati tehnike specifikacije. U njihovom pisanju
se preporuuje koritenje standardnog, prirodnog naina opisa. Naravno, to sa sobom nosi i
odreene negativnosti koje proistiu iz same prirode takvog pristupa. Naime, koritenjem takvog

8
naina notacije generiraju se odreene nejasnoe, nedovoljno precizni zahtjevi, nepotpuni
zahtjevi, suvie opi (generalni) zahtjevi
Upravo zbog takvih problema potrebno je, kad god je to mogue, uz korisniki zahtjev
navesti i odgovarajue obrazloenje. To e u poetku zahtijevati neto vie vremena, meutim
takav pristup e se isplatiti u kasnijim fazama razvoja softverskog proizvoda. Naime, neprecizno
definirani i nepotpuni zahtjevi, naroito funkcionalni, su glavni razlog neuspjenog razvoja
softvera i/ili probijanja rokova njegovog razvoja. Takoer, dobra je praksa usvojiti i pridravati
se odreenih (standardnih) smjernica tokom evidentiranja korisnikih zahtjeva, npr. uz svaki
korisniki zahtjev navoditi (u standardiziranom obliku) tko je predloio zahtjev (izvor zahtjeva),
razlikovati i drugaije oznaavati obvezne od poeljnih funkcija, naznaiti meusobne ovisnosti
zahtjeva, posebno isticati kljune elemente zahtjeva, izbjegavati previe usko-strunih opisa i
termina
Neki autori (Robertsons, 1999.) istiu potrebu da se svaki korisniki zahtjev evidentira na
posebnoj kartici, koja sadri tono definirana polja: obrazloenje zahtjeva, ovisnosti o drugim
zahtjevima, izvor zahtjeva itd..[1]

2.4. Sistemski zahtjevi

Sistemskim zahtjevima detaljno i precizno se definiraju funkcije sustava i ogranienja.

Sistemski zahtjevi se mogu shvatiti kao proirena verzija korisnikih zahtjeva koji slue
softverskim inenjerima kao polazna toka za dizajniranje sustava. Oni dodaju detalje i
objanjenja na koji nain e korisniki zahtjevi biti podrani od strane sustava. Sistemski zahtjevi
u mnogim sluajevima predstavljaju i dio ugovora izmeu kupaca i razvijaa (engl. developers)
softvera. U pravilu, sistemski zahtjevi ne trebaju sadravati tehnike detalje o tome kako e
sustav biti dizajniran ili implementiran, meutim, vrlo je teko, ili je nemogue, izbjei sve takve
informacije prilikom detaljnog opisa funkcionalnosti jednog kompleksnog sustava, kakav je u
pravilu softverski proizvod. U tom kontekstu i prilikom samog pisanja sistemskih zahtjeva nije
mogue izbjei koritenje profesionalne tehnike notacije, naprotiv, ovdje se to preporuuje.
Sistemski zahtjevi, dakle, podrazumijevaju koritenje tzv. strukturiranog prirodnog jezika (stroga
uniformirana struktura navoenja zahtjeva), grafikih modela zahtjeva, matematikih formula
Primjena iskljuivo prirodnog jezika nije adekvatna prilikom definiranja sistemskih zahtjeva,
zbog ve ranije navedenih nedostataka.

9
 2.5. Zahtjevi usmjereni ka suelju (interfejsu) sustava

Gotovo svaki novi softverski proizvod mora komunicirati sa sustavom koji ve

egzistira u korisnikom okruenju. Obzirom na tu injenicu, neophodno je precizno definirati
karakteristike suelja postojeeg sustava. Te specifikacije trebaju biti definirane u poetnim
fazama i obavezno ukljuene u konani dokument softverskog zahtjeva (najee kao prilog).
Tri su osnovna tipa suelja (i specifikacija suelja) koja mogu biti definirana:
- Proceduralna suelja (engl. procedural interfaces) gdje postojei programi nude
odreene usluge (servise) dostupne putem poziva odgovarajuih interfejs-
procedura,
- Suelja za podatkovne strukture (engl. data structures) koje definiraju strukture
podataka i podatke koji se razmjenjuju izmeu programskih podsustava. Za
njihovo specificiranje najee se koriste grafike tehnike, poput ERA modela.
- Naini predstavljanja podataka (engl. data representations) koji se koriste u
postojeem softveru (npr. poredak bitova). Ovaj tip suelja je najvie prisutan u
real-time sustavima. Najbolji nain za izradu specifikacija ovog tipa su
odgovarajui dijagrami strukture koji sadre dodatna objanjenja funkcija
pojedinih skupina bitova.

10
 3. INENJERSTVO ZAHTJEVA

Inenjerstvo zahtjeva (engl. requirements engineering) je proces generiranja i

dokumentiranja zahtjeva. To je prva generika aktivnost tokom svakog procesa programskog
inenjerstva.
Procesi koji su u uporabi u inenjerstvu zahtjeva razlikuju se ovisno o domeni primjene,
ljudskim resursima i organizaciji koja oblikuje zahtjeve. Nema jedinstvenog procesa inenjerstva
zahtjeva, koji moe biti univerzalno primjenjiv.
Dva su uobiajena modela procesa inenjerstva zahtjeva - klasini i spiralni.
U okviru svakog procesa inenjerstva zahtjeva mogu se uoiti sljedee generike
aktivnosti:
- Studija izvedivosti (engl. feasibility study)
- Izluivanje (otkrivanje) zahtjeva (engl. requirements elicitation), analiza i
specifikacija.
- Validacija zahtjeva
- Upravljanje zahtjevima, odnosno promjenama u zahtjevima.

Studija Izluivanje i
izvedivosti analiza zahtjeva

Specifikacija
Izvjetaj zahtjeva
studije
izvedivosti
Validacija
zahtjeva
Modeli
sustava

Korisniki i
sistemski
zahtjevi

Specifikacija
softverskog
zahtjeva (SRS)

Slika 1: Klasini model procesa inenjerstva zahtjeva [1]

11
 Specificiranje SPECIFICIRANJE
sistemskih zahtjeva ZAHTJEVA

Specificiranje
korisnikih zahtjeva

Specificiranje poslovnih
zahtjeva

Otkrivanje
sistemskih Studija
Otkrivanje
zahtjeva izvedivosti
korisnikih
zahtjeva
Izrada
prototipa

IZLUIVANJE
ZAHTJEVA Recenzije VALIDACIJA
(engl. rviews) ZAHTJEVA

Specifikacija softverskog
zahtjeva (SRS)

Slika 2 : Shema spiralnog modela procesa inenjerstva zahtjeva [1]

Spiralni model inenjerstva zahtjeva definiran je kao tro-stupanjska aktivnost

(specifikacija, validacija, izluivanje). Promatra proces inenjerstva zahtjeva kroz iteracije
ciklusa svih aktivnosti, za razliku od klasinog modelu, gdje se ne ponavlja cijeli ciklus. U
svakoj iteraciji je razliit intenzitet aktivnosti (u ranim iteracijama fokus je na razumijevanju
poslovnog modela, u kasnijim na modeliranje sustava). Zahtjevi se u pojedinim iteracijama
specificiraju s razliitom razinom detalja.

3.1. Studija izvedivosti

Za sve nove sustave poetak procesa inenjerstva zahtjeva treba biti provoenje studije
izvedivosti, iji rezultat je izvjetaj koji sadri preporuku o daljnjem razvoju sustava ili

12
odustajanju od projekta, odnosno da li je predloeni sustav isplativ ili ne. Ulazna informacija za
studiju izvedivosti je preliminaran skup poslovnih zahtjeva.
Studija izvedivosti treba biti realizirana kao kratka, fokusirana studija koja za cilj ima
pruanje odgovora na nekoliko bitnih pitanja, na primjer:
- Da li sustav doprinosi ciljevima organizacije u koju se uvodi ?
- Da li se sustav moe izvesti postojeom tehnologijom i predvienim sredstvima ?
- Da li se predloeni sustav moe integrirati s postojeim sustavima organizacije u
koju se uvodi ?
Temeljno pitanje ovdje je doprinosi li sustav ostvarivanju ciljeva organizacije ili ne. Ako
predloeni sustav ne doprinosi osnovnim ciljevima organizacije, dakle nema pozitivan utjecaj na
ostvarivanje poslovnih rezultata, nema ga smisla implementirati. Iako je ovo oigledan i vie
nego logian zakljuak, u praksi se vrlo esto dogaa da organizacije razvijaju upravo takve
sustave, koji ne doprinose ostvarivanju ciljeva organizacije, naprotiv. Razlozi za takve
nerazumne odluke mogu biti posljedica unutar-organizacijskih slabosti i/ili vanjskih (npr.
politikih) utjecaja.
Provedba studije izvedivosti temelji se na odreivanju koje informacije su potrebne za
studiju, prikupljanju tih informacija i pisanju izvjetaja. U provedbi studije izvedivosti
neophodno je konsultirati razliite izvore informacija: strunjake koji imaju iskustva u radu sa
predloenim sustavom, ili slinim sustavima, softverske inenjere koji su upoznati sa tehnikim
karakteristikama i performansama sustava, rukovodioce odjela gdje e sustav biti implementiran
i, naravno, krajnje korisnike. Studija treba biti vie-aspektna. Ne smije biti koncentrirana samo
na tehniko-tehnoloki aspekt izvedivosti, nego treba ukljuiti i analizu operativne izvedivosti,
vremenske i, naravno, analizu ekonomske izvedivosti predloenog rjeenja.
Preporueno trajanje ove aktivnosti ne bi smjelo biti due od 21 dan. U konanom
izvjetaju mogu biti predloene i odgovarajue izmjene do kojih se dolo tokom izvoenja
studije, a odnose se na postavljene ciljeve, planirani budet, dodatne zahtjeve i sl.. Rezultat
studije mora sadravati jasnu i nedvosmislenu preporuku o nastavku ili odbijanju razvoja i
implementacije predloenog sustava.

13
 - ORGANIZACIJSKO-OPERATIVNA IZVEDIVOST
o Procjena hitnosti rjeavanja problema
o Procjena prihvatljivosti rjeenja
- VRIJEDI LI RJEAVATI PROBLEM? DA LI PREDLOENO RJEENJE
RJEAVA PROBLEM?
o Performanse protonost i odziv sustava
OPERATIVNA
IZVEDIVOST

o Informacije dovoljne, pravodobne, prikladne, aurne

o Ekonomija problemi trokova, mogunost uteda
o Kontrola sigurnost i zatita podataka
o Uinkovitost poboljanje upotrebe raspoloivih resursa
o Usluge poeljni i pouzdani servisi, fleksibilnost
- STAV KORISNIKA PREMA PREDLOENOM RJEENJU? DA LI E
KORISTITI SUSTAV?
o Podrka uprave i prihvaanje od strane krajnjih korisnika
o Mogui otpori i kako ih prevladati
o Procjena upotrebljivosti (lakoa koritenja, vrijeme osposobljavanja,
zadovoljstvo)
- PRIHVATLJIVOST VREMENSKOG RASPOREDA
o Razmatra se opravdanost rokova s obzirom na raspoloivu strunost
VREMENSKA
IZVEDIVOST

- OEKIVANO VRIJEME ZAVRETKA MOE BITI POELJNO ILI

OBAVEZNO
o vrsti rokovi
o Poeljni rokovi moe se predloiti alternativni vremenski plan
(Bolje je isporuiti ispravan sustav tri mjeseca kasnije, nego neispravan i ne
naroito koristan na vrijeme!)
- Procjena rjeenja i moguih alternativa
TEHNOLOKA
IZVEDIVOST

o Procjena stanja na tritu opreme

TEHNIKO-

o Procjena postojeih rjeenja u drugim organizacijama

- Primjenjivost rjeenja, tehnologije
o Moe li se tehnologija jednostavno primijeniti?
o Koritenje najsuvremenijih tehnologija ili zrelih, ve dokazanih?
- Strunost
- Troak razvoja sustava (fiksni troak)
o Apsolutni iznos, poetna procjena, auriranje u toku prjekta
o Plae, honorari osoblja
o Oprema
EKONOMSKA
IZVEDIVOST

o Izobrazba
- Troak primjene sustava
o Relativan iznos, ovisan o upotrebi
o Reije (struja, telefon, )
o Odravanje
o Obnova licenci
- Analiza i usporedba ukupnih trokova-koristi (cost-benefit analysis)
o Trokovi i korist - analiza mjerljivih (cijena opreme, iznos plaa,
prihod) i nemjerljivih faktora(reference, zadovoljstvo korisnika)
Tabela 2: Dimenzije studije izvedivosti

14
 3.2. Izluivanje i analiza zahtjeva

Ova faza procesa inenjerstva zahtjeva moe se smatrati najznaajnijom (i

najkritinijom). Ukljuuje struno, tehniki obrazovano osoblje koje u zajednikom radu s
kupcima i krajnjim korisnicima razjanjava domenu primjene, definira usluge koje sustav treba
pruiti, te odreuje ogranienja u radu sustava.
Ova aktivnost ukljuuje sve zainteresirane strane. Dakle u procesu izluivanja (i analize)
zahtjeva sudjeluju:
- krajnji korisnici sustava,
- menaderi (rukovodioci),
- inenjeri ukljueni u odravanje sustava,
- eksperti domene primjene,
- predstavnici sindikata i sl.
Sve njih jednim imenom nazivamo dionicima, odnosno stejkolderima (od engl. rijei
stakeholder) .
Izluivanje i samo razumijevanje zahtjeva stejkholdera je zahtjevna i relativno
problematina aktivnost, i to iz vie razloga:
- Stejkholderi ne znaju to stvarno ele, teko artikuliraju zahtjeve ili su zahtjevi
nerealni;
- Stejkholderi izraavaju zahtjeve na razliite, njima specifine naine (posjeduju
implicitno znanje o svojem radu - domeni).
- Razliiti stejkholderi imaju razliite zahtjeve, izraene na razliite naine, koji
nerijetko mogu biti u odreenom konfliktu;
- Organizacijski i politiki faktori takoer mogu utjecati na zahtjeve (npr.
rukovodioc trai da sustav ima znaajke koje poveavaju njegov utjecaj u
organizaciji);
- Zbog dinamike ekonomskog i poslovnog okruenja zahtjevi se mijenjaju za
vrijeme procesa analize;
- Uz promjenu poslovnog okruenja pojavljuju se i novi stejkholderi, s novim,
specifinim zahtjevima.
Opi model procesa izluivanja i analize zahtjeva moe se predstaviti na nain kako je to
prikazano sljedeom slikom

15
 Klasificiranje i Odreivanje
organiziranje prioriteta i
zahtjeva pregovaranje

Izluivanje zahtjeva Dokumentiranje zahtjeva

Slika 3: Spiralni model procesa izluivanja i analize zahtjeva [1]

Sa slike je vidljivo da je proces izluivanja i analize sloen iterativni proces, u kojem se

kao u spirali smjenjuju (i nadopunjuju) aktivnosti:
- Izluivanja (otkrivanja) zahtjeva podrazumijeva komuniciranje sa
stejkholderima s ciljem prikupljanja njihovih zahtjeva;
- Klasificiranja i organiziranja zahtjeva obuhvaa organiziranje zahtjeva
prikupljenih u prethodnoj aktivnosti, srodni zahtjevi se ureuju u koherentne
klastere;
- Odreivanja prioriteta i pregovaranja - zahtjevi se razvrstavaju po prioritetima i,
kroz pregovaranje, razrjeavaju eventualni konfliktni zahtjevi, koji su mogui s
obzirom da se zahtjevi prikupljaju iz vie izvora, odnosno od strane razliitih
interesnih strana (stejkholdera);
- Dokumentiranja zahtjeva obuhvaa aktivnost dokumentiranja zahtjeva
(formalnim i neformalnim dokumentima) koji se ubacuju u slijedei ciklus
spirale izluivanja i analize zahtjeva.

16
 U procesu otkrivanja i analize zahtjeva koristi se nekoliko tehnika, koje se meusobno ne
iskljuuju. Njihovim paljivim i usmjerenim kombiniranjem mogue je razotkriti veinu
zahtjeva. Najee koritene tehnike su:
- Intervjui (engl interviews),
- Upitnici i ankete
- Radni sastanci, sjednice, radionice (engl. workshops),
- Storyboarding
- Scenariji
- Obrasci upotrebe (engl. use cases)
- Dijagrami interekcije
- Prototipiranje (engl. prototyping)
U nastavku e biti opisane neke, od gore navedenih tehnika, one koje su najee
koritene u procesu izluivanja i analize zahtjeva.

3.2.1. Intervjuiranje

Intervju je jednostavna tehnika, direktna i interaktivna, koja moe imati formalni ili
neformalni karakter. Intervju sa zainteresiranim stranama (stejkholderima) je dio veine procesa
inenjerstva zahtjeva, preciznije, procesa prikupljanja i otkrivanja zahtjeva. Tim zaduen za
inenjerstvo zahtjeva paljivo priprema pitanja o postojeem sustavu, ali i o novom sustavu koji
se razvija. Iz odgovora stejkholdera na ova pitanja izvode se odgovarajui zahtjevi.
Dva su osnovna tipa intervjua:
- Zatvoreni zainteresiranim stranama se predoava skupina unaprijed definiranih
pitanja i
- Otvoreni intervju ne postoje unaprijed pripremljena pitanja, ve tim zaduen za
inenjerstvo zahtjeva otvara niz pitanja o kojima se raspravlja sa zainteresiranim
stranama s ciljem ostvarivanja boljeg razumijevanja njihovih potreba i, naravno,
otkrivanja i definiranja zahtjeva.
U praksi se intervjui sa zainteresiranim stranama organiziraju i odvijaju po obrascu koji
bi se mogao definirati kao mjeavina dva prethodno navedena oblika intervjuiranja. Naime,
odgovori na odreena (pripremljena) pitanja, mogu otvoriti neka nova (ne planirana) pitanja koja
se, potom, raspravljaju na manje strukturiran nain. Potpuno otvorena, ne strukturirana diskusija

17
tokom intervjuiranja nije dobro rjeenje, stoga se za intervju definira neki okvirni set pitanja koji
e osigurati da se tokom intervjua ne izgubi fokus.
Intervjui se mogu organizirati kao individualni i kao grupni. Individualni intervjui se
provode sa jednim osobom ili sa manjim brojem osoba koji rade isti posao. Grupni intervju
podrazumijeva intervjuiranje vie osoba iz razliitih podruja.
Intervju je dobra tehnika za dobivanje generalne, uopene slike o aktivnostima
stejkholdera, slike o njihovom poslu, koji predstavlja podruje od interesa budueg sustava.
Intervju moe pruiti jasnu predodbu o tome kako razliite zainteresirane strane vide budui
sustav, to im nedostaje kod postojeeg sustava, to stvara najvee potekoe i to oekuju od
novog sustava.
Intervju nije idealna tehnika za otkrivanje i analizu zahtjeva, naprotiv. Intervju ima niz
nedostataka, ne rijetko se dogaa da sugovornici ne govore istim jezikom. Softverski inenjeri
koriste informatiki argon koji krajnjim korisnicima nije uvijek jasan. Korisnici, s druge strane,
nisu dovoljno precizni niti su u stanju artikulirati svoje zahtjeve na adekvatan nain. Potekoe
se javljaju i u razgovorima sa ekspertima, koji, u pravilu, ne mogu shvatiti kako nekome tako
jednostavne stvari nisu jasne.
Informacije dobivene intervjuiranjem nisu same za sebe dovoljne, potrebno ih je dopuniti
informacijama prikupljenim koritenjem drugih tehnika kako bi se jasno mogli definirati
zahtjevi.
Neke preporuke za pripremanje i voenje intervjua:
- Intervju treba biti dobro pripremljen i osmiljen, s jasno definiranim ciljem.
- Pripremiti kvalitetna pitanja koja e ponuditi to jasnije odgovore, odnosno
osigurati utvrivanje informacija koje se ele saznati.
- Prouiti prethodne nalaze i raspoloivu dokumentaciju prije intervjua.
- Nita nije razumljivo i samo po sebi svima jasno.
- Ne pretpostavljati.
- Izbjegavati sugestivna pitanja.
- Ne nametati zakljuke.
- Iskrenost i nepristranost (cilj je osigurati korisniku najkvalitenije rjeenje, a ne
gurati odreena programska rjeenja).
- Provjeriti odgovore razliitih sugovornika na ista pitanja.

18
 - Analizirati injenice koje se ne poklapaju.
- Razluiti injenice od miljenja ili stavova.
- Izbjegavati grupno intervjuiranje (iznimno provesti u situacijama kada se eli
utvrditi odreeni zajedniki interes ili razrijeiti neka konfliktna situacija ili
proturjeje).
- Samostalno voditi zapisnik (tko ne razumije, ne moe biljeiti).
- Zapisnik intervjua mora sadravati ono to je reeno i slijediti tok razgovora.
- Zapisnik se alje sugovorniku/sugovornicima na uvid i potvrdu vjerodostojnosti.
- Intervju ne bi trebao trajati due od 2 sata.
- Na poetku intervjua predstaviti sve sudionike i upoznati ih sa svrhom razgovora.
- Intervju zavriti 5-10 min. prije isteka planiranog vremena.
- Provjeriti postoji li neto to je sugovornik htio rei, a nije bilo pitano.
- Dogovoriti eventualni nastavak intervjua (intervju je otvorio neka nova pitanja).
- Zahvaliti sugovorniku/sugovonicima [3].

3.2.2. Radni sastanci

Radni sastanci, sjednice ili radionice (engl. workshops) su tehnika otkrivanja i

analiziranja zahtjeva u kojoj kljuni stejkholderi zajedniki provode analizu i oblikovanje
zahtjeva. Radni sastanci imaju unaprijed definiran dnevni red, odvijaju se u posebno
prilagoenom prostoru, koji treba pruiti ugodan ambijent i osigurati nesmetan rad, sastankom
upravlja moderator, a zapisniar vodi detaljan zapisnik. Cilj sjednice je zajedniko pronalaenje
najboljeg rjeenja.
Osnovne prednosti ove tehnike su:
- Radni sastanci su pogodni u sluajevima kada se rjeavaju od opeg interesa,
- Prua mogunost preciznijeg utvrivanja dosega projekta,
- Osigurava efikasnije determiniranje proturjenih zahtjeva,
- Omoguava razrjeavanje proturjenih zahtjeva.
Ova tehnika ima i niz nedostataka, na primjer:
- Pasivnost sudionika,
- Ne rijetko dolazi do udaljavanja od osnovne teme,
- Usitnjavanje razgovora,

19
 - Sjednice bi trebale trajati vie dana, meutim to je u praksi vrlo teko ostvariti
zbog obaveza sudionika.
Uz radionice je usko vezana tehnika brainstorming, koja sudionike potie na aktivno i
kreativno sudjelovanje. Primjenjuje se tako da se od svakog sudionika zatrai da definira, po
njemu, idealno rjeenje konkretnog problema. Svaki sudionik iznosi sve to mu padne na
pamet u vezi s problemom koji se rjeava, ime se dopunjuju ve ponuena rjeenja ili
generiraju nova. Na kraju brainstorming sesije odabire se najbolje rjeenje. Ova tehnika je
uinkovita u sluajevima kada su sudionici dobri poznavatelji problemskog podruja.

3.2.3. Izrada prototipa (prototyping)

Prototip kao koncept budueg sustava dugo je vremena smatran zdravim pristupom za
dobro definiranje zahtjeva. Prototip prua korisniku stvarnu sliku onoga to bi softversko
rjeenje trebalo predstavljati. Prototip doprinosi pozitivnom stavu korisnika prema buduem
softverskom proizvodu jer mu pomae da shvati mogunosti ponuenog rjeenja. Meutim, taj
korisnikov entuzijazam moe predstavlja i problem, jer se panja posveuje mnogim nebitnim
detaljima na unosnim formama (smjetaj i veliina polja i dugmadi, boja slova i pozadine i sl.).
O samoj funkcionalnosti gotovo da se i ne razmilja. Problem je i to korisnik prototip smatra
skoro gotovim proizvodom te ne razumije zato treba jo tako puno vremena da se to isto
rjeenje zavri i stavi u upotrebu. Zbog toga, a i zbog lanog osjeaja sigurnosti proizalog iz
zadovoljstva korisnika, programeri na vrat na nos iz prototipa izrauju gotov softverski
proizvod. Preporuka je da se prototip ne koristi u analizi i prikupljanju zahtjeva.
Kao model rane verzije sustava daje teite na korisniko suelje, ne rijetko
zanemarujui sve to se dogaa unutar sustava. Upravo zbog toga treba biti paljiv u koritenju
prototipa kao tehnike za izluivanje i analizu zahtjeva. Tehnika prototipiranja se koristi kada
korisnik ne moe tono definirati svoje informacijske potrebe prije nego to se izgradi sustav.
Izrada prototipa pogodna je u onim okruenjima gdje je teko definirati konkretni model sustava
te u okruenjima gdje se informacijske potrebe korisnika mijenjaju ili razvijaju.

3.2.4. Storyboarding

Svrha storyboard tehnike je stei ranu reakciju korisnika na predloeni koncept. Ova
tehnika je uinkovita u razrjeavanju "Da, ali " sindroma. Storyboarding je iznimno jeftina
20
tehnika koja se koristi za izluivanje i analizu zahtjeva, informativna je, zanimljiva je, ne
zahtjevna, lagano se kreira i modificira. Moe biti realizirana kao:
- Pasivna tehnika korisniku (stejkholderu) se opisuje problemsko podruje kroz
niz skica, slika, ekranskih isjeaka (engl. screen shoots), primjera aplikacijakih
izlaza i sl. i to sve uz objanjenja tipa kada uradite to dogodit e se ovo;
- Aktivna tehnika podrazumijeva da se izradi i predstavi operativni scenarij,
prezentacija koja e sadravati opis i ponaanje sustava u tipinom, korisnikom
okruju;
- Interaktivna tehnika izraditi takvu prezentaciju koja e korisniku omoguiti da
upozna sustav, na realan i praktian nain. Zahtijeva aktivno sudjelovanje
korisnika.
Cilj storyboarding tehnike nije samo prianje prie o predloenom rjeenju, ve se, uz
predstavljanje rjeenja, nastoje otkriti i mnogi skriveni zahtjevi.

3.2.5. Scenariji

Scenariji su esto koritena tehnika izluivanja zahtjeva, jer je ljudima znatno lake
razumjeti, vizualizirati i, naposljetku, prihvatiti odreena objanjenja koja su realizirana kroz
opise iz stvarnog ivota, nego one opise koji su i suvie apstraktni. Scenariji su upravo takva
tehnika koja se bazira na realnim primjerima naina koritenja i funkcioniranja sustava. Tokom
prezentiranja scenarija se diskutira i kritizira ponueni scenarij, to omoguava otkrivanje i
formuliranje zahtjeva. Ova tehnika definiranja i formuliranja zahtjeva je integralni dio agilnih
metoda (poput eksteremnog programiranja).
Svaki scenarij treba biti realiziran kao opis neke konkretne interakcije korisnika sa
sustavom i trebao bi sadravati:
- Opis poetne situacije;
- Opis normalnog (standardnog) toka dogaaja;
- Opis svega to moe poi po zlu i naina oporavka;
- Informacije o paralelnim aktivnostima;
- Opis stanja sustava u trenutku kada konkretni scenarij zavrava.
Primjer scenarija fakultetskog knjininog sustava koji omoguuje naruivanje knjiga i
dokumenata iz drugih knjinica (sustav LIBSYS, opisan u [1]):

21
 Poetno stanje:

Korisnik je pristupio (logirao se) u sustav i locirao asopis u kojem se nalazi eljeni lanak.

Normalan rad:

Korisnik selektira lanak za kopiranje. Sustav trai od korisnika informaciju o njegovim

pravima (tip pretplate) ili nainu plaanja. Opcije plaanja su kreditna kartica ili raun
organizacije koja ima pretplatu. Sustav, potom, trai da korisnik potpie formular o pravima
na kopiranje i ostalim detaljima transakcije. To se upisuje u sustav. Formular o pravima na
kopiranje se provjerava, i ako je u redu lanak u PDF formatu se prosljeuje do korisnikog
raunala koje je u sklopu sustava. Korisnik treba odabrati pisa i kopija lanka se ispisuje.
Ukoliko je lanak tipa samo za ispis, lanak se brie sa korisnikog raunala nakon to
korisnik potvrdi da je ispis zavren.

to moe poi krivo:

a) Korisnik nije ispravno popunio formular o pravima na kopiranje. U tom sluaju formular
se mora ponovo dati korisniku na ispravak. Ako je ponovljeni formular krivo ispunjen,
zahtjev korisnika se odbacuje.
b) Sustav moe odbaciti i nain plaanja. Korisnikov zahtjev se odbacuje.
c) Prijenos lanka na korisnikovo raunalo nije ispravno izveden. Treba ponavljati dok
prijenos ne bude uspjean ili dok korisnik ne prekine transakciju.
d) lanak nije mogue ispisati. Ako lanak nije tipa samo za ispis dri ga se u radnom
prostoru sustava, u suprotnom lanak se brie i korisnika se kreditira u visini cijene
lanka.

Paralelne aktivnosti:

Prijenos i obrada zahtjeva drugih korisnika sustava.

Zavrno stanje:

Korisnik je i dalje u sustavu. Skinuti lanak je obrisan ako je oznaen atributom samo za
ispis.

3.2.6. Sluajevi koritenja

Sluajevi koritenja ili obrasci upotrebe (engl. use cases) je tehnika izluivanja zahtjeva
bazirana na scenarijima. Svoje porijeklo ima u objektno- orijentiranom (OO) pristupu razvoja.
Radi se o naizgled jednostavnoj tehnici koja prikazuje meusobnu povezanost sustava i okoline
opisujui to ulazi u sustav i to iz sustava izlazi. Sluaj koritenja je relativno jednostavne

22
strukture, ali vrlo je zahtjevno ispravno ga napraviti. Sluaj koritenja je jedan od dijagrama
objektno orijentirane metode za modeliranje - UML (Unified Modeling Language). Sluaj
koritenja se crta prije svih ostalih dijagrama i osnova je za ostale dijagrame. Sluajevi koritenja
i dijagrami sluajeva koritenja su dokumenti koji trebaju biti razumljivi korisniku, osmiljeni su
i napisani jezikom korisnika, izbjegavajui strune (informatike) izraze i detalje vezane za
implementaciju. Sluaj koritenja je pogodan za otkrivanje zahtjeva, ali i za kompletan ciklus
razvoja softverskog proizvoda.
Sluaj koritenja (use case) je skup scenarija povezanih jednim ciljem korisnika. U
terminologiji sluajeva koritenja korisnici predstavljaju sudionike ili aktore (engl. actors).
Sudionik je uloga korisnika u odnosu na sustav. U svakom sluaju koritenja postoji glavni
(engl. primary) sudionik koji je najee i inicijator (pokreta) sluaja koritenja. Sudionici su
vanjski dijelovi sustava te su njihove odgovornosti takoer van sustava. Dobro bi bilo svakog
sudionika tretirati kao pretpostavku. Sudionik e vjerojatno biti analiziran i kada analitiar
pone izgraivati objektni model. Sudionici e imati utjecaj na izradu klasa, najee sudionici i
postaju klase podataka, stoga je vano od poetka prepoznati i selektirati sudionike sluaja
koritenja.
Sluaj koritenja se dokumentira sa tekstualnim dokumentom i odgovarajuim
dijagramom sluaja koritenja.
Dijagram sluaja koritenja ima svoje simbole i pravila konstruiranja. Dijagram sluaja
koritenja je prikaz veze izmeu dva sluaja koritenja ili izmeu sluaja koritenja i sudionika.
Sudionicima se na dijagramima sluajeva koritenja dodjeljuju odgovarajua imena, pri emu je
vrlo vano pravilno odabrati ta imena. Aktori su na dijagramima predstavljeni sljedeim
simbolom

Sudionik

a SK simbolom elipse unutar koje je naveden naziv sluaja koritenja, npr.

Izdavanje rauna

23
 Sudionici s sluajevima koritenja u kojima sudjeluju komuniciraju putem niza poruka.
Niz poruka izmeu sudionika i SK se ne prikazuje na dijagramima sluaja koritenja, ali se
moe prikazati na drugim UML - dijagramima poput sekvencijskog ili komunikacijskog
dijagrama. U UC dijagramima postoji nekoliko vrsta veza koje se mogu ostvariti izmeu
sudionika (aktora) i sluajeva koritenja. Pregled i kratki opis svih vrsta veza prikazan je u
sljedeoj tablici:

Tip veze Grafiki prikaz Opis

Asocijacijom se povezuju aktori sa
sluajevima koritenja u kojima sudjeluju.
asocijacija Meusobno povezivanje aktora ili
meusobno povezivanje SK -a ovom vrstom
veze nije dozvoljeno
Generalizacijom se povezuju dva aktora ili
dva SK. U sluaju da se generalizacijom
povezuju dva aktora, specifiniji aktor
preuzima sve uloge apstraktnijeg aktora uz
generalizacija dodatak novih uloga. Kod koritenja
generalizacije izmeu dva obrasca uporabe
specifiniji obrazac proiruje odnosno
mijenja funkcionalnosti apstraktnijeg
obrasca uporabe.
Vezom ukljuivanja se povezuju dva SK
ukljuivanje << include >> na nain da jedan SK u toku svog
izvoenja u potpunosti izvede drugi,
ukljueni SK.
Vezom proirenja se povezuju dva SK pri
emu jedan proiruje funkcionalnost
<< extend >>
proirenje drugog. Proirenje se ostvaruje ukoliko je
zadovoljen odreeni uvjet definiran u toki
proirenja.
Tabela 3: Simboli za tipove(vrste) veza u UC dijagramima

24
 Slika 4: Primjer dijagrama sluaja koritenja za rezerviranje smjetaja

U obrascu (tekstualnom opisu) sluaja koritenja se, izmeu ostalog, opisuje scenarij tj. tok
dogaaja (koraka) od kojih se sastoji konkretni sluaj koritenja. Opis svakog koraka mora biti
jednostavan i mora jasno pokazivati tko je zaduen za njegovo izvravanje.
Obrazac sluaja koritenja moe imati sljedeu formu:

Autor:
Datum
Naziv sluaja koritenja:
Sudionik:
Opis:
Normalni tok:
Alternativni tok:
Pretpostavke:
Tabela 4: Elementi obrasca sluaja koritenja

Prilikom izrade obrasca treba se pridravati ovih preporuka:

25
 - svaki dio obrasca treba imati jednak znaaj (svi dijelovi trebaju biti jednako
vani);
- koristiti minimum odlomaka za definiranje posla. Iako analitiar ima potrebu to
vie
- toga napisati, stalno treba imati na umu da korisnik preferira obrasce koje moe
brzo pregledati;
- za svaki sluaj koritenja e vjerojatno trebati jedna ili vie stranica teksta. Na
obrascu treba ostaviti dovoljno prostora za upis.
Da bi osigurali kvalitetu prikupljenih i analiziranih zahtjeva strunjaci iz ove oblasti
predlau iterativni pristup izrade sluajeva koritenja, pri emu istiu najmanje sljedee tri
iteracije:
1. Izgradnja - kao skup sluajeva koritenja opisanih na visokom nivou,
2. Punjenje - proirenje i produbljenje na vie detaljnijih sluajeva koritenja,
3. Fokusiranje - usredotoenje i ogranienje na ono to je cilj aplikacije.
UC kao tehnika procesa otkrivanja i analize zahtjeva ima niz prednosti u odnosu na druge
tehnike:
- poboljava komunikaciju,
- zbog tekstualnog opisa i dijagrama razumljivija je svim stejkholderima,
- pomae u identificiranju granica sustava,
- pomae u izbjegavanju preranog dizajna sustava,
- fokus je na onome TO sustav treba raditi, a ne KAKO,
- ne koriste specifian jezik,
- omoguavaju relativno lako praenje korisnikih zahtjeva tokom ivotnog ciklusa
sustava.

3.2.7. Etnografija u inenjerstvu zahtjeva

Softverski sustavi nisu izolirani, oni su dio ireg socijalnog i organizacijskog okvira, koji
utjee i na mnoge zahtjeve prema sustavu i definira njegove granice, a (ne)ispunjenje tih zahtjeva
je esto kljuno za uspjeh i prihvaanje sustava. Jedan od razloga zbog kojih se mnogi
isporueni softverski sustavi nikada nisu koristili je upravo nedovoljno poznavanje i vrednovanje
takvih zahtjeva [1][2].

26
 Etnografija je opisni (deskriptivni) dio etnologije, znanost koja opisuje i prouava
materijalnu, drutvenu i duhovnu kulturu (ivot, obiaje, vjerovanja i dr.). Etnografija se odnosi
na kvalitativni opis pojava ljudskog drutva utemeljen na terenskom radu. Etnografija je metoda
holistikog istraivanja zasnovana na ideji da se svojstva sustava ne mogu nuno razumjeti na
pouzdan nain neovisno jedna o drugima. [9]
Etnografija se, dakle, u RE procesu moe koristiti kao opservacijska tehnika, tehnika
promatranja kako ljudi stvarno rade. Etnografske studije pokazuju da je rad obino dinaminiji i
kompleksniji nego to to sugeriraju (jednostavni) modeli sustava.
Etnografija se koristi za otkrivanje dva tipa zahtjeva:
- Zahtjeva koji proizlaze iz naina na koji ljudi stvarno rade, a ne kako proces
definira da bi ljudi trebali raditi i
- Zahtjeva koji proizlaze iz suradnje i drugih ljudskih aktivnosti.
Ova tehnika omoguava otkrivanje nekih kritinih, specifinih detalja u nainu
obavljanja poslovnih procesa, koji esto promaknu u procesu prikupljanja i analize zahtjeva
drugim tehnikama.
Etnografija je prvenstveno fokusirana na zahtjeve krajnjeg korisnika i kao takva ne moe
se smatrati cjelovitom metodom ili tehnikom za otkrivanje zahtjeva. Uobiajeno je kombiniranje
rezultata etnografskih studija sa tehnikama prototipa i/ili sluajevima koritenja.

3.3. Validacija zahtjeva

Validacija zahtjeva je faza procesa inenjerstva zahtjeva koja za cilj ima utvrditi da
prikupljeni (i otkriveni) zahtjevi zaista definiraju sustav kakav naruitelj eli.
Validacija zahtjeva podrazumijeva provjeru:
- valjanosti zahtjeva,
- konzistencija zahtjeva ,
- kompletnost zahtjeva,
- realnost zahtjeva,
- provjerljivost zahtjeva,
- razumljivost zahtjeva,
- adaptabilnost.
Osnovne tehnike validacije zahtjeva su:

27
 - recenzija zahtjeva - sistematska analiza zahtjeva od strane strunog tima,
- izrada prototipa - provjera zahtjeva na izvedenom sustavu koji se demonstrira
krajnjim korisnicima i naruiteljima,
- generiranje ispitnih sluaja - razvoj ispitnih sekvenci za provjeru zahtjeva.
Validacija je vrlo bitan proces jer naknadno ispravljanje pogreaka u zahtjevima generira
viestruko vee trokove od ispravljanja pogreaka tokom poetnih faza razvoja.

3.4. Upravljanje zahtjevima ili upravljanje promjenama

Zahtjevi se, naroito u velikim softverskim sustavima, stalno mijenjaju. Te promjene

nastaju iz razliitih razloga:
- zbog promijenjenog modela poslovanja,
- radi boljeg razumijevanja procesa, do ega se dolo tokom samog razvoja sustava,
- radi otkrivanja konfliktnih zahtjeva tokom rada sustava,
- radi otkrivanja novih potreba i prioriteta krajnjih korisnika do kojih se dolazi
primjenom sustava,
- zbog promjena zakona i propisa,
- zbog tehnolokih promjena i inovacija javljaju se novi zahtjevi i potrebe,
- zbog promjena drugih pod-sustava s kojima postoji interakcija,
- zbog promjena koje su nastale samim uvoenjem sustava u organizaciju i
prelaska na novi nain rada

Poetno Promijenjeno
razumijevanje razumijevanje
problema problema

Promijenjeni
Poetni zahtjevi zahtjevi

Vrijeme

Slika 5: Evolucija zahtjeva

28
 Zahtjeve, obzirom na njihovu evoluciju tokom vremena, moemo svrstati u dvije
kategorije:
- trajni zahtjevi relativno su stabilni jer proistiu iz potreba poslovne aktivnosti
organizacije, npr. u knjinici e uvijek postojati zahtjevi za evidentiranjem knjiga,
lanova i izdavanja;
- nestalni (hlapivi) zahtjevi postoji velika mogunost da e se takvi zahtjevi
mijenjati ve u fazi razvoja ili nakon to se sustav implementira u korisniko
okruenje, npr. zahtjevi vezani za obraun kamata.
Upravljanje zahtjevima je, u stvari, proces razumijevanja i kontroliranja promjena koje se
odnose na zahtjeve prema sustavu, a prisutne su konstantno. Promjene se ne mogu zaustaviti, ali
se moe pripremiti za njih na nain da se njima moe to efikasnije upravljati kada se one pojave.
Promjena je prirodni faktor svakog procesa i ona e zasigurno nastati, stoga je neophodno
osigurati odreeni plan, odnosno proces upravljanja promjenama.

3.4.1. Planiranje upravljanja zahtjevima

Planiranje je bitan, prvi korak, procesa upravljanja zahtjevima. Sam proces upravljanja
zahtjevima je vrlo skup. Za svaki projekt u fazi planiranja se utvruje odgovarajua razina
upravljanja promjenama. U procesu upravljanja zahtjevima treba uoiti sljedee aktivnosti:
- Identifikacija zahtjeva svaki zahtjev mora biti na jedinstven nain odreen
(identificiran);
- Proces upravljanja promjenama (u uem smislu) skup aktivnosti kojima se
procjenjuje utjecaj, znaaj i troak promjene;
- Izbor odgovarajueg CASE alata za potporu aktivnostima upravljanja zahtjevima.
S obzirom na koliinu podataka, brojnost veza i njihovu kompleksnost
neophodno je koristiti neki od alata koji e taj posao uiniti efikasnijim;
- Slijednost (engl. traceability, praenje traga) - definiraju se veze izmeu
zahtjeva, veze izmeu zahtjeva i stejkholdera i veze izmeu zahtjeva i pojedinih
modula. Ove veze se moraju sustavno zapisivati i odravati. Najee se za to
koriste odgovarajue matrice, poput one na narednoj stranici:

29
 ID 1.1 1.2 1.3 2.1 2.2 2.3
1.1 D R R
1.2 R
1.3 R D
2.1 R D D
2.2
2.3 R R D
Tabela 5: Traceability matrica (D postoji ovisnost, R postoji slabija veza)

3.4.2. Upravljanje promjenama zahtjeva

Ovu aktivnost ine sljedee tri faze:

1. Analiza problema i specifikacija promjena zapoinje identificiranjem problema
i, ponekad, uz prijedlog promjene zahtjeva. Problem i/ili prijedlog promjene
zahtjeva se potom analiziraju kako bi se utvrdila njihova validnost. Rezultat ove
analize se prosljeuje predlagatelju promjena, odnosno onome tko je uoio
problem, to ne rijetko rezultira konkretnijim, specifinijim i detaljnijim
prijedlogom promjene zahtjeva;
2. Analiza promjene i trokova procjenjuje se uinak predloene promjene na
ostale zahtjeve i generalno funkcioniranje sustava, te se utvruje troak koji bi
promjena prouzroila. Rezultati ove analize su podloga za donoenje odluke o
nastavku procesa promjene zahtjeva;
3. Implementiranje promjene dokumentacija zahtjeva se treba modificirati, kao i
dizajn sustava, ukoliko je to potrebno. esto se dogaa da se neka, hitna
promjena zahtjeva prvo implementira, a tek naknadno se modificira i
dokumentacija zahtjeva. To se nikako ne preporuuje jer to dovodi do
nekonzistentnosti i nepreciznosti u voenju dokumentacije zahtjeva, koja mora
uvijek biti usuglaena sa promjenama sustava.
Faktori promjene, kako vanjski, tako i unutarnji, se dobro pripremljenim pristupom
problemu i upravljanju zahtjevima i njihovim promjenama, mogu minimizirati, ali ne i potpuno
ukloniti, jer promjene su, kao i (male) pogreke u kompleksnim sustavima neizbjene.

3.5. Dokumentiranje zahtjeva

Konani proizvod ili rezultat faze inenjerstva zahtjeva je dokument softverskog

zahtjeva, koji se jo naziva i specifikacija softverskog zahtjeva (SRS). SRS je zvanini dokument

30
koji opisuje to razvijai sustava ili developeri ( od engl. developers) trebaju implementirati.
Svrha ovog dokumenta je komunikacija rezultata faze inernjerstva zahtjeva svim
zainteresiranim stranama (stejkholderima). U pravilu ukljuuje:
- opise korisnikih zahtjeva na sustav i
- detaljne specifikacije zahtjeva.
U sluajevima kada postoji veliki broj zahtjeva, detaljne specifikacije zahtjeva se mogu
prezentirati u zasebnom dokumentu.
Informacije koje sadri SRS su namijenjene razliitim kategorijama stejkholdera, poevi
od naruitelja, krajnjih korisnika, sistemskih inenjera, do inenjera koji su zadueni za razvoj i
implementiranje sustava. Upravo zbog te raznovrsnosti potencijalnih korisnika (itaa) SRS
treba biti realiziran (kao kompromis razliitih pristupa) tako da prui potrebne i adekvatne opise
zahtjeva naruiteljima i korisnicima, dodatno definira detalje zahtjeva za razvojne inenjere i
testere i da ukljui informacije o moguoj evoluciji sustava u budunosti. Te informacije o
moguim i/ili oekivanim promjenama mogu biti vrlo znaajne za sistemske dizajnere u smislu
planiranja fleksibilnog dizajna sustava, odnosno izbjegavanja restriktivnih dizajnerskih odluka i
rjeenja.
SRS
- Menaderi (rukovodioci)
Korisniki - Krajnji korisnici
zahtjevi - Inenjeri (u organizaciji)
- Sistemski dizajneri

- Krajnji korisnici
Korisniki - Inenjeri (u organizaciji)
zahtjevi - Sistemski dizajneri
- Razvojni inenjeri (developeri)

Slika 6: Tko koristi (ita) SRS

Mnogi veliki organizacijski sustavi, poput amerikog Ministarstva obrane ili IEEE, imaju
definirane vlastite standarde za izradu dokumenta softverskog zahtjeva. Najire je rasprostranjen
upravo standard IEEE/ANSI 830 1998., koji propisuje okvirnu, generalnu, strukturu

31
specifikacije softverskog zahtjeva. Osnovna poglavlja Specifikacije prema navedenom standardu
su:

UVOD
Sadri:
Opis svrhe dokumenta i kome je dokument namijenjen
Okvir ili opseg programskog proizvoda (prijedlog opeg imena programskog
proizvoda , kratki opis osnovne funkcije programskog proizvoda, opis mogue
primjene programskog proizvoda, opis koristi od primjene, osnovnih zadaa i
ciljeva primjene
Opis definicija, akronima i kratica
Reference
Opis strukture dokumenta (kratki pregled sadraja poglavlja dokumenta
OPI OPIS SUSTAVA
Sadri:
Opis programskog proizvoda iz perspektive njegova djelovanja i njegove
interakcije s drugim proizvodima. Trebaju se identificirati svi uvjeta rada sa
sustavom: korisniko suelje, hardversko suelje, softversko suelje,
komunikacijsko suelje, memorijski zahtjevi, naini i uvjeti izvoenja
Kratki opis svih funkcija koje programski sustav treba izvoditi
Opis nunih karakteristika korisnika za rukovanje sustavom
Opis ogranienja u razvoju softverskog proizvoda, npr. razne regulative,
ogranienja hardvera, suelja prema drugim funkcijama, mogunost
paralelnog rada, funkcije i kontrole, pouzdanost, sigurnost, i druga mogua
ogranienja
Opis pretpostavki i zavisnosti izvoenja softverskog proizvoda o drugim
elementima s kojima je u interakciji. Za razliku od ogranienja na dizajn ovdje
se navode mogua ogranienja na izvoenje programskog proizvoda (npr.
odreena platforma)
Lista moguih zahtjeva u buduim revizijama
SPECIFIKACIJA ZAHTJEVA SUSTAVA
Ovo je glavni i najznaajniji dio Specifikacije, ujedno i najdue poglavlje u
dokumentu. U realizaciji ovog poglavlja treba biti posebno paljiv, svi zahtjevi
moraju biti dobro specificirani, meusobno referencirani (gdje je potrebno) i
organizirani.
Sadri:
Detaljne specifikacije svih zahtjeva (funkcionalnih i nefunkcionalnih).
DODATCI
INDEKS

32
 Ovaj predloeni okvir (engl. framework) je i suvie openit i moe se prekrajati tako da
odgovara potrebama konkretne organizacije.

33
 4. RIZICI LOEG PLANIRANJA I IZVOENJA PROCESA
INENJERSTVA ZAHTJEVA

Gotovo je nemogue kreirati softverski proizvod koji udovoljava svim zahtjevima svih
zainteresiranih strana, i to iz prve. To je vrlo teko postii i nakon pete ili este revizije
programskog proizvoda. Razloga za to je mnogo, a jedan od najznaajnijih je taj to se okruenje
u kojem ivimo i radimo stalno mijenja, tako da je nemogue sagledati sve aspekte (zahtjeve)
nekog problemskog podruja. Novi zahtjevi se pojavljuju tokom samog razvoja softvera,
mijenjaju se kako interni tako i eksterni faktori koji utjeu na definiranje zahtjeva na sustav.
Mijenjaju se propisi, mijenja se trite, organizacijska politika, stejkholderi u procesu definiranja
zahtjeva otkrivaju nove (dodatne) zahtjeve, novi zahtjevi se pojavljuju i kao rezultat boljeg
upoznavanja sa problemskim podrujem, primjenom programa se takoer otkrivaju novi zahtjevi
ili definiraju prijedlozi za promjenama zahtjeva Dakle, nuno je biti svjestan injenice da
proizvod koji se izrauje nije idealno rjeenje, da e se sigurno mijenjati, unaprjeivati,
prilagoavati i poboljavati kako bi zadovoljio (nove i narasle) zahtjeve. Zato je to nuno?
Nuno je iz nekoliko razloga. Svijest o potrebi prilagoavanja i mijenjanja zahtjeva namee
projektantima zadau da razvijaju softver ija e arhitektura omoguiti provoenje promjena i
definiranje novih zahtjeva bez potrebe za sutinskim re-dizajnom softverskog proizvoda. Dobro
je biti svjestan promjenljivosti (nekih) zahtjeva jer to vodi ozbiljnijem pristupu samom procesu
izluivanja i analize zahtjeva, definiranju vrstih zahtjeva i onih manje vrstih za koje se oekuje
da e se mijenjati (koje treba posebno evidentirati).
Samo upoznavanje moguih rizika vodi do smanjivanja njihovih efekata. Spoznaje o
rizicima omoguavaju da ih se svede na minimum, ako ih ve nije mogue u potpunosti izbjei.
U kontekstu RE procesa to znai da je potrebno tako planirati i voditi aktivnosti inenjerstva
zahtjeva kako bi se u poetku to bolje definirali zahtjevi na sustav (kako funkcionalni tako i
nefunkcionalni) i da se uspostavi takav sustav upravljanja zahtjevima, koji e osigurati efikasnu
kontrolu i provoenje promjena, koje su, kako je ve ranije istaknuto, neizbjene. Koji su to,
onda, najei rizici koje treba poznavati (i pokuati izbjei ili minimizirati njihove uinke) a
vezani su za RE proces?
Jedan od najeih je nedovoljna i neadekvatna ukljuenost zainteresiranih strana . Bez
adekvatnog identificiranja i ukljuivanja stejkholdera nije mogue uspjeno definirati zahtjeve.

34
Nedovoljna ukljuenost, naroito kljunih, stejkholdera u konanici vodi razvoju neprihvatljivog
proizvoda, probijanju utvrenih rokova, estim promjenama, viestrukom poveanju trokova. i,
najee, odustajanju od daljnjeg razvoja, to predstavlja najgori scenarij i za naruitelja i za
izvoaa.
Drugi est rizik je neprecizno i nejasno definiranje vizije projekta, odnosno onoga to
sustav treba i mora pruati, a to ne treba. Greke u definiranju granica sustava vode lutanju,
gubljenju fokusa, bavljenju marginalnim aspektima problema i sl..
Nejasni, dvosmisleni i, ne rijetko, udni zahtjevi su takoer, na alost, esti pratioci RE
procesa. Korisnici nisu (uvijek) sposobni na pravi nain artikulirati i prezentirati ono to ele i
to oekuju od sustava. U procesu otkrivanja i definiranja zahtjeva treba pomoi korisnicima
da se doe do jasno i precizno definiranih zahtjeva.
(Ne)definiranje kljunih, prioritetnih zahtjeva neminovno vodi neuspjehu projekta,
produenju rokova i, u konanici, frustraciji i nezadovoljstvu korisnika.
Zanemarivanje potreba (zahtjeva) odreenih, naroito kljunih, korisnika (stejkholdera)
je neto to moe stvoriti opoziciju projektu, a to moe imati samo negativne posljedice.
(Ne)provjeravanje zahtjeva je takoer jedan od eih rizinih faktora. Sustavno
provjeravanje (inspekcija) zahtjeva, i to u to je mogue ranijoj fazi, je najefikasniji nain
identificiranja nejasnoa, nedovoljno utvrenih pretpostavki, konfliktnih zahtjeva i drugih
nedostataka,. Otkrivanje i otklanjanje (ako je to uope vie mogue) nedostataka kada je softver
ve instaliran u korisniko okruenje uzrokuje viestruko vee trokove.
Nedovoljno precizno i nepotpuno definiranje veza izmeu zahtjeva vodi neminovno
problemima u odravanju softvera. Promjene pojedinih zahtjeva se vrlo esto reflektiraju na
druge zahtjeve programskog proizvoda .
(Ne)definiranje vitalnih nefunkcionalnih zahtjeva takoer ima bitnu ulogu u realizaciji i
samom prihvaanju softverskog proizvoda .
(Ne)realno postavljeni rokovi takoer mogu biti veliki problem. Nerijetko se dogaa da
je naruitelj, obzirom na hitnost nekog posla, postavio uvjet da se projekt realizira za svega par
nedjelja. Naravno, prihvaanje takvih uvjeta, bez upoznavanja sa zadatkom i raspoloivim
resursima, vodi u probijanje nerealno postavljenog roka i/ili u realizaciju projekta, ijom
kvalitetom i mogunostima nije zadovoljan niti naruilac, niti sam izvoa.

35
 Komunikacijski problemi se javljaju kada se ne uspostavi zajedniki jezik izmeu
naruioca i izvoaa. Inenjeri esto ne razumiju u potpunosti strunu terminologiju
problemskog podruja, a korisnici, s druge strane, nemaju dostatno tehniko znanje da bi
razumjeli jezik sistemskih dizajnera i inenjera. Vrlo je bitno, dakle, da se uspostavi zajedniki
jezik koji e pomoi da se izbjegne komunikacijski jaz i mogui nesporazumi, a sve s ciljem to
jasnijeg i preciznijeg definiranja zahtjeva na sustav.
Ovdje su navedeni samo neki od rizika ili problema koji se mogu javiti u procesu
inenjerstva zahtjeva, a kojih trebaju biti svjesne, ili barem trebaju biti upoznate s njima, sve
zainteresirane strane od kojih ovisi (ne)uspjeh projekta razvoja softverskog proizvoda.
Otklanjanje ili minimiziranje ovih i mnogih drugih rizika koji se mogu javiti tokom ove poetne
faze procesa izgradnje softverskog sustava direktno utjee na uspjeh cjelokupnog projekta, jer se
u fazi inenjerstva zahtjeva postavljaju temelji razvoja softvera.

36
 5. ZAKLJUAK

Sve bri razvoj informacijskih tehnologija i sve ira primjena IT rjeenja nije, na alost,
utjecao u pozitivnom smislu na statistiku kojom se prikazuje uspjenost projekata razvoja
softverskih rjeenja.
Meu najslabijim, najkritinijim tokama razvojnog ciklusa i dalje vodee mjesto
zauzimaju propusti i greke koje se naprave u ranim fazama razvoja softverskog proizvoda.
Propusti u definiranju zahtjeva, koji su najee nepotpuni, kontradiktorni i dvosmisleni, uzrok
su problema u razvoju koji se oituju kroz probijanje planiranih rokova, viestruko poveanje
trokova i, ne rijetko, odustajanje (prekid) razvoja.
U tom smislu, inenjerstvo zahtjeva (RE), kao poetna faza softverskog inenjerstva, ima
poseban znaaj. RE aktivnosti imaju kljunu ulogu za rezultat cjelokupnog procesa razvoja, jer je
bez jasno definiranih zahtjeva nemogue razviti programski proizvod koji e zadovoljiti svojim
mogunostima i performansama sve zainteresirane strane. Ma kako dobro planirali i vodili
preostale aktivnosti programskog inenjerstva, ukoliko zahtjevi nisu dobro prikupljeni, projekat
se moe smatrati promaenim.
Krajnji cilj RE procesa je da usmjeri razvoj u smjeru koji e rezultirati dobrim,
kvalitetnim i prihvatljivim softverskim rjeenjem. Nemogue je dobiti dobar konaan proizvod
bez kvalitetno provedenih aktivnosti procesa inenjerstva zahtjeva, odnosno bez dobro
definiranih zahtjeva na sustav.
to znai dobro definiran zahtjev? Dobro definiran zahtjev je, u prvom redu, cjelovit, u
potpunosti definiran i bez nedostataka, konzistentan je i korektan, to znai da nije u konfliktu
ni sa jednim drugim zahtjevom i u potpunosti udovoljava zahtjevima korisnika. Dobro definiran
zahtjev je nedvosmislen, jasno iskazan i provjerljiv.
Ostvariti takve zahtjeve nije uvijek lako, naprotiv. Tokom svih aktivnosti RE procesa
javljaju se mnogi problemi, odnosno rizici, koje je potrebno, sustavnim i cjelovitim pristupom,
minimizirati, ukoliko ih ve nije mogue u potpunosti izbjei (a nije!). Da bi se to ostvarilo i da
bi se stvorila osnova za kvalitetno oblikovanje budueg sustava, potrebno se pridravati
smjernica inenjerstva zahtjeva te primjenjivati najadekvatnije metode i tehnike koje e poluiti
najbolje rezultate u konkretnom projektu.

37
 Krajnji rezultat RE procesa, Specifikacija softverskog zahtjeva (SRS), mora pruiti
dovoljno kvalitetnih informacija za naredne faze razvoja softverskog proizvoda, jer bez dobro
definiranih i opisanih zahtjeva nije mogue uspjeno privesti kraju tako kompleksan projekt kao
to je, u pravilu, projekt razvoja softverskog proizvoda.

38
LITERATURA

[1] Sommerville, I.: Software Engineering 8(Update), Addison Wesley, 2006.

[2] Bjrner, D.: Software Engineering 3 (Domains, Requirements, and Software Design),
Springer, 2006.
[3] Yeates, D., Wakeeld T.: Systems Analysis and Design, Prentice Hall, 2. Izdanje, 2004.
[4] Manger, R.: Softversko inenjerstvo (skripta), Sveuilite u Zagrebu, 2005.

[5] Kazmierczak E.: Requirements Engineering, Sveuilite u Melburnu, 2003.

[6] Kandt, R.K.: Software Requirements Engineering: Practices and Techniques, JPL Document
D-24994 SQI Report R-3, California Institute of Technology, 2003.
[7] IEEE: IEEE Std 830-1998 (Revision of IEEE Std 830-1993), IEEE Recommended Practice
for Software Requirements Specifications, 1998.

Internet izvori:

[8] http://www.usabilitynet.org/tools/storyboarding.htm, (1.2.2012.)

[9] http://www.ibm.com/developerworks/rational/library/dec05/krebs/, (1.2.2012.)

[10] http://hr.wikipedia.org/wiki/Etnografija , (1.2.2012.)

[11] http://hr.wikipedia.org/wiki/Programsko_in%C5%BEenjerstvo, (2.2.2012.)

[12] http://en.wikipedia.org/wiki/Software_Requirements_Specification, (2.2.2012.)

[13] http://www.ehow.com/how_4804549_software-requirements-specifications-srs-
document.html, (2.2.1012.)

[14] http://en.wikipedia.org/wiki/Non-functional_requirement, (3.2.2012.)

[15] http://www.pmhut.com/the-chaos-report-2009-on-it-project-failure, (4.2.2012)

[16] http://www.guerrillaprojectmanagement.com/the-chaos-report-myth-busters, (4.2.2012)

[17] http://www.microtoolsinc.com/Howsrs.php, (5.2.2012)

[18] http://en.wikipedia.org/wiki/Institute_of_Electrical_and_Electronics_Engineers, (5.2.2012)

[19] http://goldpractice.thedacs.com/practices/rto/index.php, (6.2.2012.)

[20] http://goldpractice.thedacs.com/practices/mr/index.php, (6.2.2012)

39
[21] http://en.wikipedia.org/wiki/Systems_engineering_process, (6.2.2012)

[22] http://en.wikipedia.org/wiki/Software_engineering, (6.2.2012)

[23] http://en.wikipedia.org/wiki/History_of_software_engineering, (6.2.2012)

[24] http://scarpedia.com/general/common-problems-during-requirement-engineering-practices/,
(6.2.2012)

[25] http://cnx.org/content/m14621/latest/, (6.2.2012)

40