Zašto su zahtevi teški - slučajne poteškoće

Objavljeno:

17.06.2012.

Kategorija:

Softverski Zahtevi



"The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want."

— Steve McConnell


Slučajne poteškoće

Koliko god nema sumnje da je suštinski teško dobro napraviti zahteve za softver, isto toliko nema sumnje da uobičajena praksa bespotrebno pogoršava stvari. Koristi se izraz slučajne, kao kontra suštinskim ne da bi se naglasilo da se ove teškoće dešavaju slučajno, već zato što su one rezultat uobičajenih grešaka u menadžmentu, prikupljanju, specifikaciji ili upotrebi zahteva.


Ovim greškama se najlakše pristupa poboljšanom praksom.


Napisano kao dodatna misao

I dalje je uobičajena praksa da se dokumentacija o zahtevima napravi tek pošto je softver napisan. Za mnoge projekte neodoljiv je izazov da se požuri sa implementacijom pre nego što su zahtevi u potpunosti razumeju. Developeri se često osećaju da ne rade ništa ako ne kodiraju; menadžeri su zabrinuti za rokove kada nema vidljivog napretka u impelementaciji... Odatle neshvatljiva potreba da se počne sa ranom implementacijom. Smatra se da je razvoj sistema očigledan način da se bolje razume šta se traži i da se vidi pravo ponašanje sistema. Greška! Rezultat toga je da se zahtevi dopisuju kasnije (ako se uopšte i zapišu), a njihova uloga nije da vode developere i testere, nego se tretiraju kao nužno zlo koje treba da zadovolji ugovorene zahteve.


Takvim zakasnelim dokumentovanjem, neizbežno se narušava osnovni cilji – definisanje šta sistem treba da radi, pre nego kako treba da radi, jer je u pitanju specifikacija napisanog koda. Zakasnelo napisano, nije ni planirano niti uzeto u obzir kao suštinski deo razvoja, a nije čak bilo ni dostupno na vreme da bude vodič iplementaciji ili menadžmentu razvoja.


Dvosmislena svrha

Zbog činjenice da specifikacija zahteva ima mnogo potencijalnih čitalaca, koji imaju različit ugao posmatranja, tačna svrha dokumenta postaje zbunjiva. Često se koristi za prodaju potencijalnim klijentima pa u sebi sadrži marketinško veličanje vrlina prozivoda; obzirom da je u pitanju jedini dokument o tome šta softver treba da radi, u sebi često sadrži uvod, objašnjenje i pregled softvera; koristi se i kao ugovor te namerno ograničava slobodu developera pri razvoju ili mogućnost klijenta da zahteva promene koje ništa ne koštaju; pošto služi kao sredstvo za saopštavanje odluka dizajnerima i koderima često u sebi sadrži detalje o dizajnu i implementaciji. Kao rezultat takvih radnji dobije se dokument u kom je nejasno koje izjave prezentuju stvarne zahteve, a koje su više vezane za marketing, dizajn ili drugu dokumentaciju. Na kraju se dobije dokument koji pokušava da bude svima sve, a u stvari ne služi nikome.


Nije napisan da bude koristan

Često se u žurbi oko implementacije malo truda poklanja zahtevima. Zbog činjenice da se od specifikacije zahteva ne očekuje da bude korisna malo je truda oko dizajna, pisanja, provere, kreiranja ili praćenja razvoja, pa se često dešava da je loše organizovana. Pisana je običnim jezikom i obično prati tok misli autora ili puki redosled izvršavanja.


Tako dobijen dokument je neupotrebljiv kao tehnička referenca jer je nejasno šta predstavlja stvarne zahteve, ne zna se gde je koji zahtev moguće pronaći, a ne postoji jasna procedura koja bi osigurala da je specifikacija dosledna ili kompletna, niti postoji jasan način tretmana izmena zahteva. Specifikacija je komplikovana za upotrebu i održavanje, i brzo postaje zastarela ili izgubi bilo koju korisnost koju je originalno trebalo da poseduje.


Nedostatak suštinskih osobina

Nedostatak predviđanja, nejasna svrha ili nepažljiv dizajn i izvršenje rezultuju zahtevima koji ne poseduju osobine potrebne za dobru tehničku specifikaciju. Dokumentovanje zahteva, ako uopšte postoji, su preobimni, nedosledni, nekompletni, neprecizni i netačni.


Dok su suštinske poteškoće ugrađene u problem, slučajne poteškoće su rezultat nemogućnosti da se održi intelektualna kontrola nad onim što se gradi. Iako je nemoguće pronaći keca iz rukava koji bi rešio prve, možemo rešiti bar druge poteškoće, tako što ćemo koristiti dobro promišljen, sistemski i disciplinovani proces razvoja, koji je osnova za rešavanje suštinskih poteškoća.



FB Komentari: