Wstęp

Siedem lat temu (2015) arty­kuł o wyma­ga­niach i śla­do­wa­niu koń­czy­łem słowami: 

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.

Source: Dlaczego śla­do­wa­nie wyma­gań jest istot­ne w pro­jek­cie? – Jarosław Żeliński IT-Consulting

Nadal poja­wia­ją się publi­ka­cje o wyma­ga­niach, zarzą­dza­niu nimi i reali­zo­wa­niu ich. Na ryn­ku są dostęp­ne apli­ka­cje pozwa­la­ją­ce je kolek­cjo­no­wać i zarzą­dzać taką kolek­cją. I sta­le mamy do czy­nie­nia z ich – wyma­gań – nie­jed­no­znacz­no­ścią . Okazuje się, że ich zna­cze­nie sta­je sie klu­czo­we dla pro­jek­tów, tak­że z per­spek­ty­wy pra­wa (PZP i zde­fi­nio­wa­ne w zale­ce­niach UZP poję­cie potrze­ba). Tym razem sku­pię się na poję­ciach «wyma­ga­nie» i «potrze­ba» w odnie­sie­niu do pro­jek­tu rozwiązania.

Mała debata

Niedawno mia­łem ogrom­ną przy­jem­ność wzię­cia udzia­łu a deba­cie na temat wyma­gań i tego co powszech­nie nazy­wa­ne jest Inżynierią Wymagań. Moim roz­mów­cą był Tom Gilb a deba­tę zosta­ga­ni­zo­wał Karolina Zmitrowicz. W toku tej deba­ty uda­ło nam się dojść do pew­ne­go cie­ka­we­go poro­zu­mie­nia: odkry­li­śmy, że ​„od lat mówi­my prozą”. 

Debata poka­za­ła waż­ną rzecz: nale­ży zawsze mówić o jakie wyma­ga­nia chodzi. 

Nie cho­dzi też o to by wydzie­lać wyma­ga­nia poza-fun­cjo­nal­ne, bo nie ma sen­su ich tak dzie­lić. Mamy ogra­ni­cze­nia i śro­do­wi­sko, ono tak­że jest ogra­ni­cze­niem czy­li, czymś cze­go z okre­ślo­ne­go powo­du wyma­ga­my. O tym posłu­cha­cie tu: 

Ale po kolei…

Wymagania czyli co?

Na począ­tek defi­ni­cje klu­czo­wych pojęć (słow­nik języ­ka pol­skie­go PWN):

wyma­ga­nie: waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpo­wia­dać
potrze­ba: to, co jest potrzeb­ne do wła­ści­we­go funk­cjo­no­wa­nia
pro­jekt: doku­ment zawie­ra­ją­cy obli­cze­nia, rysun­ki itp. doty­czą­ce wyko­na­nia jakie­goś obiek­tu lub urzą­dze­nia
mate­riał: zbiór wia­do­mo­ści i danych z jakiejś dzie­dzi­ny
kon­cep­cja: pomysł, projekt

(https://​sjp​.pwn​.pl/)

UZP defi­niu­je potrze­bę jako: «funk­cja, któ­rej bra­ku­je do osią­gnię­cia celu lub wyko­na­nia dzia­ła­nia» (źr. zale­ce­nia UZP). W pro­jek­tach zwią­za­nych z inży­nie­rią, a więc inży­nie­rią opro­gra­mo­wa­nia tak­że, mamy trzy klu­czo­we role: zama­wia­ją­cy (przy­szły użyt­kow­nik), pro­jek­tant oraz dostaw­ca (wyko­naw­ca). Spotykane tezy jako­by inży­nie­ria opro­gra­mo­wa­nia była jakąś inną inży­nie­rią, są nie do obro­ny: kom­pu­ter jest defi­nio­wa­ny jako: pro­ce­sor, pamięć i pro­gram. jest to więc urzą­dze­nie, podob­nie jak wie­le innych zawie­ra­ją­cych kom­pu­ter. Nie raz wyka­zy­wa­no to na kon­fe­ren­cjach np. orga­ni­za­cji inży­nier­skiej INCOSE.

Poniżej sche­mat obra­zu­ją­cy powyż­sze poję­cia w kon­tek­ście pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia, czy­li kom­pu­te­ra dzia­ła­ją­ce­go zgod­nie z ocze­ki­wa­nia­mi zamawiającego: 

W pro­jek­cie mamy trzy klu­czo­we role: biz­nes, ana­li­tyk-pro­jek­tant i deve­lo­per. Biznes zgła­sza potrze­by i dostar­cza mate­ria­ły jaki­mi są tu wszel­kie pisem­ne arte­fak­ty jakie powsta­ją w ana­li­zo­wa­nej fir­mie . Na tej pod­sta­wie spi­sy­wa­ne są wyma­ga­nia (wobec roz­wią­za­nia). Po zebra­niu i zatwier­dze­niu wyma­gań i na pod­sta­wie mate­ria­łów, powsta­je model biz­ne­so­wy i pro­jekt roz­wią­za­nia: logi­ka opro­gra­mo­wa­nia, tej jego czę­ści, któ­ra reali­zu­je potrze­by biz­ne­so­we (speł­nia wyma­ga­nia). Projekt to wła­śnie wyma­ga­nie jakie musi speł­nić dostaw­ca (deve­lo­per): dostar­czyć opro­gra­mo­wa­nie zgod­ne z pro­jek­tem, a tak napraw­dę kom­pu­ter odpo­wia­da­ją­cy na potrze­by biznesu. 

Skąd te wymagania wziąć?

Pojawiło się poję­cie «kom­pu­ter» a kom­pu­ter to ​„pro­ce­sor, pamięć i pro­gram” . Można więc tak­że powie­dzieć, że kom­pu­ter to sys­tem, bo skła­da się z tych trzech powią­za­nych, współ­pra­cu­ją­cych elementów. 

Kluczem do tych roz­wa­żań jest sta­ry i dobrze zna­ny Model Wewnętrznego Łańcucha Wartości opi­sa­ny przez M.E.Portera :

Jest to model opi­su­ją­cy fir­mę z per­spek­ty­wy dwóch obsza­rów aktyw­no­ści: ope­ra­cyj­ny i wspie­ra­ją­cy. Patrząc na obszar ope­ra­cyj­ny, mamy: pro­ce­sy logi­stycz­ne, mar­ke­ting i sprze­dać, obsłu­gę oraz Operations czy­li two­rze­nie «tego co jest przed­mio­tem ofer­ty». Z per­spek­ty­wy tego jakie infor­ma­cje powsta­ją i są prze­twa­rza­ne (patrz: Architektura infor­ma­cji, sys­tem infor­ma­cyj­ny a sys­tem infor­ma­tycz­ny w orga­ni­za­cji) musi­my wyod­ręb­nić kil­ka obsza­rów dzie­dzi­no­wych: okre­ślo­ny prze­pływ pra­cy mię­dzy ludź­mi (co i w jakiej kolej­no­ści robić), opis pro­duk­tu (czym on jest), opis pro­duk­cji (jak on powsta­je) oraz … Ważne jest poję­cie «komu­ni­kat».

Powyższe mozna zobra­zo­wać np. tak:

Organizacja, w tym tak­że fir­ma na ryn­ku, to sys­tem reagu­ją­cy na żąda­nia z ryn­ku: klient zama­wia ofe­ro­wa­ny pro­dukt i ten jest mu dostar­cza­ny. Żeby to wszyst­ko mogło funk­cjo­no­wać musi ist­nieć Opis Produktu, musi być on wytwa­rza­ny (Produkcja), a kolej­ność wszyst­kich reali­zo­wa­nych zadań i prac musi być upo­rząd­ko­wa­na (Opis Pracy). 

Produkcja, by była moż­li­wa, wyma­ga zde­fi­nio­wa­nia tego co ma być pro­du­ko­wa­ne (Struktura Produktu) oraz musi ist­nieć infra­struk­tu­ra pro­duk­cyj­na (System Produkcji) czu­li np. hala pro­duk­cyj­na. Ta, jeże­li jest nowo­cze­sna, to jest skom­pu­te­ry­zo­wa­na. Do jej kon­tro­li i ste­ro­wa­nia nią potrzeb­ny jest System Zarządzający Procesami Produkcji.

To wszyst­ko dzie­je się z uży­ciem okre­ślo­nych zaso­bów (w tym finan­so­we), całość to okre­ślo­ny sys­tem pro­ce­sów biz­ne­so­wych jakim jest Przepływ pracy.

Każdy z tych sys­te­mów to narzę­dzie pra­cy ludzi, są oni użyt­kow­ni­ka­mi tych sys­te­mów. Jak to dzia­ła? Podobnie jak ludzie, sys­te­my wymie­nia­ją sie komu­ni­ka­ta­mi. Nie jest moż­li­we by ludzie komu­ni­ko­wa­li sie w róż­nych tema­tycz­nie spra­wach, współ­dzie­ląc jed­ną uni­wer­sal­ną tabel­ką na wspól­nym sto­le, i nie jest moż­li­we, by komu­ni­ko­wa­ły się tak te sys­te­my. Dlatego każ­dy ma swo­je tabel­ki a poro­zu­mie­wa­ją się komunikatami. 

Wymagania na te sys­te­my to nic inne­go jak:

• opis wewnętrz­ne­go mecha­ni­zmu dzia­ła­nia każ­de­go z nich,
• opis mecha­ni­zmu wymia­ny komu­ni­ka­tów mię­dzy nimi.

Aż tyle i tyl­ko tyle. Aby to zro­bić wcze­śniej musi­my opi­sać prze­pływ infor­ma­cji i udział ludzi w tym prze­pły­wie oraz oczy­wi­ście struk­tu­rę każ­de­go komu­ni­ka­tu: są nimi dokumenty. 

A gdzie wymagania użytkownika

Czy więc mamy tu jakieś wyma­ga­nia użyt­kow­ni­ka? Nie, bo użyt­kow­nik sys­te­mu jest czę­ścią tego sys­te­mu, więc jego rola w tym wszyst­kim nie jest jego wolą a obo­wiąz­kiem. Mamy sys­tem a ​„użyt­kow­nik” jest jego czę­ścią. Dlatego wła­śnie mamy wyma­ga­nia wobec roz­wią­za­nia, to pro­jekt tego sys­te­mu, a nie mamy wyma­gań użyt­kow­ni­ka. To co sły­szy­my od ludzi to nie ich wyma­ga­nia a pro­ble­my do rozwiązania:

Źródła