Wczoraj odby­ła się w Warszawie kon­fe­ren­cja Inżynieria Wymagań, na któ­rej mia­łem przy­jem­ność wygło­sić refe­rat o kla­sy­fi­ka­cji wyma­gań. Celem mojej pre­zen­ta­cji było zwró­ce­nie uwa­gi na to, że zarzą­dza­nie wyma­ga­nia­mi to nie tyl­ko ich ​„zbie­ra­nie i kla­sy­fi­ko­wa­nie” oraz, że wyma­gań jest wię­cej niż tyl­ko ​„funk­cjo­nal­ne i poza-funkcjonalne”.

Powszechny w lite­ra­tu­rze przed­mio­tu ter­min ​„pozy­ski­wa­nie wyma­gań” jest bar­dzo róż­nie rozu­mia­ny. Można wyma­ga­nia ​„pozy­ski­wać” pod­czas sesji warsz­ta­to­wych JAD, burz mózgów, z pomo­cą ankiet, pisa­nia ​„user sto­ry” itp. Wszystkie te meto­dy mają jed­ną poważ­ną wadę: pro­du­ku­ją ogrom­ną ilość dekla­ra­tyw­nych, nie­we­ry­fi­ko­wal­nych tre­ści. Lista wyma­gań w posta­ci tabe­li z set­ka­mi wier­szy niko­go tu nie zaska­ku­je. To nie działa!

Inżynieria wymagań

Coraz czę­ściej zaczy­na poja­wiać się poja­wiać nie tyl­ko w pra­sie, poję­cie ​„inży­nie­ria wyma­gań”. Dla zasa­dy popa­trz­my na zna­cze­nia słów (sł. j. polskiego):

inży­nie­ria ?pro­jek­to­wa­nie i kon­stru­owa­nie obiek­tów oraz urzą­dzeń technicznych?
wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?
wyma­ga­ny ?nie­zbęd­nie potrzebny?

Tak więc inży­nie­ria wyma­gań to ​„pro­jek­to­wa­nie nie­zbęd­nych warun­ków, któ­rym coś [roz­wią­za­nie] musi odpo­wia­dać”. Moim zda­niem istot­ne jest jest uży­cie sło­wa ​„pro­jek­to­wa­nie” a nie ​„zbie­ra­nie”. Zbieranie to pra­ca ste­no­gra­fa. Projektowanie to już zupeł­nie inna pra­ca. Raz, że twór­cza, dwa że rzą­dzą­ca się pew­ny­mi pra­wa­mi: przede wszyst­kim spe­cy­fi­ka­cja wyma­gań to pew­na okre­ślo­na kon­struk­cja. Jaka? Zgodnie z zasa­da­mi: spój­na, nie­sprzecz­na, wery­fi­ko­wal­na i kom­plet­na. Czy takie cechy ma np. ste­no­gram z kil­ku­dnio­wych warsz­ta­tów JAD czy burzy mózgów albo dane zebra­ne z ankiet wśród przy­szłych użyt­kow­ni­ków dane­go roz­wią­za­nia? Szczerze wąt­pię.

Pojawia się kolej­ne pyta­nie: co z wyni­ka­mi ana­li­zy wyma­gań po zakoń­cze­niu pro­jek­tu wdro­że­nio­we­go? Niemalże w 100% przy­pad­ków są odkła­da­ne na pół­kę, a kolej­ne wdro­że­nie lub roz­bu­do­wa posia­da­nych narzę­dzi, to kolej­na, pro­wa­dzo­na od zera ana­li­za wyma­gań. Jak słusz­nie zauwa­żył jeden z pre­le­gen­tów, wyłą­cza­jąc start-up’y, pro­jek­ty wdro­że­nio­we (wybór, zakup, imple­men­ta­cja) to tak na praw­dę zarzą­dza­nie zmia­ną a nie ​„nowe projekty”.

Wyobraźmy sobie, że zamiast odkła­dać doku­men­ta­cję wyma­gań do lamu­sa, utrzy­mu­je­my jej aktu­al­ność i wycią­ga­my ją za każ­dym razem, gdy roz­po­czy­na­my kolej­ny nowy pro­jekt, wyma­ga­ją­cy zmia­ny jakiejś funk­cjo­nal­no­ści lub pozy­ska­nia cał­kiem nowej. Wtedy, zamiast pro­wa­dzić kolej­ną kosz­tow­ną i dłu­gą ana­li­zę wyma­gań, ana­li­zu­je­my pla­no­wa­ne zmia­ny i nano­si­my je na posia­da­ną już i kon­ser­wo­wa­ną doku­men­ta­cję. Próby korzy­sta­nia z ana­liz poprzed­nich ad-hoc naj­czę­ściej koń­czą się fia­skiem, gdyż z regu­ły każ­dą robi inny dostaw­ca roz­wią­za­nia, więc każ­da jest inna i naj­czę­ściej nie­spój­na z innymi.

Spójrzmy teraz na poniż­szy diagram:

Na dia­gra­mie mamy dwie linie (linia prze­ry­wa­na to kosz­ty bie­żą­ce, cią­gła to kosz­ty nara­sta­ją­co): czer­wo­na to kosz­ty tra­dy­cyj­ne­go mode­lu pro­wa­dze­nia nie­za­leż­nych ana­liz, ​„od zera” dla każ­de­go pro­jek­tu. Niebieska poka­zu­je kosz­ty mode­lu, w któ­rym zarzą­dza­my zmia­ną. Realia poka­zu­ją, że oszczęd­no­ści są jesz­cze więk­sze, gdyż w mode­lu ana­liz ad-hoc, pomniej­sze pro­jek­ty reali­zo­wa­ne są ​„zwin­nie” bez żad­nej doku­men­ta­cji, gdyż albo nie ma na jej opra­co­wa­nie cza­su (bar­dzo czę­sto) albo wiel­kość (mały) pro­jek­tu skła­nia do podej­mo­wa­nia ryzy­ka pra­cy bez doku­men­ta­cji. Niestety pra­ca bez doku­men­ta­cji czę­sto pro­wa­dzi do odkry­wa­nia wyma­gań dość kosz­tow­ną meto­dą prób i błę­dów (pro­to­ty­po­wa­nie). Jak wie­my, pra­wie 80% pro­jek­tów to pro­jek­ty wadli­we, w 100% przy­pad­ków źró­dłem jest (mię­dzy inny­mi) zła spe­cy­fi­ka­cja wymagań.

Jak widać, z zupeł­nie z innej stro­ny ​„odkry­li­śmy” coś co nazy­wa­my archi­tek­tu­rą kor­po­ra­cyj­ną. Skoro każ­da ana­li­za wyma­gań w ist­nie­ją­cej orga­ni­za­cji, to każ­do­ra­zo­wa ana­li­za od pozio­mu moty­wa­cji biz­ne­so­wej pro­jek­tu, przez wyma­ga­ne usłu­gi apli­ka­cyj­ne, inte­gra­cje aż do plat­form sprzę­to­wo-sys­te­mo­wych, to mamy nic inne­go, jak pro­jekt doku­men­to­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej. I na koniec bar­dzo waż­na moja uwa­ga: za jakość wyma­gań odpo­wia­da i pono­si kon­se­kwen­cje w 100% kupu­ją­cy, nigdy dostawca!

Ma sens? Ma!

Na koniec pole­cam bar­dzo cie­ka­wy arty­kuł Bogdana Berezy o inży­nie­rii opro­gra­mo­wa­nia w dzi­siej­szym (19 Marca 2014) nume­rze [[COMPUTERWORLD]].