PRIKUPLJANJE SOFTVERSKIH

ZAHTJEVA

Pripremila: doc.dr. Isaković Ines

1
 SYLLABUS
• Pojam IS i IT
• Odnos između realnih i informacionih sistema
• Projektovanje IS
• Uvod u projektovanje i izgradnju IS
• Vrste modela IS
• Definisanje zahtjeva
• Oftverski zahtjevi i njegovi elementi
• Funkcionlni elementi zahtjeva
• Nefunkcionalni elementi zahtjeva
• Korisnički zahtjevi
• Sistemski zahtjevi
• Zahtjevi usmjereni ka interface-u sistema
• Inžinjerstvo zahtjeva
• Studija izvodivosti
• Izlučivanje i analiza zahtjeva 2
• Prikupljanje informacija
• Modeliranje pomoću CASE alata
• Etnografija inžinjerstva zahtjeva
• Proces vezan za zahtjeve
• Rješavanje konflikata
• Karakteristike zahtjeva
• Dvije vrste dokumenata o zahtjevima
• Izrada prototipa zahtjeva
• Dokumentovanje zahtjeva
• Specifikacija zahtjeva
• Upravljanje procesima i mogućnostima praćenja zahtjeva
• Validacija i verifikacija
• Mjerenje zahtjeva
• Izbor tehnike za specifikaciju
• Upravljanje zahtjevima ili upravljanje promjenama
• Dokumentovanje zahtjeva
• Rizici lošeg planiranja i izvođenja procesa inžinjerstva zahtjeva

3
 UVOD
• Početkom 60 godina prošlog stoljeća dolazi do izraženog nesklada u
razvoju hardverskih komponenti i programske podrške (softvera).
Dok hardverske komponente postaju sve snažnije, brže i
raznovrsnije u svojim mogućnostima, razvoj softvera ne može
zadovoljiti narasle zahtjeve za izgradnjom novih, kompleksnijih
programskih rješenja. Javlja se tzv. softverska kriza, koja rezultira
previsokim troškovima razvoja, prekoračenjima rokova predviđenih
za razvoj i, ne rijetko, odustajanjem od daljnjeg razvoja.
• U takvoj situaciji, koja je postajala neodrživa, pojavljuje se nova
disciplina – softversko inženjerstvo (engl. software engineering) čiji
je osnovni cilj rješavanje krize programske podrške. Samu kovanicu
„software engineering“ popularizirao je, tokom Konferencije o
programskom inženjerstvu u Garmischu, Njemačka (1968.) njezin
predsjednik F.L. Bauer. Softversko inženjerstvo je disciplina koja se
bavi svim aspektima proizvodnje programske podrške, od
specifikacije sistema do njegove implementacije i održavanja.

4
• Softversko inženjerstvo se ne bavi samo tehničkim
aspektima izgradnje softverskog sistema, već i pratećim
problemima upravljanja i organizira projekta razvoja
softverskog proizvoda. Podrazumijeva primjenu novih
znanja, alata i metoda u inženjerstvu zahtjeva,
modeliranju, projektiranju, razvoju, testiranju,
implementaciji i održavanju programskih rješenja.
Softversko inženjerstvo se, dakle, bavi modelima,
metodama i alatima koji su nam potrebni da bi na što
jeftiniji način mogli proizvoditi što kvalitetnije softverske
produkte.
• Iako je prošlo nešto više od 40 godina od (zvaničnog)
nastanka i definiranja softwareskog inženjerstvakao
posebne discipline, i značajnog razvoja ovog područja u
zadnjih 20 godina, situacija u oblasti razvoja i primjene
softverskih rješenja još uvijek nije zadovoljavajuća, naprotiv.
Za ilustraciju poslužit će pregled rezultata iz izvještaja
(CHAOS Reports) za period od 1994. – 2009. godine koje
već dugi niz godina izrađuje Standish Group
5
Iako kontraverzni [16] ti izvještaji ipak nude pokazatelje koji daju jednu opću sliku stanja u
oblasti razvoja softverskih projekata. Iz tabele je vidljivo da se stanje u ovoj oblasti,
generalno gledajući, popravlja. 1994. godine je više od polovine projekata (53%) završavalo
potpunim neuspjehom, a svega 16% je bilo uspješnih projekata (završili u planiranom roku,
u okviru planiranog budžeta i na zadovoljstvo korisnika). 2009. godine, pak, „svega“ je
četvrtina propalih projekata, skoro trećina projekata je u potpunosti uspješno realizirana
(32%) i gotovo polovina (44%) je projekata koji su privedeni kraju ali uz „probijanje“
planiranih rokova, višestruko veće troškove od planiranih i smanjen opseg funkcionalnosti
softvera. Daleko od idealnog!

6
• Procesu inženjerstva zahtjeva, detaljno se
opisuju aktivnosti koje čine ovu prvu (i
najznačajniju) fazu šireg proces, procesa
programskog inženjerstva. Prezentirane su
različite metode i tehnike koje inženjerima stoje
na raspolaganju prilikom provođenja aktivnosti
prikupljanja, analize, specificiranja, validacije,
dokumentiranja i upravljanja zahtjevima.
• Mnogobrojnim rizicima koji se javljaju tokom
izvođenja aktivnosti inženjerstava zahtjeva.
Navedeni su neki od rizika, kojih trebaju biti
svjesni, u manjoj ili većoj mjeri, svi zainteresirani
akteri tako složenog projekta kakav je projekt
razvoja softverskog proizvoda.

7
 POJAM INFORMACIONIH SISTEMA

Informacioni sistem (eng. Information System) je sistem u kome se

veze izmedju objekata i veze sistema sa okolinom ostvaruju
razmjenom informacija.

 Prema Organizaciji Inetrnational Federation for

Information Processing – IFIP informacioni sistem
su definirani kao:
„Informacioni sistema prikuplja, pohranjuje, čuva,
obrađuje i isporučuje informacije važne za organizaciju
i društvo, tako da budu dostupne i upotrebljive za
svakog ko ih želi koristiti, uključujući poslovodstvo,
klijente i osoblje.“

8
 POJAM INFORMACIONIH SISTEMA

 Podatka – je opis stvari i događaja s kojim se susrećemo. Oni mogu biti

različitih oblika: numerički, alfanumerički, zvuci, slike i dr. i skladište se u
bazu podataka, organizuju na način da se lako pronalaze.
 Informacije – je podatak bitan za pomoć u izboru nekih aktualnih ili
budućih akcija ili ne-akcija. Najčešće se podaci obrađuju aplikativnim
programima, kako bi se proizvela veća njihova korisnost od one koja se
postiže u slučaju direktnog i jednostavnog pozivanja iz baze podataka.
 Razlika između podatka i informacije
 Važno je napraviti razliku između podatka i informacije, pojmova koji se često
poistovećuju. Na primjer broj 6 je podatak i on kao takav nema posebno značenje,
međutim "Sada je 6 sati" je informacija jer je podatku dodeljeno neko značenje. Tako
možemo uvideti da se informacija sastoji od podatka i značenja koje mu je dodeljeno.

 Znanje, čine podaci ili informacije koji su obrađeni i

organizovani tako da pomažu sticanju iskustva i raznih
ekspertiza koje se mogu primjeniti kod rješavanja određenog
problema. 9
 POJAM INFORMACIONIH SISTEMA

Za pojam informacije se obično vezuju dva objekta: objekat koji

stvara informacije – izvor informacija, i objekat kome su namjenjene
informacije, adresant odnosno potrošač. S obzirom na objeka i
način stvaranja informacije razlikujemo tri osnovne vrste
informacija:
1. Informacije prve vrste – neposredne informacije,
2. Informacije druge vrste – posredne informacije,
3. Pragmatične informacije.

10
 POJAM INFORMACIONIH SISTEMA

Prvu vrstu informacija čine one informacije koje korisnik prima direktno iz okoline,
odnosno direktno sa mjesta nastanka (izvora) informacije.

Drugu vrstu informacija čine informacije koje primamo posredstvom drugih ljudi, knjige,
radija, televizije itd. To su informacije koje je neko drugi sticao iz objektivne
stvarnosti. Ako nam neko drugi saopštava informaciju o stvarnosti, onda je to
njegov stav o toj stvarnosti, odnosno njegova idealizovana slika te stvarnosti.

Pragmatičnom informacijom nazivamo one vrste informacija koje se grade na osnovu

već stečenog iskustva i novoprimljenih informacija bilo posrednim ili
neposrednim putem. Novoprimljene informacije se prerađuju sa posjedovanim
informacijama i na taj način se stvaraju nove izvedene tj. pragmatične informacije.
Značaj pragmatične informacije se ocjenjuje na osnovu efekta koga ona proizvodi
na ponašanje primaoca – korisnika informacije.

11
 POJAM INFORMACIONIH SISTEMA

Informacioni sistem je podsistem poslovnog sistema. Sačinjavaju ga ulazni

podaci i izlazne informacije, procesi (obrada podataka o stanjima
stvarnog sistema) i izvršioci (osobe, programi, računari).

Poslovne sisteme sačinjavaju materijalni ulazi i izlazi (sirovine, energija,

proizvodi) i informacioni tokovi (poruke, dokumenti). Ulaz u neki poslovni
sistem predstavlja izlaz iz nekog drugog poslovnog sistema.

Poslovni sistemi sadrže procese (npr. obrada, prerada, proizvodnja), povratne

veze (npr. Poređenje plana i realizacije), skladišta podataka (informacija),
izvršioce (osobe, mašine, alati, sirovine), skladišta materijala

12
 POJAM INFORMACIONIH SISTEMA

Funkcije informacionog sistema mogu se sintetizovati na dvije osnovne

funkcije:
1. funkciju informisanja i
2. funkciju dokumentovanja.

13
 POJAM INFORMACIONIH SISTEMA

Funkcija informisanja ima cilj da upravljanje i poslovno odlučivanje učini

što efikasnijim. Naime, informacioni sistem svojim funkcionisanjem
osigurava relevantne informacije (tačne, pravovremene i na pravu
adresu upućene) za operativno i razvojno upravljanje poslovnim
sistemom i njegovim podsistemima.

Funkcija dokumentovanja stvara mogućnost da se konstantno prati

poslovanje i vrši razmjena informacija sa drugim privrednim i
društvenim podsistemima (npr. banke, Zavod za statistiku,
poslovni partneri itd.).

14
 POJAM INFORMACIONIH SISTEMA

Informacioni sistemi se klasifikuju prema različitim kriterijumima kao što su:

primijenjena tehnologija, stepen složenosti, područje primjene, itd. Kada su
informacioni sistemi zasnovani na ručnoj ili mehanografskoj obradi
podataka, bez podrške kompjutera, onda govorimo o konvencionalnim
informacionim sistemima.
Ova vrsta informacionih sistema karakteristična je za poslove koji ne zhtijevaju
stalnu ažurnost i masovnu obradu podataka. Obično se primjenjuju u
manjim organizacijama. Ipak, kako većina organizacija, odnosno poslovnih
sistema djeluje u složenim i dinamičnim uslovima poslovanja, za njihovo
upravljanje i poslovno odlučivanje potrebne su pravovremene, potpune i
kvalitetno obrađene informacije. Takve informacije mogu se dobiti jedino
primjenom savremene informacione tehnologije. Za razliku od
konvencionalnih, takve sisteme nazivamo kompjuterizovanim
informacionim sistemima.

15
 Zahtjevi savremenog poslovanja

Poslovni
procesi
Poslovanje Menadžment Plasman
Informacija - Znanje - Odluka - Akcija - Rezultat

 Pristup SVIM relevantnim strukturama podataka

 Prezentacija konkretnih sintetičkih informacija
 Donošenje odluke uz saznanje o uzrocima i posljedicama
 Trenutno raspoložive analize
16
 Zašto je danas teško dobiti
kvalitetne izvještaje?
Zato što to podrazumijeva:
• Analizu velike količine sirovih podataka,
• Dugotrajno je,
• Komplikovano za upotrebu i prikazivanje,
• Potrebna je uključenost informatičara,
• Teško je izvodljivo za operativni sistem,
• Rezultat - više verzija istine.

"Analiza-Paraliza!" 17
 Analitički IS –
On-line Analytical Processing (OLAP) analiza i obrada
podataka, izrada izvještaja

Transakciona
BP

Ostali OLAP
interni
podaci Server

Eksterni
izvori
podataka E.F. Codd : 1993
18
 INFORMACIONE TEHNOLOGIJE U PREDUZEĆU

Ključni faktori za uspješno preduzeće su:

 INFORMACIJE
 ZNANJE
 INOVATIVNOST
 KREATIVNOST

Uslov za upotrebu informacija, znanja,

inovacija i kreativnosti su informacione
tehnologije

19

11/6/2019 11:53 PM
 INFORMACIONI SISTEMI-IS
ŠTA JE IS?

Šta je ....
sistem? - sistem je skup međusobno
povezanih objekata
objekat? - fizički objekat, koncept, događaj ili
bilo kakav entitet
entitet? - posebnost koja se jasno razlikuje od
drugih objekata
20

11/6/2019 11:53 PM
  Svaka organizacija ima neki IS koji čine:
 ljudi,
 procedure ili
 objekti,
 a računarska tehnologija ne mora da bude
najvažniji element sistema.
 Informacioni sistem je skup međusobno
povezanih elemenata koji rade zajedno, sa
ciljem:
 prikupljanja,
 pohranjivanja,
 čuvanja
 obrade i
 distribucije informacija
 da bi podržali analizu, odlučivanje u organizaciji 21

11/6/2019 11:53 PM
  Zavisno od uzajamnog odnosa ulaznih (U) i izlaznih (I)
veličina informacioni sistemi mogu biti:
U>I – upravljani IS
U=I – neutralni IS
U<I – upravljački IS

 U praksi su najvažniji upravljači IS jer omogućavaju bazu za

upravljanje i donošenje odluka u organizaciji
 Za IS se još može reci da služi za sakupljanje, obradu,
čuvanje i prenošenje informacija
  Informacioni sistem je sastavni dio
organizacije, odraz realnog sistema

OBRADA
ULAZ (U) IZLAZ (I)
PROCES
PODACI INFORMACIJA

 Transakcioni IS pripada operativnom nivou

i podržava odvijanje tekućih poslovnih
procesa
 Poslovni IS predstavlja niz aktivnosti kojima
se ostvaruje neki cilj
23

11/6/2019 11:53 PM
 Spektar poslovnih podataka

Proizvodi ANALITIČKI IS
Tehnologija
Sirovine Strateško
Finansije upravljanje
Marketing
 Izvještaji
 Odluke
 Prognoze
TRANSAKCIONI IS
Operativno upravljanje
Dokumentacija
Pregledi
Transakcioni sistem Planovi
Troškovi
24
 ODNOS IZMEĐU REALNIH I INFORMACIONIH
SISTEMA

25

11/6/2019 11:53 PM
 Informacioni sistem nastaje
preslikavanjem realnog sistema
Realne sisteme možemo posmatrati kao
čvrste i meke realne sisteme.
 Čvrsti realni sistemi garantuju da će se svi važni poslovi i
procesi obaviti na vrijeme.
 Meki realni sistemi su manje zahtjevni, oni obezbjeđuju
dvije klase procesa, a to su obični procesi i procesi u
realnom vremenu koji imaju apsolutni prioritet.

26

11/6/2019 11:53 PM
UVOD U PROJEKTOVANJE I IZGRADNJU
INFORMACIONOG SISTEMA
• Fizički i logički model postojećeg IS, a zatim logički i
fizički model budućeg IS, izrađuje se na osnovu
poslovnih zahtjeva i zahtjeva krajnjih korisnika. Fizički
model (ugradni, implementacioni, tehnički) opisuje
kako je sistem fizički i tehnički izgrađen, te ko, gdje i
kada nešto radi. Logički model (esencijalni,
konceptualni, poslovni) opisuje šta je sistem, šta radi,
šta su podaci. Operativni (budući fizički) sistem
prikazuje šta, ko i kada, ali ne i gdje radi, a prema
potrebi može se razmatrati organizacijski nivo, odnosno
različito značenje podataka zavisno od područja unutar
poslovnog sistema i okruženja.

27
 VRSTE MODELA INFORMACIONOG
SISTEMA
• Model podataka opisuje ŠTA su podaci, odnosno ŠTA opisuju podaci.
Konceptualni model opisuje podatke i veze između podataka. Najčešći
konceptualni model je model entiteti-veze. Logički model opisuje strukturu
podataka i logičkih datoteka, a najčešći logički model je relacioni model
podataka.
• Model funkcija i procesa opisuje KAKO se prikupljaju, obrađuju i
distribuiraju podaci. Model funkcija se oblikuje razlaganjem
(dekompozicijom) funkcija, iterativno od vrha prema dolje (od globalnih
funkcija do osnovnih procesa). Model procesa opisuje obradu podataka
posmatranog sistema. Najčešći model procesa je dijagram toka podataka.
• Model događaja opisuje KADA se podaci obrađuju, odnosno razmatra
učinke koje događaji imaju na procese i podatke, te vrši opis stanja. Kao
primjer se može navesti dijagram promjene stanja.
• Model resursa/sredstava opisuje izvršioce, odnosno KO obrađuje podatke,
GDJE se podaci nalaze i GDJE se podaci obrađuju.
• Modeliranje programa podrazumjeva predstavljanje struktura
programskih modula informacionog sistema.

28
 Programska potpora i softversko
inženjerstvo
• softversko inženjerstvo razlikuje se od programiranja
odnosno kodiranja. Dok je kodiranje proces pisanja
programskog koda u nekom određenom programskom
jeziku, a programiranje prije svega mentalni proces
predstavljanja i implementacije određenog algoritma
najprije u simboličnom obliku (npr. pseudokodu) a potom
kodiranjem, softversko inženjerstvo obuhvaća mnogo širi
proces razvoja programa.
• Prije nego što se objasni što se podrazumijeva pod
softverskim inženjerstvom i koji je njegov značaj i prije nego
što se definira sam pojam, najprije je potrebno pojasniti što
je to programska potpora ili software.
29
• Definicija - Programska potpora (engl. software) ili
računalni program je neopipljiva komponenta
računala koja uključuje sve podkomponente nužne za
uspješno izvođenje računalnih instrukcija.
Programska potpora može uključivati izvršne
datoteke, skripte, knjižnice i druge podkomponente.
• Software mogu se razvijati za ciljanog kupca prema
njegovim zahtjevima, za skupinu kupaca (npr.
proračunske tablice za mobitele upravljane
određenim operacijskim sistemom) ili oni generički,
namjenjeni općem tržištu (engl. COTS - Commercial
Off TheShelf).

30
• Programski proizvod (engl. application) ili programski sistem
(engl. software system) sastoji se od jednog ili više software. On
se može izraditi oblikovanjem novih računalnih programa,
(re)konfiguracijom postojećih programa, ili ponovnom
uporabom postojećih komponenata programa.
• U okviru programskog inženjerstva, pojam software u širem
smislu uključuje i dokumentaciju (engl. documentation).
• Dokumentacija je pisani tekst u obliku jednog ili više
dokumenata koji objašanjava kako radi programska potpora
(software), koji su zahtjevi na rad programske potpore ili kako se
ona treba pravilno koristiti. Dokumentacija programske potpore
ima za cilj pružiti razne informacije o programskoj potpori raznim
ljudima, u ovisnosti o ulozi koju oni imaju u odnosu na
programski sistem. Primjeri cjelokupnih projektnih
dokumentacija ostvareni na kolegiju

31
• Definicija - softversko inženjerstvo (engl. software engineering)
je tehnička disciplina koja se bavi metodama i alatima za
profesionalno oblikovanje i proizvodnju software-a uzimajući u
obzir cjenovnu efikasnost.
• Potrebno je naglasiti da softversko inženjerstvo nije računarska
znanost (engl. Computer science). Računarska znanost bavi se
temeljima koji su nužni da bi se suštinski razumjeli problemi s
kojima se programski inženjeri susreću u svakodnevnom radu,
dok je softversko inženjerstvo orijentirano na praksu i rješavanje
problema klijenata. Razlika između ta dva pojma predočena je
na slici
• softversko inženjerstvo predstavlja sponu između cjelokupne
teorije pokrivene računarskom znanošću i svakodnevnog svijeta
u kojem se traže isplativa i učinkovita programska rješenja s
kojima će raditi krajnji korisnici. Oni ne moraju znati niti kako je
napravljena programska potpora, a još manje koja je teorija sve
bila potrebna kako bi se neki programski proizvod ostvario.
32
33
• Područje blisko području softwareskom inženjerstva
je inženjerstvo računalnih sistema (engl. computer
system engineering) ili kraće, računalno inženjerstvo
(engl. computer engineering).

34
• Definicija - Računalno inženjerstvo je širi pojam od
softwareskog inženjerstva budući da se to područje bavi
svim aspektima sistema zasnovanima na računalima
(inženjerstvo sklopovlja, softversko inženjerstvo i
inženjerstvo procesa). softversko inženjerstvo, kao dio
inženjerstva računalnih sistema, usredotočeno je na razvoj
programske infrastrukture i na upravljanje, primjenu i
rukovanjem podacima u računalnom sistemu.
• Inženjeri računalnih sistema su često uključeni u
specificiranje sistema, oblikovanje arhitekture, integraciju
sistema i postavljanje u korisničko okruženje. U okviru
kolegija
• Oblikovanje programske potpore bit ćemo usredotočeni na
softversko inženjerstvo, dok se ostala potpodručja
računalnog inženjerstva obrađuju tek povremeno.
35
 Temeljna pitanja softwaresko
inženjerstva
• S čime se softversko inženjerstvo sve bavi, odnosno koja su
to područja koja ono obrađuje? Na sljedećem popisu dan je
pregled nekih temeljnih pitanja koja zanimaju softversko
inženjerstvo. Ovaj popis nije iscrpan, ali pokriva većinu
pitanja koja će nas dalje zanimati.
• 1) Što je to i kako izgleda proces programskog inženjerstva?
• 2) Što je to i koji su sve modeli procesa programskog inženjerstva?
• 3) Što su to metode programskog inženjerstva?
• 4) Što je to CASE (engl. computer-aided software engineering)?
• 5) Koje su značajke dobrog programskog proizvoda?
• 6) Kakva je struktura cijene (troška) u programskom inženjerstvu?
• 7) Koje su osnovne poteškoće i izazovi u programskom inženjerstvu?
• 8) Koje vrste programskih projekata postoje i koje su njihove značajke?
• 9) Što je to profesionalna i etička odgovornost u programskom
inženjerstvu?

36
• Definicija - Proces softwareskog inženjerstva je skup
aktivnosti čiji cilj je razvoj i evolucija aplikacije. U tom
procesu bitnu komponentu čini timski rad pomoću kojeg se
učinkovito izgrađuje aplikacija. Proces softwareskog
inženjerstvaje stvarni tijek aktivnosti koji se odvija tijekom
izrade aplikacije.
• Svaki proces softwareskog inženjerstvasastoji se od četiri
temeljne generičke aktivnosti:
– specifikacije,
– oblikovanja i implementacije,
– validacije i verifikacije,
– evolucije programske potpore.

37
• Definicija - Model procesa softwareskog
inženjerstva je pojednostavljeno
predstavljanje procesa softwareskog
inženjerstva iz određene perspektive (pogleda
na proces). Postoji više predloženih modela
koji nastoje jasnije predstaviti stvarni proces
programskog inženjerstva: vodopadni,
evolucijski, komponentni, modelno-
usmjereni razvoj, agilni razvoj.
• Perspektive pogleda na proces mogu
uključivati: uloge i akcije - tko šta čini, tok
podataka, tok aktivnosti, itd.

38
 Metode softwareskog inženjerstva
• Metode softwareskog inženjerstvasu organizirani
pristupi povezivanju aktivnosti u oblikovanju i
implementaciji programske potpore. Metode uključuju:
• izbor modela sistema (npr. objektni model, model toka podataka,
model stroja s konačnim brojem stanja),
• notacije (označavanja) modela,
• pravila koje vrijede u cijelom sistemu (npr. svaki entitet u modelu
sistema mora imati svoj naziv),
• preporuke dobre inženjerske prakse pri oblikovanju (npr. jedan
razred bi idealno trebao imati samo jednu odgovornost za koju je
zadužen) i
• smjernice pri opisu procesu (npr. najprije dokumentirati atribute
razreda, potom metode).

39
 Poteškoće i izazovi u softwareskog
inženjerstvu
• Prilikom razvoja software-a pojavljuju se razne poteškoće i izazovi. Promatraju se obično
oni najčešći, odnosno karakteristični za sve procese programskog inženjerstva. To su
poglavito heterogenost razvoja, ograničeno vrijeme isporuke, povećanje pouzdanosti,
česte izmjene zahtjeva i složenost razvijenog programskog sistema.
• Heterogenost razvoja znači da postoje različite tehnike i metode razvoja software-a za
različite platforme i okoline izvođenje. Koju je tehniku i metodu najbolje za odabrati za
dani problem stvar je iskustva. Ograničeno vrijeme isporuke je često diktirano od strane
vodstva projekta na temelju zahtjeva klijenta. Potrebno je osigurati što kraći interval od
zamisli do stavljanja gotovog, prihvatljivog programskog proizvoda u proizvodnju,
odnosno na tržište. Povećanje pouzdanosti sistema ostvaruje se iscrpnim i
automatiziranim načinima ispitivanja kao i uporabom matematičkih, formalnih metoda
dokaza u pojedinim slučajevima. Česte izmjene sistema karakteristične su za poslovne
projekte u novije vrijeme, gdje je korisnik postao zahtjevniji i ažurniji. Kako reagirati na
iznenadne promjene zahtjeva korisnika stvar je često inicijalnog dogovora
između vodstva projekta i klijenta, ali inženjeri se čestu nađu u situaciji da
moraju napraviti puno izmjena u kratkom vremenskom periodu. Složenost
programskog sistema ne mora biti problem ako je arhitektura dobro osmišljena i ako je
korištena dobra inženjerska praksa u oblikovanju i implementaciji.
40
 2

Uvod (1)
 analiza zahtjeva je prvi, vrlo složen korak u procesu razvoja softvera

 skup zahtjeva je rezultat intenzivne saradnje sa naručiocima u cilju

razumjevanja njihovih osnovnih problema i potreba

 ishod cijelog projekta mnogo zavisi od rezultata analize

Grupa Standish, 19
35% projekata otkazano
8000 softvers projekata
u 350 kompanija 9% projekata isporučeno na
vrijeme i u okviru budžeta

Glavni razlozi
 nedovoljno dobro definisani zahtjevi Problemi
• loše definisani zahtjevi
 nedovoljno dobro upravljanje zahtjevima
•nije moguće na početku
definisati potpun skup zahtjeva
 3

Uvod (2)
Cijena otkrivanja i otklanjanja iste greške
(Boehm & Papaccio, 1998.g.)

Analiza
zahtjeva Projektovanje Kodiranje Održavanje

X 5 10X 200X
Na analizu zahjteva utiče razlog zbog koga se softver pravi:

 automatizacija poslova koji su se ranije obavljali ručno (elektronsko plaćanje,

elektronsko naručivanje,...)

 proširivanje ili poboljšanje postojećeg sistema (nove telefonske usluge, novi

načini kreditiranja,...)

 izrada novog sistema koji obavlja posao koji do tada nije bio rađen (doziranje
leka, SCADA,...)
 4

Zahtjevi (1)
Zahtjev je izraz željenog ponašanja softvera.

Cilj analize zahtjeva:

precizno utvrđivanje ponašanja koje naručilac očekuje od softvera
(ne vodeći računa o realizaciji)
Zahtjevi

 identifikuju objekte i entitete u sistemu (“Radnik je osoba koja radi u kompaniji.”)

 definišu ograničenja za pojedine entitete (“Radnik ne može biti plaćen više od

40 sati nedeljno.”)

 opisuju odnose između entiteta (“Radnika X nadgleda radnik Y, ukoliko je Y

ovlašćen da izmeni zaradu koju prima X.”)

 pokazuju način interakcije sistema sa okruženjem

 5

Zahtjevi (2)

Primjer: softver za obračun plata

Zahtjevi:

1. svakog meseca se štampaju liste sa obračunom zarade za svakog

radnika
2. radnici koji se po no isti mogu dobiti stimulacije

3. svakom radniku ostaviti mogućnost korišćenja godišnjeg odmora

4. sistemu se može pristupati sa više lokacija u kompaniji

5. .....
 Inženjerstvo zahtjeva
• Inženjerstvo zahtjeva je proces izrade
specifikacije software-a. To je prva generička
aktivnost tijekom svakog procesa programskog
inženjerstva. Zahtjevi opisuju što programski
sistem treba raditi kao i ograničenja u njegovom
radu. U procesu izrade specifikacije software-a
postoje postupci pronalaženja, analiziranja,
dokumentiranja i provjere funkcija i ograničenja u
uporabi. Zahtjevi sami za sebe su kraći ili duži
dokumenti koji specificiraju usluge sistema i
ograničenja u uporabi.

45
 Višedimenzijska klasifikacija zahtjeva
• Pojam zahtjeva ne koristi se konzistentno u industrijskoj primjeni. Negdje
su zahtjevi apstraktne izjave o usluzi koju bi programski sistem trebao
ponuditi ili o njegovim ograničenjima. Drugdje se tu podrazumijeva
detaljna, često formalna definicija funkcije programskog proizvoda.
• Zašto dolazi do takvih razlika u shvaćanju zahtjeva možda najbolje ilustrira
primjer.
• Primjer - Ako neka tvrtka želi ponuditi natječaj o izradi velikog, složenog
programskog projekta na otvoreno tržište, tada ona nudi apstraktnu
specifikaciju koja u najopćenitijim crtama opisuje funkciju konačnog
programskog proizvoda. Tada se na natječaj javljaju ponuđači koji predlažu
načine na koje će riješiti zadani problem. Nakon što pregleda prijedloge
ponuđača, tvrtka odabire izvođača projekta. Zatim taj izvođač piše
detaljniju specifikaciju sistema koju tvrtka vrednuje prije nego što se
potpisuje ugovor i kreće u izradu projekta.
• Obje vrste specifikacije, i ona apstraktna, i ona detaljnija, smatraju se
specifikacijom zahtjeva. 46
 Podjela zahtjeva prema razini detalja
• Mnogi projekti zapadnu u probleme kad se razine zahtjeva
međusobno miješaju. Upravo stoga je vrlo bitno klasificirati
zahtjeve prema razini detalja i prema sadržaju. Tako se
prema razini detalja razlikuju:
• Korisničke zahtjeve (engl. user requirements)
• Zahtjeve sistema (engl. system requirements)
• Specifikaciju programske potpore (engl. software specification)
• Korisnički zahtjevi su oni zahtjevi najviše razine apstrakcije.
Njih najčešće zadaje korisnik i to uglavnom u neformalnom,
nestrukturiranom obliku. Tako se oni pišu u prirodnom
jezikui crtaju jednostavnim grafičkim dijagramima. Često iz
njih nije jasno kako će točno sistem funkcionirati niti koji će
biti njegovi dijelovi. Korisnički zahtjevi obično dolaze u
okviru ponude za izradu programskog produkta, kao u
prethodno primjeru
47
48
• Zahtjevi sistema su vrlo detaljna specifikacija o funkcionalnosti i
ograničenjima software. Pišu se strukturiranim prirodnim jezikom,
posebnim jezicima za oblikovanje sistema, dijagramima i
matematičkom notacijom. Može se primijetiti da su zahtjevi
sistema mnogo detaljniji u svojoj razradi funkcionalnosti i
ograničenja od korisničkih zahtjeva. Za razliku od korisničkih
zahtjeva koji se ne zamaraju načinom izvedbe funkcionalnosti,
zahtjevi sistema definiraju što programski proizvod treba raditi na
način da se iz tako strukturiranih zahtjeva već nazire njegova buduća
arhitektura.
• Specifikacija software je najdetaljniji opis i objedinjuje korisničke
zahtjeve i zahtjeve sistema. Ona također može dodatno obuhvaćati
tehničku specifikaciju koja opisuje detaljne zahtjeve na arhitekturu i
programske dijelove.
• Svaku razinu zahtjeva čitaju i dorađuju različiti stakeholderi (slika)
na programskom projektu. U tablici predočen je opis toga koji
stakeholder čita ili dorađuje zahtjeve, ovisno o razini detalja.

49
50
 DEFINISANJE ZAHTJEVA ZA IS
• Ključne aktivnosti, koje se mogu izdvojiti u
definisanju zahtjeva za informacionim
sistemom su:
– prikupljanje informacija,
– prikupljanje podataka i
– ustanovljavanje činjenica.

51
 10

Vrste zahtjeva
 funkcionalni zahjtevi (opisuju ponašanje sistema – šta sistem treba da
radi, koje usluge pruža, kakav je format ulaznih i izlaznih podataka,
kako sistem reaguje na neki ulazni podatak, kako se mjenja
ponašanje u vremenu)

 zahtevi u pogledu kvaliteta (opisuju osobine koje softver treba da

ima da bi bio prihvatljiv sa stanovišta kvaliteta)

 projektna ograničenja (ograničenja nastala kao posljedica donijetih

odluka na projektu – na pr. zbog izbora neke platforme)

 procesna ograničenja (odnose se na tehnike i resurse koji će biti

korišćeni u izgradnji sistema – osoblje, materijali, metode
modelovanja,...)
 11

Zahtjevi u pogledu kvaliteta

 performanse sistema (vrijeme izvršenja, vrijeme odziva, protok
podataka,...)

 upotrebljivost sistema (lakoća korišćenja, moguće vrste obuke,

mogućnost neadekvatne upotrebe,...

 bezbednost sistema (kontrola pristupa, šifrovanje, fizička

bezbednost,...)
 pouzdanost i raspoloživost sistema (detekcija grešaka, srednje vrijeme
između otkaza, vrijeme oporavka, pamćenje kopija podataka,...)

 održavanje sistema (ispravljanje grešaka, lakoća izvođenja izmjena,

mogućnost većih izmjena, mogućnost prelaska na novu platformu,...)

 preciznost i tačnost podataka

 12

Projektna ograničenja

 fizičko okruženje (lociranje opreme, potrebni atmosferski radni

uslovi, napajanje, klimatizacija,...)

 povezivanje sistema sa okolinom (format ulaznih i izlaznih

podataka, interakcija sa drugim sistemima, način preuzimanja i
slanja podataka,...)

 implementacija (izbor platforme, izbor programskog jezika,

korišćene tehnologije,...)
 13

Razrešavanje konflikata (1)

 različiti subjekti na projektu mogu da imaju različita mišljenja o zahtjevima koje
sistem treba da ispuni, pa se mora definisati mehanizam za razrješenje ovakvih
konflikata

 da bi konflikt bio lakše rješen, od naručioca se zahjteva da definiše prioritete

zahtjeva
Vrste zahtjeva prema prioritetima

 suštinski – moraju da budu ispunjeni u konačnoj verziji softvera

 poželjni – nije neophodno da budu ispunjeni, ali bi bilo dobro

 opcioni – mogu se ispuniti, ali se mogu i izostaviti iz konačne verzije

Primjer: obračun plata

suštinski – obračun iznosa koji treba da bude isplaćen radniku
poželjni – razlaganje obračunatog iznosa na stavke
opcioni – štampanje platne liste u crnoj, sa naglašenim detaljima u crvenoj boji
 14

Razrešavanje konflikata (2)

 najčešće su u konfliktu zahtjevi po pitanju kvaliteta (na pr. prilagođavanje
sistema za efikasan rad na jednoj platformi ugrožava njegovu prenosivost,
lako održavanje se postiže razdvajanjem nadležnosti, što daje duže vreme
odziva)

 ako se konflikt ne može rješiti pomoću prioriteta, prelazi se na

pregovaranje i ponovno ocjenjivanje različitih pogleda

 pregovaranje zahtjeva strpljenje, toleranciju i iskustvo

 treba utvrditi razloge nepopustljivosti i o njima obavjestiti sve subjekte; tako

će jedni shvatiti probleme drugih i proceniti da li su oni veći ili manji od
njihovih sopstvenih

 na kraju dobro vođenog pregovaranja, obično se dobije rješenje prihvatljivo

za sve
 SOFTVERSKI ZAHTJEV I NJEGOVI
ELEMENTI
• Pod pojmom softverski zahtjev podrazumijeva se opis usluga
(servisa), manje i/ili više detaljan, koje sistem treba pružiti, kao i
opis definiranih operativnih ograničenja. Softverski zahtjev
reflektira potrebe kupca za sistemom koji će riješiti neki njegov
problem, zbog kojeg se razvija novi sistem ili modificira postojeći.
• IEEE standard definira zahtjev kao:
• Uvjet ili sposobnost koju korisnik treba da bi riješio problem ili ostvario cilj.
• Uvjet ili sposobnost koju mora posjedovati sistem ili komponenta sistema da
bi zadovoljila ugovor, standard, specifikacije ili neki drugi ugovoreni element.
• Dokumentiranu reprezentaciju uvjeta ili mogućnosti definiranih pod (1) i (2).
• Softverski zahtjev nije jednostavno definirati, naprotiv. Svaki
softverski zahtjev ima više elemenata, odnosno sačinjavaju ga
različite vrste zahtjeva iz različitih izvora (stakeholders – interesne
strane). Najčešća podjela je na funkcionalne i nefunkcionalne
elemente softverskog zahtjeva.
• Također razlikujemo korisničke elemente zahtjeva, sistemske
elemente (zahtjeve), i elemente softverskog zahtjeva usmjerene
ka sučelju (interfejsu) sistema. 57
 Podjela zahtjeva prema sadržaju
• Prema sadržaju, zahtjeve se može podijeliti na:
• funkcionalne zahtjeve (engl. functional requirements),
• nefunkcionalne ili ostale zahtjeve (engl. non-
functional, other requirements),
• zahtjeve domene primjene (engl. domain
requirements).

58
 FUNKCIONALNI ELEMENTI ZAHTJEVA
• Funkcionalni elementi softverskog zahtjeva definiraju softversku
funkcionalnost (operacije koje će sistem moći izvršavati i očekivano
ponašanje) koju treba ugraditi u softverski proizvod kako bi korisnicima
omogućio obavljanje njihovih zadataka. Funkcionalni elementi zahtjeva
odnose se na opisivanje funkcija sistema, usluga koje bi on trebao pružati,
izlaza koje sistem treba generirati za zadane ulaze (inpute) i ponašanja
sistema u pojedinim situacijama.
• Ovdje se definira ŠTO će sistem raditi i vrlo je značajno da funkcionalni
elementi zahtjeva budu što preciznije određeni na samom početku razvoja
softverskog proizvoda.
• U principu, funkcionalni zahtjevi trebaju biti kompletni i konzistentni, a to
nije uvijek moguće ostvariti, naprotiv. Naime, u definiranju zahtjeva se
javljaju različiti izvori (stakeholderi – zainteresirane strane) koji imaju
različite i, nerijetko, nekonzistentne zahtjeve, koji nisu, u pravilu, odmah
očigledni. Također, u slučajevima kada se razvija veliki i složen sistem
praktično je nemoguće odmah definirati sve funkcionalnosti. Razvojem
samog sistema otkrivaju se i razvijaju novi, ili modificiraju postojeći,
funkcionalni zahtjevi.
59
• Funkcionalni zahtjevi su izjave o uslugama koje
programski proizvod mora pružati, kako će
sistem reagirati na određeni ulazni poticaj, te
kako bi se trebao ponašati u određenim
situacijama. U nekim slučajevima, funkcionalni
zahtjevi trebaju eksplicitno definirati i što sistem
ne treba raditi. Funkcionalni zahjevi su kompletni
ako sadrže opise svih zahtijevanih mogućnosti,
dok su konzistentni ako ne sadržavaju konflikte ili
proturječne tvrdnje. U praksi je nemoguće postići
kompletan i konzistentan dokument o
funkcionalnim zahtjevima.

60
 NEFUNKCIONALNI ELEMENTI
ZAHTJEVA
• Kako im sam naziv govori, to su elementi softverskog zahtjeva koji
se ne odnose direktno na funkcije koje će sistem pružati korisniku u
obavljanju njegovih poslova. Prvenstveno se misli na određena
svojstva sistema (npr. pouzdanost, zahtjevi za resursima, zahtjevi
za određenim performansama, zahtjevi za kvalitetom …). Također,
ovdje ubrajamo i određene standarde razvoja, postavljena
ograničenja u svezi dizajna i/ili implementacije, ugovore i pravila
koje softverski proizvod mora podržavati, zakonsku regulativu …
• Nefunkcionalni elementi zahtjeva se u pravilu ne odnose na
određenu, pojedinačnu, značajku sistema već na sistem u cijelosti i
mogu proisteći iz određenih, zahtijevanih, karakteristika samog
softverskog proizvoda (zahtjevi na proizvod), organizacije razvoja
softvera (organizacijski zahtjevi) i iz eksternih izvora koji utječu na
određene aspekte samog softverskog proizvoda i njegovog razvoja
(eksterni zahtjevi).

61
• Standardni problem sa nefunkcionalnim
elementima zahtjeva je u tome što ih je vrlo
teško, a ponekad i nemoguće, adekvatno
verificirati. Razlog tome je što se ovi zahtjevi
najčešće postavljaju načelno, uopćeno i
neprecizno i kao takve ih je teško implementirati
na zadovoljavajući način.
• Bitno je istaći i tzv. zahtjeve domene (domain
requirements). To su zahtjevi koji proizlaze iz
domene iz koje sistem dolazi, a mogu biti
funkcionalni i nefunkcionalni. To su specijalizirani
zahtjevi koji izlaze iz poslovnog okruženja u
kojem sistem funkcionira.
62
• Nefunkcionalni zahtjevi su ograničenja u uslugama i funkcijama
programskog proizvoda.
• Najgrublja podjela je na tri tipa:
• 1) zahtjeve programskog proizvoda, koji specificiraju na koji
se osobiti način treba ponašati isporučeni proizvod, npr. da
ima odgovarajuće vrijeme odziva, da radi na operacijskom
sistemu Windows 7, da koristi HTTPS protokol;
• 2) organizacijske zahtjeve, koji su rezultat organizacijskih
pravila i procedura, npr. uporaba propisanog normiranog
procesa razvoja, korištenje uvijek točno određenog
programskog jezika pri razvoju;
• 3) vanjske zahtjeve, koji proizlaze izvan sistema i razvojnog
procesa, npr. Postizanje međusobne operabilnosti s drugim
sistemima, zakonske zahtjeve i drugo.
• Dobra je ideja da se većina nefunkcionalnih zahtjeva
navede kvantitativno kako bi se mogli ispravno
ispitati.
63
64
 ZAHTJEVI DOMENE PRIMJENE
• Zahtjevi domene primjene su takvi zahtjevi koji su
specifični za domenu primjene sistema. Oni mogu biti novi
funkcionalni zahtjevi ili ograničenja na postojeće zahtjeve.
Takvi zahtjevi se obično saznavaju kasnije u procesu
dobivanja (otkrivanja) zahtjeva buduće da ih je teško izvući
od stručnjaka. Naime, prilikom otkrivanja zahtjeva, postoje
dvije proturječnosti: razumljivost i implicitnost. Razvojni
tim ne razumije domenu primjene i stoga traži detaljan opis
zahtjeva (razumljivost), dok specijalisti domene poznaju
primjenu tako dobro da podrazumijevaju neke zahtjeve
(implicitnost) i ne navedu ih. Dok razvojni tim uspije izvući
traženu funkcionalnost, sistem već možda bude i dovršen,
što poskupljuje izmjene.

65
Načini pisanja specifikacije zahtjeva
• Kao što je već ranije rečeno, zahtjevi sistema
mogu se napisati na više načina, pri čemu se
uvijek nastoji izbjeći nestrukturirani prirodni
jezik u obliku pisanog teksta. U tablici
prikazane su sve mogućnosti za pisanje
specifikacije zahtjeva sistema. U praksi se
koriste svi pristupi, a često se i kombinira više
od jednog načina specifikacije.

66
67
 Dokument zahtjeva
• Dokument zahtjeva programske potpore je službena izjava
o tome što točno trebaju razvojni inženjeri ostvariti. On
obično sadržava i neformalne korisničke zahtjeve i
detaljniju specifikaciju zahtjeva sistema. Kad je to moguće,
ponekad se obje vrste zahtjeva integriraju u jedinstveni
opis. U ostalim slučajevima, korisnički zahjtevi su definirani
u uvodu, dok su zahtjevi sistema definirani u ostatku
dokumenta. U slučaju većeg broja zahtjeva sistema detaljni
zahtjevi mogu se prikazati u zasebnom dokumentu. Razina
detalja koja je uključena u dokument zahtjeva ovisi o vrsti
sistema koji se razvija i o vrsti razvojnog procesa. Kritični
sistemi, primjerice, trebaju imati detaljnu razradu zahtjeva
budući da su pitanje sigurnosti i zaštite od velike važnosti.

68
• Prema normi instituta IEEE iz 1998. i prema doradi
Sommervillea, dokument zahtjeva trebao bi sadržavati
sljedeće stavke:

• 1) Predgovor
• 2) Uvod
• 3) Rječnik pojmova
• 4) Definicije korisničkih zahtjeva
• 5) Specifikacija zahtjeva sistema
• 6) Arhitektura sistema
• 7) Modeli sistema,
• 8) Evolucija sistema,
• 9) Dodaci
• 10) Indeks (pojmova, dijagrama, funkcija)

• Potrebno je uočiti da ovako strukturirani dokument zahtjeva već

predviđa buduću arhitekturu i model sistem, kao i evoluciju sistema,
u vidu inačica i mogućih proširenja.

69
 Procesi inženjerstva zahtjeva
• Procesi koji su u uporabi u inženjerstvu
zahtjeva programske potpore razlikuju se
ovisno o domeni primjene, ljudskim
resursima i organizaciji koja oblikuje zahtjeve.
Pritom je važno naglasiti da nema
jedinstvenog procesa inženjerstva zahtjeva
koji bi bio primijenjiv neovisno o vrsti projekta.
Ipak, u okviru svakog procesa postoje neke
generičke aktivnosti inženjerstva zahtjeva koje
se redom odvijaju kako bi se u konačnici
definirao dokument zahtjeva. To su:
70
 • studija izvedivosti (engl. feasibility study),
• izlučivanje (otkrivanje) zahtjeva i analiza zahtjeva
(engl. requirements elicitation and analysis),
• specifikacija (zapisivanje) zahtjeva (engl. requirements
specification),
• validacija zahtjeva (engl. requirements validation).

• Osim ove četiri temeljne generičke aktivnosti,

u novije vrijeme kao dodatna aktivnost navodi
se i upravljanje promjenama u zahtjevima
(engl. requirements management).

71
 Generičke aktivnosti inženjerstva
zahtjeva
• Generičke aktivnosti inženjerstva zahtjeva ne
odvijaju se nužno slijedno, već se mnogo češće
isprepliću. Na slici prikazan je klasični model
procesa inženjerstva zahtjeva u kojem se konačni
dokument zahtjeva postepeno slaže na temelju
nekoliko manjih dokumenata - proizvoda
pojedinih generičkih aktivnosti. Iteracije su
prisutne između aktivnosti izlučivanja i analize
zahtjeva, specifikacije zahtjeva i validacije
zahtjeva, sve dok se zahtjevi ne usaglase.
72
73
 KORISNIČKI ZAHTJEVI (ZAHTJEVI
KRAJNJEG KORISNIKA)
• Korisnički zahtjevi trebaju pružiti opise zadataka koje krajnji
korisnik softverskog proizvoda mora moći obaviti služeći se
njime. Oni trebaju sadržavati funkcionalne i
nefunkcionalne elemente zahtjeva na softver i to u
takvom obliku da su razumljivi i korisnicima koji nemaju
tehnička znanja. Korisnički zahtjevi trebaju specificirati
„vanjsko“ ponašanje sistema, bez opisivanja detaljnih
karakteristika dizajna i načina implementacije softverskog
proizvoda.
• Korisnički zahtjevi ne trebaju sadržavati tehničke
specifikacije. U njihovom pisanju se preporučuje korištenje
standardnog, „prirodnog“ načina opisa. Naravno, to sa
sobom nosi i određene negativnosti koje proističu iz same
prirode takvog pristupa. Naime, korištenjem takvog načina
notacije generiraju se određene nejasnoće, nedovoljno
precizni zahtjevi, nepotpuni zahtjevi, suviše opći74
(generalni) zahtjevi …
• Upravo zbog takvih problema potrebno je, kad god je to moguće, uz
korisnički zahtjev navesti i odgovarajuće obrazloženje. To će u
početku zahtijevati nešto više vremena, međutim takav pristup će
se isplatiti u kasnijim fazama razvoja softverskog proizvoda. Naime,
neprecizno definirani i nepotpuni zahtjevi, naročito funkcionalni,
su glavni razlog neuspješnog razvoja softvera i/ili probijanja
rokova njegovog razvoja.
• Također, dobra je praksa usvojiti i pridržavati se određenih
(standardnih) smjernica tokom evidentiranja korisničkih zahtjeva,
npr. uz svaki korisnički zahtjev navoditi (u standardiziranom obliku)
tko je predložio zahtjev (izvor zahtjeva), razlikovati i drugačije
označavati obvezne od poželjnih funkcija, naznačiti međusobne
ovisnosti zahtjeva, posebno isticati ključne elemente zahtjeva,
izbjegavati previše usko-stručnih opisa i termina …
• Neki autori (Robertsons, 1999.) ističu potrebu da se svaki korisnički
zahtjev evidentira na posebnoj kartici, koja sadrži točno definirana
polja: obrazloženje zahtjeva, ovisnosti o drugim zahtjevima, izvor
zahtjeva itd.

75
 SISTEMSKI ZAHTJEVI
• Sistemskim zahtjevima detaljno i precizno se definiraju funkcije sistema i
ograničenja. Sistemski zahtjevi se mogu shvatiti kao proširena verzija
korisničkih zahtjeva koji služe softverskim inženjerima kao polazna točka
za dizajniranje sistema. Oni dodaju detalje i objašnjenja na koji način će
korisnički zahtjevi biti podržani od strane sistema. Sistemski zahtjevi u
mnogim slučajevima predstavljaju i dio ugovora između kupaca i razvijača
(engl. developers) softvera.
• U pravilu, sistemski zahtjevi ne trebaju sadržavati tehničke detalje o tome
kako će sistem biti dizajniran ili implementiran, međutim, vrlo je teško, ili
je nemoguće, izbjeći sve takve informacije prilikom detaljnog opisa
funkcionalnosti jednog kompleksnog sistema, kakav je u pravilu softverski
proizvod. U tom kontekstu i prilikom samog pisanja sistemskih zahtjeva
nije moguće izbjeći korištenje „profesionalne“ tehničke notacije, naprotiv,
ovdje se to preporučuje.
• Sistemski zahtjevi, dakle, podrazumijevaju korištenje tzv. strukturiranog
prirodnog jezika (stroga uniformirana struktura navođenja zahtjeva),
grafičkih modela zahtjeva, matematičkih formula … Primjena isključivo
prirodnog jezika nije adekvatna prilikom definiranja sistemskih zahtjeva,
zbog već ranije navedenih nedostataka.
76
 ZAHTJEVI USMJERENI KA SUČELJU
(INTERFEJSU) SISTEMA
• Gotovo svaki novi softverski proizvod mora „komunicirati“ sa
sistemom koji već egzistira u korisničkom okruženju. Obzirom na tu
činjenicu, neophodno je precizno definirati karakteristike sučelja
postojećeg sistema. Te specifikacije trebaju biti definirane u
početnim fazama i obavezno uključene u konačni dokument
softverskog zahtjeva (najčešće kao prilog).
• Tri su osnovna tipa sučelja (i specifikacija sučelja) koja mogu biti
definirana:
• Proceduralna sučelja (engl. procedural interfaces) – gdje postojeći programi
nude određene usluge (servise) dostupne putem poziva odgovarajućih
interfejs-procedura,
• Sučelja za podatkovne strukture (engl. data structures) – koje definiraju
strukture podataka i podatke koji se razmjenjuju između programskih
podsistema. Za njihovo specificiranje najčešće se koriste grafičke tehnike,
poput ERA modela.
• Načini predstavljanja podataka (engl. data representations) koji se koriste u
postojećem softveru (npr. poredak bitova). Ovaj tip sučelja je najviše prisutan
u real-time sistemima. Najbolji način za izradu specifikacija ovog tipa su
odgovarajući dijagrami strukture koji sadrže dodatna objašnjenja funkcija
pojedinih skupina bitova.
77
Procesi i modeli procesa softwareskog
inženjerstva
• Modeli procesa softwareskog inženjerstva predstavljaju uočene
pristupe organizaciji projekta izrade programske potpore. Oni nisu
prvenstveno stroži ili manje stroži recepti kako se taj posao mora
napraviti, već pomoć pri razmišljanju kako projekt uspješno privesti
kraju. Do njih se došlo na temelju iskustava razvojnih timova kao o
skupu pozitivnih zaključaka o važnosti i redoslijedu izvođenja
projektnih aktivnosti.
• U pristupu koji bi zanemario saznanja na kojima se temelje modeli
softwareskog inženjerstva razvojni tim započinje izradu software-a
te ju neprestano mijenja sve do zadovoljenja korisničkih zahtjeva.
To bi se moglo nazvati kao ad-hoc ili oportunistički pristup koji do
određene veličine razvijene programske potpore može biti
zadovoljavajući.
• Mogao bi se prikazati kao niz aktivnosti prema slici

78
79
• S druge strane, tri su jasno definirana i opće prihvaćena
generička modela softwareskog inženjerstva koji
nastoje nadići negativne strane ovog previše
pojednostavljenog ad-hoc pristupa. Moglo bi ih se
nazvati procesnim paradigmama gledano sa strane
arhitekture programske potpore ili okvirima
otvorenima za proširenja i prilagodbe koje će biti
potpuno određene samim projektom. To su:
• Vodopadni model (engl. waterfall model) koji temeljne aktivnosti
procesa izrade programske potpore gleda kao nezavisne faze
razvoja.
• Evolucijski model (engl. evolutionary model) kod kojeg se sistem
razvija kroz niz inačica ili inkremenata kod kojih svaka sljedeća
dodaje neku novu funkcionalnost u onu na koju se nastavlja
• Komponentni model (engl. component-based model) čija je
motivacija u pretpostavci ponovne iskoristivosti postojećih
komponenata.

80
• Osim ta tri generička modela, u novije vrijeme naglašavaju se kao
zasebni modeli i modelno-usmjereni razvoj programske potpore
(engl. Rational Unified Process, RUP) kao i agilni razvoj (engl. agile
development). U stvarnosti, oni čine samo podmodele tri osnovna
generička modela razvoja.
• Tri generička modela programskog inženjerstva, vodopadni,
evolucijski i komponentni, nisu potpuno međusobno isključiva. Kod
razvoja velikih sistema ima ih smisla kombinirati. Npr., evolucijski
pristup u načelu nije tu u principu pogodan, jer krenuti u razvoj
velikih sistema bez jasno definiranih temelja sistema koji se temelje
na analizi korisničkih zahtjeva i nema baš nekog smisla. Međutim,
dijelovi tog podsistema koje često nije potrebno ili je malo teže
unaprijed i do kraja jasno specificirati, kao npr. korisničko interface,
se pritom mogu razvijati evolucijskim pristupom. Ponovno
korištenje postojećih komponenti je tako široko rašireno da je skoro
nemoguće zamisliti razvojni proces koji se temelji na potpuno
nezavisnoj izradi vlastitih komponenti. Komponentno usmjereni
razvoj često je i neformalno utkan u velikom broju razvojnih procesa
u različitim fazama razvoja. 81
 Spiralni model
• Spiralni model inženjerstva zahtjeva definiran je
kao tro-stupanjska aktivnost (specifikacija,
validacija, izlučivanje). Promatra proces
inženjerstva zahtjeva kroz iteracije ciklusa svih
aktivnosti, za razliku od klasičnog modelu, gdje se
ne ponavlja cijeli ciklus. U svakoj iteraciji je različit
intenzitet aktivnosti (u ranim iteracijama fokus je
na razumijevanju poslovnog modela, u kasnijim
na modeliranje sistema). Zahtjevi se u pojedinim
iteracijama specificiraju s različitom razinom
detalja.

82
83
• Kod spiralnog pristupa iteracijama, proces
oblikovanja predstavljan je oblikom spirale
umjesto nizom aktivnosti. Svaka petlja u
spirali predstavlja jednu fazu procesa. U
svakoj fazi razvoja, eksplicitno se određuju i
razrješavaju rizici razvoja programskog
proizvoda.

84
• U početnim koracima spirale razvija se
koncept, a u kasnijim spiralnim iteracijama
aktivnosti imaju sve više detalja (specifikacija,
oblikovanje, razvoj, ispitivanje, uporaba).
• U sektoru planiranja obavlja se planiranje faza
(tj. ciklusa spirale), od prikupljanja zahtjeva do
oblikovanja, razvoja i konačno, integracije („od
koncepta do produkta“).

85
 Vodopadni model
• U ovom modelu, procesne faze su jasno odvojene i u načelu
nezavisne. Tako se mogu zasebno promatrati faze:
• Definisanje zahtjeva,
• oblikovanja,
• implementacije,
• integracije i
• održavanja sistema.
• Prema tome se pretpostavlja i da prije početka rada na
pojedinim fazama postoji dobro definiran plan rada za
svaku od njih. Može se reći da ovaj model predstavlja
“klasični” pristup projektiranju sistema gdje su koraci
razvoja planski definirani i ne preklapaju se, već slijede
jedan iza drugoga. Sljedeća faza pritom ne bi smjela
započeti dok prethodna nije završena.

86
• Detaljnije, izrada sistema po fazama se sastoji od sljedećih
faza:
– Definicija zahtjeva. Konzultacije s korisnicima identificiraju koji
su ciljevi sistema, koje usluge treba pružati i koja ograničenja su
prisutna, što sve skupa čini konačnu specifikaciju sistema.
– Oblikovanje. Definira se arhitektura sistema kroz identifikaciju
programskih i sklopovskih sredstava u odnosu na postavljene
zahtjeve te se na strani programske potpore određuju temeljne
apstrakcije izvedbe te njihovi odnosi.
– Implementacija i ispitivanje. Ostvarenje sistema kroz skupove
programskih jedinica koje se pritom propisno ispituju
odgovaraju li svojim specifikacijama.
– Integracija. Programske jedinice se ujedinjuju u cjelinu uz
neizostavno ispitivanje cijelog sistema nakon čega bi trebao biti
spreman za isporuku korisniku.
– Rad i održavanje. Podrazumijeva instalaciju i pogon sistema te
dugotrajan rad na održavanju sistema kroz ispravljanje kvarova i
nadogradnje već prema novim zahtjevima na funkcionalnost i
uvjete radne okoline.

87
88
• Zbog tako izražene nefleksibilnosti u ranoj podjeli
na faze i skupim promjenama korisničkih
zahtjeva, vodopadni model je pogodan za
projekte koji imaju visoko razumljive zahtjeve s
malom vjerojatnošću njihove promjene. Kao
model upravljanja projektom, vodopadni model
je najpogodniji te se uglavnom koristi za velike
inženjerske projekte gdje se sistem razvija na
nekoliko odvojenih mjesta. Također je prikladan
ako je moguće uspostaviti i formalnu specifikaciju
sistema temeljenu na matematičkom modelu što
pogotovo ima smisla za sisteme koji su kritični u
pogledu sigurnosti.
89
PROBLEMI VODOPADNOG MODELA

• Nefleksibilna particija projekta u odvojene dijelove čini implementaciju

promjena koje zahtijeva kupac vrlo teškom (temeljni nedostatak
vodopadnog modela).
• Model je prikladan samo ako su zahtjevi dobro razumljivi i eventualne
promjene svedene na minimum.
• Vrlo malo poslovnih sistema ima stabilne zahtjeve.
• Vodopadni model se uglavnom koristi za velike inženjerske projekte
gdje se sistem razvija na nekoliko odvojenih mjesta.

90
 Evolucija modela
• Ovaj model se još u literaturi referencira kao inkrementalni
(engl. incremental) model gdje se sistem razvija kroz niz
inačica (ili inkremenata), pri čemu svaka nova inačica
pridodaje nove funkcionalnosti u prethodno izgrađenu.
• Izdvajaju se elementi specifikacije, razvoja i validacije, koji
su više isprepleteni nego razdvojeni te imaju više narav
pojedinih aktivnosti nego pojedinačnih faza izrade. Između
susjednih aktivnosti, učestalija je povratna komunikacija
nego u vodopadnom modelu pa bi se moglo govoriti i o
određenoj istodobnosti (engl. concurrency) među njima.

91
• Dva su osnovna tipa evolucijskog modela
razvoja programske potpore:
• Istraživački razvoj i oblikovanje (engl. exploratory
development). Kod ovog pristupa prisutan je stalan rad
s naručiteljem radi identifikacije pravih zahtjeva. Razvoj
započinje u dijelovima sistema za koje su zahtjevi
dovoljno razumljivi, a nakon toga se dodaju nove
funkcionalnosti prema prijedlozima naručitelja.
• Metoda odbacivanja prototipa (engl. throwaway
prototyping). U ovom pristupu je cilj bolje
razumijevanje zahtjeva naručitelja i na osnovi toga
bolja specifikacija zahtjeva. Prototipovi koji se pritom
razvijaju na temelju slabo definiranih zahtjeva služe
samo kao pomoć pri razjašnjavanju stvarnih potreba
korisnika.

92
• Ovaj model softwareskog inženjerstva odražava način kako
vrlo često pristupamo rješavanju nekog programskog
zadatka. Svaka inačica uvodi neku od novih funkcionalnosti
zadanih u opisu zahtjeva. Najčešće prve inačice pritom
sadrže najvažnije ili najžurnije funkcionalnosti pa ih
korisnik već u ranim razdobljima projekta može
vrednovati. U slučaju neispunjavanja ili promašaja
zahtjeva, jeftiniji su ispravci pogrešaka jer je potrebno
mijenjati samo jednu ili nekoliko zadnjih inačica koje
prethode. U odnosu na vodopadni model, evolucijski
pristup razvoju je značajno brži, posebice u početnom
razdoblju rada te time čini i osnovu agilnog razvoja
programske potpore. S time se može kombinirati i planski
pristup te postoji više različitih načina pogleda na
evolucijski model programskog inženjerstva. Kod više
planskog pristupa, inkrementi se određuju unaprijed, a kod
agilnog se prvi inkrementi brzo razvijaju dok razvoj budućih
inkremenata ovisi o brzini napretka i korisničkim
prioritetima. Jedna od karakteristika evolucijskog modela
koja može biti i prednost je i da se specifikacija razvija
inkrementalno. 93
Ponavljanje
Početna inačica,
aktivnosti:
među-inačice,
specifikacija,
završna inačica
razvoj, validacija

94
EVOLUCIJSKI MODEL RAZVOJA I OBLIKOVANJA

Problemi:
• Proces razvoja i oblikovanja nije jasno vidljiv (otežava posao voditeljima
projekta).
• sistemi su često vrlo loše strukturirani zbog stalnih izmjena.
• Često su potrebne posebne vještine (npr. brzi razvoj prototipa – engl. Rapid
System Prototyping).
Primijenjivost:
• Za male i srednje interaktivne sisteme.
• Za dijelove velikih sistema (npr. korisničko interface).
• Za sisteme s kratkim vijekom trajanja.

95
 Komponentno-usmjereni model
• Uz komponentno-usmjereni model veže se jedna čitava
grana softwareskog inženjerstva, odnosno komponentno-
usmjereno softversko inženjerstvo (engl. component-
based software engineering - CBSE), koja se kao pristup
razvoju programske potpore pojavila krajem 90-ih godina
prošlog stoljeća s motivacijom postizanja bolje i šire
primjene principa ponovne uporabljivosti (engl. reuse)
programskih komponenata. Kao najjednostavnija definicija
pojma komponente može se reći da je to:
• Definicija - Komponenta je nezavisna jedinica programske
potpore koja se može kombinirati s drugim nezavisnim
jedinicama u svrhu izrade cjelovitog sistema programske
potpore.

96
• Dva su temeljna tipa interface-a komponente:
realizirano ili izvozno (eksportirano, engl. export)
interface, koje definira usluge koje komponenta pruža i
zahtijevano ili uvozno (importirano, engl. import)
interface, koje specificira koje usluge moraju biti na
raspolaganju komponenti da bi ona bila operabilna.
• Prvi tip sučelja definira popis metoda koje mogu biti
pozvane od strane korisnika komponente.
• Drugi tip sučelja navodi koje vanjske usluge joj moraju
biti osigurane za koristan rad koji izvršava. Pritom se
ne definira kako te usluge moraju biti osigurane, već se
sadržaji koje daje prenose kao parametri operacija koje
čine interface. U UML-notaciji se realizirano interface
prikazuje kružićem, a zahtijevano polukružićem na
kraju linije koja ide od simbola koji predstavlja jezgru
komponente, slika

97
uvoz izvoz

98
• S obzirom na neodvojivost pojma komponentno-usmjerenog
softwareskog inženjerstva od ideje ponovne uporabljivosti
komponente, na procese te grane softwareskog
inženjerstvamožemo gledati s dva različita stajališta, a to su:
– Razvoj za ponovnu iskoristivost (engl. development for reuse), gdje se
grade komponente predviđene za iscrpno korištenje u drugim
razvojnim procesima. U ovom tipu razvoja, programski kod
komponente je u potpunosti otvoren, a često se proces svodi na
generalizaciju postojećih komponenti za koje postoje naznake
višestruke uporabljivosti.
– Razvoj s korištenjem postojećih komponenti (engl. development with
reuse) gdje se grade nove aplikacije korištenjem postojećih
komponenti. Prikladne komponente se pritom moraju najprije pronaći
i identificirati kao one koje zadovoljavaju ili se mogu prilagoditi
potrebama aplikacije koja se gradi. Pritom za te komponente ne mora
biti dostupan programski kod.

• Slika prikazuje pregled temeljnih procesa komponentno-

usmjerenog programskog inženjerstva, uključujući oba pogleda na
komponentno-usmjereni razvoj te procese nabave, provjere i
upravljanja komponentama.
99
100
• Nabava komponente dohvaća komponente iz lokalnog izvora, tj.
razvoja komponenti, ili vanjskog izvora radi daljnjeg razvoja novih
komponenti ili korištenje istih unutar novog sistema. Te
komponente daje procesu upravljanja komponentama koji ih šalje
na provjeru i pohranu u repozitorij. Provjera komponente sastoji se
od nekog oblika certifikacije da ima funkcionalnosti navedene u
specifikaciji.
• Prvonavedena vrsta komponentnog-usmjerenog inženjerstva, razvoj
za ponovnu iskoristivost, stvara komponente koje će se koristiti u
drugoj, razvoju s korištenjem postojećih komponenti te se pojam
komponentnog usmjerenog razvoja u konkretnim situacijama
najprije veže uz korištenje postojećih komponenti. sistem se
integrira višestrukom uporabom postojećih komponenata ili
uporabom komercijalnih, gotovih komponenata (engl. COTS -
commercial-of-the-shelf).
• Komponentni model predstavlja definiciju norme za
implementaciju, dokumentaciju i isporuku komponenti. Normiranje
je važno i za razvojno osoblje kao i za osoblje podrške i održavanja
infrastrukture projekta da bi se osigurala nesmetana ugradnja i
komunikacija komponenti.

101
• Norma komponentnog modela za svaku komponentu
trebala uključivati sljedeće informacije:
• Definiciju interface koja uključuje nazive operacija koje
komponenta obavlja, parametre koje pri tome prima, opise
iznimaka i jezik kojim se interface definira. Npr., za komponente
web usluge jezik je WSDL, za Enterprise JavaBeans to je Java, za
.NET to je Component Intermediate Language (CIL), već ovisno o
specifičnosti infrastrukture komponentnog modela.
• Uputu za korištenje koja najprije pretpostavlja jedinstveni naziv
komponente po kojem joj se može pristupiti, zatim informacije o
sučeljima i atributima te način na koji se komponenta može
primjenjivati za različite usluge.
• Uputu za isporuku koja specificira način pripreme komponente
kao nezavisnog izvršnog entiteta. To znači da sa sobom mora nositi
svu prateću podršku koja ne mora nužno biti osigurana u ciljnoj
infrastrukturi niti je eksplicitno tražena od strane svojeg
zahtijevanog sučelja. Osim toga, dobro bi bilo da uključuje opis
uvjeta za daljnju nadogradnju ili zamjenu prema promjenama
korisničkih zahtjeva te bi svakako trebala uključivati temeljnu
dokumentaciju koja opisuje sadržaj i unutarnju organizaciju
komponente kako bi se lakše identificirala kao komponenta koja je
102
prihvatljiva za određenu namjenu.
• Skoro svaki projekt izrade programske potpore danas
ima elemente razvoja s korištenjem postojećih
komponenti. Ako već nije tako unaprijed etiketirano,
ponovno iskorištavanje postojećeg koda se događa
često i neformalno, tj. dizajneri koriste ono za što znaju
da postoji a da odgovara ili je slično onome za što
postoji potreba. Tako se u programerskoj praksi po
pitanju granulacije jedinica programske potpore princip
ponovne uporabe primjenjuje na različitim razinama:
• gotove aplikacije koja se (do određene mjere) može prilagoditi
različitih korisnicima,
• komponenata aplikacije čija se veličina može kretati od njenih
većih dijelova ili podsistema do pojedinih modula ili objekata,
• objekata predstavljenih svojim razredima i pojedinačnih funkcija ili
procedura kao najniže razine apstrakcije.

103
• S druge strane, za one projekte izrade programske potpore koji se u
svojem pristupu fokusiraju upravo na komponentno-usmjereni model,
moguće je identificirati nekoliko procesnih faza, Uvodna faza, specifikacija
zahtjeva, i završna faza, validacija sistema, mogu se usporediti sa sličnim
fazama i drugih procesnih modela dok su ostale faze potpuno specifične za
komponentno-usmjereni model. To su:
– Analiza postojećih komponenti. Traži se pogodna
komponenta za specifičnu namjenu. Obično se pronađu
komponente koje ispunjavaju samo dio traženih
funkcionalnosti.
– Promjene na postavljenim zahtjevima. Sa saznanjem
karakteristika pronađenih komponenti (koje ne moraju nužno
ispunjavati sve zahtjeve potrage) ponovno se analiziraju
zahtjevi primjene te, ako je to moguće, mijenjaju ne bi li bilo
moguće koristiti nađene komponente.
– Oblikovanje sistema. Uzimajući u obzir dostupne komponente
oblikuje se struktura sistema. Za pojedine zahtjeve definiraju
se nove komponente kao i elementi integracije sistema.
– Razvoj i integracija. Programska potpora koja nedostaje se
razvija te se zajedno s pribavljenim komponentama integrira u
novi sistem.
104
 MODEL PROGRAMSKOG INŽENJERSTVA TEMELJEN NA
VIŠESTRUKOJ UPORABI KOMPONENATA

Oblikovanje sistema
Analiza knjižnice Promjena zahtjeva
temeljeno na
komponenata jer su komp.
ponovnoj uporabi
fiksirane
komponenata

Specifikacija
temeljena na
zahtjevima

Razvoj i Validacija
integracija sistema

105
• Više je prednosti i dobitaka kod primjene komponentno-
usmjerenog modela. Najprije, povećana je pouzdanost
komponente koja je već prošla neki oblik ispitivanja ili je već bila
dijelom nekog funkcionalnog sistema u odnosu na onu koja to tek
treba proći. Kod planiranja troška izgradnje sistema olakšana je,
bolja i jasnija procjena troška. Za pretpostaviti je da su komponente
rađene i potvrđene za višestruku uporabu ostvarene od strane
specijalista razvoja programske potpore s takvim ciljem, a ne u
sklopu usputnih potreba drugih projekata. Isto tako, specijaliziranija
okruženja pretpostavljaju i bolje poklapanje sa zadanim normama
izrade komponente. Na kraju, ono što je vjerojatno najvidljiviji
dobitak za voditelje projekata je značajno ubrzanje u razvoju
sistema kad se uzme gotova komponenta. S druge strane, postoje i
problemi koji se mogu pojaviti kod primjene koncepta ponovne
uporabe komponenti. Ako izvorni programski kod nije dostupan,
troškovi njenog održavanja mogu značajno porasti ako postane
nekompatibilna s promjenama u sistemu. Ako se koriste i oni alati
programske potpore koji ne predviđaju ili ne podržavaju koncept
ponovne uporabnosti komponenti, to može biti poseban problem
pri integraciji takvih alata zajedno s komponentama izrađenim za
ponovnu uporabu. Problem se može očitovati u nemogućnosti
integracije takvih alata sa sistemom knjižnice potrebnih
komponenti.
106
• Posebni problem je sklonost inženjera da napišu
svoj kod umjesto da koriste tuđi.
• Često se tu radi o vjeri da se uvijek može izraditi
bolja i naprednija komponenta a i o određenom
sindromu programerskog intelektualnog izazova.
• Osim toga, troškovi održavanja knjižnice
komponenata mogu biti visoki. Knjižnicu
komponenata treba stvoriti i održavati a treba i
osigurati da njeno korištenje bude podržano
unutar čitavog razvojnog procesa.
• Poteškoću može činiti i napor pronalaženja,
razumijevanja i prilagodbe komponenata iz
vanjskih knjižnica pri čemu treba donositi
utemeljene odluke.
107
• Pri odluci hoće li se i u kojoj mjeri pribjeći razvoju
koji bi bio srodan ili se temelji na konceptu
ponovne uporabe komponenti, nekoliko je
vodećih čimbenika. To su:
– Prije svega, vremenski okvir u kojem se očekuje izrada
programskog proizvoda utječe na odluku za izbor
gotovih komponenti ili čitavog sistema.
– Očekivana dugovječnost programskog proizvoda.
– Razina znanja, vještina i iskustva razvojnog tima.
– Strogost okoline za koju je programska potpora
namijenjena i razina performansi koja se očekuje.
– Osobitosti domene primjene programske potpore.
– Izbor platforme za koju je programska potpora
predviđena.

108
 Podaktivnosti unutar specifikacije
• U okviru svakog procesa inženjerstva zahtjeva mogu se uočiti sljedeće
generičke aktivnosti:
– Studija izvedivosti (engl. feasibility study) - Procjenjuje se da li se uočene
potrebe korisnika mogu zadovoljiti uz pomoć dostupnih hardverskih i
softverskih tehnologija, da li bi predloženi sistem bio isplativ u poslovnom
smislu, te da li sistem može biti razvijen s raspoloživim budžetom.
– Izlučivanje (otkrivanje) zahtjeva (engl. requirements elicitation), analiza i
specifikacija - Otkrivaju se zahtjevi, tako da se promatraju postojeći sistemi,
analiziraju radni procesi, intervjuiraju budući korisnici i njihovi manadžeri, itd.
Na taj način stvaraju se modeli sistema, a ponekad i prototipovi, sve u cilju
boljeg razumijevanja sistema kojeg treba stvoriti.
– Validacija zahtjeva - Provjerava se da li su zahtjevi realistični (mogu se ostvariti
raspoloživom tehnologijom i budžetom), konzistentni (nisu u medusobnom
konfliktu), te potpuni (uključene su sve potrebne funkcije i ograničenja).
– Upravljanje zahtjevima, odnosno promjenama u zahtjevima - Informacije
skupljene analizom pretvaraju se u tekstove koji definiraju zahtjeve. Postoje
dvije razine u opisivanju zahtjeva: “korisnički zahtjevi” i “zahtjevi na sistem”.

109
 Vrste dokumenata koji opisuju
zahtjeve
• Korisnički zahtjevi. To je manje precizan tekst u
prirodnom jeziku, popraćen dijagramima i
tablicama, opisuje funkcije sistema i ograničenja
pod kojima sistem radi. Prilagoden je krajnjim
korisnicima.
• Zahtjevi na sistem. Riječ je o detaljnom i
preciznom opisu funkcija sistema i ograničenja.
Može služiti kao temelj ugovoru između kupca i
razvijača softvera. Služi softverskim inženjerima
kao polazište za oblikovanje. Pisan je u donekle
strukturiranom prirodnom jeziku.

110
• Modeli sistema. To su dijagrami koji opisuju ponašanje
sistem na način koji je precizniji i jezgrovitiji od
prirodnog jezika. Nastaju tijekom analize zahtjeva kao
sredstvo komunikacije između razvijača softvera i
budućih korisnika.
• Dokument o zahtjevima. Riječ je o konačnom rezultatu
specifikacije, dobivenom kao unija svih prethodno
opisanih dokumenata.
• Specifikacija softverskog designa. Ovaj dokument nije
obavezan. Predstavlja apstraktni opis grade softvera i
funkcija koje on obavlja, pisan u formalnom jeziku.
Pretpostavlja odredenu arhitekturu sistema, te na
osnovu nje dalje razraduje “zahtjeve na sistem”.
Eventualno se stvara kao most između aktivnosti
specifikacije i oblikovanja. Služi razvijačima softvera
kao polazište za daljnje oblikovanje i implementaciju.

111
 Problemi koji se pojavljuju kod
specifikacije
• Kod specifikacije se mogu pojaviti sljedeći problemi.
– Ukoliko novi sistem treba promijeniti sadašnji način rada,
tada ga je teško definirati budući da s njim još nema
iskustava.
– Razni korisnici imaju različite zahtjeve koji mogu biti u
konfliktu. Konačni zahtjevi su nužno kompromis.
– Financijeri sistema i njegovi korisnici obično nisu isti ljudi.
Kupac postavlja zahtjeve motivirane organizacijskim ili
budžetskim ograničenjima koja su u konfliktu s korisničkim
zahtjevima.
– Poslovno i tehničko okruženje se mijenja. Time se
mijenjaju i zahtjevi.

112
 Modeliranje sistema
• Tijekom otkrivanja i analize zahtjeva sastavljaju se modeli postojećeg ili
budućeg sistema. Ti modeli opisuju sistem na grafički način pomoću
dijagrama. Precizniji su i jezgrovitiji od ekvivalentnog opisa pomoću
prirodnog jezika. Još uvijek su razumljivi korisnicima. Modeli također
predstavljaju važan most između specifikacije i oblikovanja.
• Model uvijek daje apstraktnu (pojednostavnjenu) sliku sistema. Također,
on promatra sistem iz neke odredene perspektive, pa ističe neke njegove
osobine a zanemaruje druge. Najvažnije perspektive su:

• Kontekst. Odreduje se granica između sistema i njegove okoline, te

sučelja koja se uspostavljaju na toj granici.
• Ponašanje. Promatraju se transformacije podataka, reakcije
sistema na dogadaje, te promjene njegovih stanja.
• Struktura. Modelira se arhitektura samog sistema ili grada
podataka koje on obraduje.

• Da bi dobili cjelovitu sliku o sistemu, moramo imati nekoliko

komplementarnih modela koji ga promatraju iz različitih perspektiva.
Svaka metoda razvoja softvera propisuje odredeni broj modela. 113
 STUDIJA IZVEDIVOSTI
• Za sve nove sisteme početak procesa inženjerstva zahtjeva
treba biti provođenje studije izvedivosti, čiji rezultat je
izvještaj koji sadrži preporuku o daljnjem razvoju sistema ili
odustajanju od projekta, odnosno da li je predloženi sistem
isplativ ili ne. Ulazna informacija za studiju izvedivosti je
preliminaran skup poslovnih zahtjeva.
• Studija izvedivosti treba biti realizirana kao kratka,
fokusirana studija koja za cilj ima pružanje odgovora na
nekoliko bitnih pitanja, na primjer:
• Da li sistem doprinosi ciljevima organizacije u koju se uvodi ?
• Da li se sistem može izvesti postojećom tehnologijom i predviđenim
sredstvima ?
• Da li se predloženi sistem može integrirati s postojećim sistemima
organizacije u koju se uvodi ?

114
• Temeljno pitanje ovdje je doprinosi li sistem ostvarivanju ciljeva
organizacije ili ne. Ako predloženi sistem ne doprinosi osnovnim
ciljevima organizacije, dakle nema pozitivan utjecaj na ostvarivanje
poslovnih rezultata, nema ga smisla implementirati. Iako je ovo
očigledan i više nego logičan zaključak, u praksi se vrlo često događa
da organizacije razvijaju upravo takve sisteme, koji ne doprinose
ostvarivanju ciljeva organizacije, naprotiv. Razlozi za takve
„nerazumne“ odluke mogu biti posljedica unutar-organizacijskih
slabosti i/ili vanjskih (npr. političkih) utjecaja.
• Provedba studije izvedivosti temelji se na određivanju koje
informacije su potrebne za studiju, prikupljanju tih informacija i
pisanju izvještaja. U provedbi studije izvedivosti neophodno je
konsultirati različite izvore informacija: stručnjake koji imaju
iskustva u radu sa predloženim sistemom, ili sličnim sistemima,
softverske inženjere koji su upoznati sa tehničkim
karakteristikama i performansama sistema, rukovodioce odjela
gdje će sistem biti implementiran i, naravno, krajnje korisnike.
Studija treba biti više-aspektna. Ne smije biti koncentrirana samo na
tehničko-tehnološki aspekt izvedivosti, nego treba uključiti i analizu
operativne izvedivosti, vremenske i, naravno, analizu ekonomske
izvedivosti predloženog rješenja.
115
• Preporučeno trajanje ove aktivnosti ne bi
smjelo biti duže od 21 dan.
• U konačnom izvještaju mogu biti predložene i
odgovarajuće izmjene do kojih se došlo tokom
izvođenja studije, a odnose se na postavljene
ciljeve, planirani budžet, dodatne zahtjeve i sl..
• Rezultat studije mora sadržavati jasnu i
nedvosmislenu preporuku o nastavku ili
odbijanju razvoja i implementacije
predloženog sistema.

116
117
• Studija izvedivosti često se provodi na terenu,
u organiziciji gdje bi se sistem implementirao.
Neka od pitanja za ljude u organizaciji koja se
često postavljaju u studiji su:
• Koji su trenutni problemi procesa organizacije?
• Kako bi predloženi sistem pomogao u poboljšanju
procesa?
• Što ako se sistem ne implementira?
• Koji se problemi mogu očekivati pri integraciji novoga
sistema?
• Da li je potrebna nova tehnologija ili nove vještine?
• Koje dodatne resurse organizacije traži implementacija
novoga sistema?

118
PRIMJER STUDIJE IZVEDIVOSTI

119
120
 IZLUČIVANJE I ANALIZA ZAHTJEVA
• Ova faza procesa inženjerstva zahtjeva može se smatrati
najznačajnijom (i najkritičnijom). Uključuje stručno,
tehnički obrazovano osoblje koje u zajedničkom radu s
kupcima i krajnjim korisnicima razjašnjava domenu
primjene, definira usluge koje sistem treba pružiti, te
određuje ograničenja u radu sistema.
• Ova aktivnost uključuje sve zainteresirane strane. Dakle u
procesu izlučivanja (i analize) zahtjeva sudjeluju:
– krajnji korisnici sistema,
– menadžeri (rukovodioci),
– inženjeri uključeni u održavanje sistema,
– eksperti domene primjene,
– predstavnici sindikata i sl.
• Sve njih jednim imenom nazivamo stejkolderima (od engl.
riječi stakeholder) . 121
• Izlučivanje i samo razumijevanje zahtjeva stejkholdera je
zahtjevna i relativno problematična aktivnost, i to iz više
razloga:
– Stejkholderi ne znaju što stvarno žele, teško artikuliraju zahtjeve
ili su zahtjevi nerealni;
– Stejkholderi izražavaju zahtjeve na različite, njima specifične
načine (posjeduju implicitno znanje o svojem radu - domeni).
– Različiti stejkholderi imaju različite zahtjeve, izražene na različite
načine, koji nerijetko mogu biti u određenom konfliktu;
– Organizacijski i politički faktori također mogu utjecati na
zahtjeve (npr. rukovodioc traži da sistem ima značajke koje
povećavaju njegov utjecaj u organizaciji);
– Zbog dinamike ekonomskog i poslovnog okruženja zahtjevi se
mijenjaju za vrijeme procesa analize;
– Uz promjenu poslovnog okruženja pojavljuju se i novi
stejkholderi, s novim, specifičnim zahtjevima.

122
123
• Sa slike je vidljivo da je proces izlučivanja i analize složen
iterativni proces, u kojem se kao u spirali smjenjuju (i
nadopunjuju) aktivnosti:
– Izlučivanja (otkrivanja) zahtjeva – podrazumijeva komuniciranje
sa stejkholderima s ciljem prikupljanja njihovih zahtjeva;
– Klasificiranja i organiziranja zahtjeva – obuhvaća organiziranje
zahtjeva prikupljenih u prethodnoj aktivnosti, srodni zahtjevi se
uređuju u koherentne klastere;
– Određivanja prioriteta i pregovaranja - zahtjevi se razvrstavaju
po prioritetima i, kroz pregovaranje, razrješavaju eventualni
konfliktni zahtjevi, koji su mogući s obzirom da se zahtjevi
prikupljaju iz više izvora, odnosno od strane različitih interesnih
strana (stejkholdera);
– Dokumentiranja zahtjeva – obuhvaća aktivnost dokumentiranja
zahtjeva (formalnim i neformalnim dokumentima) koji se
„ubacuju“ u slijedeći ciklus spirale izlučivanja i analize zahtjeva.

124
• U procesu otkrivanja i analize zahtjeva koristi se
nekoliko tehnika, koje se međusobno ne
isključuju. Njihovim pažljivim i usmjerenim
kombiniranjem moguće je razotkriti većinu
zahtjeva. Najčešće korištene tehnike su:
– Intervjui (engl interviews),
– Upitnici i ankete
– Radni sastanci, sjednice, radionice (engl. workshops),
– „Storyboarding“
– Scenariji
– Obrasci upotrebe (engl. use cases)
– Dijagrami interekcije
– Prototipiranje (engl. prototyping)

125
 Izlučivanje i analiza zahtjeva
• Izlučivanje i analiza zahtjeva najznačajnija je generička aktivnost procesa
inženjerstva zahtjeva. Tijekom ove aktivnosti, razvojni inženjeri i drugo tehnički
obrazovano osoblje surađuje s klijentima i konačnim korisnicima sistema kako bi
saznali što više o domeni primjene i o tome koje usluge trebaju biti podržane s
kakvim performansama i ograničenjima. Vrlo je bitno pri toj aktivnosti uključiti sve
ili što više stakeholdera sistema – osoba koje će razvijeni sistem direktno ili
indirektno pogoditi. Primjerice, za sistem bankomata, mogući stakeholderi
programskog sistema uključuju:
» bankovne klijente,
» predstavnike drugih banaka,
» bankovne rukovoditelje,
» šalterske službenice,
» administratore baza podataka,
» rukovoditelje sigurnosti,
» marketinški odjel,
» inženjere održavanja sistema (sklopovlja i programske potpore),
» regulatorna tijela za bankarstvo.

126
• Model aktivnosti izlučivanja i analize zahtjeva prikazan je na slici. Svaka organizacija
imat će vlastiti način provedbe ovog modela, koji će ovisiti o specijalizaciji osoblja, vrsti
programskog proizvoda, korištenim normama razvoja i slično. Proces izlučivanja i
analize zahtjeva je iterativan. Znanje o zahtjevima sistema se tijekom svakog
ponavljanja ciklusa poboljšava dok se ne kompletira.
• Prvi korak, izlučivanje (otkrivanje) zahtjeva je postupak interakcije sa svim
stakeholderima s ciljem otkrivanja njihovih zahtjeva. Zahtjevi domene primjene se
također nastoje definirati u ovom koraku. Izvori informacija su dokumenti, stakeholderi,
slični razvijeni sistemi. Tehnike koje se koriste za otkrivanje zahtjeva su uglavnom
intervjuiranje, izrada scenarija i etnografija, o čemu će nešto kasnije biti riječi. Ponekad
se za otkrivanje zahtjeva koriste i UML obrasci uporabe.
• Tijekom drugog koraka, klasifikacije i organizacije zahtjeva, srodni zahtjevi se grupiraju i
organiziraju u koherentne grozdove (klastere). Zahtjevi se u praksi najčešće grupiraju
prema podsistemu cijelog sistema koji opisuju. Tako je teško u praksi razgraničiti
postupak specifikacije zahtjeva od razvoja arhitekture sistema.
• Tijekom trećeg koraka, ustanovljavanja prioriteta i pregovaranja, zahtjevi se razvrstavaju
po prioritetima i razrješavaju se konflikti nastali zbog različitihpogleda različitih
stakeholdera na sistem. U praksi je cilj postići kompromis zahtjeva među
stakeholderima.
• Na kraju se u četvrtom koraku zahtjevi specificiraju (pisano dokumentiraju) i
predstavljaju ulaz u sljedeću iteraciju. Zahtjevi se specificiraju tehnikama prema tablici i
zapisuju u formalnim ili neformalnim dokumentima, a najčešće grafičkom notacijom u
vidu UML obrazaca uporabe i UML sekvencijskih dijagrama. 127
128
• Pri izlučivanju zahtjeva, različiti stakeholderi ili
grupe stakeholdera imaju različiti fokus i
perspektivu na zahtjeve sistema.
• Definicija - Pogledi (engl. viewpoint) su način
strukturiranja zahtjeva tako da oslikavaju
perspektivu i fokus različitih grupa stakeholdera.
Svaki pogled uključuje skup zahtjeva sistema.
• Razlikuju se:
• pogledi interakcije - ljudi i drugi stakeholderi koji izravno
komuniciraju sa sistemom,
• neizravni pogledi - stakeholderi koji utječu na zahtjeve, ali ne
koriste sistem izravno,
• pogledi domene primjene - karakteristike domene i
ograničenja na sistem.

129
• Klijenti često puno lakše shvate programski sistem na
temelju stvarnih primjera nego kroz apstraktne opise.
Upravo iz tog razloga, scenariji su popularna i uspješna
metoda izlučivanja zahtjeva.
• Scenariji su pažljivo osmišljeni primjeri o stvarnom
načinu korištenja sistema.
• Tijekom izlučivanja zahtjeva, stakeholderi diskutiraju i
kritiziraju scenarij. Svaki scenarij pokriva jedan ili
nekoliko mogućih interakcija korisnika sa sistemom.
Scenarij obično počinje s opisom interakcije. Tijekom
procesa izlučivanja zahtjeva, dodaju se razni detalji
opisu interakcije sve dok scenarij nije završen. Scenariji
mogu biti napisani u obliku teksta uz potporu
dijagrama, slika ekrana (engl. screenshot) i na druge
načine. Mogu se koristiti više ili manje strukturirani
oblici scenarija, a scenarije je posebno pogodno
prikazati UML dijagramima obrazaca uporabe. 130
• Svaki scenarij trebao bi sadržavati sljedeće
elemente:
– Opis početne situacije.
– Opis normalnog (standardnog) tijeka događaja.
– Opis što se eventualno može dogoditi krivo.
– Informaciju o paralelnim aktivnostima.
– Opis stanja gdje scenarij završava.
• Jedan od razloga zašto se mnogo programskih
sistema isporuči, ali se nikad ne koristi je taj
što konačni zahtjevi sistema ne uzimaju
dovoljno u obzir to kako društveni i
organizacijski kontekst utječu na pojedinu
operaciju u sistemu.

131
 6

Postupak analize
Prikupljanje  analizu izvodi analitičar
zahtjeva zahtjeva

 zahtjevi se definišu u
Modelovanje term logiji naručioca
ponašanja
 analitičar ima potpunu
slobodu u odlučivanju
Specifikacija kako će sistem ispuniti
zahtjeva zahtjeve (SSZ)

Validacija
Specifikacija
zahtjeva softverskih
zahtjeva (SSZ)

Faza: Analiza zahtjeva Rezultat faze

 7

Aktivnosti u analizi

 prikupljanje zahtjeva (razgovor sa naručiocem, čitanje dokumentacije,

posmatranje aktuelnih ponašanja u okruženju)

 modelovanje ponašanja (formiranje modela ili prototipa ponašanja sistema

prema zahtjevima koji pomaže boljem razumjevanju zahtjeva i njihovih veza;
mogu se otvoriti nova pitanja koja treba razmotriti sa naručiocem

 specifikacija zahtjeva (izrada specifikacije u kojoj se definiše koji dijelovi

zahtjevanog ponašanja će biti implementirani u softveru)

 verifikacija i validacija zahtjeva (provjera da li specifikacija odgovara

očekivanjima naručioca; ako ima propusta, slijedi povratak na neku raniju
aktivnost)
 8

Prikupljanje zahtjeva
 uzeti u obzir poglede svih učesnika na sistem

 uskladiti terminologiju

 izgraditi dobre međuljudske odnose

 ako je problem poznat

• upoznati se sa procesom obavljanja posla

• postavljati prava pitanja (čiji se odgovori mogu pretočiti u zahtjeve)

 ako je problem nov

• intenzivnija saradnja, jer ni kupac nema praktičnih iskustava

• ne ulagati previše napora i ne insistirati na potpunom definisanju
skupa zahtjeva, jer će vremenom svi bolje razumeti problem, pa će
zahtjevi biti bolje definisani
 9

Tehnike prikupljanja
 razgovor (pojedinačni, u grupama – inspiracija idejama drugih)

 pregled dokumentacije (uputstva za rad, dokumentovane procedure, šeme)

 upoznavanje postojećeg sistema (sagledavanje sistema u cjelini i

aktivnosti koje se zaista obavljaju

 učenje posla od isnika smatranje korisnika kako radi konkretan posao)

 upotreba strategija specifičnih za datu oblast (korišćenje poznatih teorijskih

znanja)

 poređenje sa sličnim, ranije razvijenim sistemima (ranija iskustva

poboljšavaju kvalitet)
 PRIKUPLJANJE INFORMACIJA
• Jedna od aktivnosti kod definisanja zahtjeva za IS su intervjui sa
ključnim korisnicima i radne sjednice. Ako naručilac zapošljava
informatičare svakako ih treba uključiti u analizu. Sučeljavanje
korisnika i informatičara ubrzava se rješavanje proturječnih iskaza.
Kao zamjena za intervjue koriste se upitnici i ankete, koji su
pogodni i za prikupljanje informacija o resursima. Analiza
dokumentacije podrazumjeva prikupljanje cjelokupne
dokumentacije značajne za poslovanje, radi boljeg utvrđivanja
pravila, poslovne politike, ciljeva poslovanja i strukture informacija.
• Nužna je ocjena postojećih aplikacija i računarom podržanih
podataka, radi analize podataka, ali i zbog njihove konverzije u novi
sistem. Posmatranje, odnosno neposredni uvid u poslovne procese
posmatranjem radnih sredina (način izrade i razmjene dokumenata,
procesi osnovne djelatnosti), je značajan vid definisanja zahtjeva za
IS. Postupak analize mora biti prilagođen korisniku. Evidentiranje
rezultata analize poželjno je obaviti CASE alatima.

136
 Intervjuiranje
• Intervju je jednostavna tehnika, direktna i interaktivna, koja može
imati formalni ili neformalni karakter. Intervju sa zainteresiranim
stranama (stejkholderima) je dio većine procesa inženjerstva
zahtjeva, preciznije, procesa prikupljanja i otkrivanja zahtjeva. Tim
zadužen za inženjerstvo zahtjeva pažljivo priprema pitanja o
postojećem sistemu, ali i o novom sistemu koji se razvija. Iz
odgovora stejkholdera na ova pitanja izvode se odgovarajući
zahtjevi.
• Dva su osnovna tipa intervjua:
– Zatvoreni –zainteresiranim stranama se predočava skupina unaprijed
definiranih pitanja i
– Otvoreni intervju – ne postoje unaprijed pripremljena pitanja, već tim
zadužen za inženjerstvo zahtjeva otvara niz pitanja o kojima se
raspravlja sa zainteresiranim stranama s ciljem ostvarivanja boljeg
razumijevanja njihovih potreba i, naravno, otkrivanja i definiranja
zahtjeva.

137
• U praksi se intervjui sa zainteresiranim stranama
organiziraju i odvijaju po obrascu koji bi se mogao
definirati kao mješavina dva prethodno navedena
oblika intervjuiranja. Naime, odgovori na određena
(pripremljena) pitanja, mogu otvoriti neka nova (ne
planirana) pitanja koja se, potom, raspravljaju na manje
strukturiran način. Potpuno otvorena, ne strukturirana
diskusija tokom intervjuiranja nije dobro rješenje, stoga
se za intervju definira neki okvirni set pitanja koji će
osigurati da se tokom intervjua ne izgubi fokus.
• Intervjui se mogu organizirati kao individualni i kao
grupni. Individualni intervjui se provode sa jednim
osobom ili sa manjim brojem osoba koji rade isti posao.
Grupni intervju podrazumijeva intervjuiranje više
osoba iz različitih područja.

138
• Intervju je dobra tehnika za dobivanje generalne, uopćene
slike o aktivnostima stejkholdera, slike o njihovom poslu,
koji predstavlja područje od interesa budućeg sistema.
Intervju može pružiti jasnu predodžbu o tome kako različite
zainteresirane strane vide budući sistem, što im nedostaje
kod postojećeg sistema, što stvara najveće poteškoće i što
očekuju od novog sistema.
• Intervju nije idealna tehnika za otkrivanje i analizu zahtjeva,
naprotiv. Intervju ima niz nedostataka, ne rijetko se događa
da sugovornici „ne govore istim jezikom“. Softverski
inženjeri koriste informatički žargon koji krajnjim
korisnicima nije uvijek jasan. Korisnici, s druge strane, nisu
dovoljno precizni niti su u stanju artikulirati svoje zahtjeve
na adekvatan način. Poteškoće se javljaju i u razgovorima sa
ekspertima, koji, u pravilu, ne mogu shvatiti kako nekome
„tako jednostavne stvari nisu jasne“.

139
• Informacije dobivene intervjuiranjem nisu same za sebe dovoljne,
potrebno ih je dopuniti informacijama prikupljenim korištenjem
drugih tehnika kako bi se jasno mogli definirati zahtjevi.
• Neke preporuke za pripremanje i vođenje intervjua:
– Intervju treba biti dobro pripremljen i osmišljen, s jasno definiranim
ciljem.
– Pripremiti kvalitetna pitanja koja će ponuditi što jasnije odgovore,
odnosno osigurati utvrđivanje informacija koje se žele saznati.
– Proučiti prethodne nalaze i raspoloživu dokumentaciju prije intervjua.
– Ništa nije razumljivo i samo po sebi svima jasno.
– Ne pretpostavljati.
– Izbjegavati sugestivna pitanja.
– Ne nametati zaključke.
– Iskrenost i nepristranost (cilj je osigurati korisniku najkvalitenije
rješenje, a ne „gurati“ određena programska rješenja).
– Provjeriti odgovore različitih sugovornika na ista pitanja.
– Analizirati činjenice koje se ne poklapaju.
– Razlučiti činjenice od mišljenja ili stavova.

140
– Izbjegavati grupno intervjuiranje (iznimno provesti u situacijama
kada se želi utvrditi određeni zajednički interes ili razriješiti neka
konfliktna situacija ili proturječje).
– Samostalno voditi zapisnik („tko ne razumije, ne može bilježiti“).
– Zapisnik intervjua mora sadržavati ono što je rečeno i slijediti tok
razgovora.
– Zapisnik se šalje sugovorniku/sugovornicima na uvid i potvrdu
vjerodostojnosti.
– Intervju ne bi trebao trajati duže od 2 sata.
– Na početku intervjua predstaviti sve stakeholdere i upoznati ih
sa svrhom razgovora.
– Intervju završiti 5-10 min. prije isteka planiranog vremena.
– Provjeriti postoji li nešto što je sugovornik htio reći, a nije bilo
pitano.
– Dogovoriti eventualni nastavak intervjua (intervju je otvorio
neka nova pitanja).
– Zahvaliti sugovorniku/sugovonicima.

141
• Intervjuiranje, kao metoda izlučivanja zahtjeva,
jedan je od najčešće korištenih i često
nezaobilaznih pristupa dobivanju korisničkih
zahtjeva. Razlikuju se formalni i neformalni
intervjui. Kod formalnih intervjua, klijenta se
prethodno obavještava da će biti intervjuiran
vezano uz zahtjeve budućeg programskog
sistema, dok se kod neformalnog intervjua takva
obavijest ne zahtijeva. I u formalnom i u
neformalnom intervjuiranju tim zadužen za
inženjerstvo zahtjeva ispituje stakeholdere o
sistemu koji trenutno koriste te o novo
predloženom sistemu.

142
 Upitnici i ankete
• Upitnik je, u suštini, pismeni intervju. Sadrži pitanja koja se
postavljaju tokom razgovora. Može se dostaviti korisniku prije ili
nakon intervjua. Nedostaci upitnika su slijedeći: ispitanik može
prilagoditi (kontrolisati) svoje odgovore, teško je procijeniti
iskrenost (spontanost) odgovora, a može i obeshrabriti ispitanika.
• Anketa može da obuhvatiti više ispitanika. Pitanja su zatvorenog
tipa, a odgovori i obrada odgovora mogu se standardizovati.
Pogodna je za popis resursa.
• Na osnovu navedenog, može se zaključiti da je intervjuisanje
najelastičnije. Pomoću intervjua se može više naučiti o stavovima,
osjećajima i motivaciji osoblja. Tokom intervjua analitičar i ispitanik
se nalaze jedan nasuprot drugog, pa analitičar može posmatrati
način na koji ispitanik odgovara i po potrebi proširiti ili usmjeriti
pitanja.

143
 Proučavanje dokumenata
• Prikupljaju se svi dokumenti do kojih se može doći. U prvom redu treba
prikupiti dokumente koji su nastali kao rezultat analize procesa, tipične
dokumente (pravilnici, zakoni, obrasci, izvještaji) i dokumente nastale
analizom podataka. Poželjno je da dokumenti budu reprezentativni, tj.
popunjeni na tipičan način (tako se može ustanoviti koje informacije se
unose i na koji način). Reprezentativni dokumenti najčešće ne ukazuju na
izuzetke, to jest podatke koji se rjeđe bilježe, ali ipak trebaju. Stalno
bilježenje nekih podataka ne mora značiti da su ti podaci stvarno potrebni.
Treba prikupiti više uzoraka iste vrste dokumenta.
• Vrijednost informacija o analiziranoj organizaciji prikupljena samo preko
dokumenata je niska. Praksa može odudarati od pravilnika i
administrativnih obrazaca. Treba shvatiti zašto i kada dokumenti nastaju,
kako se popunjavaju, koliko su potrebni, te šta treba promijeniti da bi se
popravili (sadržaj, lakoća popunjavanja i čitanja). Nužno je modele
podataka, razmatrane analizom, provjeriti kod korisnika.

144
 Posmatranje poslovnog sistema
• Definisanje zahtjeva za IS se može dopuniti uvidom u poslovne
procese, odnosno posmatranjem radnih sredina. Posmatra se
lokacija i kretanje ljudi, tok izvršavanja poslova, fizički ulazi i izlazi
sistema, zaprimanje, izrada i razmjena dokumenata, procesi
osnovne djelatnosti, npr. proizvodnje. Prednost ovakvog pristupa
je u tome što je analitičar u stanju da realno sagleda poslovni
proces. Ovaj pristup je efikasan, ako se dobro provede, i
obezbjeđuje pouzdanost prikupljenih informacija.
• Nedostaci posmatranja poslovnog sistema su neefikasnost, ako se
dobro ne provede, znatan utrošak vremena, ometanje i
nelagodnost posmatranih osoba, mogućnost manipulacije
posmatrača, npr. prikrivanjem uobičajenog kršenja radnih
procedura. Podaci dobijeni iz malog broja kratkotrajnih posmatranja
mogu biti nepouzdani i netačni. Posmatranje na licu mjesta je
najteža metoda za utvrđivanje činjenica.

145
 Radni sastanci
• Radni sastanci, sjednice ili radionice (engl. workshops) su tehnika
otkrivanja i analiziranja zahtjeva u kojoj ključni stejkholderi
zajednički provode analizu i oblikovanje zahtjeva. Radni sastanci
imaju unaprijed definiran dnevni red, odvijaju se u posebno
prilagođenom prostoru, koji treba pružiti ugodan ambijent i
osigurati nesmetan rad, sastankom upravlja moderator, a
zapisničar vodi detaljan zapisnik. Cilj sjednice je zajedničko
pronalaženje najboljeg rješenja.
• Osnovne prednosti ove tehnike su:
• Radni sastanci su pogodni u slučajevima kada se rješavaju problemi od općeg
interesa,
• Pruža mogućnost preciznijeg utvrđivanja dosega projekta,
• Osigurava efikasnije determiniranje proturječnih zahtjeva,
• Omogućava razrješavanje proturječnih zahtjeva.

146
• Ova tehnika ima i niz nedostataka, na primjer:
• Pasivnost stakeholdera,
• Ne rijetko dolazi do udaljavanja od osnovne teme,
• „Usitnjavanje“ razgovora,
• Sjednice bi trebale trajati više dana, međutim to je u praksi vrlo teško
ostvariti zbog obaveza stakeholdera.

• Uz radionice je usko vezana tehnika „brainstorming“, koja

stakeholdere potiče na aktivno i kreativno sudjelovanje.
Primjenjuje se tako da se od svakog stakeholdera zatraži da
definira, po njemu, idealno rješenje konkretnog problema.
Svaki stakeholder iznosi „sve što mu padne na pamet“ u
vezi s problemom koji se rješava, čime se dopunjuju već
ponuđena rješenja ili generiraju nova. Na kraju
„brainstorming“ sesije odabire se najbolje rješenje. Ova
tehnika je učinkovita u slučajevima kada su stakeholderi
dobri poznavatelji problemskog područja.

147
 Izrada prototipa (prototyping)
• Prototip kao koncept budućeg sistema dugo je vremena smatran zdravim
pristupom za dobro definiranje zahtjeva. Prototip pruža korisniku stvarnu sliku
onoga što bi softversko rješenje trebalo predstavljati. Prototip doprinosi
pozitivnom stavu korisnika prema budućem softverskom proizvodu jer mu
pomaže da shvati mogućnosti ponuđenog rješenja. Međutim, taj korisnikov
entuzijazam može predstavlja i problem, jer se pažnja posvećuje mnogim
nebitnim detaljima na unosnim formama (smještaj i veličina polja i dugmadi, boja
slova i pozadine i sl.). O samoj funkcionalnosti gotovo da se i ne razmišlja.
Problem je i što korisnik prototip smatra „skoro gotovim proizvodom“ te ne
razumije zašto treba još tako puno vremena da se to „isto“ rješenje završi i stavi u
upotrebu. Zbog toga, a i zbog lažnog osjećaja sigurnosti proizašlog iz
„zadovoljstva“ korisnika, programeri „na vrat – na nos“ iz prototipa izrađuju gotov
softverski proizvod. Preporuka je da se prototip ne koristi u analizi i prikupljanju
zahtjeva.
• Kao model rane verzije sistema daje težište na korisničko interface, ne rijetko
zanemarujući sve što se događa unutar sistema. Upravo zbog toga treba biti pažljiv
u korištenju prototipa kao tehnike za izlučivanje i analizu zahtjeva. Tehnika
prototipiranja se koristi kada korisnik ne može točno definirati svoje
informacijske potrebe prije nego što se izgradi sistem. Izrada prototipa pogodna
je u onim okruženjima gdje je teško definirati konkretni model sistema te u
okruženjima gdje se informacijske potrebe korisnika mijenjaju ili razvijaju.
148
 Storyboarding
• Svrha storyboard tehnike je steći ranu reakciju korisnika na predloženi
koncept. Ova tehnika je učinkovita u razrješavanju "Da, ali …" sindroma.
Storyboarding je iznimno jeftina tehnika koja se koristi za izlučivanje i
analizu zahtjeva, informativna je, zanimljiva je, ne zahtjevna, lagano se
kreira i modificira. Može biti realizirana kao:
– Pasivna tehnika – korisniku (stejkholderu) se opisuje problemsko područje
kroz niz skica, slika, ekranskih isječaka (engl. screen shoots), primjera
aplikacijakih izlaza i sl. i to sve uz objašnjenja tipa „kada uradite to dogodit će
se ovo“;
– Aktivna tehnika – podrazumijeva da se izradi i predstavi „operativni scenarij“,
prezentacija koja će sadržavati opis i ponašanje sistema u tipičnom,
korisničkom okružju;
– Interaktivna tehnika – izraditi takvu prezentaciju koja će korisniku omogućiti
da upozna sistem, na realan i praktičan način. Zahtijeva aktivno sudjelovanje
korisnika.
• Cilj storyboarding tehnike nije samo „pričanje priče“ o predloženom
rješenju, već se, uz predstavljanje rješenja, nastoje otkriti i mnogi
„skriveni“ zahtjevi.

149
Storyboarding primjer

150
151
152
153
 Scenariji
• Scenariji su često korištena tehnika izlučivanja zahtjeva, jer je ljudima
znatno lakše razumjeti, vizualizirati i, naposljetku, prihvatiti određena
objašnjenja koja su realizirana kroz opise iz „stvarnog života“, nego one
opise koji su i suviše apstraktni. Scenariji su upravo takva tehnika koja se
bazira na realnim primjerima načina korištenja i funkcioniranja sistema.
Tokom prezentiranja scenarija se diskutira i kritizira ponuđeni scenarij, što
omogućava otkrivanje i formuliranje zahtjeva. Ova tehnika definiranja i
formuliranja zahtjeva je integralni dio agilnih metoda (poput eksteremnog
programiranja).
• Svaki scenarij treba biti realiziran kao opis neke konkretne interakcije
korisnika sa sistemom i trebao bi sadržavati:
– Opis početne situacije;
– Opis normalnog (standardnog) toka događaja;
– Opis svega što može poći „po zlu“ i načina oporavka;
– Informacije o paralelnim aktivnostima;
– Opis stanja sistema u trenutku kada konkretni scenarij završava.
• Primjer scenarija fakultetskog knjižničnog sistema koji omogućuje
naručivanje knjiga i dokumenata iz drugih knjižnica (sistem LIBSYS, opisan
u): 154
155
 Petrijeve mreže
• Posmatranjem pojedinačnog dijagrama prijelaza stanja možemo da
uočimo trenutak kada neki objekat šalje poruku drugom objektu. Da
bismo utvrdili da li poruka koju šalje jedan objekat može biti
primljena od strane drugog objekta, moramo da istovremeno
analiziramo dijagrame prijelaza stanja oba objekta. Petrijeve mreže
(Peterson 1977) predstavljaju oblik notacije prijelaza stanja koji se
koristi za modelovanje konkurentskih aktivnosti i njihovih
interakcija.

• Krugovi u mreži predstavljaju mjesta obavljanja aktivnosti ili

provjere uslova, dok pravougaonici predstavljau prijelaze.
Usmjerene strelice, koje se nazivaju lukovi, povezuju prijelaz sa
ulaznim mjestima i izlaznim mjestima. Mjesta su popunjena
tokenima, koji predstavljaju uslove za omogućavanje prijelaza.

156
• Kada se prijelaz aktivira, uklanjaju se tokeni iz svih ulaznih
mjesta i prebacuju u izlazna mjesta. Svakom luku može biti
dodijeljena vrijednost koja definiše broj tokena koji se
uklanjaju iz ulaznog mjesta, odnosno broj tokena koji se
ubacuje u svako izlazno mjesto nakon aktiviranja prijelaza.
Prijelaz je omogućen ako u sklopu njegovih ulaznih mjesta
postoji najmanje onoliko tokena kolika je vrijednost luka,
čime nastaju uslovi za stvarno aktiviranje prijelaza.

• Petrijeve mreže imaju svoje prednosti, kao npr.

• Mogućnost definiranja i simuliranja različitih stanja i procesa u
promatranom sistemu
• Mogućnost opisivanja toka informacija i objekata kroz sistem
• Uz prednosti, naravno dolaze i nedostaci. Glavni nedostaci
Petrijevih mreža su:
• Nepreglednost
• Velik broj varijanti

157
158
159
160
Etnografija u inženjerstvu zahtjeva
• Etnografija je opisni (deskriptivni) dio etnologije,
znanost koja opisuje i proučava materijalnu,
društvenu i duhovnu kulturu (život, običaje,
vjerovanja i dr.).

• Etnografija se, dakle, procesu može koristiti kao

opservacijska tehnika, tehnika promatranja kako
ljudi stvarno rade. Etnografske studije pokazuju
da je rad obično dinamičniji i kompleksniji nego
što to sugeriraju (jednostavni) modeli sistema.
161
• Etnografija se koristi za otkrivanje dva tipa
zahtjeva:
• Zahtjeva koji proizlaze iz načina na koji ljudi stvarno rade, a
ne kako proces definira da bi ljudi trebali raditi i
• Zahtjeva koji proizlaze iz suradnje i drugih ljudskih aktivnosti.
• Ova tehnika omogućava otkrivanje nekih
kritičnih, specifičnih detalja u načinu obavljanja
poslovnih procesa, koji često promaknu u
procesu prikupljanja i analize zahtjeva drugim
tehnikama.
• Etnografija je prvenstveno fokusirana na zahtjeve
krajnjeg korisnika i kao takva ne može se smatrati
cjelovitom metodom ili tehnikom za otkrivanje
zahtjeva.
162
• Etnografija podrazumijeva dolazak jednog ili više ljudi iz
razvojnog tima u tvrtku gdje će se sistem primjenjivati i
uključivanje tih inženjera (tzv. etnografa) u
svakodnevne aktivnosti u tom okruženju.
• Svakodnevni rad korisnika se prati i zapisuju se stvarni
zadaci koje korisnici obavljaju. Na taj način otkrivaju se
implicitni zahtjevi sistema koji pokazuju stvarni način
kako ljudi rade, a ne formalne procese koje definira
organizacija.
• Etnografija se može kombinirati s izradom prototipa
sistema u tzv. fokusiranoj etnografiji, slika Ideja je da
etnograf informira ostale inženjere tijekom razvoja
prototipa, čime se smanjuje broj ciklusa poboljšavanja
prototipa. Nadalje, izrada prototipa fokusira etnogafiju
tako što otkriva probleme i pitanja koja se potom mogu
prodiskutirati s etnografom i na koje on može potražiti
odgovore kod korisnika u sljedećoj fazi razvoja.
163
164
• Etnografija nije pogodna za uočavanje novih
značajki koje treba razviti, a i teško je pomoću
nje uočiti organizacijske i domenske zahtjeve,
budući da se fokusira na krajnjeg korisnika.
Ipak, vrlo je korisna za uočavanje kritičnih
detalja u procesu koji su možda izbjegli
ostalim tehnikama izlučivanja i analize
zahtjeva. Stoga se uvijek koristi u kombinaciji s
ostalim tehnikama.

165
 PROCES VEZAN ZA ZAHTJEVE
• Naručilac koji od nas zahtijeva gradnju novog sistema
ima određeno poimanje o tome šta sistem treba da
radi. Naručilac često želi da automatizuje zadatke koji
se obavljaju ručno, kao što je elektronsko plaćanje
računa, umjesto ručnog ispisa čekova. Ponekad
naručilac želi da poboljša ili proširi postojeći ručni ili
automatizovani sistem. Naručioci sve češće žele
proizvode koji rade nešto što do tada nisu radili. Bez
obzira na to da li je određena funkcionalnost stara ili
nova, predloženi softverski sistem posjeduje namjenu,
obično izraženu ciljevima ili željenim ponašanjem.

166
• Zahtjev predstavlja izraz željenog ponašanja. Zahtjev se bavi
objektima ili entitetima, stanjima u kojima oni mogu biti,
kao i funkcijama koje se izvode radi promjene stanja ili
osobina objekta. Napomenimo da nijedan od tih zahtjeva
ne određuje način implementacije sistema.
• Nema naznaka o sistemu za upravljanje bazama podataka
koji treba da se koristi, da li će se koristiti klijent-server
arhitektura, koliko memorije treba da ima računar ili koji će
programski jezik biti korišćen za implementaciju sistema.
Opisi, koji su specifični za implementaciju, ne spadaju u
zahtjeve (osim ako ih naručilac nije striktno propisao).
• Cilj faze definisanja zahtjeva je razumijevanje problema i
potreba naručioca. Prema tome, zahtjevi su okrenuti
naručiocu i problemu, a ne rješenju ili implementaciji.
Često kažemo da zahtjevi označavaju kakvo ponašanje
naručilac želi, bez izražavanja kako će to ponašanje biti
ostvareno. Rasprava o rješenju je preuranjena sve dok se
problem jasno ne definiše.
167
• Korisno je zahtjeve opisati kao interakciju između pojava u realnom
svijetu, bez referenciranja pojava na nivou sistema. Ovaj pristup
upražnjavamo dijelom zbog toga da bismo došli do suštine potreba
naručioca jer nekada iskazane potrebe ne odražavaju stvarne.
Pored toga, problem koji naručilac ima je obično najlakše iskazati u
kategorijama njegovog poslovanja.
• Drugi razlog zbog kog upražnjavamo takav pristup je da bismo
projektantima omogućili maksimalnu fleksibilnost prilikom
donošenja odluke o načinu ispunjavanja zahtjeva. Tokom faze
specifikacije, odlučićemo koje zahtjeve će projektovani softverski
sistem da ispuni. Tokom faze dizajna, formulisaćemo plan
implementacije navedenog ponašanja.
• Na slici je prikazan proces evidentiranja zahtjeva za predloženi
softverski sistem. Izvršilac tih zadataka obično je analitičar zahtjeva
ili analitičar sistema. Analitičar zahtjeva prvo radi sa naručiocima
na izvođenju zahtjeva: postavlja pitanja, ispituje aktuelno
ponašanje ill demonstrira slične sisteme. Nakon toga zahtjeve
evidentiramo u sklopu modela ili prototipa.

168
169
• Kada se postigne dobro razumijevanje zahtjeva, posao
se nastavlja izradom specifikacije, u kojoj se odlučuje
koji će dijelovi zahtijevanog ponašanja biti
implementirani u softveru. Tokom validacije, provjerava
se da li specifikacija odgovara onome što naručilac želi
da vidi u finalnom proizvodu. Aktivnosti analize i
validacije mogu da otkriju probleme ili propuste u
modelu ili specifikaciji, što prouzrokuje ponovne
posjete naručiocu i revidiranje modela i specifikacije.
Krajnji ishod tog procesa je specifikacija softverskih
zahtjeva (Software Requirements Specification, SRS),
koja se koristi za komunikaciju sa drugim članovima
razvojnog tima (koji rade na dizajnu, testiranju i
održavanju), o tome kako konačni proizvod treba da se
ponaša.

170
 Izvođenje zahtjeva
• Izvođenje zahtjeva je posebno važan dio procesa. Moramo da
koristimo razne tehnike za utvrđivanje šta korisnici i naručioci
stvarno žele. Ponekad automatizujemo ručni sistem, tako da je
utvrđivanje šta sistem stvarno radi lako. Međutim, često moramo
da radimo sa korisnicima i naručiocima da bismo razumjeli problem
koji je potpuno nov. Taj zadatak se rijetko svodi na jednostavno
postavljanje pravih pitanja radi prikupljanja zahtjeva koje naručilac
ima u svojoj glavi. U ranoj fazi projekta, zahtjevi su nedovoljno
formulisani i nedovoljno dobro shvaćeni. Naručilac ne može uvijek,
prilikom opisivanja, dovoljno precizno iskazati šta hoće ili sta mu
stvarno treba, a mi nismo uvijek u stanju da dovoljno dobro
shvatimo tuđe poslovne probleme. Naručilac poznaje svoj posao, ali
ne može uvijek strancima da opiše svoje poslovne probleme.
Njegovi opisi sadrže žargone i pretpostavke koje nam možda nisu
bliski.

171
• Slično tome, kao projektantima, poznata su nam
računarski zasnovana rješenja, ali ne uvijek i to kako će
moguća rješenja uticati na poslovne aktivnosti
naručioca. Mi, takođe, posjedujemo vlastiti žargon i
pretpostavke, mislimo da svi govore istim jezikom, a u
stvari različiti ljudi podrazumijevaju potpuno različita
značenja iste riječi. Do zajedničkog dogovora sa svima o
tome koji su zahtjevi, dolazimo jedino raspravom o
zahtjevima sa nekim ko je zainteresovan za sistem,
objedinjavanjem tih različitih pogleda u koherentni
skup zahtjeva, kao i zajednički pregled sa
zainteresovanim subjektima dokumenata koji sadrže
zahtjeve. Ako ne možemo da se usaglasimo oko
zahtjeva, projekat je osuđen na propast.

172
• Međutim, postoji više ljudi koji mogu dati doprinos zahtjevima novog
sistema:
• Klijenti su oni koji finansiraju razvoj softvera. Finansirajući razvoj, klijenti su na neki način,
presudni zainteresovani subjekti, pa imaju konačnu riječ o tome šta proizvod treba da
radi.
• Kupci su oni koji kupuju softver nakon što je razvijen. Nekada su kupac i korisnik isti; u
nekom drugom slučaju kupac je poslovni rukovodilac zainteresovan za poboljšanje
produktivnosti svojih radnika. Moramo u dovoljnoj mjeri da razumijemo potrebe kupaca,
da bismo napravili proizvod koji će oni kupovati i smatrati korisnim.
• Korisnici, su oni koji poznaju postojeći i koji će koristiti budući sistem. Oni su stručni za
rad postojećeg sistema, poznaju njegove najkorisnije odlike, kao i dijelove sistema koji
zahtjevaju poboljšanje. Možda ćemo željeti da se posavjetujemo takođe i sa posebnim
interesnim grupama korisnika, da bismo razumjeli njihove posebne potrebe, kao što su
korisnici sa invaliditetom, osobe kojima nisu bliski računari ili ih nerado koriste, stručni
korisnici i drugi
• Stručnjaci iz konkretne oblasti primjene, su oni kojima je problem koji softver treba da
automatizuje blizak. Na primjer, konsultovaćemo stručnjaka za finansije ako gradimo
finansijski paket, ili meteorologa ako softver treba da modeluje vremenske prilike.
• Istraživači tržišta, koji sprovode istraživanja radi određivanja budućih trendova i
potencijalnih potreba korisnika. Oni mogu da pretpostave ulogu kupca ako se softver
razvija za široko tržište, pri čemu nije identifikovan nijedan poseban kupac.
• Advokati ili revizori, kojima su bliski vladini, bezbjednosni i pravni zahtjevi. Na primjer,
možemo da se posavjetujemo sa poreskim stručnjacima da bismo se osigurali da paket za
obračun zarada poštuje poreske propise. Možemo takođe da konsultujemo stručnjake za
standarde relevantne za funkcionisanje proizvoda.
• Softverski inžinjeri i drugi tehnolozi su stručnjaci osiguravaju da je proizvod tehnički i
ekonomski izvodljiv. Oni mogu da informišu naručioca o novim hardverskim i
softverskim tehnologijama i preporuče nove funkcionalnosti koje koriste prednosti tih
tehnologija. Oni mogu takođe da procijene troškove i vrijeme potrebno za razvoj
proizvoda.
173
Svi zainteresovani subjekti imaju poseban pogled na sistem i način na koji sistem treba da
funkcioniše i ti pogledi su nerijetko protivrječni. Analitičari zahtjeva moraju da razumiju
svaki pogled i da formulišu zahtjev na način koji odražava interese svih učesnika.

174
 Vrste zahtjeva
• Zahtjevi mogu biti: poslovni zahtjevi (zašto), korisnički zahtjevi (zahtjevi
krajnjih korisnika), funkcionalni zahtjevi (šta) ili nefunkcionalni zahtjevi
(kako ili kako dobro).
– Poslovni zahtjevi (zašto) definišu ciljeve organizacije (korisnički zahtjevi na
višem nivou), odnosno daju opis problema koje treba riješiti ili sadržani u
dokumentima u kojima se opisuje vizija i opseg projekta.
– Korisnički zahtjevi (zahtjevi krajnjih korisnika) opisuju zadatke koje korisnik
mora moći obaviti služeći se aplikacijama ili koji su sadržani u opisima
slučajeva korištenja, tj. opisima scenarija rada.
– Funkcionalni zahtjevi (šta) definišu softversku funkcionalnost (očekivano
ponašanje i operacije koje sistem može izvoditi), koju treba ugraditi u proizvod
da bi omogućio korisnicima obavljanje njihovih zadataka. U ovu grupu zahtjeva
spadaju posebno zanimljive mogućnosti programa, odnosno skup logički
povezanih funkcionalnih zahtjeva koje korisniku omogućavaju ispunjavanje
poslovnih zahtjeva.
– Nefunkcionalni zahtjevi (kako ili kako dobro) su standardi, pravila i ugovori
koje proizvod mora zadovoljiti, opisi vanjskih interfejsa, zahtjevi za
performansama, ograničenja za dizajn i implementaciju, te osobine kvaliteta
koje preciziraju opis proizvoda navodeći karakteristike proizvoda u različitim
dimenzijama, a bitne su ili korisniku ili projektantu.
175
• U osnovi svakog zahtjeva za softverom jeste
njegova funkcionalnost. Funkcionalni zahtjev
opisuje obavezno ponašanje u funkciji
neophodnih aktivnosti, kao što su, reakcije na
ulaze i stanja svakog entiteta prije pojave i nakon
okončanja svake aktivnosti.
• Na primjer, u slučaju sistema za obračun zarada,
funkcionalni zahtjevi definišu:
– koliko često se izdaju platni listići,
– koji ulaz je neophodan da bi se odštampao platni
listić,
– pod kojim uslovima može da se promijeni iznos za
isplatu,
– kao i koji su razlozi uklanjanja radnika sa platnog
spiska. 176
• Funkcionalnost se ogleda u sljedećem:
– Šta će sistem da radi?
– Kada će sistem to da radi?
– Da li postoji više načina rada?
– Koje vrste proračuna ili transformacija podataka moraju da
se izvedu?
– Koje su odgovarajuće reakcije na moguće stimulanse?
• Podaci o funkcionalnim zahtjevima:
– Kakav treba da bude format ulaznih i izlaznih podataka?
– Da li neki podaci moraju da budu sačuvani u nekom
vremenskom periodu?
• Zahtjev u pogledu kvaliteta, ili nefunkcionalni zahtjev,
opisuje neke karakteristike kvaliteta koje softversko
rješenje mora da posjeduje, kao što je, na primjer,
kratko vrijeme odziva, lakoća korištenja, visoka
pouzdanost ili niski troškovi održavanja.
177
• Projektno ograničenje predstavlja unaprijed donijetu
odluku, na primjer, izbor platforme ili interfejs
komponenti, koja ograničava skup mogućih rješenja
razmatranog problema.
• Izbor fizičkog okruženja treba da daje odgovore na
sljedeća pitanja:
– Gdje će biti locirana oprema?
– Da li postoji jedna ili više lokacija?
– Da li postoje neka ograničenja u pogledu okruženja, kao
što je temperatura, vlažnost ili magnetna interferencija?
– Da li postoje ograničenja u pogledu napajanja, grijanja ili
klimatizacije?
– Da li postoje ograničenja u pogledu programskih jezika
zbog postojećih softverskih komponenti?

178
• U pogledu izbora interfejsa sljedeća su pitanja:
– Da li se ulaz preuzima iz jednog sistema ili iz više
različitih sistema?
– Da li se izlaz proslijeđuje jednom sistemu ili većem
broju različitih sistema?
– Da li je propisan način formatizovanja ulaznih i izlaznih
podataka?
– Da li je propisan nosilac podataka?
• U pogledu korisnika trebamo znati:
– Ko će koristiti sistem?
– Da li će biti više vrsta korisnika?
– Koji je nivo vještine svakog korisnika?

179
• Procesno ograničenje predstavlja ograničenje koje se
odnosi na tehnike ili resurse koji se mogu koristiti u
izgradnji sistema. Na primjer, naručilac može da
insistira na primjeni agilnih metoda, da bi mogao
operativno koristiti rane verzije sistema uz kontinuirano
proširivanje njihove funkcionalnosti.
• Resursi potrebni za procesna ograničenja:
– Koji su materijali, osoblje ili drugi resursi potrebni za
gradnju sistema?
– Koje vještine moraju posjedovati učesnici u razvoju?
• Dokumentacija za procesna ograničenja:
– Koliko je dokumentacije potrebno?
– Treba li da bude na računaru, u obliku knjige ili oboje?
– Kome je namijenjen svaki tip dokumentacije?
180
• Zahtjevi u pogledu kvaliteta ponekad zvuče kao
„majčinske“ karakteristike koje svi proizvodi treba
da posjeduju. Nakon svega, ko bi zahtijevao
softverski sistem koji je spor, neprijateljski,
nepouzdan i težak za održavanje. Bolje je zahtjeve
u pogledu kvaliteta posmatrati kao kriterijum
projektovanja koji može da se optimizuje i koristi
za izbor između različitih načina za
impelmentaciju funkcionalnih zahtjeva. Ako
usvojimo takav pristup, tada zahtjevi treba da
daju odgovor na slijedeće pitanje: Do kog
stepena mora proizvod da zadovolji zahtjeve u
pogledu kvaliteta da bi bio prihvatljiv?
181
• Performanse u pogledu kvaliteta:
– Da li postoje ograničenja u pogledu brzine izvršavanja,
vremena odgovora ili propusnosti?
– Čime će se mjeriti efikasnost korištenja resursa i
vrijeme odgovora?
– Koliki je protok podataka kroz sistem?
– Koliko se često podaci primaju i šalju?
• Upotrebljivost i ljudski faktori:
– Koja vrsta obuke će biti potrebna za svaki tip
korisnika?
– Koliko će lako korisnik da razumije i upotrebljava
sistem?
– Koliko će teško korisnik da na odgovarajući način
koristi sistem?

182
• Bezbjednost:
– Da li pristup sistemu ili informacijama mora da bude kontrolisan?
– Da li podaci jednog korisnika moraju da budu izolovani od podataka
drugih korisnika?
– Da li korisnički programi moraju da budu izolovani od drugih programa
ili od operativnog sistema?
– Da li treba da se preduzmu mjere obezbjeđenja od krađe ili
vandalizma?
• Pouzdanost i raspoloživost:
– Da li sistem mora da detektuje i izoluje greške?
– Koje je propisano srednje vrijeme između otkaza?
– Da li postoji maksimalno dopušteno vrijeme za ponovno pokretanje
sistema nakon otkaza?
– Koliko često se prave rezervne kopije?
– Da li se rezervne kopije moraju čuvati na drugoj lokaciji?
– Da li moraju da se preduzmu mjere obezbjeđenja od požara ili
poplave?

183
• Mogućnost održavanja:
– Da održavanje uključuje samo ispravljanje grešaka ili poboljšanja
sistema?
– Kada i na koje načine može sistem da se izmjeni u budućnosti?
– Koliko će biti lako dodavanje novih svojstava u sistem?
– Koliko će biti lako prenošenje sistema sa jedne platforme
(računar, operativni sistem) na drugu?
• Preciznost i tačnost:
– Koliko tačne moraju da budu izračunate vrijednosti podataka?
– Do kog stepena preciznosti moraju da se obavljaju proračuni?
• Vrijeme do isporuke/cijena:
– Da li postoji definisano vrijeme potrebno za razvoj?
– Da li postoji ograničenje iznosa novca koji se može potrošiti na
razvoj, hardver ili softver?

184
 RJEŠAVANJE KONFLIKATA
• Prilikom pokušaja iskazivanja zahtjeva korisno je tražiti da naručilac odredi
prioritete zahtjeva. Taj zadatak primorava naručioca da ukaže na
najvažnije neophodne osobine ili usluge. Okvirna šema prioriteta mogla bi
da klasifikuje zahtjeve u tri kategorije:

– Zahtjevi koji apsolutno moraju da se zadovolje (suštinski zahtjevi),

– Zahtjevi koji su veoma poželjni, ali nisu nužni (poželjni zahtjevi),
– Zahtjevi koji se mogu ispuniti, ali se mogu i izostaviti (opcioni zahtjevi).

• Primjer sistema za naplatu preko kreditnih kartica ilustruje sva tri

zahtjeva.
1. Sistem mora da bude sposoban da prikaže spisak trenutnih dugovanja,
da ih sabere i zahtijeva plaćanje do određenog datuma, što je suštinski
zahtjev.
2. Sistem za naplatu može da razdvoji dugovanja po načinu naručivanja, da
bi naručiocu pomogao u razumijevanju šablona za kupovinu, što je
poželjan zahtjev, koji vjerovatno nije neophodan.
3. Na kraju, sistem može da štampa potraživanja u crnoj, dugovanja u
185
crvenoj boji, što bi bilo korisno, ali je opciono.
• Dodjeljivanje prioriteta zahtjevima njihovom kategorizacijom
pomaže svim učesnicima da bolje shvate šta je stvarno potrebno. To
je posebno korisno ako je projekat razvoja softvera ograničen sa
aspekta vremena ili drugih resursa. Ako će definisani sistem biti
skup, ili zahtijevati mnogo vremena za razvoj, tada opcioni zahtjevi
mogu da se izostave, a poželjni analiziraju sa ciljem eliminisanja ili
odlaganja realizacije za kasnije verzije.
• Često se dešava da su dva atributa kvaliteta u konfliktu tako da je
nemoguće optimizacijom oba zadovoljiti. Ukoliko se od sistema traži
da se lako održava i da ima kratko vrijeme odziva, onda projektno
rješenje koje olakšava održavanje može da radi sporije čime se
narušava performansa. Isto tako, fino podešavanje sistema, tako da
radi posebno dobro na jednoj platformi, utiče na prenosivost na
druge platforme, dok bezbjednosni sistemi nužno kontrolišu pristup
i time ograničavaju raspoloživost nekim korisnicima.

186
• Dodjeljivanje prioriteta zahtjevima u pogledu kvaliteta primorava naručioca da
odabere one faktore kvaliteta softvera koji su njemu najvažniji, što nam pomaže da
obezbjedimo razumno, ako ne i optimalno, rješenje za postavljene zahtjeve u
pogledu kvaliteta.
• Kako možemo da testiramo da li proizvod zadovoljava zahtjev? Relativno je lako
odrediti kriterijum usklađenosti za zahtjeve u pogledu kvaliteta koji su
kvantitativne prirode. U tim slučajevima, razvojni tim koristi fokus grupe ili metriku
za procjenjivanje kriterijuma usklađenosti:

– 75 % korisnika treba da ocijeni da li je novi sistem jednako upotrebljiv kao i postojeći,

– Nakon obuke, 90 % korisnika treba da bude u stanju da obradi novi nalog u roku od 5 minuta,
– Greške u proračunu treba da se isprave u roku od tri nedjelje od trenutka prijavljivanja.

• Zanimljivo je da sve ono što se mjeri biva i urađeno, što znači da će kriterijum biti
ispunjen, osim ako je nerealan.

• Šta ako ne možemo da zadovoljimo kriterijum usklađenosti? Onda je došao

trenutak za pregovaranje i ponovno ocjenjivanje pogleda svih zainteresovanih
subjekata. Pregovaranje nije lako, jer zahtijeva sposobnost, strpljenje i iskustvo u
pronalaženju uzajamno prihvatljivih rješenja. Sukobi se obično javljaju oko
različitih pristupa ili ograničenja vezanih za rješavanje problema (na primjer, neki
zainteresovani subjekti mogu da insistiraju na upotrebi drugačijih sistema za
rukovanje bazama podataka, drugih algoritama za šifriranje, drugačijih korisničkih
interfejsa ili drugih programskih jezika).

187
 KARAKTERISTIKE ZAHTJEVA
• Uspješnosti krajnjeg proizvoda doprinosi visoka kvaliteta zahtjeva. Obično
ono što nije specifikovano se i ne realizuje. Predmet kasnije provjere su
sljedeće osobine:
– Da li su zahtjevi ispravni? Dokumentovani zahtjevi se moraju pregledati kako
bismo se uvjerili da li su oni usklađeni sa našim shvatanjem zahtjeva.
– Da li su zahtjevi dosljedni? Ako jedan zahtjev navodi da maksimalno 10
korisnika može da koristi sistem u jednom trenutku, a drugi zahtjev dozvoljava
20 korisnika, tada se za ta dva zahtjeva kaže da su nedosljedni. U opštem
slučaju, dva zahtjeva su nedosljedna ako ih je nemoguće istovremeno
zadovoljiti.
– Da li su zahtjevi nedvosmisleni? Za zahtjeve kažemo da su višeznačni ako više
osoba koje analiziraju dokument sa zahtjevima dođu do različitih, ali ispravnih
interpretacija.
– Da li su zahtjevi kompletni? Zahtjevi su kompletni ako specifikuju zahtjevano
ponašanje i izlaz za sve moguće kombinacije ulaza u svim mogućim stanjima i
pod svim mogućim ograničenjima. Primjer za to je sistem za obračun zarada,
gdje je neophodno definisati šta se događa kada radnik uzme neplaćeno
odsustvo, dobije povišicu, ili traži akontaciju. Ovdje postoje eksterno i interno
kompletni zahtjevi. Eksterno kompletni zahtjevi sva stanja, promjene stanja,
ulaze, proizvode i ograničenja opisuju u sklopu nekog zahtjeva. Opis zahtjeva je
interno kompletan ako ne postoje nedefinisani pojmovi unutar zahtjeva. 188
 – Da li su zahtjevi izvodljivi? Ovdje je potrebno znati da li postoji rješenje za potrebe naručioca.
(primjer zahtjeva naručioca koji želi da korisnici pristupe glavnom računaru udaljenom više
hiljada kilometara daleko i da vrijeme odziva bude za udaljene korisnike jednako kao i za
lokalne korisnike). Pitanja izvodljivosti često iskrsavaju kada naručilac postavlja dva ili više
zahtjeva u pogledu kvaliteta, kao što je jeftin sistem koji analizira ogromne količine podataka i
produkuje rezultate analize u nekoliko sekundi.
– Da li je svaki zahtjev relevantan? Zahtjev nekada nepotrebno ograničava razvojni tim ili
uključuje funkcionalnosti koje nisu u direktnoj vezi sa potrebama korisnika. (general treba da
odluči da novi softverski sistem tenka omogući vojnicima slanje i primanje elektronske
pošte, iako tenk ima osnovnu namjenu da savlada neravan teren). Treba pomoći
zainteresovanim subjektima da se usredsrede na suštinske i poželjne zahtjeve.
– Da li je zahtjeve moguće testirati? Za testiranje zahtjeva potrebno je formulisati testove koji
demonstriraju da li konačni proizvod zadovoljava te zahtjeve. Ako sistem treba da nam daje
„odgovor u realnom vremenu“, mi ne znamo šta je to, dok ne definišemo vremenski rok u
kojem će sistem reagovati na upite.
– Da li zahtjevi mogu da se prate? Svaka stavka u definiciji zahtjeva treba imati odgovarajuću
stavku u specifikaciji zahtjeva, i obrnuto.

• Ove karakteristike možemo da posmatramo kao funkcionalne zahtjeve i zahtjeve u

pogledu kvaliteta koji prate skup zahtjeva vezanih za proizvod. Stepen do kojeg
želimo da ih zadovoljimo direktno utiče na sveobuhvatnost rješenja i tip
informacija koje sakupljamo u procesu iskazivanja zahtjeva, kao i na izbor jezika za
specifikaciju zahtjeva i provjere koje je potrebno izvršiti u cilju validacije i
verifikacije zahtjeva.

189
 DVIJE VRSTE DOKUMENATA O
ZAHTJEVIMA
• Zahtjeve koriste različiti ljudi za različite namjene.
– Analitičari zahtjeva i njihovi klijenti koriste zahtjeve za iskazivanje
stepena razumljivosti ponašanja sistema.
– Projektanti tretiraju zahtjeve kao ograničenja vezana za utvrđeno
prihvatljivo rješenje.
– Tim za testiranje na osnovu zahtjeva formuliše grupu završnih testova,
koji će se koristiti da bi se naručiocu pokazalo da mu se isporučuje
sistem koji je i naručen.
– Zahtjevi su pomoć timu za održavanje, na osnovu koje se ovaj tim
stara da unapređenja sistema (ispravke grešaka, nove osobine) ne
utiču na originalnu namjenu sistema.
• Ponekad samo jedan dokument može da posluži za sve navedene
namjene i time dovede do uzajamnog razumijevanja naručioca,
analitičara zahtjeva i razvojnog tima. Često su, međutim, potrebna
dva dokumenta: definicija zahtjeva namijenjena poslovnom
auditorijumu, kao što su kupci, naručioci i korisnici i specifikacija
zahtjeva namijenjena tehničkom auditorijumu, kao što su
projektanti, timovi za testiranje i rukovodioci projekata. 190
• Definicija zahtjeva predstavlja kompletan spisak svega što naručilac
želi da postigne. Dokument sadrži neophodne zahtjeve, opis
entiteta koji pripadaju okruženju u kojem će predloženi sistem biti
instaliran, kao i željena ograničenja u vezi sa entitetima, u vezi sa
nadgledanjem tih entiteta, ill u vezi sa transformacijom tih entiteta.
Definiciju zahtjeva obično zajedno pišu naručilac i analitičar, i ona
predstavlja ugovor koji sadrži opis funkcionalnosti koju razvojni tim
prihvata da isporuči naručiocu.
• Specifikacija zahtjeva iskazuje zahtjeve u vidu specifikacije
ponašanja predloženog sistema. Specifikacija je takođe iskazana u
smislu okruženja, s torn razlikom što referencira jedino one entitete
kojima može da se pristupi iz sistema posredstvom njegovog
interfejsa. Na taj način, granica sistema čini eksplicitnim one
entitete iz okruženja u koje sistem ima uvid ili koje direktno
kontroliše.
– Specifikaciju zahtjeva piše analitičar, a koriste je ostali učesnici u
razvoju softvera. Analitičar mora obezbjediti da ne dođe do gubitka
informacije ili izmjena u postupku pretvaranja zahtjeva u specifikaciju.
Mora se uspostaviti jednoznačna korenspondencija između svakog
zahtjeva koji pripada dokumentu definicije zahtjeva i zahtjeva u
specifikacionom dokumentu.
191
 Upotreba prototipova
• Korisnici budućeg sistema često ne uspijevaju jasno izraziti svoje
zahtjeve, budući da ne mogu predvidjeti kako će taj sistem
utjecati na njihove radne navike, u kakvoj će interakciji biti s
drugim sistemima, te u kojoj mjeri on može automatizirati radne
procese. Tada se pribjegava izradi prototipa. Riječ je o
jednostavnom i brzo razvijenom programu, koji oponaša budući
sistem, lako se mijenja i nadograduje, te omogućuje
isprobavanje raznih ideja, koncepcija i opcija. Prototip podržava
dvije podaktivnosti unutar aktivnosti specifikacije:
• Otkrivanje zahtjeva. Korisnici eksperimentiraju, pa tako otkrivaju svoje
potrebe i dobivaju nove ideje o tome što bi sistem trebao raditi.
• Validacija zahtjeva. Uočavaju se greške i propusti u polaznim
zahtjevima, na primjer nepotpuni ili nekonzistentni zahtjevi.

192
• Osim toga, prototip može donijeti sljedeće
dodatne koristi.
– Otkrivaju se nesporazumi između razvijača
softvera i korisnika.
– Lakše se identificiraju komplicirane funkcije koje
zahtijevaju pozornost.
– Managementu se demonstrira izvedivost i
korisnost sistema.

193
 Mjesto prototipiranja unutar
softverskog procesa
• U praksi se pojam prototipiranja često miješa s pojmom
istraživačkog programiranja, dakle razvoja softvera po modelu
evolucijskog razvoja. Razlike između ta dva pojma su sljedeće.
– Cilj istraživačkog programiranja je postepeno dotjerivanje “prototipa”
u skladu sa zahtjevima koji se otkrivaju, sve dok se taj “prototip” ne
pretvori u konačni sistem. Prioritet kod implementiranja zahtjeva
imaju oni koji su najjasniji i korisnicima najpotrebniji.
– Cilj “pravog” prototipiranja je otkrivanje i validacija zahtjeva. Prioritet
kod implementiranja zahtjeva imaju baš oni koji su nejasni i koje treba
istražiti. Nakon utvrdivanja zahtjeva prototip se “baca”, a sistem se
dalje oblikuje i implementira na konvencionalni način.
• U slučaju “pravog” prototipiranja, cjelokupni softverski proces.
Pritom treba biti oprezan u izboru dijelova iz prototipa, budući da su
oni često loše strukturirani, loše dokumentirani, imaju slabe
performanse, slabu pouzdanost, te ne zadovoljavaju zahtjeve
sigurnosti.

194
195
 Tehnike za prototipiranje
• Da bi prototipiranje imalo smisla, sam prototip se mora stvoriti na brz,
jeftin i fleksibilan način. Za to su nam potrebne odgovarajuće razvojne
tehnike, koje možemo ovako klasificirati.
• Razvoj u dinamičnim jezicima visoke razine. Riječ je o programskim
jezicima koji su velikom dijelom interpretirani, te zahtijevaju glomaznu
run-time okolinu. Programi se pišu brzo i jednostavno te se na dinamički
način mijenjaju, makar su njihove performanse obično slabe zbog
interpretiranja i run-time podrške. Primjeri takvih jezika vide se u Tablici

196
• Programiranje za baze podataka. Svi komercijalni sistemi za upravljanje
bazama podataka opskrbljeni su vlastitim alatima za izradu aplikacija koje
obavljaju uobičajene radnje s podacima: ažuriranje, pretraživanje, izrada
izvještaja. Takvi alati nazivaju se jezici 4. generacije (engleska kratica 4GL) i
sastoje se od dijelova koji se vide na Slici. Jezik za rad s bazom je u velikoj
mjeri neproceduralan, te uključuje SQL. Generator sučelja omogućuje
oblikovanje zaslonskih formulara (prozora) ili web stranica za unos ili prikaz
podataka iz baze. Spreadsheet omogućuje analizu, manipulaciju i
računanje s podacima. Generator izvještaja omogućuje oblikovanje
štampanih izvještaja.

197
• Povezivanje gotovih dijelova ili aplikacija. Prototip se slaže
od već gotovih dijelova. U tu svrhu moramo imati na
raspolaganju dovoljan broj upotrebljivih gotovih dijelova,
te okvir ili mehanizam za povezivanje tih dijelova. Takoder
moramo biti spremni na odredene kompromise u
specifikaciji samog prototipa. Opća shema za povezivanje
dijelova ili aplikacija izgleda kao na Slici

198
 Uloga, prednosti i mane formalne
specifikacije
• Formalna specifikacija je neophodna ukoliko se služimo modelom
formalnog razvoja softvera. Kod drugih modela softverskog procesa ona
nije nužna, no može se koristiti ukoliko želimo razviti najprecizniju vrstu
opisa zahtjeva, a to je specifikacija softverskog designa
• U tom drugom slučaju, mjesto formalne specifikacije je na granici između
specifikacije i oblikovanja, prema Slici Rezultati formalne specifikacije
prvenstveno su namijenjeni razvijačima softvera, kao polazište za daljnje
oblikovanje, implementaciju i verifikaciju.

199
• Prednosti formalne specifikacije su sljedeće.
– Bolji uvid u zahtjeve, otklanjanje nesporazuma, smanjenje mogućnosti
greške (što sve pridonosi pouzdanosti softvera).
– Mogućnost analiziranja zahtjeva matematičkim metodama (potpunost,
konzistentnost).
– Može služiti kao podloga za formalnu verifikaciju implementiranog
sistema.
– Mogućnost “animacije” specifikacije u svrhu prototipiranja.
• Mane formalne specifikacije su sljedeće.
– Nerazumljiva je korisnicima i managementu.
– Zahtijeva posebno osposobljene softverske inženjere.
– Nije pogodna za interaktivne sisteme ili grafička sučelja.
– Ne da se dobro skalirati, naime za imalo veći sistem količina posla je
prevelika.
• U skladu s ovim prednostima i manama, formalne metode se
za sada koriste jedino za razvoj manjih dijelova pojedinih
sistema, tamo gdje se zahtijeva izuzetno velika pouzdanost i
sigurnost.
200
 IZRADA PROTOTIPA ZAHTJEVA
• Prilikom pokušaja definisanja zahtjeva, možemo utvrditi da
naručioci nisu sasvim sigurni šta tačno žele ili šta im je stvarno
potrebno. Iskazivanje zahtjeva može da rezultuje „spiskom želja" sa
veoma malo detalja ili bez jasne naznake da li je taj spisak potpun.
Ti isti naručioci, koji su neodlučni u svojim zahtjevima, bez teškoća
razlikuju isporučeni sistem koji zadovoljava njihove potrebe i
sistem koji ih ne zadovoljava. U stvari, većina ljudi nalazi da je lakše
detaljno kritikovati postojeći proizvod nego jednako detaljno
zamisliti novi. Prema tome, jedan način kako možemo da saznamo
detalje jeste da izradimo prototip predloženog sistema i da tražimo
povratnu informaciju od potencijalnog korisnika o tome koje
aspekte bi volio poboljšati, koje odlike nisu dovoljno korisne, ili koja
funkcionalnost nedostaje. Izrada prototipa može takođe da
pomogne pri utvrđivanju izvodljivosti rješenja za naručiocev
problem, kao i u traženju opcija za optimizaciju zahtjeva sa aspekta
kvaliteta.

201
• Kod izrade prototipa postoje dva pristupa: prototip koji se baca i
evolutivni prototip.
• Prototip koji se baca predstavlja softver koji se razvija radi boljeg
upoznavanja sa problemom ili predloženog rješenja i koji ne
predstavlja dio softvera koji se isporučuje. Taj pristup nam
omogućava da napišemo „brz i prljav" softver koji je loše
strukturisan, neefikasan, bez provjere grešaka, i koji vjerovatno
predstavlja samo fasadu koja ne implementira ništa od željene
funkcionalnosti, ali nas brzo dovodi do srži problema ili predloženog
rješenja. Kada na naša pitanja dobijemo odgovarajuće odgovore,
bacamo prototipski softver i započinjemo inžinjerski posao na izradi
softvera koji će biti isporučen.
• Nasuprot tome, evolutivni prototip predstavlja softver koji se
razvija ne samo da nam pomogne da odgovorimo na pitanja, već da
bi bio ugrađen u finalni proizvod. Zato, moramo da budemo mnogo
pažljiviji pri njegovoj izradi, jer taj softver na kraju treba i da
zadovolji zahtjeve u pogledu kvaliteta (na primjer, brzinu odziva,
modularnost) finalnog proizvoda, jer je kvalitet nemoguće
naknadno ugrađivati u finalni proizvod.

202
 15

Prototipovi zahtjeva (1)

 kada naručilac nije siguran šta tačno želi, lista zahtjeva ima malo detalja

 međutim, kada je proizvod gotov, korisnik dobro zna da li zadovoljava

njegove potrebe (lakše je kritikovati postojeći proizvod nego osmisliti novi)

 u ovom slučaju, jedini način da se sazna više detalja o proizvodu jeste

da se napravi njegov prototip

 prototip je djelimično razvijen proizvod koji omogućava sagledavanje različitih

aspekata sistema

 uloga prototipa

• korisnik uočava koja funkcionalnost nedostaje, koje osobine nisu

dovoljno korisne, koja su poboljšanja neophodna
• projektant ispituje izvodljivost rješenja i mogućnosti optimizacije
 16

Prototipovi zahtjeva (2)

Vrste prototipova

Ilustrativni prototip Evolutivni i prototip

•softver koji se razvija radi boljeg
upoznavanja sa problemom

•ne ulazi u konačni proizvod •razvija se sa ciljem da bude deo

•ne mora se voditi računa o kvalitetu, gotovog proizvoda
efikasnosti, provjeri grešaka •pažljivo se razvija, vodeći računa o
•brzo dovodi do suštine problema ili kvalitetu, odzivu, modularnosti,...
rješenja

•kad se dobiju odgovori, odbacuje se i

prelazi na razvoj softvera
 17

Primjer prototipa
Naručioci softvera: psiholozi i predavači koji izvode vježbe

Korisnici softvera: klijenti koji rade vježbe

Zadatak: korisnici treba da unesu datume izvođenja vježbi (ne moraju da poznaju
rad na računaru)

Ako nije jasno kakounos (korisnički interfejs) treba da izgleda, mogu se napraviti
dva prototipa:

Avgust 2011.
Dan: PUSČPSN
1234567
Mjesec: 8 9 10 11 12 13 14
15 16 17 18 19 20 21
Godina: 22 23 24 25 26 27 28
29 30 31
 18

Modelovanje ponašanja

Modelovanje ponašanja sistema na osnovu prikupljenih zahtjeva doprinosi:

 boljem razumjevanju zahtjeva

 lakšem uočavanju pitanja koja treba postaviti naručiocu/korisniku

 lakšem nalaženju nedostataka (nepoznato ponašanje u pojedinim

situacijama)

 lakšem otkrivanju nedosljednosti u zahtjevima (na pr. isti ulaz daje

različite izlaze)
 19

Metode modelovanja

 ER dijagrami (Entity Relationship diagrams)

 Tragovi događaja

 Konačni automati
 20

ER dijagrami (1)
Chen,1976.g.
 grafička notacija za predstavljanje konceptualnih modela koja daje
strukturiran pogled na problem

 identifikuje objekte i entitete u sistemu, njihove osobe i međusobne

odnose

 osim za modelo je zahtjeva, koristi se i za modelovanje dizajna

sistema, strukture softvera, baze podataka,...

 stabilan model (promene zahtjeva se uglavnom odnose na izmjene u

ponašanju entiteta, dok se skup entiteta ne mjenja)

 nivo detalja modelovanja nije lako odrediti (šta su entiteti, a šta atributi)

 koriste se u složenijim slučajevima

 21

ER dijagrami (2)
Primjer: obrtna kapija u zoo vrtu (Jackson i Zave, 1995.)

Osnovni elementi na dijagramu: entiteti (žuto), atributi (plavo), relacije (tip relacije -
roze), kardinalnost

vrijednost cijena ulaznice

m 1
ima Novčić ubačen OtvorZaNovčić
1
Posjetilac
n
ulazi 1 Rampa
zaključana
broj ulazaka
 22

Tragovi događaja (1)

 grafički opis niza događaja koji se razmenjuju između entiteta
(ponašanje)

 opis se sastoji od vertikalnih i horizontalnih linija

vertikalne linije
• vremenske ose, vrijeme teče na dole
• na vrhu ose je naziv entiteta na koji se linija odnosi
horizontaln
• predstavljaju same događaje, tj. interakciju između entiteta
• mogu se shvatiti kao poruke koje entiteti razmjenjuju

 zahtjev se dekomponuje na scenarije, a onda se za svaki scenario napravi trag

 svaki dijagram predstavlja jedan trag od više mogućih

 precizna i razumljiva semantika, pa se tragovi događaja često primjenjuju

 ne koriste se za kompletno modelovanje, jer bi broj tragova bio preveliki, već

samo u početnoj fazi za ključne zahtjeve
 23

Tragovi događaja (2)

Primjer: obrtna kapija u zoo vrtu

obrtna obrtna
posjetilac rampa rampa
novčić žeton
guranje žeton
rotacija žeton
novčić novčić
guranje guranje
rotacija rotacija
 24

Konačni automati (1)

 grafički opis komunikacije između sistema i okruženja

 definišu dinamičko ponašanje, tj. promene u ponašanju sistema usled nekih

događaja

 posebno pogodni za modelovanje različitog ponašanja izlaza sistema kada se na

njegov ulaz dovede fiksna vrijednost (sistemi kod kojih izlaz ne zavisi samo od ulaza, već i
od trenutnog stanja sistema)

 mogu se naći u određenom broju stanja

 stanju odgovara stabilan skup uslova koji važe u intervalu između dva događaja

 do promjene stanja dolazi usljed pojave događaja koji mjenja uslove u sistemu
(pobudni događaj)

 prelazi bez efekta se ne modeluju, da ne bi opterećivali model

 25

Konačni automati (2)

Primjer: obrtna kapija u zoo vrtu

Notacija: čvorovi, tj. stanja (žuto), grane, tj. prelasci iz stanja u stanje (crno),
pobudni događaji (plavo)

žeton/zvuk

novčić
zaključana otkuljučana

rotirana guranje

rotira
 DOKUMENTOVANJE ZAHTJEVA
• Bez obzira na to koji metod za definisanje zahtjeva
odaberemo, moramo da održavamo dokumenta u
kojima su evidentirani rezultati. Zajedno sa
naručiocima ćemo se pozivati na te dokumente tokom
razvoja ili održavanja. Stoga zahtevi moraju da budu
dokumentovani tako da budu korisni ne samo
naručiocu, već i tehničkom osoblju u našem
razvojnom timu.
• Na primjer, zahtjevi moraju da budu organizovani na
takav način da mogu da se prate tokom razvoja
sistema. Jasne i precizne ilustracije i dijagrami koji
predstavljaju prateću dokumentaciju, treba da budu
usaglašeni sa tekstom. Takođe je važan i nivo na
kojem su napisani zahtjevi.
214
 Definisanje zahtjeva
• Definisanje zahtjeva predstavlja evidentiranje zahtjeva uz oslonac na
terminologiju naručioca. Radeći sa naručiocem, dokumentujemo šta
naručilac može da očekuje od isporučenog sistema:
– 1. Prvo skiciramo opštu namjenu i opseg sistema, uključujući relevantne
koristi i ciljeve. Veze sa drugim zavisnim sistemima se takođe uključuju, pri
čemu navodimo terminologiju, označavanje i korisne skraćenice
– 2. Dalje, opisujemo porijeklo i razloge koji stoje iza prijedloga novog sistema.
Na primjer, ako sistem treba da zamijeni neki postojeći pristup, objasnićemo
zašto je postojeći pristup nezadovoljavajući. Aktuelni metodi i procedure se
dovoljno detaljno skiciraju, tako da možemo da odvojimo elemente kojima je
naručilac zadovoljan, od onih u koje se razočarao.
– 3. Nakon što zapišemo taj pregled problema, opisujemo suštinske
karakteristike prihvatljivog rješenja. Taj zapis obuhvata kratke opise suštine
funkcionalnosti proizvoda, na nivou slučajeva korišćenja. Zapisi takođe
obuhvataju zahtjeve u pogledu kvaliteta, kao što je pitanje vremena, tačnosti i
odgovora na otkaze. U idealnom slučaju dodijelićemo prioritete zahtjevima i
identifikovati one koji mogu da se ostave za kasnije verzije sistema.

215
 26

Formulisanje zahtjeva (1)

Da bi zahtjevi bili dobro formulisani, potrebno je obezbijediti:

 dobru organizaciju zahtjeva

 jasne tekstualne opise zahtjeva

 preciznu prateću dokumentaciju u vidu raznih dijagrama

i ilustracija
 27

Formulisanje zahtjeva (2)

Dokumentovanje zahtjeva

Definicija zahtjeva Specifikacija zahtjeva

• dokument namenjen
poslovnomauditorijumu (kupcima,
naručiocima, korisnicima)
• kompletan spisak zahtjeva naručioca
• interakcija sa okruženjem
• entiteti iz okruženja i ograničenja
vezana za entitete
• dokument namenjen
tehničkomauditorijumu (projektantima,
rukovodiocima projekta, timovima za
testiranje, održavanje)
• zahtjevi o ponašanju softvera
• samo entiteti iz okruženja kojima
se pristupa putem nekog
interfejsa

Analitičar mora da uspostavi jednoznačnu vezu između

svakog zahtjeva u Definiciji i Specifikaciji zahtjeva.
 28

Formulisanje zahtjeva (3)

Primjer: obrtna kapija u zoo vrtu

Definicija zahtjeva
1. Niko ne može da uđe u zoološki vrt bez plaćene ulazni

2. Sistem ne može da spriječi onoga ko je platio ulaz da uđe u zoo vrt.

Neispunjiv zahtjev bi bio:

2a. Svakome ko plati kartu treba obezbijediti da uđe u zoološki vrt.

Specifikacija zahtjeva
1. Kada posetilac gurne otključanu obrtnu kapiju, ona se automatski rotira za
jedan polukrug, nakon čega se sama zaključava.
 29

Definicija zahtjeva
Način izrade dokumenta - sadržaj
 skicirati opštu namjenu sistema, uključujući ciljeve, veze sa drugim sistemima,
uz uvođenje terminologije, oznaka, skraćenica i sl.

 navesti razloge za razvojsistema (zašto je postojeći sistem nezadovoljavajući, pa treba

razvijati novi, koje delove postojećeg sistema treba zamjeniti, a koje ne i dr.)

 opisati rješenje koje se predlaže kroz prikaz osnovnih funkcionalnosti na nivou

slučajeva korišćenja

 opisati okruženje u kome će sistem da radi (navođenje svih hardverskih i

softverskih komponenata sa kojima će sistem biti u interakciji)

 navesti pretpostavke vezane za ponašanje okruženja (uslovi koji mogu dovesti

do otkaza sistema, kao i eventualne promjene u okruženju koje mogu dovesti
do promjena zahtjeva)
 30

Specifikacija zahtjeva
Način izrade dokumenta - sadržaj
 detaljno opisati sve ulaze i izlaze (interfejs sistema), uključujući izvore ulaza,
odredišta izlaza, dozvoljene opsege i formate ulaznih i izlaznih veličina,
protokole razmjene podataka, vremenska ograničenja,

 prikazati zahtjevanu funkcionalnostpomoću ulaza i izlaza korisničkog interfejsa,

uključujući provjere ispravnosti ulaznih i izlaznih veličina; za sve moguće vrijednosti
na ulazu, mora biti poznata vrijednost na izlazu; ovde se mogu koristiti različite
tehnike modelovanja (konačni automati, tragovi događaja i dr.)

 utvrditi usklađenost svakog zahtjeva sa kriterijumom koji naručilac postavlja u

pogledu kvaliteta
 31

IEEE standard za specifikaciju

1. Uvod u dokument 3. Specifični zahtjevi
1.1 Namena proizvoda 3.1 Zahtevi spoljašnjih interfejsa
1.2 Opseg proizvoda 3.1.1 Korisnički interfejsi
1.3 Akronimi, skraćenice, definicije 3.1.2 Hardverski interfejsi
1.4 Reference 3.1.3 Softwerski ofterski interfejsi
nikacioni interfejsi
2. Opšti opis proizvoda .2 Funkcionalni zahtevi
2.1 Kontekst proizvoda 3.2.1 Klasa 1
2.2 Funkcije pro oda 3.2.2 Klasa 2
2.3 Karakteristike korisnika ...
2.4 Ograničenja 3.3 Zahtjevi u pogledu performansi
2.5 Pretpostavke i zavisnosti 3.4 Projektna ograničenja
3.5 Zahtjevi u pogledu kvaliteta
3.6 Ostali zahtjevi

4. Dodaci
 32

Kvalitet zahtjeva
Procena kvaliteta se zasniva na odgovorima na pitanja:

 Da li su zahtjevi ispravni? (odgovaraju shvatanjima naručioca)

 Da li su zahtjevi dosledni? (zahjtevi mogu biti istovremeno ispunjeni)

 Da li su zahtjevi nedvosmisleni?(više osoba isto interpretira zahtjeve)

Primjer: “...odstupanje položaja osovine je malo”
 Da li su zahtevi kompletni?(uzete u obzir sve moguće kombinacijeulaza)
Primjer: neplaćeno odsustvo, odmor, povišica, akontacija,...

Primjer: oprečni zahtjevi kao jeftin sistem, brz, sa obradom velike količine podataka
 Da li je svaki zahtjev relevantan?
Primjer: simulator tenka – posada šalje e-mail poruke (teška realizacija)
 Da li je zahtjeve moguće testirati? (testiranje pre realizacije softvera)
Primjer: test za provjeru mogućeg broja korisnika
 Da li zahtjevi mogu da se prate? (označavanje u dokumentima)
 33

Validacija zahtjeva
je provera da li definicije zahtjeva tačno odražavaju zahtjeve naručioca.

Kriterijumi

 ispravnost zahtjeva (subjektivna procjena)

 dosljednost zahtjeva(automatska procjena)

 nedvosmislenost zahtjeva (subjektivna procjena)

 potpunost zahtjeva (subjektivna procjena)

 relevantnost zahtjeva (subjektivna procjena)

 mogućnost praćenja zahtjeva (automatska procjena)

 34

Tehnike validacije
 čitanje dokumenata
. formiranje izveštaja o uočenim greškama

 prolazak kroz dokumenta

. jedan od autora izlaže zahtjeve zainteresovanim subjektima
. zainteresovani subjekti daju mišljenja i komentare
. tehnika je pogodna kad ima mnogo zainteresovanih subjekata (da ne bi
svi čitali pojedinačno)

 formalna inspekcija
. revizori se stavljaju u konkretne uloge (računovođa,...) i prate
propisana pravila

 ocenjivanje zahtjeva
. po raznim aspektima
. ocenjuju svi učesnici na projektu (projektanti, naručioci, ...) razne
aspekte: ciljeve, namenu, funkcije, rizike,...
 35

Verifikacija specifikacije
je provjera da li specifikacija zahtjeva odgovara definiciji zahtjeva.

 daje sigurnost da će sistem realizovan po datoj specifikaciji zadovoljiti

zahtjeve korisnika

 složen proces u kome treba dokazati da specifikacija obuhvata sve

funkcije, događaje, aktivnosti i ograničenja iznete u zahtjevima

 često se, osim specifikacije, uključuju i pretpostavke o ponašanju

okruženja

 koriste se specijalizovani programi koji pretražuju prostor izvršavanja

specifikacije; ovi programi su složeni i troše značajne resurse
– 4. Kao dio konteksta problema, opisujemo okruženje u kojem će sistem da
radi. Navodimo sve poznate hardverske i softverske komponente sa kojima
predloženi sistem treba da bude u interakciji. Da bismo se uvjerili da je
korisnički interfejs odgovarajući, pravimo nacrt opšteg radnog iskustva i
sposobnosti korisnika sistema, kao što su obrazovanje, iskustvo i tehnička
stručnost. Na primjer, možemo da osmislimo različite korisničke interfejse za
iskusne korisnike i početnike. Pored toga, navodimo eventualna ograničenja
vezana za zahtjeve ili projektna rješenja, kao što su propisi koji se primjenjuju,
hardverska ograničenja i revizijske provjere.
– 5. Ako naručilac ima prijedlog rješenja problema, skiciramo opis prijedloga.
Međutim, treba se podsjetiti da je namjena dokumenta sa izloženim
zahtjevima da se razmotri problem, a ne rješenje. Potrebno je da pažljivo
ocijenimo predloženo rješenje, da bismo odredili da li se radi o projektnom
ograničenju koje treba da bude zadovoljeno ili o dodatnoj specifikaciji koja bi
mogla da isključi bolja rješenja. Na kraju, ako naručilac postavi ograničenja u
pogledu razvoja ili ako postoje neke posebne pretpostavke koje treba da se
učine, potrebno ih je uključiti u definiciju zahtjeva.
– 6. Konačno, navodimo eventualne pretpostavke vezane za ponašanje
okruženja. Posebno opisujemo eventualne uslove iz okruženja koji mogu da
prouzrokuju otkaz predloženog sistema, kao i eventualne promjene okruženja
koje mogu da prouzrokuju izmene zahtjeva. Pretpostavke treba da budu
dokumentovane odvojeno od zahtjeva tako da projektanti znaju za koje
ponašanje su odgovorni prilikom implementacije.

226
 SPECIFIKACIJA ZAHTJEVA
• Specifikacija zahtjeva pokriva identičnu oblast kao i definisanje
zahtjeva, ali iz perspektive učesnika u razvoju. Dok su definicije
zahtjeva pisane rječnikom naručioca, pozivajući se na objekte,
stanja, događaje i aktivnosti iz svijeta naručioca, specifikacija
zahtjeva se iskazuje u kategorijama interfejsa sistema. To
postižemo preformulisanjem zahtjeva tako da referenciraju jedino
one objekte iz realnog svijeta (stanja, događaje i akcije) na koje
predloženi sistem reaguje ili koje aktivira:
– 1. Prilikom dokumentovanja interfejsa sistema, detaljno opisujemo
sve ulaze i izlaze, uključujući i izvore ulaza, odredišta izlaza, opsege
vrijednosti i formate podataka ulaza i izlaza, protokole podataka koji
upravljaju redoslijedom u kojem određeni ulazi i izlazi moraju da se
razmjenjuju, formate i organizaciju prozora, kao i eventualna
vremenska ograničenja. Treba da napomenemo da je korisnički
interfejs rijetko i jedini interfejs sistema, budući da sistem može da vrši
interakciju sa drugim softverskim komponentama (na primjer, bazom
podataka) hardverom posebne namjene, internetom itd.

227
 – 2. Zatim, ponovo iskazujemo zahtjevanu funkcionalnost u kategorijama
ulaza i izlaza interfejsa. Pri tome možemo da koristimo funkcionalnu
notaciju ili dijagrame toka podataka za preslikavanje ulaza na izlaz, ili
logiku za dokumentovanje prethodnih uslova i naknadnih uslova
funkcija. Možemo da koristimo konačne automate ili tragove događaja
za ilustrovanje sekvenci operacija ili redoslijeda ulaza i izlaza. Možemo
da koristimo dijagram odnosa između entiteta u cilju okupljanja
povezanih aktivnosti i operacija u klase. Na kraju, specifikacija treba da
je potpuna, sto znači da treba da specifikuje izlaz za sve izvodljive
sekvence ulaza. Otuda uključujemo provjere ispravnosti ulaza i
odgovora sistema na izuzetne situacije, kao što je narušavanje
preduslova.
– 3. Konačno, treba da utvrdimo kriterijume usklađenosti svakog
zahtjeva u pogledu kvaliteta koje postavlja naručilac, tako da možemo
da ubjedljivo demonstriramo da li naš sistem zadovoljava te
kriterijume kvaliteta.
• Rezultat je dovoljno detaljan opis onoga šta razvojni tim treba da
proizvede, u kome se jasno razlikuju prihvatljiva i neprihvatljiva
rješenja, ali bez naznaka o načinu projektovanja i implementacije
predloženog sistema.

228
 UPRAVLJANJE PROCESOM I
MOGUĆNOST PRAĆENJA ZAHTJEVA
• Neophodno je da postoji direktna korespondencija
između zahtjeva u definicionom i zahtjeva u
specifikacionom dokumentu. Ovo je mjesto gdje
započinju metode upravljanja projektom koje će se
koristiti tokom životnog ciklusa. Upravljanje procesom
je skup procedure koje prate:
– zahtjeve koji definišu šta sistem treba da radi;
– projektne module koji se generišu na osnovu zahtjeva;
– programski kod koji implementira projektna rješenja;
– testove koji verifikuju funkcionalnost sistema;
– dokumente koji opisuju sistem.

229
 VALIDACIJA I VERIFIKACIJA
• Podsjetimo se da dokumenti o zahtjevima služe i kao ugovor između nas i
naručioca, jer detaljno opisuju šta treba da isporučimo, ali i kao smjernice za
projektante, jer detaljno opisuju šta treba da bude napravljeno. Prema tome, prije
proslijeđivanja zahtjeva projektantima, zajedno sa naručiocem moramo da
budemo apsolutno sigurni da svaka zainteresovana strana zna namjere one druge,
kao i da su naše namjere evidentirane u dokumentima o zahtjevima. Za
uspostavljanje te sigurnosti, moramo da izvršimo validaciju zahtjeva i verifikaciju
specifikacije.
• Tokom validacije zahtjeva, provjeravamo da li definicije zahtjeva tačno odražavaju
definicije zahtjeva naručioca, odnosno, sve što je potrebno zainteresovanim
subjektima. Validacija je prilično složena jer postoji samo nekoliko dokumenata
koje možemo da koristimo kao osnovu za argumentaciju da su definicije zahtjeva
ispravne. Kod verifikacije, provjeravamo da li je jedan dokument saglasan sa
drugim. Prema tome, verifikujemo da li je naš kod saglasan sa projektnim
rješenjem, kao i da li je projektno rješenje usaglašeno sa specifikacijom zahtjeva.
Na nivou zahtjeva, verifikujemo da li specifikacija zahtjeva zadovoljava definiciju
zahtjeva. Da rezimiramo, verifikacija osigurava da gradimo sistem na pravi način,
dok validacija osigurava da gradimo pravi sistem.

230
 Validacija zahtjeva
• Naš kriterijum za validaciju zahtjeva jesu karakteristike:
– ispravan;
– dosljedan;
– nedvosmislen;
– potpun;
– relevantan;
– može se testirati;
– može se pratiti.
• Zavisno od tehnika definisanja koje koristimo, neke od navedenih
provjera (na primjer, da li su zahtjevi dosljedni i da li se mogu
pratiti) mogu da se automatizuju. Takođe, moguće je evidentirati
uobičajene greške u listi za provjeru, koju revizori mogu da koriste
kao smjernice prilikom traženja grešaka.

231
U sledećoj tabeli navode se neke od tehnika koje mogu da se koriste za
validaciju zahtjeva. Validacija može u najjednostavnijem slučaju da se
svede na čitanje dokumenata i izvještavanje o greškama.

232
• Možemo od validacionog tima da tražimo da parafira
dokument, deklarišući time da je izvršio reviziju dokumenta
i da ga odobrava. Nakon parafiranja, zainteresovani subjekti
prihvataju djelimičnu odgovornost za greške koje se nakon
toga nađu u dokumentu. Alternativno, možemo da obavimo
prolazak kroz dokumente, gdje jedan od autora dokumenta
predstavlja zahtjeve ostalim zainteresovanim subjektima i
od njih traži komentare.
• Prolaženje kroz dokumente je najefikasnije ako postoji veliki
broj raznih zainteresovanih subjekata, a nije realno da od
njih zahtjevamo da detaljno analiziraju dokumente.
Suprotan ekstremni slučaj je validacija, koja može da bude
strukturisana kao formalna inspekcija, gdje revizori uzimaju
određene uloge (na primjer, izlagač, posrednik) i prate
propisana pravila (tj. pravila o tome kako da se ispituju
zahtjevi, kada se održavaju sastanci i prave pauze, kada da
se nastavi inspekcija).

233
• Mnogo češće se validacija zahtjeva vrši pomoću
ocjenjivanja zahtjeva. Prilikom ocjenjivanja,
predstavnici našeg osoblja i osoblja naručioca
pojedinačno ispituju dokumente o zahtjevima, a zatim
se sastaju da bi raspravljali o uočenim problemima.
• Predstavnici naručioca uključuju one koji će raditi na
sistemu, one koji će pripremati ulaz sistema, kao i one
koji će koristiti izlaze sistema, pri čemu učešće mogu da
uzmu i rukovodioci tih radnika. Mi obezbjeđujemo
članove razvojnog tima, tima za testiranje i
operativnog tima. Radom u grupi, možemo da uradimo
više od provjere da definicija softverskih zahtjeva
zadovoljava validacioni kriterijum:
– 1. Pregledamo navedene ciljeve i namjenu sistema.
– 2. Poredimo zahtjeve sa ciljevima i namjenom, da bismo se
uvjerili da su svi zahtjevi neophodni.

234
– 3. Ocjenjujemo okruženje u kojem sistem treba da radi,
ispitujući interfejse između predloženog sistema i svih drugih
sistema i provjeravamo da li su njihovi opisi kompletni i ispravni.
– 4. Predstavnici naručioca pregledaju tok informacija i predložene
funkcije, da bi potvrdili da one tačno odražavaju potrebe i
namjere naručioca. Naši predstavnici ocjenjuju predložene
funkcije i ograničenja, da bi potvrdili da su oni realistični i u
okviru naših razvojnih mogućnosti. Svi zahtjevi se ponovo
provjeravaju na eventualne propuste, nepotpunost ili
nedoslednosti.
– 5. Ako postoji rizik uključen u razvoj ili stvarno funkcionisanje
sistema, možemo da procijenimo i dokumentujemo rizike,
diskutujemo i poredimo alternative, kao i da postignemo
saglasnost o pristupima koji treba da se koriste.
– 6. Ako sistem treba da se isporuči u fazama, možemo da
razgovaramo o testiranju sistema: kako će se vršiti ponovna
validacija zahtjeva sa njihovom evolucijom i promjenama; ko
treba da obezbjedi podatke za testiranje timu testira; koji
zahtjevi će biti testirani u kojim fazama.

235
• Uvijek kada se uoči problem, on se dokumentuje, određuje se uzrok
problema, a analitičari zahtjeva dobijaju zadatak da riješe problem.
Na primjer, validacija može da otkrije da postoji veliko
nerazumijevanje vezano za način na koji određena funkcija generiše
rezultat. Naručioci mogu da zahtijevaju da se podaci izražavaju u
miljama, dok korisnici žele podatke u kilometrima. Naručilac može
da kao cilj postavi pouzdanost ili raspoloživost, za koje projektni tim
smatra da ih je nemoguće postići. Ti konflikti treba da budu
razriješeni prije nego što počne projektovanje. Da bismo razriješili
konflikt, razvojni tim možda ima potrebu da napravi simulaciju ili
prototip, u cilju istraživanja ograničenja izvodljivosti, a nakon toga
da radi sa naručiocem na postizanju dogovora o prihvatljivim
zahtjevima.
• Izbor validacione tehnike zavisi od iskustva i želja zainteresovanih
subjekata, kao i od usklađenosti tehnika sa notacijama korišćenim u
sklopu definicija zahtjeva. Neke notacije imaju pomoćne alate za
provjeravanje dosljednosti i potpunosti. Takođe postoje alati koji
potpomažu proces pregleda, praćenje problema i nalaženje
rješenja. Na primjer, neke alate koristimo zajedno sa naručiocem da
bismo smanjili stepen neizvijesnosti u zahtjevima.

236
• Validacija zahtjeva je proces provjere da li zahtjevi
koje su dobiveni od klijenta zaista definiraju
sistem koji korisnik želi. Validacija se isprepliće s
analizom zahtjeva budući da se bavi pronalaskom
pogrešaka u zahtjevima. Naknadno ispravljanje
pogreške u zahtjevima može biti mnogo puta
skuplje od jednostavnog ispravljanja pogreške u
implementaciji.
• Tehnike validacije uključuju:
– Recenziju zahtjeva - detaljna, ručna analiza zahtjeva od strane
zajedničkog tima.
– Izradu prototipa - provjera zahtjeva na izvedenom sistemu.
– Generiranje ispitnih slučaja - razvoj ispitnih sekvenci za provjeru
zahtjeva.

237
238
• U zahtjevima se provjerava više svojstava. To uključuje:
• Valjanost - ostvaruje li sistem funkcionalnost koja podupire
potrebe većine stakeholdera?
• Konzistentnost - postoji li konflikt u zahtjevima?
• Kompletnost - uključuje li sistem sve funkcije koje je korisnik
tražio?
• Realnost -mogu li se sve funkcije implementirati uz danu
tehnologiju i proračun?
• Provjerljivost - mogu li se svi zahtjevi provjeriti?
• Razumljivost - je li dokument zahtjeva jasno napisan?
• Slijedivost - je li naveden izvor dokumenta u slučaju više povezanih
dokumenata?
• Prilagodljivost - mogu li se zahtjevi mijenjati bez utjecaja na druge
zahtjeve?
• Nije dobro potcijeniti probleme koji se tiču validacije
zahtjeva. U konačnici, teško je pokazati da je neki skup
zahtjeva točno onaj koji odgovara klijentskim
potrebama. Potrebno je imati dobro razvijenu
sposobnost zamišljanja programskog sistema u
izvođenju, za što treba imati iskustva.
239
 Verifikacija
• Kod verifikacije, želimo da provjerimo da li nas dokument sa
specifikacijom zahtjeva odgovara dokumentu definicije zahtjeva. Ta
verifikacija treba da nas uvjeri da će, ako implementiramo sistem
koji zadovoljava specifikaciju, on da zadovoljava i zahtjeve
naručioca. Još češće, to je jednostavno provjera mogućnosti
praćenja, gdje obezbjeđujemo da svaki zahtjev u dokumentu sa
definicijama može biti praćen sve do specifikacije.
• Međutim, kod kritičnih sistema želimo da uradimo i više, i da zaista
demonstriramo da specifikacija ispunjava zahtjeve. Tada
dokazujemo da specifikacija realizuje sve funkcije, događaje,
aktivnosti i ograničenja data u zahtjevima. Sama specifikacija je
rijetko dovoljna da pruži tu vrstu argumentacije, jer se ona piše u
smislu akcija koje će se izvesti u sistemskom interfejsu.

240
• Na primjer, da bismo prikazali da termostat i peć kontrolišu temperaturu
vazduha, potrebno je da pretpostavimo da se temperatura vazduha
mijenja kontinualno a ne skokovito, mada senzori mogu da detektuju
diskretne promjene vrijednosti, a peć koja je u radu podiže temperaturu
vazduha. Te pretpostavke mogu da budu očigledne, ali ako je zgrada
dovoljno porozna a spoljna temperatura dovoljno niska, onda naša druga
pretpostavka neće važiti. U takvom slučaju, radi opreza bi trebalo da
postavimo neke granice zahtjeva: sve dok je spoljna temperatura iznad -
100°C, termostat i peć održavaće temperaturu vazduha.
• Ovakva upotreba pretpostavki o okruženju u suštini pokazuje zašto je
dokumentacija tako važna. Oslanjamo se na okruženje da nam ono
pomogne da zadovoljimo zahtjeve naručioca, pri čemu ako su naše
pretpostavke o tome kako se okruženje ponaša pogrešne, onda sistem
možda neće raditi prema očekivanju naručioca. Ako ne možemo da
dokažemo da specifikacija i naše pretpostavke ispunjavaju zahtjeve
naručioca, onda je potrebno ili da izmijenimo specifikaciju, provjerimo i
dopunimo naše pretpostavke o okruženju ili da smanjimo zahtjeve koje
pokušavamo da zadovoljimo.
• Kada su završeni validacija i verifikacija zahtjeva, softverski inžinjer i
naručilac bi trebalo da budu prilično zadovoljni specifikacijom zahtjeva.
Uz razumijevanje šta naručilac želi, softverski inžinjer može da nastavi sa
projektovanjem sistema. U međuvremenu, naručilac ima u rukama
dokument koji tačno opisuje šta isporučeni sistem treba da radi.
241
 MJERENJE ZAHTJEVA
• Postoje mnogi načini za mjerenje karakteristika
zahtjeva, tako da prikupljene informacije dosta govore
o procesu definisanja zahtjeva i kvalitetu samih
zahtjeva.
• Mjerenja se obično fokusira na tri oblasti: proizvod,
proces i resurse. Broj zahtjeva u specifikaciji i definiciji
zahtjeva može da nam pruži osjećaj vjerovatne veličine
sistema koji se razvija.
• Kako projektovanje i razvoj vode do dubljeg
razumijevanja problema i rješenja, lako mogu iskrsavati
novi zahtjevi koji nisu bili očigledni u samom početku,
kada je pravljena specifikacija zahtjeva.
242
• Slično tome, možemo da mjerimo broj izmjena zahtjeva.
Veliki broj izmjena ukazuje na neku nestabilnost, ili na naše
nedovoljno razumijevanje šta bi sistem trebalo da radi ili
kako bi sistem trebalo da se ponaša, a takođe i sugeriše da
treba da preduzmemo radnje u cilju smanjenja stope
izmjena. Praćenje izmjena nastavlja se i tokom razvoja, a sa
promjenom sistemskih zahtjeva, može se ocjenjivati uticaj
izmjena.
• Gdje je to moguće, veličina zahtjeva i mjerenje izmjena
mogu da se evidentiraju prema tipu zahtjeva. Takva metrika
je zasnovana na kategoriji i kazuje nam da li se izmjena ili
neizvjesnost u zahtjevima događa na nivou cijelog sistema,
ili se zadržava samo na određenim vrstama zahtjeva, kao
što su, na primjer, korisnički interfejs ili zahtjevi u pogledu
baze podataka. Ta informacija nam pomaže da odredimo da
li je potrebno da usredsredimo našu pažnju na određene
tipove zahtjeva.Zahtjevi služe projektantima i testerima, pa
mjerenja treba da odraze njihovu ocjenu zahtjeva.
243
 IZBOR TEHNIKE ZA SPECIFIKACIJU
• Predstavljeni su primjeri nekoliko tehnika za
specifikovanje zahtjeva, mada pored njih
postoji još mnogo tehnika koje se mogu
koristiti prilikom projektovanja. Svaka tehnika
ima svoje dobre osobine, od kojih neke više a
neke manje odgovaraju određenom projektu.
Prema tome, važno je da za svaki projekat
imamo skup kriterijuma na osnovu kojih
odlučujemo koja tehnika najbolje odgovara.
244
• Navesti ćemo neke kriterijume namenjene tehnikama
ocjenjivanja određenih reaktivnih sistema, mada su kao
što ćemo vidjeti, mnogi od njih prilično opšti:
– Primjenljivost: Može li tehnika da opiše probleme i
rješenja iz realnog svijeta na prirodan i realističan način?
Ako tehnika pravi pretpostavke o okruženju, da li su te
pretpostavke razumne? Da li je tehnika kompatibilna sa
drugim tehnikama koje će se koristiti u okviru projekta?
– Mogućnost implementacije: Može li specifikacija da se
lako pročisti ili prevede u implementaciju? Koliko je teško
to prevođenje? Da li je ono automatizovano? Ako je tako,
da li je generisani kod efikasan? Da li je generisani kod na
istom jeziku kao onaj koji se koristi u ručno proizvedenim
dijelovima implementacije? Da li postoji čist, dobro
definisan interfejs između koda koga je generisala mašina i
ostatka koda?

245
– Mogućnost testiranja/simulacije: Može li specifikacija da se koristi za
testiranje implementacije? Da li se svaka stavka u specifikaciji može testirati
kroz implementaciju? Da li je moguće izvršiti specifikaciju?
– Mogućnost provjere: Da li je specifikacija čitljiva za one koji nisu projektanti,
kao što je recimo naručilac? Mogu li stručnjaci iz date oblasti (tj. stručnjaci za
problem za koji se pravi specifikacija) da provjere tačnost specifikacije? Da li
postoje programi za automatsku provjeru specifikacije?
– Mogućnost održavanja: Da li specifikacija može da bude korisna prilikom
pravljenja izmjena sistema? Da li se specifikacija lako mijenja tokom evolucije
sistema?
– Modularnost: Da li metod dozvoljava dekompoziciju velike specifikacije na
manje dijelove koje je lakše napisati i razumjeti? Mogu li izmjene da se načine
na manjim dijelovima bez ponovnog pisanja cjelokupne specifikacije?
– Nivo apstrakcije/izražajnosti: Koliko blisko i izražajno objekti, stanja i događaji
u jeziku odgovaraju stvarnim objektima, akcijama i uslovima u domenu
problema?
– Koliko je koncizna i elegantna rezultujuća specifikacija?
– Ispravnost: Da li jezici ili drugi alati olakšavaju proveravanje nedoslednosti ili
višeznačnosti u specifikaciji? Da li je semantika specifikacionog jezika precizno
definisana?

246
– Mogućnost verifikacije: Možemo li formalno da demonstriramo da
specifikacija zadovoljava zahtjeve? Može li verifikacioni proces da bude
automatizovan, i ako je tako, da li je ta automatizacija jednostavna?
– Bezbjednost izvršavanja: Ako kod može da se automatski generiše iz
specifikacije, da li se kod bez posljedica degradira pod neočekivanim uslovima
izvršavanja, kao što je prekoračenje opsega?
– Zrelost alata: Ako tehnika specifikovanja ima pomoćne alate, da li su ti alati
visokog kvaliteta? Da li je na raspolaganju i obuka za upotrebu tih alata? Koliko
je veliko predznanje korisnika za upotrebu tih alata?
– Proizvoljnost: Da li specifikacija može da bude nekompletna ili da dopušta
neodređenost?
– Krivulja učenja: Može li novi korisnik da nauči koncepte, sintaksu, semantiku i
heuristike date tehnike?
– Zrelost tehnike: Da li je tehnika sertifikovana ili standardizovana? Da li postoji
korisnička grupa ili velika baza korisnika?
– Modelovanje podataka: Da li tehnika uključuje predstavljanje podataka,
odnosa ili apstrakcija? Da li su mehanizmi modelovanja podataka sastavni dio
tehnike?
– Disciplina: Da li tehnika primorava one koji je koriste da pišu dobro
strukturisane i razumljive specifikacije, koje se dobro ponašaju?

247
• Prvi korak pri izboru specifikacione tehnike
jeste odrediti koji je od navedenih kriterijuma
posebno važan. Prioriteti kriterijuma su
različiti za različite probleme.
• Drugi korak za izbor specifikacione tehnike
jeste ocjenjivanje svake od potencijalnih
tehnika u smislu datog kriterijuma.
• Na kraju, biramo specifikacionu tehniku koja
najbolje podržava kriterijum koji je najvažniji
za dati problem.

248
 UPRAVLJANJE ZAHTJEVIMA ILI
UPRAVLJANJE PROMJENAMA
• Zahtjevi se, naročito u velikim softverskim sistemima, stalno
mijenjaju. Te promjene nastaju iz različitih razloga:
– zbog promijenjenog modela poslovanja,
– radi boljeg razumijevanja procesa, do čega se došlo tokom
samog razvoja sistema,
– radi otkrivanja konfliktnih zahtjeva tokom rada sistema,
– radi otkrivanja novih potreba i prioriteta krajnjih korisnika do
kojih se dolazi primjenom sistema,
– zbog promjena zakona i propisa,
– zbog tehnoloških promjena i inovacija javljaju se novi zahtjevi i
potrebe,
– zbog promjena drugih podsistema s kojima postoji interakcija,
– zbog promjena koje su nastale samim uvođenjem sistema u
organizaciju i prelaska na novi način rada …

249
• Jednom kad je sistem instaliran i u
svakodnevnoj uporabi, često se pojavljuju novi
zahtjevi. Razlog tome je taj što je korisnicima i
klijentima teško unaprijed predvidjeti sve
učinke koje će imati novorazvijeni sistem na
poslovne ili proizvodne procese. S vremenom
bit će uočene nove potrebe i prioriteti.

250
• Moguće je klasificirati vrste promjena zahtjeva u
sljedeće četiri kategorije:
• Okolinom promijenjeni zahtjevi - promjena zahtjeva zbog
promjene okoline u kojoj organizacija posluje (npr. bolnica
mijenja financijski model pokrivanja usluga).
• Novonastali zahtjevi - zahtjevi koji se pojavljuju kako kupac
sve bolje razumije sistem koji se oblikuje.
• Posljedični zahtjevi - zahtjevi koji nastaju nakon
uvođenja sistema u eksploataciju, a rezultat su
promjena procesa rada u organizaciji nastalih upravo
uvođenjem novoga sistema.
• Zahtjevi kompatibilnosti - zahtjevi koji ovise o procesima
drugih sistema u organizaciji; ako se ti sistemi mijenjaju to
traži promjenu zahtjeva i na novo uvedenom sistemu.

251
• Zahtjeve, obzirom na njihovu evoluciju tokom vremena, možemo
svrstati u dvije kategorije:

• trajni zahtjevi – relativno su stabilni jer proističu iz potreba poslovne aktivnosti

organizacije, npr. u knjižnici će uvijek postojati zahtjevi za evidentiranjem
knjiga, članova i izdavanja;
• nestalni („hlapivi“) zahtjevi – postoji velika mogućnost da će se takvi zahtjevi
mijenjati već u fazi razvoja ili nakon što se sistem implementira u korisničko
okruženje, npr. zahtjevi vezani za obračun kamata.

• Upravljanje zahtjevima je, u stvari, proces razumijevanja i

kontroliranja promjena koje se odnose na zahtjeve prema sistemu,
a prisutne su konstantno. Promjene se ne mogu zaustaviti, ali se
može pripremiti za njih na način da se njima može što efikasnije
upravljati kada se one pojave. Promjena je prirodni faktor svakog
procesa i ona će zasigurno nastati, stoga je neophodno osigurati
određeni plan, odnosno proces upravljanja promjenama.

252
 Proces promjene zahtjeva
• Promjene na postavljenim zahtjevima. Sa
saznanjem karakteristika pronađenih
komponenti (koje ne moraju nužno ispunjavati
sve zahtjeve potrage) ponovno se analiziraju
zahtjevi primjene te, ako je to moguće, mijenjaju
ne bi li bilo moguće koristiti nađene
komponente.

253
254
 Planiranje upravljanja zahtjevima
• Planiranje je bitan, prvi korak, procesa upravljanja zahtjevima. Sam proces
upravljanja zahtjevima je vrlo skup. Za svaki projekt u fazi planiranja se
utvrđuje odgovarajuća razina upravljanja promjenama. U procesu
upravljanja zahtjevima treba uočiti sljedeće aktivnosti:
– Identifikacija zahtjeva – svaki zahtjev mora biti na jedinstven način određen
(identificiran);
– Proces upravljanja promjenama (u užem smislu) – skup aktivnosti kojima se
procjenjuje utjecaj, značaj i trošak promjene;
– Izbor odgovarajućeg CASE alata za potporu aktivnostima upravljanja
zahtjevima. S obzirom na količinu podataka, brojnost veza i njihovu
kompleksnost neophodno je koristiti neki od alata koji će taj posao učiniti
efikasnijim;
– Slijednost (engl. traceability, praćenje traga) - definiraju se veze između
zahtjeva, veze između zahtjeva i stejkholdera i veze između zahtjeva i
pojedinih modula. Ove veze se moraju sistemno zapisivati i održavati.
Najčešće se za to koriste odgovarajuće matrice, poput one na narednoj
stranici:

255
256
 Upravljanje promjenama zahtjeva
• Ovu aktivnost čine sljedeće tri faze:
– Analiza problema i specifikacija promjena – započinje
identificiranjem problema i, ponekad, uz prijedlog
promjene zahtjeva. Problem i/ili prijedlog promjene
zahtjeva se potom analiziraju kako bi se utvrdila njihova
validnost. Rezultat ove analize se prosljeđuje predlagatelju
promjena, odnosno onome tko je uočio problem, što ne
rijetko rezultira konkretnijim, specifičnijim i detaljnijim
prijedlogom promjene zahtjeva;
– Analiza promjene i troškova – procjenjuje se učinak
predložene promjene na ostale zahtjeve i generalno
funkcioniranje sistema, te se utvrđuje trošak koji bi
promjena prouzročila. Rezultati ove analize su podloga za
donošenje odluke o nastavku procesa promjene zahtjeva;

257
 – Implementiranje promjene – dokumentacija zahtjeva
se treba modificirati, kao i dizajn sistema, ukoliko je to
potrebno. Često se događa da se neka, hitna
promjena zahtjeva prvo implementira, a tek
naknadno se modificira i dokumentacija zahtjeva. To
se nikako ne preporučuje jer to dovodi do
nekonzistentnosti i nepreciznosti u vođenju
dokumentacije zahtjeva, koja mora uvijek biti
usuglašena sa promjenama sistema.
• Faktori promjene, kako vanjski, tako i unutarnji,
se dobro pripremljenim pristupom problemu i
upravljanju zahtjevima i njihovim promjenama,
mogu minimizirati, ali ne i potpuno ukloniti, jer
promjene su, kao i (male) pogreške u
kompleksnim sistemima neizbježne.

258
 DOKUMENTIRANJE ZAHTJEVA
• Konačni proizvod ili rezultat faze inženjerstva
zahtjeva je dokument softverskog zahtjeva, koji
se još naziva i specifikacija softverskog zahtjeva
(SRS). SRS je zvanični dokument koji opisuje što
razvijači sistema ili developeri ( od engl.
developers) trebaju implementirati. Svrha ovog
dokumenta je komunikacija rezultata faze
inžernjerstva zahtjeva svim zainteresiranim
stranama (stejkholderima). U pravilu uključuje:
• opise korisničkih zahtjeva na sistem i
• detaljne specifikacije zahtjeva.

259
260
• Mnogi veliki organizacijski sistemi, poput
američkog Ministarstva obrane ili IEEE, imaju
definirane vlastite standarde za izradu
dokumenta softverskog zahtjeva. Najšire je
rasprostranjen upravo standard IEEE/ANSI 830
– 1998., koji propisuje okvirnu, generalnu,
strukturu specifikacije softverskog zahtjeva.
Osnovna poglavlja Specifikacije prema
navedenom standardu su:

261
 Detaljne specifikacije svih zahtjeva (funkcionalnih i nefunkcionalnih).
DODATCI
INDEKS
Ovaj predloženi okvir (engl. framework) je i suviše općenit i može se „prekrajati“
tako da odgovara potrebama konkretne organizacije.
262
 RIZICI LOŠEG PLANIRANJA I IZVOĐENJA PROCESA
INŽENJERSTVA ZAHTJEVA
• Gotovo je nemoguće kreirati softverski proizvod koji udovoljava
svim zahtjevima svih zainteresiranih strana, i to „iz prve“. To je vrlo
teško postići i nakon pete ili šeste revizije programskog proizvoda.
Razloga za to je mnogo, a jedan od najznačajnijih je taj što se
okruženje u kojem živimo i radimo stalno mijenja, tako da je
nemoguće sagledati sve aspekte (zahtjeve) nekog problemskog
područja. Novi zahtjevi se pojavljuju tokom samog razvoja
softvera, mijenjaju se kako interni tako i eksterni faktori koji
utječu na definiranje zahtjeva na sistem. Mijenjaju se propisi,
mijenja se tržište, organizacijska politika, stejkholderi u procesu
definiranja zahtjeva otkrivaju nove (dodatne) zahtjeve, novi zahtjevi
se pojavljuju i kao rezultat boljeg upoznavanja sa problemskim
područjem, primjenom programa se također otkrivaju novi zahtjevi
ili definiraju prijedlozi za promjenama zahtjeva

263
• Dakle, nužno je biti svjestan činjenice da proizvod koji
se izrađuje nije idealno rješenje, da će se sigurno
mijenjati, unaprjeđivati, prilagođavati i poboljšavati
kako bi zadovoljio (nove i narasle) zahtjeve. Zašto je to
nužno? Nužno je iz nekoliko razloga. Svijest o potrebi
prilagođavanja i mijenjanja zahtjeva nameće
projektantima zadaću da razvijaju softver čija će
arhitektura omogućiti provođenje promjena i
definiranje novih zahtjeva bez potrebe za suštinskim
redizajnom softverskog proizvoda.
• Dobro je biti svjestan promjenljivosti (nekih) zahtjeva
jer to vodi ozbiljnijem pristupu samom procesu
izlučivanja i analize zahtjeva, definiranju čvrstih
zahtjeva i onih manje čvrstih za koje se očekuje da će se
mijenjati (koje treba posebno evidentirati).

264
• Samo upoznavanje mogućih rizika vodi do
smanjivanja njihovih efekata. Spoznaje o rizicima
omogućavaju da ih se svede na minimum, ako ih
već nije moguće u potpunosti izbjeći. To znači da
je potrebno tako planirati i voditi aktivnosti
inženjerstva zahtjeva kako bi se u početku što
bolje definirali zahtjevi na sistem (kako
funkcionalni tako i nefunkcionalni) i da se
uspostavi takav sistem upravljanja zahtjevima,
koji će osigurati efikasnu kontrolu i provođenje
promjena, koje su, kako je već ranije istaknuto,
neizbježne. Koji su to, onda, najčešći rizici koje
treba poznavati (i pokušati izbjeći ili minimizirati
njihove učinke)?

265
• Jedan od najčešćih je nedovoljna i neadekvatna
uključenost zainteresiranih strana. Bez adekvatnog
identificiranja i uključivanja stejkholdera nije moguće
uspješno definirati zahtjeve. Nedovoljna uključenost,
naročito ključnih, stejkholdera u konačnici vodi razvoju
neprihvatljivog proizvoda, probijanju utvrđenih rokova,
čestim promjenama, višestrukom povećanju troškova.
i, najčešće, odustajanju od daljnjeg razvoja, što
predstavlja najgori scenarij i za naručitelja i za izvođača.
• Drugi čest rizik je neprecizno i nejasno definiranje
vizije projekta, odnosno onoga što sistem treba i mora
pružati, a što ne treba. Greške u definiranju granica
sistema vode lutanju, gubljenju fokusa, bavljenju
marginalnim aspektima problema i sl.

266
• Nejasni, dvosmisleni i, ne rijetko, čudni zahtjevi su također, na
žalost, česti. Korisnici nisu (uvijek) sposobni na pravi način
artikulirati i prezentirati ono što žele i što očekuju od sistema. U
procesu otkrivanja i definiranja zahtjeva treba „pomoći“ korisnicima
da se dođe do jasno i precizno definiranih zahtjeva.
• (Ne)definiranje ključnih, prioritetnih zahtjeva neminovno vodi
neuspjehu projekta, produženju rokova i, u konačnici, frustraciji i
nezadovoljstvu korisnika.
• Zanemarivanje potreba (zahtjeva) određenih, naročito ključnih,
korisnika (stejkholdera) je nešto što može stvoriti „opoziciju
projektu“, a to može imati samo negativne posljedice.
• (Ne)provjeravanje zahtjeva je također jedan od češćih rizičnih
faktora. Sistemno provjeravanje (inspekcija) zahtjeva, i to u što je
moguće ranijoj fazi, je najefikasniji način identificiranja nejasnoća,
nedovoljno utvrđenih pretpostavki, konfliktnih zahtjeva i drugih
nedostataka. Otkrivanje i otklanjanje (ako je to uopće više moguće)
nedostataka kada je softver već instaliran u korisničko okruženje
uzrokuje višestruko veće troškove.

267
• Nedovoljno precizno i nepotpuno definiranje veza između
zahtjeva vodi neminovno problemima u održavanju
softvera. Promjene pojedinih zahtjeva se vrlo često
reflektiraju na druge zahtjeve programskog proizvoda .
• (Ne)definiranje vitalnih nefunkcionalnih zahtjeva također
ima bitnu ulogu u realizaciji i samom prihvaćanju
softverskog proizvoda .
• (Ne)realno postavljeni rokovi također mogu biti veliki
problem. Nerijetko se događa da je naručitelj, obzirom na
hitnost nekog posla, postavio uvjet da se projekt realizira za
svega par nedjelja. Naravno, prihvaćanje takvih uvjeta, bez
upoznavanja sa zadatkom i raspoloživim resursima, vodi u
probijanje nerealno postavljenog roka i/ili u realizaciju
projekta, čijom kvalitetom i mogućnostima nije zadovoljan
niti naručilac, niti sam izvođač.

268
• Komunikacijski problemi se javljaju kada se ne uspostavi
„zajednički jezik“ između naručioca i izvođača. Inženjeri
često ne razumiju u potpunosti stručnu terminologiju
problemskog područja, a korisnici, s druge strane, nemaju
dostatno tehničko znanje da bi razumjeli jezik sistemskih
dizajnera i inženjera. Vrlo je bitno, dakle, da se uspostavi
„zajednički jezik“ koji će pomoći da se izbjegne
komunikacijski jaz i mogući nesporazumi, a sve s ciljem što
jasnijeg i preciznijeg definiranja zahtjeva na sistem.
• Ovdje su navedeni samo neki od rizika ili problema koji se
mogu javiti u procesu inženjerstva zahtjeva, a kojih trebaju
biti svjesne, ili barem trebaju biti upoznate s njima, sve
zainteresirane strane od kojih ovisi (ne)uspjeh projekta
razvoja softverskog proizvoda. Otklanjanje ili minimiziranje
ovih i mnogih drugih rizika koji se mogu javiti tokom ove
početne faze procesa izgradnje softverskog sistema
direktno utječe na uspjeh cjelokupnog projekta, jer se u fazi
inženjerstva zahtjeva postavljaju temelji razvoja softvera.
269
 ZAKLJUČAK
• Rane faze razvoja informacijskog sistema, bez obzira na njihovu
važnost u isporuci kvalitetnog proizvoda, oduvijek su podložne
tendenciji skraćivanja jer ne daju opipljive rezultate. Što prije
započeti izradu sistema želja je svih sustakeholdera. 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
štedjeti vrijeme ni novac.
• Sve brži razvoj informacijskih tehnologija i sve šira primjena IT
rješenja nije, na žalost, utjecao u pozitivnom smislu na statistiku
kojom se prikazuje uspješnost projekata razvoja softverskih
rješenja.
• Među najslabijim, najkritičnijim točkama razvojnog ciklusa i dalje
„vodeće mjesto“ zauzimaju propusti i greške koje se naprave u
ranim fazama razvoja softverskog proizvoda. Propusti u definiranju
zahtjeva, koji su najčešće nepotpuni, kontradiktorni i dvosmisleni,
uzrok su problema u razvoju koji se očituju kroz „probijanje“
planiranih rokova, višestruko povećanje troškova i, ne rijetko,
odustajanje (prekid) razvoja. 270
• U tom smislu, inženjerstvo zahtjeva (RE), kao početna
faza softverskog inženjerstva, ima poseban značaj. RE
aktivnosti imaju ključnu ulogu za rezultat cjelokupnog
procesa razvoja, jer je bez jasno definiranih zahtjeva
nemoguće razviti programski proizvod koji će
zadovoljiti svojim mogućnostima i performansama sve
zainteresirane strane. Ma kako dobro planirali i vodili
preostale aktivnosti programskog inženjerstva, ukoliko
zahtjevi nisu dobro prikupljeni, projekat se može
smatrati promašenim.
• Krajnji cilj RE procesa je da usmjeri razvoj u smjeru koji
će rezultirati dobrim, kvalitetnim i prihvatljivim
softverskim rješenjem. Nemoguće je dobiti dobar
konačan proizvod bez kvalitetno provedenih aktivnosti
procesa inženjerstva zahtjeva, odnosno bez dobro
definiranih zahtjeva na sistem.

271
• Što znači dobro definiran zahtjev? Dobro definiran zahtjev je, u
prvom redu, cjelovit, u potpunosti definiran i bez nedostataka,
konzistentan je i korektan, što znači da nije „u konfliktu“ ni sa
jednim drugim zahtjevom i u potpunosti udovoljava zahtjevima
korisnika. Dobro definiran zahtjev je nedvosmislen, jasno iskazan i
provjerljiv.
• Ostvariti takve zahtjeve nije uvijek lako, naprotiv. Tokom svih
aktivnosti RE procesa javljaju se mnogi problemi, odnosno rizici,
koje je potrebno, sistemnim i cjelovitim pristupom, minimizirati,
ukoliko ih već nije moguće u potpunosti izbjeći (a nije!). Da bi se to
ostvarilo i da bi se stvorila osnova za kvalitetno oblikovanje budućeg
sistema, potrebno se pridržavati smjernica inženjerstva zahtjeva te
primjenjivati najadekvatnije metode i tehnike koje će polučiti
najbolje rezultate u konkretnom projektu.
• Krajnji rezultat RE procesa, Specifikacija softverskog zahtjeva (SRS),
mora pružiti dovoljno kvalitetnih informacija za naredne faze
razvoja softverskog proizvoda, jer bez dobro definiranih i opisanih
zahtjeva nije moguće uspješno privesti kraju tako kompleksan
projekt kao što je, u pravilu, projekt razvoja softverskog proizvoda.

272
• Ovdje smo vidjeli najbolji način rada za razvoj
kvalitetnih softverskih zahtjeva. Vidjeli smo da učesnici
u razvoju softvera ne treba izolovano da sprovode
aktivnosti vezane za zahtjeve. Napori prilikom
definisanja i specifikacije zahtjevaju tijesnu saradnju sa
korisnicima, naručiocem, timom za testiranje,
projektantima i drugim članovima tima. Međutim, tu
su i znanja koja su važna i kojima treba samostalno
ovladati:
• Bitno je da dokumenti sa definicijom i specifikacijom zahtjeva
opisuju problem, ostavljajući izbor rješenja projektantima. Najbolji
način da se spriječi da zalutate u prostor rješenja problema jeste
opisivanje zahtjeva i specifikacija u funkciji pojava iz okruženja.
• Postoji više izvora i sredstava za izvođenje zahtjeva. Treba imati u
vidu da postoje funkcionalni i kvalitativni zahtjevi. Funkcionalni
zahtjevi objašnjavaju šta sistem treba da radi, dok kvalitativni
zahtjevi ograničavaju rješenja zavisno od bezbjednosti, pouz-
danosti, budžeta, rokova itd.

273
• Postoji više različitih tehnika za izradu definicija i specifikacija. Neke su
opisne, kao što su dijagrami odnosa između entiteta i logika, dok ostali
opisuju ponašanje, kao što su tragovi događaja, dijagrami toka
podataka i funkcije. Za neke tehnike se koristi grafička notacija, dok su
druge tehnike zasnovane na matematici. Kod svake tehnike je naglasak
na sagledavanju problema s drugog aspekta i svaka sugeriše različite
kriterijume za razlaganje problema na potprobleme. Često je poželjno
da se koriste kombinacije tehnika za određivanje različitih aspekata
sistema.
• Specifikacione tehnike takođe se razlikuju zavisno od njihovih
pomoćnih alata, zrelosti, razumljivosti, lakoće korišćenja i formalnog
matematičkog pristupa. Svaka tehnika treba da se procjenjuje za
konkretan projekat, jer ne postoji najbolja univerzalna tehnika.
• Odgovori na pitanja o zahtjevima mogu da se dobiju pomoću modela
ili prototipa. U oba slučaja, cilj je usredsređivanje na potproblem koji
predstavlja srž pitanja, umjesto da obavezno modelujemo ili pravimo
prototip cjelokupnog problema. Ako pravimo prototip, potrebno je da
unaprijed odlučimo da li će rezultujući softver biti zadržan ili odbačen.
• Potrebno je da se izvrši validacija zahtjeva da bi se osiguralo da oni
tačno odražavaju očekivanja naručioca. Potrebno je takođe provjeriti
da li su zahtjevi potpuni, ispravni, dosledni, izvodljivi itd., i to
oslanjajući se ponekad na tehnike ili alate koji su pridruženi odabranim
specifikacionim metodima. Na kraju, potrebno je da verifikujemo da li
specifikacija ispunjava zahtjeve.

274
• Postoje mnoge oblasti istraživanja u vezi sa zahtjevima.
Istraživači mogu:
• da istražuju načine za smanjivanje stepena neizvjesnosti i rizika u
zahtjevima;
• da razvijaju specifikacione tehnike i alate koji omogućavaju lakše
dokazivanje pretpostavki i tvrdnji, kao i da demonstriraju
doslednost, potpunost i determinizam;
• da razvijaju alate za omogućavanje praćenja kroz različite
međuproizvode i finalne proizvode softverskog razvoja. Alati
posebno mogu da ocijene uticaj predložene izmjene na proizvode,
procese i resurse;
• da ocjenjuju različite načine za pregledanje zahtjeva: alate,
kontrolne spiskove, inspekcije, prolaženje kroz dokumente itd.
Važno je da znamo koje tehnike su najbolje za koju situaciju;
• da stvaraju nove tehnike za simulaciju ponašanja zahtjeva;
• da nam pomažu da razumijemo koji tipovi zahtjeva su najbolji za
višekratno korišćenje u projektima koji slijede, kao i kako da
napišemo zahtjeve na način koji poboljšava njihovo kasnije
višekratno korišćenje.

275
• Razvojni tim mora da zajednički radi na saznavanju,
razumijevanju i dokumentovanju zahtjeva. Često se
različiti članovi tima usredsređuju na različita gledišta
zahtjeva. Na primjer, stručnjak za mreže može da radi
na mrežnim zahtjevima, stručnjak za korisnički interfejs
na prikazima i izvještajima, stručnjak za bazu podataka
na prihvatu podataka i skladištenju itd. Raznorodni
zahtjevi će biti integrisani u sveobuhvatnu cjelinu, pa
stoga zahtjevi moraju da se napišu na način koji
omogućava njihovo povezivanje i kontrolisanje. Na
primjer, izmjena jednog zahtjeva može da utiče na
druge zahtjeve koji su s njim u vezi, a metodi i alati
moraju da podrže izmjene koje osiguravaju rano i brzo
otkrivanje grešaka.

276
• U isto vrijeme, dio tima koji se bavi zahtjevima, mora
tijesno da sarađuje:
• sa naručiocem i korisnicima, tako da naš tim gradi proizvod koji
zadovoljava njihove potrebe;
• sa projektantima, tako da oni konstruišu projektno rješenje koje
ispunjava specifikaciju zahtjeva;
• sa timom za testiranje, tako da njihovi test skriptovi adekvatno
procijene da li imple-mentacija zadovoljava zahtjeve;
• sa piscima dokumentacije, tako da oni mogu da pišu korisnička
uputstva na osnovu specifikacije.
• Tim mora takođe da obrati pažnju na mjerenja koja
odražavaju kvalitet zahtjeva. Oni koji se bave mjerenjem
mogu da predlažu aktivnosti tima, kao što je izrada
prototipa nekih zahtjeva, kada indikatori pokažu da zahtjevi
nisu dovoljno razumljivi.
• Na kraju, moramo da radimo kao tim na pregledu
dokumenata sa definicijama i specifikacijama, kao i da
ažuriramo te dokumente shodno promjeni zahtjeva tokom
razvoja i održavanja.

277
UPRAVLJANJE SOFTVERSKIM
ZAHTJEVIMA

PRIPREMILA
doc.dr. Isaković Ines

278