Programinės įrangos kūrimo reikalavimus formuluoja ir jais vadovaujasi visi projekto dalyviai (aukšto lygio vadovai bei marketingo skyrius, vartotojai, programuotojai, analitikai), kurių poreikiai ir patirtis dažnai yra labai skirtingi. Daugelis programinės įrangos kūrimo ir reikalavimų valdymo metodikų šios problemos sprendimui siūlo apibrėžti reikalavimų abstrakcijos lygius ir sąsajas tarp skirtingų lygių reikalavimų.
Programinės įrangos kūrimo reikalavimus formuluoja ir jais vadovaujasi visi projekto dalyviai, kurių poreikiai ir patirtis dažnai yra labai skirtingi.
- Aukšto lygio vadovams bei marketingo skyriui aktuali verslo vizija, vartojimo ir pardavimo koncepcija.
- Programinės įrangos vartotojams yra svarbios sistemos panaudojimo galimybės.
- Programuotojas, užrašantis reikalavimus programos kode, pagrįstai nori išsamaus visų sistemos galimybių ir apribojimų aprašymo.
- Analitikams tenka sunkus uždavinys parengti programinės įrangos reikalavimų dokumentą, kuris tenkintų visus šiuos poreikius ir tuo pačiu išliktų patogus skaityti.
Daugelis programinės įrangos kūrimo ir reikalavimų valdymo metodikų šios problemos sprendimui siūlo apibrėžti reikalavimų abstrakcijos lygius ir sąsajas tarp skirtingų lygių reikalavimų.
Programinės įrangos reikalavimų valdymui BPĮ specialistai dažniausiai taiko RUP (Rational Unified Process) reikalavimų lygių apibrėžimą. RUP apibrėžia tris reikalavimų abstrakcijos lygius:
- verslo reikalavimai;
- vartotojo reikalavimai;
- programinės įrangos reikalavimai.
Visi šie reikalavimai yra aprašomi specialiame dokumente, kurio ruošinį galima rasti RUP metodikos ruošinių sąraše.
RUP metodikoje apibrėžiami reikalavimų abstrakcijos lygiai ir dokumentai jiems aprašyti pateikiami 1 paveiksle.
Pav. 1. RUP metodikoje apibrėžiami reikalavimų abstrakcijos lygiai ir dokumentai.
Pagrindinis reikalavimas ir pagrindinė sėkmės sąlyga, aprašant reikalavimus pagal RUP procesą, yra tęstinumo užtikrinimas. Aukštesnio abstrakcijos lygio reikalavimai turi būti pilnai paruošti, prieš pradedant ruošti žemesnio abstrakcijos lygio reikalavimus. Toks reikalavimų suskirstymas į lygius ne tik palengvina analitikų darbą, bet ir suteikia galimybę koordinuoti bei paskirstyti reikalavimų analizės darbus tarp projekto užsakovo ir vykdytojo. Projektuose pagal užsakymą verslo reikalavimus paprastai apibrėžia užsakovas, o vartotojo bei programinės įrangos reikalavimus paruošia vykdytojo sistemų analitikai. Be to užsakovo ir vykdytojo susitarimu galimas ir kitoks darbų pasiskirstymas.
Šis reikalavimų aprašymo metodas yra taikomas vienam iš nuolatinių BPĮ užsakovų, kuriant paslaugų užsakymo informacinę sistemą. Pagal susitarimą užsakovo IT skyriaus sistemų analitikai bendradarbiaudami su vartotojais ir verslo analitikais parengia vartotojo reikalavimus ir pateikia BPĮ atsakingiems darbuotojams. BPĮ sistemų analitikai detalizuoja ir parengia programinės įrangos reikalavimus. Taigi, šiame taikomame procese užsakovas yra atsakingas už pirmų dviejų lygių – verslo reikalavimų ir vartotojo reikalavimų – parengimą, o BPĮ, kaip vykdytojas, yra atsakingas už žemiausio lygio – programinės įrangos reikalavimų – parengimą (žr. 2 pav.).
Pav. 2. Atsakomybių atskyrimas.
Sėkmingam skirtingų abstrakcijos lygių reikalavimų aprašymo metodikos taikymui reikia ne tik parengti visų abstrakcijos lygio reikalavimus, bet ir išlaikyti reikalavimų rengimo tvarką nuo abstrakčiausių iki labai konkrečių.
Pavyzdys iš BPĮ praktikos:
| Viename iš projektų programinės įrangos reikalavimų paruošimui buvo suplanuotos 4 savaitės. Laikas buvo viršytas dvigubai, tačiau galutinis reikalavimų dokumentas taip ir nebuvo paruoštas. Kiekvieną kartą pristačius preliminarią programinės įrangos reikalavimų dokumento versiją klientui ir būsimiems sistemos vartotojams būdavo iš naujo aptariamas sistemos funkcijų reikalingumas bei patogumas ir keičiami prieš tai pateikti vartojo reikalavimai. Išanalizavę vartotojo reikalavimų kitimo tendencijas ir įvertinę, kad pokyčių apimtis nemažėja, mes kreipėmės į klientą ir pasiūlėme sustabdyti darbą bei atlikti problemos analizę. Mūsų iniciatyva buvo organizuotas susitikimas su kliento verslo analitikais, apibrėžusiais verslo reikalavimus šiai paslaugai ir galutiniais paslaugų užsakymo sistemos vartotojais. Aptarimo metu paaiškėjo, kad marketingo skyriaus patvirtintas ir verslo analitikų aprašytas paslaugos pardavimo verslo procesas nesutampa su tuo kaip paslauga yra realiai parduodama. Todėl yra formuojamas paslaugos pardavimo verslo procesas, o paslaugos pardavimo strategija yra keičiama ir pritaikoma prie rinkos poreikių. Tokiomis sąlygomis neįmanoma parengti pastovių verslo reikalavimų sistemai ir tuo pačiu yra neracionalu rengti žemesnio abstrakcijos lygio reikalavimus. Susitarus su klientu paslaugos įdiegimo į sistemą data buvo nukelta į kitą projekto fazę. |
|---|
Trumpai supažindinome su skirtingo lygio reikalavimų ruošimo poreikiu ir pristatėme tai iliustruojantį pavyzdį iš mūsų praktikos. Matome, kad skirtingų lygių reikalavimai ne tik geriau tenkina skirtingų projekte dalyvaujančių asmenų poreikius, bet ir palengvina reikalavimų ruošimo darbą ir leidžia jį paskirstyti tarp užsakovo ir vykdytojo. Tuo pačiu toks reikalavimų aprašymas įpareigoja nuosekliai detalizuoti reikalavimus nuo verslo reikalavimų iki sistemos reikalavimų ir padeda nustatyti, kuriame reikalavimų lygyje yra problemos.
