Produkty w procesie analizy wymagań

W arty­ku­le Inżynieria wyma­gań mię­dzy inny­mi opu­bli­ko­wa­łem tak­so­no­mię wyma­gań, jej roz­wi­nię­ta postać:

taksonomia wymagań

Temat wyma­gań regu­lar­nie wypły­wa na forach dys­ku­syj­nych i na kon­fe­ren­cjach. Ostatnio w podob­nej for­mie poja­wił się na pew­nym forum ser­wi­su LinkedIn i na dzi­siej­szej kon­fe­ren­cji. Na forum padło pyta­nie: co wybrać jako doku­men­ta­cje wyma­gań: SRS czy Use Case (odpo­wied­nio [[Software Requirements Specification]] czy­li [[spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie]] i Przypadki Użycia opro­gra­mo­wa­nia). Na dzi­siej­szej kon­fe­ren­cji zaś praw­nik, pod­czas swo­je­go refe­ra­tu, zwró­cił uwa­gę na fakt, że od stro­ny umów, pro­jek­ty – od ana­li­zy przed­wdro­że­nio­wej do dostar­cze­nia zamó­wio­ne­go opro­gra­mo­wa­nia – nale­ży dzie­lić pro­jekt na fazy będą­ce, zależ­nie od celu, umo­wą efek­tu (umo­wa o dzie­ło) i umo­wą sta­ran­ne­go dzia­ła­nia (umo­wa zlecenia).

Problem w tym, że SRS – czę­sto rozu­mia­ne jako doku­ment o struk­tu­rze opi­sa­nej w [[reko­men­da­cji IEEE830]], zawie­ra w pew­nej for­mie przy­pad­ki uży­cia (ale nie ich sce­na­riu­sze) rozu­mia­ne jako opis funk­cjo­nal­no­ści. Do tego reko­men­da­cja ta nie jest stan­dar­dem zawar­to­ści doku­men­tu a rekomendacją. 

SRS_IEEE830-1998Topics

Pojęcie przy­pad­ku uży­cia ma co naj­mniej dwie zupeł­nie róż­ne defi­ni­cje: jed­ną rodem z książ­ki Alistair’a Cockbourna Jak pisać efek­tyw­ne przy­pad­ki uży­cia”, dru­ga w spe­cy­fi­ka­cji nota­cji UML. Osobiście pre­fe­ru­ję te dru­gą i tyl­ko o nie będzie tu mowa (Cockbourn zresz­tą jaw­nie wyra­ża nie­chęć do UML w swo­jej książce).

Dla upo­rząd­ko­wa­nia dal­szej tre­ści przyj­mu­ję, że poję­cie przy­pa­dek uży­cia opro­gra­mo­wa­nia i funk­cjo­nal­ność opro­gra­mo­wa­nia są toż­sa­me (a kon­kret­nie przy­pa­dek uży­cia opi­su­je spo­sób reali­za­cji funk­cjo­nal­no­ści): obie okre­śla­ją to jaki efekt chce osią­gnąć (do cze­go użyć), w kon­kret­nym przy­pad­ku, użyt­kow­nik opro­gra­mo­wa­nia (kon­kret­na funk­cja jaką peł­ni opro­gra­mo­wa­nie, to jego moż­li­wy przy­pa­dek użycia).

Popatrzmy na eta­py pro­jek­tu, któ­re wyróż­nio­no na bazie tego, jakiej wie­dzy potrze­bu­je­my na każ­dym z tych eta­pów, by zapla­no­wać kolejny.

Etapy projektu

Jako pierw­sze powsta­ją wyma­ga­nia biz­ne­so­we opra­co­wa­ne na bazie oce­ny sytu­acji biz­ne­so­wej. Są one albo wła­snym pro­duk­tem Zamawiającego albo pro­duk­tem zatrud­nio­ne­go do tego celu eks­per­ta. Na bazie wyma­gań biz­ne­so­wych (celów biz­ne­so­wych) wyko­nu­je się ana­li­zę wyko­ny­wal­no­ści tych celów, powsta­je pomysł roz­wią­za­nia pro­ble­mu (osią­gnię­cia celu) w posta­ci wyma­gań wobec reko­men­do­wa­ne­go roz­wią­za­nia. Jeżeli ist­nie­je (zna­le­zio­no) na ryn­ku roz­wią­za­nie (pro­dukt lub stan­dar­do­wą usłu­gę) zosta­je ono zaku­pio­ne i wdro­żo­ne. Jeżeli nie (doty­czy nie tyl­ko cało­ści ale i czę­ści wyma­gań) nale­ży roz­wią­za­nie naj­pierw zapro­jek­to­wać a potem dopie­ro zle­cić wyko­na­nie i wdro­że­nie (a wcze­śniej na bazie pro­jek­tu wycenić).

Każdy z tych pro­duk­tów to przed­miot osob­nej umo­wy (lub jej eta­pu). Zależnie od stop­nia nie­wie­dzy” po stro­nie Zamawiającego, może to być umo­wa o dzie­ło lub zle­ce­nia. Jednak zale­ca się (praw­ni­cy zale­ca­ją) by, zawsze tam gdzie anga­żo­wa­ny jest eks­pert (usłu­go­daw­ca) zewnętrz­ny, sto­so­wać umo­wy o dzie­ło (umo­wa efek­tu), gdyż pozwa­la to pano­wać i nad cza­sem i nad budże­tem pro­jek­tu oraz w przy­pad­ku spo­ru sądo­we­go, moż­li­we było okre­śle­nie przed­mio­tu spo­ru (opis tego co mia­ło zostać wytwo­rzo­ne – dzieło).

Do zawar­cia umo­wy o dzie­ło koniecz­ny jest opis tego co ma powstać (opis dzie­ła). Patrząc od koń­ca: zawie­ra­jąc umo­wę z dostaw­cą opro­gra­mo­wa­nia mamy wyma­ga­nia wobec pro­duk­tu goto­we­go (w momen­cie zaku­pu speł­nia je lub nie) lub wyko­na­ny pro­jekt tego co ma powstać. Aby powstał pro­jekt musi­my mieć okre­ślo­ne wyma­ga­nia wobec roz­wią­za­nia i wyma­ga­nia (cele) biz­ne­so­we. Najtrudniej jest wyce­nić etap ana­li­zy sytu­acji biz­ne­so­wej bo tu w zasa­dzie nie wie­my jaka ta sytu­acja jest. Wymagania biz­ne­so­we, by powsta­ły, wyma­ga­ją pozy­ska­nia wie­dzy o tym jak funk­cjo­nu­je orga­ni­za­cja Zamawiającego i jakie zmia­ny pla­nu­je. To etap ana­li­zy biz­ne­so­wej (model moty­wa­cji biz­ne­so­wej i mode­le pro­ce­sów biz­ne­so­wych). W tym wypad­ku będzie to raczej umo­wa sta­ran­ne­go dzia­ła­nia z eks­per­tem, któ­ry tę ana­li­zę (i mode­le) wykona.

Pewnym roz­wią­za­niem pro­ble­mu ryzy­ka umo­wy czas i mate­riał” (nie wie­my kie­dy i jakim kosz­tem powsta­nie ocze­ki­wa­ny pro­dukt), jest okre­śle­nie tego jaki kon­kret­nie pro­dukt ma powstać (opis tego, jak stwier­dzi­my, że pra­ce wyko­na­no popraw­nie) i okre­śle­nia cza­su jaki sobie na to daje­my. Wymaga to pew­nej inwe­sty­cji, poświę­ce­nia cza­su na to, ale opła­ci się bo moc­no obni­ża­my ryzy­ko projektu.

Konkluzja praw­ni­ka, by zawie­rać umo­wy o dzie­ło jeże­li tyl­ko jest to moż­li­we, jest moim zda­niem słusz­na. Tam gdzie nie mamy wystar­cza­ją­cej wie­dzy by zawie­rać takie umo­wy, war­to zain­we­sto­wać czas by okre­ślić jed­nak przed­miot umo­wy, gdyż umo­wa zle­ce­nia z eks­per­tem (dostaw­cą opro­gra­mo­wa­nia) powo­du­je, że Zamawiający kom­plet­nie nie panu­je nad umo­wą: nie wie jakie­go pro­duk­tu ocze­ki­wać, satys­fak­cja z wyko­na­nej pra­cy może nadejść w trud­nym do prze­wi­dze­nia czasie.

Druga uwa­ga: jeże­li cały pro­ces, od pierw­szej ana­li­zy do dostar­cze­nia pro­duk­tu, reali­zu­je jed­na fir­ma, mamy do czy­nie­nia z sytu­acją, w któ­rej dostaw­ca sam kon­tro­lu­je sta­wia­ne mu wyma­ga­nia bo sam sobie defi­niu­je to co ma następ­nie wytwo­rzyć. Taki brak kon­tro­li rodzi poważ­ne ryzy­ko nierzetelności.

Komunikacja osmotyczna czyli po Brzytwie przypadków użycia

No nic nie pora­dzę na to, że zna­ny w bran­ży autor ([[Alistair Cockburn]]) moim zda­niem pły­wa w czymś co ja nazy­wam mno­że­nie bytów”, świat zna to pod nazwą [[Brzytwa Ockhama]], tu raczej jest to zaprze­cze­nie tej zasa­dzie a w moich oczach A.C. jest mistrzem w tej dziedzinie:

Alistair Cockburn przy­ta­cza na swo­jej stro­nie defi­ni­cję stwier­dza­ją­cą, że ?komu­ni­ka­cja osmo­tycz­na ozna­cza, że infor­ma­cja prze­pły­wa w tle sły­sza­na przez człon­ków zespo­łu, dzię­ki cze­mu mogą zapo­znać się z infor­ma­cją jak­by przez osmo­zę. Zwykle jest to reali­zo­wa­ne przez zespół sie­dzą­cy w jed­nym pomiesz­cze­niu. W momen­cie, gdy jed­na oso­ba zada­je pyta­nie, inni w pomiesz­cze­niu mogą albo zare­ago­wać lub zigno­ro­wać pyta­nie, zaan­ga­żo­wać się w dys­ku­sję lub kon­ty­nu­ować swo­ją pra­cę.? (źr. Komunikacja osmo­tycz­na a pro­ces).

Czytam sobie o tej komu­ni­ka­cji osmo­tycz­nej i dziw bie­rze, że takie sło­wo­twór­stwo ma miej­sce. Dlaczego? Owa osmo­tycz­na komu­ni­ka­cja” to nic inne­go jak [[komu­ni­ka­cja meto­da publish/subscribe]]. Prosty mecha­nizm, zna­ny z teo­rii komu­ni­ka­cji mówią­cy, że sys­tem jakim jest ludz­ki mózg i ucho bro­niąc się przez nad­mia­rem infor­ma­cji, odbie­ra wszyst­kie dźwię­ki ale reagu­je jedy­nie na pew­ne ocze­ki­wa­ne”. To ocze­ki­wa­nie jest niczym innym jak infor­ma­cją pomoc­ną”, np. w prze­ży­ciu (kie­dyś). To bar­dzo sta­ry mecha­nizm ukształ­to­wa­ny przez ewo­lu­cje tak­że u zwie­rząt. Dokładnie tak samo są nie raz pro­jek­to­wa­ne sys­te­my komu­ni­ku­ją­cych się modu­łó, pro­ce­sów, podsystemów.

Klasyczny przy­kład uży­cia tego wzor­ca pro­jek­to­we­go w projektach:

Jak śle­dzę książ­ki Pana Cockburn’a to nie­ste­ty mam wra­że­nie, że po pierw­sze Przypadki Użycia daw­no sta­ły się u nie­go syn­dro­mem młot­ko­we­go” (czło­wie­ko­wi, któ­ry dosta­nie do ręki wiel­ki mło­tek natych­miast wszyst­ko zaczy­na koja­rzyć się z gwoź­dziem). Po dru­gie dzi­wi mnie, że moż­na z takim zacię­ciem igno­ro­wać pozo­sta­łe doko­na­nia tuzów ana­li­zy takich jak Yourdon, Fowler czy Evans.

Tak więc pro­po­nu­ję roz­wa­że­nie, by zamiast wpro­wa­dza­nia nowe­go poję­cia: komu­ni­ka­cja osmo­tycz­na (choć wiem, że brzmi super i pew­nie pozwa­la zostać cele­bry­tą nie­jed­nej kon­fe­ren­cji) pozo­stać przy sta­rym dobrym wzor­cu publish/subscribe nie tyl­ko w obsza­rze mode­lo­wa­nia pro­ce­sów czy opro­gra­mo­wa­nia ale tak­że na niwie zwy­kłej komu­ni­ka­cji. Dla zain­te­re­so­wa­nych wzor­cem i jego zasto­so­wa­niem w mode­lach pro­ce­sów wię­cej w arty­ku­le jaki napi­sa­łem o CRM.

A koń­cząc w kwe­stii Cockbourn’a i jego orę­dow­ni­ków: oso­bi­ście i bar­dzo subiek­tyw­nie uwa­żam, że nawet jeśli dowol­ną kupę mało spój­ne­go tek­stu roz­ło­ży­my na wier­sze i kolum­ny dowol­nej ilo­ści tabel (to się cza­sem nazy­wa cza­sem nada­wa­niem tek­sto­wi struk­tu­ry) to taki tekst nadal będzie mało spój­ny. Przypadki uży­cia jako tabe­la­rycz­na for­ma zapi­su user sto­ry” lub wyma­gań funk­cjo­nal­nych, nie uzy­ska­ją spój­no­ści poprzez sam fakt ich stabelaryzowania.

Przypadki uży­cia zaś jako efekt ana­li­zy cało­ści zacho­wań i świa­do­me­go wybo­ru czę­ści z nich to jest dopie­ro spój­ny i kom­plet­ny opis wyma­gań. Bo jak to ktoś powie­dział: kom­plet­na lista naj­ład­niej­szych kobiet w danym mie­ście to nie lista spo­tka­nych ład­nych w ostat­nim mie­sią­cu a lista wybra­nych spo­śród wszyst­kich w tym mie­ście. Taka lista ma sens bo nie gro­zi nam to, ze następ­ne­go dnia w tym mie­ście spo­tka­my inna ładniejszą.

Jeżeli ktoś Ci przy­nie­sie spe­cy­fi­ka­cję przy­pad­ków uży­cia do sys­te­mu i nie będzie potra­fił jed­no­znacz­nie odpo­wie­dzieć na pyta­nie dla­cze­go jest ich aku­rat tyle a nie np. jeden mniej lub dwa wię­cej albo dla­cze­go aku­rat te a nie inne, to naj­praw­do­po­dob­niej zna­czy to, że pod­czas wdro­że­nia na pew­no spo­tkasz kil­ka innych ład­niej­szych kobiet”.