Šta je to funkcionalna specifikacija softvera? To je opis kako softver treba da radi i kako ne treba da radi. To nije tehnički dokument koji razumiju samo inženjeri, već dokument koji razumije svako ko softver koristi. To nije uputstvo za upotrebu nego dokument koji će da garantuje da će se dve strane u projektu (naručilac i izvršliac) potpuno razumjeti. Funkcionalna specifikacija se piše prije nego što se počne izrada projekta.
Ovo bi trebalo da zanima ljude koji su odgovorni za softverski projekat, ljude koji rukovode timom za izradu softvera ili rade samostalni softverski projekat i ljude koji naručuju softver.
Ako ste naručilac posla funkcionalna specifikacija vam treba za:
- Da biste razjasnili potencijalnom izvršiocu projekta šta tražite.
- Da biste uštedjeli vrijeme koje biste morali da trošite da svakom potencijalnom izvršiocu objašnjavate šta želite.
- Da biste smanjili rizike i gubitke koji bi nastali time što vas izvršioc projekta nije dobro razumio i time što je nedokumentovanja ponašanja softvera shvatio na način na koji vi niste očekivali.
Ako ste neko ko implementira softverski projekat funkcionalna specifikacija vam treba za:
- Da biste mogli da procjenite vrijeme i troškove projekta.
- Da biste znali sve eventualne probleme koje ćete imati pri izradi softvera.
- Da biste izbjegli bilo kakve nesuglasice i probleme sa naručiocem softvera.
Ko je zadužen da piše F.S.?
Idealan slučaj je da naručilac softvera napiše funkcionalnu specifikaciju. Međutim, obično naručilac softvera nema toliko iskustva o funkcionisanju softvera da može da utvrdi i definiše sva ponašanja. U tim slučajevima, izvršilac softvera upotpunjuje specifikaciju koju je napisao naručilac, ili, ukoliko specifikacije nema uopšte, na osnovu zahtjeva naručioca piše specifikaciju.
Ko će to da plati ?
Vrijeme koje oduzima analiza korisničkog zahtjeva i pisanje specifikacije za velike projekte nije malo. To vrijeme se obično obračuna u vrijednost projekta. Često ćete, kao neko ko donosi odluke u softverskoj firmi, biti u situaciji da morate da snosite rizik i uradite analizu i specifikaciju, iako niste sigurni da ćete dobiti projekat.
Treba li nam to stvarno ?
Ne da treba, nego je nužno. Nije nužno zato što je moranje, nego zato što je fantastična stvar koja će vas lišiti mnogih problema koje biste imali u komunikaciji sa drugom stranom u projektu (naručiocem, odnosno izvršiocem). Na osnovu specifikacije ćete bolje raditi i estimaciju i pravdanje troškova. Specifikacija je nešto na šta ćete se pozivati ako projekat ne rardi onako kako ste zamislili, ili ako klijent nije zadovoljan onim što ste mu isporučili.
Je li ima neko pametan da je pisao o ovome ?
Ima. Jeste li čitali članak Džoela Spolskog o specifikaciji koje je pisao još pre 15 godina ? Ako niste, pročitajte ih obavezno. Znate valjda ko je Džoel Spolski ? Ne Džoel Koen, nego Džoel Spolski ! Ako ne znate, onda je ovaj tekst imao smisao bar zbog toga što vam je ukazao na ovog fantastičnog autora IT tekstova.
Prvi u seriji članaka nalazi se ovde: http://www.joelonsoftware.com/articles/fog0000000036.html
Kako se piše funkcionalna specifikacija softvera - KONKRETNO
Osnovu svakog dobro odrađenog softverskog projekta čini planiranje. U fazu planiranja spada i analiza funkcionalnosti proizvoda. Sada će biti predstavljen primjer kako bi specifikacija mogla da izgleda.
Kao primjer možemo razmatrati mobilnu aplikaciju za naručivanje proizvoda određenog proizvođača.
Razmatraćemo situaciju iz ugla izvršioca (u zavisnosti od prakse kompanije, strukture i načina rada, taj posao će raditi projektant softvera, vođa projekta, vođa tima...), u kojoj nam je klijent objasnio donekle šta želi, ali nam nije pismeno precizirao, niti dao prototipe korisničkog interfejsa.
1. Definisanje ekrana aplikacije
Da bi nam bilo lakše da napravimo specifikaciju kako aplikacija treba da radi, treba prvo definisati koje sve ekrane (view-ove) će aplikacija sadržati i kako će izgledati navigacija kroz aplikaciju.
Na slici je dat prikaz ekrana aplikacije. Ekrani koji su isti (detalji proizvoda), obojeni su zelenom.
Navigacionu mapu ekrana treba uključiti u dokument koji će klijent pogledati i odobriti prije nego što se počne sa implementacijom.
2. Izrada prototipa (mockova) ekrana
Pravljenje mockova ekrana će pomoći da jasnije odredimo i objasnimo funkciaonalnosti. Ovu fazu možemo raditi zajedno i sa dekompozicjom funkcionlanosti po ekranima (koja je objašnjena u sljedećem dijelu teksta).
Pravljenje mockova ne podrazumjeva predstavljanje grafičkog dizajna. Bilo bi pogrešno trošiti vrijeme u ovoj fazi projekta trošiti vrijeme na definisanje i predlaganje dizajna kada nismo sigurni da su ekrani i funkcionalnosti onakve kakve naručilac očekuje.
Ne treba bukvalno shvatiti ovu preporuku – u situacijama kada narčilac traži od nas prijedlog korisničkog dizajna, tada je neophodno uključiti i taj aspekt.
3. Dekompozicija funkcionalnosti po ekranima
Kada definišemo sve ekrane i napravimo mockove, lakše nam je da dekomponujemo funkcionalnosti. Najčešće ćemo počinjati od početka, odnosno od prvog ekrana koji će korisnik vidjeti, u ovom slučaju je to login ekran.
Specifikacija funkcionalnosti je jasnija ukoliko se definiše za login ekran bi mogla da izgleda ovako:
4. Login ekran
Specifikacija funkcionalnosti za login ekran:
5. Glavni ekran
Specifikacija funkcionalnosti za glavni ekran:
Na isti način treba popisati sve ostale ekrane.
6. Izdvajanje karakterističnih ponašanja za cijelu aplikaciju
Postoje određena ponašanja koja su karakteristična za cijelu aplikaciju, i ne mogu se svrstati u specifikaciju određenog ekrana. Primjer takvih ponašanja i specifikacije je u sljedećoj tabeli
7. Definisanje platformi na kojima aplikacija radi, ograničenja i obaveza
U funkcionalnoj specifikaciji treba navesti koja su ograničenja i obaveze u vezi sa distribucijom i održavanjem aplikacije. Primjer dijela ove specifikacije je u tabeli ispod:
8. Slanje dokumentacije klijentu, modifikacije i dopune
Nakon što se funkcionalna specifikacija pošalje klijentu, očekuje se ili da bude usvojena ili da se na osnovu nje razmatraju specifikovana ponašanja. Sa jasnom specifikacijom i dalja komunikacija sa klijentom će biti daleko jasnija.
Na osnovu daljeg razgovora, pojedina ponašanja se mogu modifikovati, izbaciti, ili dodati nova.
U ovoj fazi se mogu odrediti i faze izrade projekta kao i šta će od funkcionalnosti biti implementirano u određenoj fazi. Pogledajte primjer u sljedećoj tabeli:
9. „Potpisivanje“ specifikacije od strane klijenta
Potpisivanje ovde nije u bukvalnom smislu. Potpisaće se ugovor, dok će specifikacija da bude „odobrena“ od strane klijenta.
Na ovaj način smo dobili potvrdu da je klijent razumio kako će aplikacija izgledati i raditi.
Time je i klijent dobio potvrdu da je i nama, koji smo tu da implementiramo projekat, jasno šta treba da radimo.
Ovim je funkcionalna specifikacija ispunila svoj cilj. Faza projektovanja i implementacije će sada biti mnogo jednostavnija, neće biti nejasnoća oko toga šta treba da se uradi, biće manje stresa i manje neugodnih komunikacija sa klijentom. Situacije koje smo mogli da imamo „Mislili smo da će ovo da radi ovako“ više nećemo imati.
Funkcionalna specifikacija, pritom, služiće timu koji će na osnovu nje da postavi plan i način testiranja.
10. Značaj specifikacije za usvajanje šablona (patterna) za karakteristične funkcionalnosti
Sem što će specifikacija imati značaj (kao što smo prikazali) u pojedinačnom projektu, njen značaj je i mnogo veći.
Softverski proizvodi imaju dosta sličnih funkcionalnosti i dobrih praksi oko toga kako nešto treba da radi. Kada jednom napišete dobru specifikaciju, vi ste obogatili i svoje iskustvo i napravili sebi, odnosno vašem timu i kompaniji šablon za ponašanje aplikacije u sličnim okolnostima.
Poslije nekoliko projekata u kojima ste imali i rad na funkcionalnoj specifikaciji, postaćete mnogo svjesniji i problema koje novi projekat nosi, postaćete i puni novih ideja koje ćete moći da predložite klijentu pri razgovoru o novom projektu.
Ukoliko svi u kompaniji rade na ovaj način, šabloni za karakteristična ponašanja će biti brže usvojeni i bolje iskorišćeni.
NAPOMENA: Ako želite da promovišete link u ovom članku, javite mi.
Ako vam se ovaj članak dopao, lajkujte FB stranicu DM Spot, Twitter ili LinkedIn i budite obavješteni kad novi članak bude objavljen.
