Dzisiaj krót­ki arty­kuł o wyma­ga­niach dzie­dzi­no­wych. W jed­nym z poprzed­nich arty­ku­łów pisa­łem o wyma­ga­niach, że pro­blem tkwi w ich zro­zu­mie­niu i o tym, że przy­szły użyt­kow­nik nie powi­nien pisać ​„jaki ma być ten pro­gram”, bo popy­cha pro­jekt w stro­nę cha­otycz­nych oczekiwań.

I tu jest sed­no: ana­li­za nie powin­na być tyl­ko pasmem wywia­dów, któ­re­go pro­duk­tem będę set­ki stron zapi­sów z ankiet i prze­pro­wa­dzo­nych roz­mów. Analiza, to duża pra­ca, któ­rej celem powin­no być zro­zu­mie­nie a nie tyl­ko opi­sa­nie. (Analiza wyma­gań na opro­gra­mo­wa­nie czy­li opi­sa­nie czy zro­zu­mie­nie).

Wymagania naj­czę­ściej dzie­li­my na funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Warto jed­nak upo­rząd­ko­wać pro­jekt i ukie­run­ko­wać ana­li­zę naj­pierw na wyma­ga­nia biz­ne­so­we a potem do już wymie­nio­nych dodać wyma­ga­nia dzie­dzi­no­we. Te ostat­nie są tak na praw­dę wydzie­le­niem z cha­osu ocze­ki­wań cze­goś co nazwę ​„jak to jest robio­ne” ale nie w kon­tek­ście opro­gra­mo­wa­nia (pro­gra­mi­ści wie­dzą jak pro­gra­mo­wać), a w kon­tek­ście reguł biz­ne­so­wych i decy­zyj­nych (wie­dzy o tym jak się rze­czy dzieją).

Oprogramowania bez­po­śred­nio doty­czą tyl­ko wyma­ga­nia funk­cjo­nal­ne, poza-funk­cjo­nal­ne i dzie­dzi­no­we. Wymagania biz­ne­so­we to cele jakie ma przed sobą orga­ni­za­cja, dla któ­rej ma powstać (ma zostać jej dostar­czo­ne) opro­gra­mo­wa­nie. Zresztą, nie nale­ży o tym zapo­mi­nać, że może ist­nieć inne roz­wią­za­nie pro­ble­mu orga­ni­za­cji, niż oprogramowanie.

Oprogramowanie pro­jek­to­wa­ne meto­da­mi obiek­to­wy­mi wg. naj­lep­szych prak­tyk i wzor­ców ma nastę­pu­ją­ca strukturę:

Aktor to oczy­wi­ście jego użyt­kow­nik. Oprogramowanie, jako narzę­dzie pra­cy, świad­czy usłu­gi jego użyt­kow­ni­kom – akto­rom, jest ich narzę­dziem pra­cy. Oprogramowanie zawiera:

1. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za jakość świad­czo­nych usług, to kla­sy reali­zu­ją­ce przy­pad­ki uży­cia tego oprogramowania,
2. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za logi­kę biznesową,
3. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za utrwa­la­nie infor­ma­cji (obiek­ty biznesowe).

Wymagania to warun­ki jakie ma speł­niać opro­gra­mo­wa­nie by było przy­dat­ne. Tak więc Analityk biz­ne­so­wy powi­nien zro­zu­mieć jak dzia­ła orga­ni­za­cja, zde­fi­nio­wać narzę­dzie jakie jej pomo­że, opi­sać wyma­ga­nia na to narzę­dzie. Jak? Powiem ina­czej, nie jest rolą pro­gra­mi­stów ​„odkry­wa­nie” logi­ki biz­ne­so­wej, pro­gra­mi­sta odpo­wia­da za jej imple­men­ta­cję. Dlatego war­to pamię­tać o wyma­ga­niach dzie­dzi­no­wych… nie jest to nie­ste­ty miej­sce na szcze­gó­ło­wy ich opis, tu zapra­szam na szko­le­nie o wyma­ga­niach, któ­re pro­wa­dzę.

Praktyka nie­ste­ty poka­zu­je, że zapis ocze­ki­wań użyt­kow­ni­ka i prze­ka­za­nie ich pro­gra­mi­stom to dro­ga na manow­ce… Oczekiwania w rodza­ju roz­wi­ja­ne listy, ​„mysz­ko­lo­gia”, ​„łatwe w uży­ciu ekra­ny” i cała masa innych szcze­gó­łów nijak się ma do tego jak to opro­gra­mo­wa­nie ma dzia­łać. To tyl­ko cechy użyt­ko­we inter­fej­su użyt­kow­ni­ka, te jed­nak bez wewnętrz­nej logi­ki po pierw­sze o niczym nie mówią, a po dru­gie i tak są efek­tem goto­wych ele­men­tów z jakich budu­je się inter­fejs użyt­kow­ni­ka. Warto o ich wspo­mnieć by zama­wia­ją­cy miał ich świa­do­mość ale nie oszu­kuj­my się, opi­su­je­my tak tyl­ko to co zna­my już z innych apli­ka­cji a to w pew­nym sen­sie stan­dard (np. doty­ko­wy ekran smart­fo­na czy tabletu).

Zapisanie zaś, że sys­tem ma pozwa­lać na dobór pro­mo­cji dla klien­tów o róż­nych pozio­mach zaku­pów, po pierw­sze nic nie mówi, po dru­gie wyma­ga ana­li­zy ​„o co cho­dzi” i są to wła­śnie wyma­ga­nia dzie­dzi­no­we­go. Wymaganiem funk­cjo­nal­nym będzie tu to: System pozwa­la na zarzą­dza­nie listą upu­stów. W języ­ku pol­skim i nie tyl­ko funk­cja to zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz. Innymi sło­wy wyma­ga­nie funk­cjo­nal­ne to to do cze­go ma słu­żyć opro­gra­mo­wa­nie a nie to jak ma to robić.

Przypomnę na zakoń­cze­nie: powyż­sze to tyl­ko pew­ne dobre prak­ty­ki 🙂 bazu­ją­ce na meto­dach obiek­to­wych (a w zasa­dzie takie głów­nie są teraz a w uży­ciu) i wzor­cach projektowych.