Kako pripremiti zahtev za izradu softvera po meri

Dobar zahtev opisuje problem, korisnike i očekivani rezultat dovoljno jasno da više ljudi može da ga razume na isti način. Za prvi razgovor nije potrebna tehnička specifikacija od pedeset strana. Korisniji su jedan stvaran tok rada, primer ulaznih podataka i objašnjenje šta znači uspešno završen posao.

Zahtev „treba nam aplikacija za firmu“ ostavlja mnogo prostora za pretpostavke. Zahtev „prodaja treba da pripremi ponudu, menadžer da odobri popust, a administracija da preuzme odobrene stavke“ već pokazuje korisnike, korake i granice zadatka.

Opišite sadašnji proces

Zapišite šta pokreće posao, ko učestvuje i gde se čuvaju informacije. Navedite alate koje tim koristi i mesta na kojima prepisuje podatke, čeka odobrenje ili traži poslednju verziju dokumenta.

Dodajte jedan primer sa izmišljenim ili anonimizovanim podacima. Dovoljni su obrazac, tabela ili skica. Zadržite strukturu koja je bitna za razumevanje problema, bez unošenja tuđih ličnih ili poslovno osetljivih podataka u početni materijal.

Definišite korisnike i dozvole

Navedite uloge i za svaku odgovorite: šta vidi, šta menja, šta odobrava i šta ne sme da uradi. „Svi imaju pristup aplikaciji“ nije dovoljno za određivanje pristupa pojedinačnim podacima.

Ilustrativni primer: zaposleni vidi svoje zahteve, rukovodilac zahteve svog tima, a administrator upravlja nalozima. Posebno odlučite da li administratorska uloga automatski znači i pristup poslovnom sadržaju. Tu odluku treba pretočiti u pravila i testove.

Uključite i promenu uloge, odlazak zaposlenog i postupak dodele novog pristupa.

Razdvojite prvu verziju od kasnijeg razvoja

Prva verzija treba da zatvori upotrebljiv poslovni tok. Ako se zahtev može uneti, ali niko ne može da ga obradi ili završi, tim još nema celinu koju može da koristi.

Podelite potrebe u tri grupe:

1. Neophodno za rad: bez toga proces ne može da se izvrši ili kontroliše.
2. Važno za narednu fazu: donosi korist, ali postoji prihvatljiv privremeni postupak.
3. Ideje za kasnije: traže dodatnu proveru potrebe i obima.

Za svaku grupu odredite osobu koja donosi odluku o prioritetu. Tokom razvoja nove ideje se beleže i procenjuju pre nego što promene rok i cenu dogovorene faze.

Navedite podatke i integracije

Popišite sisteme sa kojima aplikacija treba da razmenjuje podatke. Za svaki navedite smer razmene, učestalost i ko može da obezbedi tehničku dokumentaciju ili testni pristup.

Zahtev „povezivanje sa računovodstvom“ treba razložiti: koji podaci se šalju, kada, ko potvrđuje ispravnost i šta se radi kada slanje ne uspe. Proverite i da li postojeći dobavljač dozvoljava takvo povezivanje i pod kojim uslovima.

Ako je potreban prenos starih podataka, uključite uzorak, približan obim i pravila za duplikate i nepotpune zapise.

Napišite proverljive kriterijume prihvatanja

Kriterijum opisuje ponašanje koje može da se pokaže na testu. Umesto „aplikacija mora biti jednostavna“, napišite konkretan zadatak i očekivani rezultat.

Neodređen zahtev	Primer proverljivog kriterijuma
Odobravanje ponuda	Korisnik šalje ponudu, rukovodilac je odobrava, a sistem beleži ko je odobrio i kada
Zaštita podataka	Korisnik iz drugog tima ne može da vidi ili izmeni zahtev ni direktnim otvaranjem njegove adrese
Izvoz izveštaja	Izvoz sadrži dogovorene kolone i poštuje izabrani vremenski period

Dogovorite ko testira, na kojim primerima i kako se beleže primedbe. Za performanse navedite očekivani broj korisnika i obim podataka, pa tek onda usaglasite merljive ciljeve.

Kratak obrazac za prvi razgovor

• Problem koji rešavamo i posledica koju danas ima.
• Korisnici i njihove uloge.
• Jedan tok rada od početka do kraja.
• Neophodne funkcije prve verzije.
• Podaci i postojeći sistemi.
• Željeni rok, raspoloživi budžetski okvir i razlog za taj rok.
• Osoba koja potvrđuje prioritete i prihvata rezultat.

Ako još birate pristup, pročitajte poređenje gotovog softvera i razvoja po meri. Za razgovor o projektu možete krenuti upravo od ovog kratkog obrasca.