ࡱ> =?:;<q`bjbjqPqP<::gXXXX D [[[[[ \(\\\\mmm?AAAAAA$he) qm"mqqeXX\\qX\ \?q?~78 v \\ xk[t>o\L0| lmnrn\Oommmeemmmqqqq D,: : XXXXXX Vrednovanje zahtjeva kao klju  unapreenja kvalitete informacijskog sustava Miro Fran i , Ivan Pogar i Poslovni odjel, Studij informatike, Veleu iliate u Rijeci, Trpimirova 2/V, 51000 Rijeka, Hrvatska {mfrancic, pogarcic }@veleri.hr Sa~etak. Sve br~i razvoj informati ke tehnologije nije zna ajnije promijenio statistiku kojom se prikazuju rezultati projekata razvoja informacijskih sustava, posebno softvera kao najkompleksnije komponente informacijskog sustava. Meu slabijim to kama razvojnog ciklusa i dalje su greake koje se javljaju u najranijim fazama razvoja. Nedostajui, nepotpuni, kontradiktorni, dvosmisleni zahtjevi koji nisu usklaeni sa standardima kvalitete naj eai su uzrok nekompletnog razvoja koji ima za posljedicu probleme u sistemskoj integraciji i visokim troakovima odr~avanja (system reengineering). In~enjerstvo zahtjeva kao disciplina softverskog in~enjerstva zahtijeva standardizaciju s ciljem poveanja kvalitete procesa razvoja softvera. Jedna od klju nih aktivnosti in~enjerstva zahtjeva koja rezultira poveanjem kvalitete razvijenog sustava svakako je vrednovanje zahtjeva. Rad prezentira pristup vrednovanju zahtjeva kroz prakti ne preporuke za provoenje ove aktivnosti. Cilj je prezentirati postupke koji mogu u praksi pomoi realizaciju kvalitetnog sustava kroz unapreenje kvalitete procesa razvoja. Klju ne rije i: softversko in~enjerstvo, in~enjerstvo zahtjeva, vrednovanje zahtjeva, preporuka, kvaliteta Requirements validation as a key for improving the quality of information system Miro Francic , Ivan Pogarcic Business Dept, Study of Information Systems, Polytechnic of Rijeka, Trpimirova 2/V, 51000 Rijeka, Croatia {mfrancic, pogarcic }@veleri.hr Abstract. Rapid development of information technology didn't change significantly the statistical results about information systems development projects, especially software as the most complex component of information system. Among weak points of development cycle are still errors done in the early phases. Missing, incomplete, inconsistent, ambiguous requirements which do not conform the quality standards, are the most often causes of incomplete development which results with the problems in system integration and high maintenance costs. Requirements engineering as a software engineering discipline needs to be standardized providing software process improvement. One of the key software engineering activities for better software product quality is requirement validation. This paper presents approach to the requirement validation through practical recommendation for its undertaking. The goal is to present procedure which can help practitioners to improve development process quality and thus develop quality system. Keywords: software engineering, requirements engineering, requirement validation, process improvement, recommendation, quality UVOD Vrednovanje u injenog prilikom obavljanja bilo koje aktivnosti u izradi nekog proizvoda jedan je od klju nih imbenika za postizanje odgovarajue kvalitete. Razvoj informacijskog sustava dugotrajan je proces koji predstavlja niz aktivnosti iji je redoslijed izvoenja zavisan o primijenjenom razvojnom modelu. Tradicionalni pristup grupira aktivnosti u faze koje se odvijaju po principu "vodopada" bez mogunosti povratka na prethodnu fazu. Implicitno, ovakav pristup podrazumijeva da je svaka faza zavraila s rezultatom ija je kvaliteta neupitna. Takav zaklju ak mogu je samo ako se vrai kontinuirano testiranje. Problem je u tome ato je testiranje izdvojeno kao posebna faza prije samog uvoenja gotovog rjeaenja. Ukoliko se u toj fazi utvrdi da proizvod ne odgovara zahtjevima, troakovi ispravaka su veliki, a u nekim slu ajevima zahtijevane promjene mogu biti takvog opsega da se donosi odluka o napuatanju projekta. Rjeaenje je rano otkrivanje greaaka. Istra~ivanja pokazuju da su naj eai uzrok neuspjeha projekata razvoja informacijskih sustava loae definirani zahtjevi. Ovaj rad bavi se problematikom pristupa vrednovanju zahtijeva u razvoju softverskog rjeaenja kao jedne od najkompleksnijih komponenti informacijskog sustava. Vrednovanje zahtijeva jedna je od faza in~enjerstva zahtijeva pa je radi lakaeg praenja u poglavlju 2 ukratko opisan proces identificiranja, dokumentiranja i upravljanja zahtjevima. IN}ENJERSTVO ZAHTJEVA Identificiranje, razumijevanje, usuglaaavanje, opisivanje, vrednovanje i upravljanje zahtjevima za sustav podr~an ra unalom aktivnosti su procesa in~enjerstva zahtjeva. Rije  "in~enjerstvo" ukazuje na sustavno koriatenje tehnika koje e rezultirati kvalitetnim zahtjevima. Otkrivanje ato korisnik o ekuje od budueg sustava zahtijevan je proces ali presudan za ispravno oblikovanje i izradu sustava koji e osigurati poslovni uspjeh. Zajedni ki problemi, neovisno o problemskoj domeni koji se pojavljuju u definiranju zahtijeva koje sustav mora zadovoljiti jesu [1]: zahtjevi ne odgovaraju stvarnim potrebama korisnika zahtjevi su nepotpuni i/ili nekonzistentni promjene ve implementiranih zahtijeva su skupe nesporazumi izmeu korisnika koji postavljaju zahtjeve i onih koji te zahtjeve implementiraju Najbolji na in da se ovi problemi prevladaju je poboljaati sam proces ime se osigurava kvaliteta izlaznog produkta. Rezultat in~enjerstva zahtjeva je dokument zahtjeva koji predstavlja formalni okvir za dogovor postignut izmeu klijenata, krajnjih korisnika, menad~era i onih koji sustav razvijaju. On sadr~i opis onoga ato sustav treba raditi (funkcionalni zahtjevi) i kako te funkcionalne zahtjeve implementirati (nefunkcionalni zahtjevi). Opisi mogu biti prirodnim jezikom, dijagramima, tablicama ato ovisi o izvoru zahtjeva (rukovoditelj, in~enjer, & ) i praksi same organizacije. Dokument zahtjeva treba biti oblikovan da bude jednostavan za itanje i mijenjanje. Velike organizacije definiraju svoje vlastite standarde, a IEEE/ANSI 830-1993 standard predla~e sljedeu strukturu dokumenta zahtjeva: Uvod Namjena dokumenta Opseg produkta Definicije, akronimi, skraenice Reference Pregled ostatka dokumenta Opi opis Perspektiva produkta Funkcije produkta Karakteristike korisnika Ograni enja Pretpostavke i zavisnosti Opis funkcionalnih i nefunkcionalnih zahtjeva i su elja (vanjska su elja, funkcionalnost, performanse, kvaliteta) Dodaci Indeks Navedeno predstavlja generi ku strukturu dokumenta i organizacije je trebaju prilagoditi prema specifi nim potrebama. Neovisno o strukturi, dokument zahtjeva treba sadr~avati: Kratki opis sustava i koristi od razvoja sustava Objaanjenje koriatenih tehni kih termina Opis funkcionalnih zahtjeva (servisi koje sustav pru~a) Opis nefunkcionalnih zahtjeva (osobine sustava poput sigurnosti, raspolo~ivosti, & ) Ograni enja u primjeni sustava i razvojnom procesu Opis radnog okru~enja i mogue promjene Detaljne specifikacije sustava koriatenjem modela koji prikazuju veze meu komponentama sustava Zahtjevi opisani u dokumentu zahtjeva nastaju kao rezultat sljedeih faza procesa in~enjerstva zahtjeva: Identifikacija zahtjeva Proces prepoznavanja zahtjeva na sustav kroz komunikaciju s klijentima, krajnjim korisnicima i svim zainteresiranim za sustav (eng. Stakeholders). Preduvjet za uspjeano izvraenje ovog procesa je dobro poznavanje domene poslovanja za koju se sustav razvija. Analiza i usuglaaavanje zahtjeva Proces za utvrivanje eventualnih konflikata, preklapanja, nekonzistentnosti i propuatenih zahtjeva. Temeljem rezultata analize potrebno je zahtjeve usuglasiti sa svim sudionicima i definirati prioritete. Opis zahtjeva Proces u kojem se opisuju pojedina ni zahtjevi na sa~et, razumljiv i nedvosmislen na in. Osim sadr~aja bitan je i na in na koji se zahtjevi opisuju. Modeliranje sustava Proces razvijanja apstraktnih modela sustava koji su dio detaljne specifikacije sustava. Uz modele na najviaem nivou (model arhitekture i okru~enja sustava) izrauju se i detaljni modeli kao dijagram toka podataka u slu aju kad se koriste metode strukturne analize sustava. Vrednovanje zahtjeva Proces formalne provjere zahtjeva radi utvrivanja propuatenih, nekonzistentnih i nejasnih zahtjeva ime se osigurava usklaenost sa standardima kvalitete. Upravljanje zahtjevima Ne zaboravljajui mudrost " Na tom svijetu samo mijena stalna jest." potrebno je definirati aktivnosti koje e osigurati kvalitetno praenje promjena u zahtjevima na sustav. OKVIR ZA UNAPREENJE PROCESA IN}ENJERSTVA ZAHTJEVA Za svaki od procesa navedenih u poglavlju 2 predla~u se preporuke za njihovo provoenje. Preporuke su grupirane u tri tipa. Tablica 3.1 opisuje tipove preporuka (preuzeto iz [1] str. 18). Kroz iterativni postupak primjene pojedinih preporuka unapreuje se proces in~enjerstva zahtjeva. Motivacija da se preporuke implementiraju u organizaciji je poveana kvalitete zahtjeva. Tablica 3.1: Klasifikacija preporuka Tip preporukeOpisTroakoviOsnovnaRelativno jednostavna i koristi se kao okvir za ponavljajui proces in~enjerstva zahtjeva kada je jednostavno utvrditi troakove, vrijeme i resurse.NiskiSrednjaSlo~enija preporuka ija primjena rezultira definiranim procesom in~enjerstva zahtjeva i primarni cilj je uvesti sustavan pristup i strukturne metode u procesViai od osnovne i vremenski zahtjevnijaNaprednaUklju uje naprednije metode i organizacijske promjene. Cilj je podr~ati kontinuirano poboljaanje procesa. Mo~e biti podr~ana alatima.Vrlo skupa, posebno u slu ajevima koriatenja alata. Organizacijskim promjenama mogue je smanjiti troakove uvoenja.  Podjela u Tablici 3.1 izvraena je s aspekta slo~enosti i troakova uvoenja preporuka u proces in~enjerstva zahtjeva. Prakti no, primjenom odreenog skupa preporuka definirana je razina zrelosti procesa. U odnosu na SEI Capability Maturity Model koji definira pet razina zrelosti, autori iz [1] definiraju tri razine od kojih su prve dvije usporedive sa SEI modelom, a trea obuhvaa preostale viae razine. Slika 3.1 prikazuje tri razine zrelosti procesa in~enjerstva zahtjeva prema Ian Somemerville i Pete Sawyer.  SHAPE \* MERGEFORMAT  Slika 3.1: Razine zrelosti procesa in~enjerstva zahtjeva VREDNOVANJE ZAHTJEVA "Trust is good, but control is better" (Povjerenje je dobro ali kontrola je bolja) jedna je od re enica koju je voditelj jednog zahtjevnog projekta razvoja informacijskog sustava esto ponavljao. Pri tom je mislio na va~nost testiranja tijekom cijelog projekta. Ako in~enjerstvo zahtjeva shvatimo kao podprojekt cjelovitog projekta razvoja informacijskog sustava onda je vrednovanje zahtjeva nu~no kao garancija kvalitetno definiranih zahtjeva. Cilj vrednovanja zahtjeva je provjeriti definirane zahtjeve radi otklanjanja eventualnih problema prilikom njihove implementacije u sustav. Rezultat je verificiran i potvren dokument zahtjeva. U procesu vrednovanja zahtjeva treba ju biti uklju eni svi koji e sustav koristiti (klijenti, krajnji korisnici, rukovoditelji,& ) kao i oni koji sustav razvijaju (analiti ari, dizajneri, programeri, administratori baze podataka, & ). Problemi sa zahtjevima koje proces vrednovanja zahtjeva treba identificirati jesu: Neusklaenost sa standardima kvalitete Nejasno opisani zahtjevi koji se mogu razli ito shvatiti Nekonzistentnost zahtjeva koja nije otklonjena tijekom analize U otklanjanju navedenih problema zapravo se ponavljaju prethodne faze (identifikacija, analiza i usuglaaavanje zahtjeva) no s odreenom razlikom u pristupu. Prethodne faze naj eae rezultiraju nekompletnim i nestandardno opisanim zahtjevima i zadatak je vrednovanja zahtjeva izvraiti korekcije zavranog dokumenta zahtjeva. To je posljednja aansa da se otklone greake i problemi prije po etka razvoja sustava kako bi se izbjegli mnogostruko vei troakovi ispravaka gotovog rjeaenja. Preporuke za provoenje procesa vrednovanja zahtjeva prema Sommervillu i Sawyeru jesu: Provjeriti usklaenosti dokumenta zahtjeva s definiranim standardima Prvi korak prije revizije sadr~aja dokumenta zahtjeva koji ima za cilj olakaati proces detaljne revizije zahtjeva. Relativno kratkotrajan postupak kojim se utvruje usklaenost strukture dokumenta i opisa zahtjeva s definiranim standardima. Utvrene neusklaenosti mogu biti indikator ozbiljnih problema u specifikaciji zahtjeva za ije je rjeaavanje nu~na intervencija menad~menta. Postupak treba provesti osoba koja nije u estvovala u definiranju zahtjeva ali dobro poznaje standarde u definiranju zahtjeva. Ovi standardi utvruju se u fazi opisa zahtjeva. Osoba koja provodi ovaj postupak treba utvrditi nedostajue ili nekompletne odlomke dokumenta zahtjeva za ato mu mogu poslu~iti i odreeni tekst procesori. Takoer je potrebno za svaki zahtjev provjeriti da li je opisan u skladu s definiranim standardima. Provjeravaju se i formalne stvari poput numeriranja stranica, ozna avanja slika, dijagrama i tablica. U slu aju otkrivanja odstupanja od standarda dokument se vraa na doradu timu za in~enjerstvo zahtjeva ili daje na daljnju detaljnu reviziju. Prvi izbor primjenjiv je u slu aju kad ima dovoljno vremena za izradu nove verzije dokumenta ili su odstupanja takva da ih nije mogue otkloniti manjim intervencijama. Za drugu varijantu odlu ujemo se u slu aju manjih odstupanja koja ne utje u na razumljivost dokumenta i lako ih je ispraviti tijekom detaljne revizije zahtjeva ili postoji vremensko ograni enje za reviziju dokumenta. Organizirati formalnu provjeru zahtjeva Preporuka je organizirati grupu ljudi koja e na zajedni kim sastancima izvraiti sistematsku provjeru zahtjeva i usuglasiti stavove oko na ina otklanjanja identificiranih problema. Eventualne konflikte u zahtjevima potrebno je razrijeaiti izbjegavajui sukobe meu inicijatorima zahtjeva. Meta-plan tehnika jedna je od mogunosti da se uz moderatora koji treba biti osoba koja nije u estvovala u definiranju zahtjeva postigne cilj. In~enjer zahtjeva prezentira pojedina no zahtjeve, a ostali sudionici komentiraju. Identificirani problemi se zapisuju. Kasnije se o njima raspravlja i predla~u akcije za poboljaanja. Problemati ni zahtjevi se klasificiraju u etiri grupe: nejasni, nepotpuni, konfliktni i nerealni. Nejasne zahtjeve autor opisa treba ponovo opisati.    ( * 0 2 6 8 : < H L ` f h x     ҿǴҭҭҭҦҦҦҦҘho=hmHsHho=h5\mHsH hAh hGUhh.hmHsHhmHsHh hi'yhhi'yhmHsHhOJQJ^JnH tH (h5CJOJQJ\^JaJnH tH 7l  $%Cuv $dha$gd x`gd`gd  4]4gdgdgd$3]3^a$gd`4`v#$tuvwxz|Ĩxmi]Q]F9hp5mH nHsH tHh%shpmH sH hpjimH nHsH tHhpmH nHsH tHhho=hmH sH ho=h5\ho=h5\ ho=h(ho=hOJQJ^JmH nH sH tH 6ho=h5CJOJQJ\^JaJmH nH sH tH (h5CJOJQJ\^JaJnH tH ho=hmHsHho=h "5\mHsHho=h5\mHsHvwxyz{|%%J%N%))&*|**++00$a$gdY $ & Fa$gd<$a$gd^X $ a$gd^X$a$gd-gdgd%sgdp $dha$gdHd0Jp!#*$%%%H%J%N%P%j%l%%%%%%%%%%%&&Ⱥ䞐}ugYgYgYgYgYgYgYgh<CJOJQJ^JaJh, XCJOJQJ^JaJh^XnHtHh4Ch^XmHsHhF%mHsHhF%CJOJQJ^JaJhazCJOJQJ^JaJhLn&CJOJQJ^JaJhme#CJOJQJ^JaJhCJOJQJ^JaJhAU5CJOJQJ^JaJhpjiCJOJQJ^JaJhCJOJQJ^JaJ&p')))++,,,,--//.00000111112334ֺ򐂬tftfXJfJfJhNVCJOJQJ^JaJhWCJOJQJ^JaJh,MSCJOJQJ^JaJh8CCJOJQJ^JaJhmaCJOJQJ^JaJh(qCJOJQJ^JaJh[CJOJQJ^JaJhCJOJQJ^JaJh, XCJOJQJ^JaJhpjiCJOJQJ^JaJh<CJOJQJ^JaJhF%CJOJQJ^JaJh;RCJOJQJ^JaJ011112:2|2222223*3\3t333444 $ & Fa$gdNV $ & F a$gd,MS$a$gd,MS $ & F a$gdNV$a$gdNV $ & F a$gd,MS$a$gd^X444466v66877F88X9Z9,:.:`:b:d<f<<<D> $h^ha$gdA $ & Fa$gdA $h^ha$gds+ $ & Fa$gds+ $ & Fa$gdY $a$gdNV4566X99(::b<d<<<<B>D>F>??n@AADD4DHDPDRDDDDDDDDDDEEEEEEֺֺ򬞬}}ujujuj}h0h0mHsHh0mHsHh0homHsHhomHsHhKCJOJQJ^JaJhiCJOJQJ^JaJh,CJOJQJ^JaJhACJOJQJ^JaJhI|TCJOJQJ^JaJhs+CJOJQJ^JaJhY CJOJQJ^JaJh.?CJOJQJ^JaJ)D>F>b>d>????AA B BDCFCHCvCxCDD@EBE4H$a$gdgd%s $h^ha$gdi $ & Fa$gdi $h^ha$gd, $ & Fa$gd,$a$gdNVE*E,E.E>E@EBErEEEEFpFFFFFG$GGG2H6HlH|H~HHHHHĶĶzhVzhVz"h UCJOJQJ^JaJnHtH"hqCJOJQJ^JaJnHtH"h#CJOJQJ^JaJnHtHh#CJOJQJ^JaJh UCJOJQJ^JaJhqCJOJQJ^JaJhj}CJOJQJ^JaJhoCJOJQJ^JaJhnHtHhNVhmHsHh0homHsHh0mHsHhomHsH4H6HHHHHH $$Ifa$gd0 $$Ifa$gd0$a$gd#$L^`La$gd#$a$gdHHHIJocWK $$Ifa$gd0 $$Ifa$gd# $$Ifa$gd0kd$$IflgF4X  $  t06    44 laHHHHIIJJ"J$J&J8J:JTJPKZKlKnKKKKKLLLLMMMMHNXNZNNNNNNOOO"OOOOOOܼvvhCJOJQJ^JaJh`CJOJQJ^JaJh UCJOJQJ^JaJhqCJOJQJ^JaJh0CJOJQJ^JaJhnCJOJQJ^JaJ"h2]CJOJQJ^JaJnHtH"h#CJOJQJ^JaJnHtH"hqCJOJQJ^JaJnHtH.JJJPKKocWK $$Ifa$gd0 $$Ifa$gd# $$Ifa$gd0kd$$IflF4X  $ t06    44 laKKKLMocWK $$Ifa$gd0 $$Ifa$gd# $$Ifa$gd0kd($$Ifl}F4X  $ t06    44 laMMMMQQQQQQQQogggggggggg$a$gdkd$$IflF4X  $ t06    44 la OOP,PJPLPRPZPlPnPPPPPPQQQQQQQQQQQQQRR"R6RFRpRrRֶvhvh UCJOJQJ^JaJ h%shnCJOJQJ^JaJ)jBhhCJOJQJU^JaJ2jhCJOJQJU^JaJmHnHtHu#jhCJOJQJU^JaJhCJOJQJ^JaJhCJOJQJ^JaJh0CJOJQJ^JaJh`CJOJQJ^JaJ"QRrRtRvRxRzRRRZ ZnZZ`[b[*_,___f`h`$a$gd3 $ & F a$gd[ $ & F!a$gd$$a$gdWgdT$a$gd%s$a$gdn$a$gdrRtRvRxRzRRRRS V8WWJXZZ`[b[\(_*_,_<__ƹsssseWI;h UCJOJQJ^JaJhqCJOJQJ^JaJhp3CJOJQJ^JaJh1,CJOJQJ^JaJh$CJOJQJ^JaJhH)VCJOJQJ^JaJh[CJOJQJ^JaJh|CJOJQJ^JaJhWCJOJQJ^JaJhXhWaJmHsHh|"h)CJOJQJ^JaJnHtH"hXCJOJQJ^JaJnHtH"hnCJOJQJ^JaJnHtH__________f``Laabfcdd0hvjkkkkkkkkkklllnpȺȺȬtttfXheeCJOJQJ^JaJhIJCJOJQJ^JaJhH)VCJOJQJ^JaJhzHCJOJQJ^JaJhvfuCJOJQJ^JaJhOLtCJOJQJ^JaJhI|TCJOJQJ^JaJhA:CJOJQJ^JaJh3CJOJQJ^JaJh`WzCJOJQJ^JaJh UCJOJQJ^JaJh[CJOJQJ^JaJ"h`kkll8:°N $ & F$a$gd0g$a$gd0g $h^ha$gd0g$a$gd1 $h^ha$gd5$a$gd5 $h^ha$gdA:$a$gd3 $ & F a$gd[ $h^ha$gd3 Nepotpune zahtjeve potrebno je revidirati s izvorom zahtjeva. Konfliktne zahtjeve potrebno je raspraviti s njihovim izvorima i usuglasiti potrebne izmjene. Nerealni zahtjevi zna e da postoje odreena ograni enja na njihovu implementaciju (npr. raspolo~iva tehnologija). Potrebno je konzultirati sve zainteresirane radi odluke da se zahtjev ne implementira ili da ga se modificira. Za uspjeano provoenje formalne provjere nu~no je imati ljude s iskustvom pa je u nedostatku takvih ljudi potrebno izvraiti edukaciju, a ponekad i kroz pilot projekt provesti analizu troakovi/koristi i provjeriti da li je ovaj pristup za naau organizaciju najbolji. Koristiti multidisciplinarne timove za reviziju zahtjeva Ova preporuka zapravo je na elo projektnog pristupa rjeaavanja zadataka. Jedino uklju ivanjem ljudi s razli itim poslovnim i tehni kim znanjima mogue je kvalitetno revidirati zahtjeve. Ono ato ovdje treba naglasiti, a u tradicionalnom pristupu razvoja informacijskih sustava nije uva~avano je uklju ivanje klijenata. Njihovo vienje kako sustav treba izgledati da bi ispunio i njihove zahtjeve posebno je zna ajan u razvoju WEB baziranih sustava gdje su i klijenti direktni korisnici sustava. Radi efikasnosti, u timove treba uklju iti tkzv. klju ne korisnike koji prezentiraju stavove itave grupe. Definirati kontrolne liste za vrednovanje zahtjeva Kontrolne liste definiraju na ato je potrebno obratiti pozornost prilikom itanja dokumenta zahtjeva. Na taj na in otklanjanja se mogunost lutanja i skrauje vrijeme samog procesa. Smanjuje se vjerojatnost da se zaboravi provjeriti neki aspekt dokumenta zahtjeva, a posebnu korist imaju za ljude koji nemaju iskustva u procesu vrednovanja zahtjeva. Sli ne liste definiraju se i u analizi zahtjeva ali su one fokusirane na pojedina ne zahtjeve. Pitanja koja sadr~e ove kontrolne liste odnose se na cjeloviti dokument zahtjeva i veze meu pojedina nim zahtjevima. Kontrolne liste trebaju slu~iti kao podsjetnik osobi koja provjerava dokument zahtjeva da provjeri sljedee: Zna li za neki zahtjev koji nije opisan ili zna li neku informaciju koja nedostaje u opisu pojedinog zahtjeva Postoje li kontradikcije meu zahtjevima Da li su zahtjevi razumljivi Postoji li mogunost razli ite interpretacije zahtjeva Da li su zahtjevi grupirani prema srodnosti Da li je mogue jednostavno pratiti zahtjeve tj. da li su zahtjevi nedvosmisleno ozna eni , da li su ozna ene veze prema srodnim zahtjevima i razlozima radi kojih su zahtjevi uklju eni Da li pojedina ni zahtjevi i cijeli dokument odgovaraju standardima Koristiti prototip za demonstraciju zahtjeva Preporuka je izraditi prototip budueg sustava radi eksperimentiranja sa zahtjevima. Ovaj prototip mo~e biti nadogradnja prototipa razvijenog u fazi identifikacije zahtjeva. Budui je ljudima teako predo iti kako e opisani zahtjevi biti realizirani, prototip olakaava provjeru da li zahtjevi zaista zadovoljavaju stvarne potrebe. Prototip ne mora nu~no uklju iti sve zahtjeve. Mogue je ograni iti se samo na slabo razumljive i kroz eksperimentiranje s prototipom poboljaati ih, ali svakako treba obuhvatiti dovoljno funkcionalnosti da korisnik mo~e osjetiti prakti ne koristi budueg sustava. Prototip je dobra osnova za definiranje testnih slu ajeva ali isto tako mo~e poslu~iti kao privremeno rjeaenje u slu aju kaanjenja kona nog sustava. Sama izrada prototipa zahtijeva pomno izu avanje zahtjeva pa i to mo~e pridonijeti otkrivanju nekonzistentnosti i nekompletnosti zahtjeva. Eksperimentiranje s prototipom treba prepustiti korisniku ali ne dozvoliti nestrukturirano eksperimentiranje. Predla~e se izrada scenarija i uklju ivanje korisnika iz razli itih poslovnih podru ja radi pokrivanja razli itih funkcionalnosti sustava. Da bi korisnik stekao povjerenje u sustav prototip treba biti pouzdan. Napisati radnu verziju korisni kog priru nika Pisanje korisni kog priru nika u fazi provjere zahtjeva poma~e u otkrivanju eventualnih problema u koriatenju sustava. Korisni ki priru nik piae se na temelju dokumenta zahtjeva pa je i to prilika za provjeru zahtjeva jer je nu~na detaljna analiza zahtjeva. Uz to, korisni ki priru nik mo~e razjasniti pitanja vezana uz oblikovanje korisni kog su elja. Korisni ki priru nik nu~an je i za eksperimentiranje s prototipom. Sadr~aj korisni kog priru nika ne ine zahtjevi vezani uz implementaciju sustava iako se to ponekad pretpostavlja. Naprotiv, korisni ki priru nik treba isklju ivo sadr~avati opis interakcije korisnika i sustava, a ne druge funkcionalnosti i osobine sustava. Funkcionalnosti sustava opisane u dokumentu zahtjeva potrebno je opisati s aspekta na ina koriatenja jezikom razumljivom korisniku. Poteakoe u opisu funkcionalnosti sustava krajnjem korisniku mogu ukazivati na problem sa zahtjevima. Predlo~iti testne slu ajeve za provjeru zahtjeva Primjenom ove preporuke osigurava se najefikasniji na in otkrivanja nepotpunosti i dvosmislenosti zahtjeva. Eventualne poteakoe s definiranjem testnih slu ajeva za neki zahtjev posredno ukazuju da zahtjev treba revidirati. Predlo~eni testni slu ajevi mogu poslu~iti kao osnova za testiranje zavraenog sustava ali im nije cilj testiranje sustava ve vrednovanje zahtjeva. U definiranju testnih slu ajeva potrebno je utvrditi: Okru~enje u kojem e se primijeniti testni slu aj (scenarij provjere zahtjeva) Da li je mogue test definirati samo na temelju opisa jednog zahtjeva ili su potrebni neki drugi zahtjevi ( ukazuje na povezanost meu zahtjevima) Da li je za provjeru zahtjeva potrebno viae testnih slu ajeva (ako jest to ukazuje da je u opisu zahtjeva uklju eno viae zahtjeva) Kako promjena zahtjeva utje e na testne slu ajeve Radi u inkovitije primjene ove preporuke treba oblikovati dokument koji se ispunjava prilikom provjere svakog zahtjeva. Uz poativanje standarda koji se u organizaciji primjenjuje, dokument treba minimalno sadr~avati: Identifikaciju zahtjeva Povezane zahtjeve Kratki opis primijenjenog testnog slu aja Opis problema u zahtjevima koji su uzrokovali poteakoe u definiranju testnog slu aja Preporuke za otklanjanje otkrivenih problema Opisati modele sustava Nakon ato su izraeni modeli sustava u grafi koj ili formalnoj notaciji, prije samog razvoja sustava dobar na in za joa jednu provjeru zahtjeva je opisati modele prirodnim jezikom. Otkrivene greake, nekonzistentnosti i nekompletnosti modela ukazuju i na potencijalno loae specificirane zahtjeve. Korisnici bolje razumiju opise prirodnim jezikom i lakae analiziraju detaljne specifikacije. Postupak opisivanja modela prirodnim jezikom potrebno je sistematizirati na na in da se pojedine komponente modela opiau i ti opisi koriste prilikom transformacije. Na taj na in mogue je djelomi no automatizirati proces prevoenja na prirodni jezik. U cilju realnog otkrivanja problemati nih zahtjeva treba izbjegavati interpretaciju modela i pojaanjenja onoga tko model opisuje. Model treba opisivati osoba koja poznaje sustav ali nije sudjelovala u specifikaciji zahtjeva. Zbog visokih troakova primjene, ponavljanje ve u injenog (izrada ve postojeeg modela ali na drugi na in) i eventualnih poteakoa u pronala~enju kompetentnih osoba za izvraenje ovog posla ova preporuka mo~e imati opravdanje kod razvoja kriti nih sustava. U tablici 4.1 svaka od navedenih preporuka prikazana je kroz pripadnost tipu prema opem predloaku, koristima, troakovima i potencijalnim problemima primjene. Tablica 4.1: Prikaz koristi, troakova i problema primjene preporuka PreporukaTipCilj / KoristiTroakoviProblemi Provjeriti usklaenost dokumenta zahtjeva s definiranim standardima OsnovnaBrzo otkrivanje neusklaenosti sa standardima. Skrauje vrijeme detaljne revizije.Niski (eventualna potreba za prou avanjem standarda)U manjim organizacijama pronai nezavisnu osobu za provjeruOrganizirati formalnu provjeru zahtjeva OsnovnaOtkriti ato viae problemati nih zahtjeva. Ukloniti nekonzistentnosti. Smanjenje naknadnih ispravaka. Srednji (troakovi obuke za tehnike provjere, konzultanata i pilot projekta)Klasifikacija problema. Utvrivanje vremena za provoenje. Koordinacija multidisciplinarnog tima. Koristiti multidisciplinarne timove za reviziju zahtjeva OsnovnaPoveana vjerojatnost pronala~enja problema u zahtjevima. Zadobivanje povjerenja korisnika sustava i njihovo lakae uklju ivanje u provoenje nu~nih promjena prilikom implementacije novog sustava.Nema dodatnih troakova osim ako se uklju uju vanjski konzultanti.Osigurati raspolo~ivost ljudi obzirom na njihovu zauzetost redovitim poslovnim aktivnostima.Definirati kontrolne liste za vrednovanje zahtjeva OsnovnaPomo u fokusiranju na klju ne aktivnosti u procesu vrednovanja zahtjeva. Podsjetnik "Ne zaboravi!".Niski-srednjiPreviae pitanja. Nejasna pitanja. Preopenita ili detaljna pitanja.Koristiti prototip za demonstraciju zahtjevaSrednja Prikaz realizacije zahtjeva. Prihvatljiviji na in vrednovanja zahtjeva.Srednji-Visoki (troakovi izrade prototipa) Pronai kompetentne korisnike za eksperimentiranje s prototipomNapisati radnu verziju korisni kog priru nika SrednjaOtkrivanje problema u koriatenju sustava. Osnova za kona nu verziju korisni ke dokumentacije.Srednji (stvarni troakovi pisanja priru nika)Vrijeme i ljudi potrebni za pisanje priru nika. Vremenski i ljudski zahtjevno. Predlo~iti testne slu ajeve za provjeru zahtjeva SrednjaOtkriti dvosmislenosti i nekonzistentnosti u zahtjevima. Smanjenje troakova planiranja testiranja sustava.Srednji (dodatni troakovi ljudi)Mogui otpor zbog uvjerenja da je to tui posao (testera sustava). Vrednovanje zahtjeva traje du~e.Opisati modele sustava NaprednaOmoguiti airem krugu ljudi u estvovanje u procesu vrednovanja zahtjevaSrednji-visokiVisoki troakovi. Nedostatak vremena za opisivanje sustava na drugi na in. Osiguranje kompetentnih osoba za taj posao.  ZAKLJU AK Rane faze razvoja informacijskog sustava, bez obzira na njihovu va~nost u isporuci kvalitetnog proizvoda, oduvijek su podlo~ne tendenciji skraivanja jer ne daju opipljive rezultate. `to prije zapo eti izradu sustava ~elja je svih sudionika. Ukoliko se i popusti pred takvim pristupima, proces vrednovanja zahtjeva je onaj koji je najkriti niji za uspjeh projekta i na njemu ne bi trebalo atedjeti vrijeme ni novac. Ukoliko se za taj proces ne utroai dovoljno vremena i novca gotovo je sigurno da emo se suo iti s posljedicama loae postavljenih zahtjeva. Tijekom samog razvoja sustava ali kasnije i njegovog koriatenja utroait emo viaestruko vremena i novaca za ispravak programskih greaaka koje su posljedica nepotpunih i nedostajuih zahtjeva. Ono ato je potrebno posebno istaknuti je uklju ivanje klijenata u proces in~enjerstva zahtjeva ato u praksi nije uobi ajeno. Na taj na in preko informacijskog sustava poboljaavamo sveukupni odnos s klijentom. Preporuke za poveanje kvalitete procesa vrednovanja zahtjeva opisane u ovom radu mogue je uvoditi postupno ovisno o kadrovskoj i financijskoj spremnosti poslovnog subjekta. Svaka organizacija treba odlu iti primjenom koje preporuke e postii najbolji omjer troakova i koristi ali je sigurno da e svaka primijenjena preporuka rezultirati kvalitetnijom specifikacijom zahtjeva. Literatura: Sommerville I., Sawyer P.: Requirements engineering, John Willey & Sons Ltd., 1997. Podaci o autorima: Miro Fran i, dipl. in~. Veleu iliate u Rijeci Miro Fran i radi kao predava  na Veleu iliatu u Rijeci. Podru je interesa je strateako planiranje i razvoj informacijskih sustava, modeliranje procesa i podataka, upravljanje informacijskom funkcijom poduzea i upravljanje kvalitetom informacijskim sustava. Radio je na projektima implementacije informacijskih sustava u razli itim poslovnim sustavima (turizam, komunalna djelatnost i banke) kao konzultant ili kao voditelj informatike. e-mail:  HYPERLINK "mailto:mfrancic@veleri.hr" mfrancic@veleri.hr mr.sc. Ivan Pogar i Veleu iliate u Rijeci Ivan Pogar i je predava  na Veleu iliatu u Rijeci posljednje tri godine. Profesor je matematike i fizike i magistar informacijskih znanosti. Podru je interesa je e-learning, objektno orijentirane tehnologije i razvoj informacijskih sustava. Ima dugogodianje iskustvo u razvoju poslovnih aplikacija, posebno u podru ju poatanskog prometa i telekomunikacija. e-mail: pogarcic@veleri.hr Razina 3  Definirana Eksplicitno definiran proces in~enjerstva zahtjeva kao rezultat najbolje prakse. Implementiran proces unapreenja. Razina 1  Po etna Ad-hoc in~enjerstvo zahtjeva: zajedni ki problemi u definiranju zahtjeva Razina 2  Ponavljajua Definirani standardi za dokument zahtjeva i aktivnosti procesa. Manje problema sa zahtjevima, posebno za dobro poznate sustave. prʧ68:JNPn6jƸrdVrdrdrdh1CJOJQJ^JaJhNXCJOJQJ^JaJhACJOJQJ^JaJhCCJOJQJ^JaJhqCJOJQJ^JaJh5CJOJQJ^JaJhH)VCJOJQJ^JaJh UCJOJQJ^JaJh3CJOJQJ^JaJhA:CJOJQJ^JaJh "CJOJQJ^JaJUhn-CJOJQJ^JaJf6>jln4^ʵĶ*RҽԽؽ46$ȺֺtttfXhM9CJOJQJ^JaJh2jCJOJQJ^JaJhH)VCJOJQJ^JaJhApCJOJQJ^JaJh 3CJOJQJ^JaJh% CJOJQJ^JaJh UCJOJQJ^JaJhJCJOJQJ^JaJhNXCJOJQJ^JaJhiSqCJOJQJ^JaJh0gCJOJQJ^JaJh6CJOJQJ^JaJ!NlnԽֽؽ46XZ\ $h^ha$gdk;$a$gdk; $h^ha$gd3$a$gd2j $h^ha$gdJ$a$gdJ $ & F a$gd[ $h^ha$gd1 $ & F$a$gd0g$VX\~RT8ȺȺ֬ttffXȺȺhUCJOJQJ^JaJhzCJOJQJ^JaJh*%CJOJQJ^JaJh CJOJQJ^JaJhCJOJQJ^JaJh~CJOJQJ^JaJhk;CJOJQJ^JaJhH)VCJOJQJ^JaJhApCJOJQJ^JaJh2jCJOJQJ^JaJhZLCJOJQJ^JaJh3CJOJQJ^JaJ!RT8\^ $ & F a$gd[ $ & F&a$gdz$a$gdz$a$gd2j $ & F&a$gd$a$gd: 44ȺttttfTB"hg,CJOJQJ^JaJnHtH"hXCJOJQJ^JaJnHtHhXCJOJQJ^JaJh6CJOJQJ^JaJhqCJOJQJ^JaJhApCJOJQJ^JaJhp3CJOJQJ^JaJh);CJOJQJ^JaJh2jCJOJQJ^JaJhwCJOJQJ^JaJh[eCJOJQJ^JaJhqCJOJQJ^JaJh4CJOJQJ^JaJ $$Ifa$gdf=$a$gd $a$gdX$a$gdW 46JbtvxdftDFH ʸrdVHdHHVhIJCJOJQJ^JaJheeCJOJQJ^JaJh5CJOJQJ^JaJhk;CJOJQJ^JaJhf=CJOJQJ^JaJhqCJOJQJ^JaJh{CJOJQJ^JaJhXCJOJQJ^JaJ"hf=CJOJQJ^JaJnHtH"hqCJOJQJ^JaJnHtH"hg,CJOJQJ^JaJnHtH"heeCJOJQJ^JaJnHtHvx0KBB999 $Ifgdf= $IfgdI|Tkd$$Ifl`r \ # E$ T t0H$44 ladfA55 $$Ifa$gdI|Tkdz$$Iflr \ # E$ T t0H$44 la $$Ifa$gdg,fvH;kd$$Iflr \ # E$ T t0H$44 la $Ifgdk $Ifgdee ,.8:*Z\^ln68RT 68HJ02 "r䶨Ҷ䨌~~~~~~p~h;vCJOJQJ^JaJh2jCJOJQJ^JaJh6CJOJQJ^JaJhJCJOJQJ^JaJhNXCJOJQJ^JaJhACJOJQJ^JaJhCCJOJQJ^JaJ"hf=CJOJQJ^JaJnHtHhf=CJOJQJ^JaJh "CJOJQJ^JaJ*.: $Ifgdk $IfgdC $$Ifa$gdI|T\^n8MAA8/ $Ifgdk $Ifgd6 $$Ifa$gdI|Tkd$$Iflr \ # E$ T t0H$44 la8T8JD8/ $Ifgd2j $$Ifa$gdI|Tkdf$$Iflr \ # E$ T t0H$44 la $IfgdkJ2D88 $$Ifa$gdI|Tkd $$Iflr \ # E$ T t0H$44 la $Ifgdk"<;kd$$Iflr \ # E$ T t0H$44 la $Ifgdk $Ifgd2j:<BPR&(hj2fvx$& ".0䚌~pb^Sh@hWLmHsHhWLh^)CJOJQJ^JaJhnCJOJQJ^JaJhCJOJQJ^JaJhf["CJOJQJ^JaJ"h!CJOJQJ^JaJnHtHhwCJOJQJ^JaJh[eCJOJQJ^JaJh@CJOJQJ^JaJhUCJOJQJ^JaJhf=CJOJQJ^JaJhk;CJOJQJ^JaJ @BR(j4 $Ifgdk $IfgdU $Ifgdk;46dfxMDD;2 $Ifgdk $Ifgd[e $Ifgdk;kdR$$Iflr \ # E$ T t0H$44 la&B2$L^`La$gd!kd$$Iflr \ # E$ T t0H$44 la $Ifgdk "68npnpgd4C$a$gdA & Fgd%s$a$gdE$a$gd[~gd%s$a$gd$a$gd 0468bt0lnpǹչǫ㏊n\GB hA5(h%shGOJQJ^JmHnH sHtH "h;OJQJ^JmHnH sHtH "h@OJQJ^JmHnH sHtH  hG5 h[~5 h%s5hGCJOJQJ^JaJh;CJOJQJ^JaJh.CJOJQJ^JaJh@CJOJQJ^JaJh[zCJOJQJ^JaJh; CJOJQJ^JaJh[~CJOJQJ^JaJh@hWLmHsHhWLlnp&mZL:#hh+:5CJOJQJ^JaJhVCJOJQJ^JaJ$hhkh+:0JCJOJQJ^JaJ/jhhkh+:CJOJQJU^JaJh+:CJOJQJ^JaJ#jh+:CJOJQJU^JaJh4CCJOJQJ^JaJhACJOJQJ^JaJhCJOJQJ^JaJhA5CJOJQJ^JaJ#hAhA5CJOJQJ^JaJ hA5 h1,5 h%s5(*VX&(^`bdfhjlnprtvxz|~$a$gd$a$gd+:gd4C&*TX`blnpvz|v$&(\^`~Ѽѝѫљxih5CJOJQJ^JaJ#hh5CJOJQJ^JaJh`5CJOJQJ^JaJh+:hCJOJQJ^JaJ h6#h+:CJOJQJ^JaJ(h6#h+:CJOJQJ^JaJmH sH h+:CJOJQJ^JaJ hh+:CJOJQJ^JaJh+:5CJOJQJ^JaJ)HJLz||Ϛwh+:CJOJQJ^JaJhh hhCJOJQJ^JaJ#hh5CJOJQJ^JaJh+: hhCJOJQJ^JaJhCJOJQJ^JaJh`5CJOJQJ^JaJh5CJOJQJ^JaJ#hh5CJOJQJ^JaJJL||~gd4C$a$gd21h:p. A!"#$% 5 01h:p. A!"#$% 5 01h:p. A!"#$% 5 01h:p. A!"#$% $$If!vh5 55$ #v #v#v$ :Vlg t6,5 55$ /  / $$If!vh5 55$ #v #v#v$ :Vl t6,5 55$ / $$If!vh5 55$ #v #v#v$ :Vl} t6,5 55$ / $$If!vh5 55$ #v #v#v$ :Vl t6,5 55$ /  Dd D  3 @@"?$$If!vh5 5E5$ 5T5#v #vE#v$ #vT#v:Vl` tH$,5 5E5$ 5T5$$If!vh5 5E5$ 5T5#v #vE#v$ #vT#v:Vl tH$,5 5E5$ 5T5$$If!vh5 5E5$ 5T5#v #vE#v$ #vT#v:Vl tH$,5 5E5$ 5T5$$If!vh5 5E5$ 5T5#v #vE#v$ #vT#v:Vl tH$,5 5E5$ 5T5$$If!vh5 5E5$ 5T5#v #vE#v$ #vT#v:Vl tH$,5 5E5$ 5T5$$If!vh5 5E5$ 5T5#v #vE#v$ #vT#v:Vl tH$,5 5E5$ 5T5$$If!vh5 5E5$ 5T5#v #vE#v$ #vT#v:Vl tH$,5 5E5$ 5T5$$If!vh5 5E5$ 5T5#v #vE#v$ #vT#v:Vl tH$,5 5E5$ 5T5$$If!vh5 5E5$ 5T5#v #vE#v$ #vT#v:Vl tH$,5 5E5$ 5T5DyK mfrancic@veleri.hryK Lmailto:mfrancic@veleri.hryX;H,]ą'c@`@ pNormalCJ_HaJmHsHtH p@p TNaslov 1$ & F <@&&5KH OJQJ\^JaJ mHsHtHf`f *%Naslov 2 $ @&^`5OJQJaJmH sH tHf`f *%Naslov 3 $ 880@&^8`0>*OJQJaJmH sH tHZ`Z *%Naslov 6 <@&"5CJOJQJ\aJmH sH tHL`L *%Naslov 7 <@&OJQJmH sH tHR`R *%Naslov 8 <@&6OJQJ]mH sH tH>A@> Zadani font odlomkaVi@V Obi na tablica4 l4a .k@. Bez popisazOz pabstract0$77Xx5$7$8$9DH$]7^7a$ CJOJQJ^JaJmH sH tHt@t cReaetka tablice7:V0tOt G reference($5$7$8$9DH$^`a$ CJOJQJ^JaJmH sH tH6U@!6 G Hiperveza >*B*phjOBj author$$5$7$8$9DH$`a$ CJOJQJ^JaJmH sH tHnOn  authorinfo $5$7$8$9DH$`a$ CJOJQJ^JaJmH sH tH Ui      RQJ !" #!       !"#| '"!Ui<4<k<<LMkZ$%C u v w x y z { | ')`aOPwx}~0<VWr./IJ^_qr$ % & = > "!#!"""""""""|####*$R$S$\$$X%Y%Z%[%^'_'`'a'b'c'''''''''''++++2,3,..o.p...[4\444 : :D:E:<<<<t?u?? @)@`@@EAAAAAlFmFnFFF.J/J0JaJbJ L L\LLyMMMNNNNN1O^O_OvOwOSSSSSSSTTTTTTTTTT=U>UFUUU V V4V5V=VVVVWWWWWW]XXXX0Y1Y9YYYYYZ'ZoZZZZ [ [[q[[[[["\#\+\\\]]4]5]>]]] ^ ^^^^^^^^^WcXcdceccccccccdeeffff-f.fggggggggggggggggggggJhKh^hhhh@iAiBiCiDiEiFiGiHiIiJiKiLiMiNiOiPiQiRiSiVi000000000000000000000000000 00| 0| 0| @0000 0 0 0 000000 00 0x 0x 0x 0x 0x0 00 0 0 0 0 00 00000000 0 0 0 0 0 0 0000 0000 0000 0000 0000 00000 0000@00 0 0 0 0 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  00'0'0'! 0'! 0'! 0'0'0'0'0'0' 0'0'0'0' 0'0'0'0' 0'0'0'0' 0'0'0'0'$ 0'$ 0'$ 0'$ 0'$ 0'$ 0'$ 0'0' 0'0'0'0'0' 0'0'0'0'0' 0'0'0'0'& 0'& 0'& 0'& 0'0'0'0'& 0'& 0'& 0'& 0'& 0'0' 0'0'0'0'0'0'0'0'0'0'0'0'0'0' 0' 0' 0' 0' 0' 0'0' 0' 0' 0' 0' 0' 0'0' 0' 0' 0' 0' 0' 0'0' 0' 0' 0' 0' 0' 0'0' 0' 0' 0' 0' 0' 0' 0' 0' 0' 0' 0' 0'0' 0' 0' 0' 0'0' 0' 0'0' 0' 0' 0' 0' 0' 0'0' 0' 0' 0' 0' 0' 0'0'0'0'0'0' 00^0^0^0^0^ 0^00V0V0V0V0V0V0V0V0V0V0V0V0V0V0V0V0V0V0000000000000000000000000000000000000000000LMkZ$%C u v w x y z { | ')`aOPwx}~0<VWr./IJ^_qr$ % & = > "!#!"""""""""|####*$R$S$\$$X%Y%Z%[%^'_'`'a'b'c'''''''''''++++2,3,..o.p...[4\444 : :D:E:<<<<t?u?? @)@`@@EAAAAAlFmFnFFF.J/J0JaJbJ L L\LLyMMMNNNNN1O^O_OvOwOSSTTTTTTT=U>UUU V V4V5V=VVVVWWWWW]XX0Y1YYYZoZZZZ [ [[q[[[["\#\\\4]ccdeef-f.fgVi0000000@0@0000000000000000000 00 0 0 @00:0:0: 0: 0: 0: 0:0:0:0:0:0: 0:0: 0: 0: 0: 0: 0:0: 0:0: 0: 0: 0: 0: 0:0: 0:0:0:0:0:0:0:0: 0: 0: 0: 0: 0: 0: 0:0:0:0: 0:0:0:0: 0:0:0:0: 0:0:0:0: 0:0:0:0: 0:0:0:0:0: 0:0:0:0:@00 0 0 0 0 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  00&0&0&! 0&! 0&! 0&0&0&0&0&0& 0&0&0&0& 0&0&0&0& 0&0&0&0& 0&0&0&0&$ 0&$ 0&$ 0&$ 0&$ 0&$ 0&$ 0&0& 0&0&0&0&0& 0&0&0&0&0& 0&0&0&0&& 0&& 0&& 0&& 0&0&0&0&& 0&& 0&& 0&& 0&& 0&0& 0& 0& 0&0&0&0&0&0&@0&@0&@0&@0&@0&@0&@0&K00' @0& @0&@0& @0& @0& @0& K00!@0&@0&@0& @0& @0& @0&@0& @0& @0& @0& @0& @0&K00 @0&@0&@0& @0& @0& @0& K00,@0&@ 0&@0& @0& @0& @ 0 &K000K00K00K00K0#0$K0#0K0#0@00\M3P&4EHOrR_p$4 0&9<>?BDGKMNv04D>4HHJKMQh`Nf8J4:=@ACEFHIJLO;c'{'~'eeeUi_XRRS 0e0e     A@  A5% 8c8c     ?1 d0u0@Ty2 NP'p<'pA)BCD|E||s " 0e@        @ABC DEEFGHIJK5%LMNOPQRSTUWYZ[ \]^_ `abN E5%  N E5%  N F   5%    !"?N@ABC DEFFGHIJK5%LMNOPQRSTUWYZ[ \]^_ `ab@ R(  b 2$" F3  s"*?` G c $X99?2$"" H S  ?"6@ NNN?Nm r" I S  ?"6@ NNN?Nm  r" J s *  ?"6@`NNN?N    M BG HI ?"0@NNN?N   N BG HI ?"0@NNN?N   O HG0HI0?"0@NNN?N 2 P BGp HIp ?"0@NNN?N  " Q s *  ?"6@`NNN?N- 2  " R s *  ?"6@`NNN?N-$  B S  ?O JM JN QJO JRP|'UiF(#,t 6\67#8ԟ 9,8 :,|`; <,{`=> >|`?,}`@l{`]&5.fVi  j2B;fVi > *urn:schemas-microsoft-com:office:smarttags PersonName9 *urn:schemas-microsoft-com:office:smarttagsplace8 *urn:schemas-microsoft-com:office:smarttagsCityB*urn:schemas-microsoft-com:office:smarttagscountry-region p Ivan Pogarcic Ivan Pogar i Miro Francic ProductID     NRXYbiksvy{BHIV P &7C !! ! !!!!!!!##6&@&A&I&>'A'B'N'V'\''''''') )S.^.a.h.r8u8^<b<@@ecpcuc{cccccccccccccccccccd deeffff ff3f8f9f:f=f?f@fGfIfKfLfQfRfUfVfXf[fafbflfqfwfffggggViKS\YZ+4 &)_aNPvx|~/0;<UWqr-/HJ]_pr# & < > !!#!""""""""""""{#|#####)$*$Q$S$[$\$$$W%[%]''''++++++1,3,..n.p...Z4\444 : :C:E:<<<<s?u??? @ @(@)@_@`@@@DAEAAAAAkFnFFF-J0J`JbJ L L[L\LLLxMyMMMNNNNNNNN0O1O]O_OuOwOSSTTTTTTTTTTTTTTUEUFUUUUU V V3V5V]]]]] ^^VcXccceccccccccdeeefff,f3f?fyfgggggggIhKh]h^hhhhh?iVi3333v | )x|~VQJ_r& > ""|##S$\$$$''++.p.66?`@EAAAAnFFMJNJK LNNNN1OwOTT>UFUV=V.WUWWW1Y9YYYY'ZDZoZ [[[[\ \#\+\\\\]5]>]]]]^s^^cccdefggggg(hIhKh^hhhi?iVigVi)P8@pf1#%!J+`.kO fe %\R&Zbi9<z,$82O'0<Rq 3g7vK"gE,5!3&" )$T`yE&p|+% +Lv0Jk!Z0zwW6 X\<;%NIE8_GQ:wHV">7IBS~đk_B&-cRS|cV">sUUhH yi؅-n82Xptkq%zlr(USz.UX+13~F}~%,,^,`CJOJQJaJo(hH^`OJQJ^Jo(hHodd^d`OJQJo(hH4 4 ^4 `OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hHtt^t`OJQJ^Jo(hHoDD^D`OJQJo(hHh P^`PhHh @@^@`hH.h 0^`0hH..h ``^``hH... h ^`hH .... h ^`hH ..... h ^`hH ...... h `^``hH....... h 00^0`hH........h hh^h`o(hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h hh^h`hH.h88^8`CJOJQJaJo(hHh L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h hh^h`hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH. P^`PhH ^`hH. 808^8`0hH.. ^`hH... XX^X`hH .... ^`hH ..... xx^x`hH ......  `^``hH.......  ^`hH........h ^`hH.h^`CJOJQJaJo(hHh pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h^`CJOJQJaJo(hHh^`CJOJQJaJo(hHh pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h hh^h`hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h P^`Po(hHh @S^@`o(hH.h 0^`0o(hH..h ``^``o(hH... h ^`o(hH .... h ^`o(hH ..... h ^`o(hH ...... h `^``o(hH....... h 00^0`o(hH........h^`CJOJQJaJo(hHh^`CJOJQJaJo(hHh pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.hh^h`CJOJQJaJo(hH^`OJQJ^Jo(hHo^`OJQJo(hHpp^p`OJQJo(hH@ @ ^@ `OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hHh hh^h`o(hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.hh^h`CJOJQJaJo(hH^`OJQJ^Jo(hHo^`OJQJo(hHpp^p`OJQJo(hH@ @ ^@ `OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hHh hh^h`hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h hh^h`o(hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.hh^h`CJOJQJaJo(hH^`OJQJ^Jo(hHo^`OJQJo(hHpp^p`OJQJo(hH@ @ ^@ `OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hHh^`CJOJQJaJo(hHh^`CJOJQJaJo(hHh pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h P^`PhHh @@^@`hH.h 0^`0hH..h ``^``hH... h ^`hH .... h ^`hH ..... h ^`hH ...... h `^``hH....... h 00^0`hH........h^`CJOJQJaJo(hHh^`CJOJQJaJo(hHh pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h hh^h`hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH. hh^h`o(hH. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH. P^`PhH ^`hH. 808^8`0hH.. ^`hH... XX^X`hH .... ^`hH ..... xx^x`hH ......  `^``hH.......  ^`hH........,,^,`CJOJQJaJo(hH^`OJQJ^Jo(hHodd^d`OJQJo(hH4 4 ^4 `OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hHtt^t`OJQJ^Jo(hHoDD^D`OJQJo(hHh P^`Po(hHh @@^@`o(hH.h 0^`0o(hH..h ``^``o(hH... h ^`o(hH .... h ^`o(hH ..... h ^`o(hH ...... h `^``o(hH....... h 00^0`o(hH........hhh^h`CJOJQJaJo(hHh88^8`CJOJQJaJo(hHh L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h hh^h`hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h hh^h`o(hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h P^`Po(hHh @@^@`o(hH.h 0^`0o(hH..h ``^``o(hH... h ^`o(hH .... h ^`o(hH ..... h ^`o(hH ...... h `^``o(hH....... h 00^0`o(hH........h hh^h`o(hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.hh^h`CJOJQJaJo(hH^`OJQJ^Jo(hHo^`OJQJo(hHpp^p`OJQJo(hH@ @ ^@ `OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hHh hh^h`hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h^`CJOJQJaJo(hHh^`CJOJQJaJo(hHh pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.hh^h`CJOJQJaJo(hH^`OJQJ^Jo(hHo^`OJQJo(hHpp^p`OJQJo(hH@ @ ^@ `OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hHh P^`Po(hHh @S^@`o(hH.h 0^`0o(hH..h ``^``o(hH... h ^`o(hH .... h ^`o(hH ..... h ^`o(hH ...... h `^``o(hH....... h 00^0`o(hH........h P^`Po(hHh @@^@`o(hH.h 0^`0o(hH..h ``^``o(hH... h ^`o(hH .... h ^`o(hH ..... h ^`o(hH ...... h `^``o(hH....... h 00^0`o(hH........h P^`PhHh @@^@`hH.h 0^`0hH..h ``^``hH... h ^`hH .... h ^`hH ..... h ^`hH ...... h `^``hH....... h 00^0`hH........h hh^h`o(hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h hh^h`o(hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h hh^h`o(hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h P^`PhHh @@^@`hH.h 0^`0hH..h ``^``hH... h ^`hH .... h ^`hH ..... h ^`hH ...... h `^``hH....... h 00^0`hH........))$Rq"gEzlrO \>_Gj|cQ:wHn5!#<;e F}~kqp|+Xp8D Kp:9mi(qn,84CUof.4ZE <i~^+:AcG`k1({ATwY~n-iwI_")RmaIBtG=WmaTtr`.{UT;uLl2AgGG)f=_*%;Y [ Oo x|9gOk;"LV(?Pee-?PbqJ2%3$6[=E~9PBqR-H,|-s85^X""""""|####*$R$S$\$$X%Y%TTTTTTT>UFUUU V V5V=VVVVWWWWW]XXXX1Y9YYYYYZ'ZoZZZZ [[q[[[[#\+\\\]]5]>]]] ^ ^Vi@ggsgg$ !#&'/347Uipp p pppp(@pp&p*p0p2p<p>p@pBpFpJpPpRpbpjplpUnknownGz Times New Roman5Symbol3& z Arial] Times-BoldTimes New Roman3z Times?5 z Courier New;Wingdings"1c&lŦjŦTz8X4z8X4!24d~g~g 2qHX)?p2-KVALITETA MODELA POSLOVANJA RAZVIJENOG UML-om Miro Francic Miro Francic)                           ! " # $ % & ' ( Oh+'0( @L l x  0KVALITETA MODELA POSLOVANJA RAZVIJENOG UML-omMiro Francic Normal.dotMiro Francic24Microsoft Office Word@*ɚ@T0ak@^P,@ඨkz8X՜.+,D՜.+,\ hp|  4~g .KVALITETA MODELA POSLOVANJA RAZVIJENOG UML-om Naslov 8@ _PID_HLINKSAl ;mailto:mfrancic@veleri.hr  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()+,-./013456789>Root Entry FȆk@Data 1TabledWordDocument<SummaryInformation(*DocumentSummaryInformation82CompObjs  F!Microsoft Office Wordov dokument MSWordDocWord.Document.89q