PREDMET

IS307 ANALIZA I LOGIKO PROJEKTOVANJE IS-A

Predavanje broj 2
IS307-P02

FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

Nedelja

as

Tematska
jedinica

Predavanja
Lekcija ili aktivnost

Faza
analize:
Izbor, analiza i
utvrivanje
zahteva

Izbor zahteva; Procesi izbora, analize i

dogovaranja zahteva;

Faza
analize:
Izbor, analiza i
utvrivanje
zahteva

Faza
analize:
Izbor, analiza i
utvrivanje
zahteva

Rezultat znanja ili vetine

koje student treba da
dobije
ta se podrazumeva pod procesom
izbora zahteva koji predstavlja prvu
aktivnost inenjeringa zahteva.
Veza izmeu izbora i kasnije analize
i dogovaranja zahteva.

Tehnike za izbor zahteva

Prototip:
Tipovi
prototipova;
Implementacija prototipova;
Analiza i utvrivanje zahteva: Kontrolna
lista zahteva; Matrica interakcije;
Utvrivanje zahteva;

Intervjui, Analiziranje procedura i

drugih dokumenata,
Scenarija,
Sofisticirane sistemske metode,
Posmatranje i socijalna analiza
Kako tehnika prototipa moe pomoi
u razumevanju zahteva. ta je
obuhvaeno analizom i utvrivanjem
zahteva. Kakvu ulogu u tom procesu
imaju kontrolna lista zahteva i
matrica interakcije.

Copyright 2010 UNIVERZITET METROPOLITAN, Beograd. Sva prava zadrana. Bez prethodne pismene dozvole od
strane Univerziteta METROPOLITAN zabranjena je reprodukcija, transfer, distribucija ili memorisanje nekog dela ili itavih
sadraja ovog dokumenta., kopiranjem, snimanjem, elektronskim putem, skeniranjem ili na bilo koji drugi nain.
Copyright 2010 BELGRADE METROPOLITAN UNIVERSITY. All rights reserved. No part of this publication may be
reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying,
recording, scanning or otherwise, without the prior written permission of Belgrade Metropolitan University.

Oktobar, 2010.

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

SADRAJ
Uvod ........................................................................................................................................................ 3
Izbor zahteva ........................................................................................................................................... 3
Procesi izbora, analize i utvrivanja zahteva .......................................................................................... 5
Tehnike za izbor zahteva......................................................................................................................... 8
Intervjui................................................................................................................................................. 9
Analiziranje procedura i drugih dokumenata ..................................................................................... 10
Scenarija ............................................................................................................................................ 11
Sofisticirane sistemske metode ......................................................................................................... 13
Posmatranje i socijalna analiza ......................................................................................................... 14
Ponovna upotreba zahteva ................................................................................................................ 17
Prototip .................................................................................................................................................. 18
Implementacija prototipa.................................................................................................................... 19
Analiza i utvrivanje zahteva ................................................................................................................. 20
Kontrolna lista zahteva....................................................................................................................... 21
Matrica interakcije .............................................................................................................................. 22
Utvrivanje zahteva ........................................................................................................................... 23

2/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

Predavanje br. 2

Faza analize: Izbor, analiza i utvrivanje

zahteva
Uvod
U ovom predavanju su opisane aktivnosti procesa inenjeringa zahteva koje se odnose na otkrivanje
(izbor) zahteva, njihovu kasniju analizu kako bi se otklonila eventualna nekompletnost i
nekonzistentnost zahteva i na kraju utvrivanje (dogovaranje) finalnih verzija zahteva. Pored toga,
objanjene su tehnike koje se koriste pri izboru zahteva kao to su intervjui, sofisticirana analiza
sistema, analiza scenarija i etnografija. Takoe je objanjena tehnika prototipa koja interesentima
(stakeholderima) sistema u velikoj meri pomae pri razumevanju zahteva, pri emu je opisano
nekoliko razliitih pristupa izradi prototipa.

Izbor zahteva
Izbor zahteva je uobiajeno ime za aktivnosti kojima je obuhvaeno otkrivanje zahteva sistema. U
procesu izbora zahteva, inenjeri zadueni za razvoj sistema rade sa kupcima i krajnjim korisnicima
kako bi identifikovali probleme koje treba reiti, sistemske servise, traene performanse sistema,
hardverska ogranienja itd. Izbor zahteva se ne odnosi samo na pronalaenje onoga ta ljudi ele; on
zahteva paljivu analizu organizacije, domena aplikacije i poslovnih procesa nad kojima e se sistem
primenjivati.

Veoma usko povezani sa izborom zahteva su analiza i dogovaranje zahteva. Cilj analize i dogovaranja
zahteva je utvrditi i sloiti se sa skupom zahteva koji su kompletni i konzistentni. Kako bi se koristili
kao osnova za razvoj sistema, zahtevi treba da pre svega budu nedvosmisleni. Za vreme procesa
analize,otkrivaju se izostavljeni, konfliktni i dvosmisleni zahtevi, zahtevi koji se preklapaju i nerealni
zahtevi. Ukoliko ima konfliktnih zahteva ili ako meu predloenim zahtevima ima dvosmislenih
zahteva, interesenti (stakeholder) se moraju dogovoriti i sloiti oko njihove modifikacije i
pojednostavljenja.

Termin izbor zahteva sugerira da je to proces jednostavnog prenosa znanja u kojem inenjeri koji rade
na definisanju zahteva biraju i dokumentuju postojee znanje korisnika. U realnosti, proces je mnogo
komplikovaniji. Korisnici retko imaju jasnu sliku svojih zahteva; razliiti ljudi u organizaciji imaju
suprotstavljene zahteve; zahtevi su esto tehnoloki ogranieni itd. Zbog toga se izbor zahteva ne
moe poistovetiti sa procesom lovljenja zahteva, ve ga treba tretirati kao sloeni proces
dogovaranja izmeu stakeholdera i onih koji razvijaju sistem.

Neki autori (Davis, 1993) smatraju da se termin izbora odnosno otkrivanja zahteva ne moe izjednaiti
sa procesom analize i razumevanja problema. Analiza problema je aktivnost kod koje se naglasak
stavlja na upoznavanje sa problemom koji treba reiti (esto kroz razmenu miljenja i odgore na
upitnike), razumevanje potreba potencijalnih korisnika, pronalaenje ko su stvarni korisnici sistema i
razumevanje svih ogranienja kojima su podlona reenja.

3/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

Takoe je pogreno misliti da se analiza problema odnosi samo na razumevanje detalja specifinog
problema koji zahteva neku vrstu reenja. Moe se rei da postoje etiri dimenzije izbora zahteva.
1. Razumevanje domena aplikacije
Poznavanje domena aplikacije je generalno poznavanje oblasti u kojoj se sistem primenjuje. Na
primer, da bi smo razumeli sistem katalogizacije koji se koristi u bibliotekama, moramo posedovati
generalno poznavanje bibliotekog sistema i naina na koji biblioteke rade; da bismo razumeli
zahteve za sistem signalizacije na eleznicama, moramo poznavati kako eleznica radi i fizike
karakteristike vozova.

2. Razumevanje problema
Moraju se poznavati detalji specifinog problema koji moe imati korisnik. Na primer, u sluaju
sistema za katalogizaciju, moramo razumeti kako pojedinane biblioteke organizuju svoje
kolekcije knjiga; za sistem signalizacije na eleznici, moramo znati nain na koji se primenjuje
ogranienje brzine u pojedinim segmentima trasa. Razumevanjem problema, znanje o domenu
aplikacije se specijalizuje i proiruje.

3. Razumevanje poslovanja
Informacioni sistemi generalno, doprinose razvoju poslovanja organizacije. Zbog toga se mora
razumeti interakcija koja postoji izmeu IS-a i organizacije kao i nain na koji IS utie na razliite
delove poslovanja organizacije i doprinosi ostvarenju celokupnih poslovnih ciljeva.

4. Razumevanje potreba i ogranienja interesenata (stakeholdera) sistema

Stakeholderi sistema su ljudi na koje izlazi iz sistema materijalno utiu. To mogu biti krajnji
korisnici sistema, menaderi odeljenja u kojima je sistem instaliran itd. U procesu izbora sistema,
moraju se detaljno razumeti njihove specifine potrebe, procesi rada koje sistem treba da podri
kao i ulogu postojeeg sistema i tom procesu rada.

Efikasan izbor zahteva je veoma vaan proces. Ako se ne otkriju stvarni zahtevi korisnika, oni
verevatno nee biti zadovoljni finalnim sistemom. Prihvatanje sistema zavisi pre svega od toga
koliko dobro on zadovoljava njihove potrebe i podrava rad koji treba automatizovati. To nije uvek
mogue lako oceniti i moe postojati veliki opseg stakeholdera koji imaju direktne ili indirektne
koristi od sistema. Svi oni mogu koristiti razliite kriterijume za ocenu prihvatljivosti sistema.

Multidimenzionalna priroda izbora zahteva se reflektuje u razliitim problemima sa kojima se

suoavaju inenjeri koji rade na utvrivanju zahteva, kao to su:

1. Saznanja o domenu aplikacije se ne nalaze na jednom mestu. Ona postoje u razliitim

izvorima kao to su knjiga, uputstva i ljudi koji se nalaze na elu pojedinih oblasti poslovanja.
Ona esto sadre specijalnu terminologiju koja nije odmah razumljiva za inenjere zahteva.

2. Ljudi koji razumeju problem koji treba reiti su esto suvie zauzeti reavanjem drugih
problema. Oni ne mogu da provedu mnogo vremena pomaui inenjerima zahteva da
razumeju zahteve za novim sistemom. esto, oni nisu uvereni u potrebu za novim sistemom
tako da ne ele da budu obuhvaeni procesom inenjeringa zahteva.

3. Na zahteve sistema mogu uticati organizacioni problemi i politiki faktori koji ne moraju biti
vidljivi za krajnje korisnike sistema, koji takoe imaju svoje sopstvene zahteve. Vii nivoi
menadmenta mogu uticati na zahteve sistema tako to e traiti da oni zadovolje njihove
personalne agende. Na primer, oni mogu traiti da se neke funkcije sistema prenesu na
4/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

njihova odeljenja i predloe zahteve kojima se te funkcije integriu sa funkcijama koje se ve

tu obavljaju.

4. Stakeholderi esto samo u veoma generalnoj formi znaju ta zaista ele da dobiju kao izlaz iz
raunara. ak i kada imaju jasnu ideju o tome ta bi eleli da sistem radi, teko im je da to
iskau na artikulisan nain. Oni mogu postaviti nerealne zahteve jer nemaju predstavu o
trokovima njihove realizacije. Razliiti stakeholderi imaju razliite zahteve i mogu ih iskazati
na potpuno razliite naine. Analitiari moraju da otkriju sve potencijalne izvore zahteva i da
ukau na njihova preklapanja ili konflikte.

Izbor zahteva se moe dalje komplikovati injenicom da se ekonomsko i poslovno okruenje u kojem
analitiari rade neprestano menja. Ono se neminovno menja i za vreme izbora zahteva pa se zbog
toga i vanost nekih zahteva moe promeniti. Zahtevi mogu nastati i pojavom novih stakeholdera koji
prvobitno nisu bili konsultovani. Takoe, ljudi koji su bili konsultovani na nekom stupnju procesa mogu
promeniti posao tako da vie nisu raspoloivi za dalje konsultacije.

Svi ovi faktori znae da esto pri izboru zahteva nisu korisne strukturne metode. Generalno, mnoge od
njih mogu biti koriene kao podrka analizi samo poto je izvren poetni izbor zahteva. Da bi se
koristila neka metoda, mora se generalno razumeti domen aplikacije i problem koji se reava. Metode
imaju svoje mesto u procesu izbora zahteva ali njihovo korienje mora uvek biti dopunjeno
generalnim razumevanjem zahteva nastalim iz domena problema i na osnovu potreba stakeholdera
sistema.

Procesi izbora, analize i utvrivanja zahteva

Izbor i analiza zahteva su usko povezani procesi. Kada se za vreme procesa izbora zahtevi otkriju,
analitiari ih neminovno moraju izvriti. Problemi mogu biti odmah prepoznati, prodiskutovani sa
izvorima od kojih su zahtevi nastali i reeni. O analizi se esto govori kao o posebnoj aktivnosti koja
sledi nakon izbora zahteva. Meutim, treba imati na umu da su u stvarnosti to meusobno povezani
procesi.

Analiza i dogovaranje zahteva se odnose na utvrivanje zahteva visokog nivoa. Inenjeri koji rade na
utvrivanju zahteva i stakeholderi pregovaraju o zahtevima, pretresaju ih kako bi se sloili oko
definicija koje e biti ukljuene u dokument zahteva. U nekim organizacijama takvi zahtevi se
detaljnije razvijaju u toku izrade specifikacije ili modela sistema. U razvoju ovih modela se takoe
moe naii na kontradiktorne i nekompletne zahteve. Zbog toga se moe rei da su faze izbora,
analize i pretresanja zahteva meusobno povezane, da se mogu reaktivirati jedna iz druge kao bi se
otkrilo vie informacija za reavanje problema koji su otkriveni.

Zbog toga se o procesima izbora, analize i dogovaranja zahteva moe govoriti kao o segmentima
spirale kako je to prikazano na slici 1.

5/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

Slika 1. Procesi izbora, analize i dogovaranja zahteva kao segmenti spirale

Obino, inenjeri koji rade na utvrivanje zahteva otkrivaju deo informacija o zahtevima. One se
analiziraju, usaglaavaju i tada poinje druga spirala. To se nastavlja sve dok se zbog definisanog
roka ne pone sa razvojem sistema (normalni uslov zavretka) ili dok svi stakeholderi ne budu
zadovoljni zahtevima.
Postoji mnogo moguih procesa izbora zahteva i razliite organizacije koriste razliite procese.
Generalan model procesa izbora zahteva koji pokriva veinu tih razliitih procesa je prikazan na slici
2.

Postavljanje
ciljeva

Razumevanje
pozadine

Organizovanje
znanja

Sakupljanje
zahteva

Poslovni ciljevi

Organizaciona
struktura

Identifikacija
stakeholdera

Zahtevi
stakeholdera

Problem koji
treba razreiti

Domen aplikacije

Utvrivanje
prioriteta ciljeva

Zahtevi domena

Ogranienja
sistema

Postojei sistemi

Filtrirnje domena
znanja

Organizacioni
zahtevi

Slika 2. Generalan model procesa izbora zahteva

On ukljui etiri kritine aktivnosti:

1. Postavljanje ciljeva

6/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

Na ovom nivou se utvruju ciljevi itave organizacije. Njima su obuhvaeni opti ciljevi poslovanja,
okviran opis problema koji treba reiti, obrazloenje zato je sistem neophodan i ogranienja
sistema kao to su budet, termin plan i unutranja ogranienja.
2. Razumevanje pozadine
Ovo je vrlo vaan nivo gde inenjeri zahteva prikupljaju i analiziraju zahteve o pozadini sistema.
To ukljuuje informacije o organizaciji u kojoj e se sistem instalirati, informacije o aplikativnom
domenu sistema i informacije o postojeim sistemima koji se koriste i koji treba dea budu
zamenjeni sistemom koji se specificira.
3. Organizovanje znanja
Velika koliina znanja koja je sakupljena na prethodnim nivoima mora biti organizovana. To
podrazumeva identifikaciju stakeholdera sistema, njihove uloge u organizaciji, utvrivanje
prioriteta postavljenih ciljeva organizacije i odbacivanje domena znanja koji direktno ne doprinose
zahtevima sistema.
4. Sakupljanje zahteva stakeholdera
Ovaj nivo zapravo predstavlja ono to mnogi podrazumevaju pod izborom zahteva. On obuhvata
konsultacije sa stakeholderima sistema kako bi se otkrili zahtevi i dobijanje zahteva koji proizilaze
iz domena aplikacije i organizacije za koju se sistem pravi.

Mada slika 2. opisuje aktivnosti izbora zahteva, ona predstavlja idealizovan model procesa. U
realnosti, izbor zahteva je mnogo zbrkaniji jer su aktivnosti koji su pokazane na slici esto
meusobno izmeane. Takoe, kritine aktivnosti utvrivanja ciljeva koje se deavaju u ranoj fazi
izbora zahteva se esto ne izvre, to rezultuje znaajnim problemima u fazi analize kao to je
npr. nemogunost da se na osnovu utvrenih ciljeva utvrde prioriteti zahteva.

Izlaz iz procesa izbora zahteva treba da bude dokument skica zahteva sistema koji se zatim
analizira kako bi se u definiciji zahteva otkrili eventualni problemi i konflikti. Konflikti i preklapanja
su gotovo neizbeni pa da bi se oni razreili i zahtevi utvrdili, pristupa se procesu usaglaavanja
(dogovaranja) zahteva sa razliitim stakeholderima sistema. Generalni model analize i
dogovaranja je prikazan na slici 3.

Analiza zahteva
Provera
neophodnosti

Provera konzistentnosti i
kompletnosti

Provera izvodljivosti

Neophodni zahtevi

Konfliktni i nekompletni zahtevi

Neizvodljivi zahtevi

Diskusija o
zahtevima

Postavljanje prioriteta
zahteva

Postizanje
saglasnosti oko
zahteva

Dogovaranje zahteva

Slika 3. Generalni model analize i dogovaranja

Cilj analize zahteva je pronai probleme u skici zahteva. Mada je to prikazano kao sekvenca
diskretnih aktivnosti, u stvaranosti, aktivnosti analize su meusobno povezane. Aktivnosti koje su
tipino deo analize zahteva su:

7/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

1. Provera neophodnosti
Analizira se potreba za zahtevom. U nekim sluajevima, mogu biti predloeni zahtevi koji ne
doprinose poslovnim ciljevima organizacije ili reavanju specifinih problema.
2. Provera konzistentnosti i kompletnosti
Zahtevi se unakrsno proveravaju na konzistentnost i kompletnost. Konzistentnost znai da zahtevi
nisu kontradiktorni; kompletnost znai da nisu isputeni servisi ili ogranienja koja moraju biti
definisana.
3. Provera izvodljivosti
Zahtevi se proveravaju kako bi bili sigurni da su oni izvodljivi u kontekstu budeta i plana koji je
raspoloiv za razvoj sistema.
Ove aktivnosti rezultuju identifikacijom skupa zahteva o kojima e se diskutovati u procesu
dogovaranja zahteva. Da li je zahtev neophodan ili izvodljiv je esto stvar miljenja i razliiti
inenjeri se oko toga mogu ne slagati. Konflikti izmeu njih se mogu razreiti diskusijom koji od
zahteva koji je konfliktan mora da se menja i u kojoj meri.

Proces dogovaranja zahteva takoe ima veliki broj meusobno povezanih procesa koji su
prikazani na slici 3.
1. Diskusija zahteva
Zahtevi koji su oznaeni kao problematini se diskutuju i stakeholderi koji uestvuju u diskusiji
prezentuju svoja gledita o njima.
2. Postavljanje prioriteta zahteva
Zahtevima se postavljaju prioriteti o kojima se diskutuje kako bi se utvrdilo koji se zahtevi mogu
smatrati kritinim i pomogao proces donoenja odluka.
3. Postizanje saglasnosti oko zahteva
Identifikuju se reenja problema vezanih za zahteve sistema i postie se kompromis oko skupa
zahteva. Generalno, to moe podrazumevati pravljenje izmena u nekim zahtevima.

U mnogim sluajevima, iz procesa analize proizilaze pitanja na koja se ne mogu dati odgovori i oko
kojih se ne mogu postii slaganja u pogledu potrebnih izmena zahteva. To generalno znai da u
procesu dogovaranja zahteva ne raspolaemo sa dovoljno informacija. Kako bi se o zahtevima
sistema skupile nove informacije, mora se zapoeti jo jedan novi krug spirale sa slike 1.

Tehnike za izbor zahteva

Kao to je reeno, izborom zahteva je obuhvaeno pronalaenje informacija o aplikacionom domenu
sistema, specifinim problemima koje treba reiti i specifinim potrebama stakeholdera sistema.
Generalno, inenjeri koji rade na izboru zahteva imaju potrebu da koriste razliite tehnike za otkrivanje
tih informacija. U ovom predavanju je opisano nekoliko komplementarnih pristupa za izbor zahteva.

Najvie znanja pri izboru zahteva potie od itanja dokumentacije o sistemu i od razgovora sa ljudima
koji su kao korisnici ili menaderi obuhvaeni sistemom. Kao rezultat izbora zahteva se javlja ogromna
koliina informacija koja mora biti organizovana tako da bude razumljiva. Yeh i Zave su sugerirali tri
fundamentalna naina za struktuiranje tog znanja:

Deljenje
Podrazumeva organizaciju znanja u veze agregacije gde je znanje o zahtevima opisano u vidu
njenih delova. Na primer, u sistemu rezervacije (booking-a) slog rezervacije moe biti
definisan kao agregacija reference leta, izvora i destinacije leta, imena i adrese putnika,
datuma putovanja.
8/24

Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

Apstrakcija
Podrazumeva organizaciju znanja prema vezi generalno/specifino. Znanje o zahtevima je
opisano preko veze specifinih instanci prema apstraktnim strukturama. Tako, u sistemu
rezervacija, apstrakcija Putnik, moe biti razvijena i koriena kao referenca na sve klase
putnika kao to su deca i odrasli, ljudi koji plaaju punu cenu karte ili subvencioniranu cenu.

Projekcija
To je organizacija znanja iz nekoliko razliitih perspektiva ili taaka gledanja. Razliiti izvori
imaju udela u razliitim informacijama o sistemu pa je esto vano za vreme izbora zahteva
eksplicitno identifikovati te izvore. Na primer, sistem rezervacije se moe posmatrati sa take
gledita putnikog agenta, menadera letanja, operatora koji radi na ekiranju karata, putnika,
administratora baze podataka itd. o emu e se kasnije detaljnije govoriti.

Dobri inenjeri zahteva ove fundamentalne naine ne koriste samo za vreme izbora zahteva. Metode
analize, kao to je objektno-orijentisana analiza se baziraju na ovim pristupima i esto zahtevaju da se
relacije klasifikacije i agregacije eksplicitno specificiraju. O metodama koje koriste ove tehnike e
takoe kasnije biti vie rei.

Izbor zahteva je kooperativni proces kojim su obuhvaeni inenjeri zahteva i stakeholderi sistema.
Efikasan izbor zahteva efikasnu kooperaciju ali u mnogim sluajevima za inenjere zahteva i
stakeholdere je teko da formiraju dobre relacije u zajednikom radu. Neki od problema s kojima se
mogu suoiti su:
1. Za izbor zahteva nema dovoljno vremena
Stakeholderi su zauzeti ljudi koji imaju svoje obaveze i oni nemaju mnogo slobodnog vremena da sa
inenjerima zahteva diskutuju o novom sistemu.
2. Inenjeri zahteva se nisu odgovarajue pripremili za proces izbora zahteva
Od najveeg znaaja za efikasan izbor je razumevanje aplikativnog domena. Ponekad meutim,
inenjeri zahteva pre razgovora sa stakeholderima ne upoznaju ili ne mogu da upoznaju domen. Zbog
nemogunosti da se koriste specijalizovani termini sa kojima inenjeri zahteva nisu familijarni,
stakeholderi postaju nervozi i esto izmeu njih i inenjera zahteva dolazi do pogrenog razumevanja.
3. Stakeholderi ne ele novi sistem
U mnogim sluajevima, kupovina ili instaliranje novog sistema je odluka organizacije a da pri tom ljudi
na koje taj sistem ima uticaja nisu konsultovani. Oni mogu smatrati da novi sistem nije neophodan i ne
vide razlog zato treba da uestvuju u njegovoj specifikaciji.

Neke od mnogobrojnih greaka sistema na koje se nailazi su direktna posledica ovih problema.
Inenjeri zahteva moraju biti osetljivi na potrebe stakeholdera i njihove zahteve.

Intervjui
Intervjui su jedan od osnovnih naina da analitiari sakupe informacije o sistemu koji treba
projektovati. Na poetku projekta, analitiar moe provesti veliki deo vremena intervjuiui ljude o
tome ta rade, koje informacije koriste i kojim tipovima informacionih procesa moe biti zamenjen
njihov rad. Ima mnogo naina za efikasno intervjuisanje, i ne moe se rei da je jedan metod bolji od
drugoga. Smernice kojih se treba pridravati su date u predavanjima za IS201.

Korienjem intervjua je teko izvui znanje o aplikacionim domenu zbog dva razloga:
1. Mnogi aplikativni domeni imaju svoju sopstvenu terminologiju i stakeholderi smatraju veoma
tekim da o domenu diskutuju ne koristei tu terminologiju. U mnogim sluajevima, oni to rade
na jedva primetan nain pa inenjeri zahteva esto pogreno razumeju njihove opise.
9/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

2. Postoje neki tipovi domena znanja koje stakeholderi ili ne mogu lako da objasne ili su sa njima
toliko familijarni da misle da nema potrebe ni za kakvim objanjenjima. Na primer, bibliotekaru
ne treba rei da svaku knjigu pre nego to se stavi na policu treba katalogizirati. Meutim, za
inenjere zahteva to ne mora biti oigledno.

Za vreme voenja intervjua je takoe teko doi do znanje o organizaciji, prvenstveno zbog politikih i
socijalnih faktora. U svim organizacijama postoje nevidljive sile i meusobni uticaji izmeu razliitih
ljudi. One utiu na zahteve stakeholdera ali stakeholderi moraju da se u razumnoj meri njima opiru i o
njima diskutuju. Na primer, postojea organizaciona struktura se esto ne podudara sa realnou ali
stakeholderi ne ele da o tome diskutuju sa strancima, van svojih sopstvenih odeljenja.

Serijom pojedinanih intervjua se o postojeem sistemu ili njegovoj zameni mogu dobiti
nekonzistentne informacije. Da bi se dobila tana slika postojeeg sistema i sistema kakav treba da
bude, mora se raditi na prevazilaenju svih tih nekonzistentnosti. Taj proces zahteva mnogo
telefonskih poziva i dodatnih intervjua. esto je vane ljude teko nai u svojim kancelarijama a
zakazivanje novih intervjua moe biti frustrirajue i iziskivati mnogo vremena. Moe se zakljuiti da
sakupljanje informacija o informacionom sistemu serijom pojedinanih intervjua nije efikasan posao.

Druga mogua opcija je grupni intervju. U grupnom intervjuu se istovremeno intervjuie nekoliko
kljunih ljudi. Prednosti ovakvog intervjuisanja su:
mnogo efikasnije korienje vremena nego to je to u sluaju serije individualnih intervju
mogunost da se uju miljenja drugih ljudi i da se sa tim miljenjima druga intervjuisana lica
sloe ili ne sloe
sinergija koja pomae da se pronau stavovi oko kojih postoji generalno slaganje i podruja
gde pogledi potpuno divergiraju. Npr. Komentar jedne osobe moe izazvati da druga osoba
kae To me je podsetilo ili Nisam znao da je to problem .

Osnovni nedostatak grupnog intervjuisanja su potekoe vezane za zakazivanje intervjua. to je vie

ljudi obuhvaeno intervjuom, to je tee nai odgovarajue vreme i mesto za svakog od njih. Moderne
tehnologije kao to su videokonferencije i video telefoni mogu da minimiziraju geografsku disperziju
koja zakazivanje sastanaka ini tekim.

Analiziranje procedura i drugih dokumenata

Da bi se o tekuem sistemu i organizaciji koja ga podrava otkrilo vie detalja, prethodne metode
odreivanja sistemskih zahteva mogu biti dopunjene ispitivanjem dokumentacije koja se na njih
odnosi. Relevantna pisana dokumenta su:

poslovni planovi

organizaciona ema

uputstva za voenje poslovne politike

dokumenta kojima je opisana misija organizacije

opisi poslovnih procesa (standardne operativne procedure)

interna i eksterna prepiska

izvetaji o prethodnim studijama

Jedan tip korisnih dokumenata su pisane rutine ili standardne operativne procedure za pojedince ili
radne grupe. Procedura opisuje kako se jedan posao ili zadatak izvrava kao i podatke i informacije
koje se koriste ili kreiraju u procesu izvrenja tog posla. Meutim procedure nisu izvor informacija koje
se mogu koristiti bez problema.
10/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

Ponekad, analizom nekoliko pisanih procedura se moe otkriti da su neki poslovi redudantni. Na
ovakve probleme treba ukazati menadmentu organizacije i to kao na neto to mora biti razreeno
pre poetka dizajniranja sistema. esto je neophodno da se pre redizajna informacionog sistema,
redizajnira itava organizacija.
Drugi problem koji se moe pojaviti je kada se utvrdi da je neka procedura isputena. I u ovom kao i u
prethodnom sluaju, posao analitiara nije da kreira proceduru koja nedostaje to je posao
menadmenta.
Trei i najei problem je kada se otkrije da procedura nije aurna, to se moete shvatiti pri
intervjuisanju osobe koja je odgovorna za obavljanje posla opisanog tom procedurom. I u ovom
sluaju odluku da se procedure pregledaju i utvrditi da one ne odgovaraju stvarnosti donosi
menadment, a uloga sistem analitiara je da na bazi razumevanja organizacije menadmentu to
samo sugeriu.
etvrti problem se vezuje za mogunost da procedura sadri kontradiktorne informacije o tome kako
organizacija funkcionie i koje se informacije pri tom koriste, u odnosu na one dobijene intervjuom i
posmatranjem. Kao i u prethodnim sluajevima, reenje ostaje na menadmentu.
Drugi tip dokumenata koji su korisni u sistem analizi su poslovne forme. Forme se koriste za sve
tipove poslovnih transakcija, od beleenja porudbina do isporuke dobara. One su vane za
razumevanje sistema jer eksplicitno ukazuju na tokove podataka unutar ili van sistema. Forme pruaju
kritine informacije o prirodi organizacije. Npr. iz faktura koje se generiu za kupce se moe videti da
kompanija vri isporuku dobara i naplatu na razliitim adresama; za neke kupce mogu vaiti snienja
itd.
tampane forme esto odgovaraju izgledima ekrana koje sistem generie da bi se preko njih izvrio
unos ili auriranje podataka. Forme su posebno korisne kada sadre originalno unete podatke jer tada
omoguavaju da se lako odrede karakteristike podataka koje aplikacija stvarno koristi.
Trei tip korisnih dokumenata su izvetaji koje generie postojei sistem. Kao primarni izlaz za neke
tipove sistema, izvetaji omoguavaju da se sistem analitiari prilikom utvrivanja zahteva vrate
unazad, sa informacija u izvetaju na podatke koje je neophodno uneti u sistem kako bi se ti izveati
generisali.
Ako je postojei sistem baziran na raunaru, etvrti skup korisnih dokumenata predstavljaju opisi
postojeih informacionih sistema kako su dizajnirani i kako rade.
Pored navedenih, postoji mnogo razliitih tipova takvih dokumenata koji se mogu koristiti u fazi
specifikacije zahteva, od flowchat-ova do renika podataka, izvetaja iz CASE alata i korisnikih
uputstava.

Scenarija
Krajnji korisnici i drugi stakeholderi sistema smatraju da je lake pozivati se na situacije iz realnog
ivota nego na apstraktne opise funkcija koje sistem treba da omogui. Zbog toga je esto korisno za
izbor jasnih zahteva sistema, razviti skup interaktivnih scenarija i koristiti ih. Scenarija su primeri
interaktivnih sesija koje se odnose na jedan tip interakcije izmeu krajnjeg korisnika i sistema.
Korienjem scenarija krajnji korisnici simuliraju svoju interakciju sa sistemom. Oni inenjerima
zahteva objanjavaju ta rade i koje su im informacije potrebne iz sistema da bi obavili zadatak opisan
scenarijem.

Procesom razvoja scenarija se, pored toga to se razmatra interakcija korisnika sa sistemom, moe
pomoi i u razumevanju samih scenarija. Otkrivanjem moguih scenarija se pokazuje opseg moguih
interakcija sa sistemom i obelodanjuju mogunosti sistema koje se trae. Scenariji su osnovni deo
nekih objektno orijentisanih metoda analize. Autori ovih metoda analizu zahteva pristupom baziranom
na scenarijima opisuju na sledei nain:

Scenarija se mogu shvatiti kao prie koje objanjavaju kako se sistem koristi. Oni su prvenstveno
korisni za dodavanje novih detalja osnovnim opisima zahteva. Kada postoji osnovna ideja o
11/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

mogunostima sistema, za te mogunosti treba razviti scenarija korienja. Njih treba identifikovati u
diskusiji sa stakeholderima koji su u interakciji sa sistemom i za sloene sisteme, broj identifikovanih
scenarija moe biti prilian.

Scenarija mogu biti pisana na razliite naine ali moraju ukljuivati sledei skup informacija:
1. Opis stanja sistema pre ulaska u scenario
2. Normalni tok dogaaja u scenariju
3. Izuzeci od normalnog toka dogaaja
4. Informacije o drugim aktivnostima koje se mogu izvravati u isto vreme
5. Opis stanja sistema posle zavretka scenarija

Da bismo ovo ilustrovali, razmotrimo sledei scenario koji opisuje ta se deava kada je korisnik u
interakciji sa EDDIS sistemom u trenutku kada eli da narui neki dokument za koji tano ne zna u
kojoj se biblioteci nalazi. To znai da ako dokument nije raspoloiv u lokalnoj biblioteci, korisnik mora
da se loguje na EDDIS sistem kako bi ga naruio iz druge biblioteke, ime su obuhvaeni sledei
koraci:
1. Korisnik se prijavljuje (loguje) na EDDIS sistem.
2. Pojavljuje se forma za naruivanje dokumenta.
3. U formu za naruivanje dokumenta se unosi referentni broj dokumenta koji se eli.
4. Korisnik bira jednu od opcija za isporuku iz menija za isporuku.
5. Korisnik se iskljuuje iz EDDIS-a.

Ovaj scenario je jednostavan ali on ne obuhvata situacije kojima se opisuje ta se dogaa u sluaju
neeg nepredvienog. To se u scenariju napisanom na prirodnom jeziku korisnika moe dodati
korienjem klauzula ako (IF). Na primer, korak 3 moe biti dopunjen na sledei nain.
3. U formu za naruivanje dokumenta se unosi referentni broj dokumenta koji se eli. Sistem
proverava broj i ako je neispravan nudi korisniku mogunost da broj ponovo unese ili da pozove
EDDIS-om help sistem koji e mu dati savet kako da otkrije greku.

Ovo daje vie detalja ali jo uvek nedostaju informacije kao to su ulazi i izlazi. One takoe mogu biti
dodate, ali ukljuivanje novih informacija u scenario na prirodnom jeziku ga moe uiniti tekim za
itanje i razumevanje. Kao alternativa moe se uraditi grafika prezentacija scenarija to je prikazano
na slici 5. U ovom sluaju sistem je pre i posle scenarija u stanju besposlen.

Na slici 5., s leva na desno u gornjoj grupi pravougaonika je prikazan normalni tok dogaaja. Svaki
pravougaonik prikazuje neku akciju korisnika. Na primer, korisnik se prijavljuje na sistem (Login to
EDDIS), bira komandu naruivanje dokumenta (Select order document), unosi identifikator traenog
dokumenta (Input document reference), potvruje isporuku (Confirm delivery details) i odjavljuje se sa
sistema (Logout from EDDIS).

12/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

Slika 5. Grafiki prikaz scenarija

Strelice na vrhu oznaavaju kontrolu i pokazuju uslove koji moraju biti ispunjeni pre nego to se
kontrola moe preneti na sledei pravougaonik akcija. Na primer, pre nego to se plasira narudbina,
mora se uneti ispravan username i password, korisnik mora imati dozvolu za unoenje narudbine itd.
Ako uslov kontrole nije zadovoljen, ne moe se prei na sledei korak.
Izuzeci koji se mogu pojaviti pri izvrenju akcije su prikazani ispod odgovarajue akcije. U
pravougaonicima za unoenje izuzetaka je u gornjem delu kratko opisan izuzetak a u donjem akcija
koju treba preduzeti. Tako, ako korisnik unese pogrean referentni broj dokumenta, on moe pokuati
da broj ponovo unese ili moe pozvati help sistem koji e mu dati instrukcije kako dati broj treba uneti.
Na izradi scenarija treba da rade zajedno krajnji korisnici i inenjeri koji specificiraju zahteve, pri emu
je zadatak inenjera da sakupe sve napomene o komentarima korisnika, problemima i sugestijama.
Praenjem scenarija, krajnji korisnici simuliraju korienje sistema ukazujui na oblasti u kojima
scenarija nisu korektna, u kojima su pojednostavljena, razliita itd. Inenjeri zahteva mogu da
postavljaju razliita pitanja o akcijama korisnika, nainu na koji se one izvravaju, akterima koji su
ukljueni u izvrenje zadataka, moguim dogaajima u sluaju nekih alternativnih pristupa.
Kako je scenarijima opisana interakcija sistema sa stakeholderima kojom treba objasniti ta se
zapravo deava, izrada scenarija zahteva dosta vremena. Meutim, kada se jednom naprave, oni se
mogu ponovo iskoristiti u drugim sistemima. Zavisno od sloenosti interakcije, izrada scenarija moe
zahtevati 1 do 2 dana. U jednom eksperimentu sa ovom metodom, pronaeno je da se interakcija sa
medicinskim sistemom moe opisati sa 88 scenarija, to znai da je za razvoj scenarija sloenih
sistema potrebno nekoliko meseci. Meutim, za sisteme priblino iste veliine, izbor zahteva
korienjem scenarija ne zahteva znaajno mnogo vie napora nego korienjem drugih pristupa
izbora zahteva.

Sofisticirane sistemske metode

Strukturne metode analize zahteva o kojima e kasnije biti rei, nisu korisne u ranim fazama izbora
zahteva u kojoj treba razumeti aplikativni domen, problem i organizaciju. Strukturne metode se
baziraju na tekom modelu sistema, kao to su modeli objekti veze, dijagrami tokova podataka itd.
Ovi modeli nisu fleksibilni i strogu su fokusirani na automatizovani sistem. Nasuprot tome, lagane
(sofisticirane) sistemske metode se odnose na pravljenje manje formalnih modela celokupnog sociotehnikog sistema. One razmatraju automatizovan sistem, ljude i organizaciju.
Danas je razvijen je veliki broj takvih sofisticiranih metoda ukljuujui SSM, ETHICS, User-Centred
Design approch. Sve one su veoma sadrajne i ovde nee biti detaljno opisane. Ovde e se dati samo
kratak opis SSM metode koja se moe smatrati najpoznatijom od predhodno nabrojanih pristupa.
SSM (Soft Systems Methodology) nije specijalno dizajnirana kao tehnika za izbor zahteva raunarski
baziranih sistema. Ona je pre svega razvijena s namerom da pomogne pri razmiljanju o sistemu
kada treba definisati probleme koji postoje u organizaciji. U irem smislu ona se odnosi se na socio13/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

tehnoloke sisteme u koje su ukljueni ljudi, procedure, politika, hardver, softver itd. Ovako iroka
perspektiva ini ovaj pristup korisnim pri izboru zahteva i neki autori ( Bustard, 1995) opisuju kako se
SSM moe kombinovati sa metodama analize zahteva.
U SSM postoji sedam osnovnih koraka, to je prikazano na slici 6.

Aktivnost metode

Opis

Ocena problema

Obuhvata pronalaenje situacija u kojima postoje problemi. Ova aktivnost se ne

odnosi na opis prethodno definisanih problema ve na potpuno neoptereeno
sagledavanje situacije itave organizacije i pronalaenje onih koji su njome
obuhvaeni, njihovih sagledavanja situacije, postojeih procesa itd.

Opis
problematinih
situacija

Problematina situacija se opisuje korienjem dijagrama koji se nazivaju

bogate slike. Bogate slike su prezentacija organizacije i problematinih
situacija u obliku dijagrama pri ijem se crtanju ne koristi ogranien skup
simbola ve se za opisivanje situacije moe koristiti bilo koja odgovarajua
ikona (ematski crte, logo itd.)

Apstraktna
definicija sistema iz
izabrane take
gledita

Proizvodi se jedna ili vie tzv. korenitih definicija sistema. Korenitih definicija
sistema se proizvodi na osnovu odreene take gledita i moe ukljuivati
informacije o korisnicima koji imaju neke koristi od sistema, actora koji su
obuhvaeni sistemom, transformacijama ulaza u izlaze, pogledima na svet (
World Views) na osnovu kojih su napravljene definicije, ogranienjima sistema
koja su proizala iz okruenja itd.

Konceptualno
modeliranje
sistema

Modeli sistema se prave tako da odgovaraju korenitim definicijama sistema.

To su takozvani modeli ljudski aktivnosti i generalni model kojeg se treba
pridravati pri njihovoj izradi je da se aktivnosti u modelu trebaju bazirati na
glagolima koji su sadrani u korenitim definicijama.

Model/uporeivanje
sa realnim
sistemom

Proizvedeni model se uporeuje sa postojeom situacijom u realnom svetu. Za

svaku aktivnost u konceptualnom modelu se postavlja pitanje da li je ovo
aktivnost iz realnog sveta, kako ona moe biti izmerena

Identifikacija
promene

Na osnovu konceptualnog modela i poreenja model/realni svet identifikuje se

skup moguih promena u postojeem realnom sistemu. To se uzima u obzir
prilikom opisa onoga to je poeljno i izvodljivo u organizaciji.

Preporuke za dalje
akcije

Identifikovane promene se ocenjuju i proizvodi se skup predloenih akcija.

Slika 6. Sedam osnovnih koraka U SSM-u

Osnovno u SSM-u je da on prepoznaje da li je bilo koji sistem uklopljen u iri humani i organizacioni
kontekst. Analizom organizacionog konteksta, problema koje treba reiti i postojeih sistema, ova
metoda obezbeuje nain za razumevanje apstraktnih zahteva sistema To je jedna od prvih metoda
koja je predstavila notaciju taaka gledita (koje se u SSM-u zovu Pogledi na svet World Views)
gde razliite take gledita pruaju razliite percepcije problema i reenja.
SSM i druge sofisticirane metode nisu tehnike za detaljan izbor zahteva. One su efikasne kao metode
za razumevanje problema, organizacije u kojoj ti problemi postoje i ogranienja vezanih za njihovo
reavanje. One su posebno znaajne kada nije jasno koja je vrsti sistema zaista potrebna u
odreenom kontekstu. Proizvode apstraktne zahteve sistema koje treba pojasniti korienjem drugih
tehnika izbora.

Posmatranje i socijalna analiza

U timovima ljudi koji zajedniki rade (kooperiraju) na izvravanju nekih zadataka, vei deo posla se
odnosi na socijalne aktivnosti. Priroda kooperacije je esto sloena i menja se zavisno od ljudi koji u
njoj uestvuju, fizikog okruenja i organizacije u kojoj se posao odvija. Ljudi esto smatraju da je
14/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

veoma teko objasniti kako izvravaju svoje zadatke i kako ih u pojedinim situacijama obavljaju
zajedno. Pri izvrenju zadataka, pojedinci i timovi esto, koristei na krajnje intuitivan nain
raspoloivu dokumentaciju i alate, unapreuju postojei nain rada. Ponekad, oni i ne shvataju ta
zapravo rade. Kada poslovi postanu rutine i ljudi o njima ne razmiljaju svesno, njima je veoma teko
da artikuliu kako zapravo obavljaju svoj posao.
Goguen i Linde su za to dali dobar primer. Oni su ukazali da je veoma teko opisati nain na koji se
vezuju pertle na cipelama, ali da je lako taj proces demonstrirati. Posmatranje je bolji nain za
razumevanje takvih tipova zadataka od direktnog postavljanja pitanja. Zbog toga se posmatranje ljudi
moe smatrati boljim nainom za razumevanje potreba koje treba podrati projektovanim sistemom.
Sociolozi i antropolozi su pre mnogo godina koristili tehnike pasivnog posmatranja kako bi kompletno
i detaljno razumeli pojedine kulture. Pristup koji je poznat kao etnografija podrazumeva da se neko
drutvo ili kultura posmatraju dui period vremena, kako bi se detaljno sagledali sve njeni obiaji.
Teorija koja stoji iza toga da se kultura potpuno moe razumeti kada onaj ko vri posmatranje
postane njen deo, se zasniva na injenici da je detaljno poznavanje prakse odnosno naina na koji se
neto izvrava veoma vano.
Sasvim je razumno grupu radnika koji rade u banci ili kao kontrolore leta posmatrati kao lanove
drutva i za razumevanje njihovih svakodnevnih aktivnosti koristiti etnografsku analizu na osnovu koje
e se proizai zahtevi koje treba podrati raunarskim sistemom. Postoji veliki broj studija iz kojih
jasno proizilazi da se posmatranjem korisnika mogu otkriti zahtevi koji se ne mogu dobiti drugim
tehnikama izbora zahteva.
Etnografska prouavanja, se po svojoj prirodi ne mogu obavljati na osnovu utvrenih formula. Ona
zavise od linosti etnografa, tipa procesa koji se prouava i ljudi koji su obuhvaeni procesom. Da bi
bio efikasan, etnograf mora da bude prihvaen od ljudi koje prouava i sa njima dovoljno blizak kako
bi oni svoje poslove obavljali na nain koji ih obavljaju kao kada on nije tu. Ako to nije sluaj, etnograf
nee biti u stanju da izgradi stvarnu sliku o nainu na koji se poslovi stvarno obavljaju.

Mada se ne moe detaljno definisati nain na koji se obavlja etnografska studija, mogu se dati neke
smernice do kojih se dolo na osnovu dugogodinjeg iskustva u korienju tehnika za razumevanje
zahteva. To su:

1. Treba pretpostaviti da ljudi ije se ponaanje prouava, dobro rade svoj posao i fokusirati se
na aktivnosti koje oni ne obavljaju na standardni nain. One obino ukazuje na efikasnost
njihovog rada koja je proizvod njihovog individualnog iskustva.
2. Veoma je vano dosta vremena provesti na upoznavanju ljudi ije se ponaanje prouava i sa
njima uspostaviti relacije poverenja. Iz tih razloga, etnografiju moe najbolje izvesti neka
eksterna organizacija koja ljude obuhvaene procesom moe lake ubediti da e etnografska
studija biti objektivna, nego to to moe da uradi sam menadment organizacije.
3. Za vreme posmatranja treba detaljno beleiti sve naine na koje se poslovi obavljaju. Te
beleke etnograf treba da kasnije analizira i na osnovu toga izvede zakljuke. Osnova
etnografske analize je da se na osnovu detalja kako ljudi rade moraju sticati nova i sklopiti
potpuna slika.
4. Sa etnografijom se moe efikasno kombinovati open-ended voenje intervjua, ime se ljudi
ohrabruju da govore o svom poslu to je za etnografa veoma bitno.
5. Mada se nain na koji se izvravaju neki poslovi esto moe beleiti na video i audio trakama,
one zahtevaju veoma dugotrajnu kasniju obradu koja moe biti veoma skupa.
6. Da bi se identifikovali kritini elementi u nainu na koji se obavljaju pojedini poslovi, etnograf o
njima mora da razgovara i sa ljudima koji su van procesa.
15/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

Osnovni problem sa etnografijom u kontekstu inenjeringa zahteva je da se ona kao tehnika, ne moe
koristiti za ocenjivanje. Etnografija je razvijena kao tehnika za razumevanje sloenih zajednica a ne
kao tehnika za ocenjivanje naina na koji se neto radi, kako se nain rada moe unaprediti ili podrati
raunarskim sistemom. Zbog toga etnografiju treba koristiti kao podrku prilikom primene drugih
pristupa za izbor zahteva a ne kao samostalnu tehniku. Slika 7. prikazuje kako se etnografska analiza
koristi prilikom inicijalnog razumevanja sistema i aplikacionog domena. Kasniji stupnjevi etnografije se
fokusiraju i usmeravaju na nalaenje odgovora na pitanja koja proizilaze iz razvoja prototipa sistema.

Kao primer kako se etnografijom otkrivaju vani zahtevi sistema, Bentlay (1992) je opisao etnografsku
studiju kontrolora vazdunog saobraaja. On je pronaao da su manuelni poslovi kao to su sortiranje
papira koji opisuju planove letenja vani jer pomau kontrolorima da izgrade mentalnu mapu
vazdunog prostora. Ako bi se oni automatizovali, morao bi se pronai neki alternativni nain koji bi
pomogao kontrolorima da uvrste svoje znanje o avionima u svom sektoru. To je suprotno normalnoj
intuiciji da ljudi ne vole poslove koji se ponavljaju (kao to je sortiranje) i da je to najbolje
automatizovati.

Sastanci

Etnografska
analiza

Fokusirana
etnografija

Prototip
sistema

Izrada prototipa
sistema

Korisniki
eksperiment

Slika 7. Korienje etnografije u izboru zahteva

Etnografija zahteva detaljno beleenje rezultata posmatranja. U praksi je veoma teko za svakog osim
za etnografa da interpretira te beleke, tako da ti podaci imaju ogranieno korienje, posebno ako
postoji potreba da se na njih vratimo poto je etnograf preao na neki drugi posao. Da bi se razreio
taj problem kao mehanizam za organizovanje i struktuiranje etnografskih beleaka se koriste take
gledita o kojima e kasnije biti vie rei. Predlae se da se etnografija prikae iz tri take gledita:
1. Take gledita izvravanja posla
Ona opisuje kontekst i fiziku lokaciju posla kao i nain na koji ljudi koriste objekte da bi
izvravali svoje zadatke. Na primer, pri prouavanju pulta za pruanje pomoi, treba opisati
objekte koje prualac pomoi mora da koristi i nain na koji su oni organizovani.
2. Socijalne i organizacione perspektive
Ona pokuava da obelodani postojee iskustvo u obavljanju posla na nain na koji ga vide oni
koji su njime obuhvaeni. Svaka individua obino posao vidi na razliite naine i ova taka
gledita pokuava da sve te perspektive organizuje i integrie.

16/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

3. Take gledita toka izvrenja posla

Ovom takom gledita je posao predstavljen kao serija radnih aktivnosti sa informacijama koje
se prenose od jedne do druge aktivnosti.

Ovakvim struktuiranjem se u inenjeringu zahteva omoguava veoma korisna upotreba rezultata

etnografije. Meutim, korienje etnografije je jo uvek veoma nesvreno i nije lako inkorporirati je u
sistematski proces inenjeringa zahteva.

Da bi se reio ovaj problem, Holtzblatt i Beyer su razvili tehniku koja se naziva Ispitivanje zavisno od
teksta (Contextual Inquire). To je adaptirani etnografski metod koji se moe primeniti u kratkom
vremenu i sa ogranienim resursima. Bazira se intervjuisanju koje sadri open-ended pitanja,
posmatranju mesta rada i eventualno korienju prototipa koji moe pomoi u izboru zahteva. Ovom

metodom se u proces dizajniranja sistema ukljuuju krajnji korisnici. Prvenstveno se koristi za

dizajniranje interaktivnih sistema u kojima je kritino dizajniranje korisnikog interfejsa. Meutim,
osnovni principi se mogu primeniti i na druge tipove raunarski baziranih sistema.

Ponovna upotreba zahteva

Jedna od preporuka u softverskom inenjeringu jeste da pri razvoju novog sistema treba, to je
mogue vie, koristiti prethodno steena znanja. Dok je ponovno korienje dizajna i koda sistema
lako razumljivo, tee je razumeti ta znai ponovno korienje zahteva. Svakako da su svi sistemi
konceptualno razliiti i da imaju razliit skup stakeholdera, na osnovu ega proizilazi da su zahtevi
sistema razliiti.

Meutim, iako je jasno da neki zahtevi za svaki od sistema moraju biti razliiti, postoji veliki broj
situacija gde je mogue ponovo upotrebiti prethodno specificirani zahtev. Neke od tih situacija su:
1. Kada se zahtevi odnose na obezbeivanje informacija o aplikativnom domenu: mnoge
informacije ne specificiraju funkcionalnost sistema ve se odnose na ogranienja sistema ili
operacije sistema koje proizilaze iz domena aplikacije. Na primer, specifikacija sistema za
zaustavljanje vozova ukljuuje informacije o tome kako masa, brzina i putanja voza utiu na
vreme potrebno za njegovo zaustavljanje. Ove informacije se verovatno mogu primeniti na sve
sisteme koji se odnose na kontrolu i zatitu vozova.
2. Gde se zahtevi odnose na stil prezentacije informacija: one stvaraju oseaj da organizacija
ima konzistentan izgled korisnikih interfejsa svih sistema. U tom sluaju su greke
korisnika, kada on prelazi sa jednog na drugi sistem, mnogo manje verovatne. Zahtevi koji
specificiraju karakteristike korisnikog interfejsa mogu biti vie puta korieni u razliitim
sistemima.
3. Gde zahtevi reflektuju politiku kompanije, kao to je npr. politika zatite. Kada se zahtevi koji
obuhvataju tu politiku razviju za jedan sistem, oni se mogu ponovo koristiti u kasnijim
sistemima. Tako, ako je politika kompanije da sve personalne informacije budu privatne,
zahtevi za enkripcijom mogu biti zajednike za vei broj razliitih sistema.

Za mnoge sisteme, vie od 50% zahteva spadaju u ovu kategoriju, na bazi ega se moe utedeti
znaajna suma novca. Primarni razlog za utedu novca je da je zahtev koji se koristi vie puta ve
analiziran i validiran u drugim sistemima. Mada je potrebno izvriti analizu i validaciju kojima se
proverava da li su ti zahtevi odgovarajui, vreme i napor koji je potreban je mnogo manji nego u
sluaju novih zahteva.
Svakako, opasnost koja postoji prilikom viestrukog korienja zahteva je da, kada se zahtev koristi u
razliitom kontekstu od onoga u kojem je razvijen, mogu nastati neoekivani problemi. Izmeu
17/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

ponovno upotrebljenog zahteva i novog zahteva se moe pojaviti nepredviena interakcija. Kako je
ponovno upotrebljen zahtev ve bio analiziran, zbog vremenskog pritiska ili pritisaka nastalih zbog
ogranienih resursa, prilikom njegove ponove analize ovi problemi se esto ne sagledaju.
Viestruko korienje zahteva je proces koji zavisi od individualnih znanja inenjera zahteva.
Sistematiniji pristup u viestrukom korienju zahteva moe znaiti veu utedu. Postoje mnoge
tehnike koje se koriste pri primeni viestrukog korienja zahteva, mada najvie potencijala u toj
oblasti ima tehnika poznata kao uzorci dizajna (design patterns).

Prototip
Prototip sistema je inicijalna verzija sistema koja je korisnicima raspoloiva u ranom procesu razvoja.
U hardverskim sistemima, prototip se obino razvija da bi se testirao i eksperimentisalo sa dizajnom
sistema. U softverskim sistemima, prototip se ee koristi da bi se pomoglo pri izboru i validaciji
zahteva sistema.

Osnovni zahtev koji prototip treba da zadovolji jeste da se moe brzo razviti kako bi mogao da se
koristi u procesu razvoja. To znai da se u njemu moe zanemariti funkcionalnost sistema, ignorisati
mehanizmi upravljanja i kontrole kvaliteta, da se ne moraju obavezno ispuniti nefunkcionalni zahtevi
kao to su performanse, zatita, pouzdanost itd. Za razvoj prototipa se mogu koristiti iste tehnologije
koje se koriste i za razvoj finalnih sistema.

U ovom predavanju e prvenstveno biti rei o korienju prototipa koji pomau u izboru i analizi
zahteva sistema. Ovi prototipovi se esto nazivaju prototipovi koji se odbacuju (throw-away), obzirom
da se oni odbacuju kada se razvije finalni sistem. Throw-away pristup je suprotan od razvojnog
prototip koji se moe tretirati kao jedan od pristupa razvoja softvera, u kojem se na poetku procesa
razvoja korisnicima stavlja na raspolaganje softver sa ogranienom funkcionalnou. Takav softverski
sistem se tada modifikuje i proiruje sve dok se ne dobije finalni proizvod.

Razlika izmeu throw-away i razvojnog prototip je u sledeem:

Throw-away prototip se pravi s ciljem da pomogne u izboru i razvoju zahteva sistema.

Zahtevi koji se ugrauju u prototip su oni koji korisnicima stvaraju najvie potekoa i koji su
najtei za razumevanje. Zahtevi koji se mogu dobro razumeti nemaju potrebe da budu
implementirani u prototipu.

Razvojni prototip se pravi s ciljem da se korisniku brzo isporui radna verzija sistema. Zahtevi
koje treba podrati inicijalnom verzijom ovakvog prototipa su oni koje je mogue lako razumeti
i kojima se moe isporuiti korisna funkcionalnost krajnjim korisnicima. Zahtevi koje korisnici
loe razumeju se mogu implementirati tek nakon ekstenzivnog korienja prototipa.

Naravno, izmeu ova dva razliita pristupa u izradi prototipa ne postoji jasna podela. Ponekad, zbog
jakih poslovnih razloga, Throw-away prototip softvera se moe ukljuiti u finalni razvoj sistema. To se
esto javlja u sluajevima kada u re-implementaciji prototipa postoje problemi u potovanju termina
isporuke. Meutim, iako to moe proizvesti kratkotrajne dobitke, dugorono predstavlja troak.
Prototipovi su esto loe struktuirani, tako da njihovo ugraivanje u finalni proizvod moe poveati
trokove odravanja i razvoja sistema. Meutim, itav ivotni ciklus razvoja sistema se moe bitno
skratiti i biti relativno kratak.
Principijelna korist razvoja prototipa za vreme izbora zahteva je da on kupcima i krajnjim korisnicima
sistema omoguava da eksperimentiu sa softverom. Korienjem prototipa oni mogu da naue na
koji nain sistem moe podrati njihov rad. Za ljude je teko da zamisle kako e se pisani dokument
zahteva prevesti u izvrni softverski sistem. Korienjem prototipa mogu se demonstrirati zahtevi koji
nisu u potpunosti jasni pa stakeholderi mogu lake otkriti probleme i sugerirati kako se oni mogu
unaprediti.

18/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

Pored toga to slui kao eksperimentalni sistem, razvojem prototipa se za vreme inenjeringa zahteva
mogu postii i druge koristi:

Prototip moe pomoi u utvrivanju ukupne ostvarljivosti i korisnosti sistema pre nego ta se
za njegov razvoj potroi mnogo novaca;

Prototip je jedini efikasan nain za razvoj korisnikog interfejsa. Ako je prototip razvijen kao
deo procesa zahteva, to moe smanjiti kasnije trokove razvoja sistema;

Prototip se moe koristiti i za razvoj sistema za testiranje koji e biti korien kasnije, u
procesu validacije sistema. Izvrni prototip se takoe moe koristiti za back-to-back testiranje
sa finalnim sistemom, gde se istom testu podvrgavaju i prototip i finalni sistem. Ako izlazi nisu
isti, to ukazuje na greku ili na nekonzistentnost softvera;

Implementacija prototipa zahteva paljivo prouavanje zahteva ime se moe ustanovi njihova
nekonzistentnost i nekompletnost.

Naravno, za razvoj prototipa se vezuje mnogo problema i trokova koje treba tretirati kao ustupak za
koristi koje se dobijaju ovim pristupom. To su:

1. Trokovi obuke
Ako kompanija nema iskustva u razvoju prototipa, ljudi koji ga razvijaju moraju biti obueni za
korienje okruenje u kojem se on razvija ili za korienje konkretnih tehnika o kojima je bilo rei.
2. Trokovi razvoja
Oni zavise od tipa sistema za koji se razvija prototip i metode prototipa koja se koristi. U sluaju malih
sistema, za izradu prototipa moe biti potrebno samo nekoliko ovek/dana dok se za razvoj velikih
sistema moe angaovati vie ovek/godina.
3. Prekoraenje rokova zbog razvoja prototipa
U nekim sluajevima, razvoj prototipa moe prouzrokovati prekoraenje rokova; to ne predstavlja
problem ako proizvod koji se isporuuje vie odgovara potrebama korisnika, ili ako je za izradu
prototipa potrebno manje od vremena nego za pronalaenje problema koji se mogu pojaviti kada
prototip ne postoji;
4. Nekompletan prototip
Prototip moe da simulira samo funkcionalnost ili finalni sistem i kao takav da veoma malo pomogne u
odreivanju iznenadnih (neplaniranih) zahteva. On korisnike moe dovesti u zabludu ukoliko oni
smatraju da e sistem kao celina imati iste performanse i pouzdanost kao i prototip. Korisnici svoje
zahteve treba da definiu imajui to u vidu.

Mnoge organizacije smatraju da je vreme koje se troi na razvoj prototipa sistema nije izgubljeno.
Mada su inicijalni trokovi razvoja visoki, postoji vea verovatnoa da e zahtevi reflektovati realne
potrebe korisnika. Takoe se smanjuje potreba i verovatnoa za preradom zahteva, poto se sistem
stavi u upotrebu.

Implementacija prototipa
Prototip mora biti raspoloiv za vreme faze izbora zahteva, to znai da se on mora brzo
implementirati. Dok razvoj konvencionalnih sistema obino traje dosta dugo, u prototipu se moraju
koristiti brze razvojne metode. U sluaju razvoja jednostavnih sistema, kompletna implementacija
moe trajati nekoliko meseci dok je prototip mogue napraviti za samo nekoliko dana.

Za brz razvoj prototipa se mogu koristiti tri mogua pristupa:

1. Papirni prototipu u kojem se razvija model sistema i on koristi za eksperimente.
19/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

2. Prototip arobnjak iz Oza gde jedna osoba, odgovarajui na korisnike ulaze, simulira
odgovore iz sistema.
3. Automatizovani prototip, u kojima se za izvrni prototip koriste jezici etvrte generacije ili
druga brza razvojna okruenja.

Papirni prototip je jeftin i iznenaujue efikasan pristup razvoja prototipa u kojem se ne razvija izvrni
softver. Crtaju se papirnate verzije ekrana koje mogu biti prezentovane krajnjim korisnicima i planiraju
se razliita scenarija. Analitiari i krajnji korisnici radei na scenarijima simuliraju kako se sistem moe
koristiti. Za interaktivne sisteme to je efikasan nain za nalaenje reakcija korisnika na sistem,
informacija koje su njima potrebne i naina na koji oni uspostavljaju normalnu interakciju sa sistemom.
Prototip arobnjak iz Oza je takoe relativno jeftin jer ne zahteva da se razvije mnogo softvera.
Korisnici su u interakciji sa neim to ima ulogu sistema tj. zahtevi korisnika se usmeravaju ka osobi
koja simulira odgovore iz sistema. Ovaj pristup je naroito koristan kada se razvija novi sistem koji
predstavlja proirenje nekog postojeeg sistema. Korisnicima su poznati interfejsi sistema i
simulacijom arobnjak iz Oza oni mogu da sagledaju interakciju koja se odvija izmeu interfejsa i
funkcionalnosti sistema. Jedini softver koji se u tom sluaju trai je softver korisnikih interfejsa. Nije
potrebno razvijati sistem u kojem su podrane sve njegove funkcije.

Razvoj izvrnog prototipa sistema je mnogo skuplja opcija. Njime je obuhvaeno pisanje softvera koji
treba da simulira funkcionalnost sistema koju treba isporuiti. Zbog potrebe za brzim razvojem, za
razvoj prototipa treba koristiti programske jezike visokog nivoa. Postoji nekoliko alternativa:
1. Jezici etvrte generacije koji se baziraju na bazama podataka. Oni su dobri za aplikacije
prototipa koje slue za upravljanje informacijama ali imaju ogranienja u interakciji (npr. oko
baze podataka se ne moe izvesti navigacija korienjem grafike vizualizacije podataka).
2. Vizuelni programski jezici kao to je Visual Basic ili ObjectWorker. To su programski jezici
opte namene koji imaju veoma snano razvojno okruenje, pristup itavom opsegu
rejuzibilnih objekata i sistemima za razvoj korisnikog interfejsa koji omoguavaju brzo
kreiranje interfejsa. Ovi sistemi su fleksibilniji od 4GL-a ali generalno nisu toliko dobri za
aplikacije koje su orijentisane ka bazama podataka.
3. Reenja prototipa bazirana na Internetu koja se oslanjaju na korienje WWW brovsera i
jezika kao to je Java. U ovom sluaju postoje gotovi korisniki interfejsi kojima i
pridruivanjem segmenata Java programa informacijama koje treba prikazati se moe
pridodati funkcionalnost. Ti segmenti (koji se nazivaju apleti) se automatski izvravaju kada se
stranica uita u brovser. Ovaj pristup je brz nain za razvoj korisnikog interfejsa ali postoje
prirodna ogranienja koje namee sam brovser i Java zatitni model.

Interaktivni prototip system je mnogo lake napraviti od prototipa sistema u realnom vremenu. Mnogi
prototipovi sistema nisu pogodni za efikasnu hardversku interakciju tj. njihovim korienjem se ne
mogu pobuditi senzori koji se koriste u gotovom sistemu.

Za neke zahteve se ne moe napraviti prototip, npr. u sluaju itavog sistema zahteva kojima se
odslikavaju neki opti ciljevi kao to su korienje sistema, pouzdanost itd. Generalno, zbog
performansi, efikasnosti pouzdanosti itd. prototip je potpuno drugaiji od gotovog sistema pa se moe
rei da ga treba koristi samo za otkrivanje funkcionalnih zahteva sistema.

Analiza i utvrivanje zahteva

Analiza i utvrivanje zahteva su aktivnosti u kojima treba otkriti eventualne probleme u zahtevima
sistema i postii dogovor oko njihovih promena ime bi se zadovoljili svi stakeholderi sistema. Kada su
u trenutku iskazivanja zahteva problemi oigledni, analiza je povezana sa izborom zahteva. Meutim,
ona se uobiajeno vri poto se napravi inicijalna skica dokumenta zahteva. U toku analize se zahtevi
itaju, istiu problemi koji u njima postoje i vodi diskusija. Oigledno, analiza zahteva ima mnogo
20/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

zajednikog sa validacijom zahteva koja e biti opisana u sledeim predavanjima. Meutim, ipak su to
razliiti procesi. Dok se analiza bavi nekompletnim skupom zahteva o kojima stakeholderi nisu
diskutovali, kao poetna taka u validaciji se koristi kompletan skup zahteva oko kojih je postignut
dogovor.

Analiza i utvrivanje zahteva su skupi procesi koji iziskuju dosta vremena jer zahtevaju da ljudi sa
velikim iskustvom i znanjem dosta vremena provedu itajui dokumentaciju nastalu u procesu izbora
zahteva i razmiljanju o implikacijama reenica koje su u njoj napisane. Svi ljudi ne razmiljaju na isti
nain i razliiti analitiari e procesu pristupiti na razliite naine. Analizu i dogovaranje zahteva nije
mogue izraziti kao struktuiran, semantiki proces. To su procesi koji se zasnivaju na proceni i
iskustvu ljudi koji u njima uestvuju.

Kontrolna lista zahteva

Kontrolna lista je lista pitanja koju analitiar moe da koristi pri oceni svakog zahteva. Prolaskom kroz
dokument zahteva, analitiar treba da proveri svaku od stavki na listi. Kada se otkrije potencijalni
problem, treba ga zabeleiti bilo na margini dokumenta zahteva ili na posebnoj listi o obavljenoj
analizi. Kontrolna lista analize moe biti implementirana kao tabela u kojoj redovi sadre pojedinane
zahteve a kolone stavke iz kontrolne liste. Odgovarajue elije tabele tada treba popunjavati
komentarima o potencijalnim problemima.

Kontrolne liste su korisne jer analitiaru omoguavaju da se podseti ta je analizirao i tako smanji
ansu da neke zahteve zaboravi da prekontrolie. Kontrolna lista analize je organizacioni resurs koji
se razvija sa iskustvom koje se stie tokom procesa zahteva. Pitanja na kontrolnoj listi treba da budu
uoptena a ne ograniena. Ako su pitanja suvie specifina, za mnoge sisteme mogu biti irelevantna.
Slika 8. prikazuje moguu kontrolnu listu analize zahteva.

Stavka kontrolne liste

Opis

Preuranjeni dizajn

Da li u zahtevu ima elemenata preuranjenog dizajna ili informacija o

implementaciji ?

Kombinovani zahtevi

Da li je opisom zahteva obuhvaen samo jedan zahtev ili se on moe

podeliti na nekoliko razliitih zahteva ?

Zahtevi koji nisu neophodni

Da li zahtev slui samo kao kozmetiki dodatak sistemu bez kojeg se

u sutini moe ?

Korienje
hardvera

nestandardnog

Da li zahtev podrazumeva da se mora koristiti nestandardni hardver i

softver ? Da bi se donela takva odluka treba da se poznaje zahtevana
raunarska platforma.

Usklaenost sa poslovnim
ciljevima

Da li je zahtev pri predstavljanju u dokumentu zahteva konzistentan

sa definisanim poslovnim ciljevima ?

Dvosmisleni zahtevi

Da li je zahtev dvosmislen tj. da li se on moe proitati na razliite

naine od strane razliitih ljudi ? ta su mogue interpretacije zahteva
? Dvosmislenost se ne mora obavezno tretirati loom, naroito u
sluajevima kada dizajneru sistema prua neku slobodu. Meutim,
ona mora biti otklonjena na nekom stupnju razvojnog procesa.

Realistinost zahteva

Da li zahtev realistino opisuje tehnologiju koja e se koristiti za

implementaciju sistema ?

Mogunost da se zahtevi
testiraju

Da li zahtevi mogu da se testiraju tj. da li su oni dati na nain na

osnovu kojeg inenjeri testa mogu da generiu test kojim se moe
pokazati da li sistem zadovoljava njihove zahteve ?

21/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

Slika 8. Kontrolna lista analize zahteva

Kontrolna lista ne treba da sadri vie od 20 stavki jer ljudi ne mogu da ih sve dre u glavi in mogu da
zaborave neke od njih. Osim toga, dugake kontrolne liste neminovno znae da su mnoga pitanja
vezana za zahteve irelevantna i da se mogu primeniti na povran nain. Jedini izuzetak od toga su
kritine sistemske aplikacije gde se moe zahtevati posebna detaljna analiza i gde moe postajati
duga potencijalna kontrolna lista koju treba izvriti. U tim sluajevima je prihvatljivo korienje velikog
broja stavki iz kontrolne liste, za koje je potrebno dodatno vreme zbog veoma skupih greaka koje se
mogu pojaviti u specifikacijama.

Matrica interakcije
Vrlo vaan cilj u analizi zahteva je otkrivanje interakcije, konflikata i preklapanja izmeu zahteva. Kao
pomo u tim procesima se konstruie matrica interakcije na osnovu koje se mogu videti mnoge
znaajne informacije. Najjednostavniji nain za pravljenje matrice interakcije je korienje programa za
obradu tabela. U svaku kolonu i red tabele se unosi odgovarajui identifikator zahteva. Svaki od
zahteva se uporeuje sa skupom svih ostalih zahteva a elije tabele popunjavaju na sledei nain:
1. Za zahtev za koji se smatra konfliktnim, u eliju se stavlja 1.
2. Za zahtev za koji se smatra da se preklapa sa drugim zahtevom, u eliju se stavlja 1000.
3. Za zahtev za koji se smatra da je nezavistan, u eliju se stavlja 0.

Ako niste sigurni da li je zahtev konfliktan, treba pretpostaviti da jeste. Ukoliko je napravljena
pretpostavka da konflikt postoji tamo gde ga nema, takav problem se obino moe utvrditi na
jednostavan i jeftin nain; reavanje neotkrivenih konflikata je nasuprot tome mnogo skuplje.

Slika 9. prikazuje jedan primer matrice interakcije gde se uporeuje 6 zahteva.

Zahtev

R1

R2

R3

R4

R5

R6

R1

1000

R2

R3

1000

1000

1000

R4

1000

R5

R6

1000

Slika 9. Matrica interakcije

Iz matrice interakcije prikazanoj na slici 2. se moe videti da se R1 preklapa sa R3 i da je u konkliktu

sa R5 i R6; R2 je nezavistan zahtev; R3 se preklapa sa R1, R4 i R6 itd. Za vreme utvrivanja zahteva
preklapanja i konflikte treba prodiskutovati i reiti.

Prednost korienja numerikih vrednosti za konflikte i preklapanja je da se broj konflikata moe

pronai sumiranjem kolona svakog reda: broj konflikata se dobija kao ostatak deljenja dobijene sume
sa 1000 a broj preklapanja kao rezultat deljenja dobijene sume sa 1000. Kao deo procesa analize,
treba paljivo ispitati sve zahteve koji imaju visoke vrednosti ovih parametara. Veliki broj konflikata ili
preklapanja znai da e bilo koja promena zahteva imati velikog uticaja na ostatak sistema.

22/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

Obzirom da se trai da se svaki zahtev uporedi sa svakim drugim zahtevom u sistemu, matricu
interakcije treba raditi samo kada postoji relativno mali broj zahteva. Gornja granica u broju zahteva je
oko 200.

Utvrivanje zahteva
Svi sloeni sistemi imaju veliki broj stakeholdera i veoma se esto deava da se svi stakeholdri ne
slau oko zahteva sistema kao i da razliitim servisima sistema daju razliite prioritete. Utvrivanje
zahteva podrazumeva diskusiju oko konfliktnih zahteva i pronalaenje kompromisa sa kojima se mogu
sloiti svi stakeholderi. Finalni zahtevi uvek treba da budu kompromis do kojeg se dolazi na osnovu
generalnih potreba organizacije, specifinih zahteva razliitih stakeholdera, ogranienja koja proistiu
iz projektovanja i implementacije i budeta i termin plana koji su utvreni za razvoj sistema.
U principu, utvrivanje zahteva treba da bude ciljani proces. Ocena zahteva treba da se bazira na
tehnikim i organizacionim potrebama ali je u realnost to obino drugaija. Utvrivanje zahteva se
retko vri korienjem samo logikih, tehnikih argumenata. Na njih veliki uticaj imaju sama
organizacija i njena utvrena politika kao i ljudi koji su njome obuhvaeni. Jak uticaj nekih ljudi moe
dovesti do toga da njihovi zahtevi dobiju vei prioritet ili da budu prihvaeni umesto drugih zahteva.
Takoe, neki zahtevi mogu biti blokirani od strane krajnjih korisnika koji ne ele da prihvate promene
koje oni donose.
Veina vremena pri utvrivanju zahteva se provede u reavanju konflikata koji postoje meu
zahtevima. Konflikti se javljaju kada se dva ili vie zahteva koji se odnose na istu stvar iskazuju na
razliite naine. Na primer zahtev menadera organizacije u pogledu nekog distribuiranog sistema
moe biti da samo on ima privilegovan pristup lokalnim podacima. S druge strane, osoblje koje radi na
zatiti podataka moe imati zahtev da privilegovan pristup ima samo administrator sistema.
Uprkos dugogodinjem iskustvu, mnoge organizacije jo uvek ne ostavljaju mnogo vremena za
reavanje konflikata koji postoje u zahtevima. Razlog tome je to se konflikti smatraju nekom vrstom
greke pa nije prihvatljivo planirati greke, odnosno vreme za njihovo uklanjanje. Meutim, konflikti
su prirodni i nepredvidivi. Oni odslikavaju injenicu da razliiti stakeholderi imaju razliite potrebe i
prioritete. Ne moe se proizvesti sistem koji svakog moe zadovoljiti u svemu.
Najefikasniji nain reavanje eventualnih konflikata u zahtevima su sastanci. Sastanku treba da
prisustvuju analitiari koji su otkrili konflikte, preklapanje ili nepostojanje nekih zahteva i stakeholderi
sistema koji mogu pomoi u reavanju problema koji su otkriveni.

Na sastancima treba diskutovati o zahtevima kod kojih identifikovani problemi nisu mogli biti reeni
neformalnim diskusijama izmeu stakeholdera i analitiara. Svaki od zahteva kod kojeg postoji
problem treba da se posebno (individualno) prodiskutuje. Pri tom ne treba poi od predpostavke da
diskusije koje se vode oko jednog zahteva se obavezno mogu primeniti i na druge zahteve koji su sa
njima u vezi.

Sastanak treba voditi na tri nivoa:

1. Na neformalnom nivou, gde se objanjava priroda problema koji se vezuje za zahtev.
2. Na nivo diskusije, gde obuhvaeni stakeholderi diskutuju kako ti problemi mogu biti reeni.
Svim stakeholderima koji su zainteresovani za dati zahtev treba dati mogunost da diskutuju.
Na ovom stupnju se zahtevima mogu dodeliti prioriteti to uesnicima sastanka moe pomoi
da donesu odluku koje zahteve treba eliminisati a koje od njih ukljuiti u specifikaciju finalnog
sistema.
3. Na nivo reavanja, gde se postie dogovor oko akcija koje treba preduzeti u vezi zahteva. Te
akcije mogu biti brisanje zahteva, davanje sugestija za specifinim modifikacijama zahteva ili
pronalaenje novih informacija vezanih za zahtev.
Uesnicima sastanka treba dati kopije rezultata analize (npr. kontrolnu listu zahteva) a samim
sastankom treba da predsedava neko ko nije stakeholder sistema jer e se na taj nain lake
obezbediti da budu razmotreni svi pogledi stakeholdera.
23/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA

IS307 Analiza i logiko projektovanje IS

Predavanje br. 2

24/24
Naziv predavanja: FAZA ANALIZE: IZBOR, ANALIZA I UTVRIVANJE ZAHTEVA