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.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.