Pomijając ich warian­ty, sto­so­wa­ne są dwie meto­dy (gru­py metod) doku­men­to­wa­nia wyma­gań i zarzą­dza­nia nimi. Zakładamy, że są to wyma­ga­nia wobec pro­duk­tu (roz­wią­za­nia) jaki ma dostar­czyć jego dostaw­ca. W BABoK (Business Analysis Body of Knowledge), wyma­ga­nia te musi speł­nić dostar­czo­ny pro­dukt, jed­nak oczy­wi­ście roz­li­cza­ny jest dostaw­ca rozwiązania.

Stosowane są trzy meto­dy (gru­py metod) spe­cy­fi­ko­wa­nia wymagań:

  1. Specyfikacja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych (i warian­ty tej metody).
  2. Specyfikowanie tak zwa­nej czar­nej skrzyn­ki” (przy­pad­ki użycia).
  3. Specyfikowanie tak zwa­nej bia­łe skrzyn­ki” (przy­pad­ki uży­cia + model dzie­dzi­ny systemu).

Pierwsza i naj­star­sza meto­da bazu­je na zało­że­niu, że zama­wia­ją­cy i (lub) przy­szły użyt­kow­nik wie cze­go chce. Wymagania w posta­ci listy (funk­cjo­nal­ne i poza-funk­cjo­nal­ne) kolek­cjo­no­wa­ne są na warsz­ta­tach, burzach mózgów, tak zwa­nych sesjach JAD (ang. [[Joint Application Development]]), bywa, że z pomo­cą ankiet. Powstaje lista (tabe­la) z odpo­wied­nio ozna­czo­ny­mi i skla­sy­fi­ko­wa­ny­mi wymaganiami.

Czarna skrzyn­ka” to wyma­ga­nia opra­co­wa­ne w posta­ci opi­su roz­wią­za­nia sku­pia­ją­ce­go się wyłącz­nie na jego zewnętrz­nych cechach, zmu­sza do wyspe­cy­fi­ko­wa­nia tego do cze­go ma ono słu­żyć, jed­nak nie opi­su­je mecha­ni­zmu jego dzia­ła­nia, spe­cy­fi­ka­cja przy­pad­ków uży­cia w zasa­dzie zamy­ka się na udo­ku­men­to­wa­niu bodź­ca i efek­tu (stan począt­ko­wy i koń­co­wy) każ­de­go przy­pad­ku uży­cia (usłu­gi spe­cy­fi­ko­wa­nej apli­ka­cji), wyja­śnie­nie np. spo­so­bu wyko­na­nia obli­czeń – owszem – doku­men­to­wa­ne jest w posta­ci np. wzo­rów mate­ma­tycz­nych czy algo­ryt­mów, jed­nak taka cecha jak np. moż­li­wość sko­ja­rze­nia wszyst­kich zamó­wień, na bazie któ­rych powsta­ła zbior­cza fak­tu­ra na koniec mie­sią­ca” pozo­sta­je tyl­ko nazwa­nym wyma­ga­niem, spe­cy­fi­ka­cja taka nie zawie­ra opi­su mecha­ni­zmu pozwa­la­ją­ce­go na taka operację.

Biała skrzyn­ka” to spe­cy­fi­ka­cja jak wyżej, uzu­peł­nio­na o opis (model) np. mecha­ni­zmu pozwa­la­ją­ce­go na sko­ja­rze­nie tych zamó­wień z wła­ści­wą fakturą.

BABoK gene­ral­nie wska­zu­je (sku­pia się) na dwóch ostat­nich metodach.

W każ­dym pro­jek­cie trwa­ją­cym w cza­sie i dopusz­cza­ją­cym zmia­ny w jego zakre­sie (w wyma­ga­niach) poja­wia się potrze­ba zarzą­dza­nia zmia­na­mi, zaspo­ka­ja­na prak­tycz­nie zawsze z pomo­cą tak zwa­ne­go wer­sjo­no­wa­nia. Wersjonowanie wyma­gań w posta­ci pła­skiej listy wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych, jest żmud­ne, spro­wa­dza się do nie­za­leż­ne­go wer­sjo­no­wa­nia tre­ści (brzmie­nia) każ­de­go wyma­ga­nia wraz z moż­li­wo­ścią poja­wie­nia się nowe­go i usu­nię­cia już ist­nie­ją­ce­go (lub nada­nia mu sta­tu­su odrzu­co­ne”). Opisał to ład­nie Miał Wolski:

Zmiany w wyma­ga­niach wyma­ga ich wer­sjo­no­wa­nia. Wersje wyma­gań poma­ga­ją uzy­skać dostęp do okre­ślo­ne­go sta­nu wyma­ga­nia w trak­cie życia opro­gra­mo­wa­nia. Najczęściej wer­sje wyma­gań okre­śla­ne są za pomo­cą kolej­nych ich nume­rów. Najbardziej popu­lar­nym spo­so­bem nada­wa­nia nume­rów wyma­gań jest zło­że­nie nume­ru z wer­sji wyma­ga­nia oraz przy­ro­stu, oddzie­lo­nych zna­kiem krop­ki. Wersja 1.3 ozna­cza wte­dy 1 wer­sję wyma­ga­nia i 3 przy­rost. (Źródło: Wymagania ? Zarządzanie wer­sja­mi | Michał Wolski)

Zupełnie ina­czej wyglą­da w pozo­sta­łych dwóch meto­dach. Zarówno czar­na skrzyn­ka” jak i jej bia­ła” odmia­na, to są już pro­jek­ty roz­wią­za­nia (np. apli­ka­cji), bia­ła skrzyn­ka” zawie­ra wewnętrz­ną archi­tek­tu­rę. Wobec tego jest to jeden pro­jekt” a nie np. czte­ry­sta wyma­gań”. Wersjonowaniu pod­le­ga tu jeden pro­jekt, dzię­ki temu sam pro­ces wer­sjo­no­wa­nia i zarzą­dza­nie nim sta­je się znacz­nie prost­szy (moż­na to robić np. z pomo­cą sys­te­mów zarzą­dza­nia wer­sja­mi taki­mi jak [[CVS]], [[SVR]] itp.). Owszem, pro­jekt może zawie­rać wie­le deta­li, żeby uła­twić zna­le­zie­nie róż­ni­cy mię­dzy wer­sja­mi (tego co zosta­ło wła­śnie zmie­nio­ne) na począt­ku doku­men­tu (spe­cy­fi­ka­cji pro­jek­tu) umiesz­cza się tak zwa­ny regestr zmian (doty­czy całe­go projektu).

Opracowanie listy wyma­gań funk­cjo­nal­nych i poza funk­cjo­nal­nych jest rela­tyw­nie naj­prost­sze, nie wyma­ga od pra­cow­ni­ków zama­wia­ją­ce­go dodat­ko­wych kwa­li­fi­ka­cji, mogą w tym pro­ce­sie brać udział przy­szli użyt­kow­ni­cy, jed­nak utrzy­ma­nie kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści takiej spe­cy­fi­ka­cji jest najtrudniejsze.

W przy­pad­ku skrzy­nek” już sam fakt, że są one pro­jek­tem (pew­ną kon­struk­cją) pozwa­la sto­so­wać do ich opi­su typo­we inży­nier­skie meto­dy takie jak mode­lo­wa­nie. Model moż­na testo­wać więc zagwa­ran­to­wa­nie spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści jest łatwiej­sze, pro­ble­mem pozo­sta­je co naj­wy­żej kom­plet­ność, czy­li odpo­wiedź na pyta­nie Czy to są wszyst­kie wyma­ga­ne funk­cje”. Ryzyko jakie stwa­rza czar­na skrzyn­ka” to pozo­sta­wie­nie dostaw­cy (wyko­naw­cy, deve­lo­pe­ro­wi) decy­zji o posta­ci mecha­ni­zmu dzia­ła­nia (jego zapro­jek­to­wa­nie). Dostawca może go zbyt upro­ścić lub wręcz nie rozu­mieć i powsta­nie coś co nie reali­zu­je w 100% logi­ki biz­ne­so­wej danej orga­ni­za­cji. Biała skrzyn­ka” niwe­lu­je to ryzy­ko: powsta­je tu pro­jekt wewnętrz­nej logi­ki: mecha­nizm dzia­ła­nia aplikacji.

Konsekwencje. Wydawało by się, że pierw­sza meto­da jest naj­tań­sza, bo pro­jek­to­wa­nie jest kosz­tow­niej­szą pra­cą bo wyma­ga znacz­nie więk­szych kom­pe­ten­cji niż pro­wa­dze­nie warsz­ta­tów, sam przy­szły użyt­kow­nik z regu­ły nie posia­da tych kom­pe­ten­cji i musi za nie zapła­cić. Niestety jest to praw­da dla małych pro­jek­tów, tam gdzie poja­wia­ją się wyma­ga­nia w ilo­ści setek i nie raz tysię­cy, samo zarzą­dza­nie nimi jest tak pra­co­chłon­ne, że koszt rośnie szyb­ciej niż licz­ba tych wymagań.

Po prze­kro­cze­niu pew­ne­go pozio­mu zło­żo­no­ści znacz­nie lep­sze są meto­dy sys­te­mo­we opar­te na pro­jek­to­wa­niu („skrzyn­ki”), i tu waż­na uwa­ga: pro­jek­to­wa­nie to etap spe­cy­fi­ko­wa­nia wyma­gań, jeże­li pro­jekt opra­cu­je zama­wia­ją­cy, niwe­lu­je ryzy­ka jakie nie­sie ze sobą zle­ce­nie pro­jek­to­wa­nia deve­lo­pe­ro­wi: praw­do­po­dob­nie będzie uprasz­czał pro­jekt (obni­żał swój koszt) i bar­dzo praw­do­po­dob­ne, że będzie for­so­wał swo­je dotych­cza­so­we doświad­cze­nie z fir­my o podob­nym cha­rak­te­rze co nie­ste­ty bar­dzo czę­sto pro­wa­dzi do nie­upraw­nio­ne­go powie­le­nie cudzej i nie­ko­niecz­nie dobrej, logi­ki biz­ne­so­wej. Do tego poja­wia się pro­blem (duże ryzy­ko) zawłasz­cze­nia przez dostaw­cę praw autor­skich do pro­jek­tu tej biz­ne­so­wej logi­ki i całe­go mecha­ni­zmu dzia­ła­nia apli­ka­cji a tym samym orga­ni­za­cji (o czym nie raz tu już pisa­łem).

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.