Inżynieria wymagań

W grud­niu 2011 roku napi­sa­łem na zakoń­cze­nie pew­ne­go arty­ku­łu o wymaganiach:

Większość pro­jek­tów takich jak np. wdra­ża­nie nowych metod kon­tro­lin­gu, zrów­no­wa­żo­nej kar­ty wyni­ków, nowych sys­te­mów IT itp. cier­pi głów­nie z powo­du posia­da­nia nad­mia­ru infor­ma­cji z jed­nej stro­ny i kom­plet­ne­go jej nie­zro­zu­mie­nia z dru­giej. Sławne już w bada­niach ?złe i nie­kom­plet­ne wyma­ga­nia? czy ?zmia­ny zakre­su pro­jek­tu w trak­cie jego trwa­nia? to kla­sycz­ne skut­ki złej (a czę­sto pomi­ja­nia!) ana­li­zy biz­ne­so­wej. Koszty tych pora­żek wie­lo­krot­nie prze­wyż­sza­ją koszt takich ana­liz. (Analiza biz­ne­so­wa ? sku­tecz­ne mode­lo­wa­nie a ryzy­ko pro­jek­tu).

Specyfikowanie wyma­gań, zarzą­dza­nie wyma­ga­nia­mi, inży­nie­ria wyma­gań, to jak widać bar­dzo trud­ny etap pro­jek­tu. Trudność bie­rze się stad, że dostęp­ne zale­ce­nia okre­śla­ją, że wyma­ga­nia maja być np. spój­ne i kom­plet­ne ale zupeł­nie nie opi­su­ją jak to osią­gnąć (a nawet jak to spraw­dzić).

Często moż­na się spo­tkać z poję­ciem inży­nie­ria wyma­gań”. Budzi ono mój opór z dwóch powo­dów: zna­cze­nie sło­wa inży­nie­ria w j.polskim i nie­ade­kwat­ność tego sło­wa do dzie­dzi­ny jaką jest spe­cy­fi­ko­wa­nie wyma­gań, któ­re są po pro­tu listą warunków.

Zajrzyjmy do słow­ni­ka języ­ka polskiego:

inży­nie­ria ?pro­jek­to­wa­nie i kon­stru­owa­nie obiek­tów oraz urzą­dzeń technicznych?

wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?

Więc jak rozu­mieć zło­że­nie inży­nie­ria wyma­gań”? Ja nie wiem, chy­ba, że ktoś uwa­ża, że wyma­ga­nia się kon­stru­uje”, i że są to zagad­nie­nia tech­nicz­ne. Za to ma sens inży­nie­rii sys­te­mów”. Mamy def. poję­cia system:

sys­tem ?układ ele­men­tów mają­cy okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Gdyby defi­ni­cje sło­wa inży­nie­ria” okro­ić z tech­nicz­nych” albo uznać, że sys­te­my są tak­że nie tech­nicz­ne (bo są np. spo­łecz­ne) to mamy wdzięcz­na definicję:

inży­nie­ria sys­te­mów ?pro­jek­to­wa­nie i kon­stru­owa­nie ukła­dów ele­men­tów mają­cych okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Jeden z moich ulu­bio­nych auto­rów aka­de­mic­kich, Ian Sommeville (lubię go tak­że za to, że książ­ki pisze w pubach popi­ja­jąc piwo ;)) defi­niu­je inży­nie­rię wyma­gań tak:

Requirements engi­ne­ering (RE) refers to the pro­cess of for­mu­la­ting, docu­men­ting and main­ta­ining softwa­re requ­ire­ments (źr. Kotonya G. and Sommerville, I. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley & Sons)

(poję­cie inży­nie­rii wyma­gań odno­si do pro­ce­su for­mu­ło­wa­nia, doku­men­to­wa­nia i zarzą­dza­nia wymaganiami)

Tak więc uzna­jąc, że wyma­ga­nia na sys­te­my to ele­ment inży­nie­rii tych sys­te­mów, niniej­szym godzę się uży­wać poję­cia inży­nie­ria wyma­gań” w zna­cze­niu jakim opi­sał to Sommerville :).

Po co tyle glę­dze­nia o sło­wach i ich zna­cze­niach? Poza szu­ka­niem” ali­bi dla ist­nie­nia poję­cia inży­nie­ra wyma­gań” chcę poka­zać, że sło­wa mają zna­cze­nie, zanie­dby­wa­nie tego pro­wa­dzi do wie­lu nie­po­ro­zu­mień (nie­jed­no­znacz­ność) a po dru­gie zwra­cam uwa­gę, że ana­li­za poję­cio­wa to jeden z klu­czo­wych ele­men­tów ana­li­zy w ogó­le (i czę­sto zaniedbywana).

Skoro wyma­ga­nia to warun­ki, to aż pro­si się by te warun­ki spraw­dzać. Patrzmy do słownika:

spraw­dzać ?skon­tro­lo­wać, zba­dać, czy coś jest zgod­ne z praw­dą, czy coś zosta­ło zro­bio­ne prawidłowo?

Tak więc wnio­sek jest pro­sty: wyma­ga­nie (każ­de!) powin­no być spraw­dzal­ne! Bez tego nie jeste­śmy w sta­nie okre­ślić czy coś” speł­nia te wyma­ga­nia, czy­li czy zda­nie: dostar­czo­ny pro­dukt jest zgod­ny z wyma­ga­nia­mi” jest praw­dzi­we czy nie (a nie chce­my oddać roz­strzy­ga­nia tego prawnikom ;)).

Inżynieria wymagań

Skoro więc ugią­łem się i uzna­łem poję­cie inży­nie­rii wyma­gań, popa­trz­my na to sys­te­mo­wo. Jak zawsze pro­ste jest pięk­ne więc co ana­li­zu­je­my w inży­nie­rii sys­te­mo­wej i inży­nie­rii wymagań:

Granice systemu

matrioszkaPojęcie sys­tem” to tak­że super­sys­tem (sys­tem nad­rzęd­ny) i pod­sys­tem (sys­tem pod­rzęd­ny, część sys­te­mu). To trosz­kę jak zna­ne wam, być może, matriosz­ki 🙂 (figur­ki jed­na w drugiej…).

Jest to, nazew­nic­two, bar­dzo waż­ne, bo w jed­nym pro­jek­cie (doku­men­ta­cji) nale­ży zacho­wać bez­względ­ną dys­cy­pli­nę poję­cio­wą, czy­li sło­wo System powin­no się odno­sić wyłącz­nie do kon­kret­ne­go pozio­mu opi­su, resz­ta to ele­men­ty sys­te­mu nad­rzęd­ne­go lub podrzędnego.

Mianem sys­tem okre­śla się zwy­cza­jo­wo spe­cy­fi­ko­wa­ne opro­gra­mo­wa­nie, jed­nak pro­blem poja­wi się natych­miast, gdy dotknie­my takich pojęć jak wyma­ga­nia funk­cjo­nal­ne na opro­gra­mo­wa­nie i wyma­ga­nia biz­ne­so­we. To ostat­nie nie­sie pew­ną nie­ja­sność. Bo nie wiem czy cho­dzi o wyma­ga­nia wobec (w sto­sun­ku do) biz­ne­su (np. popra­wa jako­ści obsłu­gi klien­ta o 5% w naj­bliż­szym bada­niu jako­ści ISO) czy wyma­ga­nia biz­ne­su wobec (w sto­sun­ku do) opro­gra­mo­wa­nia (np. mini­ma­li­za­cja do zera otrzy­ma­nych i zagu­bio­nych zapy­tań ofertowych).

Popatrzmy na powyż­szy dia­gram. Mamy tu dwa Systemy:

  1. Organizacja jest pod­sys­te­mem, jest ele­men­tem sys­te­mu, któ­rym tu jest rynek na jakim ta orga­ni­za­cja funkcjonuje.
  2. Organizacja jest ana­li­zo­wa­nym sys­te­mem, opro­gra­mo­wa­nie jest jed­nym z zaso­bów tej orga­ni­za­cji (opro­gra­mo­wa­nie jest tu podsystemem).

Wymagania może­my tu odno­sić w sto­sun­ku do Organizacji i w sto­sun­ku do Oprogramowania. To dla­te­go jasno wyod­ręb­nia­my ana­li­zę biz­ne­so­wą (pro­duk­tem są mode­le biz­ne­so­we i wyma­ga­nia biz­ne­so­we) od ana­li­zy wyma­gań na opro­gra­mo­wa­nie (mode­le i wyma­ga­nia na opro­gra­mo­wa­nie). Jak widać wyma­ga­nia na opro­gra­mo­wa­nie to wyma­ga­nia, któ­rych źró­dłem jest biz­nes, któ­ry ma kon­kret­ne cele do osią­gnię­cia. Nie powin­ny być one poboż­ny­mi życze­nia­mi użyt­kow­ni­ków, aż do momen­tu gdy spon­sor pro­jek­tu nie powie np.: moim celem jest wygo­da pra­cy moich pra­cow­ni­ków. Oczywiście, ta wygo­da jest zawsze wyma­ga­na ale nie musi ona być celem samym w sobie i nie musi mieć naj­wyż­sze­go priorytetu.

Wymagania inte­re­sa­riu­szy. Moja defi­ni­cja inte­re­sa­riu­sza (jed­na z wie­lu): oso­ba (pod­miot) zain­te­re­so­wa­na zaist­nie­niem pro­duk­tu, na któ­rą poja­wie­nie się pro­duk­tu ma wpływ. Nie raz jestem pyta­ny czy inte­re­sa­riusz ma pra­wo zgła­sza­nia wyma­gań. Jeżeli ma coś do powie­dze­nia pod­czas odbio­ru pro­duk­tu to zna­czy, że ma wyma­ga­nia. One mogą być jed­nak nie­jaw­ne czy­li taki inte­re­sa­riusz nie zgła­sza wyma­gań ale ma wpływ na odbiór pro­duk­tu, nale­ży go koniecz­nie ziden­ty­fi­ko­wać. Jeżeli zaś ktoś nie ma nic do gada­nia przy odbio­rze pro­duk­tu nie jest inte­re­sa­riu­szem (ang. sta­ke­hol­der, klu­czem jest tu «hol­der» czy­li dys­po­nent mają­cy coś do powie­dze­nia, mają­cy wpływ). Tak wiec inte­re­sa­riusz to ktoś kto, na swo­im pozio­mie ogól­no­ści, tak­że musi umieć okre­ślić, kie­dy uzna, że pro­dukt speł­nia jego wyma­ga­nia. Jak nie potra­fi, ktoś musi mu pomóc…analityk :)).

I tu rola ana­li­ty­ka. Interesariusz spi­su­je co mu przyj­dzie do gło­wy swo­im języ­kiem, ana­li­tyk upew­nia się, że zro­zu­miał, dopro­wa­dza je do posta­ci testo­wal­nej i kla­sy­fi­ku­je wyma­ga­nia” jako źró­dło: kon­kret­ny inte­re­sa­riusz” (bo każ­de wyma­ga­nie musi mieć wła­ści­cie­la). Proszę zwró­cić uwa­gę, że inte­re­sa­riu­szem jest tak­że użyt­kow­nik jeże­li tyl­ko ma coś go powie­dze­nia w projekcie :).

Popatrzmy na wymaganie:

Wymagania

Wymaganie jest jed­no (waru­nek jaki coś musi speł­nić) ale może ono mieć wie­le atry­bu­tów i tu widzę zło­żo­ność” wyma­gań (ich [[tak­so­no­mia]]). Zarówno wysta­wia­nie fak­tur VAT” jak i dostęp­ność 99,99% cza­su” to rów­no­praw­ne wyma­ga­nia bo opro­gra­mo­wa­nie np. wspo­ma­ga­ją­ce sprze­daż jest bez­war­to­ścio­we zarów­no gdy nie pozwa­la wysta­wiać fak­tur jak wte­dy, gdy czę­sto się psu­je. Owszem, jed­no jest funk­cjo­nal­ne dru­gie jest poza-funk­cjo­nal­ne ale jed­no i dru­gie to rów­no­praw­ny waru­nek przy­dat­no­ści” czy­li Wymaganie wobec oprogramowania.

Jak wspo­mnia­łem, wyma­ga­nia są (war­to tak robić) kla­sy­fi­ko­wa­ne za pomo­cą atry­bu­tów. Najczęściej spo­ty­ka­ne to: rodzaj (Kind), źró­dło wyma­ga­nia (Source), pole­cam tak­że prio­ry­tet, meto­dę wery­fi­ka­cji (np. test, audyt zgod­no­ści z opi­sem w doku­men­ta­cji), sta­tus (pla­no­wa­ne, zaakc­pe­to­wa­ne, odrzu­co­ne, …) i inne, zależ­nie od wyma­gań i typu projektu.

Ważna uwa­ga i zale­ce­nie IIBA: zarzą­dza­nie wyma­ga­nia­mi zabra­nia” ich usu­wa­nia (albo renu­me­ra­cji po usu­nię­ciu). usu­wa­nie powo­du­je to nie­spój­ność wer­sjo­no­wa­nej doku­men­ta­cji, któ­ra tak­że ma swój cykl życia. Ja od dłuż­sze­go cza­su sto­su­ję dodat­ko­wy sta­tus odrzu­co­ne”, co daje mi cią­głość doku­men­ta­cji a tak­że pozwa­la na odwie­sze­nie” wcze­śniej zde­fi­nio­wa­ne­go wyma­ga­nia, gdy ktoś jed­nak uzna, że coś co było zbęd­ne nagle zno­wu sta­je się konieczne :).

Liczba pytań i suge­stii (tak­że na kil­ku forach dys­ku­syj­na) skło­ni­ła mnie do pod­ję­cia pró­by zbu­do­wa­nia tak­so­no­mii wyma­gań. Jak już wspo­mnia­łem wyżej, zale­ce­nia takie jak FURPS to nie­ste­ty tyl­ko pła­ska lista cech” (i nie wszyst­kich). Wydaje mi się, że struk­tu­ra wyma­gań, ich tak­so­no­mia wza­jem­ne zależ­no­ści oraz rela­cje do udzia­łow­ców pro­jek­tu (inte­re­sa­riu­sze) i przy­szłych użyt­kow­ni­ków roz­wią­za­nia, wyma­ga­ją bar­dziej for­mal­ne­go podej­ścia. Celem jest uzy­ska­nie moż­li­wo­ści spraw­dza­nia czy wyma­ga­nia – jako przed­miot inży­nie­rii wyma­gań – speł­nia­ją jakieś, trze­ba je stwo­rzyć, wymagania.

Taksonomia wymaganPowyżej pró­ba usys­te­ma­ty­zo­wa­nia wyma­gań” na bazie wyżej cyto­wa­nych defi­ni­cji tego pojęcia.

Na koniec jesz­cze kolej­na waż­na rzecz. Warto wska­zy­wać, któ­re ele­men­ty logi­ki biz­ne­so­wej (Model) odpo­wia­da­ją (są powią­za­ne) z danym wyma­ga­niem bo np. szcze­gó­ło­wo opi­su­ją wyma­ga­ny spo­sób reali­za­cji dane­go wyma­ga­nia (np. sys­tem upu­stów albo kon­kret­ny przy­pa­dek uży­cia, tak­że Model). Warto tak­że, jeże­li opis wyma­ga­nia nie jest testem, zapro­jek­to­wać test (przy­pa­dek testo­wy), któ­ry potwier­dzi speł­nie­nie wyma­ga­nia np. opro­gra­mo­wa­nie ma pozwa­lać na wyli­cza­nie pier­wiast­ków dru­gie­go i trze­cie­go stop­nia”. Tu war­to podać kil­ka kon­kret­nych danych wej­ścio­wych wraz z pra­wi­dło­wy­mi wyni­ka­mi (może to doty­czyć nap. tabe­li upu­stów, sys­te­mu sko­rin­gu klien­tów itp.).

Tego typu meto­dy maja nazwę deklaratywnych:

Programowanie dekla­ra­tyw­ne ? rodzi­na para­dyg­ma­tów pro­gra­mo­wa­nia, któ­re nie są z natu­ry impe­ra­tyw­ne. W prze­ci­wień­stwie do pro­gra­mów napi­sa­nych impe­ra­tyw­nie, pro­gra­mi­sta opi­su­je warun­ki, jakie musi speł­niać koń­co­we roz­wią­za­nie (co chce­my osią­gnąć), a nie szcze­gó­ło­wą sekwen­cję kro­ków, któ­re do nie­go pro­wa­dzą (jak to zro­bić). Programowanie dekla­ra­tyw­ne czę­sto trak­tu­je pro­gra­my jako pew­ne hipo­te­zy wyra­żo­ne w logi­ce for­mal­nej, a wyko­ny­wa­nie obli­czeń jako ich dowo­dze­nie. Programowanie dekla­ra­tyw­ne jest szcze­gól­nym przed­mio­tem zain­te­re­so­wa­nia naukow­ców, gdyż dzię­ki mini­ma­li­za­cji lub eli­mi­na­cji skut­ków ubocz­nych może zna­czą­co upro­ścić two­rze­nie pro­gra­mów współ­bież­nych. Paradygmat pro­gra­mo­wa­nia dekla­ra­tyw­ne­go obej­mu­je sze­ro­ką gamę języ­ków pro­gra­mo­wa­nia i bar­dziej szcze­gó­ło­wych para­dyg­ma­tów pod­rzęd­nych. (Programowanie dekla­ra­tyw­ne ? Wikipedia, wol­na ency­klo­pe­dia).

Dom bez planów

Proces zbierania i analizy wymagań u developera

Dziś nie­co kon­tro­wer­syj­ny arty­kuł, kry­ty­ka naj­czę­ściej sto­so­wa­nych metod ana­li­zy wyma­gań. Pojawią się tu cyta­ty ze stron dużych firm dostar­cza­ją­cych opro­gra­mo­wa­nie. Są to kry­ty­ko­wa­ne prze­ze mnie opi­sy metod pra­cy. Jednak z mojej stro­ny będzie tu: nie moje widzi­mi­się” jako wła­ści­wa meto­da”, a meto­dy powszech­nie uzna­ne za sku­tecz­ne i opi­sa­ne w sie­ci i w lite­ra­tu­rze. Osobiście zresz­tą uwa­żam, że wie­le tak zwa­nych autor­skich meto­dyk” to albo udziw­nio­ne i nad­mier­nie kom­pli­ko­wa­ne stan­dar­dy (czy­taj pod­nie­sio­ne kosz­ty ana­li­zy), albo ubra­ne w pro­ce­du­ry” meto­dy tu kry­ty­ko­wa­ne (czy­li tak­że pod­nie­sio­ne kosz­ty ale już dal­szych etapów).

Bardzo czę­sto z ust dostaw­ców opro­gra­mo­wa­nia, moż­na usły­szeć o takim podzia­le wyma­gań, któ­ry co cie­ka­we, trud­no zna­leźć w opi­sach stan­dar­dów metod ana­li­tycz­nych (np. OMG​.org):

Wymaganie jest potrze­bą klien­ta, któ­ra wpły­wa na powsta­nie nowe­go roz­wią­za­nia lub zmie­nia roz­wią­za­nie już ist­nie­ją­ce. Ze wzglę­du na poziom szcze­gó­ło­wo­ści wyma­ga­nia mogą być biz­ne­so­we lub sys­te­mo­we.

Wymaganie biz­ne­so­we reali­zo­wa­ne jest poprzez jed­no lub zbiór wyma­gań sys­te­mo­wych. Przykładem może być Import pli­ków z umo­wa­mi. Wymaganie to moż­na zre­ali­zo­wać poprzez dwa wyma­ga­nia sys­te­mo­we: import pli­ków i obsłu­ga zaim­por­to­wa­nych plików.

Wymagania sys­te­mo­we doty­czą bez­po­śred­nich funk­cjo­nal­no­ści sys­te­mu. Złożone wyma­ga­nia sys­te­mo­we moż­na przed­sta­wić za pomo­cą bar­dziej szcze­gó­ło­wych, np. Import pli­ków obej­mu­je wyko­na­nie spraw­dzeń i wali­da­cji na zaim­por­to­wa­nych danych oraz pro­ces zapi­su umów z pli­ku impor­tu w sys­te­mie.

Pojawia się poję­cie Import pli­ku z umo­wa­mi”. Jaki to ma zwią­zek z biz­ne­sem? Domyślać się moż­na jedy­nie, że te umo­wy gdzieś są i w jakimś celu powin­ny być gdzieś dostęp­ne, ale nie jestem prze­ko­na­ny by użyt­kow­nik od razu wyar­ty­ku­ło­wał, że chce mieć ich import”. To poję­cie techniczne.

Osobiście pole­mi­zu­ję z takim podej­ściem nie tyl­ko dla­te­go, że trud­no o wska­za­nie pod­staw takie­go a nie inne­go podzia­łu wyma­gań. Także dla­te­go, że jest to pro­ces z grun­tu ryzy­kow­ny. Po trze­cie, powyż­sze defi­ni­cje nie speł­nia­ją pod­sta­wo­we­go kry­te­rium słow­ni­ka pojęć: poję­cia danej prze­strze­ni nazw nie mogą być defi­nio­wa­ne z pomo­cą innych pojęć tej samej prze­strze­ni. Takie błę­dy pro­wa­dzą do tak zwa­ne­go masła maśla­ne­go, co wyszło dość szyb­ko, bo tekst w dal­szej czę­ści tre­ści cyto­wa­nej stro­ny zaprze­cza czę­ści wcze­śniej­szej defi­ni­cji wymagań:

Zgodnie z teo­rią spe­cy­fi­ka­cja powin­na zawie­rać przede wszyst­kim wyma­ga­nia zapre­zen­to­wa­ne z punk­tu widze­nia klien­ta i w ter­mi­nach dla nie­go zro­zu­mia­łych. Powinna stwier­dzać, co ma zostać zre­ali­zo­wa­ne, a nie jak nale­ży to zro­bić. Specyfikacja wyma­gań nie może być więc pró­bą pro­jek­to­wa­nia systemu.

i z tym nale­ży się zgo­dzić w 100%, wiec co robi tu import pli­ku w raz całym opi­sem ich obsłu­gi, wali­da­cji itp. (w peł­nym tek­ście cyto­wa­nym jako wyma­ga­nie opi­sa­no pro­ces impor­tu pliku).

Po pierw­sze kim tu jest Klient? Gdzie jest użyt­kow­nik? Dlaczego wyma­ga­nie okre­śla spo­sób reali­za­cji wyma­ga­nia (Import pli­ków obej­mu­je…)? Co to są bez­po­śred­nie funk­cjo­nal­no­ści sys­te­mu”? Skoro są bez­po­śred­nie to czym są nie­bez­po­śred­nie funk­cjo­nal­no­ści” i gdzie je opisano?

Ogólnie poję­cie wyma­ga­nia sys­te­mo­we”, będą­ce pró­bą opi­su jak to ma być zro­bio­ne” nie mają żad­nej racji bytu jako Wymaganie Klienta. W ogó­le lite­ra­tu­ra (nie licząc masy mier­nej jako­ści porad­ni­ków) nie zawie­ra poję­cia wyma­ga­nie sys­te­mo­we” w zna­cze­niu innym niż wyma­ga­nia na plat­for­mę sprzę­to­wo-sys­te­mo­wą. Jednak te wyma­ga­nia powi­nien okre­ślić wyko­naw­ca na eta­pie pro­jek­tu imple­men­ta­cji a nie biznes.

W moich oczach doku­men­ta­cja wyma­gań powsta­ła na bazie powyż­szych defi­ni­cji, jest po pro­stu nie­we­ry­fi­ko­wal­na (pole­cam wpis o szko­dli­wo­ści dwu­znacz­no­ści tre­ści doku­men­ta­cji). Po dru­gie war­to wie­dzieć, że zama­wia­ją­cy nie jest w sta­nie (i nie powi­nien) pre­cy­zo­wać wyma­gań innych niż biz­ne­so­we zaś wyko­naw­ca (pro­gra­mi­sta, deve­lo­per) ocze­ku­je pro­jek­tu a nie wyma­gań. Wymagania ma – okre­śla – zama­wia­ją­cy, swo­im języ­kiem (więc raczej nie import umów”), ktoś powi­nien umieć je zwe­ry­fi­ko­wać (audyt) i zamie­nić na pro­jekt tego co ma wyko­nać (dostar­czyć) dostaw­ca opro­gra­mo­wa­nia. Dokładnie tak jest w innych dzie­dzi­nach inży­nie­rii, np. budowlanej.

Cytowany opis to mniej wię­cej taki pro­sty model ról w projekcie:

Mamy użyt­kow­ni­ka, któ­ry ma wyma­ga­nia co do opro­gra­mo­wa­nia, ana­li­tyk wyma­gań je zbie­ra (sesje warsz­ta­to­we, ankie­ty, spo­tka­nia, wywia­dy, inne) i wery­fi­ku­je. Powstaje spe­cy­fi­ka­cja. Tak powsta­łe spe­cy­fi­ka­cje wyma­gań nie pod­da­ją się żad­nej wery­fi­ka­cji na kom­plet­ność i spój­ność, są dekla­ra­cją użyt­kow­ni­ków bez gwa­ran­cji, że nie odkry­je­my nowych wyma­gań lub nie uzna­my wie­lu z nich za nadmiarowe.

Jak wyglą­da zale­ca­ny proces? 

Bazuje na pro­stej” kolej­no­ści dzia­łań opi­sa­nej na stro­nach OMG​.org pod nazwą pro­ces MDA”, nie raz w moim blo­gu przy­wo­ły­wa­ny. Proces ten ma na trzy klu­czo­we kroki:

  1. opra­co­wa­nie mode­lu fir­my: model biz­ne­so­wy (pro­ce­sy biz­ne­so­we, struk­tu­ra org., regu­ły biz­ne­so­we), jest to tak zwa­ny model CIM (Computing Independent Model), celem jego powsta­nia jest zbu­do­wa­nie narzę­dzia opi­su­ją­ce­go fir­mę Klienta, któ­re posłu­ży dopie­ro do zde­fi­nio­wa­nia i wery­fi­ka­cji wymagań.
  2. opra­co­wa­nie mode­lu PIM (Platform Independent Model), jest to opis usług sys­te­mu i ich logi­ki bez żad­nych infor­ma­cji o imple­men­ta­cji, to pro­jekt oprogramowania.
  3. opra­co­wa­nie mode­li PSM (Platform Specyfic Model), jest to opis tego jak model PIM ma być imple­men­to­wa­ny (zre­ali­zo­wa­ny) i to dopie­ro robi developer.

Całość bazu­je na kla­sycz­nej ana­li­zie sys­te­mo­wej (zwa­ną tez meto­da nauko­wą). Bazując na tym opi­sie powin­no więc być tak:

Wygląda na dość skom­pli­ko­wa­ny pro­ces ale to pozo­ry. Sponsor pro­jek­tu, klu­czo­wa postać w ana­li­zie wyma­gań, okre­śla cele biz­ne­so­we. One wyzna­cza­ją wszel­kie prio­ry­te­ty w dal­szej ana­li­zie np. prio­ry­te­ty wyma­gań. Sponsor sta­wia cele biz­ne­so­we np. pod­nie­sie­nie jako­ści obsłu­gi rekla­ma­cji poprzez eli­mi­na­cję przy­pad­ków zagu­bień doku­men­tów. Powstaje model CIM, z jego pomo­cą wyszu­ku­je­my miej­sca, w pro­ce­sach biz­ne­so­wych, w któ­rych te doku­men­ty giną lub jest ryzy­ko zagi­nię­cia. I tak prze­cho­dzi­my wszyst­kie wyma­ga­nia biz­ne­so­we. Tu wyma­ga­niem biz­ne­so­wym jest cel spon­so­ra, lista jego potrzeb i w kon­se­kwen­cji dopie­ro użyt­kow­ni­ków. Jednak to nie użyt­kow­nik dekla­ru­je, że coś chce”, takie ocze­ki­wa­nie musi wyni­kać z celu spon­so­ra. Wszystkie zało­że­nia, a są nimi np. ocze­ki­wa­ne funk­cjo­nal­no­ści opro­gra­mo­wa­nia i teza, że zaspo­ka­ja­ją one wyma­ga­nia spon­so­ra pro­jek­tu, są wery­fi­ko­wa­ne z pomo­cą mode­li. Modele sa tu narzę­dziem na eta­pie ana­li­zy CIM i pro­jek­tem na eta­pie PIM.

Lista wyma­gań jako ankie­ta życzeń przy­szłych użyt­kow­ni­ków to naj­częst­sze źró­dło pro­ble­mów w projektach. 

Dalej cele biz­ne­so­we wyzna­cza­ją na mode­lu CIM jakie usłu­gi przy­szły sys­tem ma ofe­ro­wać jego użyt­kow­ni­kom, by cele biz­ne­so­we speł­nić. Np. aby doku­men­ty nie ginę­ły, należ je ska­no­wać i archi­wi­zo­wać w spo­sób bez­piecz­ny i łatwy do wyszu­ka­nia zaraz po otrzy­ma­niu. To zna­czy, że System powi­nien udo­stęp­nić usłu­gi: ska­no­wa­nie i indek­so­wa­nie, wyszu­ki­wa­nie i prze­glą­da­nie. Logika tych usług to spo­sób wza­jem­ne­go koja­rze­nia tych doku­men­tów i póź­niej­sze­go wyszu­ki­wa­nia. Dokument, któ­ry to opi­su­je to model PIM. I to wszyst­ko robi Analityk Biznesowy.

Koszty takiej analizy

Tu war­to powie­dzieć, że nie zawsze ana­li­za w posta­ci kolek­cjo­no­wa­nia np. ankiet czy wyni­ków [[sesji JAD]] jest tań­sza od pro­jek­tu reali­zo­wa­ne­go opi­sa­ną metodą.

Jeżeli ana­li­zę wyma­gań robi jed­na oso­ba, i jej kom­pe­ten­cje to tyl­ko duże doświad­cze­nie w takich wywia­dach i two­rze­nie doku­men­tów (tek­sty, tabe­le itp.), to jej koszt może być rela­tyw­nie niski, jed­nak nie­ste­ty tak opra­co­wa­na lista wyma­gań to naj­czę­ściej listy cech zawie­ra­ją­ce tak­że owe pró­by imple­men­ta­cji” (np. import pli­ków umów”), bez żad­nej gwa­ran­cji, że dla odmia­ny cze­goś oczy­wi­ste­go” a waż­ne­go nie pomi­nię­to. Brak celu biz­ne­so­we­go spon­so­ra nie daje zaś żad­ne­go narzę­dzia do odsie­wu życzeń nad­mia­ro­wych”, zwa­nych potocz­nie w pro­jek­tach poboż­ny­mi życze­nia­mi użytkowników”.

Jeżeli ana­li­za robio­na jest siłą kil­ku kon­sul­tan­tów orga­ni­zu­ją­cych sesje warsz­ta­to­we z gru­pa­mi pra­cow­ni­ków, doku­men­ta­cja ma kil­ku recen­zen­tów i trwa to np. kwar­tał, to jest to pro­ces nie mniej ryzy­kow­ny, bo pro­duk­tem tak­że jest spe­cy­fi­ka­cja życze­nio­wa, za to bar­dzo kosz­tow­na, znacz­nie kosz­tow­niej­sza niż pra­ca jego doświad­czo­ne­go ana­li­ty­ka Biznesowego.

Tego typu życze­nio­we doku­men­ty, gene­ru­ją bar­dzo duże kosz­ty na eta­pie wdra­ża­nia i zarzą­dza­nia zmia­ną (odkry­wa­nie wyma­gań i ich zmiany).

Analiza Biznesowa i spe­cy­fi­ka­cja wyma­gań opra­co­wa­na meto­dą opi­sy­wa­ną tu i na stro­nach OMG, jest od tej ostat­niej (gru­pa kon­sul­tan­tów i sesje warsz­ta­to­we) znacz­nie tań­sza. W cza­sie trwa podob­nie, jed­nak robi to z regu­ły jed­na oso­ba (tak! ale przy zało­że­niu ma sto­su­je zaawan­so­wa­ne narzę­dzia CASE nie tyl­ko do two­rze­nia dia­gra­mów ale tak­że do ich wery­fi­ka­cji śla­do­wa­nia zarzą­dza­nia spój­no­ścią mode­li itp.), a efek­tem jest pro­jekt logicz­ny a nie dopie­ro lista wyma­ga­nych cech. Korzyść jest więc podwój­na. Jeżeli zro­bi to Analityk wyna­ję­ty przez Klienta a nie Dostawcy, to wszel­kie pra­wa (know-how) do pro­jek­tu pozo­sta­ją po stro­nie nabywcy.

Można powie­dzieć, że to trud­ne i kosz­tow­ne. Trudne owszem, wyma­ga doświad­cze­nia i wie­dzy zarów­no z zakre­su zarzą­dza­nia jak i inży­nie­rii opro­gra­mo­wa­nia. Per sal­do, wli­cza­jąc w to kosz­ty mody­fi­ka­cji na eta­pie wdra­ża­nia i odkry­wa­nia wyma­gań (wady spe­cy­fi­ka­cji nie pod­da­ją­cej się wery­fi­ka­cji) jest to pro­ces zawsze tań­szy (bada­nia kie­row­ni­ków pro­jek­tów wska­zu­ją, że zła jakość wyma­gań gene­ru­je dodat­ko­we kosz­ty rzę­du 60% war­to­ści pro­jek­tu, koszt takiej ana­li­zy nie prze­kra­cza zaś 20%). Do tego poja­wia­ją się poten­cjal­ne kosz­ty nie­ujaw­nio­ne klien­to­wi: pra­wa autor­skie do pro­jek­tu i apli­ka­cji. Jeżeli fir­ma będą­ca wyko­naw­ca opro­gra­mo­wa­nia robi ana­li­zę swo­je­go klien­ta i potem mu sprze­da­je pra­wa do jej wyni­ków wraz z dostar­cza­nym opro­gra­mo­wa­niem, to jest to kla­sycz­ny przy­pa­dek aneg­do­ty o kon­sul­tan­tach, któ­rzy zapy­ta­ni o to któ­ra jest godzi­na, pro­szą Cie o Twój zega­rek, odpo­wia­da­ją na pyta­nie któ­ra godzi­na i wysta­wia­ją fak­tu­rę za usłu­gę i tak­że za zwra­ca­ny Ci Twój zegarek.

Tak więc naj­pro­ściej: mamy spon­so­ra pro­jek­tu i ewen­tu­al­nych innych zain­te­re­so­wa­nych. Oni mają wyma­ga­nia biz­ne­so­we – chcą coś w swo­ich orga­ni­za­cjach osią­gnąć lub zmie­nić. Kolejny etap to ana­li­za, któ­rej celem jest oce­na czy to moż­li­we i jak. Jako narzę­dzia pra­cy” powsta­ją model tej orga­ni­za­cji: mapy pro­ce­sów, struk­tu­ra orga­ni­za­cyj­na, sys­tem reguł i pojęć biz­ne­so­wych. Produktem tej pra­cy są reko­men­da­cje gdzie i jak moż­na osią­gnąć efek­ty wyma­gań biz­ne­so­wych. Jeżeli zapad­nie decy­zja o tym, że wyma­ga­nia biz­ne­so­we pomo­że osią­gnąć nowe opro­gra­mo­wa­nie wspie­ra­ją­ce orga­ni­za­cję, na bazie posia­da­nych mode­li opra­co­wu­je się listę wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych. Są to usłu­gi sys­te­mu jakich od nie­go ocze­ku­je­my oraz ogra­ni­cze­nia jakościowe.

Ale to za mało, taki opis jest dopie­ro wsa­dem” do pro­jek­to­wa­nia. Nie wystar­czy powie­dzieć jakiej usłu­gi ocze­ku­je­my, koniecz­ne jest opi­sa­nie tego, jaką logi­kę ma każ­da usłu­ga reali­zo­wać i jaki­mi dany­mi zarzą­dzać. Należy okre­ślić jaką wie­dzą nadal będzie dys­po­no­wał użyt­kow­nik (aktor sys­te­mu) a jaką wie­dzę” ma posia­dać opro­gra­mo­wa­nie świad­czą­ce wyma­ga­ną usłu­gę (np. kto ma umieć poli­czyć poda­tek VAT na fak­tu­rze: użyt­kow­nik czy opro­gra­mo­wa­nie do fak­tu­ro­wa­nia). Dopiero taki opis sta­no­wi jasne zada­nie” dla dostaw­cy opro­gra­mo­wa­nia, któ­ry powi­nien zostać wybra­ny dopie­ro po tym, jak będzie­my dys­po­no­wa­li opi­sem tej logi­ki i jej ogra­ni­cze­nia­mi. Dlaczego? Dostawcy się zawsze w czymś spe­cja­li­zu­ją, ta spe­cja­li­za­cja jest czyn­ni­kiem wpły­wa­ją­cym na to, któ­ry zre­ali­zu­je nasz pro­jekt naj­le­piej. Jeżeli to przy­szły wyko­naw­ca wyko­na ana­li­zę i pro­jekt, jest pra­wie pew­ne, że będzie on opty­mal­ny z per­spek­ty­wy spe­cja­li­za­cji wyko­naw­cy a nie z per­spek­ty­wy wyma­gań Zamawiającego.