U ovoj lekciji obradjivaćemo:

• Važnost ispravne interpretacije zahteva
• Ko su zainteresovani subjekti (stakeholders)
• Kako jedne druge vidi projektanti i korisnici
• Kakvi tipovi zahteva postoje
• Ragraničenje tipova zahteva

Značaj ispravnog tumačenja zahteva

Izvođenje zahteva je posebno važan deo procesa. Moraju se koristiti razne tehnike za utvrđivanje šta korisnici i naručioci stvarno žele. Ponekad se automatizuje ručni sistem, tako da je utvrdivanje šta sistem stvarno radi lako. Međutim, često moramo da radimo sa korisnicima i naručiocima da bismo razumeli problem koji je potpuno nov. Taj zadatak se retko svodi na jednostavno postavljanje pravih pitanja radi prikupljanja zahteva koje naručilac ima u svojoj glavi. U ranoj fazi projekta, zahtevi su nedovoljno formulisani i nedovoljno dobro shvaćeni. Naručilac ne može uvek, prilikom opisivanja, dovoljno precizno iskazati šta hoće ili šta mu stvarno treba, a mi nismo uvek u stanju da dovoljno dobro shvatimo tuđe poslovne probleme. Naručilac poznaje svoj posao, ali ne može uvek strancima da opiše svoje poslovne probleme. Njegovi opisi sadrže žargone i pretpostavke koje nam možda nisu bliski. Slično tome, kao projektantima, poznata su nam računarski zasnovana rešenja, ali ne uvek i to kako će moguća rešenja uticati na poslovne aktivnosti naručioca. Mi, takodje, posedujemo vlastiti žargon i pretpostavke, mislimo da svi govore istim jezikom, a u stvari različiti ljudi podrazumevaju potpuno različita značenja iste reći. Do zajedničkog dogovora sa svima o tome koji su zahtevi, dolazimo jedino raspravom o zahtevima sa nekim ko je zainteresovan za sistem, objedinjavanjem tih različitih pogleda u koherentni skup zahteva, kao i zajednički pregled sa zainteresovanim subjektima dokumenata koji sadrže zahteve. Ako ne možemo da se usaglasimo oko zahteva, kompletan projekat je unapred osuđen na neuspeh.

Slika 1.

Zainteresovani subjekti (stakeholders)

Ko su u stvari zainteresovani subjekti? Ispostavlja se da ima više ljudi koji mogu dati doprinos zahtevima 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 reć 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 meri da razumemo 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 delove sistema koji zahtevaju poboljšanje. Možda ćemo želeti da se posavetujemo takođe i sa posebnim interesnim grupama korisnika, da bismo razumeli njihove posebne potrebe, kao što su korisnici sa invaliditetom, osobe kojima nisu bliski računari ili ih nerado koriste, stručni korisnici i drugi.

Slika 2.

• Stručnjaci iz konkretne oblasti primene, su oni kojima je problem koji softver treba da automatizuje blizak. Na primer, konsultovaćemo stručnjaka za finansije ako
  gradimo finansijski paket, ili meteorologa ako softver treba da modeluje vremenske prilike. Te osobe mogu da učestvuju u definisanju zahteva, ili poseduju znanja o karakteristikama okruženja u kojima će proizvod funkcionisati.
• 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 validni, bezbedonosni i pravni zahtevi: Na primer, možemo da se posavetujemo 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ženjeri i drugi tehnolozi: Ovi 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 procene troškove i vreme potrebno za razvoj proizvoda.

Različiti pogledi zainteresovanih subjekata

Svi zainteresovani subjekti imaju poseban pogled na sistem i način na koji sistem treba da funkcioniše i ti pogledi su neretko protivrečni. Analitičari zahteva moraju da razumeju svaki pogled i da formulišu zahtev na način koji odražava interese svih učesnika. Na primer, naručilac može da specifikuje da sistem izvodi određeni zadatak, ali naručilac nije uvek i korisnik predloženog sistema. Korisnik možda hoće da zadatke izvodi na tri načina: u režimu učenja, u režimu početnika i u ekspertskom režimu. To razdvajanje omogućava korisniku da postepeno uči i ovladava sistemom. Mnogi sistemi za obradu teksta implementirani su na taj način, tako da se neiskusni korisnici mogu postepeno prilagoditi novom sistemu. Međutim, konflikti mogu da nastanu kada lakoća korišćenja podrazumeva sistem koji radi sporije nego što to dozvoljavaju zahtevi u pogledu vremena odziva.

Slika 3.

Takodje, različiti učesnici mogu da očekuju različite nivoe detalja u dokumentaciji zahteva, a u tom slučaju zahtevi treba da budu različito priređeni za različite osobe. Pored toga, korisnici i učesnici u razvoju mogu da imaju predrasude (ispravne ili pogrešne) o tome šta druge grupe vrednuju i kako deluju. Tabela 1. zbirno prikazuje neke od uobičajenih stereotipa. Ova tabela naglašava ulogu koju interakcija među ljudima igra u razvoju softverskih sistema. Za dobrog analitičara zahteva bitni su izvrsni međuljudski odnosi, kao i solidne tehničke sposobnosti.

Tabela 1. Kako jedni druge vide korisnici i projektanti:

Tabela 1.

Uz ispitivanje zainteresovanih subjekata, dopunska sredstva za izvođenje zahteva obuhvataju:

• Pregledanje raspoložive dokumentacije, kao što su dokumentovane procedure ili ručni poslovi, kao i specifikacije ili korisnička uputstva automatizovanih sistema.
• Posmatranje postojećeg sistema (ako je to moguće), radi prikupljanja objektivnih informacija o tome kako korisnici izvode svoje zadatke i bolje razumevanje sistema koji treba automatizovati ili izmeniti
• Učenje zanata od korisnika, detaljnije učenje o poslovima koje korisnik obavlja dok ih ovaj izvršava
• Intervjuisanje korisnika ili zainteresovanih subjekata u grupama, tako da oni budu inspirisani idejama drugih.
• Upotreba strategija specifičnih za datu oblast, kao što je tzv. zajednički razvoj aplikacije (Joint Application Design) ili PIECES (Wetherbe 1984) kod informacionih sistema.

Model prikazan na slici 4, za definisanje zahteva predlaže i dodatne izvore, kao što su predlošci i biblioteke zahteva iz sličnih, ranije razvijenih sistema.

Slika 4. Izvori mogućih zahteva

Tipovi zahteva

Kada većina ljudi razmišlja o zahtevima, oni razmišljaju o traženoj funkcionalnosti. Koje usluge treba da se obezbede? Koje operacije treba da se izvode? Šta treba da bude reakcija na odredjeni stimulans? Kako se zahtevano ponašanje menja u funkciji vremena i reakcija na prethodne događaje? Funkcionalni zahtev opisuje obavezno ponašanje u funkciji neophodnih aktivnosti, kao što su: reakcije na ulaze i stanja svakog entiteta pre pojave i nakon okončanja svake aktivnosti. Na primer, u slučaju sistema za obračun zarada, funkcionalni zahtevi 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 promeni iznos za isplatu, kao i koji su razlozi uklanjanja radnika sa platnog spiska.

Funkcionalni zahtevi definišu granice koje omedjuju prostor rešenja našeg problema. Prostor rešenja predstavlja skup mogućih načina izrade softvera koji implementira specifikovane zahteve. Inicijalno, taj skup može da bude vrlo velik. Medutim, u praksi obično nije dovoljno da softverski proizvod ispravno izračunava izlazne podatke, jer postoje i drugi tipovi zahteva na osnovu kojih je moguće jasno razlikovati prihvatljive proizvode od neprihvatljivih. Zahtev u pogledu kvaliteta, ili nefunkcionalni zahtev, opisuje neke karakteristike kvaliteta koje softversko rešenje mora da poseduje, kao što je, na primer, kratko vreme odziva, lakoća korišćenja, visoka pouzdanost ili niski troškovi održavanja, izraženo u kvantifabilnoj formi. Projektno ograničenje predstavlja unapred donetu odluku, na primer, izbor platforme ili interfejs komponenti, koja ograničava skup mogućih rešenja razmatranog problema. Procesno ograničenje predstavlja ograničenje koje se odnosi na tehnike ili resurse koji se mogu koristiti u izgradnji sistema. Na primer, naručilac može da insistira na primeni agilnih metoda, da bi mogao operativno koristiti rane verzije sistema uz kontinuirano proširivanje njihove funkcionalnosti. Prema tome, zahtevi u pogledu kvaliteta, projektna i procesna ograničenja dodatno sužavaju prostor rešenja.

Slika 5.

Tabela 2 sadrži primere zahteva različitog tipa. Zahtevi u pogledu kvaliteta ponekad zvuče kao „majčinske" karakteristike koje svi proizvodi treba da poseduju. Nakon svega, ko bi zahtevao softverski sistem koji je spor, neprijateljski, nepouzdan i težak za održavanje. Bolje je zahteve u pogledu kvaliteta posmatrati kao kriterijum projektovanja koji može da se optimizuje i koristi za izbor između različitih načina za implementaciju funkcionalnih zahteva. Ako usvojimo takav pristup, tada zahtevi treba da daju odgovor na sledeće pitanje: Do kog stepena mora proizvod da zadovolji zahteve u pogledu kvaliteta da bi bio prihvatljiv?

Tabela 2. Pitanja za razgraničavanje različitih tipova zahteva

Tabela 2.

Dodaj komentar Sviđa mi se - (0) Ne sviđa mi se - (0)    

Ime Nick Email Title Sigurnosni kod

CommentText

• Opšte karakteristike izvođenja zahteva 1

• Opšte karakteristike izvođenja zahteva 2

• Opšte karakteristike izvođenja zahteva 3