ducin blog®:
kako to rade pravi majstori

Software Requirements

Kao što sam već govorio, većina softverskih projekata osuđena je na neuspeh. Najčešći razlog je loš postupak upravljanja zahtevima. Neretko se dešava da su zahtevi potpuno zanemareni. O tome kakve posledice to ima, bilo je reči. Stoga, danas, nešto više reči o zahtevima.

Software Requirements Specification

Bez obzira da li pravite operatini sistem, CAD aplikaciju, tekst procesor ili neki drugi software, nameću se iste potrebe. Prvo, treba precizno utvrditi zahteve, a onda i obezbediti proces upravljanja zahtevima. Kao krajnji rezultat ovih aktivnosti treba da se dobije specifikacija zahteva, tj. Software Requirements Specification. Pored same aplikacije koja se razvija, ovo je najvažnija komponenta čitavog projekta.Dokument specifikacije zahteva može da se čuva u bilo kojoj formi. Na papiru, kao tekstualni dokument, u obliku tabele ili u relacionoj bazi. Ipak, najbolje je da se za te potrebe koristi neki specijalizovani alat.

Kakvi sve zahtevi postoje

Postoji više tipova zahteva. Generalno, svaki zahtev može da se svrsta u jednu od dve kategorije: funkcionalni i nefunkcoinalni. Funkcionalni zahtevi, predstavljaju svaku funkciju sistema. Ove funkcije mogu da koriste kajnji korsnici ili pak drugi sistemi i podsistemi. Neki od primera su: proveri stanje na računu, podigni novac, pijavi ispit, štampaj račun, prosledi fakturu itd... Ono što ih karakteriše je specifičan oblik "glagol-imenica". Na taj način uvek ih je lako prepoznati.

Nefunkcionalni zahtevi opisuju karakteristike koje sistem treba da ima. Karakteristike mogu da se svrstaju u neku od sledećih kategorija: prenosivost, skalabilnost, bezbednost, privatnost, autentikacija, enkripcija, opterećenje... Neki od primera su sledeći: "Sistem mora da podrži minimum 100 istovremenih korisnika"; "Sistem treba da opsluži najamnje 1000 konkurentnih zahteva u sekundi"; "Svi lični podatci korsnika treba da se čuvaju u kriptovanoj formi" itd.

Zahtevi/Dizajn/Implementacija

Sistem može da se posmatra na više načina. Sa aspekta korisnika, projektanta, programera... Zahtevi predstavljaju sistema na konceptualnom nivou, odnosno onako kako ga korisnik vidi. Kao skup funkcija koje mu stoje na raspolaganjju. Dizajn je pogled na sistem iz ugla projektanta, tj. sistem na logičkom nivou. Skup objekata i akcija koje ti objekti obavljaju. Implementacija prikazuje sistem onako kako ga vidi programer. Skup klasa, funkcija, paketa, komponenata...

Svaki nivo može da se posmatra kao zaseban sloj sistema. Sloj zahteva je iznad sloja dizajna, koji je opet iznad sloja implementacije. Sloj na višem nivou potpuno određuje sloj na nižem. Sa druge strane sloj na nižem nivou ni na koji način ne sme da određuje sloj na višem nivou. To za posledicu ima da dizajn i implementacija ni na koji način ne smeju da utiču na zahteve. Rešenje je da se zahtevi predstave jezikom korsinika, te da se izostave bilo kakvi tehnički termini. Slede dva primera:

• Primer 1: Korsnik od sistema zahteva rasploživi iznos za trošenje. Sistem prikazuje stanje kojim korisnik raspolaže na računu.
• Primer 2: Korisnik bira odgovarajuću opciju padajućeg menija, desnim klikom miša. Zahtev se prosleđuje do SQL servera koji čuva informacije o računima korisnika. Poziva se uskladištena procedura....

Prethodna dva primera predstavljaju dve očigledne suprotnosti. Prvi primer je odličan primer jednog funkcionalnog zahteva. Korišćen je samo rečnik korisnika. Ne pretpostavlja se ništa o načinu na koji korisnik stupa u interakciju sa sitemom. Pritiskom na neki od tastera ATM-a, ili izborom opcije na touch-screenu. O tome da li se stanje prikazuje na ekranu ili se štampa račun. Ne govori se ništa ni o tome kako su realizovane ove funkcije. Korisnika ne interesuje način na koji sistem funkcioniše Interesuje ga samo krajnji benefit, informacija o raspoloživom stanju.

Drugi primer je potpuna suprotnost. Ovde su napravljene sve greške, koje je bilo moguće napraviti. Pretpostavlja se da sistem koristi grafički interfejs i padajuće menije. Da se u interakciji sa sistemom korsnik služi mišem. Nameđe se ograničenje da se podatci o korisniku čuvaju u bazi podataka, te da postoji poseban server za tu namenu. Pominju se i uskladištene procedure... Na ovaj način zahtevi su "zaprljani" pretpostavkama o dizajnu i implementaciji. To dovodi do toga da korisnik ne razume opisane funkcija sistema, pa ni ne učustvuju u procesu. Sistem, sa druge strane, postaje potpuno nefleksibilan i ograničen nametnutim rešenjima.

Wearing multiple hats

Za "zamenu šešira" ne postoji neki adekvatan prevod na naš jezik. Bilo kako bilo, sposobnost da menjate šešir na svojoj glavi može da bude presudna u procesu razvoja. O čemu se zapravo radi. U kontekstu ove priče, to znači da prilikom pisanja zahteva treba da nosite šešir krajnjeg korsnika aplikacije. Pitanje je ŠTA, a ne KAKO. Tajna je u veštini da mentalni kontekst prilagodite trenutnoj fazi razvoja. Kao što zante, context switch je jako skupa operacija. Posebno kada je procesor sačinjen od ćelija sive mase.

Dobra vest je da sa stavljanjem programerskog šešira retko ko ima problema.