Wprowadzenie

Zarówno w pro­jek­tach jak i w dys­ku­sjach np. na kon­fe­ren­cjach czy na LinkedIn, poja­wia się sta­le pew­ne nie­po­ro­zu­mie­nie: pro­jek­to­wa­nie to water­fall”. Myśli tak każ­dy, kto wyobra­ża sobie, że pro­jekt cze­goś to jakaś masa wszyst­kich moż­li­wych deta­li. Jednocześnie nie ja jeden widu­ję Dokumenty ana­li­zy biz­ne­so­wej” albo Dokumenty wyma­gań” zawie­ra­ją­ce set­ki pozy­cji o tre­ści sys­tem powi­nien…”, nie raz wyko­na­ne przez kry­ty­ków water fall”, któ­rzy repre­zen­tu­jąc deve­lo­pe­ra dekla­ru­ją­ce­go meto­dy agi­le”, zabez­pie­cza­ją się” przez odpo­wie­dzial­no­ścią za zakres projektu. 

Pierwsza waż­na uwa­ga: pro­jekt sys­te­mu to nie jest ani zestaw dzie­siąt­ków user sto­ry” ani deta­licz­na doku­men­ta­cja powy­ko­naw­cza! I o tym dzi­siaj będzie: abs­tra­ho­wa­nie od deta­li i jed­nak nadal zarzą­dza­nie logi­ką całości.

Poniżej wyma­ga­nie napi­sa­ne przez dział IT jed­ne­go z moich klientów:

1. System musi posia­dać wbu­do­wa­ne­go klien­ta pocz­ty elek­tro­nicz­nej obsłu­gu­ją­ce­go co naj­mniej pro­to­ko­ły IMAP i SMTP.
2. Wbudowany klient pocz­ty elek­tro­nicz­nej posia­da nastę­pu­ją­ce funkcje:
2.1. Utwórz wia­do­mość ? umoż­li­wia utwo­rze­nie nowej wiadomości,
2.2. Odpowiedz ? umoż­li­wia udzie­le­nie odpo­wie­dzi nadaw­cy wraz z cyto­wa­niem i ozna­cze­nie cyto­wa­ne­go tek­stu napi­sa­ne­go przez nadawcę,
2.3. Odpowiedz wszyst­kim ? umoż­li­wia udzie­le­nie odpo­wie­dzi nadaw­cy oraz z prze­sła­niem jej na pozo­sta­łe adre­sy ema­il wymie­nio­ne w polu Do, Do wia­do­mo­ści oraz Ukryty do wia­do­mo­ści wraz z cyto­wa­niem i ozna­cze­nie cyto­wa­ne­go tek­stu napi­sa­ne­go przez nadawcę,
2.4. Prześlij dalej ? umoż­li­wia prze­sła­nie pocz­ty elek­tro­nicz­nej kolej­ne­mu odbiorcy,
2.5. Przenieś ? umoż­li­wia prze­no­sze­nie pocz­ty elek­tro­nicz­nej pomię­dzy fol­de­ra­mi na wybra­nym koncie,
2.6. Drukuj ? umoż­li­wia wydru­ko­wa­nie pocz­ty elektronicznej,
2.7. Dołącz ? umoż­li­wia dołą­cze­nie pocz­ty elek­tro­nicz­nej do spra­wy lub dokumentu,
2.8. Odbierz ? umoż­li­wia ręcz­ne ode­bra­nie pocz­ty elektronicznej,
2.9. Usuń ? umoż­li­wia usu­nię­cie wybra­nej pocz­ty elektronicznej,
2.10. Znajdź ? umoż­li­wia wyszu­ka­nie listu w fol­de­rach pocz­ty elektronicznej,
2.11. Rejestruj ? umoż­li­wia reje­stra­cję pocz­ty elek­tro­nicz­nej jako doku­men­tu w sys­te­mie w spo­sób ana­lo­gicz­ny do reje­stra­cji doku­men­tu zeskanowanego.
3. System musi udo­stęp­niać moż­li­wość kon­fi­gu­ra­cji kon­ta pocz­ty elek­tro­nicz­nej każ­de­mu użytkownikowi.
4. System zapew­nia moż­li­wość kon­fi­gu­ra­cji wie­lu kont pocz­ty elek­tro­nicz­nej dla każ­de­go użytkownika.
5. System musi umoż­li­wiać reje­stra­cję (przej­mo­wa­nie) pocz­ty elek­tro­nicz­nej przez użyt­kow­ni­ka, lub poprzez zde­fi­nio­wa­ną regu­łę (uwzględ­nia­ją­cą zapi­sa­ne­go wcze­śniej adre­sa­ta, oraz cią­głość kore­spon­den­cji w spra­wie), jako doku­men­tów w sys­te­mie z podzia­łem na treść, załącz­ni­ki i nagłówek.
6. W celu ogra­ni­cze­nia zbęd­nej dupli­ka­cji, nie­prze­ję­te maile muszą być odczy­ty­wa­ne z ser­we­ra pocz­to­we­go tyl­ko na żąda­nie użyt­kow­ni­ka (dostęp­ny listing nagłów­ków wia­do­mo­ści) i nie powin­ny być dodat­ko­wo prze­cho­wy­wa­ne w Systemie.
7. Dotyczy to rów­nież pocz­ty wysy­ła­nej przez klienta.
8. System musi umoż­li­wiać dołą­cza­nie pocz­ty elek­tro­nicz­nej do doku­men­tów lub spraw. Dołączenie musi być moż­li­we z pozio­mu klien­ta pocz­ty elek­tro­nicz­nej wbu­do­wa­ne­go w system.
Powyżej wyma­ga­nia spi­sa­ne przez oso­bę A

Inna oso­ba z tego same­go dzia­łu dodała:

1. Chcemy mieć klien­ta pocz­to­we­go w sys­te­mie, jest to wygod­ne rozwiązanie.
2. Chcemy aby klient pocz­to­wy miał moż­li­wość odczy­ta­nia i wysła­nia wia­do­mo­ści pocztowej.
3. Nie chce­my żeby EOD gro­ma­dzi­ło wszyst­kie wia­do­mo­ści syn­chro­ni­zo­wa­ne z ser­we­rem pocz­to­wym pro­to­ko­łem IMAP, a tyl­ko pobie­ra­ło nagłów­ki wiadomości.
4. Gdy użyt­kow­nik uzna, że wia­do­mość jest czę­ścią spra­wy ini­cju­je czyn­no­ści w EOD.
Powyżej wyma­ga­nia spi­sa­ne przez oso­bę B.

Świadomie poda­je źró­dło: dział IT tej instytucji.

Opublikowałem tyl­ko powyż­sze, bo resz­ta po ano­ni­mi­za­cji i tak była by pustą kart­ką (nie­ste­ty ten OPZ uka­że się dopie­ro za jakiś czas, a do tego momen­tu jest pouf­ny), ale mam nadzie­ję, że wyobra­że­nie sobie resz­ty jest dość pro­ste. I co z tym? Nic! Otóż nie jest pro­ble­mem taka for­ma wyra­że­nia wyma­gań przez Zamawiającego, bo on (biz­nes i nie tyl­ko jak widać) ina­czej nie potra­fi i nie jest to jego rola. Problemem jest uzna­nie tego za wyma­ga­nia wobec opro­gra­mo­wa­nia”. Powyższe jest raczej dopie­ro mate­ria­łem do ana­li­zy i projektowania. 

Wyobraźmy sobie teraz hipo­te­tycz­ny doku­ment wyni­ko­wy, czy­li kil­ku­na­stu (a może nawet kil­ku­dzie­się­ciu) nie­tech­nicz­nych pra­cow­ni­ków tej insty­tu­cji (księ­go­wość, admi­ni­stra­cja, itp.) z pomo­cą ana­li­ty­ka wyma­gań”, zebra­ło wyma­ga­nia, i pra­cu­jąc z edy­to­rem tek­stu w try­bie reje­stra­cji zmian, warsz­ta­to­wo, po iluś tam tygo­dniach wypra­co­wa­ło” osta­tecz­ną wer­sję wyma­gań” a potem nawet dzie­siąt­ki user sto­ry”. Ile stron będzie mia­ła taka Analiza Biznesowa Wymagań i co w niej będzie? 

Przykłady łatwo zna­leźć w Internecie:

przy­kład 1 (źr. https://​zamo​wie​nia​.mazo​via​.pl/​?​a​c​t​=​i​n​f​o​&​i​d​=​1​2​001):

Powyższe opra­co­wa­nie kosz­to­wa­ło 90 tys. zł. 

przy­kład 2 (źr. https://​plat​for​ma​za​ku​po​wa​.pl/​t​r​a​n​s​a​k​c​j​a​/​3​6​1​167):

Rozwiązanie

Od cza­su do cza­su przy­wo­łu­je tu na blo­gu podej­ście zwa­ne Model jako wyma­ga­nie” (popu­lar­ne skró­ty to: MDD – Model Driven Development, MBSE – Model Based System Engineering, MDSE – Model Driven System Engineering, o MBSE już pisa­łem ).

Kluczem są mode­le struk­tur tre­ści (doku­men­tów i ekra­nów GUI) . Powyższe życze­nia” jako spi­sa­ne wyma­ga­nia to (w peł­nej wer­sji) ogrom­na lista życzeń, nie pod­da­ją­ca się żad­nej kon­tro­li spój­no­ści i kom­plet­no­ści. Proszę podej­rzeć wska­za­ne wyżej przy­kła­dy, doku­men­ty na ponad 200 stron nie pod­da­ją­ce się żad­nej kon­tro­li… (pomi­jam, że wadli­we for­mal­nie, jeśli cho­dzi o uży­cie deka­ro­wa­nej notacji). 

Poniżej zamien­nik wyłącz­nie powyż­sze­go o poczcie elek­tro­nicz­nej, wyra­żo­ny mode­lem struk­tu­ry tre­ści. Jaką ma to zale­tę? Tę, że mamy zamknię­tą struk­tu­rę tre­ści i może­my ją mapo­wać na inne doku­men­ty (ich sza­blo­ny w pro­jek­cie) w celi wery­fi­ka­cji logi­ki spójności. 

Zakresy danych nie reali­zu­ją­ce logi­ki biz­ne­so­wej (i mało ryzy­kow­ne jeśli cho­dzi o pra­co­chłon­ność) moż­na mar­ko­wać z dokład­no­ścią do roli dane­go zesta­wu danych (poni­żej obsza­ry ozna­czo­ne linia prze­ry­wa­ną). Zgodnie z defi­ni­cją, sys­te­my infor­ma­cyj­ne prze­twa­rza­ją dane, więc dowol­ny sys­tem infor­ma­cyj­ny jest spro­wa­dzal­ny do skoń­czo­nej licz­by infor­ma­cji wyra­ża­nej jako doku­ment gru­pu­ją­cy okre­ślo­ne dane i reguł ich prze­twa­rza­nia . Rzecz w tym, że nie jest to baza danych i rela­cyj­ny model” (nie­ste­ty mono­lit moż­li­wy do wypra­co­wa­nia meto­dą water­fall), a odręb­ne doku­men­ty i ich struk­tu­ry (oraz słow­ni­ki zna­czeń uży­tych nazw). Każdy z nich może być pod­sta­wą opra­co­wa­nia odręb­ne­go, moż­li­we­go do samo­dziel­ne­go wyko­na­nia, modułu. 

Warto wie­dzieć, że:

Model rela­cyj­ny danych: zapi­sy­wa­nie ich w posta­ci współ­dzie­lo­nych znor­ma­li­zo­wa­nych struk­tur poję­cio­wych, pozba­wio­nych redun­dan­cji, jest pozba­wio­ny kon­tek­stu , nie spraw­dza się w sys­te­mach zarzą­dza­ją­cych doku­men­ta­mi. Dokument, tak­że w sen­sie praw­nym, nie może być gene­ro­wa­ną dyna­micz­nie (zapy­ta­nia SQL do bazy rela­cyj­nej) struk­tu­rą, bo jest wte­dy wir­tu­al­nym bytem, a taki nie sta­no­wi doku­men­tu w pra­wie (Kodeks Cywilny), nie da się tak­że zarzą­dzać jego cyklem życia. Dlatego doku­men­ty są coraz czę­ściej wyra­ża­ne jako struk­tu­ry XML/XSD i uzu­peł­nia­ne posta­cią ??do czy­ta­nia i dru­ku? w for­ma­cie pdf (real­nie sa to pli­ki pdf z załą­czo­ny­mi wer­sja­mi XML. (źr. Informacje dla korzy­sta­ją­cych z moich opra­co­wań – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Poniżej pro­sty model listy ode­bra­nych maili”:

Wymagania doty­czą­ce pra­cy z pocz­ta elek­tro­nicz­ną obra­zu­je ten oto – wery­fi­ko­wal­ny – model struk­tu­ry tre­ści otrzy­ma­nej mailem:

Aby poka­zać jak to dzia­ła” pisze­my sce­na­riusz (spe­cy­fi­ka­cja przy­pad­ku uży­cia) sta­no­wią­cy kon­tekst uży­cia tego doku­men­tu (for­mu­la­rza). Służy on tak­że jako test pro­jek­to­wa­nej logi­ki, a póź­niej jako test odbior­czy goto­we­go produktu: 

1. Pracownik wybie­ra opcję Poczta Elektroniczna
2. SYSTEM wyświe­tla Lista prze­sy­łek ema­il dla zalo­go­wa­ne­go użytkownika
3. Pracownik kli­ka wybra­na pozy­cje na liście ,
4. SYSTEM wyświe­tla Treść Poczty Elektronicznej
5. Pracownik dekre­tu­je ją lub ozna­cza do usu­nię­cia OK
6. if dekretacja
6.1. wska­za­nie punk­tu kan­ce­la­ryj­ne­go i OK
7. else if usuń
end if 
8. SYSTEM sys­tem potwier­dza operacje

W tym momen­cie będę koń­czył, bo kon­ty­nu­ację czy­tel­nik znaj­dzie w jed­nym z wcze­śniej­szych arty­ku­łów, frag­ment poniżej: 

Pełna doku­men­ta­cja powin­na zawie­rać w załą­cze­niu deta­licz­ne struk­tu­ry tych for­mu­la­rzy (dia­gra­my przed­sta­wia­ją­ce struk­tu­ry XML, lub sko­men­to­wa­ne mock-up?y doku­men­tów). Taka spe­cy­fi­ka­cja zawie­ra wszyst­kie infor­ma­cje pozwa­la­ją­ce deve­lo­pe­ro­wi stwo­rzyć opro­gra­mo­wa­nie słu­żą­ce do zbie­ra­nia i zarzą­dza­nia infor­ma­cją. Jako model wyma­gań na sys­te­my typu EOD jest wystar­cza­ją­ca. Gdyby było praw­dą, że wyma­ga­my od opro­gra­mo­wa­nia tak­że, by zawar­tość wybra­nych pól tych for­mu­la­rzy była wyli­cza­na lub wery­fi­ko­wa­na, musi­my dodat­ko­wo udo­ku­men­to­wać zależ­no­ści mię­dzy tymi pola­mi. Model taki czę­sto war­to uzu­peł­nić wyma­ga­ną archi­tek­tu­rą opro­gra­mo­wa­nia, bo od niej zale­żą cechy jako­ścio­we apli­ka­cji, tak zwa­ne poza­funk­cjo­nal­ne. Będzie to wła­śnie model dzie­dzi­ny sys­te­mu, opi­sy­wa­ny na moim blo­gu wie­lo­krot­nie. (źr. Modele infor­ma­cyj­ne – Jarosław Żeliński IT-Consulting – Systemy Informacyjne).

Źródła

Šilingas, D., & Butleris, R. (2009). Towards imple­men­ting a fra­me­work for mode­ling softwa­re requ­ire­ments in MagicDraw UML. Information Technology and Control, 38(2).
Paredaens, J., Bra, P. D., Gyssens, M., & Gucht, D. van. (2012). The Structure of the Relational Database Model. Springer Science & Business Media.

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.

Ten post ma 11 komentarzy

  1. Domoky

    Trzeba robić events stor­ming. Najlepiej niech pro­wa­dzi softwa­re engineer/architekt.

    1. Jarosław Żeliński

      To wła­śnie był (poprzed­nia przy­miar­ka do wyma­gań) efekt events stor­ming”, stek bez­ład­nych pomy­słów któ­re były wyłącz­nie zbio­rem zda­rzeń z życia pra­cow­ni­ków”, to co poka­za­łem to efekt samo­dziel­nej pra­cy na bazie doku­men­tów. Zastąpienie listy życzeń co do pocz­ty ema­il, sza­blo­nem for­mu­la­rza i kil­ko­ma regu­ła­mi pozwo­li­ło wykryć wie­le nie­spój­no­ści, a doku­men­ta­cja mimo to zma­la­ła trzy­krot­nie, powstał w 60 dni, zawie­ra tak­że archi­tek­tu­rę całe­go sys­te­mu infor­ma­cji. Jak opu­bli­ku­ją prze­targ to wkle­ję link. 

      events stor­ming” pro­wa­dzo­ny przez deve­lo­pe­ra mają­ce­go 15 lat doświad­cze­nia w roli deve­lo­pe­ra, to było to po czym sprzątałem… 🙁

  2. Domoky

    No jeśli się przy­kle­ja kar­tecz­ki dla same­go przy­kle­ja­nia to fajnie.
    A co z okre­śle­niem domen/poddomen, mapą kontekstu?
    Architekturę to okre­śla się po design levelu…
    Zresztą jeśli ktoś nie pra­co­wał jako programista/software engineer/software archi­tect to cięż­ko to widzę. Niestety archi­tek­ci bez takie­go back­gro­un­du zosta­ją na eta­pie umla i dzid.

    1. Jarosław Żeliński

      Co to te dome­ny i pod­do­me­ny? Mapy Kontekstu? 

      Sprzątam po tym regu­lar­nie a ze stu­den­ta­mi ćwiczę:
      Karta wypożyczenia

  3. Domoky

    Domain Driven Design jak ktoś nie pisał kodu to nie poczu­je o co chodzi…

  4. Domoky

    Po pro­stu nie ma po co dzie­lić ludzi na ana­li­ty­ków oraz inży­nie­rów opro­gra­mo­wa­nia, sko­ro ten­den­cja poka­zu­je na ryn­ku że war­to skra­cać dystans pomię­dzy biz­ne­sem a inżynierami.
    Jeśli ktoś tyl­ko zaj­mu­ję się ana­li­zą nawet nie wie jak ma cza­sa­mi ogra­ni­czo­ne spojrzenie.
    Trzeba brać wie­le czynników:
    – Modularny sys­tem ( czym jest moduł jakie ma cechy)
    – Skalowalność
    – Niezawodność SLA
    – Łatwość na rozbudowę
    Zauważać wzor­ce (enter­pri­se patterns)
    Dużo by pisać przy­kład poda­ny przez Pana jest chy­ba tro­chę sztucz­ny jak to stu­den­ci coś pró­bo­wa­li zro­bić. Dwa nie ma cze­goś takie­go jak jed­no popraw­ne roz­wią­za­nie bo ich może być kil­ka. Zachęcam do wysłu­cha­nia pod­ca­stu Mariusza Gila z S. Sobótka gdzie roz­ma­wia­ją na temat wypo­ży­cze­nia ksią­żek w biblio­te­ce i roz­ma­wia­ją o gra­ni­cach agregatów.

    1. Jarosław Żeliński

      Tendencja na ryn­ku poka­zu­je, że ten podział nabie­ra rosną­ce­go zna­cze­nia, tak jak w każ­dej innej inży­nie­rii… Proponuję zacząć od oddzie­la­nia wyma­gań funk­cjo­nal­nych od poza­funk­cjo­nal­nych. Co inne­go to poli­cze­nie VAT na fak­tu­rze a co inne­go to licz­ba fak­tur wysta­wia­nych dzien­nie. Co inne­go to jak poli­czyć upust w księ­gar­ni inter­ne­to­wej a co inne­go to milio­ny kupu­ją­cych na stro­nie WWW. Sławka Sobotke znam osobiście…

      Jakość pra­cy oce­nia­ją pła­cą­cy i dotrzy­my­wa­ne terminy… 

  5. Domoky

    Co z tego że Pan zna. Mamy odmien­ne zda­nia, jed­nak patrzę z per­spek­ty­wy oso­by któ­ra nie tyl­ko musi zbie­rać wyma­ga­nia ale, tak­że prze­kła­dać je na kod.
    Wymagania funk­cjo­nal­ne i poza funk­cjo­nal­ne są oczy­wi­stym fak­tem, jed­nak oba trze­ba brać pod uwa­gę. Przypadki uży­cia nie nio­są ze sobą istot­nej wie­dzy, reguł biz­ne­so­wych. Dobry events stor­ming przy zło­żo­nych dome­nach jest naj­lep­szą wg.
    Mnie tech­ni­ką dla inży­nie­ra opro­gra­mo­wa­nia, któ­ry umie wyko­rzy­stać podej­ście DDD do imple­men­ta­cji systemów.
    Alberto Brandolini nie był ana­li­ty­kiem ale pro­gra­mi­stą i tutaj dam tro­chę cza­su do namysłu. 

    Pozdrawiam

    1. Jarosław Żeliński

      Powtórzę: o tym jaka meto­da jest lep­sza decy­du­je cał­ko­wi­ty koszt i ter­min odda­nia dzia­ła­ją­ce­go opro­gra­mo­wa­nia do użyt­ku… Zapewne fak­tycz­nie Alberto Brandolini nie był ana­li­ty­kiem ale pro­gra­mi­stą, i tutaj dam tro­chę cza­su do namysłu.

  6. Update: opi­sa­ne cyto­wa­ne opra­co­wa­nie OPZ dla urzę­du kosz­to­wa­ło 90 tys. zł. Ja za jed­ną trze­cią tej ceny (a mam dwa razy wyż­szą staw­kę dzien­ną) odda­ję pro­jekt systemu. 

Dodaj komentarz

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