Gdzie się realizują wymagania

Tym razem dość krót­ko ale zno­wu wzor­ce i dobre praktyki.

Bardzo czę­sto spo­ty­kam, pew­nie nie ja jeden, spe­cy­fi­ka­cje wyma­gań zawie­ra­ją­ce zapi­sy ​„ocze­ki­wań użyt­kow­ni­ków”. Bardzo czę­sto sły­szę tak­że, że to przy­szły użyt­kow­nik opro­gra­mo­wa­nia powi­nien być źró­dłem wyma­gań. Nic bar­dziej błędnego.

Co nam powie słow­nik j.polskiego o wymaganiach?

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

Jest to bar­dzo zgrab­na defi­ni­cja. Zgodnie z logi­ką jeże­li jakieś poję­cie zastą­pi­my jego popraw­ną defi­ni­cją, zda­nie nie powin­no zmie­nić zna­cze­nia. Gdybyśmy więc powiedzieli:

Kupimy wyłącz­nie opro­gra­mo­wa­nie, któ­re speł­nia nasze wymagania.

to po takiej pod­mia­nie uzyskamy:

Kupimy wyłącz­nie opro­gra­mo­wa­nie, któ­re speł­nia nasze warun­ki, któ­rym musi ono odpowiadać.

Nie jest źle. Tak więc wyma­ga­nia na opro­gra­mo­wa­nie, to lista warun­ków, któ­rym musi ono odpo­wia­dać by było nam przydatne.

Najczęściej chy­ba moż­na się spo­tkać w pro­jek­tach z tak zwa­ny­mi wyma­ga­nia­mi funk­cjo­nal­ny­mi i poza funk­cjo­nal­ny­mi. Coraz czę­ściej moż­na spo­tkać też spe­cy­fi­ka­cje tak zwa­nych przy­pad­ków użycia.

Popatrzmy jed­nak naj­pierw na struk­tu­rę opro­gra­mo­wa­nia. Standardem archi­tek­tu­ry opro­gra­mo­wa­nia stał się wzo­rzec MVC ([[Model, View, Controller]]), tak go moż­na ogól­nie przedstawić:

MVC

Zanim zacznie­my spi­sy­wać wyma­ga­nia, war­to zro­zu­mieć z czym wal­czy­my. A wal­czy­my z tym, że opro­gra­mo­wa­nie to obec­nie roz­dzie­lo­ne: wygląd i treść inter­fej­su użyt­kow­ni­ka (View), logi­ka biz­ne­so­wa (Model), śro­do­wi­sko tech­no­lo­gicz­ne (Controller).

To co nazy­wa­my przy­pad­kiem uży­cia to inte­rak­cja użyt­kow­nik (aktor sys­te­mu) z sys­te­mem (opro­gra­mo­wa­nie). Tą meto­dą opi­su­je­my wyłącz­nie jeden, raczej rela­tyw­nie mało zna­czą­cy w pro­jek­cie two­rze­nia nowe­go opro­gra­mo­wa­nia, kom­po­nent. Jest on, przy­pa­dek uży­cia, jed­nak bar­dzo waż­ny przy wybo­rze goto­we­go opro­gra­mo­wa­ni bo tu defi­niu­je­my kon­kret­ną wyma­ga­ną Usługę Systemu (w goto­wym opro­gra­mo­wa­niu jej nie imple­men­tu­je­my, więc zbyt szcze­gó­ło­wy opis tu tyl­ko zaciem­nia problem).

Jeżeli tą usłu­gą ma być np. ​„wysta­wia­nie fak­tur VAT” to czyn­ność ta jest dość dokład­nie opi­sa­na w prze­pi­sach i ryzy­ko, że nie otrzy­ma­my potrzeb­nej funk­cjo­nal­no­ści jest bli­skie zeru. Jeżeli jed­nak opis wyma­ga­nej usłu­gi sys­te­mu brzmi tak:

Wymaganie funk­cjo­nal­ne: sto­so­wa­nie funk­cji wyszu­ki­waw­czych ? wyszu­ki­wa­nie danych speł­nia­ją­cych okre­ślo­ne para­me­try, w tym według wię­cej niż jeden zada­nych kry­te­riów jed­no­cze­śnie. (cytat z doku­men­tu Opis Przedmiotu Zamówienia, w skró­cie OPZ, jed­ne­go z prze­tar­gów publicznych)

to konia z rzę­dem temu, kto mi powie co ten sys­tem ma tak na praw­dę robić i jak stwier­dzić, że zaku­pio­ny sys­tem to robi (cyto­wa­ny doku­ment OPZ jest w cało­ści napi­sa­ny w tym stylu).

Interfejsy: jeże­li napi­sze­my jedy­nie z czym się łączy­my np. enig­ma­tycz­ne: sys­tem ma pozwa­lać na wymia­nę danych z opro­gra­mo­wa­niem finan­so­wo-księ­go­wym, to tak na praw­dę wska­za­li­śmy tyl­ko, że taki trans­fer ma miej­sce, ale nic ponad to, a tu klu­czem są dane prze­ka­zy­wa­ne, o któ­rych ani sło­wa, i może się oka­zać, że jakaś wymia­na danych jest moż­li­wa (w zasa­dzie pra­wie zawsze jest) ale nie takich, któ­re są nam potrzeb­ne… czy­li tak na praw­dę wyma­ga­nie nie będzie speł­nio­ne i odkry­je­my to jed­nak za póź­no po po zaku­pie oprogramowania.

Uogólniając, cała nie­bie­ska część powyż­sze­go dia­gra­mu to śro­do­wi­sko tech­no­lo­gicz­ne, z regu­ły pre­de­fi­nio­wa­ne jako tak zwa­ny fra­me­work (szkie­let opro­gra­mo­wa­nia), któ­re­go raczej się nie zmie­nia a używa.

Najciekawsze jest to, że opro­gra­mo­wa­nie słu­ży w głów­nej mie­rze do prze­twa­rza­nia danych. Coś daje­my na wej­ściu i cze­goś ocze­ku­je­my. Co tu jest istot­ne? Opis tego co jest prze­twa­rza­ne ale przede wszyst­kim regu­ły tego prze­twa­rza­nia! Przypadek uży­cia, popraw­nie opi­sa­ny, to tak­że dane wej­ścio­we i dane wyj­ścio­we, ale gdzieś powin­no być napi­sa­ne ​„jak”?

Na powyż­szym dia­gra­mie kolo­rem zie­lo­nym ozna­czo­no tak zwa­ny model dzie­dzi­ny (Model z wzor­ca MVC). To miej­sce, w któ­rym opro­gra­mo­wa­nie ​„prze­twa­rza”. To tu tkwi ​„sed­no wyma­gań”. Co cie­ka­we, popraw­nie (zno­wu dobre prak­ty­ki) zapro­jek­to­wa­ne opro­gra­mo­wa­nie całą logi­kę i przy­pad­ki uży­cia reali­zu­je wła­śnie w tym kom­po­nen­cie. Reszta to tyl­ko pozba­wio­ne logi­ki biz­ne­so­wej (tak, tu ich nie powin­no być) inter­fej­sy (użyt­kow­ni­ka i komunikacyjny).

Więc np. wyma­ga­nie ​„sys­tem powi­nien pozwa­lać na budo­wa­nie dowol­nych raba­tów sprze­da­ży do sta­łych klien­tów” (tak­że cytat z pew­nej spe­cy­fi­ka­cji sys­te­mu CRM) jest pustym stwier­dze­niem. Po pierw­sze jak te raba­ty są nali­cza­ne, po dru­gie czy aby na pew­no mecha­nizm pozwa­la na ​„dowol­ne raba­ty”… Jak to opi­sać? Tu powin­ny się poja­wić np. tabli­ce decy­zyj­ne a nie lako­nicz­ne ​„dowol­ne rabaty”.

Na zakoń­cze­nie uwa­ga: jeże­li pla­nu­je­my kupić goto­we opro­gra­mo­wa­nie, to ono już (gdzieś tam) ist­nie­je, i spe­cy­fi­ko­wa­nie szcze­gó­łów opi­su­ją­cych dokład­nie ele­men­ty pra­cy z inter­fej­sem użyt­kow­ni­ka i enig­ma­tycz­ne opi­sy tego jak ​„sys­tem liczy”, jest bez­war­to­ścio­we. Raczej wywo­ła listę tak zwa­nych kasto­mi­za­cji (zwa­nych gdzie­nie­gdzie zabój­ca­mi pro­jek­tów :)). Tak jed­nak wła­śnie wyglą­da­ją naj­czę­ściej spe­cy­fi­ka­cje pisa­ne ręka­mi przy­szłych użyt­kow­ni­ków: opi­szą oni to z czym się sty­ka­ją i co zna­ją ale w ogó­le nie opi­szą wnę­trza, któ­re­go naj­czę­ściej po pro­tu nie rozu­mie­ją (i nie muszą bo to nie ich rola), wte­dy spe­cy­fi­ka­cje sys­te­mów CRM pisa­ne ręka­mi przy­szłych użyt­kow­ni­ków – np. sprze­daw­ców – zawie­ra­ją wła­śnie bez­war­to­ścio­we zapi­sy w rodza­ju: ​„sys­tem powi­nien pozwa­lać na budo­wa­nie dowol­nych raba­tów sprze­da­ży do sta­łych klien­tów” a nie zawie­ra­ją opi­su jak te raba­ty wyliczać.

Odpowiadając na tytu­ło­we pyta­nie: wyma­ga­nia (funk­cjo­nal­ne) reali­zu­ją się w mode­lu dzie­dzi­ny sys­te­mu, któ­re­go nie zawie­ra więk­szość zna­nych spe­cy­fi­ka­cji wyma­gań… a warun­kiem popraw­ne­go wybo­ru opro­gra­mo­wa­nia są ocze­ki­wa­nia co do efek­tów przetwarzania.

Słowa kluczowe: , , , , , , ,

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).

Ten post ma 8 komentarzy

  1. polojan 6 lutego 2013 Odpowiedz

    Przed lek­tu­rą tego arty­ku­łu myśla­łem, że dobrym podej­ściem pod­czas ana­li­zy jest pre­cy­zyj­ne okre­śle­nie celów, czy­li, posłu­gu­jąc się Pana przy­kła­dem, ​„sys­tem ma pozwo­lić na budowanie/obsługę dowol­nych raba­tów dla sta­łych klien­tów”. Fakt – może to rze­czy­wi­ście zbyt ogól­ne stwier­dze­nie, ale już ​„sys­tem ma umoż­li­wić nali­cze­nie dowol­nej war­to­ści raba­tu pod­czas sprze­da­ży towa­rów do sta­łych klien­tów” już jest bli­skie praw­dy. Pana wcze­śniej­sze arty­ku­ły jasno i wyraź­nie nawo­ły­wa­ły do uni­ka­nia iden­ty­fi­ka­cji szcze­gó­łów roz­wią­zań na pozio­mie ana­li­zy. Tutaj rap­tem Pan pisze o budo­wa­niu tabel decy­zyj­nych (któ­re i tak w mojej opi­nii nie pozwo­li­ły­by na opi­sa­nie wszyst­kich warian­tów mate­ma­tycz­nych nali­cza­nia raba­tów w pro­ce­sie sprze­da­ży) i opi­sy­wa­niu ato­mo­wych szczegółów.
    No i teraz pyta­nie: jak powin­no być?
    Czy opi­sać cel, któ­rym jest umoż­li­wie­nie obsłu­że­nia w sys­te­mie dowol­nej kon­fi­gu­ra­cji raba­tów pod­czas sprze­da­ży (przy zało­że­niu, że są one tak napraw­dę poli­czal­ne i skoń­czo­ne, przy­naj­mniej te zdroworozsądkowe).
    Czy żmud­nie opi­sy­wać wszyst­kie moż­li­we kon­fi­gu­ra­cje raba­tów (wraz z ich akcep­ta­cja­mi, prze­dzia­ła­mi kwo­to­wy­mi itp, itd.)? Czy uda­ło się Panu kie­dyś spo­rzą­dzić taką tabe­lę, po lek­tu­rze któ­rej klient powie­dział ​„super, uwzględ­nił Pan wszyst­kie moż­li­we przypadki :)”?

    A może od cze­goś zale­ży dobór ziar­na ana­li­zy? Jeżeli tak, pro­szę o wska­za­nie drogi 🙂

    1. Jarek Żeliński 6 lutego 2013

      Jak powin­no być?
      – jeże­li w pla­nie jest zakup goto­we­go opro­gra­mo­wa­nia to nie ma sen­su zbyt szcze­gó­ło­we jego opi­sy­wa­nie bo szu­ka­my gotow­ca a nie projektujemy,
      – jeże­li pla­nu­je­my zle­ce­nie wyko­na­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia musi­my bar­dzo dokład­nie wyspe­cy­fi­ko­wać co i jak ma ono robić – tu projektujemy.

      I teraz wstęp­ne wyma­ga­nia powin­ny być ogól­ne ale bar­dzo dokład­nie musi­my wyko­nać ana­li­zę biz­ne­so­wą: musi­my wie­dzieć czy ów sys­tem raba­to­wy budu­je naszą prze­wa­gę na ryn­ku czy nie. Jeżeli nie, to dosto­so­wu­je­my się do tego co ofe­ru­je zna­le­zio­ne goto­we opro­gra­mo­wa­nie. Jeżeli tak, spe­cy­fi­ku­je­my dokład­nie nasze fir­mo­we know-how i zama­wia­my w tym obsza­rze dedy­ko­wa­ne oprogramowanie. 

      Faktem jest, że pomi­ną­łem w tym arty­ku­le waż­ny wcze­śniej­szy etap: ana­li­za moty­wa­cji biz­ne­so­wej. Do póki nie wiem czy sys­tem raba­tów jest dla nas waż­ny, nie ma dobrej odpo­wie­dzi na pyta­nie czy i jak szcze­gó­ło­wo go opi­sać. Tu chy­ba tkwi to ​„ziar­no analizy”.

      Innymi sło­wy celem biz­ne­so­wym może być ​„nagra­dza­nie klien­tów jaki­miś raba­ta­mi” i nie ma pro­ble­mu, albo celem może być ​„nasz kon­kret­ny super sys­tem raba­to­wy” i to są dwa róż­ne projekty.

      Podałem ten przy­kład, bo fir­my czę­sto trak­tu­ją raba­ty bar­dzo ​„oso­bi­ście” a bar­dzo ogól­nie je opi­su­ją w wymaganiach… 

  2. polojan 6 lutego 2013 Odpowiedz

    Dziękuję za odpowiedź.
    Rzadko bywa chy­ba jed­nak tak, żeby klient chciał kupić COTSa. Jest to zni­ko­my odse­tek pro­jek­tów (poza tym co to za pro­jekt…:)). W dal­szym cią­gu nie zgo­dzę się z Pana stwier­dze­niem, że w przy­pad­ku zaku­pu dedy­ko­wa­ne­go softu, nale­ży bar­dzo szcze­gó­ło­wo wyspe­cy­fi­ko­wać spo­sób reali­za­cji wyma­gań w sys­te­mie. Pamiętam poda­wa­ne przez Pana przy­kła­dy leka­rza, któ­re­go cho­ry nie pyta w jaki spo­sób będzie ope­ro­wał skal­pe­lem albo pro­du­cen­ta samo­cho­dów, któ­re­go klient nie będzie pytał w jaki spo­sób będzie mon­to­wa­ny drą­żek skrzy­ni bie­gów (nawet przy dro­gich pro­duk­cjach na zamó­wie­nie). Zarówno lekarz jak i pro­du­cent samo­cho­du mają zapew­nić swo­imi pro­duk­ta­mi reali­za­cję zało­żo­nych celów.

    Odnośnie ana­li­zy moty­wa­cji biz­ne­so­wej, to widzę tu trud­ność w okre­śle­niu prio­ry­te­tów (chy­ba, że prio­ry­tet raba­tów jest usta­la­ny przez jed­nost­kę nie korzy­sta­ją­cą z raba­tów – w każ­dym innym przy­pad­ku to czy­sto umow­na oce­na). Jeżeli nawet uda­ło­by się to zro­bić, to chce Pan powie­dzieć, że mniej waż­ne ele­men­ty powin­ny zostać opi­sa­ne ogól­nie, a te waż­niej­sze bar­dzo szcze­gó­ło­wo? Nie jestem prze­ko­na­ny, czy to słusz­ne podejście.

    A pro­pos Pana przy­kła­du, czy widział Pan/sporządził Pan kie­dyś kom­plet­ny opis poli­ty­ki raba­to­wej dla jakiej­kol­wiek firmy?

    1. Jarek Żeliński 6 lutego 2013

      Co do COTS, to jest to ponad 80% wszyst­kich sprze­da­nych sys­te­mów IT na rynku :).

      Oprogramowanie dedy­ko­wa­ne. Nie zapo­mi­naj­my o dwóch odręb­nych rze­czach: pro­jek­to­wa­nie ​„kon­struk­cji” to pra­ca deve­lo­pe­ra ale logi­ka biz­ne­so­wa to biz­nes. Nie ma sen­su by zama­wia­ją­cy ​„roz­wią­zy­wał” pro­ble­my tech­nicz­ne i tu fak­tycz­nie wystar­czy napi­sać, że opro­gra­mo­wa­nie ma być szyb­kie, wygod­ne, dostęp­ne przez sieć, i cała masa ele­men­tów leżą­cych w gestii deve­lo­pe­ra. Ale, np. ​„wzór na wyli­cze­nie podat­ku VAT” to coś za co deve­lo­per nie może odpo­wia­dać (ana­li­tyk biz­ne­so­wy tak), to musi dostać pro­gra­mi­sta ​„na tacy” na tyle szcze­gó­ło­wo i jed­no­znacz­nie by nie było moż­li­wo­ści pomył­ki i by było moż­li­we do testowania. 

      Oprogramowanie, podob­nie jak np. budow­lan­ka, to dzie­dzi­na tech­nicz­na. Zamawiając dom nie ma sen­su bym dyk­to­wał archi­tek­to­wi szcze­gó­ły kon­struk­cji stro­pu i ścian, wystar­czy że podam pla­no­wa­ne obcią­że­nie stro­pu, ale ma głę­bo­ki sens poda­nie kolo­ru ścian w posta­ci nume­ru far­by z kata­lo­gu, bo to gwa­ran­tu­je mi, że dosta­ne ​„to cze­go chcę”. Jak zamiesz­kam, kon­struk­cja ścian być może będzie dla mnie tajem­ni­cą do koń­ca życia ale na kolo­ry będę się gapił codziennie.

      Dajmy na to, z ana­li­zy biz­ne­so­wej dla sys­te­mu CRM wyni­ka, że rejestr klien­tów i notat­ki ze spo­tkań są waż­ne ale ich postać nie jest kry­tycz­na. Tu spo­koj­nie wystar­czy ogól­nie opi­sa­ne wyma­ga­nie w rodza­ju: ​„moż­li­wość noto­wa­nia tre­ści spo­tkań z klien­tem wraz z ter­mi­nem począt­ku i koń­ca oraz miej­scem spo­tka­nia”. Jeżeli jed­nak fir­ma zdo­by­wa swo­ich nowych klien­tów, odbie­ra ich kon­ku­ren­tom, bar­dzo atrak­cyj­nym sys­te­mem raba­tów z tytu­łu pro­mo­cji i pro­gra­mów lojal­no­ścio­wych, to musi to opi­sać jed­no­znacz­nie bo deve­lo­per nie ma pra­wa nic tu mie­szać ani two­rzyć po swo­je­mu, to jest klu­czo­wy wymóg biznesowy.

      Na ostat­nie pyta­nie odpo­wiem tak: robię to wła­śnie już trze­ci raz.

    2. jokoz 11 lutego 2013

      Z wła­sne­go doświad­cze­nia wiem, że im opro­gra­mo­wa­nie jest bar­dziej dedy­ko­wa­ne, tym zama­wia­ją­cy czę­ściej są skłon­ni pod­rzu­cać przy­pad­ki, któ­re nie­spo­dzie­wa­nie ​„przy­no­si życie”. A więk­szość z nich napraw­dę moż­na prze­wi­dzieć. Przy kasto­mi­za­cji komer­cyj­ne­go opro­gra­mo­wa­nia ape­tyt na mode­lo­wa­nie ​„po fak­cie” naj­czę­ściej ukró­ca­ją kosz­ty tej kasto­mi­za­cji. W przy­pad­ku dedy­ko­wa­nej twór­czo­ści brak dopre­cy­zo­wa­ne­go mode­lu, tablic decy­zyj­nych, czy przy­pad­ków uży­cia pro­wa­dzi nie­jed­no­krot­nie do kon­flik­tów i ostu­dze­nia weny twór­czej mogą­cych coś kon­ku­ren­cyj­ne­go na ryn­ku zapro­po­no­wać. W nie­stan­dar­do­wym pro­duk­cie wystar­czy pra­cy nad tym, co nie­stan­dar­do­we. Szkoda mar­no­wać cza­su na pomył­ki przy reali­za­cji stan­dar­do­wych pro­ce­sów. To powin­no być dobrze opi­sa­ne przez dobrze zna­ją­cych swo­ją pra­cę ​„rze­mieśl­ni­ków”, by nie mar­no­wać sił ​„wir­tu­ozów”, któ­rzy w tym cza­sie może odkry­li­by coś wyjątkowego.
      Oczywiście zali­czam się do ​„rze­mieśl­ni­ków” 🙂

  3. Jarek Żeliński 6 lutego 2013 Odpowiedz

    Ogólnie nie nie ma pro­stej odpo­wie­dzi na pyta­nie, kie­dy istot­ne są szcze­gó­ły i któ­re. To zawsze zale­ży od tego w jakim celu opro­gra­mo­wa­nie jest kupo­wa­ne oraz od tego do cze­go zama­wia­ją­ce­mu ono posłu­ży. Jeżeli kupo­wa­ny jest sys­tem ERP/CRM itp. ​„taki jaki ma każ­dy inny” bo bez tego trud­no funk­cjo­no­wać, to wyma­ga­nia opi­su­je­my poprzez defi­nio­wa­ne celu jego zakupu. 

    Jeżeli jed­nak nasza spe­cy­fi­ka pole­ga na reali­zo­wa­niu spe­cy­ficz­nych zadań w spe­cy­ficz­nych spo­sób i za pomo­cą spe­cy­ficz­nych tre­ści, to ta spe­cy­fi­ka musi być dogłęb­nie zro­zu­mie­nia i wręcz algo­ryt­micz­nie udokumentowana. 

    To dla­te­go tak waż­na jest ana­li­za biz­ne­so­wa poprze­dza­ją­ca spe­cy­fi­ko­wa­nie wymagań…i nie raz doku­men­to­wa­nie wręcz algo­ryt­mów doko­ny­wa­nych prze­kształ­ceń danych.

    1. polojan 7 lutego 2013

      Pozostanę z tą refleksją…

      Dziękuję za odpowiedzi.

Dodaj komentarz

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