Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]

Wymagania biznesowe – jak zbierać i dokumentować

Wprowadzenie

Ronald Ross, współ­au­tor stan­dar­du mode­lo­wa­nia reguł biz­ne­so­wych i biz­ne­so­we­go słow­ni­ka pojęć napi­sał nie­daw­no na swo­im pro­fi­lu LinkedIn:

People love sto­ries. Are user sto­ries help­ful in engi­ne­ering busi­ness solu­tions? Absolutely. Are you done with requ­ire­ments and solu­tion engi­ne­ering when you’ve wor­ked thro­ugh a set of user sto­ries? No. Not even clo­se!” [„Ludzie kocha­ją histo­rie. Czy histo­rie użyt­kow­ni­ków są pomoc­ne w two­rze­niu roz­wią­zań biz­ne­so­wych? Zdecydowanie tak. Czy skoń­czy­łeś z wyma­ga­nia­mi i inży­nie­rią roz­wią­za­nia, gdy już opra­co­wa­łeś zestaw histo­ry­jek użyt­kow­ni­ka? Nie. Nawet nie zbli­ży­łeś się do nich!”.]

(https://​www​.lin​ke​din​.com/​p​o​s​t​s​/​r​o​s​s​r​o​n​a​l​d​_​p​e​o​p​l​e​-​l​o​v​e​-​s​t​o​r​i​e​s​-​a​r​e​-​u​s​e​r​-​s​t​o​r​i​e​s​-​h​e​l​p​f​u​l​-​a​c​t​i​v​i​t​y​-​6​9​3​5​6​2​7​0​0​8​2​6​5​6​3​3​7​9​3​-​B​p​zb/)

Świat od dekad bory­ka się z jako­ścią i sku­tecz­no­ścią spe­cy­fi­ko­wa­nia wyma­gań na opro­gra­mo­wa­nie. OMG​.org opu­bli­ko­wa­ło stan­dard o nazwie MDA (ang. Model Driven Architecture ), któ­ry tak opi­su­je pro­ces two­rze­nia oprogramowania:

CIM -> PIM -> PSM

Są to odpo­wied­nio mode­le: Model Biznesowy (CIM: Computation Independent Model), Model Mechanizmu dzia­ła­nia (PIM: Platform-Independent Model, jest to model dzie­dzi­ny sys­te­mu wg. MVC) oraz Model Implementacji (PSM: Platform-Specific Model). Swego cza­su sze­rzej opi­sa­łem zależ­no­ści mię­dzy tymi mode­la­mi (czy­taj wię­cej o MDA).

CIM to model dzia­ła­nia orga­ni­za­cji: pro­ce­sy biz­ne­so­we i ich pro­duk­ty. Z uwa­gi na to, że obec­nie już nie rodzą się pro­jek­ty jed­no­ra­zo­wej infor­ma­ty­za­cji cało­ści orga­ni­za­cji, poja­wia się potrze­ba okre­śle­nia zakre­su pro­jek­tu, bo nie jest już nim cała orga­ni­za­cja. Model PIM to udo­ku­men­to­wa­ny mecha­nizm dzia­ła­nia sys­te­mu (opro­gra­mo­wa­nia), logi­ka jego dzia­ła­nia. Nie ma tu mowy o tym w jakiej tech­no­lo­gii powsta­nie, bo z zasa­dy mamy ich wie­le do wybo­ru, a wybór tech­no­lo­gii zale­ży od wie­lu poza-funk­cjo­nal­nych ogra­ni­czeń i wyma­gań. Technologia jest (powin­na być) kon­se­kwen­cją wybo­ru wyko­naw­cy i ten dopie­ro opra­cu­je model PSM, któ­ry w prak­ty­ce jest tak zwa­ną Koncepcją Wdrożenia, moż­na ją tak­że udo­ku­men­to­wać w nota­cji UML, ale na tym eta­pie powszech­na prak­ty­ką jest jedy­nie zapro­jek­to­wa­nie śro­do­wi­ska, zesta­wie­nie go i pra­ca od razu w kodzie.

Kluczowym pro­ble­mem jest przej­ście z CIM na PIM, czy­li jak udo­ku­men­to­wać zakres pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia i prze­kształ­cić go na wyma­ga­nia wobec tego oprogramowania?

CIM -> [zakres pro­jek­tu] -> PIM -> PSM

W meto­dach zwa­nych zwin­ny­mi, mode­le CIM i PIM są pomi­ja­ne. Typowym zaś narzę­dziem zbie­ra­nia wyma­gań” są tak zwa­ne histo­ryj­ki użyt­kow­ni­ka (user sto­ry). Problem w tym, że są one klu­czo­wym ryzy­kiem pro­jek­tów gdyż z regu­ły są nie­spój­ne i nie­kom­plet­ne jako wyma­ga­nia. Specyfikacja wyma­gań powin­na być: spój­na, kom­plet­na i nie­sprzecz­na. Opisanie zakre­su pro­jek­tu histo­ryj­ka­mi użyt­kow­ni­ka, nie mając mode­lu pro­ce­sów biz­ne­so­wych cało­ści (model CIM), jest pozba­wie­niem się narzę­dzia do wery­fi­ka­cji kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści takiej spe­cy­fi­ka­cji. Wszystkie wady (nie­kom­plet­ność, nie­spój­ność, sprzecz­no­ści) odkry­wa­ne są i usu­wa­ne (uzu­peł­nia­ne) dopie­ro na eta­pie wdra­ża­nia. Jest to pro­ces odkry­wa­nia wyma­gań w toku wdrożenia”. 

Historyjki użyt­kow­ni­ka jako lista potrzeb biz­ne­so­wych? Owszem! Historyjki użyt­kow­ni­ka jako wyma­ga­nia dla deve­lo­pe­ra? NIE! To tyl­ko mate­riał dla pro­jek­tan­ta, ponie­waż bar­dzo czę­sto jed­na i ta sama funk­cja sys­te­mu reali­zu­je wie­le róż­nych histo­rii użyt­kow­ni­ka. Implementacja per user sto­ry” pro­wa­dzi do bar­dzo kosz­tow­nych i nie­efek­tyw­nych roz­wią­zań (Opisywałem to na blo­gu: wpis pro­jekt Biblioteka, dwie histo­ryj­ki użyt­kow­ni­ka: chciał­bym wypo­ży­czyć książ­kę oraz chciał­bym zwró­cić książ­kę są reali­zo­wa­ne jed­ną usłu­gą apli­ka­cji: Karta Wypożyczenia, któ­ra zawie­ra rów­nież pole Data zwro­tu. Nadal spo­ty­kam pro­gra­mi­stów prze­ko­nu­ją­cych, że powin­ny to być dwa osob­ne ekra­ny – dwa przy­pad­ki uży­cia, czy­taj dwa razy wię­cej pra­cy kode­ra i dwa razy więk­szy koszt).

Czy można sformalizować proces zbierania historyjek użytkownika?

User Story to jed­no z naj­bar­dziej pro­ble­ma­tycz­nych narzę­dzi w meto­dach zwin­nych. Najczęściej zale­ca­na struk­tu­ra tych histo­ry­jek”, wraz z przykładami:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Na przy­kład:

Jako Administrator chcę otrzy­my­wać wia­do­mość e‑mail, gdy zosta­nie prze­sła­ny for­mu­larz kon­tak­to­wy, abym mógł na nie­go odpowiedzieć”

albo

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”;

Tak spi­sy­wa­ne wyma­ga­nia sta­no­wią ogrom­ny pro­blem z powo­du nie­rów­nej gra­da­cji, spro­wa­dza­nie ich do pozio­mu tak zwa­nych ato­mo­wych user sto­ry (dru­gi z powyż­szych przy­kła­dów) pro­wa­dzi do bar­dzo dużych liczb tych histo­ry­jek. Próba ich wery­fi­ka­cji (wali­da­cja user sto­ry) sta­je się co naj­mniej trud­nym zada­niem. Jakakolwiek wyce­na opro­gra­mo­wa­nia na bazie takich histo­ry­jek to wró­że­nie z fusów (więc deve­lo­pe­rzy moc­no zawy­ża­ją wyce­ny z uwa­gi na ryzy­ko utra­ty ren­tow­no­ści). Autorzy inne­go opra­co­wa­nia zauważają:

Rzeczywiście, przy oko­ło 800 US [User Story], hie­rar­chia była raczej trud­na do okre­śle­nia, a obraz sys­te­mu pod­czas pla­no­wa­nia był bar­dzo duży. Skalowalność jest więc zde­cy­do­wa­nie pro­ble­mem w pro­jek­tach zwin­nych, w któ­rych US są sła­by­mi arte­fak­ta­mi inży­nie­rii wyma­gań. Zdecydował się on [autor] na wpro­wa­dze­nie wzor­ca US: Jako [Użytkownik], chcę [Zadanie], aby [Cel]”, aby zde­fi­nio­wać hie­rar­chię w posta­ci Celu, Zadania i Użytkownika, ale bez powią­za­nia semantycznego.

Znam pro­jekt, w któ­rym licz­ba przy­pad­ków uży­cia, w pew­nym śred­niej tyl­ko wiel­ko­ści pro­jek­cie, szyb­ko się­gnę­ła czte­ry­stu. Wycena na ich pod­sta­wie poka­za­ła, że pla­no­wa­ny koszt wie­lo­krot­nie prze­kra­cza pla­no­wa­ny budżet. Ten pro­jekt zarzu­co­no, jed­nak wie­le tak wyce­nio­nych pro­jek­tów jest reali­zo­wa­nych, co daje obraz ska­li strat jakie przy­no­szą (zawy­żo­ny koszt to stra­ta). Powyżsi auto­rzy piszą na zakończenie:

Przyszłe pra­ce obej­mu­ją iden­ty­fi­ka­cję luk repre­zen­ta­cyj­nych, któ­re napo­ty­ka­ją prak­ty­cy w mode­lo­wa­niu US, oraz prze­gląd spo­so­bów, w jakie nasze ramy i [meto­da] GORE w ogó­le mogły­by roz­wią­zać te pro­ble­my. Równolegle oce­nia­na będzie rów­nież zdol­ność prak­ty­ków do sto­so­wa­nia pro­po­no­wa­nych ram zamiast zwy­kłych sza­blo­nów. Obecnie trwa­ją pra­ce nad narzę­dziem CASE (Computer Aided Software Engineering), któ­re zosta­nie wyko­rzy­sta­ne do wspar­cia eksperymentów.

Nie zna­la­złem wyni­ków dal­szych prac, więc podzie­lę się wyni­ka­mi swoich.

Gradacja User Story

Podstawowym pro­ble­mem z user sto­ry jest, moim zda­niem, brak stan­dar­du pozwa­la­ją­ce­go na zde­fi­nio­wa­nie ato­mo­wej histo­ryj­ki użyt­kow­ni­ka” czy­li pozio­mu, poni­żej któ­re­go nie dzie­li­my ich na mniej­sze. Jako audy­tor wie­lu doku­men­ta­cji (czę­sto w roli bie­głe­go) zauwa­ży­łem, że histo­ryj­ki użyt­kow­ni­ka są dopro­wa­dza­ne do pozio­mu poje­dyn­czych kro­ków sce­na­riu­szy przy­pad­ków uży­cia. Często też histo­ryj­ki użyt­kow­ni­ka utoż­sa­mia­ne są z przy­pad­ka­mi uży­cia (UML) i tak mode­lo­wa­ne, co jest poważ­nym błę­dem. Np. powyższe: 

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”

Mogło by to być czę­ścią sce­na­riu­sza usłu­gi (przy­pa­dek uży­cia UML), któ­rej celem jest Pokazanie Określonego Miejsca:

  1. AKTOR ini­cju­je usłu­gę Cel podróży
  2. SYSTEM wyświe­tla for­mu­larz Adres
  3. AKTOR wpro­wa­dza dane i naci­ska OK
  4. SYSTEM wyświe­tla mapę z nanie­sio­ną lokalizacją
  5. AKTOR kli­ka okre­ślo­ny punkt na mapie 
  6. SYSTEM powięk­sza obraz poka­zu­jąc deta­le lokalizacji

Powyższa histo­ryj­ka to jedy­nie punkt 5. tego sce­na­riu­sza. Nie trud­no dojść do wnio­sku, że samo klik­nię­cie na mapie to pozba­wio­na kon­tek­stu i celu, wyrwa­na pro­sta czyn­ność, i jej samo­dziel­ne ist­nie­nie w spe­cy­fi­ka­cji jako osob­ny byt, pozba­wio­ne jest sen­su. Z per­spek­ty­wy opro­gra­mo­wa­nia powsta­ją­ce­go w okre­ślo­nym celu, uzna­nie tej histo­ryj­ki za samo­dziel­ne wyma­ga­nie nie ma uza­sad­nie­nia. Uznanie jed­nak, że apli­ka­cja słu­ży mię­dzy inny­mi do zapo­zna­wa­nia się okre­ślo­ny­mi miej­sca­mi w prze­strze­ni, a usłu­gą tej apli­ka­cji jest Pokazanie Określonego Miejsca jak naj­bar­dziej ma sens. Idąc za suge­stią by histo­ryj­ka użyt­kow­ni­ka mia­ła strukturę: 

Jako [Użytkownik], chcę [Zadanie], aby [Cel]”

zmu­sza do zasta­no­wie­nia się czy kli­ka­nie na mapie jest celem, czy może jed­nak tym celem jest Pokazanie Określonego Miejsca, a kli­ka­nie jest ele­men­tem sce­na­riu­sza (pro­ce­du­ry) reali­za­cji tego celu (pamię­ta­my, że przy­pad­ki uży­cia mają sce­na­riu­sze, a te zło­żo­ne są z sekwen­cji kolej­nych kroków!).

Formalizacja User Story

Pojęcia Użytkownik, Zadanie, Cel, jako spój­ny zestaw pojęć odpo­wia­da­ją defi­ni­cji ato­mo­we­go (ele­men­tar­ne­go) pro­ce­su w nota­cji BPMN (doda­tek C, Słownik , ): Aktywność jest sko­ja­rzo­na z jej wyko­naw­cą (pula, tor), two­rzy pro­dukt (data object). Biorąc pod uwa­gę fakt, że pro­dukt ma tu okre­ślo­ne­go adre­sa­ta i musi on sta­no­wić sobą war­tość dla tego adre­sa­ta, mamy punkt wyzna­cza­ją­cy gra­ni­cę dzie­le­nia na czę­ści” tych histo­ry­jek. Nie będzie to moż­li­wość wsta­wie­nia z listy nume­ru NIP nabyw­cy” a utwo­rze­nie fak­tu­ry” (bo war­tość ma dopie­ro popraw­nie wysta­wio­na fak­tu­ra, a nie klik­nię­cie np. w pole NIP by wybrać kontrahenta). 

Jak sfor­ma­li­zo­wać histo­ryj­kę użyt­kow­ni­ka? Podstawą for­ma­li­za­cji (i celem) jest opra­co­wa­nie meto­dy kon­tro­li popraw­no­ści (wali­da­cja). Popatrzmy jesz­cze raz na szablon:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Typ użyt­kow­ni­ka to rola, celem jest pro­dukt pra­cy, a powo­dem? Powodem jest zawsze to, że okre­ślo­na oso­ba ocze­ku­je na efekt tej pra­cy (bez tego pra­ca ta była­by po pro­stu zbęd­na). Można więc wyobra­zić sobie taki zapis:

Jako sprze­daw­ca, chcę wysta­wić fak­tu­rę, klientowi. 

Mamy tu:

  1. rola: sprze­daw­ca
  2. cel: fak­tu­ra
  3. powód: ocze­ku­je tego klient. 

W tym miej­scu widać peł­ną zgod­ność tej defi­ni­cji z kon­struk­cją: aktyw­ność, jej pro­dukt, jego odbior­ca. Innymi sło­wy ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych wyko­na­ny w nota­cji BPMN, to nic inne­go jak połą­czo­ne w logicz­ne cią­gi histo­ryj­ki użytkownika. 

Wyobraźmy sobie taką listę histo­ry­jek użyt­kow­ni­ka, wyko­na­ną wg. powyż­sze­go opisu:

Specyfikacja histo­ry­jek użytkownika

Niektóre narzę­dzia CASE, pozwa­la­ją­ce na ich pro­fi­lo­wa­nie, pozwa­la­ją przed­sta­wić to tak­że na mode­lu wyma­gań (co póź­niej umoż­li­wia śla­do­wa­nie, czy­li kon­tro­lę kom­plet­no­ści, spój­no­ści i niesprzeczności):

Diagram wyma­gań (nota­cja SysML)

Powyższe mogło­by być kon­se­kwen­cją takie­go mode­lu procesów:

Diagram pro­ce­su reali­za­cji zamó­wie­nia (nota­cja BPMN).

Jak widać, model pro­ce­su daje peł­ny kon­tekst dla aktyw­no­ści. Fakt, że pro­ces to logicz­ny prze­pływ pra­cy, powo­du­je, że two­rze­nie mode­li BPMN gwa­ran­tu­je spój­ność, kom­plet­ność i nie­sprzecz­ność listy aktyw­no­ści, ich pro­duk­tów i ról. 

Podsumowanie

Stosowanie typo­wych histo­ry­jek użyt­kow­ni­ka ma dwie klu­czo­we wady: 1. nie ma jed­nej meto­dy zarzą­dza­nia ich gra­da­cją i struk­tu­rą, wie­lu auto­rów przy­wo­łu­je wła­sne, nie­co się róż­nią­ce meto­dy stan­da­ry­za­cji, 2. ich dro­bia­zgo­wość oraz brak meto­dy kon­tro­li spój­no­ści, pro­wa­dzą do szyb­ko rosną­cej ich licz­by, w kon­se­kwen­cji cha­osu, szcze­gól­nie w śred­nich i więk­szych projektach.

Powyżej widać, że mode­lo­wa­nie pro­ce­sów biz­ne­so­wych na pod­sta­wie zebra­nych przy­kła­do­wych doku­men­tów (pro­duk­ty pra­cy ludzi: doku­men­ty) i opra­co­wa­nie na ich pod­sta­wie dia­gra­mu przy­pad­ków uży­cia, daje znacz­nie lep­sze wyni­ki niż zbie­ra­ne na warsz­ta­tach histo­ryj­ki użyt­kow­ni­ka. Same wyma­ga­nia wyra­żo­ne jako histo­ryj­ki użyt­kow­ni­ka, nie dają żad­nej szan­sy (brak meto­dy) na kon­tro­lę ich spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści. Wymagania, jako kon­se­kwen­cja popraw­nie wyko­na­nych mode­li pro­ce­sów biz­ne­so­wych, z zasa­dy są spój­ne, kom­plet­ne i niesprzeczne.

W przy­to­czo­nym tu przy­kła­dzie widać, że dwie aktyw­no­ści (reje­stra­cja zamó­wie­nia i kon­tro­la jego sta­tu­su) reali­zo­wa­ne są jako dostęp do zapi­sa­ne­go w sys­te­mie Zamówienia. Daje to jasną prze­słan­kę do tego, że dwie histo­ryj­ki użyt­kow­ni­ka (dwie aktyw­no­ści na mode­lu pro­ce­sów) to dwa róż­ne kon­tek­sty uży­cia tej samej usłu­gi apli­ka­cji: Zamówienia (czy­li dostęp do ich two­rze­nia, aktu­ali­za­cji i pod­glą­du, to typo­wy przy­pa­dek uży­cia typu CRUD). Prawa dostę­pu do tego doku­men­tu mode­lu­je się zaś regu­ła­mi biz­ne­so­wy­mi (nie poka­za­no ich na dia­gra­mach), np. Klient ma wgląd tyl­ko w Zamówienia, któ­re sam złożył”. 

Można uznać, że małe pro­jek­ty, o małym ryzy­ku cha­osu wywo­ła­ne­go bra­kiem mode­li pro­ce­sów, moż­na reali­zo­wac na skró­ty” czy­li histo­ryj­ki użyt­kow­ni­ka i od razu model PSM (imple­men­ta­cja) z pomi­nię­ciem CIM i PIM, jed­nak jest to poważ­ne ryzy­ko już przy śred­nich pro­jek­tach. Dlatego pro­ces MDA:

{CIM -> [zakres pro­jek­tu] -> PIM} -> PSM

wyda­je się być znacz­nie efek­tyw­niej­szy co poka­zu­je prak­ty­ka (w nawia­sach klam­ro­wych {} zakres pra­cy analityka-projektanta).

Zakres pro­jek­tu to albo całe pro­ce­sy biz­ne­so­we albo świa­do­mie wybra­ne ich okre­ślo­ne aktyw­no­ści. Nie jest to tak­że żaden wodo­spad” (water­fall), bo ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych powsta­nie szyb­ciej i taniej niż lista setek histo­ry­jek z pomo­cą wie­lo­dnio­wych warsz­ta­tów anga­żu­ją­cych całe zespo­ły ludzi. Wygenerowane z mode­lu pro­ce­sów biz­ne­so­wych przy­pad­ki uży­cia, są z zasa­dy spój­ne i kom­plet­ne, więc ich ite­ra­cyj­ne (kolej­ne) spe­cy­fi­ko­wa­nie (każ­dy pro­jek­tu­je­my jako samo­dziel­ny mikro­ser­wis) pozwa­la bez ryzy­ka odda­wać je kolej­no do imple­men­ta­cji, i jed­no­cze­śnie doku­men­to­wać (uszcze­gó­ła­wiać) kolejne. 

To spraw­dzo­na w prak­ty­ce meto­da wspie­ra­na przez wie­le narzę­dzi CASE (wszyst­kie dia­gra­my i ich prze­kształ­ce­nia poka­za­ne w tym arty­ku­le powsta­ły z uży­ciem Visual-Paradigm). Diagram przy­pad­ków uży­cia UML jest tu auto­ma­tycz­nie gene­ro­wa­ny z mode­li BPMN, wg poniż­szych zasad:

BPMNtoUseCase (źr. http://​www​.visu​al​-para​digm​.com/​t​u​t​o​r​i​a​l​s​/​f​r​o​m​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​t​o​-​u​s​e​-​c​a​s​e​s​.​jsp)

Po tej ope­ra­cji wystar­czy spraw­dzić kon­tek­sty doku­men­tow i skon­so­li­do­wać w jeden ewen­tu­al­ne nad­mia­ro­we przy­pad­ki uży­cia. I na koniec:

Jeśli nie masz mode­li poję­cio­wych, bra­ku­je Ci waż­ne­go ele­men­tu ukła­dan­ki w pro­jek­to­wa­niu roz­wią­zań, któ­ry jest nie­zwy­kle pomoc­ny w dostrze­ga­niu i prze­ka­zy­wa­niu ogól­ne­go obra­zu tych historyjek.”

Ronald Ross (Business Rules)

Źródła

Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., & Brinkkemper, S. (2016). Improving agi­le requ­ire­ments: the Quality User Story fra­me­work and tool. Requirements Engineering, 21(3), 383 – 403. https://doi.org/10.1007/s00766-016‑0250‑x
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
OMG​.org. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). 334. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/
Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
Ross, R. G., & Fisher, L. (2020). Business Rules: Management and Execution.
Wautelet, Y., Heng, S., Kolp, M., & Mirbel, I. (2014). Unifying and Extending User Story Models. In M. Jarke, J. Mylopoulos, C. Quix, C. Rolland, Y. Manolopoulos, H. Mouratidis, & J. Horkoff (Eds.), Advanced Information Systems Engineering (Vol. 8484, pp. 211 – 225). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 07881-6_15
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699

Pełna Specyfikacja

Poniżej przy­kła­do­wy doku­ment wyge­ne­ro­wa­ny bez­po­śred­nio z Visual Paradigm, zawie­ra tak­że śladowanie. 

1. Procesy Business Process Diagram

Procesy Business Process Diagram

2. User Story

Historyjki użyt­kow­ni­ka jako wyma­ga­nia biznesowe.

ID

Nazwa

Rola

Produkt

Adresat

Opis

REQ001

Sprzedaż

Sprzedawca

Faktura

Klient

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

REQ002

Wydanie towa­ru

Magazynier

Dokument WZ

Klient

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

REQ003

Rejestracja Zamówień

Pracownik BOK

Zamówienie zaku­pu

Sprzedawca

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

REQ004

Śledzenie Zamówień

Klient

Zamówienie zaku­pu

Klient

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

3. Diagram Przypadków Użycia

Diagram Przypadków Użycia

4. Specyfikacja

 

Nazwa

ID

 

Główni akto­rzy 

Pula zadań

!!

Sprzedaż

UC02

Sprzedawca

Magazyny

UC03

Magazynier

Zamówienia

UC01

Klient, Pracownik BOK

4.1. Sprzedaż

ID: UC02

Usługa pozwa­la wysta­wiać faktury.

4.1.1. Główni aktorzy 

Sprzedawca

4.1.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Sprzedaż będzie doku­men­to­wa­na fak­tu­ra­mi w reje­strze sprzedaży

4.1.3. Wymagania 

4.1.3.1. Sprzedaż

ID: REQ001

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

4.1.4. Relacje

Relacja

Z

Do

unnamed

Sprzedawca

Sprzedaż

4.1.5. Diagramy Podległe 

4.1.5.1. Faktura

Faktura

4.1.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Sprzedaż

4.2. Magazyny

ID: UC03

Usługa doku­men­tu­je wyda­wa­nie towa­ru na pod­sta­wie opła­co­nych faktur.

4.2.1. Główni aktorzy 

Magazynier

4.2.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Operacje maga­zy­no­we doku­men­to­wa­ne są stan­dar­do­wy­mi doku­men­ta­mi księgowymi

4.2.3. Wymagania 

4.2.3.1. Wydanie towaru

ID: REQ002

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

4.2.4. Relacje

Relacja

Z

Do

unnamed

Magazynier

Magazyny

4.2.5. Diagramy Podległe 

4.2.5.1. Dokument WZ

Dokument WZ

4.2.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Wydanie z magazynu

4.3. Zamówienia

ID: UC01

Rejestr zamó­wień pozwa­la reje­stro­wać zamó­wie­nia, śle­dzić ich status.

4.3.1. Główni aktorzy 

Klient,  Pracownik BOK

4.3.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Zamówienia od klien­tów są reje­stro­wa­ne jako Zamówienia zaku­pu w Rejestrze zamówień

4.3.3. Wymagania 

4.3.3.1. Rejestracja Zamówień

ID: REQ003

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

4.3.3.2. Śledzenie Zamówień

ID: REQ004

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

4.3.4. Relacje

Relacja

Z

Do

unnamed

Pracownik BOK

Zamówienia

unnamed

Klient

Zamówienia

4.3.5. Diagramy Podległe 

4.3.5.1. Zamówienia Zakupu

Zamówienia Zakupu

4.3.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Rejestracja zamó­wie­nia

Czy wdrożenie zawsze wymaga reorganizacji?

Bardzo czę­sto spo­ty­kam się z pro­jek­ta­mi ini­cjo­wa­ny­mi przez śred­nie kadry kie­row­ni­cze dużych firm i urzę­dów, czę­sto mają one pew­ną wspól­ną cechę: nie może­my nic zmie­niać w stra­te­gii orga­ni­za­cji ale chce­my uspraw­nić pra­cę w naszym wydzia­le”. To z regu­ły bar­dzo cen­na ini­cja­ty­wa ale tak­że dobra dro­ga do poraż­ki pro­jek­tu. W urzę­dach czę­sto na gra­ni­cy łama­nia pra­wa… a nie raz z jego łama­niem. 

Projekty w admi­ni­stra­cji publicz­nej mają dodat­ko­wą spe­cy­fi­kę: zasa­dy usta­la pra­wo­daw­ca a nie mene­dżer orga­ni­za­cji. Bardzo dobrze opi­sał to zja­wi­sko prof. Bolesław Szafrański wska­zu­jąc przy­czy­nę wie­lu pora­żek wdro­żeń w admi­ni­stra­cji. Opisał trzy-eta­po­wy refe­ren­cyj­ny (i zale­ca­ny) pro­ces wdra­ża­nia nowych roz­wią­zań, a na jego tle, w swo­im opra­co­wa­niu, wska­zał dostrze­żo­ne zanie­dba­nia administracji:

(źr. na podst.: Bolesław Szafrański, Wydział Cybernetyki, Wojskowa Akademia Techniczna, Architektura kor­po­ra­cyj­na ? pro­ble­my nie tyl­ko pojęciowe”)

Cytuję to opra­co­wa­nie, bo model ten jest bar­dzo podob­ny do ogól­nej trój­war­stwo­wej kon­cep­cji orga­ni­za­cji. Prof Szafrański zwra­ca uwa­gę na to (z czym się zga­dzam), że kolej­ność podej­mo­wa­nia decy­zji i dzia­łań, powin­na być nastę­pu­ją­ca: opra­co­wa­nie nowej lub zmie­nio­nej stra­te­gii (Dokument stra­te­gicz­ny), opra­co­wa­nie tak­ty­ki dzia­ła­nia (Model ope­ra­cyj­ny dzia­ła­nia) oraz opra­co­wa­nie pla­nu wdro­że­nia IT (Fundament dzia­łal­no­ści, w kon­tek­ście Architektury Korporacyjnej). Oczywiście nic nie stoi na prze­szko­dzie, by ini­cja­ty­wa wyszła od dołu”.

W swo­im opra­co­wa­niu prof. Szafrański wska­zu­je, że wdro­że­nie nowej stra­te­gii wyma­ga spraw­dze­nia i ewen­tu­al­ne­go opra­co­wa­nia nowych mecha­ni­zmów, pro­ce­dur, pra­wa, pozwa­la­ją­ce­go nie tyl­ko wdro­żyć nową stra­te­gię ale tak­że sku­tecz­nie ją wymu­sić”.

Jeżeli powyż­szy model uogól­nić do posta­ci obra­zu­ją­cej zwią­zek pomię­dzy: stra­te­gią ryn­ko­wą orga­ni­za­cji, wewnętrz­ną tak­ty­ką reali­za­cji misji oraz tym jak zosta­ły one zaim­ple­men­to­wa­ne, to powsta­nie taki oto dia­gram (po pra­wej zna­ne od lat opra­co­wa­nie Business Process Trends):

Jeżeli pomiąć for­mę praw­ną, każ­da orga­ni­za­cja ma stra­te­gię i każ­da jakoś ją reali­zu­je (imple­men­tu­je: ma pra­cow­ni­ków a Ci umie­jęt­no­ści i zakre­sy obo­wiąz­ków). Mało któ­ra orga­ni­za­cja ma tak zwa­ny model ope­ra­cyj­ny”, czy­li to co łączy stra­te­gię i ludzi z ich obo­wiąz­ka­mi i uzy­ski­wa­ny­mi efek­ta­mi pra­cy. Czym jest taki model? To model pro­ce­sów biz­ne­so­wych: środ­ko­wa war­stwa” powyż­sze­go dia­gra­mu po prawej.

Rozwijające się ewo­lu­cyj­nie orga­ni­za­cje zawsze doku­men­tu­ją deta­le prac (infor­ma­cje w pro­ce­du­rach zarzą­dza­nia jako­ścią i tak zwa­nych doku­men­tach kadro­wych), czę­sto doku­men­tu­ją to, jaką rolą peł­ni orga­ni­za­cja w swo­im oto­cze­niu (misja, wizja, stra­te­gie itp.) i bar­dzo rzad­ko doku­men­tu­ją wewnętrz­ny łań­cuch war­to­ści czy­li pro­ce­sy biz­ne­so­we oraz, no naj­waż­niej­sze, logi­ka tego jak to wszyst­ko dzia­ła” w środ­ku (i czy dzia­ła z sen­sem). Wadą więk­szo­ści tego typu pro­jek­tów, jakie obser­wu­ję, jest sku­pia­nie się na deta­lach i pomi­ja­nie pryn­cy­piów. W efek­cie pro­jekt pochła­nia wie­le pra­cy i nadal nie mamy zro­zu­mie­nia cało­ści (w lit. ang. big pic­tu­re”), osią­ga­ne efek­ty są losowe. 

Pokażę na dość pro­stym przy­kła­dzie o czym mowa (pole­cam ww. opra­co­wa­nie prof. Szafrańskiego, opi­sał w nim błę­dy popeł­nio­ne w przy­pad­ku infor­ma­ty­za­cji Państwa). 

Poniższy dia­gram to uprosz­czo­ny model orga­ni­za­cji z zain­sta­lo­wa­nym sys­te­mem EOD (Elektroniczny Obieg Dokumentów) oraz zacho­wa­nym, nadal wyko­rzy­sty­wa­nym po sta­re­mu” opro­gra­mo­wa­niem pocz­ty elektronicznej. 

Linie cią­głe to dro­ga jaką poko­nu­ją doku­men­ty z uży­ciem EOD. Linie prze­ry­wa­ne to pocz­ta elek­tro­nicz­na. Jeżeli zosta­nie w jakiejś orga­ni­za­cji zain­sta­lo­wa­ny EOD (celo­wo nie uży­wam sło­wa wdro­żo­ny”) i nie zosta­nie z niej usu­nię­ty ema­il jako narzę­dzie alter­na­tyw­nej wewnętrz­nej komu­ni­ka­cji, to użyt­kow­nik będzie sam decy­do­wał, o tym któ­rym kana­łem prze­ka­że daną treść. W efek­cie EOD, któ­ry miał mieć wszyst­ko” nie ma wszyst­kie­go, dane w EOD są nie­wia­ry­god­ne i nie­kom­plet­ne. Jeżeli jest to urząd, to metry­ka spra­wy w zasa­dzie nie ma sen­su, celem jej two­rze­nia była moż­li­wość odtwo­rze­nia peł­ne­go prze­bie­gu spra­wy, a tu urzęd­nik sam decy­du­je, któ­re infor­ma­cje i doku­men­ty prze­ka­zu­je kana­łem for­mal­nym (EOD), a któ­re na boku”. Czy wszyst­ko musi być w EOD? Tak. Jeżeli nie jest, EOD jest tyl­ko uzna­nio­wym archi­wum dokumentów. 

Aby sku­tecz­nie wdro­żyć EOD nale­ży naj­pierw opra­co­wać nowy model ope­ra­cyj­ny dzia­ła­nia orga­ni­za­cji, model uwzględ­nia­ją­cy nowe narzę­dzie pra­cy, model któ­ry w spo­sób sys­te­mo­wy wyeli­mi­nu­je nie­po­żą­da­ne ele­men­ty złe­go sta­re­go sys­te­mu”. Dla przy­kła­du powy­żej nale­ży wyeli­mi­no­wać kana­ły komu­ni­ka­cyj­ne ozna­czo­ne linią prze­ry­wa­ną. Domyślam się, że wie­lu czy­tel­ni­ków myśli teraz no jak to tak bez maila?!”. Po wdro­że­niu EOD, wewnętrz­ny mail jest już nie potrzeb­ny (a nawet jest szko­dli­wy), a na zewnątrz nadal jest narzę­dziem komu­ni­ka­cji fir­ma-fir­ma (tak np. dzia­ła mój sys­tem komu­ni­ka­cji z klien­ta­mi). Bardzo czę­sto spo­ty­kam urzę­dy i fir­my, w któ­rych obieg ema­il i obieg for­mal­ny” to uzna­nio­wość pra­cow­ni­ków. Te wdro­że­nia nie speł­nia­ją pod­sta­wo­wej roli sys­te­mów EOD: śle­dze­nie spraw, sta­ty­sty­ki zaję­to­ści pra­cow­ni­ków, wychwy­ty­wa­nie wąskich gar­deł, łatwe zastę­po­wa­nie się pra­cow­ni­ków, moż­li­wość skon­tro­lo­wa­nia i prze­ję­cia spra­wy w dowol­nym momen­cie, peł­na histo­ria wymia­ny informacji. 

Takie wdro­że­nia to wła­śnie bar­dzo czę­sto ini­cja­ty­wy na śred­nich szcze­blach, gdzie mogą powstać decy­zje o wyda­niu środ­ków na takie wdro­że­nie, ale nie ma żad­nych szans na decy­zje o opra­co­wa­niu i wdro­że­niu zmian ope­ra­cyj­nych w ska­li orga­ni­za­cji (np. aktu­ali­za­cja instruk­cji kan­ce­la­ryj­nej w urzę­dzie, bez cze­go wdro­że­ni EOD nie ma tu żad­ne­go sensu).

Celowo poda­łem ten przy­kład, bo typo­wym powo­dem nie­po­wo­dzeń wdro­żeń sys­te­mów EOD czy CRM (te sys­te­my mają naj­gor­szą sta­ty­sty­kę nie­po­wo­dzeń, a są bar­dzo podob­ne do sie­bie), jest brak opra­co­wa­ne­go i wdro­żo­ne­go sku­tecz­ne­go nowe­go ope­ra­cyj­ne­go mode­lu dzia­ła­nia orga­ni­za­cji po wdro­że­niu”. Takim mode­lem są mode­le pro­ce­sów biz­ne­so­wych, ale nie w posta­ci mon­stru­al­nych ilo­ści deta­licz­nych dia­gra­mów (te są tu do nicze­go nie przy­dat­ne). Nie znam przy­pad­ku, by takie obraz­ki” się do cze­go­kol­wiek przy­da­ły. Chodzi o mode­le sfor­ma­li­zo­wa­ne, o ści­śle usta­lo­nym pozio­mie gra­da­cji pro­ce­sów. Ile dia­gra­mów powin­no być”? Tylko i aż tyle, ile trze­ba do roz­wią­za­nia pro­ble­mu… co opi­sa­łem mię­dzy inny­mi tu.

Powyższe ma tak­że inny istot­ny aspekt: pla­no­wa­nie i wdra­ża­nie zmian. Typowy roz­wój orga­ni­za­cji prze­bie­ga w spo­sób ewo­lu­cyj­ny, dość powol­ny. Nie wyma­ga żad­nych dodat­ko­wych zabie­gów poza prze­my­śla­nym wpro­wa­dza­niem nowych, poje­dyn­czych zarzą­dzeń czy drob­nych zmian orga­ni­za­cyj­nych. Jednak pró­by wdro­że­nia znacz­nych zmian w krót­kim cza­sie, z regu­ły skut­ku­ją nie­ocze­ki­wa­ny­mi efek­ta­mi, nie zawsze pożą­da­ny­mi. Moda” na re-inży­nie­rię pro­ce­sów biz­ne­so­wych w latach 90-tych prze­mi­nę­ła tak szyb­ko jak się poja­wi­ła. Dzisiejszy sil­nie kon­ku­ren­cyj­ny rynek nie daje cza­su na powol­ne, ewo­lu­cyj­ne zmia­ny. Bezpieczne zaś wpro­wa­dza­nie takich zmian nie jest moż­li­we bez przy­go­to­wa­nia. Opisane powy­żej pla­ny ope­ra­cyj­ne i ich testy, to nic inne­go jak wła­śnie przy­go­to­wa­nie się do takich zmian. Mając dobrze opra­co­wa­ne mode­le pro­ce­sów i archi­tek­tu­ry IT (jako całość Architektura Biznesowa/Korporacyjna), może­my prze­wi­dzieć i prze­te­sto­wać, więk­szość skut­ków pla­no­wa­nych zmian, i powo­li ale coraz wię­cej firm to robi… 

Wymagania biznesowe i Siatka Zachmana

Cztery lata temu pisa­łem o książ­ce Ronalda Rossa Building Business Solutions”:

Druga to pozy­cja nowa, cało­ścio­wo opi­su­ją­ca podej­ście pole­ga­ją­ca na mode­lo­wa­niu orga­ni­za­cji w ana­li­zie biz­ne­so­wej (zawie­ra część mate­ria­łu pierw­szej) . Zwraca uwa­gę na fakt, że nie cho­dzi w ana­li­zie o two­rze­nie mnó­stwa dia­gra­mów a o to, by zro­zu­mieć jak orga­ni­za­cja funk­cjo­nu­je opi­su­jąc to, oraz stwo­rzyć model, któ­ry pozwo­li na pro­gno­zo­wa­nie zacho­wa­nia orga­ni­za­cji w odpo­wie­dzi na bodź­ce, nawet te któ­re jesz­cze nie zaist­nia­ły. (Źródło: Business Rule Concepts ? czy­li jak ?wyłu­skać isto­tę rze­czy? | | Jarosław Żeliński IT-Consulting)

Niedawno wpadł mi w skrzyn­kę kolej­ny wpis na blo­gu R.Rossa:

Zachman?s basic pre­mi­se is that whe­ne­ver you engi­ne­er any­thing of com­ple­xi­ty, no mat­ter what ? a com­plex machi­ne, a sky­scra­per, a micro­chip, a spa­ce­craft, a pro­duct, a busi­ness (an enter­pri­se), or some part of a busi­ness (a busi­ness capa­bi­li­ty) ? the­re are two basic aspects that need to be addres­sed. These two aspects cor­re­spond to the columns and rows of the Framework. (Źródło: What the Zachman Architecture Framework Is ? And How It Relates to Business Rules & Business Analysis | Ronald Ross | LinkedIn, Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edi­tion, by Ronald G. Ross & Gladys S.W. Lam, 2015)

I oka­zu­je się, że zawsze war­to wra­cać do ksią­żek :). Od daw­na pra­cu­je nad uwol­nie­niem spon­so­rów pro­jek­tów od wyma­ga­nia by rozu­mie­li tech­no­lo­gię i teo­rie sys­te­mów. W lite­ra­tu­rze nie raz mozna spo­tkać poję­cie wyma­gań biz­ne­so­wych, pisa­łem o tym trzy lata temu:

Mianem sys­tem okre­śla się zwy­cza­jo­wo spe­cy­fi­ko­wa­ne opro­gra­mo­wa­nie, jed­nak pro­blem poja­wi się natych­miast, gdy dotknie­my takich pojęć jak wyma­ga­nia funk­cjo­nal­ne na opro­gra­mo­wa­nie i wyma­ga­nia biz­ne­so­we. To ostat­nie nie­sie pew­ną nie­ja­sność. Bo nie wiem czy cho­dzi o wyma­ga­nia wobec (w sto­sun­ku do) biz­ne­su (np. popra­wa jako­ści obsłu­gi klien­ta o 5% w naj­bliż­szym bada­niu jako­ści ISO) czy wyma­ga­nia biz­ne­su wobec (w sto­sun­ku do) opro­gra­mo­wa­nia (np. mini­ma­li­za­cja do zera otrzy­ma­nych i zagu­bio­nych zapy­tań ofer­to­wych). (Źródło: Inżynieria wyma­gań | | Jarosław Żeliński IT-Consulting)

Wymieniona wyżej książ­ka Rossa zawie­ra roz­dział Understanding Business Requirements i takie jego sło­wa pod tym tytułem:

RonRossBuildingBusinessSolution_17_1

Model biz­ne­so­wy two­rzy­my by opi­sać daną dzia­łal­ność, może być on tak­że uży­ty do stwo­rze­nia wyma­gań biz­ne­so­wych.” Nieco dalej czytamy:

RonRossBuildingBusinessSolution_17_2

Bardzo waż­ne: wyma­ga­nia biz­ne­so­we defi­niu­je­my wobec sys­te­mu a nie wobec biz­ne­su (fir­my). I to fak­tycz­nie jest powo­dem wie­lu nie­po­ro­zu­mień. W tym samym roz­dzia­le Ross powo­łu­jąc się na Siatkę Zachmana przy­wo­łu­je definicje:

RonRossBuildingBusinessSolution_17_3

Od dłuż­sze­go cza­su sto­su­ję w pro­jek­tach poję­cie Wymagań Biznesowych (opi­sa­ne w cyto­wa­nym wyżej, moim arty­ku­le Inżynieria wyma­gań), i po raz kolej­ny zno­wu, skła­niam się do pró­by wyko­rzy­sta­nia siat­ki Zachmana w tym celu, gdyż jeże­li ten szkie­let archi­tek­to­nicz­ny (Siatka Zachmana to tak zwa­ny szkie­let archi­tek­to­nicz­ny archi­tek­tu­ry kor­po­ra­cyj­nej) fak­tycz­nie pozwo­li spraw­nie zarzą­dzać wyma­ga­nia­mi i ich śla­do­wa­niem, to war­to z tego sko­rzy­stać, na razie porów­nu­je się (nakła­da się) ten szkie­let z MDA i jak widać jest świa­teł­ko w tunelu :):

MDA2Zachman

Dla uła­twie­nia siat­ka Zachmana w pol­skiej wer­sji (kard z pakie­tu Visual-Paradigm).

Siatka Zachmana zakres analizy

Systems Engineering Fundamentals by United States Government

Tak, taką książ­kę moż­na nabyć na Amazonie ;). Streszczenie na stro­nach sprze­daw­cy odda­je dobrze jej treść:

This book pro­vi­des a basic, con­cep­tu­al-level descrip­tion of engi­ne­ering mana­ge­ment disci­pli­nes that rela­te to the deve­lop­ment and life cyc­le mana­ge­ment of a sys­tem. For the non-engi­ne­er it pro­vi­des an ove­rview of how a sys­tem is deve­lo­ped. For the engi­ne­er and pro­ject mana­ger it pro­vi­des a basic fra­me­work for plan­ning and asses­sing sys­tem development.

Ogólnie książ­ka opi­su­je pod­sta­wo­wy kon­cep­cyj­ny etap inży­nie­rii sys­te­mów (i nie nale­ży tego utoż­sa­miać tyl­ko z bran­żą IT). Jest napi­sa­na przy­stęp­nym języ­kiem, adre­so­wa­na głów­nie dla mana­ge­rów (pierw­sze czę­ści) by zapo­znać ich z inży­nie­rią sys­te­mów i sys­te­mo­wym podej­ściem. Kierownikom pro­jek­tów poka­zu­je” czym (ewen­tu­al­nie ;)) zarządzają.

Tu tyl­ko kil­ka słów. Najpierw po raz kolej­ny cytat:

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi? (Rittel i Webber, 1973). ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

A teraz dia­gram obra­zu­ją­cy pro­ces inży­nie­rii sys­te­mo­wej” na bazie jed­nej z ilu­stra­cji w tej książce:

Proces inżynierii systemowej

Mamy tu trzy klu­czo­we eta­py, powią­za­ne iteracyjnie:

  1. Analiza wyma­gań, cho­dzi tu o wyma­ga­nia biznesowe.
  2. Analiza funk­cjo­nal­no­ści, cho­dzi tu o usta­le­nie do jakich rze­czy» sys­tem jest potrzeb­ny (prze­zna­czo­ny).
  3. Projektowanie czy­li pró­ba opra­co­wa­nia kon­struk­cji, mecha­ni­zmu dzia­ła­nia tego systemu.

Trzeci punkt to wła­śnie klucz do suk­ce­su: zanim zacznie­my kon­stru­owa­nie (np. pisa­nie kodu) war­to opra­co­wać to roz­wią­za­nie «na papie­rze”. To po pierw­sze pozwa­la unik­nąć ogrom­nych kosz­tów roz­po­zna­nia bojem” a po dru­gie daje jako pro­dukt bar­dzo dobrą (na wyso­kim pozio­mie abs­trak­cji ale kom­plet­ną) doku­men­ta­cję dzia­ła­nia systemu.

Niedawno cyto­wa­łem arty­kuł o poraż­ce sys­te­mu e‑border, tym razem innych cytat:

The Home Office had a con­cept, not a well-deve­lo­ped set of requ­ire­ments. Concepts need a reali­ty check; other­wi­se, you could be cha­sing a dre­am! Even tho­ugh the pro­gram ran a pilot to eva­lu­ate the feasi­bi­li­ty of the con­cept, the National Audit Office report (2015) cla­ims that it did not cover all aspects of the solu­tion. Consequently, the pro­gram­me was exe­cu­ted with an unte­sted con­cept and unk­nown requ­ire­ments, which led to dispu­tes. (Źródło: Blueprints Are Not Requirements!)

Jedną z głów­nych przy­czyn poraż­ki było roz­po­czę­cie reali­za­cji pro­jek­tu wyłącz­nie na bazie wizji, bez jakich­kol­wiek ana­liz i pro­jek­to­wa­nia tego co na praw­dę ma powstać i w jakich warun­kach”. Patrząc na zobra­zo­wa­ny powy­żej pro­ces inży­nie­rii sys­te­mo­wej wyko­na­no wyłącz­nie pierw­szy etap (wyma­ga­nia biz­ne­so­we) i przy­stą­pio­no do reali­za­cji pro­jek­tu bez jakich­kol­wiek ana­liz i pro­jek­to­wa­nia, od razu zaczę­ły powsta­wać pro­to­ty­py… Projekt e‑border zakoń­czył się spek­ta­ku­lar­ną porażką.

Jedną z nota­cji OMG jest SysML. Jest to dedy­ko­wa­ny dla inży­nie­rii sys­te­mów pro­fil UML. Odnosząc się do pro­ce­su inży­nie­rii sys­te­mo­wej powy­żej, powsta­ją w tej nota­cji kolej­ne diagramy:

  1. dia­gram wyma­gań (lub ich specyfikacja),
  2. dia­gram przy­pad­ków uży­cia i ich specyfikacja,
  3. model dzie­dzi­ny (mecha­nizm dzia­ła­nia sys­te­mu: dia­gra­my kom­po­nen­tów, klas i obiek­tów) oraz mode­le zacho­wa­nia sys­te­mu (dia­gra­my sekwen­cji, komu­ni­ka­cji, sce­na­riu­sze przy­pad­ków użycia).

Powyższe to wyma­ga­ne mini­mum dla popraw­ne­go wyspe­cy­fi­ko­wa­nia sys­te­mu zanim powsta­nie choć jeden wiersz kodu czy wykop pod fundament.

Z infor­ma­cji jakie posia­dam, od lat rząd USA nie pono­si takich spek­ta­ku­lar­nych pora­żek pro­jek­to­wych jak euro­pej­skie rzą­dy, jed­nak w przy­pad­ku pro­jek­tów kor­po­ra­cyj­nych już tak różo­wo nie jest :), wpad­ki mają wszystkie:

According to an often-quoted stu­dy from the Gartner Group, 75% of IT pro­jects fail. The Standish Group con­ducts an annu­al survey of IT pro­jects. Their latest report shows a decre­ase in pro­ject suc­cess rates.

  1. 32% of all pro­jects suc­ce­eded: deli­ve­red on time, on bud­get, with requ­ired features.
  2. 44% were chal­len­ged: late, over bud­get, and/or with less than the requ­ired features.
  3. 24% failed: can­cel­led prior to com­ple­tion or deli­ve­red and never used.

When we look back, we not only see failu­res but can cle­ar­ly see the boom the softwa­re indu­stry has been given with its suc­cess. But the wor­ry­ing aspect is that the­re are failu­res that are recur­ring eve­ry year, may­be in a dif­fe­rent orga­ni­za­tion but mostly with com­mon cau­ses. (Źródło: Blueprints Are Not Requirements!)

Polecam książ­kę 😉

Systems Engineering Fundamentals Kindle Edition by United States Government US Army (Author) (Źródło: Amazon​.com: Systems Engineering Fundamentals eBook: United States Government US Army: Kindle Store)

Dlaczego śladowanie wymagań jest istotne w projekcie?

Wymagania to nie­wy­czer­pa­ny temat dys­ku­sji, blo­gów i spo­rów w pro­jek­tach. Ich śla­do­wa­nie już rza­dziej jest takim tema­tem, bo mało kto to robi, a to wła­śnie mię­dzy inny­mi brak śla­do­wa­nia pro­wa­dzi do pro­ble­mów w pro­jek­cie. Typowy pro­blem to utra­ta pano­wa­nia nad zakre­sem pro­jek­tu, utra­ta pano­wa­nia nad zło­żo­no­ścią doku­men­ta­cji i ilo­ści wyma­gań” (cudzy­słów celo­wo, póź­niej o powo­dach). W kon­se­kwen­cji jakość całe­go pro­jek­tu upa­da, zado­wo­le­nie spon­so­rów tak­że (pole­cam krót­ki wpis: Why is requ­ire­ments tra­ce­abi­li­ty impor­tant on a pro­ject?). Dlaczego? Bo sko­ro wyma­ga­nia mają być FURPS i SMART, to jak to osią­gnąć i jak skon­tro­lo­wać? Jak skon­tro­lo­wać w mie­rzal­ny spo­sób np. kompletność?

O wyma­ga­niach pisa­łem nie raz, dzi­siaj z per­spek­ty­wy ich śla­do­wa­nia i celu tego pro­ce­de­ru. Bardzo czę­sto spo­ty­ka się w doku­men­tach pro­jek­to­wych wyma­ga­nia funk­cjo­nal­ne i poza­funk­cjo­nal­ne, ale mało któ­ry z tych doku­men­tów zawie­ra defi­ni­cje tych pojęć, a wyma­gań tych są set­ki a nie raz tysią­ce. Są – te wyma­ga­nia” – zbie­ra­ne” naj­czę­ściej pod­czas wywia­dów, sesji burz mózgów, sesji warsz­ta­tów wyma­gań”. Ilość wyma­gań jest naj­czę­ściej pro­por­cjo­nal­na do cza­su trwa­nia tych sesji a ana­li­za wyma­gań” jest prze­ry­wa­na gdy wyma­gań jest wystar­cza­ją­co dużo” (widy­wa­łem doku­men­ty z ponad czte­re­ma tysią­ca­mi wymagań!).

W języ­ku pol­skim sło­wo wyma­ga­nie ma bar­dzo ści­słą i bar­dzo przy­dat­na definicję:

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

Popatrzmy co na to BABOK

PMBookRequirementDefiniction

Jest to defi­ni­cja bar­dzo bli­ska tej słow­ni­ko­wej: waru­nek lub moż­li­wość pro­duk­tu lub usłu­gi, speł­nia­ją­cy ocze­ki­wa­nia” (dość wol­ne tłumaczenie ;)).

A jak są kla­sy­fi­ko­wa­ne wyma­ga­nia? Tu jest bytów” jest więcej:

PMBookRequirementDefiniction2

Tu moim zda­niem zaczy­na się mała masa­kra, bo konia z rzę­dem temu, kto jed­no­znacz­nie podzie­li dłu­gą listę cech pro­duk­tu na powyż­sze sześć kuwe­tek”. Przypomnę, że popraw­ny słow­nik pojęć to poję­cia wza­jem­nie się wyklu­cza­ją­ce, czy­li jeże­li coś jest np. wyma­ga­niem, przej­ścio­wym to nie jest żad­nym innym. Dlatego ten (taki) podział jest moim zda­niem przy­czy­ną wie­lu pro­ble­mow w projektach.

Wymagania biznesowe

Rzadko spo­ty­ka­ne a wręcz koniecz­ne do popraw­nej kon­tro­li pro­jek­tu i zarzą­dza­nia jego zakre­sem. Inna defi­ni­cja, moim zda­niem lep­sza niż ta z BABOK’a:

Business Requirements

The pur­po­se of busi­ness requ­ire­ments is to defi­ne a project?s busi­ness need, as well as the cri­te­ria of its suc­cess. Business requ­ire­ments descri­be why a pro­ject is needed, whom it will bene­fit, when and whe­re it will take pla­ce, and what stan­dards will be used to eva­lu­ate it. Business requ­ire­ment gene­ral­ly do not defi­ne how a pro­ject is to be imple­men­ted; the requ­ire­ments of the busi­ness need do not encom­pass a project?s imple­men­ta­tion deta­ils. (Business Requirements – Requirements​.com).

To rza­dziej spo­ty­ka­na defi­ni­cja wyma­gań biz­ne­so­wych. W skró­cie: wyma­ga­nia biz­ne­so­we defi­ni­cją biz­ne­so­wy cel pro­jek­tu, kry­te­ria suk­ce­su (pomy­słu); wyma­ga­nia biz­ne­so­we opi­su­ją po co pro­jekt jest uru­cha­mia­ny; wyma­ga­nia biz­ne­so­we nie mówią nic o ich imple­men­ta­cji. I to jest pro­sta i bar­dzo sku­tecz­na w uży­ciu definicja.

Schody zaczy­na­ją się przy innych wyma­ga­niach, kolej­na wersja:

Functional requ­ire­ments are a type of solu­tion requ­ire­ments. According to BABOK, the­se descri­be the beha­vior and infor­ma­tion that the solu­tion will mana­ge.” Continuing with our far­ming illu­stra­tion, an exam­ple of a func­tio­nal requ­ire­ment would be: This sys­tem will deli­ver pro­du­ce from farms in our coope­ra­ti­ve and deli­ver it to par­ti­ci­pa­ting custo­mers.” (Requirements – Requirements​.com).

Wymagania funk­cjo­nal­ne. Najczęściej poda­je się jako wyma­ga­nia wobec roz­wią­za­nia” (i słusz­nie), jed­nak nie­ste­ty, defi­nio­wa­ne są poprzez przy­kład, np. stwier­dze­nie, że funk­cjo­nal­ność to zacho­wa­nie sys­te­mu i infor­ma­cje, któ­ry­mi sys­tem zarzą­dza” jest bar­dzo nie­for­tun­ne bo nie­zwy­kle pojem­ne, pro­wa­dzi wie­lu ana­li­ty­ków to wnio­sku, że sko­ro wysta­wie­nie fak­tu­ry wyma­ga nastu klik­nięć i wpro­wa­dze­nie nastu infor­ma­cji” to wyma­gań funk­cjo­nal­nych jest też naście”. Pojęcie funk­cjo­nal­ny” jest tak sze­ro­kie, że w zasa­dzie każ­da cecha pro­duk­tu do cze­goś słu­ży i jest jakąś funk­cjo­nal­no­ścią. Przeciętny samo­chód m ich set­ki a tak na praw­dę słu­ży do prze­miesz­cza­nia się.

Poszukajmy porząd­ku i spo­so­bu śladowania.

Wymagania biz­ne­so­we to cele uru­cha­mia­nia pro­jek­tu, to są cele orga­ni­za­cji (jej kadr kie­row­ni­czych). A resz­ta? Bardzo nie­pre­cy­zyj­ne defi­ni­cje wyma­gań pro­wa­dzą do setek ich inter­pre­ta­cji. Sam fakt, że te same wyma­ga­nia (jako nazwa i opis) są, przez róż­ne oso­by tego same­go zespo­łu pro­jek­to­we­go, róż­nie kla­sy­fi­ko­wa­ne, świad­czy o tym, że jest problem.

Z pomo­cą przy­cho­dzi śla­do­wa­nie, wymu­sza dopre­cy­zo­wa­nie defi­ni­cji. Dlaczego? Bo śla­do­wa­nie, by było moż­li­we do prze­pro­wa­dze­nia, wyma­ga prze­cho­dze­nia od jed­ne­go do dru­gie­go” w cało­ści (jeden do jed­ne­go lub jeden do wie­lu ale w cało­ści), nie moż­na przejść od jed­ne­go wyma­ga­nia np. biz­ne­so­we­go do dwóch i pół wyma­gań funk­cjo­nal­nych. To muszą być cał­ko­wi­te i jed­no­znacz­ne licz­by wymagań.

Jak widać wyma­ga­nia biz­ne­so­we to cele, cele lokal­ne (dzia­ły, pio­ny), więc będzie ich kil­ka­na­ście, kil­ka­dzie­siąt przy dużych pro­jek­tach, obej­mu­ją­cych cała orga­ni­za­cję. Jeden cel biz­ne­so­wy to jed­na lub kil­ka (rzad­ko wię­cej) usług jakich ocze­ku­je­my od nowe­go roz­wią­za­nia. Tak więc nale­ża­ło­by się spo­dzie­wać kil­ku­dzie­się­ciu usług roz­wią­za­nia a nie kil­ku tysię­cy wyma­gań”. Pomijając dłu­gie dywa­ga­cje o defi­ni­cjach (były już na tym blo­gu) poniż­szy sche­mat (model poję­cio­wy) poka­zu­je związ­ki pomię­dzy spo­ty­ka­ny­mi w lite­ra­tu­rze, wyma­ga­nia­mi i ich repre­zen­ta­cja­mi (tu przy­pad­ki uży­cia w UML).

Wymagania

Na dia­gra­mie zazna­czy­łem z pomo­cą tak zwa­ne­go dzie­dzi­cze­nia” (strzał­ka z nie­wy­peł­nio­nym gro­tem wska­zu­je uogól­nio­ne poję­cie, jej dru­gi zaś koniec poję­cie szcze­gó­ło­we). Zwykła linia to powią­za­nie pomię­dzy poję­cia­mi (fakt łączą­cy róż­ne poję­cia). Tak więc wyma­ga­nia wobec roz­wią­za­nia to pewien pod­zbiór wyma­gań biz­ne­so­wych (nie wszyst­kie cele biz­ne­so­we muszą wią­zać się z kon­kret­nym roz­wią­za­niem). Wymagania wobec roz­wią­za­nia to wła­śnie spor­ne, nie­jed­no­znacz­ne, poję­cia spo­ty­ka­ne w lite­ra­tu­rze. To co moż­na potwier­dzić, to podział wszyst­kich wyma­gań” wobec roz­wią­za­nia na funk­cjo­nal­ne i nie­funk­cjo­nal­ne. Mimo bra­ku ich ści­słych defi­ni­cji (czym jest moż­li­wość łatwe­go doda­wa­nia danych kon­tra­hen­ta z listy??) wie­my, że są tyl­ko te dwa. Wymagania nie­funk­cjo­nal­ne dzie­li się (mię­dzy inny­mi) na jako­ścio­we i dzie­dzi­no­we, te dru­gie to logi­ka biz­ne­so­wa i algo­ryt­my. Mamy jed­nak pre­cy­zyj­ną defi­ni­cję poję­cia przy­pa­dek uży­cia (mam na myśli defi­ni­cję w spe­cy­fi­ka­cji nota­cji UML), jest to usłu­ga sys­te­mu, świad­czo­na akto­ro­wi (na jego żąda­nie, a wiec ini­cjo­wa­na przez akto­ra), któ­rej pro­dukt ma war­tość dla akto­ra bo jest celem korzy­sta­nia z sys­te­mu przez tego akto­ra. Tak więc przy­pad­kiem uży­cia jest to, że sys­tem pozwa­la na wytwo­rze­nie fak­tu­ry VAT” a nie to, że pozwa­la wybrać kon­tra­hen­ta z listy po klik­nię­ciu myszą”. Każda usłu­ga sys­te­mu, jego przy­pa­dek uży­cia, zwią­za­ny jest ze kon­kret­ną logi­ką jego zre­ali­zo­wa­nia (wyko­na­nia) czy­li wyma­ga­niem dziedzinowym.

Śladowanie. Jak pomaga? 

Mając listę celów pro­jek­tu, okre­śla­my, któ­re pla­nu­je­my zre­ali­zo­wać z pomo­cą nowe­go opro­gra­mo­wa­nia – to wyma­ga­nia wobec roz­wią­za­nia. Wymagania wobec roz­wią­za­nia opi­su­je­my skoń­czo­ną licz­bą wyma­ga­nych usług sys­te­mu, do któ­rych jed­no­znacz­nie przy­po­rząd­ko­wu­je­my wyma­ga­nia jako­ścio­we (np. dostęp­ność) i dzie­dzi­no­we (np. wzór na war­tość podat­ku). Całość mode­lu­je­my jako przy­pad­ki uży­cia i model dzie­dzi­ny (przy­pad­ki uży­cia – usłu­gi sys­te­mu – są reali­zo­wa­ne ele­men­ta­mi mode­lu dzie­dzi­ny, kla­sa­mi lub kom­po­nen­ta­mi reali­zu­ją­cy­mi okre­ślo­ną logi­kę). Skąd brać przy­pad­ki uży­cia? Z warsz­ta­tów? Sesji burzy mózgów? Kiepski pomysł, co napi­sa­łem na począt­ku. Jeżeli już jed­nak to robi­my to śla­do­wa­nie pozwa­la pano­wać nad zakre­sem pro­jek­tu i zło­żo­no­ścią całej doku­men­ta­cji wyma­gań: po zatwier­dze­niu wyma­gań biz­ne­so­wych, odrzu­ca­my wszyst­kie zgła­sza­ne wyma­ga­nia funk­cjo­nal­ne i nie­funk­cjo­nal­ne, któ­re nie wspie­ra­ją (nie dają się zaadre­so­wać – śla­do­wać) wyma­gań biz­ne­so­wych. Skąd brać przy­pad­ku uży­cia? Najlepiej z mode­li pro­ce­sów, bo te są zwe­ry­fi­ko­wa­nym (tu śla­do­wa­nie aktyw­ność – przy­pa­dek uży­cia) mode­lem dzia­ła­nia orga­ni­za­cji. Śladowanie wyma­ga jed­nak ści­słych – jed­no­znacz­nych, defi­ni­cji. Skoro nie da się jed­no­znacz­nie zde­fi­nio­wać funk­cjo­nal­no­ści sys­te­mu”, nie sto­suj­my tego poję­cia. Pojęcie usłu­ga sys­te­mu jest dobrze zde­fi­nio­wa­ne, w UML jest to przy­pa­dek uży­cia, w SOA i archi­tek­tu­rze kor­po­ra­cyj­nej, usłu­ga apli­ka­cyj­na koja­rzo­na jest (mapo­wa­na, śla­do­wa­na) z ele­men­tar­ny­mi (ato­mo­wy­mi) pro­ce­sa­mi biz­ne­so­wy­mi (aktyw­no­ścia­mi). 

Tak więc wyma­gań biz­ne­so­wych może być kil­ka­dzie­siąt. Wymaganych usług sys­te­mu (przy­pad­ków uży­cia) w dużym pro­jek­cie tak­że może być kil­ka­dzie­siąt. Ale set­ki, czy tysią­ce wyma­gań” to wyraz utra­ty pano­wa­nia nad zakre­sem pro­jek­tu… Tu zwró­cę uwa­gę, że wyma­ga­niem (usłu­ga sys­te­mu) może być np. wytwo­rzo­na fak­tu­ra VAT zgod­na z prze­pi­sa­mi. Cechy tej fak­tu­ry (lista pól) to nie osob­ne wyma­ga­nia, to cechy (para­me­try, atry­bu­ty) jed­ne­go wyma­ga­nia. Żadna cecha fak­tu­ry VAT nie ma sama w poje­dyn­kę żad­nej war­to­ści, nie może więc być oddziel­nym przy­pad­kiem uży­cia, tak samo jak wyma­ga­niem naszym może być samo­chód, ale jego kolor czy auto­ma­tycz­na skrzy­nia bie­gów, to cechy samo­cho­du, nie ma sen­su wyma­gać czer­wo­ne­go kolo­ru” nie ocze­ku­jąc samo­cho­du (i jak uza­sad­nić, to że ten kolor wspie­ra cel biz­ne­so­wy). Przypadkiem uży­cia samo­cho­du jest podróż a nie wło­że­nie klu­czy­ka do sta­cyj­ki, bo to jest tyl­ko jeden z ele­men­tów sce­na­riu­sza roz­po­czę­cia podró­ży samochodem.

Czemu tak czę­sto jed­nak powsta­ją nie­we­ry­fi­ko­wal­ne spe­cy­fi­ka­cje na set­ki pozy­cji? Najczęściej sły­szę – z ust ana­li­ty­ka – głu­pie tłu­ma­cze­nie: bo tak mi poka­za­no na szko­le­niu (tak czy­ta­łem w jed­nej książ­ce, tak było napi­sa­ne na blo­gu XXX, tak robi się u mnie w fir­mie itp…). Warto sobie same­mu udo­wod­nić popraw­ność wytwo­rze­nia efek­tów swo­jej pra­cy, a dobra doku­men­ta­cja ana­li­tycz­na jest sama dla sie­bie dowo­dem popraw­no­ści. Tak, mój blog tak­że nale­ży weryfikować.

Gdzie są te cholerne szczegóły

Regularnie na moich szko­le­niach oraz w toku pro­jek­tów, dosta­je pyta­nia o wali­da­cje”. Z regu­ły spo­ty­kam spe­cy­fi­ka­cje wyma­gań (albo ocze­ki­wa­nia na takie), zawie­ra­ją­ce zesta­wie­nia doku­men­tów (i for­ma­tek ekra­no­wych), dla każ­de­go zesta­wie­nie pól, dla każ­de­go pola wali­da­cje”. Problem w tym, że:

  • mie­sza­ją się tu tak zwa­ne typy pro­ste danych (zna­ko­we, licz­bo­we, itp.), tak zwa­ne maski” (data, ema­il, itp.), oraz regu­ły biz­ne­so­we (np. wła­ści­wy rabat),
  • z uwa­gi na to, że doku­men­tów jest wie­le, a pola mogą się na nich powta­rzać, powsta­je duża licz­ba powtó­rzo­nych zapi­sów wali­da­cji”, nie­jed­no­krot­nie nie­spój­nych a bywa, że sprzecznych.
  • typy pro­ste oraz regu­ły biz­ne­so­we (logi­ka biz­ne­so­wa) to dwa zupeł­nie inne obsza­ry systemu.

Jak definiować wymagania na walidacje”

Tu war­to na począ­tek wró­cić do kla­sy­fi­ka­cji wyma­gań. W arty­ku­le Inżynieria wyma­gań opi­sa­łem trzy ich rodzaje:

  1. funk­cjo­nal­ne czy­li usłu­gi apli­ka­cji (przy­pad­ki uży­cia tej aplikacji),
  2. poza-funk­cjo­nal­ne czy­li cechy jakościowe,
  3. dzie­dzi­no­we czy­li logi­ka biznesowa.

I teraz bar­dzo waż­na rzecz: któ­re ele­men­ty archi­tek­tu­ry opro­gra­mo­wa­nia, za reali­za­cję któ­rych wyma­gań odpo­wia­da­ją? W arty­ku­le Gdzie się reali­zu­ją wyma­ga­nia opi­sa­łem ogól­nie wzo­rzec pro­jek­to­wy MVC. Pomijając sam wzo­rzec, istot­ne jest to, że tak zwa­ne wali­da­cje” są doko­ny­wa­ne w dwóch róż­nych ele­men­tach archi­tek­tu­ry. Tak zwa­ne typy pro­ste danych (np. pole zna­ko­we Nazwisko) są (mogą być) spraw­dzo­ne w momen­cie ich wpro­wa­dza­nia (np. for­mat­ka ekra­no­wa nie przyj­mu­je cyfr w polu nazwi­sko). Cała logi­ka biz­ne­so­wa jest wyko­ny­wa­na wewnątrz apli­ka­cji (infor­ma­cje o ewen­tu­al­nych błę­dach poja­wią się po zatwier­dze­niu for­mu­la­rza), np. upust może być spraw­dzo­ny (albo nali­czo­ny) dopie­ro po skom­ple­to­wa­niu danych wyma­ga­nych do jego wyli­cze­nia, czy­li będzie to kil­ka róż­nych pól (naj­mniej dwa :)). Bywa, że do wyli­cze­nia cze­goś potrzeb­ne będą dane nie wpro­wa­dza­ne do danej for­mat­ki fak­tu­ry, np. sal­do klienta.

Jedną z naj­gor­szych prak­tyk pro­gra­mi­stów jakie spo­ty­kam, jest umiesz­cza­nie logi­ki biz­ne­so­wej (a są nią np. meto­dy nali­cza­nia upu­stów) w for­mu­la­rzach ekra­no­wych. Po pierw­sze pro­wa­dzi to duże­go obcią­ża­nia kodu tych for­ma­tek, po dru­gie przy dużej ilo­ści doku­men­tów (for­ma­tek ekra­no­wych) logi­ka biz­ne­so­wa jest powie­la­na, co pro­wa­dzi do dużych pro­ble­mów z utrzy­ma­niem spój­no­ści spraw­dza­nych reguł biz­ne­so­wych w apli­ka­cji. Po trze­cie pró­by pisa­nia inter­fej­sów (API) do tych apli­ka­cji (np. przyj­mo­wa­nie doku­men­tów wysta­wio­nych poza apli­ka­cją) jest nie­moż­li­we bez kolej­ne­go powie­le­nia logi­ki biz­ne­so­wej w API (jeże­li chce­my wali­do­wać” przyj­mo­wa­ne tą dro­gą dane a z raczej chce­my). Jednym sło­wem masakra.

Sprawdzoną meto­dą sku­tecz­ne­go (spój­ność, kom­plet­ność, nie­sprzecz­ność) zapi­sy­wa­nia wyma­gań dzie­dzi­no­wych (w tym wali­da­cje”) jest wydzie­le­nie w dokumentacji:

  1. słow­ni­ka pojęć
  2. słow­ni­ka reguł biznesowych 
    1. spe­cy­fi­ka­cji tablic decy­zyj­nych jako uzu­peł­nie­nia reguł biznesowych.

Słownik pojęć powi­nien obej­mo­wać wszyst­ko to co stwa­rza ryzy­ko nie­jed­no­znacz­no­ści. Reguły biz­ne­so­we, wraz z tabli­ca­mi decy­zyj­ny­mi (jeże­li są wyma­ga­ne) zebra­ne w jed­nym miej­scu (spe­cy­fi­ka­cja reguł), są niczym innym jak wyma­ga­nia­mi dzie­dzi­no­wy­mi. Tak opra­co­wa­na doku­men­ta­cja ana­li­tycz­na pozwa­la deve­lo­pe­ro­wi na łatwe poru­sza­nie się po doku­men­cie, mamy moż­li­wość wery­fi­ka­cji wyma­gań, ich spój­no­ści i kom­plet­no­ści. Załączając spe­cy­fi­ka­cje wzo­rów doku­men­tów (mock-up’y ekra­nów czy­li for­mat­ki ekra­no­we) każ­dy obszar takie­go wzo­ru albo jest oczy­wi­sty, albo jest zde­fi­nio­wa­ny (jako nazwa) w słow­ni­ku pojęć. Cała nie­try­wial­na logi­ka dzia­ła­nia jest opi­sa­na regu­ła­mi biz­ne­so­wy­mi. Ogólne zasa­dy two­rze­nia takiej dokumentacji:

  1. W toku ana­li­zy opra­co­wu­je­my mode­le pro­ce­sów biz­ne­so­wych zawie­ra­ją­ce wyłącz­nie aktyw­no­ści i ich pro­duk­ty (czy­li pro­ce­sy biz­ne­so­we) i nic ponad to (dodat­ko­we szcze­gó­ły to albo pro­ce­du­ry albo sce­na­riu­sze przy­pad­ków uży­cia, to inne dokumenty).
  2. Na mode­lach pro­ce­sów zazna­cza­my wszyst­kie aktyw­no­ści zwią­za­ne ze sto­so­wa­niem reguł biz­ne­so­wych (kon­wen­cja doku­men­to­wa­nia reguł na mode­lach zale­ży od uży­te­go narzę­dzia CASE). Reguły biz­ne­so­we uzu­peł­nia­my o ewen­tu­al­ne kry­te­ria decy­zyj­ne (np. w posta­ci tablic decyzyjnych).
  3. Równolegle pro­wa­dzi­my słow­nik pojęć dla dokumentacji.
  4. Nie defi­niu­je­my (jako biz­nes, a nawet ana­li­tyk biz­ne­so­wy, zgła­sza­ją­cy wyma­ga­nia) typów pro­stych, one są albo oczy­wi­ste, albo wyni­ka­ją z defi­ni­cji pojęć (w razie wąt­pli­wo­ści pisze­my czym jest nazwi­sko w słowniku).

Ważna rzecz. Decyzje o tym jaki­mi typa­mi danych ope­ru­je apli­ka­cja, to decy­zje deve­lo­pe­ra (pro­gra­mi­sty). Moim zda­niem pro­gra­mi­sta żąda­ją­cy w wyma­ga­niach poda­nia mu typów danych, jest nie­ukiem albo leni­wym sabo­ta­ży­stą (uży­cie – wybór typów danych, w tym typów zło­żo­nych, to decy­zje i kom­pe­ten­cje developera!).

Poniżej opi­sa­ne ele­men­ty umiesz­czo­ne na jed­nym sche­ma­cie blokowym:

Logika biznesowa

Tak więc, war­to roz­wa­żyć sto­so­wa­nie reguł biz­ne­so­wych i słow­ni­ków pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to spraw­dzo­na i bar­dzo przy­dat­na tech­ni­ka ana­li­zy i doku­men­to­wa­nia logi­ki biz­ne­so­wej. Polecam tak­że stro­nę The Business Rules Group i zamiesz­czo­ny tam Manifest Reguł Biznesowych. Tworzenie mon­stru­al­nych doku­men­tów wyma­gań, zawie­ra­ją­cych dzie­siąt­ki razy powie­la­ne wali­da­cje” pro­wa­dzi do wie­lu kło­po­tów z utrzy­ma­niem spój­no­ści i kom­plet­no­ści takich spe­cy­fi­ka­cji. Pomijam już ich uciąż­li­wą obję­tość. Jako mate­riał dla pro­gra­mi­sty są one wte­dy trud­ne w uży­ciu, do tego skła­nia­ją do naj­gor­szych prak­tyk, jaki­mi jest mię­dzy inny­mi umiesz­cza­nie logi­ki biz­ne­so­wej w kodzie for­ma­tek ekranowych.

Na koniec pole­cam książ­kę Building Business Solutions poświę­co­na temu zagadnieniu.