Specifikacija softvera po meri treba da opiše posao koji korisnik završava: ko pokreće zadatak, koje podatke unosi, koja pravila važe i kako proveravate rezultat. Dodajte prava pristupa, izuzetke, veze sa postojećim programima i obim prve verzije. Za početni razgovor dovoljan je jedan razrađen proces sa označenim otvorenim pitanjima.
Krenite od zadatka zbog kojeg zaposleni danas prepisuju podatke ili traže potvrdu porukama. Ako još odlučujete šta kupiti, pogledajte poređenje gotovog softvera i razvoja po meri. Specifikacija vam zatim pomaže da za izabrani obim tražite ponudu i dogovorite proveru isporuke.
Šta ulazi u prvu verziju?
Zapišite gde proces počinje i kada je završen. Za zahtev za nabavku to može biti unos zaposlenog, odluka rukovodioca i pregled statusa. Fakturisanje i plaćanje predstavljaju dodatni obim, čak i kada se prirodno nadovezuju na isti posao.
Uz svaki zahtev označite „prva verzija”, „kasnije” ili „otvoreno pitanje”. Funkcija koja čeka odluku nije automatski uključena u cenu. Navedite ko treba da odluči i do kada, naročito ako odgovor utiče na ponudu. Prioritete proverite sa ljudima koji obavljaju posao, uz primer njihovog sadašnjeg postupka.
Korisničku potrebu možete sažeti u rečenicu o ulozi, zadatku i razlogu. Takav zapis preporučuje GOV.UK vodič za korisničke priče. Za razvoj zatim dopišite pravila koja tu rečenicu pretvaraju u određeno ponašanje.
Obrazac za jedan poslovni zadatak
Kopirajte pitanja i popunite odgovore za svaku važnu radnju. Uz nepoznat podatak upišite ko ga proverava.
Pomerite tabelu levo ili desno da vidite sve kolone.
| Stavka | Šta upisujete |
|---|---|
| Zadatak i razlog | Koji posao korisnik završava i zašto mu je potreban? |
| Uloge i pristup | Ko unosi, vidi, menja, odobrava i izvozi podatke? |
| Ulazni podaci | Koja polja su obavezna, koje vrednosti su dozvoljene i odakle podaci dolaze? |
| Tok i završetak | Šta pokreće radnju, kojim redom se odvija i koji zapis ili status nastaje? |
| Izuzeci | Šta se dešava pri grešci, odbijanju, prekidu veze ili ponovljenom slanju? |
| Provera | Sa kojim primerom podataka proveravate svaki očekivani ishod? |
| Obim i odgovornost | Da li je zahtev u prvoj verziji, ko ga odobrava i koja je važeća verzija? |
Popunjen primer: zahtev za nabavku opreme
Ovo je izmišljen primer interne aplikacije. Iznosi i pravila služe objašnjenju specifikacije; ne opisuju klijenta ni postojeći proizvod. Zadatak NAB-01 glasi: zaposleni traži opremu da bi rukovodilac mogao da odobri nabavku pre poručivanja.
Prva verzija obuhvata jednu stavku po zahtevu, odluku i pregled statusa. Poručivanje kod dobavljača, plaćanje i email obaveštenja ostaju van tog obima. Korisnici se prijavljuju postojećim nalozima koje firma priprema za probu.
Pomerite tabelu levo ili desno da vidite sve kolone.
| Deo zahteva | Dogovoreno ponašanje |
|---|---|
| Uloge | Zaposlena Ana kreira i vidi svoje zahteve. Rukovodilac Milan vidi sve zahteve i donosi odluku. Ana nema pristup tuđim zahtevima ni odobravanju. |
| Popunjeni podaci | Naziv: bežična tastatura. Količina: 2. Procenjena cena po komadu: 45 EUR. Odeljenje: Operativa. Razlog: zamena dve neispravne tastature. Ukupno: 90 EUR, izračunato u aplikaciji. |
| Pravila unosa | Naziv, količina, cena, odeljenje i razlog su obavezni. Ukupan iznos se računa i korisnik ga ne menja. Količina je ceo broj od 1 do 100, a cena pozitivan broj sa najviše dve decimale. Odeljenje se bira iz pripremljene liste. |
| Redovan tok | Ana šalje obrazac. Aplikacija čuva zahtev NAB-104 sa statusom „Na čekanju”, autorom i vremenom slanja. Milan otvara zahtev i odobrava ga. Status postaje „Odobreno”; beleže se donosilac odluke i vreme. |
| Odbijanje | Ako nema odobrenog budžeta, Milan bira „Odbij” i upisuje „Nabavka nije u budžetu ovog meseca”. Razlog je obavezan. Ana vidi status „Odbijeno”, obrazloženje, ime rukovodioca i vreme odluke. |
| Neispravan unos | Bez razloga nabavke slanje nije uspešno. Poruka se prikazuje uz polje, ostali unosi ostaju sačuvani u obrascu, a zahtev ne nastaje. |
| Ponovljeno slanje | Dva klika ili ponovni pokušaj iste predaje posle prekida veze vraćaju isti NAB-104. Nastaje jedan zahtev. Za namerno novu nabavku Ana otvara novi obrazac. |
| Naknadne izmene | Poslati zahtev se ne menja. Pogrešan zahtev na čekanju Milan prvo odbija uz razlog. Ana zatim kreira novi zahtev. Posle odluke zahtev više ne može da se odobrava ili odbija. |
Dogovorite postupak ispravke pre razvoja. U ovom primeru prethodni zahtev mora da bude odbijen pre nove prijave, kako obe nabavke ne bi ostale otvorene.
Kako napisati kriterijume prihvatanja?
Kriterijumi prihvatanja opisuju ishode koje proveravate za konkretan zahtev. Za NAB-01, poslovni predstavnik i razvojni tim mogu da prođu sledeće provere sa probnim nalozima. Svaka je zaseban scenario; za proveru odluke pripremite nov zahtev sa statusom „Na čekanju”.
- Kada Ana pošalje navedene podatke, nastaje jedan zahtev sa ukupnim iznosom 90 EUR i statusom „Na čekanju”.
- Kada je razlog prazan ili količina 0, zahtev ne nastaje; obrazac pokazuje odgovarajuću grešku i zadržava ostale unose.
- Kada Ana pokuša da otvori tuđ zahtev ili pošalje odluku o odobravanju, aplikacija odbija pristup i ne menja podatke.
- Kada Milan odobri zahtev, Ana vidi odluku, ime rukovodioca i vreme. Ponovna odluka ne menja završeni zahtev.
- Kada Milan odbije zahtev bez obrazloženja, status ostaje „Na čekanju”. Sa navedenim razlogom postaje „Odbijeno”; Ana vidi obrazloženje, donosiloca odluke i vreme.
- Kada se ista predaja ponovi, uključujući ponovni pokušaj posle prekida veze, lista sadrži jedan NAB-104.
Prihvatanje jedne radnje ne obuhvata celo testiranje aplikacije. U GOV.UK smernicama za kvalitet funkcionalne provere su deo šire provere, uz bezbednost, performanse i pristupačnost. Dogovorite ko proverava te oblasti i kako se beleže nalazi.
Šta skica ekrana objašnjava, a šta treba dopisati?
Skica pokazuje raspored polja, dugmadi i poruka. Pored nje zabeležite obavezna polja, izračunavanje iznosa i uslove pod kojima je odluka dozvoljena. Uključite prazan pregled, grešku i završeni zahtev, uz vezu sa oznakom NAB-01.
Klikabilni prototip može pomoći zaposlenom da prođe postupak pre razvoja. Njegov prikaz uspešne predaje ne dokazuje da su čuvanje podataka ili prava pristupa već napravljeni. Za javni prezentacioni sajt, sadržaj i strukturu stranica zasebno razradite kroz brief za izradu sajta.
Za projekat koji koristi AI pretragu dopunite specifikaciju popisom dozvoljenih izvora i očekivanim odgovorima. Vodič za pripremu dokumenata za AI asistenta daje izmišljen primer kolekcije i predlog provere verzija, pristupa i nedostajućih podataka.
Podaci, integracije i uslovi rada
Popišite podatke koje preuzimate, njihove izvore i osobu koja proverava tačnost. Za postojeću tabelu zabeležite identifikatore, prazna polja i duplikate. Dogovorite probni uvoz, format izvoza i pravila čuvanja ili brisanja. Za početnu specifikaciju koristite izmišljene ili anonimizovane primere.
Ako se odobrena nabavka šalje drugom programu, navedite tačan događaj slanja, polja i smer prenosa. Odredite koji sistem vodi status, ko vidi neuspešan prenos i kako ponovni pokušaj izbegava duplikat. Dostupnost dokumentacije i probnog pristupa označite pre procene integracije.
Zahtev „aplikacija treba da bude brza” zamenite merljivim uslovom. Na primer: uz 20 istovremenih korisnika i 10.000 sačuvanih zahteva za nabavku, najmanje 95 od 100 otvaranja liste traje kraće od dve sekunde. Dogovorite probno okruženje, uređaj, mrežu i način merenja. Ovi brojevi su ilustracija, a stvarni cilj odredite prema poslu. GOV.UK smernice za performanse povezuju testiranje sa planiranim opterećenjem.
Dodajte podržane uređaje, rad tastaturom, upravljanje pristupom i postupak vraćanja rezervne kopije. Navedite koliko dug prekid rada ili koliki gubitak poslednjih izmena posao može da podnese, pa sa izvođačem dogovorite način provere i održavanja.
Ko odobrava izmene i šta poslati za procenu?
Odredite jednu osobu u firmi koja potvrđuje poslovna pravila. Razvojni tim uz predlog izmene beleži uticaj na cenu, rok i postojeće funkcije. Sačuvajte prethodnu verziju, novu oznaku, razlog promene i odobrenje. Kriterijumi prihvatanja treba da prate istu verziju kao zahtev.
Za izradu softvera po meri pripremite jedan popunjen zadatak, spisak postojećih programa i odvojene želje za kasnije. U zahtevu za besplatnu procenu projekta navedite i otvorena pitanja. Na toj osnovi možemo da razradimo obim prve verzije i podatke potrebne za ponudu.