Analiza zahteva

Perspektiva sistemskog inženjeringa na analizu zahteva.

Analiza zahteva u sistemskom inženjeringu i softverskom inženjeringu, obuhvata one zadatke koji se izvode pri utvrđivanju potreba ili uslova da bi se ostvario novi ili izmenjeni proizvod ili projekat, uzimajući u obzir eventualno konfliktne zahteve različitih karaktera, analiza, dokumentovanja, procena i upravljanja softverom ili sistemske zahteve.

Analiza zahteva je od ključnog značaja za uspeh projekta, sistema ili softvera. Zahtevi treba da budu dokumentovani, delotvorni, merljivi, testirani, praćeni, u vezi sa identifikovanim poslovnim potrebama ili mogućnosti i definisani do nivoa detalja dovoljno za projektovanje sistema.

Pregled

Konceptualno, analiza zahteva obuhvata tri vrste aktivnosti:

• Formulisanje zahteva: dokumentacije poslovnih procesa i intervjui zainteresovanih strana. Ovo se ponekad naziva prikupljanje zahteva.
• Analiziraranje zahteva: utvrđivanje da li su navedeni zahtevi jasni, potpuni, dosledni i nedvosmisleni, i rešavanje bilo kakvih sukoba.
• Dokumentovanje zahteva: Zahtevi mogu biti dokumentovani u različitim oblicima, obično uključujući skraćeni spisak i mogu uključivati fizičko-jezičke dokumente, upotebne primere, korisnička iskustva ili proces specifikacije.

Analiza zahteva može biti dug i naporan proces tokom kojeg su uključene mnoge delikatne psihološke sposobnosti. Novi sistemi menjaju sredinu i odnose među ljudima, tako da je važno da se identifikuju sve zainteresovane strane, uzmu u obzir sve njihove potrebe i da se obezbedi da razumeju implikacije novih sistema. Analitičari mogu primeniti nekoliko tehnika za sakušljanje zahteva od strane kupaca. Oni mogu da obuhvate razvoj scenarija (predstavljen kao korisnička priča u agilnim metodama), identifikacija korisničke upotrebe, upotreba posmatranja na radnom mestu ili  etnografija, držanje intervjua, ili fokus grupe (više prigodno nazvan u ovom kontekstu kao zahtevi radionice, ili zahtevi preispitivanja sesije) i stvaranje zahteva listama. Prototipovi mogu da se koriste da razviju primer sistema koji može da se dokaže akterima. Ukoliko je potrebno, analitičar će zaposliti kombinaciju ovih metoda da se utvrdi tačan zahtev zainteresovanih strana, tako da sistem koji zadovoljava poslovne potrebe se proizvodi. Kvalitet zahteva se može poboljšati kroz njih i drugih metoda

• Vizuelizacija. Koristeći alate koji promovišu bolje razumevanje željenog krajnjeg proizvoda takve kao vizuelizaciju i simulaciju.
• Dosledno korišćenje šablona. Izrada doslednog skupa modela i obrazaca da dokumentuju uslove.
• Dokumentovanje zavisnosti. Dokumentovanje zavisnosti i međusobnosti među zahtevima, kao i sve pretpostavke i kongregacije.

Tema zahteva analize

Identifikacija zainteresovanih strana

Pogledajte analizu zainteresovanih strana za diskusiju ljudi ili organizacije (pravna lica, kao što su preduzeća, organizacije za standardizaciju) koji imaju opravdan interes u sistemu. Oni mogu biti pogođeni direktno ili indirektno. Glavni novi akcenat u 1990. bio je fokus na identifikaciji aktera. Sve se više prepoznaje da akteri nisu ograničeni na organizaciji poslodavca analitičara. Ostali učesnici će uključivati:

• svako ko upravlja sistemom (normalni i održavački operateri)
• svako ko ima koristi od sistema (funkcionalni, politički, finansijski i socijalni korisnici)
• svi uključeni u kupovinu i nabavku sistema. U organizaciji masovno tržište proizvoda, upravljanju proizvodima, marketingu i ponekad prodaje kao surogat aktom potrošača (masovnom tržištu kupaca) da vodi razvoj proizvoda
• organizacije koje regulišu aspekti sistema (finansijski, bezbednost i drugi regulatori)
• ljudi ili organizacije koje se suprotstavljaju sistemu (negativni akteri; videti takođe slučaj zloupotrebe)
• organizacije odgovorne za sisteme koji interfejs sa sistemom pod dizajn
• one organizacije koje integrišu horizontalno sa organizacijom za koju je analitičar projektovanje sistema

Intervjui interesnih grupa

Intervjui interesnih grupa su uobičajene tehnike koje se koriste u analizi zahteva. Iako su uglavnom idiosinkratične u prirodi i fokusirane na perspektive i uočene potrebe zainteresovanih strana, često taj nedostatak perspektiva ima opštu prednost dobijanja mnogo bogatijeg razumevanja aktera jedinstvenih poslovnih procesa, donošenjem odgovarajućih poslovnih pravila, i uočene su potrebe. Zbog toga ova tehnika može da posluži kao sredstvo za dobijanje visoko fokusiranog znanja koje se često ne izaziva u zajedničkim zahtevima za razvoj sesije, gde je pažnja zainteresovanih strana prisiljena da preuzme više kros-funkcionalni kontekst, i želja da se izbegne kontroverza može ograničiti spremnost zainteresovanih strana da doprinesu. Pored toga, u-lice priroda razgovora daje više opuštenu atmosferu u kojoj linije misli mogu biti istražene u dužini.

Zajednički zahtevi za razvoj (JRD)  

Zahtevi često imaju kros-funkcionalne implikacije koje su nepoznate kod pojedinih učesnika i često se propuštaju ili su nepotpuno definisane tokom razgovora sa zainteresovanim stranama. Ove kros-funkcionalne posledice mogu biti izazvane obavljanjem JRD sesija u kontrolisanom okruženju, omogućavanjem obučenih moderatora (Poslovni analitičar), gde akteri učestvuju u diskusijama na izazove zahteva, analiziraju svoje podatke i otkrivaju kros-funkcionalne implikacije. Posvećeni pisari treba da budu prisutni da dokumentuju diskusiju, čime se oslobađa poslovni analitičar da vodi diskusiju u pravcu koji generiše odgovarajuće uslove koji odgovaraju cilju sesije.

JRD Sesije su analogni zajedničkoj aplikaciji dizajn sesija. U prvoj nedelji izazivaju uslove koji vode dizajn, dok kasnije izazivaju specifične karakteristike dizajna koje treba sprovesti u zadovoljavanju uslova izazvanih.

Lista zahteva stilom ugovora

Jedan tradicionalni način dokumentovanja zahteva je spisak zahteva stilom ugovora. U složenom sistemu takve zahteve lista mogu pokrenuti na stotine stranica dugo.

Odgovarajuća metafora bio bi izuzetno dug spisak za kupovinu. Takvi spiskovi su veoma pali u nemilost u modernoj analizi; jer su se pokazali neuspešni spektakularno na postizanje svojih ciljeva; ali se i dalje vide do današnjeg dana.

Prednosti

• Pruža spisak zahteva.
• Obezbeđuje ugovor između nosioca projekta i programera.
• Za veliki sistem može da obezbedi opis visokog nivoa od kojih uslovi na nižem nivou se mogu izvesti.

Slabosti

• Takve liste mogu pokrenuti na stotine stranica. Oni nisu namenjeni da služe kao čitaoci pijateljskih opisa željene aplikacije.
• Takvi zahtevi lista apstraktuju sve zahteve i tako da je malo konteksta. Poslovni analitičar može uključivati kontekst za zahteve u prateće projektne dokumentacije.
  • Ovaj sažetak nije namenjen da opiše kako su zahtevi sposobni ili da rade zajedno.
  • Lista možda ne odražava odnose i zavisnosti između zahteva. Dok se lista ne olakšava prioritet svake pojedinačne stavke, uklanjanje jednu stavku iz konteksta može da pruži čitav slučaj korišćenja ili poslovni zahtev beskoristan.
  • Lista ne zadovoljava potrebu da razmotri zahteve pažljivo sa zainteresovanim stranama kako bi stekli bolje zajedničko razumevanje implikacije za projektovanje željenog sistema / aplikacije.
• Jednostavno kreiranje liste ne garantuje njenu celovitost. Poslovni analitičar mora napraviti napore da otkriju i prikupe znatno sveobuhvatan popis, i oslanjaju se na zainteresovanim stranama da istaknu nedostajuće zahteve.
• Ove liste mogu stvoriti lažni osećaj međusobnog razumevanja između zainteresovanih strana i programera; Poslovni analitičari su od ključnog značaja za proces prevođenja.
• To je gotovo nemoguće da otkrije sve funkcionalne zahteve pred početak procesa razvoja i testiranja. Ako se ovi spiskovi tretiraju kao nepromenljivi ugovori, onda zahtevi koji nastaju u procesu razvoja mogu generisati kontroverznu promenu zahteva.

Alternativa liste zahteva

Kao alternativa liste zahteva, Agilni razvoj softvera koristi korisničke priče da predloži zahteve u svakodnevnom jeziku.

Merljivi ciljevi

Najbolje prakse uzeti sastavljenu listu zahteva samo kao tragove i više puta pitati "zašto?" do stvarne poslovne svrhe su otkrivene. Zainteresovane strane i programeri mogu onda smisliti testove za merenje  nivoa svakog cilja koji je postignut do sada. Takvi ciljevi menjaju mnogo sporije nego duge liste konkretnih ali nemerenih zahteva. Kada je osnovan mali skup kritičkih, izmerenih ciljeva, brza izrada prototipova i kratke iterativne faze razvoja može da nastavi da isporuči stvarnu vrednost zainteresovanih mnogo pre nego što je projekat pola gotovo.

Prototipovi

Prototip je računarski program koji pokazuje deo imovine drugog računarskog programa, omogućavajući korisnicima da vizualizuju aplikaciju koja još nije konstruisana. Popularan oblik prototipa je maket, koji pomaže budućim korisnicima i drugim akterim da bi dobili ideju o tome kako će sistem izgledati. Prototipovi olakšavaju da se napravi dizajn odluke, jer aspekti primene mogu da se vide i dele pre nego što je aplikacija izgrađena. Značajna poboljšanja u komunikaciji između korisnika i programera se često posmatraju sa uvođenjem prototipa. Rani pregledi aplikacija doveli su do manje promene kasnije i samim tim se značajno smanjuju ukupni troškovi.

Prototipovi mogu biti ravni dijagrami (često se nazivaju žičani okviri) ili radne aplikacije koristeći sintetizovanu funkcionalnost. Žičani okviri se prave u različitim grafičkim projektnim dokumentacijama, a često i uklanjaju sve boje sa dizajna (tj koristiti u sivim tonovima paletu boja) u slučajevima gde se očekuje konačan softver da ima grafički dizajn primenjen na njega. To pomaže da se spreči konfuzija da li prototip predstavlja konačan vizuelni izgled i osećaj aplikacije.

Slučajevi upotrebe

Upotreba slučaja je struktura za dokumentovanje funkcionalnih zahteva za sistem, obično uključuje softver, da li je novi ili se menja. Svaki slučaj upotrebe obezbeđuje niz scenarija koji prenose kako sistem treba da komunicira sa ljudskim korisnikom ili nekim drugim sistemom, da bi se postigao konkretan poslovni cilj. Slučajevi upotrebe obično izbegavaju tehnički žargon, umesto toga jezika krajnjeg korisnika ili domena stručnjaka. Slučajevi upotrebe su često koautori sa zahtevima inženjera i zainteresovanih strana.

Slučajevi upotrebe su varljivo jednostavni alati za opisivanje ponašanja softvera ili sistema. Slučajevi upotrebe sadrže tekstualni opis načina na koji su korisnici namenjeni za rad sa softverom ili sistemom. Slučajevi upotrebe ne bi trebalo da opišu unutrašnje funkcionisanje sistema, niti treba da objasne kako će taj sistem biti implementiran. Umesto toga, oni pokazuju korake potrebne za obavljanje zadatka.

Specifikacija zahteva

Izlaz procesa analize zahteva je specifikacija zahteva.

Tipovi zahteva

Zahtevi su kategorisani na nekoliko načina. Slede uobičajene kategorizacije uslova koji se odnose na tehnička upravljanja:

Zahtevi kupaca

Izjave činjenice i pretpostavke koje definišu očekivanja sistema u pogledu ciljeva misije, životne sredine, ograničenja i mere efikasnosti i podobnosti (MOE / Mos). Potrošači su oni koji obavljaju osam primarnih funkcija sistema inženjeringa, sa posebnim naglaskom na operatora kao ključnog kupca. Operativni uslovi će definisati osnovnu potrebu i, u najmanju ruku, odgovoriti na pitanja koja su u sledećem popisu:

• Operativna distribucija i razmeštanje: Gde će sistem se koristi?

• Profil misije ili scenarija: Kako će sistem ostvariti svoj cilj misije?

• Perfomanse i vezani parametri: Koji su kritični parametri sistema za postizanje cilja?

• Korišćenje sredine: Kako se različite komponente sistema koriste?
• Zahtevi efikasnosti: Kako efikasnije i ekonomičnije mora sistem biti u obavljanju svoje misije?

• Operativni životni ciklus: Koliko dugo će sistem biti u upotrebi od strane korisnika?

• Životna sredina: Kako se od sredine očekuje da će sistem da radi na efikasan način?

Arhitektonski zahtevi 

Arhitektonski zahtevi objašnjavaju šta treba da se uradi za identifikaciju potrebnih sistema za arhitekturu sistema.

Strukturni zahtevi

Strukturni uslovi objašnjavaju šta treba da se uradi za identifikaciju neophodne strukture sistema

Ponašanje zahteva

Ponašanje zahteva objašnjava šta treba da se uradi kroz identifikaciju potrebnu za ponašanje sistema.

Funkcionalni zahtevi

Funkcionalni zahtevi objašnjavaju šta treba da se uradi kroz identifikaciju potrebnih zadataka, akciju ili aktivnost koja mora biti postignuta. Funkcionalna analiza zahteva će se koristiti kao vrhunska funkcija nivoa za funkcionalne analize.

Nefunkcionalni zahtevi

Nefunkcionalni zahtevi su zahtevi koji određuju kriterijume koji se mogu koristiti da se sudi rad sistema, umesto konkretnih ponašanja.

Osnovna funkcionalnost i pomoćni zahtevi funkcionalnosti

Murali Chemuturi definisao je uslove u osnovnoj funkcionalnosti i pomoćnim zahtevima funkcionalnosti. Osnovni zahtevi Funkcionalnosti su oni bez ispunjavanja kojima proizvod ne može biti od koristi uopšte. Pomoćni zahtevi funkcionalnosti su oni koji podržavaju osnovne funkcionalnosti. Proizvod može nastaviti da radi čak i ako su ispunjeni neki ili svi prateći zahtevi funkcionalnosti, ali sa nekim sporednim efektima. Bezbednost, sigurnost, lakoća i tako dalje su primeri pomoćnih uslova Funkcionalnostit

Performanse zahteva

Obim u kojem misija ili funkcija mora biti pogubljena; uglavnom se meri u pogledu kvantiteta, kvaliteta, pokrivenosti, rokova ili spremnosti. Tokom analize zahteva, performanse (kako dobro to treba da se uradi) zahtevi će se interaktivno razvijati u svim identifikovanim funkcijama na osnovu sistema životnog ciklusa faktora; i karakteriše se u smislu stepena sigurnosti u njihovoj proceni, stepen kritičnosti prema uspehu sistema, i njihov odnos prema drugim zahtevima. 

Dizajn zahtevi

Zahtevi koji se podrazumevaju ili transformišu iz zahteva višeg nivoa. Na primer, zahtev  dugog dometa ili velike brzine može dovesti do zahteva za dizajn male težine.

Izdvojeni zahtevi

Uslov da se uspostavi deljenjem ili na drugi način dodelom uslova na visokom nivou u više zahteva nižeg nivoa. Primer: predmet 100-funti koji se sastoji od dva podsistema može da dovede do težine zahtevima 70 funti i 30 funti za dve stavke nižeg nivoa.

Dobro poznati zahtevi modela za kategorizaciju uključuju FURPS i FURPS+, razvijeni u Hjulet-Pakard-u.

Pitanja zahteva analize

Pitanja interesnih grupa

Stiv Mekonel, u svojoj knjizi Brzi razvoj, detalje o nekoliko načina korisnici mogu da inhibiraju prikupljanjem zahteva:

• Korisnici ne razumeju šta oni žele ili korisnici nemaju jasnu predstavu o njihovim zahtevima
• Korisnici se neće obavezati na skup pisanih zahteva
• Korisnici insistiraju na novim zahtevima nakon što su fiksni troškovi i raspored 
• Komunikacija sa korisnicima je spora
• Korisnici često ne učestvuju u kritikama ili su nesposobni da rade tako
• Korisnici su tehnički sofisticirani
• Korisnici ne razumeju proces razvoja
• Korisnici ne znaju o ovoj tehnologiji

To može da dovede do situacije u kojoj se zahtevi korisnika menjaju, čak i kada sistem ili razvoj proizvoda je startovan. Takođe znači da je uslov pod dejstvom procesa.

Inženjerska/programerska pitanja

Mogući problemi izazvani od strane inženjera i programera u toku analize zahteva su:

• Prirodna sklonost ka pisanju koda može da dovede do realizacije na početku pre nego što se analiza zahteva završi, potencijalno dovodi do pravljenja neelegantnog zadovoljavanja stvarnih potreba nakon što su poznati.
• Tehničko osoblje i krajnji korisnici mogu imati različite rečnike. Shodno tome, oni pogrešno veruju da su u savršenom sporazumu dok se gotov proizvod isporučuje.
• Inženjeri i programeri će možda pre pokušati da naprave zahteve za postojeći sistem ili model, nego razviti sistem specifičan za potrebe klijenta.
• Analiza često može biti sprovedena od strane inženjera ili programera, nego osoblja sa znanjem domena da pravilno razume potrebe klijenta. 

Pokušaj rešenja

Jedan pokušaj rešenja za komunikacione probleme je da se zaposle stručnjci u poslovnom ili sistemu analize.

Tehnike uvedene u 1990 kao izrada prototipova, Unified Modeling Language (UML), koristi slučajeve, i agilni razvoj softvera je takođe namenjen kao rešenje problema sa prethodnim metodama.

Takođe, nova klasa simulacije aplikacija ili definicije primena alata je ušli na tržište. Ovi alati su dizajnirani da premoste jaz komunikacije između poslovnih korisnika i IT organizacije - kao i da omogući aplikacijama da budu 'test na tržištu "pre nego što se proizvede kod. Najbolji od ovih alata nude: 

• elektronske bele table za skiciranje aplikacija tokova i test alternative
• sposobnost da se uhvati poslovna logika i  potrebni podaci
• sposobnost za generisanje prototipova visoke vernosti da blisko oponaša konačnu prijavu
• interaktivnost
• sposobnost da dodaju kontekstualne zahteve i druge komentare
• sposobnost za udaljene i distribuirane korisnike da rade i interaguju sa simulacijom

Vidi još

• Softverski dizajn
• Debagovanje
• Softversko raspoređivanje
• Održavanje softvera
• Konstrukcija softvera
• Testiranje softvera
• Razvojni ciklus softvera
• Softversko inženjerstvo

Literatura

• Berenbach, Brian; Paulish, Daniel; Katzmeier, Juergen; Rudorfer, Arnold (2009). Software & Systems Requirements Engineering: In Practice. New York: McGraw-Hill Professional. ISBN 978-0-07-160547-2. 
• Hay, David C. (2003). Requirements Analysis: From Business Views to Architecture (1st izd.). Upper Saddle River, NJ: Prentice Hall. ISBN 978-0-13-028228-6. 
• Laplante, Phil (2009). Requirements Engineering for Software and Systems (1st izd.). Redmond, WA: CRC Press. ISBN 978-1-4200-6467-4. Arhivirano iz originala 22. 10. 2014. g. Pristupljeno 20. 1. 2016. 
• McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules (1st izd.). Redmond, WA: Microsoft Press. ISBN 978-1-55615-900-8. 
• Nuseibeh, B.; Easterbrook, S. (2000). Requirements engineering: a roadmap (PDF). Proceedings of the conference on the future of Software engineering; conference: ICSE'00. ISBN 978-1-58113-253-3. doi:10.1145/336512.336523. CiteSeerX: 10.1.1.131.3116. 
• Stellman, Andrew & Greene, Jennifer (2005). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 978-0-596-00948-9. 
• Wiegers, Karl & Beatty, Joy (2013). Software Requirements (3rd izd.). Redmond, WA: Microsoft Press. ISBN 978-0-7356-7966-5. 

Spoljašnje veze

• Recenzirana Encyclopedia Entry on Requirements Engineering and Analysis
• Defense Acquisition University Stakeholder Requirements Definition Process
• MIL-HDBK 520 Systems Requirements Document Guidance