PRISTUP IZRADI SPECIFIKACIJE ZAHTEVA U PROCESU NABAVKE SOFTVERSKOG SISTEMA APPROACH TO CONSTRUCT REQUIREMENTS SPECIFICATION IN PROCESS OF PROCUREMENT OF SOFTWARE SYSTEM Milosav Majstorović, Visoka škola strukovnih studija za informacione tehnologije, milosav.majstorovic@its.edu.rs Rajko Terzić, Gradski zavod za javno zdravlje, rajkot@sbb.rs Apstrakt: Specifikacija zahteva koji se postavljaju u procesu nabavke softverskog sistema najčešće je neformalna. Posledice ovakve specifikacije mogu biti teške u fazi uvođenja, kao i eksploatacije softverskog rešenja. U velikom broju slučajeva, ovakav pristup može dovesti i do potpunog neuspeha IT projekta. Prvi cilj ovog rada je razjašnjavanje terminologije vezane za modele, najčešće korišćene u specifikaciji zahteva u kontekstu softverskih sistema, kako bi se doprinelo što konzistentnijem korišćenju modela i drugih artifakta. Drugi cilj je definisanje metodoloških koraka za izradu detaljne specifikacije zahteva u procesu nabavke softverskog sistema. Ključne reči: specifikacija zahteva, softverski sistem, model softverskih zahteva, IT projekat. Abstract: Specification of requirements, which are setup in the process of purchase of software system, is often informal. The consequences of such specifications can be severe in the introduction stage, as well as the exploitation of software solutions. In many cases, this approach can lead to complete failure of the IT project. The first objective of this paper is to clarify the terminology related to the models commonly used in the specification requirement in the context of software systems, in order to contribute to a more consistent use of models and other artifacts. The second objective is to define methodological steps for the development of the detailed specifications required in the process of procurement software system. Keywords: requirements specification, software system, model of software requirements, IT project. 1. UVOD Rezultat specifikacije zahteva (SZ) koji se postavljaju u procesu nabavke softverskog sistema treba da bude dokument (dokumenti) koji će omogućiti adekvatan izbor, nabavku i implementaciju budućih softverskih rešenja. Da bi zadovoljio ovu ulogu, dokument treba da da detaljnu i preciznu specifikaciji potreba (funkcionalnih i tehničkih zahteva). Korisnici, konsultanti i implementatori koriste rezultate SZ u procesu nabavke softverskog rešenja, njegove konfiguracije, adaptacije, kao i kasnijeg održavanja. Zbog toga, zahtevi koji se postavljaju pred novi sistem moraju biti tako dokumentovani, da budu korisni ne samo korisnicima sistema i njihovim konsultantima, već i tehničkom osoblju tima koji uvodi i održava sistem. Dakle, SZ treba nedvosmisleno da opiše šta sistem treba da radi, i da se svi učesnici u procesu, slože oko toga. Da bi se ovo postiglo, treba otkriti, organizovati i dokumentovati zahtevane funkcionalnosti i ograničenja. U toku izrade SZ, njegovi artifakti, pre svega modeli specifikacije zahteva, mogu evaluirati u različitim pravcima. Na primer, neki artifakti (kao što je rečnik termina, npr.) se jednostavno unapređuju, tj. dopunjuju, dok drugi (funkcionalni zahtevi, model objekata, itd.), u različitim fazama procesa apstrahuju različite aspekte sistema i zadovoljavaju različite potrebe. Zato, prvi zahtevaju održavanje samo najsvežije verzije, dok drugi mogu zahtevati održavanje različitih verzija (npr. poslovni funkcionalni zahtevi, domenski funkcionalni zahtevi, itd.). Ovo je pre svega evidentno u kontekstu složenih sistema [1]. U sledećem poglavlju se prvo razmatraju definicije softverskih zahteva a zatim je prikazan model softverskih zahteva na kojem je ovaj rad zasnovan. U poglavlju 3 je definisan proces izrade specifikacije zahteva, a sledećim poglavljima su ilustrovani modeli koji predstavljaju softverske zahteve, kao i faze kroz koje se oni kreiraju. Kao primer za ilustraciju je poslužio poslovni proces poručivanje kupca fiktivne proizvodne kompanije. 2. MODELI ZA SPECIFIKACIJU ZAHTEVA Softverski sistemi se implementiraju kako bi se zadovoljile potrebe korisnika. Loša analiza i specifikacija zahteva je još uvek glavni razlog neuspeha velikog broja IT projekata. Put za rešenje ovog problema je specifikacija sistema u skladu s poslovnim procesima koje treba da podrži, i u
kontekstu njegove upotrebe, tj. zasnivanje metodologije prikupljanja i dokumentovanja funkcionalnih zahteva na slučajevima upotrebe (Engl. Use case methodology). Važan preduslov uspeha projekta specifikacije zahteva je jasno određenje pojma i strukture zahteva koji se postavljaju pred softverski sistem (softverski zahtevi). Formalna definicija softverskih zahteva predložena je u IBM-ovom jedinstvenom procesu razvoja softvera (IBM Rational Unified Process - RUP) kao [2]: "Zahtev opisuje uslov kojem se sistem mora povinovati, ili funkcionalnost koju mora biti u stanju da izvrši; bilo da je izveden direktno iz potreba korisnika, ili definisan u ugovoru, standardu, specifikaciji, ili drugom formalnom dokumentu." Kompatibilna, ali opsežnija definicija je data od strane IEEE [3], gde se softverski zahtev definiše kao: Softverska funkcionalnost potrebna korisniku da bi rešio neki problem ili postigao određeni cilj; Softverska funkcionalnost koja se mora ispuniti, ili koju sistem, ili sistemska komponenta poseduje, kako bi bio zadovoljen ugovor, standard, specifikacija, ili drugi formalni dokument; Skup svih softverskih zahteva koji formiraju osnovu za kasniji razvoj softvera ili softverske komponente; Tako, softverski zahtev je zajednički termin za sledeće tipove zahteva: funkcionalni zahtevi, zahtevi vezani za performanse, zahtevi vezani za spoljni interfejs, projektna ograničenja, kao i određeni kvalitativni atributi. Ponekad se svi zahtevi van funkcionalnih zahteva nazivaju i nefunkcionalni zahtevi. U ovom radu se pošlo od modela softverskih zahteva datih u [1]. Ovaj model je dograđen procesnom dimenzijom, uključenjem BPMN (Business Process Model and Notation - [4]) dijagrama u specifikaciju funkcionalnih zahteva, i definisanjem procesa izrade funkcionalne i tehničke specifikacije sistema. Na slici 1. su prikazane glavne komponente modela softverskih zahteva, uključujući njihove međuzavisnosti. Globalni model softverskih zahteva (predstavljen najvećim paketom) sadrži druge artifakte koji su modelovani kao manji paketi. Komponente modela softverskih zahteva su na slici predstavljene kao graf manjih paketa povezanih vezama zavisnosti. Slika 1. Model softverskih zahteva glavne komponente
Centralni deo modela zahteva je model funkcionalnih zahteva koji opisuje željeno ponašanje sistema. On opisuje jasno i detaljno svaki servis koji programski sistem treba da obezbedi. Osnovni dijagrami kojima se u ovoj komponenti opisuje ponašanje su BPMN dijagrami (kojima se definiše model poslovnih procesa koji programski sistem treba da podrži) i dijagram slučajeva korišćenja (kojima se daje prikaz funkcija sistema, tj. slučajeva korišćenja sistema, kao i aktera/učesnika koji te funkcionalnosti koriste). U fazi prikupljanja i analize funkcionalnih zahteva u tradicionalnom pristupu dominantno se koriste modeli slučajeva korišćenja [5]. U [6] se naglašava da model poslovnih procesa identifikuje aktivnosti, resurse i podatke uključene u kreiranje proizvoda ili servisa, pa tako obezbeđuje vrlo korisne informacije za razvoj programskog sistema koji ga podržava, i da se u fazi analize sistema većina ovih informacija treba inkorporirati u opise slučajeva korišćenja. Imajući ovaj motiv u vidu, u [6] se predlaže pristup za podršku konstrukciji modela slučajeva korišćenja zasnovanom na modelu poslovnih procesa. Koristeći ovaj pristup, moguće je dobiti kompletan model slučaja korišćenja, uključujući učesnike, slučaj korišćenja i odgovarajuće opise (kao skup predefinisanih rečenica u prirodnom jeziku), iz elemenata BPMN dijagrama. Na slici 1. komponente čiji modeli se mogu izraziti sa UML su predstavljeni svetlo (moguće ih je predstaviti relativno formalno). Sive komponente se mogu samo delimično predstaviti korišćenjem UML-a. Za njihov opis mogu se koristiti dokumenti zasnovani na prirodnom jeziku, u tekstualnom, tabelarnom ili grafičkom obliku. Nefunkcionalni zahtevi tipično specificiraju svojstva sistema kao celine. Ova kategorija zahteva uključuje aspekte kao što su performanse, sigurnosna pravila, raspoloživost sistema, strategija čuvanja i restauracije kopija podataka i programa, itd. ([2]). Rečnik i model objekata definiše poslovni rečnik za dati domen. Rečnik se izražava u prirodnom jeziku, a model objekata se modeluje pomoću UML dijagrama klasa. Saglasno [5] model domena obuhvata najvažnije tipove objekata u kontekstu sistema. Domenski objekti su entiteti ("stvari") koji postoje, ili događaji koji se javljaju u toku rada sistema. Zbog toga, domenske klase se pojavljuju u tri tipična oblika: poslovni objekti koji reprezentuju fenomene kojima se manipuliše u poslovanju, kao što su narudžbenica, račun, ugovor, itd.; objekti i koncepti realnog sveta o kojima sistem treba da vodi računa kao što su radnik, organizaciona jedinica, itd.; događaji koji su se dogodili, ili će se dogoditi, kao što su pojava narudžbenice, pojava uplate na izvodu, itd. Model interfejsa sistema i GUI model (model grafičkog korisničkog interfejsa) opisuje interfejs koji sistem koristi u interakciji sa njegovim korisnicima (učesnicima). Korisnik može biti drugi sistem ili čovek. U fazi analize i specifikacije zahteva, interfejsi apstrahuju samo informacije koje se tiču poslovnih potreba i zbog toga zanemaruju implementacione detalje. Poslovna pravila su jedan od uobičajenih mehanizama za predstavljanje znanja o određenom poslovnom domenu. To znanje se predstavlja kao izjava koja definiše ili ograničava neki aspekt poslovanja. Tradicionalno, cilj poslovnih pravila je da budu dovoljno precizna i laka za korišćenje od strane profesionalnih softverskih inženjera, a razumljiva za sve ostale učesnike uključene u modelovanje koncepata poslovnog domena [7]. 3. PROCES IZRADE SPECIFIKACIJE ZAHTEVA Proces izrade specifikacije zahteva okvirno je prikazan BPMN dijagramom na slici 2. Rezultati ovog procesa treba da budu komponente opisane napred (slika 1.). Rezultati aktivnosti procesa (koje u stvari, u zavisnosti od veličine i složenosti problema, mogu predstavljati čitave faze) su na slici prikazani kao anotacije (napomene) uz odgovarajuću aktivnost. U nastavku će ovaj proces biti ilustrovan kroz primer procesiranja ulazne narudžbenice proizvodne kompanije. Prva aktivnost u procesu izrade specifikacije zahteva je inicijalna analiza poslovnog sistema, odnosno njegovog dela koji je predmet konkretne specifikacije. Ova aktivnost (faza) je kritični deo procesa jer treba razumeti dotičan poslovni problem, tj. poslovni proces, koji je najčešće na početku slabo definisan, a korisnik ga teško može precizno izraziti.
Slika 2. Dijagram procesa izrade specifikacije zahteva 4. SPECIFIKACIJA MODELA POSLOVNIH PROCESA Specifikacija softverskih zahteva i modela često nije u saglasnosti sa poslovnim procesima koje sistem treba da podrži, odnosno pomoću kojeg poslovni procesi treba da se realizuju. Zato, zasnivanje pribavljanja i analize korisničkih zahteva na modelima poslovnih procesa, može osigurati poravnanje poslovnih procesa i softverskih modela. Zbog toga, modelovanje poslovnih procesa prirodno spada u početne faze razvoja softvera kao što su analiza sistema i specifikacija zahteva. Na osnovu rezultata inicijalne analize poslovnog sistema, čiji segmenti su prikazani napred, moguće je definisati prvu verziju modela poslovnog procesa. Na ovaj način razvijen je model za proces Poručivanje kupca, čiji BPMN dijagram je prikazan na slici 3. Model preciznije (u odnosu na neformalne artifakte date u prvoj analizi sistema) definiše odvijanje procesa kroz eksplicitno izražavanje redosleda i uslova pod kojim se izvršavaju aktivnosti procesa. Model takođe prikazuje razmenu poruka između učesnika u procesu, kao i tok i promene statusa dokumenta Narudžbenica od njegovog kreiranja u sistemu, pa do prihvatanja (ili odbijanja). Prihvaćen dokument je osnov za iniciranje aktivnosti (pokretanje novog procesa) za njegovu realizaciju. Slika 3. Dijagram procesa Poručivanje kupca
5. IDENTIFIKACIJA I DOKUMENTOVANJE FUNKCIONALNIH ZAHTEVA U cilju identifikacije funkcionalnih zahteva, u kontekstu napred specificiranih procesa, treba dati odgovore na pitanja vezana za aspekt funkcionalnosti i aspekt podataka. U procesu pribavljanja funkcionalnih zahteva od svih relevantnih učesnika moguće je da se pojave različite, u nekom stepenu konfliktne ideje, koje treba razrešiti. Mogući način razrešenja konfliktnih i konkurentnih zahteva je dodela prioriteta zahtevima. Ovaj način zahteva od korisnika da definiše koje zahtevane funkcionalnosti su najvažnije. Manje strog pristup prioritetima može podeliti zahteve u tri kategorije: 1. Zahtevi obavezno moraju biti ispunjeni (Esencijalni) 2. Zahtevi su veoma poželjni, ali nisu obavezni (Poželjni) 3. Zahtevi su mogući, ali nisu obavezni (Opcionalni) Primer dokumentovanja funkcionalnih zahteva je dat u tabeli 1. Oznaka funkcionalnog zahteva se formira po šablonu: FR funkcionalni zahtev (Engl. Functional Requirement), oznaka procesa (u primeru PK Poručivanje kupca), redni broj zahteva). Oznaka Opis zahteva Prioritet funk. zah. FR_PK_1 Evidencija narudžbenice kupca sa standardnim podacima. E FR_PK_2 Mogućnost da korisnik, po potrebi, definiše proširen skup podataka u toku evidencije P narudžbenice. FR_PK_3 Mogućnost elektronskog preuzimanja narudžbenice kupca u sistem. O FR_PK_4 Pri unosu kupca u početku evidencije narudžbenice, sistem definiše templejt prilagođen P dotičnom korisniku, koji uključuje najčešće naručivane stavke dotičnog kupca. FR_PK_5 Automatska provera stanja zaliha u kontekstu procesirane narudžbenice. E FR_PK_6 Pregled narudžbenica po željenim kriterijumima (kupac, status, količina,...) E Tabela 1. Primer funkcionalnih zahteva za proces Poručivanje kupca 6. IDENTIFIKACIJA I DOKUMENTOVANJE POSLOVNIH PRAVILA U toku prikupljanja zahteva i njihove analize u kontekstu procesa Poručivanje kupca, identifikovana su poslovna pravila koja su data u tabeli 2. Oznaka pravila se formira po šablonu: R pravilo (Engl. Rule), oznaka procesa (u primeru PK Poručivanje kupca), redni broj pravila). Oznaka pravila R_PK_1 R_PK_2 R_PK_3 R_PK_4 R_PK_5 Opis pravila Ako kupac naručuje više proizvoda nego što je raspoloživo na zalihama, izdaje se odgovarajući nalog za proizvodnju. U obaveštenju kupcu, koje se šalje na kraju procesa prihvatanja narudžbenice, o ovome se daju adekvatne informacije. Ako je moguća realizacija narudžbenice, vrši se provera rejtinga i kreditne sposobnosti kupca. Ako je kreditni rejting loš, narudžbenica mora biti odobrena od strane rukovodioca prodaje. Ako se narudžbenica odbije od strane rukovodioca prodaje, u obaveštenju kupcu, koje se šalje na kraju procesa prihvatanja narudžbenice, o ovome se daju adekvatne informacije. Na osnovu rejtinga kupca, u slučaju prihvaćanja, narudžbenici se dodeljuje odgovarajući prioritet koji utiče na brzinu i način njene realizacije. Tabela 2. Primer poslovnih pravila za proces Poručivanje kupca KREIRANJE MODELA POSLOVNIH OBJEKATA (KONCEPTUALNOG MODELA) U procesu prikupljanja zahteva njihove analiza identifikuju se i osnovni poslovni objekti (kao i veze između njih) koji učestvuju u određenom poslovnom procesu. Naravno, neki poslovni objekti se mogu pojavljivati u više poslovnih procesa. U ovim slučajevima treba definisati koji proces je primarni za dati poslovni objekat. Na slici 4. je prikazan konceptualni dijagram klasa sa poslovnim objektima procesa Poručivanje kupca.
Slika 3. Konceptualni dijagram klasa sa poslovnim objektima procesa Poručivanje kupca ZAKLJUČAK Posledice neformalne specifikacije zahteva u procesu nabavke softverskih sistema često uzrokuju potpuni neuspeh IT projekata. U radu je učinjen napor prema formalnijoj specifikaciji zahteva koji se postavljaju pred softverski sistem. Definisan je model softverskih zahteva koji omogućuje konzistentnije korišćenje različitih artifakta koji se koriste i kreiraju u procesu nabavke i uvođenja softverskog sistema. Modelu je data procesna dimenzija kroz definisanje procesa izrade specifikacije zahteva predstavljenog kroz BPMN dijagram. Ovim je definisan metodološki postupak za izradu detaljne specifikacije zahteva (projektnog zadatka) u procesu nabavke softverskog sistema. U budućem radu se planira dalja razrada i formalizacija metodoloških koraka, kao i korišćenje CASE alata u cilju praktične primene izloženog pristupa. REFERENCE [1] Johnson R., Roussos G., Tagliati L.V., Requirements analysis for large scale systems, Journal of Object Technology, November-December 2008.Vol. 7, No. 8, pp 119-137. [2] Rational Unified Process for Systems Engineering, A Rational Software White Paper, Rational Software Corporation, 2002. [3] Systems and software engineering - Life cycle processes - Requirements engineering, ISO/IEC/IEEE 29148, 2011. [4] OMG 2011, "Business Process Model and Notation (BPMN)", Version 2.0, January 2011. [Online]. Raspoloživo na: http://www.omg.org/spec/bpmn/2.0 (Pristupano 05.04.2017.) [5] Jacobson I., Booch B., Jim Rumbaugh J., Unified Software Development Process, Addison-Wesley, 1999. [6] Estrela F. C., Ricardo J. M., Maribel Y. S., From Business Process Models to Use Case Models: A systematic approach, Advances in Enterprise Engineering VIII, Volume 174 of the series Lecture Notes in Business Information Processing, pp 167-181, 2014. [7] Hay D., Healy K. A., Defining business rules what are they really? The Business Rules Group, Tech. Rep., 2000. [Online]. Raspoloživo na : http://www.businessrulesgroup.org/first_paper/brgwhatisbr_3ed.pdf (Pristupano 10.04.2017.)